UMLのポテンシャルを探るFTP Online(4/5 ページ)

» 2004年06月25日 15時30分 公開
[Craig Larman,FTPOnline]

デザイン:ダイナミックモデリング

 デザインモデルは、ソフトウェアのダイナミックな挙動とスタティックなクラス定義という、動的な要素と静的な要素で構成される。ソフトウェアオブジェクトモデリングにおいて最もありがちな誤解は、動的なインタラクションダイアグラムよりも、静的なクラスダイアグラムを強調してしまうことである。しかし、ほかのオブジェクトであるObject Fooがタスクを埋め尽くすためにインタラクトすべきことは何であり、割り当てとコラボレーションの責任においてメッセージは具体的にどうあるべきか? という詳細な疑問を一生懸命考え抜く間に、オブジェクト設計における創造的な部分は調査される。スタティックなクラスダイアグラムを描くだけでは、特にメソッドの詳細などの、オブジェクトデザインにおいて回答が得られず、調査ができない詳細部分が置き忘れられる。

 ダイナミックなオブジェクトデザインの出発点は、SSDの中で可視化され、enterItem(...)などのオペレーションコントラクト中で可能な限り推敲されるシステムオペレーションにある(参照、オペレーションコントラクツ)。これらのオペレーションは、最初にUI階層でキャプチャされ、続いてソフトウェアシステムのアプリケーションロジック、およびドメイン階層に受け渡される。Webベースのアプリケーションにおいて、Struts Web-UI階層のアクションオブジェクトは、サーバ上で稼動中のドメイン階層にリクエストを受け渡す。

 システムオペレーションを操作するオブジェクトインタラクションの、デザインにおける多くの詳細部分は、ホワイトボード上にスケッチされるUMLのインタラクションダイアグラム内で調査することが可能だ。UMLは、シーケンスとコミュニケーションの2つのインタラクションダイアグラム表現を提供する(UML 2.0以前はコラボレーションダイアグラムと呼ばれていた)。コミュニケーションダイアグラム表現は、ダイアグラム上の2Dスペース内でインスタンスボックスの自由な配置を許すフォーマットを使用する。シーケンスダイアグラム表現は、その右側に配置され、それぞれのインスタンスに対してフェンスのようなレイアウトを使用する(図5)。

図5:シーケンスとコミュニケーション UML 2.0以前は、コラボレーションダイアグラムと呼ばれていたコミュニケーションダイアグラム表現(左側)は、ダイアグラムの2Dスペース上へのインスタンスボックスの自由な配置を許すフォーマットを使用する。シーケンスダイアグラム表現(右側)は、それぞれのインスタンスがフェンスのようなレイアウトを使用する(クリックで拡大します)

 どちらが良いのだろうか? もちろん正解はないが、より多くのオブジェクトを押し込めるというスペース面の効果により、ホワイトボード(もしくは本や雑誌)でスケッチする時、私と周囲の人々はコミュニケーションダイアグラムを好む。加えて、線の消去やスケッチの変更は、コミュニケーションダイアグラムの方が簡単だ。一方、シーケンスダイアグラムはメッセージの順序を簡単に表示し、ドキュメントを美しく仕上げることができる。それらは、いくつかのUMLケースツールを用い、コードから自動生成される。

 それは各種のイベントにおいて、レスポンシビリティのアサイメントと、デザインパターンにおけるアプリケーションに関する考慮が可能な、インタラクションダイアグラムのスケッチでのことである。図6は、enterItem(...)オペレーションのシンプルなインタラクションダイアグラムを示す。それがオペレーションコントラクトの事後条件を埋めることに注意してほしい。ひとつのボックスがひとつのインスタンスを表現し、積み重ねられたボックスは、Java Listやマップオブジェクトなどのコレクションを表現する。インスタンスに送られるメッセージ作成は、コンストラクタコールと組み合わされるJavaの新しいオペレータの呼び出しを暗に示している。

図6:期待通りに enterItem(...)オペレーションのシンプルなインタラクションダイアグラムは、オペレーションコントラクトの事後条件を埋める。ひとつのボックスがひとつのインスタンスを表現し、積み重ねられたボックスは、Java Listやマップオブジェクトなどのコレクションを表現する。インスタンスに送られるメッセージ作成は、コンストラクタコールと組み合わされるJavaの新しいオペレータの呼び出しを暗に示す(クリックで拡大します)

