この章は入門ということで、通常のモデリング作業でよく用いられる基本的な要素に重点を置いて説明していきます。 UMLの図と、その図に使用される要素を説明するだけでなく、イメージしやすいように、 勤怠管理システムを例にして説明していくことにしましょう。

  勤怠システムの仕様

今回の例に用いるのは、社員の出退社時間を管理するシステムです。 社員は出退社処理しか行えませんが、総務の人は勤怠変更入力することが可能です。 また、次期開発では、遅刻/早退の場合には、理由を入力する機能を持たせます。 画面のイメージは図1のようになっています。勤怠変更画面のイメージは省略します。

UMLでは、以下の図が使用されます。勤怠管理システムを例に、順に説明していきましょう。

• ユースケース図
• アクティビティ図
• 状態図
• クラス図
• パッケージ図
• 相互作用図
  シーケンス図
  コラボレーション図
• オブジェクト図
• コンポーネント図
• 配置図

システムの使用機能（ユースケース）と、外部環境（アクター）との関連を表します。 図を読み取るのに専門知識は必要なく、 一目でシステムの機能やシステム外部と内部の境界を理解することができます。 そのため、ユーザやクライアントとの意識統一を図ることが容易になるでしょう。 図の要素には、以下のものがあります。

ユースケース(use case)

システムの使用機能（外から見た振る舞い）を、楕円の中にユースケース名として書くことで記述します。 ユースケースを全て集めたものが、システム全体の機能となります。ユースケース間の関係は以下のものが挙げられます。 << include >> や << extend >> はステレオタイプと呼ばれるもので、 関係の意味を拡張しています。ステレオタイプについての詳細は、後で取り上げます。

汎化ではどのように拡張するかが曖昧になるため、 ユースケースにバリエーションを持たせる以外では、 <<include>>や<<extend>>の依存関係を用いることが多くなるでしょう。

アクター(actor)

機能を利用するユーザや、システムが使用するハードウェア、外部システムがアクターとして表現されます。 アクターはシステムの一部ではありません。また、アクターにも汎化があり、ユースケースへの関連を引き継ぎます。

ノート(note)

全ての図において使用できる要素で、文章を書くことができます。 単独で使用することも、対象と破線によって結びつけて使用することもできます。モデルに影響は与えません。

それでは、勤怠システムを例にユースケース図を見ていきましょう。 図2が勤怠システムのユースケース図です。 「社員認証」を含んだ「勤怠入力」機能があり、遅刻や早退だった場合には、 「早遅理由入力」機能により理由入力することが示されています。 「勤怠入力」機能である「出社」と「退社」は、 「社員」と「社員」の関連を引き継いだ「総務」によって利用されます。 また、「勤怠変更」機能は「総務」だけが利用でき、「勤怠変更」機能にも「社員認証」が含まれています。 「社員認証」/「勤怠入力」/「勤怠変更」機能は、 外部システムである「データベース」（*）を使用します。 ノートにより「早遅理由入力」は、次期開発項目であることが明記してありますので、これ以降は取り上げません。 このように、ユースケース図を作成することで、外部要素であるアクターやシステムに必要とされる機能が、 明確に切り出せていますね。

脚注(*)

データベースをアクタとして書くことには異論があるかもしれません． もしユーザの言葉として「データベース」という単語が表れていれば私はアクターとしてもよいと考えます． データベースが今回の開発対象外であること，既に存在していること， 他のシステムにおいても共有されることなどを明確にできるからです．

ユースケース記述

ユースケースを説明する文章記述です。 文章があることで、より明確にユースケースの内容を相手に伝えることができます。

図3: ユースケース記述

