分析段階の後、概念モデルはさらにオブジェクト指向設計（OOD）を使用してオブジェクト指向モデルへと開発される。 OODでは、分析モデル中の技術に依存しない概念を実装クラスにマッピングし、制約条件を特定し、インタフェースを設計し、ソリューションドメインのモデルを実現する。 一言で言えば 具体的な技術に基づいて、どのようにシステムを構築するかを詳細に記述する
オブジェクト指向設計の段階は、以下のように特定できる。 システム
システム設計
Object-of指向性システム設計では、システムのコンテキストを定義し、次にシステムのアーキテクチャを設計します。
-
Context – システムのコンテキストには、静的な部分と動的な部分がある。 システムの静的コンテキストは、システム全体の単純なブロック図を使用して設計され、それはサブシステムの階層に拡張される。 サブシステムのモデルはUMLパッケージで表現される。 動的なコンテキストは、システムが環境とどのように相互作用するかを記述します。 システムアーキテクチャ – システムアーキテクチャは、アーキテクチャ設計の原則とドメインの知識に従って、システムのコンテキストに基づいて設計されます。 典型的には、システムは層に分割され、各層はサブシステムを形成するために分解される。
オブジェクト指向分解
分解とは、分割と征服の原則に基づいて、大きな複雑システムを、より複雑度の小さいコンポーネントの階層に分割することを意味する。 システムの各主要コンポーネントはサブシステムと呼ばれる。
分解の利点は、-
-
個々の構成要素は複雑度が低いので、より理解しやすく管理しやすい。
-
専門技能を持つ労働者の分割が可能になる。
-
それは、他のサブシステムに影響を与えることなく、サブシステムを交換または変更することを可能にします。
Identifying Concurrency
同時性は、同時にイベントを受信する複数のオブジェクトと同時に実行する複数の活動を可能にします。 同時実行は動的モデルで識別され表現される。
同時実行を可能にするために、各同時実行要素は制御の別々のスレッドが割り当てられる。 同時性がオブジェクトレベルである場合、2つの同時実行オブジェクトには制御の2つの異なるスレッドが割り当てられる。 1 つのオブジェクトの 2 つの操作が本質的に同時である場合、そのオブジェクトは異なるスレッド間で分割されます。
同時実行は、データの整合性、デッドロック、および飢餓の問題に関連しています。 そのため、並行処理が必要な場合は常に明確な戦略を立てる必要がある。 さらに、並行処理は設計段階で特定される必要があり、実装段階に残しておくことはできない。
パターンの特定
アプリケーションを設計している間、いくつかの一般に認められた解決策が問題のいくつかのカテゴリに対して採用される。 これらは設計のパターンである。 パターンは、ある種のアプリケーション開発問題で使用できる文書化されたビルディングブロックのセットとして定義することができる。
Some commonly used design patterns are –
- Façade pattern
- Model view separation pattern
- Observer pattern
- Model View Controllerパターン
- Publish subscribeパターン
- Proxy パターン
イベントの制御
システム設計時に、イベントを制御する。 システムのオブジェクトで発生する可能性のあるイベントを特定し、適切に対処する必要があります。
事象とは、時間的、空間的に場所を持つ重要な発生の特定である。
モデル化できるイベントには、次の4つのタイプがある。 –
-
Signal Event – あるオブジェクトによって投げられ、別のオブジェクトによってキャッチされる名前付きオブジェクト。
-
Call Event – 操作の派遣を表す同期型イベント。
-
Time Event – 時間の経過を表すイベント。
-
Change Event – 状態の変化を表すイベント。
境界条件の処理
システム設計段階では、システム全体およびそれぞれのサブシステムの初期化と終了を扱う必要があります。 文書化されるさまざまな側面は次のとおりです。 –
-
システムの起動、すなわち、非初期化状態から定常状態への移行。
-
システムの初期構成と、必要な場合のシステムの再構成。
境界条件は境界ユースケースを使用してモデル化される。
オブジェクト設計
サブシステムの階層を開発した後、システム内のオブジェクトを識別し、その詳細設計をする。 ここでは、設計者はシステム設計中に選択した戦略を詳細に説明する。 アプリケーション領域の概念からコンピュータの概念へと重点が移行する。 分析中に特定されたオブジェクトは、実行時間、メモリ消費量、および全体的なコストを最小限に抑えることを目的として、実装のために刻み込まれる。 設計モデルの構築
オブジェクト識別
オブジェクト設計の最初のステップはオブジェクト識別である。 オブジェクト指向の分析段階で特定されたオブジェクトは、クラスにグループ化され、実際の実装に適するように洗練される。
-
この段階の機能は、 –
- それぞれのサブシステムまたはパッケージのクラスを特定し、洗練する
-
クラス間のリンクと関連を定義する
-
クラス間の階層的関連、すなわち、設計すること。 一般化/特殊化および継承
-
Designing aggregations
オブジェクト表現
クラスが識別されると、それらはオブジェクトモデリング技術を使用して表される必要があります。 この段階では、基本的に UML 図を作成します。
作成する必要がある設計モデルには 2 つのタイプがあります –
-
Static Models – クラス図とオブジェクト図を使ってシステムの静的構造を記述すること。
-
動的モデル – システムの動的構造を記述し、相互作用図や状態図を使ってクラス間の相互作用を示す。
操作の分類
この段階では、OOAフェーズで開発した三つのモデル、すなわちオブジェクトモデル、動的モデル、機能モデルを組み合わせてオブジェクトに対して実行すべき操作内容を定義する。 オペレーションは、何が行われるべきかを指定し、どのように行われるべきかは指定しない。
オペレーションに関して以下の作業が行われる –
-
システム内の各オブジェクトの状態遷移図を作成する。
-
オペレーションは、オブジェクトにより受け取られるイベントに対して定義される。
-
あるイベントが同じまたは異なるオブジェクトの他のイベントをトリガーするケースが識別される。
-
アクション内のサブ操作が識別される。
-
メインアクションはデータフロー図に展開される。
アルゴリズム設計
オブジェクト内の操作はアルゴリズムを使って定義される。 アルゴリズムとは、オペレーションで敷設された問題を解決する段階的な手順である。 アルゴリズムは、それがどのように行われるかに焦点を当てる。
与えられたオペレーションに対応するアルゴリズムは1つ以上存在する場合がある。 代替アルゴリズムが特定されると、与えられた問題領域に対して最適なアルゴリズムが選択される。 最適なアルゴリズムを選択するための指標は、-
-
Computational Complexity – Complexityは、計算時間およびメモリ要件の観点から、アルゴリズムの効率を決定する。
-
Flexibility – Flexibilityは、選択したアルゴリズムが、種々の環境において適切性を損なうことなく実装可能であるかどうかを判断する。
-
Understandability – これは、選択したアルゴリズムが理解しやすく実装しやすいかどうかを判断します。
関係の設計
関係を実装する戦略は、オブジェクト設計段階で明確にする必要があります。
設計者は、関連について次のことを行う必要があります –
-
関連が単方向か双方向かどうかを識別する。
-
関連付けのパスを分析し、必要に応じて更新する。
-
多対多の関係の場合は個別のオブジェクトとして、1対1または1対多の関係の場合は他のオブジェクトへのリンクとして、関連付けを実装する。
継承に関して、設計者は次のことを行うべきである –
-
クラスとその関連を調整する。
-
必要なときに動作が共有されるように規定を設ける。
制御の実装
オブジェクト設計者はステートチャートモデルの戦略の洗練を取り入れることができる。 システム設計では、ダイナミックモデルを実現するための基本戦略が作られる。 3406>
動的モデルの実装のためのアプローチは、 –
-
プログラム内の場所として状態を表す – これは、制御の場所がプログラム状態を定義する伝統的な手順駆動型のアプローチである。 有限状態機械は、プログラムとして実装することができます。 遷移は入力ステートメントを形成し、主制御パスは命令シーケンスを形成し、分岐は条件を形成し、後方パスはループまたは反復を形成します。 このクラスは、アプリケーションによって提供される一連の遷移およびアクションを通じてステートマシンを実行します。
-
Control as Concurrent Tasks – このアプローチでは、オブジェクトがプログラミング言語またはオペレーティング システムのタスクとして実装されます。 ここでは、イベントはタスク間呼び出しとして実装されます。
クラスのパッケージ化
大規模なプロジェクトでは、実装をモジュールまたはパッケージに綿密に分割することが重要である。 オブジェクト設計では、クラスおよびオブジェクトは、複数のグループがプロジェクトで協力的に作業できるようにパッケージにグループ化されます。
-
外部のビューから内部情報を隠す – これはクラスを「ブラック ボックス」として見ることができ、クラスのクライアントがコードを修正する必要なしにクラスの実装を変更することを許可します。
-
要素の一貫性 – クラス、オペレーション、モジュールなどの要素は、一貫した計画に基づいて組織化されており、すべての部分が共通の目標に役立つように本質的に関連している場合、首尾一貫していると言えます。
-
物理モジュールの構築 – 物理モジュールを構築する際には、以下のガイドラインが役立つ –
-
モジュールのクラスは、同じ複合オブジェクトの類似のものまたはコンポーネントを表すべきである。
-
密接に接続されたクラスは、同じモジュールにあるべきです。
-
接続されていない、または弱く接続されているクラスは、別々のモジュールに配置されるべきです。
-
モジュールは、他のモジュールとの結合が低く、モジュール間の相互作用または相互依存が最小であるべきです。
Design Optimization
分析モデルはシステムに関する論理情報を取得し、設計モデルは効率的な情報アクセスのサポートに詳細を追加します。 設計が実装される前に、実装をより効率的にするために最適化する必要がある。 最適化の目的は、時間、空間、およびその他の測定基準の観点からコストを最小化することです。
しかしながら、実装の容易さ、保守性、および拡張性も重要な関心事であるため、設計最適化は過剰であってはなりません。 完全に最適化された設計は効率的ですが、可読性および再利用性は低くなるということがよくあります。 ですから、設計者はこの2つのバランスを取る必要があります。
設計最適化のために行うことができるさまざまなことは、 –
- Adundant Associations
- Omit non-usable associations
- アルゴリズムの最適化
- 複雑な式の再計算を避けるために派生属性を保存
Addition of Redundant Associations
During design optimization, 新しい関連付けを行うことで、アクセスコストを削減できるかどうかがチェックされます。 これらの冗長な関連は情報を追加しないかもしれないが、モデル全体の効率を上げるかもしれない。
Non-Usable Associations
あまりにも多くの関連はシステムを解読不能にし、それゆえシステムの全体効率を低下させるかもしれない。 そのため、最適化の際に、すべての使用不可能な関連付けが削除される。
アルゴリズムの最適化
オブジェクト指向システムでは、データ構造とアルゴリズムの最適化は協調して行われます。 クラス設計ができたら、演算とアルゴリズムを最適化する必要がある。
アルゴリズムの最適化は、-
- 計算タスクの順序の再調整
- ループの実行順序を機能モデルで定めたものから逆転させる
- アルゴリズム内のデッドパスの除去
ことで得られる。
派生属性の保存と格納
派生属性とは、値が他の属性（ベース属性）の関数として計算される属性のことである。 派生属性の値が必要となるたびに再計算するのは時間のかかる手順です。 これを避けるために、値を計算し、その計算された形で保存することができる。
しかし、これは更新異常、すなわち、ベース属性の値の変化と派生属性の値の変化が対応しないことをもたらすかもしれない。 これを回避するために、以下の手順が取られる –
-
ベース属性値の各更新で、派生属性も再計算される。
-
すべての派生属性は、各更新後ではなく、グループで定期的に再計算され更新される。
Design Documentation
ドキュメンテーションは、ソフトウェアを作る手順を記録するあらゆるソフトウェア開発プロセスの不可欠な部分である。 設計の決定は、設計を他の人に伝えるために、どんな非自明なソフトウェアシステムでも文書化される必要がある。
Usage Areas
二次製品ではあるが、良いドキュメントは必要不可欠である。 特に次のような分野で活用されている。
- 多くの開発者によって開発されるソフトウェアの設計
- 反復的ソフトウェア開発戦略
- ソフトウェアプロジェクトの後続バージョンの開発
- ソフトウェアの評価
- テストの条件と領域の発見
- ソフトウェアのメンテナンス。
内容
有益な文書は基本的に以下の内容を含むべきである –
-
高レベルシステムアーキテクチャ -プロセス図とモジュール図
-
主要な抽象化と機構 -クラス図とオブジェクト図。
-
主要な側面の動作を説明するシナリオ – 動作図
特徴
良い文書の特徴は –
-
簡潔であると同時に、あいまいさがないこと。 一貫性、完全性
-
システムの要求仕様にトレーサブル
-
よく構成された
-
説明的ではなく図表的
宣伝文句のようになります。
-