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

《06 药品管理系统架构设计案例分析》由会员分享，可在线阅读，更多相关《06 药品管理系统架构设计案例分析（46页珍藏版）》请在金锄头文库上搜索。

1、第六章第六章药品管理系统架构设计案例分析药品管理系统架构设计案例分析1 项目背景某单位需要统一管理所采购的药品，采购的药品 总数已逾千种，传统的手工管理方式难以适应当今药 品管理种类繁多、流动量大、调配程序复杂等特点， 存在着很多不足之处。为了适应当前的业务发展需要 ，准备开发一套信息管理系统，对所采购的药品进行 有效的管理。2 需求分析需求分析的主要任务就是创建代表“目前”业务情况的业 务模型，并将此业务模型转换成“将来”的系统模型，包括功 能需求和非功能需求。非功能需求又包括质量属性和各种约定 。通过对客户的当前业务的分析，我们得到当前业务的基本需 求。2 需求分析功能需求功能说明 用户管

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

3、需求分析2.1 定义系统(1) 捕捉系统通用术语通用术语：描述系统行为过程中经常出现的名词。通过捕 捉系统通用术语可以避免在项目团队成员之间对它们的理解出 现偏差造成误解。术语说明用户信息即系统中的用户信息，包括用户名、密码、联系方式等 入库单表示采购药品的具体情况效期药品的最迟有效时间 . .角色说明库存管理员指负责记录系统中药品种类、出入库管理的用户管理员指负责系统中用户的创建、维护和权限分配的用户处长指对药品出入库单进行确认并签字的人员外部系统指希望通过一定接口与本系统进行交互的对象(2) 捕捉系统中角色和用例通过捕捉系统中的角色和用例目的是定义系统的范围，找 出并描述系统内、外部必须处

4、理的内容，以及那些与本系统需 要进行交互的人或外部系统。系统角色如下：用例说明管理用户信息每个库存管理员需要对药品的出入库进行登记管理 ，必须由管理员创建该账户，并且对其进行了一定 的权限分配，并且管理员可以对该用户信息进行维 护。同时，这些活动必须包括登陆与推出功能。 查询和统计指向用户提供按一定方式排列的药品出入库等相关 信息。而且，还要提供方便的查询，以便用户可以 迅速的查询到制定的药品。提交入库单用户根据具体情况需要从外面采购所需的药品，在 按照一定的方式填写完成相关的信息时（为维护系 统中存储信息的一致性，一些相关的信息需要从系 统已存储的信息中读取），形成入库单，提交给系 统处理。

5、根据已找出的系统角色，分析其对系统的具体要求，找出 系统的各个用例。用例说明入库单打印指用户根据一定的查询条件，选择待打印的入库批 次信息，提交给系统处理，按一定的格式，打印出 所需的实体入库单。审查订单指处长出、入库单，核定相关信息，并签字。 药品管理管理员根据所采购的药品种类，维护系统中记录的 与业务相关的药品种类信息。 授补单位管理管理员根据库存药品出库对象的相关信息，维护系 统中记录的收补单位信息。 发货单位管理管理员根据采购药品的发货单位相关信息，维护系 统记录的发货单位信息。 外部系统交互指系统根据以后的扩展需要，为系统与外部系统交 互预留一统一接口。 根据上述分析，可以得到下面业

6、务用例模型：2 需求分析2.2 细化定义(1) 细化用例细化业务用例模型，是为了更加详细地分析和描述用例。 同时，将业务用例模型转换成系统的用例模型。下面，以“角 色”库存管理员交互的用例进行细化为例。要素说明用例名称提交入库记录简要描述库存管理员根据药品采购具体情况、记录选购药品 ，形成入库单，提交给系统处理。事件流基本事件流 （1）库存管理员在待入库的药品名称栏中输入待入 库的药品名称； （2）系统根据用户输入，以列表的形式罗列当前系 统中存储的符合库存管理员要求的药品种类的详细 信息；细化用例后，还需对用例进行详细描述，直到所有涉众都 认可描述的内容已经能够正确表达出他们的需求为止。在R

