UML用况图PPT课件

1、1,第3章 用况图,3.1 系统边界 3.2 参与者 3.3 用况 3.4 用况图 3.5 用况分析 3.6 高级用况建模 3.7 检查与调整 3.8 例题,2,第3章 用况图,什么是用户需求？,用户需求即用户对所要开发系统提出的各种要求和期望。 它包括系统的功能、性能、可靠性和保密要求以及交互方式等技术性要求和资金额度、交付时间、资源使用限制等非技术性要求。 对分析员而言,功能需求是分析阶段要考虑的核心因素。,3,第3章 用况图,软件开发中的常见现象（严峻的现实）：, 用户提出的要求不完整、不准确 需求经常变化，工作没完没了 开发后期才发现误解了需求 功能都实现了，但由于性能，使用方面问题导

2、致用户不满 客户的许多增强需求未及早提出，导致软件后期维护费用陡升 测试效果差，因为测试人员不明白软件要做什么 支付了客户并不想要的产品,4,第3章 用况图,软件项目中，40%-60%的问题都是在需求分析阶段埋下的隐患，在需求审核上投入1个小时，可节省10倍以上错误更正时间，返工开工占开发总费用的40%，而70%-80%的返工是由需求方面的错误导致。 成功有效的需求开发和需求管理能为组织节省大量时间和金钱。,需求提取：可能是软件开发中最困难、最关键、最容易出错，最需沟通的方面（引导用户说出他们想要的东西：面谈、问卷、观察、文档、原型法等记录下需求）,Ivar Jacobson 从1967年开始

3、在爱立信公司所从事的近20多年对大量不同电话呼叫类型建模的工作经验，发明了use case概念。,5,需求技术,获取软件的需求是软件开发过程的重要难题，在当今的软件需求的实践中，RUP过程中的用例技术、XP中的用户故事（User Story）技术、FDD的Feature描述技术是获取需求的最佳技术，这三个技术的共同点是：站在用户的角度看待系统、定义系统 ；使用用户能够看懂的语言来描述系统，定义系统三种需求技术的特点见表6-1所示。,表6-1 三种获取需求的技术,6,第3章 用况图,软件开发的途径：首先要准确地描述用户需求中的功能需求,形成功能规格说明（SRS）。（大多数情况下,使用的是自然语言

4、。） 用况图的作用： 1、实现对功能需求描述。用于对系统的功能及与系统进行交互的外部事物建模。 2、通过找出与系统交互的外部事物,说明它们如何与系统交互更易于对系统进行探讨和理解。 3、用况图是进行OOA的第一步工作,对OOD阶段的人机交互设计和系统测试来说,用况也是非常重要的。,7,第3章 用况图,3.1 系统边界,系统边界：一个系统所包含的所有系统成分与系统以外事物 的分界线。,对系统的组成认识： 系统：被开发的计算机软硬件自身 系统成分：在OOA/OOD中定义的那些系统元素 系统外部实体：人员、设备、外系统,8,第3章 用况图,现实世界中的事物与系统的关系包括如下几种情况: 某些事物作为

5、系统成分位于系统边界内。 某些事物将是与系统进行交互的参与者，系统中没有相应的成分作为它们的抽象表示。它们只是系统边界外的参与者。 某些事物可能既有一个对象作为其抽象描述，而本身(作为现实世界中的事物)又在系统边界以外与系统进行交互。 某些事物即使属于问题域，也与系统责任没有什么关系。,超市-商品,超市-收款员,超市-收款员（顾客）,超市-保安,9,第3章 用况图,系统是由一条边界图包围起来的未知空间，系统只通过有限几个接口与外部交互。因此，把内外交互情况描述清除就确切定义了系统需求。,1用例图的认识 用例图是描述用例、参与者及其关系的图。与所有UML的其它图一样，用例图可以包括注释、约束。

