《UML和模式應(yīng)用》讀書筆記

第一部分 緒論

1、在OO開發(fā)中，至關(guān)重要的能力是熟練地為軟件對(duì)象分配職責(zé)；個(gè)人認(rèn)為將對(duì)象進(jìn)行抽象的能力也相當(dāng)重要。

2、分析(analysis)強(qiáng)調(diào)的是對(duì)問題和需求的調(diào)查研究，而不是解決方案；設(shè)計(jì)(design)強(qiáng)調(diào)的是滿足需求的概念上的解決方案(在軟件方面和硬件方面)，而不是其實(shí)現(xiàn)。

有益的分析和設(shè)計(jì)可以概括為：做正確的事（分析）和正確地做事（設(shè)計(jì)）。

3、需求分析可能包括人們?nèi)绾问褂脩?yīng)用的情節(jié)或場(chǎng)景，這些情節(jié)或場(chǎng)景可以被編寫成用例（use case）。

4、面向?qū)ο蠓治鲫P(guān)注從對(duì)象的角度創(chuàng)建領(lǐng)域描述，面向?qū)ο蠓治鲂枰�鑒別重要的概念、屬性和關(guān)聯(lián)。面向?qū)ο蠓治龅慕Y(jié)果可以表示為領(lǐng)域模型，在領(lǐng)域模型中展示重要的領(lǐng)域概念或?qū)ο蟆?/p>

5、面向?qū)ο笤O(shè)計(jì)關(guān)注軟件對(duì)象的定義-它們的職責(zé)和協(xié)作。

6、與領(lǐng)域模型表示的是真實(shí)世界的類，設(shè)計(jì)類圖表示的是軟件類。

7、敏捷建模（agile modeling）強(qiáng)調(diào)了UML作為草圖的方式，這也是適用UML的普通方式，而且通常對(duì)時(shí)間投入具有高回報(bào)（一般費(fèi)時(shí)較短）。

8、迭代開發(fā)（iterative development）是UP和大多數(shù)其他現(xiàn)代方法中的關(guān)鍵實(shí)踐。在這種生命周期方法中，開發(fā)被組織成一系列固定的短期（如三個(gè)星期）小項(xiàng)目，稱為迭代（iteration），每次迭代都產(chǎn)生經(jīng)過測(cè)試、集成并可執(zhí)行的局部系統(tǒng)。每次迭代都具有各自的需求分析、設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試活動(dòng)。

9、迭代開發(fā)的優(yōu)點(diǎn)包括：

• 減少項(xiàng)目失敗可能性，提高生產(chǎn)率，降低缺陷率。
• 在早期緩解高風(fēng)險(xiǎn)（技術(shù)、需求、目標(biāo)、可用性等等）。
• 早期可見的進(jìn)展。
• 早期反饋、用戶參與和調(diào)整，會(huì)產(chǎn)生更接近涉眾真實(shí)需求的精化系統(tǒng)。
• 可控復(fù)雜性；團(tuán)隊(duì)不會(huì)被“分析癱瘓”或長期且復(fù)雜的步驟所淹沒。
• 一次迭代中的經(jīng)驗(yàn)可以被系統(tǒng)地用于改進(jìn)開發(fā)過程本身，并如此反復(fù)進(jìn)行下去。

10、在復(fù)雜、變更系統(tǒng)中（如大多數(shù)軟件項(xiàng)目），反饋和調(diào)整是成功的關(guān)鍵要素。

11、如何進(jìn)行迭代和進(jìn)化式分析和設(shè)計(jì)：

1）在第1次迭代之前，召開第一個(gè)時(shí)間定量的需求工作會(huì)議，例如確切地定義為兩天時(shí)間，業(yè)務(wù)和開發(fā)人員（包括首席架構(gòu)師）需要出席。

• 在第一天上午，進(jìn)行高階需求分析，例如僅僅確定用例和特性的名稱，以及關(guān)鍵的非功能性需求。這種分析不可能是完美的。
• 透過咨詢首席架構(gòu)師和業(yè)務(wù)人員，從高階列表中選擇10%列表項(xiàng)，這些項(xiàng)目具備以下三種性質(zhì)：1，具有重要的架構(gòu)意義；2，具有高業(yè)務(wù)價(jià)值；3，具有高風(fēng)險(xiǎn)。
• 在剩下的一天半內(nèi)，對(duì)這三個(gè)用例的功能和非功能性需求進(jìn)行詳細(xì)的分析。完成這一過程后，對(duì)10%進(jìn)行了深入分析，90%進(jìn)行了高階分析。

2）在第1次迭代之前，召開迭代計(jì)劃會(huì)議，選擇上述三個(gè)用例的子集，在特定時(shí)間內(nèi)（例如，四周的時(shí)間定量迭代）進(jìn)行設(shè)計(jì)、構(gòu)造和測(cè)試。

3）在三到四周內(nèi)完成第1次迭代（選擇時(shí)間定量，并嚴(yán)格遵守時(shí)間）：

