UML皆でお勉強しよ♪ ３項関連

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

.＿＿＿＿＿＿＿＿＿
|　　　　　　　　　 |
|　　前スレはこちら　｜
|＿＿＿＿＿＿＿＿＿|
　　 ∧,,∧　||
⊂ミ.,,ﾟДﾟ彡つ

前スレ（１）：http://pc3.2ch.net/tech/kako/980/980236172.html
前スレ（２）：http://pc2.2ch.net/test/read.cgi/tech/1030173783

2 ：デフォルトの名無しさん：04/02/11 05:54

２げと

3 ：デフォルトの名無しさん：04/02/11 14:15

3項関連ｹﾞﾄ

4 ：デフォルトの名無しさん：04/02/14 16:24

で？

5 ：デフォルトの名無しさん：04/02/14 17:15

話題がないのに雑談とかどうでもいいレスで埋めなくてはいけない法もないよ。
質問は随時受付中。

6 ：：04/02/14 17:52

おまいらUML 2.0使う気あるか？
MDA関連の拡張目白押しだけど、、。

7 ：デフォルトの名無しさん：04/02/14 18:31

MDAは幻想ですが標準が2.0になったんならいずれ2.0には行くのでしょうな

8 ：デフォルトの名無しさん：04/02/14 22:07

UML2.0はセカンドシステム症候群になりはしないかと言われているが
どうなんでしょうかね？

9 ：デフォルトの名無しさん：04/02/14 22:18

ステートチャートなんですが、「分岐」ってどんなときに使うんでしょう。
条件判定なんかだと、「判定」という状態を作って、
そこから分岐させてすませてしまっているんですが・・・。

10 ：デフォルトの名無しさん：04/02/14 23:21

>>8
セカンドシステムってなに？

11 ：デフォルトの名無しさん：04/02/14 23:24

>>10
２版目の設計は調子に乗って盛り込みすぎ、だめになるジンクス。

12 ：デフォルトの名無しさん：04/02/15 00:15

>>9
判定状態は美しくないから

13 ：デフォルトの名無しさん：04/02/15 03:18

参考になるサイトのリンクとかないの？

14 ：デフォルトの名無しさん：04/02/15 10:40

普及の鍵はおまいらひとりひとりにかかっているわけで

15 ：デフォルトの名無しさん：04/02/15 11:57

>>14
┐(ﾟ～ﾟ)┌ じゃあ駄目だ

16 ：デフォルトの名無しさん：04/02/15 12:38

やる気なしね

17 ：デフォルトの名無しさん：04/02/21 14:20

つうかまあ、OMG自体がDesign by Committee の代表例な訳で。

18 ：デフォルトの名無しさん：04/02/22 01:53

OMG認定UML技術者資格試験というものがある。
http://www.umlcert.org

19 ：デフォルトの名無しさん：04/02/22 05:31

ＵＭＬも終わったのか・・・。

20 ：デフォルトの名無しさん：04/02/22 11:54

セカンド～にかかるってことは、実務者が規格策定の中心になってないってことを
示してるんだろうな。　机上の空論が混ざってるのが主要因なわけだろ？

21 ：デフォルトの名無しさん：04/02/24 08:06

つーか、2.0に追加されるものってほとんど人間用じゃないんじゃない？
モデルコンパイラなるものがモデルを解釈できるようにするためのものがメイン
だし。レガシーシステムの打ち直しが減るというのは、喜ぶべきかも
しれんが、一介のPGとしてはもっと開発全般にわたって役に立つものを
入れてほしいなぁ（じゃそれ何よ？といわれると困るが）。

22 ：デフォルトの名無しさん：04/02/24 12:46

>>21

そうでもないと思う。図の表現力が増すので、よりわかりやすい
モデルが作成できるのではないのかな？

23 ：デフォルトの名無しさん：04/02/27 16:08

Enterprise Architect (･∀･)ｲｲ!!
英語版で試用してるところなんだけど。もうRoseに金払う
時代は終わったか？

24 ：デフォルトの名無しさん：04/02/27 17:06

RoseはIBMのソリューション商売に組み込まれたから、
単体のツール販売とはレベルの違うところに移行しました。

25 ：デフォルトの名無しさん：04/02/27 17:59

>>23
試用版落としてみたけど英語版しかないんだね。

とりあえずフォントをMSゴシックにしたけど
関係を表わす矢印が文字化けしてる。これって既出？

--------->
オrealizeサ

なんて余分な半角カナが左右に出現する。

26 ：デフォルトの名無しさん：04/02/27 22:18

>>.26

それは確かどっかの設定を変えると直る
昔はまったような記憶が。

日本語版なら起きないとおもう

ところで、誰かEA4.0使ってみた香具師いる？
メニュー構成が変わったのでまだ慣れないけど
タブはけっこう便利かも

27 ：デフォルトの名無しさん：04/02/27 22:18

間違った
>>26 じゃなくって >>25 だ

28 ：デフォルトの名無しさん：04/02/27 23:00

>>26
今試用中なんだけど
ttp://www.sparxsystems.com/UseCaseDiagram.htm
この図の真ん中に <<extends>> ってのがあって、この括弧が
文字化けしてるみたい。<<realize>> とか、テーブル定義で
<<PK>> のところとか。

arialフォントだと表示されるけど、MSゴシックや明朝だと
半角カナの "オ" と "サ" になるね。これって << に見えるけど
違うってこと？

日本語版の方は文字化けを回避するオプションが追加されてるのか
そもそも文字を変えてるのか気になる。とりあえず落ち着いて試用
できないよ。。

29 ：デフォルトの名無しさん：04/02/28 04:59

>>28

試用版を英語のサイトから持ってきたなら文字化けするよ。
日本語のサイトのリンクからダウンロードすればいいかと。

まあ、要はUNICODE版を使うといいんじゃないの？ってこと。

30 ：デフォルトの名無しさん：04/02/28 12:43

ｐｄｆとか一般的なフォーマットで出力できないかな。
そのツールがないと見れないってのは何かと不便。

31 ：デフォルトの名無しさん：04/02/28 12:58

PDF書き出しのプリンタドライバ入れるとか。

32 ：デフォルトの名無しさん：04/02/28 13:19

ＵＭＬ図の良いサンプルがたくさん掲載されている、ＨＰってありませんか？

33 ：デフォルトの名無しさん：04/02/28 17:52

クラス図って実装段階に近づくほど、
ごちゃごちゃして、分けがわからなくなってきませんか？

34 ：デフォルトの名無しさん：04/02/28 18:33

モデルなんて無いさ
クラスなんて嘘さ
寝ぼけた人が
見間違えたのさ

マッチポンプマッチポンプ自作自演なのさ

仕様なんて無いさ
仕事なんて嘘さ

35 ：デフォルトの名無しさん：04/02/28 18:38

実践的なおすすめの本で新しめなのを紹介して下さい。

36 ：デフォルトの名無しさん：04/02/28 19:45

実践UML―パターンによる統一プロセスガイド
クレーグラーマン (著), Craig Larman (原著), 依田光江 (翻訳), 依田智夫 (翻訳), 今野睦 (翻訳)
http://www.amazon.co.jp/exec/obidos/ASIN/4894713861/
出版社: ピアソンエデュケーション ; ISBN: 4894713861 ; 第2版版 (2003/10)

Applying UML and Patterns: An Introduction to Object-Oriented Analysis
and Design and the Unified Process (2nd Edition)
by Craig Larman (Author)
http://www.amazon.com/exec/obidos/ASIN/0130925691/
Publisher: Prentice Hall PTR; 2nd edition (July 13, 2001)

37 ：デフォルトの名無しさん：04/02/28 20:48

UML distilled の 3rd Edition はどうなの?
amazon.com によれば2版で最もいらない部分だったラストのJavaでの実装の章がなくなったようだ。

1,2版みたいに邦訳って出るのかな?

38 ：デフォルトの名無しさん：04/03/01 10:49

>>36
翻訳本って読みにくい本が多いので、不安です。

39 ：デフォルトの名無しさん：04/03/01 11:07

>>38
原書読んだらいいやン。

40 ：デフォルトの名無しさん：04/03/01 11:44

>>39
それが出来たら苦労しね。

41 ：デフォルトの名無しさん：04/03/01 12:52

>>40
だったら我慢して訳本読んだらいいやン。

42 ：デフォルトの名無しさん：04/03/01 13:18

原書って読みにくい本が多いので、不安です。

43 ：デフォルトの名無しさん：04/03/01 13:25

>>41
ニッポン人が書いた本で良いのない？

44 ：デフォルトの名無しさん：04/03/01 13:35

でも確かに、あっちの本って版形が変だったり、
紙が厚くて硬かったり、レイアウトの感覚が日本語の書籍とちょっと違ってたり、
妙なフォントが使ってあったり（数字が上行ったり下行ったりしてるやつとか）、
言葉がわからない以上にどうも読みにくい。

45 ：デフォルトの名無しさん：04/03/01 14:28

シーケンス図のリバースエンジニアリングができるツールってありますかね？
EclipseUMLのEnterprise版のトライアルだと、ダイアグラム上にクラスを１つ置いてやると、
関連するオブジェクトは自動的に抜いてくれますが、シーケンス内部までは抜いてくれません。
やっぱりコレは手作業ですかね。。。

46 ：デフォルトの名無しさん：04/03/01 22:07

>>38

第2版もけっこうわかりやすいと思うのだが。
もちろん訳書のほうね

47 ：デフォルトの名無しさん：04/03/01 22:41

実践UMLは内容が良いので読むべき。
1版は訳された時代が古いので今からすると訳語が??なところもあるが。
2版は読んでないので知らん。

っつうかあの本ってUMLの本というよりGRASPの本だよな。

48 ：デフォルトの名無しさん：04/03/02 13:06

独習UMLという本は持ってるんですが、それでも
実践UMLの１版から読んだ方が良いですか？

49 ：U ◆CZtFsGiu0c ：04/03/03 15:46

>>48
第1版しか読んでないけど、第1版はUMLのバージョンが古いので第2版を読んだほう
がいいと思うよ。内容は確かにUML云々よりも(GRASPを始めとして)オブジェクト
指向設計の基礎を学ぶのに向いているんじゃないかな。

50 ：デフォルトの名無しさん：04/03/04 02:33

UML勉強しようと思って色々立ち読みして
「UMLモデリングのエッセンッス」ってのがよさそうだった。
ただ最近オライリーからも出たみたいでこれもよさげ。
個人的な感想では

エッセンス: ちょっぴり実践的な内容もある
オライリー: ちょっぴりリファレンス的な内容

って感じだったんだけど、好きな方選んでいいかな。その本は
やめとけなんて意見の人いる？

51 ：デフォルトの名無しさん：04/03/04 23:02

「UMLモデリングのエッセンス」の良さが立ち読みで解らなかったのなら、
まだ君には早いという事だ。あの薄さの割に中身は非常に深いからね。
もう少しオブジェクトについて学んでからまた読んでみるといい。
今から買って本棚に置いておくだけでも御利益はあると思うが。

52 ：デフォルトの名無しさん：04/03/05 00:41

>>51
ご利益があるのは確かだが、
しかし、あれはUMLを解説しているのだろうかと言うと？

53 ：デフォルトの名無しさん：04/03/05 01:03

>>51-52
やはりモデリングの方に重点が置かれてるってことですか。
両方買うことにします。

54 ：デフォルトの名無しさん：04/03/07 17:19

>>45
RoseRT。
でも高いYo! 俺もほしいYo!

55 ：デフォルトの名無しさん：04/03/07 19:51

正直、Ｍ＄が本腰入れて、.NETとかにこの手のツールを入れてきたら
寡占状態でぼったくりのＲｏｓｅもぬるま湯につかってられんだろうなｗ

56 ：デフォルトの名無しさん：04/03/08 16:10

ある画面から、複数の操作が可能な場合のシーケンス図って、
みんなどう書いてます？
記述順とかはあんまりｷﾆｼﾅｲ？

57 ：デフォルトの名無しさん：04/03/08 17:12

図を分けて作る。

58 ：おしえてくん：04/03/08 17:35

UMLってなんでつか？

59 ：デフォルトの名無しさん：04/03/08 21:10

ネタです。

60 ：デフォルトの名無しさん：04/03/08 22:57

>>58
ピッキングに使うドライバのようなものです。

61 ：デフォルトの名無しさん：04/03/08 23:31

なんか盛り上がらんな。
ﾈﾀで
資格試験問題でもさらして、みんなでつっこんでみるか？

62 ：デフォルトの名無しさん：04/03/09 00:30

UMLワークブックってやった人いる？
感想キボン。デザインパターン、オブジェクト指向の感想でもいいんで。

63 ：デフォルトの名無しさん：04/03/09 01:37

UML2.0対応のEnterprise Architectが2004/3/15に出るそうだけど（現在βテスト中？）
試した人いませんか？

64 ：デフォルトの名無しさん：04/03/09 02:09

まだ３／１５になってない罠

65 ：デフォルトの名無しさん：04/03/09 05:02

>>64

ベータ版は既に利用できる罠

操作系はけっこうよくなっていると感じた
意外にタブは便利です

66 ：デフォルトの名無しさん：04/03/10 19:58

EAの掲示板でJude薦めてる。。。

豪気だ

67 ：デフォルトの名無しさん：04/03/11 00:12

>>66
マジか？(w

しかし、あれでC++に対応してくれたら、もう十分なんだがな。タダだし。

68 ：デフォルトの名無しさん：04/03/12 13:52

UMLはお腹をいっぱいにしてくれますか？

69 ：デフォルトの名無しさん：04/03/12 15:08

？

70 ：デフォルトの名無しさん：04/03/12 15:10

金になるか？って質問だろ？ほっとけ。

71 ：デフォルトの名無しさん：04/03/12 16:23

ユースケース以外に使うものあるのか？

72 ：デフォルトの名無しさん：04/03/12 19:18

OMGはoh my godの略かとおもたよ

73 ：デフォルトの名無しさん：04/03/13 19:29

集約とコンポジション、関連の正確な違いがわからない。
で、先輩にきいてみた。

集約はクラスのメソッドローカルな関連、
コンポジションはクラスのフィールド、
関連は・・・単に使っている、
だそうです。

ホントかよ！？

74 ：デフォルトの名無しさん：04/03/13 23:22

>>73
その先輩とおまいは関連つくるな

75 ：デフォルトの名無しさん：04/03/13 23:48

>>74
同じパッケージの中にあるわけで。

76 ：デフォルトの名無しさん：04/03/14 00:27

>>73
【改訂版】初歩のUML　第4回
少しだけ高度なモデリング技術（その1）関連クラスと集約、コンポジション
http://www.atmarkit.co.jp/fjava/devs/renew_uml04/renew_uml04.html

77 ：デフォルトの名無しさん：04/03/14 01:24

オブジェクトの生存期間の違い。

78 ：デフォルトの名無しさん：04/03/14 12:21

>77 嘘を教えるなよ

79 ：デフォルトの名無しさん：04/03/14 13:17

UMLはC++と同じ末路をたどってるな・・・
何に使うのかわからない細かい文法をゴテゴテと安易に追加して、
みんなあきれて離れていってる。

いやUMLは普及していると言うだろうが、C++も普及してることはしている。
でも確実に衰退していってるけどね。UMLも同じだ。

80 ：デフォルトの名無しさん：04/03/14 14:32

リファクタリングとXPの大御所マーチンファウラー氏曰く、

UML2は糞
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?UnwantedModelingLanguage
UML2でプログラム作る奴はまぬけ
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?UmlMode

81 ：デフォルトの名無しさん：04/03/14 14:47

つうは、XP連中は元々こーゆーの嫌いだし。

82 ：デフォルトの名無しさん：04/03/14 17:30

>>79
離れて行ってるのではなく、従来の UML に留まってるだけだと
思うけど。俺も正直言って UML2 はマジメに覚えるつもり無し。

83 ：デフォルトの名無しさん：04/03/14 18:05

>>82
同意。MDAなんてウンザリ。
設計の表記でいいよ

84 ：デフォルトの名無しさん：04/03/14 18:15

MDAに向かうのは間違いないから注目だけはしておいている。
向こう数年で実践するとは思ってないけど

85 ：デフォルトの名無しさん：04/03/14 18:24

>>84
MDAって具体的にはなんなのよ？

86 ：デフォルトの名無しさん：04/03/14 18:43

モデルからそのまま具体的なシステムを作成するということ。

で、そのためのUML2はOCLとか細かすぎねぇ？と>>80で言われている。

私的にはMDAようにUML書くのと、プログラムするのと何が違うのだろう？
と思うし、それならいっそモデルプログラミングとでも言えばええやん。

87 ：デフォルトの名無しさん：04/03/14 18:50

ふつうにOOAからやってってOOPでコーディングする、じゃなくて、
UMLがソースで、UMLをコンパイルすると
CやJavaのコードができても一度コンパイルしてデプロイして即運用ってこと？
まじかよ。んなことできっかよ。上見たらHelloWorldも
できねぇって書いてあったぞ。

88 ：デフォルトの名無しさん：04/03/14 18:54

ライブラリやミドルウェアは、MDAで使ってもらえるようには、
UMLからの対応コードや設定ファイルへの変換モジュールを提供するわけか。

89 ：デフォルトの名無しさん：04/03/14 19:00

逆に言えば、CやJAVAに落とすからややこしいのであって、
モデルからそのままバイナリに落とせればよいのだが、
そのUMLはもはや従来のソースですらないわな。
（つーかそこにオブジェクト指向とかいるのかな？）

システム開発が視覚的ではないということに対してのUMLなのに
そこに厳密な文法導入したら手軽にモデリングできなくなるなぁ。
まさにセカンドシステム症候群そのままだね。

90 ：デフォルトの名無しさん：04/03/14 19:16

やっぱOMGってのは自分が世界を支配してるみたいな誇大妄想狂の
あつまりなんでないの？CORBAだって、妄想じみた仕様だして終わったし。
やばすぎ。

91 ：デフォルトの名無しさん：04/03/14 22:51

>>87

でも、夢というか理想としてはそういうことができてほしいんだけどね。

92 ：デフォルトの名無しさん：04/03/14 23:29

システムを作るための言語は時代とともに変わってゆくが、
システムそれ自体の構造は変わらないとしたら、
システムを作っている言語が古いというだけで、
システムを作り直すなんてばかばかしいわけだ（ホント馬鹿げている）。
だから、構造図そのものから動くものが作れたら、
その無駄なことをしなくてもよくなる。
発想はいい（心のそこから本当にそうなってほしいと思う）。
だけど、そのためにUMLが余りにも巨大で複雑で負担の大きいもの
になるのが困る。
（事前にオブジェクト図書けるならそのまま実装してしまう）
でも世界は確実にMDAに向かうだろうねぇ。

93 ：デフォルトの名無しさん：04/03/14 23:40

分析フェーズのクラス図と、実装設計のためのクラス図は違うと訊いたが、
その辺はどうなん？どっちを書けばモノができるんだ？

94 ：デフォルトの名無しさん：04/03/14 23:43

意味合い的にはf2cみたいなもんか？

95 ：デフォルトの名無しさん：04/03/14 23:51

>>92
システムはともかく文章へたやね

96 ：デフォルトの名無しさん：04/03/19 13:08

MDAが普及する為には、図を書く速度を簡単に上げられる工夫が必要なんでは？

昔脳波でマウスを動かすデバイスがあったと思うけど、あれを発展させて、
いくつかの特徴的な脳波を捉え記号化する事が簡単に出来るようになれば、
一気に普及するんではないか？

それと、マウスジェスチャーみたいなのをもっと進化させて
空間で手の動きを捉え、それで図を作る事が出来ればかなり便利になるのでは？

97 ：デフォルトの名無しさん：04/03/20 03:53

モデル図を生成するための記述言語を作れば良いのだ（ﾊﾞｶﾎﾞﾝのﾊﾟﾊﾟ風）

98 ：デフォルトの名無しさん：04/03/20 10:07

>>97
すでにOMGがXMIって仕様を作って公開してるだろ
MOF/XMI/UMLでセットみたいなもんだ
MDAが糞なのは揺るがないがな

99 ：デフォルトの名無しさん：04/03/20 17:07

モデルを定義したら、その4次元的な構図が頭に電極から送り込まれればいいんだよ

100 ：デフォルトの名無しさん：04/03/20 17:10

音声入力が一番楽

101 ：デフォルトの名無しさん：04/03/20 20:08

>>98
あまりに仕様がでかすぎて誰も実装しない。
いや、Rose とか一部実装しているのはあるけど、
XML Metadata Interchange というが Interchange する相手がない。

102 ：デフォルトの名無しさん：04/03/21 02:25

>>101

仕様が決まっていたらこれから作られるTOOLは準拠すんじゃない？

103 ：デフォルトの名無しさん：04/03/21 02:29

XMIってjudeも吐いた気がする。どれだけまともなのかわからんけど。

104 ：デフォルトの名無しさん：04/03/22 00:48

>>102
どうだろ。初版から2年経ってるけどね。
XML Schema と同じくメタスキーマなので、好きに作れる。
UML に関しては XMI に準拠したスキーマが定義されてるけど。

105 ：デフォルトの名無しさん：04/03/24 20:29

ソースコードの代替になるほどにモデリングしたら、
その結果はソースコードよりも理解するのが難解な
スパゲッティモデリングになってしまう矛盾。
実際スパゲッティのように矢印がグチャグチャ

106 ：デフォルトの名無しさん：04/03/24 20:48

今、とあるプロジェクトに携わっているのだが、
そのメンバーの一人が「アルゴリズムをクラス図で書く」ということ
に挑戦しているらしい。理由は、曰く「クラス図しかしらないから」
だそうだ。その青果物とやらを引き継ぐのは私なのだが、今のうちに
こいつを撲殺するか、ユーザガイド読ますかしたほうがいいだろうか？
だが時間の表現が乏しいクラス図でどうやってアルゴリズムを書くのだ
ろうかという好奇心もある。

どうしよう？

107 ：デフォルトの名無しさん：04/03/24 22:40

>>106

何もすべてのUMLの図を理解する必要はないと思うが、
クラス図だけっつーのはな。

ってゆーか、その人まさかフローチャートを知らんわけじゃないだろ。
ほぼフローチャート=アクティビティ図なので、だれでもこの図は書けると
思うんだけど。

108 ：デフォルトの名無しさん：04/03/24 23:23

シーケンス図だけでも十分な気がする。

109 ：デフォルトの名無しさん：04/03/25 00:01

>>106
アルゴリズムとはシーケンシャルな振る舞いのことだから、
シーケンス図でいいだろ。
あとはアクティビティ図かな。

クラス図が示す「クラス間の静的な関係」は、アルゴリズムとは関係ない。

110 ：デフォルトの名無しさん：04/03/25 01:08

>>107,108,109

わかってる、わかってるんだよ。
でも俺が書くんじゃないんだ、他人が書くんだ。
状態図やアクティビティを教えようとしても、聞かないんだよ。
「本来私にはUMLなんて必要ない」とのたまうんだ。
ちなみにシーケンスは却下だ。何故ならメソッド内でしか
処理を行わないからだ（視点を変えればシーケンスでも十分表現可能だと
思うが、それを理解させるほうが大変）。

つーかね、よくCOBOLerと世間では言うみたいだが、COBOL使ってるから
COBOLerじゃなくてCOBOLしか知らず新しいことを覚えようとしないから
COBOLerといわれるんじゃないか？と思った。
（UMLよ、早く普及してくれ）

111 ：デフォルトの名無しさん：04/03/30 00:57

111 ：デフォルトの名無しさん：sage ：04/03/25 22:45
>>107
フローチャートって…

アルゴリズム記述はPASCAL似の擬似言語で書くと決まってますが。
最近はC見たいのもあるな。

112 ：デフォルトの名無しさん：04/03/30 00:58

112 ：デフォルトの名無しさん：sage ：04/03/26 15:43
>>105
禿道
ＭＤＡを進めてるコンサル会社とかでも、割とシンプルにかけるケース
しかデモしないが、それなりの規模のアプリを書くとしたらそうなるね。

後ＵＭＬモデリングって、個人のモデリングの実力がコーディングよりも
出やすいので、スパゲティモデルになりやすいと感じた。

やっぱＭＤＡって無理っぽいな。

アルゴリズム記述はPASCAL似の擬似言語で書くと決まってますが。
最近はC見たいのもあるな。

113 ：デフォルトの名無しさん：04/03/30 19:22

110です。

たったいま、「アルゴリズムなクラス図」を引き継ぎました。
コレわすげぇわ・・・。

114 ：http://bulkfeeds.net/app/search2?q=UML：04/03/30 23:34

UML・仕様書・設計書関連2chスレッドのまとめ　（siyousyo - wikich）

http://pwiki.chbox.com/pukiwiki.php?siyousyo

http://bulkfeeds.net/app/search2?q=UML

115 ：デフォルトの名無しさん：04/03/31 00:51

>>114
乙。発展するといいね。

116 ：デフォルトの名無しさん：04/04/01 00:49

>>113
純粋にどんなものか見てみたい。

117 ：デフォルトの名無しさん：04/04/01 01:20

>>116
オレもﾉｼ

118 ：デフォルトの名無しさん：04/04/01 22:29

UMLって、基本的に枠組み作るだけで、
中の実装は結局自分でやらにゃいかんのじゃない。

万能だと思っている人、
クイックソートのアルゴリズムを
UMLから自動生成してみてください。

119 ：デフォルトの名無しさん：04/04/01 23:02

>118はUMLをいったい何だと思っているんだろう・・・

120 ：デフォルトの名無しさん：04/04/01 23:04

>>118
ここに居る人はさすがに分かってると思うけど。。。

121 ：デフォルトの名無しさん：04/04/02 00:13

>>119
そいつぁめんどいわ。ステートチャートとOCLでできるとわ思うが、
直書きしたほうが早い。
つーかシステムの構造とシステムの処理の構造は分けて考えたほうがすっきり
しない？クラスのアルゴリズムってクラスの責務でしょう？
それを一緒にするならフローチャートが一番すっきりすると思うが。

122 ：デフォルトの名無しさん：04/04/02 12:03

とりあえず UML が万能だと思っていたのは >118 だけか。

123 ：デフォルトの名無しさん：04/04/03 03:32

UMLを勉強しはじめたばかりのものですけど
このあたりのツールはどう？って既出ですか？
1st Modeller Standard Edition
ttp://www.vector.co.jp/soft/win95/prog/se269479.html
ttp://www.remus.dti.ne.jp/~tom3/
UMLmemo
ttp://www.vector.co.jp/soft/win95/prog/se215535.html

「1st Modeller Standard Edition」は非営利目的にのみ無料で使用可能だとか

ちなみに「1st Modeller Standard Edition」で趣味で作っているゲームの
クラス図を書いてみたんだけど、これでいいのかな？
ttp://pink.jpg-gif.net/bbs/18/img/44249.jpg

124 ：デフォルトの名無しさん：04/04/03 05:06

>>123

ツールについてはこっち
>おまえらUMLのモデリングツール何つかってますか？
>ttp://pc5.2ch.net/test/read.cgi/tech/1046441663/l50

クラス図についてはコメントのしようがない。
まじめに勉強する気があって、それなりに努力した成果を
あげれば、それなりにアドバイスはもらえると思うが。

125 ：デフォルトの名無しさん：04/04/04 02:15

>>123
実装レベルのクラス図には突っ込みの入れようがない。
ロバストネスが出てくるレベルでのユースケース図とシナリオ
ぐらいしかつっこめないんじゃない？

126 ：デフォルトの名無しさん：04/04/04 15:29

独学でUMLを１から勉強しようと思っています。
田舎なので講習会なんて近くでないし、会社からもお金出ないし

入門用の本としてお勧めはあるでしょうか？

127 ：デフォルトの名無しさん：04/04/04 16:21

>>126
「UMLのモデリングのエッセンス」
基本にしてディープ。純粋に読み物として面白いのでお勧め。

「オブジェクト指向とコンポーネントによるソフトウェア工学」
名前はいかついが、中身は基本。ただUMLというよりもOOより。

「UMLユーザガイド」
基本ではないがバイブル。仮にもUMLを習得せんとするならば所持して
おきたい逸品。（ただ読み物としては序文以外は面白くない）

「入門UML」
ケンドールスコット著。この人の書くUML絡みの書物はわかりやすいので
お勧め。

「リアルタイムUML第二版」
基本ではない。しかし面白い。

「ExecutableUML」
究極。

128 ：デフォルトの名無しさん：04/04/07 07:29

OCLを勉強したいんですが、何かいい書籍はありますか？

129 ：デフォルトの名無しさん：04/04/07 21:26

えらいさびれとるがどうした？
UMLももうおしまいか？

>128
ペンカーのビジネスモデリングとかどうよ？

130 ：デフォルトの名無しさん：04/04/07 23:29

OCLを具ぐると、
>私はモデリング中にOCLを使うことはほとんどありません。
>第1に、OCLの読み方を知っている人はあまりいませんし、(略）
>第2に、OCLは複雑です。（略）私個人的には、自由形式のテキストの方がずっと効果的だと気づきました。
>第3に、動くソフトウェアを生成できるようにルールを記述しようとするなら、
>私はJavaやC#などの本当のプログラミング言語を使うでしょう。
>
>OCLは興味深い概念ですが、まだ業界に受け入れられてはいません。
>すぐに受け入れられる様子もないように私には思えますので、
>覚えようと努力する価値はないでしょう。
>Scott Ambler
というのがあるのだが、どうだろう。
まあ、このひとはAgile派なんであれだけど。

131 ：デフォルトの名無しさん：04/04/08 23:36

OCLって本義は知らないが、MDA絡みならプラットフォーム依存（JDBCとか？）
よりメタなレベルで純粋なロジックを記述できる、と認識しているのだが、
どうなのだろう？どんな言語で書いても、その程度の、メタ記述はできると
思うのだが。

132 ：デフォルトの名無しさん：04/04/12 00:14

class CA

class CB{
CA ca;
}

これって集約ですか？コンポジションですか？

133 ：デフォルトの名無しさん：04/04/12 00:36

コンポジション

134 ：U ◆CZtFsGiu0c ：04/04/12 00:46

>>132
あちこちでこういう質問を見かけるけど、実装がこれこれだから、これは集約だとか
コンポジションだとかは明確にはしにくい。そもそもその例ではクラスメンバである
caのライフサイクルも示されてないじゃん。

135 ：デフォルトの名無しさん：04/04/12 00:49

>>132
ca が CB インスタンス以外から参照されず
生存期間が同じならコンポジション。

136 ：デフォルトの名無しさん：04/04/12 08:20

クラス図で質問なのですが、lispのCLOSみたいにメソッドがクラスに
属していない場合、クラス図ではどう書くのでしょう？

137 ：デフォルトの名無しさん：04/04/12 22:18

ステレオタイプを駆使。

138 ：デフォルトの名無しさん：04/04/14 01:42

そういえばlispって動的にクラスがつくれるんだよねぇ？
それってどうやって書くんだろう？
静的なクラス図では難しそうだね。

139 ：デフォルトの名無しさん：04/04/26 22:45

UMLの勉強始めたばかりなんだが2.0では
1.*の知識はムダになるの？

140 ：デフォルトの名無しさん：04/04/28 00:23

無駄にはならないだろうが、図が増えてる（2.0）

141 ：デフォルトの名無しさん：04/04/28 11:56

今MDA調べててここ覗いてみたんだが、
俺の調べた限りじゃＭＤＡはＰＩＭレベルの再利用性と
PSM自動生成によるプラットフォームの集約を目指すってことで
UMLからはソーススケルトンしか吐かないし、
大体が実装を意識してないUMLから実装コードを吐けるわけがない
という感じなんだが
プラットフォームに依存しないコードなら吐くってことなのかな
うーむよくわからん

142 ：デフォルトの名無しさん：04/04/28 14:12

なるほど、MDAツールって2種類あるんだね
スケルトン生成＋統合環境でコード作成支援するタイプと
コードまで全て生成するタイプ
しかしPIMレベルでコードを意識した設計するわけじゃないし、
どういう工程になるんだろう？
やっぱりよくわからん

143 ：デフォルトの名無しさん：04/04/28 23:40

Rhapsodyのトライアル版でもつかってみたら？

144 ：デフォルトの名無しさん：04/04/29 14:59

UMLマスターになるにはどんな本から入門してそのあと
どんな本にいくのがよろしいのですか？

145 ：デフォルトの名無しさん：04/04/30 00:31

規格書

146 ：144：04/04/30 07:05

>>145
くれ
PDF形式で
いやください

147 ：デフォルトの名無しさん：04/04/30 07:18

ほれ
http://www.omg.org/technology/documents/formal/uml.htm

148 ：デフォルトの名無しさん：04/04/30 10:45

eUMLって本当に使えるの?

149 ：デフォルトの名無しさん：04/05/04 16:17

compositeの使い方が
わからませんんんんんんんんんんんｎ
があああああああああああううううぐぐうえいさｌｋｄｓｊｆｋゎあ

150 ：デフォルトの名無しさん：04/05/09 01:26

ふじこ

151 ：デフォルトの名無しさん：04/05/12 18:49

UML2.0の規格書ってない？
ドラフトでいいんだけど

152 ：デフォルトの名無しさん：04/05/12 21:51

>>151
http://www.uml.org/

153 ：デフォルトの名無しさん：04/05/13 00:30

>>152
そこはもうさがしたんだけど
レポートしかないことない？

154 ：デフォルトの名無しさん：04/05/13 07:00

>>149
ライフサイクルが同じクラスの関連をあらわすときに使います。
aggregateと記号は似ていますが、かなり別もんです。

155 ：デフォルトの名無しさん：04/05/13 21:04

UMLはおなかがいっぱいになりまつか？

156 ：デフォルトの名無しさん：04/05/21 21:24

ビジネスマンのためのＵＭＬ入門　ビジネスモデリングによるアプローチ

これどうですか？

157 ：デフォルトの名無しさん：04/05/21 22:23

>>156

あなたの立場によっては役に立つ
エンジニアのUML入門用にはあまり役に立たないが
マネージャーなどの立場であれば役に立つと思う

158 ：デフォルトの名無しさん：04/05/21 23:53

UMLはおなかが空きますか？

159 ：デフォルトの名無しさん：04/05/23 13:06

シーケンス図で
コンストラクタはどのように表せばいいんでしょう？
それとも、シーケンス図にコンストラクタは入れないのがノーマルですか？
だとしたら、実装の時にプログラマが適当に実装しちゃう
感じでしょうか。

160 ：デフォルトの名無しさん：04/05/23 14:35

>>159

生成メッセージを利用する

おそらくどの書籍でも解説していると思うので
適当なのを読んでみるがよろし

161 ：デフォルトの名無しさん：04/05/26 16:01

UMLからC++実装ｺｰﾄﾞに落とすときは、やっぱSTL使うべきなのだろうか。
つーかSTL使わないとiteratorやらvectorやらのためにｺｰﾄﾞ書かなきゃならんのか。。。
うわぁ、STLも勉強せにゃならん。。。

162 ：デフォルトの名無しさん：04/05/26 17:17

WebアプリをUMLで設計する練習をしようとしています。
ユースケース図は書きました。
ページの繋がりというか入力ページからservletに値を渡して、Beansに格納して結果ページに
その値を表示というような流れを書くにはどの図を利用すればよいのでしょうか？
よろしくお願いします。

163 ：デフォルトの名無しさん：04/05/26 18:39

>>162

流れを書くにはシーケンス図かな
ただ、Webアプリのようなものであればロバストネス図という選択肢もあり

164 ：デフォルトの名無しさん：04/05/26 22:55

ＵＭＬのシーケンス図ででは、オブジェクト同士がメッセージ送信によって協調動作することになっている。
概念的には、各オブジェクトがそれぞれ独立的に存在し、必要に応じて通信を行っている。
しかし、メッセージ送信は、実際にはメンバ関数の呼び出しで表現される。
オブジェクトがメッセージを受け取ったときに、それに応じたメソッドが起動されるのではない。
オブジェクトを並列動作させるためにはスレッド化が必要だが、
そのための方法はいまのところ標準化されていない。

165 ：デフォルトの名無しさん：04/05/27 02:05

おそらく画面遷移図を描きたいのでしょう。であれば状態遷移図かアクティビティ図です。

166 ：デフォルトの名無しさん：04/05/28 02:37

UML使いはじめて間もない者ですが、画面遷移図なら、無理矢理UMLで書かなく
てもいいんじゃない？
UML2.0とかでツールと連携するんなら、ともかく、画面遷移を定義だけするな
ら、矢印でつながってればいいじゃん。
反論キボン

167 ：デフォルトの名無しさん：04/05/28 05:58

そう思うなら，別に使わなくても良いよ。
強制はしない。

共通仕様というのは皆が分かるように書くためのもの。
これが必要ない，代替手段がある，というのなら誰も止めはせん。

168 ：デフォルトの名無しさん：04/05/28 16:56

>>166

アンブラーも似たようなこと言ってた。
無理矢理UMLで書いてわかり難くするよりも、わかり易いものの方が
いい。

169 ：デフォルトの名無しさん：04/05/28 18:40

VISIOで状態遷移図書いて、UMLだと言いはればいいんじゃないか？
たいして変わらんし。
それで納品したよ？

170 ：デフォルトの名無しさん：04/05/28 23:48

>>168

XMLの「貴族とボヘミアンの階級闘争」みたいなものがUMLでも
起こるのだろうか。
UMLを厳密に使う派（MDA）vsスケッチ派みたいな。

171 ：デフォルトの名無しさん：04/05/29 02:49

クラス図の「関連」と「誘導可能な関連」って何が違うんですか？
単にあるクラスがあるクラスを使っているって解釈しちゃだめなの？

172 ：デフォルトの名無しさん：04/05/29 17:21

>>171
上流工程のモデリングだと具体的に参照がどちらの方向を向いているか決定できないことが多いです。
なので単純な関連を用います。
反対に詳細なクラス設計になってくると参照の方向性を厳密に決定することができるようになります。
そうした場合は関連の誘導可能性を有効にしたりしす（しなくてもかまいませんが）。
わたしはクラス図に具体性をより盛り込むことができるようになるので、結構使いますが、
一般的にはあまり利用されてはいないみたいですね。

173 ：仕様書無しさん：04/05/31 00:00

>>172
ソースとかを書くぐらいのレベルなら「関連」は全て「誘導可能」にできる
ということですか。なるほど、理解できました。
ありがとございました。

174 ：デフォルトの名無しさん：04/05/31 18:18

インスタンス同士なら一対多なんだけど、
それをクラス図で考えると多対多になるような場合、
一対多であることをどのように表現したら良いでしょうか？

例えば、あるシステムの一部で、ネットワーク上の通信を
司る二つのクラスＳとＣがあって、Ｃは必ず一つのＳと
通信し、Ｓは複数のＣから通信を受け取るとします。
これだけで考えるとＣからＳへの関連は一対多になるますが、
Ｃはその通信の種類によってあらかじめＳ１につながる
ものとＳ２につながるもの、というふうにクラスとして
考えるＣは複数のＳへつながるので多対多と考えてしまいます。
このような場合、インスタンス同士の一対多がクラス間で
は多対多になるようなものはクラス図上ではどのように
表せば良いのでしょうか？

175 ：デフォルトの名無しさん：04/05/31 21:13

>>174

ひとつのCにとっては必ずひとつのSのみと通信するということなので
クラス図でも一対他ということになるはず

インスタンスとクラスをごっちゃにして考えるから混乱する
クラス図はあくまでもクラスの図なので。

間違っていたら訂正ﾖﾛｼｸ

176 ：デフォルトの名無しさん：04/06/01 00:00

>>175
that's right.

>>174
クラス図はクラス間の静的な関係を考察するものなのでインスタンスは考慮しない。
具体的に言えば、もしそのSとCの関係を多対多と分析してしまうと、
Cから複数のSへの関連が発生、その結果、Cが複数のSと通信できるように
実装しなきゃならないことに。これじゃ困るわけでしょ？

177 ：デフォルトの名無しさん：04/06/01 01:21

>174
こんなんとか。
┌───┐1　 *┌───┐
│server ├──┤client　│
└───┘　　　└───┘
　　　△
　　　│
　 ┌┴─────┐
┌┴────┐┌┴────┐
│server_imp1││server_imp2│
└─────┘└─────┘

178 ：デフォルトの名無しさん：04/06/01 06:14

>>177

server_imp1とserver_imp2はこの例の場合、同じクラスの
インスタンスなんだよね？
となると、汎化するのは違う気がする。server_imp1:serverかな

179 ：デフォルトの名無しさん：04/06/01 22:05

>>178
リアライゼーションに見える。

180 ：デフォルトの名無しさん：04/06/02 22:29

あるクラスAのフィ－ルドがクラスＢであるときはＡとＢの間には
関連があるんですよね？
じゃあ、ＡのメソッドがＢを使用（参照？）しているときは何になるんですか？
やっぱり関連ですか？

181 ：デフォルトの名無しさん：04/06/02 22:37

DBとクラスがごっちゃになっていますね。
>>180

182 ：デフォルトの名無しさん：04/06/02 22:38

依存。点線の開いた矢印。

183 ：デフォルトの名無しさん：04/06/03 00:23

＞あるクラスAのフィ－ルドがクラスＢであるときはＡとＢの間には

この場合は集約じゃないの？

184 ：デフォルトの名無しさん：04/06/03 01:15

>>183
集約は関連の一種

185 ：デフォルトの名無しさん：04/06/03 20:56

>181
Java用語で、クラス内で定義されている変数をフィールドと言う。
ttp://www.google.co.jp/search?num=50&hl=ja&inlang=ja&ie=Shift_JIS&oe=Shift_JIS&q=Java+%83N%83%89%83X+%83t%83B%81%5B%83%8B%83h&lr=lang_ja

186 ：デフォルトの名無しさん：04/06/03 22:17

>>180
> じゃあ、ＡのメソッドがＢを使用（参照？）しているときは何になるんですか？
> やっぱり関連ですか？
<<use>>ステレオタイプのついたdependency relationshipというのは？
メソッドの引数なんかへの関係を敢えてクラス図に入れたいときにこれを使うという話を何かで読んだことがある。

187 ：デフォルトの名無しさん：04/06/03 22:32

観念論ばっかりだな（嘲笑

188 ：デフォルトの名無しさん：04/06/04 02:29

>>187
おまいの失敗体験きぼん

189 ：デフォルトの名無しさん：04/06/04 14:47

http://dictionary.goo.ne.jp/search.php?MT=%B4%D1%C7%B0%CF%C0&mode=0&kind=jn
> かんねん-ろん　くわん― 3 【観念論】
> 〔idealism〕物質ではなく観念的なもの（イデア・理念・意識など）が根本
> 的本質だとする考え方。生滅変転の現象界に対し永劫不変のイデア界の優位
> を主張するプラトンの客観的観念論、近代では物の存在を知覚に解消しよう
> とするバークリーの主観的観念論、経験的世界は超個人的な超越論的主観に
> より構成されるとするカントの超越論的観念論など多様に存在する。
> 「観念論」は主として認識論上の語で、倫理的な局面では「理想主義」と称
> する。また、存在論・世界観上は別に「唯心論」の語を与えることもある。
> アイディアリズム。
> →実在論
> →唯物論

だそうです。

190 ：デフォルトの名無しさん：04/06/06 04:23

>>186
是非にソース教えてください。

>>187
ソースに対してのUMLの記法の問題だから観念論（?）になるのかな。
別にエラーになるわけじゃないからねぇ～、そんなに詳細・正確には
書かないよね～。
MDAがはやってきたら記法にはうるさくなるだろうが。

191 ：デフォルトの名無しさん：04/06/06 10:11

>>190
comp.object見てるとよくでてくるよ。
http://groups.google.com/groups?num=100&hl=ja&lr=&ie=UTF-8&c2coff=1&q=use+stereotype+dependency+relationship+method
ここ↑にでてくるやつなんかはそんな話がちらほら。

おそらく、>>180に対する答えなんかはこれ↓っぽいし。
http://groups.google.com/groups?q=use+stereotype+dependency+relationship+method&hl=ja&lr=&ie=UTF-8&c2coff=1&selm=b28u3f%241a78ip%241%40ID-20080.news.dfncis.de&rnum=3

>>187のソース(俺は>>187ではないからそのものかどうかは知らんが)これら↓とかはそんなような話っぽいし。
http://groups.google.com/groups?q=use+stereotype+dependency+relationship&hl=ja&lr=&ie=UTF-8&c2coff=1&selm=407bda80%241%40news.totallyobjects.com&rnum=5
http://groups.google.com/groups?q=use+stereotype+dependency+relationship+method&hl=ja&lr=&ie=UTF-8&c2coff=1&selm=c6gf3k%24bjjf3%241%40ID-20080.news.uni-berlin.de&rnum=10
http://groups.google.com/groups?q=use+stereotype+dependency+relationship+method&hl=ja&lr=&ie=UTF-8&c2coff=1&selm=407bda80%241%40news.totallyobjects.com&rnum=4

俺の思うに、引数だと<<parameter>>スレテオタイプの関連を使うていうのがもっといいんではないかと。
現状のUMLだと意図が伝わればそれで無問題。>>190の言うようにMDAだと、然るべきところに然るべきものを
正しく図にしないとちゃんとコードを出してくれなくなるだろうから、そういったのはかなりうるさくなるかもね。

192 ：デフォルトの名無しさん：04/06/11 09:54

ＵＭＬの本で下記のようなのってないですか？

なぜ<<include>>を使うのか、
なぜ<<extend>>にした方が良いのか、などのオブジェクト指向の説明を含み、
現場で活用しやすい図や概念から優先的に取り上げていて、
実際のモデルを例に「なぜこうモデリングしたのか」の納得のいく説明がある書籍。

193 ：デフォルトの名無しさん：04/06/11 18:18

>>192

書籍じゃないけどこれは多少参考になるかも
ttp://www.atmarkit.co.jp/farc/rensai/uml_b_l01/uml_b_l01.html

194 ：192：04/06/12 14:22

>>193
参考になりました。
ありがとうございます。

昨日本屋に行ったのですが、
UMLの本って沢山売ってますね。
その割に普及してないような気が・・・。

195 ：デフォルトの名無しさん：04/06/12 14:27

>>194
意欲的に使おうとしているところもありますよ。
ただ納品物として求められていない限りクラス設計書なんかは作らないですね。
アーキテクトが存在する現場にも行き当たったことがありませんし……。

自分用の資料としては作っていますが。

196 ：デフォルトの名無しさん：04/06/12 14:46

「俺様専用UML活用法」
という本があれば買う。

197 ：デフォルトの名無しさん：04/06/12 21:48

>>195
漏れのところでは設計の際に必ず、クラス図・シーケンス図を書かされる。
当然それも納入対象。

198 ：デフォルトの名無しさん：04/06/19 20:41

UMTPのL1-T1、T2受かった。
が、この程度の問題できたところで何かの役に立つのだろうか？
やっぱOMGのじゃないと意味ないかなぁ。

199 ：デフォルトの名無しさん：04/06/21 13:51

シーケンス図で、
・メソッドを呼び出し、戻り値を受け取る
・その戻り値を、別のメソッドの引数とする

ということを表現するにはどうすればいいんでしょうか？
戻り値を保持する方法がわからず・・・

200 ：　：04/06/22 00:10

>>198
同じくこないだ取得しました。

認定者番号が異常に若いので、普及してないんだろうなぁとか
考えてしまい、合格したのにちょっと悲しい気持ちになりました…

201 ：デフォルトの名無しさん：04/06/22 01:36

>>198 >>200
旧ブロンズ／シルバー／ゴールドと比較してどのレベルかレポートしてもらえるとうれしいです。
私はブロンズとゴールドは取ったが、シルバーは１問足りなかった。
しかもあとでみなおしたら回答欄ずれが原因だった……。
ブロンズも何度か受けてると３回に１回は新しいことを知れたりして結構好きだったんですけどね。

202 ：デフォルトの名無しさん：04/06/22 01:38

>>199
戻り値は呼出元への点線で返すが、「保持」という概念をシーケンス上で表す術はないものと思われる。
名前やら型やらで類推するしかないでしょう。
例えば戻り値となったオブジェクトの名前をメソッドの引数に用いるとか。

203 ：デフォルトの名無しさん：04/06/22 23:11

>>201
珍しいなぁw ＞ゴールド取得&シルバー失敗
自分はシルバーとって、ゴールドはそのうちと思ってるうちにUMTPに移行しちゃった。

204 ：デフォルトの名無しさん：04/06/25 00:29

>>203
いかにPGに偏ってるかの証左だと思うよ

205 ：デフォルトの名無しさん：04/07/10 10:36

今シーケンス図のお勉強中なんですが、
いわゆるIteratorパターンの図を書こうとしてみてつまってます。

1)呼び出し元がAggregateクラスをcreateして、
2)呼び出し元がAggregateにiteratorよこせメッセージを送り、
3)AggregateがItertorをcreateして、
4)呼び出し元がIteratorにnextメッセージを送ると、
5)Iteratorが内部に持ってるAggregateの次の「行」を返す