7、UP 方法论中指明通过阐述一个用例的名称、简要描述、事件流、 特殊需求、前置条件和后置条件等六个方面可以对用例进行描 述。下面以用例“提交入库记录”为例细化描述。要素说明事件流（3）库存管理员根据实际情况的需求，选择待入库 的药品种类，并在各个入库单项记录的输入框中输 入此入库单项的相关信息（生产日期、有效日期、 单价、发货单位、核准数量和实际数量），库存管 理员确认信息无误后，点击“添加入库单项”按钮； （4）库存管理员重复上面的工作，直至此次入库记 录添加完毕； （5）系统罗列出库存管理员此次入库的所有入库单 项的详细信息，库存管理员确认无误后，点击“添加 入库记录”，系统根据数据库中现有

8、的入库批次号自 动生成新的入库批次，并将它们关联起来。 （6）该“提交入库记录”用例结束。“提交入库记录”为例细化描述（续）要素说明备选事件流库存管理员在输入待入库的药品种类名称时，系统 不能查询到相关信息时，则按一下步骤进行： （1）在系统未查询到库存管理员所需的相关药品种 类信息时，提示库存管理员是否需要添加新的药品 种类信息； （2）其次，撤销此次入库记录的提交。 特殊需求系统要保证入库信息的一致性和完整性，不允许伪 造数据。界面操作要合理，要考虑到库存管理员操 作顺序等问题。“提交入库记录”为例细化描述（续）要素说明前置条件待入库药品种类信息必须存在，不存在的药品种类 不能入库。 后置

9、条件当入库成功，相应药品的库存信息要及时更新为最 新状态。“提交入库记录”为例细化描述（续）上面对用例的描述仅限于文字描述，还不够形象。再以活 动图的形式进行建模描述如下：(2) 结构化用例结构化用例的目的是通过观察这些已经细化的用例，看能 不能抽取出共有的、可选的行为，把这些共同的内容建立为新 的用例。这样的好处是，可以消除冗余的需要以及改善系统整 体需求内容的可维护性。像“提交入库记录”用例中，“添加新的 药品种类”应作为一个新的用例提取出来，以提高上面所说的需 求内容的可维护性3 系统架构设计架构设计是将需求内容转换成设计模型的雏形以及用户体 验模型，其目的是建立整个系统初步的解决方案，

10、为详细设计 活动打下基础，这一阶段的具体活动如下：3 系统架构设计3.1 体系结构的选择决定采取分布式的还是集中式的体系结构，将是一个影响 系统性能、可缩放性、可靠性、易用性及此应用所能支持的客 户端类型的重要决策问题。根据前期的需求知道，系统是为某单位设计的，考虑到后 期的系统推广应用的可能性，采取分布式的体系结构将更适应 于今后的变化。根据前期对需求的分析，决定采取基于.Net Framework 3.0 框架来构建此分布式的信息管理系统 。.Net Framework 3.0框 架如下：基于三层结构的框架如图所示：框架讲解：UI（界面层）：职责是数据的展现和采集，数据采集的结果 通常以实

11、体对象提交给业务逻辑层处理。BL（业务逻辑层）：职责是按预定的业务逻辑处理UI层提 交的请求。 （1） 业务功能子层负责基本业务功能的实现。 （2） 业务流子层负责将业务功能子层提供的多个基本业务功 能组织成一个完整的业务流（事务只能在业务流子层开启）。RA（资源存取层）：职责是提供全面的资源访问功能支持 ，并向上层屏蔽资源的来源。(1) BEM（业务实体管理子层）：采用数据存取子层和服务 获取子层来提供业务需要的基础数据/资源访问能力。(2) DA（数据存取子层）：负责从数据库中存取资源，并向 BEM子层屏蔽所有的SQL语句以及数据库类型差异。 (3) SA（服务获取子层）：用于以SOA的方

