表2用例描述格式课件.ppt

1、2023年2月8日星期三第1页第4章 建立用例模型v4.1 需求获取v4.2 分析需求v4.3 用例在需求分析中的使用v4.4 识别参与者v4.5 确定用例v4.6 用例的粒度v4.7 用例间的关系v4.8 用例描述v4.9 用例建模2023年2月8日星期三第2页v需求分析就是分析软件用户的需求是什么。v需求分析之所以重要，就因为他具有决策性、方向性和策略性的作用，它在软件开发过程中具有举足轻重的地位，在一个大型软件系统的开发中，他的作用要远远大于程序设计。v需求分析的任务就是解决“做什么”的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求。2023年2月8日星期三第3页v整

2、个软件需求工程研究领域划分为需求开发和需求管理两部分。需求工程 需求开发 需求管理 验证 编写规格说明 分析 问题获取 2023年2月8日星期三第4页4.1 需求获取v需求是客户在项目立项时就有的一个远景。客户需求将决定在整个项目中需要承办方具体做些什么，即承办方的任务。承办方在明确了需求后，就会开始后期的设计、开发、测试、部署等工作。2023年2月8日星期三第5页4.1 需求获取v需求获取在软件工程中非常重要，因为后续的设计、开发等都基于需求。如果需求获取不正确或在需求开发过程中很多功能没有挖掘出来，那么在后期选择弥补时，将会造成项目延期以及成本大幅度增加的严重后果。v如何获取需求是摆在承办

3、方面前的首要任务。2023年2月8日星期三第6页4.1 需求获取v需求获取的目的是通过各种途径获取用户的需求信息，由于在实际工作中，大部分客户无法完整地讲述其需求，因此需求获取是一件看似简单，做起来却很难的一件事情。v在需求获取过程中，主要需要弄清楚3个问题，即：明确需要获取的信息（What）明确所获取信息的来源和渠道（Where）怎样获取需求（How）。2023年2月8日星期三第7页4.1 需求获取v(1)明确需要获取的信息（What）v需求分析师应在需求获取前明确需要获取的信息，以确保在实施需求获取时有的放矢。通常需求获取需要获取的信息包括三大类：a.与问题域相关的背景信息（如业务资料、组

4、织结构图和业务处理流程等）；b.与要求解决的问题直接相关的信息；c.用户对系统的特别期望与施加的任何约束信息。2023年2月8日星期三第8页4.1 需求获取v(2)明确所获取信息的来源和渠道（Where）v需求分析师还应确定获取需求信息的来源与渠道，以提高需求分析师在需求获取阶段的工作效率，使得所收集的信息更加有价值、更加全面。v需求信息的来源通常包括：a.来自客户的需求；b.竞争对手的产品优势与不足；c.国家政策、业务规则以及相关行业标准；d.实施产品设计所需满足的需求；e.执行测试验证工作所需满足的需求；f.实施系统安装、维护所需满足的需求。2023年2月8日星期三第9页4.1 需求获取v

5、获取需求信息的渠道包括：a.用户或客户b.公司研发管理部门c.公司技术管理部门d.项目实施部门e.营销管理部门f.旧有系统的研发项目组g.来自项目组内2023年2月8日星期三第10页4.1 需求获取v(3)怎样获取需求（How）v需求分析师应选择至少一种需求获取技术获取相关的需求，作为需求分析的依据。需求获取技术包括但不限于：a.用户访谈b.用户调查c.现场观摩用户的工作流程，观察用户的实际操作d.从行业标准、规范中提取需求e.文档挖掘f.需求讨论会g.原型法 2023年2月8日星期三第11页4.2 分析需求v通过需求获取，总结出客户服务系统主要功能需求包括以下几个方面：(1)客户可以通过不同

