【ソフトウェアエンジニアリング総復習】第9章 オブジェクト指向方法論 (20%~25%)

1. オブジェクト指向の定義

オブジェクト指向とは、物事を一つ一つのオブジェクトに分解し、オブジェクト間で分割・連携することを指しますが、問題をステップではなくオブジェクトの機能ごとに分割するのがオブジェクト指向です。オブジェクト指向プログラム開発の考え方では、各オブジェクトは明確な役割分担を持つ機能中心となります。

2. オブジェクト指向方法論の定義

オブジェクト指向の方法論は、データまたは情報を主軸として、データと処理を組み合わせる方法です。つまり、オブジェクトを、データとこれらのデータに適用できる操作で構成されるまとまりとして扱います。

オブジェクト指向のアプローチは、次の方程式で要約できます。

OO = object（对象）+classes（类）+inheritance（继承）+communication with messages

3. オブジェクト指向手法の要点

物体

1. オブジェクト指向ソフトウェア システムはオブジェクトで構成され、ソフトウェア内の要素はすべてオブジェクトであり、複雑なソフトウェア オブジェクトは比較的単純なオブジェクトで構成されます。
2. 従来の機能分解の手法はオブジェクト分解に置き換えられ、オブジェクトは客観世界の実体から抽象化され、固定されなくなります。

親切

1. すべてのオブジェクトをさまざまなオブジェクト クラスに分割し、各オブジェクト クラスでデータのセットとメソッドのセットを定義します。
2. データは、オブジェクトの静的プロパティ、つまりオブジェクトの状態情報を表すために使用されます。
3. クラスに定義されたメソッドは、クラスのオブジェクトに適用できる操作であり、クラスのすべてのオブジェクトで共有され、オブジェクトごとに操作のコードをコピーする必要はありません。

継承

サブクラスと親クラスの関係に従って、いくつかのオブジェクト クラスが階層システムを形成します。サブクラスは自動的に上位レベルの親クラスと同じデータとメソッドを持ち、下位レベルの機能は同じ名前の上位レベルの機能をシールドします。

1. C++ では、サブクラスは親クラスを継承でき、継承にはパブリック、プライベート、プロテクトの 3 つの方法があります。
2. サブクラスのメンバーは、同じ名前を持つ親クラスのメンバーをシールドします。この場合、これを非表示または再定義と呼びます。

カプセル化

1. オブジェクトは、メッセージを渡すことによってのみ相互に通信できます。
2. オブジェクトは処理の対象であり、何らかの操作の実行とそのプライベート データの処理を要求するメッセージを送信する必要がありますが、外部からそのプライベート データを直接操作することはできません。
3. オブジェクトにローカルなすべてのプライベート情報は、不透明なブラック ボックスに含まれているのと同じように、オブジェクト クラスの定義にカプセル化され、外界からは見えず、直接使用することはできません。

① 客観世界はさまざまな物体から構成されており、すべては物体であり、複雑な物体はある方法でより単純な物体から構成できると考える。オブジェクト指向アプローチは、従来のアプローチの機能分解をオブジェクト分解に置き換えます。
② すべてのオブジェクトをさまざまなオブジェクト クラスに分割し、各クラスはデータのセットとメソッドのセットを定義します。
③サブクラス（ソースクラスとも呼ばれる）と親クラス（基底クラスとも呼ばれる）の関係に従って、いくつかのオブジェクトクラスが階層構造（クラス階層とも呼ばれる）を形成します。
④ オブジェクトはメッセージを渡すことによってのみ相互に通信できます。

4. オブジェクト指向手法の利点

1. 人間の習慣的な考え方と一致している

1.1 オブジェクト指向ソフトウェア技術はオブジェクトを核とし、この技術で開発されるソフトウェアシステムはオブジェクトから構成されます。
1.2. オブジェクトは、内部状態を記述し、静的プロパティを表すデータと、これらのデータに適用できる操作 (オブジェクトの動的動作) をカプセル化することによって形成される統一体です。
1.3. オブジェクト指向設計手法の基本原理は、現実世界の概念を使用して問題を抽象的に考え、問題を自然に解決することです。
1.4 オブジェクト指向方法論の基本原理は、人間の習慣の思考方法に従って問題領域のモデルを確立し、解決方法をできるだけ直観的かつ自然に表現するソフトウェアシステムを開発することです。
1.5 オブジェクト指向ソフトウェア システムで使用されるオブジェクトは、オブジェクト世界のエンティティを抽象化したものです。

2. 良い安定性

