UML 2 アクティビティ図の概要
by Scott
W. Ambler, Copyright 2003
UML2.xのアクティビティ図(Object Management Group 2003)は、一般的に、ビジネスプロセスモデリング、1つのユースケースまたは利用シナリオに記述されたロジックのモデリング、ビジネスルールの詳細ロジックのモデリングなどに使います。UMLのアクティビティ図を使って複雑な操作の内部ロジックをモデリングすることも可能ですが、アクティビティ図が必要ないレベルまで単純になるよう操作を書き直すほうがはるかによい方法です。多くの意味で、オブジェクト指向におけるUMLアクティビティ図は、構造化開発のフローチャートやデータフロー図(DFD)に相当します。
最初に、図1および図2で使用している基本的な表記法について説明しましょう(この他にもさまざまなものがあります)。
-
初期ノード (initial node):黒丸はダイアグラムの開始地点です。初期ノードは必須ではありませんが、書いておくと図がずっと読みやすくなります。
-
アクティビティ最終ノード (activity final node):内側を塗りつぶした二重丸は終了地点です。アクティビティ図には、ゼロを含む任意の数のアクティビティ最終ノードを含めることができます。
-
アクティビティ (activity):角の丸い長方形は発生するアクティビティを表します。アクティビティには、「申込用紙をチェックする」のように物理的なもの(人が行うもの)も、「学生作成画面を表示する」のように電子的なものもあります。
-
フロー/エッジ (flow/edge):図上の矢印。フローとエッジには確かに微妙な違いがあるのですが、実際に使い分ける目的が私には分かりません。ここではフローという用語を使います。
-
フォーク (fork):1つのフローが入っていき、複数のフローが出ていく黒い棒。並列して実行されるアクティビティが始まることを表します。
-
ジョイン (join):複数のフローが入っていき、1つのフローが出ていく黒い棒。並列処理が終わることを表します。
-
条件 (condition):フロー上に付けられた「[申込用紙が正確でない]」などのテキスト。ガード条件を定義します。これが真にならなければ、次のノードに移動することはできません。
-
決断 (decision):1つのフローが入っていき、複数のフローが出ていくひし形。出ていくフローには条件を指定しますが、条件が明白な場合には指定しないモデリング担当者もいます。
-
併合 (merge):複数のフローが入っていき、1つのフローが出ていくひし形。特にそれ以外の指定がない場合(図2を参照。これについては後述します)、入ってくるフローがすべてこの点に到達するまでは処理が先に進めないことを暗黙的に表します。
- 区画 (partition):図2は3つの区画に区切られています。これはスイムレーンとも呼ばれるもので、何/誰がそのアクティビティを行うか(「申込者」か「学籍係」か「システム」か)を表します。
- サブアクティビティ指示子 (sub-activity indicator):アクティビティ(「大学に申し込む」アクティビティなど)の下隅にある熊手の形をしたマークは、そのアクティビティがさらに詳細なアクティビティ図で記述されていることを表します。図2では「ゼミに登録する」のアクティビティにこのシンボルが付いています。
-
フロー終了 (flow final):丸の中いっぱいに×が書かれたシンボル。処理がここで終わることを表します。
-
ノート (note):図2では、標準のUMLのノートを使って、この併合では処理を進める前に3つのすべてのフローが到着する必要はないことを表しています。同じことをモデリングするのに、「該当なし」と「候補リストに申込者が入っていない」の間にORの制約を付けて表現することもできます。私がノートを好んで使うのは、その方が利害関係者に理解しやすいためです。
-
ユースケース (use case):図1には、「ゼミに登録する」のユースケースがアクティビティの1つとして呼び出されることを示しました。これは、図に含まれているユースケースが呼び出されることを表すために私が使っているごまかしたやり方です。正直に言うと、この書き方がUMLで正式に認められているかどうか自信がありませんが、明らかに認められるべきだと思っています。図2のようにユースケースを普通のアクティビティとして表す方法もありますが、ユースケースを使った場合ほど分かりやすいとは思いません。
図1のアクティビティ図は、「ゼミに登録する」のユースケースのロジックをモデリングする1つの方法を表しています。アクティビティのこのような使い方は非常によく見られますが、これはアクションの基本コースと代替コースの両方を表すことかできるためです。アクティビティ図は、複数のユースケースをまたがって書くこともできますし、ユースケースの一部だけを対象に書くこともできます。また、ユースケースとまったく関係なくアクティビティ図を使うこともできます。たとえば、エクストリームプログラミング(XP)のペアの開発者(Beck 2000)が顧客(利害関係者を表すXPの用語)と一緒にアクティビティ図を書いて、ユーザストーリーやユーザストーリーがサポートするもっと大きなビジネスプロセスを分析することができます。
図1 「大学に登録する」ユースケースのUMLアクティビティ図
図1に関していくつかのことが目につきます。
-
ここで使っている表記法は、おそらく90パーセントほどの頻度で使うものです(たまにしか使わないものについては後で説明します)。
-
ひし形を使って決断や併合を表す方法は、見て分かりやすいのですが、残念ながらあまり一般的に使われてはいません。図2では、ひし形を使って分岐点を表すのではなく、アクティビティから出ていくフローに条件を付けて表しています。
-
フォークを使って並列処理を表しています。ここでは、申込者のチェックのいくつかを並列で行うことができると判断しました。これをフローチャートで表すのは簡単ではありません。
-
アクティビティ図がすぐに大きくなりすぎてしまうことが分かります。1つのユースケースのロジックだけをモデリングしているにもかかわらず、スペースが足りなくなったので、ホワイトボードに沿って図をねじ曲げなければなりませんでした。理想を言えば、もっと図を広くして、ホワイトボード上でロジックが左から右へと流れるようにしたいところです。さらに言うと、もっとホワイトボードのスペースがあるといいのですが。
-
ありがちな間違いをしています。一番最後のところで、「支払いを処理する」と「領収証を印刷する」の直前に分岐を使って、これらを並列で処理できることを表しています。これは決断ではなくフォークを使うべきです。また、併合ではなくフォークに対応するジョインを使えばよかったのですが、これはどちらでもかまいません。ジョインまたは併合が必要なのは、このアクティビティ全体が終了する前に、分岐した両方のアクティビティのフローが終了している必要があるためです。これがなければ、実際には競走状態になって、早い方のアクティビティのフローが終わるとすべてが終わってしまうことになります。
図2は、図1とは違ったアプローチで「大学に登録する」のユースケースを表したものです。先に述べたように、この図では決断を使っていません。また、区画(スイムレーン)の概念を導入して、誰/何がそのアクティビティを実行するかを示しています。この図では区画に「申込者」「学籍係」「システム」というテキストのラベルをつけましたが、アクターのシンボル(線で書いた人型)を使ってアクターがアクティビティを実行していることを明確に表す方法もよく見られます。区画によって得られる情報は有益ですが、図も長くなります。私はスペースが足りなくなって、図の続きを別のホワイトボード(ここには示していません)に書くことになりました。物理的に切り離された部分をどう合わせるかを示すために、コネクタ(Aと書かれた丸)を使っています。コネクタを使うのは通常、図の1つの端から他の端へ線を引かずにすませるためです。線を引く代わりに、コネクタに入るフローを書き、同じラベルのコネクタ(たとえば両方のコネクタにBと書かれている)から出て移動先のアクティビティに入る別のフローを書きます。図2にはその他に、フロー終了 (flow final) (丸の中いっぱいに×が書かれたもの)と、上述の併合に関する制約を記したノートが含まれています。
図2 アクターごとに区画を分けたUMLアクティビティ図
図2の区画のスタイルは、競泳用プールのレーンに似ているため「スイムレーン」と呼ばれることもよくあります。図3はそれとは違ったアプローチです。「スイムエリア」とでも呼ぶべきでしょうか。見れば分かりますが、スイムエリアはスイムレーンほど場所を取りません。また、この2つの図の区画の切り分け方が異なっていることに気づいたでしょうか。図2はアクターごとに区画を分けているのに対して、図3はユースケース内のアクションのコースごとに分けています。いつものアドバイスですが、自分の状況にもっとも合った方法を使ってください。
図3 代替コースによって区画を分けたUMLアクティビティ図
図3にはこれまでに見たことのない表記法が使われています。五角形の「セキュリティ上のリスクの可能性」というシグナルです。このシンボルは、イベントが発生したこと、つまりセキュリティ上のリスクの可能性があると判断したことを表しています。そのため「セキュリティチェックを行う」のユースケースをトリガーする必要があるかもしれません。
図4は「スケジュールを配布する」ユースケースのUMLアクティビティ図です。今回は作図ツールを使っているため、記法の例をはっきりと見ることができます。「スケジュールの印刷完了」のシグナルを受け取り(おそらく別のアクティビティ図から送られたものでしょう)、かつ4月1日(あるいはそれ以降)であれば、このアクティビティは開始します。砂時計型のシンボルは時間を表します。処理を先に進めるにはジョインに入っていくすべてのフローが起きていなければならないため、この図は「スケジュールの印刷が済んでいて、少なくとも4月1日になっている」と読み取れます。実際に私はこのことをジョイン仕様を使って示しています。ジョイン仕様は、基本的には制約であり、{joinSpec = …}の書式で記述してジョインに結び付けます。この図のジョイン仕様はまったく余分なもので、例を示したかったという他に記述する意味はありません。私がジョイン仕様を記述するのは、入ってくるフローからでは明確に分からない制約がある場合だけです。たとえば、スケジュールを4月21日までに配布しなければならないのであれば、おそらくそれをジョイン仕様として記述することでしょう。
図4 スケジュールの配布
図4で、「郵送先名簿を決定する」アクティビティの横に付いている四角はピンと呼ばれるもので、「郵送先ラベルを印刷する」アクティビティに付いてるものはパラメータです。フロー上の丸は変換を表しています。この場合、郵送先名簿に載っている人を郵便番号で並べ直し(このように分類して大量に郵送すると送料が安くなるため)、各個人をリストにしてそれぞれの送付先ラベルを印刷できるようにします。
「ラベルつきスケジュール」の箱は、アクティビティ間で受け渡すオブジェクトの例です。この記法を使うと少し間抜けな感じがするため、私がこのようにオブジェクトを表記することはほとんどありません。たいていは行間を読んで、アクティビティ間に何が流れているかを判断することができます。たとえば、「郵送先ラベルを印刷する」アクティビティから「ラベルをスケジュールに貼る」アクティビティにラベルが渡されることは明白です。
注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。本ではより詳しく説明しています。
アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。
Ronin
International, Inc. continues to help numerous
organizations to learn about and hopefully adopt agile
techniques and philosophies. We offer both
consulting and
training offerings. In addition we
host several sites - Agile
Modeling, Agile
Database Techniques, UML
Modeling Style Guidelines, Enterprise
Unified Process (EUP) - that you may find of value. You
might find several of my books to be of interest,
including
The Object Primer, Agile
Modeling, The
Elements of UML Style, and Agile
Database Techniques. For more information please
contact Michael Vizdos at 866-AT-RONIN (U.S. number) or via e-mail (michael.vizdos@ronin-intl.com).
visits since November 17, 2003.
|