
086
は、将来アーキテクチャを発展させていく上でも適宜参照すべきものだ
からです。
様々な観点で設計判断を行った結果として、システムが具体的にどの
ような構成要素に分割され、それらがどのように相互作用するのかが定
まります。この論理的な構造をモデルとして表現したものがシステムの
形状です。
システムの形状はこれから開発するソフトウェアにおける重要な概念
や基本方針を表すものです。それらを実現するソースコードに変換する
ことで、はじめて動作可能なソフトウェアとしてシステムができあがり
ます。複数人の開発者が参加して開発を行う大規模なシステムでは、そ
の概念や基本方針を確実に実現するために文書・規約・ガイドライン一
式を取りそろえておく必要があります。
アーキテクチャ設計のアクティビティ
アーキテクチャ設計のアクティビティを図3.1.2に示します。これら
のアクティビティは必ずしもウォーターフォール的に順番に実施するわ
けではなく、実際にはイテレーティブに進めていくことになるでしょ
う。
アーキテクチャはアプリケーション機能の設計や開発が本格化する前
に固めておく必要があるため、プロジェクトの早い段階からこれらのア
クティビティを開始する必要があります。
ウォーターフォール開発プロセスでは要件定義フェーズにおいて実施
します。アジャイル開発プロセスでは初期のイテレーションで重点的に
これらのアクティビティに取り組みます。
各アクティビティの詳細については次節以降で説明します。