這段時間在學 UML 模組化,UML 10 中常見的域模組化錯誤摘錄如下:
1.立即關聯指定多重度,確定每個關聯都有明确的多重度
類圖上有些關聯度表示的是一對一的關系,而其他關聯表示的是一對多的關系。這兩種關系都被稱為多重度。然而,不應在域模組化期間就确定多重度 —— 這将占用大量的時間,是導緻分析癱瘓的主要原因之一。
2.對名詞和動詞做過度的分析,而背離初衷
對名詞尤其是動詞作過度的分析,将很可能處于過低的抽象層次上,嚴重者還會有神經崩毀的危險(當然這是玩笑話)。
3.不對用例和時序圖進行研究,就将操作配置設定給類
我們提倡在域模組化過程中使用要求最低的的方式。事實上,我們是想告訴你,不應該在域模組化期間将任何操作配置設定給類。因為,在項目的該階段還沒有足夠的資訊,無法做出正确的決策。進入互動模式後,你将擁有足夠的資訊(至少希望如此),
4.在確定已滿足使用者需求之前,對代碼進行優化以提高重用性
對象和類的通用程度越高,在其他項目中重用他們的可能性就越大。一個完整地類在理論上是可以在任意數目的環境(context)中重用的,然而要實作完整性和重用性,必須考慮屬性和操作,而前面已經指出了不應在域模組化期間将操作配置設定給類的原因,是以在完成進階類圖期間,将過多的精力用于提供類的可重用性是不明智的,應快速完成域模組化的工作,以便有時間確定你建構的系統正是使用者所需要的。
5.對于每個部分(part-of)關聯,就使用聚集還是組合而争論不休
在 UML 中,有這麼一種說法,“按引用擁有”關系是聚集,而“按值擁有”關系是一種被稱為組合的“強”形式的聚集,在這種關系中,“部分”類歸父類“所有”:父類被删除後,其所有的子對象示例将自動删除。在域模組化期間視圖區分聚叢集組合無疑是費力不讨好的。在域模組化期間,更傾向于使用簡單的聚集。使用聚集還是組合是一個詳細設計方面的問題。
6.未對問題空間進行模組化之前,就假定一種具體的實作政策
改進域模型時,應删除所有明顯陳述動作而不是依存性的内容以及同實作相關的内容。在進階類圖中,不應引入涉及到具體技術的内容,如關系資料庫或特定的伺服器。将實作問題留待實作階段解決,首先對問題域模組化。
7.将類命名為難以了解的名稱(如 cPortMgrIntf),二不是直覺的名稱(如 UserManager)
首先建立模型的一個重要原因,就是促使每個小組成員就關鍵抽象的名稱達到一緻。類名越簡明,這項任務就越容易。應等到實作時再使用首字母縮寫和各種縮略語(如果你一定要這樣做的話)。
8.直接進入實作結構,如友元關系和參數化類
UML 提供了大量将我們稱作“Booch 素材”的東西添加到類圖中的機會。這包括直接來自C++的結構,如參數化類和友元關系。這些東西與解決方案空間相關,而與問題空間不相關,是以域模組化絕對是屬于問題空間的。
9.在域類和關系資料庫表之間建立 1 對 1 的映射
對使用關系資料庫的遺留系統進行重構時,資料庫中的表可能是很多的域類名稱的來源。然而,決不要将它們完全搬照搬到靜态模型中。關系資料庫中的很多屬性不能找搬到對象模型環境中,應盡可能通過聚集,将屬性組轉換為“助手(helper)“類。這種類包含的屬性和操作可被組合成更小的“部分”類。
10.過早地執行“模式化”,這将導緻根據同使用者問題毫無關系的模式建立解決方案。
模式通常在健壯性分析時才能發現。有兩種政策可用于發現同用例相關的模式:“螢幕控制”和“用例控制器”。設計模式對時序圖和設計級類圖很有用,但域模組化期間不應考慮模式的問題。
本文轉自peiquan 51CTO部落格,原文連結:http://blog.51cto.com/peiquan/1328090