物理的側面を表現する図 Chapter6　物理的側面を表現する図について徐研究室の大楠が発表します。 FM13005 大楠拓也　徐研究室

物理的側面を表現する図 システムを開発する上では、分析と共に設計も行われる 今まで見てきた図は分析・設計段階双方で使用される しかし、今から出てくる図は設計段階のみで使用される まず、はじめに・・・

物理的側面を表現する図 クラス図・オブジェクト図は論理的な側面を表現する 物理的な側面はシステム開発や運用に使用されるファイルや、　　 実行環境を表現する必要がある コンポーネント図 システムを開発、運用する上で必要なソフトウェアコンポーネントの構成を表現 配置図 実行時におけるシステム構成を表現 ・・・ １.コンポーネント図とは・・・します。このソフトウェアコンポーネントとは・・・ ※ソフトウェアコンポーネント：開発環境や運用環境に配置する再利用部品のこと. 　　 場合によっては、ビジネス手続きや各種ドキュメントを含むこともある.

コンポーネント UML1.x UML2.x ※UML1.xとUML2.xは共に、システムの物理的な側面を表現している ソースファイル、実行ファイル、ダイナミックリンクライブラリ、データファイル、 データベースのテーブル、ヘルプファイルなど UML2.x “あらかじめ決められたインタフェースを持った再利用部品” この再利用部品は１つのオブジェクトから、Webサービスまで様々な粒度のものを表現 ※UML1.xとUML2.xは共に、システムの物理的な側面を表現している

コンポーネント図(UML1.x) コンポーネント名は大きな長方形の中に記述 通常は実際のファイル名がコンポーネント名になる コンポーネント名

コンポーネントにはソースファイル、実行ファイルなどの種類があるが、 この種類はコンポーネントにステレオタイプを付けることで区別する <<executable>> main.exe <<file>> person.java 実行ファイル ソースファイル <<table>> 会員.tbl <<document>> 説明文書.doc テーブル 文書

コンポーネント図(UML2.x) 以下のどちらかを行うことで表現できる コンポーネント名の上部にステレオタイプ<<component>>をつける ステレオタイプ<<subsystem>>を使用することで、複数のコンポーネ ントをまとめるサブシステムを表現することもできる UML1.xでは、パッケージで表現する 具体的なファイルを表現するには成果物を使用するのが一般的 成果物については後ほど紹介します

コンポーネント サブシステム <<component>> component component 上がコンポーネントの例です 下がサブシステムの例です。 サブシステム <<subsystem>> サブシステム

コンポーネントの型とインスタンス(UML1.x) インスタンス(具体的な記述) 複数のコンピュータの各々に同じ実行ファイルが配置された時、　　　　　　　　　　その各々に配置された実行ファイル(※1)のことをインスタンスという コンポーネントインスタンスを表現するには、コンポーネント名に下線を引く コンポーネント図では、コンポーネントのインスタンスは使用しない 配置図で使用する <<executable>> main.exe この※１は複数のコンピュータの各々に同じ実行ファイルが配置された時、その各々に配置された実行ファイルという意味です。 型(一般的な記述) “実行ファイル(※1)がどのようなものなのか”、という定義が　　　　　　　　　　　　　コンポーネントの型になる <<executable>> main.exe

コンポーネントの依存関係(UML1.x) コンポーネントは１つ１つ物理的に独立しているが、 コンポーネントの間には関係が存在する コンポーネントは１つ１つ物理的に独立しているが、　　　　　　　　　　 コンポーネントの間には関係が存在する この関係は依存関係で表現する コンポーネント図は、以下の２面を表現する コンパイルの依存関係 実行ファイルの依存関係

コンパイルの依存関係 実行ファイルの依存関係 １つのソースファイルは１つのコンポーネントで表現する コンパイル時点であるソースファイルは他のソースファイルを必要とする このコンパイル時の関係を依存関係で表現する 実行ファイルの依存関係 分散システムや並行処理を行うシステムには、複数の実行ファイルが存在する 実行ファイル間でも呼び出しやデータのやり取りが行われている この実行ファイル間の関係を依存関係で表現する

コンパイルの依存関係の例(UML1.x) Webショッピングシステムの会員登録のソースファイルの依存関係 「会員登録画面」クラスのコンポーネント 「会員」クラスのコンポーネント memberRegistrationForm.html member.java blackList.java memberList.java 依存関係 「ブラックリスト」クラスのコンポーネント 「会員リスト」クラスのコンポーネント

実行ファイルの依存関係の例(UML1.x) Webショッピングシステムの実行ファイルの依存関係 実行ファイル 実行ファイル <<executable>> main.exe <<executable>> client.exe <<table>> 会員.tbl <<file>> ヘルプファイル テーブル ソースファイル

インタフェース コンポーネントにインタフェースをつけて、インタフェースを通してアク セスすることができる 外部の他のモデル要素から見える操作の名前(仕様)のみを記述 操作の内部の手続き(実装)は記述しない 同じインタフェースを持つコンポーネント同士は入れ替え可能なので、 汎用性があるコンポーネントを複数作成すると再利用性が向上する

