OOAD-オブジェクト指向のパラダイム

簡単な歴史

オブジェクト指向のパラダイムは、新しいプログラミングアプローチの最初のコンセプトから形になりましたが、設計と分析の手法への関心はずっと後になりました。

最初のオブジェクト指向言語は、1960年にノルウェーコンピューティングセンターの研究者によって開発されたSimula（実システムのシミュレーション）でした。
1970年、アランケイと彼のゼロックスパークの研究グループは、Dynabookという名前のパーソナルコンピューターと、Dynabookをプログラミングするための最初の純粋なオブジェクト指向プログラミング言語（OOPL）であるSmalltalkを作成しました。
1980年代、Grady Boochは、主にプログラミング言語Adaの設計を提示したObject Oriented Designという論文を発表しました。その後のエディションでは、彼はアイデアを完全なオブジェクト指向設計方法に拡張しました。
1990年代、Coadは行動指向のアイデアをオブジェクト指向のメソッドに組み込みました。

その他の重要な革新は、James RumbaughによるObject Modeling Techniques（OMT）とIvar JacobsonによるObject-Oriented Software Engineering（OOSE）です。

オブジェクト指向分析

オブジェクト指向分析（OOA）は、相互作用するオブジェクトで構成されるソフトウェアシステムのオブジェクトモデルに関して、ソフトウェアエンジニアリング要件を特定し、ソフトウェア仕様を開発する手順です。

オブジェクト指向分析と他の形式の分析の主な違いは、オブジェクト指向アプローチでは、データと機能の両方を統合するオブジェクトを中心に要件が編成されることです。それらは、システムが対話する実世界のオブジェクトをモデルにしています。従来の分析方法では、2つの側面-機能とデータ-は別々に考慮されます。

Grady BoochはOOAを「オブジェクト指向分析とは、問題領域の語彙に見られるクラスとオブジェクトの観点から要件を調べる分析方法」と定義しています。

オブジェクト指向分析（OOA）の主なタスクは次のとおりです-

オブジェクトを識別する
オブジェクトモデル図を作成してオブジェクトを整理する
オブジェクトの内部、またはオブジェクト属性の定義
オブジェクトの動作、つまりオブジェクトアクションの定義
オブジェクトの相互作用を説明する

OOAで使用される一般的なモデルは、ユースケースとオブジェクトモデルです。

オブジェクト指向設計

オブジェクト指向設計（OOD）には、オブジェクト指向分析中に作成された概念モデルの実装が含まれます。 OODでは、技術に依存しない分析モデルの概念が実装クラスにマッピングされ、制約が識別され、インターフェイスが設計されます。その結果、ソリューションドメインのモデル、つまりシステムの詳細な説明が作成されます。具体的な技術に基づいています。

実装の詳細は一般的に含まれています-

クラスデータの再構築（必要な場合）、
メソッドの実装、つまり内部データ構造とアルゴリズム、
制御の実装、および
関連付けの実装。

Grady Boochは、オブジェクト指向設計を「設計中のシステムの論理モデルと物理モデル、静的モデルと動的モデルの両方を描くためのオブジェクト指向分解プロセスと表記法を含む設計方法」と定義しています。

オブジェクト指向プログラミング

オブジェクト指向プログラミング（OOP）は、モジュール性と再利用性の利点を取り入れることを目的とする（データとメソッドの両方を備えた）オブジェクトに基づくプログラミングパラダイムです。通常はクラスのインスタンスであるオブジェクトは、相互作用してアプリケーションやコンピュータープログラムを設計するために使用されます。

オブジェクト指向プログラミングの重要な機能は次のとおりです-

プログラム設計におけるボトムアップアプローチ
オブジェクトを中心に編成され、クラスにグループ化されたプログラム
オブジェクトのデータを操作するメソッドでデータに焦点を当てる
関数を介したオブジェクト間の相互作用
既存のクラスに機能を追加して新しいクラスを作成することによる設計の再利用性

オブジェクト指向プログラミング言語の例には、C ++、Java、Smalltalk、Delphi、C＃、Perl、Python、Ruby、およびPHPがあります。

Grady Boochは、オブジェクト指向プログラミングを_「プログラムがオブジェクトの協調コレクションとして編成される実装方法として定義しました。各オブジェクトは、あるクラスのインスタンスを表し、そのクラスはすべて、継承によって結合されたクラスの階層のメンバーです。関係」_。

OOAD-オブジェクトモデル

オブジェクトモデルは、ソフトウェアアプリケーションの要素をオブジェクトの観点から視覚化します。この章では、オブジェクト指向システムの基本概念と用語について説明します。

オブジェクトとクラス

オブジェクトとクラスの概念は本質的に相互にリンクされており、オブジェクト指向のパラダイムの基盤を形成します。

対象

オブジェクトは、物理的または概念的に存在する可能性のあるオブジェクト指向環境の現実世界の要素です。各オブジェクトには-

システム内の他のオブジェクトと区別するID。
オブジェクトの特性プロパティと、オブジェクトが保持するプロパティの値を決定する状態。
状態の変化に関して、オブジェクトによって実行される外部から見えるアクティビティを表す動作。

オブジェクトは、アプリケーションのニーズに応じてモデル化できます。オブジェクトには、顧客、自動車などの物理的な存在が含まれる場合があります。または、プロジェクト、プロセスなどの無形の概念的存在

クラス

クラスは、共通の動作を示す同じ特性プロパティを持つオブジェクトのコレクションを表します。それから作成できるオブジェクトの設計図または説明を提供します。クラスのメンバーとしてのオブジェクトの作成は、インスタンス化と呼ばれます。したがって、オブジェクトはクラスのインスタンスです。

クラスの構成要素は-

クラスからインスタンス化されるオブジェクトの属性のセット。一般に、クラスの異なるオブジェクトには、属性の値に多少の違いがあります。多くの場合、属性はクラスデータと呼ばれます。
クラスのオブジェクトの動作を表す一連の操作。操作は、関数またはメソッドとも呼ばれます。

例

2次元空間の幾何学的図形の円を表す単純なクラスCircleを考えてみましょう。このクラスの属性は次のように識別できます-

x-coord、中心のx座標を示します
y座標、中心のy座標を示す
a、円の半径を示す

その操作のいくつかは次のように定義することができます-

findArea（）、面積を計算するメソッド
findCircumference（）、円周を計算する方法
scale（）、半径を増減する方法

インスタンス化中に、少なくともいくつかの属性に値が割り当てられます。オブジェクトmy_circleを作成すると、x-coord：2、y-coord：3、a：4などの値を割り当てて、その状態を表すことができます。さて、操作scale（）がスケーリング係数2のmy_circleで実行されると、変数aの値は8になります。この操作により、my_circleの状態が変化します。つまり、オブジェクトは特定の動作を示しました。

カプセル化とデータの非表示

カプセル化

カプセル化は、クラス内で属性とメソッドの両方をバインドするプロセスです。カプセル化により、クラスの内部詳細を外部から隠すことができます。クラスが提供するインターフェイスを介してのみ、外部からクラスの要素にアクセスできます。

データ隠蔽

通常、クラスは、そのクラスメソッドによってのみデータ（属性）にアクセスでき、外部からの直接アクセスから隔離されるように設計されています。オブジェクトのデータを隔離するこのプロセスは、データ非表示または情報非表示と呼ばれます。

例

クラスCircleでは、クラスの外部から属性を非表示にし、クラスデータにアクセスするためのクラスにさらに2つのメソッドを追加することで、データの非表示を組み込むことができます。

setValues（）、x-coord、y-coord、およびaに値を割り当てるメソッド
getValues（）、x-coord、y-coord、およびaの値を取得するメソッド

ここでは、オブジェクトmy_circleのプライベートデータに、クラスCircle内にカプセル化されていないメソッドから直接アクセスすることはできません。代わりに、メソッドsetValues（）およびgetValues（）を使用してアクセスする必要があります。

メッセージの受け渡し

どのアプリケーションでも、調和のとれた方法で相互作用する多くのオブジェクトが必要です。システム内のオブジェクトは、メッセージパッシングを使用して相互に通信できます。システムにobj1とobj2の2つのオブジェクトがあるとします。 obj1がメソッドの1つをobj2に実行させる場合、オブジェクトobj1はオブジェクトobj2にメッセージを送信します。

メッセージパッシングの機能は次のとおりです-

2つのオブジェクト間でのメッセージの受け渡しは通常、単方向です。
メッセージの受け渡しにより、オブジェクト間のすべての対話が可能になります。
メッセージの受け渡しには、本質的にクラスメソッドの呼び出しが含まれます。
異なるプロセスのオブジェクトがメッセージの受け渡しに関与する可能性があります。

継承

継承は、その機能を拡張および改良することにより、既存のクラスから新しいクラスを作成できるようにするメカニズムです。既存のクラスは基本クラス/親クラス/スーパークラスと呼ばれ、新しいクラスは派生クラス/子クラス/サブクラスと呼ばれます。サブクラスは、スーパークラスで許可されている場合、スーパークラスの属性とメソッドを継承または派生できます。また、サブクラスは独自の属性とメソッドを追加し、スーパークラスのメソッドを変更できます。継承は、「is – a」関係を定義します。

例

クラス哺乳類から、人間、猫、犬、牛などの多くのクラスを派生させることができます。人間、猫、犬、牛はすべて哺乳類の特徴を持っています。さらに、それぞれに固有の特性があります。牛は哺乳類であると言えます。

継承の種類

Single Inheritance -サブクラスは、単一のスーパークラスから派生します。
Multiple Inheritance -サブクラスは複数のスーパークラスから派生します。
マルチレベル継承-サブクラスはスーパークラスから派生し、スーパークラスは別のクラスなどから派生します。
階層的継承-クラスには複数のサブクラスがあり、各サブクラスには後続のサブクラスがあり、ツリー構造を形成するために複数のレベルで継続します。
ハイブリッド継承-ラティス構造を形成するための複数およびマルチレベルの継承の組み合わせ。

