UML
和模式學習筆記
(零雨其蒙原創 轉載請注明)?
本書中的英文
Ledger
分類帳
Payment n.
支付現金
Sale
銷售
SalesLineItem
商品條目
Quantity??
數量（每一小項的數量）
Amount???
數量，總計（錢）
ProductCatalog???
產品目錄
Register??
記錄器（指
POS
機）
Credit AuthorizationService
信用卡授權服務
TaxCalculator
稅金計算器
Account?
財務
Inventory??
庫存
Approval
批準
requestApproval
請求批準
Discount
折扣
?
Manufacturer
制造商
?
Piece?
塊（指的應該是棋子）
Die???
骰（色）子
Square
格子（棋盤上的格子）
Board?
板子（指棋盤）
Cup???
骰（色）盅
?
Assembly?
部件
?
?
第
2
章
迭代、進化和敏捷
開發案例
為項目選擇實踐和
UP
制品可以編寫為簡短文檔，這稱為開發案例。
?
?
|
科目
|
實踐
|
制品
迭代→
|
初始
I1
|
細化
E1
…
En
|
構造
C1
…
Cn
|
移交
T1
…
Tn
|
|
業務建模
|
敏捷建模
需求討論會
|
領域模型
|
?
|
s
|
?
|
?
|
|
需求
|
需求討論會
|
用例模型
|
s
|
r
|
?
|
?
|
|
設想
|
s
|
r
|
?
|
?
|
|
補充性規格說明
|
s
|
r
|
?
|
?
|
|
詞匯表
|
s
|
r
|
?
|
?
|
|
設計
|
敏捷建模
測試驅動開發
|
設計模型
|
?
|
s
|
r
|
?
|
|
軟件架構文檔
|
?
|
s
|
?
|
?
|
|
數據模型
|
?
|
s
|
r
|
?
|
|
實現
|
測試驅動開發
結對編程
持續集成
編碼標準
|
?
|
?
|
s
|
r
|
r
|
|
項目管理
|
敏捷項目管理
Scrum
每日例會
|
?
|
s
|
r
|
r
|
r
|
|
……
|
?
|
?
|
?
|
?
|
?
|
?
|
S
表示開始
?
?
r
表示精化
第
10
章
系統順序圖
系統事件與系統操作
系統事件，
就是外部輸入事件
系統操作
，就是處理系統事件的操作
?
?
2007
年
3
月
3
日星期六
?
第
13
章
邏輯架構和
UML
包圖
?
層（
Layer
）
是對類、包或子系統的甚為粗顆粒度分組，具有對系統主要方面加以內聚的職責。
OO
系統中通常包括的層有：
l????????
用戶界面（
UI
）
l????????
應用邏輯和領域對象（
domain
）：表示領域概念的軟件對象，這些對象實現了應用需求
l????????
技術服務（
Service
）：提供技術性技術服務的常用對象和子系統，例如數據庫接口或錯誤日志。（
Persistence
，
Logging
）
在
springframework
的
jpetstore
例子中的結構就是如此，我是按其目錄劃分來理解這些層次的。它分為
web
（表現層，提供了
spring mvc
和
struts
兩種
mvc
框架）、
dao
（其中的
iBatis
目錄是
dao
目錄的接口的實現類和輔助類）、
service
（里面包含了
web service
提供的遠程服務）、
domain
（包括了領域對象，其中的
logic
目錄則是一些業務邏輯）。
我覺得在
150
頁的圖
13-4
更好的細分了信息系統邏輯架構中常見的層。
l????????
UI
（
Presentation,View
）
l????????
Application(Workflow,Process,Mediation,App Controller)
l????????
Domain(Business,Application Logic,ZModel)
l????????
Business infrastructure(Low-Level Business Services)
l????????
Technical Services(Technical Infrastructure,High-level Technical Services)
l????????
Foundation(Core Services,Base Services,Low-level Technical Services/Infrastructure)
而在
153
頁給出的架構的混合視圖，給出了一個基本完整（不包含
UI
）的架構邏輯視圖，并對好的設計和不好的設計進行了對比。
Tier
和
Layer
我在
2006
年的夏天曾經仔細研究了這個問題，當時的結論是
Layer
傾向于邏輯層，
Tier
傾向于物理層。而在
Larman
的這本書里他給出了一個帶有歷史進程意味的
Tier
的定義：
tier
在架構中最初表示的是邏輯層（
Logic Layer
），而不是物理節點，但是現在，這個詞被廣泛用于表示物理進程節點（或節點簇），例如“客戶層”（客戶計算機）。
而后，
Larman
給出了對比了
layer
和
partition
，前者是對系統的垂直劃分，后者是水平劃分，形成相對平行的子系統。比如技術服務層（
service
）可以劃分為安全（
Security
）、持久化（
Persistence
）等分區。在這里我再一次很佩服
Larman
對問題的闡述能力，以前在《程序員》上看過一篇講分層結構的正交分解的文章，當時可能也是我水平有限，所以看得還是比較糊涂。
?
領域層和領域模型之間的關系
其實這個問題在學習領域模型時已經探討過了，不過現在則更清楚，領域模型是分析階段的將重要的領域概念可視化的結果，而領域層則是軟件設計中領域對象和領域規則的集合，在這里我覺得領域對象和領域規則的關系是領域對象內部包含一部份領域規則，而一部分領域規則則是依賴很多領域對象來完成的。
就像我以前主張的一樣，類的定義要有現實意義，比如
People
類就應該只干人事，公雞類就不應該有下蛋的方法，而
OO
技術則倡導由領域模型來獲得領域層類命名的靈感。這種做法叫作現實世界與軟件設計之間的低表示差異。
?
模型——視圖分離原則
?
這一部分的論述幫我找到了先前研究
MVC
最大的一個疑惑，就是
Model
到底指的是什么？
Larman
在
154
頁做了回答：在這種語境下（應該指的是前面提到的分層架構（
Layered Architecture
，它的先驅是在
[BMRSS96]
中描述的層模式（
layers pattern
））這個語境下），模型是領域層對象的同義詞（源于
20
世紀
70
年代末的陳舊術語）。視圖是
UI
對象的同義詞，例如窗口、
Web
頁面、
applet
和報表。
?
關于
MVC
的進一步理解
?
我一直在尋求一份
MVC
中各個元素是什么的標準答案，在介紹模型—視圖分離原則時下面有一段注釋（不知道是不是
Larman
本人的注釋，不過該書的注釋部分似乎有這樣的規范：如果是譯者添加的注釋，則在注釋后面寫上譯者注，由此判斷此處的注釋是作者原文的注釋）：這（指模型—視圖分離原則）是模型—視圖—控制器（
MVC
）模式的關鍵原則。
MVC
源于一個小型的
Smalltalk-80
模式，與數據對象（模型）、
GUI
小部件（視圖）和鼠標、鍵盤事件句柄（控制器）相關。近來，術語“
MVC
”被分布式設計團隊采納，將其應用在大規模的架構上。
MVC
中的模型指領域層、視圖指
UI
層、控制器指應用層的工作流對象。
以前，我一直在模型是指數據模型還是指領域層（那些能夠處理業務邏輯的類——那時我還不知道他們叫領域層對象），而上面這段說法使我比較信服。說
M
表示數據對象也不錯，不過那是
Smalltalk-80
朝代的事情了，就像說
PHP
是個人主頁工具（
Personal Home Page
）的縮寫也是正確的一樣，不過那是它最早的名字。
?
UML
包圖
通常用于描述系統的邏輯架構——層、子系統、包（就
Java
而言，那么就
.Net
而言指的就應該是命名空間了）。
UML
包提供了組織元素的方式。
UML
包能夠組織任何事物：類、其他包、用例等。
第
14
章
邁向對象設計
??? 159
頁介紹的一個重要的學習
UML
圖的準則就是：應該把時間花費在交互圖（順序圖或通信圖），而不僅是類圖上。忽視這一準則是十分常見的
UML
錯誤實踐。
這一點在我當初學習
UML
時就深深感到，當我們花類圖時還感覺比較容易，而到了交互圖則感到十分的困難，往往不知道怎么畫，于是從那時到現在我一直依靠類圖來進行設計和代碼生成（類圖只是幫助我來定義單個類，而對于類之間的關系就不考慮了，不過這已經很有用了）。
?
第
15
章
UML
交互圖
UML
順序圖中的圖框
P168
|
圖框操作
符
|
含
義
|
|
alt
|
選擇性的片斷，用于表示保護信息所表達的互斥條件邏
輯
|
|
loop
|
用于表示保護信息為真的循環片斷。也可以寫為
loop
（
n
）以指名循環的次數。這樣能夠增強規格說明，用以表示
FOR
循環，例如
loop
（
i
，
1
，
10
）
|
|
opt
|
當保護信息為真時執行的可選片
斷
|
|
par
|
并行執行的并行片
斷
|
|
region
|
只能執行一個線程的臨界片
斷
|
保護信息
指的是
loop
后面的
[more items]
，和
opt
后面的
[color=red]
黨這些保護信息為真時將執行該片斷。
?
生命線參與者應該表示一個對象，而不是集合。如
lineItems[i]
：
SalesLineItem
。
（
P170
圖
15-16
）
?
順序圖就是序列圖（翻譯方法不同），通信圖就是協作圖（叫法不同），它們合成交互圖
第
16
章
UML
類圖
UML
用類圖（
class diagram
）表示類、接口及其關聯。
?
表示
UML
類圖屬性的方式：屬性文本和關聯線
準則：對數據類型對象使用屬性文本表示法，對其他對象使用關聯線。
?
UML
操作與方法
P186 UML
操作是聲明，
其中包括名稱、參數、返回類型、異常列表、可能的前置和后置條件約束等。但是操作不是實現，而方法是實現。
?
UML
方法（
method
）是操作的實現。表示方法：
l????????
在交互圖中，通過消息的細節和順序來表示。
l????????
在類圖中，使用構造型為
<<method>>
的
UML
注解符號
?
類元：
是“描述行為和結構特性的模型元素”
[OMG03b]
。類元也可以被特化。它們（指類元）是對眾多
UML
元素（指被特化的類元）的泛化。這些元素包括類、接口、用例和參與者。在類圖中，最常用的兩個類元是常規的類和接口。（泛化和特化看上去像是一對反義詞）
?
泛化
泛化（
generalization
）
用由子類到超類的
-----|>
表示。
UML
對泛化的定義：
泛化——普通的類元與特殊的類元之間的分類學關系。特殊類元的每個實例也是普通類元的間接實例。因此，特殊類元間接的擁有了普通類元的特性。
?
P298
泛化
是識別概念之間的共性部分并定義超類（泛化概念）和子類（特化概念）關系的活動。它是在概念間構建分類的方法，這些概念將在類層次結構中加以描述。
泛化與繼承
（超類和子類的關系）
對于領域模型，超類是超集，而子類是子集。
對于
DCD
軟件視角的類圖，泛化
=
由超類到子類的
OOPL
（
OO
編程語言）繼承。
?
依賴
UML
中的依賴：
表示客戶（
client
）元素
（任何種類，包括類、包、用例等）了解其他的提供者（
supplier
）元素
，并且表示當提供者有所改變時會對客戶產生影響。
?
在對象圖和類圖中比較常見的類型：
l????????
擁有提供者類型的屬性（通過表示屬性的關聯線表示）
l????????
向提供者發送消息。對提供者的可見性可能是：屬性、參數變量、局部變量、全局變量或類的可見性（調用靜態或類的方法）
√
l????????
接收提供者類型的參數
√
l????????
提供者
是超類或接口（通過表示泛化的線表示）
√
表示需要使用依賴線
不需要使用依賴線
的情況：
l????????
表示超類的特殊的
UML
類
l????????
表示接口實現的線
l????????
表示屬性的線（以關聯表示屬性的線）
?
何時使用依賴線
在類圖中，使用依賴線描述對象之間的全局變量、參數變量、局部變量和靜態方法（對其他類的靜態方法加以調用）的依賴。
?
依賴與耦合
依賴可視為耦合（
coupling
）的另一個版本
，耦合是軟件開發中的傳統術語，意為某元素耦合或依賴于另一個元素。
?
耦合是對某元素與其他元素之間的連接、感知和依賴程度的度量（
P216
）。
組合（
composition
）：
1
）在某一時刻，部分的實例只屬于一個組成實例；
2
）部分必須總是屬于組成（不存在隨意游離的
Fingers
）；
3
）組成要復雜創建和刪除其部分，既可以自己來創建
/
刪除部分，也可以與其他對象協作來創建
/
刪除部分。
◆----表示擁有-部分
?
限定關聯：
一般來說，在軟件透視圖中，限定關聯暗示了基于鍵對事物進行查找，如
HashMap
中的對象。
?
UML
表示靜態類成員
UML
表示法：在類框圖中，具有下劃線的屬性或方法表示靜態類（類級別）成員，而不是實例成員。
Instance
：
ServicesFactory
，
getInstance
（）：
ServicesFactory
?