UML中級講座 第103回 具現

筆者の友人で、やたら風水や姓名判断というものにこだわる人がいます。
風水はともかくとして、両親が産まれてきた子供に幸多かれと良い名前を付けようとするのは、世界共通であり、両親の心情を考えると決して軽んずべきことではないと思いますが、筆者自身は姓名判断なるものに特に興味を持ったことはありませんでした。
しかしながら、考えてみますと、名前を付けると言う事は極めて知的な行為です。
特に、実体のない概念を考え出し、それに名前を付けて識別すると言うことは、かなり抽象的な作業です。
アーキテクチャは、往々にして、実体を伴わず、存在しているのは、アーキテクトやプログラマーの頭の中だけです。
そんな環境では、ネーミングは非常に重要になってきます。
たいていの場合、アーキテクトは概念的な物に対する名前のつけ方が上手いのですが、人によっては、対象とは関係性の低いものや、極めて誤解を招きやすい命名をして、プロジェクトを混乱させるケースが見受けられます。

さて、ネーミングとか姓名判断の話題になると必ず思い出す出来事があります。
昔、その姓名判断にこだわる友人と一緒に、スキーに行った事があるのですが、夕食の後、ペンションの暖炉の前で寛いでいた所、彼はPCを私の前に突き出し、このサイトの姓名判断は良く当たるからやってみろ、と言うのです。
すっかり酔っぱらっていた筆者は、これも座興と思い、知り合いの女性の名前をいれてクリックしてみました。
すると、軽い気持ちで入力したのと裏腹に、恐ろしいほどの悪い結果が次々と表示されて出て来ました。詳しい文面は覚えていませんが、「稀に見る大凶数」とか、「身辺に強い霊障の気配あり」と言ったような言葉が続いていたと思います。
実は、入力した名前は、筆者の知り合いの二人の同姓同名の女性のものでした。一人は小学校からの幼なじみの同級生で、もう一人は新入社員時代の同僚でした。
そして、二人に共通するのは、20年ほど前に２０代の若さで亡くなってしまっていたことでした。
同僚の女性の方は、亡くなる直前まで元気な姿を職場で見せており、彼女を知る廻りの人間達は、葬式が終わった後でも、しばらくは信じられないと言った茫漠とした状態でした。

そのスキー旅行から数年後、筆者は、郷里の母校の同窓会に卒業後初めて出席しました。
会場で、懐かしい顔ぶれ達と談笑していた所、背後から、「○○ちゃん」と筆者の幼い頃のあだ名で呼ぶ声がありました。誰だろうと振り返ると、なんと、そこに立っていたのは亡くなったはずの幼なじみの女性でした。
あまりのことに、内心仰天したのですが、努めて冷静を装い、いろいろ話を聞いて分かった事は、亡くなったのは、この同姓同名の幼なじみではなく、もう一人の別の同級生の女の子でした。
彼女が亡くなった時、既に郷里を離れていた筆者に、どこかで話が間違って伝わってきたようです。
会場で会った幼なじみの彼女は、至って元気で、幸せそうでした。

具現

図H02は、具現（Manifest）を表現した配備図の例です。
ちなみに、jarは、Java Archiverの略で、プログラミング言語Javaで記述されたソフトウエアを実行させるのに必要なクラスファイルやデータファイルをまとめるための仕様のことです。そして、Javaのソフトウエアを配布するために関係するファイルを１つにパッケージングするのに用いられます。
この図は、”Order .jar”と言う名前のJava Archiverから、"Order"という名前のコンポーネントを具現（マニフェスト）する事を、意味しています。
コンポーネント(＜＜Component＞＞）も成果物（＜＜artifact＞＞）も共にクラスの一種ですが、概念的に１つのカテゴリーとして区別し、名前とシンボル（アイコン）が定義されています。
具現（＜＜manifest＞＞）も同様に、依存関係の一種ですが、区別して命名されています。（矢印は、依存関係のものをそのまま使っています。）


図H02

UML中級講座 第102回 第９章 配備図

昨年の秋から暮れにかけて、飛行機に乗る機会が増え、機内で映画を見る事が多くなりました。
筆者は、学生時代を含め、そんなに映画を見る方ではなかったのですが、昨年は「プラダを着た悪魔」と言う映画を６回見てしまいました。
３回目ぐらいになると、さすがに飽きてきて、スクリーンを見るのも苦痛になるのですが、残念ながら機内ではなかなか眠れない質なので、仕方なく、いやいや見ているうちに、４回目あたりから、だんだん平気になってきて、最後には、立ち寄った書店で、原作本を思わず買ってしまうほどになってしまいました。
洗脳とは、こういう事なのだな、と実感しました。
そのうち、プラダの高価なバッグなどをフラフラと買ってしまうのではないかと危惧しております。

第9章 配備図
配備図は、実行時のシステム・アーキテクチャを記述する物で、幾つかの配備図固有の構成概念、コンストラクト、が用いられます。
コンストラクトには、成果物（＜＜artifact＞＞)やノード、配備関係(＜＜deployment＞＞)、具現関係(＜＜manifest＞＞）等がありますが、実は、前者２つはクラスの一種であり、後者２つは依存関係の一種です。
従って、配備図はクラス図の一種である、と言う事ができます。
ではなぜ、普通のクラス（四角形の記号）を使用しないかと言うと、できるだけアイコンやイメージ等を用いて、配備関係を視覚的に分かりやすく記述するためです。これは、ユースケース図で、本来クラスの一種であるアクターを、スティックマンで表すのと同じ事です。
このように、UMLには自分自身を拡張する機能、プロファイリングが用意されており、UMLの仕様を決めているOMGだけではなく、UMLのユーザーも、コンストラクトを追加する事ができます。
このプロファイリングを用いて、コンピュータ・ベンダーは自社固有のコンストラクトを作る事が可能であり（とは言っても、無闇やたらにアイコンを増やすとユーザーが理解不能に陥りますので、ご注意）、また、方法論等を記述する際に、固有の概念を付け加える事ができます（例えば、リスク・メタクラスなど）。
詳しくは、プロファイリングやメタモデリングの知識が必要ですので、ご興味のある方は、そちらの文献をあたってみて下さい。（本講座でも、１０章でプロファイリングを解説する予定になっていますが、いつになるか、分かりません（すみません）。）

9.1 成果物（artifact)

成果物は、図H01のように、ステレオタイプ＜＜artifact＞＞を付けて表されます。また、分類子を表現する四角形の中に右上隅に、ドキュメントを示すアイコンを付けて示したり、またドキュメントのアイコンそのものでも表す事ができます。
また、先に配備図はクラス図の一種と言いましたが、図H01で、成果物の名前”Order.Jar”に下線が引いてあり、これは成果物のインスタンスを表現している意味になる事は、クラス図と全く同じです。
成果物は、ソフトウエア開発や、システムの配備、運用に関する情報の仕様であり、具体的には、ソースコードや、実行モジュール、データベースのテーブルの他、ワードで記述された運用マニュアルやメール・メッセージなども含まれます。


図H01