OOAD-クイックガイド

簡単な歴史

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

• 最初のオブジェクト指向言語は、1960年にノルウェーコンピューティングセンターの研究者によって開発されたSimula（実システムのシミュレーション）でした。

• 1970年、XeroxPARKのAlanKayと彼の研究グループは、Dynabookという名前のパーソナルコンピューターと、Dynabookをプログラミングするための最初の純粋なオブジェクト指向プログラミング言語（OOPL）であるSmalltalkを作成しました。

• 1980年代に、Grady Boochは、主にプログラミング言語であるAdaの設計を紹介するObject OrientedDesignというタイトルの論文を発表しました。その後の版では、彼はアイデアを完全なオブジェクト指向設計手法にまで拡張しました。

• 1990年代、Coadは行動のアイデアをオブジェクト指向の方法に取り入れました。

その他の重要な革新は、James Rumbaughによるオブジェクトモデリング技法（OMT）とIvar Jacobsonによるオブジェクト指向ソフトウェアエンジニアリング（OOSE）でした。

オブジェクト指向分析

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

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

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

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

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

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

オブジェクト指向設計

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

実装の詳細には、通常、次のものが含まれます。

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

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

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

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

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

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

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

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

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

オブジェクトとクラス

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

オブジェクト

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

• システム内の他のオブジェクトからそれを区別するアイデンティティ。

• オブジェクトの特性プロパティと、オブジェクトが保持するプロパティの値を決定する状態。

• 状態の変化に関して、オブジェクトによって実行される外部から見えるアクティビティを表す動作。

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

クラス

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

クラスの構成要素は次のとおりです。

• クラスからインスタンス化されるオブジェクトの属性のセット。一般に、クラスのオブジェクトが異なれば、属性の値にも多少の違いがあります。属性は、クラスデータと呼ばれることがよくあります。

• クラスのオブジェクトの動作を表す一連の操作。操作は、関数またはメソッドとも呼ばれます。

Example

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

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

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

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

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

カプセル化とデータ隠蔽

カプセル化

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

データの隠蔽

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

Example

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

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

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

メッセージパッシング

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

メッセージパッシングの特徴は次のとおりです。

• 2つのオブジェクト間で受け渡されるメッセージは、通常、単方向です。
• メッセージパッシングにより、オブジェクト間のすべての相互作用が可能になります。
• メッセージパッシングには、基本的にクラスメソッドの呼び出しが含まれます。
• さまざまなプロセスのオブジェクトがメッセージパッシングに関与する可能性があります。

継承

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

Example

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

継承の種類

• Single Inheritance −サブクラスは単一のスーパークラスから派生します。

• Multiple Inheritance −サブクラスは複数のスーパークラスから派生します。

• Multilevel Inheritance −サブクラスはスーパークラスから派生し、スーパークラスは別のクラスから派生します。

• Hierarchical Inheritance −クラスにはいくつかのサブクラスがあり、各サブクラスには後続のサブクラスがあり、ツリー構造を形成するためにいくつかのレベルが続きます。

• Hybrid Inheritance −格子構造を形成するための、複数レベルとマルチレベルの継承の組み合わせ。

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

ポリモーフィズム

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

Example

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

一般化と専門化

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

一般化

一般化プロセスでは、クラスの共通の特性が組み合わされて、より高いレベルの階層のクラスが形成されます。つまり、サブクラスが組み合わされて、一般化されたスーパークラスが形成されます。これは、「is – a – kind –of」の関係を表します。たとえば、「車は一種の陸上車両」、「船は一種の水上車両」などです。

専門分野

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

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

リンクと関連付け

リンク

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

協会

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

協会の学位

関連付けの程度は、接続に関係するクラスの数を示します。度は、単項、2進数、または3進数の場合があります。

• A unary relationship 同じクラスのオブジェクトを接続します。

• A binary relationship 2つのクラスのオブジェクトを接続します。

• A ternary relationship 3つ以上のクラスのオブジェクトを接続します。

アソシエーションのカーディナリティ比率

バイナリアソシエーションのカーディナリティは、アソシエーションに参加しているインスタンスの数を示します。カーディナリティ比率には、次の3つのタイプがあります。

• One–to–One −クラスAの単一のオブジェクトは、クラスBの単一のオブジェクトに関連付けられています。

