UMLによるシステム設計入門 - ncsj.jp · クラス図クラス図の構成要素クラス属性操作ステレオタイプインターフェーステンプレートクラス

UMLの基礎知識

UMLによるシステム設計入門

NCSJ NoviceClassSeminar-JavaProgrammer

directedco.,ltd.

UMLの概要

•  UML–  UnifiedModelingLanguage

•  統一モデル化言語–  OMGが標準として採用

•  www.uml.org–  モデリング言語の標準

•  ソフトウエア設計の記述言語として標準•  ISO/IEC19501:2005àUML1.4.2

•  OMG–  ObjectManagementGroup–  オブジェクト指向技術の標準化団体–  CORBAやMDA、UMLなど、オブジェクト指向技術の標準化を行う団体

•  www.omg.org

NCSJ2018 UMLの基礎知識 1

UMLの目標

•  モデル化言語–  わかりやすい図式化されたモデル化言語–  ユーザーと開発者とのコミュニケーションを助ける

•  主概念を提供するための機構–  拡張機構

•  既存の主概念では扱えない部分を拡張機構によりサポートする–  特化機構

•  特定のアプリケーション領域に合わせて概念・記法・制約を特化できる

•  言語／手法への非依存–  特定のプログラミング言語に依存しない–  開発手法に依存しない

•  表記法の統一–  方法論による異なる表記法を統一する

•  OMG :UML1.1•  ISO :UML1.4.2


オブジェクト指向の方法論

•  OMT–  ObjectModeloingTechnique（オブジェクトモデル化技法）–  JamesERumbaugh(GeneralElectric)–  モデル図の記法はUMLへ取り込まれる

•  Booch–  GradyBooch(RationalSoftware)–  モデル図のコンセプトは、UMLに反映される

•  OOSE–  ObjectOrientedSoftwareEngineering（オブジェクト指向ソフトウエア工学）–  IvarJacobson(Objectory)–  ユースケース主導によるソフトウエアの設計

•  Shlaer/Mellor–  SallyShlaer,StephenJMellor(ProjectTechnology)–  構造化分析・設計の弱点を克服するために提案された


UMLの開発経緯

•  スリー・アミーゴ　： UMLの開発者–  GradyBooch Booch–  JamesRumbaugh OMT–  IvarJacobson OOSE

•  1994年　UMLの開発開始–  RationalSoftware社により作業開始

•  1997年　UML1.1がOMGに採用される•  2005年　ISO/IECに採用される

–  ISO/IEC19501:2005InformationTechnology---OpenDistributedProcessing---UnifiedModelingLanguage(UML)Version1.4.2

•  2004年　UML2.0がOMGに採用される


UMLの内容

•  ビュー–  目的に応じたシステムの説明

•  厳密にはUMLの仕様に含まれていない–  複数のダイアグラムにより構成される–  システムの「４＋１ビュー」

•  設計ビュー DesignView•  配置ビュー DeploymentView•  実装ビュー ImplementationView•  プロセスビュー ProcessView•  ユースケースビュー UsecaseView

•  ダイアグラム–  モデリングのための図–  UML2.0では、ダイアグラムを２つに分類している

•  構造図 StructuralDiagram•  振る舞い図 BehavioralDiagram

•  ノート–  ダイアグラムに追加する情報を記述するための機構–  コメント

•  分類子と修飾–  分類子（Classifier）基本的なモデル要素　–  修飾（adornment）分類子に関連付ける追加情報


ダイアグラム

•  構造図　（ StructuralDiagram）–  クラス図 ClassDiagram–  コンポーネント図 ComponentDiagram–  コンポジット構造図 CompositeStructureDiagram–  配置図 DeploymentDiagram–  パッケージ図 PackageDiagram–  オブジェクト図 ObjectDiagram

•  振る舞い図　（ BehavioralDiagram ） –  アクティビティ図 ActivityDiagram–  コミュニケーション図 CommunicationDiagram–  相互作用概要図 InteractionOverviewDiagram–  シーケンス図 SequenceDiagram–  状態マシン図 StateMachineDiagram–  タイミング図 TimingDiagram–  ユースケース図 UseCaseDiagram


クラス図

•  クラス図の目的–  クラスの詳細の記述

•  クラスおよびインターフェースの詳細を記述

•  記述する内容–  名称–  属性–  操作–  ステレオタイプ

–  クラス同士の関係•  クラス同士の関係を記述•  所有の関係

–  関連・集約の関係•  継承の関係

–  汎化・実現の関係

ComponentDiagram

ClassDiagram

CompositeStructureDiagram

PackageDiagram

DeploymentDiagram

ObjectDiagram

CommunicationDiagram

ActivityDiagram

InteractionOverviewDiagram

StateMachineDiagram

SequenceDiagram

TimingDiagram

StructuralDiagram

sBe

havioralDiagram

s

UseCaseDiagram


pkg

Window

MyWindow

<<interface>>WindowListener

MyWindowListener

TextField

TextArea

TextComponent

クラス図

クラス図の例

クラス図の構成要素

クラ

ス

クラス

属性

操作

ステレオタイプ

インターフェース

テンプレートクラス

ネスティドクラス

関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現


クラス図クラス図の構成要素

クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

<<entity>>

+ get(field : String) : String+ getID() : int

- tel : String- address : String

+ set(id : int, name : String, address : String, tel : String) : void

- name : String- id : int

Member

クラスは矩形の図形で表現する。クラスではクラス名の他、以下の物を定義する。属性：　保持する情報操作：　機能の名称ステレオタイプ：　クラスの役割を表わすもの



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

<<entity>>





Member

属性　：　保持する情報の定義名称：　属性の名称型：　属性の型可視性：　属性のアクセス属性初期値：　属性の初期値

　　　　詳細は次頁


クラス図

•  属性の詳細（１）–  名称

•  属性に付ける名称•  プログラミング言語では変数名になる

–  型•  属性のタイプ•  プログラミング言語では、組み込み型またはクラスを含むユーザ定義型

–  可視性•  属性のアクセス属性を表わす•  +:public　　　-:private　　　#:protected　　　~:package

–  初期値•  属性の初期値

–  静的属性（static）•  staticと指定された属性は、インスタンス属性ではなく、クラス属性となる


クラス図

•  属性の詳細（２）–  多重度

•  属性の多重度•  配列を表現する場合などに使用する

–  派生•  派生属性を表わす•  属性名の先頭に“ /”を付加して表現する•  派生属性は、オプショナルな属性

–  プロパティ•  追加情報を記入するためのもの

–  readOnly–  union–  subsets–  redefines–  composite

–  制約•  属性に対する制約•  ブール式で評価されるものでなければならない

–  コレクション型•  特定の制約（順序付け、一意性）をコレクション型にマップすることができる•  UMLに用意されているコレクション型

–  Bag,OrderedSet,Set,Sequence



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

<<entity>>





Member

