ホーム >  要求工学 >  2008年1月号 >  第39回：アクタ関係分析 

前回、要求の曖昧さとアクタに着目して要求の曖昧さを検出する手法を紹介した。今回はアクタ間の依存関係を分析するにはどうすればいいのか？ということについて考えよう。

さらにアクタ関係分析に基づいて、代表的なゴール指向分析手法であるi*フレームワークの戦略依存図を作成する手法を紹介しよう。

アクタ関係

前回述べたように、情報システムを取り巻く関係者としてのアクタは多様である。情報システムの利用者や情報システムそのものもアクタであると考えることもできる。このようなアクタ間の関係を分析するにはどうしたらいいのだろうか？

以下では、アクタ間の関係を表で分析する簡単な方法を紹介する。ここで扱うアクタ間の関係は、情報システムや人間活動で必要となる「サービスの依頼と提供」についての期待という基本的な関係である。

アクタは、あるサービスの提供者と受益者という２つの側面を持つと考える。そうすると、異なるアクタ間にどのようなサービスの可能性があるか、あるいはまた、そのサービスの提供者と受益者はどちらのアクタなのかということを分析することができることが分かるだろう。

また、アクタ自身はなぜアクタ関係を必要とするのだろうか、ということについても分析する必要があることに気づくだろう。つまりアクタの目標である。アクタが何か達成したい目標を持つから、そのために他のアクタに対してサービスを提供したり、他のアクタからサービスを受けたりするのである。換言すると、アクタのフロントルームとバックルームを識別するということである。アクタが最も強みとしていて、自分でやるべき価値のある仕事がフロントルームである。これに対して、必ずしも自分でやらなければならないことではない仕事がバックルームである。バックルームの仕事は、それを得意とする他のアクタに依頼すればいい。これは企業が何に集中し、何を外部に委託するかという問題と同じである。アクタがすべきことと、他のアクタに依頼することを明確に定義することが重要だ。

つまり、アクタの目標を明らかにすることは、他のアクタとの関係を明らかにすることと表裏一体になっているということが分かる。

アクタ関係の分析例

アクタ関係に着目することで、どんな要求記述の曖昧さが指摘できるかを具体的に示すために、次のような要求記述のアクタ関係をレビュしてみよう。

【要求記述例】商品販売の販売管理サービスのシナリオ

• （R1）顧客が出庫を依頼する
• （R2）在庫を確認する
• （R3）在庫不足なら不足品を発注係に発注する
• （R4）在庫があれば倉庫係に出庫を指示する
• （R5）倉庫係が出荷を確認する
• （R6）在庫を更新する
• （R7）顧客に請求書と納品書を提示する
• （R8）顧客が料金を支払う

【アクタ関係分析例】

R1：顧客がアクタである。しかし、出庫を依頼するためのアクタが不明である。この不明なアクタをシステムだと仮定する。R1から次の２つのアクタを抽出した。

A1：顧客

A2：システム

また、次のアクタ関係を抽出した。

D1：出庫を依頼する（受益者：A2、提供者：A1）

R2：誰が誰に「在庫を確認する」かが不明である。在庫は倉庫にあると考えて、倉庫係をアクタとすると、システムが倉庫係に在庫を確認することになる。R2から新たに次のアクタを抽出した。

A3：倉庫係

また、次のアクタ関係を抽出した。

D2：在庫を確認する（受益者：A2、提供者：A3）。

R3：発注係が新たなアクタである。不足品を発注するアクタが不明なので、システムであると仮定する。R3から新たに次のアクタを抽出した。

A4：発注係

また、次のアクタ関係を抽出した。

D3：不足品発注を指示する（受益者：A4、提供者：A2）。

R4：出庫を指示するアクタが不明であるため、やはりシステムであると仮定する。R4には新たなアクタは出現していない。次のアクタ関係を抽出する。

D4：出庫を指示する（受益者：A3、提供者：A2）。

R5：新たなアクタは登場しない。また、アクタ間の関係も登場しない。倉庫係の仕事として次を抽出する。

D5：出荷を確認する（A3）。

R6：在庫を更新するのは在庫を持つ倉庫係であると考える。この場合にもアクタ間の関係は登場しない。倉庫係の仕事として次を抽出する。

D6：在庫を更新する（A3）。

R7：請求書と納品書を提示するアクタが不明である.請求書と納品書は品物が配達されないと顧客に提示できないから、たとえば配達係が顧客にこれらを提示すると仮定する。新たなアクタとして配達係を抽出する。

A5：配達係

また、次の関係を抽出する。

D7：請求書を提示する（受益者：A1、提供者：A5）。

D8：納品書を提示する（受益者：A1、提供者：A5）。

R8：顧客が料金を支払う対象としてのアクタが不明であるため、アクタとして出納係を抽出する。

A6：出納係

また、次の関係を抽出する。

D9：料金を支払う（受益者：A6、提供者：A1）。

この結果を表で整理すると、表1のようになり、この表をアクタ関係表と呼ぶ。

アクタ関係表の構成

アクタ関係表の構成要素は、次の３つである。

対角要素

表のI行I列要素には、アクタ自身の達成すべき目標を記入する。

たとえば、倉庫係の目標「出荷を確認する」ことが、表1の倉庫係の行と列に対応する升目に記入されている。

上三角要素

表のI行J列要素（I＜J）には、受益者側アクタIが提供者側アクタJに期待するサービスを記入する。

