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

シーケンス・ダイアグラムへの招待

Granville Millerは、彼の新規コラムの第1回目となるこの記事で、Unified Modeling Languageの構成要素の1つであるシーケンス・ダイアグラミングを紹介しています。シーケンス・ダイアグラムは、システムの実行中にアクターとオブジェクトの間で行われる内部対話を示すために、設計プロセスの全体にわたって使用されます。Granvilleは、例としてローン処理アプリケーションを使用してこれらのダイアグラムを作成しています。一緒に試してみてください。

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

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



2001年 5月 01日

Unified Modeling Language (UML) はオブジェクト指向システムをモデリングするための標準表記です。UMLは1995年から1997にかけて段階的にオブジェクト指向プログラミング・コミュニティーに紹介され、1997年の後期にObject Management Group (OMG) によって承認されました。最初は議論の的になりましたが (紹介当初は異議や反対提案がにわか雨のように降り注ぎました)、UMLはやがてシステム表記の業界標準となりました。UMLは現在バージョン1.4になっていて、オブジェクト指向開発者の必要を満たすために進化し続けています。(UMLの詳しい歴史については、参考文献を参照してください。)

UMLは、複雑で学習しにくいかもしれません。これは主として、UMLが非常に多くの状況に対応するモデリング表記を提供しようとしているためです。それぞれのモデリング表記はダイアグラム形式になっていて、現在、9つのダイアグラムがUML仕様に含まれています。幸いなことに、UMLは段階的に学習することができます。一度に1つのダイアグラムだけを学習すればよく、初めから複雑なダイアグラムを完全に受け入れようとする必要はありません。

このコラムでは、Javaベースのアプリケーション開発のためのUMLの設計と表記について、少しずつ説明していきます。UMLフレームワークおよびその他のモデリング・テクノロジーの要点を論理的に (また、願わくば楽しく) 紹介したいと思います。そして、実世界のモデリングの例を実際に使用して学習していただきます。この第1回目では、手始めに、ローン処理アプリケーションを例に使用して、シーケンス・ダイアグラムについて説明します。この記事では、読者がJava言語のことをよく理解していて、オブジェクト指向の開発方式および用語に関する基本知識を持っていることを前提とします。オブジェクト指向の概念については簡単に説明しますが、詳しい説明はこのコラムの対象には含まれません。

シーケンス・ダイアグラムについて

アクター・パーソナリティーについて

アクター・パーソナリティーは、ユース・ケース・シナリオに参加する可能性のあるアクターを発見および識別するために役立つことがあります。単一のアクターは、1つのユース・ケース内で、また複数のユース・ケースを通じて、複数のパーソナリティーを備えることができます。これまでのところ、UML仕様に対する拡張または定型として、イニシエーター、サーバー、レシーバー、ファシリテーターの、4種類の異なるアクター・パーソナリティーが 識別されています。アクター・パーソナリティーはシーケンス・ダイアグラムに反映される可能性があるため、それらの機能をよく理解しておく必要があります。

  • イニシエーター は、システムの特定の振る舞いを開始させる外部エンティティーです。イニシエーターは、サービスを要求したりイベントを生成したりすることができます。アクターが存在するシーケンス・ダイアグラムでは、イニシエーターはシーケンスを開始させます。
  • 外部サーバー・パーソナリティーは、他のアクターにサービスを提供します。サーバーは、外部から機能または情報を提供して、システムがその目標を達するのを支援します。オペレーティング・システムを含む多くの外部システムは、サーバー・パーソナリティーです。サーバーは、メッセージを受け取ることが多いですが、メッセージを生成することはおそらくありません。
  • レシーバー・パーソナリティーは、システムから情報を受け取ります。このパーソナリティーはサービスを提供することがありますが、このサービス提供は受動的に行われます。したがって、システムに対して価値を提供しなくても構いませんが、他のアクターに対しては価値を提供する必要があります。レシーバーの例として、データ・ウェアハウスや外部バックアップ・システムなどがあります。レシーバーは一般にシステム内のオブジェクトからメッセージを受け取りますが、通常はメッセージを生成しません。
  • ファシリテーターは、他のアクターのためにアクションを行うアクターです。ファシリテーターの例として、客のためにビデオを貸し出すレンタル・ビデオ店員などがあります。