2.1 オブジェクト指向ソフトウェア システムの構造は、システムの機能分解ではなく、問題領域のモデルに基づいて確立されるため、システムの機能要件が変更されても、全体的な変更は生じません。ソフトウェア構造の一部のローカルな変更のみが必要な場合がよくあります。
2.2 現実世界の実体は比較的安定しているため、オブジェクトを中心として構築されるソフトウェアシステムも比較的安定しています。

3. 再利用性が良い

3.1 オブジェクト固有のカプセル化と情報隠蔽機構により、オブジェクトの内部実装は外界から隔離され、強い独立性を持ちます。
3.2 オブジェクトは、理想的なモジュールおよび再利用可能なソフトウェア コンポーネントです。
3.3 オブジェクト指向ソフトウェア テクノロジは、再利用可能なソフトウェア コンポーネントを使用して新しいソフトウェア システムを構築する際に優れた柔軟性を備えています。
3.4 オブジェクト クラスを再利用するには 2 つの方法があります: 1 つはクラスのインスタンスを作成して直接使用する方法、もう 1 つは現在のニーズを満たす新しいクラスをそこから派生する方法です。

4. 大規模なソフトウェア製品の開発が容易になる

オブジェクト指向手法でソフトウェアを開発する場合、ソフトウェア システムを構築する各オブジェクトは、独自のデータ、動作、機能、用途を持つマイクロ プログラムのようなものであるため、大規模なソフトウェア製品は一連のオブジェクトに分解できます。小規模で本質的に独立している 開発の技術的な困難が軽減されるだけでなく、開発作業の管理も容易になります。

5. メンテナンス性が良い

オブジェクト指向ソフトウェアはより安定しています。オブジェクト指向ソフトウェアは理解しやすいです。テストとデバッグが簡単です。

5. オブジェクト指向分析

オブジェクト指向分析では、主にオブジェクトモデル、動的モデル、関数モデルで構成されます。オブジェクト モデルは、最も基本的であり、最も重要であり、中核となります。

オブジェクト指向分析プロセス	オブジェクト指向設計プロセス	現在の段階です
実装から完全に独立したアプリケーション ドメイン モデルを構築します。	ソリューション ドメインの構造をモデルに徐々に追加します。	アプリケーションドメインとソリューションドメインの構造をプログラムコードにコンパイルし、厳密なテスト検証を実施

5.1 オブジェクトモデル

システム データ構造クラス
間のいくつかの関係を説明します: 一般化、実装、関連付け (一般的な関連付け、集約、組み合わせ、および依存関係にも分かれます)

5.1.1 クラス図の作成方法

5.1.1.1 クラス図の概念

1. クラス、インターフェース、静的構造とそれらの間の関係を示します。
2. システムの構造設計を記述するために使用されます。

5.1.1.2 クラス図の要素

1. クラス図には、注釈と制約を含めることもできます。
2. クラス図には、要素をグループ化するために使用されるパッケージとサブシステムを含めることもできます。
3. クラスのインスタンスをクラス図に配置できる場合があります。

5.1.1.3 クラス

クラスは、同じ属性、操作、関係、セマンティクスを持つオブジェクトのグループを抽象化したもので、名前部分、属性部分、操作部分を含むオブジェクト指向システムの組織構造の中核です。 。

名前	学生
属性	+ 名前: 文字列
操作する	+学ぶ()

クラス属性の構文

[可視性] 属性名[:タイプ] [=初期値] [{属性文字列}]
可視性: public (パブリック) "+"、private (プライベート) "-"、protected (保護) "#"

クラス操作の構文は次のとおりです。

[可視性] オペレーション名 [(:パラメータリスト)] [:戻り値の型] [{プロパティ文字列}]
可視性

パブリック(Public)「+」、プライベート(Private)「-」、プロテクト(Protected)「#」、パッケージパブリック(Package)「~」

パラメータテーブル

意味

名前: タイプ

複数のパラメータがある場合は、各パラメータをカンマで区切ります。
パラメータにはデフォルト値を指定できます。

属性文字列

操作の定義に事前定義された要素に加えて、いくつかの情報を追加します。

5.1.1.4 インターフェース

クラスは 1 つ以上のインターフェイスを実装できます

クラス図との主な違いは、上部に <> 表示があることです。

《インターフェース》人
+食べる()

中空の円で表すこともできます。

5.1.1.5 コラボレーション

コラボレーションとは、一部のクラス、インターフェイス、およびその他の要素が連携して何らかの協力的な動作を提供することを意味します。これは、単に要素を追加することで得られるものではありません。

5.1.1.6 関係

5.1.2 クラス関係

5.1.2.1 一般化関係

セマンティクス

