药品管理系统架构设计案例分析

06药品管理系统架构设计案例分析当前第1页\共有44页\编于星期日\14点2需求分析需求分析的主要任务就是创建代表“目前”业务情况的业务模型，并将此业务模型转换成“将来”的系统模型，包括功能需求和非功能需求。非功能需求又包括质量属性和各种约定。

通过对客户的当前业务的分析，我们得到当前业务的基本需求。当前第2页\共有44页\编于星期日\14点2需求分析

功能需求功能说明用户管理用户的创建、登录、删除和维护药品管理药品种类的添加、删除和维护发货单位管理发货单位的添加、删除和维护授补单位管理授补单位的添加、删除和维护入库批次管理添加入库药品、打印入库单、签字、入库等出库批次管理添加出库药品、打印出库单、签字、出库等统计和查询对库存、已入库和已出库药品数量统计效期管理对库存药品使用年限进行管理当前第3页\共有44页\编于星期日\14点需求分析非功能需求质量属性说明可用性将系统的错误限制在可控制的范围内可修改性控制实现、测试和部署变更的时间和成本性能在一定的时间限制内到达系统的事件生成一个响应安全性抵抗一定的攻击并从攻击中恢复可测试性允许在完成软件开发的一个增量后，较轻松地对软件进行测试当前第4页\共有44页\编于星期日\14点2需求分析2.1定义系统

(1)

捕捉系统通用术语通用术语：描述系统行为过程中经常出现的名词。通过捕捉系统通用术语可以避免在项目团队成员之间对它们的理解出现偏差造成误解。

术语说明用户信息即系统中的用户信息，包括用户名、密码、联系方式等入库单表示采购药品的具体情况效期药品的最迟有效时间............当前第5页\共有44页\编于星期日\14点角色说明库存管理员指负责记录系统中药品种类、出入库管理的用户管理员指负责系统中用户的创建、维护和权限分配的用户处长指对药品出入库单进行确认并签字的人员外部系统指希望通过一定接口与本系统进行交互的对象

(2)

捕捉系统中角色和用例通过捕捉系统中的角色和用例目的是定义系统的范围，找出并描述系统内、外部必须处理的内容，以及那些与本系统需要进行交互的人或外部系统。

系统角色如下：当前第6页\共有44页\编于星期日\14点用例说明管理用户信息每个库存管理员需要对药品的出入库进行登记管理，必须由管理员创建该账户，并且对其进行了一定的权限分配，并且管理员可以对该用户信息进行维护。同时，这些活动必须包括登陆与推出功能。查询和统计指向用户提供按一定方式排列的药品出入库等相关信息。而且，还要提供方便的查询，以便用户可以迅速的查询到制定的药品。提交入库单用户根据具体情况需要从外面采购所需的药品，在按照一定的方式填写完成相关的信息时（为维护系统中存储信息的一致性，一些相关的信息需要从系统已存储的信息中读取），形成入库单，提交给系统处理。根据已找出的系统角色，分析其对系统的具体要求，找出系统的各个用例。当前第7页\共有44页\编于星期日\14点用例说明入库单打印指用户根据一定的查询条件，选择待打印的入库批次信息，提交给系统处理，按一定的格式，打印出所需的实体入库单。审查订单指处长出、入库单，核定相关信息，并签字。药品管理管理员根据所采购的药品种类，维护系统中记录的与业务相关的药品种类信息。授补单位管理管理员根据库存药品出库对象的相关信息，维护系统中记录的收补单位信息。发货单位管理管理员根据采购药品的发货单位相关信息，维护系统记录的发货单位信息。外部系统交互指系统根据以后的扩展需要，为系统与外部系统交互预留一统一接口。…………当前第8页\共有44页\编于星期日\14点根据上述分析，可以得到下面业务用例模型：

当前第9页\共有44页\编于星期日\14点2需求分析2.2

细化定义

(1)

细化用例

