組込み分野のための
UML モデル解説書

機能編 F002

自己診断

本書は、UML モデルカタログに含まれる「自己診断」のモデル
UMTP 組込みの詳細を記述したものです。モデリングの初心者には教科書や参考

モデリング部会書として、モデリングのベテランの方々にはモデルのヒントとし2016.5.15 更新て、ぜひともお手元に置いて活用してください。

Copyright(c)2010-2016 consortium for UML based Modeling Technologies Promotion All Rights Reserved

組込み分野のための UML モデル解説書

UMTP は特定非営利活動法人 UML モデリング推進協議会の登録商標です。その他、本書に記載されている会社名、商品名などは、一般に各社の商標または登録商標です。

2

自己診断

目

次

要求仕様 .................................................................................................... 4
モデル一覧 ............................................................................................... 11
エンティティに着目したモデル ..................................................................... 12
分析モデル ............................................................................................. 13
PIM 設計モデル ....................................................................................... 25
メタファを使ったモデル .............................................................................. 44
分析モデル ............................................................................................. 49
PIM 設計モデル ....................................................................................... 53

3

組込み分野のための UML モデル解説書

自動車や通信機器などには警告灯を備えるものや故障を示す表示ができるものがあります。これらには、装置が正しく動いているかどうかを調べる自己診断機能があり、異常を検知すると、(対処や)表示を行います。また、トラブル発生時に原因究明や対応を行うため、手動で自己診断ができる機器もあります。

要求仕様
1．組込み装置には、装置が正しく動作しているかどうかを調べる自己診断機能があります。
2．自己診断は、機器管理者の要求により起動される場合と、予め設定された条件に合わせて自動的に起動される場合があります。いずれも、機器管理者の指示により中止することが可能です。
3．診断の対象には、デバイス単体や、複数デバイスから構成される機能ユニット、そして装置上で動作するアプリケーションが含まれます。
機能ユニットは階層構造を持つことが可能で、上位の機能ユニットは複数の下位機能ユニットを含む
ことができます。
4．一つの装置内では複数の自己診断を実施することが可能です。各自己診断は、1 つの診断対象に対する診断でも、それらを任意に組み合わせたものでも構いません。
（例：起動時診断や月次診断では全機能ユニット、週次診断では重要機能ユニット、日次診断では最重要ユニットなど。）
また、自己診断に含まれる各診断は、並行・逐次、どちらの形でも実施可能です。
5．診断対象ごとに、診断項目が決まっており、各診断ではどの診断項目を診断するかを設定することが可能です。
（例：起動時診断や月次診断では診断項目 1～10 まで、週次診断では 1～5 と 6～10 を交互に、日次
診断では 1 と 2 のみなど。）
6．診断結果は、診断項目ごとに OK/NG の結果と、NG の場合には、エラーコードをレポートします。
7．診断結果の履歴は保存する必要がありません。
8．診断途中で中止されたときには、それまでの診断内容をレポートして終了します。

要求仕様

4

自己診断

ユースケース
uc 要求
組込み装置

U C01:自己診断を行う<<include>>

U C03: 診断結果をレポー ト
する

U C02:自己診断を中止す る
機器管理者

U C04:自己診断を設定す る

図1

5<<include>>組込み分野のための UML モデル解説書

ユースケース記述<UC01:自己診断を行う>■概要
機器管理者が組込み装置に診断開始を指示すると、組込み装置は診断を行い、診断結果をレポートする。

■アクター
機器管理者

■事前条件
・組込み装置に実行する自己診断が設定されている■事後条件
・自己診断が終了し、診断結果がレポートされている■メインフロー
1. アクターは、実行する自己診断を指定し、システムに診断開始を指示する
2. システムは、診断を行う
3. システムは、「診断結果をレポートする」ユースケースを実行する
4. UC を終了する■課題や T．B．D 項目なし■備考
・複数の自己診断を並行して行うことが可能。この際、組込み装置内で必要な排他制御を行う。

要求仕様

6

自己診断

<UC02:自己診断を中止する>■概要
組込み装置が自己診断実行中に、機器管理者が自己診断中止を指示すると、組込み装置は自己診断を中止し、それまでの診断結果をレポートする。

■アクター
機器管理者

■事前条件
・組込み装置は自己診断を実行中である■事後条件
・自己診断が中止された・診断結果がレポートされた■メインフロー
1. アクターは、システムに、自己診断の中止を指示する
2. システムは、自己診断を中止する
3. システムは、「診断結果をレポートする」ユースケースを実行する
4. UC を終了する■課題や T．B．D 項目
・複数の自己診断を並行して実行中の場合、中止する診断の指定方法(またはすべてを中止)■備考
・自己診断を実行していない場合に、本ユースケースを実行しても、何も行われない(エラーにならない)。
自己診断中止の指示中に自己診断を終了した場合も同様。

7

組込み分野のための UML モデル解説書<UC03: 診断結果をレポートする>■概要
組込み装置が診断結果をレポートする。

■アクター
なし

■事前条件
なし

■事後条件
診断結果がレポートされている■メインフロー
1. システムは、診断結果をレポートする
2. UC を終了する■課題や T．B．D 項目
・レポートの出力手段
・レポートのフォーマット(形式)■備考・本ユースケースは他のユースケースから起動される

要求仕様

8

自己診断

<UC04:自己診断を設定する>■概要
機器管理者が組込み装置に自己診断を設定する。

■アクター
機器管理者

■事前条件
なし

■事後条件
組込み装置に自己診断が設定されている■メインフロー
1. アクターは、システムに、自己診断を設定することを指示する
2. アクターは、システムに、各種設定内容を指示する
3. システムは、指示された内容の自己診断を保存する
4. UC を終了する■代替フローなし■課題や T．B．D 項目
・どの自己診断を並行・逐次で実行するかの指定方法
・レポートの出力手段とレポートのフォーマット(形式) の指定方法■備考
設定内容は次の通り。
・自己診断の名前
・自己診断の起動方法
・診断の種類（1 つの診断対象に対する診断 or 既存の自己診断を組み合わせた診断）
1 つの診断対象に対する診断を設定した場合は、1 つの診断対象を指定する
既存の自己診断を組み合わせた診断の場合は、複数の自己診断を指定する

9

組込み分野のための UML モデル解説書

シナリオ<SC0101:自己診断を行う>
1. 山田太郎さんがルーターにイーサネット診断の開始を指示する。
2. ルーターは診断を行う。
3. ルーターは診断結果をレポートする。

<SC0201: 診断を中止する>
1. 山田太郎さんがルーターにイーサネット診断の開始を指示する。
2. ルーターは診断を行う。
3. 山田太郎さんがルーターに診断の中止を指示する。
4. ルーターは自己診断を中止する。
5. ルーターは診断結果をレポートする。

<SC0401: 自己診断を設定する(1 つの診断対象に対する診断)>
1. 山田太郎さんがルーターに自己診断を設定することを指示する。
2. 山田太郎さんはルーターに設定する自己診断の名前を『イーサネットメモリチェック』と指示する。
3. 山田太郎さんはルーターに自己診断の起動方法を毎日午前 1 時と指示する。
4. 山田太郎さんはルーターに「1 つの診断対象に対する診断」を設定することを指示する。
5. 山田太郎さんはルーターに自己診断の診断対象をイーサネットと指示する。
6. 山田太郎さんはルーターに自己診断の診断内容をメモリチェックと指示する。
7. ルーターは毎日午前 1 時、イーサネットを対象に、メモリチェックの自己診断を行うように設定する。

<SC0402: 自己診断を設定する(1 つの診断対象に対する診断その 2)>
1. 山田太郎さんがルーターに自己診断を設定することを指示する。
2. 山田太郎さんはルーターに設定する自己診断の名前を『イーサネットレジスタチェック』と指示する。
3. 山田太郎さんはルーターに自己診断の起動方法を毎日午前 2 時と指示する。
4. 山田太郎さんはルーターに「1 つの診断対象に対する診断」を設定することを指示する。
5. 山田太郎さんはルーターに自己診断の診断対象をイーサネットと指示する。
6. 山田太郎さんはルーターに自己診断の診断内容をレジスタチェックと指示する。
7. ルーターは毎日午前 2 時、イーサネットを対象に、レジスタチェックの自己診断を行うように設定する。

<SC0403: 自己診断を設定する(既存の自己診断を組み合わせた診断)>
1. 山田太郎さんがルーターに自己診断を設定することを指示する。
2. 山田太郎さんはルーターに設定する自己診断の名前を『イーサネット』と指示する。
3. 山田太郎さんはルーターに自己診断の起動方法を毎週日曜日午前 3 時と指示する。
4. 山田太郎さんはルーターに「既存の自己診断を組み合わせた診断」を設定することを指示する。
5. 山田太郎さんはルーターに『イーサネットメモリチェック』自己診断を組み合わせるように指示する。
6. 山田太郎さんはルーターに『イーサネットレジスタチェック』自己診断を組み合わせるように指示する。
7. ルーターは毎週日曜日午前 3 時、『イーサネットメモリチェック』自己診断と『イーサネットレジス
タチェック』自己診断を組み合わせた自己診断を行うように設定する。

要求仕様

10

自己診断

モデル一覧
着目点

コンセプト

ポイント

機能に着目した
モデルなし

エンティティに着目したモデル

要求仕様の内容をエンティティを中心に分析し、診断と診断項目の静的構造に着目したモデルです。

状態に着目したモデル

なし

メタファを使ったモデル

装置の自己診断機能を、日常の診断(健康診断など)にたとえてモデリングしています。

11

要求仕様の内容を忠実に分析しています。

