知人に、茨城県から都内の職場へ通っている人がおります。長年、常磐線を使っていたそうですが、最近、筑波エクスプレスが開通し、通勤環境が劇的に向上してきたそうです。
筆者は、この話を聞いて、今から20年ほど前、高校時代の友人が就職で関西から上京し、初めてMという常磐線に近い町に住み始めた頃の事を思い出しました。友人は、学生時代まで関西でしたので、東京に土地勘がなく、なんとなくMに引越したそうです。Mと言う町は（市かも知れません）田園風景の中ののどかな場所だそうで、町そのものには何の不満も無かったそうですが、通勤の行き帰りに利用する常磐線の混み方が半端でなく酷いと、当時、久々に会った筆者に訴えていました。
まず、混んでいる状態の判断基準が違うそうです。
常磐線では、ホームに電車が入ってきてドアが自動的に開くようでは、混んでると言ってはいけません。
列車がホームに近づくと、乗客たちは、ホームに待っている黒山の人だかりをみて、これ以上乗ってきては困ると、盛んに圧力を上げてドアが開かないように抵抗を試みます。
ホームで待っている人たちは、この文字通りの無言の抵抗に対し、外から自動ドアに手をかけ思いっきりひっぱって開けるそうで、その際、中から二、三人、勢い余ってホームへころげ落ちてきます。
そんな大混雑なのに、不思議なことに、あれだけホームに人が溢れていたにも関わらず、最終的に皆乗れてしまうのは、どういうわけでしょうか？友人も、それは謎だと言っていました。
友人は、ラッシュの中で、2度ほど眼鏡を無くしたそうです。あっという間に人と人の間に消えて行ってしまい、まったくどうしようもなかったそうです。
また、車内の圧力で窓ガラスがしょっちゅう割れるらしいのですが、皆慣れっこになっていて、血を流している人も含め、「ああ、またか」と言う感じで平然としているらしいのです。
彼の話を聞いて、あまりの壮絶さに「常磐線恐るべし」と言う固定観念が植え付けられてしまい、ラッシュ時の常磐線は極力近づかないようになってしまいました。今でも、こっちの方面は、まったくと言っていいほど土地勘がありません。
その結果、幸か不幸か、この話がどの程度ほんとうかは、20年以上経っても実地に体験する事が無く真実はわかりません。
ただ、たまに、常磐線で通勤していると言う人に会った時に、この話をしても、皆、否定しないので、かなり真実を突いているのでは、と想像しています。
茨城県から筑波エクスプレスで通っている知人は、この電車のおかげで、通勤環境が地獄から天国に上がったと言っています。そう言えば、声のピッチも三度ほど上がったような気がします。しかしながら、筆者は昔のイメージが強いため、実際に乗って確かめる勇気はありません。
プロファイルとMOF
前回お話しましたように、プロファイルは元の言語体系を変えずに拡張のみを行なうのに対し、MOFは、基本的にメタモデルを自由に変更する事が可能です。その意味で、MOFはプロファイルの機能を含むと言う言い方が出来ます。
そして事実、プロファイルで拡張したものを、MOFの表現で記述することが出来ます。
図I04は、インターフェースと言うメタクラスを拡張し、ホームと言うステレオタイプを拡張しています。
図 I04
これと同等の表現をMOFモデルを使って書くと、図I03のようになります。MOFによる拡張は、この図に示されるように、コンポジット集約の形になります。元のメタクラス「インタフェース」がステレオタイプ「ホーム」（これもメタクラスです）を占有し、かつステレオタイプ側から、コンポジット側（元のメタクラス）への誘導可能性が必要になります。（つまり、両方向へ誘導可能）
コンポジット側の多重度は1となりますが、［ホーム」側のインターフェースは、0..1となっています。
前者は、コンポジット集約であることの制約により当然１ですが、後者は、0..1以外の多重度を持つ場合があります。これについては、後日、解説致します。
図 I03
筆者が２０代の頃、アメリカにしばらく住んでいたことがあったのですが、ご存知の通りアメリカの会社は4時過ぎぐらいになると社員が皆帰ってしまい、アメリカに来て間もない頃は、退社後の時間をどうやって過ごすかは、一つの重要な課題でした。
筆者が住んでいたのは、アメリカ南部の田舎町で（ノースカロライナ州の州都、ローリーと言う町です）、ゴルフ場とかテニスコートなどはやたらあるのですが、東京の六本木や渋谷のような若者が好みそうなナウい（死語 失礼）繁華街はありませんでした。たまに、職場の人間とゴルフをしたり食事をしたりする事はあったのですが、とても毎日と言う訳にはいきません。
日本にいる時は、テレビはほとんど見なかったのですが、退屈を持て余してスイッチを入れる事も多くなりました。しかしながら、言葉の問題もありますが、正直言って全然面白くなく、10分もするとテレビの前にいるのが苦痛になって来ます。
その当時、アメリカ人の友人で100チャンネル以上映るテレビを持っている人がおり、筆者も映るチャンネル数を増やす契約をしようかと相談した所、実は、彼自身もほとんど見ておらず、家族、特に子供が見ているだけと言うことが判明しました。彼は、「くだらない１０個のチャンネルが、くだらない100個のチャネルになるだけだ。」と言い捨てていました。
個人差はあると思いますが、２０〜30歳以降の男は段々テレビを見なくなっていく傾向があるように感じます。筆者も、小学生の頃はテレビが大好きで、ニュースと相撲以外の番組をほとんど見ない自分の父親を不思議な気持ちで眺めていましたが、気がつくと自分がそうなってしまいました。
たまに友人と旅行先の旅館などでテレビを見たりしますが、筆者などは10分も経たずに降参してしまいますが、中には1時間以上一心不乱に見入っている人がいたりします。「面白いか？」と聞くと、「いや全然」と答えながら平然と見続けていたりします。こういう人は、きっと長時間の座禅なども平然と組めるタイプでしょう。
インタフェースの拡張例
前回、プロファイルによって、ほとんど全てのUMLモデル要素を拡張出来るお話をしましたが、本日は、例としてインタフェースの拡張を見てみましょう。
図I-01の(A)図は、メタクラス”Interface”を拡張し、"Remote"と言う名前のステレオタイプを定義していることを示しています。
この絵は、いわゆるメタモデル図であり、言語を拡張していることを示しています。
この拡張により、ステレオタイプ＜＜Remote＞＞が、ユーザーモデル層で使用可能になります。
（B)図は、その表記例です。
この図中の「テスト」と名付けられたエレメントは、インターフェースの性質を引き継ぐと共に、「Remote」で定義された性質（メタ属性やアイコンなど）を継承します。
図 I-01
5月の連休中に都内某所のビルにこもって書き物系の仕事をしていたのですが、どうも、それ以降、体調がすぐれず、オフィスの移転等もあって普段よりも忙しかったせいもあり、ブログを書く余力がありませんでした。
月が変わり、6月に入りようやく本来の調子を取り戻しつつあります。
実は、連休中にこもっていたビルは、オフィスの移転先の候補としても考えていたのですが、諸般の事情により取りやめた場所でした。見晴らしも良く、都心であるにも関わらず静かであり、非常に好条件でした。個人的には大変気に入っており、連休中のため、移転先のオフィスのごたごたがなかなか片付かない状態でしたので、無理を言って、一週間ばかり一室を書斎のように使わせてもらっていました。
ゴールデン・ウイークのためビルにまったくと言っていいほど人影はなく、ビルを独り占めしているかのような状態でした。筆者は、書き物系の仕事になると生活が段々夜型にシフトして行く性格（タチ）ですが、この時も徐々に帰宅が深夜帯になってきました。
最後の日、筆者は夜の2時半ごろ仕事を切り上げ部屋を出ました。暗い廊下の向こうにエレベータ・ホールがあり、ランプが下の階からエレベータが昇って来つつあることを示していました。こんな時間に、いったい誰がエレベータに乗っているのか訝しく思われ、入口から少し離れた所で立ち止まって見ていました。日中も含め、ほとんど誰にも会わない状態でしたので、ひょっとしたら”ビル荒し”などが入ってきたのでは、と良からぬ想像が頭に浮かんだり、もし、この階（最上階でした）に見知らぬ人物が昇って来たら、どういう言葉で挨拶しようかなどとつまらないことを考えたりしながらランプの動きを見ていました。こういう時は、ビルの隣が墓地であることも脳裏をかすめたりします。
そうしているうちに、エレベータは最上階まで昇ってきました。暗い廊下に明るい影を映しながらドアが開きましたが、誰も降りて来ません。エレベータは無人で昇ってきたのでした。
きっと、最後に乗った誰かが間違えてこの階のボタンを押したのだろうと自分自身に思い込ませながら、筆者はエレベータに乗り一階まで降りて行きましたが、乗っている間、いい気持ちはしませんでした。
体調がくずれ始めたのは、その日以降です。翌日は結構熱が出ました。きっと気のせい、あるいは偶然だと思いますが、誰かに話すことにより、気も晴れるだろうと思い、このブログに書いてみました。
拡張の表現
前回に述べましたように、プロファイルを用いた拡張は、既存の言語のルールはそのまま温存します。そして、事前に定義されているUML図の構成要素（エレメント）に新規に機能を付け加え、（同じ名前ですと言語を変更してしまうので）別の名前を付けて言語体系に付け加えます。この新たに付けられた名前をステレオタイプ名と呼びます。
図I-02で示される矢印は、拡張を表現します。ターゲット側に拡張される側の既存のエレメントを置き、ソース側に拡張の結果生成される新たなステレオタイプを書きます。
拡張される側のエレメントは、クラス、コメントなどほとんど全てのUMLエレメントが対象となりますが、唯一例外があり、ステレオタイプ自身はプロファイルにより拡張することができません。
図I-02
次回は、この拡張の具体例の表記を見てみましょう。
オフィスの移転も終わり、ようやく落ち着いてきました。
プロファイル
プロファイル概説
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の言語構造を温存し、その上に機能を拡張するものです。
気がつくと、いつの間にか冬が終わり、桜も満開になってきました。東京地方では、先週辺りから「お花見」の風景が良く見受けられます。
筆者は、学生時代に関西から東京に移動して来た組ですが、東京と関西ではお花見の仕方がちょっと異なります。この違いは、吉田兼好の徒然草にもその記述があることから、少なくとも鎌倉ー室町時代から存在していたようです。
今は知りませんが、昔、筆者の子供時代の頃は、関西（神戸）では、花見と言うと、ただ見るだけで、花の下で宴会している風景はほとんど見られませんでした。
筆者の東京風の花見デビューは、新社員の時で、どこかの公園へ宴会の場所取りに行かされたのが最初です。日中早々に場所を確保し、会社の同僚達が来るまでの時間、寝転がって桜の花と青い空、そして白い雲を眺めながらビールを飲んでいると、こう言う花見の姿もいいもんだな、としみじみと感じたことを思い出します。
はた目から見ると、あまりみっとも良い姿とは言えず、兼好法師が批判した気持ちもわかりますが、中に入ると別の感慨が湧いてきます。こう言うのを視点の相違と言うのでしょうか、その立場で、見てみないとわからないものです。
配備のメタモデル
図１０−０４は、配備のメタモデル図です。DeploymentTarget(配備する場所を示す）とDeployedArtifact(配備される内容物）は、配備（Deployment)によって関連付けられています。DeploymentTargetは配備を所有する形の定義です。
DeploymentTargetはプロパティと汎化関係を持ちますが、これによりDeploymentTargetは内部構造を持つことができます。
また、DeploymentTartgetとDeployedArtifactは、共にInstanceSpecificationと汎化関係を持ち、UML図でインスタンスレベルでの表現を可能にします。
図１０−０４
筆者は、普段はできるだけ車や電車を使わず自転車で移動することを心がけています。自転車乗りの人はよくご存知だと思いますが、自転車は、道が平らであると長い距離も苦にならず、どこまでも気楽に行くことができます。
従って、自宅のある新宿から青山とか六本木辺りは、毎日我が庭のように走り回っていましたが、オフィスを移転するまでは、赤坂方面にはほとんど足を踏み入れることはありませんでした。
これはひとえに、赤坂近辺が名前の通り起伏が激しく坂道が多いためでした。赤坂のオフィスのまわりには、かつて幽霊が多く出現したので幽霊坂と名付けられた坂や、のっぺらぼうが出現することで有名な紀伊国坂、忠臣蔵で有名な南部坂など、大小様々な坂がたくさんあります。
しかし不思議なことに、赤坂と言う名前の坂は存在しません。この辺りは、かつて第２次大戦前は赤坂区と呼ばれたほど広範な地域を包含していた地名なので、現在赤坂と呼ばれている地域以外の隣接する区の地名も探してみましたが見つかりませんでした。そして調べて行くうちに、この謎を解くヒントは「元赤坂」という現在も残る地名にあることが解りました。
江戸時代の地図を見ると、赤坂と言う坂はありませんが、［元赤坂町」という町名がそのころから既に存在していたことがわかります。場所も現在の元赤坂とほぼ同じ地域を指し迎賓館から赤坂離宮を中心とした一帯を指す地名です。この辺りは、江戸時代は紀伊和歌山藩の中屋敷があった所ですが、江戸時代以前は茜山（あかねやま）と呼ばれる小さな山だったようです。茜山の語源も諸説あるようですが、一説によると古代の染料の原材料である茜がたくさん生えていたからと言われています。そうして、その茜山に登る坂道が茜坂（あかねざか）と呼ばれていたようです。現在、紀伊国坂と呼ばれる坂も茜山に登る当時の山道の一つです。
そして茜坂が訛って赤坂となったと言う説が、最も有力な説になっています。この説の一つの傍証として、明治の始めの頃、紀伊国坂の麓に茜坂小学校と呼ばれる学校が存在していた事があげられます。（但し、古名が伝わって名付けられたのか、伝説をもとに名付けられたのか、今となっては不明）
恐らく、紀州藩の屋敷を建てる時に地形も多少変わってしまい、赤坂もしくは茜坂と呼ばれる元の地形、原風景は存在しなくなってしまったのだと思いますが、地名だけは伝えられて来たようです。
ノードのメタモデル
図１０−０３の左図は、ノードのメタモデルを表しています。ノードは、クラスを特化しており、クラスの性質を継承します。ノードには、ハードウエア環境を示すデバイス（＜＜Device＞＞）と、ソフトウエア環境を示す実行環境（＜＜Execution Environment＞＞）の二種類があり、ノード同士を入れ子にすることが可能です。
また、ノード間のネットワークを示すコミュニケーションパスは、クラス間の関係である関連の一種として定義されます。
図１０−０３
最近は、様々な用事で忙殺されております。今週は、前回にも書きましたように横浜のチベットにこもっておりますが、今週末から来週にかけてはOMG総会のためサンディエゴへ出張することになりました。
また、昨年秋にオフィスを引越したばかりですが、入居しているビルがなんと耐震強度が弱いことが判明して建替えることになってしまい、来月中にどこか別の場所へ引越さなければならないことになりました。
筆者は生来、引越が好きな方ですが、まだ一年も経っていない上に、新しい物件を見に行く暇もない状態で、正直の所辟易しています。
筆者のささやかな希望としては、青山近辺で、すぐそばに気の利いた静かなカフェがあり、お客様が来られたら、カフェでエスプレッソでも飲みながら談笑する、というのが良いのですが、そんな所は、なかなか見つからないでしょうね。
成果物のメタクラス
図10-02は、成果物（Artifact)のメタモデル図です。
成果物は、ソースコードのファイルとか実行モジュールとか言った、ソフトウエア開発プロセス上で物理的実体を持つものを表しますので、クラスの一種として定義することも可能ですが、UML2.1では、図10-02のように分類子を特化してクラスとは別に独立して定義しています。これは、恐らく、クラスから定義すると、成果物では使わない様々な性質を継承してしまうことを嫌ったからだと思います。
また、このために、逆に、オペレーションとかプロパティ（属性等）と言ったクラスでははじめから用意されているものを、定義付けしてやる必要があります。（関連は、分類子が元から持っている性質ですので定義不要。）
具現は、主にコンポーネントやノードが対象になりますが、メタモデル上では、「packageableElement」を包括的に指定しています。これにより、成果物はモデル図中で用いられる全てのエレメントを定義するモデル図ファイルであることも可能になります。
図10-02
