![[PukiWiki]](image/seasar.png "[PukiWiki]")
ダイコン時代の設計手法くーすのまとめです。
このページの趣旨は、
読者がくーすを理解して、適用可能にするための最低限の情報
をまとめることです。
なので、議論の経緯や深い所は、
を参照してもらうことになると思います。
但し、このページだけではくーすを理解できないとか手が動かないとなるとまずいので、
分からない、情報が足りないところはどんどん指摘して下さい。m(_ _)m
更新履歴
8/5
8/5 23:35
8/6
8/6 17:20
8/9 00:30
8/9 04:50
8/18 17:50
8/19 23:20
8/19 23:40
ダイコン時代のシステム開発を効率化するための設計方法論です。
でもダイコンを使わなくてもくーすは使えます。
分類としては、IDD(Interface Driven Development)に当たるもので、
固有名として、くーす(古酒のこと、Kusu)と呼びます。
業務系のシステム開発を安全に効率的に行いたいと思ってる方。
ダイコンについてある程度理解していることが望ましいですが、必須ではありません。
ゲーム開発や、自然科学系のシステム開発などには向かないかも知れません。
新業務分析が完了しているところから開始し、
外部設計、内部設計までが対象スコープです。
バウンダリで発生するイベント(画面表示時、ボタンクリック等)から
呼び出されるコントロールは一つだけです。
もっと実装寄りにすると、
StrutsのActionクラスのメソッドから呼び出されるコントロールは一つ
のように読み替えることが出来ます。
コントロールには状態を持ちません。
コントロールが状態を持たないので、
コントロールを構成するユーザ機能も状態を持ちません。
バウンダリに一時的なセッションの状態を持ち、
エンティティ(リソース)に永続的な状態を持つだけです。
コントロールから別のコントロールを呼び出してはいけません。
コントロールが汎用的な名前であったとしても、コントロールは汎用的ではありません。
そのコントロールは、同じ名前の汎用的なユーザ機能を呼び出しているだけで、
バウンダリ依存なものであることに変わりありません。
まずインターフェイスありきのため、宣言的例外は基本的に使えません。
また使う必要もありません。
但し、どのような例外が発生するか位は、実装クラスのJavadocに書いておきましょう。
例外のcatchは業務ロジックで行い、ログ出力やロールバックすることになります。
大抵はそのまま投げて、バウンダリに伝播させ、画面上のエラーメッセージに変換したりします。
ユーザ機能はその内容から自動的にインターフェイスに分類できます。
まず、その種類を考えます。
次に個別のインターフェイスの識別として、
ということになります。
ここまでルール化されているので、
ユーザ機能抽出と同時にインターフェイスの抽出が出来るようになります。
くーすにクラス図は要りません。
クラス図は、クラス間の静的構造の情報を記述するものですが、
少なくとも、業務ロジック、補助ロジックについては、
シーケンス図で表す以上の静的構造は存在しません。
あるとすれば、
ぐらいです。
これらについては、必要であれば作って下さい。
プロセスフローを参照して下さい。
新業務フローを入力として、
を平行して実施。
ロバストネス図が出来たら
を平行して実施します。
これだけです。
後は、これらの成果物を使って実装・テストを行うだけです。
これは、くーすの成果物ではなく、要求する入力になります。
バウンダリのフローとして記述されます。
業務フローを参照して下さい。
UIのモックです。
HTMLなり、VBなり、作るシステムによって変わってきます。
を纏めた図です。
ロバストネス図を参照して下さい。
UIの実装に必要な情報を纏めたものです。
UI仕様書(xls)を参照して下さい。
エンティティの仕様書です。
オブジェクトとしての性質に加えて、テーブルの物理設計についての情報も含めます。
エンティティ仕様書(xls)を参照して下さい。
UMLのシーケンス図で表したホワイトボックスシナリオです。
シナリオ毎に作られます。
シナリオシーケンス_ログイン
シナリオシーケンス_コメント一覧表示
シナリオシーケンス_コメントを登録する
を参照して下さい。
インターフェイスの仕様書です。
メソッド毎に事前条件、事後条件を記述します。
実装クラスについての仕様書は作りません。
実装クラスの仕様書が必要だと感じた場合は、
シナリオシーケンスで抽出されていないユーザ機能があるかもしれません。
コンポーネント仕様書(xls)を参照して下さい。
は、やった方が良いです。
他にも、内部設計完了後の顧客レビューをやることもあるかもしれません。
もちろん、それぞれ内部レビューはやっておくべきです。
新業務フローが画面遷移に当たるので、そこからUIモックを作ることになります。
特に難しいことはありません。
ただし、UIモックはできるだけ早い段階で顧客レビューした方が良いです。
UIモックでのフィードバック(要求漏れの発現)の遅れは、
質、量ともに重要で、発現が早くなる分リスクが減ります。
タイミングとしては、新業務フローが確定しないまでもある程度固まってきたら、
同時にUIモックの作成をはじめた方が良いです。
ロバストネス分析前にラフな画面イメージをレビューしてもらう感じです。
このとき、「開発途中のものなので・・・」というフォローは使い方を気を付けましょう。
顧客が、
(本当はナビとしてこういう情報が必要だけど、それぐらいわかってるだろうし、開発中だから含まれてないんだろうな)
というような思考になって要求が出てこないことがあります。
バウンダリのイベント毎に、
という観点でコントロールを抽出し、
コントロールが
ということでエンティティを抽出します。
ロバストネス分析を行う単位は、シナリオ毎が目安になります。
但し、登録、変更、削除等が極めて近いフローで行われいたり、
個々のシナリオのフローが短くて、
分けるよりも一つに纏めた方が楽で分かりやすいというような場合は、
複数シナリオを一枚にしても問題ありません。
UIモックとロバストネス図のバウンダリとコントロールから、
項目とデータの関連と入力チェックを中心に纏める。
エンティティ毎にエンティティの属性とその特性を纏める。
属性の抽出は、
を集めればよいはずです。
シナリオをUMLのシーケンス図で書きます。
まず、バウンダリと業務ロジックとDAOを登場させます。
次に、バウンダリから業務ロジックへコントロールに当たるメソッドを呼び出します。
あとは、コントロールをアトミックなユーザ機能になるまで分解しながらシナリオが通るように進めます。
シナリオは、
のケースについて分析します。
このとき抽出されたユーザ機能は、ルールに基づいてインターフェイスに纏めながら進めます。
シナリオ分析の粒度は、一つのシナリオです。
ロバストネス分析と違って、複数のシナリオが纏められることは殆どありません。
逆に一つのシナリオが大きくなりすぎることもあるため、
そういう場合は、複数枚のシーケンス図に分解することになるかもしれません。
全てのシナリオをシーケンス図に書き終わったらシナリオ分析完了です。
あとは、インターフェイス毎に仕様書を書けば内部設計完了です。
宣言的例外のメリットは、発生する例外を明示的に定義することです。
デメリットは、処理しない場合に使用する側のシグネチャを汚染してしまうことです。
これは、IDDとしては許容できないものです。
しかし、例外的に使えるケースがあります。
業務ロジックでRuntimeExceptionを投げられない、又は、投げたくない場合です。
具体的には、EJBを使ってたり、EJBの代替実装にする場合などです。
こういう場合は、業務ロジックでRuntime系の例外を処理、又は、ラップして、宣言的例外で投げることになります。
基本的にコントロールをトランザクション境界とします。
特殊な要件が無い限りはこれでよいはずです。
処理失敗時に自動再実行する場合、
コントロールのトランザクションの外側で再度呼び出します。
アスペクトでやるのが良いでしょう。
一時的な状態(=セッション情報)は、画面からの入力を除けば、
コントロールの戻りとして取得することになります。
それを保持するかどうかなどは、
まず、ロバストネス図の補足として記述する。
その後、UI仕様書に記述する。
ということになると思います。
俯瞰的なチェックがロバストネス図では難しい場合は、別途適切な表を作りましょう。
共通メニューのようなバウンダリが想定できるのであれば、それを。
出来ないのであれば、ログアウトリンクのようなバウンダリを設定し、ロバストネス分析を行います。
その上で、どの画面に含まれるかという情報をバウンダリの補足として記述します。
UI仕様書の作りとしても同様にした方が作業が楽になります。
最新の10件を表示しています。 コメントページを参照
