学校课件3用例

1、用例高天迎 用例n1 用例的概念n2 用例建模技术n3 实例图书馆管理系统中的用例需求分析n需求分析的任务是确定所开发的软件的功能、性能、数据等各个方面的要求。主要解决系统“做什么”的问题。n需求分析是软件整个开发过程中的一个关键过程。n需求分析中的“沟通鸿沟”： 需求分析需要各方面人员（如分析人员、开发人员、客户等）的参与，而这些人员有着不同的知识背景，对目标系统的认知程度也各不相同，这种差异导致各方面人员之间沟通困难，人为的给需求分析的实施增加了难度。需求规格说明书的目录框架参考需求n需求定义：需求定义：需求（requirement）就是系统（更广义的说法是项目）必须提供的能力和必须遵从的

2、条件。n需求分类：需求分类： n功能性功能性（行为的），有具体的完成内容的需求。n客户登录、邮箱网站的收发收发邮件、论坛网站的发帖留言等。n用户能够搜索所有的数据集合n每一个订单需要分配一个唯一标识符，用户可以永久保存起来需求n非功能性非功能性（其它所有的行为） ，软件产品为满足用户业务需求而必须具有且除功能需求以外的特性，包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。 n性能要求：要求系统能满足100个人同时使用，页面反应时间不能超过6秒；n可靠性： 系统能724小时连续运行，年非计划宕机时间不能高于8小时。要求能快速的部署，特别是在系统出现故障时，能够快速的切换到备

3、用机。n领域规则，法律，知识产权需求n在统一过程（UP）中，需求按照“FURPS+”模型进行分类。 n功能性（Functional）：特性、功能、安全性； n可用性（Usability）：人性化因素、帮助、文档； n可靠性（Reliability）：故障频率、可恢复性、可预测性； n性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率； n可支持性（Supportability）：适应性、可维护性、国际化、可配置性。 需求n“FURPS+”中的“+”是指一些辅助性的和次要的因素，比如：n实现（Implementation）：资源限制、语言和工具、硬件等； n接口（Int

4、erface）；强加于外部系统接口之上的约束； n操作（Operation）：对其操作设置的系统管理； n包装（Packaging）例如物理的包装盒； n授权（Legal）：许可证或其他方式。需求问题的代价想改进就能改进吗？需求石头问题需求问题对策1. 概念n1.1 概述n1.2 参与者n1.3 用例n1.4 用例之间的关系1.1 概述 n用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。n用例图最常用来描述系统以及子系统。 1.1 概述 n用例图包含6个元素：n参与者（Actor）n用例（Use Case）n关联关系（Association）n包含关系（Inc

5、lude）n扩展关系（Extend）n泛化关系（Generalization） 1.2 参与者 n定义：Actor是指系统以外的，需要使用系统或与系统交互的东西，包括人，设备和其它系统。Actor有不同的译名，如：参与者, 活动者, 执行者, 行动者等。n系统外部的一个实体。n参与用例的执行过程。n通过向系统输入或请求系统输入某些事件来触发系统的执行。n由参与用例时所担当的角色来表示。n每个参与者可以参与一个或多个用例。 1.2 参与者n参与者的种类：n系统用户n与所建造的系统交互的其他系统n一些可以运行的进程 确定参与者n如何寻找系统的参与者 n谁使用系统的主要功能？n谁改变系统的数据n谁从

6、系统获取信息n谁需要系统的支持以完成日常工作任务？n谁负责维护、管理并保持系统正常运行？n系统需要应付（处理）哪些硬设备？n系统需要和哪些外部系统交互？n谁（或什么）对系统运行产生的结果感兴趣？n有没有自动发生的事件确定参与者n对参与者建模的过程中需要注意的问题n参与者对于系统而言总是外部的n参与者可以直接或间接的同系统交互n一个人或事物在与系统交互时，可以扮演多个角色n每一个参与者必须有简短的描述参与者间的关系n参与者(actor)之间可以存在泛化泛化关系，表示一个一般性的参与者与另一个更为特殊的参与者之间的联系。n参与者间的泛化关系示例：说明n例：在线银行系统的一些可能的参与者参与者n客户