操作　：　クラスが備える機能　機能の呼び出し方を定義する。主な設定項目名称：　操作の名称型：　操作の型、終了時の戻り値パラメタ：　操作の実行時に与えるパラメータ可視性：　操作のアクセス属性


クラス図

•  操作（１）–  戻り値の型

•  操作が返す情報の型を指定する–  型は組み込み型、またはユーザー定義型（クラス）を指定できる–  何も情報を返さない場合は、“void”を指定する

–  静的操作•  指定されれば、“クラスの振る舞い”として機能する•  指定がなければ、インスタンスの機能

–  通常は“静的操作”ではない•  下線を使って静的操作であることを示すことがある

–  パラメータ•  操作へ渡す引数の定義•  型と名称を指定する•  多重度を指定することもできる•  パラメータに関するプロパティを指定できる

–  プロパティは｛から｝の間に記述する–  ordered,readOnly,uniqueなど


クラス図

•  操作（２）–  プロパティ

•  操作に関するプロパティを指定できる•  プロパティは｛から｝の間に記述する

–  制約•  操作の実装が満たさなければならない制約の規定•  事前条件

–  操作が呼び出される前のシステムの条件を規定する•  事後条件

–  操作が完了したのちのシステムの状態の定義•  本件条件

–  戻り値を制約する条件–  オーバーライドされた操作は、本件条件が異なる場合がある

•  クエリ操作–  属性を一切変更しない操作

•  例外–  操作によってスローされる例外–  スローする例外の明細は、ノートに記述することがある–  例外となるクラスへの依存を示すことがある



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

<<entity>>





Member

ステレオタイプ　クラスのステレオタイプ（通念）　エンティティ名は<<から>>の間に記述するステレオタイプの例　boundary,control,entity



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

+ count() : int+ list() : Enumeration+ load(cname : String) : Class

<<interface>>LoadManager

LoadManager

標準の表記アイコンでの表記

インターフェース　アイコンとして表記する場合もある　実装を持たない　属性と操作の定義はできる　実装する言語によってサポートが異なるので注意が必要



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

- count : int

+ inccrease() : int+ get() : int+ set(count : int) : void

Countervalue:int=0

テンプレートクラス　パラメータが与えられることで、別のクラスを生成するクラス　パラメータが与えられない限り、クラスとしては成立しない　パラメータはクラスの右上の点線で描かれた矩形の中に記

述される



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

ネスティッドクラス　（内部クラス、入れ子クラス）クラスの中で定義されるクラス。スコープは、クラスを定義しているクラス内に限定される。上の図では、クラスＡの中でクラスＢが定義されていることを表わしている。

A B



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

X Y

関連　クラスとクラスとの関連は、クラス同士を実線で結びつけて表現する。関連には、２つのクラスが関連する２項関連と、複数のクラスが関連するＮ項関連がある。関連に、“関連名”として名称を付加することもできる。


クラス同士の関連

X Y

1..*y

M

２項の関連

再帰的な関連

・２項の関連は、クラス同士を実線で結びつけて表わす・関連では、名称と関連の方向を表わすことができる・関連の多重度を定義することもできる

・再帰的な関連は、同じクラスを実線で結びつけて表わす・再帰的な関連でも、名称と関連の方向を表わすことができる・関連の多重度を定義することもできる


クラス同士の関連

LeaguePlayerTeam

Team

関連クラス（Ｎ項の関連）関連クラス２つのクラスの関係が、単純な直接的関係ではない場合がある。あるクラスを通して２つのクラスが関係する場合、関係クラスを用いて表現することができる。左の図では、PlayerとLeagueがTeamを通して関係していることを表現している。ここでは、Teamが関連クラスとして定義されている。


クラス同士の関係

Frame WindowEvent

依存の関係

クラス間の依存“依存”は、クラス間の関係としては関連よりも弱い関係である。あるクラスが、他のクラスを利用しているだけの場合、依存の関係といえる。

依存の表現方法依存の関係は、破線と矢印により表現される。上の図の例は、FrameクラスがWindowEventクラスに依存している様子を表わしている。依存として表現される関係ある操作を実行するときだけ関係し、クラスのインスタンスのライフサイクル全体を通して関係を保持するわけではない場合は、この依存の関係として表わされる。


ユーティリティクラス

<<utility>>

+ divide(x : int, y : int) : int+ multiple(x : int, y : int) : int+ minus(x : int, y : int) : int+ plus(x : int, y : int) : int

Calc

TotalCounter

ユーティリティクラス

ユーティリティとしての役割を果たすクラス　インスタンスとして存在することがないクラスで、操作のみを提供するクラス。　操作は“静的”なものだけが定義される。　使用するクラスからは、特定の操作の中から一時的に使うだけである。　使用するクラスからは、“依存”の関係として記述される。



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

X Y

1..*y

多重度の設定クラス間の量的な関係を示すそのクラスのインスタンスが、どれだけの範囲で所有されるのかを表わす。関連の線で、所有される側の端にて、量的範囲が示される。


クラス図

多重度の表現

X Y

1..*y

X Y

1y

X Y

*y

X Y- y- x

*1

多重度の種類　多重度の種類は以下のものがある１．固定　　1や10などの固定値を１つ示す２．範囲　　1..10、0..*などの範囲を示す３．複数　　範囲の定めがない場合は*で表現する

１．固定

２．範囲

３．複数

双方向の多重度

所有側：X　　XがYをyで所有している多重度多重度は*

所有側：Y　　YがXをxで所有している多重度多重度は1



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

X Y

X Y

誘導可能性（navigability）　クラス間の関係の一方向性を誘導可能性という。誘導可能性は、関連を示す実践の端に矢印（→）を記すことで表わす。

上記の図は、XからYへの誘導可能性を示している。

上記の図は、XからYへの誘導可能性と、YからXへの誘導はないことを示している。



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

- name : int- id : int

Employee Companyid : int

1

限定子（qualifier）限定子は、キーによってクラス間の関係が特定されることを表わす。上記の図では、CompanyがEmployeeをidによって１つ

に特定（＝限定）していることを表わしている。



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

集約（aggregation）基本的には関連であり、関連よりも強い関係がある場合に集約という。集約には、集約する側と集約されるとの方向がある。上図では、WalletがMoneyを集約していることを示している。

MoneyWallet



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

EngineVehicle

コンポジション（Composition）　コンポジション（包含）は、集約よりもさらに強い関連を示すものである。　コンポジションでは、所有される側は所有する側の一部分となっている。上図の例では、VehicleがEngineを包含（コンポジション）していることが示されている。



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

多重度

+ transport() : void

Transportation


Bus


Train

汎化（generalization）　複数のクラスから共通項を抽出して、新しいクラスを導き出すことを汎化という。　汎化の関係は、実線と白抜きの三角形（△の記号）で表わされる導き出されたクラスは、より一般的・抽象的なクラスとなる。汎化は、継承の関係も表わしている。



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現


Transportation

+ drive() : void+ transport() : void

Bus


Train

+ drive() : void

Vehicle

