OCRESブログ 第4回 詩人の娘とコンピュータ

明治の前半は、海外の文献を日本語に翻訳することが学者たちの大きな仕事でした。
現代人と明治人の教養の違いに漢籍の知識が挙げられますが、その素養の高さは、彼らが西洋語と格闘し作り出した訳語の幾つかは、漢籍の本場である中国に逆輸出された事で窺い知る事ができます。
「哲学」、「形而上学」、「理性」等が、その代表的な訳語として挙げられますが、変わった所では、「科学的」、「経済的」という言葉に使われる「的」と言う文字で、「ファンタスティック」などの形容詞の語尾、「ティック」を音訳したものだと言われており、現代の中国語でも頻繁に登場します。

そして、数ある翻訳のうち、最も苦労が忍ばれるのが、文学、就中、詩の翻訳でしょう。
直訳しても、何ら感興を催さず、やむを得ず意訳が試みられますが、場合によっては意味が全く変わってしまいます。夏目漱石は、かつて、"I love you"を（やむを得ず？）「月がきれいですね」と意訳したそうですが、明治の女性ならともかく、現代の女性には全く通じそうにありません。単なる天文オタクと思われる危険性があります。

さて、漱石たちを苦しめた英文学の作者に有名な詩人、バイロンがいます。
バイロンは、「バビロン川の畔にて」などに代表されるエキゾチシズムに富んだ作風が日本でも好まれ、明治期では最も有名であった英詩人ですが、破天荒な人生をギリシャ戦争中に終えています。
そして、彼の一人娘、エイダは、少なくともコンピュータ業界では、父親よりも遥かに有名な人物になっています。彼女は世界最初の伝説のプログラマーと言われ、コンピュータ言語、Adaは彼女の名前からとられています。

Ada と組込み系

組込み系システムを代表するコンピュータ言語はと聞かれると、アセンブラを除くと、おそらく世界的にはAdaを挙げる人が多いでしょう。Adaは日本では非常に影が薄いのですが、それでも、世界的に見るとAdaは最右翼に位置するでしょう。
最初期は、アメリカ国防総省案件だけに使われていましたが、現在では、宇宙航空分野だけでなく、安全性、信頼性を重視する分野で幅広く使われるようになりました。

