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

**仕様書無しさん** · 2012/06/14(木) 20:58:05.90

UMLと何の関係が

**仕様書無しさん** · 2012/06/14(木) 21:01:43.21

妙な資料作るよりやることあるでしょってこと

**仕様書無しさん** · 2012/06/14(木) 21:06:02.48

ダメな図ばっかり見続けた結果、図といえばダメなもの、という等式ができちゃったらしい

**仕様書無しさん** · 2012/06/14(木) 21:28:27.38

練習しないと絵はうまくならないからね
それと一緒でしょ
形から入るのが悪いとは言わないけどね

**仕様書無しさん** · 2012/06/14(木) 21:38:38.38

自分のために設計煮詰めたいとき、何使って考えるの？
いきなりコーディングとか言うなよ

**仕様書無しさん** · 2012/06/14(木) 21:41:50.78

要求がはっきりしてるなら、コーディングしながら、考えるほうだけど

**仕様書無しさん** · 2012/06/14(木) 21:59:23.68

構造が不要な規模ならそれでいいんじゃないですか

**仕様書無しさん** · 2012/06/14(木) 22:18:26.83

規模がでかいなら、要求を解読するほうがいいんじゃねえか
ま、ものによるけどね、やり方は

**仕様書無しさん** · 2012/06/15(金) 08:09:04.79

解読って。勝手に補間するのがこっちに任されてるならいいけど

**仕様書無しさん** · 2012/06/15(金) 10:05:00.34

プログラムへの変換も出来んのではなかろうか？

**仕様書無しさん** · 2012/06/15(金) 10:20:48.31

要求が曖昧でナイという保証でもあるんかね

**仕様書名無しさん** · 2012/06/15(金) 23:15:18.91

>>361
シグマプロジェクトも無駄じゃなかったといいつづけてる奴らがいるけどね。
参加者の技術的な下地を底上げし、プログラムの構造化、モジュール化に貢献して、オブジェクト指向を定着させる下地を作ったとかなんとか…

なるほどと納得した奴らは騙されるな！
そもそもそれらに日本発の技術は一つも無いぞw

**仕様書無しさん** · 2012/06/15(金) 23:24:01.35

GPIBでネットワークだっけ

**仕様書無しさん** · 2012/06/16(土) 20:45:59.36

「日本発」が偉いならTRONとRubyでも拝んでろw
どこ発の技術だろうと遅々として取り入れない電電ファミリのクソっぷりにはもう飽き飽きだ。

**仕様書無しさん** · 2012/06/16(土) 21:04:35.55

Rubyは認知されてるみたいだけど、オープン系では

**仕様書無しさん** · 2012/06/23(土) 23:06:31.31

RubyはRuby自体じゃなくて
外人が作ったライブラリが認知されてるだけだから微妙な感じ

**仕様書無しさん** · 2012/06/24(日) 07:29:32.73

結局、日本人の作ったものを日本人が認めることができなかった、
と自分で認めちゃったわけだw

**仕様書無しさん** · 2012/06/24(日) 13:14:27.95

まあRubyはRailsを作る環境に選んでもらえなければ
JIS規格化なんて絶対に無かっただろうね

**仕様書無しさん** · 2012/06/24(日) 14:44:03.44

タラレバ定食おいしいです

**仕様書無しさん** · 2012/07/10(火) 18:45:11.45

確かにWeb系なんちゃってJava使いの企業ではいきなりサクラエディタでソース書いてた
設計？ユニットテスト？何言ってんだいいから徹夜で納期に間に合わせろよって感じだった
顧客に渡す資料をパワポで作ってたｗ

**仕様書無しさん** · 2012/08/16(木) 06:55:40.30

APL みたいな言語を今設計したらどういうのができるか？ってことかな

**仕様書無しさん** · 2012/08/16(木) 13:32:24.35

RPGじゃなくて？

**仕様書無しさん** · 2012/10/31(水) 17:17:04.13

体にウォーターフォール開発がしみついてる

**仕様書無しさん** · 2012/11/03(土) 14:45:43.80

無料のUMLライティングツールでいいのない？

**仕様書無しさん** · 2012/11/20(火) 09:01:44.08

