OOAD-オブジェクト指向設計

分析フェーズの後、概念モデルは、オブジェクト指向設計（OOD）を使用してオブジェクト指向モデルにさらに発展します。 OODでは、分析モデルの技術に依存しない概念が実装クラスにマッピングされ、制約が特定され、インターフェイスが設計され、ソリューションドメインのモデルが作成されます。一言で言えば、具体的な技術に基づいてシステムを構築する方法を指定する詳細な説明が作成されます。

オブジェクト指向設計の段階は次のように識別できます-

システムのコンテキストの定義
システムアーキテクチャの設計
システム内のオブジェクトの識別
設計モデルの構築
オブジェクトインターフェイスの仕様

システム設計

オブジェクト指向システムの設計では、システムのコンテキストを定義した後、システムのアーキテクチャを設計します。

コンテキスト-システムのコンテキストには、静的部分と動的部分があります。システムの静的コンテキストは、サブシステムの階層に展開されるシステム全体の単純なブロック図を使用して設計されています。サブシステムモデルは、UMLパッケージで表されます。動的コンテキストは、システムが環境とどのように相互作用するかを記述します。 *ユースケース図*を使用してモデル化されています。
システムアーキテクチャ-システムアーキテクチャは、アーキテクチャ設計の原則およびドメインの知識に従って、システムのコンテキストに基づいて設計されています。通常、システムはレイヤーに分割され、各レイヤーが分解されてサブシステムが形成されます。

オブジェクト指向の分解

分解とは、分割統治の原則に基づいて、大規模で複雑なシステムを、より複雑度の低い小さなコンポーネントの階層に分割することを意味します。システムの各主要コンポーネントはサブシステムと呼ばれます。オブジェクト指向分解は、システム内の個々の自律オブジェクトとこれらのオブジェクト間の通信を識別します。

分解の利点は-

個々のコンポーネントはそれほど複雑ではないため、より理解しやすく、管理しやすくなっています。
これにより、専門的なスキルを持つ従業員を分割できます。
他のサブシステムに影響を与えることなく、サブシステムを交換または変更できます。

並行性の特定

同時実行性により、複数のオブジェクトが同時にイベントを受信し、複数のアクティビティを同時に実行できます。並行性は動的モデルで識別および表現されます。

並行性を有効にするために、各並行要素には個別の制御スレッドが割り当てられます。並行性がオブジェクトレベルの場合、2つの並行オブジェクトには2つの異なる制御スレッドが割り当てられます。単一のオブジェクトの2つの操作が本質的に同時である場合、そのオブジェクトは異なるスレッドに分割されます。

並行性は、データの整合性、デッドロック、および飢starの問題に関連しています。したがって、並行性が必要な場合は常に明確な戦略を立てる必要があります。また、並行性は設計段階で特定する必要があり、実装段階に残すことはできません。

パターンの特定

アプリケーションの設計中に、いくつかのカテゴリの問題に一般的に受け入れられているソリューションが採用されています。これらはデザインのパターンです。パターンは、特定の種類のアプリケーション開発の問題で使用できる文書化されたビルディングブロックのセットとして定義できます。

いくつかの一般的に使用される設計パターンは次のとおりです-

ファサードパターン
モデルビュー分離パターン
観察者パターン
モデルビューコントローラーパターン
サブスクライブパターンを公開する
プロキシパターン

イベントの制御

システム設計中に、システムのオブジェクトで発生する可能性のあるイベントを特定し、適切に処理する必要があります。

イベントは、時間と空間に位置を持つ重要な発生の仕様です。

モデル化できるイベントには4つのタイプがあります。

信号イベント-あるオブジェクトによってスローされ、別のオブジェクトによってキャッチされた名前付きオブジェクト。
Call Event -操作のディスパッチを表す同期イベント。
Time Event -時間の経過を表すイベント。
Change Event -状態の変化を表すイベント。

境界条件の処理

システム設計段階では、システム全体および各サブシステムの初期化と終了に対処する必要があります。文書化されているさまざまな側面は次のとおりです-

システムの起動、つまり、初期化されていない状態から定常状態へのシステムの移行。
システムの終了、つまり、実行中のすべてのスレッドのクローズ、リソースのクリーンアップ、および送信されるメッセージ。
システムの初期構成と、必要な場合のシステムの再構成。
システムの障害または予期しない終了の予測。

境界条件は、境界ユースケースを使用してモデル化されます。

オブジェクト設計

サブシステムの階層が開発された後、システム内のオブジェクトが識別され、その詳細が設計されます。ここで、設計者はシステム設計中に選択した戦略を詳しく説明します。重点は、アプリケーションドメインの概念からコンピューターの概念にシフトします。分析中に識別されたオブジェクトは、実行時間、メモリ消費、および全体的なコストを最小限に抑えることを目的として、実装のためにエッチングされます。

