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

オブジェクト指向分析設計 (オブジェクトしこうぶんせきせっけい、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]。例えば、パッケージCがパッケージBに依存しているとし、パッケージBがパッケージAに依存しているとする。もしパッケージAがパッケージCに依存しているのであれば、依存性は循環している。パッケージAがパッケージCに依存していないのであれば、依存性は循環していない。
複合オブジェクトによる再利用の原則
継承よりも、多態性を備えた複合オブジェクトを採用する[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) で策定した。

これまで考案されてきたオブジェクト指向開発方法論の一部を示す。

オブジェクト指向開発で使われるソフトウェアパターンを次に示す。

なおアンチパターンは、問題に対する不適切な解決策のパターンである。

脚注

[編集]
[脚注の使い方]
  1. ^ “What Is Object-Oriented Design?”. Object Mentor. 2007年6月30日時点のオリジナルよりアーカイブ。2007年7月3日閲覧。
  2. ^ エリック・ガンマ、リチャード・ヘルム・ラルフ・ジョンソン・ジョン・ブリシディース・本位田真一 (訳) ・吉田和樹 (訳)『オブジェクト指向における再利用のためのデザインパターン 改訂版』ソフトバンククリエイティブ、1995 (1999再版)。ISBN 978-4-7973-1112-9。 

関連項目

[編集]

文献案内

[編集]

オブジェクト指向開発方法論の文献

[編集]

統一モデリング言語 (UML) の文献

[編集]

ソフトウェアパターンの文献

[編集]
  • 『アナリシスパターン 再利用可能なオブジェクトモデル』、マーティン・ファウラー、堀内一 (訳)、友野晶夫 (訳)、児玉公信 (訳)、大脇文雄 (訳)、ピアソン・エデュケーション、2002年 (1998年初版)、ISBN 978-4-89471-693-3 - アナリシスパターンを中心としたオブジェクト指向分析と概念モデルの入門書
  • 『ソフトウェアアーキテクチャ ソフトウェア開発のためのパターン体系』、F. ブッシュマン、R. ムニエ、H. ローネルト、P. ゾンメルラード、M. スタル、金澤典子 (訳)、水野貴之 (訳)、桜井麻里 (訳)、関富登志 (訳)、千葉寛之 (訳)、近代科学社、2000年、ISBN 978-4-7649-0283-1
  • 『オブジェクト指向における再利用のためのデザインパターン 改訂版』、エリック・ガンマ、リチャード・ヘルム、ラルフ・ジョンソン、ジョン・ブリシディース、本位田真一 (訳)、吉田和樹 (訳)、ソフトバンククリエイティブ、1999年、ISBN 978-4-7973-1112-9 (日本語訳の初版は1995年)
  • 『アンチパターン ソフトウェア危篤患者の救出』、William J. Brown 、Raphael C. Malveau 、Hays W. "Skip" McCormick III 、Thomas J. Mowbray 、岩谷宏 (訳) 、ソフトバンククリエイティブ、2002年、ISBN 978-4-7973-2138-8

その他の文献

[編集]

外部リンク

[編集]

この記事は2008年11月1日以前にFree On-line Dictionary of Computingから取得した項目の資料を元に、GFDL バージョン1.3以降の「RELICENSING」(再ライセンス) 条件に基づいて組み込まれている。