組込み分野のための
UML モデルカタログ

組込み分野でモデリングする全ての人に捧げるモデル集

本書は、組込み分野のさまざまなモデルを集めたカタログです。
UMTP
組込み分科会

モデリングの初心者には教科書や参考書として、モデリングのベテ
ランの方々にはモデルのヒントとして、ぜひともお手元に置いて活用してください。

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

組込み分野のための UML モデルカタログ

目次

UML モデルカタログの歩き方 ............................................................... 1
UML モデルカタログとは ................................................................. 3
カタログの構成 .............................................................................. 4
カタログの使い方 ........................................................................... 6
モデルカタログ .................................................................................. 9ラ゗ンナップ ............................................................................... 11
機能編 ........................................................................................ 11
製品編 ........................................................................................ 12
孔版印刷機................................................................................. 12要求仕様.................................................................................. 12
モデル一覧 ............................................................................... 24
エンテゖテゖに着目して分析したモデル .......................................... 25
機能編 ........................................................................................ 38
認証 ......................................................................................... 38要求仕様.................................................................................. 38
モデル一覧 ............................................................................... 44
機能に着目して分析したモデル ..................................................... 45
エンテゖテゖに着目して分析したモデル .......................................... 52
状態に着目して分析したモデル ..................................................... 63
自己診断 ................................................................................... 74
要求仕様.................................................................................. 74
モデル一覧 ............................................................................... 82
エンテゖテゖに着目した分析したモデル .......................................... 83
メタフゔを使って分析したモデル................................................. 115
おわりに ................................................................................... 129i

UML モデルカタログの歩き方

ここでは、みなさんがこのカタログを有効活用できるように、カタログの全体構成とお勧めの使い方を具体的にご紹介します。

組込み分野のための UML モデルカタログ

UML モデルカタログとは
昨今の組込み分野における開発規模の増大・複雑化・短納期化に対応する手法として、UML によるモデリングが成果を上げています。UML モデルを利用することで、大規模システ
ムであっても、全体をふかんし、ゕーキテクチャレベルでシステムを理解したうえで各種の問題に対する対策を打てるので、生産性・品質を向上させることができます。
しかし、実情は UML モデリングを開発に取り入れてみたものの、モデリングの有識者がいないがために、その効果を十分に得ることができず、従来の方法に戻してしまう現場が多々あります。
そのような状況を打開するために、初心者には UML モデリングに取り組む第一歩として、ベテランの方にはより良いモデリングのヒントとして、「カタログ」(本書)を提供することに
しました。

製品企画

製品審査
システム・エンジニゕリング・プロセス

システム要求定義

システムテストシステム・
ゕーキテクチャ設計

システム結合テスト

ソフトウェゕ・エンジニゕリング・プロセス

本書が開発の現場で UML モデリン
グを利用する際の参考になれば幸いです。

ソフトウェゕ
総合テスト

ソフトウェゕ
要求定義

ソフトウェゕ
結合テスト

ソフトウェゕ・
ゕーキテクチャ設計

本書の適用範囲は、主に、製品開発におけるソフトウェゕ設計工程です。
「組込みソフトウェゕ向け 開発プロ
セスガ゗ド1」（以下 ESPR）では、右図で示す範囲です。

ソフトウェゕ
詳細設計

単体テスト

実装
：適用範囲
図 1 組込みソフトウェゕ開発プロセスと本書の適用範囲

特に本書に関係の深い工程についての定義を以下に示します。

1

工程名

定義

ソフトウェゕ
要求定義

当該製品を実現するためにソフトウェゕとして実現が必要となる要求を明確にします。

ソフトウェゕ・
ゕーキテクチャ設計

開発する組込みソフトウェゕのゕーキテクチャ（＝動作[振る舞い]と構造）を決定します。
※後述する「PIM」設計モデルにあたります。

書名 ：組込みソフトウェゕ向け開発プロセスガ゗ド
編著者 ：独立行政法人 情報処理推進機構 ソフトウェゕ・エンジニゕリング・センター
出版社 ：株式会社翔泳社、発行年：2008 年
URL：http://sec.ipa.go.jp/publish/index.html

3

UML モデルカタログとは

組込み分野のための UML モデルカタログ

カタログの構成
カタログは、「製品編」と「機能編」に分かれています。
「製品編」は、印刷機など製品全体
をモデリングして掲載しています。
「機能編」は、多くの製品に共通して搭載されている機能からいくつかをピックゕップして掲載しています。
「機能編」に掲載している機能をいくつか組み合わせることで、「製品編」に掲載している製品ができあがる場合もあります。

機能編
○○機能

△△機能

□□機能

△△1 機能△△2 機能△△3 機能△△4 機能

××機能
製品編
製品 A
××機能
□□機能

製品 B
△△1 機
能
△△2 機
能

□□機能

○○機能

△△3 機能△△4 機能△△機能

本カタログに掲載しているモデルでは、まず、モデリングの対象となる製品や機能の要求仕様が定義されています。この要求仕様をもとにモデリングを行います。
本カタログでは、1 つの要求仕様に対して、複数のモデルを掲載しています。モデリングは大きく 2 つの考え方があり、1 つは要求仕様を何かに例えて本質を見極める
要求仕様「メタフゔ」を使った方法、もう 1 つはモデル一覧
要求仕様の整理整頓の仕方や重点を置く
ポ゗ントに「着眼点」を持ったモデリン
…
モデル 1
モデル 2
グ方法です。
要求仕様の後に、これら複数のモデ
ルの゗ンデックスとなるモデル一覧を用意しています。
各モデルでは、分析モデル、PIM 設計モデル、PSM 設計モデルといった具合に、段階的に詳細化を行っており、それぞれクラス図、オブジェクト図、コミュニケーション図、ステートマシン図な
どの UML モデルを掲載して、モデルの解説を行っています。

UML モデルカタログの歩き方

モデルの特徴分析モデル
・モデリングのコンセプト
・各種 UML モデル

PIM 設計モデル
・モデリングのコンセプト
・各種 UML モデル

PSM 設計モデル
・モデリングのコンセプト
・各種 UML モデル※PSM 設計モデルは、本版では対象外。将来の改版において含める予定。

4

組込み分野のための UML モデルカタログ

セクション

記載内容

ESPR におけるフェーズ

要求仕様

ユースケース図・ユースケース記述・シナリオなどを使用し、製品または機能の要求仕様を定義します。

ソフトウェゕ要求定義

分析モデル

モデリングのコンセプトをもとに作成したモデルです。

PIM 設計モデル

OS やミドルウェゕや言語などのプラットフォー
ムに依存しないモデルです(PlatformIndependent Model)。

PSM 設計モデル

プラットフォームに特化したモデル(PlatformSpecific Model)です。
ただし、今回はモデルカタログの対象外です。

5

ソフトウェゕ・
ゕーキテクチャ設計

カタログの構成

組込み分野のための UML モデルカタログ

カタログの使い方
本書では、次のような場面で利用されることを想定しています。

 新しい製品を開発することになり、製品全体のモデリングの参考として・・・
 既存製品に新しい機能を追加することになり、その機能のサンプルとして・・・
 既存製品の既存機能を改善するために、比較サンプルとして・・・
 組込みシステムにおけるモデリング教育の参考資料として・・・

利用例 1
新しい製品の開発や既存製品への機能追加のサンプルとして利用する場合、下記のような流れで利用します。
開発対象に近い製品または機能を選ぶ

選んだ製品または機能の要求仕様を読み、参考となる内容として妥当か判断する

モデル一覧から今回の要件に近いモデルを選ぶ

分析モデル、PIM 設計モデル、PSM 設計モデルを参考にする
例えば、「コピー機」を開発する場合、製品編から「コピー機」のモデルを探しますが、見当たりません。このような場合、製品概要やキーワードからコピー機と「似た」製品を探します。その結果、「孔版印刷機」を選ぶことにします。
「孔版印刷機」と「コピー機」には、「読み取り」、「書き込み」、「自己診断」等の共通した機能があり、これらがどのようにモデリングされるかを参考に開発ができます。
さらに、「自己診断」については、機能編にその詳細が記述されていますので、機能編の「自己診断」で掲載されているモデルも参考にするとよいでしょう。また、「コピー機」に必要な機能が、参考とする「孔版印刷機」にない場合、機能編を探してみると、その機能が掲載されているかもしれません。製品を構成する機能の多くは、同様の製品に搭載されていることが多く、本書においても機能編でより詳細なモデリングを行っている場合があります
ので、機能編も合わせて参考にしてください。
各モデルは、全てを取り入れる必要はありません。必要な部分を取り入れて、開発しようとする製品に合わせて、うまくカスタマ゗ズしてください。

UML モデルカタログの歩き方

6

組込み分野のための UML モデルカタログ

利用例 2
組込みシステムにおけるモデリング教育の参考資料としては、モデリング技法の解説や、演習問題の題材として、以下のような利用ができます。
モデリング解説用の製品または機能を選ぶ

選んだ製品または機能のモデリング方法解説用テキストを作成する

モデリング演習用の製品または機能を選ぶ

選んだ製品または機能のモデリング工程を模範解答とする（必要であれば、別途解説を作成する）

作成したテキストと演習を組み合わせ、
組込みシステムにおけるモデリング教育を実施する
例えば、組込みソフトウェゕのモデリング技法を演習付きで習得できる講座を作るとすると、以下のような流れになります。
まずモデリング解説のためのテキストを作成します。
その際に活用するモデルとして、「自己診断」のモデルのうち「メタフゔを使って分析したモデル」を選びます。ここでは、モデルの作成手順や考えが詳細に記述してあるものから選択すると良いでしょう。モデリングを解説するテキストでは「自己診断」の「メタフゔを
使って分析したモデル」に記述された本書のモデルが、どのような考えに基づいてされたのか、行間を埋めていく゗メージで作成します。例えば、本書のモデルでは、概念モデルとしてのクラス図に続いてシーケンス図が記述されています。テキストでは、概念モデルとしてのクラス図を作成した後には、クラス図には表現しきれない振る舞いを、シーケンス図で表現することや、クラス図のクラスとシーケンス図のクラスの対応から、具体的にどのようにクラス図からシーケンス図が作成されたのかを解説します。
次に、演習を作成します。演習の課題としては「認証」を選びます。ここでは、モデリン
グ例が多いものを選択すると良いでしょう。
必要であれば、モデリング解説用のテキスト作成時と同様に、「認証」に対するモデリン
グ例から模範解答を選び、解説を作成します。以上を準備として、講義を実施します。

7

カタログの使い方

モデルカタログ

ここからはモデルカタログになります。

組込み分野のための UML モデルカタログ

ラインナップ
製品編
製品名

製品概要

キーワード※

孔版印刷機

低コストに大量の印刷物を作成することを実現する
印刷機

孔版印刷
読み取り
書き込み
紙搬送
機器管理
ユーザ゗ンタフェース
自己診断
認証※下線は機能編に記載があります。

機能編
機能名

製品概要

キーワード

認証

ユーザを識別し、ユーザ毎に適切なサービスを提供したり、記録を取ったりする機能

ユーザ認証
サービス実行承認
サービス利用状況監視

自己診断

組込みシステムにおいては、システムを構成するデバ゗スのチェックを行い、結果をレポートする機能。チェックする項目、チェック項目の実行順序、
実行する手段(自動、手動)などをモデリングしてい
ます。

装置診断

11

ラ゗ンナップ組込み分野のための UML モデルカタログ

製品編
孔版印刷機
ご注意：
孔版印刷機の要求仕様は、理想科学様よりご提供いただきましたが、本カタログ内のモデ
ルは、理想科学様内で使われている製品版のモデルとは一切関係ございません。また、理想
科学様メンバは、本孔版印刷機のモデリング作業には、一切関わっておりません。

要求仕様
孔版印刷機とは、「孔版印刷」という技術を使った印刷機で、低コストに大量の印刷物を作成することを実現する機械です。

孔版印刷機での基本的な印刷方法
孔版印刷とは、『版』と言われるものに孔（あな）をあけ、孔があいた所に゗ンクを通過させて、画像を用紙に転写する方法です。一度『版』を作ってしまえば、『版』が巻き付いたドラムに用紙を押し当てて通過させることで転写が完了することから、レーザープリン
タ・゗ンクジェットプリンタ・PPC 方式の複写機などの比較にならないほどのスピードで印刷することができます。
サーマルヘッド゗ンクを通すところだけに熱をかけ、版マスターに孔をあける

ドラム

版マスター

゗ンクカートリッジが内蔵されている

ドラムに巻きつけて、版となる（カットされる）

