(停止)■S2i18nProject■Wiki更新履歴editダイコン時代の設計手法くーすのまとめです。読者がくーすを理解して、適用可能にするための最低限の情報をまとめることです。議論の経緯や深い所は、tpircsさんのhigaさんによるダイコン時代の設計方法いずれ出る(と期待してやまない)ひがさんのくーす本を参照してもらうことになると思います。分からない、情報が足りないところはどんどん指摘して下さい。†ダイコン時代のシステム開発を効率化するための設計方法論です。ダイコンを使わなくてもくーすは使えます。固有名として、くーす(古酒のこと、Kusu)と呼びます。業務系のシステム開発を安全に効率的に行いたいと思ってる方。ダイコンについてある程度理解していることが望ましいですが、必須ではありません。ゲーム開発や、自然科学系のシステム開発などには向かないかも知れません。†ロバストネス分析ユースケースから分析クラス図を作るための分析法。オリジナルを知っている必要は無くて、そういう名前であると思ってもらえばよいです。システムとのI/F等コントロールバウンダリから呼び出される処理のこと。くーすでは、コントロールをユーザ機能に分解していく。ユーザ機能<オブジェクト>(<結果>)<アクション>で表される機能のこと。「〜(の〜)を〜する」みたいな感じ。アトミックなユーザ機能と、それを呼び出すフロー的なユーザ機能に分かれる。最終的にインターフェイスのメソッドになる。エンティティリソースにマッピングされる必要があるデータオブジェクト。エンティティをリソースとやり取りするためにDAOが作られるリソースDBMSやファイルなどの永続的なもの。Object)リソースにマッピングされないデータオブジェクト。バウンダリが要求する加工済みの情報をやり取りする場合のオブジェクト。Object)エンティティとリソースのマッピングを担うオブジェクト。ユーザ機能からインターフェイスが作られて、リソースに対応して実装される。業務ロジックバウンダリから呼び出されるロジック。基本的に、業務ロジックに当たるユーザ機能をさして使うが、インターフェイスをさして使ってもよい。(連動しているので誤解は無い)厳密に言う場合、業務ロジックインターフェイスと呼ぶ。補助ロジック業務ロジックから呼び出されるロジック。あとは、業務ロジックと同様。シナリオアクターの目的を達成するためのシステムとのやり取り、及び一連のシステム動作の記述この文書でのシナリオの粒度は、システムに対する1トランザクションの処理と考えて下さい。「コメントを登録する」、「利用者の情報を変更する」のような感じです。†バウンダリで発生するイベント(画面表示時、ボタンクリック等)から呼び出されるコントロールは一つだけです。実装寄りにすると、StrutsのActionクラスのメソッドから呼び出されるコントロールは一つのように読み替えることが出来ます。†コントロールには状態を持ちません。コントロールが状態を持たないので、コントロールを構成するユーザ機能も状態を持ちません。バウンダリに一時的なセッションの状態を持ち、エンティティ(リソース)に永続的な状態を持つだけです。†コントロールから別のコントロールを呼び出してはいけません。コントロールが汎用的な名前であったとしても、コントロールは汎用的ではありません。そのコントロールは、同じ名前の汎用的なユーザ機能を呼び出しているだけで、バウンダリ依存なものであることに変わりありません。†まずインターフェイスありきのため、宣言的例外は基本的に使えません。使う必要もありません。どのような例外が発生するか位は、実装クラスのJavadocに書いておきましょう。例外のcatchは業務ロジックで行い、ログ出力やロールバックすることになります。そのまま投げて、バウンダリに伝播させ、画面上のエラーメッセージに変換したりします。†ユーザ機能はその内容から自動的にインターフェイスに分類できます。コントロールである:業務ロジックになります。コントロールではないエンティティに関連する:DAOになります。エンティティに関連しない:補助ロジックになります。業務ロジックの場合、バウンダリ毎に纏める。補助ロジックは、目的語で纏める。DAOは、エンティティで纏める。ここまでルール化されているので、ユーザ機能抽出と同時にインターフェイスの抽出が出来るようになります。†くーすにクラス図は要りません。少なくとも、業務ロジック、補助ロジックについては、シーケンス図で表す以上の静的構造は存在しません。あるとすれば、バウンダリ層の作り(くーすのスコープ外)エンティティやDTOのデータ構造ぐらいです。これらについては、必要であれば作って下さい。†プロセスフローを参照して下さい。新業務フローを入力として、ロバストネス分析UIモック生成を平行して実施。ロバストネス図が出来たらUI設計ユーザ機能分析ER分析を平行して実施します。後は、これらの成果物を使って実装・テストを行うだけです。†これは、くーすの成果物ではなく、要求する入力になります。バウンダリのフローとして記述されます。業務フローを参照して下さい。HTMLなり、VBなり、作るシステムによって変わってきます。†インターフェイスとなるバウンダリバウンダリが呼び出すコントロールコントロールが関連するエンティティを纏めた図です。ロバストネス図を参照して下さい。†UIの実装に必要な情報を纏めたものです。UI仕様書(xls)を参照して下さい。†エンティティの仕様書です。オブジェクトとしての性質に加えて、テーブルの物理設計についての情報も含めます。エンティティ仕様書(xls)を参照して下さい。†UMLのシーケンス図で表したホワイトボックスシナリオです。シナリオ毎に作られます。シナリオシーケンス_ログインシナリオシーケンス_コメント一覧表示シナリオシーケンス_コメントを登録するを参照して下さい。†インターフェイスの仕様書です。実装クラスについての仕様書は作りません。実装クラスの仕様書が必要だと感じた場合は、シナリオシーケンスで抽出されていないユーザ機能があるかもしれません。コンポーネント仕様書(xls)を参照して下さい。外部設計完了後の顧客レビューは、やった方が良いです。他にも、内部設計完了後の顧客レビューをやることもあるかもしれません。それぞれ内部レビューはやっておくべきです。新業務フローが画面遷移に当たるので、そこからUIモックを作ることになります。難しいことはありません。UIモックはできるだけ早い段階で顧客レビューした方が良いです。質、量ともに重要で、発現が早くなる分リスクが減ります。同時にUIモックの作成をはじめた方が良いです。ロバストネス分析前にラフな画面イメージをレビューしてもらう感じです。このとき、「開発途中のものなので・・・」というフォローは使い方を気を付けましょう。顧客が、(本当はナビとしてこういう情報が必要だけど、それぐらいわかってるだろうし、開発中だから含まれてないんだろうな)というような思考になって要求が出てこないことがあります。†バウンダリのイベント毎に、システムに対してどのような作用を起こすかバウンダリの処理のためにどのような情報が必要かという観点でコントロールを抽出し、コントロールがどんなエンティティと関連するかということでエンティティを抽出します。ロバストネス分析を行う単位は、シナリオ毎が目安になります。複数シナリオを一枚にしても問題ありません。項目とデータの関連と入力チェックを中心に纏める。†エンティティ毎にエンティティの属性とその特性を纏める。事前の業務分析で分かっているものバウンダリから取れるものを集めればよいはずです。†シナリオをUMLのシーケンス図で書きます。バウンダリと業務ロジックとDAOを登場させます。次に、バウンダリから業務ロジックへコントロールに当たるメソッドを呼び出します。あとは、コントロールをアトミックなユーザ機能になるまで分解しながらシナリオが通るように進めます。シナリオは、しなければならないことならばできること(入力、処理結果による分岐)例外のケースについて分析します。このとき抽出されたユーザ機能は、ルールに基づいてインターフェイスに纏めながら進めます。シナリオ分析の粒度は、一つのシナリオです。ロバストネス分析と違って、複数のシナリオが纏められることは殆どありません。逆に一つのシナリオが大きくなりすぎることもあるため、そういう場合は、複数枚のシーケンス図に分解することになるかもしれません。全てのシナリオをシーケンス図に書き終わったらシナリオ分析完了です。あとは、インターフェイス毎に仕様書を書けば内部設計完了です。宣言的例外のメリットは、発生する例外を明示的に定義することです。デメリットは、処理しない場合に使用する側のシグネチャを汚染してしまうことです。これは、IDDとしては許容できないものです。例外的に使えるケースがあります。業務ロジックでRuntimeExceptionを投げられない、又は、投げたくない場合です。具体的には、EJBを使ってたり、EJBの代替実装にする場合などです。いう場合は、業務ロジックでRuntime系の例外を処理、又は、ラップして、宣言的例外で投げることになります。基本的にコントロールをトランザクション境界とします。特殊な要件が無い限りはこれでよいはずです。処理失敗時に自動再実行する場合、コントロールのトランザクションの外側で再度呼び出します。アスペクトでやるのが良いでしょう。一時的な状態(=セッション情報)は、画面からの入力を除けば、コントロールの戻りとして取得することになります。それを保持するかどうかなどは、まず、ロバストネス図の補足として記述する。その後、UI仕様書に記述する。いうことになると思います。俯瞰的なチェックがロバストネス図では難しい場合は、別途適切な表を作りましょう。共通メニューのようなバウンダリが想定できるのであれば、それを。出来ないのであれば、ログアウトリンクのようなバウンダリを設定し、ロバストネス分析を行います。その上で、どの画面に含まれるかという情報をバウンダリの補足として記述します。UI仕様書の作りとしても同様にした方が作業が楽になります。向いていたので修正しました。ソースリストは存在するのでしょうか。(土)「オブジェクト指向=ドメインモデル」という固定観念が強かったので本ページは大変勉強になります。09:34:50色弱なのでプロセスフローの線がみんな同じ色に見えます。22:13:27wikiでの記法が・・・。12:16:22添付ファイルのリンクをそのまま、[[hoge:link]]すればいいみたいです。「新業務フロー」のリンクをそうやって書いて見ました。21:03:06最新の10件を表示しています。