トピック

概要 ページの先頭へ

このページでは、RUP コンテキストに関連する UML 1.x と UML 2.0 のいくつかの相違について説明します。このページは、すべての UML ([UML04]) インフラストラクチャーとスーパーストラクチャーの仕様を扱うものではありません。ここでは、関連する UML 機能の概要を示します。詳しくは、 [RUM05] と [ERI04] を参照してください。

「UML 1.x」とは、UML 1.0 から UML 1.5 までのバージョンを指します。

UML 2.0 機能セットでの図の変更の中で最も大きなものは、振る舞いの図の変更です。具体的には、アクティビティー図と一連の相互作用図の変更です (以下の アクティビティー図シーケンス図、およびコミュニケーション図を参照してください)。

UML 2.0 には、新機能として複合構造図と構造化クラスも含まれます (以下の 複合構造図を参照してください)。

アクティビティー図 ページの先頭へ

概論

UML 2.0 では、アクティビティーのモデリングが全面的に改訂されました。通常の使用であれば、効果や外観の相違はほとんどないといえます。しかし、UML 1.5 (およびそれ以前のバージョン) でのモデリングの形式性によっては、UML 1.x の規則に基づいて作成されたモデルの厳密な解釈および実行結果が、UML 2.0 の場合とは一致しないことがあります。したがって、モデリング担当者は、UML 1.x アクティビティー・モデルを変更しなくても UML 2.0 で使用できると思われる場合でも、モデルを同様に実行できない可能性があることに注意する必要があります。この可能性は、並行性を伴う複雑なモデルの場合に特に高くなります。詳しくは、[UML04] を参照してください。

[UML04] で定義されているように、アクティビティー (アクティビティー図 で示される) とは、複数の下位ユニットを調整してシーケンス化した振る舞いの仕様です。各下位ユニットの個別の要素はアクション です。UML 1.x アクティビティー図での個別の実行可能ステップの正式名称はアクション状態でしたが、通称としてアクティビティーまたはアクティビティー状態ということもありました。UML 2.0 アクティビティーでのこれらのステップの名称はアクションです。これらのアクションは、アクティビティーの内部でさらに分解されることはありません。UML 2.0 には、状態の概念は存在しません。これは、UML 1.x の場合とは異なり、アクティビティーが状態マシンの一種ではないからです。 UML 2.0 のアクティビティーは複数のノード から構成されます。ノードのうちの 1 種類がアクション・ノードです。その他の制御 ノードとオブジェクト・ノードについては、 後に示す部分で説明します。

フロー・セマンティクス

現行のアクティビティーは、ペトリ・ネット方式のセマンティクスを使用します。トークン・フロー に基づくこのセマンティクスでは、1 つのノードを実行すると、フローと呼ばれる有向接続を経由して別のノードの実行に影響が及びます。オブジェクトまたは制御場所を含むトークンは、これらの接続を経由して複数のノード間を移動します。入力トークン上で指定された条件が満たされると、ノードは実行を開始できます。実行が完了すると、ノードはトークンを出力フローに提供して、下流のノードが実行を開始できるようにします。ノードを接続するフローは、制御フローおよびデータ・フロー (またはオブジェクト・フロー) にさらに細分化されます。制御フロー上を移動するのは制御トークンであり、データ・フロー (またはオブジェクト・フロー) 上を移動するのはデータ (またはオブジェクト) トークンです。

これは UML 1.x とは対照的です。UML 1.x では、各ノードが状態 (または疑似状態) であり、ノード間で遷移が発生しました。このため、フローのモデリングが制限されていました。

並行モデリング

UML 2.0 のモデリング機能では、無制限の並行性が許容されます。UML 1.x では、状態マシン (アクティビティー) 全体が 1 つの「実行から完了まで」のステップを実行しました。これに対して、UML 2.0 機能を全面的に活用すると、アクティビティーのノードおよびフロー・コネクターを経由して移動するトークンの複数のストリームによって、1 つのアクティビティーの複数の呼び出しを 1 回の実行で処理することができます。これは、モデリング担当者が競合状態と相互作用を意識する必要があることを意味します。トークン・フロー・セマンティクスの並行モデリングに対する影響の別の例については、後に示すセクション「セマンティクスの相違」を参照してください。

