JISX4170:2009 オープン分散処理－統一モデル化言語（ＵＭＬ）１．４．２版

X 4170：2009 (ISO/IEC 19501：2005)

（1）

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ページ

序文 ··································································································································· 1

1 適用範囲 ························································································································· 1

2 参考規格 ························································································································· 2

3 一般情報 ························································································································· 2

4 UML意味論 ···················································································································· 3

第1区分背景 ···················································································································· 3

4.1 序論 ···························································································································· 3

4.2 言語アーキテクチャ ······································································································· 3

4.3 言語形式 ······················································································································ 6

第2区分基盤 ···················································································································· 6

4.4 Foundation 基盤パッケージ························································································· 6

4.5 Core コアパッケージ ··································································································· 7

4.6 Extension Mechanisms 拡張機構パッケージ ································································ 39

4.7 Data Types データ型パッケージ ·················································································· 44

第3区分振る舞い要素 ······································································································· 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

第4区分一般機構 ············································································································· 85

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

5 UML 記法ガイド ··········································································································· 90

第1区分背景 ··················································································································· 90

5.1 序論 ··························································································································· 90

第2区分図式要素 ············································································································· 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）

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ページ

5.10 式 ····························································································································· 93

5.11 ノート ······················································································································· 93

5.12 型とインスタンスとの対応 ···························································································· 94

第3区分モデル管理 ·········································································································· 95

5.13 パッケージ ················································································································· 95

5.14 サブシステム ·············································································································· 96

5.15 モデル ······················································································································· 97

第4区分一般拡張機構 ······································································································· 98

5.16 制約及び注釈 ·············································································································· 98

5.17 要素特性 ···················································································································· 99

5.18 ステレオタイプ ·········································································································· 101

第5区分静的構造図 ········································································································· 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）

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ページ

5.46 関連クラス ················································································································ 125

5.47 N項関連 ··················································································································· 125

5.48 合成集約 ··················································································································· 126

5.49 リンク ······················································································································ 127

5.50 はん（汎）化 ············································································································· 128

5.51 依存 ························································································································· 129

5.52 派生要素 ··················································································································· 131

5.53 インスタンス接続 ······································································································· 131

第6区分ユースケース図（用例図） ···················································································· 131

5.54 ユースケース図 ·········································································································· 131

5.55 ユースケース ············································································································· 132

5.56 アクタ ······················································································································ 132

5.57 ユースケース関係 ······································································································· 133

5.58 アクタ関係 ················································································································ 133

第7区分相互作用図 ········································································································· 134

5.59 コラボレーション（協調） ··························································································· 134

5.60 シーケンス図（系列図） ······························································································ 135

5.61 オブジェクト生存線 ···································································································· 136

5.62 活性区間 ··················································································································· 137

5.63 メッセージ及び刺激 ···································································································· 137

5.64 遷移時間 ··················································································································· 138

第8区分コラボレーション図（協調図） ·············································································· 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

第9区分ステートチャート図（状態図） ·············································································· 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）

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ページ

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

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

日本工業規格 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は，対応国際規格にはな

い事項である。

適用範囲

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

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

言語を提供することを目的に，統一モデル化言語（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の略

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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に基づき，一致していることを示す。

参考規格

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

一般情報

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

した。）

注記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 矢線表記の区分

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

実線矢線

閉矢じり実線矢線

開矢じり実線矢線

半開き矢じり実線矢線

破線矢線

開矢じり破線矢線

白抜き閉矢じり破線矢線

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

UML意味論

第1区分背景

4.1

序論

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

4.2

言語アーキテクチャ

4.2.1

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

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

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

のような利点がある。

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

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

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

Group（業界団体）メタオブジェクトファシリティ（MOF）］をUMLメタモデルと連携させるための

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

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

− メタメタモデル

− メタモデル

− モデル

− ユーザオブジェクト（ユーザデータ）

これらの層の機能を，表1に示す。

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

層

記述

例

メタメタモデル

メタモデル化アーキテクチャの基盤。
メタモデルを指定するための言語を
定義する。

MetaClass，MetaAttribute，MetaOperation

メタモデル

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

Class，Attribute，Operation，Component

モデル

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

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

ユーザオブジェクト
（ユーザデータ）

モデルのインスタンス。特定の情報領
域を定義する。

<日本産業社̲配当̲98789>，654.56，
指値̲売り̲する，<株式̲相場̲サーバ̲32123>

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

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

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

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

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

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

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

例1 MetaClass

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

例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) 緩い（又は“厳密ではない”）メタモデル化では，Mnレベルのモデルは，Mn＋1レベルのモデル

のインスタンスとする。厳密なメタモデル化では，Mnレベルのモデルの各々の要素は，Mn＋1

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

4.2.2

パッケージ構造

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

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

パッケージとしている。UMLのメタモデルは，図1に示すような最上位パッケージに分解される。

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

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

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

図4−Foundationパッケージ

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〜図9のように図式記法で示す。図5は，メタモデルの構造的

な根幹を形成するモデル要素を示す。図6は，関係を定義するモデル要素を示す。図7は，依存を定義す

るモデル要素を示す。図8は，各種の分類子を示す。図9は，テンプレートパラメタ，表示要素及び注釈

の補助要素を示す。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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»）。

関連

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の両方をもつ。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

4.5.2.5

AssociationEnd 関連端

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

関連

associationEnd 限定子属性を所有する選択可能なAssociationEndを示す。属性は，

AssociationEndの一部であるか（この場合は限定子となる。），又はClassifier
の一部となる（この場合は，Featureからの継承で，素性となる。）が，両方を兼
ね備えることもある。

4.5.2.7

BehavioralFeature 振る舞い素性

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

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

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

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

属性
isQuery

Featureの実行がシステムの状態を不変に保つかどうかを指定する。真は，状態が
変化しないことを示し，偽は，副作用が発生することができることを示す。

name

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

関連

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のアドレス空間内でその制御に従って動作す
る。このようなクラスを，非公式に受動クラスと呼ぶ。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ステレオタイプ

«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は抽象メタク

ラスとする。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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とする。次の要素は，その下位クラスである分類子によっ

て継承される。

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

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

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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群の集合。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ステレオタイプ

«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の集合は，通常異なる。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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の一つとの間

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

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

メタモデルでは，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は実
現の一部となる。区別がなされない場合には，値の既定値は偽とする。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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の一種を定義する。

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

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

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

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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のただ一つの値がある。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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は，抽象

メタクラスとする。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

属性

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を参照する。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

属性

discriminator

Generalizationリンクが属する区分を示す。与えられた上位クラスの
GeneralizableElementを共有するすべてのGeneralizationリンクは，その
区別子名によって互いに素な集合に分割される。同じ区別子名をもつ各リンク集合
である各区分は，上位クラスのGeneralizableElementの特化の直交次元を表
現する。区別子は，一意でなくてよい。空文字列も，一つの区分名とみなされるの
で，すべてのGeneralizationリンクは区別子をもつ。同一の上位クラスをもつ
GeneralizableElementのリンクの集合がすべて同一の名前をもつ場合，
Generalizationリンクの下位クラスが上位クラスを特化する
GeneralizableElementとなり，そのインスタンスはすべて上位クラスの正当な
インスタンスとなる。そうでない場合には，上位クラスの間接インスタンスは，区
分のメンバの少なくとも一つの要素の（間接又は直接の）インスタンスでなければ
ならない。

関連

child

上位クラスの

GeneralizableElement

の特化版である

GeneralizableElementを示す。

parent

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

powertype

Generalizationで表現されたはん（汎）化次元に沿って，下位クラス要素のベ
キ型として働くClassifierを示す。したがって，この下位クラス要素はベキ型
要素のインスタンスとなる。

ステレオタイプ

«implementation»

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

標準制約

complete

上位クラスのインスタンスは，すべて，このはん（汎）化集合内の少なくとも一つ
の下位クラスのインスタンスでなければならないという制約を指定する［同じ区別
子及び同じ上位クラスをもつはん（汎）化の集合に対し適用。］。上位クラスが単一
の区別子をもつ場合，下位クラスのはん（汎）化集合が完全であるとは，上位クラ
スが抽象であることを意味する。はん（汎）化集合が完全であると宣言する意味は，
与えられた区別子をもつすべての下位クラスが宣言されていて，追加は期待されな
いこと［すなわち，はん（汎）化集合は閉じている。］とし，かつ，設計は下位ク
ラスの集合が固定されているとある程度の確信をもって仮定する。それにもかかわ
らず，新しい下位クラスが将来追加されるならば，既存のモデルには逆効果があり，
修正が必要となる。

