UML/モデリング

ちょっとうれしい UML 2.0 のこんな技

デシジョン入力の巻

オージス総研

山内亨和

2006年9月7日

オージス総研では、社内の有志で集まっていくつかの勉強会を実施しています。その中の一つに、筆者が参加している UML 2.0 に関する勉強会もあります。この勉強会では、現場で活用している UML 2.0 のテクニックを共有したり、便利そうな UML 2.0 の表記法を発掘したりしています。この勉強会の成果を、（少しずつではありますが）皆さんに公開していきたいと思います。

はじめに

　UML2.0で最も変更された図はアクティビティ図です。UML1.Xではその表現力の弱さから敬遠されてきたアクティビティ図ですが、UML2.0では表現の幅が広がりUML1.Xで記述できなかったことが記述できるようになりました。

　今回はそんなアクティビティ図から、デシジョン入力を紹介します。

デシジョン入力を使った例

　百聞は一見にしかず、デシジョン入力を使った例を示します。以下の図は障害管理のワークフローを定義したアクティビティ図です。

　
図 1 デシジョン入力を使った障害管理のワークフローの例

　この障害管理のワークフローでは、障害の調査が終わった後、障害の原因に応じて次に行うアクションが変わります。（自システムに障害の原因があればプログラムを修正しますし、外部システムに障害の原因があれば外部システムの担当者に障害を報告します）

　デシジョン入力は、このような条件分岐のルール（どのシステムに障害の原因があるか？）を記述するための表記です。

　デシジョン入力には次の特徴があります。

デシジョンノード（UML1.Xのデシジョン状態）のノートです
デシジョン入力（ノート）の中に条件分岐のルールを記述します。
ノートの上部に<<decision Input>>というキーワードをつけます。

　また、ガードにはデシジョン入力で定義した判定ルールとの比較値（自システム、外部システム）を記述します。

UML1.Xと比較してデシジョン入力の利点を考える

　UML1.Xの頃にはデシジョン入力はありませんでしたが、デシジョン状態やガードを使って条件分岐を表現できました。同様に、UML2.0ではデシジョン入力を使わなくても条件分岐を表現できます。わざわざデシジョン入力を使う利点とは何でしょうか。

利点１：ガードの配置が容易になる

　1つはガードの配置が容易になることです。以下の図を見てください。

　
図 2 UML 1.X の障害管理のワークフローの例

　この図はデシジョン入力を使わないで作成した障害管理のワークフローです。デシジョン入力を使った場合と比べて、ガードの記述が長くなっています（外部ｼｽﾃﾑに障害の原因がある、など）。

　アクティビティ図や状態マシン図をモデリングしていると、ガードの記述が長くなってしまって置き場に困ることがあります。ひどい場合には、上記の例のようにどの制御フローのガードなのか分からなくなってしまいます。

　デシジョン入力を使えばガードの記述が短くなるため、このような問題はなくなります。

利点２：条件分岐のルールが目立つ

　もう1つは、条件分岐のルールが目立つことです。

　条件分岐のルールは他のアクティビティ図の要素（アクションや制御フロー）と同じくらいか、それ以上に大事です。アクティビティ図をレビューする場合、条件分岐のルールは注意して確認したい点の一つです。

　しかし、デシジョン入力を使わずガードのみで書いてしまうと、重要なルールが（図中の隙間に！）目立たなく記述されてしまい、レビューアは見落としてしまうでしょう。

　そこのところ、デシジョン入力はノートという目立つサイズと表記を使っているため、レビューアも見落とさずにレビューしてくれるでしょう。

デシジョン入力を使うコツ

　アクティビティ図は、エンドユーザーなどUMLを知らない人が読む機会が多い図です。ですから、拒否反応を起こすような小難しい図にはしたくありませんし、詳しい説明をしなくても理解できる図にしたいものです。

　デシジョン入力を使う場合には、次の2つに注意しましょう。

キーワード<<decision Input>>は使わない
読者が拒否反応を起こす可能性があります。
デシジョン入力を目立つ位置に配置しよう
・　ある程度、周りに余白をとる。
・　一連のアクションの流れを眺めていくと自然に目に入るような位置に配置する。

　
図 3 一歩進んだデシジョン入力の例

参考文献

[1] 『その場でつかえるしっかり学べる UML 2.0』オブジェクトの広場編集部／著, 秀和システム

第2回 »