次の図は、さまざまなタイプの継承の例を示しています。

継承

多型

ポリモーフィズムはもともとギリシャ語で、複数の形式を取る能力を意味します。オブジェクト指向のパラダイムでは、ポリモーフィズムとは、操作対象のインスタンスに応じて、さまざまな方法で操作を使用することを意味します。多態性により、異なる内部構造を持つオブジェクトが共通の外部インターフェイスを持つことができます。ポリモーフィズムは、継承を実装するときに特に効果的です。

例

それぞれがメソッドfindArea（）を持つ2つのクラス、CircleとSquareを考えてみましょう。クラス内のメソッドの名前と目的は同じですが、内部実装、つまり面積を計算する手順はクラスごとに異なります。 CircleクラスのオブジェクトがfindArea（）メソッドを呼び出すと、SquareクラスのfindArea（）メソッドと競合することなく、操作によって円の領域が検出されます。

一般化と専門化

汎化と特殊化は、サブクラスがスーパークラスから継承するクラス間の関係の階層を表します。

一般化

一般化プロセスでは、クラスの共通の特性が結合されて、より高いレベルの階層でクラスが形成されます。つまり、サブクラスが結合されて、一般化されたスーパークラスが形成されます。それは「----種類-」関係を表します。たとえば、「車は陸上車両の一種」または「船は一種の水上車両」です。

特化

専門化は、一般化の逆のプロセスです。ここでは、オブジェクトのグループの特徴を使用して、既存のクラスから特殊なクラスを形成します。サブクラスはスーパークラスの特殊バージョンであると言えます。

次の図は、一般化と特殊化の例を示しています。

スペシャライゼーション

リンクと関連付け

Link

リンクは、オブジェクトが他のオブジェクトと共同作業するための接続を表します。ルンボーは、それを「オブジェクト間の物理的または概念的な接続」と定義しています。リンクを介して、1つのオブジェクトがメソッドを呼び出したり、別のオブジェクトをナビゲートしたりできます。リンクは、2つ以上のオブジェクト間の関係を表します。

協会

関連付けは、共通の構造と共通の動作を持つリンクのグループです。関連付けは、1つ以上のクラスのオブジェクト間の関係を表します。リンクは、関連付けのインスタンスとして定義できます。

協会の程度

関連度は、接続に関係するクラスの数を示します。学位は単項、二項、三項のいずれかです。

*単項関係*は、同じクラスのオブジェクトを接続します。
*バイナリ関係*は2つのクラスのオブジェクトを接続します。
*三項関係*は、3つ以上のクラスのオブジェクトを接続します。

集約または構成

集約または合成は、クラスを他のクラスのオブジェクトの任意の組み合わせで構成できるクラス間の関係です。オブジェクトを他のクラスの本体内に直接配置できます。集約は、「一部」または「有」関係と呼ばれ、全体からその部分にナビゲートする機能を備えています。集合オブジェクトは、1つ以上の他のオブジェクトで構成されるオブジェクトです。

例

「自動車にはモーターがあります」という関係では、自動車はオブジェクト全体または集合体であり、モーターは自動車の「一部」です。集約が示す場合があります-

物理的封じ込め-例、コンピューターはモニター、CPU、マウス、キーボードなどで構成されます。
概念的封じ込め-例、株主は共有しています。

オブジェクトモデルの利点

オブジェクトの向きに関する中核となる概念を検討したので、このモデルが提供する利点に注目する価値があります。

オブジェクトモデルを使用する利点は次のとおりです-

ソフトウェアの開発を迅速化するのに役立ちます。
保守が簡単です。モジュールがエラーを発生させた場合、ソフトウェアの他の部分がまだ稼働している間にプログラマーがその特定のモジュールを修正できるとします。
比較的手間のかからないアップグレードをサポートします。
オブジェクト、デザイン、機能の再利用が可能になります。
特に複雑なシステムの統合において、開発リスクを軽減します。

OOAD-オブジェクト指向システム

オブジェクト指向モデリング（OOM）手法は、オブジェクトを中心に構成されたモデルを使用して、アプリケーション内の物事を視覚化することを知っています。すべてのソフトウェア開発アプローチは、次の段階を経ます-

分析、
設計、および
実装。

オブジェクト指向のソフトウェアエンジニアリングでは、ソフトウェア開発者は、特定のプログラミング言語またはソフトウェアツールで最終的に表現する前に、オブジェクト指向の概念の観点からアプリケーションを識別して整理します。

オブジェクト指向ソフトウェア開発のフェーズ

オブジェクト指向の方法論を使用したソフトウェア開発の主要なフェーズは、オブジェクト指向分析、オブジェクト指向設計、およびオブジェクト指向実装です。

オブジェクト指向分析

この段階では、問題が定式化され、ユーザーの要件が特定され、実際のオブジェクトに基づいてモデルが構築されます。分析により、目的のシステムがどのように機能し、どのように開発する必要があるかに関するモデルが生成されます。モデルには実装の詳細は含まれていないため、非技術的なアプリケーションの専門家が理解して調査することができます。

オブジェクト指向設計

オブジェクト指向設計には、システム設計とオブジェクト設計という2つの主要な段階があります。

システム設計

この段階では、目的のシステムの完全なアーキテクチャが設計されます。システムは相互作用するサブシステムのセットとして考えられ、相互作用するオブジェクトの階層で構成され、クラスにグループ化されます。システム設計は、システム分析モデルと提案されたシステムアーキテクチャの両方に従って行われます。ここでは、システム内のプロセスではなく、システムを構成するオブジェクトに重点が置かれています。

オブジェクト設計

このフェーズでは、システム分析フェーズで開発されたモデルとシステム設計フェーズで設計されたアーキテクチャの両方に基づいて、設計モデルが開発されます。必要なすべてのクラスが識別されます。デザイナーが決定するかどうか-

新しいクラスはゼロから作成され、
既存のクラスを元の形式で使用できます。または
新しいクラスは既存のクラスから継承する必要があります。

識別されたクラス間の関連付けが確立され、クラスの階層が識別されます。さらに、開発者はクラスとその関連付けの内部詳細、つまり各属性のデータ構造と操作のアルゴリズムを設計します。

オブジェクト指向の実装とテスト

この段階では、オブジェクト設計で開発された設計モデルは、適切なプログラミング言語またはソフトウェアツールでコードに変換されます。データベースが作成され、特定のハードウェア要件が確認されます。コードが完成したら、コード内のエラーを特定して削除するための特別な技術を使用してテストされます。

OOAD-オブジェクト指向の原則

オブジェクト指向システムの原理

オブジェクト指向システムの概念的なフレームワークは、オブジェクトモデルに基づいています。オブジェクト指向システムには要素の2つのカテゴリがあります-

メジャー要素-メジャーとは、モデルにこれらの要素が含まれていない場合、オブジェクト指向ではなくなることを意味します。 4つの主要な要素は-

抽象化
カプセル化
モジュール性
階層

マイナー要素-マイナーとは、これらの要素が有用であることを意味しますが、オブジェクトモデルの不可欠な部分ではありません。 3つのマイナーな要素は-

タイピング
並行性
持続性

抽象化

抽象化とは、OOPの要素またはオブジェクトの本質的な機能に焦点を当てることを意味し、その無関係または偶然の特性を無視します。基本的な機能は、オブジェクトが使用されているコンテキストに関連しています。

Grady Boochは次のように抽象化を定義しています-

「抽象化とは、オブジェクトの本質的な特性を指し、他のすべての種類のオブジェクトと区別するため、視聴者の視点から見て明確に定義された概念的な境界を提供します。」

例-クラスStudentが設計されると、属性enrolment_number、name、course、およびaddressが含まれますが、pulse_rateやsize_of_shoeなどの特性は、教育機関の観点からは無関係であるため削除されます。

カプセル化

カプセル化は、クラス内で属性とメソッドの両方をバインドするプロセスです。カプセル化により、クラスの内部詳細を外部から隠すことができます。クラスには、クラスが提供するサービスを使用するためのユーザーインターフェイスを提供するメソッドがあります。

モジュール性

モジュール性は、問題の全体的な複雑さを軽減するために、問題（プログラム）をモジュールのセットに分解するプロセスです。 Boochはモジュール性を次のように定義しています-

「モジュール性とは、まとまりのある疎結合モジュールのセットに分解されたシステムの特性です。」

モジュール性は、本質的にカプセル化とリンクしています。モジュール化は、カプセル化された抽象化をモジュール内で高い凝集度を持ち、モジュール間の相互作用または結合が少ない実際の物理モジュールにマッピングする方法として視覚化できます。

階層

Grady Boochの言葉では、「階層とは抽象化のランキングまたは順序です」。階層を介して、システムは相互に関連するサブシステムで構成され、最小レベルのコンポーネントに到達するまで独自のサブシステムなどを持つことができます。「分割統治」の原則を使用しています。階層により、コードを再利用できます。

OOAの階層の2つのタイプは-

「IS-A」階層-継承の階層関係を定義します。これにより、スーパークラスから、サブクラスなどを含む複数のサブクラスを派生させることができます。たとえば、FlowerクラスからRoseクラスを派生させる場合、バラは「花」であると言えます。
「PART-OF」階層-クラスを他のクラスで構成できる集約の階層関係を定義します。たとえば、花はがく片、花弁、雄しべ、および心皮で構成されます。花びらは「一部」の花と言えます。

タイピング

抽象データ型の理論によれば、型は要素のセットの特徴付けです。 OOPでは、クラスは他のタイプとは異なるプロパティを持つタイプとして視覚化されます。入力とは、オブジェクトが単一のクラスまたは型のインスタンスであるという概念の施行です。また、異なるタイプのオブジェクトは一般的に交換できないことを強制します。どうしても必要な場合は、非常に制限された方法でのみ交換できます。

