自動生成によってシステム開発の生産性を上げるスレ

自動生成ツールを開発することにより、システム開発の生産性・品質を向上し、
より低価格で、品質の高いシステムの開発を目指しています。

自動生成ツールを開発する上で、
・システム開発の、どこの部分を自動生成するべきか(＝どこの部分の自動生成にニーズがあるのか)
・どのような手段・方法で自動生成するべきか
について、意見・情報提供をお願いします。


このスレで出てきたアイデアを元に、
私が自動生成ツールを作り、公開していきたいと考えています。

私の意見に賛同してくださる方、是非協力よろしくお願いします。

どういう自動生成ツールをつくりたいんだ？
既存の自動生成ツールとの違いの説明を踏まえて、目標を定義しろ

自動ツールはみんな考えるけど、うまくいかない

以下は、私が作りたいと考えているツールの構想です。

現在のシステム開発の工程では、
１つのプログラムの情報を表すのに、ソースコード以外にも、
クラス図やら画面設計書やらDB定義書やら
大量のドキュメントを作成しています。
こうした、１つ１つのドキュメントを書く時間には、
以外と馬鹿にできない工数がかかっているのが現状です。

こうした現状の問題を解決するために、私は、
１つのプログラムを表す設計情報をツールに入力することによって、
ツールから、クラス図や画面設計書などのドキュメント生成も行い、
またソースコード生成も行う、といったツールを作りたいと考えています。

ドキュメントの内容と、ソースコードの内容とは、論理的には同一の情報であり、
それをわざわざ分けて入力・記述するのではなく、
プログラムを表す設計情報を１回だけツールに入力することで、
ドキュメントも、ソースコードも両方出力できるものを目指しています。

例えば、画面とDBとのマッピング情報をツールに入力しておくことで、
画面設計書、DB定義書、ER図といった各種ドキュメントを自動生成し、
DB入出力処理が反映されたソースコードを自動生成する、といった具合です。

また、論理的な情報を一元管理しておくことによって、
仕様変更が生じた際に、設計書とソースコードとの同期も取りやすくなります。

課題・問題点としては、(現状私が考えている段階)
(1) 論理的なプログラムの情報を、どのようにツールに入力させる？
　　GUIで、直感的に情報を処理し、手軽に扱うことの出来るインターフェイスが必要。
　　ツールの操作性が悪いと逆に生産性が落ちる。

(2) 会社毎にドキュメントのフォーマットが異なっている点をどう吸収するか
　　委託開発でツールを使用する場合、相手先の会社のドキュメントのフォーマットに合わせなければならないケースがある。
　　生成を行う各種ドキュメントのテンプレートファイルや、変換定義をXSLTなどで外出しにしておくことで、対処可能か。

(3) どこまで自動生成に対応させるか？
　　ドキュメントとソースコードの自動生成対応率は、どれくらいを目指すべきか？
　　私は、100%の自動生成は目指す必要はないと考えています。
　　100%にこだわらなくても、ツールを使用することで生産性は大きく向上すると考えます。

と、一通り書いてみましたが、
実際に現場で開発を行っている技術者の方が、
どういった点に不便を感じていて、どうしていきたいと考えているのか、
といった点について、知りたいと考えています。

現在のシステム開発では、いくつかのCASEツールを使ってシステム開発を行っている会社が多いと思いますし、
社内ツールを開発している会社も多いと思います。
そういった各種ツールを使っていて感じた不便な点や、
こういう機能があれば良いのに、といったことを教えてください。

そうした不便な点を解消するべくツールを開発し、
システム開発の生産性・品質を向上させていく、というのが目標です。

よろしくお願いします。

ヒント：MDA

>> 7
UML2.0 と MDA の組み合わせですね。
最近話題になっていますよね。

UML設計情報からソースコードの自動生成。

でも、他のドキュメントの自動生成はできないんですよね。

ソースコードを自動生成するよりドキュメントの自動生成の方が欲しい、という
技術者の方も少なくないので・・・

UMLのような形で設計情報を入力して、
それをもとに、ソースコードやドキュメントを自動生成できたら
より便利かもしれませんし、
私の目指す方向性に近いのかもしれません。

>>1は今までどんな自動生成ツールを使って来たがあるんだ？
その使ってきたツールについてどんな不満があったんだ？
今あるツールに不満があるから自分で作りたいということなんだろうから、
それが説明できるならそれを説明したほうが何か説得力があるはず。
使ってきたツール以外に、使ったことはないが、>>1が知っている、聞いたことがある
自動生成ツールというものはどんなものなのか説明してみないか？
それから>>1が目指しているプラットフォーム、使用する開発環境、開発言語についても聞きたい。
主に使っているものでもなんでもいいから詳細よろしく求む。

