実践 ICONIXプロセス : プレファクタリング カプセル化

詳細設計の成果物は、詳細クラス図。
実装に必要な、すべてのクラス、属性、操作が定義されている完成バージョン。

詳細クラス図は、ユースケース記述を元にシーケンス図を描きながら、丁寧に実装方法を検討しているはず。だから、ワーキングソフトウェアを作る準備が整っている。

ここでモデリングツールの「コード生成」ボタンを押して、コードのテンプレートと作って、コード書きモードに突入することは可能。

プレファクタリング

コードを書いて、動くことを確認し、それから、ぎこちない箇所をリファクタリングする、ということは大切な活動です。設計をコードエディタ上でやっているなら、これもひとつのやり方。

しかし、ICONIXプロセスでは、設計は詳細クラス図で具体化する。この段階で、設計の改良をすることは、とてもコストパフォーマンスが高い。

実コードよりクラス図の方が、全体の見通しが良いです。

例えば、
・操作(メソッド)が集中しているクラス
・操作が割り当てられていないクラス( setter/getter だけのクラス)
・一つの操作だけの手続きオブジェクト

などが簡単に見つかります。

どれも典型的なアンチパターン。設計の改良を検討すべき兆候です。
コードを書いてからメソッドの移動を検討するより、この段階で、操作の割当クラスを検討したほうが、分かりやすいし、作業量も少なくてすみます。

リファクタリング(設計の改善)は、別に、コードを書き終わるまで先送りする必要はありませんよね。
プレファクタリングをしましょう。 ICONIXプロセスでは、詳細なクラス図が完成しているんですから。

カプセル化

詳細クラス図のレビューでは、
・関連するデータと操作が一つのクラスにカプセル化する
・関係の弱いデータや操作は、別のクラスに分離してカプセル化する
を丁寧に検討する。

もちろん、ドメイン(問題領域)の知識は、ドメインオブジェクトにカプセル化すること。

また、一つの大きなドメインオブジェクトではなく、密接に関連するデータと操作だけに絞り込んで小さくカプセル化したオブジェクトが連携して、協調動作するように設計する。

一つの手続きだけをカプセル化した手続きオブジェクト(名前が、 XXX-er とかになっていることが多い)は、どこかのクラスの操作に割り当てるべきではないかと、検討する。

・関連するデータと操作だけを厳選してひとかたまりにする
・関係の弱いデータや操作は、別クラスに分離する(関心の分離)

特に、ドメインオブジェクトへのカプセル化を念入りに検討しましょう。

カプセル化の原則を徹底することが、理解しやすく、変更が安全で容易なクラスを設計するコツです。
ここで、面倒がると、コードは、破綻への道に進み始めます。最初はゆっくりですが、あっという間に加速して、保守地獄にまっさかさまです。

カプセル化、とくにドメインの知識をドメインオブジェクトにカプセル化することに、時間とエネルギーを使いましょう。

詳細設計レビューの今こそ、最大で最後のチャンスです。

実践 ICONIXプロセス : ドメイン駆動

詳細設計の結果、さまざまな実装クラス、永続化のメカニズムや Web MVC メカニズムのクラスが登場します。

でも、ユースケースの実現はドメインオブジェクトが中核オブジェクトです。

ユースケース記述では、業務の用語つまりドメインモデルのクラス名を使うことを何度も強調してきました。
問題の解決空間には、さまざまな実装用のオブジェクトが必要です。
しかし、中心は問題空間の概念・知識です。

利用者にとって役に立つソフトウェアは、問題領域の知識をきちんと知っているソフトウェアです。

そして、問題領域の知識は、実装オブジェクトにちりばめるべきではありません。ドメインオブジェトに問題領域の知識をまとめておけば、理解が容易で、変更が容易なソフトウェアになります。

問題領域の知識があちこちのオブジェクトに分散したソフトウェアは、新たな知識を追加してソフトウェアを改良していくうちに、どんどん読みにくくなり、最後は変更が不可能な状態になります。破綻してしまいます。

詳細設計のレビューでは、ユースケース実現の中核が、ドメインオブジェクトであることを重点的にチェックしましょう。 ドメインモデルで発見したクラスが、シーケンス図でも主役であることを確認しましょう。

もし、脇役であるなら、設計を変更することを真剣に検討してください。

問題領域の用語の整理、つまりドメインモデルの作成からスタートする ICONIXプロセスは、実装まで一貫して、ドメインオブジェクトが中心です。ドメイン駆動で分析し、設計し、実装し、テストすることが、ICONIXプロセスなんです。

役に立つソフトウェアを自然に楽に作るためにユースケースの実現をドメイン駆動で実践的に進めましょう。ICONIXプロセスを使って。

実践 ICONIXプロセス : ユースケースの実現

詳細設計、つまりシーケンス図と詳細クラス図のレビューは、技術者しかできません。
しかし、だからこそ、ユースケースとの整合性のチェックが、詳細設計レビューの最重要事項です。

ある程度の経験者であれば、詳細クラス図で、設計の議論ができます。クラスへの操作の割り当て、つまりクラスの責務の設計とか、さまざまなデザインパターンの適用の是非とか。

しかし、詳細クラス図の議論は、本来の目的である、ユーザに利便性を提供するという視点が欠落するリスクが常にあります。

詳細設計のレビューでは、ユースケース記述を貼り付けたシーケンス図を精査します。
ユースケースの記述をひとつずつたどりながら、ユースケースが実現できるようになっているかをチェックします。

重要なことは「ユースケースの実現」です。

詳細設計とそのレビューは、実装の世界のメンバーだけでやります。
だからこそ、詳細設計レビューでは「ユースケースを実現しているか?」という利用者の視点で、徹底的に設計内容をチェックすべきです。