细化业务用例模型，是为了更加详细地分析和描述用例。同时，将业务用例模型转换成系统的用例模型。下面，以“角色”库存管理员交互的用例进行细化为例。当前第10页\共有44页\编于星期日\14点当前第11页\共有44页\编于星期日\14点要素说明用例名称提交入库记录简要描述库存管理员根据药品采购具体情况、记录选购药品，形成入库单，提交给系统处理。事件流基本事件流（1）库存管理员在待入库的药品名称栏中输入待入库的药品名称；（2）系统根据用户输入，以列表的形式罗列当前系统中存储的符合库存管理员要求的药品种类的详细信息；细化用例后，还需对用例进行详细描述，直到所有涉众都认可描述的内容已经能够正确表达出他们的需求为止。在RUP方法论中指明通过阐述一个用例的名称、简要描述、事件流、特殊需求、前置条件和后置条件等六个方面可以对用例进行描述。下面以用例“提交入库记录”为例细化描述。当前第12页\共有44页\编于星期日\14点要素说明事件流（3）库存管理员根据实际情况的需求，选择待入库的药品种类，并在各个入库单项记录的输入框中输入此入库单项的相关信息（生产日期、有效日期、单价、发货单位、核准数量和实际数量），库存管理员确认信息无误后，点击“添加入库单项”按钮；（4）库存管理员重复上面的工作，直至此次入库记录添加完毕；（5）系统罗列出库存管理员此次入库的所有入库单项的详细信息，库存管理员确认无误后，点击“添加入库记录”，系统根据数据库中现有的入库批次号自动生成新的入库批次，并将它们关联起来。（6）该“提交入库记录”用例结束。“提交入库记录”为例细化描述（续）当前第13页\共有44页\编于星期日\14点要素说明备选事件流库存管理员在输入待入库的药品种类名称时，系统不能查询到相关信息时，则按一下步骤进行：（1）在系统未查询到库存管理员所需的相关药品种类信息时，提示库存管理员是否需要添加新的药品种类信息；（2）其次，撤销此次入库记录的提交。特殊需求系统要保证入库信息的一致性和完整性，不允许伪造数据。界面操作要合理，要考虑到库存管理员操作顺序等问题。“提交入库记录”为例细化描述（续）当前第14页\共有44页\编于星期日\14点要素说明前置条件待入库药品种类信息必须存在，不存在的药品种类不能入库。后置条件当入库成功，相应药品的库存信息要及时更新为最新状态。“提交入库记录”为例细化描述（续）当前第15页\共有44页\编于星期日\14点上面对用例的描述仅限于文字描述，还不够形象。再以活动图的形式进行建模描述如下：当前第16页\共有44页\编于星期日\14点(2)结构化用例

结构化用例的目的是通过观察这些已经细化的用例，看能不能抽取出共有的、可选的行为，把这些共同的内容建立为新的用例。这样的好处是，可以消除冗余的需要以及改善系统整体需求内容的可维护性。像“提交入库记录”用例中，“添加新的药品种类”应作为一个新的用例提取出来，以提高上面所说的需求内容的可维护性当前第17页\共有44页\编于星期日\14点3系统架构设计架构设计是将需求内容转换成设计模型的雏形以及用户体验模型，其目的是建立整个系统初步的解决方案，为详细设计活动打下基础，这一阶段的具体活动如下：当前第18页\共有44页\编于星期日\14点3系统架构设计3.1

体系结构的选择

决定采取分布式的还是集中式的体系结构，将是一个影响系统性能、可缩放性、可靠性、易用性及此应用所能支持的客户端类型的重要决策问题。

根据前期的需求知道，系统是为某单位设计的，考虑到后期的系统推广应用的可能性，采取分布式的体系结构将更适应于今后的变化。当前第19页\共有44页\编于星期日\14点根据前期对需求的分析，决定采取基于.NetFramework3.0框架来构建此分布式的信息管理系统

。.NetFramework3.0框架如下：当前第20页\共有44页\编于星期日\14点基于三层结构的框架如图所示：当前第21页\共有44页\编于星期日\14点框架讲解：UI（界面层）：职责是数据的展现和采集，数据采集的结果通常以实体对象提交给业务逻辑层处理。BL（业务逻辑层）：职责是按预定的业务逻辑处理UI层提交的请求。

（1）

业务功能子层负责基本业务功能的实现。

（2）业务流子层负责将业务功能子层提供的多个基本业务功能组织成一个完整的业务流（事务只能在业务流子层开启）。当前第22页\共有44页\编于星期日\14点RA（资源存取层）：职责是提供全面的资源访问功能支持，并向上层屏蔽资源的来源。(1)BEM（业务实体管理子层）：采用数据存取子层和服务获取子层来提供业务需要的基础数据/资源访问能力。(2)DA（数据存取子层）：负责从数据库中存取资源，并向BEM子层屏蔽所有的SQL语句以及数据库类型差异。

(3)SA（服务获取子层）：用于以SOA的方式从外部系统获取资源。(4)CA（配置文件存取子层）：用于从配置文件中获取配置信息或将配置信息保存倒配置文件。Entity（实体层）：跨越其他三层，在这些层之间传递数据。当前第23页\共有44页\编于星期日\14点规则（约束）：

（1）系统各层次及层内部子层次之间都不得跨层调用。

（2）Entity对象在各个层之间传递数据。

（3）需要在UI层绑定到列表的数据采用基于关系的数据集传递，除此之外，应该使用Entity对象传递数据。

（4）对于每一个数据库表（Table）都有一个DB

Entity

class与之对应，针对每一个Entity

class都会有一个BEM

Class与之对应。（5）有些跨数据库或跨表的操作（如复杂的联合查询）也需要由相应的BEM

Class来提供支持。

（6）对于相对简单的系统，可以考虑将业务功能子层和业务流子层合并为一个。

（7）UI层和BL层禁止出现任何SQL语句。当前第24页\共有44页\编于星期日\14点.NetRemoting框架图：

当前第25页\共有44页\编于星期日\14点.NetRemoting框架介绍：.NetRemoting提供了一种允许

