UMLなんていらない
■ このスレッドは過去ログ倉庫に格納されています
メインフレーム一筋の人は「いまどきメインフレーム以外の仕事なんてほとんどない」と言う
「技術書もほとんどはメインフレームだ」とも言う
そういう人にとっては、メインフレーム以外のものは、
視界に入っても全く意識する事もないんだよ
UMLを擁護する人も同じようなものでしょ
世界が狭すぎというか、自分の世界が狭い事の認識ができていない つかさ、本読まないのかな?
UMLはもう普通に使われてるよ。 国内の一部の連中は、基本的に全く情報収集をしないよ。
自分が使っている計算機環境についてすら、全く無知ということすらある。
テンプレをコピーしていじるのが仕事、っていう。 オブジェクト指向でやろうとするとデザインパターンに自由度があり過ぎて、メインフレームみたく暗黙の定石が無いから、毎回UMLで設計してるってことなんだろうが、それって効率悪く無いか?
定石があるものなら定石を使えばいいだけ。
というか、そもそも定石がどんなものかを明確に記述する目的の「言語」なんだが。
それとも172はどんな複雑なものでもかっちり1000行でまとまってる魔法の定石集でも持ってるのか? >>172
それがお前のやり方?
お前のところは効率の悪いやり方してるんだな。
UMLは図を書く時にどれにするかの候補の一つ(だが業界標準)でしかないんだが。
UMLを使うからと言って開発のやり方が決まるわけじゃないんだよ。 「UMLで設計してる」ワロタw
設計するときにUMLで書くのであって
UMLというやり方で設計するのではない
設計するかどうかは先に決めろ。
設計すると決まってから、その書き方にUMLを使うんだよ。
つまり、設計書は設計をする為に書く物では無いってことか。
設計は全て頭の中でやって、すべて終わったら、記録として設計書に残すってことでOK? お客様がUMLで書かれた文書を求めていません。
勝手にUMLを使っても納品物として受け取ってもらえず、金を払ってもらえません。
それどころか、そんな事をしてプロジェクトを故意に遅延させた場合は、
損害賠償を請求されてもおかしくありません。
趣味として習得するなら個人の勝手なので、否定するつもりはありませんが。 >>178
お前は顧客が要求しなかったら
ソースコードも書かないのか?
設計代も要求しないのか?
楽しい馬鹿だなw 情報伝達、意識合わ、設計を詰める、作業の分離、とかそんな感じの用途に使うだろ。
使った方が早くなるから使うのに、どうやって損害賠償請求するんだ… >>178は、全部出来上がってから、余計なUMLを作るという無駄な作業をするタイプの馬鹿。
作業の効率化の為にUMLを使用して、結果成果物として再利用可能なUMLを入れるのが普通の人。 客との契約にないなら、コードを書かないのは常識。
設計は受注したが、コーディングは他社担当のため
一切コードを書く必要がないのは良くあること。
作るなと言われたはずの、UMLを使用した資料作成に、ムダな時間をかけるのは馬鹿のやる事。
費用も時間も限られているのに、なぜムダに使うのか理解できない。
故意にプロジェクトを赤字にしたり、デスマを招くなど、嫌がらせでもしたいのだろうか?
自己満足のためにやるなら個人の勝手だが、業務時間内にはやるな。 たしかに
UMLを使う機会はないわな
技術屋のオナニーとはまさにこのこと
強いて言えばソースからクラス図を生成して納品文書の水増しをするくらいか
いまだに納品物のサイズが、こなした仕事の分量だとみなす風潮は根強い >>182
根本的な所が間違ってる。
UMLを使う、使わないに関係なく設計図を書くかどうかの判断が先にくる。
設計図を書かないのならUMLがでてこないのは当たり前。
誰も設計図を書かないと判断した場面でUMLを使って図をかけなんて言っちゃいない。
絶対書けと言ってると思ってたのでしょ? そこがあんたの一つ目の根本的な間違い。
設計図を書くという選択をしたら、次はどんな記法を使って図を書くか。
社内で記法が確立されているなら、それを使って書けばいい。
誰もUMLで絶対にかけなんて言っちゃいない。UML以外を使ってもいいし、
UMLと他の何かを併用してもいい。手段と目的をごっちゃにするな。
絶対UMLで書けと言ってると思ってたのでしょ? そこがあんたの二つ目の根本的な間違い。
事実として、UMLは世界標準。ソフトウェア業界にいるのなら文字を読むのと同じくらい基礎的な知識。
プロジェクトで使う使わないに関係なく、知っていなければいけないもの。
なぜなら社外情報はUMLで書かれているから、知らなければ読めない。
仕事で使うかどうかでしか判断していない。仕様書、設計書を納品物としてしか見ていない。
読むものであるということを理解していない。そこがあんたの三つ目の根本的な間違い。
IBMで使われてないって、なんか面白いね。Rational Rose って, IBMが販売してるよね。
自社内でも使われて無いツールを年契約数十万出して使う所があるんだろうか。
IBMは大きい会社だからいろんな部署があるんだろうけど。 メインフレーム部門の保守管理部門じゃねぇの?
360や370のアセンブラで書かれたコードをエミュで動かし続けるのが仕事、っていうw UMLの設計書が飛び交ってるプロジェクトって、例外なくトラブルプロジェクトな印象なんだが、気のせいか? ダメだこりゃ
UMLも結局、強行的な推進論者だらけって事ね
有益な点や優れている点もあるはずなのに、過激な支持者ばかりが目立ち、
それを嫌がって離れていく人、近づきたがらない人も多いんだろう どこに強行的な推進論者がいるんだ?
現実を言っているだけだろ。
・UMLが業界標準。(違うというのなら他に変わるものをあげてみ)
・UMLは実際に使われてる。(技術書でUMLが使われている)
UMLに変わるものはないんだから
それ以外のものを使うなんて考えられないだろ。
社内専用の図形は業界標準になることなんて無いし。 強行的なアンチの馬鹿がひとり、
過激な反対意見で暴れていて、
誰もが嫌がって離れていく、誰も近づきたがらない人なのだけど、
本人だけは自分が正論を言っているつもりw UMLも、特定企業の社内規格も、状況に応じて使い分ければそれでいい
自分専用資料なら、その場の思いつきで独自規格を作ってもいい
UMLは無条件で切り捨てられるものではないが、絶対というわけでもない
ただそれだけのこと
くだらねえ UMLの有用性を、具体的なデータで示して欲しい。
例えばUMLを採用した結果、従来より開発コストが10%削減できたとか、
障害件数が5%減ったとか、個人の主観ではなく客観的な数値データはないのかな? 具体的なデータねぇ。
技術書の何%でUMLが使われていて、
残りの何%でUML以外の図が使われているとか
だせばいいのか?
UML以外の図って何か知らんが。 UMLで認識を共有出来る人に対して、UMLを使わずに情報を伝達した場合の時間のロスを数値化したいの? 関係者全員がUML読めてソフトの動作を理解できるようになったら
バラ色になるんじゃね? オブジェクト指向でプログラミングしていれば、前提知識レベルだけどな。
確かに銀の弾丸じゃないけど、武器にはなる。武器は使い方次第。
UMLなんて勉強するほどのものじゃないから、解らないとするとおそらくはオブジェクト指向の考え方ができていないと思う。
一年目の新人だって、クラス図渡したら実装してくれる。
それともなんだ、スケルトン書いてフローチャートとか書いて欲しいのか?
文句言ってるヤツはどういう情報伝達がお望みなんだ? UMLを使うの反対は、UML以外の図を使うということ。
UMLを使うの反対は、設計をしない。設計図を書かない。ということではない
UMLを使わないと言っているやつだって、それなりの規模なら
設計はするだろ? そのときの設計図を何で書くか。 UMLに何を期待するかで、意見が分かれると思う。
UMLを図を現す1手段だと考えれば、それ程不満はない。
UMLを使えば、皆が設計や分析がうまく行ってそれこそバラ色の開発が行える万能ツールと思っているなら、それは違うと思う。 UMLのMLはモデリング言語
設計や分析の話は関係ない。 >>202
UMLで設計すれば薔薇色…?
誰もそんな意見行っていないぞ…
一生懸命そういう事にしようとしてるやつがちらほらいるが。 >>203-204 のような、使い所が限られてるって思ってるなら問題ないと思う。
ただし、UMLを設計/分析のツール考えている人達もいる。
豆蔵では以下のようなセミナーやってる。
「UMLによるオブジェクト指向分析・設計演習」
http://www.mamezou.com/training/OOAD1.html
こんな本も出てる
実践UML 第3版 オブジェクト指向分析設計と反復型開発入門
このスレでも、設計って言葉が何度も出て来た。 >>198
プログラム作成に関わらない人は、こんなヘンテコな記号読まない、書かない、従って、勉強する可能性ゼロ。
つまり、たどり着けない桃源郷だなwww プログラム作成ができない奴が設計ができるわけない。
要件定義もできるわけない。勘違い君は死ねばよい。 そうじゃなくて、プログラム作成と設計に関わらない人もいるでしょ。
具体的には使う人とか。
そういう人はこんなヘンテコな記号見たくないわけ。 MVCのビューだけしかわかりません、って人でしょ。
そういう人は使うだけの人で、作ることには関わらない人だよね。
つまり >>198 の「関係者」には入らないと思うんだな。
米を食べる人と、米を作る人、みたいに。 >>205
逆に聞きたいんだが、
UMLを使わないオブジェクト指向分析・設計なんて
今時あるのか? オブジェクト指向分析・設計するのに
UMLじゃないものを使って記述するなんてまずない。 なことない。
C++のクラスヘッダー書きながらクラス設計なんてフツー。
そのときDoxgenで、UML出すかもしれないが、それは超オマケ。 >>212
記述っていうのは、ドキュメントファイルに
図形として書くって意味だよ。
もともと設計書を書かない(ソースコードしかない)
そういうプロジェクトがあるのは知ってる。
だけど、今はその話はしていない。
設計書を書く(出力する)プロジェクトは普通にあるだろ?
そういうプロジェクトでオブジェクト指向分析・設計をして
各ドキュメントに、どのモデリング言語を使うかって話。
今は普通はUMLを使う。
実際にDoxgenもUMLを使ってるしね。読めないと。
Doxgenなどのツールが、どこぞの社内専用モデリング言語に
対応してるわけがないわけで。 UMLがもたらす世界を夢見つつ今日もVB6の巨大システムと戦う UMLは何かをもたらすもんじゃないよ。
ただの記号だ。
世界標準だからどこでも使うってだけ。 90年代末にExcelで作ったクラス定義書を今も現役で使用。
客から指定がない限りは、それが当時からの社内標準だ。
定義を書き終われば、VBAでC++かJavaのコードの雛形を生成できる。
VB.NETとC#に対応できるよう拡張したバージョンもあり、
正規版ではないが、実用上問題がないので使われてる。
Delhiにも対応しようと言ってる信者もいるが、もうDelphi案件はないので、無視されてるな。
従来から実績のあるものを、必要に応じて拡張しつつ使い続け、
それで何も問題がないため、世界標準といえどもUMLの出番はなし。 世界標準ほど胡散臭いものがない
ローカルルールほど長期に渡って多用され続け実績を積み重ねる 昔はOMTだとかBOOCHとかの図があった。
OMTはUMLによく似たもの、BOOCHはきっちりとした図というよりも
手書きを意識した一見ラフな図の書き方だった。
説得力はあったが、実学から離れた、机の上だけの理想論にも感じられた。
UMLもその延長だろ? >>219
図の書き方と
設計方法の区別をつけなよ
(嘲笑) >>218
ローカルルールが通用しない相手に負けたひきこもり乙
世界に通用しない自称「実績」w
>>219
> 実学から離れた、机の上だけの理想論
構造化プログラミングやオブジェクト指向を、そう言って退けてきたバカの後を
追って消えて行きたいなら好きにすればいいと思うよ。 TH図というのもあって、客の提案で開発に導入した事もあった。
日本人が考案したもので、一見するとクラス図を簡略化したようにも
ER図を大幅拡張したような図にも見えた。
全体的な業務の流れを表現するだけでなく、そこからクラスやデータベースの設計にも使え、
クラスの概念がない言語、データベースではなくファイル仕様の作成にも使えるとのことだった。
高い金を払い、専門のコンサルタントとも契約した上での導入だった。
結局、システムをおおよそ俯瞰できるだけで、実開発にはほぼ無益。
理屈上は様々な図のいい所取りの規格だが、それだけのものだった。
いわゆる、自称コンサルタントの自己満足。
時間も金も無駄になり、黒字が見込めたはずのプロジェクトが、デスマ、大赤字になった。
身をもって悪例を学んだと言う点では、有益だっただろうか。
UMLもそれと大差ない。
せいぜい、積極的に導入し、思う存分赤字を垂れ流してほしい。
世界標準への適合が最優先なのだから、利益など考慮に値しないだろう。
そうしている間に、世界標準など一切無視しているプロジェクトが、黒字を達成しているのさ。 80年代と大差ない仕事をやり続けている部署の方が地道に稼いでるな
仕事が急増する事もないが、仕事が全くなくなる事もない
時代遅れだと言われても、稼いでいるのは事実だ Unfortunate Morbid Language
痛々しい病的言語 だからUMLはただの図の書き方であって
黒字とか赤字とか関係無い話だってばw
設計をしないってやり方もあるが、
設計はするだろう? 設計して図を書くだろう?
その時どんな図を書くのさ。自分で考案するのか?
汎用的に使える図(UML)が定義されてるんだから
それを使えばいいだろう。
設計ツールみてもUML図が登録されていることはあるが、
自分で考案した図なんか登録されてないぞ。 >>227
頭で設計してコードを書くんだろ。
自分一人でしか仕事できないヤツの典型。 >>222とか>>225はそもそも設計してないんじゃない?
そりゃUMLだろうとなんだろうと、工数が増えるのは当たり前 仕様は頭の中にあるってヤツの典型だよなー。
UMLが最高のモデリング言語なんて誰もいっていない。
お前の頭から仕様を外に出すための一つの手段だ 。
ていうか、UMLごときを使えないヤツが開発やる事自体が、この仕事がいかに舐められているかを表しているよな。 そしてそういうレベルの人間を大量投入してどうにかこうにかやってきて、
ついにどうにもならなくなって国が終わりかけております。
どうしたらいいんですかね本当に。勉強しろ、と怒鳴る? 十年遅いけど、大学教育を改革すればいいんじゃないかなぁ。
まともにコンピュータサイエンス教えてる大学が無いよねぇ。
時代に合ってない。 unholy maggot language
汚れたウジ虫言語 情報処理技術者検定試験をいくつか整理して、新たにコンピュータサイエンス学科の
3年次修了程度を想定した共通試験制度を作るとかかなぁ。 UMLで人妻と出会える!
サクラは一切使わない世界標準! 世界標準のUMLで痔が治りました
ありがとうございました 趣味娯楽の多様化により若者のUML離れが深刻化し
各社とも販売戦略の見直しを求められています。 やっとUMLが方法論ではなくて
ただの記号って理解したようだw
だからくだらない話を始めたんだろ? 共通言語は人類永遠の夢
バベルの塔が崩れて言葉が通じなくなったんじゃなくて
言葉が通じてなかったから欠陥工事でバベルの塔が崩れたのだよ 意味はわからなくてよいので、カタカナ語やアルファべット数文字の略語を連呼すれば
最新のイメージ、技術が高いようなイメージを持たれ、受注獲得に繋がる
有益性や成功例を提示しなくても、世界標準という言葉を使われると誰も反論できなくなる
どんな無意味なものでも、世界標準と呼ばれるものを切って捨てるには、
新規に世界標準と認められる規格を作り上げ、対案とするしかない
そこまでコストをかけるのは無駄なため、何の考えもなく右へ倣えで世界標準とやらを採用し、デスマを招く
それでも世界標準と言う言葉には魅力があるため、
書籍、資格試験、セミナー等の需要は絶えない
どれだけ失敗例を積み重ねても、カネになる以上は、決してやめない
UMLを採用せず成功した例があっても、ローカルルール、世界に通用しない等と批判し、
またもや世界標準という言葉の魔力に頼る >>250
論点ずれすぎ
そんなにUMLが憎いのか 意味はわからなくてよいので、カタカナ語やアルファべット数文字の略語を連呼すれば
最新のイメージ、技術が高いようなイメージを持たれ、受注獲得に繋がる
有益性や成功例を提示しなくても、世界標準という言葉を使われると誰も反論できなくなる
どんな無意味なものでも、世界標準と呼ばれるものを切って捨てるには、
新規に世界標準と認められる規格を作り上げ、対案とするしかない
そこまでコストをかけるのは無駄なため、何の考えもなく右へ倣えで世界標準とやらを採用し、デスマを招く
それでも世界標準と言う言葉には魅力があるため、
書籍、資格試験、セミナー等の需要は絶えない
どれだけ失敗例を積み重ねても、カネになる以上は、決してやめない
Rubyを採用せず成功した例があっても、ローカルルール、世界に通用しない等と批判し、
またもや世界標準という言葉の魔力に頼る
まあ無くても何も困ることないよなUML
あると教育コストがかかって困るけど 独自記法でやってきたとこがUMLに転換したら
いままで作ってきた独自記法のドキュメントはどうするんだろうね? >>258
記法のマニュアル。
UMLとの対応表をつけておけば良い。 >>257
だよな。
独自記法の教育コストがかかった上に
どっちみちUMLだって知らなきゃモグリだし、
選択肢は
・独自記法+UML
・UML
この2つしか無いよね。 いかれたことに、19世紀の日本の田舎みたいな、共通語を話す奴はのけもの、
方言こそ共通基盤、みたいな組織がいまだはびこってるのが日本という国だからな。 みんなが使ってるから何がいいのかわかんないけど僕も使う!
のほうが日本らしいけどな >>262
それは「僕」の選択理由が日本らしいのであって、
「みんな」は関係無いでしょw 開発者にとっては、UMLだろうが独自記法だろうが読むのは難しいことではない。
UMLは、開発者以外(例えば開発の依頼主)も図が理解できて、打ち合わせ等で仕様の確認ができるという用途が考えられていた。
開発者以外がUMLを理解できれば、仕様の誤解による戻り工数が減るはずというのが書き方を統一するUMLの狙い。
でも実際は、開発者以外がUMLを理解しないので、その利点が無いのが問題。 なお、開発者以外が、独自記法を理解できる可能性は
もっとないので、>>264の書き込みは無視して良い。 図の描き方を統一すれば仕様の誤解が減るとするUMLのアプローチ自体が失敗したんだと思う。
そこは、ラピッドプロトタイピングとか別の方法が有効なのだろう。 >>266
それはUMLと関係ない話をしてる。
図の書き方を統一しても使用の誤解が減らないのであれば
それは社内独自記法であっても、同じ事だ。
ラピッドプロトタイピングはUMLとは別のもの。
ラピッドプロトタイピングでもUMLを使うことはある。 やっぱ独自記法でよくね?
UMLも素人が見ても理解不能な程度にわかりにくい図なんだし ■ このスレッドは過去ログ倉庫に格納されています