• One–to–Many −クラスAの単一のオブジェクトは、クラスBの多くのオブジェクトに関連付けられています。

• Many–to–Many −クラスAのオブジェクトは、クラスBの多くのオブジェクトに関連付けられ、逆に、クラスBのオブジェクトはクラスAの多くのオブジェクトに関連付けられる場合があります。

集約または構成

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

Example

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

• Physical containment −たとえば、コンピューターはモニター、CPU、マウス、キーボードなどで構成されています。

• Conceptual containment −例として、株主は–シェアを持っています。

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

オブジェクト指向に関連するコアコンセプトを確認したので、このモデルが提供する利点に注目する価値があります。

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

• ソフトウェアの開発を迅速化するのに役立ちます。

• メンテナンスが簡単です。モジュールでエラーが発生した場合、ソフトウェアの他の部分がまだ稼働している間に、プログラマーはその特定のモジュールを修正できます。

• 比較的手間のかからないアップグレードをサポートします。

• オブジェクト、デザイン、および機能の再利用を可能にします。

• 特に複雑なシステムの統合において、開発リスクを軽減します。

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

• Analysis,
• デザイン、そして
• Implementation.

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

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

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

オブジェクト指向分析

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

オブジェクト指向設計

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

System Design

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

Object Design

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

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

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

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

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

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

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

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

• Abstraction
• Encapsulation
• Modularity
• Hierarchy

Minor Elements−マイナーとは、これらの要素が有用であるが、オブジェクトモデルの必須部分ではないことを意味します。3つのマイナーな要素は次のとおりです。

• Typing
• Concurrency
• Persistence

抽象化

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

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

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

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

カプセル化

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

モジュール性

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

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

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

階層

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

OOAの2つのタイプの階層は次のとおりです。

• “IS–A” hierarchy−継承における階層関係を定義します。これにより、スーパークラスから、サブクラスなどを持つ可能性のあるいくつかのサブクラスが派生する可能性があります。たとえば、クラスFlowerからクラスRoseを派生させる場合、バラは「is–a」の花であると言えます。

• “PART–OF” hierarchy−クラスが他のクラスで構成される可能性のある集約の階層関係を定義します。たとえば、花はがく片、花びら、雄しべ、および心皮で構成されています。花びらは花の「一部」であると言えます。

タイピング

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

タイピングの2つのタイプは次のとおりです。

• Strong Typing −ここでは、プログラミング言語Eiffelと同様に、コンパイル時にオブジェクトの動作がチェックされます。

• Weak Typing−ここでは、メッセージはどのクラスにも送信できます。プログラミング言語Smalltalkのように、動作は実行時にのみチェックされます。

並行性

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

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

永続性

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

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

オブジェクト指向分析のために互いに組み合わせて使用​​される3つの分析手法は、オブジェクトモデリング、動的モデリング、および機能モデリングです。

オブジェクトモデリング

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

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

• オブジェクトを識別し、クラスにグループ化します
• クラス間の関係を特定する
• ユーザーオブジェクトモデル図を作成する
• Define user object attributes
• Define the operations that should be performed on the classes
• Review glossary

Dynamic Modelling

After the static behavior of the system is analyzed, its behavior with respect to time and external changes needs to be examined. This is the purpose of dynamic modelling.

Dynamic Modelling can be defined as “a way of describing how an individual object responds to events, either internal events triggered by other objects, or external events triggered by the outside world”.

The process of dynamic modelling can be visualized in the following steps −

• Identify states of each object
• Identify events and analyze the applicability of actions
• Construct dynamic model diagram, comprising of state transition diagrams
• Express each state in terms of object attributes
• Validate the state–transition diagrams drawn

Functional Modelling

Functional Modelling is the final component of object-oriented analysis. The functional model shows the processes that are performed within an object and how the data changes as it moves between methods. It specifies the meaning of the operations of object modelling and the actions of dynamic modelling. The functional model corresponds to the data flow diagram of traditional structured analysis.

The process of functional modelling can be visualized in the following steps −

• Identify all the inputs and outputs
• Construct data flow diagrams showing functional dependencies
• State the purpose of each function
• Identify constraints
• Specify optimization criteria

Structured Analysis vs. Object Oriented Analysis