6、的方式（如电话，互联网）对软件产品或项目提出使用中的BUG或疑难问题以及投诉建议等内容。(2)客户服务人员应当能保存客户资料，保存客户历次来电内容，并对客户提出的问题及时给予解答，不能在电话中处理的应当交由相关技术工程师继续跟进处理。(3)对需要安排上门维护的申请应能及时反映给相关部门领导，并由其作出派工处理。(4)应能及时反馈有派工任务的消息给相关技术工程师，并能保存其处理结果。(5)各部门领导应能对投诉的申请给予及时处理，并能保存处理结果。(6)公司领导和部门领导应能及时查询客户的来电内容，了解产品使用情况及客户服务人员的售后服务质量等相关业务的综合统计信息。v以上需求信息需要进行详细的分

7、析、归纳。2023年2月8日星期三第12页4.2 分析需求v经过分析，为满足上述需求的客户服务系统应包括以下几个模块：(1)基础资料维护模块。包括客户基础资料录入修改，客户服务系统用户信息的添加、删除和修改，软件产品的基础资料维护，已上线项目的基础资料维护以及FAQ经验库的数据维护。(2)客户服务业务处理模块。包括客户咨询服务处理，故障申报处理，投诉处理，客户服务人员回访处理，维护人员上门处理，部门领导派工处理。(3)信息查询统计模块。包括基础资料查询统计，客户咨询的查询与统计，派工单完成情况，回访情况，维护报告查询统计以及相关报表的查询。2023年2月8日星期三第13页4.2 分析需求v软件

8、系统的需求分析可以由产品工程师或系统分软件系统的需求分析可以由产品工程师或系统分析师或两者分阶段合作完成全部的需求分析工作。析师或两者分阶段合作完成全部的需求分析工作。其主要任务是逐步细化所有的软件功能，找出系其主要任务是逐步细化所有的软件功能，找出系统各元素间的联系、接口特性和设计上的限制，统各元素间的联系、接口特性和设计上的限制，分析它们是否满足需求，剔除不合理部分，增加分析它们是否满足需求，剔除不合理部分，增加需要部分。最后，综合成系统的解决方案，给出需要部分。最后，综合成系统的解决方案，给出待开发系统的详细逻辑模型。其主要包括以下几待开发系统的详细逻辑模型。其主要包括以下几个步骤：个步

9、骤：2023年2月8日星期三第14页4.2 分析需求v(1)提取出核心、主要、急迫的业务，明晰业务流程通过需求调研，我们会发现用户各方面的业务很多，从大处着眼，包括用户的各种业务项目、业务流程，再明细到业务过程的每一个单据，每一条记录。从用户繁杂的业务中进行业务、业务流程的提取。需要分析用户的这个业务流程中哪些是系统能帮助管理的，哪些是要在系统外处理的，充分分析用户现有的业务和业务流程。2023年2月8日星期三第15页4.2 分析需求v(2)运用管理思想，优化业务流程客户服务系统是管理软件产品，要帮助用户解决的是管理问题，那么用户是这样的业务流程，就需要分析这样的流程合理吗？还有缺陷吗？怎样做

10、能提高效率、解决问题？可以运用更先进的管理思想吗？。一般情况下，需要从两个方面考虑业务流程的优化。一是我们采用了网络计算机这些新的技术手段，较之原先手工、电话等方式在信息的传递、信息的共享、数据的处理等方面将会带来新的方式，必将改变原有的业务流程。另一方面就是我们根据对用户业务的理解，考虑是否可以运用先进的管理思想，进行现有业务流程的重组或优化。2023年2月8日星期三第16页4.2 分析需求v(3)进行业务分类，规划系统蓝图明确以上内容后就可以描绘系统蓝图了。系统有几个子系统，每个子系统有哪些模块，各个模块处理哪些业务，等等。v以上内容主要是针对系统功能性需求，除此之外，系统还有性能需求也需

11、要明确。2023年2月8日星期三第17页4.3 用例在需求分析中的使用v规划出了软件的功能模块，只是软件的功能框架结构，下一步就需要明确描述每个模块的具体内容。包含什么内容、能做什么操作，每一个功能点的说明、业务规则、详细功能描述等等。这些软件需求规格必须描述的内容需要有个标准的表现方式。2023年2月8日星期三第18页4.3 用例在需求分析中的使用v用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例模型包括用例图和用例描述。v用例图主要由以下模型元素构成：2023年2月8日星期三第19页4.3 用例在需求分析中的使用v(1)参与者(Acto

12、r)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。2023年2月8日星期三第20页4.3 用例在需求分析中的使用v(2)用例(Use Case)用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。2023年2月8日星期三第21页4.3 用例在需求分析中的使用v(3)关联(Association)关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。2023年2月8日星期