身近な話題から入るので、モデリングの導入編としてお勧めです。

組込み分野のための UML モデル解説書

エンティティに着目したモデル
要求仕様をエンティティに着目し、診断を診断対象の診断項目と対応する結果と捉え、このような診断を組み合わせることでさまざまな診断をモデリングしています。

モデリングのコンセプト
要求仕様の内容を忠実に分析し、モデリングします。
要求仕様から以下の特徴が読み取れました。
(ⅰ) (後述の組み合わせた診断に対して) 単一の対象に対する診断とは 1 個の診断対象に対して定められた診断項目を診断し、診断結果を得ることです。診断対象に対して診断項目は決まっていますが、診断毎にどの診断項目を診断するかを設定することが可能です。(UML 図ではなく)簡単に図示すると以下のようになります。

A 診断

診断対象

診断項目

診断結果

診断項目

診断結果

診断項目

診断結果

診断項目

この診断 A では、この診断項目は診断しない(ⅱ)診断は複数の診断から組み合わせることもでき、以下のように 並行/順番に実行されます(組み合わせた診断)。(UML 図ではなく)簡単に図示すると以下のようになります。

○○診断

×× 診断

A 診断

A 診断

B 診断

C 診断
D1 診断

B 診断
並行に診断

D2 診断

順番に診断
E 診断

エンティティに着目したモデル

C 診断

12

自己診断

分析モデル
前述の(i)より、診断、診断対象、診断項目、診断結果、の各クラスとそれらの関係、(ii)より診断クラスの自己関連が導き出されます。さらに以下を加え、クラス図を作成しました。
(ⅲ)要求仕様 3 より診断対象の構造(組込み装置、機能ユニット、デバイス、アプリケーション、の各クラ
ス)(ⅳ)レポートを表すレポートドメイン(レポート、フォーマット、出力方法、の各クラス)

静的モデル
cl a s s 分析ク ラ ス 図
レポートドメイン

診断の順番を表す

出力方法
前
0..*

(ii)
起動条件

診断

起動条件

診断間隔
診断日時

名前

次
0..*

出力方法

0..*

名前
1

0..1

1

0..*

対象
0..1
対象

名前

1..*

1..*

名前

結果
0..*

診断項目
名前

診断
項目

結果

1

0..*

レポー ト

0..1

(i)

診断
0..* 項目
診断
項目

0..*

レポート

0..*

診断対象

1

診断結果
エラーコード成否

0..*
フォーマット1フ ォ ー マット
名前(iv)
ア プ リケー シ ョ ン

機能ユ ニット

デ バイス
1

0..*

1..*
1

1..*

上位
0..*

下位
0..*

1

組込み装置

(iii)

図2

診断には名前があり、個々の診断が区別されます。
診断は起動条件、診断対象、診断項目、レポートに関連があり、診断が何時(起動条件)、何を(診断対象)、
どの診断項目で、どのようにレポートするかを表します。

13

分析モデル

組込み分野のための UML モデル解説書

診断条件、診断対象、診断項目、レポートは関連がない場合もあります。組み合わせた診断の場合、個々の診断には必要ないので、関連がない場合もあります。また、機器管理者の要求により起動される場合には、診断条件がない場合もあります。
診断結果は診断と診断項目に関連があります。どの診断のどの診断項目の診断結果なのかを表します。
診断を行っていない場合、診断結果はありません。
組み合わせた診断は診断の自己関連で表されます。実施する診断を順番に繋ぎます。この際に 1 個の診断から複数の診断へ分岐すると、それらの複数の診断が並列に実施されることを表します。また、複数の診断から 1 個の診断に合流すると、並列の実施から順次の実施となります。
組込み装置は機能ユニットから構成され、機能ユニットはデバイスから構成されます。機能ユニットは構造をとることも可能で、ある機能ユニットは機能ユニットから構成されることもあります。また、アプリ
ケーションも組込み装置の構成要素です。
デバイス、機能ユニット、アプリケーションは診断対象です。すなわち、これらを汎化したものが診断対象です。
レポートは、出力方法とフォーマット(形式)があります。
出力方法の例としてはコンソール出力、(ログ)ファイル、電子メール、Web ページ、LED などがあります。
フォーマットの例としてはプレーンテキスト、MIME、HTML などがあります。
レポート、出力方法、フォーマットは意味的にまとまっているので、レポートドメインとします。

エンティティに着目したモデル

14

自己診断

組込み装置(ルーター)のオブジェクト構成
obj ect 組込み装置( ルー ター ) の構成
イー サネット1のレジスタ読み書き :診断項目
イー サネット1 :デ バイス

イー サネット1のメ モリ読み書き :診断項目
イー サネット1のルー プ バック :診断項目

イー サネット :機能ユ ニット
イー サネット2のレジスタ読み書き :診断項目
イー サネット2 :デ バイス

イー サネット2のメ モリ読み書き :診断項目

ルー ター :組込み装置
イー サネット2のルー プ バック :診断項目

シリアルのレジスタ読み書き :診断項目
シリアル :機能ユ ニット

シリアル :デ バイス

シリアルのメ モリ読み書き :診断項目
シリアルのルー プ バック :診断項目

セキ ュリテ ィ監視 :アプ リケー ショ ン

セキ ュリテ ィ監視アプ リケー ショ ン :診断項目

図3

イーサネット×2、シリアル×1 のルーターのオブジェクト構成です。

15

分析モデル

組込み分野のための UML モデル解説書「診断、診断対象、診断項目、診断結果の関係」のオブジェクト構成
obj ect 診断、診断対象、診断項目、診断結果の関係

イー サネット 1 :診断

イー サネット 1簡易 :診断:診断結果

イー サネット 1のレジ スタ読み書き :診断項目:診断結果
イー サネット 1のメ モ リ読み書き :診断項目

:診断結果
:診断結果

イー サネット 1のルー プ バック :診断項目:診断結果
イー サネット 1 :デ バイス

イー サネット 2 :診断

イー サネット 2簡易 :診断

イー サネット 2のレジ スタ読み書き :診断項目

:診断結果
:診断結果
:診断結果

イー サネット 2のメ モ リ読み書き :診断項目:診断結果
イー サネット 2のルー プ バック :診断項目:診断結果
イー サネット 2 :デ バイス

図4

先のルーターで診断と診断に関連するモノを示したオブジェクト構成です。
「イーサネット:デバイス」は「レジスタ読み書き:診断項目」、「メモリ読み書き:診断項目」、「ループバック:診断項目」と関連があり、デバイスのインスタンスが異なると、同じ診断項目でも別の診断項目のインスタンスとなります。
ある診断対象(「イーサネット:デバイス」)に対する診断は、診断対象のすべての診断項目を行ってもよいですし(「イーサネット 1: 診断」や「イーサネット 2: 診断」)、一部の診断項目を行ってもよいです(「イーサネット 1 簡易: 診断」や「イーサネット 2 簡易: 診断」)。

エンティティに着目したモデル

16

自己診断

「組み合わせた診断」のオブジェクト構成
obj ect 組み合わせた診断
イー サネット簡易 :診断

イー サネット1簡易 :診断

日次 :診断イー サネット1簡易 :診断

イー サネット2簡易 :診断

シリアル簡易 :診断

イー サネット2簡易 :診断

セキ ュ リテ ィ監視アプ リケー ショ ン :診断

図5

同じく先のルーターで組み合わせた診断のオブジェクト構成です。
「イーサネット簡易:診断」は「イーサネット 1 簡易:診断」を実施し、次に「イーサネット 2 簡易:診断」を実施します。
「日次:診断」は「イーサネット 1 簡易:診断」と「イーサネット 2 簡易:診断」を並列に実施し、次に「シリアル簡易:診断」を実施し、次に「セキュリティ監視アプリケーション:診断」を実施します。
「イーサネット 2 簡易:診断」から「イーサネット簡易:診断」へのリンク、「セキュリティ監視アプリ
ケーション:診断」から「日次:診断」へのリンクは診断の終了を通知するためにあります。

17

分析モデル

組込み分野のための UML モデル解説書

操作を追加したクラス構成
cl a s s 分析ク ラ ス 図( 操作付き)
レポートドメイン
出力方法
診断の順番を表す

名前
出力する()
生成する()

前0..*1 出力方法

次
0..*

0..*

診断

レポー ト

名前
起動条件

起動条件

診断間隔
診断日時

0..1

1

生成する()

チェック項目を加える(チェック項目)
レポート
最後を設定する(診断)最初を設定する(診断)
0..1
0..*
次を設定する(診断)
診断する()
診断する(レポート)
診断を中止する()生成する(文字列, 診断対象, 起動条件)生成する(文字列, 診断対象)複製する()
0..*

0..*

1

名前
出力する()
書き込む()
生成する()
0..*
1 フォーマットフ ォ ー マット
名前
生成する()
変換する()

診断項目

対象
0..1

診断
項目

対象

名前を取得する()

ア プ リケー シ ョ ン

生成する(文字列)
付ける(機能ユニット)

0..*

1..*

1

1..*

1..*

機能ユ ニット

生成する(文字列)

下位
0..*

名前
診断する()
生成する(文字列)
名前を取得する()

デ バイス
1

1..*

生成する(文字列)

上位
0..*

1

組込み装置

図6

後述のシーケンス図を作成し、操作の検討を行ったクラス図です。

エンティティに着目したモデル

結果
0..*

診断項目

診断対象
名前

0..*

18

診断
項目
1

結果
0..*

診断結果
エラーコード
成否結果を取得する()
削除する()
生成する()

自己診断