The Structured Analysis/Structured Design (SASD) approach is the traditional approach of software development based upon the waterfall model. The phases of development of a system using SASD are −

• Feasibility Study
• Requirement Analysis and Specification
• System Design
• Implementation
• Post-implementation Review

Now, we will look at the relative advantages and disadvantages of structured analysis approach and object-oriented analysis approach.

Advantages/Disadvantages of Object Oriented Analysis

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 of 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.

The dynamic model represents the time–dependent aspects of a system. It is concerned with the temporal changes in the states of the objects in a system. The main concepts are −

• State, which is the situation at a particular condition during the lifetime of an object.

• Transition, a change in the state

• Event, an occurrence that triggers transitions

• Action, an uninterrupted and atomic computation that occurs due to some event, and

• Concurrency of transitions.

A state machine models the behavior of an object as it passes through a number of states in its lifetime due to some events as well as the actions occurring due to the events. A state machine is graphically represented through a state transition diagram.

States and State Transitions

State

The state is an abstraction given by the values of the attributes that the object has at a particular time period. It is a situation occurring for a finite time period in the lifetime of an object, in which it fulfils certain conditions, performs certain activities, or waits for certain events to occur. In state transition diagrams, a state is represented by rounded rectangles.

Parts of a state

• Name − A string differentiates one state from another. A state may not have any name.

• Entry/Exit Actions − It denotes the activities performed on entering and on exiting the state.

• Internal Transitions − The changes within a state that do not cause a change in the state.

• Sub–states − States within states.

Initial and Final States

The default starting state of an object is called its initial state. The final state indicates the completion of execution of the state machine. The initial and the final states are pseudo-states, and may not have the parts of a regular state except name. In state transition diagrams, the initial state is represented by a filled black circle. The final state is represented by a filled black circle encircled within another unfilled black circle.

Transition

A transition denotes a change in the state of an object. If an object is in a certain state when an event occurs, the object may perform certain activities subject to specified conditions and change the state. In this case, a state−transition is said to have occurred. The transition gives the relationship between the first state and the new state. A transition is graphically represented by a solid directed arc from the source state to the destination state.

The five parts of a transition are −

• Source State − The state affected by the transition.

• Event Trigger − The occurrence due to which an object in the source state undergoes a transition if the guard condition is satisfied.

• Guard Condition − A Boolean expression which if True, causes a transition on receiving the event trigger.

• Action − An un-interruptible and atomic computation that occurs on the source object due to some event.

• Target State − The destination state after completion of transition.

Example

Suppose a person is taking a taxi from place X to place Y. The states of the person may be: Waiting (waiting for taxi), Riding (he has got a taxi and is travelling in it), and Reached (he has reached the destination). The following figure depicts the state transition.

Events

Events are some occurrences that can trigger state transition of an object or a group of objects. Events have a location in time and space but do not have a time period associated with it. Events are generally associated with some actions.

Examples of events are mouse click, key press, an interrupt, stack overflow, etc.

Events that trigger transitions are written alongside the arc of transition in state diagrams.

Example

Considering the example shown in the above figure, the transition from Waiting state to Riding state takes place when the person gets a taxi. Likewise, the final state is reached, when he reaches the destination. These two occurrences can be termed as events Get_Taxi and Reach_Destination. The following figure shows the events in a state machine.

External and Internal Events

External events are those events that pass from a user of the system to the objects within the system. For example, mouse click or key−press by the user are external events.

Internal events are those that pass from one object to another object within a system. For example, stack overflow, a divide error, etc.

Deferred Events

Deferred events are those which are not immediately handled by the object in the current state but are lined up in a queue so that they can be handled by the object in some other state at a later time.

Event Classes

Event class indicates a group of events with common structure and behavior. As with classes of objects, event classes may also be organized in a hierarchical structure. Event classes may have attributes associated with them, time being an implicit attribute. For example, we can consider the events of departure of a flight of an airline, which we can group into the following class −

Flight_Departs (Flight_No, From_City, To_City, Route)

Actions

Activity

Activity is an operation upon the states of an object that requires some time period. They are the ongoing executions within a system that can be interrupted. Activities are shown in activity diagrams that portray the flow from one activity to another.

Action

An action is an atomic operation that executes as a result of certain events. By atomic, it is meant that actions are un-interruptible, i.e., if an action starts executing, it runs into completion without being interrupted by any event. An action may operate upon an object on which an event has been triggered or on other objects that are visible to this object. A set of actions comprise an activity.

