ソース・コードの自動生成は失敗の歴史である。しかし「DSL（Domain Specific Language：ドメイン特化言語）」の登場で、再び自動生成に関心が集まっている。開発すべきシステムを機能や目的によって分け、それぞれの設計情報を作成。そこからコードを自動生成する考え方だ。
本記事は日経コンピュータ3月20日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集2」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。なお本号のご購入はバックナンバーをご利用ください。
設計情報から自動的にソース・コードを生成する。それができれば、プログラミング工程が不要になり、設計情報をソース・コードに変換する際に生じるバグもなくなるので、結果としてシステムの品質が上がる――。この考えに基づき、ソース・コードを自動生成するアプローチは以前からいくつもあった。1980年代にわき起こったCASE（コンピュータ支援のソフトウエア開発）ブーム。1990年代後半に話題に上り、2001年2月に米オブジェクト・マネジメント・グループ（OMG）が正式に提案した「MDA（モデル駆動アーキテクチャ）」。CASEは言われているほどのメリットが得られず、大きな成功を収めることはできなかった。MDAは一部で成果を上げているが、模索が続いている。
だが最近になって、再び自動生成アプローチへの関心が高まっている。米国のコンピュータ関連学会、ACMが発行する隔月刊誌ACM Queueの2005年12月/2006年1月号には「Coding for the Code」という記事が掲載された。設計情報からコードを自動生成する意義や、今までのアプローチとの違いなどについて、賛成派と反対派の教授が対話する形で現状を描こうとしたものだ。また米IEEEは月刊誌IEEE Computerの2006年2月号で、モデル駆動開発（Model Driven Development）の特集を組んだ。設計情報からソース・コードを自動生成するための最新のアプローチを紹介している。
関心が高まっている理由は、ビジネスの変化に素早く対応して新しいシステムを開発する方法の一つとして、設計情報レベルで再利用が可能な自動生成の手法がやはり有効だと再認識されたからだ。「ソース・コードやソフトウエア部品の再利用を進めてきたが、開発する対象によってはぎりぎりまで設計変更が求められる。その場合、自動生成の手法が有力な解決策になる」（リコーでソフト開発プロセスの改善に取り組んでいる近藤満顧問技師長）。
最近の自動生成とこれまでの自動生成を比べると、大きな違いはその対象の広さだ。これまでは、アプリケーション全体をターゲットとしていた。対象が広いだけに個々のシステムに関する設計や開発ノウハウ（例えば設定情報を保持する方法など）を利用できない。結果としてかなり手を入れなければ動かない、ごく部分的なソース・コードしか生成できなかった。そのままで動作する詳細なソース・コードを自動生成しようとすると、設計情報の段階でかなり詳細に記述しなければならず、ソース・コードを記述するのとほとんど変わらなかった。
ただ米OMGが提案したMDAは、組み込みソフト開発の一部の領域で成功した。その大きな理由は自動生成の対象領域を組み込みソフト開発に絞り込んだことにあった。
対象を絞り込んで自動生成
 |
| 図1●現在注目されているソフトウエア開発手法。システムを機能やツールなどで小領域に分割し、その範囲で自動生成しようという考え方が出てきた |
この仕組みが成り立つのは、オブジェクト指向開発の浸透により、再利用可能なアプリケーションの枠組みであるフレームワークや、ソフトウエア部品（コンポーネント）が普及したからだ。ソース・コードを自動生成する際に、フレームワークやコンポーネントを有効活用すれば、対象を絞り込みやすい。
対象を絞り込むことで、設計情報から実行可能なレベルのソース・コードを自動生成する。この動きを後押ししているのが、米IBMと米マイクロソフトだ。IBMはオープンソースの開発環境「Eclipse」に、絞り込んだ対象の設計情報を適切に表現する仕組みを2002年から取り入れている。マイクロソフトも同様の機能を、同社のソフト開発環境「Visual Studio」向けに開発中である。
これまでどちらかといえば夢物語に近く、理想的にすぎる感があったコードの自動生成。しかし今回のアプローチはかなり現実的で、大手ツール・ベンダーの支援も受けている。ようやく自動生成が使いものになる可能性が見えてきたといえるだろう。
続きは日経コンピュータ2006年3月20日号をお読み下さい。この号のご購入はバックナンバーをご利用ください。
