2013年5月版
本書は、組込み分野のさまざまなモデルを集めたカタログです。モデリングの初心者には教科書や参考書として、モデリングのベテランの方々にはモデルのヒントとして、ぜひともお手元に置いて活UMTPは特定非営利活動法人UMLモデリング推進協議会の登録商標です。その他、本書に記載されている会社名、商品名などは、一般に各社の商標または登録商標です。
UMLモデルカタログの歩き方ここでは、みなさんがこのカタログを有効活用できるように、カタログの全体構成とお勧めの使い方を具体的にご紹介します。
UMLモデルカタログとは
昨今の組込み分野における開発規模の増大・複雑化・短納期化に対応する手法として、UMLによるモデリングが成果を上げています。UMLモデルを利用することで、大規模システムであっても、全体を俯瞰し、アーキテクチャレベルでシステムを理解したうえで各種の問題に対する対策を打てるので、生産性・品質を向上させることができます。しかし、実情はUMLモデリングを開発に取り入れてみたものの、モデリングの有識者がいないがために、その効果を十分に得ることができず、従来の方法に戻してしまう現場が多々あります。そのような状況を打開するために、初心者にはUMLモデリングに取り組む第一歩として、ベテランの方にはより良いモデリングのヒントとして、「カタログ」(本書)を提供することにしました。本書が開発の現場でUMLモデリングを利用する際の参考になれば幸いです。本書の適用範囲は、主に、製品開発におけるソフトウェア設計工程です。「組込みソフトウェア向け　開発プロセスガイド¹」 （以下ESPR）では、右図で示す範囲です。図1組込みソフトウェア開発プロセスと本書の適用範囲ある部分をハードウェアで実現するかソフトウェアで実現するかは状況によって変わるため、明確にせず、システム要求定義やシステム・アーキテクチャ設計までをモデルに含めている場合もあります。特に本書に関係の深い工程についての定義を以下に示します。

カタログの構成
UMLモデルカタログは、全体カタログモデル解説書を網羅した「カタログ」ファイ歩き方ル(本書)と、個々のモデルにつ求仕接Byモデルカタログいて詳しく記述した「モデル解分析分折説書」ファイル(名前は"＜カタロ要求仕様主要UML理PIM設計PIM設計グ番号>_<対象名>.pdf"。例：受求仕様分析分析× "F001_Authentication.pdf")に求仕様By主要UML図要求仕様分かれています。カタログファEA分析分析受求仕様イルには、モデリング対象の概モデル分折分折略と、モデル全体が見渡せる少PIM設計PIM設計:数のモデル図を抜粋したものが含まれています。モデル解説書:には、モデルについての全情報が含まれています。また、場合によってはEnterprise Architectのモデルファイルが付属していますので、併せて参考にしてください。 【Enterprise Architectについて】 Enterprise Architectは、Windowsで動作するUMLモデリングツールです。組込みモデリング部会では、スパークスシステムズジャパン株式会社様のご厚意により、モデリングにEnterprise Architectを使用しています。モデルファイルを公開するにあたり、UMTP専用の機能限定版Viewerを提供頂きましたので、必要な方はUMTPサイトよりダウンロードしてお使いください。 Enterprise Architectについて詳しくは、http://www.sparxsystems.jp/を参照してください。また、各モデルは、 「製品編」、「機能編」、 「部品編」に分類されています。 「製品編」は、印刷機など製品全体をモデリングして掲載しています。 「機能編」は、多くの製品に共通して搭載されている機能からいくつかをピックアップして掲載しています。「機能編」に掲載している機能をいくつか組み合わせることで、「製品編」に掲載している製品ができあがる場合もあります。 「部品編」は、より汎用的な、ライブラリとして使用できる部品を掲載しています。この部品は、「機能編」の機能でも「製品編」の製品でも、使用することができます。本カタログでは、まず、モデリングの対象となる製品や機能の要求仕様が定義されています。この要求仕様をもとにモデリングを行います。本カタログでは、1つの要求仕様に対して、複数のモデルを掲載しています。どのような状況でも正解であるモデルというものは存在しません。さまざまな状況で、さまざまな見方があり、複数のモデルが考えられます。要求仕様の後に、これら複数のモデルのインデックスとなるモデル一覧を用意しています。各モデルでは、分析モデル、 PIM設計モデル、PSM設計モデルといった具合に、段階的に詳細化を行っており、それぞれクラス図、オブジェクト図、コミュニケーション図、ステートマシン図などのUMLモデルを掲載して、モデルの解説を行っています。
※PSM設計モデルは、本書の対象外。将来の改版において含める予定。
【複数モデルについて】モデリングの対象が同じでも、要求仕様の整理整頓の仕方や重点を置くポイントが異なれば、できあがるモデルは異なるものになります。たとえば、「機能」「エンティティ」「状態」などに着目してモデリングすることもできれば、「メタファ」に重点を置いてモデリングすることもできます。 ...
カタログの使い方
本書では、次のような場面で利用されることを想定しています。新しい製品を開発することになり、製品全体のモデリングの参考として・・・ ◆既存製品に新しい機能を追加することになり、その機能のサンプルとして・・・ ◆既存製品の既存機能を改善するために、比較サンプルとして・・・ ◆組込みシステムにおけるモデリング教育の参考資料として・・・ ◆
利用例1
新しい製品の開発や既存製品への機能追加のサンプルとして利用する場合、下記のような流れで利用します。例えば、「コピー機」を開発する場合、製品編から「コピー機」のモデルを探しますが、見当たりません。このような場合、製品概要やキーワードからコピー機と「似た」製品を探します。その結果、「孔販印刷機」を選ぶことにします。 「孔版E即刷機」と「コピー機」には、「読み取り」、「書き込み」、「自己診断」等の共通した機能があり、これらがどのようにモデリングされるかを参考に開発ができます。さらに、「自己診断」については、機能編にその詳細が記述されていますので、機能編の「自己診断」で掲載されているモデルも参考にするとよいでしょう。また、「コピー機」に必要な機能が、参考とする「孔版印刷機」にない場合、機能編を探してみると、その機能が掲載されているかもしれません。製品を構成する機能の多くは、同様の製品に搭載されていることが多く、本書においても機能編でより詳細なモデリングを行っている場合がありますので、機能編も合わせて参考にしてください。各モデルは、全てを取り入れる必要はありません。必要な部分を取り入れて、開発しようとする製品に合わせて、うまくカスタマイズしてください。組込みシステムにおけるモデリング教育の参考資料としては、モデリング技法の解説や、演習問題の題材として、以下のような利用ができます。例えば、組込みソフトウェアのモデリング技法を演習付きで習得できる講座を作るとすると、以下のような流れになります。まずモデリング解説のためのテキストを作成します。その際に活用するモデルとして、例えば「自己診断」のモデルのうち「メタファを使って分析したモデル」を選びます。ここでは、モデルの作成手順や考えが詳細に記述してあるものから選択すると良いでしょう。モデリングを解説するテキストでは「自己診断」の「メタファを使ったモデル」に記述された本書のモデルが、どのような考えに基づいてされたのか、行間を埋めていくイメージで作成します。例えば、本書のモデルでは、静的モデルとしてのクラス図に続いてシーケンス図が記述されています。テキストでは、静的モデルとしてのクラス図を作成した後には、クラス図には表現しきれない振る舞いを、シーケンス図で表現することや、クラス図のクラスとシーケンス図のクラスの対応から、具体的にどのようにクラス図からシーケンス図が作成されたのかを解説します。次に、演習を作成します。演習の課題として、例えば「認証」を選びます。ここでは、モデリング例が多いものを選択すると良いでしょう。必要であれば、モデリング解説用のテキスト作成時と同様に、「認証」に対するモデリング例から模範解答を選び、解説を作成します。以上を準備として、講義を実施します。

