面UML的分析医院系统.pptVIP

作 业 角色描述 角色描述 用例细化 用例细化 细化的用例图 类的识别 类的识别 系统类图 * 用例模型(include case model) 　　 用例模型描述的是外部执行者(Actor)所理解的系统功能。 它描述了待开发系统的功能需求。 它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和 UML 的各个模型。 用例模型由若干个用例图构成，用例图中主要描述执行者和用例之间的关系。在UML中,构成用例图的主要元素是用例和执行者及其它们之间的联系。 创建用例模型的工作包括： 定义系统、确定执行者和用例、描述用例、定义用例间的关系、确认模型。 一、执行者(Actor) 　　执行者是指用户在系统中所扮演的角色。执行者在用例图中是用类似人的图形来表示, 但执行者可以是人，也可以是一个外界系统。 注意：用例总是由执行者启动的。 如何确定执行者： 1、谁使用系统的主要功能(主执行者)? 2、谁需要从系统获得对日常工作的支持和服务？ 3、需要谁维护管理系统的日常运行（副执行者）？ 4、系统需要控制哪些硬件设备？ 5、系统需要与其它哪些系统交互？ 6、谁需要使用系统产生的结果（值）？ 一、执行者 供货 买饮料 取货款 客户 供货人 收银员 图7.15自动售货系统 回例1 二、 用例 二、用例(include case) 　从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。在UML中,用例被定义成系统执行的一系列动作（功能）。 用例有以下特点: 　　用例捕获某些用户可见的需求,实现一个具体的用户目标。 　　用例由执行者激活,并将结果值反馈给执行者。 　　用例必须具有功能上的完整描述。 如何确定用例： 1、与系统实现有关的主要问题是什么？ 2、系统需要哪些输入/输出？这些输入/输出从何而来？到哪里去？ 3、执行者需要系统提供哪些功能？ 4、执行者是否需要对系统中的信息进行读、创建、修改、删除或存储？ 二、用例 回例1 图7.16 用例图的元素 用例图 　　用例图描述了系统的功能需求，它是从执行者的角度来理解系统，由“执行者”、“用例”和“用例之间的关系”3类模型元素构成。 　　图中还有另外两种类型的连接,即《包含》和《扩展》关系，是两种不同形式的泛化关系。 用例2 用例A 用例 执行者 用例1 用例3 用例B 《使用》 《使用》 《扩展》 (a) (b) (c) 《include》表示一个用例使用另一个用例。 《Extend》通过向被扩展的用例添加动作来扩展用例。 现有一医院病房监护系统，病症监视器安置在每个病房，将病人的病症信号实时传送到中央监视系统进行分析处理。在中心值班室里，值班护士使用中央监视系统对病员的情况进行监控，根据医生的要求随时打印病人的病情报告，定期更新病历，当病症出现异常时，系统会立即自动报警, 并实时打印病人的病情报告，立及更新病历。 要求根据现场情景，对医院病房监护系统进行需求分析， 建立系统的include case model。 请对系统需求进行分析！ 经过初步的需求分析，得到系统功能要求： 1、监视病员的病症（血压、体温、脉搏等） 2、定时更新病历 3、病员出现异常情况时报警。 4、随机地产生某一病员的病情报告。 例2 医院病房监护系统 产生 病情报告 监视病情 更新病历 情景教学 二、简单的需求分析说明 系统名称：医院病房监护系统 根据分析系统主要实现以下功能： 　　1、病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到中央监护系统。 　　2、中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信号的正常值进行比较，当病症出现异常时系统自动报警。 　　3、当病症信号异常时，系统自动更新病历并打印病情报告。 　　4、值班护士可以查看病情报告并进行打印。 　　5、医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病历。 　　6、系统定期自动更新病历。 退出 上页 首页 下页 末页 需求分析 三、用UML的静态建模机制定义并描述系统的静态结构 （一）建立系统的用例图 　　1、通过以下六个问题识别角色 　　(1)谁使用系统的主要功能？ 　　(2)谁需要系统的支持以完成日常工作任务？ 　　(3)谁负责维护，管理并保持系统正常运行？ 　　(4)系统需要应付（或处理）哪些硬设备？ 　　(5)系统需要和哪些外部系统交互？ 　　(6)谁（或什么）对系统运行产生的结果（值）感兴趣？ 需求分析 　　通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色：