ストラタジーナム メニュー

2008年7月27日日曜日

OCRESブログ 第11回 コンピュータ言語

恐らく多くの人がそうだと思いますが、海外に住んでいる時と、国内に住んでいる時とでは、音楽や読書の趣味が多少変化します。
筆者もそんな一人で、例えば、アメリカに住んでいると,かえって日本的な本が読みたくなります。
筆者は、なぜか昔から太宰治氏の書くものが苦手で殆ど読まなかったのですが、カリフォルニアに住んでいた頃のある日、立ち寄ったヤオハン(日系のスーパーマーケット)の書棚で彼の「津軽」を手に取って以降、彼の小説をむさぼるように読み耽るようになりました(少し大げさです)。
しばらくは、太宰治の本が書店から消えてしまったほどです(これは事実です。海外の書店なので、きっと日本の書籍が補充されるのが遅かったからなのでしょう)。
そんなに熱中した太宰治ですが、不思議な事に、日本に帰って来たら、また全く読まなくなってしまいました。

これと似た様な現象が,音楽にも現れました。元々日本にいる時は、さほど演歌を好んで聴くタイプではなかったのですが、アメリカでは、車には必ず演歌のカセットテープを積んで走るようになりました。
特に気に入っていたのが石川さゆりさんの「津軽海峡冬景色」で、この曲を聴きながら、カリフォルニアの青い海や空の下をドライブしていると、ミスマッチな両者の情景が微妙に絡み合い、心地よい爽やかな風となって、心を通り抜けて行きました。

さて、多くの人がカリフォルニアと聞いて連想する曲の一つとして、イーグルスの「ホテル カリフォルニア」が挙げられると思います。
この歌は、もちろん曲の素晴らしさもありますが、ミステリアスで暗示的な歌詞も、多くの聞き手の心に残る要因となっています。
中でも有名なフレーズは、主人公がホテルのキャプテンにワインを持ってくるように頼んだところ,キャプテンは、「1969年以降、そのような酒はこちらにはご用意しておりません、」と断わった場面で、このフレーズは曲の発表以来,様々な形に解釈されて来ています。
有名な所では、酒を意味する「スピリッツ」と精神を意味する「スピリッツ」を引っ掛けて、「1969年以降、そのような精神(スピリッツ)はこちらにはご用意しておりません、」と、ロック業界の頽廃を皮肉っているのだという説がありますが、他にも、1969年は人類が初めて月着陸をした年であり、またベトナム戦争の最中であった事から、60年代のアメリカの繁栄と70年代の興廃期の境を象徴している、という説もあります。



1969年とは?

さて、このブログの読者層は、上記の様なありふれた説に満足されるレベルでは無いでしょう。
1969年には、きっと、もっとミステリアスで深い意味が込められていると洞察される方々が多いと思います。

実は,1969年は、OCRES的には非常に重要な年、ソフトウェア工学とコンピュータ・サイエンスが分離した年、別の言い方をすると,ソフトウェア作りが工学分野として認知された年なのです(なぜ,イーグルスが,この事を知っていたかはミステリーです)。
分離したと言っても、もちろん関係が無くなった訳ではなく、今でも密接な関係にあり、明確な境界線を引く事は出来ません。また、システム工学とも密接な関係があります。

密接に関わり合っている例として、コンピュータ言語を取り上げてみましょう。

コンピュータ言語

コンピュータ・サイエンス系の学生が、筆者の学生の頃(恐らく今でも)やっていた演習の一つに、言語作りーーコンパイラ製作の演習があります。
オートマトンや言語理論を一通り習った後、学生が自分で言語を好きな様に設計して、自分が作った言語の処理系(コンパイラ等)を製作する訳ですが、筆者も学生時代やらされました。

言語の設計そのものは結構楽しく、自由度も高くて好きなように定義できるのですが、あまり複雑な言語体系を作って仕舞うと、その処理系(コンパイラやインタプリタ等)を作るのが大変になるので、当時の学生の常として極めてシンプルな言語体系を設計して楽をしようとする傾向がありましたが、あまりシンプルにしてしまうと何も出来ない言語系になったり、あるいはFORTRANのような機械語のニーモニックの様な言語になってしまって面白みが無くなって仕舞うので、演習担当の助手たちは最低限必要な条件を、演習の最初の頃に提示していました。
当時コンピュータが大嫌いだった筆者も、仕方なく何か適当に言語を定義して(リカーシブ・コール出来る事が必須だった様な気がしますが、かなり記憶が曖昧)、ハノイの塔かアッカーマン関数か何かを計算させていました。
文脈自由言語であれば、当時既にあったyaccなどのツールを使って構文解析部分などサッサと作れるのですが、それも、使用が禁止されていて様な気がします。
また中には、自分の設計した言語で、自分自身のコンパイラを書く、いわゆるコンパイラーコンパイラに挑戦した偉い人もいたと思いますが、うまく行ったかどうかは、全く憶えていません。

