ダイコン時代の外部設計 - 業務フローをロバストネス分析

外部設計で業務フローをロバストネス分析して、
画面設計書とエンティティ定義書に落としていく開発手法を
実践投入。
しかも、オフショアですよ、あなた。
内部設計はオフショア。
やれ、要求モデル、概念モデル、仕様モデル、実装モデルだの
いろんなモデルを作ってる余裕なんてありません。
あんまり必要だとも思わないけど。
これまでのOOって重厚すぎる。
開発を楽にするために生まれたはずのOOに振り回されるような
気がしませんか。
これからは、Agile OOですよ。
ユースケース記述・クラス図など端折りましょう。


ここでいっている業務フローとは関連のある業務の流れをまとめたもので、
粒度としては、要約レベルのユースケース、FDDなら主要ユーザ機能群です。
そこから、まず最初にバウンダリ(画面・帳票など)を抽出します。
次にバウンダリからコントロールを抽出します。
コントロールは、システムが提供するサービスのことで、
VO(〜を〜する)で記述します。Vは現在形の能動態です。
なんか難しいような気がすると思いますが、
リンクやボタンのクリックなどのイベントが1つのコントロールになると
考えればわかりやすいと思います。
次にコントロールがアクセスするデータをエンティティとして抽出します。
ロバストネス分析はこれだけ、楽勝ですね。


画面設計書は、モックといっしょに作成します。
モックで画面の項目や動きを確認できたら、画面設計書に貼り付けます。
画面設計書では、項目とエンティティのカラムのマッピングを記述します。
同時にエンティティ定義書にもカラムの情報を記述します。
名詞抽出法なんて忘れてしまいましょう。
項目のバリデーションロジックも記述します。


コントロールはCRC(Class-Responsibility-collaborator)分析します。
バウンダリごとにコントロールを1つのクラスにまとめます。
このクラスをLogicのクラスと呼ぶことにします。
コントロールがもっとも粒度の荒いResponsibilityになります。
エンティティごとにDaoを作成します。Logicに提供する
Responsibilityを追加していきます。
LogicにもcollaboratorにDaoを追加します。
複雑なResponsibilityがある場合は、補足説明書に記述します。
このCRCが内部設計以降のinterface,ダイコン定義のインプットになります。


外部設計もかなりシンプルでも、でも必要なことは定義されていると思います。
ダイコン時代のOOの特徴は、ロバストネス分析の結果から自動的に
クラスが抽出できる点だと思います。
OOの最も難解だったクラス抽出が簡単にできるのです。
なんだかパズルのピースがあってきた感じがする。