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パッケージ内の定義が適用されることになります。