UMLのポテンシャルを探る：FTP Online（3/5 ページ）

効率的なJavaアプリケーション開発には、設計時にUMLを利用することが不可欠となっている。さまざまなモデル例を挙げ、UMLの使い方とその効果を解説しよう（日本語訳：澤田侑尚）。

[Craig Larman，FTPOnline]

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

システムオペレーションコントラクト

　通常、開発者のテキストユースケースおよびドメインに関する知識は、機能本位な要件における詳細を理解するに充分なものとなるが、そうではない場合もある。例として、航空券予約システムの操作であるmakeReservation（...）に関して考えてみよう。それは（あなたが航空会社の技術者でない限り）あなたが考えるよりも複雑で、行うべきことや行うべき情報のアップデートは多岐に渡るものだ。

　このアクションの流れを強調するユースケースは、適切な粒度で詳細を記録するには最も不適切なものである。このようなケースにおいて、システムオペレーションコントラクトはもうひとつの可能性を持ったオブジェクト指向アーキテクチャの加工物である。システム操作の呼び出しは、システム全体としての入力イベントであり、エアーラインドメインのmakeReservation（...）、もしくはPOSドメインのenterItem（...）やmakePayment（...）のようなものとなる。これらのシステム操作は、図2のSSDにおいて明確に図示され、またユースケーステキストの中に含蓄される。

　システムオペレーションコントラクトは、事前条件と事後条件の形式の中において、ドメインモデル内で記述されたオブジェクトに対する変更の観点から、操作の効果を記録する（参照、Operation Contracts）。コントラクトにおける事後条件は、生成中のインスタンスおよびフォーマット中のアソシエーション、変更中の属性などに対して制限される点に注意する。言い換えれば、事後条件はドメインモデル内でのオブジェクト、およびその関連性に対する変更に限定される。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

オペレーションコントラクト

　makeNewSale（...）とenterItem（...）に対するオペレーションコントラクトの2つの例において注釈する、重要なセクションは事後条件である。それは、ドメインモデルに記述されるオブジェクト、およびアソシエーション、アトリビュートを参照する（図4）。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　重要なのは、これらの事後条件がソフトウェアの振る舞いを参照せず、変更における概念の展望を作っていることだ。例として、事後条件である「A SalesLineItem instance sli was created」は、Javaインスタンスの生成やデータベースレコードの挿入を意味するのではなく、現実の世界でSalesLineItemインスタンスが、何らかの方法で生成されたことを抽象的に意味する。それは従業員の記憶に、また帳簿への記述により作り上げられる（100年前は、この帳簿は"sales register"と呼ばれていた）。しかし、われわれが注視すべき後世のデザインでは、これらの事後条件はソフトウェア用語として具体化される。

　ユニファイドプロセスにおけるシステムオペレーションコントラクトは、ユースケースモデルの一部として考えることができる。それらが（テキスト成果物としての）UMLに表現されないにも関わらず、UML記述のドメインモデルを参照し、デザインモデルに対する入力となり、そしてUMLでビジュアライズされるにつれてわれわれのディスカッションにも関連することになる。ユースケーステキストで書かれるSSDは、オプションとして記述されるコントラクトの種類、そしてドメインモデルに対するシステムオペレーションを示す。また、事後条件の中で検討されるであろうオブジェクトを示すユースケーステキストによって影響を受ける。