クラス図とかシーケンス図って言うといかめしく感じるけど
倉すずとかシーケンすずって書き直すと女の子っぽくて萌えね？

**仕様書無しさん** · 2013/02/20(水) 19:53:13.20

既存のUMLツールって計算式（数学記号込）やグラフ等が入った資料が作りにくいのがなんとも残念。

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

でもまぁ、回路図とかと一緒で、書き始めればそこに設計ノウハウが蓄積されるし、コピペで部分再利用
もできるし、それ程悪くないと思うけどなｗ

**coyajun** · 2013/06/14(金) 01:10:25.88

次の選挙では私と一緒に「橋下徹」と書いて投票しろ
ゴミクズサヨク政権を絶対に拒否する"抵抗"と"拒絶"の意思表示だ
維新の会を蔑ろにしたファシストどもは万死に値する！！！！！

**仕様書無しさん** · 2013/06/14(金) 23:54:33.59

UMLってのはプログラムを作ったことのない馬鹿SEが使う。

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

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

UMLで仕様書を書くなんてママゴト。
何も知らなくても仕様書が書けるんだから。
デスマになるのは当然のこと。

**仕様書無しさん** · 2013/06/15(土) 06:56:33.20

ユースケース図なんて
知らない人が見たら
馬鹿かこいつとか思われそうだし

UMLはへたに実装が混ざっているから駄目。
まだSAとかのほうが良かったが普及しなかったな。

**仕様書無しさん** · 2013/06/23(日) 04:19:54.92

この棒人間って昔子供の頃マンガでよく書いてましたけど・・・
これでお金もらえるんですか？

と言ったら上司にマジ切れされた

**仕様書無しさん** · 2013/08/30(金) NY:AN:NY.AN

ＵＭＬって名前からして、間違っている。

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

小学生の子供に、
「言語でも無いのに、どうして言語って名乗っているの？」
って突っ込まれた、お父さんの気持ちになってお答え下さい。

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

日本人だと判りづらいが、「Use Case」も、直訳すると、「ＣＡＳＥを使え」って言う意味で、
ある種の、催眠術か、サブリミナル効果の類を、狙っているよね。

ＣＡＳＥも個々の事例って意味じゃなくて、ＯＯＳＥって言うＣＡＳＥツールを指しているからね。
最初の、「オブジェクト指向ソフトウェア工学OOSE」って本の時には、そのウチに、コードも吐くからねって、
いかにも素人臭い感じだった。

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

ＯＯＳＥ自体は、ＯＭＴとかＢＯＯＴＨとかと、かけ離れていて、全く似ていなかったのに、
スリー･アミーゴズを、抱き込んで、自分のＯＯＳＥの方をＵＭＬと言う名前で標準にしてしまった。
ＯＯＳＥも、名前を改め、ＲＯＳＥになった。（ＣＡＳＥの暗喩であるのはスグ分るよね）

で、ＲＯＳＥは、素晴らしかったか？
ＮＯどころの話では無い、適切な言葉を選ぶとしたら、ＮＥＶＥＲだろう。

１００万円近くもするソフトなのに、Windows 上で、ＵＮＩＸのエミュレーターで、
（この頃、まだＣｙｇｗｉｎは無かった）、動かしていて、そして良く落ちた。

「こんな程度で、よく人に、ソフトの品質の指導をしようとか思うよなぁ」と言った具合。

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

結局、Rational software も、倒産して、ＩＢＭに買われて、
もはや、ＲＯＳＥは、売ってませんから、買えません。

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

UMLをやってみて特に困ったのは、
分析、設計、製造、デバッグの各工程で、どのドキュメントを
書くべきかの規定が全く無かった事。

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

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

これでは、仕事に成らないので、否応無しにUMLに独自の解釈を加えて、
無理矢理に仕事をしていたが、現場や、個人の判断で、
作成されるドキュメントが、違ってしまうと言う、なんと言う矛盾。

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

まあ、ついぞ、ROSE を仕事で使って、物件が大成功したなんて話は聞いた事が無かったな。
逆の例なら、山ほどあるが・・・

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

