自動生成によってシステム開発の生産性を上げるスレ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/09/05(月) 22:00:32より低価格で、品質の高いシステムの開発を目指しています。
自動生成ツールを開発する上で、
・システム開発の、どこの部分を自動生成するべきか(＝どこの部分の自動生成にニーズがあるのか)
・どのような手段・方法で自動生成するべきか
について、意見・情報提供をお願いします。
このスレで出てきたアイデアを元に、
私が自動生成ツールを作り、公開していきたいと考えています。
私の意見に賛同してくださる方、是非協力よろしくお願いします。
0002デフォルトの名無しさん
2005/09/05(月) 22:06:48既存の自動生成ツールとの違いの説明を踏まえて、目標を定義しろ
0003デフォルトの名無しさん
2005/09/05(月) 22:11:0500041
2005/09/05(月) 23:25:10現在のシステム開発の工程では、
１つのプログラムの情報を表すのに、ソースコード以外にも、
クラス図やら画面設計書やらDB定義書やら
大量のドキュメントを作成しています。
こうした、１つ１つのドキュメントを書く時間には、
以外と馬鹿にできない工数がかかっているのが現状です。
こうした現状の問題を解決するために、私は、
１つのプログラムを表す設計情報をツールに入力することによって、
ツールから、クラス図や画面設計書などのドキュメント生成も行い、
またソースコード生成も行う、といったツールを作りたいと考えています。
ドキュメントの内容と、ソースコードの内容とは、論理的には同一の情報であり、
それをわざわざ分けて入力・記述するのではなく、
プログラムを表す設計情報を１回だけツールに入力することで、
ドキュメントも、ソースコードも両方出力できるものを目指しています。
例えば、画面とDBとのマッピング情報をツールに入力しておくことで、
画面設計書、DB定義書、ER図といった各種ドキュメントを自動生成し、
DB入出力処理が反映されたソースコードを自動生成する、といった具合です。
また、論理的な情報を一元管理しておくことによって、
仕様変更が生じた際に、設計書とソースコードとの同期も取りやすくなります。
00051
2005/09/05(月) 23:26:03(1) 論理的なプログラムの情報を、どのようにツールに入力させる？
GUIで、直感的に情報を処理し、手軽に扱うことの出来るインターフェイスが必要。
ツールの操作性が悪いと逆に生産性が落ちる。
(2) 会社毎にドキュメントのフォーマットが異なっている点をどう吸収するか
委託開発でツールを使用する場合、相手先の会社のドキュメントのフォーマットに合わせなければならないケースがある。
生成を行う各種ドキュメントのテンプレートファイルや、変換定義をXSLTなどで外出しにしておくことで、対処可能か。
(3) どこまで自動生成に対応させるか？
ドキュメントとソースコードの自動生成対応率は、どれくらいを目指すべきか？
私は、100%の自動生成は目指す必要はないと考えています。
100%にこだわらなくても、ツールを使用することで生産性は大きく向上すると考えます。
00061
2005/09/05(月) 23:26:46実際に現場で開発を行っている技術者の方が、
どういった点に不便を感じていて、どうしていきたいと考えているのか、
といった点について、知りたいと考えています。
現在のシステム開発では、いくつかのCASEツールを使ってシステム開発を行っている会社が多いと思いますし、
社内ツールを開発している会社も多いと思います。
そういった各種ツールを使っていて感じた不便な点や、
こういう機能があれば良いのに、といったことを教えてください。
そうした不便な点を解消するべくツールを開発し、
システム開発の生産性・品質を向上させていく、というのが目標です。
よろしくお願いします。
0007デフォルトの名無しさん
2005/09/05(月) 23:38:5700081◇AutoGen
2005/09/05(月) 23:52:50UML2.0 と MDA の組み合わせですね。
最近話題になっていますよね。
UML設計情報からソースコードの自動生成。
でも、他のドキュメントの自動生成はできないんですよね。
ソースコードを自動生成するよりドキュメントの自動生成の方が欲しい、という
技術者の方も少なくないので・・・
UMLのような形で設計情報を入力して、
それをもとに、ソースコードやドキュメントを自動生成できたら
より便利かもしれませんし、
私の目指す方向性に近いのかもしれません。
0009デフォルトの名無しさん
2005/09/05(月) 23:55:00その使ってきたツールについてどんな不満があったんだ？
今あるツールに不満があるから自分で作りたいということなんだろうから、
それが説明できるならそれを説明したほうが何か説得力があるはず。
使ってきたツール以外に、使ったことはないが、>>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による開発効率上昇はバカにならないので挙げてみた。
0010デフォルトの名無しさん
2005/09/06(火) 00:05:17> 課題・問題点としては、(現状私が考えている段階)
> (1) 論理的なプログラムの情報を、どのようにツールに入力させる？
> GUIで、直感的に情報を処理し、手軽に扱うことの出来るインターフェイスが必要。
EclipseのようなIDEの役割かな。
ここでは、オープンソースの中でも最も優れたIDEだと思ったのでEclipseを挙げてみた。
> ツールの操作性が悪いと逆に生産性が落ちる。
Apache MavenやApache Ant, XDocletは基本はコマンドラインで実行するモノだがね。
操作性が悪いかどうかはうーむ、というところ。ちなみに、XdocletはAntを使って動かす。
また、AntはEclipseを使えば操作とビルドファイルbuild.xmlの編集がさらに容易になる。
> (2) 会社毎にドキュメントのフォーマットが異なっている点をどう吸収するか
> 委託開発でツールを使用する場合、相手先の会社のドキュメントのフォーマットに合わせなければならないケースがある。
> 生成を行う各種ドキュメントのテンプレートファイルや、変換定義をXSLTなどで外出しにしておくことで、対処可能か。
そのとおりXMLを使うのが望ましいが、フォーマットが異なる問題は、
基本となるスキーマだけを少なくとも定義しておいて、
企業毎に足りないと思った機能があるなら、企業がスキーマにタグをツリーからぶら下げるように追加していけばいいかと思う。
また、そのとき、どこの要素にどんな独自要素を追加したのかを示すフラグや情報をXMLに書いておけば変換も少しは容易になるだろう。
0011デフォルトの名無しさん
2005/09/06(火) 00:05:29> (3) どこまで自動生成に対応させるか？
> ドキュメントとソースコードの自動生成対応率は、どれくらいを目指すべきか？
> 私は、100%の自動生成は目指す必要はないと考えています。
> 100%にこだわらなくても、ツールを使用することで生産性は大きく向上すると考えます。
>
100%はいきすぎ。将来像としては徐々に100%に収束してゆくという形で。
ここではソースコードそのものも自動生成するという話も含まれているんだな？
UMLも気になるところだな。
ツールが高すぎて個人では手に負えないのであまり使っていない。EclipseのプラグインでFree版Omondo, UML2などをちょっと
見たことがあるが。Omondoでよくクラス図を書いてはいるがOmondoはとりあえずクラス図を書くと
Javaソースコードも勝手に自動生成する程度の機能はある。ほかはよく知らない。
0012デフォルトの名無しさん
2005/09/06(火) 00:08:37UMLの場合,
ＵＭＬからドキュメントを生成するのではなく、
ソースコードからUMLを生成したほうが楽な。
UML事態がドキュメントの役割を果たしているので。
UMLからドキュメントを生成するという発想は思いつかなかった。
それはそれで面白そうだ。
0013デフォルトの名無しさん
2005/09/06(火) 02:52:07それが違うんだよね。同一であってほしいだけ。
0014デフォルトの名無しさん
2005/09/06(火) 05:19:18試験工程ですごーく苦労するということ：
・試験結果をみてもバグが有ることがわからない（作っていないから）
・結合試験（システム単体での試験）でバグが分かっても、
どこを直したらよいか分からない
・自分（あるいはＰＪ）の命名規則に沿っていない関数・変数は
非常に読みづらい
ということで基本的にＣＡＳＥツールを使ってソースコードを自動生成
させるのには反対なのですが、皆様はどうでしょうか。
0015デフォルトの名無しさん
2005/09/06(火) 15:07:43書く量を差分で減らしてる。
が、BCBとかEclipse/Javaとかみてると、結構裏でコッソリソースに色々追加してる。
Eclipseだとコンパイルエラーの修正パターンを選択みたいに、生成パターンを幾つか選択できたり。
つまり、１度に吐き出す自動生成の時代は終わったが、Eclipse型IDEが実行時に吐き出すジェネレータは主流へと。
ただし、これを作るとはコンパイラメーカとの戦いか、Eclipseへプラグインとして取り込まれちゃうか、の諸刃の刃。
0016デフォルトの名無しさん
2005/09/06(火) 16:27:38に下流工程生産物の自動生成は有用かもしれないなあ。つーか欲しいです。
0017デフォルトの名無しさん
2005/09/07(水) 12:35:04つーことは、逆を言えば
(1) 自動生成の作業工程を分かり易く示したマニュアル、ＦＡＱがある
(2) 自動生成したソースに発生したバグに対する修正パターンを自動表示
(3) プロジェクト毎の命名規則に従って、関数・変数の命名を行う
であればOKってことね？
(まあ、他にも問題点探せばあるとは思うが・・・むしろ問題点を言って欲しい)
(1) はともかく、
(2) は、EclipseやVisual Studio .NET 2005 である程度対応できている。
(3) は、プロジェクト毎の命名規則を外部に外だしして、
命名規則に沿って変数名、関数名を自動生成するようにすればOK。
プロジェクト毎に変換定義のテンプレートを作っておけば対応できる。
0018デフォルトの名無しさん
2005/09/07(水) 12:35:43生産性向上したい＝楽がしたい
という意味においては、みんな同じ考えだよね？
0019デフォルトの名無しさん
2005/09/07(水) 12:50:16ドキュメントの自動生成にしろ、
ソースコードの自動生成にしろ、
ＣＡＳＥツールのメーカーのフォーマットに完全に従っていて、
使用者のフォーマットは完全無視状態。
ＣＡＳＥツールのメーカーは、
「ウチのフォーマットに合わせろよ」的な、
ある種の「押し付け」なんだよね。
作業工程の押し付けならまだ良いとしても、
ドキュメントは顧客に提出するものでもあるんだから、
それを固定フォーマットで生成されるとすごく困るわけよ。
だから、そこが問題で、
既存のＣＡＳＥツールは使えない状態。
その改善方法として、
プロジェクト毎に変換定義を作って、
その変換定義に従ってドキュメント生成やソースコード生成をすることで、
プロジェクトに合わせて、欲しいフォーマットに従った
ドキュメントやソースコードが生成される。
それって、すごく良いと思わない？
実際、XSLTなどで変換定義を作れば簡単に実現できるし、
実装も大して難しくない。
（XSLTで変換のマッピングを定義してやれば良いだけ)
そういうツールを作ろうと思っている。
0020デフォルトの名無しさん
2005/09/07(水) 13:57:34なぜなら、例えばDelphiでプロジェクト作成メニュー実行するとフォームが１枚開いて、
ＤＢコンポーネント複数貼ってプロパティ設定して、
実行ボタンを押したらＤＢ編集ツールが出来ちゃう。
0021デフォルトの名無しさん
2005/09/07(水) 23:09:3919の書いてるのは
XSLT定義を切り替えることで
プロジェクト毎に異なるフォーマットのドキュメントやソースコードを
生成できるってことだと思うぞ。
・プロジェクト毎の命名規則が反映されたソースコードの自動生成
・プロジェクト毎にフォーマットの異なるドキュメントの自動生成
受託開発だと、
IBM、NECと、会社毎に納品ドキュメント違うじゃん。
ドキュメントのフォーマットを、
XSLT変換定義でマッピング付けして生成することで、
異なるフォーマットのドキュメント作れるだろ？
ＤＢ編集ツールがどうとか、意味合いが異なると思うが
その辺どうなのよ？
0022デフォルトの名無しさん
2005/09/07(水) 23:14:43ttp://www.atmarkit.co.jp/fdotnet/tools/nunit2/nunit2_01.html
そのツールでは、テスト用のコードを作成して、
テストの自動化を行っているんだけど、
そのテスト用のコードの自動生成も
余裕でできると思うのよ。
画面とDBのデータマッピング情報からテストケースを生成し、
テストコードを自動生成することによって、
テストがかなり便利になると思うんだが。
0023デフォルトの名無しさん
2005/09/07(水) 23:19:52ツールに画面とDBのデータマッピング情報を入力し、
その情報をもとにして
「NUnit」用のテストコードを自動生成したらかなり便利になると思う。
どこかの会社が作ったデータマッピングツールで、
ツールに入力したレポジトリ情報を取得できれば、
その情報をもとにして
テストコードの自動生成は可能だと思う。
それができなければ
データマッピングツールを自作で作る必要があるな。
0024デフォルトの名無しさん
2005/09/08(木) 01:32:26> 会社に入って分かったのは、自動生成で作成されたソースコードは
> 試験工程ですごーく苦労するということ：
> ・試験結果をみてもバグが有ることがわからない（作っていないから）
> ・結合試験（システム単体での試験）でバグが分かっても、
> どこを直したらよいか分からない
それは自動生成ツールの信頼性が低く実績が少ないからではないかな。
有名何処の自動生成ツールなら実績があるので無駄にテストする必要がない。
それをわかってない奴がいると、無駄にテストしようとする、あるいはツールを使うのを拒もうとする。
Hibernateは信頼と実績があるので自動生成されたコードでとんでもない挙動を示すことは少ない。
それをわからない奴が見ると、自動化するとその分だけ余分にテストしないといけないから
使いたくないなどと言い出す。こういう人間を説得するのは大変だ。
すべてのオープンソース製品はフリーでサポートが無いから信用できないなんて言い出しかねない。
ApacheやTomcatを使っておきながらオープンソースは信用できないとか頓珍漢なことを言い出す輩もいる。
> ・自分（あるいはＰＪ）の命名規則に沿っていない関数・変数は
> 非常に読みづらい
>
> ということで基本的にＣＡＳＥツールを使ってソースコードを自動生成
CASEツールじゃなくてUMLにすればいいのに。
0025デフォルトの名無しさん
2005/09/08(木) 01:39:39それだったらEclipseでも似たようなことができる。
というかJUnitのC#版なんだけどね。
EclipseにもJUnitプラグインが同梱されており
いきなりJUnitによるテストで、テストファースト、テスト駆動開発を実践できる。
さらに、既存のJavaクラスから、テストクラスを自動生成する機能もある。
Javaのクラスにあるどのメソッドをテストするかも聞いてくる。
チェックボックスでテストしたいメソッドを指定すると
テストケースクラスとメソッドのスケルトンができる。
それについて、
自動生成を余裕でやるには構文解析とか大変なことをしないと行けないと思うが。
nullチェックなどワンパターン化されたものについてなど、ある程度までは自動ではできるとは思うが。
JUnitについては、Java5のアノテーションに対応した次世代版TestNGというものが開発されており、
NUnitと同等かそれ以上の機能を持つことに期待できそうだ。
0026デフォルトの名無しさん
2005/09/08(木) 01:43:31CommonclipseというEclipseプラグイン。
Javaのクラスにequals(), hashCode(),compareTo(), toString()メソッドを
Jakarta Commons langのライブラリを利用してオーバーライドし
フィールド値とその型などに合わせてそれらのメソッドを自動生成してくれるツール。
今のところ、Eclipse3.1には対応せず、Eclipse3.0までに対応。
http://www.eclipsewiki.net/eclipse/?Commonclipse
http://commonclipse.sourceforge.net/
0027デフォルトの名無しさん
2005/09/08(木) 03:04:420028デフォルトの名無しさん
2005/09/13(火) 02:08:20↓みたいな奴のこと？
http://www.genexus.jp/portal/hgxpp006.aspx
http://www.canon-soft.co.jp/product/web_performer/
こういうのって、本当に実業務でつかえるもんなの？
0029デフォルトの名無しさん
2005/09/13(火) 07:19:01XML で状態アクションマトリクスを記述するとか。
UIはそれにあわせたものを作ればいい。
0030デフォルトの名無しさん
2005/09/13(火) 07:20:440031デフォルトの名無しさん
2005/11/12(土) 01:32:180032デフォルトの名無しさん
2005/11/12(土) 12:13:390033デフォルトの名無しさん
2005/11/12(土) 12:50:22全然できてないから、わしらに仕事があるんじゃないか
0034デフォルトの名無しさん
2005/11/12(土) 12:55:06最低最悪、マニュアルは日本語化してないわ、開発支援ツールは作りかけだわ、
ビジュアル環境で開発できると思わせといて、コマンドライン入力が多いわ、動作重いわ
氏ね、どうせ上層部が口のうまい営業にだまされてホイホイ買ったんだろ
何千万の浪費だよ
0035デフォルトの名無しさん
2005/11/12(土) 13:03:13営業妨害です。通報しました。
0036デフォルトの名無しさん
2005/11/12(土) 13:41:540037デフォルトの名無しさん
2005/11/12(土) 13:57:38現在、唯一両立してるのってRubyOnRailsくらいだろ。
欲しいのがあるとすればJava版Rails、struts+s2+s2daoの組み合わせならぜひ使いたい。
0038デフォルトの名無しさん
2005/11/13(日) 03:45:510039デフォルトの名無しさん
2006/03/15(水) 23:41:07C#2.0 + Oracle 用のソースを生成する自動生成ツールは
需要ないかなぁ？
需要あるようだったら作ろうと思うんだけど。
0040デフォルトの名無しさん
2006/03/16(木) 09:26:58何を生成するんだ？
0041デフォルトの名無しさん
2006/03/16(木) 09:51:030042http://www.vector.co.jp/soft/win95/util/se072729.html
2006/03/18(土) 19:58:48もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
■ このスレッドは過去ログ倉庫に格納されています