【文章內(nèi)容簡介】 情報告 ， 要求打印病情報告 ， 也可以查看或要求打印病歷 。 系統(tǒng)定期自動更新病歷 。 三 、 用 UML的靜態(tài)建模機制定義并描述本系統(tǒng)的靜態(tài)結構 （ 一 ） 建立系統(tǒng)的用例圖 通過以下六個問題識別角色 (1)誰使用系統(tǒng)的主要功能 ？ (2)誰需要系統(tǒng)的支持以完成日常工作任務 ？ (3)誰負責維護 ， 管理并保持系統(tǒng)正常運行 ？ (4)系統(tǒng)需要應付 （ 或處理 ） 哪些硬設備 ？ (5)系統(tǒng)需要和哪些外部系統(tǒng)交互 ？ (6)誰 （ 或什么 ） 對系統(tǒng)運行產(chǎn)生的結果 （ 值 ） 感興趣 ？ 退出 上頁 首頁 下頁 末頁 需求分析 通過回答這六個問題以后 ， 再進一步分析可以識別出本系統(tǒng)的四個角色：值班護士 ， 醫(yī)生 ， 病人 ， 標準病癥信號庫 。 角色描述模板 角色： 病 人 角色職責： 提供病癥信號 角色職責識別： 負責生成 、 實時提供 各種病癥信號 。 角色： 值班護士 角色職責： 負責監(jiān)視病人的病情 變化 角色職責識別： (1)使用系統(tǒng)主要功能 (2)對系統(tǒng)運行結果感 興趣 角色： 標準病癥信號庫 角色職責： 負責向系統(tǒng)提供病癥信 號的正常值 角色職責識別： (1)負責保持系統(tǒng)正常 運行 (2)與系統(tǒng)交互 角色： 醫(yī) 生 角色職責： 對病人負責 ， 負責處理 病情的變化 角色職責識別： (1)需要系統(tǒng)支持以完 成其日常工作 (2)對系統(tǒng)運行結果感 興趣 通過分析可以初步識別出系統(tǒng)的用例為：中央監(jiān)護 ， 病癥監(jiān)護 ， 提供標準病癥信號 ， 病歷管理 ， 病情報告管理 。 頂層用例圖為： 退出 上頁 首頁 下頁 末頁 提供標準 病癥信號 病歷管理 病人 標準病癥信號庫 醫(yī)生 值班護士 病癥監(jiān)護 病情報 告管理 中央監(jiān)護 《使用》 《使用》 《使用》 角色描述 將用例細化 ， 可以得到分解的用例： 中央監(jiān)護 分解為： a 分解信號 將從病癥監(jiān)護器傳送來的組合病癥信號分解為系統(tǒng)可以處理的信號 。 b 比較信號 將病人的病癥信號與標準信號比較 。 c 報警 如果病癥信號發(fā)生異常 （ 即高于峰值 ） ， 發(fā)出報警信號 。 d 數(shù)據(jù)格式化 將處理后的數(shù)據(jù)格式化以便寫入病歷庫 。 病癥監(jiān)護 分解為： e 信號采集 采集病人的病癥信號 。 f 模數(shù)轉化 將采集來的模擬信號轉化為數(shù)字信號 。 g 信號數(shù)據(jù)組合 將采集到的脈搏 ， 血壓等信號數(shù)據(jù)組合為一組信號數(shù)據(jù) 。 h 采樣頻率改變 根據(jù)病人的情況改變監(jiān)視器采樣頻率 。 提供標準病癥信號 i（ 此用例不分解 ） 病歷管理 分解為： j 生成病歷 k 查看病歷 l 更新病歷 m 打印病歷 病情報告 分解為： n 顯示病情報告 在顯示器上顯示病情 o 打印病情報告 在打印機打印病情報告 退出 上頁 首頁 下頁 末頁 用例細化 給出細化的用例圖 退出 上頁 首頁 下頁 末頁 病人 模數(shù)轉化 數(shù)據(jù)格式化 值班護士 報警 信號采集 比較信號 標準病癥 信號庫 醫(yī)生 信號數(shù)據(jù)組合 采樣頻率 改變 提供標準 病癥信號 生成病歷 查看病歷 更新病歷 打印病歷 顯示病情報告 打印病情報告 分解信號 《 Extend 》 《 Extend 》 《 Extend 》 《 use》 《 use》 《 use》 《 use》 《 use》 《 use》 《 use》 《 use》 細化的用例圖 （ 二 ） 識別系統(tǒng)的類 通過名詞識別法和系統(tǒng)實體識別法等方法可以識別出系統(tǒng)的十二個類 , 以下用類圖這種簡單明了的方法分別表示出類的名稱 ， 屬性 ， 操作 。 見下圖： 醫(yī)生 用戶名 密碼 查看病情報告 （ ） 要求打印病情報告 （ ） 查看病歷 （ ） 要求打印病歷 （ ） 病人 姓名 性別 年齡 病癥 提供病癥信號 （ ） 病癥監(jiān)視器 采集頻率 病癥信號 格式化信號數(shù)據(jù) （ ） 采集信號 （ ） 信號組合 （ ） 報警信號 聲音 燈光 文字 報警 （ ） 數(shù)模轉化 （ ） 病歷庫 類型 大小 容量 生成病歷 （ ） 更新病歷 （ ） 查看病歷 （ ） 打印病歷 （ ） 病人病癥信號 脈搏 血壓 體溫 生成病癥信號 （ ） 病歷 格式 病人基本情況 打印時間 生成病歷 （ ） 查看病歷 （ ） 打印病歷 （ ） 標準病癥信號 脈搏 血壓 體溫 生成標準信號 （ ） 用戶名 密碼 查看病情報告 （ ） 打印病情報告 （ ） 值班護士 類型 大小 容量 提供標準信號 （ ） 標準病癥信號庫 標題 格式 生成病情報告 （ ） 查看病情報告 （ ） 打印病情報告 （ ） 病情報告 輸入 輸出 分解信號 （ ） 比較信號 （ ） 報警 （ ） 數(shù)據(jù)格式化 （ ） 中央監(jiān)護系統(tǒng) 退出 上頁 首頁 下頁 末頁 類的識別 再進一步在類圖中標明類之間的關系： 退出 上頁 首頁 下頁 末頁 * * * * * * * 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 值班護士 醫(yī)生 病人 病癥監(jiān)視 病人病癥信號 病歷 病歷庫 病情報告 報警信號 中央監(jiān)護系統(tǒng) 標準病癥信號 標準病癥信號庫 1 1 1 報警 監(jiān)視 系統(tǒng)類圖 （ 三 ） 用包圖和配置圖描述系統(tǒng)的體系結構 通過一定的分組機制得到以下包圖： 用戶 醫(yī)生 值班護士 病人 病歷管理 病歷 用戶界面 病情報告 局部監(jiān)視 報警信號 病癥監(jiān)視器 中央監(jiān)護系統(tǒng) 病人病癥信號 標準病癥信號 數(shù)據(jù)庫 病歷庫 標準病癥信號庫 用戶層 用戶界面層 應用層 數(shù)據(jù)庫層 退出 上頁 首頁 下頁 末頁 包圖 接下來用配置圖進一步描述系統(tǒng)的網(wǎng)絡結構 四 、 用 UML的動態(tài)建模機制定義并描述系統(tǒng)結構元素的動態(tài)特性及行為 （ 一 ） 下面給出兩個關系很緊密的狀態(tài)圖 退出 上頁 首頁 下頁 末頁 病癥監(jiān)視器的狀態(tài)圖 信號采集 模數(shù)轉化 數(shù)據(jù)信號組合 發(fā)送信號數(shù)據(jù) 局部顯示 開解信號 開解信號數(shù)據(jù) 比較數(shù)據(jù) 信號異常 比較數(shù)據(jù) 信號正常 格式化的數(shù)據(jù) 報警 更新病歷 更新日期到 發(fā)生病情異常 發(fā)送報警標志 數(shù)據(jù)格式化 數(shù)據(jù)格式化 打印請求 中央監(jiān)護系統(tǒng)的狀態(tài)圖 打印病情報告 數(shù)據(jù)庫服務器 標準病癥信號庫 病歷庫 TCP/IP TCP/IP 應用服務器 中央監(jiān)護系統(tǒng) 局部監(jiān)視 客戶端 用戶界面 狀態(tài)圖與配置圖 （ 二 ） 用時序圖和合作圖描述病人病情異常時系統(tǒng)的情況 ， 其他情況從略 。 時序圖 ： 病情報告 監(jiān)視器 采集信號 發(fā)送信號 信號異常 返回 打印 更新 中央監(jiān)視系統(tǒng) 病歷 報警信號 退出 上頁 首頁 下頁 末頁 合作圖： 采集信號 發(fā)送信號 信號異常 打印 更新 監(jiān)視器 中央監(jiān)視系統(tǒng) 報警信號 病情報告 病歷 時序圖與合作圖 （ 三 ） 用活動圖描述系統(tǒng)在監(jiān)護病人時的狀態(tài)變化 退出 上頁 首頁 末頁 信號正常 更新時間到 信號異常 時間間隔未到 采集信號 分析比較信號 判斷是否正常 判斷更新時間 報 警 更新病歷 打印病情報告 活動圖 一 、 問題陳述 有一個對外營業(yè)的會議中心 ， 有各種不同規(guī)格的會議室 ， 為用戶提供以下服務： １ 、 用戶可以按照會議人數(shù) 、 會議時間預訂會議室 。 可以只預訂１次 ， 也可預訂定期召開的會議 。 ２ 、 開會前允許修改會議時間 、 人數(shù) ， 重新選擇會議室 ， 甚至取消預訂的會議 。 ３ 、 確定會議預訂后 ， 會議中心負責會務管理：包括通過郵寄或電子郵件 ， 通知開會人員有關會議信息 ， 制作代表證等 。 ４ 、 系統(tǒng)根據(jù)會議室的使用情況 （ 緊張與否 ） ， 調(diào)整 、 更改會議室和會議時間 ， 并調(diào)整修改預訂會議的時間 。 會議管理系統(tǒng) 退出 下頁 末頁 案 例 三 二、建立 用例模型 識別角色 找出所有可能與系統(tǒng)發(fā)生交互行為的外部實體 、 對象 、 系統(tǒng) 。 考慮系統(tǒng)的主要功能的使用者 ， 就會想到用戶和系統(tǒng)管理者 ， 但如果直接將用戶定義為角色 ， 系統(tǒng)的所有功能幾乎都由用戶使用 。 根據(jù)問題的描述 ， 系統(tǒng)要求將會議和會議的召開分開來 。 從會議的角度看 ， 允許用戶定義 、 更改或刪除一個會議 。 從會議召開的角度看 ， 允許用戶為某個會議定義召開時間 、 參加人數(shù) 、 更改相應的數(shù)據(jù)或刪除已定義的會議召開 。 因此 ， 將用戶識別為 “ 會議管理者 ” 和 “ 會議申請者 ” 兩個角色 。 本系統(tǒng)定義以下角色： 會議管理者 （ Meeting Administrator） 會議申請者 （ Meeting Instance Requester） 郵局 （ Post Office ） 會議人員管理 （ Attendee Management ） 系統(tǒng)維護者 （ System Maintainer ） 退出 上頁 首頁 下頁 在識別角色的基礎上 ， 列出與角色相關的用例 ， 有的用例與多個角色相關 ， 經(jīng)過分析 ， 確定系統(tǒng)的用例 （ 打 ? ） 。 ⑴ 與會議管理者相關的用例： 定義一個會議 （ Define Meeting ） ? 更改一個會議 （ Alter Meeting ） ? 刪除一個會議 （ Remove Meeting ） ? ⑵ 與會議申請者相關的用例： 申請會議召開 （ Request Meeting Instance ） ? 更改申請 （ Chang Request ） ? 取消申請 （ Cancel Request ） ? 定義參加人員 （ Add Attendee ） ? 歸還會議室 （ Release Room ） ? 用例識別 退出 上頁 首頁 下頁 用例識別 ⑶ 與郵局相關的用例： 申請會議召開 （ Request Meeting Instance ） 更改申請 （ Modify Request ） 取消申請 （ Cancel Request ） ⑷ 與會議人員管理相關的用例： 定義參加人員 （ Add Attendee ） 取消申請 （ Cancel Request ） 申請會議召開 （ Request Meeting Instance ） ? 更改申請 （ Modify Request ） ⑸ 與系統(tǒng)維護者相關的用例： 會議室維護 （ Meeting Room Maintenance ） ? 設定預定時限 （ Set Reservation Tome Limit ） ? 在確定角色和用例的基礎上 ， 畫出用例圖 （ 圖１ ） 。 退出 上頁 首頁 下頁 會