Javaモデリング: UMLワークブック: 第2回

シーケンス・ダイアグラムの条件付きロジック

Granvilleが、引き続きUnified Modeling Languageとシーケンス・ダイアグラムについて説明します。ここでは、シーケンス・ダイアグラムにおける条件付きロジックの役割を吟味し、条件とループをダイアグラムに組み込んだり、ダイアグラムから除外したりできるようになっている理由について検討します。また、「汎用」と「インスタンス」という2つの形式のシーケンス・ダイアグラムと、開発サイクルにおけるそれぞれのアプリケーションについても説明します。

Granville Miller (rmiller@togethersoft.com), Mentor, TogetherSoft

Granvilleは、オブジェクト指向コミュニティーで13年間の経験を積んでいます。彼は Advanced Use Case Modeling シリーズの共著者であり、世界各地で開催されるさまざまなオブジェクト指向テクノロジーのコンファレンスでチュートリアルを提供しています。オブジェクト指向開発に関する彼の実践的なアプローチは、設立まもない企業から確固とした地位を築いているソフトウェアの巨人たちまで、さまざまな企業で仕事をした経験に基づくものです。
現在は、アジャイル・プロセス、方法論、およびJavaテクノロジーに関するセミナー、チュートリアル、および講習で教えるほか、積極的なプロジェクトの推進を指導および支援しています。Granvilleの連絡先は rmiller@togethersoft.com です。



2001年 6月 01日

前回の記事で述べたように、シーケンス・ダイアグラムはシステムの内部の振る舞いを時系列的に描くためのものです。システムの振る舞いは、いくつかのオブジェクトが互いにメッセージのやり取りをした結果生じるものであるため、シーケンス・ダイアグラムは、それらのメッセージがオブジェクト間を移動した軌跡を作図します。最終的には、シーケンス・ダイアグラムは対話のマップになります。前回の記事で作成したマップは比較的シンプルなものでしたが、多くの対話を描きました。今回はもう少し深く掘り下げ、UMLによって指定される2つの形式のシーケンス・ダイアグラムを調べてみようと思います。その2つの形式とは、汎用 とインスタンス です。まず、それぞれの形式に適合したアプリケーションについて考えてみます。

2つのタイプのシーケンス・ダイアグラム

シーケンス・ダイアグラムは、オブジェクト間で行われる2つの異なるタイプの対話を描くために使用されます。1つのタイプの対話はmust 対話です。この対話では、オブジェクトAが特定のメッセージを オブジェクトBに送信しなければなりません。もう1つのタイプの対話はmay 対話です。この対話では、オブジェクトAが特定のメッセージをオブジェクトBに送信することができます (ただし、送信しなくてもかまいません)。2つの形式のシーケンス・ダイアグラムが、これらの2つの異なるタイプの対話を描きます。汎用形式はmust 対話を描き、インスタンス形式はmay 対話を描きます。

汎用形式のシーケンス・ダイアグラムは、初期刺激の結果としてのクラス間の対話を記述します。汎用形式は、初期刺激の結果として行われる可能性があるすべての対話を文書化します。成功条件も失敗条件も、ループ、条件、ブランチなどと同様、このタイプのダイアグラムの一部です。

図1に示されているとおり、汎用シーケンス・ダイアグラムでは、横軸に沿った各ボックスにクラス名しか入っていません。この考え方は、対話の背後にあるオブジェクトが匿名で、そのクラスのすべてのオブジェクトがこの対話に参加できるということを示しています。したがって、すべてのパスを明示的にモデル化しなければなりません。汎用シーケンス・ダイアグラムの場合、オブジェクトAはこのモデル内のいずれかのメッセージをオブジェクトBに送信しなければなりません。

図1. 汎用シーケンス・ダイアグラム
図1