製品編

機能編

部品編

モデルカタログ：製品編製品編のモデルカタログです。
POO1 孔成自動動
ご注意：孔版印刷機の要求仕様は、理想科学様よりご提供いただきましたが、本力タログ内のモデルは、理想科学様内で使われている製品版のモデルとは一切関係ございません。また、理想科学様メンバは、本孔版印刷機のモデリング作業には、一切関わっておりません。
要求仕様
孔版印刷機とは、「孔版印刷」という技術を使った印刷機で、低コストに大量の印刷物を作成することを実現する機械です。
孔版印刷機での基本的な印刷方法
孔版印刷とは、『版』と言われるものに孔（あな）をあけ、孔があいた所にインクを通過させて、画像を用紙に転写する方法です。一度『版』を作ってしまえば、『版』が巻き付いたドラムに用紙を押し当てて通過させることで転写が完了することから、レーザープリンタ・インクジェットプリンタ・PPC方式の複写機などの比較にならないほどのスピードで印刷することができます。
利用者の要求と版のライフサイクル
孔版印刷機では、利用者が要求する複写や印刷の単位と、その際に作成した版のライフサイクルは一致しません。例えば、一度複写するために版を作成すると、そのまま版を残しておき、別のタイミングでその版を使って印刷を行うことができます。版を除去するタイミングは、次に原稿から複製を作るとき、もしくは、利用者が版の除去を指定した時となります。

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

モデリングのコンセプト
要求仕様で整理された原稿、版、用紙の静的な構造に着目し、これらを孔版印刷機の中心と位置づけます。その構造を中心として孔販印刷機をモデル化した全体概念モデルと、それをドメインに分類したクラス図を次に示します。孔版印刷ドメインは、主にシステム全体の状態や、利用者からの要求を取り扱うことが使命です。それ以外のドメインは、各種デバイスを制御し、孔版印刷を実現するための手段を提供する、と
分析モデル
孔版印刷ドメイン
孔版印刷ドメインは、システム全体の最上位のドメインであり、利用者からの要求を実現することが使命です。利用者からの要求の特徴は、要求仕様でまとめたように、原稿から複製を作成する場合と、すでにある版を使って印刷する場合の2種類があります。原稿から複製を作成する場合には、原稿を読み取って画像化し、その画像を使って版を作成し、版から印刷物を作成する、といった流れになります。すでにある版を使って印刷する場合には、版から印刷物を作成するだけとなります。また、このドメインでは、パフォーマンスを出すために、一枚ずつ印刷結果を確認しません。印刷自体のながれは、書き込みドメインに指定した枚数分の印刷の管理をゆだねます。
静的モデル

