需求建模之基于类的方法

第九章 需求建模：基于类的方法

概念：软件问题总是以一套交互对象为特征，借此在系统内表达每一个感兴趣的事物。每个对象变成对象类中的一个成员。对象的状态描述了每个对象，即数据属性描述了对象。我们可以用基于类的需求建模方法表达上述所有内容。

步骤：基于类的建模定义了对象、属性和关系。对一个问题描述做一番简单的探究后，能从问题的陈述中开发外部对象和类，并以基于文本或图表的形式进行表达。在创建了模型的雏形以后，就要对其不断改进，分析和评估其清晰性、完整性和一致性。

质量保证措施：必须评审需求建模工作产品的正确性、完整性和一致性。必须反映所有利益相关者的要求并建立一个可以从中导出设计的基础。

面向对象方法基于的都是我们最初在幼儿园中学到的内容：对象和属性，全局和部分，类和成员。

基于类建模表示了系统操作的对象、应用于对象间能有效控制的操作(也称为方法或服务)这些对象间(某种层级）的关系以及已定义类之间的协作。基于类的分析模型的元素包括类和对象、属性、操作、CRC模型、协作图和包。

识别和表示这些元素的非正式指导原则：

1 识别分析类

引述：真正困难的问题是首先发现什么才是正确的对象（类)。

通过检查需求模型(第8章)开发的使用场景，并对系统开发的用例进行“语法解析”[Abb83]，我们就可以开始进行类的识别了。带有下划线的每个名词或名词词组可以确定为类，将这些名词输人到一个简单的表中，并标注出同义词。如果要求某个类(名词)实现一个解决方案，那么这个类就是解决方案空间的一部分;否则，如果只要求某个类描述一个解决方案，那么这个类就是问题空间的一部分。

一旦分离出所有的名词，我们该寻找什么?分析类表现为如下方式之一：

1.1 外部实体（例如其他系统、设备、人员):产生或使用基于计算机系统的信息。

1.2 事物（例如报告、显示、字母、信号):问题信息域的一部分。

1.3偶发事件或事件（例如所有权转移或完成机器人的一组移动动作):在系统操作环境内发生。

1.4 角色（例如经理、工程师、销售人员):由和系统交互的人员扮演。

1.5 组织单元（例如部门、组、团队):和某个应用系统相关。

1.6 场地（例如制造车间或码头):建立问题的环境和系统的整体功能。

1.7 结构（例如传感器、四轮交通工具、计算机):定义了对象的类或与对象相关的类。

潜在类是否使用如下特征：

1.1 保留信息。只有记录潜在类的信息才能保证系统正常工作，这样潜在类才能在分析过程中发挥作用。

1.2 所需服务。潜在类必须具有一组可确认的操作，这组操作能用某种方式改变类的属性值。

1.3多个属性。在需求分析过程中，焦点应在于“主”信息;事实上，只有一个属性的类可能在设计中有用，但是在分析活动阶段，最好把它作为另一个类的某个属性。

1.4 公共属性。可以为潜在类定义一组属性，这些属性适用于类的所有实例。

1.5 公共操作。可以为潜在类定义一组操作，这些操作适用于类的所有实例。

1.6必要需求。在问题空间中出现的外部实体，以及任何系统解决方案运行时所必需的生产或消费信息,几乎都被定义为需求模型中的类。

（详细例子可以参考9.1章节）

2 描述属性

属性描述了已经选择包含在需求模型中的类。实质上，属性定义了类，以澄清类在问题空间的环境下意味着什么。

为了给分析类开发-一个有意义的属性集合，软件工程师应该研究用例并选择那些合理的

“属于”类的“事物”。此外，每个类都应回答如下问题:什么数据项(组合项或基本项)能够在当前问题环境内完整地定义这个类?

左边是属性，右边是数据项，如用以下方式表示一个数据项：

识别信息=系统编号＋确认电话号码＋系统状态

报警应答信息=延迟时间＋电话号码

激活或者关闭信息=主密码＋允许重试次数＋临时密码

通常，如果有超过一个项和某个类相关联,就应避免把这个项定义为属性。

3 定义操作

操作定义了某个对象的行为。尽管存在很多不同类型的操作，但通常可以粗略地划分为4种类型：(1)以某种方式操作数据（例如添加、删除、重新格式化、选择)；（2）执行计算的操作；(3）请求某个对象的状态的操作；( 4）监视某个对象发生某个控制事件的操作。这些功能通过在属性或相关属性（9.5节)上的操作来实现。因此,操作必须“理解”类的属性和相关属性的性质。

4 类-职责-协作者（Class-Responsibility-Collaborator，CRC)建模

CRC模型实际上是表示类的标准索引卡片的集合。这些卡片分三部分，顶部写类名，卡片主体左侧部分列出类的职责，右侧部分列出类的协作者。

事实上，CRC模型可以使用真实的或虚拟的索引卡，意图是有组织地表示类。职责是和类相关的属性和操作。简单地说，职责就是“类所知道或能做的任何事。协作者是提供完成某个职责所需要信息的类通常，协作意味着信息请求或某个动作请求。

 

类的分类可以通过如下分类方式进行扩展：

4.1 实体类，也称作模型或业务类，是从问题说明中直接提取出来的这些类一般代表保存在数据库中和贯穿在应用程序中(除非被明确删除）的事物。

4.2边界类，用于创建用户可见的和在使用软件时交互的接口。实体类包含对用户来说很重要的信息，但是并不显示这些信息。边界类的职责是管理实体对象呈现给用户的方式。

4.3 控制类，自始至终管理“工作单元”。也就是说，控制类可以管理;( 1）实体类的创建或更新;(2）边界类从实体对象获取信息后的实例化;( 3）对象集合间的复杂通信;(4）对象间或用户和应用系统间交换数据的确认。通常，直到设计开始时才开始考虑控制类。

给类分配职责时建议了以下5个指导原则：

4.1 智能系统应分布在所有类中以求最大程度地满足问题的需求。

4.2 每个职责的说明应尽可能具有普遍性。

4.3 信息和与之相关的行为应放在同一个类中。

4.4 某个事物的信息应局限于一个类中而不要分布在多个类中。

4.5 适合时,职责应由相关类共享。

5 关联和依赖

两个分析类以某种方式相互联系着。在 UML中，这些联系被称作关联（ accociation)。

6分析包

分析建模的一部分重要工作是分类,也就是将分析模型的各种元素(如用例、分析类）以一种方式分类，分组打包后称为分析包，并取一个有代表性的名字。分析包用来集合一组相关的类。