disjoint

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

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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 モデル要素

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

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

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

メタモデルでは，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集合を示す。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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の集合を含むモデ

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ルの一部分とする。

メタモデルでは，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とする。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

属性

concurrency

同じ受動インスタンス（すなわち，isActiveが偽であるClassifierから発生
するインスタンス。）への並行的な呼出しの意味論を指定する。能動インスタンス
は，自分自体のOperationへのアクセスを制御するので，この特性は，通常は，
（UMLで要求されているわけではないが。）sequentialに設定される。

可能性を次に示す。
・ sequential：呼出し側は，（任意の逐次Operationに関し）一つの

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

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

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

・ concurrent：並行スレッドからの多重呼出しが，（任意の並行Operationに

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

isAbstract

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

isLeaf

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

isRoot

真の場合，クラスは同じ操作の宣言を継承してはならない。偽の場合，クラスは同
じ操作の宣言を継承してもよい（しかし，継承しなくともよい。）。宣言は合致しな
ければならず，クラスは継承した操作宣言を修正してはならない。

タグ付き値

semantics

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

4.5.2.31 Parameter パラメタ

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

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

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

する。

属性

defaultValue

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

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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は，抽

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

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

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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は，抽象メタクラスとする。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

属性

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の実引数。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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は解説的内容であるため，この規格では不要であり，不採用とした。）

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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メタモデル要素又は標準要素の名前と衝突してはならない。

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

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

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

者，納期，進ちょく（捗）状況など］，コード生成情報（最適化レベル，コンテナクラスなど）のような特

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

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

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

規則がプロファイル内で形式的に定義されている（例えば，制約表現に対し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の図式記法に表現されている。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

図10−Extension Mechanismsパッケージ

4.6.2.1

Constraint 制約（4.5.2.13の拡張）

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

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

その言語は，（OCLのように）制約を記述するために特に設計されたものとすることもできるし，プロ

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

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

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

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

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

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

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

造の定義は，他のメタモデル要素に対する正構造記述と同じように行える。

属性
body

制約を定義する論理式。式は，指定された言語の文字列として書き表す。モデルが
適格であるためには，システムの安定時，すなわち原子的操作の実行中ではないと
きにはいつでも，制約を受ける要素のインスタンスを評価するとこの式からは必ず
真値が返されなければならない。

制約がステレオタイプに付加されているとき，その制約の適用範囲はUMLメタモデ
ルであり，その制約が定義されているM1モデルに対してではない。これはUMLメ
タモデルを明示的に移入する必要がないことを意味する。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

関連

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パッケージにまとめられる。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

属性

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 タグ付き値

タグ付き値は，タグ定義に適合する任意のモデル要素に対して情報を付加することを可能にする。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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に表現されている。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

図11−Data Typesパッケージの主要部

図12−Data Typesパッケージの式部

メタモデルでは，データ型はクラスの属性の型を宣言するのに用いられる。それらは図中の文字列とし

て現れるのであって，独立した“データ型”アイコンとして表示されるわけではない。そうすることで，

図の大きさを小さくできる。しかし，データ型の特定の名前が複数回登場したとしても，それらはすべて

同一のデータ型を示している。

これらのデータ型は，UMLの定義に使用されているものであり，UML利用者によって使われるデータ

型を意味しているわけではない。利用者向けのデータ型は，メタモデル内で定義されたDataTypeメタク

ラスのインスタンスである。

4.7.2.1

ActionExpression 動作式

動作式は，その評価結果が動作の実行となる式とする。

4.7.2.2

AggregationKind 集約種別

集約種別は，そのAssociationがどの種類の集約かを指定する列挙型とする。関連の終点に置かれた

場合，関連の終点から始点への関係を指定する。AggregationKindは，次の値をとる列挙型を定義する。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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が受入れ可能な変更を

指定する列挙型を定義する。その値を次に示す。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

changeable

変更に関しての制限がない。

frozen

対象オブジェクトの生成及び初期化以後において，その対象オブジェクトの値が変
更されることを許さない。他方の端点のOperationは値を変更してもよい。

addOnly

多重度が固定でない場合，その端点のオブジェクトの値を任意の時点で追加しても
よいが，一度生成された値をその端点から削除することは許さない。他方の端点へ
のあるOperationがその値を変更することはあり得る。

4.7.2.8

Expression 式

メタモデルでは，Expressionは，与えられた文脈で実行されるとインスタンスの集合（空を含む。）

を結果として返す文を定義する。各Expressionは，それが評価される環境を変更することはない。式は，

式を表す文字列及びその文字列を評価するときに用いられる解釈言語の名前を含む。

属性

language

その式の本体を表現している言語の名前を指定する。式の解釈は言語に依存する。
言語の名前が省略された場合，UMLにおいてはその式に対する解釈は与えられな
い。

body

与えられた言語によって表現された，その式に対するテキスト本体。

事前定義の言語の名前には次のものが含まれる。

OCL

オブジェクト制約言語OCL（箇条8を参照）。

（空文字列）これは自然言語の文を表している。そのような場合，明らかに形式
仕様ではなく人間向けの情報を意図している。

一般に，言語名は言語仕様書に現れているとおりのつづりで大小文字区別を厳密に表記することが望ま

しい。例えば，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 位置参照

位置参照は，振る舞いシーケンス中に拡張ユースケースを挿入する位置を指定する。指定方法は，コー

ド中の行若しくは行の範囲，状態マシン中の状態若しくは状態の集合，又は別の記述方式の仕様書におけ

る何らかの手段でよい。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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が引数を提供しているのか，及び

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

／又は，返却値を返しているのかを指定する列挙型を定義する。列挙型の値を次に示す。

入力用の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のインスタンスは，テキストの部分を定義する。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

対象要素と同じパッケージ内に宣言された要素から対象要素を参照したり使用し
たりできる。

第3区分振る舞い要素

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パッケージは，

プロセス群をモデル化するために使用される状態機械の特殊な場合を定義する。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

図17−Common 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。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

関連

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：呼出し側が操作の実行の完了を待たないですぐに継続することを示す。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

関連

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 インスタンス

モデル要素であるインスタンスは，一群の操作が適用され，それらの操作の効果を格納する状態を保持

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

する実体を定義する。

メタモデルでは，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

一個のリンクに適用される制約であり，そのリンクが実行中に生成されることを指
定する。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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のインスタンスで

なければならない。

関連

signal

そのClassifierが処理する用意のあるSignal。

4.9.2.18 ReturnAction 返却動作

返却動作は，呼出し側に値を返すことを結果とする動作とする。

メタモデルでは，ReturnActionは起動者に値を戻すことを引き起こすActionである。その値は，

Actionから継承された引数によって表現される。ReturnActionは，明示的な対象をもたない。

4.9.2.19 SendAction 送信動作

送信動作は，（非同期で）シグナルを送信することを結果とする動作とする。シグナルは，

objectSetExpressionを介して受信側の集合に向けて送信することもできるし，何らかの外部機構に

よって定義された不特定の受信側の集合に暗黙的に送信することもできる。例えば，シグナルが例外であ

る場合，受信側オブジェクトは実行時システム機構によって決定される。

メタモデルでは，SendActionはActionとする。個々のSendActionは発行すべきSignalと関連

付けられ，その実引数はActionから継承された引数の関連によって指定される。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

関連

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である。したがって，明示的な対象は存在しない。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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群は，その

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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群などが果たす

役割である。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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群の数。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

関連

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。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

InteractionInstanceSetの文脈を定義する
CollaborationInstanceSet。

participating-Stimulus

CollaborationInstanceSetの実行に参加するStimulus群。

interaction

Stimulus群が適合する相互作用パターンを定義するInteraction。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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として表される。そのユースケースモデルのユースケース及びアクタ

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

は，最上位レベルのパッケージのものと同じになる。

次の箇条では，Use Casesパッケージの抽象構文を示す。

4.11.2 抽象構文

Use Casesパッケージの抽象構文を，図21に図式記法で示す。

図21−Use 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 拡張

拡張関係は，ユースケースのインスタンスが，拡張するユースケースで定義された追加の振る舞いによ

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

って拡張されてよいことを定義する。

メタモデルでは，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のインスタンスによって実

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

行される動作の系列を規定する。動作は状態の変化及び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を実行するためにどのように相互作用するかを

定義する。

関連

Operation

その起動が呼出しイベントを引き起こす操作を示す。

ステレオタイプ

«create»

«create» は，イベントを受け取るインスタンスがまさに生成されたことを示すス
テレオタイプ付けされた呼出しイベントとする。状態機械については，状態機械の
最上位レベルで初期遷移にトリガをかける（そして初期遷移に適用される唯一のト
リガとする。）。

