組込み分野のための
UML モデルカタログ
2014 年 10 月版

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

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

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

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

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

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

2

2014 年 10 月版

目次

UML モデルカタログの歩き方 ............................................................................... 5
UML モデルカタログとは ................................................................................... 6
カタログの構成................................................................................................ 7
カタログの使い方 ............................................................................................. 9
ラインナップ ................................................................................................ 11
モデルカタログ：製品編 .................................................................................... 13
P001 孔版印刷機 ......................................................................................... 14要求仕様 .................................................................................................. 14
モデル一覧 ............................................................................................... 17
エンティティに着目したモデル ..................................................................... 18
P002 電子オルゴール ................................................................................... 20
はじめに .................................................................................................. 20要求仕様 .................................................................................................. 20
モデル一覧 ............................................................................................... 23
エンティティに着目したモデル ..................................................................... 24
P003 インライン装置 ................................................................................... 26
要求仕様 .................................................................................................. 26
モデル一覧 ............................................................................................... 30
ドメイン構造に着目したモデル ..................................................................... 31
P004 エアコン ............................................................................................ 33
要求仕様 .................................................................................................. 33
モデル一覧 ............................................................................................... 37
熱交換の原理に着目したモデル ..................................................................... 38
ソフトウェアで制御する対象に着目したモデル ................................................. 40
P005 交通 IC カードチャージ機 ...................................................................... 42
はじめに .................................................................................................. 42
要求仕様 .................................................................................................. 42
モデル一覧 ............................................................................................... 46
BCE パターンを用いたモデル........................................................................ 47
モデルカタログ：機能編 .................................................................................... 49
F001 認証 .................................................................................................. 50
3

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

要求仕様 .................................................................................................. 50
モデル一覧 ............................................................................................... 52
機能に着目したモデル ................................................................................. 53
エンティティに着目したモデル ..................................................................... 55
状態に着目したモデル ................................................................................. 57
F002 自己診断 ............................................................................................ 59
要求仕様 .................................................................................................. 59
モデル一覧 ............................................................................................... 61
エンティティに着目したモデル ..................................................................... 62
メタファを使ったモデル .............................................................................. 64
モデルカタログ：部品編 .................................................................................... 66
C001 目標制御 ............................................................................................ 67
はじめに .................................................................................................. 67
要求仕様 .................................................................................................. 67
モデル一覧 ............................................................................................... 70
エンティティに着目したモデル ..................................................................... 71
役割に着目したモデル ................................................................................. 73
C001 プログラム更新機能 ............................................................................. 75
はじめに .................................................................................................. 75
要求仕様 .................................................................................................. 75
モデル一覧 ............................................................................................... 78
エンティティに着目したモデル ..................................................................... 79
おわりに ...................................................................................................... 81

4

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

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

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

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

製品企画
システム・エンジニアリング・プロセス
システム要求定義

システムテスト

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

システム結合テスト

ソフトウェア・エンジニアリング・プロセス
ソフトウェア
総合テスト

ソフトウェア
要求定義

ソフトウェア
結合テスト

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

本書が開発の現場で UML モデリングを利用する際の参考になれば幸いです。
本書の適用範囲は、主に、製品開発におけるソフトウェア設計工程です。「組込みソフトウェア向け 開発プロセスガイド1」（以下 ESPR）では、右図で示す範囲です。

製品審査

ソフトウェア
詳細設計

単体テスト

実装
：適用範囲

：モデルに含まれる可能性がある範囲

図 1 組込みソフトウェア開発プロセスと本書の適用範囲ある部分をハードウェアで実現するかソフ
トウェアで実現するかは状況によって変わるため、明確にせず、システム要求定義やシステム・アーキテク
チャ設計までをモデルに含めている場合もあります。

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

1

工程名

定義

ソフトウェア
要求定義

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

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

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

『組込みソフトウェア向け開発プロセスガイド』独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター編
著、翔泳社、2007
URL：http://sec.ipa.go.jp/publish/index.html

6

2014 年 10 月版

カタログの構成
UML モデルカタログは、全体
カタログ
モデル解説書を網羅した「カタログ」ファイ
歩き方
ル(本書)と、個々のモデルにつ要
求仕様
モデルカタログ
いて詳しく記述した「モデル解
分
析
分
析
…
説書」ファイル(名前は"<カタロ
要求仕様
主要 UML 図
PIM 設計PIM 設計グ番号>_<対象名>.pdf"。例：
分析 分析
要求仕様
"F001_Authentication.pdf")に
要
求
仕
様
要求仕様
主要 UML 図
分かれています。カタログファ
EA
分析
分析
要求仕様
イルには、モデリング対象の概
モデル
分
析
分
析
…
略と、モデル全体が見渡せる少PIM 設計PIM 設計…
数のモデル図を抜粋したものが含まれています。モデル解説書…
には、モデルについての全情報が含まれています。また、場合によっては Enterprise Architect のモデルファイルが付属していますので、併せて参考にしてください。
【Enterprise Architect について】Enterprise Architect は、Windows で動作する UML モデリングツールです。組込みモデリング
部会では、スパークスシステムズ ジャパン株式会社様のご厚意により、モデリングに EnterpriseArchitect を使用しています。モデルファイルを公開するにあたり、UMTP 専用の機能限定版
Viewer を提供頂きましたので、必要な方は UMTP サイトよりダウンロードしてお使いください。
Enterprise Architect について詳しくは、http://www.sparxsystems.jp/ を参照してください。
また、各モデルは、「製品編」、「機能編」 、「部品編」に分類されています。
「製品編」は、印刷機など製品全体をモデリングして掲載しています。
「機能編」は、多くの製品に共通して搭載されている機能からいくつかをピックアップして掲載
しています。「機能編」に掲載している機能をいくつか組み合わせること
で、「製品編」に掲載している製品ができあがる
場合もあります。

製品
編

部品

製品 A

部品α

製品 B

部品α

△△1 機能

□□機能

○○機能

□□機能

△△2 機能△△3 機能

部品β

部品β

△△機能

部品γ

機能
編
○○機能

△△機能

□□機能
××機能

△△1 機能△△2 機能△△3 機能部品γ「部品編」は、より汎用的な、ライブラリとして使用できる部品を掲載
しています。この部品は、「機能編」の機能でも「製品編」の製品でも、使用することができます。

7

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

本カタログでは、まず、モデリングの対象となる製品や機能の要求仕様が定義されています。この要求仕様をもとにモデリングを行います。
本カタログでは、1 つの要求仕様に対して、複数のモデルを掲載しています。どのような状況でも正解であるモデルというものは存在しません。さまざまな状況で、さまざまな見方があり、複数のモデルが考えられます。
要求仕様の後に、これら複数のモデルのインデックスとなる
モデル一覧を用意しています。
各モデルでは、分析モデル、
PIM 設計モデル、PSM 設計モデ
ルといった具合に、段階的に詳細化を行っており、それぞれク
ラス図、オブジェクト図、コミュニケーション図、ステートマ
シン図などの UML モデルを掲載して、モデルの解説を行って
います。

要求仕様
モデル一覧
モデル 1

モデル 2

…

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

PIM 設計モデル
各種 UML 図

PSM 設計モデル
各種 UML 図※PSM 設計モデルは、本書の対象外。将来の改版において含める予定。

セクション

記載内容

ESPR におけるフェーズ

要求仕様

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

ソフトウェア要求定義

分析モデル

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

PIM 設計モデル

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

PSM 設計モデル

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

ソフトウェア・アーキテクチャ設計【複数モデルについて】モデリングの対象が同じでも、要求仕様の整理整頓の仕方や重点を置くポイントが異なれば、できあがるモデルは異なるものになります。たとえば、「機能」「エンティティ」「状態」などに着目してモデリングすることもできれば、「メタファ」に重点を置いてモデリングすることもできます。

82014 年 10 月版

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

新しい製品を開発することになり、製品全体のモデリングの参考として・・・

既存製品に新しい機能を追加することになり、その機能のサンプルとして・・・

既存製品の既存機能を改善するために、比較サンプルとして・・・

組込みシステムにおけるモデリング教育の参考資料として・・・

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

開発対象に近い製品または機能を選ぶ

カタログ(本ファイル)の該当項目を読み、参考となる内容として妥当か判断する

モデル解説書ファイルをダウンロードするモデル一覧から今回の要件に近いモデルを選ぶ

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

9

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

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

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

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

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

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

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

利用例 3
UML モデルカタログを題材として、実際にモデリングを行う勉強会の進め方を「勉強会ガイド」としてまとめましたので参考にしてください。

102014 年 10 月版

ラインナップ製品編
名前概要

キーワード※

孔版印刷機(P001)

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

孔版印刷
読み取り
書き込み
紙搬送
機器管理
ユーザインタフェース
自己診断
認証

電子オルゴール(P002)

機械式オルゴールの発音操作をソフトウェア制御する
ことで複数の曲の再生に対応できるようにしたオルゴ
ール

リスト管理
ユーザインタフェース

インライン装置(P003)

工場の生産ラインなどで使用される、上流から下流に向かって、製造物や検査品を搬送/処理する装置。どのような機構で搬送するか、どのような加工/検査をするかに関係なく、再利用可能なモデルとして提供し
ています。

自動運転
並行処理の待ち合わせ

エアコン(P004)

室内の温度(室温)と湿度を調整する空調装置

温度制御
熱交換
目標制御

交通 IC カードチャージ機
(P005)

主に鉄道の駅の乗車券用の自動券売機の横や改札の近くなどに設置されている、鉄道の乗車などに利用できる IC カードにお金をチャージするための装置

BCE
ライフタイムごとの情報の分類
システム全体の状態遷移※下線は機能編/部品編に記載があります。
機能編
名前

概要

キーワード

認証
(F001)

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

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

自己診断(F002)

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

装置診断

名前

概要

キーワード

目標制御
(C001)

制御対象の計測値が目標値となるように制御する仕組み。エアコンの温度調節や自動車の ABS など数多くの製品に組み込まれています。

