【正文】 　組合 整體與部分具有同樣的生存期，是一種特殊形式的聚集。泛化關(guān)系，一般和特殊元素之間的關(guān)系，就是平常所說的繼承關(guān)系。 狀態(tài)圖和活動(dòng)圖　　狀態(tài)圖　　描述 對象 生存期間的 動(dòng)態(tài)行為，所經(jīng)歷的狀態(tài)序列，引起狀態(tài)轉(zhuǎn)移的 事件、動(dòng)作。　　是 UML 動(dòng)態(tài)行為建模的 5個(gè)圖之一，用 狀態(tài)機(jī) 對一個(gè)對象的生命周期建模，狀態(tài)圖 用于顯示狀態(tài)機(jī)，重點(diǎn)在于 狀態(tài)之間的控制流。　　除了 初態(tài)和終態(tài)，還有 Idle 和 Running 兩個(gè)狀態(tài)，keyPress、finished、shutDown 是事件?！　』顒?dòng)圖　　是 UML 動(dòng)態(tài)行為建模的 5個(gè)圖之一，描述系統(tǒng)的 工作流程 和 并發(fā)行為。狀態(tài)圖的特殊形式，一個(gè)活動(dòng)結(jié)束后將立即進(jìn)入下一個(gè)活動(dòng)?！　』靖拍睿夯顒?dòng)、泳道、分支、分叉、匯合、對象流?！　?，注意區(qū)分 動(dòng)作狀態(tài) 和 活動(dòng)狀態(tài)，動(dòng)作狀態(tài)是原子的，沒有內(nèi)部轉(zhuǎn)移，沒有內(nèi)部活動(dòng)，所占用的時(shí)間可以忽略，目的是執(zhí)行進(jìn)入動(dòng)作，然后轉(zhuǎn)向另一個(gè)狀態(tài)?！　』顒?dòng)狀態(tài)是可分解的，工作完成需要一定的時(shí)間?！　?，是活動(dòng)圖中區(qū)域劃分，每個(gè)泳道代表一個(gè)責(zé)任區(qū)，知道和類并不是一一對應(yīng)的關(guān)系?！　?，同一個(gè)觸發(fā)事件，可以根據(jù)不同的警戒條件轉(zhuǎn)向不同的活動(dòng)，每個(gè)可能的轉(zhuǎn)移是一個(gè)分支?！　。绻硎?系統(tǒng)或?qū)ο笾械牟l(fā)行為，使用分叉fork 和 匯合join，匯合正好與分叉相反。，活動(dòng)圖中可以出現(xiàn)對象，對象可用作為活動(dòng)的輸入輸出?；顒?dòng)圖中的對象流表示活動(dòng)和對象之間的關(guān)系。 構(gòu)件圖　　構(gòu)件是系統(tǒng)中 遵從一組接口 且提供其實(shí)現(xiàn)的 物理的、可替換 的部分?！　?gòu)件圖 顯示一組構(gòu)件 以及它們 之間的相互關(guān)系，包括 編譯、連接、執(zhí)行時(shí) 構(gòu)建之間的依賴關(guān)系?！　?gòu)件就是一個(gè)實(shí)際文件，以下幾種類型：　　部署構(gòu)建　　工作產(chǎn)品構(gòu)件　　執(zhí)行構(gòu)件　　構(gòu)件圖可以對以下幾個(gè)方面建模：　　對源代碼文件之間的相互關(guān)系建模。對可執(zhí)行文件之間的相互關(guān)系建模。 部署圖　　部署圖 也稱 配置圖、實(shí)施圖，顯示系統(tǒng)中計(jì)算節(jié)點(diǎn)的 拓?fù)浣Y(jié)構(gòu)、通信路徑、節(jié)點(diǎn)上運(yùn)行的軟構(gòu)件等?！　∫粋€(gè)系統(tǒng)模型只有一個(gè)部署圖，常用語幫助理解分布式系統(tǒng)。部署圖 由 體系結(jié)構(gòu)設(shè)計(jì)師、網(wǎng)絡(luò)工程師、系統(tǒng)工程師 等 描述。 基于 UML 的軟件開發(fā)過程 開發(fā)過程概述　　UML 是獨(dú)立于軟件開發(fā)過程的，能夠在幾乎任何一種軟件開發(fā)過程中使用。迭代的漸進(jìn)式軟件開發(fā)過程包含四個(gè)階段：初啟、細(xì)化、構(gòu)件、部署。　　初啟　　項(xiàng)目的發(fā)起人 確定項(xiàng)目的 主要目標(biāo) 和 范圍，初步的可行性分析 和 經(jīng)濟(jì)效益分析?！　〖?xì)化　　細(xì)化階段的開始 標(biāo)志著 項(xiàng)目的正式確立?！　?，比較重要、比較有風(fēng)險(xiǎn)的用例。　　，用例、用例圖、類、類圖 將 依據(jù) 包 的劃分方法 分屬于 不同包?！　?，根據(jù)軟件元素 的重要性和風(fēng)險(xiǎn)程度 確立優(yōu)先細(xì)化原則，不能將風(fēng)險(xiǎn)的識(shí)別和解決延遲到細(xì)化階段后?！　??！　?gòu)建　　構(gòu)造階段，每次迭代中實(shí)現(xiàn)一部分用例，用戶可以及早參與對已實(shí)現(xiàn)用例的實(shí)際評價(jià)?！　≡瓌t：　　 應(yīng) 優(yōu)先安排?！　?認(rèn)為 開發(fā)風(fēng)險(xiǎn)較高的用例 優(yōu)先 安排。迭代計(jì)劃中，要確定迭代次數(shù)、每次迭代所需時(shí)間 以及 每次迭代中應(yīng)完成的用例。 基于 UML 的需求分析　　生成用例　　如果多個(gè)用戶扮演同一角色，這些用戶將由單一執(zhí)行者表示。如果一個(gè)用戶扮演多種角色，則需要多個(gè)執(zhí)行者來表示同一用戶?！　∮美饕獊碓从诜治鋈藛T對 場景的 分類和抽象，即將相似的場景進(jìn)行歸類，使一個(gè)用例可以通過實(shí)例化和參數(shù)調(diào)節(jié)而涵蓋多個(gè)場景?！　∮没顒?dòng)圖表示用例　　生成用例圖　　執(zhí)行者與用例之間的關(guān)系有兩種：觸發(fā)執(zhí)行、信息交換。　　執(zhí)行者指向用例 表示 觸發(fā)執(zhí)行 和/或 信息交換，用例指向執(zhí)行者 表示用例將生成的信息傳遞給執(zhí)行者?！　〗㈨攲蛹軜?gòu)　　頂層架構(gòu)便于開發(fā)人員 聚焦于系統(tǒng)的不同部分?！　∧Ｐ汀晥D——控制器(Model、View、Controller，MVC)模式。　　模型 維護(hù)并保存數(shù)據(jù)，視圖 呈現(xiàn)數(shù)據(jù)，控制器將動(dòng)作映射為處理功能并實(shí)際調(diào)用?！　VC 模式特別適合于分布式應(yīng)用軟件，尤其是web應(yīng)用系統(tǒng)?！　》謱幽Ｊ?降低軟件系統(tǒng)的 耦合度。　　確立頂層架構(gòu)的過程中需綜合考慮以下因素：　　包的數(shù)量，架構(gòu)過早地陷入細(xì)節(jié)，返工的可能性很大，也不合理地限制了后續(xù)分析和設(shè)計(jì)活動(dòng)的自由空間?！　“g的耦合度?！　⒉环€(wěn)引起的軟件元素分類聚集于少數(shù)幾個(gè)包中，以提高軟件系統(tǒng)的可維護(hù)性?！　】蛇x功能 和 必須實(shí)現(xiàn)的功能 置于 不同的包。根據(jù)開發(fā)人員 專長 劃分，使每個(gè)包都能分配給最合適的開發(fā)人員，有利于并行開發(fā)。 面向?qū)ο蟮脑O(shè)計(jì)方法　　設(shè)計(jì)用例實(shí)現(xiàn)方案　　，實(shí)現(xiàn)類和控制類?！　∵吔珙愑糜诿枋?系統(tǒng)與外部環(huán)境之間的交互?！　??！　?。　　。使目標(biāo)軟件系統(tǒng)的 其余部分 盡可能地 獨(dú)立于環(huán)境軟件。　　邊界類，《boundary》?！　?shí)體類“內(nèi)向收斂”特征，僅提供 讀/寫 信息的必要操作 作接口，并不涉及業(yè)務(wù)邏輯處理，《entity》?！　】刂祁?，《control》?！　∵吔珙惖淖饔梅秶梢猿絾蝹€(gè)用例　　交互圖作為用力的精確實(shí)現(xiàn)方案。　　事件流中的事件 直接對應(yīng)交互圖中的消息，事件間的先后關(guān)系體現(xiàn)為 交互圖中的時(shí)序，對消息的響應(yīng) 則構(gòu)成消息接收者的職責(zé)，這種職責(zé)被確立為 類的方法?！　〔粦?yīng)該出現(xiàn) 穿越控制類 生命線 的消息。　　為 易于理解，應(yīng)該用分離的 UML 交互圖 分別表示 事件流和每個(gè)備選事件流?！　≡瓌t上，每個(gè)類都應(yīng)該有一個(gè)操作來響應(yīng)交互圖中指向其對象的那條消息。　　設(shè)計(jì)技術(shù)支撐方案　　當(dāng)用戶需求發(fā)生變化時(shí)，技術(shù)支撐方案應(yīng)具有良好的穩(wěn)定性?！　〖夹g(shù)支撐方案應(yīng)該位于層次結(jié)構(gòu)中的較低層次?！　∫环矫嫒Q于 需求，另一方面取決于 對軟件技術(shù)手段把我和選取?！　≡O(shè)計(jì)用戶界面　　 并對 用戶分類，以便盡量照顧到所有用戶的合理要求，并優(yōu)先滿足某些特權(quán)用戶?！　?分析用戶的 工作流與習(xí)慣，從每類中選取一個(gè)用戶代表，建立調(diào)查表，判斷用戶對操作界面的需求和喜好?！　。话愠Ｓ妹罹酉?，與用戶工作習(xí)慣保持一致。其次，根據(jù)外部服務(wù)之間的聚合關(guān)系組織相應(yīng)的命令。然后充分考慮人類記憶的局限性，最好組織為一顆兩層多叉樹。提供操作的快捷方式?！　?，改進(jìn)界面設(shè)計(jì)。并評判系統(tǒng)是否 齊全、方便、好用。　　精化設(shè)計(jì)模型　　對模型進(jìn)行改進(jìn)的活動(dòng)可以分為 精化 和 合并 兩種。一般先從精化開始。設(shè)計(jì)優(yōu)秀的粗粒度組件應(yīng)該只是完成一項(xiàng)功能，這一點(diǎn)是它與子系統(tǒng)的主要區(qū)分。　　粗粒度組件的范圍過于廣泛，難以發(fā)揮重用價(jià)值，粗粒度組件擁有持久化的行為，擁有業(yè)務(wù)邏輯，需要表示層的支持?！　⑿枨蠓殖蓭讉€(gè)功能組，基本上就可以得到相應(yīng)的粗粒度組件了?！　∵^小的范圍，將會(huì)造成粗粒度組件不容易使用，用戶需要理解不同的粗粒度組件之間的復(fù)雜關(guān)系?！　∪绻赡?，在粗粒度組件之間定義單項(xiàng)關(guān)聯(lián)可以有效的減少組件之間的耦合。　　盡可能簡化組件之間的關(guān)系?！　∥覀冃枰獜能浖哪繕?biāo)領(lǐng)域中 識(shí)別出關(guān)鍵性的實(shí)體，或者說領(lǐng)域中的名詞。然后決定它們應(yīng)該歸屬于那些粗粒度組件。兩個(gè)組件之間存在重復(fù)的要素，可以從中抽取共性的部分，形成新的組件。 系統(tǒng)架構(gòu)文檔化 模型概述　　以精心選擇的形式 將若干結(jié)構(gòu)元素進(jìn)行裝配?！　≤浖軜?gòu) = { 元素，形式，關(guān)系/約束 }　　邏輯視圖(logical view)對象模型?！　∵^程視圖(process view)并發(fā)和同步特征?！　∥锢硪晥D(physical view)分布式?！　￠_發(fā)視圖(development view)靜態(tài)組織結(jié)構(gòu)?！　ational 視圖模型。　　每個(gè)視圖上均獨(dú)立地應(yīng)用 Perryamp。Wolf 軟件架構(gòu)公式。對每種視圖選用特定的 架構(gòu)風(fēng)格(architectural style)。 邏輯結(jié)構(gòu)　　邏輯架構(gòu)主要支持功能性需求，系統(tǒng)分解為一系列的關(guān)鍵抽象，(大多數(shù))來自于問題域，表現(xiàn)為對象或?qū)ο箢惖男问??！　〕橄蟆⒎庋b、繼承。　　對于數(shù)據(jù)驅(qū)動(dòng)程度高的應(yīng)用程序，可以使用其他形式的邏輯視圖，如 ER圖 代替面向?qū)ο蟮姆椒??！　∵壿嬕晥D的風(fēng)格采用面向?qū)ο蟮娘L(fēng)格，試圖在整個(gè)系統(tǒng)中 保持 單一的、一致的 對象模型。 進(jìn)程架構(gòu)　　進(jìn)程架構(gòu)考慮一些非功能性的需求，并發(fā)性、分布性、系統(tǒng)完整性、容錯(cuò)性，以及邏輯視圖的主要抽象如何與進(jìn)程結(jié)構(gòu)相配合在一起?！　∵M(jìn)程是 構(gòu)成可執(zhí)行單元任務(wù)的分組。區(qū)分主要次要任務(wù)：主要任務(wù)是 可以唯一處理的架構(gòu)元素。次要任務(wù)是 由于實(shí)施原因而引入的局部附加任務(wù)。 開發(fā)架構(gòu)　　開發(fā)架構(gòu)關(guān)注軟件開發(fā)環(huán)境下實(shí)際模塊的組織?！　￠_發(fā)架構(gòu)用模塊和子系統(tǒng)圖來表達(dá)，顯示了“輸出”和“輸入”關(guān)系。　　考慮因素：開發(fā)難度、軟件管理、重用性、通用性、由工具集、語言 所帶來的限制?！　￠_發(fā)視圖 是建立產(chǎn)品線的 基礎(chǔ)。推薦使用分層(layered)的風(fēng)格，每層具有良好定義的職責(zé)。某層子系統(tǒng)依賴同一層或低一層的子系統(tǒng)，最大程度地減少了具有復(fù)雜模塊依賴關(guān)系的 網(wǎng)絡(luò)的開發(fā)量 物理架構(gòu)　　物理架構(gòu)主要關(guān)注系統(tǒng)非功能性的需求，可用性、可靠性(容錯(cuò)性)，性能(吞吐量)、可伸縮性?！　≤浖凉?jié)點(diǎn)的映射需要高度的靈活性 及 對源代碼產(chǎn)生最小的影響。 場景　　4種視圖的元素通過數(shù)量比較少的一組重要場景(更常見的是用例)進(jìn)行無縫協(xié)同工作，我們?yōu)閳鼍懊枋鱿鄳?yīng)的腳本(對象之間和過程之間的交互序列)。　　在某種意義上 場景是最重要的 需求抽象。　　4+1 的 +1 起到了兩個(gè)作用：　　作為一項(xiàng)驅(qū)動(dòng)因素 來發(fā)現(xiàn)架構(gòu)設(shè)計(jì)過程中的 架構(gòu)元素。　　作為架構(gòu)原型測試的出發(fā)點(diǎn)?！　鼍氨硎痉ㄅc組件邏輯視圖非常相似，但它使用過程視圖的連接符來表示對象之間的交互。 迭代過程　　在進(jìn)行文檔化時(shí)，提倡一種更具有迭代性質(zhì)的方法——架構(gòu)先被原型化、測試、估量、分析，然后在一系列的迭代過程中被細(xì)化。　　除了減少 風(fēng)險(xiǎn)之外，還有其他優(yōu)點(diǎn)：團(tuán)隊(duì)合作、培訓(xùn)、加深對架構(gòu)的理解、深入程序和工具 等。使 需求被細(xì)化、成熟化?！　∠到y(tǒng)大多數(shù)關(guān)鍵的功能以場景的形式被捕獲，關(guān)鍵意味著：最重要的功能、系統(tǒng)存在的理由、使用頻率最高的功能、必須減輕的一些重要技術(shù)風(fēng)險(xiǎn)。7 2011年軟考系統(tǒng)架構(gòu)設(shè)計(jì)師學(xué)習(xí)筆記第七章 設(shè)計(jì)模式概述　　重復(fù)遇到的典型問題，描述這些共同問題和解決這些問題的方案 就形成了所謂的模式。 設(shè)計(jì)模式的歷史　　模式分為幾個(gè)部分：　　特定的情景(Context)，指模式在 何種情況下發(fā)生作用。　　動(dòng)機(jī)(System of Force)，指問題或預(yù)期的目標(biāo)?！　〗鉀Q方案(Solution)，平衡各動(dòng)機(jī) 或解決所闡述問題的 構(gòu)造或配置。每個(gè)模式描述了一個(gè)在某種特定情境下不斷重復(fù)發(fā)生的問題，以及解決該問題解決方案的核心所在。 為什么要使用設(shè)計(jì)模式　　面向?qū)ο笤O(shè)計(jì)時(shí)需要考慮 封裝性、力度大小、依賴關(guān)系、靈活性、可重用性 等?！　『喕⒓涌炜煸O(shè)計(jì)　　無需從底層做起，重用成功的設(shè)計(jì)，節(jié)約開發(fā)時(shí)間，提高軟件質(zhì)量?！　》奖汩_發(fā)人員之間的通信　　可以更準(zhǔn)確地 描述問題 及 問題的解決方案，使解決方案具有一致性?！　〗档惋L(fēng)險(xiǎn)　　有助于轉(zhuǎn)到面向?qū)ο蠹夹g(shù)　　開發(fā)人員對新技術(shù)往往會(huì)有抵觸或排斥心理，對成熟的設(shè)計(jì)模式具有以下特性：　　?！　。灰蕾囉?系統(tǒng)、語言、領(lǐng)域?！　??！　　！　　?設(shè)計(jì)模式的組成元素　　模式名，簡潔地描述了 模式的本質(zhì)，可以幫助我們思考?！　栴}或意圖，解釋了設(shè)計(jì)問題和問題存在的前因后果，可能描述了特定的設(shè)計(jì)問題?！　∏榫?，告訴我們該模式的適用性?！　?dòng)機(jī)，描述相關(guān)的動(dòng)機(jī)和約束，通常需要對各期望的目標(biāo)進(jìn)行有限排序，動(dòng)機(jī)闡明了問題的復(fù)雜性，定義了在相互沖突時(shí)所采取的各種權(quán)衡手段?！　〗鉀Q方案，因?yàn)槟Ｊ骄拖褚粋€(gè)模板，所以解決方案并不描述一個(gè)特定而具體的設(shè)計(jì)或?qū)崿F(xiàn)，而是提供設(shè)計(jì)問題的 抽象描述 和怎樣用一個(gè) 具有一般意義的 元素組合?！　∈纠?，幫助讀者理解模式的具體使用方法?！　〗Y(jié)果情景，闡述了模式后續(xù)狀態(tài)和副作用。　　基本原理，解釋該模式 如何、為何 能解決當(dāng)前問題?！　∠嚓P(guān)模式，包括 靜態(tài)的 和 動(dòng)態(tài)的，遷到模式、后續(xù)模式、替代模式?！　∫阎獞?yīng)用，通常好的模式前面都有一個(gè)摘要，提供簡短的總結(jié)和概述，為模式描繪出一個(gè)清晰的圖畫，提供有關(guān)該模式能夠解決問題的快速信息。　　新技術(shù)可能帶來的效果持懷疑態(tài)度。模式應(yīng)該說明它的目標(biāo)讀者，以及對讀者有哪些知識(shí)要求。 設(shè)計(jì)模式的分類　　軟件模式 主要可分為 設(shè)計(jì)模式、分析模式、組織和過程模式等。　　設(shè)計(jì)模式主要用于 得到簡潔靈活的 系統(tǒng)設(shè)計(jì)?！　“丛O(shè)計(jì)模式的目的劃分，創(chuàng)建型、結(jié)構(gòu)型、行為型?！　“丛O(shè)計(jì)模式范圍劃分，類設(shè)計(jì)模式、對象設(shè)計(jì)模式。　　創(chuàng)建型模式，對對象實(shí)例化過程的 抽象，采用抽象類所定義的接口，封裝了對象如何創(chuàng)建、組合等信息?！　〗Y(jié)構(gòu)型模式，如何組合已有的類和對象 以及獲得更大的結(jié)構(gòu)。行為型模式，不僅描述對象或類的模式，還描述它們之間的通信模式，特別是描述一組對等的對象怎樣互相協(xié)作 完成其中任一對象無法單獨(dú)完成的任務(wù)。 設(shè)計(jì)模式實(shí)例 創(chuàng)建性模式　　通過該了的子類來創(chuàng)建對象的。但是，這可能會(huì) 限制在系統(tǒng)內(nèi)創(chuàng)建對象的類型或數(shù)目?！　bstract Factory 模式　　在不指定具體類的情況下，為創(chuàng)建一些列 相關(guān) 或 相互依賴的對象提供了接口?！　√峁┝艘粋€(gè)可以 確定合適的具體類 的抽象類。　　優(yōu)點(diǎn)：　　可以與具體類分開?！　「菀自诋a(chǎn)品系列中轉(zhuǎn)換