2番目の形式のシーケンス・ダイアグラムはインスタンス形式です。インスタンス・シーケンス・ダイアグラムは、2つのインスタンス間で行われる単一のメッセージ交換を記述します。図2に示されているとおり、このダイアグラムでは、横軸に沿ったボックス内に変数の名前とそのクラス・タイプが入っています。この形式には、汎用形式のときのようなループ、状態、またはブランチは含まれていません。システム内の実際の制御フローでは、対話中に満たすべき表明(assertion)が「偽」になっていることがあります。表明が「偽」になっている場合は、インスタンス・シーケンス・ダイアグラム内のすべてのメッセージが無効になり、そのシナリオは実行されなくなります。インスタンス・シーケンス・ダイアグラムは単一のシナリオを記述しますが、このシナリオが実行されるかどうかは分かりません。

図2. インスタンス・シーケンス・ダイアグラム
図2

ソフトウェア開発ライフ・サイクルの分析フェーズで個々のシナリオをモデル化する場合は、インスタンス・シーケンス・ダイアグラムを使用するのが最適です。汎用シーケンス・ダイアグラムは、複数のシナリオからなる1つのユース・ケース全体をモデル化することができます。他のタイプの活動、たとえば、サブシステム間またはフレームワーク間、あるいはその両者間で使用されるプロトコルのモデル化では、コンポーネントがソフトウェア開発ライフ・サイクルのどのフェーズにあるかによって、どちらかの形式を使用することができます。汎用形式は、インスタンス形式に比べ、最終製品に組み込まれる実際のコードに近いものになります。

前回の記事では汎用形式を取り上げましたが、今回の記事でも引き続き汎用形式について検討します。今回は、汎用シーケンス・ダイアグラムにおける条件付きロジックの役割を検討し、読者のUML表記に関する知識をより広くします。


シーケンス・ダイアグラムにおける条件付きロジック

汎用シーケンス・ダイアグラムは条件付きロジックを利用します。条件付きロジックは、対話時に行われるイベントの代替フローを記述する場合に役立つことがあります。ユーザーは、ソフトウェア開発ライフ・サイクルのどのフェーズにいるかに応じて、ダイアグラムをどのような細かさにするかを決めます。分析では、詳細部分を条件式に含めなくても十分であると思えるかもしれませんし、設計では、最終製品で使用されるコードの断片を含むようなところまですることもあるでしょう。

ユーザーが開発サイクルのどのフェーズにいるかには関係なく、シーケンス・ダイアグラムとJava言語のようなオブジェクト指向言語の間の自然な対応関係は、条件式をダイアグラムに組み込む段階になると明確になります。たとえば、テラーの預金受け入れを可能にするバンキング・アプリケーションを考えてみます。この場合、指定されているのは、テラーが負数を口座に記入するのをシステム側で防止しなければならないということです。これを許せば、口座から差引かれてしまいます。したがってシステムは、キー入力されるすべての金額が正の値であることを確認するためのメカニズムを備えていなければなりません。リスト1は、預金が正の値であることを確認する条件式を示しています。

リスト1. 条件式を持つメソッド
\** This is a method in a Teller class **\
public void receiveDeposit(Account account, BigDecimal deposit)
throws ImproperDepositException {
       // Check to ensure the deposit is positive
if (deposit.compareTo(new 
BigDecimal(0.0)) > 0) {
              account.credit(deposit);
       }
       else {
              throw new ImproperDepositException();
       }
}

分析ステージでは詳細部分にあまりこだわりませんから、ダイアグラムは、預金が正の値であることを知らせるだけで十分です。汎用シーケンス・ダイアグラムでは、水平呼び出し矢印の上にメッセージ名が付いたガードとして条件が示されます。図3に示されているとおり、これらのガード条件は、メッセージ名の左側に大括弧で囲まれています。

図3. 分析時に追加された条件
図3

上記メソッドとシーケンス・ダイアグラムの間の関係は、図4でさらに明確になります。つまり、ダイアグラムは、設計フェーズで使用できるようなより明示的な内容になります。確かにメソッド全体は示されておらず、ELSE節が欠落しています。しかしこのダイアグラムでは、メッセージ矢印のセマンティクスは、条件が有効な場合にのみメッセージを送信することを指示しています。

