長い間、システム関係の仕事をしていると、他の分野の問題もシステム的に解釈してしまうのは、一種の職業病でしょうか？
最近気になった話題の一つが、北陸で起こった冤罪事件です。
無実の人間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日
先日、ちょっとした用事があり、神奈川県の厚木と言う街まで行ってきました。
厚木と言う名前から、大抵の人がすぐに思い浮かべるのは、アメリカ海軍の厚木基地だと思いますが、実は基地は厚木市内ではなく2つ隣の「綾瀬市」にあります。
こう言った事は、非常によくある現象で、千葉県にあるのに東京ディズニーランドと命名したのはその代表的な例でしょう。
ところが、厚木には更に別の謎があり、小田急やJRの「厚木駅」が、実が厚木ではなく隣の「海老名市」にあり、且つ、厚木の中心から相模川を挟んでかなりの距離があり、多くの人は、歩くのを断念して、再度電車に乗り直します。
こう言う駅名のつけ方には、きっと地元の方にとって重要な意味があるのでしょうが、他府県から来た人間にとっては、いったい誰が得をするのかが分からない（愉快犯的な？）命名で、何か不思議な感があります。
また、厚木へ行く途中に「町田」と言う市がありますが、ここも少し謎めいています。
町田市は東京都に属していますが、多くの人は神奈川県の市だと勘違いしています。
電車で行くと、多摩川を渡って神奈川県内をかなり走った後にたどり着く街であるという地理的な理由もありますが、もう一つは、都内に働きに来ている町田市民が、あまり自己主張しなかった所為でもあるでしょう。
町田から通って来ている人に、「町田は神奈川か東京か？」と聞くと、大抵は少し含羞みながら、どちらでも良いんです、と言うような曖昧な回答をして、話題を変えてしまいます。
この奥ゆかしさが、返って皆に誤解を与えているのではないかと、町田の奥にある「座間市」に古くから住んでいるＳ君と言う友人に話すと、「町田市民が奥ゆかしいと言うのは大きな誤解であり、近隣の神奈川県側の市町村を下に見下した傍若無人な人たちである」、と反論して来ました。
S君によると、町田市民は「多摩川の鉄橋」を渡って東京側に入ると、それまでの暴君的性格が、借りてきた猫のように急に大人しく、しおらしい性格に変わるのだそうです。
まるでシュレジンガーの猫のような話で、睡眠不足で眠ってしまい橋を渡ったかどうか分からない人は、暴君なのか猫なのか、どちらなのでしょうか？
そう聞くと、Ｓ君は「町田そのものが量子力学的存在だ」と言い切っていました。
いったい何がS君をそう語らせるのか、そちらも謎です。
ステレオタイプのメタ・レベル表現
前回の図I12では、ステレオタイプのインスタンス・レベルでの表現を見ましたが、さて、このインスタンス・レベルの図そのものは、クラス図でしょうか、あるいはメタクラス図でしょうか？
答えは、メタ・レベルの図、メタクラス図です。あくまでも、メタクラス図を用いてインスタンス・レベルの表現を行っているからです。
モデル・レベルの表現としては、下図I14のような風に書きます。この図では、"StopWach"は、ステレオタイプ"clock"に属する事を意味しています。
図I14
クラスが複数の上位クラスを多重継承出来るのと同様に、ステレオタイプは複数のメタクラスを拡張する事が出来ます。
図I13では、ステレオタイプ"Clock"は、"Component"と"Class"と言う2つのメタクラスを拡張しています。
また、このメタモデル図では、＜＜metaclass＞＞と＜＜stereotype＞＞と言う二つのステレオタイプを使っていますが、これらは、謂わば「メタ・ステレオタイプ」のようなものであり、メタメタ・レベルで拡張が定義されます。
また、"Creator"と謂うステレオタイプに｛Required｝と言う制約が付随しており、このパッケージ内では、"Class"単体では使用出来ず、必ず"Creator"として使用される必要がある事を示しています。
図I13
タイプ（型）レベルとインスタンス・レベル
OCUPファンダメンタルをお持ちの方は、ご存知だと思いますが、UMLでは、型レベルの視点とインスタンス・レベルの視点があります。具体的には、クラス図の通常の（型レベル）のクラス図と、そのオブジェクトに着目した図（インスタンス・レベル）が、その典型例です。
同様にして、メタモデルにも、この2つの視点が取れ、図形表現にもその違いが反映されます。
図I10は、前回（第119回）にも登場した、"Clock"と言うステレオタイプのメタモデル図です。
この図を、インスタンス表現すると、図I12のようになります。
図中のすべてのクラス名には下線が引かれ、メタクラスのインスタンスである事を示しており、属性"name"は、分類子名（クラス名等）を表しています。
このようなメタモデル図の読み書きは、中級レベルを超えた内容であり、通常のモデラーはあまり気にする必要はありませんが、更に上位のモデリング技術を身に付けたい方（プロファイリング等を駆使したモデリングや概念モデリングを行う必要のある方）のために、簡単に解説致します。
図中に、"iscomposite"という属性があります。これは、拡張（Extension)と言う概念が、コンポジットの性質を使って構成される事に起因します。
ステレオタイプが定義されると、そのインスタンス（ここでは"Clock"）は、拡張される側のメタクラス（ここでは"class"）のインスタンスを（内部に）所有します。（コンポジット関連を思い出して下さい。）
これらの性質を2つのメタクラス、PropertyとExtensionEndを用いて表しています。
また、拡張の性質を表すメタクラス、Extensionには、"isRequired"と言う論理値を持つ属性があり、以前紹介した通り、この値がTrueであると、拡張される側の分類子は必ずステレオタイプで示される性質を持つ事になります。 （参考までに言いますと、頭に"is"が付く属性名は、通常論理値を持つ性質に付けられます。これは、文法的に決められている訳ではなく一種の慣習です。（ネーミング・コンベンション））
図I12
タイプ（型）レベルとインスタンス・レベル
OCUPファンダメンタルをお持ちの方は、ご存知だと思いますが、UMLでは、型レベルの視点とインスタンス・レベルの視点があります。具体的には、クラス図の通常の（型レベル）のクラス図と、そのオブジェクトに着目した図（インスタンス・レベル）が、その典型例です。
同様にして、メタモデルにも、この2つの視点が取れ、図形表現にもその違いが反映されます。
図I10は、前回（第119回）にも登場した、"Clock"と言うステレオタイプのメタモデル図です。
この図を、インスタンス表現すると、図I12のようになります。
図中のすべてのクラス名には下線が引かれ、メタクラスのインスタンスである事を示しており、属性"name"は、分類子名（クラス名等）を表しています。
このようなメタモデル図の読み書きは、中級レベルを超えた内容であり、通常のモデラーはあまり気にする必要はありませんが、更に上位のモデリング技術を身に付けたい方（プロファイリング等を駆使したモデリングや概念モデリングを行う必要のある方）のために、簡単に解説致します。
図中に、"iscomposite"という属性があります。これは、拡張（Extension)と言う概念が、コンポジットの性質を使って構成される事に起因します。
ステレオタイプが定義されると、そのインスタンス（ここでは"Clock"）は、拡張される側のメタクラス（ここでは"class"）のインスタンスを（内部に）所有します。（コンポジット関連を思い出して下さい。）
これらの性質を2つのメタクラス、PropertyとExtensionEndを用いて表しています。
また、拡張の性質を表すメタクラス、Extensionには、"isRequired"と言う論理値を持つ属性があり、以前紹介した通り、この値がTrueであると、拡張される側の分類子は必ずステレオタイプで示される性質を持つ事になります。 （参考までに言いますと、頭に"is"が付く属性名は、通常論理値を持つ性質に付けられます。これは、文法的に決められている訳ではなく一種の慣習です。（ネーミング・コンベンション））
図I12
