JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » Software Engineering » UML  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友    訂閱主題
reply to topicthreaded modego to previous topicgo to next topic
本主題所含的標籤
無標籤
作者 為系統的邏輯結構塑模:ㄧ般化(Generalization)問題
8953190





發文: 35
積分: 0
於 2008-05-26 14:30 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
小弟有一問,想請教各位大德。
UML2.0(o'reilly)一書中有提到,如果你發現自己再說ㄧ個類別有一部份是另ㄧ類別的物件,此關係很可能是關連,聚合,或合成。如果你發現自己在說ㄧ個類別是另ㄧ個類別的型別,妳可能要改用一般化。這是啥意思呢?有點不懂!!

能用點簡潔有利的說明嗎?或者詳細貼切的例子?
幫忙解答!謝謝~


8953190 edited on 2008-05-26 14:32
reply to postreply to post
作者 Re:為系統的邏輯結構塑模:ㄧ般化(Generalization)問題 [Re:8953190]
dale1





發文: 6
積分: 0
於 2008-05-26 16:20 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
想像一下有兩個類別, 就說 A 跟 B 吧~
A 跟 B 有關係, 但是不確定是什麼關係, 就會很粗糙的先用 "關聯" (Association)帶過,
這個關聯, 可能是 "使用", 例如 A 使用 B (人使用車子); 也可能是 A 操控 B (人操控車子); 這個 "關聯" 到底是什麼樣的關聯,就看設計者的意圖而定。

A 跟 B 有關係, 並且已經確定是 "擁有" (has a) 的關係, 就可以確定是"聚合"(Aggregation),或"合成"(Composition), 例如: A 擁有 B。 那麼, 到底是"聚合"還是"合成", 也是看設計者的意圖而定。 比如說, 如果電腦製造商定義, 電腦的硬碟壞了, 只要換硬碟, 電腦就可以繼續使用, 那電腦跟硬碟的關係就是聚合 ; 如果 電腦的硬碟壞了, 就代表整台電腦都壞掉了 (是的, 這是很爛的設計,電腦跟硬碟不應該綁這麼緊), 那電腦跟硬碟的關係就是合成。

A 跟 B 有關係, 並且已經確定是 "同一種" (is a) 的關係, 就可以確定是 "一般化"(Generalization)關係, 也就是常常用的"繼承"關係,例如: A 是一種 B (車子是一種交通工具)。

如有錯誤, 還懇請先進不吝指教~


reply to postreply to post
作者 Re:為系統的邏輯結構塑模:ㄧ般化(Generalization)問題 [Re:8953190]
8953190





發文: 35
積分: 0
於 2008-05-26 16:38 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
謝謝dale1 的詳細論述
小弟再搭配課本反覆閱讀後,更了解其中關係了。
可是,又有另ㄧ問因此而生!
依賴(Dependency)要如何解釋呢?
書本說是短暫使用,那關聯,聚合,合成都不能短暫擁有嗎?
如果不能,邏輯上如何解釋較妥呢? 謝謝!


8953190 edited on 2008-05-26 16:52
reply to postreply to post
作者 Re:為系統的邏輯結構塑模:ㄧ般化(Generalization)問題 [Re:8953190]
dale1





發文: 6
積分: 0
於 2008-05-26 17:40 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
還是 A 跟 B 好了~
A 跟 B 有關係,並且已經確定是 "依賴" 的關係, 代表 A 本身沒有能力完成工作,A必須依賴 B 來做事。 比如說,"主管" 依賴 "部屬" 完成工作。一旦事情完成了,有結果了,A 就不再需要 B ("主管"領功去了,"部屬"不再被需要 ...),所以是 "短暫使用" 。

"依賴" 關係 只能是單方向的關係,不能是 "來回依賴" (Circular Dependency )。比如說,A 可以依賴 B ,但是不能夠 B 又再返回依賴 A ,以免責任劃分不清,形成設計上的錯誤 ("主管" 與 "部屬" 互踢皮球)。

如有錯誤, 還懇請先進不吝指教~


reply to postreply to post
作者 Re:為系統的邏輯結構塑模:ㄧ般化(Generalization)問題 [Re:dale1]
271080

邱郁惠

版主

發文: 22
積分: 0
於 2008-05-26 20:28 user profilesend a private message to usersend email to 271080reply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
(此回覆同步貼於UML Blog(http://www.umltw.com/2008/05/blog-post_26.html)中)

結合關係(association)是一種靜態結構上的關係,換言之,它偏向於資料關係。所以,兩類別之間放置結合關係,同時意味著這個關係必須被保存起來,這也是為何UML類別圖中最常出現的是結合關係。比方說,顧客跟訂單之間的關係,就會使用結合關係,因為我們希望系統可以保存兩者之間的關係。

結合關係的兩端通常是平等的,如果要表達整體-部分(whole-part)意涵時,就可以改用聚合關係(aggregate,空心菱形),或是組合關係(composite,實心菱形)。特別注意的是:

1. 聚合與組合都是一種結合關係,只是額外具有整體-部分的意涵。

2. 聚合關係中,整件(whole object)不會擁有部件(part object)的生命週期,所以整件刪除時,部件不會被刪除。再者,多個整件可以共享同一個部件。

3. 組合關係中,整件擁有部件的生命週期,所以整件刪除時,部件一定會跟著刪除。而且,多個整件不可以同時間共享同一個部件。

至於,實務上倒底要採用聚合關係還是組合關係,不決定於真實,而是決定於企業規則。比方說,訂單與細項之間的關係,通常採用組合關係,一旦訂單被刪掉時,底下的細項也會同時被刪除。但是,這是比較常見的企業規則,試想,或許有些領域的交易是可以拆單的,訂單被取消時,原先的細項可以被併入別的訂單中,若是如此,就適合使用聚合關係了。

一般化(generalization)是兩類別之間的關係,不同於上述的結合、聚合或組合關係,它是一種分類關係。或者說,針對某一概念或事物,其個體可區分為一般類(父類別)與特殊類(子類別)時,兩者之間便可以放置一般化關係。舉例來說,我們會說無線滑鼠和有線滑鼠(它們都是特殊類別/子類別)都是一種滑鼠(一般類別/父類別)。

依賴關係又與上列幾種關係不同,先說明為何許多UML書上會說它是短暫關係,其實這是相對於結合(聚合、組合)關係,前面有我們有提到,結合關係是一種靜態結構關係,是需要被保存下來的。相較之下,依賴關係並不需要被儲存起來,所以才會說它是短暫關係。

最常見的依賴關係(dependency)是一種使用關係,譬如顧客類別裡頭有一個計算年度交易總額操作好了,在這個操作中必須連到一群當年度的交易物件,並且呼叫交易物件取得交易金額進行累加,才能計算出年度交易總額。在這個例子中,顧客類別與交易類別就有短暫的依賴關係。

再度提醒的是,到底使用結合、聚合、組合、一般化或依賴關係,無關乎真實現象,而是與企業規則,或者與設計者想要表達什麼樣的設計有關,所以兩類別之間具有什麼樣的關係並無固定答案,端看設計而定。


reply to postreply to post
邱郁惠(271080@gmail.com)
UML Blog(http://www.umltw.com)
作者 Re:為系統的邏輯結構塑模:ㄧ般化(Generalization)問題 [Re:8953190]
8953190





發文: 35
積分: 0
於 2008-05-27 12:05 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
dale1與邱郁惠 兩位大大,謝謝您不厭其煩的回答小生不解之惑,小生非常感激。
但迷惑還未解除,願能再其詳論小生的迷惑並與以解答
迷惑點:
就您所論述"如果電腦製造商定義, 電腦的硬碟壞了, 只要換硬碟, 電腦就可以繼續使用, 那電腦跟硬碟的關係就是聚合" 那是不是電腦硬碟壞了,若不更換硬碟就不能繼續完成工作(如無法開機等等...)??若是,那不是也屬於您所論述的依賴關係嗎?(因電腦沒有能力完成工作,所以必須依賴硬碟)

不知小弟的想法是否正確?還是說,有其涵義?
願聞其詳,謝謝!!


reply to postreply to post
作者 Re:為系統的邏輯結構塑模:ㄧ般化(Generalization)問題 [Re:8953190]
dale1





發文: 6
積分: 0
於 2008-05-28 10:27 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
還是 A 跟 B 好了~
在渾沌不明的前期分析階段,我們在構思 class diagram 時,常常會"假設" A 跟 B 有 結構化(structural)的 關係。這個結構化的關係,也許是"關聯" (Association),也許是"聚合"(Aggregation)(Composition 是一種 Aggregation)。一直到設計階段,我們就必須決定這個 關係 的真正意義,不然程式寫不下去。

"依賴"(Dependency)關係 屬於 非結構化(non-structural) 關係。在分析階段的 class diagram 很少見到。為什麼 ? 因為分析階段很多的 "語意關係" (semantic relationship) 尚未清楚。必須經由不斷的推敲思考,確定 B 的改變 會導致 A 的改變,這時候才會說 " A 依賴 B "。

所以囉~
在分析階段,我會把 "電腦"跟 "硬碟" 的關係,很粗糙快速的視為"聚合"(Aggregation)。也許到了設計階段,發現我之前的分析有錯,在修正即可。 然而,我無法在 分析階段 就可以想像 - 不同的"硬碟" 對 同一台"電腦" 會產生不同的影響(IDE 或 SATA 對電腦效能的影響...),所以我不會採用 "依賴" 關係。直到我 100% 確定 "電腦"跟 "硬碟" 之間真正的互動行為之後,我才可以確定我的設計是對的~

邱郁惠小姐的解說相當精闢,值得您仔細思考~

另外~ 雖然中文字面翻譯都叫"關係" 但是原文書上面,是用 Relationship 而不是 Relation,意思是 : 比普通的關係還要更緊密! 所以,要確定兩個類別到底是什麼關係,真的要花些時間去了解 Domain Know-How。

如有錯誤, 還懇請先進不吝指教~


dale1 edited on 2008-05-28 10:30
reply to postreply to post
作者 Re:為系統的邏輯結構塑模:ㄧ般化(Generalization)問題 [Re:8953190]
8953190





發文: 35
積分: 0
於 2008-05-28 11:27 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
恩!!我對這,是也非也,渾沌不明的感覺有些初步掌握了!!
感謝大德論述!


reply to postreply to post
作者 Re:為系統的邏輯結構塑模:ㄧ般化(Generalization)問題 [Re:8953190]
starlin





發文: 14
積分: 0
於 2011-06-13 00:12 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
1) Apple Tree HAS Apples

2) Apple is a kind of Fruit


reply to postreply to post
» JWorld@TW »  Software Engineering » UML

reply to topicthreaded modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8