８０年代、筆者はアメリカのコンピュータメーカーの研究所に勤めておりましたが、当時人気のあった内部トレーニング・コースの一つがAdaを用いた設計演習でした。
レーガン大統領が戦略防衛構想を立ち上げ国防総省の入札条件の一つがAdaになると、国防総省にシステムを納入しているベンダーたちは、こぞってAdaのトレーニングを立ち上げました。筆者の勤めていた企業も例外ではなく、Adaは一躍、脚光を浴び、内部で方法論の研究が始まり、トレーニング・プログラムの殆どは重要機密扱いを受け、受講者たちはNDAにサインしてから教室に入りました。
現在、Adaは、世界標準になった最初のオブジェクト指向言語、実装言語として有名ですが、８０年代では、実装言語というよりもむしろ設計言語と言う面が強く、実際、国防総省の入札条件も、「Adaを使ってプログラミングしろ」と言うものではなく、「フォーマル・ベリフィケーションが可能な設計言語を使って設計しろ」と言うものでした。そして、当時、フォーマル・ベリフィケーション、あるいは設計(ハイレベル・デザインを含む）に使える言語と言うと、事実上Adaしかありませんでした。

そして、ソフトウエア技術者たちは、Adaで設計した後、しばしば手作業でアセンブラに落としていました。
これは、当時のコンパイラ技術が未熟であった事とともに、コンピュータそのものが遅く、コンパイルに延々時間がかかり、オブジェクトコードがアセンブラで書いたものに比べて、比較にならないぐらい遅かった所為です。

現在、Adaは宇宙航空分野ではデファクト・スタンダードになっており、最新鋭のジェット戦闘機F-22のソフトウエアもAdaで書かれているほか、他の安全性を重視する分野でも中心的な役割を演じています。

UMLツールを始め、組込み系ツールの多くはAdaをサポートしており、組込みの女王の地位は当分揺らぎそうにありません。


１２月１３日 シスコのカフェにて記す

OCRESブログ 第3回 兵站（ロジスティックス）

組込み系ソフトウエアは、欧米の場合、軍需主導で開発されてきたテクノロジーが多く、時を経て民間がそれを採用して行くケースが非常に良く見られます。
NASAに代表されるような宇宙航空技術分野も例外ではなく、元々軍事用に開発された技術、副産物が、後に民間に開放されたものが数多く存在します。

兵站、ロジスティックス

洋の東西を問わず、近代の軍隊組織において、参謀もしくは参謀本部の役割は極めて重要であり、多くの国では、軍人の最高職位は、その参謀本部の長です。また、どこの国の軍隊もそうですが、絶えず目を外に向け、常に他国の研究を行う事が習い性になっているため、たとえ敵軍であってもその長所を取り入れる事に躊躇しない事が多く、また国際間の技術伝播が早い結果、参謀本部の組織・役割は国際的に似たような構造になっており、インテリジェンス（軍事情報）を扱う部署や、計画とトレーニング、兵站、情報通信（IT）等の組織から構成されています。

歴史的には、近代の参謀制度は、18世紀のプロシア軍やフランス軍に始まると言われます。プロイセン軍は、ナポレオンに大敗した後、仏軍の軍制を真似し、また、普仏戦争後、大敗したフランスはプロシアの軍制を相当研究したと言われています。
そのプロシア軍の参謀本部ですが、その原点はさらに17世紀のプロイセン国王であるブランデンブルグ選帝侯に遡り、当時の敵国スエーデンの軍制を真似た陸軍兵站部に始まると言われています。
従って、歴史的に言うと参謀本部は兵站を原点とし、その後、インテリジェンスや戦略、戦術を扱う部隊へと発展して行きました。
近代戦においては、前線での物的人的消耗が激しく、その補給能力は勝敗に大きく影響しますが、必ずしも一般的には、その価値を認められていません。良く言われる言葉ですが、「戦争の素人は戦略を語り、プロはロジスティックスに着目する」と言われています。

情報のロジスティックス

さて、そのロジスティックスですが、昨今の現代戦では、消耗するのは物的人的資源だけではなく、情報も大量に消費されて行く事が特徴的です。
軍事アプリケーションの一つの特徴は、その強い分散処理指向と、回復能力です。TCP/IPと言う通信プロトコルは、米国国防総省のARPANETの標準プロトコルに採用されたのがきっかけで爆発的広がりを見せた事は有名ですが、そのARPANETは核攻撃にも耐えうる通信網と言うのが最終目的であり、初期から自動復旧能力が非常に重要な課題でした。
また、その情報の消費ですが、情報の種類も多岐にわたり、同一作戦を遂行する陸海空軍や同盟国間でコンパチブルである事が要求されます。
OCRESの試験カバレッジにあるDDS(Data Distribution Service)は、その仕様を決めたものです。
DDSは、システム間のデータの大量の移動、信頼性、回復性能、リアルタイム性の確保等を目的とします。
内容的には、抽象工場（Abstract Factory）を中心としたデザインパターンを使用したフレームワークであり、軍事アプリケーションだけではなく、分散処理能力を求められる民需アプロケーションへの普及が行われています。

OCRESブログ 第2回 軍事と組込み系（１）

イラク戦争の最中にアメリカの国防長官、ラムズフェルド氏が更迭されたニュース（形式的には辞任）を覚えておられる方は多いと思います。
実は、欧米のコンピュータ業界では、その前後にかなりの憶測が飛び交っていました。

産業構造的に欧米と日本のIT業界は決して同質的ではありませんが、最も異なる点の１つは、軍事分野で顕著に現われています。
筆者は、二十代の頃、当時コンピュータの巨人と呼ばれた企業の研究開発部門にいましたが、その会社のアメリカ市場の最大顧客、つまり、世界市場の最大のコンピュータ・ユーザーは米国国防総省でした。
組込み系の、特に高度技術分野においてはこの構図はまったく変わっていません。
従って、欧米のコンピュータ産業は、ハイエンドに行けば行くほど軍事産業色が強くなり、顧客である各国の国防省の動きには非常に敏感で、一方では顔色を窺いつつ、一方では政治家やロピースト、元軍人等のコンサルタントを使い影響力を行使しています。

国防総省（ペンタゴン）とポトマック川

ラムズフェルド氏の更迭は、ネオコンに代表される文民、つまり軍事の非専門家達による国防総省の完全掌握の失敗と言う側面があり、それはそれで面白い話題ではありますが、当然の事ながら、漏れ伝わる話の確度に幅があり、オンライン向きの話題ではないので、これ以上は触れません。しかし、次回以降、組込み系と言う言う観点で、軍事アプリケーションの特徴を見て行きたいと思います。

OCRESブログ 第1回 コンピュータの誕生

筆者の会社に、世界最初のコンピュータとして知られるENIACをパソコン上でシミュレートさせるソフトウエアを作った人がおり、先日そのソフトのデモを見せてもらいました。
ENIACそのものは、元々、第二次世界大戦中に米陸軍の大砲の弾道計算をする目的で始められたそうですが、完成したのは1946年で、戦争は既に終っていました。
当時、２万本近い真空管を使い、総重量30トンを超えた計算機は、今では、2キロに満たないノート型Macで、遥かに高速に走ります。（正確に言うと、Windowsアプリケーションなので、筆者の環境では、Mac上の仮想PCで走っています。）
このENIACですが、今のコンピュータと違い内部演算を10進数で行っています。当時、既に二進法の方が効率的である事は専門家の間では知られていましたが、スポンサー達を説得するために、わざわざ十進法を採用したそうです。
また、プログラミングは配線をいじって行うタイプで、所謂フォン・ノイマン型コンピュータは、ENIACの直接の後継機種であるEDVACによって初めて実装されました。

写真を見ると、プログラミング用のケーブルが一部配線されている様子が映されています。

真空管を２万本近く使っており、恐らく計算機内部の配線はもっとゴチャゴチャしたものだったでしょう。

ENIACほどエポックメーキングなものではありませんが、筆者も30年ほど前に、実験室でIC(TTLだったと思います）で構成されたNAND回路を使ってコンピュータを作った事があります。トランジスタや真空管ではなくICを用い組み立てたのですが(当時LSIや超LSIは既にありましたが、種類が限られており、実験機はICで作っていました）、それでも電線がのたくって渦を巻き、雲のようになっていて、配線をたどるだけでも大変な作業でした。

この当時を振り返って思い出すのは、ある有名な飛行家の言葉です。人類の初飛行は、アメリカのライト兄弟によって成し遂げられましたが、別にこの兄弟だけが初飛行に挑戦していたわけではなく、世界中で様々な人々によって試みられ、ことごとく失敗していました。この飛行家は、失敗が繰り返されていた頃、インタビューに答え、「飛行機を発明する事は何でもない事である。作る事も、頑張れば何とかなる。問題は、実際に飛ばす事だ。」と言う名言を残しています。

コンピュータも似たような事が言えます。コンピュータ回路も、動作原理さえ知ってれば、設計はすぐ出来ます。アナログ回路よりも、ある意味、遥かに簡単です。配線も頑張れば何とかなります。問題は、正しく動かす事、デバッグが極めて困難なのです。昨今、時々CPUのハードウエア・バグが見つかって、新聞雑誌の紙面を賑わす事がありますが、その複雑さ、困難さを示す良い例でしょう。

さて、目をソフトウエア分野に向けて見ましょう。

オブジェクト指向を含め、現在主流となっているソフトウエア・アーキテクチャの考え方の原形部分が、既にコンピュータの黎明期である50年代には大部分出そろっていたことに驚かされます。

様々な理由で、当時はまだ実用的でないと見做されたアプローチが50年後の現在、有効な手段として発展して来ています。

逆に言うと、アイデアの発見よりも、実用化の方が遥かに時間のかかる作業である、と言えます。

オブジェクト指向なり、フレームワークなり、昨今主流になりつつあるアプローチも、原理の理解よりも、実際に使う事の方が、時間と労力を要する作業と言えるでしょう。

UML中級講座 最終回 メタ属性

長い間、システム関係の仕事をしていると、他の分野の問題もシステム的に解釈してしまうのは、一種の職業病でしょうか？

最近気になった話題の一つが、北陸で起こった冤罪事件です。
無実の人間Aさんが、婦女暴行の罪で服役後、冤罪である事が判明した事件で、ご記憶のある方も多いと思います。
この事件の特徴の一つは、物的証拠が乏しい（あるいは無いと行った方がより正確かも知れませんが）事ですが、システム屋として興味があるのは、どういう成り行きで裁判所が有罪を確信するに到ったかと言うプロセスの問題です。
関係者に免責の特権を与えてでも徹底的な原因究明とプロセスの見直しを行った方が良いと思うのは、やはり、システム屋の発想でしょうか、その後の裁判でも、結局何も明らかにされませんでした。
法律関係に明るい友人に聞くと、刑事訴訟法を含む現行の訴訟システムは、一見プロセス指向的な制度に見えるけれども、実際は人間に大きく依存したもので、プロセス指向とは相反する性質のものだそうです。

この裁判が筆者にとって気になるもう一つの理由は、同じ北陸で（多分同じ裁判所？）以前、（素人目には）非常に不自然に映る判決があった事も影響しているのだと思います。
かなり昔ですが、女性2人を殺害したとして、B男（主犯）とC女（従犯）が起訴されましたが、その後、B男は無罪となり、C女の単独犯行として死刑判決がでている事件があります。C女は今でもB男が主犯で自分は従犯だと主張していますが、直近の裁判では、その主張は否定されています。
これらの事件に共通するのは、ともに物的証拠が非常に乏しいことです（ほとんど供述だけ）。
個人的には、Ｃ女の単独犯行とするにはいくつかの点で疑問が残り、より客観的な根拠が必要だと思うのですが。

メタ属性とタグ付き値

タグ付き値は、以前のUML1.Xでもサポートされておりましたが、必ずしもステレオタイプとは結びつけられてはおらず、ステレオタイプの定義なしにタグ付き値だけセットする事が可能でした。
このため、同じクラスなのにタグ付き値があるものとないものが混在し、誤った解釈を引き起こしやすかったために、UML2では、タグ付き値はステレオタイプと必ず結びつけられる事が必須となり、名称もメタ属性と呼ばれるようになりました。

図I15は、”clock(時計)”と言うステレオタイプに”resolution(精度)”と言うメタ属性が定義されている事示しています。
上段の図は、モデル・レイヤーでの記述で、下段の図は、メタモデル・レイヤーの図（インスタンス表現）であり、ともに同じ事を表現しています。


図I15

複数のステレオタイプを持つ場合のメタ属性の表現 例

図I16は、" creator”と”clock”と言う2つのステレオタイプを持つ”Stopwatch”のクラス図表現です。
この図のように、2つのステレオタイプが個別にメタ属性を持つ場合もノートの記号を使って、それぞれの値を指定する事が出来ます。


図I16

最後に
これまでの長い期間、UML中級講座をご購読頂きまして、ありがとうございます。
次回以降は、MDAモデリング、組込み系、BPMなど（OCRESやOCEB関連の）最近の話題を取り入れたものを書いて行きたいと思います。

2007年10月22日

UML中級講座 第121回 ステレオタイプのメタ・レベル表現

先日、ちょっとした用事があり、神奈川県の厚木と言う街まで行ってきました。

厚木と言う名前から、大抵の人がすぐに思い浮かべるのは、アメリカ海軍の厚木基地だと思いますが、実は基地は厚木市内ではなく2つ隣の「綾瀬市」にあります。
こう言った事は、非常によくある現象で、千葉県にあるのに東京ディズニーランドと命名したのはその代表的な例でしょう。

ところが、厚木には更に別の謎があり、小田急やJRの「厚木駅」が、実が厚木ではなく隣の「海老名市」にあり、且つ、厚木の中心から相模川を挟んでかなりの距離があり、多くの人は、歩くのを断念して、再度電車に乗り直します。
こう言う駅名のつけ方には、きっと地元の方にとって重要な意味があるのでしょうが、他府県から来た人間にとっては、いったい誰が得をするのかが分からない（愉快犯的な？）命名で、何か不思議な感があります。

また、厚木へ行く途中に「町田」と言う市がありますが、ここも少し謎めいています。
町田市は東京都に属していますが、多くの人は神奈川県の市だと勘違いしています。
電車で行くと、多摩川を渡って神奈川県内をかなり走った後にたどり着く街であるという地理的な理由もありますが、もう一つは、都内に働きに来ている町田市民が、あまり自己主張しなかった所為でもあるでしょう。
町田から通って来ている人に、「町田は神奈川か東京か？」と聞くと、大抵は少し含羞みながら、どちらでも良いんです、と言うような曖昧な回答をして、話題を変えてしまいます。
この奥ゆかしさが、返って皆に誤解を与えているのではないかと、町田の奥にある「座間市」に古くから住んでいるＳ君と言う友人に話すと、「町田市民が奥ゆかしいと言うのは大きな誤解であり、近隣の神奈川県側の市町村を下に見下した傍若無人な人たちである」、と反論して来ました。
S君によると、町田市民は「多摩川の鉄橋」を渡って東京側に入ると、それまでの暴君的性格が、借りてきた猫のように急に大人しく、しおらしい性格に変わるのだそうです。
まるでシュレジンガーの猫のような話で、睡眠不足で眠ってしまい橋を渡ったかどうか分からない人は、暴君なのか猫なのか、どちらなのでしょうか？
そう聞くと、Ｓ君は「町田そのものが量子力学的存在だ」と言い切っていました。
いったい何がS君をそう語らせるのか、そちらも謎です。


ステレオタイプのメタ・レベル表現

前回の図I12では、ステレオタイプのインスタンス・レベルでの表現を見ましたが、さて、このインスタンス・レベルの図そのものは、クラス図でしょうか、あるいはメタクラス図でしょうか？

答えは、メタ・レベルの図、メタクラス図です。あくまでも、メタクラス図を用いてインスタンス・レベルの表現を行っているからです。
モデル・レベルの表現としては、下図I14のような風に書きます。この図では、"StopWach"は、ステレオタイプ"clock"に属する事を意味しています。
図I14

ステレオタイプの多重拡張

クラスが複数の上位クラスを多重継承出来るのと同様に、ステレオタイプは複数のメタクラスを拡張する事が出来ます。
図I13では、ステレオタイプ"Clock"は、"Component"と"Class"と言う2つのメタクラスを拡張しています。
また、このメタモデル図では、＜＜metaclass＞＞と＜＜stereotype＞＞と言う二つのステレオタイプを使っていますが、これらは、謂わば「メタ・ステレオタイプ」のようなものであり、メタメタ・レベルで拡張が定義されます。
また、"Creator"と謂うステレオタイプに｛Required｝と言う制約が付随しており、このパッケージ内では、"Class"単体では使用出来ず、必ず"Creator"として使用される必要がある事を示しています。

図I13

UML中級講座 第120回 メタモデルのインスタンス表現

タイプ（型）レベルとインスタンス・レベル

OCUPファンダメンタルをお持ちの方は、ご存知だと思いますが、UMLでは、型レベルの視点とインスタンス・レベルの視点があります。具体的には、クラス図の通常の（型レベル）のクラス図と、そのオブジェクトに着目した図（インスタンス・レベル）が、その典型例です。

同様にして、メタモデルにも、この2つの視点が取れ、図形表現にもその違いが反映されます。

図I10は、前回（第119回）にも登場した、"Clock"と言うステレオタイプのメタモデル図です。

この図を、インスタンス表現すると、図I12のようになります。
図中のすべてのクラス名には下線が引かれ、メタクラスのインスタンスである事を示しており、属性"name"は、分類子名（クラス名等）を表しています。
このようなメタモデル図の読み書きは、中級レベルを超えた内容であり、通常のモデラーはあまり気にする必要はありませんが、更に上位のモデリング技術を身に付けたい方（プロファイリング等を駆使したモデリングや概念モデリングを行う必要のある方）のために、簡単に解説致します。
図中に、"iscomposite"という属性があります。これは、拡張（Extension)と言う概念が、コンポジットの性質を使って構成される事に起因します。
ステレオタイプが定義されると、そのインスタンス（ここでは"Clock"）は、拡張される側のメタクラス（ここでは"class"）のインスタンスを（内部に）所有します。（コンポジット関連を思い出して下さい。）
これらの性質を2つのメタクラス、PropertyとExtensionEndを用いて表しています。
また、拡張の性質を表すメタクラス、Extensionには、"isRequired"と言う論理値を持つ属性があり、以前紹介した通り、この値がTrueであると、拡張される側の分類子は必ずステレオタイプで示される性質を持つ事になります。 （参考までに言いますと、頭に"is"が付く属性名は、通常論理値を持つ性質に付けられます。これは、文法的に決められている訳ではなく一種の慣習です。（ネーミング・コンベンション））
図I12

UML中級講座 第120回 メタモデルのインスタンス表現

タイプ（型）レベルとインスタンス・レベル

OCUPファンダメンタルをお持ちの方は、ご存知だと思いますが、UMLでは、型レベルの視点とインスタンス・レベルの視点があります。具体的には、クラス図の通常の（型レベル）のクラス図と、そのオブジェクトに着目した図（インスタンス・レベル）が、その典型例です。

同様にして、メタモデルにも、この2つの視点が取れ、図形表現にもその違いが反映されます。

図I10は、前回（第119回）にも登場した、"Clock"と言うステレオタイプのメタモデル図です。

この図を、インスタンス表現すると、図I12のようになります。
図中のすべてのクラス名には下線が引かれ、メタクラスのインスタンスである事を示しており、属性"name"は、分類子名（クラス名等）を表しています。
このようなメタモデル図の読み書きは、中級レベルを超えた内容であり、通常のモデラーはあまり気にする必要はありませんが、更に上位のモデリング技術を身に付けたい方（プロファイリング等を駆使したモデリングや概念モデリングを行う必要のある方）のために、簡単に解説致します。
図中に、"iscomposite"という属性があります。これは、拡張（Extension)と言う概念が、コンポジットの性質を使って構成される事に起因します。
ステレオタイプが定義されると、そのインスタンス（ここでは"Clock"）は、拡張される側のメタクラス（ここでは"class"）のインスタンスを（内部に）所有します。（コンポジット関連を思い出して下さい。）
これらの性質を2つのメタクラス、PropertyとExtensionEndを用いて表しています。
また、拡張の性質を表すメタクラス、Extensionには、"isRequired"と言う論理値を持つ属性があり、以前紹介した通り、この値がTrueであると、拡張される側の分類子は必ずステレオタイプで示される性質を持つ事になります。 （参考までに言いますと、頭に"is"が付く属性名は、通常論理値を持つ性質に付けられます。これは、文法的に決められている訳ではなく一種の慣習です。（ネーミング・コンベンション））
図I12

UML中級講座 第119回 ステレオタイプとアイコン

街を歩いていると、たまに昔流行ったビートルズのナンバーが流れていることがあります。
最近では、学校唱歌にも取り上げられているそうで、若い人にとっては音楽の教科書に載っている退屈な歌と言う印象があるようですが、これは致し方ない反応でしょう。

筆者の両親やその兄弟達は、所謂戦中派（この言葉もどの程度通じるのか危惧しておりますが）と呼ばれる世代で、筆者の少年時代には、彼らが酔っぱらって軍歌などを唄う姿を見て、鬱陶しく感じたものでした。
しかし、年月が経ち、自分が当時の彼らと同じ年ごろになった今、彼らの心境が多少理解出来るようになって来ました。

高校の同窓会名簿などを見ると、前後と比較して著しくの卒業生の少ない世代があります。この世代が戦中派の世代で、多くの人たちが戦争中に亡くなっています。彼らの青春時代は、まさに戦争下で、物心両面で強い制約下にあり、現代の青春とはまったく異なった姿をしています。
そして、彼らの青春の歌が軍歌だったのでしょう。
恐らく、筆者がビートルズを聞いて懐かしいと思うのと同様に、彼らも、軍歌を聴いて自分たちの青春時代を懐旧しているのだと思います。
軍歌が青春の歌であるとは、なんとも悲しい現実ですが、筆者を含め後生の人間に、それを禁じる資格はないと思います。

ステレオタイプの表示オプション

ステレオタイプは通常ギュメ（＜＜と＞＞）でキーワードを囲んで形で表現しますが、アイコンを用いてもっと図形的な表現をすることが可能です。ただし、これは文法的に可能だと言うだけで、皆さんのお使いのUMLツールがこのオプションをサポートしているかどうかは別問題ですので、ご注意下さい。

図I10は、メタクラス"Class"を拡張して"Clock"と言う名前のステレオタイプを作っていますが、この時に同時にアイコンも定義することが可能です。

図I10

図I11は、その表示オプションを示しています。
上段左の絵は、通常のステレオタイプの表現ですが、上段真ん中の絵は、ギュメで囲まれたキーワードの代わりに、アイコン（時計のシンボル）で表現しています。
また、上段右側は、四角形を用いずアイコンだけで表現しています。この表現が可能なのは、モデル要素が一つのステレオタイプのみの拡張である時です。
下段のように、複数のステレオタイプの拡張である場合は、アイコンだけの表現は、許されません。
また、複数のアイコンを一つのステレオタイプに定義する事も可能ですが、解り難くなるだけですので、通常は避けた方が良いでしょう。

図I11

もう既に、お気付きの方も多いと思いますが、実はUMLでは、このステレオタイプによる拡張のアイコン表現を標準に含んでいます。代表的なものは、アクター表現のスティックマンです。これは、ステレオタイプ＜＜ Actor ＞＞に定義されたアイコンです。

UML中級講座 第118回 プロファイルの適用

ビジネスの会話の中で、最も避けるべき話題は宗教と政治の話だと言われます。状況は国や文化風土、そして何より相手と自分との関係に大きく依存するとは思いますが、筆者の短見では、いわゆる自由諸国と呼ばれる国々の中で、アメリカはもっともこれらの話題を避けるべき国の一つだと思います。
2001年9月11日のいわゆる同時多発テロが発生してまもない頃、筆者はフランス人の友人達と、アメリカで開催されたPM（プロジェクトマネジメント）関係のあるコンファレンスに参加しておりました。
その当時、アメリカ政府は、このテロはフセイン政権の責任でありその確たる証拠もつかんでいるとして、盛んにイラク攻撃へ向かってボルテージを上げておりました。そして、ご記憶があるかと思いますが、フランスやドイツに代表されるヨーロッパの大陸側の国々は、アメリカの動きに反対していました。
２人のフランス人は、そんな中、アメリカ人に対して盛んにブッシュ政権を攻撃し、「確たる証拠があるのならすぐに提示すべきだ。無いから出せないのだろう」と、今から考えるとまったく正当な発言をして、アメリカ人たちの同意を得ようとしておりましたが、見る見るうちにフランス人と筆者の周りから人がいなくなってしまいました。

プロファイルの適用

今までの所で、既存のメタモデルを拡張しプロファイルを作成することは、ご理解頂けたかと思いますが、実際にそれをモデルレイヤーで適用するためには、明示的な宣言が必要です。これは、包含 ＜＜include＞＞や＜＜access＞＞等で、名前空間を指定してアクセスする場合と同じで、コンピュータ言語では、厳密に宣言して置く必要があります。モデル・ライブラリが大きくなればなるほど、同じ名前や似たような名前が増えて来て、明確に指定しておかないと、この問題は深刻な問題となります。JavaやCなどのプログラミング言語の大部分は、このようなメタ言語部分があります。
例としてC言語の場合を見てみましょう。

#include ＜stdio.h＞ ----------A

main()
{
int test;
・
・
printf("テスト結果は\n", test); ------------------ B
・
・
図 C言語の例

Aで示される文は、Cのコードから見るとメタ言語にあたり、#includeの引数は名前空間で、「標準I/Oライブラリを包含しなさい」と言うCコンパイラに対する命令を表しています。
この命令があるために、コンパイラは、Bのprintf()と言うI/O関数を、標準ライブラリから（標準のUNIXでは、/usr/include/stdio.hあたりから）見つけて来て、コンパイルすることが出来ます。

これと同じような事がプロファイルにも適用されます。


図 I09

図 I09では、”Webshopping”と言うパッケージが、”Java”と”EJB”と言う2つのプロファイルパッケージの適用を宣言しています。この（＜＜apply＞＞と言う依存関係で示される）適用宣言により、”Webshopping”パッケージ内では、JavaとEJBパッケージ内の定義が適用されることになります。

UML中級講座 第117回 パッケージ（プロファイル）

明日からサンフランシスコで開催されるOMG/BPMシンク・タンクの参加のため、出張します。今週はそのために、てんやわんやで忙殺されていましたが、ようやく一息つく事が出来ました。

パッケージ

UML1.4では規定されず、UML2になって初めて定義されたものに、パッケージがあります。（プロファイルを置く場所としてのパッケージの意。図I06参照）

図 I06 プロファイル・パッケージ表示例
（このHomeと言うステレオタイプには、アイコン ”○ ”も定義されている。）

図I07は、Javaエンタープライズ・エディション用のプロファイルです。図で示されているように、プロファイルでは、独立して一からメタモデルを構築することは許されず、何らかの元になるメタモデルが参照されます。
この例では、”Componet”、”Artifact”、”Interface”が（元になる）参照されるメタクラスです。


図I07

また、参照されるメタモデルが、パッケージ内に無い場合は、他のパッケージからインポートしてきて利用します。図I08では、”Manufacturer”というプロファイル用パッケージが、JavaIntegerやColorと言う型をインポートしている状態を表しています。
また、”Factory”と言う名前の通常の（メタモデルではない）モデルパッケージに”Manufacturer”パッケージを適用（＜＜apply＞＞）しています。（パッケージの適用がUML2になって、初めて明示的に定義されました。）
この適用により、”Factory”パッケージでは、＜＜Device＞＞と言うステレオタイプや、”Volume”というタグ付き値（メタ属性）が、使用可能になります。
図I08

UML中級講座 第116回 拡張（プロファイル・パッケージ）

本日は、以前触れた港北チベットと呼ばれる地方に滞在しております。

筆者の知人で、昭和40年代、小学生の頃この地に移り住み、そのまま定着してしまった人がおります。彼の話によると、その頃のこのあたりは、農村地帯と言うよりも、むしろ原野と言う言葉が似合うぐらい緑に覆われ、ところどころに集落があるだけで、道も極めて少なく舗装もされていなかったそうです。冗談でなく、知らない人が入り込むと、抜け出せないほど迷路のような細い道がくねくねと一貫性なく続いていたそうです。
それが、今や、地元に長く住んでいる人間でも、昔の地形がまったく分からないぐらいに近代的な町に変貌してしまいました。
ある横浜に関する考古学の書物によると、昭和40年代と言うのは、有史以来最も地形が人間の手によって変化した時代であり、遺跡などの発見数が最も多かったそうです。その時期をピークにして、最近では発見数は激減しているそうで、いかに凄まじい開発ラッシュの時期であったかを物語っています。

この傾向は、決して横浜だけではなく、ある程度、日本全国共通に見られた現象でした。
筆者は、小学生の頃、関西の神戸と言う港町に住んでいたのですが、この街も例外ではありませんでした。
当時、海側の部分はすっかり近代風の町並みになっていましたが、裏山から奥に入ると、そこは別天地のように自然が残っていました。小学生は、ほんの少し山に入るだけで、トンボ取りや魚釣りができました。

筆者が小学校3年生のころ、クラスにT君と言う転校生が入ってきました。何でも、九州の方から来たと言っていました。
彼は、授業中は極めて目立たない生徒でしたが、休み時間になると、ポケットから大きなクワガタや兜虫を取り出して机の上に並べ、皆を羨ましがらせていました。蝶々やトンボは裏山に行けばいくらでも捕まえられましたが、クワガタなんかは小学生の行ける範囲の場所にはいませんでした。
T 君は、皆からどこで捕まえたのかさんざん聞かれましたが、決してその場所を明かしませんでした。
そうしたある日、何を思ったのか、T君は筆者をクワガタ取りに誘いました。「絶対に秘密だぞ」と念を押しながら、裏山から細い山道へと身軽にスタスタと歩いて行きました。
小学生達がいつも行く範囲をあっという間に超えて、薮や潅木をスイスイと潜り抜け、道かどうか分からないような所を先へ進んでゆきました。そうして、どんどん山の中へ入って行き、はたしてちゃんと帰れるのかどうか心細くなってきた頃、T君は、立ち止まって黙って前方を指さしました。
そこは林の中にぽっかり空間が明いたような草地で、正面に大きなクヌギの木がありました。
彼がクヌギの太い幹を蹴飛ばしたり枝をゆすったりすると、上からパラパラと黒いものが落ちてきました。「それっ」と行って、彼は草むらに飛び込み、次の瞬間に高々と手を差し上げると、そこにはオオクワガタが握られていました。筆者も、慌てて草むらに這いつくばり虫を探しだし、メスのクワガタを捕まえることが出来ました。
その日以来、筆者はT君と友達になり、しばしば、その秘密の空間に行くようになりました。草地に寝転がったり、彼の持っている水晶の結晶を通して空を見たりして、秘密基地の気分を満喫していました。
しかし、そんな時間は長く続きませんでした。転入して半年も経たずに、T君はまたどこかへ転校する事になりました。母親に手を引かれたT君の後ろ姿は、普段よりも幼く見え、寂しそうでした。
そして、その秘密の空間も今はありません。
翌年の夏、筆者は弟達を連れて、クワガタ取りに出かけました。裏山を越えてしばらく行くと道が突然無くなり、がけになっていました。そこから先は、見渡す限り赤茶けた造成地になっていて巨大なショベルカーが何台も行き交っていました。もはや、秘密の空間がどこにあったのか、何の手がかりもありませんでした。

窓の外を眺めながら、この港北チベットにもきっとこんな物語があったに違いないと、想像しています。

拡張（プロファイル・パッケージ）

第115回で述べましたように、プロファイリングによる拡張は、MOFのレベルではメタクラス間の関連で表現され、関連であるために誘導可能性や多重度などの特性を持つことは先に見た通りです。

そして、多重度に関しデフォルト値を持ち、拡張される側の多重度は１、拡張する側のステレオタイプの多重度は0..1です。（第115回の図I 0３参照）

また特に、拡張する側の多重度が１である場合がプロファイルで規定されており、図I 05のA図のようにMOFレベルで拡張する側（Bean）の多重度が１であるような場合、プロファイル・レベルではB図のように拡張の矢印のそばに {required} と言うキーワードを付けて表現します。
これは、Componentのインスタンスには、必ずBeanと言うステレオタイプのインスタンスが伴うことを示しています。この性質は、JAVA Beansを定義する上で使用されています。


図I05

UML中級講座 第115回 プロファイルとMOF

知人に、茨城県から都内の職場へ通っている人がおります。長年、常磐線を使っていたそうですが、最近、筑波エクスプレスが開通し、通勤環境が劇的に向上してきたそうです。

筆者は、この話を聞いて、今から20年ほど前、高校時代の友人が就職で関西から上京し、初めてMという常磐線に近い町に住み始めた頃の事を思い出しました。友人は、学生時代まで関西でしたので、東京に土地勘がなく、なんとなくMに引越したそうです。Mと言う町は（市かも知れません）田園風景の中ののどかな場所だそうで、町そのものには何の不満も無かったそうですが、通勤の行き帰りに利用する常磐線の混み方が半端でなく酷いと、当時、久々に会った筆者に訴えていました。
まず、混んでいる状態の判断基準が違うそうです。
常磐線では、ホームに電車が入ってきてドアが自動的に開くようでは、混んでると言ってはいけません。
列車がホームに近づくと、乗客たちは、ホームに待っている黒山の人だかりをみて、これ以上乗ってきては困ると、盛んに圧力を上げてドアが開かないように抵抗を試みます。
ホームで待っている人たちは、この文字通りの無言の抵抗に対し、外から自動ドアに手をかけ思いっきりひっぱって開けるそうで、その際、中から二、三人、勢い余ってホームへころげ落ちてきます。
そんな大混雑なのに、不思議なことに、あれだけホームに人が溢れていたにも関わらず、最終的に皆乗れてしまうのは、どういうわけでしょうか？友人も、それは謎だと言っていました。
友人は、ラッシュの中で、2度ほど眼鏡を無くしたそうです。あっという間に人と人の間に消えて行ってしまい、まったくどうしようもなかったそうです。
また、車内の圧力で窓ガラスがしょっちゅう割れるらしいのですが、皆慣れっこになっていて、血を流している人も含め、「ああ、またか」と言う感じで平然としているらしいのです。

彼の話を聞いて、あまりの壮絶さに「常磐線恐るべし」と言う固定観念が植え付けられてしまい、ラッシュ時の常磐線は極力近づかないようになってしまいました。今でも、こっちの方面は、まったくと言っていいほど土地勘がありません。
その結果、幸か不幸か、この話がどの程度ほんとうかは、20年以上経っても実地に体験する事が無く真実はわかりません。
ただ、たまに、常磐線で通勤していると言う人に会った時に、この話をしても、皆、否定しないので、かなり真実を突いているのでは、と想像しています。

茨城県から筑波エクスプレスで通っている知人は、この電車のおかげで、通勤環境が地獄から天国に上がったと言っています。そう言えば、声のピッチも三度ほど上がったような気がします。しかしながら、筆者は昔のイメージが強いため、実際に乗って確かめる勇気はありません。



プロファイルとMOF

前回お話しましたように、プロファイルは元の言語体系を変えずに拡張のみを行なうのに対し、MOFは、基本的にメタモデルを自由に変更する事が可能です。その意味で、MOFはプロファイルの機能を含むと言う言い方が出来ます。
そして事実、プロファイルで拡張したものを、MOFの表現で記述することが出来ます。

図I04は、インターフェースと言うメタクラスを拡張し、ホームと言うステレオタイプを拡張しています。

図 I04

これと同等の表現をMOFモデルを使って書くと、図I03のようになります。MOFによる拡張は、この図に示されるように、コンポジット集約の形になります。元のメタクラス「インタフェース」がステレオタイプ「ホーム」（これもメタクラスです）を占有し、かつステレオタイプ側から、コンポジット側（元のメタクラス）への誘導可能性が必要になります。（つまり、両方向へ誘導可能）
コンポジット側の多重度は1となりますが、［ホーム」側のインターフェースは、0..1となっています。
前者は、コンポジット集約であることの制約により当然１ですが、後者は、0..1以外の多重度を持つ場合があります。これについては、後日、解説致します。

図 I03

UML中級講座 第114回 インタフェースの拡張例

筆者が２０代の頃、アメリカにしばらく住んでいたことがあったのですが、ご存知の通りアメリカの会社は4時過ぎぐらいになると社員が皆帰ってしまい、アメリカに来て間もない頃は、退社後の時間をどうやって過ごすかは、一つの重要な課題でした。
筆者が住んでいたのは、アメリカ南部の田舎町で（ノースカロライナ州の州都、ローリーと言う町です）、ゴルフ場とかテニスコートなどはやたらあるのですが、東京の六本木や渋谷のような若者が好みそうなナウい（死語 失礼）繁華街はありませんでした。たまに、職場の人間とゴルフをしたり食事をしたりする事はあったのですが、とても毎日と言う訳にはいきません。
日本にいる時は、テレビはほとんど見なかったのですが、退屈を持て余してスイッチを入れる事も多くなりました。しかしながら、言葉の問題もありますが、正直言って全然面白くなく、10分もするとテレビの前にいるのが苦痛になって来ます。
その当時、アメリカ人の友人で100チャンネル以上映るテレビを持っている人がおり、筆者も映るチャンネル数を増やす契約をしようかと相談した所、実は、彼自身もほとんど見ておらず、家族、特に子供が見ているだけと言うことが判明しました。彼は、「くだらない１０個のチャンネルが、くだらない100個のチャネルになるだけだ。」と言い捨てていました。
個人差はあると思いますが、２０〜30歳以降の男は段々テレビを見なくなっていく傾向があるように感じます。筆者も、小学生の頃はテレビが大好きで、ニュースと相撲以外の番組をほとんど見ない自分の父親を不思議な気持ちで眺めていましたが、気がつくと自分がそうなってしまいました。
たまに友人と旅行先の旅館などでテレビを見たりしますが、筆者などは10分も経たずに降参してしまいますが、中には1時間以上一心不乱に見入っている人がいたりします。「面白いか？」と聞くと、「いや全然」と答えながら平然と見続けていたりします。こういう人は、きっと長時間の座禅なども平然と組めるタイプでしょう。

インタフェースの拡張例

前回、プロファイルによって、ほとんど全てのUMLモデル要素を拡張出来るお話をしましたが、本日は、例としてインタフェースの拡張を見てみましょう。

図I-01の(A)図は、メタクラス”Interface”を拡張し、"Remote"と言う名前のステレオタイプを定義していることを示しています。
この絵は、いわゆるメタモデル図であり、言語を拡張していることを示しています。
この拡張により、ステレオタイプ＜＜Remote＞＞が、ユーザーモデル層で使用可能になります。
（B)図は、その表記例です。
この図中の「テスト」と名付けられたエレメントは、インターフェースの性質を引き継ぐと共に、「Remote」で定義された性質（メタ属性やアイコンなど）を継承します。


図 I-01

UML中級講座 第113回 拡張

5月の連休中に都内某所のビルにこもって書き物系の仕事をしていたのですが、どうも、それ以降、体調がすぐれず、オフィスの移転等もあって普段よりも忙しかったせいもあり、ブログを書く余力がありませんでした。
月が変わり、6月に入りようやく本来の調子を取り戻しつつあります。

実は、連休中にこもっていたビルは、オフィスの移転先の候補としても考えていたのですが、諸般の事情により取りやめた場所でした。見晴らしも良く、都心であるにも関わらず静かであり、非常に好条件でした。個人的には大変気に入っており、連休中のため、移転先のオフィスのごたごたがなかなか片付かない状態でしたので、無理を言って、一週間ばかり一室を書斎のように使わせてもらっていました。
ゴールデン・ウイークのためビルにまったくと言っていいほど人影はなく、ビルを独り占めしているかのような状態でした。筆者は、書き物系の仕事になると生活が段々夜型にシフトして行く性格（タチ）ですが、この時も徐々に帰宅が深夜帯になってきました。
最後の日、筆者は夜の2時半ごろ仕事を切り上げ部屋を出ました。暗い廊下の向こうにエレベータ・ホールがあり、ランプが下の階からエレベータが昇って来つつあることを示していました。こんな時間に、いったい誰がエレベータに乗っているのか訝しく思われ、入口から少し離れた所で立ち止まって見ていました。日中も含め、ほとんど誰にも会わない状態でしたので、ひょっとしたら”ビル荒し”などが入ってきたのでは、と良からぬ想像が頭に浮かんだり、もし、この階（最上階でした）に見知らぬ人物が昇って来たら、どういう言葉で挨拶しようかなどとつまらないことを考えたりしながらランプの動きを見ていました。こういう時は、ビルの隣が墓地であることも脳裏をかすめたりします。
そうしているうちに、エレベータは最上階まで昇ってきました。暗い廊下に明るい影を映しながらドアが開きましたが、誰も降りて来ません。エレベータは無人で昇ってきたのでした。
きっと、最後に乗った誰かが間違えてこの階のボタンを押したのだろうと自分自身に思い込ませながら、筆者はエレベータに乗り一階まで降りて行きましたが、乗っている間、いい気持ちはしませんでした。
体調がくずれ始めたのは、その日以降です。翌日は結構熱が出ました。きっと気のせい、あるいは偶然だと思いますが、誰かに話すことにより、気も晴れるだろうと思い、このブログに書いてみました。


拡張の表現

前回に述べましたように、プロファイルを用いた拡張は、既存の言語のルールはそのまま温存します。そして、事前に定義されているUML図の構成要素（エレメント）に新規に機能を付け加え、（同じ名前ですと言語を変更してしまうので）別の名前を付けて言語体系に付け加えます。この新たに付けられた名前をステレオタイプ名と呼びます。
図I-02で示される矢印は、拡張を表現します。ターゲット側に拡張される側の既存のエレメントを置き、ソース側に拡張の結果生成される新たなステレオタイプを書きます。
拡張される側のエレメントは、クラス、コメントなどほとんど全てのUMLエレメントが対象となりますが、唯一例外があり、ステレオタイプ自身はプロファイルにより拡張することができません。

図I-02

次回は、この拡張の具体例の表記を見てみましょう。

UML中級講座 第112回 プロファイル

オフィスの移転も終わり、ようやく落ち着いてきました。


プロファイル
プロファイル概説

UML言語の拡張

UMLを使用する上で、言語そのものをカスタマイズしたい、あるいは拡張したいと言う要求は、常に存在します。そして、OMGの標準では、UML1.1の段階から、ステレオタイプおよびタグ付き値で、言語の拡張機能を提供してきましたが、必ずしもその定義は厳密ではなく明確さに欠ける部分がありました。
この問題を解決するために、UML2.0では、プロファイルという言葉が、メタモデリングのテクニックとして、より構造的、より正確に定義される事になりました。
ステレオタイプそのものは、既に皆さんご存知だと思いますが、キーワードをギュメで括って表現します。
ほとんどの場合、ステレオタイプは、標準ステレオタイプと呼ばれるあらかじめUMLで事前に定義されている種類のみを使用しますが、場合により自分固有のステレオタイプを付け加えたい事があります。
下の図は、プロファイリング機能により、通常のクラスを拡張して、Galaxy（銀河）、Rocket（ロケット）、QoSCategory(サービス品質カテゴリー）を表示しています。
UML2.0（もしくは最新の2.1)に対応しているツールでは、このプロファイリングの機能に対応しているケースが多いのですが、表示方法はツールにより異なりますので、この図のように写真表示やアイコン表示ができるとは限りません。（この図は、Visual Paradigmと言う製品を使って書いています。）

なぜ拡張するのか？

なぜ拡張する必要があるのかは、必ずしも一定の法則がある訳ではなく、モデラーによりまちまちですが、代表的なケースとして、次のような場合が上げられます。

• 特定のプラットフォームやドメインに固有の専門用語を使用したい場合
• 別のシンボル、アイコンを使いたい場合
• 既存のメタモデルに、新たにセマンティクスを付け加えたい場合
• 既存のメタモデルに、制約を付け加えたい場合
• モデル変換の際に必要な情報を付け加えたい場合

また、往々にして、これらの要件が複数重なって拡張を行なう必要が発生したりします。

プロファイリングとMOF

プロファイリングは、メタモデル構造をいじりますが、その大前提として、UMLそのものの構造や振舞いは一切変えることはできません。例えば、メタモデルの汎化関係のなかに新たなメタクラスを付け加えると言った事はできません。（下のメタクラス（特化メタクラスあるいはサブメタクラス）に影響を与えてしまいます）
メタモデルを変更すると言うことは、新たに言語を作ることに等しい訳で、これはMOFの範疇に所属します。
ファンダメンタルのレベルで学習したように、メタモデル構造はUML言語だけが持つ訳ではなく、JavaやCWMと言った言語も持ち、最近ではBPMN(Business process Modeling Notation)も、MOFにより定義されています。
プロファイルは、あくまでも既存のUMLの言語構造を温存し、その上に機能を拡張するものです。

UML中級講座 第111回 配備のメタモデル

気がつくと、いつの間にか冬が終わり、桜も満開になってきました。東京地方では、先週辺りから「お花見」の風景が良く見受けられます。
筆者は、学生時代に関西から東京に移動して来た組ですが、東京と関西ではお花見の仕方がちょっと異なります。この違いは、吉田兼好の徒然草にもその記述があることから、少なくとも鎌倉ー室町時代から存在していたようです。
今は知りませんが、昔、筆者の子供時代の頃は、関西（神戸）では、花見と言うと、ただ見るだけで、花の下で宴会している風景はほとんど見られませんでした。
筆者の東京風の花見デビューは、新社員の時で、どこかの公園へ宴会の場所取りに行かされたのが最初です。日中早々に場所を確保し、会社の同僚達が来るまでの時間、寝転がって桜の花と青い空、そして白い雲を眺めながらビールを飲んでいると、こう言う花見の姿もいいもんだな、としみじみと感じたことを思い出します。
はた目から見ると、あまりみっとも良い姿とは言えず、兼好法師が批判した気持ちもわかりますが、中に入ると別の感慨が湧いてきます。こう言うのを視点の相違と言うのでしょうか、その立場で、見てみないとわからないものです。


配備のメタモデル

図１０−０４は、配備のメタモデル図です。DeploymentTarget(配備する場所を示す）とDeployedArtifact(配備される内容物）は、配備（Deployment)によって関連付けられています。DeploymentTargetは配備を所有する形の定義です。
DeploymentTargetはプロパティと汎化関係を持ちますが、これによりDeploymentTargetは内部構造を持つことができます。
また、DeploymentTartgetとDeployedArtifactは、共にInstanceSpecificationと汎化関係を持ち、UML図でインスタンスレベルでの表現を可能にします。


図１０−０４

UML中級講座 第110回 ノードのメタモデル

筆者は、普段はできるだけ車や電車を使わず自転車で移動することを心がけています。自転車乗りの人はよくご存知だと思いますが、自転車は、道が平らであると長い距離も苦にならず、どこまでも気楽に行くことができます。
従って、自宅のある新宿から青山とか六本木辺りは、毎日我が庭のように走り回っていましたが、オフィスを移転するまでは、赤坂方面にはほとんど足を踏み入れることはありませんでした。
これはひとえに、赤坂近辺が名前の通り起伏が激しく坂道が多いためでした。赤坂のオフィスのまわりには、かつて幽霊が多く出現したので幽霊坂と名付けられた坂や、のっぺらぼうが出現することで有名な紀伊国坂、忠臣蔵で有名な南部坂など、大小様々な坂がたくさんあります。
しかし不思議なことに、赤坂と言う名前の坂は存在しません。この辺りは、かつて第２次大戦前は赤坂区と呼ばれたほど広範な地域を包含していた地名なので、現在赤坂と呼ばれている地域以外の隣接する区の地名も探してみましたが見つかりませんでした。そして調べて行くうちに、この謎を解くヒントは「元赤坂」という現在も残る地名にあることが解りました。
江戸時代の地図を見ると、赤坂と言う坂はありませんが、［元赤坂町」という町名がそのころから既に存在していたことがわかります。場所も現在の元赤坂とほぼ同じ地域を指し迎賓館から赤坂離宮を中心とした一帯を指す地名です。この辺りは、江戸時代は紀伊和歌山藩の中屋敷があった所ですが、江戸時代以前は茜山（あかねやま）と呼ばれる小さな山だったようです。茜山の語源も諸説あるようですが、一説によると古代の染料の原材料である茜がたくさん生えていたからと言われています。そうして、その茜山に登る坂道が茜坂（あかねざか）と呼ばれていたようです。現在、紀伊国坂と呼ばれる坂も茜山に登る当時の山道の一つです。
そして茜坂が訛って赤坂となったと言う説が、最も有力な説になっています。この説の一つの傍証として、明治の始めの頃、紀伊国坂の麓に茜坂小学校と呼ばれる学校が存在していた事があげられます。（但し、古名が伝わって名付けられたのか、伝説をもとに名付けられたのか、今となっては不明）
恐らく、紀州藩の屋敷を建てる時に地形も多少変わってしまい、赤坂もしくは茜坂と呼ばれる元の地形、原風景は存在しなくなってしまったのだと思いますが、地名だけは伝えられて来たようです。




ノードのメタモデル

図１０−０３の左図は、ノードのメタモデルを表しています。ノードは、クラスを特化しており、クラスの性質を継承します。ノードには、ハードウエア環境を示すデバイス（＜＜Device＞＞）と、ソフトウエア環境を示す実行環境（＜＜Execution Environment＞＞）の二種類があり、ノード同士を入れ子にすることが可能です。

また、ノード間のネットワークを示すコミュニケーションパスは、クラス間の関係である関連の一種として定義されます。

図１０−０３

UML中級講座 第109回 成果物のメタモデル

最近は、様々な用事で忙殺されております。今週は、前回にも書きましたように横浜のチベットにこもっておりますが、今週末から来週にかけてはOMG総会のためサンディエゴへ出張することになりました。
また、昨年秋にオフィスを引越したばかりですが、入居しているビルがなんと耐震強度が弱いことが判明して建替えることになってしまい、来月中にどこか別の場所へ引越さなければならないことになりました。

筆者は生来、引越が好きな方ですが、まだ一年も経っていない上に、新しい物件を見に行く暇もない状態で、正直の所辟易しています。
筆者のささやかな希望としては、青山近辺で、すぐそばに気の利いた静かなカフェがあり、お客様が来られたら、カフェでエスプレッソでも飲みながら談笑する、というのが良いのですが、そんな所は、なかなか見つからないでしょうね。

成果物のメタクラス

図10-02は、成果物（Artifact)のメタモデル図です。
成果物は、ソースコードのファイルとか実行モジュールとか言った、ソフトウエア開発プロセス上で物理的実体を持つものを表しますので、クラスの一種として定義することも可能ですが、UML2.1では、図10-02のように分類子を特化してクラスとは別に独立して定義しています。これは、恐らく、クラスから定義すると、成果物では使わない様々な性質を継承してしまうことを嫌ったからだと思います。
また、このために、逆に、オペレーションとかプロパティ（属性等）と言ったクラスでははじめから用意されているものを、定義付けしてやる必要があります。（関連は、分類子が元から持っている性質ですので定義不要。）

具現は、主にコンポーネントやノードが対象になりますが、メタモデル上では、「packageableElement」を包括的に指定しています。これにより、成果物はモデル図中で用いられる全てのエレメントを定義するモデル図ファイルであることも可能になります。

図10-02

UML中級講座 第108回 ノードの種類

最近は、仕事で横浜の方へよく行きます。横浜と言っても、港の方ではなく、かつて横浜のチベットと言われた山の方ですが、このチベットと呼ばれる地域は横浜市内に何ヶ所もあるそうで、横浜出身の人が話をすると我こそは本当のチベットだと言って秘境自慢争いが始まるほどです。

筆者が通っている所は、港北ニュータウンの中で、都筑区と呼ばれる所にあり、スギ花粉の多い所です。
このあたりは、かなり古くから開発された所らしく、貝塚や縄文遺跡に始まり、平安時代に編纂された続日本後紀には、都筑郡の「杉山神社」が霊験あらたかであると記録されています。
また、東海道より古いと言われる中原街道もこの地域をまっすぐに縦断しており、杉山神社も分社に分社を重ね、今では70以上になり、元々どこにあった神社なのか解らなくなってしまったほどです。郷土史家の間では、数多くの杉山神社の中で、延喜式に記された大元の神社はどれか？と言うことが話題になっています。

筆者は全くの門外漢なのですが、この手の話題は好きな方なので、かつて、有力な候補を廻ってみたことがあります。古来、有力候補としていくつかの杉山神社が揚がっていますが、筆者は新吉田の杉山神社が最有力と見ています。「杉山」という小字名があること、古墳が祭られていることのほかに、いかにも杉が好んで栄えそうな場所にあることが、杉山神社という名の起こりを想起させる点が、気に入っている点です。

ノードの種類

ノードには2種類あります。一つは、主にコンピュータ資源であるハードウエアを表すもので、デバイス（＜＜Device＞＞）と呼ばれ、もう一つは、主にソフトウエア環境を示すもので、実行環境（＜＜ExecutionEnvironment＞＞）と呼ばれます。共に、成果物、Artifact、を配備することができます。


図H10は、実行環境の例で、J2EE環境下に各種のJarが配備されている状況を示しています。

図H10

また、図H09はデバイスの例で、2つのデバイス・ノードがコミュニケーションパスで繋がれてネットワークを形成しています。また、左のデバイス・ノードには、実行環境ノードが配備されています。

図H09

UML中級講座 第107回 配備、配備仕様の表現

先日、若い知人とBPMに関してミーティングをしていたところ、話題が昨今のITエンジニアのいわゆる３Ｋ化の問題になりました。
彼の廻りの同年配の知人友人達は、4〜5年前まではIT企業を辞めても、またIT関連の企業に就職することが多かったのが、最近では、全くの異業種へ転職するようになってきているそうです。

筆者は、若い頃は、「日本には日本のやり方がある」という意見に反発を感じていた方ですが、歳を取るに従い、従来のやり方に拘る年長者の気持ちも理解出来るようになってきました。しかしながら、この3K化の問題に関しては、日本の従来のやり方が間違っていると強く感じています。あえて失敗と呼んでいいとさえ考えています。

この３Ｋ化の問題は単に勤務時間が長いと言う点だけが問題なのではなく、様々な複合的な問題のようです。一々挙げるときりがありませんが、代表的な問題としては、上流工程の品質が劣悪で、その皺寄せが開発工程を直撃している、とか、IT企業がゼネコン化し、孫請けなどは当たり前で、5次受け6次受けなどもざらに存在し、中間搾取が甚だしい、あるいはエンジニアの技術レベルが低い、、等々。

そして、その多くが日本固有の状況である事を示しており、日本固有の解決策が必要です。（欧米の先進企業の部分的な模倣では決して解決しないことが、だんだんと明らかになってきました。）

そして、ここに興味深い事実が１つあります。多くの方々が、BPMが問題の解決あるいは現状の改善の糸口になる、あるいは、なって欲しいと期待していることです。
IT産業では、かつて、新しいテクノロジーの出現により、市場が激烈に変化したり、価値基準が逆転したりするような事が何度も発生してきました。日本の強固な労働慣行でさえ、強く影響を受けています。
BPMは、生産工程のテクノロジーと言うよりも、ホワイトカラーのテクノロジーと言う面が強く、人々の期待も決して根拠のないものではありません。

さて、筆者の短見では、BPMはもろ刃の剣に感じます。
この件については、今後また触れたいと思います。

配備、配備仕様の表現

前回（第106回）、ノード内に成果物を記述して、配備を表現する形式を解説しましたが（図H07 参照）、
同じことを、図H08のように、配備を示す依存関係（＜＜Deploy＞＞を使って表現することも可能です。

図H08

UML中級講座 第106回 配備仕様

今週は、カナダのモントリオールに滞在しております。モントリオールは、ボストンと同じく米大陸としては古くから開けた都市で、町並みもヨーロッパ調です。また、住民の多くはフランス語を話し、地名や駅名も殆どがフランス語ですので、まるでフランスに来たような錯覚に囚われます。
ここは、ボストンに輪をかけて寒く、石造りの建物の間を縫う石畳の街路に人影はまばらで、時間が凍ってしまったような印象を受けます。たまに通り過ぎる人々も、ファッションを気にする若い女性を除くと、みんな南極探検隊のような格好をして無言で歩いています。
こんな街ですので、一人で夕暮れ時に歩いていると、不思議なエキゾチシズムの感に襲われます。こんな感覚は、海外旅行をしても、絶えて久しく感じたことがなかったのですが、あえて言うと、昔の神戸の異人館街にあったような、ある種のノスタルジーに似た感覚、自分が見知らぬ街でエトランジェ、異邦人になってしまったような感覚と言えば、多少ご理解頂けるでしょうか。
筆者は、ホテルの裏の雪の残る石畳の細い通りを歩いている時に、暗い電飾の窓越しに古いアンティークの電話機を見つけ、思わず店に飛び込みました。骨董屋とも雑貨屋ともつかない店の中は意外に広く、思わず目当ての電話機以外のものも買ってしまいました。

配備仕様

配備仕様（Deployment Specification)は、コンポーネントがノードに配備される際の実行オプションを記述したもので、例としては、実行場所や、並列処理の指定、トランザクション処理の指定などが挙げられます。
図H07は、AppServer1ノード内のShoppingCart.ear（＊）に配備されるOrdder.jarの配備仕様がOrderdesc.xmlであることを示しています。

