1、2018/11/20,软件工程方法,1,需求分析与用例建模,软件工程方法,2,2018/11/20,用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。 用例驱动是统一过程的重要概念，或者说整个软件生产过程就是用例驱动的。分析、设计、实现、测试都是用例驱动的，都是以实现用例为目标。 在这些开发过程中，开发人员首先捕获客户的需求，并以用例的形式组织成用例模型。然后分析并设计系统来满足这些用例，因此在用例模型之后就是分析模型，接着是设计模型和实施模型。在实现了整个系统之后，还将根据用例模型设计出测试模型来对系
2、统进行验证。 这些模型之间并不是线性转变的，它们是一个迭代、增量的开发过程。也就是在整个项目开发周期中，将会多次经过这五个模型的迭代，每次都将越来越精化。,1 客户需求分析与用例建模,软件工程方法,3,2018/11/20,1.1 建造需求模型用例建模,用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典型用例的分析，使开发者能够有效地了解用户的需求。对于正在构造的新系统用例描述系统应该作什么?对于已构造完毕的系统用例则反映了系统能够完成什么样的功能? 用例建模的主要目标是： 将需求规约变为可视化模型，并得到用户确认； 给出清晰、一致的关于系统做什么的描述，确定系统的功能
3、要求； 提供从功能需求到系统分析、设计、实现各阶段的度量标准； 为最终系统测试提供基准，据此验证系统是否达到功能要求； 为项目目标进度管理和风险管理提供依据。,软件工程方法,4,2018/11/20,用例图中包含系统、角色和用例等三种模型元素，以及它们之间的关系。,贸易经理,风险分析,进行交易,交易估价,更新帐目,使用,使用,扩展,营销人员,超越边界,评价,销售人员,记账系统,设置边界,软件工程方法,5,2018/11/20,用例模型描述的是外部执行者(Actor)所理解的系统功能。它描述了待开发系统的功能需求。它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而
4、且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和 UML 的各个模型。用例模型由若干个用例图构成，用例图中主要描述执行者和用例之间的关系。在UML中,构成用例图的主要元素是用例和执行者及其它们之间的联系。,软件工程方法,6,2018/11/20,确定系统的范围和边界； 确定系统的执行者和用例； 对用例进行描述； 定义用例之间的关系； 审核用例模型。,用例建模的步骤：,软件工程方法,7,2018/11/20,1.2 用例图,图中的元素包括：参与者、用例、一个方框和一些表示关系的连接线 。 所有的用例都位于方框之内，该方框称为“系统边界” 参与者与用例的关系：在参与者和用例之间的关联
5、是用一根带箭头的线来表示的 用例之间的关系： 1）包含关系 2）扩展关系 3）泛化关系角色与用例的关联表示角色与用例相关性。在UML中是使用一条实线连接角色与用例,软件工程方法,8,2018/11/20,1.3 定义系统的边界和范围,系统：特指基于计算机的用于解决某个特定问题域的软硬件系统。它代表的是一个活动范围。 定义系统：要定义系统的范围和边界 1定义系统的范围 :系统问题域的目标、任务、规模即系统提供的功能和任务。 2定义系统的边界:一个系统的所有元素与系统以外的事物的分界线。,软件工程方法,9,2018/11/20,1.4 确定执行者（参与者，角色）,执行者（actor）是指在系统外部
6、与系统交互的人或其他系统，它以某种方式参与了系统内用例的执行。角色在UML中通常以一个稻草人图符来表示。 执行者类型：参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟 ： 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者 角色与系统交互：角色向系统发送消息、从系统接受消息、或是与系统交换信息。 角色与用例：角色往往是发现新用例的基础，同时也是分析员和用户交流的起点。一个执行者可用启动多个用例
7、，而一个用例也可以被多个执行者启动。,软件工程方法,10,2018/11/20,1.寻找和确定执行者,通过向用户提问来识别角色： 谁使用系统提供的主要功能？（主要角色） 谁来维护、管理系统？（次要角色） 谁需要借助于系统完成日常工作任务？ 系统需要控制的硬件设备有哪些？ 系统需要与其他哪些系统交互？ 系统从哪儿得到信息？ 对系统产生的结果感兴趣的人或事是哪些？ ！不能把目光只专著于人身上。,软件工程方法,11,2018/11/20,ATM系统的Actor,1、谁使用ATM系统的主要功能（提款）？,答：储户,2、谁使用ATM系统的支持以完成日常工作任务？,答：出纳员？还不肯定，先放在这里,3、谁
8、来维护、管理并保持系统正常运行？,答： ATM系统工程师，银行人员,软件工程方法,12,2018/11/20,5、ATM系统需要处理哪些设备？,答：信用卡,6、谁对ATM系统运行的结果感兴趣？,答：银行会计、储户,4、该系统需要和哪些系统交互？,答：目前还不清楚,软件工程方法,13,2018/11/20,软件工程方法,14,2018/11/20,2.定义执行者时应该注意的问题,1）执行者之间可以有继承关系,软件工程方法,15,2018/11/20,（2）执行者代表一种角色而不是具体某个人 （3）对同一个人担任角色的限制 （4）执行者可分成主执行者和副执行者 （5）执行者还可细分为主动执行者和被
9、动执行者,主动角色：Use Case的动作序列是由他先发起的，通常系统返回最后结果 主叫方，采购人员，票据录入员等 被动角色：系统通过调用角色来完成Use Case的动作序列（或其中的某一个动作） 不是初始动作的发起者 当系统需要它们帮助的时候 最终是为了满足主动角色的需要 通常是机器或其他系统,软件工程方法,16,2018/11/20,1.5 确定用例,用例，就是一件事情，要完成这件事情，需要做一系列的活动；而做一件事情可以有很多不同的方法和步骤，也可能会遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的，在UML中我们称之为场景。一个场景就是一个用例的实例。 从本质上讲,一个
10、用例是用户与计算机之间的一次典型交互作用。在UML中,用例被定义成系统执行的一系列动作（功能）。,软件工程方法,17,2018/11/20,1.用例的特征,响应性。一个用例不自动执行，总是有执行者启动。 这件事必须由一个执行者发起，执行者的愿望是用例存在的原因。不存在没有执行者的用例，也不应该主动启动另一个用例。,软件工程方法,18,2018/11/20,回执性。 用例执行完毕，向执行者提供可识别的返回值。用例的执行结果对参与者来说是可观测的和有意义的。如，系统会监控参与者在系统里的操作，并在参与者删除数据之前备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不应该作为用例出现。因为这是一
11、个后台进程，对参与者来说是不可观测的，它应该在系统用例分析阶段定义。又比如，登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？,软件工程方法,19,2018/11/20,完整性。 用例表示一个完整的功能，必须是一完整的描述。 必须以向执行者提供返回值作为该用例完整性的标志。,软件工程方法,20,2018/11/20,用例的特征-动宾短语 用例必然是以动宾短语形式出现的。即，这件事必须有一个动作和动作的受体。 例如，喝水是一个有效的用例，而“喝”和“水”却不是。虽然生活常识告诉我们，在
12、没有水的情况下人是不会做出喝这个动作的，水也必然是喝进去的，而不是滑进去的. 但是我们所见的很多用例中类似“计算”，“统计”，“报表”，“输出”，“录入”之类的并不在少数。,软件工程方法,21,2018/11/20,2寻找和确定用例,业务用例：开始阶段，在确定用户需求过程中，系统分析员通过与客户交流建立业务模型来发现和确定的用例。 系统用例：系统构造阶段，系统分析和设计人员在进行系统分析和设计时，根据系统的需求建立的用例。 在系统开发的开端阶段，应把注意力集中在业务用例上，在精化阶段和构建阶段再考虑系统用例。,软件工程方法,22,2018/11/20,建立用例模型时，可询问？,用户(执行者)需
13、要系统提供哪些业务功能,即系统能做什么? 用户最关心系统中哪些事件?从功能观点看,这些事件表示什么? 用户要了解系统在工作中发生了哪些事件及其结果? 用户自己需要做什么? 用户是否要在系统中创建、删除、读、修改或存储某类业务数据？ 系统为了维持正常运转需要增加的功能和信息的交互； 这些信息从何而来，到哪里去？ 实现当前系统（可能是人工系统而不是自动化系统）的关键问题是什么？,软件工程方法,23,2018/11/20,通过与用户反复交流，确定主要业务用例和次要业务用例。 对于建立的每一个业务用例，都需要一组系统用例来辅助和支持。（不严谨） 系统用例是执行者与系统的交互，它描述了系统的功能需求和动
14、态行为。 系统用例用于建立系统用例模型，可通过分析系统的业务流和控制流来寻找和确定系统用例。（活动图）,软件工程方法,24,2018/11/20,如何获得用例访谈,您对系统有什么期望？ 您打算在这个系统里面做些什么事情？ 您做这件事的目的是什么？ 您做完这件事情希望有一个什么样的结果？一个明确的有效地目标才是一个用例的来源。 一个真实的目标应当完备地表达执行者的期望。 一个有效地目标应当在系统边界内，由主角发动，并具有明确的后果。应当先建立业务用例模型，然后再从业务用例模型向系统用例模型映射。 注意用例图的层次，从系统到子系统逐层建立用例图。,软件工程方法,25,2018/11/20,目标和步
15、骤的误区,软件工程方法,26,2018/11/20,怎样确定用例的粒度？,用例的粒度（用例的大小）可大可小，一般一个系统宜控制在20个用例左右。 用例是系统级的、抽象的描述，不是细化的（是做什么，非怎样做） 对复杂的系统可以划分为若干子系统处理。 用例粒度的划分最标准的方法应该是：以该用例是否完成了参与者的某个完整目的为依据的。,软件工程方法,27,2018/11/20,ATM取钱的场景中，取钱，读卡，验证账号，打印回执单等都是可能的用例？ 客户代表说：我希望这台ATM能支持跨行业务，我插入卡片输入密码后，可以让我选择是取钱还是存钱；为了方便，可以设置一些默认的存取金额按钮；我可以修改密码，也
16、可以挂失；还有我希望可以交纳水费、电费和电话等费用；为了安全起见，ATM上应当有警示小心骗子的提示条，还有摄像头；如果输入三次密码错误，卡片应当被自动吞没。,软件工程方法,28,2018/11/20,判断题,支持跨行业务 插入卡片 输入密码 选择服务 取钱 存钱 挂失卡片 交纳费用 警示骗子 三次错误吞没卡片,软件工程方法,29,2018/11/20,支持跨行业务 错，这是一个业务规则，限定业务的范围 插入卡片 错，这是一个过程步骤，不是完整目标 输入密码 错，这是一个过程步骤，不是完整目标 选择服务 错，这是一个过程步骤，不是完整目标 取钱 对，这是一个完整有效的目标 存钱 对，这是一个完整
17、有效的目标 挂失卡片 对，这是一个完整有效的目标 交纳费用 对，这是一个完整有效的目标 警示骗子 错，已超出了边界范围 三次错误吞没卡片 错，这是一个业务规则，限定业务的范围,软件工程方法,30,2018/11/20,3.描述用例,用例名： 简单名： 路径名：,软件工程方法,31,2018/11/20,用例文字描述,更详细地描述用例的功能,用例编号用例名用例描述参与者前置条件后置条件基本路径1, .X X X X2. .X X X X扩展点2a. .X X X X2a1. .X X X X变异点补充说明,软件工程方法,32,2018/11/20,用例编号:001用例名:ATM取款用例描述:储户
18、使用信用卡，在ATM机上取款参与者：储户前置条件：ATM机器处于正常准备状态后置条件：若成功，则储户取出钱，帐户上扣除钱；若失败，储户没有取到钱，帐户上钱数不变。基本路径1. 储户插卡；2. ATM机提示输入用户口令；3.储户输入口令；4.ATM机口令验证通过，提示输入钱数；5.储户输入钱数；6.ATM机进行钱数有效性检查，提示操作成功，吐出卡和钱；,ATM取款用例描述,软件工程方法,33,2018/11/20,7.储户取走卡和钱；8.ATM机屏幕恢复为初始状态。扩展点4a. ATM机验证用户口令不通过4a1. ATM机给出提示信息，并吐出信用卡；4a2. 储户取出卡；4a3. ATM机屏幕恢
19、复为初始状态.6a. ATM验证用户输入钱数超过30006a1. ATM机给出提示信息，并吐出信用卡；6a2. 储户取出卡；6a3. ATM机屏幕恢复为初始状态.。变异点无补充说明,软件工程方法,34,2018/11/20,用例名称：学生选课 执行者：学生 目的：完成一次学生选课的完整过程。 类型：主要的、基本的 级别：一级 过程描述： （1）学生输入标识码（ID），系统识别标识码的有效性； （2）对学生进行注册识别； （3）流览本学期预开课程； （4）选择学生自己要上的课程并确认； （5）退出系统，系统给出所选课程列表及相应学分合计。 异常事件流处理： （1）标识码有效性检查失败，允许学生重
20、新输入（3次机会）。 （2）注册识别失败，没有注册（尙未交学费）的学生不能选课。 （3）选择课程确认失败，所选几门课程中在上课时间上发生冲 突时，系统提示重选。,软件工程方法,35,2018/11/20,1.6 用例之间的关联,1.继承关联 2.扩展关联 3.包含关联 4.使用关联,软件工程方法,36,2018/11/20,1.继承关联,继承关联-泛化(generalization):当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。,软件工程方法,37,2018/11/20,泛化举例（一）：,软件工程方法,38,2018/11/
21、20,泛化举例（二）：,软件工程方法,39,2018/11/20,可以用来表示参与者与参与者之间，用例与用例之间的特殊/一般化关系,软件工程方法,40,2018/11/20,2.扩展(extend),箭头指向的用例为被扩展的用例，称为扩展用例；箭头出发的用例为基本用例。 扩展用例是可选的，如果缺少扩展用例，不会影响到基用例的完整性；扩展用例在一定条件下才会执行，并且其执行会改变基用例的行为。扩展用例依赖于基本用例，只是部分片断组成，不是完整的独立用例，无法单独执行；,软件工程方法,41,2018/11/20,将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。 基础用例不必知道扩
22、展用例的任何细节，它仅为其提供扩展点。 扩展用例的行为是否被执行要取决于主事件流中的判定点。,软件工程方法,42,2018/11/20,扩展举例（一）：,软件工程方法,43,2018/11/20,3.包含(include),包含是指基本用例(base use case)会用到包含用例(inclusion)，具体地讲，就是将包含用例的事件流插入到基础用例的事件流中。包含用例是可重用的用例多个用例的公共用例。 箭头指向的用例为被包含的用例，称为包含用例；箭头出发的用例为基本用例。 包含用例是必选的，如果缺少包含用例，基础用例就不完整；包含用例必须被执行，不需要满足某种条件；其执行并不会改变基用例的
23、行为。,软件工程方法,44,2018/11/20,例子：,软件工程方法,45,2018/11/20,包含用例与扩展用例的区别,相对于基础用例，扩展用例是可选的，而包含用例则不是。 如果缺少扩展用例，基础用例还是完整的，而缺少包含用例，则基础用例就不完整了。 扩展用例的执行需要满足某种条件，而包含用例不需要。 扩展用例的执行会改变基础用例的行为，而包含用例不会。,软件工程方法,46,2018/11/20,软件工程方法,47,2018/11/20,被包含的用例（此例中的检查座位详情）不是孤立存在的，它仅作为某些包含它的更大的基用例（此例中的预订座位、安排座位）的一部分出现. 基用例是可以独立于扩展
24、用例存在的，只是在特定的条件下，它的行为可以被另一个用例的行为所扩展 .,软件工程方法,48,2018/11/20,使用关联,使用关联也是一种继承关系. 在使用关联中,一个用例使用另一个用例的功能和行为.,软件工程方法,49,2018/11/20,考虑用例的关联类型,软件工程方法,50,2018/11/20,自动售货机系统,软件工程方法,51,2018/11/20,1.7 用例图实例,软件工程方法,52,2018/11/20,软件工程方法,53,2018/11/20,2 需求分析中的用例建模步骤,创建用例图模型有4项任务：找出系统中的角色和用例。区分用例的优先次序。细化每个用例。建立用例图模型
25、结构。,软件工程方法,54,2018/11/20,(1) 识别角色,例： 对一个成绩管理系统进行需求分析，可识别出如下角色及其需求。 学生（student）：浏览系统记录的成绩。 授课教师(teacher)：使用系统为学生记录成绩、更新成绩、浏览成绩，并可通过计算机发布报告卡。 管理人员（administrator）：负责创建报告卡，并浏览检查报告卡。,软件工程方法,55,2018/11/20,基于这些角色及其需求，通过回答前面的问题，可以建立如下用例： 记录成绩（Record grades） 更新成绩（update grades） 生成报告卡（generate report cards） 检
26、查报告卡（check report cards) 分发报告卡（distribute report cards ） 浏览成绩（view grades),软件工程方法,56,2018/11/20,Record grades,Update grades,Generate report cards,Check report cards,Distribute report cards,View grades,软件工程方法,57,2018/11/20,(2) 区分用例优先次序,这项任务通常是由系统分析人员完成，他们对哪一项任务最关键，哪一项任务最艰巨有最好的全局认识。他们还可以确定出哪个用例可以为其他用例
27、所重用。在上例中，可以轻松地提出以下优先次序列表： 记录成绩 测览成绩 更新成绩 生成报告卡 检查报告卡 分发报告卡某些用例必须在其他用例之前完成，因为它们之间要相互依赖。例如，在系统更新成绩之前，必须记录成绩。因此很明 显，Record Grades是最重要的用例。,软件工程方法,58,2018/11/20,(3) 细化用例的描述,在用例图中的用例通常只是简单地给出了系统应提供什么服务，并没有展示出如何提供服务，如服务的具体功能、处理流程、场景、出错情况以及异常情况等信息。这就需要对用例进行更详尽的描述。用例的描述常采用文字列表形式，也可采用UML图形描述，如交互图、活动图等。这里给出用例的
28、文字列表形式。,软件工程方法,59,2018/11/20,例 记录成绩用例的描述,记录成绩,软件工程方法,60,2018/11/20,4、构建用例图模型,将已确定并细化的参与者和用例放入用例图。此时，再借助关联（包含）和泛化的关系给出用例之间的结构模型。,软件工程方法,61,2018/11/20,3 需求分析用例建模案例,以“企业综合信息管理系统”为例，介绍需求分析阶段的业务和系统用例建模的步骤。 3.1 客户需求分析 1业务组织结构（综述）“企业综合信息管理系统”的用户是企业各级管理部门的工作人员、公司经理和系统操作人员。该系统主要提供“财务管理”、“人力资源管理”、“生产调度管理”、“进销
29、存管理”、“设备安全管理”、和“行政事务管理”等方面的服务。,软件工程方法,62,2018/11/20,2具体功能要求 本案例只对其中的“进销存管理子系统”进行详细的需求分析用例建模。（1）销售管理1）制定销售计划2）与客户签订销售合同3）检查合同履约率4）生产调度管理部门组织生产5）库存管理部门对产品进行入库、出库处理6）财务管理部门收取客户货款7）售后服务,软件工程方法,63,2018/11/20,（2）采购管理 1）制定原材料（零部件）采购计划 2）与客户签订采购合同 3）检查合同履约率 4）库存管理部门对原材料进行入库验收、存储 5）财务管理部门支付货款 （3）库存管理 1）产品入库管
30、理 2）原材料（零部件）入库管理 3）原材料（零部件）出库管理 4）产品出库管理 5）库存管理 6）采购管理部门组织采购 7）生产调度管理部门安排生产 8）财务管理部门对库存物资进行核算,软件工程方法,64,2018/11/20,3需求补充说明 （1）数据保存 采购合同：每个合同执行期可能多达几个月，合同需要长期保留。 销售合同：每个合同执行期可能多达几个月，合同需要长期保留。 历年履约合同：履约后的合同需要长期（几十年）保留，以备查使用。 库存货物清单：库存货物量随出、入库有所消长，长期保存。 货物损毁报表：长期保留，以备查使用。 入库单：长期保留，以备查核算使用。 出库单：长期保留，以备查
31、核算使用。 库存货物资产核对表：长期保留，以备查使用。,软件工程方法,65,2018/11/20,（2）系统的用户 客户、仓库管理员、销售人员、采购人员、公司经理、财务管理系统、生产调度管理系统。（3）系统运行用户界面 销售合同管理用户界面： 采购合同管理用户界面： 仓库货物清单管理用户界面：（4）系统运行的软件、硬件环境1）系统运行的软件环境2）系统运行的硬件环境,软件工程方法,66,2018/11/20,3.2 确定系统范围和系统边界 1进销存管理子系统的业务范围 2进销存管理子系统的系统边界3.3 确定执行者“进销存管理子系统”有5个人执行者和2个系统执行者，即“采购人员”、“销售人员”
32、、“仓库管理员”、“客户”、“公司经理”、“生产调度管理子系统”和“财务管理子系统”。,软件工程方法,67,2018/11/20,3.4 确定用例 （1）“企业综合信息管理系统”中的用例（一层） 财务管理； 人力资源管理； 生产调度管理； 进销存管理； 设备安全管理； 行政事务管理。 （2）“进销存管理子系统”中的用例（第二层） 销售管理； 采购管理； 库存管理。 （3）“销售管理子系统”中的用例（第三层） 制定产品销售计划； 签订销售合同； 督促客户付款； 监督产品发货； 检查合同履约； 提供售后服务。,软件工程方法,68,2018/11/20,（4）“采购管理子系统”中的用例（第三层）制定
33、采购计划；签订采购合同；货物入库检验；支付货款；检查合同履约。 （5）“库存管理子系统”中的用例（第三层）入库管理；出库管理；库存管理。,软件工程方法,69,2018/11/20,3.5 分层绘制用例图 1最高层用例图,软件工程方法,70,2018/11/20,2第2层用例图,软件工程方法,71,2018/11/20,3第3层用例图,软件工程方法,72,2018/11/20,4第4层用例图,软件工程方法,73,2018/11/20,软件工程方法,74,2018/11/20,3.6 描述用例 1“增加销售合同”用例 用例编号：04010101（共有4层用例图结构，每层用2位数字表 示， 采用8位
34、编号。） 用例名： 增加销售合同 执行者: 人执行者：合同管理员、客户、公司经理。系统执行者：“财务管理子系统”和“生产调度管理子系统”。 目 的: 合同管理员将与客户签订的销售合同的详细内容录入管理系统，用于对销售合同进行统计、查询、检查是否履约等，监控正在履约的合同。 类 型： 端点、主要的、基本的 级 别： 一级,软件工程方法,75,2018/11/20,过程描述： （1）合同管理员输入标识码（ID），系统识别标识码的有效性； （2）初始化一个新销售合同，设置各种处室标志； （3）输入一个新的具有唯一性的合同编号； （4）将与客户签订的销售合同的详细内容录入管理系统； （5）退出系统。
35、与其它用例的关联：过程描述（1）中包含身份验证用例；（4）中包含编号自动生成用例。 异常事件流处理： （1）标识码有效性检查失败：系统检测标识码有效性失败，允许重新输入。 （2）编号也可以由合同管理员手动输入，系统自动进行唯一性检查。出现错误，允许重新输入。2“修改合同”用例 ,软件工程方法,76,2018/11/20,建模要点,构建结构良好的用例： 1）为系统和部分系统中单个的、可标识和合理的原子行为命名； 2）将公共的行为抽取出来，放到一个被包含用例中，再将它include进来； 3）对于变化部分，将其抽取出来，放到一个扩展用例（用extent连接）中； 4）清晰地描述事件流，使得读者能够
36、轻而易举地理解 构建结构良好的用例图：摆放元素时，应该避免交叉线的出现 ；对于语义上接近的行为和角色，最好使它们在物理上也更加接近； 根据系统实际情况控制粒度,软件工程方法,77,2018/11/20,例子,有一个爱书之人，家里各类书籍已过千册，平时又时常有朋友外借，因此需要一个个人图书理系统。该系统应该能够将书籍的基本信息按计机类、非计算机类分别建档，实现按书名、作类别、出版社等关键字的组合查询功能。在使用系统录入新书籍时系统会自动按规则生成书号，以修改信息，但不能够删除记录。该系统还应该够对书籍的外借情况进行记录，可对外借情况列打印。另外，还希望能够对书籍的购买金额、册按特定时限进行统计。
37、,软件工程方法,78,2018/11/20,用例图的绘制流程,软件工程方法,79,2018/11/20,记录需求特性表,软件工程方法,80,2018/11/20,识别参与者,已有的上下文关系图（表示系统范围）及其他相关模型：它们描述了系统与外部系统的边界，从这些图中可以寻找出与系统有交互关系的外部实体。 项目相关人员分析：对项目的相关人员进行分析，就能够决定出哪些人将会与系统进行交互。 书面的规格说明和其它项目文档（如会谈备忘录等） 需求研讨会和联合应用开发会议的记录：这些会议的参与者通常是很重要的，因为他们在组织中所代表的角色就是可能与系统发生交互的参与者。 当前过程和系统的培训指南及用户手
38、册：这些东西中经常会有潜在参与者。,软件工程方法,81,2018/11/20,合并需求获得用例,软件工程方法,82,2018/11/20,错误-不能用include,软件工程方法,83,2018/11/20,优化,软件工程方法,84,2018/11/20,网上选课系统：管理员通过系统管理界面进入，建立本学期要开的各门课程，将课程信息保存在数据库中，并可以对课程进行改动和删除。学生通过浏览器根据学号和密码进入选课界面，在这里学生可以查询已选课程信息并选课，教师可以选择所上课程并提交成绩。 管理员负责维护各项信息。这些操作结果存入数据库中。,软件工程方法,85,2018/11/20,软件工程方法,
39、86,2018/11/20,现有一医院病房监护系统，病症监视器安置在每个病房，将病人的病症信号实时传送到中央监视系统进行分析处理。在中心值班室里，值班护士使用中央监视系统对病员的情况进行监控，根据医生的要求随时打印病人的病情报告，定期更新病历，当病症出现异常时，系统会立即自动报警, 并实时打印病人的病情报告，立及更新病历。要求根据现场情景，对医院病房监护系统进行需求分析， 建立系统的Use case model。,软件工程方法,87,2018/11/20,请对系统需求进行分析！,经过初步的需求分析，得到系统功能要求： 1、监视病员的病症（血压、体温、脉搏等） 2、定时更新病历 3、病员出现异常
40、情况时报警。 4、随机地产生某一病员的病情报告。,例2 医院病房监护系统,监视病情,更新病历,软件工程方法,88,2018/11/20,二、简单的需求分析说明系统名称：医院病房监护系统根据分析系统主要实现以下功能：1、病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到中央监护系统。2、中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信号的正常值进行比较，当病症出现异常时系统自动报警。3、当病症信号异常时，系统自动更新病历并打印病情报告。4、值班护士可以查看病情报告并进行打印。5、医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病历。6、系统定期自动更新病历。
41、,软件工程方法,89,2018/11/20,三、用UML的静态建模机制定义并描述系统的静态结构（一）建立系统的用例图1、通过以下六个问题识别角色(1)谁使用系统的主要功能？(2)谁需要系统的支持以完成日常工作任务？(3)谁负责维护，管理并保持系统正常运行？(4)系统需要应付（或处理）哪些硬设备？(5)系统需要和哪些外部系统交互？(6)谁（或什么）对系统运行产生的结果（值）感兴趣？,软件工程方法,90,2018/11/20,通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色：值班护士，医生，病人，标准病症信号库。角色描述模板,通过分析可以初步识别出系统的用例为：中央监护，病症监护，提
42、供标准病症信号，病历管理，病情报告管理。顶层用例图为：,角色描述,软件工程方法,91,2018/11/20,通过分析可以初步识别出系统的用例为：中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。顶层用例图为：,软件工程方法,92,2018/11/20,将用例细化，可以得到分解的用例： 1、中央监护 分解为： a 分解信号 将从病症监护器传送来的组合病症信号分解为系统可以处理的信号。b 比较信号 将病人的病症信号与标准信号比较 。c 报警 如果病症信号发生异常（即高于峰值），发出报警信号。d 数据格式化 将处理后的数据格式化以便写入病历库 。 2、病症监护 分解为：e 信号采集 采集病人的病症信号。f 模数转化 将采集来的模拟信号转化为数字信号。g 信号数据组合 将采集到的脉搏，血压等信号数据组合为一组信号数据。h 采样频率改变 根据病人的情况改变监视器采样频率。 3、提供标准病症信号 i（此用例不分解）,软件工程方法,93,2018/11/20,4、病历管理 分解为：j 生成病历k 查看病历l 更新病历 m 打印病历 5、病情报告 分解为：n 显示病情报告 在显示器上显示病情o 打印病情报告 在打印机打印病情报告,软件工程方法,94,2018/11/20,给出细化的用例图,细化的用例图,