のだと思うのですが、
5)を表現するにはIteratorの向こう(右側)に、さらにAggregate
がないといけませんよね？

そうした場合、IteratorをcreateしたAggregateと、Iteratorの向
こうのAggregateが同じモノだというのをどう表現したらよいの
でしょうね？

206 ：デフォルトの名無しさん：04/07/10 12:49

>>205
左向きの矢印書けば？

207 ：205：04/07/10 13:56

>>206
それありなんすか。
呼び出しは必ず右向き→でなければならないのかと思ってました。

ありがとうございます。
書きあがりました。

208 ：デフォルトの名無しさん：04/07/10 14:07

>>205
>5)を表現するにはIteratorの向こう(右側)に、さらにAggregate
>がないといけませんよね？
そんなことをしたらいかん
オブジェクトのクローンを生成しているなら話は別だが
同一のオブジェクトを複数書くとわけのわからんことになる
IteratorがAggregateの次の行を取得するメッセージをＸとすると以下の通り。

［元］
　∥
　∥―１→［Ａ］
　∥　　　　｜
　∥―２―→∥
　∥　　　　∥―３→［Ｉ］
　∥←………∥　　　　｜
　∥　　　　｜　　　　｜
　∥―４――――――→∥
　∥　　　　｜　　　　∥
　∥　　　　∥←―Ｘ―∥
　∥　　　　∥　　　　∥
　∥　　　　∥………→∥
　∥　　　　｜　　　　∥
　∥←………………５…∥
　∥　　　　｜　　　　｜

209 ：208：04/07/10 14:09

やっぱスペースがずれたか……
エディタにコピペして見てちょ

210 ：デフォルトの名無しさん：04/07/10 18:07

>>209
ありがとう。
いい人の多いスレだなぁ。

よい子が住んでるのがよい街なら、
いい人が住んでるここはいいスレですね。

211 ：名無しさん＠そうだ選挙に行こう：04/07/11 16:42

今、SOFTBANKの「コンサルタントになる人のはじめての業務分析」って本を読みながら
勉強しているんだけど
例として出てくる通販の分析でアクターとして消費者、生産者、配送者と出るんだけど
以前読んだオージスのチュートリアルの同じような例では、顧客(=消費者)は
システムに直接関わらないからアクターにならないと書いてあったんだけどどっちが正しいの？
個人的には「コンサル～」の説明の方がしっくりきたんだけど...

212 ：名無しさん＠そうだ選挙に行こう：04/07/11 17:03

>>211
それは視点が違うからだよ。
ビジネスドメイン分析の場合は、必ず顧客がアクターとしてでてくるよ。
システム設計の場合は、顧客という寄りはシステム利用者という視点でアクターがでてくる。
目的が違えばモデルにたいする視点が違う。
どちらが間違っているという話ではないと思うよ。

213 ：名無しさん＠そうだ選挙に行こう：04/07/11 17:09

>>211
どっちも正しい。
同じような業務でも要求されるシステム要件が異なれば
分析も変わって当然。
その辺をもう少し丁寧に読み込んでごらん。
それが分かるようになれば理解が進んだってことだ。

214 ：211：04/07/12 14:08

>>212,213
成る程、視点の違いだったんですね。
システムとしてどんなサービスを提供するか？
という場合はビジネスドメイン分析。
システムは(上記分析結果の)サービスをどのように提供するか？
という場合はシステム設計となるという理解でよいのでしょうか？
今までこういった点を意識して考えたことがあまりなかったもので。
(ほぼ受託開発オンリーだったからかも)

215 ：デフォルトの名無しさん：04/07/14 09:28

UMLというよりはオブジェクト指向プログラミングについてなんですが
メソッドに外から引数を渡すか、それとも
メンバ変数にセットしてそれをメソッドからつかうかで
悩んでいます。
こういった使い分けはどう判断していけばいいんでしょうか？
ちなみに今は、コンストラクタでメンバ変数をセットして
それをメソッドからつかってます。

216 ：デフォルトの名無しさん：04/07/14 09:30

複数のメソッド間で使い回される変数は
メンバ変数にセットし、
あるメソッドでのみ使われる変数は引数として渡す
といった考え方もあるとはおもうのですが、
その場合開発が進んだ際、ある１つのメソッドを
２つに分けようという場合にクラスの設計を大きく変更することになるため、
すべてメンバ変数にしているのですが、
メンバ変数の数が膨大になってしまうクラスも出てきたりして悩みます。

217 ：デフォルトの名無しさん：04/07/14 14:50

>>215-216
悩み方が非常に非オブジェクト指向的に感じるのだが、さて？
何をメンバ変数にするかはクラス分析の過程で決まるものだし、
開発が進んだあとでインターフェースを変更するようじゃ、
そら大変だっつうか、分析失敗してたんじゃないかとか、ねぇ？

218 ：デフォルトの名無しさん：04/07/14 18:54

何を引数にして何をメンバ変数にするかは
クラスで何を実現しようとしてるかによりけりですね。
具体的な要件が判らないと、なんともいいようがないです。

オブジェクト指向って現実世界の諸々を
クラスとその関係でとらえるって事だから
使い分けをどう判断したのかって聞かれたら
「だってそうなってんだもん」としか言えないかな。
特にエンティティの場合。

だから>217は言葉はきついけど、真っ当な答え。

でも、後で失敗したーって事も、正直あるよなあ。

219 ：デフォルトの名無しさん：04/07/14 21:46

>>217
実際の開発を経験せずに
紙上でオブジェクト指向神話をすりこまれた
人間のにおいがただよってるぞ。
一度「オブジェクト指向でなぜ作るのか」
という本をよんでみては？

220 ：デフォルトの名無しさん：04/07/14 21:46

実際の開発というのは、
オブジェクト指向による実際の開発
のことな。

221 ：デフォルトの名無しさん：04/07/14 21:56

>>218
現実の世界の諸々をたかがオブジェクト指向で
表現できるわけがないってことに気づいた方がいいよ。
>>219の本をあなたにも勧めておく。

222 ：デフォルトの名無しさん：04/07/14 22:05

プログラミング初心者でかつ最近 Struts とか使ってるのだが、最初にやったオブジェクト指向関連の言説
（フィールドとメソッドを持つのがオブジェクトだとか）がよく分からなくなってきた。

Action は Action するだけだし、データを持つ Bean は全然メソッドは持たないし。
こんな疑問を持ってるのは私だけなのか。

223 ：デフォルトの名無しさん：04/07/14 22:57

>222
システムがオブジェクト

224 ：デフォルトの名無しさん：04/07/14 23:32

>>215-216
コンストラクタで設定される値はあくまでも初期値だよ。
メンバ変数は、そのオブジェクトの状態を表しているものだよ。
状態というのは、刻々と移り変わっていくものなのだ。
変わらないなら単なる定数でいいわけだしね。
安全に状態を変化させるためにメソッドがある。
メソッドを呼び出すことで、オブジェクトの内部状態を
変化させることができるのだ。
メソッドには引数を持つことができる。
引数によって、オブジェクト外部の情報を内部に伝えることができる。
引数の値をメンバ変数にそのまま設定する場合もあるだろうし、
単に処理に使って終わりのこともある。
そんなのは作る人の都合なので、気にすることはない。

マイ注文 = new 注文(”田中太郎”, "2004/07/18");
明細１ = new 明細("弁当", 1);
明細２ = new 明細("おにぎり", 3);
マイ注文.addDetail(明細１);
マイ注文.addDetail(明細２);
マイ注文.checkOut();

こんな例で、明細をコンストラクタで渡してたら
大変だし、やっぱり買うのやめた処理もできない。
もう一度まとめると、オブジェクトは変化する。

225 ：218：04/07/14 23:39

>>221
うーむそうか。あの本って所謂オブジェクト指向の
ススメって訳じゃないんだ。
同じシリーズの他の本読んだ事あったのと
タイトルの印象で、入門書みたいなんだと思ってた。

そうねえ、失敗しとるって事は、「たかがオブジェクトで～」
って事なのかも知れないですね。
それにそう思ってる方が俺の心の健康にも良いし。
有難う、読んでみます。

226 ：デフォルトの名無しさん：04/07/14 23:45

>>222
オブジェクトっていっても処理だけの奴もある。
データだけ持っていればいい奴もある。
そんなのは設計者の都合だから気にするな。
基本は内部状態と、それを外からいじるインタフェースだ。
ActionはActionだし、データを持つBeanはBeanとわかる。
独立したオブジェクトとしてカテゴリ分けできるところが偉いのさ。

227 ：デフォルトの名無しさん：04/07/15 00:18

>>224
どうもありがとうございます。
すごくよくわかったような気がするのでコードをいじくり倒してみたいと思います。

228 ：デフォルトの名無しさん：04/07/15 07:27

オブジェクト指向がそんなにすばらしくて
クラス設計、分析に間違いが入り込む余地がないほどのものだったとしたら、
今現在これほどアジャイルプロセスや、RUPなどの
アイテレーション型の開発が叫ばれる理由もないわけで。
要は魔法のツールじゃないってこと。紙面に踊るうたい文句にだまされちゃあいけない。
とはいえ、oopのほうが従来のプログラミング手法よりは
そういった間違いを防ぎやすいしようにはなっていると思います。

229 ：デフォルトの名無しさん：04/07/15 23:52

>228
オブジェクト指向はうまく使えれば、いいものだと思う。
ただ、モデリングの方法をあいまいな表現を残さずに説明できるひとがいない。
誰にでも上手に使えるところまでいってない気がする。オレモナー

230 ：デフォルトの名無しさん：04/07/16 00:28

モデリングの方法をあいまいな表現を残さずに説明できる手法って何かある？
オブジェクト指向が特別曖昧だとは思わないけど。

231 ：デフォルトの名無しさん：04/07/16 01:55

UML

232 ：デフォルトの名無しさん：04/07/16 23:48

>>230-231
>>229の言ってるのはモデルを曖昧さなく表現する方法ではなく
モデリングの方法を技術として伝授できる人がいないってことっしょ？

日本人よりも西洋人のほうがこうした「技術の定式化」→「曖昧さのない伝授」は得意そう

233 ：デフォルトの名無しさん：04/07/17 00:13

>>232
訴訟王国だからなあ。
あと暗算が不得意ってのもかなりあるんじゃない？

234 ：230：04/07/17 00:31

>>229はオブジェクト指向のモデリングの手法が曖昧だと言ってるのかと思った。
>>230はどんな手法であれ(オブジェクト指向と同程度に)曖昧に決まってるじゃんと言っている。
最後はセンスとかそういうの。

あとモデリング以前に、顧客から情報を引き出すのに失敗してるのがガンだと思う。
顧客は嘘をつくからね。間違った情報に基づいて分析したってそりゃだめに決まってる。
合意した事柄に対する拒否権を顧客が事実上持っているかぎり、これは解消されないだろうねえ。

235 ：デフォルトの名無しさん：04/07/20 17:19

質問です。
・ユーザーがデータ受信ボタンを押した時、外部システムからデータを取ってくる
といったシナリオでユースケースを書く場合、アクターはユーザーだけなんですか？
外部システムがアクターになるのは(例えば)外部システムが定期的にデータを
こちらのシステムに送ってくる場合なのでしょうか？

236 ：U ◆CZtFsGiu0c ：04/07/20 17:37

>>235
その場合外部システムも立派なアクターです。

>外部システムがアクターになるのは(例えば)外部システムが定期的にデータを
こちらのシステムに送ってくる場合なのでしょうか？

これは、ユースケースを起動するアクターということですよね? 通常この
ようなアクターは「主アクター」と呼びます。ユースケースを起動する
アクターだけでなく、システム境界の外にあってシステムとやり取りする
ものは、なんでもアクターです。

237 ：235：04/07/20 17:49

>>236
どうもありがとうございます。すっきりしました。
236のシナリオで職場の人から
「ボタン押すのはユーザーなんだからアクターはユーザーだけだ」といわれた時、
それでは大半のC/S系のシステムではユーザーというアクターしか存在しないという話になるが、
そんな訳無いよなと思ったもので。

238 ：デフォルトの名無しさん：04/07/21 11:01

顧客に提出する場合、人間じゃないアクターに
棒人間の絵を描くのは、どうも抵抗があるんだよなあ。

これはUMLと言ってですね、ってな話から始めるのも
なんか客を上から見たような感じがしちゃって。

239 ：デフォルトの名無しさん：04/07/21 19:13

>>238
擬人化してみましたって言えばどう？

240 ：デフォルトの名無しさん：04/07/21 23:28

>>238
純粋に見た目だけの問題であれば
別の形で表現してもいいんじゃないですか？
Unifiedじゃないじゃんって反論もあるかもしれませんが
Languageは所詮道具なんですから
必要に応じて改良するのも手だと思います。

241 ：デフォルトの名無しさん：04/07/21 23:51

>>240
うん、実際にはやっぱりマシンの所はマシンの絵を
貼ったりしてます。

結局昔ながらの図表入り仕様書って感じですけど
まあいいや。

242 ：デフォルトの名無しさん：04/08/03 22:54

UMLを覚えるメリットを教えて下さい。
今の自分にはUMLは、*手段の手段の為*にしかならないとしか思えません。

243 ：デフォルトの名無しさん：04/08/03 23:04

>>242
ではそれ(UML)は貴方にとっての問題解決にならなかったのでしょう。
覚えるメリットなどと言う青い鳥探しは止めて貴方の問題解決にこそ時間を割いては如何でしょうか？

244 ：デフォルトの名無しさん：04/08/04 18:05

UMLを覚える前にJavaを知っていたほうがいいのでしょうか？

245 ：デフォルトの名無しさん：04/08/04 19:22

>242
そんなのどこの本にも書いてある。
「私にとって」UMLは大したモンじゃありませんという表明にはなってるが、どうやっても
質問には見えねえな。しかも他人やUMLからみれば無価値な情報だしナァ。

