用例模型和用例.ppt

刘超 北京航空航天大学软件工程研究所,第一讲 用例模型和用例图,用例模型概述；用例图；建立用例模型的主要工作；用例模型(用例图)的建造；小 结。,刘超 北京航空航天大学软件工程研究所,I 用例模型概述,什么是用例？用例模型的意义；用例分析的目的；用例的属性；对用例图关心的人员。,刘超 北京航空航天大学软件工程研究所,什么是用例？,确定需求：软件开发中的一个致命的问题为此，各有关方面需要大量的交流，以增进对需求的了解。然而，对各方所关心的事情的描述却都是粗糙的（非形式化）、口头的或是一些杂乱的草稿，没有文档怎样描述用户所关心的事情？用例是对（用户）所关心的事情的描述。,刘超 北京航空航天大学软件工程研究所,场景Scenario,场景：用户与系统之间的一个交互过程，即为实现这次交互所要经历的一系列步骤例：假设有一个基于Web的在线购物站点，我们可以给出这样一个购物场景：主场景：顾客浏览了货单并将感兴趣的物品添加的购物筐中。如决定购买，则说明要购买的物品，提供信用卡信息并确认购物清单。系统将检查信用卡的合法性并确认销售结果。给客户发出确认电子邮件备选场景；信用卡失效,刘超 北京航空航天大学软件工程研究所,用例Use Cases,用例：一组场景，用以共同描述用户的某个特定的目标。例：用例：购买商品,刘超 北京航空航天大学软件工程研究所,用例：购买商品,主场景：顾客浏览货单并选择要买的商品顾客来付款顾客填写采购信息（地址、隔天或3天送货）系统显示价目信息顾客填写信用卡信息系统检查信用卡的合法性系统确认销售系统给客户发出确认电子邮件,刘超 北京航空航天大学软件工程研究所,候选场景,候选场景：信用卡失效第6步，系统检查信用卡失败。允许客户重新执行第5步候选场景：固定客户3a.系统显示当前购物信息、价格信息、信用卡的最后四位数字3b.顾客接受或修改这些隐含值。转至主场景的第6步,刘超 北京航空航天大学软件工程研究所,用例模型的意义,用例模型对软件开发方法的研究具有重要意义：任何方法的首要问题是了解需求，而分析典型用例是用户和开发者一起了解需求、剖析需求和跟踪需求的有效工具。Jacobson首先提出用例分析方法，对用例的使用进行了扩展，将其作用提高到项目设计和项目开发基本要素的高度，是面向对象技术进入第二代的标志。,刘超 北京航空航天大学软件工程研究所,用例分析的目的,描述和决定系统的功能需求，帮助客户和软件开发人员形成一致意见。给出系统应该做什么且与内容一致的可视化描 述，使之成为在开发全过程中研讨系统需求和进行系统设计的依据。在软件测试阶段作为系统测试的基础。建立系统实现的各个对象类和系统操作与功能需求之间的可追踪关系。,刘超 北京航空航天大学软件工程研究所,用例的一些基本特点,用例描述了用户提出的一些可见需求；用例可大可小例：10人年的项目，20-100个用例用例对应一个具体的用户目标,从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互。以字处理程序为例，“将某些正文置为黑体”和“创建一个索引”便是两个典型的用例。从这两个例子中可以了解用例的一些特点：,刘超 北京航空航天大学软件工程研究所,对用例模型关心的人员,客户：他关心如何使用系统的功能；充当模型中的哪一个角色；如何调整模型可以更好地适应他们的愿望。开发人员：他需要理解系统的功能，以作为今后工作的基础和依据；在系统集成测试期间，可以使用这些用例测试系统。其他人员：销售人员，技术支持人员，文档编写人员等也关心用例图。,刘超 北京航空航天大学软件工程研究所,II 用例图,用例图举例；用例图中的图符；用例图中的模型元素。,刘超 北京航空航天大学软件工程研究所,用例图举例（UML1.1）,刘超 北京航空航天大学软件工程研究所,用例图举例（UML1.3）,刘超 北京航空航天大学软件工程研究所,用例图中的图符（UML1.3）,刘超 北京航空航天大学软件工程研究所,包含关系与泛化关系,包含关系：描述在多个用例中都有的公共行为泛化关系：一个用例类似与另一个用例，但多一些内容。,刘超 北京航空航天大学软件工程研究所,扩展关系,类似与泛化关系，但添加了一些新规则扩展用例可以在基用例之上添加新的行为，但是基用例必须生命某些特定的“扩展点”，并且扩展用例只能在这些扩展点上扩展新的行为。,固定顾客,购买商品,扩展点：付款信息 购物信息,扩展,刘超 北京航空航天大学软件工程研究所,用例图中的模型元素系统、执行者和用例,系统：一个提供“用例”所需要的功能的“黑盒 子”。系统的外部特性由系统的功能来定义；整个系统的功能用一组用例来描述。执行者：需要使用系统的任何外部实体(例如 人、其它系统或外部设备等)。用例：用客户或用户的语言和词汇来描述的系统的一个完整功能。,刘超 北京航空航天大学软件工程研究所,用例图中的模型元素(续1)关联、使用和 扩展,关联：连接执行者和用例，表示该执行者所代表的系统外部实体与该用例所描述的系统需求有 关。这是执行者和用例之间的唯一合法连接。包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能。扩展：由用例 A连向用例 B，表示用例B描述了一项基本需求，而用例A则描述了该基本需求的特殊情况，即一种扩展。,刘超 北京航空航天大学软件工程研究所,用例图中的模型元素(续2)执行者的泛化,当几种执行者所扮演的角色可以被泛化时，可以定义一个更抽象的角色。,刘超 北京航空航天大学软件工程研究所,用例图中的模型元素(续3)注释体和注释连接,文档属性：必要时，要对用例图中的各个成分进行文字说明，称之为用例图的文档属性。文档属性用注释体和注释连接表达，其中：,注释体用于对UML实体进行文字描述。注释连接将注释体与要描述的实体相连，说明该注释体是针对该实体所进行的描述。,刘超 北京航空航天大学软件工程研究所,III 建立用例模型的主要工作,定义系统；找出执行者；找出用例；描述用例；用例的整理与加工；验证模型。,刘超 北京航空航天大学软件工程研究所,III.1 定义系统,系统的属性；定义系统时的注意点；对与外界系统交互问题的看法。,刘超 北京航空航天大学软件工程研究所,系统的属性,系统名：软件系统、业务流程或硬件系统等都 是系统，它应该有一个名字。用字符串表达系统 名。系统边界：定义系统的边界，即确定系统的内 容：哪些任务由系统完成，哪些由人工完成，哪些由其他系统完成；系统多大，有哪些功能，系统的复杂程度如何；等等。系统定义应当：基本功能明确；系统构架优良(便于增加或修改系统的功能)。,刘超 北京航空航天大学软件工程研究所,定义系统时的注意点,定义系统是用准确的语言对问题进行描述，其要点如下：汇集最重要的概念(实体)；使用客户熟悉的术语、词汇和定义；对系统或业务模型中的词汇给出准确说明(用于描述用例)。系统定义的详略程度：简单系统，半页纸左右；复杂系统，需要一系列文档。,刘超 北京航空航天大学软件工程研究所,对与外界系统交互问题的看法,与外界系统的所有交互都应在图中表达。例如，为了给一笔交易进行估价需要访问路透社，则应在用例“交易估 价”与“路透社”之间建立连接关系。只有当某个外界系统会引发信息交互时，才在系统中建立相应的外界系统。此时除非记帐系统会通过某种方式要求本系统做某件事时，才在图中显示记帐系统。应该显示那些需要用到系统中某个功能的执行者。因此，如果系统每天晚上生成一个文件，该文件随后被记帐系统获取，则该记帐系统应该是一个相关的执行者。我们赞成这种观点。把一个系统看成执行者是错误的，因为执行者仅仅是一个想从系统中获取某种信息的用户。在本示例中，执行者应是公司的内部审计师，而记帐系统只是他使用的工具。,刘超 北京航空航天大学软件工程研究所,III.2 找出执行者,执行者的主要属性；执行者与系统和用例之间的关系；执行者的获取；对执行者的描述。,刘超 北京航空航天大学软件工程研究所,执行者的主要属性,执行者是与系统有交互作用的实体(人或其它系统等)，它在执行用例时与系统之间有信息的交流。执行者的重要性可以分级：主要角色(执行主要功能，如负责保险注册和管理的职员)和次要角色(执行次要功能，如负责系统维护、数据库管理、复制备份和其它系统管理等工作的职员)。执行者有主动和被动之分：主动执行者创建用例；被动执行者不创建用例。一个执行者代表一个角色，执行一个类；因此一个执行者的名字不应使用该执行者的某个具体实例的名字。一个人在系统中的角色可以被限定为一个角色；但也可以担任不同的角色，充当不同类的执行者。,刘超 北京航空航天大学软件工程研究所,执行者与系统和用例之间的关系,执行者与系统之间的交流是通过收发消息。一个简单用例总是由一个执行者通过发消息的方法(刺激)创建；一个复合用例总是由一个或若干个执行者通过发消息的方法(刺激)创建。当执行一个(简单的或复合的)用例时，它会发一些消息给一个或多个执行者。,刘超 北京航空航天大学软件工程研究所,执行者的获取,谁使用系统的主要功能(主要使用者)？谁需要系统支持他们的日常工作？谁来维护、管理系统使其能正常工作(辅助使用者)？系统需要控制哪些硬件？系统需要与其他哪些系统交互？对系统产生的结果感兴趣的是哪些人或哪些事物？,执行者主要是业务的客户，而不是操作员。通过用户回答问题可以帮助我们识别执行者。以下问题可供参考：,刘超 北京航空航天大学软件工程研究所,对执行者的描述,执行者是类，因而可用执行者的类名及其属性和行为来描述。有必要时增加注解，对使用者情况和要求等加以说明。执行者之间的关系与其他类之间的关系相同。在用例图中，只有泛化关系用来描述某些执行者之间的公共行为。,刘超 北京航空航天大学软件工程研究所,IV 用例模型(用例图)的建造,用例间关系的示意图；包含关系的定义；扩展关系的定义；包含与扩展关系的选择；用例的获取。,刘超 北京航空航天大学软件工程研究所,用例间关系的示意图（UML1.1),刘超 北京航空航天大学软件工程研究所,包含关系的定义,包含关系是一种(因子化)重组关系。当几个用例具有共同的行为时，这个共同行为可以抽象为一个公共用例。一个特殊用例包含一个公共用例作为其一部分 时，将完全包含那个公共用例的行为，即整个公共用例被使用。包含的可视化表示：由用例A连向用例B，表示用例A中包含了用例B中的行为或功能。,刘超 北京航空航天大学软件工程研究所,扩展关系的定义,扩展与包含相似，从几个用例中抽取公共行为并放入一个单独用例中作为基本用例，然后增加新的特殊情况作为其基本用例的扩展。在扩展情况下，一个给定的执行者将执行基本用例及其所有的扩展。对于包含关系，通常执行者不会和公共用例相关联。扩展的可视化表示：由用例A连向用例B,表示用例B描述了一项基本需求，而用例A则描述了该基本需求的特殊情况，即一种扩展。,刘超 北京航空航天大学软件工程研究所,包含与扩展关系的选择,下列规则可用来判断应采用包含关系或扩展关系：,包含：当一个通用的用例可以成为几个特殊的用例的组成部分时用包含关系。因此，当在两个或更多的用例中出现重复描述而又想避免这种重复时，采用包含关系。扩展：当一个用例是另一个一般化用例的特例 时，用扩展关系。因此，当描述一般行为的变化时，采用扩展关系。要说明扩展点,刘超 北京航空航天大学软件工程研究所,UML1.3的修改,用例之间的泛化关系一般泛化关系包含关系include：原来的use关系扩展关系extend:must declare certain“extension points”,刘超 北京航空航天大学软件工程研究所,用例的获取,首先获取简单的、常规的用例作为基本用例(在上例中，基本用例是进行交易)。当一个用例与另一个用例相似，但比另一个用例做的动作要多，采用扩展关系：对用例中的每一步，问一下“这儿可能出现什么异常情况”以及“是否需要采取不同的解决方法”；将所有出现变动的部分列出，作为给定用例的扩展。一旦获取了系统的执行者，就可对每个执行者提出一些问题，然后从执行者对这些问题的答案中获取用例。,刘超 北京航空航天大学软件工程研究所,用例的获取(续2),为了完整地描述用例，还需要知道执行者的某些典型功能能否被系统自动实现。针对整个系统的问题的答案也可帮助我们获取用 例。以下问题可供参考：在开发系统的用例图时，不同的设计者选取用例的数目也不相同。,系统需要何种输入输出？输入从何处来？输出到何处去？当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题是什么？,刘超 北京航空航天大学软件工程研究所,V 小 结,用例是由执行者创建、依据执行者的意图执行的。执行者直接或间接地命令该系统执行他所期望的用例。一个用例必须至少与一个执行者相连。一个用例必须是完整的：应有一个完整的描述；常见的错误是把用例分得太小。用例要向执行者提供执行结果。如果它不能产生最终结果，这个用例就不是完整的。活动图可以用来产生用例图。一个完整的活动图可以用来产生该用例图的全集。,刘超 北京航空航天大学软件工程研究所,思考题,贵公司的一个典型产品的需求描述产品名称：需求描述：,