医院挂号管理系统系统分析与设计UML

北京理工大学珠海学院综合实践报告书课程名:系统分析与设计实践实践项目:医院门诊挂号管理系统学院：专业班级：学生学号：学生姓名：指导教师：目录第一章引言 11.1目的及范畴 11.2术语 11.3文档构造 1第二章 需求阐明 32.1系统参加者 32.2系统用例 32.3补充规格阐明 42.4业务规则 52.5领域对象分析 62.6系统次序图 72.7操作契约 7第三章 架构设计阐明 83.1逻辑视图 83.2进程视图 83.3开发视图 93.4物理视图 93.5用例视图 10第四章 用例实现 124.1 挂号用例实现 124.2统计挂号收入用例实现 12第五章设计类阐明 135.1设计类字典 135.2物理包设计 14参考文献 15心得体会 16第一章引言1.1目的及范畴目的概述：建设的总体目的和系统建设的高层需求进行描述，对系统所涉及的各方及使用者进行了分析。用于指导系统的需求分析、设计和实施。此文档是项目启动阶段各有关方进行讨论的基础。医院门诊挂号管理系统（下列简称“HRMS”），针对的是顾客办理门诊卡的来医院就医的病人。本系统能够做到一下的功效：1、能够存储一定病人信息，并方便有效的进行对应的挂号操作和后台管理，这重要涉及：·卡号信息的录入及删除·卡号信息的多核心字检索查询·卡号充值及查余额·医生导航2、能够对一定数量的病人进行对应的信息存储与管理，这其中涉及： ·病人信息的登记，注销及修改 ·能显示在改病人之前的挂号人数 ·病人资料的统计与查询3、能够对需要的统计成果提供打印输出4、能够提供一定的安全机制，提供病人信息授权访问，避免随意删改，同时提供信息备份服务HRMS重要解决下列的问题： ·从根本上解决了挂号，缴费，取药时间长，就诊时间短的问题 ·在就诊过程中自动完毕收费，杜绝了全部款项的跑漏 ·对医院药品及器材实时管理，避免了不必要的流失和不必要的损耗，增强了供应计划能力 ·患者购卡方便，退卡自由，多个费用结算方式 ·HRMS的应用使医院和保险公司、银行等单位的协作配合更加方便有利范畴概述：本文档的范畴合用于普通医院的门诊挂号管理系统。1.2术语 专门术语的定义与外文首字母组词的原词组。 “HRMS”：“医院门诊挂号管理系统”。（hospitalregistermanagesystem）1.3文档构造医院门诊挂号管理系统软件文档架构设计逻辑视图进程视图开发视图物理视图医院门诊挂号管理系统软件文档架构设计逻辑视图进程视图开发视图物理视图用例视图用例实现参考文献设计阐明心得体会其它文档需求阐明系统参加者系统用例补充规格阐明业务规则领域对象分析系统次序图操作契约引言目的及范畴术语文档构造2.1系统参加者参加者描述责任挂号员帮就诊者挂号完善就诊卡资料挂号组长统计挂号数量管理挂号员财务人员统计挂号部门的收入管理财务计算医务室人员管理科室和专家的开诊状况管理出勤等人力资源病人到医院看病的人对的给出病人的信息2.2系统用例2.2.1用例名：挂号用例描述：挂号员对病人资料整顿进行挂号的操作前置条件：病人资料齐全挂号员成功登录系统触发事件：就诊者来到挂号窗口工作流程：病人到挂号台进行挂号挂号员通过病人的资料进行整顿病人提交挂号所需的资金挂号成功，挂号员把就诊卡交给病人扩展流程： 4a. 所挂的那种号已经达成人数限制；1.系统自动提示人数已达成上限； 8a. 没有可供打印的空白票据；系统自动提示请放入打印纸；系统等待挂号员单击重新打印票据按钮；系统重复上述环节8后项条件：系统自动保存挂号信息，增加那种号的已挂号数。 2.2.2 用例名：统计挂号数量 用例描述：挂号组长统计各个挂号员的挂号数量 参加者：挂号组长 前置条件：挂号组长成功登录系统 重要流程：挂号组长输入统计挂号数量的日期系统显示设立日期后的挂号信息 扩展条件：输入日期不对的系统提示输入的日期不对的系统返回统计功效页面 2.2.3 用例名：管理值班 用例描述：医务科对医院工作人员的工作时间安排 参加者：医务室人员 前置条件：医务室人员成功登录系统 重要流程：医务人员根据已知医生请假状况，出诊状况定下计划表系统自动安排对应班次的出诊 2.2.4 用例名：统计挂号收入 用例描述：财务人员通过挂号员获得资料并进行对应的财务统计 参加者：财务人员 前置条件：财务人员成功登录系统 重要流程：挂号员传输对应的资料给财务人员财务人员对对应的资料进行统计计算 2.3补充规格阐明 功效补充阐明：登录功效系统主界面提供登录对话框，输入顾客名和密码，以及就诊卡的验证，系统验证对的后进入系统否则输出错误信息查询功效：医务人员，病人，游客能够查询到其对应的信息修改功效：根据不同的顾客实施不同的修改操作查看功效：全部的顾客都有此功效，具体涉及查看公示和提示，挂号排队人数 可用性补充阐明：方便操作，操作流程合理控制必须的录入项，使顾客精确填写信息，同时对必须录入项及时提示可靠性补充阐明：容错系统含有一定的容错能力和抗干扰能力。在碰到故障的时候能够正常运行或者是保存有关的数据项数据备份和统计日志性能补充阐明：客户普通响应时间不超出1秒统计报表时间不超出30秒支持多顾客（具体医院给出调查人数）使用，并确保性能不受影响安全性补充阐明：权限控制根据不同的顾客系统管理员设立响应权限，没有权限的顾客严禁使用该系统，不同的顾客角色只能在自己的权限范畴内进行操作重要数据加密本系统对某些重要的数据进行加密解决，如顾客口令，重要参数等，并对数据库进行md5密码操作编码原则补充阐明： 该系统应为IE7.0及更高版本和netscapenavigator的原则。2.4业务规则挂号人数限制：每一种号，在一种班次中有人数限制； 开诊：有些科室晚上不开诊大部分专家每七天开诊的时间约2个白天班次 挂号：能够挂一种科室，也能够是一种专家。 挂号费：分为平日和假日。退号和换号规则：超出该号的有效班次，不予退号和换号。统计挂号收入：精确到科室、医生、月、日和班次。2.5领域对象分析统计挂号信息，依赖于就诊卡的信息，专门负责统计挂号人数和挂号收入。就诊卡信息，依赖于病历和医院值班表，专门负责统计病人的信息和该病人所看的门诊，医生的信息。病历信息，病人初到医院时给医院的信息之一，如果病人初次到医院，则从该医院给发病历，重要统计病人的信息。医院值班表，重要统计了医务室人员对医院的班次，人员管理。2.6系统次序图系统次序图描述： 首先，系统经由医务室人员，根据医生的信息定下值班表，拟定医生的班次等信息。然后，病人就诊，病人需要出示他的病历，来详述病人的信息状况，挂号员根据病人的需要，为病人选择适合的医生和门诊，精确填写就诊卡的信息。最后，挂号组长通过挂号员的资料，整顿统计出挂号的数量，并且由系统自动发送给财务人员，让财务人员统计挂号所得的收入。2.7操作契约无。