>244
教養として触れてみるということなら、UMLの理解にはさほど時間もかからないので、
とりあえずUMLだけやってみて自分で使えるかどうか判断すればOKだと思う。
UMLの考え方を学ぶのにC++、Javaなど個別言語の知識はあまり無くてもよく、
システムの分析や設計といった部分は理解できる。JavaにかぎらないOOライクな
考え方も同時に身についていくと思うが、こっちの方は必須知識。
実際にはプログラミング用途で使われることが多いため、Javaなどを使った
実装レベルの事例が用いられることは多いし、マの書いた図は言語の知識が
ないと当然読めないが、Java使ってないならそこは今すぐには必要ないんじゃね?

246 ：デフォルトの名無しさん：04/08/04 19:41

汎用とはいえやっぱり主には設計-実装用に使われてるものだと思うんだが、
プログラミングに縁が無いのにUMLやるのはどんな奴なんだろう。
幸せになれとんか？

247 ：デフォルトの名無しさん：04/08/04 21:44

Ｓヨ気分になれる

248 ：デフォルトの名無しさん：04/08/07 13:34

>>242
誰かの目的は他の人の手段になりますからね。
システム構築のが目的の人もいれば、手段の人もいる。

249 ：デフォルトの名無しさん：04/08/07 13:36

>>246
縁が無いというのがどの程度のことを指しているのかわかりませんが、
設計者はあんまりプログラミングに縁は無いです。

250 ：デフォルトの名無しさん：04/08/16 23:32

縁はないけど、コードをイメージしないで描く奴の図面ってのは
たいてい論理的に破綻しているんだよな…

だからプログラミングやれ！って話ではないけど
プログラミングを通らないで設計をびしっと身に付ける方法ってないかなあ
思いつかん…

251 ：デフォルトの名無しさん：04/08/17 09:18

簡単な要件定義レベルとか画面構成レベルなら、
コーディング知らなくてもできるかもしれないけど、
やはり最終的にコーディングやテストの根拠となるのが設計だから、
コーディング知らないでやるには根本的な矛盾が生じるよ。

252 ：デフォルトの名無しさん：04/08/17 17:48

つまらない質問でごめん。

みんなに聞きたいんだけど、たとえば自分があるシステムを作りたいと思った。
そのシステムの設計をUMLでやるとする。
どういう順番で図を書き出す？

ホントおれバカで、でもUML学びたくて勉強しているんだけど
どの図から書けばいいのかわかんなくて手が動かない。。。

ユースケースからアクティビティいってクラス図とかって変？

253 ：デフォルトの名無しさん：04/08/17 18:05

RUPよんだらいいんじゃないか。

つーかどっかに
UML分析からコーディングまでの一貫した流れを解説した本ないかな。
どれもこれもUML分析ばっかり。

254 ：デフォルトの名無しさん：04/08/17 18:18

RUPですか。いまググッて初めてしりました。
ありがとうございます。

にしてもそうですよね、出来上がったUMLとか、業務分析をした結果の
UMLはよく見るんですが、時系列でモデリングしていく様子とか、
そこからどのようにソースコードに起こすかがわかる資料がとても
すくない気がします。

先日EAを購入したんですけど、サンプルのUMLはついていますが、
どのような経緯でその完成にいたったのかがわかりにくく、
何から見ていけばいいか、迷っている次第です。

ベテランの方からいろんな意見を聞けたらうれしいです。

255 ：デフォルトの名無しさん：04/08/17 20:39

>>253
はげはげはげはげしく同意！

コーディングまで書けよ！解説しろ！お前ら理想論ばっかりで
最後までやったこと有るのかと小一時間…ヽ(`Д´)ﾉｳﾜｰﾝ

256 ：デフォルトの名無しさん：04/08/17 21:32

>>253,254

言うまでもないことかもしれないけど、UML自体にプロセスの概念が
ないのが今の現状の原因ではないかと思います。

まだ日本にはUMLをこれから始める人が多いので、どうしても
図の書き方とかそういうのばっかり本が出てるけど、
これからそうしたプロセスと絡められた本が出てくるんじゃないかな？

ちなみに、ICONIXもいいんじゃないでしょうか。
書籍名で言えば、ユースケース入門ですね。ピアソンの薄い本。

257 ：253：04/08/17 22:30

ICONIX本もってますよ～
UMLオブジェクトモデリングっていうやつ。
ただ、ICONIXを一番最初にやるのは混乱の元仮名という気がしますね。
周りに熟知している人がいない限りは！

258 ：デフォルトの名無しさん：04/08/17 23:16

>>252
2,3人でおわるような小さいシステムなら
ストーリーカード何枚か書いて、次はクラス図だなあ。
おいらの場合。

259 ：デフォルトの名無しさん：04/08/17 23:59

>>252
手元にあるオブ脳本だと
1.画面(概要程度)
2.ユースケース図
3.シナリオ
4.クラス抽出
5.オブジェクト図
6.分析クラス図
7.アーキテクチャの導入
8.設計レベルクラス図
9.ソースコード
10.フィードバック(1へ)
だって。何となくしっくりこない？

260 ：デフォルトの名無しさん：04/08/18 00:10

>>252
ケースバイケースだなぁ。俺は要件定義からキッチリやるときにはユースケースから
はじめるが、ある程度システムよりの仕事だと

クラス図・シーケンス図

をまず並行して描いて、あと複雑な振る舞いをするクラスだけステートチャートを
描く。

コーディング始まったらシーケンス図は更新せず、捨てちゃうことも多い。

261 ：U ◆CZtFsGiu0c ：04/08/18 00:31

>>252
いろいろやり方はあるけど、FDDの方法論を紹介すると、

ユースケースと並行してドメインモデルを作り、ユースケースごとにシーケンス図を書くと
ともにドメインモデルを設計レベルに落としていく。

てな感じ。
＃ただしFDDではユースケースでなくフィーチャだけど

あと、「ストリームラインオブジェクトモデリング」では、特定のパターンのオブジェクト
モデルをコードに落とすプロセスを解説しているよ。「実践UML」にもなかったっけ?

262 ：デフォルトの名無しさん：04/08/18 09:48

UMLが有効なのは、基本設計（外部設計）以降で基本的には
実装寄りの記述にならざるをえないだろ現状。
客にUML出してやっても「？」なことが多い。
システムのイメージがつかめないんだよね。
これは、ユースケース図でさえ同じ。
子供でも理解できるようなお絵かきをしてやるほうがマシ。

で、実装のためのUML書いてると、UML書くためにコーディングしてんだか
コーディングのためのUML書いてんだかわからなくなってきて、
最後は納品物の体裁を整えるという本末転倒な目的のために
ツール使ってソースからクラス図やらシーケンス図やらを起こすことが多い。

263 ：デフォルトの名無しさん：04/08/18 12:53

>>262
俺はシステムよりの仕事してて、クライアントと UML を使って打ち合わせする
機会はまずないので、前半はなんとも言えんが。

> で、実装のためのUML書いてると、UML書くためにコーディングしてんだか
> コーディングのためのUML書いてんだかわからなくなってきて、
それは確実に 262 個人の問題だって。UML で細かい部分まで書きすぎてるん
じゃないの？　全部のクラスやシーケンスを UML にする必要はなくて、設計が
見通しにくい部分だけ書けば十分だよ。

264 ：デフォルトの名無しさん：04/08/19 00:56

UmlAsSketch!!

265 ：デフォルトの名無しさん：04/08/21 09:50

OMG認定UML試験の勉強中なんだが、拡張がよくわからん。

「UML速習リファレンス」ってな本で勉強しているのだが、
模擬問題Q３５が全然わからん。

拡張点を一つ以上持たなければならないユースケースはどれか？
って問題で
「UseCase A」→「UseCase B」 (点線の矢印）
「UseCase E」→「UseCase A」 (点線の矢印）
「UseCase C」→「UseCase D」 (点線の矢印）
「UseCase C」⇒「UseCase B」（白抜き三角矢印）

ってな状態なとき、UseCase Bが答えなんだが、
なんで？
ステレオタイプ<<extend>>がついていないので
訳わからんのだが。

266 ：デフォルトの名無しさん：04/08/23 17:00

白抜き三角矢印はextendを表す。

267 ：デフォルトの名無しさん：04/08/26 11:12

もの凄い簡単なもので良いので、
どこかにWin32で組んだ実装レベルのClass図無いでしょうか

entity・boundary・controller間の、上手い関連付けの仕方がわからないんです
言語も何でも構わないです

268 ：デフォルトの名無しさん：04/08/27 20:58

無いのだろうか(´・ω・`)

269 ：デフォルトの名無しさん：04/08/28 00:33

スルーされてんだよ。

270 ：デフォルトの名無しさん：04/08/28 08:51

>>267
http://www.asahi-net.or.jp/~dp8t-asm/java/articles/ObjectModeling/article.html

271 ：デフォルトの名無しさん：04/08/28 14:23

UMLは今熱いでつか？

272 ：デフォルトの名無しさん：04/08/28 16:06

全然
MDAなんて方向になってから下火になってきたね

273 ：デフォルトの名無しさん：04/08/28 18:13

>>259
252ではないけれども、ちょっと疑問に思ったので質問。
4.はオブジェクト抽出じゃなくってクラス抽出なの？
それなら5.を飛ばして6.に行っても良いような気がするんだけれども。。

274 ：デフォルトの名無しさん：04/08/28 18:14

オブジェクト抽出が正しい

275 ：デフォルトの名無しさん：04/08/28 18:35

モデル駆動型アーキテクチャが熱い？

276 ：デフォルトの名無しさん：04/08/28 18:48

全然
まともな香具師なら、所詮無理だって分かってるもの

277 ：デフォルトの名無しさん：04/08/28 19:09

では何故に>>272??

278 ：デフォルトの名無しさん：04/08/28 19:19

UML2.0はほぼMDAのために策定されたもんだから
今後UMLと関わるとそっちの方に手を染めなきゃならなくなるから
開発寄りのUML使いは鬱入ってると思うよ
喜んでるのは設計厨だけ

279 ：デフォルトの名無しさん：04/08/28 20:03

このあたりマーチンファウラーのブログが有名なんで紹介しておくよ

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?ModelDrivenArchitecture
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?UnwantedModelingLanguage

いま、雑誌とかでUMLとりあげる時ってMDAの話もセットだろ？
まさにUnwanted Modeling Languageだよな

280 ：デフォルトの名無しさん：04/08/28 23:55

リンク先の翻訳が

UML=Unwanted Modeling Language　から
UML=Uzee Modeling Language になっていてﾜﾛﾀ

言い得て妙ですな。

281 ：デフォルトの名無しさん：04/08/28 23:55

>>324 今のドーピングは高度化していて、国家や企業の経済的技術的バックアップなしには不可能。

282 ：デフォルトの名無しさん：04/08/29 00:00

>>281は誤爆した。 EAいいね！

283 ：デフォルトの名無しさん：04/08/31 23:00

ドレスデン大学で開発されたOCLコンパイラなるものがあるらしいが、
どうなの？本当にOCLで書いたものが動くの？
だとしたら凄いかもしれない。

284 ：U ◆CZtFsGiu0c ：04/09/03 19:09

>>279
モデルの正しさを検証するために、モデルを実行することができたらいいな、とは
思うけど、モデルを詳細化してコードを不要化しよう、というのは非効率だし
非現実的でしょう。
＃ていうかそこまで詳細化したら既にモデルではないと思う

285 ：デフォルトの名無しさん：04/09/03 22:33

>>284
＞そこまで詳細化したら既にモデルではない
なので、特定のドメインに特化した MDA ツールしかありえない。
PIM → PSM 変換のフレームワークをドメインごとに用意して、
その枠内で開発をしてもらうってことになるかと。

3 層 Web アプリは既存のフレームワークが充実しているから、
MDA に狙われやすそうだ。

286 ：デフォルトの名無しさん：04/09/07 10:06

ローカルクラスの表記ってどう書くの？

287 ：U ◆CZtFsGiu0c ：04/09/07 11:19

>>286
「Javaの」ローカルクラスですよね?
特別な表記はないと思うので、ステレオタイプ作ったら?
＃<<inner class>>ってステレオタイプは見たことあるな

288 ：デフォルトの名無しさん：04/09/10 00:35

へぼな質問ですみませんが、
クラス図で、属性として記述するのと、
集約で記述するのの違いって何でしょう？
属性がクラスであれば、外に出して集約にすることもできる、
ということでしょうか？
ほとんどの属性はクラスでもあるので、
属性と集約は、単に「記述の詳細さ」が違うだけ…という事でしょうか？

289 ：デフォルトの名無しさん：04/09/10 10:40

今から聞き取りに行ってきますage

290 ：デフォルトの名無しさん：04/09/16 17:58:05

本当に初歩的な質問で申し訳ないです。

普段、ER図やDFD図などでを用いてテーブル設計を行っているのですが、UMLは
テーブル設計にも適用できる記法でしょうか?
それともUMLはあくまでクラスの設計を目的としているのであってテーブル設計には
向かないのでしょうか?

291 ：デフォルトの名無しさん：04/09/16 18:32:01

適用出来るって事になってますが向いてるかどうかは
やった事ないんで判りません。
書籍も出てますね。
http://www.amazon.co.jp/exec/obidos/ASIN/4798103675/qid=1095327048/ref=sr_8_xs_ap_i1_xgl/250-8405791-1557817

292 ：デフォルトの名無しさん：04/09/16 18:51:58

O/Rマッピングにまつわる諸問題がそのまま当てはまりそうな…。
UMLで導出した「クラス」をどうやって「テーブル」に変換するのか気になる。

293 ：デフォルトの名無しさん：04/09/16 18:57:08

>>292
オブジェクト倶楽部のMLでその話題出たばかり。
やっぱりみんな悩むよねぇ。

MLで紹介されてた。↓
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=13071&forum=25&start=8

294 ：デフォルトの名無しさん：04/10/11 20:13:28

これからUMLを学ぼうかと思っている人間なのですが
今、私は品質保証の業務についています。
UMLを取り入れたとして、どのような成果が見込めますでしょうか
またUMLをどう有効に取り入れるべきでしょうか？

295 ：デフォルトの名無しさん：04/10/11 21:26:48

>>294 warata。なんか大学のレポートの課題みたいだ。

296 ：デフォルトの名無しさん：04/10/13 22:35:01

>>294
こんな成果が見込める・・・かも。
http://ne.nikkeibp.co.jp/members/NMDNEWS/20040913/105369/

297 ：デフォルトの名無しさん：04/10/15 10:12:28

設計段階のお話なんですが、
DAOはドメインモデルなんでしょうか？
SessionFacadeのSessionBeanはドメインモデルなんでしょうか？
BusinessDelegateのDelegateクラスはドメインモデルなんでしょうか？
EntityBeanは、ドメインモデルな気がしています。

298 ：U ◆CZtFsGiu0c ：04/10/18 13:40:20

>>297
なにを持ってドメインモデルと呼んでいるのかわからない。
というか、それを質問してどうしようというの?

ドメインモデルは問題領域のモデルであって、解決領域に属するDAOやらなんやら
とはそのままイコールにはならないよ。

299 ：デフォルトの名無しさん：04/11/15 18:47:09

UMLとはちょっと違うかもしれませんが
状態遷移図が凄く簡単に書けるツールって無いですか？

300 ：デフォルトの名無しさん：04/11/16 00:22:05

漏れはシーケンス図だけでいいな。

301 ：デフォルトの名無しさん：04/11/21 22:06:17

UMTPのL1もOMGのファンダメンタルも受かったから
それぞれ上の奴受けようとしたら、
対策本出てないじゃん。
勉強できねえよ。

302 ：デフォルトの名無しさん：04/11/22 09:18:32

303 ：デフォルトの名無しさん：04/11/23 11:16:27

umlが書けるようになる → モデリングが出来るようになる
わけじゃないんだよね。

しっかりがっちりモデリングの基礎を学ぶにはどうしたらよい物か…

304 ：デフォルトの名無しさん：04/11/23 14:24:41

>>303
数こなすしか無いに決まってるだろ！！

…と、思っていくつかの経験を歴たが、
やればやるほど場当たり的になっている俺…

305 ：デフォルトの名無しさん：04/11/23 15:05:34

>>304
慣れれば性格で綺麗なモデリングが出来るようになるもんじゃないと思う。

ある意味学問だし。

306 ：デフォルトの名無しさん：04/11/23 20:51:23

慣れだな。学問だなんて高尚なことをいうやつはUMLモデリングを勉強し始めた初心者だろう。

307 ：デフォルトの名無しさん：04/11/23 23:08:28

モデリングを「慣れ」でやられてたまるか…

データベースなら正規化を知らないような奴が設計したテーブルが
使えないのと同じ。

308 ：デフォルトの名無しさん：04/11/23 23:23:27

理論なんてつかえないよ。
実践の域にまだ達していないな。
あらゆる分野と同様に。

309 ：デフォルトの名無しさん：04/11/24 00:57:53

デザパタ本とかMVCとかしらないで慣れでやってるやつは
射殺ものだな。
逆にある程度しっていて、理論と実践のすり合わせは慣れるしかないと
言うやつには納得できるかな。

>>308
> あらゆる分野
あらゆる分野ですか。そうですか。

310 ：デフォルトの名無しさん：04/11/24 09:51:04

>>309
> デザパタ本とかMVC

いやそれはモデリング理論というよりはオブジェクト理論な気がする…
ものすごく実装寄りの話だし、そこまで下流ならばある程度は「慣れ」で
いいのかもしれない。

もっと上流。データベースの世界で言えばE-R図やDFDに相当するレベルで
はUMLで言うとなんなのだろう?
あの辺りを実践と慣れだけでやられるとプロジェクトはたちまち破綻する。

311 ：デフォルトの名無しさん：04/11/24 10:13:47

>>310
UMLだと概念モデルとかドメイン（問題領域）モデルとかいうね

312 ：デフォルトの名無しさん：04/11/25 14:17:20

例えばどのような理論が有名なのですか？

313 ：デフォルトの名無しさん：04/11/25 23:10:18

>>312
ファジィ理論とか

314 ：デフォルトの名無しさん：04/11/26 09:43:56

カオス理論とか？

315 ：デフォルトの名無しさん：04/12/14 19:28:48

>>305　ある意味学問だし。
どんな学問？

>我々の経験によればオブジェクト指向の観点を最初に(アルゴリズムの観点より前に)
>適用することが望ましい。なぜならこのアプローチはソフトウェアシステムが
>本来もっている複雑さを組織化することを助けるのに適しているからである。
...........
>Boochがオブジェクト指向を勧める理由は、自らの経験というわけです。
http://www.asahi-net.or.jp/~dp8t-asm/java/articles/OOAD/article.html#id_199_

こういう経験的なものを「学問」と呼ぶことに抵抗感はないですか？
もちろん学問と言えないからといって役に立たないというつもりはないです。
ただ、対象に応じた付き合い方というものはあるだろう、と思います。

316 ：デフォルトの名無しさん：04/12/14 21:18:40

むしろ君の学問に対する考えの狭さに抵抗感を覚えるが。

317 ：デフォルトの名無しさん：04/12/14 22:12:33

医学や薬学は経験科学だね。

318 ：デフォルトの名無しさん：04/12/15 00:30:50

心理学はカルトだよね？

319 ：デフォルトの名無しさん：04/12/15 00:47:11

心理学はアンケートだ

320 ：デフォルトの名無しさん：04/12/15 11:15:10

そもそも、因果律自体が経験則だし。
したがって、自然科学は経験則。

321 ：デフォルトの名無しさん：04/12/19 16:14:01

UML盛り上がらんな。

322 ：デフォルトの名無しさん：04/12/19 17:20:10

本屋いくと本はいっぱい出てるし、売れてるみたいよ。
でも、やっぱ、お仕事向きなんでしょうね。
趣味でやってる人にはあんまり広まらないかも。

323 ：デフォルトの名無しさん：04/12/19 22:44:47

「MDAのエッセンス」と「OCL」を買ってきた。
エッセンスのほうはスコットさんが書いてるみたいなので少し期待。
（メラーの文章は面白くないからねぇ～）

しかし、なんだね。ここ最近「マネージャのための～」とか
「UMLで見積もり～」とかいうタイトルが増えてきた一方で、MDA
絡みも増えてきたね。
管理系or設計系のUMLの二極化が進んでいるのだろうか？
どう考えてもMDAに特化したUMLを管理者が読めるとは思えないし。
ってゆ～かね、「UMLを動かす」為にUMLを難しくする意味って何だろうね。
俺には理解しがたい。

324 ：デフォルトの名無しさん：04/12/19 22:58:33

>>323
MDAを使うために、なんか「特化」しなきゃならんようなことってあったっけ？
とりあえず、ツールが日本語名と実装名の対応を管理するような
機能を持つまでは、日本語の名前が使えない、
って事ぐらいしか思い当たらんけど。

325 ：デフォルトの名無しさん：04/12/20 23:01:15

>>324
ごめん、言葉を間違えた。
OCLでごてごてになった状態機械図は～っていいたかった。

326 ：デフォルトの名無しさん：05/01/10 06:26:07

つうか、プログラマーのほうが、
状態遷移という概念を理解してくれんのですけど・・・。

なんか、やたら判定条件の多い要件があって、
毎回いちいちチェックするような話をしてたので、
ステートチャートに整理したら、
「なんですかそれは？」という顔をされて全然相手にされんかった。

「◎◎が△△の場合と、□□が○○の場合と・・・・」っていう
形でしか理解できないみたい。

327 ：デフォルトの名無しさん：05/01/10 13:59:43

それは・・・そのPGのレベルが低いだけなんじゃないの？
状態機械図くらい今時は新人でも理解できるよ。

328 ：デフォルトの名無しさん：05/01/10 14:56:44

まあ、そうなんだけど、どうやって教育したらいいものか。

十年程前にも、別のプログラマーが、通信プログラム作ってて、
ろくに仕様もよまずに通信が失敗する現象が出るたびに、
対症療法で無理やりエラーが出ないようにしてるのに
付き合わされて、キレそうになった。

だからまずプロトコルの仕様をちゃんと読んで通信モードの管理をしろ、
プロトコルに問題があって通信がうまくいかないのか、
プログラムがプロトコルの仕様を満たしてないのか、問題を切り分けろ
といったら、「そんなのは理想論だ」とか言い出すし・・・。

もう、そういうのなしで何年も仕事やってきて、
一丁前になったつもりになった奴ってどうにもならん気がする。
だって、あっちは、こっちに「現実を教えてやる」つもりでいるんだから。

329 ：デフォルトの名無しさん：05/01/10 15:17:16

>>328
お疲れ様。本当にお疲れ様、と言いたいが、悪いが板違いだ。

330 ：デフォルトの名無しさん：05/01/10 18:43:37

>>328
マ板逝けやゴルァ

331 ：デフォルトの名無しさん：05/01/10 21:17:54

>>328
大変だな。
一番良いのは、無能を切ってまともなやつを買う事だが、
無理なんだろうなｧ。

332 ：デフォルトの名無しさん：05/01/11 10:08:15

UMLでシステム構成図書きたいんでつが、
何図になりすか？

ＰＣとか機器とかサーバーとか並べたいんでつ。

333 ：デフォルトの名無しさん：05/01/11 10:25:43

配置図・・・かな？
しかし、これもUML 知らない人には全然分かってもらえない図の一つだな。

334 ：デフォルトの名無しさん：05/01/11 10:36:07

ｻﾝｸｽでつ>>333

もしかして、配置図って2.0から？
2.0って説明サイト超少ないよねー。

335 ：332：05/01/11 13:13:31

コンポーネント図と配置図はイコールでつか？
UMLが統一したのは良いけど、ちょっとバージョン乱立だよね。

336 ：332：05/01/11 14:21:07

UML1にも配置図ありますね。
日本語訳が色々あって見間違えますた。
配置図の説明とか例が少ないな。

337 ：デフォルトの名無しさん：05/01/11 19:07:53

いきなりＵＭＬ２．０でサクサク書けるようになる良い本は無いで塚？

ユースケース本買ったけどＵＭＬ説明とかサンプル図が少ﾅｶﾀﾖ。

338 ：デフォルトの名無しさん：05/01/12 00:16:29

2.0は出たばかりなので日本語の書籍は少ない。
洋書なら山ほどあるが。

PGが最低限知っとけばいいのは
クラス図
シーケンス図
ぐらいのもんじゃないの？
余裕があれば、
アクティビティ図
状態機械図

コンポーネント図、ましてや配置図なんて上流くらいでしか
お目にかかったことがない（そんな私は下級SE～）
俺がJAVAの案件で今一緒に働いてるPGは（元COBOLER）UMLどころか、
JAVAすら知らないがな･･･。
（intってIntegerの名前ですよね？だとよ･･･）

339 ：デフォルトの名無しさん：05/01/12 09:58:58

イーサネット内にPCや機器が入ってる絵を描くときは、
UMLダイアグラムを無視しして一般的なネットワーク絵みたいなのが良いのかな？

340 ：デフォルトの名無しさん：05/01/12 10:33:23

ユースケース図にデータの伝達方法（ファイル渡しとか、ＨＴＴＰとか）を入れたいと思いましたが、
ユースケースは純粋な要求だけしか書けないんですね。

配置図でも伝達方法は書けないし、どのダイアグラムを使えば良いですか？
コミュニケーション図にも媒体は書いてないしオブジェクト同士のメッセージに限るのかなぁ？

341 ：デフォルトの名無しさん：05/01/12 10:41:28

>>340
そういうのは非機能要求だと解釈しているんですが、
そういったものはUMLを使わない別の文書に書くようにしています。
最初はユースケース記述書に備考として書いておくか、
フェーズが進んだらアーキテクチャ文書に書くかな。

全てUMLで書けるわけではないんですよ。

342 ：デフォルトの名無しさん：05/01/12 11:38:28

なるほど、ユースケース書きやすいですもんね。

ユースケースの派生を書いたりすることはありますか？
派生の概念の無い人が読めるんだろうか。

343 ：342：05/01/12 11:43:16

派生と言わずに、汎化と言うんだっけか？
意味同じだよね？

344 ：341：05/01/12 11:48:38

誤解させたようなので補足。
ユースケース記述書 != ユースケース図です。

ユースケース記述書は、このような文書です。
ユースケース図のように絵で構成されるものではありません。
ttp://www-6.ibm.com/jp/software/websphere/developer/practice/i/3_1_2.gif
もとはここ
ttp://www-6.ibm.com/jp/software/websphere/developer/practice/3.html
あとは、これかな？
ttp://www.mamezou.com/tec/design004.htm
書籍なら、ユースケース実践ガイドや実践UMLなどに詳しい書き方が載ってます。
ユースケース図だけで記述するのは無理なので、こういった文書が必要になる、と、私は理解しています。

345 ：342：05/01/12 11:52:26

>ユースケース実践ガイド
持ってます。

アクターの汎化例はありました。
ユースケースの汎化はしない方が良いのかなぁ。

346 ：342：05/01/12 11:57:57

良く見たらアクターが使うユースケースも汎化してますた。
書くのは簡単だとしても、読む人には難しそうだな。

347 ：U ◆CZtFsGiu0c ：05/01/12 12:34:42

>>344
>ユースケース図だけで記述するのは無理なので、こういった文書が必要になる、と、私は理解しています。

ユースケースに関しては、ユースケース記述の方が主役でユースケース図はなくても
それほど問題ではない。UMLにはユースケース図しかないので誤解されることも多い
けどね。

>>345
>ユースケースの汎化はしない方が良いのかなぁ。

わかりにくくなることが多いので、あまり使わない。アクターの汎化も正直どうでも
いい。そんなところに悩むのであれば、他のところに頭を使った方がいい。

348 ：デフォルトの名無しさん：05/01/12 13:27:15

納得しますた>>347
>わかりにくくなることが多いので、あまり使わない。
>そんなところに悩むのであれば、他のところに頭を使った方がいい。

349 ：デフォルトの名無しさん：05/01/12 14:20:38

>>399
>配置図でも伝達方法は書けないし、

HTTP という名前をインターフェースを作り、
サーバ（あるいはサーバ上の実行可能コンポーネント（apache等））
へ実現でつなぐ。
クライアントからは、そのインタフェースに利用でつなぐ。

350 ：デフォルトの名無しさん：05/01/12 14:39:44

ｦｫ、了解>>349

351 ：デフォルトの名無しさん：05/01/12 20:24:09

>>344にあるIBMのユースケースガイドと「実践UML」にあるユースケースはかなり違うな。
それだけ型にはめなくてもいいってことか。

352 ：デフォルトの名無しさん：05/01/13 16:28:15

ユースケース記述って結局、大部分アクティビティ図で済ましちゃうんだけど。
基本フローと代替フローを一つのアクティビティ図にして、
例外フローだけ別のアクティビティ図にするみたいな。

文章で書くと、分岐条件の表現が面倒というか、
変更があったときに、分岐先の番号書き直したりするのがすげえ面倒だし、
全体の流れが直感的につかめない。
あといちいち主語を書くのがかったるい「ユーザは」「システムは」みたいな。
アクティビティ図ならレーンを設定すれば、主語が省略できるし。

353 ：U ◆CZtFsGiu0c ：05/01/13 22:58:23

>>352
フローだけなら、そういうのもありかもしれないですね。後は事前・事後条件が
書ければ、ユースケース記述で重要な要素は大体記述できますね。

354 ：デフォルトの名無しさん：05/01/14 09:16:48

ユースケースだけでＯＫ？

ついでに配置図書いてみたけど、書くのは楽でも見た目ショボ杉。

355 ：デフォルトの名無しさん：05/01/14 15:10:27

>>354
どういうツールで描いたかしらんけど、EAとかだと、
イメージを変更する機能があるので、
PCにはPC、サーバにはサーバのイメージを設定すれば、
見た目、普通に描いたシステム構造図と変わらんよ。

356 ：デフォルトの名無しさん：05/01/14 16:05:34

>PCにはPC、サーバにはサーバのイメージを設定すれば、

そうそう、このことを言いたかったんだけど、イメージを差し替えても良いの？

357 ：デフォルトの名無しさん：05/01/14 17:34:18

>>356
UML 規約的には「？」（詳しい人コメントきぼん）
だけど、現実問題としては有用だよね。
自分は同じモデルの異なるビューだと認識してる。
提供先への説明用のビュー。
おそらく、XMI へもそのまま出るはずだし。
（つまり内部的には、正規のダイアグラムと等価な情報を持ってる。）
設定を変更すれば、すぐに正規の UMLの表現に戻せる。

問題は、正規のダイアグラムを使った場合は、
要素の形状の意味（ノードとかコンポーネント）とかが明確だけど、
独自アイコンの場合はそれが曖昧になるということ。
つまり、印刷してしまった場合は完全にUMLとしての意味は失われる。
（要素の画像から、要素の意味をたどれない）
パソコンの絵であればノードだ、とかいったルールは完全にローカルなものだから。

だから、開発資料としては、UMLで作るけれども、
説明用に、UMLからイメージを差し替えた絵を派生させる、
（派生においてはオリジナルは変更しない）
というのがもっとも妥当な考え方では。

358 ：デフォルトの名無しさん：05/01/14 18:22:01

規約なんてクソだ
お客様が神様です

359 ：デフォルトの名無しさん：05/01/15 15:09:44

「ワークフローの可視化ならUMLよりもBPMN」
ttp://www.atmarkit.co.jp/news/200501/15/bpmn.html

これってどうなんでつか？

