UMLなんていらない

**仕様書無しさん** · 2011/08/31(水) 23:03:20.01

擬似コードのほうがまし
http://ja.wikipedia.org/wiki/%E7%B5%B1%E4%B8%80%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E#.E6.89.B9.E5.88.A4

**仕様書無しさん** · 2011/08/31(水) 23:05:36.74

ここは、UML. 未確認言語 (Unidentified Mysterious Language) について
語るスレです。興味がない人は書き込まないようお願いいたします。

**仕様書無しさん** · 2011/08/31(水) 23:25:31.05

クラス図と擬似コードではどちらがわかりやすいでしょうか？

# U言語
=============
Point ----|> Shape
-------------
- x: double
- y: double
-------------
+ move(dx: double, dy: double): void
=============

# 擬似コード例
class Point : Shape {
　　property dx = x
　　property dy = y
　　method move()
}

**仕様書無しさん** · 2011/09/01(木) 02:52:17.98

クラス図は意味が無いのだから
どうでもいい。

クラス図以外の話をしようぜ。

**仕様書無しさん** · 2011/09/01(木) 15:11:48.59

デザパタ本に一切図がなくて（擬似）コードだけで説明されてたらと思うとぞっとするわ。

多分 >>1 はデザパタなんて UML 推進派のでっちあげでそんなもん不要とか言うんだろうが。

**仕様書無しさん** · 2011/09/01(木) 16:48:40.92

ユースケース図とかは不要だな

**仕様書無しさん** · 2011/09/01(木) 19:22:22.10

ウムル？

**仕様書無しさん** · 2011/09/01(木) 21:29:03.11

むしろデザパタは解説にUMLが使われるせいで無駄に難解なんだと思う
日本語でしゃべれ

**仕様書無しさん** · 2011/09/01(木) 22:27:56.03

>>8
じゃあ、お前がUMLを日本語に変換してくれ。

甲、乙は丙を継承し・・・とかやるんだろ？ｗ

**仕様書無しさん** · 2011/09/03(土) 08:13:43.54

>>9
なに言ってんだこいつ

**仕様書無しさん** · 2011/09/03(土) 08:14:40.81

おまえが日本語読めないだけだろ

**仕様書無しさん** · 2011/09/03(土) 23:38:54.80

UMLで全てを設計するとかキチガイすぎる。

しかし解説用とか議論用ツールと割り切って、
重要でないメンバや関連線をスパスパっと
省いて、
資料に図を添付したりホワイトボードに
描いたりするには最強のツール。

シーケンス図なんかタイミングや順序が複雑で
図解があったほうがいいなって時だけ使えばいいし、
ステートチャート図も状態が複雑なやつだけ
図解すればいい。

状態が2つしかないのにステートチャートを
描いたりしてたら、UML意味あるの？
って疑問が出るのは当然。

**仕様書無しさん** · 2011/09/07(水) 06:31:30.84

自分用のちんまいツールを作ってるだけの趣味グラマな俺の場合、
UMLって学ぶ価値あるかな？

**仕様書無しさん** · 2011/09/08(木) 18:08:11.33

ない

**仕様書無しさん** · 2011/09/08(木) 20:46:46.63

>13
UMLっていうのはいろんなモデリングをひっくるめた名称だからね
趣味グラマだったらそのうち５種類くらいしか使わないと思う

**仕様書無しさん** · 2011/09/09(金) 00:05:23.57

一昔前は業界標準と言われてあちこちでもてはやされてたわけだが、推進してた奴らはみんな逃げたの？
象形文字みたいな記号並べてスカスカの資料大量に作ってたのはなんだったのか…

**仕様書無しさん** · 2011/09/09(金) 00:25:35.53

かといってモデリングまったくやらないのはよくないと思うけどね
俺が入るところはいきなりコーディングするやつばっかりだ

**仕様書無しさん** · 2011/09/09(金) 01:39:04.19

>>16
地図記号統合みたいな話だろ。

推進していたのは、統合させるためであって
統合が完了すれば、推進する必要がなくなるのは当たり前。

それと使うかどうかは別の話で統合してしまったあとは、
普通に使ってる。

**仕様書無しさん** · 2011/09/09(金) 08:20:53.99