はじめに
電子オルゴールは、携帯音楽プレーヤーのような音楽再生装置で、曲やプレイリスト²を再生できます。オルゴールや音楽再生装置という身近なものを考えていますので、分かりやすいモデルです。本モデルでは、曲やプレイリスト、再生パラメータをリストにまとめて管理する方式を表現しています。これは、データをグルーピングして管理する場合の参考になります。また、ユーザーインターフェースに関しては、設計モデルにデザインパターンを適用したモデルを提示しています。こちらは、小型の画面を持つ機器のユーザーインターフェースの設計に用いることができます。
要求仕様
機械式オルゴールは、シリンダやディスク上のピンが、オルゴールの櫛の歯を弾くことによって音楽を奏でます。本力タログで扱う電子オルゴールは、機械式オルゴールの発音操作をソフトウェア制御します。これにより、(通常の機械式オルゴールは1曲の演奏を行いますが)、複数の曲の再生に対応できるオルゴールとなります。曲を再生する機器には、携帯音楽プレーヤーがあります。電子オルゴールは、携帯音楽プレーヤーと同様のプレイリストにより複数の曲を再生します。プレイリストについて、携帯音楽プレーヤーとほぼ同様です。反面、携帯音楽プレーヤーは、テンポを変更できませんが(再生速度を変更すると可能ですが、音程も変わってしまいます)、電子オルゴールは、音程を変えずに、テンポを変更できます。これは、オルゴールが楽譜としてシリンダを持っており、それを元に演奏することをソフトウェアで再現しているためです。

ハードウェア仕様
1．小型の木製の箱である（発音装置との組み合わせでオルゴールを再現できるもの） 2.駅動●バッテリで駆動すること● ACアダプタ接続により駆動すること3.インターフェース●小型液晶ディスプレイ● 上/下/左/右/中央の5個のキー ● SD-Card 4.音源方式●ウェーブテーブルSWシンセ
電子オルゴールの基本的な機能
1.プレイリストに曲を登録し、プレイリスト内の曲を再生していくことができます。 2.調律³、リヴァープ4 、音量の設定を「曲調」として登録しておくことができます。ユースケース
モデル一覧

モデリングのコンセプト
(1)電子オルゴールをモデリングするにあたり、機械式オルゴールを以下のようにとらえなおしています。
シリンダを曲、櫛などを音源ととらえ、曲と音源が協調して、曲を再生します。 (2) 「電子オルゴール」を一般的な「曲を順番に再生する音楽再生装置」として捉えます。 (2a)プレイリストは曲を順番に再生するので、プレイリストは曲を集約します。 (2b)一般的に音楽再生装置のメニューはフォルダのような階層があり、プレイリストを選択します(フォルダはフォルダまたはプレイリストを集約します)。電子オルゴールには階層はなく、フォルダはプレイリストを集約します。 (2c)電子オルゴールのすべての曲を管理するものが必要で、全曲目録とします。 (2d)プレイリストと全曲目録は、曲を集約し、再生する責務を持つことが共通しています。共通部分を再生目録として汎化させます。以上をまとめた、電子オルゴールの主要なクラスを次に示します。
分析モデル
前述の電子オルゴールの主要なクラスに、ユースケースの実行に必要なユーザーインターフェース、曲調、曲調マネージャー、外部メディアを追加し、分析モデルを作成しました。また、クラス数が増えたため、ユーザーインターフェース、曲、曲調、デバイスのパッケージに分割しました。曲パッケージは、曲やプレイリストなど、曲を連続して再生するという音楽再生装置として主要な部分になります。Orderedとbagについては後述します。ユーザーインターフェースパッケージはユーザとのインターフェースを司ります。曲調パッケージは、本力タログの要求仕様の曲調を実現する部分です。要求仕様により内容が大きく変動する部分です。デバイスパッケージは、電子オルゴールのデバイスをまとめたものです。
「インライン装置」は、工場の生産ラインなどで使用される上流から下流に向かって、製造物や検査品を搬送/処理する装置のことです。どのような機構で搬送するか、どのような加工/検査をするかに関係なく、再利用可能なモデルとして提供しています。また、自動運転や並行処理の待ち合わせといった装置開発でよくみられる課題を扱っています。このモデル解説書では「インライン装置」と呼ばれる装置を、 1.前の装置から引き渡された「何か（試料）」を、 2.なんらか処理して、 3.後ろの装置に引き渡す。のステップでとらえ、汎用的な要求仕様として、提示しています。試料前処理装置から試料を受け取る試料を処理する
要求仕様
とえば、搬送ステージごと試料を移動するコンベアのような機能ならば、コンベアが一回一回の搬送で止まる位置のこと。