Entry and Exit Actions

Entry action is the action that is executed on entering a state, irrespective of the transition that led into it.

Likewise, the action that is executed while leaving a state, irrespective of the transition that led out of it, is called an exit action.

Scenario

Scenario is a description of a specified sequence of actions. It depicts the behavior of objects undergoing a specific action series. The primary scenarios depict the essential sequences and the secondary scenarios depict the alternative sequences.

Diagrams for Dynamic Modelling

There are two primary diagrams that are used for dynamic modelling −

Interaction Diagrams

Interaction diagrams describe the dynamic behavior among different objects. It comprises of a set of objects, their relationships, and the message that the objects send and receive. Thus, an interaction models the behavior of a group of interrelated objects. The two types of interaction diagrams are −

• Sequence Diagram − It represents the temporal ordering of messages in a tabular manner.

• Collaboration Diagram − It represents the structural organization of objects that send and receive messages through vertices and arcs.

State Transition Diagram

State transition diagrams or state machines describe the dynamic behavior of a single object. It illustrates the sequences of states that an object goes through in its lifetime, the transitions of the states, the events and conditions causing the transition and the responses due to the events.

Concurrency of Events

In a system, two types of concurrency may exist. They are −

System Concurrency

Here, concurrency is modelled in the system level. The overall system is modelled as the aggregation of state machines, where each state machine executes concurrently with others.

Concurrency within an Object

Here, an object can issue concurrent events. An object may have states that are composed of sub-states, and concurrent events may occur in each of the sub-states.

Concepts related to concurrency within an object are as follows −

Simple and Composite States

A simple state has no sub-structure. A state that has simpler states nested inside it is called a composite state. A sub-state is a state that is nested inside another state. It is generally used to reduce the complexity of a state machine. Sub-states can be nested to any number of levels.

Composite states may have either sequential sub-states or concurrent sub-states.

Sequential Sub-states

In sequential sub-states, the control of execution passes from one sub-state to another sub-state one after another in a sequential manner. There is at most one initial state and one final state in these state machines.

The following figure illustrates the concept of sequential sub-states.

Concurrent Sub-states

In concurrent sub-states, the sub-states execute in parallel, or in other words, each state has concurrently executing state machines within it. Each of the state machines has its own initial and final states. If one concurrent sub-state reaches its final state before the other, control waits at its final state. When all the nested state machines reach their final states, the sub-states join back to a single flow.

The following figure shows the concept of concurrent sub-states.

Functional Modelling gives the process perspective of the object-oriented analysis model and an overview of what the system is supposed to do. It defines the function of the internal processes in the system with the aid of Data Flow Diagrams (DFDs). It depicts the functional derivation of the data values without indicating how they are derived when they are computed, or why they need to be computed.

Data Flow Diagrams

Functional Modelling is represented through a hierarchy of DFDs. The DFD is a graphical representation of a system that shows the inputs to the system, the processing upon the inputs, the outputs of the system as well as the internal data stores. DFDs illustrate the series of transformations or computations performed on the objects or the system, and the external controls and objects that affect the transformation.

Rumbaugh et al. have defined DFD as, “A data flow diagram is a graph which shows the flow of data values from their sources in objects through processes that transform them to their destinations on other objects.”

The four main parts of a DFD are −

• Processes,
• Data Flows,
• Actors, and
• Data Stores.

The other parts of a DFD are −

• Constraints, and
• Control Flows.

Features of a DFD

Processes

Processes are the computational activities that transform data values. A whole system can be visualized as a high-level process. A process may be further divided into smaller components. The lowest-level process may be a simple function.

Representation in DFD − A process is represented as an ellipse with its name written inside it and contains a fixed number of input and output data values.

Example − The following figure shows a process Compute_HCF_LCM that accepts two integers as inputs and outputs their HCF (highest common factor) and LCM (least common multiple).

Data Flows

Data flow represents the flow of data between two processes. It could be between an actor and a process, or between a data store and a process. A data flow denotes the value of a data item at some point of the computation. This value is not changed by the data flow.

Representation in DFD − A data flow is represented by a directed arc or an arrow, labelled with the name of the data item that it carries.

