醫(yī)院病房監(jiān)護系統(tǒng)

一、問題描述為了對危重病人進行實時監(jiān)護，隨時了解病人病情，及時進行處理，建立病房監(jiān)護系統(tǒng)。病癥監(jiān)視器安置在每個病床，通過網(wǎng)絡(luò)將病人的病癥信號（組合）實時傳送到中央監(jiān)護系統(tǒng)進行分析處理。在中心值班室里，值班護士使用中央監(jiān)護系統(tǒng)對病員的情況進行監(jiān)控，監(jiān)護系統(tǒng)實時地將病人的病癥信號與標準的病診信號進行比較分析，當(Dang)病癥出現(xiàn)異常時，系統(tǒng)會立即自動報警，并打印病情報告和更新病歷。系統(tǒng)根據(jù)醫(yī)生的要求隨時打印病人的病情報告，系統(tǒng)定期自動更新病歷。第一頁，共八十三頁。請(Qing)對系統(tǒng)需求進行分析！經(jīng)過初步的需求分析，得到系統(tǒng)功能要求：1.監(jiān)視病員的病癥（血壓、體溫、脈搏等）2.定時更新病歷3.病員出現(xiàn)異常情況時報警。4.隨機地產(chǎn)生某一病員的病情報告。

例2醫(yī)院病房監(jiān)護系統(tǒng)產(chǎn)生病情報告監(jiān)視病情更新病歷第二頁，共八十三頁。二、簡單的需求分(Fen)析說明對“醫(yī)院病房監(jiān)護系統(tǒng)”進行分析，確定系統(tǒng)的主要功能如下：

1.病癥監(jiān)視器可以將采集到的病癥信號（組合），格式化后實時的傳送到中央監(jiān)護系統(tǒng)。

2.中央監(jiān)護系統(tǒng)將病人的病癥信號開解后與標準的病癥信號庫里的病癥信號的正常值進行比較，當病癥出現(xiàn)異常時系統(tǒng)自動報警。

3.當病癥信號異常時，系統(tǒng)自動更新病歷并打印病情報告。

4.值班護士可以查看病情報告并進行打印。醫(yī)生可以查看病情報告，要求打印病情報告，也可以查看或要求打印病歷。

6.系統(tǒng)定期自動更新病歷。需求分析第三頁，共八十三頁。1.通過以下六個問題識別角色(1)誰使用系統(tǒng)的主要功能？(2)誰需要系統(tǒng)的支持以完成日常工作任務(wù)？(3)誰負責維護，管理并保持系統(tǒng)正常運行？(4)系統(tǒng)需要應(yīng)付（或處理）哪些硬設(shè)備？(5)系統(tǒng)需要和哪些外部系統(tǒng)交互？(6)誰（或什么）對系統(tǒng)運行產(chǎn)生的結(jié)果（值）感(Gan)興趣？需求分析三、建立系統(tǒng)的用例模型值班護士、醫(yī)生、病人值班護士、醫(yī)生系統(tǒng)管理員監(jiān)護器,網(wǎng)絡(luò),報警系統(tǒng)標準病癥信號庫、病歷庫同(2)第四頁，共八十三頁。

通過回答這六個問題以后，再進一步分析可以識別出本系統(tǒng)的四個角色：值班護士，醫(yī)生，病人，標準病癥信號庫。角色描述(Shu)模板：角色：病人角色職責：提供病癥信號角色職責識別：負責生成、實時提供各種病癥信號。角色：值班護士角色職責：負責監(jiān)視病人的病情變化角色職責識別：

(1)使用系統(tǒng)主要功能

(2)對系統(tǒng)運行結(jié)果感興趣角色:標準病癥信號庫角色職責：負責向系統(tǒng)提供病癥信號的正常值角色職責識別：

(1)負責保持系統(tǒng)正常運行

(2)與系統(tǒng)交互角色：醫(yī)生角色職責：對病人負責，負責處理病情的變化角色職責識別：

(1)需要系統(tǒng)支持以完成其日常工作

