- - PR -
UMLを用いた開発について
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-06-03 22:52
ソースが先でそこから共通表現方法としてUMLへ、に1票です。 ソースを正にしてAPI仕様書も生成する。 整合性や手間を考えてもそれが現状では一番なのでは? 本来ソースは設計の前に来ません、手の動きはソースが先になりえるだけです。 UMLからソース生成というのは今後に期待です。 完成する前には「UML」ではなくなるんじゃないですかね。 みんなが使える価格で、は欲しいですよね >objectさん。 ほんと、頼みますよ、買いますから。 | ||||||||||||||||||||
|
投稿日時: 2002-06-04 00:13
C#がマイクロソフト製品という意味ではJDKはSun製品ということではないかと思います。
JDKに入っています。
ソース互換という意味では、あくまでもコンパイラにとってはコメントに過ぎないので単に読み捨てられます。ただし、実際にはjavac(Javaコンパイラ)を使用しています(http://java.sun.com/j2se/javadoc/faq/index.html#implementation)。規格としては、javadoc仕様というのは存在しています(Java言語仕様第1版18章−第2版からは消えてますが分離されたと考えれば良いのかは僕にはわからないです)。 C#の場合は、言語仕様には含まれず、プログラマーズリファレンスにしか記述がないので仕様というわけではありません。
それはそうですね。しかし、できないというのは仕組み自体が悪いからかも知れません。選挙に金がかかるのは中選挙区制が悪いのか、選挙民と政治家が腐っているのかは小選挙制を試してみないと結論が出ないかも知れません(で、結論は出たんですかね?)。仕組みを変えることによってハッピーになれるのなら試して見る価値はあるかも知れません。いずれにしろ、2つのファイルをメンテナンスするのは良いことには見えません。統合できればそのほうが良いでしょう。
というのは、画面レイアウトとか画面遷移の話でしょうか? ならば、画面のプロトタイプ作成時点にリンクで画面イメージを入れれば良いと思いますが、そういう意味ではなくてですか? 管理/メンテするのはソースファイル上ですが、実際にドキュメントとして参照するのはHTMLです。 ただし、ユーザーインターフェイスそのもののクラスという言葉から受けるイメージからは、そもそもデザインとプログラムは分離しているので、仕様に含まれないように感じます。 画面レイアウトや画面遷移(という意味と仮定して)というのは要件定義で大雑把に出てきて機能定義の部分で決定しませんか? [ メッセージ編集済み 編集者: arton 編集日時 2002-06-04 00:29 ] | ||||||||||||||||||||
|
投稿日時: 2002-06-04 06:46
>(http://java.sun.com/j2se/javadoc/faq/index.html#implementation)。規格とし>ては、javadoc仕様というのは存在しています(Java言語仕様第1版18章−第2版からは>消えてますが分離されたと考えれば良いのかは僕にはわからないです)。
>C#の場合は、言語仕様には含まれず、プログラマーズリファレンスにしか記述がない>ので仕様というわけではありません。 これですが、失礼ですが、スタンダードの意味合いの捉え方に違いがあったようです。 標準規格と括弧で書いたのは、 メーカーが何をどうしている、メーカーの仕様にどう書いてあるって意味じゃないんです。 たとえば、ANSI Cとか、ANSI C++とか、何回か改定があってその都度発表 されてますよね? インターネットの世界では、W3Cとか、エンジニアリングタスクフォースとか、 メーカーではなく、こういう機関での、取り扱いでは、どこに位置するのか? もしくは、こういう機関で、本来のスタンダード(標準)を策定しようとする 動きがあるのか? それとも、メーカーの独自仕様でただ、競争原理に従うだけで終わってしまうのか? こう言う、意味だったんですが。。。 と、言うのは、Javaの方は可能性がある程度あると思うんですが。。。 C#は?若干疑問もあったので。 そこまでの実績が出来るのは?<C#が この意味でのスタンダード(標準規格)として、動きが出るか出ないかで、 現実の世界での仕事や業務でも、使われる頻度が変わってくるでしょうし、 また、競争原理でも、その言語の方向性がはっきり示され、有利な立場に 立てる。 そう、思ったので、私の方では情報があまりなかったので、お聞きしてみたんですが。 よろしくお願いします。 | ||||||||||||||||||||
|
投稿日時: 2002-06-04 09:03
C#については、ECMAドラフトの(Draft13)のEに記述があるので、ECMA標準化の方向はあるでしょう(資料が古いので現在は違うかも知れません)。 Javaの標準化は、JCPによって行われます(Sun主導化で−というと御幣はありますが−行われる)。その結果が、Sunから出されるJDKであり仕様ですので、この場合は、メーカーの独自仕様というのとは意味合いが異なります。 話は変わりますが、競争原理に従わないと、シグマプロジェクトやAdaやOSIのように破綻するだけだと思います(いらんことを書いてますが、この文は思い付きなので堪忍。破綻というのはデファクトスタンダードにはなれないという意味です。で、デファクトでないスタンダードは画餅だと思います)。 [ メッセージ編集済み 編集者: arton 編集日時 2002-06-04 09:56 ] | ||||||||||||||||||||
|
投稿日時: 2002-06-04 09:53
artonさん、ありがとう。
よく、わかりました。 そもそも、ある程度以前から、私も、 それらの団体が、云々する時代は終わっていると また、それらの団体が、標準なんて決める時間はもうすでに 無いのではないか? ANSIのC++でさえ、とんでもない時間と、大きな変更が加わっている。 標準化される前に、機能追加、新しい考え方利用の仕方その他、 現実の世界にすでに、適さない状況になっているのでは? と、思っていましたので。 ただ、情報が私の方が無かったので、 お聞きしたかったんです。 よろしくお願い致します。 | ||||||||||||||||||||
|
投稿日時: 2002-06-04 10:14
artonさん、こんにちは。
ご回答ありがとうございます。 本末転倒云々は、方法論みたいな中で『どうせ』という単語にひっかかっただけです。 この件は切り上げたいのですがよろしいでしょうか?
WEBアプリケーションでなくデスクトップアプリケーションの場合でお願いします。 #どうしても手馴れたVBに置き換えてしまうのは良くないですが... | ||||||||||||||||||||
|
投稿日時: 2002-06-04 10:20
次にDelphiを使いそうなので可能であればUMLデビューします。
#ご指名はよくないですが... ところでobjectさんは、Delphiの開発でUMLを使ってますか? UMLツールとか別として言語的にはUML使った方が理解が深まるイメージなのですが... | ||||||||||||||||||||
|
投稿日時: 2002-06-04 12:00
確かに乱暴な書き方でした。自戒の意味をこめて嘲笑的な言い回しをしたのが問題だったようです。すみません。
VBであっても変わらないと思うのですが。仕様に記述するのはユーザーインターフェイスを持つオブジェクトの振る舞いであって、デザインでは無いと思います(というか、僕はデザインと実装は切り離しています)。 ところで
なのですが、先に継承関係を決めたりインターフェイスを決めずにソースに入るのでしょうか? インターフェイスを決めておかないと後から結合する時点で困るように思えますし、最初に継承ツリーを確認しておかないとわけがわからなくなると思います。というのは.NETやJavaみたいにクラスがコンポーネントとして自立できる場合で、確かにCOMのコンポーネントではそれほど図は必要なかったですが。それでもインターフェイスが先に立たないと実装イメージもわかないと思います。もっとも、問題領域が異なると異なる方法論がありうるので、そういった差かも知れないですね。 | ||||||||||||||||||||