6、图中的元素包括：参与者、用例、一个方框和一些表示关系的连接线，所有的用例都位于方框之内，该方框称为“系统边界”。 方框内是棋牌管理系统的多个用例，方框外是外部参与者。,10,第3章 用况图,3.2 参与者,3.2.1 概念与表示法 1、参与者的语义及表示法 参与者：是为了完成某个任务，而与系统进行交互的实体。是用户相对系统而言所扮演的角色,11,第3章 用况图, 参与者是虚拟的概念：可以是人、设备、外系统。一个人可以扮演多个角色。,参与者可以请求系统提供服务 参与者也可以响应系统发出的请求,所有参与者的请求/响应的完全集成构成了可以觉察到的系统边界。,表示法：,actor 外系统,12,第3章

7、 用况图,参与者命名，应是最能描述其功能的合适名称。, 避免为代表人的参与者起一个实际人名。, 要以他们使用系统时的工作头衔作为参与者命名。,张三、李四,教师、开发人员等, 即使工作头衔不同，但所做操作相同，也需要将其合并。,13,第3章 用况图,3.2.2 识别参与者 1、人员 从直接使用系统的人员发现参与者。强调直接使用 注意：特定的人在系统中扮演不同的角色，因此要分属不同的参与者 2、外部系统 所有与系统交互的外部应用系统都是参与者 3、设备 所有与系统交互的设备,其他子系统 其上级系统,监视器、鼠标、键盘等标准用户接口设备，不算 外部传感器、受控马达等算,到此，我们找出食堂管理系统的参

8、与者,14,参与者间的关系,在用例图中，使用泛化关系来描述多个参与者之间的公共行为。,参与者间的泛化关系示例：,15,第3章 用况图,识别和组织参与者的策略：, 启动系统行为的参与者最容易识别的参与者 从用户角度考虑怎样使用这个系统，重点考虑上述三种类型的参与者 记录参与者责任 通过识别继承关系，组织参与者,我们给出的参与者可否使用继承关系组织？,16,第3章 用况图,3.3 用况,描述参与者与系统的交互，系统外在的可见的需求情况,详细说明：一个用况是一个或几个参与者，使用系统一项功能时所进行的交互过程的描述。,使用用况的原因如下：（用况的优点）, 是对用户需求的规范化描述 可以为开发者提供一

9、种认识和理解系统的技术 为领域专家，最终用户和开发者提供了一种相互交流的手段 方便设计人机界面及测试用例,17,第3章 用况图,定义用况的含义1-8：, 一项功能。外部参与者触发该功能 系统级的功能 只描述做什么，不描述怎么做 可观察的结果值是指系统对参与者的动作要做出响应 表达了系统的功能需求，也表达了系统的功能划分 相对完整的功能,在自动提款机上提取现金,插入卡 输入密码 选择取款数目,18,第3章 用况图, 仅描述参与者与系统要完成的一件事情（不能过于综合） 参与者发起交互的可能性大,用况表示法：包含有用况名字的椭圆,用况名,用况名可以是带有数字、字母和除保留符号冒号以外的任何标点符号的

10、任意字符号,注意事项： 创建一个用况名时，要尽量使用主动语态动词和可以描述系统上执行的功能的名词。 eg：撞车、丢钱等,为什么命名时不允许使用“：”？,也有例外：系统发现异常 系统主动向设备发命令,19,第3章 用况图,编写用况容易出现的问题, 用户界面太多，用户界面属于设计范畴，鼠标，按键等内容不应出现在用况中 较低目标层次上的用况太多，无法展示系统将会给其最终用户提供什么功能 使用用况表示非行为信息，性能需求，业务规则等不要在用况中描述 目标实现不完整，尤其是错误处理,20,第3章 用况图,描述格式： （无标准规定）,用况文档模板（不要求都有，可取舍） 用况名通常为一动词 简述对用况的简单