«destroy»

«destroy» は，イベントを受け取るインスタンスが削除されることを表すステレオ
タイプ付けされた呼出しイベントとする。

4.12.2.2 ChangeEvent 変更イベント

変更イベントは，一つ以上の属性又は関連の値の変化の結果として明示的な論理式が真となったとき生

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

じるイベントをモデル化する。変更イベントは，暗黙的に引き起こされるのであって，何らかの明示的な

変更イベント動作の結果ではない。

変更イベントは，ガードと混同されないことが望ましい。変更イベントに関連する論理式が，概念的に

はそれが真になるまで連続的に評価されるのに対して，ガードはイベントがディスパッチされるときだけ

に評価される。生成されるイベントは，論理式がその後偽に変わっても，それが消費されるまで残る。

属性

changeExpression

変更イベントを規定する論理式。

4.12.2.3 CompositeState 合成状態

合成状態は，一つ以上の他の状態頂点（状態，擬似状態など）を含んだ状態とする。合成状態と包含さ

れている状態頂点との間の関連は合成集約関連とする。したがって，状態頂点は一つの合成状態の一部分

としかならない。

合成状態に包含される状態は，合成状態の下位状態と呼ばれる。それが他のいかなる状態にも含まれな

い場合直接の下位状態と呼ばれる。そうでない場合，推移的に入れ子になった下位状態として参照される。

CompositeStateは，Stateの下位とする。

関連

parameter

イベントによって定義されるパラメタの並び。

4.12.2.5 FinalState 最終状態

最終状態は，内包する合成状態が完了することを示す特別な種類の状態とする。内包する状態が最上位

状態ならば，状態機械全体の完了を意味する。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

最終状態は，出力遷移をもたない。

FinalStateは，Stateの子とする。

4.12.2.6 Guard ガード

ガードは，遷移の発火に対する細かい制御として遷移に付与された論理式とする。ガードは，状態機械

よりイベントのインスタンスがディスパッチされたとき評価される。そのときガードが真の場合，遷移は

可能となり，そうでなければ遷移不可となる。

ガードは，副作用のない純粋な式であることが望ましい。副作用をもつガード式は，不適格である。

Guardは，ModelElementの下位とする。

属性
expression

ガードを規定する論理式。

4.12.2.7 PseudoState 擬似状態

擬似状態は，状態機械グラフにおける様々な型の一時的頂点の抽象化とする。一般的にこれらは，複数

の遷移をより複雑な状態遷移経路に結び付けるために使われる。例えば，並行分岐擬似状態に入る遷移を，

その並行分岐擬似状態から抜ける遷移の集合と結び付けることによって，並行する遷移先の状態の場合に

導く複合遷移を得る。

次の種類の擬似状態が定義されている。

− 初期擬似状態は，合成状態のデフォルト状態への単一遷移における遷移元であるデフォルト頂点を表

現する。合成状態には一つしか初期頂点が存在し得ない。

− 深い履歴は，この擬似状態を直接含む合成状態の最後の活性化構成を表現する簡略記法とする。すな

わち，合成状態が最後に抜けられたときに活性であった状態構成になる。合成状態は一つしか深い履

歴点をもち得ない。遷移はデフォルトの深い履歴状態への履歴接続子から始まってよい。この遷移は，

合成状態が以前活性であったことがない場合に生じる。

− 浅い履歴は，この包含する状態の最後の活性化下位状態（しかし，下位状態の下位状態ではない。）を

表現する簡略記法とする。合成状態は，一つしか浅い履歴頂点をもち得ない。浅い履歴頂点に入って

くる遷移は，状態の最も最近の活性化下位状態への入力遷移と等価になる。遷移は，初期の浅い履歴

状態への履歴接続子から始まってよい。この遷移は，合成状態が以前活性であったことがない場合に

生じる。

− 同期合流頂点は，直交する他領域にある起点頂点から発散する幾つかの遷移をまとめるのに役に立つ。

同期合流頂点に入ってくる遷移はガードをもつことができない。

− 並行分岐頂点は，入力遷移を直交頂点で終了する二つ以上の遷移へ分散するのに役立つ。並行分岐か

ら出力する断片は，ガードをもってはならない。

− 連結頂点は，複数の遷移を結び付けるために使われる意味論非依存な頂点とする。これは状態間の複

合遷移経路を構築するために使われる。例えば，連結は複数の入力遷移を共有遷移経路を表現する単

一の出力遷移に変換（併合）するために使われる。逆に，入力遷移を違ったガード条件をもつ複数の

出力遷移に分離するためにも使うことができる。これは静的条件分枝を実現する（この場合，偽と評

価されるガード条件をもつ出力遷移は無効となる。“else”というガードが一つの出力遷移に対して

定義されてよい。この遷移は，他の遷移に付けられたすべてのガードが偽となった場合，有効となる。）。

静的条件付分枝は，（次に示す）選択頂点によって実現される動的条件付分枝とは異なる。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

− 選択頂点は，そこに達したとき，結果としてその出力遷移のガードの動的な評価が起こる。これは，

動的条件付分枝を実現する。その経路をとるかの決定が，完了までの実行可能列の同じステップで行

われる前の動作結果の関数となる複数の出力経路への遷移分離を許す。二つ以上のガードが真と評価

されるならば，任意の一つが選ばれる。一つも真と評価されないならば，モデルは不適格とみなされ

る（これを避けるために，すべての選択頂点に対して“else”ガードをもった一つの出力遷移を定義

することが勧められる。）。選択頂点は，（上で示した）連結頂点に基づく静的分枝点とは区別されるこ

とが望ましい。

PseudoStateは，StateVertexの下位とする。

属性

kind

PseudoStateの詳細な型を決定する。initial，deepHistory，
shallowHistory，join，fork，junction又はchoiceのどれかとする。

4.12.2.8 SignalEvent シグナルイベント

シグナルイベントは，特定の（非同期）シグナルの受信を表現する。シグナルイベントのインスタンス

はそれを生成した動作（例えば，送信動作）と混同しないほうがよい。

SignalEventは，Eventの下位とする。

関連

deferrableEvent

（消費されず）状態の外への遷移にトリガをかけない場合，状態機械に保持さ
れるべき候補であるイベントの並び。

entry

この状態に到達するためにとられる遷移にかかわらず，その状態へ入力すると
きは常に実行される活動であり，その定義は選択的とする。定義されている場
合，その状態で実行されるどのような内部活動又は遷移に先行して，入場動作
が常に実行され，完了する。

exit

この状態から抜けるどの遷移であっても，その状態を出るときは常に実行され
る活動であり，その定義は選択的とする。定義されている場合，すべての内部
活動及び遷移動作が実行を完了したあとにだけ，退場動作は常に実行され，完
了する。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

doActivity

その状態に存在している間実行される選択的活動。実行はこの状態に入ったと
き開始し，それ自身で終了するか，この状態を出るときのどちらか早いほうに
終了する。

internalTransition トリガをかけられた場合，この状態からの入退場なしで生じる遷移の集合。し

たがって，これらは状態変化を生じさせない。これは，その状態の入場条件，
退場条件のどちらも起動されないことを意味する。これらの遷移はたとえ状態
機械がこの状態で一つ以上の領域に入れ子になっていたとしても行うことが
できる。

4.12.2.11 StateMachine 状態機械

状態機械は，ある動的モデル要素のすべての可能な振る舞いを記述した仕様とする。振る舞いは，一連

のイベントインスタンスをディスパッチすることによってトリガをかけられる一つ以上の結合した遷移線

によって相互接続された，状態ノードのグラフをたどることとしてモデル化される。たどっている間，状

態機械はその各種要素に関連する一連の動作を実行する。

StateMachineは，最上位レベルの状態を表現するStateへの合成関係と，遷移の集合をもつ。これ

は，状態機械が遷移及び最上位状態を所有することを意味する。他のすべての状態は，最上位状態を根と

する状態包含階層を通して推移的に所有される。Model Elementへの関連は，状態機械の文脈を提供す

る。よく見られる文脈関係では，状態機械が分類子のライフサイクルを記述するために使われる。

関連

context

振る舞いがこの状態機械によって規定されるモデル要素への関連。モデル要素は，
複数の状態機械を含んでよい（ただし，ほとんどの目的には一つで十分になる。）。
各状態機械は，選択的にただ一つのモデル要素によって所有される。

top

状態包含階層の根である最上位レベルの状態を示す。あらゆる状態機械には，ただ
一つの最上位状態が存在する。

transition

状態機械によって所有される遷移の集合。内部遷移はその包含状態によって所有さ
れ，状態機械によって所有されるものではない。

