(零雨其蒙原創 轉載請注明)
2007
年
3
月
12
日星期一
第
30
章
用例關聯
目標：
以文本和圖形兩種形式，使用包含（
include
）
和擴展（
extend
）
關聯將用例聯系在一起。
?
Include
包含關系
我覺得理解其內涵可以考慮其動機（我發現其實大多數這個行業的理論都可以從考慮其動機開始，這樣會更好、更容易的理解），包含關系就是將幾個用例中相同部分抽出來，形成一個單獨的用例，那么就說那幾個用例包含該用例。其實包含的意義在于減少冗余，增加復用，所以在編寫用例時出現包含關系應該是一件水到渠成的事情。于是
Fowler
給出了何時使用包含關系的簡單且實用的準則
[Fowler03]
：
當在兩個或多個獨立用例中存在重復，而你想避免這種冗余時，可以使用
包含
關系。
包含
關系的另一個用途是描述異步事件的處理。指的是在任何時候都可以在主場景中插入該動作。
?
Cockburn
建議：
使用包含關系來處理用例之間的關系是首要原則。
Extend
擴展關系
擴展關系
是當一個用例不便或不能任意在其上添加新功能時創建擴展或附加用例，并且在其中描述，在何處和何種條件下該用該用例擴展某基礎用例的行為。相當于一部沒用照相機的手機（基礎用例），想要添加照相功能，就需要增加一個擴展插件（擴展用例），但是需要在原來手機中提供插入接口（擴展點）。具體例子見
360
頁。
?
批駁和指正一些不正確的做法是
Larman
本書的一個特點，在這一部分他指出“某些用例準則建議使用擴展用例和擴展關系，將有條件行為或者可選行為加入基礎用例。這一觀點是不正確的?！焙玫淖龇ㄊ恰皩⑵渲苯訉懭耄ɑA用例的）
擴展
部分”。增加擴展用例和擴展關系的最現實動機（或者可以說是最好的動機）就是：由于某種原因實在不能在基礎用例上進行修改了。
?
泛化關系
?????????????
絕大多數情況下不會使用，而且避免過多使用用例關系是好的實踐，即便使用了用例關系，也只是在必要時使用簡單的包含關系就可以了。用例顧問們共同觀測結論是：大量用例關系會導致復雜結果，并且會花費大量徒勞的時間。
?
?
第
31
章
領域模型的精化
時間間隔
??
反映了某些業務對象僅在有限的一段時間內有效者一概念。
包
??
使用包可以將大的領域模型組織成較小的單元。
概念分類列表
|
分類
|
示例
|
|
有形對象
|
CreditCard
，
Check
|
|
事務
|
CashPayment
，
CreditPayment
|
|
其他外部的計算機或機電系統
|
CreditAuthorizationService
|
|
抽象概念
|
?
|
|
組織機構
|
CreditAuthorizationService
|
|
金融、工作、合同、法律事務等的記錄
|
AccountsReceivable
|
?
從用例中識別名詞短語
不能機械地從用例中提取概念，應該作出必要的判斷和適當的抽象。
Generalization
泛化
???
?
泛化是
在多個概念中識別共性和定義超類（普遍概念）與子類（具體概念）關系的活動。
此活動對概念進行分類學意義上的分類，并將其在類層次結構中表示出來。遇到相似的概念，將其組織起來，形成泛化—特化類層次結構（簡稱類層次結構）。在這里我們討論的是概念類而非軟件類。
什么樣的概念子類是正確的？
???
正確的概念子類應遵守下面兩條規則（
規則意味著一定要遵守）：
l????????
100%
規則（定義的一致性）
l????????
Is-a
規則（集合成員關系的一致性）
?
定義概念子類的動機
????????
準則
在下述幾種情形下創建概念類的子類：
1
）子類有額外的有意義的屬性
2
）子類有額外的有意義的關聯
3
）子類概念的操作、處理、反應或使用的方式不同于超類或其他子類，而這些方式是我們所關注的。
4
）子類概念表示了一個活動體（例如動物、機器人等），其行為與超類或者其他子類不同，而這些行為是我們所關注的。
???
有意義和我們所關注的成為了上述準則（也可以說是
Larman
的整體思想）所強調的一個重點，子類的創建一定要創造價值，否則就不要創造它了。而上述準則為我們指明了創造子類的動機，無外乎就是說子類有了新的有意義的屬性、關聯和方法，需要將其創建出來。
?
?
定義概念超類的動機
????????
準則
在下述幾種情形下可以創建與子類具有泛化關系的超類：
1）
?
潛在的概念子類表示的是相似概念的不同變體
2）
?
子類滿足
100%
和
Is-a
規則
3）
?
所有子類都具有相同的屬性，可以將其解析出來并在超類中表達
4）
?
所有子類都具有相同的關聯，可以將其解析出來并與超類關聯。
?
對變化的狀態建模
準則
不要將概念
X
的狀態建模為
X
的子類。有兩個辦法可供選擇：
1
）定義狀態類層次結構，并將其與類
X
關聯
2
）在領域模型中忽略概念的狀態，而在狀態圖中加以反映。
?
關聯類
準則
???
在領域模型中，如果類
C
可能同時有多個相同的屬性
A
，則不要將屬性
A
置于
C
之中。應該將屬性
A
放在另一個類中，并且將其與類
C
關聯。
?
?
增加關聯類的準則
準則
在領域模型中增加關聯類的可能線索有：
l????????
有某個屬性與關聯相關
l????????
關聯類的實例具有依賴于關聯的生命期
l????????
兩個概念之間有多對多關聯，并且存在與關聯自身相觀的信息。
√
這與數據庫建模中創建關聯是一樣的（我暫時如此認為），這樣我們可以以同樣的觀點來理解合適增加關聯類（因為數據庫建模是我近幾年做項目最常用的開始軟件分析設計的起點，而學習了本書后，我想領域建模將成為我的起點）。
?
組合
組合是一種關聯關系，這在之前已經討論過了。但是在這一章補充了組合的一些準則。
?
使用組合關系的準則
準則
在下述情況下，可以考慮組合關系：
l????????
部分的生命期在組成生命其界限之內，部分的創建和刪除依賴于整體。
l????????
在物理或邏輯組裝上，整體—部分關系很明確
l????????
組成的某些屬性（例如位置）會傳遞給部分
l????????
對組成的操作（例如銷毀、移動、記錄等）可能傳遞給部分
?
我的觀點：
知道什么時候用比知道是什么更難，而且也更加重要。
?
受限關聯
???
在關聯中可能會用到限定詞（
qualifier
）
；基于限定詞的值可以區分位于關聯另一端的對象集合。具有限定詞的關聯是受限關聯。
在領域模型中
，描述一個限定詞所表達出的含義是：如何通過與另一個類的關系來區別某類中的事物。在此模型中不要用限定詞表示有關查找關鍵字這樣的設計決策。
?
自反關聯
???
概念到自身的關聯稱為自反關聯（
reflexive associaition
）。
?
使用包來組織領域模型
所有權和引用
???
元素屬于包含它的包，但同時也可以被其他包引用。在引用時，需要以包名對元素加以限定，格式是：包名：：元素名。對于在外部包（引用元素的包）中所表示的被引用的類，只可以添加新的關聯，除此之外都不能改變。（好比說水中映月，你不能改變水中月亮，因為你改變了水中月亮，天上的月亮也不會改變）
?
包的依賴關系
??????????
如果模型元素以某種方式依賴于另一元素，則可以用依賴關系來表示。
?
如何劃分領域模型
????
準則
將領域模型劃分為包結構時，將滿足下述條件的元素放在一起：
l????????
在同一主題領域，概念或目標密切相關的元素
l????????
在同一類層次結構中的關系
l????????
參與同一個用例的元素
l????????
有很強的關聯性的元素
?
?
第
33
章
架構分析
什么是架構分析？
l????????
架構分析可以被視為需求分析的規格化，其關注強烈影響“架構”的需求。
l????????
架構分析的本質是要識別影響架構的因素，理解這些的可變性和優先級，并且解決這些問題。其難點是要知道應該問什么樣的問題，權衡利弊和了解處理一個重要架構因素的各種辦法，從良性忽略到奇特設計或者第三方產品等。
優秀的架構師的價值在于他們具有知道問什么問題的經驗，并且能夠熟練選擇各種方法來解決這些因素。
?
l????????
是在功能性需求（例如處理銷售等）的語境中，識別和處理系統非功能性需求（例如安全需求等）的活動。
其包括識別變化點和最具可能性的進化點。
l????????
在
UP
中，術語“架構分析”既包含架構調查（識別）也包含架構設計（解決）。
?
?
變化點和進化點
l????????
變化點（
variation point
）
——當前現有系統或需求中的變化之外
l????????
進化點（
evolution point
）
——現有需求中不存在、但可能在將來發生，推測性的變化點。
架構分析的常用步驟
1）
?
識別和分析對架構有影響的非功能性需求。
2）
?
對于這些架構方面具有重要影響的需求，需要分析可供選擇的辦法并創建解決這些影響的解決方案。這就是架構決策。
?
因素表
??
|
因素
|
度量和質量場景
|
可變性
(
當前的靈活性和未來的演化性
)
?
|
該因素對涉眾、架構以及其他因素的影響
|
對于成功的優先級
|
困難或風險
|
|
可靠性和可恢復性
|
|
?
|
?
|
?
|
?
|
?
|
?
|
|
可支持性和可適用性
|
|
?
|
?
|
?
|
?
|
?
|
?
|
因素表是用例補充規格說明的一部分。它主要用來幫助架構師理解架構性因素的影響、優先級和可變性（立即需要的靈活性和未來的演化）。度量場景主要是將一些因素量化。
?
關注分離
實現關注分離的幾個大尺度的技巧：
1）
?
將有關事務模塊化，封裝到單獨的構件（例如子系統）中，并調用其服務
2）
?
使用裝飾者
3）
?
使用后編譯器和面向方面技術。
?
在
UP
中，架構的逐步演化和穩定是通過早期的以架構為核心的開發和測試，而不是通過紙上談兵或者“
PowerPoint
架構”來完成的。
?
UP
制品中的架構信息
l????????
架構性因素（例如因素表中的因素）被記錄在補充規格說明中
l????????
架構性決策被記錄在
SAD
（軟件架構文檔）中。這其中包含技術備忘錄和架構視圖的描述。
?
?
?
第
34
章
邏輯架構的精化
使用層模式的協作
首先層模式就是我們熟悉的分層架構！
簡單包與子系統
????
某些包和層不僅僅是概念上的一組事物，事實上它們是具有行為和接口的子系統。
外觀
????
對于表示子系統的包，
GoF
外觀（
Facade
）模式是最常用的訪問模式。一個公共的外觀對象定義了子系統的服務，客戶端不與子系統內部的構件交互，而是通過與外觀對象協作來訪問子系統。
會話外觀和應用層
????????
當系統不斷增長，需要處理許多用例和系統的操作時，則通常會引入應用層的對象來維護用例操作的會話狀態，每個會話實例表示與一個客戶的會話。這被稱為會話外觀（
Session Facade
）。
?
?
應用層
：如果存在應用層，則其應作為
UI
層和領域層之間的中介，容納負責獲知客戶會話狀態的對象，并且負責控制工作的流程。
松散分層耦合關系
有關層之間的典型耦合有下面的注解：
l????????
所有較高層都依賴于技術服務層和基礎層。
l????????
領域層依賴于業務基礎設施層。
l????????
UI
層調用應用層的服務，應用層又調用領域層的服務。除非沒有應用層，否則
UI
層不直接調用領域層的服務
l????????
對于單進程的“桌面”應用，領域層的軟件對象對于
UI
層、應用層（某種程度上，還有技術服務層）可見（可見就是說
UI
層或應用層能調用領域層對象），或者在上述各層之間傳遞（指的是領域層對象可以被傳遞到
UI
層展示數據或傳遞到技術服務層中的持久性子系統中）
l????????
另一方面，在分布式系統中，通常將領域層對象的序列化副本（也稱為值對象（
value object
）
）或數據持有者（
data object
）傳遞給
UI
層。在此情況下，領域層部署在服務器上，客戶節點得到服務器數據的副本。
?
?
基礎設施層
??????????????
將技術服務層和基礎層看成一組，稱為基礎設施層