SJ Z11289—2003面向对象领域工程指南 1

面向对象领域工程指南

SJ/Z 11289—2003

引    言

0.1  系统化的软件复用

    软件复用可以提高软件的质量和生产率，被认为是解决“软件危机”的现实可行的途径。复用包括个别式复用与系统化复用两种方式。

    在个别式的软件复用中，存在一组可复用构件，应用开发者对它们进行选择和复用。应用开发者的责任包括识别可能进行复用的机会，选择满足需要的构件或经过修改可以满足需要的构件，得到这些构件并利用它们组装成新的应用系统。在这种复用中，复用是在个人的，而不是在项目的级别是进行的，也没有定义复用的过程。

    在系统化的软件复用中，不但存在一组可复用构件，而且定义了在新的应用系统的开发过程中复用哪些构件以及如何进行适应性修改。由于一般性地识别、表示和组织可复用信息是非常困难的，因此系统化的复用将注意力集中于特定的领域，而且在系统化的复用中非常重视软件生命周期中抽象级别较高的产品的复用。在这种复用中，复用是在项目级别进行的，定义了复用的指南和过程，定义了度量标准以衡量复用的效率。

    与个别的软件复用相比，系统化的软件复用对于提高软件的质量和生产率具有更大的作用。由于将注意力集中于特定的领域，使得软件开发组织可以获得对该领域的深入了解，对于可复用信息的识别和表示会比较容易和准确，在此基础上定义的复用指南会对复用过程较有帮助。完整定义的复用过程和对复用的度量，使得复用可以比较规范和系统化，从而有助于实现软件开发组织实施复用的预期目标。

    同时，实施系统化的软件复用也有较大的风险。实施系统化软件复用的软件开发组织需要解决一系列技术和非技术的问题，例如，分析本组织的需要，定义适合这些需要的复用过程，调整人员的组织方式，建立度量标准以衡量复用的效率，并据此调整复用过程，估计投资和收益，建立特定领域的可复用构件，等等。这些行为需要较大的前期投资和整个软件开发过程和原则的变化，而预言这些投资的回报却是困难的。

    在系统化的软件复用中，充分的可复用信息的存在是非常重要的。这些信息需要被显式地表示，以便在开发过程中被复用。这些可复用信息，和为方便地定位和操作它们的一些辅助信息一起构成了复用基础设施(Reuse Infrastructure)。复用基础设施也是基于特定领域的。

0.2领域工程

  系统化复用的成功依赖于很多因素，其中领域工程是系统化的软件复用成功的关键。这主要表现在以下三个方面：

  a)  复用基础设施的形成是通过领域工程实现的。通过领域工程，将关于一个领域的知识转化成为一组规约、构架和相应的可复用构件。由于这些信息来自于同一领域中现有的系统，因此它们具有较高的可复用性。这些可复用信息构成了复用基础设施的重要组成部分；

  b)  复用基础设施的演化也是通过领域工程实现的。当一个领域中的应用系统增加了的时候，通过领域工程，可以对这些系统进行新的分析，将新系统的特征也包含在规约、构架和可复用构件中，从而使本领域中系统开发的知识和经验尽可能地反映在复用基础设施中，以促进新系统的开发：

  c)  领域工程对于系统化的软件复用的意义还在于，领域工程不仅产生了可复用性较高的构件，而且通过产生构架定义了复用的时机和复用的上下文。这样就对开发者复用这些构件提供了有力的支持，使得复用变得规范、系统和高效。

  领域工程对领域中的系统进行分析，识别这些应用的共同特征和可变特征，对刻划这些特征的对象和操作进行选择和抽象，形成领域分析模型，依据领域分析模型产生出领域中应用共同具有的构架(即特定于领域的软件体系结构，缩写为DSSA)或生成过程，并以此为基础识别、开发和组织可复用构件。这样，当开发同一领域中的新应用时，可以根据领域分析模型，确定新应用的需求规约，根据特定于领域的软件体系结构形成新应用的设计，并以此为基础选择可复用构件进行组装，从而形成新系统，或利用生成过程由新的需求生成系统

