第6章藥品管理系統(tǒng)案例分析

第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第1頁。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第2頁。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第3頁。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第4頁。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第5頁。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第6頁。2需求分析2.1定義系統(tǒng)

(1)

捕捉系統(tǒng)通用術(shù)語通用術(shù)語：描述系統(tǒng)行為過程中經(jīng)常出現(xiàn)的名詞。通過捕捉系統(tǒng)通用術(shù)語可以避免在項(xiàng)目團(tuán)隊(duì)成員之間對它們的理解出現(xiàn)偏差造成誤解。

術(shù)語說明用戶信息即系統(tǒng)中的用戶信息，包括用戶名、密碼、聯(lián)系方式等入庫單表示采購藥品的具體情況效期藥品的最遲有效時(shí)間............第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第7頁。角色說明庫存管理員指負(fù)責(zé)記錄系統(tǒng)中藥品種類、出入庫管理的用戶管理員指負(fù)責(zé)系統(tǒng)中用戶的創(chuàng)建、維護(hù)和權(quán)限分配的用戶處長指對藥品出入庫單進(jìn)行確認(rèn)并簽字的人員外部系統(tǒng)指希望通過一定接口與本系統(tǒng)進(jìn)行交互的對象

(2)

捕捉系統(tǒng)中角色和用例通過捕捉系統(tǒng)中的角色和用例目的是定義系統(tǒng)的范圍，找出并描述系統(tǒng)內(nèi)、外部必須處理的內(nèi)容，以及那些與本系統(tǒng)需要進(jìn)行交互的人或外部系統(tǒng)。

系統(tǒng)角色如下：第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第8頁。用例說明管理用戶信息每個(gè)庫存管理員需要對藥品的出入庫進(jìn)行登記管理，必須由管理員創(chuàng)建該賬戶，并且對其進(jìn)行了一定的權(quán)限分配，并且管理員可以對該用戶信息進(jìn)行維護(hù)。同時(shí)，這些活動(dòng)必須包括登陸與推出功能。查詢和統(tǒng)計(jì)指向用戶提供按一定方式排列的藥品出入庫等相關(guān)信息。而且，還要提供方便的查詢，以便用戶可以迅速的查詢到制定的藥品。提交入庫單用戶根據(jù)具體情況需要從外面采購所需的藥品，在按照一定的方式填寫完成相關(guān)的信息時(shí)（為維護(hù)系統(tǒng)中存儲(chǔ)信息的一致性，一些相關(guān)的信息需要從系統(tǒng)已存儲(chǔ)的信息中讀?。纬扇霂靻?，提交給系統(tǒng)處理。根據(jù)已找出的系統(tǒng)角色，分析其對系統(tǒng)的具體要求，找出系統(tǒng)的各個(gè)用例。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第9頁。用例說明入庫單打印指用戶根據(jù)一定的查詢條件，選擇待打印的入庫批次信息，提交給系統(tǒng)處理，按一定的格式，打印出所需的實(shí)體入庫單。審查訂單指處長出、入庫單，核定相關(guān)信息，并簽字。藥品管理管理員根據(jù)所采購的藥品種類，維護(hù)系統(tǒng)中記錄的與業(yè)務(wù)相關(guān)的藥品種類信息。授補(bǔ)單位管理管理員根據(jù)庫存藥品出庫對象的相關(guān)信息，維護(hù)系統(tǒng)中記錄的收補(bǔ)單位信息。發(fā)貨單位管理管理員根據(jù)采購藥品的發(fā)貨單位相關(guān)信息，維護(hù)系統(tǒng)記錄的發(fā)貨單位信息。外部系統(tǒng)交互指系統(tǒng)根據(jù)以后的擴(kuò)展需要，為系統(tǒng)與外部系統(tǒng)交互預(yù)留一統(tǒng)一接口?！?章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第10頁。根據(jù)上述分析，可以得到下面業(yè)務(wù)用例模型：

第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第11頁。2需求分析2.2

細(xì)化定義

(1)

細(xì)化用例

