オブジェクト指向の考え方に関する資料を読んだことがあれば、オブジェクト指向とは何かについてすぐに理解したかもしれません。つまりそれは、オブジェクトと呼ばれる再使用可能なコンポーネントによってシステムを構築するという発想に基づいたソフトウェア開発の戦略なのです。この考え方の背後には、2 つの別個の部分 (つまりデータと機能) に分けてシステムを定義する代わりに、相互に作用するオブジェクトのコレクションとしてシステムを定義するという思想があります。オブジェクトは、何かを実行すること (つまり機能) と、何かを認識すること (つまりデータ) の両方を行います。単純なように聞こえるかもしれませんが、実際にはそうではありません。ソフトウェア開発は簡単にはゆきません。しかも、オブジェクト・テクノロジーを応用するのは、複雑な問題を解決しなければならないときであるのが普通ですから、オブジェクト・テクノロジーによってシステムを開発するのは、シンプルで構造的なテクノロジーを使う場合よりもさらに難しい場合さえ少なくないのです。Unified Modeling Language (UML) の成果物をはじめとするオブジェクト指向の成果物や、UML が残したいくつかのギャップを埋めるためのエッセンス・モデルや持続モデルといったその他の成果物の使い方を理解するには、入門書のようなものが必要です。まさにそのような入門書の役割を果たすことが、本稿の意図なのです。

本稿では、図 1 にあるとおり、オブジェクト指向の技法によってソフトウェアを開発するための最小限のプロセスを示します。ここで「最小限」という表現を使っているのは、ソフトウェア開発の中心的な作業だけを取り上げることにしているからです。つまり、Requirements (要件)、Analysis (分析)、Design (設計)、Programming (プログラミング)、Testing (テスト) という基本的な作業です。プロジェクト管理、メトリック、アーキテクチャー、システム・デプロイメントといった、その他の重要な問題には触れません。システム導入後の運用やサポートも、ソフトウェア・プロセスに不可欠ですが、そのような点も取り上げません。後からお分かりになるでしょうが、基礎知識だけでも相当に込み入っていることを考えれば、ここで先走る必要はないのです。

ここでまず指摘しておきたいのは、ソフトウェア開発は大まかに見れば直列的な作業であるとはいえ、細かく見ると、時間をかけて増分リリースを出してゆく反復的な作業だという点です。この点を念頭に置いて、ここでは、要件エンジニアリング、分析、設計、プログラミング、テストという、オブジェクト指向ソフトウェア開発の主な作業を直列的に示してゆきますが、実際の現場では、これらの作業をいずれも反復的に実行しなければならないことがすぐにお分かりになることでしょう。

オブジェクト指向の要件エンジニアリング

まず、"オブジェクト指向の要件" と呼べるようなものは何もありません。筆者の経験から言えることですが、要件はテクノロジーから独立しているべきでしょう。したがって、開発過程においては、この時点以外に要件について考えるべき時はないのです。「反復的な開発」という思想に関してどんなごまかしが存在するにしても、ソフトウェア開発作業の最初の段階では、いろいろな要件を手元に集めなければなりません。たとえ一度にすべての要件を集めることはなくても、少なくともいくつかの要件を把握しておく必要があります。システムを構築するにあたって、いったい何のためのシステムかがはっきりしていなければ、作業の成功はあり得ません。この段階で一番大きな問題になるのは、要件を導き出すための時間を惜しんで、いきなりプログラミングを始めてしまう人が多いということです。各分野のエキスパート (SME) には通常の業務があって、時間を割くことができません。しかも、開発者の側にも、コーディングという "実際の作業" がしたいという願望がありますし、管理職のほうにも、プロジェクトが少しでも進んでいるのを見たいという気持ちがあります。要するに、いくらかでもコードが記述されているのを見たいというわけです。したがって、プロジェクトの関係者全員とコミュニケーションを図って、この準備段階がプロジェクトの成功のためにどうしても必要だということ、さらには、長い目で見ればそのほうが有利だということを話し合わなければならないでしょう。