数式のブラックボックス化
入力値の反映タイミング

部品編

11

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

プログラム更新
機能

ネットワークを通じてサーバに管理されている組込み機器の複数のプログラムを、依存関係を解決し動的に更新する機能。

12

データのダウンロード
依存関係の管理自己診断

2014 年 10 月版

モデルカタログ：製品編

製品編のモデルカタログです。

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

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

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

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

サーマルヘッド
インクを通すところだけに熱をかけ、版マスターに孔をあける

ドラム

版マスター

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

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

版
用紙

プレス
ローラ

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

P001 孔版印刷機

14

2014 年 10 月版
今ある版で印刷だけを要求

原稿 A の複製を要求

原稿 B の複製を要求

利用者の要求

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

版Aを
除去

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

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

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

両面→片面

原稿 1

原稿 1
表

版1

用紙 1

版1

用紙 N

用紙 1

用紙
N

集約
原稿 1

原稿 1
裏

版1

版2

用紙
N+1

15

原稿 2

用紙
2N

用紙 1
用紙 N

要求仕様

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

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

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

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

UC04:版を除去する

管理者

P001 孔版印刷機

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

2014 年 10 月版

モデル一覧
着目点

コンセプト

ポイント

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

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

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

状態に着目したモデル

なし

メタファを使っ
たモデル

なし

17

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

モデル一覧

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

ローラ

位置

セン サー

P001 孔版印刷機

18

プ レ スロ ー ラー

2014 年 10 月版

分析モデル
孔版印刷ドメイン
孔版印刷ドメインは、システム全体の最上位のドメインであり、利用者からの要求を実現することが使命です。
利用者からの要求の特徴は、要求仕様でまとめたように、原稿から複製を作成する場合と、すでにある版を使って印刷する場合の 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

版
管理番号
使用回数

19

元
1

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

1
印刷物

作成物
0..1

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

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

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

P002 電子オルゴール
はじめに
電子オルゴールは、携帯音楽プレーヤーのような音楽再生装置で、曲やプレイリスト2を再生できます。
オルゴールや音楽再生装置という身近なものを考えていますので、分かりやすいモデルです。
本モデルでは、曲やプレイリスト、再生パラメータをリストにまとめて管理する方式を表現しています。
これは、データをグルーピングして管理する場合の参考になります。また、ユーザーインターフェースに関しては、設計モデルにデザインパターンを適用したモデルを提示しています。こちらは、小型の画面を持つ機器のユーザーインターフェースの設計に用いることができます。

要求仕様
機械式オルゴールは、シリンダやディスク上のピンが、オルゴールの櫛の歯を弾くことによって音楽を奏でます。本カタログで扱う電子オルゴールは、機械式オルゴールの発音操作をソフトウェア制御します。
これにより、(通常の機械式オルゴールは 1 曲の演奏を行いますが)、複数の曲の再生に対応できるオルゴー
ルとなります。
曲を再生する機器には、携帯音楽プレーヤーがあります。電子オルゴールは、携帯音楽プレーヤーと同様のプレイリストにより複数の曲を再生します。プレイリストについて、携帯音楽プレーヤーとほぼ同様です。反面、携帯音楽プレーヤーは、テンポを変更できませんが(再生速度を変更すると可能ですが、音程も変わってしまいます)、電子オルゴールは、音程を変えずに、テンポを変更できます。これは、オルゴールが楽譜としてシリンダを持っており、それを元に演奏することをソフトウェアで再現しているためです。

機械式オルゴールの解説

シリンダ

櫛

ベッドプレート2

プレイリストは、曲や動画を再生する順番に並べたリスト。携帯音楽プレーヤーや PC の音楽再生ソフトウェアでは、プレイリス
トを使用して、好みの順番で曲や動画を再生することができる。

P002 電子オルゴール

202014 年 10 月版

シリンダ

オルゴールにとっての「楽譜」。櫛を弾くためのピンが打ち込まれている。シリンダが回転することにより櫛を弾くことで発音する。

櫛(くし)

発音するための金属板(「歯」)が並んでいる。歯の長さにより音程が決まる。

ベッドプレート

鋳物でできた土台。櫛が弾かれた際の音をボックスに伝える。

ボックス

通常は木製の箱。ベッドプレートの振動を反響させる共鳴装置として機能する。

ハードウェア仕様
1. 小型の木製の箱である（発音装置との組み合わせでオルゴールを再現できるもの）
2. 駆動
 バッテリで駆動すること
 AC アダプタ接続により駆動すること
3. インターフェース
 小型液晶ディスプレイ
 上/下/左/右/中央の 5 個のキー
 SD-Card
4. 音源方式
 ウェーブテーブル SW シンセ

電子オルゴールの基本的な機能
1. プレイリストに曲を登録し、プレイリスト内の曲を再生していくことができます。
2. 調律3、リヴァーブ4、音量の設定を「曲調」として登録しておくことができます。

3

調律は、音階(ドレミファソラシド)の音の高さ(周波数)の決め方。現在、1 オクターブを 12 等分した 12 平均律が一般的であるが、純正律、ミーントーンなど、色々な方式が存在する。
4
リヴァーブは、音の響き方。英語 reverberation(残響)より。同じ楽器の音でも、コンサートホールの響きや小さな部屋の響きなど、環境により音が異なる。この場合は、演算処理によりコンサートホールや小さな部屋の残響を再現することを示す。

21

要求仕様

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

ユースケースuc 要求
電子オルゴール
再生

プレイ リスト編集

曲管理
ユーザ
曲調編集

その他

uc 再生
電子オルゴール
UC01：再生プレイリストを選択する

ユーザ

UC04：再生曲を選択する

UC02：プレイ リ
ストを再生する

UC03：プレイ リ
ストの再生を停止する

UC05：曲を再生する

UC06：曲の再生を停止する

uc プレイ リスト編集
電子オルゴール
UC07：プレイ リストの一覧を見る

ユーザ

P002 電子オルゴール

UC11：プレイ リストの曲の一覧を見る

UC08：プレイ リストを登録する

UC09：プレイ リ
ストを削除する

UC12：プレイ リ
ストに曲を登録する

UC13：プレイ リ
ストから曲を削除する

22

UC10：プレイ リ
ストの名前を変更する

2014 年 10 月版

モデル一覧
モデル名

概要

ポイント

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

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

要求仕様の内容をエンティティ中心に分析し、オル
ゴールの部分と曲を順番に再生する音楽再生装置の2 面から考えました。

状態に着目したモデル

なし

メタファを使っ
たモデル

なし

23

オルゴールや音楽再生装置という身近なものを考えていますので、分かりやすいモデルです。
また、応用例も考えやす
いと思います。

モデル一覧

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

エンティティに着目したモデル
モデリングのコンセプト(1) 電子オルゴールをモデリングするにあたり、機械式オルゴールを以下のようにとらえなおしています。
機械式オルゴール

電子オルゴール

シリンダ：

曲：機械式オルゴールのシリンダを抽象化している。

櫛
ベッドプレートボックス

音源：機械式オルゴールの櫛、ベッドプレート、ボックスに対応している。

シリンダを曲、櫛などを音源ととらえ、曲と音源が協調して、曲を再生します。
1: 再生する():曲:クライアント
3: 曲データを取得する()

2: 再生する():音源

4: 音を出力する()

繰り返して、曲を再生する。

(2) 「電子オルゴール」を一般的な「曲を順番に再生する音楽再生装置」として捉えます。
(2a) プレイリストは曲を順番に再生するので、プレイリストは曲を集約します。
(2b) 一般的に音楽再生装置のメニューはフォルダのような階層があり、プレイリストを選択します(フォルダはフォルダまたはプレイリストを集約します)。電子オルゴールには階層はなく、フォルダはプレイリストを集約します。
(2c) 電子オルゴールのすべての曲を管理するものが必要で、全曲目録とします。
(2d) プレイリストと全曲目録は、曲を集約し、再生する責務を持つことが共通しています。共通部分を再生目録として汎化させます。
以上をまとめた、電子オルゴールの主要なクラスを次に示します。
フォルダ

再生目録

プレイ リスト

曲

全曲目録

音源

P002 電子オルゴール

242014 年 10 月版

分析モデル
前述の電子オルゴールの主要なクラスに、ユースケースの実行に必要なユーザーインターフェース、曲調、曲調マネージャー、外部メディアを追加し、分析モデルを作成しました。また、クラス数が増えたため、ユーザーインターフェース、曲、曲調、デバイスのパッケージに分割しました。

電子オルゴールの全体構造
class 00全体構造
ユーザーイ ンターフェース

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

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

1

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

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

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

曲

曲調「プレイリスト」
フォルダ
1

再生中の
再生目録 0..1
再生目録

フォルダ

曲終了の
通知先
0..1

1..*
全曲
目録 1

0..*
プレイ リスト

曲調マネージャー

全曲目録

全曲目録

1

曲調マネージ ャー

曲

0..1

所属先
1

再生中
の曲

構成員
0..*
{ordered}{bag}

曲 0..*

1 曲調マネー
ジャー

1
0..*

曲データ 0..1
の供給元

曲調

曲調

1

0..*

デバイ ス
曲の供給元

1

外部メディア

曲データ
の使用者

0..1

再生
装置

音源

1

制御
対象
1
制御対象
1

曲パッケージは、曲やプレイリストなど、曲を連続して再生するという音楽再生装置として主要な部分になります。Ordered と bag については後述します。
ユーザーインターフェースパッケージはユーザとのインターフェースを司ります。
曲調パッケージは、本カタログの要求仕様の曲調を実現する部分です。要求仕様により内容が大きく変動する部分です。
デバイスパッケージは、電子オルゴールのデバイスをまとめたものです。

25

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

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

P003 インライン装置「インライン装置」は、工場の生産ラインなどで使用される上流から下流に向かって、製造物や検査品を搬送/処理する装置のことです。どのような機構で搬送するか、どのような加工/検査をするかに関係なく、再利用可能なモデルとして提供しています。また、自動運転や並行処理の待ち合わせといった装置開発でよくみられる課題を扱っています。
このモデル解説書では「インライン装置」と呼ばれる装置を、
1.
2.
3.

