この項では、UML2.0の特徴について、UML1.xとの違いに着目しながら説明 する。
| パッケージのマージ |
パッケージどうしをマージ(融合)するという概念が追加された。
次の表に例を示す。
|
|
| package mergeの記法 |
|
| 意味 |
この図では、パッケージRはパッケージPとパッケージQのマージで ある。Rの中のクラスA(R::A)は、パッケージPのクラスA(P::A)とパッケージQの クラスA(Q::A)を融合 したものであることになり、Q::Aが持つクラスC とのassociationも、R::Aは引き継いでいる。
| Composite Structures(複合構造) の概念追加 |
オブジェクトの内部構造を描くためにComposite Structure図が導
入された。これによって、オブジェクトがどのような部品(Part)か
ら構成され、それらの部品がどのように協調動作(Collaboration)
してこのオブジェクトを構成しているのかを描けるようになった。
元々UML1.xでComposite Objectという形で、オブジェクトの内部構
造を描く仕組みはあったが、これを前面に出してきたことが特徴だ
といえる。
また、UML1.xでの「Collaboration」という言葉の意味が変更され、
動的振る舞いではなく静的協調関係を指し示す言葉になった。(元
の「Collaboration」が意味していた動的振る舞いを指す言葉としては、Interactionという言葉が使
われている)
| コンポーネントの強化 |
これもUML1.xに概念も図も存在していたが、Composite Structure
と組み合わせる ことで強力にコンポーネントを描けるようになった。
インタフェースは2種類に分かれ(requiredInterfaceと
providedInterface)、このインタフェースによってコンポーネントの外的な仕様を描
き、Composite Structureを用いてコンポーネントの内部構造を描
くことができる。コンポーネントという概念についての説明は、こちらに示した。
コンポーネントとは、クラスの特化した形あるいは再利用可能なソフトウェア部品だと言えるが、この概念
がどのように使えるものであるかは、今はまだ実験段階だといえる。
| アクティビティの強化 |
UML1.xでは、Activity図はStatechart図の特化した形だとされてい たが、UML2.0ではActivity図はState Machine図から切り離された。 したがって、UML2.0のActivity図は、State Machine図によらない表記が可能になった。
| Interaction(相互作用)の記法強化 |
Interactionを描くための記法として、UML2.0では4つの図が準備さ れている。
このうち、Sequence図とCommunication図は、UML1.xでは記述方法
の違いだけという印象だったが、UML2.0では明確に「Sequence図が
Interactionを描くための最も一般的な図」と記されている。した
がって、Communication図の使用頻度はますます低くなると予想で
きる。
このことに伴って、Sequence図では記法を大幅に改良した。UML1.x
では、一度描いた図をほかの図に取り込んで再利用する、というこ
とができず、同じ図を何度も描かなければならないということが起
こっていたが、「フレーム」という記法を導入したことでこの問題
は解消された。ループなども描きやすくなった。さらに、
Composite Structure図との関係が明記され、静的構造と動的振
る舞いとの「壁」が低くなる効果もあると考えられる。
また、大まかにInteractionを捉えるために、Interaction Overview図
が導入された。
| 時間概念の追加 |
先で述べたInteraction図の1つ「Timing図」によって、UMLに初めて時 間の概念が導入された。
ここで導入されたTiming図の目的は、オブジェクト（正確にはClassifier Instance ま たはClassifier Role)の状態を変化させるイベント 発生のタイミングによって時間の変化を記述することである。
| Pre/Post condition |
Operation(操作)とBehavior(振る舞い)に対してPre/Post conditionが貼り付くようになった。preconditionとは、この OperationまたはBehaviorが始まるときに満たされていなければな らない条件のことで、postconditionとはOperationまたはBehavior が終了したときに満たされていなければならない条件のことである。 このconditionの追加によって、このOperationやBehaviorが正しく動作しているか どうかを検証する道筋ができたといえる。
| Semantic Variation Point |
これはSuperstructureの仕様書の中に記述されている言葉で、対象 領域によって一意に決められない点を示している。つまり、UMLの 適用対象領域に合うように、ツールベンダーやユーザが意味論を定 義する必要があるポイントで、拡張性がよくなったと言える。
| 図の追加 |
先述したように、図がいくつか追加された。これについては図の記 法を参照。
| EventとTrigger |
UML2.0からは、UML1.XにあったEventというメタクラスが消滅している。かわり にTriggerというメタクラスが新たに導入された。
つまり、UML2.0ではEventという言葉を明確に「起こった出来事」として用いて いる。Triggerというのは、日本語に直したときに「引き金」と訳されるように、 関連する振る舞いを引き起こすEventを特定するもの、とされている。
Triggerは、関係するEventによって次のように分類されている。
| Trigger | MessageTrigger | SignalTrigger |
| CallTrigger | ||
| AnyTrigger | ||
| TimeTrigger | ||
| ChangeTrigger |
| StateMachine関係のメタモデルの修正 |
あまり表立ってはいないが、StateMachine(旧Statechart)のメタモデルにはかな りの修正がされている。
まず、UML1.XではStateの種類を
なお、SubStateとSynchStateという概念は、UML2.0ではなくなっている。
UML2.0では、Procedureというメタクラスは消滅した。ここで代わりとなったのは、 Activityメタクラスである。Activityというメタクラスは新しいメタクラスであっ て、UML1.XではExpressionの中に含まれていて、明確に定義されたものではなかっ た。
さらに、Guardというメタクラスもなくなった。GuardはConstraintというメタク ラスに置き換わり、メタモデルとして統一感のとれたものになった。
したがって、StateMachineに描くTransitionにつく文字列は、次のような形 に置き換わっている。
Trigger[Constraint]/Activity
なお、UML1.Xでは次のような形となっていた。
Event[Guard]/Procedure
UML2.0で、Regionの概念が追加されている。RegionとはComposite Stateの各領 域やStateMachineの領域を指す。Regionの中にStateやTransitionがある、とい うイメージになる。
たとえば、UML1.Xでは、AND Stateにおいて点線で区切られたの各部分がメタクラスとして定義されいな ったことを考えれば、Regionが定義された理由が理解できるだろう。