多重継承汎化により、多重継承を表現することもできる。上図の例では、VehicleとTransportationの２つのクラスを多重に継承してBusが定義されていることを表わしている。実装する言語によっては、多重継承は許されていないことに注意。



クラ

ス

クラス

属性

操作





関連

関連

多重度

誘導可能性

限定子

集約

コンポジット

関連

汎化

多重継承

実現

<<interface>>Printer

<<interface>>Facsimile

<<interface>>Telephone

PrintingDevice

インターフェースと実現　インターフェースを実現する場合は、インターフェースと実現するクラスの間を破線で結び、インターフェース側に白抜きの三角形（△）を記入し表わす。　上記の例では、PrintingDeviceがPrinterとFacsimileを実現

していることを表わしている。


コンポーネント図

•  コンポーネント図の目的–  システムの構成を表現する

•  実装の構成•  コンポーネント間の依存関係

–  システムの分割管理•  大規模なシステムの分割管理

–  コンポーネント・ビュー•  ブラックボックス・ビュー•  ホワイトボックス・ビュー

ComponentDiagram

ClassDiagram


PackageDiagram

DeploymentDiagram

ObjectDiagram


ActivityDiagram


StateMachineDiagram

SequenceDiagram

TimingDiagram

StructuralDiagram

sBe

havioralDiagram

s

UseCaseDiagram



•  コンポーネント–  システムの構成要素–  実行可能なパーツ–  実装の詳細は公開されない

–  提供インターフェース•  提供する機能は、「提供インターフェース」として公開される

–  要求インターフェース•  コンポーネントが機能実現のために必要とするインターフェース

<<component>>MemberList



•  コンポーネントの依存–  コンポーネント間の依存関係

コンポーネント間の依存関係は、破線と矢印で表わす。依存している側から、依存されている側が矢印の方向によって示される。左の例では、AuctionServiceがSignInManagerとAccountManagerに依存していることが示されている。

<<component>>AuctionService

<<component>>SignInManager

<<component>>AccountManager



•  アセンブリ・コネクター（assemblyconnector）–  コンポーネント同士を接続するインターフェースを表現する。–  提供インターフェース

•  提供インターフェースの表記には、丸型のボール・アイコンを使用する。

–  要求インターフェース•  要求インターフェースの表記には、半球型のソケット・アイコンを使用する。

<<component>>LogInManager

LoginService

<<component>>ServiceLoginForm

LoginService



•  コンポーネントのビュー–  ブラックボックス・ビュー

<<component>>LogInManager

LoginService

<<component>>ServiceLoginForm

LoginService

ブラックボックスビューの例コンポーネントが、要求しているインターフェースを実現しているコンポーネントを使用していることを示している例。　コンポーネントのブラックボックス・ビューを表わす時には、アセンブリ・コネクター（assemblyconnector）を使い、要求インターフェースと提供インターフェースとを明記する。上記の例では、LogInManagerが、LoginServiceインターフェースを要求し、LoginServiceを実現しているServiceLoginFormが使用されていることを示している。


コンポーネント図•  インターフェースの依存の表現

–  コンポーネントが実現するインターフェースを記述する–  コンポーネントが依存（要求）するインターフェースを明らかにする

<<component>>DataBaseDriver

<<interface>>DataBaseConnection

<<component>>MemberList

依存関係を示す

実現を表わす



•  コンポーネントのビュー–  ホワイトボックス・ビュー

<<component>>AccountManager

Account OrderOrderHistory

コンポーネントを構成している３つのクラスを示している例。コンポーネントの構造が複雑な場合は、クラス図でもって表わ

すのが一般的である。



•  ポート–  UML2.0で導入された概念–  外部に公開される機能を明示的に識別するためのもの

<<component>>DataBaseManager

DataBaseService

LogServiceDBA

SQLConsole

ポートコンポーネントに備わるポートは、□で表わされる。



•  コンポーネントのステレオタイプ（１）–  コンポーネントに適用されるステレオタイプが定義されている。

–  entity•  ビジネス上の概念を表わすコンポーネント。•  永続化されるユーザ定義型。

–  process•  ステートフルなトランザクションに基づく、機能を実現・提供す

るコンポーネント。•  状態との関連付けがなされる。

–  realization•  specificationを実現（realization）するコンポーネント。独自の

仕様は特には持たない。



•  コンポーネントのステレオタイプ（２）–  service

•  機能を提供するステートレスなコンポーネント。

–  specification•  提供／要求インターフェースは持つものの、実装は持たない。•  実装は、realizationのコンポーネントにて行われる。

–  subsystem•  システムの一部分となるような、比較的大きなコンポーネント。•  基本的には、自己完結したコンポーネントとなる。


コンポジット構造図

•  コンポジット構造図とは–  UML2.0から導入

•  システムの複雑さに対応

–  コンポジット構造•  ある機能を実現するために実行時に存在する

相互接続された要素の集まり

–  要素間の複雑な関係を形式化•  システム内の要素の組み合わせを表現する•  機能の観点から、システムを分解する

–  クラス図とコンポーネント図をリンクする•  設計の詳細に力点を置かない•  実装には力点を置かない

ComponentDiagram

ClassDiagram


PackageDiagram

DeploymentDiagram

ObjectDiagram


ActivityDiagram


StateMachineDiagram

SequenceDiagram

TimingDiagram

StructuralDiagram

sBe

havioralDiagram

s

UseCaseDiagram



•  構造とコネクタ

ペダル車輪C:チェーン

構造　機能を提供するために存在する相互接続された要素の集まりのことをいう。オブジェクト同士の関係や、通信などが示される。　UMLでは、内部構造（internalstructure）という。コネクタ（connector）　コネクタは、関係しているオブジェクト間の通信を表わしている。　上記の例では、ペダルと車輪がチェーンでつながっていることを示している。



•  ポート

ポート（port）　機能の実現方法の詳細を公開することなく、コンポジット構造から機能を提供するための方法要求インターフェース（requiredinterface）と提供インターフェース（providedinterface）　ポートは要求インターフェースと提供インターフェースとに関連付けられる。　上記の例では、AuctionSystemはAuctionServiceのポートを通じてBuyProcessorとSellProcessorとの２つのインターフェースを提供し、また匿名のポートがSignInServiceインターフェースを要求している。

AuctionSystem

BuyProcessor,SellProcessorSignInService

AuctionService



•  ポートの実現

LogServiceManager

LogServiceImpl FileIOLogService

LogServiceManager

LogService

LoginCheck

振る舞いポート　ポートを所有する分類子がポートを実装しているとき、そのポートを「振る舞いポート」という。　この場合、ポートは内部の状態に、コネクタにより結び付けられる。

内部の分類子に接続されるポート　ポートが提供する機能を内部の分類子が実現している場合、ポートは内部の分類子に、コネクタにより結び付けられる。　コンポーネントやサブシステムの構造を示すコンポジット構造図で使用される。



–  ポートの多重度•  ポートでは多重度を設定することができる。•  多重度は、[と]で括られた中に数値を示すことで表わされる。

