連載
Javaオブジェクトモデリング
第3回
静的モデル:クラスにおけるUMLとJavaのマッピング(1)
2.UMLの “クラス” |
本節ではUMLの “クラス”として、以下の3つの分類子の構造について見ていきます。
- クラス
- インターフェイス
- 例外
クラスは分類子の一種であり、クラス図における中核的なモデル要素です。
●2.1.1 アイコン
UMLでは、クラスを示すアイコンは、前回ご紹介したとおり図3に示したものです。文章ではなく図なので、大量の情報がコンパクトにまとめられています。
図3 クラスアイコン |
クラスアイコンは、複数の区画から構成されます。1番上にあるのが「名前区画(name compartment)」です。その下に、属性用の「並び区画(list compartment)」、オペレーション用の並び区画が続いています。並び区画は利用者の目的によっていくつ使ってもよいのですが、属性用とオペレーション用のものがUMLの標準仕様で定義されています。
●2.1.2 メタモデル
クラスアイコンから分かるUMLクラスのメタモデルは図4となります。このメタモデルを前提に、UMLクラスの構成について調べていきましょう。なお、このメタモデルは本連載の説明用のもので、UMLの定義する正式なメタモデルとは異なっています。
図4 クラスメタモデル |
図4のUMLクラスのメタモデルは、UMLクラスが以下の構造になっていることを示しています。
- パッケージに所属していないか、1つのパッケージに所属しているかのいずれか
- 1つの可視性を持っている
- 1つのクラス名を持っている
- ステレオタイプを0個以上複数個持っている
- 要素プロパティを1つ持っていることがある
- 要素プロパティは0個以上複数個のプロパティを持っている
- 0個以上複数個の属性を持っている
- 0個以上複数個のオペレーションを持っている
UMLのクラスはオブジェクト指向という観点から見るとオーソドックスな構成になっています。ステレオタイプや要素プロパティといった拡張機構を使って、クラスをチューニングして使用することが前提になっているわけです。
●2.1.3 ステレオタイプ
下記の表にUMLの標準仕様で定められているクラス用の標準ステレオタイプを示します。下記の表では、ステレオタイプとその意味に加えて、UML1.3およびUML1.4での定義状況、Javaでの利用とその理由を示しています。
ステレオタイプ | 意味 | 1.3 | 1.4 | Java | 理由 |
metaClass | メタクラス | ○ | ○ | ○ | Javaに対応機能あり |
powertype | パワータイプ | ○ | ○ | - | Javaの言語仕様外 |
process | 重量な実行コンテキスト(UNIXのプロセスに相当) | ○ | ○ | - | Javaの言語仕様外 |
thread | 軽量な実行コンテキスト(UNIXのスレッドに相当) | ○ | ○ | ○ | Javaに対応機能あり |
utility | ユーティリティ | ○ | ○ | ◎ | Javaで実装可能 |
auxility | 補助的に用いられるクラス | - | ○ | △ | 補助的に利用 |
focus | コアロジックやコアコントロールフローを定義するためのクラ ス | - | ○ | △ | 補助的に利用 |
implementation | 実装クラス | - | ○ | - | 分析モデルと設計モデルの関係を示す場合に利 用 |
implementation Class |
実装クラス | ○ | - | - | 分析モデルと設計モデルの関係を示す場合に利 用 |
type | タイプ | ○ | ○ | - | 分析モデルと設計モデルの関係を示す場合に利 用 |
これらの標準ステレオタイプから、Java向けの設計モデルで利用するものを絞り込みます。
typeとimplementationClass(UML 1.4ではimplementation)は、分析レベルのクラス(type)と設計レベルのクラス(implementationClass)を対比させる場合に使用するステレオタイプです。Javaの設計モデルに直接利用することはあまりないので、本連載の検討対象とはしません。
metaClassは、「そのインスタンスがクラスであるクラス」、すなわちメタクラスを示すステレオタイプです。Javaではjava.lang.Classがこのメタクラスに相当します。Smalltalkなどの言語ではメタクラスを操作することでさまざまなテクニックを用いることができるのですが、Javaではメタクラスを直接操作するような処理を行うことができないため、設計モデルの作成においてはあまり重要度の高いモデル要素ではありません。
powertypeは、「そのインスタンスがほかのタイプのサブタイプであるタイプ」、すなわちパワータイプを示すステレオタイプです。分析レベルのステレオタイプなので、本連載の検討対象外です。
processは “重要な実行コンテキスト”というと分かりにくいですが、UNIXにおけるプロセスに相当する実行単位を示すステレオタイプです。Javaのクラスには直接相当する機能がないので、本連載の検討対象外です。
threadはUNIXにおけるスレッドに相当する実行単位を示すステレオタイプです。Javaではjava.lang.Treadを用いて実現することができます。。
utilityは、インスタンスオブジェクトを持たず、クラススコープのオペレーションや属性を持つクラスです。Javaで直接相当する言語仕様はありませんが、Javaで実装することは可能です。
auxilityとfocusはUML 1.4で新規に導入されたステレオタイプです。この2つのステレオタイプはJavaの設計モデルでも利用できますが補助的に用いられるものであり、UMLとJavaとのマッピングには影響を与えないと考えられるので、本連載の検討対象とはしません。
以上の検討の結果、本連載で検討対象とするクラス用ステレオタイプは以下のものとなります。
- metaClass
- thread
- utility
クラスの標準ステレオタイプ
|
UMLのメタモデル上は、クラスは分類子の一種となっています。分類子はmetaClass、 powertype、
process、 thread、 utilityの5つのステレオタイプを 定義しており、このステレオタイプがそのままクラスにも引き継がれています。クラス自身はauxility(UML
1.4)、 focus(UML 1.4)、 implementation(UML 1.4)、 implementationClass(UML
1.3)、 typeのステレオタイプを定義しています。 以上の結果として、クラスはUML 1.3ではmetaClass、 powertype、 process、 thread、 utility、 implementationClass、 typeの7つのステレオタイプ、UML 1.4ではmetaClass、 powertype、 process、 thread、 utility、 auxility、 focus、 implementation、 typeの9つのステレオタイプが定義されていることになります。 もちろん、これらのステレオタイプは常に用いなければならないというわけではなく、対象となるモデルによって取捨選択を行います。本連載のターゲットはJavaによる実装のための設計モデルですから、この方針にのっとって利用するステレオタイプを決めていきます。 |
●2.1.4 プロパティ
UMLの仕様上は要素プロパティにはタグ付き値(tagged value)と制約(constraint)が格納されますが、これらを総称して本連載では「プロパティ」と呼ぶことにします。下記の表にUMLの標準仕様で定められているクラス用のプロパティを示します。表では、ステレオタイプとその意味に加えて、UML1.3およびUML1.4での定義状況、Javaでの利用とその理由を示しています。
プロパティ | 意味 | 1.3 | 1.4 | Java | 理由 |
active | アクティブオブジェクト | ○ | ○ | △ | Javaに対応機能あり |
root | 汎化のルートクラス | ○ | ○ | △ | 参考情報 |
leaf | 汎化のリーフクラス | ○ | ○ | △ | Javaに対応機能あり |
abstract | 抽象クラス | ○ | ○ | ◎ | Javaに対応機能あり |
persistence | オブジェクトの永続化の状態を示す(transitoryまたはpersistent) | - | ○ | △ | Java対応のオブジェクト指向データベースで利用 |
semantics | 意味規定 | ○ | ○ | - | メタモデル |
activeは、スレッドを内蔵したオブジェクトであり、いわゆるアクティブオブジェクトを示します。Javaではマルチスレッドによる実装で実現することができます。
rootは、クラスがルートクラスであることを示します。Javaではjava.lang.Objectがすべてのクラスのルートクラスなので、rootの性質を指定できる対象となります。
leafは、クラスがサブクラスを持たない継承の末端にあることを示します。Javaでは修飾子finalで表現することができます。
abstractは、クラスが抽象クラスであることを示します。Javaでは修飾子abstractで表現することができます。
persistenceは、オブジェクトの永続性に関する状態を示します。値としてtransitoryまたはpersistentを指定します。transitoryは永続化対象外のオブジェクト、persistentは永続化対象のオブジェクトを示します。
semanticsは、メタレベルの情報であり、Javaとのマッピングには無関係なので、本連載では検討対象外とします。
以上の検討の結果、本連載で検討対象とするクラス用プロパティは以下のものとなります。
- active
- root
- leaf
- abstract
- persistence
プロパティ
|
クラスの要素プロパティにクラスの性質を示すための情報を記述することができます。また属性やオペレーションのプロパティ文字列も同様の機能を持っています。 UMLの正式の仕様では、要素プロパティやプロパティ文字列には、制約(constraint)またはタグ付き値(tagged value)が設定されます。厳密な議論をする場合には、制約とタグ付き値を区別する必要がありますが、本連載では分かりやすさを重視して、要素プロパティおよびプロパティ文字列に格納される制約およびタグ付き値を総称して「プロパティ」と呼ぶことにします。 |
●2.1.5 Javaで利用するUMLクラスの種類
UMLにおける “クラス”は、ステレオタイプやプロパティによってさまざまな意味や機能を付加することができます。UMLの “クラス”であるクラス、インターフェイス、例外とステレオタイプの関係は下記の表に示しました。インターフェイスと例外にmetaClass、 thread、 utilityというステレオタイプを使用することはないので、結果として以下の種類の“クラス”が利用可能ということになります。
- (ステレオタイプのない)普通のクラス
- ステレオタイプmetaClassのクラス
- ステレオタイプthreadのクラス
- ステレオタイプutilityのクラス
- インターフェイス
- 例外
ステレオタイプ | ||||
“クラス” | なし | metaClass | thread | utility |
クラス | ○ | ○ | ○ | ○ |
インターフェイス | ○ | - | - | - |
例外 | ○ | - | - | - |
UMLの“クラス”であるクラス、インターフェイス、例外とプロパティの関係は次の表に示します。クラスはすべてのプロパティを設定可能です。インターフェイスは意味的にはrootとleafが設定可能になります。例外は基本的にはクラスと同様ですが指定して意味があるプロパティはroot、leaf、abstractとなります。
プロパティ | |||||
“クラス” | active | root | leaf | abstract | persistence |
クラス | ○ | ○ | ○ | ○ | ○ |
インターフェイス | - | ○ | ○ | - | - |
例外 | - | ○ | ○ | - | △ |
2/4
|
Javaオブジェクトモデリング 第3回 | |
分類子と“クラス” | |
UMLの“クラス”(1) | |
UMLの“クラス”(2) | |
Javaの“クラス” |
Javaオブジェクトモデリング INDEX |
IT Architect 連載記事一覧 |
アーキテクチャ 新着記事
@IT情報マネジメント 新着記事
この記事に対するご意見をお寄せください managemail@atmarkit.co.jp