UML皆でお勉強しよ♪

　 Λ＿Λ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　お勉強しよ♪
　（　　　　）　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜ ｜　|
　（_＿）＿）

しねーよ。＞UML
氏ねよ。>>1
−−−−−−−−−−−−−−終了−−−−−−−−−−−−−−
以後はsage進行で。

UMLってなんだよ

オブジェクト指向の表記方法です

正確にUMLに沿ってはないが、それモドキなやつは書くぞ。
ほとんど静的関係図だけで、ときどきシナリオぐらいだけど。
書かなきゃ、後での仕様変更やプログラムの複雑さのスケーラビリティに
影響がでる。

>>3 Unified Modeling Language

>>5
UMLっていっても、1から10まで全部教科書どおりに採用なんて
しないし、ばかばかしいと思う四。使えるところから使うし、
自分のシステムにとって不要なところはガンガンはしょる。

しょせん道具だし。

でも道具なのでこれから使うでしょう
.NET=UMLになるかな

XPしながらUMLをどう使うかが課題かな。

↑ 知ってる単語を並べただけ。

XP->ソースがドキュメント
UML->ソース以外に図を描け

ってわけで、明らかに対立してるように思えるが。
Kent BeckもUML使わんって言ってたし。

両立するとしたらソース<->UMLを
完全自動で同期取るツールがある場合のみ。

つーか、ほんとにXPやってんのか？

＞両立するとしたらソース<->UMLを
＞完全自動で同期取るツールがある場合のみ。

重いー。

XP燃え。燃えるぜ！やらせろ！誰か！

XP萌え。萌えるぜ！俺とぺあプログラミングやろうぜ！男性不可！

XPで必ず異性とのペアリングが良いということになれば、
一気にこの手法が人気になったりして。

マジな話、異性だと大抵は、野郎同士より多少生産性が
良くなりそうな気がするが。自分だけでしょか？

ペアを強要され、断ったらクビにされたといって
プロジェクトリーダーが訴えられるに一票。

つーか、1みたいに腐った絵文字かきまくるやつ誰よ？
なおか気分わるくなるよ、こんなのみていると
匿名掲示板だからってふざけていいのか？

　 Λ＿Λ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　うん。ふざけていいんだよ♪
　（　　　　）　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜ ｜　|
　（_＿）＿）

　 Λ＿Λ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　うん。ふざけていいんだよ♪
　（　　　　）　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜ ｜　|
　（_＿）＿）

ｼﾞｻｸｼﾞｴﾝﾃﾞｼﾀ

上流工程で働くにはＵＭＬもいいかな。
それみてプログラマがプログラムしてくれればいいんだけど。

私も賛成、というか、すでに（まともな）学校じゃそのようになっている
ようですね。ちなみにＣはもう省いてもよしって感じですね。

スレ違いでした。スマン。

本当にふざけスレになったらしい。

UML は Rose で書きたい。
Visio はもう嫌。

Excelでクラス図、状態遷移図描いてますが、
なにか文句ありますか？

>>25
えらい！！

>>25
Rationalは高いなぁ...
フリーの使って我慢。

>>25
テンプレートくだされ。

27です
25へではなく24でした。
ごめんなさい。

>>24
Visioってクラス数が多くなると
途端に重くならない？

とくにカットアンドペーストがなぜか重い。

>>30
重くなります。
そして飛びやすくなります。
ときどき突然死します。

それより関連の線が変な方向に回り込むのがムカツキます。
状態遷移図でネストした状態を１枚の図に書けないし。
こんなのUML1.x準拠じゃねぇ！

Roseはお試し版を試してみましたが、かなり楽チンでした。
特にシーケンス図は、Visio がクソなだけに感動します。
Visio だとメッセージを流れの途中に入れるのがたいへんですから。
手で書くのと比べたら 100倍 マシですけどね。

>>31
Visio2000(だっけ？)でですか？
私はそれより前のバージョンですが、やっぱ重いですね。
Roseを個人購入ですか？
（フリーでいいのないのかな？

UMLの表記がいつまでたっても覚えられません。
なのでテキトーに書く。

手で書くとき、集約の矢印のひし形って書きづらくねえ？
かってに○にしちゃおっと。

>>34
テンプレート使ってかきませう

UMLって分析工程でさえも、
ツールがないとやっとれんような...
手書きじゃ効率悪し...
つーことで、フリーのツールを見つけみた。
argouml.tigris.org

テ……テンプレートって穴の空いた定規のこと？
そんなの使うくらいだったらvisioで書くよ〜

......。ネタか？
Template is a form, mold, or pattern used as a guide to making something.

あぁ、読み違い。。。スマソ。

Visual Modeler使ってますけど。ＶＢ、ＶＣのソース吐いてくれるんで。
参考書だしてるの今んとこオージス総研と翔泳社だけだね（日本は）。

COBOLも近い将来UMLが使えないと設計・分析ができなくなるようです。
次期COBOLはオブジェクト指向になるらしいし。

>>31
Visioってだれが使っても不安定だったのね。

>>32
私はVisio2000以前のVisioから使ってました。
＃つまりMSに買収される前のVisio

「Visio2000になれば少しはマシになるのかなー」
とちょっと期待していたんだけど，根本的な仕様は
変更されなかったようです。不安定なのは相変わらず。

ただ着眼点は面白いアプリケーションなので
今後に期待。

Pure Java 製 UML ツール (フリーの評価版あり)

http://www.magicdraw.com/

結構重いのが難点だが Visio や Rose より使いやすかった。

いつのまにかまともになってるなぁ。

フリーのUMLツール
http://www.catkk.co.jp/~ando/milk/u-ml/
使ってないので出来は分りません

中途半端にUMLかじっただけで、仕様書もろくに見ないで自己流の
滅茶苦茶なUMLモドキを書く人っていない？
そういうのが同じプロジェクト内にいると迷惑なんだよね。
なんのための標準規格か分ってないのかね。
そういうのに限って、自分がその仕様のメリットや仕様自体を理解
できていないだけなのにUMLに文句つけまくったりして、自分の書く
自己流UMLモドキの方が優れていると思い込んでいたりするから始末に
追えない
普段のそいつの行動やスキルから、単に覚えたり本を見たりするのが
面倒なだけの怠け癖を正当化しようとしているだけだって、周りには
バレているんだけど本人には自覚症状が無いんだよね

>自己流の滅茶苦茶なUMLモドキ
を具体的に説明してよ、話のﾈﾀになるからさ。

>47
つうか、あれをどうやったらアレンジできるんだ？
そのままつかうのがいちばん簡単だと思うが。

なんかUMLツールの評価をしてる
http://www.jeckle.de/umltools.htm
ドイツ語でほとんど意味不明だが

自明なところや、自分達に関連の薄いところはハショルことは
あるよ。

>>49
そいうえばこのスレにも約一名ほどいるぞ。
○にしたらOMTと間違えるからやめとけ。>>34

44のツールを今インストールしているのだが使用許諾が「きょかのさんせいする」で
選択可能なオプションが「さんせいする」「さんせいしない」だ。

すげーローカライズだ。

44のツールMagicDrawはなかなか使いやすいね。

ひまなんで、ひやかします。

>>55
どうぞ。冷やかしでも有益な情報提供でも、アラシ以外は歓迎でしょう。きっと。

>>54
バージョン3.6？

>>52
人に渡すときはちゃんと書くよ。
っていうか清書するならvisioで書くし。
まあ、今オレの周りに他にわかる人いないからそんな機会ないけどね。

単なる思考アイテムとしてみると
ひし形は確実に不合理だろ。
まあ、そういうときは実際は○すら書かないけどね、
文脈でわかるから。

>>59
なんでもええのでは？

うん実はなんでもいい。
でもそれなりに合わせといたほうが
清書するときは楽ですなあ。
方法論とかも参考になるしねえ。

とこう

>44のツールを今インストールしているのだが使用許諾が「きょかのさんせいする」で
>選択可能なオプションが「さんせいする」「さんせいしない」だ。

使ってたの１年前の英語版です。今日見たら日本語を選択出来るみたい。
早速 3.6 を DL してみたら、爆笑してしまったよ。漢字が全然無い。
キッドピクスってお子茶間お絵描きツールがあったけど、そんな感じに
なってました。

ファイルのチューサーちゅうのダイアロックをちゅうぜつする - Abort file chooser dialog
ちょっとのぞく - Look in
かんせんとかんじるテーマ - Look and Feel Themes

あまりに笑えるんで英語表示にして使ってます。
日本語のプロパティファイル探してみます。

とりあえず、ユースケース図をかけるようになりました。

>>53
おれもつかってみた。
日本語翻訳がおもしろい。

多分、カタコトの日本語が出来る奴なんかに依頼したんだろうなぁ。このツールは
俺が使ったUML記述ツールとしては、一番使いやすい。他にもっと使いやすいのが
教えてくれ。

MagicDrawはいくらなのだ？

さぁ？

UMLモデリングのエッセンス―標準オブジ
ェクトモデリング言語入門

はどうなのよ?

>>68
まだかってねーよ

U-MLもつかえるよ。学習程度には。

>>66 > MagicDrawはいくらなのだ？

http://www.magicdraw.com の左上の Shop に行くと
MagicDraw UML Professional Edition Version 3.6i
が $499.00 だそうな。

マトモな日本語にしてやろうとパッケージを開いてみたが、
どうやらメニュー等はクラスの中らしい。

右上やった。鬱

□<-