┌──────────┬───────────────────────────┐
│ユースケース名　　　│出社処理ユースケース　　　　　　　　　　　　　　　　　│
├──────────┼───────────────────────────┤
│ゴール　　　　　　　│出社処理が完了する　　　　　　　　　　　　　　　　　　│
├──────────┼───────────────────────────┤
│事前条件　　　　　　│１－１．ログイン画面になっていること　　　　　　　　　│
├──────────┼───────────────────────────┤
│メインフロー　　　　│2-1．自分の社員IDを入力する 　　　　　　　　　　　　 │
│　　　　　　　　　　│2-2.パスワードを入力する　　　　　　　　　　　　　　 │
│　　　　　　　　　　│2-3.ログインボタンを押す(E-1) 　　　　　　　　　　  │
│　　　　　　　　　　│2-4.出社ボタンを押して出社時間を登録する(E-2) 　　  │
│　　　　　　　　　　│2-5.ログアウトボタンを押す　　　　　　　　　　　　　 │
│　　　　　　　　　　│2-6.終了ボタンを押す　　　　　　　　　　　　　　　　 │
├──────────┼───────────────────────────┤
│事後条件　　　　　　│3-1.データベースに出社時間が記録されること　　　　　 │
├──────────┼───────────────────────────┤
│例外フロー　　　　　│E-1:認証失敗。警告のダイアログボックスを表示する　　 │
│　　　　　　　　　　│E-2:データベースエラー。データベースエラーのダイアログ│
│　　　　　　　　　　│　　ボックスを表示した後、システムを終了する　　　　　│
└──────────┴───────────────────────────┘

今回は例外処理が発生するので、図3のようなイベントフローという形式で記述してみました。 例外処理が、うまくまとまって表現されていますよね。 この他にも、シナリオと呼ばれる一連の処理の流れを記述する形式があります。 シナリオは一連の処理の流れですので、ひとつのユースケースを表すのに、 メインシナリオや例外シナリオといったような、複数のシナリオが必要となります。

業務や処理の流れを表すために、関連する複数の業務手順や処理ステップを順序だてて配置したものです。 ワークフローからユースケースの処理フロー、メソッド内部のアルゴリズムなど、 手順のあるものなら色々なことが表現できます。分岐や同期を表現する場合にも便利でしょう。 図の要素には、以下のものがあります。

アクティビティ(activity)

業務や処理を行っている状態です。状態を矢印で結ぶことで、処理の流れを示します。

開始状態

システムの開始状態を示します。後に説明する状態図にも用いられます。

終了状態

システムの終了状態を示します。後に説明する状態図にも用いられます。

ガード(guard)

条件を示します。

分岐(branch)

処理の流れの分岐点を示し、ガードが真となる方向に遷移します。

図4は勤怠入力システムのアクティビティ図です。 システムが開始すると「ログイン画面表示」に遷移します。 「ログイン画面表示」からの遷移には分岐があり、ログインボタンが押された場合には、 ガードに示すように「認証作業」に遷移し、終了ボタンが押されると終了状態に遷移します。 このケースでは終了状態が2箇所あり、「データベースエラー警告表示」からも終了状態に遷移します。 残りの部分については省略しますので、図から読み取ってみて下さい。

同期バー

制御を分割したり、同期して結合したりすることを表します。 制御を分割するときはフォーク(fork)、同期して結合するときはジョイン(join)と呼びます。

レーン(swinlane)

振る舞いの責任範囲を分けるために、図を縦に分割する実線です。 オブジェクトやサブシステムに割り振られた処理のまとまりを明示します。

図5はシステム開発のワークフローを示しています。 この開発において、画面デザインは社外のデザイン部門によって、 データベースマシンの設定は社内のデータベース専門部署によって進められます。 開発チームでは、操作画面グループ、勤怠入力グループ、勤怠変更グループに分かれて開発します。 操作画面グループでは、画面部品の作成と単体テストを行いますが、 画面デザインと単体テストが完了するまでは、操作画面を作成することができません。 操作画面の作成と勤怠入力の単体テスト、勤怠変更の単体テストが終了すると、結合テストを行います。 結合テストが終了し、データベースマシンの設定も終わっていれば、総合テストを行い、実稼動へと進みます。 以上の手順が、明確に示されていますね。

