UML皆でお勉強しよ♪
■ このスレッドは過去ログ倉庫に格納されています
0001ニュージーランド漁夫
NGNG（ ・∀・）＜ お勉強しよ♪
（ ） ＼＿＿＿＿＿＿＿＿＿＿＿＿
｜ ｜ |
（_＿）＿）
0652デフォルトの名無しさん
NGNGあとIIOSかな？
JAVA向けのページだけど此処結構揃ってるYO!
ttp://www.geocities.co.jp/SiliconValley/6064/java_link.html
0653デフォルトの名無しさん
NGNGあんなクソ言語つかわねえっつーの
0655デフォルトの名無しさん
NGNG圧倒的に多いし、RDBMSは設計、管理...でERが便利で手放せそうにないし。
クラス図だけだとちょっと辛そう。UMLとERを両方とも使っていきたいんだけど
どんなもんだろう。
0656narucy56 ◆wMOjCT4s
NGNGプロジェクトで UML 使うってのは、どういうことでしょうかね。
「かんたんUML」とかに書かれていることを、そのままやろうとしたら
多分、うまくいかない（と、思うんだけど、どうでしょう）
XP的には
「どうせクラス構成なんて開発中に変わるもの」
「せっかく作ったクラス図だって時間がたてば古くなる」
「その種のドキュメント書きは無意味」
0657デフォルトの名無しさん
NGNGホワイトボードかA2くらいの紙を壁に貼った上にね、マジックでぐりぐりと。
みんなの見えるとこにおいといて、そこに書ききれないような細かいのは書かないの。
使用がかわったらすぐに書き直し。
プロジェクト終了後と社外の人に見せるときだけ瞬間的に清書。
開発が再開したら、また、同じことするんだぞ。
0659デフォルトの名無しさん
NGNGクラス図は手書きでも構わんけど
状態変移図とかはどうしてるの？
手書きだと修正がつらくね、やり直したい時とか？
オレの場合は一応紙とツールで書く、ただし細かい部分は省略、
プロトでとりあえず自分の中で不明確な点を確認、思いついた
アイデア等は図をコピーして反映する。
>655
すでにDBが存在するならUMLの出番はDB設計においては殆ど無し。
ただし新規作成ならUMLの分析は有効なはず。>604のリンク先参照
>656
>「どうせクラス構成なんて開発中に変わるもの」
これはUMLでも同じ考え、ただし変化を考慮してパターン等
を使用して大幅に変わらんようにする。
>「せっかく作ったクラス図だって時間がたてば古くなる」
>「その種のドキュメント書きは無意味」
UMLは厳密言うとドキュメントではない気がする。
ただの設計過程での思考経過を表すメモでしかない。
それにドキュメントは時間がたてば古くなるのは嘘
仕様変更が無ければドキュメントも常に最新
UMLは設計変更に対応する際の対応方法を考えるのにも当然使用される
べきでその結果UMLは常に最新になるはずなんだけど･･･
現実にうまく行ってる所は知らない。
0660デフォルトの名無しさん
NGNG>>「その種のドキュメント書きは無意味」
>UMLは厳密言うとドキュメントではない気がする。
>ただの設計過程での思考経過を表すメモでしかない。
んだね。「クラス構成が変わる」というが、そのクラス構成をより良く変える過程で
道具として使うものだと思う
メンバ変数やメソッドを逐一記述するヤシはそういないだろ
0661657
NGNG「書き直すのが面倒な図は、悪い設計」
てことなの。
状態遷移図は、細かく書き始めると確かに大変かもしれないが、
紙の上で書き直してて、もしくは付け足してて面倒だと思ったらね、
「この状態遷移は悪い遷移。もっと簡単にしる」
ってことなの。
経験からいってもね、手書きでOKなレベルでないと、
プロジェクトの他の人がその図を見たとき、
把握できないのよ。
大切なのは、何が重要なのか、を見せること。
重要な何かが、どれと関わっているのか、を見せること。
状態遷移は、定型的なパターンを図示できればOKで、
部分ごとの細かい遷移については、あくまで、壁に貼ってある図の
「発展系」なんだって認識でやればいいの。
具体的に一個一個書きたい気もわかるけど、
重要なパターンというのは数えるほどしかなくて、
しかも大体それは、小学生でも書けるような、簡単な遷移図であるべきなんだよ。
0662デフォルトの名無しさん
NGNG大雑把なところをプロジェクト参加者全員で共有するという話だと「手書きレベル
で OK な図で留めとけ」というのは、間違ってないとは思う。
ただ通信プロトコルにせよ何にせよ、実際には複雑な状態遷移と対峙すること
が多い。簡単にしすぎると
性能
効率
安定性
どこかで致命的な妥協を要求されるから。(TCP/IP も基本的な部分は簡単だ
が、実際に OS 組み込みのプロトコルスタックを組もうと思ったら、タイマーが
並行して何個も走ってる複雑な状態遷移機械になるよね）
俺は、実装者向けの図としては詳細まで書いた方が良いと思うよ。もちろん、
図に書かずにコードで書くという選択肢もあるが、経験的には図を書いた方が
ロジックミスを防ぎやすいし。
0663657
NGNG実装者が、詳細レベルまで書き下ろすことについては否定しない。
で、そういう実装レベルの図を、ドキュメント化して、実装と同期をとることも
否定しない。
そもそも、いままでそういうのを図示する共通のやり方がなかったわけだからね。
そして、たぶんその図は壁には貼られないだろうけど、
仕様のレビュー時と、コードのレビュー時に、大いに役立つだろうね。
でもおれんとこのだと、そこまで細かいものは、書く人は書く、
書かない人は書かない、で仕事しちゃってるんだよね。
徹底させてるのは、例の、壁に貼るやつだけなんだ。
0664デフォルトの名無しさん
NGNG>659
>すでにDBが存在するならUMLの出番はDB設計においては殆ど無し。
>ただし新規作成ならUMLの分析は有効なはず。>604のリンク先参照
これは分か気がするし勉強してみるけど、すでにDBがある場合は、
コードの設計をUMLでやりたいし、新規作成の場合も、最後はERから
DBへ落としたいので、いずれにしても最終的にUMLのドキュメント
と、ERを共存させたいんだけど。
それとも切り替えるのかなー。ここらをどうやってるか聞きたかったわけ。
あと、手書きでホワイトボードうんぬんの議論は分からないではないし、
議論はそれでやるけど、実際、それだけではプロジェクトは崩壊する。
8人ぐらいならまあいいかもしれないけど、100人以上の規模になると、
ER、DB定義なんかみんなのバイブルだし、ステート遷移、通信プロトコル
あたりも同じ。全体設計にかかわるところは文書化して、配布しないと
どうにもならんと思うが。
もちろん、いろいろ壁に貼っとくけど（これらのバージョン管理は大変ね）。
だいたい、ホワイトボードを永遠に消さないつもり？
議論の結果はドキュメントにしなけりゃ時間の無駄だよね。
だったら、最初からドキュメントにすること考えて作業したほうがいいと思うけど。
量的にも、ERにしても1000個近く表があったりする手書きで済む話じゃないし。
実装と完全に同期が取れていなくても、ドキュメントが無意味であることに
はならない。手書きで書ける簡単な図にしたって、納品うんぬんより電子
ドキュメント化して共有しなけりゃ議論もできない。
簡単に全体が把握できる図が必要ということはまったくそのとおり。
でもそれだけじゃ無理だし、そもそもUMLって階層的に概略から詳細まで
落とせるんだよね？ まず全体見るし、必要なら詳細見れるように書くん
じゃないの？
細かいクラスの定義なんかは、コード見ればいいけど。どこのコード見
ればいいのかのガイドはいるだろ。
あと、自分のプロジェクトではないのし、アプリの内容にもよると思うが、
プログラマーに最後までクラス図書かせてるプロジェクトは、コーディング
量も少ないし、従ってバグも少ないようだが、いかが？。
0665657
NGNG他も大体同意。
ホワイトボードは会議中だけ。
0666デフォルトの名無しさん
NGNG0667659
NGNG基本的にはUML->ER図への変換し別々に管理する。
別の手として三階層サービスモデルでテーブルを
データ層に直接記述する。もちろんデータの取り込みや
管理等も一緒に。これは大規模には使用できないかな？
でもUMLを作図した際の情報を考慮すると自然とキーや
リレーションっと言った感じが見えてくるし何より処理
に対して必要なデータが判り易くER図だけより良いのではと思ってる。
やっぱ開発規模によって使い方は変わってくるな。
これかはレスするときには分析者、実装者と開発規模とかも
記述した方がよさげ。
ちなみにオレは実装者、小規模
0668デフォルトの名無しさん
NGNGなんかおもろい活用法ないかなーと、
ちょろちょろうろつく予定です。
0669668
NGNG鬱氏
0670デフォルトの名無しさん
NGNGなんかよさげな物あった？
0671デフォルトの名無しさん
NGNG会社が金だしてくれたんでチュートリアルにでてきたよ。
というか、上司に「チュートリアル逝け」といわれた。
「超入門」というだけあって、内容は簡単だったよ。
ただ途中の「メタモデル」の部分だけはサパーリだったよ。
社内の報告＆内容発表ではそこはとばすつもりだよ。
資料がおおすぎて、時間が足りなくなって、とばしまくりだったよ。
事例が多かったので社内のUML化推進の材料にはなりそうだったよ。
質問はあまりでてなかったよ。
ただ途中いかにもオタクあがりのへんなやつが時間がないって急いでいるのに
意味不明の質問をしてからんでたよ。
昼休みにみたUMLでモデリングした自走ロボットカーのレースはおもしろかったよ。
0672デフォルトの名無しさん
NGNGやはり、そんな感じになるのね。
別の手のほうだが、データアクセスのところ（DAOね）は高スキルの人間に
任せたいので、その手法をとっているプロジェクトもある。大規模200人以上。
ただ、クラス側にあまりSQL書かないで、PL/SQLでストアードで実装し、
DAOをそれを呼ぶだけで簡略化しているようだ。
これをうまくやればＵＭＬ系の人と、ER系の人をある程度分離できるかなー？
ただ、667が言うように、両方使いたいんだよね。
DBがオブジェクトDBとしてもっと進化するか、UMLのステレオタイプが進化して、
詳細レベルはDBの物理実装まで記述でき、DBスキーマと対応取れるようになるまで、
インピーダンスミスマッチはごまかして行くしかないんだろうか。
あと、方法論と開発規模の件も同意。最近読んでる本によると、規模に応じた選択を
考える方法論がかかれているらしい（まだ、翻訳されてないみたい）。
ただ、開発中のコミュニケーション、問題発見のためのドキュメント等は規模依存と
思うけど、開発しちまったもののドキュメントは量を除き、システム規模でそんなに
変わらない気がするが、いかが。
0673667=670
NGNG>事例が多かったので社内のUML化推進の材料にはなりそうだったよ。
いいな！うちの職場もUML推進してほすい。
>672
両方使うときの最大の問題点はやっぱり同期なんだよね。
これを解決するいい方法が俺には思いつかない。
ツールもたぶん存在するだろうけど熟練度が低いと邪魔なだけ。
それに最悪1プロジェクト内に2文化が発生して実装側が混乱
し、それに伴いバグ頻発するし。いいアイデアがあれば教えて欲しいです。
ドキュメントについては同意。
でも大規模な開発に関わったことがないの正直分からんけど
オブジェクト数はどれくらいなるんだろ？
100を超えてくると混乱するからそれを解決するためにレベルが
発生してくるのでは？。
レベルがどのように分けるべきかははっきりと見えてないけど
それを管理するドキュメントみたいなものが別途必要なのかな。
0674671
NGNG一番上の人は推進せよっていって、
折れにいろいろ勉強させてくれてありがたいんだけどね、
開発の実質的な中心人物の先輩は「あんなもんは必要ない」って
感じの人なんで間に入る折れはちょっと苦しいかも。
もともとチュートリアルもその先輩に話があったのが
「忙しいから」と断わって折れに振られたわけだったし。
0675デフォルトの名無しさん
NGNGいわゆる抵抗勢力というやつですな。
0676デフォルトの名無しさん
NGNG俺もチュートリアルでたが、UMLを学ぼうと意気込んでいった
俺には前半以外は難しかった…。超入門とは思えない。
あれはなに？UMLを使うっていうよりは、UMLを研究している人たちの
場なのかい？
自分が場違いな感じがして情けなかったよ…。
> ただ途中いかにもオタクあがりのへんなやつが時間がないって急いでいるのに
> 意味不明の質問をしてからんでたよ。
あの人は他の会場にも出没して意味不明だった。
0677デフォルトの名無しさん
NGNG「UMLエディター作成者のための機能自慢大会」みたいで痛かったYO!
方法論のないUMLなんて...
0678デフォルトの名無しさん
NGNGあまり方法論に固執する問題あり
って言うてみるテスト。
0679デフォルトの名無しさん
NGNG君はおおむね正しい。
って言ってみるテスト。
0680デフォルトの名無しさん
NGNGあんまり開発方法論に固執すると問題あり
って言うのと同じ程度の意味しかないと思われ
0681デフォルトの名無しさん
NGNG方法論のない開発なんて、学習中の初心者か、
混乱しきって予測不可能になった開発現場にしか存在しないんじゃないかー。
そういう基本前提があるからこそ、
開発方法論の差異を超えた、共通のモデル記述言語＝UMLが、
重要なんだよね。
0682678
NGNGそうなんだよね。開発方法論は重要なのは確かだけどUMLだと
この開発方法でやらなきゃダメみたいな感じになってる人が
多い気する。>680が言うようにUMLで有効である開発手法は
ある程度決まってるが型にはまったやり方だけしか許されない
わけではない。
っていうかそれだとつまらんでしょ。（ｗ
0683デフォルトの名無しさん
NGNGようはある程度の方法論があった状態で、UML考えたような
気がするのは私だけ？
0684デフォルトの名無しさん
NGNG当然しょ。
最終的には普及のために方法論と独立を目指すとはいえ
開発方法論から生まれた話なのは間違い無し。
0685デフォルトの名無しさん
NGNG課のみんなに、使いにくいぞ。ゴルァ。とか言われるの怖いんですが、
UMLツールの選定、この選択で正しいと思いますか？ 当方、Java。
0686デフォルトの名無しさん
NGNG絶対、間違い。紙とペン。これがマジ最強。
0687デフォルトの名無しさん
NGNGうちも、とりあえず一つ買ってみた。
結構いいと思うし、コストパフォーマンスは優れていると思う。
とりあえず気になるのは、
○設計情報がXMLで交換できるはずなんだが、rose評価版とうまくいかなかった
○シーケンス図とコラボレーション図の自動変換ができない
以上は、まだ使い方よく分かってないからかもしれない。あと、多人数での
設計まとめるサーバは使ってないのでわからない。
オージスから出ているツールもよさそう。値段はMagicDrawの倍。
だれか使ってみたひといたらどんな感じ？ なんか、評価版が落とされまくった
らしくて、現在ダウンロード停止されているので、評価できない。
紙とペン派は、多人数で、コミュニケーション共有しなけりゃならない状況は
わかっていないと思われ。そもそもUMLはコミュニケーションツールなので
その手の方たちには必要ないだろう。
手書きのコピーを配布するなら、彼らには、ワープロも、visioもいらないだろ-な。
068830年前から時空を越えてレス
NGNG0689デフォルトの名無しさん
NGNG>○設計情報がXMLで交換できるはずなんだが、rose評価版とうまくいかなかった
XMI？XMIはまだ標準仕様が固まってないのでツール間での連携はあまり期待しない
方がいいと思います。
>○シーケンス図とコラボレーション図の自動変換ができない
普通はどちらか一つだけ書くものだと思うんですが、必要なんですか？
＃私はOMTから入ったので慣れたシーケンス図しか使いません
>紙とペン派は、多人数で、コミュニケーション共有しなけりゃならない状況は
わかっていないと思われ。そもそもUMLはコミュニケーションツールなので
その手の方たちには必要ないだろう。
最初あーでもない、こーでもないってやってるうちはホワイトボード最強ですね。
でもある程度固まったらツール使って清書するし、一人で考えてるときもツール
使って書いたり消したりしながら考えます。
ただUML使って設計を覚えようという人は、ツールをいきなり使うより手書きで
書いてみるといいと思います。OOA/Dの手法とUMLの記述法とツールの使い方を
いっぺんに覚えようとしたら挫折してもおかしくないでしょうからね。
0690685
NGNGマジレスありがとうございます。
とりあえずのリヴァース、フォワード、
あとチーム開発ができる安価なツール、
ということでMagicDrawを選定しましたので
Roseとの互換性はさほど気にならないんですが、
>○シーケンス図とコラボレーション図の自動変換ができない
はちょっと痛いですね。これだと、
リヴァース時のシーケンス図生成も行われないんだろうか……（；´д⊂）
というか、体験版さわってみたものの、
リヴァースしたクラスをクラス図に反映できん。
0691デフォルトの名無しさん
NGNG>689
シーケンス図とコラボレーション図は用途によって両方欲しいことが
多いと思う。ぱっと見はコラボレーションが全体像がつかめていいし
少し詳しくシーケンスを考えるときはシーケンス図。いずれにしても
同じ情報だから、いちいち書き直したくないなー。
XML形式はXMIと思われます（よく知らないものでスマン）。
そもそも、MagicDrawはセーブするとXMLのZIPファイル
しかファイルが作られません。これ、展開するとテキストで読めます。
これがXMIの構造になっていると思うんだが。
おっしゃるとおり、互換性はよくない模様（ツールメーカー何とかして欲しいな）。
>690
クラス図と、継承関係ぐらいまではリバースできた。シーケンスとかは無理と思う。
ただ、開発方法論の話になっちゃうけど、リバースはあまりやらないほうがいいと思う。
クラス図から直すのは大変だけど、トータル、長期的にはメリットも多しと思うのだが。
せっかくの設計が...とうことになりかねないと..。
もっとも、開発サイズとか、時と場合によりけりは方法論の常ですが。
チーム開発環境としては、結果レポート希望。
あと、紙＆ペンは否定はしてないが、これだけですむはず無し。
だれだって、メモ、走り書き、ホワイトボード図はかくに決まってるが
それだけだと、プロジェクト期間中もしくはその後メンテまでのスパン
でコミュニケーションできない。
ちょっと話がずれるが、昔、アクタとかMoreとかいう、MACでのアプリが
あったのを知ってるでしょうか。思考支援ツールといわれ、まあ今で言う
アウトラインエディタですな。ようは、ワープロは清書するだけでなく
これで書いていろいろ動かしていることで思考支援されると思われ。
論文書くときは、目次が一番苦しむからね。
いろいろあるカード利用の方法なんかも同じかな。で、ノートにUMLツール
いれて、プロジェクターでやってみようと思ってる。プロジェクター高いけど。
クラス図をカードにして、ボードであれこれ動かして議論するとよいと言う本
もあったが、あとでその結果を写すのが面倒。うまくいくと思うんだがだれか
やってみたことあります？ ERのレビューはこれでやったことあり（紙の配布も
同時にやったけど）。
0692narucy56 ◆wMOjCT4s
NGNG「コミュニケーションにコンピュータ使うことは人の視点を
コンピュータに向けてしまい、ダメ。視点は常に人に向いて
ないといけない。」
とのことで。
それ以前に、どうしても、印刷された UML図 が必要なシーンとい
うのが思い浮かばない。
わざわざ難しい設計にしてしまってるんじゃないの？ どうなの？
0693デフォルトの名無しさん
NGNGあとからシステムみるとき、
UMLないと泣きそうになりません？
コード追うのも、ヘタな日本語読むのも鬱。
0694デフォルトの名無しさん
NGNG>692
>それ以前に、どうしても、印刷された UML図 が必要なシーンとい
>うのが思い浮かばない。
ってことはUMLドキュメント自体は必要ってことでいいの？
XPだと違うかな？
0695デフォルトの名無しさん
NGNGと思います。それをどのように使うか、というところで違いがあるんでしょう。
個人的にはUMLは設計上のアイディアをある程度具体的にするために使います。
大体ツールを使って書きますが、UMLからコードを吐かせることはめったにし
ないですね。ときどきすごく細かく書くことにこだわってる人がいますが、分析
にしろ設計にしろあるところまでいったら先に進まないと煮詰まっちゃいますね。
細かいところを図にしてもわかりにくくなるだけなので、そういうところはメモ
をペタペタ貼り付けておいて、もし後で分かりやすく書けそうなら書き直します。
0696デフォルトの名無しさん
NGNGドキュメントとして提出できなくなることがしばしば。
またいちから書くのはダルい。リバースあればいいな。
0697デフォルトの名無しさん
NGNGオージスのツールというと、Konesaのことですかね。評価版を使ってみましたけど、
かなりダメな感じです。
Javaで作ってあるんで、重い上に操作性が悪い。クラス図はともかく、
シーケンス図がとにかく作りにくい。
素人にはおすすめできないけど玄人にもおすすめできないです。
リバースとかグループ開発の機能は使ってないので不明。
ちなみに普段はRoseを使ってます。Roseも、ときどきバグるけど、
Konesaより10倍マシ。
ところで最近話題らしいTogether Control Centerはどうよ?
0698デフォルトの名無しさん
NGNGレポートありがと。やっぱりRoseになるのかなー。
もう少し安けれ買ってみるのだが。お金のない人はやはりMagicDrawか。
今度、どこかの大き目のプロジェクトで、顧客だまして（もとい、推薦して）
Rose買ってみようと思ったりして。
>>692
「」の中はまったく同意だよ。昨日も顧客ががんばるから7時間ぶっとーしで
会議であった。基礎設計ね。
で、これらの会議の結果を、形にしないといけないだろ。
だいたい昨日も、その前の会議の結果を、ドキュメントにして、
それをレビューしてたの。
もっとも、UMLじゃなかったけど、UMLでいえば、ユースケースや
コラボレーション、クラス図で書くようなドキュメント類。
ドキュメントも無しで、てぶらで会議なんでできないでしょ。
大量の情報を、会議に出てる人間がまったく同様に完璧に記憶
なんてできないんだから。
相手が、今目の前にいるか、将来のメンテの人かいずれにしても
人とコミュニケーションするために、ドキュメントが必要なんだよ。
そのとき、UMLは記述方法としてよろしいと思う。
XPもドキュメントを書かなくてよいと誤解されてると思う。
不必要なドキュメントは要らない（コード見れば分かることとかね）という
ことと思う。
逆にコードもドキュメントとして読めるように書けということかな。あと、開発サイズもかなり小さくないと無理だろうね。
数100人でペアプログラミングしてるとこなど、見てみたいが...
0699デフォルトの名無しさん
NGNGクラス図があろうがなんだろうが、分かりづらいもんは
分かりづらいんだよな・・・。
できれば貴方のその、ドキュメントにしてレビューしたという
プロジェクトの内容はどんなもんなのか教えていただきたい。
0700デフォルトの名無しさん
NGNGできれば貴方のその、ドキュメントにしてレビューしたという
プロジェクトの内容はどんなもんなのか教えていただきたい。
（結局は「どんな機能を持ってるのか」ってところに着目できれば、
整理できると思うけどなぁ。）
0701デフォルトの名無しさん
NGNG「分かりづらい」ってのは君の個人的な意見だよな。
個人のレベルで主観的にいう「分かり安さ」というのは、慣れや経験、
バックグラウンドなどがかかわってくるので、いまいちつかみどころがない。
ちなみに俺は「どちらかというとUMLは分かりやすい」と感じている。
分かりづらいところがあれば、分かりやすくなるように改良する、
というのがUMLが求められていることだろう。
が、そのためには「何が」「どんな風に」「分かりづらい」かが
はっきりしないとかなり「つらい」。
ただただ否定するだけでなく、そこんとこもふまえてて建設的にいってくれ。
0702デフォルトの名無しさん
NGNG分かりやすい例とかURLとか。
よく見かけるのは、UMLの規格書にあるBank/Account/Personの例とか、
ウェブを見回るとあるDirectory/Filename/Fileとかで、そういったのを
見るとその時は分かったような気になるんですが、やっぱりよく分かりません。
いざ自分で考えてみると、そこに限定子が関与してくるのはわかるのですが、
限定子が関連のどっち側に付くべきなのかが混乱して分からなくなってしまいます。
なんかもっと分かる例と、手とり足とり解説してくれるのはないでしょうか。
0703narucy56 ◆wMOjCT4s
NGNG「限定子」俺もわかんなくて調べてみたけど、
http://www.atmarkit.co.jp/fjava/rensai/uml02/uml02.html
要するに、キーと値のリストを使ったオブジェクトで用いるものわしい。
（ただ、分かりづらいもの使っててもしょうがないよ。自分が分からないものは多分、回りの人も分らないのでは）
>>701
俺の経験では、5個以上のクラスが書かれたクラス図は分かりづらいクラス図。そんな沢山のクラス間の依存関係があっても困る。
もし 5個以上のクラス図を書かないと、具体的な機能の説明ができないようだったら、それはあまりいい設計とは言えないんじゃないの。
0704デフォルトの名無しさん
NGNGここで、pop型はpush型によって実現できるとする。
どいうことかというと、push型はデータが出来上がると
クライアントに送りだすとすると、pop型ではpush型のオブジェクト
にラップして、データが出来上がるまで待つ、という処理を
付け加えると考えると、内部でpush型を使っていても見かけ上は
pop型になるからである。
この場合pop型のモデルとpush型のモデルの関係は何だろうか？
pop型モデルはpush型モデルを使っているので、<<use>>依存関係。
push型モデルでpop型モデルを実装しているので、実装の関係。
push型モデルに機能を追加してpop型モデルにしているので、汎化特化関係。
pop型モデルはpush型モデルを含んでいるので、集約。
状況にも依存するとは思うが、果してどういう見方をするのが、正しいのだろうか。
0705デフォルトの名無しさん
NGNG内容は別として、複数のデーモンプロセスと、外部システム、webGUIが
協調して動くDBアプリだが。よくある話だ。
で、よく話が混同してるようだが、どちらもドキュメント要らないという
立場なのか、UMLはわかりにくいという立場なのかどっち？
698はドキュメントはいるだろ、という話なんだが。
で、わかりにくいという話なら、体系づけられたすばらしい
代替方法を教えてくれ。
UMLは単に記述方法なんで、詳細レベルとか、まとめ方とかでいくらでもわかり
にくくできるよ。英語で書いてあるから分かりにくい、フランス語で書いてく
れ。とぃう議論と同じに思える。
で、文法、単語ぐらい共通になってないとお互いコミュニケーション取れないから、UMLでどうです？ という意味だと思うのだが。
従って、「UMLでは...という概念がかけない」とか「文法が悪い」とかなら
議論になるが、単に分かりにくいといわれてもねー。できないやつが書いた
んだろ、ぐらいしか反応できないなー。
これだけ議論されてるわけだし、みなが同じ文法を使うということ自体も
重要。英語よりフランス後のほうが論理的だが、英語のほうが人数多いしね...
と同じ。
>698 ユースケースの話と混同してない？
機能記述以外にも、データ定義とか、インターフェースシーケンスとか
いろいろあるんだけど...
0706デフォルトの名無しさん
NGNGわざわざ調べてくれてありがとうございました。
UMLの規格の、区分(Partition)云々とかいう説明はよくのみこめなかったですが、
キーとそれによって引き出される情報、というとらえかたは解りやすかったです。
Directory/Filename/Fileの場合は、DirectoryからFilenameをキーにしてFileが引き出される。
そして、限定子を使って表現しない場合は、FilenameはFileの属性になる。
Bank/Account/Personの場合は、BankからAccountをキーにしてPersonが引き出される。
そして、限定子を使って表現しない場合は、AccountはPersonの属性になる。
もともとは、いっしょに仕事している人がオブジェクト指向(というかクラス図)がきらいな人で、
一つのクライアントは複数のサーバーにリクエストを出し、
一つのサーバーは複数のクライアントからリクエストを受ける、
一つのホストには一つのサーバーしかない、
という部分のクラス図でクライアントとサーバーに多対多の関連を引いたところ、
「だから、クラス図は使い物にならない」といわれました。
そしたら、UMLに詳しい人が、そういう場合は限定子を使うのだ、と教えてくれて、
その場はうまく治まり、よかったのですが。自分で何かしようとすると、混乱して
しまって解らなくなってしまってました。
おかげで今回少し解るようになりました。
0707narucy56 ◆wMOjCT4s
NGNG分厚過ぎる「ドキュメント」
http://objectclub.esm.co.jp/eXtremeProgramming/thud-j.html
「かんたんUML」とかオージス総研とかの本に書かれている UML を使った設計方法はかなりインチキだと思う。あんなのでうまくいくはずがない。
0708デフォルトの名無しさん
NGNGおまえUMLを使ったことないか、ちょっとさわった程度だろ。
使いこなせるようになればかなり便利だぞ。
憶測でものを言うなよ。
0709デフォルトの名無しさん
NGNGUML 一般を批判しているのではなく
《「かんたんUML」とかオージス総研とかの本に書かれている UML を
使った》 設計方法
を非難してるのでは？ 両方とも読んでないから、知らんけど。
0710デフォルトの名無しさん
NGNG俺も読んでないからわからんが、
どうせなら707が具体的にインチキさ加減を指摘して
708もカッカしないでレスしてくれれば
丸とは言わないまでも楕円くらいに治まってくれると思う。
0711デフォルトの名無しさん
NGNG0712デフォルトの名無しさん
NGNGそこに突っ込む前に「かんたんUML」と言うタイトルに突っ込まないのがおかしい
というてみるテスト。
0713デフォルトの名無しさん
NGNGそこに突っ込む前に「かんたんUML」なんてタイトルの本を手にとってしまう奴がおかしい
というてみるテスト。
0714デフォルトの名無しさん
NGNG失敗つうか、試行錯誤や再設計でそ、普通
0715695
NGNGクライアント？サーバ？ホスト？
いったいどういうクラス図を作ってるんでしょうか？
単純に多対多の関連なら関連端の多重度がともに0..*(または1..*)になるだけ
だと思うんですが。
0716デフォルトの名無しさん
NGNGhttp://www.sparxsystems.com.au/
0717デフォルトの名無しさん
NGNGダウンしてみました。ちょっと見ただけですが感想。
・日本語NG
・Win用で動作が早い
・ビジネスプロセスを表記可能（"Business Modeling with UML"？）
・DBの表記（PKとか）が可能
・実装言語へのフォワード/リバースエンジニアリング可能（出来は不明）
・ステレオタイプいろいろ
パターン、モデル共有等は未チェック。
日本語化して！
0718716
NGNG日本語はフォントを変更することで表示できることは確認済み
単にUMLだけではないのかな？個人ベースでは意味ないかも。
0719717
NGNGほんとだ。わからんかった。
メニュー-View-option-objects-Font name ...
安いのは大きな特徴だと思われ（149ドル）。
個人ベースの利用者増による普及は無い、に同意。
もともとそういう戦略ではないでしょ。
0720デフォルトの名無しさん
NGNG今現在、Javaのソースからシーケンス図を生成できるツールってあるんでしょうか？
惜しいのはあるのですが..。(Threadオンリーとか..)
それにしても、roseの体験版は何処で手に入れれば..。(コレだけまだ試せてない..)
0721デフォルトの名無しさん
NGNGRoseの体験版。.comの TryIt にあるじゃん。疲れてるな..。
0722デフォルトの名無しさん
NGNGなんだけど、読んだ人、感想ﾌﾟﾘｰｽﾞ。
(いつ出たのか知らないけど地元にはなかった)
0723デフォルトの名無しさん
NGNG地雷臭いタイトルだな（藁
0724デフォルトの名無しさん
NGNG0725デフォルトの名無しさん
NGNGhttp://pc.2ch.net/test/read.cgi/tech/1016842360/
0726デフォルトの名無しさん
NGNG0727デフォルトの名無しさん
NGNG人のソース読むときの参考として、クラス図を自動生成させたいんだけど・・・
0728デフォルトの名無しさん
NGNGdoxygen とか？
0729727
NGNG試してみた。
javadocを便利にしたような感じで、これはこれで使えそうだけど、
クラス図生成の能力がちょっと・・・
0730デフォルトの名無しさん
NGNGHAVE_DOT = YES にした？ これで多少はマシになる。
（でも UML お絵かきツールには及ばんけど）
0731デフォルトの名無しさん
NGNGシルバーって他にどんなのを覚えればいいの？
0732デフォルトの名無しさん
NGNG0733デフォルトの名無しさん
NGNG>事例が多かったので社内のUML化推進の材料にはなりそうだったよ。
社内のUML化推進をおこなうにはどうしたらいいでしょうか？
なんかいいアイデアはないですか？
0734671
NGNGいい方法があるならオレもぜひ知りたいです。
とりあえず、UML導入以前と以後でどうなるか、という観点から、
メリットとデメリットを列挙して説明する、という安直な方法でやってます。
けっこうこじつけがあります。
が、あんまりやるとかえって逆効果かなとも思ってます。
抵抗勢力が現場をしきっているので、なかなかむずかしいです。
あと、すでに終わった仕事とかを持ち帰ってUMLによる設計に
焼きなおして整理する、ということもやってます。
忙しいのであまり進んでませんが。
これはどちらかというと自分の勉強になってしまってます。
0735デフォルトの名無しさん
NGNGTogetherをつかいなさい。Roseが糞に見えてくる。
http://www.togethersoft.com
0736デフォルトの名無しさん
NGNGコンサルつきRUP導入するしかないと思う。
0737デフォルトの名無しさん
NGNGhttp://web.reedexpo.co.jp/SODEC/japanese/index.html
に行けばいろいろUML関連ツールは見られそうだ。
0738デフォルトの名無しさん
NGNGの違いがどうしてもはっきりと理解できません。
分かりやすく教えてください。
0739デフォルトの名無しさん
NGNGhttp://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」
どこが違うのかというと、オブジェクトの生成消滅のタイミング。
集約の場合は車をスクラップにしてもタイヤだけ取り外して使ってもいい。
コンポジションの場合は、手が成り立つには指が必須であり不可分の存在なので、
手を失うってことは指も同時に失うってこと。
0740デフォルトの名無しさん
NGNG俺もいまだによくわかんない。
738じゃないけど、便乗教えてくん
(1)「tires is a part of a car」とは言えないのですか？
(2)逆にいうと、タイヤはタイヤとして単独で存在できるが、指は指単独では存在できず、手の一部としてしか存在できない。
(これは正しいですか？)
(3)コンポジションは、集約の一種ですか？
(4)良くわかんない場合は、集約使っていれば間違いではないですか？
(5)実装してするときに、集約とコンポジションで差がつきますか？
0741デフォルトの名無しさん
NGNG(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 に書いたように消滅のタイミングが同じなのがコンポジション。
0742デフォルトの名無しさん
NGNGJAVAを使ったUMLの解説本はたくさんあるみたいだけど。
0743デフォルトの名無しさん
NGNG0744デフォルトの名無しさん
NGNG集約＝全体−部分関係をなす関連
合成＝集約の一種で「多くともひとつの全体に対する部分」になっているもの
といったようになってるようです。
というわけで、この“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.
0745デフォルトの名無しさん
NGNGタイヤとクルマの例だと、
タイヤとクルマは、それぞれ部分と全体を成すので集約であり、
さらに、タイヤは同時には１つのクルマの一部として機能するが、
同時に２つ以上のクルマの一部としては機能しないので合成である、
ということか。
あるクルマのタイヤを外して、別のクルマに取り付けた
場合はどうなるんだろうか。集約？ 合成？
0746デフォルトの名無しさん
NGNGパーツで構成されるコンピュータシステムは「集約」。
で、天板と脚から成るテーブルが「合成」。
『独習UML』から引用すると 744 が書いていることと同じだが、
合成は「部分側が単一のクラスの部品になっているような集約関係」
らしい。
つまりある環境において、部分が複数のクラスからも利用されて
いれば「集約」で、単一のクラスからしか利用されていなければ
「合成」になるでは。
>>745
別のクルマに取り付けられるという前提があるのであれば
「集約」ではないでしょうか。
0747デフォルトの名無しさん
NGNG> 別のクルマに取り付けられるという前提があるのであれば
> 「集約」ではないでしょうか。
なるほど、俺もそんな感じに思ってたよ。
だけど、>>744の「同時に（at a time）」というのに引っかかってしまったわけだ。
同時に、というのが集約と合成を区別するのだとすると、
ハードディスクやメモリーなどは合成ということにならん？
モニターについては複数のマシンで切り替え機を使うことで同時に
利用しているという考え方もありそうではあるが。
0748746
NGNGそうだね、「同時に」を考えるとパソコンの例は
合成だね。
今月の『JavaWorld』212頁にあるUML要素の説明からも
引用しときます。
コンポジション (ここで言う合成)
あるクラスと他のクラスの間に強い「has-a」の関係があることを
示す。この場合、「has-a」関係のhasに当たるクラスが削除されると、
aに当たるクラスもすべて削除されることになる。
0749仕様書無しさん
NGNG具象を設計するのは我々なんだから、
has-aをpart-ofとして設計またはその逆でも
問題がなければいいのでは？
0750デフォルトの名無しさん
NGNG実行しようとするとライセンスキーを聞かれる。
マニュアル読んでもdemo用のキーの事なんか書いてないし。
カネ払わないとdemoも実行できないの？
0751デフォルトの名無しさん
NGNG■ このスレッドは過去ログ倉庫に格納されています