UMLは特定のソフトウェア開発方式またはプロセスを禁止していません。単に、表記の形式を標準化しているだけです。しかし、実際には非常に多くの開発メソッドがUMLを組み込んでいます。このような方式として、Rational Unified Process (RUP)、および機能主導式の開発 (FDD) があります。UMLシーケンス・ダイアグラムは、その直感的な性質と多様性のために、これらのプロセスのフロントエンド・モデリング・アクティビティーにとって不可欠なものとなっています。シーケンス・ダイアグラムは、次のものをモデリングするために使用されます。

  • ユース・ケース・シナリオ
  • フレームワーク内のプロトコル
  • サブシステム
  • クラス
  • メソッド・ロジック

上のそれぞれの機能について、上記の順に従って簡単に説明します。

ユース・ケース・シナリオ

私たちが例として使用するアプリケーションでは、単一のユース・ケース・シナリオをモデリングするためにシーケンス・ダイアグラムを使用することにします。ユース・ケースは、指定された目的に向かってユーザーのアプリケーションと対話するアクターによって実行される、単一のタスクです。アクターは、ユーザーのアプリケーションと対話する (そのアプリケーションの外部にある) 任意のエンド・ユーザー、組織、またはシステムです。(4つのアクター・パーソナリティーについてはアクター・パーソナリティーについてを、また、ユース・ケース・シナリオの詳細については参考文献を参照してください。)

フレームワーク内のプロトコル

プロトコルは、フレームワークと、アンサンブル と呼ばれる交換可能なコンポーネントの間に位置します。フレームワークに要求される対話を理解することは、新規アンサンブルの開発に役立ちます。シーケンス・ダイアグラムは、多くの場合、これらの対話を文書化するために使用されます。

サブシステム

大規模なプロジェクトは、サブシステム と呼ばれる、より小さくて管理しやすい部分に分解されます。サブシステム間のインターフェースは、それらをより大きな全体構造、すなわちシステムに正しく統合するために不可欠です。これらのサブシステムの境界線にあるクラス間の対話を指定するためには、シーケンス・ダイアグラムが使用されます。

クラス

いくつかのクラス (SocketInetAddress など) は、適切な対話を行うために、メソッド呼び出しの複雑なシーケンスを必要とします。これらのシーケンスがいくつか集まって、こうしたクラスまたはクラスの集合と対話するためのプロトコルが形成されます。シーケンス・ダイアグラムを使用すると、クラスまたは対話を行うクラスのグループの使用法を記述することができ、したがって、対話のために必要なプロトコルを記述することができます。

メソッド・ロジック

シーケンス・ダイアグラムは、メソッド・ロジックを文書化するのに非常に適しています。事実、いくつかのCASEツールは、Javaメソッドが指定されると、自動的にシーケンス・ダイアグラムを生成します。シーケンス・ダイアグラムを使用すると将来のメソッドを設計したり、既存のメソッドの流れを文書化したりすることができます。

サンプル・アプリケーションについて

ローン処理アプリケーションの例を使用してシーケンス・ダイアグラムについて説明します。このコラムの焦点は、メソッドではなくモデリングですので、早速ダイアグラムの作成についての説明に移りたいと思います。したがって、アプリケーションの詳細については、あいまいなままにしておきます。ローン処理アプリケーションについてダイアグラムで扱う基本機能は、次のとおりです。

ユース・ケース: ローン要求の提出

  1. 申込者がローン申込書を完成させ、インターネットを介して銀行に提出します。
  2. システムはローン申込書に記載された情報を確認し、記載が正しく、またできるかぎり完全であるかどうかを検査します。
  3. システムは、申込者の信用報告を得るために外部の信用調査機関にローン要求を転送します。
  4. システムは、信用調査機関の報告書に基づいて申込者の信用評価を計算します。

はじめの一歩

