《大象 Thinking in UML》學習筆記（十三）——在提煉中思考

一、理解用例的本質
用例是系統思維
系統是一個封閉的、由一系列相互關聯、相互影響的物質構成的集合。所謂系統思維，就是考慮系統內事物的互相影響，歸納、抽象系統內的運行規律。
軟體不是孤立存在的，在設計時我們必須將軟體置於它所處的系統內容中：使用者、硬體、網路、應用環境等，並採用系統思維來分析和設計它。
用例具有系統性：
用例是相對獨立的；
不存在沒有參與者的用例，用例不應該自動啟動，也不應該主動啟動另一個用例；
用例的執行結果對參與者來說是可觀測的和有意義的；
用例必然是以動賓短語形式出現的。

用例是面向服務的
面向服務架構的第一條準則是：業務驅動服務，服務驅動技術。
SOA的開發過程與用例的分析過程也有著極高的相似程度。


二、理解用例驅動
用例與專案管理
在專案管理中，工作包佔據了非常重要的地位。
在UML裡，系統用例實現就是專案管理中的工作包。
專案管理中，一個工作包的工作量控制在1至2個人周是比較容易控制的；在系統用例裡，如果工作量大於這個時間，則需要通過用例實現來減少每個工作包的工作量。

用例與可擴充架構
業務驅動技術，一個好的可擴充架構是基於好的業務架構之上的。
業務架構從用例而來，每個用例定義了參與者對系統的要求，而業務系統，則需要將這些相對獨立的業務單元結合起來，形成更大的業務。
在需要擴充的系統裡，用例與用例之間必須避免緊耦合。
可擴充架構，其關鍵就在如何定義每個用例的介面，以及如何使用是和的技術架構來保證業務單元之間的互動來提供可擴充能力。
用例不但驅動軟體過程，也驅動技術架構。


三、理解建模的抽象層次
將事物按層次劃分是人們歸納和理解事物的重要形式。
層次不交叉，在描述事物的過程中，同一層的描述內容是“等值”的。
在進行分析設計之前，應當根據業務的複雜程度事先決定需要用多少個抽象層次來描述，並定義每個抽象層次要解決的業務問題，或者說定義每個抽象層次的關鍵特徵。
UML建模是以用例為基礎的，用例的粒度則和抽象層次直接相關，


四、劃分子系統的問題
電腦子系統描述了一個軟體的內部構成，它的劃分依據是對象依賴，目標是構建擴充下好的軟體結構；
業務子系統描述的是軟體的展現形式，以使用者部門或者業務為依據進行劃分。
使用者所謂的子系統，只是軟體展示出來的樣子，從物件導向的觀點來看，軟體內部應當維持最佳的對象結構，然後通過介面向外部展現外部所需要的樣子。


五、學會使用系統邊界
對象是由邊界來“封裝”的，介面正是邊界的體現。
描述系統時候，邊界用來定義系統的範圍，因為系統是由用例表示的，系統邊界由用例構成。
描述用例時候，邊界類是用例與外界的唯一通道，邊界類“封裝”了用例，用例邊界由邊界類來決定。
描述對象時候，對象封裝的結果是出現了一組介面方法，對象的邊界由這邊介面方法約束。

根據系統的複雜程度、業務需求規模大小決定用例的粒度，用邊界分析的方法可以協助確定用例的粒度。
邊界分析的方法主要有兩種：一種是根據業務從整體到局部；另一種是按照人邊界和物邊界進行劃分。

採用邊界分析方法進行分析，可以得到封裝度極好、介面處清晰明了、抽象層次井然有序的分析結果。


六、學會從介面認識事物
人們認知現實世界和認識軟體的過程是一致的，是從介面（表象）來認識對象而不是從對象內部（本質）來認識對象的。
將邊界分析得到的結果中，每個邊界都用介面來替代，就可以確定整個系統行為。


七、學會正確選擇
一個系統有多個涉眾，也有多個指標，所以對系統有多種期望和多個要求。所以即使在明確的期望和要求下，也需要變換立場來審視問題，做出取捨和平衡，得出最合理的設計。
此時可以用SWTO分析方法來進行判斷。
S：stretch（優點）
W：weakness（缺點）
T：threat（威脅）
O： opportunity（機會）

在需求分析和設計過程中，我們也需要改變立場來獲得對需求更為深入的理解。
在需求分析中過程，我們還可以多次變換視角，通過邊界的改變得出不同參與者與不同用例。


八、學會使用設計模式
設計模式是物件導向設計原則和方法的應用，是在具體實踐過程中解決某類問題而產生的經驗總結和最佳實務。
要使用好的設計模式首先要打好基礎，即你已經完全掌握了設計模式的意圖和適用性。