4.12.2.12 StateVertex 状態頂点

状態頂点は，ステートチャートグラフにおけるノードの抽象化とする。一般に，任意個の遷移の遷移元

又は遷移先になることができる。StateVertexは，ModelElementの下位とする。

関連

referenceState

参照される状態を経路名（状態の名前と，それが包含するすべての状態の後続名と
を，最上位状態まで結合することによって定めた名前）として表現する。

4.12.2.14 SubmachineState 下位機械状態

下位機械状態は，再利用及びモジュール化を容易にする構文的便宜とする。これは，他の状態機械によ

るマクロ的な展開を意味する略記法であり，合成状態と意味的に等価になる。挿入される状態機械は参照

状態機械と呼ばれ，下位機械状態を包含する状態機械は包含状態機械と呼ばれる。同じ状態機械が一つの

包含状態機械の文脈において一度以上参照されるかもしれない。要するに，下位機械状態は，一つ以上の

入退場点をもつ状態機械“サブルーチン”に対する“呼出し”を表現する。

入退場点はスタブ状態として指定される。

SubmachineStateは，Stateの下位とする。

関連

entry

（Stateから継承された）起動される動作を規定する。

4.13.2.2 ActivityGraph アクティビティグラフ

アクティビティグラフは，状態機械の特別なケースであり，図を構成する動作間の制御フロー及びオブ

ジェクトフローによって，計算プロセスを定義する。その主眼は，状態機械の意味を拡張するものではな

く，計算プロセス及び組織プロセスにおいて，コンピュータ制御フロー及びオブジェクトフローのモデル

化に便利な簡略記法を定義する。

アクティビティグラフの第一の目的は，一つ以上の分類子を含む活動又はプロセスの状態を記述するこ

とである。アクティビティグラフは，パッケージ，分類子（ユースケースを含む。），振る舞い素性に添付

することができる。状態機械と同じく，（アクティビティグラフからの）出力遷移がイベントによって明示

的にトリガをかけられないのであれば，それは含まれる動作の完了によって暗黙にトリガをかけられる。

下位活動状態とは，入れ子になった活動を表現しており，一定の持続時間をもち，内部的には動作又は更

に下位の活動の集合で構成される。すなわち，下位活動状態とは，活動の下位の（アクティビティ）グラ

フを埋め込んだ“階層化された動作”であり，最終的には個々の独立した動作に分割される。

判断及び並行活動をモデル化するために，連結，分岐，合流及び同期を用いることができる。

アクティビティグラフは，Partitionという概念を含んでおり，達成に対して責任を負う実世界の組

織と同様，様々な基準に従って状態を編成することができる。

アクティビティグラフを作成することによって，ビジネスプロセスエンジニアリング及びワークフロー

モデル化のための，組織のモデル化が可能となる。そのときのイベントは，あるタスク（仕事）の終了と

いった，システム内部から発生するものが多いが，顧客からの電話のような，システム外部からのものも

ある。アクティビティグラフは，完全な相互作用モデルが必要でないときに，システムモデル化に適用し

て，操作及びシステムレベルプロセスの動きを規定することもできる。

関連

type

インスタンスを特徴付けるClassifierInStateのための分類子を示す。

instate

ClassifierInStateである分類子のインスタンスを特徴付ける状態を示す。その
状態は，対応する分類子が有効な状態でなければならない。直交状態にあるオブジ
ェクトを参照するとき，このClassifierInStateは複数の状態をもつことがあ
る。

4.13.2.5 ObjectFlowState オブジェクトフロー状態

オブジェクトフロー状態は，アクティビティグラフにおける動作間のオブジェクトフローを定義する。

ある特定の分類子のインスタンスは，オブジェクトフローが占有されているときに利用可能であるが，更

に，それが特定の状態になっている場合も許す。

ある動作状態において，その状態の完了にトリガをかけられたオブジェクトフロー状態を用いることに

よって，動作によるオブジェクトの生成をモデル化することができる。次の動作状態において，そのオブ

ジェクトを使用するには，オブジェクトフロー状態からの出力遷移を，その後続の動作状態への入力遷移

として連結することによってモデル化できる。一般に，各動作は，オブジェクトを別個のオブジェクトフ

ロー状態としてモデル化される状態に位置付ける。

属性
isSynch

オブジェクトフロー状態が同期状態として用いられるかどうかを指定する論理値。

関連

type

オブジェクトの分類子を指定する分類子を指す。それ（型）は，オブジェクトの状
態及び分類子を規定するClassifierInStateとなり得る。

parameter

出力又は入力を求めるオブジェクトを提供するパラメタを指し示す。

ステレオタイプ

«signalflow»

«signalflow» は，Signalを型としてもつObjectFlowStateのステレオタイプ
である。

4.13.2.6 Partition 区分

区分は，アクティビティグラフの状態をグループ分けするための機構とする。区分は，ビジネスモデル

における組織単位に対応することがある。区分を用いて，アクティビティグラフの複数の状態の中で，特

性又は資源を割り当てることができる。特に，Partitionはモデルの動的意味論に影響を与えることは

ないが，様々な目的のため特性及び動作を割り当てるのに役立つ。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

関連

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利用者には必要はないので，こ

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

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

4.13.4 詳細意味論

注記（対応国際規格では，4.13.4は解説的内容であるため，この規格では不要であり，不採用とし

た。）

4.13.5 注記

注記（対応国際規格では，4.13.5は解説的内容であるため，この規格では不要であり，不採用とし

た。）

第4区分一般機構

ここでは，モデルに対して一般的に適用可能な機構について定義する。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に示す図式記法で表される。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

図32−Model Managementパッケージ

4.14.2.1 Dependency 依存（4.5.2.15の拡張）

UMLプロファイルのモデル化において依存は，固有の拡張をもつ。

ステレオタイプ

«modelLibrary»

この依存は，供給者パッケージがプロファイルと関連のあるモデルライブラリ
として使用されていることを意味する。クライアントはプロファイルとしてス
テレオタイプ化したパッケージであり，供給者は共有される（クラス及びデー
タ型といった）モデル要素を含む非プロファイルのパッケージである。

«appliedProfile»

この依存は，どのプロファイルがパッケージに適用可能であるかを指し示すと
き使用する。おおむね，クライアントは通常のパッケージ又はモデルであるが
（ただし，他種別のパッケージということもあり得る。），供給者はプロファイ
ルパッケージである。これは，そのプロファイルが，推移的にクライアントパ
ッケージ内に含まれるモデル要素（クライアントパッケージ自身も含む。）へ
適用されることを意味する。

4.14.2.2 ElementImport 要素移入

要素移入は，他のパッケージを移入した結果としてパッケージ内の名前空間に含まれるモデル要素の可

視性及び別名を定義する。

メタモデルでは，ElementImportはPackageと移入されたModelElementとの間の関係を具体化す

る。それは移入されたModelElementの名前及び可視性の再定義を許す。すなわち，そのModelElement

には，移入するパッケージ内で使うための別名及び／又は新たな可視性を与えてもよい。省略時は，別名

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

はなく（元の名前が使われる。），また，移入するパッケージと関連のある私的可視性となる。

属性

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に関して可視性をもつ。ただし，これは，

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

その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サブシステムは，サブシステム包含階層の最上位を表す。すな
わち，モデル化する全物理システムの境界を表現するモデル要素である。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

タグ定義

{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は解説的内容であるため，この規格では不要であり，不採用とし

た。）

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

UML 記法ガイド

第1区分背景

注記［対応国際規格では，箇条5の第1区分（背景）は解説的内容であるため，この規格では不要

であり，不採用とした。］

5.1

序論

注記（対応国際規格では，5.1は解説的内容であるため，この規格では不要であり，不採用とした。）

第2区分図式要素

5.2

グラフ及びその内容

ほとんどのUML図及び一部の複合記号は，経路によって接続されたノードを包含するグラフである。

情報はほとんど位相関係で表され，記号の大きさ又は位置には関係しない（例外もあり，シーケンス図は

時間距離軸をもつ。）。重要な視覚的な関係には，次の三つがある。

a) 接続（通常は二次元図形への線）

b) 包含（境界をもつ二次元図形記号に関する）

c) 視覚的付加（図式上で，ある記号が他の記号の“近く”にある）

こうした図式関係は，記法の解析された様式としてグラフ内のノードの接続に対応する。

UML記法は，二次元表記を基本としている。（立方体のような）三次元図形の二次元への射影もあるが，

二次元平面へ写しこまれたアイコンとして表現される。近い将来において，真に三次元的な配置及び誘導

