 |
[1999 年 8 月号] |
|
[1999 年 8 月号] |
［オブジェクト指向モデリング言語
UML］
- 情報処理 VOL.40 NO.1, NO.3より
-
UMLの課題
現在のUMLは，既存のオブジェクト指向技法で採用しているモデリング概念はほとんど取り込み，そのセマンティクスもメタモデルを使って整備されてきたが，いくつかの不備や問題点も存在する．ここでは文献11)〜13)，17)および著者自身の経験を参考にして，重要な問題点をいくつか指摘する．
ユースケースに関して
ユースケースはUMLの第1級のモデル要素である以上，ユースケースの意味について明確な指針が必要であるが，今のところ人により解釈が分かれる．特に，構造化分析や機能分割法におけるプロセスや機能との違いや適切な粒度が曖昧である．
また，ユースケースの内容記述に最低限どれだけの情報が必要なのか，その記述スタイルはどうあるべきかの定義もない．現在，アクタに対して意味のあるサービスを提供するシステムの振る舞い，システムの基本操作，ドメインプロセスといった説明があるが，UMLが開発プロセスと切り離されたことも一因となってきちんと定式化できていない17)．
また，アクタの扱いが一様でない．当該システムに関与する外部システムをアクタにする場合に，付随する相互作用をユースケースとすべきか否かで合意がなくユースケースを識別する上で恣意性を生じている13)．さらに，ユースケースの具体的な事例をシナリオと呼ぶが，シナリオはどのような意味でユースケースの事例なのかといった，両者の関係の正確な解釈も曖昧である．なぜなら，ユースケース記述は，抽象的アルゴリズム表現というよりは，当事者をパラメータ化したものではあるが振る舞いの典型的なシーケンスであることが多いからである．一方，シナリオも完全に具体的な人物やインスタンスであるよりは「少年Ａ」や「図書Ｘ」といったプロトタイプインスタンスが登場することの方が一般的であるため，ユースケースとの抽象度の違いが曖昧である．現在，ユースケース記述を，通常の典型例である主ユースケース，主ユースケースのフローの中途で分岐する2次的ユースケース，正常に終了しない例外ユースケースなどと分類することがあるが，こうやって区別された各フローがそれぞれシナリオであると考えるのが妥当だろう．
ユースケース間の汎化関係もその呼称が要らぬ誤解を招いてUMLの汚点であったが，先に述べたようにUML1.3では依存関係として解決した．
関連クラスはオブジェクト間の関連自体を実体化したオブジェクトであるが，その定義が一部曖昧であることからセマンティクスがきちんと理解されていない．UMLでは，関連クラスのインスタンスの存在は，対応する関連の両端にある２つのオブジェクトの存在に依存するはず（そうでないと普通のクラスとは別にわざわざ関連クラスを導入する意味がない）だが，一般に，その制約は認識されているとはいい難く，通常クラスと同じ意味解釈が適用されやすく，注意を要する．
シーケンス図はそこに参加するオブジェクトが活性であることをオブジェクト生存線上の白抜きの柱(制御フォーカスとも呼ばれる)を示すことで表現できる．しかし，あるオブジェクトが活性であるという状態の意味が定義されていないためその解釈が曖昧である．それは，(a)スレッドに対応，(ｂ)メソッド起動状態(言語処理系における関数・手続きの実現方式としてのスタックフレーム)に対応，の両方の解釈が入り混じっているため，正確な記法がどうあるべきなのか(戻り値の矢線を書くべきか，非同期メッセージを2度目に受信するとき活性区間は重なるべきかなど)判断できないケースが出てくる．
アクティビティ図はステートチャート図の拡張であるが，その目的や用途は大いに異なる．ステートチャート図が各オブジェクト単位のライフサイクルの表現に限定されているのに対し，アクティビティ図はある機能や処理を複数のステップ(各々をアクティビティといい，それぞれが並行処理であってもよい)のフローとして実行する様子を表現できる．したがって，ユースケースの内容記述にはもってこいの図だが，UMLではユースケース図とアクティビティ図はモデル構成の中で積極的には結び付けれられていない．
| © 1999 OGIS-RI Co., Ltd. |
|
