オブジェクト指向分析設計 (オブジェクトしこうぶんせきせっけい、OOAD 、英 : object-oriented analysis and design ) は、ソフトウェア工学 において、ソフトウェア (システム) を相互作用するオブジェクト の集まりとしてモデル化 (オブジェクト指向モデリング ) する、オブジェクト指向 に基づくソフトウェア開発 の方法である。オブジェクト指向の理論的枠組みに基づくソフトウェア開発、すなわちオブジェクト指向開発 を行う際の、ソフトウェア開発工程 において、分析工程であるオブジェクト指向分析 (OOA ; object-oriented analysis) と、設計 工程であるオブジェクト指向設計 (OOD ; object-oriented design) の、総称である。なおプログラミング 工程は、オブジェクト指向プログラミング OOP ; object-oriented programming) という。オブジェクト指向プログラミングの詳細については同項目を参照のこと。オブジェクト指向開発の具体的な方法論を、オブジェクト指向開発方法論 (object-oriented methodology) という。この項目では、オブジェクト指向開発におけるオブジェクト指向分析とオブジェクト指向設計、およびオブジェクト指向開発方法論を、主に説明する。
オブジェクト指向のモデリング (オブジェクト指向モデリング ) では、おのおののオブジェクト は、モデル化を行うシステムにおいて関心の対象となっている実体の表現であり、それぞれがそのクラス によってオブジェクトの状態 (データ要素) と振る舞いが特徴づけられる。
オブジェクト指向分析設計においては、次に示すようなシステムのさまざまな側面をモデル化することができる。
システムの静的な構造
システムの動的な振る舞い
システムにおいて協調して動作するオブジェクト群の実行時の配備 オブジェクト指向分析設計の過程で作られるモデル図の記法 (notation) は、これまで非常に多くの異なる記法が考案されてきた。
2008年現在では、オブジェクト指向分析設計におけるモデル図の記法は、統一モデリング言語 (UML) が使われる事例がほとんどである。
オブジェクト指向分析 (OOA) では、オブジェクト指向によるモデル化の技法を、システムに対する機能的な要件を分析するために、適用する。
オブジェクト指向設計 (OOD) では、オブジェクト指向分析によって得られた分析モデルを実装 (プログラミング ) するための仕様 を作るために、モデルを詳細に記述する。
オブジェクト指向分析とオブジェクト指向設計を含めた、オブジェクト指向開発の具体的な方法論を、オブジェクト指向開発方法論 (object-oriented methodology) という。
これまで非常に多くのオブジェクト指向開発方法論が考案されている。
オブジェクト指向システム は、オブジェクト の集まりから構成される。オブジェクト指向システムの振る舞いは、こうしたオブジェクト群が協調して動作することによって遂行される。オブジェクト群の協調動作は、互いにメッセージを送信しあうことによって行われてゆく。メッセージを送信するということは、メソッド( クラスやオブジェクトに属す関数 )を呼ぶ事である。オブジェクトが別のオブジェクトからメッセージを受信すると、メッセージを受信したオブジェクト自身が、そのメッセージ受信によって実行するべきことを決める。同一のメッセージが、複数の異なるメソッド によって実装 されていることがある。その場合、どのメソッドが実行の主体になるかについては、そのオブジェクトの状態に依存する。「メッセージ送信」の実装は、モデル化の対象となるシステムのアーキテクチャによりさまざまである。また「メッセージ送信」の実装は、協調動作するオブジェクト群が同一コンピュータ内に配置されているかそれとも複数のコンピュータに分散して配置されているかによっても、異なる。
オブジェクト指向分析 (OOA ; object-oriented analysis) は、システム化の対象となる領域 (問題領域; problem domain) を対象とし、分析の対象となる問題領域に存在するさまざまな情報の概念モデル (conceptual model) を作ることを目標とする工程である。オブジェクト指向分析で作る分析モデルでは、実装の水準において生じる可能性があるさまざまな種類の制約 (constraint) は、まったく考慮しない。ここで述べた実装の水準における制約には、並行性 、分散化 、永続化 などが、含まれる。すなわち分析モデルでは、システムがどのように構築されるかということは、まったく考慮しない。実装 の水準における制約は、オブジェクト指向分析の次の工程であるオブジェクト指向設計 (OOD) で、とり扱う。
オブジェクト指向分析の作業のもととなるのは、記述された形式の要求仕様 、将来に向けての企業戦略を記した書類、利害関係者 (ステイクホルダー) やその他の関係者へのインタビューなどである。システムは複数の領域に分割されることがある。システムが分割される際に、分割の基準となるのは、システムが複数のビジネスに関係する場合、その他複数の関心の領域がある場合などである。分割されたシステムは、それぞれ個別に分析される。
オブジェクト指向分析の成果物は、開発するシステムが機能的に「何を」することが必要であるかということを、概念モデルの形で記述したモデル図や文書である。オブジェクト指向分析の成果物は、ユースケース 、および統一モデリング言語 (UML) の複数のクラス図 や多数の相互作用図 のセットであることが多い。ユースケースは、ユースケース図 を使って描くことができる。成果物は、システムのユーザインタフェース を模擬して記述した資料を含むことがある。なお、アジャイルソフトウェア開発 の開発方法論を採用する場合は、オブジェクト指向分析の成果物は、必要十分な最小限の成果物を作成するのみであることが多い。
オブジェクト指向設計 (OOD ; object-oriented design) は、オブジェクト指向分析で得られた分析モデルを、さまざまな種類の制約 (constraint) を考慮したモデルに変換する工程である。ここで述べたさまざまな種類の制約には、選択したアーキテクチャに因る制約、非機能的制約 (技術的制約と環境面の制約を含む) を含む。具体的には、トランザクションスループット、レスポンスタイム、実行時のプラットフォーム 、開発環境、プログラミング言語 などが含まれる。
オブジェクト指向設計では、分析モデルで明確化された多くの概念を、クラス とインタフェース に対応づける。オブジェクト指向設計の成果物は、問題領域についてシステムが「どのように」構築されるかを詳細に記したモデル図と文書である。ただしアジャイルソフトウェア開発 の開発方法論を採用する場合は、オブジェクト指向設計の成果物は、必要十分な最小限の成果物を必要十分な最小限の詳細さの水準で作成するのみであることが多い。
オブジェクト指向設計の工程で使う資料 (オブジェクト指向設計の入力となる資料) の、一つの例を、説明する。いずれの資料も、前工程であるオブジェクト指向分析の成果物である。
概念モデル
システムが対象とする問題領域における、さまざまな概念を記述した文書とモデル図である。概念モデルは、並行性 や分散化 や永続性 などの実装の詳細に依存しない形で、明確に記述される。
ユースケース ユースケースは、何らかのビジネス目標と機能に関するシナリオでの、アクターと呼ばれるユーザとシステムの一連のやりとりを描いたものである。一つのユースケースは、アクターとシステムがどのように相互作用し、ビジネス上の目標の達成もしくはビジネス上の機能の実現をいかに行うかを説明する一つ以上のシナリオを、記述する。ユースケースのアクターは、エンドユーザである場合と、他のシステムである場合とがある。ユースケースはユースケース図 を使って描くことができる。
システムシーケンス図
システムシーケンス図は、ユースケースの個別のシナリオについて、アクターが発生させる事象とその順序および (もし有るのであれば) システム間の事象を記述したモデル図である。
ユーザインタフェース の文書(可能であれば作成しておく) ユーザインタフェースの文書は、完成させるシステムのユーザインタフェースのルックアンドフィール を示し説明した文書である。ユーザインタフェースの文書は、オブジェクト指向設計を行うに際して必須ではないが、完成させるシステムを視覚化することを助け、それにより設計者の作業にとって有用な資料となる。
関係データモデル (可能であれば作成しておく) データモデルとは、データがどのように表現されどのように使われるかを説明した、抽象的なモデルである。もしオブジェクトデータベース を使わずに関係データベース を使うのであれば、関係データモデルを作るべきであるとされる。その場合、関係データモデルを作った後にオブジェクト指向設計ができるようになる。関係データモデルを、オブジェクト指向のデータモデルに対応づける (マッピングする) ことを、どのようにして行うかを決める作業については、オブジェクト指向設計の工程に含まれる。 (参考: オブジェクトリレーショナルマッピング )
オブジェクト指向設計における次に示す5つの基本的な概念は、オブジェクト指向プログラミング言語 に組み込まれた実装の水準の機能である。
オブジェクト とクラス 何らかの概念を表現するものであり、データ構造 とそのデータ構造を扱い処理を実行するメソッド が、緊密なひとかたまりになったものである。システムの実行時には複数のオブジェクトがコンピュータ上で協調し相互作用して動作する。クラスは、オブジェクトの設計図である。オブジェクトはクラスを基にして生成される。
情報隠蔽
情報隠蔽 (information hiding) は、オブジェクトの構成要素を、外部の実体から防御する機構である。この機能は、オブジェクト指向プログラミング言語のキーワードによって有効になる。クラスの定義において、オブジェクトの構成要素であるインスタンス変数 に private や protected のキーワードをつけることにより、情報隠蔽をすることができる。
継承 継承 (inheritance) は、あるクラスを、別のクラスの機能を拡張もしくは上書きして、定義することができる機能である。継承先のクラスはサブクラス と呼ばれ、継承元のクラスのすべての特性をもつ。なお継承元のクラスはスーパークラス と呼ばれる。スーパークラスを継承してサブクラスが定義される。サブクラスは、サブクラスに固有の機能 (メソッド ) とデータ (インスタンス変数 ) をもつ。
インタフェース メソッドの実装を猶予する機能。メソッドのシグニチャ (特質) を、そのメソッドを実装することなく定義することができる機能。
多態性 (多相性、ポリモフィズム)多態性 (polymorphism) は、あるオブジェクトへの操作が呼び出し側ではなく、受け手のオブジェクトによって定まる特性である。
オブジェクト指向設計における考え方を説明する。
概念モデル図を基にして、クラス (オブジェクト) を定義し、クラス図 を作る。多くの場合は、実体はクラスに対応づけられる。
クラスのインスタンス変数 を同定する。
可能であれば、デザインパターン を使う。デザインパターンは最終的な設計ではない。デザインパターンはよく知られている一般的な問題に対する解決策を記述したものである。デザインパターンを使うことによる主な利点は、デザインパターンを複数のアプリケーションソフトウェア に対して再利用することができることである。デザインパターンは、ある問題を解決するための方法のひな型と考えることもできる。つまり、数多くの異なる状況ないしアプリケーションソフトウェアにおいて、特定の問題を解決するために使うことができるひな型である。オブジェクト指向におけるデザインパターンは、クラス群もしくはオブジェクト群の間の関係と相互作用を、提示していることが多い。デザインパターンは、開発対象となるシステムの、最終的なクラスやオブジェクトを規定するものではない。
可能であれば、アプリケーションフレームワーク を定義する。アプリケーションフレームワークとは、特定のオペレーティングシステム (OS) のためにアプリケーションソフトウェアの標準的な構造を実装するために使われる、ライブラリもしくはクラス群のセットを、多くの場合、さす用語である。大量の再利用可能なソースコード をアプリケーションフレームワークに統合することにより、開発者 (プログラマ ) の時間を大きく節約することができる。なぜなら開発者は、新しく一つのアプリケーションソフトウェアを開発するごとに、たくさんの標準的なソースコードを何度も書くという作業を、節約することができるからである。
可能であれば、永続化 するオブジェクトやデータを同定する。もし関係データベース を永続化の手段として採用するのであれば、オブジェクトと関係 (表、テーブル ) との対応づけを設計する (参考: オブジェクトリレーショナルマッピング )。オブジェクトデータベース を永続化の手段として採用する場合は、関係データベースを採用する場合のような対応づけの作業は必要ない。
複数のコンピュータ上にシステムを分散して配置する場合 (分散オブジェクト環境) には、分散オブジェクト (リモートオブジェクト、別のコンピュータからの呼び出しを受けるオブジェクト) を同定し、定義する。
UML のクラス図 による汎化 関係および集約関係 (一対多の多重度) の表現UMLのシーケンス図 の例 オブジェクト指向設計の作業を行って作成される主な成果物は、次に示すとおりである。なおこの他の種類の資料についても、後工程であるオブジェクト指向プログラミング やソフトウェア保守 などにおいて、有用となると認められる文書やモデル図などについては、作成する。アジャイルソフトウェア開発 の開発方法論を採用する場合は、オブジェクト指向設計の成果物は、必要十分な最小限の成果物を作成するのみであることが多い。
クラス図 クラス図は、システムの静的な構造を説明したモデル図であり、システムで使われるクラス、システムで使われるクラスに定義されたインスタンス変数、クラスとクラスの間の関係を、記述している。クラスとクラスの間の関係として、汎化 (継承 )、集約、コンポジション (複合オブジェクト) などの、クラス間関係を記述することができる。
シーケンス図 システムシーケンス図に対して、システムの事象を制御する具体的なオブジェクトを追加する。多くの場合、シーケンス図はシステムにおいて重要で複雑なシステム事象を記述する際に、記述する。単純な事象やありふれた事象をシーケンス図として記述することは、多くの場合は、ない。
シーケンス図においては、垂直方向に複数の平行な線を引き、同時に生存している複数のオブジェクトをそれぞれの線で表現する。また水平方向に矢印線を引き、同時に生存している複数のオブジェクト間でやりとりされるメッセージを矢印線で表現する。こうした水平方向の矢印線は、上から下に時系列に配置する。
オブジェクト指向設計においては、後工程であるオブジェクト指向プログラミングにおける考え方も、必要に応じて考慮する。
アスペクト指向プログラミング アスペクト指向プログラミング (AOP; aspect-oriented programming) では、プログラム (システム) のすべての主だった機能は、アスペクトであると考える。アスペクトには、中心的な関心事 (ビジネスロジック ) と横断的な関心事 (付加的な機能) とがある。分割しておいた中心的な関心事と付加的な関心事をいっしょに編み合わせる (weaving) ことにより、分割しておいたアスペクトを基にして、プログラム全体を生成することができる。
依存性の注入 依存性の注入 (dependency injection) の基本的な考えは、あるオブジェクトが何か別のオブジェクトへの参照をもつことに依存しているのであれば、依存される側のオブジェクトを依存する側のオブジェクトに「注入」する、ということである。例えば、データベース 接続を表現するオブジェクトが必要なオブジェクトがあるのであれば、そのオブジェクト内でデータベース接続オブジェクトを生成するのではなく、そのオブジェクトのコンストラクタ (新たなオブジェクトを生成する際に呼び出される手続き) への引数 (パラメタ) として、データベース接続オブジェクトをそのオブジェクトに渡すのである。
循環しない依存性の原則
パッケージ やソフトウェアコンポーネント の依存性のグラフ は、循環するべきではないという原則。このことは、依存性のグラフは有向非循環グラフであるべきであるとも、述べることができる[ 1] 複合オブジェクトによる再利用の原則
継承 よりも、多態性 を備えた複合オブジェクトを採用する[ 2]
オブジェクト指向プログラミング OOP ; object-oriented programming) は、オブジェクト指向開発におけるオブジェクト指向設計 (OOD) の次の工程であり（この「次の工程」という概念自体はウォーターフォール開発に固有の概念であり、それ自体はOOADともオブジェクト指向（及びオブジェクト指向プログラミング）とも独立・無関係である）、この工程でソフトウェア のプログラミング を行う。
オブジェクト指向プログラミングでは、ほとんどの場合、プログラミング言語 としてオブジェクト指向プログラミング言語 OOPL ; object-oriented programming language) を採用する。オブジェクト指向プログラミング言語では、オブジェクト 、クラス 、情報隠蔽、継承 、多態性 (ポリモフィズム) などの概念を、プログラミング言語に組み込んでいる。そのため、オブジェクト指向プログラミング言語を有効に活用することで、オブジェクト指向プログラミングを効率的に行うことができる。
一方で、オブジェクト指向プログラミングにオブジェクト指向分析設計が有効か否かは、さだかではない。オブジェクト指向分析設計ではしばしば前述のようにプログラミングが分析設計の「次の工程」であるとウォーターフォール開発的に信じられていることもあるようだが、そのような考え方はオブジェクト指向プログラミングの流行によって生まれてきた、オブジェクト指向分析設計以外の多くの手法、特にアジャイルソフトウェア開発 では完全に否定されている。また本来は、オブジェクト指向分析設計はクラスベース オブジェクト指向への拘泥は無いはずであるが、現実には多くのオブジェクト指向分析設計の解説においてクラスベースオブジェクト指向が大前提となっており、JavaScriptなどプロトタイプベース の観点は見られない。
オブジェクト指向開発方法論 (object-oriented methodology) は、オブジェクト指向分析とオブジェクト指向設計を含めた、オブジェクト指向開発の具体的な方法論である。1980年代後半から2008年現在に至るまで、非常に多くのオブジェクト指向開発方法論が考案されている。そしてオブジェクト指向開発を行う多くのソフトウェア開発者 は、いずれかのオブジェクト指向開発方法論を採用して、ソフトウェア開発を行っている。
おのおののオブジェクト指向開発方法論では、それぞれに次に示すようなソフトウェア開発工程 の具体的な方法を、詳細に提示している。
なお1990年代半ばまでは、分析と設計のモデル図の記法 (notation) も、オブジェクト指向開発方法論ごとにそれぞれ異なる記法を規定していたが、現在ではほとんどのオブジェクト指向開発方法論で、統一モデリング言語 UML ) を記法として採用している。UMLは、1997年にオブジェクト指向開発方法論者たちが共同で標準化団体 Object Management Group (OMG) で策定した。
これまで考案されてきたオブジェクト指向開発方法論の一部を示す。
オブジェクト指向開発で使われるソフトウェアパターンを次に示す。
なおアンチパターン は、問題に対する不適切な解決策のパターンである。
^ “What Is Object-Oriented Design? ”. Object Mentor. 2007年6月30日時点のオリジナル よりアーカイブ。2007年7月3日 閲覧。 ^ エリック・ガンマ 、リチャード・ヘルム ・ラルフ・ジョンソン ・ジョン・ブリシディース ・本位田真一 (訳) ・吉田和樹 (訳)『オブジェクト指向における再利用のためのデザインパターン 改訂版』ソフトバンククリエイティブ、1995 (1999再版)。ISBN 978-4-7973-1112-9 。
『UML モデリングのエッセンス 第3版』、マーティン・ファウラー 、羽生田栄一 (監訳)、多摩ソフトウェア有限会社 (訳)、翔泳社、2005年、ISBN 978-4-7981-0795-0
『UMLユーザーガイド』、グラディ・ブーチ 、ジェームズ・ランボー 、イヴァー・ヤコブソン 、羽生田栄一 (監訳)、オージス総研オブジェクト技術ソリューション事業部 (訳)、ピアソンエデュケーション、1999年、ISBN 978-4-89471-155-6
Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide (2nd Edition) , Addison-Wesley Professional, 2005, ISBN 978-0-321-26797-9
『UMLリファレンスマニュアル』、ジェームズ・ランボー、グラディ・ブーチ、イヴァー・ヤコブソン、石塚圭樹 (監訳)、日本ラショナルソフトウェア株式会社 (訳)、ピアソンエデュケーション、2002年、ISBN 978-4-89471-267-6
James Rumbaugh, Ivar Jacobson, Grady Booch, The Unified Modeling Language Reference Manual (2nd Edition) , Addison-Wesley Professional, 2004, ISBN 978-0-321-24562-5
この記事は2008年11月1日以前にFree On-line Dictionary of Computing から取得した項目の資料を元に、GFDL バージョン1.3以降の「RELICENSING」(再ライセンス) 条件に基づいて組み込まれている。
