藥品管理系統(tǒng)架構(gòu)設(shè)計案例分析

06藥品管理系統(tǒng)架構(gòu)設(shè)計案例分析當(dāng)前第1頁\共有44頁\編于星期日\14點2需求分析需求分析的主要任務(wù)就是創(chuàng)建代表“目前”業(yè)務(wù)情況的業(yè)務(wù)模型，并將此業(yè)務(wù)模型轉(zhuǎn)換成“將來”的系統(tǒng)模型，包括功能需求和非功能需求。非功能需求又包括質(zhì)量屬性和各種約定。

通過對客戶的當(dāng)前業(yè)務(wù)的分析，我們得到當(dāng)前業(yè)務(wù)的基本需求。當(dāng)前第2頁\共有44頁\編于星期日\14點2需求分析

功能需求功能說明用戶管理用戶的創(chuàng)建、登錄、刪除和維護藥品管理藥品種類的添加、刪除和維護發(fā)貨單位管理發(fā)貨單位的添加、刪除和維護授補單位管理授補單位的添加、刪除和維護入庫批次管理添加入庫藥品、打印入庫單、簽字、入庫等出庫批次管理添加出庫藥品、打印出庫單、簽字、出庫等統(tǒng)計和查詢對庫存、已入庫和已出庫藥品數(shù)量統(tǒng)計效期管理對庫存藥品使用年限進行管理當(dāng)前第3頁\共有44頁\編于星期日\14點需求分析非功能需求質(zhì)量屬性說明可用性將系統(tǒng)的錯誤限制在可控制的范圍內(nèi)可修改性控制實現(xiàn)、測試和部署變更的時間和成本性能在一定的時間限制內(nèi)到達系統(tǒng)的事件生成一個響應(yīng)安全性抵抗一定的攻擊并從攻擊中恢復(fù)可測試性允許在完成軟件開發(fā)的一個增量后，較輕松地對軟件進行測試當(dāng)前第4頁\共有44頁\編于星期日\14點2需求分析2.1定義系統(tǒng)

(1)

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

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

(2)

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

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

當(dāng)前第9頁\共有44頁\編于星期日\14點2需求分析2.2

細(xì)化定義

(1)

細(xì)化用例

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

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

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

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

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

。.NetFramework3.0框架如下：當(dāng)前第20頁\共有44頁\編于星期日\14點基于三層結(jié)構(gòu)的框架如圖所示：當(dāng)前第21頁\共有44頁\編于星期日\14點框架講解：UI（界面層）：職責(zé)是數(shù)據(jù)的展現(xiàn)和采集，數(shù)據(jù)采集的結(jié)果通常以實體對象提交給業(yè)務(wù)邏輯層處理。BL（業(yè)務(wù)邏輯層）：職責(zé)是按預(yù)定的業(yè)務(wù)邏輯處理UI層提交的請求。

（1）

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

（2）業(yè)務(wù)流子層負(fù)責(zé)將業(yè)務(wù)功能子層提供的多個基本業(yè)務(wù)功能組織成一個完整的業(yè)務(wù)流（事務(wù)只能在業(yè)務(wù)流子層開啟）。當(dāng)前第22頁\共有44頁\編于星期日\14點RA（資源存取層）：職責(zé)是提供全面的資源訪問功能支持，并向上層屏蔽資源的來源。(1)BEM（業(yè)務(wù)實體管理子層）：采用數(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ù)據(jù)。當(dāng)前第23頁\共有44頁\編于星期日\14點規(guī)則（約束）：

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

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

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

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

Entity

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

class都會有一個BEM

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

Class來提供支持。

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

（7）UI層和BL層禁止出現(xiàn)任何SQL語句。當(dāng)前第24頁\共有44頁\編于星期日\14點.NetRemoting框架圖：

當(dāng)前第25頁\共有44頁\編于星期日\14點.NetRemoting框架介紹：.NetRemoting提供了一種允許

