が配置されている

物理的側面を表現する図
FM13005 大楠拓也 徐研究室
物理的側面を表現する図
• システムを開発する上では、分析と共に設計も行われる
• 今まで見てきた図は分析・設計段階双方で使用される
• しかし、今から出てくる図は設計段階のみで使用される
2
物理的側面を表現する図
• クラス図・オブジェクト図は論理的な側面を表現する
• 物理的な側面はシステム開発や運用に使用されるファイルや、
実行環境を表現する必要がある
1. コンポーネント図
 システムを開発、運用する上で必要なソフトウェアコンポーネントの構成を表現
2. 配置図
 実行時におけるシステム構成を表現
※ソフトウェアコンポーネント:開発環境や運用環境に配置する再利用部品のこと.
場合によっては、ビジネス手続きや各種ドキュメントを含むこともある.
3
コンポーネント
• UML1.x
• ソースファイル、実行ファイル、ダイナミックリンクライブラリ、データファイル、
データベースのテーブル、ヘルプファイルなど
• UML2.x
• “あらかじめ決められたインタフェースを持った再利用部品”
• この再利用部品は1つのオブジェクトから、Webサービスまで様々な粒度のものを表現
※UML1.xとUML2.xは共に、システムの物理的な側面を表現している
4
コンポーネント図(UML1.x)
• コンポーネント名は大きな長方形の中に記述
• 通常は実際のファイル名がコンポーネント名になる
コンポーネント名
コンポーネント名
コンポーネント
5
• コンポーネントにはソースファイル、実行ファイルなどの種類があるが、
この種類はコンポーネントにステレオタイプを付けることで区別する
<<executable>>
main.exe
実行ファイル
<<table>>
会員.tbl
テーブル
<<file>>
person.java
ソースファイル
<<document>>
説明文書.doc
文書
6
コンポーネント図(UML2.x)
• 以下のどちらかを行うことで表現できる
• 長方形の右上に、UML1.xのコンポーネントの小さなアイコンを配置
• コンポーネント名の上部にステレオタイプ<<component>>をつける
• ステレオタイプ<<subsystem>>を使用することで、複数のコンポーネ
ントをまとめるサブシステムを表現することもできる
UML1.xでは、パッケージで表現する
• 具体的なファイルを表現するには成果物を使用するのが一般的
7
コンポーネント
component
<<component>>
component
サブシステム
<<subsystem>>
サブシステム
8
コンポーネントの型とインスタンス(UML1.x)
インスタンス(具体的な記述)
<<executable>>
main.exe
• 複数のコンピュータの各々に同じ実行ファイルが配置された時、
その各々に配置された実行ファイル(※1)のことをインスタンスという
• コンポーネントインスタンスを表現するには、コンポーネント名に下線を引く
• コンポーネント図では、コンポーネントのインスタンスは使用しない
• 配置図で使用する
型(一般的な記述)
<<executable>>
main.exe
• “実行ファイル(※1)がどのようなものなのか”、という定義が
コンポーネントの型になる
9
コンポーネントの依存関係(UML1.x)
• コンポーネントは1つ1つ物理的に独立しているが、
コンポーネントの間には関係が存在する
• この関係は依存関係で表現する
• コンポーネント図は、以下の2面を表現する
• コンパイルの依存関係
• 実行ファイルの依存関係
10
• コンパイルの依存関係
• 1つのソースファイルは1つのコンポーネントで表現する
• コンパイル時点であるソースファイルは他のソースファイルを必要とする
このコンパイル時の関係を依存関係で表現する
• 実行ファイルの依存関係
• 分散システムや並行処理を行うシステムには、複数の実行ファイルが存在する
• 実行ファイル間でも呼び出しやデータのやり取りが行われている
この実行ファイル間の関係を依存関係で表現する
11
コンパイルの依存関係の例(UML1.x)
Webショッピングシステムの会員登録のソースファイルの依存関係
「会員登録画面」クラスのコンポーネント
「会員」クラスのコンポーネント
member.java
memberRegistrationForm.html
blackList.java
「ブラックリスト」クラスのコンポーネント
依存関係
memberList.java
「会員リスト」クラスのコンポーネント
12
実行ファイルの依存関係の例(UML1.x)
Webショッピングシステムの実行ファイルの依存関係
実行ファイル
実行ファイル
<<executable>>
main.exe
<<executable>>
client.exe
<<table>>
会員.tbl
<<file>>
ヘルプファイル
テーブル
ソースファイル
13
インタフェース
• コンポーネントにインタフェースをつけて、インタフェースを通してアク
セスすることができる
• 外部の他のモデル要素から見える操作の名前(仕様)のみを記述
• 操作の内部の手続き(実装)は記述しない
• 同じインタフェースを持つコンポーネント同士は入れ替え可能なので、
汎用性があるコンポーネントを複数作成すると再利用性が向上する
14
インタフェース(UML1.x)
“会員DB”に”updateMembers”という
インタフェース
インタフェースが定義されている
会員DB
<<executable>>
member.exe
updateMembers
“member.exe”は
“updateMenmers”インタフェース
で決められた呼び出しのみを使用
15
インタフェース(UML2.x)
• “:Product(製品)”に提供するインタフェースを
コンポーネント”:Order(注文)”が利用している
• ”:Order(注文)”には利用するインタフェースを明確
にするために、要求インタフェースがついている
<<component>>
: Order(注文)
要求インターフェース
(required interface)
提供インターフェース
(provided interface)
要求インタフェースと提供インタフェースが接続されている
コネクタをアセンブリコネクタという
アセンブリコネクタ
<<component>>
:Product(製品)
16
インタフェースの別表記(UML2.x)
提供インターフェース
(provided interface)
提供インターフェースと要求インターフェースは、
コンポーネントを上下に区切って、
その下の段に記述することも可能
<<component>>
: Order(注文)
<<provided interfaces>>
受注
<<component>>
: Order(注文)
<<required interfaces>>
注文可能商品
要求インターフェース
(required interface)
17
配置図∽
• システムを構成するコンピュータやプリンタなどの通信接続関係と
いったハードウェア構成をUMLでは配置図で表現する
• システム実行に必要なハードウェア以外にソフトウェアコンポーネン
トやプロセス、インスタンスなどの構成も表現する
• ソフトウェアコンポーネントは実行時に存在するもののみ表現する
• ソースファイルは表現できない(コンポーネント図でのみ表現可能)
18
ノード
• 演算を実行するリソースを表す(一般にはメモリや処理機能を持つものを指す)
• 型とインスタンスがある
• ノード型では、表現しようとしているコンピュータなどを一般的に表現する
• ノード型は立方体の形で表現し、ノード名を記述する
ノード名
PC
PC
(Personal Computer)
ノード
19
ノードインスタンス
• あるノード型のコンピュータを何台か実際に配置する場合の表現に用いる
• 下線付きの名前と、ノード型名を持つ
名前 : ノード型名
• 名前、ノード型名とも省略可能
受付PC :
PC
• ノード型名がない場合は”:”をつけない
受付PC
経理部PC
経理部PC:PC
営業部PC
受付PC:PC
営業部PC:PC
20
ノード(UML2.x)
• ノードでコンピュータなどの装置(ハードウェア)だけでなく、
OSなどの実行環境(ソフトウェア)も表現できる
• 装置を表現するノードにはステレオタイプ<<device>>をつける
• 実行環境を表現するノードには<<executionEnvironment>>をつける
ノード
(装置)
ノード
(実行環境)
<<device>>
: AppServer
“:AppServer”の中に、
実行環境である”:J2EEServer”が配置されている
<<executionEnvironment>>
: J2EEServer
21
配置図のコンポーネント
• コンポーネント図ではコンポーネント型のみ使用できた
• 配置図ではコンポーネントの型とインスタンスの両方を使用できる
• 配置図のコンポーネントは実行時に実体を持つもののみ使用する
22
配置図 のコンポーネント(UML1.x)
サーバ1号機 : Server
updateMembers
<<executable>>
member.exe
ノード
コンポーネント型
:会員DB
コンポーネント
インスタンス
田中さんのマシン : PC
<<executable>>
: client.exe
<<file>>
: ヘルプファイル
23
成果物(UML2.x)
• 配置図で物理的なファイルを表現する場合、コンポーネントの代わり
に配置する
• ソフトウェアを構成する物理的な実体であるファイルを表す
• 以下の2つの方法で表記できる
• 長方形のアイコンに成果物名を記し、ステレオタイプ<<artifact>>をつける
• 右上の角を折ったやや縦長の小さな長方形のアイコンを右上に配置する
<<artifact>>
member.exe
member.exe
24
配置図の
コンポーネント
(UML2.x)
<<device>>
サーバ1号機 : Server
<<executionEnvironment>>
: UnixOS
ノード
(装置)
ノード
(実行環境)
<<artifact>>
member.exe
updateMembers
<<artifact>>
会員DB
成果物
<<device>>
田中さんのマシン : PC
<<executionEnvironment>>
: Windows
<<artifact>>
client.exe
<<artifact>>
ヘルプファイル
25
まとめ
• 設計段階においては、システムの物理的側面も設計する必要があるので、
コンポーネント図と配置図を利用する
• コンポーネント図は、ソフトウェアコンポーネントの構成を表現する
ソフトウェアコンポーネント:環境開発や運用環境に配置する再利用部品のこと
• 配置図はハードウェア構成を表現する
• ノードは通常、コンピュータを表現する
• ノードにUML1.xではコンポーネントを、UML2.xでは成果物を置くことで、
物理的なファイルの配置を表現することができる
26