練習用ページダイコン時代の設計手法くーすのまとめです。参照してもらうことになると思います。分からない、情報が足りないところはどんどん指摘して下さい。ダイコン時代のシステム開発を効率化するための設計方法論です。ダイコンを使わなくてもくーすは使えます。固有名として、くーす(古酒のこと、Kusu)と呼びます。業務系のシステム開発を安全に効率的に行いたいと思ってる方。ダイコンについてある程度理解していることが望ましいですが、必須ではありません。ゲーム開発や、自然科学系のシステム開発などには向かないかも知れません。:ロバストネス分析|ユースケースから分析クラス図を作るための分析法。オリジナルを知っている必要は無くて、そういう名前であると思ってもらえばよいです。:コントロール|バウンダリから呼び出される処理のこと。くーすでは、コントロールをユーザ機能に分解していく。:ユーザ機能|&lt;オブジェクト&gt;(&lt;結果&gt;)&lt;アクション&gt;で表される機能のこと。「〜(の〜)を〜する」みたいな感じ。アトミックなユーザ機能と、それを呼び出すフロー的なユーザ機能に分かれる。最終的にインターフェイスのメソッドになる。:エンティティ|リソースにマッピングされる必要があるデータオブジェクト。:リソース|DBMSやファイルなどの永続的なもの。Object)|リソースにマッピングされないデータオブジェクト。バウンダリが要求する加工済みの情報をやり取りする場合のオブジェクト。Object)|エンティティとリソースのマッピングを担うオブジェクト。ユーザ機能からインターフェイスが作られて、リソースに対応して実装される。バウンダリから呼び出されるロジック。インターフェイスをさして使ってもよい。厳密に言う場合、業務ロジックインターフェイスと呼ぶ。:補助ロジック|業務ロジックから呼び出されるロジック。あとは、業務ロジックと同様。この文書でのシナリオの粒度は、システムに対する1トランザクションの処理と考えて下さい。「コメントを登録する」、「利用者の情報を変更する」のような感じです。呼び出されるコントロールは一つだけです。ように読み替えることが出来ます。コントロールには状態を持ちません。コントロールを構成するユーザ機能も状態を持ちません。エンティティ(リソース)に永続的な状態を持つだけです。コントロールから別のコントロールを呼び出してはいけません。コントロールが汎用的な名前であったとしても、コントロールは汎用的ではありません。バウンダリ依存なものであることに変わりありません。インターフェイスありきのため、宣言的例外は基本的に使えません。使う必要もありません。どのような例外が発生するか位は、実装クラスのJavadocに書いておきましょう。例外のcatchは業務ロジックで行い、ログ出力やロールバックすることになります。そのまま投げて、バウンダリに伝播させ、画面上のエラーメッセージに変換したりします。ユーザ機能はその内容から自動的にインターフェイスに分類できます。-コントロールである:業務ロジックになります。--エンティティに関連する:DAOになります。--エンティティに関連しない:補助ロジックになります。-業務ロジックの場合、バウンダリ毎に纏める。-補助ロジックは、目的語で纏める。-DAOは、エンティティで纏める。ユーザ機能抽出と同時にインターフェイスの抽出が出来るようになります。くーすにクラス図は要りません。シーケンス図で表す以上の静的構造は存在しません。これらについては、必要であれば作って下さい。[[プロセスフロー: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]]を参照して下さい。