図4. より明示的な条件
図4

ELSE節のモデル化は、Teller クラスとImproperDepositException の間に別の呼び出し矢印を追加することによって行われます。この呼び出しでは、if条件の逆の条件 (この場合は、入金額がゼロ以下になる) になります。おそらく読者は、自分でこれをモデル化してみたいと思うでしょう。


for ループのダイアグラム

上の例に示されているとおり、汎用シーケンス・ダイアグラム (および、実際上、すべてのUMLダイアグラム) は、Java言語の構文を綿密にマップします。その結果、ほとんどのJavaデベロッパーは、これらのダイアグラムを直観的に理解して、すぐにそれらを使用できるようになります。汎用シーケンス・ダイアグラムとJava言語間の対応をさらに詳しく調べるために、リスト2に示されているようなfor ループをダイアグラム化します。

リスト2.for ループ
for ( int i =0; i < 4; i++) {
        squareRoom.examineCorner(i);
}

シーケンス・ダイアグラムでは、反復は、水平矢印上のメッセージ名の前にアスタリスク (*) で示されています。反復の回数が分かっていて、それが固定されている場合 (めったにありませんが) は、その回数がアスタリスクの後に大括弧で示されます。ほとんどのfor ループは、反復回数を事前に決定できないような複雑なロジックを扱いますので、この形式の大括弧表記はあまり使用されません。上記のfor ループのシーケンス・ダイアグラムを 図5に示します。

図5. forループのシーケンス・ダイアグラム
図5

while ループのダイアグラム

while ループは、ループと条件とを結び付けるので、今回の締めくりとして取り上げるのに最適の例です。リスト3に示されたwhile ループのダイアグラムを作成しましょう。

リスト3. whileループ
while ( value.notFound() ) {
        value = database.search( key );
}

このwhile ループのダイアグラムには、条件も反復を示すアスタリスクも含まれていますが、見て分かるとおり、反復回数は示されていません。while ループに反復回数が組み込まれることはめったにありません。ただし、それが見せかけの 実はfor ループである場合は別ですが。while ループのダイアグラムを図6に示します。

図6.while ループのシーケンス・ダイアグラム
図6

結論

must およびmay 振る舞いは、UMLおよびソフトウェア開発全般の基本的な概念です。ユース・ケースはmust 振る舞いを把握し、シナリオはmay 振る舞いを把握します。クラス・ダイアグラムはmust 振る舞いを把握し、インスタンス・ダイアグラムはmay 振る舞いを把握します。わたしがこの概念に焦点を当てたのは、多くの人がシーケンス・ダイアグラムの究極的な柔軟性を理解できないでおり、そのためにこの形式についての認識とその使用の仕方が二極化していることが分かったからです。

これらの記事を読むときは、モデルのセマンティクスについての直観的な理解力を高めることに集中してください。読者がこれからもっと多くのシーケンス・ダイアグラムを見たり、自分で作成したりするにつれて、多くのシーケンス・ダイアグラムが、システムのmust ビューまたはmay ビューのどちらを提示するかを示すために、条件付きロジックとダイアグラム・コンテキストを主要な手段としていることが分かるでしょう。この特質を早くに認識し、利用できるようにしておくと、将来、ますます複雑化するダイアグラム技法へ移行していくときに役立ちます。

シーケンス・ダイアグラムにおけるmust 振る舞いおよびmay 振る舞いの重要性の検討に加え、ダイアグラムにおける条件と反復の表示方法についての検討も行いました。for およびwhile ループをダイアグラムに組み込む方法が理解できたところで、do-while ループなどの他のJavaの構成要素に関するモデル化表記の練習へ移りましょう。自分でシンプルな構成のダイアグラム化を練習していけば、シーケンス・ダイアグラム作成についての理解も当然深まります。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Java technology
ArticleID=227610
ArticleTitle=Javaモデリング: UMLワークブック: 第2回
publish-date=06012001