论文部分内容阅读
摘要：软件构件技术是当前软件工程的一个热点研究领域，本文从软件构件体系的角度，全面叙述了如何通过构件化技术方法，提高星载软件的研制效率和研制能力，为解决星载软件重复研发，可靠性保障成本较高的问题提供了一条技术解决方案。
关键词：软件工程；构件；星载软件
引言
1968年，在北大西洋公约组织（NATO）召开的软件工程会议上，首次提出来了软件危机（SoftwareCrisis）的概念。会议上，Mcllroy提交了一篇题为《Mass-Produced Software Components》的论文，首次提出了软件构件（Software Components）以及构件工厂等概念，指出软件复用的一个重要基础就是需要有充足的软件构件。稍后，NATO制定了关于软件复用的一套指导性标准，其中就有关于构件及利用标准构件来实现软件复用的基本思路。
1软件构件化的好处及困难
所谓的构件就是指封装的、规范的、可重用的软件模块。广义上讲，构件可以是需求分析、设计、代码、测试用例、文档或软件开发过程的中其他产品；狭义上来说，构件一般指对外提供一组规约化接口的、符合一定标准的、可替换的软件系统的程序模块。
通过软件构件实现软件的复用，可以提高软件研制效率，增强软件可靠性，提升软件技术竞争力，实现共享知识促进软件开发的技术进步和标准化，从长远看，肯定能提高星载软件的研制能力。可以说软件构件是最有价值的软件资产。
但是我们也应该清醒地看到，在星载嵌入式环境下实现软件构件的困难，包括：
1.1环境的适应性
不同的用户需求产生了不同的载荷功能要求，不同的架构设计师构建了不同的卫星载荷的硬件系统，上层的需求变化，底层的硬件环境变化，那么处于中间层的星载嵌入式软件，需要有一种复用机制来以不变应万变，需要通过构件抽象去适应不同需求、不同硬件的差异，并由此负担了资源成本和效率的代价。
1.2新技术的追踪
复用构件是为了新产品的研制，然而软件产品耦合的因素很多，操作系统、处理器、编程语言……这些技术因素都在发展变化中，那么随之而来的问题是：大多数情况下，我们的研发部门只是技术发展方向的追随者，不是引领者，如何保证在目前的技术体系下设计的构件产品，有较长的使用寿命，在将来一段时期内的项目中都能被复用？积累的软件构件会不会有朝一日因为技术淘汰而用无可用？这就需要构件设计者能敏锐的把握新技术的发展方向并应用在构件设计中。
1.3资源的限制
一般的软件系统的处理器性能、存储器容量等资源都较为丰富，软件的性能要求方面不多，构件粒度的定义有较大的伸缩度。而星载嵌入式软件，软硬件结合紧密，需要充分考虑硬件因素，在软硬件资源局限性较大的同时，对实时性和可靠性要求高，并行、同步、中断、时序、可靠性等等方面有更多的苛刻限制，所以星载嵌入式环境下软件构件开发更有难度。
1.4复用的成本
相对于专用化设计，构件化显然需要额外增加软件的调度、接口、层次，增加了软件本身的通信成本、资源成本、规模成本和管理成本。
同时，为避免错误扩散，提高构件的适用能力，就必须构件经过更严格的软件测试，因此开发可复用构件的费用要比开发一般模块的费用要昂贵，W.Tracz认为开发可复用构件的费用比开发一般模块要超出30%～200%。收回在复用项目上的投资需要时间，W.Tracz发现，在一个软件上的投资只有在该可复用构件第3次被复用之后才能收回。
2构件体系的技术策划
星载嵌入式软件的构件体系建立是一个系统工程，也是一个循序渐进的过程，需要从研究构件特征及关系入手，建立一个构件模型，通过构件描述语言来解决构件的描述、组装问题；然后有目的的生产构件或者从已有星载载荷系统中挖掘提取构件；建立构件库对构件进行有效的分类、组织、检索及配置管理；在构件模型的基础上研究构件组装机制，并按照构件化软件架构开展软件的开发活动。
嵌入式环境下软件构件体系的架构示意如图1：
2.1构件模型
软件构件只有存在于一个定义好的软件环境（构件标准）里才能实现互联互通互操作，才能发挥效用，每个构件都提供了一套服务，软件怎么使用其他构件提供的服务、构件怎样命名、怎么在运行时发现新构件和它们的服务，因此首先必须建立一个软件构件模型，通过构件模型来全面定义构件的基本属性、构件接口结构、构件应用的框架、构件间的交互机制等内容，并提供创建构件和实现构件的规则。
国内外的研究机构根据自己的领域特征曾提出一些嵌入式构件模型，国外的如PECT、Koala、PBO以及PECOS等构件模型，国内的CBMESP、Z-CCM、DRSCDE等构件模型，
它们对实时嵌入式系统的构件开发都提出了有效的解决方案，但大多数都局限于具体实时嵌入式应用领域，与特定软件平台紧密相关，难以做到开放性、普适性，并在构件的易用性、可移植性、可靠性和质量保证方面仍存不足。
因此，通过对星载领域的软件进行分析，对其中的稳定需求和共同特征进行抽象，形成星载领域的构件模型，在此基础上，设计开发适合领域环境的构件，并加以提炼入库，以备将来复用。并且使用构件描述语言以严格而又易于理解的方式，为构件交互、构件组装和构件开发人员提供全面准确的构件信息，将构件模型进行形式化的描述。
构件模型一般可以从概念、内容、语境等角度，对构件的属性、接口、环境、关联等若干个主要元素进行定义，一个典型的构件模型元素结构如图2：
2.2构件的开发和组装
领域模型建立后，就可以按照模型定义，借鉴通用构件模型的某些特点，从实际开发环境和开发平台出发，研究分析、设计出适合星载领域软件开发和组装的构件，明确定义构件的接口以及接口配置，并进行文档化；另外，还可以通过软件再工程的手段，从已有的大量星载载荷软件资产中标识并提取可复用的构件。 构件的开发设计一定要摆脱与特定硬件平台、软件平台的耦合，以提高构件的普适性、可移植性和高复用性。
构件的组装集成是软件构件中的核心技术，构件组装集成是要通过构件的接口或者连接件来协调各个构件的行为，通过将一定数量的构件按照约定的交互机制及组装机制集成，使通过构件组合成的软件产品能够满足星载实时嵌入式系统的特定功能及非功能盖求，如服务功能、资源约束限制、环境依赖及构件时间行为等，从而实现构件的价值。
按照软件的基本结构，经常采用的构件组装机制，包括构件顺序组装、构件选择组装、构件循环组装、构件并行组装、构件同步组装和构件中断组装。
星载嵌入式环境下的构件组装受到从构件模型、需求，到构件粒度大小、组装平台特点、运行环境等多种要素的制约，同时兼顾构件之间的行为联系、数据联系等等问题，因此构件组装必须要需要结合具体的应用要求，对构件的服务功能进行选择和连接。
2.3构件的测试
一个构件的开发设计完成以后，必须通过测试来检查构件能否满足任务书中的设计指标，是否符合构件规范中的结构关系。
构件测试是构件体系结构中的重要一环，关键的原因就是构件的开发者和使用者相分离，在实际应用过程中，构件的运行环境和条件未必与构件开发时的约束一致，而且构件的使用者往往不拥有构件的源代码，这就对构件提出了很高的质量要求，必须通过严格的测试来保证。例如美国的Ariane5火箭发射失败的原因就是复用了Arirdne4系统中的构件，而没有重新进完备的测试。
随着构件的规模和复杂性增加，构件的生产成本越来越高，构件中存在的缺陷和故障造成的各类损失也大大增加，甚至会带来灾难性的后果，因此，在构件入库前必须对构件进行全面的测试。确保每个构件的正确性，才能确保将来集成此构件的每个载荷应用软件的可靠性！
因此，相对于以往的应用软件测试，构件测试的项目更多、要求更高，需要针对构件的所有属性来设计测试用例，只有测试的有效性得到充分保证，构件化才能实用化。
2.4构件的应用
传统的星载嵌入式软件开发一般都要经过系统需求分析、概要设计、详细设计、单元测试、软硬件集成、确认测试等几个阶段。而利用构件进行软件开发的过程有别于传统的开发方法，通过分析开发过程中的构件需求，然后在构件库中提取可以沿用的构件，或者进行少量改造就可以适用的构件，将新开发的构件与库中提取的构件进行集成、测试，形成最终的软件产品。传统开发方法与构件开发方法过程的对比见图3：
可见，基于构件的星载软件开发，不能完全沿用以往软件开发的过程、质量控制、文档等技术要求，需要建立一套与之适应的开发方法和研制规范。
2.5构件的管理
对星载嵌入式软件构件的管理，应结合构件化的特点，从构件库管理、配置管理、绩效管理等多方面人手，才能真正把软件构件化工作落到实处。
设计出的各类构件需要在构件库中组织、存储，当构件达到一定规模以后，构件检索将是一项构件管理的重要工作。每个星载嵌入式软件构件都需要在时间、空间、能力、接口、环境、其他非功能性需满足的前提下，进行匹配分析来确定是否能复用，所以如何提高构件检索过程的效率、查全率和查准率是基于构件的软件开发成功的一个关键。
传统的构件检索方法如基于构件关键字描述的检索方法，其检索结果的查全率较高。然而由于缺乏对构件接口功能语义的准确描述，其检索结果的准确率和效率较低。另一方面，基于形式化描述方法的构件检索效率和查准率都高，然而出于形式化逻辑中精确的接口匹配要求，以及构件用户提供形式化的构件查询请求较为困难，导致检索结果的查全率较低。
因此，要在构件库结构基础上，设计检索方法，并开发适合星载软件开发环境的构件检索、构件编辑等工具。
构件库在建设的过程中，还要注意对构件的配置管理控制，对构件的版本必须严控，过多的构件分支肯定会给项目带来管理和技术上的风险。例如图4中，两个有关联的的构件A1.0，构件B1.0已经在某项目x中被复用和验证，项目Y中也集成了构件A和构件B，尽管构件B发生了技术状态变化，版本演变到了1.1，但集成后的应用功能、性能依然能保证正常，而到了项目z时，构件B演变到1.2，技术状态出现的变化却最终导致在集成时出现了bug。
此外，还需要开发构件管理工具，对构件的组装情况进行标识、记录、检索、追踪，便于对构件的错误修复和升级换代。
作为研制管理部门，还需要进行构件的绩效管理，既要从利益角度去激励设计构件用以复用，也要提高设计者的责任意识，达到利益与责任的均衡。
3结束语
总之，构件化带来的好处显而易见，但我们也要认识到构件复用带来的问题和困难，任意构件都只具有资源、功能、接口等一定条件下有限的适用性，构件错误会随着应用数量的增加而扩散，因此需要针对星载软件领域的实际来策划构件体系结构和模型，需要改进传统的开发方法，并建立与之适应的管理体制，只有精心规划、认真探索和开拓，才能通过软件构件化工作，真正提高星载软件的可靠性、研制效率和研制能力。
关键词：软件工程；构件；星载软件
引言
1968年，在北大西洋公约组织（NATO）召开的软件工程会议上，首次提出来了软件危机（SoftwareCrisis）的概念。会议上，Mcllroy提交了一篇题为《Mass-Produced Software Components》的论文，首次提出了软件构件（Software Components）以及构件工厂等概念，指出软件复用的一个重要基础就是需要有充足的软件构件。稍后，NATO制定了关于软件复用的一套指导性标准，其中就有关于构件及利用标准构件来实现软件复用的基本思路。
1软件构件化的好处及困难
所谓的构件就是指封装的、规范的、可重用的软件模块。广义上讲，构件可以是需求分析、设计、代码、测试用例、文档或软件开发过程的中其他产品；狭义上来说，构件一般指对外提供一组规约化接口的、符合一定标准的、可替换的软件系统的程序模块。
通过软件构件实现软件的复用，可以提高软件研制效率，增强软件可靠性，提升软件技术竞争力，实现共享知识促进软件开发的技术进步和标准化，从长远看，肯定能提高星载软件的研制能力。可以说软件构件是最有价值的软件资产。
但是我们也应该清醒地看到，在星载嵌入式环境下实现软件构件的困难，包括：
1.1环境的适应性
不同的用户需求产生了不同的载荷功能要求，不同的架构设计师构建了不同的卫星载荷的硬件系统，上层的需求变化，底层的硬件环境变化，那么处于中间层的星载嵌入式软件，需要有一种复用机制来以不变应万变，需要通过构件抽象去适应不同需求、不同硬件的差异，并由此负担了资源成本和效率的代价。
1.2新技术的追踪
复用构件是为了新产品的研制，然而软件产品耦合的因素很多，操作系统、处理器、编程语言……这些技术因素都在发展变化中，那么随之而来的问题是：大多数情况下，我们的研发部门只是技术发展方向的追随者，不是引领者，如何保证在目前的技术体系下设计的构件产品，有较长的使用寿命，在将来一段时期内的项目中都能被复用？积累的软件构件会不会有朝一日因为技术淘汰而用无可用？这就需要构件设计者能敏锐的把握新技术的发展方向并应用在构件设计中。
1.3资源的限制
一般的软件系统的处理器性能、存储器容量等资源都较为丰富，软件的性能要求方面不多，构件粒度的定义有较大的伸缩度。而星载嵌入式软件，软硬件结合紧密，需要充分考虑硬件因素，在软硬件资源局限性较大的同时，对实时性和可靠性要求高，并行、同步、中断、时序、可靠性等等方面有更多的苛刻限制，所以星载嵌入式环境下软件构件开发更有难度。
1.4复用的成本
相对于专用化设计，构件化显然需要额外增加软件的调度、接口、层次，增加了软件本身的通信成本、资源成本、规模成本和管理成本。
同时，为避免错误扩散，提高构件的适用能力，就必须构件经过更严格的软件测试，因此开发可复用构件的费用要比开发一般模块的费用要昂贵，W.Tracz认为开发可复用构件的费用比开发一般模块要超出30%～200%。收回在复用项目上的投资需要时间，W.Tracz发现，在一个软件上的投资只有在该可复用构件第3次被复用之后才能收回。
2构件体系的技术策划
星载嵌入式软件的构件体系建立是一个系统工程，也是一个循序渐进的过程，需要从研究构件特征及关系入手，建立一个构件模型，通过构件描述语言来解决构件的描述、组装问题；然后有目的的生产构件或者从已有星载载荷系统中挖掘提取构件；建立构件库对构件进行有效的分类、组织、检索及配置管理；在构件模型的基础上研究构件组装机制，并按照构件化软件架构开展软件的开发活动。
嵌入式环境下软件构件体系的架构示意如图1：
2.1构件模型
软件构件只有存在于一个定义好的软件环境（构件标准）里才能实现互联互通互操作，才能发挥效用，每个构件都提供了一套服务，软件怎么使用其他构件提供的服务、构件怎样命名、怎么在运行时发现新构件和它们的服务，因此首先必须建立一个软件构件模型，通过构件模型来全面定义构件的基本属性、构件接口结构、构件应用的框架、构件间的交互机制等内容，并提供创建构件和实现构件的规则。
国内外的研究机构根据自己的领域特征曾提出一些嵌入式构件模型，国外的如PECT、Koala、PBO以及PECOS等构件模型，国内的CBMESP、Z-CCM、DRSCDE等构件模型，
它们对实时嵌入式系统的构件开发都提出了有效的解决方案，但大多数都局限于具体实时嵌入式应用领域，与特定软件平台紧密相关，难以做到开放性、普适性，并在构件的易用性、可移植性、可靠性和质量保证方面仍存不足。
因此，通过对星载领域的软件进行分析，对其中的稳定需求和共同特征进行抽象，形成星载领域的构件模型，在此基础上，设计开发适合领域环境的构件，并加以提炼入库，以备将来复用。并且使用构件描述语言以严格而又易于理解的方式，为构件交互、构件组装和构件开发人员提供全面准确的构件信息，将构件模型进行形式化的描述。
构件模型一般可以从概念、内容、语境等角度，对构件的属性、接口、环境、关联等若干个主要元素进行定义，一个典型的构件模型元素结构如图2：
2.2构件的开发和组装
领域模型建立后，就可以按照模型定义，借鉴通用构件模型的某些特点，从实际开发环境和开发平台出发，研究分析、设计出适合星载领域软件开发和组装的构件，明确定义构件的接口以及接口配置，并进行文档化；另外，还可以通过软件再工程的手段，从已有的大量星载载荷软件资产中标识并提取可复用的构件。 构件的开发设计一定要摆脱与特定硬件平台、软件平台的耦合，以提高构件的普适性、可移植性和高复用性。
构件的组装集成是软件构件中的核心技术，构件组装集成是要通过构件的接口或者连接件来协调各个构件的行为，通过将一定数量的构件按照约定的交互机制及组装机制集成，使通过构件组合成的软件产品能够满足星载实时嵌入式系统的特定功能及非功能盖求，如服务功能、资源约束限制、环境依赖及构件时间行为等，从而实现构件的价值。
按照软件的基本结构，经常采用的构件组装机制，包括构件顺序组装、构件选择组装、构件循环组装、构件并行组装、构件同步组装和构件中断组装。
星载嵌入式环境下的构件组装受到从构件模型、需求，到构件粒度大小、组装平台特点、运行环境等多种要素的制约，同时兼顾构件之间的行为联系、数据联系等等问题，因此构件组装必须要需要结合具体的应用要求，对构件的服务功能进行选择和连接。
2.3构件的测试
一个构件的开发设计完成以后，必须通过测试来检查构件能否满足任务书中的设计指标，是否符合构件规范中的结构关系。
构件测试是构件体系结构中的重要一环，关键的原因就是构件的开发者和使用者相分离，在实际应用过程中，构件的运行环境和条件未必与构件开发时的约束一致，而且构件的使用者往往不拥有构件的源代码，这就对构件提出了很高的质量要求，必须通过严格的测试来保证。例如美国的Ariane5火箭发射失败的原因就是复用了Arirdne4系统中的构件，而没有重新进完备的测试。
随着构件的规模和复杂性增加，构件的生产成本越来越高，构件中存在的缺陷和故障造成的各类损失也大大增加，甚至会带来灾难性的后果，因此，在构件入库前必须对构件进行全面的测试。确保每个构件的正确性，才能确保将来集成此构件的每个载荷应用软件的可靠性！
因此，相对于以往的应用软件测试，构件测试的项目更多、要求更高，需要针对构件的所有属性来设计测试用例，只有测试的有效性得到充分保证，构件化才能实用化。
2.4构件的应用
传统的星载嵌入式软件开发一般都要经过系统需求分析、概要设计、详细设计、单元测试、软硬件集成、确认测试等几个阶段。而利用构件进行软件开发的过程有别于传统的开发方法，通过分析开发过程中的构件需求，然后在构件库中提取可以沿用的构件，或者进行少量改造就可以适用的构件，将新开发的构件与库中提取的构件进行集成、测试，形成最终的软件产品。传统开发方法与构件开发方法过程的对比见图3：
可见，基于构件的星载软件开发，不能完全沿用以往软件开发的过程、质量控制、文档等技术要求，需要建立一套与之适应的开发方法和研制规范。
2.5构件的管理
对星载嵌入式软件构件的管理，应结合构件化的特点，从构件库管理、配置管理、绩效管理等多方面人手，才能真正把软件构件化工作落到实处。
设计出的各类构件需要在构件库中组织、存储，当构件达到一定规模以后，构件检索将是一项构件管理的重要工作。每个星载嵌入式软件构件都需要在时间、空间、能力、接口、环境、其他非功能性需满足的前提下，进行匹配分析来确定是否能复用，所以如何提高构件检索过程的效率、查全率和查准率是基于构件的软件开发成功的一个关键。
传统的构件检索方法如基于构件关键字描述的检索方法，其检索结果的查全率较高。然而由于缺乏对构件接口功能语义的准确描述，其检索结果的准确率和效率较低。另一方面，基于形式化描述方法的构件检索效率和查准率都高，然而出于形式化逻辑中精确的接口匹配要求，以及构件用户提供形式化的构件查询请求较为困难，导致检索结果的查全率较低。
因此，要在构件库结构基础上，设计检索方法，并开发适合星载软件开发环境的构件检索、构件编辑等工具。
构件库在建设的过程中，还要注意对构件的配置管理控制，对构件的版本必须严控，过多的构件分支肯定会给项目带来管理和技术上的风险。例如图4中，两个有关联的的构件A1.0，构件B1.0已经在某项目x中被复用和验证，项目Y中也集成了构件A和构件B，尽管构件B发生了技术状态变化，版本演变到了1.1，但集成后的应用功能、性能依然能保证正常，而到了项目z时，构件B演变到1.2，技术状态出现的变化却最终导致在集成时出现了bug。
此外，还需要开发构件管理工具，对构件的组装情况进行标识、记录、检索、追踪，便于对构件的错误修复和升级换代。
作为研制管理部门，还需要进行构件的绩效管理，既要从利益角度去激励设计构件用以复用，也要提高设计者的责任意识，达到利益与责任的均衡。
3结束语
总之，构件化带来的好处显而易见，但我们也要认识到构件复用带来的问题和困难，任意构件都只具有资源、功能、接口等一定条件下有限的适用性，构件错误会随着应用数量的增加而扩散，因此需要针对星载软件领域的实际来策划构件体系结构和模型，需要改进传统的开发方法，并建立与之适应的管理体制，只有精心规划、认真探索和开拓，才能通过软件构件化工作，真正提高星载软件的可靠性、研制效率和研制能力。