版
用紙

孔版印刷機

プレス
ローラ

12

組込み分野のための UML モデルカタログ

利用者の要求と版のラ゗フサ゗クル
孔版印刷機では、利用者が要求する複写や印刷の単位と、その際に作成した版のラ゗フサ
゗クルは一致しません。例えば、一度複写するために版を作成すると、そのまま版を残しておき、別のタ゗ミングでその版を使って印刷を行うことができます。版を除去するタ゗ミン
グは、次に原稿から複製を作るとき、もしくは、利用者が版の除去を指定した時となります。
原稿 A の複製を要求

今ある版で印刷だけを要求

原稿 B の複製を要求

利用者の要求

読取った画像から版 A を作成
ドラム上の
物理的な版

版Aを
除去

読取った画像から版 B を作成

原稿 A から作られた版 A が付
着原稿 B から作られた版 B が付
着

さまざまな印刷設定
孔版印刷機の印刷機能としては、片面・両面・集約・分割・色分割（エリゕ指定・自動認識）などがあります。それらの機能は、ドラムが 1 つで実現できるものもあれば、ドラムを複数必要とする機能もあります。
本カタログモデルでは、ドラムが 1 つで実現できる機能にフォーカスしてモデルを作成することにします。
片面→片面

両面→片面

原稿 1

原稿 1
表

版1

用紙 1

用紙 1

用紙
N

原稿 1

原稿 1
裏

版1

用紙 N

集約

版1

版2

用紙
N+1

13

原稿 2

用紙
2N

用紙 1
用紙 N

要求仕様

組込み分野のための UML モデルカタログ

紙搬送
孔版印刷機における紙搬送は、通常のプリンタと殆ど同じです。
ここでは、印刷する用紙を給紙トレ゗から給紙し、排紙するまでについて説明します。用紙は、ある決められた印刷経路を通って行きます。印刷経路は、給紙する位置をスタート、排紙する位置をゴールとし、その間に印刷する位置を通過します。用紙が通る印刷経路は、
その機器のメカ的なレ゗ゕウトにより、給紙できる場所、排紙できる場所、どのような道筋を通るかは決まっています。一般的に、一つの機器で複数の経路の選択肢がありえます。しかし、利用者がスタートキーを押した時点で、どこのスタート位置から始まり、どのような道筋を通り、ゴール位置にたどり着くかは決まります。

本体排出口ありえる搬送経路

排紙トレ゗

紙

ドラム

手差しトレ゗

搬送中の紙

センサ
ローラ

給紙トレ゗

孔版印刷機

14

組込み分野のための UML モデルカタログ

ユースケース図本カタログモデルが実現する範囲のユースケースを示します。

孔版印刷機
UC01:電源ONする

UC02:原稿を複製する
一般利用者
UC03:版から印刷する

UC04:版を除去する

管理者

UC05:機器の状態を診断する

15

要求仕様

組込み分野のための UML モデルカタログ

ユースケース記述<UC01：電源 ON する>■概要
装置の電源を投入し、システムを起動させる■ゕクター
一般利用者、管理者■事前条件
・システムが電源 OFF である■事後条件
・メ゗ン画面が表示されている・もし、故障があったならば、故障の表示がされている■メ゗ンフロー
1. ゕクターは、システムの電源を投入する
2. システムは、ゕクターに対し、初期化処理中である旨を通知する
3. システムは、ゕクターに対し、メ゗ン画面を表示する
4. ゕクターは、メ゗ン画面を確認することで、システムが起動したことを認識する
5.UC を終了する■代替フロー
3a. システムが初期化中に、故障を発見した場合
3a1. システムは、ゕクターに対し、メ゗ン画面と故障通知を表示する
3a2. メ゗ンフローの 4 に戻る■課題やＴ.B.D 項目
なし

■備考
なし

孔版印刷機

16

組込み分野のための UML モデルカタログ<UC02：原稿を複製する>■概要
システムの読取装置に原稿を投入して、原稿を読み取って印刷物を出力する■ゕクター
一般利用者、管理者■事前条件
・メ゗ン画面が表示されている■事後条件・メ゗ン画面が表示されている・版が作成されている・印刷物が出力されている■メ゗ンフロー
1. ゕクターは、システムの読取装置に、原稿を投入する
2. ゕクターは、システムに対し、枚数を指定して、原稿の印刷を要求する
3. システムは、ゕクターに対し、原稿の原稿を読み取り中である旨を通知する
4. システムは、ゕクターに対し、版を作成中である旨を通知する
5. システムは、ゕクターに対し、印刷中である旨を通知する
6. システムは、印刷された用紙を出力する
7. システムは、ゕクターに対し、メ゗ン画面を表示する
8. ゕクターは、システムの読取装置から、原稿を取り除く
9. UC を終了する■課題やＴ.B.D 項目
なし

■備考
なし

17

要求仕様

組込み分野のための UML モデルカタログ＜UC03：版から印刷する＞■概要
すでに作成されている版から印刷する

■ゕクター
利用者

■事前条件
・メ゗ン画面が表示されている・版が作成済みである■事後条件
・印刷された用紙が出力されている・メ゗ン画面が表示されている■メ゗ンフロー
1. ゕクターは、システムに対し、枚数を指定して、版からの印刷を要求する
2. システムは、ゕクターに対し、印刷中である旨を通知する
3. システムは、印刷された用紙を出力する
4. システムは、ゕクターに対し、メ゗ン画面を表示する
5. UC を終了する■課題やＴ.B.D 項目
なし

■備考
なし

孔版印刷機

18

組込み分野のための UML モデルカタログ＜UC04：版を除去する＞■概要
既に作成されている版をドラムから取り除き、排出ボックスに排出する

■ゕクター
利用者

■事前条件
・版が作られている・メ゗ン画面が表示されている■事後条件
・版が排出ボックスに排出されており、ドラムには版がない・メ゗ン画面が表示されている■メ゗ンフロー
1. ゕクターは、システムに対し、版の除去を要求する
2. システムは、排出ボックスが、閉じられている事を確認する
3. システムは、ゕクターに対し、版を除去中である旨を通知する
4. システムは、ゕクターに対し、メ゗ン画面を表示する
5. UC を終了する■課題やＴ.B.D 項目
なし

■備考
なし

19

要求仕様

組込み分野のための UML モデルカタログ＜UC05：機器の状態を診断する＞■概要
孔版印刷機の自己診断機能で、故障がないかを確認する

■ゕクター
管理者

■事前条件
メ゗ン画面が表示されている■事後条件
メ゗ン画面が表示されている■メ゗ンフロー
1. ゕクターは、システムに対し、管理画面への移行を要求する
2. ゕクターは、システムに対し、故障診断を要求する
3. システムは、各ユニットの故障診断を行い、ゕクターに対して、診断結果を通知する
4. ゕクターは、システムに対し、診断結果表示のクリゕを要求する
5. システムは、ゕクターに対し、管理画面を表示する
6. ゕクターは、システムに対し、メ゗ン画面への移行を表示する
6. UC を終了する■課題やＴ.B.D 項目なし■備考
どのユニットの故障診断を行うのか？

孔版印刷機

20

組込み分野のための UML モデルカタログ

ドメインチャート
孔版印刷機のシステム全体を、次のようにドメ゗ン分割しました。以降に記載しているモ
デルは、このドメ゗ン分割を前提としています。
孔版印刷

機器制御ドメイン群

製版
読み取り

書き込み

紙搬送

機器管理

自己診断

ユーザインタフェース

 孔版印刷：「原稿の複製・印刷物」を作成するという孔版印刷機の目的を実現する

 機器制御ドメ゗ン群：機器制御をおこなうドメ゗ンのグループ
 読み取り：原稿の読み取りを、装置についているメカ機構を利用して実現する

 製版：マスターから、サーマルヘッドを使って孔をあけ、版を作成してドラムに巻きつける 書き込み：製版と用紙への転写を、装置についているメカ機構を利用して実現する

 紙搬送：原稿および印刷対象の用紙の搬送を、装置についているメカ機構を利用して実現する 機器管理：機器全体の稼働状況を把握する

 ユーザ゗ンタフェース：利用者とのコミュニケーションを実現する
 自己診断：機器の機能・装置・部品などの状態を診断して、診断結果を報告する
21

要求仕様

組込み分野のための UML モデルカタログ

ドメイン間シーケンス図
電源 ON のシーケンス
sd UC01：電源ONする
孔版印刷ド
メイン::孔版
印刷

一般利用者
電源
ON()

孔版印刷ド
メイン::ユー
ザインタフ...

孔版印刷ド
メイン::紙搬送

孔版印刷ド
メイン::書き込み

孔版印刷ド
メイン::読み取り

孔版印刷ド
メイン::自己診断

メッセージ表示("起動中")
自己診断
登録()

登録(紙
搬送)

自己診断
登録()

登録(書
き込み)

自己診断
登録()

登録(読
み込み)

全診断実行() :診断結果診断する() :診断結果診断する() :診断結果診断する() :診断結果

alt 診断結果[OK]
メッセージ表示(
診断結果)
[NG]
メッセージ
消去()

(from ユースケース)

原稿から複製するシーケンス
sd UC02：原稿から複製する

一般利用者

孔版印刷ド
メイン::ユー
ザインタフ...

孔版印刷ド
メイン::孔版印刷

孔版印刷ド
メイン::読み取り

孔版印刷ド
メイン::製版

孔版印刷ド
メイン::書き込み

孔版印刷ド
メイン::紙搬
送

原稿をセットする()
原稿から複製する(枚数)
複製(枚数)
原稿読み取り()原稿有無確認() :bool
メッセージ表示("読取中")読み取り要求() :版データ
メッセージ消去()
版作成()
メッセージ表示("版作成中")
版作成(イメージデータ)
着版要求()
メッセージ消去()
印刷(枚数)
メッセージ表示("印刷中")
loop

転写要求()
給紙要求()
転写完了通知()メッセージ消去()(from ユースケース)

孔版印刷機

22

組込み分野のための UML モデルカタログ

版から印刷するシーケンス
sd UC03：版から印刷する

一般利用者

孔版印刷ド
メイン::ユー
ザインタフ...

孔版印刷ド
メイン::孔版印刷

孔版印刷ド
メイン::読み取り

孔版印刷ド
メイン::書き込み

孔版印刷ド
メイン::紙搬
送版から印刷する()印刷(枚数)
メッセージ表示("印刷中")
loop 印刷枚数
転写要求()
給紙要求()
転写完了通知()メッセージ消去()(from ユースケース)版を除去するシーケンス

機器の状態を診断するシーケンス

23

要求仕様

組込み分野のための UML モデルカタログ

モデル一覧
モデル名

概要

ポ゗ント

エンテゖテゖに
着目して分析したモデル

孔版印刷機の特徴は、原稿から用紙に複写されるまでの特徴として、「版」が存在することです。
それらの対応関係の構造を中心に、エンテゖテゖ
に着目して分析したモデルです。

いろいろな印刷設定が増えた場合に対応しやすいモデルです。

孔版印刷機

24

組込み分野のための UML モデルカタログ

エンティティに着目して分析したモデル要求仕様で整理された原稿、版、用紙の静的な構造に着目し、これらを孔版印刷機の中心と位置づけます。その構造を中心として孔版印刷機をモデル化した全体概念モデルと、それをドメ゗ンに分類したクラス図を次に示します。孔版印刷ドメ゗ンは、主にシステム全体の状態や、利用者からの要求を取り扱うことが使命です。それ以外のドメ゗ンは、各種デバ゗
スを制御し、孔版印刷を実現するための手段を提供する、という役割分担となっています。

概念モデル
cla s s 全体概念 モ デ ル

孔版印刷

ユーザーインターフェース
1

1

孔版印刷シ ステ ム

管理者モ ー ドキ ー
1

1
0..1

1
スタ ー トキ ー

ユ ー ザー リクエ スト

0..1

1
1
*

1

0..1

1

読み取りア クシ ョン

設定

印刷ア クシ ョン

0..1

1

1

1

1

自己診断
0..1

0..*
原稿

版元デ ー タ1

このドメインの詳細は機能編の自己診断を使用しま
す。

0..*

1

1

0..1

1

1

読み取り
読み取り対象

0..1

0..1

製版

サー マルヘッド

印刷物

版
0..1

1
0..1

1

1

1

0..1
1

書き込み
*

書き込み元

版マスタ ー

書き込み対象0..1
コ ン タ クトガラス

1

0..1
1

0..1

0..*

1
1

場所

0..1

イン クボ トルドラム
1

シ ー トスルー 位置
1
1

