系统架构设计师论文---架构风格

-- 摘要

       2019年8月，我司承接了某市医疗集团，智慧药房项目，该项目主要为集团下属36家社区卫生服务中心提供药品统一目录管理、药品集中采购、库存管理、处方合理用药审核、药品配发、自动化发药设备驱动提供软件支撑。在该项目中我担任了软件架构设计师一职，主要负责该项目的软件架构设计工作。本文以智慧药房项目为例，主要论述了架构风格在项目中的具体应用，在处方审核模块中，采用了基于规则的系统风格，将18万种药品合理用药规则作为基础规则库供处方审核调用，在自动化发药设备协同中，采用了隐式调用风格，将处方配发任务和设备驱动进行解耦，在药品采购和配发模块中，采用了B/S+C/S的混合架构风格，通过使用这些架构风格，提高了软件设计质量和开发效率，最终项目成功上线，并获得了用户一致好评。
 
-- 背景
       根据深化医药卫生体制改革规范药求，推进药品集中采购，增加药品的供应保障能力，严格监督管理，保障药品的用药安全，所有医疗机构开出的处方，必须通过处方审核后，方可进入划价计费环节，未经审核的处方，不得进行计费和配发。2019年8月，我司承接了某医疗集团智慧药房项目，该项目为医疗集团下属36家社区卫生服务中心提供软件支持，主要分为药品供应模块、药房管理模块、处方用药审核模块、药品配发模块、设备协同模块。药品供应模块负责药品库存预警，供社区卫生服务中心药房对药品进行集中采购，并将药品发送到省采招平台；药房管理模块主要进行一些基础信息的维护，及关注药品的库存管理，药品批号跟踪；处方用药审核模块，负责对医生开出的药品进行合理用药审核，将不合理的处方审核结果返回给医生，提醒医生修改处方；药口中配发模块，负责将处方中的药品进行调配，打印用法用量标签，确认发药后扣减相应的库存；设备协同模块主要是驱动药房中的一些自动化发药设备，将要药品信息发给设备上位机，根据设备药品的效期进行排序，通过上位机程序调用下位机，驱动设备出药。在该项目中我担任软件架构设计师职务，主要负责软件的架构设计及中间件等技术的选型工作。
 --问题回答，根据提干来
       软件架构风格描述了某一特定领域中的系统组织方式和惯用模式，反映了领域中众多系统所共有的结构和语义，并指导如何将各个构件有效地组织成一个完整的系统，提高了架构的复用性，架构风格定义了用于描述系统的述语表和一组指导构建系统的规则，一般分为数据流风格：批处理、管道-过滤器；调用/返回风格：主程序/子程序、面向对象、层次结构；独立构件风格：进程通信、事件驱动（隐式调用）；虚拟机风格：解释器、基于规则的系统；仓库风格：数据库系统、超文本系统、黑板系统。可以为从多项目提供通用的解决方案，能够极大的提高软件设计的重用方法和加快开发的进程。
--简介
       在智慧药房项目中，我使用了虚拟机风格、独立构件风格以及B/S+C/S混合架构模式；虚拟机风格中的规则系统，能够在你预先定义好的规则下，执行符合规则的一些行为，独立构件风格包括进程通信和隐式调用，减少系统的耦合度，提供了系统的可扩展性。B/S架构风格是基于浏览器和服务器的软件架构，他主要通过HTTP协议进行通信和交互，降低了维护升级的成本，C/S架构风格使得客户端程序能够处理更多的业务逻辑，更容易驱动硬件设备。以下正文将重点描述架构风格的应用实施过程和效果。
