アカウント名:
パスワード:
今、UML流行ってますか?認知度は確実に上がっただろうけど・・・。再就職の時には認めてもらえる技術であって欲しい(笑)。
UMLどころか構造化ダイアグラムも知らない相手には, 未だにフローチャートです. DBの設計や画面展開図で書かれた要求仕様を見ると, どうやらデータ中心設計も正規化も知らないらしい...
ですからUMLはもっぱら内部向け, というより個人で作れる範囲での設計用ですね. プログラムを作る人間の8割がたはカプセル化, 継承, ポリモーフといった基礎的な概念が分からないので, UMLに沿った形での製造は不可能です.
さらにUMLやオブジェクト指向についての知識が有っても, それを活かした設計ができるかどうかはまた別の話で, UMLで記述されてはいても実態は従来
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
バラの花は・・・ (スコア:2)
今、UML流行ってますか?認知度は確実に上がっただろうけど・・・。再就職の時には認めてもらえる技術であって欲しい(笑)。
道具で設計はできない (スコア:1, 興味深い)
UMLどころか構造化ダイアグラムも知らない相手には, 未だにフローチャートです. DBの設計や画面展開図で書かれた要求仕様を見ると, どうやらデータ中心設計も正規化も知らないらしい...
ですからUMLはもっぱら内部向け, というより個人で作れる範囲での設計用ですね. プログラムを作る人間の8割がたはカプセル化, 継承, ポリモーフといった基礎的な概念が分からないので, UMLに沿った形での製造は不可能です.
さらにUMLやオブジェクト指向についての知識が有っても, それを活かした設計ができるかどうかはまた別の話で, UMLで記述されてはいても実態は従来
不十分な道具では尚更設計できない (スコア:3, 興味深い)
それとあと、UML自体の意味というか書式を理解してない(誤解した)まま
突っ走っちゃったプロジェクトってのも、痛いものが有りますね。
UMLの各記号の意味を「社内独自解釈」しちゃうんだったら、わざわざ「U」MLを使う必要は無いわけで。
#百歩譲って単なる非UML絵を描くツールとして使うっていうなら、せめてRoseみたいな高価なものは選ばないほうが…(^^;
ただ、気持ちは半分わかるんですよね。
そういう場面で UML専用ツールを使うのはどうよ?と疑問に思いますが、
それ以前に、そもそもそういう場面が有る、という点が重要なんだと思います。
つまり、UML自体の記述能力って、あんまり高くないですよね。
だからUMLを逸脱した記述をしたくなってしまう。ここが本質的問題だと思う。
#ついでにいえば、その低い表現力の中でも更にサブセットしか実装できていない、実在の各種UML製品…(T_T)
##そういう意味では、特にRoseは高すぎ!!
分析にせよ設計にせよ実装にせよ、やりたいことをUMLで「必ず」素直に描けるかというと
とてもじゃないがNOなわけで、そうするとUMLを(メインの)Documentとして採用した場合に
UML自体がプロジェクトの足を引っ張り兼ねなくなっちまう…
たとえば卑近な所で。実装についてですが、UMLの「関連」って、
一般的なプログラム言語で一般的な表現(^^;によって表現される「関連」と
結構ちがうものをしか表現できないんですよね。
あの表現は意味的にはむしろRDBの関連のほうに近くて、
OOP言語のポインタだか参照だかを使う関連とは、かなりノリが違う。
いや、それ自体単独ではそれでいいんですが、OOPはそもそも上流から下流まで
意味のインピーダンスミスマッチを少なく出来ますよってのが売りな筈なのに、
よりによってOOP設計のためのカナメのVisual言語(Document)に、
こんなインピーダンスミスマッチが新規に導入されてしまったんでは
OOPにとって「迷惑」だな、という思いが有りまして。
我々が大抵最初に思考の道具として使う自然言語は、(厳密さはかけるものの)かなり表現力があります。
計算機プログラム言語も、自然言語ほどじゃないけど表現力が結構あります。
なのに間に挟まるUMLの表現力がそのどちらよりも少なくて「ボトルネック」になってしまうのならば、
一体なん役に立つんだ?と心配になってしまいます。
部分導入、つまりUMLが得意とする表現「だけ」に使うならば、それでもOKですけど、
少なくとも今のUMLは、Documentの全てとか中心とかを任せるのは、きついと思います。
で、ということは、UMLのどの機能をイツどこで使うのが適切か?ってのを
見抜く確かな目がないと導入は逆効果になりかねないってことであって、
そういう意味ではUMLの導入ってのはそれ自体かなり難しいものがありますね…
Re:不十分な道具では尚更設計できない (スコア:1)
>計算機プログラム言語も、自然言語ほどじゃないけど表現力が結構あります。
>なのに間に挟まるUMLの表現力がそのどちらよりも少なくて「ボトルネック」になってしまうのならば、
>一体なん役に立つんだ?と心配になってしまいます。
表現力に富む=具体的
表現力が少ない=抽象的
ということなので、別によいのでは?
UMLは抽象的なレベルで他の人とコミュニケーションするための道具と考えてみては?
具体的なレベルでコミュニケーションしたい場合は、コードを見せると。
Re:不十分な道具では尚更設計できない (スコア:1)
>表現力が少ない=抽象的
>ということなので、別によいのでは?
抽象とか表現力少ないとか考えるためには、まず「どの表現を」削除してるか?を考えないとしょーがないですね。
そういう意味でUMLは、何か重要な情報の幾つかを誤って捨象しちゃってるんじゃないか、
という不安があります。
>UMLは抽象的なレベルで他の人とコミュニケーションするための道具と考えてみては?
人間相手にしか使えないというのがもし真ならば、
UMLとコードの間の自動変換機能って奴は、どれもこれも全て必ず原理的に、駄目なものでしか有りえない、
ということになりますが、それでいいんでしょうかね?
UMLってそこまで「使えない」ものでオワリだということなんでしょうかね?
Re:不十分な道具では尚更設計できない (スコア:1)
ならばAgreeです。
Re:不十分な道具では尚更設計できない (スコア:1)
どこまで有効か?という問題はありますね。
UMLと丁度同じくらいの自由度(っていうのかな)が、人間のコミュニケーションとして妥当な自由度なのかというと、
そんなの状況次第なわけで、「有効か」と問われれば答えは「何をコミュニケートしたいかに拠る」としか言えない。
そのUMLの有効範囲を過小評価しても過大評価しても、まずいことになるでしょうね。
で、今世間で言われてる程度(笑)よりは、UMLの表現力は、もう少しばかり小さい、んじゃないかと思います。
結局問題は、UMLの能力範囲を、世間が(普及とはそういうことですから)どれだけ誤解してないか?に尽きるんで
ちょっとのズレはそれなりに不安のモトとなります。
コミュニケーションのツールとして (スコア:0)
システム開発なんて全然知らないお客様と
要件を詰めていく時に使うのは難しいように
思っています。
# 今使おうとしているのでAC
Re:不十分な道具では尚更設計できない (スコア:1)
>表現力が少ない=抽象的
そうですか?
抽象度の高さというのは、(非可逆の)圧縮率の高さみたいなもんだと思います。
元の事象(?)をどの圧縮法で圧縮したかによって現れたサイズの差と。
表現力というのはその圧縮画像を見せてどれだけ雰囲気を伝えられるかということだと思いますし、
良い(その事象に適した)圧縮法を使用することにより、同じサイズでも伝わり方が違うのは周知の通りですので、
UMLの表現力がイマイチなのであれば、それは困ったことだと思います。
Re:不十分な道具では尚更設計できない (スコア:1)
hienさんは、UMLを使用して抽象的なレベルでコミュニケーションするにあたり、具体的にどこらへんで困りました?