筆者は、学生時代を含め、そんなに映画を見る方ではなかったのですが、昨年は「プラダを着た悪魔」と言う映画を６回見てしまいました。
３回目ぐらいになると、さすがに飽きてきて、スクリーンを見るのも苦痛になるのですが、残念ながら機内ではなかなか眠れない質なので、仕方なく、いやいや見ているうちに、４回目あたりから、だんだん平気になってきて、最後には、立ち寄った書店で、原作本を思わず買ってしまうほどになってしまいました。
洗脳とは、こういう事なのだな、と実感しました。
そのうち、プラダの高価なバッグなどをフラフラと買ってしまうのではないかと危惧しております。
第9章 配備図
配備図は、実行時のシステム・アーキテクチャを記述する物で、幾つかの配備図固有の構成概念、コンストラクト、が用いられます。
コンストラクトには、成果物（＜＜artifact＞＞)やノード、配備関係(＜＜deployment＞＞)、具現関係(＜＜manifest＞＞）等がありますが、実は、前者２つはクラスの一種であり、後者２つは依存関係の一種です。
従って、配備図はクラス図の一種である、と言う事ができます。
ではなぜ、普通のクラス（四角形の記号）を使用しないかと言うと、できるだけアイコンやイメージ等を用いて、配備関係を視覚的に分かりやすく記述するためです。これは、ユースケース図で、本来クラスの一種であるアクターを、スティックマンで表すのと同じ事です。
このように、UMLには自分自身を拡張する機能、プロファイリングが用意されており、UMLの仕様を決めているOMGだけではなく、UMLのユーザーも、コンストラクトを追加する事ができます。
このプロファイリングを用いて、コンピュータ・ベンダーは自社固有のコンストラクトを作る事が可能であり（とは言っても、無闇やたらにアイコンを増やすとユーザーが理解不能に陥りますので、ご注意）、また、方法論等を記述する際に、固有の概念を付け加える事ができます（例えば、リスク・メタクラスなど）。
詳しくは、プロファイリングやメタモデリングの知識が必要ですので、ご興味のある方は、そちらの文献をあたってみて下さい。（本講座でも、１０章でプロファイリングを解説する予定になっていますが、いつになるか、分かりません（すみません）。）
9.1 成果物（artifact)
成果物は、図H01のように、ステレオタイプ＜＜artifact＞＞を付けて表されます。また、分類子を表現する四角形の中に右上隅に、ドキュメントを示すアイコンを付けて示したり、またドキュメントのアイコンそのものでも表す事ができます。
また、先に配備図はクラス図の一種と言いましたが、図H01で、成果物の名前”Order.Jar”に下線が引いてあり、これは成果物のインスタンスを表現している意味になる事は、クラス図と全く同じです。
成果物は、ソフトウエア開発や、システムの配備、運用に関する情報の仕様であり、具体的には、ソースコードや、実行モジュール、データベースのテーブルの他、ワードで記述された運用マニュアルやメール・メッセージなども含まれます。
図H01