ひとつのオブジェクトの状態変化を表した図で、外部からの入力と、 それに対するオブジェクトの状態遷移を表します。ひとつのオブジェクトと言っても粒度は様々で、 要求分析ではシステム全体をひとつのオブジェクトと見なすこともあります。 図の要素には、以下のものがあります。

状態(state)

オブジェクトがとる状態を表します。状態名の下の区画には動作を記述し、以下の種類の動作が記述できます。

表2: 状態に記述する動作

状態遷移(transition)

ある状態から他の状態への移行は、"イベント名[ガード]/実行する内容"のように記述します。 "イベント名"、"イベント/実行する内容"のように、不要なものは省略することができます。 また、自分自身へ遷移するイベントも記述でき、自己遷移と呼ばれます。

図6は、認証の視点から見た勤怠入力システム全体の状態図です。 開始時に状態は「未認証」となるので、entryに記述されているようにログイン画面が表示されます。ログインボタンが押された場合、認証が成功すると「認証済」に遷移し、失敗すると自己遷移します。認証が成功した場合には、「認証済」に遷移するので、entryに記述されているように勤怠入力画面が表示されます。出社ボタンが押されることで駆動される出社処理や、退社ボタンが押されることで駆動される退社処理は、状態遷移を伴わないので状態の内部に記述しています。終了ボタンが押されたときと、データベースエラーのときには、システムが終了します。

クラス図(class diagram)

モデルの静的な構造を表す図で、問題領域やシステムの構造を表現できます。パッケージ単位での表現や、全体での表現、または機能単位での表現というように、色々な視点で作成することができます。図の要素には、以下のものがあります。

クラス(class)

長方形の中は3区画に分かれ、上からクラス名、属性、操作が記述されます。クラス名の上には"<<>>"で囲まれたステレオタイプを付けることができます。属性はデータを表し、"可視性 名前:型 = デフォルト値"で表します。操作は振る舞いを表し、"可視性 名前(パラメータリスト):返り値"で表し、パラメータリストは、"名前:型=デフォルト値"をコンマで区切って並べます。また、staticな属性や操作は、下線をつけることで表現します。可視性は次のように表します。

表3: 可視性

関連(association)

クラス間に、参照や実体を保持するなどの関係があることを表します。線の両端には矢印をつけることができ、矢印がある場合は、その方向にのみ関連があることを示します。これを誘導可能性(navigability)と言い、矢印の無い関連は、誘導可能性が未知であるか、双方向であることを意味します。分析レベルでは未知であることが多いでしょう。

集約(aggregation)

関連の一種で、「全体－部分」関係を表します。

コンポジション(composition)

　

関連の一種で、より強い集約を表します。全体が削除された時点で、部分も共に削除されると考えられます。

ロール名(role name)

関連の端に書かれる、関連先の役割を表す名前です。設計レベルでは、関連先を保持するための名前、つまり属性名を付けることが多いでしょう。

多重度(multiplicity)

関連の端に書かれ、関連の張られたオブジェクト間の数的関係を表します。具体的な数値の他に、"0..n"や"*"(共に0以上)、"1..n"(1以上)、"2..7"(2から7)のように任意の値を設定できます。

依存関係(dependency)

相手の変更によって影響を受ける関係です。引数などで一時的に使用するクラスやイベント通知などを表現するときに使用します。

汎化(generalization)

属性/操作/関連を引き継ぎます。JavaやC++、C#の継承に相当します。矢印の先端が継承元となります。

実現(realization)

操作のインターフェースを引き継ぎます。Javaのinterfaceに相当します。矢印の先端が実現元となります。

