UML皆でお勉強しよ♪ 多重度２

1 ：ニュージーランド漁夫：02/08/24 16:23

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

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

前スレ（１）：http://pc3.2ch.net/test/read.cgi/tech/980236172/

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

　　　(V)∧_∧(V)
　　　　ヽ(･ω･)ノ　　ﾌｫｯﾌｫｯﾌｫｯ
.　　　　/　 /
　　　　ノ￣ゝ

.　　　　　　　　　 (V)∧_∧(V)
　　　　　　　　　　ヽ( 　　)ノ　　ﾌｫｯﾌｫｯﾌｫｯﾌｫｯ
.　　　　　　　　　　　/　 /
　　　　　　　.......... ノ￣ゝ

3 ：デフォルトの名無しさん：02/08/24 17:46

前スレ950
>クラス図だけど、俺はまずＥＲ図を作って、それを元に
>クラス図を起こすのが手っ取り早いんじゃないかと思っているのだが、
>その辺はどう？

>クラス図の継承とＥＲ図のリレーショナル型ＤＢモデルってのは、
>結局正規化という点ですごく共通する部分がある気がするんで。
>だめすか？

前スレ956
>>クラス図とER図両方作るにしても、普通は順番が逆。
>>手っ取り早いと感じるのは単にER図に慣れているからでは?
>確かにそれはある。が、ＥＲはＲＤＢの考え方からして割と機械的に
>できていくところがある。それに対し、クラス図はちょっとしたセンス
>がものをいう。で、基本はＥＲから出発し、より実装に近いかたちで
>クラス図を作るってことなんですが。

>あと、それほど有用であると思えない理由から、
>あまりユースケース図やシナリオも書かないので。
>（最初はお絵かきで業務の流れをまとめてお客に示す）

みなみなの意見キボンヌ

4 ：後藤：02/08/24 21:44

その方法じゃ、
エンティティ・オブジェクトしか
設計できてないんじゃないかな？

メソッドはストアドプロシージャで実装、
ってのも良くあるパターンなので、
OOもどきDB中心設計とひそかに名付けてます(笑
その次のステップに踏み込む気概があれば、いいんだけどねぇ

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

>>4
>その方法じゃ、
>エンティティ・オブジェクトしか
>設計できてないんじゃないかな？

そうです。まずエンティティの洗い出しをして、そのあとメソッドを
実装していくって流れです。
エンティティの洗い出しの基礎をＥＲに求めるということです。

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

設計していくうちに、(正規化とかとは直接関係なく)、
より本質的、あるいは効率的なデータ項目の組(あえてエンティティともデータ構造とも呼ばない)が、
分かってしまう事があるよね？

その場合、再設計ですね(当たり前の事だけど。

「まずＥＲ図」で出てきたエンティティってのと、
OOのモデルってのと、
本質的/効率的なデータ項目の組
との違いを無視して、
「この方法で逝っとけばとりあえず仕事が終わる」、
っていう方法に見えるんだけどぉー…

7 ：デフォルトの名無しさん：02/08/24 22:26

おれっちはちょっと違うなぁ。
所詮ＤＢはＲＤＢなんでしょっぱなからＯＯ分析は効率が悪すぎる。
なので、エンティティオブジェクトだけで不足なら、作るし、
必要ならＤＢ（ＥＲ図も触る）。
そんな感じ。

ＯＯＤＢが普及して気軽に使えるようにならん限り、ＯＯ分析と
設計にギャップがありありにありんすよ。

8 ：デフォルトの名無しさん：02/08/24 22:31

＞本質的/効率的なデータ項目の組
＞との違いを無視して、
＞「この方法で逝っとけばとりあえず仕事が終わる」、
＞っていう方法に見えるんだけどぉー…

よーわからん、業務アプリ屋なんで効率的なデータ項目っていのうは
常にＤＢに縛られる。
プロ一本辺りのデータ効率なんて、糞の上に付いたハエの糞程度の扱いだな。

誤解めされるな、アルゴリズムは別もんだけどよ。

9 ：デフォルトの名無しさん：02/08/24 22:34

ＯＯＡ/ＯＯＤの特徴は、
　　概念モデルと実装の分離が可能である事
としつこく書いてみるテスト

ＤＢ屋は、概念モデルをＤＢに乗せてるんじゃないのかぁ？

10 ：CODASYL萎え：02/08/24 22:36

むしろ、
ＤＢ屋は、帳票や入力データを正規化したものを、
ＤＢにのせてるだけじゃないかー？

11 ：7=8：02/08/24 22:41

>>10
正直に言ってしまうとこれに近い。てか作業自体はこれだ。

12 ：7=8：02/08/24 22:46

>>9
馬鹿だから感じが掴めない。
もしお手数でなければ、COBOL上がりの、C++使い、
腐れ業務アプリ屋に、愛の手を差し伸べてみるのはどーだ？
神様が祝福してくれるかどうかは分からんが、俺は感謝するぞ。

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

>>9
RDBだと、概念スキーマと外部スキーマを分離できれば充分じゃないか？
業務アプリ屋さんなら、RDBと一心同体でアプリ設計してればいいんじゃないの？

14 ：デフォルトの名無しさん：02/08/25 01:27

うーん、俺も業務アプリ屋だけど、基本的にはクラス設計してからテーブルに
落とし込むよ。クラス設計ができて永続化するべきクラスが特定できたら
それをDBに落とし込むのは大概決まった手順でできてしまうから。

もちろん、それでDB的に最高の設計ができるかというとそれは無理だけど、
実用的に問題ないレベルにはできる。でもこういうやり方がベストだなんて
誰にも言えないから、特に問題を感じてないのならそれでいいんじゃないの?

OODBは使ったことがあるけど、メンテナンスは地獄。とてもおすすめできない。
でもキャッシングのメカニズムは魅力だな。

15 ：デフォルトの名無しさん：02/08/25 02:49

オレはER図からクラス図作成に反対派だな。

ER図はクラスに比べると柔軟性に欠ける気がするし、ER図に
欠陥があるともろにクラス図に影響する気がする。
UMLの姿勢はいろいろな視点を持って設計することにある様に
個人的に思うから、やはりお互いをチェックできる様に別々に
設計して設計漏れを無くすようにした方がいい気がする。

OODBはツール周りが整備されてこないと普及も発展もないだろね。

16 ：モナ吉：02/08/25 06:22

スレさんおはよう～ ( ･∀･)ﾉ

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

>>14
>もちろん、それでDB的に最高の設計ができるかというとそれは無理だけど、
>実用的に問題ないレベルにはできる。でもこういうやり方がベストだなんて
>誰にも言えないから、特に問題を感じてないのならそれでいいんじゃないの?

ＤＢはやはり物理的なデータの格納場所であって、そこはそこである程度の
パフォーマンスは確保すべきと思うんだが。

>>15
>ER図はクラスに比べると柔軟性に欠ける気がするし、ER図に
>欠陥があるともろにクラス図に影響する気がする。
>UMLの姿勢はいろいろな視点を持って設計することにある様に
>個人的に思うから、やはりお互いをチェックできる様に別々に
>設計して設計漏れを無くすようにした方がいい気がする。

あくまでクラスとＥＲを同列にしようとは思わない。
ＥＲの世界でそこそこのものを作ったら、それでおしまい。
そのＥＲからより実装に近い、処理のパフォーマンスを考えた構成を
クラス図で作るってことなんだが。

ちなみに、俺も基本的には業務アプリ専門です。

18 ：デフォルトの名無しさん：02/08/25 12:09

>>14
>うーん、俺も業務アプリ屋だけど、基本的にはクラス設計してからテーブルに
>落とし込むよ。クラス設計ができて永続化するべきクラスが特定できたら
>それをDBに落とし込むのは大概決まった手順でできてしまうから。

この貴方のマッピング手順をここで教えてください。

19 ：デフォルトの名無しさん：02/08/25 15:12

Rational Roseで設計すればクラスからDDL生成できるYO!

20 ：952：02/08/26 23:57

>>3
> 前スレ950
> >クラス図の継承とＥＲ図のリレーショナル型ＤＢモデルってのは、
> >結局正規化という点ですごく共通する部分がある気がするんで。

ここがよくわからんのですが・・・

21 ：デフォルトの名無しさん：02/08/27 00:41

>>18
クラスの属性をカラムに落とし込むのはほとんど機械的にできるよね?
あとはクラス定義に主キーに当たるものがない場合はSEQUENCEなどで
主キーカラムを追加します。

関連は、1対Nなら基本的にN側に1側を特定するための外部キーを設ける。
N対Nなら関連テーブルを作るのが自然ですね。

問題は基底クラスと派生クラスですね。基本的にはアプリ側の都合で
基底クラス用のテーブル+派生クラスの差分テーブルを作る場合もあるし、
それぞれ別のテーブルを作ることもある。とはいっても、エンティティ
クラスはあまり複雑な継承をしないように気をつけるけど。

22 ：7=8：02/08/27 04:09

>>21
おぉお。本格的にＯＯ分析をそのまま使ってるんだ。

正規化云々のところは求めないけど、パフォーマンス的に大丈夫？
問題になったりしない？
あと、データの整合性チェックとか､気になる。

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

起きがけに頭の体操でﾏﾁﾞﾚｽしてみる

> >クラス図の継承とＥＲ図のリレーショナル型ＤＢモデルってのは、
> >結局正規化という点ですごく共通する部分がある気がするんで。

美味しいフレーズなんだけど、一応細かい指摘をしとくと、
(1)RDBの第一正規形では、他のドメインの直積(x,y)とかべき集合{a,b,c} を排除せよ　って事になってるけど、
　オブジェクト指向ではオブジェクトの要素が、他の複合オブジェクトだったり、
　オブジェクトのコレクションであってもオッケだよね。(※設計の良し悪しはべつとして。)

　RDBのオブジェクト指向拡張では、「ネストした表」つう名前で直積っぽいものを導入してるし、
　非第一正規形は簡単に正規化できるから、第一正規形は無視してオッケなんだけど。

24 ：デフォルトの名無しさん：02/08/27 05:12

(2)第二正規形(連結キーの一部に部分関数従属する属性の除去)、
　第三正規形(推移的関数従属性の除去)、ってあたりは、
　この手順に従えば、オブジェクトのモデリングをﾏｼﾞﾒにやらずとも、
　データをオブジェクトっぽいまとまりに分割できるって事かな？

　でも、それはただの　第三正規形のテーブル　であって、
　現実の事象のモデリングとは違うよね。
　扱うべきデータ項目が増えて、正規化やり直し！テーブル追加！
　てな事態にも柔軟に対応できる、変化しにくいモデルを求める事こそ重要な気がする。

25 ：7=8：02/08/27 05:19

>>23-24
(　´ⅴ｀)ノおはよう。

面白いこと言ってるような気もするけど、どっちの立場に立ってるのか
はっきり読み取れない。
クラス設計優先→ＥＲ派？

あと21さんってネタ元だと思うのですが、コテハンにしてもらえると有りがたい。

26 ：デフォルトの名無しさん：02/08/27 05:25

RDBの列には、重複がないけど、
OOで FlyWeightパターンとか(もっといい例あるかもしれんが忘れた)適用してメモリの節約していない場合には、
同じ値のオブジェクトが山のようにできてもオッケだよね。
かといって、RDBみたく MultiSet理論とつながりがあるわけでもないし。

27 ：23=24：02/08/27 05:30

ｵﾊﾖ
クラス設計優先、RDB使いたくないからORマッピング自力で開拓派、です。
面白がられてしまったって事は、私寝ぼけてるのかなぁー

28 ：7=8：02/08/27 06:02

>>27
興味深いという言う意味の「面白い」なんで、ご理解ください。

29 ：強いて言うならＥＲ派：02/08/27 12:34

ネタ元です。
>あと21さんってネタ元だと思うのですが、コテハンにしてもらえると有りがたい。
すつれい。
>>3
>>5
>>17（21は違う）

>面白いこと言ってるような気もするけど、どっちの立場に立ってるのか
>はっきり読み取れない。
>クラス設計優先→ＥＲ派？

強いて言うならＥＲ派かな。

>>クラス図の継承とＥＲ図のリレーショナル型ＤＢモデルってのは、
>>結局正規化という点ですごく共通する部分がある気がするんで。
>ここがよくわからんのですが・・・

スーパークラスの抽出（派生）と第二正規形（部分従属列の分離）です。

30 ：強いて言うならＥＲ派：02/08/27 12:36

>(2)第二正規形(連結キーの一部に部分関数従属する属性の除去)、
>　第三正規形(推移的関数従属性の除去)、ってあたりは、
>　この手順に従えば、オブジェクトのモデリングをﾏｼﾞﾒにやらずとも、
>　データをオブジェクトっぽいまとまりに分割できるって事かな？

その通りです。

>　でも、それはただの　第三正規形のテーブル　であって、
>　現実の事象のモデリングとは違うよね。

うん、違う。で、より実装に近いモデリングをそこから行うということです。
（>>3、>>17）

>　扱うべきデータ項目が増えて、正規化やり直し！テーブル追加！

データ項目が増えたら、ＥＲ修正→クラス修正かな。

31 ：デフォルトの名無しさん：02/08/28 13:40

最近UMLを始めたのですが、いくつか記述の方法が
解らない事があります。
誰か教えてくれないでしょうか？

１）
詳細設計の段階です。

クラス間に集約の関係があり、これをコンテナクラスで実装しようと
考えています。
で、このコンテナクラスの実体を属性(変数)として親側に持たせる
つもりですが、、、

この場合、クラス図の属性フィールドにこの属性(変数)を記述しても、
いいのでしょうか？

というのも、世の中の参考書を見ると、こういった場合は定義自体な
かったので、です。

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

すみません、続きです。

２）
汎化と特化は、区別して記述した方がいいでしょうか？

記号としては、どちらも中抜き三角（△）の矢印になると思い
ますが、それぞれのステレオタイプは分けないと
いけないのでしょうか？

ちなみに、ツールはVisioを使っています。

すみません、誰かお教え下さいませ。。

33 ：デフォルトの名無しさん：02/08/28 13:46

失礼、ageるの忘れてました。

34 ：デフォルトの名無しさん：02/08/28 20:24

>>31
フォワードエンジニアリングとか考えてます?
でなければ必要ないでしょう。普通は関連のロール名を変数名にマッピング
します。

>>32
汎化と特化って基底クラスから見るか派生クラスから見るかで違うだけで
同じ物だと思いますが。で、△矢印は派生クラスから基底クラスに向けて
書きますね。

35 ：デフォルトの名無しさん：02/08/28 22:34

なんか、経験者が書き込むと質が高まるなぁ。
>>34さん、これからもよろしく。

36 ：U ◆tFsGiu0c ：02/08/29 01:27

>>22
前スレ954( その他)=14=21=34です。
コテハンついでにトリップつけてみました。うまくいくかな?

>正規化云々のところは求めないけど、パフォーマンス的に大丈夫？
問題になったりしない？

Rdbの経験もそれなりあるので、問題になるようなテーブル構造にはならない
ように気をつけてます。問題はテーブル構造より検索処理で、OODBライクに
クラスの関連をたどっていくとまともなパフォーマンスがでないので、その
辺はSQLを工夫して対応しています。それとDBアクセス部分は専用クラス群に
閉じ込めてビジネスロジック層やプレゼンテーション層では意識しなくて済む
ようにしています。

>あと、データの整合性チェックとか､気になる。

整合性チェックはRdbのレベルでやるのであまり気にしなくていいと思います
けど。それともなんか問題出てきますか?

37 ：7=8：02/08/29 10:47

出来るんだぁ。と言うのが素朴な感想。

＞Rdbの経験もそれなりあるので、問題になるようなテーブル構造にはならない
＞ように気をつけてます。
ならば、E-R図から入ったほうが安全だな。と言うのが、僕の今のところの結論。

てか、まだ不慣れ時にＯＯ分析を試みてわけわかんなくなって、それ以降ＥＲから
クラス抽出する事にしてます。

DBアクセス部分を専用クラスに群に閉じ込めるって言うのは、設計レベルのオブジェクト
で、分析レベルではないと思うっすよ。ビジネスロジック層云々も同様に。

整合性に関しては、クラスから分析はじめると、整合性チェックがＲＤＢとずれるので、
よっこらしょ、どっこいしょ、と手数が増えそうな気がしたもので。

忘却の彼方に飛んでいってるから、具体例出せないんだけど、
この辺りが問題になってＥＲ図からクラスを作る事にしたんです。

38 ：U ◆tFsGiu0c ：02/08/29 13:47

>>37
>DBアクセス部分を専用クラスに群に閉じ込めるって言うのは、設計レベルのオブジェクト
で、分析レベルではないと思うっすよ。ビジネスロジック層云々も同様に。

私のやり方だとDBに落とす時点で設計レベルの話になってしまうんですよ。
分析モデルを実装の都合にあわせて設計モデルをつくるということになると、
こういったことも考える必要がありますよね。

>整合性に関しては、クラスから分析はじめると、整合性チェックがＲＤＢとずれるので、
よっこらしょ、どっこいしょ、と手数が増えそうな気がしたもので。

んークラス図から導出できる整合性チェックって何がありますかね。
コンポジション使ってるときくらいしか思い浮かばないんですが。

39 ：デフォルトの名無しさん：02/08/30 10:55

今までクラスの設計を脳内＋我流の図だけでやっておったのですが、UML覚えたらもっと簡単になる？
昔作ったやつとか忘れてくるから困ってるんだよ

40 ：デフォルトの名無しさん：02/08/30 22:56

>>39
> 今までクラスの設計を脳内＋我流の図だけでやっておったのですが、

これがホントにまともにできていたのなら
UML覚えるくらい簡単だろう

41 ：usecae：02/09/05 22:21

ｱｹﾞ

42 ： ◆k/Ubp.Kg ：02/09/08 21:44

前スレの方が上に来てるんで、ageてみる。

43 ：デフォルトの名無しさん：02/09/08 21:46

>>42
サンキューパー

44 ：名無しさん＠Ｅｍａｃｓ：02/09/09 14:50

webシステムをUMLで設計したいのですが、いいサイトある？

45 ：デフォルトの名無しさん：02/09/14 14:48

>>44
そういや、ぴあそん本でその手のがあったな

46 ：U ◆tFsGiu0c ：02/09/14 16:30

http://www.amazon.co.jp/exec/obidos/ASIN/4894712768/ref=pd_bxgy_text_1/250-5321596-3885854

これ? 会社に置いてあったので、今度読もうと思ってた。

47 ：デフォルトの名無しさん：02/09/14 18:17

ASPベースのWebアプリケーションを、UML使う方法論で設計～実装するために、
UMLの拡張機能使って、ASP用のアイコンとかstereotype作ったつう話だっけ？

48 ：デフォルトの名無しさん：02/09/14 18:23

天狼（Sirius) - 02/09/13 23:30:25
電子メールアドレス:[email protected]

コメント:
meteor閣下、お久しぶりです。天狼です。閣下をお助けすべく参りました。
＞荒らし野郎へこの愚民が！！わが同士を愚弄するとはいい度胸をしているな！！
社会のゴミだとか社会の底辺でオナニーしているとか、無教養さ丸出しの書き込みだ
な！！メアドも公開しない貴様こそ社会の底辺で自慰をしている唾棄すべき輩といえ
ようぞ！！さて、貴様は悔しかったら行動を起こしてみろとかほざいているが、貴様
は行動を起こせるのか？多分起こせまい。所詮、貧困な語彙でしか罵倒のできぬ貴様
だろうからな！！あまり我らを甘く見ないほうが身のためだぞ！！

http://www.geocities.co.jp/HeartLand-Sakura/1939/geobook.html

49 ：デフォルトの名無しさん：02/09/15 03:08

おまいらこのサイト知ってる？
http://www.umlstyle.org/

初心者も熟練者も一見の価値ありと思うんだが。
特にUML導入予定か導入後まもないプロジェクトで、モデリング規約で悩んでる
人にはかなり役立ちそうだけど、どうよ？

50 ：デフォルトの名無しさん：02/09/16 21:33

そろそろシルバー受けるか・・また落ちるんだろうな。

51 ：デフォルトの名無しさん：02/09/23 18:31

>>50 ｶﾞﾝｶﾞﾚ

52 ：鬱だ：02/09/25 19:28

シルバー落ちたYO！
話になんねーYO！

ここに問題書き込んだからみんな参考にしてくれ・・・。
http://music.2ch.net/test/read.cgi/legend/1023017547/

53 ：デフォルトの名無しさん：02/09/29 17:27

良スレはあげなあかんよ？

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

コード生成できないUMLツールってやっぱりダメダメですか？
PatternWeaverってお手軽で"よいなぁ～"って思ってたんだけど、
今のところお絵かきしか出来ないのを使ってる俺は厨房確定？
http://www.tech-arts.co.jp/product/product.html
は、"頑張ってるぜ！"感じなんだけど・・・。

55 ：　：02/10/01 03:13

UMLツールなんかいらんよ。
手書き＋デジカメにしる。
油彩だとなお良し。

56 ：デフォルトの名無しさん：02/10/01 04:41

>>55
アフォか。修正しづらいだろ。
砂と指で書くんだよ。砂の代わりに粘土を使っても可。

57 ：デフォルトの名無しさん：02/10/01 05:29

GOLDげと。
GOLD問題、質問うけつけます。

58 ：デフォルトの名無しさん：02/10/01 23:18

>>54
Java に偏るが、Together か MagicDraw + eclipse かねえ。
http://www.togethersoft.com/
http://www.magicdraw.com/
http://www.eclipse.org/

59 ：U ◆tFsGiu0c ：02/10/02 00:45

>>54
コード生成はあまり使わない。既存のプログラムを解析したり、プログラム書いてから
クラス図を起こしたりする時はリバースエンジニアリングは重宝するけどね。

60 ：デフォルトの名無しさん：02/10/02 02:32

>>58-59
レスありがとう。
リバースエンジニアリングのほうが、利用頻度が高いんですね。
参考になりました。

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

October 15th

EclipseUML
EclipseUML
EclipseUML
EclipseUML

62 ：U ◆CZtFsGiu0c ：02/10/03 22:16

>>60
いやいや世の中にはUMLで記述したモデルをプログラミングレスで動かそう
としている人たちもいますから、そう一概にはいえないでしょう。また、
Togetherみたいにラウンドトリップ開発が可能なら、そもそもモデリング
とコーディングを区別しなくてもいいかもね。
＃TogetherはまだUMLツールしか使ったことがないけど

63 ：デフォルトの名無しさん：02/10/08 02:20

ＥＡまんせー

64 ：　：02/10/08 22:49

>>63
高すぎるよ・・・

65 ：デフォルトの名無しさん：02/10/12 21:19

UML Press Vol.2記念あげ。

66 ：デフォルトの名無しさん：02/10/12 21:50

>>64
安すぎるの間違いじゃ

67 ：デフォルトの名無しさん：02/10/12 22:23

先生、普通の関連と集約をどう使い分ければいいのか良く分かりません！
例えばCDocumentとCMainWindowはただの関連ですか、それともCMainWindowはCDocumentの一部と考えるべきですか。
オシエテ下さい！

68 ：デフォルトの名無しさん：02/10/12 22:36

>>67
迷ったら関連にしとけば間違いない。
UMLモデリングのエッセンスにも書いてあるけど、
集約と関連を分ける明確な基準はないようです。

69 ：67：02/10/12 22:38

先生、有難うございました。
ノーベル賞にまた一歩近づきますた！！

70 ：デフォルトの名無しさん：02/10/17 22:48

RationalRoseなどのリバースエンジニアリング機能では
継承や集約などの矢印も自動で付与されて表示されるんでしょうか？
自動できれいに配置などもされたらすごく楽なんだけど…

71 ：デフォルトの名無しさん：02/10/18 00:03

みんなＥＡ使えよ

72 ：なんも調べないでｶｷｺ：02/10/18 01:38

ＥＡとは何でつか

73 ：デフォルトの名無しさん：02/10/18 02:42

>>72
http://www.sparxsystems.com.au/

74 ：デフォルトの名無しさん：02/10/18 21:58

>>73
体験版使ってみましたが結構よさげですね。

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

これなんぼ？

76 ：デフォルトの名無しさん：02/10/18 22:32

>>75
http://www.sparxsystems.com.au/ea_purchase.htm

77 ：デフォルトの名無しさん：02/10/18 22:35

>>75
激安ネット販売

裏情報を言うと
30日過ぎたら再インストールしたらまた使えちゃう

78 ：デフォルトの名無しさん：02/10/22 21:44

プッ

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

ArgoUML使ってる人いますか？
Attributeの順序を変えるのってできないのでしょうか。
できないとなると使いにくいのですが。

80 ：デフォルトの名無しさん：02/10/25 16:26

ちゃんと最後のコードに落としてるところまで
書いてある参考書ってないですかね？

81 ：デフォルトの名無しさん：02/10/26 16:44

>>80
自分で考えるのは嫌いか？

82 ：デフォルトの名無しさん：02/10/26 17:13

>>80
組み込みUML本
IIOS本の実践編

83 ：デフォルトの名無しさん：02/10/26 17:23

つかまだまだ
エンティティ・オブジェクトのスタブ・コード(変数と空メソッドのクラス定義)作るのがやっと、
てな環境が多いと思われ

84 ：デフォルトの名無しさん：02/10/26 17:37

UMLでメソッド・コード生成するには、
ベンダー固有のスクリプト言語でメソッド記述しなきゃならないしねぇー。
>>80 は、どこの環境つかって、どの分野のアプリを作ってるの？

85 ：デフォルトの名無しさん：02/10/26 17:38

>>80
「ユースケース入門」にあるロバストネス図を用いたプロセスが、
UML を用いた分析/設計/実装の段階をシームレスに繋ぐ手法として見るところがある。

86 ：デフォルトの名無しさん：02/10/26 17:42

ごめん、その本買ってないんだけど、
どんな感じでしょうか？

とりあえず、UMLを活用して、手書きコードを作る話ですよね？

87 ：デフォルトの名無しさん：02/10/26 17:49

「ユースケース入門―ユーザマニュアルからプログラムを作る」

いくつかあるUMLで規定されているダイアグラムの中で、
ユースケースを中心に実装まで行うICONIXアプローチについて解説。
クラスや相互作用を識別するのに有効な、ロバストネス分析についても解説する。
---

88 ：デフォルトの名無しさん：02/10/26 17:49

ソフトウェア開発において、対象をオブジェクト指向型の言語に
書き換える作業を行うためにUMLが広く使用されているが、
現実にコーディングできるレベルのオブジェクトに落とし込むのは
なかなか困難な作業だ。UMLと実際のコーディング作業には隔たりがあり、
このギャップを独自の手法で埋めていくケースをよく耳にする。
本書では、より現場に適した手法として、UMLをカスタマイズした手法を
解説している。これはUMLを拡張するとともに、対象の分析に開発時間の
多くを消費してしまうような愚行をできるだけ避けるように考えられている。

まず、問題領域に存在する主な抽象物を特定するためのドメインモデリング
を解説。つづいて新しいオブジェクトを識別し、ユースケースの流れを記述する
ユースケースモデリング、さらに、どのオブジェクトがどのユースケースに
働きかけるか、ユーザアクションの結果としてシステムがどの機能を実行するか
を理解するためのロバスト図、そしてどのクラスがどのメソッドの責任を持つか
を判断するシーケンス図、最後に、属性とメソッドを持ったクラス図からコードを
得るまでを解説している。

本書では有価証券取引のシステムを例題にとり、各章での解説は
このシステムをもとに行っている。初心者向けのUML解説書にありがちな
汎用性の低いケースの解説よりも実用的で柔軟な解説に仕上がっており、
非常に使いやすい。

UML自体は抽象的な概念であるため、実装まで生かすことができず
いきなりコーディングしてしまうなどということもあるだろう。
そういう人は本書を利用してみてほしい。実装まで落とし込む手法が
きっとつかめるだろう。

89 ：デフォルトの名無しさん：02/10/26 20:18

本書ってどの本よ(藁

90 ：デフォルトの名無しさん：02/10/27 03:04

EAって日本語対応してるの？MagicDrawよりいいかなぁ？？？

91 ：デフォルトの名無しさん：02/10/27 06:41

>>90

自分は
ttp://www.kjps.net/user/kouno/ea/japan.html
あたりを参考に、日本語が表示されるようにして使ってる

92 ：>>63=>>73：02/10/28 01:49

EAが浸透してきて嬉しい限りだ

93 ：デフォルトの名無しさん：02/10/28 20:49

安い。俺にも買えそうだ。
EAﾏﾝｾｰ

94 ：デフォルトの名無しさん：02/10/29 07:14

EAの3.50で起動直後(プロジェクト開いた直後)に
落ちる人いませんか？
WindowsXPだと発生するのか？(Windows2000では発生しない)

95 ：デフォルトの名無しさん：02/10/31 09:46

>>79
クラスのプロパティを表示して
右側にAttributeが並んでる欄で
対象のAttributeを右クリックで上げ下げできます。

operationもいっしょ。

96 ：63：02/11/01 20:52

http://member.nifty.ne.jp/kondoumh/software/bc.html

日本語で軽いのがいいならこういうのもあるよ

97 ：79：02/11/02 01:34

>>95
ありがとう。
それにしても重い・・・

98 ：名無しさん＠Ｅｍａｃｓ：02/11/02 21:49

http://www.iioss.org
ってどうですか？

99 ：82：02/11/02 22:01

○executableUML本
×組み込みUML本

鬱詩

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

>>98
使えない。

101 ：わかっててあえて問う：02/11/02 23:11

なぜ使えない？

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

iioss使うんだったら、PertternWeaverで良いような気がする。
PertternWeaverを使って解説している本も多いし。

103 ：デフォルトの名無しさん：02/11/04 01:46

PetternWeaverって汎化とか点線の関連が書けなくない？
お試し版だからかな。

104 ：デフォルトの名無しさん：02/11/16 00:31

executableUMLだけでシステムができますた。
もうプログラマーなんて必要ありません。これからは上級SEだけで市場をまかなえます。

105 ：デフォルトの名無しさん：02/11/17 02:38

>>104
詳細キボンヌ。おながいします。

106 ：デフォルトの名無しさん：02/11/17 03:05

>>104
MDAっすか？

107 ：デフォルトの名無しさん：02/11/17 07:59

OMGジャパン「OMG認定UML技術者資格試験プログラム」を発表
2003年9月にUML技術者試験スタートへ
ttp://www.omgj.org/news/releases/2002/1106/

ずいぶん先の話だけど・・・

108 ：デフォルトの名無しさん：02/11/18 18:28

TCCっていくら？
もしかして電話せんとだめ？

109 ：デフォルトの名無しさん：02/11/18 18:44

UML関連でプログラミング言語はいらないとか言ってた人がいたような…

110 ：デフォルトの名無しさん：02/11/19 06:45

UMLうざい

111 ：デフォルトの名無しさん：02/11/19 08:20

>>109
逆じゃね？
プログラムもろもろのためにUMLがあるんでしょ？

112 ：デフォルトの名無しさん：02/11/19 11:53

>108
夏から通常価格が変わってなかったら、
\1,800,000 保守料込

113 ：デフォルトの名無しさん：02/11/19 15:48

Delphiに対応してるUMLツールって
・EA
・ModelMaker
と他になんかある？

114 ：デフォルトの名無しさん：02/11/19 15:50

PatternWeaverフリー版あり

115 ：133：02/11/19 16:15

>>114
フリー版って今落とせるっけ？

あとWithClassってやつも見つけたけど書きにくい(´Д⊂

116 ：113：02/11/19 16:16

133じゃなくて113

117 ：デフォルトの名無しさん：02/11/19 21:47

アーキテクトとデベロッパーか
もってたらどっちが単価高くなるんだろ。
答えは一年後か。

118 ：デフォルトの名無しさん：02/11/28 17:07

初歩な質問でもうしわけないですが、教えてください。
UMLは、JAVAのようなオブジェクト指向な言語の設計に用いるのが一般的ですか？
Cをメインで使ってるものにとっては、有効ではないのでしょうか？

119 ：デフォルトの名無しさん：02/11/28 17:20

ところで、ＵＭＬはブロンズなら１０分でとれるな。
ということで、今日とりました。只だしよ・・・意味ないけど。
シルバーの問題、飛躍的にむずかしくない？
持ってる香具師いるの？

120 ：デフォルトの名無しさん：02/11/28 19:28

>>118
体験から言わせてもらえば、フローチャートを持ち出されるよりはマシだとおもふ。
いや、結局もう一層かますことになったんだけどね。

121 ：デフォルトの名無しさん：02/11/28 19:48

C＆構造化プログラミングでも
カプセル化されたサブモジュール間の関連やら必要な機能の考察ぐらいにはなるっしょ。

122 ：デフォルトの名無しさん：02/11/29 11:35

Describe という　jbuider 組み込みのUMLツールのお験し版
使ってるけど、高機能過ぎて java uml　オブジェクト思考わからんやつには
オススメできない。　俺はかまへんけど　いきなりあれでuml覚えるのは
結構キツイかも　

123 ：デフォルトの名無しさん：02/11/29 11:36

>118
言語には　関係ないよ　

124 ：118：02/11/29 18:43

みなさまありがとうございます。
言語にかかわらず、オブジェクト指向なプログラミングを意識すれば、
有用な手段になりうるということですね。
勉強してます。

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

Enterprise Architectいいよ！
会社に買ってもらった。
安いよ！1ライセンス100ドル前後だし。
Roseは高すぎる・・・。

操作感も良い。ちょっとUndoが弱いのが弱点だけどね。
もうVisioでUMLを書く生活には戻りたくないなぁ。

だれか、EAを使っている人いる？

126 ：デフォルトの名無しさん：02/11/30 21:17

あ、Enterprise Architectは、UMLモデラです。
一応リバース・フォワードできるらしいです。
ODBC経由でDBのスキーマを取り込めます。
ここらへんの機能はあんまり使い込んでないですが・・・。

127 ：デフォルトの名無しさん：02/12/02 12:55

>>125
>>63ですでに出てる

128 ：デフォルトの名無しさん：02/12/03 07:33

EA日本語版ｷﾀｰ!!記念age
http://www.zdnet.co.jp/enterprise/0212/02/n02.html

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

Eclipseのプラグインをきぼんぬ

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

お、日本語版がプレスに取り上げられたみたいだね。
嬉しいな。

EAユーザにしつもんですが、
分析モデルと設計モデルはどういう風に書き分けてる？
自分は、

Views
+ Dynamic View
+ 分析シーケンス図
+ 設計シーケンス図
+ Logical View
+ 分析クラス図
+ 設計クラス図

と分けているのだけど。

131 ：デフォルトの名無しさん：02/12/05 20:20

>>131

自分もほぼ同じ。強いて言えば、大概、状態図も書く必要があるので
それもDynamicViewに入れてる。

あるいは、最初のDynamicとLogicalの枠組みをはずして、
分析と設計にビューを分けるという方法もあるかと。

132 ：デフォルトの名無しさん：02/12/06 00:01

>>131
さんくす。やっぱそうするよね。

自分は状態図をクラスの下に置いてました。

パッケージA
+クラスB
+ 状態図C
+ メソッド
てな具合。
こうすると、クラスとの対応関係がわかりやすいというメリットがあるけど、
パッケージAに状態図Cに記したステートが表示されてしまうのが鬱。

なんで、パッケージにステートを表示するような仕様になっているだろうか？？？

133 ：デフォルトの名無しさん：02/12/06 06:34

>132

ダイアグラムのプロパティで、パッケージの内容を表示しないように
設定すれば、ステートは表示されない。
もちろん、他の内容も表示されないわけだが...

134 ：デフォルトの名無しさん：02/12/07 02:19

>133
そ、そりゃそうなんですけど・・・。
ステート：表示OFF
クラス、サブパッケージ：表示ON
としたいのよね・・・。

エレメントの表示設定をもっと細かく制御できると嬉しいんだけどなぁ。

135 ：デフォルトの名無しさん：02/12/07 07:55

>>134

せっかく日本語版販売サイトができたので、日本語で追加要望
投げておきました。
発売前だが、要望記入フォームがあるんだからダメってことは
ないだろう...

136 ：デフォルトの名無しさん：02/12/07 14:51

Rational買収されちゃった…

137 ：デフォルトの名無しさん：02/12/07 19:37

Together -> Bolandときて、
Rational -> IBMですか。ビックリ。
次は・・・。

138 ：デフォルトの名無しさん：02/12/07 21:05

本当にUMLツールメーカーを次々と大手が買収してるな。
Visioを買収したMicrosoftにはめちゃくちゃ遅れてるけど。

でもRationalはツールだけじゃないからな。
IBMについちゃったらRUPも薦め辛くなるかも(一部には薦め易くなるかもしれんが)

139 ：デフォルトの名無しさん：02/12/07 22:59

>138
Microsoftが進んでいるって？？？

Visioなんか使い物にならないよ。
VisioのUML機能なんて、マクロでつくったお遊びじゃん。

140 ：デフォルトの名無しさん：02/12/08 10:34

ＩＢＭ、ラショナル・ソフトウエアを約21億ドルで買収へ
　http://www.reuters.co.jp/news_article.jhtml;jsessionid=K2NCFSULQ2KSSCRBAE0CFFA?type=technologynews&StoryID=1863621

＃やれやれ

141 ：デフォルトの名無しさん：02/12/08 10:55

RupってJavaのインナークラスをどうやって表現するんでしょうか？

142 ：デフォルトの名無しさん：02/12/08 12:40

>141 意味不明。RUPは開発プロセス。
UMLって、Javaのインナークラスを・・・
てな質問の間違いだろう。

んで、これに対する答えは・・・、

わからない。（笑）
すまん。

143 ：デフォルトの名無しさん：02/12/08 14:59

まじめに考えた事ないから当て推量

・インナークラスっつうても、
　外側クラス・インスタンスへのアクセサーを持った普通のクラスなんだから、
　普通のクラスと同じ表現方法でもかまわないんとちゃうか？
・外側クラス/インスタンスへアクセスできる名前空間に所属してるっつう意味で、
　外側クラスと同名のパッケージの中にクラスを置いたら、
　インナー・クラスと解釈してソースコード生成する
　っつう仕様ならどないよ。

＃つうか、Java以外のメジャーなOO言語でインナークラスってないよね？Eiffel?

144 ：U ◆CZtFsGiu0c ：02/12/08 17:00

>>141
<<inner class>>ってステレオタイプを作ってみる:-)
意味があるかどうかわからないけどね。

145 ：デフォルトの名無しさん：02/12/10 01:04

今日なぜか、会社にRational Rose最新版があった。
なんでも中国の会社と一緒に設計するそうだ。
ＵＭＬは確実に急速に世界に広がっているようだ。

146 ：デフォルトの名無しさん：02/12/10 06:44

EAってモデルの図をPDFで出力とかできます？

147 ：デフォルトの名無しさん：02/12/10 06:49

>>146

直接PDFは不可能だが、PNGやJPG、GIFあたりの画像は可能かと。

148 ：デフォルトの名無しさん：02/12/10 11:29

誰かUMLシルバーの今期の問題持ってない？

149 ：デフォルトの名無しさん：02/12/10 12:51

ブロンズレベルの合格証が送られてきた。小さい・・・
まあ、ただで受けられる試験だからいいか。

150 ：デフォルトの名無しさん：02/12/11 01:52

>>148
前期のならある。

151 ：デフォルトの名無しさん：02/12/11 13:00

>>150
ぜひ下さい！！
[email protected]
まで送ってくれませんか？

152 ：デフォルトの名無しさん：02/12/11 14:52

EA Trialを使ってみてるのですが、
Project ExplorerにあるclassをDiagramへDrag&Dropすると
:class とobjectが張り付きます。classそのもの貼り付ける
にはどーすりゃいいんでしょう？
教えて君でｽﾏｿ

153 ：150：02/12/11 23:55

>>151
ﾒｰﾙはﾔﾀﾞな…

154 ：151：02/12/12 01:12

>>153
どうすればよいですか？

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

>152 Ctrl+D&D

156 ：135：02/12/12 07:30

>>134

返事ありました。追加予定に入れるそうなので、
そのうち機能追加されそうです。ただ、オブジェクトごとでは
なくて、ダイアグラムごと、あるいは全体で設定可能とのこと。

157 ：デフォルトの名無しさん：02/12/12 11:25

>>155 ありがと。
心置きなく製品かえるです。

158 ：デフォルトの名無しさん：02/12/13 01:17

> 156
おお。嬉しい。
これに限らず、全般的に図の表現力をアップしてほしいぞ。＞EA

159 ：デフォルトの名無しさん：02/12/14 12:39

ORMってなに？

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

EAぐらいのを秀丸程度シェアウェア料金でVectorからDLできるようにしておいたら、
皆使うんだろうか...

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

>>160
アクティベーションとかが必要無くて、一人で複数のPCにインストールできれば使う。

162 ：デフォルトの名無しさん：02/12/15 17:20

>>160
シリアルが公開されたら使う。

163 ：デフォルトの名無しさん：02/12/20 01:01

1000円ぐらいだったらどうだ？

164 ：デフォルトの名無しさん：02/12/27 18:31

UMLっていいね！
Unified Method Language!

165 ：デフォルトの名無しさん：02/12/27 21:15

今度のシルバーの問題もまたビ○オ屋だろうか

166 ：デフォルトの名無しさん：02/12/28 01:20

>>165
DVD屋だと思う。

167 ：デフォルトの名無しさん：03/01/07 21:10

UML技術者試験合格を新卒の履歴書に書いたらアフォだと思われますか？

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

別にいいんでない

169 ：デフォルトの名無しさん：03/01/08 15:31

Poseidonはどうだろう？
直感的に使えて結構高機能。IIOPとそっくりだけど、IIOPみたいに落ちたりしない。
シーケンス図にアクターが出てこないなど、少々の方言（？）はあるようだけど。
ここ見ててEAというのを使ってみたけれど、
クラス図でいちいちエクスプローラを操作しなければアトリビュートが設定できないとか、
さらに自動的にgetter/setterが生成できない(ように見える)とか、
やや使いにくい気がする。

170 ：デフォルトの名無しさん：03/01/08 16:26

>>164
x Method
o Modering

171 ：デフォルトの名無しさん：03/01/08 21:12

>>169

>クラス図でいちいちエクスプローラを操作しなければアトリビュートが設定できないとか、

これはコンテキストメニューとかショートカットキーあたりで簡単に可能。

>さらに自動的にgetter/setterが生成できない(ように見える)とか、

こっちは属性のプロパティから、設定可能ですな。

個人的には、いろいろ使ったが、EAは使いやすい気がする。
今買おうかどうか思案中。

172 ：IP記録実験：03/01/08 21:28

IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

173 ：デフォルトの名無しさん：03/01/09 02:28

しばらく実装とテストに明け暮れていてUMLから離れていたけど、EAみたいなツール出てきたんだね。
MagicDrawが話題だったころとは隔世の感さえ感じる（オーバーかな？）。
RoseかVisioか、なんて寂しく思っていたけど、EAは個人的に買ってみることにした。

もう１つ気に入ったのが、EAサイトのシンプルさ。
機能追加要求とか、シンプルながらもまとまっていて実にいい。
LANのKMもどきサイトもこんな感じにしてみたいと思ったよ。

MDAの概念は、組み込み以外にも色々と面白い応用ができそうなんで、注目してます。
executableUML本、英語学習も兼ねて買っとこう。

以上、感激ついでにカキコしちゃいました。

174 ：デフォルトの名無しさん：03/01/09 02:39

>565
もう買った。

175 ：デフォルトの名無しさん：03/01/09 02:40

ｳﾜｧｰﾝ (　｀Д´)=○)3ﾟ)∵

