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

機能編 F001

認証

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

して、モデリングのベテランの方々にはモデルのヒントとして、ぜ2016.5.15 更新

ひともお手元に置いて活用してください。

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

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

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

2

認証

目

次

要求仕様 .................................................................................................... 4
モデル一覧 ............................................................................................... 10
機能に着目したモデル ................................................................................. 11
分析モデル ............................................................................................. 11
PIM 設計モデル ....................................................................................... 17
エンティティに着目したモデル ..................................................................... 18
分析モデル ............................................................................................. 18
PIM 設計モデル ....................................................................................... 24
状態に着目したモデル ................................................................................. 29
分析モデル ............................................................................................. 29
PIM 設計モデル ....................................................................................... 32

3

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

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

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

要求仕様

4

認証

ユースケース

図1

5

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

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

■アクター
ユーザ

■事前条件
なし

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

■備考
なし

要求仕様

6

認証

＜UC02 名：サービスを利用する＞■概要
ユーザが組み込み装置で提供されているサービスを利用する

■アクター
ユーザ

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

■備考
なし

7

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

■アクター
なし

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

■備考
なし

要求仕様

8

認証

＜UC04 名：サービス利用状況を監視する＞■概要
ユーザがサービスを利用している状況を監視し、記録する

■アクター
なし

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

■備考
なし

9

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

モデル一覧
着目点

コンセプト

ポイント

機能に着目したモデル

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

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

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

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

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

状態に着目したモデル

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

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

メタファを使ったモデル

なし

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

モデル一覧

10

認証

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

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

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

誰が許可で誰が不許可か

承認

認証
+

+

ユーザを認証する()+

監視処理を実行する()

1
登録サービス*1

アカウン トサー ビ ス

名前カギ

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

1

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

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

サービスを承
認している

1 -

内容

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

登録課計
1
*

サー ビ ス利用量ルー ル

1++

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

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

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

図2

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

11

分析モデル

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

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

クラス構成その１の具体例
cla s s 要 求 仕 様 オブ ジ ェクト図認証システム

端末

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

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

承認

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

監視

端末

Bさ ん

印刷サー ビ ス

Bさ ん IDカー ド

使用履歴を と る

Aさ ん ユ ー ザ情報

Bさ ん ユ ー ザ情報

図3

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

機能に着目したモデル

12

認証

クラス構成その 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..*

サー ビ ス利用量

承認有効状況

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

図4

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

13

分析モデル

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

動的モデル
ユーザを認証するときの相互作用
s d ユ ー ザを 認証す る

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

Facade認証:認証証明書

ユーザA

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

生成()

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

機能に着目したモデル

14

認証

サービスの実行を承認するときの相互作用
s d サ ー ビ スの 実 行 を 承 認 す る

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

:サービス

ユーザA

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

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

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

図6

15

分析モデル

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

サービスの利用状況を監視するときの相互作用
s d サー ビ ス の 利 用 状 況 を 監 視 す る

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

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

ユーザA

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

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

実行権有り()

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

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

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

図7

機能に着目したモデル

16

認証

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..*-

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

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

ログオン成功ログオン失敗図8

17

PIM 設計モデル

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

-

サービス利用状況

図9

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

18

認証

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

19

分析モデル

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

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

図10

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

20

認証

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

図11

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

21

分析モデル

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

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

ユーザを認証するときの相互作用

図12

サービスを利用するときの相互作用

図13

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

22

認証

サービスの実行を承認するときの相互作用

図14

サービス利用状況を監視するときの相互作用

図15

23

分析モデル

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

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

静的モデル
分析モデルで出たクラスを、インタフェース・機能・データに当てはめると次のようになります。
「認証」「サービス利用」は、インタフェース＋機能「サービス利用監視」は、機能「アカウント」「サービス情報」「権限」「課計」「サービス利用ライセンス」は、データ

このため、「認証」と「サービス利用」は、それぞれ次のように責務を分離しました。
「認証窓口」「サービス利用窓口」「サービスプロキシ」は、インタフェース

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

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

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

