随分前ですが、本ブログで、組込みのためのソフトウェア工学教科書の翻訳者を募集した事がありました。
その後かなりの紆余曲折がありましたが、いよいよ来月７月に（株）アイ・テックより、「第一巻、基礎編」が出版される事になりました。邦題は、「組込みシステムのためのソフトウェアエンジニアリング（基礎編）」です。
本書は、ジム・クーリング氏の世界的名著「 Software Engineering for Realtime Systems」 のパート１に当たり、非常に基本的な分野がカバーされております。
本書の出版に当たり、２時間ほどの無料セミナーを、（株）日立情報制御ソリューションズ様のご好意により施設をお借りして実施する事になりました。 （ 詳しくは、UTI社のホームページ（ http://www.umlcert.org ）を、ご参照ください。）
また、書店の店頭に並ぶのは、店舗や地域によってかなりばらつくと思われますが（恐らく８月以降？）、上記ホームページでセミナー申し込みと同時に購入予約をし、セミナー会場で受け取る事も可能です。
また、さらに本書をソフトウェア工学のテキストとしてご活用頂く事をご検討頂きたく、本書籍を教科書とした演習中心の標準的な演習セミナーを開催致します。
Aコース： 分析中心 ２日間
Bコース： 設計中心 ２日間
両コースとも、題材を組込み分野から取り、基礎的なオブジェクト指向分析設計をテーマとしますが、オブジェクト指向以外の他の手法も比較検討と補完の為に使用致します。
企業、学校等で、組込み系のソフトウェア工学の適切な教科書を検討されておられる担当者の方がおられましたら、ぜひご参加をご検討ください。（前提資格として、UMLの簡単な読み書きが出来るレベルを想定しております。（OCUPファンダメンタル取得レベル相当））
このセミナーの申し込みも、上記UTIのホームページから行える予定ですので，一度覗いてみてください。
UTIでは、合わせて、
C: OCUPインターミディエート対策講座
D: OCRES インターミディエート対策講座
E: OCRESインターミディエート水準の設計講座
の各コースも予定しております。
先日、H社で社員教育を担当されているW氏とお話をしている際、たまたま話題が、「企業が、大学に対し学生にどう言う教育をして欲しいか」、と言う内容になりました。彼はあまり多くを挙げませんでしたが，筆者の印象に残った点が１つあり、それは学生の作文能力でした。
彼は，毎年今の時期になると、新入社員が送ってくるレポート類に丹念に赤ペンを入れて返しているそうでが、なかなか大変な作業量だそうです。
筆者自身の学生時代や新入社員時代を思い出しても、あまり人の作文能力に関し大きな事は言えませんが、筆者自身の反省も踏まえ、なおかつ、OCRESの勉強にもなるような話題を一つ試みたいと思います。
多くの企業は、ホワイトカラーで入社してくる社員に対し、文章の作成能力を求めますが、これは、決して美文や名文を作成する事を要求しているのではなく、報告書や設計書など、ある程度客観性を持った簡潔で読みやすい文章を要求しています。
ところが、新入社員の方は、往々にして主観と客観がごっちゃになったレポートを作成して来て、読み手を当惑させたりします。これは、語学教育が文学中心な事や、新聞などの影響もあると思いますが、一つ大きな問題として、学生に対し、情報教育がほとんどなされていない事が問題の根底にあると思います。
筆者自身の経験ですが、メタモデリングの話をしていると、往々にして，なぜメタモデルなどを使う必要があるのか？という質問に遭遇します。メタモデルは、基本的に言語の設計図であり、そんなのはモデリングに関係ないじゃないか？という素朴な疑問が生まれるのは当然です。
このモデリング言語とモデルの関係ですが、例えて言うと、数学理論と数学記号の関係に似ています。
ニュートンの公式、F = M Aは、高校時代に習うので多くの方はご存知だと思いますが、このぐらいであれば、数式を使わなくとも自然言語を使ってこの理論を表現する事は可能でしょう。
しかしながら、この公式を使って推論を行ったり、実際の数値計算を行ったりする上で、数式を使わずに自然言語だけで表現するとなると、極めて煩雑になり、間違いの入る余地が大きくなります。また，数学理論が高度になればなるほど、数学の表現法を追加してやる必要が出てきます。さらに、UMLは数式とは異なり、単なる表記法ではなく，モデリング言語であり，言語自身がモデル化されています・・・・。と、ここまでいうと半分くらいの人は分かった気になり、残りの半分は、分かった様な分からない様な気になって，共に沈黙してしまいます。
今回は、いきなりQoSなどという抽象的なメタモデルを持ち出さず、誰もが日々行っているコミュニケーションをメタモデル化して、メタモデルの有用性とコミュニケーション理論の両方を学びましょう。
コミュニケーション理論のメタモデル
下の図は、弊社のPM教育で使っているメッセージの送信者ー受信者モデルを表した図です。
この図は、メッセージの送信者は情報を媒体（音声や文字情報など）に合わせてエンコーディングし、受信者は媒体から情報をデコーディングして情報を取り出す為に、エンコーディング、デコーディングの際に情報の変形が発生し、媒体上にはノイズが入る可能性がと言う事を示していますが、実はこの図そのものがメタモデル的表現なのです。
この図をUMLを使って表現して見ましょう。
下がメタモデル図の一例です。図中は省略してありますが、四角形はすべてメタクラスを表します。
メタクラス図
次が実際のクラス図例です。
と、ここまで書いてスペースが無くなってしまいました。
おおよそ意味は見て取れると思います。
詳しいメタモデルの説明は、次回の「組込みプレス」のOCRES講座に投稿しますので、ご興味のある方はそちらを参照してみてください。
筆者が中学生の頃、父の友人で、地方で温泉旅館を経営する方から招待を受け、家族で温泉旅行に行った事があります。
着いてみると、それは近代風の立派な建物で、ホテルと伝統的な和風旅館の形式を合わせた様なところでした。 その立派な旅館の一番良い部屋に家族で泊めてもらい、翌日は彼自身が運転する車で、周りの観光地へ案内してくれました。
そして、いくつかの名所を回った後、夕方頃になって帰路に着こうとしたとき、彼は、思い出したように、確かこの奥にあったはずだと言いながら、車を脇道へ入れ一本道をしばらく走らせて行きました。
一本道がどのくらいあったかは、全く思い出せませんが、着いた場所は、海の傍の丘の上にある一種の戦争博物館でした。
戦争博物館と言っても、中学生の男の子が喜びそうな戦車や戦闘機が置いてある訳ではなく、穴の空いた錆びた鉄兜や、ぼろぼろになった背嚢やもんぺ等が展示してあるだけでした。
筆者は、内心かなり退屈を感じながらも、一生懸命説明をしてくれる父の友人と一緒に、展示物の間を巡っていました。
筆者は仕方なく聞いているという風で、彼の話の中で憶えている事は、唯一、彼自身、戦争中は予科練に行って飛行機乗りになる訓練を受けていて、その訓練の最中に戦争が終わった、という事ぐらいです。
そして、ガラスケースの中を指差しながら説明する彼の声が、あるときから急に変わってしまった事に気がつきました。
振り返ると、彼は涙をぽろぽろ流しながら、嗚咽を堪えるように説明を続けていました。
筆者は、同情するというよりも、むしろ驚きました。というのも、彼は、中学生にとっては刺激的過ぎる下ねたジョークで、泊まり客たちを笑わせており、筆者は、彼を品のないただの中年オヤジぐらいにしか見ていなかったのです。
ガラスケースの中には、特攻隊員たちが残した手紙やはがきが展示してありました。戦後３０年近くたってもなお涙ぐむほど、彼の心の傷は深かったのかも知れません。
特攻は、今の時代では狂気の沙汰としか思えませんが、彼らは決して狂気に駆られて死地に赴いたのではない事は、残された手紙類が証明しています。
ある少年兵が飛び立つ前に最後に家族に宛てた手紙の末尾が、「母さん、長生きしてください。」とあったのは、その出来事からさらに３０年以上たった今でも憶えています。
一般資源モデリング
OCRESの主要なトピックスとして、各種のUMLプロファイルがあります。これらの目的の話から入って往きましょう。
近年、オブジェクト指向開発がポピュラーになりツールがどんどんと高度化されるに従って、システム開発の時間配分が随分と変わってきました。
かつては、最も長い時間をかけていたコーディングのフェーズが非常に短くなり、場合によっては設計フェーズに付随する付属的な活動と見なせるほど、コーディング単体にかける時間割合そのものが短くなりました。
逆に割合が増えているのが設計フェーズ、特に分析にかけるワークロードが相対的に重要な位置を占めるようになってきました。
一言で組込み系、リアルタイム系と言っても、様々な分野があり、時計から、航空機、ロケット等、個々の分野に特化した分析方法があります。
ところが逆に、これらの多彩な分析方法に、一貫して共通してみられる分析過程が存在します。
図 GRM1-1は、その活動をユースケース表現したものです。
図中のモデラーは、システムの設計を行う人で、モデルを構築し分析し実装する人です。 そして、分析方法の提供者は、モデラーの分析過程をサポートする人で、分析方法を提供し、分析のために必要な資源モデルを提供しますが、UMLのプロファイルは、スケジューラビリティ分析および性能分析のためのフレームワークを提供し、モデラーをサポートします。
OCRESブログでは、本日から数回にわたり、品質モデルについて議論したいと思います。
品質は、単に組込み系、リアルタイム系だけの問題ではなく、IT系とも共通する問題です。
OCRESで取り上げる品質モデルも、単に組込み系を対象にしたものではなく、IT系とも共通するものです。
QoS サービス品質
品質は、戦後日本のお家芸の分野であり、その製品品質は世界をリードしており、わざわざ改めて学ぶ必要はなさそうです。しかしながら、その日本の世界最高峰の品質に関し一点気がかりな所があり、それがサービス品質（QoS）の概念です。
QoSは、システムが複雑巨大になるに従って重大な問題になって行きます。
一例として、行政サービスを考えてみましょう。日本の個人レベルでのサービス精神は、世界に誇れるものがあります。
ところが、窓口の人はそれなりに一生懸命にやってくれていても、結果的に行政サービス全体としては必ずしも満足いくものではないケースがあります。
また、悪名高い年金サービスですが、国民に対するサービス品質は極めて悪いと言わざるをえず、これは、個々人の担当者の資質の問題を遥かに超えて、明らかにシステムレベル（ITシステムだけではなく、組織機構全体としてのシステム）の問題です。
また、行政サービスだけではなく、民間のマネジメントのサービス品質も重要な問題です。資料によっては、日本のホワイトカラーの生産性は、先進国中で最低の水準にあると報告されています。
システムレベルでのQoS、あるいはシステム工学の面白い点は、例えば、最高の構成要素や部品を使って作られたシステムが最悪のサービスしか提供できなかったり、逆に、構成要素、部品はたいした事がないのに、総合的に最高のパフォーマンスを提供するシステムが出来上がったりする所です。
（ちなみに、システム・エンジニアという言葉は、日本では最近はITエンジニアの一職種を示す言葉として用いられていますが、海外では、本来の広範な意味、すなわち広義のシステム工学に従事する者と言う意味で使われることが多く、ロケット工学等も広義のシステム工学の一つです。）
QoS、サービス品質、という言葉は、世間一般で言われる品質と言う意味よりも、より広範な要素を含み、自然発生的に存在するものではなく、人間が積極的に定義し、評価し管理して行かなければならない概念です。
今月になって、アメリカ次期大統領選がヒートアップして来て、アメリカ人たちはかなり盛り上がっております。
傍目には、非常に楽しそうであり、知り合いのアメリカ人に、ストレートに、「楽しそうだな？」と聞いてみた所、ちょっと渋い表情になり、「楽しいんではなく、これ以外にアメリカの将来に期待できる事がないからだ」と呻いていました。
この発言に、果たして、日本人として同情すべきか、あるいは、羨むべきかは意見の分かれる所でしょうが、１つ言える事は、アメリカの組織は、それが政府や会社であろうと、あるいは、もっと小さなセクションであろうと、トップが変わると、がらりと内容も変わる事ができる点です。
管見では、イギリスの組織もそういう傾向があり、それに対し、日本は言うまでもなく、フランス・ドイツの組織もなかなかトップの言う事を聞きません。
ドイツやフランスでは、意思決定は、ある程度、組織的コンセンサスを経て行われる傾向があるのに対し、歴史的に最も早く議会制民主主義が発達した国、イギリスは、かえって、トップの独断的決断を尊重する傾向があるようです。
従って、英米系の組織では、トップの決断にそった移行が素早く行われる事が特長的で、周りも、しばらくの間は、変化を静観する傾向があります。そして、この特長が、素早い変化が要求される分野やタイミングには、英米型組織の強みとなっているようです。
しかしながら、組織が巨大化してくると、英米型組織でも、変化が素早く行えなくなってきており、俊敏さ（アジリティ）をいかに維持し、高めるかは、大きな課題になってきています。
日本においても、アジリティは重要な課題ですが、英米系で議論される方法論に加え、文化的障壁も考える必要があります。
かつて、第二次大戦後の最初の首相、吉田茂氏は、きわめてワンマンであったという悪評がありますが、その基準でいくと、アメリカの大統領を含め、大部分のアメリカ型の組織のトップは、大ワンマンになります。
また、ワンマンという言葉が、悪い意味になるのも、かなり文化的判断が入っています。果たして、吉田茂氏が、あの当時、ワンマン以外の方法で、難局を乗り切れたかどうかは、かなり疑問です。
現在、日本型組織、特に官僚組織は、かなり時代遅れなものになってきてるのは、誰の目にも明らかになってきていますが（ただし、当事者である役人たちの目は除いた方が良いかもしれませんが）、おそらく、方法論だけの議論では不十分でしょう。文化的側面にメスを入れ、この分野での議論を行う必要がありそうです。
アジリティと組込み系開発
組込み系開発は、要求される品質水準も高い上に、頻繁な更改を必要とする局面が多く、メンテナンスの品質と言う問題は、多くの企業にとり、非常に頭の痛い問題です。
組織によっては、大部分のエンジニアが、メンテナンス作業に張り付き、新しい技術の研究開発が全く行えなくなったり、また、ソースコードを担当別に分けた結果、担当者以外には誰も分からないものになってしまっているといった事態は、けっして珍しいことではありません。
また、変更を直接ソースコードに行う事も、それほど珍しくありません。
設計図を用いたメンテナンス
あえてオブジェクト指向とかUMLとか言う言葉出さなくても、歴史的には、こういった問題は設計図を用いたアプローチ、つまりモデルを用いた方法で、かなり状況が改善される事が知られていました。
オブジェクト指向という言葉がない時代から、ソフトウエア・アーキテクチャという言葉は存在し、その頃から、設計者たちは、図形や表を用いてソフトウエアの構造を設計していました。
そして、メンテナンスの際も、設計図にあたりながら、問題が、設計上のバグなのか、コーディング上のバグなのかを峻別し、前者であれば、設計変更を行う形で問題をフィックスして行きました。一見、回りくどいやり方ですが、最終的には、この方法が品質的にもコスト的にも最前である事が、知られてきています。
そして、フィックスしたコードのテストも、設計図を元に行います。今はやりの、モデル・ドリブン・テストの原型が、オブジェクト指向以前からありました。
設計図を利用しないテストでは、テストそのものがブラックボックス型になりやすく、テスト・カバレッジが悪い傾向があります。
また、リリースアップ等の場合も、直接ソースをいじるのではなく、設計図を書いて行う方が、最終的には、素早く安全に行える事が知られていました。
オブジェクト指向／UML化
オブジェクト指向以前のソフトウエア設計図を用いた方法でも、いきなりソースコードのみをメンテナンスするよりは、一定の効果が得られますが、問題も残っています。
一つは、設計者ごとに書き方がバラバラで、他の人が非常に読みにくい事で、これはメンテナンスをチームで行う上での大きな障害となっていました。また、２つ目は、設計方法にばらつきがあり、ソフトウエアの強度の水準の維持が難しい事です。
また、書き方がバラバラなために、設計ツールがなく、必要なら自分で作らなければなりませんでした。
９０年代以降、欧米の開発現場で、オブジェクト指向が急速に受け入れられてきた背景には、この種の問題に解決策を提供する事が明白になってきた事が、挙げられます。
UMLを使う事により、モデリングおよび表記法が統一され、また、自分で開発ツールを作らなくても、市販のツールを利用する事ができます。
そして、オブジェクト指向設計のアプローチにより、モジュラー構造やコンポーネント構造が半ば自然にとられ、ソフトウエア強度が上がり、品質も格段にあがる事が、明白になってきました。
そして、企業の生命線であるアジリティも、品質を確保した上で、向上する事が、広く認められるようになってきました。
明治の前半は、海外の文献を日本語に翻訳することが学者たちの大きな仕事でした。
現代人と明治人の教養の違いに漢籍の知識が挙げられますが、その素養の高さは、彼らが西洋語と格闘し作り出した訳語の幾つかは、漢籍の本場である中国に逆輸出された事で窺い知る事ができます。
「哲学」、「形而上学」、「理性」等が、その代表的な訳語として挙げられますが、変わった所では、「科学的」、「経済的」という言葉に使われる「的」と言う文字で、「ファンタスティック」などの形容詞の語尾、「ティック」を音訳したものだと言われており、現代の中国語でも頻繁に登場します。
そして、数ある翻訳のうち、最も苦労が忍ばれるのが、文学、就中、詩の翻訳でしょう。
直訳しても、何ら感興を催さず、やむを得ず意訳が試みられますが、場合によっては意味が全く変わってしまいます。夏目漱石は、かつて、"I love you"を（やむを得ず？）「月がきれいですね」と意訳したそうですが、明治の女性ならともかく、現代の女性には全く通じそうにありません。単なる天文オタクと思われる危険性があります。
さて、漱石たちを苦しめた英文学の作者に有名な詩人、バイロンがいます。
バイロンは、「バビロン川の畔にて」などに代表されるエキゾチシズムに富んだ作風が日本でも好まれ、明治期では最も有名であった英詩人ですが、破天荒な人生をギリシャ戦争中に終えています。
そして、彼の一人娘、エイダは、少なくともコンピュータ業界では、父親よりも遥かに有名な人物になっています。彼女は世界最初の伝説のプログラマーと言われ、コンピュータ言語、Adaは彼女の名前からとられています。
Ada と組込み系
組込み系システムを代表するコンピュータ言語はと聞かれると、アセンブラを除くと、おそらく世界的にはAdaを挙げる人が多いでしょう。Adaは日本では非常に影が薄いのですが、それでも、世界的に見るとAdaは最右翼に位置するでしょう。
最初期は、アメリカ国防総省案件だけに使われていましたが、現在では、宇宙航空分野だけでなく、安全性、信頼性を重視する分野で幅広く使われるようになりました。
８０年代、筆者はアメリカのコンピュータメーカーの研究所に勤めておりましたが、当時人気のあった内部トレーニング・コースの一つがAdaを用いた設計演習でした。
レーガン大統領が戦略防衛構想を立ち上げ国防総省の入札条件の一つがAdaになると、国防総省にシステムを納入しているベンダーたちは、こぞってAdaのトレーニングを立ち上げました。筆者の勤めていた企業も例外ではなく、Adaは一躍、脚光を浴び、内部で方法論の研究が始まり、トレーニング・プログラムの殆どは重要機密扱いを受け、受講者たちはNDAにサインしてから教室に入りました。
現在、Adaは、世界標準になった最初のオブジェクト指向言語、実装言語として有名ですが、８０年代では、実装言語というよりもむしろ設計言語と言う面が強く、実際、国防総省の入札条件も、「Adaを使ってプログラミングしろ」と言うものではなく、「フォーマル・ベリフィケーションが可能な設計言語を使って設計しろ」と言うものでした。そして、当時、フォーマル・ベリフィケーション、あるいは設計(ハイレベル・デザインを含む）に使える言語と言うと、事実上Adaしかありませんでした。
そして、ソフトウエア技術者たちは、Adaで設計した後、しばしば手作業でアセンブラに落としていました。
これは、当時のコンパイラ技術が未熟であった事とともに、コンピュータそのものが遅く、コンパイルに延々時間がかかり、オブジェクトコードがアセンブラで書いたものに比べて、比較にならないぐらい遅かった所為です。
現在、Adaは宇宙航空分野ではデファクト・スタンダードになっており、最新鋭のジェット戦闘機F-22のソフトウエアもAdaで書かれているほか、他の安全性を重視する分野でも中心的な役割を演じています。
UMLツールを始め、組込み系ツールの多くはAdaをサポートしており、組込みの女王の地位は当分揺らぎそうにありません。
１２月１３日 シスコのカフェにて記す
組込み系ソフトウエアは、欧米の場合、軍需主導で開発されてきたテクノロジーが多く、時を経て民間がそれを採用して行くケースが非常に良く見られます。
NASAに代表されるような宇宙航空技術分野も例外ではなく、元々軍事用に開発された技術、副産物が、後に民間に開放されたものが数多く存在します。
兵站、ロジスティックス
洋の東西を問わず、近代の軍隊組織において、参謀もしくは参謀本部の役割は極めて重要であり、多くの国では、軍人の最高職位は、その参謀本部の長です。また、どこの国の軍隊もそうですが、絶えず目を外に向け、常に他国の研究を行う事が習い性になっているため、たとえ敵軍であってもその長所を取り入れる事に躊躇しない事が多く、また国際間の技術伝播が早い結果、参謀本部の組織・役割は国際的に似たような構造になっており、インテリジェンス（軍事情報）を扱う部署や、計画とトレーニング、兵站、情報通信（IT）等の組織から構成されています。
歴史的には、近代の参謀制度は、18世紀のプロシア軍やフランス軍に始まると言われます。プロイセン軍は、ナポレオンに大敗した後、仏軍の軍制を真似し、また、普仏戦争後、大敗したフランスはプロシアの軍制を相当研究したと言われています。
そのプロシア軍の参謀本部ですが、その原点はさらに17世紀のプロイセン国王であるブランデンブルグ選帝侯に遡り、当時の敵国スエーデンの軍制を真似た陸軍兵站部に始まると言われています。
従って、歴史的に言うと参謀本部は兵站を原点とし、その後、インテリジェンスや戦略、戦術を扱う部隊へと発展して行きました。
近代戦においては、前線での物的人的消耗が激しく、その補給能力は勝敗に大きく影響しますが、必ずしも一般的には、その価値を認められていません。良く言われる言葉ですが、「戦争の素人は戦略を語り、プロはロジスティックスに着目する」と言われています。
情報のロジスティックス
さて、そのロジスティックスですが、昨今の現代戦では、消耗するのは物的人的資源だけではなく、情報も大量に消費されて行く事が特徴的です。
軍事アプリケーションの一つの特徴は、その強い分散処理指向と、回復能力です。TCP/IPと言う通信プロトコルは、米国国防総省のARPANETの標準プロトコルに採用されたのがきっかけで爆発的広がりを見せた事は有名ですが、そのARPANETは核攻撃にも耐えうる通信網と言うのが最終目的であり、初期から自動復旧能力が非常に重要な課題でした。
また、その情報の消費ですが、情報の種類も多岐にわたり、同一作戦を遂行する陸海空軍や同盟国間でコンパチブルである事が要求されます。
OCRESの試験カバレッジにあるDDS(Data Distribution Service)は、その仕様を決めたものです。
DDSは、システム間のデータの大量の移動、信頼性、回復性能、リアルタイム性の確保等を目的とします。
内容的には、抽象工場（Abstract Factory）を中心としたデザインパターンを使用したフレームワークであり、軍事アプリケーションだけではなく、分散処理能力を求められる民需アプロケーションへの普及が行われています。
