Kusu の編集 - SeasarWiki

ダイコン時代の設計手法くーすのまとめです。~
~
このページの趣旨は、~
読者がくーすを理解して、適用可能にするための最低限の情報~
をまとめることです。~
なので、議論の経緯や深い所は、~
-tpircsさんの[[higaさんによるダイコン時代の設計方法:http://www.wikiroom.com/tpircs/index.php?higa%A4%B5%A4%F3%A4%CB%A4%E8%A4%EB%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%CA%FD%CB%A1]]
-いずれ出る(と期待してやまない)ひがさんのくーす本

を参照してもらうことになると思います。~
但し、このページだけではくーすを理解できないとか手が動かないとなるとまずいので、~
分からない、情報が足りないところはどんどん指摘して下さい。m(_ _)m~
~
----
更新履歴~
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]
:ロバストネス分析|ユースケースから分析クラス図を作るための分析法。~
但しオリジナルを知っている必要は無くて、そういう名前であると思ってもらえばよいです。
:バウンダリ|システム境界に当たるインターフェイス。画面、帳票、外部システムとのI/F等
:コントロール|バウンダリから呼び出される処理のこと。~
くーすでは、コントロールをユーザ機能に分解していく。~
:ユーザ機能|&lt;オブジェクト&gt;(&lt;結果&gt;)&lt;アクション&gt;で表される機能のこと。~
「〜(の〜)を〜する」みたいな感じ。~
アトミックなユーザ機能と、それを呼び出すフロー的なユーザ機能に分かれる。~
最終的にインターフェイスのメソッドになる。
:エンティティ|リソースにマッピングされる必要があるデータオブジェクト。~
エンティティをリソースとやり取りするためにDAOが作られる
:リソース|DBMSやファイルなどの永続的なもの。~
:DTO(Data Transfer Object)|リソースにマッピングされないデータオブジェクト。~
バウンダリが要求する加工済みの情報をやり取りする場合のオブジェクト。
:DAO(Data Access Object)|エンティティとリソースのマッピングを担うオブジェクト。~
ユーザ機能からインターフェイスが作られて、リソースに対応して実装される。
:業務ロジック|
バウンダリから呼び出されるロジック。~
基本的に、業務ロジックに当たるユーザ機能をさして使うが、~
インターフェイスをさして使ってもよい。(連動しているので誤解は無い)~
厳密に言う場合、業務ロジックインターフェイスと呼ぶ。~
:補助ロジック|業務ロジックから呼び出されるロジック。~
あとは、業務ロジックと同様。~
:シナリオ|アクターの目的を達成するためのシステムとのやり取り、及び一連のシステム動作の記述~
この文書でのシナリオの粒度は、システムに対する１トランザクションの処理と考えて下さい。~
「コメントを登録する」、「利用者の情報を変更する」のような感じです。~

*概論 [#e23bdb30]
**スコープ [#d6264650]
新業務分析が完了しているところから開始し、~
外部設計、内部設計までが対象スコープです。
**概念の理解 [#p9320ad5]
***バウンダリの一つのイベントから呼び出すコントロールは一つだけ [#me08c084]
バウンダリで発生するイベント(画面表示時、ボタンクリック等)から~
呼び出されるコントロールは一つだけです。~
もっと実装寄りにすると、~
StrutsのActionクラスのメソッドから呼び出されるコントロールは一つ~
のように読み替えることが出来ます。~
***コントロールはステートレス [#y9a94bff]
コントロールには状態を持ちません。~
コントロールが状態を持たないので、~
コントロールを構成するユーザ機能も状態を持ちません。~
バウンダリに一時的なセッションの状態を持ち、~
エンティティ(リソース)に永続的な状態を持つだけです。
***コントロールからコントロールは呼び出さない [#te6216e1]
コントロールから別のコントロールを呼び出してはいけません。~
コントロールが汎用的な名前であったとしても、コントロールは汎用的ではありません。~
そのコントロールは、同じ名前の汎用的なユーザ機能を呼び出しているだけで、~
バウンダリ依存なものであることに変わりありません。~
***例外はRuntimeException系で [#p2c89d2b]
まずインターフェイスありきのため、宣言的例外は基本的に使えません。~
また使う必要もありません。~
但し、どのような例外が発生するか位は、実装クラスのJavadocに書いておきましょう。~
例外のcatchは業務ロジックで行い、ログ出力やロールバックすることになります。~
大抵はそのまま投げて、バウンダリに伝播させ、画面上のエラーメッセージに変換したりします。~
***ユーザ機能からのインターフェイスの抽出 [#d05879b9]
ユーザ機能はその内容から自動的にインターフェイスに分類できます。~
まず、その種類を考えます。~
-コントロールである：業務ロジックになります。
-コントロールではない
--エンティティに関連する：DAOになります。
--エンティティに関連しない：補助ロジックになります。

次に個別のインターフェイスの識別として、~
-業務ロジックの場合、バウンダリ毎に纏める。~
-補助ロジックは、目的語で纏める。~
-DAOは、エンティティで纏める。~

ということになります。~
ここまでルール化されているので、~
ユーザ機能抽出と同時にインターフェイスの抽出が出来るようになります。~
***クラス図なんて要らない [#ac5d465d]
くーすにクラス図は要りません。~
クラス図は、クラス間の静的構造の情報を記述するものですが、~
少なくとも、業務ロジック、補助ロジックについては、~
シーケンス図で表す以上の静的構造は存在しません。~
あるとすれば、~
-バウンダリ層の作り(くーすのスコープ外)
-エンティティやDTOのデータ構造

ぐらいです。~
これらについては、必要であれば作って下さい。~
**プロセスフロー [#t6502bb0]
[[プロセスフロー:http://www.seasar.org/wiki/index.php?plugin=attach&pcmd=open&file=%A5%D7%A5%ED%A5%BB%A5%B9%A5%D5%A5%ED%A1%BC.jpg&refer=Kusu]]を参照して下さい。~
新業務フローを入力として、
-ロバストネス分析
-UIモック生成

を平行して実施。~
ロバストネス図が出来たら
-UI設計
-ユーザ機能分析
-ER分析

を平行して実施します。~
これだけです。~
後は、これらの成果物を使って実装・テストを行うだけです。
**成果物 [#nca93a2e]
***新業務フロー(外部仕様) [#r62e64a1]
これは、くーすの成果物ではなく、要求する入力になります。~
バウンダリのフローとして記述されます。~
[[業務フロー:http://www.seasar.org/wiki/index.php?plugin=attach&pcmd=open&file=%B6%C8%CC%B3%A5%D5%A5%ED%A1%BC.jpg&refer=Kusu]]を参照して下さい。
***UIモック(外部仕様) [#hbabc32b]
UIのモックです。~
HTMLなり、VBなり、作るシステムによって変わってきます。
***ロバストネス図(外部仕様) [#b60edcb1]
-インターフェイスとなるバウンダリ
-バウンダリが呼び出すコントロール
-コントロールが関連するエンティティ

を纏めた図です。~
[[ロバストネス図:http://www.seasar.org/wiki/index.php?plugin=attach&pcmd=open&file=%A5%ED%A5%D0%A5%B9%A5%C8%A5%CD%A5%B9%BF%DE.jpg&refer=Kusu]]を参照して下さい。
***UI仕様書(外部仕様) [#je6af4ef]
UIの実装に必要な情報を纏めたものです。~
[[UI仕様書(xls):http://www.seasar.org/wiki/index.php?plugin=attach&pcmd=open&file=UI%BB%C5%CD%CD%BD%F1.xls&refer=Kusu]]を参照して下さい。
***エンティティ仕様書(外部仕様) [#fffa3cd3]
エンティティの仕様書です。~
オブジェクトとしての性質に加えて、テーブルの物理設計についての情報も含めます。~
[[エンティティ仕様書(xls):http://www.seasar.org/wiki/index.php?plugin=attach&pcmd=open&file=%A5%A8%A5%F3%A5%C6%A5%A3%A5%C6%A5%A3%BB%C5%CD%CD%BD%F1.xls&refer=Kusu]]を参照して下さい。
***シナリオシーケンス(内部仕様) [#e0c9c8c8]
UMLのシーケンス図で表したホワイトボックスシナリオです。~
シナリオ毎に作られます。~
[[シナリオシーケンス_ログイン:http://www.seasar.org/wiki/index.php?plugin=attach&pcmd=open&file=%A5%B7%A5%CA%A5%EA%A5%AA%A5%B7%A1%BC%A5%B1%A5%F3%A5%B9_%A5%ED%A5%B0%A5%A4%A5%F3.jpg&refer=Kusu]]~
[[シナリオシーケンス_コメント一覧表示:http://www.seasar.org/wiki/index.php?plugin=attach&pcmd=open&file=%A5%B7%A5%CA%A5%EA%A5%AA%A5%B7%A1%BC%A5%B1%A5%F3%A5%B9_%A5%B3%A5%E1%A5%F3%A5%C8%B0%EC%CD%F7%C9%BD%BC%A8.jpg&refer=Kusu]]~
[[シナリオシーケンス_コメントを登録する:http://www.seasar.org/wiki/index.php?plugin=attach&pcmd=open&file=%A5%B7%A5%CA%A5%EA%A5%AA%A5%B7%A1%BC%A5%B1%A5%F3%A5%B9_%A5%B3%A5%E1%A5%F3%A5%C8%A4%F2%C5%D0%CF%BF%A4%B9%A4%EB.jpg&refer=Kusu]]~
を参照して下さい。
***コンポーネント仕様書(内部仕様) [#k252b31d]
インターフェイスの仕様書です。~
メソッド毎に事前条件、事後条件を記述します。
実装クラスについての仕様書は作りません。~
実装クラスの仕様書が必要だと感じた場合は、~
シナリオシーケンスで抽出されていないユーザ機能があるかもしれません。~
[[コンポーネント仕様書(xls):http://www.seasar.org/wiki/index.php?plugin=attach&pcmd=open&file=%A5%B3%A5%F3%A5%DD%A1%BC%A5%CD%A5%F3%A5%C8%BB%C5%CD%CD%BD%F1.xls&refer=Kusu]]を参照して下さい。
**成果物のレビュー [#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での一時的な状態の扱いはどのようにすべきか？ [#p8f43ee6]
一時的な状態(=セッション情報)は、画面からの入力を除けば、~
コントロールの戻りとして取得することになります。~
それを保持するかどうかなどは、~
まず、ロバストネス図の補足として記述する。~
その後、UI仕様書に記述する。~
ということになると思います。~
俯瞰的なチェックがロバストネス図では難しい場合は、別途適切な表を作りましょう。~
**全ての画面の中にログアウトなどの共通的な処理が含まれている場合は？ [#nfac80ce]
共通メニューのようなバウンダリが想定できるのであれば、それを。~
出来ないのであれば、ログアウトリンクのようなバウンダリを設定し、ロバストネス分析を行います。~
その上で、どの画面に含まれるかという情報をバウンダリの補足として記述します。~
UI仕様書の作りとしても同様にした方が作業が楽になります。~

~
#pcomment(below,reply)

タイムスタンプを変更しない