Use Case なんて、MS-DOS 時代の１画面１機能と言う特殊な条件下であれば、
何とかなったかも知れないが、
Windows の GUI の設計では、もう半分、アウトで、
LED ３つに、SW ５個で、機能が５０個近くある組み込み機器ｂﾅは、
もｂ､書き様が無かｂﾁた。（後に変ｂﾈ拡張をして頑鋳｣ってはみたが＝E・・）

また、シーケンス図なんで、UI の黎明期に、チープな GUI 部品で、
画面を設計する手法であって、ロクに分析も済んでいない状態で、
UI 以外の設計に用いて、最初に、あんなに縦棒を何本も引いちゃったら、
設計の粒度が不適切になってしまい、死者を累々と量産した。

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

C言語なら、物件が暗礁に乗り上げても、プラス数ヶ月で終わりもするが、
オブジェクト指向の場合、作用として、乗れば早く終るが、
副作用として、反った場合、最悪、終らない。ゼロから書き直した方が、早い場合も出てくる。

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

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

そうじゃ無いだろ。「スリー・アミーゴズ」だって間違うんだよ。
言ってやれ、「UMLはクソ」だって。　スッキリするぞ。

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

スリー・アミーゴズはUMLを書けなんて
ひとことも言ってないだろ。

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

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

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

それだけの話だ。

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

ところで最近は、Grady Booch や Booch法を

BOOTH

と書くのが流行してるのか？

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

ところで、今UMLとソースを一致させたプログラムを作るにはどうすれば良いの？
VisualStudio2012のUltimateは値段が高すぎて手を出せないし

ちなみに言語はC++で

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

UMLとソースは一致しません。

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

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

それでもソースに書かれていないものは
UMLにはできないので、
つまりUMLとソースは一致しません。

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

設計と実装が一致とか意味わからん
何がしたいん？

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

お前らいつまでUML(Unidentified Mysterious Language)の話してんだよ。
さっさとUMLの話しようぜ。

**409** · 2013/08/31(土) NY:AN:NY.AN

UMLで書いた通りにソースコードを自動生成したいだけ
あとクラス図の関数をクリックすると、
ソースコードの関数の所を編集出来るようになるとなお良し

で、VisualStudio2010とEnterpriseArchitectの組み合わせを試すことにした

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

>>413
正直いってそれ意味ねぇから。

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

int foo(int value)

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

余計に手間かかってるよね？

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

UMLでいくら頑張っても
int foo(int value)
この程度しか生成できないんだ。

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

ソースコードを自動生成するというより
関数定義、C言語いうヘッダファイルの
自動生成ぐらいしか出来ないよ。

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

まあがんばってメソッドスタブができましたわーい　止まりだろうな
ただ一度レビュー用の資料作ったのをまたコードに書き写すのが面倒いのはわからんではない
それでもたいした手間では無いが

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

なら最初からコード書いて
UMLに変換すればよくね？

**409** · 2013/08/31(土) NY:AN:NY.AN

シーケンス図のループや条件分岐を追ったりは出来ない？自動生成も？

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

>>417
レビュー通すまえにコード書いてるとお説教って職場は見たことがあるｗ

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

１つ聞きたいんだがそれだと変更があるたびに中身が消えるのか？
中身を新しい方へ手で移植するって事か？

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

>407
>ただ図を書くとき、その書き方が決まっていたほうが楽だろ？
>それだけの話だ。

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

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

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

それでも、朝日新聞的な、レトリックな、印象操作で、
例外的で、イリーガルで、超特殊な、事例の話をち出して、
UMLは、有益だった、これからも有益であり続ける、と言う結論に導かなければ、
いけませんか？

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

UMLを見ていると、「バベルの塔」の説話を思い出すね。
「神罰による言葉の混乱（この場合はドキュメントだが）」であり、
「空想的で実現不可能な計画」だな。

UMLのドキュメントを複数人に、分業させて、書かせると、
まず、書く物、粒度、が滅茶苦茶で、使えないよねぇ。

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

RUP（ラショナル統一プロセス）も酷かったなぁ。
何故、イテレーション開発なのか？
何故、これで品質が上がるのか、
良～～～～く読んでったら。

理由と言うか結論が、「僕の経験則」だもんなぁ。ブッ飛んだよ。

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