動的モデル
操作の検討と実現性の確認のため、ユースケースのメインフローまたはシナリオからシーケンス図を作成しました。オブジェクト図と同様にルーターを題材としています。

ユースケース「UC01:自己診断を行う」の相互作用
s d U C01
ルーター

日次 :診
断

イーサネット1簡易 :診断

イーサネット2
簡易 :診断シリアル簡易 :診断

山田太郎さん
診断開始を指示する("日次")

セキュリティ監視アプリケーション
:診断

レポート1
:レポート

出力方法
1 :出力方法「UC01イーサネット1簡易」参照

診断する()
診断する(レポート1)

診断する(レポート1)
前の2個からのメッセージを受けて、診断を行う

診断する(レポート1)(a)

診断する(レポート1)(b)(c)
最後からのメッセージが来たので、すべての診断が終了した診断する(レポート1)
診断する(レポート1)

出力する()

出力する()(d)

図7(a)アクターから診断開始の指示を受けると、ルーターは該当する診断インスタンスに「診断する」メッセージを送信します。
(b)「日次:診断」から診断の構造に従って、個々の診断へ「診断する」メッセージを送信します(「日次:診断」から「イーサネット 1 簡易:診断」への「診断する」メッセージなど)。
(c)診断の構造の最後にある「セキュリティ監視アプリケーション:診断」が完了を示す「診断する」メッ
セージを「日次:診断」へ送信します。
(d)「日次:診断」がレポートに出力します。

19

分析モデル

組込み分野のための UML モデル解説書
s d U C01イー サネット 1簡易
イーサネット1
簡易 :診断イーサネット1のレジスタ読み書
き :診断項目

イーサネット1のメモリ読み書き :診断項目

イーサネット1
:デバイス

レポート1
:レポート

フォーマット1:フォーマット診断する(レポート1)
診断する()(a)
診断結果を返す

(b)

生成
する()

イーサ1レジ
スタ :診断結果

診断する()
生成する() イーサ1メ
モリ :診断結果

診断結果を返す(c)
名前を取得する()

書き込む()

変換する()

名前を取得する()(d)

結果を取得する()
書き込む()

変換する()

名前を取得する()
結果を取得する()
書き込む()
削除する()

変換する()
削除する()(e)
診断する(レポート1)

図8(a)「イーサネット 1 簡易:診断」は「診断する」メッセージを受信します。
(b)「イーサネット 1 簡易:診断」は各診断項目へ「診断する」メッセージを送信し、診断結果を受け取ります。
(c)「イーサネット 1 簡易:診断」はデバイスから名前を取得し、レポートに書き込みます。
(d)「イーサネット 1 簡易:診断」は各診断結果から結果を取得し、レポートに書き込みます。
(e)(すべて終了したので) 「イーサネット 1 簡易:診断」は「次」の(関連がある)「診断」へ「診断する」
メッセージを送信します。

エンティティに着目したモデル

20

自己診断

ユースケース「UC02:自己診断を中止する」の相互作用
s d U C02
ルーター

日次 :診
断

イーサネット1簡易 :診断

イーサネット2
簡易 :診断シリアル簡易 :診断

山田太郎さん
診断開始を指示する("日次")
診断する()

セキュリティ監視アプリケーション
:診断

レポート1
:レポート

出力方法
1 :出力方法「UC01(2)イーサネット1簡易」参照

診断する(レポート1)
診断する(レポート1)

診断する(レポート1)(a)

診断する(レポート1)
診断を中止する()

図示できていないが、「診断する()」の実行
中に「診断を中止する」メッセージを受信し、実行中の診断を中止する

診断を中止する()
診断を中止する()
診断を中止する()

診断を中止する()(b)

最後からのメッセージが来たので、「診断を中止する」が終了した

診断を中止する()
診断を中止する()(c)
診断を中止する()
出力する()

出力する()(d)

図9(a)アクターから診断開始の指示を受けると、ルーターは「ユースケース「UC01:自己診断を行う」のシー
ケンス」と同様に動きます。
(b)アクターから診断の中止の指示を受けると、「日次:診断」から診断の構造に従って、個々の診断へ「診断を中止する」メッセージを送信します(「日次:診断」から「イーサネット 1 簡易:診断」への「診断を中止する」メッセージなど)。
(c)診断の構造の最後にある「セキュリティ監視アプリケーション:診断」が完了を示す「診断を中止する」メッセージを「日次:診断」へ送信します。
(d)「日次:診断」がレポートに出力します。

21

分析モデル

組込み分野のための UML モデル解説書

シナリオ「SC0401: 自己診断を設定する(1 つの診断対象に対する診断)」の相互作用
s d SC0401
ルーター
山田太郎さん
自己診断を設定することを指示する()
設定する自己診断の名前を『イーサネットメモリチェック』と指示する()

自己診断の起動方法を毎日午前1時と指示する()(a)

「1つの診断対象に対する診断」を設定することを指示する()

自己診断の診断対象をイーサネット1と指示する()

自己診断の診断内容をメモリチェックと指示する()
生成する()
毎日午前1時 :起動条件
生成する("イーサネットメモリチェック",毎日午前1時, イーサネット1)

イーサネットメモ
リチェック :診断(b)
チェック項目を加える(イーサネット1のメモリ読み書き)

図10(a)アクターはルーターへ自己診断の名前、起動方法、診断対象、診断内容を指示します。
(b)ルーターは起動条件と診断を生成し、関連付けます。

エンティティに着目したモデル

22

自己診断

シナリオ「SC0403: 自己診断を設定する(既存の自己診断を組み合わせた診断)」の相互作用
s d SC0403
ルーター

イーサネットメモ
リチェック :診断

イーサネットレジ
スタチェック :診断

山田太郎さん
自己診断を設定することを指示する()

設定する自己診断の名前を『イーサネット』と指示する()

自己診断の起動方法を毎週日曜日午前3時と指示する()「既存の自己診断を組み合わせた診断」を設定することを指示する()『イーサネットメモリチェック』自己診断を組み合わせるように指示する()(a)

『イーサネットレジスタチェック』自己診断を組み合わせるように指示する()
生成する()
毎週日曜日
午前3時 :起動条件
複製する()

イーサネットメモ
リチェックのクローン :診断複製する()

イーサネットレジ
スタチェックのク
ローン :診断

生成する("イーサネット", 毎週日曜日午前3時)(b)

イーサネット:診断

最初を設定する(イーサネットメモリチェックのクローン)
最後を設定する(イーサネットレジスタチェックのクローン)
次を設定する(イーサネットレジスタチェックのクローン)

図11(a)アクターはルーターへ自己診断の名前、起動方法、組み合わせる診断を指示します。
(b)ルーターは起動条件と診断を生成し、診断を複製し、関連付けます。

23

分析モデル

組込み分野のための UML モデル解説書

初期化時の相互作用s d 初期化
ルーター生成する("イーサネット")
イーサネッ
ト :機能ユニット生成する("イーサネット1")
イーサネット
1 :デバイス生成する("イーサネット1のレジスタ読み書き")
イーサネット1のレジスタ読み書
き :診断項目
生成する("イーサネット1のメモリ読み書き")
イーサネット1のメモリ読み書き :
診断項目
生成する("イーサネット1のループバック")イーサネット1の
ループバック :診断項目
イーサネット2も同様生成する("シリアル")

シリアル
:機能ユ
ニット
生成する("シリアル")シリアル :
デバイス

生成する("シリアルのレジスタ読み書き")
シリアルのレジ
スタ読み書き :診断項目
生成する("シリアルのメモリ読み書き")
シリアルのメモリ読み書き :診断項目
生成する("シリアルのループバック")シリアルのループバック :
診断項目

セキュリティ
監視 :アプリケーション

生成する("セキュリティ監視")

生成する("セキュリティ監視アプリケーション") セキュリティ監視
アプリケーション
:診断項目

図12

ユースケースにはありませんが、初期化の際のシーケンスです。
ルーター(組込み装置)は機能ユニットとアプリケーションを生成し、機能ユニットはデバイスを生成し、デバイスとアプリケーションは診断項目を生成します。
エンティティに着目したモデル

24

自己診断

PIM 設計モデル実装できるように、かつプラットフォームに依存しないように、分析クラスを詳細化します。具体的には以下の通りです。
(ⅰ)分析では診断の順番は診断インスタンスのネットワークで表されていました。このように実装すると、流れが分岐し、再度合流する処理や、終了を通知する処理の実現が煩雑になりそうです。このため、設計では、診断を順番に行うものと並行して行うものを導入します。
分析

設計

A 診断

B 診断

C 診断

順
番
に
実
行

D 診断

A 診断
並行に実行
B 診断

C 診断

D 診断

E 診断

E 診断

(ⅱ)並列に実行するために、スレッドを導入します。ただし、プラットフォームに依存しないように、汎用的なライブラリとして導入し、PSM で実装することにします。
(ⅲ)スレッドを利用して、診断を実行する「診断実行」クラスを導入します。
(ⅳ)自己診断を中止するため、実行する/した各診断にユニークな ID を付けます。これにより、自己診断を中止している最中に自己診断を完了してしまうなどのきわどいタイミングでも動作が不安定にならないようにします。
(ⅴ)各インスタンスを管理する「～管理」クラスを導入します。
(ⅵ)誘導可能性の明示など、設計モデルとして詳細化します。

25

PIM 設計モデル

組込み分野のための UML モデル解説書

静的モデル
ドメイン構成pk g 設計全体
診断ドメ イン対象ドメ インレポー ト ドメ イン

ユ ー テ ィリテ ィ

図13

