在软件生命周期过程框架中增加领域工程过程

1、第七章 在软件生命周期过程框架中增加领域工程过程7.1 简介领域工程过程实施复用的先决条件是收集高质量的、高可用性的资产（即，可复用的软件部件，如软件设计模型）。领域工程是指在提供那些应用于特定领域的资产的过程。“领域”这个概念被用来缩小实践复用的范围，使得在一个领域的范围内概念更易于理解、技术更容易实现、组织更容易管理。典型地，被IEEE 1517标准定义为“问题空间”1的领域代表的是组织的一个局部，这个局部具有实践复用的潜力。为了复用，组织究竟应该选择什么样的方式来对其自身进行分割根据生产线，还是业务功能，或是技术平台，抑或是其他的方法？这个问题留待标准的使用者选择判断。然而，标准的意图是

2、应该将领域定义得足够得宽泛，以使其可以包括那些在一定时期内能被应用于多个软件产品的资产。另外，由于我们期望组织可以选择在多个领域中实践复用，所以我们也期望将领域工程过程在组织应用多次。7.1.1 提供资产“领域”这个概念也提升了领域工程过程，使其超出了项目的层次。领域工程过程为多个开发或者维护软件产品的软件项目提供资产，这些资产将应用在这些项目所涉及的多个软件产品中。为了符合多个项目的需求，资产必须拥有公共属性，这些属性可以被项目所生产的多个软件产品共享和复用。IEEE 1517标准将领域工程归类为一个跨项目的生命周期过程，因为这个过程超越了单个项目的边界和持续期。7.1.2 生产者复用回顾第

3、三章中的论述，生产者复用关注的是如何为复用提供资产。实际上，生产者复用就是资产的生命周期。生产者复用在领域内应用的时候就称为领域工程。通常，生产者复用关注分析、设计、开发和维护资产。当在领域中应用的时候，生产者复用关注如何为该领域分析、设计、开发和维护资产。IEEE 1517标准的软件生命周期过程框架基础过程 支持过程 组织过程跨项目过程 领域工程 IEEE 1517标准在IEEE/IEA 12207的软件生命周期过程框架中增加新的过程分类和新的过程图7-1 在IEEE/EIA 12207标准的软件生命周期过程框架中增加跨项目过程分类和领域工程过程如图7-1，IEEE 1517标准扩展了122

4、07标准的软件生命框架，加入了称为跨项目过程的过程分类。在跨项目过程分类项中，IEEE 1517标准定义了领域工程这个过程来规约在领域的层次上执行生产者复用的需求。领域工程过程覆盖了为领域进行的资产开发和维护。在IEEE 1517标准中，领域工程的定义如下：一个为一类系统、子系统或应用程序定义范围（即领域的定义）、阐明结构（即领域构架）、构建资产（如：需求、设计、软件代码和文档）的基于复用的方法。领域工程可以包含下列活动：领域定义、领域分析、开发领域构架、领域实现。2标准指定领域工程师作为负责领域工程活动的团体。按照标准对“团体”的解释，领域工程师可以是个人或个人组成的小组。最可能的情况是，组

5、织以一个项目团队的方式实现领域工程师这个团体，该团队在领域工程项目初始的时候就已经成立了，并且在整个领域工程生命周期中一直存在。表7-1列出了IEEE 1517标准中领域工程过程的活动。这些活动可以被映射到复用生产者生命周期的不同阶段，它们的细节将在下面的章节中叙述。表7-1 领域工程过程中的活动活动名称活动描述过程实施l 建立、文档化和执行领域工程计划l 选择领域模型和领域构架的表现形式领域分析l 定义领域边界和与其他领域的关系l 标识领域软件开发人员的需求l 构建、文档化、分类、评估和提交领域模型l 构造、评价和提交领域词汇表领域设计l 建立、文档化、分类、评价和提交领域构架l 开发、文档

6、化和评估资产规约资产供应l 开发、文档化、分类、评估和提交资产资产维护l 分析资产修改的要求，选择资产修改的方案并使该方案获得批准，实施资产的修改，提交修改后的资产。在每个活动的细节描述中，活动是根据其包含的任务来解释的。回顾前文，我们知道在标准中任务代表的是实施该活动的需求。下文中，将首先对任务进行讨论，然后给出实现任务的建议。7.2过程实施活动这个活动的目标是为领域工程做准备，主要包括建立领域工程计划，定义用于描述领域工程产品的格式，定义用于领域工程的技术和管理过程。7.2.1 建立领域工程计划IEEE 1517标准的过程实现活动的第一个需求（即任务）是建立和执行一个领域工程计划：8.1.

7、1.1 领域工程师要建立和文档化一个领域工程计划，如果可能的话，尽量复用一个可应用的领域工程计划模板，该计划定义了执行领域工程的资源和过程。该计划应该包括实施领域工程的标准、方法、工具、活动、任务和责任。为了建立领域工程计划，领域工程师应该和本领域中的领域专家、开发人员和软件产品的用户进行协商。领域工程计划应该被执行。3讨论根据领域的规模，一个较大、较复杂领域的领域工程可能是一件长期的，复杂的事情。把领域工程当作一个需要仔细计划的项目，对于确保领域工程的成功是非常关键的。这里所说的成功的领域工程能够促成该领域中有价值的资产被构建。实施建议领域工程计划中的一个重要元素是领域工程方法。为了选择一个