In the above figure, Integer_a and Integer_b represent the input data flows to the process, while L.C.M. and H.C.F. are the output data flows.

A data flow may be forked in the following cases −

• The output value is sent to several places as shown in the following figure. Here, the output arrows are unlabelled as they denote the same value.

• The data flow contains an aggregate value, and each of the components is sent to different places as shown in the following figure. Here, each of the forked components is labelled.

Actors

Actors are the active objects that interact with the system by either producing data and inputting them to the system, or consuming data produced by the system. In other words, actors serve as the sources and the sinks of data.

Representation in DFD − An actor is represented by a rectangle. Actors are connected to the inputs and outputs and lie on the boundary of the DFD.

Example − The following figure shows the actors, namely, Customer and Sales_Clerk in a counter sales system.

Data Stores

Data stores are the passive objects that act as a repository of data. Unlike actors, they cannot perform any operations. They are used to store data and retrieve the stored data. They represent a data structure, a disk file, or a table in a database.

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

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

制約

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

• オブジェクトモデリングでは、制約によってオブジェクト間の関係が定義されます。また、オブジェクトがさまざまな時間に取る可能性のあるさまざまな値の間の関係を定義する場合もあります。

• 動的モデリングでは、制約はさまざまなオブジェクトの状態とイベントの間の関係を定義します。

• 機能モデリングでは、制約は変換と計算の制限を定義します。

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

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

制御フロー

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

Representation in DFD −制御フローは、ブール値を生成するプロセスからそれらによって制御されるプロセスまでの点線の弧で表されます。

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

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

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

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

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

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

システム内のアクターは-

• Customers
• Salesperson
• Proprietor

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

システムでは、次の3つのプロセスを識別できます。

• 顧客の登録
• プロセス販売
• 贈り物を確認する

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

• お客様情報
• 販売詳細
• ギフトの詳細

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

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

DFDの長所と短所

利点	短所
DFDはシステムの境界を表すため、外部オブジェクトとシステム内のプロセスとの関係を表すのに役立ちます。	DFDの作成には長い時間がかかりますが、実際の目的では実行できない場合があります。
これらは、ユーザーがシステムについての知識を持つのに役立ちます。	DFDは、時間依存の動作に関する情報を提供しません。つまり、変換がいつ実行されるかを指定しません。
グラフィック表現は、プログラマーがシステムを開発するための青写真として機能します。	それらは、計算の頻度や計算の理由に光を当てません。
DFDは、システムプロセスに関する詳細情報を提供します。	DFDの準備は複雑なプロセスであり、かなりの専門知識が必要です。また、技術者以外の人には理解しにくいです。
これらは、システムドキュメントの一部として使用されます。	準備の方法は主観的であり、十分な範囲が不正確になります。

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

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

• オブジェクトモデリングは、オブジェクトの観点からソフトウェアシステムの静的構造を開発します。したがって、システムの「実行者」を示します。

• 動的モデリングは、外部イベントに応答してオブジェクトの時間的動作を開発します。これは、オブジェクトに対して実行される一連の操作を示しています。

• 機能モデルは、システムが何をすべきかについての概要を示します。

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

オブジェクトモデルに関する機能モデルの4つの主要部分は次のとおりです。

• Process −プロセスは、実装する必要のあるオブジェクトのメソッドを意味します。

• Actors −アクターは、オブジェクトモデル内のオブジェクトです。

• Data Stores −これらは、オブジェクトモデル内のオブジェクトまたはオブジェクトの属性のいずれかです。

• Data Flows−アクターとの間のデータフローは、オブジェクト上またはオブジェクトによる操作を表します。データストアとの間のデータフローは、クエリまたは更新を表します。

機能モデルと動的モデル

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

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

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

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

簡単な歴史

1990年代に、Grady BoochによるOOAD技法、James RumbaughによるOMT（オブジェクトモデリング技法）、Ivar JacobsonによるOOSE（オブジェクト指向ソフトウェアエンジニアリング）など、いくつかの技法の融合として開発されました。UMLは、OOADのセマンティックモデル、構文表記、および図を標準化しようとしました。

UMLのシステムとモデル

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

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

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

UMLの概念モデル

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

• 基本的な構成要素
• Rules
• 一般的なメカニズム

基本的な構成要素

UMLの3つの構成要素は次のとおりです。