（全くそういう手法を取り入れない前世紀から旧態依然な所も結構あるんだよw）

**仕様書無しさん** · 2011/09/10(土) 12:45:53.76

DB層以外のモデリングが必要なEJBが死滅した段階でUMLなんてほとんど用済みだろ？
フレームワーク部分以外で複雑なクラス関連をプログラマが理解する必要のあるプロジェクトなんて炎上確実だよ。

**仕様書無しさん** · 2011/09/10(土) 13:24:28.46

>>20
お前はUMLといったらクラス図しか知らないように見えるな。

クラス図はUMLで一番役立たずのものだよ。
それだけみて判断してるお前ってｗ

**仕様書無しさん** · 2011/09/10(土) 17:55:43.57

おまえの語彙ではプログラマ＝コーダだから、としか読めない

**仕様書無しさん** · 2011/09/11(日) 07:18:40.78

UMLを書くと、自動的にコーディングしてくれればいいんだけどな。

**仕様書無しさん** · 2011/09/11(日) 12:34:37.18

してくれるだろ

**仕様書無しさん** · 2011/09/11(日) 12:39:02.16

>>24
じゃあ、クラス図以外から
コード生成してくれるものを教えてください。

**仕様書無しさん** · 2011/09/11(日) 12:40:31.56

なお、クラス図を省いているのは、
クラス図は単なるコードのサブセットに過ぎず、
コードから生成できるから必要ないのです。

**仕様書無しさん** · 2011/09/11(日) 13:15:34.75

出来ない理由ばかり考えてるからそんな卑屈な性格になっていくんだよ

**仕様書無しさん** · 2011/09/11(日) 13:19:05.37

話はあなたが質問に答えたあとに聞いてあげます。

**仕様書無しさん** · 2011/09/11(日) 13:34:19.38

UMLだけでプログラムの全てが記述できるわけ無いじゃん

**仕様書無しさん** · 2011/09/21(水) 00:55:46.62

ＵＭＡやったほうがいいよ

**仕様書無しさん** · 2011/10/07(金) 20:46:16.22

# 擬似コードの例
class 女の子 {
　　property 名前
　　property 年齢
　　property 性別

　　性別 = "女"

　　method new(name, age) {
　　　　名前 = name
　　　　年齢 = age
　　}

　　method sayHello() {
　　　　printf ("%sといいます。%d歳です。\n", 名前, 年齢, 性別)
　　}
}

class ツンデレ : 女の子 {
　　method sayHello() {
　　　　printf("別にあんたの事なんて何とも思ってないんだからね！\n")
　　}
}

MAIN {
　　Miku = 女の子.new("未来", 16)
　　Mina = ツンデレ.new("美奈", 18)
　　Miku.sayHello()
　　Mina.sayHello()
}
# これをUMLでなまじ図にするよりわかりやすいと見るか、わかりにくいと見るか
# 人によって意見は分かれる

**仕様書無しさん** · 2011/10/07(金) 20:58:40.16

擬人化できるクラスなんて実際はほとんどないけどね

**仕様書無しさん** · 2011/10/07(金) 23:43:57.63

>>31
女の子classに性別propertyは必要か?
俺は組込だから、オブジェクト指向すら怪しいが

**仕様書無しさん** · 2011/10/08(土) 00:08:55.27

