用例分析技術在醫院門診信息系統需求分析中的應用

周 巖

菏澤醫學專科學校網絡中心，山東 菏澤 274000

用例分析技術是通過參與者以及用例間的關系來描繪系統內外可見的需求，是用戶和開發人員共同塑造系統的合作區間。用例被定義為是一組動作序列的描述，被系統執行后，參與者會獲得可見結果。

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

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

1 系統分析

1．1 門診組織結構的前期分析

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

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

1．2 從參與者入手的系統分析

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

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

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

首先，病人作為掛號事件的驅動者，觸發掛號系統，通過交互操作，產生的結果(數據)流向下一個環節(醫師診療系統);醫師和病人是診療系統的事件驅動者，醫師通過交互操作，產生的結果(數據)流向不同的環節(收費、治療、門診藥房、檢查、檢驗);收費員和病人是收費事件的驅動者，觸發收費系統，通過交互操作，產生的結果(數據)流向相應環節(治療、門診藥房、檢查、檢驗);各相關事件驅動者驅動治療、門診藥房、檢查、檢驗等子系統后，通過交互操作，產生的相應結果(數據)返回醫師診療系統。

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

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

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

圖1 醫院門診相關用例結構圖

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

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

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

圖2 各子系統用例及關系結構圖

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

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

2 系統設計

2．1 門診掛號

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

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

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

主題區域:門診掛號就診卡子模塊

業務功能:門診建卡、補卡

使用角色:掛號員

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

發生條件:以掛號室人員身份登錄系統，獲得所有管理權限;病人掛號;信息查詢。

請求結果:獲得就診卡、就診流水號。

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

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

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

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

2．2 醫師診療

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

醫師是外部參與者，醫師從候診隊列選取病人，獲取病人就診信息，體檢后錄入藥品醫囑。藥品信息來源于藥品庫存信息，生成電子處方保存至數據庫。在此環節生成的醫囑數據會被收款和藥房等后續環節調用。

主題區域:門診醫師診療子模塊

業務功能:藥品醫囑錄入及生成處方

使用角色:醫師

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

發生條件:以門診醫師身份登錄系統，獲得管理權限并成功叫號。

請求結果:生成藥品處方。

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

圖4 藥品醫囑用例圖

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

3 系統關鍵技術

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

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

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

4 系統實現

依據系統用例迭代分析和病人掛號涉及的相關事務行為，我們從中抽象出對象類圖，推導出系統數據結構，該文以掛號模塊為例進行簡要說明。

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

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

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

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

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

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

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

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

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

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

［6］邱郁惠．系統分析師UML用例實戰［M］．北京:機械工業出版社，2010:20-180

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

［8］王鳳斌．UML面向對象建模在管理信息系統中的應用［J］．計算機與現代化，2005，(2):119-123

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

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