概要
今回はエンタープライズモデリングのためのゴール分析手法として第15回でも紹介したi*(iスター)フレームワークの書き方の留意点について考える[1][2]。i*の意味はdistributed intentionalityということで複数の意図が分散しているという意味だ。i*フレームワークでは、社会的アクタ、ソフトゴール、タスク、資源から組織を構成すると考える。社会的アクタは相互に依存しあいながら、提供される資源を用いてタスクを遂行することによりソフトゴールを実現する。
i*フレームワークの図をパワーポイントで書く
i*フレームワークには、SD(Strategic Dependency)図とSR(Strategic Rational)図がある。これらの図では、アクタは円、タスクは六角形、資源は矩形、ゴールは楕円で書くので、パワーポイントの基本図形がそのまま使える。ソフトゴールは雲形なので、私はクリップアートの雲形を使っている。この雲形は次のようにすればパワーポイントのスライドに挿入できる。
プルダウンメニューの挿入から図を選択する。つぎにクリップアートを選択して「雲」で検索すると、影つきの雲が出てくるので、これを選択してから影付スタイルのポップアップメニューで「影なし」を指定する。
このアイコンだと、基本図形と同じようにマウスで選択してキーボードから文字を直接、雲の中に文字を記入できるから、便利である。
さて、i*フレームワークでやっかいなのは依存関係が独特な記法になっている点だ。どういうことかというと、アクタやデペンダムとの依存関係を表す線の中央に矢印が配置されているためだ。この依存関係を次のようにして2つの線に分解すると比較的簡単にきれいに書くことができる。図1に従って説明しよう。
図1 i*の依存関係を書く
たとえばまず矢印を配置する受益者(デペンダ)からソフトゴールへの中間点を決め、受益者からこの中間点まで矢線を引く。次に受益者からソフトゴールへの中間点から、ソフトゴールまで残りの線を引く。そして受益者からソフトゴールへの依存関係を選択し、提供者側の依存関係としてコピーするといい。ここで作成した2つの線を組み合わせた依存関係をグループ化しておくと、まとめてコピーできるので便利だ。
簡単なSD図の作成手順
以下では図2に従ってSD図の簡単な作成手順を紹介する。SD図を記述するときには、まずアクタを列挙する。ここではラジオのパーソナリティによる楽曲のリクエスト番組を考えよう。
図2 SD図の作成手順
アクタは番組の視聴者とパーソナリティだ。アクタを列挙したらアクタ間で、どんな依存対象があるかを考えよう。ここでは「曲を聴きたい」「曲名」「曲をリクエストして欲しい」「曲を流す」などを思いついたとしよう。
この後は視聴者とパーソナリティの間でこれらの依存対象ごとに依存関係の方向を決定すればよい。
UMLとi*フレームワーク
ソフトゴールは出てこないがUMLのユースケース図やシーケンス図をi*フレームワークのタスクや資源を用いて書くことができる。 以下では次のような商品販売シナリオについて考えよう。
例 商品販売における受付係の仕事に関するシナリオ
- 注文主が出庫を依頼する
- 在庫を確認する
- 在庫不足なら不足品を発注係に発注する
- 在庫があれば倉庫係りに出庫を指示する
- 倉庫係が出荷を確認する
- 在庫を更新する
- 注文主に納品書を提示する
まずアクタを調べると、注文主、倉庫係、発注係が見つかる。また受付係の仕事についてのシナリオなので、受付係もアクタになる。
つぎにアクタ間の関係を調べよう。このとき表1のように整理しておくと漏れがない。ここで文2と文6を次のように考える。すなわち「在庫を確認する」では受付係が最初に倉庫係から在庫情報を調べておき、出荷するごとに受付係の手元にある在庫情報を更新していくことにする。したがって文6は受付係の内部のタスクとなり、倉庫係との依存関係は生じないと考える。このため表1では文6に対する記述はない。
受益者 |
提供者 |
依頼対象 |
依頼種別 |
文番号 |
---|---|---|---|---|
注文主 |
受付係 |
出庫依頼 |
タスク |
1 |
受付係 |
倉庫係 |
在庫 |
資源 |
2 |
受付係 |
発注係 |
不足発注書 |
資源 |
3 |
倉庫係 |
受付係 |
出庫指示 |
タスク |
4 |
受付係 |
倉庫係 |
出荷確認書 |
資源 |
5 |
注文主 |
受付係 |
納品書 |
資源 |
7 |
ユースケース図とSD図
図3に例で示したシナリオに対するユースケース図とSD図を対応付けて示した。
図3 ユースケース図とSD図の関係
ユースケースのアクタとSD図のアクタを直接対応付けることができる。また受付業務のユースケースを受付係アクタに対応付けている。
ここで、ユースケースにおける線の向きとSD図における線の矢印の向きが逆転していることに注意しよう。たとえば、納品書を受け取るのは注文主だが、納品書を提供するのは受付係だ。このためSD図では納品書の提供者に対して矢が向かうのである。
シーケンス図とSR図
商品販売に対するシーケンス図の例を図4に示す。また図4に対するSR図の例を図5に示す。図4では、出庫依頼画面、出庫指示、在庫が受け付け業務に対応する。これらはSR図では図5に示したように受付係の内部のタスクとして記述する。
図5 商品販売に対するSR図の例
コラボレーション図とSD図
図6では、クライアント・サーバ・モデルに対する単純なコラボレーション図をSD図と比較している。
図6 コラボレーション図とSD図の比較
クライアントがサーバに対してリクエストすると、サーバがクライアントに対してレスポンスを返すというモデルである。
SD図では、リクエストとレスポンスをタスクで記述している。ここでSD図にソフトゴールを記述していることに注意する。
すなわち、リクエストに対しては、リクエスト量を増大させたい。レスポンスに対しては正確なレスポンスを期待している。これらのソフトゴールは非機能要求の例である。
このようにSD図では、次の3つの問いを考えることができる。
- 【問1】誰(アクタ)に依存するのか
- 【問2】何(依存対象)に依存するのか
- 【問3】なぜ、どのように(ソフトゴール)依存するのか
今回はi*フレームワークを利用する上での図の書き方のポイントとUMLの図式と対比することでSD図やSR図の役割を紹介した。
■参考文献
- [1] i*フレームワーク、http://www.bcm.co.jp/site/youkyu/youkyu15.html
- [2] i*an agent-oriented modelling frame- work, http://www.cs.toronto.edu/km/istar/
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要