1、用例与用例分析,湖南大学软件学院,面向对象程序分析与设计,主要内容,基本概念：Use case、Actor、Scenario Use case间的关系 Use Case 分析技术 案例讲解,Use Case,Ivar Jacobson于20世纪6070年代在爱立信公司开发AKE、AXE系列系统时所提出。85年博士论文与92年出版的用例驱动方法中详细论述Use Case被认为是第二代面向对象技术的标志。,Use Case 定义,定义1：用例是对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列。定义2：用例是系统、子系统或类和外部的参与者（actor）交互的动作序列的
2、说明，包括可选的动作序列和会出现异常的动作序列。,Ivar Jacobson：用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。,用例实例的定义,步骤,目标,路径,通俗一些执行者通过系统达到某个目标,Use Case 特点,用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。它有如下一些特点：用例描述了用户提出的一些可见的需求；用例可大可小；用例对应一个具体的用户目标,Use Case 对开发的意义,软件开发过程以用例驱动。,位于系统边界以外的一个实体，透过系统边界与系统进行有意义交互。参与者未必是人，可以是一个外部系统。在处理参与
3、者时，应考虑其参与系统的身份，而不是人名或工作名。,参与者（Actor）,参与者识别思路,谁使用该系统谁改变系统的数据谁从系统获取信息谁需要系统的支持以完成日常工作任务谁负责维护、管理并保持系统正常运行系统需要应付那些硬件设备系统需要和那些外部系统交互谁对系统运行产生的结果感兴趣,案例：库存管理系统,某汽车制造厂需要一套库存管理系统，该系统实现的业务：生产工人根据生产计划领取物料，库存操作员根据生产系统的派单准备，交付给领料工人，余料即时归还库房。库房管理人员定期盘点库存，通知供应商供货，对长期积存的货物，申请退货。,识别思路：,谁使用该系统谁改变系统的数据 谁从系统获取信息 谁需要系统的支持
4、以完成日常工作任务 谁负责维护、管理并保持系统正常运行系统需要应付哪些硬件设备系统需要和哪些外部系统交互 谁对系统运行产生的结果感兴趣,操作员，管理员,领料员,退料员,操作员,管理员,供应商,管理员,生产系统, 供应商系统,操作员,管理员,领料员,退料员,操作员，管理员,操作员，管理员,库存管理系统的参与者,2、用例（Use Case）,用例描述了系统的功能需求，是系统的一组动作序列的描述.用例的本质是用户与计算机之间的一次交互作用。,识别用例的策略 （1）参与者希望系统提供什么功能？（2）系统是否存储和检索信息？如果是，这个行为由哪个参与者触发?（3）当系统改变状态时，通知参与者吗？（4）存
5、在影响系统的外部事件吗？（5）是哪个参与者通知系统这些事件？,识别用例,执行者使用这个系统达到什么目标？,语法测试：【执行者】使用系统来【用例】,识别用例,用例要点,价值结果有意义的目标系统执行价值结果由系统生成执行者可见业务语言，用户观点一组用例实例用例的粒度,识别用例,有意义的目标,识别用例,业务语言而非技术语言,识别用例,用户观点而非系统观点,用户观点,系统观点,识别用例,用例命名：执行者视角,动词（宾语）,慎用弱动词，弱名词弱动词：进行，使用，复制，加载，重复弱名词：数据，报表，表格，表单，系统,主要内容,基本概念：Use case、Actor、Scenario Use case间的关
6、系 Use Case 分析技术 案例讲解,关系,参与者与用例之间关联关系用例与用例之间包含关系 (include)扩展关系 (extend)泛化关系 (generalization)参与者与参与者之间泛化关系 (generalization),关系参与者与用例之间,关联关系 描述参与者与使用用例之间的关系。在UML中，关系用实线表示，实线可以有箭头，也可以没有箭头。例：参与者与用例 通过关联相连。,1）包含关系(include) 包含关系中一个用例总是使用另一个用例的功能 包含关系中基用例本身是不完整的。例： 本例中，用例“Check Credit” 检查输入的信用卡号是否有效以及信用卡是否有
7、足够的资金。,用例间的关系包含关系,2）扩展关系(extend)扩展关系允许一个用例（可选）扩展另一个用例的功能。扩展只能发生在基用例的序列中某个特定的点上，这个点叫扩展点。扩展关系中基用例本身是完整的。,用例间的关系扩展关系,用例间的关系扩展关系,包含关系与扩展关系的区别,用例间的关系泛化关系,3）泛化关系（也称类属或概括关系） 泛化关系其实是子类与父类的关系。象类之间的泛化关系一样，用例和参与者也可以继承另一个用例和参与者。,关系参与者与参与者之间,泛化关系,主要内容,基本概念：Use case、Actor、Scenario Use case间的关系 Use Case 分析技术 案例讲解,
8、用例的描述,没有描述的Use Case就像是一本书的目录从用例的定义也可以看出，用例是一个“文字描述序列”，是“动作序列的说明” 。用例的描述是用例的主要部分，是后续的交互图分析和类图分析必不可少的部分。,用例的描述,一般说来，用例采用自然语言描述参与者与系统进行交互时双方的行为，不追求形式化的语言表达（面向不同人员）。,用例描述的内容,用例的目标用例是怎么启动的参与者和用例之间的消息是如何传送的用例中除了主路径外，其他路径是什么用例结束后的系统方法其他需要描述的内容,原则：尽可能写的“充分”，而不是追求写的形式化、漂亮。,书写用例文档,路径交互步骤的描述,只书写“可观测”的（说人话）使用主动
9、语句句子必须以执行者或系统作为主语每一句都要朝目标迈进分支和循环不要涉及界面细节,书写用例文档,路径交互步骤的描述(1),系统通过ADO建立数据库连接，传送SQL查询语句，从“零件”表查询,系统按照查询条件搜索零件,只书写“可观测”的（技术术语）,书写用例文档,路径交互步骤的描述(2),欧文从贝克汉姆处得到传球，守门员,贝克汉姆传球给欧文，欧文射门，守门员扑救.,主动语句球在谁那里？,书写用例文档,路径交互步骤的描述(3),系统从会员处获取用户名和密码,会员提交用户名和密码,使用主动语句,用户名和密码被验证,系统验证用户名和密码,书写用例文档,路径交互步骤的描述(4),执行者系统系统执行者,句
10、子必须以执行者或系统作为主语,书写用例文档,路径交互步骤的描述(5),执行者填写姓名执行者填写电话执行者填写联系地址执行者提交,每一句话都要朝目标迈进,书写用例文档,路径交互步骤的描述(6),分支：放到扩展路径循环：直接描述,分支和循环,书写用例文档,路径交互步骤的描述(7),会员从下拉框中选择类别会员在相应文本框中输入查询条件会员点击“确定”按钮,不要涉及到界面细节,书写用例文档,扩展,书写用例文档,识别扩展点的思路,执行者的选择系统验证步骤失败,注意：必须是系统能够感知的,常见错误,只描述系统的行为，没有描述参与者的行为只描述参与者的行为，没有描述系统的行为在用例描述中就设定对用户界面设计
11、的详细要求描述过于冗长,Use Case：取款Actor：储户主事件流：1、储户插入ATM卡，并键入密码；2、储户按“取款”按钮，并键入取款数目；3、储户取走现金、ATM卡并拿走收据；4、储户离开。,问题：只描述了参与者的动作序列，而没有描述系统的行为,ATM取款案例,ATM取款案例,Use Case：取款Actor：储户主事件流：1、ATM系统获得ATM卡和密码；2、设置事物类型为取款；3、ATM系统获取要提取的现金数目；4、验证帐户上是否有足够储蓄金额；5、输出现金、数据和ATM卡；6、系统复位。,问题：只描述了ATM系统的行为，而没有描述参与者的行为,ATM取款（修改后的描述）,Use
12、Case：取款Actor：储户主事件流：1、通过读卡机，储户插入ATM卡；2、ATM系统从卡上读取银行ID、帐号、加密密码、并用主银行系统验证银行ID和帐号；3、储户按“取款”按钮，ATM系统根据上面读出的卡上加密密码，对密码进行验证；4、储户按“快速取款”按钮，并键入取款数量，取款数量应该是100的倍数；5、ATM系统通知主银行系统，传递储户帐号和取款数量，并接收返回的确认信息和储户帐户余额；6、ATM系统输出现金、ATM卡和显示帐户余额的收据；7、ATM系统记录事务到日志文件；,用例描述分析,Use Case: Buy Something参与者：Customer主事件流：1、系统显示ID和
13、密码窗口；2、顾客键入ID和密码，然后按OK键；3、系统验证顾客ID和密码，并显示个人信息窗口；4、顾客键入姓名、街道地址、城市、邮政编码、电话号码，然后按OK键；5、系统验证用户是否为老顾客；6、系统显示可以卖的商品列表；7、顾客在准备购买的商品图片上单击，并在图片旁边输入要购买的数量。选购商品完毕后按Done按钮；8、系统通过库存系统验证要购买的商品是否有足够库存；.（后续描述省略）,问题：对用户界面的描述过于详细，对于需求文档来说，详细的用户描述对获取需求并无帮助。,改进后的描述,Use Case：Buy Something参与者：Customer主事件流：1、顾客使用ID和密码进入系统
14、；2、系统验证顾客身份；3、顾客提供姓名、地址、电话号码；4、系统验证顾客是否为老顾客；5、顾客选择要购买的商品和数量；6、系统通过库存系统验证要购买的商品是否有足够库存.（后续描述省略）,主要内容,基本概念：Use case、Actor、Scenario Use case间的关系 Use Case 分析技术 案例讲解,案例1：ATM系统,建立一个具有基本功能的ATM机软件,客户可以存钱，取钱,客户可以查询帐户余额,客户可以修改密码,客户可以进行转帐,需求建模用例图,需求分析的第一步是确定系统能够做什么？谁来使用这个系统？ 用例图显示用例（表示系统功能）与角色（表示提供或者接收系统信息的人或系
15、统）之间的交互。用户，项目管理员，分析人员，开发人员，质保人员都可以通过用例图了解系统功能。,需求建模用例图,建立用例图分为以下几个步骤：确定角色（Actors）创建用例（Use Case） 创建角色（Use Cases）用例（Use Case）关系图,角色,系统用户 与本系统交互的其他系统 时间,确定角色(Actor),用例,描述一个系统（或一个子系统）做什么，而不是说明怎么做.,创建用例（Use Case） 用例是角色启动的，基于这样的考虑，ATM系统根据业务流程大致可以分为以下的几个用例：客户取钱客户存钱客户查询余额客户转帐客户更改密码,建立用例图,建立事件流（用例描述）,事件流的目的是
16、建档使用案例中的逻辑流程，详细描述系统的工作。,用例“取钱”的事件流 （1）,简要说明：客户可以从ATM机上取出自己帐目上的部分或者全部存款。 前提条件：无 主事件流：,客户将卡插入ATM机，开始用例。ATM显示欢迎消息并提示客户输入密码。客户输入密码。ATM确认密码有效。如果无效则执行其他事件流A1。如果与主机联接有问题，则执行异常事件流E1。ATM提供以下选项：存钱，取钱，查询 。用户选择取钱选项。 ATM提示输入所取金额。用户输入所取金额。 ATM确定该帐户是否有足够的金额。如果余额不够，则执行A2，如果与主机联接有问题，则执行异常事件流E1。 ATM从客户帐户中减去所取金额。 ATM向
17、客户提供要取的钱。 ATM打印清单。 ATM退出客户的卡，用例结束。,其他事件流A1：输入无效密码 ATM告诉客户该密码错误。 ATM退出客户的卡，用例结束。其他事件流A2：余额不足ATM告诉客户该帐户余额不足。ATM退出客户的卡，用例结束。 异常事件流E1：联接主机出现错误ATM告诉客户联接主机出现错误。ATM在错误日志记下错误。ATM退出客户的卡，用例结束。 事后条件：无,案例2:图书管理系统,1. 这是一个图书馆支持系统；2. 图书馆将图书和杂志借给借书者。借书者已经预先注册，图书和杂志也预先注册；3. 图书馆负责新书的购买。每一本图书都购进多本书，当旧书超期或破旧时可从图书馆中清除掉。
18、4. 图书管理员是图书馆的员工。他们的工作就是和读者打交道并在软件系统的支持下工作。5. 借阅人可以预定当前没有的图书和杂志。这样，当他所预定的图书和杂志归还回来或购进时，就通知预定人。当预定了某书的借书者借阅了该书后，预定就取消。或者通过显式的取消过程强行取消预定。6. 图书馆能够容易地建立、修改和删除标题、借书者、借阅信息和预定信息。,The top 10 Use-case pitfalls,1. The system boundary is undefined or inconstant.2. The use cases are written from systems (not the
19、 actors) point of view.3. The actors name is inconsistent.4. There are too many use case.5. The actor-to-use case relationships resemble a spiders web.6. The use-case specifications are too long.7. The use-case specifications are confusing.8. The use-case doesnt correctly describe functional entitle
20、ment.9. The customer doesnt understand the use cases.10. The use case is never finished.,常见问题讨论,用例粒度问题 一个大概10人年的项目： Ivar Jacobson用大约20个用例 Martin Fowler则用约100多个用例 目前仍是很多人争论的问题，粒度大则用例数少，粒度小则用例数多，用例粒度无绝对标准。,常见问题讨论,三层结构如何采用用例表示？ 初学者容易在用例分析时马上深入考虑实现的问题。 用例是用来描述系统需求的，一般不在用例分析阶段考虑系统的实现问题，如果需要描述系统的三层结构，则在类图、部署图中表示。,