前の装置から引き渡された「何か（試料）」を、
なんらか処理して、後ろの装置に引き渡す。

のステップでとらえ、汎用的な要求仕様として、提示しています。

試料
前処理装置から試料を受け取る

インライン装置

試料を処理する

試料
後処理装置に試料を引き渡す

要求仕様
論理ハードウェア仕様※

図中の「XX エリア」は、試料が搬送されるときに、一回一回止まる場所を示す概念。たとえば、搬送ステージ上で試料だけを移動する機構ならば試料が一回一回の搬送される位置のことであり、たとえば、搬送ステージごと試料を移動するコンベアのような機能ならば、コンベアが一回一回の搬送で止まる位置のこと。
論理ブロック

構成要素

説明

操作部

スタートボタン

処理部に対しては処理の開始、搬送部に対しては前処理装置からの試料の受付を開始する。

ストップボタン

処理部に対しては処理の停止、搬送部に対しては前処理装置からの試料の受付を停止する。

P003 インライン装置

26

2014 年 10 月版

処理部

処理ユニット

試料に対する処理を行う。たとえば、加工や検査など。

搬送部

搬送ステージ

試料を搬送する領域全体の部分。

導入検出跨りセンサ「前処理装置から受け取った試料が存在すること」・「前処理装置から受け取り終わった試料を取り損なっていないこと」を確認する。

導入エリア

前処理装置から受け取った試料が一時的に置かれ、位置決めを行う場所。

試料位置決め器

試料を位置決めする機構。

エリア

試料が搬送されるときに、一回一回止まる場所。搬送ス
テージ全体が長い場合は、この普通の「エリア」が複数連続して並ぶ。

処理エリア

搬送ステージの内、試料に対し処理を行う場所のこと。

排出エリア

試料を後処理装置へ排出する場所。

試料排出器

試料を後処理装置へ排出する機構。

排出跨りセンサ

後処理装置に排出し終わった試料が、排出し損なっていないかを確認する。

機能要求

処理開始機能操作部のスタートボタンを押下すると、装置状態が運転モードになり、自動処理を開始します。



処理停止機能操作部のストップボタンを押下すると、自動処理を停止し、装置状態が停止モードになります。



試料搬送機能運転モードのときに、前処理装置から搬送部へ試料が導入されると、連続運転の実動作を開始します。

連続運転の動作仕様

①

②

③

④

⑤

①

前処理装置から引き渡された試料は、試料位置決め器によって、処理エリアから決まった距離になるように位置決めをします。この時、導入検出跨りセンサによって、前処理装置から導入されているかを確認します。

②

位置決めをした所から、一定の間隔で搬送します。この時、導入検出跨りセンサによって、前処理装置から搬送ステージ内に確実に引きこんだかを確認します。

③

処理エリアまで搬送します。処理エリアでは、処理部によって試料を処理します。

④

次の試料を処理エリアに運ぶのと同時に、処理済みの試料を後処理装置に向かって搬送します。

⑤

試料排出器によって試料を後処理装置へ排出後、排出跨りセンサで、引き渡しができているかを確認します。（払い出し部の一例：）ただし、後処理装置が排出を受け付けられない場合は、受け付けられるようになるまで待ってから排出をします。

27

要求仕様

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

以上の①～③と③～⑤の間が何回で搬送されるかは、搬送ステージの長さや試料の長さによって、さまざまなパターンが考えられます。上記の例は、最小限を考えた一例です。

搬送部の各動作と処理部の動作の並行タイミングの要求
インライン装置は、試料の位置決め、試料の処理、試料の排出を並行して行う事が出来ます。
前処理装置

位置決め中

インライン装置

後処理装置

処理中

排出中

試料の搬送は、試料の位置決め、試料の処理、試料の搬出を行っていない場合に行う事が出来ます。
前処理装置

インライン装置

後処理装置

搬送中
上記二つの状態を交互に繰り返すことによってインライン装置の動作を実現します。
試料の搬送

試料の位置決め
試料の処理
試料の排出

このため、試料の搬送が完了を待って試料の位置決め、試料の処理、試料の搬出を実行する必要があります。また、反対に、試料の位置決め、試料の処理、試料の搬出の全ての完了を待って試料の搬送を実行する必要があります。

P003 インライン装置

28

2014 年 10 月版

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

uc 要求
インライン装置

UC01.運転を開始する

ユーザ
UC02.運転を停止する

UC03.試料を導
入する
前処理装置

UC04.試料の処理結果を記録す
る
試料処理結果管理システム

UC05.試料を排
出する
後処理装置

29

要求仕様

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

モデル一覧
モデル名

概要

ポイント

ドメイン構造に着目したモデル

インライン装置の構造を中心に分析し、機能もその構造の要素自身にすべて配置しました。搬送部や処理部を（派生などで）拡張することにより、さまざ
まなインライン装置に再利用できるようにしています。

自動運転／並行処理の待ち合わせといった一般的な課題を扱っています。

P003 インライン装置

30

2014 年 10 月版

ドメイン構造に着目したモデル
モデリングのコンセプト
このモデルは、管理クラスや制御クラスといったクラスを出さずに、要求仕様からのモノの構造のみに着目してモデル化しています。
またモデルを利用する際に、オブジェクト同士の協調に集中してもらうため、（オブジェクト同士の境界線を引いてしまうような）パッケージ分けをしていません。

分析モデル
インライン装置システム全体のクラス構成
class クラス図（枠付き）

操作部
インライン装置
+
+
+

1
+装置

1

1

+装置

1

+搬送部

操作ボタン

+操作部

+スタートボタン1

1 <<ユーザ操作>>+ 押下()+ストップボタン<<Event>>
1 + 押下イベント()

+操作部
1

1

搬送部
搬送ステージ

搬送部
-

操作部

+操作部

+装置

運転開始()
運転停止()
停止完了時処理()

停止予約 = false+ 運転中確認()+ 搬送()+ 搬送停止()- 少し待つ()<<Event>>+ 停止完了イベント()

+
+
1 #
+
+搬送ステージ +
+
+
+
+

+搬送部
1

+搬送ステージ

1

搬送可能か()+導入エリア

1

1

+
+
+
+

+試料位置決め器 1

処理エリア

試料取扱い()
試料受け取り可能確認()
試料受取り開始()
試料受け取り終了(受け取り試料あり)+

試料取扱い()+処理エリア1

1 +導入エリア+導入検出跨りセンサ

試料位置決め器
位置決め()

1 +排出エリア{subsets エリア}

1 +処理エリア{subsets エリア}

+導入エリア 1

+

0..1

1

試料

+エリア内試料++処理ログ++処理対象試料 * {ordered} +

ID

処理ログ
処理済み = false
処理済設定()

1

導入エリア+前処理装置1+現在エリア+搬送ステージ

1 +導入エリア{subsets エリア}
引き渡し開始要求()
引き渡し可能確認()
試料受け取り可能設定()
試料受け取り不可設定()
引き渡し終了通知()

試料取扱い()+*{ordered} +1

1+搬送ステージ

前処理装置
+
+
+
+
+

エリア

+搬送ステージ +エリア

試料取扱い()
搬送()
単搬送動作実行()搬送ステージ上に試料あり確認()
処理エリアに処理前の試料あり確認()
排出待ち確認()
搬送動作ロック()
搬送動作アンロック()
試料受け取り可能確認()

+

+
+
+
+

後処理装置

排出エリア
+後処理装置 +
+
1 +
+

排出待ち

1

排出待ち()
試料取扱い()
搬送可能か()+排出エリア+排出エリア1

引き渡し開始()試料受け取り確認()
引き渡し終了(引き渡し試料あり)引き渡し可能状態通知(可不可)+排出エリｱ1

1 +試料排出器

1

検出センサ+排出跨りセンサ

検出状態取得()

1

試料排出器
+

排出()

処理部
+処理部

1

1

処理部

+処理部
+

処理実行()
1+処理部+処理ユニット1

処理ユニット+

処理実行()

点線の枠は、論理ハードウェア仕様の論理ブロックの範囲を示しています。
搬送ステージはエリアへの関連を持たせました。導入エリア、処理エリア、排出エリアはエリアから派生しているため、搬送ステージはこれら３種類のエリアを統一的に扱うことができます。しかし、搬送ステージからそれぞれ個別の特性も扱う必要があります。そこで、搬送ステージには、導入エリア、処理エリア、排出エリアへの関連も持たせました。また、これらの関連に{subsets エリア}を指定することによって、関連先の要素がエリアへの関連先要素に含まれていることを明確にしています。

31

ドメイン構造に着目したモデル

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

連続運転の相互作用
sd シーケンス図（自動運転中）:インライン装置:搬送部:搬送ステージ

エリア[1] :エリア

エリア[2] :エリア

エリア[3] :エリア

運転開始()
例として、３つのエリアを示している。エリアには導入、処理、排出エリアも含まれる。

搬送()
停止予約= :false

このループとは非同期的に搬送部へ停止要求がくる。停止要求を受けると停止予約が true になりループを抜ける。

loop[停止予約 = false]

試料あり= 搬送ステージ上に試料あり確認()

alt 搬送ステージ上の試料有無[試料あり == true]
試料取扱い()

搬送ステージに含まれる全てのエリアに対して、試料取扱いの操作を行う。

par[エリア1]

試料取扱い():boolean[エリア2]

試料取扱い():boolean[エリア3]
試料取扱い():boolean

排出待ち= 排出待ち確認() ref シーケンス図（排出待ち）

全てのエリアから試料取扱い完了通知を受け取ってから戻る。

alt 排出待ち確認の結果[排出待ち == true]
すこし待つ()

後処理装置に排出できずに待っている場合、時間をおいて、再度試料取扱いする。

[排出待ち == false]
搬送()
単搬送動作実行()