図7は勤怠入力のクラス図です。勤怠入力コントローラークラスは、勤怠入力画面クラスからイベントを受けます。 ここでは、JDK1.2で導入されたイベントモデルを使っています。これはObserverパターンを拡張したものです。 受信用のインターフェースをリスナークラスとして定義することにより、送信者は受信者に直接依存するのではなく、 受信用のインターフェースに依存するようになります。勤怠入力コントローラークラスでは、 勤怠入力ボタンリスナークラスというインターフェースを実現して、勤怠入力画面クラスからイベントを受けとります。 データベースラッパークラスは、データベース操作のラッパー(*)群です。 また、staticメソッドの呼び出しや引数として使用するクラスには、依存関係が用いられていることや、 勤怠入力コントローラークラスが、データという名称で勤務時間データクラスを 「全体－部分」の関係で保持することもわかりますね。ステレオタイプと制約については、以下で説明します。

ステレオタイプ(stereotype)

UMLの拡張メカニズムで、アプリケーションや問題領域固有の意味を、 わかりやすくモデルに表現するために付加する文字列です。ステレオタイプを付加することで、 同一のモデル要素を、意味的に分類することができます。例えばinterfaceのステレオタイプをつけたクラスは、 振る舞いのインターフェースのみ定義したクラスであることを明示しています。 また、ステレオタイプをアイコンに関連付けすることもでき、 図7の勤怠入力ボタンリスナークラスをアイコン表示した場合は、図8のようになります。

図8: インターフェースアイコン

制約(constraint)

{ }に囲んで制約を課すことができます。図9では、勤務時間データを年月日で整列して持つことを表しています。

図9: 制約

パッケージ間の依存関係を表す、クラス図の一種です。 クラスは、その意味や役割に基づいてグループ化されますが、そのグループをパッケージといいます。 パッケージには、パッケージを含むこともできます。

図10: パッケージ図

図10では勤怠入力のパッケージ構成を示しています。 図7のクラス図に現れたクラスは、次のようにパッケージ分割しています。

表4: パッケージ構成

クラス間の関係がパッケージ間の依存関係になるので、このような依存関係になることがわかりますよね。

オブジェクトの相互作用を表す相互作用図の1つで、オブジェクト間のメッセージのやりとりを、 時系列に沿って表現します。同じ振る舞いをコラボレーション図で表現できますが、 活性区間とライフラインは表現できません。コラボレーション図については、後に述べます。 図の要素には、以下のものがあります。

オブジェクト(object)

クラスが実体化したものをオブジェクトと呼び、インスタンスとも呼ばれます。長方形の中に、 「オブジェクト名:クラス名（下線）」で記述し、名前の一部を省略して、 「オブジェクト名（下線）」や「:クラス名（下線）」と記述することも可能です。 オブジェクトは、後述のコラボレーション図でも使用されます。

ライフライン(lifeline)

オブジェクトが生存している期間を示す点線で、オブジェクトから垂直方向に伸びます。 点線の先に×が現れるまでが生存期間です。

メッセージ(message)

ライフライン間を結ぶ水平の矢印（左右どちら向きでもOK）とメッセージ名で表現します。 矢印には、同期と非同期の2種類があり、先端の形状が異なります。同期的なメッセージは黒三角の矢じり， 非同期的なメッセージは「く」の字の矢じり(*)です．同期的とは， メッセージのリターンを待って次の処理に進むような場合で，通常のプログラミング言語の関数呼び出しです． 非同期的とは，リターンをまたずに次の処理に進む場合で，例えば受け側が別のスレッドで動いており， キューにメッセージを貯めているような場合に相当します．

図11は、出社ボタンを押してから出社処理が終了するまでのシーケンス図です。 「:勤怠入力コントローラー(下線)」への出社メッセージが非同期であるため、出社処理とは活性区間が分かれています。 また、「:勤務時間データ(下線)」の生存期間や、set勤務時間メッセージのリターンがtrueであることも、 注目のポイントです。

オブジェクトの相互作用を表す相互作用図の1つで、オブジェクト間のメッセージのやりとりを、 接続関係に着目して表現したものです。レイアウトを工夫することで、 シーケンス図よりもオブジェクト間の関係がつかみやすくなります。図の要素には、以下のものがあります。