持、影响和制约。

图1  领域工程的活动与产品

  这个阶段的主要目标是获得领域分析模型。在这个阶段之前需要进行一些准备工作，这些准备工作包括确定领域工程的目标：制订领域工程的规划；定义领域的边界；识别信息源等。领域工程的准备工作将在第4章进行详细地介绍。在此基础上，就可以分析领域中系统的需求，确定哪些需求是被领域中的系统广泛共享的，从而建立领域分析模型。当领域中存在大量系统时，需要选择它们的一个子集作为样本系统。对样本系统需求的考察将显示领域需求的一个变化范围。一些需求对所有被考察的系统是共同的。一些需求是单个系统所独有的。很多需求位于这两个极端之间，即被部分系统共享。

3.2.2领域设计

    这个阶段的目标是获得DSSA。建立了领域分析模型之后，就可以派生出满足这些被建模的领域需求的DSSA。由于领域分析模型中的领域需求具有一定的变化性，DSSA也要相应地具有变化性。它可以通过表示具有变化性的解决方案等来作到这一点。由于复用基础设施是依据领域分析模型和DSSA来组织的，因此在这个阶段通过获得DSSA，也就同时形成了复用基础设施的规约。

3.2.3领域实现  ，

    这个阶段的主要目标是依据领域分析模型和DSSA开发和组织可复用信息。这些可复用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。它们依据领域分析模型和DSSA进行组织，也就是领域分析模型和DSSA定义了这些可复用信息的复用时机，从而支持了系统化的软件复用。这个阶段也可以看作复用基础设施的实现阶段。

3.2.4领域分析模型

    领域分析模型描述领域中系统之间的共同的需求。领域工程的实施是基于这样一个事实：同一领域中的系统的需求必然具有显著的共性，其实现也常常具有共性。领域分析模型就描述了需求上的共性。称领域分析模型所描述的需求为“领域需求”(Domain Requirement)。

    领域分析模型是面向问题域的。领域分析模型包括了业务模型、业务过程和应用系统需求。但它不表示过程和功能如何实现。其中，业务模型反映了业务策略或操作概念，即，组织计划如何成功地进行操作。业务模型提供了定义业务过程的指南。业务过程定义了达到反映在业务模型中的目标所需的业务功能以及功能之间的流。业务过程是实现业务过程的应用系统的需求的来源。应用系统需求是为实现业

务过程所需的更加详细、更加技术性的功能。

    领域分析模型主要包含以下几个部分：领域术语字典、领域需求定义、面向对象分析模型(OOA模 

 b)  对于同一组事物采用不同的分类方式。

    在领域工程中，需要将以上这些不一致的术语统一起来。一方面，统一术语可以使领域工程的参与者有共同的语言，便于领域工程的实施。另一方面，术语归根到底是对事物的分类。统一术语的过程中，也就识别了领域中有哪些共同的事物，以及这些共同的事物可以有何种共同的分类方式，即识别了领域中的共同性。而为这样的一些事物（而不是另外一些事物）定义术语，常常是由于这些事物在当前处理的问题中比较基本或比较重要，那么，在统一术语的过程中识别的这些共同性，在领域中也常常是比较基本或比较重要的。

  3.3.2变化性

    当在整个领域，而不是单个系统的范围内考虑问题时，会发现从需求定义、分析模型直到实现都存在变化性口而且在这些具有变化性的成分之间还存在着依赖、互斥等关系。下面以需求为例讨论变化性和关系的基本情况。

    当考察领域中现有系统的需求时，会发现这些需求体现出一定的变化性。可以将这些需求分为可选的(Optional)、多选一的(Alternative)。

    可选的需求。部分现有系统具有这类需求，但并非全部系统都具有。未来的系统可能具有这一需求，也可能不具有这一需求。这类需求体现了领域中系统间的变化性。这种可选的需求可以成为定义应用系统维度的子领域的依据。可以将具有某种可选的需求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不能同时存在于一个系统中。上面讨论的多选一的需求是具有互斥关系的需求的一种特殊情况。

    以上对领域需求的变化性的讨论同样适用于领域的面向对象分析模型（即OOA模型）、DSSA。只是在OOA模型和DSSA中具有变化性的元素是类、属性、服务、关系等。

