1.3 モデル図の拡張
UML2.0では、従来からあったモデル図に対しても変更が加わり、表現的にもセマンティック的にも拡張されています。本日は、これらのモデル図に加えられた拡張を概観してみます。
クラス図
単なる直感的な便法から、より概念的な一貫性を持った表現に変わりました。従来のバージョンでは、属性と関連は異なるものとされていましたが、UML2.0では、属性は、一方向の誘導可能性を持った関連と等価であると再定義されました。また、コンポジット構造図の登場に伴い、ポート、パートなど内部構造を記述するためのエレメントが追加されました。
インターフェースに関しても、従来は提供インターフェースのみであったのに対し、新たに要求インターフェースが付け加わり、さらに両インターフェースが接続された状態（アセンブリー・コネクタ）もコンポーネント図で使用されるようになりました。
また、多重度表現として従来許されていた”２,４,６” といった離散的表現がUML2.0では、認められなくなりました。
さらに、ステレオタイプの定義が厳密になり、ユーザーによる拡張の方法が提供されます。（プロファイル参照）
アクティビティ図
UML1.Xでは、アクティビティ図は、ステートマシン図とほとんど同じような扱いでしたが、UML2.0では、状態の遷移ではなく、トークンの流れとしてフローが独立して定義されました。また、アクションノードの形状が変わり、角の丸い四角形となりました。
従来、フォークとジョインは必ずペアで使用しなければならないなど、文法的制約の多かった記法が改められ、フォークノード、ジョインノード等すべてのアクティビティノードにそれぞれ固有の振る舞いが定義されて、単独で扱うことが可能になりました。（従来の文法は、構造化プログラミングの流れに沿うもので、アルゴリズムを表現する上では、極めて有益な（文法上の）制約でしたが、アクティビティ図の現実の使われ方は、初学者を除けばプログラミング・ロジックの表現に使われることはむしろまれで、圧倒的に業務フローの記述に使用されていることから、この制約は排除され、より自由な表現が可能となりました。）
トークンの流れも、UML1.Xでは、複数入力を暗黙的なマージとして扱っていたのに対し、暗黙的なジョインとして扱うように改訂されました。しかしながら、暗黙的な表現では誤解を招きやすいため、複数入力は、マージノードもしくはジョインノードを使用した明示的な記法が望ましいでしょう。ツールによっては、暗黙的な表現が許されないケースもあります。（これはあくまでツールが採用した制約であって、UMLの制約ではありません。）
また、シグナルの送受信、タイムイベント、パラメータ、パラメータセット、ピンなどの記法が拡張され、さらに、データストア、セントラルバッファーノードなど、業務フローを記述する際に有用なオブジェクトノードが付け加わりました。
従来からあったスイムレーンは多次元に拡張され、名前もパーティションに変更されました。
いずれの変更も、アクティビティ図が、プログラムのアルゴリズムを記述すると言ったミクロ的な使い方よりも、業務フローやビジネスモデルと言ったマクロ的な使用方法が圧倒的に多いという現状を踏まえた拡張と言えるでしょう。
シーケンス図
UML1.Xでは、生存線（ライフライン）のヘッダーは、オブジェクトに代表されるインスタンス表現でしたが、より一般的な形に変更され、参加者（participant)と呼ばれるようになりました。そして、結合フラグメントの採用により、並列処理、条件分岐、繰り返しなどの表現が出来るようになりました。
ステートマシン図
UML1.Xでは、継続時間の差から、アクション（継続期間が短い）とアクティビティ（継続期間が長い）という２種類を使い分けていましたが、UML2.0では、どちらもアクティビティと呼ぶようになりました。