–  相互作用点•  ポートを所有する分類子がインスタンス化されるときに、ポートもインスタンス化される。•  分類子は、多重化されたどのポートが使用されているのかを識別することができる。

LogServiceManager

LogService[10]



•  コンポジット構造図–  ポートの型定義

LogServiceManager

LogService : ILogService[10]

ポートの型定義を明確に示すこともできる。　上図の例では、“LogService”ポートが“ILogService”という型（クラス）であることを示している。　クラスとして示すことで、ポートのより複雑な振る舞いや構造を説明することができるようになる。



•  コンポジット構造図–  プロパティ

•  コンポジット構造にて、“全体と部分”の関係での“部分”を示すためのもの

Window

ButtonDialogBox 2

左の例では、Windowと関連しているDialogBox、ダイアログボックスと、DialogBoxとコンポジションの関係にあるButtonが表現されている。DialogBoxはWindowに所有されていないので、

矩形の上部は破線で描かれる。


配置図

•  配置図の目的–  ハードウエアのマッピング

•  実行するハードウエアの明確化•  配置仕様の明確化•  ハードウエア仕様の定義

–  コミュニケーションパス•  ノード間の通信を表現する•  ネットワーク構成を表現する

ComponentDiagram

ClassDiagram


PackageDiagram

DeploymentDiagram

ObjectDiagram


ActivityDiagram


StateMachineDiagram

SequenceDiagram

TimingDiagram

StructuralDiagram

sBe

havioralDiagram

s

UseCaseDiagram


配置図

•  配置図の構成要素

HTTP SERVER

ClientForm

ノードシステムを構成するハードウエア

コンポーネントシステムを構成するソフトウエアコンポーネント

成果物

成果物（artifact）ソフトウエア開発プロセスにおける情報の物理的な要素。ソースファイルや実行ファイル、ドキュメントやHTMLファイル、XMLファイルなどがある。


配置図

•  配置図の例１–  システム構成を示す配置図

HTTP SERVER DATABASE SERVERWebBrowser

HTTPこの間の通信は、HTTPである。

JDBCWebサーバーとデータベースサーバーの間のコミュニケーション

は、JDBCを介して行われる。


配置図

•  配置図の例２– コンポーネントの配置

Client

ClientForm

Server

Logic2

Logic1

DataBase Server

Member DB

RMI JDBC


パッケージ図

•  パッケージ図の目的–  UML要素同士のグループ化

•  クラス、インターフェースなどをグループ（パッケージ）化する

•  パッケージに名前を付ける

–  スコープの明確化•  同じパッケージでは、パッケージを明示せずに、

要素を指定できる•  異なるパッケージでは、パッケージ名を明示し

て要素を指定する

–  システム開発の管理•  プロジェクトの構造化

–  クラスパッケージ•  機能的な振る舞いの整理

–  ユースケースパッケージ•  プロジェクの各タスクの検証

–  有向依存グラフ

ComponentDiagram

ClassDiagram


PackageDiagram

DeploymentDiagram

ObjectDiagram


ActivityDiagram


StateMachineDiagram

SequenceDiagram

TimingDiagram

StructuralDiagram

sBe

havioralDiagram

s

UseCaseDiagram


パッケージ図

•  パッケージ図の構成要素

パッケージパッケージ　パッケージは、クラスやインターフェースなどの要素を分類する方法を提供するものである。　パッケージには、名前を明記する。パッケージとスコープ　パッケージに分類されると、分類された要素はスコープを規定される。

パッケージ

クラス


パッケージ図

•  可視性

Ｕｔｉｌｉｔｙ

－クラス

＋クラス

パッケージ内部に存在するクラスには、アクセス属性を指定し、可視性を設定することができる。指定できるアクセス属性は以下の２通りである。　　＋　：　（public）　パッケージ外に公開される　　―　：　（private）　パッケージ内でのみ使用可能

・可視性の指定は、クラス名の前で、+/-が表示される


パッケージ図

•  パッケージ間の関係

http io<<import>>

http net<<access>>

インポート　インポートの指定をすることで、他のパッケージに含まれるクラスを、パッケージ名の指定をしなくとも利用できるようになる。

アクセス　アクセスの指定をすることで、インポートの時と同様に、他のパッケージに含まれるクラスを、パッケージ名の指定をしなくとも利用できるようになる。ただし、アクセスでは指定したパッケージのクラスをprivateとして扱うようになる。


パッケージ図

•  パッケージのマージ

TechnicalSupport

SalesSupport

Support

<<marge>>

<<marge>>

パッケージをマージすることで、別のパッケージで定義されている内容を利用することができるようになる。マージされるパッケージに、同じ名称の要素（クラス）が定義されている場合、マージするクラスでそれを拡張し定義することになる。

マージは、マージする側からマージされる側への、破線と矢印によって示す。


パッケージ図•  ユースケースとパッケージ

システム管理

ユーザー管理

データ登録

製品検索

⾒積作成

システム管理者

利⽤者

販売担当者

システムの分析時に、機能的な振る舞いを整理するために、ユースケースとパッケージとを利用することがある。ユースケース・パッケージは、プロジェクト管

理のツールとして利用されることがある。


パッケージ図

•  依存関係– 有向グラフを使用した依存関係の図示

http

io

net

DB Connection

Client Application

有向グラフを利用することで、パッケージ間の依存関係を明確にすることができる。


オブジェクト図

•  オブジェクト図の目的–  実行時のオブジェクト同士の関係を表現–  クラスの実行時の構造を明確化

–  クラス図と同じ構文を使用する

ComponentDiagram

ClassDiagram


PackageDiagram

DeploymentDiagram

ObjectDiagram


ActivityDiagram


StateMachineDiagram

SequenceDiagram

TimingDiagram

StructuralDiagram

sBe

havioralDiagram

s

UseCaseDiagram


クラス図


•  オブジェクト図の例

Owner Car

0..*


Ｍｉｃｈａｅｌ：Owner

Ferrari：Car

Mercedes：Car

オブジェクト図では、実行時のインスタンス同士の構造上の関係を示す。


アクティビティ図

•  アクティビティ図の目的–  “振る舞い”のフローを記述

•  ソフトウエアの機能が行う処理のフローを記述する

–  オブジェクトフローの記述•  アクション間のオブジェクトの受け渡しに伴う

フローを記述–  ソフトウエア以外のフローの記述

•  ビジネスプロセス•  ワークフロー

•  アクティビティ–  複数のアクションから構成される一連の処

理フロー–  アクション

•  処理を行っている状態•  他のアクティビティをアクションとして呼び出す

こともある

ComponentDiagram

ClassDiagram


PackageDiagram

DeploymentDiagram

ObjectDiagram


ActivityDiagram


StateMachineDiagram

SequenceDiagram

TimingDiagram

StructuralDiagram

sBe

havioralDiagram

s

UseCaseDiagram



•  アクティビティ図の構成要素（１）

開始ノード一連の手続きが開始されるところ

アクション実行される処理

終了ノード一連の手続きが終了するところ

