連載

Javaオブジェクトモデリング

第1回　連載を読む前に知っておくべきこと

　

5.オブジェクト指向開発におけるモデル体系

　オブジェクト指向開発におけるモデル体系を、コアワークフローとの関係を軸に説明します。

■■5.1 開発プロセスとモデル■■

　オブジェクト指向で用いるモデルには数々の切り口がありますが、本連載では「静的モデル」「動的モデル」「物理モデル」の3つをビューとして用いることにします。

　静的モデルは、UML図の分類で「静的・論理的」として分類したモデルで、クラス図とオブジェクト図から構成されます。実質的にはクラス図で記述するモデルと考えてよいでしょう。

　動的モデルは、「動的・論理的」として分類したモデルで、コラボレーション図、シーケンス図、ステートチャート図、ユースケース図、アクティビティ図から構成されます。動的モデルの記述におけるこれらの図の使い分けが、オブジェクト指向開発のポイントの1つとなります。

　物理モデルは、「静的・物理的」として分類したモデルです。JavaBeansやEnterprise JavaBeansなどのコンポーネントと関係が深いモデルなので、連載テーマの1つとして取り上げます。

　これらのモデルと開発プロセスの関係は図5のとおりです。もちろん、実際にはもっと複雑で絡み合った関係を持っているのですが、単純化するとこのようになります。

図5　開発プロセスとモデル

　この中でJavaとモデルの関係が出てくる個所は2つです。1つは明白で、設計モデルからJavaクラスへのマッピングです。もう1つは、システム分析モデルから設計モデルを構築する作業です。というのは、設計モデルはJavaによる実装を前提としたモデルになるからです。つまり設計モデルの作成は、ある意味Javaプログラミングであるともいえるわけです。

■■5.2 Javaとの関係■■

　UMLとJavaの関係を考えるうえで最も重要な点は、静的モデルや動的モデルとして作成されたモデルが、Javaクラスという1点に集約されることです。つまり、複数のUML図の情報を重層的に積み重ねて1つのJavaクラスを実装するということになるのです。

　静的モデルは実質的にはクラス図だけですから、Javaとの関係は分かりやすくなっています。それに対し動的モデルは、複数の図を使って重層的に表現されるモデルとJavaの関係を明確にしなければならないため、それほど簡単ではありません。モデルとJavaクラスの関係は、図6のようになります。

図6　モデルとJavaクラスの関係

　クラスそのものは、UMLによる設計モデルのものとJavaプログラムのものでは同じになります。

　オブジェクトの静的側面である属性やリレーションシップは、クラス図の情報からJavaクラスのインスタンス変数やクラス変数にマッピングされます。このマッピングは仕様がはっきりしており、CASEツールを使えば自動生成が可能なレベルのものです。ツールを使わずプログラミングを行う場合も、ルーチンワーク的な作業となるでしょう。

　それに対し、オブジェクトの動的側面であるオペレーションの実装は自動的というわけにはいきません。シグネチャについてはクラス図で定義されたものをそのままマップできますが、オペレーションの挙動については手作業でプログラミングすることになります。

■■5.3 フォワードエンジニアリングとリバースエンジニアリング■■

　UMLによるオブジェクトモデルとJavaプログラムとの相互変換をCASEツールなどで自動化する技術が実用フェーズに入ってきています。この技術分野ではフォワードエンジニアリングとリバースエンジニアリングという用語が用いられます。

　フォワードエンジニアリングとは、モデルをプログラミング言語による実装に変換する処理です。本連載のケースでは設計モデルからJavaプログラムを生成する処理となります。それに対してリバースエンジニアリングとは、プログラミング言語による実装をモデルに変換する処理です。本連載のケースではJavaプログラムから設計モデルを生成する処理となります。Javaにおけるフォワードエンジニアリング／リバースエンジニアリングの関係は、図7のとおりです。

図7　モデルの変換

　Javaクラスとその静的構造については、設計モデルの静的モデルと完全に相互変換が可能です。しかし、Javaクラスの動的挙動については、設計モデルとのマッピングに以下のような制約があります。

• 一部の情報（メソッドのシグネチャ）のみ設計モデルの動的モデルから生成可能
• 動的モデルのリバースエンジニアリングはできない

　フォワードエンジニアリングが完全にできればプログラミングは不要となるわけですが、現在の技術レベルではそこまでに至っていません。

■■5.4 コンポーネントとの関係■■

　「コンポーネント」という用語にはいろいろな意味がありますが、UMLに沿った用語法では「システムの物理的な構成物」ということになります。JavaBeansやEnterprise JavaBeansといったJavaにおけるコンポーネント部品も、UMLのコンポーネントの定義に当てはまります。ただUMLのコンポーネントの定義は幅広く、物理的な構成物であれば再利用可能なコンポーネント部品以外のもの（例えばソースコードや仕様書）もコンポーネントと呼びます。しかし、本連載ではJavaプログラム開発におけるコンポーネント部品が対象なので、基本的にJavaBeansやEnterprise JavaBeansをUMLのコンポーネントに対応するものとして考えます。

　図8は、UMLにおけるサブシステムとコンポーネントの関係を表しています。ソフトウェアを構成する部品は、モデルの論理的なビューの中ではサブシステム（パッケージ）として表現されます。また、モデルの物理的なビューの中ではコンポーネントとして表現されます。

図8　サブシステムとコンポーネント

　図9は、開発プロセスにおけるコンポーネントの位置付けを表しています。システム分析の段階では、論理的なモデルのみが存在しています。設計ワークフローでは、Javaによる実装を意識したモデリングを行うことになります。論理モデルの中では、サブシステムをJavaでの実装に適した形で詳細化していきます。さらにこの段階で物理モデルが登場し、JavaBeansやEnterprise Beanなどのコンポーネントとしてモデル化されていくわけです。

図9　開発プロセスとコンポーネント

　Javaによる実装では、論理モデルとしてJavaクラスがプログラミングされますが、これを物理的にJARファイルとしてまとめてコンポーネント化することになります。

4/5

Javaオブジェクトモデリング　第1回
	連載のはじめに
	UML（図の分類）
	開発プロセス
	オブジェクト指向開発におけるモデル体系
	Java開発におけるオブジェクトモデリングの意義

Javaオブジェクトモデリング INDEX

IT Architect 連載記事一覧