UMLシーケンス・ダイアグラムの概要

ユース・ケース・ロジックのモデリング

ここにご紹介するシーケンス・ダイアグラム用Unified Modeling Language (UML) の表記は、The Object Primer 2nd Edition の第6章から引用したものです。

Scott W. Ambler, Practice Leader, Agile Development, Rational Methods Group, IBM

Scott W. Amblerは、オブジェクト指向ソフトウェア処理の指導、アーキテクチャー・モデリング、およびEnterprise JavaBeans (EJB) 開発を専門とするコンサルタント会社である、Ronin International の社長です。彼は、オブジェクト指向開発に関する本を執筆あるいは共同執筆しています。最近刊行されたものとしては、この記事で要約された主題を詳しく論じた The Object Primer 2nd Edition などがあります。彼の連絡先はwww.ambysoft.com にあるサイトです。



2001年 4月

シーケンス・ダイアグラムは、ユーセッジ・シナリオのロジックをモデル化するために用いられます。ユーセッジ・シナリオは、その名前が示すとおり、ユーザーがシステムを使用する潜在的な方法を記述したものです。 ユーセッジ・シナリオのロジックは、ユース・ケースの一部である場合も、条件分岐の場合もあります。 また、ユーセッジ・シナリオは、ユース・ケースを通る1つの経路全体を指すこともあります。たとえば、基本的な処理の流れによって記述されるロジック、または基本的な処理の流れの一部によって記述されるロジック、さらに1つ以上の条件分岐などがその例です。 ユーセッジ・シナリオのロジックは、複数のユース・ケースに格納されるロジックを通る経路の場合もあります。 たとえば、学生が大学へ入学し、ただちに3つのセミナーに登録したとします。 シーケンス・ダイアグラムは、ユーザーのシステムを使ってロジックの流れを、目に見える形にモデル化するので、ユーザーはロジックの文書化と検証を同時に行うことができ、分析と設計の両方の目的に使えるようになります。 

図1 では、「セミナーへの登録」のユース・ケース に対する基本的な処理の流れをモデル化しています。 本稿を読みながら、今ここで図を開き、参照して見るのもよいでしょう。 

分類子

ダイアグラムの上部にある四角い箱は、分類子またはそのインスタンスを表します。通常は、ユース・ケース、オブジェクト、クラスまたはアクターです (これらも、通常四角で描かれますが、シンボルでも構いません)。 

ユーザーは、オブジェクトとクラスの両方にメッセージを送ることができるので (オブジェクトは、オペレーションの起動を通してメッセージに応答し、クラスは静的オペレーションの起動を通してメッセージに応答します)、シーケンス・ダイアグラム上にオブジェクトとクラスを含めることは、道理にかなっています。 アクターは、ユーセッジ・シナリオを始動し、ユーセッジ・シナリオのアクティブな部分を受け持つので、これらもシーケンス・ダイアグラムに含められます。 オブジェクトは、標準のUML形式では 「name: ClassName」のラベルを持ちます。ここで 「name」はオプションです。 (ダイアグラムで名前を与えられていないオブジェクトは、無名オブジェクトと呼ばれます。)クラスは、「ClassName,」というフォーマットのラベルを持ち、アクターは 「ActorName」というフォーマットの名前を持ちます。(両方とも、UMLの標準フォーマットです)。 

たとえば、図1では、「Student」アクターが「A Student」という名前を持ち <<actor>> というステレオ・タイプを持つラベルであることが分かります。 「UI32セミナー選択画面 (Seminar SelectionScreen) 」を示す主なUI要素のインスタンスは、「:SeminarSelector」 という名前を持ち<<UI>> というステレオ・タイプを持つ無名オブジェクトです。静的メッセージ「isEligible(name, studentNumber)」 が 「Student」クラスに送信されるので、「Student」クラスがダイアグラム上に示されています (「Student」 という名前の四角) 。 これについては、後に詳述します。

ダイアグラム上では、「Student」のインスタンスは、メッセージ内のパラメーターとして複数の場所で使用されるので 「theStudent」と名付けられています。 これとは対照的に「StudentsFees」クラスのインスタンスは、ダイアグラムの他の場所では参照されないため、無名で構いません。 


ライフ・ライン

四角から下に伸びる破線は、オブジェクト・ライフ・ラインと呼ばれ、シナリオがモデル化されているあいだのオブジェクトの生存期間を示します。 ライフ・ライン上の細長い四角は、メソッド起動ボックスです。これは、メッセージを満たすためにターゲット・オブジェクト/クラスにより処理が実行されていることを示します。 メソッド起動ボックスの下にあるXは、オブジェクトがメモリーから取り除かれたことを示すUMLの規則です。これは通常、<<destroy>> のステレオ・タイプを持つメッセージを受け取った結果です。 


モデリング・メッセージ (Modeling messages)

