>サイトトップへ >このカテゴリの一覧へ

X 4170

:2009 (ISO/IEC 19501:2005)

(1)

目  次

ページ

序文

1

1

  適用範囲

1

2

  参考規格

2

3

  一般情報

2

4

  UML 意味論

3

第 区分  背景

3

4.1

  序論

3

4.2

  言語アーキテクチャ

3

4.3

  言語形式

6

第 区分  基盤

6

4.4

  Foundation  基盤パッケージ

6

4.5

  Core  コアパッケージ

7

4.6

  Extension Mechanisms  拡張機構パッケージ

39

4.7

  Data Types  データ型パッケージ

44

第 区分  振る舞い要素

50

4.8

  Behavioral Elements  振る舞い要素パッケージ

50

4.9

  Common Behavior  共通振る舞いパッケージ

51

4.10

  Collaborations  コラボレーションパッケージ

61

4.11

  Use Cases  ユースケースパッケージ

68

4.12

  State Machines  状態機械パッケージ

71

4.13

  Activity Graphs  アクティビティグラフパッケージ

80

第 区分  一般機構

85

4.14

  Model Management  モデル管理パッケージ

85

5

  UML  記法ガイド

90

第 区分  背景

90

5.1

  序論

90

第 区分  図式要素

90

5.2

  グラフ及びその内容

90

5.3

  経路の描画

90

5.4

  非表示ハイパーリンク及びツールの役割

91

5.5

  背景の情報

91

5.6

  文字列

91

5.7

  名前

92

5.8

  ラベル

92

5.9

  キーワード

92


X 4170

:2009 (ISO/IEC 19501:2005)  目次

(2) 

ページ

5.10

  式

93

5.11

  ノート

93

5.12

  型とインスタンスとの対応

94

第 区分  モデル管理

95

5.13

  パッケージ

95

5.14

  サブシステム

96

5.15

  モデル

97

第 区分  一般拡張機構

98

5.16

  制約及び注釈

98

5.17

  要素特性

99

5.18

  ステレオタイプ

101

第 区分  静的構造図

103

5.19

  クラス図(類図)

103

5.20

  オブジェクト図(個体図)

103

5.21

  分類子

103

5.22

  クラス

103

5.23

  名前区画

104

5.24

  並び区画

105

5.25

  属性

106

5.26

  操作

108

5.27

  入れ子クラス宣言

110

5.28

  型及び実装クラス

110

5.29

  インタフェース

111

5.30

  パラメタ化クラス(テンプレート)

111

5.31

  束縛済み要素

112

5.32

  ユティリティ

113

5.33

  メタクラス

113

5.34

  列挙

114

5.35

  ステレオタイプ宣言

114

5.36

  ベキ型

117

5.37

  クラスパス名

117

5.38

  パッケージのアクセス又は移入

117

5.39

  オブジェクト

118

5.40

  合成オブジェクト

119

5.41

  関連

120

5.42

  二項関連

120

5.43

  関連端

121

5.44

  多重度

123

5.45

  限定子

124


X 4170

:2009 (ISO/IEC 19501:2005)  目次

(3) 

ページ

5.46

  関連クラス

125

5.47

  項関連

125

5.48

  合成集約

126

5.49

  リンク

127

5.50

  はん(汎)化

128

5.51

  依存

129

5.52

  派生要素

131

5.53

  インスタンス接続

131

第 区分  ユースケース図(用例図)

131

5.54

  ユースケース図

131

5.55

  ユースケース

132

5.56

  アクタ

132

5.57

  ユースケース関係

133

5.58

  アクタ関係

133

第 区分  相互作用図

134

5.59

  コラボレーション(協調)

134

5.60

  シーケンス図(系列図)

135

5.61

  オブジェクト生存線

136

5.62

  活性区間

137

5.63

  メッセージ及び刺激

137

5.64

  遷移時間

138

第 区分  コラボレーション図(協調図)

139

5.65

  コラボレーション図

139

5.66

  パターン構造

140

5.67

  コラボレーション内容

143

5.68

  相互作用

145

5.69

  コラボレーション役割

146

5.70

  多重オブジェクト

147

5.71

  能動オブジェクト

147

5.72

  メッセージ及び刺激

148

5.73

  生成マーカ・解体マーカ

151

第 区分  ステートチャート図(状態図)

151

5.74

  ステートチャート図

151

5.75

  状態

152

5.76

  合成状態

154

5.77

  イベント

155

5.78

  単純遷移

156

5.79

  並行状態への遷移

157

5.80

  合成状態への遷移

157


X 4170

:2009 (ISO/IEC 19501:2005)  目次

(4) 

ページ

5.81

  分解遷移経路

158

5.82

  下位機械状態

159

5.83

  同期状態

159

第 10 区分  アクティビティ図(活動図)

160

5.84

  アクティビティ図

160

5.85

  動作状態

160

5.86

  下位活動状態

161

5.87

  判断

161

5.88

  呼出し状態

162

5.89

  レーン

162

5.90

  動作とオブジェクトフローとの関係

163

5.91

  制御アイコン

163

5.92

  同期状態

165

5.93

  動的呼出し

166

5.94

  条件付き並行分岐

166

第 11 区分  実装図

166

5.95

  コンポーネント図(部品図)

166

5.96

  配置図

167

5.97

  ノード

168

5.98

  コンポーネント

169

6

  UML  プロファイルの例

170

7

  UML  モデル交換

170

8

  OCL  オブジェクト制約言語

170

附属書 A(規定)UML 標準要素

171

附属書 B(規定)法的情報

173

附属書 JA(参考)UML メタモデルのパッケージ構成及びメタクラス一覧

177

附属書 JB(参考)参考規格

181

附属書 JC(参考)用語集

183


X 4170

:2009 (ISO/IEC 19501:2005)

(5) 

まえがき

この規格は,工業標準化法第 12 条第 1 項の規定に基づき,社団法人情報処理学会(IPSJ)及び財団法人日

本規格協会(JSA)から,工業標準原案を具して日本工業規格を制定すべきとの申出があり,日本工業標準調

査会の審議を経て,経済産業大臣が制定した日本工業規格である。

この規格は,著作権法で保護対象となっている著作物である。

この規格の一部が,特許権,出願公開後の特許出願,実用新案権又は出願公開後の実用新案登録出願に

抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査会は,このような特許

権,出願公開後の特許出願,実用新案権及び出願公開後の実用新案登録出願にかかわる確認について,責

任はもたない。


X 4170

:2009 (ISO/IEC 19501:2005)

(6) 

白      紙


   

日本工業規格

JIS

 X

4170

:2009

(ISO/IEC 19501

:2005

)

オープン分散処理−統一モデル化言語(UML)

1.4.2

Open Distributed Processing

−Unified Modeling Language (UML),

Version 1.4.2

序文

この規格は,2005 年に第 1 版として発行された ISO/IEC 19501 を基に,技術的内容を変更することなく

作成した日本工業規格である。

なお,この規格で点線の下線を施してある参考事項及び

附属書 JA∼附属書 JC は,対応国際規格にはな

い事項である。

1

適用範囲

この規格は,オブジェクト分析及びオブジェクト設計を行うシステムアーキテクトに,ビジネスモデル

化及びソフトウェアシステムの成果物を記述し,視覚化し,構築し,文書化するための一つの一貫性ある

言語を提供することを目的に,統一モデル化言語(UML)について規定する。

この規格は,オブジェクト技術に関する産業界でのベストプラクティスの集大成である。UML は,既に

指導的であった三つのオブジェクト指向技法[Booch 法

1)

,OMT

2)

及び OOSE

3)

]を適切に継承するオブジ

ェクトモデル化言語である。UML は,これらのモデル化言語及び更にそれ以上の技術を融合したものであ

り,これらの技法が十分に解決することができなかったモデル化での問題点を解決するための追加の表現

力をもっている。

UML

の主要な目的の一つは,オブジェクトモデル視覚化ツール間の相互運用性を確保することによって,

産業界の状況を進歩させることである。しかし,ツール間のモデル情報の意味のある交換を可能とするた

めに,意味論的及び記法上の一致が求められる。UML は,次に示すこれらの要求を満たすものである。

−  オブジェクト分析及びオブジェクト設計[OA&D

4)

]モデルの意味論を表現するための,OA&D に共

通なメタモデルの形式定義。これは,静的モデル,振る舞いモデル,使い方のモデル,及びアーキテ

クチャモデルを含む。

− OA&D ツール間モデル交換のためのメカニズムに必要なインタフェース定義言語(IDL)

。これには,

利用者モデルの動的な構成及び走査を支援する IDL インタフェースの集合を含む。

− OA&D モデルを表現する人間に解読可能な記法。この規格は,UML の豊富な意味論を一貫性をもっ

て表現する簡潔な図的構文としての UML 記法を定義する。記法は,OA&D モデル化及び UML の本

質的な部分である。

1)

 Booch

法  Grady Booch(米)によって開発されたオブジェクト指向ソフトウェア開発手法

2)

 OMT

  Object Modeling Technique の略

3)

 OOSE

  Object Oriented Software Engineering の略


2

X 4170

:2009 (ISO/IEC 19501:2005)

   

4)

 OA&D

  Object Analysis and Design の略

注記  この規格の対応国際規格及びその対応の程度を表す記号を,次に示す。

ISO/IEC 19501:2005

,Information technology−Open Distributed Processing−Unified Modeling

Language (UML) Version 1.4.2 (IDT)

なお,対応の程度を表す記号

(IDT)

は,ISO/IEC Guide 21 に基づき,一致していることを示す。

2

参考規格

注記  この規格を利用する上で参考となる規格を,附属書 JB に示す。

3

一般情報

注記 1  (対応国際規格では,箇条 は解説的内容であるため,この規格では不要であり,不採用と

した。

注記 2  用語一覧

この規格に現れる主な用語については,

附属書 JC を参照。

注記 3  英字表記の区分

この規格では,UML の仕様を記述するメタモデル要素などの英字表記を,一般の英字略語,

規格名称,人名などと区別がしやすいように文字スタイルを変えている。その例を,次に示

す。

例 1

メタモデル要素の名前

・  パッケージ名 
・  メタクラス名 
・  クラスの属性,関連,タグ付き

値,非継承素性の名前

・  クラスの役割名 
・  属性がとる値 
・ UML の表記記号の一部として

扱われる文字列

 
Foundation 
Classifier 
name,visibility,mapping,persistence,
connection,isRoot 
ownedElement 
none 
Specification , Elements , Realization 
Elements

例 2 UML 標準のステレオタイプ又は制約

の名前

«derive»

,{ordered}

例 3 UML 及び他のプログラム言語で使う

一般的な型名,記法及びキーワード

String,Real,true,false

例 4

文字列で表す文法の表記

Template-name '<' value-list '>'

例 5

数式に現れる変数名

x,y,p1,p2

注記 4  矢線表記の区分

この規格を利用する上で参考となる矢線表記を,次に示す。

閉矢じり実線矢線

開矢じり実線矢線

実線矢線

半開き矢じり実線矢線

開矢じり破線矢線

破線矢線

白抜き閉矢じり破線矢線


3

X 4170

:2009 (ISO/IEC 19501:2005)

4

UML

意味論

第 区分  背景

4.1

序論

注記  (対応国際規格では,4.1 は解説的内容であるため,この規格では不要であり,不採用とした。)

4.2

言語アーキテクチャ

4.2.1

4

層メタモデル化アーキテクチャ

UML

メタモデルは,4 層メタモデル化アーキテクチャの一つの層として定義される。このアーキテクチ

ャは,複雑なモデルに必要な正確な意味論を定義するために十分に有効な基礎である。この方式には,次

のような利点がある。

−  コアの基本構成要素を連続するメタ層に再帰的に適用することによって詳細化する。

−  将来の UML メタモデル拡張を定義するためのアーキテクチャ基盤を提供する。

−  4 層のメタモデル化アーキテクチャに基づいた他の標準[例えば,オーエムジー

Object Management

Group

(業界団体)メタオブジェクトファシリティ(MOF)

]を UML メタモデルと連携させるための

アーキテクチャ基盤を提供する。

メタモデル化の一般的な概念フレームワークは,次の 4 層アーキテクチャに基づく。

−  メタメタモデル

−  メタモデル

−  モデル

−  ユーザオブジェクト(ユーザデータ)

これらの層の機能を,

表 に示す。

表 1層メタモデル化アーキテクチャ

記述

メタメタモデル

メタモデル化アーキテクチャの基盤。

メタモデルを指定するための言語を
定義する。

MetaClass

,MetaAttribute,MetaOperation

メタモデル

メタメタモデルのインスタンス。モデ
ルを指定する言語を定義する。

Class

,Attribute,Operation,Component

モデル

メタモデルのインスタンス。情報領域
を記述するための言語を定義する。

配当金,株価確認する,指値売りする, 
株式相場サーバ

ユーザオブジェクト

(ユーザデータ)

モデルのインスタンス。特定の情報領

域を定義する。

<

日本産業社_配当_98789>,654.56,

指値_売り_する,<株式_相場_サーバ_32123>

メタメタモデル層は,メタモデル化アーキテクチャの基盤となる。この層の基本責務は,メタモデルの

仕様を記述する言語を定義することである。メタメタモデルはモデルをメタモデルより高い抽象度で定義

し,一般的にはそれ自身が記述するメタモデルよりも簡潔である。メタメタモデルでは複数のメタモデル

を定義でき,それぞれのメタモデルに関連する複数のメタメタモデルが存在することができる。

関連したメタモデル及びメタメタモデルは,共通の設計哲学及び設計要素をもつのが一般的に望ましい

が,それは厳密な規則ではない。各層で設計の統合性を保つ必要がある。メタメタモデル層でのメタメタ

オブジェクトの例を,次に示す。

例 1  MetaClass


4

X 4170

:2009 (ISO/IEC 19501:2005)

   

例 2  MetaAttribute

例 3  MetaOperation

メタモデルは,メタメタモデルのインスタンスになる。メタモデル層の基本責務は,モデルの仕様を記

述する言語を定義することである。メタモデルは,一般にそれ自身を記述するメタメタモデルよりも詳し

くなる。特に,動的意味論を定義するときに詳しくなる。メタモデル層でのメタオブジェクトの例を,次

に示す。

例 1  Class

例 2  Attribute

例 3  Operation

例 4  Component

モデルは,メタモデルのインスタンスである。モデル層の基本責務は,情報領域を記述する言語を定義

することである。モデル層のオブジェクトの例としては,配当金,株価確認する,指値売りする及び株式

相場サーバがある。

ユーザオブジェクト(ユーザデータともいう。

)は,モデルのインスタンスである。ユーザオブジェクト

層の基本責務は,個別の情報領域を記述することである。ユーザオブジェクト層のオブジェクトの例を,

次に示す。

例  <日本産業社_配当_98789>,654.56,指値_売り_する及び<株式_相場_サーバ_32123>

4.2.1.1

MOF

メタメタモデルとのアーキテクチャの対応付け

UML

及び MOF の両者は,ともに 4 層メタモデル化アーキテクチャに基づく。MOF メタメタモデルが

UML

メタモデルのメタメタモデルとなる。MOF 及び UML は,有効範囲及び抽象レベルが異なる(UML

メタモデルは MOF メタメタモデルよりも論理モデルに近い。

)ので,両者は厳密なメタモデル化

5)

という

よりも緩いメタモデル化でつながっている。結果として,UML メタモデルは,MOF メタメタモデルのイ

ンスタンスとなる。

したがって,すべての MOF メタメタモデル要素と UML メタモデル要素との間に厳密な同型インスタン

ス接続対応は存在しない。その代わりに,これらの二つのモデルは相互運用性があるように設計されてい

るので,UML Core パッケージメタモデルと MOF メタモデルとは構造的に同一となる。

5)

緩い(又は“厳密ではない”

)メタモデル化では,M

n

レベルのモデルは,M

n

1

レベルのモデル

のインスタンスとする。厳密なメタモデル化では,M

n

レベルのモデルの各々の要素は,M

n

1

レベルのモデルの正に一個の要素のインスタンスとする。

4.2.2

パッケージ構造

UML

メタモデルの複雑性は,論理的パッケージ群に体系化することによって統制される。これらのパッ

ケージは強い結合をしているメタクラスをひとまとめにし,それほど強くない結合をしているものは他の

パッケージとしている。UML のメタモデルは,

図 に示すような最上位パッケージに分解される。

注記  図 1,図 2,図 及び図 の図中における破線矢線については 5.51 を参照する。また,大きな

長方形と小さな長方形とが重ねられた図形については 5.13 を参照する。


5

X 4170

:2009 (ISO/IEC 19501:2005)

図 1−最上位パッケージ

Foundation

パッケージ及び Behavioral Elements パッケージは,

図 及び図 に示されるように

更に分解される。

図 2Foundation パッケージ


6

X 4170

:2009 (ISO/IEC 19501:2005)

   

図 3Behavioral Elements パッケージ

このパッケージの機能及び内容は,4.8 で示す。

4.3

言語形式

注記  (対応国際規格では,4.3 は解説的内容であるため,この規格では不要であり,不採用とした。)

第 区分  基盤

4.4

Foundation

  基盤パッケージ

Foundation

パッケージは,モデルの静的構造を規定する言語基盤とする。Foundation パッケージは,

Core

,Extension Mechanisms,Data Types という下位パッケージに分解される。

図 に,Foundation

パッケージを示す。Core パッケージは,基本メタモデルに必要な基本概念の仕様を記述し,メタクラス,

メ タ関 連,メ タ属 性 のよ う な 追 加 的 言 語 要 素 を与 え る た め のア ーキ テク チャ の根 幹を定 義す る 。

Extension Mechanisms

パッケージは,モデル要素のカスタム化はどうすればよいか,新しい意味論に

どう拡張すればよいかを示す。Data Types パッケージは,言語の基本データ構造を定義する。


7

X 4170

:2009 (ISO/IEC 19501:2005)

図 4Foundation パッケージ

4.5

Core

  コアパッケージ

4.5.1

概要

Core

パッケージは,UML の Foundation パッケージを構成する下位パッケージの中で最も本質的な

ものでなければならない。このパッケージは,オブジェクトモデルの開発に必要な基本的な抽象メタモデ

ル構成要素及び具象メタモデル構成要素を定義する。抽象メタモデル構成要素は,インスタンス化はでき

ない。また,重要な構成要素の具体化,構造の共有,及び UML メタモデルの組織化のために共通して使

われる。具象メタモデル構成要素は,オブジェクトモデル作成者(対比としてメタモデル作成者)が使用

するモデル化構成要素を反映し,インスタンス化可能とする。Core に定義された抽象構成要素には,

ModelElement

,GeneralizableElement,及び Classifier があり,具象メタモデル構成要素には,

Class

,Attribute,Operation,及び Association がある。Core パッケージは,基本的なメタモ

デルに必要な,コアとなる構成要素を規定し,メタクラス,メタ関連,メタ属性などの付加的な言語構成

要素を追加するためのアーキテクチャの根幹(スケルトン)を定義する。

Core

パッケージは,UML の他の部分を定義するだけの十分な意味論を含んでいるが,UML のメタメ

タモデルではない。Core パッケージは,言語の他の部分の基盤として働く Foundation パッケージの根

本的な基礎である。Core は,他のパッケージ内では,はん(汎)化と関連とを使って根幹部にメタクラ

スを追加することによって拡張される。

4.5.2

では,Core パッケージの抽象構文を示す。

4.5.2

抽象構文

Core

パッケージの抽象構文は,次の

図 5∼図 のように図式記法で示す。図 は,メタモデルの構造的

な根幹を形成するモデル要素を示す。

図 は,関係を定義するモデル要素を示す。図 は,依存を定義す

るモデル要素を示す。

図 は,各種の分類子を示す。図 は,テンプレートパラメタ,表示要素及び注釈

の補助要素を示す。


8

X 4170

:2009 (ISO/IEC 19501:2005)

   

図 5Core パッケージの根幹部


9

X 4170

:2009 (ISO/IEC 19501:2005)

図 6Core パッケージの関係部


10

X 4170

:2009 (ISO/IEC 19501:2005)

   

図 7Core パッケージの依存部


11

X 4170

:2009 (ISO/IEC 19501:2005)

図 8Core パッケージの分類子部

図 9Core パッケージの補助要素部


12

X 4170

:2009 (ISO/IEC 19501:2005)

   

4.5.2.1

Abstraction

  抽象化

抽象化は,同一概念を表す二つの要素又は二つの要素集合を,異なった抽象化のレベルで,又は異なっ

た観点から関係付ける Dependency 関係の一つとする。

メタモデルでは,Abstraction は供給者とクライアントとの間で対応付けが存在する Dependency と

する。Abstraction の特定のステレオタイプに応じて,対応付けは,形式的又は非形式的にもなり,片

方向又は双方向とすることができる。

Abstraction

要素が複数のクライアント要素をもつ場合,供給者要素は一団としてのクライアント要

素集合の中に対応付ける。例えば,一つの分析段階クラスを,幾つかの設計段階クラスに分割する。複数

の供給者要素が存在する場合にも同様の状況となる。

Abstraction

の UML 標準ステレオタイプ付けされたクラスは,Derivation,Realization,

Refinement

及び Trace とする(これらは,«derive»,«realize»,«refine»

及び

«trace»

というス

テレオタイプをもつ Abstraction クラスへの名前とする。

属性

mapping

供給者とクライアントとの間の抽象化関係を示す MappingExpression とする。
ある場合には,Derivation のように,通常は形式的,かつ,片方向となる。他の
場合には,Trace のように,通常は非形式的,かつ,双方向となる。この対応付け
属性は選択可能であり,要素間の関係が正確に定義されていない場合には省略する
ことができる。

ステレオタイプ

«derive»

(ステレオタイプ付けされたクラスの名前は,Derivation とする。

)通常は同一

タイプのモデル要素間の派生関係を規定するが,必ずしも必要ではない。«derive»
付きの依存は,クライアントが供給者から計算できることを規定する。その対応付
けが計算によって生成できる。クライアントは,論理的に冗長であっても,効率な
どの設計上の理由から実装されることがある。

«realize»

(ステレオタイプ付けされたクラスの名前は,Realization とする。

)一つ以上の

仕様モデル要素(例えば供給者)と一つ以上のそれを実装するモデル要素(例えば
クライアント)との間の実現関係を規定する。実装モデル要素は,仕様モデル要素
が宣言したすべての操作及び受信シグナルを提供することが求められる。実装モデ
ル要素は,自身の操作及びシグナル受信の宣言を継承するか,又は作るかしなけれ
ばならない。対応付けが両者の関係を規定する。対応付けは,計算可能でも計算不
能でもよい。実現は,段階的詳細化,最適化,変換,テンプレート,モデル合成,
フレームワーク合成などをモデル化するのに使用できる。

«refine»

(ステレオタイプ付けされたクラスの名前は,Refinement とする。

)分析及び設

計のような,異なる意味論的段階のモデル要素間の洗練関係を規定する。その対応
付けは,二つの要素間又は要素集合間の関係を規定する。対応付けは,計算可能で
も計算不能でもよく,片方向でも双方向でもよい。洗練は,分析から設計への変換
などの変更をモデル化するのに用いられる。

«trace»

(ステレオタイプ付けされたクラスの名前は,Trace とする。

)異なったモデルの

同一概念を表すモデル要素又はモデル要素集合間のトレース関係を規定する。トレ
ースは,主として,モデルにまたがる要件と変更とを追跡するのに用いる。モデル
変更は,両方向に生じるので,依存の方向は往々にして無視される。対応付けで両
者の関係を指定するが,計算可能なことはまれ(稀)であり,通常は非形式的とな
る。


13

X 4170

:2009 (ISO/IEC 19501:2005)

4.5.2.2

Artifact

  成果物

成果物は,ソフトウェア開発プロセスにおいて使用又は生産される情報の物理的かたまりを表現する。

成果物の例には,モデル,ソースファイル,スクリプト及びバイナリ実行ファイルを含む。成果物は,配

置可能要素の実装でもよい。

メタモデルでは,Artifact は,一つ以上の Component への選択可能な集約関連をもつ Classifier

とする。Classifier であるため,Artifact は,その Artifact の特性を表現する Feature をもつこ

とができる(例えば,属性“読みだけ許可”又は操作“登録手続をする”とする。

Artifact

は,Component を経由することなく直接 Classifier と連結することが必要となることが

ある。例えば,コード生成の文脈においては,結果として生じた Artifact(ソースコードファイル)が,

Component

としては決して配置されない。その場合,«derive» Dependency は,Classifier と生成

された Artifact との間で用いられる。

Artifact

の標準ステレオタイプは,«file»,«file»

の下位クラス(«executable»,«source»,

«library»

,«document»)及び

«table»

とする。これらのステレオタイプは,更に実装及びプラットフ

ォーム固有ステレオタイプの下位クラスとすることができる(例えば,Java アーカイブの

«jarFile»

関連

implementationLocation

この Artifact で実装された配置可能 Component。

ステレオタイプ

«document» «source»

ファイルでも

«executable»

でもないはん(汎)用のファイルを示す。

«file»

の下位クラス。

«executable»

コンピュータシステム上で実行できるプログラムファイルを示す。«file»

の下位ク

ラス。

«file»

開発されたシステムの文脈で物理ファイルを示す。

«library»

静的ライブラリファイル又は動的ライブラリファイルを示す。«file»

の下位クラ

ス。

«source»

実行ファイルにコンパイルできるソースファイルを示す。«file»

の下位クラス。

«table»

データベーステーブルを示す。

4.5.2.3

Association

  関連

関連は,分類子間の意味的関係を定義する。関連のインスタンスは,分類子のインスタンスに関係する

組の集合とする。各組の値は,多くとも一度しか出現しない。

メタモデルでは,Association は,Class などの Classifier 間の意味的関係の宣言である。

Association

は,少なくとも二つの AssociationEnd をもつ。各端点は一つの Classifier に結ばれ

る。同じ Association 内の複数の AssociationEnd が同一の Classifier に結ばれてもよい。

Association

は,Classifier のインスタンス間の接続集合を表現する。Association のインスタン

スは,Link,すなわち,対応する Classifier から導かれた Instance の組となる。

属性

name

関連する Classifier と組み合わせて,閉じた名前空間(通常は Package)内で
一意とならなければならない,Association の名前。


14

X 4170

:2009 (ISO/IEC 19501:2005)

   

関連

connection

一つの Association は,少なくとも二つの AssociationEnd からなる。各
AssociationEnd は,Classifier への関連結合を表現し,関係を有効にするた
め 満 た す べ き 特 性 の 集 合 を 指 定 す る 。 Association の 構 造 の 大 部 分 は ,
AssociationEnd によって定義される。関連に属する分類子は,それに関与する
役割名の関連によって,AssociationEnd 群に関連付けられる。

ステレオタイプ

«implicit»

この

«implicit»

は,関連に適用され,その関連が顕在的なものではなく,概念的

なものに過ぎないことを指定する。

標準制約

xor

この

{xor}

制約は,関連集合に適用され,その集合上では,各関連インスタンスご

とに一つだけが顕在することを指定する。xor は,排他的(包含的でない)論理和
制約とする。

タグ付き値

persistence persistence は関連の状態の永久性を示す。これには,インスタンスが削除され

るとその状態も破棄される transitory と,インスタンスが削除されてもその状
態が破棄されない persistent とがある。

継承素性

関連は,GeneralizableElement とする。次の要素は,下位の Association によって継承される。

connection

下位クラスは,上位クラスと同じ個数の端点をもたなければならない。各参加クラ
ス は , 上 位 ク ラ ス の 同 じ 位 置 の 参 加 ク ラ ス の 子 孫 で な け れ ば な ら な い 。
Association が AssociationClass の場合,そのクラス特性(属性,操作など)
は継承される。他の特性は,下位クラスによって変わる。この規定は,UML 2.0 に
おいて,更に明確化される可能性がある。

非継承素性

isRoot 
isLeaf 
isAbstract

その本質によって,継承されず,はん(汎)化構造を定義する。

name

各モデル要素は,一意名をもつ。

4.5.2.4

AssociationClass

  関連クラス

関連クラスは,クラスでもある関連とする。関連クラスは,分類子の集合を結合するとともに,分類子

ではなく関係それ自体に属する素性の集合を定義する。

継承素性

AssociationClass

は,Class 及び Association の両者において規定される素性を継承する。

メタモデルでは,AssociationClass はそれ自体の素性の集合をもつ Classifier 間の意味的関係の

宣言 と する。 AssociationClass は Association 及 び Class の 両方の 下位 クラ スであ る ( 各

AssociationClass

は,Association でも Class でもある。

。したがって,AssociationClass は

AssociationEnd

及び Feature の両方をもつ。


15

X 4170

:2009 (ISO/IEC 19501:2005)

4.5.2.5

AssociationEnd

  関連端

関連端は,関連を分類子に結ぶ,関連の端点とする。各関連端は,一つの関連の一部とする。各関連の

関連端は,順序付けられる。

メタモデルでは,AssociationEnd は Association の一部であって,Association の Classifier

への接続を規定する。AssociationEnd は名前をもち,結合の特性の集合(例えば,Instance がどの

Classifier

に適合するか,多重度,接続を経由して他の Instance から到達可能かどうかなど。

)を定

義する。

次の記述で,二項関連の関連端を参照するとき,その特性を論じている側の端を終点端,もう一方を起

点端とする。

属性 
aggregation

ある端点(例えば,こちらを終点端とする。

)に着目する場合,終点端側のクラス

が,もう一方の端点(起点端側)のクラスを集約するかどうかを指定する。一端だ
けが集約となることができる。 
 
可能性を次に示す。 
・  none:終点クラスは,集約体ではない。 
・  aggregate:終点クラスは,集約体である。ゆえに,起点クラスは部分で,

aggregation の値が none でなければならない。その部分は他の集約体に含
まれることができる。

・  composite:終点クラスは,合成体である。ゆえに,起点クラスは部分で,

aggregation の値が none でなければならない。この部分は合成体が強く所
有し,他の合成体の部分であってはならない。

changeability

ある端点(例えば,こちらを終点端とする。

)に着目する場合,Association の

インスタンスが,もう一方の端点(起点端側)のクラスのインスタンスから修正可
能かどうかを指定する。言い換えると,この属性は反対側の端点のクラスの操作に
よるアクセスを制御する。 
 
可能性を次に示す。 
・  changeable:修正の制限なし。 
・  frozen:起点オブジェクトの生成後に,リンクを追加してはならない。終点

クラスの操作は,リンクを追加できる(同様の制約がない場合。

・  addOnly:いつでも起点オブジェクトからリンクを追加してよいが,一度作

られたリンクを,起点クラスから削除してはならない。終点クラスの操作は,
リンクを追加及び削除することができる(同様の制約がない場合。

ordering

終点端に着目した場合,起点インスタンスから終点インスタンスへのリンクの集合
が順序付けられているかどうかを指定する。順序付けは,リンクを追加する
Operation によって決められ維持されなければならない。順序付けは,オブジェ
クト又はリンクそれ自体に元々なかった付加的な情報を表現する。 
 
可能性を次に示す。 
・  unordered:固有順序のない集合を形成するリンク。 
・  ordered:順序付きリンクの集合は,順番に走査することができる。 
・  (整列などの)他の可能性は後で,追加キーワードを宣言することによって定

義される。ユーザ定義ステレオタイプの場合と同様,これは特定の編集ツール
によって提供された固有拡張となる。


16

X 4170

:2009 (ISO/IEC 19501:2005)

   

isNavigable

終点端に着目したときは,起点インスタンスからその関連する終点インスタンスへ
とたどることが可能かどうかを指定する。Association の両側のそれぞれの仕様
は独立である。値が真の場合,関連が起点クラスから誘導可能であり,終点役割名
が誘導式に用いられることを意味する。

multiplicity

終点端に着目したときは,与えられた Association の反対側の起点インスタン
スと関連することのできる終点インスタンスの数を指定する。

name

(ModelElement から継承)端点の役割名。終点端に着目したとき,関連の反対
側の起点インスタンスから終点インスタンスまで又は終点インスタンス群の集合
までたどるための名前を提供する。この名前は,起点の分類子の擬似属性を表現し
( す な わ ち , Attribute と 同 じ 方 法 で 使 用 す る こ と が で き る 。), 起 点 の
Classifier の Attribute 及び他の擬似属性に関して一意でなければならない。

targetScope

終点がインスタンスなのか,分類子なのかを指定する。 
 
可能性を次に示す。 
・  instance:インスタンスが各リンクの一部となる。これを省略値とする。 
・  classifier:分類子それ自体が各リンクの一部となる。通常,これはモデル

化時点で固定され,実行時に別途格納する必要はない。

visibility

他端の分類子から見たときの関連端の可視性を指定する。 
 
可能性を次に示す。 
・  public:公開属性と同様に,他の分類子は,関連をたどり,表現に役割名を

使ってよい。

・  protected:保護属性と同様に,起点分類子の子孫は,関連をたどり,表現

に役割名を使ってよい。

・  private:私的属性と同様に,起点分類子だけが,関連をたどり,表現に役

割名を使ってよい。

・  package:関連宣言のように同一パッケージ(又は任意のレベルにわたる入

れ子下位パッケージ内の分類子群)が関連を誘導でき,かつ,式で書かれた役
割名を使うことができる。

関連 
qualifier

端点に対する限定子 Attribute の選択可能な並び。並びが空の場合には,
Association は限定されない。

specification Association を 横 断 し , AssociationEnd に よ っ て ア ク セ ス さ れ る

Instance に適用可能な Operation を規定するゼロ個以上の Classifier
を示す。これは,Association の意図を示すために,端点につけられた実際
の Classifier が実現しなければならない最小インタフェースを決定する。
これは,インタフェース又は別の Classifier とする。

participant Association の端点に結合した Classifier を示す。

関連のリンクはそのリンクの与えられた位置において,あるクラスのインスタ
ンスへの参照をもつ。そのクラスは,元々の基底クラス,そのクラスの下位ク
ラス,又は指定されたインタフェースを実現するクラス,のいずれでもよい。

(名前のない合成端)

AssociationEnd を所有する Association を示す。

ステレオタイプ

«association»

実際の関連を指定する(これは既定値で冗長だが,強調のため含む。

«global»

終点が実際の関連を指定しているわけではなく,すべての要素に知られている大域
的な値を指定する。

«local»

関係が実際の関連を指定しているわけではなく,手続内の局所変数を表現する関係
を指定する。


17

X 4170

:2009 (ISO/IEC 19501:2005)

«parameter»

関係が実際の関連を指定しているわけではなく,手続パラメタを表現する関係を指
定する。

«self»

関係が実際の関連ではなく,操作及び動作を所有するオブジェクトへの参照を表現
する関係を指定する。

4.5.2.6

Attribute

  属性

属性は,

分類子のインスタンスがもつことのできる値域を記述する分類子内の名前付きスロットとする。

メタモデルでは,Attribute は,Classifier の宣言された状態,特にその Classifier の Instance

がもつ値の値域に名前を付けたものである。

属性 
initialValue

初期化時の,属性の値を指定する Expression。この式はオブジェクトを初期化す
るときに評価される(明示的なコンストラクタで初期値を置き換えてもよい。

関連 
associationEnd

限 定 子 属 性 を 所 有 す る 選 択 可 能 な AssociationEnd を 示 す 。 属 性 は ,
AssociationEnd の一部であるか(この場合は限定子となる。

,又は Classifier

の一部となる(この場合は,Feature からの継承で,素性となる。

)が,両方を兼

ね備えることもある。

4.5.2.7

BehavioralFeature

  振る舞い素性

振る舞い素性は,操作,メソッドなどのモデル要素の動的な素性を参照する。

メタモデルでは,BehavioralFeature は Classifier の振る舞いの側面を規定する。Operation,

Method

などの Classifier の各種の振る舞いの側面は,BehavioralFeature の下位クラスとする。

BehavioralFeature

は,抽象メタクラスである。

属性 
isQuery Feature の実行がシステムの状態を不変に保つかどうかを指定する。真は,状態が

変化しないことを示し,偽は,副作用が発生することができることを示す。

name

(ModelElement から継承)Feature の名前。Feature の呼出し仕様全体(名前
とパラメタとの並び)が,それを含む Classifier 内で一意でなければならない。

関連 
parameter Operation のための Parameter の順序付き並び。Operation の呼出しには,呼

出し側は Parameter の型と互換な値の並びを与えなければならない。

ステレオタイプ

«create»

明示した素性がその素性を備えた分類子のインスタンスを生成することを指定す
る。その素性を含む Classifier によって使うことができる。

«destroy»

明示した素性がその素性を備えた分類子のインスタンスを解体することを指定す
る。その素性を含む Classifier によって使うことができる。

4.5.2.8

Binding

  束縛

束縛は,供給者としてテンプレートとそのテンプレートからクライアントとして生成されたモデル要素


18

X 4170

:2009 (ISO/IEC 19501:2005)

   

との間の関係とする。束縛はテンプレートパラメタに合致する引数並びを含む。テンプレートは複製され,

置換によって,あたかもモデルの直接的部分であるかのように振る舞う暗黙的モデル断片を生成するひな

型とする。 Binding は, 一 つの 供給 者と 一つ のク ラ イアント とをもたなけ ればな らない。 一般 の

Dependency

とは異なり,供給者とクライアントは集合であってはならない。

メタモデルでは,Binding は供給者がテンプレートで,クライアントがそのテンプレートのパラメタの

置換できるインスタンスとなる Dependency とする。クライアントに与えるために供給者のパラメタを置

換する引数並びをもつ。クライアントは供給者のパラメタの束縛によって指定され,自分自身の情報は何

も付け加えない。要素が,異なるクライアントに対する多重 Binding 関係における供給者として参加し

てもよい。クライアントとして,要素は一つの Binding 関係にだけ参加してよい。

関連

argument

引数の順序並び。各引数は TemplateArgument 要素となる。modelElement 関
連によって,TemplateArgument に付加されたモデル要素は,供給者定義におけ
る対応する供給者パラメタを置き換え,結果はクライアントの定義を,あたかも直
接定義されたかのように表現する。

4.5.2.9

Class

クラス

クラスは,共通の属性,操作,メソッド,関係及び意味をもつオブジェクトの集合の記述とする。クラ

スは,クラスがその環境に提供する操作の集まりを指定するために,インタフェースの集合を利用するこ

とができる。

メタモデルでは,Class は,Object のその集合に共通の,Operation,Attribute 及び Method を

含む Feature の集まりを共有する Object の集合を記述する。さらに,Class は,ゼロ個以上の

Interface

を実現することができる。すなわち,Class の完全記述子は,実現されたすべての Interface

のすべての Operation を含まなければならない(付加的な操作も含まれる。

抽象クラス(Object を直接には生成できない。

)もあるものの,Class は Object のデータ構造を定

義 す る 。 Class か ら イ ン ス タ ン ス 化 さ れ た 各 Object は , 完 全 記 述 子 内 に 宣 言 さ れ た

StructuralFeature

に対応する値の集合をそれぞれに含む。Object は,BehavioralFeature 又は

クラス有効範囲の Attribute に対応する値は含まない。Class のすべての Object は,Class の

BehaviorlFeature

の定義を共有し,各クラス有効範囲属性に格納された単一の値へのアクセスをもつ。

属性

isActive Class の Object が,それ自体の制御スレッドを維持するかどうかを指定する。真

の場合,Object はそれ自体の制御スレッドをもち,他の活性 Object と並行して
動作する。このようなクラスを,非公式に能動クラスと呼ぶ。偽の場合,Operation
は呼出し側を制御する活性 Object のアドレス空間内でその制御に従って動作す
る。このようなクラスを,非公式に受動クラスと呼ぶ。


19

X 4170

:2009 (ISO/IEC 19501:2005)

ステレオタイプ

«auxiliary»

一般的には,二次的な論理又は制御フローの実装によって,他のより中心的又
は基本的クラスを補助するクラスを指定する。援助を受ける側のクラスは,
Focus クラスを用いて明示的に定義することもできれば,依存関係によって暗
黙的に定義することもできる。補助クラスは,一般的には,Focus クラスとと
もに用いられ,設計時に,二次的なビジネス論理又はコンポーネントの制御フ
ローを規定するのに役立つ(«focus»

も参照)

«focus»

一つ以上の補助クラスの論理又はフローに対する主論理又は制御フローを定
義するクラスを指定する。補助クラスは,Auxiliary クラスを使って明示的
に定義することもできるし,依存関係によって暗黙的に定義することもでき
る。Focus クラスは,一般的には,一つ以上の Auxiliary クラスとともに用
いられ,設計時に,要素のコアビジネス論理又は制御フローを指定するのに役
立つ(«auxiliary»

も参照)

«implementation»

特定のプログラム言語によるクラスの実装を指定する(例えば,C++,Smalltalk,
Java

。)。一つのインスタンスは実装クラスを二つ以上もたない。この点は,

implementation 指定のない一般的 UML Class と異なる。UML の一般クラ
スでは,インスタンスが一時に複数のクラスをもつことができ,時間が経つに
つれてクラスを増やしたり減らしたりする。また,オブジェクトは動的に複数
のクラスをもてる。 
 
実装クラスがその Type で定義されたすべての操作に関して,その Type の操
作として規定されているものと同じ振る舞いを提供している場合,実装クラス
はその Type を実現しているという。実装クラスは,複数の異なる Type を実
現できる。実装クラスの物理属性及び関連は,それが実現する Type のそれら
と同じである必要はなく,実装クラスは,その操作のためのメソッドを物理属
性及び関連によって提供してもよい(«type»

も参照)

«type»

そのオブジェクトに適用可能な操作とともにオブジェクトの領域を,そのオブ
ジェクトの物理実装を定義せずに指定する。型には,メソッドを含めてはなら
ない。それ自身の制御スレッドを保持してはならない。入れ子であってはなら
ない。しかし,属性又は関連をもつことができる。Type の関連は,型の操作
の振る舞いを指定するためにだけ定義され,状態データの実装を表現しない。
 
オブジェクトは,一つの Implementation Class しかもつことができない
が,複数の異なる Type に適合できる(«implementation»

も参照)

継承素性

クラスは,GeneralizableElement とする。次の要素は,その上位クラスの Classifier で規定さ

れるものの他に,下位クラスの分類子が継承する。

isActive

下位クラスは,上位クラスが受動であるときに能動であってよいが,逆は成り立たな
い。ほとんどの場合,両者は同じとする。

4.5.2.10

  Classifier  分類子

分類子は,振る舞い及び構造上の素性を記述する要素とする。分類子には,クラス,データ型,インタ

フェース,コンポーネント,及び他のメタモデルパッケージ内に定義されたその他のものを含む,複数の

特定の形がある。

メタモデルでは,Classifier は,Attribute,Method,Operation などの Feature の集まりを

宣言する。Classifier は,それを含む Namespace 内で一意な名前をもつ。Classifier は抽象メタク

ラスとする。


20

X 4170

:2009 (ISO/IEC 19501:2005)

   

Classifier

GeneralizableElement

及 び

Namespace

の 下 位 ク ラ ス と す る 。

GeneralizableElement

としては,ModelElement として継承したものの他に,Features 及び

Association

への参加を継承する。また,StateMachine,Collaboration などの所有権を引き継ぐ。

Namespace

として,Classifier はその適用範囲で入れ子になった他の Classifier を宣言する。入

れ子になった Classifier は,それが適切な可視性をもつ場合にだけ,他の Classifier からアクセス

される。入れ子になった Classifier のデータ値又は状態結果は存在しない。すなわち,これは集約でも

合成でもない。

関連

feature Classifier がもつ,Attribute,Operation,Method のような Feature の

順序付き並び。

association Classifier が与えられた端で参加する Association の AssociationEnd を示

す。これは,AssociationEnd からの参加関連の逆とする。関連のリンクは,与
えられた位置のクラスのインスタンスへの参照を含む。

powertypeRange Classifier がベキ型であるゼロ個以上の Generalization を示す。基数がゼロ

の場合,Classifier はベキ型でない。基数が正数の場合,Classifier は,関
連 に よ っ て 指 定 さ れ た Generalization の 集 合 上 の ベ キ 型 と な り ,
Generalization の下位クラス要素はベキ型としての Classifier のインスタン
スとなる。ベキ型の Classifier は,«powertype»

でマークする。

specifiedEnd

与えられた Classifier が他端から関連をたどることによって得られたインスタ
ンスに適用される操作を指定する AssociationEnd を示す(この関係は,関連の
構造を定義せず,そのたどるときに適用される操作だけを定義する。

ステレオタイプ

«metaclass»

分類子のインスタンスがクラスであることを指定する。

«powertype»

分類子がメタクラスであり,そのインスタンスが同じ区別子によってマークされた
分類子であることを指定する。

«process»

重量級の制御フローを表現する分類子を指定する。

«thread»

制御フローを表現する分類子を指定する。

«utility»

インスタンスをもたないが,クラス適用範囲の非メンバ属性及び操作を示す名前付
き集まりを表す分類子を指定する。

タグ付き値

persistence persistence は関連の状態の永久性を示し,(インスタンスが削除されるとその

状態も破棄される。

)transitory,又は,

(インスタンスが削除されてもその状態

が破棄されない。

)persistent とマークする。

semantics semantics は,分類子の意味の仕様とする。

継承素性

Classifier

は,GeneralizableElement とする。次の要素は,その下位クラスである分類子によっ

て継承される。

継承が,分類子の(仮想)完全記述子の継承要素部分を作るが,実データ構造は,変更しない。継承の

各種類の意味の説明を参照する。


21

X 4170

:2009 (ISO/IEC 19501:2005)

associationEnd

下位分類子は,すべての同じ特性によるが,その上位分類子のすべての関連で参加
を継承する。

constraint

上位分類子の制約が,下位分類子に適用される。

feature

上位分類子の属性は,下位分類子の完全記述子の一部となり,再び宣言したり又は
上書きしてはならない。 
 
上位分類子の操作は,下位分類子の完全記述の一部となり,上書きしてはならない。
再宣言は,その階層的位置(isRoot,isLeaf,isAbstract)を変更できるが,
その仕様又はパラメタ構造を変更してはならない。並行性レベルは,緩和すること
ができる(例,ガード付きから並行へ)

。上書き操作は,異なる Method にリンク

できる。上書き操作は,上位分類子が偽値をもつとき,isQuery が真となることが
できるが,逆であってはならない(言い換えると,副作用が一度でもあるならば,
常に副作用がある。

 
上位分類子のメソッドは,下位分類子の完全記述子の一部となり,上書きしてはな
らない。上書きメソッドは,状態 isQuery をセットして,その階層構造を変更し
てよいが,パラメタ構造を変更してはならない。それは,上位分類子のメソッドの
操作を上書きする異なる操作にリンクできる。

generalization 
specialization

はん(汎)化グラフの弧として祖先と子孫とを定義するという意味で,これらは,
暗黙に継承されるが,陽には継承されない。これらは,下位の分類子が適合するは
ん(汎)化構造を有向グラフとして確立する。

ownedElement

上位分類子の名前空間は,私的アクセスを除いて,下位分類子から利用できる。

非継承素性

次の要素は,下位の分類子に継承されない。

isRoot 
isLeaf 
isAbstract

その本質によって,これらは継承されない。

name

各分類子は,その一意名をもつ。

parameter

テンプレート構造は,継承されない。各分類子がある場合は,そのテンプレート構
造を宣言しなければならない。非テンプレートは,テンプレートの下位分類子であ
ってよく,逆も成り立つ。

powertypeRange

ベキ型は,はん(汎)化階層の特定のノードに対応するので,継承されない。

4.5.2.11

  Comment  注釈

注釈は,一つ以上のモデル要素に附属された注記とする。意味論的には何の働きもしないが,モデル作

成者に有用な情報を含む。

属性

body

注釈である文字列。

関連

annotatedElem Comment によって記述される ModelElement 又は ModelElement 群の集合。


22

X 4170

:2009 (ISO/IEC 19501:2005)

   

ステレオタイプ

«requirement»

システムの一部分として,要素の,望ましい素性,特性又は振る舞いを指定す
る。

«responsibility»

他の要素との関係において,要素の契約又は義務を指定する。

4.5.2.12

  Component  コンポーネント

コンポーネントは,モジュール化され,配置可能及び置換え可能なシステムの部品を表現する。これは

実装をカプセル化し,インタフェースの集合を開示する。

コンポーネントは,一般的には,コンポーネント上に存在する一つ以上の分類子を指定する。これらの

分類子の部分集合は,明示的にコンポーネントの外部インタフェースを定義する。コンポーネントは,そ

のコンポーネント内部に存在する要素によって提供されるサービスを表現するインタフェースに適合する。

コンポーネントは,バイナリ,実行形式,又はスクリプトファイルのような一つ以上の成果物によって実

装できる。コンポーネントは,ノード上に配置できる。

コンポーネントは,設計モデル(例えば,静的構造の図式を用いて)及び実装モデル(例えば,実装図

式を用いて)の両者で指定できる。設計モデルの一部として指定されるとき,コンポーネントは,ノード

に割り付ける必要も,関連した実装成果物をもつ必要もない。

メタモデルでは,Component は Classifier の下位クラスとする。それ自身の Feature をもつ必要

はないが,その代わりに,Feature をもつ他の Classifier のコンテナとして作用する。Component

は,それが開示する Interface 群及び Component 上に存在する Classifier 群によって指定される。

ElementResidence

関連の可視属性は,存在要素が,Component の外側で可視かどうかを定義する。

Component

の外部 Interface は,可視値‘public’をもつ。Component は,一つ以上の Artifact

群によって実装でき,Node 上に配置できる。

関連

deploymentLocation Component が存在する Node 集合。 
resident

(関連クラス ElementResidence)コンポーネントを指定するモデル要素の
集合。可視性属性が,コンポーネント外の要素の外部可視性を示す。Component
の外部 Interface は,ElementResidence 関連に,visibility=‘public’
をもつ。

implementation Component を実装する Artifact の集合。Component では,Artifact は,

一般に

«executable»

とする。

継承素性

次の要素は,Classifier で指定されたものに追加して,下位クラスの Component に継承される。

(なし)

非継承素性

deploymentLocation  位置の集合は,異なってよい。下位コンポーネントについては,制限が多い

ことがよくある。

resident

存在要素の集合は,異なってよい。下位コンポーネントについては,制限が
多くて,他の要素を含むことがよくある。

implementation

下位の Component を実装する Artifact の集合は,通常異なる。


23

X 4170

:2009 (ISO/IEC 19501:2005)

4.5.2.13

  Constraint  制約

制約は,テキストで表された意味的な条件又は制限とする。

メタモデルでは,Constraint は,関連した ModelElement 上の BooleanExpression であり,モ

デルが適格なときに真とする。この制限は,自然言語又は明確な意味論をもつ別種の言語で記述すること

が できる。 UML に は 定 義 済 み の Constraint も あ るが , そ れ以 外 に ユー ザが 定義 しても よ い 。

Constraint

は表明であって,実行可能な機構ではない。Constraint は,システムの正しい設計によっ

て,守られなければならない制限を示す。

属性

body

シ ス テ ム の イ ン ス タ ン ス が 適 格 で あ る と き に , 真 と 評 価 さ れ る
BooleanExpression。

関連

constrainedElement Constraint によって影響される ModelElement,又は ModelElement の並

び。制約要素が Stereotype ならば,制約はそのステレオタイプを用いるす
べての ModelElement に適用される。

ステレオタイプ

«invariant»

分類子集合又は関係集合に付加されなければならない制約を規定する。これは
制約条件が,分類子又は関係,及びそれらのインスタンスに対して,特定の要
素に関して必要な期間だけの時間中成り立っていなければならないことを示
す。

«postcondition»

操作に付加されなければならない制約を指定し,制約条件が操作呼出し後に成
り立たなければならないことを示す。

«precondition»

操作に付加されなければならない制約を指定し,制約条件が操作呼出しのため
に成り立たなければならないことを示す。

«stateInvariant»

分類子をもつ状態機械の状態頂点に付加されなければならない制約を指定す
る。ステレオタイプは,制約が分類子のインスタンスについて,インスタンス
がその状態にあるとき,成り立つことを示す。

4.5.2.14

  DataType  データ型

データ型は,その値が識別性をもたない型(純粋な値そのもの)とする。データ型は,プリミティブな

組込み型(整数,文字列など)と,定義可能な列挙型(リテラルが真偽である論理型などの定義済みの列

挙型)とを含む。

メ タ モ デ ル で は , DataType は , Operation が す べ て 純 粋 な 関 数 で あ る よ う な 特 殊 な 種 類 の

Classifier

を定義する(Operation は DataValue を返すが,識別子をもたないので,DataValue

を変えることはできない。

。例えば,ある数に対する,他の数を引数とする加算操作は,結果として第 3

の数をもたらすが,対象と引数との数は変化しない。

継承素性

DataType

は,Classifier で規定される素性を継承する。

4.5.2.15

  Dependency  依存

Association

,Generalization,Flow,及び他の(Classifier とその Instance の一つとの間

のような)メタ関係以外の関係のための便宜的な用語。


24

X 4170

:2009 (ISO/IEC 19501:2005)

   

依存は,一つ以上の要素の実装又は機能が,一つ以上の他の要素の存在を必要とすることを明示する。

メタモデルでは,Dependency は,一つ以上のクライアントから一つ以上の供給者への方向付けされた

関係であって,例えば,クライアント要素が供給者要素の存在及び知識を必要とするなどというような,

クライアントが供給者に依存することを明示する。

Dependency

の種類には,Abstraction,Binding,Permission 及び Usage がある。これらの要

素の様々なステレオタイプが前もって定義される。

関連

client

供給者要素に影響を受ける要素。Trace Abstraction のような場合には,方向は
重要でなく,二つの要素を区別する働きしかもたない。

supplier

ク ラ イ ア ン ト の 逆 。 変 化 に よ っ て 影 響 を 受 け な い 要 素 を 示 す 。( あ る 種 の
Refinement のような)2 方向関係においては,これはより一般的な要素となる。
Trace

Abstraction のような方向のない場合には,クライアント及び供給者の選

択は無意味となる。

4.5.2.16

  Element  要素

要素は,モデルの原子的な構成要素とする。

メタモデルでは,Element はメタクラス階層内の最上位メタクラスとする。二つの下位クラス,

ModelElement

と PresentationElement とをもつ。Element は,抽象メタクラスとする。

タグ付き値

documentation documentation は要素に付加された,要素についての注釈,記述,又は説明とす

る。

4.5.2.17

  ElementOwnership  要素所有権

要素所有権は,Namespace 内に含まれる ModelElement の可視性を定義する。

メタモデルでは,ElementOwnership は,Namespace と Namespace との外部の可視性を使って

ModelElement

の所有権を示すことによって,ModelElement と Namespace との間の関係を具体化す

る(4.5.2.27 を参照)

属性

isSpecification  (仕様が実現と区別されている場合に)ownedElement が包含する側の名前空間の

仕様の一部かどうかを規定する。仕様の一部でない場合には,ownedElement は実
現の一部となる。区別がなされない場合には,値の既定値は偽とする。


25

X 4170

:2009 (ISO/IEC 19501:2005)

visibility ModelElement が他の ModelElement から見られ,かつ,参照され得るかどうか

を指定する。 
 
可能性を次に示す。 
・  public:外部のどの ModelElement もこの ModelElement を見ることがで

きる。

・  protected:この ModelElement の子孫ならば ModelElement を見ること

ができる。

・  private : そ の も の , そ の 構 成 部 分 , 又 は 入 れ 子に な っ て い る 要 素し か

ModelElement を見ることができない。

・  package:ある ModelElement は,それを含むパッケージ(又は任意のレベ

ルに対する下位パッケージ)内で宣言された ModelElement から見ることが
できる。

 
他の Package における要素の使用も,Model Management で記述されたように,
その Package のアクセス又は移入の対象となることができる(Permission を参
照)

4.5.2.18  ElementResidence

  要素所在

ElementResidence

は,ある Component を規定する ModelElement 集合を定義するための,

Component

と ModelElement との間の関連クラスとする(4.5.2.12 を参照)

。コンポーネントが要素と対

応していることを示す。ElementResidence の可視性属性は,コンポーネントの外部にある所在要素の

可 視 性 を 定 義 す る 。 Component の 外 部 Interface は , そ の ElementResidence 関 連 の

visibility=‘public’

をもつ。

属性

visibility Component に存在する ModelElement が外部から可視であるかを指定する。

ElementResidence の可視性がとり得る値を次に示す。 
 
・  public:Component のアクセスと移入の許可をもっている場合,public を

もつ ModelElement は Component の外部 Interface となり,他の要素によ
って用いられる。

・  private:ModelElement は,Component の内部となり,外部の要素によっ

て用いることはできない。

・  protected:ModelElement は,下位の Component 群に対してだけ可視とな

る。

 
可視性値 package は,ElementResidence の可視性には適用しない。Component
及びその所在は,それを含む Package への可視性値のある ElementOwnership
関連をもつ。

4.5.2.19

  Enumeration  列挙

メタモデルでは,Enumeration は値域が前もって定義された,列挙リテラルと呼ばれる値の並びであ

る DataType の一種を定義する。

列挙リテラルは,コピー可能であり,値として格納され,引数として渡される。列挙リテラルは,列挙

データ型の内部で順序付けられる。列挙リテラルは,列挙データ型内部で完全一致比較又は範囲指定の比

較ができる。他に定義された代数はない(例,加算も減算もできない。


26

X 4170

:2009 (ISO/IEC 19501:2005)

   

Primitive

データ型の実行時インスタンスは,Value とする。Enumeration 型そのものの一部とし

て定義された EnumerationLiteral の一つに,そのような値は正確に対応する。

Enumeration

は,操作をもてるが,それは純粋な関数でなければならない(これは,すべての DataType

要素に対する規則となる。

関連

literal EnumerationLiteral 要素の順序付き集合。各要素は,列挙要素のインスタンス

がとり得る値を指定する。

4.5.2.20

  EnumerationLiteral  列挙リテラル

列挙リテラルは,Enumeration データ型の実行時拡張の要素を定義する。関係する下位構造はもたな

い。すなわち,原子的とする。Enumeration データ型の列挙リテラルは,順序付けられている。

列挙データ型内で識別に用いられる名前(ModelElement から継承する。

)をもつ。

EnumerationLiteral

は,ModelElement であり,

(M1)モデルで Enumeration の構造を定義する

ため現れる。実行時(M0)システムでは,列挙リテラルは,それが表す EnumerationLiteral に多対一

対応する DataValue とする(これは,微妙だが,M1 及び M0 実体の間の必要な区別とする。

列挙リテラルに対応する実行時の値は,等価性のための比較,及び列挙リテラル範囲内の相対順序付け

又は包含関係のための比較ができる。

関連

enumeration

この列挙リテラルがインスタンスとなる列挙分類子。

4.5.2.21

  Feature  素性

操作,属性などと同様に,素性は,Classifier 内にカプセル化される特性とする。

メタモデルでは,Feature は,Classifier の Instance 又は Classifier それ自体の,振る舞い又

は構造上の特徴を宣言する。Feature は,抽象メタクラスとする。

属性

name Classifier 又は Instance 内の Feature を識別するために使用する名前

(ModelElement から継承される。

。AssociationEnd の名前を含む祖先からの

名前の継承において,一意でなければならない。より正確な詳細については,具体
的な規則を参照する。 
 
属性,区別子,及び反対側の関連端は,継承された名前の集合の中では一意な名前
をもたなければならない。同じ操作については,複数の宣言をもつことができる。
複数の操作が異なる呼出し仕様のもとで,同一の名前をもっていてもよい。詳細に
ついては,対応する規則を参照する。

ownerScope Feature が,Classifier のそれぞれの Instance の中にあるのか,Classifier

それ自体の Feature の単一のインスタンスであるかを規定する。 
 
可能性を次に示す。 
・  instance:Classifier の各 Instance は,Feature に対するそれ自体の

値をもつ。

・  classifier:Classifier それ自体の Feature のただ一つの値がある。


27

X 4170

:2009 (ISO/IEC 19501:2005)

visibility Feature が,他の Classifier によって使用できるかどうかを規定する。入れ子

にした Classifier の可視性は結合され,最も制限された可視性が,その結果と
なる。 
 
可能性を次に示す。 
・  public:その Classifier への可視性をもつ任意の外部の Classifier が,

Feature を使用できる。

・  protected:その Classifier の任意の子孫が,Feature を使用できる。 
・  private:その Classifier それ自体だけが,Feature を使用できる。 
・  package:同じパッケージ(又は,任意のレベルでの入れ子になった下位パッ

ケージ。

)内で,Feature の所有者として宣言された任意の Classifier は,

その Feature を利用できる。

関連

owner Feature を宣言している Classifier。Attribute が Classifier に所有され

る(この場合には素性。

)か,又は AssociationEnd に所有される(この場合には

限定子。

)かのどちらかだが,両方ではないことに注意する。

4.5.2.22

  Flow  フロー

フローは,一つのオブジェクトの二つの版の間,又はオブジェクトとそのコピーとの間における関係と

する。

メタモデルでは,Flow は Relationship の下位クラスとする。Flow は,起点又は複数の起点から終

点又は複数の終点への方向をもった関係とする。

Flow

の定義済みステレオタイプは,«become»

及び

«copy»

とする。become は,オブジェクトの一つの

版と異なる値,状態又は位置によって他の版と関係付ける。copy は,オブジェクトをそのオブジェクト

のコピーとして開始する他のオブジェクトと関連付ける。

ステレオタイプ

«become»

Flow 関係を規定する。その起点及び終点は,異なる時点における同じインスタン
スを表現する。しかし,起点と終点とは,値,状態インスタンス,及び役割が異な
る可能性をもつ。A から B への Become フロー関係はインスタンス A が,新しい値,
状態インスタンス,及び役割をもって時空の異なる点で B となることを意味する。

«copy»

Flow 関係を規定する。その起点及び終点は,異なるインスタンスであるにもかか
わらず,同じ値,状態インスタンス,及び役割(ただし,識別性は異なる。

)をも

つ。A から B への Copy フロー関係は,B が A の正確なコピーであることを意味す
る。A の将来の変更は B に反映されなくて構わない。

4.5.2.23

  GeneralizableElement  はん(汎)化可能要素

はん(汎)化可能要素は,はん(汎)化関係に参加可能なモデル要素とする。

メタモデルでは,GeneralizableElement は,他の GeneralizableElement のはん(汎)化とな

る こ と が で き る ( す な わ ち , 祖 先 で 定 義 さ れ た す べ て の Feature 及 び 祖先 に 含 ま れ る すべ て の

ModelElement

は,GeneralizableElement 内にも存在する。

。GeneralizableElement は,抽象

メタクラスとする。


28

X 4170

:2009 (ISO/IEC 19501:2005)

   

属性

isAbstract GeneralizableElement が直接のインスタンスをもつことができるかどうかを

規 定 す る 。 真 は , GeneralizableElement

の イ ン ス タ ン ス が

GeneralizableElement の下位クラスでなければならないことを示す。偽は,下
位クラスのインスタンスではなく GeneralizableElement のインスタンスがあ
ることを示す。抽象的な GeneralizableElement は,必要な情報すべてを保持
していないので,インスタンス化不能とする。 
注記  この後に続く文章は,解説的内容であるため削除。

isLeaf GeneralizableElement が,子孫をもたない GeneralizableElement かどう

かを規定する。真は,子孫をもたないことを示す。偽は,子孫をもつ可能性(実際
その瞬間に子孫がなくてもよい。

)を示す。

isRoot GeneralizableElement が,祖先をもたないルート GeneralizableElement

かどうかを指定する。真は,祖先をもたないことを,偽は祖先のある可能性(実際
にその時点で祖先がなくてもよい。

)を示す。

関連

generalization

その上位クラスの GeneralizableElement が現在の GeneralizableElement
の直上の祖先である Generalization を示す。

specialization

その下位クラスの GeneralizableElement が現在の GeneralizableElement
の直下の子孫である Generalization を示す。

継承素性

次の要素は,下位クラス GenerizableElement によって継承される。

constraint

上位クラスのすべての制約が下位クラスに適用される。

非継承素性

isRoot

isLeaf

isAbstract

その本質によって,継承されないが,はん(汎)化構造を定義する。isRoot は,
上位クラスがないときにだけ真とできる。isLeaf は,下位クラスがないときにだ
け真とできる。

name

各モデル要素は,その一意名をもつ。

4.5.2.24

  Generalization  はん(汎)化

はん(汎)化は,より一般的な要素とより特殊な要素との間の分類関係とする。より特殊な要素は,

(す

べての特性,メンバ,関係をもつ)より一般的な要素と完全に一致していて,付加的な情報を含むことが

できる。

メ タ モ デ ル で は , Generalization は , GeneralizableElement を 階 層 内 の よ り 一 般 的 な

GeneralizableElement

と結び付ける,方向付きの継承関係とする。Generalization は,下位型化

関 係 と す る ( す な わ ち , よ り 一 般 的 な GeneralizableElement の Instance を , よ り 特 殊 な

GeneralizableElement

の Instance によって置き換えてもよい。

。Generalization 関係の結果に

関しては,Inheritance を参照する。


29

X 4170

:2009 (ISO/IEC 19501:2005)

属性

discriminator Generalization リ ン ク が 属 す る 区 分 を 示 す 。 与 え ら れ た 上 位 ク ラ ス の

GeneralizableElement を共有するすべての Generalization リンクは,その
区別子名によって互いに素な集合に分割される。同じ区別子名をもつ各リンク集合
である各区分は,上位クラスの GeneralizableElement の特化の直交次元を表
現する。区別子は,一意でなくてよい。空文字列も,一つの区分名とみなされるの
で,すべての Generalization リンクは区別子をもつ。同一の上位クラスをもつ
GeneralizableElement の リ ン ク の 集 合 が す べ て 同 一 の 名 前 を も つ 場 合 ,
Generalization

リ ン ク の 下 位 ク ラ ス が 上 位 ク ラ ス を 特 化 す る

GeneralizableElement となり,そのインスタンスはすべて上位クラスの正当な
インスタンスとなる。そうでない場合には,上位クラスの間接インスタンスは,区
分のメンバの少なくとも一つの要素の(間接又は直接の)インスタンスでなければ
ならない。

関連

child

上 位 ク ラ ス の

GeneralizableElement

の 特 化 版 で あ る

GeneralizableElement を示す。

parent

下 位 ク ラ ス の GeneralizableElement の は ん ( 汎 ) 化 版 で あ る
GeneralizableElement を示す。

powertype Generalization で表現されたはん(汎)化次元に沿って,下位クラス要素のベ

キ型として働く Classifier を示す。したがって,この下位クラス要素はベキ型
要素のインスタンスとなる。

ステレオタイプ

«implementation»

下位クラスが上位クラスの実装(上位クラスの属性,操作,メソッド)を継承
するが,供給者のインタフェースを公開にせず,その提供を保証しない,した
がって,置換可能性を満たさないことを指定する。これは私的継承で,通常は,
プログラミング実装目的のためだけに使われる。

標準制約

complete

上位クラスのインスタンスは,すべて,このはん(汎)化集合内の少なくとも一つ
の下位クラスのインスタンスでなければならないという制約を指定する[同じ区別
子及び同じ上位クラスをもつはん(汎)化の集合に対し適用。

。上位クラスが単一

の区別子をもつ場合,下位クラスのはん(汎)化集合が完全であるとは,上位クラ
スが抽象であることを意味する。はん(汎)化集合が完全であると宣言する意味は,
与えられた区別子をもつすべての下位クラスが宣言されていて,追加は期待されな
いこと[すなわち,はん(汎)化集合は閉じている。

]とし,かつ,設計は下位ク

ラスの集合が固定されているとある程度の確信をもって仮定する。それにもかかわ
らず,新しい下位クラスが将来追加されるならば,既存のモデルには逆効果があり,
修正が必要となる。

disjoint

上位クラスのインスタンスは,はん(汎)化集合内部の与えられた下位クラスの一
つのインスタンスとなるという,はん(汎)化集合に適用される制約を規定する。
これは,はん(汎)化のデフォルト意味論となる。


30

X 4170

:2009 (ISO/IEC 19501:2005)

   

incomplete

上位クラスのインスタンスは,はん(汎)化集合内の下位クラスのインスタンスで
なくともよい(ただし,このようなインスタンスが存在するかどうかについては保
証がない。

)という制約を指定する[同じ区別子をもつはん(汎)化集合に対し適

用。

。不完全であるとは,上位クラスが具象であることを意味する。はん(汎)化

集合が不完全と宣言することは,与えられた区別子をもつすべての下位クラスが宣
言される必要はなく,下位クラスが追加されることがあることを意味する。したが
って,下位クラスの集合が固定だと期待しないことが望ましい。

overlapping

ある下位クラスのインスタンスが同時に集合内の他の下位クラスのインスタンス
である(しかし,このようなインスタンスが実際に存在することを保証するわけで
はない。

)という,はん(汎)化集合に適用される制約を指定する。

4.5.2.25

  Interface  インタフェース

インタフェースは,要素の振る舞いを特徴付ける,名前付けられた操作集合とする。

メタモデルでは,Interface は,その Interface を実現する Classifier が提供するサービスを定

義する Operation の集合を含む。Classifier は,複数のサービスを提供してもよい。すなわち,一つ

の Classifier が複数の Interface を実現したり,複数の Classifier が同じ Interface を実現し

てもよい。

Interface

は,GeneralizableElement とする。

Interface

は,Attribute,Association,及び Method をもってはならない。Interface は

Association

に参加してもよい,すなわち,

(Interface 以外の)Classifier から Interface に向

かう Association をもつことができる。ただし,このとき,Classifier から Interface は誘導可能,

Interface

から Classifier は誘導可能ではない,とする。

継承素性

Interface

は,Classifier に指定された素性を継承する。

4.5.2.26  Method

  メソッド

メソッドは,操作の実装とする。メソッドは,操作の結果をもたらすアルゴリズム又は手続を規定する。

メタモデルでは,Method は,Classifier における名前付けられた振る舞いの宣言とする。これは,

Classifier

の(直接的)単一操作,又は,

(間接的)操作集合を実現する。

一つの特定の分類子(メソッドの所有者として)及び操作(メソッドの仕様として)には,一つのメソ

ッドがある。

属性

body ProcedureExpression としての Method の実装。

関連

specification Method が 実 装 す る Operation を 示 す 。 Operation は , Method を も つ

Classifier がもつか,又は Classifier によって継承されなければならない。
Operation の呼出し仕様及び Method の呼出し仕様は,合致しなければならない。

4.5.2.27

  ModelElement  モデル要素

モデル要素は,モデル化しようとするシステムから抜き出した抽象化要素とする。人間が理解しやすい

ように情報を表現するための要素であるビュー要素と対比する。


31

X 4170

:2009 (ISO/IEC 19501:2005)

メタモデルでは,ModelElement は,Model 内の名前付きの実体である。ModelElement は,UML

内のすべてのモデル化メタクラスのための基底とする(ElementOwnership,ElementResidence,

ElementImport

,TemplateParameter,TemplateArgument 及び Argument のような図において明

示的に表示されないものであっても。)。その他のすべてのモデル化メタクラスは,直接又は間接的な

ModelElement

の下位クラスとする。

各 ModelElement は,テンプレートとみなすことができる。テンプレートは,ModelElement のどの

部分がテンプレートパラメタかを示す templateParameter の集合をもつ。少なくとも一つのテンプレ

ー ト パ ラ メ タ が あ る 場 合 , ModelElement は テ ン プ レ ー ト と な る 。 テ ン プ レ ー ト で な い 場 合 ,

ModelElement

はテンプレートパラメタをもつことはできない。しかし,このような埋め込みパラメタは,

通常,完全ではなく,正構造規則を満足する必要はない。テンプレートがインスタンス化したときに与え

られた引数は,正構造でなければならない。

部 分 的 に イ ン ス タ ン ス 化 さ れ た テ ン プ レ ー ト も 許 さ れ る 。 こ れ は , す べ て で は な い が 一 部 の

templateParameter

のために引数がある場合とする。部分的にインスタンス化されたテンプレートも,

パラメタがあるので,テンプレートには違いない。

属性

name

包含する Namespace 内の ModelElement の識別子。

関連

asArgument

モ デ ル 要 素 が テ ン プ レ ー ト を 束 縛 す る 引 数 と な る ゼ ロ 個 以 上 の
TemplateArgument を示す。

clientDependency

クライアントの逆。

ModelElement がクライアントとなる Dependency

集合を示す。

constraint

要素に影響を及ぼす Constraint の集合。

implementationLocation

実装モデル要素が所在するコンポーネント。

namespace ModelElement を含む Namespace を示す。ルート要素以外のすべての

ModelElement は,唯一の Namespace に属する。そうでなければ,

(あ

る種の仮想名前空間である。

)他の ModelElement の合成部分とする。

ルートパッケージから始まる Namespace 又は ModelElement の名前
の経路名は,すべての ModelElement に対して一意の名称を提供する。
関 連 属 性 の 可 視 性 は , そ の 名 前 空 間 外 の 要 素 の 可 視 性 を 規 定 す る
4.5.2.17 を参照)

presentation ModelElement のビューを表す PresentationElement の集合。 
supplierDependency

供給者の逆。ModelElement が供給者となる Dependency 集合を示す。


32

X 4170

:2009 (ISO/IEC 19501:2005)

   

templateParameter

(関連クラス TemplateParameter)パラメタの合成集約順序付き並
び。各パラメタは,テンプレートの束縛時に置換されるべき実際の
ModelElement に 対 す る 置 換 子 と し て 指 定 さ れ た ダ ミ ー の
ModelElement とする(4.5.2.8 を参照)

。実際のモデル要素は,ダミー

の ModelElement と同じであるか,又は子孫の一種でなければならな
い。ダミーの ModelElement の特性は,テンプレートパラメタの名前
と し て 使 わ れ る 名 前 を 除 い て は 無 視 さ れ る 。 関 連 ク ラ ス
TemplateParameter は,ダミーの ModelElement と同じ種類のデフ
ォルトの ModelElement と関連付けられ得る。パラメタに対応する引
数を供給しない Binding の場合には,デフォルトの ModelElement の
値 が 使 わ れ る 。 Binding が 引 数 を 欠 き , か つ , デ フ ォ ル ト の
ModelElement がない場合には,構成は無効となる。 
注記  テンプレートパラメタ要素は構造を欠いている。例えば,Class

であるパラメタは Feature を欠いている。しかし,Feature は
実引数には存在している。

ModelElement

が少なくとも一つの templateParameter をもつ場合,これはテンプレートであり,

そうでなければ通常の要素とする。

タグ付き値

derived

真値は,モデル要素が他のモデル要素から完全に導出されることができることを示
し,論理的には冗長である。分析モデルでは,その要素は有用な名前又は概念を定
義するために含まれる。設計モデルでは,通常,その要素は,再計算の必要を避け
るために実装において存在することが望ましいということを示す。

継承素性

ModelElement

は,GenerizableElement ではないが,その子孫の一部は GeneralizableElement

になる。次の要素は,GeneralizableElement である要素の下位クラスによって継承される。

constraint

下位クラスは,上位クラスのすべての制約の対象とする。

presentation

下位クラスは,省略時,上位クラスと同じに表されるが,上書きされてもよい。

stereotype

モデル要素が,ステレオタイプによって分類される場合,その下位クラスも,ステ
レオタイプによって分類される。下位クラスは,ステレオタイプで定義されたタグ
を使ってもよい。ステレオタイプで課される制約の対象となる。

taggedValue

タグがあるモデル要素に適用すると定義された場合(例えば,タグを定義するステ
レオタイプで分類されるから。

,タグは,モデル要素の下位クラスに適用する。

非継承素性

clientDependency 
supplierDependency

一般継承規則は,可能でない。

deploymentLocation

位置の集合は,異なってよい。下位クラスについては,制限が多いことが
よくある。

implementationLocation  下位クラスは,上位クラスと異なる実装でよい。 
name

各モデル要素は,自分の名前をもつ。名前は,継承されない。

namespace

下位クラス及び上位クラスの名前空間は異なってよい。

templateParameter

下位クラス及び上位クラスは,テンプレート構造が異なってよい。

4.5.2.28

  Namespace  名前空間

名前空間は,それぞれの名前がその名前空間内の一意な要素を示す ModelElement の集合を含むモデ


33

X 4170

:2009 (ISO/IEC 19501:2005)

ルの一部分とする。

メタモデルでは,Namespace は,Association,Classifier などの他の ModelElement を所有す

る ModelElement とする。所有された各 ModelElement の名前は,Namespace 内で一意でなければな

らず,更に,包含される各 ModelElement は一つの名前空間に所有される。Namespace の具象下位クラ

スは,含まれる要素の種類に関する付加的制約をもつ。Namespace は,抽象メタクラスとする。

Classifier

の素性のような,モデル要素の明示的部分は名前空間の被所有要素としてはモデル化され

ない。名前空間は,パッケージの内容,又は他のクラスの有効範囲内で宣言されたクラスのような,非構

造化内容のために使われる。

関連

ownedElement

(関連クラス ElementOwnership)Namespace のもつ ModelElement の集合。
この可視性属性は,要素が名前空間の外で可視かどうかを明示する。

4.5.2.29

  Node  ノード

ノードは,計算資源を表現する実行時の物理オブジェクトとする。一般には少なくとも一つのメモリを

もち,通常は処理能力をも備え,そのためにコンポーネントを配置することもできる。

メタモデルでは,Node は Classifier の下位クラスとなる。これは,Node 上に配置された Component

の集合に関連する。

関連

deployedComponent Node 上に配置された Component の集合。

継承素性

次の要素は,Classifier で規定されたものに加えて,下位クラスの Node に継承される。

(なし)

非継承素性

resident

存在要素の集合は,異なってもよい。下位クラスについては,通常は制限が厳しい。

4.5.2.30

  Operation  操作

操作は,振る舞いをもたらすためにオブジェクトから要求されるサービスとする。操作は,可能な実際

のパラメタ(可能な返却値も含む。

)を記述した呼出し仕様をもつ。

メタモデルでは,Operation は,その Operation を含む Classifier の Instance に適用可能な

BehavioralFeature

とする。


34

X 4170

:2009 (ISO/IEC 19501:2005)

   

属性

同じ受動インスタンス(すなわち,isActive が偽である Classifier から発生
するインスタンス。

)への並行的な呼出しの意味論を指定する。能動インスタンス

は,自分自体の Operation へのアクセスを制御するので,この特性は,通常は,
(UML で要求されているわけではないが。

)sequential に設定される。

 
可能性を次に示す。 
・  sequential : 呼 出 し 側 は ,( 任 意 の 逐 次 Operation に 関 し ) 一 つ の

Instance へのただ一つの呼出しだけが,一度に実行可能となるように調整し
なければならない。同時呼出しが発生した場合には,システムのその意味及び
システムの完全性は保証できない。

・  guarded : 並 行 ス レ ッ ド か ら の 多 重 呼 出 し が ,( 任 意 の ガ ー ド さ れ た

Operation に関し)一つの Instance に同時に発生してもよいが,開始を許
されるのはただ一つの呼出しだけとする。他の呼出しは,最初の Operation
の実行が完了するまでブロックされる。同時発生ブロックによるデッドロック
のないことを保証するのは,システム設計者の責任とする。ガードされた
Operation は,同時に発生した Operation が逐次である場合において,正
しく実行(又は自分自体をブロック)しなければならない。そうでないときに
は,guarded とはいえない。

concurrency

・  concurrent:並行スレッドからの多重呼出しが,

(任意の並行 Operation に

関し)一つの Instance へ同時に発生することができる。これらはすべて,正
しい意味をもって並行的に処理される。並行的な Operation は,同時に発生
した逐次又はガードされた Operation の場合には,正しく実行されなければ
ならない。そうでないときには,concurrent とはいえない。

isAbstract

真の場合,操作は実装をもたず,子孫は実装を与えなければならない。偽の場合,
操作はクラスに実装をもつか,又は祖先から継承しなければならない。

isLeaf

真の場合,操作の実装は子孫のクラスによって上書きされてはならない。偽の場合,
操作の実装は子孫のクラスによって上書きされてもよい(しかし,上書きされる必
要はない。

isRoot

真の場合,クラスは同じ操作の宣言を継承してはならない。偽の場合,クラスは同
じ操作の宣言を継承してもよい(しかし,継承しなくともよい。

。宣言は合致しな

ければならず,クラスは継承した操作宣言を修正してはならない。

タグ付き値

semantics semantics は,操作の意味規定とする。

4.5.2.31

  Parameter  パラメタ

パラメタは,変更,受渡し,返却が可能な束縛されない変数とする。パラメタには,名前,型,通信の

方向が含まれる。パラメタは,操作,メッセージ,イベント,テンプレートなどの指定に使われる。

メタモデルでは,Parameter は,Operation,Signal などに渡されたり,返却される引数の宣言と

する。

属性

defaultValue

評価すると,Parameter に引数が与えられない場合に使用する値をもたらす
Expression。


35

X 4170

:2009 (ISO/IEC 19501:2005)

kind

要求される Parameter の種類を指定する。 
 
可能性を次に示す。 
・  in:入力 Parameter。

(修正してはならない。

・  out:出力 Parameter。

(呼出し側に情報を通信するために修正してもよい。

・  inout:修正してもよい入力 Parameter。 
・  return:呼出しの返却値。

name Parameter の名前(ModelElement から継承される。

。Parameter 並び内で一

意でなければならない。

関連

type

引数の値が適合しなければならない Classifier を示す。

4.5.2.32

  Permission  許可

許可は,依存の一種とする。モデル要素に他の名前空間の要素に対するアクセスを保証する。

メタモデルでは,Permission をクライアントの ModelElement と供給者の ModelElement との間

の Dependency とする。クライアントは,供給者の内容への参照の許可を受け取る。供給者は Namespace

でなければならない。

Permission

の既定義ステレオタイプは,«access»,«import»

及び

«friend»

とする。

«access»

及び

«import»

の場合には,クライアントは,公開可視性をもつ供給者名前空間の要素を参照

する許可を与えられる。«import»

の場合には,供給者名前空間にある公開の名前がクライアント名前空

間に追加される。要素はまた,祖先の名前空間の任意の保護された内容にアクセスしてよい。さらに,要

素は,自分自身又は自分が含む名前空間のどのような内容(公開,保護,私的,又はパッケージ)にもア

クセスできる。

«friend»

の場合には,可視性にかかわらず,供給者名前空間の要素を参照する許可を与えられる。

ステレオタイプ

«access»

二つの名前空間の間のステレオタイプ付けされた許可依存とし,終点名前空間の公
開内容が,起点パッケージの名前空間にアクセス可能であることを示す。

«friend»

起点が操作,クラス又はパッケージのようなモデル要素で,目標が操作,クラス又
はパッケージのような異なるパッケージにあるモデル要素であるような,ステレオ
タイプ付けされた許可依存とする。«friend»

関係は,宣言された可視性にかかわ

らず,終点に対し起点へのアクセス権を与える。クライアントが供給者の内側を見
ることができるように可視性を拡張する。

«import»

二つの名前空間の間のステレオタイプ付けされた許可依存とし,終点パッケージの
公開内容が起点パッケージの名前空間に追加されることを示す。

4.5.2.33

  PresentationElement  表示要素

表示要素は,一つ以上のモデル要素の文章又は図による表示とする。

メタモデルでは,PresentationElement は読者に ModelElement の集合を表示する Element とす

る。これは表示に使われるすべてのメタモデルの基盤とする。この表示目的で使われる他のメタクラスは,

すべて PresentationElement の直接又は間接の下位クラスとする。PresentationElement は,抽

象メタクラスとする。このクラスの下位クラスは,図形エディタツールの領分で,ここでは規定されない。

将来の定義のための用意である。


36

X 4170

:2009 (ISO/IEC 19501:2005)

   

4.5.2.34

  Primitive  プリミティブ

Primitive

は,既定義の DataType を該当する UML 下位構造なしに定義する。すなわち,それは,

UML

部分をもたない。プリミティブデータ型は,UML の外で(例えば,数学的に)定義された代数又は

演 算 を も つ こ と が で き る 。 UML で 使 わ れ る Primitive デ ー タ 型 そ の も の は , Integer ,

UnlimitedInteger

及び String を含む。

Primitive

データ型の実行時インスタンスは,DataValue とする。その値は UML の外で定義された

数学的要素(例えば,各種の整数)に多対 1 対応にある。

4.5.2.35

  ProgrammingLanguageDataType  プログラム言語データ型

データ型は,その値が識別性をもたない型とする(すなわち,純粋な値とする。

。プログラム言語デー

タ型は,特定のプログラム言語の意味論に従って,その言語で利用できる構築要素を用いて規定されたデ

ータ型とする。

広範なプログラム言語が存在して,その多くは,UML 分類子に含まれない型構成要素を含む。場合によ

っては,プログラム言語で利用可能な正確な形式で,その構成要素を表現することが重要となる。

ProgrammingLanguageDataType

は,そのようなプログラム言語の型を言語依存の形式で把握する。そ

れらは,言語解釈に依存するが,言語の名前及びそれらを特徴付ける文字列で表現される。それらは,特

定の言語に依存するため,

(言語間の合意による場合を除いては)言語間で可搬でなく,他の UML 分類子

に対応付けない。したがって,それらの意味論は,特定言語に対して意図されたプロファイルによる特別

の解釈を除いて不透明となる。

多くの又はほとんどのプログラム言語型は,他の UML 分類子を用いて直接表現でき,そのような表現

は,より深い意味分析を可能にする。

ProgrammingLanguageDataType

は , そ の 名 前 が な く て も よ い 。 名 前 の な い 二 つ の

ProgrammingLanguageDataType

は,等価とは考えない。

属性

expression ProgrammingLanguageDataType の式は,そのプログラム言語で表現される。

継承素性

UML

では,継承特性が未定義の言語依存構成要素を定義することを意図する。

4.5.2.36

  Relationship  関係

関係は,モデル要素の間の接続とする。

メタモデルでは,Relationship は特定の意味をもたない便宜的用語とする。Relationship は抽象

メタクラスとする。

Relationship

の下位クラスは,Association,Dependency,Flow 及び Generalization とす

る。

4.5.2.37

  StructuralFeature  構造素性

構造素性は,属性などの,モデル要素の静的な素性を参照する。

メタモデルでは,StructuralFeature は,Attribute などの Classifier の Instance の構造上

の 側 面 を 宣 言 す る 。 例 え ば , そ の StructuralFeature の 多 重 度 及 び 変 更 可 能 性 を 指 定 す る 。

StructuralFeature

は,抽象メタクラスとする。


37

X 4170

:2009 (ISO/IEC 19501:2005)

属性

changeability

オブジェクトが生成された後に,値が修正されるかどうか。 
 
可能性を次に示す。 
・  changeable:修正への制限なし。 
・  frozen:オブジェクトのインスタンス化及びその初期化後に,値を変更して

はならない。値の集合に追加をしてはならない。

・  addOnly:多重性が単一値に固定されていない場合に限って意味をもつ。追加

値を,値の集合に追加してよいが,値を一度生成したならば,削除又は変更し
てはならない。

multiplicity

インスタンスに保持される素性のデータ値の数。値集合の基数は,素性の暗黙部分
とする。多重度が 1..1 である場合には,素性はスカラーで,すなわち,正確に一つ
の値を保持する。

ordering

インスタンス集合が順序付けられているかどうかを規定する。順序付けは,素性に
値を追加する Operation によって決められ維持されなければならない。この特性
は,多重度が 1 より大きい場合にだけ妥当とする。 
 
可能性を次に示す。 
・  unordered:インスタンスは,固有順序のない集合を形成する。 
・  ordered:順序付きインスタンスの集合は,順番に走査することができる。 
・  他の可能性(整列などの)は後で,追加キーワードを宣言することによって定

義される。ユーザ定義ステレオタイプの場合と同様,これは特定の編集ツール
によって提供された私的拡張となる。

targetScope

対象が Instance なのか,Classifier なのかを指定する。 
 
可能性を次に示す。 
・  instance:各値は,対象とする Classifier の Instance への参照を含む。

これは通常の Attribute に対する設定とする。

・  classifier:各値は,対象とする Classifier そのものへの参照を含む。こ

れは,メタ情報を格納する方法を表現する。

関連

type

インスタンスが素性の値である分類子を示す。Class,Interface 又は DataType
でなければならない。 
実際の型は,宣言された型又は(Interface のための)宣言された型を実現する
Class の子孫であってよい。

タグ付き値

persistence

素性の状態の永続性を示し,遷移的(インスタンスが削除されるとその状態も破棄
される。

)又は永続的(インスタンスが削除されてもその状態が破棄されない。

)と

マークする。

4.5.2.38

  TemplateArgument  テンプレート引数

テンプレート引数は,Binding とその引数の一つ(ModelElement)との間の関係を具体化する。

関連

binding

テンプレート引数を所有する Binding。

modelElement

対象 Binding の実引数。


38

X 4170

:2009 (ISO/IEC 19501:2005)

   

4.5.2.39

  TemplateParameter  テンプレートパラメタ

テンプレートパラメタは,テンプレート(ModelElement)とそのパラメタ(ModelElement)との間

の関係を定義する。少なくとも一つの templateParameter 関連をもつ ModelElement は,

(定義から)

テンプレートとする。

メタモデルでは,TemplateParameter は,テンプレートである ModelElement とテンプレート引数

のための置換子のダミーの ModelElement との間の関係を具体化する。詳細については,4.5.2.27 を参照

する。

関連

defaultElement ModelElement の選択可能な既定値。具体化された TemplateParameter クラス

関連のテンプレートの ModelElement の Binding の場合には,対応するテンプレ
ートパラメタに引数が与えられなかった場合に,束縛済み要素の引数として,
defaultElement が用いられる。引数が与えられず,しかも既定値がない場合に
は,モデルは適格性を欠く。

4.5.2.40

  Usage  使用

使用は,完全な実装又は操作のために,ある要素が他の要素(又は要素集合)を必要とする関係とする。

使用で関係付けられた二つの要素は同じモデルの中になければならない。

メタモデルでは,Usage は,クライアントが供給者の存在を必要とする Dependency とする。クライ

アントが供給者をどのように使用するかは,その«Usage»の記述中に定義され,例えば,クラスが他のク

ラスの操作を呼び出す,メソッドが他のクラスの引数をとる,他のクラスをインスタンス化するクラスの

メソッドなどとなる。

Usage

の各種のステレオタイプは前もって定義されるが,その集合は開で,追加可能とする。

ステレオタイプ

«call»

起点が操作であり,終点も操作であるステレオタイプ付けされた使用依存とする。
この関係は,依存が適用されるクラスにその操作が存在するという意味で,操作を
もつクラスを起点及び終点とすることができる。call 依存は,起点操作又は起点
クラスの操作が終点操作及び終点クラスの操作を呼出すことを指定する。call 依
存は,取り囲む分類子の操作,及び他の可視性である分類子の操作を含み,それに
限定されない適用範囲内のどの終点操作とも起点操作をつなげてよい。

«create»

クライアント分類子が供給者分類子のインスタンスを生成することを示すステレ
オタイプ付けられた使用依存とする。

«instantiate»

クライアント上の操作が供給者のインスタンスを生成することを示す分類子間の
ステレオタイプ付けられた使用依存とする。

«send»

起点が操作で,終点がシグナルであり,起点が目標シグナルを送ることを規定する
ステレオタイプ付けられた使用依存とする。

4.5.3

正構造記述

注記 OCL で記述された各要素に対する正構造記述は,一般の UML 利用者には必要はないので,こ

の規格では不採用とした。

4.5.4

詳細意味論

注記  (対応国際規格では,4.5.4 は解説的内容であるため,この規格では不要であり,不採用とした。)


39

X 4170

:2009 (ISO/IEC 19501:2005)

4.6

Extension Mechanisms

  拡張機構パッケージ

4.6.1

概要

Extension Mechanisms

パッケージは,ステレオタイプ,制約,タグ定義及びタグ付き値を用いて新

しい意味論によって特定の UML モデル要素がいかにカスタム化されたり拡張されたりするかを指定する

下位パッケージとする。特定の目的のために定義されたそのような拡張の一貫した集合が UML プロファ

イル(4.14 を参照)を構成する。

UML

は,典型的なソフトウェアモデル化プロジェクトの要求に合致するように注意深く定義された豊富

なモデル化の概念及び記法の集合を提供する。しかし,利用者は UML 標準で定義されたものを越えた付

加的な機能を求めてもよい。こうした要求に対して UML では,モデル作成者のレパートリに新たな種類

のモデル化要素を追加したりモデル化要素に自由形式で情報を付加することを可能にする,組込みの拡張

機構によって対応している。基本となる拡張機構は,ステレオタイプの概念である。これによって,UML

メタクラスに対して新たなメタ属性及び追加的な意味論をもつ仮想的な下位クラスを定義する手段を提供

する。

プロファイルの拡張機構を用いて定義されたすべての拡張に対する基本的な制約は,拡張は標準の UML

意味論に対して厳密な意味で加算的でなければならない。そのような拡張であれば標準意味論と衝突した

り矛盾したりすることはない。結果として,こうした拡張機構は UML の標準意味論を洗練する手段であ

り,任意の意味拡張を支援することはない。プロセス固有又は,実装言語固有の領域(例えば特定の言語

及び環境に対するコード生成の支援)の UML モデルを作成するために,UML に新しいモデル化要素を追

加することが許される。ステレオタイプ及びタグは UML 自身の定義に使用されている。UML メタクラス

として直接定義するほどには複雑でないとみなされた標準モデル要素の定義に使用されている。

各ステレオタイプはそれ自身 UML のメタクラスである。したがって,UML ツールの利用者はステレオ

タイプを定義することができるので,例えば新たな«persistent»をクラスに付加できるように定義する

ことができる。多くの利用者は,新たなステレオタイプを定義したりはせず,モデル化のときに例えば単

に“«persistent»”をクラス“請求書”に付加するという形でただ適用するだけに留まる。

プロファイルとは,ステレオタイプ化されたパッケージであり,ステレオタイプ,タグ付き定義,及び

制約を用いてメタモデルを拡張することによって特定の領域又は目的のためにカスタム化されたモデル要

素を含む。プロファイルは,依存するモデルライブラリ及び拡張したメタモデルサブセットを指定しても

よい。

ステレオタイプとは,

(タグ定義に基づく)追加的な値,追加的な制約,及び必要ならば新しい図的表現

を定義するモデル要素とする。一個以上の特定のステレオタイプをは(貼)られたすべてのモデル要素は,

その要素が標準 UML においてもつ属性,関連及び上位クラスに加えて,これらの追加的な値及び制約を

受け取ることになる。

ステレオタイプは元々の UML メタモデルのクラス階層に基づく分類機構を補強するものなので,新た

なステレオタイプは事前定義された UML メタモデル要素又は標準要素の名前と衝突してはならない。

タグ定義は,モデル要素に付加する新しい特性を指定する。個別のモデル要素の実際の特性はタグ付き

値を用いて指定される。これらは単純なデータ型の値又は他のモデル要素への参照である。タグ定義は,

メタ属性定義と対比でき,タグ付き値はモデル要素へ付加する値に対応する。タグ付き値は,管理情報[著

者,納期,進ちょく(捗)状況など]

,コード生成情報(最適化レベル,コンテナクラスなど)のような特

性を表現することに用いることもできる。

制約も,意味論を洗練するために任意のモデル要素に付加することができる。ステレオタイプに付加さ


40

X 4170

:2009 (ISO/IEC 19501:2005)

   

れた制約は,そのステレオタイプをは(貼)られたすべてのモデル要素によって守られなければならない。

規則がプロファイル内で形式的に定義されている(例えば,制約表現に対し OCL を用いている。

)場合に

は,モデル化ツールはそのプロファイルを適用するときにその規則を解釈してモデル作成者が制約を守る

ことを強制するような支援を可能としてもよい。

これは UML 仕様の適用範囲及び意図の想定外であるが,新たなメタクラス及びその他のメタ要素を明

示的に追加することによって UML メタモデルを拡張することも可能である。この機能は,OMG メタオブ

ジェクトファシリティ(MOF)を支援するツール及びリポジトリの使用に依存する。プロファイルは,UML

の組込みの“軽量な”拡張機構といわれるが,MOF によって定義される“重量級の”拡張機構と対比して

こう呼ばれる。これは UML プロファイルが UML メタモデルを拡張する方法に制限があるためである。そ

のような制限は MOF 利用の文脈には適用されず,原則的には任意のメタモデルが定義可能である(結果

として,すべてのプロファイル定義は MOF メタモデルとしても表すことができるが,逆に UML に基づく

すべての MOF メタモデルが適正な UML プロファイルとして定義できるわけではない。

実用的な観点からは,軽量な拡張を指定するためにモデル化ツールを使用するときに,UML 拡張機構(拡

張要素に対する既定の図式記法を含む。

)及び UML DTD に対する事前定義 XMI と互換性のある XMI 生成

能力を完全に提供するのが望ましい(これは MOF メタモデルに基づく専用の XMI フォーマットよりも可

読性があることを期待しているわけではない。

プロファイルを定義するときにモデル作成者は,UML メタモデル中で最も意味論的に類似した要素を拡

張の基底にするように注意深く選択することが望ましい。これを遵守しないと容易に意味論的に誤ってい

たり冗長な言語拡張が生じてしまう。

(領域に対応したツール化を目的とした)

プロファイルの定義におい

て領域に対する意味論の拡張を行うときに,モデル作成者は新たなステレオタイプ定義に固執しすぎない

よう注意を払うことが望ましい。ほとんどの場合,ステレオタイプと既存の標準モデル要素との組合せが

最も効果的であろう。あるプロファイル定義内の標準又は一般のモデル要素の例は,利用者が再利用又は

下位クラス化を意図した複数の標準のクラス又は利用者が適用できる標準テンプレートの集合である。

プ ロ フ ァ イ ル に 関 連 し た 幾 つ か の 標 準 の ス テ レ オ タ イ プ ( «profile» , «modelLibrary» ,

«appliedProfile»

)及びタグ(

{applicableSubset}

)が Model Management パッケージ中に定

義されている。

次の箇条では,Extension Mechanisms パッケージの抽象構文について記述する。

4.6.2

抽象構文

Extension Mechanisms

パッケージに対する抽象構文は,

図 10 の図式記法に表現されている。


41

X 4170

:2009 (ISO/IEC 19501:2005)

図 10Extension Mechanisms パッケージ

4.6.2.1

Constraint

  制約(4.5.2.13 の拡張)

制約は,モデル要素に対して新しい意味論を言語的に指定することを許す概念とする。その仕様は特定

の制約言語による式として表現される。

その言語は,

(OCL のように)制約を記述するために特に設計されたものとすることもできるし,プロ

グラム言語,数学的記法又は自然言語とすることもできる。モデル編集ツールで制約の入力を強制する場

合には,ツールは制約言語の構文と意味論とを理解しなければならない。言語の選択は任意なので,制約

は拡張機構の一つである。

メタモデルでは,モデル要素に直接付加された制約は,このモデル要素が従わなければならない意味論

的な制限を記述する。ステレオタイプに付加された制約は,そのステレオタイプをもつ各モデル要素に適

用される。ただし,ステレオタイプ定義に付加された制約の場合には,その制約の適用範囲は UML メタ

モデルであって,それが定義されたモデルに対してではない。したがって,ステレオタイプに対する正構

造の定義は,他のメタモデル要素に対する正構造記述と同じように行える。

属性

body

制約を定義する論理式。式は,指定された言語の文字列として書き表す。モデルが
適格であるためには,システムの安定時,すなわち原子的操作の実行中ではないと
きにはいつでも,制約を受ける要素のインスタンスを評価するとこの式からは必ず
真値が返されなければならない。 
 
制約がステレオタイプに付加されているとき,その制約の適用範囲は UML メタモデ
ルであり,その制約が定義されている M1 モデルに対してではない。これは UML メ
タモデルを明示的に移入する必要がないことを意味する。


42

X 4170

:2009 (ISO/IEC 19501:2005)

   

関連

constrainedElement

その制約を受ける要素の順序付き並び。

constrainedStereotype  その制約が適用されるステレオタイプ。この制約は,自動的にそのステレ

オタイプをは(貼)られたすべてのモデル要素に適用される。

任 意 の

Constraint

は , 一 つ 以 上 の

constrainedElement

リ ン ク 又 は 一 つ の

constrainedStereotype

リンクのいずれかであり,両者を同時にもつことはない。

4.6.2.2

ModelElement

  モデル要素(4.5.2.27 の拡張)

モデル要素は,任意のタグ付き値及び(それらが意味をなすために受ける)制約をもつことができる。

モデル要素は,一つ以上のステレオタイプをもつことができる。その場合,そのステレオタイプの基底と

なるクラスは,そのモデル要素のメタクラス(Class,Association,Dependency など)又はその下

位クラスの一つと合致する必要がある。ステレオタイプの存在は,モデル化要素に暗黙の制約を置くこと

を可能にするとともに,特定のタグ付き値の存在を要求できる。ステレオタイプの存在は,モデル化要素

に制約を課し,特定のタグ付き値の存在を要求してもよい。

関連

constraint

制約は,そのモデル要素によって満足されなければならない。モデル要素は,制約
の集合をもつことができる。制約はシステムの安定時,すなわち原子的操作の実行
中ではないときに評価されなければならない。

stereotype

そのモデル化要素の UML メタクラス(基底クラスがその下位クラスの一つ)を,
更に限定するステレオタイプを指定する。そのステレオタイプは適用対象のメタク
ラスの標準意味論と衝突したり矛盾したりせず,追加的な制約及びタグ定義を指定
することを可能にする。あるステレオタイプに対するすべての制約及びタグ定義
は,そのステレオタイプのは(貼)られたモデル要素に適用される。ステレオタイ
プは,そのモデル要素を記述する仮想的なメタクラスとして振る舞う。

taggedValue

関連するタグ定義に基づいて任意の特性をモデル要素に付加することができる。タ
グ付き値の解釈は,UML メタモデルの適用範囲外である。

4.6.2.3

Stereotype

  ステレオタイプ

ステレオタイプの概念は,モデル要素に対して新たな仮想的なメタモデル要素のインスタンスであるか

のように取り扱うことを可能にし,一種の名付けを行う(分類する)手段を提供する。このようなモデル

要素は,同種の類似したモデル要素でステレオタイプなしのものと同じ構造(属性,関連,及び操作)を

もつ。ステレオタイプは,そのモデル要素に適用する追加的な制約及びタグ定義を指定してもよい。さら

に,ステレオタイプは,同一の構造をもつ二つのモデル要素の間の意味の違い及び使い方の違いを示すの

に利用してもよい。

メタモデルでは,Stereotype メタクラスは GeneralizableElement の下位クラスである。ステレ

オタイプに付加されたタグ定義及び制約は,そのステレオタイプによって名付けられたモデル要素すべて

に対して適用される。ステレオタイプは,要素を表すのに用いるための表示用アイコンを指定してもよい。

ステレオタイプが他のステレオタイプの下位クラスである場合,その上位型のステレオタイプからすべ

ての制約及びタグ付き値を継承し,その基底クラスと同種のものに適用しなければならない。ステレオタ

イプは,その適用してもよい基底クラスを常に把握している。関連する Stereotype 群は通常,一つの

Profile

パッケージにまとめられる。


43

X 4170

:2009 (ISO/IEC 19501:2005)

属性

baseClass

例えば,Class,Association,Refinement 又は Constraint といった一つ以
上の UML モデル要素の名前をステレオタイプの適用先として指定する。これはメ
タクラスの名前であり,利用者向けのモデルクラスというよりは UML メタモデル
から取られたクラスに対するものである。

icon

このステレオタイプで名付けられたモデル要素を表示するときに利用されるアイ
コンの幾何学的表現。

関連

extendedElement

ステレオタイプによる影響を受けるモデル要素を指定する。それぞれ,
baseClass 属性によって指定された同種のモデル要素でなければならな
い。

definedTag

それぞれがタグ付き値を指定するタグ定義の集合を指定する。そのステレ
オタイプが名付けたモデル要素がそれぞれのタグ付き値を保持可能にな
る。

stereotypeConstraint

このステレオタイプによって名付けられたモデル要素すべてに対して適
用される制約を指定する。これらの制約は,UML メタモデル全体を適用範
囲として定義される。

4.6.2.4

TagDefinition

  タグ定義

タグ定義は,ある種のモデル要素に付加可能なタグ付き値を指定する。タグ定義は,付加するステレオ

タイプに仮想的なメタ属性を定義するのに用いることができる。これらのメタ属性の幾つかは他のメタモ

デル要素への参照であってもよいので,結果として新たな片方向のメタ参照を指定するのに利用できる。

しかし,そのような利用法は慎重に行わないと,元々の UML メタモデルの単なる洗練以上の新たな意味

論を定義するという誤った使用に容易に陥る危険がある。

タグ定義はステレオタイプと併せて定義したほうがよい,そうすることによってステレオタイプはその

基底クラスの意味論に制約付けられるという規律を守った利用がより適正に実施できる。しかし,主とし

て,UML1.3 の基礎の上に定義されたモデルとの互換性という理由によって,ステレオタイプと関連付け

られていないタグ定義の導入も現在可能になっている。

属性

multiplicity

このタグに基づくタグ付き値が取り得るデータ値の数,又は関係するタグ付き値に
関連付けられたモデル要素の数を指定する。

tagType

一般の場合には,タグの型はデータ型であり,この属性は,タグ定義に関連付けら
れたタグ付き値の取り得る値の範囲を指定する。 
 
特殊な場合として,タグの型がデータ型以外のメタクラスを参照しているときに
は,タグの値はそのメタクラスのインスタンスであるモデル要素を参照する。

関連

typedValue

そのタグ定義に適合するタグ付き値。

owner

そのタグ定義が属するステレオタイプ。

4.6.2.5

TaggedValue

  タグ付き値

タグ付き値は,タグ定義に適合する任意のモデル要素に対して情報を付加することを可能にする。


44

X 4170

:2009 (ISO/IEC 19501:2005)

   

ModelElement

のインスタンスであるタグ付き値は,自動的に name 属性を継承しているが,タグ付き値

で実際に用いられている名前は,関連するタグ定義の名前となる。タグ付き値の解釈は,意図的に UML

意味論の適用範囲外としている。したがって,その解釈は,利用者又はタグ値を定義したプロファイルに

おいて指定されたツール規約によって決定されなければならない。様々なモデル分析ツールが UML の基

礎意味論を超えて,操作に対し必要とされる情報を提供するようにタグ定義を導入することが期待される。

そのような情報として,コード生成選択肢,モデル管理情報,ユーザ固有の意味論などを含むことができ

る。

いずれのタグ付き値も,一つ以上の参照値リンク又は一つ以上のデータ値のいずれかをもたなければな

らないが,それらを両方同時にもつことはできない。

属性

dataValue

タグ付き値の一部となる値の集合を指定する。この値の型は,タグ定義に関連付け
られた tagType 属性で指定された型に適合しなければならない。指定可能な値の
数は,関連するタグ定義において多重度を表す multipliticty 属性によって定義
される。

関連

type

タグ付き値の名前,意味,型を定義するタグ定義を指定する。

referenceValue

このタグ付き値が参照するモデル要素を指定する。これらの要素は,メタモデルに
おけるモデル水準のインスタンスか又はタグ定義に対応する tagType 属性によっ
て指定されるステレオタイプのいずれかである。参照の数は,関連するタグ定義の
multiplicity 属性によって定義される。

4.6.3

正構造記述

注記 OCL で記述された各要素に対する正構造記述は,一般の UML 利用者には必要ないので,この

規格では不採用とした。

4.6.4

詳細意味論

注記  (対応国際規格では,4.6.4 は解説的内容であるため,この規格では不要であり,不採用とした。)

4.6.5

注記

注記  (対応国際規格では,4.6.5 は解説的内容であるため,この規格では不要であり,不採用とした。)

4.7

Data Types

  データ型パッケージ

4.7.1

概要

Data Types

パッケージは,UML を定義するのに使われている異なったデータ型を指定するための下

位パッケージとする。これらの基本概念の意味論はよく知られていると想定できるため,この箇条は他の

パッケージに比べて単純な構成になっている。

4.7.2

抽象構文

Data Types

パッケージに対する抽象構文は,

図 11 及び図 12 に表現されている。


45

X 4170

:2009 (ISO/IEC 19501:2005)

図 11Data Types パッケージの主要部

図 12Data Types パッケージの式部

メタモデルでは,データ型はクラスの属性の型を宣言するのに用いられる。それらは図中の文字列とし

て現れるのであって,独立した“データ型”アイコンとして表示されるわけではない。そうすることで,

図の大きさを小さくできる。しかし,データ型の特定の名前が複数回登場したとしても,それらはすべて

同一のデータ型を示している。

これらのデータ型は,UML の定義に使用されているものであり,UML 利用者によって使われるデータ

型を意味しているわけではない。利用者向けのデータ型は,メタモデル内で定義された DataType メタク

ラスのインスタンスである。

4.7.2.1

ActionExpression

  動作式

動作式は,その評価結果が動作の実行となる式とする。

4.7.2.2

AggregationKind

  集約種別

集約種別は,その Association がどの種類の集約かを指定する列挙型とする。関連の終点に置かれた

場合,関連の終点から始点への関係を指定する。AggregationKind は,次の値をとる列挙型を定義する。


46

X 4170

:2009 (ISO/IEC 19501:2005)

   

none

この端点は,集約体ではない。

aggregate

この端点は,集約体である。したがって,他方の端点はその部分となり集約種別の
値は none をとらなければならない。部分は,他の集約に包含されてもよい。

composite

この端点は,合成体集約である。したがって,他方の端点はその部分となり集約種
別の値は none をとらなければならない。この部分は合成体集約側によって強い意
味で所有され,他のいずれの合成体集約の部分にもなることは許されない。

4.7.2.3

ArgListsExpression

  引数並び式

メタモデルでは,ArgListsExpression は,評価されたときにオブジェクトの並びの集合を返す文を

定義する。

4.7.2.4

Boolean

  論理型

メタモデルでは,Boolean は,論理条件を指す列挙型を定義する。その列挙型のリテラルは,次のいず

れかである。

true Boolean の条件は,満足している。 
false Boolean の条件は,満足していない。

4.7.2.5

BooleanExpression

  論理式

メタモデルでは,BooleanExpression は,評価されたとき Boolean のインスタンスを返す文とする。

4.7.2.6

CallConcurrencyKind

  呼出し並行性種別

呼出し並行性種別は,同じ受動インスタンスに対する複数の並行呼出しの意味論を指定するための列挙

型とする。受動インスタンスとは,isActive=false であるようなある Classifier に基づく Instance

のことである。この列挙型は,次の値をとる。

sequential

呼出し側は,ある Instance に対する任意の sequential 宣言された Operation
に関して一度にただ一つの呼出しだけが特定されるように調整する必要がある。同
時呼出しが起こった場合には,システムの意味論及び完全性は保障できない。

guarded

複数の並行スレッド群からの複数呼出しが,ある Instance に対する任意の
guarded 宣言された Operation に関して同時に起きる可能性があるが,その中の
ただ一つだけが開始を許される。その他の呼出しは最初の Operation の実行が完
了するまでブロックされる。同時ブロックに起因するデッドロックが起きないこと
を保障するのは,システム設計者の責任である。guarded 宣言された Operation
は,sequential 宣言された Operation の同時呼出しの場合にも正しく実行され
る(又はお互いにブロックする)必要があり,それが保証されない場合は呼出しの
意味論に guarded を指定することはできない。

concurrent

複数の並行スレッド群からの複数呼出しが,ある Instance に対する任意の
concurrent 宣言された Operation に関して同時に起きることを許す。それらの
呼出 し は 正 し い意 味 論 に基 づ い て並 行に進 行す る。concurrent 宣 言され た
Operation は sequential 又は guarded 宣言された Operation との同時呼出
しの場合にも正しく実行される必要があり,それが保障されない場合は呼出しの意
味論に concurrent を指定することはできない。

4.7.2.7

ChangeableKind

  変更可能性種別

メタモデルでは,ChangeableKind は,ある AttributeLink 又は LinkEnd が受入れ可能な変更を

指定する列挙型を定義する。その値を次に示す。


47

X 4170

:2009 (ISO/IEC 19501:2005)

changeable

変更に関しての制限がない。

frozen

対象オブジェクトの生成及び初期化以後において,その対象オブジェクトの値が変
更されることを許さない。他方の端点の Operation は値を変更してもよい。

addOnly

多重度が固定でない場合,その端点のオブジェクトの値を任意の時点で追加しても
よいが,一度生成された値をその端点から削除することは許さない。他方の端点へ
のある Operation がその値を変更することはあり得る。

4.7.2.8

Expression

  式

メタモデルでは,Expression は,与えられた文脈で実行されるとインスタンスの集合(空を含む。

を結果として返す文を定義する。各 Expression は,それが評価される環境を変更することはない。式は,

式を表す文字列及びその文字列を評価するときに用いられる解釈言語の名前を含む。

属性

language

その式の本体を表現している言語の名前を指定する。式の解釈は言語に依存する。
言語の名前が省略された場合,UML においてはその式に対する解釈は与えられな
い。

body

与えられた言語によって表現された,その式に対するテキスト本体。

事前定義の言語の名前には次のものが含まれる。

OCL

オブジェクト制約言語 OCL(箇条 を参照)

(空文字列)  これは自然言語の文を表している。そのような場合,明らかに形式
仕様ではなく人間向けの情報を意図している。

一般に,言語名は言語仕様書に現れているとおりのつづりで大小文字区別を厳密に表記することが望ま

しい。例えば,Cobol ではなく COBOL,ADA ではなく Ada,Postscript ではなく PostScript などを用いる。

言い換えると,正確につづるということである。

4.7.2.9

Geometry

  ジオメトリ

ジオメトリは,例えば,ステレオタイプに付加するアイコンのような幾何学図形を記述するために用い

る非解釈の型とする。この仕様の詳細は,モデル編集ツールの実装によって提供されなければならない。

したがって,この型は実際にはメタモデルには定義されないが,属性の型としてだけ利用される。

4.7.2.10

  Integer  整数型

メタモデルでは,Integer は,Primitive のインスタンスである分類子要素とし,整数の組込み型を

表す。Integer のインスタンスは,整数の無限集合(…−2,−1,0,1,2…)の要素である。

4.7.2.11

  IterationExpression  反復式

メタモデルでは,IterationExpression は,解釈言語の反復制御構造として評価される文字列を定

義する。

4.7.2.12

  LocationReference  位置参照

位置参照は,振る舞いシーケンス中に拡張ユースケースを挿入する位置を指定する。指定方法は,コー

ド中の行若しくは行の範囲,状態マシン中の状態若しくは状態の集合,又は別の記述方式の仕様書におけ

る何らかの手段でよい。


48

X 4170

:2009 (ISO/IEC 19501:2005)

   

4.7.2.13

  Mapping  対応付け

メタモデルでは,Mapping のそれぞれは,ModelElement を写像するための式とする。これは交換の

目的で String として表される。

属性

body

対応付けを表現する文字列。対応付けの形式は,現在 UML では規定されていない。

4.7.2.14

  MappingExpression  対応付け式

Mapping

と評価される式。

4.7.2.15

  Multiplicity  多重度

メタモデルでは,Multiplicity は,非負の整数からなる空でない集合を定義する。ゼロだけからなる

集合({0})は,有効な Multiplicity とは認められない。すべての Multiplicity は,少なくとも一つ

の対応する String 表現をもつ。

4.7.2.16

  MultiplicityRange  多重度範囲

メタモデルでは,MultiplicityRange は,整数の範囲を定義する。範囲の上限は下限を下回ってはな

らない。下限は,非負整数でなければならない。上限は,非負整数又はその範囲の上限が存在しないこと

を示す特殊な値 unlimited でなければならない。

4.7.2.17

  Name  名前

メタモデルでは,Name は,ModelElement 群に名前を付けるのに使われるトークンを定義する。名前

は String として表現される。

4.7.2.18

  ObjectSetExpression  オブジェクト集合式

メタモデルでは,ObjectSetExpression は,インスタンスの集合を評価される文を定義する。

ObjectSetExpression

は,Action において対象インスタンスを指定するのに一般的に使用される。

SendAction

の対象として使用される場合,式は予約語“all”を用いる。これを評価すると,基盤とな

る実行時システムで決められたとおり,信号を受け取れるすべてのインスタンスが結果として返る。

4.7.2.19

  OrderingKind  順序付け種別

順序付け種別は,集合の要素をどう並べるかを指定する列挙型を定義する。多重度の値が 1 以上のとき

多重度をもつ要素群と併せて用いられる。順序付けは,その集合を変更する操作によって決定され維持さ

れなければならない。列挙型のリテラル集合は,設計,コード生成などの目的のためにツールによって新

しい値が追加できるようにオープンである。例えば,整列済みという値を設計仕様で利用することも考え

られる。

値は,次のとおりとする。

unordered

集合の要素は,固有の順序をもたない。 
集合の要素は,逐次的順序をもつ。

ordered

他の可能性(整列済みなど)を追加的なキーワードを宣言することによって後から
定義してもよい。利用者定義ステレオタイプとして,特定の編集ツールによってサ
ポートされる私的な拡張となる。

4.7.2.20

  ParameterDirectionKind  パラメタ方向種別

メタモデルでは,ParameterDirectionKind は,ある Parameter が引数を提供しているのか,及び


49

X 4170

:2009 (ISO/IEC 19501:2005)

/又は,返却値を返しているのかを指定する列挙型を定義する。列挙型の値を次に示す。

in

入力用の Parameter(値は変更されない)である。

out

出力用の Parameter(呼出し側へ情報を伝えるために値が変更されてよい。

)であ

る。

inout

変更可能な入力用の Parameter である。

return

呼出しの返却値である。

4.7.2.21

  ProcedureExpression  手続式

メタモデル中では,ProcedureExpression は,評価されると結果としてその環境の値を変更する文

を定義する。

4.7.2.22

  PseudostateKind  擬似状態種別

メタモデルでは,PseudostateKind は,Pseudostate の種類を区別する列挙型を定義する(詳細は

4.12.2.7

を参照)

。列挙型の値を,次に示す。

choice

入力遷移を複数の互いに素な出力遷移に分割する。各出力遷移はガード条件をも
ち,入力経路上の事前の動作が完了した後で評価される。少なくとも一つの出力遷
移が活性化しなければ,そのモデルは不適格である。

deepHistory

遷移の終点に到達したときに,包含する複合状態から最後に抜け出る直前に活性で
あった完全な状態の構成を復元する。

fork

入力遷移を複数の並行出力遷移に分割する。すべての遷移は一緒に発火する。

initial

包含する複合状態への遷移のデフォルトの終点。

join

並行領域から単一の出力遷移への複数の遷移を合併する。すべての遷移は一緒に発
火する。

junction

単一の完了実行する経路として複数の遷移を一緒につなぐ。複数の入力又は出力を
もつことができる。junction をもつ各完了経路は論理的に独立しており,一度に
はただ一つの完了経路だけが発火する。分岐及び合流を構成するのに利用される。

shallowHistory

遷移の終点に到達したときに,包含する状態から最後に抜け出る直前に活性であっ
た複合状態内の一つの状態を復元する。最後に活性であった状態の任意のサブ状態
が復元されるわけではない。

4.7.2.23

  ScopeKind  適用範囲種別

メタモデルでは,ScopeKind は,ある素性が特定のインスタンスに属するのか又はその分類子全体に

属するのかを定義する。その値を,次に示す。

instance

その素性がある Classifier の Instance 群に付随する。例えば,各 Instance
のそれぞれの Attribute 又はある Instance に対して作用する Operation であ
る。

classifier

その素性がある Classifier 全体に付随する。例えば,その Classifier 全体で
共有されている Attribute 又は,生成操作のようにその Classifier 自身に対し
て作用する Operation である。

4.7.2.24

  String  文字列型

メタモデルでは,String は,Primitive の一つのインスタンスである分類子モデル要素とする。

String

のインスタンスは,テキストの部分を定義する。


50

X 4170

:2009 (ISO/IEC 19501:2005)

   

4.7.2.25

  TimeExpression  時間式

メタモデルでは,TimeExpression は,あるイベントが発生した時刻を定義する文を定義する。時間

式の特定の形式が指定されているわけではないので,実装時の検討課題である。

4.7.2.26

  TypeExpression  型表現式

メタモデルでは,TypeExpression は,解釈言語におけるプログラム言語の組込み型の符号化である。

これは,ProgrammingLanguageDataType 内で使用される。

4.7.2.27

  UnlimitedInteger  非負整数

メタモデル中では,UnlimitedInteger は,Primitive の一つのインスタンスである分類子要素であ

る。特殊値“unlimited”によって拡張された非負整数を範囲としてもつデータ型を定義する。多重度の

上限の指定に利用される。

4.7.2.28

  Uninterpreted  解釈なし

メタモデルでは,Uninterpreted は,領域に依存し UML では定義しないあいまいな対象を指定する。

4.7.2.29

  VisibilityKind  可視性種別

メタモデルでは,VisibilityKind は,それの参照する要素が,それを包含する名前空間の外からど

のように見えているかを指定する列挙型を定義する。

public

他の要素から対象要素を参照したり使用したりできる。

protected

元の要素の下位要素から対象要素を参照したり使用したりできる。

private

元の要素だけが対象要素を参照したり使用したりできる。

package

対象要素と同じパッケージ内に宣言された要素から対象要素を参照したり使用し
たりできる。

第 区分  振る舞い要素

4.8

Behavioral Elements

  振る舞い要素パッケージ

この Behavioral Elements パッケージは,動的な振る舞い又はモデルを指定する言語上部構造とす

る。Behavioral Elements パッケージは,次の下位パッケージ,Common Behavior パッケージ,

Collaborations

パッケージ,Use Cases パッケージ,State Machines パッケージ,及び Activity

Graphs

パッケージに分割されている。

Common

Behavior

パッケージは,振る舞い要素に要求される中核概念を規定する。Collaborations

パッケージは,特定の仕事を達成するためにモデル要素を使用する場合の振る舞い的な文脈を規定する。

Use Cases

パッケージは,アクタ及びユースケースとを用いて振る舞いを規定する。State Machines

パッケージは,有限状態遷移システムを用いて振る舞いを定義する。Activity Graphs パッケージは,

プロセス群をモデル化するために使用される状態機械の特殊な場合を定義する。


51

X 4170

:2009 (ISO/IEC 19501:2005)

図 13Behavioral Elements パッケージ

4.9

Common Behavior

  共通振る舞いパッケージ

4.9.1

概要

Common Behavior

パッケージは,Behavioral Elements パッケージを構成する下位パッケージ群

の中で最も基礎的な下位パッケージとする。これは,動的な要素に要求される中核概念を規定し,

Collaborations

,StateMachines 及び Use Cases の各下位パッケージを支援する下部構造を提供す

る。

次の箇条では,Common Behavior パッケージの抽象構文を記述する。

4.9.2

抽象構文

Common Behavior

パッケージに対する抽象構文が次の

図 14 に図式記法で表現され,Signal 及び

Reception

を定義するモデル要素を示している。


52

X 4170

:2009 (ISO/IEC 19501:2005)

   

図 14Common Behavior パッケージのシグナル部

図 15 は,CreateAction,CallAction,SendAction などの様々な動作を指定するモデル要素を説

明している。

図 15Common Behavior パッケージの動作部


53

X 4170

:2009 (ISO/IEC 19501:2005)

図 16 はインスタンス部,図 17 はリンク部を定義するモデル要素を示している。

図 16Common Behavior パッケージのインスタンス部


54

X 4170

:2009 (ISO/IEC 19501:2005)

   

図 17Common Behavior パッケージのリンク部

次のメタクラス群は,Common Behavior パッケージ中に含まれている。

4.9.2.1

Action

  動作

動作は,モデルの状態を変化させるような計算手続の抽象を構成する実行可能な文で規定し,オブジェ

クトにメッセージを送信したりリンク又は属性の値を変更することによって現実化することができる。

メタモデルでは,Action は ActionSequence の部分になることができ,受け手の指定だけでなく実

引数の指定,すなわちその Action が実行されるときに用いられる実 Instance を決定する式を含んだ

Argument

の並びを指定できる。

メタ属性 target は型 ObjectSetExpression に属し,それは実行されると,ディスパッチされた

Signal

の受信オブジェクトのような Action の意図した対象であるゼロ個以上の特定の Instance 群に

置き換えられる。反復するメタ属性は,動作が実行されるときに対象集合が繰り返されることを規定する。

対象インスタンス群に対して,動作が逐次的に適用されるのか,並列に適用されるのかは UML 内部では

定義されていない。

Action

は,抽象メタクラスとする。

属性

isAsynchronous

ディスパッチされた Stimulus が非同期か否かを示す。

recurrence

その Action が何回実行されるのが望ましいかを示す式。

script

その Action の効果を記述する ActionExpression。

target

その Action の対象を決定する ObjectSetExpression。


55

X 4170

:2009 (ISO/IEC 19501:2005)

関連

actualArgument Action を評価するときに必要な実引数を決定する Expression の列。

4.9.2.2

ActionSequence

  動作列

動作列は,動作の集まりとする。

メタモデルでは,ActionSequence は他の Action 群の集約となる Action とする。これは所有して

いる State 又は Transition の振る舞いを記述する。

関連

action

一つの原子単位として順番に実行される Action 群の列。

4.9.2.3

Argument

  引数

引数は,ディスパッチされたリクエストにおいて渡された実際の値を決定する方法を記述した式とする。

メタモデルでは,Argument は,Action を構成する部分であり,Expression 型のメタ属性の値を含

む。所有する Action が実行されるときに実引数がどのように決定されるかを述べている。

属性

value

評価されるときに実 Instance を決定する式。

4.9.2.4

AttributeLink

  属性リンク

属性リンクは,インスタンスの名前付きスロットであり,属性の値を保持する。

メタモデルでは,AttributeLink は Instance の状態の一部を構成し,Attribute の値を保持する。

関連

value AttributeLink の値であるような Instance。 
attribute AttributeLink のリンク元の Attribute。

4.9.2.5

CallAction

  呼出し動作

呼出し動作は,インスタンスに対する操作の起動を結果とする動作とする。呼出し動作は,同期か非同

期のいずれかであり,その操作が同期的又は非同期的に起動されることを指定する。

メタモデルでは,CallAction は一つの Action である。特定の Instance 又は Instance の集合が

対象式を通して指定され,実引数が Action から継承された引数関連を通して指定される。起動すべき

Operation

は,関連付けられた Operation によって指定される。

属性

isAsynchronous

(Action から継承)ディスパッチされた操作が非同期か否かを指定する。 
 
・  False:呼出し側が操作の実行の完了を待つことを示す。 
・  True:呼出し側が操作の実行の完了を待たないですぐに継続することを示す。


56

X 4170

:2009 (ISO/IEC 19501:2005)

   

関連

operation Action が実行されるときに起動される操作。

4.9.2.6

ComponentInstance

  コンポーネントインスタンス

コンポーネントインスタンスは,ノードインスタンス上に駐在するコンポーネントのインスタンスとす

る。コンポーネントインスタンスは状態をもち得る。

メタモデルでは,ComponentInstance は,Component から生じた Instance である。Instance

の集合に関連付けたり,ある NodeInstance 上に存在することができる。

関連

resident

特定の ComponentInstance の内部に存在する Instance の集まり。

4.9.2.7

CreateAction

  生成動作

生成動作は,ある分類子の一つのインスタンスの生成を結果とする一つの動作とする。

メタモデルでは,CreateAction は Action である。インスタンス化すべき分類子は,CreateAction

のインスタンス化関連によって指定される。CreateAction は対象インスタンスをもたない。

関連

instantiation CreateAction が 実 行 さ れ る と き に 生 成 さ れ る 一 個 の Instance の 属 す る

Classifier。

4.9.2.8

DataValue

  データ値

データ値は,識別性をもたないインスタンスとする。

メタモデルでは,DataValue は Instance の下位であるがその状態を変更できないようにしたもので

ある。すなわち,それに適用可能なすべての Operation は純粋な関数,すなわち,問合せである。

DataValue

は通常,属性値として使用される。

4.9.2.9

DestroyAction

  解体動作

解体動作は,その動作で指定されたオブジェクトの解体を結果とする動作とする。

メタモデルでは,DestroyAction は Action である。オブジェクトの指定は,Action の対象関連に

よって行われる。

4.9.2.10

  Exception  例外

例外は,一般的には実行が失敗した場合などに振る舞い特性によって上げられたシグナルとする。メタ

モ デ ル で は , Exception は Signal か ら 派 生 す る 。 個 々 の Exception は , そ れ を 発 行 す る

BehavioralFeature

と関連付けられている。

関連

context

(Signal から継承)その例外を発行する BehavioralFeature の集合。

4.9.2.11

  Instance  インスタンス

モデル要素であるインスタンスは,一群の操作が適用され,それらの操作の効果を格納する状態を保持


57

X 4170

:2009 (ISO/IEC 19501:2005)

する実体を定義する。

メタモデルでは,Instance は,その構造及び振る舞いを宣言する Classifier の少なくとも一つと

接続している。Instance は属性値の集合を保持し Link の集合と接続し,双方の集合はその Instance

の属する Classifier の定義と一致する。これら二つの集合はその Instance の現在の状態を実装して

いる。一つの Instance は,他の Instance 又は Link を所有することもできる。Instance は,抽象

メタクラスである。

関連

slot

その Instance の属性値を保持する AttributeLink の集合。

linkEnd

その Instance に付加された接続 Link 群の LinkEnd の集合。

classifier

その Instance の構造を宣言した Classifier の集合。

ownedInstance

その Instance によって所有されている Instance の集合。

ownedLink

その Instance によって所有されている Link の集合。

owner

その Instance を所有している Instance を指定する。

標準制約

destroyed

一個のインスタンスに適用される制約であり,そのインスタンスが実行中に解体さ
れることを指定する。

new

一個のインスタンスに適用される制約であり,そのインスタンスが実行中に生成さ
れることを指定する。

transient

一個のインスタンスに適用される制約であり,そのインスタンスが実行中に生成さ
れ解体されることを指定する。

タグ付き値

persistent

そのインスタンスの状態の永続性を指定し,transitory(その状態は,インスタ
ンスが解体されるときに破壊される。)か,persistent(その状態は,インスタ
ンスが解体されるときに破壊されない。

)かを示す。

4.9.2.12  Link

  リンク

モデル要素であるリンクは,インスタンス間の接続とする。

メタモデルでは,Link は Association の一つのインスタンスである。その Assocaiation の

AssociationEnd

の集合と一致する LinkEnd の集合を保持する。一つの Link は,Instance 同士の接

続を定義する。

関連

association

そのリンクの宣言であるような Association。

connection

その Link を構成する LinkEnd の組。

owner

その Link を所有する Instance を指定する。

標準制約

destroyed

一個のリンクに適用される制約であり,そのリンクが実行中に解体されることを指
定する。

new

一個のリンクに適用される制約であり,そのリンクが実行中に生成されることを指
定する。


58

X 4170

:2009 (ISO/IEC 19501:2005)

   

transient

一個のリンクに適用される制約であり,そのリンクが実行中に生成され解体される
ことを指定する。

4.9.2.13

  LinkEnd  リンク端

リンク端は,リンクの端点とする。メタモデルでは,LinkEnd は,ある Instance と接続される Link

の一部である。リンク端は,その Link の Association の一つの AssociationEnd に対応する。

関連

associationEnd

その LinkEnd の宣言である AsscociationEnd を指す。

instance

その LinkEnd に接続する Instance を指す。

qualifierValue

対 応 す る AssociationEnd に 関 連 し た 限 定 子 Qualifier の 値 を 保 持 す る
AttributeLink 群を指す。

標準制約

association

リンク端に適用される制約であり,対応するインスタンスが関連を通して可視であ
ることを指定する。

global

リンク端に適用される制約であり,対応するインスタンスがそのリンクに対して相
対的に大域有効範囲にあるために可視であることを指定する。

local

リンク端に適用される制約であり,対応するインスタンスがそのリンクに対して相
対的に局所有効範囲にあるために可視であることを指定する。

parameter

リンク端に適用される制約であり,対応するインスタンスがそのリンクに対して相
対的なパラメタであるために可視であることを指定する。

self

リンク端に適用される制約であり,対応するインスタンスがそのリクエストの送信
者であるために可視であることを指定する。

4.9.2.14

  LinkObject  リンクオブジェクト

リンクオブジェクトは,その所有する属性値の集合へのリンクであり,一群の操作が適用可能な対象と

する。

メタモデルでは,LinkObject は Instance 集合の要素同士の接続であり,接続自身が属性値の集合

を保持し Operation の集合を適用できる対象でもある。これは Object 及び Link 両者の下位クラスで

ある。

4.9.2.15

  NodeInstance  ノードインスタンス

ノードインスタンスは,ノードのインスタンスとする。コンポーネントインスタンスの集まりは,ノー

ドインスタンスに存在することが可能である。

メタモデルでは,NodeInstance は Node から生じる Instance である。一つの NodeInstance 上に

存在する各 ComponentInstance は,対応する Node 上に存在する一つの Component のインスタンスで

なければならない。

関連

resident NodeInstance 群に存在する ComponentInstance の集まり。

4.9.2.16

  Object  オブジェクト

オブジェクトは,あるクラスから生じたインスタンスとする。


59

X 4170

:2009 (ISO/IEC 19501:2005)

メタモデルでは,Object は Instance の下位クラスであり,その Instance は,少なくとも一つの

Class

から生じたものである。Class の集合は動的に変更可能であり,このことは,特定の Object の

素性の集合はそのオブジェクトの生涯を通して変化する可能性があることを意味する。

4.9.2.17

  Reception  受信

受信は,ある分類子がシグナルの受信に反応する用意をしているという事実を示す宣言とする。受信は,

シグナルを指定し,期待される振る舞いの反応を仕様化する。受信は,期待される振る舞いの要約である。

シグナルの扱いの詳細は,状態機械によって仕様化される。

メタモデルでは,Reception は BehavioralFeature の下位であり,その素性を含む Classifier

が受信素性によって指定されたシグナルに反応するという事実を宣言する。属性 isPolymorphic は,そ

の振る舞いが多相的かどうかを指定し,値が真であれば,その振る舞いは常に同じであるとは限らず状態

又は下位クラス化に影響されることを示す。属性 specification は,その Signal への期待すべき反応

を示す。

属性

isAbstract

真である場合,その受信が実装をもたず,実装は子孫によって提供される必要があ
る。偽である場合,受信はその分類子の中,又は祖先からの継承によって実装をも
たなければならない。

isLeaf

真である場合,受信の実装は子孫の分類子によって上書きされてはならない。偽で
ある場合,受信の実装は子孫の分類子によって上書きされてもよい(が必ず上書き
する必要はない。

isRoot

真である場合,その分類子は同じ受信の宣言を継承してはならない。偽である場合,
その分類子は同じ受信の宣言を(しなくてもよいが)継承してもよい(しかし,ど
んな場合にも宣言は一致しなければならない。すなわち,分類子は受信の継承され
た宣言を変更することは許されない。

specification String で述べられた一つの Signal を受け取った分類子の効果の記述。

関連

signal

その Classifier が処理する用意のある Signal。

4.9.2.18

  ReturnAction  返却動作

返却動作は,呼出し側に値を返すことを結果とする動作とする。

メタモデルでは,ReturnAction は起動者に値を戻すことを引き起こす Action である。その値は,

Action

から継承された引数によって表現される。ReturnAction は,明示的な対象をもたない。

4.9.2.19

  SendAction  送信動作

送 信 動 作 は ,( 非 同 期 で ) シ グ ナ ル を 送 信 す る こ と を 結 果 と す る 動 作 と す る 。 シ グ ナ ル は ,

objectSetExpression

を介して受信側の集合に向けて送信することもできるし,何らかの外部機構に

よって定義された不特定の受信側の集合に暗黙的に送信することもできる。例えば,シグナルが例外であ

る場合,受信側オブジェクトは実行時システム機構によって決定される。

メタモデルでは,SendAction は Action とする。個々の SendAction は発行すべき Signal と関連

付けられ,その実引数は Action から継承された引数の関連によって指定される。


60

X 4170

:2009 (ISO/IEC 19501:2005)

   

関連

signal Action が実行されるときに起動されるシグナル。

4.9.2.20

  Signal  シグナル

シグナルは,インスタンス間で交信される非同期の刺激の仕様化とする。受信側インスタンスは状態機

械によってシグナルを処理する。シグナルははん(汎)化可能要素であり,シグナルを扱うクラス群とは

独立に定義される。受信はあるクラスがシグナルを取り扱うということの宣言であるが,実際の処理は状

態機械によって仕様化される。

メタモデルでは,Signal は Classifier の下位であり,Attribute 群として表されるパラメタを伴

っ て い る 。 個 々 の Signal は , い つ も 非 同 期 で あ る 。 個 々 の Signal は , そ れ を 発 行 す る

BehavioralFeature

群と関連付けられている。

関連

context

シグナルを発行する BehavioralFeature の集合。

reception

そのシグナルを処理する用意のある Class 群を指定する Reception の集合。

4.9.2.21

  Stimulus  刺激

刺激とは,二つのインスタンス間の交信の実体化とする。

メタモデルでは,Stimulus は一つの交信であり,ある Instance へ送信された一つの Signal 又はあ

る Operation の一回の起動を意味する。これは,ある Instance の生成又はある Instance の解体のリ

クエストであってもよい。これは,送信側,受信側をもち,すべて Instance からなる実引数の集合を伴

うこともある。

関連

argument

その Stimulus の引数である Instance の列。

communicationLink

交信に使用される具体的な Link。

dispatchAction

実行されるとその Stimulus の起動を帰結するような Action。

receiver

その Stimulus を受信する Instance。

sender

その Stimulus を送信する Instance。

4.9.2.22

  SubsystemInstance  サブシステムインスタンス

サブシステムインスタンスは,一つのサブシステムのインスタンスとする。これはサブシステムの実行

時表現であり,サブシステムのもつ関連に対応したリンクに接続することができる。サブシステムインス

タンスの仕事は,入ってくる交信を,刺激をサブシステム内の適切な受信オブジェクトへ再転送すること

によって,うまくさばくことである。メタモデルでは,SubsystemInstance は Instance の下位クラ

スである。

4.9.2.23

  TerminateAction  終了動作

終了動作は,オブジェクトを自己解体する。

メタモデルでは,TerminateAction は Action の下位である。TerminateAction の対象は,暗黙

的にその動作を実行する Instance である。したがって,明示的な対象は存在しない。


61

X 4170

:2009 (ISO/IEC 19501:2005)

4.9.2.24

  UninterpretedAction  解釈なし動作

解釈なし動作は,UML において明示的に実体化されない動作を表す。

極端な場合では,例えば Smalltalk のように,任意の動作は何らかのインスタンスに対する呼出し又

は起動である。しかし,より実践的には,解釈なし動作は,呼出し動作でも送信動作でもなく他の種類の

動作にも容易には分類できないような言語依存の動作をモデル化するのに利用できる。

4.9.3

正構造記述

注記 OCL で記述された各要素に対する正構造記述は,一般の UML 利用者には必要はないので,こ

の規格では不採用とした。

4.9.4

詳細意味論

注記  (対応国際規格では,4.9.4 は解説的内容であるため,この規格では不要であり,不採用とした。)

4.10

  Collaborations  コラボレーションパッケージ

4.10.1

概要

Collaborations

パッケージは,Behavioral Elements パッケージの下位パッケージとする。この

パッケージは,UML の Foundation パッケージ及び Common Behavior パッケージで定義された構成要

素を使用する。

Collaborations

パッケージは,Collaboration 群及び CollaborationInstanceSet 群を定義

するための手段を提供する。Collaboration で使用される主要な構成要素には,ClassifierRole,

AssociationRole

, Interaction

及 び

Message

が 含 ま れ る 。 一 方 , 一 つ の

CollaborationInstanceSet

では,Instance,Stimulus 及び Link が使用される。

協調し合う Instance 群に関する記述には,次の二つの側面がある。1)  参加者の構造の記述,2)  その

参加者の交信パターンの記述。ある特定のタスクを実行する役割を果たす複数の参加者の構造,及びこれ

らの参加者の関係を,Collaboration と呼ぶ。そのタスクを達成する役割を果たす Instance 群によっ

て実行される交信パターンを,Interaction と呼ぶ。その振る舞いは,全体的な Interaction 内で

Stimulus

群を交換する Instance 群の集合によって実装される。設計で使用されるメカニズムを理解す

るためには,それらの Instance 群及び Interaction 群を見ることが重要になる。Instance 群及び

Interaction

群は,自身を一部とする全体的なシステムから射影された一つの目的,又は関係をもつ一

連の目的の達成に関係する。

Collaboration

には,ClassifierRole 群及び AssociationRole 群の集合が含まれ,これらはあ

る一連の目的に必要とされる参加者を定義している。ClassifierRole 群に適合する Instance 群は,

こ の ClassifierRole 群 が 定 義 す る 役 割 を 果 た す 。 一 方 , Instance 群 間 の Link 群 は , そ の

Collaboration

の AssociationRole 群に適合する。ClassifierRole 群及び AssociationRole

群は,Instance 群及び Link 群の使用法を定義する。また,Classifier 群及び Association 群は,

これらの Instance 群及び Link 群に必要とされるすべての特性を宣言する。

Interaction

は,

Collaboration

の文脈の中で定義される。

Interaction

は,

その Collaboration

内の役割間での交信パターンを指定する。より厳密にいうと,Interaction は半順序の Message 群の

集合を包含し,これらの各 Message 群は一つの交信を規定している。その規定内容は,例えば,送信さ

れる Signal,又は呼び起こされる Operation,更には送信者及び受信者それぞれが果たす役割といった

ものになる。

CollaborationInstanceSet

は,その CollaborationInstanceSet の Collaboration が指定

するタスクを連帯して実行する Instance 群の集まりを参照する。これらの Instance 群は,その


62

X 4170

:2009 (ISO/IEC 19501:2005)

   

Collaboration

の ClassifierRole 群が定義する役割を果たす。すなわち,これらの Instance 群は,

ClassifierRole

群(Instance 群が適合する。

)が宣言するすべての特性をもつ。タスクを実行すると

き に Instance 群 間 で 送 信 さ れ る Stimulus 群 は , CollaborationInstanceSet の

InteractionInstanceSet

に参加している。これらの Stimulus 群は,その Collaboration の

Interaction

群のうちの一つに存在する Message 群に適合する。一つの Instance は,同時に複数の

CollaborationInstanceSet

群 に 参 加 で き る た め , そ の 交 信 の す べ て が 必 ず し も 唯 一

InteractionInstanceSet

だけから参照されるというわけではない。交信はインターリーブすることが

できる。

パラメタ化 Collaboration は,異なる設計で繰り返し使用することのできる設計の構造を表現する。

Collaboration

へ の 参 加 者 は , Classifier 群 及 び Relationship 群 を 含 め , は ん ( 汎 ) 用

Collaboration

のパラメタとなることができる。このパラメタは,はん(汎)用 Collaboration から

のインスタンス化のそれぞれにおいて,特定の ModelElement 群に結合される。このようなパラメタ化

Collaboration

は,あるデザインパターンの構造を把握することができる(デザインパターンは,構造

の側面以外の側面も関係する。

。大部分の Collaboration 群は,名前の付いた ModelElement に付加

されるため,それ自身は無名であってもよい。これに対して,Collaboration のパターンは独立した設

計の構成要素であり,必ず名前をもたなければならない。

Collaboration

は,様々な粒度で表現してよい。粗い粒度の Collaboration は,細かい粒度の他の

Collaboration

を作り出すように洗練してよい。

Collaboration

は,ユースケースの実現のされ方,ROOM

6)

のアクタ構造,OOram

7)

の役割モデル,

及び Catalysis

8)

で定義されるコラボレーションといった,幾つかの異なる事柄の表現に使うことができる。

それらはまた,Interaction 群の文脈の設定並びに Subsystem の仕様部及び実現部の間の対応付け定

義にも使われる。

6)

  ROOM (Real-Time Object-Oriented Modeling)

:ObjecTime 社によって開発された,組込み・リア

ルタイムシステム向けの手法。

7)

  OOram (The Object Oriented Role Analysis Method)

:Oslo 大学の Trygve Reenskaug 教授及び Taskon

社の創始者によって開発された手法。オブジェクト指向モデルを実行するための役割の概念に

基づいた手法。

8)

  Catalysis

:英国 TriReme 社の Wills 氏及び米 Kinetium 社の D'Souza 氏が提唱している方法論。コ

ンポーネントベースのアプリケーションを開発する手法で,記法は UML を拡張している。

Collaboration

は,UseCase と同様に,Operation 又は Classifier に対して付加できる。これ

は,Operation 及び Classifier の実現を記述する目的で,すなわち,その Operation 及び UseCase

が規定する振る舞いを実行するために Instance 群が果たす役割を記述する目的で行う。Classifier

を記述する Collaboration は,UseCase を記述する場合と同様に,一般的に Classifier 群及び

Association

群を参照する。これに対して,Operation を記述する Collaboration は,通常その

Operation

を所有する Classifier に付加された Association 群に加えて,その Operation の引数

及び局所変数も含む。Collaboration の内部で定義された Interaction 群は,Instance 群が

Operation

及び UseCase 内で規定された振る舞いを実行するときの,その Instance 群間の交信パタ

ーンを規定する。

また,

Collaboration

は Classifier の静的構造を定義するために,

その Classifier

に付加してよい。この静的構造とは,その Classifier の Attribute 群,Parameter 群などが果たす

役割である。


63

X 4170

:2009 (ISO/IEC 19501:2005)

ClassifierRole

又は AssociationRole は,一つ以上の Classifier 群又は Association 群を,

自身の基底としてもっている。同一の Classifier 又は Association が複数の Collaboration 群の

中で役割の基底として現れること,及び,一つの Collaboration 内に,それぞれ別々の役割で複数回現

れることができる。この各出現において,Classifier 又は Association のどの特性が,特定の用途に

おいて必要であるかを規定する。これらの特性は,その Classifier 又は Association がもつすべて

の特性の一部となる。

Collaboration

は,GeneralizableElement とする。したがって,Collaboration は,他の

Collaboration

のタスクの特化であるタスクを規定してよい。

次の箇条では,Collaborations パッケージの抽象構文について示す。

4.10.2

  抽象構文

Collaborations

パッケージの抽象構文を,

図 18∼図 20 に図式記法で示す。

図 18Collaborations パッケージの役割部


64

X 4170

:2009 (ISO/IEC 19501:2005)

   

図 19Collaborations パッケージの相互作用部

図 20Collaborations パッケージのインスタンス部


65

X 4170

:2009 (ISO/IEC 19501:2005)

4.10.2.1

  AssociationEndRole  関連端役割

関連端役割は,コラボレーションの中で使われるのと同様に,関連の端点を規定する。

メタモデルでは,AssociationEndRole は AssociationRole の一部であり,ClassifierRole へ

の AssociationRole の接続を規定する。これは,AssociationEnd と関連し,Association におけ

る対応部分を宣言する。

属性

collaborationMultiplicity Collaboration 内でこの役割を果たす LinkEnd 群の個数。

関連

availableQualifier Collaboration 中で使われる Qualifier 群の部分集合。 
base AssociationEndRole が射影になる AssociationEnd。

4.10.2.2

  AssociationRole  関連役割

関連役割は,コラボレーション内で必要な,関連の使用法を示す。

メタモデルでは,AssociationRole は Collaboration 内で使われる Association の限定された

ビューを規定する。AssociationRole は,その基底 Association の AssociationEnd に対応する

AssociationEndRole

の集合の合成とする。

属性

multiplicity Collaboration 内でこの役割を果たす Link 群の個数。

関連

base AssociationRole がビューとなる Association。 
conformingLink AssociationRole に適合する Link 群の集合。

4.10.2.3

  ClassifierRole  分類子役割

分類子役割は,コラボレーション内の参加者によって果たされる特定の役割とする。これは,コラボレ

ーションにおいて何が要求されているかによって定義される分類子の限定されたビューを規定する。

メタモデルでは,ClassifierRole は,Collaboration への参加者,すなわち Instance 群が適合

する役割を規定する。ClassifierRole は,Feature 群の集合を定義する。これは,基底 Classifier

群中で利用可能な Feature 群の部分集合であり,また,同様にその役割の中で使われている基底

Classifier

群 中 に 含 ま れ る ModelElement 群 の 部 分 集 合 と す る 。 ClassifierRole は

AssociationEndRole

群 を 経 由 し て AssociationRole 群 に 接 続 さ れ る 。 ClassifierRole は

Classifier

の一種なので,二つの ClassifierRole 間に Generalization の関係を定義できる。下

位の役割は上位の特化になる,すなわち下位の Feature 群及び内容は,上位の Feature 群及び内容を含

む。

属性

multiplicity Collaboration 内でこの役割を果たす Instance 群の数。


66

X 4170

:2009 (ISO/IEC 19501:2005)

   

関連

availableContents Collaboration

内 で 使 わ れ て い る 基 底 Classifier に 含 ま れ る

ModelElement 群の部分集合。

availableFeature Collaboration 内で使われている基底 Classifier の Feature 群の部分集

合。

base ClassifierRole がビューとなっている Classifier 群。 
conformingInstance ClassifierRole に適合する Instance 群の集合。

4.10.2.4

  Collaboration  コラボレーション

コラボレーションは,操作又は分類子が,ユースケースのように,特定の方法で使われる分類子及び関

連の集合によって,どのようにして実現されるかを記述する。コラボレーションは,インスタンス及びリ

ンクによって果たされる役割を定義する。これはインスタンスがその役割を果たすときのそれらの間の交

信を定義する相互作用と同様になる。

メタモデルでは,Collaboration は,関連する Classifier 又は Operation の実現に参加する

Classifier

群,Association 群を表現する ClassifierRole 群,及び AssociationRole 群の集合

を含む。Collaboration は,また,参加している ClassifierRole 群に適合する Instance 群によっ

て演じられる振る舞いを記述するために使われる Interaction 群の集合も含んでよい。

Collaboration

は,Classifier 群のモデルのビュー(制限,断面及び射影)を規定する。射影は,

参加している ClassifierRole 群に適合する Instance 群間に要求される関係を記述するとともに,こ

れらの Classifier 群の Feature 群と含まれる ModelElement 群に要求される部分集合を記述する。

幾つかの Collaboration 群が,同一の Classifier 群の集合の,別の射影を記述してもよい。したが

って,Classifier は,幾つかの ClassifierRole 群の基底になりえる。

Collaboration

はまた,例えば Collaboration の目的を果たすために Classifier 群間に必要と

さ れ る Generalization 群 の よ う な , 構 造 的 要 求 の 表 現 に 必 要 な ModelElement 群 , 通 常 は

Classifier

群及び Generalization 群の集合を参照できる。

Collaboration

は GeneralizableElement で あ り , 一 つ の Collaboration が 他 の

Collaboration

のタスクの特化であるようなタスクを規定してもよい。

関連

constrainingElement Generalization 及び Constraint のように,Collaboration に参加

し て い る ModelElement 群 に 対 し て 特 別 の 制 約 を 追 加 す る
ModelElement 群。

interaction Collaboration 内で定義される Interaction 群の集合。 
ownedElement

(Namespace から継承)Collaboration によって定義される役割の集
合。これらは ClassifierRole 群及び AssociationRole 群とする。

representedClassifier Collaboration がその実現となる Classifier(Collaboration が

Classifier を表現する場合に使用される。

representedOperation Collaboration がその実現となる Operation(Collaboration が

Operation を表現する場合に使用される。

usedCollaboration

起 点 と な る Collaboration 群 を 定 義 す る と き に 使 用 さ れ る
Collaboration。


67

X 4170

:2009 (ISO/IEC 19501:2005)

4.10.2.5

  CollaborationInstanceSet  コラボレーションインスタンス集合

コラボレーションインスタンス集合は,コラボレーションが規定する特定のタスクを実行するときに,

一緒に連携するインスタンスの集合とする。コラボレーションインスタンス集合のインスタンスは,その

コラボレーションの中で定義された役割を果たす。

メ タ モ デ ル で は , CollaborationInstanceSet は , そ の CollaborationInstanceSet の

Collaboration

がもつ ClassifierRole 群及び AssociationRole 群によって定義された役割を果た

す,Instance 群及び Link 群の集合を参照する。

CollaborationInstanceSet

は , InteractionInstanceSet

を 包 含 す る 。 こ の

InteractionInstanceSet

は , CollaborationInstanceSet の Instance 群 間 で 交 換 さ れ る

Stimulus

群の集合を参照し,その CollaborationInstanceSet の Collaboration 内にある,ある

Interaction

の Message 群に対応する。

関連

constrainingElement Generalization 及び Constraint のように,Collaboration に参

加 し て い る ModelElement 群 に 対 し て 特 別 の 制 約 を 追 加 す る
ModelElement 群。

Collaboration CollaborationInstanceSet に参加する Instance 群が果たす役割

を宣言している Collaboration。

interactionInstanceSet CollaborationInstanceSet の Collaboration がもつタスクを実

行するときに Instance 群間で渡される Stimulus 群を参照する
InteractionInstanceSet。

participatingInstance CollaborationInstanceSet に参加する Instance 群の集合。 
participatingLink CollaborationInstanceSet に参加する Link 群の集合。

4.10.2.6

  Interaction  相互作用

相互作用は,特定のタスクを実行するインスタンス間の交信を規定する。各相互作用は一つのコラボレ

ーションの文脈の中で定義される。メタモデルでは,Interaction は,それを所有する Collaboration

の ClassifierRole 群に適合する Instance 群の集合間の交信を規定する Message 群の集合を含む。

関連

context Interaction の文脈を定義する Collaboration。 
message Interaction 内の交信を規定する Message 群。

4.10.2.7

  InteractionInstanceSet  相互作用インスタンス集合

相互作用インスタンス集合は,コラボレーションインスタンス集合に参加する刺激の集合とする。メタ

モデルでは,InteractionInstanceSet は,その InteractionInstanceSet の Interaction がも

つ Message 群に適合する Stimulus 群の集合を参照する。

関連

context

InteractionInstanceSet の文脈を定義する 
CollaborationInstanceSet。

participating-Stimulus CollaborationInstanceSet の実行に参加する Stimulus 群。 
interaction Stimulus 群が適合する相互作用パターンを定義する Interaction。


68

X 4170

:2009 (ISO/IEC 19501:2005)

   

4.10.2.8  Message

  メッセージ

メッセージは,相互作用の中に示されるインスタンス間での特定の交信を定義する。

メタモデルでは,Message は Interaction の中での一つの特定の交信を規定する。交信は,Signal

の発生,Operation の呼出し,Instance の生成又は削除ができる。Message は交信の種類を規定する

だけでなく,送信者及び受信者の役割,Action のディスパッチ,並びに交信 Link によって果たされる

役割を規定する。さらに,Message は,Interaction 内での相対的な順序を規定する。

関連

action Message によって送られる Stimulus を引き起こす Action。 
activator

現在の Message のディスパッチを引き起こす振る舞いを呼び出した
Message。

communicationConnection Message によって示される交信中で使われる Link 群によって果たされ

る AssociationRole。

conformingStimulus

この Message に適合する Stimulus 群の集合

interaction

その Message が部分となっている Interaction。

receiver

交信を受信し,それに反応する Instance の役割。

predecessor

それらの完了が,

現在の Message の実行を可能にする Message の集合。

それらのすべてが,実行の開始前に完了していなければならない。

sender

交信を引き起こし,応答を受信できる Instance の役割。

4.10.3

  正構造記述

注記 OCL で記述された各要素に対する正構造記述は,一般の UML 利用者には必要はないので,こ

の規格では不採用とした。

4.10.4

  詳細意味論

注記  (対応国際規格では,4.10.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

4.10.5

  注記

注記  (対応国際規格では,4.10.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

4.11  Use Cases

  ユースケースパッケージ

4.11.1

  概要

Use Cases

パッケージは,Behavioral Elements パッケージの下位パッケージとする。このパッケ

ージは,システムのような実体の機能性を定義するための概念を規定する。このパッケージは,UML の

Common Behavior

パッケージ及び Foundation パッケージで定義された構成要素を使用する。

Use Cases

パッケージの要素は,主としてシステム又はサブシステムのような実体の振る舞いを内部

構造を想定せずに定義するために用いられる。このパッケージのキーとなる要素は,Use Case 及び Actor

になる。ユースケースのインスタンス及びアクタのインスタンスは,実体のサービスが使われるときに相

互作用する。ユースケースが,実体内のクラスによって定義された協同するオブジェクトによってどのよ

うに実現されるかは,Collaboration で規定できる。実体のユースケースは,その実体に含まれる要素

のユースケースの集合に詳細化してもよい。これらの下位ユースケースが,どのように相互作用するかも

また Collaboration で表される。通常,システム自体の機能仕様は,別のユースケースモデル内に

«useCaseModel»

の付いた Model として表される。そのユースケースモデルのユースケース及びアクタ


69

X 4170

:2009 (ISO/IEC 19501:2005)

は,最上位レベルのパッケージのものと同じになる。

次の箇条では,Use Cases パッケージの抽象構文を示す。

4.11.2

  抽象構文

Use Cases

パッケージの抽象構文を,

図 21 に図式記法で示す。

図 21Use Cases パッケージ

次のメタクラスが Use Cases パッケージに含まれる。

4.11.2.1

  Actor  アクタ

アクタは,実体の利用者が実体と相互作用をもつとき,果たすことができる役割の一貫した集合を定義

する。アクタは,交信する各々のユースケースに対し,別の役割を果たすと考えられる。

メタモデルでは,Actor は Classifier の下位クラスとする。Actor は,Name をもち,UseCase 群

の集合と交信をしたり,実現のレベルでは,UseCase 群の実現に用いられる Classifier 群と交信して

もよい。また,Actor は,他の要素がどのようにこの Actor と交信するかを記述した Interface 群の

集合をもってもよい。

Actor

は,他の Actor との間にはん(汎)化関係をもってもよい。これは,下位 Actor は,上位 Actor

と同じ役割を果たすことができること,すなわち上位 Actor と同じ UseCase 群の集合と交信できること

を意味する。

4.11.2.2

  Extend  拡張

拡張関係は,ユースケースのインスタンスが,拡張するユースケースで定義された追加の振る舞いによ


70

X 4170

:2009 (ISO/IEC 19501:2005)

   

って拡張されてよいことを定義する。

メタモデルでは,Extend 関係は,基底の UseCase の UseCaseInstance が,拡張する UseCase 中

に定義された構造及び振る舞いによって拡張されてよいことを意味する,方向性をもった関係とする。そ

の関係は,拡張が行われる場合に満たさなければならない条件,及び追加の振る舞い断片が挿入される基

底 UseCase 中の拡張点への参照の列からなる。

属性

Condition

拡張が行われるとき満たさなければならない条件を指定する式。

関連

Base

拡張される UseCase。

Extension

拡張する振る舞いを指定する UseCase。

extensionPoint

追加分がどこに挿入されるべきかを指定する基底 UseCase 中の拡張点の列。

4.11.2.3

  ExtensionPoint  拡張点

拡張点は,ユースケース内のそのユースケースが拡張されるかもしれない一つ以上の位置を参照する。

メタモデルでは,ExtensionPoint は,名前,及び所有する側のユースケースの振る舞いにおける一

つ以上の位置記述をもち,その位置に一片の振る舞いが挿入できる。

属性

Location

そのユースケースの振る舞いへの拡張が挿入可能な一つ以上の位置への参照。

4.11.2.4

  Include  包含

包含関係は,ユースケースが他のユースケースで定義される振る舞いを含むことを定義する。メタモデ

ルでは,Include 関係は,追加 UseCase の振る舞いが基底 UseCase の振る舞いの中に挿入されること

を意味する二つの UseCase 群間の方向性をもった関係とする。基底 UseCase は,追加 UseCase 中に定

義された振る舞いの実行結果に依存してよいが,追加 UseCase の構造,すなわち特定の属性及び操作の

存在に依存してはならない。

関連

Addition

追加の振る舞いを指定する UseCase。

Base

追加を含むことになる UseCase。

4.11.2.5

欠番)

注記  “4.11.2.5”とあるのは,ISO/IEC 19501 原文の誤りである。ただし,この規格で修正すると項

番がずれ,原文との対応がとれなくなるので,修正は施していない。

4.11.2.6

  UseCase  ユースケース

ユースケースは,システム又はその他の意味的実体の振る舞いを,その内部構造を明らかにすることな

く定義するために用いられる。それぞれのユースケースは,実体がアクタと相互作用を行いながら実行で

きる一連の動作を,その変種も含めて規定する。

メタモデルでは,UseCase は Classifier の下位クラスであり,UseCase のインスタンスによって実


71

X 4170

:2009 (ISO/IEC 19501:2005)

行される動作の系列を規定する。動作は状態の変化及び UseCase の環境との交信を含む。その系列は

Operation

及び Method 群,ActivityGraph 群,StateMachine 群などの多くの異なる技術を使って

記述することができる。

UseCase

群及びその Actor 群との間に Association 群があってもよい。そのような Association

は,UseCase のインスタンス及び Actor の役割の一つを演じる利用者が交信することを示す。UseCase

群は,Extend 関係,Include 関係及び Generalization 関係によって他の UseCase 群と関係付けら

れてもよい。Include 関係は,UseCase に,別の UseCase 中に記述された振る舞いを取り入れて含め

ることを意味し,一方 Extend 関係は,UseCase が,別の UseCase 中に記述された振る舞いを条件に基

づいて拡張することを意味する。UseCase 群間の Generalization は,下位が上位よりも更に具体的で

あることを意味する。下位は,上位のすべての Feature 群及び Association 群を継承し,更に,新た

な Feature 群及び Association 群を追加してもよい。

UseCase

の実現は,Collaboration 群の集合によって規定できる。すなわち,その Collaboration

群の集合は,システム内の Instance が一連の UseCase を実行するためにどのように相互作用するかを

定義する。

関連

Extend

その UseCase 群を拡張する UseCase 群への Extend 関係の集まり。

extensionPoint

その UseCase が拡張される ExtensionPoint の集まりを定義する。

Include

その UseCase 群が含む UseCase 群への Include 関係の集まり。

4.11.2.7

  UseCaseInstance  ユースケースインスタンス

ユースケースインスタンスは,ユースケースに規定される一連の動作の実行とする。

メタモデルでは,UseCaseInstance は Instance の下位クラスとする。UseCaseInstance によっ

て実行されるそれぞれのメソッドは原子トランザクションとして実行される。すなわち,それは他の

UseCaseInstance

によって中断されない。

明確に記述された UseCaseInstance は,シナリオと呼ばれる。

4.11.3

  正構造記述

注記 OCL で記述された各要素に対する正構造記述は,一般の UML 利用者には必要はないので,こ

の規格では不採用とした。

4.11.4

  詳細意味論

注記  (対応国際規格では,4.11.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

4.11.5

  注記

注記  (対応国際規格では,4.11.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

4.12  State Machines

  状態機械パッケージ

4.12.1

  概要

State Machines

パッケージは,Behavioral Elements パッケージの下位パッケージとする。この

パッケージは,振る舞いを有限状態遷移システムによってモデル化するために使うことのできる概念集合

を記述する。これらの概念は,Common Behavior パッケージ内に定義された概念だけではなく,


72

X 4170

:2009 (ISO/IEC 19501:2005)

   

Foundation

パッケージ内に定義された概念に基づいている。ゆえに,Behavioral Elements の他の

下位パッケージとの統合が可能となる。

4.12

で記述される状態機械の形式は,Harel のステートチャートのオブジェクトに基づいた変種とする。

これは,ROOM モデル化言語で定義されたステートチャートの変種である ROOM チャートで定義されて

いる概念と類似した幾つかの概念を組み込んでいる。

状態機械は,モデル化される種々の要素の振る舞いを記述するのに使うことが可能になる。例えば,個々

の実体(例えば,クラスインスタンス)の振る舞いモデル化,及び実体間の相互作用(例えば,コラボレ

ーション。

)定義に使える。

さらに,状態機械の形式は,アクティビティグラフの意味基盤を提供する。これは,アクティビティグ

ラフが状態機械の特別な形式であることを意味する。

次の箇条では,State Machines パッケージの抽象構文を記述する。

アクティビティグラフは,4.13 で記述する。

4.12.2

  抽象構文

状態機械に対する抽象構文を

図 24 に示す。この図は状態及び遷移といった状態機械グラフの基本概念の

すべてを含む。

図 25 は,状態機械の振る舞いにトリガをかけることが可能なイベントの抽象構文を説明し

ている。

図 24 及び図 25 で定義されている概念の仕様を,英字順に列挙する。


73

X 4170

:2009 (ISO/IEC 19501:2005)

図 24State Machines パッケージの主要部


74

X 4170

:2009 (ISO/IEC 19501:2005)

   

図 25State Machines パッケージのイベント部

4.12.2.1

  CallEvent  呼出しイベント

呼出しイベントは,特定の操作の同期起動要求の受信を表現する(呼出しイベントインスタンスは,そ

れを引き起こした呼出し動作とは異なる。

。期待される結果は,その特定状態におけるその操作の振る舞

いを特徴付ける動作列の実行になる。

オブジェクト生成イベント及びオブジェクト削除イベントは,CallEvent の二つの特別な場合とする。

関連

Operation

その起動が呼出しイベントを引き起こす操作を示す。

ステレオタイプ

«create» «create»

は,イベントを受け取るインスタンスがまさに生成されたことを示すス

テレオタイプ付けされた呼出しイベントとする。状態機械については,状態機械の
最上位レベルで初期遷移にトリガをかける(そして初期遷移に適用される唯一のト
リガとする。

«destroy» «destroy»

は,イベントを受け取るインスタンスが削除されることを表すステレオ

タイプ付けされた呼出しイベントとする。

4.12.2.2

  ChangeEvent  変更イベント

変更イベントは,一つ以上の属性又は関連の値の変化の結果として明示的な論理式が真となったとき生


75

X 4170

:2009 (ISO/IEC 19501:2005)

じるイベントをモデル化する。変更イベントは,暗黙的に引き起こされるのであって,何らかの明示的な

変更イベント動作の結果ではない。

変更イベントは,ガードと混同されないことが望ましい。変更イベントに関連する論理式が,概念的に

はそれが真になるまで連続的に評価されるのに対して,ガードはイベントがディスパッチされるときだけ

に評価される。生成されるイベントは,論理式がその後偽に変わっても,それが消費されるまで残る。

属性

changeExpression

変更イベントを規定する論理式。

4.12.2.3

  CompositeState  合成状態

合成状態は,一つ以上の他の状態頂点(状態,擬似状態など)を含んだ状態とする。合成状態と包含さ

れている状態頂点との間の関連は合成集約関連とする。したがって,状態頂点は一つの合成状態の一部分

としかならない。

合成状態に包含される状態は,合成状態の下位状態と呼ばれる。それが他のいかなる状態にも含まれな

い場合直接の下位状態と呼ばれる。そうでない場合,推移的に入れ子になった下位状態として参照される。

CompositeState

は,State の下位とする。

関連

Subvertex

合成状態に所有される状態頂点の集合。

属性

isConcurrent

分割の意味論を規定する論理値。属性が真の場合,合成状態は,

(通常は,並行実

行に関連する)領域と呼ばれる二つ以上の直交する直積構成要素に直接分割され
る。偽の場合,合成状態中には,直接直交構成要素は存在しない。

isRegion CompositeState が並行状態の下位状態かどうかを示す派生論理値。それが真の

場合,CompositeState は,並行状態の直接下位状態とする。

4.12.2.4

  Event  イベント

イベントは,観察可能な出来事の型の仕様とする。イベントインスタンスを生成する出来事は,持続期

間をもたず一瞬に起こるものとみなされる。

厳密にいうと,用語“イベント”は型を参照するために用いられ,その型のインスタンスを参照しない。

しかし,意味が文脈から明らかな場合には,この用語がイベントインスタンスを参照するためにも用いら

れる。

Event

は,ModelElement の下位とする。

関連

parameter

イベントによって定義されるパラメタの並び。

4.12.2.5

  FinalState  最終状態

最終状態は,内包する合成状態が完了することを示す特別な種類の状態とする。内包する状態が最上位

状態ならば,状態機械全体の完了を意味する。


76

X 4170

:2009 (ISO/IEC 19501:2005)

   

最終状態は,出力遷移をもたない。

FinalState

は,State の子とする。

4.12.2.6

  Guard  ガード

ガードは,遷移の発火に対する細かい制御として遷移に付与された論理式とする。ガードは,状態機械

よりイベントのインスタンスがディスパッチされたとき評価される。そのときガードが真の場合,遷移は

可能となり,そうでなければ遷移不可となる。

ガードは,副作用のない純粋な式であることが望ましい。副作用をもつガード式は,不適格である。

Guard

は,ModelElement の下位とする。

属性 
expression

ガードを規定する論理式。

4.12.2.7

  PseudoState  擬似状態

擬似状態は,状態機械グラフにおける様々な型の一時的頂点の抽象化とする。一般的にこれらは,複数

の遷移をより複雑な状態遷移経路に結び付けるために使われる。例えば,並行分岐擬似状態に入る遷移を,

その並行分岐擬似状態から抜ける遷移の集合と結び付けることによって,並行する遷移先の状態の場合に

導く複合遷移を得る。

次の種類の擬似状態が定義されている。

−  初期擬似状態は,合成状態のデフォルト状態への単一遷移における遷移元であるデフォルト頂点を表

現する。合成状態には一つしか初期頂点が存在し得ない。

−  深い履歴は,この擬似状態を直接含む合成状態の最後の活性化構成を表現する簡略記法とする。すな

わち,合成状態が最後に抜けられたときに活性であった状態構成になる。合成状態は一つしか深い履

歴点をもち得ない。遷移はデフォルトの深い履歴状態への履歴接続子から始まってよい。この遷移は,

合成状態が以前活性であったことがない場合に生じる。

−  浅い履歴は,この包含する状態の最後の活性化下位状態(しかし,下位状態の下位状態ではない。

)を

表現する簡略記法とする。合成状態は,一つしか浅い履歴頂点をもち得ない。浅い履歴頂点に入って

くる遷移は,状態の最も最近の活性化下位状態への入力遷移と等価になる。遷移は,初期の浅い履歴

状態への履歴接続子から始まってよい。この遷移は,合成状態が以前活性であったことがない場合に

生じる。

−  同期合流頂点は,直交する他領域にある起点頂点から発散する幾つかの遷移をまとめるのに役に立つ。

同期合流頂点に入ってくる遷移はガードをもつことができない。

−  並行分岐頂点は,入力遷移を直交頂点で終了する二つ以上の遷移へ分散するのに役立つ。並行分岐か

ら出力する断片は,ガードをもってはならない。

−  連結頂点は,複数の遷移を結び付けるために使われる意味論非依存な頂点とする。これは状態間の複

合遷移経路を構築するために使われる。例えば,連結は複数の入力遷移を共有遷移経路を表現する単

一の出力遷移に変換(併合)するために使われる。逆に,入力遷移を違ったガード条件をもつ複数の

出力遷移に分離するためにも使うことができる。これは静的条件分枝を実現する(この場合,偽と評

価されるガード条件をもつ出力遷移は無効となる。

“else”というガードが一つの出力遷移に対して

定義されてよい。この遷移は,他の遷移に付けられたすべてのガードが偽となった場合,有効となる。

静的条件付分枝は,

(次に示す)選択頂点によって実現される動的条件付分枝とは異なる。


77

X 4170

:2009 (ISO/IEC 19501:2005)

−  選択頂点は,そこに達したとき,結果としてその出力遷移のガードの動的な評価が起こる。これは,

動的条件付分枝を実現する。その経路をとるかの決定が,完了までの実行可能列の同じステップで行

われる前の動作結果の関数となる複数の出力経路への遷移分離を許す。二つ以上のガードが真と評価

されるならば,任意の一つが選ばれる。一つも真と評価されないならば,モデルは不適格とみなされ

る(これを避けるために,すべての選択頂点に対して“else”ガードをもった一つの出力遷移を定義

することが勧められる。

。選択頂点は,

(上で示した)連結頂点に基づく静的分枝点とは区別されるこ

とが望ましい。

PseudoState

は,StateVertex の下位とする。

属性

kind PseudoState

の 詳 細 な 型 を 決 定 す る 。 initial , deepHistory ,

shallowHistory,join,fork,junction 又は choice のどれかとする。

4.12.2.8

  SignalEvent  シグナルイベント

シグナルイベントは,特定の(非同期)シグナルの受信を表現する。シグナルイベントのインスタンス

はそれを生成した動作(例えば,送信動作)と混同しないほうがよい。

SignalEvent

は,Event の下位とする。

関連

signal

このイベントに関連する特定のシグナル。

4.12.2.9

  SimpleState  単純状態

単純状態は,下位状態をもたない状態とする。これは,State の下位とする。

4.12.2.10

  State  状態

State

は,

(通常は暗黙的な)不変条件が成り立っている間の状況をモデル化する抽象メタクラスとす

る。不変条件はオブジェクトが外部イベントの発生を待つような静的な状況を表現してもよい。しかし,

ある活動を実行するプロセスのような動的な状況をモデル化することも可能になる(すなわち,このモデ

ル要素は,活動が開始したときに状態に入り,その活動が完了すると直ちに状態を抜ける。

State

は,StateVertex の下位とする。

関連

deferrableEvent

(消費されず)状態の外への遷移にトリガをかけない場合,状態機械に保持さ
れるべき候補であるイベントの並び。

entry

この状態に到達するためにとられる遷移にかかわらず,その状態へ入力すると
きは常に実行される活動であり,その定義は選択的とする。定義されている場
合,その状態で実行されるどのような内部活動又は遷移に先行して,入場動作
が常に実行され,完了する。

exit

この状態から抜けるどの遷移であっても,その状態を出るときは常に実行され
る活動であり,その定義は選択的とする。定義されている場合,すべての内部
活動及び遷移動作が実行を完了したあとにだけ,退場動作は常に実行され,完
了する。


78

X 4170

:2009 (ISO/IEC 19501:2005)

   

doActivity

その状態に存在している間実行される選択的活動。実行はこの状態に入ったと
き開始し,それ自身で終了するか,この状態を出るときのどちらか早いほうに
終了する。

internalTransition  トリガをかけられた場合,この状態からの入退場なしで生じる遷移の集合。し

たがって,これらは状態変化を生じさせない。これは,その状態の入場条件,
退場条件のどちらも起動されないことを意味する。これらの遷移はたとえ状態
機械がこの状態で一つ以上の領域に入れ子になっていたとしても行うことが
できる。

4.12.2.11

  StateMachine  状態機械

状態機械は,ある動的モデル要素のすべての可能な振る舞いを記述した仕様とする。振る舞いは,一連

のイベントインスタンスをディスパッチすることによってトリガをかけられる一つ以上の結合した遷移線

によって相互接続された,状態ノードのグラフをたどることとしてモデル化される。たどっている間,状

態機械はその各種要素に関連する一連の動作を実行する。

StateMachine

は,最上位レベルの状態を表現する State への合成関係と,遷移の集合をもつ。これ

は,状態機械が遷移及び最上位状態を所有することを意味する。他のすべての状態は,最上位状態を根と

する状態包含階層を通して推移的に所有される。Model Element への関連は,状態機械の文脈を提供す

る。よく見られる文脈関係では,状態機械が分類子のライフサイクルを記述するために使われる。

関連

context

振る舞いがこの状態機械によって規定されるモデル要素への関連。モデル要素は,
複数の状態機械を含んでよい(ただし,ほとんどの目的には一つで十分になる。

各状態機械は,選択的にただ一つのモデル要素によって所有される。

top

状態包含階層の根である最上位レベルの状態を示す。あらゆる状態機械には,ただ
一つの最上位状態が存在する。

transition

状態機械によって所有される遷移の集合。内部遷移はその包含状態によって所有さ
れ,状態機械によって所有されるものではない。

4.12.2.12

  StateVertex  状態頂点

状態頂点は,ステートチャートグラフにおけるノードの抽象化とする。一般に,任意個の遷移の遷移元

又は遷移先になることができる。StateVertex は,ModelElement の下位とする。

関連

outgoing

その頂点を出る遷移を指定する。

incoming

その頂点に入る遷移を指定する。

container

この状態頂点を包含する合成状態。

4.12.2.13

  StubState  スタブ状態

スタブ状態は,下位機械状態内で出現することができ,参照される状態機械内に保持する実際の下位頂

点を表現する。これは,包含する状態機械における状態頂点に,参照される状態機械における下位頂点を

連結する遷移の遷移元又は遷移先となることができる。

StubState

は,State の下位とする。


79

X 4170

:2009 (ISO/IEC 19501:2005)

関連

referenceState

参照される状態を経路名(状態の名前と,それが包含するすべての状態の後続名と
を,最上位状態まで結合することによって定めた名前)として表現する。

4.12.2.14

  SubmachineState  下位機械状態

下位機械状態は,再利用及びモジュール化を容易にする構文的便宜とする。これは,他の状態機械によ

るマクロ的な展開を意味する略記法であり,合成状態と意味的に等価になる。挿入される状態機械は参照

状態機械と呼ばれ,下位機械状態を包含する状態機械は包含状態機械と呼ばれる。同じ状態機械が一つの

包含状態機械の文脈において一度以上参照されるかもしれない。要するに,下位機械状態は,一つ以上の

入退場点をもつ状態機械“サブルーチン”に対する“呼出し”を表現する。

入退場点はスタブ状態として指定される。

SubmachineState

は,State の下位とする。

関連

submachine

下位機械状態の代わりに置き換えられる状態機械。

4.12.2.15

  SynchState  同期状態

同期状態は,状態機械の並行領域を同期するために使用される頂点とする。これは,論理値(活性,非

活性)に対応するのではなく,整数に対応するという意味で状態とは違っている。同期状態は,他の領域

が一つ以上の特定状態に入る前に,一つの領域が一つ以上の特定状態を離れることを保証するために,並

行分岐及び同期合流とともに使用される。

SynchState

は,StateVertex の下位とする。

属性

bound SynchState の最大総数を指定する正の整数値又は“unlimited”

。総数は,同期

状態の入力遷移及び出力遷移との発火回数の差とする。

4.12.2.16

  TimeEvent  時間イベント

時間イベントは,期限の時間切れをモデル化する。時間イベントのインスタンスの出現時点(期限の時

間切れ)は,その受理時点と同じになる。しかし,受理時点とディスパッチ時点との間には(例えば,待

ち行列の遅れに起因する)様々な遅延が存在するので注意が必要である。

期限を指定する表現は,相対的又は絶対的のいずれでもよい。この時間表現が相対的で開始時間が明示

的に定義されていない場合,イベントによってトリガをかけられる遷移の遷移元状態への入場時間は相対

的となる。時間表現が絶対的である場合,時間切れのときにも状態機械がまだ同じ状態にある場合に限り,

時間イベントインスタンスが生成される。

属性

when

対応する時間切れを指定する。

4.12.2.17

  Transition  遷移

遷移は,遷移元状態頂点及び遷移先状態頂点の間の方向付けられた関係とする。それは,複合遷移の一


80

X 4170

:2009 (ISO/IEC 19501:2005)

   

部であってよい。複合遷移は状態機械を一つの状態構成からもう一つの状態構成に移し,特定のイベント

インスタンスに対する状態機械の完全な応答を表現する。

Transition

は,ModelElement の下位とする。

関連

trigger

遷移を発火させるイベントを指定する。一つの遷移当たりに一つのトリガが存在で
きる。

guard

遷移の発火で細かい制御を与える論理述語。これは,遷移が発火するときに真でな
ければならない。イベントをディスパッチするときに評価される。一つの遷移につ
き一つのガードが存在できる。

effect

遷移が発火したときに実行される選択的な動作を示す。

source

遷移の元となる状態頂点(状態又は擬似状態)を示す。

target

遷移が行われたとき到達する遷移先の頂点を示す。

4.12.3

  正構造記述

注記 OCL で記述された各要素に対する正構造記述は,一般の UML 利用者には必要はないので,こ

の規格では不採用とした。

4.12.4

  詳細意味論

注記  (対応国際規格では,4.12.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

4.12.5

  注記

注記  (対応国際規格では,4.12.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

4.13  Activity Graphs

  アクティビティグラフパッケージ

4.13.1

  概要

Activity Graphs

パッケージは,State Machines パッケージの拡張ビューを定義する。状態機械

及びアクティビティグラフは,いずれも根本的には状態遷移システムであり,また,多数のメタモデル要

素を共有する。この第 3 区分では,State Machines パッケージの中でも特にアクティビティグラフに

固有な概念について記述する。アクティビティグラフの拡張は,それだけに固有の意味論をほとんどもた

ない。それは,Foundation パッケージ及び Common Behavior パッケージへの依存を含む,State

Machines

パッケージの文脈において理解するのが望ましい。

アクティビティグラフは,状態機械の特別なケースであり,通常は一つ以上の分類子を含むプロセスを

モデル化するものである。ここでの重要な点は,それらの動作をどの分類子が実施するかよりも,動作が

行われるためのシーケンス及びコンディションに合わせてある。そうした図の状態のほとんどが,原子的

動作を表現する動作状態である。すなわち,ある動作を起動させてからそれが完了するまでの待機状態の

ことである。動作状態の遷移は,次に示すいずれかのイベントによってトリガをかけられる。

−  一つ前の動作状態の終了(終了イベント)

−  特定の状態におけるオブジェクトが利用可能になったとき

−  シグナルの発生

−  条件の成立

状態機械の基本的概念に幾らかの下位型を追加定義することによって,アクティビティグラフの適格性


81

X 4170

:2009 (ISO/IEC 19501:2005)

が形式的に定義される。また,

(アクティビティグラフの適格性は)副次的に状態機械の動的な意味にも対

応付けられる。加えて,活動固有の複数の下位型は,アクティビティグラフをツール間でやりとりするう

ちに発生する,あいまいさを取り除く。

4.13.2

  抽象構文

アクティビティグラフのための抽象構文を,

図 30 の図式記法で示す。

図 30Activity Graphs パッケージ

4.13.2.1

  ActionState  動作状態

動作状態は,原子的動作の実行,おおむね操作の起動を表現する。

動作状態とは,入場動作を伴う単純な状態である。入場動作の実行完了という暗黙のイベントによって,

唯一の退場遷移がトリガをかけられる。したがって,状態とは,入場動作の実行そのものに対応する。ま

た,出力遷移は,入場動作が実行を完了するとすぐに起動する。

ActionState

は,その入場動作の一部として,二つ以上の動作を実行してもよい。動作状態は,退場


82

X 4170

:2009 (ISO/IEC 19501:2005)

   

動作,do 活動又は内部遷移を行わない。

属性

dynamicArguments

実行時に動作状態の並列実行の数を決定する ArgListsExpression。値は,
オブジェクトの並びでなければならない。各並びは,実行の引数となる。こ
の属性は,isDynamic 属性が偽のとき無視される。

dynamicMultiplicity

動作状態の並列実行の数を制限する多重度。この属性は,isDynamic 属性
が偽のとき無視される。

isDynamic

そ の 状 態 の 複 数 動 作 が 同 時 に 実 行 で きる か ど う かを 規 定 す る 論 理 値 。
dynamicArguments 属性とともに用いられる。

関連

entry

(State から継承された)起動される動作を規定する。

4.13.2.2

  ActivityGraph  アクティビティグラフ

アクティビティグラフは,状態機械の特別なケースであり,図を構成する動作間の制御フロー及びオブ

ジェクトフローによって,計算プロセスを定義する。その主眼は,状態機械の意味を拡張するものではな

く,計算プロセス及び組織プロセスにおいて,コンピュータ制御フロー及びオブジェクトフローのモデル

化に便利な簡略記法を定義する。

アクティビティグラフの第一の目的は,一つ以上の分類子を含む活動又はプロセスの状態を記述するこ

とである。アクティビティグラフは,パッケージ,分類子(ユースケースを含む。

,振る舞い素性に添付

することができる。状態機械と同じく,

(アクティビティグラフからの)出力遷移がイベントによって明示

的にトリガをかけられないのであれば,それは含まれる動作の完了によって暗黙にトリガをかけられる。

下位活動状態とは,入れ子になった活動を表現しており,一定の持続時間をもち,内部的には動作又は更

に下位の活動の集合で構成される。すなわち,下位活動状態とは,活動の下位の(アクティビティ)グラ

フを埋め込んだ“階層化された動作”であり,最終的には個々の独立した動作に分割される。

判断及び並行活動をモデル化するために,連結,分岐,合流及び同期を用いることができる。

アクティビティグラフは,Partition という概念を含んでおり,達成に対して責任を負う実世界の組

織と同様,様々な基準に従って状態を編成することができる。

アクティビティグラフを作成することによって,ビジネスプロセスエンジニアリング及びワークフロー

モデル化のための,組織のモデル化が可能となる。そのときのイベントは,あるタスク(仕事)の終了と

いった,システム内部から発生するものが多いが,顧客からの電話のような,システム外部からのものも

ある。アクティビティグラフは,完全な相互作用モデルが必要でないときに,システムモデル化に適用し

て,操作及びシステムレベルプロセスの動きを規定することもできる。

関連

partition

モデル要素を含む各 Partition の集合。

4.13.2.3

  CallState  呼出し状態

呼出し状態は,入場動作として呼出しの動作を,必ず一つだけ含む動作状態とする。それは,オブジェ

クトフローをモデル化するとき,どの動作が入力をとり,又は出力を提供するか,表記上あいまいになる


83

X 4170

:2009 (ISO/IEC 19501:2005)

ことを軽減するために役立つ。

4.13.2.4

  ClassifierInState  状態内分類子

状態内分類子は,特定の状態又は複数の状態にあるとき,与えられた分類子のインスタンスを特徴付け

る。

(状態内分類子は)アクティビティグラフで用いられるとき,オブジェクトフロー状態を通じて,動作

の入力及び/又は出力を規定できる。

関連

type

インスタンスを特徴付ける ClassifierInState のための分類子を示す。

instate ClassifierInState である分類子のインスタンスを特徴付ける状態を示す。その

状態は,対応する分類子が有効な状態でなければならない。直交状態にあるオブジ
ェクトを参照するとき,この ClassifierInState は複数の状態をもつことがあ
る。

4.13.2.5

  ObjectFlowState  オブジェクトフロー状態

オブジェクトフロー状態は,アクティビティグラフにおける動作間のオブジェクトフローを定義する。

ある特定の分類子のインスタンスは,オブジェクトフローが占有されているときに利用可能であるが,更

に,それが特定の状態になっている場合も許す。

ある動作状態において,その状態の完了にトリガをかけられたオブジェクトフロー状態を用いることに

よって,動作によるオブジェクトの生成をモデル化することができる。次の動作状態において,そのオブ

ジェクトを使用するには,オブジェクトフロー状態からの出力遷移を,その後続の動作状態への入力遷移

として連結することによってモデル化できる。一般に,各動作は,オブジェクトを別個のオブジェクトフ

ロー状態としてモデル化される状態に位置付ける。

属性

isSynch

オブジェクトフロー状態が同期状態として用いられるかどうかを指定する論理値。

関連

type

オブジェクトの分類子を指定する分類子を指す。それ(型)は,オブジェクトの状
態及び分類子を規定する ClassifierInState となり得る。

parameter

出力又は入力を求めるオブジェクトを提供するパラメタを指し示す。

ステレオタイプ

«signalflow» «signalflow»

は,Signal を型としてもつ ObjectFlowState のステレオタイプ

である。

4.13.2.6

  Partition  区分

区分は,アクティビティグラフの状態をグループ分けするための機構とする。区分は,ビジネスモデル

における組織単位に対応することがある。区分を用いて,アクティビティグラフの複数の状態の中で,特

性又は資源を割り当てることができる。特に,Partition はモデルの動的意味論に影響を与えることは

ないが,様々な目的のため特性及び動作を割り当てるのに役立つ。


84

X 4170

:2009 (ISO/IEC 19501:2005)

   

関連

contents

区分に属する状態を規定する。入れ子領域を構成する必要はない。

4.13.2.7

  SubactivityState  下位活動状態

下位活動状態は,一定の存続期間をもつ非原子的ステップ列の実行を表現する。それは,内部的には一

連の動作から構成され,また,ときにはイベント待ちを含むこともある。すなわち,下位活動状態とは,

関連する下位アクティビティグラフを実行している“階層化された動作”である。

下位活動状態は,入れ子になったアクティビティグラフを実行する下位の状態機械である。下位活動状

態への入力遷移がトリガをかけられたとき,入れ子のアクティビティグラフとともに実行が開始される。

下位活動状態の出力遷移は,入れ子のアクティビティグラフが終了状態に到達したとき(すなわち,実行

が完了したとき)

,又はトリガとなるイベントが遷移上に発生したときに可能となる。

下位活動状態の意味論は,入れ子となったグラフの内容を静的に置換して,すなわち,合成状態に下位

活動状態を入れ替えて,得られたモデルと等価である。

属性

dynamicArguments

状態の下位機械の並列実行の数を決定する ArgListsExpression。オブジ
ェクトの並びの集合を値としてとらなければならない。各並びは,一つの実
行の引数となる。この属性は,isDynamic 属性が偽のとき無視される。

dynamicMultiplicity

状態の動作の並列実行の数を制限する多重度。この属性は,isDynamic 属
性が偽のとき無視される。

isDynamic

状 態 の 下 位 活 動 が 同 時 に 実 行 で き る か ど う か を 規 定 す る 論 理 値 。
dynamicArguments 属性とともに用いられる。

関連

submachine

(SubmachineState から継承された)下位活動状態内で,概念的に入れ子になっ
ているアクティビティグラフを示す。下位活動状態は,合成状態と概念的に等価で
あり,その(合成状態の)内容は,入れ子のアクティビティグラフの状態となって
いる。入れ子のアクティビティグラフには,初期状態及び終了状態がなければなら
ない。

4.13.2.8

  Transition  遷移

Transition

は,State Machines パッケージの Transition から継承される。

タグ付き値

usage usage は,オブジェクトフロー状態に対し入力又は出力となる遷移だけに適用す

る。usage は,

“uses”又は“modifies”の値をもつ。

“uses”の値は,オブジ

ェクトフロー状態からのびている遷移の他端側の状態の動作が,オブジェクトフロ
ー状態によって表現されるオブジェクトを使用するが,修正はしないことを示す。
“modifies”の値は,その他端の動作がオブジェクトを修正し,かつ,使用する
こともあり得ることを示す。

4.13.3

  正構造記述

注記 OCL で記述された各要素に対する正構造記述は,一般の UML 利用者には必要はないので,こ

の規格では不採用とした。


85

X 4170

:2009 (ISO/IEC 19501:2005)

4.13.4

  詳細意味論

注記  (対応国際規格では,4.13.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

4.13.5

  注記

注記  (対応国際規格では,4.13.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

第 区分  一般機構

ここでは,モデルに対して一般的に適用可能な機構について定義する。UML のこの規格では,Model

Management

と呼ぶ唯一のはん(汎)用機構パッケージを含む。Model Management パッケージは,モ

デル要素がどのようにしてモデル,パッケージ,サブシステム及び UML プロファイルに編成されるかを

規定する。

4.14  Model Management

  モデル管理パッケージ

4.14.1

  概要

Model Management

は,Foundation パッケージに依存するとする。このパッケージは,Model,

Package

,及び Subsystem を定義する。それらは,すべて他の ModelElement 群のグループ化単位と

して役立つ。

Model

群は,物理システムのそれぞれ異なったビューを取り込むために使用する。Package 群は,Model

の中で ModelElement 群をグループ化するために使用する。Subsystem は,物理システム内の振る舞い

単位を表現する。UML プロファイル群は,UML 拡張をグループ化する専用のパッケージである。

ここでは,モデル化される物理システム,すなわち,モデルの主題そのものとモデル内で物理システム

を表すモデル要素とを,明確に区別しなければならない。この意味から,一貫して物理システムという用

語は前者を指すときに用い,

(最上位の)サブシステムという用語は後者を指すときに用いる。物理システ

ムの例としては,ソフトウェア,ハードウェア及び人を含むようなクレジットカードサービスがある。こ

の物理システムのための UML モデルは,クレジットカードサービスと呼ばれる最上位のサブシステムか

ら構成され,これを分解すると,認証,信用及び支払いといったサブシステムになる。家の建築を例にと

れば,家が物理システムに当たり,青写真がモデルに,そして青写真に使われる要素がモデル要素に当た

る。

次の箇条では,ModelManagement パッケージの抽象構文を記述する。

4.14.2

  抽象構文

ModelManagement

パッケージのための抽象構文は,

図 32 に示す図式記法で表される。


86

X 4170

:2009 (ISO/IEC 19501:2005)

   

図 32Model Management パッケージ

4.14.2.1

  Dependency  依存(4.5.2.15 の拡張)

UML

プロファイルのモデル化において依存は,固有の拡張をもつ。

ステレオタイプ

«modelLibrary»

この依存は,供給者パッケージがプロファイルと関連のあるモデルライブラリ
として使用されていることを意味する。クライアントはプロファイルとしてス
テレオタイプ化したパッケージであり,供給者は共有される(クラス及びデー
タ型といった)モデル要素を含む非プロファイルのパッケージである。

«appliedProfile»

この依存は,どのプロファイルがパッケージに適用可能であるかを指し示すと
き使用する。おおむね,クライアントは通常のパッケージ又はモデルであるが
(ただし,他種別のパッケージということもあり得る。

,供給者はプロファイ

ルパッケージである。これは,そのプロファイルが,推移的にクライアントパ
ッケージ内に含まれるモデル要素(クライアントパッケージ自身も含む。

)へ

適用されることを意味する。

4.14.2.2

  ElementImport  要素移入

要素移入は,他のパッケージを移入した結果としてパッケージ内の名前空間に含まれるモデル要素の可

視性及び別名を定義する。

メタモデルでは,ElementImport は Package と移入された ModelElement との間の関係を具体化す

る。それは移入された ModelElement の名前及び可視性の再定義を許す。すなわち,その ModelElement

には,移入するパッケージ内で使うための別名及び/又は新たな可視性を与えてもよい。省略時は,別名


87

X 4170

:2009 (ISO/IEC 19501:2005)

はなく(元の名前が使われる。

,また,移入するパッケージと関連のある私的可視性となる。

属性

alias

別名は移入された ModelElement の局所名を定義し,パッケージ内部で使われる。

isSpecification ownedElement が(実現から識別された仕様の場合)名前空間を含む仕様の一部

かどうかを規定する。仕様でない場合,ownedElement は,実現の一部である。
仕様と実現の区別がなされない場合,値は省略値として偽になる。

visibility

移入された ModelElement は,移入する側の Package に対して public,
protected 又は private のいずれかである。

4.14.2.3

  Model  モデル

モデルは,物理システムのビューを取り込む。それは,特定の目的をもった物理システムの抽象化とす

る。モデルに何を含め,何を含めないかは,その目的によって決定される。したがって,モデルはその目

的に関連する物理システムの側面を,適度なレベルの詳細さで完全に記述する。

メタモデルでは,Model は Package の下位クラスである。これは,ともに物理システムを記述する

ModelElement

群の包含階層を含む。Model はまた,システム環境を表す ModelElement 集合を含む。

システム環境は,おおむね Actor と,Dependency,Generalization,及び Constraint の相互関係

を伴って構成される。

各モデルは,その目的及び抽象レベル(例えば,分析モデル,設計モデル,実装モデルなど)によって

定義される物理システムの視点を表現するために,異なった Model 群が用意されている。おおむね異なっ

たモデルは互いに補足し合い,それら(異なったモデル)の観点(視点)によって定義される。例えば,

ユースケースモデルは,ビジネス分析者という利害関係者の視点によって定義できる。各モデルは,物理

システムの完全な記述である。Model 群が入れ子になるとき,内容を保持している Model は物理システ

ムの包括的な視点を表現する。その物理システムは,内容となっているモデル群によって定義される異な

った視点を与えている。

ステレオタイプ

«systemModel»

systemModel は,同一の物理システムのモデルの集まりを含むステレオタイプで
ある。また,systemModel は,異なるモデル内のモデル要素間のすべての関係及
び制約も含む。

«metamodel»

metamodel は,そのモデルが他のモデルの抽象化であることを表すステレオタイ
プである。すなわち,モデルのモデルである。したがって,M2 がモデル M1 のモデ
ルである場合,M2 はモデル M1 のメタモデルである。このとき M1 内のクラスは,
M2 内のメタクラスのインスタンスである。このステレオタイプは,4 層のメタモデ
ル化アーキテクチャで用いられているように,再帰的に適用できる。

4.14.2.4

  Package  パッケージ

パッケージは,モデル要素のグループ化とする。

メタモデルでは,Package は,Namespace 及び GeneralizableElement の下位クラスとなる。

Package

は,Package 群,Classifier 群,Association 群などの ModelElement を含む。Package

は,Constraint 群及びその Package の ModelElement 間の Dependency 群を含んでよい。

Package

の各 ModelElement は,記述している Package に関して可視性をもつ。ただし,これは,


88

X 4170

:2009 (ISO/IEC 19501:2005)

   

その ModelElement が他のパッケージにおいてもその(«access»

又は

«import»

の)Permission をも

つか,又は(その Package に対し)Generalization の関係など,ModelElement 群として利用可能

なときに限る。

ある Package から他の Package への

«access»Permission

又は

«import»Permission

は,起点となる Package 内の公開 ModelElement 群を目的の Package 内で参照することを許可する。

これらの違いは,移入された Package 内のすべての公開 ModelElement 群が,その移入する側の

Package

内の Namespace に追加されるのに対し,アクセスする側の Package 内の Namespace には影

響しないことにある。Package 内で使用可能な ModelElement 群とは,その Package 内の Namespace

の内容であり,その Package が所有又は移入する ModelElement 群と,アクセスされた Package 内の

公開 ModelElement 群とを合わせたものにしなければならない。

関連

importedElement  パッケージによって定義される名前空間は,他の移入されたパッケージ内のモデル

要素によって拡張される。

ステレオタイプ

«facade» «facade»

は,他のパッケージの所有であるモデル要素に対する参照を含むステレ

オタイプパッケージである。これは,パッケージの内容の一部を“公開ビュー”と
して提供するために使用される。facade がそれ自体のモデル要素を含むことはな
い。

«framework» «framework»

は,システムの全体又は一部が再利用可能なアーキテクチャを規定

するモデル要素を含むステレオタイプパッケージである。フレームワークは,おお
むねクラス,パターン又はテンプレートを含む。フレームワークがアプリケーショ
ン領域のために特化されるとき,(フレームワークは)アプリケーションフレーム
ワークとして引用されることがある。

«modelLibrary» «modelLibrary»

は,他のパッケージによって再利用される予定のモデル要素を含

むステレオタイプパッケージである。その中のモデルライブラリ内にあるプロファ
イルとは異なり,モデルライブラリは,ステレオタイプ及びタグ付き定義を使用す
るメタモデルを拡張しない。モデルライブラリは,ある種のプログラム言語におけ
るクラスライブラリと類似のものである。

«profile» «profile»

は,特定の領域又は拡張機構,例えば,ステレオタイプ,タグ付定義,

制約などを使用する目的のためカスタム化されたモデル要素を含むステレオタイ
プとする。また,プロファイルが依存するモデルライブラリ,及びプロファイルが
拡 張 す る メ タ モ デ ル 部 分 集 合 を 規 定 す る こ と が で き る ( 後 者 は ,
applicableSubset タグ定義によって規定される。

«stub» «stub»

は,他のパッケージの公開部分だけを表現するステレオタイプとする。

«topLevel» «topLevel»

は,包含階層内の最上位のパッケージを指すステレオタイプとする。

«topLevel»

は,名前空間を外側へ向けて見ながら名前を探すときの外縁限界を定

義する。topLevel サブシステムは,サブシステム包含階層の最上位を表す。すな
わち,モデル化する全物理システムの境界を表現するモデル要素である。


89

X 4170

:2009 (ISO/IEC 19501:2005)

タグ定義

{applicableSubset}  このタグ定義は,プロファイルパッケージにだけ適用され,関連するプロファ

イルで使用されているメタ要素を並びにする。このタグ定義と関連する値は,
文字列の集合であり,それぞれの文字列は適用可能なメタ要素の名前を表現す
る。 
 
適用可能なサブセットの使用は,必ずしもメタ要素を排除するものではない
が,関連するプロファイルからどの要素が参照されているかを,明確に識別し
ておく。さらに,タグ定義は,直接に関連するプロファイルにだけ適用される。
プロファイルが,移入又ははん(汎)化によって他のプロファイルと結合され
るときには,適用可能なサブセットは直接に関連するプロファイルへ適用され
る。適用可能なサブセットのタグ定義がない場合は,UML 全体のメタモデルが
適用可能であることを意味する。

4.14.2.5

  Subsystem  サブシステム

サブシステムは,物理システム内の振る舞い単位を表現するモデル要素群のグループ化とする。サブシ

ステムはインタフェースを提供し,操作をもつ。加えて,サブシステムのモデル要素は仕様及び実現要素

に区分される。仕様要素は,サブシステムの操作とともに実現要素によって実現される。

メタモデルでは,Subsystem は Package 及び Classifier 両方の下位クラスである。したがって,

Feature

の集合と Association の集合とをもつことができる。ただし,Feature の集合は,Operation

及び Reception となるように制約される。

Subsystem

の内容は,仕様要素及び実現要素という二つの部分集合に分けられる。仕様要素の部分集

合は,Subsystem の Operation とともに,Subsystem に含まれる振る舞いの仕様を提供する。一方,

実現要素の部分集合中の ModelElement 群は,共同して仕様の実現を提供する。いずれの種類の

ModelElement

でも仕様要素又は実現要素であり得る。仕様要素と実現要素との間の関係は,様々な方法

で定義できる(例えば,コラボレーション,«realize»

依存を用いるなど。

属性

isInstantiable Subsystem がインスタンス化可能か否かを示す。偽の場合,Subsystem はその物

理システムにおける一意な部分を表現する。そうでない場合,システムで複数の
Subsystem が同一の定義を含むことになる。

4.14.3

  正構造記述

注記 OCL で記述された各要素に対する正構造記述は,一般の UML 利用者には必要はないので,こ

の規格では不採用とした。

4.14.4

  詳細意味論

注記  (対応国際規格では,4.14.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

4.14.5

  注記

注記  (対応国際規格では,4.14.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。


90

X 4170

:2009 (ISO/IEC 19501:2005)

   

5

UML

  記法ガイド

第 区分  背景

注記  [対応国際規格では,箇条 の第 1 区分(背景)は解説的内容であるため,この規格では不要

であり,不採用とした。

5.1

序論

注記  (対応国際規格では,5.1 は解説的内容であるため,この規格では不要であり,不採用とした。)

第 区分  図式要素

5.2

グラフ及びその内容

ほとんどの UML 図及び一部の複合記号は,経路によって接続されたノードを包含するグラフである。

情報はほとんど位相関係で表され,記号の大きさ又は位置には関係しない(例外もあり,シーケンス図は

時間距離軸をもつ。

。重要な視覚的な関係には,次の三つがある。

a)

接続(通常は二次元図形への線)

b)

包含(境界をもつ二次元図形記号に関する)

c)

視覚的付加(図式上で,ある記号が他の記号の“近く”にある)

こうした図式関係は,記法の解析された様式としてグラフ内のノードの接続に対応する。

UML

記法は,二次元表記を基本としている。

(立方体のような)三次元図形の二次元への射影もあるが,

二次元平面へ写しこまれたアイコンとして表現される。近い将来において,真に三次元的な配置及び誘導

がデスクトップコンピュータで可能になるかもしれないが,現在は実用的ではない。

UML

記法で使用される基本的な図的構成要素には,次の四つがある。

a)

アイコン  アイコンは決まったサイズ及び形をもつ図形である。サイズを広げて中に内容を入れるこ

とはしない。アイコンは領域記号の範囲内で,経路の終端として,又は経路に接続したりしなかった

りする記号として表すことができる。

b)

二次元記号  二次元記号は可変の高さ及び幅をもち,文字列の並び,他の記号などを中に保持するこ

とができる。多くは,類似した種類又は異なる種類の区画に分割される。経路は二次元記号の境界で

終端されることによって,それに接続したことになる。二次元記号を移動又は削除すると,その記号

の内容,及びその記号に接続している経路すべてが影響を受ける。

c)

経路  端点の付加された線分の系列である。概念的には,経路は単一の位相的実体であるが,個々の

線分は図形的に操作することができる。線分がその経路から分離して存在することはない。経路は,

その両端で常に他の図形記号と接続する(ぶら下がる線は存在しない。

。経路は,終端をもつことが

できる。終端とはすなわち,経路の終わりを表すアイコンであり,経路記号の意味を限定する。

d)

文字列  文字列は“構文解析されない”形式で,多様な情報を提示する。UML 記法においては,記法

上の文字列の使用は,基盤となるモデル情報へ解析可能な構文をもつと仮定する。例えば,属性,操

作,及び遷移に関する構文がある。これらの構文は,ツールの表示上の選択肢によって拡張されるこ

とがある。文字列は,記号の単一の要素,記号の一部,並びの要素(この場合は,並びでの位置が情

報を伝える。

,記号又は経路に接続されたラベル若しくは図式上の独立要素になることができる。

5.3

経路の描画

経路は,端点同士がつながっている一連の線分からなる。経路全体は単一の位相的単位である。線分は,

直交線,傾斜線又は曲線とすることができる。ある種の線の引き方の常識が存在する。つまり,すべて直

交線,すべて直線,又は斜め方向だけは曲線を用いる。線のスタイルは,入力するツールによって制限さ


91

X 4170

:2009 (ISO/IEC 19501:2005)

れることがある。線分が交差するときは,図式のどの部品から他のどの部品へつながっているか判別が困

難になるため,一方の線分に(電気回路図に見られるような)小さな半円記号を用いて交差させる。この

ようにして,その経路が直接交わらず,また接続もしていないと示すことができる。

[集約及びはん(汎)化のような]幾つかの関係においては,同じ種類の幾つかの経路が一つの記号に

接続されることがある。また,

(特定の関係を記述する)状況では,記号に接続した複数の線分は一本の線

分に合流することができるので,そのような記号からのびている経路は,幾つかの経路に樹木のように枝

分かれすることがある。これは純粋に図的表現上の選択肢であって,それぞれの経路は概念的には別個の

ものである。この表現上の選択肢は,合流した線分又は同一でない線分の場合には使用しなくともよい。

5.4

非表示ハイパーリンク及びツールの役割

紙面の記法では隠ぺい(蔽)した情報を含むことはできない。コンピュータ画面の記法では,非表示の

(すなわち,静的ビューには表示されない)ハイパーリンクを含むことによって,図的なビューにおいて,

又はテキスト表において動的に他の情報に対してアクセスすることが可能となる。そのような動的リンク

は,動的といえども目に見える情報と同様な記法の一部であるが,この規格ではその形式を規定しない。

それらの規定はツールの責務とする。静的なビューでは,有用,かつ,興味深い情報が不十分にしか見ら

れなかったり,又は全く見られなかったりするということを承知の上で,この規格では UML における静

的な記法を定義する。あらゆる動的なツールの動作を定義するには知見が足りないし,決して動的な表現

という新しい形式の革新を押さえ込みたいわけでもない。やがては標準化に足る動的な記法が確立するか

もしれないが,今はその段階ではないと考える。

5.5

背景の情報

注記  (対応国際規格では,5.5 は解説的内容であるため,この規格では不要であり,不採用とした。)

5.6

文字列

文字列とは,モデルに関する情報を表示するのに適した文字集合の中の文字からなる連鎖である。文字

集合には,英字以外の文字及び記号を含めてよい。

5.6.1

意味論

図中の文字列は通常,基礎となるモデルの文字列に対応しモデルに関する情報を格納又は符号化する。

しかし,純粋に図の中だけに存在する文字列もある。UML は,様々な自然言語のマルチバイト文字を表現

するのに,十分な文字集合を前提にしている。特に,伝統的な 8 ビット ASCII 文字集合は不十分である。

この規格では,ツール及びコンピュータは特殊文字に対するエスケープ規約を含めて,文字列の操作及び

記憶を正確に行えて,任意の文字列が混乱を起こさずに使用できるものと仮定する。

5.6.2

記法

文字列は,テキスト文字列図形として視覚表現される。通常の印字可能な文字は,そのまま表示できる。

印字不可能な文字の表示は規定せず,プラットフォーム依存とする。文字列は目的に応じて,単一行の実

体として,又は自動改行される段落として表示できる。

字体及びフォントサイズは,文字列自体には依存しない図的なマーカである。それらは,様々なモデル

の特性をコード化してもよい。そのコード化の一部はこの規格で提示するが,残りはツール又はユーザに

任される。

5.6.3

表示上の選択肢

注記  (対応国際規格では,5.6.3 は解説的内容であるため,この規格では不要であり,不採用とした。)

5.6.4

注記  (対応国際規格では,5.6.4 は解説的内容であるため,この規格では不要であり,不採用とした。)


92

X 4170

:2009 (ISO/IEC 19501:2005)

   

5.6.5

対応付け

注記  (対応国際規格では,5.6.5 は解説的内容であるため,この規格では不要であり,不採用とした。)

5.7

名前

5.7.1

意味論

名前は,ある有効範囲内で,モデル要素を一意に識別するために使用される文字列である。経路名は,

システムのルートから(又は別の地点から)始まるモデル要素を見出すために使用される。名前は,ある

有効範囲内での選択子(限定子)である。この規格では,名前の付けられる各要素については,その有効

範囲を明確にする。

経路名は,区切り記号(

“::”など)でつながれた一続きの名前である。この規格では様々な種類の経路

名について,それぞれ適切な場所で,特定の区切り記号とともに記述する。

5.7.2

記法

名前は,テキスト文字列図形として表示される。通常,名前は単一行に表示され,印字の不可能な文字

は含まれない。ツール及び言語は,名前に使用する文字列の長さ及び文字集合に,妥当な制限を課すこと

ができる。名前のための制約は,注釈などの任意文字列に対してよりも,厳しくなる可能性がある。

5.7.3

注記  (対応国際規格では,5.7.3 は解説的内容であるため,この規格では不要であり,不採用とした。)

5.7.4

対応付け

注記  (対応国際規格では,5.7.4 は解説的内容であるため,この規格では不要であり,不採用とした。)

5.8

ラベル

ラベルは,図形記号に付加した文字列とする。

5.8.1

意味論

ラベルは,図における文字列の特定の用法のためにある。これは純粋に記法上の用語である。

5.8.2

記法

ラベルは,図中の他の記号に図形として付加された文字列である。視覚的には通常,

(閉じた領域の中に)

文字列を囲い込むことによって,又は記号の近くに文字列を配置することによって,ラベルの付加を表現

する。文字列を,

(記号の下など)一定の場所に配置することもある。しかし,文字列は記号の“近く”に

なければならないという文がほとんどである。ツールは,ラベルと図形記号との間をつなぐ,図による内

部リンクを保持するので,ラベルも記号と一緒にドラッグされる。だが,最終的な図の外見は美的判断の

問題で,どの記号にラベルが付加されたか混乱しないようにすることが望ましい。図を見ただけでは付加

されたかどうか視覚的にわかりにくい場合もあるが,グラフとしては明確,かつ,あいまいなところはな

い(そして,意味的な対応付けに関してもあいまいさは残らない。

5.8.3

表示上の選択肢

注記  (対応国際規格では,5.8.3 は解説的内容であるため,この規格では不要であり,不採用とした。)

5.8.4

注記  (対応国際規格では,5.8.4 は解説的内容であるため,この規格では不要であり,不採用とした。)

5.9

キーワード

容易に判別できる図形記号の数は,限られている。UML 記法では,テキストのキーワードを使用するこ

とによって,共通主題(例えば,基底クラスのメタモデル下位クラス,メタモデル基底クラスのステレオ

タイプ,並び要素のグループなど)に基づき複数の変化形を区別する。ユーザ側から見ると,メタモデル

下位クラスとステレオタイプとの間の区別はあまり重要ではないが,ツールの作成者及びメタモデルの実


93

X 4170

:2009 (ISO/IEC 19501:2005)

装者には重要である。

一般的な記法では,ギュメ“«»”で囲んでキーワードを使用する。

例  «キーワード»

この規格では,特定の定義済みのキーワードについて記述している。これらのキーワードは,記法にお

いては予約語として扱わなければならない。それ以外はユーザがステレオタイプ名として使用できる。定

義済みキーワードと同じステレオタイプ名を使用することを禁じる。

5.10

5.10.1

  意味論

様々な UML の構成要素で式が必要とされる。式とは,実行時に評価すると特定の値を返す,言語で表

された計算式とする。式は,型,論理値及び数値の表現を含む。UML は,式に対する明示的な言語解析機

を含まない。むしろ,式はある言語の文字列として表現される。制約言語 OCL は UML の意味論定義に使

用され,ユーザレベルでも使用できる。また,その他の言語(プログラム言語など)も使うことができる。

型の構文は言語依存度が高いので,UML では型の式を構築する構文を規定することを避ける。クラス又

は単純データ型の名前は,単純 Classifier 参照と対応するが,複雑な言語依存の型の式からなる構文

(C++の関数ポインタなど)は,仕様言語の責任とする。

5.10.2

  記法

式は,ある言語で定義された文字列で表示される。文字列の構文はツール及びその言語解析機の責任と

する。解析機は,実行時に文字列を評価して適切な型を生成したり,又は式の意味把握のために意味構造

を生成したりすることが可能とみなす。例えば,型の式は Classifier 参照に対して評価を行い,論理式

は真偽いずれかに対して評価する。言語自体は,モデル化ツールに既知であるが一般に図の中では明示し

ない。これは,式の形式がその目的を明確にしているという前提があるからである。

5.10.3

  例

注記  (対応国際規格では,5.10.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.10.4

  対応付け

注記  (対応国際規格では,5.10.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.10.5

  OCL 

注記  (対応国際規格では,5.10.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.10.6

  選択される OCL 記法

注記  (対応国際規格では,5.10.6 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.10.7

注記  (対応国際規格では,5.10.7 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.11

ノート

ノートとは,テキスト情報を含む図的記号とする(埋め込まれた画像を含む場合もある。

。ノートは,

制約,注釈,メソッド本体及びタグ付き値といった,メタモデルから様々なテキスト情報を表示するため

の記法とする。


94

X 4170

:2009 (ISO/IEC 19501:2005)

   

5.11.1

  意味論

ノートは,記法上の項目とする。幾つかの意味要素においてテキスト情報を示す。

5.11.2

  記法

ノートは,右上隅が“折れ曲がっている”長方形として表現される。ノートは,任意テキストを含む。

また,ある図式の中で,破線を用いてゼロ個以上のモデル化要素に接続することができる。

5.11.3

  表示上の選択肢

注記  (対応国際規格では,5.11.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.11.4

  例

注記  (対応国際規格では,5.11.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.11.5

  対応付け

注記  (対応国際規格では,5.11.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.12

型とインスタンスとの対応

モデル化の主な目的は,多岐にわたる具体的な項目を記述するような,はん(汎)用記述を用意する。

これはときに型・インスタンス二分法として知られる。UML におけるモデル化概念の大半が,この二面性

をもっており,普通は,モデル化は二つの対になったモデル化要素によって行われる。二つの要素のうち,

一つははん(汎)用の記述子,もう一つは記述を行う個別の項目を表現する。こうした対の要素の UML

に お け る 例 は , Class-Object , Association-Link , UseCase-UseCaseInstance ,

Message-Stimulus

などである。

型的な要素及びインスタンス的な要素の図は全く同じではないが,多くの類似点をもつ。したがって,

型−インスタンスの対になった各要素に対して,対応関係が見てすぐ分かるような記法を選ぶと都合がよ

い。こうした方法の数は限られており,それぞれに利点及び欠点がある。UML では,型−インスタンスの

区別は,要素の各組に対して同じ幾何学記号を使用した上でインスタンス要素の名前文字列(型名が存在

しているときはそれも含む。

)に下線を引くことによって示す。こうした視覚的な区別で,図の全体がイン

スタンス要素を含む場合でさえ,通常は特に強調しなくても容易に見分けられる。

図 38−クラスとオブジュクト

ツール利用者の選択肢としては,インスタンス要素を,例えば色又は埋め込みパターンなど異なる図形


95

X 4170

:2009 (ISO/IEC 19501:2005)

マーカで自由に代替可能である。

(コラボレーションにおける)役割は,型とインスタンスとのほぼ中間に位置する。インスタンスに似

た点としては,単一の分類子に対する個々の出現を識別する。型に似た点としては,多くの異なるインス

タンスをもつことができる再利用可能な要素を記述する。役割は分類子の区別可能な使用法であるが,そ

れでいて一般的な記述(コラボレーション)の一部でもあり,多くのインスタンスを生成することができ

る。実行時オブジェクトは,ゼロ個以上のクラス及びゼロ個以上の役割に対応することがある。役割の記

法では,その基底分類子を表示してもよい。インスタンスの記法では,その分類子の仕様,役割の仕様,

又は両方ともを記述してもよい。

役割は,名前,コロン及び下線なしでコラボレーションの一部となる型によって示される。インスタン

スは,付加的な名前,付加的な斜線,それに続く役割の並び,コロン,型の並びなどで示される。

図 39−役割及びオブジェクト

第 区分  モデル管理

5.13

パッケージ

5.13.1

  意味論

パッケージは,モデル要素のグループ化とする。パッケージそれ自体は,他のパッケージ内で入れ子に

できる。パッケージは,他種のモデル要素と同様,下位パッケージを含むことができる。すべての UML

モデル要素は,パッケージに入れて整理することができる。

パッケージはモデル要素を所有し,また,構成制御,格納及びアクセス制御の基礎となる。各要素は単

一パッケージが直接所有するので,パッケージ階層は厳密な木構造になる。しかし,パッケージは,

Permission

依存の

«import»

及び

«access»

を用いてモデル化された,他のパッケージを参照できる。そ

して,利用関係はグラフになる。パッケージ間の他の依存関係は,通常,複数要素の間に一つ以上の依存

があることを示す。

5.13.2

  記法

パッケージは大きな長方形で表され,その左上隅に小さな長方形(

“タブ”

)を付加する。これは,通常

のフォルダのアイコンである。

パッケージの内容は,大きな長方形の中に表示することができる。また,内容をパッケージの外側に描


96

X 4170

:2009 (ISO/IEC 19501:2005)

   

画して,包含される要素を線で結ぶという表示もできる。プラス記号(+)を円の中に描いて,その端点

でコンテナに接続させる。

−  大きな長方形の中にパッケージの内容を表示しない場合は,パッケージ名を長方形の中に置くことが

できる。

−  大きな長方形の中にパッケージ内容を表示する場合は,パッケージ名をタブの中に置くことができる。

キーワード文字列は,パッケージ名の上に置くことができる。既定義ステレオタイプの facade,

framework

,stub,及び topLevel はギュメ“«»”でくくることができる。

特性の並びは,パッケージ名の後又は下に,波括弧“{}”でくくる。例:{abstract}。特性構文の詳

細については,5.17 に示す。

パッケージ要素のパッケージ外での可視性は,可視性記号(公開の場合“+”

,私的の場合“-”

,保護の

場合“#”

,パッケージは“~”

)を要素名の前に置いて示すことができる。

複数パッケージにまたがる要素の関係性を示すため,記号間に関係性を示す線を表示することができる。

二つのパッケージ間の移入又はアクセスの関係性は,それぞれ文字列

«import»

又は

«access»

がラベルと

して付いた開矢じり破線矢線で描画する。

移入又はアクセスされたパッケージの要素は,パッケージ記号の外側に表示することができる。移入さ

れたパッケージにある(公開の)要素はクライアント側の名前空間に追加されるので,パッケージ記号の

内側に描画することも可能である。

5.13.3

  表示上の選択肢

注記  (対応国際規格では,5.13.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.13.4

  スタイルガイド

注記  (対応国際規格では,5.13.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.13.5

  例

注記  (対応国際規格では,5.13.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.13.6

  対応付け

注記  (対応国際規格では,5.13.6 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.14

サブシステム

5.14.1

  意味論

パッケージがモデル要素を組織化するはん(汎)用機構であるのに対し,サブシステムは物理システム

内の振る舞い単位,ひいてはモデル内の振る舞い単位を表現する。サブシステムはインタフェースを提供

し,複数の操作をもつ。そして,その内容は,仕様要素及び実現要素に分割される。サブシステムの仕様

は,ユースケース,状態機械などの仕様要素を伴う,サブシステム上の操作で構成される。

名前空間を定義することを除けば,サブシステムは,それが包含するモデル要素の振る舞いの仕様単位

となる。サブシステムはインスタンス化可能な場合及び不可能な場合がある。

5.14.2

  記法

サブシステムは基本的にパッケージと同じ方法で示されるが,大きな長方形の右上隅にさすまた型の記

号を追加する。サブシステムの名前は(省略可能なキーワード,ステレオタイプなどとともに)大きな長


97

X 4170

:2009 (ISO/IEC 19501:2005)

方形の中に置かれる。特に,サブシステムの内容を大きな長方形の中に表示する場合などは,サブシステ

ム名及び分岐をタブ(小さな長方形)内に置く。

インスタンス化可能なサブシステムは,その名前の上に文字列

«instantiable»

をもつ。

大きな長方形は三つの区画をもち,それぞれ,複数の操作,複数の仕様要素,及び複数の実現要素のた

めにある。これらは通常,長方形を垂直線によって区切ってから垂直線の左側の部分を水平線によって(更

に)二つの区画に分けることで示される。操作は左上の区画に,仕様要素はその下に,実現要素は右の区

画に表示する。後の二つの区画(左下及び右)には,それぞれ“Specification Elements”及び

“Realization Elements”とラベルを付けて,混同を避ける。操作区画にはラベルを付けない。これ

がサブシステム記法の一般的なパターンであるが,図によってはカスタム化された違う方法も多く用いら

れる。

図 42−三つの区画がある,サブシステム記法の一般的なパターン

実現部分から仕様部分への対応(すなわち,操作及び仕様要素への対応)は,白抜き閉矢じり破線矢線

を用いて描画される。コラボレーションを表示するためには,対応関係をテキストで表すこともできる。

1

枚の図中にあるサブシステムをそれと同格の他の要素群と一緒に示すときには,内容を表示しないこ

とが多い。そうした場合は,大きな長方形の中に区画は作らない。

5.14.3

  表示上の選択肢

注記  (対応国際規格では,5.14.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.14.4

  例

注記  (対応国際規格では,5.14.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.14.5

  対応付け

注記  (対応国際規格では,5.14.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.15

モデル

5.15.1

  意味論

モデルは,物理システムのあるビューを示す。ゆえに,ある目的を伴う物理システムの抽象化とする。

例えば,利害関係者の置かれるカテゴリに対して,物理システムの振る舞いの側面を記述する。モデルは,

物理システムをこの特定のモデルの目的に沿って完全な形で表現するのに必要なすべてのモデル要素を含


98

X 4170

:2009 (ISO/IEC 19501:2005)

   

む。このモデル内のモデル要素は,パッケージ・サブシステム階層で構成される。階層の最上位パッケー

ジ・サブシステムは物理システムの境界を表現する。

同一の物理システムの異なるモデルは,そのシステムの異なる側面を表示する。予約

«systemModel»

は,物理システムのためのモデル集合全体を包含するモデルに適用できる。

異なるモデル内の要素間の関係は,モデルの自己完結性によって,モデル内容に意味論上の影響を与え

ない。しかし,洗練作業をトレースしたり,モデル間をまたぐ要求のつながりを保持したりするには有用

である。

モデル間の関係は,洗練,移入などを表す。

5.15.2

  記法

モデルは,通常のパッケージ記号の大きな長方形の右上隅に小さな三角形を記述して表される。特にモ

デル内容が大きな長方形の中に表示される場合は,三角形をタブ内のモデル名の右に描画してよい。

複数のモデル間の関係は,異なるモデル内の要素間の関係と同様,既知の様々な関係記法を用いて表示

される。特にトレース依存は,«trace»

を付けた破線に選択肢として矢じりが開いた形の矢印を付けた開

矢じり破線矢線で記述される。

5.15.3

  表示上の選択肢

注記  (対応国際規格では,5.15.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.15.4

  例

注記  (対応国際規格では,5.15.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.15.5

  対応付け

注記  (対応国際規格では,5.15.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

第 区分  一般拡張機構

この章の要素は,任意のモデル化要素に適用できるはん(汎)用の機構とする。特別の用途の意味論は,

利用者の取り決め,又は特定の制約言語若しくはプログラム言語による解釈に依存する。したがって,そ

れらは UML に対する拡張可能性の仕組みを構成する。

5.16

制約及び注釈

5.16.1

  意味論

制約とは,モデル要素間での意味論関係とする。制約は,この関係で真を維持しなければならない条件

及び命題を規定する。制約が真でない場合,モデルによって記述されているシステムは無効となる(その

結果は,UML の範囲外である。

。ある種の制約(例えば,関連の xor 制約)は UML で既に定義されてい

る。その他は,ユーザが定義してよい。ユーザ定義制約は,所定の言語における単語で記述され,その構

文及び解釈はツールに任される。制約はモデル要素に対し付加される意味論的情報を表現し,単にモデル

要素のビューに対し付加するものではない。

注釈とは,モデル要素に直接に付加された文字列(人間が判読可能な文書への参照を含む。

)とする。注

釈は任意のテキスト情報を一般的に重要と想定される任意のモデル要素に付加するが,意味論的には効果

をもたない。注釈は,判断根拠の説明に用いることができる。


99

X 4170

:2009 (ISO/IEC 19501:2005)

5.16.2

記法

制約は,波括弧“{}”内のテキスト文字列で示す。形式的制約を書くことができるような言語を一つ以

上ツールが提供することを期待している。制約を書くための記述の定義済み言語の一つに OCL がある。

OCL

を使用しないで,制約を自然言語で書き表すことができる。それぞれの制約は特定の言語で書き表さ

れるが,通常は図に表示されない(ただし,ツールはその制約を保持しなければならない。

(属性など)記法がテキスト文字列となる要素に対しては,制約文字列を波括弧でくくり,その要素テ

キスト文字列の直後につなぐことができる。

(クラス内の属性など)記法がテキスト文字列の並びとなる要素に対しては,制約文字列は,その並び

要素として表すことができる。この制約は,他の制約文字列の並び要素まで,又は並び要素の終端まで,

後続するすべての並び要素に適用される。並び要素に付加された制約は,一般制約を置き換えることはな

いが,制約文字列内において個々の制約を強化又は修正することができる。

(クラス又は関連経路のような)単一の図的記号に対しては,制約文字列はその記号の近くに置く。記

号が名前をもつ場合,名前の近くに置く。

(二つのクラス又は二つの関連のような)二つの図的記号に対しては,制約は一つの要素からもう一つ

の要素への破線矢線として示され,波括弧内の制約文字列によってラベルが付けられる。矢線の方向は,

制約における関連情報となる。クライアント(矢線の後端)は制約の最初の位置に対応付けられる。供給

者(矢線の先端)は制約の二番目の位置に対応付けられる。

三つ以上の図的記号に対しては,制約文字列をノート記号中に書き,各記号と破線で結ぶ。この記法は

他の場合にも使用できる。

[はん(汎)化経路又は関連経路のような]同じ種類の三つ以上の経路に対して

は,すべての経路を横切る破線に制約を付加する。

注釈はノートアイコン内に(波括弧でくくらない)テキスト文字列として表す。他の(式又は制約のよ

うな)要素中に注釈を含める構文を UML は規定しないが,ツールが特定の言語に対する式構文の一部と

して提供することができる。

5.16.3

  例

注記  (対応国際規格では,5.16.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.16.4

  対応付け

注記  (対応国際規格では,5.16.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.17

要素特性

様々な要素が視覚的な記法のない詳細特性をもつ。タグ付き値機構を使ってユーザが新しい要素特性を

定義できる。

モデル要素に付加された特性を表示するために文字列を用いることができる。メタモデル属性,並びに

既定義及び利用者定義のタグ付き値で表される特性が含まれる。

5.17.1

  意味論

一般に特性は,属性,関連,及びタグ付き値を含むモデル要素に付加された任意の値を表す。任意の要

素から間接的に見つかる値を含む。ある種の特性は,

(UML では規定しない)式内部で構文をもつ。しか

し明白な UML 記法ではない。

タグ付き値は,キーワードと値との対とする。タグ付き値は,

(図形要素及び意味モデル要素を含む)あ

らゆる種類のモデル要素に付加できる。キーワードをタグと呼ぶ。タグは,一つ以上の種類のモデル要素


100

X 4170

:2009 (ISO/IEC 19501:2005)

   

に適用可能な特性を表現する。タグ及び値は,いずれも文字列としてコード化される。タグ付き値は UML

の拡張機構であり,任意情報をモデルに付加することを許す。モデル作成ツールには文字列として記述さ

れたタグ付き値を定義,表示,及び検索するための基本的な機能の提供が期待される。しかし,UML の意

味論を拡張するような機能は期待しない。コード生成,報告書出力その他の支援ツールが,タグ付き値を

読み,柔軟な方法でそれらの意味論を誘導することが期待される。

5.17.2

  記法

特性(メタモデル属性又はタグ付き値)は,波括弧“{ }”でくくられたコンマ区切りの特性仕様の系列

として表示する。

特性仕様は,次の形式をもつ。

name = value

ここで name は特性(メタモデル属性又は任意のタグ)の名前であり,value はその値を表す任意の文

字列である。特性の型が論理型であり value が省略された場合,省略時値は真とする。真値を指定するた

めにはキーワードを書くことができる。偽値を指定するためには,name も value も完全に省略する。他

の型の特性は明示的な値が必要である。文字列又は数字以外の値をとる場合,値の表示構文はツールに任

される。

特性文字列はタグ付き値と同様に,組込み型属性を表示するために使用できる。

論理型特性はしばしば isName の形をとる。

ここで name を真又は偽の値をとる何らかの条件名とする。

このとき name が値を伴わずに単独で現れると,

“isName = true”を意味する。例えば,{abstract}

{isAbstract = true}

と同様とする。

タグ付き値は他のモデル要素を参照することができる(4.6.2.5 を参照)

。そのような場合,値が参照され

たモデル要素の名前である場合を除き,通常のタグ付き値の書式が用いられる。代わりに,依存関係の記

法である«taggedValue»関係を用いて図的に表現することができる。依存関係を表す矢の向きは参照さ

れる要素へ向く。これら二つの例を,

図 53 に示す。


101

X 4170

:2009 (ISO/IEC 19501:2005)

図 53−参照としてのタグ付き値の代替記法

5.17.3

  表示上の選択肢

注記  (対応国際規格では,5.17.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.17.4

  スタイルガイド

注記  (対応国際規格では,5.17.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.17.5

  例

注記  (対応国際規格では,5.17.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.17.6

  対応付け

注記  (対応国際規格では,5.17.6 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.18

ステレオタイプ

5.18.1

  意味論

ステレオタイプは事実上,モデル化作業時に導入されるメタモデル要素の新しいクラスとする。ステレ

オタイプは,同じ形式(属性及び関係)をもつ既存のメタモデル要素の下位クラスとして表現し,異なる

目的をもつ。一般に,ステレオタイプは用法上の違いを表現する。ステレオタイプ付き要素は,基底メタ

モデルクラスに存在する制約に対し追加的な制約をもつことができる。ステレオタイプ付き要素は,ステ

レオタイプを付加された要素によって,必要とされる情報を追加するためのタグ付き値をもつことができ

る。コードジェネレータ及びその他のツールでは,ステレオタイプ付き要素を特別に扱うことが期待され


102

X 4170

:2009 (ISO/IEC 19501:2005)

   

る。ステレオタイプは,UML の組込み拡張機構の代表例である。

5.18.2

  記法

ステレオタイプの一般的な表し方は,要素名(ある場合)の上にキーワード文字列を書くこと以外は,

メタモデルの基本要素の記号を用いるのと同じとなる。このキーワード文字列(5.9 を参照)は,ステレオ

タイプ名をギュメ“«»”で囲む。ギュメは,フランス語名などで使用される引用符号である(例えば,«

ステレオタイプ 1»)

注記  ギュメは二つの山括弧のように見えるが,ほとんどの拡張フォントにおいては一つの文字であ

る。ほとんどのコンピュータでは文字列変換ユティリティがある。山括弧を二つ重ねるのを代

用手段として用いてもよい。

キーワード文字列は一般に記述しようとしているモデル要素の名前の上部又は前方におかれる。複数の

ステレオタイプが同一のモデル要素に定義される場合は,一方が他方の下にくるように垂直的に配置され

る。並び要素としても使用できる。この場合,他のステレオタイプ文字列又は空のステレオタイプ文字列

“«»”がくるまで,その後続の並び要素に適用される。ステレオタイプ名は,その要素型に適用可能な定

義済みキーワードに一致しないのが望ましい。

UML

記法の図形の拡張を許すために,図形アイコン又は図形マーカ(生地,色などの)をステレオタイ

プに関連付けることができる。UML は図的な仕様の形式は指定しないが,多くのビットマップ及び線画フ

ォーマットは存在する(それらの移植性は困難な問題である。

。このアイコンは,次の二つのうちのいず

れかの方法で使用できる。

a)

そのステレオタイプの基底モデル要素の記号の一部として用いられているステレオタイプのキーワー

ド文字列の代わり,又は追加として使用できる。例えば,クラス長方形内の名前区画域の右上隅に置

く。この形式では,内容を見ることができる。

b)

基底モデル要素記号全体をアイコンに縮退でき,その要素名はアイコンの中,又はアイコンの上下に

置く。基底モデル要素記号に含まれている他の情報は省略される。アイコン仕様のより一般的な形式,

及び違う形式も考えられるが,それはツール設計者の工夫に任せる。過度な拡張は移植性を損なう。

複数のステレオタイプが定義された場合は,図形アイコン又は図形マーカが省略される。

UML

は,色のような図形マーカの使用を避けている。これは,色の識別が困難な人又は主要な周辺装置

であるプリンタ,コピー機,ファックスなどへの制約を排除するためである。UML 記号は,そのような図

形マーカを必要としない。利用者は,個人目的においてはツールで強調表示をするなど,自由に図形マー

カを用いてよいが,互換性の制限を知っておくことが望ましい。また,必要な場合には,標準形式を用意

しておく必要がある。

ステレオタイプそれ自身の分類階層は,5.35 に述べられているようにクラス図で表示できる。この機能

は,既存のステレオタイプを使い,新たなステレオタイプを定義しない多くのモデル設計者には必要ない。

5.18.3

  例

注記  (対応国際規格では,5.18.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.18.4

  対応付け

注記  (対応国際規格では,5.18.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。


103

X 4170

:2009 (ISO/IEC 19501:2005)

第 区分  静的構造図

クラス図は,モデルの静的構造,特に,存在物(クラス及び型)

,その内部構造,及び他のものとの関係

を示す。クラス図は時間情報を示さないが,時間的な振る舞いをもったり記述したりするものを具体化し

た存在を含むこともできる。オブジェクト図は,クラス図に適合するインスタンスを示す。

第 5 区分では,クラス及びその変種,テンプレート及びインスタンス化クラス,クラス間の関係[関連

とはん(汎)化]

,並びにクラスの内容(属性及び操作)を示す。

5.19

クラス図(類図)

クラス図は,静的関係で接続された Classifier 要素のグラフとする。クラス図には,インタフェース,

パッケージ,関係,更には,オブジェクト又はリンクのようなインスタンスまでもが含まれる。静的構造

図のほうがよりよい名前だが,クラス図のほうが簡潔であるし,一般にも普及している。

5.19.1

  意味論

クラス図は,静的構造モデルの図的なビューとする。個々のクラス図がモデルの各区画を表現するわけ

ではない。

5.19.2

  記法

クラス図は,宣言された静的モデル要素,例えばクラス,インタフェース,それらの関連などのモデル

要素の集まりとする。それらはお互い同士及びその内容とでグラフを構成する。複数のクラス図は,パッ

ケージに組織化することができる。このパッケージは,対象とするモデルそのものに対応するパッケージ

であるか,又は対象とするモデルパッケージ上に作られた別パッケージのいずれかである。

5.19.3

  対応付け

注記  (対応国際規格では,5.19.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.20

オブジェクト図(個体図)

オブジェクト図は,オブジェクト及びデータ値からなるインスタンスのグラフとする。静的オブジェク

ト図は,クラス図のインスタンスとなる。ある時点におけるシステムの詳細な状態のスナップショットを

示す。オブジェクト図の利用は限定的であり,主にデータ構造の例を示すのに使う。

ツールがオブジェクト図に別の表示形式を提供する必要はない。クラス図はオブジェクトを含むことが

できる。オブジェクトを含み,かつ,クラスをもたないクラス図がオブジェクト図となる。いろいろな方

法で特定の用法を示すには,オブジェクト図といういい方は便利である。

5.21

分類子

Classifier

は,Class,DataType 及び Interface のメタモデル上位クラスとする。これらはすべ

て類似した構文をもち,キーワード付きの長方形記号で表記され,必要ならばキーワードを付ける。図に

おいてクラスが最も共通的なので,クラスはキーワードなしの長方形で表現し,その他の Classifier

の下位クラスにはキーワードを付ける。次の箇条では Class を中心に説明するが,記法のほとんどは,他

の種類の要素に対しても意味論的に適切に適用できる。

5.22

クラス

クラスは,類似の構造,振る舞い及び関係をもつオブジェクトの集合に対する記述子とする。モデルで

は,クラスの内包,すなわちクラスを定義する規則の記述を旨とする。実行時は,その外延,すなわちそ

のインスタンス集合を与える。UML は,クラス宣言の仕方及びクラスの性質の指定方法に関する記法だけ

でなく,クラスの使用記法も提供している。その形式においてクラスに類似した(インタフェース,シグ

ナル,ユティリティなどの)モデル化要素は,クラス記号上にキーワードを使って示される。これらは独


104

X 4170

:2009 (ISO/IEC 19501:2005)

   

立したメタモデルクラス又は Class のステレオタイプである。クラスはクラス図の中で宣言され,他のほ

とんどの図において使用される。UML は,クラスを宣言し使用するための図的記法,及び他のモデル要素

の中のクラスを参照するためのテキスト形式の記法を提供する。

5.22.1

  意味論

クラスは,モデル化されるシステム内の概念を表す。クラスは,データ構造,振る舞い,及び他の要素

との関係をもつ。

クラスの名前は,それが宣言されるパッケージ内で適用範囲をもち,パッケージ内で(クラス名の間で)

一意でなければならない。

5.22.2

  基本記法

クラスは,水平線で区分された三つの区画をもち,実線の長方形として描かれる。最初の名前区画は,

クラス名及びそのクラスの(ステレオタイプを含む。

)その他の一般的特性を保持する。中間の並び区画は

属性の並びを保持する。最後の並び区画は操作の並びを保持する。

詳細については,5.235.24 を参照する。

5.22.2.1

  参照

パッケージ名の指定がない場合,パッケージ内に示されるクラスはそのパッケージ内で定義されるもの

と仮定する。他のパッケージにおいて定義されたクラスへの参照を示すために,次の構文を使用する。

        Package-name::Class-name

フルパス名は,二重コロン“::”でパッケージ名を連結することによって指定できる。

5.22.3

  表示上の選択肢

注記  (対応国際規格では,5.22.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.22.4

  スタイルガイド

注記  (対応国際規格では,5.22.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.22.5

  例

注記  (対応国際規格では,5.22.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.22.6

  対応付け

注記  (対応国際規格では,5.22.6 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.23

名前区画

5.23.1

  記法

名前区画は,クラス及びその他の特性の名前を次のように表示する。

選択可能のステレオタイプキーワードをギュメ“«»”でくくりクラス名の上に置く,及び/又はステレ

オタイプアイコンを区画の右上隅に置く。ただし,ステレオタイプ名が定義済みキーワードと一致しては

ならない。

クラスの名前はその次に表れる。抽象クラスの場合,

(斜体字を扱える言語には)クラス名が斜体で表示

される。または,クラス名の下又は後にキーワード abstract を付ける。例えば,請求書

{abstract}


105

X 4170

:2009 (ISO/IEC 19501:2005)

ただし,はん(汎)化状態の明示的規定はフォント情報に優先する。

特性(メタモデル属性又はタグ付き値)を示す文字列並びを,クラス名の下の波括弧内に置く。この並

びは,UML 記法にないクラス属性及びタグ付き値も表示できる。論理型キーワードの値指定がない場合,

その値は真とみなす。例えば,leaf(クラス階層中の末端の下位クラス)のクラスは,特性

{leaf}

もつ。

ステレオタイプ及び特性並びは,選択可能とする。

図 56−名前区画

5.23.2

  対応付け

注記  (対応国際規格では,5.23.2 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.24

並び区画

5.24.1

  記法

並び区画は,文字列並びを保持し,各項目は,属性,操作などの素性の表現とする。文字列は一行に一

つ表示する。一行に入らない場合どのように表示するかはツールに依存する。属性又は操作並び以外に,

選択可能並びを使って既定義の値又はユーザ定義の値(責務,規則,修正の履歴など)を示すこともでき

る。UML では選択可能並びを定義しない。利用者定義並びの操作は,ツールに依存する。

並び項目は,順序付けがされている。その順序は,利用者が変更してよい。要素順序は意味のある情報

であり,ツールの中でアクセス可能でなければならない(例えば,コード生成ツールによって宣言並びの

生成に使用できる。

。並び要素は,他目的のために異なる順序で(例えば,ある方法でソートして)提示

してもよい。その並びがソートされても,元になるモデルにおける最初の順序は維持する。順序情報が単

に見え方上抑止されているだけである。

並びの最終要素又は並びの区切られた節の最終要素としての省略記法“.

”は,そのモデルにおいて選

択条件に合致する他の並び要素がまだ存在するが,その並び中には表示しないことを表す。そのような隠

れた要素は,その並びの異なる見せ方では現れてよい。

5.24.1.1

  グループ特性

特性文字列が並びの要素として示されてもよい。その場合,他の特性文字列が表れるまで,後続のすべ

ての並び要素にその特性が適用される。特性を各々の並び要素に付加するのと等価とする。特性文字列は,

モデル要素を指示しない。例としては,ステレオタイプ及び可視性の指定が挙げられる。キーワード文字

列も,その後の並び要素を修飾するために同じように使用できる。

5.24.1.2

  区画名

区画には,区画の種類を示す名前を表示することができる。区画名は,太字体で区画の上部中央に表示

する。一部の区画を省略したり,利用者定義区画を追加した場合にこの機能は便利である。Class には,


106

X 4170

:2009 (ISO/IEC 19501:2005)

   

attributes

及び operations という名前の定義済み区画がある。利用者定義区画の例としては,要件

などが考えられる。クラスには名前区画が必ず表されていなければならない。したがって,名前区画の区

画名は,記載しない。

5.24.2

  表示上の選択肢

注記  (対応国際規格では,5.24.2 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.24.3

  例

注記  (対応国際規格では,5.24.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.24.4

  対応付け

注記  (対応国際規格では,5.24.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.25

属性

属性区画の文字列は,クラスにおける属性を表示するために使用される。同様な構文が,限定子,テン

プレートパラメタ,操作パラメタなどを指定するために使用される(幾つかの構文ではある項が省略され

ることがある。

5.25.1

  意味論

属性は,意味論的には合成集約関連と等価とする。ただし,その目的及び用法は通常異なる。

属性の型は,Classifier とする。

5.25.2

  記法

属性は,属性モデル要素の各種特性へ構文解析することが可能なテキスト文字列として示される。既定

の構文を次に示す。

visibility name : type-expression [ multiplicity ordering ] = initial-value

{ property-string }

−  ここに,visibility は,次のいずれかとする。

・ + 公開可視性  (public)

・ # 保護可視性  (protected)

・ -

私的可視性  (private)

・ ~ パッケージ可視性  (package)

−  可視性マーカは,省略することもできる。可視性マーカが存在しないことは,可視性が表示されない

ことを表す(未定義又は公開ということではない。

。ツールは,可視性が表示されていなくても新し

い属性に可視性を割り当てることが望ましい。この可視性マーカは,完全な可視性特性仕様文字列の

簡略記法である。

−  可視性は,キーワード(public,protected,private,及び package)で指定することもでき

る。この形式は,特に属性全体のブロックに適用するためのインライン並び要素の場合に使う。

特定のプログラム言語に対して付加的な種類の可視性を定義してよい。例えば,C++の実装可視性

がある(現実にはすべての私的可視性は,言語依存である。

。そのような可視性は,特性文字列又は

ツール固有の取り決めで指定されなければならない。

−  name は,属性名を表現する識別子文字列とする。


107

X 4170

:2009 (ISO/IEC 19501:2005)

−  [multiplicity ordering]

は,属性の多重度及び順序付けを示す(5.44 を参照)

。この項は省略で

きる。省略した場合,多重度は 1..1(厳密に 1)とする。

−  ordering 特性は,多重度の上限が 1 より大きいときに意味をもつ。順序付け特性は,次のうちの一

つとなる。

・  (省略)

:  値は順序付けられていない

・  unordered:値は順序付けられていない

・  ordered:  値は順序付けられている

−  type-expression は,次の二つのうちのどちらかを表す。

・  分類子の名前

・  ProgrammingLanguageDatatype と対応付けられる言語依存の文字列

−  initial-value は,新しく生成されたオブジェクトの初期値に対する言語依存の式である。初期値

は,省略可能である(等号記号も省略可能)

。新しいオブジェクトに対する明示的なコンストラクタが

省略時の初期値を追加するか又は変更することができる。

−  property-string は,要素に適用する特性値を指示する。特性文字列は選択可能とする(特性が指

定されない場合,波括弧は省略される。

クラス有効範囲属性は,名前及び型表現文字列に下線を引くことによって示す。それ以外の属性は,イ

ンスタンス有効範囲になる。

        class-scope-attribute

この記法の正当性は,オブジェクトがインスタンス値であるように,クラス有効範囲属性が実行システ

ムにおけるインスタンス値であるということによる。両者とも下線を付すことによって指定できる。イン

スタンス有効範囲属性は,下線を付けない。これが既定値である。

属性が変更可能かどうかを示す記号はない(省略時値は変更可能)

。変更不能な属性は,特性

{frozen}

で示される。

多重度指示子がない場合,属性は厳密に一個の値を保持する。多重度は,次の例のように,分類子名の

あとの角括弧内に多重度指示子を入れることで指示できる。

        colors : 色[3]

        points : 点[2..* ordered]

多重度が 0..1 の場合は,ヌル値である可能性がある。すなわち,範囲内の特定の値をもつのではなく,

値そのものがない可能性を示す。例えば,次の宣言はヌル値と空文字列とを区別する。

        name : String [0..1]

ギュメ内のステレオタイプキーワードは,可視性表示を含む属性文字列全体の前に置かれる。波括弧内

の特性並びは属性文字列全体の後に置かれる。

5.25.3

  表示上の選択肢

注記  (対応国際規格では,5.25.3 は解説的内容であるため,この規格では不要であり,不採用とし


108

X 4170

:2009 (ISO/IEC 19501:2005)

   

た。

5.25.4

  スタイルガイド

注記  (対応国際規格では,5.25.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.25.5

  例

注記  (対応国際規格では,5.25.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.25.6

  対応付け

注記  (対応国際規格では,5.25.6 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.26

操作

操作区画の見出しは,クラスで定義された操作及びクラスによって提供されたメソッドを表す文字列と

する。

5.26.1

  意味論

操作は,そのクラスのインスタンスが実行を要求するサービスとする。操作には,名前及び引数並びが

ある。

5.26.2

  記法

操作は,操作モデル要素の各種特性へ構文解析できるテキスト文字列として示す。既定構文を次に示す。

visibility name ( parameter-list ) : return-type-expression { property-string }

−  ここに,visibility は,次のいずれかとする。

・ +  公開可視性  (public)

・ #  保護可視性  (protected)

・ -  私的可視性  (private)

・ ~  パッケージ可視性  (package)

可視性マーカは,省略できる。それは可視性を示していないことを表す(未定義又は公開ということで

はない。

。可視性マーカは,完全な可視性特性使用文字列の簡略記法とする。

可視性は,キーワード(public,protected,private,及び package)でも指定できる。この形

式は,操作全体に適用するためのインライン並び要素の場合に使う。

C++

の実装可視性のような付加的な可視性は,特定のプログラム言語に対して定義してよい(現実には

すべての非公開可視性は言語依存である。

。そのような付加的可視性は,特性文字列又はツール固有の取

り決めで指定する。

−  name は,識別子文字列である。

−  返却値型表現は,実装型又は操作が返す値の型の言語依存仕様である。操作が値を返さない場合(C++

void

のような)

,コロン及び返却値型を省略する。型表現並びを用いて,複数の返却値を示すことも

できる。

−  parameter-list は,コンマで区切った仮パラメタ並びである。次の構文で指定する。

        kind name : type-expression = default-value


109

X 4170

:2009 (ISO/IEC 19501:2005)

・  kind は in,out,又は inout であり,指定がない場合の省略時値は in である。

・  name は,仮パラメタの名前である。

・  type-expression は,実装型の(言語依存の)仕様である。

・  default-value は仮引数に対する選択可能な値表現であるが,対象言語の制限に従う。

−  property-string は,要素に適用する特性値を示す。特性文字列は,選択可能とする(特性を指定

しない場合は,波括弧も省略する。

クラス有効範囲操作は,文字列に下線を引く。インスタンス有効範囲操作が既定であり,かつ,マーク

されることはない。

システム状態を変更しない(副作用をもたない)操作は,特性

{query}

で指定する。{query}

が指定さ

れなければ,操作はシステム状態を変更することができるが,変更しない場合もある。

操作の並行性に関する意味論は,

特性文字列

{concurrency

=

name

}

で指定する。

name

は,

sequential

guarded

,concurrent のいずれかとする。指定がない場合には並行性に関する意味論は定義されず,最

悪の場合,逐次操作を仮定する。

最上位の操作呼出し仕様は,クラスの操作を宣言する(これは,そのクラスのすべての子孫に継承され

る。

。このクラスが操作を実装しない場合(すなわちメソッドを供給しない場合)

,その操作に

{abstract}

を付けるか,操作呼出し仕様を斜体にして抽象操作であることを示す。下位クラスで

{abstract}

特性な

しの操作呼出し仕様が現れた場合,その下位クラスがその操作に対応したメソッドを実装することを意味

する。

メソッドの実際のテキスト又はアルゴリズムは,操作見出しに付けられたノートで指定してもよい。

あるクラスのオブジェクトが与えられたシグナルを受け付けて応答する場合,«signal»

と見出しが付

いた操作は,そのクラスが与えられたシグナルを受け付けることを示す。構文は操作構文と同じである。

オブジェクトのシグナルに対する応答は状態機械で示す。この記法はあるクラスのオブジェクトがエラー

条件や例外に対してどう応答するかを示す。これをシグナルとしてモデル化する。

操作の振る舞い仕様は,その操作に付記されたノートで与えられる。ある言語による形式仕様(意味論

的な Constraint の場合)である場合,仕様のそのテキストは波括弧“{}”で囲まれていることが望まし

い。自然言語で振る舞いの記述(Comment)の場合,テキストには何も付けないことが望ましい。

ギュメ“«»”内のステレオタイプ  キーワードは,可視性表示を含む操作文字列全体の前に置く。波括弧

内の特性並びは,操作文字列全体の後に置く。

5.26.3

  表示上の選択肢

注記  (対応国際規格では,5.26.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.26.4

  スタイルガイド

注記  (対応国際規格では,5.26.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.26.5

  例

注記  (対応国際規格では,5.26.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.26.6

  対応付け

注記  (対応国際規格では,5.26.6 は解説的内容であるため,この規格では不要であり,不採用とし

た。


110

X 4170

:2009 (ISO/IEC 19501:2005)

   

5.27

入れ子クラス宣言

5.27.1

  意味論

別のクラスの中で宣言されたクラスはその別のクラスの名前空間に属し,その名前空間の中でだけ使う

ことができる。この構造構文は,主に実装上の理由であり情報隠ぺい(蔽)の理由のために用いられる。

5.27.2

  記法

クラス宣言とその名前空間内のクラスとは線で結ぶことができる。その線には,クラス宣言と結び付け

る端点にいかり(錨)アイコンを付ける。いかり(錨)は円の中に十字をもつ。パッケージの中身はクラ

スの内部で宣言され,かつ,その名前空間に属する。

5.27.3

  対応付け

注記  (対応国際規格では,5.27.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.28

型及び実装クラス

5.28.1

  意味論

クラスは,Type 又は Implementation Class としてステレオタイプ付けできる(区別しないでおく

ことも可能である。

。Type は,オブジェクトの物理的な実装を定義することなく,適用可能な一連の操

作を伴って,オブジェクト群の定義域を規定する。Type は,いかなるメソッドも含まない。操作に対す

る振る舞い仕様を提供することが可能である。Type は,また属性及び関連をもつことも可能であるが,

それらはあくまでもその型の操作の振る舞いを指定する目的だけに定義されるものである。

Implementation Class

は,そのオブジェクトの(属性及び関連に対する)物理的なデータ構造及び

メソッドを(C++,Smalltalk などの)伝統的なオブジェクト指向言語で実装したように定義する。

Implementation Calss

がある Type を実現しているというのは,その Type に定義されている操作を

すべて提供し,かつ,それらの操作の振る舞いが Type 操作仕様と一致していることをいう。一つの

Implementation Class

が複数の異なる Type を実現することがあり得る。

5.28.2

  記法

区分する必要のないクラスは,ステレオタイプなしで表示される。型は

«type»

で,実装クラスは

«implementationClass»

で示される。ツールは図全体の省略時設定を自由に行うことができ,ステレオ

タイプが明示されていないクラス記号はすべて,省略時のステレオタイプのクラスとして解釈される。こ

れは,プログラミングレベルに近いモデルにとって有効であろう。

クラスによる型の実装は,Realization 関係としてモデル化され,破線三角閉矢じり[破線のはん(汎)

化矢線]で示される。この記号は,実現するクラスが,振る舞いに適合する Type のすべての操作を少なく

とも提供することを意味し,

(属性又は関連といった)構造の継承は必ずしも意味しない。クラスはん(汎)

化階層は,通常はクラスが実現する型のはん(汎)化階層と同等であるが,実現する型の操作を提供する

限り,必ずしも必す(須)ではない。

5.28.3

  例

注記  (対応国際規格では,5.28.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.28.4

  対応付け

注記  (対応国際規格では,5.28.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。


111

X 4170

:2009 (ISO/IEC 19501:2005)

5.29

インタフェース

5.29.1

  意味論

インタフェースは,クラス,コンポーネント,及び(サブシステムを含む)他の Classifier の外部か

ら見える操作に対する,内部構造のない指定子とする。各インタフェースは,実際のクラスの振る舞いの

うち,限定された部分を指定することが多い。インタフェースには実装がない。属性,状態,関連もなく,

操作だけをもつ(インタフェースは単方向関連の終点端になり得るが,その場合でも,そのインタフェー

ス自身からの誘導可能性をもつ関連はもつことができない。

。インタフェースは,はん(汎)化関係をも

つことができる。インタフェースは,形式上は,属性もメソッドもなく抽象操作をもつ抽象クラスと等価

であるが,UML メタモデル内では,Interface は Class と同等に(ともに Classifier として)扱わ

れる。

5.29.2

  記法

インタフェースは Classifier であり,区画及び

«interface»

をもつ長方形記号を使って表示できる。

インタフェースが提供する操作の並びは,操作区画に置かれる。属性区画は常に空なので,省略してよい。

インタフェースは,インタフェース名をその下にもつ小さな円として表示することができる。この円は

それを提供する分類子と実線で結合される。これは,そのクラスがその円のインタフェース型のすべての

操作を提供することを示す。提供されている操作は,円の記法には示さない。操作並びを表すためには長

方形記号を使用する。インタフェースによって供給されている操作を使用又は要求するクラスは,円を指

す破線矢線でその円と接続する。破線矢線は,インタフェースで指定されている操作以外の操作をそのク

ラスが要求しないことを意味する。このクライアント側のクラスは,必ずしもそのインタフェースのすべ

ての操作を要求するわけではない。

分類子から提供するインタフェースへの Realization 関係は,破線三角閉矢じり[破線のはん(汎)

化記号]で示される。この記法は,実装クラスによる型の実現を示すのに使用する記法と同じである。実

際,この記法を二つの分類子記号間で用いることができ,クライアント(矢線の根元側)は,供給者(矢

線の頭側)で定義されたすべての操作を提供するが,供給者のデータ構造(属性及び関連)を提供する必

要はないことを示す。

5.29.3

  例

注記  (対応国際規格では,5.29.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.29.4

  対応付け

注記  (対応国際規格では,5.29.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.30

パラメタ化クラス(テンプレート)

5.30.1

  意味論

テンプレートは,一つ以上の未束縛の仮パラメタを伴った,クラスに対する記述子とする。それはクラ

スの族を定義し,その各クラスはその仮パラメタを実際の値に束縛することによって指定される。典型的

な仮パラメタは属性型を表すが,整数その他の型,又は操作さえも表すことができる。テンプレート内の

属性及び操作は,仮パラメタに基づいて定義される。したがって,それらの属性及び操作も,テンプレー

トが実際の値に束縛されたときに,結果として束縛される。

テンプレートには未束縛仮パラメタがあるので,そのままでは直接使用可能なクラスではない。仮パラ

メタは,束縛形式のクラスを形成するために,実際の値に束縛されなければならない。クラスがテンプレ


112

X 4170

:2009 (ISO/IEC 19501:2005)

   

ートの上位クラスになったり関連の終点端になったりする(しかし,テンプレートから他のクラスの一方

向関連は許される。

。テンプレートが通常のクラスの下位クラスだと,そのテンプレート束縛で形成され

るすべてのクラスは,その上位クラスの下位クラスであることを意味する。

仮パラメタ化は,Collaboration,Package など他の ModelElement にも適用できる。ここでのク

ラスに対する説明は,他の種類のモデル化要素にも同様に当てはまる。

5.30.2

  記法

小さな破線の長方形がクラスの長方形(又は他のモデル化要素の記号)の右上隅に重ね合わされる。破

線の長方形は,そのクラス及び実装型に対する仮パラメタのパラメタ並びを含む。並び表示は省略可能だ

が,並びが空であってはならない。パラメタ化クラスの名前,属性,及び操作は通常どおり,クラス長方

形の中に現れる。仮パラメタの実現値を含んでもよい。例えばパラメタの一つによって識別される関連ク

ラスを示す場合のように,仮パラメタの実現値は,そのクラスの文脈内で現れてもよい。

5.30.3

  表示上の選択肢

注記  (対応国際規格では,5.30.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.30.4

  例

注記  (対応国際規格では,5.30.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.30.5

  対応付け

注記  (対応国際規格では,5.30.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.31

束縛済み要素

5.31.1

  意味論

テンプレートは,はん(汎)化又は関連のような通常の関係では直接使用できない。パラメタを宣言し

ている範囲の外側では無意味な自由パラメタをもつからである。使用するためには,テンプレートのパラ

メタは実際の値に束縛されなければならない。パラメタに対する実際の値は,使用するときの有効範囲の

中で定義される式とする。参照する有効範囲自身がまたテンプレートである場合,参照するテンプレート

のパラメタは,参照されるテンプレートの束縛において実際の値として使用できる。しかし,テンプレー

トはそれぞれの外部には有効範囲をもたないので,二つのテンプレートのパラメタ名は対応するとは想定

できない。

5.31.2

  記法

束縛済み要素は,次のような要素名の文字列のテキスト構文として表示する。

    Template-name ‘<’ value-list ‘>’

value-list

はコンマで区切られた,値を表す式を要素とする空でない並びである。

Template-name

は,テンプレートの名前である。

例えば,VArray<点,3>

はテンプレート VArray によって記述されるクラスを指定する。

値の個数及び型は,与えられた名前のテンプレートに対するテンプレートパラメタの個数及び型に一致

しなければならない。

束縛済み要素の名前は,パラメタ化した要素名が使用できるところでは,どこに用いてもよい。例えば,

束縛済みクラス名はクラス図において,属性型又は操作呼出し仕様の一部として,クラス記号の中で使用


113

X 4170

:2009 (ISO/IEC 19501:2005)

できる。

束縛済み要素は,完全にそのテンプレートによって指定される。したがって,その内容は拡張されては

ならない。例えば,クラスに対する新しい属性又は操作の宣言は許されない。しかし,束縛済みクラスの

下位クラスを定義することができ,その下位クラスは通常の方法で拡張可能となる。

束縛済み要素とそのテンプレートとの関係は,«bind»

付きの Dependency 関係として表示できる。引

数は,«bind»

のあとの丸括弧内に示される。この表示形式を採用した場合,束縛済み形式が元のテンプレ

ートと異なる名前をもってもよい。

5.31.3

  スタイルガイド

注記  (対応国際規格では,5.31.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.31.4

  例

注記  (対応国際規格では,5.31.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.31.5

  対応付け

注記  (対応国際規格では,5.31.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.32

ユティリティ

ユティリティとは,クラス宣言の形式で,大域的な変数及び手続をグループ化する。これは基本的なモ

デル要素ではなく,プログラミングの便宜上の手段とする。ユティリティの属性及び操作は大域変数及び

大域手続となる。ユティリティは分類子のステレオタイプとしてモデル化される。

5.32.1

  意味論

ユティリティのインスタンス有効範囲の属性及び操作は,大域的な属性及び操作として解釈される。ユ

ティリティがクラス有効範囲の属性及び操作を宣言することは適切ではない。インスタンス有効範囲のメ

ンバは,既にクラス有効範囲に存在するものとして解釈されているからである。

5.32.2

  記法

ユティリティは,Class の

«utility»

として示される。それは属性及び操作の両方をもってもよく,す

べて大域的な属性及び操作として扱われる。

5.32.3

  例

注記  (対応国際規格では,5.32.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.32.4

  対応付け

注記  (対応国際規格では,5.32.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.33

メタクラス

5.33.1

  意味論

メタクラスとは,そのインスタンスがクラスであるようなクラスとする。

5.33.2

  記法

メタクラスは,Class の

«metaclass»

として示される。

5.33.3

  対応付け

注記  (対応国際規格では,5.33.3 は解説的内容であるため,この規格では不要であり,不採用とし


114

X 4170

:2009 (ISO/IEC 19501:2005)

   

た。

5.34

列挙

5.34.1

  意味論

列挙は,ユーザ定義のデータ型であり,そのインスタンスはユーザ指定の名前付き列挙リテラルとする。

リテラルは相対順序をもっているが,代数は定義されない。

5.34.2

  記法

列挙は,«enumeration»

の付いた Class 記法(長方形)を使って示される。列挙の名前は,上の区画

に配置される。列挙リテラルの順序付き並びは,真中の区画に一つ一行で配置する。リテラルに関して定

義した操作群は,下の区画に配置する。真中及び下の区画は省略してもよい。

5.34.3

  対応付け

注記  (対応国際規格では,5.34.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.35

ステレオタイプ宣言

5.35.1

  意味論

ステレオタイプはユーザ定義のメタ要素であり,その構造は既存の UML メタ要素(

“基底クラス”

)に

合致する。ステレオタイプはユーザ定義であるので,ステレオタイプ宣言は,それが概念的には上位のメ

タモデル層に属していても,UML4 階層のメタモデル化階層の“モデル”層に現れる要素とする。

5.35.2

  記法

ステレオタイプは二つの異なるメタモデル層をまたぐので,その二つの層の間をまたぐことを明確に示

すような特別な記法が必要となる。具体的には,どのようにモデルレベルの要素(ステレオタイプ)がメ

タ 要 素 ( UML の 基 底 ク ラ ス ) と 関 連 す る か を 示 す こ と が 必 要 と な る 。

図 67 に 示 さ れ る よ う な

«stereotype»

と呼ばれる特殊な Dependency のステレオタイプを用いることで表される。

ステレオタイプは,«stereotype»

の付いた Classifier 記法(長方形)を使って示す(

図 67)。ステ

レオタイプの名前は,上の区画に配置する。ステレオタイプによって記述される要素に対する制約は,

Constraints

と呼ばれる名前付き区画に配置できる。必要なタグは,Tags と呼ばれる名前付き区画に配

置できる。並びの中の各項目(タグ)は,次の形式で定義される。

        tagDefinitionName : String [multiplicity]

String

はタグの値の型を表現するデータ型の名前と合致する文字列であるか,又はメタクラス若しく

はステレオタイプへの参照とする。後者の場合,文字列は次の形式をもつ。

        «metaclass» metaclassName

又は

        «stereotype» stereotypeName

ここで,metaclassName は参照されたメタクラスの名前及び参照するステレオタイプの名前とする。

multiplicity

は選択可能であり,多重度を指定するための標準的な規則に適合する。範囲を指定する場

合には下限値であるゼロは選択可能なタグであることを示す。


115

X 4170

:2009 (ISO/IEC 19501:2005)

図 67−ステレオタイプ宣言の記法形式

図 67 における図の例にあるように,ステレオタイプ Persistent は UML のメタ要素 Class のステレ

オタイプとなる。TableName は省略可能なタグであり,その型は String と呼ばれるモデルの型となる。

ここで,SQLFile はモデルにおける Component のインスタンスに対する参照となる。

ステレオタイプのためにアイコンを定義することができるが,アイコンの図的な定義は UML の有効範

囲外であり,編集ツールによって扱われる。

ステレオタイプ及びタグを指定する代替的で一般的なより簡便な方法が

表 及び表 にそれぞれ示して

ある。

表 2−ステレオタイプ指定のテーブル形式

ステレオタイプ

基底クラス

タグ

制約

記述

アーキテクチャ
要素

Generalizable

Element

N/A N/A

N/A

はん(汎)用ステレオタイプ。
アーキテクチャのモデル化
に使われるすべての他のス

テレオタイプの上位ステレ
オタイプとする。

カプセル

Class

アーキテクチ

ャ要素

isDynamic

self.isAct

ive

= true

アーキテクチャ仕様の構造

化コンポーネントのモデル
化に使われるクラスを示す。


116

X 4170

:2009 (ISO/IEC 19501:2005)

   

表 3−タグ指定のテーブル形式

タグ

ステレオタイプ

多重度

記述

isDynamic

カプセル

UML::Datatypes::Boolean

1

関連するカプセルクラスが,

動的に生成,解体できるかを
識別するために使われる。

表 のステレオタイプ指定の各行は一つのステレオタイプを定義し,表 のタグ指定の各行は一つのタ

グ定義を含んでいる。

ステレオタイプ指定表の列は,次のように定められている。

−  ステレオタイプ:ステレオタイプの名前。

−  基底クラス:ステレオタイプの基底として提供される UML メタモデル要素。

−  親:定義されたステレオタイプの直接的な上位(上位が一つも存在しない場合は“N/A”の記号が用

いられる。

−  タグ:このステレオタイプに結び付けられたタグ付値のすべてのタグの並び(一つも定義されていな

い場合は N/A。

−  制約:このステレオタイプに結び付けられた制約の並び。

−  記述:説明するために付いた注釈などの非形式的記述。

タグ指定表の列は,次のように定義されている。

−  タグ:タグの名前。

−  ステレオタイプ:このタグを所有するステレオタイプの名前。単独のタグの場合は“N/A”

−  型:タグに結び付けられる値の型の名前。

−  多重度:一つのタグのインスタンスに結び付けられる値の最大の個数。

−  記述:説明するための注釈などの非形式的記述。

ステレオタイプ指定表及びタグ指定表の双方において,適用可能な指定がない列は省略される。

図におけるステレオタイプ指定表の例では,二つの関係あるステレオタイプが定義されている。一行目

では GeneralizableElement のステレオタイプである

«

アーキテクチャ要素»

が宣言されている。二行目

では

«

ア ー キテ クチャ要 素 »

で あ る

«

カ プ セ ル »

が 宣 言 されて いる が, これ は メ タモ デ ル におけ る

GeneralizableElement

の下位クラスであるクラスのインスタンスに適用する。

図 68 は,図 67 の表と等価な宣言を示したものだが,制約及び非形式的記述が省かれている。

図 68−図 67 で表したステレオタイプ宣言の等価図式


117

X 4170

:2009 (ISO/IEC 19501:2005)

5.35.3

  対応付け

注記  (対応国際規格では,5.35.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.36

ベキ型

5.36.1

  意味論

ベキ型(Powertype)は,そのインスタンスがモデル内のクラスであるようなユーザ定義のメタ要素と

する。

5.36.2

  記法

Powertype

は,«powertype»

の付いた分類子記法(長方形)を使って示す。Powertype の名前は上

の区画に配置する。その要素は通常のクラスであるため,ベキ型の属性及び操作を通常利用者は定義しな

い。

ベキ型のインスタンスは,クラスの上位側の線をまたぐように引いた破線に付加して示す。

        discriminatorName: powertypeName,

この構文では,ベキ型を明示的に定義しなくても,線上のベキ型名が暗黙にベキ型を定義する。

5.36.3

  対応付け

注記  (対応国際規格では,5.36.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.37

クラスパス名

5.37.1

  記法

クラス記号(長方形)はクラス,及び他のクラスに対する関係のような特性を定義するために用いる。

異なるパッケージ内のクラスへの参照は,次の形式で,クラスのパス名を用いて表す。

        package-name :: class-name

クラスに対する参照は,テキスト表現の中,特に属性及び変数に対する型仕様の中にも表れる。このよ

うなところでは,クラスへの参照はその構文規則に従って,単にクラス自身への名前を含めたり,パッケ

ージ名を含めて示す。

5.37.2

  例

注記  (対応国際規格では,5.37.2 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.37.3

  対応付け

注記  (対応国際規格では,5.37.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.38

パッケージのアクセス又は移入

5.38.1

  意味論

要素は,異なるパッケージに含まれる要素を参照することができる。パッケージレベルでは,«access»

依存は,対象パッケージの内容が,クライアントパッケージ又はその中に再帰的に組み込まれたパッケー

ジから参照されてもよいことを示す。対象は,参照する側から見て十分な可視性をもたなければならない。


118

X 4170

:2009 (ISO/IEC 19501:2005)

   

すなわち,無関係なパッケージに対する公開可視性,対象パッケージの子孫に対する公開可視性若しくは

保護可視性,又は対象パッケージの内部に入れ子になったパッケージに対する任意の可視性をもつ(後者

の場合,アクセス依存は必要ない。

。このパッケージの内部で入れ子になっているパッケージがアクセス

する場合,包含パッケージと同じアクセスができる。

アクセス依存は,クライアントの名前空間を変更せず,参照の自動作成もせず,あくまでも参照の確立

を許可するだけである。また,参照の作成時に,ツールが必要に応じてユーザのためにアクセス依存を自

動的に作成することもできる。

移入依存は,アクセスを保証し,対象名前空間において適切な可視性をもつ名前を,アクセスするパッ

ケージにロードする(すなわち,参照にパス名が必要なくなる。

。しかし,そのような名前は自動的に再

移出しないので,名前を明示的に再移出されなければならない(そして新たな名前及び可視性を同時に与

えることが可能でなければならない。

5.38.2

  記法

アクセス依存は,参照側(クライアント)パッケージから対象側(供給者)パッケージへの依存矢線で

表示される。この矢線には

«access»

が付加される。この依存は,クライアントパッケージ内の要素が供

給者内の要素を合法的に参照できることを示す。参照は,供給者が指定した可視性制約を満たさなければ

ならない。依存が自動的に参照を作成しない。依存は,参照の確立を許可するだけである。

移入依存は,«import»

をもつことを除いて,アクセス依存と同じ記法を用いる。

5.38.3

  例

注記  (対応国際規格では,5.38.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.38.4

  対応付け

注記  (対応国際規格では,5.38.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.39

オブジェクト

5.39.1

  意味論

オブジェクトは,クラスの特定のインスタンスを表現する。オブジェクトは,識別性及び属性値をもつ。

役割はインスタンスに似た特徴をもっているので,同様な記法はコラボレーション内の役割を表現する。

5.39.2

  記法

オブジェクトの記法は,5.12 で示したように,クラス記法から派生し,インスタンスレベルの要素には

下線を付ける。

オブジェクトは,二つの区画をもつ長方形で表す。

上の区画では,オブジェクト名及びそのクラスにすべて下線を付け,次の構文で示す。

        objectname : classname

classname

には,必要に応じてパッケージを含めたフルパス名を含めてよい。パッケージ名はクラス

名の後におき,二重コロンで区切る。次に例を示す。

        表示  ウィンドウ:ウィンドウシステム::図形ウィンドウ:ウィンドウ


119

X 4170

:2009 (ISO/IEC 19501:2005)

クラスのステレオタイプは,

(名前の文字列の上にあるギュメに)テキスト,又は右上隅のアイコンとし

て示すことができる。オブジェクトのステレオタイプは,そのクラスのステレオタイプと一致しなければ

ならない。

一つのオブジェクトが複数クラスのインタンスである場合,コンマで区切られたクラス名並びを使う。

クラス名は,適正な多重クラス分類に適合していなければならない。すなわち,唯一の実装クラスが許さ

れるが,型は複数個を許す。

クラスの特定の状態にオブジェクトが存在することを示すには,次の構文を使用する。

        objectname : classname ‘[’ statename-list ‘]’

並びは,並行発生することのできる,コンマ区切りの状態名の並びでなければならない。

下の区画では,オブジェクトの属性及びその値を並びとして示す。各行は,次の構文をもつ。

        attributename : type = value

type

は,クラスの属性宣言と重複するので,省略してもよい。

value

はリテラル値として指定する。UML ではリテラル値の式に対する構文を規定しない。ツールが

プログラム言語を使って構文を指定することを期待している。

同一のオブジェクトの異なる時点における二つの値の間のフロー関係は,«become»

の付いた破線矢線

によって二つのオブジェクト記号を結合して示す。コラボレーション図でこのフロー矢線を使う場合,ラ

ベルにシーケンス番号を含め,いつその値が変化するかを示すことも可能とする。同様に,«copy»

を用い

て,別のオブジェクト値から新たにオブジェクトを生成することを示してもよい。

5.39.3

  表示上の選択肢

注記  (対応国際規格では,5.39.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.39.4

  スタイルガイド

注記  (対応国際規格では,5.39.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.39.5

  変種

注記  (対応国際規格では,5.39.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.39.6

  例

注記  (対応国際規格では,5.39.6 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.39.7

  対応付け

注記  (対応国際規格では,5.39.7 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.40

合成オブジェクト

5.40.1

  意味論

合成オブジェクトは,密に結合した高レベルのオブジェクトを表現する。このオブジェクトは合成クラ


120

X 4170

:2009 (ISO/IEC 19501:2005)

   

スのインスタンスであり,その合成クラスはその部分要素との間に合成集約関連が存在する。合成オブジ

ェクトは,コラボレーション図に似ているが(コラボレーション図よって単純で限定され)

,静的モデル内

の合成集約によって完全に定義される(5.48 を参照)

5.40.2

  記法

合成オブジェクトはオブジェクト記号として示される。合成オブジェクトの名前文字列は,長方形の上

部近くにある区画に(任意のオブジェクトとともに)置かれる。下の区画は,属性値の並びの代わりに,

合成オブジェクトの部分要素を保持する(ただし,属性値の並びも合成オブジェクトの部分要素とみなす

ことができるので,大きな違いはない。

。入れ子を繰り返すことによって,合成オブジェクトの部分要素

の幾つかを更に合成オブジェクトにすることも可能とする。

5.40.3

  例

注記  (対応国際規格では,5.40.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.40.4

  対応付け

注記  (対応国際規格では,5.40.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.41

関連

二項関連は,二つの分類子記号を接続する線として示す。この線は,その特性を示すために様々な修飾

をもつことができる。三項以上の関連は,クラス記号を線で接続したダイヤモンドで示す。

5.42

二項関連

5.42.1

  意味論

二項関連は,厳密に二つの分類子間の関連とする(分類子からその分類子自身への再帰関連の可能性も

ある。

5.42.2

  記法

二項関連は,二つの分類子記号を接続する実線経路として描く(両端は同じ分類子に接続してもよいが,

二つの端点は区別する必要がある。

。経路は一つ以上の断片で構成してもよい。個々の断片に意味上の重

要性はないが,ツールが関連記号の移動又はサイズ変更において図的な意味をもたせてもよい。断片の接

続列を経路と呼ぶ。

二項関連で両端は,同じ分類子に付加できる。そのような関連のリンクは同種の分類子の二つの異なる

インスタンス,又はそれ自身に結合することができる。後者は,必要ならば制約で禁止できる。

分類子に接続される関連の端点は関連端と呼ばれる。関連についての意味的に重要な情報のほとんどは

関連端に付加される。

経路には,主要部分に図的な装飾を施すことができる。装飾は,関連全体の特性を示す。これらは線分

に沿って,又は複数の線分を横断して移動してもよいが,経路には接続したままでなければならない。混

乱が起きないように,関連装飾を関連端にどれだけ近づけてよいかを決めるのはツールの責任とする。次

の種類の装飾が経路に接続できる。

5.42.2.1

  関連名

関連の名前(選択可能)を指定する。

経路の近く(役割名と混同するほど端点に近くではなく)に文字列で名前を示す。名前の文字列はその

中に,選択可能な小さな黒く塗りつぶされた三角形をもつことができる。三角形はどの方向に名前を読む

かを指定する。ただし,この名前の方向性の矢は,意味論的に重要性はもたず,純粋に記述的なものでな


121

X 4170

:2009 (ISO/IEC 19501:2005)

ければならない。関連に参加する分類子は,名前矢の方向に従って順序付けられる。

注記  関連モデルの名前方向特性は,必要ではない。関連内の分類子の順序付けが名前の方向となる。

この取り決めは,N 項関連にも適用する。

ギュメ内のステレオタイプキーワードを,関連名の前又は上に置くことができる。特性文字列を,関連

名の後ろ又は下に置くことができる。

5.42.2.2

  関連クラスシンボル

例えば,属性,操作,他の関連などクラスに類似した特性をもつ関連を指定する。これは,その関連が

関連クラスであり,かつ,その場合に限り表示される。関連経路に破線で接続したクラス記号として示す。

関連経路及び関連クラス記号は,単一名をもつ同一の基底モデル要素を表現する。この名前は,経路上,

クラス記号の中,又はその両方(ただし,同じ名前でなければならない。

)に配置できる。

論理的には,関連クラスと関連とは同一の意味実体であるが,図的には別とする。関連クラス記号は線

分から移動して引き離すことができるが,経路とクラス記号とは破線でつながった状態を維持しなければ

ならない。

5.42.3

  表示上の選択肢

注記  (対応国際規格では,5.42.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.42.4

  スタイルガイド

注記  (対応国際規格では,5.42.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.42.5

  選択肢

注記  (対応国際規格では,5.42.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.42.6

  例

注記  (対応国際規格では,5.42.6 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.42.7

  対応付け

注記  (対応国際規格では,5.42.7 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.43

関連端

5.43.1

  意味論

関連端は,分類子に接続する関連の端点とする。これは関連の一部であり,分類子の一部ではない。関

連は,二つ以上の端点をもつ。関連で重要な詳細のほとんどはその端点に付随する。関連端は,独立分離

できない。関連に機械的に付随する一部にすぎない。

5.43.2

  記法

経路は,それが分類子記号と接続する端点に図的な装飾をもつことができる。それらの装飾は,その分

類子に対する関連の特性を示す。装飾は関連記号の一部であり,分類子記号の一部ではない。端点装飾は

線の端点か又は線の端点付近のいずれかに付加されているが,一緒に移動しなければならない。次の種類

の装飾が関連端に付加できる。

5.43.2.1

  多重度

テキスト構文で指定する。多重度は,特定の関連又は図全体に対して表示を抑制してもよい。不完全な


122

X 4170

:2009 (ISO/IEC 19501:2005)

   

モデルの場合には,モデル自体に多重度を指定しないこともできる。その場合表記中では,多重度が抑止

されなければならない(5.44 を参照)

5.43.2.2

  順序付け

多重度が 1 よりも大きい場合は,関連要素集合に順序があってもなくてもよい。指定がない場合は,順

序付けなしになる(集合を構成する。

。多様な順序付けが,関連端の制約として指定できる。順序付けを

どう実現又は保持するかは指定しない。新しい要素を挿入する操作は,位置を暗示的(例えば端点)又は

明示的に指定できなければならない。可能な値としては,次がある。

−  順序付けなし:要素は順序なしの集合を構成する。これは既定値であり明示する必要はない。

−  順序付けあり:集合の要素は順序をもつが,重複は禁止する。このはん(汎)用仕様は,すべての種

類の順序付けを含む。これはキーワード構文

{ordered}

で指定できる。

順序付け関係は多様な方法で実装できるが,通常は,特定の実装を選択する言語固有のコード生成特性

で規定する。実装の拡張によって,はん(汎)用仕様“ordered”要素を保持するため,データ構造を置

き換えなければならない場合もある。

実装レベルでは,整列を指定することもできる。新しい意味情報を付加しないが,次のように設計判断

を表す。

−  整列済み:要素はその内部値に基づいて整列される。実際の整列規則は,別の制約として適切に指定

される。

5.43.2.3

  限定子

限定子は,選択的であるが,表示は抑制できない(5.45 を参照)

5.43.2.4

  誘導可能性

経路端点に矢じりを付加し,矢じりの指す分類子への誘導可能性を示すことができる。矢じりは経路の

ゼロ,一つ,又は二つの端点に付加できる。完全に明示的に表現したいのであれば,矢じりは与えられた

方向の誘導可能性をすべて示すことができる。実際には,矢じりの幾つかを抑制して例外的な状況を示す

のが便利である。

5.43.2.5

  集約指示子

集約を指示するために経路端点に白抜きダイヤモンドを付加する。ダイヤモンドは両端に付加してはな

らないが,なくてもよい。ダイヤモンドは集約するクラスに付加する。集約は選択的であるが,抑止でき

るものではない。

黒塗りダイヤモンドは,合成集約として知られているより強い集約形式を意味する(5.48 参照)

5.43.2.6

  役割名

経路端点の近くにある名前文字列。役割名近くの経路端点に接続したクラスが演じる役割を指示する。

役割名は選択的であるが,抑止できるものではない。

5.43.2.7

  インタフェース指定子

次の構文で Classifier 名を指定する。

        ‘:’ classifiername, . . .

関係しているインスタンスによる関連オブジェクトの期待される振る舞いを示す。言い換えれば,イン

タフェース指定子は,関連を有効にするために必要な振る舞いを指定する。この場合,通常,実際の分類

子は,特定の関連に必要とされるよりも多くの機能を提供する(他の責務をもつ場合があるため)


123

X 4170

:2009 (ISO/IEC 19501:2005)

役割名及びインタフェース指定子を使用することは,関連及び二つの役割だけを含む小さなコラボレー

ションを生成することと等価とする。構造は,関連役割名と接続された分類子で定義される。したがって,

元の関連及び分類子は,コラボレーションの使用になる。元の分類子は,インタフェース指定子(分類子

として,インタフェース又は型になる)と互換性がなければならない。

インタフェース指定子を省略した場合,関連するクラスのすべてのアクセスを取得するためには,関連

を使うことができる。

5.43.2.8

  変更可能性

リンクが変更可能(追加,削除,又は移動が可能)な場合,指示子は必要はない。特性

{frozen}

は,

オブジェクトを生成及び初期設定したあとで,オブジェクトに対してリンクの追加,削除又はオブジェク

トから(装飾の付いた端点の方向へ)のリンクの移動ができないことを示す。特性

{addOnly}

は,リン

クを新たに追加できる(多くの場合,多重度も可変)が,リンクを修正又は削除ができないことを示す。

5.43.2.9

  可視性

役割名の前にある可視性指示子(“+”

,“  #”

,“  –”

,明示キーワード

{public}

など)によって指定

する。これは,与えられた役割名の方向に関連をたどるときの可視性を指定する。

その他の特性を関連端に対して指定できるが,図的構文は存在しない。特性を指定するためには,関連

経路の端点付近にある制約構文(波括弧“ {}”のテキスト文字列)を使用する。例としては可変性がある。

5.43.3

  表示上の選択肢

注記  (対応国際規格では,5.43.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.43.4

  スタイルガイド

注記  (対応国際規格では,5.43.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.43.5

  例

注記  (対応国際規格では,5.43.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.43.6

  対応付け

注記  (対応国際規格では,5.43.6 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.44

多重度

5.44.1

  意味論

多重度は,ある集合が取り得る基数の許容範囲を指定する。多重度指定は,関連内の役割,合成集約内

の部分,繰返し,及び他の目的に対して与えることができる。本質的に,多重度指定は非負整数の開集合

の部分集合とする。

5.44.2

  記法

多重度指定はコンマで区切られた整数区間の系列からなる文字列として示す。ここで,区間は(多分無

限の)整数範囲を次の形式で表現する。

        lower-bound .. upper-bound

ここで,lower-bound 及び upper-bound はリテラルの整数値とし,下限から上限の閉じた(境界を


124

X 4170

:2009 (ISO/IEC 19501:2005)

   

含む)整数範囲を指定する。さらに,星文字“*”を上限に使うことができ,その場合は無制限の上限を示

す。

(テンプレートのような)パラメタ化された文脈では上限及び下限は式でもよいが,実際の利用時はい

つも,評価された結果はリテラルの整数値にしなければならない。評価結果がリテラルの整数値にならな

い未束縛の式は許されない。

一つの整数値が指定される場合,整数範囲は単一の整数値を含む。

多重度指定が単一の星文字“*”からなる場合,無制限の非負整数を示す,すなわち,0..*(ゼロ以上)

と等価とする。

0..0

の多重度は,インスタンスが現れないことを示すので無意味とする。

ある仕様言語の式を多重度に使うことができるが,そのモデルの中で固定整数範囲に決定されなければ

ならない。すなわち,式の動的評価は行われない。これは本質的に,多くのプログラム言語のリテラル値

に対するのと同じ規則とする。

5.44.3

  スタイルガイド

注記  (対応国際規格では,5.44.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.44.4

  例

注記  (対応国際規格では,5.44.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.44.5

  対応付け

注記  (対応国際規格では,5.44.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.45

限定子

5.45.1

  意味論

限定子は,属性又は属性の並びとする。その値は,関連の先のインスタンスに関連するインスタンス集

合を区分するのに役立つ。

5.45.2

  記法

限定子は,最終の経路断片とその経路断片が接続する分類子記号との間の関連経路端に付加される,小

さな長方形として示す。限定子長方形は関連経路の一部であり,分類子の一部ではない。限定子長方形は

経路断片につなぐ。限定子は関連の起点端に付加される。起点分類子のインスタンスは限定子の値ととも

に,関連の他端の終点分類子のインスタンス集合から一つの区分を一意に選択する,すなわち,どの終点

も厳密に一つの区分とする。

終点端に付加される多重度は,起点インスタンスと限定子の値との対によって選択される,終点インス

タンスの可能な候補を示す。共通の値は,次を含む。

−  “0..1”

:一意の値を選択することができるが,すべての可能な限定子の値が必ずしも一つの値を選択

するとは限らない。

−  “1”

:すべての可能な限定子の値が一意の終点インスタンスを選択する。したがって,限定子の値の

定義域は有限でなければならない。

−  “*”

:限定子の値は,終点の複数のインスタンスを部分集合に区分する指標である。

限定子属性は,限定子長方形の中に描かれる。一つ以上の属性をそれぞれ 1 行に示すことができる。初

期値式に意味がないことを除いて,限定子属性は分類子属性と同じ記法をもつ。

一つの関連の両端に限定子をもつことは(幾分まれだが)

,許される。


125

X 4170

:2009 (ISO/IEC 19501:2005)

5.45.3

  表示上の選択肢

注記  (対応国際規格では,5.45.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.45.4

  スタイルガイド

注記  (対応国際規格では,5.45.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.45.5

  例

注記  (対応国際規格では,5.45.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.45.6

  対応付け

注記  (対応国際規格では,5.45.6 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.46

関連クラス

5.46.1

  意味論

関連クラスは,クラス特性(又は関連特性をもつクラス)をもつ関連とする。関連及びクラスとして描

かれるが,実際は単一のモデル要素である。

5.46.2

  記法

関連クラスは,関連経路に破線が付与されたクラス記号(長方形)として示す。クラス記号の中の名前

及び関連経路に付加された名前文字列は,冗長であるが同じとすることが望ましい。関連経路は,いずれ

の端点にも通常の修飾をもつことができる。クラス記号は,通常の内容をもつことができる。破線上には,

修飾はない。

5.46.3

  表示上の選択肢

注記  (対応国際規格では,5.46.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.46.4

  スタイルガイド

注記  (対応国際規格では,5.46.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.46.5

  例

注記  (対応国際規格では,5.46.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.46.6

  対応付け

注記  (対応国際規格では,5.46.6 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.47  N

項関連

5.47.1

  意味論

N

項関連は,三つ以上の分類子(単一の分類子が一度以上現れてもよい。

)の間の関連とする。関連のそ

れぞれのインスタンスは,それぞれの分類子の n 組の値とする。二項関連は,それ自身の記法をもつ特殊

な場合とする。

N

項関連の多重度を指定できるが,二項の多重度よりも自明ではない。一つの役割に指定される多重度

は,他の N-1 の値が固定されたときの,その関連におけるインスタンスの組が取れる数を表現する。


126

X 4170

:2009 (ISO/IEC 19501:2005)

   

N

項関連は,どの役割にも集約マーカを含んではならない。

5.47.2

  記法

N

項関連は,それぞれの関係するクラスに引かれた経路付きの大きなダイヤモンド(すなわち,経路の

端点の記号よりも大きい)として示す。関連名(ある場合)は,ダイヤモンドの近くに示す。役割修飾は

二項関連の場合と同様に,それぞれの経路上に表すことができる。多重度を示すことはできるが,限定子

及び集約は許されない。

関連クラス記号を破線でダイヤモンドに付加することができる。これは,属性,操作,及び/又は関連

をもつ N 項関連を示す。

5.47.3

  スタイルガイド

注記  (対応国際規格では,5.47.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.47.4

  例

注記  (対応国際規格では,5.47.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.47.5

  対応付け

注記  (対応国際規格では,5.47.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.48

合成集約

5.48.1

  意味論

合成集約は,集約の強い形式とする。一つの部分インスタンスは,同時には一つの合成体に含まれなけ

ればならず,かつ,合成オブジェクトは,その複数の部分の取扱いの総責任をもたなければならない。集

約端の多重度は,1 を超えてはならない(非共有とする。

(詳細は,5.43 を参照)

合成集約における合成体は,その識別性を関係内の各部分に“射影”する。言い換えると,オブジェク

トモデルにおけるそれぞれの部分オブジェクトは,一意の合成オブジェクトによって識別できる。合成オ

ブジェクトは,自分自身の識別性をその一次識別性として保持する。要点は,それが一意の合成体の部分

としてもまた識別できる点である。合成集約は推移的である。オブジェクト A がオブジェクト B の部分で

あり,このオブジェクト B がオブジェクト C の部分である場合,オブジェクト A はオブジェクト C の部

分でもある。このように,それぞれの異なる詳細度において,一つの部分は幾つかの合成オブジェクトに

よって識別できる。

合成集約の部分は,クラス及び関連(必要ならば,AssociationClass 群の形式に形成することもで

きる。

)を含むことができる。合成オブジェクトにおける関連の意味は,単一のリンクで接続されたオブジ

ェクトの組が,すべて同じコンテナオブジェクトに属さなければならない。言い換えれば,合成オブジェ

クトはその識別性を,合成集約の部分端に対応するそれぞれのリンクに射影する。関連及びその関連に関

係する二つのクラスがすべて,合成体としての同じクラスに対し,部分として関係する場合,その関連の

インスタンスであるリンクは,合成クラスのインスタンスであるオブジェクトによって識別され,かつ,

リンクで接続されたオブジェクトもまた,合成オブジェクトによって識別される。すなわち,これらのリ

ンク及びオブジェクトはすべて,同じ合成オブジェクトと関連しなければならない。

5.48.2

  記法

合成集約は,関連端修飾として黒塗りのダイヤモンドで示すことができる。代わりの記法として,UML

は,多くの場合に合成集約を示すのに,より便宜的な,図的に入れ子にした形式を提供する。


127

X 4170

:2009 (ISO/IEC 19501:2005)

合成集約の修飾を使った二項関連の経路を使う代わりに,合成は,全体側要素記号の内部の部分側要素

記号の図的な入れ子で示すこともできる。この入れ子クラスのような要素は,その合成要素の内部で多重

度をもつこともできる。多重度は,部分記号の右上隅に示す。多重度記号が省略されている場合,省略時

の多重度は多とする。これは,合成分類子の中での部分としての,その多重度を表現する。入れ子要素は,

合成集約の中で役割名をもつこともできる。名前は,型の前に次の構文で示す。

        rolename ‘:’ classname

これは合成体への合成集約関連における役割名を表現する。

代わりの記法として,合成集約は全体側の要素に付加された関連経路の端点上の黒塗りダイヤモンド修

飾で示す。多重度は通常の方法で示すことができる。

属性は,実際のところ,分類子とその属性の分類子との間の合成関係である。

完全に合成体の境界内部に描かれた関連は,合成集約の部分と考える。その関連の単一リンク上の複数

のインスタンスは,同じ合成体の部分でなければならない。経路が合成体の境界をはみ出して描かれる関

連は,合成集約の部分とは考えない。その関連の単一リンク上の複数のインスタンスは,同じ合成体の部

分でも,又は異なった合成体の部分でもあり得る。

合成集約の記法は,コラボレーションの記法と似ている。合成は,そこに参加するもののすべてが単一

の合成オブジェクトの部分となるようなコラボレーションと考えることもできる。

入れ子記法は,別クラスの内部で宣言されるクラスを示す正しい方法ではない。そのように宣言される

クラスは,内包するクラスの構造的な部分ではなく,パッケージが内部クラスに対して作用するのと同じ

ように,単に内包するクラスの名前空間の有効範囲をもつ。このような名前空間の包含は,クラス記号の

右上隅にパッケージ記号を置くことによって示すことができる。ツールは利用者がパッケージ記号をクリ

ックして,その中で宣言された要素集合を開くようにできる。

“いかり(錨)記法”

(線分の端に円の中の

十字)を二つのクラス長方形の間の線分上で使い,いかり(錨)アイコン付きのクラスが線分の他端のク

ラスを宣言することを示すこともできる。

5.48.3

  設計指針

注記  (対応国際規格では,5.48.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.48.4

  例

注記  (対応国際規格では,5.48.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.48.5

  対応付け

注記  (対応国際規格では,5.48.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.49

リンク

5.49.1

  意味論

リンクは,オブジェクト参照の組(の並び)とする。ほとんどの場合は,リンクはオブジェクト参照の

対とする。リンクは,関連のインスタンスとする。

5.49.2

  記法

二項リンクは,二つのインスタンス間の経路として示す。インスタンスから自分自身までのリンクの場


128

X 4170

:2009 (ISO/IEC 19501:2005)

   

合,インスタンスはループを含むことができる(経路の詳細は,5.41 を参照)

役割名は,リンクの両端に示すことができる。関連名は,経路の近くに示すことができる。存在する場

合,インスタンスを示すために下線を引く。リンクはインスタンス名をもたず,自分が関係するインスタ

ンスから自分の識別性を得る。リンクはインスタンスなので多重度は示さない。他の関連修飾(集約,合

成集約,及び誘導)は,リンク端に示すことができる。

限定子は,リンク上に示すこともできる。限定子の値は,その長方形の中に示すことができる。

5.49.2.1

  実装ステレオタイプ

ステレオタイプをリンク端に付加して,実装の様々な種類を示すことができる。次のステレオタイプを

使うことができる。

«association»

関連(省略時,強調する場合を除いて指定不要)

«parameter»

メソッドのパラメタ

«local»

メソッドの局所変数

«global»

大域変数

«self»

自己リンク(自身にメッセージを送信するインスタンス)

5.49.2.2

  項リンク

N

項リンクは,それぞれ参加するインスタンスへの経路付きのダイヤモンドとして示す。それ以外の関

連の修飾及び関連端の修飾は,二項リンクと同じものを使うことができる。

5.49.3

  例

注記  (対応国際規格では,5.49.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.49.4

  対応付け

注記  (対応国際規格では,5.49.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.50

はん(汎)化

5.50.1

  意味論

はん(汎)化は,より一般的な要素(上位)とより特定的な要素(下位)との間の分類関係とする。こ

の,より特定的な要素とは,より一般的な要素と完全に一貫性をもち,かつ,追加情報を加えた要素であ

る。はん(汎)化は,クラス,パッケージ,ユースケース,及び他の要素に使われる。

5.50.2

  記法

はん(汎)化は,下位(下位クラスのような,より特定的な要素)から上位(上位クラスのような,よ

り一般的な要素)への,より一般的な要素側の経路端に大きな白抜き三角形が付いた実線の経路として示

す。

はん(汎)化経路は,上位の複数の下位の区分名である区別子と呼ばれるテキストラベルをもつことが

できる。下位は,与えられた区分に含まれるように宣言される。区別子ラベルがなければ“空文字列”区

別子を示す。これは,有効な値(

“省略時”の区別子)とする。

はん(汎)化は,クラスと同様に関連に適用することもできる。関連の間のはん(汎)化を示すには,

はん(汎)化の矢線を下位関連経路から上位関連経路に描く。この記法は,線分が別の線分に接続される

ので,紛らわしいかもしれない。代わりの記法は,それぞれの関連を関連クラスとして表現し,かつ,他


129

X 4170

:2009 (ISO/IEC 19501:2005)

の分類子と同じように関連クラスの長方形の間にはん(汎)化の矢線を描く方法とする。縮退した関連ク

ラスは正当な関連なので,このアプローチは,例え関連が追加的な属性をもたない場合でも使うことがで

きる。

特定の図に示されない,モデルにおける追加的な下位の存在は,下位の場所に省略記号“…”を使って

示すことができる。

注記  これは,追加的な下位が将来追加されるかもしれないということを示さない。これは追加的な

下位がたった今存在するが,見えていないということである。これは,そのような情報が伏せ

られていることを示す記法上の便宜とし,意味論の提示とはしない。

下位の間の意味論的な制約を示すために,既定義の制約を使うこともできる。コンマで区切ったキーワ

ードの並びを大括弧で囲み,共有された三角形の近く(幾つかの経路が単一の三角形を共有する場合)

,又

は関係するすべてのはん(汎)化の線分を横切る点線の近くに置く。次のキーワードを(とりわけ)使う

ことができる(次の制約は,既定義とする。

overlapping

(二つ以上の下位の)祖先である集合の中に,

(この)二つ以上の下位のどちらに

も含まれる要素が存在できる。インスタンスは,二つ以上の下位の直接又は間接の
インスタンスにすることができる。

disjoint

(二つの下位の)祖先である集合の中に,

(この)二つの下位の両方に含まれる要

素が存在してはならない。どのインスタンスも,二つの下位の直接又は間接のイン
スタンスにしてはならない。

complete

(示されているか否かにかかわらず)すべての下位が規定されている。下位の追加
はできない。

incomplete

幾つかの下位が規定されているが,並びが不完全であることが知られている。まだ
モデルにない追加的な下位がある。これはモデル自身について述べている。これは,
省略記号と同じではない。省略記号は,モデルには追加的な下位があるが,現在の
図に示していないことを述べている。

区別子は,上位の属性及び関連役割の間で一意でなければならない。同じ区別子名が複数現れてもよく,

これは下位が同じ区分に所属することを示す。

多重分類又は動的分類の使用は言語の動的実行意味論に影響するが,静的モデルからは通常明白ではな

い。

5.50.3

  表示上の選択肢

注記  (対応国際規格では,5.50.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.50.4

  対応付け

注記  (対応国際規格では,5.50.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.51

依存

5.51.1

  意味論

依存は,二つのモデル要素(又は,二つのモデル要素集合)の間の意味論的な関係を示す。依存はその

モデル要素自体に関係し,かつ,その意味の解釈にはインスタンス集合を必要としない。これは,依存の

終点要素の変更が起点要素の変更を必要とすることがある状況を示す。


130

X 4170

:2009 (ISO/IEC 19501:2005)

   

5.51.2

  記法

依存は,二つのモデル要素間の破線矢線で示す。矢線末尾側のモデル要素(クライアント)は,矢じり

側のモデル要素(供給者)に依存する。矢線には,ステレオタイプ及び固有名でラベル付けすることを選

択することができる。

要素集合をクライアント又は供給者にすることもできる。この場合,クライアント側が末尾となる一つ

以上の矢線が,供給者側が矢じりとなる一つ以上の矢線の末尾に接続される。望む場合,小さな点を連結

に置くことができる。依存へのノートは,連結点に付加されることが望ましい。

次の種類の Dependency は既定義とし,キーワード付きで示すことができる。これらの幾つかは実際の

メタモデルクラスに対応し,それ以外はメタモデルクラスのステレオタイプに対応する。これらはすべて

ギュメ内のキーワード付きの破線矢線として示す。名前の欄には,メタモデルクラス名又は与えられたキ

ーワードステレオタイプ付きの非公式クラス名を示す。

キーワード

名前

説明

access Access あるパッケージに対して,他のパッケージに所有される公開要素の参照を

(適切な可視性のもとで)許可する。«access»

付きの Permission に対

応付ける。

bind Binding

テンプレートパラメタを実際の値に束縛して,非パラメタ化要素を生成す
る(詳細は,5.31 を参照)

。Binding に対応付ける。

derive Derivation

ある要素と別の要素との間の計算可能な関係(それぞれの要素への依存に
加えて,もう一つの依存。

。«derivation»

付きの Abstraction に対応

付ける。

import Import あるパッケージに対して,他のパッケージに所有される公開要素の参照を

許可するとともに,クライアントパッケージに対して,供給者パッケージ
の公開要素の名前を追加する。«import»

付きの Permission に対応付け

る。

refine Refinement

両者間で対応付け(完全でなくてもよい)をもつ二つの要素間の履歴上又
は派生的な接続。対応付けの説明のノートを依存に付加することができる。
様々な種類の洗練が提案されており,それ以上に詳細なステレオタイプを
付けてそのことを示してもよい。«refinement»

付きの Abstraction に

対応付ける。

trace Trace 異なる意味レベルの同じ概念を表現する二つの要素間の履歴上の接続。

«trace»

付きの Abstraction に対応付ける。

use Usage

ある要素が正しく実装又は機能するために,別の要素の存在を必要とする
状況。それ以上に詳細なステレオタイプを付けて,別クラスの操作の呼出
し,アクセス許可の承認,別クラスのオブジェクトのインスタンス化など
の依存の厳密な性質を示すこともできる。Usage に対応付ける。キーワー
ドが Usage の(«call»,«create»,«instantiate»,«send»)の一つ
の場合,与えられたステレオタイプ付きの Usage に対応付けられる。

5.51.3

  表示上の選択肢

注記  (対応国際規格では,5.51.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.51.4

  例

注記  (対応国際規格では,5.51.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。


131

X 4170

:2009 (ISO/IEC 19501:2005)

5.51.5

  対応付け

注記  (対応国際規格では,5.51.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.52

派生要素

5.52.1

  意味論

派生要素は,別の要素から計算できる要素とする。意味論的な情報を追加しないが,明確化するため,

又は設計目的で含める。

5.52.2

  記法

派生要素は,属性又は役割名のような派生要素名の前に斜線“/”を置くことで示す。

5.52.3

  スタイルガイド

注記  (対応国際規格では,5.52.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.53

インスタンス接続

5.53.1

  意味論

インスタンスとその分類子との間の接続を示す。

5.53.2

  記法

インスタンスが末尾となり,分類子が頭となる破線矢線で示す。矢線には,«instanceOf»を付ける。

5.53.3

  対応付け

注記  (対応国際規格では,5.53.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

第 区分  ユースケース図(用例図)

ユースケース図は,システム又は意味論的実体内部のユースケースとそのアクタとの間の関係を示す。

5.54

ユースケース図

5.54.1

  意味論

ユースケース図は,アクタ及びユースケースをその関係とともに示す図とする。ユースケースは,サブ

システム又はクラスと同様に,システム又は分類子の外部の相互作用者に明示するために,システム又は

分類子の機能を表現する。

5.54.2

  記法

ユースケース図は,アクタ,ユースケース集合,インタフェース(なくてもよい)

,及びこれらの要素間

の関係のグラフとする。関係には,次のものがある。1)  アクタとユースケースとの間の関連,2)  アクタ

間のはん(汎)化,3)  ユースケース間のはん(汎)化,拡張,及び包含。ユースケースは,それを含むシ

ステム又は分類子の境界を表現する長方形で囲むことも選択可能である。

5.54.3

  例

注記  (対応国際規格では,5.54.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.54.4

  対応付け

注記  (対応国際規格では,5.54.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。


132

X 4170

:2009 (ISO/IEC 19501:2005)

   

5.55

ユースケース

5.55.1

  意味論

ユースケースは,システム,サブシステム,又はクラスが提供する一貫した機能単位を表現する分類子

の一種とする。これは,システム(サブシステム,クラス)が実行する動作とともに,システム(サブシ

ステム,クラス)と一つ以上の外部の相互作用者(アクタと呼ばれる。

)との間で交換されるメッセージ系

列として明示される。

拡張点は,他のユースケースの動作系列を挿入できる,ユースケースのある位置への参照とする。それ

ぞれの拡張点は,ユースケース内での一意の名前,及びそのユースケースの振る舞い内での位置記述をも

つ。

5.55.2

  記法

ユースケースは,ユースケース名を含むだ(楕)円として示す。名前及び名前の下に含まれる特性の並

びの上に,ステレオタイプキーワードを置くことも選択可能である。分類子として,ユースケースは属性

及び操作を表示する区画をもつこともできる。

拡張点は,ユースケースの区画に extension points の見出し付きで載せることができる。拡張点の

位置記述は,通常のテキストのような適切な形式で与えられるが,状態機械の状態名,又は事前条件若し

くは事後条件のような他の形式も可能とする。

ユースケースの振る舞いは,便宜に応じて幾つかの異なる方法で記述できる。単なるテキストがよく使

われるが,状態機械,並びに操作及びメソッドは,ユースケースの振る舞いを記述する別方法の例とする。

ユースケースとそのアクタとの間の相互作用の記述にはシーケンス図を使うことができる。

5.55.3

  表示上の選択肢

注記  (対応国際規格では,5.55.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.55.4

  スタイルガイド

注記  (対応国際規格では,5.55.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.55.5

  対応付け

注記  (対応国際規格では,5.55.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.56

アクタ

5.56.1

  意味論

アクタは,実体と相互作用するとき,その実体の利用者が演じる役割の一貫した集合とする。アクタは,

自分が交信するそれぞれのユースケースに関して,役割を演じると考えることができる。

5.56.2

  記法

アクタの標準ステレオタイプアイコンは,下にアクタ名が付いた“人型”図形とする。

5.56.3

  表示上の選択肢

注記  (対応国際規格では,5.56.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.56.4

  スタイルガイド

注記  (対応国際規格では,5.56.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。


133

X 4170

:2009 (ISO/IEC 19501:2005)

5.56.5

  対応付け

注記  (対応国際規格では,5.56.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.57

ユースケース関係

5.57.1

  意味論

ユースケース間又はアクタとユースケースとの間は,次の標準関係とする。

−  関連:アクタがユースケースに参加する,すなわち,アクタのインスタンスとユースケースのインス

タンスとが互いに交信する。これはアクタとユースケースとの間の唯一の関係とする。

−  拡張:ユースケース A からユースケース B への拡張関係は,ユースケース A で指定された振る舞い

によってユースケース B のインスタンスが(拡張で指定された特定条件下で)拡大することができる

ことを示す。拡張関係で参照される B 内の拡張点で定義された位置に,振る舞いが挿入される。

−  はん(汎)化:ユースケース C からユースケース D へのはん(汎)化は,C が D の特化とすること

を示す。

−  包含:ユースケース E からユースケース F への包含関係は,ユースケース E のインスタンスが F によ

って指定された振る舞いを含むことを示す。その振る舞いは,E で定義された位置に包含される。

5.57.2

  記法

アクタとユースケースとの間の関連は,アクタとユースケースとの間の実線で示す。この実線は多重度

のような端修飾をもつことができる。

ユースケース間の拡張関係は,拡張を提供するユースケースから基底ユースケースへの開矢じり破線矢

線で示す。矢線は

«extend»

でラベル付けされる。関係の条件は,キーワードの近くに表すことも選択可

能とする。

ユースケース間の包含関係は,基底ユースケースから包含されるユースケースへの開矢じり破線矢線で

示す。矢線は«include»でラベル付けされる。

ユースケース間のはん(汎)化は,はん(汎)化矢線,すなわち,上位ユースケースに向けて引く白抜

き閉矢じり実線矢線で示す。

ユースケースとその外部相互作用系列との間の関係は,通常はシーケンス図への不可視ハイパーリンク

で 定 義 さ れ る 。 ユ ー ス ケ ー ス と そ の 実 現 と の 間 の 関 係 は , コ ラ ボ レ ー シ ョ ン に 向 か う ,

«representedClassifier»

付きの破線矢線で示すことができるが,不可視ハイパーリンクとして定義

することもできる。

5.57.3

  例

注記  (対応国際規格では,5.57.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.57.4

  対応付け

注記  (対応国際規格では,5.57.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.58

アクタ関係

5.58.1

  意味論

アクタ間及びアクタとユースケースとの間は,次の標準関係とする。

−  関連:ユースケースへのアクタの参加,すなわち,アクタのインスタンスとユースケースのインスタ

ンスとが互いに交信するということ。これは,アクタとユースケースとの間の唯一の関係とする。


134

X 4170

:2009 (ISO/IEC 19501:2005)

   

−  はん(汎)化:アクタ A からアクタ B へのはん(汎)化は,A のインスタンスは,B のインスタンス

が交信するのと同じ種類のユースケースと交信できるということを示す。

5.58.2

  記法

アクタとユースケースとの間の関連は,アクタとユースケースとの間の実線として示す。

アクタ間のはん(汎)化は,はん(汎)化矢線,すなわち,白抜き閉矢じり実線矢線で示す。矢じりは,

より一般的なアクタに向けて引く。

5.58.3

  例

注記  (対応国際規格では,5.58.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.58.4

  対応付け

注記  (対応国際規格では,5.58.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

第 区分  相互作用図

振る舞いの記述は,次の二つの側面を含む。1)  参加者の構造的な記述,及び 2)  交信パターンの記述。

振る舞いの中で役割を演じる Instance 群,及びそれらの間の関係がもつ構造を,Collaboration と呼

ぶ。特定の目的を達成するために役割を演じる Instance 群が実行する交信パターンを,Interaction

と呼ぶ。振る舞いの二つの側面は,多くの場合一つの図に一緒に記述されるが,構造的な側面を分離して

記述することが有用なときもある。

相互作用図は,同じ基礎とする情報に基づいて,Collaboration 及びもしかすると Interaction に

よって規定される二つの形式で現れるが,それぞれの形式は特定の側面を強調する。二つの形式は,シー

ケンス図及びコラボレーション図とする。シーケンス図は,明示的な交信系列を示し,実時間の仕様及び

複雑なシナリオに向いている。コラボレーション図は,Interaction の中の複数の役割及びその役割間

の関係を中心に据えた Interaction を示す。コラボレーション図は別の次元として時間を示さないので,

交信系列及び複数の並行スレッドはシーケンス番号を使って決定しなければならない。

5.59

コラボレーション(協調)

5.59.1

  意味論

あるタスクを達成するため,相互作用全体にわたって Stimulus 群を交換する Instance の集合によ

って,振る舞いが実装される。設計で使われるメカニズムを理解するためには,より大きなシステムから

射影されたそのシステムの一部である目的又は関連する目的集合の達成に絡む,Instance 群及びそれら

の協同動作だけを見ることが重要である。このような静的構成要素は,コラボレーションと呼ばれる。

Collaboration

は , 与 え ら れ た 目 的 集 合 に 必 要 な 参 加 者 を 定 義 す る ClassifierRole 及 び

AssociationRole

の集合を含む。ClassifierRole に適合する Instance は ClassifierRole によ

って定義された役割を演じるし,他方,Instance 間の Link は,Collaboration の AssociationRole

に適合する。ClassifierRole 及び AssociationRole は Instance 及び Link の使い方を定義し,

Classifier

及び Association は,その Instance 及び Link のすべての必要な特性を宣言する。

Interaction

は,Collaboration の文脈で定義される。Interaction は,Collaboration にお

ける役割間の交信パターンを指定する。より厳密には,Interaction は半順序の Message 集合を含み,

その Message のそれぞれは一つの交信を指定している。例えば,どのような Signal が送信されるか又

はどのような Operation が起動されるか,並びに,そのそれぞれに対応する,送信側及び受信側が演じ


135

X 4170

:2009 (ISO/IEC 19501:2005)

る役割が,指定される。

CollaborationInstanceSet

は , そ の Collaboration が 指 定 す る タ ス ク を 一 緒 に 実 行 す る

Instance

の集合である。これらの Instance は,Collaboration の ClassifierRole が定義する役

割を演じる,すなわち,Instance は ClassifierRole が定義するすべての特性をもっている(これを,

Instance

は ClassifierRole に適合する,という。

。そのタスクを実行するときに Instance 間で送

信される Stimulus 群は,CollaborationInstanceSet の InteractionInstanceSet に参加して

いる。Collaboration 内の Interaction 群の一つにおいて,これらの Stimulus は Message に適合

する。一つの Instance は同時に複数の CollaborationInstanceSet に参加できるので,その

Instance

のすべての交信が,必ずしも唯一の InteractionInstanceSet だけから参照されていると

は限らない。これらは,インターリーブすることができる。

Collaboration

は UseCase と同様に,Operation 又は Classifier に対して付加して,振る舞い

の文脈,すなわち,Operation 又は UseCase が指定する振る舞いを実行するために Instance 群が演

じる役割を,記述することができる。Collaboration は,Operation 又は Classifier の実現を記述

す る た め に 使わ れ る 。 Classifier を 記 述す る Collaboration は UseCase と 同 様 に , 一 般 に

Classifier

群及び Association 群を参照する。他方,Operation を記述する Collaboration は,

Operation

の引数及び局所変数,並びにその Operation を所有する Classifier に付加された通常の

Association

群を含む。一つの Collaboration の内部で定義された Interaction 群は,Operation

又は UseCase が指定する振る舞いを実行するときの Instance 間の交信パターンを指定する。これらの

パターンは,シーケンス図又はコラボレーション図で表現する。Collaboration は Class に付加して,

Class

の静的構造,すなわち,属性,パラメタ,その他が互いに協同動作する方法を定義することもでき

る。

パラメタ化 Collaboration は,異なる設計で繰り返し使うことができる設計の構造を表現する。

Classifier

群 及 び Relationship 群 を 含 む Collaboration の 参 加 者 は , は ん ( 汎 ) 用

Collaboration

のパラメタにすることができる。はん(汎)用 Collaboration のインスタンス化では,

パラメタは特定の ModelElement に束縛される。そのようなパラメタ化 Collaboration は,設計パタ

ーンの構造(設計パターンは構造的側面以上を含む。

)を把握することができる。大部分の Collaboration

は名前付けされた ModelElement に付加されているので匿名にできるが,Collaboration パターンは,

名前を持たなければならない独立した設計の構成要素とする。

Collaboration

は異なるレベルの粒度で表現できる。粗い粒度の Collaboration を詳細化して,よ

り細かい粒度の別の Collaboration を生成することもできる。

5.60

シーケンス図(系列図)

5.60.1

  意味論

シーケンス図は,必要な操作又は結果を得るための Interaction 又は InteractionInstanceSet

を表す。Interaction は,Collaboration 内部の ClassifierRole 間の Message 集合とする。

InteractionInstanceSet

は,CollaborationInstanceSet 内部の Instance 間の Stimulus 集

合とする。

5.60.2

  記法

シーケンス図は,次の二つの次元をもつ。1)  垂直次元は時間を表現する,及び 2)  水平次元は異なる複

数のインスタンスを表現する。通常,時間はページの下に進む(必要ならば,次元は逆にすることもでき

る。

。通常は時系列だけが重要だが,実時間アプリケーションでは時間軸は実計量単位としてもよい。イ


136

X 4170

:2009 (ISO/IEC 19501:2005)

   

ンスタンスの水平方向の順序付けは意味がない。

シーケンス図で使われる異なる種類の矢線は,5.63 に記述する。これらはコラボレーション図における

ものと同じとする(5.65 を参照)

この記法の多くは,Buschmann,Meunier,Rohnert,Sommerlad 及び Stal のオブジェクトメッセージシー

ケンスチャート記法からの直接引用であり,オブジェクトメッセージシーケンスチャート記法自体は,メ

ッセージシーケンスチャート記法に修正がなされて派生した。

5.60.3

  表示上の選択肢

注記  (対応国際規格では,5.60.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.60.4

  例

注記  (対応国際規格では,5.60.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.60.5

  対応付け

注記  (対応国際規格では,5.60.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.61

オブジェクト生存線

5.61.1

  意味論

シーケンス図では,オブジェクト生存線は特定の役割を演じる Instance を表す。生存線の間の矢線は,

その役割を演じる Instance 間の交信を表す。シーケンス図の中には,役割における Instance の存在

及び期間を示すが,Instance 間の関係は示さない。役割は ClassifierRole によって規定される。

ClassifierRole

は,役割を演じる Instance の特性,及びその役割の Instance がもつ他の Instance

への関係を記述する。

5.61.2

  記法

Instance

は,

“生存線”と呼ばれる垂直の破線で示す。生存線は,特定の時間における Instance の

存在を表現する。図に示される期間に Instance が生成又は解体される場合,その生存線は適切な点で開

始又は停止する。そうでない場合は,それは図の上端から下端まで伸びる。オブジェクト記号は,生存線

の頭に描く。Instance が図中で生成される場合,Instance を生成する Stimulus に対応する矢線を,

矢じりがオブジェクト記号に接するように描く。図中で Instance の解体を表現する場合,解体を引き起

こす Stimulus に対応する矢線,又は(自己解体の場合は)解体される Instance からの返却矢線に大

きな“X”でマークする。トランザクションの開始時に存在する Instance は,図の上端(最初の矢線の

上)に示す。他方,トランザクション終了時に存在するインスタンスは,最後の矢線よりも下に続く生存

線をもつ。

生存線は,条件分岐を示すために二つ以上の並行生存線に分離できる。それぞれの分離軌跡は,交信に

おける条件分岐に対応する。生存線は後続点で一緒に合流できる。

5.61.3

  表示上の選択肢

注記  (対応国際規格では,5.61.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.61.4

  例

注記  (対応国際規格では,5.61.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。


137

X 4170

:2009 (ISO/IEC 19501:2005)

5.61.5

  対応付け

注記  (対応国際規格では,5.61.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.62

活性区間

5.62.1

  意味論

活性区間(制御の焦点)は,Instance が直接に,又は下位手続によって Action を実行する期間を示

す。これは Action の実行継続期間,及び活性区間と呼出し元との間の制御関係(スタックフレーム)の

両方を表現する。

5.62.2

  記法

活性区間は,上端を開始時に,かつ,下端を完了時に合わせた細長い長方形として示す。実行される

Action

は,スタイルに応じて,活性区間記号の隣,又は左余白にテキストでラベル付けすることができ

る。代わりの記法として,入力矢線で Action を示すこともできるが,この場合,活性区間自体の上の

Action

は省略することができる。手続的な制御フローでは,活性区間記号の上端は入力矢線(動作を開

始するもの)の先端にあり,この記号の下端は返却矢線の末尾である。

それぞれが自分自身の制御スレッドをもつ並行 Instance 群の場合,活性区間は,それぞれの Instance

が Operation を実行する期間又は状態機械の遷移を示す。他の Instance 群による Operation 群は無

関係である。直接的な計算処理と(入れ子の手続による)間接的な計算処理との間の区別が重要でない場

合,生存線全体を活性区間として示すことができる。

手続的なコードの場合,活性区間は Instance で手続が活性な期間,又は多分他の Instance 群の下

位手続が活性な期間を示す。言い換えると,与えられた時点ではすべての活性な入れ子の手続の活性区間

を表すことができる。活性区間が存在する Instance への再起呼出しの場合は,視覚的に“積み重さね”

に見えるように,二番目の活性区間記号は,最初のものの少し右側に描く(再起呼出しは,任意の深さま

で入れ子にできる。

5.62.3

  例

注記  (対応国際規格では,5.62.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.62.4

  対応付け

注記  (対応国際規格では,5.62.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.63

メッセージ及び刺激

5.63.1

  意味論

刺激は,動作が期待される,情報を伝達する二つのインスタンス間の交信とする。Stimulus は

Operation

の起動,Signal の発生,又は Instance の生成若しくは解体を引き起こす。

メッセージは Stimulus の規定とする,すなわち,Message は,送信側及び受信側の Instance が適

合しなければならない役割を指定するとともに,実行時にはその Message に適合する Stimulus をディ

スパッチする Action を指定する。

5.63.2

  記法

シーケンス図では,Stimulus と Message とは,ある Instance 又は ClassifierRole の生存線か

ら,別の Instance 又は ClassifierRole の生存線への水平方向の実線矢線として示す。Instance か

ら 自分自身への Stimulus の場合,矢線は同じ生存線で開始及び終了する。矢線は,起動される


138

X 4170

:2009 (ISO/IEC 19501:2005)

   

Operation

名又は Signal 名でラベル付けされる。その引数値又は引数式も表すことができる。

矢線はシーケンス番号でラベル付けして,相互作用全体の Stimulus(Message)の系列を示すことが

できる。しかし,シーケンス図では矢線の物理位置が相対的な系列を示すので,シーケンス番号が省略さ

れることが多い。コラボレーション図では必要となる。いずれの図においても,並行制御スレッドの識別

のためにシーケンス番号は有用である。また,矢線は,条件及び/又は反復表現でラベル付けすることも

できる。

5.63.3

  表示上の選択肢

注記  (対応国際規格では,5.63.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.63.4

  例

注記  (対応国際規格では,5.63.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.63.5

  対応付け

注記  (対応国際規格では,5.63.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.64

遷移時間

5.64.1

  意味論

Message

は,例えば,送信時及び受信時のような異なる時間を指定することもできる。これらは

Constraint

式の中で使うことができる形式名とする。異なる種類の時間の集合は既定のものに対して追

加可能とする。利用者は特別な状況には必要に応じて,経過時間及び実行開始時刻のような新しいものを

発明できる。これらの式は,Message に対して有効な特定の時間制約を指定するために制約の中で使うこ

とができる。

5.64.2

  記法

遷移インスタンス(シーケンス図及びコラボレーション図における Stimulus,Message,又は状態機

械における Transition)には,名前を与えることができる。時間制約は遷移名に基づく式として作られ

る 。 例 え ば , Stimulus 名 が stim の 場 合 , そ の 送 信 時 は stim.sendTime () , 及 び 受 信 時 は

stim.receiveTime

()

で表現する。時間制約は,

(シーケンス図では)矢線と一直線との先の左余白に,

又は(コラボレーション図では)矢線の末尾近くに示すこともできる。Constraint 群は,大括弧で囲ん

だ論理式(時間式を含むことも可能)をシーケンス図上に置くことで指定できる。

5.64.3

  表示上の選択肢

注記  (対応国際規格では,5.64.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.64.4

  例

注記  (対応国際規格では,5.64.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.64.5

  対応付け

注記  (対応国際規格では,5.64.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。


139

X 4170

:2009 (ISO/IEC 19501:2005)

第 区分  コラボレーション図(協調図)

5.65

コラボレーション図

5.65.1

  意味論

コ ラ ボ レ ー シ ョ ン 図 は , Instance 群 が 演 じ る 役 割 及 び 特 定 の 文 脈 で 必 要 な 関 係 を 与 え る

Collaboration

又は Instance 群とそれらの間の関係の集まりである CollaborationInstanceSet

を表す。また,コラボレーション図は Interaction(InteractionInstanceSet)を表すことができ,

この Interaction(InteractionInstanceSet)は,望む結果を達成するための Collaboration 内

で役割を演じる Instance 群間の相互作用を指定する Message 群(Stimulus 群)の集合を定義する。

Collaboration

は,Operation 又は Classifier の実現を記述するために使用する。Classifier

を記述している Collaboration は,UseCase と同様に,一般的に Classifier 及び Association を

参照する。一方,Operation を記述している Collaboration は,Operation の引数及び局所変数を

含み,更に,その Operation を所有している Classifier に接続している通常の Association も含む。

5.65.2

  記法

コ ラ ボ レ ー シ ョ ン 図 は , 互 い に 連 結 し た Instance 群 , 又 は ClassifierRole 群 及 び

AssociationRole

群のグラフを表す。Interaction 又は InteractionInstanceSet によって明示

された交信を含むことができる。

コラボレーション図は,しばしば設計作業の支援に用いるので,Link 群又は AssociationRole 群を

表現する線の矢じりで誘導可能性を示す(長方形間の線上の矢じりは,一方向の誘導可能性の Link 又は

AssociationRole

を示す。線に隣接する矢印は,その方向への Stimulus 群又は Message の流れを表

す。明らかに,そのような矢印を一方向の線に逆向きを指すように付けることはできない。

相互作用の順序は,通常 1 から始まる数字列で表す。制御の手続的な流れに対しては,呼出しの入れ子

に従って交信番号を付与する。並行インスタンス間の非手続的な相互作用に対しては,すべての順序番号

は同一レベルになる(すなわち,入れ子にならない。

相互作用のないコラボレーション図は,その相互作用を行う文脈を表す。単一の Operation 又は一つ

の Class 若しくは Class 群の全 Operation 群に対する文脈を表すことができる。

実行中に Instance 又は Link が,生成又は解体されることを示すために次の標準の制約を用いること

ができる。

−  実行の間に生成される Instance 群及び Link 群は,{new}

と指定することができる。

−  実行の間に解体される Instance 群及び Link 群は,{destroyed}

と指定することができる。

−  実行の間に生成され,その後解体される Instance 群及び Link 群は,{transient}

と指定するこ

とができる。

生存状態におけるこれらの変化は Instance 群間の詳細な相互作用から導出可能であり,これらは記法

上の便宜を図る。

5.65.2.1

  コラボレーション  インスタンス

インスタンスレベルで表されているコラボレーション図は,CollaborationInstanceSet を表す。

すなわち,オブジェクト長方形及び線の集まりは,それぞれ Instance 群及び Link 群に対応する。これ

らのインスタンスは,CollaborationInstanceSet の Collaboration の ClassifierRole 群及び

AssociationRole

群に適合する。この図は,Link 上を交信する Stimulus 群に対応する線上の矢印を

含むことができる。この図は Operation 又は Classifier の実現に関係している Instance 群を表し,

その実行によって間接的に影響を受けたりアクセスされる Instance 群を含む。その図は Instance 群


140

X 4170

:2009 (ISO/IEC 19501:2005)

   

間の Link 群を表し,手続引数を表す一時的なもの,局所変数,自己リンクなどを表現する。個々の属性

値は,通常,明示しない。Stimulus 群を属性値に送信する場合,Attribute 群は代わりに Association

群を使ってモデル化することが望ましい。

5.65.2.2

  コラボレーション

仕様レベルでのコラボレーション図は,コラボレーションを表す。すなわち,Collaboration で定義

した役割を表す。同時に,これらの役割は,Collaboration の Operation 又は Classifier の実現を

示す。その図は,その Collaboration における ClassifierRole 群及び AssociationRole 群に対

応するクラス長方形及び線の集まりを含む。この場合,その線に付加している矢印は Message 群に対応

する。

5.65.3

  例

注記  (対応国際規格では,5.65.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.65.4

  対応付け

注記  (対応国際規格では,5.65.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.66

パターン構造

5.66.1

  意味論

Collaboration

は,設計構成要素の実装を指定するために用いる。この目的のため,その文脈及び相

互作用を指定する必要がある。さらに,Collaboration を単一の実体として“外側”から見ることがで

きる。例えば,これは,システム設計におけるデザインパターンの存在の識別に用いることができる。

Pattern

は,パラメタ化された Collaboration となる。すなわち,Collaboration テンプレートと

なる。そのパターンの各々の利用においては,実際の Classifier でパターン定義で使っているパラメタ

を置換する。

Gamma

,Helm,Johnson 及び Vlissides のデザインパターンで定義しているパターンは,構造に関する記

述ばかりでない。UML はデザインパターンの構造の側面及び振る舞いの側面を記述する。しかし,UML

記法は,使用上のトレードオフ,例題などのパターンの他の重要な側面を含まない。これらは他の手段,

例えば,文書又は表で表さなければならない。

Collaboration

は,下位と呼ばれる他の Collaboraiton を使って定義することができる。その場合,

上位と呼ばれる Collaboration における各々の役割は上位 Collaboration で定義された新しい役割

又は複数の下位 Collaboration で定義し,上位 Collaboration の定義で再利用する役割となる。後

者の場合,その役割はその上位 Collaboration の目的に合うように名前を振り直す。その場合,その役

割の元の名前は上位 Collaboration で用いられている名前の後ろに中括弧を使って表す

図 95 を参照)。

5.66.2

  記法

Collaboraiton

の利用は破線のだ(楕)円として表し,その Collaboration の名前を中に表す。破

線の直線は,コラボレーションの記号からその Collaboration に登場する Classifier の各々の記号

へ引く。各直線には,参加者の役割のラベルを付ける。役割名は,その Collaboration の文脈における

要素名に対応する。Collaboration におけるこの名前は,モデル内でのパターンの各出現の要素を規定

する束縛パラメタとして扱われる。したがって,コラボレーション記号はパターン使用で現れる実

Classifier

群及び Association 群を伴ったデザインパターンの利用を示すことができる。


141

X 4170

:2009 (ISO/IEC 19501:2005)

図 95Collaboration の利用

Collaboration

は GeneralizableElement なので,他の Collaboration と Generalization

関係をもってもよい。このようにして,ある Collaboration を別の Collaboration の特化として定

義することができる。これは通常の Generalization 矢線で表し,下位 Collaboration を表現する破

線のだ(楕)円から上位 Collaboration のアイコンへ引く。この下位 Collaboration の役割は,上

位 Collaboration の役割の特化としてもよい。これは,下位コラボレーションにおいて上位コラボレー

ションの役割名を再定義することによって表す。

図 96Collaboration の特化。

監視コラボレーションの Subject 役割は,Observer コラボレーションで定義

された Subject 役割の特化(拡張)なので,Subject 役割の基底側の呼出し

待ち行列クラスの代わりに,管理対象待ち行列クラスが用いられる。

開矢じりをもつ破線の矢線は,Collaboration が Operation 又は Classifier の実現であることを

表す。この関係は,Collaboration 記号内にテキスト形式で構成することもできる。


142

X 4170

:2009 (ISO/IEC 19501:2005)

   

図 97Collaboration とそれが実現する要素との間の関係は,Collaboration から

実現される要素への,開矢じり破線矢線又はテキストで示される。

通常の取り決めを用いて,CollaboratioInstanceSet を表す。すなわち,下線のついた名前の付い

た破線のだ(楕)円として表す。CollaborationInstanceSet に参加する Instance 群及び Link 群

は,破線の直線でだ(楕)円に結び付ける。インスタンスが果たす役割名は,その直線及びインスタンス

の近くに示す。

ある場合には,コラボレーションアイコン[破線のだ(楕)円で表される。

]内に Collaboration の

静的構造を表すと便利である。

図 98−コラボレーションアイコン内に示された Collaboration の静的構造

一つの Collaboration を他の Collaboration を使って表すには,二つの方法がある。すなわち,

Collaboration

群とそれらの間との関係を表す破線のだ(楕)円で表す方法又は通常のコラボレーショ

ン図を用いる方法である。前者の方法は,その Collaboration 群の関係を明示的に表すという利点があ

る。一方,後者は新たに定義する Collaboration の構造を表す。


143

X 4170

:2009 (ISO/IEC 19501:2005)

図 99−コンポーネントフレームワーク Collaboration は,プロキシ Collaboration 

二つの実現及びコンテナ Collaboration の二つの実現を使う。コンポーネント

フレームワークの二つの役割は,使われる Collaboration 群の二つずつの役割に

対応する。

5.66.3

  対応付け

注記  (対応国際規格では,5.66.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.67

コラボレーション内容

Collaboration

の内容は,Instance 群及び Link 群が(Operation 又は UseCase の実行のような)

特定の目的のために与えられた文脈における協調方法を規定する役割の集まりとする。Collaboration

は,特定目的のための完全なモデルの断片とする。

5.67.1

  意味論

コラボレーション図は,Collaboration 又は CollaborationInstanceSet を表す。前者の場合,

コラボレーション図は一つ以上の役割を表し,その内容,関係,隣接する Collaboration の役割に加え,

必要に応じて付加的な関係及び Class 群を含む。コラボレーション図が CollaborationInstanceSet

を表すときには,Collaboration で定義している役割を果たす CollaborationInstanceSet に参加

するインスタンスを示す。Collaboration を用いるために,各々の役割は実 Classifier(又は多重分

類を用いている場合は,Classifier の集まり)に束縛していなければならず,その役割によって必要と

される Feature 群を提供する。付加的な要素は,役割間の Generalization 群のような役割でモデル

化できない付加的要件を表現する。


144

X 4170

:2009 (ISO/IEC 19501:2005)

   

5.67.2

  記法

コラボレーション図は,クラスの長方形又はオブジェクトの長方形,及びそれに接続した線のグラフと

して表す。これらのアイコンは,ClassifierRole 群及び AssociationRole 群,又は Instance 群及

び Link 群に,それぞれ対応する(5.69 を参照)

しかし,コラボレーション図は,他の要素,例えば他の Classifier 群,Generalization 群,

Constraint

群などを含めてもよく,これによってその他の補助的要素を示す。これらの要素は,通常の

各アイコンで表す。

図 100Collaboration の制約要素として Constraint を伴う

Collaboration

を示すコラボレーション図。

図 101−制約要素として付加的 Generalization を伴う

異なる役割を示すコラボレーション図


145

X 4170

:2009 (ISO/IEC 19501:2005)

5.67.3

  対応付け

注記  (対応国際規格では,5.67.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.68

相互作用

Instance

群のコラボレーションは,Stimulus 群を交換することによって(Operation を実行する

ような)ある目的を達成するために相互作用をする。これらは Signal 群の送信及び Operation 群の呼

出しばかりでなく,条件及び時間イベントによる暗黙の相互作用も含んでよい。このように特定の目的を

達成するために,交信をする特定のパターンを Interaction とする。Collaboration のタスクを行う

とき,CollaborationInstanceSet に参加する Instance 群間に送信する Stimulus 群の集まりを

InteractionInstanceSet

と呼ぶ。

5.68.1

  意味論

Interaction

は振る舞い仕様であり,Collaboration 内の Instance 群集合間で交換される交信系

列を構成し Operation 実装のような特定の目的を達成する。Interaction を規定するために,第一に

Collaboration

を規定する必要がある。すなわち,相互作用の役割及びそれらの関係を確立することで

ある。次に,可能な相互作用系列を規定する。これらは条件(分岐又は条件シグナル)を含む単一記述か,

又は可能な実行経路を経由する特定の経路をそれぞれ記述した複数記述によって規定する。

一つの交信は,Message を用いて規定する。すなわち,送信側及び受信側の役割を規定するのと併せて

行われる交信を引き起こす Action を規定する。Action は,どのような種類の交信が行われるかを規定

する。例えば,Signal 送信又は Operation 呼出のようなもので設定される引数を決定する式系列を伴

う。

Action

を実行するとき,Message に適合するように Stimulus 群をディスパッチする。Stimulus

は,Message の送受信側の役割を演じる送受信 Instance 群の参照と併せて,ディスパッチする Action

の引数式を評価した結果である Instance 群の参照系列を含む。InteractionInstanceSet は,

Interaction

の Message に適合する Stimulus 群の集まりとなる。すなわち,Collaboration が定

義するタスクを実行するとき,Stimulus 群を CollaborationInstanceSet に参加する Instance 群

間に送信する。

5.68.2

  記法

Interaction

は,シーケンス図又はコラボレーション図として表す。両方の図は,コラボレーション

の実行を表す。しかし,シーケンス図は Instance 群又は Instance 群の Attribute の値間の関係は示

さない。したがって,シーケンス図は完全には Collaboration の文脈の側面を表さない。シーケンス図

は Collaboration の振る舞いの側面を明示的に表し,そのとき Stimulus 群の時系列及びメソッド起

動の明示的な表現を含む。シーケンス図は,第 7 区分で示す。コラボレーション図は相互作用の完全な文

脈を表し,特定の相互作用に関連する Instance 群及びそれらの間の関係を含んでいる。Stimulus 群の

順序は,シーケンス番号で表す。なぜなら,シーケンス図のように時間軸に従って配置することはこの種

の図では不可能であるからである(実際には,ある場合に時間軸と一緒にシーケンス番号を使うと便利に

なる。

。コラボレーション図の内容は,5.69 で示す。

5.68.3

  対応付け

注記  (対応国際規格では,5.68.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。


146

X 4170

:2009 (ISO/IEC 19501:2005)

   

5.68.4

  例

注記  (対応国際規格では,5.68.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.69

コラボレーション役割

5.69.1

  意味論

分類子役割は,Collaboration における Instance の演じる役割を指定する。その役割は,必要とな

る Operation 群及び Attribute 群のような役割を演じる Instance の種類及び他の役割を演じる

Instance

群との関係を規定する。他の役割との関係は AssociationRole 群で定義する。これらの関

係は,Instance 群間で必要とされる Link 群を記述する。すなわち,存在している Link 群の部分集合

となる。

5.69.2

  記法

ClassifierRole

は,クラスの長方形記号で表す。通常名前区画だけを表すが,必要に応じて属性及

び操作区画を示してもよい。名前区画は文字列を含む。

        ‘/’ ClassifierRoleName ‘:’ ClassifierName  [‘,’ ClassifierName]*

Classifier

(又は多重分類を用いている場合は Classifier 群)の名前は,必要ならば Package か

らなるフルパス名を含むことができる。ツールで実現する場合,通常,あいまいにならなければ短縮パス

名を許す。Package 名は Classifier 名の前に置かれ,二重コロンで区切る。例えば,

表示_ウィンドウ:ウィンドウシステム::図形ウィンドウ:ウィンドウ

ステレオタイプは(名前文字列の上のギュメ内に)テキストで示してもよいし,又は右上隅にアイコン

として示してもよい。Instance 群の集合を表現する ClassiferRole は,クラスの長方形の右上隅に多

重度(例えば“*”

)を含むことができる。

AssociationRole

は , 通 常 の 関 連 を 表 す 線 分 と と も に 示 す 。 AssociationRole 名 は ,

ClassifierRole

と同様な構文に従う。AssociationRole 名が省略された場合,ClassifierRole

記号に接続している線分が AssociationRole を示す。AssociationRole 端に付いている情報(すな

わち,AssociationEndRole 群)は,AssociationEnd 群と同じ記法で表す。

ClassifierRole

によって定義される役割を演じる Instance は,オブジェクトの長方形で表される。

通常,属性区画はない。Instance 名は,文字列で指定する。

        ObjectName  ‘ / ’  ClassifierRoleName ‘ : ’  ClassifierName  [ ‘ , ’

ClassifierName]*

したがって,Instance 名が先頭にきて ClassifierRole の完全名をその後ろに続け,すべてに下線

を引く。属性区画を表した場合,その役割を演じる Instance によって必要とされる Attribute の名前

を示す。ある Attribute が値をもつことが必要となる場合,オブジェクト図と同じ方法で表す。すなわ

ち,名前の後ろに等号とその値とを書く。

Link

は,オブジェクトの長方形間の線分として表す。その名前の文字列は,役割を演じる Object の


147

X 4170

:2009 (ISO/IEC 19501:2005)

構文に従う。

5.69.3

  表示上の選択肢

注記  (対応国際規格では,5.69.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.69.4

  例

注記  (対応国際規格では,5.69.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.69.5

  対応付け

注記  (対応国際規格では,5.69.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.70

多重オブジェクト

5.70.1

  意味論

多重オブジェクトは,Association の“多”側の Instance 群の集合を表現する。これは,全体の集

合に対する Operation 群及び Signal 群を表すのであり,単一 Instance にではない。基となる静的モ

デルは,このグループ化によって影響を受けない。これは,関連した Instance 群へのアクセスに使用す

る多重度“多”の付いた Association に対応する。

5.70.2

  記法

多重オブジェクトは二つの長方形を垂直,水平方向にわずかにずらし表す。これは,長方形が積み重ね

らていることを意味している。多重オブジェクト記号へのメッセージの矢線は,Instance 群集合への

Stimulus

であることを示す(例えば,個々のオブジェクトを検索するための選択 Operation を示す。

多重化されている Instance の集合において個々の Instance への各 Operation を実行するために,

次の二つの Stimulus 群が必要となる。1)  個々の Instance 群への Link 群を取り出すための多重オブ

ジェクトに対する反復,及び 2)(一時的な)Link を使って各 Instance へ送信する Stimulus。図の上

では,反復及び適用を単一の矢線にまとめて簡略化してもよい。対象の役割名は,複数 Link を示すため

に“多”指示子(*)を用いる。単一の Stimulus として記述しても本来のモデル(及び実際のプログラ

ム)では,前述の二層構造(Link 群を検索する反復及び各 Link を使った交信)が必要である。

集合上の一つの Instance は,通常のオブジェクト記号で表すが,集合の一部であることを示すために

合成 Link を用いる多重オブジェクト記号を付けてもよい。単一オブジェクト記号への交信矢線は,各

Instance

への Stimulus を示す。

一般的には多重オブジェクトへの選択 Stimulus が個々の Instance への参照を返し,送信元がこれ

に Stimulus を送信する。

5.70.3

  例

注記  (対応国際規格では,5.70.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.70.4

  対応付け

注記  (対応国際規格では,5.70.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.71

能動オブジェクト

能動オブジェクトは,制御スレッドを所有し制御活動を開始するオブジェクトとする。受動オブジェク

トは,データは保持するが制御は開始しないオブジェクトとする。ただし,受動オブジェクトは受信した


148

X 4170

:2009 (ISO/IEC 19501:2005)

   

要求を処理する過程で Stimulus 群を送信してもよい。コラボレーション図では,能動クラスの

ClassifierRole

が実行中に出現する能動オブジェクトを表す。

5.71.1

  意味論

能動オブジェクトは,制御スレッドを所有する Instance である。プロセス及びタスクは,伝統的な能

動オブジェクトである。

5.71.2

  記法

能動オブジェクトに対する役割は,太い境界線をもつ長方形で示される。しばしば,能動オブジェクト

の役割は,組込み部分をもつ合成体として表される。

特性キーワード

{active}

を能動オブジェクトを示すために用いてもよい。

5.71.3

  例

注記  (対応国際規格では,5.71.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.71.4

  対応付け

注記  (対応国際規格では,5.71.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.72

メッセージ及び刺激

5.72.1

  意味論

コラボレーション図では刺激は二つの Instance 群間での交信であり,動作がそれに引き続いて起こる

情報を伝達するものとなる。Stimulus は,Operation の呼出し,Signal の発生,又は Instance の

生成若しくは解体を起こす。

メッセージは Stimulus の規定とする。すなわち,送信及び受信 Instance 群の適合すべき役割及び

実行時に Message に適合する Stimulus をディスパッチする Action を規定する。

5.72.2

  記法

Message

及び Stimulus は,それぞれ AssociationRole 及び Link の近くに,ラベル付きの矢線で

表す。意味は,Link を対象 Instance への Stimulus 搬送に用いることとなる。矢線は直線に沿って表

し,受信 Instance に向かう。

5.72.2.1

  制御フロー型

次に各種の矢じりの型を示す。これらは,交信種別を表すために用いる。

      閉矢じり実線矢線

手続呼出し,又は入れ子になった制御フローを表す。入れ子になった順序系列の全体は,自分より外側

の系列が再開する前に,完了する。この矢じりは,通常の手続呼出しを表すのに用いてもよい。しかし,

インスタンスが相手に Signal を送り,継続する前に入れ子になった振る舞い系列の完了を待つ並行能動

オブジェクトに用いてもよい。

      開矢じり実線矢線

非同期交信,すなわち,入れ子になっていない制御の流れを表す。送信者は刺激をディスパッチし,即

座に次のステップを再開する。


149

X 4170

:2009 (ISO/IEC 19501:2005)

      開矢じり破線矢線

手続呼出しからの返却を表す。活性化終端では,返却矢線は暗黙なので省略してよい。

その他の種類

その他の種類の制御,例えば,

“妨害”又は“タイムアウト”のような文字列で表してもよい。しかし,

これらは,UML コアの拡張として扱う。

半開き矢じり実線矢線は,非同期交信を表すために用いてもよい。この代替案は,後方互換のために含

める。UML 1.3 及びそれ以前の版では,半開き矢じり実線矢線及び開矢じり実線矢線があったが大差はな

い(その上,よく理解されていない。

5.72.2.2

  矢線のラベル

次では,用語 Message を用いるが,Stimulus でもよい。

ラベルは,次の構文をもつ。

        predecessor sequence-expression return-value := message-name

          argument-list

ラベルは,相互作用内の送信する Message,その引数,返却値及び Message の順序を表し,呼出しの

入れ子,反復,分岐,並行,同期なども一緒に表す。

5.72.2.3

  先行子

先行子は,コンマで区切りの入ったシーケンス番号の並びに続けてその後ろに斜線(

‘/’

)を書く。

        sequence-number ‘,’ . . . ‘/’

この並びがない場合には,省略する。

各 sequence-number は,反復項をもたないシーケンス式とする。他の Message のシーケンス番号と

一致しなければならない。

意味は,並び内に現れるシーケンス番号をもつ交信がすべて発生するまで Message が可能とならない

ということである。したがって,先行子の並びはスレッドの同期を表現する。

数値的に先行するシーケンス番号に対応する Message は暗黙の先行子であり,明示的に並べる必要は

ない。同一の前置詞(レベル)をもつすべてのシーケンス番号は,一つの列をなす。数値的な先行子とは,

最後の項が 1 小さいシーケンス番号である。すなわち,数値 3.1.4.5 は,3.1.4.6 の先行子である。

5.72.2.4

  シーケンス式

シーケンス式は,ドットで区切られたシーケンス項の並びの後ろにコロン(

‘:’

)を書く。

        sequence-term ‘.’ . . . ‘:’

各項は,相互作用全体での手続的な入れ子の順位を表す。すべての制御が並行な場合,入れ子にはなら

ない。各 sequence-term は,次の構文をもつ。


150

X 4170

:2009 (ISO/IEC 19501:2005)

   

        [ integer | name ] [ recurrence ]

integer

は,手続呼出しのある順位における Message の逐次順序を表現する。整数項が一つ異なる

Message

は,その入れ子の順位で,逐次的な順序となる。例えば,活性化 3.1 内で,3.1.4 は 3.1.3 の次と

なる。name は,並行制御スレッドを表現する。最後の“name”が異なる Message は,その順位におい

て並行となる。例えば,活性化 3.1 内で 3.1a は 3.1b と並行となる。すべてのスレッドは,その入れ子の順

位で同等となる。

recurrence

は条件実行又は反復実行を表現する。これは条件に依存して実行されるゼロ個以上の

Message

を表現する。これは,次のいずれかとなる。

        ‘*’ ‘[’ iteration-clause ‘]’an iteration

        ‘[’ condition-clause ‘]’a branch

iteration

は,与えられた入れ子の深さでの Message 列を表現する。iteration-clause は省略し

てもよい(反復条件は指定しない。

。iteration-clause は擬似コード又は実際のプログラム言語で表

されるが,UML では形式を規定しない。例えば,*[i := 1..n]。

condition

は , condition-clause の 真 偽 値 に そ の 実 行 が 依 存 す る Message を 表 現 す る 。

condition-clause

は擬似コード又は実際のプログラム言語で表されるが,UML ではその形式を規定し

ない。例えば,[x > y]。

分岐は“星”のない反復と同様に示される。単一の実現値に限定される反復として,それをみなすこと

ができる。

反復の記法は,反復内の Message の逐次的実行を仮定する。並行に実行する可能性もある。これに対

する記法は,星印の後ろに(並行に対する)二重縦線を書く。例えば,*||

入れ子制御構造内では,反復が内側の順位では繰り返さない。各順位の構造は,閉じている文脈内での

反復を規定する。

5.72.2.5

  呼出し仕様

呼出し仕様は,Operation 又は Reception の名前,引数及び返却値を示す文字列とする。Message

の呼出し仕様は,Message がディスパッチする Action に結びついている Operation 又は動作に結びつ

いている Signal の Reception の呼出し仕様から導出する。これらは,次の特性をもつ。

返却値

これは全体の相互作用の一連の実行で,交信の最後で返される値を示す名前の並びである。この識別子

は,後続する Message への引数として用いることができる。Message が値を返却しない場合,返却値及

び代入演算子は省略する。

メッセージ名

これは,受信者に適用される Operation 又は受信者に送信される Signal の名前となる。

引数並び

これは,括弧内のコンマで区切られた引数(実パラメタ)の並びである。括弧は,その並びが空であっ

ても使用することができる。各引数は Instance への参照,擬似コード又は適切なプログラム言語で書い

た式のいずれかである(UML は,規定しない。

。式は,前のメッセージの返却値(同じ適用範囲で)及び


151

X 4170

:2009 (ISO/IEC 19501:2005)

起点 Instance からの誘導式(すなわち,その起点 Instance の Attribute 群,Link 群,及び到達可

能な経路)を用いてもよい。

5.72.3

  表示上の選択肢

注記  (対応国際規格では,5.72.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.72.4

  例

注記  (対応国際規格では,5.72.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.72.5

  対応付け

注記  (対応国際規格では,5.72.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.73

生成マーカ・解体マーカ

5.73.1

  意味論

生成マーカ・解体マーカは,相互作用の実行中に,ある Instance 群及び Link 群の生成及び解体を指

定する。要素の生成及び解体にはマークを付けることができる。

5.73.2

  記法

相互作用中に生成される Instance 又は Link は,標準の制約である new を付加する。相互作用の間に

解体される Instance 又は Link は,標準の制約である destroyed を付加する。これらの制約は,要素

に 名前 がつい てな くと も , 用 い ても よ い。 この 両 方 の 制 約を同 時に 用 いても よい が, 標 準 の 制 約

transient

を new destroyed の代わりに用いてもよい。

5.73.3

  表示上の選択肢

注記  (対応国際規格では,5.73.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.73.4

  例

注記  (対応国際規格では,5.73.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.73.5

  対応付け

注記  (対応国際規格では,5.73.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

第 区分  ステートチャート図(状態図)

5.74

ステートチャート図

ステートチャート図は,オブジェクト,相互作用などのモデル要素の振る舞いを規定する。特に,要素

が存続中に起こり得る状態及び動作系列を独立イベント(例えば,シグナル,操作の起動など)の反応と

して指定する。

この章で記述する意味論及び記法は,David Harel のステートチャートをオブジェクト指向用に変更した

ものである。彼の業績で従来の階層構造のない状態機械から大きく進歩した。また,ステートチャート記

法は,Moore 機械及び Mealy 機械で示される従来の状態機械の両方の側面を実装している。

5.74.1

  意味論

ステートチャート図は,イベントインスタンスの受信に対する応答を規定することによって動的な振る


152

X 4170

:2009 (ISO/IEC 19501:2005)

   

舞いのある実体の振る舞いを表現する。ステートチャート図は,主にクラスインスタンスの振る舞い記述

に用いる。しかし,ステートチャートは,ユースケース,アクタ,サブシステム,操作,メソッドなど他

の振る舞いを記述してもよい。

5.74.2

  記法

ステートチャートは,状態機械を表現するグラフである。状態機械グラフ内の状態及び様々な他の型を

表す頂点(擬似状態)は状態及び擬似状態記号で表し,遷移は状態記号を結ぶ有向線分で表す。状態は,

物理的な包含によって下位の図を含むことができる。状態機械には,状態機械全体のすべての要素を含む

最上位状態が存在する。最上位状態の図的表現は,選択的とする。

状態機械間の関連や文脈には,特別な記法はない。

簡単な電話オブジェクトのステートチャート図の例を

図 104 に示す。

図 104−状態図

5.74.3

  対応付け

注記  (対応国際規格では,5.74.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.75

状態

5.75.1

  意味論

状態は,オブジェクトの存続中又は相互作用中に,オブジェクト又は相互作用が条件を満たしたり,動

作を実行したり,イベントを待つなどする状況とする。合成状態は,単一状態とは対照的に図的に分解で


153

X 4170

:2009 (ISO/IEC 19501:2005)

きる(合成状態及びその記法は,5.76 に詳細を記述する。

。概念的には,オブジェクトはある時間ある状

態に留まっている。しかし,意味論的には瞬間的に“通り過ぎる”状態及び瞬間的でない遷移もモデル化

できる。

状態は進行中の活動をモデル化するのに用いてもよい。このような活動は,入れ子の状態機械又は計算

式で規定する。

5.75.2

  記法

状態は,丸み付き長方形で表す。選択的に名前タブを付けてもよい。名前タブは長方形であり,通常状

態の上部外側に添えられ状態名を書く。並行領域のある合成状態の名前を表すために使うが,他の場合に

も使ってよい。

状態は水平線で区切った複数の区画に細分してもよい。分割された区画は次のとおりとなる。

−  名前区画:この区画は状態名(選択)を文字列として保持する。名前のない状態は匿名であり,すべ

て別個のものとなる。一つの図中で同じ状態名を二度使用するのは混乱を起こすので望ましくない。

名前タブを使うときは名前区画を使わないことが望ましい。逆に,名前区画を使うときは名前タブは

使わないことが望ましい。

−  内部遷移区画:この区画は,要素がその状態中に実行される内部動作又は活動の並びを表す。

動作ラベルは,動作式が規定する動作を起動する状況を特定する。動作式を記述するときには,その実

体の有効範囲にある任意の属性及びリンクを使うことができる。動作式が空の場合,分離記号である逆斜

線は選択的となる。

多くの動作ラベルはいろいろな目的に予約されているので,それらはイベント名としては使えない。予

約動作ラベルとその意味を次に示す。

−  entry:このラベルは,対応する動作式によって規定される,状態入場時に実行される動作(入場動

作)を識別する。

−  exit:このラベルは,対応する動作式によって規定される,状態退場時に実行される動作(退場動作)

を識別する。

−  do:このラベルは,モデル要素がその状態にある間又は動作式が規定する計算完了までの間の実行活

動を識別する(計算完了の場合,完了イベントを生成する。

−  include:このラベルは,下位機械起動の識別に用いる。動作式は起動する下位機械の名前を含む。

下位機械状態とその記法については 5.82 で記述する。

その他の場合,動作ラベルは対応する動作式にトリガをかけるイベントを識別する。これらのイベント

は内部遷移と呼ばれ,状態が退場しないか再入場でない限り自己遷移と意味的に等しい。すなわち,対応

する入退場動作を実行しないことを意味する。内部状態の並び項目の一般的な形式は,次のとおりである。

  event-name ‘(’ comma-separated-parameter-list ‘)’ ‘[’ guard-condition‘]’

‘/’ action-expression

guard-condition

が異なる場合,同じ event-name 名が一つの状態に対して 2 回以上表れてもよい。

イベントパラメタ及び guard-condition は選択的である。イベントがパラメタをもつ場合,パラメタを

現在のイベント変数を action-expression で用いることができる。

5.75.2.1

注記  (対応国際規格では,5.75.2.1 は解説的内容であるため,この規格では不要であり,不採用とし


154

X 4170

:2009 (ISO/IEC 19501:2005)

   

た。

5.75.3

  対応付け

注記  (対応国際規格では,5.75.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.76

合成状態

5.76.1

  意味論

合成状態は,二つ以上の並行下位状態(領域と呼ぶ。

)又は互いに排他的に素である下位状態に分解され

る状態とする。与えられた合成状態の詳細化(細分化)は,これら二つの場合のどちらかに限る。必然的

に合成状態の下位状態は,いずれかの型の合成状態となることができる。

新たに生成されたオブジェクトは,最上位の初期擬似状態から始まる最上位の省略時遷移をする。最外

郭の最終状態に遷移するオブジェクトは終了する。

状態の各領域は,初期擬似状態及び最終状態をもってもよい。包含する状態への遷移は,下位領域の初

期擬似状態への遷移を表現する。下位領域での最終状態への遷移は,その下位領域での活動の完了を表現

する。すべての並行領域での活動の完了はこれらの領域を包含する上位状態の活動の完了を表現し,包含

するこの上位状態の完了イベントにトリガをかける。オブジェクトの最上位状態の完了は,オブジェクト

の終了に対応する。

5.76.2

  記法

状態を展開すると,内部の状態機械の構造を示す。合成状態には,

(選択的な)名前及び内部遷移区画の

他に入れ子の図の領域を含む区画があってもよい。便宜上及び見かけ上,テキスト区画は図形領域内で水

平方向に縮めてもよい。

並行下位状態への展開は,状態の領域をタイル状に並べ破線で区切って表す。各領域は,並行下位状態

となる。その場合,名前は選択的でよいが互いに素な入れ子状態となっていなければならない。状態全体

のテキスト区画は,実線で並行状態と区切る。並行状態の名前を書くためにタブ記法を使うこともできる。

タブ記法は,空白を節約する。

互いに素な下位状態への展開は,図形領域内で入れ子の状態図で表す。

初期擬似状態は,小さな黒丸で表す。最上位の状態機械では,初期状態からの遷移にはオブジェクト生

成イベントのラベルを付けてもよい。それ以外の場合では,そのラベルを付けてはならない。ラベルが付

けられていない場合,包含する状態への遷移を表す。初期遷移には,動作を付けてもよい。

注記  状態機械は,必ず最上位の状態がなければならない。ただし,図としてその最上位の状態を表

すかは選択的である(5.74 を参照)

最終状態は,黒丸及びそれを囲む円(標的)として表す。最終状態は包含する上位状態の活動の完了を

表現し,上位状態上の暗黙の活動完了イベントのラベルの付いた遷移(通常ラベルのない遷移として表す。

を,そのような遷移を定義している場合トリガをかける。

ある場合には,合成状態の分解表示を隠すと便利なこともある。例えば,合成状態内の状態機械が非常

に大きかったり,単に図に必要な空白がないこともある。このような場合,合成状態は特別な“合成”ア

イコンの付いた単一状態図形で表現してもよい(通常,右下隅に付ける。

。このアイコンは,−二つの水

平に結合した状態を表している−その状態が,現在のステートチャート内では表示していない分解構造が

あることを示す視覚的な印となる。

5.76.3

  例

注記  (対応国際規格では,5.76.3 は解説的内容であるため,この規格では不要であり,不採用とし


155

X 4170

:2009 (ISO/IEC 19501:2005)

た。

5.76.4

  対応付け

注記  (対応国際規格では,5.76.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.77

イベント

5.77.1

  意味論

イベントは着目すべき事象発生とする。状態図での現実的目的は,状態遷移にトリガをかける事象発生

である。イベントには幾つかの種類がある(互いに排他である必要はない。

−  (論理式で記述されたとして)真となる指定条件は,変更イベントインスタンスとする。式の値が偽

から真に変わると,常にイベントが発生する。これは,ガード条件とは異なる。ガード条件は,イベ

ント発火時に一度だけ評価する。ガード条件が偽の場合,遷移は起こらずイベントは失われる。

−  あるオブジェクトから他のオブジェクトへの明示的シグナル受信は,シグナルイベントインスタンス

とする。遷移におけるトリガとして,イベント呼出し仕様で表す。

−  オブジェクト遷移として実装した操作呼出し受信は,呼出しイベントインスタンスとする。

−  指定イベント(現在の状態への入場が多い)後の指定時間経過又は与えられた日付・時刻の発生は,

TimeEvent

とする。

イベント宣言はそのパッケージ内で有効範囲をもち,パッケージ内で可視性をもつクラスに対する状態

図に用いてよい。イベントは,一つのクラス内で局所的ではない。

5.77.2

  記法

シグナル又は呼出しイベントは,次の形式で定義する。

        event-name ‘(’ comma-separated-parameter-list ‘)’

パラメタは,次の形式をもつ。

        parameter-name ‘:’ type-expression

シグナルは,クラス図でクラス記号に

«signal»

を使って宣言できる。パラメタは,属性として指定す

る。あるシグナルは,別のクラスのシグナルの下位クラスとして規定できる。これは下位イベント発生が,

そのイベント又は祖先に基づく遷移にトリガをかけることを表す。

経過時間イベントは,キーワード after の後に評価する経過時間(モデル化した時間)になる式で規定

する。例えば,after(5 秒)又は after(状態 A を退場してから 10 秒)のように規定する。開始点を

示してない場合は,現在の状態へ入場してからの時間とする。条件として他の時間イベントも規定できる

[例えば,when(日付=2000 年 1 月 1 日)のように]

真になる条件は,キーワード when の後の論理式で示す。これは,値が真になるまで条件を連続的に試

験をするとみなすかもしれないが,実際には値が変化したときだけ検査する。

シグナルは,クラス図で長方形記号上に

«signal»

を使って定義できる。遷移にトリガをかけるために

使用するシグナル名を定義する。パラメタは,属性区画に示される。操作はない。シグナルは,はん(汎)

化関係で表してもよい。


156

X 4170

:2009 (ISO/IEC 19501:2005)

   

5.77.3

  例

注記  (対応国際規格では,5.77.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.77.4

  対応付け

注記  (対応国際規格では,5.77.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.78

単純遷移

5.78.1

  意味論

単純遷移は二つの状態間の関係を表し,規定された条件が満たされて規定されたイベントが発生したと

き,あるインスタンスが 1 番目の状態から 2 番目の状態に入り特定の動作をする。そのような状態変化で

は,遷移が“発火”するという。遷移に対するトリガは,その遷移にラベル付けされたイベント事象発生

となる。イベントはパラメタをもってもよく,そのパラメタは遷移で規定している動作及び遷移元状態と

遷移先状態とに付随している入退場動作でアクセス可能となる。イベントは,一度に一つだけ処理される。

イベントがどの遷移もトリガをかけない場合は,そのイベントは無視される。同一の逐次領域内で一つ以

上の遷移のトリガをかける(異なる並行領域でない)場合,一つだけが発火する。競合する遷移が同一の

優先度の場合,任意の一つを選びトリガをかける。

5.78.2

  記法

遷移は,遷移元状態から始まり遷移先状態に至る実線矢線で描く。その遷移のラベルは,次の形式とす

る。

        event-signature ‘[’ guard-condition ‘]’ ‘/’ action-expression

イベント呼出し仕様は,引数を伴うイベントを表す。

        event-name ‘(’ comma-separated-parameter-list ‘)’

guard-condition

は Boolean 式であり,トリガイベントのパラメタ,並びに,状態機械が表すオブ

ジェクトの属性及びリンクで表す。guard-condition は,現在の状態機械の並行状態試験及び到達可能

オブジェクトの明示的に示した状態(例えば,

“in 状態 1”又は“not in 状態 2”

)を含んでよい。状態

名は,入れ子状態で完全限定する経路名形式“状態 1::状態 2::状態 3”としてもよい。これは,異なる合成

状態領域で同一状態名となった場合に用いてよい。

action-expression

は,遷移が発火したときに実行する。動作式は,オブジェクトの所有する操作,

属性,及びリンク,並びにトリガをかけるイベントのパラメタ,又は適用範囲内で可視である他の素性,

を使って記述する。この動作は,他のいかなる動作よりも前に実行しなければならない。この実行モデル

は,

“完了実行”意味論として知られている。この動作式は,独立した動作からなる動作列でよく,この動

作列には,シグナル送信,操作起動などの明示的にイベントを生成する動作を含んでもよい。この式の詳

細は,モデルの動作言語に依存する。

5.78.2.1

  遷移時間

遷移が発火する時間を指定するために,遷移上に名前を付ける(5.64 を参照)


157

X 4170

:2009 (ISO/IEC 19501:2005)

5.78.3

  例

注記  (対応国際規格では,5.78.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.78.4

  対応付け

注記  (対応国際規格では,5.78.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.79

並行状態への遷移

並行遷移は,複数の遷移元状態及び遷移先状態をもつ。並行遷移は,同期及び/又は並行下位状態のな

い並行スレッドへの制御分割を表現する。

5.79.1

  意味論

並行遷移は,すべての遷移元状態になったとき可能となる。発火後,すべての遷移先状態になる。

5.79.2

  記法

並行状態は短く太い棒(

“同期棒”であり,同期,分岐,又はその両方を示す。

)で表す。遷移元状態か

ら“同期棒”への一本以上の実線矢線を書くことができる。遷移文字列を“同期棒”の付近に書いてもよ

い。各々の矢線は,それぞれの遷移文字列を書かない。

5.79.3

  例

注記  (対応国際規格では,5.79.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.79.4

  対応付け

注記  (対応国際規格では,5.79.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.80

合成状態への遷移

5.80.1

  意味論

合成状態境界への遷移は,その開始点への遷移(並行な場合には,並行領域の各開始点への合成遷移)

と等価とする。入場動作は,外部からその状態へ入場したときに常に実行される。

合成状態からの一つの遷移は,その状態領域内の全深度の各状態につながっている。その遷移は,入れ

子状態に“継承”される。継承された遷移は,同一トリガをもつ入れ子遷移の存在によって覆い隠すこと

ができる。

5.80.2

  記法

合成状態の境界へ向かう遷移は,合成状態への遷移を表す。これは,合成状態領域内の初期擬似状態へ

の遷移と等価となる。初期擬似状態は,存在しなければならない。状態が並行合成状態の場合,遷移は並

行下位状態の各初期擬似状態への遷移を表す。

遷移は,任意の入れ子の深さの合成状態領域に直接向かってよい。すべての入場動作は,遷移が進入し

た状態で実行する。並行合成状態内の遷移では,

“同期棒”からの遷移矢線は一つ以上の並行状態へ引いて

もよい。他の並行領域は,省略時初期状態から開始する。

合成状態境界からの遷移は,合成状態の遷移を示す。そのような遷移が発火する場合,内部の入れ子状

態は強制終了し退場動作を行い,遷移動作が起こり新たな状態となる。

遷移は,任意の深さの入れ子の合成状態領域内の各状態からその外部の状態へ直接向かってよい。すべ

ての退場動作は,遷移が退場するすべての状態上で実行する。並行合成状態内の遷移で,遷移矢線は一つ

以上の並行状態から“同期棒”へ向かってよい。したがって,他の領域の状態は遷移のトリガには関係し


158

X 4170

:2009 (ISO/IEC 19501:2005)

   

ない。

状態領域は,

‘H’と書かれた小さな円として履歴状態指示子を書いてもよい。履歴指示子は,それが示

されている状態領域に適用する。履歴指示子は,何本もの外部状態から入力遷移をもってもよい。ラベル

なしの出力遷移を一つもってもよい。これは,その領域に入場していない場合,省略時の“以前の状態”

を識別する。履歴指示子への遷移が発火した場合,オブジェクトが合成領域内で最後に所有していた状態

を再開する。必要な入場動作が,実行される。履歴指示子は,

“深い履歴”用の‘H*’としてもよい。こ

れは,合成領域内の任意の深さの最後の状態を再開することを示す(履歴指示子と同一順位の状態を限定

する訳ではない。

。領域は“浅い”及び“深い”履歴指示子の両方をもってもよい。

5.80.3

  表示上の選択肢

注記  (対応国際規格では,5.80.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.80.4

  例

注記  (対応国際規格では,5.80.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.80.5

  対応付け

注記  (対応国際規格では,5.80.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.81

分解遷移経路

5.81.1

  意味論

定義によって,遷移は状態機械グラフ上の二つの頂点を結ぶ。しかし,この頂点には一時的な擬似状態

もあるので,単一の“完了実行”ステップの文脈で実行される遷移の連鎖を記述する必要がある。そのよ

うな遷移を複合遷移という。

実用的には,複合遷移の切片を共有すると便利になることが多い。例えば,二つ以上の複合遷移が一緒

になり共有経路をとり動作を共有し同じ状態で終了する場合がある。他の場合として,相互排他経路(す

なわち,非並行)に遷移を分解すると便利となることもある。

これらの両方は図的な分解の例であり,ある遷移を共有することによって単純な図になる。しかし,分

解は動的に適応する振る舞いをモデル化するのにも便利である。例としては,単一イベントが遷移先状態

集合に遷移させるが,最終遷移先状態は複合遷移にトリガをかけた後の動作(計算)の結果として決定さ

れるものである。

分解による経路の分割及び結合は,5.79 で述べている並行遷移の分割及び結合とは異なっている。分解

遷移の遷移元と遷移先とは並行ではない。

5.81.2

  記法

異なる非並行な状態又は擬似状態から始まる二つ以上の遷移が,共通の結合点で終了できる。各複合遷

移は,連結点から始まる経路を共有できる。連結点は小さな黒丸で表現する。又は,ひし(菱)形で表現

してもよい(5.87 を参照)

同一の連結点から始まる二つ以上のガード遷移は,静的分岐点を表現する。通常,ガードは互いに排他

となる。これは,木構造の各経路に沿った全条件の論理積をガード条件とした各々の遷移の集合と等価と

なる。静的分岐の意味論では,すべての出力遷移のガードは遷移する前に評価される。

共通の動的選択点から始まる二つ以上のガード遷移は,動的選択をモデル化するのに用いられる。この


159

X 4170

:2009 (ISO/IEC 19501:2005)

場合,出力遷移のガードはその選択点に到達時に評価する。ガードの値は,入力遷移の動作で実行される

計算の関数であってよい。動的選択点は,小さな白丸で表す(小さな状態アイコンを想起させる。

5.81.3

  例

注記  (対応国際規格では,5.81.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.82

下位機械状態

5.82.1

  意味論

下位機械状態は,別の場所で定義された状態機械の起動とする。他の仕様で規定した複雑な仕様の畳み

込みを意味している簡略形を表現するという意味でマクロ呼出しに似ている。下位機械は,起動する状態

機械と同一文脈になければならない。

一般的な場合,起動される状態機械は,その任意の下位状態に入場できるか,又はその省略時(初期)

擬似状態から入場できる。同様に,任意の下位状態から,状態機械の最終到達結果として,又は下位機械

内のすべての下位状態に適用される“継承”若しくは“グループ”遷移によって,退場できる。省略時以

外の入退場は,スタブ状態で規定できる。

5.82.2

  記法

下位機械状態は,その内部遷移区画内に適切な“include”宣言を付けた通常の状態として表す(5.75

を参照)

。予約語 include に続く式は,起動された下位機械の名前である。

選択的に,下位機械は一つ以上の入場スタブ状態及び一つ以上の退場スタブ状態をもってもよい。これ

らの記法は端点にラベルを付けることを除いて,スタブ化遷移のスタブ端点に用いられているのと同様と

なる。そのラベルは起動された下位機械内で対応する下位状態の名前を表現する。起動された下位機械の

最上位で,下位状態が未定義の場合は,経路名を用いる。名前は,起動された下位機械内の状態の有効な

名前でなければならない。

下位機械が省略時擬似状態から入場するか又は下位機械状態完了の結果退場する場合,スタブ状態記法

を使う必要はない。同様に,下位機械状態の境界が起点となる明示的“グループ”遷移で退場が起こる場

合,スタブ状態は必要ではない(下位機械のすべての下位状態への適用を意味する。

同じ下位機械を起動する下位機械状態を,異なる入出場点の動作仕様及び異なる内部遷移をもつ同一の

状態図内で複数回起こすことができる。

5.82.3

  例

注記  (対応国際規格では,5.82.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.82.4

  対応付け

注記  (対応国際規格では,5.82.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.83

同期状態

5.83.1

  意味論

同期状態は,状態機械の同期並行領域を表す状態とする。他の領域がある状態に入場する前にある領域

がその特定の状態から退場することを保証するために,分岐及び合流の結合が用いられる。同期状態から

出て行く遷移の発火は,出力遷移及び入力遷移の発火数の差を規定することによって制限できる。

5.83.2

  記法

同期状態は,内部に上限を書き込んだ小さな円として表す。その上限は正の整数又は星印(

‘*’:無制限


160

X 4170

:2009 (ISO/IEC 19501:2005)

   

を表す。

)とする。同期状態は,可能な場合二つの領域間の境界上に描く。

5.83.3

  例

注記  (対応国際規格では,5.83.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.83.4

  対応付け

注記  (対応国際規格では,5.83.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

第 10 区分  アクティビティ図(活動図)

5.84

アクティビティ図

5.84.1

  意味論

アクティビティ図は,状態の意味論を規定する状態機械の一種とする。その状態の活動完了又は下位活

動の完了が遷移のトリガをかける。それは,手続自体の状態機械を表現する。

5.84.2

  記法

アクティビティ図は,状態図の特別な場合とする。ほとんどすべての状態が活動状態又は下位活動状態

であり,ほとんどすべての遷移が遷移元の活動又は下位活動の完了によってトリガをかけられる。全体の

アクティビティ図は(モデルによって)

,ユースケース,パッケージ,操作の実装などの分類子に結び付け

る。この図の目的は,内部の処理(外部のイベントではなく)によって駆動されるフローに着目すること

である。アクティビティ図は,すべて又はほとんどのイベントが内部的に生成した動作の完了を表現する

状況(すなわち,手続的制御フロー)において用いる。非同期イベントが発生する状況では,通常の状態

図を用いる。

5.84.3

  例

注記  (対応国際規格では,5.84.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.84.4

  対応付け

注記  (対応国際規格では,5.84.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.85

動作状態

5.85.1

  意味論

動作状態は,入場動作と少なくとも一本の出力遷移と,暗黙の入場動作の完了イベントとを含んだ状態

(ガード条件があれば,更に複数の遷移がある。

)の簡略記法とする。動作状態は,内部遷移,明示的イベ

ントによる出力遷移及び退場動作をもたないほうがよい。このような場合は,通常の状態を使ってはなら

ない。動作状態から退場する遷移は,イベント呼出し仕様を含まないほうがよい。このような遷移は,そ

の状態における動作の完了によって暗黙り(裡)にトリガをかけられる。遷移はガード条件及び動作を含

んでもよい。動作状態の通常の用法は,アルゴリズム(手続)の実行又はワークフローの実行におけるス

テップをモデル化することである。

5.85.2

  記法

動作状態は,上下が直線でその両端に円弧をもつ形状とする。動作式は,その記号中に書く。動作式は,

同一図中でユニークである必要はない。


161

X 4170

:2009 (ISO/IEC 19501:2005)

5.85.3

  表示上の選択肢

注記  (対応国際規格では,5.85.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.85.4

  例

注記  (対応国際規格では,5.85.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.85.5

  対応付け

注記  (対応国際規格では,5.85.5 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.86

下位活動状態

5.86.1

  意味論

下位活動状態は,アクティビティグラフを起動する状態とする。下位活動状態に入場したとき,

“入れ子”

になっているアクティビティグラフをアクティビティグラフとして実行する。下位活動状態は入れ子にな

っているグラフの最後の状態に到達するまで又は下位活動状態からの退場遷移のトリガイベントが発生す

るまで,下位活動状態からは退場しない。通常アクティビティグラフの状態はトリガイベントをもたない

ので,下位活動状態の入れ子になっているグラフが終了したとき下位活動状態から退場する。複数の下位

活動状態が一つのアクティビティグラフを起動してもよい。

5.86.2

  記法

下位活動状態は動作状態と同じ方法で表すが,異なるのは右下隅に入れ子アクティビティ図を示すアイ

コンを付ける。下位活動の名前は,記号の中に書く。下位活動は,同一図中でユニークである必要はない。

この記法は,

“入れ子”構造をサポートする他の UML 構成要素に適用できる。そのアイコンは入れ子構

造の型を示唆しなければならない。

5.86.3

  例

注記  (対応国際規格では,5.86.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.86.4

  対応付け

注記  (対応国際規格では,5.86.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.87

判断

5.87.1

  意味論

判断は,状態図(及び派生したアクティビティ図)では,オブジェクトの論理条件によって決定するそ

れぞれの遷移を示す条件とする。UML では,判断及びその判断の合流に対する簡略記法がある。それぞれ

の結果は,そこからの出力遷移として表すことが望ましい。

“else”として表す既定義のガードを一つの

出力遷移に定義してよい。この遷移は,他の遷移のすべてのガードが偽の場合,実行可能となる。

5.87.2

  記法

判断は,異なるガード条件をラベル付けした複数の出力遷移として表す。

判断のアイコンは伝統的なひし(菱)形とし,一つの入力矢線と二つ以上の出力矢線とを書き,イベン

トトリガがなく互いに異なったガード条件のラベルを付ける。

同一のアイコンを,判断分岐の併合を表すためにも用いる。これを合流と呼ぶ。合流は,二つ以上の入

力矢線及び一つの出力矢線を描く。


162

X 4170

:2009 (ISO/IEC 19501:2005)

   

判断の連鎖は,合成遷移の一部としてもよい。しかし,その連鎖の第一切片だけがイベントトリガラベ

ルを含むことができる。すべての切片に,ガード式を記述してもよい。合流から来る遷移は,トリガラベ

ル又はガード式をもたない。

5.87.3

  例

注記  (対応国際規格では,5.87.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.87.4

  対応付け

注記  (対応国際規格では,5.87.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.88

呼出し状態

5.88.1

  意味論

呼出し状態は,その入場動作として一つだけの呼出し動作をもつ動作状態とする。オブジェクトフロー

のモデル化は,動作が入力をもち出力を提供するということに関する記法上のあいまい性を減らすのに有

用となる。

5.88.2

  記法

呼出し状態は,動作状態と同様に表される。ただし,呼出し動作の操作名はその記号内に表し分類子を

操作名の下に括弧を使って表す。

5.88.3

  例

注記  (対応国際規格では,5.88.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.88.4

  対応付け

注記  (対応国際規格では,5.88.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.89

レーン

5.89.1

  意味論

レーンは,複数の動作及び下位活動を一つにまとめたものでなければならない。レーンは,例えば,動

作及び下位活動の責務ごとにまとめるために用いる。それらは,しばしばビジネスモデルの組織的な単位

となる。

5.89.2

  記法

アクティビティ図は,視覚的に“レーン”に分割してもよい。そして,各レーンは両側の隣接するレー

ンと垂直実線で分離する。レーンの相対順序には,意味がない。各動作を各レーンに割り当てる。遷移は,

レーンをまたがってもよい。遷移経路の順路には意味がない。

5.89.3

  例

注記  (対応国際規格では,5.89.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.89.4

  対応付け

注記  (対応国際規格では,5.89.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。


163

X 4170

:2009 (ISO/IEC 19501:2005)

5.90

動作とオブジェクトフローとの関係

5.90.1

  意味論

動作は,オブジェクトによってオブジェクトに対し作用する。これらのオブジェクトは,動作を起こす

主要な責任をもつか,又はその動作で使用若しくは決定されるかのいずれかとする。動作は,動作を起動

しアクティビティグラフをもつオブジェクトとその動作の対象となるオブジェクトとの間の呼出しを規定

する。

5.90.2

  記法

5.90.2.1

  動作に対するオブジェクトの責任

シーケンス図では,動作を行うオブジェクトの責任は生存線とその上に動作を書いて表す(5.60 を参照)

アクティビティ図は生存線は表さないが,各々の動作はどのオブジェクトがその操作を行うかを仕様化す

る。これらのオブジェクトは,ある方法でレーンと関係してもよい。レーン内の動作は同一オブジェクト

又は複数のオブジェクトによって扱われる。

5.90.2.2

  オブジェクトフロー

動作の入出力となるオブジェクトは,オブジェクト記号で表す。破線矢線を,動作状態から出力となる

オブジェクトへ描き,そして入力オブジェクトから動作状態へ描く。同一オブジェクトはある動作の出力

となり,一つ以上の後続動作の入力としてもよい。

制御フロー(実線)の矢線は,オブジェクトフローの(破線)矢線を書いて冗長になれば省略しなけれ

ばならない。言い換えると,ある状態がオブジェクトを出力しそれが後続状態の入力となるとき,オブジ

ェクトフローで示される関係は制御フローを意味する。

5.90.2.3

  状態におけるオブジェクト

しばしば,同一オブジェクトを多数の後続動作又は下位活動が操作する。一つのオブジェクトと関係す

るすべての動作及び下位活動へ,又はそれからの矢線を描くことができる。しかし,より分かりやすくす

るためにそのようなオブジェクトは一つの図中複数表示してもよい。各々は,オブジェクトの生存期間中

の異なる時点のものを表す。同一オブジェクトが多数現れていることを区別するために,各々のオブジェ

クトの状態をかぎ括弧内に書きそれをオブジェクト名の後ろに付けてもよい(例えば,購入依頼[承認]

この記法は,コラボレーション図及びシーケンス図でも用いてよい。

5.90.3

  例

注記  (対応国際規格では,5.90.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.90.4

  対応付け

注記  (対応国際規格では,5.90.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.91

制御アイコン

制御アイコンは,遷移上で指定できるある種の情報に対する明示的な表現とする。これらのアイコンは

アクティビティ図を描くのには必す(須)ではないが,多くの利用者はそれらがもつ付加的効果が必要と

なる。5.91.1 で,制御アイコンの種類及び記法を示す。

5.91.1

  記法

5.91.1.1

  シグナルの受信

シグナルの受信は,

(いずれかの一方の)側面に三角のくぼみのある凹五角形として表す。シグナルの呼

出し仕様は,記号の内側に表す。ラベルのない遷移矢線を先行する動作状態からこの五角形へ引き,そし


164

X 4170

:2009 (ISO/IEC 19501:2005)

   

て別のラベルなしの遷移矢線をこの五角形から次の動作状態へ引く。破線矢線をオブジェクト記号からこ

の五角形のくぼみに向かって引いてもよく,これはシグナルの送信者を示す。これは,選択的である。

5.91.1.2

  シグナルの送信

シグナルの送信は,

(いずれか一方の)側面に三角のせん(尖)端をもつ凸五角形で表す。シグナルの呼

出し仕様は記号の内側に表す。ラベルのない遷移矢線を先行の状態遷移からこの五角形へ引き,そして他

のラベルのない遷移矢線をこの五角形から次の動作状態へ引く。破線矢線を五角形のせん(尖)端からオ

ブジェクト記号に引いてもよく,シグナルの受信者を示す。これは,選択的である。

図 124−シグナルの送受信のための記号

5.91.1.3

  遅延イベント

しばしば,他の動作又は下位活動が進行中に発生したイベントを遅延しなければならないことがある(通

常,処理されないイベントは直ちに消失する。

。これはそのイベントが消費されるか廃棄されるまで,内

部キューに保持している内部遷移として考えられる。各状態は,その状態のときに発生しても遅延され遷

移トリガとして使わないイベント集合を指定する。あるイベントがその状態上の遅延可能イベントに含ま

れず遷移にトリガをかけない場合,既に発生していてもキューから除去される。遷移がイベントに依存し

イベントが内部キューにある場合,遷移は直ちに発火する。複数の遷移が可能な場合,キュー内の先頭イ

ベントが優先する。

遅延可能イベントは,状態内に斜線及び操作 defer をイベント名に付けた並びで表す。そのイベントが

起きた場合,そのイベントを保存し,他の状態へ遷移したときに再現される。他状態で再遅延もある。オ

ブジェクトがイベント遅延されない状態に到達すると,そのイベントは受理されるか又は消失されなけれ

ばならない。合成状態,又はそれと等価な下位機械状態及び下位活動状態に,イベントが遅延可能の指示

を表してもよいが,それはその合成状態全体を通して遅延可能であり続ける場合となる。

保持している遷移を遅延可能イベントがトリガをかけると,そのキューからその遷移が除かれる。

動作状態では,イベントを遅延する必要はない。なぜならば,動作状態ではイベント処理に対して割込


165

X 4170

:2009 (ISO/IEC 19501:2005)

み可能ではないからである。この場合,その状態中で発生した遅延イベント及び非遅延イベントの両方が,

その状態が完了するまで遅延される。これはイベントの相対順序,状態完了及びイベント遅延に関係なく

遷移のタイミングは同じであることを意味する。

図 125−遅延イベント

5.91.2

  対応付け

注記  (対応国際規格では,5.91.2 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.92

同期状態

同期状態は,状態機械の同期状態と同様とする。アクティビティ図で SynchState が一つずつの入出力

遷移をもち,かつ,制限のない境界をもつとき,SynchState 記法は省略してもよい。意味論及び対応付

けは,もし同期状態の丸が含まれているならば,状態機械の記法として定義しているものと同じとする。


166

X 4170

:2009 (ISO/IEC 19501:2005)

   

図 126−並行活動の同期

5.93

動的呼出し

5.93.1

  意味論

動作状態の動作又は下位活動状態のアクティビティグラフは,二度以上並行実行してよい。並行起動の

数は,並行式によって実行時に決定される。この並行式の評価結果は,引数並びの集合と評価され起動ご

とに一つの引数並びがある。

5.93.2

  記法

動作又は下位活動状態の動的起動が一回限りでない場合,その多重度を状態の右上隅に示す。そうでな

れば,何も示さない。

5.93.3

  対応付け

注記  (対応国際規格では,5.93.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.94

条件付き並行分岐

アクティビティ図では,並行分岐からの出力遷移はガードをもってもよい。これは並行分岐遷移で始ま

る領域が開始せず,対応する合流で完了することが要求されないことを意味する。ガードの通常の記法及

び対応関係が,並行分岐からの出力遷移に用いられる。

第 11 区分  実装図

5.95

コンポーネント図(部品図)

実装図は物理的な実装の側面を表し,コンポーネントの構造及び実行時のシステム配置を含む図とする。

実装図は,コンポーネント図と配置図との二種類の図となる。1)  コンポーネント図は,コンポーネントの

構造を表し,その中にはコンポーネントを規定する分類子及びコンポーネントを実装する成果物を示す。

2)

配置図は,コンポーネントを配置するノードの構造を示す。これらの図はビジネスモデルにまで広く適

用することができ,その場合コンポーネントはビジネス手続及び成果物を表し,配置ノードはビジネス上

の構成単位及び(人的その他の)資源を表す。


167

X 4170

:2009 (ISO/IEC 19501:2005)

5.95.1

  意味論

コンポーネント図は,ソフトウェアコンポーネント間の依存関係を表し,そのコンポーネントを規定す

る分類子(例えば,実装クラス)及びそれらを実装する成果物を含める。例えば,ソースコードファイル,

バイナリコードファイル,実行可能ファイル,スクリプトなどがある。

コンポーネント図は,型形式だけでありインスタンス形式の図はない。配置図は,コンポーネントイン

スタンスを表すために使う(ノードなしで生成が可能である。

5.95.2

  記法

コンポーネント図は,依存関係によって結合したコンポーネントのグラフとなる。コンポーネント同士

は物理的な包含関係で結合してもよく,それは合成関係を表現する。

コンポーネントを規定する分類子は,物理的包含又は

«reside»

関係によってコンポーネントに結合で

き,その場合,その関係は Component と ModelElement との間のメタ関連のインスタンスとなる。同

様にコンポーネントを規定する成果物は,物理的包含又は

«implement»

関係によってコンポーネントと結

合でき,Component と Artifact との間のメタ関連のインスタンスとなる。

コンポーネント型を含む図は,静的依存関係を表すために用いる。例えばプログラム間のコンパイル依

存などであり,クライアントコンポーネントから提供元コンポーネントへの破線矢線(依存)で表す。こ

の種の依存は,実装固有であり依存のステレオタイプで表してよい。

コンポーネントは,それ自身の素性(例えば,属性,操作)をもっていないが,素性を定義する分類子

のコンテナとして振る舞う。コンポーネントはインタフェースを公開し,それはコンポーネント上に存在

している要素が提供するサービスを表現する。コンポーネント図は,これらコンポーネント間のインタフ

ェース及び呼出し依存を表すことができる。このとき,コンポーネントから他のコンポーネントのインタ

フェースに破線矢線を用いる。

5.95.3

  例

注記  (対応国際規格では,5.95.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.95.4

  対応付け

注記  (対応国際規格では,5.95.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.96

配置図

5.96.1

  意味論

配置図は,実行時の処理要素,ソフトウェアコンポーネント,プロセス,オブジェクトなどの構成を示

す図とする。ソフトウェアコンポーネントインスタンスは,ソフトウェアコード単位の実行時の具現を表

現する。

(既にコンパイルされ)実行時の実体として存在しないコンポーネントは,配置図には表さずコン

ポーネント図に表す。

ビジネスモデルでは,実行時の処理要素は作業者及び組織単位,ソフトウェアコンポーネントは作業者

及び組織単位が用いる手続,文書などである。

5.96.2

  記法

配置図は,交信関連で結合したノードのグラフとする。ノードはコンポーネントインスタンスを含んで

よい。これは,コンポーネントがそのノード上で稼動又は実行することを表す。コンポーネントは分類子

のインスタンスを含んでもよく,それはそのインスタンスがコンポーネント上に存在することを表す。コ

ンポーネントは,別のコンポーネントと破線矢線の依存(おそらくインタフェース)で接続する。これは,


168

X 4170

:2009 (ISO/IEC 19501:2005)

   

コンポーネントが他のコンポーネントのサービスを用いることを表す。ステレオタイプは,必要ならば正

確な依存関係を示すために用いてもよい。

配置図は,どのコンポーネントが,どのノードに存在するかを示すために用いる。それは,«deploy»

を付けた破線矢線をコンポーネントからノード記号へ引くか,ノード記号内にコンポーネント記号を図的

に入れ子にして表す。

ノードインスタンスからノードインスタンスへのコンポーネントインスタンスの移出又はコンポーネン

トインスタンスからコンポーネントインスタンスへのオブジェクトの移出は,«become»

を付けた依存関

係を使って表す。この場合,コンポーネントインスタンス又はオブジェクトは,ノード上又はコンポーネ

ントインスタンス上に一時的に存在する。

プロセスは,オブジェクトの特殊な種類とする(5.71 を参照)

5.96.3

  例

注記  (対応国際規格では,5.96.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.96.4

  対応付け

注記  (対応国際規格では,5.96.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.97

ノード

5.97.1

  意味論

ノードは,処理資源を示す物理的なオブジェクトを表現する。一般には,少なくともメモリ及び処理能

力を備えた処理資源を表す。ノードは計算機器ばかりでなく,人的資源又は機械処理資源を含む。ノード

は,型及びインスタンスとして表現してよい。実行時の計算インスタンス,例えばオブジェクト,コンポ

ーネントインスタンスなどはノードインスタンス上に存在してよい。

5.97.2

  記法

ノードは,三次元の立方体図形で表す。ノード型は,型名をもつ。

        node-type

ノードインスタンスは,名前及び型名をもつ。ノードは,その記号の中又は下に下線付き名前文字列を

付けてもよい。名前文字列は,次の構文となる。

        name ‘:’ node-type

name

は,ノード名がある場合は個々のノードの名前となる。node-type は,ノードの種類を表す。ど

ちらも選択的である。node-type が省略された場合,コロンも省略する。

«deploy»

を付けた破線矢線は,その node-type がコンポーネント型をサポート可能であることを示す。

代わりに,ノード記号の内側に入れ子のコンポーネント記号で表してもよい。

コンポーネントインスタンス及びオブジェクトは,ノードインスタンス記号内に含めてもよい。これは,

それらがノードインスタンス上に存在することを示す。

ノードは,他のノードと関連で結んでもよい。ノード間の関連は,ノード間の交信経路を示す。その関

連は,更新経路の形態を示すステレオタイプを使ってもよい(例えば,チャネル及びネットワークの種類)


169

X 4170

:2009 (ISO/IEC 19501:2005)

5.97.3

  例

注記  (対応国際規格では,5.97.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.97.4

  対応付け

注記  (対応国際規格では,5.97.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

5.98

コンポーネント

5.98.1

  意味論

コンポーネントはモジュール化された配置可能で置換え可能なシステムの部分を表現し,実装を隠ぺい

(蔽)しインタフェースの集合を公開する。

コンポーネントは,コンポーネントに存在する一つ以上の分類子で規定される。これらの分類子の部分

集合は,明示的にコンポーネントの外部インタフェースを定義する。コンポーネントはその公開するイン

タフェースに準拠し,そのインタフェースはコンポーネント上に存在する要素が提供するサービスを表現

する。コンポーネントは一つ以上の成果物,例えば,バイナリファイル,実行可能ファイル,スクリプト

ファイルなどで実装してよい。コンポーネントは,ノード上に配置する。

5.98.2

  記法

コンポーネントは,大きな長方形にその側面から二つの突き出した長方形を付けたもので表す。コンポ

ーネント型は,型名をもつ。

        component-type

コンポーネントインスタンスは,名前及び型をもつ。コンポーネントの名前及び型は,コンポーネント

記号中又は上下に下線付き文字列で示す。その構文は,次となる。

        component-name ‘:’ component-type

どちらも選択的である。component-type が省略された場合,コロンも省略する。

コンポーネントインスタンス上に存在するオブジェクトは,コンポーネントインスタンス記号内に入れ

子として表す。類推によって,コンポーネントによって実装されるクラスは,コンポーネント内に入れ子

として表してよい。これは内包を示すものであって,所有関係ではない。

コンポーネント上にある要素は,コンポーネント記号内に入れ子として表す。内在する要素の他コンポ

ーネントに対する可視性は,パッケージの中身の可視性と同じ記法で示される(すなわち,パッケージ名

の後ろに可視性記号を書く。

。可視性の意味は,コンポーネントの形態に依存する。例えば,ソース言語

コンポーネント(プログラムテキスト)では,ソース言語要素へのアクセスを制御する。実行時コードコ

ンポーネント(実行可能コード)では,他のコンポーネントのコードからの呼出し又はアクセスを制御す

る。

5.98.3

  例

注記  (対応国際規格では,5.98.3 は解説的内容であるため,この規格では不要であり,不採用とし

た。


170

X 4170

:2009 (ISO/IEC 19501:2005)

   

5.98.4

  対応付け

注記  (対応国際規格では,5.98.4 は解説的内容であるため,この規格では不要であり,不採用とし

た。

6

UML

  プロファイルの例

注記  (対応国際規格では,箇条 は解説的内容であるため,この規格では不要であり,不採用とし

た。

7

UML

  モデル交換

注記  (対応国際規格では,箇条 は解説的内容であるため,この規格では不要であり,不採用とし

た。

8

OCL

  オブジェクト制約言語

注記 OCL で記述された各要素に対する正構造記述は,一般の UML 利用者には必要はないので,こ

の規格では不採用とした。


171

X 4170

:2009 (ISO/IEC 19501:2005)

附属書 A

規定)

UML

標準要素

A.1

概要

この附属書は,既定義の UML 標準要素を含む。標準要素は,ステレオタイプ,制約条件及びタグ付き

値とする。既定義の UML 標準要素で使われる名前は予約語として扱われるので,モデル作成者は,これ

らの名前を異なる定義で上書きしないことが望ましい。各標準要素は,その基底要素を含む箇条 4(UML

意味論)に記述されている。

標準要素名

適用する基底要素

種類

«access» Permission

ステレオタイプ

«appliedProfile»

Dependency (as extended)

ステレオタイプ

association LinkEnd

標準制約

«association» AssociationEnd

ステレオタイプ

«auxiliary» Class

ステレオタイプ

«become» Flow

ステレオタイプ

«call» Usage

ステレオタイプ

complete Generalization

標準制約

«copy» Flow

ステレオタイプ

«create» BehavioralFeature

ステレオタイプ

«create» CallEvent

ステレオタイプ

«create» Usage

ステレオタイプ

«derive» Abstraction

ステレオタイプ

derived ModelElement

タグ付き値

«destroy» BehavioralFeature

ステレオタイプ

«destroy» CallEvent

ステレオタイプ

destroyed Instance

標準制約

destroyed Link

標準制約

disjoint Generalization

標準制約

«document» Artifact

ステレオタイプ

documentation Element

タグ付き値

«executable» Artifact

ステレオタイプ

«facade» Package

ステレオタイプ

«file» Artifact

ステレオタイプ

«focus» Class

ステレオタイプ

«framework» Package

ステレオタイプ

«friend» Permission

ステレオタイプ

global LinkEnd

標準制約

«global» AssociationEnd

ステレオタイプ

«implementation» Class

ステレオタイプ

«implementation» Generalization

ステレオタイプ

«implicit» Association

ステレオタイプ

«import» Permission

ステレオタイプ

incomplete Generalization

標準制約

«instantiate» Usage

ステレオタイプ


172

X 4170

:2009 (ISO/IEC 19501:2005)

   

標準要素名

適用する基底要素

種類

«invariant» Constraint

ステレオタイプ

«library» Artifact

ステレオタイプ

local LinkEnd

標準制約

«local» AssociationEnd

ステレオタイプ

«metaclass» Classifier

ステレオタイプ

«metamodel» Model

ステレオタイプ

«modelLibrary»

Dependency (as extended)

ステレオタイプ

«modelLibrary» Package

ステレオタイプ

new Instance

標準制約

new Link

標準制約

overlapping Generalization

標準制約

parameter LinkEnd

標準制約

«parameter» AssociationEnd

ステレオタイプ

persistence Association

タグ付き値

persistence Classifier

タグ付き値

persistence StructuralFeature

タグ付き値

persistent Instance

タグ付き値

«postcondition» Constraint

ステレオタイプ

«powertype» Classifier

ステレオタイプ

«precondition» Constraint

ステレオタイプ

«process» Classifier

ステレオタイプ

«profile» Package

ステレオタイプ

«realize» Abstraction

ステレオタイプ

«refine» Abstraction

ステレオタイプ

«requirement» Comment

ステレオタイプ

«responsibility» Comment

ステレオタイプ

self LinkEnd

標準制約

«self» AssociationEnd

ステレオタイプ

semantics Classifier

タグ付き値

semantics Operation

タグ付き値

«send» Usage

ステレオタイプ

«signalflow» ObjectFlowState

ステレオタイプ

«source» Artifact

ステレオタイプ

«stateInvariant» Constraint

ステレオタイプ

«stub» Package

ステレオタイプ

«systemModel» Model

ステレオタイプ

«table» Artifact

ステレオタイプ

«thread» Classifier

ステレオタイプ

«topLevel» Package

ステレオタイプ

«trace» Abstraction

ステレオタイプ

transient Instance

標準制約

transient Link

標準制約

«type» Class

ステレオタイプ

«utility» Classifier

ステレオタイプ

usage Transition

タグ付き値

xor Association

標準制約


173

X 4170

:2009 (ISO/IEC 19501:2005)

附属書 B

規定)

法的情報

注記  附属書 の扱いについて

ここに記載している情報は,この規格と ISO/IEC 19501 とが IDT(一致規格)であることを

考慮し,Annex B (normative) Legal Information を変更することなく掲載するものである。しかし,

この規格の利用者は,

“まえがき”で書かれている著作権及び特許権に関する記述以上の制約を

何ら受けるものではない。

将来,ISO/IEC において ISO/IEC 19501 の改定が審議される段階で,日本からはこの項の除

外を求めるものとする。

なお,

ISO/IEC JTC1 Directives

では,

IS

(International Standard)

又は ISP

(International Standardized

Profile

)を各国が国家規格として採用する場合の著作権の扱いを,次のように保証している。

JTC1 Directives

  Annex M の M6.1.4

Once the specification has been approved by JTC 1 as an 
IS or ISP, it will be published following ISO and IEC 
standing copyright policy, i.e.: 
・  Copyright for publication of the specification as an

International Standard (IS) or an International 
Standardized Profile (ISP) is granted to ISO/IEC 
and any National Body which transposed such IS or 
ISP into a national standard.

JTC1

通達  附属書 M M6.1.4

仕様が,JTC1 によって IS 又は ISP として承認され
ると,ISO/IEC の通常の著作権等に基づいて出版さ
れる。 
・  国際規格(IS)又は国際規格相当(ISP)として

出版する場合の著作権は,ISO/IEC,及びこれ
らの IS 又は ISP を国家規格として採用したいか
なる国にも付与される。

B.1

著作権情報

Copyright © 1997-2001 Electronic Data Systems Corporation

Copyright © 1997-2001 Hewlett-Packard Company

Copyright © 1997-2001 IBM Corporation

Copyright © 1997-2001 ICON Computing

Copyright © 1997-2001 i-Logix

Copyright © 1997-2001 IntelliCorp

Copyright © 1997-2001 Microsoft Corporation

Copyright © 2003 Object Management Group

Copyright © 1997-2001 ObjecTime Limited

Copyright © 1997-2001 Oracle Corporation

Copyright © 1997-2001 Platinum Technology, Inc.

Copyright © 1997-2001 Ptech Inc.

Copyright © 1997-2001 Rational Software Corporation

Copyright © 1997-2001 Reich Technologies

Copyright © 1997-2001 Softeam

Copyright © 1997-2001 Sterling Software

Copyright © 1997-2001 Taskon A/S


174

X 4170

:2009 (ISO/IEC 19501:2005)

   

Copyright © 1997-2001 Unisys Corporation

B.2

仕様の使用−条件及び通告

この規格は,次の B.3 以降で定められた条件及び通告に従って,OMG(Object Management Group)仕様

を詳述したものである。この規格は,この規格のいかなる部分もいかなる会社の製品に実装することを確

約するものではない。この規格に含まれる情報は,予告なしに変更されることがある。

B.3

ライセンス

上記にリストした会社は,OMG(Object Management Group)に対し,この規格の複写,配布,修正及び

修正版コピーの配布を実施するための,非独占的,ロイヤルティ免除,全額支払済みの世界ライセンスを

付与した。上記にリストした各著作権保有者は,この規格に定める仕様の使用,又はいかなるコンピュー

タソフトウェアをこの仕様へ合致させる者が,このような著作権保有者の資料に含まれる著作権を侵害し

たとはみなさないことに同意した。

次のすべての契約条件を前提に,この仕様の著作権保有者は,ソフトウェア及びこの仕様に基づく特別

な目的をもつ仕様の作成及び配布を目的とした,並びにこの仕様書のコピー及び配布を目的とした,この

仕様書の使用のための,全額支払済み,非独占的,譲渡不可,永久の世界ライセンス(サブライセンスの

権利はもたない。

)を下記条件を満たすことを条件に,著作権法の下に付与する。

a)

上記で特定した著作権表示と本許可通知との両方がこの仕様のすべてのコピーに表示される。

b)

仕様の使用は,情報目的のために行われ,いかなるネットワークコンピュータにも複写又は提供され

ない,また,いかなる媒体にも提供されない。また,商用を目的とした売買,譲渡はできない。

c)

本仕様の変更はできない。当事者がいずれかの条件に違反した場合は,本限定許可は,予告なしに自

動的に終了する。終了と同時に,当事者は所有又は制御している仕様のいかなるコピーも消去しなけ

ればならない。

B.4

特許

採用者は,OMG 仕様の遵守又は採用のために,特許権をもつ発明の使用が必要とされる可能性がある

ことに注意する必要がある。OMG は,OMG 仕様によってライセンスを求められるような特許を特定する

責任を負わない。また,このような注意が必要となる特許の法的有効性又は範囲の法的調査を実行する責

任を負わない。OMG 仕様は,将来的で助言的なものである。採用を検討するユーザは,特許侵害に対す

る責任に対し,自ら身を守る必要がある。

B.5

一般的な使用制限

この仕様の不正使用は,著作権法,商標法,通信規定及びその法規を侵害するおそれがある。この規格

には,著作権によって保護されている情報が含まれている。無断複写・転載を禁ずる。著作権で保護され

ている情報は,著作権保持者の許可なく,複写,又はいかなる形式若しくは手段(写真複写,録音,テー

プに記録,又は情報記憶装置及び検索システムを含む図形的,電子的,又は機械的な手段)で使用するこ

とはできない。

B.6

保証の放棄

本出版物は正確であると思われるが,現状どおりで提供され,誤り又は誤植が含まれる可能性がある。


175

X 4170

:2009 (ISO/IEC 19501:2005)

Object Management Group

と上記にリストされた会社は,本出版物に関し,権利,請求権又は所有権の保証

に限らず,特定の目的,使用に対する市場性の暗黙の保証,適格性の保証などいかなる種類の保証を明示

的にも暗黙的にも行わない。

Object Management Group

及び上記にリストされた会社は,この規格に含まれる誤りに対し責任はない。

また,たとえ利益,収入,データ又は使用の損失があったとしても,若しくは,このような損害の可能性

の警告を受けていながら,本資料の提供,実施,使用において特定のユーザ又は第三者に損害が及んだと

しても,直接的,間接的,付随的及び特別な場合の結果として起こった損害に対する責任又は保証の責任

はない。

この仕様を用いて開発されるソフトウェアの品質及び性能に関するすべてのリスクは,当事者が負担し

なければならない。本保証の放棄は,この仕様を使用するために当事者に付与されるライセンスの重要な

部分を構成する。

B.7

制限された権利上の慣習

アメリカ政府による使用,複製又は開示は,次に示す条項に規定されている制限に従う。

−  The Rights in Technical Data and Computer Software 条項 DFARS 252.227-7013 の副条項

(c) (1) (ii)

−  Commercial Computer Software-Restricted Rights 条項 48 C.F.R. 52.227-19 の副条項

(c) (1)

及び(2)

− DoD  F.A.R.

補足の 48 C.F.R.227-7202-2 及びその後継条項

− Federal

Acquisition

Regulations

の 48C.F.R.12.212 及びその後継条項

仕様の著作権保持者は上記に示すとおりで,250 First Avenue, Needham, MA 02494, U.S.A.の Object

Management Group

を通し連絡が可能である。

B.8

商標

The OMG Object Management Group Logo®, CORBA®, CORBA Academy®, The Information Brokerage®,

XMI® and IIOP® are registered trademarks of the Object Management Group. OMG™, Object Management

Group™, CORBA logos™, OMG Interface Definition Language (IDL)™, The Architecture of Choice for a

Changing World™, CORBAservices™,CORBAfacilities™, CORBAmed™, CORBAnet™, Integrate 2002™,

Middleware That’s Everywhere™, UML™, Unified Modeling Language™, The UML Cube logo™, MOF™,

CWM™, The CWM Logo™, Model Driven Architecture™, Model Driven Architecture Logos™, MDA™, OMG

Model Driven Architecture™, OMG MDA™ and the XMI Logo™

は,Object Management Group の商標である。

その他のすべての製品又は会社名は,識別の目的だけに使用されており,それぞれの所有者の商標の可能

性がある。

B.9

遵守

上記にリストされた著作権保持者は,Object Management Group(OMG として活動又は OMG の指名によ

って活動を行う)者であり,常に,コンピュータソフトウェアの開発者,供給者又は販売者に対し,仕様

に適合していることを示す認定マーク,商標,又は他の特別な呼称を使用する許可を与えることのできる

唯一の機関である。

本ライセンス条項に従って開発するソフトウェアは,仕様に定めた適用可能な適合ポイントに完全に合

致している場合だけ,この仕様への準拠性又は適合性を主張することができる。適用可能な適合ポイント

に部分的にだけ合致して開発されたソフトウェアの場合は,当該ソフトウェアがこの仕様をベースに開発


176

X 4170

:2009 (ISO/IEC 19501:2005)

   

されたとだけ主張できるが,この仕様に準拠,又は適合していると主張することはできない。Object

Management Group

によってテストスイートが実装され認証された場合は,この仕様を用いて開発されたソ

フトウェアがテストスイートを完全に満足した場合だけ,この仕様に遵守又は適合していると主張するこ

とができる。

B.10

問題報告

すべての OMG 仕様は,継続的にレビューされ改善される。本過程の一部として,読者が次の主ウェブ

ページ上にリストされている“Issue Reporting Form”を使用し,あいまいな点,矛盾点,又は不正確な点

を報告することを奨励する。

http://www.omg.org


177

X 4170

:2009 (ISO/IEC 19501:2005)

附属書 JA

参考)

UML

メタモデルのパッケージ構成及びメタクラス一覧

JA.1

  UML

メタモデルのパッケージ構成


178

X 4170

:2009 (ISO/IEC 19501:2005)

   

JA.2

メタクラス一覧


179

X 4170

:2009 (ISO/IEC 19501:2005)


180

X 4170

:2009 (ISO/IEC 19501:2005)

   


181

X 4170

:2009 (ISO/IEC 19501:2005)

附属書 JB

参考)

参考規格

注記  次に掲げる規格は,ISO/IEC 19501 の箇条 2 (Normative references) で示された引用規格である

が,実際には規格の本文では引用されていない。したがって,この規格では参考規格とする。

1)  JIS X 5740-2:1998

:  ISO/IEC 10746-2:1996 (IDT)

JIS X 5740-2

  開放型分散処理−参照モデル:基盤

ISO/IEC 10746-2

,Information technology−Open Distributed Processing−Reference Model: Foundations

及び ITU-T Recommendation X.902

2)  JIS X 5740-3:1998

:  ISO/IEC 10746-3:1996 (IDT)

JIS X 5740-3

  開放型分散処理−参照モデル:アーキテクチャ

ISO/IEC 10746-3

,Information technology−Open Distributed Processing−Reference Model: Architecture

及び ITU-T Recommendation X.903

3)  JIS X 0137-1:2003

:  ISO/IEC 15474-1:2002 (IDT)

JIS X 0137-1

  CASE データ交換形式−CDIF フレームワーク−第 1 部:概要

ISO/IEC 15474-1

,Information technology−CDIF framework−Part 1: Overview

4)  JIS X 0137-2:2003

:  ISO /IEC 15474-2:2002 (IDT)

JIS X 0137-2

  CASE データ交換形式−CDIF フレームワーク−第 2 部:モデル化及び拡張性

ISO /IEC 15474-2

,Information technology−CDIF framework−Part 2: Modelling and extensibility

5)  JIS X 0138-1:2004

:  ISO/IEC 15475-1:2002 (IDT)

JIS X 0138-1

  CASE データ交換形式−CDIF 転送形式−第 1 部:構文及び符号化の一般規則

ISO/IEC 15475-1

,Information technology−CDIF transfer format−Part 1: General rules for syntaxes and

encodings

6)  JIS X 0138-2:2004

:  ISO/IEC 15475-2:2002 (IDT)

JIS X 0138-2

  CASE データ交換形式−CDIF 転送形式−第 2 部:構文 SYNTAX.1

ISO/IEC 15475-2

,Information technology−CDIF transfer format−Part 2: Syntax SYNTAX.1

7)  JIS X 0138-3:2004

:  ISO/IEC 15475-3:2002 (IDT)

JIS X 0138-3

  CASE データ交換形式−CDIF 転送形式−第 3 部:符号化 ENCODING.1

ISO/IEC 15475-3

,Information technology−CDIF transfer format−Part 3: Encoding ENCODING.1

8)  ISO/IEC 15476-1:2002

ISO/IEC 15476-1

,Information technology−CDIF semantic metamodel−Part 1: Foundation

9)  ISO/IEC 15476-2:2002

ISO/IEC 15476-2

,Information technology−CDIF semantic metamodel−Part 2: Common

10)  ISO/IEC 15476-3:2006

ISO/IEC 15476-3

,Information technology−CDIF semantic metamodel−Part 3: Data definitions

11)  ISO/IEC 15476-4:2005

ISO/IEC 15476-4

,Information technology−CDIF semantic metamodel−Part 4: Data models


182

X 4170

:2009 (ISO/IEC 19501:2005)

   

12)  ISO/IEC 15476-6:2006

ISO/IEC 15476-6

,Information technology−CDIF semantic metamodel−Part 6: State/event models


183

X 4170

:2009 (ISO/IEC 19501:2005)

附属書 JC

参考)

用語集

注記  この用語集は,対応する国際規格 ISO/IEC 19501 において巻末に掲載されている用語集である。

規格本体又は附属書を構成するものではない。したがって,この規格では参考情報として掲載

することにした。

用語集

この用語集は,統一モデル化言語(UML)及びメタオブジェクトファシリティ(MOF)を記述するため

に用いる術語を定義する。UML 及び MOF 固有の専門用語に加え,OMG 標準,及びオブジェクト指向分

析・設計方法論に関連する用語を含む。その上,オブジェクトリポジトリ及びメタデータ管理系の領域ま

でも含める。用語集の見出し語は,アルファベット順に並べる。また,MOF 固有の見出し語は

[MOF]

とし

て識別される。

記法の規約

この用語集の見出し語は,通常,小文字で始められる。語句が標準の慣例で大文字で始められるものに

ついて,頭の文字を大文字で表す。頭字語は,伝統的に小文字で表すものでない限り,すべて大文字で表

す。

複数の語句からなる用語の一部が[ ]括弧で囲まれるときは,その用語を参照する場合,その語句は選

択可能とすることを示す。例えば,ユースケース[class]は,単にユースケースとして参照する。

この用語集では,次の規約が用いられている。

・  対比語:<用語>