ストラタジーナム メニュー

2007年1月23日火曜日

UML中級講座 第103回 具現

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

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

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

具現

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



図H02