ダイコン時代の設計手法 - ロバストネス分析
ユースケースが正しいことを検証する、あるいは
さらに詳細な設計をする前の準備として、
ロバストネス分析は役に立つと思います。
ロバストネス分析とはユースケースの登場人物を
バウンダリ、コントロール、エンティティに分類して
その関連を分析するものです。
バウンダリはアクターとのインターフェースで画面や帳票などを指します。
コントロールはユースケースが提供するサービスです。
エンティティはシステムで管理されるデータです。
ロバストネス分析を終えるとバウンダリから画面遷移図を作成できます。
エンティティは、ER分析のもとねたになります。
コントロールは、さらにUI層のコントローラ、サービス層、永続化層に
ブレークダウンします。
コントロールの分析がロジックをどこに置くのかにつながってきます。
ダイコン時代の設計手法 - 作業待ちの回避
ここでいう作業待ちとは、前工程が決まらないために
後工程の人が遊んでしまう状態のことです。
作業待ちが起こると工数的なダメージがあるばかりではなく、
開発者のモチベーションも下げてしまいます。
仕様と実装を明確に分離し、仕様を先につめるようにしておけば、
実装が追いつかなくても、モックで作業を進められるので、
実装が追いつかないことによる作業待ちは回避できます。
残りは、ユーザや分析者が仕様を決められない場合でしょうか。
ユーザや分析者は、当然間違ったものは作りたくないので、
いろいろ悩み意思決定が遅れます。確かに業務ロジックの中身を
Fixさせるのは時間のかかることです。
しかし、業務ロジックのインターフェースを決めるだけならそんなに
時間はかからないと思います。
インターフェースさえ決まれば、作業待ちは回避できます。
ユーザや分析者にいきなり細部までつめてもらうのではなく、
先ずはインターフェースを決めてもらってから、後から詳細を決めて
もらうようにすれば、たいていの作業待ちは回避できるのではないでしょうか。
ダイコン時代のオブジェクト指向
従来のオブジェクト指向では、クラス・継承・多態性などを学んでも、
結局、実プロジェクトにどうやって活かしたらよいのか、
よくわからないというのが実情だったのではないでしょうか。
デザインパターンなども実際のコードに生かせるのは、
業務システムがターゲットだと皆無に近いのではないでしょうか。
これまでオブジェクト指向が生かされてきたのは、きっと
フレームワーク的な部分でしょう。
ダイコン時代のオブジェクト指向は、業務システムがターゲットです。
次の考えにもとづいています。
- 仕様と実装を分離する。
- 役割分担を明確にする。
- 最も結びつきの強いクラスに役割を担当させる。
1によって、並行開発が可能になり、納期の短縮が期待できます。
作業待ちも減るでしょう。
モックによるテストがしやすくなるので、自動テストのカバレッジが
増え品質も向上します。
UI層、サービス層、永続化層、エンティティ層に明確に役割分担することも
特徴的なところです。
従来のオブジェクト指向で最も難しいのはクラスの抽出ではないでしょうか。
現実世界を反映させたものではないことは間違いないところですが、
定石的なものが確立されていないので、四苦八苦していた部分だと思います。
ダイコン時代のオブジェクト指向では、クラスの抽出に明確な指針を
打ち出します。
最初にユースケースをロバストネス分析して、バウンダリ、コントロール、
エンティティを抽出します。
エンティティはER分析を経てエンティティ層のオブジェクトにマッピングされます。
コントロールは次のようなクラスにマッピングされます。
クラスの抽出は終わっているので、残りは、
- 各クラスに役割に応じた責務を割り当てる
- クラス間の依存関係を定義する
ことです。
役割が明確なので、責務を割り当てるのはそれほど難しくないでしょう。
クラス間の依存関係はダイコン定義に反映されます。
UI層のコントローラはサービス層との依存関係を持ち、
サービス層は永続化層と依存関係を持ち、
永続化層はO/Rマッピングのフレームワークと依存関係を持つというように
依存関係のパターンもあらかじめ決まってます。
ダイコン時代は、オブジェクト指向もシンプルかつ具体的な指針に基づいて
行うことができます。
