依赖关系-火龙果软件.PPTVIP

识别参与者须注意的问题： 尽管参与者在用例图中是用类似人的图形来表示，但参与者并不一定必须是人。 参与者代表角色。 一个实体可以扮演多种角色（参与者），在确定实体的参与者身份时，应考虑其所扮演的角色，而不是实体的头衔或名称。 角色不是对职位建模。 用例图的构成 用例 用例描述了系统所执行的一组动作序列，系统执行该动作序列来为参与者产生一个可供观察的结果。 用例的UML符号表示是椭圆，并可在符号下标出用例名。 在实践中，用例的名字通常是用动词词组命名从问题域中发现的一些行为。 用例表示了系统的功能，也就是系统提供给参与者的功能。系统的用例构成了系统的所有使用功能。 用例图的构成 用例图的构成 构造一个好的用例应该遵循的原则： 一个用例应该描述一个从头至尾的完整的功能，用例要与参与者交互。 用例的获取是需求分析时首先要做的工作，大部分用例将在需求分析时产生，并且随着工作深入会发现更多的用例，这些都应及时添加到已有的用例集中。用例集中的每个用例都是一个潜在的需求。 参与者的识别对识别用例很有用。面对一个大系统，可先列出参与者清单，再对每个参与者列出它的用例，问题就会容易很多。 在识别出了参与者后，可以通过一些问题的答案来帮助发现系统的用例。 用例图的构成 对于每个用例，都可以用事件流来规定用例的行为。用例的事件流是对完成用例规定行为所需要的事件的描述。 在描述用例的事件流时，既可以用非正式的结构化文本，也可以用正式的结构化文本，还可以用伪代码。在创建事件流文档时，每个项目都应使用一个标准模板，模板内容如下所示： X “用例名” X.1 简单描述 X.2 前置条件 X.3 后置条件 X.4 事件流 X.4.1 基流 X.4.2 分支流（可选） X.4.3 替代流 用例间的关系 类属关系(Generalization) 用例间的类属关系如同类间的类属关系。也就是说，子用例继承父用例的行为和含义，子用例可添加新行为或覆盖父用例的行为。 包含关系(Include) 多个用例可能具有一些相同的功能，共享的功能通常被放在一个单独的用例中，可在该用例和其他需要使用其功能的用例之间创建Include关系。 使用Include关系可以避免重复描述同样的事件流，因为公共的行为被放入一个专门的用例中，这个专门的用例是被基用例包含的。 用例图的构成 扩充关系(Extend) 扩充关系用来说明可选的、只在特定条件下运行的行为，具有扩充关系的用例基于参与者的选择，可以运行几个不同的流。 用例间的扩充关系表示基用例在指定的扩充点隐式地含有另一个用例的行为。基用例可以独立存在，但在特定条件下，它的行为会被另一个用例的行为扩充。基用例只在被称为扩充点的特定点被扩充。可以认为，扩充用例将行为推进基用例。 包含关系（抽取公共行为）和扩充关系（识别变种）对于创建简单、易于理解的系统用例集是非常重要的。 用例图的构成 2.3.3 用例图的应用 为系统的上下文建模 为系统的上下文建模，涉及到围绕整个系统划一条线，并确保位于系统外的参与者与系统相互作用。这个上下文定义了系统存在的环境。在建立用例图时，首先要确定围绕系统的参与者，确定参与者很重要，因为这样就确定了与系统交互作用的一类事物。 对系统的需求建模 需求规定了用户期望系统做什么。需求的表达可以有很多方式，例如：事件流描述、活动图。系统的全部或大部分功能需求可以表达为用例。UML的用例图对于管理这些需求是很重要的。为系统的需求建模涉及到规定系统应该做什么，不需要知道系统应该怎样实现这些行为，即用例图用来规定系统的行为。 2.4 类图和对象图 类的相关概念 类图 对象图 2.4.1 类的相关概念 类是一组具有相同属性、操作、关系和语义的对象的描述，是现实世界中的事物的抽象，当这些事物存在于真实世界中时，它们是类的实例，被称为对象。 类的UML符号表示是划分为3个格子的长方形，顶部的格子放类名，中间格子放类的属性、属性的类型和值，下面的格子放操作、操作的参数表和返回类型。 有实例的建模元素称为类元，它具有结构特征(属性)和行为特征(操作)。包括类、接口、数据类型、信号、构件、节点、用例和子系统。 类的名称 每个类都有一个名字，与其他类相区别。 在实践中，类名通常用问题域中的短名词或名词词组来表示。通常将类名中的每个组成词的第一个字母大写，如Student、HelloWorld等。 类的命名应尽量用问题域中的术语，应明确、无歧义，以利于开发人员与用户之间的相互理解与交流。 类的属性 属性描述了类的所有对象所共有的特性。一个类可以有