クラスとサブクラスの関係、インターフェイスとサブインターフェイスの関係、
クラス (サブクラス、サブインターフェイスと呼ばれます) は別のクラス (親クラス、親インターフェイスと呼ばれます) の機能を継承し、独自の新しい機能を追加できます。

文法

伸びる

シンボル

サブクラスから親クラス、またはサブインターフェイスから親インターフェイスを指す中空の三角形の矢印を持つ実装。

5.1.2.2 リレーションシップの実装

セマンティクス

クラスとインターフェイスの関係。
クラスは複数のインターフェイスを実装し、すべてのインターフェイスの機能を実現できます。
仕様と実装の分離の原則を具体化します。

文法

実装する

シンボル

実装は、クラスから実装されたインターフェイスを指す中空の三角形の矢印が付いた破線で表されます。

5.1.2.3 依存関係

セマンティクス

あるクラス A は別のクラス B を使用しますが、この関係は偶然で一時的で非常に弱いものですが、クラス B の変更はクラス A に影響します。

文法

クラス B はクラス A のメソッドのパラメータ (またはローカル変数) として存在します。

シンボル

実装は、クラスから実装されたインターフェイスを指す中空の三角形の矢印が付いた破線で表されます。

5.1.2.4 関係

セマンティクス

依存関係より強い、必然的、長期的、強力;
一方向の関連付け (クラスに生徒を追加するだけ)、双方向の関連付け (生徒にクラスの属性を追加) に
分かれる 1 対 1 (生徒と生徒) ID カード）、1 対多（クラスと学生）、多対多の関連付け（学生とコース）には 2 つのクラス
の関連付け（顧客と注文、注文と商品）、および 1 つのクラスとそれ自体（リーダーも従業員）

文法

クラス B はクラス A 内でメンバー変数として形成されます。

シンボル

これは、クラス A からクラス B を指す矢印が付いた点線で表されます。
双方向の関連付けにより 2 つの矢印をキャンセルできます。

5.1.2.5 集約関係

セマンティクス

関連関係の特殊なケース、
全体と部分の関係、
全体は分離可能、全体のライフサイクルと部分のライフサイクルは異なる、
has-aの関係、コンピュータとCPUの関係、会社と従業員の関係、クラスと学生の関係。

文法

同じ関係。

シンボル

中空のひし形と実線の矢印。

5.1.2.6 構成関係

セマンティクス

関連関係の特殊なケース。
全体と部分の関係、部分全体は分離できず、集合体より強い。contains
-a の関係。
全体のライフ サイクルは部分のライフ サイクルと同じ。
間の関係。人や手足。

文法

同じ関係。

シンボル

実線のひし形と実線の矢印。

複雑な問題 (大規模システム) のオブジェクト モデルは、通常、サブジェクト層、クラスとオブジェクト層、構造層、属性層、サービス層の 5 つの下位層で構成されます。

5.2 動的モデル

システム制御構造の説明

5.2.1 動的モデルの概念

動的モデルは、瞬間的および動作的なシステム制御プロパティを表し、オブジェクト モデル内のオブジェクトの法的変更シーケンスを規定します。

5.2.2 動的モデルのモデリング

UML によって提供される状態図を使用して、オブジェクトの状態、状態遷移をトリガーするイベント、およびオブジェクトの動作を記述します。各クラスの動的動作は状態図によって記述され、各クラスの状態図はイベントを共有することによって結合されて、システムの動的モデルを形成します。つまり、動的モデルは、状態図のグループのコレクションです。イベント共有に基づいて相互に関連付けられます。

5.2.2.1 シーケンス図/タイミング図

4つの要素

オブジェクト オブジェクト
ライフライン ライフライン
メッセージ メッセージの
アクティブ化 アクティブ化

5.2.2.2 コラボレーション図

1. オブジェクト間の組織的なコラボレーション関係を説明します。これは、システムのユースケースの動作も反映することができます。
2. コラボレーション図は、アクター、オブジェクト、接続、メッセージなどの基本要素で構成されます。

5.2.2.3 状態図

1. 状態図は主に、オブジェクトが存在する間の動的な動作を記述し、オブジェクトが経験する状態シーケンス、状態遷移を引き起こすイベント、および状態遷移に伴う付随アクションを表すために使用されます。
2. 一般に、ステート マシンを使用してオブジェクトのライフ サイクルをモデル化できます。
3. 状態図は、状態間の制御フローの記述に重点を置いて、状態マシンを表示するために使用されます。

5.2.2.3.1 状態図とアクティビティ図の比較

説明の焦点が違う

1. 状態図は、オブジェクトの状態と状態間の遷移を記述します。
2. アクティビティ図は、アクティビティからアクティビティへの制御の流れを記述します。