アジリティを備えた静的なデザイン

 ソフトウェアオブジェクトデザインの静的サイドを図示するために、クラスダイアグラムはUMLの中で使用される。対照的に、それらのドメインモデルでの使用においては、概念的なオブジェクトというよりもソフトウェアオブジェクトのビジュアライズに、デザインモデルのクラスダイアグラムが使用される。アジャイルなモデリングは、モデルと加工物の作成におけるプラクティスを並列に促すが、別個のホワイトボード上でのインタラクションとクラスダイアグラムの並列スケッチを私も推奨する。われわれは、インタラクションダイアグラムを5分間で理解でき、続いて、関連するクラスダイアグラムを含む処理を容易に行える。その後、成長するインタラクションダイアグラムに対応し、それを埋め込んでいく。双方のダイアグラムにおける創造的な調査と議論は相互に補完する。

 図7は、ソフトウェアオブジェクトのドメイン階層において補完的にデザインされたクラスダイアグラムを示し、図6で示されるインタラクションダイアグラムに関連する(参照 Resources:ここで紹介されるいくつかの書籍は、GRASPパターンおよびアドバンスドオブジェクトデザイン、そしてオブジェクトデザインとオブジェクトモデルの基礎を対象とした効果的な学習で取り上げられる、オブジェクトデザインとその責任の割当てにおける基本原則をカバーしている)。UPにおいて、これらのインタラクションとクラスダイアグラムはデザインモデルの一部分である。ユースケース本文に記載される機能本位の要件と、補足の仕様における非機能本位な要件は、オブジェクトデザインに対するメインの入力である。

図7:Interaction Match ソフトウェアオブジェクトのドメイン階層において補完的にデザインされたクラスダイアグラムは、図6で示されるインタラクションダイアグラムに関連する(クリックで拡大します)

 オプションとしてオペレーションコントラクトは、より詳細なインプットを提供できる。このドメインモデルは、低位表現ギャップにおけるオブジェクト指向の原則的な利点を用いることで、デザインにおけるオプション的な入力となり得る。それは、(ドメインモデルで図示される)ドメインの語彙から喚起される名称と情報を用い、SaleやCachPaymentのようなソフトウェアクラスを作成することである。アプリケーションのドメイン階層におけるオブジェクトのソフトウェアデザインを、ドメインにおけるわれわれの概念的なモデルと等しくするために行うことであり、具体的には、現実世界のドメインモデルにおけるSaleと、JavaにおけるSaleのようなものである。ソフトウェアとドメインの間における表現のギャップを縮めることで、いくつかのアドバンテージのひとつとして理解性を改善する。図8は、起り得る影響関係と、起り得る作成順序を示したものだ。

図8:Influential Relationships, Take Two 影響を及ぼす関係およびユースケースモデルの加工物の関係で起り得る作成順位を示す。この表現におけるドメインモデルは、低位表現ギャップでのオブジェクト指向の原則的な利点を用いることで、デザインにおける入力となり得る。われわれはドメインの語彙から喚起される名前と情報を用いてソフトウェアクラスを作成するが、それはアプリケーションのドメイン階層におけるオブジェクトのソフトウェアデザインと、ドメインにおける概念的なモデルを等しくするためである(クリックで拡大します)

 ここでの紹介は、UMLに関連するいくつかのカギとなるオブジェクトデザイン要素に言及しているが、その他の関連性も存在する。例として、UMLパッケージダイアグラムは、モデルおよび論理的なパッケージ構造のビジュアライズのために利用可能で、もちろんJavaパッケージを用いたインプリメンテーションに反映することもできる。これらも、デザインモデルの一部である。

 またUMLクラスダイアグラムは、データモデルに対する特殊なUMLプロファイルを使うことであり、データモデルスキーマを図示するために使用できる。UMLディプロイメントダイアグラムは、異種オペレーティングシステムでのシステム処理において、また、Javaプロセス上やネットワーク接続された別のコンピュータノード上で、コンポーネントの物理的なディプロイメントを行うモデルに対して使用できる。これらは、ユニファイドプロセスディプロイメントモデルの一部であり、構成的なビューのセットの中でUMLを用いることにより、アーキテクチャ全体をビジュアルに概説することが可能だ。それは、アーキテクチャにおいて、よく知られているN+1ビューモデルをベースにする(参照、関連リンク)。

© Copyright 2001-2005 Fawcette Technical Publications

注目のテーマ