漏れは
プロジェクト管理ツールApache Maven,
Javadocコメント、アノテーションから他のソースコードを自動生成するXDoclet,
プラグインが豊富なオープンソースIDE Eclipse,
GNU make同様の自動化を可能にする ビルドツールApache Ant,
テストの自動化には重要な役割を果たすテスティングフレームワーク JUnit
を使ってきた。

そして、そんなに使いこなしているわけではないが、
ほかに、DBスキーマからJavaソースコードを自動生成するO-RマッピングツールCayenne,
テンプレートエンジンを使ってソースコードや設定ファイルなどを自動生成する Jakarta Velocity

Ant, JUnit, プラグインが豊富なEclipseはよく使っている。
Eclipseによる自動化はここで話題にしていいのか迷うところだが、今は挙げないでおこう。

他に知ってはいるがあまりつかったことがないものとしてエディタEmacs,
Cayenneよりも機能が豊富なO-RマッピングツールHibernateなどだ。

自動生成とは関係なさそうなモノもあるが、テストの自動化は重要であり、
IDEによる開発効率上昇はバカにならないので挙げてみた。

>>5
> 課題・問題点としては、(現状私が考えている段階)
> (1) 論理的なプログラムの情報を、どのようにツールに入力させる？
> 　　GUIで、直感的に情報を処理し、手軽に扱うことの出来るインターフェイスが必要。
EclipseのようなIDEの役割かな。
ここでは、オープンソースの中でも最も優れたIDEだと思ったのでEclipseを挙げてみた。

> 　　ツールの操作性が悪いと逆に生産性が落ちる。
Apache MavenやApache Ant, XDocletは基本はコマンドラインで実行するモノだがね。
操作性が悪いかどうかはうーむ、というところ。ちなみに、XdocletはAntを使って動かす。
また、AntはEclipseを使えば操作とビルドファイルbuild.xmlの編集がさらに容易になる。

> (2) 会社毎にドキュメントのフォーマットが異なっている点をどう吸収するか
> 　　委託開発でツールを使用する場合、相手先の会社のドキュメントのフォーマットに合わせなければならないケースがある。
> 　　生成を行う各種ドキュメントのテンプレートファイルや、変換定義をXSLTなどで外出しにしておくことで、対処可能か。
そのとおりXMLを使うのが望ましいが、フォーマットが異なる問題は、
基本となるスキーマだけを少なくとも定義しておいて、
企業毎に足りないと思った機能があるなら、企業がスキーマにタグをツリーからぶら下げるように追加していけばいいかと思う。
また、そのとき、どこの要素にどんな独自要素を追加したのかを示すフラグや情報をXMLに書いておけば変換も少しは容易になるだろう。

> (3) どこまで自動生成に対応させるか？
> 　　ドキュメントとソースコードの自動生成対応率は、どれくらいを目指すべきか？
> 　　私は、100%の自動生成は目指す必要はないと考えています。
> 　　100%にこだわらなくても、ツールを使用することで生産性は大きく向上すると考えます。
>
100%はいきすぎ。将来像としては徐々に100%に収束してゆくという形で。
ここではソースコードそのものも自動生成するという話も含まれているんだな？

UMLも気になるところだな。
ツールが高すぎて個人では手に負えないのであまり使っていない。EclipseのプラグインでFree版Omondo, UML2などをちょっと
見たことがあるが。Omondoでよくクラス図を書いてはいるがOmondoはとりあえずクラス図を書くと
Javaソースコードも勝手に自動生成する程度の機能はある。ほかはよく知らない。

>>8
UMLの場合,

ＵＭＬからドキュメントを生成するのではなく、
ソースコードからUMLを生成したほうが楽な。

UML事態がドキュメントの役割を果たしているので。


UMLからドキュメントを生成するという発想は思いつかなかった。
それはそれで面白そうだ。

>ドキュメントの内容と、ソースコードの内容とは、論理的には同一の情報
それが違うんだよね。同一であってほしいだけ。

会社に入って分かったのは、自動生成で作成されたソースコードは
試験工程ですごーく苦労するということ：
　・試験結果をみてもバグが有ることがわからない（作っていないから）
　・結合試験（システム単体での試験）でバグが分かっても、
　　どこを直したらよいか分からない
　・自分（あるいはＰＪ）の命名規則に沿っていない関数・変数は
　　非常に読みづらい

ということで基本的にＣＡＳＥツールを使ってソースコードを自動生成
させるのには反対なのですが、皆様はどうでしょうか。