メッセージは、ラベルの付いた矢印で表されます。 メッセージ送信元および送信先が、オブジェクトまたはクラスの場合、ラベルはメッセージの応答内で起動されたメソッドのシグニチャーです。 しかし、送信元、送信先のいずれかが人間のアクターであると、メッセージには、通知される情報が記述された簡単なテキストからなるラベルが付きます。 たとえば、「:EnrollInSeminar」オブジェクトは、「isEligibleToEnroll(theStudent)」メッセージを 「Seminar.」のインスタンスに送ります。 渡すべきメソッド名と、(もしあれば) パラメーター名の両方を含めた私の方法に注意してください。

また、図1では、「Student」アクターが、「name」および 「student number」というラベルの付いた メッセージを通して 「:SecurityLogon」オブジェクトへ情報を提供することを示しています。 (これらは、実際にはメッセージではなく、ユーザーの対話です)。 戻り値は、戻り値を示すラベルのある破線付き矢印で示しています。これはオプションです。 たとえば、メッセージ起動の結果として、戻り値「theStudent」が、「Student」クラスから戻る際に示されます。それに対して、「isEligibleToEnroll(theStudent)」 メッセージを 「seminar.」に送った結果の戻り値は示されません。何が戻るのかが明らかな場合には、戻り値を示さないのが私の書き方なので、シーケンス・ダイアグラムは乱雑にならずに済みます。 (お分かりのように、シーケンス・ダイアグラムは、すぐに込み入ってしまいます。) 

ダイアグラムは左側から下方へ要約され、メッセージが、ユース・ケースの段階のロジックを満たしました。 ユース・ケースのステップでは、あまり正確な文言を使用しません。ダイアグラム上の文章が長くなりすぎて読み難くなるからです。 ステップ番号が、ユース・ケースのステップ番号と一致することと、ステップの全般的な考えが読む人に分かりやすく書くことが肝心です。

図1では、以下に挙げる「セミナーへの登録」ユース・ケースにおける基本的な処理の流れのUMLシーケンス・ダイアグラムを示しています。


「セミナーへの登録」ユース・ケース

名前 : セミナーへの登録
識別子 : UC 17
説明 : 受講資格のある在学生をセミナーに登録する。
事前の状態 : 学生は大学に登録されている 。
事後の状態 : 学生に受講資格があり、また定員に余裕がある場合には、希望するコースに登録できる。
拡張: 該当せす
包含: 該当せず
継承元 : 該当せず

基本的な処理の流れ:

  1. 学生が、あるセミナーへの登録を希望している。
  2. 学生は、「UI23セキュリティー・ログイン画面」を使用して氏名と学生番号をシステムに入力する。
  3. システムは、業務処理規則「BR129登録資格を判別する」に従って、その学生が大学のセミナーに登録する資格があるかを検証する。
  4. システムは、「UI32セミナー選択画面」を表示する。この画面には、選択可能なセミナーのリストが表示される。
  5. 学生は、登録したいセミナーを示す。
  6. システムは、業務処理規則「BR130学生のセミナー登録資格を判別する」に従い、その学生がそのセミナーに登録する資格があることを検証する。
  7. システムは、業務処理規則「BR143学生のセミナー・スケジュールを検証する」に従って、そのセミナーがその学生の既存のスケジュールに合うことを検証する。
  8. システムは、講座案内に記載された受講料、学生に適用される受講料、および適用される税金に基づきセミナーの受講料を計算する。 業務処理規則「BR 180受講料を計算する」および「BR45セミナーの税金を計算する」を適用する。
  9. システムは、「UI33セミナー受講料画面」で受講料を表示する。
  10. システムは学生に対し、そのセミナーに登録したいかどうか尋ねる。
  11. 学生はそのセミナーに登録したいことを示す。
  12. システムは、その学生をそのセミナーに登録する。
  13. システムは、「UI88セミナー登録要約画面」を介して登録が正常に行われたことを学生に通知する。
  14. システムは、業務処理規則「BR100学生にセミナー受講料を請求する」に従い、学生にセミナー受講料を請求する。
  15. システムは、その学生に登録内容の印刷文書を希望するかどうか尋ねる。
  16. 学生は、印刷文書を希望することを示す。
  17. システムは、登録文書「UI89登録要約レポート」を印刷する。
  18. 学生が印刷された登録文書を受け取ると、ユース・ケースが終了する。

条件分岐的な流れA : 学生がセミナーに登録する資格を持たない。

  1. システムは、その学生がセミナーに登録する資格がないことを判別する。
  2. システムは、その学生に登録する資格がないことを通知する。
  3. ユース・ケースが終了する。

条件分岐の流れB : 学生が前提受講条件を満たしていない。

  1. システムは、その学生が選択したセミナーへ登録する前提受講条件を持っていないことを判別する。
  2. システムは、その学生には前提受講条件がないことを通知する。
  3. システムは、その学生に必要となる前提受講条件を通知する。
  4. ユース・ケースは、基本的な処理の流れのステップ4へと続く。

条件分岐の流れC : 学生は、選択可能なセミナーに登録しないと決める。

  1. 学生はセミナーのリストを閲覧するが、登録したいセミナーについては見ない。
  2. ユース・ケースが終了する。

参考文献

コメント

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=SOA and web services
ArticleID=245151
ArticleTitle=UMLシーケンス・ダイアグラムの概要
publish-date=042001