软件平台化研发的策略.doc

软件平台化研发的策略
1 概述
软件是公司创新产品之源，基于平台化架构研发的软件可以显著提升产品的可靠性，缩短新产品的研发时间。
所谓“平台”是指实现信息处理功能的计算环境，是一套基础设施，用来支撑公司产品各种测量与分析及管理应用，并为这些应用提供一个标准的运行环境。软件平台可以裁减和组合，并通过标准化应用编程接口（API）为各种不同应用提供服务。
平台一般具有以下特性：
(1)开放性：“平台”的实现应严格遵循统一的标准、规范和信息格式，通过最大限度的软件重用和数据共享，提供标准的服务和统一的编程接口，以实现各系统（各部分）之间的互操作，实现软件和用户在不同档次的软硬件环境之间的移植。
注：“平台”一般由高级技术人员研制；而用户一般为工程实施人员。
(2)可移植能力：“平台”的构成应能使软件和用户，方便地从一个硬件或软件环境转向另一个硬件或软件环境中使用。
(3)安全保密能力：“平台”应根据共性的安全需求，制定相应的安全策略，确定“平台”的安全框架，实现基本的安全机制和基本的安全服务，建立公共的安全基础设施，使得基于“平台”的产品能按各自的安全需求，实现相应的安全功能，保障安全可信。
(4)系统管理能力：“平台”应有能力管理平台操作、资源和用户，实现系统配置、故障和性能管理。
(5)互操作能力：“平台”的构成应能使两个或多个系统（部分）之间有效地互相提供服务、交换和使用数据。
(6)可伸缩能力：为适应不同规模和不同处理负荷的需要，“平台”应具有适应工作负荷变化的灵活配置能力，使应用软件对系统规模的变化有较强的适应能力。
(7)分布处理能力：“平台”应提供远端过程计算和分布式对象处理的能力，使各业务、操作以及信息传送能够在指定的多个物理或逻辑分散的平台上实现。
(8)网络化的处理能力：“平台”应通过一组标准的通信接口，实现信息处理和细心你传送一体化，使网络中合理部署硬件，都有能力实现所要求的处理和操作。
2 平台的技术参考模型