図H07

配備は、タイプレベルもしくはインスタンスレベルで表現することが可能で、図H06は、配備仕様のタイプレベルとインスタントレベルの記法を示しています。

図H06

(＊）EARは、Enterprise Archiveの略で、Java EEアプリケーションのパッケージ形式。WAR(Web Application Archive)やEJB(Enterprise Java Beans)、Jar等を包含することが可能。

UML中級講座 第105回 ノード内の配備

マサチューセッツ州は、伝統的にリベラリズムの影響が強く、民主党支持の州として知られています。そして、ご想像の通り、昨今のブッシュ政権に対する評価は、最大限上品に言って「糞のレベル」にあります。

昨日、リベラルアーツを形だけまねて中身が伴っていない大学教育の話をしましたが、どういう点が違うかと言うと、基本的な学習項目には、あまり差がないのですが、こちらのリベラルアーツの学校の最大の特長は、少人数教育であり、全人格的な教育が期待されていることです。
日本の形骸的なリベラルアーツの教育は、必ずしも大学や為政者の意思ではなく、60年代70年代の学生運動に示されるように、学生側の意思であった面もあり、一概に誰の責任と決めつけるのは難しい所です。
また、リベラルアーツ系にも大きな欠点があります。教育費が、べらぼうに高いことです。
アメリカの大学の学費は、中流家庭にとっても、極めて大きな負担であり、そのために奨学金制度などもありますが、十分ではありません。そして、向学心はあるがお金がない若者にとって最もポピュラーで、かつ名誉ある方法が、兵士になることです。
何年かの兵役を務めると、軍から大学の学費を得ることができます。
今現在、イラクに相当数のアメリカの若者達が行っていますが、多くは、軍からの奨学金を得るためだと言われています。

今回、筆者が訪問したオフィスに、十代の頬の赤い兵士の写真が飾っている方がおられました。聞くと、息子が来月からイラクに行くことになったと言われます。

一般に、アメリカでは、公務員は日本ほど良い職業とは見做されていませんが、幾つかの例外があり、警察官や消防士、そして兵士など、第一線で危険な公的サービスに従事する人たちは、社会から一定の敬意をもって遇されます。（それに対して、バックオフィスの公務員は、最も好意的な言い方をしても、民間に就職出来なかった気の毒な人たちと見做されます）

イラクの問題は、自分たちの子供が戦地に赴く問題であり、ブッシュ政権に対する評価は、極めて微妙です。

ノード内の配備

前回は、ノード内の配備を表す方法として、ノードのシンボル内に配備する成果物のシンボルを書き込む形式を紹介しましたが、成果物のシンボルを使わずに名前のみを書いて表現することも可能です。（テキスト表現）
図H05は、AppServer1内の成果物をテキスト表現で示しています。


図H05

UML中級講座 第104回 ノード

今週は、BPM関係の仕事でOMGの本部を訪問しております。

OMGの本部は、ご存知の方も多いと思いますが、米国マサチューセッツ州のボストンにあり、冬の気温は氷点下になることが珍しくなく、日本の感覚で言うと、雪のないスキー場に来たような感じがします。
ボストンは、人口はたいして多くないのですが、日本でも、そして世界でも有名な街です。
日本では、高校の歴史で習う「ボストン茶会事件」や「ボストンバッグ」で有名ですが、後者のボストンバッグは日本固有の呼び方で、ボストンでは通じないと、こちらが尋ねる前に現地のアメリカ人に教えられました。（よっぽど、良く聞かれるのでしょう）
ボストンバッグは、戦後の日本へボストン大学の学生が持っている姿が紹介されて、そこから命名されたようです。

さて、ボストンやその週辺地域は、名門大学が多く、マサチューセッツ州は別名、教育州と呼ばれるほどです。
先ほど挙げたボストン大学をはじめ、ハーバード大学やマサチューセッツ工科大学(MIT)、また芸術分野ではバークレー音楽大学なども、このあたりにあります。（OMG本部のメンバーも、自然と、こう言うかしこそうな大学の卒業生が多いようです。）
アメリカの中上流家庭では、リベラルアーツの伝統を重んじる気風が残っており、幼少期から貧困を経験したことのない自分たちの子弟を、田舎の小さな街で一人暮らしさせ、文学や哲学、そして自然科学などをじっくりと学びながら、今後の人生の進路を考えさせたいと思う親が多いようです。（背景には、貧困は、人生の最善の教師という考え方があるようです）
そして、その後に、専門の職業教育（法学や医学、経営学、工学等々）を学ぶと言うコースが一般的です。
実は、こう書いていて、ふと気付いたのですが、日本の戦後の大学教育も、アメリカのリベラルアーツ重視の姿勢を模倣したものでありました。
個人的な体験を極端に一般化するようで、少し気が引けますが、筆者は、大学入学時は全員が教養学部に入り、その後、専門学部を自由選択できる仕組みの（リベラルアーツの考え方を忠実に再現したような形の）大学におりましたが、残念ながら、模倣したのは形だけで、中身は全く伴っていなかったような気がします。
これは筆者一人の感想ではなく、友人達もみな教養課程の内容に不満を感じていました。
筆者が教養課程で唯一有意義だったと思われる経験は、故廣松渉先生の哲学の講義へ出席出来たことぐらいで、他の授業は殆ど何の感銘も得ることができませんでした。

筆者は、六本木ヒルズに住み美女に囲まれた生活をしている方々に対しては、さほど羨ましいと感じたりしませんが（負け惜しみに聞こえるとは思いますが）、アメリカの片田舎にある伝統的なリベラルアーツ重視の学校（日本では知名度が低いですが）で勉学に励む方に対しては、羨望の思いを禁じえません。
教育は、形だけまねるのはすぐできますが、中身の充実には長い年月が必要なようです。マサチューセッツ州にあるいわゆる名門大学は、日本のどの大学よりも長い歴史を持っています。
日本も大学の独立性が増してきた今、カスタマー・ボイスに真剣に耳を傾けることにより、教育内容も充実したものになって行く事でしょう。

ノード

ノードは、成果物（＜＜artifact＞＞)に実行環境を提供する計算機資源のことで、ハードウエア資源やソフトウエア資源の両方を包括します。
ノードの例として、アプリケーション・サーバー（＜＜application Server ＞＞）、クライアント・ワークステーション（＜＜client workstation＞＞）、携帯機器（＜＜mobile device＞＞）、組込み機器（＜＜embedded device＞＞）等が挙げられます。

ノードは、メタモデル的にはクラスの一種ですが、図H03のAppServer1のように、箱形のシンボルを使って表現します。（当然の事ながら、分類子の四角形とステレオタイプを用いて表すことも可能です。）
また、ノードのなかに成果物などを入れて、成果物がノードに配備されていることを示すことが可能です。
図H03では、ShoppingCart.jarとOrder.jarの二つの成果物が、ノードへ配備されていることを示しています。（また、図中の依存関係は、ShoppingCart.jarがOrder.jarに対して、何らか形で依存していることを意味しています。）
図H03の配備関係は、図H04のようにステレオタイプ＜＜deploy＞＞を用いて表すことも可能です。

図H03

図H04

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