8、合适的领域工程方法，组织应该：1. 基于领域的目标，领域工程工作将产生的输出制品，可用的工具和领域工程团队的技能来进行选择；2. 考虑结合下列某种确定的领域分析方法：l SEI的面向特征的领域分析4，l STARS的复用库过程模型（就是我们通常所说的“三明治”方法（”Sandwich” approach）5，l 美国国防信息系统局/信息管理中心（DISA/CIM）的领域分析和设计过程6；3. 与领域工程团队中的领域工程师和领域专家一起评审所选择的领域工程方法；4. 领域的目标涉及到进行领域工程的目的。进行领域工程的目的是：l 获取对领域的理解，即，基本的公共概念和词汇表；l 决定领域中是否有足

9、够的公共属性保证在领域中实践系统化复用；l 提供一组在领域中能被用于构建软件产品的具有高可复用性的资产。虽然标准中没有特别提到，组织还是被建议要明确定义领域工程的目标，并将其作为领域工程过程实施活动的一个部分。对领域目标的一个清楚定义对于开发一个合适的领域工程计划是非常关键的。在领域工程计划中包括领域目标会确保领域工程团队的所有成员和被领域工程影响的人员对目标有一个共同的理解。领域工程计划也应该把领域工程当作一个必须被完全管理的项目。因此，领域工程计划应该包括项目的约束条件，如预算、进度表和资源。资源应该包括进行领域工程所需的技术资源和非技术资源。技术方面，标准要求标识所需的工具、方法和标准。

10、非技术方面，应该定义活动、任务和职责。领域工程团队应该对领域工程项目负责（如图7-2）。领域分析团队的成员应该扮演下列的角色并具有相应的技能。团队的某一个成员可以同时扮演下列的多个角色，并拥有多个相应的技能：1. 系统/业务分析员，分析建模和数据综合（data synthesis）的专家；2. 数据管理员，负责所有的数据字典和命名标准；3. 信息架构员，全面了解属于领域的企业或业务单元的信息/企业体系结构；4. 领域专家，对领域有专家级知识和理解；5. 终端用户和软件开发人员，全面了解系统的目前需求和未来需求；6. 复用促进人（reuse facilitator），有领域分析的经验。IEEE

11、1517标准定义“领域专家”是“对领域非常熟悉的、能向领域工程师提供细节信息的个人”。7领域专家可以包括知识丰富的最终用户和软件专业人员（即在软件产品开发工作中有经验的软件系统开发人员和维护人员）。他们应该知道该领域中规划的未来系统的重要属性是什么。领域专家是领域信息的关键来源，因此也是领域分析团队的一个关键成员。业务分析员数据管理员 终端用户 信息架构员软件开发人员复用促进人图7-2 领域工程项目团队的成员最后，领域工程计划应该标识用于支持领域工程项目的工具。我们需要不同类型的工具来支持分析、设计和实现活动。例如，为构建和分析战略性计划模型（strategic planning models

12、）和信息体系结构提供支持的工具，如实体关系、数据流、对象模型图工具和字典工具，在进行领域分析时是非常有用的。另外，数据综合工具、数据和过程逆向工程工具、程序代码分析器、流图工具、复杂度量工具、过程逻辑和数据优化重组工具在进行领域分析时也是非常有用的。此外，仓库、浏览器、目录工具和配置管理工具是存储和管理领域模型、领域构架和资产所需的工具。当然，特定领域工程项目的到底需要什么样的特定工具取决于模型的类型、被分析的代码和所选的描述领域模型和领域构架的表现形式（representation forms）。7.2.2 选择领域模型和领域构架的表现形式在领域工程过程的过程实施活动的第二个任务中，IEEE

13、 1517标准要求选择领域模型和领域构架的表现形式：8.1.1.2 领域工程师应该按照组织的复用标准，与领域中的领域专家、软件产品的开发人员和用户商议，以选择领域模型和领域构架的表现形式。8讨论根据IEEE 1517标准，领域模型和领域构架的定义如下：领域模型：领域分析的产物，提供了领域需求的表示。领域模型标识和描述了领域中的数据结构、信息流、功能、约束和控制。领域模型描述了领域中不同系统之间在需求上共性和特性。9领域构架：领域中系统的一般性结构或设计。领域构架包含那些满足领域模型中所规约的需求的设计。领域构架是设计的文档，相反，领域模型是需求的文档。领域构架：1）能够通过一些少量的调整来生成

14、领域中的软件系统的设计；并且2）为单个软件系统提供配置资产的框架。10领域模型是一般性的分析模型，领域构架是高层次的设计模型。它们一起为在领域中构建资产和软件产品提供起点和指南。因此，领域模型和领域构架的表现形式影响了为领域提供资产的领域工程方法的选择，在领域中构建软件产品的开发方法的选择，领域工程和软件开发工具的选择。实施建议为领域模型和领域构架选择的表现形式应该与领域分析设计方法和领域工程项目中使用的工具相适应。例如，面向特征领域分析（FODA）方法使用一组模型（实体关系模型、数据流图、状态转换图和结构图）11描述领域模型，另外一组模型（过程交互模型和模块结构图）描述领域构架。12领域模型

