ひがやすを技術ブログ

電通国際情報サービスのプログラマ

ダイコン時代の設計手法 - 外部設計に必要なもの

ダイコンの守備範囲は、外部設計以降なのですが、外部設計をするために
最低これだけは必要になるだろうと思うものを書いておきます。
逆にいうとこれらが決まらずに外部設計にはいっても、
結局待ち状態に入り、プロジェクトは迷走をし始めるでしょう。
デスマはこのようにしてはじまる!


新業務フロー
これだけあれば、外部設計をはじめられます。
新業務フローとは今回開発するシステムにおける業務フローのことです。
新業務フローでは、アクター・バウンダリ
明らかになっていればそれでいいと思います。


バウンダリとはシステムの外部とのインターフェースのことで、
画面や帳票のことです。


今回、業務フローのフォーマットは顧客が理解できるものなら何でも良いと
思います。

ダイコン時代の設計手法 - 外部設計

外部設計のインプットデータは、業務フローです。
業務フローごとに外部設計を行います。
ユーザにレビューしてもらえるのは、外部設計まで。
気合を入れます(笑)。


業務フローの中で、既にバウンダリが洗い出されているはずなので、
それらをもとにロバストネス分析を行います。
ロバストネス分析は、次のように行います。


バウンダリごとにUI仕様書とモックを作成します。
UI仕様書には項目説明をつけます。
項目とテーブルのカラムのマッピングも行います。
足りないカラムがあればエンティティ仕様書に追加します。
Validationもこの段階でつめます。


コントロールとはVO(動詞 + 目的語)で書き表されるもので、
「〜を〜する」という1センテンスになります。
動詞は現在形の能動態です。
画面で起こるイベントごとにコントロールを定義します。
コントロールがすべて洗い出されていることを確認したら、
データのマッピングとValidation以外にやらなければいけない処理が
あるのかを確認します。
あれば、補足説明書(?)に記述しておきます。


バウンダリの分析をしながら、エンティティ(テーブル)の業務項目(カラム)を
エンティティ仕様書に追加していきます。
また、エンティティ間の関連もつめます。


これで、業務フローがBCEにマッピングされました。


UI層のコントローラは、バウンダリに含めることにしました。
id:akonさん、id:habuakihiroさん。
そのほうが分かりやすそうなので。

ダイコン時代の設計手法 - 内部設計

バウンダリに関しては、UI層のフレームワークに合わせた
内部設計書を作成します。
とりあえず、必要だと思われるのは、UI層のコントローラ
(例えばStrutsのAction)のコンポーネント定義です。
UI層のコントローラは、ロジック層のクラス(interface)に依存します。
依存関係もコンポーネント仕様書に記述します。
ロジック層とは、以前サービス層と呼んでいた層です。
SOAの絡みでややこしくなりそうなので、呼び方を変えました。m(_ _)m


コントロールの内部設計が最も重要なポイントです。
コントロールの処理を

  • 業務固有の部分
  • 永続化に関する部分
  • 共通部分

に分解します。
業務固有の部分は、ロジック層のコンポーネントで実装します。
ロジック層のコンポーネントバウンダリごとに作成します。
例えば、従業員管理初期ページに

  • 新規入力を行う
  • 検索を行う

という2つのコントロールがあった場合、
従業員管理初期Logicクラスに

  • 新規入力を行う
  • 検索を行う

というコントロールに1:1に対応するメソッドが用意され
業務固有の部分を実装することになります。
このコントロールに対応したメソッドはバウンダリから呼び出されます。


コンポーネント仕様書では、メソッドごとに事前条件・事後条件を記述します。
事前条件とは、メソッドを呼び出すために必要な引数の条件です。
事後条件には、引数として何をもらったらどういう結果を返すのかという
テスト仕様を記述します。
開発者は仕様書を書きながらテスト内容も同時に考えているので、
何を実装しなければいけないのかが明確になります。
またレビュー時にテスト仕様も確認できるのでレビューの質も上がります。


永続化に関する処理は、永続化層のDaoで実装されます。
Daoはエンティティごとに作成します。
動的なSQLの生成が必要な場合、その実装は永続化層で行います。
S2Daoの場合は特に実装の必要はありません。
条件によって見に行くエンティティが変わるような
エンティティをまたがる動的なSQLは、ロジック層でどのエンティティが
対象なのかの判定を行い、エンティティが決まった後は、
そのエンティティのDaoに処理を任せます。


共通処理は共通コンポーネントまたは、staticなユーティリティメソッドで
実装します。


エンティティは、エンティティ仕様書より自動生成されるので
内部設計は特に必要ありません。