ＣＡＳＥツールのその問題点を解決したのが、クラスライブラリの派生による開発。
書く量を差分で減らしてる。

が、BCBとかEclipse/Javaとかみてると、結構裏でコッソリソースに色々追加してる。
Eclipseだとコンパイルエラーの修正パターンを選択みたいに、生成パターンを幾つか選択できたり。

つまり、１度に吐き出す自動生成の時代は終わったが、Eclipse型IDEが実行時に吐き出すジェネレータは主流へと。

ただし、これを作るとはコンパイラメーカとの戦いか、Eclipseへプラグインとして取り込まれちゃうか、の諸刃の刃。

例えば、単体試験項目抽出および手順書作成ツールとか、比較的
に下流工程生産物の自動生成は有用かもしれないなあ。つーか欲しいです。

>>14
つーことは、逆を言えば

(1) 自動生成の作業工程を分かり易く示したマニュアル、ＦＡＱがある
(2) 自動生成したソースに発生したバグに対する修正パターンを自動表示
(3) プロジェクト毎の命名規則に従って、関数・変数の命名を行う

であればOKってことね？
(まあ、他にも問題点探せばあるとは思うが・・・むしろ問題点を言って欲しい)

(1) はともかく、
(2) は、EclipseやVisual Studio .NET 2005 である程度対応できている。
(3) は、プロジェクト毎の命名規則を外部に外だしして、
　　命名規則に沿って変数名、関数名を自動生成するようにすればOK。
　　プロジェクト毎に変換定義のテンプレートを作っておけば対応できる。

ＣＡＳＥツール賛成派、反対派はもちろんいると思うが、
生産性向上したい＝楽がしたい
という意味においては、みんな同じ考えだよね？

既存のＣＡＳＥツールは、
ドキュメントの自動生成にしろ、
ソースコードの自動生成にしろ、
ＣＡＳＥツールのメーカーのフォーマットに完全に従っていて、
使用者のフォーマットは完全無視状態。
ＣＡＳＥツールのメーカーは、
「ウチのフォーマットに合わせろよ」的な、
ある種の「押し付け」なんだよね。

作業工程の押し付けならまだ良いとしても、
ドキュメントは顧客に提出するものでもあるんだから、
それを固定フォーマットで生成されるとすごく困るわけよ。

だから、そこが問題で、
既存のＣＡＳＥツールは使えない状態。

その改善方法として、
プロジェクト毎に変換定義を作って、
その変換定義に従ってドキュメント生成やソースコード生成をすることで、
プロジェクトに合わせて、欲しいフォーマットに従った
ドキュメントやソースコードが生成される。

それって、すごく良いと思わない？

実際、XSLTなどで変換定義を作れば簡単に実現できるし、
実装も大して難しくない。
（XSLTで変換のマッピングを定義してやれば良いだけ)

そういうツールを作ろうと思っている。

すごく良いと思わない。

なぜなら、例えばDelphiでプロジェクト作成メニュー実行するとフォームが１枚開いて、
ＤＢコンポーネント複数貼ってプロパティ設定して、
実行ボタンを押したらＤＢ編集ツールが出来ちゃう。

>20
19の書いてるのは
XSLT定義を切り替えることで
プロジェクト毎に異なるフォーマットのドキュメントやソースコードを
生成できるってことだと思うぞ。

・プロジェクト毎の命名規則が反映されたソースコードの自動生成
・プロジェクト毎にフォーマットの異なるドキュメントの自動生成

受託開発だと、
IBM、NECと、会社毎に納品ドキュメント違うじゃん。
ドキュメントのフォーマットを、
XSLT変換定義でマッピング付けして生成することで、
異なるフォーマットのドキュメント作れるだろ？

ＤＢ編集ツールがどうとか、意味合いが異なると思うが
その辺どうなのよ？

.NET環境で、「NUnit」っていうツールがあるのね。
ttp://www.atmarkit.co.jp/fdotnet/tools/nunit2/nunit2_01.html

そのツールでは、テスト用のコードを作成して、
テストの自動化を行っているんだけど、
そのテスト用のコードの自動生成も
余裕でできると思うのよ。

画面とDBのデータマッピング情報からテストケースを生成し、
テストコードを自動生成することによって、
テストがかなり便利になると思うんだが。

22の続き

ツールに画面とDBのデータマッピング情報を入力し、
その情報をもとにして
「NUnit」用のテストコードを自動生成したらかなり便利になると思う。

どこかの会社が作ったデータマッピングツールで、
ツールに入力したレポジトリ情報を取得できれば、
その情報をもとにして
テストコードの自動生成は可能だと思う。