15、和领域构架的表现形式也应该和开发方法，以及用于开发领域中的软件产品的相应分析设计模型相适应。应该使领域模型和领域构架使用同样的表现形式，这样不但可以减少学习两种表现形式所带来的学习开销，还省去了从一种表现形式转换到另一种表现形式的麻烦，同时也减少了对支持领域工程和软件产品开发的工具的需求。一个公共的模型语言（如对象管理组织的UML）可以考虑作为领域模型和领域构架的表现形式。13 可以使用UML模型的一个组合（类模型、用况模型、序列/协作模型）来描述领域模型。更多的关于UML的信息参见第10章。7.2.3 定义技术和项目管理过程在领域工程过程的过程实施活动的第三个任务中，要求按照IEEE/EIA

16、 12207标准的过程规约来建立领域工程过程。此外，还需要在领域工程师和资产管理员之间建立沟通过程。8.1.1.3 领域工程师应该：a) 按照IEEE/EIA 12207.0-1996标准的文档过程对为这个过程建立文档；b) 按照IEEE/EIA 12207.0-1996标准的配置管理过程对领域工程的输出进行配置管理；c) 按照IEEE/EIA 12207.0-1996标准的问题解决过程来文档化和解决资产和领域工程过程中发现的问题和缺陷；d) 按照IEEE/EIA 12207.0-1996标准的联合评审过程进行联合评审，并使得该领域中的领域专家、软件产品的开发人员和用户介入到评审中来；e) 建

17、立一个过程，当由领域工程师开发的资产出现问题或者需要被变更的时候，使用这个过程来定义如何接收和解决这些问题，并向资产管理员提供反馈。14讨论这个需求是IEEE 1517标准使用已有的IEEE/EIA 12207标准，为与复用相关的过程提供规约的一个实例。如图7-3所示，领域工程过程使用了IEEE/EIA 12207标准的支持过程，即文档化过程、配置管理过程、问题解决过程和联合评审过程，来规约其文档化、配置管理、问题解决和联合审核方面的需求。领域工程过程的另一个需求是指定提供和资产管理员沟通的方法。这个需求是很清楚的，因为IEEE 1517标准将资产的开发和管理分成了两个独立的角色，以平衡生产领

18、域资产的责任和对领域资产的控制。领域工程师这个角色负责资产的开发和维护，资产管理员这个角色则负责资产的管理。为了有效地完成它们被指派的职责，两个角色之间需要有一个沟通渠道。IEEE 1517标准的软件生命周期过程框架基本过程支持过程组织过程跨项目过程文档化 领域工程配置管理问题解决联合审核图7-3 IEEE/EIA 12207标准的支持过程在IEEE 1517标准的领域工程中的使用实施建议图7-4显示了领域工程师和资产管理员对的领域信息的沟通。- 领域模型- 领域构架- 领域资产- 资产修改方案- 实施计划- 已修改的资产- 资产修改请求- 资产问题报告- 资产复用信息- 资产版本信息- 资产

19、引退信息- 资产分类模式- 资产接收和验证过程资产管理员（资产管理过程的代理）领域工程师（领域工程过程的代理）图7-4 领域工程师和资产管理员之间的通信渠道7.3 领域分析活动和传统的软件系统生命周期一样，领域工程生命周期包括分析、设计、实现和维护活动。只是，周期是应用到资产上的，这些资产包括领域模型、领域构架和其他类别的用于构建领域中的软件产品的软件部件。领域分析是资产生命周期中的分析阶段。IEEE 1517标准定义领域分析为：（A） 对领域中系统的分析，以发现它们之间的共性和特性；（B） 一个过程，通过这个过程来标识、捕获和组织开发软件系统时使用的信息，从而使得这些信息能在创建领域中的新系

20、统时被复用；（C） (A)和（B）中的过程的结果。15领域分析活动对领域中已有的和预期的软件产品的特征进行分析、抽象，并对其建模，以确定这些产品在什么地方是相同的（共性），以及什么地方是不同的（特性）。这些信息被领域分析的过程中产生的一组领域模型所捕获。领域模型的目的是：1 辅助理解领域的关键共性元素和这些元素之间存在的关系；2 定义领域词汇表，建立对领域的共同理解；3 捕获领域中的关键共性和特性特征、性能、概念和功能。7.3.1 定义领域边界IEEE 1517标准要求领域分析活动的一个输出结果是对执行领域工程过程的领域的边界所作的定义：8.1.2.1 领域工程师应该定义领域的边界和该领域与其

21、他领域之间的关系。16讨论定义领域的边界时应该思考哪些功能、特征、属性和性能应该被包括在这个领域中，哪些不应该包括在该领域中，并根据结论来定义这个领域的边界。同样，诸如“一个领域是另一个领域的子集”这样的关系也应该建立。上述这些信息，在标准中被定义为“领域定义”。标准要求生成“领域定义”信息，如果有必要，还可以重新定义领域模型。实施建议领域边界应该通过与组织中已定义的其它已有领域进行比较，并采用迭代的方式不断精化。来自市场分析、用户需求、软件开发人员和领域专家的信息可以被用来确定领域的边界。同样，还应该对复用程序实施计划进行复审，因为计划中包含了对组织中领域的标识。领域的边界应该和复用程序实施