176 ：デフォルトの名無しさん：03/01/09 03:27

>>49
ここのurlみるべし。

177 ：デフォルトの名無しさん：03/01/09 18:26

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 138720人　発行日：2003/1/9

年末年始ボケがそろそろ収まり始めた今日このごろのひろゆきです。

そんなわけで、年末に予告したIP記録ですが実験を開始しています。

「２ちゃんねる20030107」
こんな感じで各掲示板の最下部に日付が入ってるんですが、
20030107以降になってるところはログ記録実験中ですー。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

178 ：デフォルトの名無しさん：03/01/10 00:14

というわけで、掲示板の最下部のバージョン表示が20030107a以降のやつは、
ログとり実験やってますです。
今のところ、qb,live2,tmpですね

179 ：デフォルトの名無しさん：03/01/10 09:03

>>536
だからそのサイトはなんだよ！怖いよ！恐ろしいよ！
誰か漏れの代わりに見に行ってくれ！

180 ：デフォルトの名無しさん：03/01/10 10:23

電話まだー？

181 ：デフォルトの名無しさん：03/01/10 11:00

fDUMwxQmｶﾞﾝｶﾞﾚ

182 ：デフォルトの名無しさん：03/01/10 11:31

確かに小一時間はオカシカッタ

183 ：デフォルトの名無しさん：03/01/10 12:18

2ちゃんねる　が衰退していく

あるネット関連会社の社長は、
「いずれにしても2ちゃんねるは資金が底をつけば終わり。
あまり知られていないことだが、2ちゃんねる内部関係者によると今、
大手通信会社系が調査費名目で資金提供している。
だが、それが止まれば続けてはいけないだろう」
と証言する。
2ちゃんねるが判決によって力を失った場合、
資金提供の打ち切りも予想される。

http://ascii24.com/news/reading/causebooks/2002/07/01/636911-000.html

184 ：デフォルトの名無しさん：03/01/10 12:46

>>922

そうきたら言葉はないですねぇ
俺はほとんど嘘だと思っているのでｗ　２ｃｈは

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

このままじゃ閉鎖だな　　　　　　

186 ：デフォルトの名無しさん：03/01/10 14:29

ワラタ

187 ：デフォルトの名無しさん：03/01/10 14:54

そういう次元の高い話じゃないですって・・・捨てられる以前のお話です。
てーか、これでも私「鬼女」なんですけど。

188 ：デフォルトの名無しさん：03/01/10 16:22

いよいよ終焉か

189 ：デフォルトの名無しさん：03/01/10 22:30

フリーのUML作成ツールでいいのってありませんか？

190 ：デフォルトの名無しさん：03/01/10 22:32

全部にいれてみた。

191 ：デフォルトの名無しさん：03/01/10 22:40

ウラの取れてない内部告発はもう出来ないというわけか？

192 ：デフォルトの名無しさん：03/01/11 00:00

君の責任です

193 ：デフォルトの名無しさん：03/01/11 00:08

あっ、漏れと同じ串だ

194 ：デフォルトの名無しさん：03/01/11 09:31

なんでそれが「つまり」やねん(^_^;)

195 ：デフォルトの名無しさん：03/01/11 10:06

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 139038人　発行日：2003/1/10

なにやら、連日メルマガだしてるひろゆきです。

そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。

重くなって落ちたりしてもご愛嬌ってことで。。。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

196 ：デフォルトの名無しさん：03/01/11 10:58

IPってなに？

197 ：デフォルトの名無しさん：03/01/11 11:17

>196
いんたーねっとぷろとこる

198 ：デフォルトの名無しさん：03/01/11 11:28

できるよ。こうしてP2Pの参加人口は激増するのであった。

そのうち、2chはP2P掲示板の補完的な役割を担うことになろう。

結局、前回はUNIXだったが今回はDownloadが
匿名掲示板を救うのだなあ。。。

199 ：デフォルトの名無しさん：03/01/11 12:17

【社会】2ちゃんねるが全板でIP記録を開始 3年に渡る"匿名掲示板"の歴史に幕…
http://news2.2ch.net/test/read.cgi/newsplus/1042202364/

200 ：デフォルトの名無しさん：03/01/11 12:22

　 Λ＿Λ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　ＵＭＬの話題にもどしやがれ
　（　　　　）　＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜｜　|
　（_＿）＿）

201 ：デフォルトの名無しさん：03/01/11 12:30

だからフリーでいいツールを教えてくれって何度も言っているのに・・・

202 ：デフォルトの名無しさん：03/01/11 12:48

ほほぅ

203 ：デフォルトの名無しさん：03/01/11 15:38

478 名前：　投稿日：03/01/10 20:46 ID:/I1K4Xxq
犯罪カキコは最初から論外だが
名誉毀損系のカキコが出来なくなるのがツライよなぁ・・
事実でもよほどのことがない限り有罪になっちゃう

482 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/10 20:47 ID:jWxHxvti
名誉毀損かどうかは裁判所が判断することすね。
警察の照会書で対応するかどうかは、
違法性が客観的に判断できるかどうかですね。

496 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/10 20:50 ID:jWxHxvti
＞勝手に過去ログDVD作ってヤフオクで売って
訴えられたら悲惨すよー。

529 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/10 20:56 ID:jWxHxvti
Ｑ．プロバイダー責任制限法第四条による発信者情報の開示請求があった場合には、
　　記録されているＩＰ情報を開示することがありえますか？

Ａ.状況により。

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

IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

205 ：デフォルトの名無しさん：03/01/11 21:59

IPの問題などどうでもいいよ。

それよりフリーのツール知りたい。

206 ：デフォルトの名無しさん：03/01/11 23:25

ねぇよ

207 ：デフォルトの名無しさん：03/01/11 23:41

2ちゃんねるも現実ですよ。

208 ：デフォルトの名無しさん：03/01/11 23:50

http://bitarts.jp/tech/etc/free_uml.html
フリー

209 ：デフォルトの名無しさん：03/01/11 23:51

>>205
俺が試したフリーソフトの中ではIIOSSが一番マシだった。

210 ：デフォルトの名無しさん：03/01/12 00:45

IIOSS
http://www.iioss.org/index-j.html

211 ：デフォルトの名無しさん：03/01/12 02:19

あらまぁお二人で（ｗ

212 ：デフォルトの名無しさん：03/01/12 09:55

4nd……　ラウンジの「ラウンジ恋愛部」かとおもた

213 ：デフォルトの名無しさん：03/01/12 11:17

ドキュメント作成のためのUMLツールならJava製じゃない方がいいな。
EAは図をコピペでWordやExcelに持っていけるのが楽。
やっぱり最終的な納品はWordやExcelになることが多いしね。

#それにしてもノイズ多すぎ。

214 ：デフォルトの名無しさん：03/01/12 20:38

2002年２ちゃんねるアニメランキング1位のアニメに・・・・

モナーが出演決定！！！！！！！！！！！！！！！！！！！！！

<<放送時間>>
1/12
大阪テレビ大阪（日）9：30～10：00
東京テレビ東京（日）9：30～10：00
名古屋テレビ愛知（日）9：30～10：00
福岡ＴＶＱ九州放送（日）9：30～10：00
札幌テレビ北海道（日）9：30～10：00
岡山・高松テレビせとうち（日）9：30～10：00　

215 ：デフォルトの名無しさん：03/01/12 20:42

何か勘違いしているように読めるのだけれど。

２ちゃんで７日以内に反論するのは「削除依頼された書き込みをした書き込み者」だよ。
その人が、書き込みが正当である旨反論すれば、管理人としては削除すべきではないという
積極的な心証を得る場合があり、ひいてはISP責任法の免責事由になる場合もある、
というのが狙いだと思っています。

あと、
>確かにレスが事実誤認であることを証明するのは原告側。
原告側にこの証明責任はありません。

216 ：デフォルトの名無しさん：03/01/12 20:51

ホビーの作業、乙です。

217 ：デフォルトの名無しさん：03/01/13 15:20

すみません、MagicDrawを使っている方いらっしゃいますか?
困っていることがあるので教えてほしいんですけど。
あるクラス図に対して、1個のクラスを作った後で、
そのクラスを別のクラス図にも表示させるようにしたんですけど、
別のクラス図からクラスを削除しようとすると、元のクラス図の方まで
削除されてしまいます。
元のクラス図の方には残して、別のクラス図からクラスを削除する
方法はないのでしょうか?

218 ：217：03/01/13 15:22

環境書き忘れました。
MagicDraw5.5iで、プラットフォームはMacOSXです。
WindowsやLinuxでの情報でも構いませんので、
良かったら教えてください。

219 ：デフォルトの名無しさん：03/01/13 15:41

やっぱグラフィカルで大まかな設計はUMLだな

220 ：山崎渉：03/01/13 18:34

（＾＾）

221 ：デフォルトの名無しさん：03/01/13 21:20

フリーソフトでJudeの他になんかいいのある？

222 ：デフォルトの名無しさん：03/01/13 21:37

>>221
Poseidon
IIOSS

223 ：デフォルトの名無しさん：03/01/13 22:03

よんどｗ

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

Poseidon
http://www.gentleware.com/products/index.php3

225 ：山崎渉：03/01/15 17:49

（＾＾）

226 ：デフォルトの名無しさん：03/01/15 23:31

超初歩的ですいません
ＤＢのＥＲ図をUMLで書くときは何図をつかうのでしょうか？

227 ：デフォルトの名無しさん：03/01/15 23:34

フリーじゃないものでラショナル以外のよいツール教えてください。
できればjavaでないもの

228 ：デフォルトの名無しさん：03/01/15 23:53

>>226
ER 図は ER 図、UML は UML かと。

>>227
作図だけなら Visio じゃだめ？

229 ：226：03/01/16 00:15

>>228
レスありがとうございます。
やはりＥＲ図はＵＭＬと別なんですか

両方かけるツールありますか？
visioはいくらくらいしますか？
会社でかうのだろうけど

230 ：デフォルトの名無しさん：03/01/16 00:22

正直、Visioはお奨めできない。
どうしても欲しかったらヤフオクで買え。

231 ：デフォルトの名無しさん：03/01/16 00:30

＞正直、Visioはお奨めできない。
なぜですか？
興味があるのでおしえてください

232 ：デフォルトの名無しさん：03/01/16 09:42

>>227

ここでよく話題にあがっているEnterprise Architect試してみるがよろし。
http://www.sparxsystems.jp/ea_downloads.htm

フリーじゃないもので、Javaじゃないツールって言うと
Rational Rose
MS Visio(高いやつ)
Describe
Enterprise Architect
あたりが思い浮かぶ。

233 ：デフォルトの名無しさん：03/01/16 10:10

ＥＡ以外でまともな有料ツールつうと数十万はするだろ。

234 ：デフォルトの名無しさん：03/01/17 10:43

visio使ってるよ。
UMLやるために買ったんじゃないけど。

海外のシェアウェアみたいなのも幾つか試したけど、
日本語が使えないとか、Javaのコードしか吐けないとか
希望に合うのが無くって、使い慣れてるしとりあえず
visioでやるかな、って流れで。

他にvisioやってる人いない？
生命線の上に活性化を乗せるのがうまくいかないんだけど(笑)
あと、コード出力ができない。.NET入ってないとメニューに出てこないのかな？

235 ：デフォルトの名無しさん：03/01/18 00:37

>>234
visioはコード出力できません。
コード解析機能だけです。

236 ：デフォルトの名無しさん：03/01/18 01:09

netの一番高いやつがコード生成できますよ
VISIONが一番使いやすいようなきがするのですが
値段が高すぎ

237 ：デフォルトの名無しさん：03/01/18 06:41

>>234
Visio使ってたよ。
クラス図を書くのに使ってたけど、関連がうまくまっすぐならなくて
「イライラするんだよ！（王蛇）」って感じだったので、結局やめました。

価格と機能からすると、EAが一番良いのではないでしょうかね。

238 ：デフォルトの名無しさん：03/01/18 09:33

つーか、visioは重い。

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

>クラス図を書くのに使ってたけど、関連がうまくまっすぐならなくて
ほんと線が思い通りにならない。
状態図とかだと遷移が直線にしかできない。

visioってＵＭＬ仕様的にはどうなの？

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

webアプリケーションの仕様で実際の画面以外に
UMLをつけたいのですが、ステートチャート図だけでも
足りるでしょうか？
他にも加えるとしたら何図でしょうか？

241 ：U ◆CZtFsGiu0c ：03/01/18 16:12

>>240
どういうレベルの「仕様」かわからないけど、画面遷移だけだったら状態図だけで
十分でしょう。遷移ごとの処理仕様を記述するのならロバストネス図とかシーケン
ス図とかが必要になってきますが。

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

UMLからC++のコードを導くような本とかサイトとかってないですか？

もちろん、UMLは言語から独立って話はわかるんですが、
最近、浅海さんとかJavaの話はたくさんありますよね。
ご存知の方、よろしくお願いします。

243 ：デフォルトの名無しさん：03/01/19 03:37

UMLの特徴としてふさわしいものをすべて選択しなさい。
(1)表記法だけでなく、開発の手順（開発プロセス）についても明示している。
(2)さまざまなオブジェクト指向方法論の用語と表記法を統一したものである。
(3)これを使うすべての開発関係者には実装言語についての知識も要求される。
(4)採用できる開発プロセスに制限がある。
(5)どのようなモデルを作るべきかについての指針も明示されている。
(6)オブジェクト指向開発において、開発関係者の共通言語として使用することができる。

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

>243
2,6?

245 ：デフォルトの名無しさん：03/01/19 18:07

デザインパターンってUMLに入らないの？

246 ：デフォルトの名無しさん：03/01/19 21:16

>>243
絶対（3)は必要。
実装できないやつのUMLなんて空想の産物。

247 ：デフォルトの名無しさん：03/01/19 22:01

お客さんへの説明にも使えるというお題目を信じるなら (3) は違うわけだが。

248 ：デフォルトの名無しさん：03/01/20 03:17

俺も>244に同意で　2)&6)。

問題領域をモデリングするだけなら実装言語の知識は必須じゃないだろ。
メタ言語をメタ言語として書けばいいだけ。

以上の理由から
(3)これを使うすべての開発関係者には実装言語についての知識も要求される。
　　　　　　　　^^^^^^^^
が当てはまらないので除外。

249 ：2問目：03/01/20 04:52

アクターやユースケースを考える場合、どのような視点に立てばよいですか。
適切なものをすべて選びなさい。
a)2個以上のユースケースを作成したか。
b)ユースケースがアクターにとって価値のある機能か
c)ユースケースがシステム内部まで立ち入っていないか。
d)システムに期待している機能がユースケースとしてすべて定義できているか。
e)アクターは役割ごとに定義されているか。

250 ：デフォルトの名無しさん：03/01/20 17:08

>249
d．e

251 ：デフォルトの名無しさん：03/01/21 01:21

>250
ｃ)ってどういうことを言ってるの？

252 ：サンタマリア：03/01/21 01:47

アクターのユースケを考える場合、どのような視点に立てばよいですか。
適切なものをすべて選びなさい。
a)2人以上のユースケを作成したか。
b)ユースケがアクターとして価値のある存在か
c)ユースケが作品内部まで立ち入っていないか。
d)作品に期待している演技がユースケとしてすべて定義できているか。
e)アクターは役割ごとに定義されているか。

253 ：デフォルトの名無しさん：03/01/21 02:23

>251
ユースケースは表面的な、要求定義を図に落としたモノだと思うから
実装よりの記述があるのは不適切ってことなんじゃないか？

254 ：デフォルトの名無しさん：03/01/21 02:40

>253
いわゆる外部仕様ってこと？

255 ：デフォルトの名無しさん：03/01/21 09:29

>>254
でもどうだろうね。
理想的にはビジネスモデルだけを抽出するのがベストだけど、
暗黙的に実装を想像しながらやらないとあんまり意味がない気も。

256 ：デフォルトの名無しさん：03/01/21 09:44

>>246
最近はソフトウェア業界以外でもUML使ったりしてるらしいけど。

257 ：デフォルトの名無しさん：03/01/21 10:47

最近は至る所で講習会が行われてるなぁ

258 ：デフォルトの名無しさん：03/01/21 11:18

ソフトウェア開発以外でUML？何に使うんだ？

259 ：デフォルトの名無しさん：03/01/21 11:26

業務の流れや人材資源などの配置をUMLで表現するとこも多くなった

260 ：デフォルトの名無しさん：03/01/21 11:54

ソフトウェア産業以外でも普及し始めるとSE/PGとしては使えてないとなぁ

261 ：デフォルトの名無しさん：03/01/21 12:07

読むのは簡単。書くのは結構面倒。

262 ：デフォルトの名無しさん：03/01/21 12:51

他でも普及すると、客にもUML使って説明できるから楽なんだがな。

263 ：デフォルトの名無しさん：03/01/21 13:33

業務形態も一種のソフトウェアと考えれば、わりと自然な話かもッスね。
人間・組織のソフトウェアにコンピュータのソフトウェアを
インテグレートするようになるんだろうか。

264 ：デフォルトの名無しさん：03/01/21 15:42

客がUML使って書いて下請けに投げれば。
上流が要らなくなるね。

265 ：デフォルトの名無しさん：03/01/21 19:24

客側から提案する場合の工数は減るが、不要にはならないだろう。

266 ：デフォルトの名無しさん：03/01/21 19:38

限りなく営業に近づくのだろうね。

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

まぁでも、お客さんで自分がほんとは何がやりたいのかわかっている場合って少ないわけで。
一般の人がそこまでできるんだったら、もうSIとかシスコンの会社っていらないよね。

268 ：デフォルトの名無しさん：03/01/22 18:55

クラス図の多重度で、「0..*」と「*」は同じ事を
意味していると思うのですが、使い分けの基準は
ありますか？

269 ：U ◆CZtFsGiu0c ：03/01/22 19:22

>>268
意味は同じですが、「存在しないこともある」というのを明確にする
ために0..*と記述するようにしています。

270 ：デフォルトの名無しさん：03/01/23 01:29

最近クラス図を覚えました。世の中には便利なものがあるもんだと関心しておるのですが、
これって規模がでかくなっていったらどうやって書いたらええですか。どんどん広げていく
訳にも行かないので困っております。階層化するとか定石があるのなら教えてプリーズ！

271 ：デフォルトの名無しさん：03/01/23 02:19

結局>249はc)d)e)ということでよろしいか？

272 ：デフォルトの名無しさん：03/01/23 02:28

>>270
コンポーネント図、パッケージ図。
「きれいでかんぺきなしようしょ」が書きたいのでなければ、
そのアプリケーションにとってキモとなる部分や、
説明が必要だと思う部分だけ図を描けばいい。
その方が時間も無駄にならない。

273 ：デフォルトの名無しさん：03/01/23 08:57

狭い領域に全部書こうとしてはならん。

274 ：デフォルトの名無しさん：03/01/23 09:54

>>272
レスサンクス
まだクラス図しかやってないのでコンポーネント図とかも勉強しやす

275 ：デフォルトの名無しさん：03/01/23 15:01

>>246 ：デフォルトの名無しさん：03/01/19 21:16
>絶対（3)は必要。
>実装できないやつのUMLなんて空想の産物。

プロ市民の論理て結局これでないの？

276 ：デフォルトの名無しさん：03/01/23 17:38

その後（260番台）に「実装技術を知らない客側が書くUML」の話題だった訳だが。

なんにせよ問題出した奴が早いとこ解答だしてくれんとなんとも言えんな。俺まだブロンズだし。

277 ：デフォルトの名無しさん：03/01/23 19:56

UMLとPascalの表記法って類似点が結構多いような気が
するのですがこれは何故なのでしょう？
UMLってC++やJavaの方がさかんに使われていますが
それらとは明らかに違いますよね？

どちらもBNFの表記法を素直に継承しているから？

278 ：デフォルトの名無しさん：03/01/23 20:47

>>277
PASCAL　:LL文法
C++,Java:LALR文法
の違い。
たしかLL文法は、再帰的に簡単に構文を辿れるが、
LALR文法の場合は、構文要素の先読みをしないと、構文解析ができない、
てな違いがあったと思う

279 ：デフォルトの名無しさん：03/01/23 20:50

ところで、
＞UMLとPascalの表記法って類似点が結構多いような気が
「UMLの表記方法」とはナニを指しているのでせうか？

280 ：デフォルトの名無しさん：03/01/23 21:13

シグネチャの書き方か？

<<foo>> bar(baz : Baz&) : void

とかの。

281 ：山崎渉：03/01/23 21:19

（＾＾）

282 ：デフォルトの名無しさん：03/02/01 15:20

http://www.molips.com/jp/
http://www3.to/d-d-s

すごく便利なんだけど
これ無料だったりする。

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

age

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

EAのアカデミック版って通常版に比べると異常に安いな...
MSのOfficeとかもそうだけど、通常版買った人間からみるとけっこう辛いものがある。

285 ：デフォルトの名無しさん：03/02/05 00:11

ＯＯ厨的には抽象化により
プログラムを知らなくても設計理論だけで書ける（はず）
現実世界なら話は別

286 ：デフォルトの名無しさん：03/02/05 00:30

Rose RealTimeで開発してまつ。

使い方憶えるのにとっても時間が掛かりましたが（２～３週間）、
今はさくさくクラス図書いて、ステートチャート書いて、ちょこ
ちょことコード書いてと、ExecutableUMLって言うのですか？
とても便利です。

クラス図と状態図だけですけど、吐きだしたコードとダイアグラ
ムが必ず連動しているっていいですね。
MagicDrawとかPatternWeaverで書いてた頃が懐かしいです。

でも、高いですよねぇ。フローティングで１５０万円位します
もんね。

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

>>286

それを買ってもらえる環境がｳﾗﾔﾏｽｲ
僻みなのでsage

288 ：デフォルトの名無しさん：03/02/07 00:36

漏れは１週間前からRose Enterprise使い始めました。
まだ使いこなせないけど、使い勝手はかなりいい。
しかし１ライセンス５０マソは高いな。

289 ：デフォルトの名無しさん：03/02/07 00:58

既存のクラスをインポートしようとするとすぐ固まるのと、
印刷がしょぼいのは直ったのかな。

290 ：デフォルトの名無しさん：03/02/07 22:03

>>289

RoseRTですが、印刷はしょぼいですね。なので、ウェッブ・パブリッシャ
でHTML変換してイントラで公開。この機能は重宝してまつ。

インポート(？)は使ってませんね。ユニットコントロールで別モデルからの
取り込み（変更可）や共有（変更不可）はできます。

あと、ステートチャートで同期バーが使えないのは面倒くさいかも。チョイ
ス・ポイントで判別しないといけないし、図上に平行動作が現れてこない。

あとはアクティビティ図が描ければイイな。実装には関係ないけど制御系な
ので仕様として残したい。クラスの振る舞いとは別に並列／平行動作が多い
からね。全体動作を見るにはよい。手動で更新しないといけないけど。

よいツールですよ。UMLをきちんと理解してないと使えないですけど。

291 ：U ◆CZtFsGiu0c ：03/02/08 12:24

>>290
>インポート(？)は使ってませんね。ユニットコントロールで別モデルからの
取り込み（変更可）や共有（変更不可）はできます。

おそらくリバースエンジニアリングのことだと思います。Javaの場合だとRose起動用の
クラスパスに対象クラスを含める必要があってむちゃくちゃめんどくさかったんですが、
今もそうでしょうか。

また、一番よく使うシーケンス図の自己呼び出しがちゃんと書けないのも不満。
なので、

>よいツールですよ。UMLをきちんと理解してないと使えないですけど。

今はTogether使ってます。RoseもTogetherもフローティングライセンスで独占して
使えないので、安くていいツールがあれば乗り換えも考えるんですけどね。

292 ：デフォルトの名無しさん：03/02/08 12:45

>>291

おぉ・・・そうか。

無印ＲｏｓｅとＲｏｓｅＲＴは全く別物かもしれないですね。
（お値段も倍以上違う）

無印は今度使ってみます（評価版があったはず）

293 ：デフォルトの名無しさん：03/02/08 21:26

>>291

安くていいツールは、ここでも話題になっているEAす。
先日のキャンペーンで買ったけど、大きな不満はない。
シーケンス図がRoseより書きやすいような。

294 ：デフォルトの名無しさん：03/02/11 19:47

クラス図使って開発してると、すんごい整理されて
いいんですけど、逆にすごい凝ったものも整然と
できちゃうわけで、
あとでわけわかめになったりしません？

奇跡的な構成のシステムができて
やったやったと喜んでたんですが、あとで困っちゃって。
整理されすぎるのも困るなぁと。

多少冗長なぐらいでやめておくほうがいいんでしょかね。

なんかプログラムの最適化とかアセンブリとかの話と
同じような現象がクラス図にもあるんだなぁと
そのとき思ったでする。

295 ：デフォルトの名無しさん：03/02/12 01:58

シルバーレベルってどのくらいの知識が必要なんでしょうか？
UMLリファレンスマニュアル
UMLユーザーガイド
UMLによる統一ソフトウェア開発プロセス
UML仕様書
が必要とか？

296 ：U ◆CZtFsGiu0c ：03/02/12 13:07

>>293
やっぱりEAですか…暇になったら評価版を試してみます。