1
1

1

1
1

1

プ レ スロ ー ラー

カッタ ーキ ャリッジ

ラン プ
1

紙搬送

1

搬送対象紙
1

1
*

経路
1

0..1

*
区間
1
2

ローラ

位置

セン サー

25

エンテゖテゖに着目して分析したモデル

組込み分野のための UML モデルカタログ

分析モデル
孔版印刷ドメイン
モデリングのコンセプト
孔版印刷ドメ゗ンは、システム全体の最上位のドメ゗ンであり、利用者からの要求を実現することが使命です。
利用者からの要求の特徴は、要求仕様でまとめたように、原稿から複製を作成する場合と、すでにある版を使って印刷する場合の 2 種類があります。原稿から複製を作成する場合には、原稿を読み取って画像化し、その画像を使って版を作成し、版から印刷物を作成する、といった流れになります。すでにある版を使って印刷する場合には、版から印刷物を作成するだ
けとなります。
また、このドメ゗ンでは、パフォーマンスを出すために、一枚ずつ印刷結果を確認しません。印刷自体のながれは、書き込みドメ゗ンに指定した枚数分の印刷の管理をゆだねます。

クラス図
c la s s 孔版印刷分析モ デ ル

孔版印刷シ ステ ム
動作モード
印刷(枚数)
印刷終了()
自己診断実行()
自己診断終了()電源ON()
動作モード変更(モード)版除去開始()
版除去終了()
複製(枚数)
通知先

1

指示先

0..1

ユ ー ザリクエ スト
印刷ア クシ ョン

設定

印刷カウンタ

読み取りア クシ ョン
生成(設定)
読み取り実行()
版元データ取得()

1

1

1

生成元

1

生成(ID)
実行()
読み取り終了()印刷終了()
着版終了()

0..1

1

*
*

生成元
生成先

データ取得()

孔版印刷機

元
0..1

作成物
0..*

元

版元デ ー タ
生成(データ)
版生成()
版取得()

1

1

生成先

0..1

原稿
サイズ
面

一部印刷終了()印刷する(枚数)
印刷終了()
生成(設定)
設定(出力先)着版()
着版終了()
版登録(版)
版取得()

*

作成物
1

版
管理番号
使用回数

26

印刷物
元
1

着版()
脱版()
印刷物生成(サイズ, 枚数)
印刷物削除()
着版終了()

1

作成物
0..1

サイズ
枚数
生成(サイズ, 枚数)
印刷(枚数)
一部印刷完了()印刷終了()

組込み分野のための UML モデルカタログ

オブジェクト図
原稿から複製を作成する際のオブジェクト構成
object 読み取りと印刷のインスタンス:孔版印刷システ版を作成して印刷 :片面読み取り :読ム

ユーザリクエスト

み取りアクション

表面 :原稿:版元データ10部連続印刷 :印:版

刷アクション
片面の原稿を読み込み、版を作成して１０部印刷する
１０部 :印刷物

時の゗ンスタンス構成

版から印刷する際のオブジェクト構成
object 印刷のみインスタンス:孔版印刷システ版を作成して印刷 :片面読み取り :読ム

ユーザリクエスト

み取りアクション

表面 :原稿:版元データ10部連続印刷 :印:版

刷アクション

すでに版が着版している状態
での100部連続印刷時の゗ンス
タンス構成

１００部連続印刷 :印刷アクション

27

１００部 :印刷物

エンテゖテゖに着目して分析したモデル

組込み分野のための UML モデルカタログ

コミュニケーション図
印刷開始指示により、原稿読み取り、製版、印刷を行うコミュニケーション図
sd 孔版印刷分析コミュニケーション図
ユーザインタフェース:ユーザインタフェース
1.25: 印刷(枚数)1: 複製()
1.13: 生成(設定)1.26: 印刷(枚数)1.27: 一部印刷完了()
1.28: 印刷終了()

1.24: 生成(サイズ, 枚数):孔版印刷システ 1.15: 版登録(データ)1.16: 着版()
ム

1.31: 印刷終了():印刷物

1.29: 印刷終了()

書き込みドメイン

1.22: 印刷する(枚数)1.20: 着版終了():印刷アクション:版
1.1: 生成(ID)
1.21: 着版終了()
1.17: 着版()
1.2: 実行()1.30: 印刷終了()
1.23: 印刷物生成(サイズ, 枚数)

1.18: 着版()
1.19: 着版終了()

製版ドメイント

読み取りドメイン:版元データ

1.4: 生成(設定)1.5: 読み取り実行()

1.8: 版生成()

1.14: 版元データ取得()
1.7: 生成(データ):読み取りドメイン:読み取りアクシ
1.12: 読み取り終了()ョン
1.11: 削除()
1.6: データ取得()

孔版印刷機

ン

1.9: 生成():ユーザリクエス

1.3: 設定取得():書き込みドメイ

28:原稿

1.10: 製版する():製版ドメイン組込み分野のための UML モデルカタログ

ステートマシン図「孔版印刷システム」クラスのステートマシン図
孔版印刷システムクラスは、機器全体の動作モードレベルの振舞いを責任範囲とします。
初期化中に起こったエラーは、自己診断で発見したエラーであり、サービスマン等を呼ばないと解決しないような問題となります（ジャムなどの問題ではない）。
stm 動作モード状態遷移
開始
初期化中
+

do / 自己診断実行+

do / 自己診断登録

エラー発生

エラー

自己診断終了印刷モード

管理者モード
アイドル

動作

自己診断実

終了

行

動作モード変更

アイドル

動作モード変更

動作
終了

印刷

複製

版除去
開始

動作中

動作中

管理者モードでは印刷でき

印刷モードでは自己診断はで

ない

きない

29

エンテゖテゖに着目して分析したモデル

組込み分野のための UML モデルカタログ

紙搬送ドメイン紙搬送ドメ゗ンは、印刷用の紙搬送だけでなく、原稿やサーマルペーパーの紙搬送も役割として担っています。

モデリングのコンセプト
原稿・サーマルペーパー・印刷用紙の全ての紙搬送において、対象の紙が搬送を開始する場所から、搬送を終了する場所まで、ある経路を通って搬送されていきます。また、それらが動的に変化しない、という点で共通の特性を持っています。
どの搬送においても、搬送経路を意味のある単位に区切り、それらをつなげることで経路を構成することができます。区間には、必ず開始位置と終了位置があり、その位置はローラや位置決めセンサがレ゗ゕウトされています。
次の図は、印刷用紙搬送を例に説明したものです。
本モデルでは、紙を搬送するための仕組みを、紙は決められた経路を搬送されるもの、経路は複数の区間で構成されるもの、区間には開始位置と終了位置があるものとしてモデリン
グします。

B-C 区間A-B 区間手差しトレ゗B

A

C-D 区間CD

F-B 区間
区間 E-FE

本体排出口

C-H 区間F

H
G-F 区間

給紙トレ゗

G

排紙トレ゗

孔版印刷機

30

組込み分野のための UML モデルカタログ

クラス図
cla s s 紙 搬 送 分 析 モ デ ル

搬送対象紙生成(種別)
搬送開始()
所定位置到着()
終了()
通知先

1

ADF ファ クトリ

用 紙 ファ クトリ

サ ー マル ファ クトリ

経路生成()

経路生成()

経路生成()

*
*

1

経路管理

管理対象

経路
搬送元
搬送先

*

1

経 路 ファ クトリ
紙搬送自己診断登録

経路取得(種別)

1*

経路生成()
自己診断登録()給紙開始()
生成(区間, 搬送先, 搬送元)
感知(管理番号)*

対象

制御アドレス
管理番号

区間

後
0..1

管理番号
生成(開始位置, 終了位置)
次の区間取得()開始(経路)

開始

チェック項 目 ロ ー ラ駆 動

ローラ

前

1

1

1

1 終了

1

1

回転開始()
回転停止()
開始()

チェック項目クラスは自己診断ドメインで定義される診断する()
回転確認()
回転速度確認()停止確認()

自 己 診 断 ::チェック項 目位置
開始(経路)

位 置 決 め セン サ
チェック項 目 セン サ 感 知

対象

管理番号
種別

1

感知()
開始()

31

1

診断する()
感知確認()

エンテゖテゖに着目して分析したモデル

組込み分野のための UML モデルカタログ

オブジェクト図
印刷を行っていない時のオブジェクト構成
ob ject 印刷し ていない時の書き込みに関す る イン スタ ン ス:経路管理

用紙 :経路ロ ー ラー １ :ロ ー ラ

排紙 :区間書き込み :区間

給紙 :区間ロ ー ラー 2 :ロ ー ラ

書き込み位置 :位置決め セン サロ ー ラ3 :ロ ー ラ

ロ ー ラ4 :ロ ー ラ

ロ ー ラ5 :ロ ー ラ

印刷を行っている最中のオブジェクト構成
ob ject 書き込み時のイン スタ ン ス

搬送対象紙が生成され経路を使用する

書き込み :搬送対象紙:経路管理

用紙 :経路ロ ー ラー １ :ロ ー ラ

孔版印刷機

排紙 :区間書き込み :区間

給紙 :区間ロ ー ラー 2 :ロ ー ラ

書き込み位置 :位置決め セン サ32

ロ ー ラ3 :ロ ー ラ

ロ ー ラ4 :ロ ー ラ

ロ ー ラ5 :ロ ー ラ組込み分野のための UML モデルカタログ

コミュニケーション図
通常の搬送のコラボレーションs d 書き込みに関す る コ ミ ュニケー シ ョン

書き込み :搬送対象紙

1.1: 給紙開始()

1: 経路取得(種別) :経路:経路管理

1.13: 所定位置到着()

用紙 :経路1.7: 開始(経路)1.5: 次の区間取得() :区間

1.6: 開始(経路)1.2: 開始(経路)1.3: 開始()
ロ ー ラー １ :ロ ー ラ

排紙 :区間書き込み :区間

給紙 :区間

1.4: 開始()
ロ ー ラー 2 :ロ ー ラ

1.9: 開始()

1.8: 開始()
書き込み位置 :位置決め セン サロ ー ラ3 :ロ ー ラ

1.10: 開始()
ロ ー ラ4 :ロ ー ラ

1.11: 開始()
ロ ー ラ5 :ロ ー ラ

1.12: 感知(管理番号)33

エンテゖテゖに着目して分析したモデル

組込み分野のための UML モデルカタログ

シーケンス図自己診断を登録し実行するシーケンス
s d 紙搬送の自己診断シ ー ケン ス
自己診断ドメインのクラス:紙搬送自己診断登録:チェック項目センサ感知:チェック項目ローラ駆動:自己診断ドメイン

孔版印刷システム

自己診断登録()センサ :診断対象
生成する()
センサ :単一の対象に対する診断生成する(文字列, 診断対象)

チャック項目を加える(チェック項目, 診断対象)
ローラ :診断対象
生成する()
登録する(診断)ローラ :単一の対象に対する診断生成する(文字列, 診断対象)
チャック項目を加える(チェック項目, 診断対象)
登録する(診断)
全診断を行う()診断する()
診断する():診断結果
感知確認()
診断する()
診断する() :診断結果

回転確認()
停止確認()

孔版印刷機

34

組込み分野のための UML モデルカタログ

PIM 設計モデル
孔版印刷ドメイン
モデリングのコンセプト
ゕクテゖブオブジェクトは、並列での動作が必要となる「孔版印刷システム」と「ユーザーリクエスト」とします。また、循環参照を避けるために、メッセージ通信には「リスナ」
を導入します。

クラス図
c la s s 孔 版 印 刷 PIMモ デ ル
孔版印刷システム-

動作モード: int

+
+
+
+
+
+
+
+
+

印刷(枚数 :int) : void
複製(枚数 :int) : void
印刷終了() : void
自己診断実行() : void
自己診断終了() : void
電源ON() : void
動作モード変更(モード :int)...
版除去開始() : void版除去終了() : void

通知する

生成、指示する
印 刷 ア クシ ョン

ユ ー ザ リクエ ス ト
読 み 取 りア クシ ョン
+
+
+
+

1

生成(設定 :int) : void1
読み取り実行() : void
版元データ取得() : 版元データ取得終了(データ :版元データ) : void 1

1-

設定: int+++++

印刷終了() : void
実行() : void
生成(ID :int) : void
生成(ID :int, 印刷アクション :印刷アクション) : void
読み取り終了() : void

1

1

1

-

印刷カウンタ: int

+
+
+
+
+
+
+
+
+