シーケンス・ダイアグラムを作成するための第一歩は、そのダイアグラムで外部エンティティーとの対話を表現するのか、内部エンティティーとの対話を表現するのかを決定することです。ユース・ケース・シナリオをモデリングしようとする場合は、シーケンス・ダイアグラムは一般に外部エンティティーとの対話を表します。フレームワーク内のプロトコルをモデリングしようとする場合は、シーケンス・ダイアグラムは一般に、内部または外部のいずれかの対話を表現します。サブシステム、クラス、および個々のメソッド・ロジックのダイアグラムは、一般に内部エンティティーだけを表します。いずれの場合にも、モデリングしようとする対話のタイプにより、シーケンス・ダイアグラム内の最初の (そして最も左側の) 要素が決まります。

外部エンティティーとの対話は、あるアクターがその対話の一部であることを示します。内部対話は、(サブシステム・ユース・ケースがその対話の基礎になっている場合には) アクターによって開始されることもありますが、Sender と呼ばれる汎用クラスによって開始される場合のほうが多いはずです。アクターが対話を開始する場合、そのアクターは、4つの一般的なアクター・パーソナリティー (詳細については、アクター・パーソナリティーについてを参照) の1つである、イニシエーターのカテゴリーに当てはまります。

ここでは、ローン処理アプリケーションのための1つのシナリオ (上で概要を示したローン要求の提出 ユース・ケース) をダイアグラム化することに焦点を絞ります。申込者がオンライン・ローン申込書を完成してそれをインターネットで提出するときに、シーケンス・ダイアグラムに対して加えられる変更に注意してください。このシナリオでは、申込者はシステムの外部に存在し、したがって、アクターによって表されます。最初に、図1に示すように、このアクターApplicant をダイアグラムに追加します。

図1. 申込者の追加
図1

重要な項目の追加

対話のイニシエーターが配置された後で、次のステップとして、シナリオの進行とともにイニシエーターが対話する相手となるオブジェクトを追加します。これらのオブジェクトの名前は、クラスまたはインスタンスのいずれかの振る舞いを反映している必要があります。(クラスまたはインスタンスのいずれを選択するのかによって、シーケンス・チャートには別個の意味が与えられます。しかし、この2つの違いの説明は次回に取っておきます。)

このサンプル・シナリオでは、LoanApplicationLoanRequest の2つのクラスを追加します。ローン申込書 (loan application) は、ローンを申し込むときに必要です。これには、申込者と希望のローンに関する情報が含まれます。ローン要求 (loan request) は、ローン申込書を受け取った銀行が信用調査機関に送る書式です。これには、ローン申込者から得られた情報、および申込者の信用履歴に関する情報の要求が含まれます。シーケンス・ダイアグラムへのこれら2つのクラスの追加を、図2に示します。

図2. 2つの対話するクラスの追加
図2

点をつないで

シーケンス・ダイアグラムは、ほとんどのソフトウェア開発者にとって直感的に理解できます。これらのダイアグラムは、オブジェクトおよびアクター (横軸) を時間 (縦軸) にマップします。メッセージは、オブジェクトを結び付けます。これは、時間の経過とともにメッセージが発生し、あるオブジェクトから別のオブジェクトまで縦軸を下方に移動することによって行われます。これらのメッセージは、オブジェクトまたはアクターの下部の中央を起点とする、縦方向の破線に結合されています。この線はライフライン と呼ばれます。

横軸には、呼び出し矢印 またはメッセージ矢印 とも呼ばれる矢印でメッセージを表します。メッセージ矢印は送信側 (尾部) から受信側 (頭部) を指します。これらの矢印は、システムの動的振る舞いを捕らえるために使用されます。呼び出しは通常、左から開始されて右に向けて移動します。つまり、対話における最初の矢印は、通常は左から現れます。あるクラスの新規インスタンスを作成する場合は、ライフラインではなくそのクラス自体を指すように矢印を描きます。私たちのシナリオの最初のステップは新規ローン申込書を作成することですので、ApplicantLoanApplication の間に矢印を引きます。Javaで新規インスタンスを作成するためには、コンストラクターを呼び出す必要がありますので、コンストラクター名と、可能な場合にはその引数を使用して、この矢印にラベルを付けることができます。