細(xì)化業(yè)務(wù)用例模型，是為了更加詳細(xì)地分析和描述用例。同時(shí)，將業(yè)務(wù)用例模型轉(zhuǎn)換成系統(tǒng)的用例模型。下面，以“角色”庫存管理員交互的用例進(jìn)行細(xì)化為例。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第12頁。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第13頁。要素說明用例名稱提交入庫記錄簡要描述庫存管理員根據(jù)藥品采購具體情況、記錄選購藥品，形成入庫單，提交給系統(tǒng)處理。事件流基本事件流（1）庫存管理員在待入庫的藥品名稱欄中輸入待入庫的藥品名稱；（2）系統(tǒng)根據(jù)用戶輸入，以列表的形式羅列當(dāng)前系統(tǒng)中存儲(chǔ)的符合庫存管理員要求的藥品種類的詳細(xì)信息；細(xì)化用例后，還需對用例進(jìn)行詳細(xì)描述，直到所有涉眾都認(rèn)可描述的內(nèi)容已經(jīng)能夠正確表達(dá)出他們的需求為止。在RUP方法論中指明通過闡述一個(gè)用例的名稱、簡要描述、事件流、特殊需求、前置條件和后置條件等六個(gè)方面可以對用例進(jìn)行描述。下面以用例“提交入庫記錄”為例細(xì)化描述。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第14頁。要素說明事件流（3）庫存管理員根據(jù)實(shí)際情況的需求，選擇待入庫的藥品種類，并在各個(gè)入庫單項(xiàng)記錄的輸入框中輸入此入庫單項(xiàng)的相關(guān)信息（生產(chǎn)日期、有效日期、單價(jià)、發(fā)貨單位、核準(zhǔn)數(shù)量和實(shí)際數(shù)量），庫存管理員確認(rèn)信息無誤后，點(diǎn)擊“添加入庫單項(xiàng)”按鈕；（4）庫存管理員重復(fù)上面的工作，直至此次入庫記錄添加完畢；（5）系統(tǒng)羅列出庫存管理員此次入庫的所有入庫單項(xiàng)的詳細(xì)信息，庫存管理員確認(rèn)無誤后，點(diǎn)擊“添加入庫記錄”，系統(tǒng)根據(jù)數(shù)據(jù)庫中現(xiàn)有的入庫批次號自動(dòng)生成新的入庫批次，并將它們關(guān)聯(lián)起來。（6）該“提交入庫記錄”用例結(jié)束?！疤峤蝗霂煊涗洝睘槔?xì)化描述（續(xù)）第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第15頁。要素說明備選事件流庫存管理員在輸入待入庫的藥品種類名稱時(shí)，系統(tǒng)不能查詢到相關(guān)信息時(shí)，則按一下步驟進(jìn)行：（1）在系統(tǒng)未查詢到庫存管理員所需的相關(guān)藥品種類信息時(shí)，提示庫存管理員是否需要添加新的藥品種類信息；（2）其次，撤銷此次入庫記錄的提交。特殊需求系統(tǒng)要保證入庫信息的一致性和完整性，不允許偽造數(shù)據(jù)。界面操作要合理，要考慮到庫存管理員操作順序等問題。“提交入庫記錄”為例細(xì)化描述（續(xù)）第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第16頁。要素說明前置條件待入庫藥品種類信息必須存在，不存在的藥品種類不能入庫。后置條件當(dāng)入庫成功，相應(yīng)藥品的庫存信息要及時(shí)更新為最新狀態(tài)?！疤峤蝗霂煊涗洝睘槔?xì)化描述（續(xù)）第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第17頁。上面對用例的描述僅限于文字描述，還不夠形象。再以活動(dòng)圖的形式進(jìn)行建模描述如下：第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第18頁。(2)結(jié)構(gòu)化用例

結(jié)構(gòu)化用例的目的是通過觀察這些已經(jīng)細(xì)化的用例，看能不能抽取出共有的、可選的行為，把這些共同的內(nèi)容建立為新的用例。這樣的好處是，可以消除冗余的需要以及改善系統(tǒng)整體需求內(nèi)容的可維護(hù)性。像“提交入庫記錄”用例中，“添加新的藥品種類”應(yīng)作為一個(gè)新的用例提取出來，以提高上面所說的需求內(nèi)容的可維護(hù)性第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第19頁。3系統(tǒng)架構(gòu)設(shè)計(jì)架構(gòu)設(shè)計(jì)是將需求內(nèi)容轉(zhuǎn)換成設(shè)計(jì)模型的雛形以及用戶體驗(yàn)?zāi)Ｐ停淠康氖墙⒄麄€(gè)系統(tǒng)初步的解決方案，為詳細(xì)設(shè)計(jì)活動(dòng)打下基礎(chǔ)，這一階段的具體活動(dòng)如下：第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第20頁。3系統(tǒng)架構(gòu)設(shè)計(jì)3.1