7、：从系统获取信息并执行金融交易。n管理人员：开办系统的用户。获取并更新信息。n厂商：接受作为转帐支付结果的资金nmail系统说明n责任类似或重叠泛化出一个抽象执行者1.3 用例 nUse Case概念是Jacobson于60年代和70年代在爱立信公司开发AKE，AXE系列系统时发明的，并在其博士论文(85年)和92年出版的论著中做了详细论述。n在软件开发中采用Use Case驱动是Jacobson对软件界最重要的贡献之一。 n自Jacobson的著作出版后，面向对象领域已广泛接纳了用例这一概念，并认为它是第二代面向对象技术的标志。UseCase驱动use case对软件开发的意义实现实现测试测

8、试需求需求分析和设计分析和设计Use Cases 把所有这些过程绑到一起把所有这些过程绑到一起Use Case的定义n在一个workshop(专题讨论会)上，14位主要的OO专家对Use Case有14个定义。n定义1：use case是对一个活动者活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列。n定义2：The specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem, or class can p

9、erform by interacting with outside actors.用例的三种常用形式n摘要简洁的一段概要，通常用于主成功场景n一般用于早期需求分析中n非正式非正式的几个段落，覆盖不同场景n一般用于早期需求分析中n详述详细编写所有步骤及各种变化n以摘要的形式编写了大量用例之后，详细编写其中少量重要的、高价值的用例摘要形式的用例n处理销售n顾客携带所购商品到达收银台，收银员使用POS系统记录每件商品。系统连续显示累计总额，并逐行显示细目。顾客输入支付信息，系统对支付信息进行验证和记录。系统更新库存信息。顾客从系统获得购物小票，然后携带商品离开。例：在线银行系统的一些可能的用例：浏

10、览帐户余额列出交易内容划拨资金支付帐款登录退出系统编辑配置文件买进证券卖出证券use case说明： Use case从用户的角度获取操作性需求，可以促进与用户沟通，并不考虑系统内部对该功能的具体实现方式。 用例是对系统的功能进行清晰而一致的描述，代表系统中各个项目相关人员之间就系统的行为所达成的契约。 使用use case可以用来划分系统与外部实体的界限，是OO系统设计的起点，是类、对象、操作的来源。 用例的一些特点：（1）用例描述了用户提出的一些可见的需求；（2）用例可大可小；（3）用例对应一个具体的用户目标。争论： 本质上，Use Case分析是一种功能分解功能分解(functional

11、 decomposition)(functional decomposition)的技术，没有以对象观点为中心，因而有人认为Use Case 分析只是OOA/OOD的先导性工作，并非OOA/OOD过程的一部分；但也有人视其为OOA/OOD的一环。 不管怎样，Use Case是UML的一部份，Use Case是OO开发过程中的第一步。用例n为用例的逻辑流程建立文档，详细描述系统用户的工作和系统本身的工作n用例的描述是独立于实现方法的，描述系统“做什么”，而不是“怎么做”n1. 简要说明n2. 前提条件n3. 事件流（主事件流、其他事件流、错误流 ）n4. 事后条件用例n用例的组成n简要说明n与用

12、例相关的说明，描述该用例的作用n应包括执行用例的不同类型用户和通过这个用例要达到的结果n前提条件n列出用例执行之前必须满足的条件，例如另一个用例必须要先执行n后置条件n用例执行完毕后必须满足的条件，例如必须执行另一个用例n事件流程（主事件流、其他事件流、错误流 ）n从用户角度描述执行用例的具体步骤n包括用例的开始和结束、用例如何与参与者交互、用例的正常流程、主事件流的变体以及错误流用例n学生提交实验结果的用例描述 student提交实验结果用例用例名称用例名称提交实验结果提交实验结果参与者参与者学生学生假设假设学生完成了实验学生完成了实验前置条件前置条件学生已预约了实验，并且完成实验学生已预约

