OODとは? わかりやすく解説

Weblio 辞書 > 辞書・百科事典 > 百科事典 > OODの意味・解説 

ウード (ドクター・フー)

(OOD から転送)

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2019/12/25 17:21 UTC 版)

ナビゲーションに移動 検索に移動
ウード

ウード: Ood)は、イギリスの長寿SFテレビドラマ『ドクター・フー』に登場する地球外生命体の種族。劇中の歴史においては42世紀ごろの未来に生息する[1]

ウードは奴隷種族であり、普段は穏和かつ親切であるが、外部からの影響を受けやすいように描写されている。後に彼らは奴隷制度から解放され、『時の終わり』では100年という短期間のうちに高度な文明を築いていた[2]

特徴

ウードは顔の下側からは触手が伸びたヒューマノイドの種族である。テレパシー種族でもあり、翻訳機を用いて非テレパシー種族と会話を交わしている[3]。翻訳機と呼ばれる球体は管を経由して体と繋がっているが、この管は元々体と外部の脳を繋いでいた。未来の人類が彼らの脳を物理的に取り除き、元々脳があった場所に翻訳機を固定したのである。ウードには性別はないようである。ウードは皆1つの精神を共有するためシステムにあるため名前や称号は必要とされないが、人間の都合によって「ウード1アルファ1」や「ウードシグマ」といった具合に識別されることがある[4][1]。『囚われの歌』においてドクターは、ウードの個性はウードの意識の集合体が個々に異なる現れ方をした結果であると述べ、「潜在意識ってのは色んな形で現れる。復讐心で赤目となり狂暴化したが、忍耐を覚えた者もいる。頭のいいシグマは慈悲も身につけたらしい。」("Funny thing, the subconscious. Takes all sorts of shapes. Came out in the Red-Eye as revenge, came out in the Rabid Ood as anger, and then there was patience. All that intelligence and mercy focused on Ood Sigma.")と発言した[1]。ウードは高い共感性を持ち、低レベルのテレパシーコミュニケーションフィールドを共有している。タイムロードが介入するなどしてテレパシーフィールドに耳を傾けると、彼らの歌を聞き取ることができる[1]。この能力により彼らはテレパシーコントロールを受けやすくなっており、さらに強力なテレパシーの力により支配されているエピソードも複数ある[4][5]

歴史

シリーズ2『闇の覚醒』でウードは初登場を果たした。彼らは人間に使役される奴隷向きの種族で、人間のためのあらゆる種類の単純労働をこなしていた。労働を生きがいにし、命令に従って給仕する以外の目的がない様子が描写された。また、病気に感染しても申告しないなど自分自身のことを気にかけず、仕事が与えられなければやつれて死んでしまうとも言われた。なお、吹替および字幕では読み取れないが、ウードを奴隷の立場から解放せんとする集団 "Friends of the Ood" の存在が仄めかされている[6]

Official Doctor Who Annual 2007 によると、ウードの生息する惑星は馬頭星雲にあり、集合精神に支配されていたが人類の入植者により滅ぼされた。BBCが著作権を持つ書籍 Doctor Who: Creatures and Demons ではウードはウード・スフィアから進出したとされている。ウード・スフィアはセンソライツの故郷であるセンソ・スフィアに距離的に近く、センソライツはウードと肉体・精神ともに類似している。集合意識を失ったウードは人類の入植者へ奴隷に出頭して奴隷となった。

10代目ドクターとローズ・タイラーは人間が統率する調査隊に雇われた大量のウードと遭遇している。ビーストによりウードのテレパシーレベルが異常値を示し、ウードは彼の軍団に下ることとなった。ビーストの支配下に置かれたウードは目が赤く光り、翻訳機を投げつけて感電死させることで次々に調査基地の人間を抹殺した[6]。最終的にドクターは必要に迫られ、生きているウードを惑星クロプ・トールもろともブラックホールへ捧げることとなった[4]

ウードはシリーズ4『囚われの歌』で再登場し[7]、生まれついての奴隷ではなく奴隷化させられた種族であることが明かされた。ウードの翻訳機は本来個人と結び着いていた後脳を置き換えたものであり、ウードをテレパシーで繋ぐ集合意識は、ウードを奴隷化して売買する企業ウード・オペレーションにより200年もの間ウードから隔離されていた。同エピソードで赤目のウードが再登場し、集合意識の命令に従って暴動を起こした。ドクターがウードを集合意識を解放してウードを自由の身とした。解放後、宇宙に散らばった全てのウードがウード・スフィアに戻されることとなった。同エピソードで初登場を果たしたウード・シグマは、ドナ・ノーブルをドクター・ドナと呼び、ドクターの歌が終わりに近いことを告げている。

ウード・シグマは2009年秋スペシャル『火星の水』で再登場し、2059年の地球へ戻った10代目ドクターとコンタクトを取ろうとした[8]

『時の終わり』に登場した長老

ウードは後に『時の終わり』二部作にも登場した。ドクターはついにウード・シグマのメッセージを受け入れ、『囚われの歌』から100年後のウード・スフィアへ足を運んだ。ドクターはウードの文明があまりにも急速に発展したこと、そして100年をかけて時間を見渡す能力を会得したことを知る。時間を透視できるのは時間が血を流しているからであるとウードの長老が説明し、彼はウード族が見た夢と予言をドクターへ見せる[2]。後に、ウード・シグマが再び姿を現し、10代目ドクターがターディスに入って11代目ドクターに再生するのを応援した[9]

シリーズ6『ハウスの罠』では1人のウードがネフューと呼ばれている。ネフューはハウスと呼ばれる存在の影響下にあり、エイミー・ポンドローリー・ウィリアムズをターディスの旧型のコンソールルームで殺そうとしていたところ、彼が立っていた場所に11代目ドクターとイドリスが着陸したため死亡し、一瞬で蒸発する羽目になった。ドクターはネフューに関して"another Ood I failed to save"(字幕では「気の毒だったな」、吹替では「気の毒なことをした」)と言及し、以前にウードに出会っていたことを仄めかした。ネフューの目はハウスに乗っ取られた際に緑色に光り、以前のシリーズと差別化されている[5]

ミニエピソード "Death is the Only Answer" では、アルバート・アインシュタインが謎の液体を摂取して赤目のウードへ変化している。ウードは "Death is the only answer" というフレーズを繰り返した後、アインシュタインに戻った[10]

シリーズ6『ドクターの戦争』では11代目ドクターがウード・シグマと再会するはずであったが、2010年新春スペシャルまでの製作総指揮を担当したラッセル・T・デイヴィスがウード・シグマのライセンスを持っていたため、このシーンはカットされた[11]

ミニエピソード Pond Life では、ターディスで迷子になった1人のウードがエイミーとローリーの家に訪れている。ドクターがウード・スフィアに連れ戻すまでの数日間はエイミーとローリーの執事として働いていた[12]

登場

テレビ

  • 『闇の覚醒』/『地獄への扉』(2006)
  • 『囚われの歌』(2008)
  • 『時の終わり』(2009–10)
  • 『ハウスの罠』(2011)

カメオ出演

  • 『火星の水』(2009)
  • 『魔術師の弟子』(2015)
  • 『カラスに立ち向かえ』 (2015)

ミニエピソード

  • Death is the Only Answer (2011)
  • Pond Life (2012)

出典

[ヘルプ]
  1. ^ a b c d シリーズ4『囚われの歌』
  2. ^ a b 2009年クリスマススペシャル『時の終わり』Part1
  3. ^ TARDIS, Doctor Who Adventure Games”. 2010年8月28日時点のオリジナルよりアーカイブ。2011年6月11日閲覧。 “The game says that the Ood have no vocal cords.”
  4. ^ a b c シリーズ2『地獄への扉』
  5. ^ a b シリーズ6『ハウスの罠』
  6. ^ a b シリーズ2『闇の覚醒』
  7. ^ Return of the Ood”. Doctor Who News. BBC (2007年7月25日). 2007年11月23日時点のオリジナルよりアーカイブ。2019年10月13日閲覧。
  8. ^ Anders, Charlie Jane (2009年3月2日). “The Comeback That Brings The Doctor To His Knees”. io9. Gawker Media. 2009年4月8日閲覧。
  9. ^ 2010年新春スペシャル『時の終わり』Part2
  10. ^ "Death is the Only Answer"
  11. ^ The Brilliant Book 2012
  12. ^ Pond Life

外部リンク 


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

(OOD から転送)

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2026/02/15 21:28 UTC 版)

オブジェクト指向分析設計 (オブジェクトしこうぶんせきせっけい、OOAD: object-oriented analysis and design ) は、ソフトウェア工学において、対象領域や要求をオブジェクトとして捉え、分析(オブジェクト指向分析)と設計(オブジェクト指向設計)を通じて、実装へ至るモデルを洗練するソフトウェア開発工程である。一般に、ユースケースやクラス図などの視覚的モデリング(例:UML)を用いて、要件と設計を対応付けながら作業を進める。

概要

オブジェクト指向のモデリング (オブジェクト指向モデリング) では、おのおののオブジェクトは、モデル化を行うシステムにおいて関心の対象となっている実体の表現であり、それぞれがそのクラスによってオブジェクトの状態 (データ要素) と振る舞いが特徴づけられる。

オブジェクト指向分析設計においては、次に示すようなシステムのさまざまな側面をモデル化することができる。

  • システムの静的な構造
  • システムの動的な振る舞い
  • システムにおいて協調して動作するオブジェクト群の実行時の配備

オブジェクト指向分析設計の過程で作られるモデル図の記法 (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) は、オブジェクトの構成要素を、外部の実体から防御する機構である。この機能は、オブジェクト指向プログラミング言語のキーワードによって有効になる。クラスの定義において、オブジェクトの構成要素であるインスタンス変数privateprotected のキーワードをつけることにより、情報隠蔽をすることができる。
継承
継承 (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年。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」(再ライセンス) 条件に基づいて組み込まれている。




英和和英テキスト翻訳

英語⇒日本語日本語⇒英語

辞書ショートカット

すべての辞書の索引

「OOD」の関連用語

OODのお隣キーワード
検索ランキング

   

英語⇒日本語
日本語⇒英語
   



OODのページの著作権

   
ウィキペディアウィキペディア
All text is available under the terms of the GNU Free Documentation License.
この記事は、ウィキペディアのウード (ドクター・フー) (改訂履歴)、オブジェクト指向分析設計 (改訂履歴)の記事を複製、再配布したものにあたり、GNU Free Documentation Licenseというライセンスの下で提供されています。 Weblio辞書に掲載されているウィキペディアの記事も、全てGNU Free Documentation Licenseの元に提供されております。

©2026 GRAS Group, Inc.RSS