SJ Z 11289-2003 面向对象领域工程指南.pdf

I CS 3 5.0 8 0L 7 7备案昙:1 2 0 3 4-2 0 0 3中 华 人 民 共 和 国 电 子 行 业 标 准S J/Z 1 1 2 8 9-2 0 0 3面向对象领域工程指南G u id e o f o b j e c t-o ri e n te d d o m a in e n g i n e e ri n g2 0 0 3-0 6-0 4 发布2 0 0 3-1 0-0 1 实施中 华 人 民 共 和 国 信 息 产 业 部 发布S J/Z 1 1 2 8 9-2 0 0 3目次前言.一，.，.一”.-.一”“.-.-.价.，.II引言一价二价 二 价.一一一.一一一.一一一一.一一.一一一一.，m1 范围卜.”.”，.”.”.，.-卜.一 ，.卜.一12 术语和定义.-.一 价 价.一，”.-.-一”.-.，.13 领域工程方法概述.”.一”“”，.-.-一”“.-二，.-.，.13.1 领域工程的定义 一”.-.-.一”.价”.-.-.-.-.，价一.一.一13.2 领域工程中的活动与产品 一价，-.-一，.一 甲 二 甲-.-.-”.一，.一，甲，-.-二，-13.3 共同性与变化性.-一”.，.“.一“”.一 价一.一一.一 一.33.4 参与领域工程的人员二价 价-.-.-一”.-.-.-.-.-.一54 准备工作二价.，.价 一一价一一一一，.一一一 一一，.一一.M一一一一，一，.64.1 规划问题 二“，价，.，价.一一一一一.一一一一一一一 一，.64.2 管理问 题.，.-.一，.，.“.“.-一 85 领域分析二，.，.，.卜.价.一 价一一.一一一一-一.85.1 目标与产品，.，.一，二，.-，.价.，.-.85.2 过程.，.，.，价.，.价 一一 一 一价 一一一一一，.95.3 活动与指南，.，一价，二 二，价一 一一一一.一.一.一.一一一一一1 06 领域设计.卜 卜 .一，.卜.，卜.-卜.一 1 36.1 目 标与产品.，.一，.，.，.，.1 36.2 过程，.，.，二，.，二，-_二 1 36.3 活动与指南.一.-.，.，一，一，.-.，价.一 1 47 领域实现二，.-价.一，.-.一，.，.卜.-二，.，.1 87.1 目标与产品二价-，.，.价.一一.一价一一.一.1 87.2 过程.价，.价 一一一.一一.一.一一.一.一.一一一一一.一一，.1 97.3 活动与指南，.，.，.，“，.，.，.，.，.2 0S J/Z 1 1 2 8 9-2 0 0 3前言本指导性技术规范由中国电 子技术标准化研究所归口。本指导性技术规范由北京大学负责起草。本指导性技术规范主要起草人:王千祥。S J/Z 1 1 2 8 9-2 0 0 3引言0.1 系统化的软件复用 软件复用可以提高软件的质 量和生产率，被认为是解决“软件危机”的现实可行的途径。复 用包括个别式复用与系统化复用两种方式。在个别式的软件复用中，存在一组可 复用构 件，应用开发者 对它们进行选择和复用。应用开发者的责任包括识别可能进行复用的 机会，选择满足需要的构件或经过修改可以 满足需要的构件，得到这些构件并利用它们组装成新的应用系统。在这种复 用中，复用是 在个人的，而不是在项目 的级别是进行的，也没有定义复用的过程。在系统化的软件复用中，不但存在一组可复用构件，而且定义了在新的应用系统的开发过程中复用哪些构件以 及如何进行适应性修改。由于一般性地识别、表示 和组织可复用信息是非常困难的，因此系统化的复用将注意力集中于特定的 领域，而且在系统化的复用中非常重视软件生 命周期中抽象级别较高的 产品的 复用。在这种复用中，复用是在项目 级别 进行的，定义了复用的指南和过程，定义了度量标准以衡量复用的效率 与个别的软件复用相比，系统化的软件复用对于提高软件的质量和生产率具有更大的作用。由于将注意力集中于特定的 领域，使得软件开发组织可以 获得对该领域的深入了 解，对于可复用信息的 识别和表示会比 较容易和准确，在此基础上定义的复用指南会对复用过程较有帮助。完整定义的复 用过程和对复用的度量，使得复用可以比较规范和系统化，从而有助于实现软件开发组织实施复用的预期目 标。同时，实施系统化的软件复用也有较大的风险。实施系统化软件复用的软件开发组织需要解决一系列技术和非技术的问 题，例如，分析本组织的需要，定义适合这些需要的复用过程，调整人员的组织方式，建立度量标准以 衡量复 用的效率，并据此调整复用过程，估计投资和收益，建立特定领域的可复用构件，等等。这些行为需要较大的前期投资和整个软件开发过程和原则的变化，而预言这些投资的回报却是困难的。在系统化的软件复用中，充分的 可复 用信息的存在是非常重 要的。这些信息需要被显式 地表示，以便在开发过程中 被复用。这些可复用信息，和为方便地定位和操作它 们的一些辅助信息一起构 成了复用基础设施(R e u s e I n fr a s t r u c t u r e)。复用基础设施也是基于 特定领域的。0.2 领域工程 系统化复用的成功依赖于很多因素，其中领域工程是系统化的软件复用成功的关键。这主要表现在以下三个方面:a)复用基础设施的 形成是通过领域工程实现的。通过领域工 程，将关于一个领域的知识转化成为 一组规约、构架和相应的可复用构件。由 于这些信息来自 于同一领域中 现有的系统，因此它们 具有较高的可复用性。这些可复用信息构成了复用基础设施的重要组成部分:b)复用基础设施的 演化也是 通过领域工程实现的。当一个领域中的 应用系统增加了的 时候，通过 领域工程，可以 对这些系统 进行新的分析，将新系统的 特征也包含在规约、构架和可复用构件 中，从而使本领域中系统开发的知识和经验尽可能地反映在复用基础设 施中，以 促进新系统的 开发;c)领域工程对于系统化的软件复用的 意义还在于，领域工程不仅产生了 可复用性较高的构件，而 且通过产生构架定义了复用的 时机和复用的上下文。这样就对开发者复用这些构件提供了 有力 的支持，使得复用变得规范、系统和高效。mS J/Z 1 1 2 8 9-2 0 0 3 领域工程对领域中的系统进行分析，识别这些应用的 共同特征和可变特征，对刻划这些特征的 对象和操作进行选择和抽象，形成领域分析模型，依据领域分析模型产生出领域中应用共同具有的构架(即特定于领域的软件体系结 构，缩写为D S S A)或生 成过程，并以此为基础识别、开发和组织可复用构件。这 样，当 开 发同 一 领 域中 的 新 应 用 时，可 以 根据 领 域 分 析 模型，确 定 新 应 用的 需 求 规 约，根 据 特 定于 领域的软件体系结构形成新 应用的设计，并以 此为 基础 选择可复用构件进行组装，从而形成新系统，或利用生成过程由新的需求生成系统。S J/Z持、1 1 2 8 9-2 0 0 3影响和制约。1一。!1三现/-。二州叻朔镇一、J一实一-二二川映睡拌丁L一域川-。一一牛令一口和一/领-。领域分析模型 OOA 一褂仑领域分析规划和管理活动币r r 刃 确 定 领 域 F T-A 舜 画币卿刃曰 全 堑工程的目 标 匕 M-M暨曰 口壹 止 星 塑口 图1 领域工程的活动与产品3.2.1 领域分析 这个阶段的主要 目标是获得领域分析模型。在这个阶段之前需要进行一些准备工作，这些准备工作包括确定领域工程的目 标;制订领域工程的规划;定义领域的 边界;识别信息源等。领域工程的 准备工作将在第 4 章进行详细地介绍。在此基础上，就可以分析领域中系统的需求，确定哪些需求是被领域中的系统广泛共享的，从而建立领域分析模型。当领域中存在大量系统时，需要选择它们的一个子集作为样本系统。对样本系统需求的考察将显示领域需求的一个变化范围。一些需求对所有被考察的系统是共同的。一些需求是 单个系统所独有的。很多 需求位于这两个极端之间，即 被部分系统共享。3.2.2 领域设计 这个阶段的目 标是获得D S S A。建立了 领域分析模型之后，就可以 派生出满足这些被建模的领域需求的D S S A。由 于领域分析模型中的领域需求具有一定的变化性，D S S A也要相应地具有变化性。它可以 通过表示具有变化性的解决方案等来作到这一点。由 于复用基础设施是依据领域分析模型和 D S S A来组织的，因此在 这个阶段通过获得D S S A，也就同时形成了复用基础设施的 规约。3.2.3 领域实 现 这个阶段的 主要目 标是依据领域分析模型和 D S S A开发和组织可复用信息。这些可复用信息可能是从现有系统中 提取得到，也可能需要通过新的开发得到。它们依据领域分析模型 和D S S A进行组织，也就是领域分析模型和D S S A定义了 这些可复用信息的复用时机，从而支持了系统化的软件复用。这个阶段也可以看作复用基础设施的实现阶段口3.2.4 领域分析模型 领域分析模型描述领域中系统 之间的共同的需求。领域工程的实施是基于这样一个事实:同一 领域中的系统的需求必然具有显著的共性，其实 现也常常具有共性。领域分析模型就描述了 需求上的共性。称领域分析模型所描述的需求为“领域需求”(D o m a i n R e q u ir e m e n t).领域分析模型是面向问题域的。领域分析模型包括了业务模型、业务过程和应用系统需求。但它不表示过程和功能 如何实现。其中，业务模型反 映了 业务策略或操作概念，即，组织计划如何成功地进行操作。业务模型提供了定义业务过程的指南。业务过程定义了 达到反映在业务模型中的目 标所需的业务功能以 及功能 之间的流。业务过 程是实现业务过 程的应用系统的需求的 来源。应用系统需求是为实现 业务过程所需的更 加详细、更加技术性的 功能。领域分析模型主要包含以下几个部分:领域术语字典、领域需求定义、面向对象分析模型(O OA模S J/Z 1 1 2 8 9-2 0 0 3 b)对于同一组事物采用不同的分类方式。在领域工程中，需要将以 上这些不一致的术语统一起来。一方面，统一术语可以 使领域工程的参与者有共同的语言，便于领域工程的实施。另一方面，术语归根到底是对事物的分类。统一术语的过程中，也就识别了领域中有哪些共同的 事物，以 及这些共同的事物可以 有何种共同的 分类方式，即 识别了领域中的 共同性。而为 这样的一些事物(而不是另外一些事物)定义术语，常常是由于这些事物在当前处理的问题中比较基本或比较重要，那么，在统一术语的过程中识别的这些共同性，在领域中也常常是比较基本或比较重要的。3.3.2 变化性 当在整个领域，而不是单个系统的范围内考虑问题时，会发现从需求定义、分析模型直到实现都存在变化性。而且在这些具有变化性的成分之间还存在着依赖、互斥等关系。下面以需求为例讨论变化性和关系的基本情况。当考察领域中现有系统的需求时，会发现这些需求体现出一定的变化性。可以将这些需求分为可选的(O p t i o n a l)、多选一的(A l t e r n a t iv e).可选的需求。部分现有系统具有这类需求，但并非全部系统都具有。未来的系统可能具有这一需求，也可能不具有这一需求。这类需求体现了领域中系统间的变化性。这种可选的需求可以成为定义应用系统维度的子领域的依据。可以 将具有某种可选的需求r 的系统定义为一个子 领域E，则在这个子领域中，需求 r 成为了必须的需求。相应地，可以将不具有需求 r 的系统定义为一个子领域 F，则在这个子领域中，没有需求r.多选一的需求。这是一组互相之间存在着特定关系的需求。假设需求 a,b,c是这样的一组需求，当单独地考察每项需求时，它们都是可选的需求，但是，一个特定的系统必须具有其中的一项需求，又只能 具有其中的一项，即，不能同时具有a 和b，或a 和c，或a,b 和c。从领域/子领域的角度来看，这类需求提供了将领域划分为一组应用系统维度的子领域的一种可能的方式。仍以上述多选一的需求a,b和 c为例，可以将具有需求 a,b或 c的系统分别定义为子领域 E,F和 G，这三个子领域就形成了对原来的领域D的一个划分。在这样划分形成的三个子领域中，a,b或 c 分别成为各 自子领域中必须的需求。当运用抽象的原则看待这些多选一的需求时，就会发现，它们常常是某个比较抽象的、必须的需求的一组具体的实现方式。这种认识一方面有助于对需求的了解和组织，另一方面有助于定义和实现满足这些需求的构件。这一点将在下文中进一步讨论。3.3.3 变 化性之间的关系 领域中具有变化性的需求间可能的关系包括依赖、互斥等。依赖关系是指只有在需 求a 存在的 情况下，才能存在需求b，这时 称需求b 依赖于需求a.互斥关系是指需求 a 和 b 不能同时存在于一个系统中。上面讨论的多选一的需求是具有互斥关系的需求的一种特殊情况。以 上对领域需求的 变化性的讨论同样适用于领域的 面向 对象分析 模型(即O O A模型)、D S S A。只是在O O A模型和D S S A中 具有变化性的元素是类、属性、服务、关系等。3.3.4 变化性的固 定 当 基于领域工程的产品 进行应用工程时，为得到单个目 标系统的各个阶段的产品，需要将变化性固定下来。需求上的变化性有不同的固定时间，在开发单个目标系统时，需要固定固定时间为开发时的哪些变化性。对于可选的需求，要确定是否选择该需求，对于多选一的需求，要确定选择哪一个需求。不同的 变化性可能具有不同的固定时间。典型的固定时间包括开发时和运行时。开发时固定意味 着在系统开发的过程中(分析、设计、实现、编译、链接)固 定变化性。运行时固定意味着在系统开发告 一段落，系统投入运行后，通过设置数据等手段，固定变化性。需求上的变化性的固定时间对于系统的设计有显著的影响。如一组多选一的需求的固定时间为运行时，就要求系统能够对这一组需求都进行支持，而且要提供在系统投入运行后从这一组需求中选择一个的手段。因此，在领域工程的实施中识别变化性S J/Z 1 1 2 8 9-2 0 0 3 领域工程中的活动依据其组织方式，可以分为两种。一种是领域工程师组织的领域专家会议。基于会前的准备，领域专家在会议中就与被分析的领域相关的问 题进行报告，然后领域专家 在领域工程师的组织和引 导下，基于一致的意见形成某种领域工程产品，或形成对于某种领域工程产品的开发计划，并对产品进行复审。另一种是会议以外的准备和开发工作。在会前，领域专家针对在会议中将涉及的与被分析的领域修改的问题进行必要的准备，领域工程师也要对这些问题进行尽可能的了解。在会后，要对会议上形成的一致意见进行整理 和文档化，为 会议上形成的领域工程产品 增加细节，要依据会议上形成的开发计划进行具体领域工程产品的开发工作。这些工作主要由领域专家完成。在整个领域工程的实施过程中，这两种活动是穿插进行的。4 准备工作 领域工程是一项需要大量人力和资源投入的活动，因此，除了本指导性技术规范将作为核心内容进行介绍的领域分析、领域设计、领域实现等技术问题以外，还对准备工作进行介绍，例如:规划和管理等方面的问题。这些问题对于领域工程的实施是非常重要的，但它们不是领域工程的核心活动，本章将对这些问题进行简要的讨论。4.1 规划问题 领域工程中的规划问题涉及确定领域工程的目标、确定领域工程的范围、制订领域工程的实施计划等方面。这些问题是在领域工程实施的初期就要遇到的，同时，由于领域工程过程是反复的、逐渐精化的过程，在领域工程的实施过程中，这些问题可能需要重新考虑。4.1.1 进行可行性分析 基于对软件开发组织的情况、领域中现有的软件开发情况、领域的成熟程度、组织可用的资源等方面的考察，分析进行领域工程的可行性。这些需要考虑的问题包括:a)组织是否将在领域中继续开发新的系统，并且在新的开发中得益于领域分析模型、D S S A和可 复 用构 件的 存在?助组织是否已经充分了 解了领域中 系统的开发技术，使得建立令人 满意的领域分析模型和D S S A 成为可能?c)开发者是否已 经通过开发领域中的 系统获得了足够的经验，以 保证领域工程的 产品是可用的?d)是否有(或将建立)机制以 保证领域工程的产品 真正 地被使用?等。如果这些问 题的回答都是肯 定的，那么进行领域工程就可能是合适的。4.1.2 定义领域工程的目 标 定义领域工程的目标是领域工程中首先要进行的活动。基于不同的领域工程 目标，为领域工程分配的资源、领域工程的实施过程和得到的产品都会有所不同。组织进行领域工程的可能的目标包括:a)对问题域的描述和理解;b)对问题域、解空间以及两者映射关系的描述和理解;动基于现有的系统，开发D S S A和可复用构件，以利于新系统的快速开发;d)对现有系统进行再工程，引入新的技术，同时尽可能领域现有系统的开发经验，以利于新系统 的快速开发;e)其它口 可行性分析是定义领域工程 目标的基础。为降低实施领域工程的风险，在定义 目标时应根据软件开发组织当前的状况，在可用资源的约束下，解决组织面临的最重要、最迫切的问题，避免定义过多、过高的目 标，将有限的资源分散。4.1.3 确定领域的范围 通过确定领域的范围，可以明确分析的对象，领域工程过程中所有活动都要在这个范围内进行。如上所述，“领域”是指一组具有相似或相近软件需求的应用系统所覆盖的功能区域。因此，领域范围的 S J/Z 1 1 2 8 9-2 0 0 3确定既要考虑应用系统的方面，也要考虑功能区域的方面。在功能区域方面，要确定本次的领域工程活动将针对哪个或哪些功能进行。这里要注意的是，这些功能应具有内在的联系，一个指导性的原则是这些功能与一组共同的数据相关。如果将一组没有内在联系的功能结合为一个领域，进行领域工程，将使得领域工程的目标较为发散，得到的结果将缺乏整体性和一致性。在应用系统方面，要确定本次的领域工程活动将对哪些应用系统进行分析。如果被分析的系统过少，分析的结果是否适用于其它系统或预期的系统，就缺乏可靠的依据。因此，被分析的领域应该至少有三个现有的系统。确定作为分析对象的系统之后，在领域工程中由这些系统得到的信息，应该说明是由哪个或哪些系统得到的。图2 描述了在两个维度上确定领域范围的活动。应 用 系 统匕二二井井共森丰勃以蕊勃了功能区域图2 确定 领域范围 在整个领域工程的过程中，有可能将整个领域划分为几个不同功能区域上的子领域。这时，在各个功能区域上所选择的系统可以是不同的。由于整个领域工程过程是反复的、逐渐精化的过程，因此从领域工程的实施过程中，可能进行多次的范围确定。确定后的领域范围，要在领域工程文档中显式地说明。确定领域范围时要考虑以下方面的问题:a)领域工程的目 标;b)进行领域工程的可用资源。这里所指的资源包括时间、人力、财力等方面。当资 源比较充足时，可以使目标领域包含较大的功能区域和较多的现有系统。反之，则应选择较小的功能区域和较 少的现有系统。基于领域工程的目标，功能区域变化的余地可能较小，而现有系统变化的余地 可能较大;c)充分考虑领域的内聚性，使得划分在一个领域中的“事物”具有比较密切的联系。4.1.4 识别信息源 识别信息源是领域工程的另一个重要的准备活动，信息源即整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、用户调查和市场分析、领域演化的历史记录、相关领域的领域工程结果等。其中，现有系统是最重要的信息来源。这里指的“现有系统”可以包括系统在生命周期中各个S J/Z 1 1 2 8 9-2 0 0 3阶段的表现形式，即不仅包括源代码和可运行的实体，还包括分析文档、设计文档、测试计划、测试记录、演化记录等多种内容。这些内容对于进行领域分析和领域设计是非常重要的。对于分析和设计文档缺乏 或不完整的 系统，可以先对现有系统进行逆向工程，恢复系统的 分析和设 计，用于领域分析和以 后的整个领域工程过程。逆向工程的理论和技术超出了本指导性技术规范的范围，不再赘述口 在领域分析阶段识 别的信息源，要在领域工程文档中 显式地说明。信息源中的 现有系统已 经在确定领域范围时进行了应用，因此，要在两者之间建立起交叉引用，即维护两者间的可追踪性。4.1.5 制订领域工程的实施计划 与其它软件开发活动一样，实施领域工程需要制订计划，并需要在领域工程的全过程进行项目管理。4.1.6 进行领域工程方法的 培训 领域工程师向管理者和领域工程的参与者介绍领域工程的观点、方法和预期的收益，可能的话，用实例 加以 说明。这样做，一方面确立管理者的信心，争取管理者的支持，另一方面使领域专家了 解领域工程，有利于领域工程的顺利实施。4.2 管理问题 领域 工程中的管理问题主要涉及资源投入等方面。4.2.1获得管理者的支持 实施 领域工程、开展系统化的软件复用，是一 个技术迁移的过程。如前所述，实施领域工程、建立复 用基 础设施需要大量的投入，而预言其收 益却是比较困 难的，而且实施领域工程后，软件开发组织的软 件开发 方式、人员组织等都可能会发生变化，因此，实施领域工程需要获得管理者相当的 支持。4.2.2 获得必须的资源 实施领域工程需要各种资源。在领域工程的实施过程中，当需要某种资源时，要保证该资源是可用的。其中领域专家是非常重要的。从上述对领域专家的要求可以看到，领域专家对于软件开发组织是非常重要的，他们常常担负着很多责任，因此，必须保证他们有足够的时间和精力参与领域工程的工作。领域分析5.1 目标与产品 领域分析是领域工程的第一个阶段，这个阶段的主要目标是获得对于目标领域的问题域和系统责任的认识，并将这种认识显示地表示出来。领域分析阶段的主要产品是 领域分析模型。领域分析模型由以下三个部分构成:5.1.1 领域需求定义 领域需求定义描述领域需求。与应用工程中的需求定义类似，领域需求定义应使用户和软件开发人员都能够理解，因此应采用自然语言，并且以在问题域中比较 自 然的方式进行组织。与应用工程中的需求定义不同的是，在领域需求定义中 要说明 所描述的需求的变化性，并且要有一个专门的 部分说明这些具有变化性的需求间的关系，在“问题与决定”部分要说明确定需求变化性时遇到的问题和决策的理由。对于比较 重要，或者比 较特殊的需 求，还要说明其信息来源。可以采用如下的 记法表示需求的变化性。对于可选的需求在需求后加注形如(0 2)的 标记，其中 O表示该需 求是可选的(O p ti o n a l),O后面的 数字是为便于在文档中的 其它部分引 用该需求而定义的 序号。对于多选一的需求在需求后加注形如(A l-2)的标记，其中 A表示该需求是一组多选一的(A lt e rn a ti v e)需求中的一个，A后面的第一个数字是为这一组多选一的需求定义的序号，第二个数字是该需求在该组中的序号。5.1.2 领域面向 对象分析模型 领域面向对象分析模型以规范的形式表达该领域的用户需求 与应用工程中的面向对象分析模型类似，面向 对象领域工程方法中的领域面向 对象分析 模型也分为以 下几个部分，每个部分中都 可能具有变化性，在“详细说明”部分要说明这些具有变化性的元素间的关系。a)类图描1*了樟型中有哪几类对象，每一类对象的内部构成以及各类对象与外部的关系。类图中 S J/Z 1 1 2 8 9-2 0 0 3 的类、属性、服务及各种关系等元素都可能具有变化性。对于这些变化性的表示将在下文中介 绍;b)主题图画出了系统中的主题。运用粒度控制的原则，将类组合为数量较少的几个主题，可以使 得模型的开发者和使用者都能在不同的粒度层次上表示或理解模型;c)U s e c a s e 和交互图 是面向 对象分析模型中的另一补充模型。U s e c a s e 采用自 然语言描述活动者 与系统进行交互时双方的行为。在领域分析模型中，u s e c a s e 可能是具有变化性的。交互图是 一种详细表示对象之间以 及对象与系统外部的活动者之间动态联系(即 行为依赖关系)的图形 文档。面向对象方法建议，针对每个u s e c a s e 画一个交互图，其中只包括与当前的u s e c a s e 有 关的对象;d)详细说明 包括对 模型中从全局到局部所有需要说明的信息。详细说明的组织，采用从整体到局 部的方式，分为三个层次:“系统说明”对整个模型作一些必要的说明;“主题说明”说明每个 主题描述一组什么事物，或解决一个什么问 题;“类描述模板”详细说明每个类。在这三个层 次中，都有可能要说明模型中的变化性。如主题说明中可以说明某个主题是可选的，类描述模 板中可以说明 某个类或某个属性是可选的。具有变化性的 元素之间的依 赖、互斥关系，也要在 类描述模板中说明。5.2过程 领域分析阶段的主要活动及过程如图3 所示。注建立领域需求定义确定领域中共同的需求确定领域中需求的变化性确定具有变化性的需求间的关系【蔺 赢鑫暴厂一卜 一一 II I才 片 丰-j-幸公:_ 二二 二 二 二 二 二_!确 定术 语确 定解 释确定同义词图3领域分析 从整体上看，领域分析阶段主要有三项活动:建立领域需求定义、建立领域面向对象分析模型和建立领域术语字典，其中前两项活动构成领域分析的主线。一般地，在领域分析阶段应首先建立领域需求定义，然后建立领域面向对象分析模型。建立领域术语字典是在这两项活动中穿插进行的，即在建立领域需求定义或建立面向 对象分析模型的过程中，可以 根据需要随时在领域术语字典中定义术语。在建立领域需求定义的过程中主要有三项活动:确定领域业务模型、确定领域业务过程和确定领域需求。它们通常是顺序进行的。在建立领域面向对象分析模型的过程中除了要建立面向对象分析模型以外，还要建立面向对象分析S J/Z 1 1 2 8 9-2 0 0 3模型与领域需求定义的可追踪性，这两项活动是以前者为主穿插进行的，即在建立分析模型的过程中可以随时建立与需求定义的可追踪性。在领域术语字典中定义术语一般有三个步骤:确定术语、确定解释和确定同 义词。它们通常是顺序进行的。如上所述，领域工程过 程是反复的、逐渐精化的 过程，作为其中一个部分的领域分析过程也是如此。其中所包含的各项活动并不是严格的顺序关系。在建立面向对象分析模型的过程中，就可能返回到建立领域需求定义的活动中，对领域需求定义进行补充和完善。三项主要活动内部的各项活动也是可以进行反复的。在建立领域分析模型之后，要对领域分析的产品进行复审，其中一个重要的内容是，利用领域分析模型，固定其中的变化性，得到一个现有系统的需求模型。5.3 活动与指南5.3.1 建立领域需求定义 这项活动的主要信息来源是各个现有系统的需求定义。如上所述，当考察领域中现有系统的需求时，会发现这些需求的适用性体现出一定的变化性。建立领域需求定义的任务就是要明确该领域中的系统可能具有哪些需求以及这些需求的变化性。识别共同的需求 建立领域需求定义的活动应从识别领域中共同的需求开始。这些共同的需求是领域中比较稳定的成分，是一个领域区别于另一个领域的本质特征，是领域需求定义中首先应该表示的需求。上文已经讨论了统一术语对识别共同需求的作用，也强调了在这一活动中运用抽象原则的重要性。此外，现有的标准规范(如国际 标准、国 家标准、行业标准)等也是重要的 信息源。从建立领域需求定义的角度看，这些标准规范通常都以比较一般的方式，规定了领域中的系统应具有的共同的需求，而没有限制这些需求的实现方式。在识别共同需求的过程中，充分参考标准规范，将提高领域工程产品在未来新系统开发中被复用的可能。识别需求的变化性 在识别了领域中系统共同的需求后，注意力将转向识别需求的变化性。这项活动中主要的步骤是识别 具 有变 化性的需求，确定该可变需求的 类型(是可选的 还是多选一的)，确定该变化性的固定时间。在此过程中，有以下问题需要特别注意:a)当考察领域中系统的可变需求时，需求的类型划分并不是绝对的。随着问题域中业务策略的发 展和计算机科学技术的发展，需求的类型划分也会相 应地发生变化，过去是可选的需求，有可 能成为以后的系统中必须的成分，也有可能在以后的系统中不再需要。为适应这种情况，一方 面，需要对领域工程的产品进行维护和演化，尽可能保持它们与当前的业务和技术发展同步，另一方面，在领域工程中，在确定可变需求的类型时，除了以现有系统作为主要依据以外，要 尽可能地对未来的业务和技术发展进行预见。为做到这一点，在领域分析阶段，应由问题域中 的 专家(如领域中系统的有经验的 用户等)参加，与系统开发方面的专家一起，对领域的未来发 展进行预测;b)处理“几乎是必须的”需求。在确定可变需求的类型时，可能遇到这样的需求，在现有的系统 中它几乎是必须的，只有个别的系统没有这一需求。这时有两种可能的处理方式，需要对这几 个个 别的 系统进行仔细地考察后，确定采用哪种方式。如果这几个系统并不是领域中的典型系 统，如只是原型系统或示例性的系统，则应将该需求处理为必须的需求。如果这几个系统具有 一定的代表性，如实际上代表了某个应用系统维度的子领域，则可以将该需求作为可选的需求。在这两种情况下，都要将决策的理由记录在“问题与决定”部分中。对于那种只有个别系统具 有，而多 数系统不具有的需求，也应采用同 样的处理方法;c)软件开发组 织的需要是确定变化性时 需要考虑的重要因素。领域工程以 及对领域工程产品 进行1 0S J/Z 1 1 2 8 9-2 0 0 35.3.2.2 识别和表示模型中的变化性 与 建立领域需求定义时类似，在建立O O A模型时，也要首先关注模型中 具有共同性的、稳定的部分，建立起模型的骨千，然后再将注意力转向具有变化性的部分。领域需求定义中 的变化性将表现为O O A模型各个部分的 变化性，如某个u s e c a s e 可能 是可选的，某 几个u s e c a s e 可能是多 选一的，等等。本指导性技术规范将主要讨论O O A基本模型，即 类图中的变化性。O O A模型中的变化性可以表 现在以下许多方面:a)一个类可以是可选的，一组类可以是多选一的。b)类的属性可以是可选的，一组属性可以是多选一的。一组多选一的属性可能是不同名的，也可 能是同名的属性具有不同的类型。c)类的服务可以是可选的，一组服务可以是多选一的。还可能某个服务中的某些步骤是可选的。d)类之间的 关系也可能是可选的或多选一的。e)这些变化性是考虑单 个系统不会出现的 情况，因 此现有的O O A模型的表示方式中，没有能够直接表示这些变化性的 元素。这时一种理想的 情况是 采用支持领域工程的O O A建模表示法和相应的C A S E工具，来直接表示变 化性。本指导 性技术规范将主要讨论使 用现有的、面向单个系统开发的O O A建模表示法和相应的C A S E工具，来间接地表示这些变化性。这些变化性原则 上可以采用如下的 方式表达:可选的元素在元素名中 加注形如(0 2)的标记，一组多选一的 元素在元素名中加注形如(A l-1)的 标记。在类图中 还有一种情况，即某 个服务中的某些步骤是可选的或多选一的，我们称这种情况为“服务具有内部变化性”。这种情况无法用以上两种方式表达，这时 应在该服务的详细说明中进行描述，并在服务 名中加注形如(V 3)的标记，表示这个服务具有内 部变化性。在应用工程中，分析阶段应主要关注问题域和系统责任，在设计阶段再考虑与实现有关的问题。在领域 工程中，在领域分析和领域设计之间也应保持这种责任划分。在领域分析阶段建立O O A模型时，应努力得到一个直接映射问题域和系统责任的模型，而不应考虑与实现有关的问题。按照这个原则，在O O A模型中 表达上述变化性时，应尽可能采用O O A建模中 可用的 方式，按照问 题域的 本来面目 去表达。如，在领域分析阶段应不考虑有关选用的编程语言、数据库、图形用户界面等方面的问题，也不应基于实 现方面的考虑对模型进行调整和修改。在实践中，由 于领域专家通常都了 解领域中 系统的实现，因 此在建 立O O A模型时很容易加入实现方面的考虑，这就要求领域工程师进行必要的引导，避免得到受实现因素影响的模型。与领域需求定义中的情况类似，在 O O A模型中，对于模型中比较重要或比较特殊的变化性元素要说明其信息源;在详细说明部分要说明确定模型元素变化性时遇到的问题和决策的理由;在详细说明还要说明具有变化性的元素之间的关系;元素之间比较重要或比较特殊的关系也要说明其信息源。5.3.2.3 建立O O A模型与 领域需求定义间的可追踪性 在 领域需求定义中的需求与O O A模型中的元素(类、属 性、服务、关系等)之间 要建立起可追踪性，固定的需求追踪到固定的元素，可选的需求追踪到可选的元素，多选一的需求追踪到多选一的元素。这些可追踪性的建立是在建立 O O A模型的过程中穿插进行的。理想情况下，这种可追踪性应该是双向的，如由领域需求定义中一个可选的需求，可以找到 O O A模型中一组可选的元素，而由O O A模型中一个可选的元素，可以找到领域需求定义中一个可选的需求。但在实践中，建立双向的可追踪性代价较大。一种变通的方式是只建立一个方向的可追踪性，另一个方向的查找使用编辑工具或 C A S E工具进行支持。如对领域需求定义中具有变化性的需求，说明在 O O A模型中 有哪些元素(类、属性、服务、关系)与之对应。当需要从 O O A模型中的某个类查 找相关的需求时，使 用编辑工具(如M S W o r d)的 查找功能 在领 域需求定义中查找。对于这种方式可以进一步改进。由于领域需求定义中的一项功能需求常常需要多个类的对象协作来S J/Z 1 1 2 8 9-2 0 0 3进行初步的领域设计回口国口结合设计模式，实现变化性建立与领域分析模型的可追踪性复审图4领域设计过程 作为领域工程一个部分的领域设计过程也是反复的、逐渐精化的过程。其中所包含的各项活动并不是严格的 顺序关系。为保持图 形的 简洁，在图4 中没有表示出 各项活动之间这种反复的 关系。6.3 活动与 指南6.3.1 进行 初步的 领域设计 这 项活动的信息来源主要包括 领域需求定义、面向 对象的分析模型、领域中 现有系统的设计等。如上所述，同一个领域中的系统，在实现方面也常常是相似或相近的。进行初步的领域设计的任务就是建立一个 基础的O O D模型，初步地把握这些实 现方面的共性。在 面向 对象开发方法中，从O O A到O O D不是转换，不是细 化，而是调整和增补。基于领域工程与应用工程的密切关系，作为领域工程产品的 O O D模型也是对 O O A模型进行调整和增补得到的，也分为四 个部分。在这部分对建立O O D模型的 活动的 讨论中，与应用工程类似的 活动，如如 何得到问 题域部分、如何开发人机交互部分等，将不再赘述。在这部分将重点讨论领域工程中特有的问题 与 建立O O A模型 类似，这项活动也有两种可能的工作方式。一种是在现有系统的O O D模型中选择一 个作为基础，依据领域需求定义和O O A模型，参考其它系统的O O D模型，对这个模型进行补充和修改。这个作为基础的 模型应该是比较典型的，或者比较清晰、完整的。另一种是依据领域需求定义和O O A模型，逐步建立一个新的O O D模型，将现有系统的OO D模型作为参考。如果能够找到一个质量比 较高的模型作为基础，那么第一 种工作方式的代价会比较小，否则，就应该采 用第二种工作方式。如果在领域分析阶段建立O O A模型时，采用了某 个现有系统的O O A模型作为基础，那么，在领域设计阶段仍然采用那个系统的O O D模型作为基础，有助于这项活动的顺利进行。设 计是软件开发的 各个阶 段的 产品中非常重要的 一个部分，它集中 体现了 软件开发人员的创造力。领域工程的目的之一就是，将软件开发人员在开发同一个领域中的系统时逐渐积累的设计经验，显式地表达出 来，以便在未来的开发中复 用。因此，在建立O O D模型的过程中，要充分地参考现有系统的设计，采用已经在实践中经过验证的解决方案，从而保证得到的 O O D模型的正确性和可复用性。与此同时，在注意这一原则的基础上，要注意以下几个方面的问题。与建立 O O A模型时