• 在開始的兩天內(nèi)，開發(fā)者和其他成員分組進(jìn)行建模和設(shè)計(jì)工作，在首席架構(gòu)師德帶領(lǐng)和指導(dǎo)下，于“公共作戰(zhàn)室”的眾多白板上，畫出UML的草圖（及其他的模型）。
• 然后，開發(fā)者摘掉其“建模帽子”并戴上“編程帽子”，開始編程、測(cè)試和集成工作并且剩余的時(shí)間均用于完成這項(xiàng)工作。
• 進(jìn)行大量的測(cè)試，包括單元測(cè)試、驗(yàn)收測(cè)試、負(fù)載測(cè)試和可用性測(cè)試等。
• 在結(jié)束前的一周，檢查是否能夠完成初始的迭代目標(biāo)；如果不能，則縮小迭代的范圍，將次要目標(biāo)置回任務(wù)列表中。
• 在最后一周的星期二，凍結(jié)代碼。必須檢入、集成和測(cè)試所有代碼，以建立迭代的基線。
• 在星期三的上午，向外部涉眾演示此局部系統(tǒng)，展示早期可視進(jìn)展，同時(shí)要求反饋。

4）在第1次迭代即將結(jié)束時(shí)（如最后一周的星期三和星期四），召開第二次需求工作會(huì)，對(duì)上一次會(huì)議的所有材料進(jìn)行復(fù)查和精化，然后選擇具有重要架構(gòu)意義和高業(yè)務(wù)價(jià)值的另外10%到15%的用例，用一到兩天對(duì)其進(jìn)行詳細(xì)分析。

5）于周五上午，舉行下一迭代的迭代計(jì)劃會(huì)議。

6）以相同步驟進(jìn)行第2次迭代。

7）反復(fù)進(jìn)行四次迭代和五次需求工作會(huì)，這樣在第4次迭代結(jié)束時(shí)，可能已經(jīng)詳細(xì)記錄了大約80%-90%的需求。

8）我們大概推進(jìn)了整個(gè)項(xiàng)目過程的20%。此時(shí)，可以估計(jì)這些精化的、高質(zhì)量的需求所需工作量和時(shí)間。因?yàn)榫哂幸罁?jù)現(xiàn)實(shí)得出的調(diào)查、反饋結(jié)論并進(jìn)行了早期編程和測(cè)試，因此估計(jì)能夠做什么和需要多長時(shí)間的結(jié)果會(huì)更為可靠。

9）此后，一般不需要再召開需求工作會(huì)；需求已經(jīng)穩(wěn)定了（盡管需求永遠(yuǎn)不會(huì)被凍結(jié)）。接下來是一系列為期三周的迭代，在最后一個(gè)周五召開的迭代計(jì)劃會(huì)上選擇適宜的下一步工作，每次迭代都要反復(fù)詢問：“就我們現(xiàn)在所知，下一個(gè)三周應(yīng)該完成的、最關(guān)鍵的技術(shù)和業(yè)務(wù)特性是什么？”

利用這種方式，經(jīng)過早期探索式開發(fā)的幾次迭代之后，團(tuán)隊(duì)將能夠更準(zhǔn)確地回答“什么、多少、何時(shí)”。

12、建模（構(gòu)建UML草圖……）的目的主要是為理解，而非文檔。

第二部分 初始階段

1、用一句話來概括初始階段：預(yù)見項(xiàng)目的范圍、設(shè)想和業(yè)務(wù)案例。用一句話來概括初始階段要解決的主要問題：涉眾是否就項(xiàng)目設(shè)想基本達(dá)成一致，項(xiàng)目是否值得繼續(xù)進(jìn)行認(rèn)真研究。

2、需求分析的最大挑戰(zhàn)是尋找、溝通和記�。ㄍǔＪ侵赣涗洠┦裁词钦嬲�需要的，并能夠清楚地講解給客戶和開發(fā)團(tuán)隊(duì)的成員。

3、在統(tǒng)一過程中，需求按照“FURPS+”模型進(jìn)行分類，這是一中有效的記憶方法，其含義如下：

• 功能性（Funcational）：特性、功能、安全性。
• 可用性（Usability）：人性化因素、幫助、文檔。
• 可靠性（Reliability）：故障頻率、可恢復(fù)性、可預(yù)測(cè)性。
• 性能（Performance）：響應(yīng)時(shí)間、吞吐量、準(zhǔn)確性、有效性、資源利用率。
• 可支持性（Supportability）：適用性、可維護(hù)性、國際化、可配制性。

”FURPS+“中的”+“是指一些輔助性的和次要的因素，比如：

• 實(shí)現(xiàn)（Implementation）：資源閑置、語言和工具、硬件等。
• 接口（Interface）：強(qiáng)加于外部系統(tǒng)接口之上的約束。
• 操作（Operation）：對(duì)其操作設(shè)置的系統(tǒng)管理。
• 包裝（Packaging）：例如無力的包裝盒。
• 授權(quán)（Legal）：許可證或其他方式。

若想從生活中得到什么，必不可少的第一步就是：決定想要什么。 -本。斯坦(Ben Stein)

4、用例是文本形式的情節(jié)描述，廣泛應(yīng)用于需求的發(fā)現(xiàn)和記錄工作中。

