航天中心软件的一个领域工程方法和模型

第２６卷第５期　飞行器测控学报　Ｖｏｌ＿２６　Ｎｏ．５　２００７年１０月　Ｊｏｕｒｎａｌ　ｏｆ　Ｓｐａｃｅｃｒａｆｔ　ＴＴ＆Ｃ　Ｔｅｃｈｎｏｌｏｇｙ　０ｃｔ．２０ｏ７　航天中心软件的一个领域工程方法和模型　崔晓峰　（北京航天飞行控制中心・北京・１０００９４）　摘要软件复用被视为提高软件开发效率和产品质量的有效途径。研究和实践表明，针对特定领域的软件复　用容易取得成功。本文给出了一个基于ＵＭＬ　２．０和体系结构视图、针对航天中心软件特点的领域工程建模方　法，具体分析和设计了相应的一系列领域工程模型，它们可以成为航天中心软件复用的“核心资产”，为未来的　各个应用系统开发提供有力支持。　关键词航天中心；领域工程；领域模型；软件复用；软件体系结构　中图分类号：Ｖ５５８；ＴＰ３１１　文献标识码：Ａ　Ａ　Ｄｏｍａｉｎ　Ｅｎｇｉｎｅｅｒｉｎｇ　Ａｐｐｒｏａｃｈ　ａｎｄ　ｔｈｅ　Ｍｏｄｅｌｓ　ｆ０ｒ　Ｓｐａｃｅ　Ｃｅｎｔｅｒ　Ｓｏｆｔｗａｒｅ　ＣＵＩ　Ｘｉａｏ．ｆｅｎｇ　（Ｂｅｉｊｉｎｇ　Ａｅｒｏｓｐａｃｅ　Ｃｏｍｍａｎｄ　ａｎｄ　Ｃｏｎｖｏｌ　Ｃｅｎｔ￣，Ｂｅｒｉｎｇ　１０００９４）　Ａｂｓｔｒａｃｔ　Ｓｏｆｔｗａｒｅ　ｌｅｎｓｅ　ｉｓ　ｒｅｇａｒｄｅｄ　ａｓ　ａｎ　ｅｆｆｅｃｔｉｖｅ　ｗａｙ　ｔｏ　ｉｍｐｒｏｖｅ　ｓｏｆｔｗａｒｅ　ｄｅｖｅｌｏｐｍｅｎｔ　ｅｆｆｉｃｉｅｎｃｙ　ａｎｄ　ｐｒｏｄｕｃｔ　ｑｕａｌｉ—　ｔｙ．Ｒｅｓｅａｒｃｈ　ａｎｄ　ｐｒａｃｔｉｃｅ　ｓｈｏｗ　ｔｈａｔ　ｓｕｃｃｅｓｓ　ｏｆ　ｄｏｍａｉｎ—ｓｐｅｃｉｆｉｃ　ｓｏｆｔｗａｒｅ　ｒｅｕｓｅ　ｉｓ　ｒｅｌａｔｉｖｅｌｙ　ｅａｓｙ　ｔｏ　ａｃｈｉｅｖｅ．Ｔｈｉｓ　ｐａｐｅｒ　ｐｒｏｐｏｓｅｓ　ａ　ｄｏｍａｉｎ　ｅｎｇｉｎｅｅｒｉｎｇ　ａｐｐｒｏａｃｈ　ｕｓｉｎｇ　ＵＭＬ　２．０　ａｎｄ　ａｒｃｈｉｔｅｃｔｕｒｅ　ｖｉｅｗｓ　ｔｏ　ｍｏｄｅｌ　ｓｏｆｔｗａｒｅ　ｏｆ　ｓｐａｃｅ　ｃｅｎｔｅｒｓ．Ａ　ｓｅ—　ｉｔｅｓ　ｏｆ　ｃｏｒｒｅｓｐｏｎｄｉｎｇ　ｄｏｍａｉｎ　ｅｎｇｉｎｅｅｒｉｎｇ　ｍｏｄｅｌｓ　ｒａｅ　ａｎａｌｙｚｅｄ　ａｎｄ　ｄｅｓｉｇｎｅｄ．Ｔｈｅｓｅ　ｍｏｄｅｌｓ　ｃａｎ　ｂｅ　ｕｓｅｄ　ａｓ　ｔｈｅ　ｃｏｒｅ　ｓａｓｅｔｓ　ｆｏｒ　ｓｏｆｗｔａｒｅ　ｒｅｕｓｅ　ｆｏｒ　ｓｐａｃｅ　ｃｅｎｔｅｒｓ　ａｎｄ　ｐｒｏｖｉｄｅ　ｓｕｂｓｔａｎｔｉａｌ　ｓｕｐｐｏｒｔ　ｆｏｒ　ｄｅｖｅｌｏｐｍｅｎｔ　ｏｆ　ａ　ｖａｒｉｅｔｙ　ｏｆ　ｆｕｔｕｒｅ　ａｐｐｌｉｃａｔｉｏｎ　ｓｙｓ—　ｔｅｍｓ．　Ｋｅｙｗｏｒｄｓ　Ｓｐａｃｅ　Ｃｅｎｔｅｒ；Ｄｏｍａｉｎ　Ｅｎｇｉｎｅｅｉｒｎｇ；Ｄｏｍａｉｎ　Ｍｏｄｅｌ；Ｓｏｆｔｗａｒｅ　Ｒｅｕｓｅ；Ｓｏｆｔｗａｒｅ　Ａｒｃｈｉｔｅｃｔｕｒｅ　０　引　言　软件复用（Ｓｏｆｔｗａｒｅ　Ｒｅｕｓｅ），即重复使用“为了复用目的而设计的软件”，被视为解决“软件危机”、提　高软件生产效率和质量、实现软件产业工业化生产方式的可行途径－ｌ　Ｊ。而成功的复用需要有目标、系统　化的面向复用的开发，即“为复用而设计（Ｄｅｓｉｇｎ　ｆｏｒ　Ｒｅｕｓｅ）”。软件工程的研究和实践表明，领域特定　（Ｄｏｍａｉｎ．ｓｐｅｃｉｉｆｃ）的软件复用活动相对容易取得成功。领域是一组具有相似或相近软件需求的应用系统　所覆盖的功能区域。领域工程（Ｄｏｍａｉｎ　Ｅｎｇｉｎｅｅｒｉｎｇ），即为一组相似或相近系统的应用工程建立基本能力　和必备基础的过程，是目前可复用资产基础设施建设的主要技术手段　。　航天中心软件具有突出特点，有较强的领域成熟性和稳定性。但是以往的工程实践主要是面向单个　系统，已有的一些复用活动往往限于低层次、小粒度，例如库函数形式，难以从根本上获得效率和质量的提　升。另一方面，航天中心软件规模大、接口多，尤其是对可靠性、实时性等质量属性有着特别的高要求，因　此更加迫切需要在一套科学、规范、可操作性强的方法指导下开展领域工程，实现系统化的软件复用。　本文首先基于对当前主要领域工程方法的简述，提出了一个针对航天中心软件的领域工程方法，对比　说明了其特点和优势。接下来用该方法对航天中心软件进行了具体的领域分析和设计，给出了一系列领　域工程模型。这些模型可以成为航天中心软件复用的“核心资产”（Ｃｏｒｅ　Ａｓｓｅｔｓ），为未来的各个应用工程　开发提供有力支持。　｝收稿日期：２００６—１２—０８　作者简介：崔晓峰（１９７１～），男，博士研究生，高级工程师，主要从事航天测控软件开发和软件工程方法研究。　维普资讯 http://www.cqvip.com 第５期　崔晓峰：航天中心软件的一个领域工程方法和模型　８３　１　方法概述　从Ｎｅｉｇｈｂｏｒｓ＿３　在１９８４年创立“领域分析”的概念并开发Ｄｒａｃｏ方法以来，许多领域工程技术被提出，　有代表性的包括ＦＯＤＡ＿４］、ＦＯＲＭ＿５］、ＦＡＳＴ＿６　等。通常，领域工程过程被划为３个阶段：领域分析，领域设　计，领域实现。在领域分析阶段，收集和分析关于问题域的信息，定义标识领域同性和变化性的领域　模型；在领域设计阶段，识别和规约问题域中那些将被解决方案支持的方面；在领域实现阶段，建立和测试　解决方案产品以供使用　］。从一个领域的视角对共同性和变化性进行识别和控制，是开展领域工程活动　的关键。ＦＯＤＡ在１９９０年引入特征分析的思想，即用产品特征（Ｆｅａｔｕｒｅｓ）对一个领域中的共性和差异进　行识别和分类。特征是用户和开发者都理解的核心抽象，特征模型提供了一个开发、参数化以及配置可复　用资产的基础　，在已有方法中得到普遍使用。　本文采用了上述３阶段划分，实施完整的领域工程过程。在领域分析阶段产生环境模型、特征模型、　领域字典等；在领域设计阶段产生领域体系结构模型；在领域实现阶段进行领域构件的开发。针对已有方　法大多只侧重单个阶段、提出的模型各异、模型间映射能力弱、语义不够严格等不足，本文着眼于整个领域　工程过程的各个模型，给出了较系统、一致的模型定义。同时使用ＵＭＬ　２．０＿８　并通过衍型（Ｓｔｅｒｅｏｔｙｐｅ）等　手段进行扩展，用于全部模型的统一建模，利用了ＵＭＬ　２．０语义严格性和体系结构描述能力增强的优点，　并且利于实现模型之间的正向转换和逆向追踪性。　本方法的特征模型针对航天软件领域的要求，强调图示的规范性和语义的准确性。特征被表示为模　型中的一阶实体，并能够清晰描述特征之间的组合、范化、依赖、关联等关系。对特征的详细分解刻画，尤　其是对非功能（Ｎｏｎ．ｆｕｎｃｔｉｏｎａ１）特征（又称为质量特征）的建模，是本方法的一个主要特点。已有的各种方　法中，特征模型比较精化的是ＦＯＲＭ＿５　Ｊ，它将所有特征分为４类，非功能特征被列入能力特征中，缺乏对其　本身及外在关联的具体描述。非功能特征作为决定软件体系结构的重要因素，对于高质量要求的航天领　域软件而言尤其关键。为此，本方法首先将所有的特征分为功能和非功能２大类，功能特征采用类似　ＦＯＲＭ的４层分解进行建模，非功能特征则分为特性层和度量层，并且建立了功能与非功能特征的关联，　这对于后续的设计和验证具有重要意义。　本方法对于领域体系结构的建模，是基于当前软件体系结构研究中得到普遍重视的多视图方法并进　行了扩展。基于多视图的体系结构描述，体现了关注点分离的思想，对系统的描述全面、易于理解和交流，　并有利于一致性检测以及质量属性的评估。常规的多视图方法，无论给出一组固定视图，如Ｋｒｕｃｈｔｅｎ的４　＋１模型　、Ｈｏｆｍｅｓｉｔｅｒ的４视图模型　…，还是给出多类视图由应用者按需选择，如ＣＭＵ－ＳＥＩ的“Ｖｉｅｗｓ　ａｎｄ　Ｂｅｙｏｎｄ”模型［１１　Ｊ、ＩＥＥＥ标准１４７１－２０００＿ｌ　等，都是针对单个产品，未包含领域设计要素。另一方面，已有　的领域工程方法中，对于领域体系结构建模给出的支持还比较初步，有一些方法采用了多视图描述，例如　１１１ｉｅｌ和Ｈｅｉｎ　Ｌｌ　提出了一个对ＩＥＥＥ　１４７１进行基本扩展的元模型，在体系结构的逻辑视图、物理视图、进　程视图以及部署视图建模中加入了变化性。本文在领域设计中，采用了“Ｖｉｅｗｓ　ａｎｄ　Ｂｅｙｏｎｄ”方法对体系结　构建模，因为它体现了构件与连接子作为体系结构最基本建模元素的重要性。本文针对领域体系结构的　需要对这些视图进行了扩充，并且与特征模型一样也基于ＵＭＬ　２．０扩展作为描述手段，可以直接与特征　模型中的功能特征、非功能特征以及包含的变化点建立关联，并实现模型间的转换。　２航天中心软件的领域工程建模　航天中心是航天工程中的一个重要组成要素，是航天飞行中信息处理、监视控制、指挥协同等任务的　核心。本文的领域工程对象是航天中心完成上述功能的软件系统。（限于篇幅，这里重点通过示例说明　建模元素和方法，而不是给出详尽的领域模型。）　２．１领域分析　领域分析阶段的目标是获得领域模型（Ｄｏｍａｉｎ　Ｍｏｄｅ１），它描述领域中系统之间的共同需求。这个阶　段的主要活动包括确定领域边界，识别信息源，分析领域中系统的需求，确定哪些需求是领域中系统所广　维普资讯 http://www.cqvip.com 飞行器测控学报　第２６卷　泛共享的，哪些是可变的　Ｊ。　对航天中心软件进行领域分析，形成的结果主要包括：环境模型（Ｃｏｎｔｅｘｔ　Ｍｏｄｅ１）、特征模型（Ｆｅａｔｕｒｅｓ　Ｍｏｄｅ１）、领域字典（Ｄｏｍａｉｎ　Ｄｉｃｔｉｏｎａｒｙ）。　环境模型通过领域环境分析，对目标领域的范围进行界定，并分析该领域与其外部元素的关系。环　境分析的结果即环境模型，包括一个结构图和一个环境图。对于航天中心软件，用领域结构图表示它与其　上层、下层以及同层领域的关系，可以是组合关系、泛化关系等。环境图用于说明航天中心与其外部元素　之间的交互，包括相互连接和数据流，以及领域边界上的变化性。　特征模型通过特征建模，识别一个领域内产品的外部可见特性，并将它们组织成为一个特征模型。　本文对ＵＭＬ　２．０进行扩展，用于建立特征模型。在该模型中，把特征表示为一阶实体。系统特征分为功　能特征和非功能特征。特征之间的各种关系被明确标识。功能特征和非功能特征之间的关联说明了前者　对后者的需求，与之对应的关联类用于定义该功能特征在该非功能特征上的度量。扩展了以下衍型对特　征进行修饰：《ＦＦ》（功能特征），＜＜ＦＦｏｐｔｉｏｎａｌ＞＞（可选的功能特征），＜＜ＦＦｖａｒｉａｔｉｏｎ＞＞（具有选择性子特征　的功能特征），《ＦＦｖ　ａｎｔ》（选择性功能特征），《ＮＦ》（非功能特征），＜＜ＮＦｍｅｔｒｉｃ＞＞（度量性非功能特　征）；识别特征之间的以下关系：组合（父特征是子特征的组合），泛化（父特征是子特征的一般化），依赖　（Ａ特征的存在依赖于Ｂ特征的存在），关联（ｃ特征是Ａ、Ｂ特征的关联类）；功能特征分为４个层次进行　描述：能力（Ｃａｐａｂｉｌｉｔｉｅｓ）层，操作环境（Ｏｐｅｒａｔｉｎｇ　Ｅｎｖｉｒｏｎｍｅｎｔ）层，领域技术（Ｄｏｍａｉｎ　Ｔｅｃｈｎｏｌｏｇｉｅｓ）层，实现　技术（Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ　Ｔｅｃｈｎｉｑｕｅｓ）层；非功能层分为２个层次进行描述：特性（Ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ）层，度量（Ｍｅｔ—　ｉｒｃｓ）层。图１、图２是航天中心软件特征模型的示例，描述了功能特征和非功能特征以及它们之间关系，　并提供了描述变化性的机制。　蠹＜＜ｌａｙｅｒ＞＞　领域技术　Ｆｖａ。幻ｒｉａ　ｔｉｏ　ｆ　　’’。。　。。１＜＜ＦＦｖａｒｉａｎｔ＞＞￣　＜＜ＦＦｖａｒｉａｎｔ＞￣　ＴＣＰ　　ｌＵＤＰ　图１航天中心软件的特征模型示例（功能特征）　维普资讯 http://www.cqvip.com

