概論

スコープ

新業務分析が完了しているところから開始し、
外部設計、内部設計までが対象スコープです。

概念の理解

バウンダリの一つのイベントから呼び出すコントロールは一つだけ

バウンダリで発生するイベント(画面表示時、ボタンクリック等)から
呼び出されるコントロールは一つだけです。
もっと実装寄りにすると、
StrutsのActionクラスのメソッドから呼び出されるコントロールは一つ
のように読み替えることが出来ます。

コントロールはステートレス

コントロールには状態を持ちません。
コントロールが状態を持たないので、
コントロールを構成するユーザ機能も状態を持ちません。
バウンダリに一時的なセッションの状態を持ち、
エンティティ(リソース)に永続的な状態を持つだけです。

コントロールからコントロールは呼び出さない

コントロールから別のコントロールを呼び出してはいけません。
コントロールが汎用的な名前であったとしても、コントロールは汎用的ではありません。
そのコントロールは、同じ名前の汎用的なユーザ機能を呼び出しているだけで、
バウンダリ依存なものであることに変わりありません。

例外はRuntimeException系で

まずインターフェイスありきのため、宣言的例外は基本的に使えません。
また使う必要もありません。
但し、どのような例外が発生するか位は、実装クラスのJavadocに書いておきましょう。
例外のcatchは業務ロジックで行い、ログ出力やロールバックすることになります。
大抵はそのまま投げて、バウンダリに伝播させ、画面上のエラーメッセージに変換したりします。

ユーザ機能からのインターフェイスの抽出

ユーザ機能はその内容から自動的にインターフェイスに分類できます。
まず、その種類を考えます。

  • コントロールである:業務ロジックになります。
  • コントロールではない
    • エンティティに関連する:DAOになります。
    • エンティティに関連しない:補助ロジックになります。

次に個別のインターフェイスの識別として、

  • 業務ロジックの場合、バウンダリ毎に纏める。
  • 補助ロジックは、目的語で纏める。
  • DAOは、エンティティで纏める。

ということになります。
ここまでルール化されているので、
ユーザ機能抽出と同時にインターフェイスの抽出が出来るようになります。

クラス図なんて要らない

くーすにクラス図は要りません。
クラス図は、クラス間の静的構造の情報を記述するものですが、
少なくとも、業務ロジック、補助ロジックについては、
シーケンス図で表す以上の静的構造は存在しません。
あるとすれば、

  • バウンダリ層の作り(くーすのスコープ外)
  • エンティティやDTOのデータ構造

ぐらいです。
これらについては、必要であれば作って下さい。

プロセスフロー

プロセスフローを参照して下さい。
新業務フローを入力として、

  • ロバストネス分析
  • UIモック生成

を平行して実施。
ロバストネス図が出来たら

  • UI設計
  • ユーザ機能分析
  • ER分析

を平行して実施します。
これだけです。
後は、これらの成果物を使って実装・テストを行うだけです。

成果物

新業務フロー(外部仕様)

これは、くーすの成果物ではなく、要求する入力になります。
バウンダリのフローとして記述されます。
業務フローを参照して下さい。

UIモック(外部仕様)

UIのモックです。
HTMLなり、VBなり、作るシステムによって変わってきます。

ロバストネス図(外部仕様)

  • インターフェイスとなるバウンダリ
  • バウンダリが呼び出すコントロール
  • コントロールが関連するエンティティ

を纏めた図です。
ロバストネス図を参照して下さい。

UI仕様書(外部仕様)

UIの実装に必要な情報を纏めたものです。
UI仕様書(xls)を参照して下さい。

エンティティ仕様書(外部仕様)

エンティティの仕様書です。
オブジェクトとしての性質に加えて、テーブルの物理設計についての情報も含めます。
エンティティ仕様書(xls)を参照して下さい。

シナリオシーケンス(内部仕様)

UMLのシーケンス図で表したホワイトボックスシナリオです。
シナリオ毎に作られます。
シナリオシーケンス_ログイン
シナリオシーケンス_コメント一覧表示
シナリオシーケンス_コメントを登録する
を参照して下さい。

コンポーネント仕様書(内部仕様)

インターフェイスの仕様書です。
メソッド毎に事前条件、事後条件を記述します。 実装クラスについての仕様書は作りません。
実装クラスの仕様書が必要だと感じた場合は、
シナリオシーケンスで抽出されていないユーザ機能があるかもしれません。
コンポーネント仕様書(xls)を参照して下さい。

成果物のレビュー

  • 新業務フローの顧客レビュー
  • ロバストネス分析前のUIモック(ラフ版)の顧客レビュー
  • ロバストネス分析後のロバストネス図の顧客レビュー
  • 外部設計完了後の顧客レビュー

は、やった方が良いです。
他にも、内部設計完了後の顧客レビューをやることもあるかもしれません。
もちろん、それぞれ内部レビューはやっておくべきです。



トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2005-06-12 (日) 00:00:00 (4811d)