體系結(jié)構(gòu)的選擇

決定采取分布式的還是集中式的體系結(jié)構(gòu)，將是一個(gè)影響系統(tǒng)性能、可縮放性、可靠性、易用性及此應(yīng)用所能支持的客戶端類型的重要決策問題。

根據(jù)前期的需求知道，系統(tǒng)是為某單位設(shè)計(jì)的，考慮到后期的系統(tǒng)推廣應(yīng)用的可能性，采取分布式的體系結(jié)構(gòu)將更適應(yīng)于今后的變化。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第21頁。根據(jù)前期對需求的分析，決定采取基于.NetFramework3.0框架來構(gòu)建此分布式的信息管理系統(tǒng)

。.NetFramework3.0框架如下：第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第22頁。基于三層結(jié)構(gòu)的框架如圖所示：第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第23頁?？蚣苤v解：UI（界面層）：職責(zé)是數(shù)據(jù)的展現(xiàn)和采集，數(shù)據(jù)采集的結(jié)果通常以實(shí)體對象提交給業(yè)務(wù)邏輯層處理。BL（業(yè)務(wù)邏輯層）：職責(zé)是按預(yù)定的業(yè)務(wù)邏輯處理UI層提交的請求。

（1）

業(yè)務(wù)功能子層負(fù)責(zé)基本業(yè)務(wù)功能的實(shí)現(xiàn)。

（2）業(yè)務(wù)流子層負(fù)責(zé)將業(yè)務(wù)功能子層提供的多個(gè)基本業(yè)務(wù)功能組織成一個(gè)完整的業(yè)務(wù)流（事務(wù)只能在業(yè)務(wù)流子層開啟）。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第24頁。RA（資源存取層）：職責(zé)是提供全面的資源訪問功能支持，并向上層屏蔽資源的來源。(1)BEM（業(yè)務(wù)實(shí)體管理子層）：采用數(shù)據(jù)存取子層和服務(wù)獲取子層來提供業(yè)務(wù)需要的基礎(chǔ)數(shù)據(jù)/資源訪問能力。(2)DA（數(shù)據(jù)存取子層）：負(fù)責(zé)從數(shù)據(jù)庫中存取資源，并向BEM子層屏蔽所有的SQL語句以及數(shù)據(jù)庫類型差異。

(3)SA（服務(wù)獲取子層）：用于以SOA的方式從外部系統(tǒng)獲取資源。(4)CA（配置文件存取子層）：用于從配置文件中獲取配置信息或?qū)⑴渲眯畔⒈４娴古渲梦募?。Entity（實(shí)體層）：跨越其他三層，在這些層之間傳遞數(shù)據(jù)。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第25頁。規(guī)則（約束）：

（1）系統(tǒng)各層次及層內(nèi)部子層次之間都不得跨層調(diào)用。

（2）Entity對象在各個(gè)層之間傳遞數(shù)據(jù)。

（3）需要在UI層綁定到列表的數(shù)據(jù)采用基于關(guān)系的數(shù)據(jù)集傳遞，除此之外，應(yīng)該使用Entity對象傳遞數(shù)據(jù)。

（4）對于每一個(gè)數(shù)據(jù)庫表（Table）都有一個(gè)DB

Entity

class與之對應(yīng)，針對每一個(gè)Entity

class都會(huì)有一個(gè)BEM

Class與之對應(yīng)。（5）有些跨數(shù)據(jù)庫或跨表的操作（如復(fù)雜的聯(lián)合查詢）也需要由相應(yīng)的BEM

Class來提供支持。

（6）對于相對簡單的系統(tǒng)，可以考慮將業(yè)務(wù)功能子層和業(yè)務(wù)流子層合并為一個(gè)。

（7）UI層和BL層禁止出現(xiàn)任何SQL語句。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第26頁。.NetRemoting框架圖：

第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第27頁。.NetRemoting框架介紹：.NetRemoting提供了一種允許

對象通過應(yīng)用程序域與另一個(gè)對象進(jìn)行交互的框架。首先，客戶端通過Remoting，訪問通道以獲得服務(wù)端對象，再通過代理解析為客戶端對象。這就提供一種可能性，即以服務(wù)的方式來發(fā)布服務(wù)器對象。遠(yuǎn)程對象代碼可以運(yùn)行在服務(wù)器上（如服務(wù)器激活的對象和客戶端激活的對象），然后客戶端再通過Remoting連接服務(wù)器，獲得該服務(wù)對象并通過序列化在客戶端運(yùn)行。這種框架提供了許多種服務(wù)，包括激活和生存期支持，以及負(fù)責(zé)與遠(yuǎn)程應(yīng)用程序進(jìn)行信息交互的通訊通道。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第28頁?？蚣苓x擇：