制御フロー手続きの流れを示す

ディシジョンノード、マージノード分岐および合流を示す

ガード条件分岐したフローの条件



•  アクティビティ図の構成要素（２）

<<signal sending>>

<<signal receipt>>

パーティション1 パーティション2

振る舞い呼び出しアクション

イベント受理アクションイベントの発生を受けて実行される（UML2.0の仕様では、アイコンの向きが反対）

シグナル送信アクションシグナルを送信する

オブジェクトノードアクティビティの中で受け渡されるデータを表わす

フォークノード、ジョインノード並列して実行されるフローの分岐点・結合点を示す

振る舞い呼び出しアクション外部で定義されているアクティビティ

アクティビティパーティションロール毎にアクティビテイを分割するパーティション


アクティビティ図•  基本的な制御フロー

–  単純なビデオカメラのアクティビティ

録画

初期設定

保存

開始ノードここからアクティビティは開始される

アクションアクションでは、処理の内容が示される

遷移処理の遷移と方向は、実践と矢印で示される

終了ノードアクションの終了は、終了ノードで示される


初期設定

メディアの確認

エラー通知

録画

保存

[エラー][エラーなし]

アクティビティ図•  判断が入る制御フロー

–  メディアの確認を行うビデオカメラの録画–  ディシジョンノードとマージノードの使用例

ディシジョンノードここでメディアの確認で、エラーがあった場合の分岐を示す

マージノードここで分岐したフローが、もとのフローに結合されることを示す

ガード分岐したフローが対応する条件を示す


初期設定

メディアの確認

録画

保存

[エラーなし]

<<signal receipt>>メディアの挿入を待つ

<<signal sending>>メディア交換を促す

経過時間確認

メディア挿入確認[２分未経過]

[未挿入]

[挿入確認]

[２分経過]

アクティビティ図•  判断が入る制御フロー

–  メディアの確認と自動電源OFF行うビデオカメラの録画動作–  シグナルの使用例

ディシジョンノードここでメディアの確認で、エラーがあった場合の分岐を示す

マージノードここで分岐したフローが、もとのフローに結合されることを示す


アクティビティ図•  同期バー

–  同期バーは、並行して動作する処理の起動と結合を表わすために使用する。

–  並行して動作する処理の起動を「フォーク」という–  並行して動作している処理が結合することを「ジョイン」という印刷の指示

印刷データの生成

作業画面の表示印刷の実行

印刷完了の通知

フォークノードフォークノードでは、並列処理の起動を表わす

ジョインノードジョインノードでは、並列処理の結合を表わす


アクティビティ図•  オブジェクトノードとオブジェクトフロー

–  顧客情報を登録するときのフロー–  アクションにて生成されるオブジェクトとその受け渡しを記述した例

顧客データの入力

顧客データの登録

[未登録]顧客データ

顧客一覧

顧客一覧の表示

オブジェクトノードオブジェクトノードでは、アクション間で受け渡されるデータを表現することができる。



•  ピン（ pin ）–  オブジェクトノードの特別な表記法–  アクションへの入出力を簡潔に表現する–  長方形で表記する

•  ピンの種類–  入力ピン（inputpin）

•  アクションへの入力を示す–  出力ピン（outputpin）

•  アクションからの出力を示す–  例外ピン（exceptionpin）

•  ピンがエラー状態（例外）と関係している場合–  値ピン（valuepin）

•  入力データの仕様を明記するのに用いる

発注処理受注処理Order Order

入力ピン

出力ピン



•  アクティビティパーティション–  activitypartition–  スイムレーン

–  水平、または垂直に分ける–  アクションの実行主体によって

分類する

プリンタワードプロセッサ

印刷指示

印刷データ

印刷処理通常処理

<<signal sending>>印刷完了通知

<<signal receipt>>印刷完了待ち

完了メッセージ


アクティビティ図•  例外処理

ファイルを指定

ファイルを開く

ファイルを読み込むエラーを通知する

FileNotFound例外ハンドラ　例外ハンドラは、アクションに小さい四角を付加して表記する。　例外を処理するアクションと、例外の型を示す。

例外　例外は例外ハンドラとなるアクションと結び付けて、例外が発生した時の処理を明記する。　例外が発生すると、その後の通常の処理には遷移せず、中断される。



録画を予約する




拡張領域拡張領域は、コレクションであるデータを受け付け、また出力するアクションを定義できる。・拡張領域の表記は、拡張領域の中で実行されるア

クションを破線で囲う。・コレクションの表記は、ピンを４つ並べて示す。



•  ループ–  ループノードによりループを表現することができる

•  ループノード–  ループノードは、以下の３つのサブ領域から構成される–  セットアップ：　ループに入る前に１度だけ実行される–  ボディ：　繰り返し実行されるループの本体–  テスト：　ループを継続する条件

セットアップ

ボディ[true]

[false]

テスト

単一のノードでの表記

セットアップ

ボディ

テスト



•  ストリーム–  入力を受け付けながら、出力も行う処理をストリームという

•  ストリームの表現–  アクティビティ図でのストリームの表現は、以下の２通り

•  入出力のピンに｛stream｝と表記する•  ピンを表現する四角形を、■で表記する

ファイルの読み込み画面に表示ファイル

バイトコード文字

ファイルの読み込み画面に表示ファイル

バイトコード文字

{stream} {stream}



•  割り込み可能アクティビティ領域–  処理の中断をサポートできる領域を示す

妥当性のチェックファイルの読み込み

<<signal receipt>>キャンセル要求

内容の表示

キャンセル表示

割り込み可能アクティビティ領域　破線で示す領域が、割り込み可能アクティビティ領域となる



•  特殊なノード

•  中央バッファノード–  ノードの一種–  オブジェクト間で受け渡されるデータを

キューイングするためのもの

•  データストアノード–  特殊な中央バッファノード–  通過するデータをすべてコピーする

<<centralBuffer>>PrintQueue

<<datastore>>DBManager


コミュニケーション図

•  コミュニケーション図とは–  UML2.0以降–  以前は“コラボレーション図”と呼ばれてい

た–  相互作用を記述する図の１つ

•  コミュニケーション図の目的–  オブジェクト間のコミュニケーションを明確

にする–  メッセージの順序よりも、オブジェクト自体

に注目する–  コミュニケーションを行う実態となるオブジェ

クトを見出す

ComponentDiagram

ClassDiagram


PackageDiagram

DeploymentDiagram

ObjectDiagram


ActivityDiagram


StateMachineDiagram

SequenceDiagram

TimingDiagram

StructuralDiagram

sBe

havioralDiagram

s

UseCaseDiagram


コミュニケーション図•  コミュニケーション図の構成要素

利用者 : アクター

<<control>>userProc : Processor

<<entity>>userData : Data

<<boundary>>userForm : Form

1: データ入力()

2: 設定()

3: 登録依頼()

4: 取得()

アクター実現される機能を利用する外部の存在アクターは、システムの外部から機能を利用する存在であり、必ずしも人である必要はない。アクターは、通常ユースケースで定義される。








