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

**仕様書無しさん** · 2011/11/20(日) 06:38:24.00

>>100
クラス図は設計であるが、
そのクラス図はソースコードから作れる。
すなわちソースコードは設計そのものということになる。

ソースコードを書く作業がクラス図を書く作業そのものであるため、
クラス図を作る意味はない。これがUMLで一番使われないと言われている理由。

そしてソースコードから生成できるのはクラス図しか無い。
クラス図が役立たずなだけで、それ以外のドキュメントは必要なのだ。

**仕様書無しさん** · 2011/11/20(日) 10:02:57.23

重要なビジネスロジックの仕様書くUMLって存在しないよね？
なんかUMLって要らない部分の仕様書ってイメージ。

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

いらない部分って？

**仕様書無しさん** · 2011/11/21(月) 07:10:38.26

「重要なビジネスロジック」って何のこと言ってるの？
抽象化で消える、ソースコードでしか表現できないような細部のことを指してるなら、
そりゃ抽象化の道具である図にはならんわな。

**仕様書無しさん** · 2011/11/21(月) 07:11:09.87

>>103 プログラムには設計はいらなくて、コーディングさえすればモノは作れると思ってるとかw

**仕様書無しさん** · 2011/11/21(月) 12:52:11.04

そこで形式仕様(ry

**仕様書無しさん** · 2011/11/21(月) 14:33:31.80

ジャクソン父子はすごいよな

**仕様書無しさん** · 2011/12/25(日) 23:18:27.69

最終的に納品資料を検収するお客サマは、システムなんて一切知りませんよ。
プログラミングなんて言っても一切言葉が通用しない。
UMLなんて書いても、意味のわからない謎の図形だとしか思われない。
そんな人達から、検収を受けないと先に進めないんですよ。

**仕様書無しさん** · 2011/12/26(月) 08:14:17.72

システムの中身がわからないのに「検収」と称して、何をやるんだ？

書類を紙飛行機にして、飛んだら合格？

**仕様書無しさん** · 2011/12/26(月) 20:27:45.02

今時UMLなんて過去の遺物を納品物件として持って行ったら、
システム屋の自己満資料持って来て馬鹿じゃないの？って言われて、速攻で叩き返されるのがオチだろ？

**仕様書無しさん** · 2011/12/26(月) 21:01:23.66

>>109
提出した文書について、隅から済まで以下の点を徹底チェックする。文書の内容は不問。
・誤字脱字
・フォントおよびフォントサイズの統一
・図や罫線の位置ズレ
・文体の統一チェック（ですます調、である調など）
・パンチ穴のズレ、破れチェック
・英単語が使われている場合は辞書を引いてスペルミスのチェック
・その他文章の不統一チェック（アラビア数字と漢数字の混在、全角カナと半角カナの混在、漢字の送り仮名の統一など）

**仕様書無しさん** · 2011/12/27(火) 00:10:08.83

>>109
お前、何か物を買ったときに
検品したこと無いの？

**仕様書無しさん** · 2011/12/27(火) 00:10:54.53

>>110
お前の客の話？
その客にお前は合わせてるの？ｗ

**仕様書無しさん** · 2011/12/27(火) 09:50:22.86

>>112 10kgに耐える強度が必要なものの検品なら、9kg掛けてみるのが検品。
それの色艶を見て評価するのはバカの所業。

なのにプログラムでは、そのバカの所業を「検品」と称してるんだろ、バカなの死ぬの死んじまえ。
っていう話だということも分からない奴は、全員強度不足の飛行機に乗って死ねばいいよ。

**仕様書無しさん** · 2011/12/27(火) 10:01:25.75

>>114が正しいな。
実際の世の中で通用するかは別だけど…
めんどくせぇ。

**110** · 2011/12/27(火) 12:20:01.57

>>112
もう客がUML学習にコストかけてシステム屋にレベル合わせてくれる時代じゃないんだよ。

**仕様書無しさん** · 2011/12/27(火) 13:22:46.08

客は日本語、それも自分がわかる用語で書けとしか言わんしな。

**仕様書無しさん** · 2011/12/27(火) 13:46:14.62

UMLなんかで設計してるから他人のメールアドレスが
付与されちゃうような事態になるんじゃないですかね

**仕様書無しさん** · 2011/12/27(火) 14:37:06.93

ﾄﾞｷｭﾓのｼｽﾃﾑってそうなの？？？
kwsk

**仕様書無しさん** · 2011/12/27(火) 16:02:32.36

所詮は「言語」なんで、日本語でもゴミのような文章もあれば、きちんとした文章もあるのと同じだと思うが。

**仕様書無しさん** · 2011/12/27(火) 19:55:23.06

>>118
確かに、「間違っても他人のメールアドレスが付加されないように」とか、UMLで表現出来るとは思えない。
あり得ないはずの事態に対して念押しのようなロジックって、UMLだと確実に漏れそう。

**仕様書無しさん** · 2011/12/27(火) 20:56:56.98

>>111
どうせ文書しか読んでくれないから、文章力のある人が重宝される。
大学や大学院で国文学を専攻し、優れた文章に触れる機会が多かった人を歓迎だ。

昔、NECがPCの説明書の文章を、作家に書いてもらった事がある。
技術屋が書くと理解困難になるので、畑違いではあるが、文章を書いてでメシ食ってるプロに委託したってこと。
システムの仕様書も、そういうやり方でいいのでは？と思い始めた。

**仕様書無しさん** · 2011/12/27(火) 21:30:02.31

テクニカルライタなんていらない、という発想か
斬新だな

**仕様書無しさん** · 2011/12/28(水) 09:25:43.80

設計前のPTにしては文字が多すぎだし、
書くのが面倒だからCBには向かない。
大昔のSAのほうがまし。

2文字表現してみました(´∀｀)。

**仕様書無しさん** · 2011/12/28(水) 21:58:11.86

そういうもんなのかなあ
文学的表現なんて不要なんだから淡々と論理的に説明すればいいだけだと思うんだが
理解不能になったのはその技術屋が説明へたくそだったってだけで

**仕様書無しさん** · 2011/12/29(木) 00:08:25.63

淡々と論理的に説明しても、技術屋の書く文章なんてお客サマは一切理解しませんよ。
文章力のある人に書いてもらい、内容はさっぱりわからないが
説得力のある結論が書かれているので、検収印を押すという状況に持ち込むんですよ。

やる事は、銀行や証券会社のリテール営業と同じ。
高度な金融商品は、専門的な学習が必要で、一般人にはまず理解できない。
ところが彼らは口が上手いので、内容をわかっていない客にわかった振りをさせて納得させ、
契約までこぎつけてしまう。

**仕様書無しさん** · 2011/12/29(木) 00:31:40.50

日本も国際標準のシステム構築費先払い制になればいいのに。
売上だけ進行基準にしても、客に変な言いがかりつけられて、検収人質に契約外のタダ働きされられるから意味ねーよ。
システム範囲やドキュメントレベルが顧客の気分でどんどん水増しされるwww

**仕様書無しさん** · 2011/12/29(木) 15:48:17.83

事前に範囲を決めておきますよ。
水増しの話が出てきたら、すぐに営業が飛んで行って追加費用の話になりますよ。
揉めに揉めたあげく、開発側が妥協させられるはめになりますた。

**仕様書無しさん** · 2011/12/29(木) 20:12:41.13

システム屋が水増しだと訴えても、顧客側が契約範囲を拡大解釈するから、お互いの言い分は平行線で交渉にならん。
プロジェクト開始前の見積額が数倍だった時に書いてあった提案書の内容が、いつのまにか全て約束したことにされてたり。

**仕様書無しさん** · 2012/01/04(水) 14:54:11.76

日本だと先払いは困難だろ
後からどんどん追加機能や修正を求められても、
契約外だと言って全て突っぱねても良いなら可能だけど

**仕様書名無しさん** · 2012/01/04(水) 19:43:12.36

つっぱねをやると、そこからは二度と仕事は来ないからな。
IBMはそれでどんどん評判悪くなって日本での仕事が減ったわけだし。

**仕様書無しさん** · 2012/01/06(金) 02:37:59.03

>>125
書くこと書いてりゃイイんだろ、とばかり冗長な表現になることが多い。
長々と書いている間に混乱してしまう事もある。
内容そのものは間違いではないので一層タチ悪い。

「Aの出力」と書けば分かるとこが、たとえば
「機能Aを実行完了した際に結果として発生したAの実行出力結果アウトプット帳票印刷」
になる。

そりゃまあ完了しないと出ないんだし、エラーじゃなく正常な出力のことを言ってるんだし
出力結果をファイルにしてから印刷用にフォーマット整えて印刷指示までかけるように
処理してるんだけどさ・・・

**仕様書無しさん** · 2012/01/09(月) 22:02:21.81

習得しても使う機会がない
取引先が国内企業だろうと、外資だろうと、公官庁だろうと、
UMLを使用した文書の作成を求められる事がない。
内輪だけで使う資料に、UMLを採用する必要性もない。
せいぜい、自分だけしか見ない、個人用メモに使う程度。

**仕様書無しさん** · 2012/01/15(日) 17:23:55.53

20年後や30年後に、大昔のシステムを全面更新するため
古い設計書を見たら、意味不明な図が多数ある。
若手のプログラマやSEは、それが何なのかもわからず頭を抱える。
そこへ頭の薄くなった大ベテランが現れ、とうの昔に廃れたUMLだと語り、
懐かしそうにそれを眺め、「俺が若い頃はよぉ・・・」と誰も頼んでいないのに昔話を始める。

そんな光景を思い浮かべた。

**仕様書無しさん** · 2012/01/15(日) 18:06:04.07

古くなるものとそうでないものの見極めがつかない奴ってよくいるよねー

**仕様書名無しさん** · 2012/01/15(日) 21:43:26.42

エジプトの壁画に書かれてる落書きみたいな象形文字も、実は高度な文明遺産なのかもね。

**仕様書無しさん** · 2012/01/15(日) 22:17:03.26

少なくとも、今もこれからも
UMLに変わる図が存在しないことは事実

**仕様書無しさん** · 2012/01/16(月) 22:43:39.36

大手は70年代から図の書式統一を試み、実際に社内書式として確立させてきた。
その下請けを担った中堅、中小も、大手の手法をそのまま真似たり、
自社流にアレンジした上で使ってきた。
もちろん、技術の変化に合わせた改良は、常に続けてきた。

後になってからUMLなんてものが登場してきても、
顧客から指定がない限りは採用はできません。
ある年代を境に、それまで統一してきたはずの図の書式がガラリと変わるのは困ります。

**仕様書無しさん** · 2012/01/17(火) 01:42:07.52

そしてあるとき外資系と協力することになった。
当然外資系はUMLで統一だｗ

**仕様書無しさん** · 2012/01/17(火) 20:57:00.82

HPとIBMの仕事をしたことがあるけれど、UMLと言う言葉が出た事もなかった。
外資も日本企業と同様、独自書式を使ってた。
その独自書式の、社内検定まで作ってた。
IT産業黎明期からやってる企業なので、日本企業以上に独自ノウハウの蓄積が大きいんだろ。
10年後に残ってるかどうかもわからない新興の規格より、
30年以上使ってる上、今後30年も使う予定の、独自規格の方がよほど安心できる。

**仕様書無しさん** · 2012/01/17(火) 22:07:00.26

自分たちだけで最後まで全部やり切れるなら
独自書式のほうが使い勝手がいいに決まってる。

**仕様書無しさん** · 2012/01/17(火) 23:31:11.54

だが、悔しいことに
書籍までは、社内独自書式が使えないんだ。

だからいつまで立っても理解出来ない。
くそ。底辺なのか

**仕様書無しさん** · 2012/01/18(水) 07:29:46.39

社内独自規格で世間から取り残されて何十年。
ただの死亡フラグだよそれwwwwww

**仕様書無しさん** · 2012/01/18(水) 19:23:02.00

社内は社内で必要ならやればいい。
だけどUMLは世界標準なため、
書籍なんか見てもUMLで書いてある。

間違ってもどこかの会社でしか通用しない
図はでてこないｗ

社内で必要な図を否定はしないが
UMLはどちらにしろ学ばなければならないもの。

UMLを学ぶのは当然として、社内でしか通用しない図まで
学ばなきゃいけない会社かどうかってだけだ。

もしくは、社内でしか生きられない人になるのも良い。
おすすめはしないし、俺にはありえない選択だが、
世の中にはそういう奴もいるだろｗ

**仕様書無しさん** · 2012/01/18(水) 19:29:47.95

帳票系しかやったことないのか？

**仕様書無しさん** · 2012/01/18(水) 19:47:43.25

新しい規格、開発標準、開発言語、ライブラリが、毎年のように登場する。
学ばないと生き残れないと思い、必死になって習得し続けたものの、
ふと気づいてみると、ほとんどが10年もすれば廃れている。
世界標準だの何だの言っても、気づいた時には誰も使っていない。
過去の遺物と化した世界標準が、当時を知る人しか理解できない迷惑物となっていく。
内輪でしか通じない、独自規格ばかりが残り、現場での試行錯誤の末に、より一層進化・洗練され続けている。

そんな事を、何十年も前から繰り返してきた。
相変わらず新しい規格が登場し、世界標準を標榜するが、もう手は出さない。
すぐに過去の遺物になるような資料を、これ以上増やさない。

**仕様書無しさん** · 2012/01/18(水) 20:02:42.58

>>146
もしかして社内専用の物が
標準になると思ってるの？

それは無いぞｗ

だからUMLしか選択肢はないんだよね。

**仕様書無しさん** · 2012/01/18(水) 20:05:14.15

>>147

世の中の理不尽に文句を言ってもしょうがない。

UMLは普通に書籍などで使われてる。
今使う必要があるのだから
学ぶしか無いのだよ。

**仕様書無しさん** · 2012/01/18(水) 20:20:33.00

2～3年もすれば、破棄して新規に作り直すようなシステムばかりじゃないんだよ。
10年や20年以上に渡って運用し続けるシステムで、
ごく短期間で移り変わり続ける、標準とやらに従うのは無意味。
書かれた時代によって標準が異なるため、まるで統一性のない資料よりは、
社内でしか通用しない規格だが、全体統一が取れている方がよほど見やすい。

**仕様書無しさん** · 2012/01/18(水) 20:30:16.86

お金を払うのはお客様です
お客様が採用しろと言えば、独自規格でも喜んで採用します
お客様が採用するなと言えば、世界標準であろうと何であろうと絶対に採用しません
ただそれだけです
私たちは、お客様が支払うお金から給料を貰い、生計を立てているサラリーマンです
それを忘れずに

**仕様書無しさん** · 2012/01/18(水) 20:45:00.25

自前の技術もなければ、他所に通用する技術もない。
そういうどんづまり状態に陥るパターンの見事な実例ばかり。

**仕様書無しさん** · 2012/01/18(水) 20:56:30.60

だから、社内の技術は必要なら使えばいいじゃない。

だけど、UMLは世界の標準技術で
実際に使われているから、やらざるを得ないってこと。

会社独自の技術は会社やめればゴミにしかならないけど
世界の標準技術はゴミにはならない。

**仕様書無しさん** · 2012/01/18(水) 22:10:00.06

なぜそれを使う必要かを考えないからお前らはだめなんだよ

**仕様書無しさん** · 2012/01/18(水) 22:22:03.03

なぜそれを使う必要があるかを考えた。

書籍などで使われてるから
勉強するにしてもUMLは必要。

**仕様書無しさん** · 2012/01/19(木) 00:22:50.66

共通言語だからな。
方言だったり、別の言語でもいい。

**仕様書無しさん** · 2012/01/19(木) 00:53:53.50

UMLが世界の標準だと言い張るのは自由だけど、どこの企業もそれを求めてこない。
日本企業も、外資の日本法人も、外国企業も。

プログラミング言語、データベース、モデリング、ネットワーク、
ハードウェア、プロジェクト管理などなど、様々な分野の
和書を見ても洋書を見ても、UMLなんてほぼ見かけない。

例外的にUMLが多用される書籍は、UMLそのものの解説書。
UMLのためのUMLでしかない。

**仕様書無しさん** · 2012/01/19(木) 02:45:56.33

>>156
言い張るも何もUML以外を使う理由がないから
普通にUMLで書かれている。

デザインパターンの本とか
設計絡みの本ではUMLで書かれてるよ。
組み込み系でも普通にシーケンス図はよく使われてるし。

図解の図ではなくて、技術的な
図が出てきたらUMLと思えばいい。

そのことに気づいてないとしたら、よっぽど勉強をしない人か
UMLがあまりにも素晴らしくて意識せずに読めるかのどちらかだ。

**仕様書無しさん** · 2012/01/19(木) 22:34:12.85

UMLのためのUMLって何かわかる気がする
基礎的なUMLの知識は、より一層UMLを理解するための知識で、
それ自体が更に、より高度にUMLを理解するための知識でしかないって感じ
UMLの目的はUMLであり、UMLの手段もUMLってところか
閉じた世界での自己完結

**仕様書無しさん** · 2012/01/19(木) 22:37:13.81

閉じた世界で生きてるから
今の技術書に書かれているのがUMLだと
いうことにも気づかない。

**仕様書名無しさん** · 2012/01/20(金) 08:57:00.39

そもそもUMLは、オブジェクト指向台頭期のEJBなんかの過度なオブジェクト指向設計に対応するために作られたんじゃない？
現在のようにフレームワーク中心の形に落ち着けば、アプリ屋側が利用するUMLなんてごく一部に限られるだろ？

**仕様書無しさん** · 2012/01/20(金) 11:32:54.09

フレームワークを理解しないで使うだけの人ならそうだね。
そういうのを、使えていると言っていいのかどうかは知らないが。

**仕様書無しさん** · 2012/01/20(金) 19:55:08.56

UMLを多用する世界しか知らない人も多いんだろうな
そのような書籍しか見ないから、あたかもUMLが常識であるかのように錯覚してしまう

野球の事しか頭にない人達が、誰でも野球に興味を持つのが当たり前で、
野球を好まない人はおかしいと言うのと、同じようなものかな

**仕様書無しさん** · 2012/01/20(金) 20:37:45.67

これからは知らないでは済まないだろうと思い、
UMLの入門書を買ってみたのは6年も前のこと。
今のところ活用する機会は一切無く、今後も無さそうだ。
習得必須の世界標準だと煽り、書籍、セミナー受講料、資格試験料をぼったくる商売だったんだろう。
俺は見事に騙されて本を買っちゃったって事。
次は同じ手には引っかからないよう注意しようと思う。

**仕様書無しさん** · 2012/01/20(金) 21:39:22.97

> 今のところ活用する機会は一切無く、今後も無さそうだ。

単にお前がゴミクズなだけじゃね？

普通に技術書買えば、ほとんど採用されてるし。

**仕様書無しさん** · 2012/01/20(金) 21:56:50.05

みんな馬鹿だなぁ。

**仕様書名無しさん** · 2012/01/20(金) 23:21:20.84

流行るとか、これからの業界標準とか言われながら一向に普及しない規格作ったりするやつらってなんなの？
ASP、EJB、SOA、RFID、クラウドもほとんどの場合はハードを持たないホスティングに過ぎないし…

**仕様書無しさん** · 2012/01/20(金) 23:55:21.66

知ってて損はないと思うが

**仕様書無しさん** · 2012/01/21(土) 05:01:39.13

メインフレーム一筋の人は「いまどきメインフレーム以外の仕事なんてほとんどない」と言う
「技術書もほとんどはメインフレームだ」とも言う
そういう人にとっては、メインフレーム以外のものは、
視界に入っても全く意識する事もないんだよ
UMLを擁護する人も同じようなものでしょ
世界が狭すぎというか、自分の世界が狭い事の認識ができていない

**仕様書無しさん** · 2012/01/21(土) 05:55:09.35

むしろUMLを腐す人にあてはまるだろその理屈はw

**仕様書無しさん** · 2012/01/21(土) 07:08:51.21

つかさ、本読まないのかな？

UMLはもう普通に使われてるよ。

**仕様書無しさん** · 2012/01/22(日) 09:54:06.66

国内の一部の連中は、基本的に全く情報収集をしないよ。
自分が使っている計算機環境についてすら、全く無知ということすらある。
テンプレをコピーしていじるのが仕事、っていう。

**仕様書名無しさん** · 2012/01/22(日) 12:44:55.23

オブジェクト指向でやろうとするとデザインパターンに自由度があり過ぎて、メインフレームみたく暗黙の定石が無いから、毎回UMLで設計してるってことなんだろうが、それって効率悪く無いか？

**仕様書無しさん** · 2012/01/22(日) 13:01:29.71

定石があるものなら定石を使えばいいだけ。
というか、そもそも定石がどんなものかを明確に記述する目的の「言語」なんだが。

それとも172はどんな複雑なものでもかっちり1000行でまとまってる魔法の定石集でも持ってるのか？

**仕様書無しさん** · 2012/01/22(日) 13:05:39.82

>>172
それがお前のやり方？
お前のところは効率の悪いやり方してるんだな。

UMLは図を書く時にどれにするかの候補の一つ（だが業界標準）でしかないんだが。
UMLを使うからと言って開発のやり方が決まるわけじゃないんだよ。

**仕様書無しさん** · 2012/01/22(日) 13:20:17.97

「UMLで設計してる」ワロタｗ

設計するときにUMLで書くのであって
UMLというやり方で設計するのではない

設計するかどうかは先に決めろ。
設計すると決まってから、その書き方にUMLを使うんだよ。

**仕様書無しさん** · 2012/01/22(日) 14:41:09.90

名言ですな
UML使いたくなった

**仕様書名無しさん** · 2012/01/22(日) 17:22:52.89

つまり、設計書は設計をする為に書く物では無いってことか。
設計は全て頭の中でやって、すべて終わったら、記録として設計書に残すってことでOK？

**仕様書無しさん** · 2012/01/22(日) 22:20:20.52

お客様がUMLで書かれた文書を求めていません。
勝手にUMLを使っても納品物として受け取ってもらえず、金を払ってもらえません。
それどころか、そんな事をしてプロジェクトを故意に遅延させた場合は、
損害賠償を請求されてもおかしくありません。

趣味として習得するなら個人の勝手なので、否定するつもりはありませんが。

**仕様書無しさん** · 2012/01/22(日) 23:45:44.77

>>178
お前は顧客が要求しなかったら
ソースコードも書かないのか？
設計代も要求しないのか？
楽しい馬鹿だなｗ

**仕様書無しさん** · 2012/01/22(日) 23:48:03.88

情報伝達、意識合わ、設計を詰める、作業の分離、とかそんな感じの用途に使うだろ。
使った方が早くなるから使うのに、どうやって損害賠償請求するんだ…

**仕様書無しさん** · 2012/01/22(日) 23:50:37.79

>>178は、全部出来上がってから、余計なUMLを作るという無駄な作業をするタイプの馬鹿。
作業の効率化の為にUMLを使用して、結果成果物として再利用可能なUMLを入れるのが普通の人。

**仕様書無しさん** · 2012/01/23(月) 00:57:57.95

客との契約にないなら、コードを書かないのは常識。
設計は受注したが、コーディングは他社担当のため
一切コードを書く必要がないのは良くあること。

作るなと言われたはずの、UMLを使用した資料作成に、ムダな時間をかけるのは馬鹿のやる事。
費用も時間も限られているのに、なぜムダに使うのか理解できない。
故意にプロジェクトを赤字にしたり、デスマを招くなど、嫌がらせでもしたいのだろうか？
自己満足のためにやるなら個人の勝手だが、業務時間内にはやるな。

**仕様書無しさん** · 2012/01/23(月) 01:00:59.30

たしかに
UMLを使う機会はないわな
技術屋のオナニーとはまさにこのこと
強いて言えばソースからクラス図を生成して納品文書の水増しをするくらいか
いまだに納品物のサイズが、こなした仕事の分量だとみなす風潮は根強い

**仕様書無しさん** · 2012/01/23(月) 01:42:15.84

>>182
根本的な所が間違ってる。

UMLを使う、使わないに関係なく設計図を書くかどうかの判断が先にくる。
設計図を書かないのならUMLがでてこないのは当たり前。
誰も設計図を書かないと判断した場面でUMLを使って図をかけなんて言っちゃいない。

絶対書けと言ってると思ってたのでしょ？　そこがあんたの一つ目の根本的な間違い。

設計図を書くという選択をしたら、次はどんな記法を使って図を書くか。
社内で記法が確立されているなら、それを使って書けばいい。
誰もUMLで絶対にかけなんて言っちゃいない。UML以外を使ってもいいし、
UMLと他の何かを併用してもいい。手段と目的をごっちゃにするな。

絶対UMLで書けと言ってると思ってたのでしょ？　そこがあんたの二つ目の根本的な間違い。

事実として、UMLは世界標準。ソフトウェア業界にいるのなら文字を読むのと同じくらい基礎的な知識。
プロジェクトで使う使わないに関係なく、知っていなければいけないもの。
なぜなら社外情報はUMLで書かれているから、知らなければ読めない。

仕事で使うかどうかでしか判断していない。仕様書、設計書を納品物としてしか見ていない。
読むものであるということを理解していない。そこがあんたの三つ目の根本的な間違い。

**仕様書無しさん** · 2012/01/23(月) 03:59:59.73

IBMで使われてないって、なんか面白いね。Rational Rose って, IBMが販売してるよね。
自社内でも使われて無いツールを年契約数十万出して使う所があるんだろうか。
IBMは大きい会社だからいろんな部署があるんだろうけど。

**仕様書無しさん** · 2012/01/23(月) 06:51:23.88

メインフレーム部門の保守管理部門じゃねぇの？
360や370のアセンブラで書かれたコードをエミュで動かし続けるのが仕事、っていうw

**仕様書名無しさん** · 2012/01/23(月) 09:03:59.50

UMLの設計書が飛び交ってるプロジェクトって、例外なくトラブルプロジェクトな印象なんだが、気のせいか？

**仕様書無しさん** · 2012/01/23(月) 09:37:18.12

釣れますか？

**仕様書無しさん** · 2012/01/23(月) 20:11:35.24

ダメだこりゃ
UMLも結局、強行的な推進論者だらけって事ね
有益な点や優れている点もあるはずなのに、過激な支持者ばかりが目立ち、
それを嫌がって離れていく人、近づきたがらない人も多いんだろう

**仕様書無しさん** · 2012/01/23(月) 21:12:37.62

どこに強行的な推進論者がいるんだ？

現実を言っているだけだろ。

・UMLが業界標準。（違うというのなら他に変わるものをあげてみ）
・UMLは実際に使われてる。（技術書でUMLが使われている）

UMLに変わるものはないんだから
それ以外のものを使うなんて考えられないだろ。
社内専用の図形は業界標準になることなんて無いし。

**仕様書無しさん** · 2012/01/24(火) 07:04:21.12

強行的なアンチの馬鹿がひとり、
過激な反対意見で暴れていて、
誰もが嫌がって離れていく、誰も近づきたがらない人なのだけど、
本人だけは自分が正論を言っているつもりw

**仕様書無しさん** · 2012/01/24(火) 15:56:34.14

UMLも、特定企業の社内規格も、状況に応じて使い分ければそれでいい
自分専用資料なら、その場の思いつきで独自規格を作ってもいい
UMLは無条件で切り捨てられるものではないが、絶対というわけでもない
ただそれだけのこと
くだらねえ

**仕様書無しさん** · 2012/01/24(火) 21:26:27.12

でも読めないと技術者としてはダメだね。

**仕様書無しさん** · 2012/01/24(火) 21:38:37.58

UMLの有用性を、具体的なデータで示して欲しい。
例えばUMLを採用した結果、従来より開発コストが10%削減できたとか、
障害件数が5%減ったとか、個人の主観ではなく客観的な数値データはないのかな？

**仕様書無しさん** · 2012/01/24(火) 22:03:09.32

>>194
UMLと何を比べるんだ？

**仕様書無しさん** · 2012/01/24(火) 22:12:05.30

具体的なデータねぇ。

技術書の何%でUMLが使われていて、
残りの何％でUML以外の図が使われているとか
だせばいいのか？

UML以外の図って何か知らんが。

**仕様書無しさん** · 2012/01/24(火) 23:16:30.16

UMLで認識を共有出来る人に対して、UMLを使わずに情報を伝達した場合の時間のロスを数値化したいの？

**仕様書無しさん** · 2012/01/25(水) 11:29:45.82

関係者全員がUML読めてソフトの動作を理解できるようになったら
バラ色になるんじゃね？

**仕様書無しさん** · 2012/01/25(水) 23:59:03.96

>>198
銀の弾丸は無いって言葉知ってる？ｗ

**仕様書無しさん** · 2012/01/26(木) 00:55:35.08

オブジェクト指向でプログラミングしていれば、前提知識レベルだけどな。
確かに銀の弾丸じゃないけど、武器にはなる。武器は使い方次第。

UMLなんて勉強するほどのものじゃないから、解らないとするとおそらくはオブジェクト指向の考え方ができていないと思う。
一年目の新人だって、クラス図渡したら実装してくれる。

それともなんだ、スケルトン書いてフローチャートとか書いて欲しいのか？
文句言ってるヤツはどういう情報伝達がお望みなんだ？