オブジェクト指向分析と設計

オブジェクト指向分析および設計( OOAD ) は、オブジェクト指向プログラミングを適用し、ソフトウェア開発プロセス全体でビジュアル モデリングを使用して関係者のコミュニケーションと製品の品質をガイドすることで、アプリケーション、システム、またはビジネスを分析および設計するための技術的なアプローチです。

現代のソフトウェア エンジニアリングにおける OOAD は、通常、反復的かつ増分的な方法で実行されます。OOAD アクティビティの出力は、それぞれ分析モデル (OOA の場合) と設計モデル (OOD の場合) です。リスクやビジネス価値などの主要要因に基づいて、これらを継続的に改良し、進化させることが目的です。

1990 年代半ば以前のオブジェクト指向テクノロジの初期には、ソフトウェア開発とオブジェクト指向モデリングにはさまざまな競合する方法論があり、多くの場合、特定のコンピュータ支援ソフトウェア エンジニアリング(CASE) ツール ベンダーに結び付けられていました。当時の主な懸念事項は、標準的な表記法、一貫した用語、プロセス ガイドが存在せず、コミュニケーションの効率が低下し、学習曲線が長くなっていました。

よく知られている初期のオブジェクト指向方法論のいくつかは、Grady Booch、James Rumbaugh、Ivar Jacobson ( Three Amigos )、Robert Martin、Peter Coad、Sally Shlaer、Stephen Mellor、Rebecca Wirfs-Brockなどの第一人者からインスピレーションを受けて生まれました。

1994年、ラショナルソフトウェアの3人の仲間が協力して、統一モデリング言語（UML）の開発を開始しました。その後、フィリップ・クルヒテンとウォーカー・ロイス（ウィンストン・ロイスの長男）とともに、彼らは独自の方法論であるOMT、OOSE、ブーチ法を、他の業界リーダーのさまざまな洞察と経験と統合し、ソフトウェア開発とプロジェクト管理の業界のベストプラクティスを学習するための包括的な反復的かつ増分的なプロセスガイドおよびフレームワークであるラショナル統一プロセス（RUP）に統合するというミッションを成功させました。 ^[1]それ以来、統一プロセスファミリーは、オブジェクト指向分析と設計のためのおそらく最も人気のある方法論および参照モデルになりました。

オブジェクトには、エンティティを表すためにグループ化されたカプセル化されたデータとプロシージャが含まれます。「オブジェクト インターフェイス」は、オブジェクトと対話する方法を定義します。オブジェクト指向プログラムは、これらのオブジェクトの対話によって記述されます。オブジェクト指向設計は、オブジェクト指向分析中に特定され、文書化された問題を解決するために、 オブジェクトとその対話を定義する規律です。

以下は、オブジェクト指向設計のクラスベースのサブセットの説明です。これには、オブジェクトが通常、クラスをインスタンス化するのではなく、他の (プロトタイプ) オブジェクトを複製することによって取得されるオブジェクト プロトタイプ ベースのアプローチは含まれません。オブジェクト指向設計は、オブジェクト指向分解のプロセスと、設計中のシステムの論理モデルと物理モデル、および状態モデルと動的モデルの両方を表す表記法を含む設計方法です。

ソフトウェアライフ サイクルは、通常、問題の抽象的な説明から始まり、設計、コードとテスト、そして最後に展開へと段階的に分割されます。このプロセスの最初の段階は分析と設計です。分析フェーズは、「要件取得」とも呼ばれます。

ソフトウェア開発へのいくつかのアプローチ (総称してウォーターフォール モデル) では、各ステージ間の境界は、かなり厳格で連続的であることが意図されています。「ウォーターフォール」という用語は、このような方法論に対して造語され、進行が一方向にのみ連続的に進むこと、つまり、分析が完了したらそのときにのみ設計が開始され、設計上の問題によって分析モデルの変更が必要になったり、コーディング上の問題によって設計の変更が必要になったりすることはまれ (エラーの原因と見なされる) であることを意味します。