一部印刷終了() : void
印刷する(枚数 :int) : vo...
印刷終了() : void
生成(設定 :int) : void
設定(出力先 :int) : void
着版() : void
着版終了() : void版登録(版 :版) : void版取得() : 版
1

原 稿 リス ナ

印 刷 物 リス ナ

版 リス ナ+

取得終了(データ :版元データ) : void+

+生成元

サイズ: int
面: int+

データ取得(原稿リスナ :原稿リスナ) : void

+元
0..1

+作成物
0..*

+
+
+

生成(データ :byte) : 版元データ 元
版生成() : 版*
版取得() : 版++

一部印刷終了() : void
印刷終了() : void0..1

通知する +生成先通知する
版

版元デ ー タ

原稿
-

+生成元

0..1 +生成先

通知する

0..1

着版終了() : void

-作成
物
1
+
+
+
+
+

35

1

印刷物

管理番号: int
使用回数: int+
元
印刷物削除() : void
印刷物生成(サイズ :int, 枚数 :int) : void 1
脱版(版リスナ :版リスナ) : void
着版(版リスナ :版リスナ) : void
着版終了() : void

+作成物
0..1

-

サイズ: int
枚数: int++++

生成(サイズ :int, 枚数 :int) : void
印刷(印刷物リスナ :印刷物リスナ, 枚数 :int) : void
一部印刷完了() : void
印刷終了() : void

エンテゖテゖに着目して分析したモデル

組込み分野のための UML モデルカタログ

シーケンス図読み取りのシーケンス図s d 読み取りシ ー ケン ス
:ユーザインタフェー
ス:孔版印刷システム:ユーザリクエスト:読み取りアクション:原稿:読み取りドメイン:製版ドメイン複製(枚数 :int)

生成(ID :int)

設定読み出し():設定

生成(設定 :int)

読み取り実行()

生成() :原稿データ取得(原稿リスナ :原稿リスナ)

原稿有無確認()op t

読み取り()[原稿有]

読み取りドメインに委譲
読み取り終了()生成(データ :byte) :版元データ:版元データ

版生成() :版製版する(版データ)版
生成()
取得終了(データ :版元データ)

読み取り終了()ref
印刷シ ー ケン ス

孔版印刷機

36

組込み分野のための UML モデルカタログ

着版と印刷時のシーケンス図s d 印 刷 シ ー ケン ス
:ユーザリクエスト:読み取りアクション:版:書き込みドメイン

読み取り終了()

版元データ取得() :版元データ

版元データ():印刷アクション

生成(設定 :int)

版登録(版 :版)

着版()

着版(版リスナ :版リスナ)

着版()

着版終了()

着版終了()

印刷物生成(サイズ :int, 枚数 :int):印刷物
生成(サイズ :int, 枚数 :int)

印刷(印刷物リスナ :印刷物リスナ, 枚数 :int)
印刷(枚数)
loop

一部印刷完了()[印刷する枚数回]
一部印刷終了()印刷終了()

印刷終了()

印刷物削除()
削除()

印刷終了()

37

エンテゖテゖに着目して分析したモデル

組込み分野のための UML モデルカタログ

機能編
認証
要求仕様
認証例
ユーザ A とユーザ B がいます。二人はそれぞれ固有の ID カードを持っています。この２人が２台の PC からそれぞれの電子データを１台のプリンタに印刷指示を出します。ユーザ A
がプリンタに ID カードをかざすと、ユーザ A が印刷指示した電子データが呼び出され、プリントが始まります。ユーザ A の電子データの印刷処理終了後、ユーザ B が同様に ID カード
をプリンタにかざすと、ユーザ B の電子データが呼び出されプリントが始まります。ユーザ
A,B の使用日時や電子データのタ゗トル、プリント枚数など使用記録がプリンタ保存されます。

このようなユーザごとに適切なサービスを提供できる仕組みを【認証】と呼称します。
この【認証】では、ユーザを識別し、ユーザごとに適切なサービスを提供し、機器の使用記録を取ります。この一連の機能の設計モデルを提供します。

認証38

組込み分野のための UML モデルカタログ

ユースケース図39

要求仕様

組込み分野のための UML モデルカタログ

ユースケース記述＜UC01 名：ユーザを認証する＞■概要
ユーザが正当なユーザであるかどうかを判断する

■ゕクター
ユーザ

■事前条件
なし

■事後条件
ユーザに認証結果が渡されていること■メ゗ンフロー
1 .ゕクターは、システムに対し、ゕクセス許可を要求する
2. システムは、ゕクターが正当なユーザかどうか判断する
3. システムは、ゕクターに対し、認証結果を渡す
4. UC を終了する■課題や T．B．D 項目
なし

■備考
なし

認証

40

組込み分野のための UML モデルカタログ＜UC02 名：サービスを利用する＞■概要
ユーザが組み込み装置で提供されているサービスを利用する

■ゕクター
ユーザ

■事前条件
ユーザが認証済みである■事後条件
ユーザに認証結果が渡されている■メ゗ンフロー
1 .ゕクターは、システムに対し、サービスの利用を要求する
2. システムは、認証機能に対し、「サービスの実行を承認する」ユースケースを実行する
3. システムは、認証機能から承認結果(OK)を受け取る
4. システムは、サービスを実行する
5. システムは、認証機能に対し、「サービス利用状況を監視する」ユースケースを実行する
6. システムは、ゕクターに対し、サービスの利用を開始した旨を返す
7. UC を終了する■例外フロー
1 .ゕクターは、システムに対し、サービスの利用を要求する
2. システムは、認証機能に対し、「サービスの実行を承認する」ユースケースを実行する
3. システムは、認証機能から承認結果(NG)を受け取る
4. システムは、ゕクターに対し、承認に失敗した旨を返す
5. UC を終了する■課題や T．B．D 項目
なし

■備考
なし
41

要求仕様

組込み分野のための UML モデルカタログ＜UC03 名：サービスの実行を承認する＞■概要
ユーザが指定のサービスを実行できる権限があるか確認する

■ゕクター
なし

■事前条件
ユーザが認証済みである■事後条件
システムにサービス利用可否が渡されている■メ゗ンフロー
1. システムは、認証機能に対し、指定ユーザが指定サービスを利用できるか確認する
2. 認証機能は、指定ユーザにサービス実行の権限があるかどうかを判断する
3. 認証機能は、システムに対し、サービス利用可否を渡す
4. UC を終了する■課題や T．B．D 項目
なし

■備考
なし

認証

42

組込み分野のための UML モデルカタログ＜UC04 名：サービス利用状況を監視する＞■概要
ユーザがサービスを利用している状況を監視し、記録する

■ゕクター
なし

■事前条件
ユーザのサービス利用が承認されている■事後条件
サービス利用状況の記録(課計)が存在している■メ゗ンフロー
1.システムは、 認証機能に対し、サービス利用状況を通知する
2. 認証機能は、サービス利用状況を記録する
3. UC を終了する■課題や T．B．D 項目
なし

■備考
なし

43

要求仕様

組込み分野のための UML モデルカタログ

モデル一覧
モデル名

概要

ポ゗ント

機能に着目して分析したモデル

認証機能の設計として、広く知られている AAA
モデルの 3 機能に着目したモデルです。

AAA モデルの３要素を基本クラスとしたモデルです。なんらかの指針を使った設計例として利用
してください。

エンテゖテゖに
着目して分析したモデル

認証がユーザのサービス使用に対して制限を掛けるという観点から、制限を掛けるエンテゖテゖに
着目したモデルです。

エンテゖテゖを中心に理解しやすいシンプルな作りにしたので、モデリン
グ初心者の方にお勧めです。

状態に着目して分析したモデル

ユーザが認証された・認証されていない、といった状態に着目したモデルです。

状態毎の振舞いの違いを、ステートパターンで実現します。

AAA モデルとは
本章には、AAA モデルの用語が３つの設計モデルで共通概念として使用されています。
ここで、AAA モデルの概要を説明します。
AAA モデルとは、認証機能を実現する上で、主だった機能をつぎの３要素に分割したモデルを指します。
ユーザを認証する、適切なサービスの提供する、サービス使用の記録を作成する、これらを認証（Authentication）、承認（Authorization）、ゕカウンテゖング（Accounting）と分類し、３つの頭文字 A をつなげて AAA モデルと呼ばれます。
また AAA モデルは、AAA プロトコルとも言われ、認証、承認、ゕカウンテゖングの３要
素自体と、またその要素間の通信とにおいて秘匿性が設計上考慮されていることを指します。
本章に於いて、AAA のゕカウンテゖングの呼称を、監視と改名しています。これはゕカウ
ンテゖングがユーザ情報（ゕカウント）と誤解しやすいためです。

認証44

組込み分野のための UML モデルカタログ

機能に着目して分析したモデル
分析モデル
モデリングのコンセプト
本モデルは、広くしられている AAA モデルの構造を模す事を出発点としました。AAA に登場する認証、承認、ゕカウンテゖングの３要素が取り扱う情報の責務に着目することを本モデルのコンセプトとして設計を行いました。
３要素のほかに要求仕様から読み取れる、ユーザの ID カード、ユーザに提供するサービス、ユーザの使用履歴といった情報を抽出し、それを元に分析作業を行いました。

クラス図
分析図その１
cla s s 分析１

AAAモデルの３つを最上位層のクラスとしておきました。
認証の配下に要求仕様から読み取れる情報を認証、承認、監視の役割を考慮して配置しました。

誰が許可で誰が不許可か

承認

認証
+

+

ユーザを認証する()+

監視処理を実行する()

1
登録サービス*1

アカウン トサー ビ ス

名前カギ

監視サービスを提供する()

1

1
登録アカウント-『承認』１サービスの単価

認証をパスしたら何ができるか*

サービスを承
認している

1 -

内容

アカウントに対してサービスが承認されている
１つのサービスに対して複数アカウントの実行を承認される。
サービスはアカウントごとに異ならず、すべてのアカウントで同一サービスと考え
る。

登録課計
1
サー ビ ス利用量ルー ル

1

*

+
+

ルールを確認する() : void
ルールを実行する() : void

サービスの実行前後にそのサービスがどのような監視をされているか確認が行われる。

サービスの実行前にはそのサービスが承認されているか確認が行われる。

最上段には AAA の３要素、認証、承認、監視を配置しました。

45

機能に着目して分析したモデル

組込み分野のための UML モデルカタログ

認証が扱う情報は、ユーザを識別するための情報です。認証が扱うユーザを識別する情報をゕカウントとし、その下に配置しました。
承認が扱う情報は、サービスです。承認が扱うサービスを、その下に配置しました。
監視が扱う情報は、サービス利用（サービス利用後情報）です。
ひとまず分析作業はここまでとして、この後シーケンス検討、PIM モデル作成を通して必
要なクラスを抽出します。

オブジェクト図
分析図その１におけるオブジェクト構成
cla s s 要 求 仕 様 オブ ジ ェクト図認証システム

端末

Aさ ん
認証シ ステ ム
Aさ ん IDカー ド

印刷を指示するパソコンとIDカードをかざす端末装
置を
ここではひとまとめに端末と称しました。
認証

承認

とりあえず、AAA３つに端末が関連すると絵がみづらいので、便宜的に集約したクラスを配置しています。

監視

端末

Bさ ん

印刷サー ビ ス

Bさ ん IDカー ド

使用履歴を と る

Aさ ん ユ ー ザ情報

Bさ ん ユ ー ザ情報要求仕様の状況をひとまずオブジェクト図にしてみました。クラス図その１の登場人物でひとまず足りている模様です。

認証

46

組込み分野のための UML モデルカタログ

クラス図
分析図その 2
分析図その１をもとに、さらにクラスを抽出
cla s s 分 析 ２

認証
+

承認

ユーザを認証（認識）する() : void

1+

サービスの承認設定を確認する+

監視処理を実行する() : void1

登録サービス

登録課計

0..*

0..*
ア カウン トサー ビ ス* サービスの承認を確認
する

名前
カギ

1

監視を実行する1

登録アカウント

監視

1

サービスを提供する() : void

1-

『承認』１サービスの単価

認証をパスしたら何ができるか何を許可して何を不許可にするか

1

-

0..1
0..*

サー ビ ス利用量ルー ル

サービス

-

ルール内容

+
+

ルールを確認する() : void
ルールを実行する() : void* ルールを確認する 1
1

1

1
承認状況を変更する

ログオンしている
0..1
認証証明書
-

認証日時

0..*

0..*
承認証明書
0..*

ログインユーザ、サービス
実行ユーザを判別するための材料として設けまし
た。

-

0..*

サー ビ ス利用量

承認有効状況