13、三第22页4.3 用例在需求分析中的使用v以课程注册系统为例，当参与者是学生时，学生使用该系统可以进行登录系统、注册课程和查看报告的操作。登录注册课程学生查看报告2023年2月8日星期三第23页4.3 用例在需求分析中的使用v用例方法完全站在用户的角度上（从系统的外部）来描述系统的功能。v在用例方法中，把被定义系统看作是一个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。v用例方法首先描述了被定义系统有哪些外部使用者（抽象成为Actor），这些使用者与被定义系统发生交互；针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务（抽象成为Use Case），或者说系统是如何被这些

14、参与者使用的。v所以从用例图中，我们可以得到对于被定义系统的一个总体印象。2023年2月8日星期三第24页4.3 用例在需求分析中的使用v与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。v在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统设计主要由对象模型来记录描述。另外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。用例方法比传统的SRS更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。2023年2月8日星期三第25页4.3 用例在需求分析中的使用v在RUP中，用例

15、被作为整个软件开发流程的基础，很多类型的开发活动都把用例作为一个主要的输入制品（Artifact），如项目管理、分析设计、测试等。根据用例来对目标系统进行测试，可以根据用例中所描述的环境和上下文来完整地测试一个系统服务，可以根据用例的各个场景（Scenario）来设计测试用例，完全地测试用例的各种场景可以保证测试的完备性。2023年2月8日星期三第26页4.4 识别参与者v客户服务系统是对公司和客户进行统一管理的系统，根据客户服务系统案例需求说明书，具体包括以下几个方面：(1)基础资料维护。包括系统管理员添加、删除、修改客户服务系统账户信息，添加、修改、删除公司产品及项目信息；客户服务人员添加

16、、修改、删除客户资料信息，添加、修改、删除经验库信息等。(2)业务处理。包括客户服务人员新增、修改、删除客户咨询信息；维护人员处理客户问题、填写维护报告；部门领导处理投诉，安排任务等。(3)统计查询。包括客户资料查询、客户来电咨询查询、经验库查询、客户服务系统用户信息查询、回访任务及维护报告查询等。v明确以上信息后，分析系统的参与者。2023年2月8日星期三第27页4.4 识别参与者v对于这个系统，通过需求陈述文档，可以得到以下一些信息：系统管理员维护系统用户帐号和产品项目信息。客户服务人员维护客户资料、客户咨询以及经验库信息。维护人员填写维护报告。部门领导处理投诉。v所以创建以下参与者：系统

17、管理员、客户服务人员、维护人员、部门领导。2023年2月8日星期三第28页4.4 识别参与者v参与者是在系统之外，透过系统边界与系统进行有意义交互的任何事物。通俗地讲，参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手：(1)系统开发完成之后，有哪些人会使用这个系统？(2)系统需要从哪些人或其他系统中获得数据？(3)系统会为哪些人或其他系统提供数据？(4)系统需要与哪些其他系统交互？(5)系统是由谁来维护和管理并保持其正常运行？(6)系统需要应付（处理）哪些硬设备？(7)谁（或什么）对系统运行产生的结果感兴趣？(8)有没有自动发生的事件？2023年2月8日星期三第29页4.4 识

18、别参与者v在这里需要注意的是：系统参与者一定是与系统有直接联系的事物，这里事物包括人和其他系统。“直接联系”是个什么概念呢？在客户服务系统中，客户打电话给客户服务人员反馈问题，客户服务通过系统对反馈的问题进行处理，在这个业务过程中，客户并没有直接操作客户服务系统，就没有直接联系，所以客户不是系统的参与者。这样的例子还有很多，比如超市的收银系统，收银员是该系统的参与者，而超市客户则不是；银行系统中，银行的窗口服务员是参与者，而在窗口存钱或取钱的客户不是参与者。但在银行ATM系统中，客户从银行ATM机存取款，客户是ATM系统中的参与者。2023年2月8日星期三第30页4.5 确定用例v找到参与者之