360 ：デフォルトの名無しさん：05/01/15 15:37:48

>>359
まあ確かに、UMLというのはオブジェクト指向設計といった、
システムを作る側から出てきたもので、
使う側というか、経営とかそういう方向から見ると足りない部分もあるだろうけど・・・。

なら、それはそれで一つのダイアグラムとして定義して、
UML に組み込めばいいじゃん、と思うんだけど、
なんで独立した仕様にしなきゃいかんのかよくわからん。

たとえば、ツールでアクターとかオブジェクトの共有はできるんだろうか。
ユーザ側がコレで定義したビジネスプロセスを一旦紙にプリントしてもらって、
開発側では、それを分析して UML ツールにまた入力するなんてアホクサくてやってられんが・・・。

361 ：デフォルトの名無しさん：05/01/16 17:18:56

>>360
そこで変換ツールの出番ですよ。

362 ：デフォルトの名無しさん：05/01/17 11:01:38

>>361
いや既にUMLでお腹一杯、時間も一杯な現実もあるし。

363 ：デフォルトの名無しさん：05/01/17 15:07:18

BPMNって何？
エリクソン&ペンカーの拡張UMLみたいなもの？

364 ：デフォルトの名無しさん：05/01/17 15:12:48

リンク先ぐらい読めよ。

365 ：デフォルトの名無しさん：05/01/17 15:17:31

>>363
bmpの拡張だよ。
jpgやgifと同じようなもの。

366 ：デフォルトの名無しさん：05/01/20 20:57:11

なぜ止まる？

367 ：デフォルトの名無しさん：05/01/21 10:03:27

まあ、語れるだけの知識のある香具師がいないんでしょう。

368 ：デフォルトの名無しさん：05/01/22 16:51:13

OMGのファンダメンタル受かったので
インターメディエイトの対策をしようと
思うんだが、日本語の情報が少ない。

誰かＵＭＬ２ハンドブックだけで勉強して
受かった人いますか？

本にはActionとProfileについて書いてないけど
配点と合格ラインを見ると本の記述レベルが
試験のレベルに届いていればいけそうな気もするが
試験のレベルがわからないので不安

やっぱり英語の仕様書見ないとダメかな？

369 ：デフォルトの名無しさん：05/01/22 16:52:07

■の話ハ■板デ

370 ：368：05/01/22 17:07:31

>>369
スマソ、■板の存在を知らなかった

見つけたのでそっちに行きマツ

371 ：デフォルトの名無しさん：05/01/22 17:13:24

■って何？？

372 ：デフォルトの名無しさん：05/01/22 17:15:03

しかく

373 ：デフォルトの名無しさん：05/01/25 03:55:13

子連れ狼

374 ：デフォルトの名無しさん：05/01/25 03:58:47

子連れ狼

375 ：デフォルトの名無しさん：05/01/25 15:08:54

予蓮ね娘

376 ：デフォルトの名無しさん：05/01/26 02:36:38

矛蓮わ根

377 ：デフォルトの名無しさん：05/01/26 05:19:24

娘っ子連れ

378 ：デフォルトの名無しさん：05/01/26 12:01:13

子連れフランケン

ぷよぷよスレはここですか？

379 ：デフォルトの名無しさん：05/01/26 12:48:06

　　　　　　ちゃん　　　　　　　大五郎
拝一刀─────────────大五郎
　　　　　　1　　　　　　　　　　　　　　1

380 ：デフォルトの名無しさん：05/01/26 12:55:27

多重度の明記に、親子の絆の強さを感じます。

381 ：デフォルトの名無しさん：05/01/26 23:53:42

Executable UMLって物（概念？）を勉強してみようと思うんだが、
実用性とか浸透度って如何ほどの物なんでしょう？
ピントずれてたらすいません。

382 ：デフォルトの名無しさん：05/01/28 21:43:43

アクティビティー図ではループをどのように表現すればよいの
でしょうか。
フローチャートであった台形の図は無いようですし、がんばって
◇で表現するしかないのでしょうか。

ちょっと不便な気がしています。

383 ：デフォルトの名無しさん：05/01/29 10:29:09

制約でがんばってくれ

384 ：デフォルトの名無しさん：05/01/29 11:08:04

サブアクションにすればええんでないの。

385 ：デフォルトの名無しさん：05/01/30 20:21:10

UMLユーザー図ガイドP263をみると、◇でがんばれとかいて
あります。

>>383
アクティビティー図に制約ってかけるの？
weightのこと？

>>384
サブアクションってなに？

386 ：デフォルトの名無しさん：05/01/30 21:05:49

>>385
>サブアクションってなに？
すまん、「サブアクティビティ」だった。
別のアクティビティ図を、アクション中に一つのアクティビティとして埋め込むの。

詳細は、

OMG Unified Modeling Language Specification
March 2003 Version 1.5 formal/03-03-01
http://www.omg.org/cgi-bin/doc?formal/03-03-01

3.86 Subactivity state

を参照してください。

387 ：デフォルトの名無しさん：05/02/01 20:44:50

>>386
ありがとうございます。勉強になります。

388 ：デフォルトの名無しさん：05/02/14 23:53:38

分類子はインスタンスを持つ事のできる要素といいつつ、インターフェースも分類子のうちに含まれています。
インターフェースってインスタンス作れないですよね。
これはどう捉えたらいいのでしょうか。

389 ：388：05/02/15 00:25:08

すいません。
抽象分類子っていうのがありました。

390 ：デフォルトの名無しさん：05/03/15 11:04:45

オブジェクトの複製や生成ってどう表現してます？
自分の想像する限り、依存を使って、

　　　　　　　コピー
コピー元 ←・・・・・・コピー先

みたいになると思うんですが、コピー先から元に向かって矢印が
つくのが、感覚的にどうもしっくりきません。

391 ：デフォルトの名無しさん：05/03/15 11:20:30

　　　　　　　コピー
コピー元・・・・・・→ コピー先

でいいんじゃないか？

392 ：デフォルトの名無しさん：05/03/15 11:35:16

普通にシーケンス図でかくべ。

クラス図は静的だからそういうのは
関連にならんのじゃないかなあ。

393 ：デフォルトの名無しさん：05/03/15 11:39:25

クラスじゃなくてインスタンスのコピーだろうからなぁ

394 ：デフォルトの名無しさん：2005/04/05(火) 18:05:36

（集約でない）アソシエーションと集約の違いを
実装上で簡単に表現するにはどうすればいいですか。
javaかsmalltalkで例示してください。

395 ：U ◆CZtFsGiu0c ：2005/04/05(火) 18:54:25

>>394
コンポジションでない集約と関連を実装で区別する手段も必要もない。

396 ：デフォルトの名無しさん：2005/04/06(水) 14:48:08

>>392
でも、生成系のパターンを使ったクラス図を書こうとすると、
いるんじゃないの。
Factory や Builder のクラスと生成物の関係が、
シーケンス図みないとわからないってのはえらい面倒なような。

397 ：394：2005/04/06(水) 15:29:48

>>395
ということは、実装をベースに考えると、
合成集約とそれ以外の関連の２分法でいい、ということか。

関連を安易に集約で表現するといけないってどこかの本で
読んだのだが、実装上は違いないならしゃーないな。

398 ：U ◆CZtFsGiu0c ：2005/04/06(水) 18:20:17

>>397
コンポジションだって、厳密に実装する必要があるわけではない。
教科書どおりだと、全体に当たる側のオブジェクトは部分に当たるオブジェクトの
参照を外部にまったく渡さないか、あるいはコピーを作って渡すことになるけど、
そこまでやる必要があるかどうかは要件次第。

「関連を安易に集約で表現する」ってのはモデル上の話でしょ。それだって、
そもそも関連と集約を区別することを疑問視する人も多いので(ファウラーとか)、
そこまで気にする必要はないと思う。

399 ：デフォルトの名無しさん：2005/04/06(水) 23:08:08

そもそも図化って抽象化が目的なんじゃないの？
だとしたら、１つの図が２つ以上の意味を持つ事は避けられない事だし
何より、図中に含まれる情報量を増やして詳細化していくと、図化その
ものが無意味化してしまうのではないか？

400 ：デフォルトの名無しさん：2005/04/06(水) 23:18:04

要件を、実装にまで具体化する過程としてモデルがあって、
そのモデルを表現するために図があるんでないの？

401 ：デフォルトの名無しさん：2005/04/08(金) 20:44:25

OMG認定UML技術者資格試験とUMLモデリング技能認定試験
ってOMG認定の方が受験料高いけど有名って事でいいですか？
最低ランクレベルを取得する場合はどっちも難易度
似たようなものでしょうか？すんません教えてください。

402 ：デフォルトの名無しさん：2005/04/09(土) 16:04:53

似たようなものだ。つーかOCUPのほうが簡単。

403 ：デフォルトの名無しさん：2005/04/15(金) 16:44:45

シーケンス図で、自己呼び出しと外部呼出しで分岐って、
しちゃいけないんでしょうか。

404 ：デフォルトの名無しさん：2005/04/16(土) 00:42:04

age　ます。

405 ：デフォルトの名無しさん：2005/04/21(木) 04:28:07

DFDからクラス図に落とす方法の載せたHPとか方法そのものとか
誰か知りませんか？

406 ：U ◆CZtFsGiu0c ：2005/04/27(水) 12:30:24

>>405
そもそもDFDとクラス図は、自動的にマッピングできるようなものではないです。
＃動的なモデルと静的なモデルの違いもあるし
どういう理由でそういうことをしたいんですか?

407 ：デフォルトの名無しさん：2005/04/29(金) 19:57:28

>>405
そういう質問ができるってことは、
DFDもクラス図も読めないし書けない人なんでしょうね。

408 ：デフォルトの名無しさん：2005/05/11(水) 21:26:04

クラス図で一意制約を表現したくなった場合ってどうかくのかな？（note以外）
イメージするところは、RDBのユニークインデックスなんでございますが。

409 ：デフォルトの名無しさん：2005/05/11(水) 22:55:49

multiplicityの{unique}

exp.
Customer
purchase : Purchase [*] {ordered, unique}
account: Account [0..5] {unique}

410 ：デフォルトの名無しさん：2005/05/13(金) 22:44:36

UMLによるオブジェクト指向モデリングセルフレビューノートを買った奴いるか？
いたらレポートしてくれ、よろしくな

411 ：デフォルトの名無しさん：2005/05/13(金) 23:06:30

MSDNに付いてくるUMLツールないですか？

412 ：デフォルトの名無しさん：2005/05/13(金) 23:11:06

>>411
エンプラ版にVisio

413 ：デフォルトの名無しさん：2005/05/14(土) 01:03:45

414 ：デフォルトの名無しさん：2005/05/14(土) 08:30:02

>>412
ついてね－よ、ばーか

415 ：412：2005/05/14(土) 10:01:34

>>414
2002までだったのな。
ttp://www.microsoft.com/japan/msdn/subscriptions/prodinfo/levels.aspx#uni
ユニバーサルだと>411

416 ：デフォルトの名無しさん：2005/05/14(土) 10:37:47

あーサブスクリプションまでわかんないや。
来週会社で調べてくるわ。
ありが㌧。

417 ：デフォルトの名無しさん：2005/06/09(木) 04:01:19

単方向関連は分析レベルのクラス図で使っても良いのでしょうか？

418 ：デフォルトの名無しさん：2005/06/10(金) 00:20:47

なぜ、ダメだと思ったのか？

419 ：デフォルトの名無しさん：2005/06/10(金) 00:42:31

感覚的なもんだと思うんだけど
分析というより、設計を意識しているような気がしたから

420 ：デフォルトの名無しさん：2005/06/10(金) 01:17:59

漏れの場合、分析レベルで、
ロバストネス分類を頭で思いうかべ、
・関連の方向
・ロール名
・多重度
・主要なメンバ変数
・主要なメソッド
まで書いてます。
シナリオが全て満たされたら設計・実装に移るようにしてる。

# お客に見せても良いように、クラス名などは日本語のまま。
## 文句は言わせないが。

421 ：デフォルトの名無しさん：2005/06/10(金) 01:41:29

分析結果に対して文句言わせない？
すげぇな、俺には無理だ。

422 ：デフォルトの名無しさん：2005/06/10(金) 01:54:50

客が文句を言ってもいいのは、シナリオやユースケースだと思ってるだけ。
# RFP、ビジネスモデル、概念モデル、ドメインモデルも。

分析段階で文句言わせるとリスクが増える。
最悪、設計者・実装者をあそばせるようになる。
# 勘弁してくれ～。

423 ：デフォルトの名無しさん：2005/06/10(金) 10:32:54

実は「分析」という言葉が曲者のような気がする。

・ビジネスモデルを作るために業務を「分析」する。
・設計モデルを作るためにビジネスモデルを「分析」する。

はどちらも分析だけど、工程が違う。
なんかごっちゃになってるような。

424 ：421：2005/06/10(金) 10:48:33

>>423
ああそういうことですか。

いわゆる業務分析の事かと思ってました。
だから、強気だなーと。

425 ：デフォルトの名無しさん：2005/06/10(金) 12:06:14

ビジネスモデリング(業務分析)と
分析モデリングは随分違うよねぇ～。