タイピングの2つのタイプは-

Strong Typing -ここでは、プログラミング言語Eiffelの場合のように、オブジェクトの操作がコンパイル時にチェックされます。
Weak Typing -ここでは、メッセージはどのクラスにも送信できます。動作は、プログラミング言語Smalltalkのように、実行時にのみチェックされます。

並行性

オペレーティングシステムの同時実行により、複数のタスクまたはプロセスを同時に実行できます。システムに単一のプロセスが存在する場合、単一の制御スレッドがあると言われています。ただし、ほとんどのシステムには複数のスレッドがあり、一部はアクティブ、一部はCPUを待機、一部は中断、一部は終了しています。複数のCPUを備えたシステムは、本質的に同時スレッドの制御を許可します。ただし、単一のCPUで実行されているシステムは、適切なアルゴリズムを使用して、スレッドに公平なCPU時間を与え、同時実行を可能にします。

オブジェクト指向環境では、アクティブなオブジェクトと非アクティブなオブジェクトがあります。アクティブなオブジェクトには、他のオブジェクトのスレッドと同時に実行できる独立した制御スレッドがあります。アクティブなオブジェクトは、相互に同期するだけでなく、純粋にシーケンシャルなオブジェクトとも同期します。

持続性

オブジェクトはメモリ空間を占有し、特定の期間存在します。従来のプログラミングでは、オブジェクトの寿命は通常、それを作成したプログラムの実行の寿命でした。ファイルまたはデータベースでは、オブジェクトの寿命はオブジェクトを作成するプロセスの期間よりも長くなります。作成者が存在しなくなった後もオブジェクトが存在し続けるこのプロパティは、永続性と呼ばれます。

OOAD-オブジェクト指向分析

ソフトウェア開発のシステム分析またはオブジェクト指向分析フェーズでは、システム要件が決定され、クラスが識別され、クラス間の関係が識別されます。

オブジェクト指向分析で相互に使用される3つの分析手法は、オブジェクトモデリング、動的モデリング、および機能モデリングです。

オブジェクトモデリング

オブジェクトモデリングは、オブジェクトに関してソフトウェアシステムの静的構造を開発します。オブジェクト、オブジェクトをグループ化できるクラス、およびオブジェクト間の関係を識別します。また、各クラスを特徴付ける主な属性と操作も識別します。

オブジェクトモデリングのプロセスは、次の手順で視覚化することができます-

オブジェクトを特定し、クラスにグループ化します
クラス間の関係を特定する
ユーザーオブジェクトモデル図の作成
ユーザーオブジェクト属性を定義する
クラスで実行する必要のある操作を定義する
用語集を確認する

動的モデリング

システムの静的な振る舞いを分析した後、時間および外部の変化に関するシステムの振る舞いを調べる必要があります。これが動的モデリングの目的です。

ダイナミックモデリングは、「個々のオブジェクトがイベント（他のオブジェクトによってトリガーされる内部イベント、または外界によってトリガーされる外部イベント）に応答する方法を記述する方法」と定義できます。

動的モデリングのプロセスは、次の手順で視覚化することができます-

各オブジェクトの状態を識別する
イベントを特定し、アクションの適用可能性を分析します
状態遷移図で構成される動的モデル図の作成
オブジェクトの属性の観点から各状態を表現する
描かれた状態遷移図を検証する

機能モデリング

機能モデリングは、オブジェクト指向分析の最終コンポーネントです。機能モデルは、オブジェクト内で実行されるプロセスと、メソッド間を移動するデータの変化を示します。オブジェクトモデリングの操作の意味と動的モデリングのアクションを指定します。機能モデルは、従来の構造化分析のデータフロー図に対応しています。

機能モデリングのプロセスは、次の手順で視覚化することができます-

すべての入力と出力を特定する
機能的な依存関係を示すデータフロー図の作成
各機能の目的を述べる
制約を特定する
最適化基準を指定する

構造化分析とオブジェクト指向分析

構造化分析/構造化設計（SASD）アプローチは、ウォーターフォールモデルに基づいたソフトウェア開発の従来のアプローチです。 SASDを使用したシステムの開発の段階は次のとおりです-

実現可能性調査
要件分析と仕様
システム設計
実装
実装後レビュー

次に、構造化分析アプローチとオブジェクト指向分析アプローチの相対的な長所と短所を見ていきます。

オブジェクト指向分析の利点/欠点

Advantages	Disadvantages
Focuses on data rather than the procedures as in Structured Analysis.	Functionality is restricted within objects. This may pose a problem for systems which are intrinsically procedural or computational in nature.
The principles of encapsulation and data hiding help the developer to develop systems that cannot be tampered by other parts of the system.	It cannot identify which objects would generate an optimal system design.
The principles of encapsulation and data hiding help the developer to develop systems that cannot be tampered by other parts of the system.	The object-oriented models do not easily show the communications between the objects in the system.
It allows effective management of software complexity by the virtue of modularity.	All the interfaces between the objects cannot be represented in a single diagram.
It can be upgraded from small to large systems at a greater ease than in systems following structured analysis.

構造化分析の利点/欠点

Advantages	Disadvantages
As it follows a top-down approach in contrast to bottom-up approach of object-oriented analysis, it can be more easily comprehended than OOA.	In traditional structured analysis models, one phase should be completed before the next phase. This poses a problem in design, particularly if errors crop up or requirements change.
It is based upon functionality. The overall purpose is identified and then functional decomposition is done for developing the software. The emphasis not only gives a better understanding of the system but also generates more complete systems.	The initial cost of constructing the system is high, since the whole system needs to be designed at once leaving very little option to add functionality later.
The specifications in it are written in simple English language, and hence can be more easily analyzed by non-technical personnel.	It does not support reusability of code. So, the time and cost of development is inherently high.

OOAD-動的モデリング

動的モデルは、システムの時間依存の側面を表します。システム内のオブジェクトの状態の一時的な変化に関係しています。主な概念は次のとおりです-

状態。オブジェクトの存続期間中の特定の条件での状況です。
遷移、状態の変化
イベント、遷移をトリガーするオカレンス
アクション、何らかのイベントのために発生する中断されないアトミックな計算、および
移行の同時実行。

ステートマシンは、イベントが原因で発生するアクションだけでなく、いくつかのイベントが原因で、ライフタイム中に多くの状態を通過するオブジェクトの動作をモデル化します。状態マシンは、状態遷移図によってグラフィカルに表されます。

状態と状態遷移

状態

状態は、オブジェクトが特定の期間に持っている属性の値によって与えられる抽象化です。これは、オブジェクトの存続期間内の有限期間に発生する状況であり、特定の条件を満たす、特定のアクティビティを実行する、または特定のイベントの発生を待機します。状態遷移図では、状態は丸い長方形で表されます。

状態の部分

名前-文字列は、ある状態を別の状態と区別します。状態に名前を付けることはできません。
入場/退場アクション-状態の開始時および終了時に実行されるアクティビティを示します。
内部遷移-状態の変化を引き起こさない状態内の変化。
サブ状態-状態内の状態。

初期状態と最終状態

オブジェクトのデフォルトの開始状態は、その初期状態と呼ばれます。最終状態は、ステートマシンの実行の完了を示します。初期状態と最終状態は疑似状態であり、名前以外の通常の状態の部分を持たない場合があります。状態遷移図では、初期状態は黒丸で示されます。最終状態は、塗りつぶされていない別の黒丸で囲まれた黒丸で表されます。

遷移

遷移は、オブジェクトの状態の変化を示します。イベントの発生時にオブジェクトが特定の状態にある場合、オブジェクトは指定された条件に従って特定のアクティビティを実行し、状態を変更できます。この場合、状態遷移が発生したと言われます。遷移は、最初の状態と新しい状態の間の関係を示します。遷移は、ソース状態から宛先状態へのソリッドな有向アークによってグラフィカルに表されます。

遷移の5つの部分は-

ソース状態-遷移の影響を受ける状態。
イベントトリガー-ガード条件が満たされた場合にソース状態のオブジェクトが遷移するための発生。
Guard Condition -Trueの場合、イベントトリガーの受信時に遷移を引き起こすブール式。
アクション-何らかのイベントが原因でソースオブジェクトで発生する、割り込み不可能でアトミックな計算。
ターゲット状態-移行完了後の宛先状態。

例

人が場所Xから場所Yまでタクシーを利用しているとします。その人の状態は、待機中（タクシーを待っている）、乗車（彼はタクシーを持っており、その中を移動している）、および到達した（彼は目的地に到達した）です。次の図は、状態遷移を示しています。

トランジション

イベント

イベントは、オブジェクトまたはオブジェクトのグループの状態遷移をトリガーできる発生です。イベントには時間と空間の場所がありますが、それに関連付けられた期間はありません。通常、イベントはいくつかのアクションに関連付けられています。

イベントの例としては、マウスクリック、キーの押下、割り込み、スタックオーバーフローなどがあります。

遷移をトリガーするイベントは、状態図の遷移の弧と一緒に記述されます。

例

上の図に示されている例を考えると、待機状態から乗車状態への移行は、その人がタクシーに乗ると発生します。同様に、彼が目的地に到着すると、最終状態に到達します。これら2つのオカレンスは、イベントGet_TaxiおよびReach_Destinationと呼ばれます。次の図は、状態マシンのイベントを示しています。

遷移イベント

外部および内部イベント

外部イベントは、システムのユーザーからシステム内のオブジェクトに渡されるイベントです。たとえば、ユーザーによるマウスクリックまたはキー押下は外部イベントです。

内部イベントは、システム内のあるオブジェクトから別のオブジェクトに渡されるイベントです。たとえば、スタックオーバーフロー、除算エラーなど。

遅延イベント