しかし、後から翻って考えてみると、この言語の設計製作の演習は、結構有益でした。
もちろん、実社会に出ると、実際に言語処理系を作る事は、そういう部署にでも行かない限りは、まずやりませんが、言語そのものは、直接的もしくは間接的に,様々な形で常に付合って行く事になります(UMLも言語体系の一つです。)

当時、システム記述言語(OSや組込み系を記述する言語)として最もポピュラーだったのがC言語でしたが、当時の学生としては、不満が多く(それは、今の学生がC言語に対して持つ不満と殆ど同じだと思います)、さっさと進化して、D言語やE言語が出来て、21世紀当たりだと当然、Z言語か、ひょっとしたら自然言語でシステム記述が出来るのではないかと想像していましたが、残念ながら、21世紀に入って10年近くたった今でも、相変わらずC言語が主流であるとは、当時は想像もしていませんでした。

さて、言語設計が有意義だというのは、つまり、それが「設計」だったからです。
設計というのは、トレードオフを決定する場です。例えば、言語を出来るだけ精密にしようとして数学式の様な言語にすると、プログラミングの生産性が落ちたり、習得に時間がかかったりして不人気となり誰も使わない言語になったりします。また、生産性を上げようとして簡略な表現法を取ると、可読性が落ちてプログラミング品質が劣化したりします。あるいは、品質を上げようとして、プログラミングの自由度を減らし可読性の高い表現方法を採用すると、今度は生産性が落ちたりして不人気になったりします。
設計は、通常唯一解が存在せず、設計者の個性と市場の間のバランスの上に成り立っています。
こうして、言語の使用者(プログラマ)の観点だけではなく、言語の設計者の観点から言語を眺めるのは、学生にとって非常に良い機会だと思います。

そして、設計法や開発論などに代表される方法論(Methodology)を考えるという事は、徐々にサイエンスから工学(エンジニアリング)の分野に足を突っ込んでいく事を意味します。
方法論というのは、原理法則とは異なり、絶対的なものではなく、例えばオブジェクト指向設計論に則らなくてもシステムは出来ますし、また大抵の場合、適用分野の向き不向きが存在します。
あくまでも、合目的的な思考です。


ところで、組込み系の1つの主要なシステム記述言語がC言語だとしたら、C++言語はどうでしょうか?
答えは"YES、 but.."と少し口ごもった感じになるでしょう。勿論、主流言語の一つである事は間違いありませんが、実は、評判が手放しで良いという訳ではなく、バグを呼び込みやすい言語、使用する上で、注意を要する言語として知られています。

C++言語でプログラミングしたからと言って、オブジェクト指向分析設計をしたとは言えない事は,皆さんご存知だと思いますが、逆も真であり、オブジェクト分析設計をしたからと言って必ずしもオブジェクト指向言語でコーディングする必要はありません。

実装言語を何にするかは、対象エリアの特徴を考え慎重に決定する必要があります。
C++言語が要注意と言われる理由の一つはメモリーの使い方であり、例えば,メモリーサイズの小さなシステムでは、C++の動的なメモリーのアロケーションが問題となったり、また、リアルタイム系では、イベント発生から、メモリーをアロケーションしてオブジェクト生成が終わるまでに要する時間が嫌われたりします。(このような,現象をさけるために、C++系の組込みシステムでは、シングルトン等を使用し、初期化の際にメモリーを割り振ってしまう事が,よく行われます。)

C++言語のもう一つの問題は、コーディングの自由度の高さです。
先ほど、C++で書かれているからと行って必ずしもオブジェクト指向分析設計をしているとは言えないと言いましたが、中にはそれを遥かに超えて、オブジェクト指向プログラミングでさえない場合もあります。
表現するとすれば、「バレンシア風 スパゲッティ・プログラム オブジェクト指向香味添え」という様な、一見高級そうな複雑な味わいのプログラムが結構存在します。
勿論,こう言った事は経験の浅いプログラマが犯しやすく、経験を積むに従って無くなって行く問題ですが、プログラミングの現場は,多くの場合、多数派の経験の浅いプログラマと少数の熟練者という形で構成されやすく、それだけ熟練者の負担が重くなって,全体の生産性や品質を下げやすくなってしまいます。

というわけで、言語の設計と言うのは、言語を考える上で非常に有意義です。
先ほど上げましたyaccやlexと言った構文解析ツールも使えますので、コンピュータ・サイエンス系以外の方でも、サンデー・プログラミングで挑戦可能な域にあると思います。

ただ、風変わりな言語体系を作り、その誰にも理解不能な言語を使って自分だけの世界(システム)を構築するという事は、一歩間違えると漆黒のオタク空間へ吸い込まれてしまい元に戻れなくなってしまう事を意味しますので、耐性が無い方は控えた方が良いでしょう(冗談です)。


2008年7月12日土曜日

OCRESブログ 第10回 ソフトウエア工学