19、后，就需要根据参与者来确定系统的用例。v对于每一个参与者，相对应的用例如下：2023年2月8日星期三第31页4.5 确定用例v客户服务人员：(1)登录系统(2)查询客户信息及咨询记录(3)查询经验库信息(4)查询基础资料信息(5)补充完善经验库信息(6)维护客户资料(7)维护来电记录 2023年2月8日星期三第32页4.5 确定用例v维护人员：(1)查询自己的派工单及报告信息(2)接受并处理自己的派工单(3)填写报告2023年2月8日星期三第33页4.5 确定用例v系统管理员：(1)管理用户(2)维护基础资料(3)维护系统 2023年2月8日星期三第34页4.5 确定用例v部门领导：(1)查询

20、客户资料及咨询信息(2)查询项目及产品信息(3)查询维护人员派工单的执行情况(4)安排派工任务2023年2月8日星期三第35页4.5 确定用例v确定用例主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的，用例命名往往采用动宾结构。参与者与用例连起来读，往往是一条通顺的句子，例如：客户服务人员（参与者）维护客户资料（用例）。2023年2月8日星期三第36页4.5 确定用例v寻找用例可以从以下问题入手（针对每一个参与者）：(1)参与者为什么要使用该系统？(2)参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？(3)参与者是否会将外

21、部的某些事件通知给该系统？(4)系统是否会将内部的某些事件通知该参与者？2023年2月8日星期三第37页4.6 用例的粒度v对于一个系统来说，不同的人进行用例分析后得到的用例数目有多有少。v如果用例粒度很大，那么得到的用例数就会很少，如果用例粒度很小，那么得到的用例数就会很多。v那么到底多大的粒度才是比较合适的？2023年2月8日星期三第38页4.6 用例的粒度v用例就是客户付钱给我们，要我们帮助解决的问题。这些问题是软件系统的重心所在，也是客户的价值所在。当客户来找我们解决问题时，如同一个病人去找医生看病。这个病可能是大病，也可能是小病。正如医生无法决定病人得什么病一样，我们也无法决定客户所

22、遇到的问题，我们所能选择的只是解决这些问题的方案。v所以用例（大小）粒度的决定在于客户，用例的关键在于准确反映客户需求。2023年2月8日星期三第39页4.6 用例的粒度v用例是一种用来探索需求的技术，而需求和设计之间的区别在于需求解决的是系统“做什么”的问题；而设计则是针对需求中提出的问题，解决系统该“怎么做”的问题。需求调研的过程是发现和界定问题的过程，设计的过程是寻找解决方案的过程。需求分析的思维方式是总结和抽象，系统设计的思维方式是分解和细化。2023年2月8日星期三第40页4.6 用例的粒度v在确定用例过程中，主要有两个方面的问题会迷惑分析者。其一是当分析人员面对具有业务流程的用例时

23、该如何处理；其二是面对具有功能分解的用例时如何处理。2023年2月8日星期三第41页4.6 用例的粒度v具有业务流程的用例是指某个用例需要分几个业务阶段来完成，如客户服务系统中维护人员接受派工单需要首先查看到派工单，然后选择接受派工单。那么对于查看派工单和接受派工单，究竟是作为一个用例好，还是作为两个用例好？我们对这类问题处理的原则是什么？2023年2月8日星期三第42页4.6 用例的粒度v用例是被从现实的场景中抽象出来的。如果这些场景有紧密的联系（高内聚），且能真正反映用户的需求，那么用用例技术来组织它们则可以复用这些场景中的步骤描述，从而达到事倍功半的效果。在该例中，查看派工单和接受派工单

