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

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

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

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

システムデザイン

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

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

オブジェクト指向の分解

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

分解の利点は次のとおりです。

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

並行性の識別

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

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

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

パターンの識別

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

一般的に使用されるデザインパターンは次のとおりです。

ファサードパターン
モデルビューの分離パターン
オブザーバーパターン
モデルビューコントローラーパターン
パブリッシュサブスクライブパターン
プロキシパターン

イベントの制御

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

イベントは、時間と空間に場所がある重要な発生の仕様です。

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

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

境界条件の処理

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

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

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

オブジェクト設計

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

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

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

オブジェクトの識別

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

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

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

オブジェクト表現

クラスが識別されたら、オブジェクトモデリング技法を使用してそれらを表す必要があります。この段階では、基本的にUML図を作成します。

作成する必要のある設計モデルには2つのタイプがあります-

Static Models −クラス図とオブジェクト図を使用してシステムの静的構造を説明する。
Dynamic Models −システムの動的構造を記述し、相互作用図と状態図を使用してクラス間の相互作用を示します。

業務の分類

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

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

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

アルゴリズム設計

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

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

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

関係のデザイン

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

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

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

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

クラスとその関連付けを調整します。
抽象クラスを識別します。
必要なときに行動が共有されるように準備します。

制御の実装

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

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

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

パッケージングクラス

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

パッケージングのさまざまな側面は次のとおりです。

Hiding Internal Information from Outside View −クラスを「ブラックボックス」と見なすことができ、クラスのクライアントがコードを変更しなくても、クラスの実装を変更できます。
Coherence of Elements −クラス、操作、モジュールなどの要素は、一貫した計画に基づいて編成され、そのすべての部分が本質的に関連しているため、共通の目標を達成できる場合、一貫性があります。
Construction of Physical Modules −以下のガイドラインは、物理モジュールを構築する際に役立ちます−
- モジュール内のクラスは、同じ複合オブジェクト内の類似したものまたはコンポーネントを表す必要があります。
- 密接に接続されたクラスは、同じモジュール内にある必要があります。
- 接続されていないクラスまたは接続が弱いクラスは、別々のモジュールに配置する必要があります。
- モジュールは、良好な結合性、つまり、コンポーネント間の高度な連携を備えている必要があります。
- モジュールは他のモジュールとの結合度が低い必要があります。つまり、モジュール間の相互作用または相互依存は最小限である必要があります。

設計の最適化

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

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

設計の最適化のために実行できるさまざまなことは次のとおりです。

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

冗長な関連付けの追加

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

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

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

アルゴリズムの最適化

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

アルゴリズムの最適化は、次の式で得られます。

計算タスクの順序の再配置
機能モデルに規定されているものからのループの実行順序の逆転
アルゴリズム内のデッドパスの削除

派生属性の保存と保存

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

ただし、これにより、更新の異常が発生する可能性があります。つまり、基本属性の値が変更され、派生属性の値に対応する変更がない場合があります。これを回避するために、次の手順が実行されます-

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

設計ドキュメント

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

使用領域

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

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

内容

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

High–level system architecture −プロセス図とモジュール図
Key abstractions and mechanisms −クラス図とオブジェクト図。
Scenarios that illustrate the behavior of the main aspects −行動図

特徴

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

簡潔であると同時に、明確で一貫性があり、完全である
システムの要件仕様にトレーサブル
Well-structured
説明的ではなく図式的