設計ではクラスが非常に増えたため、3 個のドメインとユーティリティに分けました。
診断ドメイン：自己診断の中心となる「診断」クラスを中心とする部分
対象ドメイン：「診断対象」クラスを中心とする部分
レポートドメイン：「レポート」クラスを中心とする部分
ユーティリティ：スレッドなどを実現する汎用的なライブラリ

エンティティに着目したモデル

26

自己診断

「診断ドメイン (1)診断関連」のクラス構成
cl a s s 診断ドメ イン( 1) 診断関連
レポートドメイン
レポー ト-

書き込み排他制御: ミューテックス

+
+
+
+
+
+

デバイス名を書き込む(文字列) : void
出力する() : void
書き込み排他制御を開始する() : void
書き込み排他制御を終了する() : void
診断結果を書き込む(文字列, 成否, エラーコード) : void
生成する(文字列, 文字列) : void

-レポート
0..1

0..*
-起動条件

起動条件

診断

0..1

1

周期起動
-

初回診断日時: 日時
診断間隔: 秒+++間隔を取得する() : 秒
初回起動日時を取得する() : 日時
生成する(日時, 秒) : void-

キャンセルする診断ID: 診断ID
名前: 文字列

#
#
+
+
+
+
+

キャンセルか(診断ID) : boolean
キャンセルする診断IDを登録する(診断ID) : void
レポートを取得する() : レポート
起動条件を取得する() : 起動条件

1..*
{ordered}

診断する(診断ID) : void
診断する(診断ID, レポート) : void
診断を中止する(診断ID) : void
-診断

1..*

1

1

順番に実行す る診断
+
+
+
+
+

<<enumeration>>
成否
成功 {readOnly}
失敗 {readOnly}

並行に実行す る診断

診断する(診断ID) : void
診断する(診断ID, レポート) : void
生成する(文字列, 起動条件) : void
生成する(文字列) : void
付ける(診断) : void

診断結果

+
+
+
+
+

診断する(診断ID) : void
診断する(診断ID, レポート) : void
生成する(文字列, 起動条件) : void
生成する(文字列) : void
付ける(診断) : void

単一の対象に対す る診断-

エラーコード: エラーコード
成否: 成否++++

エラーコードを取得する() : エラーコード
削除する() : void成否を取得する() : 成否
生成する(成否, エラーコード) : void

+
+
+
+
+
+

チェック項目を加える(チェック項目) : void
レポートを書き込む() : void
診断する(診断ID) : void
診断する(診断ID, レポート) : void
生成する(文字列, 診断対象, 起動条件) : void
生成する(文字列, 診断対象) : void
0..*

0..*

-対象

-診断

対象ドメイン

1..*

1

診断対象
-

名前: 文字列++

チェック項目を検索する(文字列) : 診断項目
名前を取得する() : 文字列

-対象

-診断
項目 -

1..*

1..*

+
+
+

-診断項目
診断項目

名前: 文字列
診断する() : 診断結果生成する(文字列) : void
名前を取得する() : 文字列

図14

27

PIM 設計モデル

組込み分野のための UML モデル解説書

スレッドを作成する/しないが異なるため、診断クラスを「順番に実行する診断」クラスと「並行に実行する診断」クラスに分けました。また、「単一の対象に対する診断」も振る舞いが異なるので、異なるクラスとしました。
「単一の対象に対する診断」は文字通り単一の対象に対して、指定された診断項目の診断を実行します。
「並行に実行する診断」はスレッドを作成し、指定された診断を並行に実行します。
「順番に実行する診断」はスレッドを作成せず、指定された診断を順番に実行します。
「診断結果」と「診断」の関連は「診断する」操作の間だけ必要なので、依存としました。

エンティティに着目したモデル

28

自己診断

「診断ドメイン (2)診断管理関連」のクラス構成
cl a s s 診断ドメ イン( 2) 診断管理関連
レポートドメイン
-レポート

レポー ト
1

-

書き込み排他制御: ミューテックス

+
+
+
+
+
+

デバイス名を書き込む(文字列) : void
出力する() : void
書き込み排他制御を開始する() : void
書き込み排他制御を終了する() : void
診断結果を書き込む(文字列, 成否, エラーコード) : void
生成する(文字列, 文字列) : void<<interface>>
タスク+-レポート 0..1

実行する() : void

1

-レポート

0..*

0..*

診断タイマー タスク
+
+

-診断

0..*

診断タスク

実行する() : void
生成する(診断, レポート) : void-

診断ID: 診断ID

0..1

+
+

実行する() : void
生成する(診断, 診断ID, レポート) : void

0..1

-診断

1

診断

診断実行

1

-

キャンセルする診断ID: 診断ID
名前: 文字列

#
#
+
+
+
+
+

キャンセルか(診断ID) : boolean
キャンセルする診断IDを登録する(診断ID) : void
レポートを取得する() : レポート
起動条件を取得する() : 起動条件

診断する(診断ID) : void
診断する(診断ID, レポート) : void-

新規診断ID: 診断ID
診断IDを排他: ミューテックス

+
+
+
+
+

タイマーを設定する(診断) : void
新規診断IDを取得する() : 診断ID
診断する(文字列) : boolean
診断を中止する(文字列) : void
生成する() : void

診断を中止する(診断ID) : void
-診断

-診断

1

1

1

0..*
-診断管理

診断管理

1
+
+
+
+
+

1

検索する(文字列) : 診断
最初を取得する() : 診断
次を取得する() : 診断
生成する() : void登録する(診断) : 診断

0..*

-履歴
診断履歴エ ント リ

1

診断履歴
-エントリ

-

診断ID: 診断ID+++

診断IDを取得する() : 診断ID 0..*
診断を取得する() : 診断
生成する(診断ID, 診断) : void

1

+
+
+

検索する(診断) : 診断ID生成する() : void登録する(診断ID, 診断) : void

図15

診断管理は診断を集約し、管理します。
診断実行は診断の実行を司ります。タスクインタフェースを実装した診断タスクと診断タイマータスクを利用し、診断を実行します。
診断履歴は診断を行う際に診断履歴エントリを作成し、診断の履歴を管理します。履歴は自己診断を中止する際に使用します。

29

PIM 設計モデル

組込み分野のための UML モデル解説書「対象ドメイン」のクラス構成
cl a s s 対象ドメ イン

診断
設計::単一の対象に対す る診断
+
+
+
+
+
+

チェック項目を加える(チェック項目) : void
レポートを書き込む() : void
診断する(診断ID) : void
診断する(診断ID, レポート) : void
生成する(文字列, 診断対象, 起動条件) : void
生成する(文字列, 診断対象) : void
0..*

-対象

0..*

設計::診断対象
+
+

-対象

1..*

-下位
0..*

-デバイス
+
-上位
0..*

図16

機能ユニット管理は機能ユニットを集約し、管理します。
デバイス管理はデバイスを集約し、管理します。
アプリケーション管理はアプリケーションを集約し、管理します。

エンティティに着目したモデル30+生成する(文字列) : void
-アプリケーション

1
設計::ア プ リケー シ ョ ン管理

設計::デ バイス管理
検索する(文字列) : デバイス
最初を取得する() : デバイス
次を取得する() : デバイス生成する() : void登録する(デバイス) : 診断

診断する() : 診断結果生成する(文字列) : void
名前を取得する() : 文字列

1..*

1..*

1

+
+
+
+
+

名前: 文字列

設計::ア プ リケー シ ョ ン

生成する(文字列) : void

-デバイス

設計::機能ユ ニット 管理
検索する(文字列) : 機能ユニット
最初を取得する() : 機能ユニット
次を取得する() : 機能ユニット生成する() : void登録する(機能ユニット) : 診断

1..* +++

設計::デ バイス

1..*

1

1

+
+
+
+
+

設計::診断項目-

1..*

チェック項目を検索する(文字列) : 診断項目
名前を取得する() : 文字列生成する(文字列) : void
付ける(機能ユニット) : void

-機能ユ
ニット

-診断
項目

名前: 文字列

設計::機能ユ ニット
+
+

-診断項目

1..*

1

+
+
+
+
+

検索する(文字列) : アプリケーション
最初を取得する() : アプリケーション
次を取得する() : アプリケーション
生成する() : void登録する(アプリケーション) : 診断

自己診断

「レポートドメイン」のクラス構成
cl a s s レポー ト ドメ イン
設計::レポー ト 管理
+
+
+
+
+

検索する(文字列) : レポート最初を取得する() : レポート
次を取得する() : レポート生成する() : void登録する(レポート) : void
1
-レポート

0..*

設計::レポー ト-

書き込み排他制御: ミューテックス

+
+
+
+
+
+

デバイス名を書き込む(文字列) : void
出力する() : void
書き込み排他制御を開始する() : void
書き込み排他制御を終了する() : void
診断結果を書き込む(文字列, 成否, エラーコード) : void
生成する(文字列, 文字列) : void

-フォーマット

0..*

0..*

1

1

設計::フ ォ ー マット-出力方法
設計::出力方法-

名前: 文字列-

名前: 文字列+++

デバイス名を変換する(文字列) : 文字列
診断結果を変換する(文字列, 成否, エラーコード) : 文字列生成する(文字列) : void++

出力する() : void
生成する(文字列) : void

-フォーマット

1..*

1

-出力方法

1

設計::フ ォ ー マット 管理
+
+
+
+
+

1..*

設計::出力方法管理

検索する(文字列) : フォーマット
最初を取得する() : フォーマット
次を取得する() : フォーマット
生成する() : void登録する(フォーマット) : void

+
+
+
+
+

検索する(文字列) : 出力方法
最初を取得する() : 出力方法
次を取得する() : 出力方法
生成する() : void登録する(出力方法) : void