インタフェース(UML1.x) “会員DB”に”updateMembers”というインタフェースが定義されている インタフェース 会員ＤＢ updateMembers “member.exe”は “updateMenmers”インタフェース で決められた呼び出しのみを使用 <<executable>> member.exe

インタフェース(UML2.x) “:Product(製品)”に提供するインタフェースを コンポーネント”:Order(注文)”が利用している <<component>> : Order(注文) 要求インターフェース (required interface) 次にUML2.xの時のインタフェースについて説明します。 要求インタフェースと提供インタフェースが接続されているコネクタをアセンブリコネクタという 提供インターフェース (provided interface) アセンブリコネクタ <<component>> ：Product(製品)

<<component>> インタフェースの別表記(UML2.x) 提供インターフェースと要求インターフェースは、　　　コンポーネントを上下に区切って、　　　　　　　　　　　その下の段に記述することも可能 提供インターフェース (provided interface) <<component>> : Order(注文) <<provided interfaces>> 受注 <<required interfaces>> 注文可能商品 <<component>> : Order(注文) 要求インターフェース (required interface)

配置図∽ システムを構成するコンピュータやプリンタなどの通信接続関係と いったハードウェア構成をUMLでは配置図で表現する システム実行に必要なハードウェア以外にソフトウェアコンポーネン トやプロセス、インスタンスなどの構成も表現する ソフトウェアコンポーネントは実行時に存在するもののみ表現する ソースファイルは表現できない(コンポーネント図でのみ表現可能)

ノード 演算を実行するリソースを表す(一般にはメモリや処理機能を持つものを指す) 型とインスタンスがある ノード型では、表現しようとしているコンピュータなどを一般的に表現する ノード型は立方体の形で表現し、ノード名を記述する ノード名 PC PC (Personal Computer) ノード

ノードインスタンス あるノード型のコンピュータを何台か実際に配置する場合の表現に用いる 下線付きの名前と、ノード型名を持つ 名前、ノード型名とも省略可能 ノード型名がない場合は”：”をつけない 名前　 ： ノード型名 受付PC ： PC 右のこれは表記方法とその例です。 下の図は例です。 受付PC 営業部PC 経理部PC 経理部PC:PC 受付PC:PC 営業部PC:PC

<<executionEnvironment>> ノード(UML2.x) ノードでコンピュータなどの装置(ハードウェア)だけでなく、　　　　　　　 OSなどの実行環境(ソフトウェア)も表現できる 装置を表現するノードにはステレオタイプ<<device>>をつける 実行環境を表現するノードには<<executionEnvironment>>をつける 次にUML2.xのノードについてです。 ノード (装置) <<device>> : AppServer “:AppServer”の中に、 実行環境である”:J2EEServer”が配置されている ノード (実行環境) <<executionEnvironment>> : J2EEServer

配置図のコンポーネント コンポーネント図ではコンポーネント型のみ使用できた 配置図ではコンポーネントの型とインスタンスの両方を使用できる 配置図のコンポーネントは実行時に実体を持つもののみ使用する

配置図 のコンポーネント(UML1.x) サーバ１号機 : Server 田中さんのマシン : ＰＣ updateMembers <<executable>> member.exe ：会員ＤＢ コンポーネント インスタンス ノード コンポーネント型 田中さんのマシン : ＰＣ <<executable>> : client.exe <<file>> : ヘルプファイル

<<artifact>> 成果物(UML2.x) 配置図で物理的なファイルを表現する場合、コンポーネントの代わり に配置する ソフトウェアを構成する物理的な実体であるファイルを表す 以下の２つの方法で表記できる 長方形のアイコンに成果物名を記し、ステレオタイプ<<artifact>>をつける 右上の角を折ったやや縦長の小さな長方形のアイコンを右上に配置する <<artifact>> member.exe member.exe

配置図の コンポーネント(UML2.x) <<device>> サーバ１号機 : Server <<executionEnvironment>> : UnixOS ノード (装置) <<artifact>> member.exe updateMembers <<artifact>>会員ＤＢ ノード (実行環境) この図はUML1.xの配置図のコンポーネントをUML2.xへ適応したものです。 成果物 <<device>> 田中さんのマシン : ＰＣ <<executionEnvironment>> : Windows <<artifact>> client.exe <<artifact>> ヘルプファイル

まとめ 設計段階においては、システムの物理的側面も設計する必要があるので、 コンポーネント図と配置図を利用する コンポーネント図は、ソフトウェアコンポーネントの構成を表現する ソフトウェアコンポーネント：環境開発や運用環境に配置する再利用部品のこと 配置図はハードウェア構成を表現する ノードは通常、コンピュータを表現する ノードにUML1.xではコンポーネントを、UML2.xでは成果物を置くことで、　 物理的なファイルの配置を表現することができる 最後にまとめです。・・・。 以上で発表を終わります。