がデスクトップコンピュータで可能になるかもしれないが，現在は実用的ではない。

UML記法で使用される基本的な図的構成要素には，次の四つがある。

a) アイコンアイコンは決まったサイズ及び形をもつ図形である。サイズを広げて中に内容を入れるこ

とはしない。アイコンは領域記号の範囲内で，経路の終端として，又は経路に接続したりしなかった

りする記号として表すことができる。

b) 二次元記号二次元記号は可変の高さ及び幅をもち，文字列の並び，他の記号などを中に保持するこ

とができる。多くは，類似した種類又は異なる種類の区画に分割される。経路は二次元記号の境界で

終端されることによって，それに接続したことになる。二次元記号を移動又は削除すると，その記号

の内容，及びその記号に接続している経路すべてが影響を受ける。

c) 経路端点の付加された線分の系列である。概念的には，経路は単一の位相的実体であるが，個々の

線分は図形的に操作することができる。線分がその経路から分離して存在することはない。経路は，

その両端で常に他の図形記号と接続する（ぶら下がる線は存在しない。）。経路は，終端をもつことが

できる。終端とはすなわち，経路の終わりを表すアイコンであり，経路記号の意味を限定する。

d) 文字列文字列は“構文解析されない”形式で，多様な情報を提示する。UML記法においては，記法

上の文字列の使用は，基盤となるモデル情報へ解析可能な構文をもつと仮定する。例えば，属性，操

作，及び遷移に関する構文がある。これらの構文は，ツールの表示上の選択肢によって拡張されるこ

とがある。文字列は，記号の単一の要素，記号の一部，並びの要素（この場合は，並びでの位置が情

報を伝える。），記号又は経路に接続されたラベル若しくは図式上の独立要素になることができる。

5.3

経路の描画

経路は，端点同士がつながっている一連の線分からなる。経路全体は単一の位相的単位である。線分は，

直交線，傾斜線又は曲線とすることができる。ある種の線の引き方の常識が存在する。つまり，すべて直

交線，すべて直線，又は斜め方向だけは曲線を用いる。線のスタイルは，入力するツールによって制限さ

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

れることがある。線分が交差するときは，図式のどの部品から他のどの部品へつながっているか判別が困

難になるため，一方の線分に（電気回路図に見られるような）小さな半円記号を用いて交差させる。この

ようにして，その経路が直接交わらず，また接続もしていないと示すことができる。

［集約及びはん（汎）化のような］幾つかの関係においては，同じ種類の幾つかの経路が一つの記号に

接続されることがある。また，（特定の関係を記述する）状況では，記号に接続した複数の線分は一本の線

分に合流することができるので，そのような記号からのびている経路は，幾つかの経路に樹木のように枝

分かれすることがある。これは純粋に図的表現上の選択肢であって，それぞれの経路は概念的には別個の

ものである。この表現上の選択肢は，合流した線分又は同一でない線分の場合には使用しなくともよい。

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は解説的内容であるため，この規格では不要であり，不採用とした。）

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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記法では，テキストのキーワードを使用するこ

とによって，共通主題（例えば，基底クラスのメタモデル下位クラス，メタモデル基底クラスのステレオ

タイプ，並び要素のグループなど）に基づき複数の変化形を区別する。ユーザ側から見ると，メタモデル

下位クラスとステレオタイプとの間の区別はあまり重要ではないが，ツールの作成者及びメタモデルの実

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

装者には重要である。

一般的な記法では，ギュメ“«»”で囲んでキーワードを使用する。

例 «キーワード»

この規格では，特定の定義済みのキーワードについて記述している。これらのキーワードは，記法にお

いては予約語として扱わなければならない。それ以外はユーザがステレオタイプ名として使用できる。定

義済みキーワードと同じステレオタイプ名を使用することを禁じる。

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 ノート

ノートとは，テキスト情報を含む図的記号とする（埋め込まれた画像を含む場合もある。）。ノートは，

制約，注釈，メソッド本体及びタグ付き値といった，メタモデルから様々なテキスト情報を表示するため

の記法とする。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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−クラスとオブジュクト

ツール利用者の選択肢としては，インスタンス要素を，例えば色又は埋め込みパターンなど異なる図形

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

マーカで自由に代替可能である。

（コラボレーションにおける）役割は，型とインスタンスとのほぼ中間に位置する。インスタンスに似

た点としては，単一の分類子に対する個々の出現を識別する。型に似た点としては，多くの異なるインス

タンスをもつことができる再利用可能な要素を記述する。役割は分類子の区別可能な使用法であるが，そ

れでいて一般的な記述（コラボレーション）の一部でもあり，多くのインスタンスを生成することができ

る。実行時オブジェクトは，ゼロ個以上のクラス及びゼロ個以上の役割に対応することがある。役割の記

法では，その基底分類子を表示してもよい。インスタンスの記法では，その分類子の仕様，役割の仕様，

又は両方ともを記述してもよい。

役割は，名前，コロン及び下線なしでコラボレーションの一部となる型によって示される。インスタン

スは，付加的な名前，付加的な斜線，それに続く役割の並び，コロン，型の並びなどで示される。

図39−役割及びオブジェクト

第3区分モデル管理

5.13 パッケージ

5.13.1 意味論

パッケージは，モデル要素のグループ化とする。パッケージそれ自体は，他のパッケージ内で入れ子に

できる。パッケージは，他種のモデル要素と同様，下位パッケージを含むことができる。すべてのUML

モデル要素は，パッケージに入れて整理することができる。

パッケージはモデル要素を所有し，また，構成制御，格納及びアクセス制御の基礎となる。各要素は単

一パッケージが直接所有するので，パッケージ階層は厳密な木構造になる。しかし，パッケージは，

Permission依存の «import» 及び «access» を用いてモデル化された，他のパッケージを参照できる。そ

して，利用関係はグラフになる。パッケージ間の他の依存関係は，通常，複数要素の間に一つ以上の依存

があることを示す。

5.13.2 記法

パッケージは大きな長方形で表され，その左上隅に小さな長方形（“タブ”）を付加する。これは，通常

のフォルダのアイコンである。

パッケージの内容は，大きな長方形の中に表示することができる。また，内容をパッケージの外側に描

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

画して，包含される要素を線で結ぶという表示もできる。プラス記号（＋）を円の中に描いて，その端点

でコンテナに接続させる。

− 大きな長方形の中にパッケージの内容を表示しない場合は，パッケージ名を長方形の中に置くことが

できる。

− 大きな長方形の中にパッケージ内容を表示する場合は，パッケージ名をタブの中に置くことができる。

キーワード文字列は，パッケージ名の上に置くことができる。既定義ステレオタイプの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 記法

サブシステムは基本的にパッケージと同じ方法で示されるが，大きな長方形の右上隅にさすまた型の記

号を追加する。サブシステムの名前は（省略可能なキーワード，ステレオタイプなどとともに）大きな長

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

方形の中に置かれる。特に，サブシステムの内容を大きな長方形の中に表示する場合などは，サブシステ

ム名及び分岐をタブ（小さな長方形）内に置く。

インスタンス化可能なサブシステムは，その名前の上に文字列 «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 意味論

モデルは，物理システムのあるビューを示す。ゆえに，ある目的を伴う物理システムの抽象化とする。

例えば，利害関係者の置かれるカテゴリに対して，物理システムの振る舞いの側面を記述する。モデルは，

物理システムをこの特定のモデルの目的に沿って完全な形で表現するのに必要なすべてのモデル要素を含

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

む。このモデル内のモデル要素は，パッケージ・サブシステム階層で構成される。階層の最上位パッケー

ジ・サブシステムは物理システムの境界を表現する。

同一の物理システムの異なるモデルは，そのシステムの異なる側面を表示する。予約 «systemModel»

は，物理システムのためのモデル集合全体を包含するモデルに適用できる。

異なるモデル内の要素間の関係は，モデルの自己完結性によって，モデル内容に意味論上の影響を与え

ない。しかし，洗練作業をトレースしたり，モデル間をまたぐ要求のつながりを保持したりするには有用

である。

モデル間の関係は，洗練，移入などを表す。

5.15.2 記法

モデルは，通常のパッケージ記号の大きな長方形の右上隅に小さな三角形を記述して表される。特にモ

デル内容が大きな長方形の中に表示される場合は，三角形をタブ内のモデル名の右に描画してよい。

複数のモデル間の関係は，異なるモデル内の要素間の関係と同様，既知の様々な関係記法を用いて表示

される。特にトレース依存は，«trace» を付けた破線に選択肢として矢じりが開いた形の矢印を付けた開

矢じり破線矢線で記述される。