図17

レポート管理はレポートを集約し、管理します。
フォーマット管理はフォーマットを集約し、管理します。
出力方法管理は出力方法を集約し、管理します。

31

PIM 設計モデル

組込み分野のための UML モデル解説書「ユーティリティ」のクラス構成
cl a s s ユ ー テ ィリテ ィ+<<interface>>
タスク実行する() : void++

別スレッドやタイマーで実行したい場合、このインタフェースを実現するクラスを作成します。「実行する」
操作を再定義し、所望の動作を記述します。

<<interface>>
スレッドプ ー ル
起動する(タスク) : タスクハンドル
起動する(int, タスク[]) : void++<<interface>>
タスク ハンドル
取り消す() : void
終了したか() : boolean

別スレッドで実行したい場合
・「タスク」インタフェースを実現するクラスのインスタンスを引数とし、「起動する」操作を実行します。別スレッドで引数のクラスのインスタンスの「実行する」操作が実行され、「タスクハンドル」インスタンスが返さ
れます。
または、
・「タスク」インタフェースを実現するクラスのインスタンスの配列を引数とし、「起動する」操作を実行します。引数の配列数分の別スレッドで、インスタンスの「実行する」操作が実行されます。すべての操作が終了した時点で操作を終了します。
※スレッドは必要に応じて作成され、動作終了時にスレッドプールに保持され、再利用されます。

タスクハンドルを介して、実行中(後)の別スレッドを「取り消す」や、「終了したか」状態を調べることができます。
※注意：「取り消す」はスレッドを強制的に終了させるため、プラットフォー
ムにより資源の解放がされないなどが起きる可能性があります。

+<<interface>>
タイマー
登録する(タスク, 日時, 間隔) : タイマータスクハンドル

タイマーで実行したい場合、「タスク」インタフェースを実現するクラスのインスタンスを引数とし、「登録する」操作を実行すると、タスクが登録され、「タスクハンドル」インスタ
ンスが返されます。指定した時間から指定した間隔でタスクのインスタンスの「実行する」操作が定期的に実行されます。この時のスレッドは登録したスレッドとは別で新規に作成されたものになります。

<<interface>>
タイマー タスク ハンドル
+ 取り消す() : void
タスクハンドルを介して、登録したタイマータスクを取り消すことができます。

++<<interface>>
ミュ ー テ ック ス
アンロックする() : void
ロックする() : void

図18

エンティティに着目したモデル

32

自己診断

動的モデル
PIM 設計モデルのクラス図を踏まえ、再度シーケンス図を作成します。

ユースケース「UC01:自己診断を行う」の相互作用
s d 設計U C01
UI

:診断実行

:診断管理

:スレッド
プール

日次 :順番に実行する診断:診断履歴:山田太郎さん
診断開始を指示する("日次")
診断する("日次") :boolean
検索する("日次") :診断
(a)

:日次

新規診断IDを取得する() :診断ID生成する(日次,診断ID1,0)

日次タスク:診断タスク

登録する(診断ID1, 日次)(b)

起動する(日次タスク) :タスクハンドル
実行する()
診断する(診断ID1)(c)『設計UC01日次』参照

図19(a)アクターから診断開始の指示を受けると、UI は診断実行に「診断する」メッセージを送信します。
(b)診断実行は診断管理から該当する診断インスタンス(「日次: 順番に実行する診断」)を検索し、診断タ
スクを生成し、診断履歴に登録し、生成した診断タスクをスレッドプールへ渡して診断を起動します。
(c)スレッドプールは診断タスクへ「実行する」メッセージを送信し、「日次: 順番に実行する診断」に診断を実行させます。

33

PIM 設計モデル

組込み分野のための UML モデル解説書

s d 設計U C01日次
日次 :順番 イーサネット簡に実行す
易 :並行に実る診断
行する診断

シリアル簡易:単一の対象に対する診断セキュリティ監視アプ
リケーション :単一の対象に対する診断

レポート1 :
レポート

出力方法1
:出力方法

診断する(診断ID1)
キャンセルか(診断ID1) :boolean
診断する(診断ID1,レポート1)『設計UC01イーサネット簡易』参照
キャンセルか(診断ID1) :boolean
診断する(診断ID1,レポート1)(a)
キャンセルか(診断ID1) :boolean
診断する(診断ID1,レポート1)
書き込み排他制御を開始する()

出力する()

出力する()(b)

書き込み排他制御を終了する()

図20(a)「日次:順番に実行する診断」は「診断する」メッセージを受信すると、キャンセル(診断中止があるか)をチェックしながら、集約する診断インスタンスへ順次「診断する」メッセージを送信します。
(b)(すべての診断を実行し終わると)レポートに排他制御を行い、出力させます。

エンティティに着目したモデル

34

自己診断

s d 設計U C01イー サネット 簡易
イーサネット
簡易 :並行に実行する診断:スレッド
プール

イーサネット1簡
易 :単一の対象に対する診断イーサネット2簡
易 :単一の対象に対する診断診断する(診断ID1,レポート1)生成する(イーサネット1簡易,診断ID1,レポート1)
イーサネット1簡易タスク:診断タスク
生成する(イーサネット2簡易,診断ID1,レポート1)

イーサネット2簡易タスク :診断タスク

キャンセルか(診断ID) :boolean(a)

起動する(2, イーサネット1簡易とイーサネット1簡易)
実行する()
実行する()(b)

診断する(診断ID1,レポート1)
診断する(診断ID1,レポート1)『設計UC01イーサネット1簡易』参照

図21(a)「イーサネット簡易:並列に実行する診断」は「診断する」メッセージを受信すると、診断タスクを生成し、キャンセル(診断中止があるか)をチェックし、生成した診断タスクをスレッドプールへ渡して診断を起動します。
(b)スレッドプールはスレッドを使用して、各診断を並列に実行させます。

35

PIM 設計モデル

組込み分野のための UML モデル解説書
s d 設計U C01イー サネット 1簡易
イーサネット1簡
易 :単一の対象に対する診断イーサネット1のレジスタ読み書
き :診断項目

イーサネット1のメモリ読み書き :診断項目

イーサネット1:デバイス

レポート1 :
レポート

フォーマット
1 :フォーマット

診断する(診断ID1,レポート1)
キャンセルか(診断ID1) :boolean
診断する() :診断結果生成する(成功,0)
イーサ1レ
ジスタ :診断結果(a)

キャンセルか(診断ID1) :boolean
診断する() :診断結果生成する(成否, エラーコード)
イーサ1メ
モリ :診
断結果

(b)
レポートを書き込む()
書き込み排他制御を開始する()
名前を取得する() :文字列
デバイス名を書き込む(イーサネット1)

デバイス名を変換する(
イーサネット1) :文字列

名前を取得する() :文字列
成否を取得する() :成否
エラーコードを取得する() :エラーコード
診断結果を書き込む("イーサネット1のレジスタ読み書き",成功,0)

診断結果を変換する(文字列, 成否, エラーコード) :文字列

名前を取得する() :文字列
成否を取得する() :成否
エラーコードを取得する() :エラーコード
診断結果を書き込む("イーサネット1のメモリ読み書き",成功,0)

診断結果を変換する(文字列, 成否, エラーコード) :文字列

書き込み排他制御を終了する()

図22(a)「イーサネット 1 簡易:単一の対象に対する診断」は「診断する」メッセージを受信すると、キャンセル(診断中止があるか)をチェックしなら、診断項目に診断を行わせます。
(b)(すべての診断を実行し終わると)レポートに書き込みます。

エンティティに着目したモデル

36

自己診断

ユースケース「UC02:自己診断を中止する」の相互作用
s d 設計U C02
UI

:診断実行

:診断管理

:スレッド
プール

日次 :順番に実行する診断:診断履歴:山田太郎さん
診断開始を指示する("日次")
診断する("日次") :boolean
検索する("日次") :診断:日次

新規診断IDを取得する() :診断ID生成する(日次,診断ID1,0)

日次タスク:診断タスク

登録する(診断ID1, 日次)(a)

起動する(日次タスク) :タスクハンドル『設計UC02日次』参照
実行する()
診断する(診断ID1)

自己診断の中止を指示する("日次")
診断を中止する("日次")検索する("日次") :診断

図示できていませんが、「診断する」メッセージを実行中に「自己診断の中止を指示する」メッセー
ジが送信されています:日次検索する(日次) :診断ID:診断ID1
診断を中止する(診断ID1)
キャンセルする診断IDを登録する(
診断ID1)(b)

図23(a)アクターから診断開始の指示を受けると、ルーターは「ユースケース「UC01:自己診断を行う」のシー
ケンス図」と同様に動きます。
(b)アクターから診断の中止の指示を受けると、診断実行は診断管理から該当する診断インスタンスを検索し、「診断を中止する」メッセージを送信します。

37

PIM 設計モデル

組込み分野のための UML モデル解説書

s d 設計U C02日次
日次 :順番に実行する診断イーサネット簡
易 :並行に実行する診断

レポート1 :
レポート

出力方法1
:出力方法

診断する(診断ID1)『設計UC02イーサネット簡易』参照
キャンセルか(診断ID1) :boolean(a)

診断する(診断ID1,レポート1)

キャンセルか(診断ID1) :boolean(b)「診断する」メッセージと「キャンセルか」メッセージの間に「診断を中止する」メッセージを受信し、「キャンセルする診
断IDを登録する」が行われています。よって、「キャンセル
か」メッセージの戻り値は真になります

出力する()
書き込み排他制御を開始する()
出力する()
書き込み排他制御を終了する()