2: 設定()

3: 登録依頼()

4: 取得()

ライフラインアクターあるいは他のライフラインとコミュニケーションする実体。ライフラインは、クラスがインスタンス化されたものであり、ライフラインを考案することで、クラスの定義をすることができる。








2: 設定()

3: 登録依頼()

4: 取得()

メッセージライフライン間でやりとりされるメッセージメッセージではメッセージ名と方向を指定する。その他、メッセージと同時に送る情報をパラメータとして定義することができる。メッセージは、そのメッセージを受けるライフラインを定義しているクラスが備える

べき操作を明確にする。


コミュニケーション図

メッセージの種類–  同期メッセージ

•  処理が完了するまで、次のメッセージには遷移しないタイプのメッセージ。

•  通常、メッセージはこの同期メッセージである。

–  非同期メッセージ•  処理が終わるかどうかにかかわらず、次のメッセージに遷

移する。•  プロセスやスレッドなどを起動したときは、この非同期メッセ

時として実行される。

–  戻りメッセージ•  他のメッセージによて呼び出され、終了するタイミングを明

記する場合に使用する。


コミュニケーション図•  メッセージの引数と戻り値

–  ライフライン間のメッセージの仕様は、引数と戻り値を定義することで、明確にできる。

Manager list : MyList

5: add(o:Object) : int

引数　　　型：Object　　引数名：o戻り値　　型：int


相互作用概要図

•  相互作用概要図の目的–  複数のアクティビティの概要を表わす–  相互作用間の関係を明確にする

ComponentDiagram

ClassDiagram


PackageDiagram

DeploymentDiagram

ObjectDiagram


ActivityDiagram


StateMachineDiagram

SequenceDiagram

TimingDiagram

StructuralDiagram

sBe

havioralDiagram

s

UseCaseDiagram


相互作用概要図•  相互作用概要図の例

口座振り込みのシーケンス図sd

: ユーザー

振り込み先口座取引履歴口座ＡＴＭ

1: 振り込み()

1.1: 引き落とし()

1.3: 取引内容の記録()

flag

1.2: [flag == treu] 払込()

新規ドキュメント作成のシーケンス図sd

: ユーザー

ドキュメント

ワードプロセッサー

1: 新規作成() <<create>>1.1: 新規ドキュメント()

2: 文書作成()2.1: 書き込み()

3: 終了()3.1: 保存()

<<destroy>>3.2: 破棄()


シーケンス図

•  シーケンス図の目的–  オブジェクト間のメッセージのやりとり

を明確化–  メッセージの順序を明確化–  相互作用図の１つ

ComponentDiagram

ClassDiagram


PackageDiagram

DeploymentDiagram

ObjectDiagram


ActivityDiagram


StateMachineDiagram

SequenceDiagram

TimingDiagram

StructuralDiagram

sBe

havioralDiagram

s

UseCaseDiagram


シーケンス図•  シーケンス図の構成要素

–  アクター

: 観客

座席データベース座席予約画面チケットカウンター

1: チケット要求()1.1: 空席確認()

1.1.1: 座席状況一覧()

2: 支払い()2.1: 座席確保()

2.1.1: 登録()

アクターの役割アクターは、一連のシーケンスを起動するシステムの外部に存在するものである。シーケンス図の中では、ライフラインの１つとしての役割を果たす。



–  ライフライン

: 観客




2: 支払い()2.1: 座席確保()

2.1.1: 登録()

ライフラインライフラインは、相互作用に関係するオブジェクトである。ライフラインは、その名称が示し

ている通り、オブジェクトが生存している期間を示していることがある。



–  メッセージ

: 観客




2: 支払い()2.1: 座席確保()

2.1.1: 登録()

メッセージライフライン間で行われるコミュニケーションは、メッセージによって表わされる。シーケンス図では、メッセージは

より上に位置するものから実行される。通常は、左側のライフラインからより右に位置するライフラインへとメッセージが送られる。メッセージでは、同時に送られる

引数を記すこともできる。戻り値は、“戻りメッセージ”として記述される。


シーケンス図

•  メッセージの種類–  同期メッセージ

•  処理が完了しなければ、次のメッセージへ遷移しないものをいう•  通常のメッセージは、同期メッセージである•  同期メッセージは、　　　で表記する

–  非同期メッセージ•  処理の完了を待たずに、次のメッセージの実行へ遷移するもの•  非同期メッセージの表記は、「→」で行う。

–  戻りメッセージ•  メッセージに戻り値がある場合は、戻りメッセージを使用する。•  戻りメッセージは破線と矢印で表記する。



–  実行指定

: 観客




2: 支払い()2.1: 座席確保()

2.1.1: 登録()

実行指定メッセージを受けたライフラインが実行している処理とその期間を示すものを、実行指定という。おなじライフライン上にいくつかの実行指定が存在する場合はある。


シーケンス図•  オブジェクトの生成と破棄

新規ドキュメント作成のシーケンス図sd

: ユーザー

ドキュメント

ワードプロセッサー

1: 新規作成() <<create>>1.1: 新規ドキュメント()

2: 文書作成()2.1: 書き込み()

3: 終了()3.1: 保存()

<<destroy>>3.2: 破棄()

生成メッセージ生成メッセージにより、新しいオブジェクト（ライフライン）が作られたことを示す。

破棄メッセージ破棄メッセージにより、オブジェクト（ライフライン）が破棄され、終了したことを示す。


シーケンス図•  状態不変式

シーケンス図0sd

: 観客


1: チケット要求()


2: 支払い()2.1: 座席確保()

2.1.1: 登録()

{t .. t + 3}

1.1: 空席確認()

空席あり

t = now

不変条件式ライフラインにラベルを付けて、ライフラインの論理条件を示すことができる。不変条件式は、通常ブール式で表現するが、左図のようにステートマシン図で詳細を表現することもできる。


シーケンス図•  相互作用フラグメント


: ユーザー


1: 振り込み()


1.2: 払込()


相互作用フラグメントは、不可分な一連の相互作用のことをいう。上記の図では、矩形で括られた部分の一連の処理は、１つのトランザクションとして不可分な部分である。


シーケンス図•  複合フラグメント


: ユーザー


1: 振り込み()


1.2: 払込()


[支払 == true]

critical

複合フラグメントでは、関連する１つ以上の相互作用フラグメントを１つのまとまりとする機構を提供する。これを相互作用オペランドという。複合フラグメントに収められた相互作用フラグメントがどのようなものなのかは、複合フラグメントの左上に示される「相互作用演算子」が表わす。


シーケンス図•  相互作用演算子の種類（１）

–  オルタナティブ（alternative）•  複数の相互作用オペランドがあり、各オペランドにはガード条件が示されている。この

ガード条件により、実行する処理が選択されるものをいう。•  表記　：　alt

–  オプション（option）•  ガード条件が真（true）である場合に実行される相互作用フラグメントのこと。•  表記　：　opt

