UMLなんていらない

1 ：2011/08/31 〜 最終レス ：2012/10/31

擬似コードのほうがまし
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

2 ：

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

3 ：

クラス図と擬似コードではどちらがわかりやすいでしょうか？
# U言語
=============
Point ----|> Shape
-------------
- x: double
- y: double
-------------
+ move(dx: double, dy: double): void
=============
# 擬似コード例
class Point : Shape {
　　property dx = x
　　property dy = y
　　method move()
}

4 ：

クラス図は意味が無いのだから
どうでもいい。
クラス図以外の話をしようぜ。

5 ：

デザパタ本に一切図がなくて（擬似）コードだけで説明されてたらと思うとぞっとするわ。
多分 >>1 はデザパタなんて UML 推進派のでっちあげでそんなもん不要とか言うんだろうが。

6 ：

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

7 ：

ウムル？

8 ：

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

9 ：

>>8
じゃあ、お前がUMLを日本語に変換してくれ。
甲、乙は丙を継承し・・・とかやるんだろ？ｗ

10 ：

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

11 ：

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

12 ：

UMLで全てを設計するとかキチガイすぎる。
しかし解説用とか議論用ツールと割り切って、
重要でないメンバや関連線をスパスパっと
省いて、
資料に図を添付したりホワイトボードに
描いたりするには最強のツール。
シーケンス図なんかタイミングや順序が複雑で
図解があったほうがいいなって時だけ使えばいいし、
ステートチャート図も状態が複雑なやつだけ
図解すればいい。
状態が2つしかないのにステートチャートを
描いたりしてたら、UML意味あるの？
って疑問が出るのは当然。

13 ：

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

14 ：

ない

15 ：

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

16 ：

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

17 ：

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

18 ：

>>16
地図記号統合みたいな話だろ。
推進していたのは、統合させるためであって
統合が完了すれば、推進する必要がなくなるのは当たり前。
それと使うかどうかは別の話で統合してしまったあとは、
普通に使ってる。

19 ：

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

20 ：

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

21 ：

>>20
お前はUMLといったらクラス図しか知らないように見えるな。
クラス図はUMLで一番役立たずのものだよ。
それだけみて判断してるお前ってｗ

22 ：

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

23 ：

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

24 ：

してくれるだろ

25 ：

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

26 ：

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

27 ：

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

28 ：

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

29 ：

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

30 ：

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

31 ：

# 擬似コードの例
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でなまじ図にするよりわかりやすいと見るか、わかりにくいと見るか
# 人によって意見は分かれる

32 ：

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

33 ：

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

34 ：

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

35 ：

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

36 ：

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

37 ：

うほっ？

38 ：

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

39 ：

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

40 ：

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

41 ：

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

42 ：

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

43 ：

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

44 ：

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

45 ：

そりゃ、設計書を書かない所では
見かけないだろうなｗ
どんな底辺会社ｗ

46 ：

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

47 ：

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

48 ：

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

49 ：

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

50 ：

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

51 ：

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

52 ：

>>51
おいおい、オレオレフレームワークが
なぜダメか知ってるだろ？
UMLを使うと
・世界共通だから、ネット・書籍等の図も読めるようになる。
・世界共通だから、新たに人を雇っても（その人がUMLを理解してるのなら）教育の必要がなくなる
・すでに用意されているものだから、独自に書式をつくらなくてよい。
独自の書式にメリットはない。
何のために独自にするのさ。
あえて、違う書式を使う理由がないよ。

53 ：

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

54 ：

乗り換えられないようにする効果はない。
（人間辞めるときはすぐ辞めるから）
逆に教育の必要性というデメリットは
回避不可能。

55 ：

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

56 ：

>>55
それは大手だけ。

57 ：

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

58 ：

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

59 ：

ごく最近設立された新興企業でもない限り、
大手も中堅も、大抵は社内書式として、図の書き方等を独自に決めてるよ。
誰かがトップダウン的に決めたケースもあるし、長年のノウハウ蓄積の結果、
ボトムアップ的に決まったケースもある。
中小企業の場合だと、大手の実績のある手法を拝借する事もある。
そうやってきた企業にとっては、UMLなんてのは後から出てきたものでしかない。
自社に好都合なものが既にあるのに、わざわざUMLを新規に採用する必要がない。
使うのは、取引先から求められた場合のみ。