由于該系統(tǒng)僅在局域網(wǎng)內(nèi)使用，用戶數(shù)量有限，因此，決定采取局域網(wǎng)內(nèi)的分布式的桌面信息管理系統(tǒng)方式實(shí)現(xiàn)此系統(tǒng)。根據(jù)前面的分析，我們采用.NetFramework3.0框架實(shí)現(xiàn)該系統(tǒng)的，采用.NetRemoting實(shí)現(xiàn)客戶端與服務(wù)器端之間的通信。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第29頁。3系統(tǒng)架構(gòu)設(shè)計(jì)3.2系統(tǒng)架構(gòu)的分析與設(shè)計(jì)

架構(gòu)的設(shè)計(jì)對系統(tǒng)質(zhì)量屬性的實(shí)現(xiàn)起著決定性的作用，而架構(gòu)的形成又是由這些質(zhì)量屬性驅(qū)動(dòng)的。由于系統(tǒng)為簡單的MIS系統(tǒng)，因此，下面著重對數(shù)據(jù)存取層和業(yè)務(wù)邏輯層架構(gòu)的設(shè)計(jì)進(jìn)行比較詳細(xì)的介紹。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第30頁。(1)

數(shù)據(jù)持久層的架構(gòu)分析與設(shè)計(jì)

可維護(hù)性場景：

第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第31頁。性能場景：

第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第32頁。安全性場景：第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第33頁?？删S護(hù)性：架構(gòu)的設(shè)計(jì)不僅僅是面向客戶的，同樣需要面向開發(fā)人員的。在數(shù)據(jù)存取層中添加數(shù)據(jù)源訪問組件，通過在數(shù)據(jù)訪問層中添加一個(gè)數(shù)據(jù)庫配置組件，可以使系統(tǒng)的數(shù)據(jù)源快速的從一種類型轉(zhuǎn)換到另一種類型。滿足實(shí)際業(yè)務(wù)擴(kuò)展需要。

性能：由于系統(tǒng)采用分布式的結(jié)構(gòu)，雖然用戶數(shù)量有限，但如果用戶頻繁的向服務(wù)器端發(fā)送請求，勢必導(dǎo)致系統(tǒng)性能下降。因此，在數(shù)據(jù)存取層中添加SQL訪問組件，實(shí)現(xiàn)對數(shù)據(jù)庫更新操作的批量處理，減少訪問數(shù)據(jù)庫的頻度，對系統(tǒng)性能的提升有一定得幫助。安全性：數(shù)據(jù)的并發(fā)訪問是分布式系統(tǒng)的中的潛在威脅。同一時(shí)間，不同客戶端對同一數(shù)據(jù)記錄進(jìn)行操作必然存在并發(fā)一致性問題，如：丟失修改、不可重復(fù)讀和讀臟數(shù)據(jù)等。本架構(gòu)通過數(shù)據(jù)庫事務(wù)處理組件對這一問題進(jìn)行控制。數(shù)據(jù)庫事務(wù)處理組件通過對事務(wù)進(jìn)行隔離級別劃分的機(jī)制，維持了數(shù)據(jù)庫的ACID（原子性、一致性、獨(dú)立性和持久性）要求，提高了系統(tǒng)的安全性。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第34頁。滿足以上質(zhì)量場景的數(shù)據(jù)存取層架構(gòu)：

第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第35頁。數(shù)據(jù)存取架構(gòu)分析：

該架構(gòu)主要包括：數(shù)據(jù)源組件、SQL訪問組件、SQL參數(shù)和結(jié)果集處理組件四大模塊。其中，數(shù)據(jù)源組件主要負(fù)責(zé)數(shù)據(jù)庫連接的管理；SQL訪問組件負(fù)責(zé)數(shù)據(jù)庫服務(wù)器的交互；結(jié)果處理組件模塊負(fù)責(zé)處理從存儲(chǔ)過程或查詢操作類返回的結(jié)果數(shù)據(jù)；在整個(gè)架構(gòu)中，凡是涉及到SQL語句參數(shù)的處理都交給類“SQL參數(shù)”?；谶@種架構(gòu)的數(shù)據(jù)存取過程，滿足上述的預(yù)期目標(biāo)。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第36頁。

