管理信息系统(6-2).ppt

第六章 系 统 设 计 实例2——病人监护系统 实例2——病人监护系统 本实例说明改进模块结构图的过程，在改进过程中运用了一些SC优化技巧。 问题描述 初始SC SC的改进 进一步优化 总结 1 问题描述 本系统MNPA是某医院的一个病人监护系统,其功能如下： 所有的病人都由专门的设备进行监视，设备同病床相连，这些设备可以测量病人的脉搏、体温、血压、呼吸……等项目（下面称这些项目为因素）。系统每过一定的时间间隔从监视设备读入上述因素， 并把它们存入数据库中。医生为每个病人指定了各种因素的安全范围（如312号病人的体温安全范围是36。C~38.5。C)，如果系统发现某个因素值越出安全范围， 或发现某个监视部件有故障， 则向护理站发出通知：如果是因素越限则报告病人号；如果是监视部件故障则报告床位号。 1 问题描述(续) 监视部件故障： 两种可能的设备故障 监视设备读出的数据由七个因素值及一个硬件故障标志字组成。 1)硬件故障标志字：七个二进制位，说明测量这七个因素的硬件是否有效（如：某个硬件单元是否已接入电路中） 如： 1110101 表示第4、6个硬件故障，其测出的因素值无效 1-有效 0-无效 1 问题描述(续) 监视部件故障(续)： 2)设备软件故障：即监视设备测出的因素值不合理（如：体温测出52。C的不合理值等）。 故障处理 在硬件故障标志字指出硬件无效或软件检查出因素值不合理时，都应作为监视设备故障向护理站报告 将这些因素值存入数据库时应加上标志，指出它们是无效的 1 问题描述(续) 数据存储： 数据库中的数据应该可以按病人号进行检索。各因素是相互无关的，其格式和长度均不相同。在数据库中，不必标出个因素值是否安全。 注：因素值无效与因素值安全是两个概念。 比如体温为 39。C是有效的，却是不安全的。 2 初始结构图(续) 这个初始模块结构图是一位经验不足的设计员，根据经验和直观想象直接得出的。所以可改进的余地还很大。 2 初始结构图(续) 模块“检查因素值”调用三个下层模块分别完成三个功能： 1）查出不合理的因素值（‘检查因素值’模块中再将Error Flags2和硬件故障标志字合并成设备故障标志Error Flags) 2)查出某病人的因素安全值范围 3)决定病人的因素值是否安全 模块“处理因素值”将数据存入数据库，并在发现不安全因素或设备故障时通知护理站 3 结构图的改进 使用技巧： 减少块间联系，主要是减少模块之间传送的参数个数 消除“管道性”模块 消除重复的功能 如果一个模块篇幅较大，可考虑分解 如果一个模块篇幅较小，可考虑同其调用模块合并 要考虑将来可能发生的变化和扩充 3 结构图的改进(续) 3 结构图的改进(续) 改进一： 减少块间联系，主要是减少模块之间传送的参数个数，简化模块之间的界面 分析： “病人监护系统”——“处理因素值”的界面 1) “处理因素值”接收的参数unsafe flags，除了“报告不安全因素”要用到，其另两个下层模块不必用到这一参数；且“报告不安全因素”不返回任何参数给“处理因素值” ；“报告不安全因素”所需的参数在主模块“病人监护系统”中都有；所以将它改成由主模块直接调用。这样又可简化unsafe flags这一参数。 3 结构图的改进(续) 分析： “病人监护系统”——“处理因素值”的界面 2) 同理，主模块可以直接调用“存入数据库”，这样，主模块“病人监护系统”与“处理因素值”的界面又可以消去Factors这一参数。 3 结构图的改进(续) 分析： “病人监护系统”——“处理因素值”的界面 3) 现在， “处理因素值”的功能仅仅是调用“报告错误设备”，所以它可以合并到主模块中去。 3 结构图的改进(续) 分析： “病人监护系统”——“处理因素值”的界面 说明—— “处理因素值”模块并没有做什么实质性的工作，而只是像“管道”一样，将一些参数从主模块传送到它的几个下层模块， 而这些模块完全可以由主模块直接调用。 3 结构图的改进(续) 改进二： 消除重复的功能 分析： “报告错误设备”模块 1) “报告错误设备”模块应该向护理站报告故障设备的床位号而不是病人号，所以应该在这个模块中包含从病人号查出床位号的功能。而模块“读取病人信息”已经含有这个功能。所以可把它提供的BedNum参数回送给主模块，再由主模块传送给“报告错误设备”模块，但这样增加了块间联系。 如果改为由“读取病床因素值”直接调用“报告错误设备”，则可将传送给主模块的参数BedNum消去，可减少块间联系。 3 结构图的改进(