各エリアの試料を次のエリアへ移動する。
先頭のエリアの試料はなくなる。

搬送結果= :boolean
搬送に何らかのトラブルが発生した場合
は、Loopを抜ける。

break[搬送結果 == false][試料あり == false]
すこし待つ()

停止完了イベント()<<event>>

P003 インライン装置

32

2014 年 10 月版

P004 エアコン
要求仕様
エアコン(エアー・コンディショナー)は、室内の温度(室温)と湿度を調整する空調装置です。
エアコンの基本機能として、暖房機能、冷房機能、除湿機能があります。空気清浄機能や内部洗浄機能などの付加価値機能はありません。
エアコンの利用者は、寒いと感じたときにはエアコンの暖房機能を利用し、暑いと感じたときには冷房機能または除湿機能を利用します。
利用者は、快適と思う温度をエアコンに設定します。
エアコンの暖房運転では、室温が設定温度より低ければ暖房運転を続け、設定温度以上になったら暖房
運転を弱めて室温が設定温度を保つように暖房運転を続けます。
エアコンの冷房運転では、室温が設定温度よりも高ければ冷房運転を続け、設定温度以下になったら冷房運転を弱めて室温が設定温度を保つように冷房運転を続けます。
冷房による冷たい空気が苦手な人は除湿運転を選ぶと、エアコンは室温を保ったまま快適な湿度になるまで除湿を続けます。快適な湿度は 50%～60%といわれていますが、温度によって快適に感じる湿度が異なるため、目標湿度は別途検討することにします。
暑い日に帰宅したときなどに、風量を強くして急激に室温を下げることもできます。また、冷房の風を直接体に当てた
いときや避けたいときなどに、風向を調整することもできます。
就寝時や外出時などの切り忘れ防止のため、オフタイマー
機能もあります。

エアコン操作方法
エアコン操作は右図に示すリモコンで行います。
各操作状況はリモコン上部の画面に表示されます。

設定温度:

運転:
冷房
オフタイマー:なし

２８.0℃

風向: 自動風量: 自動

オフタイマー

風量

暖房

エアコンが室温を調整する仕組み
エアコンは、熱媒体を室内と室外との間で循環させ、熱媒体を圧縮して温度を上げたり蒸発させて温度を下げたりし、その熱媒体を室内と室外で空気と熱交換することにより室内の温度を調整しています。

冷房

運転
停止

風向

▲
除湿

温度
設定
▼

エアコンで冷房できる仕組みを下図に示します。

33

要求仕様

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

室内⑤ 熱媒体を減圧すると温度が下がる⑥ 室内温度が
徐々に
下がる

屋外
15℃

圧縮
30℃

15℃

室温
(最初 30℃)
30℃④ 外気温 30℃
(外は広い
ので温度
変化微小)

熱媒体は熱を運ぶトラックのようなもの③ 熱媒体を
屋外で
冷却する
圧縮
60℃
② 熱媒体を
加圧する
と温度が
上がる

① 室内の熱が熱媒体に移るハードウェア構成
一般的なエアコンのハードウェアは、室内機、室外機、それと、温度調整に利用する熱媒体を室内機と室外機の間で循環させるための配管で構成されます。
また、各所に異常を検知する機構が装備されています。
ハードウェアの大まかな構成図を以下に示します。リモコン、ブザー、LED などの UI 部品は省いてモデリングしています。

P004 エアコン

34

2014 年 10 月版

室外機

室内機
室内温度センサー
制御装置

室内湿度センサー

室外温度センサー

リモコン受信部

コンプレッサー

電源

四方弁

熱交換器

蒸発器

熱交換器

冷媒(熱媒体)

室外ファン

送風ファン
フラップ

冷房運転
冷房運転時の動作原理簡略図を以下に示します。
冷たい熱媒体(気体)

沸点以下の熱媒体 (液体)
熱交換器

熱交換器
蒸発器
( 膨張弁)

室内

室外
四方弁

室温の熱媒体(気体)

熱い熱媒体(気体)

コンプレッサー35

要求仕様

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

ユースケース
ユースケースには、アクターがエアコンに求める価値を記述します。システム設計者はシステム内部からの観点でどのように実現するかを記述しがちなのですが、アクターが何を望んでいるのか、何を実現するのかという観点で記述します。
アクターとして、エアコンの利用者だけがいます。
アクターがしたいことは、基本的にリモコンで操作できることと一緒です。
設定温度の上げ下げは温度設定の変更としてまとめます。
本カタログモデルで扱うエアコンのユースケース図を以下に示します。
uc ユースケース
エアコン

UC01:暖房運転を開始する

UC02:冷房運転を開始する

UC03:除湿運転を開始する

UC04:設定温度を上げる

UC05:設定温度を下げる

UC06:風量を変更する
利用者
UC07:風向を変更
する

UC08:オフタイ マー
を設定する

UC09:運転を停止する

P004 エアコン

36

2014 年 10 月版

モデル一覧
着目点

コンセプト

ポイント

熱交換の原理に着目したモデル

熱媒体が室内と室外の間を行き来して熱を交換することで室内の温度や湿度を調整していることに着目し、空気と熱媒体がどのような役割を担い、熱がどのように交換されるのかを分析したモデルです。デ
バイスを切り離して考えることで、デバイスに左右されずに末長く使えるモデルです。

動作原理を抽象化してモデリングすることで、実世界の環境や物質や現象をモデルとして捉えることができるモデルです。

ソフトウェアで制御する対象に着目したモデル

暖房・冷房・除湿の主要 3 機能とそれを実現するためのデバイスとの関係に着目し、各機能を担う制御部分と、利用するデバイスとの関係を中心にモデルで表現しました。

直感的でイメージしやすい、モデリングにあまり馴染みのない方にも理解しやすいモデルです。

37

モデル一覧

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

熱交換の原理に着目したモデル
モデリングのコンセプト
エアコンの動作原理を抽象化し、エアコンの動作に欠かせない熱交換を中心に考え、空気と熱媒体の関係を捉えながら、熱交換を実現するために必要なデバイスを付け加えていきます。

概念モデル
class 概念クラス図（全体）
ユーザインタフェース
リモ コン

1

1

1

1

1

1

温湿度制御
運転制御

1
オフタイ マー設定時間

1
運転モ ード

停止する
1

1

温度設定

気流設定

運転状態

設定温度

設定風量
設定風向

1

1

1

選択する

参照する

参照する

0..1

0..1

0..1

暖房

冷房

温湿度制御
動作状態
制御状態

除湿

0..1

0..1

制御する

監視する

1

熱交換

冷媒
圧力
状態

1
空気

湿度
風量
風向
飽和水蒸気量

水蒸気
含む

熱媒体
温度

熱交換する

38

熱

交換元
1
持つ
1

P004 エアコン

1

1

交換先
1..2

量

量
1

2014 年 10 月版

分析モデル
熱交換のクラス構成
class クラス図（熱交換）
熱交換先
1..2
熱媒体
温度

熱交換する
熱交換元
1

熱交換する(相手)

冷媒<<enumeration>>
空間

空気

圧力
状態

湿度
空間

室温を上げる(温度調整量)
室温を下げる(温度調整量)

温度を計る()
湿度を計る()
風量を設定する(風量)風向を設定する(風向)

室内
室外

冷房運転時の熱交換相互作用
sd コミュニケーション図（熱交換、冷房運転）

温湿度制御
1: 室温を下げる(制御量)
室内 :空気5: 熱交換する(熱媒体):冷媒

5.2: 熱交換完了()

3: 熱交換する(熱媒体)

室外 :空気3.2: 熱交換完了()

4: 冷媒を減圧する(減圧率)2: 冷媒を加圧する(加圧率)4.1: 減圧完了()

2.1: 加圧完了()

5.1: デバイス.室内ファンを回す(回転数)3.1: デバイス.室外ファンを回す(回転数)

デバイ ス

39

熱交換の原理に着目したモデル

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

ソフトウェアで制御する対象に着目したモデル
モデリングのコンセプト
暖房・冷房・除湿の主要 3 機能とそれを実現するためのデバイスとの関係に着目し、各機能を担う制御部分と、利用するデバイスとの関係を中心にモデルで表現しました。

分析モデル
コンセプトに従い、物理デバイスとそれを制御する制御クラスとの関連でモデルを構成します。

クラス構成
class 分析モデル(全体)
オフタイ マー<<enumeration>>
運転状態

運転モード

設定時間

運転状態

設定する(時間)発動する()<<enumeration>>
制御状態

停止中
暖房中
冷房中
除湿中

オフタイマー 停止先 除湿()
暖房()
停止()
1
1 冷房()<<enumeration>>
風量

停止中
制御中

<<enumeration>>
風向

自動
弱
中
強

自動
スイング
固定

運転管理 1 運転管理 1 運転管理 1
気流設定

温湿度設定
目標温度
目標値 1 目標湿度 = 60 {readOnly}
設定温度を取得する()
設定温度を設定する(温度)暖房
暖房 1

温度調整する()
開始する()
停止する()

冷房 1

除湿

目標湿度は固定値(60%)

冷媒順番方向 1

参 3
照
元
室内
湿度 1

温度センサー

湿度センサー

現在温度

現在湿度

取得する()

取得する()

冷媒減圧 1

四方弁

1

3

参 3
制 3 制 3 制 3 参 3
照
御
御
御
照
元
元
元
元
元
室内
室外
温度 1 温度 1

温度調整する()
開始する()
停止する()

気流種別
制御状態

調節する

温度調整する()
開始する()
停止する()

湿度差

P004 エアコン

気流制御

温度差
制御状態

温度調整する()
開始する()
停止する()

暖房
冷房
除湿

利用者 3

設定情報 1 風向を取得する()
風向を設定する(風向)風量を取得する()
風量を設定する(風量)
利用者 1

温湿度制御

冷房

<<enumeration>>
循環方向

除湿 1

設定風向
設定風量

蒸発器

循環方向

開口度

設定する(循環方向)設定する(開口度)

冷媒加圧

1

