業務分析について(3)

スキル

» 2009/10/05

　久しぶりの投稿になりました。

　個人事業に8月、9月と集中してきたのですが、課金って難しいなぁ～とマコトに痛感しています。マコトの顧客満足を目指す前に個人の信用力のなさ……。まぁわたしの事業戦略が甘いだけだとは思いますが、食べていけるほどお金が取れていないので、10月から業務委託契約を再開しました。扶養するべき家族がいるもので、収入が途切れることの恐怖は予想を超えていました(汗）。

　さて、今回はだいぶ期間が空いてしまいましたが、業務分析についての続編です。

■はじめに

　前回の業務分析について（2）では、動的モデル、機能モデル、静的モデルについてお伝えしました。今回は、機能モデルを掘り下げ、実装できるレベルに落とす方法を紹介します。

■機能モデルを詳細化してみる

　前回に引き続き、約定を取り消すというユースケースを対象に考えます。前回の機能モデルの発注等の余分なユースケースを除外し、下図の通り詳細化してみました。

　この詳細化した図は、ロバストネス図と呼ばれており、バウンダリ(黄)、コントローラ(青)、エンティティ(赤)という3要素で機能(ユースケース)を具体化して、実装できる形にまとめていくことを目的に使用しています。

■バウンダリ（ユーザーインターフェイス）

　図内のバウンダリ名称から一目瞭然と思いますが、バウンダリはユーザーインターフェイスです。

　バウンダリで重要なことは、関連するアクタ（FX業者や個人投資家）の漏れがないように要件を確認することです。今回は図で明記されていますが、仮に個人投資家に通知するバウンダリが漏れていた場合、後々になって機能を追加（コントローラとバウンダリ1つずつ、場合によては、エンティティも）しなければならなくなり、プロジェクトの遂行に支障が出る可能性があります。

　バウンダリは、画面仕様書のインプットとなります。画面レイアウト自体は、影響範囲が比較的狭いので優先度を低くしてよいのですが、データ項目については、とても重要です。なぜかというとデータ項目は、エンティティやデータトランスファーオブジェクトと関係が深く、重要なデータ項目を漏らすと修正の影響範囲が広くなる傾向にあるためです。

■コントローラ（サービス）

　コントローラは、システム内部で使用するサービスです。業務トランザクション（コミット、ロールバック←これは単純にDBトランザクションと対にはなりません）の粒度で統一することが重要です。また、ユーザ（ココでは個人投資家）毎の逐次処理を保障するロックの仕組み、他の（証拠金計算などのリアルタイム性が求められるような）機能との兼ね合いで性能が求められる場合のメモリキャッシュの仕組みなどもココに含めます。

　コントローラは、サービス仕様書のインプットとなります。

■エンティティ（論理データ）

　エンティティは、論理データ構造です。エンティティに振る舞いを定義したドメインオブジェクトによってできるだけ再利用性を高め、コントローラから効率よく使用されるようにします。また、データアクセスオブジェクトを定義して、物理データベースに永続化させます。システム要件に拠りますが、システムの拡張性や柔軟性を優先する場合は、バウンダリの項で定義したデータ項目と当該業種（ココでは金融）ドメインモデルをマージしながら作業を進めるとよろしいと思います（わたしは、ドメイン駆動開発が好きですが、そんな時間はなかなかとれないのが現実かなぁと）。

　エンティティは、テーブル仕様書のインプットとなります。

■おわりに

　これまでの連載でお気づきの方もいらっしゃると思いますが、ユーザの要求の源泉から今回のユースケースの詳細化までの一連の流れでトレーサビリティがとれていること（インプットとアウトプットが連鎖され、要求の源泉がどのような形で実装として担保されるか）がお分かりいただけたかと思います。

　この関係性を保っていくことが、ユーザーへの説明責任、プロジェクトの遂行責任上重要で、もし矛盾が生じているようなトコロがあれば、プロジェクト遂行のネックになりますので、熟慮（ココが腕の見せ所）が必要になります。

　今後の業務分析の続編は、トレーサビリティを基準として、今回の各種仕様書について掘り下げるか(より実装に近い方向)、逆にアクタ一覧やユースケースマトリクス（より要件定義に近い方向）の話にするか、コメント内容などで決めたいと思います。