設計建?；A與實例

設計建?；A與實例第1頁，課件共35頁，創(chuàng)作于2023年2月知識圖譜第2頁，課件共35頁，創(chuàng)作于2023年2月Agenda設計建模的內(nèi)容如何使用UML進行設計建模設計建模實例本章小結第3頁，課件共35頁，創(chuàng)作于2023年2月Agenda設計建模的內(nèi)容如何使用UML進行設計建模設計建模實例本章小結第4頁，課件共35頁，創(chuàng)作于2023年2月設計建模的內(nèi)容將實現(xiàn)工作劃分為更易于管理的各個部分捕獲子系統(tǒng)之間的主要接口通過對單個子系統(tǒng)、接口

和類進行設計，為后續(xù)的

開發(fā)活動提供基礎深入理解與非功能性需求

和約束相聯(lián)系的編程語言、

構件重用、操作系統(tǒng)、分

布與并發(fā)技術、數(shù)據(jù)庫技

術、用戶界面技術等相關問題第5頁，課件共35頁，創(chuàng)作于2023年2月設計建模的內(nèi)容架構設計（架構建模）：也稱為概要設計、高層設計，將軟件需求轉(zhuǎn)化為軟件的系統(tǒng)結構。就是將從宏觀的角度將軟件分成包及構件，并確定包與包、構件與構件之間的接口。詳細設計（構件建模）：也稱為低

層設計，將對構件表示進行細化。

對應于面向?qū)ο笤O計，就將是分析

出詳細的類（包括設計類的引入）

以及類與類之間的交互。第6頁，課件共35頁，創(chuàng)作于2023年2月Agenda設計建模的內(nèi)容如何使用UML進行設計建模設計建模實例本章小結第7頁，課件共35頁，創(chuàng)作于2023年2月架構建模用例視圖：就是需求建模的結果，是架構設計的輸入；設計視圖：在需求建模完成的概念（領域）模型的基礎上，重點在于包的組織以及包之間的依賴；進程視圖：在架構設計階段相對弱化；實現(xiàn)視圖：架構設計的重點，關鍵在于理清系統(tǒng)中的構件組成及構件間的關系；部署視圖：根據(jù)解決方案的特點，對部

署模型進行初步的設計第8頁，課件共35頁，創(chuàng)作于2023年2月架構建?！_定核心元素將分析類映射到設計元素：

--若分析類比較簡單，就可直接映射為設計類。通常分析類、控制類和一般的實體類都可以直接映射為設計類

--一個分析類可以映射為一個設計類或者多個設計類的簡單組；

--如果分析類的職責比較復雜，其行為很難由單個設計類或幾個設計類的簡單組合來承擔，那么就應該映射為“子系統(tǒng)接口”。定義子系統(tǒng)接口：首先是為子系統(tǒng)接口命名；接著描述擬建子系統(tǒng)的行為；然后確定子系統(tǒng)接口對其他設計元素的依賴關系第9頁，課件共35頁，創(chuàng)作于2023年2月架構建模—確定核心元素在需要時，可以對子系統(tǒng)進行輔助說明：通過順序圖來說明操作的使用方式和執(zhí)行順序；通過狀態(tài)圖來說明實現(xiàn)接口的設計元素可能處于的狀態(tài)等。融合子系統(tǒng)：當將分析類映射到設計元素、確定子系統(tǒng)接口之后，還應該逐步地將設計元素合并成子系統(tǒng)。通常是從設計元素出發(fā)，定義出候選的子系統(tǒng)接口，然后再從這些候選集合中進行不斷的精化和融合調(diào)整子系統(tǒng)：并非所有子系統(tǒng)接口都必須自主開發(fā)，有時可從以往開發(fā)的子系統(tǒng)中找到符合需求的構件，甚至可能可以通過直接購買的方式來實現(xiàn)這些子系統(tǒng)第10頁，課件共35頁，創(chuàng)作于2023年2月架構建模—引入外圍元素引入相應框架、基礎設施等外圍元素分析結果設計結果實施方法存儲(留存)RDBMSJDBC……ADO.NETXML……分布式RPC.NETRemoting……JMI………第11頁，課件共35頁，創(chuàng)作于2023年2月架構建模—優(yōu)化組織結構層次結構第12頁，課件共35頁，創(chuàng)作于2023年2月架構建?！獌?yōu)化組織結構管道和過濾架構代理架構第13頁，課件共35頁，創(chuàng)作于2023年2月架構建?！獌?yōu)化組織結構出版者/訂閱者模式網(wǎng)狀架構第14頁，課件共35頁，創(chuàng)作于2023年2月架構建?！獦嫿ú渴饒D在設計階段聚焦于節(jié)點或節(jié)點實例，以及它們之間的連接—架構設計在實現(xiàn)階段則聚焦于將物理構件分配給節(jié)點。因此在架構設計階段，可以根據(jù)實際的需要，確定待開發(fā)系統(tǒng)將部署于哪些物理節(jié)點之上，以及物理節(jié)點的一些環(huán)境要求、節(jié)點之間的通信協(xié)議等