さまざまな機会

1. ライフサイクル中のオブジェクトの動作を示す場合は、状態図を使用する方が良いでしょう。
2. ユースケースの分析、複数のユースケースに関わるワークフローの理解、マルチスレッドアプリケーションの使用などが目的の場合は、アクティビティ図を使用することをお勧めします。

5.3 機能モデル

システム機能の説明

5.3.1 機能モデルの概念

5.3.1.1 機能モデルの定義

機能モデルは、変化するシステムの機能特性を表し、システムが何をすべきかを指定するため、ターゲット システムに対するユーザーのニーズをより直接的に反映します。

5.3.1.2 機能モデルの構成

機能モデルは一連のデータ フロー図で構成されます

5.3.2 ユースケース図 (強調)

UML によって提供されるユースケース図は、要件分析と機能モデルの構築のための強力なツールでもあります。UMLでは、ユースケース図を用いて構築されたシステムモデルをユースケースモデルと呼びます。

5.3.2.1 ユースケース図の定義

ユースケース モデルは、外部アクターが理解するシステムの機能を記述します。ユースケースモデルの確立は、システム開発者とユーザーの間で議論を重ねた結果であり、要件仕様に関して開発者とユーザーが合意に達したことを記述したものです。

5.3.2.2 ユースケース図の表現

5.3.2.2.1 システム

意味

システムはユース ケースを提供するブラック ボックスとみなされ、システムが内部でどのように動作するか、ユース ケースがどのように実装されるかは、ユース ケース図モデルの構築には重要ではありません。

特急

システムはボックスで表され、その境界線はシステムの境界を表します。これは、システムの機能範囲を示し、システムの機能を定義するために使用されます。システムの機能を記述するユースケースはボックスの内側に配置され、外部エンティティを表すアクターはボックスの外側に配置されます。

5.3.2.2.2 使用例

意味

ユースケースはアクター (参加者) によって認識され、システムの完全な機能です。システムによって完了する一連のアクションとして UML でユースケースを定義する

特急

UML では、楕円はユースケースを表します。ユース ケースは、ユース ケースがどのアクター (参加者) と対話するかを示す関連付けを通じてアクター (参加者) に接続され、この対話は双方向です。

特徴

1. ユースケースは、特定のユーザーの目標を達成する、ユーザーに表示される機能を表します。
2. ユースケースは常にアクター (actor) によって開始され、アクター (actor) に識別可能な値を提供します。
3. ユースケースが完了している必要がある

知らせ

ユースケースは、機能を使用する特定のインスタンスではなく、機能のクラスを表すクラスです。ユースケースの一例は、システムの実際の利用方法であり、通常、ユースケースはスクリプトと呼ばれる。スクリプトはシステムの特定の実行プロセスです。

5.3.2.2.3 アクター（参加者）

意味

アクター (参加者) は、システムと対話する人または他のシステムであり、外部エンティティを表します。ユースケースを使用し、システムと対話する人または何かは、アクター (参加者) です。アクター (参加者) は、特定の人や物ではなく、役割を表します。

特急

UML では、ラインマンはアクターを表します。ユースケース図では、アクター（参加者）とユースケースが直線で結ばれており、両者の間で情報がやり取りされることを意味しており、これを通信リンクと呼びます。アクターはユースケースをトリガーし、ユースケースと情報を交換します。1 つのアクターを複数のユース ケースに関連付けたり、1 つのユース ケースを複数のアクターに関連付けたりできます。

5.3.2.2.4 ユースケースの関係

拡張された関係

あるユース ケースにいくつかのアクションを追加すると、別のユース ケースが構成されます。これら 2 つのユース ケース間の関係は拡張関係です。後者は前者の動作の一部を継承し、後者は通常、拡張ユース ケースと呼ばれます。

使用関係 (関係を含む)

あるユースケースが別のユースケースを使用する場合、2つのユースケースの間に使用関係（包含関係）が形成されます。

5.3.2.2.4.1 ユースケースの関係における類似点と相違点

1. どちらも、いくつかのユース ケースから共通の動作を抽出し、それらを 1 つのユース ケースにまとめ、他のユース ケースで使用 (包含) または拡張されます。
2. 使用（収容）する目的と拡張する目的は異なります。拡張関係は、一般的な動作の変化を説明するときに使用されます。
3. 複数のユースケースで重複した記述があり、その重複を避けたい場合は、使用関係（包含関係）を利用します。

5.3.2.2.5 例

例1 学生管理システムの登録

事例2 ネットワーク授業システム（ラーニングパスの利用と同様）

例 3 本を借りる

