ICONIX - 1.Domain分析
ICONIXの分析工程 ここでは、ICONIXの分析工程を見てゆきます。最初に全てのベースとなる静的モデルのドメイン分析、続けて動的モデルのユースケース分析、ロバストネス分析、そしてシーケンス分析と進みます。この過程で、全ての主要な用語はドメイン分析で作成したドメインモデル(用語集)を元に行わなければなりません。
例えば、ドメインモデルに「ユーザー」と定義したならば、以降の分析に現れる用語は「利用者」ではなく「ユーザー」です。用語のブレを許さずに「ユーザー」に統一しなければなりません。逆に「利用者」の方が適切だと思ったならば、以降の分析で使う文書の訂正より先にドメインモデルを書き直す必要があります。それほどドメインモデルは影響力の高いものなわけです。
では、そのドメインの分析から始めたいと思います。
ドメイン分析 ドメインモデルは全ての工程の基本となります。何故ならそれが正規の用語集となるからです。フワフワとした曖昧な言葉を棄て、正確で本質的な用語を捉えてゆくと、思考がクリアになります。また、ドメイン用語は属性も定義しますので、誰かが「ユーザー」と記述 (会話) した際、そこに「ユーザーID」「氏名」「住所」等の関連属性が含まれているか否かという点も明確になります。
ですから、仮に「ユーザーID」や「氏名」「住所」等が含まれていた場合は、記述や会話の中で「ユーザー」という表現が出た場合にこれらの情報も含むことが分かるわけです。厳密さだけではなく簡潔さも手に入れる事ができます。会話と文書が徐々に変わってゆくのが体験できるかも知れません。
Before: システムはユーザID, 氏名, 住所を画面に表示する。
After : システムはユーザー情報をユーザー詳細画面に表示する。
ドメインモデルの抽出 ドメイン分析を行うには、最初にドメインモデルの候補を抽出します。これはドメインエキスパートが提供するユーザーストーリー等から導き出します。何やら難しそうに聞こえますが、ドメインエキスパートというのは業務に詳しい担当者、ユーザーストーリーとは業務の流れを説明した文章です。要は「業務担当者のお話を聞いたり文章を読んだりしてキーワードを見つける」という作業に過ぎません。
ユーザーストーリーが存在しない時は、関連がありそうな文書を漁ってみます。それは簡単なシステム化の企画書かも知れませんし、何らかのマニュアルや、時には誰かが残したメモかも知れません。文書化されたものがなければ業務担当者へのインタビューで代替するのも一案です。
主要なドメインモデルの選出 ドメインモデルの候補が抜き出せたら、候補の中から主要なドメインモデルを選出します。対象システムとの関連性が薄そうなモデルを一旦脇に寄せて主要なモデルだけを選りすぐります。
例えば営業支援システムを開発しているとします。“営業担当”, “売上実績” 等は関連が深そうですが、“社用車”, “出社時刻” 等は関連が薄そうです。こうして関連の深そうなモデルを主要なドメインモデルとします。
これが重要なのは、直前の工程で多くの候補が出た場合 その全てを分析するのは大変だからです。逆に利用頻度が高く重要なものに絞って分析すれば時間の節約になり効率の良い仕事ができます。
その他のモデルの分析も無意味ではありませんが、分析初期の貴重な時間が惜しいですし 分析初期の精度にもあまり期待できません。それよりかは重要なドメインモデルに絞って分析し、フィードバックを得ることで徐々に分析精度を高めた後に、その他のモデルを追加した方が効率的という考え方です。
スコープ外に区分けしたドメインモデルも、後から必要だと分かった時に分析することは可能なので、ここでは一旦スコープを限定してしまいます。
モデル名のチェック 抽出したドメインモデルには最初から名前が存在しますが、あくまで仮の名称として捉えてください。分析が進んでも名前が変更されない保証は何一つありません。「今までそう呼ばれてきたから」「その時はその名前が良さそうに見えたから」という程度の理由で名前付けされている可能性も高く本質的な名前とは限りません。勿論それが最適な名前である可能性もありますが、最初はそれを疑ってください。
例えば、以下に示すのはあまり良くない名前の例とその改善例です。
# 問題点 例 改善方針 改善例 1 抽象的すぎて他のモデルと衝突しがち 担当者 修飾子を付けて具体化 ○○社経理担当 2 名詞に見えるが実体は動詞 承認 別のモデルの「操作」に分類 「経理部長」内の「承認()」に移動 3 同じものに複数の名称が存在 - クレジットカード