5、用例是一種優(yōu)秀的方法，使領(lǐng)域?qū)＜一蛐枨筇峁┱咦约壕帉懀ɑ騾⑴c編寫）用例成為可能，并使這項(xiàng)工作難度降低。

第三部分 細(xì)化迭代1 基礎(chǔ)

1、細(xì)化（elaboration）是一般項(xiàng)目中最初的一系列迭代，其中包括：

• 對(duì)核心、有風(fēng)險(xiǎn)的軟件架構(gòu)進(jìn)行編程和測(cè)試。
• 發(fā)現(xiàn)并穩(wěn)定需求的主體部分。
• 規(guī)避主要風(fēng)險(xiǎn)。

細(xì)化階段是最初的一系列迭代，在這一階段，小組進(jìn)行細(xì)致的調(diào)查、實(shí)現(xiàn)（編程和測(cè)試）核心架構(gòu)、澄清大多數(shù)需求和應(yīng)對(duì)高風(fēng)險(xiǎn)問題。

2、在細(xì)化階段可能出現(xiàn)的一些關(guān)鍵思想和最佳實(shí)踐包括：

• 實(shí)行短時(shí)間定量、風(fēng)險(xiǎn)驅(qū)動(dòng)的迭代。
• 及早開始編程。
• 對(duì)架構(gòu)的核心和風(fēng)險(xiǎn)部分進(jìn)行適應(yīng)性的設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試。
• 盡早、頻繁、實(shí)際地測(cè)試。
• 基于來自測(cè)試、用戶、開發(fā)者的反饋進(jìn)行調(diào)整。
• 通過一系列討論會(huì)，詳細(xì)編寫大部分用例和其他需求，每個(gè)細(xì)化迭代舉行一次。

3、通過關(guān)聯(lián)而不是屬性來表示概念類之間的關(guān)系。

4、沒有所謂唯一正確的領(lǐng)域模型。所有模型都是對(duì)我們?cè)噲D要理解的領(lǐng)域的近似。領(lǐng)域模型主要是在特定群體中用于理解和溝通的工具。

5、在同一層內(nèi)的對(duì)象在職責(zé)上應(yīng)該具有緊密關(guān)聯(lián)，不同層中對(duì)象的職責(zé)則不應(yīng)該混淆。

6、需要哪些對(duì)象，它們?nèi)绾瓮ㄟ^消息和方法進(jìn)行協(xié)作，通過動(dòng)態(tài)對(duì)象建模（例如繪制順序圖）才能真正落實(shí)這些準(zhǔn)確和詳細(xì)的結(jié)論。

7、應(yīng)該把時(shí)間花費(fèi)在交互圖（順序圖或通信圖），而不僅是類圖上。

8、任何順序圖都可以使用sd圖框圍繞起來，并對(duì)其命名。當(dāng)你想要引用相應(yīng)名字的sd圖框時(shí)，可以使用ref圖框。

9、在類圖中，使用依賴線描述對(duì)象之間的全局變量、參數(shù)變量、局部變量和靜態(tài)方法（對(duì)其他類的靜態(tài)方法加以調(diào)用）的依賴。

10、GRASP是通用職責(zé)分配軟件模式（General Responsibility Assignment Software Patterns）的縮寫。GRASP的9個(gè)模式如下所示：

創(chuàng)建者（Creator）

如果以下的條件之一（越多越好）為真時(shí)，將創(chuàng)建類A實(shí)例的職責(zé)分配給類B：

• B“包含”或組成聚集A。
• B記錄A。
• B直接使用A。
• B具有A的初始化數(shù)據(jù)，并且在創(chuàng)建A時(shí)會(huì)將這些數(shù)據(jù)傳遞給A。因此對(duì)于A的創(chuàng)建而言，B是專家。
• B是對(duì)象A的創(chuàng)建者。

注意：對(duì)象的創(chuàng)建常常具有相當(dāng)?shù)膹?fù)雜性，這時(shí)最好的方法是把創(chuàng)建職責(zé)委派給稱為具體工廠（Concrete Factory）或抽象工廠（Abstract Factory）的輔助類，而不是使用創(chuàng)建者模式所建議的類。

信息專家（Information Expert）

把職責(zé)分配給信息專家，它具有實(shí)現(xiàn)這個(gè)職責(zé)所必需的信息。分配職責(zé)應(yīng)當(dāng)從清晰地描述職責(zé)開始。

注意：由于耦合與內(nèi)聚問題導(dǎo)致某些情況下，專家模式建議的方案并不合適。

低耦合（Low Coupling）

分配職責(zé)，使耦合性盡可能低。利用這一原則來評(píng)估可選方案。

控制器（Controller）

控制器是UI層之上的第一個(gè)對(duì)象，它負(fù)責(zé)接收和處理系統(tǒng)操作消息。 

高內(nèi)聚（High Cohesion）

內(nèi)聚（或更為專業(yè)地說，是功能內(nèi)聚）是對(duì)元素職責(zé)的相關(guān)性和集中度的度量。

多態(tài)性（Polymorphism）

純虛構(gòu)（Pure Fabrication）

間接性（Indirection）

防止變異（Protected Variations）