後者は一応 UMLにも関連してるけど、
前者に統一的なノーテーションすらまだまだ
(BPMNみたいな実行できるビジネスモデルは分析の道具ではないし

426 ：デフォルトの名無しさん：2005/06/10(金) 12:53:51

「超上流工程」なんて言葉も言われることがあるよね。

しかし、そうすると、通常言われるところの「要件定義」って、ビジネスモデリングなしで、
いきなりシステムユースケースつくろうとしてるような気がするんだけど。
「ビジネスモデルを分析する」という作業を、結局、
「顧客へシステムの具体的な動作をどうするか質問してその答えを鵜呑みにする」
で済ませてる、みたいな。

こういうやり方だと、開発側で、システムの仕様と顧客業務との不整合なんて検証のしようがないよね。
「客があのときあれでいいといったからいいんだ」みたいな。

427 ：420：2005/06/10(金) 23:10:13

>>425
ＡＲＩＳとかあるけど、業務分析でも形(form)を変えたUMLで良いんでは？
対象がソフト・ハードから人間・組織になっただけかと。

>>426
それでも、システムの振る舞いがおかしいと、不整合に気づいちゃうんだよ orz。

普通、ビジネスモデリングはビジネスコンサルにでもやらせるんじゃないの？

428 ：デフォルトの名無しさん：2005/06/11(土) 07:11:24

>>420
おまぃはこれでも読んどけ
■BPMN関連：
　　@IT: BPMNを活用したビジネスプロセス・モデリング
　　(1）ビジネスを可視化するモデル記述言語「BPMN」　http://www.atmarkit.co.jp/farc/rensai/bpmn01/bpmn01.html
　　（2）「BPMN」の基本要素を理解する　　　　　　　　　　 http://www.atmarkit.co.jp/farc/rensai/bpmn02/bpmn02.html

　　【UMLじゃ】BPML【満足できない】　　　　　　　　　　　　 http://pc8.2ch.net/test/read.cgi/tech/1112008136/
　　・BPMLとBPMNの区別が付いていなかった恥ずかしい人のスレ

■ビジネス紺猿の研究にはまずこのあたり：
　　「戦略づくりの七つ道具―MBAビジネス実践マニュアル MBAビジネス実践マニュアル」
　　若林広二 (著) (2004/5) 中央経済社　　　　　　　　　http://www.amazon.co.jp/exec/obidos/ASIN/4502587907/
　　・ビジネスコンサルの七つ道具くらい勉強しとけ。ちなみに活動基準原価管理(ABC)の記述は弱かった気がする。

　　「コンサルタントになる人のはじめての業務分析」
　　窪田寛之 (著) (2004/07) ソフトバンクパブリッシング http://www.amazon.co.jp/exec/obidos/ASIN/4797324058/
　　・中身はUMLとコンポーネントモデリング手法を使った業務分析、という謎本

■より進んだ話題：
　　・現在の企業が取り組んでいる、企業情報システム構築方法についても勉強しとけ。

　　「かんたん!エンタープライズ・アーキテクチャ―UMLによる「業務と情報システムの最適化計画」の立案ビジネス図解シリーズ」
　　加藤正和 (著) (2004/08) 翔泳社　　　　　　　　　　　http://www.amazon.co.jp/exec/obidos/ASIN/4798107581/

　　エンタープライズサービスバス―ESBとSOAによる次世代アプリケーション統合
　　David A.Chappell (著), ソニックソフトウェア株式会社, 渡邉了介　http://www.amazon.co.jp/exec/obidos/ASIN/4873112206/

429 ：420：2005/06/11(土) 13:22:41

>>420
ありがとう。
ところで、ビジネスの論理ビューの文献はないかな？

# そろそろ、最後の2冊も買わないかんか...

430 ：デフォルトの名無しさん：2005/06/12(日) 00:31:22

あのさ、日本語か英語か、どっちかでしゃべれ。
おまえの脳内造語は痛すぎる

＞ビジネスの論理ビューの文献はないかな

431 ：デフォルトの名無しさん：2005/06/12(日) 00:57:00

>>427
>普通、ビジネスモデリングはビジネスコンサルにでもやらせるんじゃないの？

予算があればね。

でも実際問題、ユーザ側の意識が高くて、システム化以前に、
ビジネスプロセスリエンジニアリングとか業務シミュレーションのために、
コンサルやとって、モデルが作ってあって、
「このモデルのここんところをこう変えたいんですよ」
なんて都合の良い仕事なんて今のところあり得ないし、
システム化のためだけに、コンサルやとって業務分析させるなんて、
そうとう規模のでかいシステムでないとありえない。

432 ：デフォルトの名無しさん：2005/06/12(日) 01:07:24

話題を勝手にずらすな。

「ビジネスの論理ビュー」って何だよ？
ちゃんと説明しろ

433 ：デフォルトの名無しさん：2005/06/12(日) 01:08:47

>>432
引き篭もりバカの脳内単語だから相手にすんな。
どうせまた情けない説明をして叩かれまくる可哀想なヤシなんだから

434 ：デフォルトの名無しさん：2005/06/12(日) 01:32:12

http://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E3%81%AE%E8%AB%96%E7%90%86%E3%83%93%E3%83%A5%E3%83%BC&num=100
ビジネスの論理ビューに該当するページが見つかりませんでした。

検索のヒント
- キーワードに誤字・脱字がないか確かめてください。
- 違うキーワードを使ってみてください。
- より一般的な言葉を使ってみてください。

http://www.google.com/search?as_q=&num=100&hl=ja&c2coff=1&btnG=Google+%E6%A4%9C%E7%B4%A2&as_epq=Logical+view+of+Business&as_oq=&as_eq=rule+data+&lr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=
"Logical view of Business" -rule -data の検索結果 1 件中 1 - 1 件目 (0.33 秒)

OO, Modular, and related topics - [ このページを訳す BETA ]
... world. This is something that (to me) gets lost easily in "Implementation issues"
(both of compilers and applications). Modular (and structured) programming seems
(to me) to reflect a "logical" view of business (or whatever) issues. While OO ...
www.usenet-archive.de/comp.lang.cobol/ 40701-OO_Modular_and_related_topics_.php - 6k - 補足結果 - キャッシュ - 関連ページ

435 ：デフォルトの名無しさん：2005/06/12(日) 02:04:34

>>434
comp.lang.cobolに禿ﾜﾛｽ

436 ：431：2005/06/12(日) 02:42:15

>>432
俺は 420 じゃないぞ。
「ビジネスの論理ビュー」なんて知らん。

437 ：デフォルトの名無しさん：2005/06/12(日) 03:02:49

>>434
-rule, -data がミソだなｗ
　　Logical view of business rule
　　Logical view of business data
なら辛うじて28件ほどヒットするけど、
要するに手続きやデータ抜きで
Logical viewなんて言っても始まらないってこったｗ

まぁ、いまどきLogical viewがうんたら言い出すのは
レガシー入ってるヤシだと思うけど。
今ならUMLやEAのviewが旬

438 ：420：2005/06/12(日) 04:51:59

ごめん、
　Logical view of business -process
のつもりでした、吊ってきます。

439 ：デフォルトの名無しさん：2005/06/13(月) 12:57:32

現状のUML ツールで業務分析やろうとしてる（やってる）人はいませんか？
自分は、Eriksson-Penker 法でやろうとしてるんですが、
どうも訳本の評判が悪くて二の足を踏んでるんでます。

440 ：デフォルトの名無しさん：2005/06/13(月) 13:16:49

>>439
原著嫁

441 ：デフォルトの名無しさん：2005/06/13(月) 13:36:37

>>440
原著、訳書よりも高いんですよ。

442 ：デフォルトの名無しさん：2005/06/15(水) 13:04:03

>>441
何も読むな

443 ：デフォルトの名無しさん：2005/06/15(水) 13:15:04

なんか、人いないねぇ・・・

444 ：デフォルトの名無しさん：2005/06/15(水) 13:19:15

OCUPのインターメディエイトについて、
試験の難易度、対策本などの情報　知りたいとです。

445 ：デフォルトの名無しさん：2005/06/15(水) 21:10:20

質問です。

今度OCUP受験しようと思って勉強しています。
クラス図における関連とは関係と汎化関係にあるエレメントであって
関連が関係のインスタンスではないですよね？
今某e-ラーニングソフトの解説に思いっきり
関連は関係のインスタンスであると書いてあるのですが･･･
それとも自分が勉強した本が間違っているのでしょうか？
ちなみに本はソフトバンクから出版されているOCUP試験対策本です。

もうひとつ、ユースケースの表現で
ステレオタイプ<<usecase>>は標準で用意されていないのですか？
翔泳社から出版されている独習UML第3版には
ユースケースの表記にステレオタイプ<<usecase>>を用いたものもあったのですが
某e-ラーニングソフトの回答にはステレオタイプ<<usecase>>を用いた表記は
無いと書いてありました。どちらが正解なのでしょうか？

上記の質問はUML2.0の仕様でお願いします。

446 ：デフォルトの名無しさん：2005/06/15(水) 23:01:45

U・・・・うんこだいすき
M・・・・まじぎれさん
L・・・・るーずそっくす大好き

447 ：デフォルトの名無しさん：2005/06/16(木) 10:57:44

UMLモデリングのエッセンス第3版
http://www.amazon.co.jp/exec/obidos/ASIN/4798107956/

448 ：デフォルトの名無しさん：2005/06/16(木) 22:23:51

>>447
ｵｵ､(｀∀’)ｿﾚｲｲﾈ!

449 ：デフォルトの名無しさん：2005/06/16(木) 22:47:32

B5で良い本ない？

450 ：デフォルトの名無しさん：2005/06/17(金) 00:34:28

ここにもキチガイ

451 ：445：2005/06/19(日) 15:43:26

e-ラーニングのサポートセンターに質問した結果、以下の回答が得られました。

Q:
クラス図における関連とは関係と汎化関係にあるエレメントであって関連は関係のインスタンスではない？

A:
関連とは、インスタンス間につながりのある意味的な関係です。
関係は抽象的、関連は具体的と考えると分かりやすいでしょう。
関連→関連→集約→コンポジションという関係である。
また、コンポジションは推移的であり、関連の一種です。
関係はエレメント間になんらかの関係があることを意味する抽象概念です。
「関連は関係のインスタンスである」は非常に曖昧な表現であり、
誤りと解釈することも可能であり、正しいと解釈することもできます。

Q:
ステレオタイプ<<usecase>>を用いたユースケースの表記は無いのか？

A:
<<usecase>>は、標準ステレオタイプではなく、従って<<use case>>付きの
長方形が何を意味するかは、拡張を行った人間が定義する必要があります。

ちなみにOCUPファンダメンタル試験は得点率86%で合格することができました。
スレ汚しどうも失礼しました。

452 ：デフォルトの名無しさん：2005/06/19(日) 23:42:12

質問いいすか？
UMLの実装レベルのクラス図（C++）を書きたいんですが、コンストラクタとデストラクタって
どうすればいいんでしょう。ざっと参考書を見た感じでは、ステレオタイプで<<create>><<destroy>>を
付ける本、<<constructor>><<destructor>>を付ける本、何も付けずにそのまま書く本、
「コンストラクタは自明なので省略」という本があります。たぶん、どれでもいいような気がするのですが、
みなさん、どうしてます？

お願いしまっす。

453 ：デフォルトの名無しさん：2005/06/19(日) 23:47:33

>>452
UML資格試験には出ないので無視するﾖﾛｼ。
ついでにそんなことで上げないこと。

454 ：452：2005/06/21(火) 06:53:12

誰か教えてください。お願いします。

>>453
すみません。資格試験とは関係ないんです。お願いします。

455 ：デフォルトの名無しさん：2005/06/21(火) 07:04:39

>>452
ぶっちゃけ、ツールがどう扱うかの問題のような気がする。

・シーケンス図で、生成、削除のメッセージがどう扱われているか
　（ステレオタイプと別途プロパティが設定できる場合と、
　　デフォルトのステレオタイプが割り当てられる場合とかがある。）
・コード生成でどう指定すればコンストラクタを吐くのか。

このあたり、ツールの挙動にあわせて設定しないと使いにくくてしょうがないので、
UMLの仕様云々以前にツールの仕様にあわせることになるんでは。

456 ：デフォルトの名無しさん：2005/06/22(水) 00:19:36

漏れはコンストラクタは区別つけずに書いてるな。。

457 ：デフォルトの名無しさん：2005/06/29(水) 20:56:18

依存関係のステレオタイプの使い分け方が分りません
<<use>>
<<call>>
<<instance>>
<<derived>>
<<becomes>>

それぞれどういう場合に使うのでしょうか？
ご教授ください

458 ：デフォルトの名無しさん：2005/07/01(金) 02:42:17

「ユースケース入門」って本を読んでたらロバストネス図のオブジェクト間の線に
クラスの集約のような菱形マークが使われていた。
ロバトネス分析に集約ってアイディアはあるの？

459 ：458：2005/07/01(金) 02:43:43

○ロバストネス分析
×ロバトネス分析

orz

460 ：デフォルトの名無しさん：2005/07/01(金) 09:13:58

>>458
いわゆる「ロバストネス分析」（動的分析）では集約はでてこないはず。
ドメイン分析（静的分析）においては当然でてきます。

>ロバストネス分析に集約ってアイディアはあるの？

自分は、ロバストネス図というのは、MVCステレオタイプを設定したクラスによるクラス図で、
ロバストネス分析というのは、そのようなクラス図を動的分析に使おうというアイディア、
と理解してます。
つまり、「クラス図だけど、集約とか構造のことは忘れて MVC の関連で
ざっくりとシステムの振る舞いを分析しましょう」ということだと。

461 ：デフォルトの名無しさん：2005/07/01(金) 15:04:26

>>458
http://www.sparxsystems.jp/ea_diagrams2.htm
のページの下から2番目の図↓にそのものが紹介されてました。
http://www.sparxsystems.jp/images/p63.png
菱形マークは関係を表すもののようです。この図のコンテキストから
「サブミットボタン」は「債権トレード入力画面」の一部であると読み
取れそうです。

462 ：デフォルトの名無しさん：2005/07/08(金) 17:02:11

質問させて頂きます

ユースケース図でアクタを定義するとき
ユーザーと管理者を書いていたのですが
アクタが使用するシステムの権限ごとに定義したほうがいいのでしょうか？

463 ：デフォルトの名無しさん：2005/07/08(金) 23:38:35

>>462
不要

464 ：デフォルトの名無しさん：2005/07/09(土) 00:07:53

>>462
アクタ増やすんじゃなくて、ユースケースで対応したら？

465 ：デフォルトの名無しさん：2005/07/09(土) 09:04:24

>>463
不要なんですか・・・
アクタは役割ごとに定義すると思っていたので困惑しています

>>464
申し訳ございません，ユースケースで対応するということは
ユースケースは今のままでユースケース記述で分岐させるような
ことでしょうか？

466 ：デフォルトの名無しさん：2005/07/09(土) 12:10:22

もしユーザ、管理者という「ロール(役割)」以外にもっと細かいロールがあって、
それらが利害関係や権限について質的に大きく異なるならば、
アクタを追加した方が良いと思う。

アクタ追加の目的は
・ロールの職務範囲/責任範囲の明確化
・システムがロールに対して提供する機能の適切さの確認
は、荒っぽいロール区分では充分できないから。

ユーザと管理者については、ちょっと考えると下記のようなロールがありそう。

管理者
　├ 業務管理者 (承認したり、システム管理者に業務指示したりするひと)
　└ システム管理者
　　　├ 情報システム部門
　　　│　├ サーバ管理者
　　　│　└ DB管理者
　　　└ 現場情報システム担当 (現場部署固有の設定等)

ユーザ
　├ 業務ユーザ (業務上のの各種ロール)
　│　├ 在庫管理担当
　│　├ 経理担当
　│　├ カスタマーサービス担当
　│　└ 商品情報入力担当
　└ 一般ユーザ
　　　├ 特別会員
　　　├ 会員
　　　└ ゲスト

つか、業務ユーザと一般ユーザを一つのシステム上で扱うのは、
ちっちゃなWebサイトしかないような気もするけど

467 ：デフォルトの名無しさん：2005/07/09(土) 17:11:40

>>466
なるほど
もう一度アクタを追加するのがいいのか
検討してみようと思います

468 ：デフォルトの名無しさん：2005/07/13(水) 01:41:48

なんだかなあ・・・。

マインド・マップとUMLの連携術
ttp://www.atmarkit.co.jp/farc/rensai/mm02/mm02a.html

469 ：デフォルトの名無しさん：2005/07/13(水) 02:14:26

平鍋さんとこは、いつもネタが早いなぁ。
こっちはNLPから始めてるっつうに。
そういえばもう一つ新しく始めるというアレはどうなんだろう？

そろそろ「脳科学でOO」つうアレゲなネタでも立てて未踏に出してみるか（藁

470 ：デフォルトの名無しさん：2005/07/13(水) 02:21:20

農家学で本当に気合の入っている人は、
まず現実的な仕事でカネを稼いでから、
それで自前の研究所を建てるそうだ。

日米の技術者　夢の大きさに格差
　ttp://techon.nikkeibp.co.jp/article/TOPCOL_LEAF/20050408/103559/

471 ：デフォルトの名無しさん：2005/07/14(木) 10:57:06

初歩的な質問で申し訳ございません，アドバイスお願いします

次のような場合はクラスAからクラスBに対する関係は
UMLのクラス図ではどのように表現するのが妥当でしょうか？

class A{
int idB; //クラスBのインスタンスを一意判別するための変数，class Bのidが入る
}

class B{
int id;
string hoge;
}

集約？関連？依存？どれか分からずに困っています
よろしくお願いします

472 ：U ◆CZtFsGiu0c ：2005/07/14(木) 13:01:36

>>471
このスレッドでも何度も出てきたけど、そんな実装ベースの話だけで判断
できるものではないです。AとBはどのような関係にあるのですか?

473 ：デフォルトの名無しさん：2005/07/14(木) 13:33:40

>>472
申し訳ありません

Windowsのファイルとユーザー，ユーザーのファイルに対する権限のようなものを
イメージしています

私はこのときファイル，ユーザー，権限の三つをクラスとして考えて
これらの関係について考えているうちに分からない点が幾つか出てきました

まず権限にはファイルとユーザーを特定するための情報が
必要なので権限からファイルとユーザーに関連を引いていたのですが

実際にはファイルとユーザーを特定するidを持つだけなのでそのまま関連でいいのかが
分からなくなり質問させていただきました

あと，もう一点分からない点があります
このように権限を持つユーザーのみがファイルを操作できるということを表現するには
クラス図ではどのようにすればいいのでしょうか？

質問ばかりで本当に申し訳ございませんご教授ください．

474 ：U ◆CZtFsGiu0c ：2005/07/15(金) 10:01:47

>>473
そういうことであれば、権限クラスがファイルクラスとユーザークラスにそれぞれ
関連を持つ、ということでいいでしょう。おそらく権限クラスを関連クラスとして
定義することもできるでしょうが、あまり意味はないと思います。

>このように権限を持つユーザーのみがファイルを操作できるということを表現するには
クラス図ではどのようにすればいいのでしょうか？

UMLのダイアグラム表記だけで表現することを考えるとクラス図では無理でしょう
ね。シーケンス図で表現するか、メモをつけておくくらいでしょう。

475 ：デフォルトの名無しさん：2005/07/15(金) 15:16:59

>>474

メモを張っていくことにします
アドバイス有難うございました

476 ：黒：2005/07/15(金) 15:54:31

>>473
この場合をクラス図で表すと

ユーザー　←◇　権限　◇→　ファイル

となるんジャマイカ？
権限クラスがユーザーとファイルを知ってさえいれば良いし
ただユーザーかファイルどちらかが削除された時点で
権限オブジェクトも削除されるからコンポジションが良いのかもね
ユーザーとファイルが他のものからコンポジションの部分として共有されてると
だめなのか？わけワカメ

477 ：U ◆CZtFsGiu0c ：2005/07/15(金) 16:28:10

>>475
＠ITにも投稿しましたか? 問題が解決したのであれば、そっちも片付けといた
ほうがいいですよ。

>>476
コンポジションにはなりえないし、そもそも全体ー部分の関係でもないので
集約でもないですね。普通に関連でいいでしょう。

478 ：デフォルトの名無しさん：2005/07/16(土) 01:42:42

まあ、関連にとどめておくのが吉だと思うけど
(特に分析工程でこういうことにこだわるのは時間の無駄)
強いて言えば、

アカウント　←　権限　←◆　ファイル

権限はあきらかにファイルのライフサイクル下にあるので。
ちなみに

アカウント　＜+---+-- ユーザ
　　　　　　　　　+-- グループ

479 ：デフォルトの名無しさん：2005/07/21(木) 16:03:23

しかし、さあ、UMLを書く段階で、SEが「コンポジション」か「ただの関連」かって悩んでも、
実装時には、PGがまた実装方法で悩むわけでしょ。そうすると、「コンポジション」か「ただの関連」
かって悩むことにどれだけ意味があるんだろうか。

480 ：デフォルトの名無しさん：2005/07/21(木) 16:09:09

ここで聞いていいか微妙な話題かもしれないっすけど、
XMIからSVGに変換するようなXSLTファイルってどっかに落ちてないですかね？

481 ：U ◆CZtFsGiu0c ：2005/07/21(木) 16:22:08

>>480
こんなことやってる人たちがいる。実際に試してみて感想を教えてね:-)
http://uml2svg.sourceforge.net/

482 ：デフォルトの名無しさん：2005/07/21(木) 16:58:10

>>481
ありがとう、ちょっといってくる。

483 ：デフォルトの名無しさん：2005/07/21(木) 19:45:50

使ってみたけど・・何か微妙にズレる？
Inkscapeの方に原因あるんかな？

484 ：デフォルトの名無しさん：2005/08/24(水) 21:50:23

みなさんUMLソフトになに使ってますか？
1st Modeller使ってるんですがイマイチ使い勝手良くなくて、
judeは画面がおかしくなるため(javaのため？)使えないのですが、
やはりEnterprise Architect辺りを金払って使うのが一番ですか？

485 ：デフォルトの名無しさん：2005/08/24(水) 22:32:56

おまえらUMLのモデリングツール何つかってますか？
http://pc8.2ch.net/test/read.cgi/tech/1046441663/

486 ：デフォルトの名無しさん：2005/08/25(木) 00:00:54

>>485
すんません、誘導ありがとうございます。

487 ：デフォルトの名無しさん：2005/09/30(金) 11:12:22

誘導可能性ってなんなんですか。
本にいきなり説明もなしに出てきて困ってます｡
教えてください｡

488 ：デフォルトの名無しさん：2005/10/02(日) 23:58:21

>>487
関連の向き

489 ：デフォルトの名無しさん：2005/10/23(日) 10:46:52

おれならHaskellでスマートに書くけどねｗ

490 ：デフォルトの名無しさん：2005/10/25(火) 09:10:44

いや、別に UML で設計して Haskell で書いてもええんでは？

491 ：デフォルトの名無しさん：2005/11/02(水) 17:31:27

クラス図って、書く人の観点によってぜんぜん違う図ができたりしませんか？
特に後付けで作った後に納品物の１つとして書いちゃってる人なんて、
関連じゃなくて単なる実装レベルの参照も線で引いちゃってたりする人もいる。

492 ：デフォルトの名無しさん：2005/11/02(水) 22:27:57

>>491
なに？　クラス図とコードが一対一だと思ってるのか？
それとも静的な物である事を忘れてnewしてるから実現んでって奴なのか？？

493 ：デフォルトの名無しさん：2005/11/18(金) 10:55:31

>471
おい、なんでidでもつんだ。
クラスAのインスタンス変数はインスタンスBへの参照じゃねーの？

494 ：デフォルトの名無しさん：2005/11/18(金) 11:00:33

>479
設計段階でコンポジッションだったらdelete時にカスケードで子供のインスタンスも削除する、
ただの関連ならばカスケードデリートしないと言う風な一意性をもった実装時のガイドライン
を作成すれば、SEが悩むことに意味があり、PGが悩まないことになるんじゃない？

495 ：デフォルトの名無しさん：2005/11/18(金) 11:32:18

どういうガイドラインだったっけ？
と悩むPGが多いよなあ。

496 ：デフォルトの名無しさん：2005/11/18(金) 13:09:08

>495
わかるー。いまやってるやつも、シーケンス図で記載してある
ビジネスロジックの部分はちゃんとできてるけど、ガイドラインはほぼ無視。
テメーラ無能だから全部こっちでTaglibつくってやってんだろうが！
ちゃんと嫁やｺﾞﾙｧ

とは言えない・・・

497 ：デフォルトの名無しさん：2005/11/19(土) 10:59:14

そこでMDAですよ。
そこまでいかなくても、コードスケルトン出力時に、集約の種類によって、
ある程度扱いを変えることができる機能を持ってるツールは多いんじゃないの。

498 ：デフォルトの名無しさん：2005/11/21(月) 11:11:45

>497
今回うちのプロジェクトでは、hibernateをつかってクラス図からTopDownで実装し、
その中でコンポジッションの場合にcascade-delete出来るようmappingの設定を
おこなってみた。これだとソースにcascade-deleteのコードを書かなくていい感じ

499 ：デフォルトの名無しさん：2005/11/25(金) 13:18:57

最近UMLを勉強し始めたJavaプログラマです。
クラス図のところで躓いてしまいました。
質問は、「コンストラクタをクラス図にどう書くか？」です。
「書かなくてよい」という人がいますが、インスタンスの生成方法は重要ですから、
私は書きたいと思うのです。
すると、「コンストラクタはメソッドではないので書くべきではない」とも言うのです。
確かに、調べた数冊の書籍には、クラス図にコンストラクタが書いてありません。
そういうものなのでしょうか？
どなたか、よろしくお願いします。

500 ：デフォルトの名無しさん：2005/11/25(金) 16:31:10

>>499
UMLはただの情報伝達手段。
一般的か、そうでないかなんて、規約の範囲内であればどうでもいい。

フレームワーク的にどうしてもその実装が必要なら、コメントで釘をさしておいてもよし。
逆に言うなら、伝える情報は少ないほど、簡潔であるほど、伝わりやすい。

501 ：デフォルトの名無しさん：2005/11/25(金) 20:16:34

>>500
なんかそんな話ばっかりだよね。
で、結局、どうなのかわかんない。
で、普通、コンストラクタは書かないもんなの？どっちなんだよ。

502 ：デフォルトの名無しさん：2005/11/25(金) 20:52:27

>>501
クラス図をベースにベタ実装するなら書いてあっても不思議じゃないが、そんなことはPMか上司に聞けって。
ソースコードをそのまま日本語にしたような仕様書をやめる為のUMLだ。
実装者が「クラス図に書いてないから知りませんでした。」とかノタマウようなレベルならUMLを使うことが間違い。

503 ：デフォルトの名無しさん：2005/11/25(金) 21:57:52

>>502
クラス図なんか書かずにクラス書いちゃえば？って思うな。
UMLが何の役に立つか謎だよ。

504 ：デフォルトの名無しさん：2005/11/25(金) 23:04:27

たくさんのクラスがあったら、誰と誰が関連してて、誰がどんな機能を
持ってるのか1枚紙でざっと概略つかめたら楽チンでしょ。

505 ：デフォルトの名無しさん：2005/11/25(金) 23:59:05

>>504
なるほどね。
でも、実際にはそうはなんないよね。
MSの宣伝か何かで、やたら長いクラス図書いてるのあるよね。
あれ、確か、クラス名だけのような気がするが、あれに機能入れたら、ぞっとする。

506 ：デフォルトの名無しさん：2005/11/26(土) 03:53:59

手段と目的を取り違えてはいけない。
なんでも間でもクラス図に突っ込もうとする事は
なんでも間でもprivate宣言しやがる事位に
馬鹿な事だ。

507 ：デフォルトの名無しさん：2005/11/26(土) 14:53:50

むしろクラス間の関係が判りやすく記述されている事が重要
などと逝ってみるテスト

508 ：デフォルトの名無しさん：2005/11/26(土) 16:23:49

そこら辺は、実際に書いてみないと頃合い掴みにくいけどね。

実際、一枚に纏めるわけではなく、業務分析、基本設計、詳細設計、
PGからの逆起こしの各レベルで使ったり、詳細やPGのレベルでも
全体像用、パッケージ間関連用、詳細用と目的に応じて分けたりする
わけだし。
（納品物としてではなく、メンバの理解用の自作資料とか集めると自然にそうなる）

509 ：デフォルトの名無しさん：2005/11/26(土) 21:20:48

ま、設計なんてどんな方法使っても、実装を終えてから見直すと、陳腐に映るから不思議だw

510 ：デフォルトの名無しさん：2005/11/26(土) 21:28:41

あぁ確かになｗ

実装後に設計図の修正をしないケースなんてマズ無い品ｗっｗ

511 ：デフォルトの名無しさん：2005/11/26(土) 21:31:06

UML as Sketch

512 ：デフォルトの名無しさん：2005/11/26(土) 23:36:26

オオムネ賛成だが、
>なんでも間でもprivate宣言しやがる事位に馬鹿な事だ。
フィールドはなんでもかんでもprivateにしてください。おながいします。
例外もある？あーはいはい、あるでしょうね。
でも、そういうこと言う奴のコードでまともなの見（ｒｙ

513 ：デフォルトの名無しさん：2005/11/26(土) 23:53:08

なんでもかんでもプライベート宣言してくれてた方がまだマシなのでは？ｗ

514 ：デフォルトの名無しさん：2005/11/27(日) 02:41:23

なんでもかんでもpublicにしてくれと言ってる
クラスもどきの構造体使いなんです＞＜

515 ：デフォルトの名無しさん：2005/12/07(水) 00:38:55

日本語からシーケンス図を自動的に作るツールってありますか？

516 ：デフォルトの名無しさん：2005/12/07(水) 14:31:54

ttp://www.atmarkit.co.jp/fjava/devs/01fivemin/fivemin00.html

517 ：Omoti ◆rzOmotimAo ：2005/12/10(土) 08:06:15

http://www.net24.ne.jp/~omoti/central/6.png
だれかこれをUMLのユースケースにしてもらえませんか？

518 ：デフォルトの名無しさん：2005/12/10(土) 08:31:46

UMLのユースケース

519 ：デフォルトの名無しさん：2005/12/10(土) 09:40:40

>>517
warota

520 ：デフォルトの名無しさん：2005/12/10(土) 19:08:28

http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-list/41416?41372-41617

521 ：デフォルトの名無しさん：2005/12/10(土) 19:19:18

ユースケースにしたら、今度は「プログラムにしてくれませんか？」とか言ってくる罠。

522 ：デフォルトの名無しさん：2005/12/10(土) 19:28:26

アクターがかわいくない！もっと萌え～なシンボルにすべき！

523 ：デフォルトの名無しさん：2005/12/10(土) 19:29:59

そんなことしたら・・・・

会社で使えないだろ。
客先のプレゼンで使えないだろ。

524 ：デフォルトの名無しさん：2005/12/10(土) 19:43:04

>>517
お前最悪だな。
http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-list/40974?40971-41184

525 ：デフォルトの名無しさん：2005/12/10(土) 20:06:52

>>523
OMGに認めさせて公式なものにすればいいんじゃね？

526 ：デフォルトの名無しさん：2005/12/10(土) 23:48:26

>>523
あんな子供の絵みたいなアクターの方が恥ずかしいって

527 ：Omoti ◆rzOmotimAo ：2005/12/12(月) 08:32:08

http://www.net24.ne.jp/~omoti/central/14.png
ユースケース書いてみた
オレ様が本で独学した限りでは、この書き方で
間違ってないはずだが、どうだろう？

528 ：デフォルトの名無しさん：2005/12/12(月) 21:32:23

Omoti ｷﾀ━━━━(゜∀゜)━━━━！

529 ：デフォルトの名無しさん：2005/12/12(月) 23:00:36

>>527
配色センスが間違っている

530 ：デフォルトの名無しさん：2005/12/13(火) 23:11:06

ユースケースの中にアクターがいる

531 ：デフォルトの名無しさん：2005/12/13(火) 23:19:03

政府の王様

532 ：デフォルトの名無しさん：2005/12/13(火) 23:44:36

>>530
それワーカだよ。

533 ：デフォルトの名無しさん：2005/12/15(木) 01:01:21

Omoti氏ね！

534 ：デフォルトの名無しさん：2005/12/15(木) 01:06:42

>>527
その根拠のない自信はどこから来るんだ？

535 ：デフォルトの名無しさん：2005/12/20(火) 23:30:03

Omoti = バカ

536 ：デフォルトの名無しさん：2005/12/24(土) 12:15:09

UMLの構成図って表現力が不足していて使えないけど、
みんなは構成図ってどんなの書いてるの？

537 ：デフォルトの名無しさん：2005/12/24(土) 12:32:48

UMLに構成図なんかあったっけ？

538 ：536：2005/12/24(土) 12:54:27

>>537
あっごめん。配置図だった

539 ：デフォルトの名無しさん：2005/12/24(土) 13:03:47

「オブジェクト指向で開発する！」
とハリきってスタートしたプロジェクト・・・

最初にUMLの設計書をそれなりに書いても、
結局、プロジェクトの最後の方では、従来の設計書しか
使わなくなって、UMLの設計書は誰も見なくなったゴミ設計書
になるよ・・・

そんなプロジェクトばっかり経験・・・

540 ：デフォルトの名無しさん：2005/12/24(土) 13:29:07

>>538
配置図か。そんなものは使わない。
普通にネットワーク構成図の方が優れているので、淘汰されて当たり前。
UMLの評価すべき点は、記法の統一性だけだから、
それがあまり重要でない局面ではUMLにこだわる必要はない。

541 ：デフォルトの名無しさん：2005/12/25(日) 04:14:13

ユースケース・サンタマリア

542 ：デフォルトの名無しさん：2005/12/25(日) 05:19:10

>>539
UMLなのに仕様書エディタはWord, Excel。
UMLなのに実装がCライク、コボルライク。
UMLなのにクラス分割が微妙で、アクセス
属性は、なんでもかんでもprivate。

そんなプロジェクトだった？

543 ：デフォルトの名無しさん：2005/12/25(日) 12:22:33

>>542
もしかして、同じプロジェクトに居た？

544 ：デフォルトの名無しさん：2005/12/25(日) 13:01:44

ﾋﾟﾋﾟﾋﾟｯ
>>542-543特定ｽﾏｽﾀw

545 ：デフォルトの名無しさん：2005/12/25(日) 15:28:50

>>542
>属性は、なんでもかんでもprivate。

なんでもかんでもpublicよりいいジャマイカｗ

546 ：デフォルトの名無しさん：2005/12/26(月) 01:42:07

>>545
昨日ゲーム板でみたのだが、

反省だけなら猿でも出来る、
揚げ足取りなら馬鹿でも出来る

のだ、そうだ。

まあ、protectedの存在も知らない癖に
ここに来ている様な奴に言っても無駄だろうが。

547 ：デフォルトの名無しさん：2005/12/26(月) 01:43:49

>>543
いや、お約束のパターンなので(w
仕様書絡みの面では、特に最初のは地獄かと。

548 ：デフォルトの名無しさん：2005/12/26(月) 02:49:44

>>546
ほうジョークで慰めたつもりだったんだが、
揚げ足取りだと取られて過剰反応されてしまったな。
まぁいいや、ゲームの方もがんばれよｗ

549 ：デフォルトの名無しさん：2005/12/30(金) 16:25:38

それよりアクセス属性がみなprivateでどうやって動くんだろうと思ったが。
それとも、フィールドの話？ならなんでもかんでもprivateだろ、普通。

550 ：デフォルトの名無しさん：2005/12/30(金) 17:01:31

所詮UMLの低脳の集まりか

551 ：デフォルトの名無しさん：2005/12/30(金) 17:02:17

所詮UMLも低脳の集まりかだ

くそあおり損ねた
逃げよ♪

552 ：デフォルトの名無しさん：2005/12/31(土) 08:28:42

お前ら541が今年最高のダジャレを言ってるんだぞ。ちゃんと注目しろ

553 ：デフォルトの名無しさん：2005/12/31(土) 16:43:29

今年最後の自演乙であります

554 ：デフォルトの名無しさん：2005/12/31(土) 20:02:17

スレを見た感じ今からUMLはやらん方が良いんかな？

555 ：デフォルトの名無しさん：2005/12/31(土) 20:05:20

>>554
逆だ。やったほうがいい。
別にＵＭＬにこだわる必要はないけど、表現方法を広げるって意味では有効
最近は特に図解がブームだし

556 ：デフォルトの名無しさん：2005/12/31(土) 21:09:29

一人で数千行程度のプログラムを書くのに、
UMLを使う価値はある？

557 ：デフォルトの名無しさん：2005/12/31(土) 22:22:39

門外不出の一子相伝のプログラムなら不要。
というか、文章に残すな！口伝だ口伝！

558 ：デフォルトの名無しさん：2006/01/01(日) 12:59:48

>>555さん
私も少しやってみようと思います。

559 ：デフォルトの名無しさん：2006/01/04(水) 23:45:29

>>556
漏れも独りだが
2ヵ月後にソース追いかける気無くなりました

やっぱ、UML価値あるのでは？

560 ：デフォルトの名無しさん：2006/01/04(水) 23:57:57

そう言う人は、UML以前からいたけど、しっかりした構想が出来上がってるはずだよ。

561 ：デフォルトの名無しさん：2006/01/05(木) 20:38:35

コンポーネント図と配置図なんですが、
まったく理解できません。
解説していただけないでしょうか

562 ：デフォルトの名無しさん：2006/01/06(金) 00:18:43

>>561
それ、使わねえから理解する必要ないよ

563 ：デフォルトの名無しさん：2006/01/06(金) 16:03:49

Makefile とか build.xml とかを吐くツールとか出れば、
もう少し使われるようになると思うんだがなぁ。

564 ：デフォルトの名無しさん：2006/01/10(火) 01:48:06

YMOとUMLだったらどっちが難しいですか？

565 ：デフォルトの名無しさん：2006/01/10(火) 16:11:00

UML2.0とeclipsの組み合わせで使ってる人いる？
どんな感じですか。作業効率あがんのかな。

566 ：デフォルトの名無しさん：2006/01/24(火) 02:07:28

>>564
YMCAのほうが難しいよ

567 ：デフォルトの名無しさん：2006/01/24(火) 02:11:24

数千行程度ならUMLいらないと思う。
でも、おいこみかけたい時や、詰めたい時
UMLあると短時間で片付くことが多いよ。

568 ：デフォルトの名無しさん：2006/01/25(水) 22:02:08

YMCM

569 ：デフォルトの名無しさん：2006/01/28(土) 22:26:56

ローカル変数の記述ってUMLでは考慮しないの？

570 ：デフォルトの名無しさん：2006/01/29(日) 08:07:51

UMLはモデル言語で、アルゴリズム言語じゃないしな。

571 ：デフォルトの名無しさん：2006/01/29(日) 08:13:39

なるほど。もっかい出直してきます。

572 ：デフォルトの名無しさん：2006/02/26(日) 01:57:22

>>570
アルゴリズム記述できないのにどうやってMDAをやる気なんだろうと
思わないか？

573 ：デフォルトの名無しさん：2006/02/26(日) 02:03:47

え？
普通にコード書き込めるけど？

574 ：デフォルトの名無しさん：2006/02/26(日) 02:11:05

アルゴリズム言語を見てピタゴラスイッチを思い浮かべた香具師、挙手

575 ：デフォルトの名無しさん：2006/02/26(日) 02:16:23

アルゴリズム体操を見て、アルゴリズムについての一般人との概念の違いを思い知らされた。

576 ：デフォルトの名無しさん：2006/02/26(日) 03:41:59

>>575
あれは正直唖然とした・・・

577 ：デフォルトの名無しさん：2006/02/27(月) 07:28:04

ﾜﾗﾀ
http://sidhes.hp.infoseek.co.jp/alg3.htm
どこがアルゴリズムなんだと

578 ：デフォルトの名無しさん：2006/02/27(月) 09:53:39

＞577
どこがって？

教えてあげないよ、ジャン

ってところでしょう。まあ佐藤雅彦のやる事だから・・・

579 ：デフォルトの名無しさん：2006/02/27(月) 23:01:46

ライフゲームのグライダーとか近いのかな？

580 ：デフォルトの名無しさん：2006/03/01(水) 02:58:47

>>573
おいおい、コード書いちゃったらMDAの意味無いじゃん。
だいたい今はアルゴリズムを記述する共通規格ないだろ？

581 ：デフォルトの名無しさん：2006/03/04(土) 13:02:39

MDAが解決しようとしている問題は、
「アルゴリズム」じゃなくて、
「アルゴリズムの使い方」じゃないの。

アルゴリズムの実装、特に手続き部分は
自体は従来どおりのやり方であるしかない。

そこで、パッケージライブラリなりフレームワークなりを作って、
それを使うためのオブジェクトモデルを用意して、
アプリケーションのデータモデルに、
アルゴリズムのオブジェクトモデルのロールを割り当てれば、
そのアルゴリズムをパッケージやフレームワークの細かい
使い方を知らなくても、実装コード（の一部とスケルトン）が
でてくる、みたいな話じゃないの。

582 ：：2006/03/13(月) 14:23:02

UMLのクラス図で○のなかに+がある記号がクラスの関連のやじるしの所にでてきてるんだけど、どういう意味なんですか？

583 ：デフォルトの名無しさん：2006/03/13(月) 18:53:23

>582
ぜんぜんわからんがとりあえず発言
関連の設定でpublicをprivateにした結果、○のなかがマイナスになるようなら、そういういみじゃないの？
ちなみにあっしの今まで使ってたツールは+の外に○はなかった気がスルガ。

584 ：デフォルトの名無しさん：2006/03/13(月) 20:11:10

>>582

ネスト？

585 ：デフォルトの名無しさん：2006/03/13(月) 22:16:19

いまjudeでjavaのソースからクラス図作ろうとしたんだけど、
なにこれ！？パッケージ違うと同じ図に入れられないジャン。
つかえねー！

586 ：デフォルトの名無しさん：2006/03/14(火) 02:04:09

アクティビティ図で無限ループを含む場合の
記述サンプルってないですか
スレッドかプロセス起して無限ループさせて
イベント待つような図を書きたいけどわからない

587 ：デフォルトの名無しさん：2006/03/14(火) 10:56:08

>586
なぜアクティビティ図で？
スレッドというオブジェクトのライフサイクルとかが絡む話だったら
シーケンス図つかえばいーじゃん。
んでもってloopフラグメントつかえばいーじゃん。

ついでに
どのオブジェクトがスレッドを生成するのかとかそんな情報も、
アクティビティ図だと自然文で記載することに多分なっちゃうよね。
シーケンス図だとそんなんも図になるしいーんじゃない？

アクティビティ図なんて業務フローのときだけおせわになればいーじゃん。

588 ：デフォルトの名無しさん：2006/03/14(火) 10:59:08

>585
自動生成したクラス図に、別のパッケージのクラス図を構造ツリーから
ドラッグ&ドロップすればいいんじゃねーの？

つかえるー

589 ：http://www.vector.co.jp/soft/win95/util/se072729.html：2006/03/18(土) 20:36:58

TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

590 ：デフォルトの名無しさん：2006/03/20(月) 13:33:05

>589
あちこちにマルチ乙

591 ：デフォルトの名無しさん：2006/04/08(土) 12:57:33

おいら分析する時に、汎化から特化って考えかたするのね。
とりあえずざっくり、把握してから、特化していく感じ。

なのにUMLは、汎化方向に←付けるんだよね。
俺の感覚だと、特化←なんだよ。
どうにかしてくれよ。腹立つ。

うんこだよ。

592 ：デフォルトの名無しさん：2006/04/08(土) 17:06:16

>>591
感覚的には分かる。そういうツールばかりだからな。
操作については我慢するしかないんじゃないか。
ツールの設定で変えられればいいのにね。

593 ：デフォルトの名無しさん：2006/04/08(土) 17:09:35

ツールの設定で表記法を変えちゃだめだろう

俺も親 ← 子の矢印の向きには違和感あった。
実装の感覚からいうと。

でも分析の場合って確かに向きとしては「汎化」なんだよね。
お客さんからのヒアリングで最初から抽象化なんか出来る訳ないし。

594 ：デフォルトの名無しさん：2006/04/08(土) 17:21:35

>>593
うるせーばか、こちとら経験豊富なクソプログラマーなんだから、
汎化構造から、特化の方へ思考するんだよ。

>>592
UMLは、産業界全体で使う表記法なので、変更しちゃ駄目。

595 ：デフォルトの名無しさん：2006/04/08(土) 17:26:26

>>591
俺もそうなので気持ちは分かるが諦めれ。
結城本だったか、
子は誰が親なのか知っているが、親は子の事を知らん。
なので、知ってる方向(子から親の方向)に矢印を書く、つーのを見て、それもありなのかなとｵﾓﾀ。

596 ：デフォルトの名無しさん：2006/04/08(土) 18:17:32

>>593
何か誤解があるようだけど、表記法を変えるんじゃなくて
継承関係を描く時、子クラスから親クラスへマウスを操作するという
操作を逆にするということ。

597 ：デフォルトの名無しさん：2006/04/08(土) 18:23:43

あの三角は末広がりということで、、、、。
ここはOMTの表記のほうが優れてたな。

598 ：593：2006/04/09(日) 00:39:38

>>594
ばかってゆったら自分がばか！

いやいや俺もクソプログラマーだから
汎化から特化の方が直感的でいいよ。
最後の2行はあきらめというかまあそんな感じです。

>>596
てなわけで最初に誤解したのは592って事ですね。

599 ：デフォルトの名無しさん：2006/04/09(日) 01:35:51

UMLの矢印は依存関係を表してるんだろ？
一目でそれが分かるのが利点なのに逆がいいなんて訳わからん
継承や実現だけ逆向きにするなんて気持ち悪い

600 ：デフォルトの名無しさん：2006/04/09(日) 15:19:50

>>599
矢印使ってる事が問題なんだよな
矢印は流のイメージが有るし、アクティビティー図等その他の
図表では流れを表現してるんだから

601 ：デフォルトの名無しさん：2006/04/10(月) 02:21:37

クラス図とアクティビテイー図とごっちゃに書いてる奴は誰だ？

602 ：デフォルトの名無しさん：2006/04/15(土) 23:48:42

悪いな
スタビライザー図を書いたんだよ

603 ：デフォルトの名無しさん：2006/04/19(水) 23:50:56

UMLをこれから勉強します。
良いサイトがありましたら教えて下さい。
演習があればなおいいのですが・・・
とりあえず、ここを見つけました。
http://www.ogis-ri.co.jp/otc/hiroba/technical/Jouhoushori-UML/

604 ：デフォルトの名無しさん：2006/04/20(木) 00:09:06

>>603
ageてみます。よろしくおながい。

605 ：デフォルトの名無しさん：2006/04/23(日) 22:44:59

UMLのいろいろな図の書き方とか本読めば分かるが、
UMLの図を書いただけじゃぁ、設計にならんよな？

画面レイアウトとかの画面の設計とか、データベースの
テーブル設計書とか、いつどのタイミンフで書けばいいのだ？

オブジェクト指向で開発すると、UMLだけで、そう言ったものは
書かずに開発するのか？

606 ：デフォルトの名無しさん：2006/04/23(日) 23:33:48

>>605
UMLは所詮外部設計しかできねえよ、詳細設計になったら書けば？

607 ：デフォルトの名無しさん：2006/04/24(月) 11:17:52

>606
チミはUMLで外部設計しかしてないのか？
チミは画面レイアウトを詳細設計フェーズで決めるのか？

ワシはUMLで要件定義、基本設計、詳細設計やるぞ
ワシは画面レイアウトは基本設計でやるぞ
ワシは画面設計（基本設計レベル、ユーザとの界面の仕様と解釈されたし）は基本設計でやるぞ
画面設計の詳細設計レベルは詳細設計でやるし。
ワシはテーブル定義は詳細設計でやるぞ。基本設計はクラス図でエンティティ定義してるから。

608 ：デフォルトの名無しさん：2006/04/24(月) 12:29:25

>>607
お客さんに恵まれている例

609 ：デフォルトの名無しさん：2006/04/25(火) 09:13:34

>608
まあ、そういう話もあるが、結局言いたいのは、画面設計は
いままでみんながやってたタイミングでOKということと、
UMLは詳細設計にだってつかえるじゃろがボケェ
ということだ。　

610 ：デフォルトの名無しさん：2006/05/10(水) 02:33:51

UML Superstructure Specification, v2.0, formal/05-07-04を見てるんですけど
P158 Figure9.1で
StructuredActivities<---merge---StructuredActivities
ってなってるんですが，これって間違いですかね？

611 ：デフォルトの名無しさん：2006/05/10(水) 04:25:58

>>610
それらは、それぞれActivity::StruecuredActivitiesとCompositeStructure::StructuredActivitiesだから、間違ってない。
と、思う。

612 ：デフォルトの名無しさん：2006/05/10(水) 04:28:39

>>610
ちょっと間違えた。
正しくはActivities::StructuredActivitiesとCompositeStruectures::StruecturedActivities。

613 ：デフォルトの名無しさん：2006/05/10(水) 04:42:17

矢印が逆だと感じる人は、
「A depends on B」が「A→B」の形になったわけなので、
「これはもともとは英語なんだ」と強引に納得するしかない。

614 ：610：2006/05/10(水) 05:06:44

そういうことですかー。
ありがとうございました。感激

615 ：デフォルトの名無しさん：2006/05/10(水) 05:10:59

>>614
ちなみに、その<<merge>>はただの<<merge>>ではなく、merge incrementalってやつ。

616 ：610：2006/05/10(水) 05:33:20

ようやく眠れると思ったら，もう会社の時間・・・zzz

617 ：デフォルトの名無しさん：2006/05/14(日) 22:19:54

なにか良い本がないかと思ってこのスレに来てみたけど、何だか自分が
色々と勘違いしてるかもしれない事に気が付いた・・・

C++とオブジェクト指向の勉強を初め、プログラムを書きながら実践してる所なんだけど
規模が大きいのものを書こうとすると頭の中で考えがまとまらないので
補助ツールみたいな心づもりでUMLに手を出してた

どっこいオブジェクト指向言語とはまた別物なのか

618 ：デフォルトの名無しさん：2006/05/16(火) 09:30:24

２ちゃん内UML相互リンク

おまえらUMLのモデリングツール何使ってますか?２
http://pc8.2ch.net/test/read.cgi/tech/1147499933/

おまえらUMLのモデリングツール何つかってますか？
http://pc8.2ch.net/test/read.cgi/tech/1046441663/

UML皆でお勉強しよ♪ ３項関連
http://pc8.2ch.net/test/read.cgi/tech/1076446411/

【受験料】　UML技術者認定試験　【無料】
http://school5.2ch.net/test/read.cgi/lic/1051073081/

UML技術者資格試験【OCUP,UMTP】
http://pc8.2ch.net/test/read.cgi/prog/1115543652/

＿＿ＵＭＬロボット＿＿
http://that4.2ch.net/test/read.cgi/robot/1047690048/

619 ：デフォルトの名無しさん：2006/05/17(水) 19:57:45

JUDE使ってるんですが、Delphiのプロパティってどこに書くのが適切なんでしょう。
属性欄？操作欄？
Delphiのモデルビューだともう一つ、プロパティ欄があるんだよなー。
まあ、プロパティだって属性欄で言いか

620 ：デフォルトの名無しさん：2006/05/17(水) 20:39:45

>>619

素直にEA使うべし

621 ：デフォルトの名無しさん：2006/05/17(水) 20:52:35

エレクトロニック・アーツ

622 ：デフォルトの名無しさん：2006/05/18(木) 00:49:54

今ちょうどアリスやってんだけどジャバウォック強すぎ

623 ：デフォルトの名無しさん：2006/05/18(木) 15:08:28

シーケンス図でたとえば
actor i1 i2 i3
とライフラインのインスタンスが並んでいるとして
actorからi3に直接操作が引かれるのはまずい設計なんでしょか？

actorからはi1しか操作しない、というのがよさげな気が
するのですが、この場合引き数を受け渡すだけの
操作ができてしまい、効率的でないし。。。

624 ：デフォルトの名無しさん：2006/05/20(土) 18:00:09

>>623
貧乏性だな。

625 ：デフォルトの名無しさん：2006/05/22(月) 12:16:26

>>623
インスタンスの役割によるんじゃない？

シーケンス図で、ライフラインと操作の線との交差が少ないというのが、
即ち、読みやすいから良い設計、ということばかりではないと思うけど。

なんとなく、ｇｏｔｏは必要か否か、というのと問題の根底にあるのは
似ているような気がする。

626 ：デフォルトの名無しさん：2006/05/28(日) 15:42:19

正直、webアプリケーションの場合、
どんなクラス図やシーケンス図を書いたらいいかワカラン。

ブラウザで見る1画面が1つのバウンダリクラスになるのか？
なんか実装のイメージに沿う形にどう考えてももっていけない。

今まで通りの「ここの画面のここのボタン押したら、こう言う処理をします・・・」
みたいな設計書を書くかな・・・

627 ：デフォルトの名無しさん：2006/05/28(日) 15:54:34

>>626
シーケンス図って、コンピューター同士のメッセージのやり取りを書くものだよ。
クラス図もな。

てか、オブジェクト指向ってのが根本から理解出来てないんじゃないの？

628 ：デフォルトの名無しさん：2006/05/28(日) 15:55:36

実装考える時点で負け

629 ：デフォルトの名無しさん：2006/05/29(月) 00:16:10

>>627
コンピューター同士か。
いや、ちがうだろ。

630 ：デフォルトの名無しさん：2006/05/29(月) 00:26:40

>>629
オブジェクト同士と似たようなもんだろｗ

631 ：デフォルトの名無しさん：2006/05/29(月) 00:28:30

むしろコンピューター間のプロトコルを記述した図からヒントを得ているんだろ？　シーケンス図。

632 ：デフォルトの名無しさん：2006/05/29(月) 00:29:59

ヒントの話じゃないと思う

633 ：デフォルトの名無しさん：2006/05/29(月) 00:33:02

そもそもオブジェクトが物理的に同じコンピュータ上にあるかどうかなんて、関係ないんだがな。

634 ：デフォルトの名無しさん：2006/05/29(月) 00:37:39

まあ、まずはオブジェクト指向から皆でお勉強しようやｗ

635 ：U ◆CZtFsGiu0c ：2006/05/30(火) 14:19:56

>>626
どういうレベルのシーケンス図を書こうとしていますか?
実装レベルで、たとえばJ2EEであれば、まずアクタ(ブラウザorユーザ)から
サーブレットがリクエストを受け取り、その後内部でごちゃごちゃ処理し、
JSPにフォワードして、そのJSPからアクタにレスポンス返して終了、という
形になると思います。

ロバストネズ図を描こうとしているのであれば、そもそもWebアプリかどうか
は関係ないですね。

636 ：デフォルトの名無しさん：2006/06/03(土) 18:55:32

>>627
↑こいつ無脳

637 ：デフォルトの名無しさん：2006/06/03(土) 20:45:01

いや、あまりに切れ味が見事すぎて、釣りの可能性もあるけどな
ま、もうどうでもいいよ

638 ：デフォルトの名無しさん：2006/06/04(日) 03:29:26

シーケンス図って、クラス間のメッセージ交換の図を便宜上関数コールとして使ってるだけだけどね。
別にシングルコアのCPU上にJavaで作る言語に特化した物でもないよ。
OSとか、ハードウェアアーキティクチャが変われば、CPU間のメッセージ交換と言う見方も出来るだけの話。

639 ：デフォルトの名無しさん：2006/06/04(日) 03:50:09

１オブジェクト＝1CPUコア

640 ：デフォルトの名無しさん：2006/06/04(日) 09:54:13

釣れますか？

641 ：デフォルトの名無しさん：2006/06/04(日) 10:08:13

UMLの実例を見たいんだけど、いいサイトか本はないですか

642 ：デフォルトの名無しさん：2006/06/04(日) 11:20:21

事典類はやめとけ。表記方法に捕われすぎてワケわからん事になる。
ソースから図を起こす時とか、陥りやすい罠だ。

643 ：デフォルトの名無しさん：2006/06/04(日) 12:25:04

>>640
釣りじゃねえｗ
真実だｗ

644 ：デフォルトの名無しさん：2006/06/04(日) 14:59:28

机上の空論

645 ：デフォルトの名無しさん：2006/06/04(日) 17:28:09

UML自体が机上の空論な訳だが？

646 ：デフォルトの名無しさん：2006/06/05(月) 23:56:15

3つ質問があります

1 業務プロセスをUMLで記述しようとする場合は
アクティビティ図、シーケンス図あたりが適当でしょうか？
アクティビティ図では、複数のレーンでコラボレーションするようなアクティビティは
どのように表現すれば良いでしょう？

2 クラスを見つける方法として自分が買った本には
ユースケース記述にシナリオを書いて、名詞に着目して
オブジェクト(クラス)を見つけるとありました。
あと、自分ではIDEF0やDFDでデータに着目した図を書いて
データをクラスにするのが良いかな～と考えています。
コントロール、バウンダリ、エンティティなどがあると思いますが、
クラスを見つける方法を知りたいです。

3 クラス図で、依存、集約、コンポジションはソースコードでは
片方のクラスからもう片方への参照という形になるのでしょうか？

647 ：デフォルトの名無しさん：2006/06/10(土) 00:17:12

>>646
>1 業務プロセスをUMLで記述しようとする場合は・・・
　今、UMTP-L2の勉強をしていますが、受験参考書では、
　業務分析の工程ではアクティビティ図が使われています。
　自分の経験としても、簡単なプロセスであれば、アクティビティ図で十分だと思います。

　より業務プロセス分析に特化した表記として　BPMN　というものが
　ありますが、これはUMLではありません。
　（厳密な言い方をするなら、UML表記とは違う表記ですが
　　データの互換性はあります。）
　ただ、UMLツールではBPMNもサポートするものが増えきています。

>アクティビティ図では、複数のレーンでコラボレーションするようなアクティビティは
>どのように表現すれば良いでしょう？
複数のレーンをつくってもある程度まではなんとかなるはずですが・・・。
具体的にどういった問題が生じていますか？

>2 クラスを見つける方法として自分が買った本には
名詞抽出法は基本ですが、後は慣れだと思います。
ある程度まで分析でクラスを見つけられるようになったら、
実装モデリングまで何度かやってみることをお勧めします。
分析工程のクラス図は、設計工程、実装工程で使うことを目的に作るものですから、
後の工程を経験すると、どのように作るとあとから作業がしやすいか、
という視点から、おのずとどうモデリングすべきかがわかってきます。

648 ：デフォルトの名無しさん：2006/06/10(土) 00:30:50

>>646
>3 クラス図で、依存、集約、コンポジションはソースコードでは
>片方のクラスからもう片方への参照という形になるのでしょうか？
UMLの規格においては、その点についての規定はありません。

UML上の表現に対して、それをソースコード上でどう実現するかは、
使う側にゆだねられています。
Java で考えると、たとえば、集約はCollection だけど、
コンポジションだから配列フィールドで実現する、
かというと、必ずしもそうではなく、コンポジションうをCollection フィールドにして、
生成・追加はそのクラス内部でだけやる、というようなつくりにしてもいいわけです。

たいていの場合は、プロジェクト単位で方針を決めて
（主に実行速度やメモリ効率などの実装上の問題を考慮して）、
それにあわせてコーディングする（あるいはツールにそのように設定して生成させる）
ことになるでしょう。

649 ：デフォルトの名無しさん：2006/06/11(日) 02:23:09

>>647

たとえば、こんな感じのときです
http://www.vipper.org/vip273377.png.html

650 ：デフォルトの名無しさん：2006/06/11(日) 03:37:54

>>649
ああ、なるほど、それは困りますね。
おそらく、アクティビティ図では、レーンをまたがるアクティビティというのは描けないでしょう。

act5 の中身を分解して各レーンごとのアクティビティまで書くか、
レーンの分割をやめてしまって、荒い粒度の
（「act1 -> actX(act2～act4をまとめてしまったアクティビティ)　->act5 」のような感じの）
アクティビティ図にするしかないでしょう。

ところで、act5 の中で、part1～part4がどう連携するのかは、分からなくていいのですか？

651 ：デフォルトの名無しさん：2006/06/11(日) 12:44:39

>>650

act5のアクティビティで具体的に想定していたのは、会議なので
part1～part4の連携の記述は考えていませんでした。

とりあえずは

・act5のコメントで、参加するパーティションを明記する
・連携の内容については、別の図に粒度を小さくして
　アクティビティ図、シーケンス図、コミュニケーション図のどれか
　で記述する

感じでしょうか

652 ：デフォルトの名無しさん：2006/06/11(日) 12:48:30

なんか、使い方間違ってないかな？

653 ：デフォルトの名無しさん：2006/06/11(日) 23:21:16

>>652
kwsk

654 ：U ◆CZtFsGiu0c ：2006/06/13(火) 13:11:49

>>652
そんな気もするけど、でも「会議」が業務プロセスにおけるアクティビティ
として適切でないか、というとそんなこともないんだよね。

>>651
「その会議に参加するメンバ」の役割でくくったレーンを追加すれば?
厳密に記述することが目的じゃないんだから、見る人がわかればいいんだ
よね、結局。

655 ：デフォルトの名無しさん：2006/06/13(火) 21:21:47

会議って言うよりは、その会議の役割である意思決定
ていうのが適切かもしれない

で、意思決定を行う機関をレーンの名前にする
例えば会社レベルだと取締役会とか

656 ：デフォルトの名無しさん：2006/06/17(土) 10:56:28

UMLのシーケンス図の表記方法についてご教授下さい。
インタフェースを中心とした設計をして、ポリモを多用しています。
この場合のシーケンス図の表記法がよく理解できていません。
インタフェース、シーケンス図表記などとググッてみたものの
ユーザインタフェース…とかクラス図での表記しか見つけられませんでした。

参考になるサイト等の紹介でもかまいませんので、よろしくお願いします。

657 ：デフォルトの名無しさん：2006/06/17(土) 11:08:43

具体的にはどういった事を表記するときに困っているのですか？

658 ：デフォルトの名無しさん：2006/06/17(土) 11:26:14

ポリモフィズムは、継承だろ？　もしくは実現

659 ：デフォルトの名無しさん：2006/06/17(土) 11:28:08

シーケンス図にポリモフィズムの関係なんて、別に書かなきゃいいじゃん

660 ：デフォルトの名無しさん：2006/06/17(土) 11:45:21

>657
例えば、従業員と給与体系（月給、歩合給、年俸等）の関係で、
従業員の給与体系を、月給から歩合給などに変更することが可能なモデルに
する場合、給与体系というインタフェースクラスを作成し、月給クラスや
歩合給クラスが実装クラスとしています。従業員クラスから給与体系クラス
への関連を持つようなクラス図にしています。
このときに、ある従業員の給与計算を行う場合、
従業員の給与体系の実装クラスである月給や歩合給クラスをNewして、
給与体系インタフェースクラスの変数に入れるような処理をしています。
この場合に、シーケンス図では、給与体系インタフェースクラスを記述する
のか、それとも月給や歩合給クラスなどを記述するのか、どちらがよいの
でしょうか？

ご教授よろしくお願いいたします。

661 ：デフォルトの名無しさん：2006/06/17(土) 11:58:32

>>660
そのシーケンス図の目的によりますが、
一般的には（たとえば、今回のレスに対して一枚だけシーケンス図を描く、というような場合）、
>給与体系インタフェースクラスを記述する
ことになると思います。

662 ：デフォルトの名無しさん：2006/06/20(火) 22:11:51

サーブレット&ＪＳＰのクラス図の書き方わかんねえええ

663 ：デフォルトの名無しさん：2006/06/21(水) 09:43:54

>>662
まずはドメイン領域の設計とレイヤ設計を分けて考えることをお勧めします。

んで、ドメイン領域の設計はUML教科書の通りにすれば良いのかと。
（会社クラスと組織クラスと従業員クラスが関連を持ってる、みたいな形ね）

レイヤ設計、というかアーキテクト設計は、ドメインをどうやって操作するのかを
表現すればいいのかと。

例えばこんな形ね。
http://www-06.ibm.com/jp/software/websphere/developer/j2ee/lightweight/
（私はSpring遣いなので、これをもっと詳しく書いた設計図を各プロジェクト共通の
アーキテクト設計書として使いまわしています）

664 ：デフォルトの名無しさん：2006/07/22(土) 15:57:30

アクティビティ図で
AがBから情報を取得することを表現する場合、

Aのパーティションに
「情報を要求する」アクティビティ(a1)と
「情報を受取る」アクティビティ(a2)を描いて、
Bのパーティションに
「情報を提供する」アクティビティ(b1)を描いて、
a1からb1へコントロールフローで繋いで、
b1からa2へコントロールフローで繋いで、
b1からa2へオブジェクトを示してオブジェクトフローで繋ぐ
って描くんだと思いますが、パーティションが多くて離れていたりすると
見づらいと思います。

もっと簡潔に描く方法はないですか？

665 ：デフォルトの名無しさん：2006/07/22(土) 15:58:58

ageときます

666 ：デフォルトの名無しさん：2006/07/22(土) 16:37:53

>>663
階層化すれば？
上位階層はaとb、c...レベルの関係を記述する。
下位階層は２つの組織間だけの詳細(a1, a2, b1)を別な図で書けばいい。

667 ：デフォルトの名無しさん：2006/07/25(火) 23:46:30

クラス図で、スタティック定数しか持っていないクラスを
参照する場合、どう表現すればよいのでしょうか。
依存？関連？

668 ：デフォルトの名無しさん：2006/07/26(水) 01:03:14

>>667
依存でよいと思います。

669 ：デフォルトの名無しさん：2006/07/26(水) 01:04:30

>>667
そんなにいちいち線引いてらんね

670 ：デフォルトの名無しさん：2006/07/27(木) 01:10:36

フォルダにあるファイルを印刷するツールを作ろうとしてます
http://www.geocities.jp/retort_curry119/UML.pdf

ユースケース図の描き方とか
こんな感じで良いんでしょうか？

671 ：デフォルトの名無しさん：2006/07/27(木) 03:19:57

>>670
フォルダの中のファイルを全部印刷するの？

672 ：デフォルトの名無しさん：2006/07/27(木) 07:21:48

>>670
見たけどユースケース違うんじゃね？
「リストファイルを作成する」ってユースケースは、
単体で成り立つケース(1)なの？
それとも、印刷時だけ行う手順(2)なの？

1なら、印刷は「リストファイルを作成する」とは別ユースケースにして、

　　　　→印刷する
ユーザ　　　↓
　　　　→リストファイルを作成する→フォルダーを選択する

2なら

ユーザ→印刷する→リストを作成する→フォルダーを選択する

かなと思う。詳細は知らんけど。
だけど、ほんとはこうなんじゃないの？

　　　　→リストファイルを作成する→フォルダーを選択する
ユーザ　
　　　　→印刷する→リストファイルを指定する

673 ：670：2006/07/28(金) 00:02:11

>>671 >>672
レスありがとうございます

要件を簡単に箇条書きすると
・フォルダ内の全てのファイルをリスト順に印刷する
・リスト作成ボタンクリックで、リスト書き込み先のファイルを指定する
・リスト作成では、指定フォルダ内のファイル名をソートして書き込む
・リストファイルには、ファイル名だけ記述し、パスは記述しない
・印刷開始ボタンクリックで、リストファイルを選択する
・リストファイルのファイル名と、フォルダのパスを連結して印刷対象ファイルのフルパスを得る
こんな感じです

画面イメージも付けてみました
http://www.geocities.jp/retort_curry119/UML.pdf

ファイル構成が同じ、別のフォルダを印刷したいので、こんな風にしてみました
普通は 672さんの最後の感じで良いんだと思います

674 ：デフォルトの名無しさん：2006/07/28(金) 22:10:40

>>664
コネクタってパーティションと一緒に使っちゃダメなの？
あと細かい指摘になるけどa1やa2はアクティビティではなく
アクションでは？

675 ：デフォルトの名無しさん：2006/07/30(日) 14:26:08

>>674
コネクタを使って、途中の線を省略するっていう方法もアリでしょうね
厳密には、アクションですね

676 ：デフォルトの名無しさん：2006/07/30(日) 14:32:48

あしたはいよいよnecのアレが配布される非ですね

677 ：デフォルトの名無しさん：2006/07/31(月) 13:38:21

>>676
ダウンロードのためのリンク見つけられず・・・
まだないのか？

678 ：デフォルトの名無しさん：2006/07/31(月) 20:03:32

>>676

いまだにみつからないのだが...

679 ：デフォルトの名無しさん：2006/08/01(火) 19:46:47

>>678

ttp://uml.livedoor.biz/archives/50505702.html

680 ：デフォルトの名無しさん：2006/08/04(金) 21:52:52

NECのフリーのツール
アクティビティ図のジョインとフォークが逆じゃね？
フローを折れ線にすると判る

681 ：デフォルトの名無しさん：2006/08/04(金) 23:24:14

サイトのメアドから報告してあげれば～。

682 ：デフォルトの名無しさん：2006/08/13(日) 05:40:08

スレッドに書き込まれた株式番号全てを集計しランキング化するプログラムのステートマシン図です。
http://kasamatusan.sakura.ne.jp/cgi-bin2/src/ichi48069.jpg.html
血迷いながら書いたのですが、まずは何から学んだ方が良いでしょうか？

683 ：デフォルトの名無しさん：2006/08/13(日) 09:44:56

これはアクティビティ図じゃないのか。

684 ：デフォルトの名無しさん：2006/08/13(日) 23:49:37

アクティビティ図ですね

4桁の数字をキーにして、ハッシュにレス番号を追加する
の後のフローは？

もう少し見易くなるように配置や線の形状を工夫した方が良いと思う

685 ：デフォルトの名無しさん：2006/08/14(月) 02:24:29

こんな醜いアクティビティー図描ける人がいたなんて！

686 ：デフォルトの名無しさん：2006/08/14(月) 20:40:57

ここでビジネスＵＭＬについての質問はいいですか？

ソフトウェアの処理（普通のＵＭＬ）と、ユーザーの反応や活動（ビジネスＵＭＬ？）
を一つの図にまとめたいのですが、そういうことやっておられる方いますか？
独習で一度書いてみたのですが、やはり馴れた人から見るとヤバイ部分がかなりあるらしく
わかる人にきちんと聞いてみたほうがよいようなので。

687 ：デフォルトの名無しさん：2006/08/14(月) 22:02:56

ビジネスUMLって、ビジネスユースケースとかビジネスアクターの話？

688 ：デフォルトの名無しさん：2006/08/14(月) 22:20:30

無理に言うと、ビジネスモデルのＵＭＬ表記の話に近いかと思ったんですが、
かえってわかりにくいですね。ｽﾏｿ

プログラムの動きとそれを使う人間の活動（ゲームプレイなど）をまとめてＵＭＬ表記したいのですが
ＵＭＬの専門家はプログラムの処理はかけるけれど、人間活動の書法はやってないので
助言はできないという返事でした。それで、どなたかそういった（ちょっとイレギュラーな）事を
やっている方がおられたら紹介していただきたいと思いまして。

689 ：デフォルトの名無しさん：2006/08/14(月) 22:56:21

きちんとクラスにできれば、ビジネスモデルでもＵＭＬで表記できるんじゃないの？
ＵＭＬの記法には、プログラムに依存してるところがあるのかな？
具体的には、何が描けないって言われたわけ？

690 ：デフォルトの名無しさん：2006/08/14(月) 23:08:37

>プログラムの動きとそれを使う人間の活動（ゲームプレイなど）をまとめてＵＭＬ表記したいのですが

とりあえず、アクティビティ図で、ユーザ（プレイヤー）と、
システムのレーンを分けて書いてみたら？

691 ：デフォルトの名無しさん：2006/08/15(火) 01:18:33

シーケンス図で、

　　　　　objectA　　　　　objectB　　　　　objectC
　　　　　　　　 methodB(objectC)
　　　　　　　　------------>

のように、objectAのインスタンスから objectB　のインスタンスのメソッドをコールする際に、
引数にobjectCのインスタンスを引数に渡すような場合、上のような書き方でいいのでしょうか？

692 ：デフォルトの名無しさん：2006/08/15(火) 11:50:50

>>691
そのとおり。

ちなみに、methodB のパラメタが ClassA で、 objectC が　ClassA のインスタンスであった
場合に、methodB　のメッセージのパラメタを入力するときに、objectCを候補に出してくれる
ようなアシスト機能を持っているツールは自分の知る限り無い。
シーケンス図上の「objectC」というオブジェクトと、メッセージ「methodB(objectC) 」の
「ObjectC」の関連をツールは認識していないし、データとしても持っていないんだろうと思う。

693 ：デフォルトの名無しさん：2006/08/16(水) 01:53:53

実装まで意識してＵＭＬ描くなボケ

694 ：デフォルトの名無しさん：2006/08/16(水) 05:27:05

概念的なのと、詳細と段階を分けて描けば良いでしょ
詳細なので全体を描くのは難しいだろうけど、対象範囲を狭めればＯＫだと思う

695 ：デフォルトの名無しさん：2006/08/16(水) 21:55:24

実装方法を説明するための UML図というものもあるはずだし。

696 ：デフォルトの名無しさん：2006/08/16(水) 22:50:56

は？

697 ：デフォルトの名無しさん：2006/08/17(木) 22:44:59

とりあえず、配置図やコンポーネント図はそうだろう。

698 ：デフォルトの名無しさん：2006/08/18(金) 01:26:46

>>697
そんなアバウトな図で何表現すんだよ。

699 ：デフォルトの名無しさん：2006/08/18(金) 23:21:29

>>698
まあ、君は使う必要がないんだから、それでいいじゃん。

700 ：デフォルトの名無しさん：2006/08/18(金) 23:47:07

UMLってjavaに特化してない？
パッケージの可視性なんてもろJavaオンリーって気がするんだよね

701 ：デフォルトの名無しさん：2006/08/19(土) 23:23:15

>>700
Java にパッケージの可視性というものは無い。
package private の話か？

702 ：デフォルトの名無しさん：2006/08/19(土) 23:40:10

どっちかというと.NETのアセンブリが概念として近いんじゃない？

703 ：デフォルトの名無しさん：2006/08/20(日) 13:38:32

ちょっと調べてみたけれど、

OMT には、可視性の概念が無いっぽい。

　オブジェクトモデル化技法　出典: フリー百科事典『ウィキペディア（Wikipedia）』
　ttp://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%A2%E3%83%87%E3%83%AB%E5%8C%96%E6%8A%80%E6%B3%95

Booch法には、package private というのはどうもないようだ。

　オブジェクトの広場：Booch法言いたい放題
　ttp://www.ogis-ri.co.jp/otc/hiroba/specials/BoochSpecial/chat.html

Booch法が発表されたのが 1990年で、Java の開発も同時期に始まっている。

　ジェームズ・ゴスリン　出典: フリー百科事典『ウィキペディア（Wikipedia）』
　ttp://ja.wikipedia.org/wiki/%E3%82%B8%E3%82%A7%E3%83%BC%E3%83%A0%E3%82%BA%E3%83%BB%E3%82%B4%E3%82%B9%E3%83%AA%E3%83%B3%E3%82%B0

なので、

１．Java で　package private　の概念が示され、UMLでそれが取り入れられた
２．1990年代初頭に、OMT、Booch法以降のオブジェクトモデリングの議論の中で、
　　　　package private　の概念が示され、Java にそれが取り入れられた。

の二つの可能性が考えられるが・・・。
詳しい人解説キボンヌ。

704 ：デフォルトの名無しさん：2006/08/25(金) 02:38:56

誰かクラス図の関連と依存の違いを教えてくれ。
クラスAでクラスBのインスタンスを生成して、Bのメソッドを使用するとする。
１．Bを変更するとAに影響がでる（見直す必要がある）＝AはBに依存する。
２．インスタンスを生成した時点でBはAのプロパティとなる＝AからBへ関連をあらわす実線矢印？

多分２がダウトなんだろうけど、int a;がプロパティなら、B　instanceB;もプロパティだし。

あと、スレッドプログラミングのときはスレッド自体はどうクラス図に描くの？

705 ：デフォルトの名無しさん：2006/09/05(火) 23:31:46

>>704
設計モデルまたは実装モデルをＵＭＬで表現するときに、こういうルールを使ってます。

依存：プロパティ、フィールド変数にならないオブジェクトを操作する
関連：プロパティ、フィールド変数に保持するオブジェクトを操作する

仕様上は決まりがないので、なにか基準を決めて運用する必要があると思うです。

設計モデルでスレッドクラスを表現する必要があるならば、スレッドクラスを書くだけです。
スレッドのオブジェクト・インスタンスを表現する必要があるならば、クラス図では書けないので
別の図を使うだけです。

706 ：デフォルトの名無しさん：2006/09/06(水) 00:47:59

クラス図に、ちょっとだけオブジェクトを描きたくなることないですか？

707 ：デフォルトの名無しさん：2006/09/06(水) 01:38:59

誰か良い本教えて～。
独習UML買ったんだけど、死ぬほど分かりにくい上に書いてないところとかがある。
だいたいかけるようになったけど、細かいところが微みょーな上にノウハウゼロ。

708 ：デフォルトの名無しさん：2006/09/06(水) 21:53:08

>>706
つうか、オブジェクト図とクラス図って区別してないツールが多いから・・・。

>>707
UMTP L2 の参考書が以外に参考になるかもしれん。

709 ：デフォルトの名無しさん：2006/09/06(水) 23:47:53

>>708

それ以外だとどの本がいいの? 俺も知りたい。

710 ：デフォルトの名無しさん：2006/09/14(木) 23:47:56

UMLモデリングのエッセンス

711 ：デフォルトの名無しさん：2006/09/17(日) 18:30:47

UMLでテンプレートを特殊化したクラスってどうかくかわかる？
インスタンティエイテドクラスでいいのかなぁ。
C++で使う特性クラスとかをUMLで表現しようってのがそもそも間違ってるのかも。

712 ：デフォルトの名無しさん：2006/09/19(火) 19:20:53

クラスAがクラスB のポインターを持っている場合とメソッドのパラメータで渡される場合、ローカルで宣言して使う場合、メソッドの戻り値で与えられて使う場合は関係はどうなるんでしょう？

・クラスAがクラスB のポインターを持っている場合
関連もしくは集約、操作を行えば操作

・メソッドのパラメータで渡される場合
関連、操作を行えば操作

・ローカルで宣言して使う場合
関連、操作を行えば操作

・メソッドの戻り値で与えられて使う場合
関連、操作を行えば操作

こんなかんじでしょうか？
操作を行うということは必然的にその前段階として関連か集約の関係があるとみなしていいのでしょうか？

713 ：U ◆TZmHcxsMjM ：2006/09/20(水) 21:16:29

>>711
パラメタライズドクラスとそれを継承したクラスで表現できると思う。

714 ：デフォルトの名無しさん：2006/11/15(水) 19:17:26

TCPで通信するサーバとクライアントのアプリを
きちんとUMLで仕様を表現してから、
それに従ってプログラミングしたいと思ってます。

とりあえず下のような図を考えてみたのですが、
これで一般に「きちんとしたUML」と認識してもらえるでしょうか？

■ クラス図

　　　　<<TCP:55001>>　←受信ポート番号を表記したい
　 ___________　　　　　　　　　__________
　| Server |----O )----| Client |
　|___________|　　　　　　　　.|__________|
　　　　　　　　　　↑
関数呼び出しでなく、TCPメッセージのやりとりをする
関係にあることを表現したいのでインターフェースを挟んだ。

715 ：714：2006/11/15(水) 19:18:44

で、上のクラス図に対応するコードです。

■ C++コード

// 提供?インターフェース
class ServerIF
{
　　virtual int recvMessage() = 0;
};

// TCPサーバクラス
class Server :public ServerIF
{
　　int recvMessage() {};
};

// 要求?インターフェース
class ClientIF
{
　　virtual int sendMessage() = 0;
};

// TCPクライアントクラス
class Client :public ClientIF
{
　　int sendMessage() {};
};

716 ：U ◆CZtFsGiu0c ：2006/11/16(木) 20:31:56

>>714
そういうのはクラス図ではなく、配置図やコンポーネント図でカバーする
内容だと思う。

717 ：デフォルトの名無しさん：2006/11/16(木) 20:40:08

ちうか「インターフェイス」の意味を取り違えていると思う。
とりあえずシーケンス図を使って通信プロトコルを書いた方が良さげなきがする。

718 ：デフォルトの名無しさん：2006/11/16(木) 20:55:42

そういうことはないだろ。
「インターフェース」は、Java の Interface を表してても、
通信プロトコルを表してても、物理的な規格（RS232CとかUSBとかEthernetとか）を
表しててもいいはず。

719 ：デフォルトの名無しさん：2006/11/24(金) 20:22:39

ねえねえ、オブジェクトの抽出って、仕様書や問題文から"名詞"を抜き出すってのを
よく聞くんだけど、みんなそれでやってるの？

となると、例えば、ホテルとか航空券の予約システムなんてのを考えると、
"客"、"座席"、から始まって、"予約"、"予約確認"、"空席状況"･･･と出てくるかもしれない。(今やってる問題は出てくる。)、あれぇ？って状況なんだけど･･･

･･･流れが逆だけど、javaでいうメソッドもクラスも混ざってるよね･･･。

はて、頭冷やしてやり直すべきか･･･。

720 ：デフォルトの名無しさん：2006/11/24(金) 21:34:27

「予約確認」は動詞じゃないの。
「予約」は文脈によって動詞の場合と名詞の場合がある。
名詞の「予約」がクラスになって、動詞の「予約」がメソッド（操作）になる。

で、最初のころに陥りがちなことだけど、分析工程で要素の分類に神経質になりすぎて、
全然先に進めなくなってしまうということが起きる。
モデリングは、慣れの要素が大きいから、一つの工程を完璧にこなそうとかし始めると、
最初から躓いてしまう。
最初は、多少変かなあ、不足かなあ、と感じる程度の内容でも、
一度実装まで一通りやったほうがいい。
何回かやると、要領がわかってくる。

721 ：デフォルトの名無しさん：2006/11/24(金) 22:10:09

>>719
「ユースケース入門―ユーザマニュアルからプログラムを作る」を読むことおすすめする。
この本はかなりしっくりくると思う。

722 ：デフォルトの名無しさん：2006/11/26(日) 01:43:23

ユースケース、アクティビティ図、クラス図
を何回かスパイラルで改版していくと良いと思う

ウォーターフォールみたいに後戻りしないでっていうのは
経験をつめば出来るようになるだろうけど

723 ：デフォルトの名無しさん：2006/12/07(木) 23:21:30

これから、企業の新規システムのユースケースを
作成しようと思っているが、なんかいい本ない？

724 ：デフォルトの名無しさん：2006/12/07(木) 23:59:13

つUML モデリングのエッセンス

725 ：U ◆CZtFsGiu0c ：2006/12/08(金) 01:01:11

>>723
http://www.amazon.co.jp/gp/product/4798101273

726 ：デフォルトの名無しさん：2006/12/08(金) 21:16:34

ワードとかに貼り付けられるUMLにエディタはありませんか？

727 ：デフォルトの名無しさん：2006/12/09(土) 16:48:16

画像出力して張り付けでよければ、どのエディタでもできるけど
巨大化したシーケンス図とか困るのよね

728 ：デフォルトの名無しさん：2006/12/10(日) 02:08:20

福島、和歌山、宮崎をネタに、
「県知事談合パターン」をUMLで表現せよ

729 ：デフォルトの名無しさん：2006/12/10(日) 02:25:54

>>727
貼り付けるときはメタファイルでやるのがコツだけど、
やっぱりかなりでかい図は、文字が読めないんだよな。
みなさんどうしてます？

730 ：デフォルトの名無しさん：2006/12/10(日) 17:39:04

クラス図とか使い始めたの最近な大学生なんだけど、
システムはクラス同士の関係で全部説明できるはずですよね？

なんか、グループワークで同じグループの人がデータベースをクラス図に入れてるんだけど
これは違うよーな気が･･･。

それから、
"データベースからクエリなんかで必要な情報を検索する"
って言うのはクラスの機能にあたるのでしょうか？

731 ：デフォルトの名無しさん：2006/12/11(月) 13:14:43

>>730
・クラスベースで考えるならクラス同士の関係で全部説明できる。
・データベースの何をクラスかしてるか知らんがDB機能を持つものをクラスとして扱ってるというならあり。
・"･･･検索する"は少なくともユースケースにつながる機能の一つであることは間違いない。その"機能"をひとつのクラスで実装するのか分散するのかは実装しだい。

732 ：デフォルトの名無しさん：2006/12/11(月) 16:39:18

統一教会と安部は関連で
勝共連合と麻生が関連で
統一と山口組の多重継承が勝共
勝共の主要メンバーが笹川で岸信介と関連

733 ：デフォルトの名無しさん：2006/12/13(水) 03:37:56

>>730
ＥＲ図はクラス図で表現できるでしょ
クラス図の方が表現力は高いと思ってるけど

734 ：デフォルトの名無しさん：2007/02/17(土) 21:28:15

UMLを学び始めたばかりの者です。
以下の仕様でユースケースを作ってみたのですが、このような感じで良いのでしょうか？

ユースケース名：製品データベースの観覧と管理
アクタ：社員（データベースを使用するuser、データベース管理者、営業部門、卸部門、会計部門が存在する）
目的：社員のデータベースの観覧、及び管理
事前条件：役職によってデータベースアクセス権限が違う
基本系列：
データベース管理者はデータベースのすべての情報を観覧、管理する事が可能だが、何を行ったかはログが残る。

営業部門の社員は製品の情報と在庫を観覧する事が出来、顧客から注文が入った場合はその製品を予約する事が出来るが、在庫の個数を変更する事は出来ない。

卸部門の社員は製品の情報を観覧、在庫の個数を観覧・変更することが出来る。

会計部門は製品の情報と価格を観覧する事が出来る。

事後条件：社員はそれぞれの役職に沿ってデータベースを観覧、及び管理をする事が出来る。
ユースケース図：ttp://user.ftth100.com/log/up/log/3363.jpg

735 ：デフォルトの名無しさん：2007/02/18(日) 05:49:07

Eclipseのプラグインとして使えるフリーのUML描画ツールあったら
教えてください。
いろいろ試したけど、どれもいまいちでした。
Amateras試したけど、他のプラグインとの相性でバグが発生しました。
でも機能的には一番いい感じがしました。
他にお勧めはないでしょうか？

736 ：デフォルトの名無しさん：2007/02/18(日) 22:09:17

Topcased

737 ：デフォルトの名無しさん：2007/02/24(土) 14:18:26

入門UML買ったんで来てみたが……
もうオワットルのか（＾ω＾；）

738 ：デフォルトの名無しさん：2007/03/08(木) 23:49:27

手法自体は役に立ってると思う

主に
時間的な縛りが無くて、仕様変更が多い趣味のアプリを作る用途に

739 ：デフォルトの名無しさん：2007/03/20(火) 02:03:35

Cで良くみるHelloWorld↓なんだけど

#include <stdio.h>
int main(int argc, char **argv){
printf("Hello World!");
}

だれかこのHelloWorldソフトウェアをUMLで表現したやつ知らない？

740 ：デフォルトの名無しさん：2007/03/22(木) 12:30:50

>>739
ステートチャートで表現するなら
開始　状態：あいさつ動作　終了
クラス図なら、適当にStartupかGlobalクラスをこさえて操作でprintfを定義
・・・とか

741 ：デフォルトの名無しさん：2007/03/23(金) 00:12:05

UMLって自分で書くコードのために脳内整理するとか
自分で書いたコードを人に説明するにはいいと思うんだけど、

人の書いたUMLで実装しろといわれたら気が狂いそう。

742 ：デフォルトの名無しさん：2007/04/25(水) 20:12:26

描き方に指針つーか、良いお手本があればいいんだけどねえ。
まだまだ時間の積み上げがひつようか

743 ：デフォルトの名無しさん：2007/05/01(火) 08:08:20

ユースケース図書くときにそのシステム自体のプログラム(サブシステムとかではない)をアクタにしたりしないですよね？

744 ：デフォルトの名無しさん：2007/05/01(火) 18:23:33

> 743
しないと思う。外部のシステムはアクターにするけど。

745 ：デフォルトの名無しさん：2007/05/01(火) 22:45:31

>>744
ありがとうございます。
もう一つ確認したいのですが、ユースケース図はシステムを利用するユーザ（アクタ）視点の定義であってその内部とのつながりを表す必要はない（むしろ表すべきでない）という理解で良いでしょうか？

746 ：デフォルトの名無しさん：2007/05/02(水) 17:33:19

>>745

> ユースケース図はシステムを利用するユーザ視点の定義
はい、私は全体の俯瞰図みたいな使い方をしてます。

> その内部とのつながりを表す必要はない
この「内部」が何を指してるのかよく分からないんですが、
もしかしてユースケースをすごく緻密に書こうとしてますか？

基本的には、どの立場の人が業務のどの部分にどう係るかが
分かればいいもんだと思ってますが。

747 ：デフォルトの名無しさん：2007/05/05(土) 02:44:16

extends(だっけ？9とかのことじゃないかな

748 ：デフォルトの名無しさん：2007/05/07(月) 07:01:02

>>746
遅くなって申し訳ないです。
かなり細かく書こうとしてましたがあまり細かくなるとユーザに分かりづらくなりそうなのでやめました。

>>747
もう少し根本の考えでした。

回答していただいた方々、ありがとうございました。

749 ：デフォルトの名無しさん：2007/05/27(日) 14:41:59

UML本で迷っています。アドバイス下さい。
最初に２冊も３冊も買うと心理的負担が大きいので、まずは１冊のみ用意することを考えています。
今自分が購入候補として考えているのは以下です。
他のものがよければ是非お教え願いたく存じます。

①UML モデリングのエッセンス第3版 | マーチン・ファウラー著, 羽生田栄一翻訳 | 翔泳社発行

②独習UML 第3版 | 株式会社テクノロジックアート著 | 翔泳社発行

③UMLデスクトップリファレンス | Dan Pilone 著, 原隆文翻訳 | オライリー・ジャパン発行

④入門 UML 2.0 | Russ Miles, Kim Hamilton 著, 原隆文翻訳 | オライリー・ジャパン発行

本関連の質問はスレ開始から幾度かありましたが、皆さんの生の声や新しい情報を頂きたかったので、あえて質問します。
どうかよろしくお願いします。

750 ：デフォルトの名無しさん：2007/05/27(日) 16:15:01

>>749
UML モデリングのエッセンス

751 ：デフォルトの名無しさん：2007/05/27(日) 21:39:09

749です。
今日店を回りましたが

①UML モデリングのエッセンス第3版 | マーチン・ファウラー著, 羽生田栄一翻訳 | 翔泳社発行

が置いてありませんでした。
ネットで買うのもいいですが、中身を見てから買いたいので、自分にあった本を探そうかと思います。

752 ：デフォルトの名無しさん：2007/05/28(月) 02:25:48

　ファウラ本はUMLの書き方勉強したあとに、こんなん実務で
使えるかよってジレンマに陥ってから読んだほうがいいとおもう。

753 ：デフォルトの名無しさん：2007/05/28(月) 03:43:25

>>749

強いて言えば②

①については>>752の通り買うべきだが、今は買うべきではない

754 ：デフォルトの名無しさん：2007/06/08(金) 11:40:35

いまさらだけど疑問。
UMLはなぜ破線なんて手書きで書きにくいものを採用してるんだろう。手書きでメモるのを放棄してる。
と、最近使い勝手のよさそうな図を見て破線があることにげんなりした自分。

755 ：デフォルトの名無しさん：2007/06/08(金) 17:03:06

定規使う事を前提にしてるからじゃね？

756 ：デフォルトの名無しさん：2007/06/08(金) 23:28:29

>>755
ツールが売れる事を前提にしているのです。

757 ：デフォルトの名無しさん：2007/06/08(金) 23:35:07

スケッチとして使うなら破線て省略可能なやつばっかじゃね？

758 ：デフォルトの名無しさん：2007/07/07(土) 10:35:22

これと、

+----------+
| Class1　　　 |
+----------+
| name:String|
+----------+

これって、

+----------+ 　　　name +----------+
| Class1　　　 |　◆-------| String　　　 |
+----------+　　　　　　1 +----------+

等価と考えていいの？

759 ：デフォルトの名無しさん：2007/07/07(土) 20:29:50

コンポジションが付くかはわからんのんじゃね？

760 ：デフォルトの名無しさん：2007/07/07(土) 20:40:17

761 ：デフォルトの名無しさん：2007/07/07(土) 21:04:34

たしか等価

762 ：デフォルトの名無しさん：2007/07/07(土) 21:10:33

ありがとう。

それで、なんでこんなことを聞いたかというと、
等価なら、同じモデルをダイアグラムごとに表現を変えれてもいいと思うんだが、
そいうことのできるツールってないねえ、という話がしたかった。

763 ：デフォルトの名無しさん：2007/07/09(月) 10:46:40

そういう需要ってあるんかね?自分的にはあってもいいと思うけど。

764 ：デフォルトの名無しさん：2007/07/14(土) 03:05:20

>>759
コンポジションって、「全体がなければ部分も存在できない」
集約は、「全体が無くても、部分だけで存在できる」
だったと思う。

>>758
のケースだと
Stringクラスは・・・って、ああそうか
クラスとしては存在できるのか、
nameインスタンスとしては、Class1が無いと駄目だけど。

765 ：デフォルトの名無しさん：2007/07/22(日) 11:06:01

iconixアプローチ使ってる人っているかしらん？？
今、UMLの勉強中なんだけど、使える手法なのかなぁって思って。
（当方の状況は、UMLは一通り見たけど実戦経験が多少足りない感じ。）

766 ：デフォルトの名無しさん：2007/08/05(日) 23:58:03

C言語でUMLしようと思ったときに
JAVAとかC#みたいな参考書になるものってないっすか？

767 ：デフォルトの名無しさん：2007/08/06(月) 00:03:29

一応UMLってのは言語非依存ですよ・・・

768 ：デフォルトの名無しさん：2007/08/06(月) 22:17:18

>>766

非オブジェクト指向言語に当てはめるのもどうかと思うが…

769 ：デフォルトの名無しさん：2007/08/06(月) 23:05:16

BREWの実装を勉強したらいいと思うぉ。

#本末転倒とも言う。

770 ：デフォルトの名無しさん：2007/08/14(火) 00:57:41

EAでC言語はけるのに
なんで他のは未対応なんだ

UMLのツールって糞高い割りにつかえねーソフト
ばっかりだよなぁ

771 ：デフォルトの名無しさん：2007/08/14(火) 14:26:24

>>770

EAを基準にして考えると対抗馬は存在しないと思う
基準を他のソフトにすべきでは？

772 ：デフォルトの名無しさん：2007/08/14(火) 22:30:06

まあ、基本的に UMLツールの目的は、UMLを編集することだから。
UMLから言語コードへの変換はぶっちゃけ、外付けのプログラムでやればいい。

MS-Word に仕様書からプログラム吐く機能がないから
使えないとはいわないだろう。

773 ：デフォルトの名無しさん：2007/08/14(火) 23:53:11

そもそもUMLは言語コードと対応すべきものではないような

774 ：デフォルトの名無しさん：2007/08/14(火) 23:59:02

対応は、もともとしてるのではなくて、（アーキテクトが）「させる」もの。

775 ：デフォルトの名無しさん：2007/08/15(水) 00:04:29

人はそれをフレームワークという

776 ：デフォルトの名無しさん：2007/08/15(水) 07:00:48

>>772

Wordがソフトの設計をすることをある程度前提にしたものであり
記述するための言語(たぶん日本語)がソフトの設計をすることを
ある程度前提にしたものであるなら、その通り。

UMLツールが、単にUMLを編集するだけのものか
あるいはその先に存在するプログラムを吐くところまで
対応するかは、UMLツールのポリシー次第。

プログラムが吐けないから使えないということはないが
プログラムが吐けることは一つの長所と言えるだろう。

あとは使う側のポリシー次第。

777 ：デフォルトの名無しさん：2007/08/15(水) 12:35:34

そうやって自由度の高い説明されると
聞いている方は頭に詰め込んだ概念がどんどん瓦解していって
最後には「何でもできるけど何もしない」ところに落ち着いてしまうんだよな

778 ：デフォルトの名無しさん：2007/08/15(水) 12:37:48

「何でもできるけど何もしない」のは中立で動かないってことじゃない
何かしようとすると、それを”しない場合”を制限してしまうから、何も出来ないということ

”CASEツールはUMLツールの一部じゃん”、って逝って”UMLツールはプログラムの一種じゃん”
って言った瞬間に、この「何でもできるけど何もしない」に落ち着くってことだ

779 ：デフォルトの名無しさん：2007/08/15(水) 14:02:07

上中流の設計で使うUMLと下流CASEで使うUMLは区別してる。
一貫してやれてるところもあるのだろうけど、うちじゃとても無理だ。
下流CASEは開発言語にディペンドして拡張されてるなんちゃってUMLのほうが実用的。

780 ：デフォルトの名無しさん：2007/08/15(水) 15:00:26

そもそもUMLは記述に便利な仕様としてエロイ人が決めただけであって、そのとおりにしないと動かないようなプログラム言語とは違うんだから適当なとこを取り入れるぐらいでちょうど（　｀ー´）いいんじゃネーノ？

781 ：デフォルトの名無しさん：2007/08/15(水) 23:31:31

>>777
でも、本質的な回答は、「お前の責任で自由に決めろ」だよ。
「オブジェクト指向で作らなければならない」「UMLを使わなくてはならない」
なんていう、「誰かが決めてくれた規則」なんてのは本質的な知識ではないから、
いずれ（知識や経験が深まるにつれ）瓦解する宿命にあった知識だよ。

782 ：デフォルトの名無しさん：2007/08/16(木) 11:52:18

「いっちょ○○でやってみっか！」
くらいのノリでいいんじゃない

783 ：デフォルトの名無しさん：2007/08/16(木) 18:23:48

難しく思うのは難しく考えてるからだ

784 ：デフォルトの名無しさん：2007/08/16(木) 18:24:28

>>783
考え無しに突っ切られると死ねる

785 ：デフォルトの名無しさん：2007/08/18(土) 06:32:58

そしてみんないなる

786 ：デフォルトの名無しさん：2007/08/20(月) 13:49:45

住人的推薦図書はどれ？
ただし尼で買えるの限定

787 ：デフォルトの名無しさん：2007/09/24(月) 02:55:50

いなる

788 ：デフォルトの名無しさん：2007/10/03(水) 03:01:41

○×ゲームの簡単なクラス図作成の課題が出て
一応他の方のものとか見させて頂いたんですけど
皆ほぼ素人なんで
ここの住人的にはどんな風になりますでしょうか

ネットワークを利用するとかではなくて普通に交代で操作する
程度の奴なんですが

789 ：デフォルトの名無しさん：2007/10/11(木) 23:33:09

本を買いたい。
今のところ目をつけているのは、UML2.0クイックリファレンス（オライリー）と独習UML（翔泳社）。

値段は前者のほうが安い。
でも後者にはCD-ROMがついている。中身はどうやらUML描画ツールらしい。

どっちが良いんだろう？

790 ：デフォルトの名無しさん：2007/10/12(金) 03:29:45

つJUDE

791 ：デフォルトの名無しさん：2007/10/25(木) 23:20:38

Linuxで複数のプログラムが絡み合って作業するものを作ってるんですが、
初めてUMLを勉強がてら導入しようかと思ってます。

それらのプログラムは定期的に自動実行されて、
外部から人が操作するようなことは基本的にありません。
結果を人間が確認するということはあります。

こういう場合ってユースケース図は描くもんなんでしょうか。
アクター自体がないから描かない？

792 ：デフォルトの名無しさん：2007/10/26(金) 01:35:27

処理フローとユースケースと間違えてるのでは？
今作ろうとしているシステムがアウトプットするものを
欲しがっている人やシステムがアクタ
自動実行するアーキテクチャが良いかどうかは
ユースケースの検討後にわかって来ること

793 ：791：2007/10/26(金) 10:56:54

>>792
処理フローとユースケースは区別ついてると思うのですが、
色々調べるとまずはユースケース図を描きましょうとあるので、
やろうと思ったんですがどうにもアクターが出てこないんです。
プログラム同士でのやり取りがあるので、
個別のプログラムをアクターとできなくもないんですが、
そうするとシステムの枠の中にもアクターがでてきてしまい、
という感じになってしまうんですね。

これはプログラムの実装が先に頭にあるせいかもしれません。

外部システムなどはアクターにできると読んだので、
個別のプログラムもアクターにできるものかと思ったんですが、
その複数のプログラムを一塊で内部システムなんですよね。

例えば
1) メールを1分に1回送信するプログラム
2) 1)がちゃんと走っているか確認し続けるプログラム
が同時に走っているとして、
こんな時にはユースケース図はどうするんでしょうか。
ユースケース図なんて要らない？
それとも、1)と2)を作ると決めてかかっている時点で、
設計の考え方として手順が間違っていますか。

