ソースコード自動生成の黒歴史を塗り替えるブランコ
Excelからプログラムを作る多言語対応オープンソース

NTTデータ ビジネスブレインズ
伊賀敏樹
2007/12/25

開発現場の夢をかなえるブランコ

今回の主な内容 ・ ソースコード自動生成の弱点を克服するために ・ コラム　「貧弱なコンピュータでソースコード自動生成を 　してはいけない!?」 ・ コラム　「設計情報とソースコードとを乖離させない工夫」 ・ 設計書からソースコードを自動生成する4つのメリット ・ コラム　「ソースコード自動生成とDI／AOP」 ・ blanco Frameworkならではの7つの特徴 ・ コラム　「有償サポートもある」 ・ blanco Frameworkでソースコードを自動生成するために 　必要な環境 ・ コラム　「Ruby on Railsとの違い」 ・ blanco Frameworkのツール一覧 ・ ソフトウェア開発改善のためのアプローチの1つとして

　ソフトウェア開発をしていて、「設計書を書き終わったら、そのままソースコードができちゃったらいいな」なんて思ったことはありませんか？ この記事では、まさに「設計書（Excelブック形式）からソースコードを自動生成」してしまう「blanco Framework」（Sourceforgeのページ）というツールの紹介をします。

　blanco Frameworkが提供しているExcel様式に、Microsoft Office（Excel）やOpenOffice.orgを使って所定の必要項目を記入すると、Java、.NET、JavaScript、PHP、Ruby、Pythonのソースコードが自動生成できます（主にサポートしているのは、Java、C#.NETの2言語です）。皆さんのソフトウェア開発に組み込むと、プログラミング作業の一部をとても楽にすることが期待できます。

図1　blanco Frameworkの概念図（設計書を書き終わったらソースコードができちゃう）

　こちらのblanco Frameworkについて、開発者メンバーの1人として紹介させていただきます。とはいえ、「ソースコード自動生成」というジャンルについて、あまりご存じない方も多いでしょうから、まずソースコード自動生成にまつわるさまざまなトピックについて紹介していきます。

　ちなみに、ソースコード自動生成を行うプログラムのことを、「ソースコード・ジェネレータ」と呼ぶ場合があります。

■ ソースコード自動生成と、その黒歴史

　ソースコードを自動生成するという取り組みは、ソフトウェア開発業界の中で長い歴史を持っています。そして、悲しいことにそれら大部分の取り組みはおおむね失敗に終わってしまいました。業務システム開発においては、特にその傾向が強いようです。

　人によっては、ソースコード自動生成は20世紀に取り組まれて、そして「失敗」の烙印（らくいん）が押された「過去の遺物」でしょう。このような背景のため、ソフトウェア開発業界の経験が長く、それら「暗黒の歴史」を知っている人ほど、ソースコード自動生成という取り組みには懐疑的な立場を取ることが多いと思われます。

ソースコード自動生成の弱点を克服するために

　暗黒の歴史を持つソースコード自動生成ですが、最近になって弱点を克服するためのポイントが整理されてきて、また克服できるようになってきています。

■ 昔よりコンピュータが速くなった

　明らかに昔と一番変わっていて、そして効果が高い点がコンピュータの処理能力です。

● 黒歴史：その1「自動生成のコストが掛かり過ぎだ！」

　かつてのソースコード自動生成への取り組みにおいて、ソースコード自動生成のコストと自動生成されたソースコードをコンパイルするためのコストは、とても高いものだったのです。このため、普通にコーディングしたソースコードをコンパイルするだけでも結構な時間が必要であったうえに、ソースコード自動生成や自動生成されたソースコードのコンパイルのための時間がさらに必要になってしまっていたのです。

● 昔の汎用機に比べたら

　現在では、この点が劇的に改善されています。皆さんの目の前にあるパソコンは、一昔まえの汎用機よりも、単純にCPU能力やメモリ搭載量などの処理能力が圧倒的に高いのです（総合的な能力では、依然として劣っている場合があるのですけれどもね……）。

　ソースコード自動生成や、自動生成されたソースコードのコンパイルを、何度でも、そして即座に実行できるようになったのです。

コラム　「貧弱なコンピュータでソースコード自動生成をしてはいけない!?」

このように、ソースコード自動生成はある程度のコンピュータ処理能力を前提としています。あまり非力なマシンでソースコード自動生成に取り組むと、前述のような「黒歴史」と同じ目に遭ってしまう可能性があります。 とはいえ、コンピュータ処理能力にも当然のごとく限界があります。ソフトウェア規模が大きなシステムにおいては、全ソースコード自動生成と全コンパイル・ビルドには相当な時間が必要となります。 このような場合には、ソースコード自動生成とコンパイル・ビルドの単位を分割することにより対処する必要があります。そのような大規模システムの場合には、分割してビルドできるように当初から計画しておきましょう。

■ 2つのデザイン・パターンの発見

　その次に重要なのが、「ジェネレーション・ギャップ」パターンや「フック・オペレーション」パターンというデザイン・パターンの発見です。

● 黒歴史：その2「生成されたソースコードと設計書が違う！」

　20世紀におけるソースコード自動生成の取り組みの致命的な欠点の1つとして、自動生成されたソースコードが設計情報と乖離してしまうという問題が挙げられます。