ウォーターフォール モデルに代わるものとして、反復モデルがあります。この区別は、反復ソフトウェア開発のためのスパイラル モデルに関する非常に影響力のある論文でBarry Boehmによって普及されました。反復モデルでは、モデルのさまざまな段階で作業を並行して行うことができます。そのため、たとえば、分析、設計、さらにはコードまですべて同じ日に作業し、ある段階の問題が別の段階の問題に影響を与える可能性があります (これはエラーの原因とは見なされません)。反復モデルが重視されるのは、ソフトウェア開発が知識集約型のプロセスであり、設計の問題を理解しなければ分析などを完全に理解することはできないこと、コーディングの問題が設計に影響を与える可能性があること、テストによってコードや設計をどのように変更すべきかに関する情報が得られることなどです。^[2]

ウォーターフォール モデルを使用してオブジェクト指向開発を行うことは可能ですが、実際にはほとんどのオブジェクト指向システムは反復的なアプローチで開発されます。その結果、オブジェクト指向プロセスでは「分析と設計」が同時に考慮されることがよくあります。

オブジェクト指向パラダイムは、モジュール性と再利用性を重視します。オブジェクト指向アプローチの目標は、「オープン - クローズド原則」を満たすことです。モジュールがオープンであるのは、拡張をサポートしている場合、またはモジュールが新しい動作を追加したり新しい状態を記述するための標準化された方法を提供している場合です。オブジェクト指向パラダイムでは、これは多くの場合、既存のクラスの新しいサブクラスを作成することで実現されます。モジュールがクローズであるのは、他のすべてのモジュールが使用する必要がある、明確に定義された安定したインターフェイスがあり、あるモジュールの変更によって別のモジュールに導入される可能性のある相互作用と潜在的なエラーが制限されている場合です。オブジェクト指向パラダイムでは、これはオブジェクトでサービスを呼び出すメソッドを定義することで実現されます。メソッドはパブリックまたはプライベートのいずれかにすることができます。つまり、オブジェクトに固有の特定の動作は他のオブジェクトに公開されません。これにより、コンピュータプログラミングでよく発生する多くのエラーの原因が軽減されます。^[3]

ソフトウェア ライフサイクルは、通常、問題の抽象的な説明から設計、コードとテスト、そして最終的に展開へと段階的に分割されます。このプロセスの最初の段階は分析と設計です。分析と設計の区別は、多くの場合、「何をするか」と「どのようにするか」で説明されます。分析では、開発者はユーザーやドメイン エキスパートと協力して、システムが何をすべきかを定義します。実装の詳細は、この段階ではほとんどまたは完全に (特定の方法によって異なりますが) 無視されます。分析段階の目標は、適切なテクノロジなどの制約に関係なく、システムの機能モデルを作成することです。オブジェクト指向分析では、これは通常、ユース ケースと最も重要なオブジェクトの抽象的な定義によって行われます。その後の設計段階では、分析モデルを改良し、必要なテクノロジやその他の実装の選択を行います。オブジェクト指向設計では、さまざまなオブジェクト、そのデータ、動作、および相互作用を記述することに重点が置かれます。設計モデルには、プログラマがコードで設計を実装できるように、必要なすべての詳細が含まれている必要があります。^[4]

ソフトウェア ライフサイクルにおけるあらゆる分析アクティビティの目的は、実装の制約に依存しないシステムの機能要件のモデルを作成することです。

オブジェクト指向分析と他の形式の分析の主な違いは、オブジェクト指向アプローチでは、オブジェクトを中心に要件を整理し、システムが対話する現実世界のオブジェクトをモデルにした動作 (プロセス) と状態 (データ) の両方を統合することです。他の分析方法や従来の分析方法では、プロセスとデータという 2 つの側面が別々に考慮されます。たとえば、データはER 図でモデル化され、動作はフローチャートまたは構造図でモデル化されます。

OOAでよく使われるモデルはユースケースとオブジェクトモデルです。ユースケースはシステムが実行しなければならない標準的なドメイン機能のシナリオを記述します。オブジェクトモデルは主要オブジェクトの名前、クラス関係（例えば、CircleはShapeのサブクラス）、操作、プロパティを記述します。理解を助けるためにユーザーインターフェイスのモックアップやプロトタイプを作成することもできます。^[5]