24、两个步骤的真正目的就是让维护人员接受派工任务，用户的需求也在于此，这两个步骤是紧密联系在一起的，所以把它们作为一个用例。2023年2月8日星期三第43页4.6 用例的粒度v具有功能分解的用例是指该用例往往可以分解为多个用例，如：维护客户资料，在该用例中客户服务人员可以做3件事：增加一条客户资料、修改一条客户资料、删除一条客户资料，那么分析人员可以有两种方案，第一种方案是把这个用例单独看作一个用例来描述，第二种方案则是分成3个用例来描述。2023年2月8日星期三第44页4.6 用例的粒度v不同的人对这个问题会有不同的看法。v从捕获用户需求的角度考虑，建议采用第一种方案，采用第二个方案的主要问题是

25、限制了分析人员的思路。v虽然从系统实现的角度看，对客户资料的操作有添加、删除、修改等，但事实上，用户真正目的可能并不是对记录的添加、修改和删除，而是别的目的。如维护人员填写维护信息，虽然这个要求会涉及到维护信息的增加、删除和修改，但如果采用第二个方案有可能忽视了维护人员报告维护信息这个真正的用户需求。2023年2月8日星期三第45页4.7 用例间的关系v用例之间本来是独立的、并行的，但是某些时候用例之间确实是具有一定的业务关系，例如客户在浏览Web站点时可以选择是否在线购买商品，“浏览Web站点”用例与“购买商品”用例之间就存在一定的关系。需要有一种方法来清楚地描述这样的需求。2023年2月8

26、日星期三第46页4.7 用例间的关系v这种需求可以通过描述用例间的关系来表达。客户在浏览Web站点时可以选择是否在线购买商品，“浏览Web站点”用例与“购买商品”用例之间可以通过扩展关系来描述：“购买商品”用例是“浏览Web站点”用例的扩展。v用例与用例之间的关系有三种：包含、扩展和泛化。2023年2月8日星期三第47页4.7 用例间的关系v这几种关系都是从现有的用例中抽取出部分信息，然后通过不同的方法来重用这部分信息，以减少模型维护的工作量。2023年2月8日星期三第48页4.7 用例间的关系v包含（include）关系 包含关系是把几个用例的公共行为分离成一个单独的用例，使这几个用例与该单

27、独的用例之间所建立的关系。被抽取出来的单独的用例叫做被包含用例（Inclusion），而抽取出公共用例的几个用例称为基础用例（Base）。具体地讲，就是将被包含用例的业务插入到基础用例的业务中。UML中，用例之间的包含关系是由基础用例指向被包含用例的一条虚线箭头来表示的，线上加构造型。2023年2月8日星期三第49页4.7 用例间的关系v在ATM机中，如果查询、取现、转帐这三个用例都需要打印一个回执给客户，我们就可以把打印回执这一部分内容提取出来，抽象成为一个单独的用例“打印回执”，而原有的查询、取现、转帐三个例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时，就只需要改动一个用例，

28、而不用在每一个用例都作相应修改，这样就提高了用例模型的可维护性。2023年2月8日星期三第50页4.7 用例间的关系打印回执取款存款储户转帐2023年2月8日星期三第51页4.7 用例间的关系v扩展（extend）关系扩展（extend）关系是指基础用例（Base）中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例（Extension）的业务过程在一定的条件下按照相应的扩展点插入到基础用例（Base）中。对于包含关系而言，子用例中的业务过程是一定要插入到基础用例中去的，并且插入点只有一个。而扩展关系可以根据一定的条件来决定是否将扩展用例的业务过程插入基础用例业务过程，并且插入点可以有多个。

29、UML中，用例之间的扩展关系是由扩展用例指向基础用例的一条带箭头的虚线表示的，线上加构造型。2023年2月8日星期三第52页4.7 用例间的关系v例如对于电话业务，可以在基本通话（Call）业务上扩展出一些增值业务，如：呼叫等待（Call Waiting）和呼叫转移（Call Transfer）。在这个例子中，呼叫等待和呼叫转移都是对基本通话用例的扩展，但是这两个用例只有在一定的条件下（如应答方正忙或应答方无应答）才会将被扩展用例的事件流嵌入基本通话用例的扩展点，并重用基本通话用例中的事件流。2023年2月8日星期三第53页4.7 用例间的关系CallCall WaitingCall Tran