機能要求
◆処理開始機能操作部のスタートボタンを押下すると、装置状態が運転モードになり、自動処理を開始します。 ◆　処理停止機能操作部のストップボタンを押下すると、自動処理を停止し、装置状態が停止モードになります。 ◆　試料搬送機能運転モードのときに、前処理装置から搬送部へ試料が導入されると、連続運転の実動作を開始します。連続運転の動作仕様①　前処理装置から引き渡された試料は、試料位置決め器によって、処理エリアから決まった距離になるように位置決めをします。この時、導入検出跨りセンサによって、前処理装置から導入されているかを確認します。 ②　位置決めをした所から、一定の間隔で搬送します。この時、導入検出跨りセンサによって、前処理装置から搬送ステージ内に確実に引きこんだかを確認します。 ③　処理エリアまで搬送します。処理エリアでは、処理部によって試料を処理します。 ④次の試料を処理エリアに運ぶのと同時に、処理済みの試料を後処理装置に向かって搬送します。 ⑤　試料排出器によって試料を後処理装置へ排出後、排出跨りセンサで、引き渡しができているかを確認します。（払い出し部の一例：）ただし、後処理装置が排出を受け付けられない場合は、受け付けられるようになるまで待ってから排出をします。以上の①～③と③～⑤の間が何回で搬送されるかは、搬送ステージの長さや試料の長さによって、 ※さまざまなパターンが考えられます。上記の例は、最小限を考えた一例です。搬送部の各動作と処理部の動作の並行タイミングの要求インライン装置は、試料の位置決め、試料の処理、試料の排出を並行して行う事が出来ます。試料の搬送は、試料の位置決め、試料の処理、試料の搬出を行っていない場合に行う事が出来ます。搬送中上記二つの状態を交互に繰り返すことによってインライン装置の動作を実現します。試料の搬送
このため、試料の搬送が完了を待って試料の位置決め、試料の処理、試料の搬出を実行する必要があります。また、反対に、試料の位置決め、試料の処理、試料の搬出の全ての完了を待って試料の搬送を実行する必要があります。
ユースケース
モデル一覧

ドメイン構造に着目したモデル
モデリングのコンセプト
このモデルは、管理クラスや制御クラスといったクラスを出さずに、要求仕様からのモノの構造のみに着目してモデル化しています。またモデルを利用する際に、オブジェクト同士の協調に集中してもらうため、（オブジェクト同士の境界線を引いてしまうような）パッケージ分けをしていません。
分析モデル
点線の枠は、論理ハードウェア仕様の論理ブロックの範囲を示しています。搬送ステージはエリアへの関連を持たせました。導入エリア、処理エリア、排出エリアはエリアから派生しているため、搬送ステージはこれら３種類のエリアを統一的に扱うことができます。しかし、搬送ステージからそれぞれ個別の特性も扱う必要があります。そこで、搬送ステージには、導入エリア、処理エリア、排出エリアへの関連も持たせました。また、これらの関連に{subsetsエリア}を指定することによって、関連先の要素がエリアへの関連先要素に含まれていることを明確にしています。連続運転の相互作用モデルカタログ：機能編機能編のモデルカタログです。
FOO1務員
要求仕様
認証例
ユーザAとユーザBがいます。二人はそれぞれ固有のIDカードを持っています。この2人が2台のPCからそれぞれの電子データを１台のプリンタに印刷指示を出します。ユーザＡがプリンタにIDカードをかざすと、ユーザＡが印刷指示した電子データが呼び出され、プリントが始まります。ユーザＡの電子データの印刷処理終了後、ユーザＢが同様にIDカードをプリンタにかざすと、ユーザＢの電子データが呼び出されプリントが始まります。ユーザA,Bの使用日時や電子データのタイトル、プリント枚数など使用記録がプリンタ保存されます。このようなユーザごとに適切なサービスを提供できる仕組みを【認証】と呼称します。この【認証】では、ユーザを識別し、ユーザごとに適切なサービスを提供し、機器の使用記録を取ります。この一連の機能の設計モデルを提供します。
ユースケース
モデル一覧

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