–  ブレイク（break）•  関連する相互作用フラグメントのオペランドが終了すると、それを含む相互作用が終了

するもののこと。•  表記　：　break

–  パラレル（parallel）•  関連する相互作用フラグメントがマージされ、並行して実行されるもの。•  表記　：　par

–  弱シーケンス（weaksequence）•  複数のオペランドのイベントを、交互に重ねて実行できる。•  表記　：　seq

–  強シーケンス（strictsequence）•  複数のオペランドのイベントの実行が、必ず上から下への順で実行される。•  表記　：　strict


シーケンス図•  相互作用演算子の種類（２）

–  否定（negative）•  不正なオペランドを指定するのに用いる。実行されることはない。•  表記　：　neg

–  クリティカル領域（criticalregion）•  不可分な相互作用オペランドを指定する。•  表記　：　critical

–  有効（consider）•  関係のあるメッセージを明示する。•  表記　：　consider{message,message,…}

–  無効（ignore）•  無視すべきメッセージを指定する。•  表記　：　ignore{message,message,…}

–  アサーション（assertion）•  唯一の妥当な実行パスであることを示す。•  表記　：　assert

–  ループ（loop）•  指定された範囲で繰り返すオペランドであることを示す。•  表記　：　loop(min,max)


シーケンス図•  ガード条件

: ユーザー


1: 振り込み()



flag

1.2: [flag == treu] 払込()

ガード条件は、その処理がどのような条件の時に実行可能かを示す。ガード条件はブール式で表記する。


シーケンス図•  時間指定

: 観客


1: チケット要求()


2: 支払い()2.1: 座席確保()

2.1.1: 登録()

{t .. t + 3}

1.1: 空席確認() t = now

時間制限の設定変数と、ガード条件を利用することで、時間制限を設定することができる。


ステートマシン図

•  ステートマシン図とは–  UML2.0以降–  以前はステートチャート図

•  DavidHarelのステートチャートを拡張したもの

•  ステートマシーン図の目的–  オブジェクトの内部的な状態の遷移を表わ

す–  外部エンティティとの通信をモデリングする

•  UMLのステートマシン–  振る舞いステートマシン

•  オブジェクトの振る舞いを示す–  プロトコル状態マシン

•  プロトコルの振る舞いを示す•  実装には結び付けられない

ComponentDiagram

ClassDiagram


PackageDiagram

DeploymentDiagram

ObjectDiagram


ActivityDiagram


StateMachineDiagram

SequenceDiagram

TimingDiagram

StructuralDiagram

sBe

havioralDiagram

s

UseCaseDiagram



•  振る舞いステートマシンビデオカメラstm

初期化中

待機中録画中

保存中

初期化完了

録画開始

録画完了

終了

終了

振る舞いステートマシンステート（状態）マシン図では、システムの構成要素の振る舞いを図で示す。状態マシンの名称は、図の左上に示されるが、省略することも可能である。ステートマシンは他のクラスやサブシステムなどの分類子と関連付けられるが、UML2.0では関連付けのためのメカニズムを提供していない。関連を明確に表記するには、ノートを使って記述することになる。



•  状態ビデオカメラstm

初期化中

待機中録画中

保存中

初期化完了

録画開始

録画完了

終了

終了

状態状態は、分類子のインスタンスが動作中の特定の条件がなりたっている期間をモデル化したものである。もっとも簡単な状態の表記では、状態の名称を記す。名称のほかに、内部の区画でアクティビティや遷移を示すこともできる。



•  状態

イベント２ [条件２] / 動作２イベント１ [条件１] / 動作１exit / 退場時の動作do / 実行活動entry / 入場時の動作

状態の名称名前区画状態の名称を記入する区画

内部アクティビティ区画内部でのアクティビティを記入する区画。アクティビティには、以下の３つがある。　・entry ：　入場時動作　・do ：　実行活動　・exit ：　退場時動作

内部遷移区画内部での状態遷移とその契機となるイベントを表記する区画。イベントと条件、動作の名称を記入する。


ステートマシン図•  コンポジット状態

チケット販売

受け付け中会計中空席確認中

include / チケット販売

チケット販売

チケット販売stm

チケット販売

受け付け中会計中空席確認中

コンポジット状態の表現コンポジット状態とは、その中に１つ以上の領域を持つ状態である。左図は、状態の中に１つの領域を持っている例である。

コンポジット状態の簡易表現コンポジット状態の簡易な表現方法も用意されている。左図のように、コンポジット状態であることを示すアイコンを用いて、状態が領域を持っていることを示し、詳細は別のダイアグラムにて記述することもできる。



チケット販売

清算中締め処理中

空席確認中会計中受け付け中

複数の領域をもつコンポジット状態状態が複数の領域を持つ場合は、破線で領域を区切る。破線の向きは、縦でも横でも構わない。直交状態ここでの例のように、２つ以上の領域をもつコンポジット状態を直交状態ともいう。



チケット販売

清算中締め処理中

空席確認中会計中受け付け中

サブ状態状態の中で定義される状態を、サブ状態という。直接サブ状態他のサブ状態に含まれていないものを、直接サブ状態という。間接サブ状態他のサブ状態に含まれているサブ状態は、間接サブ状態という。これは結果的に再帰することになる。


ステートマシン図•  サブマシン状態

空席確認中 : 空席確認SMチケット請求中

空席なし

チケット発行中

会計中

サブマシン状態は、状態の中で他のステートマシンを参照することである。UMLではサブマシン状態を、状態と遷移を再利用できるようにカプセル化したものとして定義している。参照されるステートマシンは、状態名の後の：（コロン）に続けて、名称を指定する。

空席確認中 : 空席確認SM

サブマシン状態を、コンポジットアイコンを示した状態として表記することもできる。


ステートマシン図•  疑似状態

–  pseudostate–  開始や終点、フォークやジョインなど、遷移の動作を記述するための

特殊な状態–  UML2.0では以下のものが用意されている

•  開始擬似状態　● ステートマシンの開始点•  選択　ガード条件に基づいた分岐•  深い履歴状態の領域内で使用される復帰点•  浅い履歴直前の状態の復帰点•  入場点コンポジット状態へ遷移するときの遷移先•  退場点コンポジット状態へ遷移するときの遷移先•  フォーク直交状態への分岐点

•  ジョイン直交状態からの合流点

•  ジャンクション　● 複数の遷移を１つに結合する•  終点ノード　× ステートマシンを終了する•  終了擬似状態　ステートマシンの終了


ステートマシン図•  遷移

ビデオカメラstm

初期化中

待機中録画中

保存中

初期化完了

録画開始

録画完了

終了

終了

遷移状態の遷移は、→で状態を接続することで表わす。状態の遷移が起こるイベントを遷移とともに記すこともできる。遷移の種類遷移には以下の４つがあるが、表記上の差異は規定されていない。　・複合遷移　・上位遷移　・内部遷移　・完了遷移



•  遷移の種類– 複合遷移•  ある状態から別の状態への遷移