第三章 架构设计阐明3.1逻辑视图这个是逻辑视图，表明了界面业务类阐明底层数据库之间的关系。3.2进程视图进程视图阐明：医院挂号系统共分为三大模块，第一模块为挂号模块，重要负责挂号具体的操作与统计挂号量。第二个模块是医务室操作模块，具体负责医生的出勤，班次等有关的信息。第三个模块是财务部门模块，重要负责医院的收入统计。3.3开发视图开发视图重要指的就是系统的类包之间的关系，在医院挂号管理系统中，财务操作包依赖于挂号操作包与医务室操作包，而挂号操作包依赖于医务室操作包。3.4物理视图这个是构件视图，在进行系统的分析时候，特意将每个功效模块按照包的形式规划，因此和类包的形式非常相像。构件视图重要描述了系统各个功效的关系。 这个是布署视图，就是系统在医院中终究是如何使用的。在本系统中，挂号处设立一种终端，负责解决挂号有关操作，医务室布署一种终端，负责医务室的人员管理，而财务部布署一种有关的终端，用于财务的统计，每个终端都通过局域网连接到WEB服务器，而WEB服务器则将操作的信息返回到数据库之中执行。3.5用例视图 医院门诊挂号管理系统：重要功效涉及：挂号，统计挂号量，管理班次，统计收入四大功效。

第四章 用例实现4.1 挂号用例实现4.2统计挂号收入用例实现

第五章设计类阐明5.1设计类字典统计挂号信息：编号数据项名称阐明1NumberInt2MoneyInt就诊卡信息：编号数据项名称阐明1NameString2AgeInt3sexString4InfoString5IdInt病历信息：编号数据项名称阐明1namestring2ageint3sexstring4infostring医院值班信息：编号数据项名称阐明1NameString2idint3dutystring4maxint5subjectstring5.2物理包设计

参考文献[1]刘敏莺、杨丽、文学义：《RationalRose基础教程》[M]，冶金工业出版社，第20页。[2]（美）CraigLarman著，李洋，郑龚等译：《UML和模式应用》[M]，冶金工业出版社，第20页。

心得体会UML这门课程，对于我们大家来说本是一种很陌生的东西，但通过一种学期的学习，逐步对它有了一定的理解和认识。本学期在老师的带领下我们共同完毕了对UML课程的学习。现在，回想过去的学习过程，得到了下列几点体会：1、我们在求学的过程中，必定会碰到诸多新的内容和知识，对于新的知识，我们应当用一种良好的态度去看待它，主动并努力的学习新知识。2、我们也应当永葆自己的求知欲，坚持与社会同进步，不停的充实和完善自己。3、我们在学习得过程中，应当认真严谨。另外，这是第一次一种人去完毕实践课的作业，我觉得优点在于，整个进度都掌握在自己手中，工作进度比较快。缺点是由于只是个人去设计，因此某些部分设计与实际相悖，没有团体一起交流考虑得那么周全。学了UML设计使我对抽象的事物更加具体，并且懂得如何将这些设计模式的办法应用在其它方面，使生活更加有效率。这次实践课我存在的局限性：由于缺少实际开发经验，某些业务逻辑，以及开发场景的扩展点未能具体列出。由于缺少界限的概念。尚