22、计划中对该领域的说明相符，如不相符，则它们其中之一或者两者都需要重新定义或调整。上下文模型、数据流模型或对象模型可以被用来表示领域的边界。17数据流模型或结构图可以用来表示领域之间的关系。18用来表示领域边界的模型应该分别与所选的表示领域模型和领域构架的表现形式相同。7.3.2 标识开发人员的需求IEEE1517标准要求的另一个领域分析任务是标识构建领域中软件产品的软件开发人员的需求：8.1.2.2 领域工程师应该标识领域中软件产品的开发人员的当前的和期望的需求。19讨论领域中的软件产品的开发人员是领域工程成果的初始用户。因为他们具有开发领域中软件产品的经验，所以这些软件开发人员可能在标识在他

23、们的开发工作中最有用的资产时具有发言权。软件开发人员在过去的软件产品开发中曾经使用过的资产极有可能在这些产品未来的新版本及其执行中也会用到，同样，这些曾经使用过的资产也极有可能在那些与过去的软件产品十分相似的新软件产品中用到。那些被软件开发人员认为在某个领域中，对构建目前的和未来的软件产品有用的资产应该被用来帮助定义或提炼领域的边界。实施建议应该与领域软件产品的开发人员和维护人员座谈，来标识他们认为对软件产品最有用的资产。应该评价这些领域软件开发人员的经验和专门技术，并以此来判断他们是否有在工作中使用资产所需的技能。基于这些信息，领域边界可能需要被调整以确保领域工程项目可以产生开发人员和维护人

24、员在他们的工作中使用的资产。7.3.3 构建领域模型在领域分析活动的这个任务中，要求领域工程师构建领域模型：8.1.2.3 领域工程师应该使用过程实施活动中选择的表现形式来构建领域模型。20讨论领域模型捕获了领域的静态的和动态的特性，以及领域词汇表。他们的目的是协助理解领域的关键概念、特征、性能、功能，以及这些特性之间的关系。领域模型是领域资产的基本规约。领域分析产生领域模型，并且可以把领域分析看作领域中当前和未来软件产品的需求分析的一种形式。实施建议典型地，领域分析是采用自上而下/自下而上相结合的迭代方式执行的。在自上而下的分析中，主要是研究已有的系统和方法，标识其共性结构。相似的共性结构被

25、归在一个组中，供进一步的研究。标识这个组中的共同的和不同的方面，并以此为基础建立表现组属性的基本结构。在领域分析的自下而上的部分中，标识系统和模型中的通用资产。也要标识通用资产之间关系，如一般特殊关系（“is a”）和聚合关系（“consists of”）。将通用资产映射到自顶向下分析中定义的基本结构中。7.3.4 构造领域词汇表在领域分析活动的这个任务中，要求领域工程师构造领域词汇表：8.1.2.4 领域工程师应该构造领域词汇表，以提供描述重要领域概念和领域中相似或通用资产之间的关系所需的术语。21讨论领域词汇表示标识领域中软件产品之间存在的共性的基础。领域词汇表能使领域工程师和软件开发人员

26、使用相同的语言进行交流，因此更容易辨识和理解那些在构造领域中的软件产品时所用到的作为通用构建块的资产。实施建议可以通过和领域专家讨论，并分析在软件系统文档、分析和设计模型以及企业和业务模型中存在的概念、关键词、名词和动词，生成领域词汇表。领域词汇表应该在创建领域模型的迭代过程中不断进行精化。7.3.5 分类和文档化领域模型在领域分析活动的这个任务中，要求领域工程师对领域模型进行分类和文档化：8.1.2.5 领域工程师应该分类和文档化领域模型。22讨论领域模型在领域模型中就已经存在资产了中包含的所有类别的资产都只能在复用消费者理解的基础上才有被复用的可能。文档化的作用就是提供理解的方式，向复用消

27、费者提供对资产的清楚标识和解释。负责构建领域构架和其他领域资产，并维护领域中软件产品的领域工程师是领域模型的主要复用消费者。即使资产有很好的文档，如果难以找到它，它可能仍然难以被复用。因此，资产不仅必须被文档化，还要有很好地组织。需要将资产进行分类，划分出一个易于理解的结构，以使复用消费者快捷容易地找到资产。IEEE 1517标准定义分类为“易于从复用库中查询和提取资产的资产组织方式。”23实施建议对于任何资产（包括领域模型）而言，它的文档应该包括下列信息：资产是做什么的、资产的特性、使用资产的需求。此外，文档还应该包含复用所特需的信息，如复用的条件和复用的方法。表7-2列出了建议资产文档中包

28、含的各类信息。表7-2 资产文档信息的种类l 资产名称，符合组织的命名规范l 关于资产功能的简短描述l 资产所属的领域l 使用资产的基础设施，包括技术环境需求、性能约束和法律约束l 测试，包括测试计划、测试案例、测试脚本、测试数据集和测试工具l 资产的质量（例如，错误率）l 改善资产的建议，并将建议表述成可复用的形式l 资产使用历史记录l 资产的分类信息分类模式可以很简单，仅包含资产的名称，也可以更加复杂，例如由一组刻面值组成的刻面分类模式。在第5章中，对分类模式进行了讨论。标准将建立领域分类模式的职责指派给了资产管理员，并将使用分类模式分类资产的职责指派给了生成或获取资产的领域工程师。7.3

29、.6 评价领域模型和词汇表IEEE 1517标准要求评价领域模型和领域词汇表：8.1.2.6 领域工程师应该依照选择的模型技术的规定和组织的资产接收与验证过程对领域模型和领域词汇表进行评价。评价的结果应当文档化。24讨论这个任务明确的指出了，标准要求全面核查领域模型的质量。作为领域的分析模型，领域模型在复用消费者和复用生产者之间扮演着重要的角色。对于复用生产者而言，领域模型影响领域构架和其他领域资产的开发。例如，领域模型被用于确定资产的复用潜能（即，哪些是可以用于开发领域软件产品的最有价值的资产）。有最大复用潜能的资产是领域工程后续创建或获取活动的焦点。对于复用消费者而言，领域模型影响领域中软

30、件产品的开发。例如，在建立软件产品项目计划的时候，可以使用领域模型标识复用的机会，并且为软件项目设定复用目标的层次。也能在软件产品生命周期的分析阶段，使用领域模型核查软件产品的需求规约的完整性和一致性。由资产管理员负责建立与管理组织的资产接收和验证过程。实施建议完成用于建立领域模型的自上而下/自下而上的领域分析活动之后，要通过执行以下活动对领域模型进行评价：1 核查领域分析活动中领域模型中定义的所有通用资产和关系。2 对领域模型进行冗余检查，确保没有冗余的资产或关系。如果在模型中发现冗余，需要使用公共的资产来替代冗余资产，以消除模型中的冗余。3 核查领域模型是否符合组织的所有模型标准和命名规范

31、。4 核查领域模型是否被适当的分类，是否有合适的文档。7.3.7 进行领域分析的联合评审IEEE 1517标准要求对领域分析进行正式的评审：8.1.2.7 领域工程师应该按照IEEE/EIA 12207.0-1996标准的联合评审过程对领域分析进行联合评审。软件开发人员、资产管理员、领域专家和用户应该参与评审。25讨论因为领域模型是领域工程过程的主要提交成果，所以应该从受领域模型影响的那些团体的各自不同的视角对领域模型进行正式评审。例如，软件开发人员将成为模型的复用消费者，资产管理员将在模型的整个生命周期里管理模型。领域专家和用户也要参与评审，确保领域模型正确捕获了领域的所有已知的关键概念。实

32、施建议领域分析评审的形式在IEEE/EIA 12207标准的联合评审过程中详细说明了。在用于评价诸如领域模型这样的软件产品时，IEEE/EIA 12207标准的联合评审过程是当成技术评审来执行的。它的作用是评价软件产品，以确保它的：1 完整性；2 与标准的符合性；3 与计划及获批准的变更的一致性。IEEE/EIA 12207标准联合评审过程包括两个参与对象：（1）被评审对象和（2）评审者。领域分析联合评审中，领域工程师被指定为被评审对象，领域专家、用户和软件开发人员被指定为评审者。7.3.8 向资产管理员提交领域模型IEEE 1517标准要求在领域工程过程中开发的或获取并获认同的资产要交给资产

33、管理员，资产管理员管理领域资产的使用：8.1.2.8 领域工程师应该将领域模型交付给资产管理员。讨论领域工程师的职责是为领域开发并维护资产，而不是管理资产的使用。当领域工程师完成了资产的开发或维护功能，资产的管理职责就要转交给资产管理员。实施建议被认同的领域模型应该和其他的领域资产一样提交给组织的复用目录和/或复用库，在那里，它能被复用消费者访问、更新和进行合适地维护。7.4领域设计活动IEEE 1517标准的领域设计活动的目标是生成领域构架和领域资产的设计规约。领域构架为使用资产构建软件产品提供了一个通用的、一般性的框架。如果领域模型可以被看作是理解领域共性的定义层面的设备，那么领域构架可以

34、被看作是使用资产构建领域中的软件产品时使用的一种的实现层面的媒介（implementation vehicle）。领域构架提供了：1 将资产组装成软件产品的大体结构；2 使用已有资产的一种促进机制；3 创建新资产的指导；4 理解领域中关键通用资产及资产之间存在的关系的辅助手段。领域资产是为适应领域构架而设计的。这样一来，领域构架是将资产组装成软件产品的“胶水”。标准也希望领域中的每个软件项目都能够基于领域模型，并从领域构架派生。7.4.1 生成领域构架在领域设计活动的这个任务中，如果领域构架存在就选择它，不存在就创建它：8.1.3.1 领域工程师应该依照领域模型，遵循组织的标准，生成领域构架，