コンプレッサー圧力開始する()
調節する(温度差)停止する()

調節元 1

調節元 1

室内ファン 1

風向

{XOR}

ファン

制御元 室外ファン 回転数開始する()
止める()
1 設定する(回転数)設定する(圧力) 1
停止する()
動かす()

40

1

フラップ
角度
開く()
設定する(角度)閉じる()

2014 年 10 月版

運転モードのステートマシン
stm ステートマシン図(運転モード)開始

停止中

冷房ボタン押下/冷房()

暖房ボタン押下/暖房()

停止ボタン押下/停止()
除湿ボタン押下/除湿()

冷房中

停止ボタン押下/停止()

entry / 冷房.開始する()
exit / 冷房.停止する()

暖房ボタン押下/暖房()

冷房ボタン押下/冷房()

冷房ボタン押下/冷房()

除湿ボタン押下/除湿()

除湿ボタン押下/除湿()

暖房中entry / 暖房.開始する()
exit / 暖房.停止する()

停止ボタン押下/停止()

除湿中
entry / 除湿.開始する()
exit / 除湿.停止する()

暖房ボタン押下/暖房()

ユースケース 01:暖房運転時のシーケンス図
sd UC01:暖房運転開始:運転モード:暖房:温度設定:コンプレッサー:四方弁

室外 :ファン

:気流制御

室内 :ファン

:フラップ

利用者
暖房()
開始する()
開始する()
開く()
動かす()

設定する(暖房)開始する()
動かす()
温度調整する()ref
暖房温度制御41

ソフトウェアで制御する対象に着目したモデル

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

P005 交通 IC カードチャージ機
はじめに
近年の組み込み機器は、機能の増大と複雑化、ネットワークを介した他システムとの連携などにより、デバイスを制御する部分よりも、むしろアプリケーション部分の方が開発の大半を占めます。そのような機器の開発では、システムをいかにすっきりと部分に分けるかが、システム全体の品質に大きく影響します。
今回のモデリングにあたっては、BCE パターンと呼ばれる手法を用いてアーキテクチャを構築したり、システム全体の状態遷移を捉えてその状態毎に処理クラスを割り当てる方法を適用しました。
組み込み機器の個々のデバイスコントロールではなく、装置としてのアプリケーション全体を設計する
ような場合には、有用な考え方だと思いますので、是非参考にしてください。

要求仕様
交通 IC カードチャージ機とは、主に鉄道の駅の乗車券用の自動券売機の横や改札の近くなどに設置されている、鉄道の乗車などに利用できる IC カードにお金をチャージする(入れる)ための装置です。
一般的には、IC カードを読み書きする装置および現金を挿入する装置(つり札を排出する装置を兼ねることが多い)と、ボタンや表示パネル・スピーカーなど利用者とのやりとりを行うための装置から構成されます。
最近では乗車券等の自動券売機でも、IC カードにお金をチャージする機能が利用できるものが増えていますが、今回対象とする交通 IC カードチャージ機はチャージ専用の装置で、乗車券を購入することはできません。
但し、モデリングにあたっては、自動券売機等の他の装置への転用(または借用)がしやすい構成にすることを考慮しています。

IC カードチャージ機の主な機能
IC カードチャージ機は、装置の製造メーカーや鉄道会社によって機能が異なりますが、ほとんどの場合には、以下の機能を備えています。
IC カードに現金でお金をチャージする機能

領収書を発行する機能

IC カードの残高や利用履歴を確認する機能



問題が発生した場合などに、係員に連絡するための機能

これらの機能を実現するために、IC カードチャージ機を管理するシステムとの通信など、外部との通信を行う機能も必須です。
その他、現金を扱う装置である関係上、現金の盗難などの不正な行為へ対処するための機能も必要です。

今回の IC カードチャージ機
今回モデルの題材とする IC カードチャージ機では、上記のような一般的な機能に加えて、次の機能を搭載しています。
IC カードにクレジットカードでお金をチャージする機能

P005 交通 IC カードチャージ機

42

2014 年 10 月版

IC カードの利用履歴をレシートに印刷する機能



また、IC カードチャージ機を管理(メンテナンス)するための機能として、以下のような機能を搭載しています。
利用レポート(装置が利用された履歴・ログ)を印刷する機能

印刷機能が正常に動作することを確認するための、テストプリントを実行する機能



問題が発生した場合などに、使用不可にする機能

今回のモデルの題材となる IC カードチャージ機の外見を以下の図に示します。

スピーカー

マイク

ICカードチャージ機

よびだし
とりけし

案内表示

1000

2000

チャージ金額
3000
5000

ICカード挿入口

クレジットカード
10000
11
44
77
**

履歴表示

領収書/履歴

22
55
88
00

33
66
99
##

紙幣・おつり
発行

閉

開
かぎ

43

要求仕様

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

ユースケース
今回題材とする IC カードチャージ機のユースケースを示します。
u c 交通IC カードチャージ 機

交通ICカードチャージ機【UC1-2】クレジ ット
カ ードでチャージ する【UC1-1】現金でチ
ャージ する【UC1】チャージ する <<extend>>【UC2】領収書を発行する<<include>>【UC3】ICカ ードの残高を照会する

ユーザー

ICカ ードシ ステム<<include>>【UC4】ICカ ードの【UC5】ICカ ードの利用履歴を表示す利用履歴を印刷す<<extend>>るる

クレジ ットシ ステム【UC6】係員を呼び出す【UC7-1】使用不可にする

係員呼び出し・通話
シ ステム【UC7】使用可否を設定する【UC7-2】使用可能
にする

メンテナー

【UC8】利用レポート
を管理する【UC8-1】利用レポートを印刷する【UC8-2】利用レポートをクリア する【UC9】テストプリ
ントをする<<mitigate>>

お金を盗む

警備シ ステム泥棒

P005 交通 IC カードチャージ機【UC10】警報を鳴らす44

2014 年 10 月版

システム全体の状態遷移
ユースケース図とそれぞれのユースケース記述を総合して、システム全体の振る舞いを状態図としてまとめたものが、以下の図です。
(以下の図はサマリーになっています。モデルファイルを参照していただくと、詳細な状態遷移図を見ることができます。)
st m シ ステ ム状態

機構的に、鍵が開いた状態でないと電源ON/OFFできない

電源ON

電源OFF
ユーザー利用不可
鍵を開ける

メンテ ナンス中
entry / カードロック解除
entry / 取り込み中の紙幣・クレジットカードの排出
鍵を閉める ["使用不可"以外選択]

鍵を開ける

使用停止表示中
entry / カードロック

鍵を閉める ["
使用不可"選
択]
警報機検知

異常検知中
do / 警備システムに異常を通知する
do / 警報を鳴らす
鍵を開ける

警報機検知
ユーザー利用可チェック完了 [サービス不可]

待機中
entry / おつり用の紙幣残量、印紙残量等のチェック
ICカード挿入
取り込み完了

ユーザー利用処理中
entry / カードロック
exit / カードロック解除
処理完了

処理続行不可(
エラー)
取り出し中

キャンセル

取り出し完了
タイムアウト(取り忘れ検知)
後処理中
entry / クレジットカード・紙幣をシステム内に取り込む

45

要求仕様

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

モデル一覧
着目点

概要

ポイント

BCE パターンを用いたモデル交通 IC カードチャージ機のアプリケーション部分
を、B(Boundary:システムの境界)
C(Control:システムが行う処理)、
E(Entity:システムが扱うもの/こと)、の性質の違いに着目してモジュール分割しています。

「これがチャージ機である」という知識の凝集度を極力高め、ソフトのほとんどの部分がチャージ機能付の券売機等、他の機器に転用できる(また借用できる)構造を狙っています。

P005 交通 IC カードチャージ機46

2014 年 10 月版

BCE パターンを用いたモデル
分析モデル
モデリングのコンセプト
分析モデルの作成にあたっては、ドメイン（システムが扱う問題領域）に対する理解を詳細にし、整理し、語彙を揃えることを目的に、交通 IC カードチャージ機が扱うデータを洗い出しました(BCE の E に相当)。
データを洗い出すことだけに集中した理由は、分析のこの段階では「What(何をつくるのか)」に思考と議論を集中させ、「How(実現手段)」の検討に入ることを防止する意味もあります。機能の実現手段については、後の PIM 設計モデル作成時に検討します。
分析モデル作成作業の結果として、交通 IC カードチャージ機が扱うデータは、


情報が付随するモノや情報のライフタイムの違いによっていくつかのグループに分けられる。



扱うデータの種類も量もそれほど多くない。

ということが分かりました。その結果を、下の図に示します。

クラス図
IC カードチャージ機が扱うデータ
c lass 概念モ デル
ユーザーによるIC カードチャージ 機の一回の利用毎にある情報

Ｉ Ｃ カードのサービス毎にある情報

現金によるチャージ

チャージ

サービス仕様チャージ金額
領収書発行有無

1回のチャージの上限金額
カードの上限金額<<enumeration>>
ユーザー利用結果
装置毎にある情報

ユーザー利用ジ ョブ

クレジ ッ トカードによる
チャージ

残高照会

正常終了
ICカードエラー
おつり取り忘れ・・・

利用レポート

おつり金額
投入金額

1*
1

利用履歴

*

*

日時
1*

0..1

利用履歴照会
利用履歴印刷有無*1
チャージ 機情報

1

駅名
設置場所

Ｉ Ｃ カード毎にある情報

クレジ ッ トカード毎にある情報
1

1<<enumera...
IC カード状態
有効
紛失中
・・・

IC カード情報
残高1

IC カード1*<<enumeration>>
クレジ ッ トカード状態

1

ICカード番号

有効
無効

クレジ ッ トカード情報
1 *クレジ ッ トカード
クレジットカード番号
11

1
ICカードシステムから取得できる情報*

ICカードから読み取れる情報

ICカードシステムから取得できる情報

クレジットカードから読み取れる情報

IC カード利用履歴
残高
日時チャージ 履歴
*

支払い履歴
着駅
発駅