モデリングのコンセプト
本モデルは、広くしられているAAAモデルの構造を模す事を出発点としました。AAAに登場する認証、承認、アカウンティングの３要素が取り扱う情報の責務に着目することを本モデルのコンセプトとして設計を行いました。 3要素のほかに要求仕様から読み取れる、ユーザのIDカード、ユーザに提供するサービス、ユーザの使用履歴といった情報を抽出し、それを元に分析作業を行いました。
分析モデル
静的モデル最上段にはAAAの３要素、認証、承認、監視を配置しました。認証が扱う情報は、ユーザを識別するための情報です。認証が扱うユーザを識別する情報をアカウントとし、その下に配置しました。承認が扱う情報は、サービスです。承認が扱うサービスを、その下に配置しました。監視が扱う情報は、サービス利用（サービス利用後情報）です。
クラス構成その2
クラス構成その１をもとに、さらにクラスを抽出します。シーケンスの検討やPIMモデルの検討を通してクラス図は上記のように変化しました。以下は追加された最下段のクラスの責務と説明となります。認証証明書：ログインアカウントと非ログインアカウントを区別するためにログイン時に生成されます。承認証明書：サービス実行前にサービスの実行権が監視からも認められているか確認するクラスです。例えば監視条件を満たさない場合（課金不足など）、サービスの実行権を失う状況を実現します。サービス利用量：監視の使用記録などの実データとなります。

モデリングのコンセプト
認証機能は、ユーザがサービスを使用したいという要求に対して、正当なユーザか？正当なサービスか？正しく使用されているか？といった観点からサービス使用に対して制限を掛けるという機能になります。この事からユーザがサービスを利用するまでに、ユーザにサービス利用の制限をかけるエンティティが幾つか出現すると考えられます。これらのエンティティを明確化することをモデリングの出発点として分析作業を行いました。
分析モデル
静的モデルこのクラス図において、「認証」「サービス利用」「サービス利用監視」がそれぞれ認証、承認、監視の役割に当たります。これら以外の情報がサービス利用に制限をかけるためのエンティティとなります。制限をかけるためにどのような情報が必要かという点を検討するために、サービスの利用時に制限するために行う確認事項を洗い出してみます。 ・正当なユーザか？ ・正当なサービスか？ ・正当な組み合わせか？ ・正当に使用されているか？（監視記録）このうち、正当な組み合わせに関しては、サービスの実行時刻や実行場所など様々な条件が考えられますが、モデルを簡素化するために、一旦、アカウントとサービスの組み合わせが適切か？というシンプルな確認とします。上述した確認事項から残りのエンティティを見た場合、 ・「アカウント」は、サービス利用者が妥当かどうかを判断するための情報・「サービス情報」は、正当なサービスを実行するための情報・「権限」は、どのユーザがどのサービスを実行できるかを示した情報・「サービス利用量」は、サービスの利用状況の記録という位置づけになります。これで先ほどの確認に伴うエンティティは網羅できました。クラス図の中で残された一つの「サービス利用ライセンス」は、ユーザが特定のサービスの実行を許可された事を示す情報として作成しました。