24

認証

図16

25

PIM 設計モデル

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

図17

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

26:サービス利用窓口

認証サービスを利用するときの相互作用
sd シーケンス図

:ユーザ
1.0

:サービス利用窓口

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

1.2

:サービス利用

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

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

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

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

1.7

図18

27

PIM 設計モデル

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

サービスの実行を承認するときの相互作用
sd シーケンス図:サービス利:サービス利用窓口

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

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

:利用結果

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

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

る() :サービス名

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

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

用ライセンス

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

1.7

図19

サービス利用状況を監視するときの相互作用
sd シーケンス図:サービス利:サービス利:サービス利:サービス利:サービス利:サービス利:サービスプ用窓口

用用ライセンス

用情報

用監視

用量

ロキシ

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

1.1

:利用結果

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

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

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

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

る(利用結果コード)

図20

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

28

認証

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

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

ユーザ

認証
-

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

認証済みかどうか
*

1

-

権限
+所有権限

ユーザ名
パスワード

1

1

1

-

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

1

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

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

1

-

サービス名
利用量

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

*
承認

-

1

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

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

利用する

サー ビ ス

+サービス

-

サービス名

0..1

1

更新する

具象サー ビ ス

図21

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

29

分析モデル

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

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

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

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

サービス利用を終了する

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

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

サービス利用を終了する

サー ビ ス利用中

図22

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

状態に着目したモデル

30

認証

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

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

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

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

未認証
認証済

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

31

分析モデル

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

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

状態に着目したモデル

32

認証

静的モデル
c la s s PIMモ デ ル

ユーザ

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

-アカウントリスト

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

1

-

ユーザ名
パスワード

+
+
+

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

-認証

1

サービス名

1

1

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

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

1

サ ー ビ ス利 用 量
+

利用量

+

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

+
+
+

1
権限

-

+サービス利用量
未認証

+所有権限

権限の有無

1

認証済

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

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

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

サー ビ ス

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

-サービス

1
1

-

1 +
+

-サービス利用状態

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

具象サー ビ ス+

サ ー ビ ス未 利 用+++

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

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

1

図23

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

33

PIM 設計モデル

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

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

サー ビ スX権限 :権限

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

サー ビ スY 権限 :権限

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

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

:認証コ ン テ キ スト

:未認証

Aさ ん :ユ ー ザ

図24

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

状態に着目したモデル

34

認証

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

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

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

:認証コ ン テ キ スト

:認証済

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

:サー ビ ス未利用

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

:サー ビ ス未利用

図25

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

35

PIM 設計モデル

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

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

サー ビ スX権限 :権限

サー ビ スY 権限 :権限

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

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

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

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

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

:サー ビ ス利用中

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

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

:サー ビ ス未利用

図26

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

状態に着目したモデル

36

認証

動的モデル
ユーザを認証するときの相互作用
s d ユ ー ザを 認証す る
account :アカウント:ユーザ:認証コンテキスト:未認証

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

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

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

authenticated :認証済

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

:認証結果
:認証結果

図27

37

PIM 設計モデル

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

サービスを利用するときの相互作用
s d サー ビ ス を 利 用 す る:認証コンテキスト

authenticated :認証済

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

usingService :サー
ビス利用中

service :具象サービス

account :アカウント

:権限

ユーザ

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

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

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

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

:利用結果
:利用結果

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

:利用結果

:利用結果

:利用結果

図28

状態に着目したモデル

38

amount :サービス利用量

認証

サービスの実行を承認するときの相互作用
s d サー ビ ス 利 用 を 承 認 す る:サービス利用コンテキスト:サービス未利用

account :アカウント:権限

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

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

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

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

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

状態を設定する(usingService)

図29

サービス利用状況を監視するときの相互作用
s d サー ビ ス の利用を 監視す る
service :具象サービス

amount :サービス利用量

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

利用量更新(利用量)

図30

39

PIM 設計モデル

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

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