13、了实验，并且完成实验后置条件后置条件学生提交实验结果后，系统数据库存储实验结果学生提交实验结果后，系统数据库存储实验结果主事件流主事件流1.1.学生登录系统；学生登录系统；2.2.学生完成实验结果；学生完成实验结果；3.3.学生选择该门实验课程点击学生选择该门实验课程点击“上传上传”按钮；按钮；4.4.系统弹出上传实验结果菜单；系统弹出上传实验结果菜单；5.5.学生选择自己的实验结果文件夹进行上传；学生选择自己的实验结果文件夹进行上传；6.6.上传成功之后系统提示提交成功；上传成功之后系统提示提交成功；7.7.系统修改存储学生是否提交实验结果的字段。系统修改存储学生是否提交实验结果的字段。备选

14、事件流备选事件流1a.1a.非法用户：提示用户名或密码错误；非法用户：提示用户名或密码错误；5a.5a.学生的实验结果文件夹未按要求命名，不是以学期和学号两部分组成学生的实验结果文件夹未按要求命名，不是以学期和学号两部分组成：系统提示文件夹命名错误；：系统提示文件夹命名错误；5b.5b.学生所提交的实验结果文件夹是空：系统提示文件夹为空；学生所提交的实验结果文件夹是空：系统提示文件夹为空；6a.6a.在上传实验结果的过程中突然中断：系统要求学生重新上传实验结果在上传实验结果的过程中突然中断：系统要求学生重新上传实验结果；6b.6b.学生误传了实验结果，把其他课程的实验提交到该实验课，可以进行学

15、生误传了实验结果，把其他课程的实验提交到该实验课，可以进行删除操作，重新上传，重复删除操作，重新上传，重复3 37 7的操作；的操作；6c.6c.学生未按时提交实验结果：系统提示已过期；学生未按时提交实验结果：系统提示已过期；用例n只书写“可观测的”的n使用主动语句n句子必须以执行者或系统作为主语n每一句都要朝目标迈进n分支和循环n不要涉及界面细节用例用例用例用例用例用例用例Use Case的描述nuse case采用自然语言描述参与者与系统进行交互时双方的行为，不追求形式化的语言表达。n描述用例时的原则：尽可能写得“充分”，而不是追求写得形式化，完整，漂亮。n作为OOA文档的一个组成部分，U

16、se Case的描述应该有一定的规范格式。n在统一的标准出现之前，人们可以创造发明use case的不同表示形式，但至少在一个开发组织内部应该采用统一的格式。Use Case的描述用例的一个描述格式：用例的一个描述格式： ( (用例模板用例模板) )n用例名称用例名称。表明用户的意图或use case的用途，如“划拨资金”。 n标识符标识符 可选可选 。唯一标识符，如 “UC1701”，在文档的别处用标识符来引用这个用例。 n用例描述用例描述。概述用例的几句话。n参与者参与者。与此用例相关的参与者列表。n优先级优先级。一个有序的排列，1代表优先级最高。n状态状态 可选可选 。用例的状态，通常为

17、以下几种之一：进行中、等待审查、通过审查或未通过审查。n前置条件前置条件。一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足。 n后置条件后置条件。一个条件列表，如果其中包含条件，则这些条件将在用例完成以后得到满足。n基本操作流程基本操作流程。描述用例中各项工作都正常进行时用例的工作方式 。 n可选操作流程可选操作流程。描述变更工作方式、出现异常或发生错误的情况下所遵循的路径。n被泛化的用例被泛化的用例 可选可选 。此用例所泛化的用例列表。n被包含的用例被包含的用例 可选可选 。此用例所包含的用例列表。n被扩展的用例被扩展的用例 可选可选 。此用例所扩展的用例列表。 n修改历

18、史记录修改历史记录 可选可选 。关于用例的修改时间、修改原因和修改人的详细信息。 n问题问题 可选可选 。与此用例的开发相关的问题的列表。 n决策决策 可选可选 。关键决策的列表，将这些决策记录下来以便维护时使用。n频率频率 可选可选 。参与者访问此use case的频率。如用户每日访问一次或每月一次。例：用例模板n用例名称用例名称：处理订单n标识符标识符：UC1701n用例描述用例描述：当一个订单初始化或者被查询的时候这个用例开始。它处理有关订单的初始化定义和授权等问题。当订单业务员完成了同一个顾客的对话的时候，它就结束了。n参与者参与者：订单业务员n优先级优先级：1n状态状态：通过审查n前

