- - PR -
Javaソース生成アプリケーションの実現性について
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2003-10-02 09:51
おはようございます。
もう一点重要な問題を忘れておりました。 それは、生成されたソースの妥当性を誰が検証するか、です。初歩的なパターンですと 「以上」と「それより大きい」の判定や異常なデータを故意に送信された場合の防御の ことを考えますと状況によりますが「ソースの自動生成はできない」と回答したほうが 安全な気がいたします。 [ メッセージ編集済み 編集者: Ken-Lab 編集日時 2003-10-02 09:55 ] | ||||||||
|
投稿日時: 2003-10-02 09:59
unibon です。こんにちわ。
一般に、仕様が明確に決まらないまま先走って開発を開始しようとすると、 どうしても一段階メタ度が高いもの(汎用性が高いもの)を 作ろうとしてしまうのではないでしょうか。 たしかに汎用性が高いほうが良く、技術的な面白みはありますが、 できれば、そのような苦労は避けられるのならば 避ける方向に持っていったほうが良いと感じます。 ヘタをすると、フレームワークやコンパイラを作ることになってしまいます。 話の腰を折るようですが、今一度、目的がなにかを検討されてはどうでしょうか。 すなわち、汎用性を重視した結果そうなったのか、 それとも速度を気にしていてそうなったのか、 はたまた、仕様が決まっていないからそうなったのか。 ＃そのような検討があった上でのご質問だったらすみません。 
＃以下、あとで追加。 すみません。最初のご投稿の先頭で、実現性を問われている旨、書かれていますね。 [ メッセージ編集済み 編集者: unibon 編集日時 2003-10-02 10:37 ] | ||||||||
|
投稿日時: 2003-10-02 10:26
もっと大掛かりにMDAぽく、
XSD+InfoPath とか RelaxerStudioプロジェクト（マッピングの中に検証が入っています） http://www.atmarkit.co.jp/fjava/devs/relaxer01/relaxer01.html を参考にしたらどうでしょう。 構文からパーサ生成も発想としては同じ物でしょう。 XMLBooster: the fastest XML parser generator http://www.xmlbooster.com/ パーサージェネレータなら多数あります、検証ジェネレータも 同列にできるでしょう。 クライアントに検証ツールを配布しなくて、 データアップロード でサーバーで検証もありです。ソフトの従量課金とかの面も開拓？ JavaWebStart とか ノータッチディプロイメント？ 普通のデータなら使い捨てのDBに登録してエラーが返るのを キャッチするとか。 昔ならデータ変換ツールで変換時のチェックを動かすとか（変換出力は捨てる） 今風なら適当にXML化してその結果を五万とあるXMLツールで検証する。 [ メッセージ編集済み 編集者: MMX 編集日時 2003-10-03 16:04 ] | ||||||||
|
投稿日時: 2003-10-02 17:04
皆さん色々書かれているようですが、、、^^;
元質問者さんの
に素直に回答すると、 実現性：ある 似たような開発経験：ない（理由は以下） ※同じような提案をされた際に、コードジェネレータではなく 普通に外部パラメータを読んでチェックする仕様を再提案し、それを 採用させた。 ですかね。 まぁ、「でも絶対やれ」って顧客から言われたら逆に美味しいかもしませんね。 なんせ、規模的に普通に創るよりも何倍も必要ですし。ウマー。 | ||||||||
|
投稿日時: 2003-10-02 20:12
ども。ソースジェネレータ作成経験者のraccoonです。
いわゆるIDLコンパイラみたいなやつをけっこう作ってました。 # BNFで文法作ってyaccとlex使って・・・，というヤツ。 私もやはり，今回のケースでわざわざソースジェネレータを作るべきかは 疑問（ってかむしろやらなくてよいのでは，と思っているクチ）ですが， それは他の方々が発言してくれているので， ここはソースジェネレータについての話をします。 「できる／できない」でいうと「できる」が結論です。 工数や難易度については，文法の複雑さ・自由度や出力ソースの量と質に 影響されるのでなんともいえません。 提示いただいた程度ならば大したことありませんが， # yaccやlexなんて使うまでもない。perlスクリプトとかでもできそうだ。 汎用性や拡張性のある文法にすると，それだけ工数＆難易度が上がります。 # 凝ろうと思えばいくらでもできてしまう。 また，Wataさんのおっしゃるとおり，「どの程度かわりうるか」を見越したうえで， それに耐えうる文法とチェック仕様を決めないといけないでしょう。 データの仕様が変わるのは構わないのですが，定義の文法や チェック機能の仕様が変更となると，結局はほとんどの場合， ソースジェネレータ自身の修正が必要となってしまいます。
コンパイルは毎回行う必要はなく，インタフェースデータ仕様が変更されたとき （＝定義ファイルが変更されたとき）にだけ行えばよいはずです。 ファイルのパースは毎回必要なので，その分の性能向上は見込めると思います。
生成されたソースの正当性を検証するのは，ソースジェネレータを作った人です。 *ソースジェネレータを作る人は，ソースジェネレータが正しく動作することを検証する。 *ソースジェネレータの正しい動作とは，正しいソースを生成することである。 *正しいソースとは，仕様どおり動作する（この場合は正しくチェックを行う）ソースである。 ということで，ソースジェネレータを作る人は，あらゆる定義文でジェネレータが 正しく動作することを検証（テストで確認）し，かつそのソースの内容が正しい， つまりそのソースがあらゆるデータで正しく動作することを検証（テストで確認）します。 したがって，ステップあたりのテスト工数は通常のプログラムよりも多めに考えておいてください。 [ メッセージ編集済み 編集者: raccoon 編集日時 2003-10-02 21:09 ] | ||||||||
|
投稿日時: 2003-10-02 22:21
あらためまして・・・。 これはソースジェネレータである、と考えれば極端な話eclipseも一部ソースを 生成しているわけで珍しいものではなかったですね。 この話題のカギは、クライアントさんがソースジェネレータの価値をどのように捉え、 どのぐらいの開発費を捻出していただけるか、というところにあるのでしょうね。 | ||||||||
|
投稿日時: 2003-10-09 19:21
やるとしたらなんでもソースジェネレータだけでやると考えるより
チェックを行うクラスを別に用意して,それを使用するだけの部分を ジェネレータで作るぐらいが効率的では | ||||||||
|
投稿日時: 2003-10-10 08:42
ハネさんこんにちは。
ソースを作る必要は無いのではないでしょうか？ 必要なのは、アプリケーション生成アプリケーション？ではないでしょうか ソースというと、人間が読めるソースコード(*.java)のことですよね？ それだけではコンピューターは何も実行できません。。。。 クラスファイル(*.class)を生成するのではないでしょうか？ 外部定義ファイルは最初に１回だけ読み込んでずっと保持していれば、 データごとに毎回読みに行く必要は無いのではないでしょうか？ クラスファイルを毎回作らないのと同じだと思います。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。