はじめに†
くーすとは†
ダイコン時代のシステム開発を効率化するための設計方法論です。
でもダイコンを使わなくてもくーすは使えます。
分類としては、IDD(Interface Driven Development)に当たるもので、
固有名として、くーす(古酒のこと、Kusu)と呼びます。
想定する読者†
業務系のシステム開発を安全に効率的に行いたいと思ってる方。
ダイコンについてある程度理解していることが望ましいですが、必須ではありません。
ゲーム開発や、自然科学系のシステム開発などには向かないかも知れません。
- ロバストネス分析
- ユースケースから分析クラス図を作るための分析法。
但しオリジナルを知っている必要は無くて、そういう名前であると思ってもらえばよいです。
- バウンダリ
- システム境界に当たるインターフェイス。画面、帳票、外部システムとのI/F等
- コントロール
- バウンダリから呼び出される処理のこと。
くーすでは、コントロールをユーザ機能に分解していく。
- ユーザ機能
- <オブジェクト>(<結果>)<アクション>で表される機能のこと。
「〜(の〜)を〜する」みたいな感じ。
アトミックなユーザ機能と、それを呼び出すフロー的なユーザ機能に分かれる。
最終的にインターフェイスのメソッドになる。
- エンティティ
- リソースにマッピングされる必要があるデータオブジェクト。
エンティティをリソースとやり取りするためにDAOが作られる
- リソース
- DBMSやファイルなどの永続的なもの。
- DTO(Data Transfer Object)
- リソースにマッピングされないデータオブジェクト。
バウンダリが要求する加工済みの情報をやり取りする場合のオブジェクト。
- DAO(Data Access Object)
- エンティティとリソースのマッピングを担うオブジェクト。
ユーザ機能からインターフェイスが作られて、リソースに対応して実装される。
- 業務ロジック
- バウンダリから呼び出されるロジック。
基本的に、業務ロジックに当たるユーザ機能をさして使うが、
インターフェイスをさして使ってもよい。(連動しているので誤解は無い)
厳密に言う場合、業務ロジックインターフェイスと呼ぶ。
- 補助ロジック
- 業務ロジックから呼び出されるロジック。
あとは、業務ロジックと同様。
- シナリオ
- アクターの目的を達成するためのシステムとのやり取り、及び一連のシステム動作の記述
この文書でのシナリオの粒度は、システムに対する1トランザクションの処理と考えて下さい。
「コメントを登録する」、「利用者の情報を変更する」のような感じです。