對象通過應(yīng)用程序域與另一個對象進行交互的框架。首先，客戶端通過Remoting，訪問通道以獲得服務(wù)端對象，再通過代理解析為客戶端對象。這就提供一種可能性，即以服務(wù)的方式來發(fā)布服務(wù)器對象。遠(yuǎn)程對象代碼可以運行在服務(wù)器上（如服務(wù)器激活的對象和客戶端激活的對象），然后客戶端再通過Remoting連接服務(wù)器，獲得該服務(wù)對象并通過序列化在客戶端運行。這種框架提供了許多種服務(wù)，包括激活和生存期支持，以及負(fù)責(zé)與遠(yuǎn)程應(yīng)用程序進行信息交互的通訊通道。當(dāng)前第26頁\共有44頁\編于星期日\14點框架選擇：

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

架構(gòu)的設(shè)計對系統(tǒng)質(zhì)量屬性的實現(xiàn)起著決定性的作用，而架構(gòu)的形成又是由這些質(zhì)量屬性驅(qū)動的。由于系統(tǒng)為簡單的MIS系統(tǒng)，因此，下面著重對數(shù)據(jù)存取層和業(yè)務(wù)邏輯層架構(gòu)的設(shè)計進行比較詳細(xì)的介紹。當(dāng)前第28頁\共有44頁\編于星期日\14點(1)

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

可維護性場景：

當(dāng)前第29頁\共有44頁\編于星期日\14點性能場景：

當(dāng)前第30頁\共有44頁\編于星期日\14點安全性場景：當(dāng)前第31頁\共有44頁\編于星期日\14點可維護性：架構(gòu)的設(shè)計不僅僅是面向客戶的，同樣需要面向開發(fā)人員的。在數(shù)據(jù)存取層中添加數(shù)據(jù)源訪問組件，通過在數(shù)據(jù)訪問層中添加一個數(shù)據(jù)庫配置組件，可以使系統(tǒng)的數(shù)據(jù)源快速的從一種類型轉(zhuǎn)換到另一種類型。滿足實際業(yè)務(wù)擴展需要。

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

當(dāng)前第33頁\共有44頁\編于星期日\14點數(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é)處理從存儲過程或查詢操作類返回的結(jié)果數(shù)據(jù)；在整個架構(gòu)中，凡是涉及到SQL語句參數(shù)的處理都交給類“SQL參數(shù)”?；谶@種架構(gòu)的數(shù)據(jù)存取過程，滿足上述的預(yù)期目標(biāo)。當(dāng)前第34頁\共有44頁\編于星期日\14點

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

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

(3)高效可靠的事務(wù)處理；(4)良好的可重用性和可維護性。當(dāng)前第35頁\共有44頁\編于星期日\14點Facade模式：當(dāng)前第36頁\共有44頁\編于星期日\14點業(yè)務(wù)邏輯層架構(gòu)設(shè)計：Fa?ade模式在本系統(tǒng)中應(yīng)用：

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

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

當(dāng)前第38頁\共有44頁\編于星期日\14點業(yè)務(wù)邏輯層架構(gòu)分析：

該業(yè)務(wù)邏輯層的架構(gòu)是前面Fa?ade模式的一種變形，他繼承了Fa?ade模式的所有優(yōu)點，同時，具體到我們的架構(gòu)中，它又實現(xiàn)了客戶端不必與業(yè)務(wù)對象直接交互。客戶端只需要輸入業(yè)務(wù)參數(shù)（業(yè)務(wù)請求對象），然后調(diào)用業(yè)務(wù)對象執(zhí)行器，通過對象執(zhí)行器委派到具體的事務(wù)處理對象，就可以通過結(jié)果響應(yīng)對象獲取業(yè)務(wù)執(zhí)行結(jié)果。該業(yè)務(wù)邏輯層架構(gòu)具備良好的維護性、可靠性和可擴展性。當(dāng)前第39頁\共有44頁\編于星期日\14點3系統(tǒng)架構(gòu)設(shè)計3.3結(jié)構(gòu)化設(shè)計模型