図 2 は、要件エンジニアリング作業の一環として開発できる成果物間の関係を示したものです。四角の枠で示したのが成果物であり、矢印は "影響力" の関係を示しています。たとえば、Class Responsibility Collaborator (CRC) Model (クラス責任範囲コラボレーター (CRC) モデル) に入っている情報と、Essential Use-Case Model (エッセンス・ユース・ケース・モデル) 内の情報は、互いに影響力を及ぼし合っています (本稿で取り上げるすべての成果物の定義については、用語集をご覧ください)。図 2 からは、いくつかの重要な教訓も引き出せます。1 つは、要件エンジニアリングは極めて反復性の高いプロセスだという点です。2 つ目として、オブジェクト指向の要件のエンジニアリングは、ユース・ケースの記述よりもはるかに複雑だという点があります。したがって、「ユース・ケースに影響された X」という表現は、「要件に影響された X」という表現に改めたほうが的を突いているように思います。

上に戻る

オブジェクト指向の分析

分析の目的は、何を構築するのかを把握することにあります。確かにこの点では、要件エンジニアリングとよく似ています。各ユーザーが何を構築したいと思っているのかを判別することが、要件エンジニアリングの目的でした。では、主な違いはどこにあるのでしょうか。要件エンジニアリングでは、各ユーザーがシステムをどのように使うかに焦点を合わせているのに対し、分析の場合は、システムそのものが焦点になっています。図 3 は、分析作業の主な成果物とそれらの相互関係を示したものです。実線の枠は分析用の主な成果物であり、点線の枠は要件用の主な成果物です。前の図と同じく、矢印は "影響力" の関係を示しています。たとえば、CRC Model (CRC モデル) に入っている情報と、Class Model (クラス・モデル) の情報は、互いに影響力を及ぼし合っています。図 3 には重要な意味が 3 つあります。1 つの点として、分析も反復的なプロセスだということです。2 つ目に、要件収集と分析を一緒に考えてみれば、両者の相互関係は非常に強く、両者の間のプロセスも極めて反復的です。後から取り上げますが、分析と設計の場合も同じように、両者の間に相互関係と反復性が見られます。3 つ目の点は、"エッセンス" モデルである Essential Use Case Model (エッセンス・ユース・ケース・モデル) と Essential User Interface Prototype (エッセンス・ユーザー・インターフェース・プロトタイプ) が (参考文献の「Software Use」を参照)、分析用技術製品 (つまり、ユース・ケース・モデルとユーザー・インターフェース・プロトタイプ) に発展しているということです。同じように、Class Responsibility Collaborator (CRC) Model (クラス責任範囲コラボレーション (CRC) モデル) は、分析クラス・モデルに発展しています。

図 3 だけでなく、本稿で使用している同じような図についても言えることですが、想定できるすべての "影響力" の関係が図示されているわけではない、という重要な点をはっきりさせておく必要があります。たとえば、Use Case Model (ユース・ケース・モデル) の開発中に、User Interface (ユーザー・インターフェース) 内の 1 つの機能が欠けていると思う場合、図の中ではその 2 つの成果物の間に関係が示されていないことに気付くかもしれません。厳密に学問的な観点からすると、ユース・ケース・モデルがユーザー・インターフェース・モデルと対立する場合は、まずどこが問題になっているかを検討し、それに合わせてユース・ケース・モデルを更新し、この変更をエッセンス・ユース・ケース・モデルにも反映してから、エッセンス・ユーザー・インターフェース・モデルに反映し、最後にユーザー・インターフェース・モデルに反映する、という手順を実行することになるでしょう。確かに、実際の現場でも、そのような順番で作業を進めるかもしれません。しかし、それとは別に、ユース・ケース・モデルとユーザー・インターフェース・モデルを一緒に更新してから、対応する要件用成果物にその変更内容を反映するという方法もあります。場合によっては、その方法を採用する確立のほうが高いかもしれません。これは、反復的な開発の重要な側面です。つまり、必ずしもお決まりの順番で作業を進めるとは限らないのです。むしろ、作業の内容は、時間をかけて改良を重ねた成果物間の関係に基づくということです。