図24(a)「日次:順番に実行する診断」は「診断する」メッセージを受信すると、キャンセル(診断中止があるか)をチェックしながら、集約する診断インスタンスへ順次「診断する」メッセージを送信します。
(b)キャンセルがあると、「診断する」メッセージの送信を中止します。レポートに排他制御を行い、出力させます。

エンティティに着目したモデル

38

自己診断

s d 設計U C02イー サネット 簡易
イーサネット
簡易 :並行に実行する診断:スレッド
プール

イーサネット1簡
易 :単一の対象に対する診断イーサネット2簡
易 :単一の対象に対する診断診断する(診断ID1,レポート1)生成する(イーサネット1簡易,診断ID1,レポート1)
イーサネット1簡易タスク :
診断タスク
生成する(イーサネット2簡易,診断ID1,レポート1)(a)

イーサネット2簡易タスク :診断タスク

キャンセルか(診断ID) :boolean
起動する(2, イーサネット1簡易とイーサネット1簡易)
実行する()
実行する()(b)

診断する(診断ID1,レポート1)
診断する(診断ID1,レポート1)『設計UC02イーサネット1簡易』参照
図25(a)「イーサネット簡易:並列に実行する診断」は「診断する」メッセージを受信すると、診断タスクを生成し、キャンセル(診断中止があるか)をチェックし、生成した診断タスクをスレッドプールへ渡して診断を起動します。
(b)スレッドプールはスレッドを使用して、各診断を並列に実行させます。

39

PIM 設計モデル

組込み分野のための UML モデル解説書
s d 設計U C02イー サネット 1簡易
イーサネット1簡
易 :単一の対象に対する診断イーサネット1のレジスタ読み書
き :診断項目

イーサネット1:デバイス

レポート1 :
レポート

フォーマット
1 :フォーマット

診断する(診断ID1,レポート1)
キャンセルか(診断ID) :boolean
診断する() :診断結果(a)生成する(成功,0)
イーサ1レ
ジスタ :診断結果(b) 図示できていませんが、2個の「キャンセル
か」メッセージの間に「診断を中止する」メッセー
ジを受信し、「キャンセルする診断IDを登録する」が行われています。よって、後の「キャンセルか」
メッセージの戻り値は真になります(c)
キャンセルか(診断ID) :boolean
名前を取得する() :文字列

デバイス名を変換する(
イーサネット1) :文字列

デバイス名を書き込む(イーサネット1)
名前を取得する() :文字列(d)

成否を取得する() :成否診断結果を変換する(
文字列, 成否, エラー
コード) :文字列

エラーコードを取得する() :エラーコード
診断結果を書き込む("イーサネット1のレジスタ読み書き",成功,0)

図26(a)「イーサネット 1 簡易:単一の対象に対する診断」は「診断する」メッセージを受信すると、キャンセル(診断中止があるか)をチェックしなら、診断項目に診断を行わせます。
(b)図示できていませんが、「イーサネット 1 簡易:単一の対象に対する診断」からの 2 個の「キャンセル
か」メッセージの途中で、「診断を中止する」メッセージを受信しています。
(c)2 個目の「キャンセルか」メッセージの戻り値が真になり、診断を中止します。
(d)レポートを書き込みます。
※「キャンセルか」の判断は診断 ID を用いて行います。自身の診断 ID と「診断」クラスの「キャンセルする診断 ID」属性が合致すると、キャンセルとなり、「キャンセルか」メッセージの戻り値が真になります。このモデルでは「キャンセルする診断 ID」属性が 1 個のため、一時点でのキャンセルは一つの診断だけですが、「キャンセルする診断 ID」を複数持つことにより、一時点で複数の診断のキャンセルができるようになります。

エンティティに着目したモデル

40

自己診断

シナリオ「SC0401: 自己診断を設定する(1 つの診断対象に対する診断)」の相互作用
s d 設計SC0401
UI

:デバイス
管理

イーサネット1:デバイス

イーサネット1のメモリ読み書き :診断項目:山田太郎さん

:診断管理

:診断実行

自己診断を設定することを指示する()
設定する自己診断の名前を『イーサネットメモリチェック』と指示する()
自己診断の起動方法を毎日午前1時と指示する()「1つの診断対象に対する診断」を設定することを指示する()

自己診断の診断対象をイーサネット1と指示する()(a)

