《UML系统用例》PPT课件.ppt

,CH4 用例图系统用例及用例关系,统一建模语言,11软件工程,知识回顾需求获取,难点,重点,掌握用例图的地位作用及定义,确定用例及用例间的关系,教学目标,教学内容,需求是客户在项目立项时就有的一个远景，客户需求将决定在整个项目中需求承办方具体做些什么，即承办方的任务。承办方在明确了需求后，就会开始后期的设计、开发、测试、部署等工作。,一 需求获取,Click to add title in here,4,在需求获取过程中，主要需要弄清楚三个问题,一 需求获取,明确需要获取的信息,明确所获取信息的来源和渠道,怎样获取需求,What,Where,How,二 用例图相关概念介绍,1.什么是用例图由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。,2.用例图的作用,用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。,参与者，Actor关键词：边界参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物,识别参与者1,要点系统外参与者代表在系统边界之外的真实事物，并不是系统的成分系统边界参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定有意义交互的任何事物人、外系统、外部因素、时间,识别参与者,识别参与者思路,谁使用系统的主要功能谁改变系统的数据谁从系统获取信息谁需要系统的支持以完成日常工作任务谁负责日常维护、管理并保证系统正常运行谁使用或删除系统中的信息谁（或什么）对系统运行产生的结果（值）感兴趣系统需要应付（处理）那些硬设备系统需要和那些外部系统交互在预定时间，是否有事件自动发生时间、气温等内部外部条件,参与者的类型和职责,主要参与者直接与系统交互的人，或执行系统主要功能的执行者次要参与者使用系统次要功能的执行者，或维护系统一般功能的执行者外部硬件作为系统一部分的、运行应用的非计算机的硬件其他系统为其工作需要与系统交互的外部系统,参与者之间的关系,独立关系泛化关系一个参与者的抽象描述可以被一个或多个具体的参与者所共享,客户,个体客户,商业客户,用例1,定义：Use Case用例表示系统的一项外部功能，它从用户的角度分析所得的需求。为完成一个相对完整的一种功能，系统执行的一系列动作的集合,是外部可见的一种系统功能代表的是一个完整的功能有一系列动作,用例,用例2,用例捕获某些角色可见的需求，实现一个具体的角色需求用例由其用户角色使用，并提供确切的输出给角色用例可大可小，但它必须是对一个具体的角色目标实现的完整描述用例的动态执行过程可以用UML的交互作用来说明，可以用状态图、顺序图、协作图或非正式的文字描述来表示,识别用例,识别用例关键词：价值定义用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例（场景）简洁：参与者使用系统达到目标,识别用例要点,可观测用例止于系统边界结果值用例是有意义的目标系统执行结果值由系统生成由参与者观测业务语言、用户观点一组用例实例用例的粒度用例命名,可观测：用例止于系统边界,描述交互，而不是内在的系统活动,边界-Boundary,也叫系统边界，用于界定系统功能范围用一个带名称的矩形框，把描述系统功能的用例都置于其中，而描述的与系统交互的角色都置于其外系统-完整系统或子系统一个系统包括一个或多个用例准确的定义系统的边界（功能）不是一件很容易的事先识别出系统的基本功能集，以此为基础定义一个稳定的、精确定义的系统体系结构，再不断地扩充系统功能，以逐步完善,结果值：有意义的目标,业务功能，而非系统处理,系统执行：结果值由系统生成,系统需要处理的，由系统生成,参与者观测：用户观点而非系统观点,用户观点,系统观点,要点：用例粒度,用例要有路径，路径要有步骤；而这一切都是可观测的最常犯错误：粒度过细，陷入功能分解过细的粒度，一般都会导致技术语言的描述，而不再是业务语言,用例粒度-1,把步骤当用例把系统活动当用例,用例粒度-2,“四轮马车”C(Create)R(Read)U(Update)D(Delete)所有业务最终会成为CRUD？CRUD能为Actor提供价值？CRUD掩盖业务，锐变成关系数据库的建模：“系统就是数据的增删改查”关心数据的存储和维护，反而忽略了用户的目的,用例粒度-3,用例粒度-4,如果确实是CRUD？如果CRUD不涉及复杂的交互，一个用例“管理”即可不管是C、R、U、D，都是为了完成“管理”目标甚至很多种的基本数据管理都可以用一个用例表示,用例粒度-5,灵活处理CRUD,可以把包含复杂交互的路径独立出去形成用例,用例的命名,执行者视角：（状语）动词+（定语+）宾语,用例关系,Include提取公共步骤，便于复用Extend分离扩展路径Generalization同一业务目的的不同技术实现,包含关系1,包含关系2,包含关系,某些步骤在多个用例重复出现，且单独形成价值用例步骤较多时，可用Include简化当完全知道什么时间要调用用例时，基用例需要包含用例所封装的逻辑可以简单认为源代码中的函数调用或操作调用,包含举例1,包含举例2,扩展关系1,扩展关系2,将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点扩展用例的行为是否被执行要取决于主事件流中的判定点。,扩展关系2,基用例路径本身是完整的可能是一条扩展路径扩展路径步骤多扩展路径内部还可以有扩展点扩展之扩展扩展路径未定或容易变化分离以“冻结”基用例基础用例可以单独存在，但在一定条件下，他的行为可以被另一个用例作为扩展,扩展关系,扩展举例,泛化关系,同一业务目的不同技术实现：一个用例可以泛化为另一个更普通用例（更普通用例特化为特殊用例）UML 1.5:用例间的泛化关系表明子用例包含父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系,泛化,一个售货员可以终止任何交易，除了那些需要特殊的售货员（高级代理）终止的超过了一定限制的交易,包含用例与扩展用例的区别,相对于基础用例，扩展用例是可选的，而包含用例则不是。如果缺少扩展用例，基础用例还是完整的，而缺少包含用例，则基础用例就不完整了。扩展用例的执行需要满足某种条件，而包含用例不需要。扩展用例的执行会改变基础用例的行为，而包含用例不会。,用例关系：扩展 VS.泛化,采用不同关系，文档结构不同,小结,理解需求以用例为中心组织需求基于用例的需求分析过程获取原始需求开发一个可以理解的需求识别参与者识别用例确定关系,思考,基于用例的需求分析过程可大致分几步？什么是系统边界用例的概念用例的关系参与者的定义与关系,思考1：识别参与者？,寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑；,在这个叙述里，谁是寻呼台系统的Actor？用户？气温？时间？,思考2：获取需求-考勤卡应用程序,初次访谈记录开发者：谁将使用这个应用程序？客 户：所有用它来记录可记帐以及不可记帐的工时的雇员开发者：现在考勤卡应用程序是什么样的？客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？开发者：谁来管理收费项目代码？客 户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。,思考2：识别参与者：考勤卡系统,开发者：谁将使用这个应用程序？客 户：所有用它来记录可记帐以及不可记帐的工时的雇员开发者：现在考勤卡应用程序是什么样的？客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？开发者：谁来管理收费项目代码？客 户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。,思考2：识别用例：考勤卡系统,开发者：谁将使用这个应用程序？客 户：所有用它来记录可记帐以及不可记帐的工时的雇员开发者：现在考勤卡应用程序是什么样的？客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？开发者：谁来管理收费项目代码？客 户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。,思考2：考勤卡系统,思考3：识别用例,Email客户端（如：outlook express），A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收邮件,用例是一个完整的交互，用例之间没有顺序的关系,思考3：识别用例-正确,下一讲内容,用例规约,