この手の話題はDB設計でも上がるが、性別とジェンダーは別だとかなんとか。
一応コンストラクタで性別受け取ってないって部分でカバーしてるんだろうが、
それならpropertyという表現が適切かどうかという(ry

**仕様書無しさん** · 2011/10/08(土) 08:51:51.58

女の子クラスが人間クラスの継承で、人間変数に女の子インスタンスをつっこんでるとき、メンバ変数で見れたほうがソースが見やすいだろうな。

**仕様書無しさん** · 2011/10/08(土) 09:08:11.91

僕はJava VMになって全てにアクセスしたいです

**仕様書無しさん** · 2011/10/08(土) 13:01:41.65

うほっ？

**仕様書無しさん** · 2011/10/08(土) 16:16:04.83

さすがにもう使ってないや。
せいぜい、個人レベルのメモ程度の用途で、UMLっぽいのを書くことがある程度。
顧客に提出しても、たいていは意味不明な図だとしか思ってもらえないため、提出資料としての価値がない。
社内限定で使うにしても、内部資料に時間・コストをかけるわけにはいかず、
結局は簡略化したコードや、日本語の文書で書く事になる。

**仕様書無しさん** · 2011/10/09(日) 12:17:48.65

UMLみたいな学者が考えた設計書って
理路整然と体系だっているのはいいが
真面目に作ると枚数もかさむし、重要な部分とそうで無い部分が並列に扱われるから
実際業務で扱う作り手、読み手からしたら
机上の空論感が半端ない。

**仕様書無しさん** · 2011/10/09(日) 12:20:07.92

そしてプログラムもそういう調子で書くわけ？

**仕様書無しさん** · 2011/10/09(日) 13:48:12.21

>>39
UMLを考えたのは学者ではありません。
実用のために作られたものです。

クソ素人が

**仕様書無しさん** · 2011/10/09(日) 13:59:38.35

OMGが学識者や、大企業が非効率な自分たちのノウハウ標準にしようと圧力かけられておかしな方向に進んだこと知らないのかね？

**仕様書無しさん** · 2011/10/09(日) 14:11:39.10

必死でググってdisってるホームページ探したんだね、えらいえらい

**仕様書無しさん** · 2011/10/09(日) 14:42:11.07

もうあまり見かけないよ。
中身を見る事なんて無いのに、ソースから自動的にクラス図の生成をやってる所がある程度だ。
いまだに、納品物の量がこなした仕事の量だと思い込んでいる取引先もあるので、
納品物水増し程度には役立つ。

**仕様書無しさん** · 2011/10/09(日) 15:18:21.36

そりゃ、設計書を書かない所では
見かけないだろうなｗ

どんな底辺会社ｗ

**仕様書無しさん** · 2011/10/09(日) 18:45:16.75

みんな必死こいてUML書いてたのって、かれこれ7～10年ぐらい前だろ？
完全にIT業界の黒歴史だと思うんだけどね。

**仕様書無しさん** · 2011/10/09(日) 19:35:53.35

うん。使いどころがわかって、どう使えばいいかもわかってきたから、もう誰も騒がなくなった。
そして、わからない奴は永遠に取り残されたわけだw マシン語があれば無敵とか、
構造化なんて一時的なブームとか信じてた人たちみたいに。

**仕様書無しさん** · 2011/10/09(日) 20:18:26.45

作っても、納品物として要求されないんだよ。
設計書の一部として添付しても、レビュー時に「なんじゃこりゃ？」と言われ
結局削除するはめになる。
PGやらSEやらはUMLを理解していても、取引先の担当者が理解していない以上は、
まさに「なんじゃこりゃ？」な図でしかないんだ。

**仕様書無しさん** · 2011/10/09(日) 20:20:24.95

じゃあソースコードも読めないだろうから、ソースコードも納品しなけりゃいいんじゃね？

**仕様書無しさん** · 2011/10/09(日) 20:26:37.40

>>48
お前は、UMLは自分たちが使うものって
考えが全くないんだなｗ

**仕様書無しさん** · 2011/10/09(日) 23:12:06.38

納品対象外の内部資料なら、
共通的な書式である必要がないからな。
伝わりづらいとこだけあれば十分だし、それ以外は蛇足でしかない。

**仕様書無しさん** · 2011/10/09(日) 23:49:38.89

>>51
おいおい、オレオレフレームワークが
なぜダメか知ってるだろ？

UMLを使うと
・世界共通だから、ネット・書籍等の図も読めるようになる。
・世界共通だから、新たに人を雇っても（その人がUMLを理解してるのなら）教育の必要がなくなる
・すでに用意されているものだから、独自に書式をつくらなくてよい。

独自の書式にメリットはない。
何のために独自にするのさ。
あえて、違う書式を使う理由がないよ。

**仕様書無しさん** · 2011/10/09(日) 23:54:04.80

んなもん簡単に他に乗り換えれないようにするために決まってんだろ馬鹿

**仕様書無しさん** · 2011/10/10(月) 00:22:09.14

乗り換えられないようにする効果はない。
（人間辞めるときはすぐ辞めるから）

逆に教育の必要性というデメリットは
回避不可能。

**仕様書無しさん** · 2011/10/10(月) 00:46:45.28

新卒文化の日本では
新たに雇う人＝新入社員
新入社員でUMLが分かってるヤツなんて
居ないから結局教育コストは減らない。
大手の顧客情シスはコボラー集団だしw

**仕様書無しさん** · 2011/10/10(月) 00:55:06.07

>>55
それは大手だけ。

**仕様書無しさん** · 2011/10/10(月) 01:06:15.60

大手生保で2000人規模のコボラー集団かかえてるとこあるよw

**仕様書無しさん** · 2011/10/10(月) 01:15:50.67

大手で将来にわたってクビにならないという前提ならいいんだが、
今の世の中その考えは楽観的すぎだし、
会社に将来を殺されないように気をつけてね。

**仕様書無しさん** · 2011/10/10(月) 13:49:40.64

ごく最近設立された新興企業でもない限り、
大手も中堅も、大抵は社内書式として、図の書き方等を独自に決めてるよ。
誰かがトップダウン的に決めたケースもあるし、長年のノウハウ蓄積の結果、
ボトムアップ的に決まったケースもある。
中小企業の場合だと、大手の実績のある手法を拝借する事もある。

そうやってきた企業にとっては、UMLなんてのは後から出てきたものでしかない。
自社に好都合なものが既にあるのに、わざわざUMLを新規に採用する必要がない。
使うのは、取引先から求められた場合のみ。

**仕様書無しさん** · 2011/10/10(月) 14:59:24.62

欧米のような消費型思想と日本の蓄積型思想の違いだな。
日本企業は新しいものは取り入れても、今を捨てて新しいものに完全に置き換えることは嫌うから。

**仕様書無しさん** · 2011/10/10(月) 15:02:20.25

未来永劫フローチャートとCOBOL使い続けるのが「蓄積型思考」なのか？
B版の用紙に縦書きするのが「蓄積型思考」なのか？

ただのバカだろ、それ単に。

**仕様書無しさん** · 2011/10/10(月) 16:39:44.32

実際そんな理屈言っても通用しないんだよ。
予算が足りないからできませんなんてのは言い訳にならないから、今あるものをつぎはぎで使うことになる。
年金とか銀行とかのシステムがいい例。

**仕様書無しさん** · 2011/10/10(月) 16:42:47.06

破綻に向けて好きに突っ走ってくれ

他人が吹っ飛ぶだけなら綺麗な花火だね、で済むからな

**仕様書無しさん** · 2011/10/10(月) 18:20:36.00

予算が足りないという
言い訳はいらないからｗ

**仕様書無しさん** · 2011/10/10(月) 19:18:19.87

COBOLは2050年でも現役だろう。
ヘタすると、22世紀まで生き残ってる可能性も否定できない。

時代遅れだと言われつつもCOBOLを使い続けた会社が
100年以上の実績を持つ貴重な資産を持つ事になる。
もちろんその頃には、JavaだのVBだのC++だのは消滅して忘れ去られている。
そんな短寿命のものに手を出し続け、その度に更新を繰り返し続けた会社は、
ろくに蓄積もなく、何度でも同じようなシステムを作り直し続ける。

**仕様書無しさん** · 2011/10/10(月) 19:29:17.03

うん。

そりゃあ、業界全体のシェアから見たら、全盛期の10%も生き残ってなくて、それでもなお
>>65 みたいな狂信者がいるんだから、最後の 1% はそれぐらい長生きするだろうねぇw

**仕様書無しさん** · 2011/10/10(月) 20:11:17.88

開発のシェア的にはそうだが、
現役のソースコード量としては、10%どころじゃない。

**仕様書無しさん** · 2011/10/11(火) 02:43:15.18

コボラーはコボラーだけでやっててくれればいいよ
どれだけコボルが稼働していようと、眼中にないものは眼中にない

**仕様書無しさん** · 2011/10/12(水) 22:31:41.45

もしCOBOLを完全排除する場合、他言語での作り直し、移行に何十年かかることやら。

移行が完全完了する頃には、最も古いコードは20年や30年以上前のもので、
旧式言語を排除したつもりなのに、新規開発に使用した言語も既に
旧式化している事だろう。

**仕様書無しさん** · 2011/10/13(木) 06:24:51.06

元のCOBOLの古さにかわりはないだろうし、
新しいCOBOLがあることももしかして知らない？

**仕様書無しさん** · 2011/10/13(木) 20:23:32.38

オブジェクト指向を取り入れただの、MSの.Netに対応しただの、
新世代のCOBOLが作られても、ついていけるコボラーがどれだけいるのか？

**仕様書無しさん** · 2011/10/14(金) 06:56:29.86

結局、技術の根が古い新しい関係なく、
ついていける奴と、ついてこれない奴、がいるだけなんだよなw

**仕様書無しさん** · 2011/10/14(金) 19:42:28.13

>>71
どうせ30年後には、新世代COBOLではなくなってる。
最新のものが登場したからと言って採用し続けると、
多数の世代の言語が混在し、保守困難になる。
古代の言語に統一されている方がまだマシだ。

**仕様書無しさん** · 2011/10/14(金) 20:46:43.19

古代の言語の古代の仕様だったら保守困難にならない、なんて保証がどこにあるんだ？
古代のハードウェア、古代のOSを使い続ける自由は、ネットワークセキュリティが問題に
なる以前のプラットフォームにしか存在しないぞ？

あるとすれば、サイバーノーガード戦法で世界中のさらし者になる自由ぐらいだ。

**仕様書無しさん** · 2011/10/14(金) 22:16:34.68

金融機関「外部接続は基本的に専用線。しかたのないものは、イントラと物理的にも論理的にもネットワーク分断しております」

**仕様書無しさん** · 2011/10/15(土) 00:09:58.82

製造業でも、外部とは物理的にネットワークが繋がってないのがよくある。
内部犯行や、従業員を装って内部に侵入するケースがない限りは、
攻撃を受ける事は考えられない。
だから10年以上前のソフトウェアを、セキュリティパッチも当てずに
何の問題もなく使い続けていたりする。

**仕様書無しさん** · 2011/10/15(土) 21:57:56.31

詳細設計書の一部として、全クラスの全パブリックメソッドに
シーケンス図つける羽目になったことはあるよ。泣きたくなった。

>>73
昔からの奴を要件定義からやりなおすのも難儀だからなあ。
今のまま引きずっても仕様がないといえば仕様がない。

とりあえずlambdaかevalできればもうなんでもいいよ、漏れは。

**仕様書無しさん** · 2011/10/15(土) 22:53:07.54

COBOLはどうでもいいから
フローチャートの再来であるUMLをなんとか滅ぼそう

**仕様書無しさん** · 2011/10/16(日) 11:00:33.41

フローチャートの再来みたいな糞低レベルのUMLなら滅ぼされてしかるべきだが

**仕様書無しさん** · 2011/10/16(日) 11:45:38.65

初期のシステムでやりたいこと整理のためにユースケース図は便利やね。
もちろんなんとなく図で把握できればいいし、
下手すりゃ客に見せることもあるので正式なユースケース技法じゃ書かないけど。
クラス図？なにそれ。美味しいの？

**仕様書無しさん** · 2011/10/16(日) 12:21:51.31

まあmainに全ての処理を書いちゃう奴にはUMLなんていらねえよなw

**仕様書無しさん** · 2011/10/16(日) 15:01:20.65

新入社員になんかやらせる時はシーケンス図を描かせてみるな。細かい記法はいいからと言って。
すると、たいてい1オブジェクトに処理が集中するんで、そこで責務の話をすると通じやすい。

**仕様書無しさん** · 2011/10/16(日) 19:06:05.30

フローチャートの方がまだマシだわ

**仕様書無しさん** · 2011/10/16(日) 19:53:28.05

フローチャートとかマジで言ってんの？
頭の医者にかかったほうが…

**仕様書無しさん** · 2011/10/16(日) 22:00:19.56

UMLの資格の受験料高すぎだろ・・・

**仕様書無しさん** · 2011/10/16(日) 22:30:05.16

>>85
受験料をぼったくるための資格なんだから当然の事。
実はあれって有用性ゼロで、ただのぼったくりじゃないのか？と思う人が増えたら、
UMLに替わるものを作り、今度はそれの資格の受験料でぼったくるさ。

**仕様書無しさん** · 2011/10/16(日) 23:27:03.44

有用性のある実用的な資格なんてほとんどないだろ？
合格基準と、実用性が乖離している資格が大杉。

**仕様書無しさん** · 2011/10/28(金) 22:51:36.97

今後はUMLが常識になり、知らない奴は淘汰されるのではないかと思い、
自腹で書籍を購入して学習した俺はバカでしたよ。
あれから何年たっても、どこの案件でも、使う機会は一切なし。
UMLの使用を提案しても、相手にされる事はない。
自社で受注した案件でも、他社の下請け案件でも、UMLと言う言葉すら登場しない。
他の事に金と時間を使うべきだった。

**仕様書無しさん** · 2011/10/28(金) 23:15:41.45

UMLは正直、自分用になってるな。それはそれで役には立ってるが。
普及しなかった原因のひとつにはオープンソースは普及しても、オープンドキュメントが広まらなかったせいだと考えてる。
Unifiedの部分が「分かる人は分かる」であっては、どうしようもない。

ちなみに俺は初めてUMLを知った時、「ついにコーディングレスの時代が来たか…」と思った。当然幻想だった。

**仕様書無しさん** · 2011/10/30(日) 09:03:39.01

標準化してるくせに見やすくないよな
もっとパッと見て理解できるようになったら普及するんじゃね

**仕様書無しさん** · 2011/10/30(日) 14:48:37.63

個人レベルの資料やメモとして、UMLもどきを書く事があるくらいだ。
自分さえわかればいいので、完全に自己流の図だ。

**仕様書無しさん** · 2011/10/30(日) 23:25:34.25

学術者が寄り集まってああだこうだ相談して作った記法や言語は得てしてわかりづらい。
そうじゃなければ個人がネタで作ったC言語およびその派生言語がここまで流行ることはなかっただろう。

**仕様書無しさん** · 2011/10/30(日) 23:35:51.14

C言語を作ったデニス・リッチーは学術者だよｗ

**仕様書無しさん** · 2011/10/31(月) 11:17:51.04

Java作った連中もドクター取ってるか、それと同じレベルとみなされてるよな。

>>92 はグローバル変数だけしかなくて、関数定義すらもない言語でも、一生使ってればいいよ。

92 · 2011/10/31(月) 16:53:06.90

意味を取り違えるなよ。
企画段階から自称頭のいいヤツら大勢集まって、考えたものはダメってこと。
一人の天才が自己完結させた物の方が、シンプルで分かりやすい。
だた天才は意外とポカやらかすから最小限の欠点のみ凡人が外堀埋めて完成させる必要があるけどね。

**仕様書無しさん** · 2011/10/31(月) 18:30:45.25

ほう、それでそれで

Pascalについてはどう説明してくれるのか楽しみだ

92 · 2011/10/31(月) 22:11:28.14

とっくに死滅したとの認識。
派生言語のデルファイが一時期流行ったのもGUIが手軽にできるVB以外の唯一の選択子だったから。

**仕様書無しさん** · 2011/11/01(火) 00:58:06.49

> 学術者が寄り集まってああだこうだ相談して作った記法や言語は得てしてわかりづらい。

この主張に照らしてどうか聞いてるんだが。

**仕様書無しさん** · 2011/11/04(金) 20:04:11.54

DelphiはVBライクにGUIを作成でき、VBより高速動作するのが売りだった。
でもObject Pascalなんて知ってる人はごく少数派。
結局、拡張や保守に難があり、消えていった。

**仕様書無しさん** · 2011/11/18(金) 21:29:43.59

コードが全部仕上がってから、ツールを使ってクラス図を自動生成する程度。
中身は見ない。
そうやって納品物を水増しすれば、何も知らない人の目には
多量の仕事をこなしたかのように見せる事ができる。

UML登場以前にも、ツールで関数一覧や呼び出し階層一覧を自動生成したりして、
形だけの水増し用資料を作っていた。
それと同じ。