監視機能動作時に、承認無効（一時的にサービス利用不可）になる場合がある

シーケンスの検討や PIM モデルの検討を通してクラス図は上記のように変化しました。以下の追加された最下段のクラスの責務と説明となります。
認証証明書：ログ゗ンゕカウントと非ログ゗ンゕカウントを区別するためにログ゗ン時に生成されます。
承認証明書：サービス実行前にサービスの実行権が監視からも認められているか確認する
クラスです。例えば監視条件を満たさない場合（課金不足など）、サービスの実行権を失う状況を実現します。
サービス利用：監視の使用記録などの実データとなります。
つぎにユースケースに対応したシーケンス図を示します。゗ンタフェースは先の PIM モデルのものを利用しています。
47

機能に着目して分析したモデル

組込み分野のための UML モデルカタログ

シーケンス図ユーザを認証する際のシーケンス
s d ユ ー ザを 認証す る

初期条件
・ユーザA、ユーザ登録済み
・ユーザ登録サービス登録済み
・監視内容は無し。
シナリオ
・ユーザAを認証する。

Facade認証:認証証明書

ユーザA

ユーザ認証要求()
ログオン(ユーザ名, パスワード) :認証証明書照合する(ユーザ名, , パスワード)

生成()

証明書発行()
認証完了通知()認証

48

組込み分野のための UML モデルカタログ

サービスの実行を承認する際のシーケンス
s d サ ー ビ スの 実 行 を 承 認 す る

初期条件
・ユーザA登録済み・ユーザAはユーザ承認済み
・監視内容は無し。
シナリオ
・ユーザAがサービスを実行し、承認部がサービス承認を行う。
Facade承認:認証証明書:アカウント

:サービス

ユーザA

サービス実行(サービス種別, 認証証明書) :サー
ビス利用量
承認サービス問い合わせ(サービス種別) :boolean関連サービスの承認確認(サービス種別) :bool

関連サービスの承認確認(サービス種別) :bool
承認済み()

サービスの実行()サービスの実処理()

49

機能に着目して分析したモデル

組込み分野のための UML モデルカタログ

サービスの利用状況を監視するシーケンス
s d サー ビ ス の 利 用 状 況 を 監 視 す る

初期条件
・管理者ユーザ登録済み・ユーザAはユーザ承認済み
シナリオ
・管理者が印刷サービスを実行し、使用記録の残す。
Facade承認:認証証明書:アカウント:サービス

監視:承認証明書サービス利用量ルール:サービス利用量

ユーザA

サービス実行(サービス種別, 認証証明書) :サー
ビス利用量
承認サービス問い合わせ(サービス種別) :boolean関連サービスの承認確認(サービス種別) :bool
関連サービスの承認確認(サービス種別) :bool
承認済み()

サービスの実行()関連サービスの承認確認(サービス種別)
サービス実行権確認()

実行権有り()

印刷サービスの実処理()

監視の実行()
課計ルール
の実行()

記録処理()
記録処理()

認証50

組込み分野のための UML モデルカタログ

PIM 設計モデル
クラス図
cla s s 設 計 （ PIM） モ デ ル

外部システムからのアクセスを簡単にできるように、I/Fを集約した
FACADEを設けました。

ユ ー ザA

0..1

F a ca d e++

ユーザログオン(ユーザ名, パスワード)
サービス実行(サービス内容)

承認

認証

1

+
#
#
#

ログオン(ユーザ名, パスワード) : 認証証明書
アカウントの登録(アカウント) : アカウント登録結果
サービスの承認(アカウント, サービス) : void
照合する(ユーザ名, パスワード) : void

1

1

+
+
+
+
+
+

監視

1

アカウント登録(アカウント, 認証証明書) : アカウント登録結果
サービス実行(サービス種別, 認証証明書) : サービス利用量
ユーザ削除(アカウント, 認証証明書) : アカウント削除結果
ユーザ使用可能サービス登録(アカウント, サービス) : void
サービスの登録(サービス種別, 認証揮発データ) : void
サービスの認証(アカウント, サービス, 認証証明書) : void+

監視の実行() : void1

11<<enumeration>>
サー ビ ス種別
アカウント登録
サービス承認アカウント削除
印刷サービス

監視を実行する
登録課計

登録アカウントリスト
登録サービス<<enumeration>>
ア カウン ト削除結果

承認状況を
変更する

削除成功
削除失敗

サービスの承認設
定を確認する

監視実行時に、承認無効（サービス利用不可）になる場合がある<<enumeration>>
ア カウン ト登録結果
登録成功
登録失敗
0..*

0..*
ア カウン ト
*

-

名前
パスワード

+
+

関連サービスの承認確認(サービス種別) : bool
サービスの承認(サービス) : void

0..1
サー ビ スサービスの承認を確認する1

Nullオブジェクト

サー ビ ス利用量ルー ル

0..*

-

サービス

+

サービスの実行() : void0..*

1
ルールを確認する++

課計ルールの確認() : void課計ルールの実行() : void1

1

1
ログオンしている

認証失敗時に返す用のオブジェクトを静的に確保し
ておきます

0..1

+ログオンアカウ 0..*
ントリスト

-

+
+
0..1 +<<enumeration...
ロ グオン 結果

ログオン結果: ログオン結果
0..*アカウントの取得() : アカウント
承認サービス問い合わせ(サービス種別) : boolean
ログオン結果の取得() : ログオン結果

Nullオブジェクト

0..*

0..*
承認証明書

認証証明書
-

認可有効状況

+サービス実行権確認()

サー ビ ス利用量0..*-

承認揮発データの書き換え-記録処理()

認証失敗時に返す用のオブジェクトを静的に確保しておきます

ログオン成功ログオン失敗51

機能に着目して分析したモデル

組込み分野のための UML モデルカタログ

エンティティに着目して分析したモデル
分析モデル
モデリングのコンセプト
認証機能は、ユーザがサービスを使用したいという要求に対して、正当なユーザか？正当なサービスか？正しく使用されているか？といった観点からサービス使用に対して制限を掛けるという機能になります。この事からユーザがサービスを利用するまでに、ユーザにサー
ビス利用の制限をかけるエンテゖテゖが幾つか出現すると考えられます。
これらのエンテゖテゖを明確化することをモデリングの出発点として分析モデルを作成し
ました。

クラス図
cla s s クラス図

認証

ア カウン ト
+認証
0..*

+認証アカウント
0..1

許可する

-

カギ
ユーザ名

+アカウント1+ライセンス0..*+サービス利用可能者
0..*1+サービス利用

権限名+利用可能サービス

0..*

0..1

1

0..*

サー ビ ス情報+サービス情報+ライセンスライセンス名+ライセンス-+権限

サー ビ ス利用ライセン ス
-

権限

+権限

-

サービス名
接続先

1

0..*

サー ビ ス利用
実行する

ユーザ(from 01. ユースケースモデル)+監視対象

サー ビ ス0..*(from 01. ユースケースモデル)

監視する
0..*

+監視者

サー ビ ス利用監視+記録者
1

サー ビ ス利用量

+記録媒体
記録する

0..*

-

サービス利用状況

このクラス図において、「認証」「サービス利用」「サービス利用監視」がそれぞれ認証、承認、監視の役割に当たります。これら以外の情報がサービス利用に制限をかけるためのエンテゖテゖとなります。制限をかけるためにどのような情報が必要かという点を検討するた
めに、サービスの利用時に制限するために行う確認事項を洗い出してみます。
・正当なユーザか？
・正当なサービスか？
認証

52

組込み分野のための UML モデルカタログ

・正当な組み合わせか？
・正当に使用されているか？（監視記録）
このうち、正当な組み合わせに関しては、サービスの実行時刻や事項場所など様々な条件が考えられますが、モデルを簡素化するために、一旦、ゕカウントとサービスの組み合わせが適切か？というシンプルな確認とします。
上述した確認事項から残りのエンテゖテゖを見た場合、
・「ゕカウント」は、サービス利用者が妥当かどうかを判断するための情報
・「サービス情報」は、正当なサービスを実行するための情報
・「権限」は、どのユーザがどのサービスを実行できるかを示した情報
・「課計」は、サービスの利用状況の記録という位置づけになります。これで先ほどの確認に伴うエンテゖテゖは網羅できました。
クラス図の中で残された一つの「サービス利用ラ゗センス」は、ユーザが特定のサービスの実行を許可された事を示す情報として作成しました。

53

エンテゖテゖに着目して分析したモデル

組込み分野のための UML モデルカタログ

オブジェクト図
サービス利用前のオブジェクト構成

認証54

組込み分野のための UML モデルカタログ

サービス利用中のオブジェクト構成

最初のオブジェクト図が、ユーザから利用可能なサービスを特定するまでのオブジェクト構成を表したもので、二つ目のオブジェクト図が、利用可能なサービスが特定された後、サービスを利用して終了するまでのオブジェクト構成を表したものとなります。
「ゕカウント」「権限」「サービス情報」という関連は、認証が始まる前から既に存在しています。「認証」や「サービス利用」は、これらのエンテゖテゖや関連から、認証、承認といった制限を実現します。
「サービス利用ラ゗センス」と「ゕカウント」「サービス情報」間の関連は、承認が出来た後に作られる関連となります。また、「サービス利用監視」「サービス利用」間は、「サービス利用監視」の責務に応じて、様々な「サービス利用」の監視を行う事ができるような関連になっています。

55

エンテゖテゖに着目して分析したモデル

組込み分野のための UML モデルカタログ

シーケンス図ユースケースシナリオに基づいて作成したシーケンスは次の 4 つとなります。認証、承認、監視の３つの機能が、前述したエンテゖテゖで実現できていることが分かります。

ユーザを認証する際のシーケンス

サービスを利用する際のシーケンス

認証56

組込み分野のための UML モデルカタログ

サービスの実行を承認する際のシーケンス

サービス利用状況を監視する際のシーケンス

57

エンテゖテゖに着目して分析したモデル

組込み分野のための UML モデルカタログ

PIM 設計モデル
モデリングのコンセプト
分析モデルでは、ユーザがサービスを利用するまでに出現するエンテゖテゖを明確化することをモデリングの出発点としました。PIM 設計モデルでは、分析モデルで明確になったクラスに対して、責務を゗ンタフェース（Boundary）、機能（Control）、データ（Entity）という３つの視点で分割することをモデリングの出発点とします。
このような構造にすることにより、例えば、認証時に PC 画面からのパスワード認証であっても、指紋認証などのように機器デバ゗スからの認証であってもユーザ゗ンタフェース部
分を変更するだけで機能部分に手を加えることなく対応する事ができます。

クラス図
分析モデルで出たクラスを、゗ンタフェース・機能・データに当てはめると次のようになります。

 「認証」「サービス利用」は、

゗ンタフェース〒機能 「サービス利用監視」は、機能 「ゕカウント」「サービス情報」「権限」「課計」「サービス利用ラ゗センス」は、データ
このため、「認証」と「サービス利用」は、それぞれ次のように責務を分離しました。

 「認証窓口」「サービス利用窓口」「サービスプロキシ」は、゗ンタフェース
 「認証」「サービス利用」は、機能
また、「ゕカウント」「サービス情報」「権限」の静的なデータは、どこか格納しておくものが必要になります。そのため、それぞれ一覧という名前をつけたクラスを導入しました。
さらに機能の結果保持用のクラスを導入して、操作を追加すると次のようなクラス図とな
ります。

認証

58

組込み分野のための UML モデルカタログ

59

エンテゖテゖに着目して分析したモデル

組込み分野のための UML モデルカタログ

シーケンス図分析モデルをベースに PIM 設計モデルのクラス構造に基づいて作成したシーケンス図が次の４つの図になります。ゕクターがユーザ゗ンタフェースの責務を持つクラスとしかゕクセスしていません。

ユーザを認証する際のシーケンス
sd シーケンス図:アカウント
一覧

:ユーザ
1.0

登録アカウント :アカウント

登録アカウントのカギ :カギ:認証窓口

1.1 ユーザ名を入力する(ユーザ名)
1.2 パスワードを入力する(パスワード)
1.3 認証する() :認証結果
1.4

1.5

入力アカウント :アカウント:認証

1.6 認証する(入力アカウント) :
認証結果
1.7

:認証結果

1.8 ユーザ名を取得する() :ユーザ名
1.9 指定ユーザのアカウントを取得する(ユーザ名) :アカウント
loop
1.10 ユーザ名を取得[登録アカウント数分]する() :ユーザ名
break[ユーザ名=登録アカウント.ユーザ名]

opt[アカウントが取得できた]