遅延イベントとは、現在の状態のオブジェクトによってすぐに処理されるのではなく、後で他の状態のオブジェクトによって処理できるようにキューに並んでいるイベントです。

イベントクラス

イベントクラスは、共通の構造と動作を持つイベントのグループを示します。オブジェクトのクラスと同様に、イベントクラスも階層構造に編成できます。イベントクラスには属性が関連付けられている場合がありますが、これは暗黙的な属性です。たとえば、私たちは航空会社のフライトの出発のイベントを考慮することができ、次のクラスにグループ化することができます-

Flight_Departs（Flight_No、From_City、To_City、Route）

行動

アクティビティ

アクティビティは、一定の期間を必要とするオブジェクトの状態に対する操作です。それらは、システム内で中断される可能性のある継続的な実行です。アクティビティは、あるアクティビティから別のアクティビティへのフローを表すアクティビティ図に表示されます。

アクション

アクションは、特定のイベントの結果として実行されるアトミック操作です。アトミックとは、アクションが中断できないことを意味します。つまり、アクションが実行を開始すると、イベントによって中断されることなく完了します。アクションは、イベントがトリガーされたオブジェクト、またはこのオブジェクトに表示される他のオブジェクトに対して実行できます。一連のアクションがアクティビティを構成します。

入場と退場のアクション

エントリアクションは、状態への遷移に関係なく、状態に入るときに実行されるアクションです。

同様に、状態から出た遷移に関係なく、状態を離れるときに実行されるアクションは、終了アクションと呼ばれます。

シナリオ

シナリオは、指定された一連のアクションの説明です。特定のアクションシリーズを実行するオブジェクトの動作を示します。主なシナリオは基本的なシーケンスを表し、副次的なシナリオは代替シーケンスを表します。

動的モデリングの図

動的モデリングに使用される2つの主要な図があります-

相互作用図

相互作用図は、さまざまなオブジェクト間の動的な動作を説明します。オブジェクトのセット、それらの関係、およびオブジェクトが送受信するメッセージで構成されます。したがって、相互作用は、相互に関連するオブジェクトのグループの動作をモデル化します。相互作用図の2つのタイプは-

シーケンス図-それは表形式でメッセージの時間的順序を表します。
コラボレーション図-頂点とアークを介してメッセージを送受信するオブジェクトの構造的組織を表します。

状態遷移図

状態遷移図または状態マシンは、単一のオブジェクトの動的な動作を記述します。オブジェクトがその存続期間中に通過する状態のシーケンス、状態の遷移、遷移を引き起こすイベントと条件、およびイベントによる応答を示します。

イベントの並行性

システムでは、2つのタイプの並行性が存在する場合があります。彼らは-

システムの同時実行性

ここでは、並行性はシステムレベルでモデル化されています。システム全体は、各ステートマシンが他のステートマシンと同時に実行されるステートマシンの集合としてモデル化されます。

オブジェクト内の並行性

ここで、オブジェクトは並行イベントを発行できます。オブジェクトには、サブ状態で構成される状態があり、各サブ状態で同時イベントが発生する場合があります。

オブジェクト内の並行性に関連する概念は次のとおりです-

単純および複合状態

単純な状態にはサブ構造がありません。内部にネストされたより単純な状態を持つ状態は、複合状態と呼ばれます。サブ状態は、別の状態内にネストされている状態です。通常、ステートマシンの複雑さを軽減するために使用されます。サブ状態は、任意の数のレベルにネストできます。

複合状態には、順次サブ状態または並行サブ状態があります。

シーケンシャルサブステート

順次サブ状態では、実行の制御は、あるサブ状態から別のサブ状態に順次に渡されます。これらのステートマシンには、最大で1つの初期状態と1つの最終状態があります。

次の図は、順次サブ状態の概念を示しています。

シーケンシャルサブステート

同時サブステート

並行サブステートでは、サブステートは並行して実行されます。つまり、各ステートは同時に実行するステートマシンを持っています。各状態マシンには、独自の初期状態と最終状態があります。ある並行サブ状態がもう一方より先に最終状態に達すると、制御はその最終状態で待機します。ネストされたすべてのステートマシンが最終状態に達すると、サブステートは単一のフローに戻ります。

次の図は、並行サブ状態の概念を示しています。

同時サブステート

OOAD-機能モデリング

機能モデリングは、オブジェクト指向分析モデルのプロセスの観点と、システムが行うべきことの概要を提供します。データフロー図（DFD）を使用して、システムの内部プロセスの機能を定義します。計算時にデータ値がどのように導出されるか、または計算する必要がある理由を示すことなく、データ値の機能的導出を示します。

データフロー図

機能モデリングは、DFDの階層を通じて表されます。 DFDは、システムへの入力、入力に対する処理、システムの出力、および内部データストアを示すシステムのグラフィカルな表現です。 DFDは、オブジェクトまたはシステムで実行される一連の変換または計算、および変換に影響する外部コントロールとオブジェクトを示します。

ルンボー等。 DFDを「データフロー図は、オブジェクトのソースから他のオブジェクトの宛先に変換するプロセスを介したオブジェクトのデータ値のフローを示すグラフです」と定義しています。

DFDの4つの主要な部分は-

プロセス、
データフロー、
俳優、そして
データストア。

DFDの他の部分は-

制約、および
制御フロー。

DFDの機能

プロセス

プロセスは、データ値を変換する計算アクティビティです。システム全体を高レベルのプロセスとして視覚化できます。プロセスはさらに小さなコンポーネントに分割できます。最下位レベルのプロセスは、単純な機能です。

DFDでの表現*-プロセスは、名前が内部に記述された楕円として表され、一定数の入力および出力データ値を含みます。

例-次の図は、入力として2つの整数を受け入れ、それらのHCF（最大公約数）およびLCM（最小公倍数）を出力するプロセスCompute_HCF_LCMを示しています。

HCMおよびLCMを計算するDFD

データフロー

データフローは、2つのプロセス間のデータの流れを表します。アクターとプロセスの間、またはデータストアとプロセスの間である可能性があります。データフローは、計算のある時点でのデータ項目の値を示します。この値は、データフローによって変更されません。

DFDでの表現*-データフローは、それが運ぶデータ項目の名前でラベル付けされた有向弧または矢印によって表されます。

上の図では、Integer_aとInteger_bはプロセスへの入力データフローを表し、L.C.M。およびH.C.F. 出力データフローです。

データフローは、次の場合に分岐することがあります-

次の図に示すように、出力値は複数の場所に送信されます。ここでは、出力矢印は同じ値を示すためラベル付けされていません。
データフローには集計値が含まれており、次の図に示すように、各コンポーネントは異なる場所に送信されます。ここでは、分岐した各コンポーネントにラベルが付けられています。

データフローの分岐

俳優

アクターは、データを生成してシステムに入力するか、システムによって生成されたデータを消費することにより、システムと対話するアクティブなオブジェクトです。つまり、アクターはデータのソースおよびシンクとして機能します。

DFDでの表現*-アクターは長方形で表されます。アクターは入力と出力に接続され、DFDの境界上にあります。

例-次の図は、カウンター販売システムのアクター、つまりCustomerとSales_Clerkを示しています。

DFDの俳優

データストア

データストアは、データのリポジトリとして機能するパッシブオブジェクトです。アクターとは異なり、操作を実行できません。データを保存し、保存されたデータを取得するために使用されます。データ構造、ディスクファイル、またはデータベース内のテーブルを表します。

DFDでの表現*-データストアは、データストアの名前を含む2本の平行線で表されます。各データストアは、少なくとも1つのプロセスに接続されます。入力矢印にはデータストアの内容を変更する情報が含まれ、出力矢印にはデータストアから取得した情報が含まれます。情報の一部を取得する場合、出力矢印にラベルが付けられます。ラベルのない矢印は、完全なデータ取得を示します。双方向の矢印は、取得と更新の両方を意味します。

例-次の図は、すべての販売の詳細を格納するデータストアSales_Recordを示しています。データストアへの入力は、アイテム、請求額、日付などの売上の詳細で構成されます。平均売上を見つけるために、プロセスは売上レコードを取得して平均を計算します。

DFDのデータストア

制約

制約は、時間の経過とともに満たされる必要がある条件または制限を指定します。新しいルールを追加したり、既存のルールを変更したりできます。制約は、オブジェクト指向分析の3つのモデルすべてに現れる可能性があります。

オブジェクトモデリングでは、制約はオブジェクト間の関係を定義します。また、オブジェクトが異なる時間に取る可能性のある異なる値間の関係を定義することもできます。
ダイナミックモデリングでは、制約がさまざまなオブジェクトの状態とイベント間の関係を定義します。
機能モデリングでは、制約は変換と計算の制限を定義します。

表現-制約は中括弧内の文字列としてレンダリングされます。

例-次の図は、営業部門のすべての従業員にインセンティブを与え、人事部門のすべての従業員の給与を増やすことを決定した会社の従業員の給与を計算するためのDFDの一部を示しています。制約\ {Dept：Sales}は、部門が販売の場合にのみインセンティブを計算し、制約\ {Dept：HR}は部門がHRの場合にのみ増分を計算することがわかります。

DFDの制約

制御フロー

プロセスは特定のブール値に関連付けられ、値がtrueの場合にのみ評価されますが、プロセスへの直接入力ではありません。これらのブール値は、制御フローと呼ばれます。

DFDでの表現*-制御フローは、ブール値を生成するプロセスから制御されるプロセスへの点線の円弧で表されます。

例-次の図は、算術除算のDFDを表しています。除数はゼロ以外でテストされます。ゼロでない場合、制御フローOKの値はTrueになり、その後、除算プロセスは商と剰余を計算します。

DFDの制御フロー

システムのDFDモデルの開発

システムのDFDモデルを開発するために、DFDの階層が構築されます。最上位のDFDは、単一のプロセスとそれと対話するアクターで構成されます。