第15頁，課件共35頁，創(chuàng)作于2023年2月構件建模架構建模的目的是確定組成系統(tǒng)的構件，以及構件之間的交互關系對每個構件進行詳細的設計，確定參與類（包括設計類）、類的屬性與操作（職責）以及類與類之間的交互關系（細化類模型）；確定類與類之間的交互的控制流（順序圖、協(xié)作圖、活動圖、狀態(tài)機圖等）；闡述接口的實現(xiàn)方式（細化構件圖）兩大視角：用例實現(xiàn)、邏輯結構第16頁，課件共35頁，創(chuàng)作于2023年2月Agenda設計建模的內(nèi)容如何使用UML進行設計建模設計建模實例本章小結第17頁，課件共35頁，創(chuàng)作于2023年2月確定解決方案劃分子系統(tǒng)：

--任務管理子系統(tǒng)--時間日志子系統(tǒng)

--用戶管理子系統(tǒng)--產(chǎn)能查詢分析子系統(tǒng)明確部署結構第18頁，課件共35頁，創(chuàng)作于2023年2月確定解決方案確定子系統(tǒng)之間的關系第19頁，課件共35頁，創(chuàng)作于2023年2月架構建模時間日志子系統(tǒng)架構建模第20頁，課件共35頁，創(chuàng)作于2023年2月架構建模B/S子系統(tǒng)架構建模第21頁，課件共35頁，創(chuàng)作于2023年2月架構建模B/S子系統(tǒng)架構建模第22頁，課件共35頁，創(chuàng)作于2023年2月架構建模B/S子系統(tǒng)架構建模第23頁，課件共35頁，創(chuàng)作于2023年2月構件建?！瓌t對用例的事件流進行梳理，逐一確定邊界對象和實體對象，將邊界對象放到UI層、實體對象和業(yè)務規(guī)則放在業(yè)務邏輯層，并根據(jù)流程確定接口；然后再根據(jù)業(yè)務邏輯層的實體類需要的數(shù)據(jù)存儲來分析數(shù)據(jù)訪問層；對分布式、并發(fā)、安全、日志等其它機制進行相應的處理

第24頁，課件共35頁，創(chuàng)作于2023年2月構件建?！袨榉治鲩_始計時：開始一次計時暫停計時：暫時停止計時，并累加“中斷次數(shù)”恢復計時：重新開始計時，從“暫?！钡健盎謴汀敝g的時間累加到“中斷時間”中停止計時：生成日志記錄、填寫信息、存儲時間日志登錄系統(tǒng)：連接到后臺服務器，以完成數(shù)據(jù)的交互上傳時間日志：將本地數(shù)據(jù)庫中的已完成（即已經(jīng)停止計時）的時間日志上傳到服務器上更新任務ID：從后臺服務器獲取最新的任務ID，以供本地數(shù)據(jù)庫使用。第25頁，課件共35頁，創(chuàng)作于2023年2月構件建?！鞔_行為特性行為影響實現(xiàn)者開始計時禁用“開始計時”、“恢復計時”啟用“暫停計時”、“停止計時”TimeLog類暫停計時禁用“開始計時”、“停止計時”、“暫停計時”啟用“恢復計時”TimeLog類恢復計時禁用“開始計時”、“恢復計時”啟用“暫停計時”、“停止計時”TimeLog類停止計時禁用“暫停計時”、“恢復計時”、“停止計時”啟用“開始計時”系統(tǒng)退出時，如果處于計時狀態(tài)，將觸發(fā)TimeLog類登錄系統(tǒng)獨立操作接口LoginSystem上傳時間日志系統(tǒng)發(fā)起，當系統(tǒng)登錄成功后，通過獨立線程輪詢數(shù)據(jù)庫完成ThreadAppend接口logAppend更新任務ID當成功登錄系統(tǒng)后，自動發(fā)起用戶可以在停止計時并輸入信息時手動發(fā)起接口getTaskID第26頁，課件共35頁，創(chuàng)作于2023年2月構件建模—UI構件設計第27頁，課件共35頁，創(chuàng)作于2023年2月構件建模—登錄系統(tǒng)行為分析第28頁，課件共35頁，創(chuàng)作于2023年2月構件建?！蟼鲿r間日志行為分析第29頁，課件共35頁，創(chuàng)作于2023年2月構件建?！氯蝿誌D行為分析第30頁，課件共35頁，創(chuàng)作于2023年2月構件建?！嫊r行為分析第31頁，課件共35頁，創(chuàng)作于2023年2月構件建?！O計類整理第32頁，課件共35頁，創(chuàng)作于2023年2月構件建?！毣惵氊煹?3頁，課件共35頁，創(chuàng)作于2023年2月Agenda設計建模的內(nèi)容如何使用UML進行設計建模設計建模實例本章小結第34頁，課件共35頁，創(chuàng)作于2023年2月本章小結首先闡述了設計建模的內(nèi)容、