12、式从外部系统获 取资源。(4) CA（配置文件存取子层）：用于从配置文件中获取配置 信息或将配置信息保存倒配置文件。Entity（实体层）：跨越其他三层，在这些层之间传递数据 。规则（约束）：（1）系统各层次及层内部子层次之间都不得跨层调用。（2） Entity对象在各个层之间传递数据。（3）需要在UI层绑定到列表的数据采用基于关系的数据集传 递，除此之外，应该使用Entity对象传递数据。 （4）对于每一个数据库表（Table）都有一个DB Entity class与 之对应，针对每一个Entity class都会有一个BEM Class与之对应 。（5）有些跨数据库或跨表的操作（如复杂的联

13、合查询）也需 要由相应的BEM Class来提供支持。 （6）对于相对简单的系统，可以考虑将业务功能子层和业务 流子层合并为一个。（7） UI层和BL层禁止出现任何SQL语句。. Net Remoting框架图：. Net Remoting框架介绍：. Net Remoting提供了一种允许 对象通过应用程序域与另一 个对象进行交互的框架。首先，客户端通过Remoting，访问通 道以获得服务端对象，再通过代理解析为客户端对象。这就提 供一种可能性，即以服务的方式来发布服务器对象。远程对象 代码可以运行在服务器上（如服务器激活的对象和客户端激活 的对象），然后客户端再通过Remoting连接服

14、务器，获得该服 务对象并通过序列化在客户端运行。这种框架提供了许多种服 务，包括激活和生存期支持，以及负责与远程应用程序进行信 息交互的通讯通道。框架选择：由于该系统仅在局域网内使用，用户数量有限，因此，决定 采取局域网内的分布式的桌面信息管理系统方式实现此系统。 根据前面的分析，我们采用. Net Framework 3.0框架实现该系统 的，采用. Net Remoting实现客户端与服务器端之间的通信。3 系统架构设计3.2 系统架构的分析与设计架构的设计对系统质量属性的实现起着决定性的作用，而 架构的形成又是由这些质量属性驱动的。由于系统为简单的MIS 系统，因此，下面着重对数据存取层

15、和业务逻辑层架构的设计进 行比较详细的介绍。(1) 数据持久层的架构分析与设计可维护性场景：性能场景：安全性场景：可维护性：架构的设计不仅仅是面向客户的，同样需要面向 开发人员的。在数据存取层中添加数据源访问组件，通过在数据 访问层中添加一个数据库配置组件，可以使系统的数据源快速的 从一种类型转换到另一种类型。满足实际业务扩展需要。性能：由于系统采用分布式的结构，虽然用户数量有限，但 如果用户频繁的向服务器端发送请求，势必导致系统性能下降。 因此，在数据存取层中添加SQL访问组件，实现对数据库更新操 作的批量处理，减少访问数据库的频度，对系统性能的提升有一 定得帮助。安全性：数据的并发访问是分

16、布式系统的中的潜在威胁。同 一时间，不同客户端对同一数据记录进行操作必然存在并发一致 性问题，如：丢失修改、不可重复读和读脏数据等。本架构通过 数据库事务处理组件对这一问题进行控制。数据库事务处理组件 通过对事务进行隔离级别划分的机制，维持了数据库的ACID（ 原子性、一致性、独立性和持久性）要求，提高了系统的安全性 。满足以上质量场景的数据存取层架构：数据存取架构分析：该架构主要包括：数据源组件、SQL访问组件、SQL参数和 结果集处理组件四大模块。其中，数据源组件主要负责数据库 连接的管理；SQL访问组件负责数据库服务器的交互；结果处理 组件模块负责处理从存储过程或查询操作类返回的结果数据； 在整个架构中，凡是涉及到SQL语句参数的处理都交给类“SQL 参数”。基于这种架构的数据存取过程，满足上述的预期目标。(2) 业务逻辑层架构设计：业务逻辑层作为MIS系统的关键部分，对系统的灵活性实现 起着决定性的作用。在本系统的业务逻辑层架构层中，采取了 Faade模式，下面简单介绍一下Faade模式的好处：(1) 网络开销小，客户只需要和一个“门面Faa