表記法

アクション・ノードおよび制御ノード

以下の図は、多数の UML 2.0 要素を図示します。この図は、四角形のフレームを使用する UML 2.0 の通常の方法で表示され、左上のコンパートメントに名前が記入されています。この図を以下に示す UML 1.x バージョンと比較してください。2 つの図の外観は似ています (異なる図の向きと色の規則を使用できますが、セマンティクス上の意味はありません)。このモデルの実行結果は、UML 1.x と UML 2.0 のどちらでも同じです。制御ノード (決定、マージ、フォーク、結合、初期、最終) の外観は、UML 1.x で使用されたものと同じです。制御フローは矢印付きの直線で示されるので、UML 1.x の遷移矢印と外観が似ています。

この図は、さまざまなノード タイプ (初期、アクション、決定、フォーク、結合、マージ、アクティビティー最終) を図示するアクティビティー図を示します。制御フローも示します。

UML 2.0 アクティビティー図の例

この図は、UML 1.x バージョンでの対応する図を示します。

UML 1.x アクティビティー図の例

UML 2.0 には、フロー最終 と呼ばれる追加の制御ノード・タイプがあります ([UML04] から取得した以下の図に示します)。このノード・タイプは、フローを終了させるために、アクティビティー最終ノードの代わりに使用されます。これが必要になるのは、UML 2.0 ではアクティビティー最終ノードのいずれかのインスタンスに制御が到達すると、アクティビティー全体 (すべてのフローを含む) が終了するからです。フロー最終ノードでは、それに関連付けられたフローのみが終了されます。UML 1.5 では「実行から完了まで」のセマンティクスを使用したため、この点は問題になりませんでした。しかし、無制限の並行性が許容される UML 2.0 では、すべてのフローが停止しすべてのトークンが破棄されることを場合によっては回避する必要があります。

この図は、フロー最終制御ノードを図示します。

フロー最終制御ノード

オブジェクト・ノード

UML 2.0 アクティビティー・モデリングでは、オブジェクト・ノードもサポートされます。オブジェクト・ノードは、アクティビティー・ノードの一種であり、特定の分類子のインスタンス (特定の状態を持つインスタンスの場合もあります) をアクティビティー内の特定のポイントで (たとえば、アクションからの出力またはアクションへの入力として) 使用できる可能性があることを示します。オブジェクト・ノードは、特定のタイプのオブジェクト (特定の状態を持つオブジェクトの場合もあります) からのフローまたはオブジェクトへのフローのコンテナーとしての役割を果たします。UML 2.0 では、オブジェクト・ノードのためにピン と呼ばれる新しい表記法が導入されました。ピンは、アクションへの入力またはアクションからの出力を表し、アクションの四角形に関連付けられた小さな四角形として描かれます。以下に例を示します。

この図は、オブジェクト・ノードのためのピン表記法を示します。オブジェクト・フローによって出力ピンが入力ピンに接続されています。

ピン表記法

矢印はオブジェクト・フローを表します。UML 1.x でオブジェクト・フロー状態に対する遷移に点線が使用されたのとは異なり、これらの矢印は実線です。1 つのアクションに対する出力ピンの名前と、接続されたアクションに対する入力ピンの名前が同じ場合は、出力ピンと入力ピンをマージしてスタンドアロン・ピンを作成できます。この表記法の外観も UML 1.x のオブジェクト・フローと似ています。

この図は、代替スタンドアロン・ピン表記法を示します。

スタンドアロン・ピン表記法

構造化アクティビティー・ノード

構造化アクティビティー・ノードは、実行可能なアクティビティー・ノードであり、複数の下位アクティビティー・ノードに展開できることもあります。下位ノードは 1 つの構造化アクティビティー・ノードのみに属しますが、ネストされることもあります。制御フローに接続されたり、ピンに関連付けられたりすることもあります。構造化アクティビティー・ノードは、角の丸い点線の四角形として描かれます。四角形の中には下位ノードとフローが含まれ、上部にはキーワード <<structured>> が表示されます。

アクティビティー・パーティション