連続する各下位レベルで、詳細が徐々に追加されます。プロセスはサブプロセスに分解され、サブプロセス間のデータフローが識別され、制御フローが決定され、データストアが定義されます。プロセスの分解中、プロセスに出入りするデータフローは、DFDの次のレベルのデータフローと一致する必要があります。

例-卸売店の取引を自動化するソフトウェアシステム、卸売業者ソフトウェアを考えてみましょう。店は大量に販売し、商人と小売店の所有者で構成される顧客がいます。各顧客は、自分の詳細に登録するように求められ、一意の顧客コードC_Codeが与えられます。販売が完了すると、ショップはその詳細を登録し、発送のために商品を送ります。毎年、ショップは顧客にクリスマスギフトを配布します。クリスマスギフトは、総売上と所有者の決定に応じて、銀貨または金貨で構成されます。

Wholesaleソフトウェアの機能モデルを以下に示します。次の図は、最上位のDFDを示しています。ソフトウェアを単一のプロセスとして示し、それと対話するアクターを示しています。

システム内の俳優は-

お客様
営業担当者
所有者

卸売店のDFD

次のレベルのDFDでは、次の図に示すように、システムの主要なプロセスが識別され、データストアが定義され、プロセスとアクターとの相互作用、およびデータストアが確立されます。

システムでは、3つのプロセスを識別することができます-

顧客を登録する
プロセス販売
ギフトを確認する

必要となるデータストアは次のとおりです-

顧客の詳細
販売詳細
ギフト詳細

卸売ソフトウェアのDFD

次の図は、顧客の登録プロセスの詳細を示しています。その中には、詳細の確認、C_Codeの生成、顧客の詳細の更新の3つのプロセスがあります。顧客の詳細が入力されると、それらが検証されます。データが正しい場合、C_Codeが生成され、データストアの顧客の詳細が更新されます。

カスタマープロセスのDFD

次の図は、ギフトの確認プロセスの拡張を示しています。合計売上の検索とギフトコインの種類の決定という2つのプロセスがあります。 Find Total Salesプロセスは、各顧客に対応する年間総売上を計算し、データを記録します。この記録と所有者の決定を入力として、ギフトコインはギフトコインの種類の決定プロセスを通じて割り当てられます。

ギフトプロセスのDFD

DFDの長所と短所

Advantages	Disadvantages
DFDs depict the boundaries of a system and hence are helpful in portraying the relationship between the external objects and the processes within the system.	DFDs take a long time to create, which may not be feasible for practical purposes.
They help the users to have a knowledge about the system.	DFDs do not provide any information about the time-dependent behavior, i.e., they do not specify when the transformations are done.
The graphical representation serves as a blueprint for the programmers to develop a system.	They do not throw any light on the frequency of computations or the reasons for computations.
DFDs provide detailed information about the system processes.	The preparation of DFDs is a complex process that needs considerable expertise. Also, it is difficult for a non-technical person to understand.
They are used as a part of the system documentation.	The method of preparation is subjective and leaves ample scope to be imprecise.

オブジェクトモデル、動的モデル、機能モデルの関係

オブジェクトモデル、動的モデル、および機能モデルは、完全なオブジェクト指向分析のために互いに補完的です。

オブジェクトモデリングは、オブジェクトに関してソフトウェアシステムの静的構造を開発します。したがって、システムの「実行者」を示します。
ダイナミックモデリングは、外部イベントに応じてオブジェクトの一時的な動作を開発します。オブジェクトに対して実行される一連の操作を示します。
機能モデルは、システムが行うべきことの概要を示します。

機能モデルとオブジェクトモデル

オブジェクトモデルの観点から機能モデルの4つの主要部分は次のとおりです-

プロセス-プロセスは、実装する必要があるオブジェクトのメソッドを意味します。
アクター-アクターはオブジェクトモデルのオブジェクトです。
データストア-これらは、オブジェクトモデル内のオブジェクトまたはオブジェクトの属性のいずれかです。
データフロー-アクターとの間のデータフローは、オブジェクトに対する操作またはオブジェクトによる操作を表します。データストアとの間のデータフローは、クエリまたは更新を表します。

機能モデルと動的モデル

動的モデルは操作が実行されるタイミングを示し、機能モデルは操作の実行方法と必要な引数を示します。アクターはアクティブオブジェクトであるため、動的モデルはいつ動作するかを指定する必要があります。データストアはパッシブオブジェクトであり、更新とクエリにのみ応答します。したがって、動的モデルは、いつ動作するかを指定する必要はありません。

オブジェクトモデルと動的モデル

動的モデルは、オブジェクトのステータスと、イベントの発生およびその後の状態の変化に対して実行された操作を示します。変更の結果としてのオブジェクトの状態は、オブジェクトモデルに表示されます。

OOAD-UML分析モデル

統一モデリング言語（UML）は、OOADのグラフィカル言語であり、ソフトウェアシステムの設計図を記述する標準的な方法を提供します。オブジェクト指向システムの成果物を視覚化、指定、構築、および文書化するのに役立ちます。複雑なシステムの構造と関係を表すために使用されます。

簡単な歴史

1990年代に、Grady BoochによるOOAD技術、James RumbaughによるOMT（Object Modeling Technique）、およびIvar JacobsonによるOOSE（Object Oriented Software Engineering）のいくつかの技術の融合として開発されました。 UMLは、セマンティックモデル、構文表記、OOADの図を標準化しようとしました。

UMLのシステムとモデル

システム-システムを形成する特定の目的を達成するために編成された要素のセット。多くの場合、システムはサブシステムに分割され、一連のモデルによって記述されます。

モデル-モデルは、システムをよりよく理解するために作成された、システムの単純化された完全で一貫した抽象化です。

ビュー-ビューは、特定の視点からのシステムのモデルの投影です。

UMLの概念モデル

UMLの概念モデルには、3つの主要な要素が含まれます-

基本的な構成要素
規則
一般的なメカニズム

基本的な構成要素

UMLの3つのビルディングブロックは次のとおりです-

物事
関係
図

物事

UMLには4つの種類があります。

構造的なもの-これらは物理的または概念的な静的要素を表すUMLモデルの名詞です。構造的なものは、クラス、インターフェース、コラボレーション、ユースケース、アクティブなクラス、コンポーネント、およびノードです。
動作-これらは、時間と空間の動的な動作を表すUMLモデルの動詞です。ふるまいの2つのタイプは、インタラクションとステートマシンです。
グループ化-UMLモデルの組織的な部分を構成します。グループ化の種類は1つだけです。つまり、パッケージです。
注釈事項-これらは要素を記述するために適用されるコメントを表すUMLモデルの説明です。

関係

関係は、物事間のつながりです。 UMLで表すことができる関係の4つのタイプは次のとおりです-

依存性-これは、あるものの変化が他の物の変化をもたらすような、2つのものの間の意味的関係です。前者は独立したものであり、後者は依存するものです。
関連付け-これは、共通の構造と共通の動作を持つリンクのグループを表す構造的な関係です。
一般化-これは、サブクラスがスーパークラスから構造と動作を継承する一般化/特殊化関係を表します。
実現-これは、1つの分類子が他の分類子が順守することを保証する契約を定めるような、2つ以上の分類子間の意味関係です。

図

ダイアグラムは、システムのグラフィカルな表現です。一般にグラフ形式の要素のグループで構成されます。 UMLには全部で9つの図が含まれています-

クラス図
オブジェクト図
ユースケース図
シーケンス図
コラボレーション図
状態図
アクティビティ図
コンポーネント図
配置図

規則

UMLには多数のルールがあり、モデルは意味的に自己矛盾がなく、システム内の他のモデルと調和的に関連しています。 UMLには次の意味規則があります-

お名前
範囲
視認性
誠実さ
実行

一般的なメカニズム

UMLには4つの一般的なメカニズムがあります-

仕様
装飾品
共通部門
拡張性メカニズム

仕様

UMLでは、各グラフィカル表記の背後に、構文とセマンティクスを示すテキストステートメントがあります。これらは仕様です。仕様は、システムのすべての部分と異なるパス間の関係を含むセマンティックバックプレーンを提供します。

装飾品

UMLの各要素には、一意のグラフィック表記があります。さらに、名前、スコープ、可視性などの要素の重要な側面を表す表記法があります。

共通部門

オブジェクト指向システムは多くの方法で分割できます。分割の2つの一般的な方法は-

クラスとオブジェクトの分割-クラスは、類似したオブジェクトのグループの抽象化です。オブジェクトは、システム内に実際に存在する具体的なインスタンスです。
インターフェイスと実装の分割-インターフェイスは、相互作用のルールを定義します。実装は、インターフェースで定義されたルールの具体的な実現です。

拡張性メカニズム

UMLは、拡張可能な言語です。システムの要件に合わせて、制御された方法でUMLの機能を拡張することができます。拡張メカニズムは次のとおりです-

ステレオタイプ-UMLの語彙を拡張し、既存のブロックから新しいビルディングブロックを作成できます。
タグ付き値-UMLビルディングブロックのプロパティを拡張します。
制約-UMLビルディングブロックのセマンティクスを拡張します。

OOAD-UMLの基本表記

UMLは、各ビルディングブロックに特定の表記法を定義します。

クラス

クラスは、3つのセクションを持つ長方形で表されます-

クラスの名前を含む上部セクション
クラス属性を含む中央セクション
クラスの操作を表す下部セクション

属性と操作の可視性は、次の方法で表すことができます-

パブリック-パブリックメンバーはシステムのどこからでも見ることができます。クラス図では、接頭辞「+」が付いています。
Private -プライベートメンバーはクラス内からのみ表示されます。クラス外からはアクセスできません。プライベートメンバーの前には記号「-」が付きます。
Protected -保護されたメンバーは、クラス内およびこのクラスから継承されたサブクラスからは見えますが、外部からは見えません。記号「＃」が前に付いています。

