Kusu
をテンプレートにして作成
[
トップ
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
|
ログイン
]
開始行:
ダイコン時代の設計手法くーすのまとめです。~
~
このページの趣旨は、~
読者がくーすを理解して、適用可能にするための最低限の情報~
をまとめることです。~
なので、議論の経緯や深い所は、~
-tpircsさんの[[higaさんによるダイコン時代の設計方法:http:...
-いずれ出る(と期待してやまない)ひがさんのくーす本
を参照してもらうことになると思います。~
但し、このページだけではくーすを理解できないとか手が動か...
分からない、情報が足りないところはどんどん指摘して下さい...
~
----
更新履歴~
8/5~
-文章の校正~
-用語の更新~
--ユーザ機能：アトミック云々を追加~
--DAO：インターフェイスについてを追加~
--業務ロジック：追加~
--補助ロジック：追加~
-ユーザ機能分析で、シナリオ分析について追加
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~
-UIでの一時的な状態の扱いについて追加
-全ての画面の中に共通的な処理が含まれている場合について追加
----
----
#contents
#navi(Kusu)
----
*はじめに [#gf13fec5]
**くーすとは [#a0590c86]
ダイコン時代のシステム開発を効率化するための設計方法論で...
でもダイコンを使わなくてもくーすは使えます。~
分類としては、IDD(Interface Driven Development)に当たるも...
固有名として、くーす(古酒のこと、Kusu)と呼びます。
**想定する読者 [#xfc621cb]
業務系のシステム開発を安全に効率的に行いたいと思ってる方。~
ダイコンについてある程度理解していることが望ましいですが...
ゲーム開発や、自然科学系のシステム開発などには向かないか...
**用語 [#e6554200]
:ロバストネス分析|ユースケースから分析クラス図を作るため...
但しオリジナルを知っている必要は無くて、そういう名前であ...
:バウンダリ|システム境界に当たるインターフェイス。画面、...
:コントロール|バウンダリから呼び出される処理のこと。~
くーすでは、コントロールをユーザ機能に分解していく。~
:ユーザ機能|<オブジェクト>(<結果>)<アクシ...
「〜(の〜)を〜する」みたいな感じ。~
アトミックなユーザ機能と、それを呼び出すフロー的なユーザ...
最終的にインターフェイスのメソッドになる。
:エンティティ|リソースにマッピングされる必要があるデータ...
エンティティをリソースとやり取りするためにDAOが作られる
:リソース|DBMSやファイルなどの永続的なもの。~
:DTO(Data Transfer Object)|リソースにマッピングされないデ...
バウンダリが要求する加工済みの情報をやり取りする場合のオ...
:DAO(Data Access Object)|エンティティとリソースのマッピン...
ユーザ機能からインターフェイスが作られて、リソースに対応...
:業務ロジック|
バウンダリから呼び出されるロジック。~
基本的に、業務ロジックに当たるユーザ機能をさして使うが、~
インターフェイスをさして使ってもよい。(連動しているので誤...
厳密に言う場合、業務ロジックインターフェイスと呼ぶ。~
:補助ロジック|業務ロジックから呼び出されるロジック。~
あとは、業務ロジックと同様。~
:シナリオ|アクターの目的を達成するためのシステムとのやり...
この文書でのシナリオの粒度は、システムに対する１トランザ...
「コメントを登録する」、「利用者の情報を変更する」のよう...
*概論 [#e23bdb30]
**スコープ [#d6264650]
新業務分析が完了しているところから開始し、~
外部設計、内部設計までが対象スコープです。
**概念の理解 [#p9320ad5]
***バウンダリの一つのイベントから呼び出すコントロールは一...
バウンダリで発生するイベント(画面表示時、ボタンクリック等...
呼び出されるコントロールは一つだけです。~
もっと実装寄りにすると、~
StrutsのActionクラスのメソッドから呼び出されるコントロー...
のように読み替えることが出来ます。~
***コントロールはステートレス [#y9a94bff]
コントロールには状態を持ちません。~
コントロールが状態を持たないので、~
コントロールを構成するユーザ機能も状態を持ちません。~
バウンダリに一時的なセッションの状態を持ち、~
エンティティ(リソース)に永続的な状態を持つだけです。
***コントロールからコントロールは呼び出さない [#te6216e1]
コントロールから別のコントロールを呼び出してはいけません。~
コントロールが汎用的な名前であったとしても、コントロール...
そのコントロールは、同じ名前の汎用的なユーザ機能を呼び出...
バウンダリ依存なものであることに変わりありません。~
***例外はRuntimeException系で [#p2c89d2b]
まずインターフェイスありきのため、宣言的例外は基本的に使...
また使う必要もありません。~
但し、どのような例外が発生するか位は、実装クラスのJavadoc...
例外のcatchは業務ロジックで行い、ログ出力やロールバックす...
大抵はそのまま投げて、バウンダリに伝播させ、画面上のエラ...
***ユーザ機能からのインターフェイスの抽出 [#d05879b9]
ユーザ機能はその内容から自動的にインターフェイスに分類で...
まず、その種類を考えます。~
-コントロールである：業務ロジックになります。
-コントロールではない
--エンティティに関連する：DAOになります。
--エンティティに関連しない：補助ロジックになります。
次に個別のインターフェイスの識別として、~
-業務ロジックの場合、バウンダリ毎に纏める。~
-補助ロジックは、目的語で纏める。~
-DAOは、エンティティで纏める。~
ということになります。~
ここまでルール化されているので、~
ユーザ機能抽出と同時にインターフェイスの抽出が出来るよう...
***クラス図なんて要らない [#ac5d465d]
くーすにクラス図は要りません。~
クラス図は、クラス間の静的構造の情報を記述するものですが、~
少なくとも、業務ロジック、補助ロジックについては、~
シーケンス図で表す以上の静的構造は存在しません。~
あるとすれば、~
-バウンダリ層の作り(くーすのスコープ外)
-エンティティやDTOのデータ構造
ぐらいです。~
これらについては、必要であれば作って下さい。~
**プロセスフロー [#t6502bb0]
[[プロセスフロー:http://www.seasar.org/wiki/index.php?plu...
新業務フローを入力として、
-ロバストネス分析
-UIモック生成
を平行して実施。~
ロバストネス図が出来たら
-UI設計
-ユーザ機能分析
-ER分析
を平行して実施します。~
これだけです。~
後は、これらの成果物を使って実装・テストを行うだけです。
**成果物 [#nca93a2e]
***新業務フロー(外部仕様) [#r62e64a1]
これは、くーすの成果物ではなく、要求する入力になります。~
バウンダリのフローとして記述されます。~
[[業務フロー:http://www.seasar.org/wiki/index.php?plugin=...
***UIモック(外部仕様) [#hbabc32b]
UIのモックです。~
HTMLなり、VBなり、作るシステムによって変わってきます。
***ロバストネス図(外部仕様) [#b60edcb1]
-インターフェイスとなるバウンダリ
-バウンダリが呼び出すコントロール
-コントロールが関連するエンティティ
を纏めた図です。~
[[ロバストネス図:http://www.seasar.org/wiki/index.php?plu...
***UI仕様書(外部仕様) [#je6af4ef]
UIの実装に必要な情報を纏めたものです。~
[[UI仕様書(xls):http://www.seasar.org/wiki/index.php?plug...
***エンティティ仕様書(外部仕様) [#fffa3cd3]
エンティティの仕様書です。~
オブジェクトとしての性質に加えて、テーブルの物理設計につ...
[[エンティティ仕様書(xls):http://www.seasar.org/wiki/inde...
***シナリオシーケンス(内部仕様) [#e0c9c8c8]
UMLのシーケンス図で表したホワイトボックスシナリオです。~
シナリオ毎に作られます。~
[[シナリオシーケンス_ログイン:http://www.seasar.org/wiki/...
[[シナリオシーケンス_コメント一覧表示:http://www.seasar.o...
[[シナリオシーケンス_コメントを登録する:http://www.seasar...
を参照して下さい。
***コンポーネント仕様書(内部仕様) [#k252b31d]
インターフェイスの仕様書です。~
メソッド毎に事前条件、事後条件を記述します。
実装クラスについての仕様書は作りません。~
実装クラスの仕様書が必要だと感じた場合は、~
シナリオシーケンスで抽出されていないユーザ機能があるかも...
[[コンポーネント仕様書(xls):http://www.seasar.org/wiki/in...
**成果物のレビュー [#md1eeaba]
-新業務フローの顧客レビュー
-ロバストネス分析前のUIモック(ラフ版)の顧客レビュー
-ロバストネス分析後のロバストネス図の顧客レビュー
-外部設計完了後の顧客レビュー
は、やった方が良いです。~
他にも、内部設計完了後の顧客レビューをやることもあるかも...
もちろん、それぞれ内部レビューはやっておくべきです。
*プロセス [#p20ee81d]
**UIモック作成 [#r02daca1]
新業務フローが画面遷移に当たるので、そこからUIモックを作...
特に難しいことはありません。~
ただし、UIモックはできるだけ早い段階で顧客レビューした方...
UIモックでのフィードバック(要求漏れの発現)の遅れは、~
質、量ともに重要で、発現が早くなる分リスクが減ります。~
~
タイミングとしては、新業務フローが確定しないまでもある程...
同時にUIモックの作成をはじめた方が良いです。~
ロバストネス分析前にラフな画面イメージをレビューしてもら...
このとき、「開発途中のものなので・・・」というフォローは...
顧客が、~
(本当はナビとしてこういう情報が必要だけど、それぐらいわか...
というような思考になって要求が出てこないことがあります。
**ロバストネス分析 [#v91385d6]
バウンダリのイベント毎に、
-システムに対してどのような作用を起こすか
-バウンダリの処理のためにどのような情報が必要か
という観点でコントロールを抽出し、~
コントロールが~
-どんなエンティティと関連するか
ということでエンティティを抽出します。~
~
ロバストネス分析を行う単位は、シナリオ毎が目安になります。~
但し、登録、変更、削除等が極めて近いフローで行われいたり、~
個々のシナリオのフローが短くて、~
分けるよりも一つに纏めた方が楽で分かりやすいというような...
複数シナリオを一枚にしても問題ありません。~
**UI設計 [#i0f5495f]
UIモックとロバストネス図のバウンダリとコントロールから、~
項目とデータの関連と入力チェックを中心に纏める。
**エンティティ分析 [#w124492e]
エンティティ毎にエンティティの属性とその特性を纏める。~
属性の抽出は、~
-事前の業務分析で分かっているもの
-バウンダリから取れるもの
を集めればよいはずです。
**ユーザ機能分析 [#k36f836a]
シナリオをUMLのシーケンス図で書きます。~
まず、バウンダリと業務ロジックとDAOを登場させます。~
次に、バウンダリから業務ロジックへコントロールに当たるメ...
あとは、コントロールをアトミックなユーザ機能になるまで分...
シナリオは、~
-しなければならないこと
-ならばできること(入力、処理結果による分岐)
-例外
のケースについて分析します。~
~
このとき抽出されたユーザ機能は、ルールに基づいてインター...
~
シナリオ分析の粒度は、一つのシナリオです。~
ロバストネス分析と違って、複数のシナリオが纏められること...
逆に一つのシナリオが大きくなりすぎることもあるため、~
そういう場合は、複数枚のシーケンス図に分解することになる...
~
全てのシナリオをシーケンス図に書き終わったらシナリオ分析...
あとは、インターフェイス毎に仕様書を書けば内部設計完了で...
*ベストプラクティス [#z74e7faa]
**宣言的例外の使い道はないのか？ [#lf7ee7f9]
宣言的例外のメリットは、発生する例外を明示的に定義するこ...
デメリットは、処理しない場合に使用する側のシグネチャを汚...
これは、IDDとしては許容できないものです。~
~
しかし、例外的に使えるケースがあります。~
業務ロジックでRuntimeExceptionを投げられない、又は、投げ...
具体的には、EJBを使ってたり、EJBの代替実装にする場合など...
こういう場合は、業務ロジックでRuntime系の例外を処理、又は...
**トランザクション境界はどう設定する？ [#sf64acd1]
基本的にコントロールをトランザクション境界とします。~
特殊な要件が無い限りはこれでよいはずです。~
処理失敗時に自動再実行する場合、~
コントロールのトランザクションの外側で再度呼び出します。~
アスペクトでやるのが良いでしょう。~
**UIでの一時的な状態の扱いはどのようにすべきか？ [#p8f43e...
一時的な状態(=セッション情報)は、画面からの入力を除けば、~
コントロールの戻りとして取得することになります。~
それを保持するかどうかなどは、~
まず、ロバストネス図の補足として記述する。~
その後、UI仕様書に記述する。~
ということになると思います。~
俯瞰的なチェックがロバストネス図では難しい場合は、別途適...
**全ての画面の中にログアウトなどの共通的な処理が含まれて...
共通メニューのようなバウンダリが想定できるのであれば、そ...
出来ないのであれば、ログアウトリンクのようなバウンダリを...
その上で、どの画面に含まれるかという情報をバウンダリの補...
UI仕様書の作りとしても同様にした方が作業が楽になります。~
~
#pcomment(below,reply)
終了行:
ダイコン時代の設計手法くーすのまとめです。~
~
このページの趣旨は、~
読者がくーすを理解して、適用可能にするための最低限の情報~
をまとめることです。~
なので、議論の経緯や深い所は、~
-tpircsさんの[[higaさんによるダイコン時代の設計方法:http:...
-いずれ出る(と期待してやまない)ひがさんのくーす本
を参照してもらうことになると思います。~
但し、このページだけではくーすを理解できないとか手が動か...
分からない、情報が足りないところはどんどん指摘して下さい...
~
----
更新履歴~
8/5~
-文章の校正~
-用語の更新~
--ユーザ機能：アトミック云々を追加~
--DAO：インターフェイスについてを追加~
--業務ロジック：追加~
--補助ロジック：追加~
-ユーザ機能分析で、シナリオ分析について追加
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~
-UIでの一時的な状態の扱いについて追加
-全ての画面の中に共通的な処理が含まれている場合について追加
----
----
#contents
#navi(Kusu)
----
*はじめに [#gf13fec5]
**くーすとは [#a0590c86]
ダイコン時代のシステム開発を効率化するための設計方法論で...
でもダイコンを使わなくてもくーすは使えます。~
分類としては、IDD(Interface Driven Development)に当たるも...
固有名として、くーす(古酒のこと、Kusu)と呼びます。
**想定する読者 [#xfc621cb]
業務系のシステム開発を安全に効率的に行いたいと思ってる方。~
ダイコンについてある程度理解していることが望ましいですが...
ゲーム開発や、自然科学系のシステム開発などには向かないか...
**用語 [#e6554200]
:ロバストネス分析|ユースケースから分析クラス図を作るため...
但しオリジナルを知っている必要は無くて、そういう名前であ...
:バウンダリ|システム境界に当たるインターフェイス。画面、...
:コントロール|バウンダリから呼び出される処理のこと。~
くーすでは、コントロールをユーザ機能に分解していく。~
:ユーザ機能|<オブジェクト>(<結果>)<アクシ...
「〜(の〜)を〜する」みたいな感じ。~
アトミックなユーザ機能と、それを呼び出すフロー的なユーザ...
最終的にインターフェイスのメソッドになる。
:エンティティ|リソースにマッピングされる必要があるデータ...
エンティティをリソースとやり取りするためにDAOが作られる
:リソース|DBMSやファイルなどの永続的なもの。~
:DTO(Data Transfer Object)|リソースにマッピングされないデ...
バウンダリが要求する加工済みの情報をやり取りする場合のオ...
:DAO(Data Access Object)|エンティティとリソースのマッピン...
ユーザ機能からインターフェイスが作られて、リソースに対応...
:業務ロジック|
バウンダリから呼び出されるロジック。~
基本的に、業務ロジックに当たるユーザ機能をさして使うが、~
インターフェイスをさして使ってもよい。(連動しているので誤...
厳密に言う場合、業務ロジックインターフェイスと呼ぶ。~
:補助ロジック|業務ロジックから呼び出されるロジック。~
あとは、業務ロジックと同様。~
:シナリオ|アクターの目的を達成するためのシステムとのやり...
この文書でのシナリオの粒度は、システムに対する１トランザ...
「コメントを登録する」、「利用者の情報を変更する」のよう...
*概論 [#e23bdb30]
**スコープ [#d6264650]
新業務分析が完了しているところから開始し、~
外部設計、内部設計までが対象スコープです。
**概念の理解 [#p9320ad5]
***バウンダリの一つのイベントから呼び出すコントロールは一...
バウンダリで発生するイベント(画面表示時、ボタンクリック等...
呼び出されるコントロールは一つだけです。~
もっと実装寄りにすると、~
StrutsのActionクラスのメソッドから呼び出されるコントロー...
のように読み替えることが出来ます。~
***コントロールはステートレス [#y9a94bff]
コントロールには状態を持ちません。~
コントロールが状態を持たないので、~
コントロールを構成するユーザ機能も状態を持ちません。~
バウンダリに一時的なセッションの状態を持ち、~
エンティティ(リソース)に永続的な状態を持つだけです。
***コントロールからコントロールは呼び出さない [#te6216e1]
コントロールから別のコントロールを呼び出してはいけません。~
コントロールが汎用的な名前であったとしても、コントロール...
そのコントロールは、同じ名前の汎用的なユーザ機能を呼び出...
バウンダリ依存なものであることに変わりありません。~
***例外はRuntimeException系で [#p2c89d2b]
まずインターフェイスありきのため、宣言的例外は基本的に使...
また使う必要もありません。~
但し、どのような例外が発生するか位は、実装クラスのJavadoc...
例外のcatchは業務ロジックで行い、ログ出力やロールバックす...
大抵はそのまま投げて、バウンダリに伝播させ、画面上のエラ...
***ユーザ機能からのインターフェイスの抽出 [#d05879b9]
ユーザ機能はその内容から自動的にインターフェイスに分類で...
まず、その種類を考えます。~
-コントロールである：業務ロジックになります。
-コントロールではない
--エンティティに関連する：DAOになります。
--エンティティに関連しない：補助ロジックになります。
次に個別のインターフェイスの識別として、~
-業務ロジックの場合、バウンダリ毎に纏める。~
-補助ロジックは、目的語で纏める。~
-DAOは、エンティティで纏める。~
ということになります。~
ここまでルール化されているので、~
ユーザ機能抽出と同時にインターフェイスの抽出が出来るよう...
***クラス図なんて要らない [#ac5d465d]
くーすにクラス図は要りません。~
クラス図は、クラス間の静的構造の情報を記述するものですが、~
少なくとも、業務ロジック、補助ロジックについては、~
シーケンス図で表す以上の静的構造は存在しません。~
あるとすれば、~
-バウンダリ層の作り(くーすのスコープ外)
-エンティティやDTOのデータ構造
ぐらいです。~
これらについては、必要であれば作って下さい。~
**プロセスフロー [#t6502bb0]
[[プロセスフロー:http://www.seasar.org/wiki/index.php?plu...
新業務フローを入力として、
-ロバストネス分析
-UIモック生成
を平行して実施。~
ロバストネス図が出来たら
-UI設計
-ユーザ機能分析
-ER分析
を平行して実施します。~
これだけです。~
後は、これらの成果物を使って実装・テストを行うだけです。
**成果物 [#nca93a2e]
***新業務フロー(外部仕様) [#r62e64a1]
これは、くーすの成果物ではなく、要求する入力になります。~
バウンダリのフローとして記述されます。~
[[業務フロー:http://www.seasar.org/wiki/index.php?plugin=...
***UIモック(外部仕様) [#hbabc32b]
UIのモックです。~
HTMLなり、VBなり、作るシステムによって変わってきます。
***ロバストネス図(外部仕様) [#b60edcb1]
-インターフェイスとなるバウンダリ
-バウンダリが呼び出すコントロール
-コントロールが関連するエンティティ
を纏めた図です。~
[[ロバストネス図:http://www.seasar.org/wiki/index.php?plu...
***UI仕様書(外部仕様) [#je6af4ef]
UIの実装に必要な情報を纏めたものです。~
[[UI仕様書(xls):http://www.seasar.org/wiki/index.php?plug...
***エンティティ仕様書(外部仕様) [#fffa3cd3]
エンティティの仕様書です。~
オブジェクトとしての性質に加えて、テーブルの物理設計につ...
[[エンティティ仕様書(xls):http://www.seasar.org/wiki/inde...
***シナリオシーケンス(内部仕様) [#e0c9c8c8]
UMLのシーケンス図で表したホワイトボックスシナリオです。~
シナリオ毎に作られます。~
[[シナリオシーケンス_ログイン:http://www.seasar.org/wiki/...
[[シナリオシーケンス_コメント一覧表示:http://www.seasar.o...
[[シナリオシーケンス_コメントを登録する:http://www.seasar...
を参照して下さい。
***コンポーネント仕様書(内部仕様) [#k252b31d]
インターフェイスの仕様書です。~
メソッド毎に事前条件、事後条件を記述します。
実装クラスについての仕様書は作りません。~
実装クラスの仕様書が必要だと感じた場合は、~
シナリオシーケンスで抽出されていないユーザ機能があるかも...
[[コンポーネント仕様書(xls):http://www.seasar.org/wiki/in...
**成果物のレビュー [#md1eeaba]
-新業務フローの顧客レビュー
-ロバストネス分析前のUIモック(ラフ版)の顧客レビュー
-ロバストネス分析後のロバストネス図の顧客レビュー
-外部設計完了後の顧客レビュー
は、やった方が良いです。~
他にも、内部設計完了後の顧客レビューをやることもあるかも...
もちろん、それぞれ内部レビューはやっておくべきです。
*プロセス [#p20ee81d]
**UIモック作成 [#r02daca1]
新業務フローが画面遷移に当たるので、そこからUIモックを作...
特に難しいことはありません。~
ただし、UIモックはできるだけ早い段階で顧客レビューした方...
UIモックでのフィードバック(要求漏れの発現)の遅れは、~
質、量ともに重要で、発現が早くなる分リスクが減ります。~
~
タイミングとしては、新業務フローが確定しないまでもある程...
同時にUIモックの作成をはじめた方が良いです。~
ロバストネス分析前にラフな画面イメージをレビューしてもら...
このとき、「開発途中のものなので・・・」というフォローは...
顧客が、~
(本当はナビとしてこういう情報が必要だけど、それぐらいわか...
というような思考になって要求が出てこないことがあります。
**ロバストネス分析 [#v91385d6]
バウンダリのイベント毎に、
-システムに対してどのような作用を起こすか
-バウンダリの処理のためにどのような情報が必要か
という観点でコントロールを抽出し、~
コントロールが~
-どんなエンティティと関連するか
ということでエンティティを抽出します。~
~
ロバストネス分析を行う単位は、シナリオ毎が目安になります。~
但し、登録、変更、削除等が極めて近いフローで行われいたり、~
個々のシナリオのフローが短くて、~
分けるよりも一つに纏めた方が楽で分かりやすいというような...
複数シナリオを一枚にしても問題ありません。~
**UI設計 [#i0f5495f]
UIモックとロバストネス図のバウンダリとコントロールから、~
項目とデータの関連と入力チェックを中心に纏める。
**エンティティ分析 [#w124492e]
エンティティ毎にエンティティの属性とその特性を纏める。~
属性の抽出は、~
-事前の業務分析で分かっているもの
-バウンダリから取れるもの
を集めればよいはずです。
**ユーザ機能分析 [#k36f836a]
シナリオをUMLのシーケンス図で書きます。~
まず、バウンダリと業務ロジックとDAOを登場させます。~
次に、バウンダリから業務ロジックへコントロールに当たるメ...
あとは、コントロールをアトミックなユーザ機能になるまで分...
シナリオは、~
-しなければならないこと
-ならばできること(入力、処理結果による分岐)
-例外
のケースについて分析します。~
~
このとき抽出されたユーザ機能は、ルールに基づいてインター...
~
シナリオ分析の粒度は、一つのシナリオです。~
ロバストネス分析と違って、複数のシナリオが纏められること...
逆に一つのシナリオが大きくなりすぎることもあるため、~
そういう場合は、複数枚のシーケンス図に分解することになる...
~
全てのシナリオをシーケンス図に書き終わったらシナリオ分析...
あとは、インターフェイス毎に仕様書を書けば内部設計完了で...
*ベストプラクティス [#z74e7faa]
**宣言的例外の使い道はないのか？ [#lf7ee7f9]
宣言的例外のメリットは、発生する例外を明示的に定義するこ...
デメリットは、処理しない場合に使用する側のシグネチャを汚...
これは、IDDとしては許容できないものです。~
~
しかし、例外的に使えるケースがあります。~
業務ロジックでRuntimeExceptionを投げられない、又は、投げ...
具体的には、EJBを使ってたり、EJBの代替実装にする場合など...
こういう場合は、業務ロジックでRuntime系の例外を処理、又は...
**トランザクション境界はどう設定する？ [#sf64acd1]
基本的にコントロールをトランザクション境界とします。~
特殊な要件が無い限りはこれでよいはずです。~
処理失敗時に自動再実行する場合、~
コントロールのトランザクションの外側で再度呼び出します。~
アスペクトでやるのが良いでしょう。~
**UIでの一時的な状態の扱いはどのようにすべきか？ [#p8f43e...
一時的な状態(=セッション情報)は、画面からの入力を除けば、~
コントロールの戻りとして取得することになります。~
それを保持するかどうかなどは、~
まず、ロバストネス図の補足として記述する。~
その後、UI仕様書に記述する。~
ということになると思います。~
俯瞰的なチェックがロバストネス図では難しい場合は、別途適...
**全ての画面の中にログアウトなどの共通的な処理が含まれて...
共通メニューのようなバウンダリが想定できるのであれば、そ...
出来ないのであれば、ログアウトリンクのようなバウンダリを...
その上で、どの画面に含まれるかという情報をバウンダリの補...
UI仕様書の作りとしても同様にした方が作業が楽になります。~
~
#pcomment(below,reply)
ページ名:
![[PukiWiki]](image/seasar.png "[PukiWiki]")