5.15.3 表示上の選択肢

注記（対応国際規格では，5.15.3は解説的内容であるため，この規格では不要であり，不採用とし

た。）

5.15.4 例

注記（対応国際規格では，5.15.4は解説的内容であるため，この規格では不要であり，不採用とし

た。）

5.15.5 対応付け

注記（対応国際規格では，5.15.5は解説的内容であるため，この規格では不要であり，不採用とし

た。）

第4区分一般拡張機構

この章の要素は，任意のモデル化要素に適用できるはん（汎）用の機構とする。特別の用途の意味論は，

利用者の取り決め，又は特定の制約言語若しくはプログラム言語による解釈に依存する。したがって，そ

れらはUMLに対する拡張可能性の仕組みを構成する。

5.16 制約及び注釈

5.16.1 意味論

制約とは，モデル要素間での意味論関係とする。制約は，この関係で真を維持しなければならない条件

及び命題を規定する。制約が真でない場合，モデルによって記述されているシステムは無効となる（その

結果は，UMLの範囲外である。）。ある種の制約（例えば，関連のxor制約）はUMLで既に定義されてい

る。その他は，ユーザが定義してよい。ユーザ定義制約は，所定の言語における単語で記述され，その構

文及び解釈はツールに任される。制約はモデル要素に対し付加される意味論的情報を表現し，単にモデル

要素のビューに対し付加するものではない。

注釈とは，モデル要素に直接に付加された文字列（人間が判読可能な文書への参照を含む。）とする。注

釈は任意のテキスト情報を一般的に重要と想定される任意のモデル要素に付加するが，意味論的には効果

をもたない。注釈は，判断根拠の説明に用いることができる。

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

に適用可能な特性を表現する。タグ及び値は，いずれも文字列としてコード化される。タグ付き値は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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

図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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

る。ステレオタイプは，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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

第5区分静的構造図

クラス図は，モデルの静的構造，特に，存在物（クラス及び型），その内部構造，及び他のものとの関係

を示す。クラス図は時間情報を示さないが，時間的な振る舞いをもったり記述したりするものを具体化し

た存在を含むこともできる。オブジェクト図は，クラス図に適合するインスタンスを示す。

第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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

立したメタモデルクラス又はClassのステレオタイプである。クラスはクラス図の中で宣言され，他のほ

とんどの図において使用される。UMLは，クラスを宣言し使用するための図的記法，及び他のモデル要素

の中のクラスを参照するためのテキスト形式の記法を提供する。

5.22.1 意味論

クラスは，モデル化されるシステム内の概念を表す。クラスは，データ構造，振る舞い，及び他の要素

との関係をもつ。

クラスの名前は，それが宣言されるパッケージ内で適用範囲をもち，パッケージ内で（クラス名の間で）

一意でなければならない。

5.22.2 基本記法

クラスは，水平線で区分された三つの区画をもち，実線の長方形として描かれる。最初の名前区画は，

クラス名及びそのクラスの（ステレオタイプを含む。）その他の一般的特性を保持する。中間の並び区画は

属性の並びを保持する。最後の並び区画は操作の並びを保持する。

詳細については，5.23，5.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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ただし，はん（汎）化状態の明示的規定はフォント情報に優先する。

特性（メタモデル属性又はタグ付き値）を示す文字列並びを，クラス名の下の波括弧内に置く。この並

びは，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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