乱暴にいえば、オブジェクトとその協調動作の設計がぎこちなくても、ユースケースがきちんと実現できていれば、最も重要な目的は達成できている、という評価基準が重要です。

実践 ICONIXプロセス : 居心地の良さ?

予備設計までは、業務の用語、ユーザの用語だけで分析・設計することに集中してきました。
詳細設計では、実装技術の用語、フレームワークの API、Java の API がたくさん登場します。

多くの技術者にとっては、ようやく居心地が良くなった気分かもしれません。

言葉の影響

予備設計まで慣れない形式的な言葉を使っていたが、ようやく気軽にいつもの言葉でしゃべれるようになった、という感じかもしれません。

使う言葉は、発想や価値感に大きく影響します。

実装の言葉でしゃべるのが居心地が良い、と感じているということは、設計・実装・テストも、実装の価値観で判断してしまうということです。

引き戻す

詳細設計レビューで重要なことは、実装の言葉が追加されても、中心は問題領域の言葉(ドメインモデル)と利用のシナリオ(ユースケースモデル)でなければいけません。

役に立つソフトウェアを作るには、問題領域の知識を増やし、利用者の使い方を熟知することが絶対に必要です。
詳細設計のレビュアーは、実装が分かる人間、つまり技術者しかできません。しかし、このレビュアーは、実装の世界に浸るのではなく、ユースケース駆動、ドメイン駆動の世界を貫くのが仕事です。

実装の言葉がでてくると、ついつい実装の価値観と判断基準にはまり込んでいってしまう開発メンバーを、問題領域の価値観・判断基準に引き戻さなければいけません。

自分ではできなくても

経験やスキルの問題もありますが「意識」の問題は非常に大きい。

まったく同じ技量・経験の技術者が二人いて、詳細設計の担当者とレビュアーに役割分担する。まちがいなく、詳細設計を担当した技術者は、実装の価値観にはまりこんで行きます。
ある意味、それは自然のことです。実装の言葉を駆使しなければいけないのですから。

だからこそ、レビュアーを担当するときには、意識的に徹底的に、実装の価値観ではなく、問題領域の価値観でチェックをし、判断をする。

そうすることが、役に立つ良いソフトウェアを開発する勘所だから。

実践 ICONIXプロセス : 詳細設計レビューの目的

詳細設計レビューの重要な3つのチェックポイント。

・ユースケース駆動になっているか?
・ドメイン駆動になっているか?
・カプセル化をしているか?

起こりがちな問題

詳細設計で、シーケンス図を描きながら、クラス図を完成させていきます。
いよいよ実装クラスが登場してきます。

この実装クラスの登場により、設計が本来の目的から大きくはずれがちになります。
実装用のオブジェクトが主役になり、手続き指向の設計が中心になる。

詳細設計レビューは、この問題をチェックし、ただしい方向に軌道修正をする、重要なステップです。
レビュアーは、十分な経験を積んだレベルの高い開発者が担当すべきです。

ユースケース駆動がどこかにいっちゃう

実装のメカニズムに夢中になるあまり、何を実装しようとしているか見失ってしまう。
フレームワークの実装パターンをどうやって使うかを考えるが、なにを実現しようとしているのか、見失う。

最悪のケースでは、フレームワークにより魅力的なクラス/メソッドがあったので、そちらを使ってみた。結果として要求仕様(ユースケースモデル)を勝手に変えしまった、ということが実際にありました。

詳細設計レビューでは、いつも、ユースケース記述を実現するんだ、という視点で念入りにチェックしてください。
この実装は、ユースケースをどう実現しているんだろう?

ドメイン駆動がどこかにいっちゃう

ドメインモデリングで、問題領域の用語を洗い出し、整理しながら分析・設計をしてきました。
実装クラスが登場すると、関心の中心がいつのまにか、ドメインオブジェクトではなく、フレームワークの足場クラスなどに移動してしまう。

気がつくと、シーケンス図上で、ドメインクラスは隅っこにちょっこっと登場し、メッセージの矢印がどこからも来ていない。 ( setter, getter は描かないのが ICONIX流なので)

書籍詳細を表示するユースケースであれば、シーケンス図でも、中心は、Book オブジェクトであるべきです。
Book オブジェクトが脇役であることを発見したら、徹底的にレビューをしましょう。

書籍の詳細を表示したいわけですから、Book オブジェクトが多くの責任を果たすべきです。
そういう設計、作り方が、役にたつソフトウェア、保守が容易なソフトウェアをつくるポイントですから。

カプセル化が貧弱

気が付けば、ユースケースを実現するために、手続き型の設計をはじめちゃっている。
オブジェクトという名前だけど、実際には、メソッドの入れ物を用意しているだけ。

メソッド(手続き)の数だけ、オブジェクトが発生している。

クラスを責務を持たせる、関連する操作とデータを一箇所に集めておく。
クラス図に、操作だけのクラスを発見したら警戒警報です。

よーく見直してみましょう。
関連性が強いデータと操作は、まとめておきましょう。そのほうが読みやすく修正が簡単なコードになります。

手続き型設計は逆のパターンも登場する。
なんどもかんでも、一つのクラスにメソッドを詰め込む。Java の String クラスがちょっと、この傾向がありますね。

Customer という馬鹿でかいクラスがあって、Customer に関する手続きはすべて、このクラスに詰め込む。
クラス図で、パブリックな操作が5つも10もあるようなクラスを発見したら警戒警報です。

カプセル化とは、なんでも詰め込める魔法の入れ物を用意することではないのです。

calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< March 2024 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM