 |
【連載】Javaオブジェクトモデリング INDEX |
| 本連載は、Javaプログラミングが一通りできて、UMLの基本的な文法を一通り知っているプログラマを対象に、オブジェクト指向開発の流れの中におけるUMLとJavaの関係について説明するものです。また、オブジェクト指向開発プロセスはマスターしているものの、Javaによる開発はこれからという方にも有益でしょう。
UMLによるオブジェクトモデルとJavaの関係が重要になるのは、以下の2点です。
「設計モデルとJavaプログラムのマッピング」は、まさにUMLからJavaへの落とし込みのところですから重要なのは当然です。一方、「システム分析モデルと設計モデルのマッピング」においてJavaが登場するのは、設計モデルが実装環境であるJavaを意識したものだからです。本連載では前者の「設計モデルとJavaプログラムのマッピング」を主要テーマとして展開していきます。 なお、本連載は、「静的モデル」「動的モデル」「物理モデル」という3つの大きな切り口で構成されます。この大枠に沿いながら、UMLによるオブジェクトモデルとJavaとの対応関係について説明していきます。 |
| UMLによる設計モデルとJavaプログラムの相互変換は、かなり自動的に行うことができるようになってきたといえる。つまりUMLを使った設計は、半分はJavaプログラミングであると考えられる。逆に、Javaプログラミングはオブジェクトモデリングそのものであるという考え方も成立するだろう。そうすると、UML設計をせずにいきなりJavaプログラミングをするというアプローチにも説得力がある。 もちろん小規模のプログラムでは、Javaプログラミングだけでも十分に機能する。しかし、ある程度の規模の製品を複数メンバーのチームで開発する場合は、UMLのモデリングなしでは考えられない。それは、ソースコードしか存在しない開発では、メンバー間でモデルの共有ができないからだ。メンバー間でモデルの共有ができないということは、開発の基盤となるアーキテクチャの策定ができないことであり、プログラムの質を高めるうえで極めて重要な作業であるレビューができないということでもある。これでは一定の質を保ったプログラムを作成し続けることはできない。さらに、プログラムの保守を行うチームに対する情報の伝達もまったくできないことになる。 製品開発では、開発時の効率だけでなく、保守フェーズを含めた製品のライフサイクル全体における効率が非常に重要である。つまり、場所や時間を超えて開発メンバー間で共有できるモデルの存在が不可欠であり、UMLによるモデリングは必須の作業といえるだろう。 UMLで作成したモデルをJavaプログラムに落とし込むことは、一見機械的な作業のようで、具体的な手順はなかなか一筋縄ではいかない。UMLとJavaの関係を考えるには、UMLとJavaの個々の技術だけでなく、UMLとJavaの接点となるモデル体系の理解が必要である。さらにこのモデル体系を理解するためには、オブジェクト指向開発プロセスの理解が必要となってくる。 |
||
| 1. 連載のはじめに | ||
| 2. 問題の構造 | ||
| 3. UML（図の分類） | ||
| 4. 開発プロセス | ||
| 4.1 イテレーションとフェイズ | ||
| 4.2 本連載の工程モデル | ||
| 5. オブジェクト指向開発におけるモデル体系 | ||
| 5.1 開発プロセスとモデル | ||
| 5.2 Javaとの関係 | ||
| 5.3 フォワードエンジアリングとリバースエンジニアリング | ||
| 5.4 コンポーネントとの関係 | ||
| 6. Java開発におけるオブジェクトモデリングの意義 | ||
| 第2回 静的モデルの全体像 | ||
| 第2回はUMLの静的モデルとJavaの静的モデルについて概観する。UMLの静的モデルはクラス図とオブジェクト図で記述されるが、Javaとのマッピングを考えるうえでは、クラス図のみを検討対象にすれば十分である。 クラス図はオブジェクト指向開発プロセスにおいて、さまざまな形で用いられる。この中で、設計ワークフローで作成されるクラス図がJavaと直接関係を持ってくる。 設計ワークフローにおけるクラス図は、Javaでの実装をターゲットにしたものになる。Javaの言語機能を正確にモデル化するようクラス図の持っている機能を取捨選択し、必要であれば機能を拡張して使用する必要がある。つまり、Javaをターゲットとした設計ワークフローのクラス図は、クラス図のJava向けプロファイルとなるわけだ。 Javaは、クラスとインターフェイスを核にした言語仕様になっており、静的モデルもクラスとインターフェイスを起点にして記述される。 |
||
| 1. UMLの静的モデル | ||
| 2. モデルの流れ | ||
| 3. クラス図の変遷 | ||
| 3.1 ドメイン分析 | ||
| 3.2 システム分析 | ||
| 3.3 設計 | ||
| 3.3.1 名前 | ||
| 3.3.2 アクセサとミューテータ | ||
| 3.3.3 多重度 | ||
| 3.3.4 可視性 | ||
| 3.3.5 アソシエーションロール | ||
| 3.4 クラス図とJava | ||
| 4. クラス図のモデル | ||
| 4.1 クラス | ||
| 4.1.1 クラスの構成 | ||
| 4.1.2 クラスの種類 | ||
| 4.2 リレーションシップ | ||
| 4.3 パッケージ | ||
| 5. Javaの静的モデル | ||
| 5.1 クラス | ||
| 5.2 インターフェイス | ||
| 第3回 静的モデル：クラスにおけるUMLとJavaのマッピング（1） | ||
| “クラス”は、UMLとJavaでほとんど同じ構造になっており、簡単なクラス図を書くことが目的であればマッピングは比較的簡単に行える。しかし、CASEツールでの自動マッピングなどをターゲットにして、厳密にマッピングを考えていくと、UMLの複雑な部分も見えてくる。UMLの仕様が膨大であるうえに、UMLとJavaのモデルが微妙にズレている点もあるからだ。 この問題に対応するためには、Javaとのマッピングに使用するUMLの仕様を絞り込んだうえで、UMLの仕様にないJavaの機能をステレオタイプやプロパティなどの拡張メカニズムを使って、拡張していく必要がある。もちろん、このような拡張を行う場合には、用途に応じてプロファイルとしてまとめていくことが必要である。そして、このプロファイルを開発チームの中でのルールとして利用することで、UMLを用いたコミュニケーションを円滑に行うことができるようになる。 第3回、第4回は、オブジェクトの核となるモデル要素であるクラスについて、JavaとUMLのマッピングを検討するために必要な論点を明らかにしたうえで、サンプルのプロファイルを作成した。このプロファイルは筆者の好みが大きく反映されてるが、一般的な開発ではそのまま利用できるのではないかと思う。もちろん、実際の開発に当たっては、利用するCASEツールとの整合性といった要因を考慮に入れてチューニングしていくとよい。 |
||
| 1. 分類子と“クラス” | ||
| 2. UMLの“クラス” | ||
| 2.1 クラス | ||
| 2.1.1 アイコン | ||
| 2.1.2 メタモデル | ||
| 2.1.3 ステレオタイプ | ||
| 2.1.4 プロパティ | ||
| 2.1.5 Javaで利用するUMLクラスの種類 | ||
| 2.2 インターフェイス | ||
| 2.2.1 アイコン | ||
| 2.2.2 メタモデル | ||
| 2.2.3 ステレオタイプ | ||
| 2.2.4 プロパティ | ||
| 2.3 例外 | ||
| 2.3.1 アイコン | ||
| 2.3.2 メタモデル | ||
| 2.3.3 ステレオタイプ | ||
| 2.3.4 プロパティ | ||
| 2.4 UML属性のメタモデル | ||
| 2.5 UMLオペレーションのメタモデル | ||
| 2.5.1 ステレオタイプ | ||
| 2.5.2 プロパティ | ||
| 3. Javaの“クラス” | ||
| 3.1 クラス | ||
| 3.2 クラスの種類 | ||
| 3.3 インターフェイス | ||
| 3.4 インターフェイスの種類 | ||
| 3.5 メソッド | ||
| 3.6 コンストラクタ | ||
| 3.7 属性 | ||
| 3.7.1 用途による分類 | ||
| 3.7.2 格納方法による分類 | ||
| 3.7.3 属性に相当する変数 | ||
| 第4回 静的モデル：クラスにおけるUMLとJavaのマッピング（2） | ||
| 4. “クラス”のマッピング | ||
| 4.1 クラスのマッピング | ||
| 4.1.1 共通の部品 | ||
| 4.1.2 要検討の部品 | ||
| 4.1.3 Javaのみの部品 | ||
| 4.1.4 UMLのみの部品 | ||
| 4.2 インターフェイスのマッピング | ||
| 4.2.1 共通の部品 | ||
| 4.2.2 Javaのみの部品 | ||
| 4.2.3 UMLのみの部品 | ||
| 4.3 “クラス”の種類 | ||
| 4.3.1 普通のクラス | ||
| 4.3.2 metaClass | ||
| 4.3.3 thread | ||
| 4.3.4 utility | ||
| 4.3.5 インターフェイス | ||
| 4.3.6 シグナル | ||
| 4.3.7 例外 | ||
| 4.4 その他のJava“クラス” | ||
| 4.4.1 java.lang.Object | ||
| 4.4.2 java.lang.String | ||
| 4.4.3 配列 | ||
| 4.4.4 java.lang.Cloneable | ||
| 4.4.5 java.lang.Runnable | ||
| 4.4.6 java.io.Serializable | ||
| 4.4.7 java.io.Externalizable | ||
| 5. 属性のマッピング | ||
| 5.1 属性の種類 | ||
| 5.2 部品のマッピング | ||
| 5.2.1 共通の部品 | ||
| 5.2.2 要検討の部品 | ||
| 5.2.3 Javaのみの部品 | ||
| 5.2.4 UMLのみの部品 | ||
| 6. オペレーションのマッピング | ||
| 6.1 オペレーションの種類 | ||
| 6.2 部品のマッピング | ||
| 6.2.1 共通の部品 | ||
| 6.2.2 要検討の部品 | ||
| 6.2.3 Javaのみの部品 | ||
| 6.2.4 UMLのみの部品 | ||
| 7. サンプルプロファイル | ||
| 7.1 クラス | ||
| 7.1.1 具象クラス | ||
| 7.1.2 抽象クラス | ||
| 7.1.3 インターフェイス | ||
| 7.1.4 ユーティリティ | ||
| 7.1.5 例外 | ||
| 7.2 属性 | ||
| 7.2.1 種類のマッピング | ||
| 7.2.2 部品のマッピング | ||
| 7.3 属性のマッピング例 | ||
| 7.3.1 プリミティブ型属性 | ||
| 7.3.2 オブジェクト属性 | ||
| 7.3.3 初期化 | ||
| 7.3.4 クラス変数 | ||
| 7.4 オペレーション | ||
| 7.4.1 種類のマッピング | ||
| 7.4.2 部品のマッピング | ||
| 7.5 オペレーションのマッピング例 | ||
| 7.5.1 インスタンスメソッド | ||
| 7.5.2 引数のあるインスタンスメソッド | ||
| 7.5.3 復帰値がvoid型のインスタンスメソッド | ||
| 7.5.4 例外のあるインスタンスメソッド | ||
| 7.5.5 抽象メソッド | ||
| 7.5.6 クラスメソッド | ||
| 7.5.7 final | ||
| 7.5.8 native | ||
| 8. マッピング例 | ||
| 8.1 具象クラス | ||
| 8.2 抽象クラス | ||
| 8.3 インターフェイス | ||
| 8.4 インターフェイスと定数 | ||
| 8.5 ユーティリティ | ||
| 8.6 ファクトリ | ||
| 8.7 内部データ | ||
| 第5回 静的モデル：データ型におけるUMLとJavaのマッピング（1） | ||
| クラス図の中核となるモデル要素は分類子だが、この分類子の一種にデータ型がある。 データ型とJavaの関係は一見簡単そうに見えるが、まじめに考え出すとなかなか奥の深いテーマである。第5回、第6回は、オブジェクト指向におけるデータの扱いを視野に入れたうえで、UMLのデータ型とJavaのマッピングについて説明する。 | ||
| 1. オブジェクトとデータ | ||
| 1.1 オブジェクトとデータの違い | ||
| 2. UMLにおけるデータの位置付け | ||
| 2.1 分類子とデータ型 | ||
| 2.2 合成集約と属性 | ||
| 3. Javaにおけるデータの位置付け | ||
| 3.1 プリミティブ型と参照型 | ||
| 3.2 事実上のデータ型 | ||
| 3.3 Javaのデータ型 | ||
| 3.4 バリューオブジェクトの導入 | ||
| 3.4.1 変数の更新（プリミティブ型） | ||
| 3.4.2 変数の更新（オブジェクト） | ||
| 3.4.3 データの比較（プリミティブ型） | ||
| 3.4.4 データの比較（オブジェクト） | ||
| 第6回 静的モデル：データ型におけるUMLとJavaのマッピング（2） | ||
| 4. Javaによるデータ型の実装 | ||
| 4.1 イミュータブルオブジェクト | ||
| 4.2 equalsメソッド | ||
| 4.3 その他 | ||
| 4.3.1 toStringメソッド | ||
| 4.3.2 Stringを引数にしたコンストラクタ | ||
| 4.3.3 java.lang.Cloneable | ||
| 4.3.4 java.io.Serializable | ||
| 4.3.5 java.lang.Comparable | ||
| 4.4 バリューオブジェクトの実例 | ||
| 4.4.1 java.lang.String | ||
| 4.4.2 java.lang.Integer | ||
| 5. バリューオブジェクトの実装例 | ||
| 5.1 Point | ||
| 5.1.1 必須 | ||
| 5.1.2 推奨 | ||
| 5.1.3 参考 | ||
| 5.2 値として操作してみる | ||
| 6. サンプルプロファイル | ||
| 6.1 UMLとJavaのマッピングの論点 | ||
| 6.2 サンプルプロファイル | ||
| 6.3 コラム：“データ型”と“クラス” | ||
| 6.4 記法 | ||
| 6.4.1 プリミティブ型 | ||
| 6.4.2 バリューオブジェクト | ||
| 第7回 静的モデル：リレーションシップ（1） | ||
| 静的モデルの基本となるモデル要素は分類子（classifier）とリレーションシップ（relationship、関係）である。その分類子の中でも特に重要な分類子であるクラス、インターフェイス、データ型については、第3回から第6回までの4回にわたって取り上げてきた。第7回、第8回はリレーションシップの詳細を検討する。 | ||
| 1. リレーションシップとは何か | ||
| 2. UMLのリレーションシップ | ||
| 2.1 Association | ||
| 2.2 Generalization | ||
| 2.3 Flow | ||
| 2.4 Dependency | ||
| 3. UMLノーテーションからみたリレーションシップ | ||
| 第8回 静的モデル：リレーションシップ（2） | ||
| 4. リレーションシップの全体像 | ||
| 4.1 リレーションシップの関係 | ||
| 4.2 アソシエーションの用語法 | ||
| 4.3 ディペンデンシィの用語法 | ||
| 5. 各リレーションシップの機能 | ||
| 5.1 アソシエーション | ||
| 5.2 集約 | ||
| 5.3 合成集約 | ||
| 5.4 汎化 | ||
| 5.5 リアライゼーション | ||
| 5.6 ディペンデンシィ | ||
| 5.7 クラス図の例 | ||
| 第9回 静的モデル：アソシエーションの基本概念 | ||
| UMLとJavaは同じオブジェクト指向のカテゴリにある技術だが、オブジェクト指向モデルとオブジェクト指向プログラミングの微妙な機能差を反映する形で、具体的な部品レベルでは細かな相違が多数ある。この細かな相違がUMLとJavaのマッピングを考えるうえでのハードルとなるわけだが、第9回で検討するアソシエーションはそのハードルの1つということができる。 このハードルをクリアするための準備として、今回はアソシエーションのマッピングを考えるうえでの枠組み、UMLアソシエーションとJavaのマッピングに関する基本構造について整理した。 |
||
| 1. アソシエーションとは何か | ||
| 2. UMLにおけるアソシエーション | ||
| 2.1 メタモデル | ||
| 2.2 ノーテーション | ||
| 3. Javaにおけるアソシエーション | ||
| 3.1 変数 | ||
| 3.2 クラス | ||
| 3.2.1 配列 | ||
| 3.2.2 コレクションライブラリ | ||
| 3.2.3 その他のクラス | ||
| 4. アソシエーションのマッピングを考える | ||
| 4.1 UMLのメタモデルをJavaで忠実に再現した場合 | ||
| 4.2 最もシンプルな例 | ||
| 5. UMLの観点からマッピングを考える | ||
| 第10回 静的モデル：アソシエーションエンドの部品 | ||
| 「第9回
静的モデル：アソシエーションの基本概念」は、アソシエーションの基本概念とJavaとの関係について説明しました。今回から数回に渡り、UMLアソシエーションを構成する各種部品とJavaとのマッピングについて、具体的に検討していきます。 さて、UMLノーテーション上のアソシエーションは、「アソシエーション」「アソシエーション・エンド」「限定子を示す属性」という3つの部品で構成されていますが、それぞれの部品はさらに、細かい部品の集合となっています。 UMLにおけるアソシエーションの部品は、主にアソシエーション・エンドに関連付けられている以下のものです。
誘導可能性（isNavigable） 可視性（visibility） ターゲット・スコープ（目標範囲、targetScope） 集約（aggregation） 多重度（multiplicity） 順序付け（ordering） 変更可能性（changeability） 限定子（qualifier） インターフェース指定子（interface specfication） |
||
| 1. アソシエーションの部品 | ||
| 1.1 アソシエーション本体の部品 | ||
| 1.2 アソシエーション・エンドの種類 | ||
| 2. アソシエーション・エンドの部品 | ||
| 2.1 ロール名 | ||
| 2.1.1 UMLでの表現 | ||
| 2.1.2 Javaでの実現 | ||
| 2.1.3 2つのアソシエーション | ||
| 2.1.4 両端にロール名がある場合 | ||
| 2.2 誘導可能性 | ||
| 2.2.1 UMLでの表現 | ||
| 2.2.2 Javaでの実現 | ||
| 2.2.3 両端に誘導可能性がある場合 | ||
| 2.3 可視性 | ||
| 2.3.1 UMLでの表現 | ||
| 2.3.2 Javaでの実現 | ||
| 第11回 静的モデル：アソシエーションの付加情報 | ||
| 「第10回 静的モデル：アソシエーションエンドの部品」は、アソシエーション・エンドに関連付けられている10個の要素のうち、基本部品「ロール名（rolename）」「誘導可能性（isNavigable）」「可視性（visibility）」までを解説しました。今回は基本部品の残りである「ターゲット・スコープ（目標範囲、targetScope）」に加え、JavaとUMLマッピングで重要となるアソシエーションの付加情報として「集約（aggregation）」「多重度（multiplicity）」「順序付け（ordering）」までを解説します。 | ||
| 2.4 ターゲット・スコープ | ||
| 2.4.1 UMLでの表現 | ||
| 2.4.2 Javaでの実現 | ||
| 2.5 基本部品 | ||
| 2.6 集約 | ||
| 2.6.1 UMLでの表現 | ||
| 2.6.2 Javaでの実装 | ||
| 2.7 多重度 | ||
| 2.7.1 UMLでの表現 | ||
| 2.7.2 Javaでの実現 | ||
| 2.8 順序付け | ||
| 2.8.1 UMLでの表現 | ||
| 2.8.2 Javaでの実現 | ||
| 静的モデル：アソシエーションのUML部品のまとめ | ||
| 今回は、アソシエーションの残りの付加情報「変更可能性（changeability）」「限定子（qualifier）」「インターフェイス指定子（interface specification）」まで解説し、アソシエーションにおけるUMLの部品の解説をまとめます。 | ||
| 2.9 変更可能性 | ||
| 2.9.1 UMLでの表現 | ||
| 2.9.2 Javaでの実現／frozen | ||
| 2.9.3 Javaでの実現／addOnly | ||
| 2.10 限定子 | ||
| 2.10.1 UMLでの表現 | ||
| 2.10.2 Javaでの実現 | ||
| 2.11 インターフェイス指定子 | ||
| 2.11.1 UMLでの表現 | ||
| 2.11.2 Javaでの実現 | ||
| 2.12 UML部品のまとめ | ||
| 静的モデル：アソシエーションのJavaの部品 | ||
| 前回までは4回にわたって、アソシエーションに関するUMLの部品について詳細な検討を行ってきました。そもそもその目的は、UMLアソシエーションとJavaのマッピングをスムーズに実現させることにあるのですが、これがなかなか難しい作業です。以前検討した、UMLのクラスとJavaのクラスのマッピングも細かく考えていくと大変な作業でした（「第3回 静的モデル：クラスにおけるUMLとJavaのマッピング（1）」）。ですが、クラスはUMLとJavaにおいて多少の機能差があるとはいえ、同じ部品が用意されているため、UMLのみにあるモデル要素のアソシエーション（Java側には直接対応する部品がない）と比べて楽な作業であるともいえます。それでは、いよいよ今回は、Java側のアソシエーションに関する部品の検討を行っていきましょう。 | ||
| 3.アソシエーションに関するJavaの部品 | ||
| 3.1 インスタンス変数とクラス変数 | ||
| 3.2 配列 | ||
| 3.3 コレクション | ||
| 3.3.1 Collection | ||
| 3.3.2 List | ||
| 3.3.3 Set | ||
| 3.3.4 SortedSet | ||
| 3.3.5 Map | ||
| 3.3.6 SortedMap | ||
| 3.4 Java部品のまとめ | ||
| 第14回 静的モデル：Javaを前提としたUMLアソシエーション | ||
| 前回「第13回
静的モデル：アソシエーションのJavaの部品」はUMLの観点からの部品、Javaの観点からの部品について確認をしてきました。今回は、これらの部品を組み合わせて、Javaプログラムを前提としたUMLアソシエーションのプロファイルについて考えていきます。UMLアソシエーションのプロファイルに関する全体の構成は以下のようになります。
4.1 方針 今回は「4.5 多重度」までを解説します。 |
||
| 4 プロファイル | ||
| 4.1 方針 | ||
| 4.1.1 アソシエーション本体 | ||
| 4.1.2 アソシエーション・エンド | ||
| 4.2 変数のマッピング | ||
| 4.3 必須の部品 | ||
| 4.3.1 UMLでの表現 | ||
| 4.3.2 Javaでの実装 | ||
| 4.4 集約 | ||
| 4.4.1 UMLでの表現 | ||
| 4.4.2 Javaでの実装 | ||
| 4.5 多重度 | ||
| 4.5.1 UMLでの表現 | ||
| 4.5.2 Javaでの実装（1） | ||
| 4.5.3 Javaでの実装（2） | ||
| 第15回 静的モデル：「順序付け」から「インターフェイス指定子」まで | ||
| 4.6 順序付け | ||
| 4.6.1 UMLでの表現 | ||
| 4.6.2 Javaでの実装／制約ordered | ||
| 4.6.3 Javaでの実装／制約sorted | ||
| 4.7 変更可能性 | ||
| 4.8 限定子 | ||
| 4.8.1 UMLでの表現 | ||
| 4.8.2 Javaでの実装 | ||
| 4.9 インターフェイス指定子 | ||
| 4.9.1 UMLでの表現 | ||
| 4.9.2 Javaでの実装 | ||
（続く）
 |
IT Architect 連載記事一覧 |
アーキテクチャ 新着記事
＠IT情報マネジメント 新着記事
この記事に対するご意見をお寄せください managemail@atmarkit.co.jp
スポンサーからのお知らせ
転職／派遣情報を探す
「ITmedia マーケティング」新着記事
「AIによる顧客体験（CX）向上」に懐疑的な見方が広がる――Qualtrics調査
Qualtricsが実施した年次グローバル調査から見えたカスタマーエクスペリエンス（CX）の現...
2025年のSNS大予測 AIの時代に「ソーシャル」はどう変わる？
もういくつ寝ると2025年……と数えるのはさすがに気が早いかもしれないが、それでも2024...
SEOで陥りがちな失敗は「アルゴリズム変更に対応できなかった」が最多に 原因は？
SEOの成功には何が必要なのか、失敗経験者へのアンケートで浮き彫りになったこととは……。
