藥品管理系統架構設計案例分析

藥品管理系統架構設計案例分析

第一頁，共四十七頁。1項目背景某單位需要統一管理所采購的藥品，采購的藥品總數已逾千種，傳統的手工管理方式難以適應當今藥品管理種類繁多、流動量大、調配程序復雜等特點，存在著很多不足之處。為了適應當前的業(yè)務發(fā)展需要，準備開發(fā)一套信息管理系統，對所采購的藥品進行有效的管理。第二頁，共四十七頁。2需求分析需求分析的主要任務就是創(chuàng)建代表“目前”業(yè)務情況的業(yè)務模型，并將此業(yè)務模型轉換成“將來”的系統模型，包括功能需求和非功能需求。非功能需求又包括質量屬性和各種約定。

通過對客戶的當前業(yè)務的分析，我們得到當前業(yè)務的基本需求。第三頁，共四十七頁。2需求分析功能需求功能說明用戶管理用戶的創(chuàng)建、登錄、刪除和維護藥品管理藥品種類的添加、刪除和維護發(fā)貨單位管理發(fā)貨單位的添加、刪除和維護授補單位管理授補單位的添加、刪除和維護入庫批次管理添加入庫藥品、打印入庫單、簽字、入庫等出庫批次管理添加出庫藥品、打印出庫單、簽字、出庫等統計和查詢對庫存、已入庫和已出庫藥品數量統計效期管理對庫存藥品使用年限進行管理第四頁，共四十七頁。需求分析

非功能需求質量屬性說明可用性將系統的錯誤限制在可控制的范圍內可修改性控制實現、測試和部署變更的時間和成本性能在一定的時間限制內到達系統的事件生成一個響應安全性抵抗一定的攻擊并從攻擊中恢復可測試性允許在完成軟件開發(fā)的一個增量后，較輕松地對軟件進行測試第五頁，共四十七頁。2需求分析2.1定義系統

(1)

捕捉系統通用術語通用術語：描述系統行為過程中經常出現的名詞。通過捕捉系統通用術語可以避免在項目團隊成員之間對它們的理解出現偏差造成誤解。

術語說明用戶信息即系統中的用戶信息，包括用戶名、密碼、聯系方式等入庫單表示采購藥品的具體情況效期藥品的最遲有效時間............第六頁，共四十七頁。角色說明庫存管理員指負責記錄系統中藥品種類、出入庫管理的用戶管理員指負責系統中用戶的創(chuàng)建、維護和權限分配的用戶處長指對藥品出入庫單進行確認并簽字的人員外部系統指希望通過一定接口與本系統進行交互的對象

(2)

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

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

第十頁，共四十七頁。2需求分析2.2

細化定義

(1)

細化用例

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

結構化用例的目的是通過觀察這些已經細化的用例，看能不能抽取出共有的、可選的行為，把這些共同的內容建立為新的用例。這樣的好處是，可以消除冗余的需要以及改善系統整體需求內容的可維護性。像“提交入庫記錄”用例中，“添加新的藥品種類”應作為一個新的用例提取出來，以提高上面所說的需求內容的可維護性第十八頁，共四十七頁。3系統架構設計架構設計是將需求內容轉換成設計模型的雛形以及用戶體驗模型，其目的是建立整個系統初步的解決方案，為詳細設計活動打下基礎，這一階段的具體活動如下：第十九頁，共四十七頁。3系統架構設計3.1

體系結構的選擇

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

根據前期的需求知道，系統是為某單位設計的，考慮到后期的系統推廣應用的可能性，采取分布式的體系結構將更適應于今后的變化。第二十頁，共四十七頁。根據前期對需求的分析，決定采取基于.NetFramework3.0框架來構建此分布式的信息管理系統

。.NetFramework3.0框架如下：第二十一頁，共四十七頁?；谌龑咏Y構的框架如圖所示：第二十二頁，共四十七頁?？蚣苤v解：UI（界面層）：職責是數據的展現和采集，數據采集的結果通常以實體對象提交給業(yè)務邏輯層處理。BL（業(yè)務邏輯層）：職責是按預定的業(yè)務邏輯處理UI層提交的請求。

（1）

業(yè)務功能子層負責基本業(yè)務功能的實現。

（2）業(yè)務流子層負責將業(yè)務功能子層提供的多個基本業(yè)務功能組織成一個完整的業(yè)務流（事務只能在業(yè)務流子層開啟）。第二十三頁，共四十七頁。RA（資源存取層）：職責是提供全面的資源訪問功能支持，并向上層屏蔽資源的來源。(1)BEM（業(yè)務實體管理子層）：采用數據存取子層和服務獲取子層來提供業(yè)務需要的基礎數據/資源訪問能力。(2)DA（數據存取子層）：負責從數據庫中存取資源，并向BEM子層屏蔽所有的SQL語句以及數據庫類型差異。