(2)對系統(tǒng)運行結(jié)果感興趣角色描述第五頁，共八十三頁。２.識別(Bie)用例回答下面的問題：⑴與系統(tǒng)實現(xiàn)有關(guān)的主要問題是什么？⑵系統(tǒng)需要哪些輸入/輸出？這些輸入/輸出從何而來？到哪里去？⑶執(zhí)行者需要系統(tǒng)提供哪些功能？⑷執(zhí)行者是否需要對系統(tǒng)中的信息進行讀、創(chuàng)建、修改、刪除或存儲？通過分析可以初步識別出系統(tǒng)的用例為：中央監(jiān)護，病癥監(jiān)護，提供標準病癥信號，病歷管理，病情報告管理。頂層用例圖為：第六頁，共八十三頁。

通過分析可以初步識別(Bie)出系統(tǒng)的用例為：中央監(jiān)護，病癥監(jiān)護，提供標準病癥信號，病歷管理，病情報告管理。頂層用例圖為：醫(yī)院病房監(jiān)護系統(tǒng)高層用例圖值班護士醫(yī)生病人標準病癥信號庫病癥監(jiān)護提供標準病癥信號中央監(jiān)護病歷管理病情報告管理<<extend>><<include>><<include>><<include>>第七頁，共八十三頁。進一步將用例細化，即分解用例：1.中央監(jiān)護(Hu)

分解:a分解信號將從病癥監(jiān)護器傳送來的組合病癥信號分解為系統(tǒng)可以處理的信號。

b比較信號將病人的病癥信號與標準信號比較。

c報警如果病癥信號發(fā)生異常（即高于峰值），發(fā)出報警信號。

d數(shù)據(jù)格式化將處理后的數(shù)據(jù)格式化以便寫入病歷庫。2.病癥監(jiān)護

分解:e信號采集采集病人的病癥信號。

f模數(shù)轉(zhuǎn)化將采集來的模擬信號轉(zhuǎn)化為數(shù)字信號。

g信號數(shù)據(jù)組合將采集到的脈搏，血壓等信號數(shù)據(jù)組合為一組信號數(shù)據(jù)。

h采樣頻率改變根據(jù)病人的情況改變監(jiān)視器采樣頻率。用例細化第八頁，共八十三頁。3.提供標準病癥信(Xin)號

i（此用例不分解）4.病歷管理

分解為：j生成病歷

k查看病歷

l更新病歷

m打印病歷

病情報告管理

分解為：n顯示病情報告

在顯示器上顯示病情

o打印病情報告在打印機打印病情報告用例細化第九頁，共八十三頁。給出(Chu)細化的用例圖細化的用例圖病人模數(shù)轉(zhuǎn)化數(shù)據(jù)格式化值班護士報警信號采集比較信號標準病癥信號庫

醫(yī)生信號數(shù)據(jù)組合采樣頻率改變提供標準病癥信號生成病歷查看病歷更新病歷打印病歷顯示病情報告打印病情報告分解信號<<Extend>><<Extend>><<Extend>><<include>><<include>><<include>><<include>><<include>><<include>><<include>><<include>>第十頁，共八十三頁。用例名：

中

央

監(jiān)

視執(zhí)行者：值班護士、醫(yī)生目標：對病人的病癥信號進行監(jiān)測、處理，超過極限報警。功能描述：1.分解信號：將從病癥監(jiān)護器傳送來的組合病癥信號分解為系統(tǒng)可以處理的信號。2.比較信號：將病人的病癥信號與標準信號比較

。3.報警：如果病癥信號發(fā)生異常（即高于峰值），發(fā)出報警信號。4.數(shù)據(jù)格式化：將處理后的數(shù)據(jù)格式化以便寫入病歷庫