11、描述 参与者 包含、扩展、继承的用况 前置条件：描述启动此用况所必须具备的条件 后置条件：描述用况结束时确保成立的条件 基本流（主要成功场景） 可选流（扩展流） 例外 限制 注释（附加信息）,21,第3章 用况图,注意：,基本流 通常不包括任何条件和分支 如下页 扩展流 存放所有的条件处理 扩展部分非常重要，它说明了所有其他场景或分支 （无论成功的还是失败的） 有时候从某个位置产生的扩展会非常复杂，这时就 会促使我们使用一个单独的用况来表达这个扩展；,22,用例事件流的表示,图6-3 小刘取款场景,23,第3章 用况图,3.4 用况图：展示了用况之间以及用况和参与者之间是怎样互相联系的。,用况

12、和参与者的关联：参与者和用况之间的关系。 意味着参与者与用况之间可通信,用况图创造了一个很好的语境图，显示了系统的边界，哪些在系统外，如何使用系统,如果系统比较复杂可绘制多幅，每幅侧重系统功能的一个方面,24,第3章 用况图,3.5 用况图分析,1、选择系统边界（系统边界是否只是一个软件应用，还是硬件与软件作为一个整体，还是需要加上操作者，甚至整个组织） 2、识别参与者（除明显的参与者外，下列问题）,次要参与者：为系统提供服务,25,第3章 用况图,3、捕获用况 识别用况最好的方法是从参与者列表开始，考虑每个参与者如何使用系统。, 利用参与者捕获用况 开始建立用况时，关注点是参与者，要仔细分析

13、参与者，以及其需求，参与者要达到什么目的，需要系统提供什么服务，把所有向参与者提供的服务项目找到，每个服务项目就是一个用况。 从系统功能捕获用况 一项系统功能要描述在一个用况中 穷举方式考虑每个参与者与系统的交互情况 角色扮演：建模人员深入到现场 记录具体流程 脚本场景（行为序列）,给出食堂管理系统的用况，并与参考者建立联系,26,第3章 用况图,1、参与者之间的关系 继承关系：如果一组参与者具有共同的性质，可以把这些性质抽取出来放在另一个参与者中，这组参与者再从中继承。（泛化关系）,B: cook A: mother cook C: father cook,A的实例能与和B的实例进行交互的用

14、况实例进行通信,27,第3章 用况图,用况在出现以下三种情况时，可考虑产生新用况，并在用况间建立关系 在一个用况中存在着几处重复使用的动作序列 在几个用况中存在着重复使用的动作序列 一个用况中的主要动作序列或分支动作过于冗长和复杂，并且分离它们有助于管理和理解。,用况关系有三种：包含、扩展和继承,3.6 高级用况建模,28,第3章 用况图,（1）包含关系 起因： 两个或多个用况中有重复行为，把重复行为放在同一个用况中，原用况引入该用况。 将过长用况分解,A到B的包含关系：用况A在它内部说明的某一位置显式的使用用况B的行为结果,A：基用况 B：被包含用况,好处：避免多次描述同一事件流，有助于确定

15、那里可以重用某些功能，一个用况可以包含多个用况，也可以被多个用况所包含。,29,第3章 用况图,（2）扩展关系 起因：一个或几个用况中存在可选的描述系统行为的片段。用况中可选的，只在特定条件下运行的行为，把可选行为描述抽取出来，形成扩展用况。 A：基用况 B：扩展用况,按A中指定条件，把B插入A中扩展点定义位置，A在指定的扩展点隐式的包含有B用况行为。,30,第3章 用况图,扩展点：用况中的一个或一组位置，在这个位置上，可插入其他用况的完整动作序列或其中的片段（一个用况中，各扩展点的名字是唯一的）,31,第3章 用况图,记录成绩,修改成绩,保存成绩,60分以下,提醒管理员,问题：如果每次都要提

16、醒管理员，该用况图如何表示？,32,第3章 用况图,当建立了多个扩展用况模型后，扩展点不表示哪个用况扩展了基用况，而只表示是否有扩展使用。一个基用况可以有多个扩展点，而所有的扩展点必须对基用况为真。,扩展与包含的区别： 扩展：可选行为；包含：义务行为，必选行为 扩展：基用况可单独存在；包含：基用况不能单独存在 表示法不同： 扩展：由扩展用况指向基用况 包含：由基用况指向被包含用况 扩展：参与者不能与扩展用况直接通信 包含：参与者可以与被包含用况直接通信,33,第3章 用况图,（3）继承关系 与类之间或参与者之间的继承关系一样 B到A的继承关系：特殊用况B是一般用况A的详细说明特殊用况可以增加或