オブジェクト指向設計 (OOD) は、ソフトウェアの問題を解決するために相互作用するオブジェクトのシステムを計画するプロセスです。これはソフトウェア設計の手法です。クラスとその子 (インスタンス化されたオブジェクト) の機能を定義することで、各オブジェクトは、その状態を持つクラスの同じ実装を実行できます。

OOD では、開発者はオブジェクト指向分析で作成された概念モデルに実装制約を適用します。このような制約には、ハードウェアおよびソフトウェアプラットフォーム、パフォーマンス要件、永続的なストレージとトランザクション、システムの使いやすさ、予算と時間による制限などが含まれます。技術に依存しない分析モデルの概念は、実装クラスとインターフェイスにマッピングされ、ソリューション ドメインのモデル、つまり、具体的な技術に基づいてシステムを構築する方法の詳細な説明が作成されます。 ^[6]

OOD 中の重要なトピックには、オブジェクト指向設計原則に 基づいたアーキテクチャ パターンと設計パターンを適用したソフトウェア アーキテクチャの設計も含まれます。

オブジェクト指向設計の入力は、オブジェクト指向分析の出力によって提供されます。出力成果物は、オブジェクト指向設計の入力として使用するために完全に開発される必要はないことを認識してください。分析と設計は並行して行われる可能性があり、実際には、1 つのアクティビティの結果は、反復プロセスを通じて短いフィードバック サイクルで他のアクティビティにフィードできます。分析と設計はどちらも段階的に実行でき、成果物は一度に完全に開発されるのではなく、継続的に成長させることができます。

オブジェクト指向設計の一般的な入力成果物は次のとおりです。

• 概念モデル: オブジェクト指向分析の結果であり、問​​題領域の概念を捉えます。概念モデルは、同時実行性やデータ ストレージなどの実装の詳細から独立するように明示的に選択されます。
• ユースケース: 一連のイベントをまとめて記述したもので、システムが何か役に立つことを行うきっかけとなります。各ユースケースは、特定のビジネス目標または機能を達成するために、システムがアクターと呼ばれるユーザーとどのように対話すべきかを伝える 1 つ以上のシナリオを提供します。ユースケースのアクターは、エンド ユーザーまたは他のシステムです。多くの場合、ユースケースはユースケース図にさらに詳しく記述されます。ユースケース図は、アクター (ユーザーまたは他のシステム) と、それらが実行するプロセスを識別するために使用されます。
• システム シーケンス図: システム シーケンス図 (SSD) は、ユース ケースの特定のシナリオについて、外部アクターが生成するイベント、その順序、および考えられるシステム間イベントを示す図です。
• ユーザー インターフェイスドキュメント (該当する場合): 最終製品のユーザー インターフェイスの外観と操作性を示して説明するドキュメント。これは必須ではありませんが、最終製品を視覚化するのに役立ち、デザイナーの役に立ちます。
• リレーショナル データ モデル(該当する場合): データ モデルは、データの表現方法と使用方法を記述する抽象モデルです。オブジェクト データベースを使用しない場合、オブジェクト リレーショナル マッピングに選択された戦略はOO 設計プロセスの出力であるため、通常は設計の前にリレーショナル データ モデルを作成する必要があります。ただし、リレーショナル データ モデルとオブジェクト指向設計成果物を並行して開発することは可能であり、成果物の成長によって他の成果物の改良が促進される可能性があります。

オブジェクト指向設計の 5 つの基本概念は、プログラミング言語に組み込まれた実装レベルの機能です。これらの機能は、次のような一般的な名前で呼ばれることがよくあります。