• Things
• Relationships
• Diagrams

物事

UMLには4種類あります。

• Structural Things−これらは、物理的または概念的な静的要素を表すUMLモデルの名詞です。構造的なものは、クラス、インターフェース、コラボレーション、ユースケース、アクティブクラス、コンポーネント、およびノー​​ドです。

• Behavioral Things−これらは、時間と空間にわたる動的な動作を表すUMLモデルの動詞です。行動の2つのタイプは、相互作用とステートマシンです。

• Grouping Things−それらはUMLモデルの組織的な部分を構成します。グループ化するのは、パッケージという1種類だけです。

• Annotational Things −これらは、要素を説明するために適用されるコメントを表すUMLモデルの説明です。

関係

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

• Dependency−これは、一方の変化が他方の変化をもたらすような、2つのものの間の意味関係です。前者は独立したものであり、後者は依存的なものです。

• Association −これは、共通の構造と共通の動作を持つリンクのグループを表す構造関係です。

• Generalization −これは、サブクラスがスーパークラスから構造と動作を継承する一般化/特殊化の関係を表します。

• Realization −これは、2つ以上の分類子間の意味関係であり、1つの分類子が、他の分類子が確実に遵守する契約を定めます。

ダイアグラム

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

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

ルール

UMLには、モデルが意味的に自己無撞着であり、システム内の他のモデルと調和して関連するように、いくつかのルールがあります。UMLには、次のセマンティックルールがあります。

• Names
• Scope
• Visibility
• Integrity
• Execution

一般的なメカニズム

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

• Specifications
• Adornments
• 共通の部門
• 拡張メカニズム

仕様

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

装飾品

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

共通の部門

オブジェクト指向システムは、さまざまな方法で分割できます。除算の2つの一般的な方法は次のとおりです。

• Division of classes and objects−クラスは、類似したオブジェクトのグループを抽象化したものです。オブジェクトは、システム内に実際に存在する具体的なインスタンスです。

• Division of Interface and Implementation−インターフェースは相互作用のルールを定義します。実装は、インターフェースで定義されたルールの具体的な実現です。

拡張メカニズム

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

• Stereotypes − UMLの語彙を拡張し、既存のビルディングブロックから新しいビルディングブロックを作成できるようにします。

• Tagged Values −UMLビルディングブロックのプロパティを拡張します。

• Constraints −UMLビルディングブロックのセマンティクスを拡張します。

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

クラス

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

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

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

• Public−パブリックメンバーは、システムのどこからでも見ることができます。クラス図では、接頭辞「+」が付いています。

• Private−プライベートメンバーは、クラス内からのみ表示されます。クラス外からはアクセスできません。プライベートメンバーの前には記号「-」が付いています。

• Protected−保護されたメンバーは、クラス内およびこのクラスから継承されたサブクラスからは表示されますが、外部からは表示されません。記号「＃」が前に付きます。

抽象クラスのクラス名はイタリックで記述されています。

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

オブジェクト

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

• 上部のセクションには、オブジェクトの名前と、それがインスタンスであるクラスまたはパッケージの名前が含まれています。名前は次の形式を取ります-

  • object-name −クラス名

  • object-name −クラス名::パッケージ名

  • class-name −匿名オブジェクトの場合

• 下のセクションは、属性の値を表します。これは、attribute-name = valueの形式を取ります。

• オブジェクトは、角の丸い長方形を使用して表される場合があります。

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

成分

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

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

インターフェース

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

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

パッケージ

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

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

関係

さまざまなタイプの関係の表記は次のとおりです。

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

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

UML構造図は、クラス図、オブジェクト図、コンポーネント図、配置図に分類されます。

クラス図

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

システムのクラス図

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

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

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

システム内のクラス

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

関係

• A Bank “has–a” number of Branches −構成、1対多

• A Branch with role Zonal Head Office supervises other Branches −単項関連、1対多

• A Branch “has–a” number of accounts −集約、1対多

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

• A Customer can have one Current Account −関連付け、1対1

• A Customer can have one Savings Account −関連付け、1対1

• A Branch “has–a” number of Loans −集約、1対多

• A Customer can take many loans −関連付け、1対多

オブジェクト図

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

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

コンポーネント図

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

コンポーネント図は、次のもので構成されます。