图1 平台的技术参考模型图
2.1 应用支撑软件
“平台”所属各应用支撑软件，一般是外购进入，它们除遵循相应的标准外，还提供有对外接口规范。
2.2 应用平台
2.2.1 软件工程服务
应提供从应用软件的需求分析、设计、编码、测试到维护的整个生命周期的全过程的支持环境和计算机辅助软件工具，以及程序设计语言服务等。
2.2.1.1 支持环境
2.2.1.2 程序设计语言
2.2.2 用户接口服务
用户接口服务通过人机交互服务API提供外观表示和运作方式的支持；通过人机交互服务外部环境接口向用户提供人机交互支持。
2.2.3 数据管理服务
对多个应用共享的数据进行独立管理的能力。
2.2.4 数据交换服务
为各种应用之间和应用与外部环境之间进行数据交换（包括数据的描述、存储、访问和传送等）提供服务，通过定义数据格式以支持互操作。包括文档、图形、地理/空间、图像、视频、音频、大气/海洋等数据交换服务。
2.2.5 图形服务
图形服务应支持图形的产生和处理，包括二、三维图形对象的定义、显示、输入、输出、存储等，使图形处理独立于图形显示、硬拷贝和输入设备。
2.2.6 通信服务
(1)应能屏蔽异种通信的差异、向应用提供可靠、安全、实时的端到端\点对点的信息传输；
(2)机外设备间应采用以TCP/IP为主、TCP/IP和OSI协议集相结合的网络体系结构，机内单元之间采用串口直连；
(3)能实现实时传输服务软件和网络安全服务的功能，并向上提供统一的编程接口。
2.2.7 操作系统服务
操作系统是操作和管理应用平台的核心服务，它提供应用软件和应用平台之间的接口，支持应用软件的操作。操作系统服务包括核心操作、外壳和实用程序。
2.2.8 中文化服务
应在系统中提供一组服务和接口，支持基本汉字处理、中文风格人机界面等。
2.2.9 安全服务
平台必须为特定的信息系统提供公共的安全基础设施，为各种不同的应用提供统一的安全应用编程接口，使特定系统可以根据该系统安全需求选择所需强度的安全机制和所需的安全服务。
安全服务应用提供以下功能：
(1)操作系统的安全服务应在C2级或C2级以上的基础上提供信息安全标记、用户安全标记和鉴别、强制访问控制等安全功能；
(2)网络安全服务应提供鉴别服务（包括数据源和身份鉴别）、访问控制服务、数据机密性服务、数据完整性服务、抗抵赖服务（包括源发方抵赖和目的方抵赖）和可用性等六类基本安全服务。
(3)数据库安全服务应提供在商用数据库系统基础上的库内加密及库外加密功能，对国产化数据库系统应提供多级访问控制功能。
(4)安全管理应提供包括安全事件审计跟踪工具和安全评测工具再内的各种实用程序。其中，安全事件审计跟踪工具一般包括异常安全事件的监测、记录、报警和触发相关安全处理程序以及安全记录分析工具等。
(5)安全服务可通过多种安全机制来实现，比如，加密机制、数字签名机制、访问控制机制、数据完整性机制、鉴别交换机制、信息量填充机制、路由控制和公证机制等，这些机制可单独使用，也可以组合使用。
2.2.10 系统管理服务
包括故障管理、配置管理、性能管理、记帐管理和安全管理等功能。
2.2.11 分布式计算服务
支持分布异构环境下应用的协同工作，实现资源透明。
2.3 应用编程接口（API）
应用编程接口是“平台”上的特定应用与“平台”服务软件之间、“平台”内各层服务软件之间以及同层内不同服务软件之间的接口。采用标准化的、统一发布的公共API，对应用的可移植性、人机界面的一致性以及系统的互操作性提供有力的保证。
这些公共API应用包括在“平台”的程序员手册、编程参考手册或相应文档中。
2.4 外部环境接口（EEI）
外部环境应包括与应用平台交换信息的三类外部实体，即：用户（人）、信息交换实体（例如可移动盘等）及通信实体（例如电话线、网线、交换设备等）。主要有以下三类接口，这些应包含在“平台”的程序员手册、编程参考手册或相应文档中。
(1)人/机交互服务：定义了人与应用平台之间的物理交互接口。比如：显示器、键盘、鼠标、音频设备等。
(2)信息服务：它定义了应用平台与外部驻留存储服务之间的接口。它规定了标准格式和语法将保证数据可移植性和应用互操作性。
(3)通信服务：它为应用软件及应用应用支撑软件与外部实体之间的交互服务提供接口。必须将协议的状态、格式和语法标准化。
3 产品的组成原理
3.1 硬件的接口
公司产品硬件的接口主要有以下五类，具体见下图2所示。
(1)人机交互接口：应提供键盘、鼠标与显示器等人机交互接口，键盘与鼠标接口一般为PS2或USB接口，显示器接口一般为VGA或DVI接口。
(2)设备控制接口：应提供主控电脑与仪器设备控制器之间的通信接口，主要包括PCI、cPCI、LAN与USB等接口。
(3)程控总线接口：提供主控电脑或仪器设备控制器与仪器设备之间的通信接口，一般包括LAN、USB、GPIB、IEEE1394、PXI、VXI/MXI、LXI与RS-232等接口。
(4)开关部件接口：作为仪器设备与通用测试接口中的接收器之间的接口，一般应符合GJB5936-2007第5章的要求。
(5)接收器夹具接口：作为通用测试接口中的接收器与测试接口适配器中的夹具之间的接口，一般应符合IEEE1505的规定。

图2 产品的硬件接口示意图
3.2 软件的组成
软件组成见下图3。

图3 软件的组成示意图
软件的功能结构模型见下图4。