− [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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

た。）

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

・ 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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ートの上位クラスになったり関連の終点端になったりする（しかし，テンプレートから他のクラスの一方

向関連は許される。）。テンプレートが通常のクラスの下位クラスだと，そのテンプレート束縛で形成され

るすべてのクラスは，その上位クラスの下位クラスであることを意味する。

仮パラメタ化は，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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

できる。

束縛済み要素は，完全にそのテンプレートによって指定される。したがって，その内容は拡張されては

ならない。例えば，クラスに対する新しい属性又は操作の宣言は許されない。しかし，束縛済みクラスの

下位クラスを定義することができ，その下位クラスは通常の方法で拡張可能となる。

束縛済み要素とそのテンプレートとの関係は，«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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

た。）

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

図67−ステレオタイプ宣言の記法形式

図67における図の例にあるように，ステレオタイプPersistentはUMLのメタ要素Classのステレ

オタイプとなる。TableNameは省略可能なタグであり，その型はStringと呼ばれるモデルの型となる。

ここで，SQLFileはモデルにおけるComponentのインスタンスに対する参照となる。

ステレオタイプのためにアイコンを定義することができるが，アイコンの図的な定義はUMLの有効範

囲外であり，編集ツールによって扱われる。

ステレオタイプ及びタグを指定する代替的で一般的なより簡便な方法が表2及び表3にそれぞれ示して

ある。

表2−ステレオタイプ指定のテーブル形式

ステレオタイプ

基底クラス

親

タグ

制約

記述

アーキテクチャ
要素

Generalizable
Element

N/A

はん（汎）用ステレオタイプ。
アーキテクチャのモデル化
に使われるすべての他のス
テレオタイプの上位ステレ
オタイプとする。

カプセル

Class

アーキテクチ
ャ要素

isDynamic self.isAct

ive = true

アーキテクチャ仕様の構造
化コンポーネントのモデル
化に使われるクラスを示す。

116

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

表3−タグ指定のテーブル形式

タグ

ステレオタイプ

型

多重度

記述

isDynamic

カプセル

UML::Datatypes::Boolean

関連するカプセルクラスが，
動的に生成，解体できるかを
識別するために使われる。

表2のステレオタイプ指定の各行は一つのステレオタイプを定義し，表3のタグ指定の各行は一つのタ

グ定義を含んでいる。

ステレオタイプ指定表の列は，次のように定められている。

− ステレオタイプ：ステレオタイプの名前。

− 基底クラス：ステレオタイプの基底として提供されるUMLメタモデル要素。

− 親：定義されたステレオタイプの直接的な上位（上位が一つも存在しない場合は“N/A”の記号が用

いられる。）。

− タグ：このステレオタイプに結び付けられたタグ付値のすべてのタグの並び（一つも定義されていな

い場合はN/A。）。

− 制約：このステレオタイプに結び付けられた制約の並び。

− 記述：説明するために付いた注釈などの非形式的記述。

タグ指定表の列は，次のように定義されている。

− タグ：タグの名前。

− ステレオタイプ：このタグを所有するステレオタイプの名前。単独のタグの場合は“N/A”。

− 型：タグに結び付けられる値の型の名前。

− 多重度：一つのタグのインスタンスに結び付けられる値の最大の個数。

− 記述：説明するための注釈などの非形式的記述。

ステレオタイプ指定表及びタグ指定表の双方において，適用可能な指定がない列は省略される。

図におけるステレオタイプ指定表の例では，二つの関係あるステレオタイプが定義されている。一行目

ではGeneralizableElementのステレオタイプである «アーキテクチャ要素» が宣言されている。二行目

では «アーキテクチャ要素» である «カプセル» が宣言されているが，これはメタモデルにおける

GeneralizableElementの下位クラスであるクラスのインスタンスに適用する。

図68は，図67の表と等価な宣言を示したものだが，制約及び非形式的記述が省かれている。

図68−図67で表したステレオタイプ宣言の等価図式

117

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

すなわち，無関係なパッケージに対する公開可視性，対象パッケージの子孫に対する公開可視性若しくは

保護可視性，又は対象パッケージの内部に入れ子になったパッケージに対する任意の可視性をもつ（後者

の場合，アクセス依存は必要ない。）。このパッケージの内部で入れ子になっているパッケージがアクセス

する場合，包含パッケージと同じアクセスができる。

アクセス依存は，クライアントの名前空間を変更せず，参照の自動作成もせず，あくまでも参照の確立

を許可するだけである。また，参照の作成時に，ツールが必要に応じてユーザのためにアクセス依存を自

動的に作成することもできる。

移入依存は，アクセスを保証し，対象名前空間において適切な可視性をもつ名前を，アクセスするパッ

ケージにロードする（すなわち，参照にパス名が必要なくなる。）。しかし，そのような名前は自動的に再

移出しないので，名前を明示的に再移出されなければならない（そして新たな名前及び可視性を同時に与

えることが可能でなければならない。）。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

クラスのステレオタイプは，（名前の文字列の上にあるギュメに）テキスト，又は右上隅のアイコンとし

て示すことができる。オブジェクトのステレオタイプは，そのクラスのステレオタイプと一致しなければ

ならない。

一つのオブジェクトが複数クラスのインタンスである場合，コンマで区切られたクラス名並びを使う。

クラス名は，適正な多重クラス分類に適合していなければならない。すなわち，唯一の実装クラスが許さ

れるが，型は複数個を許す。

クラスの特定の状態にオブジェクトが存在することを示すには，次の構文を使用する。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

スのインスタンスであり，その合成クラスはその部分要素との間に合成集約関連が存在する。合成オブジ

ェクトは，コラボレーション図に似ているが（コラボレーション図よって単純で限定され），静的モデル内

の合成集約によって完全に定義される（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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ければならない。関連に参加する分類子は，名前矢の方向に従って順序付けられる。

注記関連モデルの名前方向特性は，必要ではない。関連内の分類子の順序付けが名前の方向となる。

この取り決めは，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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

モデルの場合には，モデル自体に多重度を指定しないこともできる。その場合表記中では，多重度が抑止

されなければならない（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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

役割名及びインタフェース指定子を使用することは，関連及び二つの役割だけを含む小さなコラボレー

ションを生成することと等価とする。構造は，関連役割名と接続された分類子で定義される。したがって，

元の関連及び分類子は，コラボレーションの使用になる。元の分類子は，インタフェース指定子（分類子

として，インタフェース又は型になる）と互換性がなければならない。

インタフェース指定子を省略した場合，関連するクラスのすべてのアクセスを取得するためには，関連

を使うことができる。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

含む）整数範囲を指定する。さらに，星文字“*”を上限に使うことができ，その場合は無制限の上限を示

す。（テンプレートのような）パラメタ化された文脈では上限及び下限は式でもよいが，実際の利用時はい

つも，評価された結果はリテラルの整数値にしなければならない。評価結果がリテラルの整数値にならな

い未束縛の式は許されない。

一つの整数値が指定される場合，整数範囲は単一の整数値を含む。

多重度指定が単一の星文字“*”からなる場合，無制限の非負整数を示す，すなわち，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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

合成集約の修飾を使った二項関連の経路を使う代わりに，合成は，全体側要素記号の内部の部分側要素

記号の図的な入れ子で示すこともできる。この入れ子クラスのような要素は，その合成要素の内部で多重

度をもつこともできる。多重度は，部分記号の右上隅に示す。多重度記号が省略されている場合，省略時

の多重度は多とする。これは，合成分類子の中での部分としての，その多重度を表現する。入れ子要素は，

合成集約の中で役割名をもつこともできる。名前は，型の前に次の構文で示す。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

合，インスタンスはループを含むことができる（経路の詳細は，5.41を参照）。

役割名は，リンクの両端に示すことができる。関連名は，経路の近くに示すことができる。存在する場

合，インスタンスを示すために下線を引く。リンクはインスタンス名をもたず，自分が関係するインスタ

ンスから自分の識別性を得る。リンクはインスタンスなので多重度は示さない。他の関連修飾（集約，合

成集約，及び誘導）は，リンク端に示すことができる。

限定子は，リンク上に示すこともできる。限定子の値は，その長方形の中に示すことができる。

5.49.2.1 実装ステレオタイプ

ステレオタイプをリンク端に付加して，実装の様々な種類を示すことができる。次のステレオタイプを

使うことができる。

«association»

関連（省略時，強調する場合を除いて指定不要）

«parameter»

メソッドのパラメタ

«local»

メソッドの局所変数

«global»

大域変数

«self»

自己リンク（自身にメッセージを送信するインスタンス）

5.49.2.2 N項リンク

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

の分類子と同じように関連クラスの長方形の間にはん（汎）化の矢線を描く方法とする。縮退した関連ク

ラスは正当な関連なので，このアプローチは，例え関連が追加的な属性をもたない場合でも使うことがで

きる。

特定の図に示されない，モデルにおける追加的な下位の存在は，下位の場所に省略記号“…”を使って

示すことができる。

注記これは，追加的な下位が将来追加されるかもしれないということを示さない。これは追加的な

下位がたった今存在するが，見えていないということである。これは，そのような情報が伏せ

られていることを示す記法上の便宜とし，意味論の提示とはしない。

下位の間の意味論的な制約を示すために，既定義の制約を使うこともできる。コンマで区切ったキーワ

ードの並びを大括弧で囲み，共有された三角形の近く（幾つかの経路が単一の三角形を共有する場合），又

は関係するすべてのはん（汎）化の線分を横切る点線の近くに置く。次のキーワードを（とりわけ）使う

ことができる（次の制約は，既定義とする。）。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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は解説的内容であるため，この規格では不要であり，不採用とし

た。）

第6区分ユースケース図（用例図）

ユースケース図は，システム又は意味論的実体内部のユースケースとそのアクタとの間の関係を示す。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

− はん（汎）化：アクタAからアクタBへのはん（汎）化は，Aのインスタンスは，Bのインスタンス

が交信するのと同じ種類のユースケースと交信できるということを示す。

5.58.2 記法

アクタとユースケースとの間の関連は，アクタとユースケースとの間の実線として示す。

アクタ間のはん（汎）化は，はん（汎）化矢線，すなわち，白抜き閉矢じり実線矢線で示す。矢じりは，

より一般的なアクタに向けて引く。

5.58.3 例

注記（対応国際規格では，5.58.3は解説的内容であるため，この規格では不要であり，不採用とし

た。）

5.58.4 対応付け

注記（対応国際規格では，5.58.4は解説的内容であるため，この規格では不要であり，不採用とし

た。）

第7区分相互作用図

振る舞いの記述は，次の二つの側面を含む。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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

る役割が，指定される。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ンスタンスの水平方向の順序付けは意味がない。

シーケンス図で使われる異なる種類の矢線は，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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

第8区分コラボレーション図（協調図）

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

間の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群を伴ったデザインパターンの利用を示すことができる。

143

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

図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群のような役割でモデル

化できない付加的要件を表現する。

145

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

構文に従う。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

要求を処理する過程で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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

開矢じり破線矢線

手続呼出しからの返却を表す。活性化終端では，返却矢線は暗黙なので省略してよい。

その他の種類

その他の種類の制御，例えば，“妨害”又は“タイムアウト”のような文字列で表してもよい。しかし，

これらは，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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

[ 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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

起点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は解説的内容であるため，この規格では不要であり，不採用とし

た。）

第9区分ステートチャート図（状態図）

5.74 ステートチャート図

ステートチャート図は，オブジェクト，相互作用などのモデル要素の振る舞いを規定する。特に，要素

が存続中に起こり得る状態及び動作系列を独立イベント（例えば，シグナル，操作の起動など）の反応と

して指定する。

この章で記述する意味論及び記法は，David Harelのステートチャートをオブジェクト指向用に変更した

ものである。彼の業績で従来の階層構造のない状態機械から大きく進歩した。また，ステートチャート記

法は，Moore機械及びMealy機械で示される従来の状態機械の両方の側面を実装している。

5.74.1 意味論

ステートチャート図は，イベントインスタンスの受信に対する応答を規定することによって動的な振る

152

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

舞いのある実体の振る舞いを表現する。ステートチャート図は，主にクラスインスタンスの振る舞い記述

に用いる。しかし，ステートチャートは，ユースケース，アクタ，サブシステム，操作，メソッドなど他

の振る舞いを記述してもよい。

5.74.2 記法

ステートチャートは，状態機械を表現するグラフである。状態機械グラフ内の状態及び様々な他の型を

表す頂点（擬似状態）は状態及び擬似状態記号で表し，遷移は状態記号を結ぶ有向線分で表す。状態は，

物理的な包含によって下位の図を含むことができる。状態機械には，状態機械全体のすべての要素を含む

最上位状態が存在する。最上位状態の図的表現は，選択的とする。

状態機械間の関連や文脈には，特別な記法はない。

簡単な電話オブジェクトのステートチャート図の例を図104に示す。

図104−状態図

5.74.3 対応付け

注記（対応国際規格では，5.74.3は解説的内容であるため，この規格では不要であり，不採用とし

た。）

5.75 状態

5.75.1 意味論

状態は，オブジェクトの存続中又は相互作用中に，オブジェクト又は相互作用が条件を満たしたり，動

作を実行したり，イベントを待つなどする状況とする。合成状態は，単一状態とは対照的に図的に分解で

153

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

きる（合成状態及びその記法は，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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

た。）

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

た。）

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ない。

状態領域は，ʻ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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

場合，出力遷移のガードはその選択点に到達時に評価する。ガードの値は，入力遷移の動作で実行される

計算の関数であってよい。動的選択点は，小さな白丸で表す（小さな状態アイコンを想起させる。）。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

を表す。）とする。同期状態は，可能な場合二つの領域間の境界上に描く。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

判断の連鎖は，合成遷移の一部としてもよい。しかし，その連鎖の第一切片だけがイベントトリガラベ

ルを含むことができる。すべての切片に，ガード式を記述してもよい。合流から来る遷移は，トリガラベ

ル又はガード式をもたない。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

て別のラベルなしの遷移矢線をこの五角形から次の動作状態へ引く。破線矢線をオブジェクト記号からこ

の五角形のくぼみに向かって引いてもよく，これはシグナルの送信者を示す。これは，選択的である。

5.91.1.2 シグナルの送信

シグナルの送信は，（いずれか一方の）側面に三角のせん（尖）端をもつ凸五角形で表す。シグナルの呼

出し仕様は記号の内側に表す。ラベルのない遷移矢線を先行の状態遷移からこの五角形へ引き，そして他

のラベルのない遷移矢線をこの五角形から次の動作状態へ引く。破線矢線を五角形のせん（尖）端からオ

ブジェクト記号に引いてもよく，シグナルの受信者を示す。これは，選択的である。

図124−シグナルの送受信のための記号

5.91.1.3 遅延イベント

しばしば，他の動作又は下位活動が進行中に発生したイベントを遅延しなければならないことがある（通

常，処理されないイベントは直ちに消失する。）。これはそのイベントが消費されるか廃棄されるまで，内

部キューに保持している内部遷移として考えられる。各状態は，その状態のときに発生しても遅延され遷

移トリガとして使わないイベント集合を指定する。あるイベントがその状態上の遅延可能イベントに含ま

れず遷移にトリガをかけない場合，既に発生していてもキューから除去される。遷移がイベントに依存し

イベントが内部キューにある場合，遷移は直ちに発火する。複数の遷移が可能な場合，キュー内の先頭イ

ベントが優先する。

遅延可能イベントは，状態内に斜線及び操作deferをイベント名に付けた並びで表す。そのイベントが

起きた場合，そのイベントを保存し，他の状態へ遷移したときに再現される。他状態で再遅延もある。オ

ブジェクトがイベント遅延されない状態に到達すると，そのイベントは受理されるか又は消失されなけれ

ばならない。合成状態，又はそれと等価な下位機械状態及び下位活動状態に，イベントが遅延可能の指示

を表してもよいが，それはその合成状態全体を通して遅延可能であり続ける場合となる。

保持している遷移を遅延可能イベントがトリガをかけると，そのキューからその遷移が除かれる。

動作状態では，イベントを遅延する必要はない。なぜならば，動作状態ではイベント処理に対して割込

166

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

図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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

コンポーネントが他のコンポーネントのサービスを用いることを表す。ステレオタイプは，必要ならば正

確な依存関係を示すために用いてもよい。

配置図は，どのコンポーネントが，どのノードに存在するかを示すために用いる。それは，«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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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は解説的内容であるため，この規格では不要であり，不採用とし

た。）

171

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

標準要素名

適用する基底要素

種類

«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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書B

（規定）
法的情報

注記附属書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 著作権情報

174

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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の指名によ

って活動を行う）者であり，常に，コンピュータソフトウェアの開発者，供給者又は販売者に対し，仕様

に適合していることを示す認定マーク，商標，又は他の特別な呼称を使用する許可を与えることのできる

唯一の機関である。

本ライセンス条項に従って開発するソフトウェアは，仕様に定めた適用可能な適合ポイントに完全に合

致している場合だけ，この仕様への準拠性又は適合性を主張することができる。適用可能な適合ポイント

に部分的にだけ合致して開発されたソフトウェアの場合は，当該ソフトウェアがこの仕様をベースに開発

181

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書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

183

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書JC

（参考）

用語集

注記この用語集は，対応する国際規格ISO/IEC 19501において巻末に掲載されている用語集である。

規格本体又は附属書を構成するものではない。したがって，この規格では参考情報として掲載

することにした。

用語集

この用語集は，統一モデル化言語（UML）及びメタオブジェクトファシリティ（MOF)を記述するため

に用いる術語を定義する。UML及びMOF固有の専門用語に加え，OMG標準，及びオブジェクト指向分

析・設計方法論に関連する用語を含む。その上，オブジェクトリポジトリ及びメタデータ管理系の領域ま

でも含める。用語集の見出し語は，アルファベット順に並べる。また，MOF固有の見出し語は [MOF] とし

て識別される。

記法の規約

この用語集の見出し語は，通常，小文字で始められる。語句が標準の慣例で大文字で始められるものに

ついて，頭の文字を大文字で表す。頭字語は，伝統的に小文字で表すものでない限り，すべて大文字で表

す。

複数の語句からなる用語の一部が[ ]括弧で囲まれるときは，その用語を参照する場合，その語句は選

択可能とすることを示す。例えば，ユースケース[class]は，単にユースケースとして参照する。

この用語集では，次の規約が用いられている。

・対比語:<用語>

対立したり，又は本質的に異なる意味をもつ用語を引用する。

・参照語:<用語>

似たようではあるが，同義的な意味ではない関連した用語を引用する。

・同義語:<用語>

別の用語として同一の意味をもち参照される用語を示す。

・頭字語:<用語>

用語が頭字語とすることを意味する。読者は，省略されずに表された用語がほとんど使われていな

ければ，定義として常に，省略しない用語として参照する。

用語一覧

JC.1

抽象クラス（abstract class）

直接インスタンス化できないクラス。
対比語：具象クラス（concrete class）。

JC.2

抽象化（abstraction）

ある実体を他のすべての種類の実体から区別する本質的な特徴。
抽象化は，観察者の観点に対し，相対的な境界を定義する。

184

X 4170：2009 (ISO/IEC 19501：2005)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

JC.3

動作（action）

コンピュータ的な処理を抽象化した実行可能な仕様。動作は，一
般的には，システムの状態を変え，そして，オブジェクトにメッ
セージを送ることによって，又は（オブジェクトの）連結若しく
は属性の値を変更することによって実現することができる。

JC.4

動作系列（action sequence）

動作列を決定する式。

JC.5

動作状態（action state）

原子的動作の実行を表現する状態であり，一般的には，操作の呼
出しを表現する状態。

JC.6

活性化（activation）

動作の実行。

JC.7

能動クラス（active class）

そのインタンスが能動オブジェクトであるクラス。
参照語：能動オブジェクト（active object）

JC.8

能動オブジェクト
（active object）

スレッドをもち，制御活動を開始できるオブジェクト。能動クラ
スのインスタンス。参照語：能動クラス（active class），スレッド
（thread）。

JC.9

アクティビティグラフ
（activity graph）

複数の分類子を含んだプロセスをモデル化するために用いられる
状態機械の特別な場合。
対比語：ステートチャート図（statechart diagram）。

JC.10

アクタ [class]（actor [class]）ユースケースの利用者が，そのユースケースと相互作用を行うと

きに果たす一貫した役割の集合。一つのアクタは，そのアクタが
交信する各ユースケースに対し一つの役割をもつ。

JC.11

実パラメタ
（actual parameter）

同義語：引数（argument）。

JC.12

集約 [class]
（aggregate [class]）

集約（全体−部分）関係において，“全体”を表現するクラス。
参照語：集約（aggregation）。

JC.13

集約（aggregation）

集約（全体）とその構成要素間の“全体−部分”関係を規定する
関連の特別な形式。参照語：合成体（composition）。

JC.14

分析（analysis）

ソフトウェア開発プロセスの一部であり，その主目的が問題領域
のモデルを作ることにある過程のこと。分析は何をするかに焦点
をあて，設計ではどのようにそれを行うかに焦点を当てる。
対比語：設計（design）。

JC.15

分析時（analysis time）

ソフトウェア開発プロセスの分析段階の間に起こることを指す。
参照語：設計時（design time），モデル化時（modeling time）。

JC.16

アーキテクチャ
（architecture）

システムの組織的構造及び関連する振る舞い。アーキテクチャは，
インタフェースを使って相互作用したりする部品，部品を結合す
る関係，及び構成している複数の部品に対する制約に再帰的に分
解できる。インタフェースを使って相互作用する部品は，クラス，
コンポーネント及びサブシステムとする。

JC.17

引数（argument）

実行時のインスタンスを決定するパラメタの束縛。同義語：実パ
ラメタ（actual parameter）。対比語：パラメタ（parameter）。

JC.18

成果物（artifact）

ソフトウェア開発プロセスにおいて利用する，又は作成する情報
の物理的な構成要素。成果物の例としては，モデル，ソースファ
イル，記述及びバイナリの実行可能形式のファイルを含む。成果
物は配置可能なコンポーネントの実装としてもよい。
同義語：成果物（product)。対比語：コンポーネント（component）。

JC.19