>>294
すまんが困ってることがなんなのかよくわからん。

297 ：293：03/02/12 23:32

>>296

少なくとも、事実上個人利用としての選択肢は
JudeみたいなJava系のツールかEAしかないでしょ

>>295

少なくとも、ブロンズが余裕で受かるレベルじゃないと
太刀打ちできないと思う。レベルが違う。

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

>>295
あと実際のモデリング経験。
かんがれよ。

299 ：デフォルトの名無しさん：03/02/13 05:01

>>294
>あとでわけわかめになったりしません？
しません。

>やったやったと喜んでたんですが、あとで困っちゃって。
>整理されすぎるのも困るなぁと。
そもそもこの文章の中で言う整理って何のことでしょうか？

>多少冗長なぐらいでやめておくほうがいいんでしょかね。
いいえ。

>同じような現象がクラス図にもあるんだなぁと
>そのとき思ったでする。
意味不明です。

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

まだ評価版は試してないんだけど、EAは「実現」を表す
破線に△のラインは書けるの？　サンプル画面見ても
「汎用」の実線に△のラインしか出てなかったからさ。

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

>>300

今試してみたらできた。
普通にrealizeの接続をつくればOK。

302 ：デフォルトの名無しさん：03/02/16 21:50

質問させてください。
class Super{}
class Sub1 extends Super{}
class Sub2 extends Super{}
class User{
　Sub1 s1;
　Sub2 s2;
}

なんてコードをクラス図で表わすときに、
Userからのコンポジットの線は、Sub1とSub2に1本ずつ引くものでしょうか。
それとも、UserからSuperに1本だけ書けばよいのでしょうか。

俺は、Sub1とSub2の両方に1本ずつだと思うんですが。。。

303 ：デフォルトの名無しさん：03/02/16 23:35

>>302
UserがSub1、Sub2の型で持つのなら、両方に一本ずつじゃない？
でもSuperがインターフェースを定義しているだけで、Subはその
実装を提供しているだけなら、Superに一本でもいいような気がする。

StateまたはStrategyパターンのような感じで表現する方が好みだけど。

304 ：デフォルトの名無しさん：03/02/17 00:06

SuperへのポインタでSub1又はSub2を保持するならSuperに一本。
今回の場合はSub1,Sub2へ各一本じゃないの?

305 ：302：03/02/17 00:27

>>303
>>304
レスありがとうございました。
わかりました。

なんで、こんなバカな（？）ことを聞いたかというと、
実際には、Userクラスにも種類がいくつかあって、いくつかのSubクラスを
内部に持つので、クラス図が交錯する線だらけになってしまうのです。
教科書を見ると、サンプルはいつもすっきりしていて、派生クラスに線が
引かれているのはあまり見ないので、不安になったのです。

>>303
たしかに、UserがSuperだけ持つようにできればすっきりなのですが、
そうすると、Superの使いたくない派生クラスまで「理論上は扱える」ように
なってしまいます。それは、将来、問題になるような気がするので、
やはり、派生クラスで持たせたいのです。おかしいでしょうか？

あと、1つ聞かせていただいてよろしいでしょうか。
クラス図が線だらけになるのを避けるために、線を間引いてもよいのでしょうか？

質問を重ねてすみませんが、よろしくお願いします。

306 ：303：03/02/17 02:42

>>305
何のためのクラス図かによるんじゃないかな。

UMLからソースを生成するようなCASEツール使ってるのなら、
教科書(?)通りに正確に記述する必要があるかも知れないけど。

開発者や設計者といった人が見るためのものなら、線を間引いてでも
見易くしないと、>>305 が作ったUML図は見にくいということになり、
最終的に見向きもされなくなる。

307 ：305：03/02/18 00:59

>>306
レスありがとうございます。
やっぱり、間引いてもいいんすね。

俺の場合、UMLからコードを書くんじゃなくて、コードからUMLを
書かされるんです。

308 ：うん込まん：03/02/19 22:12

あげ

309 ：デフォルトの名無しさん：03/02/19 22:22

http://www.google.co.jp/search?num=100&hl=ja&ie=UTF-8&oe=UTF-8&c2coff=1&as_qdr=all&q=+%22%E3%81%86%E3%82%93%E3%81%93%E3%83%9E%E3%83%B3%22+site%3A2ch.net&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

310 ：デフォルトの名無しさん：03/02/21 00:33

>>307
それ、手作業なの？？
不毛だ…

311 ：ななし：03/02/21 14:20

ドイツ製で・・・梅何とか？？ってＵＭＬ設計のできる
ツールがあるの？

クラス図を書くと、そのままコードまで出てくれるって奴。
詳しくは知らないんだけど・・・ちょっと小耳にはさんだ。

312 ：デフォルトの名無しさん：03/02/25 01:29

class A{
};

class B{
void func(){ A a; }
};

みたいな関係は、「BがAを使う」ではないかと思うのですが、
その場合、BからAに→を引くのでしょうか？
それとも単にBとAを線で結ぶだけでしょうか？
それとも線は何も書かないのでしょうか？

お願いします。

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

>>312
「BはAに依存している」ということで
「依存」を表す点線の→をBからAに引きます。

314 ：デフォルトの名無しさん：03/02/28 23:37

こちらでツールについて語ってください。

ま、金が余ってるなら Rose、
Rational にお布施したくないなら EA ってことで。

315 ：デフォルトの名無しさん：03/03/01 00:42

EAの日本語版はそろそろだっけ

316 ：デフォルトの名無しさん：03/03/01 02:32

>315
予定では2003/4/1ですね。
ふぅ…もう待ちきれないので英語版、買っちゃおうかな…

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

>>316

俺もそう思ってFAQ見たり聞いたりしたが、日本語版が欲しいなら
今英語版を買うよりは4月に日本語版を買うべきだそうだ

売らない販売担当も珍しい

318 ：デフォルトの名無しさん：03/03/01 10:22

>>317
あれ、日本語版にアップデートできるんじゃなかったの？

319 ：デフォルトの名無しさん：03/03/01 10:23

まぁあと30日だから、評価版でも間に合いそうだけど

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

EA評価版使ってみた。やっぱ日本語版がいいなあ。
こいつのUnitTest機能って、xUnitみたいなテスティング用コードを生成してくれるのか？
ヘルプ読んでもわからんかったので教えてくだされ。

321 ：デフォルトの名無しさん：03/03/01 15:31

EA評価版使ってます。早く日本語版出て欲しいです。
とりあえず日本語のヘルプだけでも一般に公開して
くれればいいのに。

で、質問。
クラス図から生成されるJavaソースのフォーマットは
変更することはできるのでしょうか？

322 ：デフォルトの名無しさん：03/03/01 18:47

オージスのシルバー三回落ちたぞゴルァ
ＵＴＡＹＡの問題もう見飽きた

323 ：322：03/03/01 18:48

こうなったら一生かかっても自力で受かってやる
受かったやつは皆、不正をしてるんだろうがな！！

324 ：デフォルトの名無しさん：03/03/01 19:33

>322
最近のことですが、シルバー試験に一発合格しました。
ブロンズの時は一発満点合格でした。

UTAYAの問題以外は、UMLの基礎がしっかりできていれば
大丈夫です。もう一度チュートリアルをしっかり読むとか
「UMLモデリングのエッセンス」を読むとかが対策かな。
あとはデザインパターンを軽く学んでおけばいいでしょう。

UTAYAの問題は仕様をよく読んで、ユースケースに
きちんとまとめられないと、その後の問題もきついだろうね。
あんまり書くと、ネタバレになっちゃうからやめとくけど。

仕事で資格が必要とかでなければ、不正して受かっても
うれしくないでしょ。がんばってください。

325 ：デフォルトの名無しさん：03/03/01 21:55

317です。

FAQにもあったのですが、今英語版を買うと、日本語版にするときに
別途カネが必要らしいので、１ヶ月なら待ったほうがよいとのこと。

というわけで319と同じく評価版で遊んでます。

326 ：デフォルトの名無しさん：03/03/02 01:59

日本語版は延期な罠

と、縁起でもないﾈﾀを振ってみる

327 ：317：03/03/02 08:06

評価版でいろいろ試してみますた。

>>320
そういうわけではなくて、単に記録ができる、というもののようだ
少なくとも、そういう機能は発見できず

>>321
同じく変更できそうなところは発見できず。

328 ：デフォルトの名無しさん：03/03/02 08:44

ドリームパートナー募集中！
今話題のYahoo! BB、BBフォンの販売にご協力下さい。
販売には特別な知識は必要ありません。
魅力的な報酬プランご確認の上、お気軽にご参加下さい。

http://join.dreampartner.jp/mmd/bb/index.html

329 ：デフォルトの名無しさん：03/03/02 11:32

>>326

確かにこの手のローカライズ版にはつきものかも。

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

>>321
ヘルプだけもらってもしょーもない気もするが
どんな活用法が？

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

OMG認定UML技術者資格試験プログラムが９月から始まるね。
９月以降はオージスの方取っても失笑されるようになるんだろうな。
その前に取っときたい所だが・・・

332 ：デフォルトの名無しさん：03/03/03 20:37

>>330
読み慣れた日本語で内容を理解する。

333 ：デフォルトの名無しさん：03/03/05 18:43

EA(体験版)で作成した図を清書する事って出来ます？
オブジェクトを適当に配置したんで綺麗にしたいんですが．．．

334 ：デフォルトの名無しさん：03/03/05 20:48

>>333

いちおう自動整列機能が存在する。
が、自分はこれ一発で納得できる図になったことはない...

現状が適当なら、とりあえずこれを実行してその後
整理するのがよいかな

335 ：デフォルトの名無しさん：03/03/06 01:30

EA（体験版）のリバースエンジニアリングで、
以下のようなコードを処理すると文字化けするんだけど、
なんとかならん？

string ファイル名;

「ァ」がまずいみたい。
日本語版だと大丈夫なのかな？

336 ：デフォルトの名無しさん：03/03/06 02:42

>>335
手いうかコードに日本語あんま使わんわな

337 ：デフォルトの名無しさん：03/03/06 07:41

>>336

禿同

ただ、VBあたりの本だと使っている例も多い

338 ：デフォルトの名無しさん：03/03/06 07:45

とりあえずココで選びなさいな
http://homepage3.nifty.com/digikei/index2.html

339 ：333：03/03/06 11:06

>>334
出来ました。情報感謝m(__)m

340 ：デフォルトの名無しさん：03/03/07 02:14

Konesa-RealTimeとRose RealTimeって似たようなものですか？
それとも、やっぱ値段相応にRose RealTimeの方が優れてるんですか？

いやね、どっちか買おうかと思って。
やっぱ、メジャーなRose系にしといた方がいいかなぁ。

Konesa-RealTimeの体験版使ってみたけど、コード自動生成って楽しいね。

341 ：デフォルトの名無しさん：03/03/07 21:33

>>340

慣れれば、どっちも似たようなもんだと思うよ。

違いがあるとすれば、対応ＯＳの差かな。自分でフレームワークを
未対応ＯＳ向けにポーティングしなくても済むからね。

対応ＲＴＯＳの数で言えば、

　RoseRT ＞ Konesa

だったと思いまつ。その他、RoseRTは標準で分散オブジェクト環
境(コネクシス)を持っていたりする点で優れているかも。

342 ：デフォルトの名無しさん：03/03/13 00:05

>>326

予定通り4月1日発売らしいage

343 ：デフォルトの名無しさん：03/03/13 00:19

質問です。ちょっと教えて君みたいで恐縮ですが

コンポーネント図で、
パッケージの中にコンポーネントを入れることは変でしょうか？

配置図で、JARで圧縮されたJavaクラスライブラリをパッケージとして
表すことは変でしょうか？　これはコンポーネントとして表すべきでしょうか？

配置図でJVMを表すとき、コンポーネントで表すべきでしょうか？
またはそのコンポーネントの中にJavaのコアAPIのパッケージも含めるべきでしょうか？

UMLブロンズをとってもこれらを理解できませんでした。
こんな私はUMLのブロンズ資格を持つべきではないでしょうか？

私のUML環境はEclipse + Omondoで使い始めています。
以前はIIOSSを使ってました。

344 ：デフォルトの名無しさん：03/03/13 00:39

>>342
発売延期がなくても、待たされる罠。
ttp://www.sparxsystems.jp/ea_releaseJp.htm

345 ：デフォルトの名無しさん：03/03/13 02:19

>344
これを良心的とみるべきなのか、判断に迷うわねぇ

346 ：デフォルトの名無しさん：03/03/13 07:02

>>345

まァ、カネ払ってもなしのつぶて状態になるよりは
きっちり対応してくれるほうがいいかもね

既にそんだけ購入希望者がいるってことでしょ？

347 ：346：03/03/13 07:13

sage忘れた

良心的に考えれば、キャンペーンで事前購入してる人優先てのも
わからんでもない
買っとくべきだったのかな。。。

348 ：デフォルトの名無しさん：03/03/13 08:14

>>343
>コンポーネント図で、
>パッケージの中にコンポーネントを入れることは変でしょうか？
変じゃありません。サブシステムという扱いになります。

>配置図で、JARで圧縮されたJavaクラスライブラリをパッケージとして
>表すことは変でしょうか？　これはコンポーネントとして表すべきでしょうか？
普通は配置図ではコンポーネントを使います。
ただし配置図の目的は物理的なコンポーネントの配置位置を示すことです。
パッケージだろうがコンポーネントだろうが目的が達成されやすい方法がいいのです。
なので状況によると思います。

>配置図でJVMを表すとき、コンポーネントで表すべきでしょうか？
ノードがよいと思います。おそらくそれはアプリケーションサーバでしょうから・・・。

>またはそのコンポーネントの中にJavaのコアAPIのパッケージも含めるべきでしょうか？
含めるべきではありません。邪魔です。

>UMLブロンズをとってもこれらを理解できませんでした。
>こんな私はUMLのブロンズ資格を持つべきではないでしょうか？
そんなことはないです。
これだけの問題意識を持てる方はもっと上位のスキルを目指すべきです。

349 ：デフォルトの名無しさん：03/03/13 11:57

>>344
サーバくらい増設しろよ。

350 ：346：03/03/13 22:02

>>349

クレジットの手数料払うと赤字になるくらいの
利益率だと難しいと思われ

実際ここのサーバ安いしねサポートはどうなんだろ？

351 ：デフォルトの名無しさん：03/03/13 22:48

>>350

ｽﾚ違い

352 ：デフォルトの名無しさん：03/03/14 00:16

>>351
適したスレはどこなんだよ！と言ってみる。

353 ：デフォルトの名無しさん：03/03/14 00:55

>>350
言われて調べてみたけど、共有のレンタルサーバとは・・・
確かに安いけど、どうせ借りるなら、もうちょっとデカイ会社のに
すればいいのに。

354 ：デフォルトの名無しさん：03/03/14 07:00

>>349,350,353

同じようなこと(サーバ増設ｼﾙ)サポートに聞いてみたら
将来的には考えてるらしいとのこと。

まあ、なんだな。利益率の設定間違えたと。

355 ：デフォルトの名無しさん：03/03/15 13:55

＿＿ＵＭＬロボット＿＿
http://that.2ch.net/test/read.cgi/robot/1047690048/l50

356 ：デフォルトの名無しさん：03/03/23 23:53

サーバくらい短期でも借りられると思うんだがな。
MXとかNYって、ほんとはこういうのに対処するためのツールなんだろうな。
サーバ負荷を減らすために、みんなで共有しるか。

357 ：356：03/03/23 23:54

あ、ダメですな。
IDもらってからDLだったか。
すまそ。

358 ：デフォルトの名無しさん：03/03/30 22:56

age

359 ：デフォルトの名無しさん：03/03/31 20:50

EA日本語版使ってみた。

確かにいくつか英語残ってる部分もあるが、基本的には
問題ない感じ。

やっぱ日本語はいいね

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

おー、いいなぁ。
しかし、制限しなきゃいけないほど、そんなにサーバ混んでるのかな。

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

今のところはストレスないですね。
制限もないようですし。

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

>>360,361

どうやら杞憂だったというオチのようで。。。

363 ：デフォルトの名無しさん：03/04/03 19:27

それはそれで悲しいな。

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

サポートの人がぽろっと教えてくれたけど
注文は予想以上に来ているらしい。サーバーがそれ以上の
性能を示したってことか？

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

只今上司を「ＵＭＬって意外と使えるな」というふうに洗脳中・・・

366 ：デフォルトの名無しさん：03/04/04 21:36

只今上司を「2chって以外と使えるな」というふうに洗脳中・・・

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

独習ＵＭＬ改訂版ってどうよ？
漏れは初心者に毛が生えた程度なんだが。

368 ：しお韓：03/04/05 15:00

598 名前：　[sage] 投稿日：03/04/05 14:58 ID:mQUML4qC
おまえらヤル気あんのか？

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

>>368
おぉぉぉぉx！

370 ：デフォルトの名無しさん：03/04/05 23:17

>>367
改訂版は知らないけど(1.4対応？)、
独習UML自体は入門向けにちょうどいい。

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

>>367

「はじめて学ぶUML」がお勧め。
両方読んだ立場としては、こっちのほうがいいかな。

でも、この2冊ならどっちでもOKでしょう。

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

ブロンズとったー！！！ここからが大変なようですね．

373 ：プロの逝って良しの１ ◆MvRbZL6NeQ ：03/04/06 14:11

宗教だな。
技術ではない擬似技術

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

UML2.0をちょっと眺めてたんだけどよ、
コーディングがこれで完全に設計の工程から
切り離されたって気がしたな。
一部のUMLを中心とした研究を志す企業を除いては
世の中はフレームワーク／コンポーネントメーカ
とビジネスのSIに完全に分かれていくんだろうか。
おれらもどっちに付くのかそろそろ決める時期が
きてるんじゃないかな。

375 ：プロの逝って良しの１ ◆MvRbZL6NeQ ：03/04/06 15:43

Ａ「ちっ、また使えねー設計図よこしたな」
Ｂ「組織ってのは無駄なものなんだよ」
Ａ「しょがねー、また勝手に作るか」
Ｂ「毎度毎度だけど誰も気付かないねえ」

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

結局ＵＭＬ覚えたって設計に必要な知識の５％くらいしか補完してくれないと思う。
それに気付かないで糞ＵＭＬ排出してＯＯ語ってる奴等が大多数だから腹立たしい。

>>374
効果的に使いこなせる奴ほとんど居ないんじゃないの？
日本じゃ３年早いと思う。

377 ：デフォルトの名無しさん：03/04/08 14:44

実務で使っている人の話が聞きたいなぁ。
そんな人はまだまだ少ないんだろうねぇ。

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

実務で使ってます

ソフト屋が４０人程度の部署で、そのうち２５人は組み込みのファーム
ウェア開発要員なんだけど、eUMLでがんばって開発してまつ。

シリーズ物の息が長～い製品なので、ソフトの寿命も１０年以上と長い。
顧客の要望でちょこちょこ変更も多い。（半導体工場に入れる装置だか
らね。リソ工程）

なので、オブジェクト指向だ！ UMLだ！ってんで新しい者好きが多かっ
たせいもあり、新規装置のソフトはオブジェクト指向＆UMLで開発して
ます。

取っ掛かりは大変でしたけど（勉強会は半年も続いた。ツールベンダの
コンサルにはしこたま貢がされた）、今はUMLなしでの開発は考えられ
ないです。

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

>>378
頭の使い方が以前とは変わったような気がしたりしませんか？

380 ：プロの逝って良しの１ ◆MvRbZL6NeQ ：03/04/08 23:34

セールスマン必死だな

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

実務で使っている方に質問です。

■実際の開発ツールは何を使われましたでしょうか？
■実際はＵＭＬだけでは設計書が足りないと思うのですが、
　何の設計書を追加いたしましたか？

実際の開発ツールはＵＭＬだけに特化していて、
実際は使えないようなイメージがあるおいらは間違っているでしょうか？

ユースケースからクラスに落とすところなんて、
とてもじゃないけどＵＭＬだけではできるとは思えません。

質問ばかりですいませんが、よろしくお願いします。

382 ：プロの逝って良しの１ ◆MvRbZL6NeQ ：03/04/08 23:47

えーとね。
真面目な話。
聞いた話なんだけど、ＯＯのコンサル連中の中には
自己開発セミナーから流れて来たのが居るそうだ。
自己啓発セミナーがＩＴ関係もやってたことがあって、
ソフトウエア開発の知識もあるということだそうだ。

>>378みたいなのは導入後の評価が変質してるから怪しいかも。

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

>>378
eUMLですか。。。
別のスレでも書いたのですが、UMLで書くと、初期化処理とか例外処理とかがぬけていて、
後から気づくことってありませんでしたか？
今、ちょっとそのへんの取りこぼしをどうフォローするか、考えてます。

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

実際にクライアントとの打ち合わせにＵＭＬを使う事なんか
あるのでしょうか？

導入している企業はほとんどＩＴ関連かＩＴ部門のみで、それ以外の相手に
ＵＭＬで説明などしようものなら「そんな専門用語分からんわい」ってなりそう。

385 ：U ◆CZtFsGiu0c ：03/04/09 13:05

>>381
>■実際の開発ツールは何を使われましたでしょうか？

これはUMLツールですか? 今はTogatherを使っています。

>■実際はＵＭＬだけでは設計書が足りないと思うのですが、
　何の設計書を追加いたしましたか？

よく書くのはDBの物理設計書、画面設計書(モックアップの場合もある)です。
設計とはいえないかも知れませんが、ユースケースシナリオもUMLでは書けない
ので別に書く必要がありますね。

>ユースケースからクラスに落とすところなんて、
とてもじゃないけどＵＭＬだけではできるとは思えません。

クラスを抽出するのはツールにはできません。それを行なうのは人間です。

386 ：デフォルトの名無しさん：03/04/09 14:08

実務で使っている方へ質問です。

効率良くＵＭＬを学習するには、どうするのが一番だと思いますか？

１．本をたくさん購入して読みまくる。

２．ネットで勉強する。

３．とにかく使ってみる（身近なものをモデリングしまくる）

４．他

上記では、３が良いのかなぁ・・・

387 ：デフォルトの名無しさん：03/04/09 21:51

UML自体知らなくても図で説明するのはわかりやすいと思う。

388 ：先月まで実務で使ってた方：03/04/09 22:33

実務で使ってる方…か。
案外やる気があって自分で勉強してる層の方がわかってるかもよ。
この業界ってそうじゃん…。

実際やってみてハマった点とかは人の振り見てアレな感じなんだろうけど、
学習方法なんて自習してる人間のほうが知ってるって。

389 ：sage：03/04/09 22:49

まあその、UMLなんかは適当な部分も多いわけで
一人でやるだけじゃなくて、だれか知ってる人に
なんどかみてもらう機会を作るといいと思うよ。

UMLが記述*言語*だっていうのは、知識を詰め込むだけじゃ
だめで、実際に読んで、書いて、コミュニケーションして、
そのなかで体得してく部分があるからじゃないかな。

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

ＵＭＬ＝設計書って考え方は、そもそも間違ってるんじゃないの？
あくまで統一的なモデリングによるコミュニケーション手段だし。
そこを理解せずに取り入れてるプロジェクトって大抵足かせになって失敗してるね。

結局ＵＭＬを標準文書として取り入れる為には、
ＵＭＬによるコミュニケーションが必然になるポイントが分かってなきゃいけなくて、
その為にはOOADPのプロセスが標準化されてなくちゃいけなくて、
その為にはOO開発をいくつか経験（成功）しなくちゃいけなくって、
その為にはOO理解してる技術者を集める（育てる）必要があって、

・・・まあ、素人は手出すなってこった。

391 ：デフォルトの名無しさん：03/04/09 23:47

RoseRTなので、分析段階は通常のUMLでああだこうだ言いながら
みんなでモデリングしてます。実装はRT上でUML(なのか？)で書い
たものがそのままソースコードになります。

ですが、もちろんそんなものだけでは設計しきれないので、通常の
仕様書も作成しています。

例外処理や初期化処理はアクティビティ図で最初に仕上げておきま
すね。

UMLだけで何もかもできるなんて都合の良い話はないっす。

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

例外処理のもう一つの定義方法、ステートチャートで処理する。

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

>・・・まあ、素人は手出すなってこった。
正にだね。

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

統一された表現方法を多様に持てるだけでも良いとおもうが。

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

>>383

Catalysisあたりを見て、pre-condition,post-condition
を設計書に混ぜるとよろし。

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

>>385
together（Togetherに限らず、最近のＵＭＬツールは全て）
はＵＭＬしか書けないと思っています。
実際の開発だとユースケースシナリオ、ＥＲ図、用語一覧等ＵＭＬ以外の仕様書を
作成する必要があると思っていますが、
その他の設計書はＥＸＣＥＬ等で作成したのでしょうか？
それとも他のツール（Xupper、Erwin等）を使用したのでしょうか？

ＥＲ図、用語一覧はＥＸＣＥＬだとかなり辛いと思いますが、
実際どうなんでしょうか？

またTogetherは一人で開発する際には良いと思いますが、
複数チームで開発する際、複数人が作ったユースケース、クラス図全体を
まとめる時はどうしたのでしょうか？

質問ばかりで申し訳ありません。

397 ：あぼーん：03/04/10 02:53

あぼーん

398 ：佐々木健介：03/04/10 02:53

　　　　　＿＿＿＿_＿
　　　／＿　　　　　　|
　　 /.　＼￣￣￣￣|
　　/　　／　 ―　― |
　　|　 /　　　-　　- |
　 ||| (5　　　　　　>　|
　| | |　　　　 ┏━┓|　　／￣￣￣￣￣￣￣￣￣￣
| | | | 　　　　┃─┃|　＜　こんなサイトを見つけた
|| | | | 　＼　┃　 ┃/　　＼　　正直、スマンカッタ
| || |　|　　　￣　　　　　　　　　＼＿＿＿＿＿＿＿＿＿
http://saitama.gasuki.com/kensuke/

399 ：あぼーん：03/04/10 02:53

400 ：かおりん祭り：03/04/10 02:54

http://www.saitama.gasuki.com/kaorin/
　　　　　　　こんなのございま－す♪
　　　　　　￣￣￣￣∨￣￣￣￣￣￣￣￣￣￣
　　　　　　　　～oノハヽo～
　 ,.-''"¨￣●`' ‐（＾▽＾）
　(,,●i,,,i,,,,,,,,i,,,,●),,)⊂　）
　　　）　　（　　　　|｜　| 　　
　　（＾▽＾）　　（_（＿_）
~~~~~ ￣￣ ~~~~~　　　 ~~~~~

401 ：デフォルトの名無しさん：03/04/10 06:53

>>396
>together（Togetherに限らず、最近のＵＭＬツールは全て）
>はＵＭＬしか書けないと思っています。
大体のUMLモデリングツールでERはかけます。
ＤＤＬも出ます。

>実際の開発だとユースケースシナリオ、ＥＲ図、用語一覧等ＵＭＬ以外の仕様書を
>作成する必要があると思っていますが、
実際の開発で全部作る必要は無いです。
特にユースケースなんていらないです。
でも、大体要件定義書で適当に定義しているから用語一覧は作ってないですけど、
確かにあったら便利ですね。

>ＥＲ図、用語一覧はＥＸＣＥＬだとかなり辛いと思いますが、
>実際どうなんでしょうか？
そんなことは無いです。
ＥＲ図なんか紙とペンありゃいくらでもかけます。
あとでExcelに表にして、こぴぺして置換してDDLを作っちまえばいいことです。

>またTogetherは一人で開発する際には良いと思いますが、
>複数チームで開発する際、複数人が作ったユースケース、クラス図全体を
>まとめる時はどうしたのでしょうか？
どうなんでしょうね。
バージョン管理システムに対応しているので、一応マージされるとは思います。
そもそも多人数で開発できるだけのTogetherのライセンスがある時点で、
かなりレア（リッチすぎ）な環境といえるのではないでしょうか。
それとも私が貧乏な環境で開発しすすぎなんでしょうか・・・。

402 ：U ◆CZtFsGiu0c ：03/04/10 12:01

>>396
>together（Togetherに限らず、最近のＵＭＬツールは全て）
はＵＭＬしか書けないと思っています。

実際UML書くのにしか使っていません。

>実際の開発だとユースケースシナリオ、ＥＲ図、用語一覧等ＵＭＬ以外の仕様書を
作成する必要があると思っていますが、
その他の設計書はＥＸＣＥＬ等で作成したのでしょうか？

設計書としてのメインはWORDで、それにTogetherで作った図を貼り付けています。
DBのテーブル設計書はExcelで作ることが多いですね。もしER図が必要なら多分
Visioで書くでしょう。もっとも論理レベルの設計はクラス図と重なるので
書くことはほとんどないです。

>またTogetherは一人で開発する際には良いと思いますが、
複数チームで開発する際、複数人が作ったユースケース、クラス図全体を
まとめる時はどうしたのでしょうか？

最終的には図をコピーして貼り付けるので別々に作っていても問題ありません。

>>401
残念ながらフローティングライセンスなので、常時使うわけにはいきません。
ただ社内では同じようにフローティングライセンスで導入されているRoseを
使う人が多いので、使いたいときに使えなかったことはないですが。

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

本当はユースケース分析がキモなんだよ、と言ってみるテスト。

404 ：383：03/04/11 08:57

>>391, 392, 395
ありがとうございます。やっぱそうなのかなあ。
すべてのユースケースが動く前提としていくつかの条件があったりして、
でも制御する側(ソフト)はそんなんあたりまえだろ、ってところが抜けるんですよねえ。
それを全部のユースケースに書くのは冗長だし。
392さんから指摘された、ステートチャートでシステムの状態を定義してから、それぞれの状態で"分類"された
ユースケースを書く、ってのがよさそうですね。(とすると、ユースケース駆動って考えかたとは違ってくる？)

391さんのところは、アクティビティ図を最初に書くってことだと、ある程度ソフトのワク(オブジェクト)が決まってる、ってことなんでしょうか？
それともドメイン間のアクティビティ図を真っ先に作る、ってことですか？

403さんに同意です。作成後の仕様変更(とユーザからの文句)が減るかな、と。
ただ、ユースケースからクラスへ落とし込むのに「職人技が必要(これといった方法がない)」だなあ、と感じます。

405 ：U ◆CZtFsGiu0c ：03/04/11 12:43

>>404
>ただ、ユースケースからクラスへ落とし込むのに「職人技が必要(これといった方法がない)」だなあ、と感じます。

今まで読んだ書籍の中でこの辺について一番説得力のある手法が書いてあるのは

http://www.amazon.co.jp/exec/obidos/ASIN/4894713772/250-0220809-4321855

これでした。名詞抽出法って馬鹿にする人結構いるけど、とっかかりとしては
有効だと思うんだけどな。

406 ：デフォルトの名無しさん：03/04/11 19:59

ピア村は珍訳が多いからなあ

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

>>405
を、懐かしいｗ
入門と言いつつも実践的な内容で、とっかかりとしてはかなりの良本だね。
ところでICONIXって今どうなんかなぁ。
ＸＰなんてやったら、こんなキッチリとはドキュメント作らないだろうし。

408 ：404：03/04/12 06:59

>>405
ありがとうございます。読んでみます。
原著の人、けっこいい本いろいろ書いてますよね。

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

このスレに居る奴なら、スリーアミーゴは押さえた方がいいな。
Chevy Chase、Martin Short、Steve Martinだっけ？
あとGang of Fourも外せないだろ。
John King、Andy Gill、Dave Allen、Hugo Burnhamはチェックしとけ。

410 ：デフォルトの名無しさん：03/04/13 13:58

EA買おうか迷ってるんだけど、使いやすいですか？
プロフェッショナルにしようと思うんだけど。
個人利用の予定です。

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

>410
体験版があるので自分で判断してみましょう…

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

>>410

あの価格帯ということなら満足。
昔Rose2000使ってたけど、それよりかEAのほうが数段マシ。
それ以降のRoseは使ってないので改善されているかもしれんけど。

413 ：409：03/04/15 01:56

なんで誰も反応してくれないんだよ！
渾身のネタだったのに・・・

414 ：U ◆CZtFsGiu0c ：03/04/15 12:08

>>409
ネタとしてはストレートすぎるのでは? あ、「四人組」ではないのがひねった
ところ? でもそっちのGoFは知ってる人少ないと思うぞ:-)

415 ：山崎渉：03/04/17 15:33

（＾＾）

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

UMLフォーラム2003の開催、運営をされた皆様、お疲れ様＆お世話になりました！

UML2.0標準化の勢いにのって、UML/MDA活用技術がより一層普及すれば良いですね。
冬のUMLフォーラムで、またお会いしましょう。。。

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

ロボコン、モデル部門で入賞したっす！（どこかは秘密）
素直にうれしかったです。

いわゆる第一人者の方々とお話ができたし、とても良い機会でした。
来年は・・・仕事が忙しくなければね（ｗ

418 ：山崎渉：03/04/20 03:12

　　 ∧＿∧
　　（　　＾＾）＜ぬるぽ（＾＾）

419 ：山崎渉：03/04/20 03:46

　　 ∧＿∧
　　（　　＾＾）＜ぬるぽ（＾＾）

420 ：デフォルトの名無しさん：03/04/25 23:15

クラス図でどう表現したら良いのか分からないものがあるので教えて下さい。

言語はdelphiです。（javaが分からないので）

・継承
TOb01 = class(TOb00)
end;

・集約（コンポジション）
TOb01 = class
ob : TOb00;
end;

ここまでは合ってますよね？
ではこれはどう表現すれば良いのでしょうか？

TOb01 = class
function a : TOb00;
procedure b( ob : TOb00);
procedure c;
end;

procedure TOb01.c;
var
ob : TOb00;
begin
ob.func;
end;

421 ：420：03/04/25 23:16

下げてしまった・・・

しかもインデントが出来てない・・・

422 ：デフォルトの名無しさん：03/04/25 23:50

>>405
名詞抽出法って真面目にやりだすと結構悩んじゃうと思うんですが。
あの頃の私が若かったからかもしれませんが…。

まぁでもあの本は面白いと思う。薄くて手頃だし。

423 ：デフォルトの名無しさん：03/04/26 00:45

赤伝票と黒伝票は同じクラスでしょうか？
それともそれぞれクラスにするべきでしょうか？

424 ：デフォルトの名無しさん：03/04/26 14:49

>>423
場合による

425 ：デフォルトの名無しさん：03/04/26 16:13

クラス図と実際のコードを併記しているHPなどありませんか？