抽象クラスのクラス名は斜体で書かれています。

例-先ほど紹介したCircleクラスを考えてみましょう。 Circleの属性は、x座標、y座標、および半径です。操作は、findArea（）、findCircumference（）、およびscale（）です。 x-coordとy-coordはプライベートデータメンバーであり、radiusは保護されたデータメンバーであり、メンバー関数はパブリックであると仮定します。次の図は、クラスの図表示を示しています。

クラスサークル

対象

オブジェクトは、2つのセクションを持つ長方形として表されます-

上部セクションには、オブジェクトの名前と、それがインスタンスであるクラスまたはパッケージの名前が含まれています。名前は次の形式を取ります-
オブジェクト名-クラス名
オブジェクト名-クラス名::パッケージ名
クラス名-匿名オブジェクトの場合
下部のセクションは、属性の値を表します。属性名=値の形式を取ります。
オブジェクトは角丸長方形を使用して表される場合があります。

例-c1という名前のCircleクラスのオブジェクトを考えてみましょう。 c1の中心は（2、3）にあり、c1の半径は5であると仮定します。次の図は、オブジェクトを示しています。

オブジェクトC1

成分

コンポーネントは、インターフェースのセットに準拠し、それを実現するシステムの物理的で交換可能な部分です。クラスやインターフェースなどの要素の物理的なパッケージングを表します。

表記法-UMLダイアグラムでは、コンポーネントは、下図に示すようにタブ付きの長方形で表されます。

コンポーネントの表記法

インタフェース

インターフェースは、クラスまたはコンポーネントのメソッドのコレクションです。クラスまたはコンポーネントによって提供されるサービスのセットを指定します。

表記-一般的に、インターフェースはその名前とともに円として描かれます。インターフェイスは、ほとんどの場合、それを実現するクラスまたはコンポーネントに接続されます。次の図は、インターフェースの表記法を示しています。

コンポーネントのインターフェース

パッケージ

パッケージは、要素の組織化されたグループです。パッケージには、クラス、コンポーネント、その他のパッケージなどの構造的なものが含まれている場合があります。

表記-グラフィカルには、パッケージはタブ付きフォルダーで表されます。パッケージは通常、名前だけで描かれます。ただし、パッケージの内容に関する追加の詳細が含まれている場合があります。次の図を参照してください。

パッケージ

関係

関係の異なるタイプの表記法は次のとおりです-

関係の表記

通常、関係内の要素は、関係内で特定の役割を果たします。ロール名は、特定のコンテキストに参加している要素の動作を示します。

例-次の図は、クラス間のさまざまな関係の例を示しています。最初の図は、DepartmentとEmployeeの2つのクラス間の関連付けを示しています。部門では、複数の従業員が働いている場合があります。 Workerはロール名です。部門の横にある「1」と従業員の横にある「*」は、カーディナリティ比が1対多であることを示しています。 2番目の図は、集約関係を示しています。大学は多くの学科の「全体」です。

関係

OOAD-UML構造図

UML構造図は、クラス図、オブジェクト図、コンポーネント図、展開図のように分類されます。

クラス図

クラス図は、システムの静的なビューをモデル化します。システムのクラス、インターフェース、およびコラボレーションで構成されます。そしてそれらの間の関係。

システムのクラス図

単純化された銀行システムについて考えてみましょう。

銀行には多くの支店があります。各ゾーンでは、1つのブランチがゾーンヘッドオフィスとして指定され、そのゾーン内の他のブランチを監督します。各支店には複数のアカウントとローンを設定できます。アカウントは、普通預金口座または当座預金口座のいずれかです。顧客は普通預金口座と当座預金口座の両方を開設できます。ただし、顧客は複数の普通預金口座または当座預金口座を持ってはなりません。顧客は銀行からローンを調達することもできます。

次の図は、対応するクラス図を示しています。

銀行システムのクラス図

システム内のクラス

銀行、支店、口座、普通預金口座、当座預金口座、ローン、および顧客。

関係

銀行は支店数を「持っている」-構成、1対多
ゾーナル本社の役割を持つ支部は、他の支部を監督します-単項協会、一対多
支店は「アカウント数」を持っています-集約、1対多

クラスAccountから、2つのクラス、つまり普通預金口座と当座預金口座が継承されました。

顧客は1つの当座預金口座を持つことができます-1対1の関連付け
顧客は1つの普通預金口座を持つことができます-関連付け、1対1
支店は「多数のローンを持っています」-集約、1対多
顧客は多くのローンを引き受けることができます-協会、1対多

オブジェクト図

オブジェクト図は、ある時点でのオブジェクトのグループとそのリンクをモデル化します。クラス図に物のインスタンスを表示します。オブジェクト図は、相互作用図の静的な部分です。

例-次の図は、銀行システムのクラス図の一部のオブジェクト図を示しています。

銀行システムのオブジェクト図

コンポーネント図

コンポーネント図は、コンポーネントのグループ間の構成と依存関係を示しています。

コンポーネント図で構成-

コンポーネント
インターフェース
関係
パッケージとサブシステム（オプション）

コンポーネント図が使用されます-

フォワードおよびリバースエンジニアリングによるシステムの構築。
オブジェクト指向プログラミング言語を使用してシステムを開発しながら、ソースコードファイルの構成管理をモデリングします。
モデリングデータベースのスキーマを表します。
動的システムの動作のモデリング。

例

次の図は、C ++を使用して開発されたシステムのソースコードをモデル化するコンポーネント図を示しています。 4つのソースコードファイル、つまり、myheader.h、otherheader.h、priority.cpp、およびother.cppを示しています。 myheader.hの2つのバージョンが示されており、最新バージョンからその祖先までトレースしています。ファイルpriority.cppは、other.cppにコンパイルの依存関係があります。ファイルother.cppには、otherheader.hに対するコンパイル依存性があります。

コンポーネント図

配置図

配置図では、ランタイム処理ノードとその上に存在するコンポーネントの構成に重点が置かれます。それらは通常、ノードと依存関係、またはノード間の関連付けで構成されます。

配置図はに使用されます-

通常、ソフトウェアを集中的に使用するハードウェアのコレクションで構成される組み込みシステムのモデルデバイス。
クライアント/サーバーシステムのトポロジを表します。
完全分散システムをモデル化します。

例

次の図は、クライアント/サーバーアーキテクチャに従うコンピューターシステムのトポロジを示しています。この図は、プロセッサーで構成されるサーバーとしてステレオタイプ化されたノードを示しています。この図は、システムに4つ以上のサーバーが展開されていることを示しています。サーバーに接続されているのはクライアントノードです。各ノードは、ワークステーション、ラップトップ、スキャナー、プリンターなどの端末デバイスを表します。ノードは、実際の同等物を明確に表すアイコンを使用して表されます。

展開図

OOAD-UML動作図

UML動作図は、システムの動的な側面を視覚化、指定、構築、および文書化します。動作図は、ユースケース図、相互作用図、状態図図、アクティビティ図のように分類されます。

ユースケースモデル

使用事例

ユースケースは、システムが目に見える結果をもたらす一連のアクションを記述しています。これは、システムの外部のものとシステム自体との相互作用を示しています。ユースケースは、システムの一部だけでなくシステム全体にも適用できます。

俳優

アクターは、ユースケースのユーザーが果たす役割を表します。俳優は人かもしれません（例：学生、顧客）、デバイス（例：ワークステーション）、または別のシステム（例：銀行、機関）。

次の図は、Studentという名前のアクターの表記とGenerate Performance Reportという名前のユースケースを示しています。

アクターとユースケースの表記法

ユースケース図

ユースケース図は、システム内の要素の振る舞いと、コンテキスト内での要素の使用方法の外観を示しています。

ユースケース図の構成-

ユースケース
俳優
依存関係、一般化、関連付けなどの関係

ユースケース図が使用されます-

システムのすべてのアクティビティを長方形で囲み、システムと対話することでシステムの外部のアクターに焦点を当てることにより、システムのコンテキストをモデル化する。
外部の観点からシステムの要件をモデル化する。

例

自動化された取引所システムについて考えてみましょう。私たちは、システムの次の機能を想定しています-

取引所には、個人顧客と法人顧客の2種類の顧客との取引があります。
顧客が注文すると、販売部門によって処理され、顧客に請求書が渡されます。
このシステムにより、マネージャは顧客のアカウントを管理し、顧客が投稿したクエリに回答できます。

自動取引所のユースケース

相互作用図

相互作用図は、オブジェクトとそれらの関係の相互作用を示します。また、それらの間で受け渡されるメッセージも含まれます。相互作用図には2種類あります-

シーケンス図
コラボレーション図

相互作用図はモデリングに使用されます-

シーケンス図を使用した時間順序による制御フロー。
コラボレーション図を使用した組織の制御フロー。

シーケンス図

シーケンス図は、時間に応じたメッセージの順序を示す相互作用図です。

表記-これらの図は、2次元チャートの形式です。相互作用を開始するオブジェクトは、x軸上に配置されます。これらのオブジェクトが送受信するメッセージは、y軸に沿って、上から下に時間が長い順に配置されます。

例-自動取引所システムのシーケンス図を次の図に示します。

シーケンス図

コラボレーション図

コラボレーション図は、メッセージを送受信するオブジェクトの構造を示す相互作用図です。

表記-これらの図では、相互作用に参加するオブジェクトが頂点を使用して表示されます。オブジェクトを接続するリンクは、メッセージの送受信に使用されます。メッセージはラベル付き矢印として表示されます。

例-自動トレーディングハウスシステムのコラボレーション図を下図に示します。

コラボレーション図

状態図

状態図は、ある状態から別の状態へのオブジェクトの制御フローを示す状態マシンを示しています。状態マシンは、オブジェクトがイベントおよびイベントへの応答のために受ける状態のシーケンスを描写します。