• Components
• Interfaces
• Relationships
• パッケージとサブシステム（オプション）

コンポーネント図は次の目的で使用されます-

• フォワードエンジニアリングとリバースエンジニアリングによるシステムの構築。

• オブジェクト指向プログラミング言語を使用してシステムを開発しながら、ソースコードファイルの構成管理をモデル化します。

• モデリングデータベースでスキーマを表す。

• 動的システムのモデリング動作。

Example

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

配置図

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

配置図は次の目的で使用されます-

• 通常、ソフトウェアを多用するハードウェアのコレクションで構成される組み込みシステムのモデルデバイス。

• クライアント/サーバーシステムのトポロジを表します。

• 完全分散システムをモデル化します。

Example

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

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

ユースケースモデル

使用事例

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

俳優

アクターは、ユースケースのユーザーが果たす役割を表します。アクターは、人（学生、顧客など）、デバイス（ワークステーションなど）、または別のシステム（銀行、機関など）の場合があります。

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

ユースケース図

ユースケース図は、システム内の要素がどのように動作し、コンテキストでどのように使用できるかについての外観を示しています。

ユースケース図は、次のもので構成されます。

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

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

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

• 外部の観点からシステムの要件をモデル化すること。

Example

自動トレーディングハウスシステムについて考えてみましょう。システムの次の機能を想定しています-

• 商社は、個人顧客と法人顧客の2種類の顧客と取引を行っています。

• 顧客が注文すると、販売部門によって処理され、顧客に請求書が渡されます。

• このシステムにより、マネージャーは顧客アカウントを管理し、顧客から投稿された質問に答えることができます。

相互作用図

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

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

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

• シーケンス図を使用した時間順序による制御フロー。

• コラボレーション図を使用した組織の制御フロー。

シーケンス図

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

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

Example −自動トレーディングハウスシステムのシーケンス図を次の図に示します。

コラボレーション図

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

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

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

状態図図

ステートチャート図は、ある状態から別の状態へのオブジェクトの制御フローを表すステートマシンを示しています。ステートマシンは、イベントが原因でオブジェクトが受ける状態のシーケンスと、イベントへの応答を表します。

状態遷移図は、次のもので構成されます。

• 状態：シンプルまたはコンポジット
• 状態間の遷移
• 遷移を引き起こすイベント
• イベントによるアクション

ステートチャート図は、本質的に反応性のあるオブジェクトをモデル化するために使用されます。

Example

Automated Trading House Systemで、Orderをオブジェクトとしてモデル化し、そのシーケンスをトレースしましょう。次の図は、対応する状態チャート図を示しています。

アクティビティ図

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

アクティビティ図は次のもので構成されます-

• 活動状態と行動状態
• Transitions
• Objects

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

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

Example

次の図は、自動トレーディングハウスシステムの一部のアクティビティ図を示しています。

分析フェーズの後、概念モデルは、オブジェクト指向設計（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

• 説明的ではなく図式的

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

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

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

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

アソシエーションの実装

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

アソシエーションは、単方向または双方向のいずれかです。さらに、各関連付けは、1対1、1対多、または多対多のいずれかになります。

一方向の関連付け

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

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

実装のために、当座預金のオブジェクトは、NULLの可能性があるCustomerの属性として含まれています。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;
   } 
};

• One–to–one Associations−ここで、クラスの1つのインスタンスは、関連付けられたクラスの1つのインスタンスにのみ関連しています。たとえば、次の図に示すように、部門とマネージャーには1対1の関連付けがあります。

これは、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;  
   }    
};

• One–to–many Associations−ここで、クラスの1つのインスタンスは、関連付けられたクラスの複数のインスタンスに関連付けられています。たとえば、次の図の従業員と扶養家族の関係について考えてみます。

これは、クラスEmployeeに依存関係のリストを含めることによって実装されます。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);
   }               
};

双方向の関連付け

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

• Optional or one–to–one Associations −次の図に示すように、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();   
};

• One–to–many Associations −次の図に示すように、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();
};

クラスとしての関連付けの実装

関連付けにいくつかの属性が関連付けられている場合は、別のクラスを使用して実装する必要があります。たとえば、次の図に示すように、従業員とプロジェクトの間の1対1の関連付けについて考えてみます。

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

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

   public:
   // class methods
};

制約の実装

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