このシステムの借り手は学生と教師であり、このシステムは借り手に本の照会、本の貸し出し、本の返却のサービスを提供する。学生は5冊まで、教師は20冊まで借りることができます。本の貸し出し・返却時には、まず「借り手の本人確認」が必要です。本を返却する際、延滞した場合は罰金を支払います。先生が借りたい本がすでに借りられている場合、先生は図書予約サービスを通じて本を予約することもでき、予約後、先に本を借りることができます。

例 4 鉄道チケット注文システム

乗車券予約システムでは、乗車券の購入、退会、乗車券の残数確認、時刻表の確認の4つの操作が可能です。チケットを購入する場合でも、チケットの購読を解除する場合でも、ユーザーはまずシステムにログインする必要があります。列車時刻の検索には主に駅による検索と列車番号による検索の2通りがあります。システムへのログイン中にパスワードを忘れた場合は、パスワードを再取得する機能も利用できます。

例5 商品の購入

システムには登録機能があり、顧客は登録後ログインするだけでシステム上で商品を購入することができ、システムを通じて
商品を閲覧し、商品の詳細情報を閲覧し、気に入った商品を購入することができ、
顧客はさまざまな方法で支払いを行うことができ、銀行のオンライン決済機能 送金による支払いも可能
商品プロモーション機能を備えており、システムが指定した一部の商品、またはユーザーの商品購入額が一定額を超えた場合に、チェックアウト時に割引が受けられる、顧客がログイン後、
メッセージ機能を使用して商品やサービスについてコメントできる、
システム管理者がメッセージ機能を使用して顧客からの質問に回答し、登録ユーザーを管理できる、
エントリースタッフが更新できる新しい製品の追加や既存の製品の更新を含む製品情報 情報の更新。
システムにより、複数の人が同時にオンラインで製品を閲覧および購入できます。

例6 オンラインコース選択

学生情報管理システムの「オンライン履修選択モジュール」では、学生は「履修情報の閲覧」「履修選択」「選択履修削除」の3つの操作を行うことができます。「コース情報を見る」には主に「コース番号で見る」と「コース名で見る」の2つの方法があります。
管理者は「コース情報のメンテナンス」操作を行うことができます。
学生と管理者のすべての操作は、完了する前に「システムにログイン」する必要があります。「ログインシステム」プロセス中にパスワードを忘れた場合は、「パスワード再取得」機能も使用できます。

例 7 チェスおよびカード ホール管理システム

チェス＆カードホール管理システムでは、顧客はネットワークを介して座席を予約する操作を通じて座席情報を確認する必要があります。空きシートまたは満席のシートがない場合は、「プロセス待機キュー」を選択します。
顧客がチェス＆カードホールに到着すると、フロントのウェイターが座席を手配し、座席情報を確認する必要があります。
顧客がチェス アンド カード ホールから出たい場合は、フロントデスクの店員がチェックアウトを処理する必要があります。これは銀聯 POS システムを介した現金チェックアウトと銀行カード チェックアウトをサポートしています。

6. 3モデルの比較

1. クラスインスタンスのライフサイクルまたはランタイムを記述するクラスごとに確立された動的モデル
2. 状態遷移は、データ フロー図のプロセスおよびユース ケース図のユース ケースにマッピングされる動作を駆動します。これらは、クラス図のサービスにも対応します。
3. 機能モデルの処理は、オブジェクト モデルのクラスによって提供されるサービスに対応する必要があります。
4. データフロー図内のデータ ストア、およびデータのソース/宛先ポイントは、通常、オブジェクト モデル内のオブジェクトです。
5. データ フロー図のデータ フローは、多くの場合、オブジェクト モデル内のオブジェクトの属性値であるか、オブジェクト全体である場合があります。
6. ユースケース図内のアクター、場合によってはオブジェクト モデル内のオブジェクト
7. 機能モデルでの処理により、動的モデルでイベントが生成される場合があります
8. オブジェクト モデルは、データ フロー、データ ストレージ、データ ソース/宛先構造をデータ フロー図で記述します。

オブジェクト指向でソフトウェアを開発する方法では、通常、次の 3 種類のモデルを確立する必要があります。
オブジェクト モデル ---- システムのデータ構造を記述します。
動的モデル ---- システムの制御構造を記述します。
機能モデル----システム機能の説明。
これら 3 つのモデルにはすべて、データ、制御、操作などの概念が含まれていますが、モデルごとに重点が異なります。
一般的なソフトウェア システムは、データ構造を使用し (オブジェクト モデル)、操作を実行し (動的モデル)、データ値の変更を実行する (機能モデル) ときに、これら 3 つの側面を組み合わせます。