http://www.jeckle.de/umltools.htm
全部使って評価してくれる人柱募集(W

U-ML使ってる。VC++のソース付き出来たからバグ報告したんだけど、
作者が忙しくてバグ対応できないんだわ。
んで、将来的に一から作り直すつもりなんだと。

いつになるかわからんものを待てないし、
将来作り直されるものをチマチマ直してもしゃーないし、
誰か俺と一緒にDelphiあたりに移植しない？
Javaでもいいけど、GUIツールは重くなっちゃうからなあ。

つーことはwsbuilderではつくらないのね<思いのやだ
kylix or BCBがいいな。

あ、kylix or Delphiってことか...

　

Visio2000でクラス図を書いたが、プロパティを開けるクラスと
そうでないクラスがあるのはナゼ？

　

そういう人が設計やっている下でPGやると苦労する。
とゆーか、その設計で自分でコーディングしろといいたい。

>>81

47に描写されているような人に関して言っているのか、
47に(書いた人に)対して言っているのか不明瞭な指し方だね。
そのタイトルだけでは。

なるほど、書法の微妙な独り善がりは問題だ。

>>82
だからUMLなんですけどね。
きっととんがった環境なんでしょう。
Uの丸みがとれてVariableになっちゃって、
VMLになっちゃってるんだろうな。

さがりすぎたので

age

ホビーレベルだとＵＭＬ使わないけど、
クラス図は他人にクラス構造伝えるのに便利だから使ってるよん。

ステートチャートの質問です。
今仕事で作っているチャートがうまくまとまらないのです。

あるオブジェクトにはＡとＢの２つの状態があります。
またそれと平行してaとbの状態があります。
あわせて都合４つの状態があります（実際はもっと複雑です）。
そしてこれらは平行して遷移するため状態のネストはできません。
これを普通に書くととてもごちゃごちゃしてしまいます。

こういう場合、確か「憂鬱なプログラマの〜」では、
Ａ←→Ｂとa←→bを別のチャートとしてわけてしまうように書かれていたと思います。
これはとてもいいアイデアだと思うのですが、
しかし今回のオブジェクトは、AかBかでa←→bの系統のチャートに影響が出ます。
これらの影響も図示したいので、別のチャートに分けることはうまくありません。

いまいち判りにくいかもしれませんが、
どなたかヒントを下さい。

A+a,A+b,B+a,B+bという4つの状態を持つと考えれば、A、Bの
状態内にそれぞれa、bを入れ子にすればいいんじゃないですか?
確かに冗長だけど。

なんか優良スレに近づいているので、あげとこう

>>87
平行する状態数のすべての組み合わせが４つくらいですむなら
>>88の方法が一番簡単そうだね。
ただ平行する状態がそれぞれ３〜４個より多くなるとすぐ破綻しそう
条件付きの状態遷移の書き方もたしかあったから
無理せずそれつかえばいいんじゃないの？
「憂鬱なプログラマの〜」の例でも
「ＣＤが挿入されている状態のときにPlayボタンが押されたら演奏中に遷移」
みたいなのがあったような記憶がある。

>>88　>>90
入れ子にするのはすぐに思いついたのですが、
かえって複雑に入り混じってしまいます。
>>90さんの言うとおりです。

今はA←→Bの系統の遷移図を書いて、
a、b はフラグということにして、
遷移のゲート条件に書くことにしました。

これは実は最初に試した方法で、あまりすっきりしないのですが、
一日中こねくりまわしてなんとか見やすい図になりました。
根本的な解決ではないですが……。
とにかくありがとうございました。

シルバー受けたら97点だった・・（涙
いまいち納得いかん。。

あげときます。

Rose使っているが、操作性悪いぞｺﾞﾙｧ　ソート指定してもソートされなかったり、
ファイル開きなおしたらソート前の状態になったり。
それとユースケースとかのオブジェクトが複数選択できないのが辛いぞ。
とりあえずサクサク作ってからパッケージに分けようとすると、その操作で
死にそうになる。

>>68
難しい。俺にはこの本からエッセンスを吸収することは出来なかったにょ。

Visio2000のUMLステンシル、バージョンアップしないのかな。
シーケンス図のイベント順が１つづつしか移動できないとか、
ステートチャートの遷移がネストできないとか、
ステートチャートのイベント名を編集できないとか、
C++出力時にコンストラクタ・デストラクタが出せないとか、
直して欲しいところが山ほどあるのに。
誰もマイクロソフトに文句を言わないのかなぁ。

>>96
Visio2000てマイクロソフトだったの？
例によってまた買収でもされたのか？
VisualStudioにRoseのほうのサブセット版がついてたような気がする

>Visio2000てマイクロソフトだったの？
>例によってまた買収でもされたのか？

そうですよ。結構前の話ですけど。

>VisualStudioにRoseのほうのサブセット版がついてたような気がする

Visual Modelerですね。

MolipでUML描けるようになったね。

UMA!?

関連クラス(点線で関連付けるやつ)と3項関連の使い分けが、よく分かりません。
どういう場合にどっちを使ったら良いのでしょう?

ガイシュツかもしれませんが
参考になるURLを教えてくださいま

１００超えました。
このスレつくってよかったです。

　 Λ＿Λ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　お勉強しよ♪
　（　　　　）　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜ ｜　|
　（_＿）＿）

このスレみて勉強しようと決意しました。
けど、何をプログラムするネタにしようか悩む、
というかネタがないっす。

いずれ実戦で使えるように、
理論をお勉強したいと思います・・・

>105
車とかテレビとかを要素機能に分解してモデリングするといい練習になるかも。
答えの見当も付くからUMLの表記理解もしやすいし。

UML的な表現方法はソフトウエア以外でもとっても有効。
仮にUMLが廃れても、この手のダイアグラムには慣れとくべきでしょうね。
ちょっとだけ先輩の社会人より。

個人できるUMLシルバー用の学習ってある？

OGISの試験やったことないから何とも言えないけど、目に付く物体・現象すべてが
ドメインになり得るはずだからと考えて物見るようにしてますね。
でも、個人的にはユ−スケ−スを突っ込んでみたいと思う今日このごろ。

>105
UMLやるといろいろいい傾向が生まれます。
VBAでちょろっと書くのにも目に見えてスッキリ書けるようになるし、その他業務も
同様にスッキリ扱えるようになった。実装言語の前に覚えてもいいんじゃないかと思
うくらいです。これは特定言語に依存しないメリットかも。。。？
で、106のように書いたんだけどね。

U-MLが行方不明age

プロ倉ミグの書類すべてマシンで管理しているから
手書きでUMLするのはいやだなあ。

誰かオプソで作ってくれ。
ギコUMLとか。

UMLの書籍を買う前に、さわりだけでも勉強したいので
それ系の役に立つWebページを教えてくださいよお。

おねがいします。

>>109
UNIXならDiaで書けないこともないんだが。GTK+アプリなので、
移植できるかもしれないね。
http://www.lysator.liu.se/~alla/dia/

Molipで図だけはかけるよ。

　 Λ＿Λ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　最初の頃より雰囲気よくなったね
　（　　　　）　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜ ｜　|
　（_＿）＿）

>110
オ−ジス総研のペ−ジにいろいろあるよ。
あと、本ならRational日本のサイトに紹介がある。

algo/UMLはどうよ?

http://argouml.tigris.org/

ＯＯの世界の話で何だけど、UMLの概念はVBでも確かに有効だよ。
インタ−フェイスを嫌でも考えるようになるからモジュ−ルが洗練されてくる。
つまり、処理の考え方が鍛えられる。
だから”ＯＯをやる”と構えなくても勉強する価値はある。
.NETにもつながる概念だし。。。。
間違ってもイベント内に処理系書くようなことはしなくなるよ。

これから勉強するなら、Boochの”UMLユ−ザ−ガイド”（ピアソン）を手元に置いとけばいい。
あと、VBに特化してると言う意味で”VBプログラマのためのUML”(SE)もわかりやすい。
MartinFowlerの本はその後でないと意味が解らなくて誤解してしまう可能性あり。
そしてそのあとにGoFパタ−ンにハマろう。

MagicDraw、日本語ちゃんと表示されるようになったみたい。
面白い表現見れなくて残念だけど。。

http://www.magicdraw.com

>>111
移植ってwinへですか？
ならば既に有ったような＆使ったことあるような記憶が。
どこでgetしたんだったか完璧忘れ。ごめん。

ただDia自体の操作体系で、ちょっといやだなと思う面もあった。
矢印が四角に接続するでしょ。あの接続の場所の融通が
きかないってのがちょっと。その面はRose系(MSVCに吸収合併
された奴を触ったことが)には負けてる。
あ。半年くらい前の話。その後改善されてるのかな…

あ。DiaのUMLって、マクロ(正式名称知らない)でしたっけ。
じゃあマクロを直せば良い…のかな…

>>120
それってフリーなの？

>>121
ソースも付いてる。
http://www.gnome.org/gnome-office/dia.shtml

MagicDrawなおったんか、
再度DLしてみっか。

あったあった。俺が以前見つけたのって、ここ。
http://hans.breuer.org/dia/
＃それにしてもうわさ通りGoogle恐るべし。

蛇足だけど>>122の和訳は
http://www.jp.gnome.org/gnome-office/dia.html

これ日本語使えるの？
tgifみたいで懐かしいや。

Visicoか

GNU/GPLなものがでてきたとたんに良スレだな。

GIMPが必要なのね。

>>128
GIMPは要らぬ。
あの頁から手繰れるライブラリ(dll)類を
diaのbinディレクトリにぶちこむだけで動いた。
GtkとかXMLとかのライブラリらしい。
蛇足だがそれらをぶちこんだdia総サイズは5Mくらいだった。

＃GIMPもDiaもGtkに依存している、ということ。
＃DiaがGIMPに依存してるわけじゃない。

日本語。あれとは別に日本語パッチを
見たことがあるんだけど、それはunix版で、
win版+日本語ってのは見たことない。
またしても半年前知識なんでご免。今は有るかも。
つーか無かったら誰かやってね(^^;
まぁ日本語なしでも行ける気もするけど。
＃つーかMENUとかはどうでもよくて、欲しいのは日本語入力かも。
あるいはlinuxかなんかでヤルか。

改めて感想：
「保存データを圧縮」はオフったほうがきもちいい。
XMLそのまんまで保存されるんで、冗長ではあるが、
エディタとかsed(笑)とかでいじれるようになるので重宝。

>>129
ウィンドウズ版の日本語化パッチはなさそう...
Linux版つかうことにします。

Molipでもいいんだけど印刷/PDFなら

XMLがJavaやC++へのスケルトンと
内部設計書の自動化に多いに役に立つ／たった。
仕様書工房みたいのだれかつくらんかな。

マジックドローは遅いパチョコンだと遅くてたまらん。

マジックドローって3.6i/3.6SP1を使えばよいの？

MagicDraw, 漏れはPC新しくしたので、も一回ダウンロードしたよ。
バージョンは4.1Professional Demo version. 日本語がマトモになってたよ。

>>133
情報ありがとう

マジック絵描き、日本語マトモになったけど、やっぱ重いよう。

制御しかやったことのないドキュンだから、色々参考になったよ。
身近にあるツールと言えばVisualModelerなんだけど、
フリーでも結構いいものがあるんだな。
とりあえずあげとくよ。

UML、今後のために勉強しておくか・・・
昔オブジェクト指向なんて全く知らなかった頃
プログラミングしようとして挫折した「モノポリー」なんて
題材としては少々大きいかも知れないけどいいよね?

もうちょっと小さい内容で具体的なものがあればいいんだけど・・・
ま、がんばってみます。

なにごとも地道に。

マジックドロー早速インストールしてみました。
メニューとかには日本語はＯＫだったけど、
モデル要素内の記述した日本語が□□□□って感じで化けてしまい
表示・印刷されないという現象が起きてしまいました。
OS WIN98SEです。

どなたかヘルプ！！

Diaにしてみろ

ライセンスキー入れろって？？？
デモ版なのに？？？
どうすりゃいーの教えてください。お願いします。

おっと下げちった。すんまそん。おせーて。

分かりました。
本家の方から落したのを使ったら表示されるようになりました。
付属のをつかったらダメってことだったのね♪

MagicDrawUML key is sent to you by e-mail.
って書いてあったのね。ごめん

>>144
あわてんぼ。

あわちんぼ

今月号のＤＢマガジンにRoseの評価版が付録だねぇ。

>>147
またあの評価版だろ？
FAXでキーをもらって、１ヶ月しか使えない奴。

10年、20年後はプログラマーがUMLのような抽象性の高い言語を使って
AIにコードを書かせるようになるんでしょうか？

意見を聞きたいです。

>>149
脳細胞シミュレーションによる人工知能によりプログラマ不要

>>148
そうだったのかぁ

Magic Draw、クラス名には日本語がちゃんとでるのに、
メソッド名が文字化けする、、、
うちの環境だけなのかなぁ。

あるユースケースがあって、それを中断する動作って
別のユースケースと考えるべき？　それともそのユースケースの
一部？

>>153
ユースケースのActor同士に関連を定義できる、とか
参考書に書いてあったような気がします。
まだ全然勉強できてないんで怪しいですけど。

それを使えば表現できるでしょうか？

ユ−スケ−スの粒度とかによっても答えは変わるんじゃないかなあ？
先が細かくなりそうなら、そのユ−スケ−スは早い時期に分割しちゃうかもしれない。

>>154
　あ、そうか。中断は別のアクターでもできますね。
　ということは、別のユースケースにしないといけないのかな？

　もしくは、「そのユースケースを開始したアクターにしか中断
できなかったら、そのユースケースの一部。別のアクターにも中断
処理が許されているなら、それは別ユースケースにするべき」かな？

>>155
　ユースケースの分割って、どういうときにするもんなんですか？

age

「連載初歩からのUML」
http://www.atmarkit.co.jp/fjava/rensai/uml01/uml01.html

>>156
人によって色々な意見があるとは思うけれど、汎化の匂いを感じた時とかに
考えることが多いかも。それでクラスの抽出が楽になったこともあったよ。
逆にクラスにしたら予想以上にデカいことに気づいてバラしたこともある。

この辺は扱うソフトウエアの問題領域や性格に振り回されるような気がする。
自分も勉強中なので明確な解答はまだ持っていないけど、とりあえずは”ユ−スケ−ス
の要素”をイメ−ジしながらブツブツやってます。

>>159
ユースケースの汎化ってUML1.3でなくなったんじゃなかったっけ？
「クラスにしたら予想以上にデカい」って、ユースケースを丸ごと
クラスにしたの？　それって根本的に間違ってない？

>>159
ヤマハのオブジェクトなんとか推進委員だかのなんだかの
話にそっくりだなぁ。抽象したりバラしたり...

>ユースケースを丸ごとクラスにしたの？
違う違う、そんなことしないよ。

ユースケースって、プログラム上では何になるのかな。

Java関係の参考書って、UML使われてるね。
UMLはJava使いには必須？

箱と線をつなぎあわせたUMLみたいなものって、
お客サンとのコミュニケーションにほんとに役立つか疑問が呈されて
おりますね。
高度10000mからのシステムのビューでしかないようなもの。
具体的なユーザーストーリーも大事、ということには同意かな。

UMLの話題では余り出てこないけど、シナリオってのがなかったっけ？

これは道具だから、心酔召されるな。
お客とのコミュニケーションよりも
元請下請間のコミュニケーションに重宝するとおもう。
頭固い年食った決定権をもつ人々には
フロントーページだったかで書いたシナリオの具体図がよかろうて。

UMLってどんどん複雑になってる気がする。
おいらみたいなドキュンぷろぐらまーにゃ怖くて手をだせないよ。
もっと簡単にならんもんかね。

>>168
必要なところだけ使えばいいジャン。

UMLは必須だと思うけどね。
うちは会社もUMLだし、お客さんもどこもだいたいUML。
実際問題、UML知らないと生きていけない。
実感としては役に立つ！けどね。

>>170
会社どこ。転職しよっかな。

>>167
　道具に心酔するってもアリだと思うけどね。
過信しちゃいけないのはわかってるけど。

>>171
　確かに募集してるけどね＜コンサルタント
　ＯＯを分析からできて、Javaがかけて、できればCORBAが使える
とよい。C++は必須じゃないけど、できた方が本人としては楽だと
思う。あと、海外の仕事が多いからTOEIC800以上ないとちょっと
キビシイかも。どかな。

MagicDrawで他人が書いたJavaソースコードのクラス図を書かせると
一目瞭然だなぁ。

1.初めにてけとーにソースコーディング
2.デモ
3.仕様決定
4.MagicDrawでクラス図にして汎化を試みる
5.またソース直す
6.2へ戻る

こんなんはだめか

　ところで、CaseツールでTogether使っている人っていない？
http://www.togethersoft.com/
　JavaのコードとUMLのクラス図を言ったり来たりできる優れもの。
しかもタダのバージョンもある。
　英語が苦手で上のバージョンでナニできるかイマイチわからない
のだー。使ってる人、教えて！

>>173
TOEICはOKだけど、OOを分析から、ってのが修行たりん
おいらにはまだ無理かも。Java,CORBA,C++はふつーに
使えるよん。なんか、最近どろくさく速度重視、というか、
そうでもなくて、オープンソース系活用して納期短縮しましょ、
ってなわけでCで書く仕事してっからOOな言語の仕事はうらやましいな。

ただ、これでようやく3年目だしまだプログラマーやってたいな。
紺猿って何年くらい経験してからなるのがいいと思う？
おいら新卒とか経験浅いこんさるは信じてない。

>>176
　あ、３年目か。それじゃちょっと厳しいなぁ。いくら技術が
あってもやっぱり若いヤツの言うことなんか聞きたかねえ、って
お客さんがやっぱり日本には多いからねえ……
　でもTOEICがＯＫ、Java、Ｃ＋＋、CORBAできるってすごいねえ。
なかなかそんな人いないよ。あなたの未来はメチャメチャ
輝いていると見た！！
　年が若いのがホントに残念。

>>174
なんかリファクタリングしてるっぽい。やるときはちゃんと
帽子2つ用意してね。

>>176
インドからきてる人とか、中国からきてる人とか、同年代25,6くらい
だけど全然かなわないっすよ。皆飛び級とかしてるし。

>>178
ファクタリングかぁ...
デモみせないと不安になるひと多いですよね？

帽子ってなんすか？

コンサルになるには本書けばいいとおもー

「UMLがオブジェクト・モデル図の標準表記法に」ですって。
http://itpro.nikkeibp.co.jp/members/NIT/ITARTICLE/20010508/1/

>>176
やっぱり、「OpenSourceはOO方面に弱い」ってのは
言えてるんだろうなあ。
まぁ、読んで字のごとくOpenSourceなわけで、
実装「だけ」が一人歩きして流通してるんだよな。
＃それに奴らはしばしば、必要以上に実装至上主義だし。
しかもCじゃ、リーズナブルなリバエンの自動化は無理だろうし。
ちょっと鬱。
GnomeやKDEの世界がもう少し元気になると
多少は改善するんだろうか？

あとはUMLの図を流通する手段か。
XMLかなんかで標準化されるんでしたっけ？

>>181
パスわ要求されたんで入れない(t_t)

VisioかRose、どっちにしようか迷ってます。カネは問題ありません。

これまでの話の流れでいくと、やっぱし、Roseが無難なところですか？機能的に。。

>>183
選ぶならRoseかな。
体験版しか使ったこと無いけど、
モデリングやリバースなど、実用性ではいちばん。

ただ印刷用の書類を作るのには向かない。
こちらはVisioのほうがいい。
そのかわりCASEとしては使い物にならない。
モデルを作るだけなら十分。

一番いいのは、両方買うこと。

>>184
サンキュ♪

Judeを***して自分でクラス書き換えてつかうとか...

Jadってすごいなぁ。

もうＯＭＴって廃れたのかな？

>>187
っていうか、UMLの先祖でしょ？
Booch+OMT=>Unified-Method->UML

TogetherJ は?だめ?

UMLは楽しいよ。

いちいちUMLなんか使ってられん！
↑
↓
やっぱUMLでちゃんと設計しないとダメだ！

これを１ヶ月単位くらいで繰り返してます（藁）。

使える所から使えば良いのさ（ぶ−ち・ふぁうら−他多数談）
UMLにはクラス図とかシ−ケンス図しかない訳じゃない。
テキストのシナリオだってUMLのプロセスに含まれてるし。

シナリオ書いてみるのは重要だとオモー。
これってクライアントに示しても違和感ないしさ。
プログラマに見せても違和感ないしさ。

クラス図なんてクライアントに見せても???だろうしなあ。
多重度の数字・記号なんて特に訳わからんだろ。。。

プログラミング経験、ＥＲ図作成経験、ＴＯＥＩＣ８４０ありなんですけど
使ってもらえますか？？？
＊来年３０歳

>>194

でも、書籍「かんたんUML」のアレは夢物語としても、
＃つーか本当に(1件たりとも)あんなことする企業って有るの？
多少はUMLの知名度がソフト屋以外にも広がって欲しいなと
思うことは多い。

というのも、自然言語の曖昧さゆえに
客との間(とかチーム内でもだが)で
意思の疎通がうまくいかない伝言ゲーム状態に
陥ることが多いんで。

まぁつまりUMLに限らないわけだけど、
あれっぽい記述能力があり、曖昧さが出来るだけ少ない
人工言語が欲しい。世間にそこそこ普及して欲しい。

あえていえばUMLはOOっていう考え方に依存してるため、
将来OOを丸々越える方法論が出る日までの命(w)なので、
他の人工言語とかも色々欲しくなる…

>>196
>客との間(とかチーム内でもだが)で
>意思の疎通がうまくいかない伝言ゲーム状態に
>陥ることが多いんで。

そこなんだよな−。
語彙の不一致もあるから自然言語ベ−スでやってるとお互い確認を繰り
返すようになって疲れる。
フロ−チャ−トみたいにソフト屋以外でも使われるようになるといい。

UMLはＯＯに依存しているがゆえに、ソフト屋にだけ使わせるのは勿体無い
気がする。細かい点を省略すれば、普通の会社が普通に使えると思うのだけど。
特定の実装言語に依存しないのだから、仕事のモデリングにのみ使うのも
いいと思うのは俺だけかな？

>UMLはＯＯに依存しているがゆえに、ソフト屋にだけ使わせるのは勿体無い

直接的には俺もそれに同位体なんだけど、
ただ、同意してる理由が「単に俺が今OOまんせーな人だから」
なのではないか？という恐れが有りまして、
保険を用意したい気分にもなっちゃうんです。
OOが果たして森羅万象のうちの何割を表現できる/できないのか？が
よく判らないというか、今後どう変化するのだろうか？というか。

まぁ現段階でなに言っても杞憂とか皮算用とかでしか
ないのかも知れないけど、少なくとも関数型言語スレ見てると
OO以外の世界も色々有るんだなーと悩んでしまうし。

あとUMLについて細かい話でもう1つ突っ込むなら、
OOといってもClassがっちり有る言語(典型的にはJava)に
最適化されがちな仕様だってことも、ひっかかる感じ。
Prototype型OOPLとかに相当する絵を描こうと思ったら、
全く描けないわけじゃないけど少し(しかも恒常的に)手間が増える。
「今一番流行っているスタイル」にフォーカスしてるんだよなあ。
完全に引けとは言わないが、もう少しだけソフトフォーカスつーか
ワイドつーかにしても、いいようなキモする。

初心者向けの本教えてage

>>200
SEの「独習UML」はどう？

　 Λ＿Λ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　祝２００スレ♪
　（　　　　）　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜ ｜　|
　（_＿）＿）

>>200
ありがと本屋で見てみるわ。

UMLって表記法のみならず開発プロセスの統一でも有るわけだけど
そこらへんどう？

ビジュアル開発、イベントドリブン、旧来の
DFD,ERDとの連携に付いてはどう？

>旧来のDFD,ERDとの連携に付いてはどう？

連携って、なんかイヤじゃないかな？
DFDなんか捨て捨てってカンジかと思うのだが。

よって、DFDとかからの情報の吸い上げ(一方通行)
という意味においてのみ、なんか有ってもヨイとは思う。

が、どうやって吸い上げるか？という手段レベルの話で
十分なようなキモするんで、方法論そのものには関係ないかも。

クラス図とERDって、どうやって使い分けてよいかってのに悩む。
それぞれの作成目的が違うってのは理解できるんだけど、似通った図なので
併用してるとこんがらがっちゃう。

単純に ERD は DB 設計用、ってことでいいと思うけど。
実際は UML だけで十分だろうけど、
ERD は利用者人口からいってさすがに無視できないから。

>>206
UMLだけで十分なのでERDを作りたくない、って
設計初期段階では思うんだけど、設計を進めていくと
やっぱERDないとDBに落とせない〜、ってなっちゃう。

プログラムを作る時、ＵＭＬどの図からはじめるのがいいですか？
ユースケース図→シーケンス図とクラス図って感じでしょうか？
もうちょっと細かく
ユースケース図→アクティビティ図→シーケンス図クラス図

GUIやWebシステムを作るとき、各画面はクラスにしてしまっていいのでしょうか？

画面遷移とかはどの図になるんでしょう

Excel みたいな テーブル(グリッド)のコントロールに対応した
クラスはありますか。

>ユースケース図→アクティビティ図→シーケンス図クラス図

俺の場合、アクティビティ図は操作の詳細化に使うほうが多い。
で、ユースケース図→シナリオ→クラス図・シーケンス図
って感じだよ（教科書どおりだけど）。

>GUIやWebシステムを作るとき、各画面はクラスにしてしまっていいのでしょうか？
クラスのステレオタイプでBoundaryというのがあるね。
GUIにもそれなりの責務があるとみなせばクラスにできるから、この辺は意見が分か
れるところみたいだよ。
画面遷移はシ−ケンスに組み込むか、単にユ−ザからの見た目だけを追うこともある。
判断はその時の要求によるけど、PGから見ればシ−ケンスだろうね。

>Excel みたいな テーブル(グリッド)のコントロールに対応した
>クラスはありますか。
商用コントロ−ルは特定のクラスに対応して作ることはないと思うから、設計の要求
に合わせて”選ぶ”もしくは作っちまうかじゃないかなあ？

揚げ。

>>208
それってウォターフォールモデルだなぁ。
どこからはじめてよい開発モデルのほうがやりやすそう。
おいらは、初めにデモりたいコード書いて
それをクラスにしてファクタリングするよ。

コ−ド書いてからクラス決定するの？
かえって面倒じゃないか？

ユースケース図作成
→クラス図・シーケンス図作成
→ユースケース図手直し
→クラス図手直し
→アクティビティ図・ステートチャート図作成
→クラス図手直し
→コード作成
→クラス図手直し
……

あげちゃう。

で、magicdraw日本語表示されるようになったみたいって言ってたけど、それって
メニューなんかのことなのかな。図の中のオブジェクトに日本語入らないね。
きのうデモ版ダウンロードしてちょこっとさわっただけだけど、とくに設定は
ないはず環境はjapaneseにしたし。ベンダーに直してってメールしといたよ。
日本語表示できるなら金だして買う価値ある。

>>217
フォント変更すれば？

judeを逆コンパイルしてみました。
なんか私にも同様のモノをつくれそうでした。
皆さんいくらだったら購入してくれますか？

>>218
ちょっとここに書くのが早すぎただけだろ、くそが。

>>220
おこらないでね。
私もこれで困ったんですけど、
動かしていたらやりかた見つけたのですよ。
なので、日本語版に設定したのだから、最初からフォントを
MS明朝あたりに設定して欲しいですね。
フォント変更しても、全てに反映されないし。

>>221

マニュアル読んだら出てた。確かに日本語環境指定したらデフォルト
フォントを漢字対応にしてほしい（ていうか日本人なら自然にそうなる
って思う）。Roseは使ったことないが、結構いいね。とくにソースから
クラス図出してくれるとこなんか感動もん。

>>222
Javaからやったらうまくいったけど
VC++からやってみたひといますか？

magicdrawプロフェッショナル版買いました。いいねーこれ。ドキュメント
書くの楽になるね。２ｃｈもたまにいい情報あるよねーマジデ。
ひさびさの大ヒット。

>>224
　おいくら？

>>225
６〜７万くらいだったかと。
フリー版もあるみたいだね。
ダウンロードしようとしたら、個人情報を登録しないと
できないみたいだったのでやめた。

$499.00です。roseと比べたら激安。結構良心的にやってるみたい。メーリングリストも
あるし。ちなみにわたしは回し者ではありません。
デモ版は図がセーブ出来ないですが、jpgイメージに落とせるのでwordのドキュメント
なんかに貼り付けることできるよ。セーブできないっていうのは、かなりダメージ
でかいので買っちゃいましたけど。

同じようなの１万円以下のシェアウェアで出たら
皆さん購入しますか？

>>228
フォーマットがvisio互換なら考える

>>229
VISIOフォーマットでエクスポートなら？

エクスポート＆インポートが絶対条件だな、俺の場合。

>>228

かなり機能がでかいから同等なものもで作るのは大変そうだけど、
同等でやすけりゃ売れるよね。magicdraw自体がroseをターゲット
にしてるわけだから。magicdrawはデベロッパーと直接やりとりしな
いと（質問とかもね）いけないので英語が出来ないとつらいって
いう面はあるね。

>>232
デベロッパーと直接やり取りというのは？
もうちょっと詳しくお願いします。

>>231
VISIOがあれば
印刷機能なしでもよいということですか？

>>233

日本の販売会社通してないから作った会社＝デベロッパーが売ってると
思うんだけど。買い方はwebの登録ページでカード番号いれた
らダウンロード画面が出てくるしくみ。買うだけなら英語いらないよ。
マニュアルは英語だけみたい。不具合で文句いいたくても英語書けない
とつらいってことですね。
プログラムのヘルプは日本語になってる。

>>235
そういう意味でしたか。
日本人が開発したもので日本語で質問できるとしたらどうですか？

え、ヘルプが日本語なの？　すげーなー。

MagicDraw の日本語 ML ってあるのかな。
作ってもよさげな気がする。

どっちにしろ皆のＵＭＬになる日は今のままでは遠いなぁ。
下請け会社にＵＭＬでかいてるもの渡しても理解してくれないしさ。

定期揚げ（三ケで１００円）

>>239
凡例も書いてわたせばいいじゃん。

>>241
そうだね。つーか、シナリオの日本語が...以下自粛。

確かにシナリオのシチュエーション表現は普段文章
書き慣れていないと駄目だね。

Magicdraw評判いいね。
でも関連の線がカクカクしちゃうのなんとかできないのかな？

接続線を選択して
Edit-Links-直線の種類-Oblique

Options-projectで
スタイル-デフォルト-パス-直線の種類-Oblique

ではないだろうかという噂を聞きました。

ユースケース図にでてくるアクターの概念がいまいちピンとこない。
ある程度のシステムならわかるけど、普通のアプリケーションの場合はどうなるの。
ユーザーぐらいしか思い浮かばないけど。

アクターはロール（役割）でいいのではないだろうか？

>>普通のアプリケーション

ってなに？ノートパッドとか？

>>甲州街道
抽象化して考えてね。

メタなUMLとはなんぞや？

AA

ノートパッドならどんなアクターが考えられる？

ノ−トパッド単独をドメインとするならユ−ザぐらいじゃない？

>>252
ノ−トパッド単独をドメインとしないなら、どうするの？

ダイアグラムが着目しているスコープの中で
外部と見なすものはすべてアクターでいいんでないの？

しかしノートパッド程度でOO分析・設計が必要？

キーボード等のイベント発生器、
ウィンドウ、ファイル、ユーザー。

集約とコンポジションの違いって？？

Fowlerいわく、”集約は気休め”

>>257
あまり使わないってこと？？

age

ＵＭＬでは、ＯＭＴでいう「データ辞書」ってあるんですか？

>>260
クラス図の分析過程で出てくるやつ？？

最近オブジェクト指向によるシステム分析・設計に興味をもち、
Webで資料あさってます。
↓とか
http://www.njk.co.jp/otg/Drop/Drop_v20/
まだまだ、現実に行うには勇気が要りそうなものが多いですが、
面白いですね

なにかよさげなものあったら教えてください

>>262
内容は全部見てないが、よくここまでまとめたもんだ。

>>260
　UMLはモデリングランゲージだからね。無いかもしれない。
あるとしたらRUP（Rational Unified Process）のほうかな？

MagicDraw4.5ダウソロードした？

>集約とコンポジションの違いって？？

UMLでいうコンポジションは集約の一種で、子オブジェクトのライフ
サイクルが親オブジェクトと同じ、つまり親オブジェクトが消滅した
ら子オブジェクトも消滅する、というものを指したと思います。

>>266
なるほど。
じゃあ「人」と「お金」は集約で、「車」と「タイヤ」はコンポジション
ってこと？

それは包含とは言わないか？＞２６６

いま、MagicDraw4.5betaを試用しているんだけど、
メソッド、メンバーに限り特定の日本語が化けてしまう。
（ほ、とか）
うちんとこだけ？

>>267
金は天下の回りモノ。
人に集約(ってのか?)されてるものじゃないぞ。
法人と金庫(笑)と人とをまとめた抽象クラスを作って
それに集約っていうならまだ良いが。
抽象的な財布とでも呼べば良いかも。

蛇足だが「金」ってオブジェクトにしにくくないか？
金や水みたいに数を数えにくいものって
器(金なら財布)に所属する属性としてしか
作りようがない感じだったりしないか？

JDK1.4は対応してないみたいだな、MagicDrawは

>>268
包茎？

>>272
優良スレなんだから、くだらないこと書かないでね。

>>270
>「金」ってオブジェクトにしにくくないか？
アナリシスパターンの「量」が参考になるかもしれない。
簡単に言うと、数値と単位をひとまとめにしたオブジェクト。

元発言の意図をくんでいないおそれが高いのでsage

>>266
　OMTのときはそれが集約だったんだけどな。
　UMLでの集約って通常の関連とどう違うんだろう。

集約
：関連の特殊な形で、関連するオブジェクト間に「全体−部分」
の関係が成り立っている。
コンポジション
：集約の一形態。全体と部分の関係が強く、部分オブジェクト側
のライフタイムが、全体オブジェクト側のライフタイムに依存し
、一度確立された関係は変更できない。したがって、全体オブジ
ェクト側の多重度は必ず「１」である。

って書いてありましたよ。

>>275
分析の仕方によって、ただの関連として捉える
こともあれば、集約として捉えることもあるって
ことですかね？？

>>276
＞分析の仕方によって、ただの関連として捉える
＞こともあれば、集約として捉えることもあるって
＞ことですかね？？

その通り！！あなたはかしこーい。

>>274
いや、こっちの意図としては、そんな感じっす。
アナパタは日本語上陸したばっかりの頃に読んだが
しょせん自分がドキュだということを思い知った(笑)
半分以上の意味がわからんかった。鬱

>「量」
そういや有ったような気がするなあ。
でもあれって、「同じ金額」という概念の
同一性と同値性の区別の問題は
どう克服してましたっけか？？？

age

買っ・ちゃ・った♥
UMLによるJavaオブジェクト設計　第2版

>>280

うわー、その本、最悪だよ。(藁
俺は買って後悔した。　どぉ？使える？

RateManager

>同一性と同値性の区別の問題は
通貨まで考えると取引時のレートまで考えなくちゃならなくてタイヘン
でしょうねぇ。アナパタ本では、トレーディングに関しては２章設けて
紹介してますね。

長さとか重さみたいに、文脈によらないで値が変換できるときには、単位を
オブジェクトにして、単位同士の換算方法を知識として持つようなパターンが
紹介されていますよ。

...また題意とちがう応対をしている気がする(w

ｶﾞｲｼｭﾂだったらごめん。

めっちゃおそレスでｽﾏｿ、
UML描くツールだけど、
UML Forumであのマーチンファウラーがいってたけど、
「CASEツールなどいらん、ホワイトボードとでデジカメで十分や」
だってさ。
たしかに設計段階で、クラス抽出〜洗練を繰り返してる段階で
わざわざツール使ってUMLかくのタルイよね。
その点で、マーチンファウラーはええこというな、とおもったよ。

みんな、ホワイトボードを買いに行こう！！
（誰かこのレス見てくれんやろか？）

>>284

俺はちょっとアイディアを練ったりするのに、
Ａ３サイズのホワイトボードを愛用してるよ。
コピーとれば保存できるから便利。

>>281
例題が載っている本が欲しくてね。
一応前にもUMLの本を持っていたんだけど、
やっぱし例題があるとわかりやすいから。

それに、この本にはいいことが書いていたよ。
「人は、例題からも学ぶのではなく、例題が唯一の学び場だ」
だったかな?うろ覚え。

経験的には分かっていたけど、あぁなるほどね、と
つい感心してしまった。

全然関係ないけれど、初めてfowlerのサイト見た時に顔写真見て

”逆さまになりそうだ”

と思ったのは俺だけ？

参考：
http://www.martinfowler.com

>>287
どういうこと？？

>>287
私はﾁｮﾋﾟｰﾘ同意

逆さ達磨

KivioにUMLステンシルあるのかな？

MagicDraw
住所っていれたら住＠になるなぁ

>CASEツールなどいらん、ホワイトボードとでデジカメで十分や」

要するに裏紙たばねたやつに書き散らしでOKということなんね。

>>293
俺みたいな書き方でも良いのか‥‥安心。
でもすぐに無くすんだよなー。しかも、書き直すたびに違うクラス図になってるんだよなー。

KentBeckも逆さだるまっぽい

>>293
　そいつらがコード吐いてくれたら完璧！

なんでモデリング言語にコードジェネレート期待するかなー。

>>296
コードを印刷した紙の裏にUML書けば、そういう気分に浸れるかも。無理か。

MOFってなんだ？

MOF=大蔵省？

Meta Model Facility

間違えた。Meta Object Facilityね

MOFはmetaが3階層もあってやたら難しいのだけど。
MetaのMetaのMeta…

MOFとかXMIとかって現場に入ってくるのはいつ頃だろう
UMLとかかなり早いスピードで来たからこれらもチェックして
おく必要あるのかなぁ>>303

http://www.secure-biz.net/OSD2000/presentations/Technical%20Solutions/T02%20-%2009_15AM%20MON/XMI-iyengar-dod/sld001.htm
こんなのあったので一応はっときます

>>304
UMLモデラー同士でデータ相互活用！みたいな謳い文句で
XMIが提唱されたのは2年くらい前かな。
その後、Rational Roseがプラグインで部分的に対応して、
IBMがXMI toolkitを作りっぱにしたくらいか。

MOFの仕様書とXMIの仕様書合わせて700Pくらいあって
こんなん読めるかっつー感じだ。
別に仕様書読破する必要もないけど、
MOFもXMIも資料がまだまだ少ないんだよね。

>>306
XML関連はどんどん新しい仕様が出てくるのに、
UMLをさらにメタメタにしたような規格は新しいの殆ど出てこないね。
XMIも風呂敷はデカソウだけど、関連したソフトウェアのアップデート
もされていないみたいだし｡｡｡
頭いい人が考えても、凡人がついていかないと普及しないんだね（藁。
様子見だってことは分かりました。ありがとう

関連書籍
http://www.amazon.co.jp/exec/obidos/ASIN/0201709155/qid=992748071/sr=1-1/249-1864945-9054761

>>304
ArgoUML MagicDraw は、とりあえず、XML で保存しているけど、
互換性あるのかな

>>308
ほんとですか？だとしたら内部でメタデータの変換してるはず。
MagicDrawダウンロードしてみようかな。

>>309
こんな感じで、XMLになります。
<?xml version='1.0' encoding='UTF-8'?>
<!-- <!DOCTYPE XMI SYSTEM 'uml.dtd'> -->

<XMI xmi.version = '1.0' >
<XMI.header >
<XMI.documentation >
<XMI.exporter >MagicDraw UML</XMI.exporter>

UMLからC++のコードを生成するツールってないですかね？

>>310
ひどいXMLだなぁ、namespaceとかそういう概念も無いんだろうか（笑）

>>307
XMI コードは、 XMI 規格（Meta-Meta-Meta）下で
XML化されたUML規格（Meta-Meta）で作るUMLモデル（Meta）だからねえ。
MetaレベルのXMLは自分で設計するし。
基本的にはUMLと同じで覚えて使うものだと思う。

>>311
Roseはクラス図からスケルトンコードを生成してくれるよ。
IDL使いには便利だと思う。

MagicDrawもスケルトンはきますよ。
Vestのやつもいいね。

こんなのあります。がいしゅつだったらすみません。

http://jcp.org/jsr/detail/26.jsp

どっかのUMLツールの会社と豆蔵が提携したというのを
日経コンピュータかなんかで読みました。
MagicDraw もどっかの会社が代理店になるらしいです。
UML-jp あたりで見た気します。
日本にも、UMLツール続々上陸でしょうか？

みんなRationalのボッタ栗商売に嫌気がさしてることは想像できるよね。

代理店通したら高くなりそう。
いっそのことマイクロソフトが買い取ったほうが、
VC++についてくるだろうから嬉しい。
VisualModelerでは組み込み用途には非力すぎたし。

>>317
日本に代理店ができる前に買った方がいいかも

age

UMLが描ける
Java/C++、その他のクラススケルトン生成（エクスポート）
ソースコードを読み込んでUML（クラス）図生成（インポート）
Visio/Roseのインポート＆エクスポート
印刷も一応できる。
そのほかプラグイン機能で拡張可能
複数人による同時編集機能
で、Vectorに登録して3000円で販売だったら馬鹿売れですか？

>>320
あとから各言語用のプラグインが出たりすれば買っちゃうと思う。
何せRuby対応ってのは聞きませんし。
まぁ使い勝手重視ですけど。
手書きのような手軽さがあればパーフェクトゥ

>>321
ルビー対応ですか
各言語に精通してないとできそうもない...
sourceforgeあげで、無料で使用できるほうがいいですね。

Ruby対応のUML書けるツール、欲しいッス。

ここで求められているものをUMLで描いて開発してみたいもんだ。
Ruby対応か...

MartinFowlerがなかなか含みのある話をしてるよ。↓

http://www.cbop.gr.jp/Martin2/Tokyo2001MF.htm

あ、UMLのツ−ル作ろうと思ってる人への煽りじゃないからね。

>>320
それができたら、Vectorなんてせこいこと言ってないで、
アメリカで会社作ってNASDAQに上場した方が儲かる。
できたらだけど。

>>325さんのリンク先をよみましたよ。
コストの把握ですか...
これを計算する方法と
アプリケーションもつけたほうがよさげ
土木建設工事を例にだしていたので、
積算によって正確に算出している会社ってあるんですか？

http://www.cbop.gr.jp/Martin2/Tokyo2001MF.htm
から抜粋
------------------
第二の利点は、デザインの模索のやり方において、何処に行きたいかの模索ではなくて,既に到達した現状を
記述する事をやります。コードは完全に終了してはいませんが、途中までできている時です。
UMLのダイヤグラムと実際のコードとの同期をいかにしてとるかは重要です。コードは決して終わる事は
ありません。そういう状況の中で、UMLのダイヤグラムがきちんと最新のものになっているかと言う事が
非常に重要です。
-----------------
これまでにここで紹介されたツールって同期してたっけ？

Kernel UML
いいなこれ。

http://www.cbop.gr.jp/Martin2/Tokyo2001MF.htm
から抜粋
----------------
Toolの価値はあるのですが、また危険を伴う事があることを理解しておかなくてはいけません。
----------------

>>327
日本の土木は談合の世界だからなあ。。。
現実みれば理想論っぽい。
言いたいことはわかるけど。

>320
すでにあるよん
ttp://www.togethersoft.com/us/products/index.html#features

言語はJavaのみだけど
クラス図のみの機能なら無料です

>>332
さんけう

>>332
ライセンスキーはどこから手に入れるの？

フリー
http://www.togethercommunity.com/community-edition.shtml
お試し
http://www.togethersoft.com/us/products/download/instructions.html

together って日本で、どっかの代理店ないのかな？
今○さんあたりの会社がいれるのかな？　

together良いね。かなり。すごく。フリー版でもC++の解析、吐き出しもできる。
気になるお値段の方は、と思って調べてみたんだけど、どこの国の代理店も値段表記してないし、
ましてやネット販売もやっていないような。

JavaのGUIなソフトって、いつになったらストレスフリーで使えるようになるんだろう。

こんなのあるよ。知らなかったな。
http://www.iioss.org

オープンテクノロジー主導なんで、ちょっとどうかなと
思うのですが、

>>337
Javaで描かれたものがそのマシンの上でC++に変換され、
コンパイルして使えるようになればいいのにね。
そういうパッケージソフトあったような...

>>338
参加してみたい...

皆さんどのフェーズから開発言語を意識してそれように描いてますか？
設計モデルから？

システム用件から機能抽出するとき、
どういうツールをつかいますか？

VisioはUMLからのコ−ド吐き捨てたみたいね。
VSに統合するからなんだとさ。

要求を文章にして、そこから名詞やら動詞やら・・・

>>343
ソースコードからインポートできないのね

オージス総研がRoseを捨てたね。
そのかわりKonesa（コネッサ）というツールを売り出すらしい。
開発元は、組み込み向けの状態遷移型CASEツールCATSで
有名なZIPC。

http://www.ogis-ri.co.jp/otc/news/rose/20010219/index.html
http://www.ogis-ri.co.jp/otc/products/konesa/index.html
http://www.zipc.com/zoo/konesa.htm
http://www.zipc.com/zoo/zoo.htm

でも高いんだろうなぁ。
Visio2001で我慢するか…。

>>346
MagicDraw demo version はどう？

UML はお絵かきだよ
役に立たないよねー

>>348
図らずとも自分の未熟さを認めている奴発見。

そうかぁ？
分析フェーズで相当わかることがあるんだけど。

>>349
図らずもUMLでなんでもできてしまうと思い込んでいる
UML信者発見
大量トランザクション処理システムや、割り込みが入るシステムや
分散処理、設計できないだろー
クラス設計はできても、それは使い物にならないんだよねえ
その名はUML もし、この俺に反論があるんだったら
上の処理をどうやってUMLで、記述するのか言ってみな
いえなきゃお前が未熟なんだよ

348では適用分野について何の明言もないので、
「一般的に言って」UMLは使えないと言っているとしかとれない。
一般的に言ってUMLが有用なのは明らかなので、349の反論は的はずれではない。
それに対して350がUMLが不向きな分野を挙げて反論とするのは
何とも的はずれでハァ？としか言いようがないな。
UMLが何にでも使えるとは思わないが、
分散処理向きに拡張したUMLについての論文もあるので探して読んでくれ。

>>352
またまた、自分の感覚だけで反論しているUML信者はっけーん
だいたいさ、ジョブフローの記述もできなければ、大量トランザクションの
記述もできないようなUMLなんて だめだめ

みなさんの適用分野がかなりちがうとオモワレ...

分析フェーズにおいてUMLを用いるよりより方法は？＞352

>>353
自分はプロセス記述にUML使わないから。
なんで向かない分野をことさら取り上げるわけ？

「UMLは役に立つ」と思う人がUMLを役に立てる方法を議論するスレだと思うので、そっちの方向でお話ししません？

UMLはシステム設計における必要条件の一つでいいのでは？
それだけで一通り設計できる場合だってあるしね。>>353

こんなのむいてるよっていうのを列挙してくれるとありがたいです。

>だいたいさ、ジョブフローの記述もできなければ、大量トランザクションの
記述もできないようなUMLなんて だめだめ

ジョブフローはアクティビティ図ではダメなんですか？
＃ ま、わざわざUMLベースで書くこともないと思いますけど

大量トランザクションの記述って、どんなことをイメージして
いますか？

大量のトランザクションと
多様なトランザクションは
別だとおもうけろ

割込みといえば、最近はリアルタイムUMLなんてのも有るわな。
割込み違いだとは思うが一応述べると、タイムアウトとかの概念も
記述できるようになってるようだぞ。本も出てる。

あとフローやトランザクションって
State図やSequence図じゃ駄目なのか？

まぁ、if文に相当するものは、UMLじゃ書き難いかもだが。

>>351
大量トランザクションは分野が違うので知らないけど、
割り込みや分散処理は設計できる。
そういうCASEツールもあるぞ。
もちろん何でもできるとは思ってないが、
>>348はアホだと確信できる。

だいたい割り込みが設計できないと思っている時点で、
オブジェクト指向を理解していないことがバレバレ。
メッセージの概念を把握していないのか？
それともUMLにメッセージが無いと思い込んでいるのか？
どちらにしても、素人丸出しだな。
応答時間まで考慮して設計できるCASEツールがあることも知らないんだろうな。

UMLに向いてる分野で興味あるのだけど
ハードウェア設計にはどうなんでしょう？
組み込みのリアルタイム処理向けの話題は
結構あるけどソフトレベルの話ですよね

たとえばPCIみたいなバスを、
デバイスやブリッジをオブジェクトに見立てて、
トランザクションをシーケンス図で描けば、
タコなデバイスを設計してバスをロックさせる様子とか、
分かり易いと思うんだけど。タイミングチャートより。

とりあえず制御用のステートマシンをMagicdrawで描いてみるかな。
UMLのステート図をHDLに落としてくれるツールって無いかなぁ

質問スレじゃないような気もするんですが・・・
どうしてもわからないので、どなたか助けてください。
「もぐらたたきゲームを考えたときに、もぐらは一定時間ででてきます。」
これをシーケンス図であらわすとどうなるかがわかりません。
なお、オブジェクトはあらかじめあたえられていて、「プレーヤー」「もぐらたたき台」
「もぐら」です。
もぐらたたき台が一定時間ごとにもぐらを呼び出すとかんがえてもうまくいきません。
「逝ってよし」などといわず、どなたか助けてください。

>>365
まさにリアルタイムUML本はどうよ？
いきなり心臓ペースメーカーの概念設計なんか出てきてびびった。
とりあえずどれくらいいけそうか立ち読みお勧め(わら

>>366
>あたえられていて

1つ質問だが、Objectは自分で考えたのを「追加」しちゃ駄目か？
駄目なら、それはOOPの問題としておかしいんで、答え無し。
そういうおかしい場合は忘れるとして。

そうだな。俺なら「周期タイマー」オブジェクトを
モグラと一対一の数になるだけ生成する(勿論その前に
そういうClassを作る)ところだ。

で、それらタイマーオブジェクトを、Actorとするなあ俺なら。
Actorは人間様(ユーザー)でなくてもよいわけで、
こういう「勝手に動くもの」はActorとして似合いだと思う。

というか、タイマー＋モグラ＋モグラ穴(不要か?)が
1つのセットになっていて、それが複数セット並ぶと
もぐらたたきゲームができるわけだよな。
設計レベルでは、そのセットと台が、
多対一でRelateすることになるだろう。

それに対するかたちで、もう一丁のActorである
ユーザーの右腕(わら)またはハンマーが、
非同期(=イベント)で殴りかかるわけだ…

…と、とりあえずこのくらいを考えた。所要時間0.3秒(嘘

>>367
ありがとうございました。そうですよね、タイマーオブジェクトを
作成しない限り無理ですよね。参考になりました。
一度、その方針で作ってみます。
本当にありがとうございました。

実は、このモデルはOMT法で書かれていたものですが、
必ずしもOMT→UMLというふうにはいかないんですね。

>>367
ありがとう。立ち読みしてみまーす。

UMLじゃないけど、ちょっと前Interfaceで特集・連載があった
自律オブジェクト指向(AOO)という話は読んでてｻﾊﾟｰﾘだった。
ちょっと電波入ってる気がしたのは、
おれが分析・設計の本を読み慣れてないから？

>>363-364
批判するのは簡単にできるが、どうやってオブジェクト指向のお絵かき
しかできないUMLに分散処理や割り込みが記述できるの
またビジネスの分野であっても、オブジェクト指向DBとの連携を
どうやって設計するんだよ。
結局、UMLでお絵かきした後で、別の方法で書き直す、設計しなおすのが
現実だろう。おまえじゃあオブジェクト指向を知ってるのかよ
どうも、ちょっと知っているだけで実際に使っているようには見えないが

>>371
全てをまかなえないと言うのと、役に立たないと言うのとでは、
かなり違いがあるが……。371の発言は、UMLが役立つ
ツールの一つであることを認めてないか？
348と矛盾しているな。


分散処理や割り込みの設計は、ただUMLを使うだけでなく、
デザインパターンと組み合わせるんだよ。
どこのコンサルでもそう指導するだろ。
知らないなら人に聞く前に勉強しろよ。

このスレに全くついて行けないﾓﾚがバカなのか
それともチミ達が頭良すぎるのか、どっちですか？

言いがかりをつけて楽んでいるようにしか見えないのは俺だけか？
UML万能論を唱えているやつなんていないのに。

>>371
あ、ところで。
＞別の方法で書き直す、設計しなおすのが
この別の方法って何？後学のために知りたいのだけど。

おれ、トラックの運転手なんだけど、メールってちっとも役にたたないな。荷物をおくれないからな。

開発に、UMLツールつかって、うまくいったケースってありますか？

Rose をつかったという話は聞くのですが、それが本当に機能したか
どうかは、あんまりはっきりしないようなのですが、

考えをまとめて、議論するには、UMLって非常にいいと思うのですが
UMLツールつかって明らかに成果でるもんでしょうか？

>>371
>批判するのは簡単にできるが、どうやってオブジェクト指向のお絵かき
>しかできないUMLに分散処理や割り込みが記述できるの

うーん。かく言う君がまさに、UMLに対して
「批判するのは簡単」という状況に陥っていると思えるが(藁

お絵かきしか出来ないから何もできない、と呼ぶなら、
プログラム言語のソースだって文字しかないから
何も出来なさそうなものだ(藁

ちなみに大昔、コンパイラがまだ「実現不可能だ」と
思われていた時代 (つまりFortranより前の時代)には
冗談抜きでそう認識されていたのだろうと思われる。

「記述」はなんぼでも出来るんだよ。
文法(文じゃなくて絵だから絵法か?)さえ有れば。

あとはそれを「コンパイル(?)」するコンパイラ
(もちろん他の言語に変換するTranslatorでもいい) が有るかどうかの差だけだ。
問題を自分で勘違いするな。

で、ソウ言う風に整理したとして、質問(批判)の対象は、なに？

>またビジネスの分野であっても、オブジェクト指向DBとの連携を
>どうやって設計するんだよ。

OODBすなわちビジネスという決め付けが痛いってのはおいといて。

そんな実装べったりの部分にUMLとか設計とかいう単語を持ち出すのか？
オブジェクトをどうメモリ(に隠蔽されたDB：OODBってのは
そう実装されてることが多いらしい)に置くか？という問題が、
(ビジネス)アプリとかの「設計」の領域なのか？

そんなのはキミじゃなくてOODBベンダにとっての設計の領域だろうよ。
たぶん彼らは社内でOODBの機能を設計してるだろうからな。

>結局、UMLでお絵かきした後で、別の方法で書き直す、設計しなおすのが
>現実だろう。

キミは「(キミの視野の範囲の)実際」にしか使ってないようだな(藁

上記のように直接変換するツールの有無も問題だが、ソレ以前に
「思考支援ツール」
の重要性を全然認識してないと思われる。

UMLで描いた「とおりに」思考するんだよ。
あんたそういうふうに思考してるか？
してない(できない)ならそもそもUML使わなくていいよ。ぽい。
でもUMLは、OOP的なフツーの思考をフツーに図示できるように作られている
という意味ではなかなか健闘してるから、思考できないってのはフツーは無い
はずなんだけどなあ。

書きなおし(=Translate)が手動であることは、ツールの都合上あるだろう。
が、設計までし直すのかキミは？
UMLをなんか勘違いしてないか？描いたとおりの姿がつまりキミの設計なんだよ。

というわけで、UMLで描けなくて困った設計パターンについて、幾つか言及してみろよ。
話はそこからだな。

なんかもりあがってる

>>365
貴方が作って、フリーで流す。
そして我々得をする。

>>378さんに同意するけど、
みなさん大まかに分けて、
概念フェーズ、
分析フェーズ、
設計フェーズ
に分けてないんですか？
いきなり設計フェーズの話してもなぁ。
設計フェーズは例えば、開発する言語の特性を考えながら設計するんですけれど。
三つのフェーズそれぞれどこか違っていてもいいとおもうんですけどね。

>>378

>うーん。かく言う君がまさに、UMLに対して
>「批判するのは簡単」という状況に陥っていると思えるが(藁
実際に出来ないから使えないんじゃないのって言ってるんだけど
で、僕に反論があるんだったらその記述方法を示してください
っていってるんだけど。

ただ、ＵＭＬを使って自分の考えをまとめるだけならちょっとは、つかえるかもね
実際去年ＵＭＬもどきの分析方法でやってた連中がいたが
使えないのに気づいてしまった時は遅く、泣く泣く徹夜の連続で
分析からやり直してた連中がいたなあ

>>382
どいうものに使おうとして失敗したんですか？
またやり直したときのツールはなんですか？

>>383
たしか、Ｒａｔｈｏｎａｌ とかなんとかだったみたい
やり直してたのは、手書きでやってたみたい

>>384
ツールがRationalのをお使いだったんですね。（Rose?)

で、何をつくろうとして、
手書きで書いていた設計方法というのはなんだったんですか？

>実際去年ＵＭＬもどきの分析方法でやってた連中がいたが
>使えないのに気づいてしまった時は遅く、泣く泣く徹夜の連続で

だからさぁ、
「使えない」のは、UML図なの？
それとも(そのとき使ってみた)UML図ツールなの？

ごっちゃにしてないか？

>>386
さらに、UMLを理解せずに使っていたということも考えられるね。

>>386
だから、ＵＭＬみたいなお絵描きをしてたってこと

つーかUML使ったところでモデリングが出来るようになるわけじゃないだろ。
分析に必要な能力は「物事を正確に理解すること」であってたいていの人間は
その過程で図を書くと思う。UMLはその時に「なるべくみんなで同じ記号を使
いましょう」って言ってるだけなんだからさ。
ただOO全盛のこのご時世にユースケースなんていう手続き指向の図を取り入れた
ところはすごいと思う。

そうそう。ワープロ使ったからといって文章がうまくなるわけじゃないのといっしょ。
まあ、どこにでも自分の能力のなさを道具のせいにする奴がいるってことか。

>ただOO全盛のこのご時世にユースケースなんていう手続き指向の図を取り入れた
>ところはすごいと思う。

「一般人の思考」にとってはOOより手続きのほうがわかりやすい！と
信じている人々が多いらしいからな(藁

ところで、UML勉強できるところでいいところある？
ツールは、Rose じゃなくて安い奴がいいのだけど、
MagicDraw があるといいのだけど、他でもいいよ。

iioss

>>393
http://www.ogis-uml-university.com/

またfjに
CUTEコンソーシアム
http://www.cute-c.org

本コンテンツは、情報処理振興事業協会(IPA)の平成12年度委託プロジェクトと
して実施された「ソフトウェア技術者向けCORBA/UMLトレーニング環境開発」の
成果物をベースとしたもので、以下の3種類を内容としております。

1) OMG標準技術情報 (320p以上)
OMGジャパンが提供するOMG標準技術体系の解説のほか、最新動向紹介、適用事例、
各種レファランス情報などを提供。
2) CORBA基礎 (320p以上)
CORBAの概要や、CORBAを用いた開発方法などを説明。
3) UML基礎 (320p以上)
UMLをアプリケーション開発で利用する開発者に焦点をあて、アプリケーション
開発で使用する構成要素、記法と、要求仕様を分析設計していくプロセスを、例
題に基づいて説明。

なんてのがあったから見てみれば。

クラス図の「依存」について。
オブザーバとサブジェクトの依存関係はわかるのですが、それ以外にもあるそうで。

メンバに持たずメソッドのパラメータとして渡されるだけのものがそうなの？
普通の「関連」との区別の仕方を教えてプリーズ。

俺もクラス図で → と …> の違いがイマイチよく分からない。誰か教えてアロエリーナ。

>>397
俺もよくわからん。アロエリーナ。

UML知らんから言葉で言ってくれ。説明しちゃる

>>399

→ は、誘導可能性というらしい。関連している一方のクラスに対してメッセージを送ったり
情報を参照したりできることを表すらしい。

…> は、依存関係。二つ以上のモデル要素間の意味的な関係を示す。
対象要素(依存される側)への変更が、依存元(依存する側)の要素への変更を
必要とする場合もあることを意味する｡

つまり、どう違うの？ 多分、全然違うんだろうけど…。
JAVAかC++のソースで説明してくれるとわかるような気がする。

ははは。それだけじゃ確かによくわかんないや。ってことで一応見た。
http://member.nifty.ne.jp/siteKT/uml/diagrams/class.html
誘導可能性の矢印は関連の中でも一方向の場合だから、A->BでBはAの存在を知らない場合だね。
Bを使っているだけっつーか。こっちは単純。
依存の場合は、AもBもお互いのことを知らない(関連がない)けど、Bに応じてAが決まるとか求まる
とかの条件を表現したい場合に使うね。
依存はクラス間の直接の結びつきを表しているわけじゃないってことだね。
ManagerクラスがいてそいつがA/Bを扱うような場合、A/B間に関連の線は引かないけど
依存の線を引く場合はあるでしょってことね。
上記以外も覗いたけどうまく説明してるところはあんまりないね。

　 Λ＿Λ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　祝400スレ
　（　　　　）　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜ ｜　|
　（_＿）＿）

400レスやん(藁

>>401
すばらしぃ！

>>401

ありがとうございます。
なるほど。そういうことなのか…。

>>403
まちがえました（鬱

ゆっくりながらも伸びたね。

演歌みたいな伸び方だなぁ。

つまりUMLなんてそんなもんだよ。
もうちょっと本当に必要な区別に絞った方がいいと思うんだけどねぇ。
共通言語といいながら他人に「この記号どういう意味?」っていちいち
聞かれるようじゃしょうがない。ある意味デザインパターンにも
当てはまるけど。

>>409
それは単に「勉強」不足っていうんじゃないのか？

C言語とかでも結構いるじゃん、
未だにポインタとかも間違えて使うくせに
(おかげでバグだらけだ…勘弁してくれ)
Cで仕事してる(ということになってる(わら))奴、ってのが。

あーゆーのと同じ。「勉強」不足だよ。

#間違った知識のまま、なんぼ「経験」を積んでも、駄目。
#間違いを経験しまくっているだけだから。

「今の」自分に「必要」じゃないからって
削らないほうがいいと思うぞ、UMLは。

#むしろ足りないもののほうが多いような…

Kernel UMLでいいとオモワレ

そうするとね。勉強不足の人たちにどうやって勉強させようかってのがある。
これとこれは似ているけどちょっと違うってのが多くなると、まともに理解している
やつの比率が急激に下がるよね。あーそんなこといまさらいってもしょうがないのにｽﾏｿ。鬱
なんでも最初から複雑だったわけじゃないんだからねぇ…。
(XML Schemaは最初から複雑だったが(藁)

Roseは高いけどやっぱいいですよ。
要求管理からテスティング／構成管理まで連携できるらしいし。
でもRational Suiteって一体いくらするんだろ。

やっとブロンズ30点取った・・。
１０回くらい受けたな（藁。

>>414
それって問題解いて UML を覚えようとしてないか？(笑

>415
あの問題って何げに初級レベルの本には載ってないような事も
たまに出題されたりして、新たな発見があったりする。

１度合格した後でも実力確認に便利。
まあもともとの動機は２４点で合格したのが鬱だったからだが。

すれ違いですみません。GangOfFour以外のパターンが紹介されているサイト
なんかがあったら教えて頂けないでしょうか？よろしくお願いします。

初歩的な質問だったらすいません
アクティビティ図に例外処理書きたいんですがどうしたらいいですか？

ここからここまでの間で例外が発生したら・・みたいな

今更すまんが
>>400
Java で言えば
　…＞ は インタフェースのimplements を示し、
　―＞　は has-a 関係を表す (ただし集約(―◇)ではない)
として使ってますが間違ってますか。

class SomeClass implements SomeIF {
　　…
}
の場合
┌─────┐ ┌────┐
│SomeClass│…＞│ SomeIF │
└─────┘ └────┘
であり、

class SomeClass {
　　OtherClass other;
　　…
}
の場合は
┌─────┐ ┌──────┐
│SomeClass│――＞│ OtherClass │
└─────┘▲uses└──────┘ (▲はほんとは右向き)

ってかんじ。

zureta....utu

Judeつかうとええよ>>419

>>421
探してみた、↓のことかな。
フリーなのはヨイ。使ってみます。多謝。
ttp://objectclub.esm.co.jp/Jude/

>>422
クラス図のテキスト出力あったでしょ？

だ、だれか例外の書き方を・・・

>>424
※印つけてかいとけば？

コメントにしろってこと？
「ここからここまで」みたいなのがビジュアルにわかりたい！
ってみんな思わないのかな。しょうがなくユースケースの
システム境界線もってきてコメント書いたりしてるけど、
UMLで決まってないのかなあ。

Integer.toString()が連続するときとか、それぞれに
分岐は絶対書きたくないでしょ？

>例外

シーケンス図の、矢印のうちの一本なんじゃないの？例外って。

Object間の、ちょっと経路^H^H毛色のかわったメッセージだろ例外って？

えーっと、とりあえずアクティビティ図で書きたいんだけど。

シーケンスはそうやって書くよ。つーか正常系の処理しか書かないこと多いので
シーケンスに入れないことの方が多いけど。シーケンスなら例外が発生する場所の
最後の部分（コードで言うcatchの位置）に書けばいいから悩まないけど。

ところで正常系と異常系ってちゃんとシーケンス分けて書いてる？
四角点線とかで囲って一枚の図の中に収めたいなあ

>ところで正常系と異常系ってちゃんとシーケンス分けて書いてる？

二つにだけ分ければ済むもんじゃ無さそうだな。
例外(が発生する個所)の数だけ、パラレルワールド(わら)の出現が
想定されそうなものだ。

というわけで、シーケンス図も、樹形図になるんじゃないのか？
ちと2次元の紙には表記できそうもないが。
世界の分岐をZ方向に取る3次元図なら、まだなんとかなりそうだとは思う。
あ。X軸はObjectの列挙、Y軸は時間、だとして。

あるいは、あるObjectのあるメソッドを取り出したフローチャート
(シーケンス図から1つのX=Nを取り出し、かわりにZ軸の自由度を与えたもの)
に、クリックポイントを作って他のObjectのフローチャートと
ハイパーリンクでもさせようか？


UMLの図って、しばしば2次元じゃ足りないよなーと思うものが多いなあ。
たとえばシーケンス図とコラボレーション図は
合体して3次元図にするほうが判りやすいだろうし
そもそも合体すれば2種類も要らない。つまり2次元に落とすために
わざわざ1つの表記を2つに分割する必要があったっていう感じ。

ま、好きなだけ次元を使っていいなら、はっきりいって
殆どの図を1つにまとめることが出来るっていう話に
なるんだけどな(わら
そこまでは無理としても、とりあえず1つくらい次元を増やしたいなあ。
3次元ディスプレイが欲しいー

φ(. . )
シーケンス図の３Ｄ化ね。
それもUML描けるアプリケーションに機能として取り込みます。

でも上司のハンコもらう最終出力は紙じゃん
3Dディスプレイと電子認証が一般化するまでは、
波線で囲って異常処理書きたい

つーかハンコ押す立場になってしまったのが鬱

>>431
うちは既に電子認証ですよ。

うーん、あまり厳密に図を書くことを考えなくてもいいんじゃない
かな。UMLを書くのは設計の意図を明確にするためだから、コメント
をつけることで例外処理を記述できるのならそれで充分でしょう。

なんでもかんでも図で表そうとすると、時間だけかかって返って
わかりにくくなってしまうんじゃないですか。

>>433
そうなのかも。
つーか、そのメモに誰が見たか、理解したか、承認したかの三段階で
描いておけばマチガイないでしょう。

> あまり厳密に図を書くことを考えなくてもいいんじゃないかな。

それとUMLで例外が*書けない*こととは別次元の問題じゃない？
コメントだと「どこからどこまでの間で」というのが表しにくい。
設計だけしてコーディングは外注にまかす（コーダーのレベルが未知かつ、
綿密なコミュニケーションが期待できない）こともあるので、
シーケンス図のメッセージ一つに対して１メソッド、クラス図で
変数名や関数名まで明記、という形にしたいんだけど。

>>432
電子認証ってどっかに申し込むの？詳しいこと書いてあるURL希望

つーか印鑑が浸透してるのって東アジアだけだよね？
お役所も含めて全廃しないかな。サインでいいよ。
筆跡鑑定を乗り切る偽造サインを書くより、印鑑偽造する方が
簡単でしょ。

このスレで紹介されていた
MagicDrawすごく良かったです。
サンキュー

>422
これは、殆ど使えない。この程度なら自分で作ったほうがまし。

>>437
テキスト出力のためだけに紹介したのだろう。

独習UMLってお勧めでしょうか?
私は、まだUML初心者、といったレベルですが。

>>439
習うより慣れろ。
とりあえずどんどんやってけ。
You must take your own risk if any.

>>428
シーケンス図は 1 枚が一つのシナリオ（ストーリー）に対応し、正常系と例外系は
別々のストーリーになるから、別々に書くのが普通だと思っていたけど、違うの？

だってーメンドくさいじゃん

それだけだけど

それだけじゃないや
異常系にどんなケースがあるのか把握しづらい。
せめて正常系と異常系を１セットずつで済んでほしい。
異常終了のケースすべてに対応するシーケンス用意するのいやあああ

やったぜオージスのシルバー合格！！
って俺4381人目でうけて4046人目の合格者みたいだけど
そんなに合格率が高いのか。。。

>>444
どこでうけたの？

Webで受けたけどなにか？

ところでオージスのゴールド受けようと思うんだけど
よさげな参考書しりません？Ｇａｍｍａのデザインパターン
からの出題とあるんだけど、実例の多い参考書教えてください。

ここに書き込みたくてとりあえずブロンズを取得してみました。

>447
ブロンズって簡単だけどＵＭＬの一通りを網羅してるし
各設問の質が高く量も豊富！オージス太っ腹ですね。

オージスの回し者ってわけじゃないよ。。。

>448の間違え！

一度合格しても、
何回もやってしまいそう。

ついでだから、シルバーとゴールドも公開にして
オブジェクト指向はゼロックスが作りオージスが広めた
そして両者とも同じ運命をたどった。

っということにしてくれればみな助かるのに。。。

>>452 オブジェクト指向ってゼロックスが作ったの？

協調図で、newというステレオタイプがあるのですが、書き方が良く分かりません。
メッセージと同様に、リンクの線の上に書けばいいのですか？

俺もシルバーレベルとったけど、ステレオタイプ全般いまいちよく分からない。

「これは、こういうときに使うんだ！」っていうのが分かりやすいものもあります
けどね。
createとか。
ただ、createでオブジェクトの生成を表現すると、「コンストラクタにこの引数
を渡して、生成する」っていうのが表現できない。
私が知らないだけで、実はできるのかな？

UMLを使いこなせるようになる日は、遠そうです。

>>456
> ただ、createでオブジェクトの生成を表現すると、「コンストラクタにこの引数
> を渡して、生成する」っていうのが表現できない。
> 私が知らないだけで、実はできるのかな？

同じとこで前に悩んだことがありました。
そのときは、その生成されたオブジェクトが引数のオブジェクトに依存する、
ってことになるんじゃないだろうかというところでお茶を濁すことにしました。

>>457
＞そのときは、その生成されたオブジェクトが引数のオブジェクトに依存する、
？？
ちょっと分かりにくいです。
createって書くと、引数を書く場所は無いような。

age

IIOSSの書籍出てるぞage
「IIOSS UMLに基づく設計/開発環境のすべて」ASCII 3800円。

自分が納めた血税(わら)がどう使われてるか心配な人は
立ち読み(ぉ)するとナニかが判るかも。

どれかってみるか：）
IIOSSの関連団体って民営化されんじゃなかったの？
どこだっけ？ETLだっけ？

C++のコードを読み込んで
UMLに展開してくれるフリーのアプリってないの？

>>462
C++なんざの需要が少ない(から無い)ってことじゃないの？(わら

とはいえ、特定の幾つかの言語しかサポートしてないUMLツールが多いのは
むかつくなあ。まぁ「Java的な言語」しか事実上サポートしてないUML自体が
悪いってのも有るけど。Interfaceをサポートしてるくせに特異メソッドを
サポートしてないってのは、えこひいきってもんだろう。

>>462
探してみて。リバースエンジニアリングできるのは少ないみたい。
http://www.objectsbydesign.com/tools/umltools_byPrice.html

UML使えると時給あがるかな

上がらないんじゃない？

独習ＵＭＬってどうなんでしょう。
読んで役に立ちますか。

http://homepage2.nifty.com/katuya/index.html

>>468
無関係なリンクはるなよ！

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
| BizCafeにもＵＭＬの本おいてくれないかなぁ。
＼＿＿ 　　＿＿＿＿＿＿＿＿＿＿
　　　　　∨ 　Sapporo BizCafe
　　　 ∧＿∧　　　　　　　　 　　∧＿∧　　　 ／￣￣￣￣￣￣￣￣￣￣
　　　（　・∀・）　　　　　　 　　　（´∀｀　）　＜　そうですね。
　　　（　つ　　）つ□　　　□ ⊂（　　　　）　　| オライリーだけじゃぁねぇ。
　　┃ﾚ ＿＿ 　 |￣￣￣￣ |　 ._＿＿ノ┃ 　＼＿＿＿＿＿＿＿＿＿＿
　　┗━┳┳＼ |￣￣￣￣|　./━┳┳┛
　　　　　┃┃　　|＿_＿_＿|　 　　

「この関連線、あっても無くてもいい」ってどうやって表現するのでしょう？
注釈で書いておくしかないのでしょうか。

普通は「あっても無くてもいい関連線を書きたい」なんてことを考える人はいないと
思うのですが、デザパタの図を書く時にはそういう表現が出来ると、嬉しいかなと。

０。。＊

>>472
あ。
そんな簡単な事に気付かないなんて。
頭かたいな、私。

保守age
今日からUMLの本格的な勉強を始める。
と同時に業務にも適用。
できるかな？

さてさてふむ〜〜

MagicDrawを買ってもらうことにした。
まだ確定ではないけど。
コストパフォーマンス的にMagicDrawが一番イイと思ったけど、
意見求む。

UMLじゃないけど､VisioのER図ってなんであの程度なんだ？
リレーションがフィールド指さないし（テーブル単位）
あれじゃ､Accessで書いた方がまし
設計書だよ設計書！

なんで下げ進行なんですか？

ageネタがないからでは…
MagicDrawはオンライン販売しかないのか。
サイトを少ししか眺めていないけど。

>>479
オンラインストアで購入すると、PDF 形式の領収書がメールで送られ
てくる。

>>480
そうですか。
他にUML描きソフトって何がありましたっけ?
数万円程度で購入できるUML描きソフトなんて
あまり無かったように記憶していましたが…
ちなみに、Visioという答えはダメという方向で。

>>481
UML モデリングツールののリストは >>464 のリンク先にまとまっているので、
こちらで探すのがよろしいかと。

Roseは高すぎage

.NETのβ２にVisioが付いてる！
これでUMLを書いてC#のコードを吐ける。
VisualStudioと連携できる！（前もできたけど）

Officeと合体しないと思いきや、
VisualStuidoと合体してしまった。
VisualModelerの立場がないけれど、
MicrosoftはUMLに本気らしいね。

それなのに、UMLステンシルの機能そのものは、
Visio2kと全く変わってなかった……。
何もかもが昔のままだよ……。

Visioのバージョンは2002ではなくXPだったよ。

Java言語で学ぶデザインパターン入門
で説明されてる集約(aggregation)は
UMLでいうところのAssociationですか？

この本の用語通りのUMLエディタがないので
よくわからないです。

>>486
書籍なりネットで調べればいくらでも書いてあると思うが。。。
関連 ( association ) の特別な場合が集約 ( aggregation )。a-part-of の関係だ。
より強い集約がコンポジション ( compositon )｡has-a の関係。

http://www.atmarkit.co.jp/fjava/rensai/uml02/uml02.html
http://www-6.ibm.com/jp/developerworks/components/010427/j_tip-objrel.html

CADでUML使う人っている？
ダイグラムをCADで書くってことじゃなく、車などの製品の構成要素をモデリングするって使い道。
あんまり聞かないんだけど・・・。

　 Λ＿Λ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　アゲ！
　（　　　　）　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜ ｜　|
　（_＿）＿）

>>476
年間保守もつけた？
どういうライセンスで買うか悩み中。
フローティングライセンスとかもあるしね。

>>488
いまは、ＵＭＬでデータベースもＸＭＬも表せるからなぁ。
標準の表記とかはないけど、関連に対して自分でステレオタイプを定義すればできると思うよ。
ちゃんと定義すれば業界標準にできるかもね。（まぁ、布教活動のほうが大変だろうけど。）

揚げ

　 Λ＿Λ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　このスレって人気あるの？
　（　　　　）　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜ ｜　|
　（_＿）＿）

そろそろゴールドレベル取った人いる？

UMLで単に関数(メソッド)が呼ばれる順序を表現するときってどんな図を書けばいいの？

↓例えばC++でこんなクラスの内部構造を説明するための図を書きたいんだけど…。

class CGoodClass
{
public:
　　void niceFunction()
　　{
　　　　int n = a();
　　　　b(n);
　　}
private:
　　int a(){ return …; }
　　void b(){ … }
}

ｽﾏｿ。ちょっとサンプルプログラムと日本語が変だから、訂正します。

-------------------------------------------------------------------------
UMLで単に関数(メソッド)が呼ばれる順序を表現するときってどんな図を書けばいいの？
↓例えばC++で書いたこんなクラスの内部構造を説明するための図を書きたいんだけど…。

class CGoodClass
{
public:
　　void niceFunction()
　　{
　　　　int n = a();
　　　　b(n);
　　}
private:
　　int a() { return …; }
　　void b(int n) { …; }
}

>>495
シーケンス図
個人的には private なメソッドに図は必要ないと思うけど。
（全部一つのクラスで済ますようなのは設計がおかしいので）

>>497
privateメソッドかどうかはともかく、自分自身を呼び出すシーケンスも書け
ますね。

iiossのMEFはどうよ。

>>499
私もしりたい。どこでもいいけど、よく説明したサイトないかな？

>500

ttp://www.iioss.org/index-j.html
Magicdrawの試用版よりは断然いいよ多分。
Roseも高いし。
イイオスマンセーになりそう。

>>501
さんくすこ。
まだ触りしかいぢってないけど、何となくマンセーな予感。

iioss のデモが、今週の金曜の夜にあるみたい。
UML-jp あたりには流れるんじゃないかな？

JAVAやC++だけではなくて
いわゆるOOPLと呼ばれていない言語への適用のしかたも知りたい。

>>503

oosquareだろ？マンセーって出てやや鬱なんだけど・・・
それにしても、なんかmagicdrawと比べてシーケンス図描きにくくない？

UML等の図をテキストのAAに変換するツールありませんか？
上にあった、Judeの出力は、あまり美しくない。

はるか昔、UML以前のOMTなどを奇麗に描けるドローツールがNiftyのプログラミングフォーラム
にあったんですけど…。

図をメールしたり、掲示板にｶｷｺするときに使える。

みつけた。

http://www.osk.3web.ne.jp/~shino/dev/DICON/DICON.html

どうでもいいけど、イイオスじゃなくてイーオスです。

>>508

なんだコイツ(藁
IIOS本にイイオスと読めとかいてあるけど何か？

間違えた。

×IIOS本
○IIOSS本

どうでもいいけど。

>>509
そりゃ、MagicDraw の方ができはいいさ。

>>506
Judeならクラス図をテキストに出力できたよ。

UMLってKylixやDelphiでも使えるの？

>>509
ﾈﾀﾆﾏｼﾞﾚｽ､ｶｺﾜﾙｲ

>どうでもいいけど。

ｽｺﾞｲｺﾀﾞﾜﾘｶﾞﾐﾗﾚﾏｽ(ﾜﾗ

>>514

どういうネタだよ。。。さっさと氏ね。

イイヤマではなくイーヤマです。

マ版逝け。

age

シナリオがめんどくさい。
有効だといわれれば納得はできるが、生産性を考えると
とてもめんどくさい。
みなさん書いてますか？シナリオ

シナリオ書いてません。

「ユースケース入門」わかりやすくていい。
おすすめだ。

>>521
これ？
http://www-6.ibm.com/jp/developerworks/components/010803/j_co-design5.html

>>522
これ。薄いからさらっと読める。
分析と設計の隙間を埋めるのにロバストネス分析を使っていて、ちと参考になった。
http://www.amazon.co.jp/exec/obidos/ASIN/4894713772/ref=sr_aps_d_1_1/249-8637940-9573946

UML勉強したいんだけど、入門にはこれ買っとけって書籍あったらおしえて。

>>524

みんな持ってるファウラー本。
http://www.amazon.co.jp/exec/obidos/ASIN/4881358642/qid=1006660688/sr=1-1/ref=sr_1_0_1/249-9814225-6872300
手元に置くと便利。
http://www.amazon.co.jp/exec/obidos/ASIN/4894711559/qid=1006661504/sr=1-10/ref=sr_1_0_10/249-9814225-6872300

シルバー取った人って何を参考に勉強したの？
俺はとりあえず、ﾘｱﾙﾀｲﾑUMLっつー本を買ってきたんだが。

>>523
マニュアルからプログラムってなんか逆説的。

>>527
CGI の Web アプリでやってみたら何気に面白かった。
マニュアル→画面デザインを書いた時点でできあがった気分になるけど（ｗ

UML Press創刊記念age
http://www.gihyo.co.jp/umlpress/

すでに第一号でネタ切れっぽくないか？

>530
単発雑誌かと思った（藁）

ゴールドレベル（デザインパターン）のカードがやっと届きました。
４ヶ月も待たされただけに、シルバーより格好良いカードが届くと期待していたのですが
銀が金になっただけでした。
無料なので贅沢は言えませんけどね。

こんなのもあります。メニューとマニュアル(PDF）が日本語でフリー版あり
ttp://www.tech-arts.co.jp/product/product.html

私もＵＭＬ　Ｐｒｅｓｓ１号かいました。
デザインパターンを読んでいるところです。

Ｃ＋＋やＪａｖａもいいんですけど
Ｃでかかれたものをラッパークラスをつくらないで
リファクタリングしていくなどという記事も載せて欲しい今日このごろです。

ｺﾉｽﾚｽｸﾞﾆｻｶﾞﾙﾈ

Cﾏｶﾞｼﾞﾝﾄｶ
ｻｶﾝﾆUMLﾂｶｯﾃｲﾙﾝﾀﾞｹﾄﾞ
ｺｺﾃﾞﾊﾓﾘｱｶﾞｯﾃﾅｲﾈ

>>534
漏れもUMLプレス買ったYO!
デザパタのたとえが笑った。
Mediator‐孔明がすべての部隊の面倒を見ます。

ゴールドレベルで玉砕した。
「90点は超えただろ」とか思いつつ自信満々で送信したら、
68点だとさ。
自信あった分野だけに、ほんと死にたいくらいの屈辱。
首括ります。

>>535
Cマガは出遅れすぎ。
Java World なんかはずいぶん前から UML を盛んに取り上げていた。
つーか今月の状態遷移うんぬんの記事は橋にも棒にも。
地域通貨のアホ記事もねじ込まれたのかねえ。

>>536
「ぼくにもわかるデザインパターン」って小学生かい、と突っ込みを入れたくなったよ。

>>538
たかが北大教授のLETSの記事じゃなぁ。
でもああゆうのが後で大化けするんだよなぁ。

>>583
JavaWorldはそうだねぇ。

CマガジンはC++ではなくCへのデザインパターン適用記事を
誰かに書かせるべきだ。

>>540
CマガのCはC言語のCではなくコンピュータのCです。

>>540
だれもここでそれ以外のこと主張してないって。

Cマガへのご意見ご要望苦情などは編集部か下のスレへ

Ｃマガを語る
http://pc.2ch.net/test/read.cgi/tech/992194388/

>CマガジンはC++ではなくCへのデザインパターン適用記事を
>誰かに書かせるべきだ。

そこまで濃いことを書けるCハッカーがCマガ側には居ないんだろうなあ。
米国記事だと望みはないでもないが。

米本家DDJでは、それ系(?)の濃い記事が目白押し。
層の厚さってのを思いしらされる。

訳判らん用語並べて悦に入るな！
設計書は画面構成図とか皆に判るように書こうＮＥ！

>>544

既に誰か書いてたよ
http://www.sage-p.com/process/cool.htm

magicdrawで書いた図をwmfで出力して、PowerPointなどで
取り込んだのですが、日本語が文字化けします。なんとか
なりませぬか？

wmf?

>>548
http://www.jisyo.com/viewer/list/W.shtml

>>549
なるほど。
>>547
自分もやってみたが、化けた。環境設定を日本語にしたけど
だめ。

>>533
PatternWeaver使ってみたけど出来悪いね。
ＭＬも最悪だし。

>>551
自分も使ってみました。つかいにくーい。
な○せさんとこでしょ？売ってるの。

>>552
な○せさんの所はな○せさん以外はＶＢ専門の人ばかり。

あげとくよ

ファウラー本っていい本ですか？
自分にはよくわからなかったです。
もっと簡単なのでいいのってありますか？

http://www.omgj.org/umlrobo/

　 　 Ａ＿Ａ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　だからAAっていうのか。なっとく
　（　　　　）　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜ ｜　|
　（_＿）＿）

クラス図を書いていてクラスの数が増えてくると、汎化と関連の線を
１つの図に書くと線が入り乱れてわかりにくい場合ってないですか？
理想的には線が入り乱れないようなすっきりした設計ができれば
いいのだけれどそれができない場合、汎化の図、関連の図と分けて
書いたりしてもいいんですよね？みなさんどうしてます？

>>558分けて書いたほうが分かりやすい。

お前ら！
参照先のオブジェクトが一つ（IDオブジェクトなど）でも、
参照もとの一部分となっている場合は集約としてよいですか？

class A{
IDClass B;
Vector members;
}

class B{
}

みたいな時、membersは集約で表せると思うんですが、
Bは集約なの？ただの参照？

ちゅうかUMLよくわかんなさすぎ。

UMLの使えるレベルを考えよう。

まずは、自分の考えの整理のために使えば。
ローズなんかで、びちっとドキュメントするのは
もっとあとの話。

手書きﾏﾝｾｰ
ツールを使うのは客に収める必要があるときだけだーよ

>>560
>参照先のオブジェクトが一つ（IDオブジェクトなど）でも、
参照もとの一部分となっている場合は集約としてよいですか？

いいんじゃないですか。

>みたいな時、membersは集約で表せると思うんですが、
Bは集約なの？ただの参照？

これだけ見ると、コレクションかどうかの違いしかないと思うんですが。

>ちゅうかUMLよくわかんなさすぎ。

厳密な定義が本当に必要かどうかも考えましょう。

今月のDBﾏｶﾞｼﾞｿの特集＝UML

ogisUMLも復旧したようだからシルバーでも受験してくるかな。
自信ないけど・・・。

XMLも面白そうだからシルバークリアできたら勉強してみるか。

class Super{
}

class Sub{
}

class Use{
public static void main( String[] args ){
Sub s = new Sub();
}
}
これをＵＭＬのクラス図で書いてみな？

class Use{
public static void main( String[] args ){
Super s = new Sub();
}
}
また、こうした場合のクラス図をかいてみな？

UML使いこなしてる人って
やっぱりomgのサイトの公式ドキュメントを
読むのかな？英語に問題がなければ
おれも読みたいよ。w3mやrfcもそうだけどさ。

>>566
二つ目はコンパイルエラーですね。

哲学的な話になるのかもしれませんが、
オブジェクト間の関係は、
dependency,association,generalization
の三つしかないのでしょうか？
これって見つけた人は天才？

class Super{
}

class Sub extends Super{
}

class Use{
public static void main( String[] args ){
Sub s = new Sub();
}
}
これをＵＭＬのクラス図にすると

|Use|−−−＞|Sub|−−−−△|Super|

で、よいのですか？

class Use{
public static void main( String[] args ){
Super s = new Sub();
}
}
また、こうした場合のクラス図は、

|Use|−−−＞|Super|△−−−−|Sub|

で良いのですか？

私も、570のクラス図の書き方があっているかわかりません。
私が解釈したのは、Useクラスが他のクラスをどう扱うかだと思います。
前者の問題では、SubのフィールドにSubオブジェクトの参照を入れているから、
UseのアソシエーションはSubに向かっているで良いと思います。
後者の問題では、SuperのフィールドにSubオブジェクトの参照を入れているから、
Useは、SubのオブジェクトをSuperのオブジェクトとして扱うので、
UseのアソシエーションはSuperに向かっているで良いと思います。
皆さん本当はどうなのでしょうか？
私は合っていると思いますが、私もまだ初めてから３ヶ月なので自信がありません。
教えて下さい。（はぁ〜と）

>570
良いんでないの

>570
うおぉ〜なるほどぉ〜。
これは勉強になりました！！！
この辺ってどの本にも載っていない事じゃないですか。
入門プログラマーが一番必要としているのはこんな部分ですよね。
いままで後者の方も
変数の型はSuperですが、実物がSubのオブジェクトなので、
|Use|−−−＞|Sub|−−−−△|Super|
かなぁ〜と思っていました。
ありがとうございました。

正直、関連と集約の違いが説明できない。

>>571
それでいいんでないの？

>>567
OMGのPDFが一番シンプル分かりやすいのには同意

>>570
UseクラスがSubのインスタンスをSuperで受けている理由よって
変わってくるじゃないかな？
人よって違うしクラス図のみだけでなくシーケンス図等もあわせ
て考えることも必要だと思うよ。
それに同じクラス図でも実装は複数存在することもあるからね。

>574
アソシエーション（関連）とアグレゲート（集約）って、
ソースコードに落とすと、私は殆どが以下のようになると思っています。
アグレゲートって、has-aの関係を適用して、クラスのインスタンス変数で保持して使う。
アソシエーションの場合は、メソッド内で一時的にインスタンス生成して使う。
必ずしもそうじゃないと思いますが、殆どの実装パターンがそれになっちゃうと思うなぁ〜。

私が良く分からないのは、アグレゲートとコンポジションの違いかな。
コンポジションなんかはインスタンス生成時に配列でオブジェクトを作っておいたり
しますけどねぇ〜。

UMLプレスのvol2っていつ発売されるの？

>>580
それは禁句だ。

>574,578
一応説明のあるページを紹介
ttp://www.asahi-net.or.jp/~dp8t-asm/java/tips/UMLClassDiagram.html

オレとしては
集約は共通で使用するインスタンスを管理する場合
コンポジションはインスタンスの管理に特化して所有権が
移動しない場合
その他は関連
でもコンポジション使用しないで集約にしておいて実装時決定する感じ。

>582
なるほど。
考え方ですよね。
同じ実装方法でも、考え方の違い。

おおジス総研のシルバーレベル試験に、この半年間に受かった人いる？
何点くらい取られました？

俺、以前から逆に２０点ほど下がってしまった…
受かるのはいつになるやら（＾＾；

今日会社で資料を状態遷移図で書いたら
読めないからフローチャートで書き直せって言われた(鬱

>585
今度はシーケンス図で再チャレンジだ!（ｗ
状態遷移図ってUML以外でも結構使われるんだけどね。

UMLてDBのテーブル設計ためにあるの？それとも言語のため？
なんかそのあたりがわからん

>578
オレもあまり詳しく知らないんで間違ってるかも知れないけど
オブジェクト指向設計のための表記法で分析と設計の両方で使われるはず。
DB設計にも流用可能だと思うよ。

>>587
クラス＝テーブルって訳じゃないだろ。

Poseidon for UML
　http://www.gentleware.de/jobs/index.php3
IIOS
　http://www.iioss.org/index-j.html

だれか両者の関係知らん？

知ってる。

>>547
いまさらなタイミングで書くけど、MagicDraw 5.0SP1 だと、メニューバーから

1. [オプション] - [環境] で「環境のオプション」ダイアログを開く
2. 左側のツリービューで [一般] を選択
3. 右ペインに表示される [WMF文字セット] を「シフトJIS」に設定

で出力した WMF ファイルを Word2000 に張ったら、印刷できたよ。

Chen君がやってた関係クラスがリレーショナルＤＢのテーブルなのかな？

>>587
DBのテーブル設計のための図は雰囲気の似た別のやつがあるでしょ。ER図だっけ？
UMLのクラス図の文法ってこれを下敷きにして作ったような気がする。

スリーアミーゴの書いたこの本
はたしてUMLのバイブルになりうるのか？
誰か読んだ人感想プリーズ

http://www.amazon.co.jp/exec/obidos/ASIN/4894712679/qid=1014735082/sr=1-5/ref=sr_1_2_5/250-0132920-0658615

感想プリーズ

http://www.amazon.com/exec/obidos/ASIN/020130998X/
この本、もう古いよ。もしかしてUML1.1なんじゃないの？
今はもう1.4が標準的に使われつつあるよ。それでもいい、
基本的な概念が知りたいんだっていうならいいかもしれないけど。

>>587-589,>>593-594
オブジェクト-リレーショナル・マッピングの手法
(いかにRDBとOOPLのセマンティック・ギャップを埋めるか)って、
Rationalがなんか名前付けて出してた、と思う。

漏れは Infomix Universal Serverで有名な　
Stone Brakerさんのブックレット(ORDB本)読んで、
試行錯誤したクチだけど、
こないだDOA向けCASEツールの説明会パンフレット見せてもらってたら、
「OOにもこんなに対応できます」みたいな説明にその手法が載ってて、
初めて知りました(鬱

プロジェクト管理に関する本が読みたいです。
有名な本となるとやっぱりboochのこれかもしれません。
http://www.amazon.com/exec/obidos/ASIN/0805305947/

が、しかし如何せん古い。RUPに則した形でかつ
もっとつっこんだ内容の本はないでしょうか？
英語の本で構わないので。

>>599
Rational.com近辺の、大量のドキュメントの中とか、
日本ラショナルの教育で、そーいうのを扱ってると思うんですけど...
漏れも知りたいので、ご存知の方お教え下さい。

>>600
rationalのサイトみたけど、いいドキュメントは
なかったな。
いろいろアマゾンで検索しても
boochの本より良さそうなのはなかった。
上のヤツを買うよ。

漏れは、RUPはラショナル製品買わないと、
情報なし/意味なしかと考えていたんで、
RUPでのプロジェクト管理について本気で探していませんでした。
今日探してみます。

んで、RUP DQNな漏れは、こんな本読もうとしてますです。
　「ソフトウェアプロジェクト管理―21世紀に向けた統一アプローチ」
　http://www.amazon.co.jp/exec/obidos/ASIN/4894715597/qid=1015207724/sr=1-14/ref=sr_1_2_14/250-4956143-4769858
　"反復型ソフトウェア管理プロセス" に関する本で、
　RUPに限らず スパイラル開発、反復型開発全般に通用する話だろうと予測してます。

Smalltalkの親玉が書いた、こっちの本も興味あるけど、まだ買えてない...(泣
　「オブジェクト指向開発のプロジェクト管理―ケーススタディとフレームワーク」
　http://www.amazon.co.jp/exec/obidos/ASIN/479529707X/qid%3D1015207855/250-4956143-4769858

http://www.amazon.com/exec/obidos/ASIN/0201309580/
>>602
この本はレビュー読む限りじゃRUPに則しててなかなかよさげですね。
翻訳は日本ラショナルがやってるからどっちにしようか迷いますｗ。
（基本的には個人で翻訳したOO関連書籍は買わないことにしてるので、）

UMLのDB設計への適応についてメモ
DB設計は往々にしてUMLの静的分析のみで行われがちであるのは
ダイアグラムがER図のみであることから容易に推測できる。
UMLのクラス図の様にユースケースや状態変移図、シーケンス図等
の動的分析の工程加えることにより洗練された設計が可能とおもわれる。

と個人的見解をカキコしてみるtest

>>604
http://www.tech-arts.co.jp/oo/uml.html#003_4

参考になると思われ

とカキコしてみるtest

MagicDraw 5.0はここから国内販売するみたいだね。
http://www.hic-soft.co.jp/news.html

>>606
「2002年発売予定」っていつのことだろう。
Webページの最終更新日が去年の11月だよ、大丈夫かいなこの会社。

実際どうなんだろう、この手のツールって生産性あがるのかな。
個人的には手書きとVisioで充分な気もしてるんだけど。

>>607
> 実際どうなんだろう、この手のツールって生産性あがるのかな。
絵を書くのは楽になる。

特に、

- 一度書いた絵に修正を加える。
- クラス図で、ある図では A, B, C クラスを、別の図では B, C, D, E, F クラスを
　含めるような場合に、最初の図で設定した依存関係や継承関係を、簡単に次
　の図に反映できる。

ってあたりが便利。

私は昔は UNIX で Tgif という汎用ドローツールを使ってたんだけど、細かい
修正が面倒で使うのやめた。今は MagicDraw 使ってるけど、それなりに便利
だよ。

ただメソッドの仕様なんかを細かく書くと、ソースコードと同期をとるのが面倒
なんで、

- 主要部分だけ MagicDraw で図に書いておく
- メソッドの仕様などは doxygen 形式でソースコード埋め込み

と使い分けてる。

MagicDraw は試用もできるから、とりあえず試してみたら？

validationが出来るものはどれになるんだろ。
MagicDrawは作図機能は評判がいいみたいだけど、
そっちはどかな？

シルバー合格に効く本を教えてくれ！！！

>>608
>- クラス図で、ある図では A, B, C クラスを、別の図では B, C, D, E, F クラスを
>　含めるような場合に、最初の図で設定した依存関係や継承関係を、簡単に次
>　の図に反映できる。

別にコピペでいいじゃん、、という気もするが（藁
ある程度の規模のダイアグラムを書いて、継続的にメンテしなきゃならないような
状況だと効いてくるんだろうな。

クラス図だけならVisioでも良いけど状態変移図やシーケンス図とかは
Visioでは辛いと思うのはオレだけですか？

当方、UMLを始めようと思っています。
もしプロジェクトで掲示板（Webアプリケーション）をUMLで表現しようと思ったら、
何から始めるのでしょうか？
その際なんですが、クラス図とか、シーケンス図、とか全てが必要になってくるのでしょうか？
自分はプログラマなんですが、普通のアプリケーションならクラス図とかは必要だと思うのですが、
掲示板とか簡単なWebアプリケーションならクラス図はいらないと思ったりするのですが・・・。
そこんとこはどうなんでしょう？

例えば、掲示板で書きこみをDBに保存して、その１つの書きこみを１つのクラスとして
java ex)
public class message{
private String date;
private String author;
private String email;
private String message;
....
}
扱う（マッピングする）なら、クラス図とかも使用できると思うのですが、
現実では、１つの書きこみをわざわざ１つのクラス（インスタンス）にしたりしませんよね？
表示するときは、書きこみをDBから取ってきて、直で表示するようにしますよね？

ん〜、難しい・・・。
オレは、UMLを根本的に理解してないんだろうな・・・。

作図のみだけど、DynamicDraw。 軽いのが(・∀・)ｲｲ!!
http://www.molips.com/jp/index.html

>>613
自分と全く同じところで全く同じ悩みに嵌まってますな。（ｗ

自分は一度すべてをオブジェクトとして扱うようなＵＭＬの諸図を書いて、
いざ実装しようとしてワケワカに陥った末、結局ベタにコーディングしてから
リファクタリングしていくほうがうまくいったというオチでした。

ＵＭＬを設計の道具として使うか、発想の道具として使うか、日本人は前者と
して抱え込んでしまいがちだけど、業務として要求されない限り後者として書
き捨てていくほうがいいように思った。

今IIOSSを使ってるんだけど、
これってパッケージのネストは出来ないの？

>>615
UML は実装する前に方針を決めるとき、特にイテレーションの過程で次の機能を
実装するときに、

- 今、どうなってる？
- 次に、どこをいじればいい？

というのを見るために使ってる。主要なものだけ書いておいて、詳細は含めない。

書き捨てちゃっても良いけど、図の量を減らして常に up-to-date に保てる程度に
しとくと、役に立つ場面も多いよ。

あ、ごめんごめん。できた。すまそ。
それにしても遅いな。やっぱりJavaアプリは
1GHzぐらいないと厳しいかもね。

615>>
617>>

お〜、同士がいたかぁ〜。
やっぱりそんなものなのかにゃ〜。

>>613
俺もそう考えちゃう。気持ちがわかる。
>>613のような状況ではどうすべきだったわけ？

・ちゃんとUMLで設計したように、プログラミングすべきだった。
・べたでコーディングしてからUMLにする。→どうやって？

だれか教えてクレー

私もそんなの始めてます。
私の理解だと、

要求される機能の分析のための最初はユースケースです。
次に抽出されたアクタからクラス図を書きます。
次に要求される機能から管理者ログインなどの手順のシーケンスを図にします。

フローは不要でしょう。あれはソース読めない人が
設計がおかしくないかと騒いだときに出す資料だと思います。
だって、ソースより可読性悪いもん。
今時のアルゴリズムの本だってフローチャート載せてなくて
片言ALGOLかPascalかJavaかCだし。

>>621
複数の言語で非同期でコールバックしてる場合は必要だと思いますが、
如何ですか？

>>623
読めないソースは多い。

非同期のコールバックってシーケンス図とか状態遷移図で表すような。

フローって昔懐かしいフローチャートのこと？
それとも別の何かですか？

>>624
UML でフローチャートっぽい図と言うと、アクティビティ図かねぇ。

613の質問をだした者ですが・・・。

>>623
の方は、何故、自分自信に返信しているんですか？
コールバック？　それとも再帰？　(W

俺のやり方（Webアプリの場合）

1.画面遷移のモックアップを作成 紙に手書きしてから HTML でざっと
2.使う技術・ライブラリを選定し、クラスを大雑把に抽出しておく
3.ユースケースを書く。たまに変なシナリオを書くのに熱中
4.クラス図を書く。前に抽出したクラスは半分忘れておく
5.必要に応じてシーケンス図、ステートチャート図、アクティビティ図を書く
6.コードにおとしつつ 3-5 を繰り返す
7.コードを書きつつ 4-5 を繰り返す

アクティビティ図って
（データフロー＋フローチャート）／２ぐらいだと思いますが

>>627
モックアップって何なんでしょうか？

やっぱり実際に使って、描かないと覚えれないなぁ…

そんな私は組み込み系…

>>626
そのとおり！

>>629
プロトタイプでもいいや。

｜モックアップ
｜ 【mock-up】
｜原寸模型。実物大の模型。

>>630
全部覚える必要あるのかね？

アクティビティ図で並列処理部分を描いて初めて
folk()がフォークだったと気づきました。

>>613
>現実では、１つの書きこみをわざわざ１つのクラス（インスタンス）にしたりしませんよね？

いや、すると思うけど。普通に。
その例の場合は message クラスを RDB のテーブルにマップして、インスタンスをその
テーブルの行にマップするのが定石じゃないかな。

>>635

613の質問をした者です。

>いや、すると思うけど。普通に。
え？　普通に？　マジで？　しかも、定石なの？
その際の、利点とスピードは？
掲示板の例でいうと、１画面でもしも２０個の書きこみを表示する場合は、
２０個のmessageクラスのインスタンスを作っちゃうの？

EJBのEntity beanは、そういう方法だけど、やっぱり重すぎないですか？

>>636
613さんはプログラマなのかな。実装レベルの話と分析・設計レベルの話を
ごっちゃにしてる節が見受けられるような。。。
UMLはあくまで記法なので、その奥にあるオブジェクト指向開発への理解を
深めるのがいいと思うですよ。

オブジェクト指向分析の過程で現れたエンティティをRDBにマップする例で
参考になりそうなWebページを紹介しときます。

5、UMLを使用したデータモデリング
http://www.tech-arts.co.jp/oo/uml.html#005

UMLによるオブジェクト指向開発
http://www.mamezou.com/tec/Tips/umlForPractice/index.html

>>637
613じゃないけどありがと。
他スレで触発されてRUPの本を読み始めてたけどどうも分からんかった。
637さんの一言でなんとなく糸口見えてきたかも。

要件分析をユースケースで行い、
モデル分析で抽出したモデルをインターフェース／抽象クラスとして、
設計・実装過程で、インターフェースをクラスで実装する、
という感じらしいですね。

でも、モデリングになれていなかったり、アーキテクチャ・レベルの課題を解いていると、
前半部分をすっとばしがち。
(PGオンリーだと、モデルは天下りに決定済、という前提が多いしね)

んで、リファクタリングでインターフェースやモデルを抽出したりしてね。
ボトムアップな作り方をする人やグループが、
いきなりトップダウンに移行するのは、難

やっぱり思うのは、UMLがいくら方法論非依存なものだとしても
なにかしらのものとセットで覚えないとだめかもね。
おれはとりあえずRUPの本で色々試しながらやってみるよ。
一人で顧客になってみたり、ユースケースエンジニアになってみたり・・・

おままごとみたいだな（藁

＃掲示板て、EJBよりXSLT向き課題って感じするけど

>>641
誰もEJBの話なんてしてないよ・・・。

日下部先生に
「作って分かるRUP」を書いて欲しい！

>>642 　　〉〉636

>>644
掲示板でEJBとか言ってるんじゃなくて、DBのROWを１つのクラスのインスタンスにマッピングする
方法がEJBのEntity Beanと同じって言っただけです。

前のメッセージをさかのぼってもらえれば分かります。

>>643
Roseの評価版にチュートリアルがある

>>645 あ、誤爆すんません。

＞DBのROWを１つのクラスのインスタンスにマッピングする方法
ﾏｲｸﾛｿﾌﾄの DAO とか ADO あたりのクラス設計でも、
御馴染みですよね。

ﾏｲｸﾛｿﾌﾄ環境では「パフォーマンス悪いから」と、
わざわざODBCレベルでプログラミングするC/C++ プログラマの方が、
私の周りには結構いたみたいです。

>>645
それやりたいんだが量が多すぎてめんどくさいなり。
ま、実際には(Delの話だが)TDataSetが代用になるからいいんだけど。

Javaに移行したら本格的に取りかかってみよ〜。

１．コンビニにいく。
２．普通に買い物をする
３．なにくわぬ顔で店を出る
４．数分後、息を切らしてコンビニのレジにかけよる
５．「お、おい！さっき俺がこなかったか！」と叫ぶ
６．「あなたが買い物していったんですよ？」と店員に言われる
７．「ば、ばかもぉ〜ん！それがルパンだ！追えぇ〜！」と、叫びながら店を出る

＃６．で「知りません」と言われたら以下のシナリオを実行。

７’．「キ、キサマがルパンだなぁ〜？」と店員のむなぐらをつかむ
８’．警察へ通報される
９’．「ま、まて！！わ、わしゃあインターポールの銭形だぞ〜！」と叫びながら連行される


↑このコピペはユースケース記述を中途半端に知っている人物が
書いたのだろうか？

フリーで使える「まともな」UMLドローツールって無いかなあ。
クラス図だけでいいんだけど。

Jude1.2,1.3とArgo/UMLを試してみたけど、どっちもしばらく使ってるとデータがぶっ壊れて
図が２度と開けなくなったり、いきなり無言で落ちたりして使い物にならん。
JREのバージョンをとっかえひっかえしてもたいして効果なし..

>>650
フリーバージョンがある、
Pattern WeaverやMagic drawは？
Magic drawはセーブ時に要素数の制限があるから、一生懸命書いてセーブできないと悲惨だけど。

>650
あとIIOSかな？

JAVA向けのページだけど此処結構揃ってるYO!
ttp://www.geocities.co.jp/SiliconValley/6064/java_link.html

IIOSSはJavaに特化しすぎててむかつく。
あんなクソ言語つかわねえっつーの

>>651-652
ありがと〜早速試してみるYO!

これから実プロジェクトにUML使ってみようと思っているのだが、DBはOracleが
圧倒的に多いし、RDBMSは設計、管理...でERが便利で手放せそうにないし。
クラス図だけだとちょっと辛そう。UMLとERを両方とも使っていきたいんだけど
どんなもんだろう。

>>655

プロジェクトで UML 使うってのは、どういうことでしょうかね。

「かんたんUML」とかに書かれていることを、そのままやろうとしたら
多分、うまくいかない（と、思うんだけど、どうでしょう）

XP的には
「どうせクラス構成なんて開発中に変わるもの」
「せっかく作ったクラス図だって時間がたてば古くなる」
「その種のドキュメント書きは無意味」

俺のお薦めは、開発中はすべて手書き。
ホワイトボードかA2くらいの紙を壁に貼った上にね、マジックでぐりぐりと。

みんなの見えるとこにおいといて、そこに書ききれないような細かいのは書かないの。
使用がかわったらすぐに書き直し。

プロジェクト終了後と社外の人に見せるときだけ瞬間的に清書。

開発が再開したら、また、同じことするんだぞ。

そう。初めはUMLツールなんかは使わないのが吉。
ホワイトボードと、PostItの四角形の奴を使うと書き直しが楽だよ。

>657
クラス図は手書きでも構わんけど
状態変移図とかはどうしてるの？
手書きだと修正がつらくね、やり直したい時とか？

オレの場合は一応紙とツールで書く、ただし細かい部分は省略、
プロトでとりあえず自分の中で不明確な点を確認、思いついた
アイデア等は図をコピーして反映する。

>655
すでにDBが存在するならUMLの出番はDB設計においては殆ど無し。
ただし新規作成ならUMLの分析は有効なはず。>604のリンク先参照

>656
>「どうせクラス構成なんて開発中に変わるもの」
これはUMLでも同じ考え、ただし変化を考慮してパターン等
を使用して大幅に変わらんようにする。

>「せっかく作ったクラス図だって時間がたてば古くなる」
>「その種のドキュメント書きは無意味」
UMLは厳密言うとドキュメントではない気がする。
ただの設計過程での思考経過を表すメモでしかない。
それにドキュメントは時間がたてば古くなるのは嘘
仕様変更が無ければドキュメントも常に最新
UMLは設計変更に対応する際の対応方法を考えるのにも当然使用される
べきでその結果UMLは常に最新になるはずなんだけど･･･
現実にうまく行ってる所は知らない。

>>「せっかく作ったクラス図だって時間がたてば古くなる」
>>「その種のドキュメント書きは無意味」
>UMLは厳密言うとドキュメントではない気がする。
>ただの設計過程での思考経過を表すメモでしかない。

んだね。「クラス構成が変わる」というが、そのクラス構成をより良く変える過程で
道具として使うものだと思う

メンバ変数やメソッドを逐一記述するヤシはそういないだろ

壁に手書きっていうのはね、大きな意味があってね、

「書き直すのが面倒な図は、悪い設計」

てことなの。

状態遷移図は、細かく書き始めると確かに大変かもしれないが、
紙の上で書き直してて、もしくは付け足してて面倒だと思ったらね、

「この状態遷移は悪い遷移。もっと簡単にしる」

ってことなの。

経験からいってもね、手書きでOKなレベルでないと、
プロジェクトの他の人がその図を見たとき、
把握できないのよ。

大切なのは、何が重要なのか、を見せること。

重要な何かが、どれと関わっているのか、を見せること。

状態遷移は、定型的なパターンを図示できればOKで、
部分ごとの細かい遷移については、あくまで、壁に貼ってある図の
「発展系」なんだって認識でやればいいの。

具体的に一個一個書きたい気もわかるけど、
重要なパターンというのは数えるほどしかなくて、
しかも大体それは、小学生でも書けるような、簡単な遷移図であるべきなんだよ。

>>661
大雑把なところをプロジェクト参加者全員で共有するという話だと「手書きレベル
で OK な図で留めとけ」というのは、間違ってないとは思う。

ただ通信プロトコルにせよ何にせよ、実際には複雑な状態遷移と対峙すること
が多い。簡単にしすぎると

　性能
　効率
　安定性

どこかで致命的な妥協を要求されるから。(TCP/IP も基本的な部分は簡単だ
が、実際に OS 組み込みのプロトコルスタックを組もうと思ったら、タイマーが
並行して何個も走ってる複雑な状態遷移機械になるよね）

俺は、実装者向けの図としては詳細まで書いた方が良いと思うよ。もちろん、
図に書かずにコードで書くという選択肢もあるが、経験的には図を書いた方が
ロジックミスを防ぎやすいし。

>>662
実装者が、詳細レベルまで書き下ろすことについては否定しない。
で、そういう実装レベルの図を、ドキュメント化して、実装と同期をとることも
否定しない。

そもそも、いままでそういうのを図示する共通のやり方がなかったわけだからね。

そして、たぶんその図は壁には貼られないだろうけど、
仕様のレビュー時と、コードのレビュー時に、大いに役立つだろうね。

でもおれんとこのだと、そこまで細かいものは、書く人は書く、
書かない人は書かない、で仕事しちゃってるんだよね。

徹底させてるのは、例の、壁に貼るやつだけなんだ。

655です。
>659
>すでにDBが存在するならUMLの出番はDB設計においては殆ど無し。
>ただし新規作成ならUMLの分析は有効なはず。>604のリンク先参照

これは分か気がするし勉強してみるけど、すでにDBがある場合は、
コードの設計をUMLでやりたいし、新規作成の場合も、最後はERから
DBへ落としたいので、いずれにしても最終的にUMLのドキュメント
と、ERを共存させたいんだけど。
それとも切り替えるのかなー。ここらをどうやってるか聞きたかったわけ。

あと、手書きでホワイトボードうんぬんの議論は分からないではないし、
議論はそれでやるけど、実際、それだけではプロジェクトは崩壊する。
8人ぐらいならまあいいかもしれないけど、100人以上の規模になると、
ER、DB定義なんかみんなのバイブルだし、ステート遷移、通信プロトコル
あたりも同じ。全体設計にかかわるところは文書化して、配布しないと
どうにもならんと思うが。

もちろん、いろいろ壁に貼っとくけど（これらのバージョン管理は大変ね）。
だいたい、ホワイトボードを永遠に消さないつもり？
議論の結果はドキュメントにしなけりゃ時間の無駄だよね。
だったら、最初からドキュメントにすること考えて作業したほうがいいと思うけど。

量的にも、ERにしても1000個近く表があったりする手書きで済む話じゃないし。
実装と完全に同期が取れていなくても、ドキュメントが無意味であることに
はならない。手書きで書ける簡単な図にしたって、納品うんぬんより電子
ドキュメント化して共有しなけりゃ議論もできない。

簡単に全体が把握できる図が必要ということはまったくそのとおり。
でもそれだけじゃ無理だし、そもそもUMLって階層的に概略から詳細まで
落とせるんだよね？ まず全体見るし、必要なら詳細見れるように書くん
じゃないの？
細かいクラスの定義なんかは、コード見ればいいけど。どこのコード見
ればいいのかのガイドはいるだろ。

あと、自分のプロジェクトではないのし、アプリの内容にもよると思うが、
プログラマーに最後までクラス図書かせてるプロジェクトは、コーディング
量も少ないし、従ってバグも少ないようだが、いかが？。

最後の二行は同意。

他も大体同意。

ホワイトボードは会議中だけ。

良スレ age

>664
基本的にはUML->ER図への変換し別々に管理する。
別の手として三階層サービスモデルでテーブルを
データ層に直接記述する。もちろんデータの取り込みや
管理等も一緒に。これは大規模には使用できないかな？
でもUMLを作図した際の情報を考慮すると自然とキーや
リレーションっと言った感じが見えてくるし何より処理
に対して必要なデータが判り易くER図だけより良いのではと思ってる。

やっぱ開発規模によって使い方は変わってくるな。
これかはレスするときには分析者、実装者と開発規模とかも
記述した方がよさげ。

ちなみにオレは実装者、小規模

明日から UML FORUM/TOKYO 2002 が開幕。

なんかおもろい活用法ないかなーと、
ちょろちょろうろつく予定です。

ｽﾏｿ、UML Forumの会期は、3/26(火)〜3/27(水)だった
鬱氏

>668
なんかよさげな物あった？

>>670
会社が金だしてくれたんでチュートリアルにでてきたよ。
というか、上司に「チュートリアル逝け」といわれた。

「超入門」というだけあって、内容は簡単だったよ。
ただ途中の「メタモデル」の部分だけはサパーリだったよ。
社内の報告＆内容発表ではそこはとばすつもりだよ。
資料がおおすぎて、時間が足りなくなって、とばしまくりだったよ。
事例が多かったので社内のUML化推進の材料にはなりそうだったよ。
質問はあまりでてなかったよ。
ただ途中いかにもオタクあがりのへんなやつが時間がないって急いでいるのに
意味不明の質問をしてからんでたよ。
昼休みにみたUMLでモデリングした自走ロボットカーのレースはおもしろかったよ。

>667
やはり、そんな感じになるのね。
別の手のほうだが、データアクセスのところ（DAOね）は高スキルの人間に
任せたいので、その手法をとっているプロジェクトもある。大規模200人以上。
ただ、クラス側にあまりSQL書かないで、PL/SQLでストアードで実装し、
DAOをそれを呼ぶだけで簡略化しているようだ。
これをうまくやればＵＭＬ系の人と、ER系の人をある程度分離できるかなー？
ただ、667が言うように、両方使いたいんだよね。

DBがオブジェクトDBとしてもっと進化するか、UMLのステレオタイプが進化して、
詳細レベルはDBの物理実装まで記述でき、DBスキーマと対応取れるようになるまで、
インピーダンスミスマッチはごまかして行くしかないんだろうか。

あと、方法論と開発規模の件も同意。最近読んでる本によると、規模に応じた選択を
考える方法論がかかれているらしい（まだ、翻訳されてないみたい）。

ただ、開発中のコミュニケーション、問題発見のためのドキュメント等は規模依存と
思うけど、開発しちまったもののドキュメントは量を除き、システム規模でそんなに
変わらない気がするが、いかが。

>671
>事例が多かったので社内のUML化推進の材料にはなりそうだったよ。
いいな！うちの職場もUML推進してほすい。

>672
両方使うときの最大の問題点はやっぱり同期なんだよね。
これを解決するいい方法が俺には思いつかない。
ツールもたぶん存在するだろうけど熟練度が低いと邪魔なだけ。
それに最悪1プロジェクト内に2文化が発生して実装側が混乱
し、それに伴いバグ頻発するし。いいアイデアがあれば教えて欲しいです。

ドキュメントについては同意。
でも大規模な開発に関わったことがないの正直分からんけど
オブジェクト数はどれくらいなるんだろ？
100を超えてくると混乱するからそれを解決するためにレベルが
発生してくるのでは？。
レベルがどのように分けるべきかははっきりと見えてないけど
それを管理するドキュメントみたいなものが別途必要なのかな。

>>673
一番上の人は推進せよっていって、
折れにいろいろ勉強させてくれてありがたいんだけどね、
開発の実質的な中心人物の先輩は「あんなもんは必要ない」って
感じの人なんで間に入る折れはちょっと苦しいかも。
もともとチュートリアルもその先輩に話があったのが
「忙しいから」と断わって折れに振られたわけだったし。

>>674
いわゆる抵抗勢力というやつですな。

>>671

俺もチュートリアルでたが、UMLを学ぼうと意気込んでいった
俺には前半以外は難しかった…。超入門とは思えない。
あれはなに？UMLを使うっていうよりは、UMLを研究している人たちの
場なのかい？
自分が場違いな感じがして情けなかったよ…。

> ただ途中いかにもオタクあがりのへんなやつが時間がないって急いでいるのに
> 意味不明の質問をしてからんでたよ。

あの人は他の会場にも出没して意味不明だった。

漏れは気まぐれでUMLエディターのセッション聞いたけど、
「UMLエディター作成者のための機能自慢大会」みたいで痛かったYO!

方法論のないUMLなんて...

でもUMLと方法論は厳密に言うと別物だから
あまり方法論に固執する問題あり

って言うてみるテスト。

>>678
君はおおむね正しい。

って言ってみるテスト。

>>678-679 Javaと開発方法論は別物だから、
　あんまり開発方法論に固執すると問題あり

　って言うのと同じ程度の意味しかないと思われ

スタンダードか、暗黙の同意か、という差はあれど、
方法論のない開発なんて、学習中の初心者か、
混乱しきって予測不可能になった開発現場にしか存在しないんじゃないかー。

そういう基本前提があるからこそ、
開発方法論の差異を超えた、共通のモデル記述言語＝UMLが、
重要なんだよね。

>681
そうなんだよね。開発方法論は重要なのは確かだけどUMLだと
この開発方法でやらなきゃダメみたいな感じになってる人が
多い気する。>680が言うようにUMLで有効である開発手法は
ある程度決まってるが型にはまったやり方だけしか許されない
わけではない。

っていうかそれだとつまらんでしょ。（ｗ

だけど、UML作った人たちの頭には、RUPが概念的に存在してて、
ようはある程度の方法論があった状態で、UML考えたような
気がするのは私だけ？

UML も RUP も Rational の親玉たち （アミーゴズ?）のものだから
当然しょ。
最終的には普及のために方法論と独立を目指すとはいえ
開発方法論から生まれた話なのは間違い無し。

MagicDrawを課で10本程度購入しようと思っています。
課のみんなに、使いにくいぞ。ゴルァ。とか言われるの怖いんですが、
UMLツールの選定、この選択で正しいと思いますか？　当方、Java。

>>685

絶対、間違い。紙とペン。これがマジ最強。

>685
うちも、とりあえず一つ買ってみた。
結構いいと思うし、コストパフォーマンスは優れていると思う。
とりあえず気になるのは、

○設計情報がXMLで交換できるはずなんだが、rose評価版とうまくいかなかった
○シーケンス図とコラボレーション図の自動変換ができない

以上は、まだ使い方よく分かってないからかもしれない。あと、多人数での
設計まとめるサーバは使ってないのでわからない。

オージスから出ているツールもよさそう。値段はMagicDrawの倍。
だれか使ってみたひといたらどんな感じ？ なんか、評価版が落とされまくった
らしくて、現在ダウンロード停止されているので、評価できない。


紙とペン派は、多人数で、コミュニケーション共有しなけりゃならない状況は
わかっていないと思われ。そもそもUMLはコミュニケーションツールなので
その手の方たちには必要ないだろう。

手書きのコピーを配布するなら、彼らには、ワープロも、visioもいらないだろ-な。

プログラム、紙と鉛筆で書いてますが何か？

>>687
>○設計情報がXMLで交換できるはずなんだが、rose評価版とうまくいかなかった

XMI？XMIはまだ標準仕様が固まってないのでツール間での連携はあまり期待しない
方がいいと思います。

>○シーケンス図とコラボレーション図の自動変換ができない

普通はどちらか一つだけ書くものだと思うんですが、必要なんですか？
＃私はOMTから入ったので慣れたシーケンス図しか使いません

>紙とペン派は、多人数で、コミュニケーション共有しなけりゃならない状況は
わかっていないと思われ。そもそもUMLはコミュニケーションツールなので
その手の方たちには必要ないだろう。

最初あーでもない、こーでもないってやってるうちはホワイトボード最強ですね。
でもある程度固まったらツール使って清書するし、一人で考えてるときもツール
使って書いたり消したりしながら考えます。

ただUML使って設計を覚えようという人は、ツールをいきなり使うより手書きで
書いてみるといいと思います。OOA/Dの手法とUMLの記述法とツールの使い方を
いっぺんに覚えようとしたら挫折してもおかしくないでしょうからね。

>>687

マジレスありがとうございます。

とりあえずのリヴァース、フォワード、
あとチーム開発ができる安価なツール、
ということでMagicDrawを選定しましたので
Roseとの互換性はさほど気にならないんですが、

>○シーケンス図とコラボレーション図の自動変換ができない

はちょっと痛いですね。これだと、
リヴァース時のシーケンス図生成も行われないんだろうか……（；´д⊂）

というか、体験版さわってみたものの、
リヴァースしたクラスをクラス図に反映できん。

687です。

>689
シーケンス図とコラボレーション図は用途によって両方欲しいことが
多いと思う。ぱっと見はコラボレーションが全体像がつかめていいし
少し詳しくシーケンスを考えるときはシーケンス図。いずれにしても
同じ情報だから、いちいち書き直したくないなー。

XML形式はXMIと思われます（よく知らないものでスマン）。
そもそも、MagicDrawはセーブするとXMLのZIPファイル
しかファイルが作られません。これ、展開するとテキストで読めます。
これがXMIの構造になっていると思うんだが。
おっしゃるとおり、互換性はよくない模様（ツールメーカー何とかして欲しいな）。

>690
クラス図と、継承関係ぐらいまではリバースできた。シーケンスとかは無理と思う。
ただ、開発方法論の話になっちゃうけど、リバースはあまりやらないほうがいいと思う。
クラス図から直すのは大変だけど、トータル、長期的にはメリットも多しと思うのだが。
せっかくの設計が...とうことになりかねないと..。
もっとも、開発サイズとか、時と場合によりけりは方法論の常ですが。

チーム開発環境としては、結果レポート希望。


あと、紙＆ペンは否定はしてないが、これだけですむはず無し。
だれだって、メモ、走り書き、ホワイトボード図はかくに決まってるが
それだけだと、プロジェクト期間中もしくはその後メンテまでのスパン
でコミュニケーションできない。

ちょっと話がずれるが、昔、アクタとかMoreとかいう、MACでのアプリが
あったのを知ってるでしょうか。思考支援ツールといわれ、まあ今で言う
アウトラインエディタですな。ようは、ワープロは清書するだけでなく
これで書いていろいろ動かしていることで思考支援されると思われ。
論文書くときは、目次が一番苦しむからね。

いろいろあるカード利用の方法なんかも同じかな。で、ノートにUMLツール
いれて、プロジェクターでやってみようと思ってる。プロジェクター高いけど。
クラス図をカードにして、ボードであれこれ動かして議論するとよいと言う本
もあったが、あとでその結果を写すのが面倒。うまくいくと思うんだがだれか
やってみたことあります？ ERのレビューはこれでやったことあり（紙の配布も
同時にやったけど）。

各種 XP 本の論調によると

「コミュニケーションにコンピュータ使うことは人の視点を
コンピュータに向けてしまい、ダメ。視点は常に人に向いて
ないといけない。」

とのことで。

それ以前に、どうしても、印刷された UML図 が必要なシーンとい
うのが思い浮かばない。

わざわざ難しい設計にしてしまってるんじゃないの？　どうなの？

>>692

あとからシステムみるとき、
UMLないと泣きそうになりません？
コード追うのも、ヘタな日本語読むのも鬱。

をXP対UMLという定番対決になってきたね。何か創造的な議論が出来ることを期待。

>692
>それ以前に、どうしても、印刷された UML図 が必要なシーンとい
>うのが思い浮かばない。
ってことはUMLドキュメント自体は必要ってことでいいの？
XPだと違うかな？

UMLがコミュニケーションの道具として役に立つ、ということでは一致している
と思います。それをどのように使うか、というところで違いがあるんでしょう。

個人的にはUMLは設計上のアイディアをある程度具体的にするために使います。
大体ツールを使って書きますが、UMLからコードを吐かせることはめったにし
ないですね。ときどきすごく細かく書くことにこだわってる人がいますが、分析
にしろ設計にしろあるところまでいったら先に進まないと煮詰まっちゃいますね。
細かいところを図にしてもわかりにくくなるだけなので、そういうところはメモ
をペタペタ貼り付けておいて、もし後で分かりやすく書けそうなら書き直します。

ソースとUMLの同期がとれなくなって、設計時のUMLが
ドキュメントとして提出できなくなることがしばしば。
またいちから書くのはダルい。リバースあればいいな。

>>687
オージスのツールというと、Konesaのことですかね。評価版を使ってみましたけど、
かなりダメな感じです。

Javaで作ってあるんで、重い上に操作性が悪い。クラス図はともかく、
シーケンス図がとにかく作りにくい。
素人にはおすすめできないけど玄人にもおすすめできないです。
リバースとかグループ開発の機能は使ってないので不明。

ちなみに普段はRoseを使ってます。Roseも、ときどきバグるけど、
Konesaより10倍マシ。

ところで最近話題らしいTogether Control Centerはどうよ?

>>697
レポートありがと。やっぱりRoseになるのかなー。
もう少し安けれ買ってみるのだが。お金のない人はやはりMagicDrawか。
今度、どこかの大き目のプロジェクトで、顧客だまして（もとい、推薦して）
Rose買ってみようと思ったりして。
>>692
「」の中はまったく同意だよ。昨日も顧客ががんばるから7時間ぶっとーしで
会議であった。基礎設計ね。
で、これらの会議の結果を、形にしないといけないだろ。
だいたい昨日も、その前の会議の結果を、ドキュメントにして、
それをレビューしてたの。

もっとも、UMLじゃなかったけど、UMLでいえば、ユースケースや
コラボレーション、クラス図で書くようなドキュメント類。
ドキュメントも無しで、てぶらで会議なんでできないでしょ。
大量の情報を、会議に出てる人間がまったく同様に完璧に記憶
なんてできないんだから。

相手が、今目の前にいるか、将来のメンテの人かいずれにしても
人とコミュニケーションするために、ドキュメントが必要なんだよ。
そのとき、UMLは記述方法としてよろしいと思う。
XPもドキュメントを書かなくてよいと誤解されてると思う。
不必要なドキュメントは要らない（コード見れば分かることとかね）という
ことと思う。
逆にコードもドキュメントとして読めるように書けということかな。あと、開発サイズもかなり小さくないと無理だろうね。
数100人でペアプログラミングしてるとこなど、見てみたいが...

>>695

クラス図があろうがなんだろうが、分かりづらいもんは
分かりづらいんだよな・・・。

できれば貴方のその、ドキュメントにしてレビューしたという
プロジェクトの内容はどんなもんなのか教えていただきたい。

>>698

できれば貴方のその、ドキュメントにしてレビューしたという
プロジェクトの内容はどんなもんなのか教えていただきたい。

（結局は「どんな機能を持ってるのか」ってところに着目できれば、
整理できると思うけどなぁ。）

>>699
「分かりづらい」ってのは君の個人的な意見だよな。
個人のレベルで主観的にいう「分かり安さ」というのは、慣れや経験、
バックグラウンドなどがかかわってくるので、いまいちつかみどころがない。
ちなみに俺は「どちらかというとUMLは分かりやすい」と感じている。

分かりづらいところがあれば、分かりやすくなるように改良する、
というのがUMLが求められていることだろう。
が、そのためには「何が」「どんな風に」「分かりづらい」かが
はっきりしないとかなり「つらい」。
ただただ否定するだけでなく、そこんとこもふまえてて建設的にいってくれ。

話の腰を折って申し訳ないですが、限定子(Qualifier)について教えて下さい。

分かりやすい例とかURLとか。

よく見かけるのは、UMLの規格書にあるBank/Account/Personの例とか、
ウェブを見回るとあるDirectory/Filename/Fileとかで、そういったのを
見るとその時は分かったような気になるんですが、やっぱりよく分かりません。
いざ自分で考えてみると、そこに限定子が関与してくるのはわかるのですが、
限定子が関連のどっち側に付くべきなのかが混乱して分からなくなってしまいます。

なんかもっと分かる例と、手とり足とり解説してくれるのはないでしょうか。

>>702

「限定子」俺もわかんなくて調べてみたけど、
http://www.atmarkit.co.jp/fjava/rensai/uml02/uml02.html

要するに、キーと値のリストを使ったオブジェクトで用いるものわしい。

（ただ、分かりづらいもの使っててもしょうがないよ。自分が分からないものは多分、回りの人も分らないのでは）

>>701

俺の経験では、5個以上のクラスが書かれたクラス図は分かりづらいクラス図。そんな沢山のクラス間の依存関係があっても困る。

もし 5個以上のクラス図を書かないと、具体的な機能の説明ができないようだったら、それはあまりいい設計とは言えないんじゃないの。

データを取りにいくのかどうかでpush/popという区別をすることがある。

ここで、pop型はpush型によって実現できるとする。
どいうことかというと、push型はデータが出来上がると
クライアントに送りだすとすると、pop型ではpush型のオブジェクト
にラップして、データが出来上がるまで待つ、という処理を
付け加えると考えると、内部でpush型を使っていても見かけ上は
pop型になるからである。

この場合pop型のモデルとpush型のモデルの関係は何だろうか？
pop型モデルはpush型モデルを使っているので、<<use>>依存関係。
push型モデルでpop型モデルを実装しているので、実装の関係。
push型モデルに機能を追加してpop型モデルにしているので、汎化特化関係。
pop型モデルはpush型モデルを含んでいるので、集約。

状況にも依存するとは思うが、果してどういう見方をするのが、正しいのだろうか。

>699, 700
内容は別として、複数のデーモンプロセスと、外部システム、webGUIが
協調して動くDBアプリだが。よくある話だ。

で、よく話が混同してるようだが、どちらもドキュメント要らないという
立場なのか、UMLはわかりにくいという立場なのかどっち？

698はドキュメントはいるだろ、という話なんだが。

で、わかりにくいという話なら、体系づけられたすばらしい
代替方法を教えてくれ。

UMLは単に記述方法なんで、詳細レベルとか、まとめ方とかでいくらでもわかり
にくくできるよ。英語で書いてあるから分かりにくい、フランス語で書いてく
れ。とぃう議論と同じに思える。

で、文法、単語ぐらい共通になってないとお互いコミュニケーション取れないから、UMLでどうです？ という意味だと思うのだが。
従って、「UMLでは...という概念がかけない」とか「文法が悪い」とかなら
議論になるが、単に分かりにくいといわれてもねー。できないやつが書いた
んだろ、ぐらいしか反応できないなー。

これだけ議論されてるわけだし、みなが同じ文法を使うということ自体も
重要。英語よりフランス後のほうが論理的だが、英語のほうが人数多いしね...
と同じ。
>698 ユースケースの話と混同してない？
機能記述以外にも、データ定義とか、インターフェースシーケンスとか
いろいろあるんだけど...

>>703
わざわざ調べてくれてありがとうございました。

UMLの規格の、区分(Partition)云々とかいう説明はよくのみこめなかったですが、
キーとそれによって引き出される情報、というとらえかたは解りやすかったです。

Directory/Filename/Fileの場合は、DirectoryからFilenameをキーにしてFileが引き出される。
そして、限定子を使って表現しない場合は、FilenameはFileの属性になる。
Bank/Account/Personの場合は、BankからAccountをキーにしてPersonが引き出される。
そして、限定子を使って表現しない場合は、AccountはPersonの属性になる。

もともとは、いっしょに仕事している人がオブジェクト指向(というかクラス図)がきらいな人で、
一つのクライアントは複数のサーバーにリクエストを出し、
一つのサーバーは複数のクライアントからリクエストを受ける、
一つのホストには一つのサーバーしかない、
という部分のクラス図でクライアントとサーバーに多対多の関連を引いたところ、
「だから、クラス図は使い物にならない」といわれました。

そしたら、UMLに詳しい人が、そういう場合は限定子を使うのだ、と教えてくれて、
その場はうまく治まり、よかったのですが。自分で何かしようとすると、混乱して
しまって解らなくなってしまってました。

おかげで今回少し解るようになりました。

>>705

分厚過ぎる「ドキュメント」
http://objectclub.esm.co.jp/eXtremeProgramming/thud-j.html

「かんたんUML」とかオージス総研とかの本に書かれている UML を使った設計方法はかなりインチキだと思う。あんなのでうまくいくはずがない。

>>707
おまえUMLを使ったことないか、ちょっとさわった程度だろ。
使いこなせるようになればかなり便利だぞ。
憶測でものを言うなよ。

>>708
UML 一般を批判しているのではなく

　《「かんたんUML」とかオージス総研とかの本に書かれている UML を
　使った》　設計方法

を非難してるのでは？　両方とも読んでないから、知らんけど。

>>707-708
俺も読んでないからわからんが、
どうせなら707が具体的にインチキさ加減を指摘して
708もカッカしないでレスしてくれれば
丸とは言わないまでも楕円くらいに治まってくれると思う。

「かんたん UML」 は分析・設計に失敗しないでさくさく進むのがおかしい。

>711
そこに突っ込む前に「かんたんUML」と言うタイトルに突っ込まないのがおかしい

というてみるテスト。

>>712
そこに突っ込む前に「かんたんUML」なんてタイトルの本を手にとってしまう奴がおかしい

というてみるテスト。

>>711 分析･設計に失敗しないでさくさく進むのがおかしい。
　失敗つうか、試行錯誤や再設計でそ、普通

>>706
クライアント？サーバ？ホスト？
いったいどういうクラス図を作ってるんでしょうか？

単純に多対多の関連なら関連端の多重度がともに0..*(または1..*)になるだけ
だと思うんですが。

誰かこのツール使ったことある人いますか？
http://www.sparxsystems.com.au/

>>716
ダウンしてみました。ちょっと見ただけですが感想。
・日本語NG
・Win用で動作が早い
・ビジネスプロセスを表記可能（"Business Modeling with UML"？）
・DBの表記（PKとか）が可能
・実装言語へのフォワード/リバースエンジニアリング可能（出来は不明）
・ステレオタイプいろいろ

パターン、モデル共有等は未チェック。

日本語化して！

>>717
日本語はフォントを変更することで表示できることは確認済み
単にUMLだけではないのかな？個人ベースでは意味ないかも。

>>718
ほんとだ。わからんかった。
メニュー-View-option-objects-Font name ...

安いのは大きな特徴だと思われ（149ドル）。

個人ベースの利用者増による普及は無い、に同意。
もともとそういう戦略ではないでしょ。

ここのところ、UMLツールを片っ端から物色してるのですが。
今現在、Javaのソースからシーケンス図を生成できるツールってあるんでしょうか？
惜しいのはあるのですが..。(Threadオンリーとか..)

それにしても、roseの体験版は何処で手に入れれば..。(コレだけまだ試せてない..)

>>720
Roseの体験版。.comの TryIt にあるじゃん。疲れてるな..。

オージス総研が「10日でおぼえるUML入門教室」って本を書いたみたい
なんだけど、読んだ人、感想ﾌﾟﾘｰｽﾞ。
(いつ出たのか知らないけど地元にはなかった)

>>722
地雷臭いタイトルだな（藁

TogetherSoftのControlCenterはビクーリするくらいよい

関連スレ！

http://pc.2ch.net/test/read.cgi/tech/1016842360/

存在を忘れていたのでage

Javaのソースからクラス図作ってくれる、*無料*なツールってある？
人のソース読むときの参考として、クラス図を自動生成させたいんだけど・・・

>>727
doxygen とか？

>>728
試してみた。
javadocを便利にしたような感じで、これはこれで使えそうだけど、
クラス図生成の能力がちょっと・・・

>>729
HAVE_DOT = YES にした？　これで多少はマシになる。

（でも UML お絵かきツールには及ばんけど）

とりあえず、ブロンズ程度の内容は覚えたんだけど、
シルバーって他にどんなのを覚えればいいの？

覚えなくてもいいから実地をやれ。

>>671
>事例が多かったので社内のUML化推進の材料にはなりそうだったよ。
社内のUML化推進をおこなうにはどうしたらいいでしょうか？
なんかいいアイデアはないですか？

>>733
いい方法があるならオレもぜひ知りたいです。

とりあえず、UML導入以前と以後でどうなるか、という観点から、
メリットとデメリットを列挙して説明する、という安直な方法でやってます。
けっこうこじつけがあります。
が、あんまりやるとかえって逆効果かなとも思ってます。

抵抗勢力が現場をしきっているので、なかなかむずかしいです。

あと、すでに終わった仕事とかを持ち帰ってUMLによる設計に
焼きなおして整理する、ということもやってます。
忙しいのであまり進んでませんが。
これはどちらかというと自分の勉強になってしまってます。

>>727
Togetherをつかいなさい。Roseが糞に見えてくる。
http://www.togethersoft.com

>>734

コンサルつきRUP導入するしかないと思う。

ソフトウエア開発環境展
http://web.reedexpo.co.jp/SODEC/japanese/index.html
に行けばいろいろUML関連ツールは見られそうだ。

集約の「共有」(白い菱形)と「合成」(黒い菱形) (←Visioの用語を使用)
の違いがどうしてもはっきりと理解できません。

分かりやすく教えてください。

用語はごちゃごちゃしているのでこの表を参照してくれ。
http://www.atmarkit.co.jp/fjava/devs/jobjmdl01/jobjmdl_about.html

集約の「共有」(白い菱形) は 集約、
集約の「合成」(黒い菱形) は コンポジッションと呼ぼう。
関連の特殊な形態が集約であるように、
集約のよりオブジェクト間の結びつきが強いものがコンポジション。

集約は has-a の関係だ。
例えば、「a car has four tires」

コンポジションは a-part-of の関係。
例えば、「a finger is a part of a hand」

どこが違うのかというと、オブジェクトの生成消滅のタイミング。
集約の場合は車をスクラップにしてもタイヤだけ取り外して使ってもいい。
コンポジションの場合は、手が成り立つには指が必須であり不可分の存在なので、
手を失うってことは指も同時に失うってこと。

>>739
俺もいまだによくわかんない。
738じゃないけど、便乗教えてくん

(1)「tires is a part of a car」とは言えないのですか？
(2)逆にいうと、タイヤはタイヤとして単独で存在できるが、指は指単独では存在できず、手の一部としてしか存在できない。
　(これは正しいですか？)
(3)コンポジションは、集約の一種ですか？
(4)良くわかんない場合は、集約使っていれば間違いではないですか？
(5)実装してするときに、集約とコンポジションで差がつきますか？

>>740
(1) いいよ。その場合はタイヤは車と不可分。
　739 は取り外したタイヤを転がして遊んだりもできるという設計思想だった。
　そのプログラムの設計上、どの程度オブジェクト同士の結びつきが強いかなので
　集約よりも強いならばコンポジションで表記すればいい。

(2) そだね。集約の端的な例は コンテナに近いクラスかな。
　Book クラスと BookShelf クラスがあるとする。
　BookShelf はインスタンス変数で Verctor books を持ち、
　Book オブジェクトを追加する add(Book book)、削除する delete(Book book) メソッド、
　あとは数を数えたり条件検索したり管理に便利なメソッドがある。
　ある Book を複数の BookShelf に登録したり、
　ある BookShelf が detele や GC されたあとも、その BookShlef にあった Book を
　読者オブジェクトに利用したりなんてことはありえると思う。

　GUI のウィジェットはコンポジション。
　ウインドウ・フレーム・ペインの上にボタンやテキストフィールドを乗せるけど、
　ウインドウがなきゃボタンなどは表示されないし触れない。
　ウインドウが消滅するときはその上に乗っていたウィジェットも一緒に消える。

(3) そう。
(4) 教えるときはそう言ってる。あんま良くないけどね。
　関連と集約は使い分けてほしいけど、集約とコンポジションは混乱しがちだから。
(5) 定義的には 739 に書いたように消滅のタイミングが同じなのがコンポジション。

C#を使ったUMLの解説本って出てます？
JAVAを使ったUMLの解説本はたくさんあるみたいだけど。

別になんの言語を使っててもUMLはUMLだろーよ。

UML1.4をみてみると、
集約＝全体−部分関係をなす関連
合成＝集約の一種で「多くともひとつの全体に対する部分」になっているもの
といったようになってるようです。
というわけで、この“at most one composite at a time”というのがUMLでの
合成の意味を決定付けているのではないでしょうか。

用語集より
aggregation
A special form of association that specifies a whole-part
relationship between the aggregate (whole) and a
component part. See: composition.

composition
A form of aggregation which requires that a part instance be
included in at most one composite at a time, and that the
composite object is responsible for the creation and
destruction of the parts. Composition may be recursive.
Synonym: composite aggregation.

ノーテーションガイドより
Composite aggregation is a strong form of aggregation which requires that a part instance be
included in at most one composite at a time and that the composite object has sole
responsibility for the disposition of its parts. The multiplicity of the aggregate end may not
exceed one (it is unshared). See “AssociationEnd” on page 2-22 in the Semantics chapter for
further details.

セマンティックスより
composite - The target class is a composite; therefore, the
source class is a part and must have the aggregation value of
none. The part is strongly owned by the composite and may not
be part of any other composite.

>>744
タイヤとクルマの例だと、
タイヤとクルマは、それぞれ部分と全体を成すので集約であり、
さらに、タイヤは同時には１つのクルマの一部として機能するが、
同時に２つ以上のクルマの一部としては機能しないので合成である、
ということか。

あるクルマのタイヤを外して、別のクルマに取り付けた
場合はどうなるんだろうか。集約？　合成？

『独習UML』の例だと、HDやメモリ、モニタといった
パーツで構成されるコンピュータシステムは「集約」。
で、天板と脚から成るテーブルが「合成」。

『独習UML』から引用すると 744 が書いていることと同じだが、
合成は「部分側が単一のクラスの部品になっているような集約関係」
らしい。

つまりある環境において、部分が複数のクラスからも利用されて
いれば「集約」で、単一のクラスからしか利用されていなければ
「合成」になるでは。

>>745
別のクルマに取り付けられるという前提があるのであれば
「集約」ではないでしょうか。

>>746
> 別のクルマに取り付けられるという前提があるのであれば
> 「集約」ではないでしょうか。
なるほど、俺もそんな感じに思ってたよ。
だけど、>>744の「同時に（at a time）」というのに引っかかってしまったわけだ。
同時に、というのが集約と合成を区別するのだとすると、
ハードディスクやメモリーなどは合成ということにならん？
モニターについては複数のマシンで切り替え機を使うことで同時に
利用しているという考え方もありそうではあるが。

>>747
そうだね、「同時に」を考えるとパソコンの例は
合成だね。


今月の『JavaWorld』212頁にあるUML要素の説明からも
引用しときます。

コンポジション (ここで言う合成)
あるクラスと他のクラスの間に強い「has-a」の関係があることを
示す。この場合、「has-a」関係のhasに当たるクラスが削除されると、
aに当たるクラスもすべて削除されることになる。

抽象的にそうなんだろけど、
具象を設計するのは我々なんだから、
has-aをpart-ofとして設計またはその逆でも
問題がなければいいのでは？

magicdraw、demo版落としてみたんだけど、
実行しようとするとライセンスキーを聞かれる。
マニュアル読んでもdemo用のキーの事なんか書いてないし。
カネ払わないとdemoも実行できないの？

メールで試用キーが送られてこなかったっけ？

送られてこないっす。flashmail使ってるけど。
試しにメアド変えて(hotmail)登録してみたら、
今度は届いた。2通も。
どうなってるんだ…でもさんくすこ。>751

漏れ１ライセンス購入したらライセンスキー３個届いた。
どれも使える。

大丈夫なのかmagicdraw。

>>754
幸い MagicDraw のソフト本体が腐ってるという話は出てないから、まー大丈夫
なんじゃないの？

C++のコード取り込みがうまくいかん<MagicDraw 5.1
リバースするきさらさら無いからいいけど。

今いち、買おう、という値段じゃないんだなあ。

おれんとこには試用ライセンスが４つきた。
時間差で。

つまり、今がチャンス？w

>>756
MagicDraw の C++ のリバースはダメダメだね。そもそも、コンパイラでも ANSI C++
フルサポートしてる実装の方が少ないぐらいだから、期待してないけど（ｗ　俺が試し
た中で C++ に比較的良く対応していたのが Togehter。ただし値が張るのと、C++ の
ソースに UML 用の情報を埋め込むタイプなので、微妙に使いにくいのが難。

そんなわけで、結局 MagicDraw のスタンダード版（リバース無し）を使ってるよ。

IIOSSのコードいじってjavaに特化した部分ごっそり削ろうかなあ。

そのためにJava覚えるのもばかばかしいがなあ..

>>759
「Togehter」を見てふと、ルー大芝を思い出してしまった。
てーぅぎゃざーあ

UML関連の記事２題：

http://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20020527/1/
http://www.atmarkit.co.jp/fjava/devs/survey/survey0205/survey0205.html

＞ 数億円をかけて100ライセンス以上を購入した。
ここだけ反応してしまった。

いま仕事でUMLを書こうとしているのですが、
クラス図では、Cの構造体をどのように書けばいいのですか

名前と属性だけ書いた箱

ありがとうございます。もう少しご教授お願いします。
クラスとの関係はアグレゲーション（白い菱形）または、
コンポジション（黒い菱形）でよいのでしょうか。

よいんでない？

>>766は「アグリゲーション」ではないかと。
delegateは「デリゲート」？「デレゲート」？

デリゲート

suge-

a

ｂ

UML技術者認定制度のシルバーはどんな問題が出るの?
140点満点ってことは、140問もあるの!?

一問140点、残りはダミーです。

マジで?

5問。設問が3･4つといったところ。だったかな。
ていうか
親の名前でも使って試しに受けてみなさい。
オージス総研では日本語が通じない事がイタイぐらい身に染みる。

ｆ

シルバーとゴールドの問題文、あれは確かに日本語とは信じ難い

b

「Roseを256倍使う本」を書こうと思うんだけど売れると思う？

>>780

うん、>>780の親が買ってくれるよ。

>>781
いや、親には内緒だから。

　 Λ＿Λ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　初めはロクな書き込みなかったけど...最近は嬉しいな♪
　（　　　　）　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜ ｜　|
　（_＿）＿）

ｺﾝﾄﾞｻｯﾎﾟﾛﾉｱﾙｶｲｼｬﾄｺﾗﾎﾞﾚｰｼｮﾝｽﾙﾝﾀﾞｹﾄﾞUMLｦｺﾐｭﾆｹｰｼｮﾝﾂｰﾙﾉﾋﾄﾂﾄｼﾏｽ

お高いCASEツールなんぞ買えないし
フリーのこんなのいいと思うけどどうよ。
単純明快な感じするけど。

http://www.vector.co.jp/soft/win95/prog/se215535.html?l

おお、なんかよさげな感じ

いいね、コレ。
こういうメモ描きに適したのってなかったもんね。
Roseはもちろん、Visioもmagicdrawも構えちゃうし。

この手のダイアグラムには、こういう気軽な道具こそが大切だとつくづく思えるね。
早速言いふらかしましょう。

多重度が指定できると良いのだが.. とか言い出すとキリないけど
ほんとよく出来てると思う。

清書は Visio か何かでやればいいかと。
試行錯誤するのにいいかも。

評判よさそうだから
作者に教えてやろう。
きっとよろこぶﾀﾞｽ。

コレがいいか〜？
俺ならmagicdraw使うな…

ていうかもう、code gen付いてないUMLエディタを使う気にならん…

む。
危うく作者に「大評判ﾃﾞｽ！」と送るところだった。
送るのはやめておこう。
よくないのか？
code genてなんだべ。

コードジェネレータ。

いや、まあ、こういう激軽いのを欲しがってた人もいるにはいるだろうな。
んで、そういう人にはバカ受け、と。
そう報告する分には良かろうて。

ああ、こぉどぢぇねれたーか。
ふぅん。

なんかこう、「クラスを作って」から「クラス図に反映」っていう直感的な
操作ができるエディタって少ない。俺が知ってる限りではMagicDrawだけ。
どいつもこいつも、「まずクラス図に配置してから」云々って操作を強いるんだよなー。

想像するコォドジェネレェタ
もやもや。

+-----------+
| Pen |　　　　public class Pen{
+-----------+ private int katasa;
| -katasa |
+-----------+ public void getKatasa(){
|getKatasa()| //てめぇで実装しれ
+-----------+ }
　　 △ }
　 　｜　　　→
+------------+ class SharpPen extends Pen{
| SharpPen | private int Sin_no_kazu;
+------------+
|-Sin_no_kazu| public void getKazu(){
+------------+ //てめぇで書けっつーの
|getHonsu() | }
+------------+ }

よく知らんけどきっとこういうやつに違いない。

すまんズレ過ぎて意味がわからん。
気にしないでくれ・・。

あのねえ・・・最近のコードジェネなら、
setter/getter ぐらいは中身まで書いてくれるよ・・・

ふぅん、そか・・。

ねぇ、>>794の
「クラスを作って」から「クラス図に反映」
って普通の使い方なわけ？

平たく言えば、Borland の RAD の 2-WAY と一緒でしょ。
どっちかを変更すればもう一方にも自動的に変更が適応される。

普通かどうかは知らん。
ただ、俺は「まずクラス図に空のクラスを放り込む」って操作に違和感を禁じ得ないの。
「クラスを作って」から「クラス図やシーケンス図に放り込むと初めて図として表示される」ってのが自然だろ。


＃まあこう力説しても「どうでもいいじゃん」と流された事しかないけど…

>799　いや、俺はあくまで”最初の一歩が気に入らん”と言いたい。

こだわるねぇ

>>801
今あるほとんどの UML エディタは
オブジェクト指向設計向けに作られているからしょうがない。
RUP を見ても分かるように図を作成して開発を進めましょうってやり方。
設計段階によってはクラス図とコードが一対一対応しない。
UML エディタは開発支援ツールとしてはあんまり成功してないけどな。
コードセントリックな方が受け入れられやすいし。

>>803
同感

けど、ＵＭＬと既存言語間のマッピングは一つの様式に拘るべきだな。

お絵かきから設計を始めるなんてのは、正に絵空事。

同じクラスを違う図に配置すると別物として扱われるタイプのものは嫌、ということ？
それだったら同意

どうせ名前くらいはその場でつけるんだから
新規作成したその場でアイコンのプロパティが開いてくれたほうが楽。

>>794
Roseはできるよ

Rose使いてえ…
でも会社が買ってくれん…
買って貰ったとしても動かせるスペックのマシンがあるかどうか…


＞同じクラスを違う図に配置すると別物として扱われるタイプのものは嫌、ということ？
誰がそんな話してた？

＞新規作成したその場でアイコンのプロパティが開いてくれたほうが楽。
なんの話？

>>805
設計図が無い他業界を教えてくれ。

>>809
>>800

UML認定試験の解答集ってどこかにないのかね

>>809
Roseは起動してしまえばそんなに重くないよ。
Togetherはどう？モデリングだけならCommunityEditionでいけるが。

>>809

確かこのスレで紹介されていたような気がするが
http://www.sparxsystems.com.au/
これけっこう完成度高い。シーケンス図がイイです。
英語しかないのが難。

期限なしでタダで使えるエディションがあるツールって
ないですか？　前Togetherにそういうのあったけど、
今はどうなんだろ。サイトにはエディションの説明無いけど。

ＵＭＬmemo、やっぱいいよこれ。
思い浮かんだことをホントに気楽にメモ書きできるから。
BMP印刷でも身内レベルなら十分ですわ。

UML使って設計やりながら、こういう割り切った仕様のソフトに助けられてる。
それに引き換えなんじゃオレの設計わ。。。
ああ、悲しい。

>>816
ASCII 出力ができればいいなと思ったり。
メールや 2ch に UML 図を書ける(ｗ

・属性に下線が引けない
・多重度が指定できない

というのが解決してくれればちょいとRDBのテーブル設計にも使えて
個人的にｲｲ感じなのだけど...

OOP,RDBでのアプリ開発って、開発手順はUMLになるの？

819の訂正。開発手順はUMLベースなのかいな？

>>817
そういうのができるのがvectorにおいてあったような気がした。

UMLメモ、ステートチャートをサポートして欲しい。サーバーサイドの
開発にはステートチャート必須だよ。

>>822
つーか、ＵＭＬエディタって、IIOSSみたいのがあるんだから、
解析して、抽象クラスだけつくっておいて、あとは各ＯＳに
みんなでかってに実装してくれという代物があればいいな。

>822
同意だね。
ステートチャートこそ気楽に描けなかったりするし・・・。
欲張りか。

>>819
OOA
OOD
OOP
など、いろいろございます。UMLは頭二つでしょうかね。

汎用系システムがメインの会社ですが、WEBアプリの開発プロセスがドキュメントで皆無。
大手ベンダーでは如何なものかと？誰かUMLベースの手順書くれないかな・・・・

シーケンス図ってエクセルで書くと楽なことがあるなぁ。

>>826
そういうときは、客向けの仕様書もおろそかな場合が多い。
さらに、ＤＢアーキテクトとウェブロジック設計者・実装者が
分担されている場合が多い。この場合ウェブロジック設計者自らが
開発プロセスを示す場合がおおい。
（現実無視の実際の１／３の期間の線表が既にひかれている場合が多い）
開発分担し過ぎててオーバーヘッドが多いのが最近の特徴かな。
（つーか、最初の見積もりが甘すぎる）
また、ＵＭＬだけに頼ってはいけない。
ＵＭＬはあくまでデザインパターン等で意志疎通をしたりするための
記述方法だ。
問題は、プロセス、設計に対して時間をかけて綿密に打ち合わせ、
コミュニケートするかどうかだ。

＞ＵＭＬはあくまでデザインパターン等で意志疎通をしたりするための
＞記述方法だ。

( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ
( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ
( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ
( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ ( ﾟдﾟ)ﾎﾟｶｰﾝ

俺が読めないのでＵＭＬは禁止。

>>830
それはだめだ、圧倒的にＵＭＬで描いたほうが分かりやすいものがある。
しかし、なんでもＵＭＬでかけると思っている厨房がいていや。

>>831
どんなもんが書けないのかおせーてけろ。

>>832
とりあえずマニュアルは書けないよな。

ずこーん

Unidentified Mysterious Lingerie

UMLあげ

>>27
フリーのって何？

age

>>８３２
http://argouml.tigris.org
なんかは？

837だった。

PatternWeaver1.0がうちの研究室にやってきた。
お金要りませんからためしに使ってみてくださいってやつらしい。

なんか、皆さんの書き込み見てると非常に人気のないように思われるPatternWeaver1.0
私はUMLは厨程度にしか使えないのでこの程度のものでも困らないけど、
んー、こんなソフトが買ったら10万円近くするのか。

ってか、うちの研究室はとりあえず5ライセンスほどもらったけど
30ライセンスほしいっていったら30ライセンスもらえそうな感じだったらしい。
評判悪いせいか、売り込み必死？

PatternWeaverってＵＭＬ書籍によくついてるし、
フリーのバージョンもありますね。

フリーのバージョンダウンロードしてきて、
ちょいと勉強してみようとおもっとりますが、
他のツールの方が使いやすいですか？

仕事中にお絵かきか。
おめでてーな。

はいはい、そうだね。

XPしながらUMLをどう使うかが課題かな。

>>845
知ってる言葉を並べてみました、って感じだな

うｍｌ
あ〜あ、俺の会社じゃ誰も書けないや

>>847
書くだけなら１０分もあれば覚えられるだろ
要はどう生かすかだね

ＵＭＬ使いましょうとかいってる会社はＥＲ図さえ書いてない予感。

MagicDrawの最新版はEclipse2.0のPlug-Inが同梱されていて、
個人的には結構使いやすいと思う。
今日はじめて試してみただけだから、使い込んでいないけど、
個人的には気に入った。

ｶﾞｲｼｭﾂ?

UML ツールですが、
Sparx Systems の Enterprise Architect を使っています

あんまり安いとは言いがたいのですが、他があんまりにも高いので、
値段的には安く感じます。$150程度。

私は UML を考えをまとめる為に使っているので、あんまり厳格に
書く必要がありません。一番便利に使っているのがシーケンス図です。
クラス図なんかは、いちいち書くの面倒なので、C++ で書いて
UML ツールに解析させて、はっつけておきます。

まあ、私の場合、時間軸で複雑性があって、テキストでいちいち書いて
られない。という場合だけ使っています。

こんな、絵でネチネチ書いていたら時間かかってお話にならないので。

あ、EA のよい所は、まあまあの速度と、安定性を持っている事、
C++,Java,Delph などのコードからクラス図を作ってくれる事
シーケンスが書きやすい事ぐらいかな。

欠点は
名前がまずすぎる。Enterprise Architect じゃ、MS-NET の
製品ラインと同じになってしまう。ちなみに、アイコンには EAと
ある。EAといえば、エレクトロニック　アートのゲームかな。
個々のオブジェクトのプロパティの編集が面倒。
グリッドの扱いがわかりにくい。画面と印刷のイメージがずれる事が
ある。画面でも拡大縮小で文字が図からはみ出たりする事がある。

>>851

オブジェクトのプロパティの編集は、まず適当なオブジェクトで
プロパティダイアログを表示させておいて、あとはそのダイアログを
閉じずに、他の編集したいオブジェクトを選択すれば、ダイアログの
中身が変わる。

という意味ではなくて？

>>848

生かし方が分からない。オブジェクト図や相関図などチマチマ書いていられないのが現状だし

＞850
俺の会社じゃねーかYO!

>>853
全部書こうと思うとだめだろ
必要な図だけ書けば

>>852
使い勝手の悪い所は、プロパティウインドウで編集できる項目が
オブジェクトを選択して、ダイアログを出した時に出来る事より
少なすぎる事と、プロパティウインドウでは意味の無い物しか
出てこない点です｡

この為に、細かな設定がどうなっているのか調べる為に、色々な
オブジェクトのプロパティダイアログを開くという事になります。
まあ、ショートカットを使えば、それほど手間じゃないのですが。
（たとえば ALT+Enterとかね）

>>853
必要な図とわ？

>>857
仕事に必要な図ってことじゃねーの？

今日はシーケンス図つかったよ。

>>859
ぢゃ、明日はコラボレーション図だね&heart;

ホワイトボードの感覚で描ける、UML支援ツールがほしいな。
保存と、印刷機能必須で、マウスじゃないやつ。

シーケンス図がさくっと書けるフリーのツールどっかにない？

ペイント

>>862
かみとえんぴつ。

自分で探すか。

>865
warata

>>865
ばかもの！
ソフト作りになんらかの形でかかわる者ならば、

　　「自分で作るか。」

と言わんか！

UMLツールって、作るのすげー難しそう。
ああいうドロー系ってやったことないからビビります。

ドロー系で作るから厄介になるのでは？と私は思います｡

Doxygen が使っている graphvis を見て思う事は、プログラマが
直接絵を書いちゃいけないんじゃないかと思います｡

特にシーケンス図にいたっては、テキストで記載できる方が良い｡

たとえば次のように、オブジェクトを定義して、流れをプログラムの
ようにして書けば勝手に絵が出来上がる｡はず。

class puser:<Actor>, viwer, coverEdt, printer

puser: call viewer::new
puser: call viewer::getPrinterStructure
viewer: call printer::dispatch

クラス図の方は、プログラムから戻した方が書くほうは楽｡

ただ、動的モデルの方は、動いているプログラムから取り出すという
斬新なアイデアあるが、これは設計が先かプログラムが先かという
問題になってしまうし。そもそも、データが多すぎて、要点を明確に
する為に消す時間がけっこうかかってしまう。

>869
UMLの意味わかってないでしょ？

だから、絵はコンピュータに書かせて気に入らない処は修正すれば
いいの。

人に考え方を説明して、同じ目標に向かえばいいのだから。

puserって何？

ﾌﾟｰｻｰ

ユーザーへのポインタ

pfood?==「ごはんを食べないか？」

>871
前から思ってたけど、あなた頭悪いでしょ？

頭悪いけど何か問題でも。

ちなみに、puser は ユーザーの作成したプログラムという感覚で
書きました｡例なんだから、これにつっこんでどうするんだ。
という気が私にはしますが。

>>877
相手が頭悪いと相手のレベルに下がって考えないといけないから
面倒くさいんだよねぇ。

>877
あまりにも頭悪いみたいなのでマジレスしてやる。


発端
>868 名前：デフォルトの名無しさん 投稿日：02/08/10 12:06
>UMLツールって、作るのすげー難しそう。
>ああいうドロー系ってやったことないからビビります

頭悪い人のレス
>869 名前：森　秀樹 投稿日：02/08/10 22:14
>ドロー系で作るから厄介になるのでは？と私は思います｡

>871 名前：森　秀樹 投稿日：02/08/11 00:59
>だから、絵はコンピュータに書かせて気に入らない処は修正すれば
>いいの。

その「コンピュータにUML（図）を書かせるツール」を作る話してるんだろうが！
いくらなんでも頭悪すぎ。いっぺん氏ね。

コンピュータにUML(図)を書かせるツールの話だったのですか。
ドロー系て書いてあったので、今まであるような、画面上で位置を
元に線を書くようなツールだと考えていました。

じゃ基本的には考え方は同じなわけですね。

論理的に、どこのオブジェクトからどこのオブジェクトを、どのように
呼び出すかを記載すれば、コンピューターが絵を作ってくれる。

Sparx の EA のように、画面上で位置情報を元に、論理的な流れを内部
的に作るのでは無いという意味なんですね。

ドロー系て書いてあるから、私が誤解しました。

>>880を読んで確信した。
ここまでバカな人初めて見た。