。其他非功能需求:高可靠性、實時性主要步驟：按設(shè)定頻率連續(xù)接收來自各病人的病癥信號，并進行分解。將病人的病癥信號與專家系統(tǒng)（標準病癥信號庫）中的標準信號進行比較判斷是否超過極限值。若超過極限值，進行報警，并及時更新病歷和打印病情報告。相關(guān)用例：病癥監(jiān)護、提供標準病癥信號、病歷管理、病情報告管理。相關(guān)信息：(優(yōu)先級、性能、頻執(zhí)行率)：優(yōu)先級：報警處理具有最高優(yōu)先級3,一般病歷管理為1,其他2.性能：實時性、高可靠性頻執(zhí)行率：根據(jù)病情嚴重程度12-30次/小時用例“中央監(jiān)護”描述模(Mo)板第十一頁，共八十三頁。第十章內(nèi)(Nei)容概要面向?qū)ο蠓椒▽W(xué)概述面向?qū)ο蟮母拍蠲嫦驅(qū)ο蠼ML可視化建模基礎(chǔ)面向?qū)ο蟮男枨筇崛∶嫦驅(qū)ο蠓治觥锏谑?，共八十三頁。模型：為了理解事物而對事物作出的一種抽象，是對事物的一種無歧義的書面描述。模型由一組圖示符號和組織這些符號的規(guī)則組成，利用它們來定義和描述問題域中的術(shù)語和概念。模型是一種思考工具，把(Ba)知識規(guī)范地表示出來。模型是現(xiàn)實的簡化、化簡的實現(xiàn)。面向?qū)ο蠼５谑摚舶耸?。第十四頁，共八十三頁。第十五頁，共八十三頁。第十六頁，共八十三頁。第十七頁，共八十三頁。第十八頁，共八十三頁。第十九頁，共八十三頁。第二十頁，共八十三頁。第二十一頁，共八十三頁。第二十二頁，共八十三頁。第二十三頁，共八十三頁。第二十四頁，共八十三頁。第二十五頁，共八十三頁。第二十六頁，共八十三頁。第二十七頁，共八十三頁。UML描述模型的三種基本詞匯：要素（Things）、關(guān)系（Relationships）、圖（Diagrams）UML有(You)4種要素：表述結(jié)構(gòu)的要素：UseCase、類、接口、協(xié)作表述行為的要素：交互、狀態(tài)機用于組織的要素：包用于輔助說明的要素：注釋面向?qū)ο蠼７栂到y(tǒng)－UML第二十八頁，共八十三頁。UML有4種關(guān)系：關(guān)聯(lián)關(guān)系：有聯(lián)系依(Yi)賴關(guān)系：使用泛化關(guān)系：特殊到一般實現(xiàn)關(guān)系：規(guī)約到解決方案UML有9種圖：UseCase圖：展示UseCase、Actor及其關(guān)系；類圖：展示類、接口、包及其關(guān)系；面向?qū)ο蠼７栂到y(tǒng)－UML0..1*employeremployee第二十九頁，共八十三頁。順序圖：按時序展示對象間消息傳遞；協(xié)作圖：強調(diào)收發(fā)消息的對象間的組織結(jié)構(gòu)；狀態(tài)圖：展示對象在其生命周期中的可能狀態(tài)以及在這些(Xie)狀態(tài)上對事件的響應(yīng)；活動圖：展示系統(tǒng)從一個活動轉(zhuǎn)到另一活動的可能路徑和判斷條件；對象圖：某個時間點上系統(tǒng)中各對象的快照；構(gòu)件圖：展示系統(tǒng)各構(gòu)件及其關(guān)系；配置圖：展示交付系統(tǒng)中軟硬件間物理關(guān)系；面向?qū)ο蠼７栂到y(tǒng)－UML第三十頁，共八十三頁。UseCase圖主要用于描述系統(tǒng)和外部環(huán)境的關(guān)系。UseCase：對系統(tǒng)提供的功能的一種描述。(Ausecasedescribesbehaviorthatthesystemexhibitstobenefitoneormoreactors.)Actor：是可能使用這些UseCase的人或外部系統(tǒng)。(Actorsarerolesadoptedbythingsthatinteractdirectlywithsystem.Aroleislikeahatthatsomethingwearsinaparticularcontext.)系統(tǒng)邊界：UseCase在(Zai)內(nèi)，Actor在外；用例之間的關(guān)系：《extend》、《include》、 GeneralizationUseCase（用例）圖簡介第三十一頁，共八十三頁。用(Yong)例圖示例PlaceOrderCancleOrderCheckOrderStatusRequestCatalogShipProductMailordersystemactorcommunicationrelationshipSubjectnamesystemboundaryusecaseCustomerShippingCompanyDispatcher第三十二頁，共八十三頁。用例圖(Tu)示例第三十三頁，共八十三頁。Actor與UseCase間的連線稱為(Wei)通信關(guān)聯(lián)，表示Actor與相應(yīng)UseCase的交互。無論有無箭頭，通信關(guān)聯(lián)都表示雙向會話，箭頭表示Actor觸發(fā)UseCase。第三十四頁，共八十三頁。類圖應(yīng)用最廣，可在各個層次上描述系統(tǒng)的靜態(tài)結(jié)構(gòu)。方框表示類：上面寫類名，中間是類的屬性，下面是類的操作。關(guān)(Guan)聯(lián)（Association）：關(guān)聯(lián)關(guān)系表示類的實例之間存在某種穩(wěn)定的聯(lián)系。對象圖是類圖的一種變形，對象名下面要加下劃線。類圖/對象圖簡介第三十五頁，共八十三頁。類的(De)表述形式：＋：public－：private＃：protected關(guān)聯(lián)關(guān)系：第三十六頁，共八十三頁。AClassinUMLClassnameAttributesOperators第三十七頁，共八十三頁。AnObjectinUMLobjectnameandclass第三十八頁，共八十三頁。ClassRelationshipsinUMLGeneralizationDependencyAssociationThesecanrepresentinheritance,using,aggregation,etc.第三十九頁，共八十三頁。Exampleclassdiagram第四十頁，共八十三頁。AssociationStructuralrelationshipbetweenpeerclasses(orobjects).Associationcanhaveanameanddirection,orbebi-directionalRolenamesforeachendoftheassociationMultiplicityoftherelationship第四十一頁，共八十三頁。ExamplesofAssociation第四十二頁，共八十三頁。AssociationcodeexampleclassPerson{public:private:Company*employer;};classCompany{public:private:Person**employee;};EachinstanceofPersonhasapointertoitsemployerEachinstanceofCompanyhasacollectionofpointersdenotingitsemployees第四十三頁，共八十三頁。LinkAttributesAssociationsmayhavepropertiesinthesamemannerasobjects/classes.Salaryandjobtitlecanberepresentedas第四十四頁，共八十三頁。Aggregation(聚合(He)/共享聚集)Apartofrelationship(physicalcontainment)classProjectGroup{public:ProjectGroup();

private:Personmember[n];};第四十五頁，共八十三頁。Composition(組合(He)，組合(He)聚集)第四十六頁，共八十三頁。AggregationvsCompositionAggregationisasharedcontainment.Manyotherclassesmayhavethesametypeofaggregate.E.g.,string,listCompositionisaggregatesthatcannotstandbythemselves(e.g.,foot,arm,etc.)第四十七頁，共八十三頁。Generalization/Inheritance第四十八頁，共八十三頁。第四十九頁，共八十三頁。Dependency依賴關(guān)系描述兩個模型元素（類、用例等）之(Zhi)間的語義連接關(guān)系：其中一個模型元素是獨立的，另一個模型元素不是獨立的，它依賴于獨立的模型元素，如果獨立的模型元素改變了，將影響依賴于它的模型元素。第五十頁，共八十三頁。Refine當對同一個事物在不同抽象層次上描述時，這些描述之間具有細(Xi)化關(guān)系。假設(shè)兩個模型元素A和B描述同一個事物，它們的區(qū)別是抽象層次不同，如果B是在A的基礎(chǔ)上的更詳細的描述，則稱B細化了A，或稱A細化成了B。細化的圖示符號為由元素B指向元素A的、一端為空心三角形的虛線第五十一頁，共八十三頁。第五十二頁，共八十三頁。第五十三頁，共八十三頁。類圖示例：簡單手表的組成部(Bu)分第五十四頁，共八十三頁。對象(Xiang)圖：類圖：第五十五頁，共八十三頁。在三個層次上使用類圖：概念層：描述應(yīng)用域中的概念說明層：考察軟件的接(Jie)口部分，而非實現(xiàn)部分，要區(qū)分接(Jie)口與實現(xiàn)（即類型與類）實現(xiàn)層：揭示軟件實現(xiàn)體的構(gòu)成情況。只有在這層才有真正嚴格意義上的類的概念要理解問題：概念層要理解軟件：說明層類圖/對象圖簡介第五十六頁，共八十三頁。順序圖描述幾個對象間的動態(tài)協(xié)作關(guān)系，一個對象通過發(fā)送消息與其他對象相互作用(Yong)。一個對象對消息的接收觸發(fā)一個操作的執(zhí)行，從而可能給其他對象發(fā)消息。順序圖對識別UseCase中的附加對象很有用：包含在UseCase中的對象稱為參與對象；順序圖展示了這些對象間傳送消息的時間順序，反映了對象之間的一次特定交互過程；順序圖簡介第五十七頁，共八十三頁。順序圖示例(Li)：簡單手表調(diào)時第五十八頁，共八十三頁。順序圖示(Shi)例：一臺打印服務(wù)器第五十九頁，共八十三頁。也是用來描述系統(tǒng)中對象間的動態(tài)協(xié)作關(guān)系；協(xié)作圖側(cè)重說(Shuo)明哪些對象間有消息傳遞；順序圖側(cè)重表述在某情況下對象間傳遞消息的時序性；協(xié)作圖中要給消息編號來標明消息的執(zhí)行順序；協(xié)作圖簡介第六十頁，共八十三頁。協(xié)作圖示例：打印服務(wù)(Wu)器第六十一頁，共八十三頁。協(xié)作圖中使用的消息層次編號(Hao)能反映激活的嵌套性質(zhì)，這在順序圖中能顯式地表示出來。第六十二頁，共八十三頁。一個狀態(tài)是對象滿足的一種條件。狀態(tài)可認為是一個類屬性值的抽象；用對象的多個狀態(tài)及這些狀態(tài)間的轉(zhuǎn)換來描述單個對象的行為。標注狀態(tài)轉(zhuǎn)移：事件[條件]／動作動作：伴隨轉(zhuǎn)移發(fā)(Fa)生，不會被中斷活動：在某一狀態(tài)中進行，可以被中斷狀態(tài)圖簡介第六十三頁，共八十三頁。簡單手表“設(shè)置時間”UseCase的狀(Zhuang)態(tài)圖第六十四頁，共八十三頁。類似流程圖描述所要(Yao)進行的各項活動的執(zhí)行流程描述一個UseCase的處理流程活動圖可以方便地描述控制轉(zhuǎn)移條件以及并行執(zhí)行等要求活動圖簡介第六十五頁，共八十三頁?；顒?Dong)圖示例：打印過程第六十六頁，共八十三頁。第六十七頁，共八十三頁?；顒訄D示例：開發(fā)軟件需求(Qiu)的流程第六十八頁，共八十三頁?；顒訄D示例(Li)：表示并發(fā)和同步第六十九頁，共八十三頁。第七十頁，共八十三頁。構(gòu)件圖(Tu)描述程序代碼的組織結(jié)構(gòu)構(gòu)件：源代碼構(gòu)件二進制目標代碼構(gòu)件可執(zhí)行構(gòu)件文檔構(gòu)件構(gòu)件圖簡介第七十一頁，共八十三頁。反(Fan)映程序代碼構(gòu)件間的依賴關(guān)系的構(gòu)件圖第七十二頁，共八十三頁。描述系統(tǒng)中軟硬件的物理配置情況和系統(tǒng)體系結(jié)構(gòu)結(jié)點表示實際的物理設(shè)備連接表示各物理結(jié)點的連接方式結(jié)點內(nèi)(Nei)部表示分配到該結(jié)點運行的構(gòu)件或?qū)ο笈渲脠D簡介第七十三頁，共八十三頁。描述一個系(Xi)統(tǒng)的物理體系(Xi)結(jié)構(gòu)的配置圖第七十四頁，共八十三頁。標記值（TaggedValue）附屬于UML元素的(De)各種信息（Property）具有形式：{屬性名=值}約束（Constraint）UML中限制一種或多個元素語義的規(guī)則形式：{約束條件}UML的三種擴展機制第七十五頁，共八十三頁。UML的三(San)種擴展機制第七十六頁，共八十三頁。構(gòu)造型（Stereotype）構(gòu)造型機制是(Shi)指在已有的模型元素基礎(chǔ)上建立一種新的模型元素。它與現(xiàn)有元素要相差不多，只是(Shi)多一些特別的語義UML