(3)SA（服務獲取子層）：用于以SOA的方式從外部系統獲取資源。(4)CA（配置文件存取子層）：用于從配置文件中獲取配置信息或將配置信息保存倒配置文件。Entity（實體層）：跨越其他三層，在這些層之間傳遞數據。第二十四頁，共四十七頁。規(guī)則（約束）：

（1）系統各層次及層內部子層次之間都不得跨層調用。

（2）Entity對象在各個層之間傳遞數據。

（3）需要在UI層綁定到列表的數據采用基于關系的數據集傳遞，除此之外，應該使用Entity對象傳遞數據。

（4）對于每一個數據庫表（Table）都有一個DB

Entity

class與之對應，針對每一個Entity

class都會有一個BEM

Class與之對應。（5）有些跨數據庫或跨表的操作（如復雜的聯合查詢）也需要由相應的BEM

Class來提供支持。

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

（7）UI層和BL層禁止出現任何SQL語句。第二十五頁，共四十七頁。.NetRemoting框架圖：

第二十六頁，共四十七頁。.NetRemoting框架介紹：.NetRemoting提供了一種允許

對象通過應用程序域與另一個對象進行交互的框架。首先，客戶端通過Remoting，訪問通道以獲得服務端對象，再通過代理解析為客戶端對象。這就提供一種可能性，即以服務的方式來發(fā)布服務器對象。遠程對象代碼可以運行在服務器上（如服務器激活的對象和客戶端激活的對象），然后客戶端再通過Remoting連接服務器，獲得該服務對象并通過序列化在客戶端運行。這種框架提供了許多種服務，包括激活和生存期支持，以及負責與遠程應用程序進行信息交互的通訊通道。第二十七頁，共四十七頁?？蚣苓x擇：

由于該系統僅在局域網內使用，用戶數量有限，因此，決定采取局域網內的分布式的桌面信息管理系統方式實現此系統。根據前面的分析，我們采用.NetFramework3.0框架實現該系統的，采用.NetRemoting實現客戶端與服務器端之間的通信。第二十八頁，共四十七頁。3系統架構設計3.2系統架構的分析與設計

架構的設計對系統質量屬性的實現起著決定性的作用，而架構的形成又是由這些質量屬性驅動的。由于系統為簡單的MIS系統，因此，下面著重對數據存取層和業(yè)務邏輯層架構的設計進行比較詳細的介紹。第二十九頁，共四十七頁。(1)

數據持久層的架構分析與設計

可維護性場景：

第三十頁，共四十七頁。性能場景：

第三十一頁，共四十七頁。安全性場景：第三十二頁，共四十七頁。可維護性：架構的設計不僅僅是面向客戶的，同樣需要面向開發(fā)人員的。在數據存取層中添加數據源訪問組件，通過在數據訪問層中添加一個數據庫配置組件，可以使系統的數據源快速的從一種類型轉換到另一種類型。滿足實際業(yè)務擴展需要。

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

第三十四頁，共四十七頁。數據存取架構分析：

該架構主要包括：數據源組件、SQL訪問組件、SQL參數和結果集處理組件四大模塊。其中，數據源組件主要負責數據庫連接的管理；SQL訪問組件負責數據庫服務器的交互；結果處理組件模塊負責處理從存儲過程或查詢操作類返回的結果數據；在整個架構中，凡是涉及到SQL語句參數的處理都交給類“SQL參數”?；谶@種架構的數據存取過程，滿足上述的預期目標。第三十五頁，共四十七頁。

(2)業(yè)務邏輯層架構設計：

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

(3)高效可靠的事務處理；(4)良好的可重用性和可維護性。第三十六頁，共四十七頁。Facade模式：第三十七頁，共四十七頁。業(yè)務邏輯層架構設計：Fa?ade模式在本系統中應用：

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

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

第三十九頁，共四十七頁。業(yè)務邏輯層架構分析：

該業(yè)務邏輯層的架構是前面Fa?ade模式的一種變形，他繼承了Fa?ade模式的所有優(yōu)點，同時，具體到我們的架構中，它又實現了客戶端不必與業(yè)務對象直接交互?？蛻舳酥恍枰斎霕I(yè)務參數（業(yè)務請求對象），然后調用業(yè)務對象執(zhí)行器，通過對象執(zhí)行器委派到具體的事務處理對象，就可以通過結果響應對象獲取業(yè)務執(zhí)行結果。該業(yè)務邏輯層架構具備良好的維護性、可靠性和可擴展性。第四十頁，共四十七頁。3系統架構設計3.3結構化設計模型

確定設計模型的結構化也就是根據設計需要定義出若干設計包。

包的設計原則：(1)包的內聚性

重用等價模型

共同重用原則

共同封閉原則

(2)包的耦合性

無環(huán)依賴原則

穩(wěn)定依賴原則

穩(wěn)定抽象原則第四十一頁，共四十七頁。包的劃分主要有兩種：

按照子系統來分：

第四十二頁，共四十七頁。按照架構層次來分：