对象通过应用程序域与另一个对象进行交互的框架。首先，客户端通过Remoting，访问通道以获得服务端对象，再通过代理解析为客户端对象。这就提供一种可能性，即以服务的方式来发布服务器对象。远程对象代码可以运行在服务器上（如服务器激活的对象和客户端激活的对象），然后客户端再通过Remoting连接服务器，获得该服务对象并通过序列化在客户端运行。这种框架提供了许多种服务，包括激活和生存期支持，以及负责与远程应用程序进行信息交互的通讯通道。当前第26页\共有44页\编于星期日\14点框架选择：

由于该系统仅在局域网内使用，用户数量有限，因此，决定采取局域网内的分布式的桌面信息管理系统方式实现此系统。根据前面的分析，我们采用.NetFramework3.0框架实现该系统的，采用.NetRemoting实现客户端与服务器端之间的通信。当前第27页\共有44页\编于星期日\14点3系统架构设计3.2系统架构的分析与设计

架构的设计对系统质量属性的实现起着决定性的作用，而架构的形成又是由这些质量属性驱动的。由于系统为简单的MIS系统，因此，下面着重对数据存取层和业务逻辑层架构的设计进行比较详细的介绍。当前第28页\共有44页\编于星期日\14点(1)

数据持久层的架构分析与设计

可维护性场景：

当前第29页\共有44页\编于星期日\14点性能场景：

当前第30页\共有44页\编于星期日\14点安全性场景：当前第31页\共有44页\编于星期日\14点可维护性：架构的设计不仅仅是面向客户的，同样需要面向开发人员的。在数据存取层中添加数据源访问组件，通过在数据访问层中添加一个数据库配置组件，可以使系统的数据源快速的从一种类型转换到另一种类型。满足实际业务扩展需要。

性能：由于系统采用分布式的结构，虽然用户数量有限，但如果用户频繁的向服务器端发送请求，势必导致系统性能下降。因此，在数据存取层中添加SQL访问组件，实现对数据库更新操作的批量处理，减少访问数据库的频度，对系统性能的提升有一定得帮助。安全性：数据的并发访问是分布式系统的中的潜在威胁。同一时间，不同客户端对同一数据记录进行操作必然存在并发一致性问题，如：丢失修改、不可重复读和读脏数据等。本架构通过数据库事务处理组件对这一问题进行控制。数据库事务处理组件通过对事务进行隔离级别划分的机制，维持了数据库的ACID（原子性、一致性、独立性和持久性）要求，提高了系统的安全性。当前第32页\共有44页\编于星期日\14点满足以上质量场景的数据存取层架构：

当前第33页\共有44页\编于星期日\14点数据存取架构分析：

该架构主要包括：数据源组件、SQL访问组件、SQL参数和结果集处理组件四大模块。其中，数据源组件主要负责数据库连接的管理；SQL访问组件负责数据库服务器的交互；结果处理组件模块负责处理从存储过程或查询操作类返回的结果数据；在整个架构中，凡是涉及到SQL语句参数的处理都交给类“SQL参数”。基于这种架构的数据存取过程，满足上述的预期目标。当前第34页\共有44页\编于星期日\14点

(2)业务逻辑层架构设计：

业务逻辑层作为MIS系统的关键部分，对系统的灵活性实现起着决定性的作用。在本系统的业务逻辑层架构层中，采取了Façade模式，下面简单介绍一下Façade模式的好处：(1)网络开销小，客户只需要和一个“门面Façade”交互，只要一个网络调用就可以完成业务逻辑；(2)客户端表示层和业务逻辑层得到解耦，完全分离；

(3)高效可靠的事务处理；(4)良好的可重用性和可维护性。当前第35页\共有44页\编于星期日\14点Facade模式：当前第36页\共有44页\编于星期日\14点业务逻辑层架构设计：Façade模式在本系统中应用：

通过前期的需求分析，我们将业务用例模型中需要完成的业务流，分解成原子级的业务功能（图中的小圆圈），通过业务流（门面Facade）的整合，以实现业务用例模型中的预期用例功能。在系统开发期间，可以将业务流和业务功能的具体实现很好的解耦合，每个“门面Façade”可以认为成对应了一个系统功能子系统，为系统的并行开发提供了可能。通过Façade模式，给系统的可维护性和性能等质量属性实现，奠定了很好的基础。根据前面分析知，系统采用基于.NetFramework3.0平台的Remoting技术实现分布式的。在Remoting技术中，客户端通过远程调用服务器端注册的业务功能组件的指针，完成自身的业务处理需要。这种远程调用的机制虽然占用一定的网络流量，但它对于系统代码的安全性起到一定的保护作用。同时，方便系统的升级。当前第37页\共有44页\编于星期日\14点

业务逻辑层的一种可用框架：

当前第38页\共有44页\编于星期日\14点业务逻辑层架构分析：

该业务逻辑层的架构是前面Façade模式的一种变形，他继承了Façade模式的所有优点，同时，具体到我们的架构中，它又实现了客户端不必与业务对象直接交互。客户端只需要输入业务参数（业务请求对象），然后调用业务对象执行器，通过对象执行器委派到具体的事务处理对象，就可以通过结果响应对象获取业务执行结果。该业务逻辑层架构具备良好的维护性、可靠性和可扩展性。当前第39页\共有44页\编于星期日\14点3系统架构设计3.3结构化设计模型