图4 软件的功能结构模型图
(1)用户接口层：该层作为人机界面应完成与用户间的交互，应至少提供对话框、快捷键、菜单与命令按纽等人机交互方式。
(2)测试管理核心层：该层应提供软件的核心构件，维护与管理核心构件之间的通信中枢，将底层的功能服务进行无缝融合并根据上层需求展现给用户接口。
(3)外围服务层：该层主要完成具体应用的功能服务，包括测量控制、诊断推理、维护与信息管理等，这些功能服务应该是动态的、可扩充的，做到应用与具体硬件无关。
(4)测试驱动层：该层作为测试程序与仪器设备、开关部件与被测件等相关资源进行特性的纽带，测试驱动程序应实现同功能仪器设备间的互换。
(5)仪器设备层：该层应直接面向各类测试资源、仪器设备层的输入/输出控制一般应基于VISA函数库，做到仪器驱动器与程控总线无关。
3.3 软件的接口
软件的接口示意见下图5所示，一般有以下接口：
(1)软件架构接口：该接口应为二次软件开发者提供通用方法，可约束影响自动测试软件操作的系统需求、软件协议和交互规则，并能提高软件的可移植性。
(2)软件人机接口：该接口应遵循友好、一致的原则，一般应在人机交互界面的颜色、文字、控件、快捷键、菜单与帮助方面保持协调一致。
(3)应用开发环境接口：视自动测试系统需求规定测试程序的开发与调试接口，所选用的应用开发环境必须得到所选用软件架构的支持。
(4)测试程序文档接口：测试程序文档接口应有助于用户来理解测试程序的设计原理与测试操作过程。
(5)诊断服务接口：应用于提供诊断推理所提供的基本服务。
(6)运行时间服务接口：运行时间服务接口应规定测试程序执行期间调用测试程序的方法。
(7)资源管理接口：提供测试程序与仪器设备资源分开的基本方法，应便于开发虚拟仪器，提高测试程序的可移植性。
(8)仪器设备类接口：服务于测试过程或运行时服务与仪器驱动器之间，应有助于提高测试程序的可移植性。
(9)开关部件类接口：服务于测试过程或运行时服务与仪器驱动器之间，应有助于提高测试程序的可移植性。
(10)接口适配器类接口：服务于测试过程或运行时服务与仪器驱动器之间，应有助于提高测试程序的可移植性。
(11)仪器驱动类接口：一般应符合VISA规范。
(12)仪器通信管理器接口：
(13)多媒体格式接口：视功能需求用于规定与多媒体编辑工具和用户之间传递的超联结文本、音频、视频和三维物体模型信息的格式。
(14)第三方软件接口：一般以文件形式与其他软件进行数据通信。

图5 软件的接口示意图
3.4 信息交换
3.4.1 内部各功能构件之间的信息交换
(1)内容一般包括：仪器描述信息、测试适配信息、被测件描述信息、测试配置信息、测试描述信息、测试结果信息与诊断信息。
(2)一般应通过测试管理平台软件提供的框架机制来进行交换，一般应以可扩展标记语言（XML）文档的形式存储；
(3)内部不适合使用多种数据库来存储交换信息，应通过开放式数据库连接ODBC进行数据库访问，系统软件应使用结构化查询语句SQL对数据库进行查询、定义、操纵与控制。
3.4.2 系统之间的信息交换
(1)内容一般包括被测件描述信息、测试配置信息、测试描述信息、测试结果信息与诊断信息。
(2)信息交换处理应基于自动测试标注语言（ATML）格式，应符合IEEE1671的规定。
3.4.3 系统与外部环境间的信息交换
(1)内容一般包括被测件描述信息、测试配置信息、测试结果信息与诊断信息。
(2)信息交换处理应符合IEEE1671的规定。
4 软件平台化研制的注意事项
在软件平台化研制过程中，除了要注意建立合理的框架结构，还要注意：
(1)将不可变（或不易变的）功能模块做好封装，按照标准的接口，以此作为搭建平台的基础。
(2)将可变的，做好功能分解，一般使用封装的功能模块进行组合实现；
(3)将易变的，做好前台表现与后台处理之间的剥离，将后台处理进行封装。
一要注意产品基线（即版本）控制。也就是要对当前成熟的予以固化，任何改变都要经过批准，严禁私自改变。具体控制点：
(1)设计与测试文档要严格控制。
(2)对运行依赖的硬环境（CPU、主板、内存、外设等）的厂家、型号等予以固化；
(3)对运行依赖的软环境（操作系统名称、版本号、驱动等）予以固化；
(4)对软件的实现语言、开发环境、调试环境、测试环境等进行固化；
(5)对产品的现有功能进行原理固化。
二要注意组织管理的质量控制。
重点要注意如下控制：
(1)平台设计开发人员最好不要直接面向客户个性化软件应用的开发；
(2)平台设计开发不要由少数人（指两、三个人）完成；
(3)不能测试本人设计开发的软件功能模块或代码；
(4)平台的各功能模块构件之间要有清晰的接口关系，成熟的功能模块构件一定要安排专人做好封装（代码标准化、文档留档）、通过测试。
(5)适当鼓励平台设计开发人员，可以代码重用率作为软件设计开发人员的质量目标予以考核。