17、覆盖一般用况的行为,注意：被包含的用况和用于扩展的用况一般不能单独使用，只能作为基用况的一部分存在，而一般用况和特殊用况可单独存在。,34,第3章 用况图,3.7 检查与调整 检查与调整原则： （1）参与者 确定所有角色归入响应参与者 所有参与者至少和一个用况相关联 若一个参与者是另一个参与者的一部分，使用继承 两个参与者扮演了相同的角色，考虑合并,35,第3章 用况图,（2）用况 每个用况至少和一个参与者或其他用况相关联 两个用况有相同类似序列，考虑合并或者抽取新用况（形成包含、扩展、继承） 一个用况有完全不同的事件流，可考虑分解,36,第3章 用况图,在对系统的功能需求进行捕获和描述时，需

18、要注意以下几点： 用况正确、无歧义 需求变化、理解偏差（开发中），及时修改用况保证模型的正确性和完整性 不要画成工作流程图 用况大小适中 用况不是人机界面 明确系统做什么，而不是如何做 尽量不要使用多层包含、扩展和继承关系,37,第3章 用况图,不太适合用况方法的情况： 用户很少或没有，接口也很少，如：科学计算/仿真、杀毒软件、编译程序等 功能需求非常简单，非功能需求和约束占主导地位 适用：当前大部分应用软件：功能需求占主导地位，有很多参与者（分为不同用户类型，为它们提供不同功能），具有很多接口,38,6阅读用例图,6用例粒度 用例的粒度，就是用来描述用户目标的大小的程度。从大到小可将用例分成

19、三个层次：概述级、用户目标级、子功能级。下面以读者阅读图书为例，说明用例的三个级别。,39,6阅读用例图,概述级 概述级,参与者把整个系统看成一个用例。如图6-15所示。 用户目标级 目标级用例是对概述级进一步细化。 子功能级 子功能级用例是对目标级用例的进一步细化。,图6-15 概述级,图6-1用户目标级,图6-1子功能级,40,例题1,描述如下的用况图（订单处理系统）,41,例题2,研究生学籍管理系统,方法1：,对登录的描述如下： 研究生启动系统； 系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系统进行验证，给出验证信息； 若通过，且该生选择选课； 系统执行用况“ 选

20、课” 若通过，且该生选择查看学分 系统执行用况“查看学分”,42,例题2,研究生学籍管理系统,方法2：,对“选课”的描述如下： 研究生启动系统； 系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系统进行验证，给出验证信息； 若通过验证，系统执行用况“选课”的其余部分,43,例题2,研究生学籍管理系统,方法3：,对“登录”的描述如下： 研究生启动系统； 系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系统进行验证，给出验证信息； 若通过，且该生选择选课； 系统在扩展点“选课”处执行用况“ 选课” 若通过，且该生选择查看学分 系统在扩展点“查看学分”处执行用

21、况“查看学分”,44,例题2,研究生学籍管理系统,方法4：,对“登录”的描述如下： 研究生启动系统； 系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系统进行验证，给出验证信息； 对“选课”的开始部分描述如下： 若通过了登录，且该生选择选课； 系统开始执行用况“ 选课” ,45,例题3,成绩管理系统 教师可记录成绩。记录成绩包含保存成绩 教师可以更新成绩。更新成绩包含加载、保存成绩 教师、学生和管理员可浏览成绩，浏览成绩包含登录 管理员可以生成报告卡 教师可以分发报告卡 根据以上描述画出用况图。,46,例题3,管理员通过系统管理界面进入，建立本学期要开的各门课程，将课程信息

