ロバストネス図を活用したシステム設計
![](https://thinkit.co.jp/sites/default/files/styles/main_image_730x/public/main_images/object_oriented_cover_4.jpg?itok=MY6yVQ0V)
ロバストネス図とは
今回のテーマは「ロバストネス図」です。ロバストネス図とは、ロバストネス分析を行った結果のアウトプットとなります。ロバストネス分析とは、スリーアミーゴス(ソフトウェアの分野における統一モデリング言語(UML)を開発した3人)の1人であるイヴァー・ヤコブソンが提唱した分析手法で、システムを「バウンダリ」「エンティティ」「コントロール」の3つに分けて分析し(これらについては後述します)、要求モデル(ドメインモデル、ユースケースモデル)をロバスト(堅牢、強靭)にします。
ロバストネス図はUMLで定義されている13種類のダイアグラムには入っていませんが、UMLのコミュニケーション図やコラボレーション図を簡略化した形で簡単に書くことができます。ロバストネス図を書くことで要件の振る舞いが整理され、実装すべき点を明確にできます。
ユースケースシナリオを作成する
ロバストネス図のインプットは要件定義フェーズで作成された成果物、いわゆる要件定義書などですが、ユースケースシナリオを作成し、ユースケースシナリオをインプットとしたほうがスムーズにロバストネス図を書くことができます。
ユースケースとは、アクター(人間や外部システム)が要件を達成するためのシステム内の振る舞いのことを指します。ユースケースシナリオとは、ユースケースの台本、つまり、アクターがシステムとやり取りする台本を表したものです。
ロバストネス図を書くためにはインプットなるユースケースシナリオが必要なので、ユースケースシナリオについて簡単に説明します。例えば、「顧客詳細画面を表示する」のユースケースシナリオは以下のようになります。
●ユースケース名:顧客詳細画面を表示する
●アクター名:オペレータ
●基本フロー
1. オペレータはログイン画面にIDとパスワードを入力する
2. システムは入力されたIDとパスワードの組み合わせが社員情報に登録されているか検証する
3. システムはメニュー画面を表示する
4. オペレータはメニュー画面にある「顧客一覧」ボタンを押下する
5. システムは顧客情報より顧客の一覧情報を取得し、顧客一覧画面を表示する
6. オペレータは顧客一覧より任意の顧客のリンクを押下する
7. システムは顧客情報より該当の顧客の詳細情報を取得し、顧客詳細画面を表示する
●代替フロー
2a. IDとパスワードの組み合わせが社員情報に登録されていない場合
2a1. システムは、ログインできない旨のメッセージをエラー画面に表示する
基本フローとは、ユースケースが成功した場合の処理の流れを記したものです。 メインフローや主シナリオなどとも言われます。代替フローとは、ユースケースが成功した場合の基本の流れ以外や、失敗に終わった場合の処理の流れを記したものです。副シナリオや例外などとも言われます。
また、ユースケースシナリオにはこの他に「事前条件」や「事後条件」という項目もあります。事前条件とは、ユースケースが実行される前に満たされていなければならない条件です。上記の例では「ログイン画面が表示されている」が事前条件と言えます。事後条件とは、ユースケース実行後に満たされていなければならない条件です。上記の例では「顧客一覧で選択した顧客の詳細画面が表示されている」が事後条件と言えます。
ロバストネス図を作成する
それでは、上記のユースケースシナリオをインプットにロバストネス図を作成していきましょう。冒頭でも少し触れましたが、ロバストネス図はバウンダリ、エンティティ、コントロールで構成されます。
バウンダリ、エンティティ、コントロールの各要素をユースケースシナリオの基本フローから探します。
基本フローの1に「オペレータはログイン画面にIDとパスワードを入力する」とあります。バウンダリは画面やボタン、リンク、帳票や他システムとのインタフェースなので「ログイン画面」がバウンダリだと分かります。アクターである「オペレータ」がバウンダリである「ログイン画面」と関連があるので、処理の流れを表す矢印をオペレータからログイン画面に向かって表します。
基本フローの2に「システムは入力されたIDとパスワードの組み合わせが社員情報に登録されているか検証する」とあります。エンティティは半永久的に管理するデータなので「社員情報」がエンティティだと分かります。
また、システムが行う処理を定義し、バウンダリとエンティティを繋ぐコントロールですが、「社員情報登録検証」がコントロールで「社員情報」と「社員情報登録検証」がシナリオから関連があることも分かります。バウンダリである「ログイン画面」とエンティティである「社員情報」を「社員情報登録検証」コントロールで繋ぎます。
なお、エンティティに向かう線が矢印になっていないのは、エンティティで行き止まりになるためです。
基本フローの3で「システムはメニュー画面を表示する」とあります。社員情報登録検証後にバウンダリである「メニュー画面」に進み、再びオペレータに戻って来ることが分かります。
ここまでの基本フロー1~3の要素と矢印である関連線をロバストネス図に記述すると以下のようになります。
このように、ユースケースシナリオのフローからバウンダリ、エンティティ、コントロールの各要素を洗い出し、処理の流れに向かって関連している要素に線を引いていきます。
残りの基本フロー4~7も同様のアプローチでロバストネス図に表すと、以下のようになります。
基本フローが出来たので、最後に下記の代替フローをロバストネス図に加えて完成させます。
2a. IDとパスワードの組み合わせが社員情報に登録されていない場合
2a1. システムは、ログインできない旨のメッセージをエラー画面に表示する
ロバストネス図のルール
ロバストネス図を書くにあたっては、以下のルールを遵守する必要があります。
- アクターはバウンダリのみ関連線(矢印)が引ける
- バウンダリはコントロールとアクターのみ関連線が引ける
- エンティティはコントロールのみ関連線が引ける
- コントロールはコントロール同士とバウンダリのみ関連線が引ける
アクターがコントロールに関連線を引いたり、バウンダリがエンティティに関連線を引いたりすることはできません。ご注意ください。
おわりに
いかがでしたか。今回はロバストネス図について解説しました。
ユースケースシナリオやドメインモデルなどに曖昧な箇所や不整合な点が残っていてもなかなか見つけることは難しいですが、ロバストネス図を描くことで様々な不備を発見できます。つまり、ロバストネス図によりシステムの要件を明確にし、文字通り堅牢な(ロバストネス)設計にできると言えます。ロバストネス図は簡単に描くことができるので、取り入れてみてはいかがでしょうか。
次回はJava8で取り入れられたラムダ式について解説します。