第12章领域分析 p84.pptVIP

《UML面向对象建模与设计》(第2版)，Michael Blaha,James Rumbaugh 著，车皓阳 杨眉译，人民邮电出版社，2006年 第12章 领域分析 领域分析(domain analysis)，关心的是如何设计出一套准确简洁的、可以理解的和正确的真实世界的模型 在分析过程中，创建模型，并开始深度理解需求 要创建领域模型，就必须与业务专家交流，检查需求陈述并审视相关制品 要把重要的特征抽象出来，并把细节推迟到后续阶段 成功的分析模型描述了必须要完成哪些内容，但它没有限制完成这些内容的方式，它们还要规避实现决策 构造领域模型有几个目的：澄清需求，为风险承担人和开发者之间的约定提供依据，而且要把模型当成设计和实现的出发点 12.1 分析概述 分析模型描述对象的三个方面：对象的静态结构(类模型)、对象之间的交互(交互模型)和对象的生存期(状态模型) 在每个问题当中，这三个子模型并不是同等重要的 几乎所有的问题都会有类模型，类模型是对真实世界实体的抽象 涉及反映控制和定时响应的问题，例如用户界面和过程控制，都需要有重要的状态模型 一些问题，比如大量的计算以及与其他系统和不同用户交互的系统，都会有重要的交互模型 把分析划分成两个阶段： 第一个阶段，领域分析，专注于理解问题的真实本质 第二个阶段，应用分析，构建于领域模型之上——合并了用户可见的主要的应用程序制品，用户必须核准这些制品的使用权 12.2 领域类模型 分析需求的第一步是构造领域模型 领域模型显示了真实系统的静态结构，并把系统划分成可工作的片段 领域模型描述真实世界的类以及它们之间的相互关系 在分析过程中，类模型的优先级要高于状态和交互模型，这是因为静态结构容易更好地定义，而且会较少地依赖应用程序的细节，并且当解决方案发生演化的时候会更加稳定 领域模型的信息来自于问题陈述、其他相关系统的制品、专家对应用领域的了解以及对真实世界的总的认识 要先寻找类和关联，因为它们提供了问题的总体结构和方法 接下来要增加属性来描述类和关联的基本网络 然后使用继承来组合和组织这些类 在领域模型中，操作常常是不重要的，领域模型的主要意图是捕获领域的信息内容 初始分析模型可能会有缺陷，必须在后面的迭带中更正 整个模型不一定非要统一进行创建 问题的某些反面可能要经过几次迭代进行深度分析才行，而其他方面却仍然可以粗略分析 创建领域类模型，必须要经过下面几个步骤： 寻找类[12.2.1~12.2.2节] 准备数据字典[12.2.3节] 寻找关联[12.2.4~12.2.5节] 寻找对象和链接的属性[12.2.6~12.2.7节] 使用继承组织和简化类[12.2.8节] 验证可能查询的访问路径[12.2.9节] 迭代并细化模型[12.2.10节] 把类编组成包 12.2.1 寻找类 创建类模型的第一步就是从应用领域寻找相关的对象类 对象包括物理实体，例如房屋、人和机器 概念也是对象，例如弹道、座位分配和付款计划 所有的类都必须在应用领域中是有意义的；要避免出现实现制品，例如链表和子程序 在问题陈述中并不是所有的类都是清晰的；有一些类会隐含在应用领域或常识之中 从问题的书面描述中列举候选类开始。不要精挑细选；要记下能想起来的每一个类。类常常与名词对应。 例如，在语句“销售不同剧院剧目入场券的预定系统”中，暂定类会是Reservation(预定)、System(系统)、Ticket(入场券)、Performance(剧目)和Theater(剧院) 但是，我们的目的是捕获概念；一方面并不是所有的名词都是概念，另一方面概念也会在话语的其他部分中得到体现，这些都是值得注意的问题 不要过分担心继承或者高层类；首先要了解某些特定的类，这样就不会在潜意识里抑制细节，以图和预想的结构相配合 例如，如果正在为图书馆创建目录和检出系统，那就要确定不同种类的资料，例如图书、杂志、报刊、唱片、录像，等等。 在以后，通过寻找相似性和差异性，可以把它们归类到更广泛的范畴内 12.2.2 保留正确的类 冗余类。如果两个类展示出相同的概念，应该保留最具描述能力的那个名称 例如，尽管Customer可以描述乘坐航班的某人，但Passenger更具描述力。另一方面，如果问题与包机合约相关，那么Customer也是合适的名称，因为这项合约会牵涉好多名乘客 ATM示例。Customer和User是冗余的；保留Customer是因为它更具描述力 不相关的类。如果一个类和问题关系不大或者干脆无关，那就删除它。在这里要进行判断，因为在另一个环境里这个类可能反而会很重要 例如，在剧院订票系统中，持票人的职业是无关的，但剧院人员的职业却是很重要的 ATM示例。分摊费用就位于ATM软件范畴之外 含混的类。类应该是详尽而精确的。一些临时类的边界定