– 上位遷移•  コンポジット状態からの遷移

– 内部遷移•  コンポジット状態内での遷移

– 完了遷移•  明示的なトリガーを持たない状態からの遷移



•  プロトコルステートマシン–  プロトコルの振る舞いを表現するためのもの–  プロトコルに則った通信における状態変化やイベントを定義す

る•  通信の実装を定義するわけではない

–  プロトコルステートマシンの特徴•  アクティビティ（entry,exit,do）は使用できない•  状態が状態不変式を持つ•  プロトコルステートマシンであることを明記するため、{protocol}をダイ

アグラムのタイトルに記入する•  遷移は、事前条件、トリガーイベント、事後条件を持つ

–  表記方法　：　[事前条件]　イベント /[事後条件]•  各遷移は分類子の操作（１つ）に関連付けることができる•  プロトコルの遷移について、作用アクティビティは指定されない


ステートマシン図•  プロトコルステートマシン

SMTPメール送信 {protocol}stm

初期状態

接続状態本文送信中

受信確認

接続要求 [OK]

アドレス確認 [OK]

送信完了 [OK]


タイミング図

•  タイミング図–  UML2.0以降–  ライフラインの状態変化を時間軸

にそって表現する–  メッセージのタイミングの詳細を表

現する

•  タイミング図の目的–  リアルタイムシステムのモデリング–  メッセージの処理時間–  応答時間–  割り込み処理

ComponentDiagram

ClassDiagram


PackageDiagram

DeploymentDiagram

ObjectDiagram


ActivityDiagram


StateMachineDiagram

SequenceDiagram

TimingDiagram

StructuralDiagram

sBe

havioralDiagram

s

UseCaseDiagram


タイミング図•  タイミング図の例

SMTP送信:Ｍ

ＴＡ

（MailTransferA

gent

）

接続状態

初期状態

本文送信中

受信確認

接続要求

送信

接続解除

12345　　　　t

{t..t+100}



SMTP送信:Ｍ

ＴＡ

（MailTransferA

gent

）

接続状態

初期状態

本文送信中

受信確認

接続要求

送信

接続解除

12345　　　　t

{t..t+100}

ライフライン

状態



SMTP送信:Ｍ

ＴＡ

（MailTransferA

gent

）

接続状態

初期状態

本文送信中

受信確認

接続要求

送信

接続解除

12345　　　　t

{t..t+100}

状態の変化を起こすメッセージ



SMTP送信:Ｍ

ＴＡ

（MailTransferA

gent

）

接続状態

初期状態

本文送信中

受信確認

接続要求

送信

接続解除

12345　　　　t

{t..t+100}

ある時点でのライフラインの状態を示す線



SMTP送信:Ｍ

ＴＡ

（MailTransferA

gent

）

接続状態

初期状態

本文送信中

受信確認

接続要求

送信

接続解除

12345　　　　t

{t..t+100}

時間制限の表記

ティックマーク値（tickmarkvalue）


ユースケース図

•  ユースケース図とは–  システムに関する機能的な要件を記述す

る–  ユースケースはアクターにより開始される

•  ユースケース図の目的–  システムの機能要件を記述–  要件へ名称を付ける–  要件とかかわる外部アクターを明確にする

•  高度なモデリング–  実装に依存しないビューを提供する–  アクターとユースケースの汎化–  ユースケースの包含–  ユースケースの拡張

ComponentDiagram

ClassDiagram


PackageDiagram

DeploymentDiagram

ObjectDiagram


ActivityDiagram


StateMachineDiagram

SequenceDiagram

TimingDiagram

StructuralDiagram

sBe

havioralDiagram

s

UseCaseDiagram



会員

会員情報を登録する

貸出の申請をする

返却をする

会計をする

店員

在庫を確認する

レンタルビデオ・

管理システムアクターアクターは、システムの外部からシステムが提供するユースケースを使用する存在である。アクターは、それぞれロールを表わしている。アクターにより使用するユースケースが異なる。




人型のアイコン（スティックマン）の下に、アクターの名称を記述するユースケースを起動するユーザーを記述する　　具体的な名称を記述することが望ましい

アクターの記述方法

１. スティックマンを用いて、アクターを記述する方法

２. 分類子を用いて記述する方法

<<actor>>会計をする

アクター名は記述子に記入するアクターであることを示すために、テンプレートを記述している　アクターには詳細を記述する必要がないので、区画が必要ない。　そのため、通常アクターの記述に分類子は使われない。

店員


会員



返却をする

会計をする

店員



管理システムユースケースユースケースは、システムが提供する機能により実現される外部へのサービスである。ユースケース図では、機能の仕様や実現方法ではなく、機能とかかわる外部アクターやユースケースを明確にすることにフォーカスを当てている。




会計をする楕円の中央に、名称を記述する通常は要求される機能をあらわす語句を記述する　　「〜する」と表現するのが一般的

ユースケースの記述方法

１. 楕円を用いて、ユースケース名を記述する方法

２. 分類子を用いて記述する方法

会計をする

拡張点明細を表示する

ユースケース名は記述子の上部に記入する下部には、拡張点を記述している


会員



返却をする

会計をする

店員



管理システムシステム境界システム境界は、システムと外部との境界を明示し、システムの外部に位置するものを明確にする。左の例では、アクターがシステムの外部の存在であることが分かる。



アクターの汎化アクター同士の関係を汎化することもできる。複数のユースケースにて、同じ機能が利用できるなら、抽象的なアクターを導出することができる可能性がある。

アカウント

店員会員

ログイン

ログアウト

メッセージを確認する

Webビデオレンタルシステム



ビデオを検索する

出演者で検索する

シリーズで検索する

ユースケースの汎化ユースケースを抽象化して考える場合には、汎化を利用する。左の例では、「出演者で（ビデオを）検

索する」と、「シリーズで（ビデオを）検索する」との２つのユースケースを抽象化し、「ビデオを検索する」というユースケースを導出している。



貸出回数を表⽰する

会計をする

<<extend>>

ユースケースの拡張ユースケースを拡張して、別のユースケースが提供する機能を追加することができる。左の例では、「会計をする」というユースケー

スにて、「貸出回数を表示する」というユースケースを利用することができることを表わしている。会計時に、貸出回数の表示ができるということである。



会計をする


ログイン

<<include>>

<<include>>

ユースケースの包含ユースケースを包含し、ユースケースの実行時に共通に実行されるユースケースを表わすことができる。上図の例では、「会計をする」と「在庫を確認する」との２つのユースケー

スにて、「ログイン」というユースケースを共有していることを表わしている。


NCSJ NoviceClassSeminar-JavaProgrammer

ディレクテック株式会社

Documents

UMLによるシステム設計入門 - ncsj.jp · クラス図 クラス図の構成要素 クラス 属性 操作 ステレオタイプ インターフェース テンプレートクラス

UMLによるシステム設計入門 - ncsj.jp · クラス図クラス図の構成要素クラス属性操作ステレオタイプインターフェーステンプレートクラス