目のつけどころが"ソフト"でしょ　開発プロセス考15　――統合モデル化言語におけるアクティビティ図

　UML（Unified Modeling Language）において，分析用としてユースケース図が最初に使われます．しかし，場合によってはアクティビティ図を，ユースケース図に先行して作成することもあります．ここでは，「注文して商品を手に入れる」という過程のアクティビティ図を考えてみます．

●アクティビティ図とは何か

　図1について，簡単に説明します．全体は縦方向の三つの部分に分かれています．UMLではこれを「スイム・レーン」と呼び，競泳のレーンに模しています．実際，それぞれのレーンは，ロールごと（すなちアクタごと）のアクティビティを書くことになります．ちなみに，アクティビティは角の丸い矩形で表現されます．図1のいちばん左側は，顧客のアクティビティを表しており，彼/彼女には「サービスの要求」，「支払い」，「注文品の確認」というアクティビティがあるということを示しています．

［図1］　アクティビティの例

　単純な矩形はロール間でやり取りするオブジェクトを表しています（すなわちレーンをまたぐオブジェクト）．各オブジェクトの［ ］で示されている部分は，そのオブジェクトの状態を表しています．例えば，顧客から営業に渡る注文オブジェクトは「発行中」状態を持ち，営業からストック・ルームに渡るオブジェクトは，システムへの「入力済み」という状態を持ちます．《physical》というステレオ・タイプは，情報ではなく実際のモノを表しています．アクティビティ間で受け渡されるオブジェクトは点線で結び，それ以外（すなわち単純なアクティビティ間）の順序は実線で表現します．

　次に，どのような場面でこの図を使うのかを考えてみます．あるいは，なぜ，この表記法が必要になるのかを考えてみます．

●通信機能を持つ組み込み系ではアクティビティ図が必要に

　今，対象としている世界の中にシステムとロールを持った人（アクタ）がいると単純化して考えます．UML の多くの表記は，このうち，システムのみを記述するために存在しています．

　しかし，初めからシステム（境界）が明確なわけではありません^注1．例えば，業務フローを記述しようとすると，アクタを含めてどういった情報やモノがやり取りされているかを記述する必要があります．このシステムそのものがよくわかっていないとき，「業務を記述したい」ということになります．業務を記述しながらシステムそのものを徐々に明確にしていくような場合，UMLでは先のアクティビティ図を使うしかありません（もちろん，UMLにこだわらないということであれば，いくらでも書きようがあるのだが...）^注2．

　すなわち，先の質問の答えは，

• いつ使うか→ 業務分析などでシステム（境界）を意識しないとき
• なぜ必要か→ アクタ間の情報・モノの流れが記述できるから

ということになります．

　このようなアクティビティ図を利用した記述は，事務処理系でよく用います．一方，使用されるハードウェアや使いかたを最初から明確に定義できる組み込み系では，あまり必要はなかったと思います．しかし，いまや組み込み系はさまざまな対象と通信する機能を持ちつつあり，そのときに複雑なアクタとの関係を含めて整理する必要が生じるに違いありません．このような場合には，アクティビティ図が必要になってくるのでは，と考えています．

 注1；一般には，ユーザですらどういうシステムが適切かはわかっていない．
 注2；このほかに，UMLにはユースケース図があり，システムとアクタの関連を記述している．しかし，あくまでもシステムが前提になっていることに注意が必要である．システムとアクタのやり取りは，図の楕円の部分として記述されるが，アクタ間の情報の流れは，ユースケース図といえども記述することができない．

(本コラムはDESIGN WAVE MAGAZINE 2002年10月号に掲載されました)

◆筆者プロフィール◆
伊藤昌夫（いとう・まさお）．自動車会社，航空機関連会社のソフトウェア・エンジニアを経て，ニルソフトウェアを設立．ソフトウェア・プロセスおよび開発環境が専門で，そのためのコンサルテーションおよびツールの提供を行っている．設計における人間の認知活動に興味を持っている．