Part11は，システムのアプリケーション構成を明確にしました。Part12では，アプリケーションのアーキテクチャとインフラのアーキテクチャを明らかにします。そして，本講座において作成したモデルを提案依頼書に活用します。
Part12は，システムレベルのモデリングの4回目です。Part11では，ユースケースとデータを対応付けてそれらの関係を明らかにし，システムのアプリケーション構成を明確にした上で，コンポーネントに分割しました。
Part12の演習の目的は，システムのソフトウエア構成を明確にすることと，システムのインフラ構成を明確にすることです。具体的な作業として，演習では「アーキテクチャ図」と「インフラ図」を作成します（図1）。
また、これまでの総まとめとして，モデルを活用したRFP（Request For Proposal：提案依頼書）を取り上げます。
ソフトウエア構成を明確化
Part12の1つ目の演習は，システムのソフトウエア構成をアーキテクチャ図で可視化することです。ソフトウエア構成を明確にすることで，システムの複雑性を低減して，保守性や再利用性を向上させます。表記法はUMLの「パッケージ図」です。サンプルを図2に示します。
ソフトウエアコンポーネントの分類（レイヤ）は，上部の左側に小さな長方形（タブ）の付いた大きな長方形（パッケージ）で表記します。レイヤ名は，タブの中に表記します。そのレイヤに属する個々のソフトウエアコンポーネントは，コンポーネントアイコンを先頭に付けて，パッケージ中に表記します。
今回は，サンプルとして，マイクロソフトのリファレンスアーキテクチャである「.NETのアプリケーション アーキテクチャ」（参考文献を参照）を取り上げて説明します。
プレゼンテーションレイヤ
プレゼンテーションレイヤは，利用者とのやり取りを担当します。ビジネスレイヤのコンポーネントを使用するので，ビジネスレイヤに依存します。「ユーザーインターフェイスコンポーネント」と「ユーザープロセスコンポーネント」が含まれます。
「ユーザーインターフェイスコンポーネント」は，個々のユーザーインタフェースを実現するためのコンポーネントです。例えば，顧客登録画面や受注登録画面などのことです。
「ユーザープロセスコンポーネント」は，複数のユーザーインタフェースを同期および協調動作させるためのコンポーネントです。例えば，受注を登録してから在庫を引き当てるまでの一連のやり取りを制御します。
ビジネスレイヤ
ビジネスレイヤは，ビジネスロジックを担当します。データレイヤのコンポーネントを使用するので，データレイヤに依存します。「ビジネスコンポーネント」と「ビジネスワークフロー」，「サービスインターフェイス」，「ビジネスエンティティコンポーネント」が含まれます。
「ビジネスコンポーネント」は，ビジネスレイヤの中心的なコンポーネントです。ビジネスルールを実装し，ビジネスタスクを実行するためのコンポーネントです。ビジネスタスクとは，例えば「顧客を登録する」や「在庫を検索する」などのことです。
「ビジネスワークフロー」は，長期間にわたる複数の手順を含む「長期ビジネスプロセス」の定義と調整を行います。例えば「注文」から「在庫引当」，「代金請求」，「納車」へ至るまでの手順をビジネスプロセス管理ツールで実装します。
「サービスインターフェイス」は，ビジネスロジックをサービスとして外部に公開するためのインタフェースです。例えば，中古車の在庫検索機能をWebサービスとして公開します。
「ビジネスエンティティコンポーネント」は，コンポーネント間でデータを受け渡すためのコンポーネントです。例えば，在庫データを在庫検索画面に渡します。
データレイヤ
データレイヤは，データの入出力を担当します。「データアクセスコンポーネント」と「サービスエージェント」が含まれます。
「データアクセスコンポーネント」は，データストアにアクセスする機能を一元管理するためのコンポーネントです。例えば，顧客データの生成と読み取り，更新，削除を行う処理があります。
「サービスエージェント」は，外部サービスを利用するためのコンポーネントです。例えば，Webサービスとして公開されている，中古車の在庫検索機能を利用します。
セキュリティ，運用管理，通信
これまでに説明した「プレゼンテーションレイヤ」と「ビジネスレイヤ」，「データレイヤ」以外にセキュリティや運用管理，通信のためのコンポーネントもあります。今回，図2では割愛しています。注意してください。