状態図表の構成は-

状態：単純または複合
状態間の遷移
遷移を引き起こすイベント
イベントによるアクション

状態図は、本質的に反応するオブジェクトのモデリングに使用されます。

例

自動取引所システムで、注文をオブジェクトとしてモデル化し、そのシーケンスをトレースしましょう。次の図は、対応する状態チャート図を示しています。

状態チャート図

アクティビティ図

アクティビティ図は、ステートマシンで進行中の非アトミック操作であるアクティビティのフローを示しています。アクティビティは、アトミック操作であるアクションをもたらします。

アクティビティ図の構成-

アクティビティ状態とアクション状態
トランジション
オブジェクト

アクティビティ図はモデリングに使用されます-

システムと対話する、アクターによって表示されるワークフロー。
フローチャートを使用した操作または計算の詳細。

例

次の図は、自動取引所システムの一部のアクティビティ図を示しています。

アクティビティ図

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

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

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

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

システム設計

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

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

オブジェクト指向の分解

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

分解の利点は-

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

並行性の特定

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

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

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

パターンの特定

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

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

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

イベントの制御

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

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

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

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

境界条件の処理

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

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

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

オブジェクト設計

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

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

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

オブジェクト識別

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

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

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

オブジェクト表現

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

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

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

操作の分類

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

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

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

アルゴリズム設計

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

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

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

関係のデザイン

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

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

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

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

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

制御の実装

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

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

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

パッケージングクラス

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

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

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

設計の最適化

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

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

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

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

冗長な関連付けの追加

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

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

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

アルゴリズムの最適化

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

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

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

派生属性の保存と保存

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

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

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

設計ドキュメント

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

利用分野

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

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

内容

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

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

特徴

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

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

OOAD-実装戦略

通常、オブジェクト指向設計の実装には、標準オブジェクト指向プログラミング言語（OOPL）の使用、またはオブジェクト設計のデータベースへのマッピングが含まれます。ほとんどの場合、両方が含まれます。

プログラミング言語を使用した実装

通常、オブジェクト設計をコードに変換するタスクは簡単なプロセスです。 C 、Java、Smalltalk、C＃、Pythonなどのオブジェクト指向プログラミング言語には、クラスを表現するためのプロビジョニングが含まれています。この章では、C を使用した概念を例示します。

次の図は、C ++を使用したCircleクラスの表現を示しています。

クラスサークル表現

アソシエーションの実装

ほとんどのプログラミング言語は、関連付けを直接実装するための構造を提供しません。したがって、アソシエーションを実装するタスクには相当な検討が必要です。

関連付けは単方向または双方向のいずれかです。また、各関連付けは1対1、1対多、または多対多のいずれかです。

単方向の関連付け

単方向の関連付けを実装するには、単方向性が維持されるように注意する必要があります。さまざまな多重度の実装は次のとおりです-

オプションの関連付け-ここでは、参加オブジェクト間にリンクが存在する場合と存在しない場合があります。たとえば、下図の顧客と当座預金口座との関連付けでは、顧客は当座預金口座を持っている場合と持っていない場合があります。

一方向の関連付け

実装のために、現在のアカウントのオブジェクトは、NULLである可能性がある顧客の属性として含まれています。 C ++を使用した実装-

class Customer {
   private:
  //attributes
   Current_Account c;//an object of Current_Account as attribute

   public:

   Customer() {
      c = NULL;
   }//assign c as NULL

   Current_Account getCurrAc() {
      return c;
   }

   void setCurrAc( Current_Account myacc) {
      c = myacc;
   }

   void removeAcc() {
      c = NULL;
   }
};

* 1対1の関連付け*-ここでは、クラスの1つのインスタンスは、関連付けられたクラスの1つのインスタンスにのみ関連付けられています。たとえば、下の図に示すように、DepartmentとManagerには1対1の関連付けがあります。

One to One Unidirectional Association

これは、NULLであってはならないManagerのオブジェクトであるDepartmentに含めることで実装されます。 C ++を使用した実装-

class Department {
   private:
  //attributes
   Manager mgr;//an object of Manager as attribute

   public:
   Department (/*parameters*/, Manager m) {//m is not NULL
     //assign parameters to variables
      mgr = m;
   }

   Manager getMgr() {
      return mgr;
   }
};

* 1対多の関連付け*-ここでは、クラスの1つのインスタンスが、関連付けられたクラスの複数のインスタンスに関連付けられています。たとえば、次の図のEmployeeとDependentの間の関連付けを検討してください。

One to Many Unidirectional Association

これは、クラスEmployeeにDependentsのリストを含めることで実装されます。 C ++ STLリストコンテナを使用した実装-

class Employee {
   private:
   char * deptName;
   list <Dependent> dep;//a list of Dependents as attribute

   public:
   void addDependent ( Dependent d) {
      dep.push_back(d);
   }//adds an employee to the department

   void removeDeoendent( Dependent d) {
      int index = find ( d, dep );
     //find() function returns the index of d in list dep
      dep.erase(index);
   }
};

双方向の関連付け

双方向の関連付けを実装するには、両方向のリンクを維持する必要があります。

オプションまたは1対1の関連付け-下の図に示すように、1対1の双方向の関連付けを持つProjectとProject Managerの関係を考慮します。

1対1の双方向の関連付け

C ++を使用した実装-

Class Project {
   private:
  //attributes
   Project_Manager pmgr;
   public:
   void setManager ( Project_Manager pm);
   Project_Manager changeManager();
};

class Project_Manager {
   private:
  //attributes
   Project pj;

   public:
   void setProject(Project p);
   Project removeProject();
};

* 1対多の関連付け*-下図に示すように、1対多の関連付けを持つ部門と従業員の間の関係を考慮します。

1対多の双方向の関連付け

C ++ STLリストコンテナを使用した実装

class Department {
   private:
   char *deptName;
   list <Employee> emp;//a list of Employees as attribute

   public:
   void addEmployee ( Employee e) {
      emp.push_back(e);
   }//adds an employee to the department

   void removeEmployee( Employee e) {
      int index = find ( e, emp );
     //find function returns the index of e in list emp
      emp.erase(index);
   }
};

class Employee {
   private:
  //attributes
   Department d;

   public:
   void addDept();
   void removeDept();
};

C ++を使用したWorksOnの実装

class WorksOn {
   private:
   Employee e;
   Project p;
   Hours h;
   char* date;

   public:
  //class methods
};

制約の実装

クラスの制約は、属性が取る値の範囲とタイプを制限します。制約を実装するために、オブジェクトがクラスからインスタンス化されるときに、有効なデフォルト値が属性に割り当てられます。実行時に値が変更されるたびに、値が有効かどうかがチェックされます。無効な値は、例外処理ルーチンまたは他のメソッドによって処理される場合があります。

例 *

年齢が18から60の範囲の値を持つ属性であるEmployeeクラスを考えます。次のC ++コードにはそれが組み込まれています-

class Employee {
   private: char* name;
   int age;
  //other attributes

   public:
   Employee() {                  //default constructor
      strcpy(name, "");
      age = 18;               //default value
   }

   class AgeError {};         //Exception class
   void changeAge( int a) {  //method that changes age
      if ( a < 18 || a > 60 ) //check for invalid condition
      throw AgeError();       //throw exception
      age = a;
   }
};

状態図の実装

状態チャート図に状態を実装するには、2つの代替実装戦略があります。

クラス内の列挙

このアプローチでは、状態はデータメンバー（またはデータメンバーのセット）の異なる値によって表されます。値は、クラス内の列挙によって明示的に定義されます。遷移は、関係するデータメンバーの値を変更するメンバー関数によって表されます。

汎化階層でのクラスの配置

このアプローチでは、一般的なポインター変数によって参照できるように、状態が一般化階層に配置されます。次の図は、状態チャート図から一般化階層への変換を示しています。

状態チャートの実装

データベースシステムへのオブジェクトマッピング

オブジェクトの永続性

オブジェクト指向システムの開発の重要な側面は、データの永続性です。永続性により、オブジェクトはそれを作成したプログラムよりも長い寿命を持ちます。永続データは、必要に応じてリロードできる場所からセカンダリストレージメディアに保存されます。

RDBMSの概要

データベースは、関連データの順序付けられたコレクションです。

データベース管理システム（DBMS）は、データベース内のデータの定義、作成、保存、操作、取得、共有、および削除のプロセスを容易にするソフトウェアのコレクションです。

リレーショナルデータベース管理システム（RDBMS）では、データはリレーションまたはテーブルとして保存されます。各列またはフィールドは属性を表し、各行またはタプルはインスタンスのレコードを表します。

各行は、「主キー」と呼ばれる選択された最小限の属性のセットによって一意に識別されます。

外部キー*は、関連テーブルの主キーである属性です。

RDBMSでクラスをテーブルとして表現する

クラスをデータベーステーブルにマップするために、各属性はテーブル内のフィールドとして表されます。既存の属性が主キーとして割り当てられるか、別のIDフィールドが主キーとして追加されます。クラスは、要件に応じて水平または垂直に分割できます。

たとえば、下の図に示すように、Circleクラスをテーブルに変換できます。

クラスをテーブルとして表す

Schema for Circle Table: CIRCLE(CID, X_COORD, Y_COORD, RADIUS, COLOR)
Creating a Table Circle using SQL command:
CREATE TABLE CIRCLE (
   CID  VARCHAR2(4) PRIMARY KEY,
   X_COORD INTEGER NOT NULL,
   Y_COORD INTEGER NOT NULL,
   Z_COORD INTEGER NOT NULL,
   COLOR
);

データベーステーブルへの関連付けのマッピング

1対1の関連付け