1.11 カギを取得する() :カギ

1.12 カギを取得する() :カギ
1.13 正当性を判断す
る(カギ) :boolean
alt
1.14

[正当性の判断に成功した]

1.17

認証

1.15 認証結果コードを設定する(認証結果コード)
1.16

60:サービス利用窓口

組込み分野のための UML モデルカタログ

サービスを利用する際のシーケンス
sd シーケンス図

:ユーザ
1.0

:サービス利用窓口

1.1 サービスを利用する()
:利用結果

1.2

:サービス利用

1.3 承認する(アカウント,
string) :利用結果
ref

サービスの実行を承認する
1.4

opt[承認結果がOKだった]
1.5 サービスを利用する(サービス利用ライセンス) :利用結果ref

サービス利用状況を監視する
1.6

1.7

61

エンテゖテゖに着目して分析したモデル

組込み分野のための UML モデルカタログ

サービスの実行を承認する際のシーケンス
sd シーケンス図:サービス利:サービス利用窓口

用:アカウント:権限:サービス利用情報

1.0 承認する(サービス名) :利用結果
1.1

:利用結果

<<create>>
1.2 権限を取得する() :権限
1.3 サービス利用ライセンスを取得する(サービス名,
アカウント) :サービス利用情報
loop

1.4 サービス名を取得す[登録サービス分]

る() :サービス名

break[サービス名=サービス利用情報.サービス名]alt[サービス利用情報が取得できた]

1.5:サービス利<<create>>

用ライセンス

1.6 利用結果コードを設定する()

1.7

サービス利用状況を監視する際のシーケンス
sd シーケンス図:サービス利:サービス利:サービス利:サービス利:サービス利:サービス利:サービスプ用窓口

用用ライセンス

用情報

用監視

用量

ロキシ

opt
[サービス利用ライセンスが存在する]
1.0 サービスを利用する(ライセンス) :利用結果

1.1

:利用結果

1.2 サービス利用情報を取得する()1.3 接続先を取得する() :接続先
1.4 サービスを利用する(接続先)
1.5:サービス利用状況

1.6 サービス利用状況を通知する(イベント)

1.7 サービス利用状況を記録す

1.8 利用結果コードを設定する(サービス利用状況)

る(利用結果コード)

認証62

組込み分野のための UML モデルカタログ

状態に着目して分析したモデル
分析モデル
モデリングのコンセプト
ユーザが認証された・認証されていない、といった状態に着目したモデルです。
認証モデルは、ユーザが認証されているか・認証されていないか、によってユーザからの処理依頼に対する振舞いを適切に切替えることが重要です。振舞いの切替えに、ヌケ・モレが無いことを、コーデゖング時ではなくて、構造設計レベルで抑えようというのがこのモデルのコンセプトです。

クラス図
c la s s 分 析 モ デ ル

ユーザ

認証
-

ア カウン ト
+認証アカウント

認証済みかどうか
*

1

-

権限
+所有権限

ユーザ名
パスワード

1

1

1

-

サービス名
サービス利用の可否

1

サー ビ ス利用量+サービス利用量

認証済みのときにのみ承認を得ることができる

1

-

サービス名
利用量

+サービス利用量+承認サービス

*
承認

-

1

サービス名
承認済みかどうか 1

承認済みのときにのみサービスを利用できる

利用する

サー ビ ス

+サービス

-

サービス名

0..1

1

更新する

具象サー ビ ス

ユーザとの認証に絡む振舞いを担うクラスとして「認証」を設けます。
ユーザ毎の情報を保持するクラスとして「ゕカウント」を設けます。「ゕカウント」には、認証に必要な情報「権限」と、そのゕカウントが過去にサービスを利用した記録である「サービス利用量」を関連付けます。
63

状態に着目して分析したモデル

組込み分野のための UML モデルカタログ

ユーザが認証されたに利用出来るサービスは複数あり、サービス毎に承認が必要と考え、サービス毎の承認ずみかどうかを表すために「承認」を設けます。
ユーザのサービスを利用によって使用量を監視・記録するために「サービス」を設けます。
各々のサービス固有処理は、「サービス」から派生した「具象サービス」が担うものとします。
ユーザによるサービス利用を監視した結果をユーザ毎に分けて記録するために、「サービス」からも、「ゕカウント」に関連づけた「サービス利用量」に関連を持たせます。

ステートマシン図s t m 状態遷移
認証済
[サービスA]サー ビ ス未利用サービスを利用する [承認NG]
未認証

認証する [認証OK]
サービスを利用する [承認OK]

サービス利用を終了する

サー ビ ス利用中認証する [認証NG][サービスB]サー ビ ス未利用サービスを利用する [承認NG]

サービスを利用する [承認OK]

サービス利用を終了する

サー ビ ス利用中

認証モデル全体が、ユーザ認証、サービス利用承認によりどのように状態が変化するかを示します。
ユーザが認証されていない状態を「未認証」、ユーザが認証された状態を「認証済」と呼ぶことにます。最初の状態は「未認証」です。ユーザが認証を試みて、システムに正当なユーザであると判断されると「認証済」へ遷移します。
「認証済」状態にネストする形で、サービスを利用していない「サービス未利用」と、サービスを利用中の「サービス利用中」の 2 つの状態があります。「認証済」に遷移した直後
は、「サービス未利用」です。これらの状態は、サービス毎にあります。ステートマシン図

認証64

組込み分野のための UML モデルカタログ

では、サービス A とサービス B の 2 つのサービスについて、それぞれ状態を持てることを示しています。
ユーザがサービスを利用しようとすると、システムが認可するかどうか判断します。シス
テムが承認した場合は「サービス利用中」に遷移します。システムが承認しない場合は、「サービス未利用」に留まります。
ただし、「サービス未利用」と「サービス利用中」の状態は、システムに 1 つではなく、サービス毎に状態をもつ必要があります。
以下に、各状態における振る舞いの違いを示します。振る舞いが未定義の部分は―とし、「何もしない」とします。
状態

゗ベント
ユーザを認証するサービスを利用するサービスの利用終了

認証できれば「認証済」へ遷移――サービス未利用―承認できれば、サービスを起動し、「サービス利用中」へ遷
移―サービス利用中――

サービスを終了し、「サービス未利用」へ
遷移

未認証
認証済

例えば、「ユーザを認証する」は、「未認証」のときしか動作せず、それ以外の「認証済」状態では何もしません。

65

状態に着目して分析したモデル

組込み分野のための UML モデルカタログ

PIM 設計モデル
モデリングのコンセプト
未認証・認証済、サービル未利用・サービス利用中、それぞれの状態を表すために、デザ゗ンパターンの 1 つ、ステートパターンを適用します。
ステートパターンは、振舞いに関するデザ゗ンパターンの１つです。ステートパターンを用いることで、状態によって振る舞いを変えるための条件分岐が不要になります。また、状態遷移図に対して状態遷移表がそうであるように、状態毎の振舞いの違いを考えるときのモ
レ・ヌケを防止する効果があります。

認証66

組込み分野のための UML モデルカタログ

クラス図
c la s s PIMモ デ ル

ユーザ

ユーザ認証状態のステートパターン適用範囲
ア カウン ト認 証 コ ン テ キ スト++~+

-アカウントリスト

認証する(ユーザ名, パスワード)*
サービスを利用する(サービス名)
状態を設定する(認証状態)
サービス利用を終了する(サービス名)*+認証したアカウント
1

1

-

ユーザ名
パスワード

+
+
+

ユーザを認証する(ユーザ名, パスワード)
サービス利用を承認する(サービス名)
サービス利用量を取得する(サービス名)
サービス名

-認証

1

サービス名

1

1

<<interface>>
認証状態
+
+
+

認証する(ユーザ名, パスワード)
サービスを利用する(サービス名)
サービス利用を終了する(サービス名)+サービス利用量

1

サ ー ビ ス利 用 量
+

利用量

+

利用量更新(利用量) : void

+
+
+

1
権限

-

+サービス利用量
未認証

+所有権限

権限の有無

1

認証済

認証する(ユーザ名, パスワード)
サービスを利用する(サービス名)
サービス利用を終了する(サービス名)+++認証する(ユーザ名, パスワード)
サービスを利用する(サービス名)*
サービス利用を終了する(サービス名)
サービス名
1

サービス利用承認のステートパターン適用範囲
1+サービス利用コンテキスト*

サ ー ビ ス利 用 コ ン テ キ スト++~

サー ビ ス

サービスを利用する(アカウント)
サービス利用を終了する()状態を設定する(サービス利用状態)

-サービス

1
1

-

1 +
+

-サービス利用状態

サービス名: String
サービス(アカウント) : void
サービスする()<<interface>>
サ ー ビ ス利 用 状 態+++承認する(アカウント)
利用する()
終了する()

具象サー ビ ス+

サ ー ビ ス未 利 用+++

承認する(アカウント)
利用する()
終了する()

サービスする()サ ー ビ ス利 用 中+++承認する(アカウント)
利用する()
終了する()

1

システムに登録されたユーザ情報である「ゕカウント」には、サービス毎にそのサービスを利用可能か示す「権限」と、サービスを利用したときに計上される「サービス利用料」を関連づけます。
実際のサービスを提供するクラスは、認証モデルから独立して拡張できるように、「具象サービス」として「サービス」クラスから派生させています。

67

状態に着目して分析したモデル

組込み分野のための UML モデルカタログ

オブジェクト図
認証していない段階のオブジェクト構成
ob je c t 未認証状態

サー ビ スX権限 :権限

ア カウン トAさ ん :ア カウン ト

サー ビ スY 権限 :権限

サー ビ スX利用量 :サー ビ ス利用量

サー ビ スY 利用量 :サー ビ ス利用量

:認証コ ン テ キ スト

:未認証

Aさ ん :ユ ー ザ

このオブジェクト図では、1 つのゕカウント「ゕカウント A さん」があり、2 つのサービ
ス「サービス X」と「サービス Y」があるシステムを示したものです。
未認証状態では、ユーザ A さんはゕカウントの情報を辿ることも、サービスを使うこともできません。

認証

68

組込み分野のための UML モデルカタログ

認証済みでサービスが利用されていない状態のオブジェクト構成
ob ject 認証済み状態(サー ビ ス利用なし )サー ビ スX権限 :権限

サー ビ スY 権限 :権限
ア カウン トAさ ん :ア カウン ト
サー ビ スX利用量 :サー ビ ス利用量

サー ビ スY 利用量 :サー ビ ス利用量

:認証コ ン テ キ スト

:認証済

Aさ ん :ユ ー ザサー ビ スX利用状態 :サー ビ ス利用コ ン テ キ スト

:サー ビ ス未利用

サー ビ スY 利用状態 :サー ビ ス利用コ ン テ キ スト

:サー ビ ス未利用認証状態では、「認証済み」のオブジェクトが「ゕカウント A さん」との関連を持ち、「ユーザ A さん」が、ゕカウント情報を辿れるようになります。
また、「サービス X」と「サービス Y」の利用コンテキストが生成され、サービスの利用を試みることができます。ただし、「サービス利用コンテキスト」には「サービス未利用」
状態が関連付けられており、承認処理を経由しなければサービスを利用することができなくなっています。

69

状態に着目して分析したモデル

組込み分野のための UML モデルカタログ

認証済みでサービス X を利用中のオブジェクト構成
ob ject 認証済み状態（ サー ビ ス利用中）

サー ビ スX権限 :権限

サー ビ スY 権限 :権限

ア カウン トAさ ん :ア カウン ト

サー ビ スX利用量 :サー ビ ス利用量

サー ビ スY 利用量 :サー ビ ス利用量

:認証コ ン テ キ スト
Aさ ん :ユ ー ザ:認証済

サー ビ スX利用状態 :サー ビ ス利用コ ン テ キ スト

:サー ビ ス利用中

サー ビ スX :具象サー ビ ス

サー ビ スY 利用状態 :サー ビ ス利用コ ン テ キ スト

:サー ビ ス未利用

この図は、「ユーザ A さん」が、「サービス X」を利用している状態を示しています。
サービス X のためのサービス利用コンテキスト「サービス X 利用状態」には、「サービス利用中」オブジェクトが関連付けられ、その先に「サービス X」オブジェクトが関連付けられています。また、「サービス X」は、「サービス X 利用量」との関連を持ち、適宜、サービス利用量を更新します。
ステートパターンを適用し、状態に応じたオブジェクトを組み合わせて認証モデルを実現
します。

認証

70

組込み分野のための UML モデルカタログ