だいたい、Use Case 図の呪いの藁人形（あなたの物件が失敗します様にとの呪いがかっている）を
つかまえてアクターと呼ぶけれど、あれは、アクター理論でしょう？（それも、かなり歪んだ）

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

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

だいたい、C:++や、Java 等の、成功していると言われているオブジェクト指向言語では、
言語レベルで、データ構造に対するオブジェクト指向しか使われていない様な状況で、
設計手法として、メッセージ・パッシングを一番最初に書きなさいというのはどうなんですかね？

**仕様書無しさん** · 2013/08/31(土) NY:AN:NY.AN

Use Case　図が、アクター理論なのかは、不明だが
（だれか、OOSE の著者に問い合わせてくれ）

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

だれか友達は、いなかったのかな？
こいつ（ OOSE )を世に出す前に、恥かしいからヤメようととか、言ってくれる・・・・

**仕様書無しさん** · 2013/09/01(日) 00:08:40.23

マ板で自演とか勘弁しろ
クソが

**仕様書無しさん** · 2013/09/01(日) 01:58:35.97

>>418
> シーケンス図のループや条件分岐を追ったりは出来ない？自動生成も？

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

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

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

たった3行でかけるループを図にすると
どれだけ作成するのに手間がかかるか。

**仕様書無しさん** · 2013/09/01(日) 15:16:54.22

手段と目的を履き違えてんな
あと仕事でそういうルールが決まってて自分がルール決める立場に居ないなた文句言うんじゃ言うなクズが

**仕様書無しさん** · 2013/09/01(日) 15:42:16.08

>>421
まず、UMLは「手法」だという思い込みを直せ。話はそれからだ。

**仕様書無しさん** · 2013/09/01(日) 19:09:36.72

UMLからコードに変換するという考えが
そもそも間違ってるんだよよね。

UMLはコードから見たら
下書きみたいなもの。

**仕様書無しさん** · 2013/09/01(日) 21:11:20.49

>429
>まず、UMLは「手法」だという思い込みを直せ。話はそれからだ。

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

んですよね。分ります。

**仕様書無しさん** · 2013/09/01(日) 21:49:24.28

>429
>まず、UMLは「手法」だという思い込みを直せ。話はそれからだ。

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

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

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

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

それに、本人に聞いてみたら「手法です」とか言うかもしれないだろ（頭オカシイんだから）

**仕様書無しさん** · 2013/09/01(日) 21:55:54.21

手法であれば、OMT法、Booch法、OOSE/Obectory法、
シュレイヤー／メラー法のように「法」がついてる。

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

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

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

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

名前の時点でUMLが図の書き方であることは明白。

**仕様書無しさん** · 2013/09/01(日) 22:03:38.05

>433
>名前の時点でUMLが図の書き方であることは明白。

それじゃ、「UML」は、「言語」なんですね。
聞いてやるから、喋ってみて下さい。ハヤく～～～～！

**仕様書無しさん** · 2013/09/01(日) 22:08:21.10

何を喋ればいいの？

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

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

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]。

**仕様書無しさん** · 2013/09/01(日) 22:13:36.19

>435
図の描き方が、何で、「言語」なんて、名前なんですか？
プログラム言語でも、無いですよね？

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

そんなに正しいなら、何で、ラショナル・ソフトウェア潰れちゃったんですか？
実際のところ、屁のツッパリほども、現実世界では、役に立たなかったからじゃあないんですか？

**409** · 2013/09/01(日) 22:22:35.44

値段の問題じゃね？
１００万円もするようなソフトをそうそう買える人間は居ない

**仕様書無しさん** · 2013/09/01(日) 22:53:32.23

>435
「コピペを鵜呑みにしていたら、思わぬ反撃を食らって、動揺しているんですよね。」　
分ります。

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

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

それに、ここは、２ちゃんねる。便所の落書きですから、
世間的に認められるとか、そう言う事は、頓着しないハズの場所なので・・・

**仕様書無しさん** · 2013/09/01(日) 23:07:49.54

「ＵＭＬは、オワコン」
「ＵＭＬは、クソ」
「屏風（びょうぶ）と、ＵＭＬは、曲がらなければ立たない。」

♪みなさん、ご唱和、ヨロシクお願いしま～す！

**仕様書無しさん** · 2013/09/01(日) 23:10:20.17

>>436
つぶれた工務店には必ず大工道具があったってなｗ

**仕様書無しさん** · 2013/09/01(日) 23:21:05.67

普通に使って役に立ってるんだが何言ってんだコイツ？
ツールに使われてる臭がめちゃめちゃするな。こういう原理主義者はさっさと現場から退場してもらわないとな。

**仕様書無しさん** · 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/
潰れてないじゃん。

お前いっつもそうだな。
何も調べず、自分で思い込みで突っ走る。

**仕様書無しさん** · 2013/09/01(日) 23:55:24.70

>442
>潰れてないじゃん。

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

う～ん、リアル・タイムの、ネット上のニュースでは、完全に潰れた旨が書いてあったのに、
大本営発表ニュースしか残ってないな。

**仕様書無しさん** · 2013/09/01(日) 23:57:27.05

買収されたのは潰れたとは言わない。

**仕様書無しさん** · 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が記法であることの否定を
一切してない

**仕様書無しさん** · 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

一見関係ありそうで関係ない話を始める
「ところで、カモノハシが卵を産むのは知っているか？」
「ところで、ラショナルが潰れたのは知っているか？」

**仕様書無しさん** · 2013/09/02(月) 00:02:48.73

>>446
あー、なるほど。
それだったのかｗ

**仕様書無しさん** · 2013/09/02(月) 00:11:02.02

いや～、確か、何期も赤字を出した挙句の買収だったんだけどね。
もう、ＲＯＳＥも、買えない事だし。　これ以上、可哀想な、被害者も増えないだろう。

>445
> UMLが記法であることの否定を
> 　一　切してない
ハイ、ハイ、今度、何処に、そんな事が書いて有るのか教えてね。

**仕様書無しさん** · 2013/09/02(月) 00:22:05.02

詭弁♪詭弁♪

いつになったらUMLが記法ではない
証拠を出してくれるのかな？
UMLが記法っていう証拠はとっくに出てるのに。

**仕様書無しさん** · 2013/09/02(月) 06:20:14.39

> 449
> UMLが記法っていう証拠はとっくに出てるのに。

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

みんなも、聞きたがっているよ。　オマエの脳内ソースの出所を・・・・

**仕様書無しさん** · 2013/09/02(月) 06:45:00.23

>449
>UMLが記法っていう証拠はとっくに出てるのに。

それから、どうやったら、
ＯＭＴや、Ｂｏｏｔｈ法達を（あからさまに手法だよね、これらは）、統一したら、
記法などと言う、低いレベルに、話が落っこちやうのか、教えてね。

「手法」を統一したハズのに、実は「記法」でしたなんて、
一般庶民の感覚からすると、詐欺だから。

**仕様書無しさん** · 2013/09/02(月) 07:09:33.43

UMLアンチが必死なスレ
というかUMLの話をしたい人はどこに行けば良いの？

**仕様書無しさん** · 2013/09/02(月) 08:07:00.19

「UML」そのものは手法じゃない、というだけの話を、
いつまでたっても理解できないバカが詐欺とか言うなw

**仕様書無しさん** · 2013/09/02(月) 08:29:45.46

そりゃオレオレUML(Undefined Mysterious Language)をドヤ顔で見せられても困るわな。
しかもそれを銀の弾丸の様に薦めてくるが全員ポカンですわ。うるさいからプロジェクトから外されちゃって逆恨みしてUMLは役に立たないﾄﾞﾔｧってそりゃないよなwwww
こいつDFDもフローチャートもER図も役に立たないって言うんだろ。原始人に戻れってか？w

**仕様書無しさん** · 2013/09/02(月) 21:08:20.80

「ＵＭＬは、オワコン」
「ＵＭＬは、クソ」
「屏風（びょうぶ）と、ＵＭＬは、曲がらなければ立たない。」
「ＵＭＬは、詐欺」
「ＵＭＬこそ、欺瞞」

♪２つ増えました！みなさん、ご唱和、ヨロシクお願いしま～す！

**仕様書無しさん** · 2013/09/03(火) 01:50:53.71

手書きで図示するようなのの整形やら手間を省くための道具
頭のなかの情報を整理したり、コードの可視化に使うことも出来る道具

だいたいそういう感じの認識でいる
知ってて損することでもないし、道具は使ってなんぼ

**仕様書無しさん** · 2013/09/03(火) 07:38:38.18

ＵＭＬは
1.設計前のメモみたいなモン
2.言語ではなく図法

こんな感じ？

**仕様書無しさん** · 2013/09/03(火) 17:08:30.86

>>457 うへー、おまえ、頭わるいな！

**仕様書無しさん** · 2013/09/03(火) 22:20:49.80

個人的には、UML の中で、有益な部分など、１０％も無いと思っているが、
（下駄を履かせて））仮に２０％が有益で、残りの８０％が、ダメだったとして・・・

　「８０％もの、大部分が、ダメ、ダメじゃないか」　と、

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

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

これが、５０％だったとして、相当酷い話だ。
他人に、強要出来るような性質の話では無い。

**仕様書無しさん** · 2013/09/03(火) 22:22:38.63

>459 間違えた訂正
× これが、５０％だったとして、相当酷い話だ。
○ これが、５０％だったとしても、相当酷い話だ。

**仕様書無しさん** · 2013/09/03(火) 22:39:18.47

アルファベットや数字に全角を多用するあたりで技術者としての素性がバレバレwwwww

**仕様書無しさん** · 2013/09/03(火) 23:21:09.21

オマエが、会社で、「ＵＭＬ、ＵＭＬ」って、連呼する度に、
オマエ、実は、影で、クス、クス笑われているぞ、
気付いていないのは、オマエだけだ。

「何で、みんな、オレの汚物ェクト嗜好を理解しようとしないんだ～！」って、
人格に問題があるからじゃ、ないかなぁ～～、多分。

**仕様書無しさん** · 2013/09/03(火) 23:58:35.36

もうさ、少しは、学習しようよ。
ＵＭＬを使って、大失敗した物件を、それこそ山の様に見てきたぜ。

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

ＵＭＬは、悪くない、失敗したのは、馬鹿なＰＧが、ＵＭＬを
正しく書かなかったからだ。

オレ様が担いでいるんだから、間違っている訳無いだろう。
ハッハッハァ～！

**仕様書無しさん** · 2013/09/04(水) 02:18:50.43

うちの職場じゃ全角英数を使うやつは人として扱われないな

**仕様書無しさん** · 2013/09/04(水) 04:37:33.88

今時、UML程度でつまずいてどうすんだってw

**仕様書無しさん** · 2013/09/04(水) 16:04:22.13

UMLうちの会社では役にたってるけどなあ

**仕様書無しさん** · 2013/09/04(水) 16:34:19.74

UMLで詳細設計とかやるのはアホ。
設計概略をわかりやすく記したり、
ホワイトボードで設計を話し合ったりするのに使うと役立つ。
UMLは割り切って使うツール。
設計書に書く時も、本筋と関係ない部分の動作はコメントにしてざっくり省略するのがいい。

**仕様書無しさん** · 2013/09/04(水) 21:27:41.93

>466
>UMLうちの会社では役にたってるけどなあ

って、下のＵＭＬの図１３種類を全てフル・ガチで、
書いているわけじゃないんでしょ？

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

これに通常、調査分析、設計、製造、デバッグの工程がクロスするけど・・・ねぇ。
こう言うの、日本語で、何て言うの、「やってられない？」

**仕様書無しさん** · 2013/09/05(木) 04:56:20.62

>>468
まさか、全部書かなきゃいけないと思っている？
悪いのはUMLじゃなくて、あんたの頭。

**仕様書無しさん** · 2013/09/05(木) 23:08:24.29

「ＵＭＬは、オワコン」
「ＵＭＬは、クソ」
「屏風（びょうぶ）と、ＵＭＬは、曲がらなければ立たない。」
「ＵＭＬは、詐欺」
「ＵＭＬこそ、欺瞞」
　　　　＋
「ＵＭＬは、他人を見下す道具」　← NEW!!

>469 のお陰で、また１つ増えてしまいました。
♪みなさん、ご唱和、ヨロシクお願いしま～す！