35、并将其文档化。27讨论领域构架作为高层初始设计规约，被用于为领域中的每个软件产品生成设计。它提供了规范的框架，在此框架中，形式化的定义了构件的接口，以指导设计领域资产和软件产品。当创建这个领域构架时，作出了许多与系统运行相关的体系结构层面上的决定。当在领域软件产品的开发中复用构架时，就不需要再做这样的决定了。这样可以加快开发过程，并能消除构建冗余软件部件的现象。实施建议如果领域中的软件产品需要不同的目标环境，那么为该领域开发多个领域构架是可能是必要的。例如，需要不同的构架提供给分布式应用程序、单处理器应用或基于主机的应用。构架专家和有构建这种软件构架经验的软件开发人员可以利用他们的知识和经验来

36、帮助设计领域构架。领域模型也可以考虑作为领域设计的一个重要输入。设计模型的一般性结构是建立领域构架的基础。他们或者可以成为领域构架，或者可以成为领域构架中的子系统。和领域模型一样，领域构架必须被一般化、标准化和文档化，使得它能在构建多个软件产品时使用。下面列举一些推荐的一般化领域构架的方法：1 将实现上的依赖分离出来，使得容易辨认和改变实现（环境）细节，以适宜特殊软件产品的需求，或者满足新的环境和以后的技术需求。2 将构架分层，以使资产（如：过程和服务）可按应用特定的、操作系统特定的、硬件平台特定的等方式进行分层。这样，将使构架易于适应领域中特殊软件产品的特殊需求。283 在每一层，首先寻找适

37、合构架的通用资产，然后再以此为基础寻找适合构架的其它资产。例如，那些支持通信、用户界面、窗体管理、信息管理、事务管理和批处理控制的过程和服务应该定义为构架资产。许多这样的资产是依赖环境的，并且可以作为“水平”复用的实例，因为它们可以在那些共享相同系统环境需求的多个领域中使用。下面是标准化领域构架的推荐的方法： 1 标准化资产之间的接口（例如，应用系统和数据库管理系统之间的标准接口，应用系统和通信软件之间的标准协议）；292 关注子系统（例如，通信子系统）和它们之间的交互；3 使用标准化的建模语言，如UML。领域构架的文档应该包含以下信息：为复用构架所做适配调整的信息，什么时候可以复用构架，以及

38、构架的分类信息。表7-3列出了建立领域构架文档的建议。表7-3 领域构架的文档l 为复用构架所做适配调整的信息，指导复用消费者为构建特殊的软件产品修改或特殊化领域构架30l 什么时候可以复用构架，描述设计领域构架所需的特殊的硬件目标环境和特殊的开发工具（如：代码生成器、图形用户界面开发环境）l 领域构架的分类信息，使用领域资产管理员指明的分类模式对领域构架进行分类的信息（详细内容参见第5章）7.4.2 评价领域构架在领域设计活动的这个任务中，IEEE 1517标准要求对领域构架进行评价：8.1.3.2 应该按照所选择的构架设计技术和组织的资产接收与验证过程对领域构架进行评价。评价的结果应该文档

39、化。31讨论因为领域构架被用来指导软件产品和领域资产的开发，所以它的质量、完整性、一致性和对标准的符合程度都必须被仔细评价。建立和管理组织的资产接收和验证过程是资产管理员的职责，领域构架就是使用这个过程进行评价的。实施建议为了确定领域构架的可用性，应该至少和一个领域中存在的软件产品的设计进行比较，以判断领域构架是否能作为产品的初始设计。作为领域工程团队的成员，领域专家也应该审核领域构架。7.4.3 开发资产的规约在IEEE 1517标准的领域设计活动的这个任务中，关注点是生成领域资产的设计规约：8.1.3.3 对每一个被选中的，为复用而设计的实体，领域工程师应该开发并文档化资产的规约这里资产的

40、规约相当于12207中的详细设计报告。32讨论在这个需求里，标准指出，领域中所有可能的资产中只有一部分是将为复用而设计的。在领域工程中，一个选择性的复用策略（a selective reuse strategy）通常是被重视的。选择性的复用将挑选出有最高复用潜力的资产，进而开发它们或获取它们。这些资产：1 能在领域的软件开发和维护项目中被最频繁地使用；2 为组织提供最大的利益（例如：节省费用、节省时间、减少项目失败的风险、强化标准）；3 能被用于构建和维护对组织最重要的策略性的软件产品；4 是复用消费者（例如，软件开发人员和软件维护人员）所需要的，即是已知的资产需求。为了控制领域工程项目的费用

41、和时间，只需要为高复用潜力的资产实现设计规约。实施建议为了创建特定资产的设计规约，组织应该研究领域中目前在构建或再工程的软件产品的共性（如公共特征或服务）。也应该询问开发人员，获取他们的建议和意见，评审目前在市场上有销的资产。表7-4显示了应该提供的资产的设计规约信息。此外，组织应该考虑标识以下信息，以辨识领域中的哪些资产具有最高的复用潜力：1. 资产被用于构建或维护某领域中的软件产品的可能的次数；2. 可以复用该资产的软件产品的战略上的商业重要性；3. 在这些软件产品中可能存在的相似性和差异性；4. 这些差异对资产复用潜力的影响，和复用该资产的收益；5. 资产在复用中适应可能的差异和捕获可能