30、sfer2023年2月8日星期三第54页4.7 用例间的关系v泛化（generalization）关系当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用例，其他用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。但在实际应用中很少使用泛化关系。UML中，用例之间的泛化关系用三角形箭头表示，由子用例指向父用例。2023年2月8日星期三第55页4.7 用例间的关系v例如：执行交易是一种交易抽象，执行房产交易和执行证券交易都是一种特殊的交易形式。用例“交易”与“房产交易”、“证券交易”之间就可以表示为泛化

31、关系。交易房产交易证券交易2023年2月8日星期三第56页4.8 用例描述v用例已经确定下来，但是用例只是一个简单的“动-宾”词语，只知其意，不知其深意。如客户服务人员的用例：查询经验库信息。通过此用例我们可以知道基本的业务过程是查询经验信息，但是并不知道到底按照什么方式查，查些什么信息出来。在这种情况下，系统设计人员无法很好地开展工作。这样就意味着我们必须详细的描述用例。2023年2月8日星期三第57页4.8 用例描述v用例的描述应该包含哪些内容，并没有一个统一的标准，不同的开发机构可能会有不同的要求，但一般应包含以下内容：2023年2月8日星期三第58页4.8 用例描述v(1)用例的目标是

32、什么？v(2)用例是怎么启动的？v(3)参与者和用例之间的消息是如何传送的？v(4)用例中除了主路径外，其他路径是什么？v(5)用例结束后的系统状态是怎样的？v(6)其他需要描述的内容是什么？v总之，描述用例的基本原则是尽可能写得“详细”、“充分”。2023年2月8日星期三第59页4.8 用例描述v作为OOA文档的一个组成部分，用例的描述应该有一定的规范格式，但没有统一标准。然而，一个开发机构内部应该采用统一的格式。后面是按照一个业界比较认同的格式来描述客户服务系统中的“维护客户资料”用例。2023年2月8日星期三第60页4.8 用例描述1.UC1：维护客户资料1.1 简要说明 该用例提供客户

33、服务人员对公司客户资料进行录入、修改和删除功能；Actor（角色）：客户服务人员；2.事件流2.1 基本流 1、Actor选择“维护客户资料”功能启动该用例；2、系统显示维护客户资料的主界面，其中列出查询界面；3、Actor选择新增客户资料；4、系统提示录入客户资料；5、Actor输入客户编号、来源（售后、培训、电话咨询、关系客户）、类型（代理商、终端客户、关系客户）、省份、公司名称、联系人，联系电话、EMAIL、登记时间、地址、邮编等。输入完成后提交这些信息；6、系统验证输入数据是否正确；如验证不正确则提示用户重输入；如检验正确则增加这个客户信息，并返回到客户资料维护主界面；7、Actor选

34、择退出，该用例结束。2023年2月8日星期三第61页4.8 用例描述2.2 备选流2.2.1 修改客户资料 1、在客户资料维护的主界面，用户选择查询某客户资料；2、系统显示符合条件的客户资料，内容包括；客户编号、来源、类型、省份、公司名称；3、Actor选择修改某客户资料；4、系统显示修改客户资料界面；5、Actor修改来源（售后、培训、电话咨询、关系客户）、类型（代理商、终端客户、关系客户）、省份、公司名称、联系人，联系电话、EMAIL、地址、邮编、备注。并提交这些信息；6、系统验证输入数据是否正确（与基本流一致）；如检验不正确则提示用户重输入；如验证正确则修改这个客户信息，并返回到客户资料

35、维护主界面。2.2.1.1取消修改客户资料 1、在修改客户资料界面中，用户选择取消；2、系统返回到客户资料维护主界面。2023年2月8日星期三第62页4.8 用例描述2.2.2删除客户资料 1、在客户资料维护主界面的客户资料显示部分，用户选择“删除”某客户资料；2、系统提示用户确认删除；3、用户选择确认；4、系统删除所选客户资料，并返回客户资料维护主界面。2.2.2.1取消删除客户资料 1、在提示用户确认删除的界面中，用户选择取消；2、系统返回到客户资料维护主界面。3.特殊需求 无4.前置条件 客户服务人员已经登录系统5.后置条件 系统中保存了用户所输入的客户资料。6.扩展点 无 2023年2