精算履歴
駅

47

BCE パターンを用いたモデル

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

PIM 設計モデル
モデリングのコンセプト
交通 IC カードチャージ機のアプリケーション全体を、
Boundary (システムと外部との境界)

Control (システムで行う処理)Entity (システムが扱うもの/こと)の性質の違いに着目してモジュール分割しています。これにより、汎用性の高いソフトウェア部品の集合として全体の機能を実現することを狙っています。
また、Control の部分は、システム全体の状態遷移に着目し、システムの状態に応じて処理を行うクラスを切り替えるアーキテクチャーになっています。

パッケージ構成
交通ＩＣカードチャージ機のソフトウェアの、トップレベルのパッケージ構成を以下に示します。各パ
ッケージの性質の理解を助けるために、それぞれにステレオタイプをつけています。Boundary, Control,
Entity の他に、便利機能を実現するモジュールやクラスには、Utility というステレオタイプをつけています。

トップのパッケージ構成
c lass ドメイン構成<<control>>ア プリ ケーシ ョン<<entity>>
装置<<control>>
機能コントローラ<<boundary>>
外部通信<<utility>>
UI<<entity>>
クレジ ッ ト情報<<boundary>>
論理デバイス

P005 交通 IC カードチャージ機

48

2014 年 10 月版

モデルカタログ：機能編

機能編のモデルカタログです。

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

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

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

F001 認証50

2014 年 10 月版

ユースケース51

要求仕様

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

モデル一覧
着目点

コンセプト

ポイント

機能に着目したモデル

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

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

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

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

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

状態に着目したモデル

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

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

メタファを使ったモデル

なし

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

F001 認証52

2014 年 10 月版

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

分析モデル
静的モデル
クラス構成その１
cla s s 分析１

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

誰が許可で誰が不許可か

承認

認証
+

+

ユーザを認証する()+

監視処理を実行する()

1
登録サービス*1

アカウン トサー ビ ス

名前カギ

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

1

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

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

サービスを承
認している

1 -

内容

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

登録課計
1
*

サー ビ ス利用量ルー ル

1++

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

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

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

最上段には AAA の３要素、認証、承認、監視を配置しました。
認証が扱う情報は、ユーザを識別するための情報です。認証が扱うユーザを識別する情報をアカウントとし、その下に配置しました。
53

機能に着目したモデル

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

承認が扱う情報は、サービスです。承認が扱うサービスを、その下に配置しました。
監視が扱う情報は、サービス利用（サービス利用後情報）です。

クラス構成その 2
クラス構成その１をもとに、さらにクラスを抽出します。
cla s s 分 析 ２

認証
+

承認

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

登録アカウント+

監視処理を実行する() : 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 モデルの検討を通してクラス図は上記のように変化しました。以下は追加された最下段のクラスの責務と説明となります。
認証証明書：ログインアカウントと非ログインアカウントを区別するためにログイン時に生成されます。
承認証明書：サービス実行前にサービスの実行権が監視からも認められているか確認するクラスです。
例えば監視条件を満たさない場合（課金不足など）、サービスの実行権を失う状況を実現します。
サービス利用量：監視の使用記録などの実データとなります。

F001 認証54

2014 年 10 月版

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

分析モデル
静的モデル
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..*

-

サービス利用状況

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

55

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

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

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

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

F001 認証56

2014 年 10 月版

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

分析モデル
静的モデル
c la s s 分 析 モ デ ル

ユーザ

認証
-

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

認証済みかどうか
*

1

-

権限
+所有権限

ユーザ名
パスワード

1

1

1

-

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

1

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

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

1

-

サービス名
利用量

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

*
承認

-

1

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

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

利用する

サー ビ ス

+サービス

-

サービス名

0..1

1

更新する

具象サー ビ ス

ユーザとの認証に絡む振舞いを担うクラスとして「認証」を設けます。
ユーザ毎の情報を保持するクラスとして「アカウント」を設けます。「アカウント」には、認証に必要な情報「権限」と、そのアカウントが過去にサービスを利用した記録である「サービス利用量」を関連付けます。
ユーザが認証されたときに利用出来るサービスは複数あるため、サービス毎に承認が必要と考え、サービス毎の承認ずみかどうかを表すために「承認」を設けます。
57

状態に着目したモデル

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

ユーザのサービス利用量を監視・記録するために「サービス」を設けます。各々のサービス固有処理は、「サービス」から派生した「具象サービス」が担うものとします。
ユーザによるサービス利用を監視した結果をユーザ毎に分けて記録するために、「サービス」からも、「アカウント」に関連づけた「サービス利用量」に関連を持たせます。

動的モデル
状態遷移
s t m 状態遷移
認証済
[サービスA]サー ビ ス未利用サービスを利用する [承認NG]
未認証

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

サービス利用を終了する

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

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

サービス利用を終了する

サー ビ ス利用中

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

F001 認証582014 年 10 月版

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

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

59

要求仕様

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

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

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

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

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

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

F002 自己診断

60<<include>>2014 年 10 月版

モデル一覧
モデル名

概要

ポイント

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

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

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

状態に着目したモデル

なし

メタファを使ったモデル

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

61

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

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

モデル一覧

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

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

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

A 診断

診断対象

診断項目

診断結果

診断項目

診断結果

診断項目

診断結果

診断項目

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

○○診断

×× 診断

A 診断

A 診断

B 診断

C 診断
D1 診断

B 診断
並行に診断

D2 診断

順番に診断
E 診断

F002 自己診断

C 診断

62

2014 年 10 月版

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

63

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

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

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

診断って何だろう？

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

診断する目的は何だろう？

問題箇所や予防箇所がないかを診断することで、自己修復あるいは他者に治療・改善・修理依頼するきっかけを知ることができ、診断対象を長生き・長持ちさせるのが目的と考えられます。
3.

身近な診断には何があるだろう？
身近にある診断、点検、検査を探してみました。
 健康診断 車検
 温水洗浄便座
 分電盤
 消防設備点検

4.

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

車

温水洗浄便座

分電盤

消防設備

テスト

消防点検
防災点検

診断名

健康診断
人間ドック

車検
定期点検

テスト

診断時期

年1回
望んだとき

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

半年毎

診断対象

本人、子供、社員

車

電気設備

電気設備

消防設備

診断依頼者

本人、親、会社

所有者

家人

家人

本人、管理会
社、企業

診断場所

病院、健康管理室

車ディーラー、
車検場

設置場所

設置場所

設置場所

診断実施者

医者

メカニック

装置

装置

業者

診断項目

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

ショート

漏電、ショ
ート

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

診断結果

健康ランク、問題部

ブザー？

ブザー？

異常なし

F002 自己診断

問題なし、
64

2014 年 10 月版

位、状態など5.

要修理箇所、予防修理箇所

異常個所

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

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

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

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

前回実施日

診断周期
診断条件

1

確認する

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

健康診断での
「親」

参照者
*

情報

確認する

依頼元 *

健康診
断での
「医者」

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

1

1

結果
確認する

1

診断結果

状態
0..1 所見
結果 *

特定する
診断部位

対象 1

担当者 *
診断する
*
診断者

*

健康診
断での
「子供」

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

*
診断

診断名
* 診断説明
診断

依頼する

1

診断

実施日 1

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

診断項目

診断 1
診断依頼者

1

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

時期 *

診断日時

1

診断対象
診断対象名

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

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

記入する

65

メタファを使ったモデル

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

モデルカタログ：部品編

部品編のモデルカタログです。

2014 年 10 月版

C001 目標制御
はじめに
目標制御は、特定の制御対象・システムに対して式やテーブルといった最適化が施された形態で実装されることが多くあります。このモデルは、目標制御の実装形態はブラックボックスとし、その中身に依存しない形にしました。このモデル（部品編目標制御）では、登場するクラス数が少なく、モデルの全体と対象物が把握しやすいものとなっています。

要求仕様
目標制御システムとは、制御対象の計測値が目標値となるように制御する仕組みで、エアコンの温度調節や自動車の ABS など数多くの製品に組み込まれています。

目標制御システムの基本的な構成と動作
目標制御システムは計測器、操作器、制御器で構成されます。利用者は制御が必要な状況で、目標制御システムに制御の開始を指示します。目標制御システムは、制御中は一定時間周期で制御対象を計測し、それに応じた操作を行うというフィードバックを繰り返します。
制御対象は目標制御システム以外の不特定な要因からも影響をうけますが、その都度出力を修正することで、フィードバックを繰り返すことで、うまく制御を行えるようになっています。
制御が必要かの判断

不特定な要因

目標値の決定目標制御システム
制御対象への影響
（外乱）

操作器

利用者

操作量
指示
制御器

制御対象の計測と操作

計測値

制御対象

計測器

目標制御の実例

67

はじめに

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

目標制御を開始すると、操作器の操作量が制御対象に伝わるまでの時間（むだ時間）を経過した後、計測値は目標値に近づいていきます。このときの目標値に近づくまでの時間が立ち上がり時間です。計測値が目標値に達したときに、勢いがついていたりすると、オーバーシュートが発生します。その後、ハンティン
グをしながら、徐々に計測値は目標値付近で安定するようになります。最終的に安定したときの計測値と目標値の差が定常偏差として残ることになります。
目標制御を実現するアルゴリズムには、ON/OFF 制御、PID 制御、ファジィ制御などの制御方式があり、制御方式によって、目標値への近づき方の特徴に違いがあります。注：これらの制御方式については付録を参照してください。

用語定義
すでにいくつかの用語を使用していますが、あらためて用語の定義を行います。しかし、それだけではイメージがつきにくいと思いますから、具体的な製品（例としてエアコンと ABS）で、何に該当するかもあわせて以下に示します。
用語

用語の意味

エアコンの場合

ABS の場合

目標制御
システム

制御対象を制御するための仕組み

－

－

制御対象

目標制御を行う対象

室温

車輪速度

目標値

目標とする制御対象の値指定された室温の値指定された車輪速度の値

計測値計測された制御対象の値