42、的相似性的能力；6. 验证资产的复用性和整体质量的容易程度；7. 生成/再工程/获取资产的成本；8. 与制造/提供资产所需的时间相比，资产生命周期的期望值；9. 管理和维护资产的成本；10. 为了偿还其成本，资产需要被使用的次数；11. 使用资产提供的商业效益（例如：加快投入市场的时间）；12. 使资产适合领域构架的容易程度。表7-4 资产设计规约的信息l 资产的功能： 资产期望它的客户提供什么 资产能为客户产生什么 资产的性能特性 资产需要的共性和特性的范围 对资产所需目标环境的假设l 使用资产的限制7.4.4 评价资产规约IEEE 1517标准要求评价资产规约：8.1.3.4 对每一个特定

43、的资产，应该按照IEEE/EIA 12207.0-1996标准的5.3.6.7节和组织的资产接收与验证过程，评价资产的规约。评价的结果应该文档化。33讨论除了指定组织的资产接收和验证过程，标准还阐明了IEEE/EIA 12207标准的软件评价要求要被用于评价资产的规约。在IEEE/EIA 12207标准的开发过程的软件详细设计活动中，软件详细设计的评价范围是：1. 设计到需求规约的可追踪性；2. 与构架设计的一致性，以及各部分之间的一致性；3. 采用的设计方法及标准的适合性；4. 软件测试和维护的可行性。实施建议资产的可追溯性能通过将资产映射到领域模型的适当位置来论证。能通过验证资产适合领域构

44、架，及资产接口符合领域标准来表明资产的一致性。能通过论证资产规约符合领域资产管理员提供的资产接收和验证过程来表明设计方法和标准的适应性。通过论证资产文档的完整性来表明资产的可测试能力和可维护性。7.4.5 进行领域设计的联合评审IEEE 1517标准要求对领域设计进行正式的评审：8.1.3.5 领域工程师应该按照IEEE/EIA 12207.0-1996标准的联合评审过程进行领域设计的联合评审。软件开发人员、领域专家和资产管理员应该参与评审。34讨论领域设计产生的制品是领域工程项目成功的关键，也是使用领域资产开发软件产品的关键。对领域设计活动和它的制品进行正式的评审能帮助保证领域工程项目是可跟

45、踪的，并能保证领域设计的输出是完整的和高质量的。实施建议IEEE 1517标准使用IEEE/EIA 12207标准的联合评审过程来规约领域设计评审的需求。使用联合评审过程评估领域设计活动的状态和结果。执行该活动的项目管理评审是为了判断该活动是否按照领域工程计划进行，是否有足够可用的资源以满足活动的需求，是否存在导致领域工程项目冒较大风险的问题。此外，对领域构架和资产设计规约进行技术评审可以确保它们的完整性，和标准的一致性，并且可以确保它们已经可以为领域资产和软件产品的开发提供适当的输入了。7.4.6 提交领域构架IEEE 1517标准要求向负责管理领域构架的资产管理员提交被认可的领域构架：8.

46、1.3.6 领域工程师应该向资产管理员提交领域构架。35讨论由于领域构架的作用是用来开发领域中的所有软件产品，所以领域构架必须得到适当的管理。同时，这也和采用基于复用的开发方法（如，基于构件的开发）有着密切的关系。领域构架的管理职能是指派给资产管理员的。实施建议应该将领域构架提交到组织的复用目录和/或复用库，在那里，领域构架可以被软件开发人员、维护人员和其他的领域工程师访问，并且可以被更新和维护。7.5资产供应活动在IEEE 1517标准领域工程过程的这个活动中，那些被认为对某个领域中的软件产品具有复用潜力的资产，通过获取过程或开发过程被提供了。这些资产将被作为构建块（building blo

47、ck）来组装该领域中的软件产品。这些资产可能是已有的，也可能需要被开发。对于那些需要被开发的资产，需要创建它们的规约。7.5.1 开发或获取资产IEEE 1517标准要求通过两种方法提供资产：开发或获取：8.1.4.1 领域工程师应该通过两种方法开发资产（develop asset）：如果要获取资产，则需要进行获取过程（5.1条款）产生一个合同；如果要在内部开发资产，需要执行开发过程（5.3条款）。36讨论回顾IEEE/EIA 12207标准对软件产品的定义：“一组计算机程序、过程、可能相关的文档和数据”。37IEEE 1517标准把资产当作一种特殊的软件产品，因为资产的基本功能是用来构造其他

48、软件产品的构建块。虽然与一般的软件产品相比资产有其特殊性，但是开发或获取软件产品的一般需求也适合资产。因此，IEEE 1517标准使用开发过程和获取过程（见第四章）说明开发和获取软件产品的一般需求。此外，本活动加入了和开发或获取资产特别相关的任务。IEEE 1517标准的基本过程获取供给开发运行维护过程实施活动系统需求分析活动系统体系结构设计活动软件需求分析活动软件体系结构设计活动软件详细设计活动软件编码和测试活动软件集成活动软件合格性测试活动软件集成活动系统合格性测试活动软件安装软件接收支持活动图7-5 IEEE 1517标准开发过程中的活动IEEE 1517标准的基本过程获取过程供给过程开

