2ちゃんねる★スマホ版★■掲示板に戻る■全部1-最新50

UMLなんていらない

1 :
2011/08/31(水) 23:03:20.01
2 :
2011/08/31(水) 23:05:36.74
ここは、UML. 未確認言語 (Unidentified Mysterious Language) について
語るスレです。興味がない人は書き込まないようお願いいたします。
3 :
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()
}
4 :
2011/09/01(木) 02:52:17.98
クラス図は意味が無いのだから
どうでもいい。

クラス図以外の話をしようぜ。
5 :
2011/09/01(木) 15:11:48.59
デザパタ本に一切図がなくて(擬似)コードだけで説明されてたらと思うとぞっとするわ。

多分 >>1 はデザパタなんて UML 推進派のでっちあげでそんなもん不要とか言うんだろうが。
6 :
2011/09/01(木) 16:48:40.92
ユースケース図とかは不要だな
7 :
仕様書無しさん
2011/09/01(木) 19:22:22.10
ウムル?
8 :
2011/09/01(木) 21:29:03.11
むしろデザパタは解説にUMLが使われるせいで無駄に難解なんだと思う
日本語でしゃべれ
9 :
2011/09/01(木) 22:27:56.03
>>8
じゃあ、お前がUMLを日本語に変換してくれ。

甲、乙は丙を継承し・・・とかやるんだろ?w
10 :
2011/09/03(土) 08:13:43.54
>>9
なに言ってんだこいつ
11 :
2011/09/03(土) 08:14:40.81
おまえが日本語読めないだけだろ
12 :
2011/09/03(土) 23:38:54.80
UMLで全てを設計するとかキチガイすぎる。

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

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

状態が2つしかないのにステートチャートを
描いたりしてたら、UML意味あるの?
って疑問が出るのは当然。
13 :
仕様書無しさん
2011/09/07(水) 06:31:30.84
自分用のちんまいツールを作ってるだけの趣味グラマな俺の場合、
UMLって学ぶ価値あるかな?
14 :
2011/09/08(木) 18:08:11.33
ない
15 :
2011/09/08(木) 20:46:46.63
>13
UMLっていうのはいろんなモデリングをひっくるめた名称だからね
趣味グラマだったらそのうち5種類くらいしか使わないと思う
16 :
2011/09/09(金) 00:05:23.57
一昔前は業界標準と言われてあちこちでもてはやされてたわけだが、推進してた奴らはみんな逃げたの?
象形文字みたいな記号並べてスカスカの資料大量に作ってたのはなんだったのか…
17 :
2011/09/09(金) 00:25:35.53
かといってモデリングまったくやらないのはよくないと思うけどね
俺が入るところはいきなりコーディングするやつばっかりだ
18 :
2011/09/09(金) 01:39:04.19
>>16
地図記号統合みたいな話だろ。

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

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

19 :
2011/09/09(金) 08:20:53.99
(全くそういう手法を取り入れない前世紀から旧態依然な所も結構あるんだよw)
20 :
2011/09/10(土) 12:45:53.76
DB層以外のモデリングが必要なEJBが死滅した段階でUMLなんてほとんど用済みだろ?
フレームワーク部分以外で複雑なクラス関連をプログラマが理解する必要のあるプロジェクトなんて炎上確実だよ。
21 :
2011/09/10(土) 13:24:28.46
>>20
お前はUMLといったらクラス図しか知らないように見えるな。