第５期　崔晓峰：航天中心软件的一个领域工程方法和模型　８５　图２航天中心软件的特征模型示例（非功能特征）　领域字典通过领域字典建立起一个领域内共同认可的标准术语、缩略语、定义的知识库，成为领域　工程和应用开发过程的基础。航天中心软件的领域字典，应以标准化的工程术语为依据。在领域字典中　须给出每个领域概念的名字、属性、解释、示例等。　２．２领域设计　领域设计的主要目标是获得领域体系结构（Ｄｏｍａｉｎ　Ａｒｃｈｉｔｅｃｔｕｒｅ），它是对领域模型中描述需求的一个　解决方案，适用于领域内的一系列应用系统，包含领域共同性和变化性的设计。　本文的领域体系结构建模基于“Ｖｉｅｗｓ　ａｎｄ　Ｂｅｙｏｎｄ”方法，选择使用不同的体系结构视图类型，即模块　视图、构件与连接子（Ｃ＆Ｃ）视图、分配视图，它们分别代表了软件如何作为一组实现单元来组织、如何作　为一组具有运行时行为和交互的元素来组织、如何与其环境中的非软件结构相关　ｌ　。　本文将用于单个软件体系结构描述的上述方法扩展到领域软件，在各个视图中引入变化点，并标识变　化点关联的体系结构元素以及变化点到领域模型（特征模型）的可追踪性、变化点的绑定时间、决策推理　依据等。本文以ＵＭＬ　２．０为基础并进行扩展，作为领域体系结构的建模工具。　（１）模块视图　模块视图记录一个系统的首要的实现单元。该视图类可以包含分解（ｄｅｃｏｍｐｏｓｉｔｉｏｎ）、使用（ｕｓｅｓ）、泛　化（ｇｅｎｅｒａｌｉｚａｔｉｏｎ）、分层（１ａｙｅｒｅｄ）等风格¨　。　图３是航天中心软件的一个模块视图。该视图使用了分解风格、使用风格、分层风格来对航天中心软　件的顶层模块结构进行描述。在该视图中，第一级模块为“软件配置项（ＣＳＣＩ）”，用衍型《ｃｓｃＩ》表示，在　该系统包含７个ＣＳＣＩ，分为任务（Ｔａｓｋ）层、支持（Ｓｕｐｐｏ￣）层２层；任务层中的配置项分别实现特征模　型中的对应特征，并且可以看到相应变化点在体系结构中的实现；从特征模型中可以看到Ｐｌａｎ、Ｏｒｂｉｔ、Ｔｅ—　ｌｅｍｅｔｒｙ、Ｔｅｌｅｃｍｄ等特征均依赖于变化点ＥｘｔｅｒｎＰａｃｋａｇｅＦｏｒｍａｔ，因此在设计中增加ＤａｔａＰｏｒｔａｌ配置项，由它　实现该特征，则Ｐｌａｎ等４个配置项都只需“使用”ＤａｔａＰｏｒｔａｌ，而不需要各自实现该变化点；第二级模块为　“软件部件（ＣＳＵ）”，用衍型《ＣＳＵ》表示，ＤａｔａＰｏｒｔａｌ配置项包含了２个ＣＳＵ，即Ｒｅｃｅｉｖｅｒ和Ｓｅｎｄｅｒ。　（２）Ｃ＆Ｃ视图　Ｃ＆Ｃ视图记录系统的执行单元。该视图类可以包含管道与过滤器（Ｐｉｐｅ—ａｎｄ—Ｆｉｌｔｅｒ：）、共享数据　（Ｓｈａｒｅｄ—Ｄａｔａ）、发布一订阅（Ｐｕｂｌｉｓｈ—Ｓｕｂｓｃｄｂｅ）、客户端一服务器（Ｃｌｉｅｎｔ—Ｓｅｒｖｅｒ）、对等（Ｐｅｅｒ—ｔｏ—Ｐｅｅｒ）、通信　进程（Ｃｏｍｍｕｎｉｃａｔｉｎｇ—Ｐｒｏｃｅｓｓｅｓ）等风格¨　。　维普资讯 http://www.cqvip.com 飞行器测控学报　第２６卷　任务　＜＜ＣＳＣＩ＞＞　＜＜ＣＳＣＩ＞＞　／，＝　￣Ｓｃｈｅ　ｄｕｌｅ　Ｐｃ．　．ｔ　Ｄｉｓｐｌａｙ　＜实现了＜ＣＳＣ变化点＜Ｉ＞＞Ｔｅｌｅ＜ｃｍＦＦｄ　Ｉ　ｃ　　ｏｐｔｉｏｎ＞＞Ｔｅｌｅｃｍｄ　ｌ　．．＜＜ＣＳＣＩ＞＞　Ｐｌａｎ　…・　＜＜ＣＳＣＩ＞＞　Ｏｒｂｉｔ　＜＜ＣＳＣＩ＞＞　Ｔｅｌｅｍｅｔｒｙ　＜＜ＣＳＣＩ＞＞　Ｔｅｌｅｃｍｄ　一　针‘ＴＦ　Ｆｏ。ｐｔｍｉｏｎ　　：ｌａｙｅｒ＞＞　＜＜Ｃ　ＳＣＩ＞＞ＤａｔａＰｏｒｔａｌ实现　。　支持　＜＜ＣＳＣＩ＞＞　了变化点＜＜ＦＦｖａｒＥｘｔｅｒｎＰａｃｋａｇｅ　ｉＦｏｒｍａｔａｔｉｏｎ＞　　ＤａｔａＰｏｒｔａ１　／　ｃｓＲｅｃｅｖｅｒ　Ｉ　ＩＳｅｎ　ｄｅｒ　Ｉ　～～～＿Ｉ’’＿．．－－－－一－　－　／＇Ｊ　ｌ　＜＜ＥｘＦｃ锄ＦｖｏｒａｍＰｒａｉａｃａｔ　ｔｋｉｏａｇ＞ｅ＞　图３　航天中心软件的领域体系结构示例（模块视图）　图４是航天中心软件系统中Ｒｅｃｅｉｖｅｒ进程的一个简化Ｃ＆Ｃ视图。在该视图中，Ｒｅｃｅｉｖｅｒ构件与系统　中其他构件（如Ｓｃｈｅｄｕｌｅｒ、Ｔｅｌｅｍｅｔｒｙ）之间的交互均通过中间件，采用Ｐｕｂｌｉｓｈ－Ｓｕｂｓｃｒｉｂｅ的方式进行信息传　递；Ｒｅｃｅｉｖｅｒ构件（用衍型《ｐｒ０ｃｅｓｓ》表示其为一个进程）由３个构件和２个连接子组装而成，这３个构件　都通过预先定义好的接口同中间件进行交互；ＡｃｑｕｉｒｅＣｏｎｆｉｇ构件（用衍型《ｔｈｒｅａｄ》表示其为一个线程）通　过读取配置文件，得到对外部网络包格式的描述，再通过共享区提供给ＲｃｖＰｒｏｃｅｓｓ据此进行解包，因此在　ＡｃｑｕｉｒｅＣｏｎｆｉｇ构件上实现了ＥｘｔｅｍＰａｃｋａｇｅＦｏｒｍａｔ变化点；ＲｃｖＰｒｏｃｅｓｓ与ＳａｖｅＤａｔａ构件之间通过一个连接　子ＤａｔａＢｕｆ进行交互，从而将原始数据交给ＳａｖｅＤａｔａ转储，ＤａｔａＢｕｆｆ实现了互斥的缓冲区读写操作，并且　可以定量分析缓冲区的平均等待时间等质量属性，因此实现了非功能特征Ｅｆｉｆｃｉｅｎｃｙ。　口……一外部数据…………ｊ　……—．解包后的遥测数据…－ｊ　运行状态　图４航天中心软件的领域体系结构示例（Ｃ＆Ｃ视图）　（３）分配视图　分配视图记录一个系统的软件与其开发和执行环境之间的关系。该视图类可以包含部署（Ｄｅｐｌｏｙ－　ｍｅｎｔ）、￣（Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）、工作分配（ｗｏｒｋ　Ａｓｓｉｇｎｍｅｎｔ）等风格　。　航天中心软件运行在大型、异构的分布式环境中，软件单元的部署对于系统实现的效率和灵活性具有　维普资讯 http://www.cqvip.com 第５期　崔晓峰：航天中心软件的一个领域工程方法和模型　８７　重要影响，这些需要在分配视图中进行描述。　２．３领域实现　领域实现是以领域模型和领域体系结构为基础，进行可复用构件的识别、生产和管理。　以图４所示的软件体系结构为例，可以将其中提供数据缓冲的连接子ＤａｔａＢｕｆｆ通过面向对象方式实　现为一个可复用的类。　３　航天中心软件的领域模型到应用开发　基于领域工程的成果，新应用系统的开发不再是从零开始，而是建立在对分析、设计、实现等阶段的软　件资产大量复用的基础上。这样的单个产品开发过程通常称为应用工程（Ａｐｐｌｉｃａｔｉｏｎ　Ｅｎｇｉｎｅｅｉｒｎｇ）。　航天中心软件的应用开发中，首先根据已有的领域特征模型进行特征选择；然后根据确定的特征，在　已有的领域体系结构上进行变化点的决策，形成应用特定的体系结构；继而，根据该体系结构选择需要的　领域构件，这些构件是领域工程阶段已经开发好的制品。　４　小　结　面对蓬勃发展的航天事业，各类航天测控软件须应对更高的质量和开发效率要求，开展软件领域工程　方法是以复用手段达到该目标的有效途径。　本文在已有的领域工程方法基础上，以加强质量关注、表达能力以及规范化和可操作性为目标，提出　了一套针对航天中心软件的完整领域工程建模方法。该方法强调了变化性和非功能特征的刻画以及它们　的追踪性，并以当前软件体系结构为中心（Ａｒｃｈｉｔｅｃｔｕｒｅ—Ｃｅｎｔｒｉｃ）的观点，在领域体系结构的设计和描述中　使用了多视图以及基于构件（Ｃｏｍｐｏｎｅｎｔ—Ｂａｓｅｄ）和模型驱动（Ｍｏｄｅｌ—Ｄｒｉｖｅｎ）的开发思想。由于ＵＭＬ２．０在　语义严格性和体系结构描述能力上的增强，该方法使用它并加以扩展作为领域工程建模的统一元模型。　参考文献　［１］杨芙清，梅宏，李克勤．软件复用与软件构件技术［Ｊ］．电子学报，１９９９，２７（２）：６８－７５．　［２］　杨芙清，王千祥，梅宏，等．基于复用的软件生产技术［Ｊ］．中国科学（Ｅ辑），２００１，３１（４）：３６３３７１．　［３］Ｎｅｉｇｈｂｏｒｓ　Ｊ．Ｔｈｅ　Ｄｒａｃｏ　Ａｐｐｒｏａｃｈ　ｔｏ　Ｃｏｎｓｔｒｕｃｔｉｏｎ　Ｓｏｆｔｗａｒｅ　ｆｒｏｍ　Ｒｅｕｓａｂｌｅ　Ｃｏｍｐｏｎｅｎｔｓ［Ｊ］．ＩＥＥＥ　Ｔｒａｎｓａｃｔｉｏｎｓ　ｏｎ　ｏｆＳｗａｒｔｅ　Ｅｎｇｉｎｅｅｉｒｎｇ，１９８４，　１Ｏ（５）：５６４－５７３．　［４］Ｋａｎｇ　Ｋ　Ｃ，Ｃｏｈｅｎ　Ｓ，Ｈｅｓｓ　Ｊ，ｅｔ　１ａ．Ｆｅａｔｕｒｅ－Ｏｒｉｅｎｔｅｄ　Ｄｏｍａｉｎ　Ａｎｌａｙｓｉｓ，Ｆｅａｓｉｂｉｌｉｔｙ　Ｓｔｕｄｙ［Ｒ］．Ｓｏｆｔｗａｒｅ　Ｅｎｇｉｎｅｅｉｒｎｇ　Ｉｎｓｉｔｔｕｔｅ，Ｐｉｔｔｓｂｕｒｇｈ　ＣＭＵ／ＳＥＩ－９０－ＴＲ－２１，１９９０．　［５］Ｋａｎｇ　Ｋ　Ｃ，Ｄｏｎｏｈｅｅ　Ｐ．Ｆｅａｔｕｒｅ－Ｏｒｉｅｎｔｅｄ　Ｐｒｏｄｕｃｔ　Ｌｉｎｅ　Ｅｎｇｉｎｅｅｉｒｎｇ［Ｊ］．ＩＥＥＥ　Ｓｏｆｔｗａｒｅ，２００２，１９（４）：５８－６５．　［６］Ｃｏｐｌｉｅｎ　Ｊ，Ｈｏｆｍａｎ　Ｄ，Ｗｅｉｓｓ　Ｄ．Ｃｏｍｍｏｎａｌｉｔｙ　ａｎｄ　Ｖａｒｉａｂｉｌｉｔｙ　ｉｎ　ｏｆＳｗａｔｒｅ　Ｅｎｇｉｎｅｅｒｉｎｇ［Ｊ］．ＩＥＥＥ　Ｓｏｆｔｗａｒｅ，１９９８，１５（６）：３７－４５．　［７］Ａｒａｎｇｏ　Ｇ，Ｐｒｉｅｔｏ－Ｄｉｓａ　Ｒ．Ｄｏｍａｉｎ　Ａｎｌａｙｓｉｓ　ａｎｄ　ｏｆＳｔｗａｒｅ　Ｓｙｓｔｅｍｓ　Ｍｏｄｅｌｉｎｇ［Ｍ］．ＩＥＥＥ　Ｃｏｍｐｕｔｅｒ　Ｓｏｃｉｅｔｙ　Ｐｒｅｓｓ，１９９１．　［８］Ｏｂｊｅｃｔ　Ｍａｎａｇｅｍｅｎｔ　Ｇｒｏｕｐ．ＵＭＬ　２．０　Ｓｕｐｅｒｓｔｒｕｃｔｕｒｅ　Ｓｐｅｃｉｆｉｃａｉｔｏｎ：Ｆｉｎａｌ　Ａｄ￣ｔｅｄ　Ｓｐｅｃｉｉｆｃａｔｉｏｎ［ｓ］．（２００３一Ｏ８一Ｏ２）［２００６一Ｏ１一Ｏ１］　ｈｔｔｐ：／／ｗｗｗ．ｏｇｍ．ｏｒｇ／ｄｏｃｓ／ｐｔｃ／０３－０８－０２．ｐｄｆ（Ａｕｇｕｓｔ　２００３）．　［９］Ｋｒｕｃｈｔｅｎ　Ｐ．Ｔｈｅ　４＋１　Ｖｉｅｗ　Ｍｏｄｅｌ　ｏｆ　Ａｒｃｈｉｔｅｃｔｕｒｅ［Ｊ］．ＩＥＥＥ　ｏｆＳｔｗａｒｅ，１９９５，１２（６）：４２－５０．　［１Ｏ］Ｈｏｆｍｅｉｓｔｅｒ　Ｃ，Ｎｏｒｄ　Ｒ，Ｓｏｎｉ　Ｄ．Ａｐｐｌｉｄ　ｅＳｏｆｔｗａｒｅ　Ａｒｃｈｉｔｅｃｔｕｒｅ［Ｍ］．ＭＡ：Ａｄｄｉｓｏｎ・Ｗｅｓｌｅｙ，２０００．　［１１］ＣｌｅｍｅｎｔｓＰ，Ｂａｃｈｍａｎｎ　Ｆ，Ｂａｓｓ　Ｌ，ｅｔａ１．Ｄｏｃｕｍｅｎｔｉｎｇ　ＳｏｆｔｗａｒｅＡｒｃｈｉｔｅｃｔｕｒｅ：Ｖｉｅｗｓ　ａｎｄＢｅｙｏｎｄ［Ｍ］．Ｂｏｓｔｏｎ，ＭＡ：Ａｄｄｉｓｏｎ－Ｗｅｓｌｅｙ，２００２．　［１２］ＩＥＥＥ．ＩＥＥＥ　Ｓｔｄ１４７１－２０００．ＩＥＥＥＲｅｃｏｍｍｅｎｄｅｄＰｒａｃｔｉｃｅｆｏｒＡｒｃｈｉｔｅｃｔｕｒｌＤｅａｓｃｒｉｐｔｉｏｎｓｏｆＳｏｆｔｗａｒｅ－Ｉｎｔｅｎｓｉｖｅ　Ｓｙｓｔｅｍ￣［Ｓ］．ＮｅｗＹｏｒｋ，ＮＹ：　Ｉｎｓｔｉｔｕｔｅ　ｏｆ　Ｅｌｅｃｔｒｉｃａｌ　ａｎｄ　Ｅｌｅｃｔｒｏｎｉｃｓ　ｇｎ＠ｎｅｅ￣，２０００．　［１３］Ｔｈｉｅｌ　Ｓ，Ｈｅｉｎ　Ａ．Ｓｙｓｔｅｍａｔｉｃ　Ｉｎｔｅｇｒａｉｔｏｎ　ｆｏ　Ｖａｒｉｂｉａｌｉｙｔ　ｉｎｔｏ　Ｐｒｏｄｕｃｔ　Ｌｉｎｅ　Ａｒｃｈｉｔｅｃｔｕｒｅ　Ｄｅｓｉｇｎ［Ｊ］．Ｌｅｃｔｕｒｅ　Ｎｏｔｅｓ　ｏｎ　Ｃｏｍｐｕｔｅｒ　Ｓｃｉｅｎｃｅ，２００２，　Ｖｏ１．２３７９：１３０．１５３．