22、保存到数据库中，并可以对课程进行改动和删除。学生通过浏览器根据学号和密码进入选课界面，在这里学生可以查询已选课程信息并选课，教师可以选择所上课程并提交成绩，管理员负责维护各项信息。这些操作结果存入数据库中。,47,例题3,数据库,48,练习,有一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但不能够产出记录。该系统还应该能够对书籍的外借情况记录，可对外借情况列表打印。另外，还

23、希望能够对书籍的购买金额按特定时限进行统计。,49,练习,50,练习,51,69 用例图应用,691 问题描述 当需求分析人员对用户和客户进行访谈后，就要记录下用户和客户对业务系统的描述。开发人员必须把客户对业务系统的陈述转化为完整的，清晰的、可用于开发系统的描述，这种描述业务系统的格式，必须是客户能理解的、认可的标准格式。当然，“完整”和“清晰”实际上是做不到的。第一次是不可能非常接近这些目标的。但是，最终应有一个文档描述了系统应完成的所有工作（和系统不应完成的工作），而且没有误解。 例如，下面就是汽车租赁系统的业务陈述(Nowhere Cars任务陈述)：,52,69 用例图应用,商店将汽

24、车的跟踪自动化了使用条形码、柜台终端和激光阅读器，这有许多优点：租凭助手的效率提高了20%，汽车很少失踪，客户群很快变大（根据市场调查，其部分原因至少是专业化和效率的显著提高）。 管理层认为，Internet会提供进一步提高效率、降低成本的机会。例如，现在不是打印可用汽车的目录，而可以让每个Internet冲浪人员在线浏览这些目录。对于有特权的客户，可以提供额外的服务，例如通过鼠标点击进行预约。这个领域的目标是每个商店的运营成本降低15%。 在两年内，使用电子商务的所有功能，通过Web浏览器提供所有的服务，在客户中完成汽车的交付和收回，以达到虚拟租凭公司的最终目标，将未预约业务的运营成本降到最

25、低。,53,69 用例图应用,上面有三个段落的任务陈述包含了许多信息：公司的自动化历史；客户对日期的满意度；在线目录和预约；有特权和无特权的客户；节约成本的历史和目标；公司的最终目标（“虚拟租凭公司”）。当然，管理层的一些想法实现起来还有很长的路要走（客户适应虚拟租凭商店的时间可能会超过两年），但调查至少有两个很好的起点：公司的商店目前提供什么服务？哪些适合在Internet上提供？ 上述任务陈述是下面案例分析的基础。虚拟公司的新系统称为Coot，客户可使用的Internet功能集合称为iCoot.,54,69 用例图应用,开发Nowhere Cars系统的优点是：在延长的期限内爱好者出租专用

26、汽车。由于不可能出租所有型号的汽车，客户在要租汽车时，必须找到一家租凭货店。汽车的租凭方式是先到先得到服务，客户可以在当前可用的汽车中选择。另外，如果客户要租用的某型号汽车目前没有，还可以预约，当有匹配的型号汽车时，助手就会与客户直接签约；客户必须在两天内取车（或交抵押金，先于其他客户取车）。会员必须注册，才能电话预约。 692 定义术语表,55,69 用例图应用,每个业务领域都具有它本身独一无二的词汇，需求分析的目的就是理解和定义这些词汇。词汇应该被项目相关人所理解。术语表必须解决同音异义和同义异音问题。 一般来说，我们从问题描述中提取术语表。 下面是汽车租赁系统的术语表： Nowhere

27、Cars术语表 术语 定义 Car（业务对象） 由商店保存的、用于出租的CarModel的实例 CarModel（业务对象） 目录中的一个模型，可用于预约 Customer（业务参与者，业务对象） 为获得一个标准服务而付费的人 Member（业务对象） 其身份和信用状况已得到验证的顾客，因此，可以访问特定的服务（例如电话预约或通过Internet预约）,56,69 用例图应用,术语表中的每一项都定义了一个术语，其定义可短可长。 从案例分析的术语表中可以看出，可以记录每个术语与开发阶段之间的关系（业务参与者、系统参与者）。下面是可以使用的关系列表（每一项都可以用于多种关系）： 业务参与者：业务需