1：1の関連付けを実装するには、1つのテーブルの主キーが他のテーブルの外部キーとして割り当てられます。たとえば、部門とマネージャー間の関連付けを考慮してください-

1対1の関連付け

テーブルを作成するSQLコマンド

CREATE TABLE DEPARTMENT (
   DEPT_ID INTEGER PRIMARY KEY,
   DNAME VARCHAR2(30) NOT NULL,
   LOCATION VARCHAR2(20),
   EMPID INTEGER REFERENCES MANAGER
);

CREATE TABLE MANAGER (
   EMPID INTEGER PRIMARY KEY,
   ENAME VARCHAR2(50) NOT NULL,
   ADDRESS VARCHAR2(70),
);

1対多の関連付け

1：Nアソシエーションを実装するには、アソシエーションの1側のテーブルの主キーが、アソシエーションのN側のテーブルの外部キーとして割り当てられます。たとえば、部門と従業員との間の関連付けを検討してください-

1対多の関連付け

テーブルを作成するSQLコマンド

CREATE TABLE DEPARTMENT (
   DEPT_ID INTEGER PRIMARY KEY,
   DNAME VARCHAR2(30) NOT NULL,
   LOCATION VARCHAR2(20),
);

CREATE TABLE EMPLOYEE (
   EMPID INTEGER PRIMARY KEY,
   ENAME VARCHAR2(50) NOT NULL,
   ADDRESS VARCHAR2(70),
   D_ID INTEGER REFERENCES DEPARTMENT
);

多対多の関連付け

M：Nアソシエーションを実装するために、アソシエーションを表す新しい関係が作成されます。たとえば、従業員とプロジェクトの間の次の関連付けを検討してください-

多対多の関連付け

Works_Onテーブルのスキーマ*-WORKS_ON（EMPID、PID、HOURS、START_DATE）
Works_On関連付けを作成するSQLコマンド*-CREATE TABLE WORKS_ON

(
   EMPID INTEGER,
   PID INTEGER,
   HOURS INTEGER,
   START_DATE DATE,
   PRIMARY KEY (EMPID, PID),
   FOREIGN KEY (EMPID) REFERENCES EMPLOYEE,
   FOREIGN KEY (PID) REFERENCES PROJECT
);

テーブルへの継承のマッピング

継承をマッピングするために、ベーステーブルのプライマリキーが、派生テーブルの外部キーと同様にプライマリキーとして割り当てられます。

例

テーブルへの継承のマッピング

OOAD-テストと品質保証

プログラムコードを作成したら、テストして、その中のすべてのエラーを検出して処理する必要があります。多くのスキームがテスト目的で使用されています。

別の重要な側面は、プログラムが目的とする目的を果たしているかどうかを確認するプログラムの目的適合性です。フィットネスはソフトウェアの品質を定義します。

オブジェクト指向システムのテスト

テストは、ソフトウェア開発中の継続的なアクティビティです。オブジェクト指向システムでは、テストには3つのレベル、つまり単体テスト、サブシステムテスト、およびシステムテストが含まれます。

単体テスト

単体テストでは、個々のクラスがテストされます。クラス属性が設計に従って実装されているかどうか、およびメソッドとインターフェイスにエラーがないかどうかが確認されます。ユニットテストは、構造を実装するアプリケーションエンジニアの責任です。

サブシステムのテスト

これには、特定のモジュールまたはサブシステムのテストが含まれ、サブシステムリードの責任です。サブシステムと外部との相互作用だけでなく、サブシステム内の関連付けのテストも含まれます。サブシステムテストは、サブシステムの新しくリリースされた各バージョンの回帰テストとして使用できます。

システムテスト

システムテストには、システム全体のテストが含まれ、品質保証チームの責任です。チームは、新しいリリースをアセンブルするときに、システムテストを回帰テストとして頻繁に使用します。

オブジェクト指向のテスト手法

グレーボックステスト

オブジェクト指向プログラムのテスト用に設計できるさまざまなタイプのテストケースは、グレーボックステストケースと呼ばれます。グレーボックステストの重要なタイプのいくつかは次のとおりです-

状態モデルベースのテスト-これには、状態カバレッジ、状態遷移カバレッジ、および状態遷移パスカバレッジが含まれます。
ユースケースベースのテスト-各ユースケースの各シナリオがテストされます。
クラス図ベースのテスト-各クラス、派生クラス、関連付け、および集計がテストされます。
シーケンス図ベースのテスト-シーケンス図のメッセージのメソッドがテストされます。

サブシステムテストの手法

サブシステムテストの2つの主なアプローチは次のとおりです-

スレッドベースのテスト-サブシステムで単一のユースケースを実現するために必要なすべてのクラスが統合され、テストされています。
使用ベースのテスト-階層の各レベルのモジュールのインターフェイスとサービスがテストされます。テストは、個々のクラスから始まり、クラスで構成される小さなモジュール、徐々に大きなモジュール、そして最後にすべての主要なサブシステムに進みます。

システムテストのカテゴリ

アルファテスト-これは、ソフトウェアを開発する組織内のテストチームによって実行されます。
ベータテスト-これは協力顧客の選択グループによって実行されます。
受け入れテスト-これは、成果物を受け入れる前に顧客によって実行されます。

ソフトウェア品質保証

ソフトウェア品質

SchulmeyerとMcManusは、ソフトウェア品質を「ソフトウェア製品全体の使用に対する適合性」と定義しています。良質のソフトウェアは、本来行うべきことを正確に実行し、ユーザーが定めた要件仕様の満足度の観点から解釈されます。

品質保証

ソフトウェア品質保証は、ソフトウェア製品が使用に適している程度を決定する方法論です。ソフトウェアの品質を決定するために含まれている活動は-

監査
標準とガイドラインの開発
レポートの作成
品質システムの見直し

品質要因

正確性-正確性は、ソフトウェア要件が適切に満たされるかどうかを決定します。
ユーザビリティ-ユーザビリティは、ソフトウェアをさまざまなカテゴリのユーザ（初心者、非技術者、および専門家）が使用できるかどうかを決定します。
移植性-移植性は、ソフトウェアが異なるハードウェアデバイスを備えた異なるプラットフォームで動作できるかどうかを決定します。
保守性-保守性は、エラーを修正し、モジュールを更新できる容易さを決定します。
再利用性-再利用性は、モジュールとクラスを他のソフトウェア製品の開発に再利用できるかどうかを決定します。

オブジェクト指向のメトリック

メトリックは、プロジェクトメトリック、製品メトリック、プロセスメトリックの3つのカテゴリに大きく分類できます。

プロジェクト指標

プロジェクトメトリックにより、ソフトウェアプロジェクトマネージャーは進行中のプロジェクトのステータスとパフォーマンスを評価できます。次のメトリックは、オブジェクト指向ソフトウェアプロジェクトに適しています-

シナリオスクリプトの数
キークラスの数
サポートクラスの数
サブシステムの数

製品メトリック

製品メトリックは、開発されたソフトウェア製品の特性を測定します。オブジェクト指向システムに適した製品メトリックは次のとおりです-

クラスごとのメソッド-クラスの複雑さを決定します。クラスのすべてのメソッドが同等に複雑であると想定される場合、より多くのメソッドを持つクラスはより複雑であるため、エラーの影響を受けやすくなります。
継承構造-いくつかの小さな継承ラティスを持つシステムは、単一の大きな継承ラティスを持つシステムよりもよく構造化されています。経験則として、継承ツリーのレベル数は7（±2）を超えてはならず、ツリーのバランスをとる必要があります。
結合と結合-結合度が低く、結合度が高いモジュールは、再利用性と保守性が向上するため、設計が適切であると見なされます。
クラスの応答-クラスのインスタンスによって呼び出されるメソッドの効率を測定します。

プロセス指標

プロセスメトリックは、プロセスのパフォーマンスを測定するのに役立ちます。それらはすべてのプロジェクトで長期間にわたって収集されます。これらは、ソフトウェアプロセスの長期的な改善の指標として使用されます。一部のプロセスメトリックは次のとおりです-

KLOC（キロ行コード）の数
欠陥除去効率
テスト中に検出された平均障害数
KLOCあたりの潜在的な欠陥の数

Object-oriented-analysis-design-quick-guide

OOAD-オブジェクト指向のパラダイム

簡単な歴史

オブジェクト指向分析

オブジェクト指向設計

オブジェクト指向プログラミング

OOAD-オブジェクトモデル

オブジェクトとクラス

対象

クラス

カプセル化とデータの非表示

カプセル化

データ隠蔽

メッセージの受け渡し

継承

継承の種類

多型

一般化と専門化

一般化

特化

リンクと関連付け

Link

協会

協会の程度

関連付けのカーディナリティ比

集約または構成

オブジェクトモデルの利点

OOAD-オブジェクト指向システム

オブジェクト指向ソフトウェア開発のフェーズ

オブジェクト指向分析

オブジェクト指向設計

オブジェクト指向の実装とテスト

OOAD-オブジェクト指向の原則

オブジェクト指向システムの原理

抽象化

カプセル化

モジュール性

階層

タイピング

並行性

持続性

OOAD-オブジェクト指向分析

オブジェクトモデリング

動的モデリング

機能モデリング

構造化分析と オブジェクト指向分析

オブジェクト指向分析の利点/欠点

構造化分析の利点/欠点

OOAD-動的モデリング

状態と状態遷移

状態

状態の部分

初期状態と最終状態

遷移

イベント

外部および内部イベント

遅延イベント

イベントクラス

行動

アクティビティ

アクション

入場と退場のアクション

シナリオ

動的モデリングの図

相互作用図

状態遷移図

イベントの並行性

システムの同時実行性

オブジェクト内の並行性

単純および複合状態

シーケンシャルサブステート

同時サブステート

OOAD-機能モデリング

データフロー図

DFDの機能

プロセス

データフロー

俳優

データストア

制約

構造化分析とオブジェクト指向分析