オブジェクト設計には、次のフェーズが含まれます-

オブジェクト識別
オブジェクト表現、つまり設計モデルの構築
操作の分類
アルゴリズム設計
関係の設計
外部相互作用の制御の実装
クラスと関連付けをモジュールにパッケージ化する

オブジェクト識別

オブジェクト設計の最初のステップは、オブジェクトの識別です。オブジェクト指向の分析フェーズで識別されたオブジェクトは、クラスにグループ化され、実際の実装に適したように洗練されます。

この段階の機能は次のとおりです-

各サブシステムまたはパッケージ内のクラスの特定と改良
クラス間のリンクと関連付けを定義する
クラス間の階層的な関連付け、つまり、一般化/特殊化と継承の設計
集計の設計

オブジェクト表現

クラスを特定したら、オブジェクトモデリング手法を使用してそれらを表現する必要があります。この段階では、基本的にUMLダイアグラムを作成します。

生産する必要がある設計モデルの2種類があります-

静的モデル-クラス図とオブジェクト図を使用してシステムの静的構造を記述する。
動的モデル-システムの動的構造を記述し、相互作用図と状態図を使用してクラス間の相互作用を示します。

操作の分類

このステップでは、オブジェクトに対して実行される操作は、OOAフェーズで開発された3つのモデル、つまりオブジェクトモデル、動的モデル、機能モデルを組み合わせて定義されます。操作は、実行方法を指定するのではなく、実行内容を指定します。

操作に関して次のタスクが実行されます-

システム内の各オブジェクトの状態遷移図が作成されます。
操作は、オブジェクトが受け取るイベントに対して定義されます。
1つのイベントが同じオブジェクトまたは異なるオブジェクトで他のイベントをトリガーするケースが識別されます。
アクション内のサブオペレーションが識別されます。
主なアクションは、データフロー図に展開されます。

アルゴリズム設計

オブジェクトの操作は、アルゴリズムを使用して定義されます。アルゴリズムは、操作で発生した問題を解決する段階的な手順です。アルゴリズムは、その方法に焦点を当てています。

特定の操作に対応する複数のアルゴリズムが存在する場合があります。代替アルゴリズムが特定されると、特定の問題領域に最適なアルゴリズムが選択されます。最適なアルゴリズムを選択するためのメトリックは次のとおりです-

計算の複雑さ-複雑さは、計算時間とメモリ要件の観点からアルゴリズムの効率を決定します。
柔軟性-柔軟性は、さまざまな環境で適切性を失うことなく、選択したアルゴリズムを適切に実装できるかどうかを決定します。
理解度-これにより、選択したアルゴリズムが理解しやすく、実装しやすいかどうかが決まります。

関係のデザイン

関係を実装する戦略は、オブジェクトの設計段階で書き留める必要があります。対処される主な関係は、関連付け、集計、および継承で構成されます。

デザイナーは、関連付けに関して次のことを行う必要があります-

関連付けが単方向か双方向かを識別します。
関連付けのパスを分析し、必要に応じて更新します。
多対多の関係の場合、関連付けを個別のオブジェクトとして実装します。または、1対1または1対多の関係の場合は、他のオブジェクトへのリンクとして。

継承に関して、設計者は次のことを行う必要があります-

クラスとその関連付けを調整します。
抽象クラスを識別します。
必要なときに動作が共有されるようにプロビジョニングします。

制御の実装

オブジェクト設計者は、ステートチャートモデルの戦略に改良点を組み込むことができます。システム設計では、動的モデルを実現するための基本的な戦略が作成されます。オブジェクトの設計中、この戦略は適切な実装のために適切に装飾されます。

動的モデルの実装のためのアプローチは次のとおりです-

プログラム内の場所として状態を表す-これは、制御の場所がプログラムの状態を定義する従来の手順駆動型のアプローチです。有限状態マシンはプログラムとして実装できます。遷移は入力ステートメントを形成し、メイン制御パスは命令のシーケンスを形成し、分岐は条件を形成し、逆方向パスはループまたは反復を形成します。
ステートマシンエンジン-このアプローチは、ステートマシンエンジンクラスを通じてステートマシンを直接表します。このクラスは、アプリケーションが提供する一連の遷移とアクションを通じてステートマシンを実行します。
同時タスクとしての制御-このアプローチでは、オブジェクトはプログラミング言語またはオペレーティングシステムのタスクとして実装されます。ここでは、イベントはタスク間呼び出しとして実装されます。実際のオブジェクトの固有の並行性を保持します。