3.3.4变化性的固定

    当基于领域工程的产品进行应用工程时，为得到单个目标系统的各个阶段的产品，需要将变化性固定下来。需求上的变化性有不同的固定时间，在开发单个目标系统时，需要固定固定时间为开发时的哪些变化性。对于可选的需求，要确定是否选择该需求，对于多选一的需求，要确定选择哪一个需求。

    不同的变化性可能具有不同的固定时间。典型的固定时间包括开发时和运行时。开发时固定意味着在系统开发的过程中（分析、设计、实现、编译、链接）固定变化性。运行时固定意味着在系统开发告一段落，系统投入运行后，通过设置数据等手段，固定变化性。需求上的变化性的固定时间对于系统的设计有显著的影响。如一组多选一的需求的固定时间为运行时，就要求系统能够对这一组需求都进行支持，而且要提供在系统投入运行后从这一组需求中选择一个的手段。因此，在领域工程的实施中识别变化性

领域工程中的活动依据其组织方式，可以分为两种。

    一种是领域工程师组织的领域专家会议。基于会前的准备，领域专家在会议中就与被分析的领域相关的问题进行报告，然后领域专家在领域工程师的组织和引导下，基于一致的意见形成某种领域工程产品，或形成对于某种领域工程产品的开发计划，并对产品进行复审。

    另一种是会议以外的准备和开发工作。在会前，领域专家针对在会议中将涉及的与被分析的领域修改的问题进行必要的准备，领域工程师也要对这些问题进行尽可能的了解。在会后，要对会议上形成的一致意见进行整理和文档化，为会议上形成的领域工程产品增加细节，要依据会议上形成的开发计划进行具体领域工程产品的开发工作。这些工作主要由领域专家完成。

    在整个领域工程的实施过程中，这两种活动是穿插进行的。

4  准备工作

    领域工程是一项需要大量人力和资源投入的活动，因此，除了本指导性技术规范将作为核心内容进行介绍的领域分析、领域设计、领域实现等技术问题以外，还对准备工作进行介绍，例如：规划和管理等方面的问题。这些问题对于领域工程的实施是非常重要的，但它们不是领域工程的核心活动，本章将对这些问题进行简要的讨论。

4.1规划问题

    领域工程中的规划问题涉及确定领域工程的目标、确定领域工程的范围、制订领域工程的实施计划等方面。这些问题是在领域工程实施的初期就要遇到的，同时，由于领域工程过程是反复的、逐渐精化的过程，在领域工程的实施过程中，这些问题可能需要重新考虑。

4.1.1进行可行性分析

    基于对软件开发组织的情况、领域中现有的软件开发情况、领域的成熟程度、组织可用的资源等方面的考察，分析进行领域工程的可行性。这些需要考虑的问题包括：

    a)组织是否将在领域中继续开发新的系统，并且在新的开发中得益于领域分析模型、DSSA和可复用构件的存在？

    b)组织是否已经充分了解了领域中系统的开发技术，使得建立令人满意的领域分析模型和DSSA成为可能？

    c)  开发者是否已经通过开发领域中的系统获得了足够的经验，以保证领域工程的产品是可用的？

    d)  是否有（或将建立）机制以保证领域工程的产品真正地被使用？等。如果这些问题的回答都是肯定的，那么进行领域工程就可能是合适的。