19、置条件前置条件：订单业务员登录进系统n后置条件后置条件：下订单；库存数目减少 n基本操作流程基本操作流程：n1. 顾客来订购一个吉他，并且提供信用卡作为支付手段。n2. .n可选操作流程可选操作流程：n顾客来订购一个吉他，并且使用汇票的方式。n顾客来订购一个风琴，并且提供信用卡作为支付手段。n顾客使用信用卡下订单，但那张信用卡是无效的。n顾客来下订单，但他想要的商品没有存货。n被泛化的用例被泛化的用例：无n被包含的用例被包含的用例：登录 (UC1706)。n被扩展的用例被扩展的用例：无n修改历史记录修改历史记录：nRene Becnel, 定义基本操作流程, 2002/10/3 nRene B

20、ecnel, 定义可选操作流程, 2002/10/6用例描述的一些常见错误分析n在描述用例时易犯的错误包括：n只描述系统的行为，没有描述actor的行为。n只描述actor的行为，没有描述系统的行为。n设定对用户界面的设计的要求。n过于冗长。n例1：下面是一个用例描述的片断：Use Case: Withdraw Cash（提取现金）参与者：Customer主事件流：1. 储户插入ATM卡，并键入密码。2. 储户按 “Withdrawal” 按钮，并键入取款数目。3. 储户取走现金、ATM卡并拿走收据。4. 储户离开。上述描述中存在的问题：n只描述了参与者的动作序列，没有描述系统的行为。n改进的

21、描述如下：Use Case: Withdraw Cash （提取现金）参与者: Account Holder主事件流：1. 通过读卡机，储户插入ATM卡。2. ATM系统从卡上读取银行ID、帐号、加密密码、并用主银行系统验证银行ID和帐号。3. 储户键入密码，ATM系统根据上面读出的卡上加密密码，对密码进行验证。4. 储户按“FASTCASH”按钮，并键入取款数量，取款数量应该是5美元的倍数。5. ATM系统通知主银行系统，传递储户帐号和取款数量，并接收返回的确认信息和储户帐户余额。6. ATM系统输出现金，ATM卡和显示帐户余额的收据。7. ATM系统记录事务到日志文件。n例2：下面是一个用

22、例描述的片断：Use Case: Withdraw Cash参与者: Customer主事件流：1. ATM系统获得ATM卡和密码。2. 设置事务类型为 Withdrawal3. ATM系统获取要提取的现金数目。4. 验证帐户上是否有足够储蓄金额。5. 输出现金，数据和ATM卡。6. 系统复位。上述描述中存在的问题：n只描述了ATM系统的行为，而没有描述参与者的行为。这样的描述很难理解，验证和修改。n改进的描述同例1。n例3：下面是一个用例描述的片断：Use Case: Buy Something参与者: Customer主事件流：1. 系统显示“ID and Password”屏幕。2. 顾

23、客键入ID和密码，然后按OK按钮。3. 系统验证顾客ID和密码，并显示“Personal Information”屏幕4. 顾客键入姓名、街道地址、城市、州、邮政编码、电话号码，然后按OK按钮。5. 系统验证用户是否为老顾客。6. 系统显示可以卖的商品列表。7. 顾客在准备购买的商品图片上点击，并在图片旁边输入要购买的数量。选购商品完毕后按“Done”按钮。8. 系统通过库存辅助系统验证要购买的商品是否有足够库存。.etc.上述描述中存在的问题：n对用户界面的描述过于详细，对于需求文档来说，详细的UI描述对获取需求获取需求并无帮助。n改进的描述可以如下所示：Use Case: Buy Some

24、thing参与者: Customer主事件流：1. 顾客使用ID和密码进入系统。2. 系统验证顾客身份。3. 顾客提供姓名、地址、电话号码。4. 系统验证顾客是否为老顾客。5. 顾客选择要购买的商品和数量。6. 系统通过库存辅助系统验证要购买的商品是否有足够库存。. etc.n例4：下面是一个用例描述的片断：Use Case: Buy Something参与者: user(或Customer)主事件流：1. 顾客使用ID和密码进入系统。2. 系统验证顾客身份。3. 顾客提供姓名。4. 顾客提供地址。5. 顾客提供电话号码。6. 顾客选取商品。7. 顾客确定商品的数量。8. 系统验证顾客是否为老