426 ：デフォルトの名無しさん：03/04/27 16:15

>>420
あー俺も同じところで悩んでる

427 ：U ◆CZtFsGiu0c ：03/04/27 16:37

>>420
obはローカル変数ですね。だったら単なる依存関係じゃないですか?
setterっぽいbが気になりますが:-)

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

>>423
赤伝票と黒伝票で機能がそれぞれ異なるのであれば分ける。
ほとんど機能が同じなのであれば、同一のクラスにして区分で識別する。
ちなみに大体の伝票は金額の+と-だけで赤黒分ける必要は無いと思う。

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

>>425
デザインパターン紹介してるサイトとか

430 ：デフォルトの名無しさん：03/04/28 23:26

UMLブロンズで、適当な住所入力して合格してしまったんですが、
放置して大丈夫でしょうか？
最後エンター連打したら画面に認定証が・・・・・・・・

（つーかチュートリアル斜め読みとヤマカンで受かるとは・・(;´Д⊂）

431 ：420：03/04/29 13:53

>>427
TOb01 = class
　function a : TOb00;
　procedure b( ob : TOb00);
　procedure c;
end;
procedure TOb01.c;
var
　ob : TOb00;
begin
　ob.func;
end;

これらa,b,cのメソッドをクラス図でどう区別するのかが分かりません。
全部依存になってしまうんですかね？

あと私の理解では、メソッドcのローカル変数obがグローバル変数なら
TOb00とTOb01は関連になると思っていますが、合っていますか？

ちなみにRationalRoseでコード生成すると依存にすると全く
TOb01クラス内でTOb00が使われていません。

関連にするとステレオタイプをincludeにしても extendにしても
（ステレオタイプを設定しなくても）
TOb01の属性としてTOb00が使われているみたい
↓（つまりこうなる）
TOb01 = class
ob : TOb00;
end;
（これは集約じゃないのかな？）
（っていうか集約にしてもコードには変化なし）

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

これは読んだ？
【改訂版】初歩のUML
http://www.atmarkit.co.jp/fjava/devs/index/

433 ：420：03/04/29 14:26

>>432

いや、読んでませんでした。
じっくり読んでみます。
ありがとうございました。

434 ：420：03/04/29 18:38

>関連の線だけのものと、関連の線に集約をつけたものを実装コードに落とす際に
>明確な違いはありません。

>UMLを単なるソースコード自動生成CASEツールの表記法だと
>思っている方も多かったのではないでしょうか？

うむむ。そうだったのか。
「ソースコードを作るさいの骨組み」と「モデルを理解するための手段」が同時に
成り立つのだと思ってると失敗するみたいですね。

435 ：U ◆CZtFsGiu0c ：03/04/30 01:20

>>430
>あと私の理解では、メソッドcのローカル変数obがグローバル変数なら
TOb00とTOb01は関連になると思っていますが、合っていますか？

グローバル変数ってフィールド変数の間違いですか? ならなんらかの関連を持つ
でしょうね。グローバル変数が間違いでないのなら、それも単なる依存関係です。
＃Delphiってフィールド変数であってたっけ?

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

クラス図のメソッド書くところ、コンストラクタって書かないんですか？
俺の持ってる本には書いてない。
意図的に書かないのか、単なるヌケなのか、教えてください。

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

「コンストラクタ」なんて言う言語依存の仕組みは、
それこそケースバイケースで書く書かないを決めるしかあるまい。

438 ：420：03/05/02 13:53

>>435
>グローバル変数ってフィールド変数の間違いですか?
> ならなんらかの関連を持つでしょうね。
え？それって>>420の集約になるんじゃないですか？
（集約も関連の一種ですが・・）

グローバル変数なら依存になるんですね。
interface
type
TOB00=class
procedure func1;
end;
TOB01=class
procedure func2;
end;
var
ob : TOB00;//グローバル変数
implimentation
procedure TOB01.func2;
begin
ob.func1;//ここで使うと依存？
end;

439 ：U ◆CZtFsGiu0c ：03/05/02 16:28

>438
>え？それって>>420の集約になるんじゃないですか？
（集約も関連の一種ですが・・）

クラスのメンバだってだけで集約になるとは限らない。あくまで集約は
全体-部分の関係にある関連を指す。実装上の都合で集約関係にないクラス
のインスタンスをメンバに持つことだってある。

>グローバル変数なら依存になるんですね。

こっちもそうだけど、実装上こうだから何々という関連になる、という
考え方は危険だよ。

440 ：420：03/05/05 16:04

>>439
＞こっちもそうだけど、実装上こうだから何々という関連になる、という
＞考え方は危険だよ。

という事はリバースエンジニアリングを頭の中でやるのは止めた方が良いという
事ですか？

どうも実装の方向から考えてしまうのですが、これがそもそも間違っているんですかね（＾＾；

システム設計時のクラス図でもコードと一意に考えない方が良いのですか？

そうだとするとクラス図とコードの関係ってけっこう曖昧なものなんですね。

（
多重度であらわすとこんな感じ？
　　　クラス図上の表現 1..* --- 1..* 実際のコード
）

441 ：デフォルトの名無しさん：03/05/05 16:07

http://www.yahoo2003.com/betu/linkvp2/linkvp.html

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

>>440
コードと一対一のクラス図を作ることも出来るよ。
開発手法によるけど、分析-設計-実装にアクティビティが分けられる手法では、
各アクティビティごとにクラス図を作って、徐々に洗練させていったりする。
あくまで開発上の道具なのでどう使おうと構わない。

コードと一対一だと、作り終わった後にドキュメント用として生成するくらいしか使い道なさげ。
（まあ、Together みたいな使い方もあるけどね）

443 ：U ◆CZtFsGiu0c ：03/05/06 04:19

>>440
>という事はリバースエンジニアリングを頭の中でやるのは止めた方が良いという
事ですか？

いや自動的にこうなる、と考えるのがまずいんで、「考える」のはまずくないです。

>どうも実装の方向から考えてしまうのですが、これがそもそも間違っているんですかね（＾＾；

クラスの関連、という概念をもう一度見直したほうがいいと思います。

>システム設計時のクラス図でもコードと一意に考えない方が良いのですか？
>そうだとするとクラス図とコードの関係ってけっこう曖昧なものなんですね。

クラス図からコードへはほぼ自動的に変換できますが、逆はそうではない、という
ことです。

444 ：420：03/05/06 13:17

>>442
＞あくまで開発上の道具なのでどう使おうと構わない。

これは理解しているつもりなのですが、どうもまだ頭が固いみたいっす。

>>443
＞クラス図からコードへはほぼ自動的に変換できますが、逆はそうではない、
＞ということです。

私はこの辺がまだちゃんと分かっていないみたいです。
（何が分からないのか分からない状態になっているのかも（＾＾；）

もっと勉強せねば・・・

445 ：デフォルトの名無しさん：03/05/14 15:48

C++のプロジェクトに使えてIIOSS並のフリーのUMLツール無いですか？

446 ：デフォルトの名無しさん：03/05/14 15:52

>>445
こういう根性のやつは気に入らない。
金くらい出せよ(怒)

447 ：デフォルトの名無しさん：03/05/14 19:08

しかし、気の利いた UML ツール作れれば商売になるよな。
UML ツールも 100 以上出てるけど、これだってのがない。

448 ：デフォルトの名無しさん：03/05/14 23:05

>>447

自分的にはEAっすね

449 ：デフォルトの名無しさん：03/05/14 23:07

EAってMagicDrawとかと比べてどこが凄いの？

450 ：デフォルトの名無しさん：03/05/14 23:23

>>449

MagicDraw :
スタンダード版（￥48,000～）デザイン・ツールのみを必要する開発者に適した製品です。
プロフェッショナル版（￥140,000～）コード生成、リバース・エンジニアリング、ラウンド・トリップ・エンジニアリング機能を必要とする開発者に適した製品です。
年間メンテナンス契約は￥16,000～

EA:
デスクトップ版
1ライセンス以上4ライセンス以下 13,000円
5ライセンス以上19ライセンス以下 11,000円
20ライセンス以上100ライセンス未満 10,000円

プロフェッショナル版
1ライセンス以上4ライセンス以下 21,000円
5ライセンス以上19ライセンス以下 19,000円
20ライセンス以上100ライセンス未満 17,000円

451 ：デフォルトの名無しさん：03/05/15 00:56

既存のソフトがどんな設計しているのか知りたいのですが、
UMLによる設計図付きのオープンソースソフトウェアって無いですか？

452 ：デフォルトの名無しさん：03/05/15 02:16

風林火山

453 ：デフォルトの名無しさん：03/05/15 02:38

UNIX ユーザで Dia 使ってる方は多いと思いますが、
日本語をちゃんと扱えるか、とか、Windows 版の動作とか、どうでしょうか？

454 ：デフォルトの名無しさん：03/05/15 06:35

448ですが、

>449
Tnx

結局、個人で買おうとなると他のものは手が出ないので
EAか1stModeler・あとはフリーor安いJava製くらいの選択肢しかない。

自分的にJavaは重くていやなので、EAと。満足してます。

455 ：デフォルトの名無しさん：03/05/15 20:47

>>454

大規模PJ(100名規模)で使うにしても、業務SEみんなで使おうとしたら、
モデリングツールだけで数千万とかになってしまう。

EAなら、100人で同時に使っても100万強ですむしね。

456 ：デフォルトの名無しさん：03/05/15 23:09

サイトライセンスとかフローティングライセンスとか、
大人数向けのライセンス用意しているとこもあるかと。

457 ：デフォルトの名無しさん：03/05/15 23:28

>>456

サイトライセンスとかフローティングライセンスとか大人数向けのライセンスを
用意しているところは、100人が使っても100万強ですむのですか？

http://www.rational.co.jp/pdf/price/PL-ROS-020701.pdf

458 ：デフォルトの名無しさん：03/05/16 06:31

>456,457

結局、捨てるほど金があるところじゃないと
RoseやVisioでの大規模開発なんてできないでしょ

割引をして>455の値段(数千万)になれば万々歳。

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

なんてUMLってクラスのメンバをメソッドとかフィールドって呼ばないで属性とか
持って回った言い方するのかな？もっと言語に近づいて一対一の表記しないと
誤解によって生まれたUMLのイデイオムが広まったりしないのかな。

460 ：U ◆CZtFsGiu0c ：03/05/17 09:50

>>459
>なんてUMLってクラスのメンバをメソッドとかフィールドって呼ばないで属性とか
持って回った言い方するのかな？

実装言語に依存しないようにしてるからでしょ?

>もっと言語に近づいて一対一の表記しないと
誤解によって生まれたUMLのイデイオムが広まったりしないのかな。

よくわからんが、どういう誤解が生じると?
それと言語に近づくって、どの言語に近づくの?

461 ：デフォルトの名無しさん：03/05/17 11:05

ほれ、一覧にしてやる。

UML：属性、操作
C++：メンバ変数、メンバ関数
Java：フィールド、メソッド
Delphi：フィールド・プロパティ、メソッド
C#：フィールド・プロパティ、メソッド
Eiffel：属性、ルーチン
Smalltalk：インスタンス変数、メソッド
objective-c：インスタンス変数、メソッド
Ruby：インスタンス変数、メソッド
ECMAScript：プロパティ、メソッド

462 ：デフォルトの名無しさん：03/05/17 15:40

>>459

意味に対して作業すれ。設計とかプログラミングとかな。
具体的な名前や実装なんぞ後回しでヨイ。

どーしても具体的な名前や実装でないと
しっくりこない、うまく行かないなら残念ながら適性がない。
具体的な名前や実装なんぞに頼らんでも
うまく意味を伝えられる能力は必要だ。
そのための統一価値観がUMLの本質だからな。

ま、相手がダメ野郎で回避不能だとけっこうツラいけど……。
それはUMLのせいではない。

463 ：デフォルトの名無しさん：03/05/17 21:31

>>461
C++のコンストラクタとデストラクタ、JavaのコンストラクタはUMLでは何ていうの？

464 ：デフォルトの名無しさん：03/05/17 21:37

>>463
操作。
インスタンスを生成する操作だと明示するためにはステレオタイプを使う。
http://www.atmarkit.co.jp/fjava/devs/jobjmdl04/jobjmdl04_3.html

465 ：デフォルトの名無しさん：03/05/18 03:40

>しっくりこない、うまく行かないなら残念ながら適性がない。
>具体的な名前や実装なんぞに頼らんでも
>うまく意味を伝えられる能力は必要だ。

根底にある思想はオブジェクト指向だよね。もしそれを理解してない、あるいは
使えないSEがいたら混乱するんではないかなという話です。それと言語に対して
あまり抽象化しすぎるとかえって理解する手間が掛かる、言語との一対一の
ダイアグラムが見えづらくなる気がしたもので。もともとUMLの存在意義はシステム
のクラスやオブジェクトの関わりを直感的に図示するためにあるのでしょう？それを
手軽に扱えないようだと困る。
クラス図レベルのようなものはオブジェクト指向言語を扱っている人なら表記は違えど
頭の中に持っているイメージだと思いますが。
例えばUMLをJavaとかRubyとかObjectPascalとかそれぞれの言語用に定石を分けた
ほうがかえって分かりやすい気がします。UML for ObjectPascalみたいな。

466 ：デフォルトの名無しさん：03/05/18 08:39

>>465
オブジェクト指向自身は、実装に依存してはいけない概念だと思う。
さらに言うと、「言語を超えて(言語を知らなくても)」理解できることが重要なんではないのかなあ。
つまり、実体はJavaで書かれているものを理解してSmalltalkで作り直す、とか言うときに、直接
Javaを知らなくても(概念は)理解できる、とか。
こうやって(設計レベルの)知識を蓄積(継承)できるのがUMLのエラいところだと思うけど。

467 ：465：03/05/20 17:03

>466
私は抽象化しすぎるのは反対。現実にC++とJavaでは多重継承とインターフェース
の違い等あると思います。多重継承をしない言語系の違いでも大分異なる
クラスライブラリが出来ると思います。
これら言語の特徴を避けて統一的な表記、表現は無理じゃないかと思います。
現実に異なる処理系でプログラムを移植する場合には双方の処理系の理解が無ければ
不可能ではないですか？私はそう思っています。私は明確にある特定の
オブジェクト指向言語が理解できてないとUMLを使うことはできないと思います。
抽象化しすぎるとかえって細部が見えにくくなり、実装に偏りすぎると全体像が
見えにくくなるという事はあると思います。宇宙の創世についての説明を科学的根拠に
基づいて説明をするという手順を踏まなければ正確な物事を理解することはできないと
思います。もしこれらの説明を極端に抽象化すると「神は言われた、光あれ、そして宇宙が
始まった」という事になってしまわないでしようか。
私は処理系自身が主役でUMLはツールであると思います。

468 ：U ◆CZtFsGiu0c ：03/05/20 18:33

>467
すまんが、何を言いたいのか結局よくわからない。

>これら言語の特徴を避けて統一的な表記、表現は無理じゃないかと思います。

よくわからんなあ。現在のUMLツールなら、属性の型や操作のシグネチャを特定の
プログラミング言語対応に設定できるけど、それでは不満なの?
もしかして分析レベルのモデルと設計レベルのモデルをごっちゃにしてない?

そもそも「属性」や「操作」といった用語があるくらいで理解が困難になるもの
なの? そんな人が「モデリング」なんてできるの?

469 ：デフォルトの名無しさん：03/05/20 19:11

つーか、UML とコードと全く同じ内容なら、コードだけでいい。

470 ：デフォルトの名無しさん：03/05/20 22:34

>>469

UMLとコードが同じなら、コードとダイアグラムの同期がとれて
書き換えが楽になるのではないかと。

MDAで開発しているからそう言えるのかもしれんが

471 ：デフォルトの名無しさん：03/05/21 00:38

>>470

コードとダイアグラムの同期がとれて
何がうれしいのかと。

472 ：デフォルトの名無しさん：03/05/21 07:05

>>471
470じゃあないけど、「動くものが視覚化できる」のは大きいと思うけど。

ソース読め、よりは理解する時間が短くて済みそう。

473 ：デフォルトの名無しさん：03/05/21 19:37

>>472
情報が多すぎてソース読む方が「コンパクト」な分だけマシになる

474 ：デフォルトの名無しさん：03/05/21 19:59

ユースケース(シナリオ) <-> コラボレーション/シーケンス <-> クラス <-> コード
の同期が取れれば嬉しい。
シナリオの一部を選択すると、その範囲でのシーケンス図やクラス図が表示できるつー感じで。

475 ：デフォルトの名無しさん：03/05/21 20:58

>>471
>>472

使っているツールが Rose RealTime なので、

　UML（ClassとState Chart）＋プロパティで書いたC++コード

がソースコードとして自動生成されます。ROOM法に則った書き方
でかつ付属のフレームワーク上で動かすから楽なだけなんだけどね
（CodeSync機能もあるよ・・・限定された部分だけだが)

ROOMの書き方はUML 2.0で標準(？)になったみたいだから、UML
と呼んでいい・・・よね？（ｗ

でも、１ライセンス110万円、フローティングで150万円でつ

476 ：デフォルトの名無しさん：03/05/22 02:46

PatternWeaverのコミュニティエディションって、
フリーなんですか？それとも試用版なんですか？
どこみても書いてないもんで。
書いてないってことはフリーなのかな

477 ：デフォルトの名無しさん：03/05/23 00:36

>>476

どこ読んでるのかしらんが、日本語理解できないのか？

各Editionの位置づけ
Community Editionの制約
http://www.tech-arts.co.jp/product/pw_ce.html

Community Edition は優れたモデリング言語であるUMLを普及させることを目的に機能制限付きで配布しているバージョン

478 ：465：03/05/23 19:33

>>これら言語の特徴を避けて統一的な表記、表現は無理じゃないかと思います。
>
>よくわからんなあ。現在のUMLツールなら、属性の型や操作のシグネチャを特定の
>プログラミング言語対応に設定できるけど、それでは不満なの?
>もしかして分析レベルのモデルと設計レベルのモデルをごっちゃにしてない?

オブジェクト指向という概念は抽象的であるべきという意見に対して私は、言語
レベルの実装や試みの方がUMLよりも先を行っていますよ、という事を言いたかった
のです。CASEツールのような側面ばかり強調されるのは何か間違っていると思います。
それと設計やモデリングといいますが、言語レベルでクラスを使いこなせない人が
設計や分析など安易にさせ易いような印象を各種情報をみて感じました。これらに
ついては不満ですね。

479 ：デフォルトの名無しさん：03/05/23 23:09

ああそうですか。あなたはあなたの道を勝手に進んでくださいよ。

480 ：465：03/05/23 23:29

言いたいことはそれだけですか。これだからダメなんです。
もし言語レベルでクラスを扱う事ができなければ設計やモデリングなどという概念
のかけらすら芽生えないでしよう。これはクラスが分かっていなければ対象となる
事象の本質を突くことすらできないことを物語っています。
さらにいうと各言語には個性的な特徴を持ちます。Perlのようなスクリプト思考の
オブジェクト指向言語の使いやすさをC++に求めることはできない。それらを設計の
段階からUMLというメタなもので統一しようとする概念はどこか現実とそぐわないと感じます。
UMLの発展はメタな概念からコードに落とすという過程から生まれたものではない
ですね。UMLについては否定していません。むしろUMLとオブジェクト指向との関係
に対する理解がおかしいと感じたまで。再度UMLとオブジェクト指向に対するシステム
分析をされてはいかがですか？

481 ：デフォルトの名無しさん：03/05/23 23:39

いやいや、全くあなたのおっしゃるとおり。すばらしい。

482 ：デフォルトの名無しさん：03/05/23 23:48

>478
プログラミング言語レベルの話は、いってみれば"戦術"で、UMLなどのモデリングの話は"戦略"って感じで、
話がかみあってないように感じる。
# >468さんの言ってる、” もしかして分析レベルのモデルと設計レベルのモデルをごっちゃにしてない? ”
# ってことと同じ意見かな。

>478さんの理想とする世界と、UMLが目指す世界は違っているのではないかなあ。

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

ｿﾝﾅｺﾄﾐﾝﾅﾜｶｯﾃﾙﾝﾀﾞｯﾃ
ﾃﾞﾝﾊﾟｦｱｲﾃﾆｼﾃﾀﾗｷﾘｶﾞﾅｲﾝﾀﾞｯﾃ
ﾀﾞｶﾗｼﾊﾞﾗｸﾀﾞﾏｯﾃﾛｯﾃ

484 ：482：03/05/23 23:55

あら、書いているうちに。

>>480
メタなもの、っていうとそれはUMLではなくMDAではないの？

UMLは、しょせん"言語"なんだと思っているんだけど、違うのかな？

485 ：デフォルトの名無しさん：03/05/24 00:25

私の意見としては、実装よりのUMLも欲しいと思う。
実装できない設計と同じで、実装できない(むずかしい)モデル化をしても
困るから。

UMLは言語に依存していないがゆえ、自分の使う言語に沿った表記もできる。
業務→概念レベル⇒実装レベル→実装
とやった時、UML以前よりも、⇒部分の「表記法上の壁」が低くなってると思う。
それだけで儲けもの。

486 ：デフォルトの名無しさん：03/05/24 00:33

表記法上の壁って何？

487 ：デフォルトの名無しさん：03/05/24 02:38

有償ソフトウエアでメジャーなUML設計ツールを教えてください。
５万以下で購入できるものを探しています。

これはどうなんでしょう？実績はあるんでしょうか？
http://www.sparxsystems.jp/ea_features.htm

488 ：デフォルトの名無しさん：03/05/24 03:05

OMTでいいじゃないですか。

489 ：デフォルトの名無しさん：03/05/24 03:07

>>488
独り言？

490 ：デフォルトの名無しさん：03/05/24 07:47

>>487

うちの会社それ使ってますよ。けっこうｲｲ!です
最初別の部署が使っていて、社内で横展開されていってます

っていうか、5マソ以下の有償ツールって他にあるの？
10マソならいろいろ選択肢あるけど

491 ：デフォルトの名無しさん：03/05/24 18:55

ツール乱立しているけど、どうせＭＳとＩＢＭに根こそぎ持ってかれるんだろうなぁ

492 ：U ◆CZtFsGiu0c ：03/05/25 16:43

>>478
>オブジェクト指向という概念は抽象的であるべきという意見に対して私は、言語
レベルの実装や試みの方がUMLよりも先を行っていますよ、という事を言いたかった
のです。

えーと、先を行っているというのは「何が」?

>CASEツールのような側面ばかり強調されるのは何か間違っていると思います。

その通りですね。

>それと設計やモデリングといいますが、言語レベルでクラスを使いこなせない人が
設計や分析など安易にさせ易いような印象を各種情報をみて感じました。これらに
ついては不満ですね。

同感ですね。でもそれはそのような文章を書く人の責任で、UMLの責任ではないのでは?
もしかしてMDAとかActionSemanticsとか最近のUMLの拡張について不満があるのかな?

それで、UMLをもっと実装言語よりにすると何がよくなるんでしょうか。あなたの最初の
主張はそういうことでしたよね?

493 ：デフォルトの名無しさん：03/05/25 16:48

ﾔﾒﾃｯﾃｲｯﾃﾙﾉﾆﾅｾﾞｷｲﾃｸﾚﾅｲﾝﾀﾞﾛｳ

494 ：デフォルトの名無しさん：03/05/26 13:14

読みにくいんだもん

495 ：デフォルトの名無しさん：03/05/26 22:51

点線の矢印「依存」と実線の矢印「関連」の違いを教えてください。
「依存」の方は、メソッド内で使う場合のみってことのようですが、それでいいんでしょうか。
矢印つきの「関連」は、（Javaで言えば）フィールドみたいな場合かと思うのですが、
そうすると「集約」との違いがわからなくなります。

496 ：デフォルトの名無しさん：03/05/26 23:39

>>495
「関連」はクラスがインスタンス変数として相手のオブジェクトを保持すること
「依存」はオブジェクトをインスタンス変数としては保持せずに一時的に、
メソッドのパラメータ、戻り値、ローカル変数として参照すること。

「集約」は「関連」の特別な形状。実装上は同じだから区別しなくて良い。
ただし「コンポジション」は保持しているインスタンス変数のオブジェクトライフサイクルを管理しる

497 ：デフォルトの名無しさん：03/05/27 00:42

概念モデル、仕様モデル、実装モデル
それぞれで関連のニュアンスは違ってくる

>>496 のは実装モデルのお話しだな。
関連 = 属性　だなんて思いこんじゃ駄目。
概念モデルの関連が実際にで属性になるか、操作の引数になるかは実装レベルのお話し。

集約とは、インスタンスの寿命が、それと関連するインスタンスの寿命に
引きずられるような場合をいう。完全に一致するとコンポジション。

498 ：デフォルトの名無しさん：03/05/27 23:04

ユースケースって業務フローが書けないと思うのですが、
みんなはどうしてますか？
アクティビティ図ですか？
ここら辺にＵＭＬの限界があるような気がします。

499 ：デフォルトの名無しさん：03/05/28 00:17

>>498
シナリオ書け

500 ：デフォルトの名無しさん：03/05/28 00:42

>>499
言葉足らずで申し訳ないです。
ユースケースでの業務フローといっているのは、
ユースケース間のフローのことを言っています。

501 ：デフォルトの名無しさん：03/05/28 00:44

分析シーケンス図

502 ：デフォルトの名無しさん：03/05/28 01:16

>>498

UMLでわざわざ書くなら、アクティビティ図

UMLではめんどくさいので使っている業務フロー記法そのまま、というのもありだと
おもってるでし。

503 ：山崎渉：03/05/28 12:32

　　　　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾）＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

504 ：デフォルトの名無しさん：03/05/28 12:37

関連クラスを扱えるツールってないですか？

505 ：デフォルトの名無しさん：03/05/28 21:08

>>504

普通扱えるんじゃないの？

506 ：デフォルトの名無しさん：03/05/28 21:29

関連クラスってどういう意味だ？

507 ：デフォルトの名無しさん：03/05/28 21:33

どういう意味って・・・クラス間の関連をクラスにしたもの

以下のページを参照して下さいな

http://www.ogis-uml-university.com/tutorial/design/do_work/do_work4_2.htm

508 ：デフォルトの名無しさん：03/05/28 21:40

ああ、はいはい。
ステレオタイプ付けるんじゃだめなの？

509 ：デフォルトの名無しさん：03/05/28 23:38

>>504
別に関連クラスなんて使わなくても通常のクラスの関連に変換してしまえば良いのでは？
むしろ関連クラスを使うと余計分かりづらい気がします。

510 ：デフォルトの名無しさん：03/05/28 23:44

会社の金でRational Rose買いました。使い方わかりません。鬱。
誰かサイトか何か教えて。

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

サイトより先にここのスレを全部読んでみてはいかが？

512 ：デフォルトの名無しさん：03/05/29 21:49

Roseを習得するなら、ひたすら使い込むしかないんじゃない？

513 ：510：03/05/29 22:48

>>511　>>512
使い方がわからんのです。
たとえば、「メソッドを抽象にする」なんてことすらどうすればいいかわかりません。

俺はばかなんです。上の人にはそれがわからんのです。

514 ：デフォルトの名無しさん：03/05/29 22:53

とほほ・・・

Ｒｏｓｅ云々の前に、前提としてモデリングやＵＭＬは
理解してるんですよね？

　「ＵＭＬモデリングのエッセンス」

でも読みながら、地道に勉強してつかわさい

515 ：デフォルトの名無しさん：03/05/29 23:19

>>513
ツールの使い方ではなくてＵＭＬの表記法がまだ理解できていないのでは？

516 ：デフォルトの名無しさん：03/05/29 23:45

だからとりあえずスレを全部読めって･･･

517 ：デフォルトの名無しさん：03/05/29 23:56

画面遷移図をUMLで書くとしたら、やっぱりステートチャート図？

518 ：510：03/05/30 00:01

>>514
>>515
通じてない？プログラマの人ではない？
UMLはわかってるつもりですが？ブロンズくらいには。（ｗ

たとえば、抽象メソッドは、普通イタリックでそ？
ま、表現はいいんだけど、Roseで、それをどう指定するかなんかがわかんないってな話なんだけど。
そーゆーのができないとコード生成しても、結局、手で修飾子を書くはめに。

519 ：デフォルトの名無しさん：03/05/30 00:06

>>513 の書き方じゃ、
表記法が分からないのか、ツールの使い方が分からないのか
分からないでしょ。
まぁそれは置いておいて、
ツールの使い方がわからないなら、マニュアル読むしかないんでないの？

520 ：デフォルトの名無しさん：03/05/30 00:16

＞通じてない？プログラマの人ではない？
＞UMLはわかってるつもりですが？ブロンズくらいには。（ｗ
ハァ、どういう育ち方したらこういう人間になるんだかね。
通じないのはてめえの文がﾜｹﾜｶﾗﾝからじゃねえかよ。

521 ：デフォルトの名無しさん：03/05/30 00:23

>>519
マニュアル？そんなのあるの？
インストールガイドやら、キー管理やらはあったけど。
あ、ソースCD？

>>520
使い方がわからんって書いてるじゃん。最初から。ポケェ。
なんちゃて。まあ、落ち着いて仲良くやろうや。

522 ：デフォルトの名無しさん：03/05/30 00:28

このやろう・・・自分が悪いとはかけらも思っちゃいないんだな
だからー、お前の文の書き方じゃ515が言うように
＞ツールの使い方ではなくてＵＭＬの表記法がまだ理解できていないのでは？
としか思えねえんだよ！
それに加えてこの横柄な態度・・・。

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

>>521
PDF のマニュアルが入った CD があるはずだが？

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

>>522
>このやろう・・・自分が悪いとはかけらも思っちゃいないんだな
だって、悪くないもんさ。
横柄だったら、すまんかった。

>>523
ありがと。そんな感じのCDあったような。
明日会社で確かめる。

また、わかんないことがあったら、聞きに来るよ。

525 ：デフォルトの名無しさん：03/05/30 02:01

UMLがわかりにくい理由
１、まずＵＭＬをかけてもコードの実装がもうひとつはっきりしない
　　実装例も少ない（最近、すこしずつ本で見かけるが）
２、Ｊａｖａでは関連と集約を区別しないといってもね（純粋に意味上の問題）
　　もし間違えて書いたらどうなるの？なんかやばい？意味上で区別するだけ
　　他の言語では区別するの？
３、ＥＲ図との関連がわかりにくい。ＤＢのフィールドはすべてプロパティ
　　にしなければだめんなの？
４、単純な処理ならＵＭＬ面倒なんですけど（ｗ
　　少なくともマスタ処理なんかはいらないような気がする。
　　ＸＰでもＵＭＬ書かない見たいだし（ケントベックは書かない見たいだし）
５、シーケンスなんて書いてもよく代わるんですけどそのたびに書き直すの？
６、ＤＢで１対多のリレーションがあるときＵＭＬでは継承になるの？
そのほかにも疑問が一杯。
いまいちメリットがみえてこない。あっ私厨房ですから（ｗ

526 ：デフォルトの名無しさん：03/05/30 02:27

>>525
その柔軟性がUMLの良いところでもあると思うのだが。
１～６の質問は、すべてモデリングする人によって違うし。

527 ：デフォルトの名無しさん：03/05/30 03:27

>>525
そうそう。
おいらも実際UMLを使った開発を行ったことがないので、
同じようなことが判らない。
書籍を見ても>>526さんのように抽象的になってるし。
書籍ごとに言っていることが違う場合もあったり。

恐らくUMLを使った開発プロセスがまだ発展途上状態だからですかねぇ。

ちなみにおいらの意見としては下記のとおり。
１．同意です。
　　クラス図だけじゃ書けないでしょう。設計者と実装者が違うときどうしてんだろう。
　　恐らく、関数仕様書的なものが必要だと思われます。
２．多分これは区別しなくても問題ないでしょう。ただ単に意味上区別するだけだと思います。
　　ただコンポジションはライフサイクル管理といった点で区別すべきだと思います。
３．確かに。
　　ER図とクラス図のマッピングをどう作るか？謎です。
　　恐らくクラス図→ER図か、ER図→クラス図のどっちかだと思います。
　　DBのフィールドは基本はすべてインスタンス変数に持つべきだと思います。
４．これは書くべきだと思います。
　　設計者と実装者が異なる場合や、ユーザとの意識合わせ、引継時資料として。
５．う～ん。悩むところですねぇ。
　　イテレーション開発と関係してくるのかもしれませんが。
６．これは「関連」でしょう。UMLでも多重度はあらわせますし。

528 ：デフォルトの名無しさん：03/05/30 03:28

ちなみに私の疑問も追加します。
実際に開発した方がどうやったかといった意見がいただきたいです。
ちなみに私も厨房です。

７．システムをどう分割するか？
　　　ユースケース単位？ドメイン単位？

８．設計段階ではUML図はすべて半角文字になっているが、
　　分析時にはどうすべきか？
　　　分析時から半角文字？分析時は全角日本語表示＋半角文字変換？
　　　半角文字変換は手動でやるの？

９．クラス図はどの単位で作成するの？

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

ついでに便乗質問。
ＭＶＣのところとＵＭＬがいまいち理解しにくい。
シーケンス図はかけるけど本当にこれでいいのて感じ。
それと基本的にはRoseなんかはクラスからコード生成しているみたいだし
ＵＭＬと実装は一対一に対応するとおもうけど必ずしも対応しなくても
いいという人がいたり実際どうなの？
ＵＭＬあって実装するときどの点が便利なん？
クラス図・・・これはなくてはコードがかけないからだれでも書くと思う
シーケンス図・・・これもオブジェクト同士の関連から便利
他はなんか単にいまあまであった仕様書をマンガチックにしたもの
みたいなんでメリットがみえない。
とくにＥＲ図とクラス図とＸＭＬ。なんか関係がいまいち見えてこない。
ついでにデザインパターンとＥＲ図とクラス図の関係。
やっぱみえてこない。
あっ、ただ仕様書だからこれをかけばいいよていえばかけるよ
このＵＭＬの仕様書どうりかえばいいんだから。
ただ実装のときに本当に役にたつのか？
実装経験者にきいてみたい

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

自作自演か？
しかも、問題集の答えをすぐに見ちゃうタイプのようだな（ｗ

531 ：デフォルトの名無しさん：03/05/30 07:09

>>528
>>７．システムをどう分割するか？
>>　　　ユースケース単位？ドメイン単位？

システム?
一個一個ユースケース単位で分割するアホがいるのか？
適当に要件にあわせて分割してくださいませ。

