识别用例和用例图.ppt

第4章 用例和用例图 一个系统的初始阶段是从获得需求开始的。一旦需求确定了，就可以在问题说明中确定用例。 本章说明了如何从问题说明中提取用例以及如何建立用例图模型。 用例：基于用户目标的需求组织形式 立足开发者视角（银行取款） 系统要求用户输入合法的密码 系统能够接受用户录入的取款金额 系统能够从帐户中扣除取款金额 系统允许选择“打印数据” 或者 “不打印数据” 系统能够显示交易结束信息 4.1 识别用例图 用例图最重要的作用是使最终用户和开发者之间进行交流。 在开发的初始阶段，通过确定系统的参与者和主要用例来建立用例图。在细化阶段，把更多的详细信息加入到已确定的用例中，用例模型将越来越成熟。 4.1 识别用例图 建立一个系统的用例图通常是开发过程中一个困难的部分。 建立一个用例图包括以下步骤： 定义系统。 确定参与者和用例。 描述用例。 定义用例和参与者之间的关系。 定义用例之间的关系。 4.1 识别用例图 客户和开发者通过用例图达成共识，用例图包括以下几个内容： 谁将与系统交互。（参与者） 系统将做什么。（用例） 需要什么接口。（关系） 4.2 用例图组件 一、参与者(Actor) ： ?参与者代表的是与系统交互的任何人或任何事物。参与者是外部的，不是系统的组成部分，但如果要使用或支持参与者，则需要一个接口。 An Actor defines a coherent set of roles that users of use cases play when interacting with use cases. An actor has one role for each use case with which it communicates. 4.2 用例图组件 一、参与者： ?参与者用于表示使用系统的对象，参与者可以是一个人或者一个系统。参与者由一个固定的图形表示，并在图形下面列出参与者的名字。 4.2 用例图组件 ? 每个参与者的名称要反映参与者的角色，而不是它的功能或它的实例，所以给参与者提供一个最能描述其功能的合适名称是非常重要的。并且我们要避免为代表人的参与者起一个实际人名。如：参与者张三是个“教师”，是他所扮演的角色。如果命名为 “张三”就不对了。 4.2 用例图组件 参与者如何确定？可以通过以下一些问题来帮助你确定参与者： 谁使用系统的主要功能? 谁从系统获取信息？ 谁支持和维护系统？ 谁需要系统的支持以履行他们的日常职责？ 在组织里这个系统被用到哪里？ 与系统交互的是哪些硬件设备？ 与这个系统交互的其他系统是哪些？ 4.2 用例图组件 二、用例(Use Case) The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. A use case is a coherent unit of functionality provided by a system, a subsystem, or a class as manifested by sequences of messages exchanged among the system and one or more outside interactors (called actors) together with actions performed by the system. 4.2 用例图组件 用例简介 用例对参与者和系统之间的交互建立模型。它是通过参与者调用功能来启动的，这将会产生一个可视化的结果。一个用例产生的结果必须是一个给系统用户的特定值。 用例的功能和结果必须是一个完整且有意义的事件流。它阐明了系统提供给参与者的功能。 4.2 用例图组件 用例的名称 用例通常具有名称，该名称通常简要地描述了用例的功能。 用例名称通常以一个动词开始，常用动宾结构表示。用例名称显示在用例图标下面或者图标里面。 4.2 用例图组件 用例的大小 对于用例的具体大小没有明确的规定。但一个用例应该包含一项主要功能，这项功能应该是完整的，是有始有终的。如：“转帐”就是一个用例，而“验证密码”一般不看成是一个用例。 4.2 用例图组件 用例的文档化 一旦决定了每个用例将做什么和谁将调用它，就应该写一个简短的文本来描述这一点。这段描述在开发过程的初始阶段完成，它应该以一些句子说明用例的目的，还应该说明用例提供的功能的高层次定义。 4.2 用例图组件 识别用例的方