25、顾客。9. 系统打开到库存系统的连接。10. 系统通过库存系统请求当前库存量。11. 库存系统返回当前库存量12. 系统验证购买商品的数量是否小于库存量。. etc.上述描述中存在的问题：n对用例的描述过于冗长，可以采用更为简洁的描述方式，如合并类似的数据项（步骤3至步骤5），提供抽象的高层描述（步骤9至12）等。n改进的描述可以如下所示：Use Case: Buy Something参与者: user(或Customer)主事件流：1. 顾客使用ID和密码进入系统。2. 系统验证顾客身份。3. 顾客提供个人信息(包括姓名、地址、电话号码), 选择要购买的商品及数量。4. 系统验证顾客是否为老

26、顾客。5. 系统使用库存系统验证要购买的商品数量是否少于库存量。. etc.如何发现用例n选择系统边界n在许多情形下，系统边界是显而易见的n寻找主要参与者n参与者可以使用户，外部的硬件或者另外一个系统n为每个参与者确定他们的目标n参与者-活动列表如何发现用例n定义用例n一般而言，为每一个用户目标定义用例n定义用例需要交流和参与n领域专家的参与非常重要n迭代开发识别用例n业务语言而非技术语言识别用例n用户观点而非系统观点识别用例n识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。 n特定参与者希望系统提供什么功能n系统是否存储、检索信息，如果是，由哪个参与者触发n当系

27、统状态改变时，是否通知参与者n是否存在影响系统的外部事件n那个参与者通知系统这些事件识别用例n用例的“粒度”n最常犯错误把步骤当作用例n把执行者动作当作用例n把系统活动当作用例识别用例n用例的“粒度”： CRUDn警惕CRUD泛滥！n所有业务最终都会成为CRUD光CRUD能为actor提供价值吗？识别用例n用例的“粒度”n一个用例背后可能隐藏着许多数据操作识别用例n用例的“粒度”：如果确实是纯CRUDn如果CRUD不涉及复杂的交互，一个用例“管理”即可n不管是C、R、U、D，都是为了完成“管理”的目标n甚至很多种基本数据的管理都可以用一个用例表示识别用例n用例的“粒度”n也可以把包含复杂交互的

28、路径独立出去形成用例讨论n登录？讨论n几个登录？5.1.4 用例间的关系 nUse Case除了和参与者有关联(association)外，Use Case之间也存在着一定的关系(relationship)。包括：泛化(generalization)关系、包含(include)关系、扩展(extend)关系等。n也可以利用UML的扩充机制自定义Use Case间的关系。关联关系n表示参与者用例之间进行通信。 n不同的参与者可以访问相同的用例。 泛化关系n泛化泛化(generalization)(generalization)代表一般与特殊的关系。use case间的泛化关系与类之间的泛化关系（

29、继承关系）类似。n子用例表示父用例的特殊形式。 n子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变继承的行为。泛化关系n泛化关系（Generalization）n如果系统中一个或多个用例是某一个一般用例的特殊化用例时，就应该使用用例的泛化关系，例如：包含关系n包含包含(Include)(Include)n一个用例可以简单地包含其他用例具有的行为，并把它所包含的行为作为自身行为的一部分，这称作用例间的包含关系n客户用例可以简单地包含提供者用例具有的行为，并把它所包含的用例行为作为自身行为的一部分 包含关系的例子：inclusion use casebase use case包含关系n包

30、含关系的特点n包含用例（客户用例）执行，则被包含用例（提供者用例）必须执行n什么时候使用包含关系？n如果两个以上的用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用例可以和这个用例建立包含关系n一个用例的功能太多时，可以用包含关系建模成两个以上的用例，降低用例的复杂度扩展关系n扩展扩展(extend)(extend)关系关系的基本含义与泛化关系类似，但是对于扩展Use Case有更多的规则限制，即基本的Use Case必须声明若干“扩展点” (extension point)(extension point)，而扩展Use Case只能在这些扩展点上增加新的行为。n基础用例提供扩