アクティビティー・パーティション とは、1 つのアクティビティーのノードおよびフローを、共有されたいくつかの特性に基づいてグループ化する方法です。UML 1.x のアクティビティー図では、基準に基づいて (たとえば、ビジネス・モデリングでは開発組織別に) アクションをグループ化するために、レーンの概念 (パーティションと見なされていました) を使用しました。UML 2.0 では、このパーティショニング機能をアクティビティー図の複数の次元にまで拡張し、追加の表記法を提供します。これにより、たとえば、個別のアクションが属しているパーティションの名前をラベルとしてアクションに付けることができます。以下の図は、UML 2.0 の仕様に基づいて表記される多層レーンの例を示します。ここでは、場所と責務に基づいてアクションがグループ化されています。

2 次元のレーンのある UML 2.0 方式のアクティビティー・パーティションの図解

2 次元レーンを使用するアクティビティー・パーティションの例

セマンティクスの相違

UML 2.0 アクティビティー・モデルには、トークン・フロー・セマンティクスと無制限の並行性という特徴があります。このため、UML 1.x に慣れているモデリング担当者が新規モデルを作成したり既存モデルを変換したりする場合には、設計意図どおりの実行結果が得られるように注意する必要があります。たとえば、上記の processPassenger の例では、チェックインする旅客が頻繁利用客のメンバーであることがあります。この場合には、代理店は、旅客に対して頻繁利用客へのマイルの認定を行う必要があります。この例を以下の UML 1.x モデル部分に示します。

この図は、ガードされた並行遷移のある UML 1.x モデル部分を示します。

ガードされた並行遷移の使用

UML 1.x では、オプションの並行遷移に対してガードを適用すると、遷移は開始されず、振る舞いはモデル内に遷移が表示されていない場合と同様になります。したがって、その他 2 つの遷移が完了すると、結合後に実行が継続されます。UML 2.0 では、旅客が頻繁利用客でない場合は、トークンがそのフローに沿って結合に到達することはなく、モデルは機能停止します。これは、結合がすべてのフローでトークンを待機するので、継続できなくなるからです。以下に示すようなモデルを作成する必要があります。ここでは、「荷物の取り扱い」フローと同じ方法で条件が処理されます。並行フローに依存する下流の結合がないことが確実であれば、並行フローにガードを直接適用してもかまいません。

この図は、以上の図の UML 2.0 バージョンを示します。ガードされた並行フローの代わりに、決定ノードとマージ・ノードを使用します。

ガードされた並行フローの代わりに決定ノードとマージ・ノードを使用

コミュニケーション図 ページの先頭へ

UML 1.x のコラボレーション図は、UML 2.0 ではコミュニケーション図 に名称変更されました。以前のバージョンとの意味上の相違はありません。コミュニケーション図は、相互作用図の 1 つのタイプであり、従来のコラボレーション図に基づいています。

表記法

コミュニケーション図では、複数の生存線の間の相互作用に注目します。このグラフでは、構造化クラスの各部分またはコラボレーションの各役割を表す四角形としてノードが示されます。この図の周囲には四角形のフレームがあり、左上隅のコンパートメントに名前が記入されています。この表記法は、以前の UML バージョンから変更されています。

  • ノードは、相互作用内の生存線に対応します。
  • パーツの間の直線は、コミュニケーション・パスを形成するコネクターを表します。
  • コネクター上に多重度が示されることがあります。
  • パーツ間のメッセージは、コネクターの直線の近くにあるラベル付き矢印によって示されます。
コミュニケーション図は、運用またはユース・ケースの実装を表す相互作用のモデリングに使用されます。

コミュニケーション図の例:

注文システムのコミュニケーション図の例

注文システムのコミュニケーション図の例

コンポーネント ページの先頭

UML 2.0 では、コンポーネントはクラス記号によって表記されます。UML 1.4 で定義された 2 つの突出部分のある四角形は使用しません。代わりに、<<component>> ステレオタイプを使用します。 オプションとして、UML 1.4 のアイコンに似たコンポーネント・アイコンを、コンポーネント記号の右上隅で引き続き使用できます。

UML 2.0 では、コンポーネントは構造化クラスであると定義します。これは、コンポーネントの内部構造内の要素 (部分) 間のコラボレーションをモデリングすることにより、振る舞いをより詳細に記述できることを意味します。パーツはコネクターを経由して接続されます。コンポーネントの提供インターフェースおよび必須インターフェースを通じてコンポーネントのカプセル化レベルを向上させるために、ポートを使用できます。詳しくは、概念: コンポーネント概念: 構造化クラスを参照してください。

