- - PR -
シーケンス図からのソース生成
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2007-05-29 12:36
Blogのアクセス記録を見て、この会議室の議論を知りました。Blogを書いている「こうの」と申します。
シーケンス図に対する私の個人的な意見は、皆さんの一連の投稿と同じですが、1点だけ。
あります。山ほどあります。 ただ、ここでの投稿にあるように、完全に生成するためには、シーケンス図に細かい情報まで書かなければなりません。それを維持するのはさらに大変です。 キタキツネさんが考えるような、ある程度の設計からスケルトン+αのコードを生成する、というような使い方は現実的だと思います。ただ、ツールとして実装するのであれば、そのレベルでは許されません。多くの人が望んでいるのは、「完全に生成する」機能なのです。 そして、この機能をツールが提供したとしても、設計者が幸せになるとは考えづらいです。実現すると、設計者は細かいレベルまでシーケンス図を書かされる可能性もあると思います。(効率化のための「手段」としてツールを使っているはずなのに、ツールが「目的」となってしまう危険性があります。) そういったわけで、この機能を提供する予定は今のところありません。当事者が出てくるのもどうかな、と思いましたが、ご参考になれば幸いです。 | ||||
|
投稿日時: 2007-05-29 13:57
「完全に」生成するんですから、細かいレベルまでシーケンス図を書かないと所期の 結果が得られません。「可能性もある」じゃなくて、「当然」細かいレベルまで、と いうか全てのメッセージを記述します。 で、これでエンジニアが幸せになるかというと、「JAVAエンジニア」は必ずしも 幸せにはならないかも知れません。シーケンス図から完全に動作するJAVAのコードを 生成するっていうことは、JAVAはこの場合中間言語としてしか機能していない わけで、つまりエンジニアがプログラミングするのはもはやJAVAではなく 「シーケンス図言語」なわけですから。メンテナンスも原則シーケンス図に対して 行うので、シーケンス図のメンテナンスが面倒、と言うのはそれこそ本末転倒。 いわばシーケンス図がソースコード。出来たJAVAコードはは一応テキストだけど コンパイラの吐いたオブジェクトと一緒。 JAVA上でチューニングなりメンテナンスなりを行おうというのならシーケンス図からの 「完全な」自動生成を使うのは(少なくとも現在のレベルの自動生成では)手段の 選択としては誤りだと思います。 もし、シーケンス図言語によって「完全に動作する」プログラムをより効率的に 記述でき、メンテナンスも楽になるような状況があれば担当するエンジニアは 幸せになれるんでしょうが(先に紹介したRose RealTimeだとかRhapsodyだとかは 幸せになる、と主張しているわけですが)、それは「JAVAエンジニア」の幸せとは 必ずしも一致しないでしょうね。 | ||||
|
投稿日時: 2007-05-29 14:42
完全互換のシーケンス図を作ったとしたら、それはもはやJava言語そのものになっちゃいますよね。
文字列によるコーディングではなく、グラフィカルな図形によるコーティングになった場合、 どのような感触なのかな?というのは興味深いのですが。 (脳で言えば言語野によるコーディングではなく視覚野によるコーディングになるのかしら?) 情報としてはシーケンス図側にも完全なJavaのコードを内包する必要がありますが、 図示するに当たってメソッドコール全てを図示しなくとも良いわけで、 レベルを設定できるようにすればある程度の見易さは確保できるかもしれない。 しかし、先にも述べたようにどこまでを表示する/したいというのは 人間側の主観によるところですから、マーキング方式でもしないとやはり難しいのでしょうか。 | ||||
|
投稿日時: 2007-05-30 08:06
こんにちは。皆さん返答ありがとうございます。
>こうのさん 確かにツールを作成される立場としては辛いですよねぇ。。正直、自分は「シーケンスからソースを書き出せたら便利!」という考えだけで、そこまでは考え至りませんでした。 (Blogにも書きましたが)機能限定版のアドインとしてでも提供して頂けると嬉しいです。 ※ちょっと話しがそれますが、Beanが自動生成できるようになると、実装するのってビジネスロジックだけになると思ってます。DAOはabator(iBATIS)でSQLまで含めて全部生成できますから。(多少の追加はあるでしょうが) 実装がビジネスロジックだけというはいい感じだと思ってます。 自分の意見としては、最終的にシーケンス図のみで全ての作業を完結できると良いと思ってます(JAVAは全くでてこない)。やっぱりソースコードよりは図のほうが分かりやすい。前後の処理も見やすいですしね。 ただ、皆さん仰っている通り、全て記載するとごちゃごちゃし過ぎるというのは自分も感じています。nagiseさんの言われていたように、表示レベルを設定できると嬉しいですね。指定パッケージ以下の処理のみ表示、とかsetter,getterは記載しない、とか。※思いつきで書いてますが あとは開発効率の問題でしょうか。実装についてはEclipseを初め、色々と便利なツールが揃っているので、現時点ではソースコードを直接書くほうが圧倒的に早いんですよねぇ。。UMLで完結するのはまだまだ先なのかな? |