--以三个维度阐述 
     处方模块模块中，采用了虚拟机风格中的基于规则的系统风格，目前现有药品目录有18万种，一个患者在不同的时间或不同的科室就诊，每次就诊会开出相应的处方药品，判断这些药品之间是否存在相互作用，给药方式是否正确，是一项巨大的工程，所以在处方审核模块中，我使用了虚拟机风格中的基本规则的风格，《中国药典》、《临床药物治疗合理用药原则》、《配伍禁忌》中对现有18万种药品间的合理用药有明确使用规则说明，将这些药品的相互作用做为基础规则库，再加上药品说明书中明确指出的用药规则及药师制定的一些自定义规则，规则数据量较大，因此我们选择了适合处理大数据的非关系型数据库MongoDB，在医生开出处方后，将处方中的药品本位码和规则库中的规则进行配对，如果发现有存在相互作用、用法用量有误等不合理处方时，及时将审核结果，不合理用药的原因，发送到医生工作站，让医生修改处方，处方审核模拟中使用了基于规则的架构风格，大大提高了药师人工审核的工作效率，保障了患者的用药安全。
       在发药设备协同环节，我采用了隐式调用风格，来简化构件间的交互，隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件，项目中有多种不同的发药设备，如果在发药管理中直接驱动设备出药，增加了应用系统和设备之间的耦合度，降低了扩展性，新增一台发药设备时，不能快速对其进行扩展兼容，因此，项目中采用了开源的MQ消息中间件做边连接构件，这个是Apache 基金下的核心开源项目 Kafka，配发系统在处方药品调配时，作为生产者，将处方中的药品信息发送给 Kafka，发药设备作为消息的消费者，从Kafka中获取发药数据。这种方式相对于同步调用的好处就是，消息发送者将消息发给Kafka后，就可以去处理其它任务了，无需等任务处理结果，发药设备如果在维护情况下，重启了设备，不会因为没收到数据，造成出药失败，只需要在启动后，重新到Kafka中再次消费数据即可，在上文中提到的，处方审核时，碰到不合理的处方通知医生，也同样采用了隐式调用风格。
       在药师配发药和发药设备出药环境，我采用了B/S+C/S的混合架构风格，B/S的优点：维护方便，系统功能改造后，只需要服务器端程序更新，即可实现所有的用户同步更新，简化操作，客户端只需要安装浏览器，无需单独安装系统。输入系统服务地址就可以打开系统进行操作。缺点：可操控性不强，客户端不能处理太多的业务逻辑，大都逻辑是由服务端处理完成。所有用户使用的是同一套WEB程序，很难实现个性化的需求定制。相比较而言C/S的个性化定制和操控性要优于B/S，因此，我们在设备上位机上，选择了winform+应用服务器的C/S架构。不同的设备所具备的功能不同的，界面设置、功能也大不相同，C/S很好的满足了个性化定制的需求，而且上位面程序在订阅到Kafka消息时，会调用下位机PLC程序，驱动设备出药，这是Web程序无法实现的。在药房发药窗口电脑上的配发系统，采用了B/S架构，院内业务需求经常发生变化，采用B/S架构能够方便业务功能扩展和及时更新，降低了运维成本。
 
 -- 结尾
　　项目从2019年8月启动到2020年10月历时14个月，圆满完成，顺利完成验收，并取得了客户的一致好评，该项目运行一年多，也出现过一些小的问题，由于医院使用的是集团内部局域网，与外网隔离，给排查问题及维护增加了困难，一次发药设备上的上位机不心小被药房老师删除后，不会重新安装操作，上报我司后，我们联系医院信息科老师，在信息科的老师协助下，对软件重新进行了安装，此次事件，导致了设备停止工作了几个小时，影响了药房发药效率。后来我司安排了1名售后维护该项目，这一年内也新增了一些发药设备，由于选用了合适的架构风格，使得设备的接入及服务的扩展变得非常容易，在售后同事的协助下，系统至今运行稳定。该项目的成功，让我意识到了使用了架构风格的作用和价值，坚定了我对架构风格应用的信心，合理选择合适的架构风格，能够大大的提高了软件设计的复用方法，加快开发的进程，在项目中起到事半功倍的作用。经过这次项目，我也看到了自己身上的不足之处，在未来还会不断地更新知识，完善本系统的设计，使系统能够适应国家医改的变化需要，这是作为软件从业的我为之努力的动力和方向。
 

posted @ 2021-12-21 13:38  VipSoft  阅读(3602)  评论(0)  编辑  收藏  举报