アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
javaでイイと思う (スコア:0)
javaが無難だと思う。
javaだとフレームワークやらEJBなんか使ってれば、
大規模システムでも、実際にコーディングする部分はそれほど
多くないけど、phpなんかだと、基本的な機能まで一から作
Re:javaでイイと思う (スコア:1)
>javaが無難だと思う。
質問。
Javaって「設計から落としやすい」ですか?
というか、そうだとしたら、それは何故?
ふつーのOOP言語なら、「設計からの落とし易さ」はどれも同じようなもんだと思うが。
ちなみにUMLとJavaの相性は、(巷で言われてるのと反して)全然良くないっすね。
だいたい、オブジェクト間の「参照」とU
Re:javaでイイと思う (スコア:0)
>みたいな 基礎的な部分からして、考え方が全然違うじゃん。
そりゃ当たりまえですよ。UML はモデリング言語であって実装言語では
ないんですから。実装レベルの概念でしかモデル化できないんだったら最初から実装言語で書いた方がましです。
業務分析の段階では、オブジェクト間の整合性を
Re:javaでイイと思う (スコア:1)
>実装レベルの概念でしかモデル化できないんだったら最初から実装言語で書いた方がましです。
「モデリング」にも色々あるはずなのにも関わらず、
UMLはそのうちの1つ(?)の方法しか提供してないのが、痛いんだと思います。
それこそOOPはモデリングから実装までの概念の地続きっぷりが売りなのですから、
たとえば、ふつーのプログラム言語と同じ意味の「参照」が
UMLみたいなモデリング言語の「関連」を表すための概念として採用されても、よかったはず。
だって、あの「参照」って、プログラムの中でしか通用
Re:javaでイイと思う (スコア:0)
ツール屋の金儲けのネタであって、付き合うだけ時間のムダ
だと思います。コミュニケーションツールであると割り切って、
VISIOで描いた図で済ませる程度の付き合いが、UML との
適切な距離の取り方でしょう。極論を言えば、UMLが最大の
実力を発揮するのはホワイトボードの上でしょう。
「参照」という概念はプログラム外でも見られますが、
「関連」という曖昧な概念をすべて置き換えるには全く
不十分です (だって両端に自然言語で「ロール名」が
書けて、「承認する」みたいな曖昧な表記でとりあえずは
済ませられるんですよ?!)。結局、システムの両端にある
ビジネスロジックとマシン語のインピーダンスミスマッチの
総量は不変なので、「人間の高度な思考」の必要量は一定
なんですよ。できるのは、適切な中間層を設けてレベルの違う
事柄を一度に扱わないで済ませたり、設計/実装に移る前に
要求されるシステムとの乖離をチェックしたりというだけです。
#435228 にも書いたんですが、G7 さんは最初から実装言語で
書く XP のような開発方法論を導入した方がいいと思いますよ。
現実には、XPほど後戻りに寛容な方法論を導入できないことが
多いので、UMLで図を書いて、脳内で動かすプロトタイプとして
活用せざるを得ないわけですが…。
Re:javaでイイと思う (スコア:1)
>ツール屋の金儲けのネタであって、付き合うだけ時間のムダ
あはは。それもそうですね。
ただ問題は、金儲けネタのつまらんものが
UML(のツール)のうち変換自動化機能「だけ」なのか?という疑問です。
>極論を言えば、UMLが最大の
>実力を発揮するのはホワイトボードの上でしょう。
たしかにRoseに数十万円(かける人数分!!)を払うのはアホらしいものを感じてます。
#MSWordでDocumentを統一するだけでもゲイツ税がアホらしいのに、
#遥かに高いツールを制式Documentとして採用しちゃうと、Rational税が更に悲惨…
問題は「コミュニケーションツール」という位置付けが何なのか?なんだろうな。
UMLという言語をカタコトでも話して、まあそれなりの意思疎通を図れればよし、
という程度の期待しかしないならば、前述したようにそれはそれなんですが、
UMLの定義を厳格に真に受けると、UML自体の仕様の不備(表現力の不足や蛇足)やツールの不備に
延々と付き合わされて、生産性が低いったら…
さて本題。
>「参照」という概念はプログラム外でも見られますが、
>「関連」という曖昧な概念をすべて置き換えるには全く
>不十分です
ん?なんで置き換えないとならんのでしょう?
(あの)参照と(あの)関連って、抽象度だのなんだのにおいて、
そんなに違う位置に位置していないと思います。
>(だって両端に自然言語で「ロール名」が
>書けて、「承認する」みたいな曖昧な表記でとりあえずは
>済ませられるんですよ?!)。
なにか驚くに値しますか?
そういう実装言語を作りゃいいじゃないですか。
#てゆーか有るし。
つまり、所詮は「関連」だって実装言語にそのまま落とせる概念なんです。
逆にいえば、UMLみたいな位置付けの言語が「参照」を採用しても
べつに悪くなかっただろうなとは思います。
だって「参照」と「関連」の違いって、単に単方向か双方向かの違いだけでしょう。
つまり「参照」を逆向きにも自動的に張る仕組みが有れば、それで同じモノになります。
#他にも色々実装手段はあります。そしてそれを(いちいちプログラマがやるんじゃなく)自動的にそうなるようにすることも可能。
というか、逆に言えば、単方向と双方向をオプションの切り替えだけ(見た目も矢印が違うだけ)で
表現するってやり方が、本当に抽象度が高いかどうか怪しいです。
もっと全然違うものかも知れないものを「兼用」して合体させてるだけ、かも知れないのに。
あと、曖昧な表記ですって?
もし識別子として日本語が通る言語ならば、「承認する」って
そのまま書いてコンパイル通るじゃないですか?
曖昧でもなんでもないじゃないですか?
#どーでもいいがJavaは日本語とおりますね。変数名とかは日本語でOKみたい。こないだ気付いて爆笑した。
#ただしJavaはClassファイル名がClass名と同名であることが義務付けられてるために、
#ファイル名としてその日本語名が処理できない環境ならば、アウト(^^;
#Win上のJDKでは、javacどころかjarすら日本語ファイル名が処理できないようで…なんだかなあ…
それとも「済ませられる」ってのを「処理まで記述しないと完結しない」という意味で
捉えてらっしゃいますか?
だとしたら、それはなんか変です。とりあえずオブジェクト(指向)ならば、
処理はさておいて先ずクラスと「属性」の定義を脊髄反射的に済ますことが出来る。
つまり望みのクラスに「承認する」という属性を作ればいいんです。
数十秒で書けるでしょ?コード補完機能のついた環境ならsetter/getterまで作っても殆ど時間を要しないし、
そもそも「思考の抽象性」も損なっていない。
#型を考えるのは面倒(=抽象性を妨げる)ので、型なし言語のほうが便利です(^^;
そして、昔のエライ人も言っているように、属性さえ(きちんと)設計できれば、後はなんとでもなります(^^;
つまり、属性決めたところで話を一段落させていいんです。
>ビジネスロジックとマシン語のインピーダンスミスマッチの
>総量は不変なので、「人間の高度な思考」の必要量は一定
それはマシン語に展開した後の総量を見れば同じでしょうけど、
人間に課される量、つまり展開される前の量、は変化するんじゃないですか?
俺が個人的に「足し算と掛け算の違い」と呼んでいる現象(?)がコレに当たるんだと思います。
たとえば10を表現する際に加算しか使っちゃいけないというルールなら、3+7だろうが2+8だろうが
合計は10になる(当たり前)ですが、積算も使ってよくなれば2*5とか出来る
Re:javaでイイと思う (スコア:0)