要件や行うべきことが複雑すぎる時は処理内容をドキュメントに起こす手間がいきなりコードを書き出してつまづく時間よりもお得になりやすいです。ドキュメントは自然言語で書かれているため、プログラミング言語よりも融通が効きやすくよりわかりやすい形へ書き直すことも楽です。体感どこにどの処理を書こうかと迷ったりする程に取り扱う対象が多いなら、コードに近いドキュメントとしてて画面と操作対象と操作内容を図に起こすロバストネス図が役に立ちます。
ロバストネス図はロバストネス分析を図示したものです。ロバストネス分析はシステムで取り扱うものを次の三つに分けて整理する方法です。
- 画面、フォーム、ボタンなどといったインターフェース（GUIなどで使うインターフェース）を表すバウンダリー
- データベースを表すエンティティ
- 処理内容を表すコントロール
ルールとしてはコントロールを介さずにバウンダリー同士、エンティティ同士、バウンダリーとエンティティをつなげない、ということです（処理をつなげないのが大事なので共通するコメントなどはそれとわかるように書いておけば大丈夫です）。
大雑把にはこれだけです。API サーバならば API がバウンダリー、データベースのテーブルや永続化しているファイルがエンティティ、プログラム内のメソッドや関数がコントロールな感じです。
これを各所の関係をつなげていくのがロバストネス分析です。この分析の内容を図示するのがロバストネス図で大体、次の様になります。
細部はコメントで補えば良いのでそのあたりは自由です。
これを PlantUML で書くことができます。主に使う機能は次リンクの配置図の機能です。この中にある boundary, entity, control をそのまま使います。
配置図の構文と機能
図のソースコードが次です。
@startuml
'top to bottom direction
left to right direction
package ページ{
boundary 送信ボタン as submit
package フォーム as form{
boundary 名前入力欄 as nameInput
boundary パスワード入力欄 as passwordInput
boundary "パスワード（確認）入力欄" as passwordConfirmInput
boundary エラーメッセージ表示欄 as errors
}
}
package JavaScript as JS {
entity 名前 as name
entity パスワード as password
entity "パスワード（確認）" as passwordConfirm
control 入力された名前を反映 as bindName
nameInput-->bindName
name<--bindName
control 入力されたパスワードを反映 as bindPass
passwordInput-->bindPass
password<--bindPass
control "入力されたパスワード（確認）を反映" as bindPassC
passwordConfirmInput-->bindPassC
passwordConfirm<--bindPassC
control エラーチェック as errorCheck
submit-->errorCheck
errorCheck-->errors: エラー内容を渡す
errorCheck-->name: 取得
errorCheck-->password: 取得
errorCheck-->passwordConfirm: 取得
errorCheck-left->Server: 入力内容を送信
}
package サーバ as Server {
}
@enduml
例の様に雑に書くとかなり見難いので何が何でもパッケージ化を厳密にすることになります。見やすくなった状態のパッケージ単位でディレクトリなりクラスなりコンポーネントなりにコードに落とし込むと結構整理されたコードになります。