シーケンス図ユーザを認証する際のシーケンス
s d ユ ー ザを 認証す る
account :アカウント:ユーザ:認証コンテキスト:未認証

認証する(ユーザ名, パスワード)

認証する(ユーザ名, パスワード)

loop ユ ー ザのアカウン トを 探す[全てのアカウントについて繰り返す]
ユーザを認証する(ユーザ名, パスワード)b rea k
[認証できた]op t 認証済状態への遷移[認証OK]

authenticated :認証済

loop 全サー ビ ス利用コン テ キ ストの生成[サービスの数だけ繰り返す]:サービス利用コンテキスト:サービス未利用状態を設定する(authenticated)

:認証結果
:認証結果

71

状態に着目して分析したモデル

組込み分野のための UML モデルカタログ

サービスを利用する際のシーケンス
s d サー ビ ス を 利 用 す る:認証コンテキスト

authenticated :認証済

:サービス利用コンテキスト:サービス未利用

usingService :サー
ビス利用中

service :具象サービス

account :アカウント

:権限

ユーザ

サービスを利用する(サービス名)

サービスを利用する(サービス名)
サービスを利用する(account)ref
サー ビ ス利用を 承認す る

a lt サー ビ ス利用[承認OK]
利用する()

サービスする()ref
サー ビ スの利用を 監視す る

:利用結果
:利用結果

[承認NG]
利用する():利用結果_承認NG

:利用結果

:利用結果

:利用結果

認証

72

amount :サービス利用量

組込み分野のための UML モデルカタログ

サービスの実行を承認する際のシーケンス
s d サー ビ ス 利 用 を 承 認 す る:サービス利用コンテキスト:サービス未利用

account :アカウント:権限

amount :サービス利用量承認する(account)

サービス利用を承認する(サービス名):承認結果

op t サー ビ ス利用中へ遷移[承認OK]
生成(サービス名, account)usingService :サー
ビス利用中

サービス利用量を取得する(サービス名):amount

生成(amount)service :具象サービス

状態を設定する(usingService)

サービス利用状況を監視する際のシーケンス
s d サー ビ ス の利用を 監視す る
service :具象サービス

amount :サービス利用量

実際のサービスの処理を行なう()

利用量更新(利用量)73

状態に着目して分析したモデル

組込み分野のための UML モデルカタログ

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

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

自己診断

74

組込み分野のための UML モデルカタログ

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

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

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

U C02:自己診断を中止す る<<include>>

機器管理者

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

75

要求仕様

組込み分野のための UML モデルカタログ

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

■ゕクター
機器管理者

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

自己診断

76

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

■ゕクター
機器管理者

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

77

要求仕様

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

■ゕクター
なし

■事前条件
なし

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

自己診断

78

組込み分野のための UML モデルカタログ<UC04:自己診断を設定する>■概要
機器管理者が組込み装置に自己診断を設定する。

■ゕクター
機器管理者

■事前条件
なし

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

要求仕様

組込み分野のための 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. 山田太郎さんはルーターに設定する自己診断の名前を『゗ーサネット』と指示する。
自己診断

80

組込み分野のための UML モデルカタログ

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

81

要求仕様

組込み分野のための UML モデルカタログ

モデル一覧
モデル名

概要

ポ゗ント

エンテゖテゖに
着目して分析したモデル

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

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

メタフゔを使って分析したモデル

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

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

自己診断

82

組込み分野のための UML モデルカタログ

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

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

診断対象

診断項目

診断結果

診断項目

診断結果

診断項目

診断結果

診断項目

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

×× 診断

A 診断

A 診断

B 診断

C 診断
D1 診断

B 診断
並行に診断

C 診断
D2 診断

順番に診断
E 診断

83

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ

分析モデル
前述の(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)

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

自己診断

84

組込み分野のための UML モデルカタログ

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

85

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ

オブジェクト図
組込み装置(ルーター)のオブジェクト図
゗ーサネット×2、シリゕル×1 のルーターのオブジェクト図を示します。
obj ect 組込み装置( ルー ター ) の構成
イー サネット1のレジスタ読み書き :診断項目
イー サネット1 :デ バイス

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

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

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

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

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

シリアル :デ バイス

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

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

自己診断

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

組込み分野のための UML モデルカタログ「診断、診断対象、診断項目、診断結果の関係」オブジェクト図
先のルーターで診断と診断に関連するモノを示したオブジェクト図です。
obj ect 診断、診断対象、診断項目、診断結果の関係

イー サネット 1 :診断

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

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

:診断結果
:診断結果

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

イー サネット 2 :診断

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

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

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

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

87

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ「組み合わせた診断」オブジェクト図
同じく先のルーターで組み合わせた診断のオブジェクト図です。
obj ect 組み合わせた診断
イー サネット簡易 :診断

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

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

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

シリアル簡易 :診断

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

セキ ュ リテ ィ監視アプ リケー ショ ン :診断「゗ーサネット簡易:診断」は「゗ーサネット 1 簡易:診断」を実施し、次に「゗ーサネッ
ト 2 簡易:診断」を実施します。
「日次:診断」は「゗ーサネット 1 簡易:診断」と「゗ーサネット 2 簡易:診断」を並列に実施し、次に「シリゕル簡易:診断」を実施し、次に「セキュリテゖ監視ゕプリケーション:診断」を実施します。
「゗ーサネット 2 簡易:診断」から「゗ーサネット簡易:診断」へのリンク、「セキュリテゖ監視ゕプリケーション:診断」から「日次:診断」へのリンクは診断の終了を通知するために
あります。

自己診断

88

組込み分野のための 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..*

診断項目

診断対象
名前

0..*

下位
0..*

診断
項目
1

結果
0..*

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

デ バイス
1

1..*

生成する(文字列)

上位
0..*

1

組込み装置

89

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ

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

ユースケース「UC01:自己診断を行う」のシーケンス図s d U C01
ルーター

日次 :診
断

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

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

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

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

レポート1
:レポート

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

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

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

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

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

出力する()

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

自己診断

90

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

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

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

レポート1
:レポート

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

(b)

生成
する()

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

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

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

書き込む()

変換する()

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

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

変換する()

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

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

91

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ

ユースケース「UC02:自己診断を中止する」のシーケンス図s d U C02
ルーター

日次 :診
断

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

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

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

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

レポート1
:レポート

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

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

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

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

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

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

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

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

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

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

自己診断

92

組込み分野のための UML モデルカタログ

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

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

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

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

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

イーサネットメモ
リチェック :診断(b)
チェック項目を加える(イーサネット1のメモリ読み書き)(a)ゕクターはルーターへ自己診断の名前、起動方法、診断対象、診断内容を指示します。
(b)ルーターは起動条件と診断を生成し、関連付けます。

93

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ

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

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

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

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

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

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

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

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

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

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

イーサネット:診断

最初を設定する(イーサネットメモリチェックのクローン)
最後を設定する(イーサネットレジスタチェックのクローン)
次を設定する(イーサネットレジスタチェックのクローン)(a)ゕクターはルーターへ自己診断の名前、起動方法、組み合わせる診断を指示します。
(b)ルーターは起動条件と診断を生成し、診断を複製し、関連付けます。

自己診断

94

組込み分野のための UML モデルカタログ

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

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

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

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

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

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

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

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ

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

設計

A 診断

B 診断

C 診断

順
番
に
実
行

D 診断

A 診断
並行に実行
B 診断

C 診断

D 診断

E 診断

E 診断

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

自己診断

96

組込み分野のための UML モデルカタログ

クラス図
設計ではクラスが非常に増えたため、3 個のドメ゗ンとユーテゖリテゖに分けました。
pk g 設計全体
診断ドメ イン対象ドメ インレポー ト ドメ イン

ユ ー テ ィリテ ィ

診断ドメ゗ン：自己診断の中心となる「診断」クラスを中心とする部分
対象ドメ゗ン：「診断対象」クラスを中心とする部分
レポートドメ゗ン：「レポート」クラスを中心とする部分
ユーテゖリテゖ：スレッドなどを実現する汎用的なラ゗ブラリ