それができなければ
データマッピングツールを自作で作る必要があるな。

>>14
> 会社に入って分かったのは、自動生成で作成されたソースコードは
> 試験工程ですごーく苦労するということ：
> 　・試験結果をみてもバグが有ることがわからない（作っていないから）
> 　・結合試験（システム単体での試験）でバグが分かっても、
> 　　どこを直したらよいか分からない

それは自動生成ツールの信頼性が低く実績が少ないからではないかな。
有名何処の自動生成ツールなら実績があるので無駄にテストする必要がない。
それをわかってない奴がいると、無駄にテストしようとする、あるいはツールを使うのを拒もうとする。

Hibernateは信頼と実績があるので自動生成されたコードでとんでもない挙動を示すことは少ない。
それをわからない奴が見ると、自動化するとその分だけ余分にテストしないといけないから
使いたくないなどと言い出す。こういう人間を説得するのは大変だ。
すべてのオープンソース製品はフリーでサポートが無いから信用できないなんて言い出しかねない。
ApacheやTomcatを使っておきながらオープンソースは信用できないとか頓珍漢なことを言い出す輩もいる。


> 　・自分（あるいはＰＪ）の命名規則に沿っていない関数・変数は
> 　　非常に読みづらい
>
> ということで基本的にＣＡＳＥツールを使ってソースコードを自動生成
CASEツールじゃなくてUMLにすればいいのに。

>>22
それだったらEclipseでも似たようなことができる。

というかJUnitのC#版なんだけどね。

EclipseにもJUnitプラグインが同梱されており
いきなりJUnitによるテストで、テストファースト、テスト駆動開発を実践できる。
さらに、既存のJavaクラスから、テストクラスを自動生成する機能もある。
Javaのクラスにあるどのメソッドをテストするかも聞いてくる。
チェックボックスでテストしたいメソッドを指定すると
テストケースクラスとメソッドのスケルトンができる。
それについて、

自動生成を余裕でやるには構文解析とか大変なことをしないと行けないと思うが。
nullチェックなどワンパターン化されたものについてなど、ある程度までは自動ではできるとは思うが。


JUnitについては、Java5のアノテーションに対応した次世代版TestNGというものが開発されており、
NUnitと同等かそれ以上の機能を持つことに期待できそうだ。

Javaの自動生成ツールといえあ、
CommonclipseというEclipseプラグイン。

Javaのクラスにequals(), hashCode(),compareTo(), toString()メソッドを
Jakarta Commons langのライブラリを利用してオーバーライドし
フィールド値とその型などに合わせてそれらのメソッドを自動生成してくれるツール。
今のところ、Eclipse3.1には対応せず、Eclipse3.0までに対応。


http://www.eclipsewiki.net/eclipse/?Commonclipse
http://commonclipse.sourceforge.net/

結構高めの商用も視野に入れれば結構ありそうだけどな。

ここで話題にしているのって、
↓みたいな奴のこと？
http://www.genexus.jp/portal/hgxpp006.aspx
http://www.canon-soft.co.jp/product/web_performer/

こういうのって、本当に実業務でつかえるもんなの？

入力方法の前に、どういう形式で情報を持つかの方が大事じゃない？

XML で状態アクションマトリクスを記述するとか。
UIはそれにあわせたものを作ればいい。

UMLも、UIの一形態に過ぎないとおもう。

age

自動生成できたらプログラマの職がなくなるじゃん

>>32
全然できてないから、わしらに仕事があるんじゃないか

ポータルサイトのフレームワークの「BroadVision」
最低最悪、マニュアルは日本語化してないわ、開発支援ツールは作りかけだわ、
ビジュアル環境で開発できると思わせといて、コマンドライン入力が多いわ、動作重いわ

氏ね、どうせ上層部が口のうまい営業にだまされてホイホイ買ったんだろ
何千万の浪費だよ

>>34
営業妨害です。通報しました。

>>1 perl覚えろよ

この手のツール色々試してみたけど、自由度と楽さがトレードオフ。パターンにハマルと効果上がるけど、それ以外は普通に作るより大変。
現在、唯一両立してるのってRubyOnRailsくらいだろ。
欲しいのがあるとすればJava版Rails、struts+s2+s2daoの組み合わせならぜひ使いたい。

フレームワークと自動生成が組み合わされば便利。

Visual Studio 2005が最近リリースされたけれど、
C#2.0 + Oracle 用のソースを生成する自動生成ツールは
需要ないかなぁ？

需要あるようだったら作ろうと思うんだけど。

>>39
何を生成するんだ？

人の作ったコードは変数名ひとつまで自分式に書き直さないと使いたくないんだ

TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？