(2)業(yè)務(wù)邏輯層架構(gòu)設(shè)計(jì)：

業(yè)務(wù)邏輯層作為MIS系統(tǒng)的關(guān)鍵部分，對系統(tǒng)的靈活性實(shí)現(xiàn)起著決定性的作用。在本系統(tǒng)的業(yè)務(wù)邏輯層架構(gòu)層中，采取了Fa?ade模式，下面簡單介紹一下Fa?ade模式的好處：(1)網(wǎng)絡(luò)開銷小，客戶只需要和一個(gè)“門面Fa?ade”交互，只要一個(gè)網(wǎng)絡(luò)調(diào)用就可以完成業(yè)務(wù)邏輯；(2)客戶端表示層和業(yè)務(wù)邏輯層得到解耦，完全分離；

(3)高效可靠的事務(wù)處理；(4)良好的可重用性和可維護(hù)性。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第37頁。Facade模式：第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第38頁。業(yè)務(wù)邏輯層架構(gòu)設(shè)計(jì)：Fa?ade模式在本系統(tǒng)中應(yīng)用：

通過前期的需求分析，我們將業(yè)務(wù)用例模型中需要完成的業(yè)務(wù)流，分解成原子級的業(yè)務(wù)功能（圖中的小圓圈），通過業(yè)務(wù)流（門面Facade）的整合，以實(shí)現(xiàn)業(yè)務(wù)用例模型中的預(yù)期用例功能。在系統(tǒng)開發(fā)期間，可以將業(yè)務(wù)流和業(yè)務(wù)功能的具體實(shí)現(xiàn)很好的解耦合，每個(gè)“門面Fa?ade”可以認(rèn)為成對應(yīng)了一個(gè)系統(tǒng)功能子系統(tǒng)，為系統(tǒng)的并行開發(fā)提供了可能。通過Fa?ade模式，給系統(tǒng)的可維護(hù)性和性能等質(zhì)量屬性實(shí)現(xiàn)，奠定了很好的基礎(chǔ)。根據(jù)前面分析知，系統(tǒng)采用基于.NetFramework3.0平臺(tái)的Remoting技術(shù)實(shí)現(xiàn)分布式的。在Remoting技術(shù)中，客戶端通過遠(yuǎn)程調(diào)用服務(wù)器端注冊的業(yè)務(wù)功能組件的指針，完成自身的業(yè)務(wù)處理需要。這種遠(yuǎn)程調(diào)用的機(jī)制雖然占用一定的網(wǎng)絡(luò)流量，但它對于系統(tǒng)代碼的安全性起到一定的保護(hù)作用。同時(shí)，方便系統(tǒng)的升級。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第39頁。

業(yè)務(wù)邏輯層的一種可用框架：

第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第40頁。業(yè)務(wù)邏輯層架構(gòu)分析：

該業(yè)務(wù)邏輯層的架構(gòu)是前面Fa?ade模式的一種變形，他繼承了Fa?ade模式的所有優(yōu)點(diǎn)，同時(shí)，具體到我們的架構(gòu)中，它又實(shí)現(xiàn)了客戶端不必與業(yè)務(wù)對象直接交互?？蛻舳酥恍枰斎霕I(yè)務(wù)參數(shù)（業(yè)務(wù)請求對象），然后調(diào)用業(yè)務(wù)對象執(zhí)行器，通過對象執(zhí)行器委派到具體的事務(wù)處理對象，就可以通過結(jié)果響應(yīng)對象獲取業(yè)務(wù)執(zhí)行結(jié)果。該業(yè)務(wù)邏輯層架構(gòu)具備良好的維護(hù)性、可靠性和可擴(kuò)展性。第6章藥品管理系統(tǒng)案例分析全文共48頁，當(dāng)前為第41頁。3系統(tǒng)架構(gòu)設(shè)計(jì)3.3結(jié)構(gòu)化設(shè)計(jì)模型

確定設(shè)計(jì)模型的結(jié)構(gòu)化也就是根據(jù)設(shè)計(jì)需要定義出若干設(shè)計(jì)包。

包的設(shè)計(jì)原則：(1)包的內(nèi)聚性

重用等價(jià)模型

共同重用原則

共同封閉原則

(2)包的耦合性