上に戻る

オブジェクト指向の設計

設計の目的は、システムの構築方法を決定することです。この情報があってはじめて、システムの実際のインプリメンテーションを進めることができます。この点で、設計は分析とは異なります。分析段階では、何を構築するかに焦点を合わせました。図 4 からもお分かりになるように、分析用成果物 (点線の枠で図示) は、設計用成果物の開発に影響を及ぼします。前の図と同じく、矢印は "影響力" の関係を示しています。たとえば、分析 (概念) クラス・モデルの情報と、設計クラス・モデルの情報は、互いに影響力を及ぼし合っています。図 4 には重要な意味が 3 つあります。1 つの点として、要件や分析と同じように、設計も反復的なプロセスだということです。2 つ目に、分析と設計を一緒に考えてみれば、両者の相互関係は非常に強く、両者の間のプロセスも極めて反復的です。次のセクションで取り上げますが、設計とプログラミングの場合も同じように、両者の間に相互関係と反復性が見られます。3 つ目の点は、分析クラス・モデルが設計クラス・モデルに発展しており、インプリメンテーション環境、階層構造をはじめとする設計上の概念、設計パターンのアプリケーションなどの特色を反映しているという点です。

設計プロセスの最初の段階で決定しておかなければならないハイレベルな問題がいくつかあります。1 つは、純粋なオブジェクト指向の方法で設計を行うのか、それともコンポーネント・ベースの方法を使うのか、という点です。純粋なオブジェクト指向の方法の場合は、クラスのコレクションからソフトウェアを構築するのに対し、コンポーネント・ベースの方法では、コンポーネントのコレクションからソフトウェアを構築します。この場合のコンポーネントは、他のコンポーネントまたはクラスを使って作成することになります。(もちろん、オブジェクト・テクノロジー以外の方法でコンポーネントを作成することも可能です。)

設計段階で決定しなければならない 2 番目の点は、一般的なビジネス・アーキテクチャーをすべて採用するのか、それとも一部だけを採用するのか、という問題です。このアーキテクチャーは、各企業の固有のビジネス・モデルまたはドメイン・アーキテクチャー・モデル (企業ビジネス・モデルともいう) に基づいて定義する場合と (参考文献の「Process Patterns」を参照)、各業界で推進されている一般的なビジネス・アーキテクチャー・モデルに基づいて定義する場合とがあります。たとえば、製造業界、保険業界、銀行業界などでは、標準的なビジネス・モデルが存在します。一般的なビジネス・アーキテクチャーを採用することにした場合は、設計モデルにその決定を反映し、ビジネス・クラスのインプリメンテーションにおいてそのビジネス・アーキテクチャーを応用する方法を示す必要があります。

3 番目の点として、一般的な技術インフラストラクチャーのすべてを活用するのか、それとも一部だけを活用するのか、を決定しなければなりません。各企業の技術インフラストラクチャー、つまりおそらくはコンポーネントやフレームワークのコレクションを使ってシステムを構築するのでしょうか。Enterprise JavaBeans (EJB) テクノロジー、CORBA、San Francisco Component Framework (参考文献を参照) などは、システム構築のベースになり得る技術インフラストラクチャーの例です。プロジェクトの目標の 1 つとして、将来のプロジェクトでも使える再使用可能な成果物を作成することを考えている場合もあるでしょう。もしそうであれば、技術アーキテクチャーのモデリングを真剣に検討してみるべきです。技術アーキテクチャーのモデリングの問題は本稿の守備範囲からは外れますが、拙著「Process Patterns」(参考文献) の中で取り上げていますので、そちらをご覧ください。

4 つ目の決定事項は、システムの機能面以外の要件や制約です。こうした要件については、分析段階で検討し、できればいろいろな矛盾を解決しておくことが望ましいのですが、実際にモデルの中に要件を取り込んでゆく作業は設計段階で行います。この場合の要件は主に技術サービスに関係があります。たとえば、一般には、セキュリティー上のアクセス権限やデータ共用の方法の設定といった、機能面以外の要件があるでしょう。そうした要件を満たすための作業を続けているうちに、それらの要件を完全にインプリメントするのが不可能だという点に気付く場合もあるかもしれません。たとえば、1 秒未満の応答時間をサポートするようなシステムを構築するのはコスト的に無理ですが、数秒の応答時間であれば実現が可能だろうといったような問題です。それぞれのシステムでは、設計上のメリットとデメリットのバランスを考えなければなりません。

上に戻る

オブジェクト指向のプログラミング

オブジェクト指向のプログラミングの目的は、実際のシステムを構築することです。つまり、システムの設計を実現するためのコードを開発しなければなりません。図 5 からもお分かりになるように、設計用成果物 (点線の枠で図示) は、ソース・コードの開発に影響を及ぼします。ここで最も重要な点は、設計とプログラミングの間に強い相互関係と反復性が見られるということです。プログラミング作業では、設計上の問題点がすぐに明らかになるでしょう。そうした問題点は解決しなければなりません。たとえば、設計担当者がプログラミング環境の何かの機能を知らなかったために、そうした機能が活用されていないというような問題です。

ここでは明らかになっていませんが、採用できるソース・コードのタイプは 2 つあります。1 つは、Java コードや C++ をはじめとするオブジェクト指向のコードであり、もう 1 つは、データ定義言語 (DDL)、データ操作言語 (DML)、ストアード・プロシージャー、トリガーなどの持続メカニズム・コードです。クラス・モデル、状態チャート・ダイアグラム、ユーザー・インターフェース・プロトタイプ、ビジネス・ルール、コラボレーション・ダイアグラムは、オブジェクト指向コードの開発に影響を及ぼすのに対し、持続モデルは、持続コードの開発に影響を及ぼします。(持続モデルの詳細については、参考文献の「Toward a UML Profile for a Relational Persistence Model」を参照してください。)

上に戻る

オブジェクト指向のテスト

できるだけ早い段階でテストを実施するというのは、ソフトウェア・エンジニアリングの鉄則です。ほとんどのミスはプロジェクトの初期段階で発生しており、問題点の解決にかかるコストは、発見が遅れれば遅れるほど膨らんでゆきます。

技術屋と呼ばれる人々は、設計やコーディングといったことが得意であり、それゆえに技術屋という肩書きをもらうわけですが、その一方で、要件の収集や分析の実施といった、非技術的な作業はあまり得意でない場合が少なくありません。ある意味では、だからこそ技術屋と呼ばれるのかもしれませんが、結果的に、設計やコーディングの段階よりも、要件定義や分析の段階において、より多くのエラーが発生するというのが、開発者たちの傾向となっています。

早い段階でのテストが望ましいと言えるもう 1 つの要因は、問題点の解決にかかるコストが、後の段階になればなるほど膨らむという点です。これは、ソフトウェア開発の性質からして当然と言えば当然です。要するに、1 つ 1 つの作業は、その前の作業に基づいて行われてゆくのです。たとえば、モデリングの作業は、要件定義の段階で収集した情報に基づいて行われます。プログラミングは、前に開発したモデルに基づいて行われ、テストは、前に作成したソース・コードに基づいて行われるわけです。仮に要件の理解に間違いがあれば、その要件に基づいて決定されたあらゆるモデルは無効になる可能性があります。そうであれば、そのモデルに基づいて記述されたすべてのコードも怪しくなりますし、テストの作業も、間違った条件に照らしてアプリケーションを検証することになってしまいます。したがって、開発の最終段階で検出されたエラーや、アプリケーションのリリース後に発見されたエラーは、修正にかなりのコストがかかってしまうのです。それとは逆に、発生直後の早い段階で発見されたエラーは、修正にかかるコストがはるかに少なくて済むでしょう。ほんのわずかな文書を更新するだけでよいからです。

Full-Life cycle Object-Oriented Testing (FLOOT) と呼ばれる方法は、オブジェクト指向ソフトウェアの検証と妥当性検査を実施するためのテスト技法のコレクションです。FLOOT の全体的な作業の流れを示したのが、図 6 です。その図から分かるとおり、ソフトウェア開発のあらゆる局面において、多彩な技法が用意されています。(参考文献の「The Object Primer 2nd Edition」、「Building Object Applications That Work」、「Testing Object-Oriented Systems」を参照してください。) オブジェクト指向システムでは、他のシステムに比べて、テスト作業が減るよりはむしろ増える場合が少なくありません。オブジェクト・テクノロジーが採用されている問題ドメインは、極めて複雑になっているからです。

上に戻る

オブジェクト指向開発の複雑さ

オブジェクト指向の開発にまつわる一般的な誤解の 1 つは、構造的な開発よりもはるかに簡単だという考えです。とはいえ、図 2 から図 6 をまとめた図 7 を見ればお分かりになるように、オブジェクト指向の開発は実際には非常に複雑なのです。おそらく、ほとんどの "オブジェクトの教祖たち" が認める以上に複雑でしょう。しかも、冒頭で指摘したとおり、本稿で取り上げるのは基礎知識だけであり、管理、運用、プロジェクト間の問題などには触れていないのです。

オブジェクト指向やコンポーネント・ベースの技法やテクノロジーを駆使して、基幹ソフトウェアを開発することは可能です。現に、数多くの企業において毎日行われているのです。要するに、オブジェクト指向は多種多様なスキルを必要とする複雑な作業である、という事実を直視しなければならないということです。本稿は、オブジェクト指向開発の入門編にすぎません。ここでの目的は、オブジェクト指向開発の複雑さを明らかにし、オブジェクト指向開発の技法そのものだけでなく、各技法の相互の関連についても理解しなければならないという事実を強調することにあります。成功するためには、各企業において、新しい開発ツールや技法やプロセスのほかに、トレーニングや教育や指導のためにも投資が必要になるでしょう。この作業を見くびるべきではありません。オブジェクト指向開発を成功させるのは、かなりの難問なのです。

上に戻る

用語集: オブジェクト指向開発の重要用語

アクティビティー・ダイアグラム (Activity diagram)。 ハイレベルのビジネス・プロセスまたはクラスの状態間の推移をモデリングするための UML ダイアグラム (後者の機能に関する限り、アクティビティー・ダイアグラムは、状態チャート・ダイアグラムの特別版のようなものとも言えます)。

ビジネス・ルール (Business rule)。 各企業の運用上の原則や方針。

変更ケース (Change case)。 システムが将来サポートしなければならなくなるかもしれない潜在的な要件。

変更ケース・モデル (Change-case model)。 システムに当てはまる変更モデルのコレクション。詳細については、「Designing Hard Software」(参考文献) を参照してください。

クラス・ダイアグラム (Class diagram)。 システムの各種クラスとそれぞれの関連を示した UML ダイアグラム。

クラス・モデル (Class model)。 クラス・ダイアグラムとその関連資料。

クラス責任範囲コラボレーター (CRC) カード (Class Responsibility Collaborator (CRC) card)。 3 つのセクションに分かれた標準的な索引カード。1 番目は、カードが表しているクラスの名前を示したセクション、2 番目は、クラスの責任範囲を一覧表示したセクション、3 番目は、このクラスが責任範囲の役割を果たすためにコラボレートする他のクラスの名前を一覧表示したセクションです。

