第四章 静态建模：用例和用例图
用例模型是把应满足用户需求的基本功能（集）聚合起来表示的强大工具
用例模型的基本组成部件是用例、角色和系统。用例用于描述系统的功能；角色是与系统进行交互的外部实体，可以是系统用户、也可以是其它系统或硬件设备；系统的边界线以内的区域（即用例的活动区域）则抽象表示系统能够实现的所有基本功能
引入用例的主要目的：
l 确定系统应具备哪些功能，这些功能是否满足系统的需求（开发者与用户协商达成共识的东西）
l 为系统提供清晰一致的描述，以便为后续的开发工作打下良好的交流基础，方便开发人员传递需求的功能
l 为系统的验证工作打下基础，通过验证最终实现的系统能够执行的功能是否与最初需求的功能相一致，保证系统的实用性
l 从需求的功能（用例）出发，提供跟踪进入系统中具体实现的类和方法，检查其是否正确的能力
3.1 用例图
用例图中包含了系统、角色和用例三种模型元素，要画出三种模型，还要画出三种模型之间的各种关系（通用化、关联、依赖）
3.2 系统
系统是用例模型的一个组成部分，代表的是一部机器或一个商务活动等，而不是真正实现的软件系统。系统的边界用来说明构建的用例模型的应用范围
3.3 角色
角色（actor）是与系统交互的人或事。所谓“与系统交互”指的是角色向系统发送消息，从系统中接收消息，或是在系统中交换信息。只要使用用例，与系统相互交流的任何人和事都是角色。
角色分为几个等级：主要角色（primary actor）指的是执行系统主要功能的角色；次要角色（secondary actor）指的是使用系统的次要功能的角色，次要功能是指一般完成维护系统的功能；将角色分级的主要的目的是，保证把系统的所有功能表示出来，而主要功能是使用系统的角色最关心的部分
角色也可以分成主动角色和被动角色，主动角色可以初始化用例，而被动角色不能，仅仅参与一个或多个用例，在某个时刻与用例通信
3.3.1 发现角色
l 使用系统主要功能的人是谁（即主要角色）
l 需要借助于系统完成日常工作的人是谁
l 谁来维护、管理系统（次要角色），保证系统正常工作
l 系统控制的硬件设备有哪些
l 系统需要与哪些其它系统交互
l 对系统产生的结果感兴趣的人或事是哪些
在完成了角色识别工作后，建模者就可以建立系统或与系统交互的实体（entities）了，即可以从角色的角度出发，考虑角色需要系统完成什么样的功能，从而建立角色需要的用例
3.3.2 UML中的角色
UML中的角色是具有版类《角色》的类，该类的名字用角色的名字命名，用以反映角色的行为。角色类包含具有属性、行为和描述角色的文档性质。
两种图示法：右边的一般用在用例图中
3.3.3 角色之间的关系
在用例图中，只用通用化关系描述若干个角色之间的行为
通用化关系的含义是：把某些角色的共同行为（原角色中的部分行为），抽取出来表示成通用行为，且把它们描述成为超类（superclass）
3.4 用例
3.4.1 什么是用例
用例代表的是一个完整的功能。UML中的用例是动作步骤地集合。动作（action）是系统的一次执行（能够给某个角色输出结果值）
用例具有以下特征：
l 用例总由角色初始化
l 用例为角色提供值
l 用例具有完全性：只有产生了返回给角色的结果值，才能说明用例执行完毕
用例和角色之间也有连接关系，用例和角色之间的关系属于关联（association），又称为通信关联（communication association）；
3.4.2 发现用例
l 角色需要从系统中获得哪种功能?角色需要做什么?
l 角色需要读取、产生、删除、修改或存储系统中的某种信息吗?
l 系统中发生的事件需要通知角色吗?或者角色需要通知系统某件事吗?这些事件（功能）能干些什么?
l 如果用系统的新功能处理角色的日常工作是简单化了，还是提高了工作效率?
l 还有一些与当前角色可能无关的问题，也能帮助建模者发现用例，如：系统需要的输入/输出是什么信息?这些输入/输出信息从哪儿来到哪儿去?系统当前的这种实现方法要解决的问题是什么（也许是用自动系统代替手工操作）?
3.4.3 UML中的用例
角色与用例之间的关联关系（通信关联关系）用一条直线表示
3.4.4 用例之间的关系
用例之间有扩展、使用、组合三种关系，扩展和使用是继承关系（通用化关系）的另一种体现形式，组合则是把相关的用例打成包（package），当作一个整体看待
扩展：一个用例中加入了一些新的动作后则构成了另一个用例，这两个用例之间的关系就是通用化关系，又称为扩展关系；前者称通用化用例，后者称为扩展用例
使用：一个用例使用另一个用例时，这两个用例之间就构成了使用关系
3.5 描述用例
用例的描述其实是一个关于角色与系统如何交互的规格说明，该规格说明要清晰明了，没有二义性，描述用例时，应着重描述系统从外界看来会有什么样的行为，而不管该行为在系统内部是如何具体实现的，即只管外部能力，不管内部细节
用例的描述应包含以下几方面：
l 用例的目标
l 用例是怎样被启动的
l 角色和用例之间的消息流
l 用例的多种执行方案
l 用例怎样才算完成并把值传给了角色
3.6 测试用例
用例可用于测试系统的正确性和有效性；正确性表明系统的实现符合规格说明，有效性保证开发的系统是用户真正需要的系统
正确性测试方法有两种：一种是用具体的用例测试系统的行为，称为“漫游用例”；另一种是用用例描述本身测试，称为“定义测试”；前者好一些
3.7 实现用例
实现用例的主要任务是把用例描述中的各个步骤和动作变换为协作中的类、类的操作和类之间的关系，具体说来，就是把用例中每个步骤所完成的工作交给协作中的类来完成。
用例和它的实现（即协作）之间的关系可以用精化关系表示（带箭头的点画线）
三种版类对象类（sterotype object types）：
l 边界对象（boundary objects）：这种对象类紧靠系统的边界（虽然仍在系统内部），它负责与系统外部的角色交互，在角色和系统内部的其它对象类之间传递消息
l 控制对象（control objects）：这种对象类控制一组对象之间的交互。控制对象可以是刺激用例启动的角色，也可以用来实现若干个用例的普通序列。控制对象通常仅存于用例执行阶段
l 实体对象（entity objects）：这种对象代表系统控制区域内的区域实体。它是被动对象，本身不能启动交互。在信息系统中，实体对象通常是持久化的，存储在数据库内存中，实体对象也可以出现在多个用例中
用例图用协作实现，协作描述了类（或对象）、类与类之间的关系和交互（显示类之间怎样交互才能实现一个具体的功能），协作用活动图、协作图和交互图描述
扫一扫
1809
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
