ロバストネス図の使い道
オブジェクト指向設計のダイアグラムの中で、特殊な使い方と思われる図法としてロバストネス図がある。
ラフなメモ書き。
【元ネタ】
ロバストネス図は素晴らしい - 檜山正幸のキマイラ飼育記
ユースケース駆動開発実践ガイドを読んでわかったこと - paz3のおもいつき
【1】僕が現場でロバストネス図を見たのは、RUPが標準の開発プロセスと称している案件だった。
そこでは、設計SEが、画面の処理やバッチ処理をロバストネス図で描いて、設計の意図や処理の流れを説明していて、そんな使い方があるのか、と理解した時がある。
設計SEが要件定義やアーキテクチャ設計で、画面の表示処理や更新ロジック、バッチ処理をプログラマに説明しようとする時、DFD(データフローダイアグラム)に近い絵をホワイトボードに描く時が多い。
処理とデータストアを矢印で結んで、このボタンを押すと、こんな処理が働いて、このテーブルに貯められるのだ、と。
でも、DFDは正直使いづらい。
機能が多かったり、複雑になるほど、DFDは絵として読みづらくなる。
オブジェクト指向設計の発想がないので、長い手続き型プログラムで実装されやすい。
かと言って、独自の記法を使うと、その絵は再利用しづらいし、説明する本人しか理解できない。
【2】ロバストネス図を使うオブジェクト指向設計として、ICONIXプロセスがある。
「ユースケース駆動開発実践ガイド」が一番有名だ。
「ユースケース駆動開発実践ガイド」では、ロバストネス図は、ユースケースである機能要求とクラス図・シーケンス図などの実装モデルの間をつなぐ「オブジェクトの絵」として定義される。
ロバストネス図の利点は、何といっても描きやすいことだ。
バウンダリ、コントローラ、エンティティの3つの要素は、○を書いて、ちょっと取っ手を付けたり、矢印をつけたり、棒を引くだけですぐに描ける。
ロバストネス図はホワイトボードに手書きで書く時に威力を発揮する。
ロバストネス図は素晴らしい - 檜山正幸のキマイラ飼育記に幾つかの利点が書かれている。
ロバストネス図なら、かなり多くのバウンダリ、コントローラ、エンティティを埋め込んでも、絵として違いが分かりやすい。
また、バウンダリ、コントローラ、エンティティに色付けできれば、より理解しやすくなる。
【3】僕の感想としては、ロバストネス図の描き方や使い方に幾つかの注意点があると思っている。
一つは、バウンダリは外部とのインターフェイスが定義であるなので、バウンダリの例として、画面や帳票だけでなく、バッチをキックするCronも相当すること。
この方法を採用できるので、ロバストネス図は特にバッチ処理の概要を示すのに都合が良い。
また、ロバストネス図は素晴らしい - 檜山正幸のキマイラ飼育記のように、外部システムとREST APIでやり取りしたり、SOA連携するやり取りをバウンダリ間のメッセージ送受信として表現する事もできる。
外部システム連携では、外部とやり取りするI/Fがとても重要だ。
外部システム連携の構造は、システムそのものをオブジェクトに見立てて、お互いにメッセージをやり取りしあうイメージで考えると分かりやすい。
この考え方は、システムオブシステムズ(System of Systems)の発想にもつながる。
ソフトウェアの品質を学びまくる:JSTQB-ALシラバスのお勉強 ─ 1.1~1.5
System of systems - Wikipedia, the free encyclopedia
もう一つは、コントローラがメソッドとして実装されること。
つまり、ロバストネス図で分析されたコントローラは、シーケンス図のオブジェクトで存在せず、どこかのクラスのメソッドとして実現される。
UMLを描こう - Vol.5 ICONIXロバストネス図 : アシアルブログのように、コントローラは「主語がシステムとなっている文の動詞」である。
したがって、「システムがすべきこと=実装すべき処理=コントローラ」になっている。
手続き型プログラムにはまりすぎている開発者がロバストネス図を描いてみると、コントローラを多用しすぎる傾向がある。
彼が書いたロバストネス図を絵としてみた場合、コントローラを多用した図は、バッチ処理のように、一つのデータをこねくり回すような処理の流れになりやすい。
つまり、一昔前の構造化設計の機能分解と同じ発想なのだ。
【4】ロバストネス図はホワイトボードで手書きで描くのが一番向いている。
僕は、astahのクラス図の中にロバストネス図を埋め込んで描く時が多い。
astahは設計のスケッチとして、とても使いやすいので重宝している。
| 固定リンク
「モデリング」カテゴリの記事
- 「システム開発・刷新のためのデータモデル大全」を読み直した感想~親子頻出アンチパターンは初心者モデラーに多い(2024.08.31)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- アーキテクチャ量子の考え方はソフトウェア工学に物理学アプローチを適用したアイデアではないか(2024.02.12)
「astahによるUMLモデリング」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- astahにタイミング図がサポートされた(2024.03.12)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
- パッケージ原則とクラス原則の違いは何なのか(2023.10.14)
コメント