たとえば、システムが倉庫係に期待することとして「在庫を確認する」ことが、システムの行と倉庫係の列が交差する升目に記入されている。

下三角要素

表のI行J列要素（J＜I）には、提供者側アクタIが受益者側アクタJから期待されるサービスを記入する。この場合、受益者と提供者が上三角要素と逆転していることに注意する。

たとえば、倉庫係がシステムに期待することとして「出庫を指示する」ことが、倉庫の行とシステムの列が交差する升目に記入されている。

アクタ関係表を用いたレビュ

さて、このようなアクタ関係表を見て何が分かるだろうか？

まず、アクタ間の関係が疎であることに気づくのではないだろうか？

例題の要求記述だけだとなんとなく機能が列挙されていていいような気になるが、アクタ関係表を見ると、もっと必要な関係があるのではないかと心配になりそうである。

実はこれが重要なポイントだ。アクタ関係表を記述することで、アクタやアクタ間の依存関係の漏れを調べるのに役立つ。

たとえば、出納係の列が何も記入されていない。これは出納係が顧客から徴収した金額をどこで管理するのか不明であることを意味する。

一方、配達係の行にも何も記入がない。これは配達係が他のアクタに期待するサービスが抜けていることを示している。たとえば、倉庫係がシステムから出庫を指示された後で配達係りに配達を指示することが抜けているのではないだろうか？もしそうなら、配達係の行と倉庫係の列が交差する升目に「配達を指示する」という記述が必要となる。

また各アクタに対応する対角行列に記述が抜けている。これはアクタがなぜ必要なのか、アクタの活動の達成目標が漏れていることを示している。

このようにアクタ関係表を記述することで、アクタやアクタ間の関係に由来する要求の漏れを防ぐことができるはずである。

アクタ関係表とi*フレームワーク

実は、アクタ関係表は、本連載でもたびたび紹介した代表的なゴール指向要求工学手法であるi*フレームワークの戦略依存図（Strategic Dependency Diagram、SD図）に変換できる。

直感的に言えば、アクタ関係表のアクタをSD図のアクタとし、アクタ関係表の升目の中の記述をSD図のソフトゴールに対応付ければいい。

たとえば、表１のアクタ関係表が図1のSD図に対応することは明らかであろう。詳細な変換手続きについては、文献[4]を参考にしていただきたい。なお、文献ではアクタ関係表のことをアクタ関係行列ARM（Actor Relationship Matrix）と呼んでいる。アクタ関係表は筆者らがi*フレームワークのゴール図を作成する上で様々な課題があることに気づいたことから考案した方法である。つまり、ゴール図を構成する上で本質的な要素だけを抽出して、それを特別な図ではなく、誰でも知っている表を用いて表現したのである。なおi*フレームワークの課題の詳細については文献[3]を参考にしていただきたい。

表を用いることによって、アクタとアクタ間の依存関係についての網羅的なレビュが可能になっただけでなく、抽出作業を容易化できるようになった点は大きな副産物であったと思う。

まとめ

今回は、要求の曖昧さと要求レビュに役立つアクタ関係表について説明した。前回、前々回も指摘したとおり、要求仕様の曖昧さについては古くから問題だとして指摘されてはいるが、現実には強力なモデリング手法が現場レベルで浸透していない。しかし、今回紹介したような手法であれば、誰でもすぐに使おうと思えば使うことができる簡単で強力な手法である。今後もこのような現実的なアプローチによって、要求の曖昧さを低減する手法の開発が望まれる。

たとえば、前回紹介した要求記述の構成要素が実はアクタ関係に対応している。前回紹介した方法では、要求をアクタ、アクタの状況、イベント、入力、動作、アクタに及ぼす結果に基づいて明確に記述する。これは、アクタ関係を具体化しているのと同じである。つまりアクタとアクタ間の関係を分析できれば、アクタが他のアクタに対する期待としての要求が、どんな状況で、どのようなイベントを契機として発生し、そのイベントではどのような入力があり、それに基づいてどのような処理が必要となるのか？その結果として何が出力され、アクタの状況はどのように変化するのか？これらを明確に記述することができれば、要求の漏れを防ぐことができるようになる。アクタやアクタ間の関係に漏れがあれば、必要な要求を抽出できないことは明らかである。現在、筆者らはこのような観点から要求定義・管理方法の研究を進めている。

先日、名古屋で開催されたソフトウェア工学の国際会議（APSEC）[5]で何人かの研究者と話したが、要求工学の分野で、要求レビュの研究がほとんどないので、新たにこの分野の研究を立ち上げるべきだということで意見が一致した。アクタ関係に着目した要求レビュの研究が進展することを期待している。

---

■参考文献

• [1] i*homepage：http://www.cs.toronto.edu/km/istar/
• [2] 山本修一郎 著：～ゴール指向による!!～
  　 システム要求管理技法、ソフトリサーチセンター、2007
• [3] 井部己文、山本修一郎：利用シーンを考慮した、iスターフレームワークの適用上の課題、第157回ソフトウェア工学研究発表会、2007
• [4] 井部己文、山本修一郎、佐藤友合子：アクタ関係行列を用いたiスターフレームワーク作成方法の提案、第158回ソフトウェア工学研究発表会、2007
• [5] http://apsec2007.fuka.info.waseda.ac.jp/