クラス責任範囲コラボレーター (CRC) モデル (Class Responsibility Collaborator (CRC) model)。 システムの全体または一部をモデリングした CRC カードのコレクション。

コラボレーション・ダイアグラム (Collaboration diagram)。 各種クラスのインスタンス、それぞれの相互関係、相互のメッセージ・フローを示した UML ダイアグラム。コラボレーション・ダイアグラムは通常、メッセージをやり取りするオブジェクトの構造的な編成に焦点を合わせています。

コンポーネント・ダイアグラム (Component diagram)。 アプリケーション、システム、企業のいずれかを構成するソフトウェア・コンポーネントを示した UML ダイアグラム。各種コンポーネント、それぞれの相互関係や相互作用、さらにはそれぞれの公用インターフェースが図示されています。

制約 (Constraint)。 ソリューションを提供する上での自由の範囲を限定する制限事項。

デプロイメント・ダイアグラム (Deployment diagram)。 システムのハードウェア、ソフトウェア、ミドルウェアの構成を示した UML ダイアグラム。

エッセンス・モデル (Essential model)。 テクノロジーから離れた理念による抽象的な記述によって問題のエッセンスを取り込むためのモデル。エッセンス・モデリングの詳細については、「Software Use」(参考文献) を参照してください。

エッセンス・ユース・ケース (Essential use case)。 テクノロジーやインプリメンテーションとは別にユーザーの意図を取り込んだ、シンプルで抽象的かつ一般的なユース・ケース。

エッセンス・ユース・ケース・モデル (Essential use-case model)。 エッセンス・ユース・ケースからなるユース・ケース・モデル。

エッセンス・ユーザー・インターフェース・プロトタイプ (Essential user-interface prototype)。 システムのユーザー・インターフェースの基本的な抽象特性をモデリングした、ユーザー・インターフェースの低精度プロトタイプ。

モデル (Model)。 問題ドメインまたは問題ドメインのソリューションの抽象的な記述。伝統的には、ダイアグラムとその関連資料を合わせたものをモデルとみなします。ただし、インタビュー結果や CRC カードのコレクションといったダイアグラム以外のものもモデルとみなされます。

非機能要件 (Non-functional requirements)。 システムが準拠しなければならない規格、規定、契約。システムと連動させる外部システムのインターフェースの記述。パフォーマンス要件。設計やインプリメンテーションにかかわる制約。システムが準拠しなければならない品質特性。

持続モデル (Persistence model)。 ソフトウェア・システムの持続データの側面を記述したモデル。

プロトタイプ (Prototype)。 ユーザー・インターフェースやシステム・アーキテクチャーなどのシミュレーション。何かの方法を採用し、その方法に対して重要なリソースを実際に投資する前に、その方法を他の人々に説明するために使用します。

要件モデル (Requirements model)。 ユース・ケース・モデル、ユーザー・インターフェース・モデル、ドメイン・モデル、変更ケース・モデルのほかに、システムの要件を記述した補足的な仕様などからなる、成果物のコレクション。

シーケンス・ダイアグラム (Sequence diagram)。 シーケンシャル・ロジック (つまりメッセージの時間順) をモデリングした UML ダイアグラム。

状態チャート・ダイアグラム (State chart diagram)。 オブジェクトの状態や各状態間の推移を記述した UML ダイアグラム。以前は、「状態ダイアグラム」または「状態推移ダイアグラム」といいました。

システム・ユース・ケース (System use case)。 対応するエッセンス・ユース・ケースの要件をシステムでどのように満たすかを記述した詳細なユース・ケース。ユーザー・インターフェース設計のいろいろな側面など、インプリメンテーション固有の機能を参照する場合が少なくありません。

システム・ユース・ケース・モデル (System use-case model)。 システム・ユース・ケースからなるユース・ケース・モデル。

ユース・ケース (Use case)。 アクターに対して測定可能な値を提供するアクションのシーケンス。