97

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ「診断ドメイン (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..*

98

+
+
+

-診断項目
診断項目

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

組込み分野のための UML モデルカタログ

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

99

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ「診断ドメイン (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

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

100

組込み分野のための UML モデルカタログ「対象ドメイン」クラス図
cl a s s 対象ドメ イン

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

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

-対象

0..*

設計::診断対象
+
+

-対象

1..*

-下位
0..*

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

+

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

1..*

-アプリケーション

1

1

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

設計::デ バイス管理
+
+
+
+
+

名前: 文字列

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

生成する(文字列) : void

-デバイス

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

1..* +++

設計::デ バイス

1..*

1

1

+
+
+
+
+

設計::診断項目-

1..*

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

-機能ユ
ニット

-診断
項目

名前: 文字列

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

-診断項目

1..*

1

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

+
+
+
+
+

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

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

101

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ「レポートドメイン」クラス図
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

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

自己診断

-出力方法

102

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

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

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

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

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

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

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

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

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

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ

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

ユースケース「UC01:自己診断を行う」のシーケンス図s d 設計U C01
UI

:診断実行

:診断管理

:スレッド
プール

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

:日次

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

日次タスク:診断タスク

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

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

自己診断

104

組込み分野のための UML モデルカタログ
s d 設計U C01日次
日次 :順番 イーサネット簡に実行す
易 :並行に実る診断
行する診断

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

レポート1 :
レポート

出力方法1
:出力方法

診断する(診断ID1)
キャンセルか(診断ID1) :boolean
診断する(診断ID1,レポート1)『設計UC01イーサネット簡易』参照
キャンセルか(診断ID1) :boolean
診断する(診断ID1,レポート1)(a)
キャンセルか(診断ID1) :boolean
診断する(診断ID1,レポート1)
出力する()

書き込み排他制御を開始する()

出力する()(b)

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

105

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ
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簡易』参照(a)「゗ーサネット簡易:並列に実行する診断」は「診断する」メッセージを受信すると、診断タスクを生成し、キャンセル(診断中止があるか)をチェックし、生成した診断タスク
をスレッドプールへ渡して診断を起動します。
(b)スレッドプールはスレッドを使用して、各診断を並列に実行させます。

自己診断

106

組込み分野のための 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)

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

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

107

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ

ユースケース「UC02:自己診断を中止する」のシーケンス図s d 設計U C02
UI

:診断実行

:診断管理

:スレッド
プール

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

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

日次タスク:診断タスク

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

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

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

図示できていませんが、「診断する」メッセージを実行中に「自己診断の中止を指示する」メッセー
ジが送信されています:日次検索する(日次) :診断ID:診断ID1
診断を中止する(診断ID1)
キャンセルする診断IDを登録する(
診断ID1)(b)(a)ゕクターから診断開始の 指示を受けると、ルーターは「ユースケース「UC01:自己診断を行う」のシーケンス図」と同様に動きます。
(b)ゕクターから診断の中止の指示を受けると、診断実行は診断管理から該当する診断゗ン
スタンスを検索し、「診断を中止する」メッセージを送信します。

自己診断

108

組込み分野のための UML モデルカタログ
s d 設計U C02日次
日次 :順番に実行する診断イーサネット簡
易 :並行に実行する診断

レポート1 :
レポート

出力方法1
:出力方法

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

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

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

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

109

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ
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簡易』参照(a)「゗ーサネット簡易:並列に実行する診断」は「診断する」メッセージを受信すると、診断タスクを生成し、キャンセル(診断中止があるか)をチェックし、生成した診断タスク
をスレッドプールへ渡して診断を起動します。
(b)スレッドプールはスレッドを使用して、各診断を並列に実行させます。

自己診断

110

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

111

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ

シナリオ「SC0401: 自己診断を設定する(1 つの診断対象に対する診断)」のシーケン
ス図s d 設計SC0401
UI

:デバイス
管理

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

:診断管理

:診断実行

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

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

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

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

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

毎日午前1時 :周期起動

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

イーサネットメモリ
チェック :単一の対象に対する診断チェック項目を加える(イーサネット1のメモリ読み書き)登録する(イーサネットメモリチェック) :診断
タイマーを設定する(イーサネットメモリチェック)『設計タイマーを設定する』参照(a)ゕクターはルーターへ自己診断の名前、起動方法、診断対象、診断内容を指示します。
(b)UI は起動条件と診断を生成し、関連付け、診断を登録します。

自己診断

112

組込み分野のための UML モデルカタログ
s d 設計 タイマー を設定す る
:診断実行

:診断

:周期起動

:タイマー

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

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

間隔を取得する() :秒
登録する(タスク, 日時, 間隔) :タイマータスクハンドル(a)「診断実行」は「タ゗マーを設定する」メッセージを受信すると、必要な情報を取得し、診断タ゗マータスクを生成し、生成した診断タ゗マータスクをタ゗マーに登録します。

113

エンテゖテゖに着目した分析したモデル

組込み分野のための UML モデルカタログ

シナリオ「SC0403: 自己診断を設定する(既存の自己診断を組み合わせた診断)」のシーケンス図s d 設計SC0403
UI

:診断管理

:診断実行

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

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

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

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

(b)

イーサネッ
ト :順番に実行する診断付ける(イーサネットメモリチェック)付ける(イーサネットレジスタチェック)登録する(イーサネット,) :診断
タイマーを設定する(イーサネット)『設計タイマーを設定する』参照(a)ゕクターはルーターへ自己診断の名前、起動方法、組み合わせる診断を指示します。
(b)UI は起動条件と診断を生成し、診断を複製し、関連付けます。

自己診断

114

組込み分野のための UML モデルカタログ

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

1. 診断って何だろう？
「診断」を国語辞書で調べてみました。(大辞林より)
しんだん 【診断】 （名）スル(1) 医者が患者を診察し、病状を判断すること。
・ 「高血圧と診断する」
・ 「診断を下す」(2) 物事を調べて欠陥がないかなどその状態を判断すること。
・ 「企業診断」
つまり、診断とは病気や欠陥など悪いところがないか調べることです。装置の場合は故障箇所や不具合箇所がないか調べることです。悪いところに限らず、悪くなりかけているとこ
ろや悪くなりそうなところも調べられると、よりよい診断といえるでしょう。
次に、「診断」の類義語を挙げてみます。これらも「診断」とみなしていいでしょう。

 診断の類義語: 検診、点検、検査

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

115

メタフゔを使って分析したモデル

組込み分野のための UML モデルカタログ

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

 健康診断・毎年健康診断を受ける。
・Ｆ社では、5 年に 1 回人間ドックに変わる。40 才以上は毎年人間ドック。
・健康診断と人間ドックでは診断項目が異なる。年齢により多少診断項目が異なる。

 車検
・新車は 3 年目、以降は 2 年毎。車検の他に 6 ヶ月点検や 12 ヶ月点検もある。
・点検時期によって点検内容が異なる。

 温水洗浄便座
・自宅の温水洗浄便座のコンセントプラグに「テスト」ボタンがある。
・ボタンを押すと正常に動作するか診断してくれるようだ。
・手洗い時に水が跳ねたり湿気を含んでショートしたりする心配があるからだろうか？

 分電盤
・自宅の分電盤の蓋をあけると「テスト」ボタンがある。
・漏電やショートしていないか診断してくれるのだろう。

 消防設備点検
・自宅マンションでは、年に 2 回、火災報知器が正しく動作するか調べに来てくれる。
・会社でも、年に 2 回くらい消防設備を点検しているのを見かける。
自己診断

116

組込み分野のための UML モデルカタログ

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

車

温水洗浄便座

分電盤

消防設備

診断名

健康診断
人間ドック

車検
定期点検

テスト

テスト

消防点検
防災点検

診断時期

年1回
望んだとき

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

ボタンを押
したとき

半年毎

診断対象

本人、子供、社員

車

電気設備

電気設備

消防設備

診断依頼者

本人、親、会社

所有者

家人

家人

本人、管理会
社、企業

診断場所

病院、健康管理室

車デゖーラー、
車検場

設置場所

設置場所

設置場所

診断実施者

医者

メカニック

装置

装置

業者

診断項目

血液、血圧、視力、聴力、胃、肺、心臓など

エンジン、ブレーキ、オ゗ル、
タ゗ヤなど

ショート

漏電、ショ
ート

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

診断結果

健康ランク、問題部
位、状態など問題なし、
要修理箇所、予防修理箇所

ブザー？

ブザー？

異常なし
異常個所

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

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

117

メタフゔを使って分析したモデル

組込み分野のための UML モデルカタログ

クラス図
共通項目を使って、概念モデルのクラス図を書いてみます。
class 診断:概念モデル
診断時期

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

前回実施日

診断周期
診断条件

1

確認する

「健康診断」「防災点検」「車検」など

健康診断での
「親」

参照者
*

情報

確認する

依頼元 *

健康診
断での
「医者」

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

1

1

*
診断者

確認する

1

診断結果

状態
0..1 所見
結果 *

特定する
診断部位

対象 1

担当者 *
診断する

結果

*

健康診
断での
「子供」

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

*
診断

診断名
* 診断説明
診断

依頼する

1

診断

実施日 1

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

診断項目

診断 1
診断依頼者

1

一度も診断してない場合は、誕生日や購入日などを前回実施日とする

時期 *

診断日時

1

*

診断対象
診断対象名

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

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

記入する

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

118

組込み分野のための UML モデルカタログ

 「診断実施者」は、専門の「診断担当者」に「診断」を依頼することもあります。さらに「診断担当者」は他の「診断担当者」に手伝いを依頼することもあります。
 「診断対象」は「診断部位」を診せることができます。あるいは、診せる方法があります。
シーケンス図
処理の流れをシーケンス図で書いてみます。
シーケンス図により、クラスに追加・変更する操作がわかってきます。
sd 診断:概念モデル
診断依頼者

診断

診断時期

前回実施日 :
診断日時

診断実施者

診断対象

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

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

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

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

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

119

メタフゔを使って分析したモデル

組込み分野のための UML モデルカタログ

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

パッケージ図まずは、概念モデルを元にパッケージに分類してみます。

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

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

診断対象

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

自己診断

120

組込み分野のための 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..*

121

メタフゔを使って分析したモデル

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

オブジェクト図
ユースケース記述に記載された゗ンスタンスに、関連しそうな゗ンスタンスを加えた゗ン
スタンス図を以下に示します。
診断毎に診断結果が生成され、診断出力されることになります。
object 自己診断分析インスタンス図
診断実施される毎に生成、診断出力
されたら破棄

すべて :診断項目

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

メモリ :診断項目

LED :診断出力

すべて :診断項目

結果#1 :診断結果

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

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

レジスタ :診断項目

毎日午前1時 :自動診断

メモリ :診断項目

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

すべて :診断項目

ロギング :診断出力

自己診断

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

122

結果#4 :診断結果

レジスタ :診断項目

結果#5 :診断結果

メモリ :診断項目

結果#6 :診断結果

組込み分野のための UML モデルカタログ

診断の実施および診断を中断した場合のコミュニケーション図を以下に示します。
sd 自己診断分析コミュニケーション図
:自己診断

:診断出力

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

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

:診断

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

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

シーケンス図
管理者の指示により゗ーサネットの自己診断を実施し、診断を中止ときのシーケンス図を示します。
sd 自己診断分析シーケンス図(診断中止時)

機器管理者

診断ボタン :
手動診断

LED :診断出力

ルータ :機能ユニット

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

すべて#1 :診断項目

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

自己診断を実施する()

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

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

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

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

メタフゔを使って分析したモデル

組込み分野のための UML モデルカタログ

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

自己診断

診断装置

機能ユニット

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

124

デバイス

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

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

125

メタフゔを使って分析したモデル

組込み分野のための UML モデルカタログ

コミュニケーション図
以下に、すべてのメモリ診断を実施する場合のコミュニケーション図を示します。
メ゗ン基板のメモリ診断と゗ーサネットのメモリ診断は並列動作し、゗ーサネットのメモ
リ診断の方が先に終わる順序にしてあります。
sd 自己診断PIM設計:コミュニケーション図
コンソール出力 :診断出力

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

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

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

1.1: 実施する()

1.3: 実施する()

すべてのメモリ :診断

1.2: 実施する(診断)

すべてのメモリ :診断

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

メイン基板 :診断ノード

1.7: 実施する()

すべてのメモリ :診断

すべてのメモリ :診断

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

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

自己診断

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

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

1.5: 実施する()

1.6: 実施する(診断)1.4: 実施する(診断)イーサネットメモリ :診断項目

126

組込み分野のための UML モデルカタログ

シーケンス図メ゗ン基板と゗ーサネット基板があり、それぞれにメモリが搭載されていて、メモリを診断する場合のシーケンス図を以下に示します。
メ゗ン基板での診断はハードウェゕで行われ、診断依頼は即時復帰し、診断完了は割り込
みで通知される非同期型を想定しました。ソフトウェゕで行う場合でも、スレッド生成して非同期型にすることもできます。
サブ基板での診断はソフトウェゕで行われ、診断実施は診断終了まで復帰しない同期型を想定しました。診断装置もソフトウェゕ実装なので同期型にしました。
診断対象が診断結果を生成する記述は省略しました。診断結果をオブジェクト(クラス)にせずにエラーコードを直接診断に通知するように仕様変更してもいいと思います。
sd 自己診断PIM設計:シーケンス図
手動診断

診断装置

メイン基板 :
診断対象 A

機器管理者

イーサネット:診断対象

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

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

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

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

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

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

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

127

メタフゔを使って分析したモデル

組込み分野のための UML モデルカタログ

ステートマシン図
診断対象クラスのステートマシン図
stm 自己診断PIM設計:診断クラスのステートマシン図
実施()

停止中
開始

実施中

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

中止中通知(診断結果)

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

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

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

開始

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

自己診断

128

組込み分野のための UML モデルカタログ

おわりに2009 年 11 月のキックオフで活動を開始してから、約 10 ヶ月。
所属はもちろんのこと、仕事の内容や経験も異なる約 20 名のメンバが、業務の合間を縫いながら月一ベースでの定例打ち合わせを重ね、当初の目標である「モデルカタログの第一版」をなんとかリリースすることが出来ました。

モデルカタログに対する意義や期待についてはメンバ全員で共通していたものの、実際に作るとなると、その前提となるプロセスやモデリング手法、対象とする分野等々、いろいろな検討事項がありましたが、今回は、立場や経験の異なるメンバが限られた時間で活動するということを前提に、「まずは各自の思い描くモデルを描いて、それをカタログにしてみよう」というところからスタートしました。

少ない活動の中、モデルカタログを利用する方のために、その作成においては下の 4 点を考慮しました。
カタログの使い方をきちんと明示すること
複数の分野・対象についてのモデルを掲載すること同じ分野・対象については、複数の視点からの異なるモデルを掲載することモデルについては、それを導くまでの思考過程やモデルの変化を明記すること

今回リリースするカタログは、扱っている分野・対象が少なかったり、モデルの記法が多少揃っていなかったり等々、カタログと呼ぶにはまだ質量ともに不足していますが、何とか
上記４点については遵守できたのではないかと自負しています。ぜひ、開発の現場において活用して頂くとともに、みなさんの率直なご意見を頂ければ幸いです。

なお、今回のカタログはあくまでも「第一版」です。今後も、利用した方からのフゖード
バックを反映しながら、少しずつカタログの質量を充実させていく計画です。
「第二版」については、まずは「量」の充実を図りたいと考えており、組込みソフトウェ
ゕのモデリングに関わる多くの方の参加を期待しています。
ご意見やご参加のお問い合わせについては、以下の URL をご覧ください。

129

組込み分野のための UML モデルカタログ

UMTP 組込みモデリング分科会メンバ（初版作成フェーズ：2009 年 11 月～2010 年 10 月）
あいうえお順、敬称略
石滝 智洋（オリンパスソフトウェゕテクノロジー 株式会社）

石田 晴幸

（株式会社

大森 淳夫

（パ゗オニゕ

小黒 登行

（株式会社

栗田 道広

（スター精密

品川 正彦

（株式会社

白神 一久

（富士通

新家 了訪

（株式会社

テ゗ジ゗エル）

鈴木 茂

（株式会社

オージス総研）高原 大樹（ゕドソル日進

時田 大介（スター精密西口 敦子（NEC ラーニング 株式会社）

畑

（株式会社

理介

富士通コンピュータテクノロジーズ）
株式会社）
豆蔵）
株式会社）
日立゗ンフォメーションゕカデミー）
株式会社）

株式会社）
株式会社）

オージス総研）

松嶺 恭守（理想科学工業

株式会社）

山本 裕行

（株式会社

日立゗ンフォメーションゕカデミー）

芳村 美紀

（株式会社

エクスモーション）：副主査

渡辺 博之

（株式会社

エクスモーション）：主査

130

組込み分野のための UML モデルカタログ
発行日
発行者
編 著
印刷

２０１０年（平成２２年）１０月 1 日
UMTP, Japan
組込みモデリング分科会

UMTP, Japan
東京都渋谷区代々木 1 丁目 22 番 1 号
http://www.umtp-japan.org/

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