794 ：デフォルトの名無しさん：2007/10/26(金) 12:23:09

とりあえず、アクタ=運用者かなんかにしとけばいんじゃね？
cronのスケジュールしたり、ヘルスチェックでアラートあがったとき
それ見て対処する人いるはずだし

795 ：デフォルトの名無しさん：2007/10/26(金) 18:52:44

>>793
UMLはシステムの理解を助けるためのものでシステムを記述するためのものじゃないから
それぞれの図は必要に応じて使用するんだそうな

796 ：デフォルトの名無しさん：2007/10/26(金) 20:02:00

>>792

アクターは、ざっくり言えば
・対象のシステムに含まれない
・対象のシステムに関与する(利用する等)
なので、

1と2を「対象のシステム」とするならば
例えばSMTPサーバ(1が送信する先)はアクターになりうる。

また、2で確認した結果、ログを出すとか、エラーの時には
警告のメールを出すとか、何らかのアクションがあるはずなので
(あるいはその出したログを見る管理者がいる、とか)
このあたりのシステム外の要素もアクターになりうる。

あってますか？

797 ：791：2007/10/27(土) 00:32:25

皆さんレスありがとうございます。
管理者だとか外に出せるものを外に出して、
おかげさまで、なんとなく描き始められました。

798 ：デフォルトの名無しさん：2007/11/05(月) 23:47:08