ユース・ケース・ダイアグラム (Use-case diagram)。 各種ユース・ケース、アクター、それぞれの相互関係を示した UML ダイアグラム。

ユース・ケース・モデル (Use-case model)。 ユース・ケース・ダイアグラム、ユース・ケース定義、アクター定義からなるモデル。ユース・ケース・モデルは、システムの動作要件を記述するために使用します。

ユーザー・インターフェース・フロー・ダイアグラム (User interface-flow diagram)。 システムの各種インターフェース・オブジェクトとそれぞれの関係をモデリングしたダイアグラム。インターフェース・フロー・ダイアグラム、ウィンドウ・ナビゲーション・ダイアグラム、インターフェース・ナビゲーション・ダイアグラムともいいます。

ユーザー・インターフェース・フロー・ダイアグラム (User interface-flow diagram)。 システムの各種インターフェース・オブジェクトとそれぞれの関係をモデリングしたダイアグラム。インターフェース・フロー・ダイアグラム、ウィンドウ・ナビゲーション・ダイアグラム、インターフェース・ナビゲーション・ダイアグラムともいいます。

ユーザー・インターフェース・モデル (User-interface model)。 ユーザー・インターフェース・プロトタイプ、ユーザー・インターフェース・フロー・ダイアグラム、ユーザー・インターフェースの関連資料からなるモデル。

ユーザー・インターフェース・プロトタイプ (User-interface prototype)。 システムのユーザー・インターフェース (UI) のプロトタイプ。ユーザー・インターフェース・プロトタイプには、手書きの図のようなシンプルなものから、プログラミングした画面やページやレポートのコレクションといった複雑なものまであります。

参考文献

• Building Object Applications That Work: Your Step-By-Step Handbook for Developing Robust Systems with Object Technology、Scott W. Ambler 著 (New York: Cambridge University Press)
  
  
• Process Patterns -- Building Large-Scale Systems Using Object Technology、Scott W. Ambler 著 (New York: Cambridge University Press)
  
  
• More Process Patterns -- Delivering Large-Scale Systems Using Object Technology、Scott W. Ambler 著 (New York: Cambridge University Press)
  
  
• The Object Primer 2nd Edition -- The Application Developer's Guide to Object-Orientation、Scott W. Ambler 著 (New York: Cambridge University Press)
  
  
• The Process Patterns Resource Page、Scott Ambler 著
  
  
• 「Toward a UML Profile for a Relational Persistence Model」、Scott W. Ambler 著
  
  
• Testing Object-Oriented Systems: Models, Patterns, and Tools、R. Binder 著 (Reading, MA: Addison Wesley Longman, Inc.)
  
  
• Software Use: A Practical Guide to the Models and Methods of Usage-Centered Design、L.L. Constantine、L.A.D. Lockwood 共著 (New York: ACM Press)
  
  
• Fundamentals of Object-Oriented Design in UML、M. Page-Jones 著 (New York: Dorset-House Publishing)
  
  
• The Unified Modeling Language Reference Manual、J. Rumbaugh、I. Jacobson、G. Booch 共著 (Reading, MA: Addison Wesley Longman, Inc.)
  
  
• Applying Use Cases: A Practical Guide、G. Schneider、J.P. Winters 共著 (Reading, MA: Addison Wesley Longman, Inc.)
  
  
• Software Requirements、K. Wiegers 著 (Redmond, WA: Microsoft Press)
  
  
• IBM SanFrancisco
  
  
• Enterprise JavaBeans テクノロジー
  
  
• CORBA Web サイト
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• オブジェクト指向の要件エンジニアリング
• オブジェクト指向の分析
• オブジェクト指向の設計
• オブジェクト指向のプログラミング
• オブジェクト指向のテスト
• オブジェクト指向開発の複雑さ
• 用語集: オブジェクト指向開発の重要用語
• 参考文献
• 著者について
• コメント