UML の以前のバージョンでは、サブシステム と呼ばれる特別なモデリング要素が定義され、インターフェースを持つパッケージとしてモデリングされていました。また、物理アーキテクチャーでのモデルの構造化にコンポーネントを使用していました。UML 2.0 では、モデルのすべての部分にわたってコンポーネントを汎用的に使用します。したがって、サブシステムをモデリングするための特別な要素は不要になりました。UML 1.x で使用されたサブシステムの実現とサブシステムの仕様のための独立したコンパートメントは、UML 2.0 では、コンポーネントに適用される独立したステレオタイプ (それぞれ <<realization>> および <<specification>>) になりました。もう 1 つの新しいコンポーネント・ステレオタイプは、大規模なコンポーネントのモデリングを示す <<subsystem>> です。

RUP では、コンポーネントを使用してサブシステムをモデリングすることをお勧めします (詳しくは、ガイドライン: 設計サブシステムを参照してください)。

複合構造図 ページの先頭へ

アーキテクチャーの要素間に特定のコラボレーションが設定されることがあります。設計時にパーツやコネクターが既知であるとは限りません。一般的なクラス図 (およびその他の静的な図) では、これらの要素に適用される役割、責務、関係、規則を十分明確に表せないことがあります。

これらの問題に対処するために、UML 2.0 には複合構造図が追加されました。 この図では、構造化クラス (コンポーネント、クラスなど) の内部構造を、構造化クラスからシステムのほかの部分への相互作用ポイントを含めて表すことができます。この図は、収容構造化クラスの振る舞いを共同で実行する複数のパーツの構成を示します。

複合構造図は、構造化クラスの内部のコンテンツを描写するために使用されます (複合構造図の詳細および例については、概念: 構造化クラスを参照してください)。

シーケンス図 ページの先頭へ

UML 2.0 には、シーケンス図のいくつかの新機能があります。

  • フラグメントにより、シーケンス図の内部で発生する振る舞いのセマンティクスが明確になります。フラグメントを組み合わせると、シーケンス図の部分がカプセル化されます。これにより、個別のフローをモデリングして、各条件から実行の代替パスがどのように派生するかを示すことができます。

  • 相互作用オカレンスにより、相互作用を再利用可能なチャンクに分解できます。これは、1 つの相互作用の部分をほかのいくつかの相互作用が共有する場合に便利な方法です。

  • UML 1.x では、ループの可能な表現方法の 1 つは、メモの内部に記述されたループ条件を使用することでした。メモは、ループ条件が true であるときに実行されるメッセージまたはメッセージのセットに添付されていました。UML 2.0 には、ループ固有の表現があります。

  • UML 2.0 では、オブジェクトがどのように作成および破棄されるかを、シーケンス図で示すことができます。

  • オカレンスの実行は、オブジェクトがメッセージを受け取った時点で実行する制御フォーカスを示します。

フラグメント、相互作用オカレンス、ループを表す新機能があるため、シーケンス図は 2 つの形式で使用できます。

  • インスタンス形式: 特定のシナリオを詳細に記述して、条件、分岐、ループのない 1 つの可能な相互作用を文書化します。この形式は、1 つのユース・ケース・シナリオを表すために使用されます。 同じユース・ケースの複数のシナリオは、それぞれ異なるシーケンス図で表されます。UML 1.x セマンティクスをサポートするモデリング・ツールでは、この表現形式のみを使用できます。

  • 汎用形式: 条件、分岐、ループなどの UML 2.0 の新機能を利用して、シナリオ内のすべての可能な代替パスを記述します。この形式は、一意のシーケンス図内で同じユース・ケースの複数のシナリオを表すために使用できます (意味がある場合)。

以下の図は、複数のシナリオをモデリングするシーケンス図の例を示します。alt フラグメントは、条件が満たされたかどうかに依存するメッセージ・シーケンスの 2 つの可能な代替パスを示します。

分岐、ループ、条件を示すシーケンス図

例: 分岐、ループ、条件を示すシーケンス図

Rational Unified Process   2003.06.15