Example

年齢が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）では、データはリレーションまたはテーブルとして格納されます。各列またはフィールドは属性を表し、各行またはタプルはインスタンスのレコードを表します。

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

A foreign key 関連するテーブルの主キーである属性です。

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の関連付けを実装するには、一方のテーブルの主キーをもう一方のテーブルの外部キーとして割り当てます。たとえば、部門とマネージャーの関係について考えてみましょう。

テーブルを作成するための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側にあるテーブルの外部キーとして割り当てられます。たとえば、部門と従業員の関連付けについて考えてみます。

テーブルを作成するための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アソシエーションを実装するために、アソシエーションを表す新しいリレーションが作成されます。たとえば、従業員とプロジェクトの間の次の関連付けについて考えてみます。

Schema for Works_On Table − WORKS_ON（EMPID、PID、HOURS、START_DATE）

SQL command to create Works_On association − 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 
);

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

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

Example

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

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

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

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

ユニットテスト

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

サブシステムテスト

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

システムテスト

システムテストには、システム全体のテストが含まれ、品質保証チームの責任です。チームは、新しいリリースを組み立てるときに、回帰テストとしてシステムテストを使用することがよくあります。

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

グレーボックステスト

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

• State model based testing −これには、状態カバレッジ、状態遷移カバレッジ、および状態遷移パスカバレッジが含まれます。

• Use case based testing −各ユースケースの各シナリオがテストされます。

• Class diagram based testing −各クラス、派生クラス、関連付け、および集計がテストされます。

• Sequence diagram based testing −シーケンス図のメッセージのメソッドがテストされます。

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

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

• Thread based testing −サブシステムで単一のユースケースを実現するために必要なすべてのクラスが統合され、テストされます。

• Use based testing−階層の各レベルのモジュールのインターフェースとサービスがテストされます。テストは、個々のクラスから始まり、クラスで構成される小さなモジュール、徐々に大きなモジュール、そして最後にすべての主要なサブシステムになります。

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

• Alpha testing −これは、ソフトウェアを開発する組織内のテストチームによって実行されます。

• Beta testing −これは協力する顧客の選択されたグループによって実行されます。

• Acceptance testing −これは、成果物を受け入れる前に顧客によって実行されます。

ソフトウェア品質保証

ソフトウェアの品質

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

品質保証

ソフトウェア品質保証は、ソフトウェア製品が使用に適している程度を決定する方法論です。ソフトウェアの品質を判断するために含まれるアクティビティは次のとおりです。

• Auditing
• 標準とガイドラインの開発
• レポートの作成
• 品質システムのレビュー

品質要因

• Correctness −正確さは、ソフトウェア要件が適切に満たされているかどうかを決定します。

• Usability −ユーザビリティは、ソフトウェアをさまざまなカテゴリのユーザー（初心者、非技術者、専門家）が使用できるかどうかを決定します。

• Portability −移植性は、ソフトウェアがさまざまなハードウェアデバイスを備えたさまざまなプラットフォームで動作できるかどうかを決定します。

• Maintainability −保守性は、エラーの修正とモジュールの更新の容易さを決定します。

• Reusability −再利用性は、モジュールとクラスを他のソフトウェア製品の開発に再利用できるかどうかを決定します。

オブジェクト指向メトリクス

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

プロジェクトメトリクス

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

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

製品メトリクス

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

• Methods per Class−クラスの複雑さを決定します。クラスのすべてのメソッドが等しく複雑であると想定される場合、より多くのメソッドを持つクラスはより複雑になり、エラーの影響を受けやすくなります。

• Inheritance Structure−いくつかの小さな継承ラティスを持つシステムは、単一の大きな継承ラティスを持つシステムよりも適切に構造化されています。経験則として、継承ツリーのレベル数は7（±2）を超えてはならず、ツリーのバランスが取れている必要があります。

• Coupling and Cohesion −結合度が低く、凝集度が高いモジュールは、再利用性と保守性が向上するため、より適切に設計されていると見なされます。

• Response for a Class −クラスのインスタンスによって呼び出されるメソッドの効率を測定します。

プロセスメトリクス

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

• KLOC（Kilo Lines of Code）の数
• 欠陥除去効率
• テスト中に検出された障害の平均数
• KLOCあたりの潜在的な欠陥の数