ログイン
検索
メインメニュー
開発者ブログ
ChangeVisionメンバーズ分布マップ
フォーラム一覧   -   トピック一覧
   astah*の使い方
     クラス図:関連クラス名と関連名を別々に設定する方法
投稿するにはまず登録を

スレッド表示 | 新しいものから 前のトピック | 次のトピック | 下へ
投稿者 トピック
koba
投稿日時: 2008-4-30 11:13
新米
登録日: 2008-3-27
居住地:
投稿: 8
クラス図:関連クラス名と関連名を別々に設定する方法
JUDE Professionalでは、関連クラス名と関連名は
同一のものになるようですが、別々に設定する方法が
ありましたらお教えください。

分析モデルを作成する際に、両者が別設定できると、
より自然なモデルが記述できる場合があります。

たとえば、以下の様な場合です([]はクラス、---は関連です)

   注文する|>
[顧客]----------[商品]
     ・
     ・
    [注文]

ほかにも、"The Object Primer"p.238で、
関連名を"enrolled in"とし、
関連クラスは"Enrollment"とするなどがあります。
joba
投稿日時: 2008-4-30 15:11
開発者
登録日: 2006-4-27
居住地: Fukui
投稿: 597
Re: クラス図:関連クラス名と関連名を別々に設定する方法
kobaさん、こんにちは。

ご質問、ありがとうございます。

引用:
JUDE Professionalでは、関連クラス名と関連名は同一のものになるようですが、別々に設定する方法がありましたらお教えください。
ご希望に添えず申し訳ありませんが、現時点ではございません。

引用:
分析モデルを作成する際に、両者が別設定できると、より自然なモデルが記述できる場合があります。

具体例のご紹介、ありがとうございました。現時点では、あいにく対応の予定はございませんが、ご要望としてお預かり致します。今後、同様の要望が増えてきた段階で対応を検討したいと思います。

以上、ご希望に添えず申し訳ありませんが、宜しくお願い致します。
okamura
投稿日時: 2008-4-30 16:38
開発者
登録日: 2006-5-2
居住地:
投稿: 157
Re: クラス図:関連クラス名と関連名を別々に設定する方法
参考までに、UMLの仕様書の関連クラスの説明には、”関連クラスの名前は一つしか存在しない”と注意して書かれています。
関連クラスは、関連+クラスなのではなくて、関連の性質もクラスの性質も両方持った一つのモデル要素、という考えになっています。
koba
投稿日時: 2008-5-1 16:47
新米
登録日: 2008-3-27
居住地:
投稿: 8
Re: クラス図:関連クラス名と関連名を別々に設定する方法
ご返答いただき、ありがとうございます。
たしかにUMLの仕様書(「UML2.0仕様書」p.256 7.3.4 AssociationClass)では
「関連クラスは名前を一つだけ持ち」
となっていますね。
JUDEとしては致し方ないところかも知れません。

参考情報までいただき、ありがとうございました。
naka_aki
投稿日時: 2008-5-2 8:35
常連
登録日: 2006-7-4
居住地:
投稿: 42
Re: クラス図:関連クラス名と関連名を別々に設定する方法
自称関連クラスオタクのnaka_akiです。

なにをもって「自然なモデル」と呼ぶのか、ってのもあります。

関連クラス名を動詞にするのも乙なもんですよ。
個人的にはそういうフレームワークに接する機会が多いもので。結構いいかんじです。

(ERD屋さん風にいえば「イベント系エンティティ」っていう奴でしょうか?)

なお、その場合、動詞の時制とかを細かくいじるといいです。たとえばコピー元 → コピー先という関連を表現するなら、単に「Copy」じゃなく、「Copied」「Copyable」とか。「既にコピーしちゃった」なら前者を使いますし「既にしたとは限らないが今後可能である」なら後者です。そうすることで、その関連クラスのインスタンスの意味が、よりピンポイントで絞れて、いい感じです。素の「xxxする」という動詞をそのまま関連名(関連クラス名)にするのは時々不安です。

(関連クラスに関する話題は、使いにくい→事例や議論が育たない→誰も使い方を開発しない→使いにくい…という負のスパイラルになってる気がする。)

例えば「注文する」は細かく見れば「注文済み」または「注文可能」のどちらかだけが必要だったりしませんか?あるいはその両方がそれぞれ別々に必要だったりしませんか?

この辺をびしっと分けとくと、たとえばCopyの責務がCopiedとCopyableに株分けされるので、関連クラスのインスタンスを、

●いつnew/deleteすべきかが、より明瞭になる。
●(責務が少ないから)いちど作ったインスタンスを後からupdate/deleteする必要性が減る。そのぶん色々な場面での分離度が上げれて、設計面のみならず実装面でも便利。

といったゴリヤクがある…んじゃないかなーと思ってます。
スレッド表示 | 新しいものから 前のトピック | 次のトピック | トップ

投稿するにはまず登録を