検索する(”イーサネット1") :デバイス:イーサネット1

自己診断の診断内容をメモリチェックと指示する()
チェック項目を検索する("メモリチェック") :チェック項目:イーサネット1のメモリ読み書き

生成する(明日午前1時,86400)

毎日午前1時 :周期起動

生成する("イーサネットメモリチェック",毎日午前1時,イーサネット1)(b)

イーサネットメモリ
チェック :単一の対象に対する診断チェック項目を加える(イーサネット1のメモリ読み書き)登録する(イーサネットメモリチェック) :診断
タイマーを設定する(イーサネットメモリチェック)『設計タイマーを設定する』参照

図27(a)アクターはルーターへ自己診断の名前、起動条件、診断対象、診断内容を指示します。
(b)UI は起動条件と診断を生成し、関連付け、診断を登録します。

41

PIM 設計モデル

組込み分野のための UML モデル解説書

s d 設計 タイマー を設定す る
:診断実行

:診断

:周期起動

:タイマー

タイマーを設定する(診断)
レポートを取得する() :レポート
:診断タイ
マータスク

生成する(診断, レポート)
起動条件を取得する() :起動条件
初回起動日時を取得する() :日時(a)

間隔を取得する() :秒
登録する(タスク, 日時, 間隔) :タイマータスクハンドル

図28(a)「診断実行」は「タイマーを設定する」メッセージを受信すると、必要な情報を取得し、診断タイマー
タスクを生成し、生成した診断タイマータスクをタイマーに登録します。

エンティティに着目したモデル

42

自己診断

シナリオ「SC0403: 自己診断を設定する(既存の自己診断を組み合わせた診断)」の相互作用
s d 設計SC0403
UI

:診断管理

:診断実行

:山田太郎さん
自己診断を設定することを指示する()

設定する自己診断の名前を『イーサネット』と指示する()
自己診断の起動方法を毎週日曜日午前3時と指示する()「既存の自己診断を組み合わせた診断」を設定することを指示する()『イーサネットメモリチェック』自己診断を組み合わせるように指示する()
検索する("イーサネットメモリチェック") :診断(a):イーサネットメモリチェック『イーサネットレジスタチェック』自己診断を組み合わせるように指示する()
検索する("イーサネットレジスタチェック") :診断:イーサネットレジスタチェック生成する(日曜日午前3時,604800)

毎週日曜
日午前3時
:周期起動

生成する("イーサネット",毎週日曜日午前3時)

(b)

イーサネッ
ト :順番に実行する診断付ける(イーサネットメモリチェック)付ける(イーサネットレジスタチェック)登録する(イーサネット,) :診断
タイマーを設定する(イーサネット)『設計タイマーを設定する』参照

図29(a)アクターはルーターへ自己診断の名前、起動方法、組み合わせる診断を指示します。
(b)UI は起動条件と診断を生成し、診断を複製し、関連付けます。

43

PIM 設計モデル

組込み分野のための UML モデル解説書

メタファを使ったモデル
モデリングのコンセプト
装置の自己診断機能をモデリングするにあたり、まずは診断の意味や目的を考え、日常生活の診断に適用できる概念モデルを作成してみます。診断についての理解を深め、概念を明確にすることで、分析モデル
や設計モデルの作成に役立つと思います。

1.

診断って何だろう？
「診断」を国語辞書で調べてみました。(大辞林より)
しんだん 【診断】 （名）スル(1) 医者が患者を診察し、病状を判断すること。
・ 「高血圧と診断する」
・ 「診断を下す」(2) 物事を調べて欠陥がないかなどその状態を判断すること。
・ 「企業診断」

つまり、診断とは病気や欠陥など悪いところがないか調べることです。装置の場合は故障箇所や不具合箇所がないか調べることです。悪いところに限らず、悪くなりかけているところや悪くなりそうなところも調べられると、よりよい診断といえるでしょう。
次に、「診断」の類義語を挙げてみます。これらも「診断」とみなしていいでしょう。
 診断の類義語: 検診、点検、検査

ついでに、「自己」とは、国語辞書で調べるまでもなく「自分自身で」ということ。つまり、医者が自分を診断する、企業が自社を診断するということで、装置であれば装置自身で装置内部を診断することです。

メタファを使ったモデル

44

自己診断

2.

診断する目的は何だろう？
診断して悪いところが見つかったらどうしますか？
・医者に言われたなら、病気を治療する
・企業に欠陥があるなら、正す、改善する・装置であれば、不具合箇所を修理、修復、交換する
悪いところをなおすのはなぜですか？
・人であれば、長生きしたいから。重症になると、介護が必要になったり、お金がかかったりするから。
・企業であれば、企業存続にかかわるから。
・装置であれば、業務に支障が出るから。
悪いところをなおすのは誰ですか？
・他者: 医者、業者
・自己: 自分、自社以上のことから、問題箇所や予防箇所がないかを診断することで、自己修復あるいは他者に治療・改善・修理依頼するきっかけを知ることができ、診断対象を長生き・長持ちさせるのが目的と考えられます。
3.

身近な診断には何があるだろう？
身近にある診断、点検、検査を探してみました。
 健康診断・毎年健康診断を受ける。
・Ｆ社では、5 年に 1 回人間ドックに変わる。40 才以上は毎年人間ドック。
・健康診断と人間ドックでは診断項目が異なる。年齢により多少診断項目が異なる。
 車検
・新車は 3 年目、以降は 2 年毎。車検の他に 6 ヶ月点検や 12 ヶ月点検もある。
・点検時期によって点検内容が異なる。
 温水洗浄便座
・自宅の温水洗浄便座のコンセントプラグに「テスト」ボタンがある。
・ボタンを押すと正常に動作するか診断してくれるようだ。
・手洗い時に水が跳ねたり湿気を含んでショートしたりする心配があるからだろうか？
 分電盤
・自宅の分電盤の蓋をあけると「テスト」ボタンがある。
・漏電やショートしていないか診断してくれるのだろう。
 消防設備点検
・自宅マンションでは、年に 2 回、火災報知器が正しく動作するか調べに来てくれる。
・会社でも、年に 2 回くらい消防設備を点検しているのを見かける。

45

組込み分野のための UML モデル解説書

4.

診断に関する共通項目には何があるだろう？
前述の身近な診断(点検、検査を含む)において、共通する項目を挙げてみます。
対象物
共通項目
人

5.

車

温水洗浄便座

分電盤

消防設備

テスト

消防点検
防災点検

診断名

健康診断
人間ドック

車検
定期点検

テスト

診断時期

年1回
望んだとき

初回 3 年
以降 2 年毎ボタンを押した ボタンを押
とき
したとき

半年毎

診断対象

本人、子供、社員

車

電気設備

電気設備

消防設備

診断依頼者

本人、親、会社

所有者

家人

家人

本人、管理会
社、企業

診断場所

病院、健康管理室

車ディーラー、
車検場

設置場所

設置場所

設置場所

診断実施者

医者

メカニック

装置

装置

業者

診断項目

血液、血圧、視力、聴 エンジン、ブレ
力、胃、肺、心臓など ーキ、オイル、
タイヤなど

ショート

漏電、ショ
ート

熱検知、煙検知、防炎扉、シ
ャッター等

診断結果

健康ランク、問題部
位、状態など

ブザー？

ブザー？

異常なし
異常個所

問題なし、
要修理箇所、予防修理箇所

診断シナリオ
共通項目を使って、診断するときの手順(シナリオ)を考えてみます。

 登場人物(アクター)は「診断依頼者」「診断実施者」「診断対象」の 3 人。
 本人が本人の診断を依頼すれば「診断依頼者」と「診断対象」は同一です。
 「診断依頼者」は、「診断時期」になった「診断」がないか定期的に確認し、あれば「診断実施者」に「診断対象」の「診断」を依頼します。
 「診断時期」に関係なく、「診断対象」が調子悪くなったり、なんとなく気になったときに「診断依頼者」が「診断実施者」に「診断対象」の「診断」を依頼することもあります。
 「診断実施者」は、「診断項目」毎に「診断対象」を「診断」し、「診断結果」を記入して「診断依頼者」に通知します。
 「診断対象」は「診断部位」を診せます。
 「診断依頼者」は、「診断結果」を確認し、問題があれば治療や修理などを施します。

メタファを使ったモデル

46

自己診断

「診断」のクラス構成
class 診断:概念モデル
診断時期

健康診断では「１歳までは3ヶ月毎」「１歳以上は毎年」など

1

確認する

健康診断での
「親」

参照者
*

情報

確認する

依頼元 *

健康診
断での
「医者」

診断実施者
実施する(診断)
診断者

1

1

*
診断者

確認する

1

診断結果

状態
0..1 所見
結果 *

特定する
診断部位

対象 1

担当者 *
診断する

結果

*

健康診
断での
「子供」

依頼する
依頼先 1 依頼者 *

*
診断

診断名
* 診断説明
診断

依頼する

1

診断

実施日 1

健康診断では「血液検査」「視力検査」「聴力検査」「心電図検査」など。
さらに「血液検査」は「血糖値検査」「コレステロール値検査」などに細分化。

診断項目

診断 1
診断依頼者

1

一度も診断してない場合は、誕生日や購入日などを前回実施日とする時期 *「健康診断」「防災点検」「車検」など

診断日時

前回実施日

診断周期
診断条件

1

*

診断対象
診断対象名

* 診せる(診断部位名)
診断対象

健康診断では「血液」「目」「耳」「心臓」「肺」「胃」など。
さらに「血液」は「白血球」「赤血球」「糖分」「鉄分」などに細
分化。

記入する
図30

 「診断」には「診断名」があり、いつ頃(診断時期)、誰/何/どの部位 (診断対象) を、どのように診断す
るのか(診断説明)が分かります。
 「診断」には「診断時期」があるものとないものがあります。
 「診断時期」がある場合、「前回診断日」から「診断周期」が経過していたら「診断」する時期です。
一度も診断してない場合、誕生日、購入日、設置日、使用開始日などを「前回診断日」とします。
 「診断時期」には「診断条件」がある場合があります。車であれば「初回は 3 年目」「以降は 2 年毎」
といったように「経年」により「診断周期」が変化します。
 「診断時期」に関係なく、「診断対象」が調子悪くなったときやなんとなく気になるときなどに、「診断依頼者」が「診断実施者」に「診断対象」の「診断」を依頼することもできます。
 「診断」は「診断項目」に細分化されることがあります。さらに「診断項目」が詳細化されることもあります。
 「診断実施者」は「診断」を実施し、「診断」に応じた「診断結果」を記入します。「診断項目」がある場合、「診断項目」毎に「診断結果」を記入したあと、それを要約して「診断」の「診断結果」に記入します。
 「診断実施者」は、専門の「診断担当者」に「診断」を依頼することもあります。さらに「診断担当者」は他の「診断担当者」に手伝いを依頼することもあります。
 「診断対象」は「診断部位」を診せることができます。あるいは、診せる方法があります。

47

組込み分野のための UML モデル解説書「診断」の相互作用sd 診断:概念モデル
診断依頼者

診断

診断時期

前回実施日 :
診断日時

診断実施者

診断対象

診断時期か確認する()
診断時期か確認する()
経過日数を確認する()

依頼する(診断)
診断対象を特定する():診断対象
診断する()

診断結果を記入する()
診断結果記入する()
実施日 :診断日時記入する()

前回実施日を更新する()
更新する()

診断完了を通知する(診断)
診断結果を確認する()
確認する()

図31

処理の流れをシーケンス図で書いたものです。
シーケンス図により、クラスに追加・変更する操作がわかってきます。

メタファを使ったモデル

48

自己診断

分析モデル
要求仕様で出てくる要素として「自己診断」「診断対象」「診断項目」「診断結果」があります。それらの関係に重点を置き、概念モデルを参考にしつつ、ユースケースをできるだけ忠実にモデル化してみます。
なお、診断対象がどのように診断するのかについては関知せず、並行実施するか順次実施するかも診断
対象にまかせることにし、診断を実施することによって診断結果がレポートされることに重点を置きます。

静的モデル
概念モデルを元に分類したパッケージ

pkg 自己診断分析パッケージ図
診断情報

診断結果
<<flow>><<use>>

診断対象

診断依頼<<call>>図32

概念モデルで出てきた「診断依頼者」は「診断依頼」とします。ここには、管理者からの「自己診断」の要求を受け付けて、「診断対象」に依頼するまでの部分を担当します。
自己診断では、「診断対象」自身が「診断実施」するので、「診断実施」は「診断対象」にまとめます。
「診断依頼」と「診断対象」の間でやりとりされる情報を「診断情報」としてまとめます。ここには「診断」と「診断結果」が入ります。
概念モデルでの「診断時期」は、自動診断の設定情報として「自己診断」に含めることにします。「診断日時」は要求仕様には出てこなかったので扱わないことにします。
それらを踏まえてクラス化していきます。

49

分析モデル

組込み分野のための UML モデル解説書

クラス構成

class 自己診断分析クラス図
診断依頼
手動診断

自動診断

診断条件

自己診断を設定する()

*

1

出力先

選定元

自己診断

1

起動方法: String
診断対象: String
診断内容: String
組合せ: String

自己診断を実施する()
自己診断を中止する()
依頼元 *
1 作成元

診断出力

1

選定する

診断結果をレポートする(診断結果)
通知先

1 参照元

1

通知する

作成する

参照する

診断情報
*

*

診断依頼

中継

* 診断結果

診断

診断結果

診断名: String

依頼する

結果: boolean
エラーコード: int

診断名を確認する()
診断結果をレポートする(診断結果)
* 診断名
通知先
1
確認する

* 診断結果

診断対象
診断 1

1

記入する

通知する

確認元

1

診断対象

通知元

1 診断元

診断項目

名称: String
実施する(診断)
中止する(診断)

機能ユニット 外部
1

1..*

1

内部
構成する

デバイス

1..*

図33

メタファを使ったモデル

50

アプリケーション

自己診断「自己診断」には、機器管理者の要求により起動される「手動診断」と、予め設定された「診断条件」に合わせて起動される「自動診断」があります。いずれも「自己診断」のサブクラスです。
「自己診断」を実施する際には、「診断結果」をレポートするための「診断出力」を用意しておきます。
コンソール出力、ロギング出力、LED 点滅など、いろいろな「診断出力」の実装が考えられます。
「診断対象」には「機能ユニット」「デバイス」「アプリケーション」があります。いずれも「診断対象」のサブクラスです。「機能ユニット」はいくつかの「デバイス」から構成されます。
「診断対象」には「診断項目」が決まっています。「自己診断」を実施する毎に「診断結果」がレポー
ト(通知)されます。「診断項目」に応じた診断が行われるので「診断項目」も「診断対象」のサブクラスにして診断の実施と中止ができるようにしておきます。
「診断対象」で診断を実施するときは、何の診断なのかを表す診断名と、「診断結果」をレポートできる「診断」を渡すことにします。「診断」は並列動作可能なので、「診断結果」は非同期で通知できるようにしておきます。「診断結果」が通知されたら診断完了したとみなすことができます。つまり、「診断」には診断実施中なのか診断完了したのかといった状態が存在することになります。
要求仕様にできるだけ忠実にしたためこのようなクラス図になりましたが、「診断」自身が診断実施できた方がいいなどの見直しは PIM 設計で行うことにします。

ユースケース記述に記載されたインスタンスに、関連しそうなインスタンスを加えたインスタンス図を以下に示します。
診断毎に診断結果が生成され、診断出力されることになります。

オブジェクト構成
object 自己診断分析インスタンス図
診断実施される毎に生成、診断出力
されたら破棄

すべて :診断項目

診断ボタン :手動診断
イーサネット :診断

メモリ :診断項目

LED :診断出力

すべて :診断項目

結果#1 :診断結果

結果#2
:診断結果
:診断結果
結果#3 :診断結果
ルータ :機能ユニット

イーサネット#1 :デバイス

レジスタ :診断項目

毎日午前1時 :自動診断

メモリ :診断項目

イーサネットのメモリ :診断

すべて :診断項目

ロギング :診断出力

イーサネット#2 :デバイス

結果#4 :診断結果

レジスタ :診断項目

結果#5 :診断結果

メモリ :診断項目

結果#6 :診断結果

図34

51

分析モデル

組込み分野のための UML モデル解説書

動的モデル
診断を実施および診断を中断するときの相互作用
sd 自己診断分析コミュニケーション図
:自己診断

:診断出力

1: 実施する(診断)1.5: 診断結果をレポートする(診断結果)

1.2: 中止する(診断)
:診断対象

:診断

1.1: 実施する(診断)1.4: 診断結果をレポートする(診断結果)

1.3: 中止する(診断)
:診断項目

図35

管理者の指示により自己診断を実施し、診断を中止するときの相互作用
sd 自己診断分析シーケンス図(診断中止時)

機器管理者

診断ボタン :
手動診断

LED :診断出力

ルータ :機能ユニット

イーサネット#1 :デバイス

すべて#1 :診断項目

自己診断を実施する()
取得する()
取得する()
イーサネット:診断
実施する(診断)
診断名を確認する() :String
実施する(診断)
診断名を確認する() :String
実施する(診断)

自己診断を実施する()

自己診断を中止する()
中止する(診断)
診断名を確認する() :String
中止する(診断)
診断名を確認する() :String
中止する(診断)

自己診断を中止する()
結果#2 :診断結果

診断結果をレポートする(診断結果)

診断結果をレポートする(診断結果)
診断結果確認()
診断LEDを消灯する()

図36

メタファを使ったモデル

52

自己診断

PIM 設計モデル
分析モデルの関係性を崩さないように、依存性をできるだけ排除したコンパクトなモデルにします。

静的モデル
class 自己診断PIM設計:クラス図
診断スイッチ

診断コマンド

診断予約

電源投入時

1000枚印刷毎

毎日午前1時削除する(自動診断) : void登録する(自動診断) : void
起動元 1
起動する
診断依頼

起動内容 *
手動診断

自動診断
起動内容 起動条件
設定する(起動方法) : void
1
判定する
設定する(診断対象) : void 1
設定する(診断名) : void

自己診断

取得元

出力元
1

*

1

コンソール出力

診断出力

出力先

出力する

起動方法

ロギング出力レポートする(診断結果) : void

参照元 0..1
LED表示
取得する

参照する
診断情報
診断結果 *
診断
診断

診断名: String

結果

1 判明する
実施する() : void0..1
中止する() : void
通知する(診断結果) : void
通知先 *
依頼元 *
依頼する

診断結果
結果: boolean
エラーコード: int
結果

0..1

記入する

通知する
診断対象

依頼先

1

通知元 1
診断対象

診断対象名: String

診断元実施する(診断) : void
中止する(診断) : void

1

部分

全体

1..*
{ordered}
構成する
1
診断ノード

診断項目

追加する(診断対象) : void
削除する(診断対象) : void

最上位
診断対象
1

診断装置

機能ユニットデバイス

アプリケーション

診断装置を取得する() : 診断対象

図37

「自動診断」は、「診断予約」として複数登録できるようにしました。ただし、「診断予約」は大抵の装置に備わっていると思われるスケジュール機能を利用することを想定し、本モデルでは詳しく取り上げないことにします。

53

PIM 設計モデル

組込み分野のための UML モデル解説書

分析モデルでは「自己診断」から「診断対象」に診断実施を指示していましたが、パッケージの独立性を高めるため、「診断」で診断実施できるようにし、「診断依頼」パッケージと「診断対象」パッケージを完全分離させました。
「診断」は、生成したあと 1 度だけ診断実施して破棄することができますが、「診断」をひとつ生成したあと何度も診断を実施して最新の診断結果を受け取ることもできます。
分析モデルでの「診断対象」は「診断項目」を保持していましたが、「機能項目」自体も「診断対象」のサブクラスであり、その構造がファイルシステムの「ディレクトリ」と「ファイル」のツリー構造に類似しているので、「ディレクトリ」相当を「診断ノード」とし、「ファイル」相当を「診断項目」としました。
これにより、診断対象がファイルのディレクトリ名のように指定でき、以下のように診断対象を文字列で指定できるようにします。
・すべての診断: "*"・メイン基板のすべての診断: "main/*"・メイン基板のメモリ診断 : "main/memory"
・すべての基板のメモリ診断: "*/memory"
なお、「診断ノード」から下位の「診断対象」に診断を依頼するには、「診断」オブジェクトが必要になります。依頼元から渡ってきた「診断」をそのまま渡すと、複数の「診断結果」が「診断出力」に渡ることになり、診断経過が出力されるような動作になります。ひとつの診断毎に「診断結果」を待ち合わせるよ
うな場合には、一時的な「診断」オブジェクトを生成して診断依頼し、診断結果を待ち合わせるようにする必要があります。

オブジェクト図は分析モデルと同等です。

メタファを使ったモデル

54

自己診断

動的モデル
メモリ診断を実施するときの相互作用
sd 自己診断PIM設計:コミュニケーション図
コンソール出力 :診断出力

1.12: レポートする(診断結果)
すべてのメモリ :手動診断

1.11: 通知する(診断結果)

1: 実施する(診断)ルータ装置 :診断ノード

1.1: 実施する()

1.3: 実施する()

すべてのメモリ :診断

1.2: 実施する(診断)

すべてのメモリ :診断

1.10: 通知する(診断結果)

メイン基板 :診断ノード

1.8: 通知する(診断結果)

イーサネット :診断ノード

1.7: 実施する()

1.5: 実施する()
すべてのメモリ :診断

1.6: 実施する(診断)1.4: 実施する(診断)

すべてのメモリ :診断

1.9: 通知する(診断結果)

メイン基板メモリ :診断項目

イーサネットメモリ :診断項目

図38

メイン基板のメモリ診断とイーサネットのメモリ診断は並列動作し、イーサネットのメモリ診断の方が先に終わる順序にしてあります。

55

PIM 設計モデル

組込み分野のための UML モデル解説書

メイン基板とイーサネット基板それぞれに搭載されたメモリを診断するときの相互作用
sd 自己診断PIM設計:シーケンス図
手動診断

診断装置

メイン基板 :
診断対象 A

機器管理者

イーサネット:診断対象

自己診断を実施する()
コンソール出力:診断出力
診断装置を取得する() :診断対象
メインメモリへの診断依頼部分は省略

すべてのメモリ:診断実施する()
実施する(診断)
すべてのメモリ:診断実施する()
実施する(診断)

イーサネットメモリへの診断依頼部分の記述は省略

すべてのメモリ :診断実施する()

実施する(診断)通知する(診断結果)

診断終了を待つ()通知する(診断結果)

診断終了を待つ()通知する(診断結果)
レポートする(診断結果)

図39

メイン基板での診断はハードウェアで行われ、診断依頼は即時復帰し、診断完了は割り込みで通知される非同期型を想定しました。ソフトウェアで行う場合でも、スレッド生成して非同期型にすることもできます。
サブ基板での診断はソフトウェアで行われ、診断実施は診断終了まで復帰しない同期型を想定しました。
診断装置もソフトウェア実装なので同期型にしました。
診断対象が診断結果を生成する記述は省略しました。診断結果をオブジェクト(クラス)にせずにエラーコ
ードを直接診断に通知するように仕様変更してもいいと思います。

メタファを使ったモデル

56

自己診断

診断対象クラスの状態遷移

stm 自己診断PIM設計:診断クラスのステートマシン図
停止中
開始

実施()

実施中

通知(診断結果)
中止()

中止中通知(診断結果)
図40

診断対象クラスの状態遷移

stm 自己診断PIM設計:診断対象ステートマシン図
停止中

実施(診断) /診断中診断 = 診断

診断中診断.通知(診断結果)/診断中診断 = なし

開始

中止(診断) [診断中診断==診断]
中止中
診断.通知(診断結果)/診断中診断 = なし
図4157

PIM 設計モデル

組込み分野のための UML モデル解説書「自己診断」
発行日 ２０１０年（平成２２年）１０月 1 日
第二版発行 ２０１２年（平成２４年）５月１7 日
発行者 UMTP, Japan
編 著 組込みモデリング部会
印刷
UMTP, Japan
東京都渋谷区代々木 1 丁目 22 番 1 号
http://www.umtp-japan.org/

Copyright(c)2010-2016 consortium for UML based Modeling Technologies Promotion All Rights Reserved