36、月8日星期三第63页4.8 用例描述v以上内容是参考了一些开发机构和以上内容是参考了一些开发机构和UML使用使用者的经验后总结出来的用例描述格式，形式者的经验后总结出来的用例描述格式，形式如表如表4-2所示：（具体使用时可用表格的形所示：（具体使用时可用表格的形式表示，也可以不使用表格形式）式表示，也可以不使用表格形式）2023年2月8日星期三第64页4.8 用例描述v表表4-2 用例描述格式用例描述格式描述项描述项说说 明明用例名称表明用户的意图或用例的用途，如“查询客户资料”用例编号【可选】唯一标识符，在文档其他地方可以通过标识符来引用该用例用例描述简要概述用例参与者与此用例相关的参与者优

37、先级【可选】一个有序的排列，1代表优先级最高状态【可选】用例的状态，通常为以下几种之一：进行中、等待审批、通过审查或未通过审查前置条件一个条件列表，这些条件必须在访问该用例前被满足后置条件一个条件列表，这些条件必须在完成该用例后被满足基本操作流程描述用例中各项工作都正常进行时用例的工作方式备选操作流程描述变更工作方式、出现异常或发生错误时所遵循的路径被泛化的用例【可选】此用例所泛化的用例列表被包含的用例【可选】此用例所包含的用例列表被扩展的用例【可选】此用例扩展点用例列表2023年2月8日星期三第65页4.8 用例描述v用例描述虽然看起来简单，但事实上它是捕获用户需求的关键一步，很多人虽然也能

38、给出用例的描述，但描述中往往存在很多错误或不恰当的地方，在描述用例时容易犯的错误包括：2023年2月8日星期三第66页4.8 用例描述v(1)只描述参与者的行为，没有描述系统的行为。例如：1取款1.1 简要说明 客户取款；2事件流2.1基本流 1、储户插入ATM卡，并键入密码；2、储户按“取款”按钮，并键入取款数目；3、储户取走现金、ATM卡以及收据；4、储户离开。2023年2月8日星期三第67页4.8 用例描述v(2)只描述系统的行为，没有描述参与者的行为。例如：1取款1.1简要说明 客户取款；2事件流2.1基本流 1、ATM系统获得ATM卡和密码；2、设置事务类型为“取款”；3、ATM系统

39、获取要提取的现金数目；4、验证账户上是否有足够储蓄金额；5、输出现金、数据和ATM卡；6、系统复位。2023年2月8日星期三第68页4.8 用例描述v以上两个错误原因是没有理解用例描述的以上两个错误原因是没有理解用例描述的作用，即描述参与者与系统的交互过程。作用，即描述参与者与系统的交互过程。既然是交互过程那就是有来有往，既然是交互过程那就是有来有往，“用户用户做什么做什么”然后然后“系统做什么系统做什么”这两样应该这两样应该是成对出现在描述中。是成对出现在描述中。2023年2月8日星期三第69页4.8 用例描述v（3）描述过于冗长。例如：2事件流2.2备选流2.2.1修改客户资料1、在客户资

40、料维护的主界面，用户选择查询某客户资料；2、系统显示符合条件的客户资料，内容包括；客户编号、来源、类型、省份、公司名称，同时在每行的开始位置放置“修改”的按钮，以便让用户点击进行资料修改；3、用户选择某客户记录左边的“修改”按钮，修改某客户资料；4、系统打开修改客户资料界面；5、2023年2月8日星期三第70页4.8 用例描述v（4）描述的内容不够明确。例如：2.2备选流2.2.1修改客户资料1、在客户资料维护的主界面，用户选择查询某客户资料；2、系统显示符合条件的客户资料；3、用户选择修改某客户资料；4、系统打开修改客户资料界面；5、用户修改来源（售后、培训、电话咨询、关系客户）、类型（代理