4.1.2定义领域工程的目标

    定义领域工程的目标是领域工程中首先要进行的活动。基于不同的领域工程目标，为领域工程分配的资源、领域工程的实施过程和得到的产品都会有所不同。组织进行领域工程的可能的目标包括：

    a)  对问题域的描述和理解；    ．

    b)  对问题域、解空间以及两者映射关系的描述和理解：

    c)  基于现有的系统，开发DSSA和可复用构件，以利于新系统的快速开发：

    d)  对现有系统进行再工程，引入新的技术，同时尽可能领域现有系统的开发经验，以利于新系统的快速开发；

    e)  其它。

    可行性分析是定义领域工程目标的基础。为降低实施领域工程的风险，在定义目标时应根据软件开发组织当前的状况，在可用资源的约束下，解决组织面临的最重要、最迫切的问题，避免定义过多、过高的目标，将有限的资源分散。

4.1.3确定领域的范围

    通过确定领域的范围，可以明确分析的对象，领域工程过程中所有活动都要在这个范围内进行。如上所述，“领域”是指一组具有相似或相近软件需求的应用系统所覆盖的功能区域。因此，领域范围的确定既要考虑应用系统的方面，也要考虑功能区域的方面。

    在功能区域方面，要确定本次的领域工程活动将针对哪个或哪些功能进行。这里要注意的是，这些功能应具有内在的联系，一个指导性的原则是这些功能与一组共同的数据相关。如果将一组没有内在联系的功能结合为一个领域，进行领域工程，将使得领域工程的目标较为发散，得到的结果将缺乏整体性和一致性。

    在应用系统方面，要确定本次的领域工程活动将对哪些应用系统进行分析。如果被分析的系统过少，分析的结果是否适用于其它系统或预期的系统，就缺乏可靠的依据。因此，被分析的领域应该至少有三个现有的系统。确定作为分析对象的系统之后，在领域工程中由这些系统得到的信息，应该说明是由哪个或哪些系统得到的。

    图2描述了在两个维度上确定领域范围的活动。

图2确定领域范围

    在整个领域工程的过程中，有可能将整个领域划分为几个不同功能区域上的子领域。这时，在各个功能区域上所选择的系统可以是不同的。由于整个领域工程过程是反复的、逐渐精化的过程，因此从领域工程的实施过程中，可能进行多次的范围确定。确定后的领域范围，要在领域工程文档中显式地说明。

    确定领域范围时要考虑以下方面的问题：

    a)领域工程的目标；

    b)  进行领域工程的可用资源。这里所指的资源包括时间、人力、财力等方面。当资源比较充足时，可以使目标领域包含较大的功能区域和较多的现有系统。反之，则应选择较小的功能区域和较少的现有系统。基于领域工程的目标，功能区域变化的余地可能较小，而现有系统变化的余地可能较大；

    c)  充分考虑领域的内聚性，使得划分在一个领域中的“事物”具有比较密切的联系。

4.1.4识别信息源

    识别信息源是领域工程的另一个重要的准备活动，信息源即整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、用户调查和市场分析、领域演化的历史记录、相关领域的领域工程结果等。其中，现有系统是最重要的信息来源。这里指的“现有系统’’可以包括系统在生命周期中各个阶段的表现形式，即不仅包括源代码和可运行的实体，还包括分析文档、设计文档、测试计划、测试记录、演化记录等多种内容a这些内容对于进行领域分析和领域设计是非常重要的。对于分析和设计文档缺乏或不完整的系统，可以先对现有系统进行逆向工程，恢复系统的分析和设计，用于领域分析和以后的整个领域工程过程。逆向工程的理论和技术超出了本指导性技术规范的范围，不再赘述。

    在领域分析阶段识别的信息源，要在领域工程文档中显式地说明。信息源中的现有系统已经在确定领域范围时进行了应用，因此，要在两者之间建立起交叉引用，即维护两者间的可追踪性。

4.1.5制订领域工程的实施计划

    与其它软件开发活动一样，实施领域工程需要制订计划，并需要在领域工程的全过程进行项目管理。

4.1.6进行领域工程方法的培训

    领域工程师向管理者和领域工程的参与者介绍领域工程的观点、方法和预期的收益，可能的话，用实例加以说明。这样做，一方面确立管理者的信心，争取管理者的支持，另一方面使领域专家了解领域工程，有利于领域工程的顺利实施。