パッケージングクラス

大規模なプロジェクトでは、実装をモジュールまたはパッケージに細かく分割することが重要です。オブジェクトの設計中、クラスとオブジェクトはパッケージにグループ化され、複数のグループがプロジェクトで協力して作業できるようにします。

パッケージングのさまざまな側面は-

外部情報から内部情報を非表示-クラスを「ブラックボックス」として表示し、クラスのクライアントがコードを変更することなく、クラスの実装を変更できます。
要素の一貫性-クラス、操作、またはモジュールなどの要素は、一貫した計画で編成され、そのすべての部分が本質的に関連しているため、共通の目標に役立つ場合、一貫性があります。
物理モジュールの構築-次のガイドラインは、物理モジュールを構築する際に役立ちます-
モジュール内のクラスは、同じ複合オブジェクト内の類似のものまたはコンポーネントを表す必要があります。
密接に接続されたクラスは同じモジュール内にある必要があります。
未接続または弱接続のクラスは、別々のモジュールに配置する必要があります。
モジュールは良好な結束性、つまり、コンポーネント間の高度な連携が必要です。
モジュールは、他のモジュールとの結合度が低い必要があります。つまり、モジュール間の相互作用または相互依存は最小限でなければなりません。

設計の最適化

分析モデルはシステムに関する論理情報をキャプチャし、設計モデルは詳細を追加して効率的な情報アクセスをサポートします。設計を実装する前に、実装をより効率的にするために設計を最適化する必要があります。最適化の目的は、時間、スペース、およびその他のメトリックに関してコストを最小化することです。

ただし、実装の容易さ、保守性、および拡張性も重要な関心事であるため、設計の最適化は過剰であってはなりません。完全に最適化された設計はより効率的ですが、読みにくく再利用性が低いことがよく見られます。したがって、設計者はこの2つのバランスを取る必要があります。

設計の最適化のために行われる可能性のあるさまざまなことは-

冗長な関連付けを追加する
使用できない関連付けを除外する
アルゴリズムの最適化
派生属性を保存して、複雑な式の再計算を回避します

冗長な関連付けの追加

設計の最適化中に、新しい関連付けを導出することでアクセスコストを削減できるかどうかがチェックされます。これらの冗長な関連付けによって情報が追加されることはありませんが、モデル全体の効率が向上する場合があります。

使用できないアソシエーションの省略

関連付けが多すぎると、システムが判読不能になり、システムの全体的な効率が低下する可能性があります。そのため、最適化中に、使用できない関連付けはすべて削除されます。

アルゴリズムの最適化

オブジェクト指向システムでは、データ構造とアルゴリズムの最適化は共同で行われます。クラスの設計が完了したら、操作とアルゴリズムを最適化する必要があります。

アルゴリズムの最適化は以下によって得られます-

計算タスクの順序の並べ替え
ループの実行順序を、機能モデルで定められた順序と逆にする
アルゴリズム内のデッドパスの削除

派生属性の保存と保存

派生属性は、値が他の属性（基本属性）の関数として計算される属性です。必要なたびに派生属性の値を再計算することは、時間のかかる手順です。これを回避するために、値を計算し、計算された形式で保存できます。

ただし、これは更新の異常、つまり、派生属性の値に対応する変更がないベース属性の値の変更を引き起こす可能性があります。これを回避するには、次の手順が実行されます-

ベース属性値が更新されるたびに、派生属性も再計算されます。
すべての派生属性は、各更新後ではなく、グループ内で定期的に再計算および更新されます。

設計ドキュメント

ドキュメントは、ソフトウェアの作成手順を記録するソフトウェア開発プロセスの重要な部分です。他の人に設計を送信するために、重要なソフトウェアシステムの設計決定を文書化する必要があります。

利用分野

二次製品ですが、特に次の分野では、優れたドキュメントが不可欠です-

多くの開発者によって開発されているソフトウェアの設計
反復的なソフトウェア開発戦略
ソフトウェアプロジェクトの後続バージョンの開発において
ソフトウェアの評価用
テストの条件と領域を見つけるため
ソフトウェアのメンテナンス用。

内容

有益なドキュメントには、本質的に次の内容を含める必要があります-

高レベルのシステムアーキテクチャ-プロセス図とモジュール図
主要な抽象化とメカニズム-クラス図とオブジェクト図。
主な側面の動作を説明するシナリオ-動作図

特徴

優れたドキュメントの特徴は次のとおりです-

簡潔かつ同時に、明確で一貫性のある完全な
システムの要件仕様にトレーサブル
よく構成された
記述的ではなく図式的

Object-oriented-analysis-design-ooad-object-oriented-design

目次