60 ：

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

61 ：

未来永劫フローチャートとCOBOL使い続けるのが「蓄積型思考」なのか？
B版の用紙に縦書きするのが「蓄積型思考」なのか？
ただのバカだろ、それ単に。

62 ：

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

63 ：

破綻に向けて好きに突っ走ってくれ
他人が吹っ飛ぶだけなら綺麗な花火だね、で済むからな

64 ：

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

65 ：

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

66 ：

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

67 ：

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

68 ：

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

69 ：

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

70 ：

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

71 ：

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

72 ：

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

73 ：

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

74 ：

古代の言語の古代の仕様だったら保守困難にならない、なんて保証がどこにあるんだ？
古代のハードウェア、古代のOSを使い続ける自由は、ネットワークセキュリティが問題に
なる以前のプラットフォームにしか存在しないぞ？
あるとすれば、サイバーノーガード戦法で世界中のさらし者になる自由ぐらいだ。

75 ：

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

76 ：

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

77 ：

詳細設計書の一部として、全クラスの全パブリックメソッドに
シーケンス図つける羽目になったことはあるよ。泣きたくなった。
>>73
昔からの奴を要件定義からやりなおすのも難儀だからなあ。
今のまま引きずっても仕様がないといえば仕様がない。
とりあえずlambdaかevalできればもうなんでもいいよ、漏れは。

78 ：

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

79 ：

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

80 ：

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

81 ：

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

82 ：

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

83 ：

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

84 ：

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

85 ：

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

86 ：

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

87 ：

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

88 ：

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

89 ：

UMLは正直、自分用になってるな。それはそれで役には立ってるが。
普及しなかった原因のひとつにはオープンソースは普及しても、オープンドキュメントが広まらなかったせいだと考えてる。
Unifiedの部分が「分かる人は分かる」であっては、どうしようもない。
ちなみに俺は初めてUMLを知った時、「ついにコーディングレスの時代が来たか…」と思った。当然幻想だった。

90 ：

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

91 ：

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

92 ：

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

93 ：

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

94 ：

Java作った連中もドクター取ってるか、それと同じレベルとみなされてるよな。
>>92 はグローバル変数だけしかなくて、関数定義すらもない言語でも、一生使ってればいいよ。

95 ：

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

96 ：

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

97 ：

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

98 ：

> 学術者が寄り集まってああだこうだ相談して作った記法や言語は得てしてわかりづらい。
この主張に照らしてどうか聞いてるんだが。

99 ：

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

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

ユニシステム株式会社 (205)
IT用語に(笑)を付けてみるスレ (335)
うどんかそば (788)
IT用語に(笑)を付けてみるスレ (335)
【政治】マ板ニュースオッチ Ver3【経済】 (265)
テストデータに「test」とか「てst」とかもうやめろ (367)
--log9.info------------------
iTMSプリカ販売情報共有スレ (411)
iPodにしか転送できないiTMS（ﾟ�听）ｲﾗﾈ　３ (645)
【自爆】SONYがiTMSに楽曲提供しない方針99％固まる (299)
【決して】敵はSONY。SONYとSMEは不買で【買うな】 (516)
ＡＡＣ対ＣＤみんな音質に関してはどうなのさ？ (866)
ソニー　ついにネット音楽配信でアップルに楽曲提供 (876)
【参加？】iTMS不参加レーベルに告ぐ【不参加？】 (360)
懐かしく】iTMSで懐メロ【新しい】 (240)
ナップスタージャパンシステム議論スレ (836)
iTunes Store　曲が追加されたら報告するスレッド (495)
【iTMS】iTunes値上げされたら上げるスレ (426)
1曲50円とかどう見ても安いと思うやつのスレ (486)
iTMSに曲提供しなかったSONYは2度氏ぬ！ (439)
フリーダウンロードの曲について語るスレ【２】 (402)
定額制の音楽配信サービスを語ろう (363)
アニソン・エロゲーソング総合スレッド (229)
--log55.com------------------
靴の匂いフェチ
diadora ディアドラ N.0001
シューツリー/シューキーパー　4
SPINGLE MOVEは語る　第3章
甲薄紳士靴が見つからず困っている！
【ハードボイルド】革靴探偵物語 一話【調査報告】
【大輔・仲田】本格靴クラクロ2【長谷・上条】
デッキシューズのスレ3