現在の室温の値

現在の車輪速度の値

外乱

制御対象に加えられる予測できない影響

室外との熱のやり取り、等

路面との摩擦、等制御器

目標制御を司る部品

－

－

入力器

利用者からの指定内容や指示を受け付け
る部品

入力パネル

ブレーキペダル

計測器

制御対象を計測する部品

室温センサ

車輪速度センサ

操作器

何からのアクチュエータを駆動させることで、制御対象を操作する部品

コンプレッサー

油圧サーボ

操作量

操作器がもつ指定可能な量で、結果的に制御対象を操作する量

コンプレッサー出力

油圧サーボ出力制御方式

目標制御を実現する方式、アルゴリズム－－

C001 目標制御

68

2014 年 10 月版

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

uc 目標制御システムのユースケース
目標制御システム

UC01:起動する

UC02:制御項目を設定する
操作器
UC03:目標制御
を開始する
外部システムUC04:目標制御
を終了する

計測器

UC05:停止する

補足：アクター「外部システム」とは、最終的な製品（エアコン等）に含まれるプログラム（目標制御システムを使用するプログラム）を指します。

ユースケース一覧
No.

ユースケース名

概要／備考

UC01

起動する

目標制御システムを起動する。

UC02

制御項目を設定する

目標値やその他の制御項目を変更する。
操作量の計算途中にも制御項目を変更できます。

UC03

目標制御を開始する

制御対象の計測値が目標値となるように制御する。
一定時間周期で制御対象の計測と操作を繰り返すことで、制御対象は徐々に目標値に近づいていく。

UC04

目標制御を終了する

制御対象の操作を止める。

UC05

停止する

目標制御システムを停止する。

69

要求仕様

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

モデル一覧
モデル名

概要

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

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

目標制御システムを構成する部品をエンティティとして捕らえたモデルです。

部品を中心としたシンプ
ルなモデルです。

役割に着目したモデル

目標制御システムについて必要な役割に着目しました。実現方法にとらわれず「現実と目標を一致させる」という目標制御の本質を抽象化したモデルです。

オブジェクト指向を意識したモデルです。

状態に着目したモデル

なし

メタファを使ったモデル

なし

C001 目標制御

ポイント

70

2014 年 10 月版

エンティティに着目したモデル
モデリングのコンセプト
静的な構造として目標制御を行うのに必要な構成部品に着目しました。
また、要求仕様に登場する ON/OFF 制御、PID 制御、ファジィ制御といった複数の制御方式に対応できるように考慮しました。

分析モデル
１．制御対象および計測、操作について
実際の制御対象（エアコンであれば室温で、ABS なら車輪速度です）の今の状態の保持やそれに関する情報を保持するクラスとして「制御対象クラス」を定義しました。制御対象クラスは属性として目標値と計測値を持ちます。なお、「計測値」属性は実際には操作であり、操作を呼ぶと計測器クラスの「計測する」
操作を呼び出します。
制御対象には一般的に、制御対象特有の上限値・下限値、あるいは計測器が持つセンサからくる上限
値・下限値（計測限界）が存在します。そのため、制御対象クラスは範囲クラスを保持する形となります。
２．制御方式について制御器が制御を行う際、どのように制御するか？（制御対象への出力をどうするか？）（例えば計測値
が目標値に近づいてきたから、出力を弱めるといったこと）を考える必要があります。これを制御方式クラスが行います。制御方式には ON/OFF 制御、PID 制御、ファジィ制御といろいろな方法がありますから、制御方式クラスは抽象クラスとなります（ストラテジーパターン）。制御方式クラスが操作量を算出する際には、元となるデータ（制御パラメータ）が必要となりますので、制御方式クラスは制御パラメータクラス
を保持することになります。
制御方式クラスでは操作量算出時に必要な内部データ（PID 制御であれば例えば、偏差（目標値と現在値の差）の時間積分値）が必要ですが、これは実際の制御方式に依存するため、ここでは抽出していません。
制御パラメータが持つデータについても同様で、PID 制御であれば比例係数、積分係数、微分係数の 3 つを持つことになりますが、これも制御方式に依存するものですのでここでは抽出していません。注：PID 制御の詳細については付録を参照してください。
３．定期的な制御について
制御は定期的に行う必要があるためタイマーが必要となりますから、それを定義しました。分析の動的モデルではタイマーが目標制御システムで定義される操作を直接呼び出す形としますが、本来は、一般にタイマーは目標制御部品とは別の部品であり、タイマーが目標制御システムで定義している操作を直接呼び出すことはできません。これについては PIM で検討します。
４．その他
制御対象を実際に制御する場合、その良し悪し、具体的には立ち上がり時間、オーバーシュート量、ハンティング量、定常偏差の量などを、考える必要があります。しかし、これについては制御方式クラスのサブクラスが考えることであるため、クラス構成を抽出する際には考慮対象外としました。

71

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

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

静的モデル
目標制御システムのクラス構造
class 目標制御の静的モ デル
操作器

1

制御器

操作器

1

状態

操作する(操作量) :void

起動する() :void
制御項目を設定する() :void
開始する() :void1
1サイクル処理を行う() :void
終了する() :void
停止する() :void
1
1
1 タイマー

制御対象
1

制御対象
1

1

1
状態：
制御中、
非制御中

1 制御範囲
範囲

タイ マー

上限値
下限値

周期
1 制御方式

計測器

目標値
/計測値

定期実行する() :void

制御方式

パラメータ

操作量を算出する(目標値, 計測値) :操作量1

制御パラメータ

0..1

計測器
計測する() :計測値

保持するデータはサブクラス
でのみ出てきます。
PID制御であれば、比例係
数、微分係数、積分係数です。
※PIMのクラス図では記載していますので、イメージがつかない場合はPIMを見てくだ
さい。

動的モデル
「制御中」の相互作用
sd 制御中
:タイマー

:制御器

:制御方式

:制御パラメータ

:制御対象

:計測器

操作器

1サイクル処理を行う()

opt 制御実行判断[制御実行中の場合]

目標値を取得する()
計測値を取得する()計測する()

操作量を算出する(目標値, 計測値)
制御パラメータを取得する()

実際の操作名はサブクラスによります。
例えば、PID制御であれば、「比例係数を取得する」などになります。

PID制御であれば、ここで偏差（計測値と目標値との差）を計算し、それを元に操作量を算出します
操作する(操作量)

C001 目標制御

72

2014 年 10 月版

役割に着目したモデル
モデリングのコンセプト
目標制御の理想と現実を近づける機能に着目しモデリングしました。
目標制御の目的である「対象の現実を理想に近づける」という点をアーキテクチャの中心に据え、それぞれの役割を擬人化したモデルです。このようなモデリングの考え方もあるというサンプルとして、分析モ
デルのみ提示します。

分析モデル
１．制御対象および計測、操作について
実際の制御対象（例えばエアコンにおける室温、ABS における車体速度）を表すクラスとして、「対象」クラスを設けました。「対象」クラスには「理想」と「現実」２つのロールがあります。「理想」のロールは目標とする制御対象の値を保持し、「現実」のロールは計測された制御対象の値を保持します。
「対象」クラスは「更新させる人」クラスによって定期的にその内容を更新されます。「現実」のロー
ルには制御対象の計測（更新）時刻が必要なため属性として持ち、「理想」のロール側には必要ないため、属性に多重度を示しています。
また、目標制御の入力数と出力数はそれぞれ１つずつのモデルです。
２．制御方式について制御を行う際、どのように制御するか（例えば計測値が目標値に近づいてきたら、出力を弱めること）
を考える必要があります。これを制御アルゴリズムクラスが行います。
制御アルゴリズムクラスの制御方式には ON/OFF 制御、PID 制御、ファジィ制御といろいろな方式があるため、制御アルゴリズムクラスは抽象クラスです。（ストラテジーパターン）。制御アルゴリズムクラス
は先の「理想」と「現実」を用いて、操作量を決定します。
３．定期的な制御について目標制御を定期的に実行するため「タイマー」クラスを定義しました。「タイマー」クラスは「一致させる人」クラスを呼び出し、「一致させる人」クラスは理想と現実を制御アルゴリズムに渡して定期的な制
御を行います。
また、別のタイマーとして、対象クラスを定期的に更新する、「更新させる人」クラスを定義しました。
「更新させる人」クラスが先の「タイマー」クラスと別に存在する理由として、「現実」のロールでの制御対象の計測は、「一致させる人」クラスの制御間隔とは異なる間隔で実行される場合があること、また「理想」のロールで保持している目標とする制御対象の値が不定期に変更される可能性があるためです。

73

役割に着目したモデル

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

静的モデル
目標制御のクラス構造
class 役割に着目したモ デル クラス 図
更新タイ マー
タイ マー
周期
状態

更新させる人OFFにする()
ONにする()

更新UI

1

1

状態：
制御中
非制御中

1
対象

1

理想

計測時刻 [0..1]
値1一致させる人0..1

計測時刻を取得する() :計測時刻 現実更新する()
1
値を取得する() :値制御アルゴリズ ム

一致させる()

0..1 1

計算する(理想, 現実) :操作量

0..1
1

1

制御器

1

値を集める人
1

値を取得する() :値

働く人
駆動する(操作量)

操作器

計算機

値入力UI

計測器

計算する()
値を取得する() :値画面を表示する()
値を取得する() :値計測する()
値を取得する() :値ABSの「車体速度」など

目標値の入力現実の値を取得する計測器
温度計・速度計など

オブジェクト例 エアコン
object オブジェクト例 エ アコン:更新UI:更新タイ マー:タイ マー

指定された室温（理想） :対象:一致させる人

現在の室温（現実） :対象入力パネル :値入力UI

C001 目標制御

室温センサ :計測器

パラメータ

コンプレッサー :働く人

74:制御アルゴリズ
ム

制御方式

2014 年 10 月版