31、展点以添加新的行为。n扩展用例提供插入片段以插入到基础用例的扩展点上。扩展关系n扩展关系的特点n基础用例没有扩展用例也是完整的用例n基础用例被执行时，一般不会涉及扩展用例，只有特定的条件发生，扩展用例才可能被执行，这是与包含关系的差别UseCase的泛化、扩展、包含关系的比较 当处理正常行为的变型时，而且只是偶尔描述时，可以考虑只用泛化关系泛化关系。 如果需要重复处理两个或多个Use Case时，可以考虑使用包含关系包含关系，实现一个基本Use Case对另一个Use Case的引用。 当描述正常行为的变型，而且希望采用更多的控制方式时，可以在基本Use Case中设置扩展点，使用扩展关系扩展

32、关系。小结：actor，usecase的关系(relationship)类型说明：可在usecase间建立关联，但意义不是很明确。association关联:actor和usecase之间的关系包含:usecase之间的关系includeextend扩展:usecase之间的关系generalization泛化:actor之间或usecase之间的关系关系类型说明表示符号5.2 用例图建模技术n5.2.1 对语境建模n5.2.2 对需求建模5.2.1 对语境建模识别系统外部的参与者。将类似参与者组织成泛化的结构层次。在需要加深理解的地方，为每个参与者提供一个构造型。将参与者放入到用例图中，并说

33、明参与者与用例之间的通信路径。5.2.2 对需求建模 识别系统的外部参与者来建立系统的语境。考虑每一个参与者期望的行为或需要系统提供的行为。把这些公共的行为命名为用例。确定提供者用例和扩展用例。对这些用例、参与者和它们之间的关系建模。用注释修饰用例。选修课管理系统用例图用例图n在UML中，一个用例模型由若干个用例图用例图(use case diagram)(use case diagram)描述。用例图是显示一组用例、参与者以及它们之间关系的图。 例：金融贸易系统的用例图。一个use case图的例子financial trading system用例图中的一些主要图标AssociationG

34、eneralizationDependency说明：UML中不使用颜色来作为图形语义的区分标记。注释连接Realizeuse-case realizationextend use case注释include use casen用例图是表达用例和活动者及其之间关系的载体n用例图是模型图，用例图可包含用例，活动者以及它们之间的关系n用例图的用途是为软件系统、软件子系统、类的动态行为建模。它从两个方面对其建模对象的内容进行描述，即：n描述它们的边界n对它们进行需求分析用例的组织和用例图用例的组织和用例图n用例图和用例关系在编写用例工作中是次要的。用例是文本文档。编写用例意味着编写文本。n绘制简单的用

35、例图，并与参与者-目标列表关联。Use Case图的建立步骤(1) 找出系统外部的参与者和外部系统，确定系统的边界和范围；(2) 确定每一个参与者所期望的系统行为；(3) 把这些系统行为命名为Use Case；(4) 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分；(5) 编制每一个Use Case的脚本；(6) 绘制Use Case图；(7) 区分主事件流和异常情况的事件流，可以把表达异常情况的事件流的Use Case画成一个单独的子Use Case；(8) 细化Use Case图，解决Use Case间的重复与冲突问题。3 实例图书馆管理系统n3.1 确定系统涉及的总体信息n3.2

36、 确定系统的参与者n3.3 确定系统的用例n3.4 使用Rational Rose绘制用例图的步骤n3.5 图书馆管理系统的用例图3.1 确定系统涉及的总体信息n读者：n借书n还书n书籍预定n查询 3.1 确定系统涉及的总体信息n图书馆管理员：n书籍借出处理n书籍归还处理n预定信息处理 3.1 确定系统涉及的总体信息n系统管理员：n增加书目n删除或更新书目n增加书籍n减少书籍n增加读者帐户信息n删除或更新读者帐户信息n书籍信息查询n读者信息查询 3.2 确定系统的参与者n首先分析系统所涉及的问题领域和系统运行的主要任务：n分析使用该系统主要功能部分的是哪些人。n谁将需要该系统的支持以完成其工作。n系统的管理者与维护者。 3.2 确