>>796
実務的に言えばアクターは「人」でいいよ。
組織があり、人がいて、その人が何をするのかっつーのを基準に会社のビジネスを捕らえるのがコツだな。

まぁ客は往々にして、複雑怪奇なものが好きだから、
どういう風に作ったなんて言わないけどねｗｗｗｗｗｗｗｗｗｗｗ

799 ：デフォルトの名無しさん：2007/11/18(日) 18:42:45

擬人化だいすき日本人が
なぜかアクターの概念にはてこずる不思議

800 ：デフォルトの名無しさん：2007/11/18(日) 19:10:00

EA とかだと、アイコンは全部カスタマイズしてしまえるから、
全オブジェクト萌え化したい誘惑に駆られるな。
ただ、それが会社で出す資料に、間違えて混ざるとまずい。

801 ：デフォルトの名無しさん：2007/11/18(日) 21:15:40

ああそうか
あの棒人間が無機質的すぎるのか

802 ：デフォルトの名無しさん：2007/11/22(木) 23:40:24

棒って言われるとどきどきしちゃう

803 ：デフォルトの名無しさん：2007/12/08(土) 17:46:16

>>766
遅レスすまんが、Core Foundationのソースコード

804 ：デフォルトの名無しさん：2007/12/23(日) 20:08:19

UMLモデリングツールのパターンウィーバーって評判どう？

805 ：デフォルトの名無しさん：2007/12/25(火) 03:40:20

>>804

スレ違い
http://pc11.2ch.net/test/read.cgi/tech/1147499933/

806 ：デフォルトの名無しさん：2008/02/11(月) 01:55:04

初めて設計の仕事頼まれたんだけど
クラス図とかシーケンス図とか、どういうファイルで出せばいいんでしょうか？
jpgファイルで出すのは非常識？一番楽なんだけど…

807 ：デフォルトの名無しさん：2008/02/11(月) 02:32:32

>>806
学生の俺としてはVisioで出せばいいかもと思ってる
最悪画像でもベクター画像だな(wmfとかemfとかepsとか)

808 ：デフォルトの名無しさん：2008/02/11(月) 08:02:28

>>806

漏れはExcelで出せという指定があったので
シートに画像貼り付けて出したらダメだとよ

809 ：デフォルトの名無しさん：2008/02/11(月) 10:47:51

>>806
ツールで作成した元ファイルでいいんでね？　クライアントからの指定があればそれに合わせる。

810 ：デフォルトの名無しさん：2008/02/11(月) 19:27:41

>>807
>>808
>>809
ありがとうございます
デフォになってるような形式は無いみたいですね
jpgではまずいようなのでまともな形式ではき出せるツールを探してみます

811 ：デフォルトの名無しさん：2008/02/12(火) 06:49:13

Excelでどうやって、クラス図とかかくんだ？？？
たしかに図は書けるが・・・

812 ：デフォルトの名無しさん：2008/02/12(火) 06:51:31

svgだろ、常考
と思ったら、おれが使ってるJUDEは svg出せなかった orz

813 ：デフォルトの名無しさん：2008/02/13(水) 00:24:19

確かに、テーブル設計とかはExcel のほうが楽だから。
Excel　で作ったテーブル設計図から、XMI でクラスモデルを
吐かせるとかできれば便利なのに。

814 ：デフォルトの名無しさん：2008/03/21(金) 11:00:29

仕事中に勉強なんてするなよ。
給料泥棒だぞ。

815 ：デフォルトの名無しさん：2008/03/21(金) 15:48:04

勉強しなきゃ仕事にならんのだったら有給労働となるべきだが

816 ：デフォルトの名無しさん：2008/04/12(土) 13:09:38

>>815
いいこというね！

817 ：デフォルトの名無しさん：2008/04/12(土) 18:26:43

会社によっては、必要な技能を習得する期間さえ見積もりに入れてるってのに。
仕事時間以外で勉強って、ありえないな。

818 ：デフォルトの名無しさん：2008/04/12(土) 18:37:34

必要な技能を持ち合わせていない人たちも多いけどな

819 ：デフォルトの名無しさん：2008/04/18(金) 16:02:42

>>817
その言い方だと、見積もりに入れない会社もあるってことですね。

820 ：デフォルトの名無しさん：2008/04/18(金) 23:54:03

> 仕事時間以外で勉強って、ありえないな。

こんな社員ばっかの会社って悲惨だな。

821 ：デフォルトの名無しさん：2008/04/19(土) 00:08:00

向上心の有無と、業務時間外の業務のための勉強を
一緒に論じるのはおかしいぞ。

822 ：デフォルトの名無しさん：2008/04/19(土) 01:47:09

金くれるんなら勉強してやるよ、って、
いかにもサラリーマン根性って感じだね。
仕事のためにしか新しいことを吸収しようともしない。

823 ：デフォルトの名無しさん：2008/04/19(土) 01:58:13

楽するための苦労（努力）は必要だと思いますっ。
その上で、それを予算に計上させるのがBetterなんだと思いますっ。

って、思ったんですが個人的に勉強しててもプロジェクトとして
みた場合、構成員が個人的に勉強しないような人はｺﾞﾛｺﾞﾛいるからなぁ。
そういう前提だとわからないでもないかな。

さて、どっちの人なんだろ。

824 ：デフォルトの名無しさん：2008/04/19(土) 02:29:40

>>823
だから、業務なんだから業務に必要なことは計上するのが当然だって。
絶対必要な残業して残業代つかなかったらおかしいだろ？

が、発端である>>813のように「便利」程度であれば、
いかに便利であるか、それによって人月がどれだけ削減できるか等を
明確にしなければ「そういうのは個人的にやって」と言われるのも当然。
(>>814も元々この視点から言ったんだろうし)

で、スキル向上のために自己学習するのは社会人として当然。
もちろんやってない奴もいるが、
少なくとも>>817は>>822の思うような意味では言ってない。

と釣りにﾏｼﾞレス。

825 ：デフォルトの名無しさん：2008/04/19(土) 11:55:25

UMLって金もらって勉強するような性格のものじゃないだろ。
そんな特別なものじゃないよな。
ワードとエクセルでドキュメント書くので、
その勉強時間にお金くださいって言ってるようなもの。

826 ：デフォルトの名無しさん：2008/04/19(土) 11:59:04

>>825
確かに。
特殊な技術や専門性の高い知識は相応の見積もりを出していいが、
ここで議論しているのはUMLについて。
勝手な都合でUMLでドキュメント作りますって言っておいて、
その勉強時間にお客さんがお金出してね、って、
客を馬鹿にするにも程がある。

827 ：デフォルトの名無しさん：2008/04/19(土) 12:01:29

>>826
そういうことなら、最初から新人教育の時にでも、
UMLぐらいはやっておくべきだね。
プログラマーやSEの常識的知識としてね。

828 ：デフォルトの名無しさん：2008/04/19(土) 13:32:29

UML勉強すんのに、その分工数上乗せ！？
どこの会社だよ。ふざけすぎじゃないか？

829 ：デフォルトの名無しさん：2008/04/19(土) 13:52:32

そういや、ここがUMLのスレだと今更思い出した

830 ：デフォルトの名無しさん：2008/04/19(土) 22:14:18

だって発注元へ提出の設計図のフォーマットがUMLなんだもん

831 ：デフォルトの名無しさん：2008/04/23(水) 09:39:34

UMLでC++のソースからクラス図を書こうとしています。おもいっきり初心者の質問だと思うのですが、
friend関数って、どういう記号で表せば良いですか？
+がpublic、-がprivate、#がproctedだと思うのですが、friend関数の表し方がわかりません。
よろしくお願いします。

832 ：デフォルトの名無しさん：2008/04/23(水) 14:15:54

ノートでいいんじゃねの？

833 ：デフォルトの名無しさん：2008/04/24(木) 02:33:31

オブジェクト指向でfriendなんてママ子使わねえよ。

834 ：デフォルトの名無しさん：2008/04/24(木) 09:50:46

設計が悪いとfriend使わざるをえなくなる。

835 ：デフォルトの名無しさん：2008/04/24(木) 12:08:43

friend関数があると、設計が悪いというのはなぜですか？
２つのクラスにまたがって何かをする関数とか、あとoperator<<とかは
friendにするしかない関数じゃないですか？

836 ：デフォルトの名無しさん：2008/04/24(木) 12:12:53

# 二つのクラスにまたがって何かをする関数
# あとoperator<<とかはfriendにするしかない関数じゃないですか？
そうなの？
構文上できないなら仕方ないけど，いろいろ考えた結果そうするしかないというのは悪癖に近いものだと思うぞ？

837 ：デフォルトの名無しさん：2008/04/24(木) 14:01:06

どうもはじめまして。
勉強しょってなんですか？
その会社ふざけてるんじゃないですか？

838 ：デフォルトの名無しさん：2008/04/24(木) 14:39:42

>>835
なぜUMLにfriend関数の表記法がないのかを考えたことないだろ。

839 ：デフォルトの名無しさん：2008/04/24(木) 14:47:22

まあC++だからな。
CにあれこれOOP構造を追加して更に参照型やらも追加して何でも許した結果・・・
辻褄合わせでfriendも生まれたルーズ言語仕様。

840 ：デフォルトの名無しさん：2008/04/24(木) 18:43:22

UMLをコード生成やリバース解析目的で使うなら、
言語毎の拡張はあったほうが現実的ではある。

C++型のfriendはパッケージスコープ型のfriendより厳密だとは思うが、
大方の評価は少々やりすぎだと思われているのか追随する言語は少ない。

841 ：デフォルトの名無しさん：2008/04/24(木) 21:12:33

UMLを日本語に訳してみ

842 ：デフォルトの名無しさん：2008/04/24(木) 21:15:22

未確認言語
Unidentified Mysterious Language

843 ：デフォルトの名無しさん：2008/04/24(木) 22:00:31