リンク(link)

インスタンスレベルでの関連で、他のオブジェクトとの参照関係を表します。リンクと関連の関係は， オブジェクトとクラスの関係と同じです．すなわち，関連をインスタンス化したものがリンクとなります．

メッセージ(message)

シーケンス図で使用するものと同じですが、メッセージの相対的順序番号が必須となります。

図12は、先に挙げたシーケンス図と同等の処理を、コラボレーション図で表現しています。 オブジェクト間の関連に注目したかったため、アクターである「社員」は省略しました。 「:勤務時間データ(下線)」の生存期間はわかりにくくなってしまいましたが、 オブジェクト間の関係はシーケンス図よりもつかみやすいですね。

システムに存在するオブジェクトのある時点におけるスナップショットです。 メッセージの無いコラボレーション図とも言えます。図の要素には、以下のものがあります。

オブジェクト(object)

先程述べたことの補足ですが、長方形を2区画にすることで、下の区画に属性を表現することができます。 属性は「属性名:型 = 値」で記述し、「:型」は省略可能です。

図13: オブジェクト図

図13は、出社処理のために勤務時間データのインスタンスを生成し、 データを設定した時点でのオブジェクト群のスナップショットです。 実際にどのようなデータが設定されるかがわかると思います。

コンポーネント間の依存関係を表す図です。図の要素には、以下のものがあります。

コンポーネント(component)

ソフトウェアやexeファイル、dllファイル、ソースコードなどが、コンポーネントとして定義できます。

図14: ソース間の依存関係を表すコンポーネント図

図15: 実行ファイル間の依存関係を表すコンポーネント図

図14では、C++での実装を例にとって、ソースコードとヘッダファイルの依存関係を示しています。 勤怠入力コントローラー.cppは、 勤怠入力コントローラー.hとデータベース操作.h、勤務時間データ.hをインクルードします。 図15では実行ファイルとライブラリの依存関係を示しています。 勤怠入力.exeは、データベース.dllをリンクします。

実行時のシステム構成や、コンポーネントがどのノードに割り当てられているかを表現することができます。 配置図において、コンポーネントはインスタンスとなるので、名称に下線を引いて表現します。 また、通信プロトコルなどを指定したい場合には、ノード間の関連にステレオタイプを付けることで指定できます。 図の要素には、以下のものがあります。

ノード(node)

コンピュータ資源を表し、下線付きでノード名を記述します。

図16では勤怠入力実行時のシステム構成を示しています。 勤怠入力とデータベースが、コンポーネントとして別ノード上に記述されているので、 勤怠入力が動作しているコンピュータとデータベースが動作しているコンピュータが、 異なっていることがわかります。 また、これらのコンピュータ間ではTCP/IPによって通信していることが、ステレオタイプによって記述されています。

勤怠入力システムを例に、一部分を抽出する形で説明してきましたが、 図や要素の意味、実際のシステムへの適用などはイメージできたでしょうか？ 最初から全ての図を使うと、すごく時間がかかってしまうと思いますので、 クラス図あたりから使用してみてはいかがでしょう。コーディング前にクラス構成が洗練されるなどの 効果が得られると思います。

次章は実践編ということで、LEGO MINDSTORMS(TM)を制御するプログラミングに、 UMLによる分析/設計を適用します。内容が簡単ですし、 実際にLEGO MINDSTORMS(TM)があれば動かせるものであるため、より楽しめると思います。 是非そちらも読んでみて下さい。

手書きでもよい．まずはホワイトボードに書くことからはじめよ．

「すべて」を書こうとしない．注目しているポイントのみ図にせよ．

用語辞書を作れ．名前を統一せよ．

困ったらノート．日本語で説明せよ．

そのプロジェクトでよく現れる分類は，ステレオタイプにせよ．

≫第3章