【正文】 部署圖。描述組成和分布情況。部署圖 節(jié)點(diǎn)表示實(shí)際的計(jì)算機(jī)和設(shè)備，邊表示節(jié)點(diǎn)之間的物理連接，也可以顯示連接的類型及節(jié)點(diǎn)之間的依賴性。　 用例和用例圖　　用例圖 也翻譯為 用況、用按 等，在 UML 中，用例用一個(gè)橢圓表示，往往用 動(dòng)賓結(jié)構(gòu) 或 主謂結(jié)構(gòu) 命名。　　可選的 動(dòng)作序列 和 會(huì)出現(xiàn)異常的動(dòng)作序列。　　用例是代表系統(tǒng)中 各種相關(guān)人員之間 就系統(tǒng)的行為所達(dá)成的契約?！　⌒枨箅A段 用例是 分析人員與客戶溝通的工具 項(xiàng)目規(guī)模估算的依據(jù)。　　設(shè)計(jì)階段 用例是 系統(tǒng)功能設(shè)計(jì)的主要輸入?！　?shí)現(xiàn)階段 用例是 檢測(cè)類型為正確性的文檔?！　”举|(zhì)上，用力分析 是一種功能分解 的技術(shù)?！　⑴c者角色，參與者實(shí)際上并不是系統(tǒng)的一部分?！　∮美g的關(guān)系，泛化、包含、擴(kuò)展 等。　　包含是比較特殊的依賴關(guān)系?！　U(kuò)展，基本用例必須聲明 若干“擴(kuò)展點(diǎn)”，而這些擴(kuò)展用例只能在這些擴(kuò)展點(diǎn)上增加新的行為和含義?！　∮美龍D建模人員可以在途中給某些圖符加上填充色，在語(yǔ)義上，使用填充顏色和不使用填充顏色的模型是 一樣的?！　?交互圖　　描述對(duì)象之間 對(duì)象與參與者之間 動(dòng)態(tài)協(xié)作關(guān)系 協(xié)作過(guò)程中行為次序?！　⊥ǔＣ枋鲇美男袨椋@示該用例中所涉及的對(duì)象 對(duì)象之間的消息傳遞。　　順序圖、協(xié)作圖 之間可以互相轉(zhuǎn)化，一個(gè)用例需要多個(gè)順序圖或協(xié)作圖。　　交互圖可以幫助分析人員 對(duì)照檢查 每個(gè)用例中所描述的 用戶需求，提醒分析人員去補(bǔ)充遺漏的類或方法。　　水平方向?yàn)閷?duì)象維，一般 主要參與者放在最左邊，次要參與者放在最右邊。垂直方向?yàn)闀r(shí)間維?！　?類圖和對(duì)象圖　　一般而言，類的名字是 名詞。　　類之間的關(guān)系 有 關(guān)聯(lián)、聚集、組合、泛化、依賴 等。　　關(guān)聯(lián)，鏈 是關(guān)聯(lián)的實(shí)例，關(guān)聯(lián)表示 類與類之間的關(guān)系，鏈表示 對(duì)象與對(duì)象之間的關(guān)系?！　￡P(guān)聯(lián)用 實(shí)線表示，角色還具有多重性?！　￡P(guān)聯(lián)類 描述關(guān)聯(lián)的 屬性、操作、以及其他信息。　　關(guān)聯(lián)類 通過(guò)一條虛線與關(guān)聯(lián)連接。　　自返關(guān)聯(lián) 又稱 遞歸關(guān)聯(lián)，同一個(gè)類的兩個(gè)對(duì)象間的關(guān)系。兩個(gè)關(guān)聯(lián)端，每個(gè)關(guān)聯(lián)端的角色不同?！　【奂徒M合　　聚集 是一種特殊形式的 關(guān)聯(lián)，類之間整體與部分的關(guān)系?！　〗M合 整體與部分具有同樣的生存期，是一種特殊形式的聚集。泛化關(guān)系，一般和特殊元素之間的關(guān)系，就是平常所說(shuō)的繼承關(guān)系。　 狀態(tài)圖和活動(dòng)圖　　狀態(tài)圖　　描述 對(duì)象 生存期間的 動(dòng)態(tài)行為，所經(jīng)歷的狀態(tài)序列，引起狀態(tài)轉(zhuǎn)移的 事件、動(dòng)作?！　∈?UML 動(dòng)態(tài)行為建模的 5個(gè)圖之一，用 狀態(tài)機(jī) 對(duì)一個(gè)對(duì)象的生命周期建模，狀態(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)、泳道、分支、分叉、匯合、對(duì)象流。　　，注意區(qū)分 動(dòng)作狀態(tài) 和 活動(dòng)狀態(tài)，動(dòng)作狀態(tài)是原子的，沒(méi)有內(nèi)部轉(zhuǎn)移，沒(méi)有內(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ū)，知道和類并不是一一對(duì)應(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)對(duì)象，對(duì)象可用作為活動(dòng)的輸入輸出?；顒?dòng)圖中的對(duì)象流表示活動(dòng)和對(duì)象之間的關(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)件圖可以對(duì)以下幾個(gè)方面建模：　　對(duì)源代碼文件之間的相互關(guān)系建模。對(duì)可執(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è)部署圖，常用語(yǔ)幫助理解分布式系統(tǒng)。部署圖 由 體系結(jié)構(gòu)設(shè)計(jì)師、網(wǎng)絡(luò)工程師、系統(tǒng)工程師 等 描述。　　 基于 UML 的軟件開發(fā)過(guò)程　　 開發(fā)過(guò)程概述　　UML 是獨(dú)立于軟件開發(fā)過(guò)程的，能夠在幾乎任何一種軟件開發(fā)過(guò)程中使用。迭代的漸進(jìn)式軟件開發(fā)過(guò)程包含四個(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)一部分用例，用戶可以及早參與對(duì)已實(shí)現(xiàn)用例的實(shí)際評(píng)價(jià)。　　原則：　　 應(yīng) 優(yōu)先安排?！　?認(rèn)為 開發(fā)風(fēng)險(xiǎn)較高的用例 優(yōu)先 安排。迭代計(jì)劃中，要確定迭代次數(shù)、每次迭代所需時(shí)間 以及 每次迭代中應(yīng)完成的用例?！?基于 UML 的需求分析　　生成用例　　如果多個(gè)用戶扮演同一角色，這些用戶將由單一執(zhí)行者表示。如果一個(gè)用戶扮演多種角色，則需要多個(gè)執(zhí)行者來(lái)表示同一用戶。　　用例主要來(lái)源于分析人員對(duì) 場(chǎng)景的 分類和抽象，即將相似的場(chǎng)景進(jìn)行歸類，使一個(gè)用例可以通過(guò)實(shí)例化和參數(shù)調(diào)節(jié)而涵蓋多個(gè)場(chǎng)景?！　∮没顒?dòng)圖表示用例　　生成用例圖　　執(zhí)行者與用例之間的關(guān)系有兩種：觸發(fā)執(zhí)行、信息交換?！　?zhí)行者指向用例 表示 觸發(fā)執(zhí)行 和/或 信息交換，用例指向執(zhí)行者 表示用例將生成的信息傳遞給執(zhí)行者?！　〗㈨攲蛹軜?gòu)　　頂層架構(gòu)便于開發(fā)人員 聚焦于系統(tǒng)的不同部分。　　模型——視圖——控制器(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)的過(guò)程中需綜合考慮以下因素：　　包的數(shù)量，架構(gòu)過(guò)早地陷入細(xì)節(jié)，返工的可能性很大，也不合理地限制了后續(xù)分析和設(shè)計(jì)活動(dòng)的自由空間?！　“g的耦合度?！　⒉环€(wěn)引起的軟件元素分類聚集于少數(shù)幾個(gè)包中，以提高軟件系統(tǒng)的可維護(hù)性。　　可選功能 和 必須實(shí)現(xiàn)的功能 置于 不同的包。根據(jù)開發(fā)人員 專長(zhǎng) 劃分，使每個(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》?！　】刂祁悾禼ontrol》?！　∵吔珙惖淖饔梅秶梢猿絾蝹€(gè)用例　　交互圖作為用力的精確實(shí)現(xiàn)方案?！　∈录髦械氖录?直接對(duì)應(yīng)交互圖中的消息，事件間的先后關(guān)系體現(xiàn)為 交互圖中的時(shí)序，對(duì)消息的響應(yīng) 則構(gòu)成消息接收者的職責(zé)，這種職責(zé)被確立為 類的方法。　　不應(yīng)該出現(xiàn) 穿越控制類 生命線 的消息?！　?易于理解，應(yīng)該用分離的 UML 交互圖 分別表示 事件流和每個(gè)備選事件流?！　≡瓌t上，每個(gè)類都應(yīng)該有一個(gè)操作來(lái)響應(yīng)交互圖中指向其對(duì)象的那條消息。　　設(shè)計(jì)技術(shù)支撐方案　　當(dāng)用戶需求發(fā)生變化時(shí)，技術(shù)支撐方案應(yīng)具有良好的穩(wěn)定性。　　技術(shù)支撐方案應(yīng)該位于層次結(jié)構(gòu)中的較低層次?！　∫环矫嫒Q于 需求，另一方面取決于 對(duì)軟件技術(shù)手段把我和選取。　　設(shè)計(jì)用戶界面　　 并對(duì) 用戶分類，以便盡量照顧到所有用戶的合理要求，并優(yōu)先滿足某些特權(quán)用戶?！　?分析用戶的 工作流與習(xí)慣，從每類中選取一個(gè)用戶代表，建立調(diào)查表，判斷用戶對(duì)操作界面的需求和喜好?！　?，一般常用命令居先，與用戶工作習(xí)慣保持一致。其次，根據(jù)外部服務(wù)之間的聚合關(guān)系組織相應(yīng)的命令。然后充分考慮人類記憶的局限性，最好組織為一顆兩層多叉樹。提供操作的快捷方式。　　，改進(jìn)界面設(shè)計(jì)。并評(píng)判系統(tǒng)是否 齊全、方便、好用。　　精化設(shè)計(jì)模型　　對(duì)模型進(jìn)行改進(jìn)的活動(dòng)可以分為 精化 和 合并 兩種。一般先從精化開始。設(shè)計(jì)優(yōu)秀的粗粒度組件應(yīng)該只是完成一項(xiàng)功能，這一點(diǎn)是它與子系統(tǒng)的主要區(qū)分?！　〈至６冉M件的范圍過(guò)于廣泛，難以發(fā)揮重用價(jià)值，粗粒度組件擁有持久化的行為，擁有業(yè)務(wù)邏輯，需要表示層的支持。　　將需求分成幾個(gè)功能組，基本上就可以得到相應(yīng)的粗粒度組件了?！　∵^(guò)小的范圍，將會(huì)造成粗粒度組件不容易使用，用戶需要理解不同的粗粒度組件之間的復(fù)雜關(guān)系?！　∪绻赡?，在粗粒度組件之間定義單項(xiàng)關(guān)聯(lián)可以有效的減少組件之間的耦合?！　”M可能簡(jiǎn)化組件之間的關(guān)系?！　∥覀冃枰獜能浖哪繕?biāo)領(lǐng)域中 識(shí)別出關(guān)鍵性的實(shí)體，或者說(shuō)領(lǐng)域中的名詞。然后決定它們應(yīng)該歸屬于那些粗粒度組件。兩個(gè)組件之間存在重復(fù)的要素，可以從中抽取共性的部分，形成新的組件?！　?系統(tǒng)架構(gòu)文檔化 模型概述　　以精心選擇的形式 將若干結(jié)構(gòu)元素進(jìn)行裝配?！　≤浖軜?gòu) = { 元素，形式，關(guān)系/約束 }　　邏輯視圖(logical view)對(duì)象模型?！　∵^(guò)程視圖(process view)并發(fā)和同步特征?！　∥锢硪晥D(physical view)分布式?！　￠_發(fā)視圖(development view)靜態(tài)組織結(jié)構(gòu)?！　ational 視圖模型?！　∶總€(gè)視圖上均獨(dú)立地應(yīng)用 Perryamp。Wolf 軟件架構(gòu)公式。對(duì)每種視圖選用特定的 架構(gòu)風(fēng)格(architectural style)?！　?邏輯結(jié)構(gòu)　　邏輯架構(gòu)主要支持功能性需求，系統(tǒng)分解為一系列的關(guān)鍵抽象，(大多數(shù))來(lái)自于問(wèn)題域，表現(xiàn)為對(duì)象或?qū)ο箢惖男问健！　〕橄?、封裝、繼承。　　對(duì)于數(shù)據(jù)驅(qū)動(dòng)程度高的應(yīng)用程序，可以使用其他形式的邏輯視圖，如 ER圖 代替面向?qū)ο蟮姆椒??！　∵壿嬕晥D的風(fēng)格采用面向?qū)ο蟮娘L(fēng)格，試圖在整個(gè)系統(tǒng)中 保持 單一的、一致的 對(duì)象模型。　　 進(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)圖來(lái)表達(dá)，顯示了“輸出”和“輸入”關(guān)系。　　考慮因素：開發(fā)難度、軟件管理、重用性、通用性、由工具集、語(yǔ)言 所帶來(lái)的限制?！　￠_發(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)的映射需要高度的靈活性 及 對(duì)源代碼產(chǎn)生最小的影響。 場(chǎng)景　　4種視圖的元素通過(guò)數(shù)量比較少的一組重要場(chǎng)景(更常見(jiàn)的是用例)進(jìn)行無(wú)縫協(xié)同工作，我們?yōu)閳?chǎng)景描述相應(yīng)的腳本(對(duì)象之間和過(guò)程之間的交互序列)?！　≡谀撤N意義上 場(chǎng)景是最重要的 需求抽象?！　?+1 的 +1 起到了兩個(gè)作用：　　作為一項(xiàng)驅(qū)動(dòng)因素 來(lái)發(fā)現(xiàn)架構(gòu)設(shè)計(jì)過(guò)程中的 架構(gòu)元素?！　∽鳛榧軜?gòu)原型測(cè)試的出發(fā)點(diǎn)?！　?chǎng)景表示法與組件邏輯視圖非常相似，但它使用過(guò)程視圖的連接符來(lái)表示對(duì)象之間的交互?！　?迭代過(guò)程　　在進(jìn)行文檔化時(shí)，提倡一種更具有迭代性質(zhì)的方法——架構(gòu)先被原型化、測(cè)試、估量、分析，然后在一系列的迭代過(guò)程中被細(xì)化?！　〕藴p少 風(fēng)險(xiǎn)之外，還有其他優(yōu)點(diǎn)：團(tuán)隊(duì)合作、培訓(xùn)、加深對(duì)架構(gòu)的理解、深入程序和工具 等。使 需求被細(xì)化、成熟化?！　∠到y(tǒng)大多數(shù)關(guān)鍵的功能以場(chǎng)景的形式被捕獲，關(guān)鍵意味著：最重要的功能、系統(tǒng)存在的理由、使用頻率最高的功能、必須減輕的一些重要技術(shù)風(fēng)險(xiǎn)。2011年軟考系統(tǒng)架構(gòu)設(shè)計(jì)師學(xué)習(xí)筆記第七章　　 設(shè)計(jì)模式概述　　重復(fù)遇到的典型問(wèn)題，描述這些共同問(wèn)題和解決這些問(wèn)題的方案 就形成了所謂的模式。　　 設(shè)計(jì)模式的歷史　　模式分為幾個(gè)部分：　　特定的情景(Context)，指模式在 何種情況下發(fā)生作用?！　?dòng)機(jī)(System of Force)，指問(wèn)題或預(yù)期的目標(biāo)?！　〗鉀Q方案(Solution)，平衡各動(dòng)機(jī) 或解決所闡述問(wèn)題的 構(gòu)造或配置。每個(gè)模式描述了一個(gè)在某種特定情境下不斷重復(fù)發(fā)生的問(wèn)題，以及解決該問(wèn)題解決方案的核心所在。　　 為什么要使用設(shè)計(jì)模式　　面向?qū)ο笤O(shè)計(jì)時(shí)需要考慮 封裝性、力度大小、依賴關(guān)系、靈活性、可重用性 等。　　簡(jiǎn)化并加快快設(shè)計(jì)　　無(wú)需從底層做起，重用成功的設(shè)計(jì)，節(jié)約開發(fā)時(shí)間，提高軟件質(zhì)量?！　》奖汩_發(fā)人員之間的通信　　可以更準(zhǔn)確地 描述問(wèn)題 及 問(wèn)題的解決方案，使解決方案具有一致性?！　〗档惋L(fēng)險(xiǎn)　　有助于轉(zhuǎn)到面向?qū)ο蠹夹g(shù)　　開發(fā)人員對(duì)新技術(shù)往往會(huì)有抵觸或排斥心理，對(duì)成熟的設(shè)計(jì)模式具有以下特性：　　?！　?，不