モデリングのコンセプト
ユーザが認証された・認証されていない、といった状態に着目したモデルです。認証モデルは、ユーザが認証されているか・認証されていないか、によってユーザからの処理依頼に対する振舞いを適切に切替えることが重要です。振舞いの切替えに、ヌケ・モレが無いことを、コーディング時ではなくて、構造設計レベルで抑えようというのがこのモデルのコンセプトです。
分析モデル
静的モデルユーザとの認証に絡む振舞いを担うクラスとして「認証」を設けます。ユーザ毎の情報を保持するクラスとして「アカウント」を設けます。「アカウント」には、認証に必要な情報「権限」と、そのアカウントが過去にサービスを利用した記録である「サービス利用量」を関連付けます。ユーザが認証されたときに利用出来るサービスは複数あるため、サービス毎に承認が必要と考え、サービス毎の承認ずみかどうかを表すために「承認」を設けます。ユーザのサービス利用量を監視・記録するために「サービス」を設けます。各々のサービス固有処理は、 「サービス」から派生した「具象サービス」が担うものとします。ユーザによるサービス利用を監視した結果をユーザ毎に分けて記録するために、「サービス」からも、 「アカウント」に関連づけた「サービス利用量」に関連を持たせます。動的モデル状態遷移認証モデル全体が、ユーザ認証、サービス利用承認によりどのように状態が変化するかを示します。ユーザが認証されていない状態を「未認証」、ユーザが認証された状態を「認証済」と呼ぶことにます。最初の状態は「未認証」です。ユーザが認証を試みて、システムに正当なユーザであると判断されると「認証済」へ遷移します。 「認証済」状態にネストする形で、サービスを利用していない「サービス未利用」と、サービスを利用中の「サービス利用中」の2つの状態があります。「認証済」に遷移した直後は、「サービス未利用」です。これらの状態は、サービス毎にあります。ステートマシン図では、サービスAとサービスBの2つのサービスについて、それぞれ状態を持てることを示しています。ユーザがサービスを利用しようとすると、システムが認可するかどうか判断します。システムが承認した場合は「サービス利用中」に遷移します。システムが承認しない場合は、「サービス未利用」に留まります。ただし、「サービス未利用」と「サービス利用中」の状態は、システムに1つではなく、サービス毎に状態をもつ必要があります。
F002自己診断
自動車や通信機器などには警告灯を備えるものや故障を示す表示ができるものがあります。これらには、装置が正しく動いているかどうかを調べる自己診断機能があり、異常を検知すると、(対処や)表示を行います。また、トラブル発生時に原因究明や対応を行うため、手動で自己診断ができる機器もあります。
要求仕様
1．組込み装置には、装置が正しく動作しているかどうかを調べる自己診断機能があります。 2．自己診断は、機器管理者の要求により起動される場合と、予め設定された条件に合わせて自動的に起動される場合があります。いずれも、機器管理者の指示により中止することが可能です。 3.診断の対象には、デバイス単体や、複数デバイスから構成される機能ユニット、そして装置上で動作するアプリケーションが含まれます。機能ユニットは階層構造を持つことが可能で、上位の機能ユニットは複数の下位機能ユニットを含むことができます。 4. 一つの装置内では複数の自己診断を実施することが可能です。各自己診断は、1つの診断対象に対する診断でも、それらを任意に組み合わせたものでも構いません。 (例：起動時診断や月次診断では全機能ユニット、週次診断では重要機能ユニット、日次診断では最重要ユニットなど。）また、自己診断に含まれる各診断は、並行・逐次、どちらの形でも実施可能です。 5．診断対象ごとに、診断項目が決まっており、各診断ではどの診断項目を診断するかを設定することが可能です。 (例：起動時診断や月次診断では診断項目1～10まで、過次診断では1～5と6～10を交互に、日次診断では１と２のみなど。） 6．診断結果は、診断項目ごとにOK/NGの結果と、NGの場合には、エラーコードをレポートします。 7．診断結果の履歴は保存する必要がありません。 8.診断途中で中止されたときには、それまでの診断内容をレポートして終了します。
ユースケース
モデル一覧

要求仕様をエンティティに着目し、診断を診断対象の診断項目と対応する結果と捉え、このような診断を組み合わせることでさまざまな診断をモデリングしています。
モデリングのコンセプト
要求仕様の内容を忠実に分析し、モデリングします。要求仕様から以下の特徴が読み取れました。 ( i ) (後述の組み合わせた診断に対して)単一の対象に対する診断とは1個の診断対象に対して定められた診断項目を診断し、診断結果を得ることです。診断対象に対して診断項目は決まっていますが、診断毎にどの診断項目を診断するかを設定することが可能です。(UML図ではなく)簡単に図示すると以下のようになります。 ( ii )診断は複数の診断から組み合わせることもでき、以下のように並行/順番に実行されます(組み合わせた診断)。(UML図ではなく)簡単に図示すると以下のようになります。
分析モデル
前述の(i)より、診断、診断対象、診断項目、診断結果、の各クラスとそれらの関係、(ii)より診断クラスの自己関連が導き出されます。さらに以下を加え、クラス図を作成しました。 ( iii )要求仕様3より診断対象の構造(組込み装置、機能ユニット、デバイス、アプリケーション、の各クラス) ( iv )レポートを表すレポートドメイン(レポート、フォーマット、出力方法、の各クラス)
モデリングのコンセプト
装置の自己診断機能をモデリングするにあたり、まずは診断の意味や目的を考え、日常生活の診断に適用できる概念モデルを作成してみます。診断についての理解を深め、概念を明確にすることで、分析モデルや設計モデルの作成に役立つと思います。
1.  診断って何だろう？
診断とは病気や欠陥など悪いところがないか調べることです。装置の場合は故障箇所や不具合箇所がないか調べることです。悪いところに限らず、悪くなりかけているところや悪くなりそうなところも調べられると、よりよい診断といえるでしょう。 ◆診断の類義語:検診、点検、検査2.診断する目的は何だろう？問題箇所や予防箇所がないかを診断することで、自己修復あるいは他者に治療・改善・修理依頼するきっかけを知ることができ、診断対象を長生き・長持ちさせるのが目的と考えられます。 3.身近な診断には何があるだろう？身近にある診断、点検、検査を探してみました。 ◆健康診断◆車検◆温水洗浄便座◆分電盤◆消防設備点検4.診断に関する共通項目には何があるだろう？前述の身近な診断(点検、検査を含む)において、共通する項目を挙げてみます。

5.診断シナリオ
共通項目を使って、診断するときの手順(シナリオ)を考えてみます。 ◆登場人物(アクター)は「診断依頼者」「診断実施者」「診断対象」の３人。本人が本人の診断を依頼すれば「診断依頼者」と「診断対象」は同一です。 ◆ ◆ 「診断依頼者」は、「診断時期」になった「診断」がないか定期的に確認し、あれば「診断実施者」に「診断対象」の「診断」を依頼します。 ◆ 「診断時期」に関係なく、「診断対象」が調子悪くなったり、なんとなく気になったときに「診断依頼者」が「診断実施者」に「診断対象」の「診断」を依頼することもあります。 「診断実施者」は、「診断項目」毎に「診断対象」を「診断」し、「診断結果」を記入して「診断依頼◆者」に通知します。 「診断対象」は「診断部位」を診せます。 ◆ 「診断依頼者」は、「診断結果」を確認し、問題があれば治療や修理などを施します。 ◆
静的モデル
共通項目を使って、概念モデルのクラス図を書いてみます。モデルカタログ：部品編部品編のモデルカタログです。
COO1日環制御
はじめに
目標制御は、特定の制御対象・システムに対して式やテーブルといった最適化が施された形態で実装されることが多くあります。このモデルは、目標制御の実装形態はブラックボックスとし、その中身に依存しない形にしました。このモデル（部品編目標制御）では、登場するクラス数が少なく、モデルの全体と対象物が把握しやすいものとなっています。
要求仕様
目標制御システムとは、制御対象の計測値が目標値となるように制御する仕組みで、エアコンの温度調節や自動車のABSなど数多くの製品に組み込まれています。
目標制御システムの基本的な構成と動作
目標制御システムは計測器、操作器、制御器で構成されます。利用者は制御が必要な状況で、目標制御システムに制御の開始を指示します。目標制御システムは、制御中は一定時間周期で制御対象を計測し、それに応じた操作を行うというフィードバックを繰り返します。制御対象は目標制御システム以外の不特定な要因からも影響をうけますが、その都度出力を修正することで、フィードバックを繰り返すことで、うまく制御を行えるようになっています。目標制御の実例目標制御を開始すると、操作器の操作量が制御対象に伝わるまでの時間（むだ時間）を経過した後、計測値は目標値に近づいていきます。このときの目標値に近づくまでの時間が立ち上がり時間です。計測値が目標値に達したときに、勢いがついていたりすると、オーバーシュートが発生します。その後、ハンティングをしながら、徐々に計測値は目標値付近で安定するようになります。最終的に安定したときの計測値と目標値の差が定常偏差として残ることになります。目標制御を実現するアルゴリズムには、ON/OFF制御、PID制御、ファジィ制御などの制御方式があり、制御方式によって、目標値への近づき方の特徴に違いがあります。注：これらの制御方式については付録を参照してください。
用語定義
すでにいくつかの用語を使用していますが、あらためて用語の定義を行います。しかし、それだけではイメージがつきにくいと思いますから、具体的な製品（例としてエアコンとABS）で、何に該当するかもあわせて以下に示します。

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

モデル一覧

モデリングのコンセプト
静的な構造として目標制御を行うのに必要な構成部品に着目しました。また、要求仕様に登場するON/OFF制御、PID制御、ファジィ制御といった複数の制御方式に対応できるように考慮しました。
分析モデル
１．制御対象および計測、操作について実際の制御対象（エアコンであれば室温で、ABSなら車輪速度です）の今の状態の保持やそれに関する情報を保持するクラスとして「制御対象クラス」を定義しました。制御対象クラスは属性として目標値と計測値を持ちます。なお、「計測値」属性は実際には操作であり、操作を呼ぶと計測器クラスの「計測する」操作を呼び出します。制御対象には一般的に、制御対象特有の上限値・下限値、あるいは計測器が持つセンサからくる上限値・下限値（計測限界）が存在します。そのため、制御対象クラスは範囲クラスを保持する形となります。 2．制御方式について制御器が制御を行う際、どのように制御するか？（制御対象への出力をどうするか？）（例えば計測値が目標値に近づいてきたから、出力を弱めるといったこと）を考える必要があります。これを制御方式クラスが行います。制御方式にはON/OFF制御、PID制御、ファジィ制御といろいろな方法がありますから、制御方式クラスは抽象クラスとなります（ストラテジーパターン）。制御方式クラスが操作量を算出する際には、元となるデータ（制御パラメータ）が必要となりますので、制御方式クラスは制御パラメータクラスを保持することになります。制御方式クラスでは操作量算出時に必要な内部データ（PID制御であれば例えば、偏差（目標値と現在値の差）の時間積分値）が必要ですが、これは実際の制御方式に依存するため、ここでは抽出していません。制御パラメータが持つデータについても同様で、PID制御であれば比例係数、積分係数、微分係数の3つを持つことになりますが、これも制御方式に依存するものですのでここでは抽出していません。注：PID制御の詳細については付録を参照してください。
３．定期的な制御について
制御は定期的に行う必要があるためタイマーが必要となりますから、それを定義しました。分析の動的モデルではタイマーが目標制御システムで定義される操作を直接呼び出す形としますが、本来は、一般にタイマーは目標制御部品とは別の部品であり、タイマーが目標制御システムで定義している操作を直接呼び出すことはできません。これについてはPIMで検討します。
4.その他
制御対象を実際に制御する場合、その良し悪し、具体的には立ち上がり時間、オーバーシュート量、八ンティング量、定常偏差の量などを、考える必要があります。しかし、これについては制御方式クラスのサブクラスが考えることであるため、クラス構成を抽出する際には考慮対象外としました。静的モデル目標制御システムのクラス構造
動的モデル
「制御中」の相互作用
モデリングのコンセプト
目標制御の理想と現実を近づける機能に着目しモデリングしました。目標制御の目的である「対象の現実を理想に近づける」という点をアーキテクチャの中心に据え、それぞれの役割を擬人化したモデルです。このようなモデリングの考え方もあるというサンプルとして、分析モデルのみ提示します。
分析モデル
1．制御対象および計測、操作について実際の制御対象（例えばエアコンにおける室温、ABSにおける車体速度）を表すクラスとして、「対象」クラスを設けました。「対象」クラスには「理想」と「現実」２つのロールがあります。「理想」の口ールは目標とする制御対象の値を保持し、「現実」のロールは計測された制御対象の値を保持します。 「対象」クラスは「更新させる人」クラスによって定期的にその内容を更新されます。「現実」のロールには制御対象の計測（更新）時刻が必要なため属性として持ち、「理想」のロール側には必要ないため、属性に多重度を示しています。また、目標制御の入力数と出力数はそれぞれ１つずつのモデルです。 2．制御方式について制御を行う際、どのように制御するか（例えば計測値が目標値に近づいてきたら、出力を弱めること）を考える必要があります。これを制御アルゴリズムクラスが行います。制御アルゴリズムクラスの制御方式にはON/OFF制御、PID制御、ファジィ制御といろいろな方式があるため、制御アルゴリズムクラスは抽象クラスです。（ストラテジーパターン）。制御アルゴリズムクラスは先の「理想」と「現実」を用いて、操作量を決定します。 ３．定期的な制御について目標制御を定期的に実行するため「タイマー」クラスを定義しました。「タイマー」クラスは「一致させる人」クラスを呼び出し、「一致させる人」クラスは理想と現実を制御アルゴリズムに渡して定期的な制御を行います。また、別のタイマーとして、対象クラスを定期的に更新する、「更新させる人」クラスを定義しました。 「更新させる人」クラスが先の「タイマー」クラスと別に存在する理由として、「現実」のロールでの制御対象の計測は、「一致させる人」クラスの制御間隔とは異なる間隔で実行される場合があること、また「理想」のロールで保持している目標とする制御対象の値が不定期に変更される可能性があるためです。静的モデル
オブジェクト例
おわりに
2010年10月に第一版のモデルカタログを出してから、約1年半。この間、メンバーを再構成して第二版のモデルカタログの作成に取り組んできました。第二版のモデルカタログ作成にあたっては、第一版の反省を踏まえ、「モデルの品質向上」と「カタログとしての見やすさ」を目標に掲げ、メンバー全員で熟考を重ねてきました。たとえば「モデルの品質向上」では、モデリング経験豊富なメンバーにモデル作成チームの専任レビュアーとして活動してもらったり、ライターズワークショップと呼ばれる厳密なレビューセッションを通じてモデルのブラッシュアップを行ったりしてきました。また、「カタログの見やすさ」については、これまで一冊にまとめていたカタログを、モデルの一覧をサマリして掲載した全体版(本書)と個々のモデルを詳細に説明したモデル版(モデル解説書)に分けるなどの工夫をおこないました。そして、このような新たな試みを通じて、今回なんとかリリースにこぎ着けたのが「製品編」の「電子オルゴール」と、「部品編」の「目標制御」という２つのモデルです。いずれも担当メンバーやレビューを行った他メンバーの思いがこもった力作となっています。ぜひ、じっくりと読み込んでいただけると嬉しいです。今回も、第一版同様、所属・仕事内容・経験のそれぞれが異なるメンバーが、業務の合間を縫って集い、作成を行ってきました。前回と違い、今回は各自が担当するモデル作成チームごとの集まりを主体に進めて来ましたが、特に今回の2つのモデル担当のメンバーの活動量は相当なものがありました。今回無事リリースできたのは、メンバーのモデリングに対する熱意がそれを上回った証だと思います。さて、モデルカタログですが、これからも版を重ねていく予定です。今回の２つのモデルに続き、続々とリリース予定のモデルが控えています。それに向けて、みなさんからのフィードバックやご要望をいただきたいのはもちろんですが、いっしょにモデルを作ってみたいという方も歓迎いたします。このモデリング部会は、会社や業務の枠を超えて、純粋にモデラーとしての活動に専念出来る貴重なフィールドです。モデリングに興味のある方や、UMTPで資格認定されたスキルを実際のモデリングの場で試したい方など、多くのみなさんの参加をお待ちしています。ご意見やご参加のお問い合わせについては、以下のURLをご覧ください。 http://www.umtp-japan.org/ (上記UMTPサイトから「UMTPについて」→「活動報告」→「組込みモデリング部会」)最後に、第一版に引き続き、第二版のモデルも、ぜひ、開発の現場において活用して頂ければ、開発メンバー一同嬉しい限りです。

組込み分野のためのUMLモデルカタログ
初版発行２０１０年（平成２２年）１０月１日第四版発行２０１３年（平成２５年）５月１日発行者   UMTP, Japan編　著　組込みモデリング部会ED刷UMTP, Japan東京都渋谷区代々木1丁目22番1号http://www.umtp-japan.org/ Copyright(c)2010-2013 consortium for UML based Modeling Technologies Promotion All Rights Reserved