• オブジェクト/クラス: データ構造と、データに作用するメソッドまたは関数との密接な結合または関連付け。これはクラスまたはオブジェクトと呼ばれます(オブジェクトはクラスに基づいて作成されます)。各オブジェクトは個別の機能を果たします。オブジェクトは、そのプロパティ、オブジェクトの内容、および実行可能な機能によって定義されます。オブジェクトは、類似したオブジェクトのセットであるクラスの一部になることができます。
• 情報の隠蔽: 一部のオブジェクト コンポーネントを外部エンティティから保護する機能。これは、変数を所有クラスに対してプライベートまたは保護として宣言できるようにする言語キーワードによって実現されます。
• 継承:クラスが別のクラスの機能を拡張またはオーバーライドする機能。いわゆるサブクラスには、スーパークラスから派生 (継承) されたセクション全体があり、独自の関数とデータのセットがあります。
• インターフェース (オブジェクト指向プログラミング) :メソッドの実装を延期する機能。関数またはメソッドのシグネチャを実装せずに定義する機能。
• ポリモーフィズム（具体的には、サブタイピング）：オブジェクトをそのサブオブジェクトに置き換える機能。オブジェクト変数が、そのオブジェクトだけでなく、そのサブオブジェクトもすべて格納できる機能。

• オブジェクトの定義、概念図からクラス図の作成: 通常はエンティティをクラスにマップします。
• 属性とそのモデルを識別します。
• デザインパターンを使用する（該当する場合）：デザインパターンは完成したデザインではなく、あるコンテキストにおける一般的な問題に対する解決策の説明です。^[7]

デザイン パターンを使用する主な利点は、複数のアプリケーションで再利用できることです。また、さまざまな状況やアプリケーションで使用できる、問題解決方法のテンプレートと考えることもできます。オブジェクト指向のデザイン パターンは通常、クラスまたはオブジェクト間の関係と相互作用を示しますが、関係する最終的なアプリケーション クラスまたはオブジェクトは指定しません。

• アプリケーション フレームワークを定義する(該当する場合): アプリケーション フレームワークは通常、特定のオペレーティング システム用のアプリケーションの標準構造を実装するために使用されるライブラリまたはクラスのセットです。大量の再利用可能なコードをフレームワークにバンドルすると、開発される新しいアプリケーションごとに大量の標準コードを書き直す作業が省かれるため、開発者の時間が大幅に節約されます。
• 永続的なオブジェクト/データを識別する (該当する場合): アプリケーションの単一実行時間よりも長く存続する必要があるオブジェクトを識別します。リレーショナル データベースを使用する場合は、オブジェクト関係マッピングを設計します。
• リモート オブジェクト (該当する場合) とそのバリエーションを識別して定義します。

• シーケンス図-システム シーケンス図を拡張して、システム イベントを処理する特定のオブジェクトを追加します。

シーケンス図では、同時に実行されるさまざまなプロセスまたはオブジェクトが平行な垂直線で表示され、それらの間で交換されるメッセージが発生順に水平矢印で示されます。

• クラス図- クラス図は、システムのクラス、その属性、およびクラス間の関係を表示してシステムの構造を説明する静的構造UML図の一種です。シーケンス図の開発を通じて識別されたメッセージとクラスは、システムのグローバル クラス図の自動生成への入力として使用できます。

• 依存性注入: 基本的な考え方は、オブジェクトが他のオブジェクトのインスタンスに依存している場合、必要なオブジェクトが依存オブジェクトに「注入」されるというものです。たとえば、データベース接続を内部的に作成するのではなく、コンストラクターに引数として渡します。
• 非循環依存関係の原則: パッケージまたはコンポーネントの依存関係グラフ(粒度は開発者1人の作業範囲によって異なります)には循環があってはなりません。これは有向非循環グラフを持つとも呼ばれます。^[8]たとえば、パッケージCはパッケージBに依存し、パッケージBはパッケージAに依存しています。パッケージAがパッケージCに依存している場合は、循環が発生します。
• 複合再利用原則：継承よりもオブジェクトの多態的 合成を優先する。^[7]

オブジェクト指向モデリング (OOM) は、開発ライフサイクル全体を通じてオブジェクト指向パラダイムを使用して、アプリケーション、システム、およびビジネス ドメインをモデリングする一般的なアプローチです。OOM は、現代のソフトウェア エンジニアリングにおける OOD と OOA の両方のアクティビティで頻繁に使用される主要な手法です。