28、求中出现的参与者 业务对象：业务需求中出现的参与者 系统对象：系统需求中出现（在系统内部）的对象 分析对象：分析模型中出现的对象 部署制品：在系统中部署的某个信息，例如文件 设计对象：设计模型中出现的对象 设计节点：构成系统体系结构的计算机或过程 设计层：子系统的垂直部分 设计包：把多个相关类组织在一起，用于组织开发。 收集需求的活动结束后，开发者建立了两个产品：第一个产品是对业务系统的问题描述；第二个产品是对业务系统中词汇的定义。,57,69 用例图应用,693 标识参与者 首先，需要标识业务参与者。参与者是在业务中扮演某个角色的人、部门或者独立的软件系统。一般来说，参与者使用系统或给系统提

29、供服务。 与现实生活一样，参与者可以在不同的时刻，扮演不同的业务角色。例如，小刘在Nowhere Cars商店上班时，他是一个助手；如果他在回家之前要租用一辆汽车，就成为一个顾客。,58,69 用例图应用,我们一般是从业务陈述中获取业务参与者。 下面是汽车租赁系统(Nowhere Cars)的业务参与者表： 助手：商店的一个员工，帮助顾客租用其汽车和预约汽车型号。 顾客：为获得一个标准服务而付费的人。 会员：其身份和信用状况已得到验证的顾客，因此，可以访问特定的服务（例如电话预约或通过Internet预约）。 非会员：其身份和信用状况没有验证的顾客，因此，他要月月必须交押金，租用汽车必须提供一

30、份驾照副本。 AuK：处理顾客信息、预约、出租和可用汽车型号目录的已有系统。 债务部门：处理未付费用的Nowhere Cars部门。 法律部门：处理设计租用汽车事故的Nowhere Cars部门。,59,69 用例图应用,694 标识系统用例 一旦有了参与者，就可以从参与者的角度看系统,问系统能给参与者提供哪些服务?通过一问一答,就可以查找用例。 iCoot系统用例列表: U1：浏览索引：顾客浏览汽车型号的索引。 U2：查看结果：给顾客显示检索到的汽车型号子集。 U3：查看汽车型号细节：给顾客显示检索到的汽车型号细节，例如描述和广告。 U4：搜索：顾客指定类别、构造和引擎规格，搜索汽车型号。

31、U5：登录：会员使用会员号和当前密码登录iCoot。,60,69 用例图应用,U6：查看会员信息：会员查看iCoot存储的会员信息子集，例如姓名、地址和信用卡调节。 U7：进行预约：会员在查看汽车型号的细节时，预约一种汽车型号。 U8：查看租用情况：会员查看当前租用的汽车的汇总信息。 U9：修改密码：会员修改用于登录的密码。 U10：查看预约情况：会员查看还没有结束的预约汇总信息，例如日期、时间和汽车型号。 U11：取消预约：会员取消还没有结束的预约。 U12：注销：会员从iCoot中注销。 系统用例可以在用例图上描述，显示参与者与特定用例的关系这有助于了解系统的使用方式。iCoot的用例图如

32、图6-18所示：,61,69 用例图应用,图6-18 iCoot的一个简单的用例图,62,69 用例图应用,在用例图中，每个用例都在一个椭圆中显示为一个序号和一个标题。包含所有用例的方框表示系统的边界可以把系统名称放在方框中。在系统边界的外部，显示参与者，在用例和使用它们的参与者之间添加关联。,63,610 建模要点,构建结构良好的用例：1）为系统和部分系统中单个的、可标识和合理的原子行为命名；2）将公共的行为抽取出来，放到一个被包含用例中，再将它include进来； 3）对于变化部分，将其抽取出来，放到一个扩展用例（用extent连接）中；4）清晰地描述事件流，使得读者能够轻而易举地理解 构建结构良好的用例图：摆放元素时，应该避免交叉线的出现 ；对于语义上接近的行为和角色，最好使它们在物理上也更加