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

周 巖

菏澤醫(yī)學(xué)?？茖W(xué)校網(wǎng)絡(luò)中心，山東 菏澤 274000

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

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

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

1 系統(tǒng)分析

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

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

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

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

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

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

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

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

1．3 對(duì)象模式的需求分析

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

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

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

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

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

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

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

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

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

2 系統(tǒng)設(shè)計(jì)

2．1 門診掛號(hào)

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

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

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

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

業(yè)務(wù)功能:門診建卡、補(bǔ)卡

使用角色:掛號(hào)員

功能簡(jiǎn)述:對(duì)就診卡信息進(jìn)行查詢、添加、修改和存儲(chǔ)操作。

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

請(qǐng)求結(jié)果:獲得就診卡、就診流水號(hào)。

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

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

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

在該用例中，掛號(hào)員是扮演啟動(dòng)角色的參與者。

2．2 醫(yī)師診療

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

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

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

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

使用角色:醫(yī)師

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖5 門診掛號(hào)管理程序時(shí)序圖

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

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

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

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

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

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

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

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

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

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

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