Index: [Article Count Order] [Thread]

Date:  15 Apr 2005 19:07:19 +0900
From:  "y-kamite" <y-kamite@....jp>
Subject:  [modeling-dojo:00311] Re: コメントお疲れ様です(訂正)
To:  modeling-dojo@....jp
Message-Id:  <20050415185206.21EF.Y-KAMITE@....jp>
In-Reply-To:  <20050415053218.23482.qmail@....jp>
References:  <20050415053218.23482.qmail@....jp>
X-Mail-Count: 00311

#すみません。書きかけのものをご送信してしまいました。
#こちらが正しいです。

こんにちは、上手です。
 
> 依存方向に誤りがある
> このモデルだと同じItem(品物種別)の服を同時にOrderすることができない
> 現物がない :現物?
> 
> この3点が理解できんでした、勉強してみます
> (特に回答を求めるものではありません)

荒井さんのモデルのレビューの方式を早速使ってみます。

・日本語に直して関係を読み上げる。

(荒井本 P.102)
Item は Price に依存する。
Service は Price に依存する。

依存の向きは確かに逆のようです。

(P.76)
Item は Order の一部です。
Order は 0 以上の Item を必要とする


Service は Item の一部です。
Item は 0 以上の Service を必要とする

背広:種類
実際のモノ:現物
黒い背広上下
紺の背広上下
とすれば良いのですが、上のItemクラスはこの2つのクラスの属性や操作が
混ざっているようです。このため、背広(種類)をクリーニングに出すと、もう
同じ背広(種類)はOrderできなくなります。

・荒井本P.99 クラス+操作で読み上げて検証する。
Item の deliver は。

種類が納入をするというのは矛盾していませんか。

集約もおかしそうです。
多重度もおかしいかな。
・荒井本P.99 集約か関連か迷ったら、関連を引く

IDなどの属性名は、設計モデルを示すので、分析モデルでは使いません。

・・荒井本P.80 分析モデルと設計モデルの書き分け
以下のようなものが分析クラスにあってはいけない
1 IDなどの識別子
2 属性の中にデータのキャシュを目的とした属性がある
3 属性、引数、返り値のいずれかに型が定義してある
4 属性、操作に可視性が定義してある

(では)

> 
> 他の作品のコメントもこれからじっくり読みたいと思います
> 
> SadMan
> 

---------------------------------------------------
上手裕 y-kamite@....jp y-kamite@....jp
---------------------------------------------------