第8章 用例分析

边界类的表示方法
边界类在模型中有两种表示方法，如下 图所示。一种是构造性<<boundary>>的类 形式，另一种是图标形式。
<<boundary>> 边界类名称
边界类名称
图7-3：边界类的表示方法
2．控制类（Control）
控制类是用于封装一个或几个用例所特 有的流程控制行为，通过它可建立系统的 动态行为模型。它有效地分离了边界类对 象和实体类对象，使系统更能承受边界的 变更，它还将用例所特有的行为与实体类 对象分离，使得实体类对象在用例和系统 中具有更高的可复用性。
2．查看帖子的用例规约。 第1步：进入分组讨论区界面。 讨论区成员：选择进入相应的分组讨论区。 系统：将分组讨论区中信息全部显示出来。 第2步：查看帖子。 讨论区成员：选择需要查看的帖子。 系统：显示帖子的全部内容。
分析以上用例规约中存在的边界类、实 体类和控制类。
拓展练习 （1）根据“新增帖子”的用例描述，给出 “删除帖子”、“修改帖子”的用例描述。 （2）分析“删除帖子”、“修改帖子”中存 在的边界类、控制类和实体类。
: Student
扩展思考：时序图与协作图的比较
8.4 习题与练习
1．用哪种UML图可以表示对象的交互？他们的组成 元素都有哪些？ 2．描述对象A和对象B之间“打电话”的时序图，并 将其转换为协作图。 3．选择一个系统（例如工资管理系统、飞机订票系统 或图书管理系统等），分别用OOA方法对它进行分析，并 给出分析模型。 4．根据以下用例图，分析储户在取款过程中存在的分 析类，并画出时序图和协作图。
边界类：表示参与者与系统之间的交互； 实体类：表示系统存储和管理的永久信息； 控制类：表示系统在运行过程中的业务控制逻辑。
这种划分的基本思想是将对象在系统中所承担 的行为按照其作用和变化影响程度进行分类，将 变化对系统结构的影响限制在一个相对明确的范 围内。
需求分析的过程
理解用例模型 识别实体类
1）实体类的识别质量很大程度上取决于分析人员书写 文档的风格和质量； 2）自然语言是不精确的，因此在分析自然语言描述时， 应该尽量使描述文档中的一些措辞规范化，以弥补这种不 足； 3）在自然语言描述中，名词可以对应类、属性或同义
词等多种类型。
8.2.5 用例分析示例
修改帖子
查看帖子
讨论区人员
回复帖子
控制类的特点：
独立于环境，不随环境的变更而变更； 确定用例中的控制逻辑和事务； 在实体类的内部结构或行为发生变更时， 也不会变更； 使用或规定若干实体类的内容，协调这些 实体类的行为； 可能按不同的流程或方式执行。
控制类的表示
控制类在模型中有两种表示方法，如下 图所示。一种是构造性<<control>>的类形 式，另一种是图标形式。
面向对象分析完成下列内容： 1）发现和定义系统存在的类。
2）识别分析类。
3）定义交互行为，即对象行为模型。
8.2 识别分析类
分析类的来源：用例规约
分析类的角度：
系统与角色的边界； 系统使用的信息； 系统的控制逻辑。
8.2.1 什么是分析类
在面向对象的分析中，类代表了一组对象所 共同拥有的属性和行为。在分析识别类中，根据 分析角度的不同，将分析类划分为边界类、实体 类和控制类。
<<entity>> 实体类名称
实体类名称
图7-5：实体类的表示方法
8.2.2 识别边界类
通常，一个参与者与一个用例之间的交互或者通信 对应一个边界类。边界类信息收集是从参与者的角度考虑， 而这些边界类信息将来可以被实体类和控制类所使用。下 图示意了边界类识别的基本方法，也就是在每一对“用 例—参与者”之间确定一个边界类。
学生
选课
课程目录系统
Student
Schedule
RegistrationController
CourseOffering
sd seq
:Student
:RegisterCourseForm
:RegistrationController :CourseCatalogSystem
:Schedule
:Student
8.2.4 识别实体类
实体类通常是用例中的参与对象，对应 着现实世界中的“事物”，识别实体类需 要开发人员进一步理解应用领域，可以通 过分析用例描述和词汇表等发现备选的实 体对象。
实体类的因素包括以下几点： 人员 组织 物品 设备 事件 表格
识别实体类应当注意的以下几个问题：
新增帖子
1．新增帖子的用例规约 第1步：进入分组讨论区界面。 讨论区成员：选择进入相应的分组讨论区。 系统：将分组讨论区中信息全部显示出来。 第2步：新增帖子。 讨论区成员：要求新增一条帖子信息。 系统：进入新增帖子界面。 第3步：填写帖子。 讨论区成员：填写帖子中的具体信息。 系统：显示输入的内容。 第4步：提交。 讨论区成员：提交填写好的讨论区。 系统：保存该讨论区到内部数据库。
<<control>> 控制类名称
控制类名称
图7-4：控制类的表示方法
3．实体类（Entity）
实体类是用于对必须存储的信息和相关 的行为建模，其主要职责是存储和管理系 统中的信息。它通常具有持久性，即他们 的属性和关系需要长期保存，有时甚至在 系统整个生命周期都存在。
实体类的表示
实体类在模型中有两种表示方法，如下 图所示。一种是构造性<<entity>>的类形式， 另一种是图标形式。
:CourseCatalog
1://create schedule()
2://get course offerings() 3://get course offerings(forSemester)
4://get course offerings() 5://display course offerings()
识别分析类
识别边界类
识别控制类 定义交互行为
评审分析模型 图7-2：需求分析过程
1．边界类（Boundary）
边界类是用于描述外部参与者与系统之间的交互。 一个系统可能有多种边界类： 用户界面类：用户和系统用户进行通信； 系统接口类：用户和其他软件系统进行通信； 设备接口类：为硬件设备提供接口。
8.3.1 时序图
以时间顺序显示对象交互的图，它显 示了参与交互的对象和所交换消息的顺序。 由于对象生存期的引入，时序图具有时间 顺序的概念，从而可以清晰地表示对象在 其生存期的某一时刻的动态行为。
1.时序图的组成
（1）对象 （2）生命线 （3）消息 （4）消息条件 （5）标号 （6）激活（控制期）
用户
用例
外部系统
用户界面 图7-6：识别边界类的示意图
外部系统接口
识别边界类应注意以下几个问题：
边界类应关注参与者与用例之间交互的信息或者响应的事件， 不要描述窗口组件等界面的组成元素； 在分析阶段，力求使用用户的术语描述界面；
边界类实例的生命周期不限于用例的事件流，如果两个用例同 时与一个参与者交互，那么它们很可能会一边共用一个边界类， 一边增加边界类的复用性。
8.2.3 识别控制类
控制类负责协调边界类和实体类，通常在现实世界中没有 对应的事物，它负责接受边界类的信息，并将其分发给实 体类。 控制类与用例存在着密切的关系，它在用例开始执行时创 建，在用例结束时取消。一般来说，一个用例对应一个控 制类，如下图所示。
用户
用例
外部系统
控制逻辑 图7-7：识别控制类的示意图
例3：绘制新增帖子的协作图。
例4：绘制学生选课的协作图。
sd seq 5://display course offerinngs() 6://display blank schedule
: CourseCatalog
(from Actors)
4://get course offerings()
识别控制类应当注意以下几个问题：
当用例比较复杂时，特别是在产生分支事件流的情况 下，一个用例可以有多个控制类； 在有些情况下，用例事件流的逻辑结构十分简单，这 时没有必要使用控制类，边界类可以实现用例的行为； 不同用例包含的任务之间存在着比较密切的联系，则 这些用例可以使用一个控制类，其目的是复用相似部 分以降低复杂性。
6://display blank schedule()
7://select 4 primary and 2 alternate offerings()
8://create schedule with offerings()
9://create with offerings()
10://add schedule(Schedule)
:RegisterForCourseForm
1://create schedule() 7://select 4 primary and 2 alternate offerings()
2://get course () 8://create schedule with offerings()
(from Actors)
(from Actors)
8.3.2 协作图
协作图是表示角色间交互的图，主要用 来描述对象间的交互关系。协作图是一种 基于结构的表示交互的方法，强调参加交 互的对象的组织。
1.协作图的组成
（1）对象 （2）链 （3）消息
2.协作图的生成
协作图使用对象图作为基础，产生一张 协作图，首先要将参加交互的对象作为图 的顶点；然后，把链接这些对象的链表示 为图的弧；最后，用对象发送和接收的消 息来修饰这些链，这就提供了在协作对象 的结构组织的语境中观察控制流的一个清 晰的可视化轨迹。