最近は、以前ご紹介したOCRESの試験範囲にも指定されている書籍を発行する事もあり、組込み系・リアルタイム系のソフトウエア工学の話をする事が多くなりました。
そこで、今回のブログでは,それらの対話を通じて非常に良く聞かれる事,2点に付いて書いてみたいと思います。言うなれば、ブログ版FAQ(Frequently Asked Questions)です。

欧米のエンジニアは、ソフトウエア工学をいつどこで、どのように学ぶのか?

最も正確な解答は、「欧米と一言で言っても、国によって様々であり,アメリカと言っても産業や企業ごとに異なる」です・・・と言っても、恐らく大部分の人にとっては、正確過ぎて反って、期待した答になっていないと思いますので、私見も交え、大雑把な図を描いてみたいと思います。

まず第一に、IT系と組込み・リアルタイム系では、様子が少し異なります。
IT系エンジニアは、学校でコンピュータ・サイエンス系のトレーニングを一通り受けてきた人が多いのに対し、組込み・リアルタイム系エンジニアは、むしろ、電子工学や機械工学、化学と言ったコンピュータ・サイエンス以外の分野の専門教育を受けて来た人たちが多数を占めます。
従って、学校でのコンピュータ教育は、言語教育までと言った人が主流となり、ソフトウェア工学のトレーニングは、主に企業内教育の場で行われる事になります。

また、ITと異なり、ハードウェアとソフトウエアの独立性が低く、ハードウェアの設計者であってもソフトウェア側の事情を知らないとシステム設計が出来ない場合が多く(ハードのソフト化)、システム工学と合わせてソフトウェア工学のトレーニングを行います。(現実的には、分野によっては、システム設計の主導権をソフトウェア側が握っており、そういった場合は,ソフトウェア工学を通じてシステム工学を学ぶ事になります。)

そして、企業教育の特徴は、グループによる事例研究や演習を短期間(通例2〜4日間)に集中して行う点であり、学校教育のように、週2時間で半年間という様なパターンは皆無に近いと思います。( ただし、E-ラーニング等で、知識教育を補助的に組み合わせるケースは非常に多い。)





システム品質について

システム品質の話をする場合、時々、NASAの惑星探査ロケットが、かつて、メートル法とフィート法を間違えて距離を測定し、惑星に接近するつもりが,激突してしまった事例を取り上げる事があるのですが、人によって受け取り方が違い、筆者の意図する向きとは正反対の方向に解釈される場合もあるので(恐らく,筆者の言葉足らずのせいでしょう)、ここで、改めてお断りしておきたいと思います。

この話をする時の反応は大きく2つに分かれ、一つは、「メートルとフィートの換算方法は小学生でも知っており、なんで何人もの博士号を持つ技術者たちがチェックしたと言うのに、事前に分からなかったのか? 注意不足にもほどがある。」というものです。

この問題は、例えて言うと、ビット列「 0100 」を一方のソフトは4メートルと解釈し、もう一方は4フィートと解釈する様な現象で、解釈が異なる、つまり意味を取り違えてしまうバグで、意味論的エラー(セマンティック・エラー)と呼ばれる問題です。
実は,このようなバグはソースコード・レビューのようなテスト以外の手法で取り去るのは非常に困難である事が知られています。
また、遠い宇宙空間で走る予定のソフトを地上でテストするのも大きな課題です。(たとえ地上でテストしても、宇宙空間で同じように走る保証がない等)
関係者に取っては、「まさか」に属する種類の間違いですが、残念ながら、このような間違いは人間の注意力では解決されず、よりシステマティックなアプローチが必要である事が専門家の間では常識になっています。
システム工学の進歩も,このような品質問題を解決するために進歩してきました。
最近の飛行機は、昔に比べて数段安全になってきましたが、これは決して、昔に比べて、関係者の注意力が増して来たからではなく、墜落する原因のいくつかが解って来て、それに対してシステム的な対処がなされた事に大きく起因します。
従って、こういった問題で重要な事は、エラーを起こした人間の責任を追及する事ではなく、なぜ、エラーが発生するのか,なぜ防げないのかと言った点を調査する事にあり、それに対しシステマティックな解決策を取る事にあります。(当事者は、説明する責任は当然ながらあります。)
昨今のUMLをはじめとするソフトェア設計手法やテスト手法の発達もシステマティックな解決策の一つです。

最近、重篤な状況下の患者に対し非常に難しい処方を施した医師が、結果的に患者が死亡した責任を問われて逮捕されるニュースが流れましたが、システム屋の目には非常に奇異な事件に感じます。
もちろん、刑罰もシステマティックな手法の一つですが、故意の犯罪に対しては、ある程度限定的に有効だと知られている手法ですが、過失に対する抑止効果は極めて疑問です。(そもそも、リスキーな処方をとる事自身が過失だとする意見に対し、疑問がありますが。)

むしろ、システム的、組織的な問題に対し、何らシステム的、組織的解決をはかろうとしない事自身を問題視すべきでしょう。