>>831
べつに、こんなんでいいでしょ
<<friend>>

ちなみにfriendを非難する者の大半は、
その本質的な存在価値を理解してない。
gotoを盲目的に非難すること全くおなじ。

844 ：デフォルトの名無しさん：2008/04/24(木) 23:22:35

ちなみにfriendを擁護する者の大半は、
その本質的な弊害を無視して手を抜いている。
gotoを知った風に支持することと全くおなじ。

845 ：デフォルトの名無しさん：2008/04/25(金) 00:02:03

>>844
馬鹿め。
friendを擁護したり、gotoを支持する人間などおよそ存在せん。
適切に使える人間と適切に使えない人間がいるだけだ。

伝聞でfriendを非難する人間は、実際にfriendをつかうことはなかろう。
弊害を自分の身をもって経験せず、そもそも使いかたもわからんくせに
その言葉にどれほどの説得力が伴うのかね？

846 ：デフォルトの名無しさん：2008/04/25(金) 00:22:27

パッケージの、I/Fの内側だけで完結するなら別にfriend使おうがどうでもいいよ。

847 ：デフォルトの名無しさん：2008/04/25(金) 01:18:21

>>845
>弊害を自分の身をもって経験せず
失笑ｗ

848 ：デフォルトの名無しさん：2008/04/25(金) 07:56:38

失笑（しっしょう）
「笑いが止まること、さげすんで笑うこと」という意味ではなく、「おかしさをこらえることができず吹き出すこと」。さげすんで笑うことは「冷笑」。

849 ：デフォルトの名無しさん：2008/04/25(金) 09:37:12

これはどっちだろうな (・∀・)ﾆﾔﾆﾔ

850 ：デフォルトの名無しさん：2008/04/25(金) 09:41:39

>>845
だって使う必要がないもーん。
無理やりfriend使って英雄気分ですか？ｗｗｗ

851 ：デフォルトの名無しさん：2008/04/26(土) 00:52:35

一応、「俺のコーヒー返せｗ」の意味だった＜失笑

852 ：デフォルトの名無しさん：2008/05/03(土) 01:43:34

>>850
必要性の判断なんてどうでもよくて、
実際使ったことがあるかどうかだろ。
しかも無理やりじゃなく、適切にだ。
ま、おのれの未経験を恥じればよい。

853 ：デフォルトの名無しさん：2008/05/15(木) 13:35:10

自民はあんたらが選挙で選んだ政党だろ。
だったらあんたらが責任とるのは当たり前。

854 ：デフォルトの名無しさん：2008/05/24(土) 03:19:43

>>646でも出てるけど
レーンをまたいでアクティビティを配置するってのは，駄目なのかな？
やっぱ細かくわけたりして，またがらないようにすべき？

見てわかればいいような気もするんだけど，
もし，またがって配置することを許してしまうと，
離れたレーンをまたぐ場合どう記述するか困っちゃうしなぁ

855 ：デフォルトの名無しさん：2008/05/24(土) 18:49:51

>>854
自己レス
またがって描くのは禁止って本に書いてあったorz

856 ：デフォルトの名無しさん：2008/05/24(土) 23:55:31

レーンまたいだら誰のアクティビティかわからなくなる。

857 ：デフォルトの名無しさん：2008/06/02(月) 00:27:29

要件分析から実装まで、ひと通りの流れを実例交じりで
参考になるような良書って何かお勧めありますか？
特に、分析から設計フェーズに移行する時の実践的な
ノウハウみたいなものが載ってる書籍みたいな。

858 ：デフォルトの名無しさん：2008/06/02(月) 13:15:32

ないね。。。

859 ：デフォルトの名無しさん：2008/06/02(月) 19:38:44

ガーンorz

860 ：デフォルトの名無しさん：2008/06/03(火) 13:35:32

おれの背中を見て学べ

861 ：デフォルトの名無しさん：2008/06/03(火) 13:44:23

立派な刺青だな
どこの業界から転職してきたのやら

862 ：デフォルトの名無しさん：2008/06/03(火) 15:16:24

多分、アメリカ海兵隊。

863 ：デフォルトの名無しさん：2008/06/03(火) 15:32:45

教えてもらうな。見て盗め。

864 ：デフォルトの名無しさん：2008/06/03(火) 15:43:47

それは著作権違反でくぁwせdrftgyふじこlp

865 ：デフォルトの名無しさん：2008/06/03(火) 18:16:53

だから何をみればいいのさ！

866 ：デフォルトの名無しさん：2008/06/04(水) 15:43:31

ところで俺を見てくれ、こいつをどう思う?

867 ：デフォルトの名無しさん：2008/06/04(水) 16:08:27

おわってるな

868 ：デフォルトの名無しさん：2008/06/04(水) 18:41:05

UMLもう終わりか

869 ：デフォルトの名無しさん：2008/06/08(日) 19:00:53

で、どうしろと？

870 ：デフォルトの名無しさん：2008/06/14(土) 10:41:43

フローチャートからソースを書いて、Ｃ言語の考え方を覚えてきた

同じように、umlでソースを考えながら
クラス設計の考え方を、体系的に学習したい

umlで問題、解答例のソースが多めに載ったお勧めの参考書教えれ
言語はなんでもいい
仕様は調べる

871 ：デフォルトの名無しさん：2008/06/14(土) 10:55:50

本屋いってこい。

872 ：デフォルトの名無しさん：2008/06/14(土) 11:01:48

適当に探したけどみつからなかったのさ

873 ：デフォルトの名無しさん：2008/06/14(土) 11:05:52

過去ログ嫁

874 ：デフォルトの名無しさん：2008/06/14(土) 11:13:27

意地悪しないでくださぃぃいいいい

875 ：デフォルトの名無しさん：2008/06/14(土) 13:15:30

過去ログ読んでも特に条件に合致した書籍がないんだが

876 ：デフォルトの名無しさん：2008/06/14(土) 14:06:53

>>870
設計を実装の言語条件でドウコウしようと言うのは、恥ずべき行為だw
UMLと１対１で対応して実装までできる言語は存在していないし、その必要も無いからな。

877 ：デフォルトの名無しさん：2008/06/14(土) 16:22:10

>>876
理由を教えてくれ

878 ：デフォルトの名無しさん：2008/06/14(土) 19:04:38

分析で抽出された多重継承の取り扱い方とかを設計のフェーズで決まるんじゃないの？

879 ：デフォルトの名無しさん：2008/06/14(土) 20:12:39

>>877
家の設計図に施工会社の指定をしないのと同じw

880 ：デフォルトの名無しさん：2008/06/14(土) 21:16:04

>>879
ＵＭＬの書籍として、ある特定の言語で解答例を示した書籍はないということか？

881 ：デフォルトの名無しさん：2008/06/14(土) 21:29:46

UMLとJava(1.4までの）との相性はいい。
オブジェクト内やオブジェクト間の関係や振る舞いを記述するのがUMLなので、
UMLから生成できる言語コードはクラスやメソッドなどのスケルトンになる。
メソッドの中の具体的なコードは対象外なのよ。
プログラムのステップと1対1なんて構造以前のFORTRANくらいしか記憶にない。

882 ：デフォルトの名無しさん：2008/06/14(土) 21:32:48

構造化以前
化が抜けてた。つまり FORTRAN77より古いやつね。

883 ：デフォルトの名無しさん：2008/06/15(日) 10:13:56

無いのか・・・

くそう、クラス間の関係の考え方を定着させるためには
良いツールだと思ったんだけどなあ

抽象化プログラミング入門みたく、問いと解答が一対一なやつがあったらいいのに

884 ：デフォルトの名無しさん：2008/06/15(日) 13:14:23

常識的に考えて、シーケンス図やコラボレーション図じゃないの。

885 ：デフォルトの名無しさん：2008/06/15(日) 13:54:33

そうですね、クラス図とかよりは
そっちの方を求めています。

886 ：デフォルトの名無しさん：2008/06/15(日) 13:59:49

あと、クラス間の関係の「考え方」を学ぶには、デザインパターンの勉強をしたほうがいいのでは。
デザインパターン（やその適用）を表現する手段としてはUMLは便利。

887 ：デフォルトの名無しさん：2008/06/15(日) 14:21:51

なるほど、調べてみます。
色々とお世話になりました。

888 ：デフォルトの名無しさん：2008/06/15(日) 14:39:02

ガラッと見方を変えるとワークフロー記述言語というアプローチもあるかな。
アクティビティ図やステートチャートでそのままプログラミングするイメージ。
BPELやXOML(net WF用)が一応使える。

889 ：デフォルトの名無しさん：2008/06/15(日) 17:46:08

>>883
ってか、どこの工程の話だ？
要件定義や基本設計では実装は意識しちゃだめ、
ってのが定説なんだが。
どこぞの言語と、って奈良、専門書のたくさん置いてある本屋に行って、
片っぱしから当たれば、数件まわればそこそこ見つかる。
設計フェーズ以降の話の本だ。Java、C++、VBなどなど。

ここまで教えたんだから、あとは自分の足で探して味噌。

890 ：デフォルトの名無しさん：2008/06/15(日) 17:48:05

amazon行くのに足はいらん

891 ：デフォルトの名無しさん：2008/06/15(日) 18:31:44

幽霊でも探せる！

892 ：デフォルトの名無しさん：2008/06/15(日) 20:32:29

でも買うには、お足が必要だよん

893 ：デフォルトの名無しさん：2008/06/16(月) 08:09:24

でお前らは書きあがった図が、よりよい物であること、要求を満たしている事をどうやって保障してるんだ？
お絵かきツールで図を描くだけだったら誰にでも出来るぞ

894 ：デフォルトの名無しさん：2008/06/16(月) 12:43:34

>>889
設計フェーズ以降の本です。
もしよろしければ、お勧めの本を教えてください。

一応、本は2冊買いました。
良い本等はわからないので分かりやすそうなものですが。
（オブジェクトデザイン、抽象化プログラミング入門）

ＵＭＬを何故学習しようとしている理由は
自分の欠点として、クラスが上手く作れない、クラスを読むのが遅い
ということがあります。
そこで手に取ったＵＭＬ本での設計図＋ソースを読んだとき
すごく分かりやすいと感じたからです。

なので、問題形式でＵＭＬ
解答としてソースという本を探しています。

＋αでデザインパターンやＵＭＬを多く知れればさらに嬉しいです。

895 ：デフォルトの名無しさん：2008/06/16(月) 12:45:19

スレ違いであれば申し訳ない。

896 ：デフォルトの名無しさん：2008/06/16(月) 14:38:49

>>894
設計といっても範囲が広い。
ソースとの対応うんぬんというところを見ると詳細設計以下のフェーズと見ていいのだろうか？
デザインパターンのような典型的なものでない限りは、
純粋なUMLでそのレベルのロジックを表現するのは無理がある。
言語特有の概念とUMLのミスマッチは大きいことがあるから初心者だとそこがつらいかもしれない。

897 ：デフォルトの名無しさん：2008/06/17(火) 10:45:46

もう実装済みオブジェクトの内部動作説明資料を作ろうと思うんですが、
何図で書くのがいいですかね？
ステートマシン図かシーケンス図だと思いますが。

898 ：デフォルトの名無しさん：2008/06/17(火) 10:53:08

どの言語よ
手続き型ならデータフローでいいんでね？

899 ：デフォルトの名無しさん：2008/06/17(火) 10:56:13

>>898
C# です。

900 ：デフォルトの名無しさん：2008/06/17(火) 11:26:34

内部動作の「何」を書くか決めたら >>897 の解が自ずとでるんじゃないか？

901 ：デフォルトの名無しさん：2008/06/20(金) 04:04:31

ＵＭＴＰのUMLモデリング技能認定試験L1T2を受験しようと思うのだけど、
これって合格したら履歴書の資格欄に書いていいんだよね？

902 ：デフォルトの名無しさん：2008/06/24(火) 14:15:26

パッケージがネストされている場合、親子のパッケージは双方向に依存していると考えればよいでしょうか?

903 ：デフォルトの名無しさん：2008/06/27(金) 21:34:42

904 ：デフォルトの名無しさん：2008/06/30(月) 23:02:03

>>857
実践UMLはよんだ？　責務の割当について、オブジェクトデザインより分かり
やすく書いてあると思う。

>>870
オープンソースをリバースエンジニアリングする。俺の経験では、
デバッガを使って、オブジェクト図を起こすのが最も勉強になった。

905 ：デフォルトの名無しさん：2008/07/01(火) 00:39:35

デバッガ使ってオブジェクト図とか、どんなマゾだよw

906 ：デフォルトの名無しさん：2008/07/21(月) 13:35:36

クラス図の依存関係の破線矢印と、関連の実践矢印って、何が違うのだ？

907 ：デフォルトの名無しさん：2008/07/21(月) 16:56:02

>>906
依存は、これがないと生きて行けない奴の事を指す。
関連は、これも使ってるけど、念のため。って事。

908 ：デフォルトの名無しさん：2008/07/27(日) 12:02:57

脚本作成技術とＵＭＬとの対応

登場人物や組織・物等とその関係性　　　　クラス図

各シーンでの人物間関係性の推移シナリオ　シーケンス図

紙芝居的表現　　　　　　　　　　　　　　コラボレーション図

・・・こんなもんでどう？

909 ：デフォルトの名無しさん：2008/08/02(土) 16:23:03

紙芝居は、オブジェクト図じゃないかな？

910 ：デフォルトの名無しさん：2008/08/03(日) 19:12:34

まあオブジェクト図は実名出してるし
スナップ写真みたいなもんだけどね。

でも紙芝居ってシーンを区切って
時系列にそって説明するから
説明が書いてあるのがコラボレーション図で
だれかが説明するのがオブジェクト図ってとこ？

オブジェクト図にメッセージを追加して
コミュニケーション図に発展させる事はあるから
定義としては微妙だね。

911 ：デフォルトの名無しさん：2008/08/13(水) 16:03:03

クラス図で汎化と実現の違いがわかんね。
インタフェースと実装クラスを汎化の矢印で結んだらダメなのだろうか。

実現が汎化の一種ならまだわかるんだが
メタモデルを調べてみると実現は汎化ではなく依存の一種らしい
うーむ

912 ：デフォルトの名無しさん：2008/08/14(木) 16:46:29

>>911
インタフェース（の仕様）に合わせて関数なりメソッドなりメッセージをつくるわけだから依存でいいと思うよ。

913 ：デフォルトの名無しさん：2008/08/14(木) 17:50:11

■■みんなでサイトつくろうぜｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ■■
「お前ら一緒にサイト作ろうぜｗｗｗｗｗｗｗｗｗｗ」
「２ちゃん越えるサイト作ろうぜｗｗｗｗ」
「仕事無いんだ･･････」
「やろうぜ！」
「みんなでサイトつくろうぜｗｗｗｗｗｗｗｗｗｗ」
http://gacco.o0o0.jp/
http://yutori.2ch.net/test/read.cgi/news4vip/1218673130/
http://ex14.vip2ch.com/test/read.cgi/part4vip/1218612197/
興味沸いたらきてください！
======================!! 人材募集中 !!======================
■プログラムを組んでくれる人
　＊サーバー側
　　言語はRubyかPerlの予定ですが、Perlが有力候補。
　　・チャット
　　　定期的にクライアントから着信があり、それに対して更新されたチャットのメッセージを返信する程度の能力。じゃなくて機能。
　　　通信するときのフォーマットは未定。
　　・ログイン・アカウント管理
　　　ログイン認証、各アカウントの点数などの管理。データベースは未定。
　　・お絵描き
　　　未定。とりあえず鯖に負担がかからない程度にたまに画像を送信してあげるって感じで
　＊クライアント側
　　はっきり言って俺もわからね。Ajaxだとかflashだとかjavaだとか。
■機能提案(正しくは人材ではなく、意見?)
　「こんな機能があったら良い!」「こうするともっと楽しくなる!」などの意見募集中。
　挨拶とか気にせずスレにどんどん書き込んでくれればおk
■デザイン
　サイトのデザインを考えてくれる人、作ってくれる人募集中。
　できればphotoshop illustrator使える人(プロジェクト共有しやすいので)

914 ：デフォルトの名無しさん：2008/08/15(金) 19:27:09

>>912
実現ではあるが汎化ではないような関係ってありうるのかな

915 ：デフォルトの名無しさん：2008/09/10(水) 21:54:18

きちんと書けていたUMLを自己流に修正するうちの先輩をどうにかしてくれ・・・。
「オレUML分からないから」とかいいながら勝手にいじりやがって。
奴が直した部分だけ、メンバは意味読み間違えるし、意味は分かっても情報量が少なすぎだし、
顧客は微妙顔をしてみるし。
挙げ句の果てに「これじゃ分からないから、説明を追加してください」って注文されて、設計書は分厚くなるし。
奴がサブリーダをやる前までの開発フェーズは平和だったのになぁ。

916 ：デフォルトの名無しさん：2008/09/11(木) 09:51:28

ｼｬﾝｶｰﾙﾉｺﾄｶｰｰｰｰｰｰｰｰｰｰｰｰ

917 ：デフォルトの名無しさん：2008/09/11(木) 22:40:42

クラス間の関連が２本ある場合って、特に制約がなければ
同じオブジェクトにも違うオブジェクトにもなりうるってことでいいのかな？

例えば、クラスAとクラスBで関連が２本引かれてて、
A→Bの1つの関連の多重度が3、もう１つの関連が1とする。

するとオブジェクト図では
a1→b1
　→b2
→b3
→b4
もありうるし、
a1⇒b1（2本の関連）
　→b2
→b3
もありうるんだよね？

918 ：デフォルトの名無しさん：2008/09/12(金) 01:29:05

>>917
クラス図に動的な関係を記述してる時点で間違い。

919 ：デフォルトの名無しさん：2008/09/12(金) 20:27:41

>>918
いや、動的じゃねぇし。
関連が２本あるばあいのオブジェクト図としてありうるパターンを聞いてるんだって

920 ：デフォルトの名無しさん：2008/09/12(金) 22:06:51

関連が2本というのも間違いじゃ？

分けるべきクラスを、無理に一つにしているのかもね。

921 ：デフォルトの名無しさん：2008/09/13(土) 02:57:20

オブジェクト図なら、２本にせずに２つ書けばいいし、
クラス図なら、根本的に間違ってるって事さ。

922 ：豆レンジャー：2008/09/13(土) 12:15:48

>>921
ごめん、関連が２本以上あるクラス図なんていくらでもあるんだけど…
関連って関連クラスのことではないよ？

┌──┐　 ┌──┐
│A　　├─┤B　　│
│　　　├─┤　　　│
└──┘　 └──┘
↑これクラス図なんだけど、こういう形は根本的に間違ってるって事なのか？

923 ：デフォルトの名無しさん：2008/09/13(土) 13:33:33

例えばクラスAに納品先住所と請求先住所があってともに住所クラス（B)と
関連があるケースのことだろうか？
ER図なんかではありがちなパターンだけど、表記上はBダッシュを作って、
注釈で同じリレーションであることを示すことが多いかな。

924 ：デフォルトの名無しさん：2008/09/13(土) 14:16:52

同じクラス間に２本以上の関連があると言う事は、どちらのクラスも役割が複数あると言う事。
もうその時点でクラス分けが間違ってる。

納品先住所と請求先住所の線を２本引く意味が分からない。
住所と言う基本クラスに納品先と請求先という派生クラスがあるって事だろ？
どうやったら２本引く必要があるのかわからない。

925 ：デフォルトの名無しさん：2008/09/14(日) 10:45:12

例えば航空券の予約システムは（モデリングの本質からの参照だけど）、
定期便クラスと地区クラスに２本関連がありますよ。
目的地と出発地というロール名です。

その場合のオブジェクト図って特に制約が記述されてない限り
目的地＝出発地となることもあるわけで（つまり、地区オブジェクト１つリンク２つ）。

つまり>>917の言ってることは合ってる。

926 ：デフォルトの名無しさん：2008/09/14(日) 14:14:54

出発地、目的地、中継地１、２、３…

その時点で２つとする事自体が間違いじゃね？

927 ：デフォルトの名無しさん：2008/09/14(日) 14:21:48

設計する際にクラス図、シーケンス図は基本として、
各メソッドのロジックを記載するにはどの図を使えばいいですか？
UMLではなく普通にフローチャートを書いた方がいいのでしょうか？

928 ：デフォルトの名無しさん：2008/09/14(日) 20:59:10

>>927
UMLでもチャートは書けるでしょ。
アクティビティー図とか、オブジェクト図とか好きなの使えば？

929 ：デフォルトの名無しさん：2008/09/17(水) 00:32:11

>>925
オブジェクト図は、同じオブジェクト同士で2本以上のリンクはありえないお

930 ：デフォルトの名無しさん：2008/09/17(水) 01:27:25

え？　同じリンク辿ればいいのになんで２本もいるの？

931 ：デフォルトの名無しさん：2008/10/01(水) 20:31:17

>>929
オブジェクト図はインスタンスの関連を表した物
クラス図の段階でリンクが２つあれば、オブジェクト図でもリンクが２つは許される
このぐらい常識だろう、その前にロールや関連が理解出来ていないのか？

932 ：デフォルトの名無しさん：2008/10/02(木) 02:27:17

２本書く意味が分からない。

933 ：デフォルトの名無しさん：2008/10/02(木) 20:15:40

>>932
1本で良いよな....
>>926を見て思うけど、無理にくっつけちゃったのかなぁ？

934 ：931：2008/10/02(木) 21:36:17

何が分からないの良く分からんが、簡単に複数リンク(関連)を説明すると
まず、基本だが表記として複数リンクは許されている

次に>>924
>同じクラス間に２本以上の関連があると言う事は、どちらのクラスも役割が複数あると言う事。
>もうその時点でクラス分けが間違ってる。
基本的に、ロール（役割)はクラスにしてはいけない
（一生一つの役割しか持たないのなら、クラスにしてもかまわないが、変わらない事を保証することが難しい）
例えば、銀行の役割（ロール)として、　・お金を貸す(預金)　・お金を借りる（住宅ローンなど）
がある、これをロール(役割)ごとにクラスを作ろうとは思わないだろう
まず銀行のクラスを作って、そのロールとして預金やローンを定義すると思うが
（現実世界で、１つの物をモデリングの世界で同じ実態を２つのクラスで表現するのはおかしいだろう）
これに、個人を加え銀行との関係を考えると、２つのリンクが存在するのがモデリングとして正しくないか？（預金とローンでは関連の意味が違う）

多分、分かり難いのは、複数リンクが上位の概念モデルでしか出てこない為だと思う
モデリングを進めて行くと、関連がクラスになる、上の銀行と個人だと間に口座クラスやローン契約クラスが現れ
単一のリンクに変わって行く、あと多くの書籍で単一リンクのみ書かれているから複数リンクに違和感も出る

935 ：デフォルトの名無しさん：2008/10/18(土) 23:44:13

そんな、書き方に凝っても意味無いだろ、
と最近思うようになってきた。
おら、こんな風にもUMLで書けるんだぜ、
おまいらちゃんと実装しろよ、みたいなｗ

936 ：デフォルトの名無しさん：2008/10/22(水) 21:16:12

書き方に凝るんじゃなくて設計に凝るもんだろjk

937 ：931：2008/10/22(水) 23:16:38

凝っている凝ってないは主観だがら、どうでもいいが
せめて、人の書いた物は理解出来ないと

938 ：デフォルトの名無しさん：2008/10/24(金) 18:50:51

だから、やたらとテク使ってるぜ！みたいな、
悪い意味で凝り凝りのモデル書くのが正統だ、
みたいに押しつけられても困るってことだ。

939 ：デフォルトの名無しさん：2008/10/25(土) 02:14:35

UML凝っても、実装時の言語じゃその通りに記述出来ないから、無意味なんだよ♪

940 ：デフォルトの名無しさん：2008/10/25(土) 07:27:28

可読性重視ならシンプルなモデルこそいいモデル。

941 ：デフォルトの名無しさん：2008/10/25(土) 10:06:49

例外はどうやってモデリングすればいいの？

942 ：デフォルトの名無しさん：2008/10/25(土) 11:07:12

ぷっ、関連を２つ張るのが凝っているモデルなんだｗ
”底辺”がんばれよ～ｗ

943 ：デフォルトの名無しさん：2008/10/25(土) 14:33:15

コーダーだから、しょうがないじゃん、コーダーに関連が複数あるクラス図なんて渡さないし

しかしコイツらは、最初に「クラス図なら、根本的に間違ってる」とか書いて
自分が間違っていることに気づくと、こんどは
「書き方に凝っても意味無い」・「書き方に凝るんじゃなくて設計に凝るもんだ」だと
本当に、ダメぷりが良くわかる　orz

944 ：デフォルトの名無しさん：2008/10/25(土) 14:46:22

>>943
表記ルールでの話と、実際の運用に耐えうるクラス図のあり方と混同してないか？
表記ルールでは正しくとも、実運用で混乱をきたす書き方はダメだろって話を延々としてるだけだし。

945 ：デフォルトの名無しさん：2008/10/25(土) 15:18:47

それぐらいも、わからん奴に運用やらすなｗ

表記だけが正しいんじゃなく、意味があるだろう「ロール」と「関連」
それを理解出来ないで、今度は
「表記ルールでは正しくとも、実運用で混乱をきたす書き方はダメ」
本当にコーダーはダメダメだな orz

946 ：デフォルトの名無しさん：2008/10/25(土) 20:28:33

粒ぞろいの有能なマだけでプロジェクトが遂行出来るなんて夢物語だからな。
誰もが誤解無く読み取れる設計図を心がけるのは設計者のつとめだろ。
自己満足な高度で難解な設計をする奴は会社に取ってもマイナスでしかない。

947 ：デフォルトの名無しさん：2008/10/25(土) 20:45:40

正論だな

948 ：デフォルトの名無しさん：2008/10/25(土) 23:17:00

>>945
”底辺”に何を言ってもしょうがないぞ
UMLは文章と同じで、書くより読む方がはるかに簡単だけど
それすら勉強しないから”底辺”なんだしｗ　(スレタイも見ていないんじゃないかｗ)

それと、運用メンバーとプロジェクトメンバーの区別も出来ないかｗ

949 ：デフォルトの名無しさん：2008/10/26(日) 03:37:25

人を見下した発言してる時点でたかが知れてる。
>>945が底辺扱いしてる連中は、その道を大分前に通過してるんだよ。

950 ：デフォルトの名無しさん：2008/10/26(日) 12:18:20

糞スレレベルが臨界点を突破しました。
乗組員は速やかにマ板へ退避して下さい。

951 ：デフォルトの名無しさん：2008/11/29(土) 00:57:20

>>949
他人がどれほど理解できないかを理解する時間的余裕が出るには年輪が必要なんだよ

952 ：デフォルトの名無しさん：2008/12/07(日) 13:27:15

少し前にも話題に上がってましたが
<<friend>>の表記と多重度の記述の仕方についてお聞きしたい事があります。uml初学者です。
値を保持するクラスAがあってオブジェクトの生成と削除をクラスBに
一括してやらせようとしてます。そこでまずクラス図として

<<create>><<destroy>><<friend>>
A←－－－－－－－－－－－－－－B
0..*　　　　　　　　　　　　　　　　　　　　 1

のように記述しました。ただ依存を用いると多重度が書けないと言う事実を
知り、分からなくなりました。
というのも<<friend>≫は依存の時のみに使うステレオタイプだったと記憶していて
反面クラスBは生成したクラスAオブジェクトのリストを持っているので多重度は
書きたいなぁと思ったからです。

例えば依存じゃなくて関連を使って記述したらまずいでしょうか?
<<create>><<destroy>><<friend>>
A←──────────────B
0..*　　　　　　　　　　　　　　　　　　　　　1

何故<<friend>>が必要になったかというとC++を使ってまして、クラスAは一定のクラス（クラスB)でしか
オブジェクトの生成・削除をされたくなく、コンストラクタとデストラクタをプライベートで記述したために
クラスBをクラスAのオブジェクトの生成・削除ができるようにfriend classとして記述したという次第です。
なにぶんクラス図から実装を考えるレベルではなく、コードからクラス図を記述しようとしているので色々
矛盾していたり、勘違いしている部分(C++についても)があると思うのですが、なにかヒントをいただけたら
幸いです。

953 ：デフォルトの名無しさん：2008/12/07(日) 14:43:38

>>952
根本が狂ってるんじゃどうしようもないさw
依存と言う言葉は「実体は知らない」程度の意味なのに、
おまいの言ってる依存は、頼り切ってるどころか相互乗り入れしているし。

954 ：デフォルトの名無しさん：2008/12/07(日) 15:47:14

根本から狂ってますか...orz
依存というのは薄い結びつきなんですね、、ありがとうございます
ではこの場合のリレーションシップはどれが適当でしょうか?
いわれたことを踏まえて自分はコンポジションと予想したのですが

それと、ちょっと見方を変えて
クラス図は設計図の一種(コーディングの前段階)なんだから
<<create>><<destroy>>
A────────────◆B
0..*　　　　　　　　　　　　　　　　　　1

としておいて、これをC++で実装する事にしたら結局friend使う事になっちゃった
ということにしておくという考え方はありでしょうか；

955 ：デフォルトの名無しさん：2008/12/08(月) 23:11:14

ぷ　・・・　　。　　　　　iii ~ !

956 ：【中吉】【788円】株価【45】：2009/01/01(木) 21:54:17

どうよ

957 ：デフォルトの名無しさん：2009/01/26(月) 15:40:23

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1422563484
どうよ

958 ：デフォルトの名無しさん：2009/02/06(金) 00:09:31

>>934
ロール（業務）をクラス化しておいて、
管理クラス（銀行）にぶら下げる様な設計はありだと思うが？

実際、イベント処理系はその手の設計が多い。

とか、かこうと思ったらかなりのカメレスにorz

959 ：デフォルトの名無しさん：2009/02/14(土) 19:19:58

E-mail欄ってほとんどE-mail欄の役割は果たしてないよね。

960 ：デフォルトの名無しさん：2009/02/16(月) 07:27:11

むしろ使っちゃだめだし

961 ：デフォルトの名無しさん：2009/02/19(木) 14:25:51

じゃなんであるの？

962 ：デフォルトの名無しさん：2009/02/28(土) 03:50:47

sageるためじゃね？ｗ

963 ：934：2009/03/03(火) 22:57:08

>>958
>ロール（業務）をクラス化しておいて、
>管理クラス（銀行）にぶら下げる様な設計はありだと思うが？
どんな設計をしているか分からんが、基本的に
残高と出金・入金金額はいつでも、同じトランザクションで
行なわなければならない、それを別クラスにするのは、俺はおかしいと思う
まっ、Mementoパターンとかで、履歴を管理したい場合は別クラスでも
いいかもしれないけど

964 ：デフォルトの名無しさん：2009/03/05(木) 19:40:59

>>963
それはトランザクションで一つのロールとならないか？

965 ：934：2009/03/05(木) 21:33:38

>>964
ロールになる事も有ると思うが、それで？

966 ：デフォルトの名無しさん：2009/03/06(金) 04:22:33

>>965
別に

967 ：デフォルトの名無しさん：2009/03/17(火) 17:28:15

畑を荒らしてるのはモグラじゃないよ。
モグラの穴を利用しているネズミだよ。
モグラは肉食だから野菜は食べないよ。

968 ：あぼーん：あぼーん

あぼーん

969 ：デフォルトの名無しさん：2009/03/18(水) 08:07:18

宣伝乙としか