C001 プログラム更新機能
はじめにプログラム更新機能は、ネットワークを通じてサーバに管理されている組込み機器の複数のプログラムを、依存関係を解決し動的に更新する機能です。今では、自動販売機、スマートメータ、ゲーム機器、携帯電話など、ありとあらゆる製品に搭載されています。

要求仕様プログラム更新機能の基本的な構成と要求事項
プログラム更新機能を持つ組込み機器のソフトウェアは、OS、フレームワーク、アプリケーションの 3
つのレイヤから構成されているものとします。プログラム更新機能は、フレームワークの一つの機能として存在し、OS が提供する機能を使用しながらフレームワーク上で動作するプログラムを更新します。

組込み機器１
アプリケーション
プログラム
A
サーバ

プログラム
B

プログラム

・・・

C
ネットワーク

フレームワーク
プログラム更新
機能

・・
・

OS
組込み機器 2

タイマ

組込み機器 3

このモデルでは、プログラム更新機能に対する重要な要求事項として、以下のものがあるとします。


データの通信量を少なく抑えるために、プログラムの差分を圧縮したデータをダウンロードすること。

プログラムもしくはダウンロードしたデータの正当性を保証するために、署名を用いること。



動作中のプロセスをできるだけ止めずにプログラムの更新が可能であること。

プログラムの更新に失敗した場合に、更新前のプログラムで動作すること。

プログラム更新の結果をサーバで検知できること。

75

はじめに

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

プログラム更新の流れ
ログ出力プログラムを、サーバログ出力プログラムに差し替え（削除と追加）、DB アクセスプログラムを更新する場合を例としてプログラム更新の流れを説明します。
以下の図のように更新を行うとします。
ログ出力.dll: 2.0

DB アクセス.exe: 1.2

使

使

用

GUI アプリケーショ
ン.exe: 1.0

用
更新後

ログ出
力.dll: 2.0

変更なし

更新

DB アクセス.exe: 2.1

差し替え

用

使

サーバログ出
力.dll: 1.0

使GUI アプリケーショ
ン.exe: 1.0
赤字：更新箇所

用

更新の流れは以下の図の通りとなります。
①バージョンリスト送付指示

組込み機器②バージョンリスト送付（プログラム更新機能）③更新指示
組込み機器側のタイミングで以下を始める④更新プログラム要求
サーバ⑤更新プログラム送付⑥結果報告

C001 プログラム更新機能762014 年 10 月版

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

uc 要求プログラム更新機能

UC01:プログラムのバージ ョ
ンリストを提供する

サーバ

UC02:プログラムを更新する

ユースケース一覧
No.

ユースケース名

概要／備考

UC01

プログラムのバージョンリスト
を提供するプログラムのバージョンリストをサーバに送る。

UC02

プログラムを更新するプログラムをダウンロードして更新する。

77

要求仕様

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

モデル一覧
着目点

コンセプト

ポイント

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

更新対象のプログラムとその組み合わせというシス
テム内に存在するエンティティに着目したモデルです。

プログラム間の使用関係を使って、停止するプロ
セスを特定します。

C001 プログラム更新機能782014 年 10 月版

エンティティに着目したモデル
モデリングのコンセプト
動作中のプロセスをできるだけ止めずにプログラムの更新を行うために、プログラム間の使用関係を管理し、更新対象のプログラムと関連しているプログラムを実行しているプロセスのみを停止します。

クラス構成
class クラス構成<<enumeration>>
更新区分<<interface>>
更新用タイ マハンドラ

プログラム更新機能
プログラムのバージョンリストを取得する()プログラムの更新を指示する()
タイムアップ()

維持
削除
追加
変更

タイムアップ()セット名

1

現バージョンセット
1

0..1

バージ ョンセット

ダウンロードデータ

セット名

セット名
/ハッシュ
署名

生成する(セット名)
プログラムを順番に取得する()更新の影響を受けるプロセスを停止する()
更新プログラムを診断する()

ダウンロードデータを追加する(ダウンロードデータ)検証する()
展開する()
差分を適用する(バージョンセット)

プログラム名プログラム名1

プログラム名

1

1
適用する

プログラム
名前
バージョン
更新区分
パス

差分データ
名前
バージョン
更新区分

使用先
0..*

差分を適用する(更新前プログラム)

使用しているプロセスを停止する()プログラムを診断する()
使用関係を構築する()

セキュリティ
署名
証明書

使用元
0..*

プロセス
プロセス

自己診断
自己診断

診断対象

79

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

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

プログラム更新機能の動作フロー
act 動作フロー
サーバ

プログラム更新機能開始

バージ ョンリストの送付を指示する

バージ ョンリストを提供する

更新を行うかを判断する

更新予定時刻は、OSによって適切に設定される。

[更新しない]終了[更新する]
更新を指示する

更新指示を受け取る
更新
予定
時刻

ダウンロードデータを送る

更新後プログラムを要求する

ダウンロードデータ

ダウンロードデータを受け取る

正当性を確認する

更新前後のプログラムの差分をまとめて圧縮し、署名を付与したものです。

[確認OK][確認NG]

ダウンロードデータを展開する

各プログラムに対して実施し、マージが終わるとダウンロードデータを削除する。

更新前プログラムと差分データをマージ するダウンロードデータを削除する

更新後プログラム

更新の影響を受けるプロセスを停止する

更新後プログラムの診断を行う[診断OK][診断NG]

現在のプログラムを更新後プログラムに変更する

更新前プログラムを削除する

更新結果を受け取る

更新結果を送る

終了

C001 プログラム更新機能

80

更新後プログラムを削除する

2014 年 10 月版

おわりに第二版によせて (2012 年 5 月)
2010 年 10 月に第一版のモデルカタログを出してから、約 1 年半。この間、メンバーを再構成して第二版のモデルカタログの作成に取り組んできました。第二版のモデルカタログ作成にあたっては、第一版の反省を踏まえ、「モデルの品質向上」と「カタログとしての見やすさ」を目標に掲げ、メンバー全員で熟考を重ねてきました。
たとえば「モデルの品質向上」では、モデリング経験豊富なメンバーにモデル作成チームの専任レビュ
アーとして活動してもらったり、ライターズワークショップと呼ばれる厳密なレビューセッションを通じてモデルのブラッシュアップを行ったりしてきました。また、「カタログの見やすさ」については、これまで
一冊にまとめていたカタログを、モデルの一覧をサマリして掲載した全体版(本書)と個々のモデルを詳細に説明したモデル版(モデル解説書)に分けるなどの工夫をおこないました。
そして、このような新たな試みを通じて、今回なんとかリリースにこぎ着けたのが「製品編」の「電子オルゴール」と、「部品編」の「目標制御」という 2 つのモデルです。いずれも担当メンバーやレビューを行った他メンバーの思いがこもった力作となっています。ぜひ、じっくりと読み込んでいただけると嬉しいです。
今回も、第一版同様、所属・仕事内容・経験のそれぞれが異なるメンバーが、業務の合間を縫って集い、作成を行ってきました。前回と違い、今回は各自が担当するモデル作成チームごとの集まりを主体に進めて来ましたが、特に今回の 2 つのモデル担当のメンバーの活動量は相当なものがありました。今回無事リリースできたのは、メンバーのモデリングに対する熱意がそれを上回った証だと思います。
さて、モデルカタログですが、これからも版を重ねていく予定です。今回の 2 つのモデルに続き、続々とリリース予定のモデルが控えています。それに向けて、みなさんからのフィードバックやご要望をいただ
きたいのはもちろんですが、いっしょにモデルを作ってみたいという方も歓迎いたします。このモデリング
部会は、会社や業務の枠を超えて、純粋にモデラーとしての活動に専念出来る貴重なフィールドです。モデリングに興味のある方や、UMTP で資格認定されたスキルを実際のモデリングの場で試したい方など、多くのみなさんの参加をお待ちしています。ご意見やご参加のお問い合わせについては、以下の URL をご覧ください。
http://www.umtp-japan.org/(上記 UMTP サイトから「UMTP について」→「活動報告」→「組込みモデリング部会」)
最後に、第一版に引き続き、第二版のモデルも、ぜひ、開発の現場において活用して頂ければ、開発メンバー一同嬉しい限りです。

81

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

カタログ作成に携わったメンバー (あいうえお順、敬称略。社名は参加当時のもの)
池下 弘之（日本電気株式会社）

石井 基樹（株式会社 JVC ケンウッド）

石滝 智洋（オリンパスソフトウェアテクノロジー株式会社）

石田 晴幸（株式会社富士通コンピュータテクノロジーズ）

大嶋 主悦（株式会社豆蔵）

大森 淳夫（パイオニア株式会社）

小黒 登行（株式会社豆蔵）金子 翔（アドソル日進株式会社）

栗田 道広（スター精密株式会社）

河野 岳史（スパークスシステムズジャパン株式会社）

小林 健一（株式会社豆蔵）

品川 正彦（株式会社日立インフォメーションアカデミー）

清水 鉄矢（オリンパスソフトウェアテクノロジー株式会社）

白神 一久（株式会社富士通システム統合研究所）

新家 了訪（株式会社テイジイエル）

鈴木 茂（株式会社オージス総研）

高原 大樹（アドソル日進株式会社）

辻村 浩史（株式会社富士通コンピュータテクノロジーズ）

時田 大介（スター精密株式会社）

西口 敦子（NEC ラーニング株式会社）

畑（株式会社オージス総研）

理介

羽生田

栄一

（株式会社豆蔵）

古谷 聡（日本プロセス株式会社）

松嶺 恭守（理想科学工業株式会社）

宮崎 崇（ムトーアイテックス株式会社）

山本 裕行（株式会社日立インフォメーションアカデミー）

吉田 邦雄（オムロンソフトウェア株式会社）

芳村 美紀（株式会社エクスモーション）：副主査

力武 克彰（仙台高等専門学校）

渡辺 博之（株式会社エクスモーション）：主査

82

組込み分野のための UML モデルカタログ
初版発行 ２０１０年（平成２２年）１０月１日
第八版発行 ２０１４年(平成２６年) １０月１日
発行者 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