まだソフトウェア開発ライフ・サイクルにおける分析段階ですので、できるだけ多くの分析情報を含める必要があります。私たちのビジネス・アナリストの1人は、私たちが新規ローン申込書の作成作業を「ローン申込書の完成」と呼んでいると述べています。作成中のシーケンス・ダイアグラムに忠実であり続けたいと望むのであれば、図3に示すように、LoanApplication コンストラクターを呼び出す共用静的メソッドとしてcomplete を実装することもできます。

図3. LoanApplicationの作成
図3

活動化のダイアグラム

あるメッセージがクラスまたはインスタンスによって受け取られると、受け取る側のオブジェクトのライフライン上にボックスが作成されます。このボックスは活動化 と呼ばれます。活動化は、受信側のメソッドでの制御のフローを表します。メッセージによってオブジェクトが作成される場合、最初の活動化は、コンストラクターのロジックを表します。それ以降のメッセージによって、新しい活動化が行われます。

メッセージが受け取られると、受け取る側のオブジェクトは、それ自体に対して、または他のオブジェクトに対して、メッセージを送信することができます。これは、矢印の尾によって表されます。矢印は、活動化を起点として新規の活動化を終点とするメッセージを表します。オブジェクトがそれ自体を呼び出す場合、新しい活動化は古い活動化の上に置かれます。

私たちのシナリオでは、申込者はローン申込書と2回対話します (最初は完成させるため、2回目は提出するため)。LoanApplication は、submit (提出) メッセージを受け取ると、自分自身にvalidate (検証) メッセージを送って、自分自身を検証します。LoanApplication が有効な場合には、信用調査機関に送る新規LoanRequest を作成します。図4はLoanApplication の検証を表しています。

図4. LoanApplicationの検証
図4

矢が飛ぶように: 時間経過の表示

メッセージが送られてから受け取られるまでにかなりの時間を要する場合、時間の経過を示すために、傾斜した矢印を使用します。この表記は、呼び出しがアトミックでないことを示すために使用されます。アトミックでない呼び出しの例としては、CORBAまたはRMIを介するメソッド呼び出し、またはネットワークを介して送信されるメッセージがあります。

私たちの例では、信用調査機関は外部システムであり、サーバー・パーソナリティーを備えたアクターです (詳細については、アクター・パーソナリティーについて を参照してください)。サーバーは通常メッセージを生成することはなく、メッセージ (この場合には、信用チェッカーによって送られる、信用報告書の要求) をサーバーあてに送らせます。信用チェッカーは信用調査機関を表します。信用チェッカーは要求を追跡して信用調査機関に転送し、応答を追跡して受信し、さらにローン処理アプリケーションと信用調査機関の間の結合を設定します。信用調査機関は要求を受け取って、それ自体のスケジュールに従って要求を処理します。下の図5に示すように、この間の時間経過を表すために、傾斜した矢印を使用します。

活動化が終わったときの呼び出し元への戻りは、暗黙的に行われます。しかし、場合によっては、明示的に戻りを行わせることもできます。明示的な戻り呼び出しは、受信側を尾とし、送信側を頭とした、破線の矢印によって示されます。明示的な戻り矢印には、多くの場合、呼び出しによって戻される値がラベルとして付けられます。私たちの例では、CreditBureauCreditChecker の間に明示的な矢印が追加されています。requestCreditReport メソッドから戻されるオブジェクトはCreditReport ですので、これを矢印のラベルにすることができます。

図5. CreditReport (信用報告書) の入手
図5

次回の予定

このコラムの最初に述べたように、シーケンス・ダイアグラムは、時間の経過とともに行われるシステム内部の振る舞いを記述するのに便利です。今回は、シーケンス・ダイアグラムの作成の第1歩として、オブジェクト間の対話のモデリングについて説明しました。次回では、2つの形式のシーケンス・ダイアグラム (汎用およびインスタンス) を紹介し、単純な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=227609
ArticleTitle=Javaモデリング: UMLワークブック: 第1回
publish-date=05012001