　多くのソースコード自動生成の実装は、自動生成されたソースコードを直接編集することを前提としていました。しかし、ひとたび自動生成されたソースコードを手動で編集してしまうと、ソースコード自動生成の再実行ができなくなるか、あるいは手動で編集した部分をあきらめて破棄するか、いずれかを選択する必要があったのです。揚げ句の果てに、設計情報の変更に合わせてソースコードを手動で編集する始末でした（設計情報とソースコードの二重メンテナンスは結構嫌なものです）。

　このようなことから、ソースコード自動生成が生産性や保守性を上げるどころか、むしろ生産性と保守性を下げる結果につながる場合が多かったのです。特に、システム全体の中で、保守に掛かるコストの割合が高いシステムにおいては、この点が致命傷となってしまうのです。

● デザイン・パターンとオブジェクト指向の組み合わせによる解決

　現在では、「ジェネレーション・ギャップ」パターンや「フック・オペレーション」パターンの発見により、この点は克服できるようになっています。これらのパターンをオブジェクト指向プログラミング言語と併用することにより、自動生成されたソースコードを直接編集することなく、自動生成されたソースコードに機能追加や機能変更ができるようになったのです（※注釈：工夫すれば非オブジェクト指向言語でも同様のことは実現できるでしょう）。

　これにより、ソースコード自動生成は何度でも繰り返し実行できるようになりました。設計情報の変更のたびに、あるいはソフトウェアのビルドのたびに、ソースコード自動生成を実行することにより、設計情報と自動生成されたソースコードとは乖離しなくなったのです（参考「フレームワークをベースとした自動生成技術の登場」）。

コラム　「設計情報とソースコードとを乖離させない工夫」

設計情報と自動生成されたソースコードを乖離させない方法の1つとして、ビルドプロセスにソースコード自動生成を組み込んでおく方法があります。ソースコード自動生成に取り組む際には、設計情報と自動生成されたソースコードとの乖離はウイークポイントの1つですので、ぜひビルドプロセスにソースコード自動生成を組み込んで、この問題が発生しないようにしましょう。 逆に、ソフトウェアを作っては破棄するスタイルのソフトウェア開発においては、ソースコード自動生成を何度でも繰り返し実行できるメリットはあまり出ません。 すべてのソースコードを完全に自動生成してしまうようなソースコード自動生成アプローチを取ることができれば、「ジェネレーション・ギャップ」パターンのような方法は採用しなくても問題は発生しません。 また、IDE（統合開発環境）の仕組みを利用して、自動生成ソースコードと手動で行ったコーディングとをうまく同居させるアプローチも存在します。

■ ソフトウェア領域を小分けにしたソースコード自動生成

　最近の潮流の1つとして、ソフトウェア領域を小分けにしてソースコード自動生成を行うという手法があります。「ソフトウェア領域」には、例えば、Strutsによる画面設計に関する部分や文字列処理に関する部分、定数、ファイル入出力、DB処理、Webサービス、バッチ処理に関する部分などがあります。

● 黒歴史：その3「すべて自動生成できたらいいのに……」

　すべてのソースコードを自動生成できれば、それは素晴らしいことです。ところが、現実的にはすべてを自動生成しようとすればするほど、ソースコードの複雑度が上がり、その結果自動生成が想定していない機能の実装が難しくなってしまう場合があります。

　また、すべてを自動生成するために、多くの設計情報を事前にセットしてからでないとソースコードの自動生成が実施できないという場合もあるでしょう。

　このように、ソースコード自動生成の取り組みにおいて、すべてを自動生成しようと取り組めば取り組むほど、さまざまな自由度が下がり、どうもうまくいかなくなってしまう場合があるということが知られていました。

● ドメイン特化言語を使ってのソースコード自動生成が増えた

　このような背景もあり、最近、ソフトウェア領域を小分けにしてソースコード自動生成を行うというアプローチが注目されています。

　対象とするソフトウェア領域が小さければ小さいほど、自動生成されたソースコードの複雑度は下がり、事前にセットしなければならない設計情報も少なくなります。自動生成が想定していない機能を実装する場合には、その部分だけ自動生成を実施しないという方法も取りやすくなります。

図2　ソフトウェア領域を小分けにしたソースコード自動生成（小分けにすることにより複雑度が下がる）

　このような対象のソフトウェア領域が小さいソースコード自動生成においては、ドメイン特化言語（DSL＝Domain Specific Language）が利用されることが多くなってきているようです。

　続いて次ページでは、設計書からソースコードを自動生成する4つのメリットや自動生成とDI／AOPの関係、さらに、blanco Frameworkならではの7つの特徴について見ていきましょう。

1-2-3-4

INDEX　特集「Excelからプログラムを作る多言語対応オープンソース」
	Page1
	開発現場の夢をかなえるブランコ ソースコード自動生成の弱点を克服するために コラム　「貧弱なコンピュータでソースコード自動生成をしてはいけない!?」 コラム　「設計情報とソースコードとを乖離させない工夫」
	Page2
	設計書からソースコードを自動生成する4つのメリット コラム　「ソースコード自動生成とDI／AOP」 blanco Frameworkならではの7つの特徴
	Page3
	コラム　「有償サポートもある」 blanco Frameworkでソースコードを自動生成するために必要な環境 コラム　「Ruby on Railsとの違い」
	Page4
	blanco Frameworkのツール一覧 ソフトウェア開発改善のためのアプローチの1つとして

Java Solution全記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）