<< 実践 ICONIXプロセス : シーケンス図とクラス図 | main | 実践 ICONIXプロセス : 静と動、要求と実装 >>

実践 ICONIXプロセス : 問題空間から解決空間へ

ICONIXプロセスでは、ロバストネス分析(予備設計)までは、問題空間( Problem Space )だけに集中します。解決空間( Solution Space ) つまり実装は、詳細設計(シーケンス図作成)から始まります。

問題領域(ドメイン)は、ドメインモデル(概念クラス)とユースケースモデルで記述します。
ICONIXプロセスでは、ドメインモデルは、詳細クラス図に発展し、そのままコードになります。
ユースケースモデルは、ロバストネス分析を経て、シーケンス図になり、実装設計に反映します。

インフラの足場クラスの登場

解決空間には、さまざまな実装用のオブジェクトが登場します。永続化メカニズムの実装、Web アプリケーションの MVC の実装などのオブジェクトですね。採用したフレームワークと、アプリケーションアーキテクチャパターンによって、大半のオブジェクトは決まります。

多重度

ICONIXプロセスでは集約の多重度は、ようやくこの段階で登場します。
ようするに、Book book ; で実装するのか、 List<Book> books ; で実装するのか決めなければいけないので、この時点では、多重度は重要になる。

ここまでは、多重度はそれほど重要でないし、クラス図に描くべきではない、というのがICONIXプロセスの主張。
データモデルでは、多重度の明示と検証は重要だが、クラス図では、オプションである。 Java で実装するときに、検討・決定すれば、十分、ということのようです。

まじめな(?)モデル論から見れば、かなり乱暴なやり方ですが、実践的には、この程度の位置づけで十分な気もします。

書籍一覧と実装

概念クラスが実装では消える(!)ことがあります。典型的なのが書籍一覧( BookList ) が実装クラスでは、List になって、独立したクラスではなくなるパターンです。

「ユースケース駆動開発実践ガイド」では、シーケンス図作成の過程で、永続化メカニズムの BookDao オブジェクトを導入し、List<Book> getBookListByCategory( int categoryID ) メソッドを割り当てた段階で、BookList は、消えるといっていますね。
図から消すだけなのか、モデルから削除すべきことを言っているのか、意図は不明です。

概念モデルで発見したクラスを、実装方法の決定時に削除というのは、おかしいので、詳細クラス図からは消して、概念モデル図には残す、というのが良いように思う。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
   1234
567891011
12131415161718
19202122232425
2627282930  
<< November 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM