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
語るスレです。興味がない人は書き込まないようお願いいたします。
# U言語
=============
Point ----|> Shape
-------------
- x: double
- y: double
-------------
+ move(dx: double, dy: double): void
=============
# 擬似コード例
class Point : Shape {
property dx = x
property dy = y
method move()
}
どうでもいい。
クラス図以外の話をしようぜ。
多分 >>1 はデザパタなんて UML 推進派のでっちあげでそんなもん不要とか言うんだろうが。
日本語でしゃべれ
じゃあ、お前がUMLを日本語に変換してくれ。
甲、乙は丙を継承し・・・とかやるんだろ？ｗ
なに言ってんだこいつ
しかし解説用とか議論用ツールと割り切って、
重要でないメンバや関連線をスパスパっと
省いて、
資料に図を添付したりホワイトボードに
描いたりするには最強のツール。
シーケンス図なんかタイミングや順序が複雑で
図解があったほうがいいなって時だけ使えばいいし、
ステートチャート図も状態が複雑なやつだけ
図解すればいい。
状態が2つしかないのにステートチャートを
描いたりしてたら、UML意味あるの？
って疑問が出るのは当然。
UMLって学ぶ価値あるかな？
UMLっていうのはいろんなモデリングをひっくるめた名称だからね
趣味グラマだったらそのうち５種類くらいしか使わないと思う
象形文字みたいな記号並べてスカスカの資料大量に作ってたのはなんだったのか…
俺が入るところはいきなりコーディングするやつばっかりだ
地図記号統合みたいな話だろ。
推進していたのは、統合させるためであって
統合が完了すれば、推進する必要がなくなるのは当たり前。
それと使うかどうかは別の話で統合してしまったあとは、
普通に使ってる。
フレームワーク部分以外で複雑なクラス関連をプログラマが理解する必要のあるプロジェクトなんて炎上確実だよ。
お前はUMLといったらクラス図しか知らないように見えるな。
クラス図はUMLで一番役立たずのものだよ。
それだけみて判断してるお前ってｗ
じゃあ、クラス図以外から
コード生成してくれるものを教えてください。
クラス図は単なるコードのサブセットに過ぎず、
コードから生成できるから必要ないのです。
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でなまじ図にするよりわかりやすいと見るか、わかりにくいと見るか
# 人によって意見は分かれる
女の子classに性別propertyは必要か?
俺は組込だから、オブジェクト指向すら怪しいが
一応コンストラクタで性別受け取ってないって部分でカバーしてるんだろうが、
それならpropertyという表現が適切かどうかという(ry
せいぜい、個人レベルのメモ程度の用途で、UMLっぽいのを書くことがある程度。
顧客に提出しても、たいていは意味不明な図だとしか思ってもらえないため、提出資料としての価値がない。
社内限定で使うにしても、内部資料に時間・コストをかけるわけにはいかず、
結局は簡略化したコードや、日本語の文書で書く事になる。
理路整然と体系だっているのはいいが
真面目に作ると枚数もかさむし、重要な部分とそうで無い部分が並列に扱われるから
実際業務で扱う作り手、読み手からしたら
机上の空論感が半端ない。
UMLを考えたのは学者ではありません。
実用のために作られたものです。
クソ素人が
中身を見る事なんて無いのに、ソースから自動的にクラス図の生成をやってる所がある程度だ。
いまだに、納品物の量がこなした仕事の量だと思い込んでいる取引先もあるので、
納品物水増し程度には役立つ。
見かけないだろうなｗ
どんな底辺会社ｗ
完全にIT業界の黒歴史だと思うんだけどね。
そして、わからない奴は永遠に取り残されたわけだw マシン語があれば無敵とか、
構造化なんて一時的なブームとか信じてた人たちみたいに。
設計書の一部として添付しても、レビュー時に「なんじゃこりゃ？」と言われ
結局削除するはめになる。
PGやらSEやらはUMLを理解していても、取引先の担当者が理解していない以上は、
まさに「なんじゃこりゃ？」な図でしかないんだ。
お前は、UMLは自分たちが使うものって
考えが全くないんだなｗ
共通的な書式である必要がないからな。
伝わりづらいとこだけあれば十分だし、それ以外は蛇足でしかない。
おいおい、オレオレフレームワークが
なぜダメか知ってるだろ？
UMLを使うと
・世界共通だから、ネット・書籍等の図も読めるようになる。
・世界共通だから、新たに人を雇っても（その人がUMLを理解してるのなら）教育の必要がなくなる
・すでに用意されているものだから、独自に書式をつくらなくてよい。
独自の書式にメリットはない。
何のために独自にするのさ。
あえて、違う書式を使う理由がないよ。
（人間辞めるときはすぐ辞めるから）
逆に教育の必要性というデメリットは
回避不可能。
新たに雇う人＝新入社員
新入社員でUMLが分かってるヤツなんて
居ないから結局教育コストは減らない。
大手の顧客情シスはコボラー集団だしw
それは大手だけ。
今の世の中その考えは楽観的すぎだし、
会社に将来をされないように気をつけてね。
大手も中堅も、大抵は社内書式として、図の書き方等を独自に決めてるよ。
誰かがトップダウン的に決めたケースもあるし、長年のノウハウ蓄積の結果、
ボトムアップ的に決まったケースもある。
中小企業の場合だと、大手の実績のある手法を拝借する事もある。
そうやってきた企業にとっては、UMLなんてのは後から出てきたものでしかない。
自社に好都合なものが既にあるのに、わざわざUMLを新規に採用する必要がない。
使うのは、取引先から求められた場合のみ。
日本企業は新しいものは取り入れても、今を捨てて新しいものに完全に置き換えることは嫌うから。
B版の用紙に縦書きするのが「蓄積型思考」なのか？
ただのバカだろ、それ単に。
予算が足りないからできませんなんてのは言い訳にならないから、今あるものをつぎはぎで使うことになる。
年金とか銀行とかのシステムがいい例。
他人が吹っ飛ぶだけなら綺麗な花火だね、で済むからな
言い訳はいらないからｗ
ヘタすると、22世紀まで生き残ってる可能性も否定できない。
時代遅れだと言われつつもCOBOLを使い続けた会社が
100年以上の実績を持つ貴重な資産を持つ事になる。
もちろんその頃には、JavaだのVBだのC++だのは消滅して忘れ去られている。
そんな短寿命のものに手を出し続け、その度に更新を繰り返し続けた会社は、
ろくに蓄積もなく、何度でも同じようなシステムを作り直し続ける。
そりゃあ、業界全体のシェアから見たら、全盛期の10%も生き残ってなくて、それでもなお
>>65 みたいな狂信者がいるんだから、最後の 1% はそれぐらい長生きするだろうねぇw
現役のソースコード量としては、10%どころじゃない。
どれだけコボルが稼働していようと、眼中にないものは眼中にない
移行が完全完了する頃には、最も古いコードは20年や30年以上前のもので、
旧式言語を排除したつもりなのに、新規開発に使用した言語も既に
旧式化している事だろう。
新しいCOBOLがあることももしかして知らない？
新世代のCOBOLが作られても、ついていけるコボラーがどれだけいるのか？
ついていける奴と、ついてこれない奴、がいるだけなんだよなw
どうせ30年後には、新世代COBOLではなくなってる。
最新のものが登場したからと言って採用し続けると、
多数の世代の言語が混在し、保守困難になる。
古代の言語に統一されている方がまだマシだ。
古代のハードウェア、古代のOSを使い続ける自由は、ネットワークセキュリティが問題に
なる以前のプラットフォームにしか存在しないぞ？
あるとすれば、サイバーノーガード戦法で世界中のさらし者になる自由ぐらいだ。
内部犯行や、従業員を装って内部に侵入するケースがない限りは、
攻撃を受ける事は考えられない。
だから10年以上前のソフトウェアを、セキュリティパッチも当てずに
何の問題もなく使い続けていたりする。
シーケンス図つける羽目になったことはあるよ。泣きたくなった。
>>73
昔からの奴を要件定義からやりなおすのも難儀だからなあ。
今のまま引きずっても仕様がないといえば仕様がない。
とりあえずlambdaかevalできればもうなんでもいいよ、漏れは。
フローチャートの再来であるUMLをなんとか滅ぼそう
もちろんなんとなく図で把握できればいいし、
下手すりゃ客に見せることもあるので正式なユースケース技法じゃ書かないけど。
クラス図？なにそれ。美味しいの？
すると、たいてい1オブジェクトに処理が集中するんで、そこで責務の話をすると通じやすい。
頭の医者にかかったほうが…
受験料をぼったくるための資格なんだから当然の事。
実はあれって有用性ゼロで、ただのぼったくりじゃないのか？と思う人が増えたら、
UMLに替わるものを作り、今度はそれの資格の受験料でぼったくるさ。
合格基準と、実用性が乖離している資格が大杉。
自腹で書籍を購入して学習した俺はバカでしたよ。
あれから何年たっても、どこの案件でも、使う機会は一切なし。
UMLの使用を提案しても、相手にされる事はない。
自社で受注した案件でも、他社の下請け案件でも、UMLと言う言葉すら登場しない。
他の事に金と時間を使うべきだった。
普及しなかった原因のひとつにはオープンソースは普及しても、オープンドキュメントが広まらなかったせいだと考えてる。
Unifiedの部分が「分かる人は分かる」であっては、どうしようもない。
ちなみに俺は初めてUMLを知った時、「ついにコーディングレスの時代が来たか…」と思った。当然幻想だった。
もっとパッと見て理解できるようになったら普及するんじゃね
自分さえわかればいいので、完全に自己流の図だ。
そうじゃなければ個人がネタで作ったC言語およびその派生言語がここまで流行ることはなかっただろう。
>>92 はグローバル変数だけしかなくて、関数定義すらもない言語でも、一生使ってればいいよ。
企画段階から自称頭のいいヤツら大勢集まって、考えたものはダメってこと。
一人の天才が自己完結させた物の方が、シンプルで分かりやすい。
だた天才は意外とポカやらかすから最小限の欠点のみ凡人が外堀埋めて完成させる必要があるけどね。
Pascalについてはどう説明してくれるのか楽しみだ
派生言語のデルファイが一時期流行ったのもGUIが手軽にできるVB以外の唯一の選択子だったから。
この主張に照らしてどうか聞いてるんだが。
でもObject Pascalなんて知ってる人はごく少数派。
結局、拡張や保守に難があり、消えていった。
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
ホワイトカラー・エグゼプション (681)
偽装請負会社の社長は人格異常さ (450)
誰でもできるITテスター☆技術者時給で稼ぐスレ (327)
プロが薦めるキーボード Part2 (921)
社内失業～企業に捨てられたﾌﾟﾛｸﾞﾗﾏｰ (355)
受託開発より自社開発の方がよくね？ (257)
--log9.info------------------
甲子園で印象に残るホームラン (427)
がんばれ鎌倉学園！古豪復活 (837)
関東のシニア・ボーイズ進路 Part22 (989)
☆★健大高崎野球部☆★PART3 (284)
今治西高校応援スレPart27 (483)
【アゴ・ゴリラ】横浜高校part170【出入り禁止】 (341)
◆◇岡山◇◆関西高校応援スレ49 (452)
石川県の高校野球part61 (461)
近畿の高校野球263 (782)
■■浦和学院野球部応援スレ Part35■■ (570)
埼玉の高校野球について語ってみるか★218 (651)
校名がカッコいい高校part？ (121)
鹿児島実応援スレ (666)
夏の甲子園出場回数全国№1☆北海高校35回目 (872)
広島県の高校野球を語れ91 (462)
徳島県の高校野球45 (708)
--log55.com------------------
★2ch.scは何故失敗したのか
★クロール批判要望スレ
★削ジェンヌに文句ある人集合
★迷惑行為報告担当 - 小さな親切募集中 2
★2ch.scへの要望スレ Part3
★かっこう観測所
★スレ立て人キャップ
★2ch.scニュース系板観測所