システム化の対象範囲
本システムはAdventureWorks基幹システムで利用するデータベース上の次のマスター管理を提供します。トランザクションデータに関しては、異なるサブシステム上で管理します。
本システムで管理対象となるマスターテーブルは次のとおりです。
-
Person.BusinessEntity
-
Person.Person
- HumanResources.Employee
- HumanResources.Gender
- HumanResources.MaritalStatus
- ...
なお本システムのスコープに入るテーブルですが、次のテーブルに関しては変更頻度が極端に低いことが想定されるため、システムとして提供は行わず定期的なメンテナンスにて直接データベースを更新するものとします。
- HumanResources.Gender
- HumanResources.MaritalStatus
- ...
AdventureWorks従業員管理システムのアーキテクチャ設計
それではさっそく、本システムを構築するためのアーキテクチャについて説明していきましょう。
システムを構築するための重要な決定事項（アーキテクチャ）と、その決定理由について解説し、必要と思われる個所では実際のコードを例にとって解説します。
本稿でアーキテクチャを記載するにあたり、Rational Unified Process（RUP）にて提唱された4＋1ビューを用いて記載・説明していきます。
まずユースケースビューで、システム全体のユースケースから、アーキテクチャを決定するために重要となるユースケースを抽出します。
続いて、システム全体の論理構成を論理ビューで決定し、それを物理的にどう配置するか配置ビューで決定します。
その後、論理ビュー・配置ビューの決定事項に従い、抽出されたアーキテクチャ上重要なユースケースの実現方法を、実装ビューにて説明します。
最後にプロセスビューでは、並行性やパフォーマンス要件で特に重要と考えられる事項について検討しますが、本稿では非機能要求を規定することは難しいため、対象外といたします。
ユースケースビュー
本節では、システムのアーキテクチャを決定するために重要となるユースケースを選定します。
ユースケースとは、利用者にとってシステムを利用する価値を表し、一つ以上の機能の組み合わせによって提供されます。
ユースケースと機能は明確に異なります。例えばユーザーを登録する際に、性別をプルダウンで選択するとします。これは明確に「機能」ですが、性別をプルダウンで選択すること自体は、利用者の最終的な価値になりません。ユースケースとはあくまでも利用者に価値を提供するための、一つ以上の機能の集合を表すものとします。
本稿では、次のユースケースを対象にアーキテクチャを決定することとします。
アーキテクチャを決定する上で重要なユースケースは次の三つです。
- ログインする
- 従業員を閲覧する
- 従業員を編集する
ログインする
厳密に言うと「ログイン」はユースケースではありません。ユースケースを実行するための前提条件となる機能です。ログインは他のユースケースを利用するための前提条件であり、他のユースケースを構成する一つの機能に過ぎません。
しかしログインを他のユースケースの一部とした場合、すべてのユースケースで重複した記述（仕様や設計など）が発生してしまいます。また、ユースケースは機能ではありますが、アーキテクチャ上特別に重要な機能でもあります。
仕様書や設計書を記述していく上でユースケース駆動を採用した場合、本来はユースケースではないものでも、ユースケースとして管理したほうがプロジェクト全体で都合の良いものもあります。
このため、あえてユースケースとして定義し、必要となるアーキテクチャを検討するものとします。
ログインにおける認証には、統合Windows認証を利用します。本稿では認可については検討対象としません。
従業員を閲覧する
本システムの主となる機能で、従業員の一覧の表示、絞り込み、ソートといった機能を提供します。
管理対象とする社員は多くないため（現時点で290名）、すべての社員をグリッド上に表示し、その上でフィルターによる絞り込みや、ソートなどをExcelライクな操作感で提供することを望まれています。
従業員を編集する
「従業員を閲覧する」ユースケースを拡張し、グリッド上で表示している従業員の編集および新規追加を行います。
本ユースケースは、ユーザー インターフェースからデータベースまでの相互作用としては「従業員を閲覧する」と大きく異なりません。しかし、ユーザー インターフェースの実現にあたり、検討すべき課題が多くあるため、検討・記載することとします。