49、发过程运行过程维护过程启动活动需求方案准备活动合同准备和更新活动供应者监控活动接收和完工活动图7-6 IEEE 1517标准获取过程中的活动图7-5中是组成IEEE 1517标准的开发过程的活动，这些活动可以应用到使用资产的软件产品开发中。图7-6是组成IEEE 1517标准的获取过程的活动，这些活动可以应用到获取软件产品所需的资产中。需要注意的是，在开发或获取资产时，不需要按照IEEE 1517标准执行所有的活动。标准允许用户取消一些活动来裁减这些过程，这样能更好的符合那些开发资产而不是开发软件产品的项目的范围、数量级、复杂度和关键性。实施建议资产是一种软件产品，这没有错，但是还应该看到资产

50、是一种特殊的软件产品，这个特殊的软件产品具有一些通常一般软件产品所不具有的属性。这种特殊性源于资产具有可以多处使用（multiple-use）的能力。例如，任何软件产品都被期望是高质的。要求资产被彻底的规约、文档化，并期望它是高效、可测试的，这样可以保证资产具备足够的质量以满足基本的复用质量认证。38然而，为了进一步确保资产的可复用性，资产必须具备一些其它的特性，如轻便性、互操作性、可理解性和可维护性。IEEE 1517标准如下定义可复用性：在构建一个软件系统或其他资产中，资产能被使用的程度。在复用库中，使资产易于在不同的环境、软件系统中使用，以及易于构建其它资产的特性。39表7-5列出了保证

51、资产可复用性的通常特性。如果要开发资产，领域工程师应该使资产具有这些可复用性的特性。如果要获取资产，领域工程师应该在资产的选择标准中包含这些可复用性特性。表7-5 可复用性特性l 一般化的，且具有内置的适配能力/特性化能力（adaptability/specialization）l 广泛可用的l 模块化/自包含的l 完整地和一致的l 不依赖于机器的l 实现/应用无关的l 可靠的l 鲁棒的（资产采用良好的错误/异常处理，具有内置的安全性）l 易理解的/被很好文档化的l 标准化的l 轻便的（能在不同的硬件和操作系统中使用；依赖于硬件和操作系统的特征被最小化和分离）l 可验证的/可测试的l 可维护的

52、l 封装的（细节被分离开来，并对用户隐藏，从而也最小化了变化的影响）在一个资产中体现表7-5中的所有特性是不可行的，也是不必要的。但是，软件产品要使用的资产至少应该有下面的特性：1 一般化的2 标准化的3 文档化的开发资产的时候，领域工程师应该一般化资产，使它能在多个产品中使用。一个一般化的资产捕获了领域的共性特征，也考虑了要接受的差异性。一般化是从资产中抽象共性和去掉特性（即，忽视实现方法、时间、地点和条件等细节）的技术，它可以使资产普遍可用和可复用的。表7-6列出了一些通常用于资产一般化的技术。表7-6 一般化技术l 分离出内部/实现的细节/依赖，如语言、目标环境依赖40l 从特定于应用的

53、业务规则、逻辑和过程中分离出抽象的通用行为/功能l 增加额外的特征以扩大（broadening）资产41l 分离使用资产所需的信息（如：从实现它所需信息得出的规约）l 将资产转换为一个高层的抽象（如：从代码到设计）42l 不分离跨资产的概念，而是将资产分层，以使得资产在概念上自包含43l 保持构建接口是独立于实现的、清晰的和简单的44l 将信息隐藏并包装起来45l 通过参数化和抽象类等技术标识共性、隔离特性46l 暂时不考虑小细节l 按照确定的（即不同的软件产品间保持不变的）和变化的（即不同的软件产品间发生变化的）需求描述资产47标准化使软件复用变得更简单。当软件特征，如菜单、图形用户界面、帮

54、助功能和错误处理被标准化之后，复用的机会就得到了提升。按照标准实现特征的资产能被用于加强标准。如果资产遵守组织的文档、接口设计和测试标准，资产有较好的质量和通用性，资产的可复用性也就会得到提升。表7-7列出了一些资产标准化的通常范围。表7-7 资产标准化范围l 对函数的调用、控制和停止l 错误控制l 帮助l 用户界面（例如，常用的用户对话框）l 通信（如，通用的网络访问）l 文档信息和格式，例如标准化导言域（preamble fields）来描述资产的名称、作者、建立日期、版本号、参数描述、定义日期、文档模板等信息l 符合分析和设计模型标准，如OMG的UMLl 命名规则l 查询处理l 资产接口

55、文档是资产可复用性的一个基本成分。在本章的下一节将进一步讨论资产的文档。表7-8提供了建立资产时为了保证可复用性需要遵守的一些基本方针。表7-8 资产开发的一般性指南l 在构建一个新的资产前，确定该资产不存在。如果存在，尽量复用而不是重新创造这个资产。l 符合命名规则。l 使用一致的设计风格，这个风格与在组织的资产接收和验证过程中使用的设计原则（如，GUI设计标准）相一致。l 使用来自复用库/目录的模板建立新的资产，确保资产符合标准的格式，并确保其其完整性。l 使用对象技术隐藏时间信息。对象封装了它的数据，并只开放操作其数据所需要的操作。l 限制资产之间的通信。资产应该松耦合高内聚。l 了解组织的资产验证标准。生成资产的时候要尽可能符合这些标准。l 为每一个资产开发做出决定，使其在一定程度上既符合当前需求又满足未来所需资产的开发。l 确定资产中蕴涵的