オブジェクト指向モデリングは、通常、ビジネスプロセスやユースケースなどの動的動作のモデリングと、クラスやコンポーネントなどの静的構造のモデリングという2つの側面に分かれます。OOAとOODは、OOM中の2つの異なる抽象レベル（分析レベルと設計レベル）です。統一モデリング言語（UML）とSysMLは、オブジェクト指向モデリングに使用される2つの一般的な国際標準言語です。^[9]

OOM の利点は次のとおりです。

効率的で効果的なコミュニケーション

通常、ユーザーは包括的なドキュメントやプログラミング言語のコードを理解するのが困難です。視覚的なモデル図は理解しやすく、ユーザーや関係者が開発者にシステムの適切な要件と構造に関するフィードバックを提供できるようになります。オブジェクト指向アプローチの主な目標は、システムと現実世界の間の「意味のギャップ」を減らし、関係者が日常業務で使用する用語とほぼ同じ用語を使用してシステムを構築することです。オブジェクト指向モデリングは、これを実現するための重要なツールです。

有用かつ安定した抽象化

モデリングはコーディングに役立ちます。ほとんどの最新のソフトウェア方法論の目標は、まず「何を」という質問に対処し、次に「どのように」という質問に対処することです。つまり、まず実装の制約を考慮せずにシステムが提供する機能を決定し、次にこれらの抽象的な要件に対する具体的なソリューションを作成する方法を検討し、テクノロジーや予算などの制約によって詳細な設計とコードに洗練します。オブジェクト指向モデリングは、システム要件と設計の両方の抽象的でアクセス可能な記述、つまりプロセスやオブジェクトなどの基本的な構造と動作を定義するモデルを作成することでこれを実現します。これは、具体的で複雑なソース コードよりも抽象度の高いレベルを持つ、重要で価値のある開発資産です。

• Grady Booch . 「オブジェクト指向分析および設計とアプリケーション、第 3 版」:http://www.informit.com/store/product.aspx?isbn=020189551X Addison-Wesley 2007。
• Rebecca Wirfs-Brock、Brian Wilkerson、Lauren Wiener。オブジェクト指向ソフトウェアの設計。Prentice Hall、1990 年。[オブジェクト指向プログラミングと設計の現実的な入門書。 ]
• オブジェクト指向設計の理論: オブジェクト指向設計の構成要素とそれを表現するための表記法 (設計パターンに重点を置きます)。
• Martin Fowler .分析パターン: 再利用可能なオブジェクト モデル. Addison-Wesley、1997 年。[概念モデルによるオブジェクト指向分析入門]
• ベルトラン・マイヤー著「オブジェクト指向ソフトウェア構築」プレンティス・ホール、1997年
• Craig Larman . UML とパターンの適用 - OOA/D と反復開発入門. Prentice Hall PTR、第 3 版。2005 年。
• セトラグ・コシャフィアン。オブジェクト指向。
• Ulrich Norbisrath、Albert Zündorf、Ruben Jubeh。ストーリー駆動型モデリング。Amazon Createspace。p. 333.、2013年。ISBN 9781483949253。 

Wikiversityにはオブジェクト指向ソフトウェア設計に関する学習リソースがあります

• 記事「UML と RUP を使用したオブジェクト指向分析と設計の概要 (CRC カードについても)」。
• UML の適用 - オブジェクト指向分析と設計チュートリアル
• OOAD および UML リソース Web サイトとフォーラム – UML を使用したオブジェクト指向分析と設計。
• Dhiraj Shetty による UML を使用したソフトウェア要件分析の記事。
• 記事 現実世界におけるオブジェクト指向分析
• オブジェクト指向分析と設計 - UML を使用した概要
• ラーマン、クレイグ。UML とパターンの適用 - 第 3 版
• オブジェクト指向分析と設計
• LePUS3 と Class-Z: オブジェクト指向設計のための形式モデリング言語