クラス図はUMLで一番役立たずのものだよ。
それだけみて判断してるお前ってw
22 :
2011/09/10(土) 17:55:43.57
おまえの語彙ではプログラマ=コーダだから、としか読めない
23 :
2011/09/11(日) 07:18:40.78
UMLを書くと、自動的にコーディングしてくれればいいんだけどな。
24 :
2011/09/11(日) 12:34:37.18
してくれるだろ
25 :
2011/09/11(日) 12:39:02.16
>>24
じゃあ、クラス図以外から
コード生成してくれるものを教えてください。
26 :
2011/09/11(日) 12:40:31.56
なお、クラス図を省いているのは、
クラス図は単なるコードのサブセットに過ぎず、
コードから生成できるから必要ないのです。
27 :
2011/09/11(日) 13:15:34.75
出来ない理由ばかり考えてるからそんな卑屈な性格になっていくんだよ
28 :
2011/09/11(日) 13:19:05.37
話はあなたが質問に答えたあとに聞いてあげます。
29 :
2011/09/11(日) 13:34:19.38
UMLだけでプログラムの全てが記述できるわけ無いじゃん
30 :
2011/09/21(水) 00:55:46.62
UMAやったほうがいいよ
31 :
仕様書無しさん
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でなまじ図にするよりわかりやすいと見るか、わかりにくいと見るか
# 人によって意見は分かれる
32 :
2011/10/07(金) 20:58:40.16
擬人化できるクラスなんて実際はほとんどないけどね
33 :
2011/10/07(金) 23:43:57.63
>>31
女の子classに性別propertyは必要か?
俺は組込だから、オブジェクト指向すら怪しいが
34 :
2011/10/08(土) 00:08:55.27
この手の話題はDB設計でも上がるが、性別とジェンダーは別だとかなんとか。
一応コンストラクタで性別受け取ってないって部分でカバーしてるんだろうが、
それならpropertyという表現が適切かどうかという(ry
35 :
2011/10/08(土) 08:51:51.58
女の子クラスが人間クラスの継承で、人間変数に女の子インスタンスをつっこんでるとき、メンバ変数で見れたほうがソースが見やすいだろうな。
36 :
2011/10/08(土) 09:08:11.91
僕はJava VMになって全てにアクセスしたいです
37 :
2011/10/08(土) 13:01:41.65
うほっ?
38 :
2011/10/08(土) 16:16:04.83
さすがにもう使ってないや。
せいぜい、個人レベルのメモ程度の用途で、UMLっぽいのを書くことがある程度。
顧客に提出しても、たいていは意味不明な図だとしか思ってもらえないため、提出資料としての価値がない。
社内限定で使うにしても、内部資料に時間・コストをかけるわけにはいかず、
結局は簡略化したコードや、日本語の文書で書く事になる。
39 :
2011/10/09(日) 12:17:48.65
UMLみたいな学者が考えた設計書って
理路整然と体系だっているのはいいが
真面目に作ると枚数もかさむし、重要な部分とそうで無い部分が並列に扱われるから
実際業務で扱う作り手、読み手からしたら
机上の空論感が半端ない。
40 :
2011/10/09(日) 12:20:07.92
そしてプログラムもそういう調子で書くわけ?
41 :
2011/10/09(日) 13:48:12.21
>>39
UMLを考えたのは学者ではありません。
実用のために作られたものです。

クソ素人が
42 :
2011/10/09(日) 13:59:38.35
OMGが学識者や、大企業が非効率な自分たちのノウハウ標準にしようと圧力かけられておかしな方向に進んだこと知らないのかね?
43 :
2011/10/09(日) 14:11:39.10
必死でググってdisってるホームページ探したんだね、えらいえらい
44 :
2011/10/09(日) 14:42:11.07
もうあまり見かけないよ。
中身を見る事なんて無いのに、ソースから自動的にクラス図の生成をやってる所がある程度だ。
いまだに、納品物の量がこなした仕事の量だと思い込んでいる取引先もあるので、
納品物水増し程度には役立つ。
45 :
2011/10/09(日) 15:18:21.36
そりゃ、設計書を書かない所では
見かけないだろうなw

どんな底辺会社w
46 :
2011/10/09(日) 18:45:16.75
みんな必死こいてUML書いてたのって、かれこれ7〜10年ぐらい前だろ?
完全にIT業界の黒歴史だと思うんだけどね。
47 :
2011/10/09(日) 19:35:53.35
うん。使いどころがわかって、どう使えばいいかもわかってきたから、もう誰も騒がなくなった。
そして、わからない奴は永遠に取り残されたわけだw マシン語があれば無敵とか、
構造化なんて一時的なブームとか信じてた人たちみたいに。
48 :
2011/10/09(日) 20:18:26.45
作っても、納品物として要求されないんだよ。
設計書の一部として添付しても、レビュー時に「なんじゃこりゃ?」と言われ
結局削除するはめになる。
PGやらSEやらはUMLを理解していても、取引先の担当者が理解していない以上は、
まさに「なんじゃこりゃ?」な図でしかないんだ。
49 :
2011/10/09(日) 20:20:24.95
じゃあソースコードも読めないだろうから、ソースコードも納品しなけりゃいいんじゃね?
50 :
2011/10/09(日) 20:26:37.40
>>48
お前は、UMLは自分たちが使うものって
考えが全くないんだなw
51 :
2011/10/09(日) 23:12:06.38
納品対象外の内部資料なら、
共通的な書式である必要がないからな。
伝わりづらいとこだけあれば十分だし、それ以外は蛇足でしかない。
52 :
2011/10/09(日) 23:49:38.89
>>51
おいおい、オレオレフレームワークが
なぜダメか知ってるだろ?

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

独自の書式にメリットはない。
何のために独自にするのさ。
あえて、違う書式を使う理由がないよ。
53 :
2011/10/09(日) 23:54:04.80
んなもん簡単に他に乗り換えれないようにするために決まってんだろ馬鹿
54 :
2011/10/10(月) 00:22:09.14
乗り換えられないようにする効果はない。
(人間辞めるときはすぐ辞めるから)

逆に教育の必要性というデメリットは
回避不可能。
55 :
2011/10/10(月) 00:46:45.28
新卒文化の日本では
新たに雇う人=新入社員
新入社員でUMLが分かってるヤツなんて
居ないから結局教育コストは減らない。
大手の顧客情シスはコボラー集団だしw

56 :
2011/10/10(月) 00:55:06.07
>>55
それは大手だけ。
57 :
2011/10/10(月) 01:06:15.60
大手生保で2000人規模のコボラー集団かかえてるとこあるよw

58 :
2011/10/10(月) 01:15:50.67
大手で将来にわたってクビにならないという前提ならいいんだが、
今の世の中その考えは楽観的すぎだし、
会社に将来を殺されないように気をつけてね。
59 :
2011/10/10(月) 13:49:40.64
ごく最近設立された新興企業でもない限り、
大手も中堅も、大抵は社内書式として、図の書き方等を独自に決めてるよ。
誰かがトップダウン的に決めたケースもあるし、長年のノウハウ蓄積の結果、
ボトムアップ的に決まったケースもある。
中小企業の場合だと、大手の実績のある手法を拝借する事もある。

そうやってきた企業にとっては、UMLなんてのは後から出てきたものでしかない。
自社に好都合なものが既にあるのに、わざわざUMLを新規に採用する必要がない。
使うのは、取引先から求められた場合のみ。
60 :
2011/10/10(月) 14:59:24.62
欧米のような消費型思想と日本の蓄積型思想の違いだな。
日本企業は新しいものは取り入れても、今を捨てて新しいものに完全に置き換えることは嫌うから。
61 :
2011/10/10(月) 15:02:20.25
未来永劫フローチャートとCOBOL使い続けるのが「蓄積型思考」なのか?
B版の用紙に縦書きするのが「蓄積型思考」なのか?

ただのバカだろ、それ単に。
62 :
2011/10/10(月) 16:39:44.32
実際そんな理屈言っても通用しないんだよ。
予算が足りないからできませんなんてのは言い訳にならないから、今あるものをつぎはぎで使うことになる。
年金とか銀行とかのシステムがいい例。
63 :
2011/10/10(月) 16:42:47.06
破綻に向けて好きに突っ走ってくれ

他人が吹っ飛ぶだけなら綺麗な花火だね、で済むからな
64 :
2011/10/10(月) 18:20:36.00
予算が足りないという
言い訳はいらないからw
65 :
2011/10/10(月) 19:18:19.87
COBOLは2050年でも現役だろう。
ヘタすると、22世紀まで生き残ってる可能性も否定できない。

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

そりゃあ、業界全体のシェアから見たら、全盛期の10%も生き残ってなくて、それでもなお
>>65 みたいな狂信者がいるんだから、最後の 1% はそれぐらい長生きするだろうねぇw
67 :
2011/10/10(月) 20:11:17.88
開発のシェア的にはそうだが、
現役のソースコード量としては、10%どころじゃない。
68 :
2011/10/11(火) 02:43:15.18
コボラーはコボラーだけでやっててくれればいいよ
どれだけコボルが稼働していようと、眼中にないものは眼中にない
69 :
2011/10/12(水) 22:31:41.45
もしCOBOLを完全排除する場合、他言語での作り直し、移行に何十年かかることやら。

移行が完全完了する頃には、最も古いコードは20年や30年以上前のもので、
旧式言語を排除したつもりなのに、新規開発に使用した言語も既に
旧式化している事だろう。
70 :
2011/10/13(木) 06:24:51.06
元のCOBOLの古さにかわりはないだろうし、
新しいCOBOLがあることももしかして知らない?
71 :
2011/10/13(木) 20:23:32.38
オブジェクト指向を取り入れただの、MSの.Netに対応しただの、
新世代のCOBOLが作られても、ついていけるコボラーがどれだけいるのか?
72 :
2011/10/14(金) 06:56:29.86
結局、技術の根が古い新しい関係なく、
ついていける奴と、ついてこれない奴、がいるだけなんだよなw
73 :
2011/10/14(金) 19:42:28.13
>>71
どうせ30年後には、新世代COBOLではなくなってる。
最新のものが登場したからと言って採用し続けると、
多数の世代の言語が混在し、保守困難になる。
古代の言語に統一されている方がまだマシだ。
74 :
2011/10/14(金) 20:46:43.19
古代の言語の古代の仕様だったら保守困難にならない、なんて保証がどこにあるんだ?
古代のハードウェア、古代のOSを使い続ける自由は、ネットワークセキュリティが問題に
なる以前のプラットフォームにしか存在しないぞ?

あるとすれば、サイバーノーガード戦法で世界中のさらし者になる自由ぐらいだ。
75 :
2011/10/14(金) 22:16:34.68
金融機関「外部接続は基本的に専用線。しかたのないものは、イントラと物理的にも論理的にもネットワーク分断しております」
76 :
2011/10/15(土) 00:09:58.82
製造業でも、外部とは物理的にネットワークが繋がってないのがよくある。
内部犯行や、従業員を装って内部に侵入するケースがない限りは、
攻撃を受ける事は考えられない。
だから10年以上前のソフトウェアを、セキュリティパッチも当てずに
何の問題もなく使い続けていたりする。
77 :
仕様書無しさん
2011/10/15(土) 21:57:56.31
詳細設計書の一部として、全クラスの全パブリックメソッドに
シーケンス図つける羽目になったことはあるよ。泣きたくなった。

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

とりあえずlambdaかevalできればもうなんでもいいよ、漏れは。
78 :
2011/10/15(土) 22:53:07.54
COBOLはどうでもいいから
フローチャートの再来であるUMLをなんとか滅ぼそう
79 :
2011/10/16(日) 11:00:33.41
フローチャートの再来みたいな糞低レベルのUMLなら滅ぼされてしかるべきだが
80 :
2011/10/16(日) 11:45:38.65
初期のシステムでやりたいこと整理のためにユースケース図は便利やね。
もちろんなんとなく図で把握できればいいし、
下手すりゃ客に見せることもあるので正式なユースケース技法じゃ書かないけど。
クラス図?なにそれ。美味しいの?
81 :
2011/10/16(日) 12:21:51.31
まあmainに全ての処理を書いちゃう奴にはUMLなんていらねえよなw
82 :
2011/10/16(日) 15:01:20.65
新入社員になんかやらせる時はシーケンス図を描かせてみるな。細かい記法はいいからと言って。
すると、たいてい1オブジェクトに処理が集中するんで、そこで責務の話をすると通じやすい。
83 :
2011/10/16(日) 19:06:05.30
フローチャートの方がまだマシだわ
84 :
2011/10/16(日) 19:53:28.05
フローチャートとかマジで言ってんの?
頭の医者にかかったほうが…
85 :
2011/10/16(日) 22:00:19.56
UMLの資格の受験料高すぎだろ・・・
86 :
2011/10/16(日) 22:30:05.16
>>85
受験料をぼったくるための資格なんだから当然の事。
実はあれって有用性ゼロで、ただのぼったくりじゃないのか?と思う人が増えたら、
UMLに替わるものを作り、今度はそれの資格の受験料でぼったくるさ。
87 :
2011/10/16(日) 23:27:03.44
有用性のある実用的な資格なんてほとんどないだろ?
合格基準と、実用性が乖離している資格が大杉。
88 :
2011/10/28(金) 22:51:36.97
今後はUMLが常識になり、知らない奴は淘汰されるのではないかと思い、
自腹で書籍を購入して学習した俺はバカでしたよ。
あれから何年たっても、どこの案件でも、使う機会は一切なし。
UMLの使用を提案しても、相手にされる事はない。
自社で受注した案件でも、他社の下請け案件でも、UMLと言う言葉すら登場しない。
他の事に金と時間を使うべきだった。
89 :
2011/10/28(金) 23:15:41.45
UMLは正直、自分用になってるな。それはそれで役には立ってるが。
普及しなかった原因のひとつにはオープンソースは普及しても、オープンドキュメントが広まらなかったせいだと考えてる。
Unifiedの部分が「分かる人は分かる」であっては、どうしようもない。

ちなみに俺は初めてUMLを知った時、「ついにコーディングレスの時代が来たか…」と思った。当然幻想だった。
90 :
2011/10/30(日) 09:03:39.01
標準化してるくせに見やすくないよな
もっとパッと見て理解できるようになったら普及するんじゃね
91 :
2011/10/30(日) 14:48:37.63
個人レベルの資料やメモとして、UMLもどきを書く事があるくらいだ。
自分さえわかればいいので、完全に自己流の図だ。
92 :
2011/10/30(日) 23:25:34.25
学術者が寄り集まってああだこうだ相談して作った記法や言語は得てしてわかりづらい。
そうじゃなければ個人がネタで作ったC言語およびその派生言語がここまで流行ることはなかっただろう。
93 :
2011/10/30(日) 23:35:51.14
C言語を作ったデニス・リッチーは学術者だよw
94 :
2011/10/31(月) 11:17:51.04
Java作った連中もドクター取ってるか、それと同じレベルとみなされてるよな。

>>92 はグローバル変数だけしかなくて、関数定義すらもない言語でも、一生使ってればいいよ。
95 :
2011/10/31(月) 16:53:06.90
意味を取り違えるなよ。
企画段階から自称頭のいいヤツら大勢集まって、考えたものはダメってこと。
一人の天才が自己完結させた物の方が、シンプルで分かりやすい。
だた天才は意外とポカやらかすから最小限の欠点のみ凡人が外堀埋めて完成させる必要があるけどね。
96 :
2011/10/31(月) 18:30:45.25
ほう、それでそれで

Pascalについてはどう説明してくれるのか楽しみだ
97 :
2011/10/31(月) 22:11:28.14
とっくに死滅したとの認識。
派生言語のデルファイが一時期流行ったのもGUIが手軽にできるVB以外の唯一の選択子だったから。
98 :
2011/11/01(火) 00:58:06.49
> 学術者が寄り集まってああだこうだ相談して作った記法や言語は得てしてわかりづらい。

この主張に照らしてどうか聞いてるんだが。
99 :
2011/11/04(金) 20:04:11.54
DelphiはVBライクにGUIを作成でき、VBより高速動作するのが売りだった。
でもObject Pascalなんて知ってる人はごく少数派。
結局、拡張や保守に難があり、消えていった。
100 :
2011/11/18(金) 21:29:43.59
コードが全部仕上がってから、ツールを使ってクラス図を自動生成する程度。
中身は見ない。
そうやって納品物を水増しすれば、何も知らない人の目には
多量の仕事をこなしたかのように見せる事ができる。

UML登場以前にも、ツールで関数一覧や呼び出し階層一覧を自動生成したりして、
形だけの水増し用資料を作っていた。
それと同じ。
101 :
2011/11/20(日) 06:38:24.00
>>100
クラス図は設計であるが、
そのクラス図はソースコードから作れる。
すなわちソースコードは設計そのものということになる。

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

そしてソースコードから生成できるのはクラス図しか無い。
クラス図が役立たずなだけで、それ以外のドキュメントは必要なのだ。
102 :
2011/11/20(日) 10:02:57.23
重要なビジネスロジックの仕様書くUMLって存在しないよね?
なんかUMLって要らない部分の仕様書ってイメージ。
103 :
2011/11/20(日) 10:14:40.26
いらない部分って?
104 :
2011/11/21(月) 07:10:38.26
「重要なビジネスロジック」って何のこと言ってるの?
抽象化で消える、ソースコードでしか表現できないような細部のことを指してるなら、
そりゃ抽象化の道具である図にはならんわな。
105 :
2011/11/21(月) 07:11:09.87
>>103 プログラムには設計はいらなくて、コーディングさえすればモノは作れると思ってるとかw
106 :
2011/11/21(月) 12:52:11.04
そこで形式仕様(ry
107 :
2011/11/21(月) 14:33:31.80
ジャクソン父子はすごいよな
108 :
仕様書無しさん
2011/12/25(日) 23:18:27.69
最終的に納品資料を検収するお客サマは、システムなんて一切知りませんよ。
プログラミングなんて言っても一切言葉が通用しない。
UMLなんて書いても、意味のわからない謎の図形だとしか思われない。
そんな人達から、検収を受けないと先に進めないんですよ。
109 :
2011/12/26(月) 08:14:17.72
システムの中身がわからないのに「検収」と称して、何をやるんだ?

書類を紙飛行機にして、飛んだら合格?
110 :
2011/12/26(月) 20:27:45.02
今時UMLなんて過去の遺物を納品物件として持って行ったら、
システム屋の自己満資料持って来て馬鹿じゃないの?って言われて、速攻で叩き返されるのがオチだろ?

111 :
2011/12/26(月) 21:01:23.66
>>109
提出した文書について、隅から済まで以下の点を徹底チェックする。文書の内容は不問。
・誤字脱字
・フォントおよびフォントサイズの統一
・図や罫線の位置ズレ
・文体の統一チェック(ですます調、である調など)
・パンチ穴のズレ、破れチェック
・英単語が使われている場合は辞書を引いてスペルミスのチェック
・その他文章の不統一チェック(アラビア数字と漢数字の混在、全角カナと半角カナの混在、漢字の送り仮名の統一など)
112 :
2011/12/27(火) 00:10:08.83
>>109
お前、何か物を買ったときに
検品したこと無いの?
113 :
2011/12/27(火) 00:10:54.53
>>110
お前の客の話?
その客にお前は合わせてるの?w
114 :
2011/12/27(火) 09:50:22.86
>>112 10kgに耐える強度が必要なものの検品なら、9kg掛けてみるのが検品。
それの色艶を見て評価するのはバカの所業。

なのにプログラムでは、そのバカの所業を「検品」と称してるんだろ、バカなの死ぬの死んじまえ。
っていう話だということも分からない奴は、全員強度不足の飛行機に乗って死ねばいいよ。
115 :
2011/12/27(火) 10:01:25.75
>>114が正しいな。
実際の世の中で通用するかは別だけど…
めんどくせぇ。
116 :
2011/12/27(火) 12:20:01.57
>>112
もう客がUML学習にコストかけてシステム屋にレベル合わせてくれる時代じゃないんだよ。
117 :
2011/12/27(火) 13:22:46.08
客は日本語、それも自分がわかる用語で書けとしか言わんしな。
118 :
仕様書無しさん
2011/12/27(火) 13:46:14.62
UMLなんかで設計してるから他人のメールアドレスが
付与されちゃうような事態になるんじゃないですかね
119 :
2011/12/27(火) 14:37:06.93
ドキュモのシステムってそうなの???
kwsk
120 :
2011/12/27(火) 16:02:32.36
所詮は「言語」なんで、日本語でもゴミのような文章もあれば、きちんとした文章もあるのと同じだと思うが。
121 :
2011/12/27(火) 19:55:23.06
>>118
確かに、「間違っても他人のメールアドレスが付加されないように」とか、UMLで表現出来るとは思えない。
あり得ないはずの事態に対して念押しのようなロジックって、UMLだと確実に漏れそう。
122 :
2011/12/27(火) 20:56:56.98
>>111
どうせ文書しか読んでくれないから、文章力のある人が重宝される。
大学や大学院で国文学を専攻し、優れた文章に触れる機会が多かった人を歓迎だ。

昔、NECがPCの説明書の文章を、作家に書いてもらった事がある。
技術屋が書くと理解困難になるので、畑違いではあるが、文章を書いてでメシ食ってるプロに委託したってこと。
システムの仕様書も、そういうやり方でいいのでは?と思い始めた。
123 :
2011/12/27(火) 21:30:02.31
テクニカルライタなんていらない、という発想か
斬新だな
124 :
2011/12/28(水) 09:25:43.80
設計前のPTにしては文字が多すぎだし、
書くのが面倒だからCBには向かない。
大昔のSAのほうがまし。

2文字表現してみました(´∀`)。
125 :
2011/12/28(水) 21:58:11.86
そういうもんなのかなあ
文学的表現なんて不要なんだから淡々と論理的に説明すればいいだけだと思うんだが
理解不能になったのはその技術屋が説明へたくそだったってだけで
126 :
2011/12/29(木) 00:08:25.63
淡々と論理的に説明しても、技術屋の書く文章なんてお客サマは一切理解しませんよ。
文章力のある人に書いてもらい、内容はさっぱりわからないが
説得力のある結論が書かれているので、検収印を押すという状況に持ち込むんですよ。

やる事は、銀行や証券会社のリテール営業と同じ。
高度な金融商品は、専門的な学習が必要で、一般人にはまず理解できない。
ところが彼らは口が上手いので、内容をわかっていない客にわかった振りをさせて納得させ、
契約までこぎつけてしまう。
127 :
2011/12/29(木) 00:31:40.50
日本も国際標準のシステム構築費先払い制になればいいのに。
売上だけ進行基準にしても、客に変な言いがかりつけられて、検収人質に契約外のタダ働きされられるから意味ねーよ。
システム範囲やドキュメントレベルが顧客の気分でどんどん水増しされるwww
128 :
2011/12/29(木) 15:48:17.83
事前に範囲を決めておきますよ。
水増しの話が出てきたら、すぐに営業が飛んで行って追加費用の話になりますよ。
揉めに揉めたあげく、開発側が妥協させられるはめになりますた。
129 :
2011/12/29(木) 20:12:41.13
システム屋が水増しだと訴えても、顧客側が契約範囲を拡大解釈するから、お互いの言い分は平行線で交渉にならん。
プロジェクト開始前の見積額が数倍だった時に書いてあった提案書の内容が、いつのまにか全て約束したことにされてたり。
130 :
2012/01/04(水) 14:54:11.76
日本だと先払いは困難だろ
後からどんどん追加機能や修正を求められても、
契約外だと言って全て突っぱねても良いなら可能だけど
131 :
2012/01/04(水) 19:43:12.36
つっぱねをやると、そこからは二度と仕事は来ないからな。
IBMはそれでどんどん評判悪くなって日本での仕事が減ったわけだし。
132 :
2012/01/06(金) 02:37:59.03
>>125
書くこと書いてりゃイイんだろ、とばかり冗長な表現になることが多い。
長々と書いている間に混乱してしまう事もある。
内容そのものは間違いではないので一層タチ悪い。

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

そりゃまあ完了しないと出ないんだし、エラーじゃなく正常な出力のことを言ってるんだし
出力結果をファイルにしてから印刷用にフォーマット整えて印刷指示までかけるように
処理してるんだけどさ・・・
133 :
2012/01/09(月) 22:02:21.81
習得しても使う機会がない
取引先が国内企業だろうと、外資だろうと、公官庁だろうと、
UMLを使用した文書の作成を求められる事がない。
内輪だけで使う資料に、UMLを採用する必要性もない。
せいぜい、自分だけしか見ない、個人用メモに使う程度。
134 :
2012/01/15(日) 17:23:55.53
20年後や30年後に、大昔のシステムを全面更新するため
古い設計書を見たら、意味不明な図が多数ある。
若手のプログラマやSEは、それが何なのかもわからず頭を抱える。
そこへ頭の薄くなった大ベテランが現れ、とうの昔に廃れたUMLだと語り、
懐かしそうにそれを眺め、「俺が若い頃はよぉ・・・」と誰も頼んでいないのに昔話を始める。

そんな光景を思い浮かべた。
135 :
2012/01/15(日) 18:06:04.07
古くなるものとそうでないものの見極めがつかない奴ってよくいるよねー
136 :
2012/01/15(日) 21:43:26.42
エジプトの壁画に書かれてる落書きみたいな象形文字も、実は高度な文明遺産なのかもね。
137 :
2012/01/15(日) 22:17:03.26
少なくとも、今もこれからも
UMLに変わる図が存在しないことは事実
138 :
2012/01/16(月) 22:43:39.36
大手は70年代から図の書式統一を試み、実際に社内書式として確立させてきた。
その下請けを担った中堅、中小も、大手の手法をそのまま真似たり、
自社流にアレンジした上で使ってきた。
もちろん、技術の変化に合わせた改良は、常に続けてきた。

後になってからUMLなんてものが登場してきても、
顧客から指定がない限りは採用はできません。
ある年代を境に、それまで統一してきたはずの図の書式がガラリと変わるのは困ります。
139 :
2012/01/17(火) 01:42:07.52
そしてあるとき外資系と協力することになった。
当然外資系はUMLで統一だw
140 :
2012/01/17(火) 20:57:00.82
HPとIBMの仕事をしたことがあるけれど、UMLと言う言葉が出た事もなかった。
外資も日本企業と同様、独自書式を使ってた。
その独自書式の、社内検定まで作ってた。
IT産業黎明期からやってる企業なので、日本企業以上に独自ノウハウの蓄積が大きいんだろ。
10年後に残ってるかどうかもわからない新興の規格より、
30年以上使ってる上、今後30年も使う予定の、独自規格の方がよほど安心できる。
141 :
2012/01/17(火) 22:07:00.26
自分たちだけで最後まで全部やり切れるなら
独自書式のほうが使い勝手がいいに決まってる。
142 :
2012/01/17(火) 23:31:11.54
だが、悔しいことに
書籍までは、社内独自書式が使えないんだ。

だからいつまで立っても理解出来ない。
くそ。底辺なのか
143 :
2012/01/18(水) 07:29:46.39
社内独自規格で世間から取り残されて何十年。
ただの死亡フラグだよそれwwwwww
144 :
2012/01/18(水) 19:23:02.00
社内は社内で必要ならやればいい。
だけどUMLは世界標準なため、
書籍なんか見てもUMLで書いてある。

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

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

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

もしくは、社内でしか生きられない人になるのも良い。
おすすめはしないし、俺にはありえない選択だが、
世の中にはそういう奴もいるだろw
145 :
2012/01/18(水) 19:29:47.95
帳票系しかやったことないのか?
146 :
2012/01/18(水) 19:47:43.25
新しい規格、開発標準、開発言語、ライブラリが、毎年のように登場する。
学ばないと生き残れないと思い、必死になって習得し続けたものの、
ふと気づいてみると、ほとんどが10年もすれば廃れている。
世界標準だの何だの言っても、気づいた時には誰も使っていない。
過去の遺物と化した世界標準が、当時を知る人しか理解できない迷惑物となっていく。
内輪でしか通じない、独自規格ばかりが残り、現場での試行錯誤の末に、より一層進化・洗練され続けている。

そんな事を、何十年も前から繰り返してきた。
相変わらず新しい規格が登場し、世界標準を標榜するが、もう手は出さない。
すぐに過去の遺物になるような資料を、これ以上増やさない。
147 :
2012/01/18(水) 20:02:42.58
>>146
もしかして社内専用の物が
標準になると思ってるの?

それは無いぞw

だからUMLしか選択肢はないんだよね。
148 :
2012/01/18(水) 20:05:14.15
>>147

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

UMLは普通に書籍などで使われてる。
今使う必要があるのだから
学ぶしか無いのだよ。
149 :
2012/01/18(水) 20:20:33.00
2〜3年もすれば、破棄して新規に作り直すようなシステムばかりじゃないんだよ。
10年や20年以上に渡って運用し続けるシステムで、
ごく短期間で移り変わり続ける、標準とやらに従うのは無意味。
書かれた時代によって標準が異なるため、まるで統一性のない資料よりは、
社内でしか通用しない規格だが、全体統一が取れている方がよほど見やすい。
150 :
2012/01/18(水) 20:30:16.86
お金を払うのはお客様です
お客様が採用しろと言えば、独自規格でも喜んで採用します
お客様が採用するなと言えば、世界標準であろうと何であろうと絶対に採用しません
ただそれだけです
私たちは、お客様が支払うお金から給料を貰い、生計を立てているサラリーマンです
それを忘れずに
151 :
2012/01/18(水) 20:45:00.25
自前の技術もなければ、他所に通用する技術もない。
そういうどんづまり状態に陥るパターンの見事な実例ばかり。
152 :
2012/01/18(水) 20:56:30.60
だから、社内の技術は必要なら使えばいいじゃない。

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

会社独自の技術は会社やめればゴミにしかならないけど
世界の標準技術はゴミにはならない。
153 :
2012/01/18(水) 22:10:00.06
なぜそれを使う必要かを考えないからお前らはだめなんだよ
154 :
2012/01/18(水) 22:22:03.03
なぜそれを使う必要があるかを考えた。

書籍などで使われてるから
勉強するにしてもUMLは必要。
155 :
2012/01/19(木) 00:22:50.66
共通言語だからな。
方言だったり、別の言語でもいい。
156 :
2012/01/19(木) 00:53:53.50
UMLが世界の標準だと言い張るのは自由だけど、どこの企業もそれを求めてこない。
日本企業も、外資の日本法人も、外国企業も。

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

例外的にUMLが多用される書籍は、UMLそのものの解説書。
UMLのためのUMLでしかない。
157 :
2012/01/19(木) 02:45:56.33
>>156
言い張るも何もUML以外を使う理由がないから
普通にUMLで書かれている。

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

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

そのことに気づいてないとしたら、よっぽど勉強をしない人か
UMLがあまりにも素晴らしくて意識せずに読めるかのどちらかだ。
158 :
2012/01/19(木) 22:34:12.85
UMLのためのUMLって何かわかる気がする
基礎的なUMLの知識は、より一層UMLを理解するための知識で、
それ自体が更に、より高度にUMLを理解するための知識でしかないって感じ
UMLの目的はUMLであり、UMLの手段もUMLってところか
閉じた世界での自己完結
159 :
2012/01/19(木) 22:37:13.81
閉じた世界で生きてるから
今の技術書に書かれているのがUMLだと
いうことにも気づかない。
160 :
2012/01/20(金) 08:57:00.39
そもそもUMLは、オブジェクト指向台頭期のEJBなんかの過度なオブジェクト指向設計に対応するために作られたんじゃない?
現在のようにフレームワーク中心の形に落ち着けば、アプリ屋側が利用するUMLなんてごく一部に限られるだろ?
161 :
2012/01/20(金) 11:32:54.09
フレームワークを理解しないで使うだけの人ならそうだね。
そういうのを、使えていると言っていいのかどうかは知らないが。
162 :
2012/01/20(金) 19:55:08.56
UMLを多用する世界しか知らない人も多いんだろうな
そのような書籍しか見ないから、あたかもUMLが常識であるかのように錯覚してしまう

野球の事しか頭にない人達が、誰でも野球に興味を持つのが当たり前で、
野球を好まない人はおかしいと言うのと、同じようなものかな
163 :
2012/01/20(金) 20:37:45.67
これからは知らないでは済まないだろうと思い、
UMLの入門書を買ってみたのは6年も前のこと。
今のところ活用する機会は一切無く、今後も無さそうだ。
習得必須の世界標準だと煽り、書籍、セミナー受講料、資格試験料をぼったくる商売だったんだろう。
俺は見事に騙されて本を買っちゃったって事。
次は同じ手には引っかからないよう注意しようと思う。
164 :
2012/01/20(金) 21:39:22.97
> 今のところ活用する機会は一切無く、今後も無さそうだ。

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

普通に技術書買えば、ほとんど採用されてるし。
165 :
2012/01/20(金) 21:56:50.05
みんな馬鹿だなぁ。
166 :
2012/01/20(金) 23:21:20.84
流行るとか、これからの業界標準とか言われながら一向に普及しない規格作ったりするやつらってなんなの?
ASP、EJB、SOA、RFID、クラウドもほとんどの場合はハードを持たないホスティングに過ぎないし…
167 :
2012/01/20(金) 23:55:21.66
知ってて損はないと思うが
168 :
2012/01/21(土) 05:01:39.13
メインフレーム一筋の人は「いまどきメインフレーム以外の仕事なんてほとんどない」と言う
「技術書もほとんどはメインフレームだ」とも言う
そういう人にとっては、メインフレーム以外のものは、
視界に入っても全く意識する事もないんだよ
UMLを擁護する人も同じようなものでしょ
世界が狭すぎというか、自分の世界が狭い事の認識ができていない
169 :
2012/01/21(土) 05:55:09.35
むしろUMLを腐す人にあてはまるだろその理屈はw
170 :
2012/01/21(土) 07:08:51.21
つかさ、本読まないのかな?

UMLはもう普通に使われてるよ。
171 :
2012/01/22(日) 09:54:06.66
国内の一部の連中は、基本的に全く情報収集をしないよ。
自分が使っている計算機環境についてすら、全く無知ということすらある。
テンプレをコピーしていじるのが仕事、っていう。
172 :
2012/01/22(日) 12:44:55.23
オブジェクト指向でやろうとするとデザインパターンに自由度があり過ぎて、メインフレームみたく暗黙の定石が無いから、毎回UMLで設計してるってことなんだろうが、それって効率悪く無いか?
173 :
2012/01/22(日) 13:01:29.71
定石があるものなら定石を使えばいいだけ。
というか、そもそも定石がどんなものかを明確に記述する目的の「言語」なんだが。

それとも172はどんな複雑なものでもかっちり1000行でまとまってる魔法の定石集でも持ってるのか?
174 :
2012/01/22(日) 13:05:39.82
>>172
それがお前のやり方?
お前のところは効率の悪いやり方してるんだな。

UMLは図を書く時にどれにするかの候補の一つ(だが業界標準)でしかないんだが。
UMLを使うからと言って開発のやり方が決まるわけじゃないんだよ。
175 :
2012/01/22(日) 13:20:17.97
「UMLで設計してる」ワロタw

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

設計するかどうかは先に決めろ。
設計すると決まってから、その書き方にUMLを使うんだよ。
176 :
2012/01/22(日) 14:41:09.90
名言ですな
UML使いたくなった
177 :
2012/01/22(日) 17:22:52.89
つまり、設計書は設計をする為に書く物では無いってことか。
設計は全て頭の中でやって、すべて終わったら、記録として設計書に残すってことでOK?
178 :
2012/01/22(日) 22:20:20.52
お客様がUMLで書かれた文書を求めていません。
勝手にUMLを使っても納品物として受け取ってもらえず、金を払ってもらえません。
それどころか、そんな事をしてプロジェクトを故意に遅延させた場合は、
損害賠償を請求されてもおかしくありません。

趣味として習得するなら個人の勝手なので、否定するつもりはありませんが。
179 :
2012/01/22(日) 23:45:44.77
>>178
お前は顧客が要求しなかったら
ソースコードも書かないのか?
設計代も要求しないのか?
楽しい馬鹿だなw
180 :
2012/01/22(日) 23:48:03.88
情報伝達、意識合わ、設計を詰める、作業の分離、とかそんな感じの用途に使うだろ。
使った方が早くなるから使うのに、どうやって損害賠償請求するんだ…
181 :
2012/01/22(日) 23:50:37.79
>>178は、全部出来上がってから、余計なUMLを作るという無駄な作業をするタイプの馬鹿。
作業の効率化の為にUMLを使用して、結果成果物として再利用可能なUMLを入れるのが普通の人。
182 :
2012/01/23(月) 00:57:57.95
客との契約にないなら、コードを書かないのは常識。
設計は受注したが、コーディングは他社担当のため
一切コードを書く必要がないのは良くあること。

作るなと言われたはずの、UMLを使用した資料作成に、ムダな時間をかけるのは馬鹿のやる事。
費用も時間も限られているのに、なぜムダに使うのか理解できない。
故意にプロジェクトを赤字にしたり、デスマを招くなど、嫌がらせでもしたいのだろうか?
自己満足のためにやるなら個人の勝手だが、業務時間内にはやるな。
183 :
2012/01/23(月) 01:00:59.30
たしかに
UMLを使う機会はないわな
技術屋のオナニーとはまさにこのこと
強いて言えばソースからクラス図を生成して納品文書の水増しをするくらいか
いまだに納品物のサイズが、こなした仕事の分量だとみなす風潮は根強い
184 :
2012/01/23(月) 01:42:15.84
>>182
根本的な所が間違ってる。

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

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

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

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

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

仕事で使うかどうかでしか判断していない。仕様書、設計書を納品物としてしか見ていない。
読むものであるということを理解していない。そこがあんたの三つ目の根本的な間違い。
185 :
2012/01/23(月) 03:59:59.73
IBMで使われてないって、なんか面白いね。Rational Rose って, IBMが販売してるよね。
自社内でも使われて無いツールを年契約数十万出して使う所があるんだろうか。
IBMは大きい会社だからいろんな部署があるんだろうけど。
186 :
2012/01/23(月) 06:51:23.88
メインフレーム部門の保守管理部門じゃねぇの?
360や370のアセンブラで書かれたコードをエミュで動かし続けるのが仕事、っていうw
187 :
2012/01/23(月) 09:03:59.50
UMLの設計書が飛び交ってるプロジェクトって、例外なくトラブルプロジェクトな印象なんだが、気のせいか?
188 :
2012/01/23(月) 09:37:18.12
釣れますか?
189 :
2012/01/23(月) 20:11:35.24
ダメだこりゃ
UMLも結局、強行的な推進論者だらけって事ね
有益な点や優れている点もあるはずなのに、過激な支持者ばかりが目立ち、
それを嫌がって離れていく人、近づきたがらない人も多いんだろう
190 :
2012/01/23(月) 21:12:37.62
どこに強行的な推進論者がいるんだ?

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

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

UMLに変わるものはないんだから
それ以外のものを使うなんて考えられないだろ。
社内専用の図形は業界標準になることなんて無いし。
191 :
2012/01/24(火) 07:04:21.12
強行的なアンチの馬鹿がひとり、
過激な反対意見で暴れていて、
誰もが嫌がって離れていく、誰も近づきたがらない人なのだけど、
本人だけは自分が正論を言っているつもりw
192 :
2012/01/24(火) 15:56:34.14
UMLも、特定企業の社内規格も、状況に応じて使い分ければそれでいい
自分専用資料なら、その場の思いつきで独自規格を作ってもいい
UMLは無条件で切り捨てられるものではないが、絶対というわけでもない
ただそれだけのこと
くだらねえ
193 :
2012/01/24(火) 21:26:27.12
でも読めないと技術者としてはダメだね。
194 :
2012/01/24(火) 21:38:37.58
UMLの有用性を、具体的なデータで示して欲しい。
例えばUMLを採用した結果、従来より開発コストが10%削減できたとか、
障害件数が5%減ったとか、個人の主観ではなく客観的な数値データはないのかな?
195 :
2012/01/24(火) 22:03:09.32
>>194
UMLと何を比べるんだ?
196 :
2012/01/24(火) 22:12:05.30
具体的なデータねぇ。

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

UML以外の図って何か知らんが。
197 :
2012/01/24(火) 23:16:30.16
UMLで認識を共有出来る人に対して、UMLを使わずに情報を伝達した場合の時間のロスを数値化したいの?
198 :
2012/01/25(水) 11:29:45.82
関係者全員がUML読めてソフトの動作を理解できるようになったら
バラ色になるんじゃね?
199 :
2012/01/25(水) 23:59:03.96
>>198
銀の弾丸は無いって言葉知ってる?w
200 :
2012/01/26(木) 00:55:35.08
オブジェクト指向でプログラミングしていれば、前提知識レベルだけどな。
確かに銀の弾丸じゃないけど、武器にはなる。武器は使い方次第。

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

それともなんだ、スケルトン書いてフローチャートとか書いて欲しいのか?
文句言ってるヤツはどういう情報伝達がお望みなんだ?
201 :
2012/01/26(木) 01:44:22.77
UMLを使うの反対は、UML以外の図を使うということ。
UMLを使うの反対は、設計をしない。設計図を書かない。ということではない

UMLを使わないと言っているやつだって、それなりの規模なら
設計はするだろ? そのときの設計図を何で書くか。
202 :
2012/01/26(木) 07:52:18.10
UMLに何を期待するかで、意見が分かれると思う。
UMLを図を現す1手段だと考えれば、それ程不満はない。
UMLを使えば、皆が設計や分析がうまく行ってそれこそバラ色の開発が行える万能ツールと思っているなら、それは違うと思う。
203 :
2012/01/26(木) 08:36:49.57
UMLのMLはモデリング言語

設計や分析の話は関係ない。
204 :
2012/01/26(木) 08:47:57.78
>>202
UMLで設計すれば薔薇色…?
誰もそんな意見行っていないぞ…
一生懸命そういう事にしようとしてるやつがちらほらいるが。
205 :
2012/01/26(木) 09:19:25.78
>>203-204 のような、使い所が限られてるって思ってるなら問題ないと思う。

ただし、UMLを設計/分析のツール考えている人達もいる。
豆蔵では以下のようなセミナーやってる。
「UMLによるオブジェクト指向分析・設計演習」
http://www.mamezou.com/training/OOAD1.html

こんな本も出てる
実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

このスレでも、設計って言葉が何度も出て来た。
206 :
2012/01/26(木) 11:22:54.01
>>198
プログラム作成に関わらない人は、こんなヘンテコな記号読まない、書かない、従って、勉強する可能性ゼロ。
つまり、たどり着けない桃源郷だなwww
207 :
2012/01/26(木) 13:15:49.65
プログラム作成ができない奴が設計ができるわけない。
要件定義もできるわけない。勘違い君は死ねばよい。
208 :
2012/01/26(木) 14:47:58.08
そうじゃなくて、プログラム作成と設計に関わらない人もいるでしょ。
具体的には使う人とか。
そういう人はこんなヘンテコな記号見たくないわけ。
209 :
2012/01/26(木) 15:44:16.76
MVCのビューだけしかわかりません、って人でしょ。
そういう人は使うだけの人で、作ることには関わらない人だよね。
つまり >>198 の「関係者」には入らないと思うんだな。

米を食べる人と、米を作る人、みたいに。
210 :
2012/01/26(木) 22:24:13.02
>>205
逆に聞きたいんだが、
UMLを使わないオブジェクト指向分析・設計なんて
今時あるのか?
211 :
2012/01/26(木) 22:25:08.55
オブジェクト指向分析・設計するのに
UMLじゃないものを使って記述するなんてまずない。
212 :
2012/01/27(金) 11:01:09.78
なことない。
C++のクラスヘッダー書きながらクラス設計なんてフツー。
そのときDoxgenで、UML出すかもしれないが、それは超オマケ。
213 :
2012/01/27(金) 22:14:22.21
>>212
記述っていうのは、ドキュメントファイルに
図形として書くって意味だよ。

もともと設計書を書かない(ソースコードしかない)
そういうプロジェクトがあるのは知ってる。
だけど、今はその話はしていない。

設計書を書く(出力する)プロジェクトは普通にあるだろ?
そういうプロジェクトでオブジェクト指向分析・設計をして
各ドキュメントに、どのモデリング言語を使うかって話。

今は普通はUMLを使う。
実際にDoxgenもUMLを使ってるしね。読めないと。

Doxgenなどのツールが、どこぞの社内専用モデリング言語に
対応してるわけがないわけで。
214 :
2012/01/28(土) 11:28:32.69
UMLがもたらす世界を夢見つつ今日もVB6の巨大システムと戦う
215 :
2012/01/28(土) 11:29:20.25
UMLは何かをもたらすもんじゃないよ。
ただの記号だ。

世界標準だからどこでも使うってだけ。
216 :
2012/01/30(月) 21:07:21.49
90年代末にExcelで作ったクラス定義書を今も現役で使用。
客から指定がない限りは、それが当時からの社内標準だ。
定義を書き終われば、VBAでC++かJavaのコードの雛形を生成できる。
VB.NETとC#に対応できるよう拡張したバージョンもあり、
正規版ではないが、実用上問題がないので使われてる。
Delhiにも対応しようと言ってる信者もいるが、もうDelphi案件はないので、無視されてるな。
従来から実績のあるものを、必要に応じて拡張しつつ使い続け、
それで何も問題がないため、世界標準といえどもUMLの出番はなし。
217 :
2012/01/30(月) 22:06:19.62
>>216の社内だけの話(大爆笑)
218 :
2012/01/30(月) 22:57:27.48
世界標準ほど胡散臭いものがない
ローカルルールほど長期に渡って多用され続け実績を積み重ねる
219 :
2012/01/31(火) 00:17:39.50
昔はOMTだとかBOOCHとかの図があった。
OMTはUMLによく似たもの、BOOCHはきっちりとした図というよりも
手書きを意識した一見ラフな図の書き方だった。
説得力はあったが、実学から離れた、机の上だけの理想論にも感じられた。
UMLもその延長だろ?
220 :
2012/01/31(火) 08:11:20.25
>>219
図の書き方と
設計方法の区別をつけなよ
(嘲笑)
221 :
2012/01/31(火) 08:11:36.70
>>218
ローカルルールが通用しない相手に負けたひきこもり乙
世界に通用しない自称「実績」w

>>219
> 実学から離れた、机の上だけの理想論

構造化プログラミングやオブジェクト指向を、そう言って退けてきたバカの後を
追って消えて行きたいなら好きにすればいいと思うよ。
222 :
2012/01/31(火) 19:23:16.57
TH図というのもあって、客の提案で開発に導入した事もあった。
日本人が考案したもので、一見するとクラス図を簡略化したようにも
ER図を大幅拡張したような図にも見えた。
全体的な業務の流れを表現するだけでなく、そこからクラスやデータベースの設計にも使え、
クラスの概念がない言語、データベースではなくファイル仕様の作成にも使えるとのことだった。
高い金を払い、専門のコンサルタントとも契約した上での導入だった。

結局、システムをおおよそ俯瞰できるだけで、実開発にはほぼ無益。
理屈上は様々な図のいい所取りの規格だが、それだけのものだった。
いわゆる、自称コンサルタントの自己満足。
時間も金も無駄になり、黒字が見込めたはずのプロジェクトが、デスマ、大赤字になった。
身をもって悪例を学んだと言う点では、有益だっただろうか。

UMLもそれと大差ない。
せいぜい、積極的に導入し、思う存分赤字を垂れ流してほしい。
世界標準への適合が最優先なのだから、利益など考慮に値しないだろう。
そうしている間に、世界標準など一切無視しているプロジェクトが、黒字を達成しているのさ。
223 :
2012/01/31(火) 19:24:30.54
してから言えw
224 :
2012/01/31(火) 19:29:09.00
確かにUML活用部署はデスマの嵐
225 :
2012/01/31(火) 20:03:25.15
80年代と大差ない仕事をやり続けている部署の方が地道に稼いでるな
仕事が急増する事もないが、仕事が全くなくなる事もない
時代遅れだと言われても、稼いでいるのは事実だ
226 :
2012/01/31(火) 21:09:16.88
Unfortunate Morbid Language
痛々しい病的言語
227 :
2012/01/31(火) 21:39:45.91
だからUMLはただの図の書き方であって
黒字とか赤字とか関係無い話だってばw

設計をしないってやり方もあるが、
設計はするだろう? 設計して図を書くだろう?
その時どんな図を書くのさ。自分で考案するのか?

汎用的に使える図(UML)が定義されてるんだから
それを使えばいいだろう。

設計ツールみてもUML図が登録されていることはあるが、
自分で考案した図なんか登録されてないぞ。
228 :
2012/02/01(水) 01:27:32.23
>>227
頭で設計してコードを書くんだろ。
自分一人でしか仕事できないヤツの典型。
229 :
2012/02/01(水) 08:47:22.42
>>222とか>>225はそもそも設計してないんじゃない?
そりゃUMLだろうとなんだろうと、工数が増えるのは当たり前 
230 :
2012/02/01(水) 09:00:59.71
仕様は頭の中にあるってヤツの典型だよなー。

UMLが最高のモデリング言語なんて誰もいっていない。
お前の頭から仕様を外に出すための一つの手段だ 。

ていうか、UMLごときを使えないヤツが開発やる事自体が、この仕事がいかに舐められているかを表しているよな。
231 :
2012/02/01(水) 10:57:51.70
そしてそういうレベルの人間を大量投入してどうにかこうにかやってきて、
ついにどうにもならなくなって国が終わりかけております。

どうしたらいいんですかね本当に。勉強しろ、と怒鳴る?
232 :
2012/02/01(水) 14:07:35.01
十年遅いけど、大学教育を改革すればいいんじゃないかなぁ。
まともにコンピュータサイエンス教えてる大学が無いよねぇ。
時代に合ってない。
233 :
2012/02/01(水) 18:43:58.38
unholy maggot language
汚れたウジ虫言語
234 :
2012/02/01(水) 18:44:32.46
UMLを使い始めたら一週間でモテモテ
235 :
2012/02/01(水) 18:48:16.93
UMLで包茎が治った!
236 :
2012/02/01(水) 18:58:49.75
情報処理技術者検定試験をいくつか整理して、新たにコンピュータサイエンス学科の
3年次修了程度を想定した共通試験制度を作るとかかなぁ。
237 :
2012/02/01(水) 19:12:25.79
世界標準UMLがナウなヤングにバカウケ
238 :
2012/02/01(水) 19:23:02.59
UMLで全米が泣いた!!
239 :
2012/02/01(水) 19:39:34.37
UMLで人妻と出会える!
サクラは一切使わない世界標準!
240 :
2012/02/01(水) 19:54:55.97
世界標準のUMLで痔が治りました
ありがとうございました
241 :
2012/02/01(水) 20:49:15.09
UMLを入れたら車の燃費が目に見えて良くなったわ
242 :
2012/02/01(水) 22:43:48.13
UMLでご飯がおいしく炊けました
243 :
2012/02/01(水) 23:23:56.07
趣味娯楽の多様化により若者のUML離れが深刻化し
各社とも販売戦略の見直しを求められています。
244 :
2012/02/02(木) 09:12:22.57
UML使ったら背が伸びた
245 :
2012/02/02(木) 19:35:52.76
UML被害者の会
246 :
2012/02/02(木) 21:51:42.59
中3死亡 UML遊びで窒息
247 :
2012/02/03(金) 02:55:48.39
やっとUMLが方法論ではなくて
ただの記号って理解したようだw
だからくだらない話を始めたんだろ?
248 :
2012/02/03(金) 03:23:46.39
共通言語は人類永遠の夢
バベルの塔が崩れて言葉が通じなくなったんじゃなくて
言葉が通じてなかったから欠陥工事でバベルの塔が崩れたのだよ
249 :
2012/02/03(金) 06:30:55.37
OOP向けフローチャート
250 :
2012/02/03(金) 07:50:16.53
意味はわからなくてよいので、カタカナ語やアルファべット数文字の略語を連呼すれば
最新のイメージ、技術が高いようなイメージを持たれ、受注獲得に繋がる

有益性や成功例を提示しなくても、世界標準という言葉を使われると誰も反論できなくなる
どんな無意味なものでも、世界標準と呼ばれるものを切って捨てるには、
新規に世界標準と認められる規格を作り上げ、対案とするしかない
そこまでコストをかけるのは無駄なため、何の考えもなく右へ倣えで世界標準とやらを採用し、デスマを招く

それでも世界標準と言う言葉には魅力があるため、
書籍、資格試験、セミナー等の需要は絶えない
どれだけ失敗例を積み重ねても、カネになる以上は、決してやめない
UMLを採用せず成功した例があっても、ローカルルール、世界に通用しない等と批判し、
またもや世界標準という言葉の魔力に頼る
251 :
仕様書無しさん
2012/02/03(金) 07:50:36.97
UMLで勃起力アップ
252 :
2012/02/03(金) 08:32:27.80
>>250
必死だなw
253 :
2012/02/03(金) 14:18:27.10
>>250
論点ずれすぎ
そんなにUMLが憎いのか
254 :
2012/02/03(金) 21:09:29.73
意味はわからなくてよいので、カタカナ語やアルファべット数文字の略語を連呼すれば
最新のイメージ、技術が高いようなイメージを持たれ、受注獲得に繋がる

有益性や成功例を提示しなくても、世界標準という言葉を使われると誰も反論できなくなる
どんな無意味なものでも、世界標準と呼ばれるものを切って捨てるには、
新規に世界標準と認められる規格を作り上げ、対案とするしかない
そこまでコストをかけるのは無駄なため、何の考えもなく右へ倣えで世界標準とやらを採用し、デスマを招く

それでも世界標準と言う言葉には魅力があるため、
書籍、資格試験、セミナー等の需要は絶えない
どれだけ失敗例を積み重ねても、カネになる以上は、決してやめない
Rubyを採用せず成功した例があっても、ローカルルール、世界に通用しない等と批判し、
またもや世界標準という言葉の魔力に頼る
255 :
2012/02/03(金) 22:49:35.38
という脳内設定だったのさ、で終わりですねw
256 :
2012/02/03(金) 22:52:22.00
まあ無くても何も困ることないよなUML
あると教育コストがかかって困るけど
257 :
2012/02/03(金) 22:53:29.35
独自記法は教育コストゼロなのかwwwwwww
258 :
2012/02/04(土) 09:31:59.71
独自記法でやってきたとこがUMLに転換したら
いままで作ってきた独自記法のドキュメントはどうするんだろうね?
259 :
2012/02/04(土) 11:30:20.37
>>258
記法のマニュアル。
UMLとの対応表をつけておけば良い。
260 :
2012/02/04(土) 11:31:44.54
>>257
だよな。

独自記法の教育コストがかかった上に
どっちみちUMLだって知らなきゃモグリだし、
選択肢は

・独自記法+UML
・UML

この2つしか無いよね。
261 :
2012/02/04(土) 11:50:58.36
いかれたことに、19世紀の日本の田舎みたいな、共通語を話す奴はのけもの、
方言こそ共通基盤、みたいな組織がいまだはびこってるのが日本という国だからな。
262 :
2012/02/04(土) 12:17:39.64
みんなが使ってるから何がいいのかわかんないけど僕も使う!
のほうが日本らしいけどな
263 :
2012/02/04(土) 12:27:36.81
>>262
それは「僕」の選択理由が日本らしいのであって、
「みんな」は関係無いでしょw
264 :
2012/02/04(土) 13:30:28.73
開発者にとっては、UMLだろうが独自記法だろうが読むのは難しいことではない。
UMLは、開発者以外(例えば開発の依頼主)も図が理解できて、打ち合わせ等で仕様の確認ができるという用途が考えられていた。
開発者以外がUMLを理解できれば、仕様の誤解による戻り工数が減るはずというのが書き方を統一するUMLの狙い。
でも実際は、開発者以外がUMLを理解しないので、その利点が無いのが問題。
265 :
2012/02/04(土) 14:07:31.43
なお、開発者以外が、独自記法を理解できる可能性は
もっとないので、>>264の書き込みは無視して良い。
266 :
2012/02/04(土) 14:33:58.23
図の描き方を統一すれば仕様の誤解が減るとするUMLのアプローチ自体が失敗したんだと思う。
そこは、ラピッドプロトタイピングとか別の方法が有効なのだろう。
267 :
2012/02/04(土) 14:41:09.71
>>266
それはUMLと関係ない話をしてる。

図の書き方を統一しても使用の誤解が減らないのであれば
それは社内独自記法であっても、同じ事だ。

ラピッドプロトタイピングはUMLとは別のもの。
ラピッドプロトタイピングでもUMLを使うことはある。
268 :
2012/02/04(土) 14:45:30.26
やっぱ独自記法でよくね?
UMLも素人が見ても理解不能な程度にわかりにくい図なんだし
269 :
2012/02/04(土) 14:58:19.81
”素人が見ても”

じゃあプロは?
270 :
2012/02/04(土) 15:03:57.09
独自記法てのは参入障壁として機能しそうだね
271 :
2012/02/04(土) 15:04:55.35
新しい人が、会社に入ってきた時
まず独自記法を覚えないといけないという
参入障壁かw
272 :
2012/02/04(土) 22:16:46.95
>>270
貧しい労働者が他人に仕事を奪われないために築く防壁だな。
いずれ国ごと滅ぶ。
273 :
仕様書無しさん
2012/02/05(日) 23:12:05.79
UMLなんて懐かしいな。
もう5〜6年も前の事かな。
入門書の購入や研修受講に会社が金を出すほど積極的だったり、
自分の金で本を買ったり試験を受けたりする奴もいたり。
実際に使っている所もあり、今後使う機会はありえるという認識はあるけれど
今のところは私的な用途以外では、使う機会が皆無。
UMLの次は何が出てくるんだろ。
274 :
仕様書無しさん
2012/02/05(日) 23:27:05.21
UMLは廃止になるらしいよ
275 :
2012/02/05(日) 23:54:03.59
新規格を新たな世界標準として普及させる事で
解説書の出版、セミナーの開催、資格制度の策定という
ビジネスが生まれ続けます。
276 :
2012/02/06(月) 03:27:56.06
ドメイン駆動設計とか誰もやらんの?
277 :
2012/02/06(月) 10:03:48.05
それができないバカが一人で必死に暴れてるだけですからw
278 :
2012/02/06(月) 11:20:56.17
馬鹿は[できない理由]を探すからな
UMLを使うメリットが見えてない
279 :
2012/02/06(月) 14:32:35.40
で、メリットは?
280 :
2012/02/06(月) 15:11:12.10
UMLを学ぼうとしない不勉強者を淘汰することができる
281 :
2012/02/06(月) 15:23:20.66
>>279
しょうもない独自記法を学ばせずに済む
282 :
2012/02/06(月) 15:26:46.18
UMLで書かれた設計書を更新させられる時が一番鬱になる。
283 :
2012/02/06(月) 15:38:03.28
お前は何で書かれてても欝になるだろうメンヘラよ
284 :
2012/02/06(月) 20:23:42.64
独自記法が単純明快すぎ、1時間程度の説明を受ければ、
あとは既存資料の真似をするだけでほぼ事足りました。
「世界標準だから無条件で従え」というものではなく、
実際の現場で試行錯誤を重ね、洗練させ続けたものの方が、有用性があるのは当然ですね。
285 :
2012/02/06(月) 20:35:22.73
> 実際の現場で試行錯誤を重ね、洗練させ続けたもの

世界の多数の実際の現場で試行錯誤を重ね、洗練させ続けたものより
一事業所で試行錯誤を重ね、洗練させ続けたもののほうが優れていると
思うバカがここにいますw
286 :
仕様書無しさん
2012/02/06(月) 21:25:44.34
UML使ってない職場なら無理に学ぶ必要はないよ
いざ使うとなってから学んでも十分OKさ
287 :
2012/02/06(月) 21:48:45.06
まぁ、難しいものじゃないからな。
必要なときに覚えればいい。

割と使う機会はあると思うが、こんなに要らないって騒ぐヤツがいるっていうのは、土方だから必要無いとか…?
288 :
2012/02/06(月) 22:03:17.30
俺の人生には必要ない!
といえばいいのにねw
289 :
2012/02/06(月) 22:10:39.79
UMLも、独自規格も、その時々の状況に応じて使い分ければいい。

どうせUMLも何年か後には別規格に取って代わられるだろうし
独自規格もその頃には大幅に更新されているだろう。
その時はその時で、UML後継規格と、新独自規格を状況によって使い分ければいいだけの話。
あえてUMLを使い続け、古い資料と体裁を統一するという選択もあるかもしれない。
290 :
2012/02/06(月) 22:32:04.45
独自規格は、今すぐ外部では使えないという
欠点があるな。
291 :
2012/02/06(月) 22:55:52.38
モデリング言語の良し悪し語れるほどモデリング言語に詳しいのかよw
比較対象持ってきて比較するなり、評価ポイントまとめてから出直してこいw
292 :
2012/02/06(月) 22:59:03.39
他社の都合を一切考慮する必要がなく、
自社の都合だけで自由に仕様を作ることができる
独自仕様の方が優れていますよ。
自社だけで完結する場合のみ、という条件付きですが。
293 :
2012/02/06(月) 23:37:36.78
自社だけで半導体の精錬から、システムの運用までやってるならw

それから規格のメンテナンスも。
米軍とか国鉄クラスの規模の組織なら、なんでも自分ところの規格、
って例も過去あったけどさw
294 :
2012/02/07(火) 00:39:38.77
>>291
社内専用だぞ?

勝手に公開できるわけ無いだろう。
しかも俺がどこの会社の人間かばれるだろ。

比較するまでもなく答えが出てる。
295 :
2012/02/07(火) 07:26:30.16
比較できないのに、優劣がわかるバカw
296 :
2012/02/07(火) 08:11:02.10
>>294
社内専用で見せれないけど、UMLより優れたモデリング言語があるとしよう。
その秘伝のモデリング言語が仮にUMLより優れていたとして、他の会社がその言語使うメリットってなによ。(まぁ、知らないから使いようも無いわけだが)
標準化されてるから他社(他者)との共通言語として使える事がUMLのメリットだよな。
コードジェネレータに食わす為にUMLを独自拡張するってなら話は分かるが、モデリング言語の研究した事ない人間に良し悪し語られた上に
「比較されるまでもなく答えが出てる(キリッ」とか言われても…すごく思い込みが激しいか、信者か、中二病にしか見えないです…^^;
297 :
2012/02/07(火) 08:58:22.43
改変パターン1:

社内の一部のヲタク専用で見せれないけど、COBOLより優れたオブジェクト指向言語があるとしよう。
その秘伝のオブジェクト指向Javaが仮にCOBOLより優れていたとして、他の会社がその言語使うメリットってなによ。(まぁ、知らないから使いようも無いわけだが)
標準化されてるから他社(他者)との共通言語として使える事がCOBOLのメリットだよな。
コードジェネレータに食わす為にCOBOLを独自拡張するってなら話は分かるが、オブジェクト指向言語の研究した事ない人間に良し悪し語られた上に
「比較されるまでもなく答えが出てる(キリッ」とか言われても…すごく思い込みが激しいか、信者か、中二病にしか見えないです…^^;
298 :
2012/02/07(火) 09:01:43.74
過去に「COBOLのような独自言語」が山程あって、みんな俺のほうが優れてる、と主張していた、
とかいうバカな事実を知らないバカが必死ですねw
299 :
2012/02/07(火) 09:02:19.11
改変パターン2:

インターネッツ専用で見せれないけど、汎用機OSより優れたGNU, POSIX準拠OSがあるとしよう。
その秘伝のGNU準拠Linuxが仮に汎用機OSより優れていたとして、他の会社がその言語使うメリットってなによ。(まぁ、知らないから使いようも無いわけだが)
標準化されてるから他社(他者)との共通言語として使える事が汎用機OSのメリットだよな。
GNU, POSIX準拠コードを動かす為に汎用機OSを独自拡張するってなら話は分かるが、オープンソースの研究した事ない人間に良し悪し語られた上に
「比較されるまでもなく答えが出てる(キリッ」とか言われても…すごく思い込みが激しいか、信者か、中二病にしか見えないです…^^;
300 :
2012/02/07(火) 09:11:57.63
改変パターン3:

特定メーカー品で見せれないけど、コードジェネレーターより優れたクラスライブラリングがあるとしよう。
その秘伝クラスライブラリが仮にコードジェネレーターより優れていたとして、他の会社がその言語使うメリットってなによ。(まぁ、知らないから使いようも無いわけだが)
標準化されてるから他社(他者)との共通言語として使える事がコードジェネレーターのメリットだよな。
コードジェネレータに食わす為にランタイムライブラリを独自拡張するってなら話は分かるが、オブジェクト指向の研究した事ない人間に良し悪し語られた上に
「比較されるまでもなく答えが出てる(キリッ」とか言われても…すごく思い込みが激しいか、信者か、中二病にしか見えないです…^^;
301 :
2012/02/07(火) 09:19:44.29
結局、「UMLのメリットは?」っていう質問の裏には、”標準”であること以外の良い部分教えて、ってこと。

それに対してベストの答えは、
・標準化されてないUML以外のものを他の会社が使うメリットってなによ
・標準化されてるからUMLはメリット
・「比較されるまでもなく答えが出てる(キリッ」とか言われても…すごく思い込みが激しいか、信者か、中二病にしか見えないです…^^;
藁wwwww

このスレ、この文脈が延々と繰り返されるのみです。
302 :
2012/02/07(火) 09:30:43.26
おまえの脳味噌が永久ループしてるだけだろw
303 :
2012/02/07(火) 09:35:22.84
UMLって聞くと、裸の王様を思い出すんだよね。
「世界標準ですから」っていうのと、「愚か者には見えない服ですから」っていうのが同じに聞こえる。
304 :
2012/02/07(火) 09:39:14.82
302はcと認定し、無効とします。

***テンプレ***
a) 標準化されてないUML以外のものを他の会社が使うメリットってなによ
b) 標準化されてるからUMLはメリット
c) 「比較されるまでもなく答えが出てる(キリッ」とか言われても…すごく思い込みが激しいか、信者か、中二病にしか見えないです…^^;
305 :
2012/02/07(火) 09:43:15.49
303 304はcと認定し、無効とします。
306 :
2012/02/07(火) 09:56:01.11
このスレ、有効なレスがゼロかよw

で、UMLのメリットは?
”標準”であること以外の良い部分教えて、ってことね。
307 :
2012/02/07(火) 10:04:49.49
サードパーティのツールが使える
308 :
2012/02/07(火) 10:25:03.25
XMLとは別人だよな
309 :
2012/02/07(火) 10:34:48.09
なんか俺言っちゃいけない事言ったのかな…すげー発作だな…

UMLの利点は標準化されてるモデリング言語だって最初から言ってるじゃん。
ただの共通言語だって。
それ以上でも以下でも無いって。

それに対して「ドクジノゲンゴガー」って噛み付くから、じゃあそれを俺らが使うメリットってなによ?って聞いてるんだろ。

UMLに勝るモデリング言語を提示できず、UMLに対する改善案を提示できず、ドクジノゲンゴを広めるわけでも無い。
一体何が言いたいんだこのバカ?
UMLを叩く為にUMLを叩いてるから話が一向にかみ合わない。
310 :
2012/02/07(火) 10:58:01.05
知識が広まれば知識を独占することで特権を得ていた人たちはその地位を失うのだ。
311 :
2012/02/07(火) 11:04:55.74
UMLで全部設計しちゃうと実装の仕事はお安い海外にもっていかれるもんな
時の流れだから仕方ないか
312 :
2012/02/07(火) 11:35:01.77
そもそもアウトプットがUMLならばUMLを扱える会社ならどこでもいいということに
313 :
2012/02/07(火) 11:46:34.58
要求をUMLに落とすまでが腕の見せ所になるね
314 :
2012/02/07(火) 15:33:20.41
googleとかfacebookって独自記法使ってるの?
315 :
2012/02/07(火) 20:21:28.77
使っていれば、公開してるだろw
316 :
2012/02/18(土) 14:21:43.07
つーかモデリング言語って発想がクソってスレなんじゃないかここ
317 :
2012/02/18(土) 22:33:41.45
地図記号のようなものだ。
クソなわけがない。
318 :
2012/02/19(日) 21:19:56.29
>>316はこのスレのことを正しく把握している。
>>317は直前のレスしか読めていない。

できれば擁護論者のほうに高いレベルを求めたいものだ。
319 :
2012/02/19(日) 21:28:47.93
お前の感想なんかいらんしw
320 :
2012/02/19(日) 21:29:35.88
レベルの低い奴が「高いレベルを求めたいものだ。」とかw
321 :
2012/02/23(木) 23:21:06.91
>>319-320
以上、レベルの低い奴提供のレベルの低い反論でした
322 :
2012/02/24(金) 07:57:09.63
>>318 を入れ忘れるくらいレベルが低かった、とwwwwwwww
323 :
2012/02/27(月) 11:50:35.05
モデリングがクソだとすると、この糞はそれにまさる情報伝達の手段を持っているのだろうか。
伝達手段の一つで、抽象度が高いのだから、認識を共有できる人への伝達速度は早いのだが。

まさか、俺がやれば早いとか言って、全部一人でやるタイプではないよな…
324 :
2012/02/27(月) 11:53:19.34
伝統の伝票ベースの仕事しか想像力の範囲に存在しないとか、そういう人でしょ
staticおじさんとかと同類
325 :
2012/03/01(木) 01:39:14.93
このスレは擁護派である程、UMLにあまり期待してないね。だから、不満がない。
設計に使わないって言ってるんだから。

毎年30万以上払ってソフト使ってる人や、一人15万払ってセミナー受けるような人は期待を裏切られた気持ちになるんだろう。
326 :
2012/03/01(木) 01:50:48.06
そんなの、自分が悪いだろ。
いい話されてアムウェイ入っちゃうヤツくらいカス。
そんなやつはどんどんセミナー商法に貢いでて下さい。

そもそも、UMLで設計とか、設計の意味わかってないんだろ。
どうあがいたって考えることは人間の脳以外でできないんだから、頭で設計して、設計を頭の外に出すのがUML。
そこから設計を見直すってならわかるが。
UMLを使えばいい設計になると思ってるなら頭の病気だよ。

自分がよくわからないことはすごいと思いたいだけの腐ったゴミ屑。
占い師や霊媒師を信じる芸能人と同じ。
327 :
2012/03/11(日) 10:08:27.85
このスレには始めて来たんだけど
方程式ってなんの役に立つんだよっいう人間を見た気分。
なかなかに衝撃的だ
328 :
2012/03/11(日) 20:40:03.50
全然違うだろ
方程式は数学の土台にあたるものだが、
UMLはあくまで複数ある表記法の一つでしかない
329 :
2012/03/11(日) 20:47:04.93
数学の土台は論理であって、方程式は土台でもなんでもないよ。
330 :
2012/03/11(日) 22:28:35.70
漢数字かギリシャ数字って感じ?
UMLはエジプト絵文字みたいな位置だな
あちこちで目にするけど、なんやよう分からん
331 :
2012/03/11(日) 22:59:02.50
なんだ、数学の方もわかってないのか
さすがIT土方は違うな
332 :
2012/03/12(月) 01:00:42.48
>>327
どうして、UMLを方程式に例えたの? どういった点が似てるの?
333 :
2012/03/12(月) 03:12:05.68
>>332
使えると物凄く便利なのに、使えない人にとっては全く意味をなさない道具。
俺はその書き込みに特に違和感を感じなかったけど。
334 :
2012/03/13(火) 08:04:15.74
プラス
・単なるツールでしかないが、思考の手助けになること
・他に代替手段(鶴亀算、行列など)はいくらでもあること
・概念(代数/オブジェクト指向)が分かればたいした物ではないこと

まぁ分からん人は何を言っても分からんだろう
335 :
2012/03/14(水) 01:49:41.64
「物凄く」って程、便利かね。このスレでも、>>328が書いてるように「UMLはあくまで複数ある表記法の一つでしかない 」程度だよ。

UMLって新しい手法を提案するっていうより、制定当時既にあった複数の表記法を統一する為にルールで縛ったものだよね。
自由度や表現力という意味では、UMLに縛られない方が優れている。

いろんな対象を取り扱うプログラムでは必要な図も対象によって異なる。それぞれに適した描き方を採用すれば良いと自分は考えている。
336 :
2012/03/14(水) 02:16:49.45
>>335
物凄く便利なのは方程式でした。
UMLはそこそこ便利って位かな。

君の言う通り、UMLはモデリングの共通部分を抽出したものだと思う。
付け足しちゃいけないわけじゃないし、事実、実際のプロジェクトでは拡張UMLが使われる事は少なくないはず。

いろんな言語やツールがあるけど、学習能力の高い集団なら何を使っても便利。
低い集団なら、極力使う技術を絞った方がいい。
ここで文句言ってるやつは、だいたい後者なんだよね…
337 :
2012/03/14(水) 03:31:12.79
>>335です。

自分は、UMLをプログラムに活かそうといろんな本を読んだけど、こんなのが有ったんだ。
Step1 ユーザーから要求を聞いて、ユースケースを書きましょう
Step2 ユースケースの説明を文章で書きましょう
Step3 説明の文章から名詞を抽出してクラス図を書きましょう

また、ほかの雑誌ではUMLの図のパターンとJAVAのソースの対応表なんてのが記事で載ってたりした。

上の例は極端だけど、自分の勉強した範囲ではUMLを積極的に活用してプログラムを作るというものがあったので、
それを開発に活かそうとしたけど実際にはうまくいかずUMLに対する不信感がありました。

このスレで>>326を読んで、自分が過去に行ったUML中心でプログラムを開発するというのではなく、
設計は別で行って考えを表現するのにUMLなどの図を使うというのが正しいな、と今は思います。
338 :
2012/03/14(水) 20:38:46.82
>>337
> 設計は別で行って考えを表現するのにUMLなどの図を使うというのが正しいな、と今は思います。
何を読んだのかしらないけど、そもそも
設計は別で行って考えを表現する図を統一したものがUML。
正しいも何も、そのために作られたもの。


オブジェクト指向による設計方法・・・OMT法、Booch法、OOSE法

いろんな人が色々考えた。
考え方バラバラ、当然図もバラバラ。

考え方がバラバラなのは仕方ないけど
せめて図だけは同じ物を使おうよ



UML
339 :
2012/03/15(木) 00:40:52.64
UMLの理念は良いとして短期間でコロコロ変え過ぎだろ

L1取る前に独習UML通読したけど、
図の名前が変わったり、以前あったステレオタイプをバッサリ削ったり

俺が初めてUMLに触れたのは1.3位だったけど、
独習UMLは2.x対応を謳ってたわ
何だよ2.xって
そんだけコロコロ変わってるからこそ、そう謳うしかなかったんだろうが

表記法を統一する為に作られたはずなのに、バージョン違えば同じ事を表現するのに違う表記を強いられるとか意味不明過ぎる

とりあえずL2までは取ろうと思ってるけど、正直言って今後も普及は望むべくもないなと思ってるわ
340 :
2012/03/15(木) 01:25:38.03
UMLが図の描き方にすぎないという点では意見が一致してるね。

少し話はずれるけど、そもそも自分がUMLとかオブジェクト指向とか勉強したのは正しいプログラム開発とはどういうものか知りたかったから。
正しい知識と手順で行えばスケジュールを遅れる事無く進められ不具合ないプログラムを作れる、そんな理想に近い手段を探してた時期が自分にはありました。
多くの人達にとって、いろんな言語やツールを使うのは同じ思いがあるんじゃないかな。だれでもトラブルは避けたいもの。
UMLは、そういう必要性から勉強するとがっかりしてしまったんだ。ただの図の描き方だったから。
341 :
2012/03/15(木) 01:45:09.63
>>339
言語なんだから変化するのは仕方が無いな。

>>340
必ず正しい答えと言うものがないため、特定の方法を丸暗記しても役に立たない。
方法はパラメータによって効果が変わる。
いわゆるベストプラクティスってやつを目指すには、状況に合わせてちいさな方法を最適になるように組み合わせる必要がある。
これはシステムの設計で小さなアーキテクチャパターンを組み合わせるのに似ていて、その方法がどう言う状況でどういう効果をもたらすのかを理解していなければ使いこなせない。
ただし、これは可能な限り合理的、効率的に仕事を遂行する事を目指している。
完全に見積もりたいのであれば、完全に同じやり方で、やったことのある仕事をするべき。
がしかし、開発を仕事としてしている限り同じ事を繰り返さないようにするために仕事をするため、いつもやった事ない作業が発生する。

ここまで書いて疲れた…
342 :
2012/03/15(木) 09:01:06.83
オブジェクト指向にしっくり来ないんだったら、違う視点として、
ジャクソン親子の本でも読んでみるといい。
343 :
2012/03/15(木) 09:44:10.61
オブジェクト指向にしっくり来ない、といわれると気分はstatic!になりそう
344 :
2012/03/15(木) 13:12:17.43
>>342
ありがとう。ジャクソン親子ですね。読んでみます。

>>343
気分はstatic!ですか。ググってみたけど...あはは、すごいですね。いえ、マネしないようにします。
345 :
2012/05/23(水) 20:37:08.23
ジャクソン先生自身の著作じゃないけど、jsp/jsdについて書かれた本読んでみた。
確かに合理的だし、とっても勉強になった。

以前は、データと処理を分離する構造化設計はオブジェクト指向に反するとか、構造化設計を知らない方が先入観無くてオブジェクト指向が速く習得できるとか言われたけど、
最近は、”今でも通じる考え方”とか”モデリングの原点”とか言って構造化設計の本も本屋に並んでるね。
世の中の流れが、”脱構造化”から”オブジェクト指向以前の研究にも学ぶ事がある”になってる気がする。
346 :
2012/05/24(木) 07:38:20.42
オブジェクト指向=脱構造化、というのが大嘘っすよ。
誰がそんなこと言いふらしてるのか知らんけど。

従来の構造化では、コントロールの流れのみを構造化していたのに対して、
オブジェクト指向ではデータ抽象で、データについても構造化する、というか。
347 :
2012/05/28(月) 14:48:36.36
今はエージェント志向が流行
役割毎にタスクを分けてメッセージ交換しあって動くの
348 :
2012/06/01(金) 07:28:31.10
こういうとこで長々語るような奴は、
頭でっかちでろくな実績がない
349 :
2012/06/01(金) 08:16:07.02
とかいう奴はたいてい頭がない
350 :
2012/06/01(金) 09:54:19.93
と、こんなところで長々語っちゃった方が発狂しながら申してます。
351 :
2012/06/01(金) 20:31:54.69
プログラマー板なんだから、プログラミングに役立つ事書き込もうぜ。
352 :
2012/06/01(金) 22:08:15.12
そろそろテキストベースのプログラム言語ではなく
グラフィカルにプログラムが作れるパラダイムを規格化するべきだ

テキストしか表示できなかった20年以上前のコンピュータならともかく
グラフィックがふんだんに表示できる今のコンピュータで
テキストに拘る必要はない
353 :
2012/06/13(水) 21:06:55.22
ノンコーディングとか老害が夢見る発想だな。
354 :
2012/06/13(水) 21:10:03.67
コンピュータがどうやって動くかわかってない人は表面的なことしか考えないんだね
355 :
2012/06/13(水) 23:22:31.13
間違いなくこういう残念な子が、第五世代コンピューターとか言い出したんだよな。
356 :
2012/06/13(水) 23:38:18.27
アナログコンピュータ的な発想が忘れられない人たち?
357 :
2012/06/14(木) 07:25:12.85
>>355
『渕一博―その人とコンピュータサイエンス』を100回読んでから出直せ
358 :
2012/06/14(木) 08:37:15.35
>>356
1980年代、
技術的な裏付が何もないのに、国家予算で
人間を超えた人工知能を作ろうとか、
エヴァのmagiみたく生体パーツでコンピューターを作ろうとかいって、
国民の血税を数百億単位でドブに捨てさせたペテン師達のことだよ。
そもそもの目的はまったく達成できなかったが、わずかな副産物が出来たことでプロジェクトは成功だったと言いつづけてる。

今風の言い方をすると、バブル脳ってやつ。
359 :
2012/06/14(木) 09:13:35.42
>>358
貴様こそデタラメだろうが。
全部出典を出してみな。
360 :
2012/06/14(木) 09:42:04.69
AppleのSiriとオリエント工業のドールをコラボさせれば十分だな
361 :
2012/06/14(木) 09:54:22.95
言い続けることさえできなかったシグマ(ry
362 :
2012/06/14(木) 16:15:50.76
>>358
今だに、当時の思い出に浸って、やれると思ってる人たちがいるみたいだね
世は、デジタル的発想になってきてるのに
アナログ的発想ベースでデジタル的発想で考えるとかできないのかね
363 :
2012/06/14(木) 17:21:33.89
デジタル的発想って何?
アナログ的発想って何?

それこそただのバズワード脳だね。
364 :
2012/06/14(木) 17:44:18.45
人の感覚でコンピュータが動くと思ってるのかい?
365 :
2012/06/14(木) 17:49:02.28
バズワードとか言いたがるのがバズワード脳
366 :
2012/06/14(木) 18:46:11.20
完成してから資料作ることよりは、要求に対する読解力を磨けや
何作るかわかってないのに作ろうとするから資料作ってもワケワカになるんじゃねえの
そういう考える時間も十分に与えてくれないところもあるみたいだし
367 :
2012/06/14(木) 19:31:26.07
段階的詳細化のためのツールとしてユースケース図とか悪くないと俺は思うけど?
ソースコードに手をつける前にすることとして。
368 :
2012/06/14(木) 19:34:09.50
>>356
アナログコンピュータってのは、1Aと1Aを足したら2Aになる、とかいう、
物理法則の数式をそのまま応用したものだぞ。
物理法則も数学も放棄したら、現代文明は崩壊するんだが。
369 :
2012/06/14(木) 20:28:50.34
アナログコンピュータがダメとは思ってない
アナログベースでいかにデジタル的な方法に変換するかを考えないと
370 :
2012/06/14(木) 20:58:05.90
UMLと何の関係が
371 :
2012/06/14(木) 21:01:43.21
妙な資料作るよりやることあるでしょってこと
372 :
2012/06/14(木) 21:06:02.48
ダメな図ばっかり見続けた結果、図といえばダメなもの、という等式ができちゃったらしい
373 :
2012/06/14(木) 21:28:27.38
練習しないと絵はうまくならないからね
それと一緒でしょ
形から入るのが悪いとは言わないけどね
374 :
2012/06/14(木) 21:38:38.38
自分のために設計煮詰めたいとき、何使って考えるの?
いきなりコーディングとか言うなよ
375 :
2012/06/14(木) 21:41:50.78
要求がはっきりしてるなら、コーディングしながら、考えるほうだけど
376 :
2012/06/14(木) 21:59:23.68
構造が不要な規模ならそれでいいんじゃないですか
377 :
2012/06/14(木) 22:18:26.83
規模がでかいなら、要求を解読するほうがいいんじゃねえか
ま、ものによるけどね、やり方は
378 :
2012/06/15(金) 08:09:04.79
解読って。勝手に補間するのがこっちに任されてるならいいけど
379 :
2012/06/15(金) 10:05:00.34
プログラムへの変換も出来んのではなかろうか?
380 :
2012/06/15(金) 10:20:48.31
要求が曖昧でナイという保証でもあるんかね
381 :
2012/06/15(金) 23:15:18.91
>>361
シグマプロジェクトも無駄じゃなかったといいつづけてる奴らがいるけどね。
参加者の技術的な下地を底上げし、プログラムの構造化、モジュール化に貢献して、オブジェクト指向を定着させる下地を作ったとかなんとか…


なるほどと納得した奴らは騙されるな!
そもそもそれらに日本発の技術は一つも無いぞw
382 :
2012/06/15(金) 23:24:01.35
GPIBでネットワークだっけ
383 :
2012/06/16(土) 20:45:59.36
「日本発」が偉いならTRONとRubyでも拝んでろw
どこ発の技術だろうと遅々として取り入れない電電ファミリのクソっぷりにはもう飽き飽きだ。
384 :
2012/06/16(土) 21:04:35.55
Rubyは認知されてるみたいだけど、オープン系では
385 :
2012/06/23(土) 23:06:31.31
RubyはRuby自体じゃなくて
外人が作ったライブラリが認知されてるだけだから微妙な感じ
386 :
2012/06/24(日) 07:29:32.73
結局、日本人の作ったものを日本人が認めることができなかった、
と自分で認めちゃったわけだw
387 :
2012/06/24(日) 13:14:27.95
まあRubyはRailsを作る環境に選んでもらえなければ
JIS規格化なんて絶対に無かっただろうね
388 :
2012/06/24(日) 14:44:03.44
タラレバ定食おいしいです
389 :
2012/07/10(火) 18:45:11.45
確かにWeb系なんちゃってJava使いの企業ではいきなりサクラエディタでソース書いてた
設計?ユニットテスト?何言ってんだいいから徹夜で納期に間に合わせろよって感じだった
顧客に渡す資料をパワポで作ってたw
390 :
2012/08/16(木) 06:55:40.30
APL みたいな言語を今 設計したら どういうのができるか? ってことかな
391 :
2012/08/16(木) 13:32:24.35
RPGじゃなくて?
392 :
仕様書無しさん
2012/10/31(水) 17:17:04.13
体にウォーターフォール開発がしみついてる
393 :
仕様書無しさん
2012/11/03(土) 14:45:43.80
無料のUMLライティングツールでいいのない?
394 :
2012/11/20(火) 09:01:44.08
クラス図とかシーケンス図って言うといかめしく感じるけど
倉すずとかシーケンすずって書き直すと女の子っぽくて萌えね?
395 :
2013/02/20(水) 19:53:13.20
既存のUMLツールって計算式(数学記号込)やグラフ等が入った資料が作りにくいのがなんとも残念。

レイヤ構造(OSI 7階層みたいなもの)を表現するのにコンポーネント図を使ってるが、昔ながらのブロック図
の方が見やすかった。

でもまぁ、回路図とかと一緒で、書き始めればそこに設計ノウハウが蓄積されるし、コピペで部分再利用
もできるし、それ程悪くないと思うけどなw
396 :
coyajun
2013/06/14(金) 01:10:25.88
次の選挙では私と一緒に「橋下徹」と書いて投票しろ
ゴミクズサヨク政権を絶対に拒否する"抵抗"と"拒絶"の意思表示だ
維新の会を蔑ろにしたファシストどもは万死に値する!!!!!
397 :
2013/06/14(金) 23:54:33.59
UMLってのはプログラムを作ったことのない馬鹿SEが使う。

あんなお絵かきソフトで作ったもので指示されたんじゃ
不明点だらけで作れるわけがない。

大手メーカーの馬鹿SEでUMLで仕様書を作成していると
なったら、そこの仕事は絶対に受けない。

UMLで仕様書を書くなんてママゴト。
何も知らなくても仕様書が書けるんだから。
デスマになるのは当然のこと。
398 :
2013/06/15(土) 06:56:33.20
ユースケース図なんて
知らない人が見たら
馬鹿かこいつとか思われそうだし

UMLはへたに実装が混ざっているから駄目。
まだSAとかのほうが良かったが普及しなかったな。
399 :
2013/06/23(日) 04:19:54.92
この棒人間って昔子供の頃マンガでよく書いてましたけど・・・
これでお金もらえるんですか?

と言ったら上司にマジ切れされた
400 :
仕様書無しさん
2013/08/30(金) NY:AN:NY.AN
UMLって 名前からして、間違っている。

Unified Modeling Language (統一モデリング言語) って、
どこら辺が、どの様に 言語? 教えてエロい人。

小学生の子供に、
「言語でも無いのに、どうして言語って名乗っているの?」
って突っ込まれた、お父さんの気持ちになってお答え下さい。
401 :
仕様書無しさん
2013/08/31(土) NY:AN:NY.AN
日本人だと判りづらいが、「Use Case」 も、直訳すると、「CASEを使え」 って言う意味で、
ある種の、催眠術か、サブリミナル効果の類を、狙っているよね。

CASEも個々の事例って意味じゃなくて、OOSEって言うCASEツールを指しているからね。
最初の、「オブジェクト指向ソフトウェア工学OOSE」 って本の時には、そのウチに、コードも吐くからねって、
いかにも素人臭い感じだった。
402 :
仕様書無しさん
2013/08/31(土) NY:AN:NY.AN
OOSE 自体は、OMT とか BOOTH とかと、かけ離れていて、全く似ていなかったのに、
スリー・アミーゴズを、抱き込んで、自分の OOSE の方を UML と言う名前で標準にしてしまった。
OOSE も、名前を改め、ROSE になった。(CASEの暗喩であるのはスグ分るよね)

で、ROSEは、素晴らしかったか?
NO どころの話では無い、適切な言葉を選ぶとしたら、NEVER だろう。

100万円近くもするソフトなのに、Windows 上で、UNIXのエミュレーターで、
(この頃、まだCygwinは無かった)、動かしていて、そして良く落ちた。

「こんな程度で、よく人に、ソフトの品質の指導をしようとか思うよなぁ」 と言った具合。
403 :
仕様書無しさん
2013/08/31(土) NY:AN:NY.AN
結局、Rational software も、倒産して、IBM に買われて、
もはや、ROSE は、売ってませんから、買えません。
404 :
仕様書無しさん
2013/08/31(土) NY:AN:NY.AN
UMLをやってみて特に困ったのは、
分析、設計、製造、デバッグ の各工程で、どのドキュメントを
書くべきかの規定が全く無かった事。

OMT や、BOOTH では、有る程度、定まっていて、迷う事は無かったのに、
UML の登場に拠って、酷い混乱が、現場にもたらされた。

困って、色々、本を漁って読んでみたが、それこそ、本によって全部違う。
単に、シナリオ と言った場合に、ユース・ケース図を指す場合もあれば、
シーケンス図の事だったり、単なる文章で良い? とか訳ワカメ。

これでは、仕事に成らないので、否応無しにUMLに独自の解釈を加えて、
無理矢理に仕事をしていたが、現場や、個人の判断で、
作成されるドキュメントが、違ってしまうと言う、なんと言う矛盾。
405 :
仕様書無しさん
2013/08/31(土) NY:AN:NY.AN
まあ、ついぞ、ROSE を仕事で使って、物件が大成功したなんて話は聞いた事が無かったな。
逆の例なら、山ほどあるが・・・

問題なのは、OOSE 自体の思想が、古すぎた事。
MS-DOS 時代の変な常識の上に立脚して出来ている。

Use Case なんて、MS-DOS 時代の 1画面1機能 と言う特殊な条件下であれば、
何とかなったかも知れないが、
Windows の GUI の設計では、もう半分、アウトで、
LED 3 つに、SW 5 個 で、機能が50個近くある 組み込み機器bナは、
もb、書き様が無かbチた。(後に変bネ拡張をして頑鋳」ってはみたが=E・・)

また、シーケンス図なんで、UI の黎明期に、チープ な GUI 部品 で、
画面を設計する手法であって、ロクに分析も済んでいない状態で、
UI 以外の設計に用いて、最初に、あんなに縦棒を何本も引いちゃったら、
設計の粒度が不適切になってしまい、死者を累々と量産した。
406 :
仕様書無しさん
2013/08/31(土) NY:AN:NY.AN
C言語なら、物件が暗礁に乗り上げても、プラス 数ヶ月で終わりもするが、
オブジェクト指向の場合、作用として、乗れば早く終るが、
副作用として、反った場合、最悪、終らない。 ゼロから書き直した方が、早い場合も出てくる。

こう言った人には、UMLの本を読むより、先に、アンデルセン童話の「裸の王様」 を一読する事をお勧めする。

「UML は何故正しいの?」 と言う問いに、
「スリー・アミーゴズ が、そう言ってるから。」 と言う以外に何も無い。

そうじゃ無いだろ。「スリー・アミーゴズ」だって間違うんだよ。
言ってやれ、「UMLはクソ」だって。 スッキリするぞ。
407 :
2013/08/31(土) NY:AN:NY.AN
スリー・アミーゴズはUMLを書けなんて
ひとことも言ってないだろ。

ただ図の書き方を決めただけ。
その図が必要だと思えば書けばいいし、
必要じゃなければ書く必要はない。

図が必要かどうかを決めるのは
開発者だ。

ただ図を書くとき、その書き方が
決まっていたほうが楽だろ?

それだけの話だ。
408 :
2013/08/31(土) NY:AN:NY.AN
ところで最近は、Grady Booch や Booch法 を

BOOTH

と書くのが流行してるのか?
409 :
2013/08/31(土) NY:AN:NY.AN
ところで、今UMLとソースを一致させたプログラムを作るにはどうすれば良いの?
VisualStudio2012のUltimateは値段が高すぎて手を出せないし

ちなみに言語はC++で
410 :
2013/08/31(土) NY:AN:NY.AN
UMLとソースは一致しません。

一致するのであれば、ソースからUMLを生成すればいい。

UMLはソースの一部分しか書かないので
ソースからUMLを生成することは出来ても
UMLからソースは一部分しか生成できません。

それでもソースに書かれていないものは
UMLにはできないので、
つまりUMLとソースは一致しません。
411 :
2013/08/31(土) NY:AN:NY.AN
設計と実装が一致とか意味わからん
何がしたいん?
412 :
仕様書無しさん
2013/08/31(土) NY:AN:NY.AN
お前らいつまでUML(Unidentified Mysterious Language)の話してんだよ。
さっさとUMLの話しようぜ。
413 :
2013/08/31(土) NY:AN:NY.AN
UMLで書いた通りにソースコードを自動生成したいだけ
あとクラス図の関数をクリックすると、
ソースコードの関数の所を編集出来るようになるとなお良し

で、VisualStudio2010とEnterpriseArchitectの組み合わせを試すことにした
414 :
2013/08/31(土) NY:AN:NY.AN
>>413
正直いってそれ意味ねぇから。

当たり前の話するけどさ、
メソッドを自動生成したければ、UMLにメソッドを書かないといけない。
引数を自動生成したければ、UMLに引数を書かないといけない
戻り値を自動生成したければ、UMLに引数を書かないといけない

int foo(int value)

というコードを自動生成するために、
一体UMLでは何回マウスをクリックしなきゃならないのかな?

余計に手間かかってるよね?
415 :
2013/08/31(土) NY:AN:NY.AN
UMLでいくら頑張っても
int foo(int value)
この程度しか生成できないんだ。

ソースコードで書かないといけないのはむしろ
int foo(int value) {
  この部分
}


ソースコードを自動生成するというより
関数定義、C言語いうヘッダファイルの
自動生成ぐらいしか出来ないよ。
416 :
2013/08/31(土) NY:AN:NY.AN
まあがんばってメソッドスタブができましたわーい 止まりだろうな
ただ一度レビュー用の資料作ったのをまたコードに書き写すのが面倒いのはわからんではない
それでもたいした手間では無いが
417 :
2013/08/31(土) NY:AN:NY.AN
なら最初からコード書いて
UMLに変換すればよくね?
418 :
2013/08/31(土) NY:AN:NY.AN
シーケンス図のループや条件分岐を追ったりは出来ない?自動生成も?
419 :
2013/08/31(土) NY:AN:NY.AN
>>417
レビュー通すまえにコード書いてるとお説教って職場は見たことがあるw
420 :
仕様書無しさん
2013/08/31(土) NY:AN:NY.AN
1つ聞きたいんだがそれだと変更があるたびに中身が消えるのか?
中身を新しい方へ手で移植するって事か?
421 :
仕様書無しさん
2013/08/31(土) NY:AN:NY.AN
>407
>ただ図を書くとき、その書き方が 決まっていたほうが楽だろ?
>それだけの話だ。

「UMLは、クソだ!」 と言うと帰ってくる、典型的な反応ですね。
自分だけは判っているけど・・・・みたいな。 (ハイ、ハイ)

君は、一匹狼みたいだから、そうやってスネてれ良いのかも知れないけど

大所帯で、人員も玉石混合状態で、
こんな、ヒネクレた、解釈を加えないと、使えない様な手法は(使えてないけど)、
物件の進行上の障害以外の何者でも無いんですけど・・・・

それでも、朝日新聞的な、レトリックな、印象操作で、
例外的で、イリーガルで、超特殊な、事例の話をち出して、
UMLは、有益だった、これからも有益であり続ける、と言う結論に導かなければ、
いけませんか?
422 :
仕様書無しさん
2013/08/31(土) NY:AN:NY.AN
UMLを見ていると、「バベルの塔」の説話を思い出すね。
「神罰による言葉の混乱 (この場合はドキュメントだが)」 であり、
「空想的で実現不可能な計画」 だな。

UMLのドキュメントを複数人に、分業させて、書かせると、
まず、書く物、粒度、が滅茶苦茶で、使えないよねぇ。
423 :
仕様書無しさん
2013/08/31(土) NY:AN:NY.AN
RUP(ラショナル統一プロセス)も酷かったなぁ。
何故、イテレーション開発なのか?
何故、これで品質が上がるのか、
良〜〜〜〜く読んでったら。

理由と言うか結論が、「僕の経験則」だもんなぁ。ブッ飛んだよ。
424 :
仕様書無しさん
2013/08/31(土) NY:AN:NY.AN
だいたい、Use Case 図の 呪いの藁人形 ( あなたの物件が失敗します様にとの呪いがかっている) を
つかまえて アクター と呼ぶけれど、あれは、アクター理論 でしょう?(それも、かなり歪んだ)

よく判らないけど、Windows の カスタム・コントロール や、
X11 の ウィジェット 等で、実現されていて、GUI の分野に限定すれば、
アクター理論は、成功していると思うんですけど。(踊れと言われれば踊るよねぇ)

でも、それじゃ、、アクター理論の信者は、満足できなんですかね?
全ての問題を アクター 理論で、表現し、実現しないと、いけないんですかね?

だいたい、C:++や、Java 等の、成功していると言われている オブジェクト指向言語では、
言語レベルで、データ構造に対するオブジェクト指向しか使われていない様な状況で、
設計手法として、メッセージ・パッシング を 一番最初に書きなさいというのはどうなんですかね?
425 :
仕様書無しさん
2013/08/31(土) NY:AN:NY.AN
Use Case 図 が、アクター理論 なのかは、不明だが
( だれか、OOSE の著者に問い合わせてくれ )

普通、アクター理論では、アクターは、「踊れ」 と命令される立場なハズなのに、
Use Case 図 は、アクター が、UseCase に命令をだしていて、なんだか、逆だよね。

だれか友達は、いなかったのかな?
こいつ( OOSE )を世に出す前に、恥かしいからヤメようととか、言ってくれる・・・・
426 :
仕様書無しさん
2013/09/01(日) 00:08:40.23
マ板で自演とか勘弁しろ
クソが
427 :
2013/09/01(日) 01:58:35.97
>>418
> シーケンス図のループや条件分岐を追ったりは出来ない?自動生成も?

出来るか出来ないかで言えば出来るよ。

ただ、図を書いてコードを生成するのは手間がかかるだけ。

for(var i = 0; i < array.length; i++) {
 console.log(array[i]);
}

たった3行でかけるループを図にすると
どれだけ作成するのに手間がかかるか。
428 :
仕様書無しさん
2013/09/01(日) 15:16:54.22
手段と目的を履き違えてんな
あと仕事でそういうルールが決まってて自分がルール決める立場に居ないなた文句言うんじゃ言うなクズが
429 :
2013/09/01(日) 15:42:16.08
>>421
まず、UMLは「手法」だという思い込みを直せ。話はそれからだ。
430 :
2013/09/01(日) 19:09:36.72
UMLからコードに変換するという考えが
そもそも間違ってるんだよよね。

UMLはコードから見たら
下書きみたいなもの。
431 :
仕様書無しさん
2013/09/01(日) 21:11:20.49
>429
>まず、UMLは「手法」だという思い込みを直せ。話はそれからだ。

「屏風 (びょうぶ) と、UML は、曲がらなくては、立たない。」

んですよね。 分ります。
432 :
仕様書無しさん
2013/09/01(日) 21:49:24.28
>429
>まず、UMLは「手法」だという思い込みを直せ。話はそれからだ。

それに、UML が、「図の描き方で、手法では無い」 って言うのは、
いったい、誰の意見で、何処に書いて有るんですか?

それは、アンタ の勝手な解釈でしょう?

自分も、同じ様に、解釈する所だけど、
このソフト工学の仮面を被った、安愚楽牧場に、
何時間、無駄にした所で、みな、普通、そう思うんだ?

別に、UMLの本の1行目に、
「これは図の書き方であって、手法ではありません。キリッ」 とか、但し書きで、断ってあれば、
文句は無いが、実際は、そうじゃないだろぅ。

それに、本人に聞いてみたら 「手法です」 とか言うかもしれないだろ (頭オカシイんだから)
433 :
2013/09/01(日) 21:55:54.21
手法であれば、OMT法、Booch法、OOSE/Obectory法、
シュレイヤー/メラー法のように「法」がついてる。

UML法などというものはない。

UMLはUnified Modeling Languageの略
日本語にすると、統一モデリング言語

統一モデリング言語によって統一されたのは、
モデリング”言語”であって、法ではない。

OMT法、Booch法などの手法は統一されていない。
あくまでモデリングするための言語が統一されただけ。

名前の時点でUMLが図の書き方であることは明白。
434 :
仕様書無しさん
2013/09/01(日) 22:03:38.05
>433
>名前の時点でUMLが図の書き方であることは明白。

それじゃ、「UML」 は、「言語」なんですね。
聞いてやるから、喋ってみて下さい。 ハヤく〜〜〜〜!
435 :
2013/09/01(日) 22:08:21.10
何を喋ればいいの?

ここに書いてあることと同じことしか喋らないよ?

逆に君がここに書いていないことを喋ればいいのにw
俺がいくら俺に都合のいい事を喋っても、
お前の意見が認められることがないのはわかるよね?

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

1994年、ラショナルはゼネラル・エレクトリックからジェームズ・ランボーを雇った。
その後同社は今日の2つのオブジェクト指向モデリング技法を生み出すこととなった。
それは、ランボーのオブジェクトモデル化技法(OMT, オブジェクト指向分析 (OOA) の一種)と、
グラディ・ブーチのBooch法(オブジェクト指向設計 (OOD) の一種)である。
ランボーとブーチは共同で彼らの【技法】を統一する作業を開始した。

間もなくイヴァー・ヤコブソンが加わった。オブジェクト指向ソフトウェア工学(OOSE)の開発者である。
ヤコブソンは1995年に自身の会社である Objectory AB が買収されたことにより、
ラショナルに合流した。この3人の方法論者をスリーアミーゴスと呼ぶ。

1996年、ラショナルはあまりにも多様なモデリング言語が存在していると
オブジェクト技術の採用が遅れてしまうと判断し、
彼らの【統合作業をオープンな統一モデリング言語の開発に方向転換した。】
OOPSLA '96 においてオブジェクト技術系の競合企業が集まってこれに関する話し合いが行われ、
ランボーのOMT記法で使われていた四角形でクラスを表す技法がブーチの雲でクラスを表す技法に勝った[1]。
436 :
仕様書無しさん
2013/09/01(日) 22:13:36.19
>435
図の描き方が、何で、「言語」 なんて、名前なんですか?
プログラム言語でも、無いですよね?

やっぱり、UMLの正当性は、ウチ達には、スリー・アミーゴズがいるから、だけなんですよね?

そんなに正しいなら、何で、ラショナル・ソフトウェア 潰れちゃったんですか?
実際のところ、屁のツッパリほども、現実世界では、役に立たなかったからじゃあないんですか?
437 :
2013/09/01(日) 22:22:35.44
値段の問題じゃね?
100万円もするようなソフトをそうそう買える人間は居ない
438 :
仕様書無しさん
2013/09/01(日) 22:53:32.23
>435
「コピペを鵜呑みにしていたら、思わぬ反撃を食らって、動揺しているんですよね。」 
分ります。

> お前の意見が認められることがないのはわかるよね?

あの〜、スレタイ 読めませんでしょうか?

それに、ここは、2ちゃんねる。便所の落書きですから、
世間的に認められるとか、そう言う事は、頓着しないハズの場所なので・・・
439 :
仕様書無しさん
2013/09/01(日) 23:07:49.54
「UML は、オワコン」
「UML は、クソ」
「屏風(びょうぶ)と、UML は、曲がらなければ立たない。」

♪みなさん、ご唱和、ヨロシクお願いしま〜す!
440 :
2013/09/01(日) 23:10:20.17
>>436
つぶれた工務店には必ず大工道具があったってなw
441 :
仕様書無しさん
2013/09/01(日) 23:21:05.67
普通に使って役に立ってるんだが何言ってんだコイツ?
ツールに使われてる臭がめちゃめちゃするな。こういう原理主義者はさっさと現場から退場してもらわないとな。
442 :
2013/09/01(日) 23:45:30.11
>>436
> そんなに正しいなら、何で、ラショナル・ソフトウェア 潰れちゃったんですか?
http://ja.wikipedia.org/wiki/%E3%83%A9%E3%82%B7%E3%83%A7%E3%83%8A%E3%83%AB
http://blogs.itmedia.co.jp/nagap/2012/12/rational-softwa-4766.html
http://www-01.ibm.com/software/jp/rational/
潰れてないじゃん。

お前いっつもそうだな。
何も調べず、自分で思い込みで突っ走る。
443 :
仕様書無しさん
2013/09/01(日) 23:55:24.70
>442
>潰れてないじゃん。

いや、普通に、潰れて、IBM に買収されたんだけど。
日本のラショナル が、IBM の傘下に入るタイミングが少しズレた様な・・・

う〜ん、リアル・タイムの、ネット上のニュースでは、完全に潰れた旨が書いてあったのに、
大本営発表ニュースしか残ってないな。
444 :
2013/09/01(日) 23:57:27.05
買収されたのは潰れたとは言わない。
445 :
2013/09/02(月) 00:00:04.88
UMLも未だに更新されているしな
http://www.omg.org/spec/
> Date-Time Vocabulary DTV business process design formal/2013-08-01

ラショナルのことを持ちだして
一体どういう結論したいのか理解できん

UMLが記法であることの否定を
一切してない
446 :
2013/09/02(月) 00:01:36.84
詭弁の特徴のガイドラインとは、詭弁の特徴をまとめたものである。詭弁のガイドラインと呼ばれることも。
http://dic.nicovideo.jp/a/%E8%A9%AD%E5%BC%81%E3%81%AE%E7%89%B9%E5%BE%B4%E3%81%AE%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3

一見関係ありそうで関係ない話を始める
「ところで、カモノハシが卵を産むのは知っているか?」
「ところで、ラショナルが潰れたのは知っているか?」
447 :
2013/09/02(月) 00:02:48.73
>>446
あー、なるほど。
それだったのかw
448 :
仕様書無しさん
2013/09/02(月) 00:11:02.02
いや〜、確か、何期も赤字を出した挙句の買収だったんだけどね。
もう、ROSE も、買えない事だし。 これ以上、可哀想な、被害者も増えないだろう。

>445
> UMLが記法であることの否定を
>  一 切してない
ハイ、ハイ、今度、何処に、そんな事が書いて有るのか教えてね。
449 :
2013/09/02(月) 00:22:05.02
詭弁♪詭弁♪

いつになったらUMLが記法ではない
証拠を出してくれるのかな?
UMLが記法っていう証拠はとっくに出てるのに。
450 :
仕様書無しさん
2013/09/02(月) 06:20:14.39
> 449
> UMLが記法っていう証拠はとっくに出てるのに。

だから、どこ? 折角だから、勿体ぶらずに教えてよ!

みんなも、聞きたがっているよ。 オマエの脳内ソースの出所を・・・・
451 :
仕様書無しさん
2013/09/02(月) 06:45:00.23
>449
>UMLが記法っていう証拠はとっくに出てるのに。

それから、どうやったら、
OMT や、Booth法 達を (あからさまに手法だよね、これらは)、統一したら、
記法 などと言う、低いレベルに、話が落っこちやうのか、教えてね。

「手法」 を統一したハズのに、実は 「記法」 でしたなんて、
一般庶民の感覚からすると、詐欺だから。
452 :
2013/09/02(月) 07:09:33.43
UMLアンチが必死なスレ
というかUMLの話をしたい人はどこに行けば良いの?
453 :
2013/09/02(月) 08:07:00.19
「UML」そのものは手法じゃない、というだけの話を、
いつまでたっても理解できないバカが詐欺とか言うなw
454 :
仕様書無しさん
2013/09/02(月) 08:29:45.46
そりゃオレオレUML(Undefined Mysterious Language)をドヤ顔で見せられても困るわな。
しかもそれを銀の弾丸の様に薦めてくるが全員ポカンですわ。うるさいからプロジェクトから外されちゃって逆恨みしてUMLは役に立たないドヤァってそりゃないよなwwww
こいつDFDもフローチャートもER図も役に立たないって言うんだろ。原始人に戻れってか?w
455 :
仕様書無しさん
2013/09/02(月) 21:08:20.80
「UML は、オワコン」
「UML は、クソ」
「屏風(びょうぶ)と、UML は、曲がらなければ立たない。」
「UML は、詐欺」
「UML こそ、欺瞞」

♪2つ増えました!みなさん、ご唱和、ヨロシクお願いしま〜す!
456 :
2013/09/03(火) 01:50:53.71
手書きで図示するようなのの整形やら手間を省くための道具
頭のなかの情報を整理したり、コードの可視化に使うことも出来る道具

だいたいそういう感じの認識でいる
知ってて損することでもないし、道具は使ってなんぼ
457 :
2013/09/03(火) 07:38:38.18
UMLは
1.設計前のメモみたいなモン
2.言語ではなく図法

こんな感じ?
458 :
2013/09/03(火) 17:08:30.86
>>457 うへー、おまえ、頭わるいな!
459 :
仕様書無しさん
2013/09/03(火) 22:20:49.80
個人的には、UML の中で、有益な部分など、10% も無いと思っているが、
(下駄を履かせて))仮に 20% が有益で、残りの 80%が、ダメだったとして・・・

 「80% もの、大部分が、ダメ、ダメ じゃないか」 と、

 「まだ、20% も、有益な部分が残っているじゃないか」 は、

同じ事を、指して言っている訳だ。

これが、50%だったとして、相当酷い話だ。
他人に、強要出来るような性質の話では無い。
460 :
仕様書無しさん
2013/09/03(火) 22:22:38.63
>459 間違えた訂正
× これが、50%だったとして、相当酷い話だ。
○ これが、50%だったとしても、相当酷い話だ。
461 :
2013/09/03(火) 22:39:18.47
アルファベットや数字に全角を多用するあたりで技術者としての素性がバレバレwwwww
462 :
仕様書無しさん
2013/09/03(火) 23:21:09.21
オマエが、会社で、「UML、UML」って、連呼する度に、
オマエ、実は、影で、クス、クス 笑われているぞ、
気付いていないのは、オマエだけだ。

「何で、みんな、オレの汚物ェクト嗜好を理解しようとしないんだ〜!」って、
人格に問題があるからじゃ、ないかなぁ〜〜、多分。
463 :
仕様書無しさん
2013/09/03(火) 23:58:35.36
もうさ、少しは、学習しようよ。
UMLを使って、大失敗した物件を、それこそ山の様に見てきたぜ。

巨人がいくらボロ負けしても、長嶋終身名誉監督は、悪くない、
悪いのは、○×ヘッド・コーチだ。みたいな世界だよね。

UMLは、悪くない、失敗したのは、馬鹿なPGが、UML を
正しく書かなかったからだ。

オレ様が担いでいるんだから、間違っている訳無いだろう。
ハッハッハァ〜!
464 :
2013/09/04(水) 02:18:50.43
うちの職場じゃ全角英数を使うやつは人として扱われないな
465 :
2013/09/04(水) 04:37:33.88
今時、UML程度でつまずいてどうすんだってw
466 :
2013/09/04(水) 16:04:22.13
UMLうちの会社では役にたってるけどなあ
467 :
2013/09/04(水) 16:34:19.74
UMLで詳細設計とかやるのはアホ。
設計概略をわかりやすく記したり、
ホワイトボードで設計を話し合ったりするのに使うと役立つ。
UMLは割り切って使うツール。
設計書に書く時も、本筋と関係ない部分の動作はコメントにしてざっくり省略するのがいい。
468 :
仕様書無しさん
2013/09/04(水) 21:27:41.93
>466
>UMLうちの会社では役にたってるけどなあ

って、下のUMLの図13種類を全てフル・ガチで、
書いているわけじゃないんでしょ?

 ・ユースケース図
 ・クラス図
 ・オブジェクト図
 ・パッケージ図
 ・コンポジット構造図
 ・コンポーネント図
 ・配置図
 ・アクティビティ図
 ・シーケンス図
 ・コミュニケーション図
 ・相互作用概要図
 ・タイミング図
 ・ステートマシン図、

これに通常、調査分析、設計、製造、デバッグ の工程がクロスするけど・・・ねぇ。
こう言うの、日本語で、何て言うの、「やってられない?」
469 :
2013/09/05(木) 04:56:20.62
>>468
まさか、全部書かなきゃいけないと思っている?
悪いのはUMLじゃなくて、あんたの頭。
470 :
仕様書無しさん
2013/09/05(木) 23:08:24.29
「UML は、オワコン」
「UML は、クソ」
「屏風(びょうぶ)と、UML は、曲がらなければ立たない。」
「UML は、詐欺」
「UML こそ、欺瞞」
    +
「UML は、他人を見下す道具」 ← NEW!!

>469 のお陰で、また1つ増えてしまいました。
♪みなさん、ご唱和、ヨロシクお願いしま〜す!
471 :
仕様書無しさん
2013/09/05(木) 23:18:56.16
>469
>悪いのはUMLじゃなくて、あんたの頭。

>469 は、アレかな?
他人が、自分と違う解釈を UML に入れると、馬鹿扱いかな? 
世界は、オマエ を中心に回っている訳では無いから。

チョット悪質なので、自己愛製人格障害を患っている可能性が高いな。
きっと、幼い頃の ネグレクト(育児放棄、児童虐待)体験 が原因だろう。

父ちゃんは、アル中で、母ちゃんは、男作って逃げたんだろう?
分っているんだよ。知ってんだよ。何でも、お見通しさ!
472 :
2013/09/06(金) 00:37:21.04
>>471
ここまで被害妄想の激しい人間も珍しいな
473 :
2013/09/06(金) 00:40:34.87
>>468
使いこなしてる人間が居るならそいつに合わせれば良いんじゃね?
474 :
2013/09/06(金) 00:49:29.86
>>469はUMLに限らず道具を道具として利用できない人全般に言えることだと思う
この業界の老害に結構多い
475 :
仕様書無しさん
2013/09/06(金) 22:02:49.67
まさかとは、思うが、

「道具として使いこなしている」≒「クラス図しか描かない」

じゃないだろうな?

アホアホ仕様のUMLとの格闘の末に疲れ果て、
現実解として、もう、「クラス図」しか、書いていない所は多いが、
「疲れ果てた」結果と、「使いこなしてる」が、
やっている事が同じ? んな訳無いよね。

大上段に、家元や、賢者を気取って、
「クラス図」しか書かなくて良いんですよ、
「僕が発見した方法です」って、
言われなくても、もう皆、クラス図しか、書いてないけど。

まあ、まさか、勘違いだとは思うので、
「使いこなしている」派の諸氏は、是非、その優れた方法とやらを
披露してくれたまへ。(出来るモノなら)
476 :
2013/09/06(金) 23:17:10.95
がんばるなあ。
477 :
2013/09/07(土) 05:38:35.01
UMLに良心でも殺されたんじゃね?
478 :
2013/09/07(土) 06:47:34.67
へー、やっぱりクラス図しか書いてないからあんなアホな解釈になるんだな。
道具の文句は、ちゃんと使ってからにしないと、自分が恥かくだけだよ。
479 :
2013/09/07(土) 08:56:20.84
クラス図、コンポーネント図、シーケンス図、ステートチャート図くらいしかまともに使ったことない。

特にユースケース図、本当に使っている奴いんの?
480 :
仕様書無しさん
2013/09/07(土) 16:20:44.54
>>479
プログラミングしかしないと使わないよな。SEが業務分析とかするときに使ってるの見るぜ。
フローチャートの代わりに使ってる奴もたまに居るよな。
481 :
仕様書無しさん
2013/09/07(土) 16:22:14.88
>>480
間違えた。
そりゃアクティビティ図だった。
482 :
2013/09/07(土) 19:20:28.58
ユースケース図は利用シーンを設定するためのものだからな、
使われるのは主に業務分析とかUIデザインあたりだな。
483 :
仕様書無しさん
2013/09/07(土) 21:10:48.05
>>477
>UMLに良心でも殺されたんじゃね?

UMLが殺したモノがあるとしたら、>>477 の両親と、
オブジェクト指向 と、ソフトウエア工学 かな。

何の裏付けも無い、「僕の経験則」 や、「ただ何となく」 が、
標準と名乗って、有益な手法達を駆逐してしまった。
484 :
仕様書無しさん
2013/09/07(土) 21:27:09.18
まあ、末端のPG の目から見たら、

「UMLを使って設計する」 ≒ 「ドキュメントが実質無い様な状態」

と同じに見える事だろう。

 ・それは上流設計だから、お前が見るべきモノでは無い。
 ・そもそも、そんなドキュメントは無い。
 ・誰も見ないので、何ヶ月も、まったく保守されていない。
 ・要求機能仕様と、そのクラス図、全然、合って無いから、見ないほうが良いよ。

 ・実は、UML とは全然関係ない、ドキュメントがある。

 ・そんな暇があるなら、コーディングしろ。


通常は、優秀なPGの何人かが、時間と才能を無駄にする事で、
この 「ドキュメント真空状態」 を何と力づくで、押さえ込むが、

メンバー が ショボ かったり、殆ど初対面同士で、意思の疎通を欠くと、
ひたすら、防戦一方になり、性能未達、工期遅延、完成不能 に、容易く陥る。


「UMLは、デス・マーチ 発生機」?
485 :
2013/09/08(日) 09:50:07.50
それUML関係ないよね
仕事に不満があるのはわかったから上司に直接言えば?
486 :
仕様書無しさん
2013/09/08(日) 17:18:27.36
現場のPGごときが自分の作業範囲を確定出来ないとかレベルが低いですって自己紹介乙
487 :
仕様書無しさん
2013/09/08(日) 17:19:30.70
それをUMLのせいにしようと必死かよ。クズゴミアスペは現場から消えろよ。
488 :
仕様書無しさん
2013/09/08(日) 21:07:36.68
このスレは、分りやすいね。

誰〜れも、まともな、反証も挙げれず、感情的な レス しか帰ってこないところを見ると、
「あぁ〜、図星を付かれて、痛いんだなぁ〜」 と思うね。

まあ、UML 自体が、嘘の上に嘘を付き固めて、矛盾の上に矛盾を塗り込めて、出来ていて、
更に、ご丁寧に、失敗の上に失敗を繰り返した、隠し切れない、実績(?)があるから、
それこそ、本当に、穴だらけ。

弁論(ディベート) の 論題(テーマ) に、こんな物を選んだ日には、
肯定派は、100% 近くの確立で負けるだろう。

今、UML を弁護するには、
「白馬は馬にあらず」 と言う詭弁で、相手を言い負かす位、難しいね。
489 :
仕様書無しさん
2013/09/08(日) 22:54:18.05
なんか、UML信じている人って、マルクス主義 や、共産主義を信じていた、
70年代安保の時代の学生運動家に似ていて、面白いよね。


UML肯定派は、まるで、浅間山荘にまで追い詰められた、連合赤軍みたい。

「革 命 が成功しないのは、オマエの革命戦士としての自覚が足りないからだ〜!」
「UMLが成功しないのは、オマエの S E としての自覚が足りないからだ〜!」


それから、日系移民社会において、太平洋戦争に日本が負けても、信じない
「勝ち組」と呼ばれる人たちが居て、「神国日本が負けるハズは無い」とか言っていたらしい。
アメリカ領のハワイで、終戦後10年しても、まだ居たって言うんだから、凄いなぁ。

だから、オマエらも、後10年は、ガンバレよ!


個人的に興味があるのは、
戦時中の軍国少年は、戦後、大挙して、左翼になったが、
今、UML を担いでる奴らは、UML亡き後、何処へ行くのかなぁ〜〜って言う事。

あぁ、そういえば、ITRONも、何だか、同じ様に、妙に思想っぽかったけど、
ITRON協会も解散して、アイツら、何処に消えたんだろう。
ソフトに変な思想を持ち込んじゃイカンね。
490 :
仕様書無しさん
2013/09/08(日) 23:37:30.88
なんか言った?
491 :
2013/09/08(日) 23:44:19.71
うむ、これはなにも言ってないに等しい長文
492 :
2013/09/09(月) 04:56:05.51
信じるも何も…
言語に過ぎないものを信じるとか嘘とか、あるわけないだろ、バカすぎw
493 :
2013/09/09(月) 07:17:29.98
とうとう壊れたか
494 :
2013/09/09(月) 07:33:11.66
このバカをこのスレから外に出さないでくれw
495 :
仕様書無しさん
2013/09/09(月) 08:53:35.78
UML(Undefined Mysterious Language)は確かに必要無いよな。
意味わからないもんな。
496 :
2013/09/09(月) 19:49:50.81
>>489
言葉は意志を伝えるためにあるんだよ
あなたの言葉には罵声以外に意志を感じられない
虚しくないですか?
497 :
仕様書無しさん
2013/09/10(火) 00:29:55.61
こらこら
キチにマジレスすんなよ
498 :
2013/09/10(火) 00:46:32.23
UML使って書くのはいいけど、
それよりも重要なのは
どの方法論を使うかだと思うな。

UML使ってる人って
方法論は何を使ってるの?
499 :
仕様書無しさん
2013/09/10(火) 23:10:51.36
>>489
>>あなたの言葉には罵声以外に意志を感じられない

いや、罵倒しているんですけど。読んで分りません?


>>虚しくないですか?

このハタ迷惑な標準とやらで、どれだけの人が迷惑したか分っているのか?

変な独自解釈入れれば、イケるとか言っているが、所詮、独自解釈でしょう?
この業界に、入りたての若い人は、こんな変な、独自解釈入れなくちゃ、使えないなんて、分らないよ。
新たな、犠牲者、量産して、どうするの?

自分の気持ちを最優先にして、他人が、苦労したり、挫折したりする、可能性を全く無視ですか、
それは、冷たくは、ないですか?


もう、こんな変な方法論は、一回、お葬式出して、一旦、仕切りなおした方が良いよ。
少なくとも、OMTや、Booch でやっている、頃は、全然、こんな問題無かった。

まるで、明治時代以前の、文言不一致みたいな状態。
読み言葉と、書き言葉が、もう、全然違いますみたいなのは、もう、止めようよ。
500 :
仕様書無しさん
2013/09/11(水) 01:20:30.23
点が多い
うーん
3点
やり直し!
501 :
2013/09/11(水) 03:06:45.02
読みづらいな
502 :
仕様書無しさん
2013/09/11(水) 09:14:24.75
自演乙
503 :
仕様書無しさん
2013/09/11(水) 22:46:26.05
今更、死に体で、オワコンの、UML を担ごうなんて、
相当な情弱か、4月フレッシャーズ新人特集の受け売りだからな。
504 :
仕様書無しさん
2013/09/11(水) 23:09:35.23
じゃあどうやって設計すんの?
505 :
仕様書無しさん
2013/09/11(水) 23:41:03.42
設計なんかしなくていきなり造り出す VB
506 :
2013/09/12(木) 08:11:10.36
犬小屋を作るには設計はいらないが
設計せずにビルを建てるのは無茶だよな
507 :
仕様書無しさん
2013/09/12(木) 09:22:51.75
結局四角形を線で結ぶ何かを書き始めるくらいならUML使えよ…
508 :
2013/09/12(木) 09:43:26.95
結局文句言ってるのはUMLに振り回されてる人でしょ
役に立つ部分だけ採用すればいいだけなのに
509 :
仕様書無しさん
2013/09/12(木) 12:40:59.90
5人のチームで全員が俺様謎表記法だったらどうする?
510 :
仕様書無しさん
2013/09/12(木) 22:37:50.33
>>504
>>じゃあどうやって設計すんの?

個人的な意見を言わせてもらうと、
まともだった、OMT か Booch法 か、
更に、もう、一昔前の、DOA(データ中心分析)で、十分だろう。

分析、設計、製造、デバッグ の各フェース で、何を書かなくてはならないのか、
ハッキリ しているので、精神衛生上、相当、スッキリ する事請け合い。
511 :
2013/09/12(木) 23:04:49.42
>>510
はい、お前は設計経験なしの素人ってことが確定しました。おめでとうございます。

1.ツールと手法を同じレベルで並べるなド素人
2.デバッグはフェーズじゃねえだろ?テストって言いたかったの?このド素人
3.フェースってなに?リアルで使ったことない言葉を背伸びして言ってみたのがバレバレですねド素人
512 :
仕様書無しさん
2013/09/12(木) 23:07:32.95
分り辛いので、ちょっと歴史に例えさせてもらうと、

ヨーロッパで、ギリシャ、ローマ と高い文明が続いて、
その後、中世に、一度、衰退するよね。

ソフトウェアにおいて、更に、最近の話で、信じられないだろうが、あんな感じ。

文明や学問が発達していたのに、宗教と迷信まみれの原始社会に、後退してしまった
UML からは、そんな印象しか受けない、まさしく後退。



良く整備された C言語 でも、個人で取り扱えるのは、数10万行 あたりが限界だった。

それが、OMT/Booch 法 を使って、C++で、個人でも、本気で、数100万行単位で、
取り扱う事が出来た。 本当に、巨大で、複雑なモノが作れるようになったと、スゲー喜んでいた所に、

  ・・・UMLの登場だ。 

ニュー・カマーの諸君は、最初から、UML しか無かった様に見えるかも知れないが、
オールド・カマーの目線からすると、後から出てきたクセに、何だこのゴミは? と写る訳。
513 :
2013/09/12(木) 23:11:33.86
> それが、OMT/Booch 法 を使って、C++で、個人でも、本気で、数100万行単位で、
> 取り扱う事が出来た。 本当に、巨大で、複雑なモノが作れるようになったと、スゲー喜んでいた所に、
>
>   ・・・UMLの登場だ。 

ん? UMLってOMT法やBooch法で使われていた図を
統一しただけのものだよ。

OMT法やBooch法は図が変わっただけで
何も変わってないはずだが?
514 :
仕様書無しさん
2013/09/12(木) 23:23:10.98
>>511
>>はい、お前は設計経験なしの素人ってことが確定しました。

スゲーな、オマエは、僅か十数行の文章を読んだだけで、プログラムの経験値が分るのか?
エスパーじゃねぇの、まるで、ウチの会社じゃ要らねーけど、誰か、雇ったげて〜。

>> 1.2 3
箇条書きにすると、頭が良さそうに見えるね。良かったね。々々。ヨシヨシ。
言葉の粗や、重箱の隅をつつかせると、日本一だね。
じゃあ、今度は、ソフトウェア工学で、反論してみよっか?
515 :
仕様書無しさん
2013/09/12(木) 23:25:51.32
>>513
>>何も変わってないはずだが?

(゚Д゚)ハァ
516 :
仕様書無しさん
2013/09/12(木) 23:34:08.59
>>513
>>何も変わってないはずだが?

しまった、思わず、絶句してしまった。

図をカッパらっただけよ。 
そこは、まるで、中国製の粗悪なデッド・コピーの模造品の様。

なぜ、この部品の、ここの形状は、こうなっているのか? 
とか言う設計ノウハウが、まるまる、ゴソっと、音を立てて、抜け落ちている。
517 :
仕様書無しさん
2013/09/12(木) 23:41:31.01
読みづらい文だなおい
UMLなんて高度なテクノロジーの前に国語(あいうえお)を勉強し直せば?
518 :
2013/09/12(木) 23:52:51.26
>>516
> そこは、まるで、中国製の粗悪なデッド・コピーの模造品の様。
何を言ってるのかさっぱりわからん。

かっぱらうも何も本人じゃん。

http://itpro.nikkeibp.co.jp/word/page/10003184/

> OMT法 米リレーショナル・ソフトウエア社のJames Rumbaugh氏らが開発した。
> 同じくOOA/OOD方法論では代表的なBooch法を開発したGrady Booch氏や
> Objectory法の開発者であるIvar Jacobson氏と共同で
> これら3つの方法論を融合させた新しいOOA/OOD方法論を作成している。

> この統合方法論は「Unified Modeling Language(UML)」という名称で,
> 分析/設計のプロセスを細かく定義するよりはむしろ,
> さまざまなプロセスに使える表記法の確立に重点を置いている。

表記法の確立
519 :
2013/09/13(金) 00:22:08.62
なんかキチが論破された瞬間を見た気がするw
520 :
2013/09/13(金) 04:32:21.78
そもそもランボーもブーチも
「方法論は本に書いてある通りやるんじゃない、
それぞれの事情に応じて自分で改良して実践するもんだ」
って書いてたはずだが、
このスレの例のあの可哀想な人は全然読んでないようだ。
521 :
2013/09/13(金) 08:49:57.63
職場でセンセイって言われるタイプだな
522 :
2013/09/13(金) 19:14:08.88
センスのない人はUML覚える程度の事すら大変らしいな
523 :
2013/09/13(金) 19:21:05.93
アンチUMLおじさん
524 :
2013/09/13(金) 21:31:08.52
しかも論破されてやんのwwww
525 :
仕様書無しさん
2013/09/13(金) 22:53:57.30
>>524
>>しかも論破されてやんの

論破?ハァ?どこが?

UML が、クソ の役にも立たないのは、万人が認める所だろう。
都合の良いコピペで、勝ったとか、論破とか、馬鹿じゃないの?

オマエらは、脳内とか、チラシの裏 だけだから、お気楽に UML を担いでいれば
済んでいるかも知れないが、無責任極まりない。

責任ある立場だったら、効率の悪い方法は、使っちゃいけないの。
売り上げ、工程の進行、労務管理、皆の給料、守らなくちゃいけないモノは沢山ある。

どこを、どう見たって、役に立たないだろう。
526 :
仕様書無しさん
2013/09/13(金) 22:58:23.74
あなたは、どちらの上司に付きますか?

 A.UML 信者。 変な教義や解釈を押し付けてくる。

 B.アンチ UML。 実利優先。正当性?権威? そんなの関係ねー!

まあ、自分のサラリーマン生命や、プライベートな時間を 投げ打ってまでもねぇ。
527 :
2013/09/13(金) 23:13:03.02
>>525, 526

>>518

やっぱり論破されてんじゃんww
声に出して>>518もう一度読めよwww

boochなんて言ってるよwww
528 :
仕様書無しさん
2013/09/13(金) 23:34:55.24
>>527
>>boochなんて言ってるよ

別段、関係無いんじゃない? 特定の個人が何か言ったって。

本当に全然役に立たないんだから。

勝ったとか言うなら、世間の UML 離れ、過疎化 を何とかしてから言いたまえ。

UML を触った事のある人の 90% 以上は、何だこのゴミ、役に立たない。 
と思っているぞ。
529 :
2013/09/13(金) 23:44:08.93
ブーチ法とか誰も使って無いと思います。古すぎますね。OMTとか今時誰が知ってるんですかね?
誰も知らない使えない。その上ツールも無い。まだUMLの方がマシなんじゃないですかね?
そこまで言うならその手法で成果を発表して下さいよ。
今ならGitHubもオープンソースもTwitterもblogも発表する場は星の数ほど有りますか是非そのご自慢の開発手法とやらの効果を見せて下さい。
ま、成果が上がったら認めてあげますよ。
530 :
仕様書無しさん
2013/09/13(金) 23:45:15.57
まっ、UML が、正しいのか、間違っているのか、を決めるのは、結局は、世間だから。

使って役に立ったと思う人の方が多ければ、残るし。
何じゃこれ、と思う人の方が多ければ、消えていくし。

マズい、ラーメン屋が、潰れていくのと、あまり、事情は、変らない。
二度と行かないでしょう? 激マズだったら。
531 :
2013/09/14(土) 00:14:46.83
クソスレいちいち上げんじゃねぇぞ
532 :
2013/09/14(土) 03:16:44.28
自分が使いこなせない=ゴミって思うのは勝手だけど
主張しても同じくゴミのような人からしか同意は得られないと思うよ
533 :
2013/09/14(土) 04:54:01.45
ゴミだゴミだと連呼してるだけじゃ何も言ってないのと同じなのに
いい歳こいてるであろうオッサンが、なぜそんなことにも気付けないのだろう
534 :
2013/09/14(土) 12:24:59.20
UMLが要らないなら何が必要なんだっけ
535 :
2013/09/14(土) 15:34:24.88
UMLの代わりに俺俺記法で
図を書くんだろう?
536 :
2013/09/14(土) 16:25:21.87
エクセルでな
537 :
2013/09/14(土) 17:06:09.73
エクセル方眼紙の好きな連中がゴミなんだろ
538 :
2013/09/14(土) 18:47:05.83
エクセル方眼で俺様表記
見た目はUMLなのに線の意味が全然違うとかな
+の代わりにp_とか書いてあって毎回意味を聞く羽目に

しねwwww
539 :
2013/09/14(土) 18:55:02.19
p_って書いてあるんだから
プライベートのpだろ。
英語ぐらい知ってろよな
540 :
2013/09/14(土) 19:42:38.96
画像を表すpって事ですね!分かります!俺らプログラマーであって大喜利やってんじゃないからなから!残念!!

しかし派遣は瞬間で消えるからいいけどプロパーがそうやってると炎上確定だよな〜…
541 :
2013/09/14(土) 19:50:34.75
VisualStudio2012Ultimateのシーケンス図生成機能って便利だね
542 :
2013/09/14(土) 20:07:31.36
そんな書き方すんのかって意味では役に立つな。
543 :
仕様書無しさん
2013/09/15(日) 17:28:41.92
シーケンス図生成ドヤァ
544 :
2013/09/15(日) 19:29:42.09
道具を道具として使えない奴は猿にも劣るってことだな、ってのがよくわかる良スレだった。おわり。
545 :
仕様書無しさん
2013/09/17(火) 09:34:37.42
あるぇえ〜?不要厨どこ行った?
546 :
2013/09/17(火) 14:01:27.63
厨つっても中坊じゃなくて中年なのがウケる
547 :
2013/09/17(火) 19:34:42.35
そういうのいいから実践的なUMLの素晴らしさを述べてよ
548 :
2013/09/17(火) 21:15:00.11
定番過ぎて腐ったような煽りレス
549 :
仕様書無しさん
2013/09/17(火) 21:22:50.01
>>547
涙拭けよwwwwうぇwwうぇwwwww
550 :
仕様書無しさん
2013/09/20(金) 22:35:55.46
いや、いらないだろ。
100徳ナイフなんて現場じゃ有害なだけ。
551 :
仕様書無しさん
2013/09/21(土) 00:49:33.68
派遣「UMLです」
他「はぁ?」
552 :
2013/09/21(土) 01:59:58.07
551「ドヤッ」
他「はぁ?」
553 :
2013/09/21(土) 08:36:32.79
UMLを100徳ナイフだと評した奴がどこにいる?
>>550 の脳内?
554 :
仕様書無しさん
2013/09/21(土) 09:32:38.31
アスペかテメェは
555 :
仕様書無しさん
2013/09/21(土) 23:52:19.32
実際使えない事から目を反らして人格攻撃なんてUMLが使えない左証だな。
使えるって主張が全部感情論とかpgr
556 :
2013/09/22(日) 00:34:17.03
> アスペかテメェは
↑人格攻撃

> 全部感情論
↑自己紹介
557 :
仕様書無しさん
2013/09/22(日) 10:37:39.76
肯定派は揚げ足しか取れないってもの追加だな
こんな感情論の世界じゃUMLとかいう100徳ナイフで現場が無用の混乱を起こしてるってのも納得だな
558 :
2013/09/22(日) 10:42:25.51
そりゃ、俺様論理なんだから、おまえが納得できるのも当たり前。
おまえの論理が納得できるのは、他に誰もいないけどなw
559 :
仕様書無しさん
2013/09/22(日) 17:09:17.80
>>558
肯定派は揚げ足しか取れないってもの追加だな
こんな感情論の世界じゃUMLとかいう100徳ナイフで現場が無用の混乱を起こしてるってのも納得だな
560 :
2013/09/27(金) 09:18:57.26
あれ?結局必要って結論出ちゃったな
561 :
2013/09/27(金) 11:40:06.31
良かった良かった
562 :
2013/09/27(金) 18:38:39.71
さすがに天下のMicrosoftを敵に回す気は無かったか
563 :
2013/09/27(金) 20:18:41.10
は?
564 :
2013/09/28(土) 02:07:40.24
MicrosoftのvisualstudioがUMLに対応してる事すら知らないの?
565 :
2013/09/28(土) 08:08:14.93
UMLの使われ方全体から見れば、そんなの誤差の範囲内。
566 :
2013/09/30(月) 09:14:56.24
実装レベルで使うのは無意味
設計段階でこんな感じでーってやるのが一番マシ
567 :
2013/09/30(月) 18:10:16.22
>>564
それってどの程度対応してるの?
ラウンドトリップに対応してる?
568 :
2013/09/30(月) 19:24:28.92
UMLはソースコードで記述可能なことを全て表現可能なように設計された言語じゃないし
569 :
2013/09/30(月) 19:36:13.75
ソースで書ける事をUMLで書く位ならさっさとソースを書けばよろしいDRY
570 :
2013/10/27(日) 21:00:40.04
UMLいらない人って設計どうしてるの?
IFの仕様書だけ書いてあとはマによろしくーって感じで流すの?
それとも詳細設計書とかでなに作るか共有してるの?
そうするとどのクラスにどんな機能が実装されるかどうやって表現するの?
まさか表と文章で全部表現するの?
やっぱりせめてドメインモデル図みたいなオーバービュー欲しいよね?
そうしないとみんな勝手に同じような機能作っちゃうよね?
そしたら何かしらの絵を書くよね?
UML欲しいよね?
それともエクセルとかワードで無駄に綺麗な絵を作っちゃうのかな?
それこそ無駄だよね?

受託だと客次第ってのもあるし規模にもよるけど、
ドメインモデル図、ユースケース図(外部IFだけ記載)、クラス図(スケルトンから自動生成)、ステートマシン図はやっぱ使うかなー。
あとはUMLじゃないけどER図あれば大体事足りるかな。
571 :
2013/10/28(月) 03:06:32.17
何言ってんだコイツ
572 :
2013/10/28(月) 09:40:02.65
>>571 スレタイ通りの不勉強自慢乙w
573 :
2013/10/28(月) 18:33:59.34
勉強しても理解できないぐらいに頭が悪いだけなんでね?
574 :
仕様書無しさん
2013/12/23(月) 01:12:30.96
UMLで書いたものをジェネレートしてコードに落とすツールがあるぐらいだから、
まあUMLはあっていいんじゃない?資格もいろいろとありますし。てか、資格手当貰っている。。。
575 :
2013/12/23(月) 02:06:27.81
UMLで書いたものをジェネレートしてコードに落とすことはできない。
せいぜいC言語でいうヘッダファイルが限界。
ヘッダファイルなんてインターフェースでしかない。
関数と変数の定義なんて、コードとは呼べない。
576 :
2013/12/23(月) 09:30:49.05
資格手当もらってるから、あってもいいだと?
恥を知れ
577 :
2013/12/23(月) 12:05:19.39
まだ >>1 が生きてたのかw
578 :
2014/01/09(木) 06:49:29.93
シーケンス図は便利な時もあるが
それを書くソフトがクソすぎ
イライラする
579 :
2014/02/27(木) 13:23:06.67
シーケンス図、アクティビティ図ぐらいは考えをまとめるのに便利なときもあるかも。
580 :
2014/03/01(土) 15:33:45.55
結局タイミングチャートとフローチャートという、元々確立していた図法の焼き直しの奴だけw
581 :
2014/03/02(日) 06:41:37.22
アクティビティ図がフローチャートに見えちゃうアホが実在するんだww
582 :
2014/03/02(日) 11:44:52.52
「焼き直し」という表現が見えないアホが実在するんだwwww
583 :
2014/03/02(日) 16:00:56.33
焼き直しに見えちゃうほど生兵法なんだねーww
584 :
2014/03/02(日) 19:22:52.36
フローチャートには数多くの批判があったけど、
それを踏まえた設計になっていることを具体的に説明できるのかなw
585 :
2014/07/08(火) 22:43:14.64
UML化kkっこおおあああああうぇえええええええ
586 :
仕様書無しさん
2014/11/04(火) 16:04:46.99
他人のプログラムを読むときにクラス図やコミュニケーション図を描いたら見通しが良くなったことがある。
確かに設計で使うのは手間がかかるだけかも
587 :
2014/11/04(火) 20:07:12.12
ユースケース図はなんとかならんか。
人形見せるとユーザーさんが困惑する。
588 :
2014/11/04(火) 20:37:07.16
パワポあたりクリップアートの棒人間でも使えば?
589 :
2014/11/05(水) 21:35:23.73
>ユースケース図はなんとかならんか。
>人形見せるとユーザーさんが困惑する。

客相手に書いているなら役にたたん。誰も見向きもしない
プログラマが 保守のために使って初めて意味を持つ
プログラマがソースを追いかけるという、手間を省くためにある
SEがかいているようなものもいらない。
590 :
2014/11/07(金) 21:24:56.96
ある意味javadocやdoxygenみたいな立ち位置だな
591 :
2014/11/08(土) 06:00:41.02
>>587
艦娘でも貼っとけ
592 :
2014/11/17(月) 22:27:23.88
UML好きな奴ってプログラマを下賤な輩みたく見下してる
593 :
2015/01/24(土) 10:30:51.44
んなこたーない
技術力低いプログラマほどUMLが好きなもんだ
594 :
2015/01/25(日) 00:44:43.94
未だにクラス図の描き方がよくわからん。

インターフェース図に入れたら図がわけわからんくなるし
外したら外したでスカスカになるし。

包含関係もよくわからん。
包含してたらコレクションクラスでもない限り、まず間違いなく依存してるんじゃないの?
なんで矢印が別にあるんだ
595 :
2015/01/25(日) 13:07:34.79
インタフェースは基本的に丸いやつ(アイコン表記?)で書いとけばスッキリするよ
596 :
2015/04/06(月) 18:01:15.26
UMLの解説探すとプログラムコード以外での説明が多い
結局UMLはプログラミング以外に有益
597 :
仕様書無しさん
2015/11/03(火) 10:40:55.78
転職の際は要チェック。
下記の条件が全て当てはまる会社にご注意下さい。

・IT系 in Tokyo
・転職会議で2.5点
・転職会議の「その他>2ch情報」の欄で過去の労基2chスレが表示される
598 :
2015/11/03(火) 11:08:06.92
UMLやら各種モデリング言語の事例とかみると、ほぼ100%組み込み界隈だけど
あっちの方面ではフルに使ってるのかね
599 :
仕様書無しさん
2015/11/03(火) 14:12:13.72
組み込みは全体の仕組みが大事だからなぁ
大規模な物になると機能毎に受け持つ会社が沢山絡むから
記号の意味から教えなくて済むUMLは重宝するんだよ。
600 :
仕様書無しさん
2015/11/03(火) 18:01:41.50
U・M・L!U・M・L! UMA ぢゃないよ U・M・L!
601 :
仕様書無しさん
2015/11/04(水) 09:38:45.80
アニオタイイカゲンニシロ
602 :
2016/02/02(火) 16:40:02.77
(小規模案件を単独か馴染みの人間若干名かとでやっつけるだけの環境にいるなら)
UMLなんていらない
603 :
2016/02/02(火) 18:20:48.18
超亀で>>594に長文レスしたいが、
悩み2点がいずれもクラス図について言及しているとして、

> インターフェース図に入れたら図がわけわからんくなるし
では、インターフェース「を」図に入れたら図がわけわからんくなるし
と言いたかったのかどうか、

> 包含関係もよくわからん。

での「包含」は、依存が話題なので、クラス間の“関係”に係わって、
ソースコースに対象オブジェクトを保持する属性を設けることを意図しているのか、

その変がちょっとわからないなぁと、
超過疎スレを眺め小一時間悩んでみた、と。

もしかすると、インターフェース図というのがコンポーネント図のことで、
その中に表現するパーツやらのことについてなのかもしれん…とも
604 :
2016/02/02(火) 18:24:50.60
明日から今月末までに、UMTPをL1〜L3まで、
OCUPをAdvancedまで受験するので個人的な祈念age
605 :
2016/02/02(火) 21:24:55.35
ソースコースだってよ…ソースコード
最後のコンポーネント図についてはつまりホワイトボックス表現のこと
606 :
仕様書無しさん
2016/02/02(火) 22:25:25.52
インターコースがなんだって?
607 :
仕様書無しさん
2016/02/03(水) 22:25:07.00
実態派遣SEの知的財産と契約料金の搾取助長

相場が下がって迷惑だから年収1,000万円以下のSEは辞めてもらえませんか?

[推定平均生涯収入]
100万/月 3億円5,000万以上(大卒サラリーマン上位 レベル)
90万/月 3億円以上(大卒サラリーマン平均レベル)
80万/月 2億円5,000万以上(大卒サラリーマン下位 レベル、高卒サラリーマン上位レベル)
70万/月 2億円以上(高卒サラリーマン平均レベル)
60万/月 1億円5,000万以上(高卒サラリーマン下位 レベル)
50万/月 1億円以上(フリーターレベル)
40万/月 5,000万以上(パートレベル)

http://labaq.com/archives/51497438.html
608 :
2016/05/16(月) 21:53:19.05
皆さん、UMLは役に立ってますか
609 :
仕様書無しさん
2016/10/07(金) 19:32:00.52
EA13でたらしい
リボンUIって…
610 :
2016/10/15(土) 12:02:05.75
最近はPlant UMLみたいな、コードでUML描くのがメジャーになりつつあるから
UML嫌いの理由としてわりと多そうな、そもそも図をツールで描くのがしんどすぎるっていうのがカバーされるようになるかな?
611 :
2016/10/22(土) 10:41:16.16
どんなに頑張って書いても
それが動くわけじゃないからな
Maxでもつかったほうがマシ
612 :
2016/10/26(水) 12:20:02.38
ステートマシン図で、入場点、退場点による入退場の際、
入退場動作の影響は受けるんだろうか。
613 :
仕様書無しさん
2017/03/15(水) 22:02:57.48
umlのクラス図で質問です。
うまく伝えにくいのですが、2つのクラス間に線がひいてあり、その線の途中から他のクラスに線が引いてあるのはなんて言うのでしょうか?

&#9723;----------&#9723;
|
&#9723;
614 :
2017/03/16(木) 21:55:11.27
日本語を分解して単語のプロパティとか関連とか考えるくせがつくから
メモとるのがうまくなった

説明に役立ったことはない
615 :
2017/03/18(土) 18:27:18.06
統一された規格は海外サプライヤーと仕事するときとかに便利だ
616 :
2017/03/23(木) 12:45:28.49
UMLを極めると、UMLの利点が失われる法則
198KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: