用例分析技術(shù)在醫(yī)院門診信息系統(tǒng)需求分析中的應用

周 巖

菏澤醫(yī)學專科學校網(wǎng)絡中心，山東 菏澤 274000

用例分析技術(shù)是通過參與者以及用例間的關(guān)系來描繪系統(tǒng)內(nèi)外可見的需求，是用戶和開發(fā)人員共同塑造系統(tǒng)的合作區(qū)間。用例被定義為是一組動作序列的描述，被系統(tǒng)執(zhí)行后，參與者會獲得可見結(jié)果。

用例分析可對系統(tǒng)局部進行有效的邊界劃分，從而獨立分析系統(tǒng)局部參與者的對應用例。另外，在整個軟件開發(fā)過程中，用例驅(qū)動模式可貫穿軟件的開發(fā)全程，可有效避免開發(fā)過程中軟件需求變更的混亂。用例分析可應用于多種迭代式軟件開發(fā)過程，可在早期對需求錯誤加以鑒別和解決。在前期的需求分析中，首先要明確參與者的數(shù)量以及每個參與者的參與目標是什么?其參與目標就是我們要分析的角度，這個角度就可以描述成一個用例。這也就是為什么用例會成為建模方法的原因［1］。

用例分析的粗細，應由業(yè)務需求的情況決定［2］。復雜的部分細一些，簡單的部分粗一些，保證每個用例都保持密切的相關(guān)性，以指導后續(xù)的功能劃分。

1 系統(tǒng)分析

1．1 門診組織結(jié)構(gòu)的前期分析

在系統(tǒng)需求分析的前期，通常要實地考察業(yè)務部門的管理體系，在充分了解和掌握其管理結(jié)構(gòu)的基礎上，再逐步進行業(yè)務細化和切割，最終劃分出獨立的業(yè)務單元［3］，以便后期借助用例分析。

確定系統(tǒng)邊界［4］是用例分析的前提，在實地調(diào)查過程中，要找出位于系統(tǒng)外部和內(nèi)部的事物。在系統(tǒng)外部歸納出參與者，在系統(tǒng)內(nèi)部總結(jié)出用例。在此指導前提下，我們初步分析出醫(yī)院門診業(yè)務結(jié)構(gòu)組成，其業(yè)務可分為:門診掛號、醫(yī)師診療、門診收費、門診藥房、檢查檢驗科等。而這些科室的所有日常工作都是圍繞著醫(yī)師診療這個核心去進行的。該文將通過以上幾個不同方面對系統(tǒng)需求進行分析。

1．2 從參與者入手的系統(tǒng)分析

按需求分析以用例為最終分析模式的要求，首先要對門診業(yè)務由粗到細，由大到小，由繁到簡的順序來進行分析，最終歸結(jié)到人(參與者)、事(過程)、物(結(jié)果)的層面。

按一般規(guī)律，尋找參與者是用例分析的首要前提，并且常有一個參與者對應多個用例的特性，先找到參與者也便于從參與者的角度分析用例的內(nèi)容，使系統(tǒng)分析更貼近應用。那么針對醫(yī)院門診信息系統(tǒng)開發(fā)的需求分析，尋找其用例的過程就首先變成與參與者(用戶)分析交流的過程。這里的用戶應是和系統(tǒng)互動及交互信息的個體。所以應該包括病人、掛號員、收款員、醫(yī)師、護士、藥師及其他外部系統(tǒng)與硬件設備等。參與者會啟動、參與用例的運行，找到參與者就可以引導我們找到用例，以建立醫(yī)院門診管理信息模型。

在與醫(yī)院門診各科室業(yè)務人員座談的同時，我們用多種調(diào)查表格，以了解記錄他們對待開發(fā)系統(tǒng)的想法和期望，并從中歸納總結(jié)出待開發(fā)系統(tǒng)最終需要完成哪些工作。我們在對門診具體業(yè)務調(diào)查的基礎上，總結(jié)出了門診業(yè)務關(guān)系:

首先，病人作為掛號事件的驅(qū)動者，觸發(fā)掛號系統(tǒng)，通過交互操作，產(chǎn)生的結(jié)果(數(shù)據(jù))流向下一個環(huán)節(jié)(醫(yī)師診療系統(tǒng));醫(yī)師和病人是診療系統(tǒng)的事件驅(qū)動者，醫(yī)師通過交互操作，產(chǎn)生的結(jié)果(數(shù)據(jù))流向不同的環(huán)節(jié)(收費、治療、門診藥房、檢查、檢驗);收費員和病人是收費事件的驅(qū)動者，觸發(fā)收費系統(tǒng)，通過交互操作，產(chǎn)生的結(jié)果(數(shù)據(jù))流向相應環(huán)節(jié)(治療、門診藥房、檢查、檢驗);各相關(guān)事件驅(qū)動者驅(qū)動治療、門診藥房、檢查、檢驗等子系統(tǒng)后，通過交互操作，產(chǎn)生的相應結(jié)果(數(shù)據(jù))返回醫(yī)師診療系統(tǒng)。

1．3 對象模式的需求分析

我們采用面向?qū)ο蠓治龇椒?object-oriented analysis，OOA)對醫(yī)院門診系統(tǒng)的流程進行分析。借用用例建立需求模型來描述各系統(tǒng)的功能，開發(fā)人員通過分析系統(tǒng)的各項功能和非功能需求之后，把需求按照統(tǒng)一建模語言(unified modeling language，UML)的規(guī)則設計成相應的用例，建立系統(tǒng)的用例圖之后，可以再通過活動圖和時序圖來進一步標示出各個用例間的業(yè)務關(guān)系和大致流程。通過這種方式來確定模型中的用例和參與者。用例的堆放順序應體現(xiàn)其發(fā)生時間。

在分析門診總體業(yè)務關(guān)系的基礎上，我們對門診管理系統(tǒng)所涉及的相關(guān)內(nèi)容以用例的形式進行羅列(如圖1所示)。圖1中列舉了相關(guān)參與者和與其對應的用例，在這里我們只列出一些相關(guān)的基本內(nèi)容，用以銜接后面的敘述。

圖1 醫(yī)院門診相關(guān)用例結(jié)構(gòu)圖

針對較龐大的信息管理系統(tǒng)分析，系統(tǒng)切分是不可避免的工作。我們把整個系統(tǒng)按業(yè)務界線劃分出幾個信息孤島，這幾個信息孤島就應該是將來的子系統(tǒng)。而子系統(tǒng)的切分就是每個信息孤島按功能目標的繼續(xù)切分。

系統(tǒng)核心功能分為:門診掛號、醫(yī)師診療、門診收費、門診藥房、檢查、檢驗治療五大部分。檢查、檢驗為第三方引進軟件，該系統(tǒng)只提供數(shù)據(jù)接口。其中病人、掛號員、醫(yī)師、收費員、藥劑師為用例參與者［5］。

以上五大功能部分，他們之間的關(guān)系既是并列相互獨立的，同時也是相互依存的，在系統(tǒng)層面上他們都屬于門診信息系統(tǒng)的子部分，都有平臺共用、數(shù)據(jù)共享的特性，其包含關(guān)系如圖2所示。

圖2 各子系統(tǒng)用例及關(guān)系結(jié)構(gòu)圖

其實，在前面的分析中，我們獲得的系統(tǒng)層面級的用例對系統(tǒng)的切分幫助是巨大的。因為系統(tǒng)級的用例可以清楚地顯示出子系統(tǒng)的功能目的和關(guān)系。而如果跳過了系統(tǒng)級的用例分析，直接進行子系統(tǒng)的分析，那么分析過程將會是散在的、零亂的、毫無頭緒的，并且效率會很低。

經(jīng)過以上的分析，我們獲得了實體子系統(tǒng)，接下來的工作就是對每個子系統(tǒng)進一步的切分和整合。受篇幅所限，以下僅對門診掛號和醫(yī)師診療用例進行分析說明。

2 系統(tǒng)設計

2．1 門診掛號

掛號員是用例的參與者。負責啟動、運行掛號用例，用例內(nèi)容應包含卡號及流水號的建立、錄入、保存、查詢、修改、統(tǒng)計病人基本信息及收費信息;建卡和補卡;最終生成就診卡。此階段中的建卡或補卡操作是對病人基本信息的存儲和調(diào)用。在此環(huán)節(jié)生成的病人信息數(shù)據(jù)也會被后續(xù)環(huán)節(jié)調(diào)用。

一般來說，對于有經(jīng)驗的系統(tǒng)分析者，用活動圖抓用例是一個效率較高的辦法。但在實際應用中，應該注意對業(yè)務活動的分析不要陷入流程細節(jié)，要時刻銘記此階段的流程分析僅是用來尋找用例，而不是分析出復雜、全面的流程細節(jié)［6］。

通過分析門診掛號發(fā)卡業(yè)務活動，從中找出了病人信息錄入和就診卡處理2個用例。圖3為就診卡處理用例圖。

主題區(qū)域:門診掛號就診卡子模塊

業(yè)務功能:門診建卡、補卡

使用角色:掛號員

功能簡述:對就診卡信息進行查詢、添加、修改和存儲操作。

發(fā)生條件:以掛號室人員身份登錄系統(tǒng)，獲得所有管理權(quán)限;病人掛號;信息查詢。

請求結(jié)果:獲得就診卡、就診流水號。

如圖3所示為掛號員在門診建卡/補卡中所包含的內(nèi)容:①操作員首先進入建卡或補卡界面;②信息錄入系統(tǒng)(初次就診);③或直接查詢調(diào)出病人信息(復診);④收費或生成新就診卡;⑤用例結(jié)束。在此用例中，病人和掛號員是參與者。

圖3 門診就診卡(建卡/補卡)用例圖

圖3中箭頭表示參與者與用例之間的聚合關(guān)系［7］，是用來表示參與者與系統(tǒng)雙方的通信關(guān)系，并不是用來表示信息或數(shù)據(jù)流向。而目前習慣使用箭頭表示單向聚合關(guān)系，用以表示參與者扮演的是啟動還是支持角色。

在該用例中，掛號員是扮演啟動角色的參與者。

2．2 醫(yī)師診療

其中，包括“藥品醫(yī)囑”、檢查/檢驗醫(yī)囑、治療醫(yī)囑等，在此僅以藥品醫(yī)囑為例進行用例的分析描述。

醫(yī)師是外部參與者，醫(yī)師從候診隊列選取病人，獲取病人就診信息，體檢后錄入藥品醫(yī)囑。藥品信息來源于藥品庫存信息，生成電子處方保存至數(shù)據(jù)庫。在此環(huán)節(jié)生成的醫(yī)囑數(shù)據(jù)會被收款和藥房等后續(xù)環(huán)節(jié)調(diào)用。

主題區(qū)域:門診醫(yī)師診療子模塊

業(yè)務功能:藥品醫(yī)囑錄入及生成處方

使用角色:醫(yī)師

功能簡述:藥品醫(yī)囑錄入及生成處方。

發(fā)生條件:以門診醫(yī)師身份登錄系統(tǒng)，獲得管理權(quán)限并成功叫號。

請求結(jié)果:生成藥品處方。

如圖4所示，門診醫(yī)師進入診療子系統(tǒng):①從候診隊列選取病人及信息;②進入藥品醫(yī)囑錄入界面;③調(diào)取藥品醫(yī)囑模板并修改;④將表單內(nèi)容保存至數(shù)據(jù)庫;⑤支持處方打印功能;⑥用例結(jié)束。在此用例中，藥品信息來源于藥品庫存數(shù)據(jù)信息。醫(yī)師是用例參與者。

圖4 藥品醫(yī)囑用例圖

此外，還有門診收費、門診藥房等用例均有各自的特點，但基本原理相似，在此不做贅述。

3 系統(tǒng)關(guān)鍵技術(shù)

首先把系統(tǒng)切分成功能不同的子系統(tǒng)，每個子系統(tǒng)負責完成部分特點較接近的用例。對于需要多個子系統(tǒng)協(xié)同實現(xiàn)的大粒度用例可切分成若干個小粒度子用例［8］，由各子系統(tǒng)負責完成相應子用例。其次分析用例的事件流，確定各子系統(tǒng)間依賴關(guān)系，定義系統(tǒng)接口［9］。通過用例結(jié)合迭代應用分析，考慮到該系統(tǒng)的分布式特點，系統(tǒng)采用三層架構(gòu)的組件COM+運行模式具有更大的優(yōu)勢。

組件的管理控制更適合于三層架構(gòu)的瘦客戶模式，對用戶端資源要求較低，而且可滿足用戶對軟件系統(tǒng)的集中控制和局部升級的需求。

三層組件模式可更好地支持分布式計算環(huán)境。邏輯層應用程序可以分布在多個機器上運行，從而迅速提高系統(tǒng)的運行速度。所以組件應用技術(shù)將是該信息系統(tǒng)開發(fā)的首選技術(shù)。

4 系統(tǒng)實現(xiàn)

依據(jù)系統(tǒng)用例迭代分析和病人掛號涉及的相關(guān)事務行為，我們從中抽象出對象類圖，推導出系統(tǒng)數(shù)據(jù)結(jié)構(gòu)，該文以掛號模塊為例進行簡要說明。

根據(jù)門診掛號系統(tǒng)類模型可以知，掛號行為涉及到病人的基本信息、掛號類型選擇及科室、醫(yī)療人員基本信息，最終組合成掛號單信息。

掛號業(yè)務規(guī)則包括檢驗數(shù)據(jù)的合理性和完整性、數(shù)學運算、篩選歸類等。其中，最基本的處理就是定位查找、顯示、修改和保存。但此處的定位查找，修改和保存操作應遵循業(yè)務規(guī)則進行數(shù)據(jù)處理，最后與數(shù)據(jù)庫的交互就依靠調(diào)用數(shù)據(jù)訪問組件來完成。掛號管理程序時序圖如圖5所示。

定位查找和修改兩個操作可以看作是保存操作的前期步驟，且修改操作只是對用戶界面的數(shù)據(jù)進行了變動，數(shù)據(jù)庫中的數(shù)據(jù)并不受影響。僅當用戶點擊了界面的“確認”按鍵，系統(tǒng)才將對數(shù)據(jù)庫中的數(shù)據(jù)進行相應的更改。其他類同此。

圖5 門診掛號管理程序時序圖

該文通過利用UML(unified modeling language)的概念結(jié)合實際應用，分析了如何在系統(tǒng)分析階段通過用例分析手段由淺到深、由粗到細地去分析用戶的業(yè)務需求。與傳統(tǒng)的系統(tǒng)分析方式相比，用例的分析方法完全是從事務的表象來定義系統(tǒng)的功能，它把需求與設計融合起來。在OOA(object-oriented analysis)面向?qū)ο蟮姆治鲈O計方法中，系統(tǒng)的功能性需求主要借用例模型來描述，系統(tǒng)的設計依附于用例模型的記錄描述［10］。用例也同時定義了其自身使用的內(nèi)部與外部環(huán)境，每一個用例描述被看作是一個獨立的功能服務。用例的分析方法也更易于被用戶所理解，可使開發(fā)人員和用戶之間針對系統(tǒng)需求進行溝通更加有效。

［1］金聯(lián)，黃霞．用例分析技術(shù)在軟件開發(fā)中的應用［J］．湖南工業(yè)職業(yè)技術(shù)學院學報，2005，5(4):22-24

［2］王楓，石冰心，羅莉敏．UML建模機制研究及在系統(tǒng)需求分析中的應用［J］．計算機工程與設計，2005，26(4):971-975

［3］毋國慶，梁正平，袁夢霆，等．軟件需求工程［M］．北京:機械工業(yè)出版社，2008:32-81

［4］黃國興，周勇．軟件需求工程［M］．北京:清華大學出版社，2008:55-156

［5］金軼，黃刊迪．利用UML建立醫(yī)院門診信息系統(tǒng)的用例模型［J］．醫(yī)學信息，2007，20(12):2004-2006

［6］邱郁惠．系統(tǒng)分析師UML用例實戰(zhàn)［M］．北京:機械工業(yè)出版社，2010:20-180

［7］陳建峽．基于UML的分析建模方法［J］．湖北工業(yè)大學學報，2005，20(4):45-48

［8］王鳳斌．UML面向?qū)ο蠼Ｔ诠芾硇畔⑾到y(tǒng)中的應用［J］．計算機與現(xiàn)代化，2005，(2):119-123

［9］談俊峰．用用例分析技術(shù)進行需求分析和構(gòu)架建模［J］．計算機工程與設計，2004，25(2):252-255

［10］李思廣，林子禹，胡峰，等．基于UML的軟件過程建模方法研究［J］．計算機工程與應用，2003，(6):76-78