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