>>８．設計段階ではUML図はすべて半角文字になっているが、
>>　　分析時にはどうすべきか？
>>　　　分析時から半角文字？分析時は全角日本語表示＋半角文字変換？
>>　　　半角文字変換は手動でやるの？

最初から最後まで全部日本語でやれや。

>>９．クラス図はどの単位で作成するの？

主に全体と機能。

532 ：デフォルトの名無しさん：03/05/30 08:51

>>525
ちょっと自分自身が行った回答に異論もあるんだが(w、話のネタとして。
---
1. RoseやRhapsodyでコードは自動生成。無問題。＜コードを直したら、その結果からUMLを自動修正、無問題。
2.デザイナの考え方を残す意味あいがつよいのでは？間違えると、保守で大変なことになるかもしれない。
3.この２つは、概念がちと違うような気がする。(可換ではない、という意味)
JavaでC++でポインタを使って書いたとこをどう変えたらよいのか？という質問に似ているような感じを受けた。
4.逆に、コードを書くのが面倒。UMLで仕様書と実体の両方表現できるし。
5.同上。煩雑にシーケンスが変わるのなら、それこそ「仕様書と実体」の整合性をとるのに無駄な労力が必要。
6.実装依存。(普通の関連で表現しても良くない？)
>>528
7.システム分割は、ユースケースとは別の世界で行った方がよさそう。
個人的には、eUMLの分け方で良いと思った。
8.運用問題。ガイジンが一人でもメンバにいれば、仕様書にすら全角文字は入れられんし。。。
9.いろんな単位(粒度)がありそう。個人的には、サブシステム/ドメイン単位かなあ？

533 ：U ◆CZtFsGiu0c ：03/05/30 14:18

なかなか面白い話題ですね。
>>525
1. UMLだけでは機械的に実装できないでしょうね。あくまでUMLはモデリング
言語ですから。
2. 区別する必要があればするし、しなくてよければしないだけ。まあコンポジション
でなければそれほど意識する必要はないかな。
3. DBのフィールドはDBの都合でついてるものもあるから、単にテーブルをクラス
にマッピングしてもダメですね。既存のDBがある場合はまずはドメインモデルを
作ってみてからどうやってマッピングしていくか考えた方がいいです。
4. 新規にマスタ管理をつくるのなら他の部分と別にする必要はないと思うけど。
XPでもホワイトボード使って設計会議やるときにはUML使って書いたりするでしょう。
それにXPではプロジェクト内でコミュニケーションするときに原則的に文書を
使わないってだけで成果物としてドキュメントが要求されていればUMLで書くでしょう。
5. うーん、設計と実装ってどうやってやってますか? ドキュメントが要求される
タイミングによりますね。
6. …素直に考えると1対多の関連になりませんか?
>>528
7. システムの分割? それは主に性能要件などの非機能要件に関わることなので、
ユースケースやドメインとは別問題でしょう。
8. 分析時は通常日本語です。変換は手動です(たいした手間じゃないし)。
9. ユースケース単位で作成します。この辺はツールの助けがないときついですね。

534 ：デフォルトの名無しさん：03/05/30 23:57

すいません。
７．システムをどう分割するか？
　　　ユースケース単位？ドメイン単位？

システムの分割とは構造化設計時の機能分割の意味合いです。
大規模で開発する際は、ある程度にシステムを分割してそれぞれの担当者に割り振ると思うのですが、
それをどのように分割するかということです。
やっぱりユースケース単位に分けるべきなのでしょうか？

535 ：デフォルトの名無しさん：03/05/31 00:33

>>534
eUML読んでみるとよいかも。
ざっくりと、「アプリケーション」「ユーザインタフェース」「メカニズム」「ドライバ」の４つに分かれる、とのこと。
ユースケースの関係は、通常「アプリケーション」でしかあらわれないと思うけど。
言い換えると、入力と動作はユースケースとは別の次元になるってこと。
# みてくれはどう変わろうと、本質的にやりたいことは変わらない、と。

536 ：デフォルトの名無しさん：03/05/31 00:47

1、UMLは汎用モデリング言語なので、特定言語との1対1のマッピングは
存在しません。というわけで、プロジェクトで好きに決めてやれば
いいと思うんだけど、モデリングツールを使っていればコード生成で
概ねマッピングしてくれるので、それに従うのがいいんじゃないかな。
Rose+Javaなら、だいたいこんな感じじゃない？
対1関連=関連先の型のインスタンス変数,
対多関連=Set,List,Mapなど, ロール名=インスタンス変数名

2、Javaでは集約はあんまり意味はないと思うよ。使わないっていう
ルールにした方が混乱がなくていいと思う。
3、ERとクラス図って、キーを指定する以外はたいして違わないような気が
するんだけど、違う?DB詳しくないんで教えてください。
4.面倒なら書かなければいいよ。
5.シーケンスが提出ドキュメントに含まれるかどうかじゃないかなー。
俺は考えをまとめる時だけにしか使わないので、作りっぱなし。
6.素直にやるなら関連です。
7.たいがいユースケース単位で分割します。ユースケースの
大きさにもよるんだけど。
8.力業で変換してます。メチャ大変
9.全体一枚と詳細多数。図ごとに何を表現したいかテーマを決めて
やるといいよ。

537 ：デフォルトの名無しさん：03/05/31 01:20

>>529
>>ＵＭＬあって実装するときどの点が便利なん？

最終ソースがオブジェクト指向である場合、各工程間の移行がスムーズ
という利点がUMLにあると思います。
例えば、ユースケース→分析レベル各図→実装に即した各図→オブジェクト指向のソース
はスムーズに移行できますが、
旧物理DFD→旧論理DFD→新論理DFD→？？？→オブジェクト指向のソース

>>他はなんか単にいまあまであった仕様書をマンガチックにしたもの
>>みたいなんでメリットがみえない。

書き方の統一というメリットがあると思います。

538 ：デフォルトの名無しさん：03/05/31 01:41

なるほど少しわかってきたような（ｗ
回答者の賢人者たちに感謝

539 ：U ◆CZtFsGiu0c ：03/05/31 15:36

>>534
機能というカットだと、普通はユースケースだろうね。
でも、ユースケースがピンとこないようだったらFDDのように機能を細分化してみると
いいかもね。

540 ：デフォルトの名無しさん：03/05/31 21:26

>>539
規模がでかくなると、ユースケースが100とか200ぐらいになりそうな気がするんだが、分割は難しいのではないのかなあ。

...そもそもUCがそんなに多くなるような分析はするな、ってこともわかっているんだが、そ～もいかないこともあって。。。

ユースケースの適正数は、普通どのくらい？(10から20ぐらいを目標にしているんだが、、、10倍にもなる(w。)

541 ：U ◆CZtFsGiu0c ：03/06/01 00:10

>>540
ユースケースの粒度に関してはいろいろ議論があって、今でも収束していないと
思います。ユースケースを2段階(概要と詳細)で書く人たちもいるし、FDDみたいに
ユースケースに否定的な人たちもいるし。
＃FDDのフィーチャは粒度がはっきりしています

でもシーケンス図が書ける程度の粒度にはなっていないと困りますね。

542 ：デフォルトの名無しさん：03/06/01 18:21

なかなか面白い話題ですねぇ
ユースケースの粒度は難しい問題だと思います。

某書では、
「ユースケースの単位」
→「アクターがそのユースケースを実行すると満足して席を立てる」
　　AND　「長くても２０分程度でユースケースの実行が終わる」
とありました。
このレベルで作ると、大規模だと数100個できそうな気がします。
おそらく、もっとレベルの大きいユースケースを作って分割していくしかないのかなぁと
おもいます。

あと、ユースケースを実行するとデータのCRUDでユースケースが４つできてしまうような気がするのですが、
みなさんどうされてますか？
１．４つのユースケースを作る
　　「AAを参照する」、「AAを作成する」、「AAを削除する」、「AAを変更する」
２．４つはまとめる
　　「AAを管理する」
私は粒度を考えると「２．」の方法のほうがいいのかなと思っています。

543 ：デフォルトの名無しさん：03/06/01 22:51

age

544 ：デフォルトの名無しさん：03/06/01 23:56

>>542
個人的には、その某書の単位が一番いいんじゃないかと思っています。
ある程度そのユースケース内で機能が完結するので、
担当を割り当てる単位として適当のような気がするんですよね。
数百のユースケースができるような場合は、
サブシステムに分けることを考慮してもいいかも。
CRUDに関しては同意見です。

545 ：デフォルトの名無しさん：03/06/02 06:54

>>542
甘い。
「AAを管理する」から、「AAを参照する」、「AAを作成する」、「AAを削除する」、「AAを変更する」を派生させる。
管理がCRUD全部をさすとは限らないし。ロールによって出来るユースケースも違うだろ？

546 ：U ◆CZtFsGiu0c ：03/06/02 13:14

>>542
>１．４つのユースケースを作る
　　「AAを参照する」、「AAを作成する」、「AAを削除する」、「AAを変更する」

これって見事にFDDのフィーチャの粒度ですね。

>>545
まあシステムの機能をCRUDだけで表すことはできないですしね。

547 ：デフォルトの名無しさん：03/06/02 20:32

>>542

某書：
http://www.amazon.co.jp/exec/obidos/ASIN/4774116882/249-5819862-2709141

>>542 のCRUDの2
の粒度の話は、こっちに書いてありましたね。
http://www.amazon.co.jp/exec/obidos/ASIN/4774117420/qid=1054553369/sr=1-2/ref=sr_1_2_2/249-5819862-2709141

私的には、そんなところで悩むよりも、ユースケース仕様を書くことに
注力したいですね。

548 ：デフォルトの名無しさん：03/06/02 20:33

ここのせいでオナニーしすぎだよまったく・・・
　　　　　　　　　↓

　http://www.dvd-yuis.com/

549 ：デフォルトの名無しさん：03/06/03 00:42

>>547
複数人で書かなきゃいけないときに困る。

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

>>549

ことば足らずでした。
そんなところで悩むよりも、（どんな粒度であっても長短あるので、
なんでもいいからはじめに決めてしまって）ユースケース・・・
ってことでした。

特に大きなチームでの基準の統一、というのは確かに難しいことですねえ。

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

>>550
ユースケースを書くときはとにかく機能を思いつくままがんがん書いていって、
最後にグループ化するのがよいと思います。

552 ：デフォルトの名無しさん：03/06/12 16:43

新人にusecaseのincludeとextendの違い・使い分けを質問されて困ってます。
いろいろ調べたんですが今ひとつすっきりした答えが見つかりません。
どう答えればよいでしょうか？

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

MagicDrawでXMIにエクスポートできないのはどういうわけですか？
Rational Roseでサポートしてないからダメだとか言うエラーが出るんですけど。

あとEnterprise Architectを使いたいのですが、インストールしようとすると
キーが作成されないとか言うエラーが出るんです。
これはどうすれば？

誰か教えてください。

554 ：デフォルトの名無しさん：03/06/12 19:43

>>553

EAのほうは、製品版なら最初にライセンスキーの入力が必要。

っていう話ではなくて？

555 ：デフォルトの名無しさん：03/06/12 21:25

>>552
ユースケースでそこまで凝っても仕方がない。
どっちか一つを使うことにして片方は忘れると良い。

556 ：デフォルトの名無しさん：03/06/12 22:10

>>552
漏れも555さんのおっしゃっているのと同じようなアドバイスをもらった。
「ユースケースは細部にこだわるよりもわかりやすさを優先しろ」とも言われたなあ。

557 ：デフォルトの名無しさん：03/06/12 23:34

>>552
includeは主体となるユースケースが、別のユースケースを「含む」。
つまり、主体となるユースケースから、別のユースケースを参照している。
目的は、ユースケースの共通化。
複数のユースケース間で同じになる処理を一カ所にまとめておくために使う、
と考えて良いと思う。
extendは、主体となるユースケースを、別のユースケースが「拡張する」。
つまり、拡張ユースケースから、主体となるユースケースを参照としている。
主体となるユースケースは、拡張ユースケースのことを知らない。
目的は、条件分岐の外出し。
主フローと異なるフローが、すごく長くて複雑な場合などに、
外に出してすっきりさせるために使う、と考えて良い。
includeと違って、処理の共通化ではなく、あくまで単なる外だし。
extendのユースケースを、他のユースケースから利用することはできない。

・・・って感じでよかったっけ?

558 ：デフォルトの名無しさん：03/06/13 01:30

>>557
同意見です。

559 ：552：03/06/13 10:30

includeは2つ以上のユースケースから使用されない場合
書かれないという考えでよろしいでしょうか。

ＵＭＬは納品物としてしか作ったことが無かったので
新人と一緒に勉強しています。

560 ：デフォルトの名無しさん：03/06/13 23:46

>>559
書かれないというか、書く意味がないんじゃない？
一つのユースケースからしか使ってないユースケースを外だししてもあまり意味ないでしょう。
INCLUDEの存在意義は共有ユースケースの取り出しにあるでしょう。

EXTENDは共通化されなくても取り出すけど。
特にEXTEND機能がある場合とない場合を分けて開発できる場合には便利だよ。

561 ：デフォルトの名無しさん：03/06/15 22:38

米OMG、モデリング言語「UML 2.0」の策定完了
ttp://biztech.nikkeibp.co.jp/wcs/leaf/CID/onair/biztech/comp/252121

562 ：デフォルトの名無しさん：03/06/16 11:39

納品するために書くUML、か。
それってどうよ？

563 ：デフォルトの名無しさん：03/06/16 23:29

>>562
> それってどうよ？

不毛

564 ：デフォルトの名無しさん：03/06/21 10:30

下図にバナナClassを追加するとき、関連「食べる」は動物バナナで結ぶんですか？
それとも人間バナナ・猿バナナそれぞれに結ぶのでしょうか？

　　　　　動物
　　　　　　 △
　　┌──┴─┐
　人間　　　　　猿

565 ：デフォルトの名無しさん：03/06/21 10:48

動物じゃないの。
「食べる」っていう関連は俺なら引かないけど。

566 ：デフォルトの名無しさん：03/06/21 10:56

>>564
食性についてなら
　　　　　　　　　動物
　　　　　　　　　　△
　　　　　 ┌──┴─┐
　　　　　草食　　　　肉食
　　　　　 △　　　　　　△
　┌──┴─┐┌─┴─┐
　　　　　　　　雑食
　　　　　　　　　△
　　　　　┌──┴─┐
　　　　人間　　　　　猿
ジャマイカ？
で、実際にバナナを食べるかどうかは個体によって違うから、
インスタンスにもたせろ。

567 ：デフォルトの名無しさん：03/06/21 11:01

　　　　食べ物　　　　植物
　　　　　 △　　　　　　△
　┌──┴─┐┌─┴─┐
　　　　　　　野菜果物
　　　　　　　　　△
　　　　┌──┴─┐
　　　バナナ

とした上で
動物食べ物の関連

568 ：564：03/06/21 13:52

>>565-567
できるだけ抽象的、汎的なクラス同士を関連づけるわけですね。
バナナは質問のための例なんでより範囲を広げた分析はしません…。

569 ：デフォルトの名無しさん：03/06/29 22:45

保守

570 ：デフォルトの名無しさん：03/07/05 20:05

現在、プログラム板で一番上にあるスレはここです(^^)

571 ：デフォルトの名無しさん：03/07/10 13:55

UMLブロンズがあっさり（チュートリアル斜め読み＋JAVAの知識）受かったので
調子に乗ってシルバーも受けてみたら２７点だったｗ
まあ世の中そんなうまく行かないもんだなね（´ー`）y-~~~

572 ：Enterprise Architectよさげ：03/07/12 14:50

Enterprise Architectで、C++コードのメンバ関数の中身は
どこにどうやって記述するのですか？
それとも、メンバ関数の中身は、コードを吐き出したあと、
書けということなんでしょうか？

573 ：U ◆CZtFsGiu0c ：03/07/12 15:25

最近EA使い始めました。確かにいいですね、これは。

>>572
そりゃそうでしょう。EAは単なるモデリングツールなので、コードエディタなんて
ありませんよ。それはC++に限った話ではありません。

574 ：572：03/07/12 16:36

なるほど、やはりそうなんですか。
ありがとうございます。

575 ：デフォルトの名無しさん：03/07/13 16:21

>>573

コードエディタは月末？の新バージョンで搭載されるそうな。
別件でサポートに聞いたとき教えてくれた。

576 ：山崎渉：03/07/15 09:53

　__∧＿∧_
　|（　　＾＾）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

577 ：デフォルトの名無しさん：03/07/18 13:10

保守age

578 ：デフォルトの名無しさん：03/07/18 13:27

うむる

579 ：デフォルトの名無しさん：03/07/19 09:28

すんません。
Eclipse使ったことある方教えてもらえませんか？

Eclipse(2.1.1)UMLでクラス図とシーケンス図を描いているのですが
クラス図を作成するとそこに追加したクラスが自動生成されますよね？
その後シーケンス図を新規作成して先に作成されたクラスを
追加しようとするとできない事があるのです。
Name入力 => TypeをBrowseで選択 => 選択後ＯＫを押しても画面に反映されず
・・・というカンジです。
また既存のシーケンス図をコピーして右クリックproperties => type =>Browseで
クラスを変えようとしてもできません。デフォルトで存在しているクラスは取り込めるのですが
クラス図作成でできたクラスのみダメなのです。
同じような現象が出た方、解決できた方はいませんか？

ちなみにC:\eclipse\workspace\.metadata\.logを見ると下記のようなエラーになっています。

!ENTRY org.eclipse.ui 4 4 7 18, 2003 15:47:48.985
!MESSAGE イベント・ループ内の未処理例外キャッチ。
!ENTRY org.eclipse.ui 4 0 7 18, 2003 15:47:48.985
!MESSAGE java.lang.NullPointerException
!STACK 0
java.lang.NullPointerException
at com.omondo.uml.b.a.p.if(SourceFile:2214)
at com.omondo.uml.b.a.p.if(SourceFile:1433)
（略）

580 ：デフォルトの名無しさん：03/07/19 18:44

>>579
　 ∧＿∧ 　　
　（　´∀｀）＜　ぬるぽ
http://www.forum-omondo.com/

581 ：デフォルトの名無しさん：03/07/19 21:09

http://www.eclipse.org/

582 ：579：03/07/23 00:32

結局、新たにプロジェクトを作成しなおしたら
うまくいきました。なんかファイルが壊れてたみたいです。
お騒がせしました。

583 ：デフォルトの名無しさん：03/07/28 19:29

UMLとUMLを通してオブジェクト指向の考え方を習得したいのですが，
お薦めの本はありますか?
コンピュータサイエンスの基礎は学習済です。

584 ：デフォルトの名無しさん：03/07/29 09:31

DynamicDraw使っている人いる?

585 ：デフォルトの名無しさん：03/07/29 09:32

DynamicDraw 使っている人いる?

586 ：デフォルトの名無しさん：03/07/29 23:52

>>583
二元マルコフ情報源について知るところを述べよ

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

>>586
何も知りません

588 ：デフォルトの名無しさん：03/07/30 06:38

>>583
ストリームラインオブジェクトモデリング
Javaエンタープライズコンポーネント

589 ：デフォルトの名無しさん：03/07/31 16:29

>> 583
UMLモデリングのエッセンス
http://www.amazon.co.jp/exec/obidos/ASIN/4881358642/uselesspgsnes-22

590 ：デフォルトの名無しさん：03/07/31 21:26

>>584
|_・)ノ

591 ：山崎渉：03/08/02 02:12

（＾＾）

592 ：デフォルトの名無しさん：03/08/02 11:32

>>589
ネタ?

593 ：デフォルトの名無しさん：03/08/02 21:07

>>571
シルバーってどんな具合?
何が分かってればOK?

594 ：デフォルトの名無しさん：03/08/03 17:42

>>593
んなもん技術者なら自分で調べろや

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

>>594
>>593は技術者ではなくて，作業者ですよ

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

住人の少ないｽﾚだな。

597 ：デフォルトの名無しさん：03/08/05 10:19

住人だけに10人しかいなかったりしてな。

598 ：デフォルトの名無しさん：03/08/05 21:26

>>597を晒しあげ

599 ：デフォルトの名無しさん：03/08/05 21:41

寧ろ、無限の住・・・

600 ：キリ番ゲッター見習い ◆cEL6a7QKc2 ：03/08/10 01:32

　　　　　　　　　　　　　　／￣￣￣￣￣￣￣
　　　　　　　／⌒彡　＜　600ゲットォォォォォ
　　　　　　　/　冫、）　　＼＿＿＿＿＿＿＿
　　　　　　/ 　` ／　　　　　　　　　　(´´
　　　　　（つ　つ　　　　　　　(´⌒(´
　　　　　／／〉　〉≡≡≡(´⌒;;;≡≡≡
　　　　（＿_）（＿_）　(´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

601 ：デフォルトの名無しさん：03/08/10 14:57

「ボールを投げる」をＵＭＬで分析したらどうなるか？
投げる人
・投げる強さ(attribute)
・投げる(method)
ボール
・大きさ、重さ(attribute)

ボールと投げる人の関係は？
加速度やボールの位置は、ボールの属性？

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

＞ボールと投げる人の関係は？
ボール＝投げるﾒｿﾄﾞの引数

＞加速度やボールの位置は、ボールの属性？
y

603 ：デフォルトの名無しさん：03/08/10 19:10

>>601
オブジェクト指向的には
　投げる人
　ボール
があって
ボールのメソッドに
　私を投げろ（投げる人）
だと思うぞ。
ボールには重さや加速度、投げる方向、位置をカプセルしデータを隠蔽する。
ボールのほうがデータ量が多いのでこちらに操作を実装する。

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

>>583
コレは？　　遅すぎたか？

はじめて学ぶUML
竹政昭利 (著)

http://www.amazon.co.jp/exec/obidos/ASIN/4816334114/qid%3D1060510758/249-6407994-8056350

http://books.rakuten.co.jp/RBOOKS/NS/CSfLastGenGoodsPage_001.jsp?GOODS_NO=1517969

605 ：デフォルトの名無しさん：03/08/10 19:51

> ボールのメソッドに
> 　私を投げろ（投げる人）
はぁ？

606 ：デフォルトの名無しさん：03/08/10 20:15

>>601
「何のためにボールを投げるのか?」が判らないと分析は無理。
その人の目的によって、ボールや人に必要な属性も操作も関係も全く違うんだからな。
それくらい判ってから分析に手を出せ。

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

投げる人のメソッドに
　投げる（ボール）
じゃないんですのん？

608 ：デフォルトの名無しさん：03/08/10 20:18

そこにボールがあるから

609 ：デフォルトの名無しさん：03/08/10 20:22

投げる人の操作に「投げる(投げられるもの)」かもな。

UMLのスレなんだから「操作」「属性」くらいの言葉遣いはちゃんとしる!

610 ：デフォルトの名無しさん：03/08/10 20:55

>>604
サンクス。
今，近所の図書館に1冊だけあったUML関連の本
「わかりやすいUML入門―UML 1.4とJ2EE対応」で勉強しています。
リンク先読みましたが，検定試験もあるんですね。勉強して受けてみようかな。

611 ：601：03/08/11 07:03

>>606
まぁ、そうなんだけど、単純にボールと投げる人をみんなどう関係付けるのかなぁ
と思って、質問してみました。
俺的には、「投げた」クラスを導入して、そいつに加速度とか方向とか
持たせます。ボールには持たせません。
変な問題ですまんかった。

612 ：デフォルトの名無しさん：03/08/11 09:22

>>611
であれば、ボールに「運動状態」に関する属性を持たせればいいんでは？
時刻ごとのポールの位置を知るのはどうするんだよ。

つーか、加速度？

613 ：601：03/08/11 14:58

>時刻ごとのポールの位置を知るのはどうするんだよ。
ボールが自立的に動いていないのであれば、「投げた」クラスが移動の履歴
になるのではないかと。

614 ：デフォルトの名無しさん：03/08/11 21:55

>>603
「投手.投げる(ボール)」
だと思うけど…
で、上の方のスーパークラスには
「物.移動する(x, y, z)」
なたいな。

615 ：デフォルトの名無しさん：03/08/12 19:44

多重度について質問です。混乱してきてしまって。

やさしいUMLの例題で大学と受験生の関係は
受験生　　―　　大学
　　0..* 1..*

大学から見て受験生は、受験生がこない場合もあるし、受験生は500人くる可能性もある
よって多重度は0..* は納得

受験生から見て大学は複数受けることも可能だから1..*ということですが、
受験生が大学を受けないということを想定すると、0..*になりませんか？

UMLはじめてまだ一週間ちょいなため
「1..*」「0..*」の区別のつけ方がいまいちピンときません。

多重度以前に自身のクラスの関係の考え方が間違っているかもしれませんが、
合わせて教えていただけると助かります。

616 ：615：03/08/12 19:46

すいません。ずれてしまっている・・。

大学からみて受験生への多重度は0..*
受験生からみて大学への多重度は1..*
です。

617 ：デフォルトの名無しさん：03/08/12 19:49

>>615
関連性による。
両者の関係が「受験する」とかになってない？

618 ：615：03/08/12 20:06

>>616
例題は「受験生」クラスからみた「大学」クラスの多重度を答えよ。となってます。
関連性については触れられていません。
受験生が大学を受験するという関係が成り立っているなら、納得がいきます。

UMLシルバーを9月までに取れっていわれてるけど・・道は長そうです。
妹の名前で受けてみましたが、
すべての多重度関係の問題が1..*か0..*が入るような気がして・・

注文と顧客という関係の多重度を考えるにしても

注文　　－　　顧客
0..*　　　　　1

注文からみると注文する顧客は一人なので、多重度は1

注文　　－　　顧客
0..*　　　　　1..*

顧客は店内に複数人いることを想定し、注文からみると顧客は1..*

問題を見ても関連性についてはあまり触れられてないんですよね・・（汗
ただ、これとこれのクラスの多重度を答えよという感じで・・

注文と顧客の多重度を考える際、両者の関連性によっては「1」「1..*」の
どちらも考えられるんでしょうか？

619 ：デフォルトの名無しさん：03/08/12 20:24

>>615

>>617でも書かれているけど、「受験生」という時点で
受験をすることが前提になっていると思われる。

なので、この問題では1..*なのでは。

これが、「受験生」じゃなくって「高校生」ならば
受験しない人もいると思うので、0..*になるはず。

620 ：デフォルトの名無しさん：03/08/12 20:32

>>619
ものすごくわかり易いレスありがとう。

>受験をすることが前提になっていると思われる。
なるほど・・前提ですか。
～が前提での関係という考え方にするとすごくわかり易いですね。
もう少しだけ、頭を整理してみます。
0..*になる参考例もわかり易い。ありがとう～

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

写真集だよん☆☆☆☆☆☆
http://www.sexpixbox.com/pleasant/sexy/index.html

622 ：デフォルトの名無しさん：03/08/13 01:47

>>618

問題の仕様にもよるけど
注文からみた顧客の多重度は1..*やろ？

詳しい人待ったほうがよさそやね・・。

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

受験しない受験生はいない

624 ：デフォルトの名無しさん：03/08/13 05:00

>>618
顧客と注文の関係は（1対多）
顧客(1) - (0...*)注文
だと思いますよ。
ひとつの注文から見た顧客はまず1人です。
注文する顧客が0人でであることはありえませんし、
2人以上で注文あることはあまりないでしょう（業務によりますが）。
多重度の決定をするには自分がそのクラスのインスタンスになったつもりで、
リンクする対象が業務上いくつ存在しえるか、という形で考えるとかなり正確に決定できます。
受験生と大学の関係は多対多ですが、業務ルールで受験費用が高いなどで受験せずに
様子見をする受験生の存在がありえそうならば（ほんの少しでも）、
受験生(0...*) - (0...*)大学
ですし、受験生は必ず受験しければならないという業務ルールが存在するのであれば、
受験生(1...*) - (0...*)大学
です。

625 ：624：03/08/13 05:02

>>624
>受験生(1...*) - (0...*)大学
間違えた。こうだ。
受験生(0...*) - (1...*)大学

626 ：山崎渉：03/08/15 15:38

　　　 (⌒V⌒)
　　　│ ＾＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

627 ：デフォルトの名無しさん：03/08/15 23:33

a g e ! !

628 ：デフォルトの名無しさん：03/08/19 12:03

1st Modeller使ってる人ｲﾈｶ?
マ、ム両板でもあんまし話題に上がってないんだが、安いのがｳﾏｰ。

629 ：デフォルトの名無しさん：03/08/19 20:59

>>628

安いというか、一番下のバージョンはフリーですね。
ただ、業務として購入するにはあまりにも頼りなさ過ぎる。

日記を見ればわかると思うが、「本業」が忙しいとダメそうなので
部署の標準ツールにはなりえないのよね...

630 ：デフォルトの名無しさん：03/08/19 21:01

おっと、補足しておくと、ソフト自体は悪くないよ。

UMLの勉強ならJava系のソフトを使うよりも、こっちを使う
ほうがいいと個人的には思う。

631 ：デフォルトの名無しさん：03/08/20 10:19

>>629-630　レスthx.
社内業務改善(つか次期基幹システム構築発注のための分析)に使うので、Javaとか
コード分析・生成とか全くいらんス。個人的には社内のちょっとした要望(Excel
便利マクロﾂｸﾚﾂｸﾚ攻撃)に使おうかと。ちょっとした物作っても一旦業務に使わ
れるとなきゃこまる状態になるので、後任者にしっかりしたドキュメントを残す
のにいいのかなぁと思う次第です。

632 ：デフォルトの名無しさん：03/08/20 11:44

>>631

確か、UMLの絵を描くだけのツールなら、もっと便利な奴が
フリーであったはず。名前忘れたけど。

633 ：デフォルトの名無しさん：03/08/20 14:09

>>632
ダイナミックドロー

634 ：デフォルトの名無しさん：03/08/20 14:34

シルバー落ちますた｡･ﾟ･（ﾉД｀）･ﾟ･

ブロンズみたいに、間違えた問題がどれなのかわかるとうれしいな。

635 ：デフォルトの名無しさん：03/08/20 16:31

資格板より・・

１１月から世界で統一させたUML資格ができますね
http://www.umlcert.org/

受験料金３万かぁ、、、

・・はやめにとったほうがいいかも。

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

>>.635

ベータ試験に参加すれば、参加費が安くなるはず。
日本でもやるのかどうか知らないけど。

取得しなきゃいけない人は、参加したほうがいいかも。

それにしても、US$200がなぜに30000円になるんだろ。

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

翻訳料・関税・送料・為替手数料

638 ：デフォルトの名無しさん：03/08/29 00:52

シルバー落ちたようわあぁぁん

639 ：デフォルトの名無しさん：03/08/29 12:41

IBMがRational新製品群のプレスリリース出してるよ
ttp://www-6.ibm.com/jp/NewsDB.nsf/2003/08271

640 ：デフォルトの名無しさん：03/09/01 23:55

UMLの仕様が膨大だそうですが・・・・
Ｊａｖａと対応していないＵＭＬの部分てどのような
部分があります？これから仕様書ＵＭＬを読もうかなと思っていますが

641 ：デフォルトの名無しさん：03/09/02 06:17

>>640
いまんとこパラメーター化クラスとかかな？もうすぐjavaでもできるようになるけど。
ＵＭＬの仕様書はNotationGuideだけ読んどきゃいいですよ。
UML Semanticsなんかはよまなくてもいいです。

642 ：デフォルトの名無しさん：03/09/02 16:12

EA3.60リリースage

643 ：デフォルトの名無しさん：03/09/02 16:39

さっそくビルド636リリースsage

それにしても、けっこういいんじゃないの？
昔よりかメニュー構成がわかりやすい。

644 ：デフォルトの名無しさん：03/09/02 16:49

>>642

参考：
http://www.zdnet.co.jp/enterprise/0309/02/epn01.html

645 ：デフォルトの名無しさん：03/09/02 23:55

UMLツールについて

ソース自動生成が可能か、
ＵＭＬ準拠1.4(または2.0)orお絵かき図のレベルかなど
基準がいろいろあると思いますが、使いやすいのは？

(a) Rational Rose Enterprise Edition
(b) Konesa Client Evaluation 2.0 + JBuilder8
(c1) Together Control Center
(c2) Together Edition for JBuilder
(d) Pattern Weaver
(e) WithClass 7.0J Enterprise Edition
(f1) Describe Developer for Sun ONE Studio 4
(f2) Describe Enterprise
(g) Enterprise Architect (EA)
(h) ホワイトボードで十分

いろいろ意見を聞かせていただければ助かります。

646 ：デフォルトの名無しさん：03/09/03 00:06

将来性うんぬん別にするならRoseに一票。
Java系ツールは遅いしバギーなものがまだまだ多い。
EAは使ったことないけど、評判イイみたいね。

647 ：デフォルトの名無しさん：03/09/03 07:07

(g) Enterprise Architect (EA)

使いやすい、安い、機能も十分。
何の問題もないソフトウェアです。

648 ：デフォルトの名無しさん：03/09/03 11:18

EAのアカデミックプロフェッショナルがいいかな

649 ：デフォルトの名無しさん：03/09/03 12:25

Roseはやはり(たぶん)トップシェアということだけあって資料が豊富。
使いやすさは個人的にはどうかと思うが、トータルで考えると
失敗はしないという感じかな。

問題は、それを買うだけの金があるかってこった。
うちは、見積もりとって上司に見せたら冗談言うなって言われた...

ってなわけでEAを検討中。

650 ：デフォルトの名無しさん：03/09/03 22:05

>>643
EA3.60にバージョンアップ完了
確かにメニュー体系がかなりかわってますね。

何にしても以前のメニューに慣れかかっていたので
またこれから使いこまなければ

651 ：デフォルトの名無しさん：03/09/05 11:29

ユースケース図を練習してます。
TVシステムのユースケース図を書くときに、まずアクタとして観覧者、リモコンのアクタが考えられます。
アクタのシナリオとして、
観覧者：電源ON・OFF
　　　：チャンネル変更
リモコン：電源ON・OFF
　　　　：チャンネル変更
と動作が同じであるとき、この二つのアクタの関連は「依存」だと思うんですが、どうなんでしょう？
でも、先生によると間違っているそうです。

初心者丸出しの質問ですいません。

652 ：デフォルトの名無しさん：03/09/05 17:40

チェスのアクタを抽出するとき、KINGやKNIGHTなどのアクタはアクタ＜コマ＞の汎化だが、
＜黒コマ＞、＜白コマ＞などのアクタがアクタ＜コマ＞の汎化である場合、アクタ＜KING＞＜KNIGHT＞は
アクタ＜白コマ＞＜黒コマ＞の二種類分の汎化を行わなければならないのか？
>651

コマの動きのレベルでユースケース図を作成するのならば、黒・白のアクタを考える用はないだろう。
チェスプレイヤーの視点でユースケース図を作成するのならば、コマのアクタすら必要ない。
逆にいえば、黒・白のアクタの抽出が必要なレベルとは、黒・白のコマ視点での試合などには
黒・白コマのアクタのチェスシステムへの関連が必要となる。

653 ：デフォルトの名無しさん：03/09/05 17:49

EAでシーケンス図のオブジェクトを上下に移動させたい
のですが、ドラッグしても元の位置に戻ってしまいます。

動かせないものなのでしょうか？

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

>651
俺が書くならこうする。
　〇　　　　TVシステム
　大－→[(スイッチを操作する)－includes→(リモコンで操作する)]
視聴者
([]はシステム境界、()はユースケースと思いねえ)

リモコンをアクターにするなら、観覧者(って変な言葉じゃねえ？)とは違う
システム境界で扱うことになるんじゃなかろうか。

655 ：デフォルトの名無しさん：03/09/05 22:37

>651

観覧者とリモコンが同レベルのシステム使用者であるのが、
不自然なわけですね。観覧者の要求定義とリモコンの要求定義が同じもの
ならば、それらを汎化させることが可能なはずだが、観覧者の「見る」と
言う要求の汎化とリモコンのTV操作の汎化が同一であるわけがないので、
それらのアクタが同レベルのユースケース図で同時に記述されることは
おかしい。

656 ：U ◆CZtFsGiu0c ：03/09/06 00:19

>>653
上下には動きませんよ。っていうか動かして何がしたいんですか?

657 ：デフォルトの名無しさん：03/09/06 00:44

>>656
返信サンクス。
そうですか。
いや、ダイヤグラムのプロパティと重なるので・・
っていう理由だけです。

プロパティ側を動かせば良い話ですが、
ダイヤグラム自体は全体に中央よりに
置きたいと思ったもので。

658 ：デフォルトの名無しさん：03/09/06 09:24

>>651
システムの境界がよくわからないなあ。
TVシステムとして、リモコンは含まれるの？それとも含まれないの？
ちょっと言い方を換えると、リモコンはTVシステムとして作るの？作らないの？

作るのであれば、リモコンはアクターにならないはず。

...命題としてリモコンと視聴者がアクターとして定義されているのなら、アクターの汎用ができるのでは？
（TVシステム操作者とか定義してそれを継承する。）

659 ：U ◆CZtFsGiu0c ：03/09/06 11:19

>>651
たしかにシステム境界がはっきりしないとモデリングのしようがないですね。
個人的にはリモコンはサブシステムとして定義したいところですが、ユースケース
の段階ではリモコンを含めて一つのシステムとしたほうがわかりやすいですね。

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

リモコンはユーザインターフェース。だからシステム境界そのものだ。

661 ：デフォルトの名無しさん：03/09/07 18:39

リモコンをユースケースとして考えるなら、ユースケース「電源ON・OFF」
「チャンネル変更」とどんな関係になるんだろう？
アクタ自体が直接ＴＶをいじくることができるのだから、《include》じゃ
ないような気がするけど、でも《extend》でもないだろうし・・・。

662 ：デフォルトの名無しさん：03/09/07 22:11

「リモコン」はユースケースにできんでしょ。
「リモコンで操作する」とかならまだしも。

ちなみに漏れはこうじゃないかと。

　　　　　　（リモコンで操作）
　　　　　　　　　↓≪ｅｘｔｅｎｄ≫
　♀─→（テレビを操作）
視聴者　　　　　↓≪include≫
　　　　　　(電源on/of、ch変更等)

663 ：デフォルトの名無しさん：03/09/07 22:27

>>662
それだと、リモコンも視聴者から操作を受けるのでは？

664 ：デフォルトの名無しさん：03/09/08 00:01

includeやextendは無理に使わなくてもいいのでは。
本質的に必要なユースケースは下の6つだと思います。
アクターは全部視聴者

・リモコンで電源を入れる
・リモコンで電源を切る
・リモコンでチャンネルを変える
・本体スイッチで電源を入れる
・本体スイッチで電源を切る
・本体スイッチでチャンネルを変える

665 ：デフォルトの名無しさん：03/09/08 12:13

「契約」がいまいちわからん。

666 ：デフォルトの名無しさん：03/09/08 18:15

>>665

public class test2{
public static void main(String args[]){
CA ca=new CA();
try{
System.out.println(ca.func(12,0));
}catch(Exception e){
System.out.println(e);
}
}
}
class CA{
protected int in(int a)throws Exception{
if(a==0){throw new Exception("ZERO");}
return a;
}
protected int body(int a,int b){
return a/b;
}
protected int out(int a){
return a;
}
public int func(int a,int b)throws Exception{
return out(body(a,in(b)));
}
}

667 ：デフォルトの名無しさん：03/09/11 13:18

カテゴリ分け謎すぎ

★ オープンソース、無償モデリングツールの実力派
[UMLツールレビュー]　UMLモデリングツールには、強力な機能を持つ実力派オー
プンソース・プロダクトがいくつもある。そんなオープンソースの代表的な製品
を評価する
http://www.atmarkit.co.jp/fjava/devs/review03/review03_1.html

668 ：デフォルトの名無しさん：03/09/11 19:02

>>667

そもそもEAはオープンソースでも無償でもないのに意味不明。
しかもなぜに英語版！？

669 ：デフォルトの名無しさん：03/09/11 21:10

>>668
体験版が無償＆英語版のみだからじゃない？

670 ：デフォルトの名無しさん：03/09/11 22:19

>>669

御意

個人的には、EAの掲示板で書かれている意見に近いかな。

671 ：デフォルトの名無しさん：03/09/21 16:48

関連の引き方について質問

1個のクラスについて数種類の集約や継承のクラスがあるとき
線を個々に引いていくのと一箇所に一箇所に集約してから引くの
の違いがよくわかりません

こんな感じです

　　　スーパークラス
　　　↑　　　　↑
サブクラス　　サブクラス

　　　スーパークラス
　　　　↑
　　 ┌─┴─┐
　　　｜　　　　｜
サブクラス　　サブクラス

それともどちらも意味は同じなんですか？

672 ：デフォルトの名無しさん：03/09/21 16:59

同じ意味。
うえがSeparateTargetStyleでしたがSharedTargetStyle

673 ：デフォルトの名無しさん：03/09/21 17:08

サブクラスを作成するときどの基準で作るかで使い分ける
前者の場合はまったくことなる基準の書き方
後者の場合は同じ基準の書き方

例えば社員というスーパークラスがあるとして
サブクラスに
営業社員　事務社員　20代　30代　40代　があるとする

営業社員、事務社員は職種という基準で特化してるわけだから
線を引くときは後者の引き方を使用。同じく残りは年代という基準
これで、二股（A）と三又（B）の汎化ができるでしょ。
AとBは基準が違うわけだから前者の線の引き方をするわけさ

わかたかな？

674 ：673：03/09/21 17:10

>>672
なに！おなじだたのか。
じゃあ俺の言ってるのは忘れてください

675 ：デフォルトの名無しさん：03/09/22 05:52

こんなページがあったよ
ttp://www.atmarkit.co.jp/fjava/devs/object05/object05.html

ただこの人の言っていること、たまに？

676 ：デフォルトの名無しさん：03/09/22 06:25

>>675

今回の場合で言えば、正しいと思う。
671において、２つのサブクラスが並列的な関係・概念に
あるのであれば、>>672は正しいでしょう。

でも、675のURLにあるような場合や、673のような例の場合には
それぞれが別個の継承になると言う意味で、正しい。

もしかすると、UMLの規約としては、上記の文中の「正しい」は
「わかりやすい」なのかもしれない

677 ：デフォルトの名無しさん：03/09/22 07:32

多重継承と集約の違いがよく分からん…
FAXもプリンタも独立して存在するけど、
それぞれの機能を部品と見立てて集約として扱えばいいような？

678 ：デフォルトの名無しさん：03/09/22 09:39

>>677
実装の違いだと思いますよ。だからどっちの表記でもいいじゃない
でも、多重継承はJavaだとコードに落とすときへぼくなるから
集約のほうがよさげですね

679 ：デフォルトの名無しさん：03/09/22 11:03

>>677
あなたが作るFAXプリンタが、「FAXとプリンタを組み合わせたもの」なら集約で表現し、
「FAXとしても、プリンタとしても振舞う何かべつのもの」なら多重継承で表現すればいい。

680 ：デフォルトの名無しさん：03/09/22 11:19

>>677
集約で表現出来るなら、多重継承する必要はない。

681 ：デフォルトの名無しさん：03/09/23 02:00

>>677
適切なモデル化を判断するには、作ろうとしているモデルの抽象度によることに注意。

概念モデルか？実装・設計モデルか？

概念モデルならば、継承＝分類関係、集約＝所有関係と言い切れる。
実装・設計モデルだと、実際のコード的にうれしいのが正解。

682 ：デフォルトの名無しさん：03/09/23 02:47

EA試用中です。今までフリーのUMLツールを
使っていたのですが、これはコードと同期とれたりとびっくりです。

よろしければ、どなたか>>91さんのレス、詳細について教えて
頂けないでしょうか。サイトが消えてしまっていて…。

日本語でアクティビティ図とか、少し書いてみたいだけですので、
問題があったらスルーしてください。

683 ：682：03/09/23 02:51

ぐぁ、ごめんなさい。先にこのスレ見てたので
先入観から、特殊な方法が必要なのかと思ってました。

フォント変えるだけですね…久しぶりに逝ってきます。

684 ：デフォルトの名無しさん：03/09/23 15:08

>>681
>概念モデルならば、継承＝分類関係、集約＝所有関係と言い切れる。

勝手に言い切るんじゃねぇ。お前は神か。ちょっとは概念モデルの勉強しろ。

685 ：デフォルトの名無しさん：03/09/23 17:31

あ、けんかしないで。>>684
結局どうなの？

686 ：デフォルトの名無しさん：03/09/23 17:36

>>681
言い切れるはいいすぎかもね。
仕様と実態的な継承も使われる。
ただ、この使い方は、個人的にあまり賛成できない。
他人が見て理解するのが難しい。

という意味で、割り切って681的な使用法とするのがいいかもしれない。

どーなのよ？　>>684

687 ：デフォルトの名無しさん：03/09/23 17:43

ぐわ。
s/実態/実体/
です。

688 ：デフォルトの名無しさん：03/09/24 04:16

>>686
時と場合による。
そもそも681は分類とオブジェクトコンポジション、集約の区別がついていない。

分類はあくまで大まかなカテゴリ分けをする際に利用される概念。継承関係は発生しない。
継承関係を発生させるのはオブジェクトコンポジションとクラス継承。
概念、物理ふくめて領域モデルでは大体オブジェクトコンポジションが適切なときがほとんど。
ただし継承元オブジェクトの種類が多く、それによってアルゴリズムの切り替えが多数発生するときは、
はじめからクラス継承がいい。またはインターフェースを利用してそのアルゴリズムをプラガブルにしておく。

集約とかコンポジションは継承関係とか関係なし。ただ所属してたり、部品だったり、持っているするだけ。

689 ：デフォルトの名無しさん：03/09/24 08:35

>>688
>継承関係を発生させるのはオブジェクトコンポジションとクラス継承。
>集約とかコンポジションは継承関係とか関係なし。
意味不明

690 ：デフォルトの名無しさん：03/09/25 00:36

UMLプロフェッショナルなかた

やさしいUMLって本どうおもいますか？

僕はこれ読んで「感動した！（獏）」って感じですけど
実際はそうでもない？

691 ：デフォルトの名無しさん：03/09/25 00:46

>>688
概念モデルにしぼろうや。

692 ：デフォルトの名無しさん：03/09/25 00:48

>>688 OK。君とははなしても無駄みたい。

693 ：デフォルトの名無しさん：03/09/25 06:17

>>689、692
理解できねぇお前があほなだけだ。氏ね。

694 ：デフォルトの名無しさん：03/09/25 11:19

なかなかクラス図かかけない　ＥＲ図なら動物的な
勘で、かけるんだけどなぁ　

695 ：デフォルトの名無しさん：03/09/25 11:49

つづきだけどＷＥＢアプリの詳細クラス図はかけそうな
気もするが、それ以外の概念レベルとかはさっぱりわからん

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

UMLで工数の計算はできますか

697 ：デフォルトの名無しさん：03/09/26 01:27

UMLのLってなんだか知ってる？

698 ：デフォルトの名無しさん：03/09/26 05:23

Love

699 ：デフォルトの名無しさん：03/09/26 05:53

Lolita

700 ：デフォルトの名無しさん：03/09/26 09:28

Unified Modeling Language

701 ：デフォルトの名無しさん：03/09/26 18:42

　　　　　　☆ へぇー
　　　　　　　　　　　〃Λ＿Λ 　／￣￣
　　　　　　　　　　　（　・∀・）＜へぇー
　　　　　　　　┏┓⊂　⊂＿)　＼＿＿
　　　　　　／￣￣￣￣￣￣￣／|
　　　　　　　　| ￣￣￣￣￣￣￣:|　:|
　　　　　　　　|　|￣￣￣￣￣￣|　|　 |
　　　　　　　　|　|　　　 ┃　　　|　| 　|
　　　　　　　　|　|　　　 ┃　　　 |　| 　|
　　　　　　　　|　|　　　 ┃　　　 |　| 　|
　　　　　　　　|　|＿＿＿＿＿＿|　|／
　　　　　　　 └───────┘

702 ：デフォルトの名無しさん：03/09/27 00:56

えーと
UnkoとMankoと…Lはなんだっけ

703 ：デフォルトの名無しさん：03/09/27 09:58

>>702
Loadbalanceでは？

704 ：デフォルトの名無しさん：03/10/01 08:32

>>696
できない。あきらめろ

705 ：デフォルトの名無しさん：03/10/01 21:50

クラス図でイタリック表記は純粋仮想の時でOK?
仮想もイタリック？

706 ：デフォルトの名無しさん：03/10/01 22:01

純粋仮想って、JavaのInterfaceと同等？
なら、<<interface>>なるステレオタイプでいいのでは？

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

Javaで、「抽象メソッドしかない抽象クラス」と「インターフェース」は別でしょう。
C++の純粋仮想クラスもまたインターフェースとは意味が違うのでは?

概念モデルでは変わらないかもしれないけど

708 ：705：03/10/01 22:20

ごめん。言葉が足りんかった。操作の表記の話です。

709 ：デフォルトの名無しさん：03/10/02 17:50

>>708
>抽象クラスの名前または抽象操作のシグナチャは、斜体で表示する。
UML表記法ガイドVer1.1

710 ：705：03/10/02 22:40

>>709
抽象操作とは純粋仮想メソッドをさすと思ってOKかな？
EAでC++をリバースするとvirtualで斜体になってしまうけど
これは間違いということか？
ちなみにpure virtualをリバースすると斜体+<<pure>>という
ステレオタイプがつくけど

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

Jude 竹って使ってみてどうでしょうか？

UMLの勉強で使用してみたいと思っているのですが、
ほかのソフトとの比較、良い点、不満な点があったら教えてください。

http://www.objectclub.jp/Jude/

712 ：デフォルトの名無しさん：03/10/03 06:30

>>710

709を書いた者ではないですが、

UML自身は、特定の言語を前提として定義されていないので
抽象操作がC++の何に対応するかというのは、厳密には
定義されていないということになる

ただ、抽象という言葉はabstractあるいはvirtualと
等価であると思うので、私自身はC++ならvirtual=斜体で
いいと思う

713 ：デフォルトの名無しさん：03/10/05 20:01

状態遷移図、すげぇぇぇぇぇ!!!!! UMLさいこーーー!!!!!
複雑なのがあっというまにコーディング出来ちゃったよ
しかもコードだけ見ても分かりやすい。もう失禁しそう。

もっと刺激的なのないかな(;´Д`)ﾊｧﾊｧ
アクティビティ図とかは、つまらなそうなんだよなぁ、正直

714 ：デフォルトの名無しさん：03/10/05 20:02

駄レスでageちゃって、ごめんよ・・・・

715 ：デフォルトの名無しさん：03/10/05 20:03

＿|￣|○il|li

716 ：デフォルトの名無しさん：03/10/05 20:08

>>715
ガンガレ

717 ：705：03/10/06 00:47

>>712
>UML自身は、特定の言語を前提として定義されていないので

確かにそのとおりだが、斜体の操作は実装を持たないことを
表現していると考えると斜体の操作をC++のvirtualと
書くのは不自然で、virtual =0としなくてはならんと思うんだが。

>抽象クラスの名前または抽象操作のシグナチャは、斜体で表示する。
これを
斜体の操作は実装を持たないことを表現している
と取ってよいものか？

718 ：デフォルトの名無しさん：03/10/07 00:45

>>717
「抽象=abstract」っつーのは「実装を持たない」の意とは違うと思うが。
例えばクラスの場合、完全に実装を持たないのはinterfaceであり、
abstractは部分的に実装を持つものを指す。

操作の場合は、
　ａｂｓｔｒａｃｔ = 「実装を持たないか仮の実装を持つ」 = virtual
で良いと思われ。

719 ：デフォルトの名無しさん：03/10/07 01:34

「UMLリファレンスマニュアル」より引用。
--
抽象操作(abstract operation)
実装のない操作、すなわち仕様はあるがメソッドを持たない操作。
実装は、子孫の具象クラスで提供されなければなりません。
(中略)
抽象操作の名前はイタリック体で示されます。

メソッド(method)
操作を実装したもの。メソッドは、操作の結果を生み出すアルゴリズム、
すなわち手続きを具体的に記述します。
--
よってUMLの定義に厳密に従えば、C++の場合は
「イタリック体で表記される操作」=「純粋仮想関数」
になると思われ。

720 ：デフォルトの名無しさん：03/10/10 21:50

OMGの試験、選抜された香具師いる？

721 ：デフォルトの名無しさん：03/10/12 12:08

ｵｰﾏｲｶﾞｰ

722 ：デフォルトの名無しさん：03/10/13 10:37

UML参考書籍でよいのって何があるの？

723 ：705：03/10/13 11:22

719の意見がただしそうなので、
斜体＝純粋仮想と考えてUML使うことにします。
EAのリバースついては掲示板で聞いてみようかな。

724 ：デフォルトの名無しさん：03/10/13 12:29

>>722
ファウラーのやつ

725 ：デフォルトの名無しさん：03/10/13 12:30

マーティン・ファウラー UMLモデリングのエッセンス
ケンドール・スコット入門UML
クレイグ・ラーマン　実践UML

726 ：デフォルトの名無しさん：03/10/17 15:41

力だめしにシルバー受けてみた。
むずい・・・。ブロンズと大違いやんけ。
結果101点。ひゃーぎりぎりかぁ。修行がたらんなぁ。

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

実践UML
第二版発売age

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

>>725
今気づいたけど
イヴァーヤコブソン, ジェームズランボー, グラディブーチ
がかかわってる本はそこにはないですね

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

>727
初版とどんくらい変わってる?
時代が古いだけに訳がこなれてないが、もれに責務というものを教えてくれた名著なので
ちょっと思い入れが。

730 ：デフォルトの名無しさん：03/10/21 23:00

まあ、K&R や Stroustrup いい参考書じゃないのと同じ。
UMLユーザーガイドでUML学べるかっての。

731 ：デフォルトの名無しさん：03/10/22 06:37

実践UML 第二版買いました。
UMLとかパターン本ってゆうかUPをどのように適用するかって本ですね。

ユースケースとか問題領域モデリングとかのテーマに関しては、中途半端な解説内容で
勉強したい人はこの本の内容を鵜呑みにしないで専門の本を買ったほうがいいと思います。

UPのフェーズにあわせて章立て進んでいきますが、テーマが分散していて読み終わることには
最初のほうに書いてあったことを忘れてしまいそうです。

あんましお勧めしません。

732 ：デフォルトの名無しさん：03/10/23 03:15

そろそろ UML 2.0 対応の書籍出ないかな

733 ：デフォルトの名無しさん：03/10/23 06:12

>>732

UML Distilled 第3版

ただし翻訳されてないけど

734 ：デフォルトの名無しさん：03/11/09 23:15

>>580
ｶﾞｯ

735 ：デフォルトの名無しさん：03/11/18 23:43

konesaってどうよ？

736 ：デフォルトの名無しさん：03/11/18 23:49

>>735
このスレでの話題にされ具合で察してください。

おまえらUMLのモデリングツール何つかってますか？
http://pc2.2ch.net/test/read.cgi/tech/1046441663/

737 ：デフォルトの名無しさん：03/11/22 00:39

なんか、こっちで質問した方がよさげなので
こちらで質問させてもらいます。

いま、初めてクラスとDBを使ってプログラミング
をしようと思っています。
その練習として
名前とメッセージだけのDBを使った掲示板を作ろうと思っています。

最低限作るべきクラスとしては
①メッセージクラス($name,$msg/ 名前設定・読み込み()、メッセージ設定・読み込み() )
②DB基本クラス(DBへの接続などを行う)
③DBクラス($name,$msg/$name,$msgをDBへ書き込む・読み込む() )

で、③は②を継承して②と①は関連してるというクラス図になると思うのですが
③でメッセージ・名前のカキコミを行うときは
①からコンストラクタに値を渡して、コンストラクタで
名前とメッセージを設定するべきなのか
それとも
③に名前を設定する関数、メッセージを設定する関数を入れて
名前とメッセージを設定するべきなのか、それとも別にもっと良い方法があるのか
で、迷っています。
前者だと、カキコミ時はいいのですが、DBからの読み込み時に
無駄にコンストラクタが動いてしまうし
後者だと書き込むプロパティ（ipやパスワード等）がどんどん増えていったときに
たった１行だけのメソッドを大量に作り、また呼び出さなければならなくなるので
なんか面倒そうです。

一般的にはどのような手法をとるものなのでしょうか？
宜しくお願いします。

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

＜丸数字は不可＞

何がしたいのかいまいち判らんのだが、
（３）が（２）を継承するというのがまず？だ。
さらに、（３）があるのに（１）と（２）の間に関連を引くというのもよくわからん。
このスレ的なアドバイスとしては「ユースケースから根本的に見直せ」かいな？

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

まちがえました
（１）と（２）じゃなく（１）と（３）の間に関連でした。

740 ：デフォルトの名無しさん：03/11/22 09:11

>>737
Perlっぽいなぁ。
(1)は(3)を知らなくていい。(1)のプロパティの保存や取得は、全て1つの関数で
するようにしたら？別の関数にするのではなくて。

XPかぶれの漏れの意見だが、とりあえず一番シンプルな方法で作ってみる、
あとで似たようなこと（別のテーブルに保存する、など）をするときに
最初はコピペで作ってみる、一通り動いたら両方で重複するコードが
無くなるように設計を変更する、っていうのでどう？

む、この回答ではスレ違いだ。というか質問自体UMLとの関係が低そうだ。

741 ：デフォルトの名無しさん：03/11/22 13:58

>>737
エンティティ、バウンダリ、コントロールとオブジェクトの役割を分ける設計方法がある。
とりあえずこれでも読んでくれ。
http://www.ogis-uml-university.com/download/download2.html

742 ：デフォルトの名無しさん：03/11/25 01:21

レスどうもです
こういった
どういう風にクラス図をつくるべきかって
スレってあるのでしょうか？
もしくはwebでもいいのですが
DBなしで考えても
いまいち決まらないです
単にID名前メッセージを入れるだけなのに
やっぱり僕にオブジェクト指向なんて無理なのかな…

743 ：デフォルトの名無しさん：03/11/25 01:32

>>742
>>741は読んだか？

オブジェクト指向ってのは知識じゃなくて技能だからある程度は経験積まんと見えてこん部分もあるよ。
取敢えず動くもんを組んでみるべ。最初から完璧なものはできんだろうが、それはそれで経験になる。
同じプログラムを視点を変えて何度も分析実装てみるというのもいい。
まぁ、がんばってちょ。

744 ：デフォルトの名無しさん：03/11/25 21:58

WebアプリのUMLのクラス図書きたいんだけど、JSPは
どーやって表現するんでつか？

745 ：デフォルトの名無しさん：03/11/26 00:17

JSPごとにクラスを描く、じゃ答にならないのかな？

746 ：デフォルトの名無しさん：03/11/26 10:50

UIクラス(ウィンドウなど)と問題領域のクラスとの間の
関連を実装するときに、
UIクラスに問題領域のオブジェクトのポインタを持たせるべきなのか
それともその逆なのか、どちらなのでしょう・・・

747 ：746：03/11/26 11:27

質問が悪かったです。
UIクラスから問題領域クラスへの単方向関連を張るべきなのか
それとも逆なのか・・・

748 ：デフォルトの名無しさん：03/11/26 22:51

UI からドメインのオブジェクト。

749 ：746：03/11/26 22:58

ありがとうございます
スッキリしました。

750 ：デフォルトの名無しさん：03/11/27 00:28

>>742
おいらも同じところで悩んでる。
>>743のいってることもわかってるつもりなんだけどね

こういう分析の（具体的な）方法がある　みたいなサイト、本ないですかね？

751 ：デフォルトの名無しさん：03/11/27 00:43

いや、そうとも限らん。
UIの使い回しが考えられるなら、間にcontrollerを置いて
そこから両者へ単方向関連を張るやりかたも多い。
その場合、UIの操作を受け取るためのinterfaceを用意して
controllerがそれを実現する形をとるので、UIは他のクラスに
依存しない独立性の高いものにできる。

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

>>750
難しいなあ。
@IT の記事全部とピアソンのインターネット関連/オブジェクト指向技術カテゴリの本を20冊くらい読むとか。

753 ：746：03/11/27 07:43

>>751
なるほど…
うまいこと考える人もいるもんだなぁ

754 ：デフォルトの名無しさん：03/11/27 09:08

>>750
アナリシスパターン・・・UMLじゃないか

755 ：デフォルトの名無しさん：03/11/28 07:36

>>750
S/M法によるオブジェクトモデリングとか読んでみれば？
ﾋﾟｼｯ

756 ：デフォルトの名無しさん：03/11/29 11:46

問題領域に関する本はたくさんあるが
それをコンピューター領域と組み合わせて
どう実装し、どのようなコードを書いていくかまで
説明している本がほすぃ。
憂鬱な～などイロイロ読んだが、
どれも抽象的な話ばかり。
読めば理解できるんだが
実際コードを書こうとするとつまずく。

757 ：デフォルトの名無しさん：03/11/29 12:21

そんな本があったら俺が欲しいよ。
その辺はもう形式知として文章にできるような代物じゃないからなあ

758 ：737：03/11/30 21:13

DB使わないタイプのを作ることにしました。
とりあえず、投稿する部分だけ、書いたのですが
なんか、ちがうような…
アドバイスあればよろしくお願いします・・

クラス図
http://diary.lowsrc.org/archives/bbs7.png

クラスの定義
http://diary.lowsrc.org/archives/phps/cbbs/classbrd.phps

書き込み用のウィンドウ
http://diary.lowsrc.org/archives/phps/cbbs/submit.phps

759 ：737：03/11/30 21:14

あ、PHPです。

760 ：737：03/11/30 21:17

今気づいたんですが、
変数をprivateとしてあつかった方がいいっすね・・

761 ：デフォルトの名無しさん：03/11/30 22:24

取敢えず、気のついたことだけ。
PHPは知らんからUMLだけね。

分析段階から設計段階をすっとばしてコードに落としてるね。
これじゃうまくいかなくて当然。
その分析段階のクラス図も抜けが多い。
ま、一番始めはこの程度のものからスタートするんだけど、
これを分析を進めてどんどん膨らませてゆく訳よ。
「とりあえずクラス図書いてみました。んじゃコード」
これじゃ分析にならんよ。

UMLを真面目に勉強するつもりなら、クラス図の他の図も勉強しな。
とりわけシーケンス図は役に立つよ。
>>758の分析もシーケンス図を書いてみれば何が足りないのかすぐに気がつくと思う。
もちろんその他の図も覚えたほうがいいけど、まず最初はこの２つを使いこなせるようにする。
がんがれ。

762 ：737：03/11/30 22:47

ありがとうございます。
一応、憂鬱な～っていう本を一通り読みました。
シーケンス図も考えてたんですが
エライ単純になっちゃうようなきがするんで・・
とりあえず、作ってみました。
http://diary.lowsrc.org/archives/2003_11.html

足りないクラスって何ですかー。

763 ：デフォルトの名無しさん：03/11/30 23:41

色々言いたいことはあるのだけど今時間が取れないので手短に。

その壱
憂プラはオブジェクト指向の入門書としては最適だけどUML（という言葉の無かった頃の本）の
解説はさすがに古い。新しめのUMLの入門書を１冊仕上げた方がいいような。
少なくとも>>741は読もうね。

その弐
利用者に着目したのは筋がいいです。
利用者の振る舞いはユースケース図で分析します。
でも憂プラが書かれた頃はユースケースが着目されてなかったんで解説がほとんどない(笑

その参
その利用者の振る舞いですが、「掲示板を読む」と「掲示板に書きこむ」と大きく２つあります。
それぞれ必要とされるクラス・メソッドが異なります。これをはっきりさせること。
この辺はクラス図を書いてるだけだとよく分からないのでユースケース図やシーケンス図が
必要になるんです。
ただ、全ての投稿を時間順にずらずら並べるだけの掲示板なら「読む」方はあまり考慮する
必要が無さそうですけどね。
でも、その場合でも、「投稿があったらそれを表示する」というプロセスは必要でしょ？
シーケンス図はそこまで考えましょう。

764 ：デフォルトの名無しさん：03/11/30 23:43

その四
「メッセージを作る」というメソッドが方々にありますが、「メッセージを作る」のは一ヶ所で、
あとは「メッセージを渡す」「メッセージを記録する」になるのでは？

その五
本来は分析段階でウィンドウクラスやファイルのことは考慮しないんですが・・・。
しかし、投稿ウィンドウがファイルに書きこんだり、掲示板ウィンドウが直接ファイルから
読込みますか(笑
それだと掲示板クラスがメッセージクラスを集約するという分析が無意味になりますぜ。
もう一度ウィンドウクラスは外して分析してみたらどうでしょう。

以下はまた後で。じゃね。

765 ：737：03/11/30 23:56

ほんと、参考になります。
ありがとうございます。

766 ：デフォルトの名無しさん：03/12/01 03:16

モデリングツールスレにも書いたけど

Dynamic Draw
http://www.molips.com/jp/intro/index.html
これよくないか？

767 ：デフォルトの名無しさん：03/12/01 03:39

>>766
モデリングツールスレでも書こうかと思ったけど

うざい。

つかさ、図を書くだけならモデリングツールとは言わんのよ。

768 ：デフォルトの名無しさん：03/12/01 06:57

モデリングツールではなくドローツールやね。

769 ：デフォルトの名無しさん：03/12/03 12:54

UIオブジェクトはユーザインターフェースとすると
PDオブジェクトってなんですか？

770 ：U ◆CZtFsGiu0c ：03/12/03 19:04

>>769
UIオブジェクトとかPDオブジェクトとかどこから引っ張ってきた用語?
PDってProblem Domainの略かな? 文脈がわからないと答えようがないよ。

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

>>767,768
ttp://exportsrc.sourceforge.jp/
単なるドローツールではないよ。
ソースの雛型位ならプラグインで生成できる。

…もっともこの程度じゃ、モデリングツールには程遠いが。

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

>>771
宣伝うざい。
＞…もっともこの程度じゃ、モデリングツールには程遠いが。
それが分かってたら一々レスするなよ。

773 ：デフォルトの名無しさん：03/12/06 07:28

からage

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

737の人ではありませんが、私もUMLを始めようと思ったので同じ事をしようと思います。
きちんと分析しるという事なので、なるべくそのように心がけるつもりです。

やりたい事：
・ユーザーが掲示板にアクセスすると、投稿記事が一定数(とりあえず10レス)表示される
画面が表示される。
・ユーザーは掲示板に書き込みができる。ただしタグは使えない。
・ユーザーは自分の書き込んだ投稿記事を削除することができる。
・管理者は掲示板にアクセスし、パスワードを入力する。
・認証で問題が無ければ、管理者モードになる。
・管理者モードは、以下の事以外は、通常モードと一緒である。
□任意の記事を削除できる。
□タグを使って投稿できる。

775 ：デフォルトの名無しさん：03/12/06 11:36

>>774
手順を踏んでやりたいならまずはユースケース図を書いてみ。
このレベルでは例外的な事柄や細かい機能は書かなくていい。

図を書いたら資料の二つ目にあるようなユースケース記述を書く。
774 氏が「やりたい事」に書いたのをもう少し詳細にした感じ。
機能ではなくて、アクターがこうしたらこうなるという書き方で
(例）タグは使えない→タグを含めた投稿をするとエラー画面に遷移する)。
だるいけどこれが書けると作るものが何かがほとんど決まる。

資料
http://uml.ogis-ri.co.jp/tutorial/analysis/do_work/dowork1_1.html
http://www.relaxer.org/process/sample/library/LibrarySystem1.1/LibrarySystem.html

776 ：774：03/12/06 12:47

ユースケース図です。
http://montpython.s13.xrea.com/uml/usecase.png
ユーザーと管理者の機能が似通っているので、ユーザーから管理者へ継承するか、
共通のインターフェースなり抽象クラスを作ることになると思いました。

ユースケース記述は、いきなりイベントフローを記述するのは大変なので、
いくつかシナリオを書こうと思います。

777 ：デフォルトの名無しさん：03/12/06 13:06

>>776

この場合、
「ユーザーのできることは管理者でもできる」
「管理者のできることはユーザーができるとは限らない」

ので、ユーザーを親アクター・管理者を子アクターとして
汎化関係を作るとよいと思うのですがどうでしょう？

PostMessageについては、名前が同じで機能がちょっと
違うので、Extendするとよさそうな気がする

778 ：デフォルトの名無しさん：03/12/06 13:08

補足

方針として、
・同じユースケースは複数作らない
・似たユースケースはうまく共通部分を取り出す
って感じでしょうか。

779 ：774：03/12/06 14:57

ええと、こんな感じでしょうか？
http://montpython.s13.xrea.com/uml/usecase2.png

ところで、継承すると
http://montpython.s13.xrea.com/uml/extend.png
ですが、
インターフェースや抽象クラスにすると
http://montpython.s13.xrea.com/uml/usecase2.png
となってこっちの方がすっきりしてそうですが。
でも、UserとAdminというクラスを作ってごそごそした方がいいかな。

780 ：デフォルトの名無しさん：03/12/06 16:57

シナリオ１：ユーザーによる掲示板の閲覧と書き込み
ユーザーのモナーはWebブラウザでhttp://www.foo.com/bar/にアクセスすると掲示板が表示された。
掲示板は投稿フォーム(名前、メールアドレス、本文、削除用パスワード)があり、
その下に投稿記事が１０件表示されていた。

モナーは投稿フォームに名前、本文を入力して「送信する」ボタンを押した。
しかし、削除用パスワードが入力必須であるため(メアドは任意)、
「削除用パスワードを入力してください」というエラーメッセージが表示された。
モナーはブラウザの「一つ前に戻る」ボタンを押し投稿前の画面に戻した。
モナーは投稿フォームに名前、メールアドレス、本文、削除用パスワードを入力し、
「送信する」ボタンを押した。
そうすると投稿フォームと投稿記事が表示され、投稿記事の一番上に
今投稿した自分の記事が表示されていた。

こんなところでしょうか？

781 ：デフォルトの名無しさん：03/12/06 17:13

シナリオ２：過去の記事の閲覧
ユーザーのモナーはWebブラウザでhttp://www.foo.com/bar/にアクセスすると掲示板が表示された。
掲示板は投稿フォーム(名前、メールアドレス、本文、削除用パスワード)があり、
その下に投稿記事が１０件表示されていた。
さらにその下に、「次のページ」というボタンが表示されていた。
モナーは「次のページ」というボタンを押した。
そうすると投稿フォームと、次の１０件の投稿記事が表示され、
その下に「前のページ」「次のページ」のボタンが表示されていた。
モナーは「前のページ」というボタンを押した。
そうすると投稿フォームと、前の１０件(つまり元の１０件)の投稿記事が表示され、
その下に「次のページ」のボタンだけが表示されていた。

このシナリオは「記事の閲覧」なのでユースケース図に新しく追加する必要はありませんよね？

782 ：774：03/12/06 18:42

あ、ユースケース図間違っていました。訂正
http://montpython.s13.xrea.com/uml/usecase3.png

この２つのシナリオから、「View Message」ユースケースについてユースケース記述を作成してみます。
ユースケース名: View Message
1. 概要: 投稿記事およびフォームを表示する。
2. 事前条件: すでに投稿された記事があり、各記事がファイル(かDB)して存在すること。
2.2. 基本フロー:
(1) ユーザーはWebブラウザ上からアクセスする。(HTTPでHTMLを要求するって書くべき？)
(2) システムはファイルに納められている投稿記事データからIDが最新順に10件取り出す(E-1)
(3) システムはヘッダ、投稿フォーム、10件の投稿記事データ、「次のページへ」
とあるボタン、フッタを出力する。
(4) ユーザーは「次のページへ」のボタンを押す。
(5) システムはファイルに納められている投稿記事データから、次に最新である10件を取り出す(E-2)
(6) システムはヘッダ、投稿フォーム、10件の投稿記事データ、「前のページへ」ボタンと
「次のページへ」ボタン、フッタを出力する。

783 ：デフォルトの名無しさん：03/12/06 18:48

2.3 代替フロー:
(E-1):(2)で投稿記事データが10件に満たない場合、(3)で「次のページへ」のボタンは出力せず、
投稿記事は全件出力し、ユースケースは終了する。
(E-2):(5)で次の投稿記事データが10件に満たない場合、(6)で「次のページへ」のボタンは出力せず、
投稿記事は残り全件出力する。
2.4 事後条件: なし

これらをユースケース毎にシナリオをいくつか書いて、それを元に
ユースケース記述を作成するということでいいんでしょうか。

784 ：デフォルトの名無しさん：03/12/06 20:55

↑勉強熱心なのはいいがもうちょいおちつけ。

おまえさんのかいているのはユースケース図ではない。
まずちゃんとしたユースケース図をかくところかは始めろ。

785 ：デフォルトの名無しさん：03/12/06 21:50

>>784
>まずちゃんとしたユースケース図をかくところかは始めろ。
どれがきちんとしてるのかがさっぱりです。各機能を分割してユースケースにしたらあかん
というのはわかっているつもりですが。入門書みてもアクターから３つぐらいのユースケースに
線が引かれていて、それぞれの説明がされているだけでした。
というかユースケースで汎化関係使えるのも知らなかったです。すいません。

786 ：デフォルトの名無しさん：03/12/07 00:44

784が言いたいのは、「ユースケース図を何のために書くんだ？」
という基本的なことを自問しなさいって事だと思うよ。
ＵＭＬを道具として使えるか、ＵＭＬに使われるかは、それで決まる。

787 ：デフォルトの名無しさん：03/12/07 01:05

機能の捕らえ方が問題。
実装するのが自分(達)だから、どうしても内部的な処理の分け方をしてしまうと思うけど、
ユースケース図はuse case、つまり使用する側の立場に立って考える。
外から見てどういう風に処理が分かれているのか、という点が大事。
まずはそれを洗い出して、必要ならincludeやextends関係を構築する。
まずは外部設計ってことね。

788 ：デフォルトの名無しさん：03/12/07 01:05

>750
遅レスで、コメン。

この手の本がこの世に無いのは理由がある。
人間は、その人の頭の中にあるものしか表現できない。
その人の頭に自然に浮かぶプロセスを言葉で表現するのは難しい。

業務要件を理解したり、ユースケースドキュメントを読み書きしている時点で、
なんとなく、頭の中でクラス図ができていないと、分析はできない。
クラス図を書いている時は、頭の中を整理したり、間違いの修正や、細かい詰めをやっているだけ。
これは、人間が普通に持っている能力だから、訓練すれば伸びる。
的確で分かりやすい文章を書ける能力に近い。

理屈に頼ろうとする香具師は、ＤＱＮの傾向がある。気をつけよう。

789 ：デフォルトの名無しさん：03/12/07 08:51

ユースケース図の解説
ttp://www.atmarkit.co.jp/fjava/devs/renew_uml08/renew_uml08.html

短いけどよくまとまっている。>>774氏へのみんなのコメントと同趣旨のことが丁寧に
書かれてるので参考になると思う。

ま、だれも最初から完璧な分析なんて出来ないので、少し突っ込まれたぐらいで
へこたれないでがんがれ。
そいや、>>737氏はへこたれたままかいな。がんばってちょ。

790 ：737：03/12/07 15:08

ま　だ　い　き　て　ま　す　よ

:::::::::::::::::::::::::::::::::|,.．-──- ､　 |:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::| : : : : : : : : : ＼|:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::| : : : : : : : : : : : |:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|::,-…-…-ミ: : |:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|:i '⌒'　 '⌒' i: ::|:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|:|　ｪｪ　ｪｪ　|: :|:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|:|　　　,.、　 |: :|:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|:i　r‐-ﾆ-┐ |: :|:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|ゞヽ二ﾞノｲゞ:|:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|＼` ｰ一'´丿　|:::::::::::::::::::::::::::::::::

791 ：デフォルトの名無しさん：03/12/07 15:52

>>782
＞ユースケース名: View Message

フローが日本語ならこれも日本語にしよう。ここで命名の語彙を
気にする必要もないし。

＞1. 概要: 投稿記事およびフォームを表示する。

主語を書くか、あるいはアクタの項でプライマリアクタを明記
するか、どっちかしておいた方が良い。

＞2. 事前条件: すでに投稿された記事があり、各記事がファイル(かDB)して存在すること。

ファイルとかDBとか実現方式の話は無くても良いな。決めかねて
いる話なら、尚更書くべきじゃない。どうしてもユースケース記述に
含めたかったら、別項（例えば「技術メモとか」）で補足しよう。
（ちなみに俺だったら投稿無しは代替フローで扱うと思う。）

（続く）

792 ：デフォルトの名無しさん：03/12/07 15:53

（続き）
＞(1) ユーザーはWebブラウザ上からアクセスする。(HTTPでHTMLを要求するって書くべき？)

ツールやプロトコルより大事な事が書かれてない。
フローの記述について、こんなガイドラインを挙げる人もいる。
show the actor's intent, not the movements

＞(3) システムはヘッダ、投稿フォーム、10件の投稿記事データ、「次のページへ」

ヘッダ、フッタ、ボタンはユースケースの外（UI仕様書とか）に
書いた方が良い。ユースケースだけで外部仕様全体をカバーする
必要ないし。

＞(4) ユーザーは「次のページへ」のボタンを押す。

(4)～(6)は、次10件の閲覧が可能である事が書かれていれば十分。

>>783
代替フローのナンバリングの仕方なら、(E-1)とか(E-2)とかよりも、
>>775の2つ目のリンクのやり方がお勧め。

793 ：774：03/12/07 21:25

使用する立場に立って考えるというんですね。
システムに素人なユーザーでもわかるように書くということでしょうか。
わかっているつもりでも、「ここまで大胆に(？)書いてもいいんだろうか？』と不安になって、
ついDBやファイルなど、システム周りの細かいことを書いてしまいます。

とりあえずユースケース記述だけ書き直してみます。

794 ：デフォルトの名無しさん：03/12/07 22:34

>>793
＞システムに素人なユーザーでもわかるように書くということでしょうか
ちょっとちがう。
「そもそもこれから開発するシステムは何をするものなのか？」を明確にする。

君がやっているのは、すでに自分の頭の中にあるプログラムの構想を書出してるだけ。
これだとシステムの自分が認識している部分はどんどん詳細になるけど、
もし見落としている部分があると、それは何時までたっても分析対象として浮上してこない。
そのまま実装段階に入ると途中で機能追加＆仕様変更なんてことになりかねない。
ま、練習なんだからそれを経験するのもいいと思うけど。

795 ：774：03/12/07 23:23

>>793
つまり今まで私がやってきたのは、「どのようにしてシステムを動かすか？」という考え方であり、
それは間違いであって、「何をこのシステムでするのか？」「なぜこのシステムは必要なのか？」
という考え方がユースケースであるということでしょうか？

796 ：login:Penguin：03/12/07 23:53

>795

>「何をこのシステムでするのか？」
その通りです。
それを把握するために、シナリオをヒアリングするわけです。

797 ：794：03/12/08 00:35

>>795
もう他の人からレスがついてるけど。

君の目的が「WEB掲示板システムをつくること」なら、
どんな開発手法を取っても君の自由なので間違いも何もない。

しかし、君の目的が「UMLとそれを利用した開発手法を学ぶこと」なら
>>795の問いにはイエス。
「どのようにシステムを動かすか？」という視点が不要な訳では全くない。
しかし、その分析はもっと後でやる。

798 ：デフォルトの名無しさん：03/12/08 01:18

>>794
＞そのまま実装段階に入ると途中で機能追加＆仕様変更なんてことになりかねない。

プログラマが勝手に脳内仕様で補完したりする方が嫌だな。
特に代替フロー、あとログとか。

799 ：デフォルトの名無しさん：03/12/08 10:45

良スレage

800 ：デフォルトの名無しさん：03/12/10 23:30

アクター側の視点に立ってユースケースを書き直してみます。

アクターユースケース
--------------------------------------------------------
ユーザー掲示板を閲覧する
掲示板にメッセージを投稿する
自分の投稿メッセージを削除する
--------------------------------------------------------
管理者投稿されたメッセージを管理する
--------------------------------------------------------

「何をシステムでやりたいのか？」を考えると、
管理者がやりたいのはメッセージの削除などの「メッセージ管理」ですので、
ユーザーのユースケースである「掲示板を閲覧する」「掲示板に投稿する」はおかしいと思い、
「投稿されたメッセージを管理する」としました。

ところで、「管理者はタグを使って投稿できる」はユースケースにする必要はないでしょうか？
管理者がやりたい目的を考えると、管理者のユースケースにしてしまうのはおかしな気がしました。
(ユースケース「掲示板に投稿する」の付けたしみたいで変？)これはどこに書くべきでしょうか？
ユーザーのユースケース「掲示板にメッセージを投稿する」でイベントフロー上の代替フローにでも
記述するのでしょうか？

801 ：デフォルトの名無しさん：03/12/11 07:42

>>800
そんな感じでいいと思いますよ。
あとは個々のユースケースをもう少し細かく分析して、必要なユースケースを付け足して行く。
ユースケース図を書いた方が分かりやすいと思う。

「タグ付きの投稿をする」もユースケースとしては必要でしょう。汎化をつかうのかな？

802 ：774：03/12/11 22:22

>>801
>「タグ付きの投稿をする」もユースケースとしては必要でしょう。汎化をつかうのかな？
ユースケースについてはまだわかっていないので無理に構造化をしません。
下手をするとまたシステムの設計をやらかしかねないので。
ユースケース記述をひとつやってみました。

ユースケース:掲示板を閲覧する
アクター:ユーザー
概要:

803 ：デフォルトの名無しさん：03/12/11 22:47

途中で送信してしまった。

概要:このユースケースは、ユーザーが、投稿されたメッセージを取得できるようにする。
事前条件:なし？

イベントフロー:
1.ユーザーはシステムに掲示板の表示を要求する。
2.システムは投稿されたメッセージの一覧を出力する。

代替フロー:
2で投稿されたメッセージが存在しない場合、何も出力しない。
2でメッセージを1ページで表示しきれない場合、他に表示ができるメッセージがあることを
ユーザーに通知する。

ずいぶんシンプルになってしまいました。代替フローで「何も出力しない」とありますが、
実際は投稿フォームなどがあるのですが・・・これでいいのでしょうか？

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

>>803
例えば漏れが自分のスタイルでが書くとこんな感じになると思う。
最初に断っておくけど、これで正解という意味ではないし、これで十分という意
味でもない。取り敢えず最初のスケッチはこんなもんということ。だからナンバ
リングは考慮してない。

掲示板システムユースケースフロー
1.掲示板の閲覧
1.1初期ページの表示
アクター：ビジター
事前条件：なし
ビジターが掲示板を開くと、掲示板システムは初期ページを表示します。
初期ページには間近に投稿された記事が10件と、それよりも古い記事を閲覧する
ための「前の記事」メニューと、投稿用のフォームが同時に表示されます。

代替フロー
1.1S1
投稿された記事が10件以下のときは、掲示板システムは「前の記事」は表示しな
いで、記事と投稿用フォームのみ表示します。
1.1S2
投稿された記事が0件の場合は、掲示板システムは初期ページに「投稿された記
事はありません」というメッセージと、投稿用フォームのみを表示します。

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

おそらく、↑の後に、1.2過去の記事の閲覧とか、1.3ページを指定して閲覧とか、
1.4全記事の一括表示とか、いろいろ続くと思うけど、とりあえず本件だと1.2だ
けでいいのかな？

ユースケースで大事なのはアクターの要求と、それにシステムがどう応えるかを
明確にすることなので、それは具体的に記述したほうがいい。
ただし、システムそのものはブラックボックスとして考えるということ。

この辺のやり方は人それぞれだけど、漏れのやり方は、最初はフローは注意書程
度にとどめて、考えられるユースケースをどんどん図に書き出してゆく。図は紙
に鉛筆でいいんで、実際に書いたり消したりした方が自分的には考えやすいな。

うーん、ひょっとしたら、ユースケースで一番大事なのは「必要なユースケースを
もれなく上げること」かもしんない。

806 ：login:Penguin：03/12/13 14:05

>805
> うーん、ひょっとしたら、ユースケースで一番大事なのは「必要なユースケースを
> もれなく上げること」かもしんない。
>
ひょっとしなくても、そうでしょう。

807 ：デフォルトの名無しさん：03/12/13 14:36

というかそれが出来れば苦労はない。

808 ：sage：03/12/13 15:43

なので、
ある程度まで出来たところで、実装レベルまで落として、
そこで必要なユースケースが発見されたら、
また、要件定義レベルへ戻って、ユースケース図に追加を行いましょう。
ってのが、RUP とかの　反復開発の考え方なんでは？

809 ：デフォルトの名無しさん：03/12/14 00:35

>>802
＞ユースケースについてはまだわかっていないので無理に構造化をしません。

コーバーンの本に汎化を使うやり方があるけど、かなり面倒くさい。
「タグ付きで投稿する」から「投稿する」への矢印だけだと駄目で、「タグ
付きで投稿する」と「タグなしで投稿する」の2つから「投稿する」に向かって
汎化しないと矛盾するらしい。止めといた方が良いかも。

ファウラーのUML本には、代替フローに書くやり方と拡張を使うやり方が
載ってる。代替フローに書くなら「アクタが管理者だった」なんて条件で
記述すれば良いんだと思う。
ただこの掲示板のケースだと、拡張はやや難しいかも。タグを使えるのと
使えないのと、どちらを拡張元にすればいいかやや躊躇う。前者なら拡張
された方を一般ユーザが使う事になるし、後者なら拡張ユースケースが
うまく書けない(少なくとも俺は)。

関連の選択で悩むより、やはりできるやり方（代替フローとか）で先に進む
のが得策かと。

810 ：デフォルトの名無しさん：03/12/14 00:52

俺も晒してみるか。

usecase name:
　掲示板を閲覧する
actor:
　ユーザ
main flow:
　1. ユーザはシステムに掲示板の閲覧を要求する
　2. システムは最新10件までの記事を取得する
　3. システムは2の結果を成形し投稿フォームと共に表示する
　4. ユーザは前後10件ずつ、システムに再表示させる事ができる
alternative flow:
　3a. 2の結果、記事が無かった
　　3a1. システムは記事が無い旨を表示する

これが実際だとすると「3a1は、これで良いですか？」とか「"10件"は
ベタ書きで良いですか?」とか、愛想笑いしながら客と話してみる。
あと「2で記事を取得するときにシステムエラーが発生したらどうなる？」
とか、誰かが俺を問い詰めたりもする。

811 ：デフォルトの名無しさん：03/12/16 12:31

クラス図とか掲示板で表記するの難しいので、横書き表記を考えてみた。

クラス：C{クラス名:属性：操作}
インタフェース：I{インタフェース名：操作}
継承：e{スーパークラス名:{ロール名:多重度}:{ロール名:多重度}}
集約：a{クラス名:{ロール名:多重度}:{ロール名:多重度}:クラス名}
コンポジション：c

例：
C{人:性別：歩く}
e{人}C{男::}
e{人}C{女::}

a{人:{勤労:*}:{雇用:1..*}:会社}

良かったら使ってくれ

812 ：811：03/12/16 23:15

間違えてた。

継承：e{スーパークラス名：派生クラス｝

C{人:性別:歩く}
e{人:{男::}}
e{人:{女::}}

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

>>811-812
俺は使ったことないが U言語なんてのがある。
http://objectclub.esm.co.jp/U-Language/

814 ：デフォルトの名無しさん：03/12/18 23:36

UMLってどれくらい現場に浸透してる？
流行だろうけど、使う使わないの現場が分かれそうな気がするんだけど

815 ：デフォルトの名無しさん：03/12/18 23:57

>>814
あるところの調査では15%とか。
まあ企業ごとの変なノウハウを押し付けられるよりは
こういった標準の方が嬉しいわな。

816 ：デフォルトの名無しさん：03/12/19 00:45

>あるところの調査では15%とか。
これかな？
http://www.atmarkit.co.jp/fjava/devs/survey/survey0210/survey0210.html
検討中まで含めるとだいぶ多いな･･･やはり流行りか

817 ：デフォルトの名無しさん：03/12/19 05:31

>>814-816

タイミング的にはこれがソースと思われ。
(両方が同じソースかもしれんけど)

「UML採用は15％以下」、新技術を警戒するユーザー企業
http://www.atmarkit.co.jp/news/200312/17/juas.html

818 ：デフォルトの名無しさん：03/12/19 17:02

結局使わないから手間がムダなばかり

819 ：デフォルトの名無しさん：03/12/19 19:27

>>813
2chで書いたりするときに、たまに使ってるよ。

>>814
かつてのお客さんは、UML指定だったな。
お客さんが「UMLドキュメントは資産になるんだからちゃんと書いてね」というところだった。
標準というものの価値を理解している、頭のいいお客だったよ。

820 ：デフォルトの名無しさん：03/12/19 19:51

なんか日本語変だぞ

821 ：デフォルトの名無しさん：03/12/19 23:24

＞「UML採用は15％以下」、新技術を警戒するユーザー企業

意外と低いんだな。驚いた。
てかユーザ企業ってどんなシステムやってるところなんだろう。
俺なんか4年前からWebアプリやってるだけど、UMLを納品しな
かった無いし、なんか不思議な気がする。

822 ：デフォルトの名無しさん：03/12/20 01:29

>>821
日本語おかしいぞ。

823 ：デフォルトの名無しさん：03/12/20 11:28

そもそもオブジェクト指向と無縁な開発も、まだまだ多いってことかな。
それともまさかBooch法とか？

824 ：sage：03/12/20 11:54

Booch法しかない時代からBooch法やるだけの先取性のあるところが、
古い方法に固執するとも思えないが。
（Booch法を導入したキレモノが退職してイモしか残ってないとかならありえるが）

でも、オブジェクト指向開発に、UML が必須というわけではないし。
UML使ってない→オブジェクト指向してない
とは必ずしもいえないと思う。

つうか、開発資料を全然作ってないところだってあるだろうし、
（開発資料をきちんと作っている会社が全体の15%　でもオレは驚かない）
きちんと開発資料を作ってる会社の中でなら、UMLを採用している会社の割合は
もう少し高いんじゃなかろうか。

825 ：デフォルトの名無しさん：03/12/20 12:26

俺は大手で大量の仕様書にまみれて仕事してるが、
使っているのはWordの文章とフローチャート図だね。
そもそも設計のイメージ図を正しく書くより、
製品の仕様の文章を正しい日本語で書くことのほうが、ずっと大事なのは当たり前。
上司やお客さんは、あいまいな図よりも開発者が言い逃れできない仕様書を望んでいるんだから。ようは言質が取りたいわけよ。
UMLじゃ解釈の違いで言い逃れできちゃうわけよ。
だからイメージ図よりもむしろ、文章の仕様書の統一基準のほうが望まれているだろうね。
これからはそういう動きが出てくるかも。

826 ：デフォルトの名無しさん：03/12/20 12:58

>>825
仕様書の話？まあ適材適所って事だろう。別に自慢げに言う事でもないと思うがね。
それとも「仕様書」をダイアグラムだけで書くようにUMLが強制でもしてたっけ？

827 ：デフォルトの名無しさん：03/12/20 13:07

>>825
うーむ、UMLはイメージ図とは違うんだがなぁ。。。
MDAで、製品そのものに近いところまで表現できるし、
仕様書の統一といった意味では、UMLを拡張して使うのが正解だと思う。
# UMLは、あるいみ仕様書の統一基準にしかすぎないわけで。

828 ：いなむらきよし：03/12/20 14:58

キケー！

829 ：デフォルトの名無しさん：03/12/20 20:13

>>825
> UMLじゃ解釈の違いで言い逃れできちゃうわけよ。
フローチャートだって言い逃れできるだろ

830 ：デフォルトの名無しさん：03/12/21 09:03

>>818
同意。
UMLで、仮にいろんなことが明確になったとして、バグが減ったのか？
結局、新しいのを追いかけて、作業量・学習量が増えるだけ。
根本が変わらない。

831 ：デフォルトの名無しさん：03/12/21 09:58

オブジェクト図で2つのオブジェクト間に2本以上のリンクを引くのはOKなのでしょうか？

832 ：デフォルトの名無しさん：03/12/21 10:18

ＵＭＬで何か明確になったか？何も変わらん
オブジェクト指向ツール作ってる会社が
ひと商売したかったということだけは明確にだったが。
あと偉そうな口叩いて実装はヘタクソな厨ＳＥが増えた。

833 ：デフォルトの名無しさん：03/12/21 11:49

業界標準のありがたみを理解していない奴がいるな。

834 ：デフォルトの名無しさん：03/12/21 12:08

>ＵＭＬで何か明確になったか？何も変わらん

じゃあ、UML 使わずにデザインパターン書いて味噌。

>あと偉そうな口叩いて実装はヘタクソな厨ＳＥが増えた。

それは、単に、UML　もわかってないんじゃないの？
実装できなくても、要件分析がきちんとできるなら、
そのレベルの話をするのは、「えらそう」でもなんでもないし、
むしろ、SEとして当然なんでは。

そもそも、現状は、数からいったら、
設計はできないが実装はできる > 実装はできないが設計はできる
じゃないの。
要件定義レベルで、まともな UML を書ける香具師がいたら、
そいつが実装はからきしだめでも、即来て欲しいよ。
ユーザーへのプレゼン用のPowerPoint資料を、
要件定義だといって渡されて、それで実装やらされるよりは、
100万倍ましだ。

835 ：デフォルトの名無しさん：03/12/21 12:30

おまえらが思ってるほど普及してないのに、何が標準化なのやら（嘲笑
もう下り坂だよ、UMLは

あと実装がヘタでが設計巧いいない奴なんて居ないよ、
そんな奴がいたら財産をそいつに全部やってその場で自殺してやるよ（笑

836 ：デフォルトの名無しさん：03/12/21 12:42

>>831
OK

837 ：デフォルトの名無しさん：03/12/21 12:47

>>835
>>820

838 ：デフォルトの名無しさん：03/12/21 13:00

>>835
>あと実装がヘタでが設計巧いいない奴なんて居ないよ、

だから、
> >あと偉そうな口叩いて実装はヘタクソな厨ＳＥが増えた。
> >それは、単に、UML　もわかってないんじゃないの？
といっているわけだが。

まあ、君個人が UMLについて、どのような見解をもとうと勝手だけど、
現状で UML に代わる手段がない以上、
（>ＵＭＬで何か明確になったか？何も変わらん
　じゃあ、UML 使わずにデザインパターン書いて味噌。）
必要とする人は、君がどう思おうと、使っていくだろうね。

君は、今受け取ってる要件定義資料に満足してるの？
それが UML よりも便利だというのなら、是非教えて欲しいもんだが。

839 ：デフォルトの名無しさん：03/12/21 13:17

>>835
煽りじゃなく参考までに教えて欲しいんだけど、
例えばクラス間の関係とかどう表現してます？

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

>>836
分かりました。ありがとうございます。

841 ：デフォルトの名無しさん：03/12/21 19:56

>>835
おれも知りたいな。CRCカード最高！とかそういうことですか？
オブジェクト指向自体を非難してるとかじゃないすよね？

842 ：デフォルトの名無しさん：03/12/22 20:32

アンチパターン
「実装溺愛」
プログラミング技能と抽象の定義する技能は別物だが、抽象化の能力を持った人が少ない結果、
結果的に実装派が主導権を握ってしまう状況。これはオブジェクト指向開発に平等主義を
持ち込むと起こりやすい。そのため組織の役割分担を明確にし、抽象派がアーキテクトを、
優秀なプログラマがコンポーネントを、それ以外のプログラマがデベロッパとして参加させろ。

843 ：デフォルトの名無しさん：03/12/23 12:28

＞抽象化の能力を持った人が少ない
アナリストを育てようとしない企業側にも問題があるような気がする
ま、マネージャーの中にもこのあたり分かってないのが大勢だけどな

844 ：デフォルトの名無しさん：03/12/23 14:56

>平等主義を持ち込む
問題の根源はここにあるように思うんだけど。

例え「抽象化の能力を持っ」ていないとしても、
「アイツはオレより詳しいから、この辺の判断はアイツに任せよう」
という割り切りができれば、なんら問題ないはず。
（まあ、誰一人としてまともな能力を持った人間がいない、というのは論外だけど）

もちろん、「アイツはオレより詳しい」を判断する能力は必要だけど、
新しい技術が次から次へでてくる状況下で、グループで開発をするなら、
全員が同時にスペシャリストでいることは、どうしても不可能なんだから、
そういった判断はどうしても必要だと思う。

845 ：デフォルトの名無しさん：03/12/23 19:28

ここの奴らが勤めてる会社は、文章の仕様書よりUMLの仕様書のほうが重要視されてる会社ばかりなのか？
ドキュメントを書かないXPやアジャイルが話題になってるが、そんな会社は聞いたことも無いが。
設計イメージ図の統一基準よりも、日本語の仕様設計書の業界統一基準のほうがよっぽどありがたいし、金になるのにねえ。
誰か作れよ

846 ：デフォルトの名無しさん：03/12/23 20:13

>>845
>日本語の仕様設計書の業界統一基準
SLCP-JCF98 使えば。

847 ：デフォルトの名無しさん：03/12/23 20:51

>>845
UMLが重要視されています。

常に新しいもの・開発手法を採用することになり、ほとんどのメンバーがついていけずに
品質が落ちていっています。
その言い訳が「新しい案件だし」の一言でまかり通る会社です。＿|￣|○

848 ：デフォルトの名無しさん：03/12/23 21:47

>>845
＞ここの奴らが勤めてる会社は、文章の仕様書よりUMLの仕様書のほうが重要視されてる会社ばかりなのか？

どっちも書けて、必要に応じて活用できるのがいいでしょうな。

＞ドキュメントを書かないXPやアジャイルが

書かないんだっけ？ソースは？

＞設計イメージ図の統一基準よりも、日本語の仕様設計書の業界統一基準のほうがよっぽどありがたいし、金になるのにねえ。

なんだ>>825か？別に同じ事を何回も書かなくていいのに。

849 ：デフォルトの名無しさん：03/12/23 23:54

>>845そのた
スレちがいになってきてます。ここはム板ですYO！

850 ：デフォルトの名無しさん：03/12/25 22:05

Aspect Oriented ProgrammingのようなOOと直交する概念を
UMLでどう記述すればいいのか悩み中です。
いま考え付いている選択肢は次の３つです。

1.ステレオタイプを使う
2.付箋（笑）をペタペタ貼りまくる
3.UMLはOOのための図法だからOOと関係ないことを書いてはいけない

どう思いますか？

851 ：850：03/12/27 13:31

質問がアホすぎるのかな。すみません。

852 ：デフォルトの名無しさん：03/12/27 20:04

皆様 OCL(ObjectConstraint Language) って使われてますか？
私は多くの解説書でばっさり削られてるので、最近まで存在すら知らなくて……
実際の使用率・有用性などが知りたいのですが。

853 ：デフォルトの名無しさん：03/12/28 12:34

>>852
つかってない。
ノートかコードで説明すればいいんでないかという気がする。

854 ：デフォルトの名無しさん：03/12/29 02:45

>>850
『AspectJ in Action』にステレオタイプを使ってる例がちょっとあるよ。
《woven》とか《aspect》とか。

あとググッたらいろいろ出てきた。
俺はまだ読んでないけど、こんなのとか↓

『An UML-based Aspect-Oriented Design Notation For AspectJ』
http://dawis.informatik.uni-essen.de/site/publications/papers/aop/StHaUn_AspectOrientedDesignNotation_AOSD_2002.pdf

855 ：850：03/12/30 00:50

>>854
ありがとう。
うーん、自分もステレオタイプを選択肢にあげていたけど、
ステレオタイプを使うってのは、何かが間違ってるね…。
結局自分では、「規格で定義されたUML」の範囲では扱えない、
という結論に達したよ。

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

AOP自体は余り詳しくないけど、アスペクト指向の中には①別のアスペクトに
属する事柄を別けて扱うって事と、②同じアスペクトに属する事柄をまとめて
扱うって事があると思う。

で前者①については、例えば{aspect=StatePattern}のようにtagged valueを
使ってどのアスペクトに属するか要素ごとに追記するやり方や、アスペクト
ごとにダイアグラムを描き分けるやり方が考えられる。

後者②についてはパラメタライズド・コラボレーションでパターンを
表現するのと同じやり方が使えると思う。

普通のUMLで、割に自然とAOPは導入できると思うんだけど、どうでしょう。

857 ：デフォルトの名無しさん：04/01/02 08:40

後者（パラメタライズド・コラボレーション）はそれでも構わないと思う。

だが前者は全然ダメ。
実装上で各要素がどのアスペクトに影響されるかなんていちいち書かないのに
（そのためにアスペクトを使ってるのに）、図の上でそれを対象要素に個別に
描き足すことになるのって、おかしいよ。

それに、アスペクトの中身を記述するための道具立てが今のUMLには足りない。

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

>>857
UMLで描けないアスペクトの中身って、例えば何？

859 ：デフォルトの名無しさん：04/01/02 16:03

>>858
1.「アスペクト」そのものを表現するモデリング要素
　（AspectJでいうと、aspect）
2.そのアスペクトが影響を与える「対象」そのものを表現するモデリング要素
　（AspectJでいうと、pointcutやそれを構成するjoin point）
3.その対象にアスペクトが与える「影響」を表現するモデリング要素
　（AspectJでいうと、advice）
これが全部、UMLにはないでしょ。これが全部モデリング要素として表現されて、
「1は3の集約になっていて3はそれぞれ2への一方通行の関連を持つ」のような
記述を自然に描きたい。

860 ：デフォルトの名無しさん：04/01/02 16:03

>>858
リスペクト

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

海外掲示板用オフラインリーダーを作るスレ
http://pc2.2ch.net/test/read.cgi/tech/1072883528/

海外でよく使われていうる掲示板スクリプト
専用のオフラインリーダー作って下さい。

必要な条件はID、PASSを管理できること、
OpenJaneみたいな三面型の見た目。
簡単にローカライズできるように言語ファイルを採用

862 ：856：04/01/03 00:39

>>857
＞実装上で各要素がどのアスペクトに影響されるかなんていちいち書かないのに
＞（そのためにアスペクトを使ってるのに）、図の上でそれを対象要素に個別に
＞描き足すことになるのって、おかしいよ。

tagged valueについてのレスですよね。weavingの結果としてのモデルを
表現するとき、どの要素がどのアスペクトに属するか解るようにしておいた
方がいいでしょう。そのつもりがなければ>>856でtagged valueの直後に
書いたように、別のダイアグラムに書けば良いし。

863 ：856：04/01/03 00:48

>>859
＞1.「アスペクト」そのものを表現するモデリング要素
＞2.そのアスペクトが影響を与える「対象」そのものを表現するモデリング要素
＞3.その対象にアスペクトが与える「影響」を表現するモデリング要素

「対象」も「影響」も、結局はクラスの要素や関連、オブジェクトの協調に
還元されるのでは？「アスペクト」に着目してダイアグラムを切り出した上で、
あとは普通にUMLを描くだけだと思うんだけど。

＞「1は3の集約になっていて3はそれぞれ2への一方通行の関連を持つ」のような
＞記述を自然に描きたい。

まずアスペクトをそのように記述する事が正しいかよく分からない。例えば、
あるアスペクトに固有のクラスやインスタンス、或いはクラスの継承関係の
表現もこの記述に含まれます？

それと集約とか関連などの言い方をみると、結局クラスのようにアスペクトを
扱いたいように読めてしまうんだけど、だとしたら、クラスアイコンを拡張して
区画を追加したり、それこそステレオタイプを使えばいいのではと思う。

864 ：856：04/01/03 00:51

>>862-863で書いたことは、例えばステートチャート図が無くても、必ずしも
システムの動的側面を記述できなくなる訳じゃないってのと同じ話ね。

つまり状態遷移そのものを表現したいときに、ステートチャートが無いと
不便なのと同程度には、アスペクトに関連する道具立てが無い事が不便だ
とは思う。

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

憂鬱なプログラマのためのオブジェクト指向開発講座を読んでいます。
第５章の関連まで読んで疑問に思ったことを質問させてください。
クラスが別のクラスを属性に持つことはほとんどない、とあり、
必要があれば関連のクラスを作る、とあります。
でも実際のサンプルプログラムでは、他のクラスのポインタを持っていて、
関連クラスが別のクラスを作成して、そのポインタに設定する、というものでした。
他のクラスのポインタでも結局は別のクラスを属性に持っていることにならないのでしょうか？

866 ：デフォルトの名無しさん：04/01/03 19:36

>>865
スレ違いなので一言ですます。
おまえの読み方が間違ってる。
これ以上は他のスレに逝け。

867 ：865：04/01/03 20:36

>>866
読んだことないか理解していないくせに何をほざいている。
市ね

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

UMLの話しちゃう。

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

送り仮名のせいで微妙な事に、、
「UMLの話しとちゃう(違う)。」だ

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

>865
答えは5章に書いてあるぜ。日本語が読めるならわかるはずだ。
日本語読めないからこんなスレ違いの質問してるのだろうけど

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

>>867
ダウト！

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

Visioを使ってUML図を書く方法を説明しているウェブとかないですか？
それっぼく図を作ることはできるけど、正しい使い方がよくわかんないんだよ。

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

>>872
VisioのUMLは死んでるからうやめとけ。バグばっか。

874 ：デフォルトの名無しさん：04/01/06 09:57

やっぱり死んでいるのか。
M$が後付しただけに。
しかもUML以外の目的でも使えるようになっている
ただの便利ツールと化しているし。

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

>>874
> ただの便利ツールと化しているし。
化してるってもともと便利ツールのほうが本職ですよ。ダンナ。
UMLツールとして本格的に使うほうが無理がある。
ちょろっと書くには便利。

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

オライリーの「入門 UML」ってどんな感じでしょうか？
初学者向けにも良いですか？

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

>876
UML2.0じゃないのがなあ・・・
今更1.2とかやってもねえ。
中身の良し悪しは知らん。

878 ：デフォルトの名無しさん：04/01/08 05:38

>>876,877

ぱっと見た感じわかりやすそう。
でも877に禿同。敢えて買う意味なしと思われ。

879 ：デフォルトの名無しさん：04/01/08 14:56

>>877-878
なるほど、2.0 じゃないんですか。ほかの本を当たってみます。

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

>>879

UML2.0の本は皆無という罠

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

昔ちょっと勉強したUML。今は全く使ってないけど、
いくつか質問させてください。

私の周りでは全く普及しないけど、みなさんの周りでは普及してますか？
これから、普及してくと思いますか？あるいは消えて無くなりますか？

UMLとはクラス図のことだという印象があるのだけど、クラス図の他もつかってますか？

UMLをソフト開発でなくて、なにげないメモをとるのにも使っている人いますか？

UMLの表現力なんですが、どんな概念でもこれで記述できるんでしょうか？

厨な質問スマソ

882 ：デフォルトの名無しさん：04/01/10 11:17

>>881
> UMLとはクラス図のことだという印象があるのだけど、クラス図の他もつかってますか？
シーケンス図とステートチャートも使ってる。

> UMLの表現力なんですが、どんな概念でもこれで記述できるんでしょうか？
いや、全然。何でも記述できるのはソースコードしかないが、それだと粒度が細かすぎて
見通しが悪いから、OO がらみんの本質部分だけ抽出したのが UML でしょ。

細かいアルゴリズムとかは記述できないし、非 OO 的な要素 (AOP など) も書けない。
でも、それで良いんだよ。

883 ：U ◆CZtFsGiu0c ：04/01/10 16:30

>>881
>私の周りでは全く普及しないけど、みなさんの周りでは普及してますか？

うちの会社のエンジニアでUMLの読み書きができない社員はいません。
また、協力会社にお願いする場合でもUMLが読めるのは最低条件です。

>これから、普及してくと思いますか？あるいは消えて無くなりますか？

普及するかどうかはわからんですね。でも、UMLがあろうがなかろうがモデリングは
必要ですから統一された仕様があったほうが便利でしょう。だから変化することはある
でしょうが、短いスパンで考えれば消えはしないと思います。

>UMLとはクラス図のことだという印象があるのだけど、クラス図の他もつかってますか？

クラス図はドメインモデルはともかく、実装レベルではあまり重視していません。
それよりも相互作用図、状態遷移図のほうが重要です。

>UMLをソフト開発でなくて、なにげないメモをとるのにも使っている人いますか？

いいえ。質問の意図がよくわからないけど。

>UMLの表現力なんですが、どんな概念でもこれで記述できるんでしょうか？

んなわきゃない。

884 ：881：04/01/10 18:24

シーケンス図と状態遷移図。なるほど。
そういえば、回路設計のときにも状態遷移図よく書きますね。
状態遷移図から、HDLコードを生成するツールとかもあった。

>>UMLをソフト開発でなくて、なにげないメモをとるのにも使っている人いますか？
>いいえ。質問の意図がよくわからないけど。

実は最近、メモ術みたいなものをいろいろ模索してるんだけど、
マインドマップって知ってますか？検索してみて。
これはメモの方法なんですが、ようはキーワードを書いてまるでかこんだやつを
線で結んでいくメモの書き方です。
これをUMLで書いたらもっも便利じゃないかと思ったわけです。
で、それを日常のメモでやってる人いないかな？と思ったのです。
そんな人いない？

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

JUDE竹と、VISIOをUMLツール比べてみたんだけども、JUDE竹の方が取っ掛かりがいい。
VISIOは今ひとつ動きが良く分からなかった。
まだ勉強中なので、これからまた覚えていくと見方が変わっていくんだろうか。。。
VISIOな方、使い勝手はどうですか？

886 ：885：04/01/12 23:48

JUDE竹なのですが、ユースケースにシナリオってどうやって書けばいいんですか。。
EAだと書けたんですが。。

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

JUDEを2年ぶりくらいに触ったが、かなり使いやすくなってるね。
当面の仕事ではこれを使おうと思ってる。

MDAを業務アプリとして実戦投入できるのははるか先だしな。
UML2.0も今はお勉強程度しかできない。
(この方向に向かうことは確実なんだけど)

>>881
UMLを読み書きできないのは、恥ずかしいことだと認識しておいたほうがいいよ。

888 ：885：04/01/13 22:07

結局EA買っちゃったYO!
まだユースケースしか試してないけど、試用版のメニューが英語ってのに耐えられなくて。。。

889 ：デフォルトの名無しさん：04/01/14 05:27

>>885

いまさらながら、かもしれないが

JudeやEAはUMLのためのモデリングツール
VISIOは絵を描くためのツール

UMLを描くために使うなら、JudeやEAのほうがよいかと。

890 ：885：04/01/14 20:34

>>889
ありがとん。
今EA正規版インスコ中です。
レスのおかげで安心して使えます。

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

やはりコードと対応していないクラス図が気になりますが
実務でしている人、気になりませんか
それとシーケンとクラス図の対応気になりませんか

892 ：デフォルトの名無しさん：04/01/14 22:39

889ですが、

今何気なくEAのページ見ていたら
おんなじこと書いてあるｼﾞｬﾝ

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

>>891
コードとUMLダイアグラムの乖離はまったく気にしてません。

UMLを描くのは、かなり粒度の粗いスケッチとしてか、
厳密なシーケンス指定をするときくらい。
だから、アーキテクチャや概要の設計時には死ぬほど描きます。

自分がUML描画ツールを選ぶときの視点は「詳細を省略した図が描けるかどうか」です。
UMLからコード生成できるくらい変に高機能だと、
気にしたくない詳細まで設定する必要が出てきて使いにくい。

以前にVisio2000のUMLステンシルを試してみたときは、
メッセージアローひとつ引くにも過剰な厳密さが求められて萎えた。

894 ：実装できないモデルはスケッチにすぎない：04/01/14 23:18

MDAとかExecutable UMLとかだと?

895 ：デフォルトの名無しさん：04/01/15 01:35

>881

> 私の周りでは全く普及しないけど、みなさんの周りでは普及してますか？
> これから、普及してくと思いますか？あるいは消えて無くなりますか？

OO一筋十年の俺としては、普及してもらわないと困ります。

> UMLとはクラス図のことだという印象があるのだけど、クラス図の他もつかってますか？

アーキテクチャ設計の時にはパッケージ図を使いますね。大まかな責任分担を決めるため。
コンポーネント図はあんまり使わないな。やっぱ、Visioとかのほうがわかりやすいんで。
シーケンス図はめったに書きません。客が「書け！」って言ったときぐらい。そんな時は、リバースで済ませます。
当然、コラボレーション図も書いたこと無い。
状態遷移図は、場合によりけりですね。自然言語で表現するのが難しくなったら、状態遷移図を書き始めます。そうしないと、自分がわからなくなるもんで。
アクティビティ図は、意外に使えますよ。シンプルなんで、ユーザに説明しやすいんです。要件定義の時には、アクティビティ図を見せて説明する事が多いです。

> UMLをソフト開発でなくて、なにげないメモをとるのにも使っている人いますか？

ソフト開発以外って事ですよね？
たまぁに、クラス図使うかなぁ。

> UMLの表現力なんですが、どんな概念でもこれで記述できるんでしょうか？

note使えばなんでもありかも（ｗ

896 ：893：04/01/15 02:05

>>894
現状の普及帯のツールでは
実装とシームレスにつながっているモデルは作れないから。
作れるのかもしれないが、残念ながらそのためのノウハウをまだ持っていない。

MDAの方向に進むのは確実だと考えているけど、
いま使えるわけではない。

ツールを無理に適用するためにGenerationGapなりの
パターンに沿ってモデルを描くのも本末転倒だと思う。

897 ：デフォルトの名無しさん：04/01/15 15:34

メーカのページとか、
日経の記事とか読むと、すぐにでも使えるような
ことが書いてあるから困るんだよな >>MDA

898 ：デフォルトの名無しさん：04/01/15 17:21

>>893の使い方に激しく同意

899 ：デフォルトの名無しさん：04/01/17 01:34

もう全然勢いなくなったなUMLは
このスレではさも普及してるようにみせかけてる零細下請けのSEどもが必死だけど（藁
大手数社出向したけど、もうどこも使ってなかったよん

900 ：デフォルトの名無しさん：04/01/17 01:46

その大手がどこか知らないけど、
俺が仕事したところは皆使ってるぞ。
顧客から指定してくるところも多い。

901 ：デフォルトの名無しさん：04/01/17 13:09

基本的なことなんですが、クラス図って静的な構造だけを記述するんですよね
動的なオブジェクトは描かずに、多重度だけで表現するんですよね？

902 ：デフォルトの名無しさん：04/01/17 14:11

>>901
そう。

複数のオブジェクト間の協調動作はシーケンス図とコラボレーション図、
単一オブジェクトの振る舞いはステートチャートで書くことになる。

903 ：U ◆CZtFsGiu0c ：04/01/17 16:07

>>901
一応、システムのある瞬間のオブジェクトの関係を示すためにオブジェクト図を使う
ことができます。ただし使ってるのを見たことないです。

904 ：デフォルトの名無しさん：04/01/18 04:34

リスト構造とか、データ構造を動的に持つような場合、
オブジェクト図を使わないと、追いきれないように思うんだけど。

905 ：885：04/01/18 11:00

なんかEAのチュートリアルをやっていくうちに、段段EAが良く思えてきた。
単なるUMLツールじゃなくて、プロジェクトの管理なんかもできそうで、
プロジェクト管理とUMLの連携が良さそうな気配。。

906 ：885：04/01/18 18:00

UMLの試験受けようと思ったら、すげー高いよ(;;
前のブロンズとかだったら、確かロハだったはずなのに。。
個人じゃ厳しすぎる。。

907 ：デフォルトの名無しさん：04/01/19 05:58

ソフトウェア業界以外でUMLを使ってる例ってあるの？
プロセス記述っていってもソフトウェア開発のそれ以外に
実例があるのかと。

908 ：デフォルトの名無しさん：04/01/19 07:02

回路設計とかには使われる（使おうとする動きがある）
って話は聞いたことがあるけど。

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

ビジネスプロセスのモデリングに使おうとしている人たちは居る

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

今更気づいたけど、ここってスレ名に反してUMLの勉強にあんまりなってない気がする。。
UMLって実はマイナーなの？

911 ：デフォルトの名無しさん：04/01/21 00:09

UML自体の扱う問題の範囲が広いのと、
参加者のレベルがまちまちなせいで、話が発散してるように思われ。

912 ：デフォルトの名無しさん：04/01/21 00:50

何しろ物がビジュアルだから文字のやりとりでは話が遠い。

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

OMGのサイトからUML1.5(03-03-01)っていうのを落として来ました。
UMLを使ってどうモデリングするかっていう実務の話は別として、
表記法を読み書きできるようになるには、これだけ読めば十分ですか？
ヒキコモリなので本を買うお金がありません。

914 ：マーチン・ファウラー信者：04/01/21 16:13

>913

仕様書ですか？

分量が多すぎる気がします。業務で使う上では、そこまで細かくは書きません。
相手が読めなければ意味がないですしね。

本当は、「UMLモデリングのエッセンス」（翔泳社 ; ISBN: 4881358642）がお勧めなんですが。
\2,400はつらいですか。

915 ：UML初心者：04/01/22 09:19

はじめまして。UML初心者です。
これから業務でUMLを使うので、勉強しなければならないのですが、
いいテキストや参考書ってありませんか？
昨日、本屋に行っていろいろ見て見たんですけど、どれがいいのか
いまいち判断がつきません。

今回のプロジェクトでは開発はJAVAで行うので、JAVAと一緒にUMLを
学ぶといった趣旨の本もあったのですが、どうでしょうか？

状況としては私は開発は行わなく、基本設計や詳細設計を担当するので
JAVAのソースが読めればいいといわれているのですが。
ってか今まで、開発一本(SAP R/3 ABAP)で来たので上流工程を担当する
のは初めてです。JAVAに関してもちょっとかじったことがあるくらいで、
具体的な文法はわかりませんが、オブジェクト指向に関してはある程度
理解しているといったレベルです。

一応今は日経コンピュータに連載されたいた
「マネジャのためのUML入門」を読んで勉強しています。

よきアドバイスをお願いします。
よろしくお願いします。

916 ：U ◆CZtFsGiu0c ：04/01/22 12:53

>>911
UMLの表記法については
http://www.amazon.co.jp/exec/obidos/ASIN/4881358642

UMLを使った分析・設計なら
http://www.amazon.co.jp/exec/obidos/ASIN/4894710773
(UMLの表記法については少し古いかも)

ユースケースを作成するのなら
http://www.amazon.co.jp/exec/obidos/ASIN/4798101273

あたりをお勧めします。

917 ：ヒキコモリ：04/01/22 16:09

>>914
ありがとうございます。UML1.5とは仕様書のことです。
オージス総研のサイトにいろいろと分り易い解説をした
ドキュメントがあるのでそれらと見比べながらしばらく、
仕様書にかじりついてみようかと思います。

オージスのサイトにはアナリシスパターンの分り易い死霊もありました。

ところでmeta-metamodelとmetamodelの違いってなんでしょうか？
metamodelが自身を定義できるならmeta-metamodelはいらなくないですか？

918 ：UML初心者：04/01/22 16:38

>>916
ありがとうございました。
ってこれって>>911となってますが、私に対するレスですよね？＾＾；
リンク先の書籍に関するレビューをみて、とりあえずUMLの表記法に
関する本を買ってみようと思います。ただ、まったくの初心者にはちょっと・・
というレビューもありましたので、まず、「はじめて学ぶUML」という本
を買って、その次にリンク先の本を買おうと思います。

とても参考になりました。
ありがとうございました。

919 ：デフォルトの名無しさん：04/01/22 17:16

DAO や DTO ってentity でしょうか、 boundary でしょうか。

920 ：U ◆CZtFsGiu0c ：04/01/22 19:23

>>919
entity、boundaryってロバストネス図(分析クラス)で使うステレオタイプだよね。
ロバストネス図のレベルでDAOやDTOなんて概念は出てこないはずだよ。

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

>>920
うーん。 DAO や DTO という捕らえ方が適切でないのかもしれませんが、
外部システムとのやりとりに仕様するデータのようなものは、
ロバストネス図の段階でもでてきますよね？
例えば、インターフェースファイルとか、SOAP にのせるデータとか。
そういったものは、どう表現すべきかということです。

922 ：910：04/01/22 23:13

>>911
>>912
そういう事なんですか。。失礼しました。
まったり進行でも悪くはないんですけどもね。。

923 ：U ◆CZtFsGiu0c ：04/01/23 15:20

>>920
(外部システムがアクタとして)アクタとのデータのやり取りに何を使うか、
というのはロバストネス図では意識しないよ。あくまでユースケースを実現
するためにシステム内部でどのようなデータを扱うのか、というのを考えれば
いい。そのようなデータはentityクラスになるよね。

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

>(外部システムがアクタとして)アクタとのデータのやり取りに何を使うか、
>というのはロバストネス図では意識しないよ。
なるほど、であれば、DAO や DTO はおよびではないですね。

>あくまでユースケースを実現
>するためにシステム内部でどのようなデータを扱うのか、というのを考えれば
>いい。そのようなデータはentityクラスになるよね。
なるほど。そう考えれば、名詞のオブジェクト化は全部できますね。
ただ、そうすると、その entity と、アクターの関連の表現は、
直接関連でつないでしまっていいものなんでしょうか？
アクターと対話するのは boundary だという理解なのでなんか違和感があるのですが。

925 ：U ◆CZtFsGiu0c ：04/01/23 18:43

>>924
どういう図を想像しているのかわかりませんが、もちろんアクタはboundary
オブジェクトとしかやりとりできませんし、entityオブジェクトはcontrol
オブジェクトからしか扱えません。

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

>>924

そうすると、人間以外のアクターと、
オブジェクトの関係を表現する方法がわからなくなってしまうのですが。

927 ：U ◆CZtFsGiu0c ：04/01/23 23:25

>>924
だから人間だろうとなかろうと、アクタと関係を持つのはboundaryオブジェクトです。
もし外部システムとのやりとりがあるなら、そのシステムとのインタフェースをboundary
オブジェクトで表現します。

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

>>927
なるほど、その限定は存在するわけですね。
それで、例えば、インターフェースファイルを介して、
外部システムとデータをやり取りするような場合、
これまでのお話だと、インタフェースファイルに対応する
データをentiryとするけれど、
ロバストネス図の段階ではインタフェースファイル自体に
ついては考えてはいけないんでしたよね？
そうすると、インタフェースファイルで連携する外部システムとの
間の　boundary　オブジェクトとしては、何を置いたらいいのでしょう？

929 ：デフォルトの名無しさん：04/01/24 00:52

なんか知らないけどスレのレベルが上がってきていい感じ。

930 ：デフォルトの名無しさん：04/01/24 01:12

>>927

>ユースケースを作成するのなら
>http://www.amazon.co.jp/exec/obidos/ASIN/4798101273

ロバネスト図のこともかいてある？

931 ：U ◆CZtFsGiu0c ：04/01/24 02:47

>>928
えーと、ロバストネス図っていうのはそんなに深く考えて書くようなものではないです。
このユースケースを実現するとしたら、大体システムにはこんな要素が必要だよね、
ってことを割り出すためのもの。ロバストネス図を比較的重視するICONIXアプローチ
でも、ロバストネス図は設計クラス図/相互作用図書いたら捨ててもいい、って
言ってるくらいのものです。

だから、

>そうすると、インタフェースファイルで連携する外部システムとの
間の　boundary　オブジェクトとしては、何を置いたらいいのでしょう？

「外部システムインタフェース」ってな感じです:-)
そのさいに、「インタフェースファイル」なんていう具体的なものは考慮しません。

そもそもロバストネス図書く必要あるんですか?

932 ：デフォルトの名無しさん：04/01/24 06:25

>>931
>えーと、ロバストネス図っていうのはそんなに深く考えて書くようなものではないです。
～
>そのさいに、「インタフェースファイル」なんていう具体的なものは考慮しません。

システムを０から自分だけで設計するのならば、それでいいだろうというのは
わかります。
しかし、、実際の一般的な開発業務では、要件の段階で、
「これこれのファイルを出してくれ」という要求になっているので、
それは、「考慮しなくていい」ではなく、逆に、
要件から見出されるオブジェクトについて、この段階で取り上げていいものといけないものを
「考慮して」、「隠す」「抽象的なものに置き換える」
ということを「しなければならない」ということになると思うのですが。

分析段階の作業として、そういった分別が必要になる、
という理解でいいでしょうか？

>そもそもロバストネス図書く必要あるんですか?

逆にいうと、その必要の有無はどうやって判断すればいいのでしょう？
現状、ユースケースからオブジェクトを抽出して、
分析レベルのクラス図、相互作用図を作ろうとした場合、
ロバストネス図として書く以外の方法が思い当たらないのですが、
勉強不足でしょうか？

933 ：U ◆CZtFsGiu0c ：04/01/24 11:06

>>932
インタフェースファイル、というのは要するに外部システムとのデータのやり取りをする
ための手段ですよね。でもそれはファイル渡しだからであって、たとえばRPCでやり取り
するのであれば、メソッドのパラメータと同列に扱うべきものです。

ロバストネス図を書くのであれば、そのインタフェースファイルにどんな情報を載せるのか
を考えて、それをentityオブジェクトとして定義します。外部システムとのやり取りは、
controlオブジェクトがboundaryオブジェクトを介して行うように定義します。

934 ：デフォルトの名無しさん：04/01/24 12:43

>>933
>するのであれば、メソッドのパラメータと同列に扱うべきものです。
ああ、なるほど、ようやくイメージがつかめました。

稚拙な質問に根気よく付き合ってくださってありがとうございました。
これで、作業を先に進められそうです。

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

>>917

> ところでmeta-metamodelとmetamodelの違いってなんでしょうか？
> metamodelが自身を定義できるならmeta-metamodelはいらなくないですか？

遅レスですが...
メタモデル、メタメタモデルの関係を理解するためには、
ＭＯＦのメタレベルを知っていると良いんじゃない。
メタレベルは次のように定義されている。

M3 = MOF　（ＵＭＬ構成要素を定義）
M2 = Class, Attribute, State, Activity....etc　（ＵＭＬの構成要素）
M1 = Class "Customer", Class "Account" （実際のＵＭＬ図）
M0 = Smith : Customer, 2010: Account ...etc (M1で定義されたもののインスタンス)

となっていて、
metamodel = M2
meta-metamodel = M3
となる。

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

ＵＭＬ2.0のSuperStructureの仕様を呼んでいたら、
Acitivityの章に、
エラー処理のnotationが定義されていたね。

2.0になって、より実装に近いレベルまでモデル図を
書くことができるようになるんだなぁ...と感じました。

2月にUML2.0に対応したＥＡがリリースされるのだそうだ。
どのようなものになるのか非常に楽しみです！

937 ：デフォルトの名無しさん：04/01/27 05:10

>>936 に関連して

他にUML2.0に対応したツール使っているひといますか？

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

つーかUML2.0は正式にリリースされたのか？
ネット久しぶりでそのへんあいまい。

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

>>938

予定では2004年4月のはず

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

サンクスです。
OCLや制約言語やパッケージテンプレートがどうなってるか楽しみです。

話し転じて、
このスレでOMGの資格やその他のUML資格に挑戦された人いますか？
私的には試験問題はなめてるとしか思えない。

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

ブロンズ取りました。
その後、試験制度がごろっと変わったので現在様子見。

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

過去スレ見ると、シルバーは結構落ちたヤツもいたみたいだが。

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

phpでオブジェクト指向プログラミングがしたくて
とりあえずクラス図を書いてみてるんですが
なかなかしっくりこないです。
visitorが紙にメッセージを書いてそれを掲示板に貼る
というのをイメージしてます
なにかコメントあればよろしくおねがいします

http://uploader.org/normal/data/up1285.png

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

>>943
ステートチャート図も見せてください。

945 ：デフォルトの名無しさん：04/02/07 01:27

http://uploader.org/normal/data/up1296.png

ステートチャート図かいてないです
すみません
これから勉強します

これシーケンス図です。

946 ：デフォルトの名無しさん：04/02/07 12:41

>>945
visitorがmessageを作成すると、messageが自動的にnameとcommentをwriteする。

特に意味もなく、visitorがregistするとbbsはPaste_msgする。という解釈でよろしいか？

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

bbsクラスのステートチャート図かいてみました。

http://www.uploader.org/normal/data/up1301.png

おながいします。

948 ：デフォルトの名無しさん：04/02/07 13:11

>>946
レスどうもです。

visitor : 人
message : 紙
bbs : 掲示板

です。

visitorが書く内容を考えてそれを紙に伝えます。
すると紙はその内容を自分（紙）にかきます。
次にvisitorはその書かれた紙を掲示板に貼ってと掲示板に頼みます。
掲示板はその紙を自分（掲示板）にはります。

ってかんじです。
@ITでクラスを擬人化してとらえると(･∀･)ｲｲ!!って書いてたので
そうしてみました。
でもなんか苦しい

949 ：デフォルトの名無しさん：04/02/07 17:38

なんだかUMTP（だったっけな）の資格本が出てましたが、
あの内容で資格っつわれてもな・・・困るよ。

>>948
やっぱダイヤグラムで表現するとわかり易いですね。
私的には、クラス図、シーケンス図、ステートチャート図、アクティビティ図
だけでほぼ全てを表現可能だと思います。もちろんユースケース図がちゃんとし
ていることが前提なんですけどね。
（オブジェクト図とかっていらん気がする・・・）

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

>>949

UMLが読める
　　↓
UMLで設計できる

の間には、おおきなギャップがあるからね。

下位の資格は間口を広げて、資格およびUML の認知度を上げる、
ってのが目的なんだろうと思う。

UML はコミニュケーション手段なんだから、今、重要なのは「UMLが読める」人が増えることで、
そのためには、そのレベルの人を認定する資格があるってのは有意義だと思うけど。

951 ：デフォルトの名無しさん：04/02/07 23:43

>>950
同感
伝統芸能みたいなもので、理解できる人間が一定数存在してこそ供給する方も存在できる訳で(w

読むだけなら難しいことないんだけど、それでも、
「オレは読めるんだよ」
ってのが優越感につながる仕組みってのは普及のためにはあっていいと思う。

952 ：デフォルトの名無しさん：04/02/08 04:49

なるほど。納得です。

上でえらそうに書きましたが、会社ではこの資格を強制的に
取得させるらしいです。とるのはいいですが（会社のお金だから）
役に立つのだろうか？
950さんのおっしゃるとおり設計と読むのはえらい違うんですよね。
資格もってるだけでDQNが（ウチ多いんすよ）が設計とかしたら
えらいことになりそうで怖い。

話し転じて、
MDAって実現するんですかね？
メラーの本読んだがどうも絵に描いたもちの雰囲気が・・・。
OCLでがちがちに固めるなら、コーディングと大して変わらんような気がする・・・。

953 ：デフォルトの名無しさん：04/02/08 05:10

>>952

MDAについては同感

ビジュアルプログラミングと
プログラムビジュアライゼーション(プログラムの可視化)の融合だと思うけど
結局のところ、OCLのようなものでコーディングしないといけないのでは？

と思う

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

>ビジュアルプログラミングと
>プログラムビジュアライゼーション(プログラムの可視化)の融合だと思うけど

MDAの理念とは全然違うと思うYO

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

もし、UMLがクライアントまで浸透したら便利になるんだろうな。

956 ：ニュージーランド漁夫：04/02/09 08:46

　 Λ＿Λ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　>>960さん次スレたてお願いします。
　（　　　　）　＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜｜　|
　（_＿）＿）

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

　 Λ＿Λ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　>>956さんageないでください。
　（　　　　）　＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜｜　|
　（_＿）＿）

958 ：デフォルトの名無しさん：04/02/10 00:20

>>955
UML が十分に浸透しないうちに MDA がプッシュされ始めているのが
ちょっとまずいんじゃないかと思ってる。
UML を小難しい、開発屋だけが分かる代物という印象にはしたくない。

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

>955
結構判るもんだよ。
UML1.0が出たばっかりのころに、クライアントに教えたよ。
アクティビティ図だったら、エンドユーザでも理解してくれる。

960 ：デフォルトの名無しさん：04/02/11 00:59

アクティビティはフローチャートと変わらん罠。
でも分岐の書き方とかは遥かにスマートなんで、
フローチャートはさっさと駆逐されてホスィ。

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

フローチャートは詰め込みすぎなように見える。

アクティビティ図で順序、ステートチャート図で状態、
オブジェクト図で構成オブジェクト数の把握、と色々な
視点で考えることが出来るから便利だと思う。

あくまで私的な考えだが。

962 ：デフォルトの名無しさん：04/02/11 08:46

次スレ立てたYO!
ttp://pc2.2ch.net/test/read.cgi/tech/1076446411/

963 ：デフォルトの名無しさん：04/02/11 12:49

情報処理試験って未だにフローチャートなんだっけ？

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

フローチャートは構造化以前のツールなので、今からみれば詰め込みすぎな
のは当たり前だね。

構造化プログラミング、構造化設計でフローチャートは駆逐されたはずなん
だが… (25年前だ)

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

むしろ構造化プログラミングでもUMLが有効だってことを
世間にアピールする方がよいかもしれませんぬ。

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

構造化プログラミングでは、その手の絵は不要。
プログラミング(詳細レベル)の範疇なんでUMLは不要だし、
スパゲッティにもならないからフローチャートも不要。

967 ：デフォルトの名無しさん：04/02/12 13:27

これってどうなんでしょう？

UMLモデリング教科書レベル1
ttp://www.cbook24.com/bm_detail.asp?sku=4798105074

UML2.0なんでしょうか・・・・

968 ：967：04/02/12 13:34

自己レス
OMG認定とは別なのね。
ttp://www.umlcert.org/ocup/index.html

UMTP
ttp://www.umtp-japan.org/examination/index.html

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

>>968
「コラボレーション図」という言葉があれば
UML2.0ではないと思って間違いはなさそうだと思う

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

>969
UML2,0にはないぞ。
コミュニケーション図
ステートマシン図

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

うめろー

972 ：デフォルトの名無しさん：04/02/16 01:34

新スレ立てるの早すぎのような気も…埋め立てついでに質問。
社内研修でUML教えるんだけど、そういう目的の時はUMLは手書きの方がいい？
JudeなどのUMLツールを使わせた方がいい？

ツール使わせると試行錯誤が楽になって受講者に良さそうなんだけど、
ツールの使い方の方ばかりに注意が行ってしまって、
肝心のUMLとそれを使った分析設計がなおざりになりそう。

外部の研修受けに行ったときは紙に手書きだった。
紙だと添削がしやすくていいかも。

973 ：デフォルトの名無しさん：04/02/16 02:07

>>972
おれは人に教えたことなんかないけど、紙のほうがいいと思う。
紙に鉛筆のほうが制約がない分、むしろ試行錯誤しやすいと思う。

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

>972
ツールだと、よほど高価なものを使わないと、ツールの制約にはまりそうですね。

975 ：デフォルトの名無しさん：04/02/16 06:53

>>974

具体的にはどんな制約？

976 ：U ◆CZtFsGiu0c ：04/02/16 11:49

>>972
クラス図なら模造紙にポストイットあたりがいいんじゃないでしょうか。
シーケンス図で試行錯誤するときなんかは、ツールのほうが楽だったりします
けどね。

受講者が使用するツールが決まっているのであれば、ツールのトレーニングも
兼ねてツールを使うのもありだと思います。

977 ：972：04/02/17 10:58

ご意見感謝です。>>973-976
紙の方がいいという意見が多いね。

ツールの制約とは違うかもしれないけど、Visio2000を使ったときに
うるさい警告でクラス図が真っ赤になった時はうんざりした。
「正しい」図をかけ、という意図はわかるんだけど、正直うるさい。

>>976
ポストイットよさそうですね。クラスアイコンの表記に使うと移動が楽になりそうです。

受講者が使うツールは多分決まってないので、
とりあえず紙に手書きですることにします。

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

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

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

UMTPとOMG認定と、
とりあえず新入社員教育の目標につかうのは、
どっちがいいでしょか？

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

>>979

新人教育の場合には、UMTPはつらいんでないの？
モデリングの技術は実際に業務で使いながら覚えそうなもんだし。
ただ、OMGのほうはUML2.0なんだよな...

とりあえず、ある程度の文法を覚えたかどうかレベルのものが
あれば、いいんだけどね。昔のブロンズのような。

それとも、UMTPの一番下ってブロンズと同等なのか？

(あんまり答えになってないっすね)

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

>>980

御意見ありがとう。
OMGが2.0というのすら知りませんでした。

L1-T1だけなら、すごく大雑把な概要はわかりそうなので、
これでいいかなと考えておりまする。
OMGの半分の費用ですむし。

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

>>981

確かに費用は半分で済むが、(履歴書などに書けるという意味での)
資格にするためには、結局2つ受験しないといけない

目安や目標として使う分にはいいが、資格にはならないので
そのところをどうするかってのがあるかも
（資格にならない費用を認めるかどうか）

あと、UMTPのほうが比較的本屋に参考書が並んでいる気がする点は
いいとおもう

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

つまり初心者は当分の間、UML1.5で勉強していればいいってことですね。