<< 実践 ICONIXプロセス : 詳細設計のまとめ | main | 実践 ICONIXプロセス : 居心地の良さ? >>

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

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

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

起こりがちな問題

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

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

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

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

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

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

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

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

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

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

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

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

カプセル化が貧弱

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

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

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

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

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

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

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

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
 123456
78910111213
14151617181920
21222324252627
28293031   
<< May 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM