皆さんこんにちは。最近、マインドマップなどの図から、GSN/D-Caseに変換するプラグイン、Something2GSNを公開しましたので、その紹介をしていこうと思います。astah* GSN/D-Caseで直接書かずにマインドマップなどの他の図から変換するとどんなことがうれしいのかなどが伝わればと思っています。

例題の想定

それでは、例を使って説明します。ホテルなどの客室によくある貴重品を入れておく金庫、セキュリティボックスの設計を考えてみましょう。ステークホルダー要求として次のようなSysMLの要求図を想定してみます。要求図はastah* SysMLだけでなく、astah* professionalにも入っています。

まず、要求1の「貴重品を安全に保管したい」は、利用者の基本的な要求で、ここでは必要な時に貴重品を出し入れできるという利便性と、セキュリティボックスの本来の目的である、第三者に貴重品が取り出せないという安全性とに分けておきます。さらに、セキュリティに関して相反する要求となりがちな、利用時の手間や憶えることなどの負担に関する要求と、セキュリティボックスを導入する宿泊施設からの要求として、コストに関する要求を仮定しておきます。

二つの設計候補案

これらの要求に対して、二つの設計案の候補があったとします。一つ目は、既にセキュリティボックスに実績のある会社で、自社の既存製品である物理的な鍵を使った設計案を提示してきました。次のようなシステム構成です。

二つ目は、テンキーを持つパスワードによる設計案です。

これらの設計に関して、どちらがよいか意思決定するために、それぞれの設計者に対して、設計案の妥当性を論証してもらうという状況を想定します。

物理鍵による設計案の妥当性の論証

まず、物理鍵による設計案を作った会社では、自社製品の妥当性についてまずマインドマップで検討してみました。

ただし、このままでは、パンフレットの宣伝文句のようにもみえ、上に述べた要求との関係を満たしているかどうかも明らかではありません。そこで、これをGSN/D-Caseの形に書き換えることにしましょう。一度マインドマップで記述してあれば、トピックの移動などは、マウスのドラッグアンドドロップでできます。次のようにGSN/D-Caseの構造を意識して書き換えたとします。各トピック名には、GSN/D-Caseにおけるノードの種類を接尾語として追記しておきます。

このように記述したマインドマップは、Something2GSNプラグインにより、瞬時にGSN/D-Caseに変換することができます。変換の仕方は、プラグイン紹介ページを参照してください。

このようにいつでも自動的に変換できれば、論証の検討はマインドマップで、論証の共有やプレゼンテーションはGSN/D-Caseで、という使い分けができます。まとめると、マインドマップでGSN/D-Caseを書くメリットの一つは次の通りです。

アイディアの探索や発散をマインドマップで行い、それをマインドマップ上でまとめることにより、素早くGSN/D-Caseが構築できます

パスワードによる設計案の妥当性の論証

パスワードによる設計案のリスク分析

さて、物理鍵案の方は、普段から使っている宣伝文句などからGSN/D-Caseを構築しましたが、パスワード案の方は、リスク分析に基づき論証を構築することとしました。ここでは前回紹介したミスユースケース手法を用いることと仮定します。まずは、分析の対象となるユースケース図を作成します。

この中で、利便性に関するユースケースは次の通りです。

貴重品を入れる
貴重品を取り出す

また、貴重品の安全性に関するユースケースは次の通りです。

パスワードを設定する
ドアを閉め、ロックする
正しいパスワードを入力し、ロックを解除する
貴重品を取り出す

ユースケース「貴重品を取り出す」は、いつでも自分の貴重品を取り出したいという利便性の要求に関するユースケースですが、同時に、利用者以外の第三者が貴重品を取り出せないという貴重品の安全性に関するユースケースでもあります。

つぎに、リスク分析をしていきましょう。具体的には、要求の達成を脅かすミスユースケースを書いてみます。つまり、これらのミスユースケースが成り立ってしまえば、要求を満足することができなくなるようなものです。

ここでは、他にもその要求を達成できなくなるミスユースケースがあるかもしれませんが、分析の結果これらがその全てであったと仮定して話を進めます。

さらに、これらのミスユースケースを引き起こす可能性のある、既にあるユースケースの正常シナリオからの逸脱を列挙してみます。