4.2管理问题

    领域工程中的管理问题主要涉及资源投入等方面。

4.2.1获得管理者的支持

    实施领域工程、开展系统化的软件复用，是一个技术迁移的过程。如前所述，实施领域工程、建立复用基础设施需要大量的投入，而预言其收益却是比较困难的，而且实施领域工程后，软件开发组织的软件开发方式、人员组织等都可能会发生变化，因此，实施领域工程需要获得管理者相当的支持。

4.2.2获得必须的资源

  实施领域工程需要各种资源。在领域工程的实施过程中，当需要某种资源时，要保证该资源是可用的。其中领域专家是非常重要的。从上述对领域专家的要求可以看到，领域专家对于软件开发组织是非常重要的，他们常常担负着很多责任，因此，必须保证他们有足够的时间和精力参与领域工程的工作。

5领域分析

5.1  目标与产品

    领域分析是领域工程的第一个阶段，这个阶段的主要目标是获得对于目标领域的问题域和系统责任的认识，并将这种认识显示地表示出来。

    领域分析阶段的主要产品是领域分析模型。领域分析模型由以下三个部分构成；

5.1.1  领域需求定义

    领域需求定义描述领域需求。与应用工程中的需求定义类似，领域需求定义应使用户和软件开发人员都能够理解，因此应采用自然语言，并且以在问题域中比较自然的方式进行组织。与应用工程中的需求定义不同的是，在领域需求定义中要说明所描述的需求的变化性，并且要有一个专门的部分说明这些具有变化性的需求间的关系，在“问题与决定”部分要说明确定需求变化性时遇到的问题和决策的理由。对于比较重要，或者比较特殊的需求，还要说明其信息来源。

    可以采用如下的记法表示需求的变化性。对于可选的需求在需求后加注形如(02)的标记，其中0表示该需求是可选的(Optional)，0后面的数字是为便于在文档中的其它部分引用该需求而定义的序号。对于多选一的需求在需求后加注形如(A1-2)的标记，其中A表示该需求是一组多选一的(Alternative)需求中的一个，A后面的第一个数字是为这一组多选一的需求定义的序号，第二个数字是该需求在该组中的序号。

5.1.2领域面向对象分析模型

  领域面向对象分析模型以规范的形式表达该领域的用户需求。与应用工程中的面向对象分析模型类似，面向对象领域工程方法中的领域面向对象分析模型也分为以下几个部分，每个部分中都可能具有变化性，在“详细说明”部分要说明这些具有变化性的元素间的关系。

  a)  类图描述了模型中有哪几类对象，每一类对象的内部构成以及各类对象与外部的关系。类图中的类、属性、服务及各种关系等元素都可能具有变化性。对于这些变化性的表示将在下文中介绍；

  b)  主题图画出了系统中的主题。运用粒度控制的原则，将类组合为数量较少的几个主题，可以使得模型的开发者和使用者都能在不同的粒度层次上表示或理解模型；

  c)  Use case和交互图是面向对象分析模型中的另一补充模型。Use CaSe采用自然语言描述活动者与系统进行交互时双方的行为。在领域分析模型中，I1$e case可能是具有变化性的。交互图是一种详细表示对象之间以及对象与系统外部的活动者之间动态联系（即行为依赖关系）的图形文档。面向对象方法建议，针对每个llSe case画一个交互图，其中只包括与当前的USe case有关的对象；

  d)  详细说明包括对模型中从全局到局部所有需要说明的信息。详细说明的组织，采用从整体到局部的方式，分为三个层次：“系统说明”对整个模型作一些必要的说明；“主题说明”说明每个主题描述一组什么事物，或解决一个什么问题：“类描述模板”详细说明每个类。在这三个层次中，都有可能要说明模型中的变化性。如主题说明中可以说明某个主题是可选的，类描述模板中可以说明某个类或某个属性是可选的。具有变化性的元素之间的依赖、互斥关系，也要在类描述模板中说明。

5.2过程

  领域分析阶段的主要活动及过程如图3所示。