41、商、终端客户、关系客户）、省份、公司名称、联系人，联系电话、EMAIL、地址、邮编、备注。并选择“提交”；6、系统检查输入数据是否正确；如检验不正确则提示用户重新输入；如检验正确则修改这个客户信息，并返回到客户资料维护主界面。2023年2月8日星期三第71页4.8 用例描述v在该描述中，“系统显示符合条件的客户资料”这句话就不明确，客户资料包括的内容很多，是全部显示出来还是有选择的显示出来，有选择的话到底显示哪几个属性的内容没有交代清楚；“系统检查输入数据是否正确”这句话也不明确，数据的检查条件是什么需要指定出来。2023年2月8日星期三第72页4.9 用例建模v参与者、用例以及用例间的关系已

42、经明确，这时需要用一种比较直观的方式表达这些信息。如何表达参与者、用例、以及它们之间的关系呢？2023年2月8日星期三第73页4.9 用例建模v用例图是显示一组用例、参与者以及它们之间关系的图，一个用例模型由若干个用例图来描述。v在上面的分析过程中，识别出了系统管理员、部门领导、维护人员、客户服务人员4个参与者，用例有登录系统、查询客户信息及咨询记录、查询经验库信息、查询基础资料信息、补充完善经验库信息、客户资料维护等。根据以上分析结果得到以下客户服务系统用例图。2023年2月8日星期三第74页4.9 用例建模v系统参与者关系图客服人员维护人员部门领导系统管理员客服系统用户客服系统用户是抽象角

43、色，其角色基数等于0。-系统中没有一个单独的角色是客服系统用户，每个用户实际上都是客服人员，维护人员，部门领导，系统管理员中的一种。2023年2月8日星期三第75页4.9 用例建模v部门领导统计查询、处理投诉、派工用例图处理投诉处理派工查询统计客户来电情况部门领导安排回访安排上门维护2023年2月8日星期三第76页4.9 用例建模v客户服务人员业务处理及资料维护用例图查询客户信息查询经验库信息查询客户咨询维护个人信息维护客户咨询信息维护客户信息维护经验库修改密码修改基本信息客服人员登录系统2023年2月8日星期三第77页4.9 用例建模v维护人员业务处理用例图接受派工填写报告处理派工单登录系统

44、维护人员查询派工单2023年2月8日星期三第78页4.9 用例建模v系统管理员进行系统维护用例图维护用户信息维护产品基础资料维护系统查询用户信息备份数据库恢复数据库查询产品及项目系统管理员登录系统设置用户权限2023年2月8日星期三第79页4.9 用例建模vUML定义了各种表现形式来描述用例图。在UML中，参与者用名字标识在下面的人形图标表示。用例用椭圆形来表示，图形下面所标出的是用例名。系统管理员设置用户权限2023年2月8日星期三第80页4.9 用例建模v参与者与用例之间的关系用单向关联线表示。系统管理员维护产品基本资料2023年2月8日星期三第81页4.9 用例建模v由于参与者事实上就是

45、类，因此，参与者之间也有继承关系（泛化）。v参与者之间的泛化关系表示一个一般性的参与者与另一个特殊性的参与者之间的关系。子参与者继承了父参与者的行为和含义，还可以增加自己的特殊行为和含义，子参与者可以出现在父参与者能出现的任何位置上。v在UML中，泛化关系用带三角形箭头的实线表示。客服人员维护人员部门领导系统管理员客服系统用户2023年2月8日星期三第82页总结v用例是系统、子系统或类和外部的参与者交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列。v用例命名往往采用动宾结构或主谓结构，但最常见的是动宾结构。v系统需求一般分功能性需求和非功能性需求，用例只涉及功能性需求。v用例之间可以有泛化关系、包含关系和扩展关系等。v参与者是指系统以外的、需要使用系统或与系统交互的东西，包括人、事物和系统等。v参与者之间可以有泛化关系。v用例的描述是用例的主要部分。v用例的描述格式没有一个统一标准，不同的开发机构可以采用自认为适合的格式。v用例分析结果的好坏与分析人员的个人经验和领域知识有很大关系。v用例模型包括用例图和用例文档（用例描述）。