例えば、ミスユースケース「金庫の中にある貴重品が取り出せなくなる」ことを引き起こす、既存のユースケースの逸脱として、ユースケース「パスワードを記憶する」の正常シナリオを逸脱するシナリオ「パスワードを忘れる」が考えられます。もちろん、他にも考えられるかもしれませんが、この説明では先ほどと同様に、このようなミスユースケースが網羅的に抽出できたと仮定して話しを進めます。

さて、これらのミスユースケースに対して対応策を考えます。

本来であれば、これら対応策に対しても、その正常シナリオの逸脱が要求の達成を脅かす可能性を検討しなければなりませんが、ここではそれらをした上で得られたものが上のユースケース図であると仮定します。ミスユースケースがあると少し見にくいので、これらの検討の結果得られたユースケースだけ抜き出したユースケース図を書いておきます。

このユースケースでは、それぞれどこから出てきたのかをコメントしています。例えば、「ホテル従業員に連絡し、パスワードを初期化してもらう」などは、利便性に関する要求の阻害要因の対策として出てきたものでした。

さて、ここまでで、要求に対する実現方法などの方針も固まってきましたので、その方針を反映したパスワード案に対するより詳細な要求図を書いてみましょう。まずは、一番最初の共通要求を再利用して、パスワード案の要求の記述のスタート地点を作成しておきます。

ここでは、要求1.1(P)、1.2(P)、2(P)、3(P)はそれぞれ共通要求を再利用したもので、パスワード案のものであることを表すために(P)を付けています。次に、リスク分析などで検討してきたこれら要求の実現方法も反映した、より詳細な要求図を記述してみます。

ここまでのミスユースケース図での分析、分析の結果得られた必要なユースケースが追加されたユースケース図、それらの結果を反映した上の要求図により、設計者の頭の中では、パスワード案が妥当であるという主張ができてきていることが想像できると思います。。これを、第三者に説明するための方法論がGSN/D-Caseです。まずは、同じastah* SysML上のマインドマップによってGSN/D-Caseによりその主張を可視化してみましょう。

少し字が小さくなってしまったかもしれませんが、クリックすれば拡大します。物理鍵案の時と同じように、Something2GSNプラグインにより、astah* GSNで読める形に変換してみましょう。

設計案が妥当であることを示すためには、一般にはそれが実際に実装できる見込みがあることも示す必要があります。上のGSN/D-Case図では、Sn7、Sn8、Sn12、Sn13のソリューションが対応します。これらのソリューションで求められるテストケースの情報も追加した、更新された要求図を示しておきます。

SysMLの要求図やユースケース図、ユースケース図を使ったミスユースケースによるリスク分析の結果においては、必ずしもその設計の意図や、追加の機能が導出された背景や経緯などについて、rationalなどのコメントを用いて一部は表現することはできますが、その全てを明示的は記述できていません。GSN/D-Caseによる論証で表現することにより、それらの関係が有機的かつ統一的に、一枚の絵で説明できるところにメリットがあります。さらに、設計モデルを記述したUMLやSysMLの各モデル要素に関連付けが可能なマインドマップで、そのような論証を書いておけば、論証の構造から、リンク機能などにより直接エビデンスとなるモデル図やモデル要素を参照することが可能になるだけでなく、モデルに変更があった場合でも、論証への影響分析がやりやすくなることが期待できます。GSN/D-Caseは、ノードの形により、論証における役割（主張であったり、戦略であったり、エビデンスであったり）が視覚的に分かりやすく表現できますので、論証の共有などが必要になったときには、GSN/D-Caseでの表現が効果的です。ここで説明した、マインドマップでGSN/D-Caseを書くメリットは次の通りです。

設計モデルをUML/SysMLなどで記述し、その論証をマインドマップで管理しておくことにより、設計モデルと論証とが有機的なつながりを保ったまま管理できます。

ちなみに、Something2GSNは、マインドマップのほかにも、オブジェクト図やブロック図などからもGSN/D-Caseを生成することができます。こちらはどちらかというと、astah* professionalやastah* SysML側で、そのモデルを活用して論証を自動構築するプラグインなどを開発する際に中間成果物として利用することを想定しています。この場合でも上のメリットは享受できます。

いかがでしたでしょうか。設計モデルの意図や背景などはUML/SysMLだけではなかなか表現するのが難しい場合もあると思います。そのときはぜひGSN/D-Caseを検討してみてください。