《用例分析与用例图.ppt》由会员分享，可在线阅读，更多相关《用例分析与用例图.ppt（55页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、用例分析 与用例图,回顾,需求工程的六个阶段 需求获取、需求分析与协商、系统建模、需求规约、需求确认、需求管理 需求分析的概念 需求的类型与怎样获取需求 需求分析过程 需求规格说明书（SRS）,主要内容,基于用例的分析与设计 业务用例与系统用例 用例与用例关系 小结与实验,前言之一,软件开发过程中常见的场景,你这做的是什么东西！,这个做还不错，不过好像不是我想要的。,我们这很混乱，你这个系统应该把我们的所有问题全部解决掉！,“弱弱”地问：“您到底想要什么？”,前言之二,需求分析与管理软件开发过程中的“永远的痛”,基于用例的分析与设计,以用例为中心组织需求,基于UML的分析与设计,使用UML过程
2、的基本特征是：用例驱动，以体系结构为中心，反复，渐增式。 用例包含了功能描述，它们将影响后面所有阶段及视图。,结构模型视图,业务用例与系统用例,业务用例： 业务过程是描述这个业务的具体工作流的 一次涉众与实现业务目标的业务之间的交互 它可能包含手工和自动化的过程 也可能发生在一个长期的时间段中 系统用例 涉及范围是这个计算机系统涉及的范围 是一个系统参与者与计算机系统一起实现一个目标 是参与者如何与计算机技术相联系，而不是业务过程。,业务用例与系统用例,业务级（概要级）,系统级,华软校园ATM机系统用例模型,华软特有的业务,用例与用例关系,用例图 参与者 用例 用例关系,用例图,获取需求、指导
3、测试、对过程中的其他工作流起指导作用,系统内部,系统外部,整车销售,参与者,参与者，Actor 关键词：边界 参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物,边界-Boundary,也叫系统边界，用于界定系统功能范围 用一个带名称的矩形框，把描述系统功能的用例都置于其中，而描述的与系统交互的角色都置于其外 系统-完整系统或子系统 一个系统包括一个或多个用例 准确的定义系统的边界（功能）不是一件很容易的事 先识别出系统的基本功能集，以此为基础定义一个稳定的、精确定义的系统体系结构，再不断地扩充系统功能，以逐步完善,识别参与者,要点 系统外 参与者代表在系统边界之外的真实事物，并不
4、是系统的成分 系统边界 参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定 有意义交互的任何事物 人、外部系统、外部因素、时间,识别参与者思路,谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 谁使用或删除系统中的信息 谁（或什么）对系统运行产生的结果（值）感兴趣 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 在预定时间，是否有事件自动发生 时间、气温等内部外部条件 ,参与者的类型和职责,主要参与者 直接与系统交互的人，或执行系统主要功能的执行者 次要参与者 使用系统次要功能的执行者
5、，或维护系统一般功能的执行者 外部硬件 作为系统一部分的、运行应用的非计算机的硬件 其他系统 为其工作需要与系统交互的外部系统,参与者之间的关系,独立关系 泛化关系 一个参与者的抽象描述可以被一个或多个具体的参与者所共享,客户,个体客户,商业客户,用例,定义：Use Case 用例表示系统的一项外部功能，它从用户的角度分析所得的需求。为完成一个相对完整的一种功能，系统执行的一系列动作的集合,是外部可见的一种系统功能 代表的是一个完整的功能 有一系列动作,用例,用例1,用例捕获某些角色可见的需求，实现一个具体的角色需求 用例由其用户角色使用，并提供确切的输出给角色 用例可大可小，但它必须是对一个
6、具体的角色目标实现的完整描述 用例的动态执行过程可以用U M L的交互作用来说明，可以用状态图、顺序图、协作图、活动图或非正式的文字描述来表示,用例的命名,执行者视角： （状语）动词+（定语+ ）宾语,识别用例,识别用例 关键词：价值 定义 用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值 一个用例定义一组用例实例（场景） 场景-用例的实例 简洁：参与者使用系统达到目标,识别用例要点,可观测用例止于系统边界 结果值用例是有意义的目标 系统执行结果值由系统生成 由参与者观测业务语言、用户观点 一组用例实例用例的粒度,可观测：用例止于系统边界,描述交互，而不是内在的系统活动,
7、结果值：有意义的目标,业务功能，而非系统处理,系统执行：结果值由系统生成,系统需要处理的，由系统生成,参与者观测：用户观点而非系统观点,用户观点,系统观点,用例粒度,用例要有路径，路径要有步骤；而这一切都是可观测的 最常犯错误：粒度过细，陷入功能分解 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言,用例粒度-1,把步骤当用例 把系统活动当用例,用例粒度-2,“四轮马车” C(Create) R(Read) U(Update) D(Delete) 所有业务最终会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心
8、数据的存储和维护，反而忽略了用户的目的,用例粒度-3,用例粒度-4,如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示,用例粒度-5,灵活处理CRUD,可以把包含复杂交互的路径独立出去形成用例,用例关系,Include 提取公共步骤，便于复用 Extend 分离扩展路径 Generalization 同一业务目的的不同技术实现,包含关系,包含关系1,包含关系2,某些步骤在多个用例重复出现，且单独形成价值 用例步骤较多时，可用Include简化 当完全知道什么时间要调用用例时，基用
9、例需要包含用例所封装的逻辑 可以简单认为源代码中的函数调用或操作调用,包含举例2,包含关系,扩展关系,扩展关系1,扩展关系2,将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点 扩展用例的行为是否被执行要取决于主事件流中的判定点。,基用例路径本身是完整的 可能是一条扩展路径 扩展路径步骤多 扩展路径内部还可以有扩展点扩展之扩展 扩展路径未定或容易变化分离以“冻结”基用例 基础用例可以单独存在，但在一定条件下，他的行为可以被另一个用例作为扩展,扩展关系3,扩展举例,泛化关系,同一业务目的不同技术实现： 一个用例可以泛化为另一
10、个更普通用例（更普通用例特化为特殊用例） UML 1.5: 用例间的泛化关系表明子用例包含父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系,泛化,一个售货员可以终止任何交易，除了那些需要特殊的售货员（高级代理）终止的超过了一定限制的交易,识别用例-登录怎么处理？,识别用例-几个登录？,或,用例之间的关系,小结,理解需求 以用例为中心组织需求 基于用例的需求分析过程 获取原始需求 开发一个可以理解的需求 识别参与者 识别用例 确定关系,思考,基于用例的需求分析过程可大致分几步？ 什么是系统边界 用例的概念 用例的关系 参与者的定义与关系,实验06,画出系统用例图 注意用例的粒度与关系 描述一个用例的活动图,谢谢,