（电路与系统专业论文）航天地面应用系统可复用数据处理系统研究.pdf

原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师的指导下，独 立进行研究所取得的成果。除文中已经注明引用的内容外，本论文不 包含任何其他个人或集体已经发表或撰写过的科研成果。对本文的研 究作出重要贡献的个人和集体，均已在文中以明确方式标明。本声明 的法律责任由本人承担。 论文作者签名矗幽盘 日期：坐 关于学位论文使用授权的声明 本人完全了解山东大学有关保留、使用学位论文的规定，同意学 校保留或向国家有关部门或机构送交论文的复印件和电子版，允许论 文被查阅和借阅；本人授权山东大学可以将本学位论文的全部或部分 内容编入有关数据库进行检索，可以采用影印、缩印或其他复制手段 保存论文和汇编本学位论文。 ( 保密论文在解密后应遵守此规定) 论文作者签名鬣篁亟堑导师签名：虹日期：坐乡 山东大学硕士学位论文 摘要 在软件发展的过程中，人们一直在探索各种形式的软件复用技术和思想，以期提 高软件开发的效率，增强软件应对需求变化和环境变化的能力。成熟的平台+ 插件的 软件设计思想以其开放性和可复用性得到软件行业的认可，并被广泛的应用于许多软 件系统的设计和实现中 数据处理分系统是所有航天工程都必须包含的重要分系统之一。对于不同航天工 程的数据处理分系统，他们内部的子系统大多都具有相似的功能。对这些子系统进行 重复的设计和实现显然会降低工程的开发效率。然而，目前这些子系统的设计与实现， 都只针对特定的航天器，很少考虑功能扩展和升级问题，基本不具有可复用性。为了 制作出具有良好扩展性和灵活性的数据处理分系统软件，本文提出了将平台+ 插件思 想应用于此类系统设计的解决方案。 本文在介绍了数据处理分系统的功能需求和软件发展过程中出现的复用技术之 后，阐明了论文选择平台+ 插件思想设计数据处理分系统的原因，并尝试使用该思想 分别设计和实现了监视和控制子系统( 数据处理分系统的子系统之- - ) 的平台部分和 插件部分，说明了平台+ 插件思想设计软件的关键是插件的接口定义。监视和控制子 系统作为数据处理分系统的一部分在嫦娥工程中的应用，验证了平台+ 插件的设计思 想在数据处理分系统中的可用性。论文最后通过分析这个子系统可以应对的环境变化 和需求变化，证明了平台+ 插件思想设计的软件具有良好的扩展性和灵活性。 关键词 可复用平台插件接口数据处理分系统 坐至奎兰堡圭兰竺丝苎 ar e s e a r c ho nr e s u a b l ed a t ap r o c s s i n gs y s t e mo f g r o u n da p p l i c a t i o ni na e r o s p a c ee n g i n e e r 矾g a b s t r a c t i no r d e rt or a i s et h ee f f i c i e n c yo f s o f t w a r ed e v e l o p m e n ta n di n c r e a s es o f t w a r e ，sa b i l i t y t op r o c e s st h ec h a n g e so fn d sa n dc o n d i t i o n s p e o p l eh a v eb e e ne x p l o r i n ga l lk i n d so f r e u s a b l em e t h o d sa n di d e a si nt h ec o u r o f s o f t w a r ed e v e l o p m e n t1 1 1 ei d e ao f p l a t f o r m + p l u g - i n si sm a t u r ea n dh a sb e e nr e c o g n i z e df o ri t sr e u s a b i l i t ya n do p e n n e s s ，w h i c hm a k e si t b ew i d e l yu s e di np l e n t yo f f a m o u ss o f t w a r e md a t ap r o c e s s i n gs y s t e m p s ) i so n eo f t h em o s ti m p o r t a n ts y s t e m si na e r o s p a c e e n g i n e e r i n g m o s to fs u b s y s t e m so fd p sf o rd i f f e r e n ts p a c e c r a f t sm a yh a v es i m i l a r f u n c t i o n s i fa l lo ft h e ma r ed e s i g n e da n dr e a l i z e dr e p e a t e d l y , t h ee f f i c i e n c yo fp r o j e c t d e v e l o p m e n tm u s t b e d e p r e s s e d h o w e v e r , t h e s es u b s y s t e m sa r ed e s i g n e dw i t h o u t c o n s i d e r i n gt h er e u s a b i l i t yi nt h ep a s t , t h e yc a no n l yb eu s e df o rs p e c i a ls p a c e c r a t l s i n o r d e rt oa c c o m p l i s he x t e n s i b l ea n dr e u s a b l ed p s s o f t w a r e , t h es o l u t i o nt ou s ep l a t f o r m + p l u g - i u si d e at ot h ed e s i g no f d p si sp r o p o s e d i nt h i sp a p e r , t h ef u n c t i o n so f d p sa n dr e u s a b l et e c h n o l o g ya n di d e a sa p p e a r e db e f o r e a r ei n t r o d u c c df i r s t , t h e nas u b s y s t e mo fm o n i t o ra n dc e n t r o l ( o n eo fs u b s y s t e m so fd p s ) u s i n gp l a t f o r m + p l u g i mi d e ai sd e s i g n e da n dr e a l i z e d , i n c l u d i n gi t sp l a t f o r ma n da h1 h e p l u g - i n s i nt h i sc o u r s e ，w ef i n d t h ef a c tt h a tt h e d e f i n i t i o no fi n t e r f a c ei st h em o s t i m p o r t a n tf o ru st od e s i g ns o f t w a r ew i t ht h i si d e a f i n a l l y , t h i sp a p e rr e a c h e st h ec o n c l u s i o n t h a tt h es o r w a r ed e s i g n e dw i t hp l a t f o r m + p l u g - i n si d e ah a sb e t t e ra b i l i t yt op r o c e s st h e c h a n g e so f n e e d sa n dc o n d i t i o n s t h em o n i t o ra n dc e n t r o ls u b s y s t e mi si m p l e m e n t e di nt h e c h a n g ep r o j e c ta sa p a r to f d p s ，w h i c hp r o v e st h a tp l a t f o r m + p l u g - i n si d e ac a nb eu s e di n t h e d p s k e y w o r d ： 6 r e u s a b l e ，p l a t f o r m ，p l u g 硫，i n t e r f a c e 。d a t ap r o c e s s i n gs y s t e m ( d p s ) 山东大学硕士学位论文 第l 章引言 地面应用系统是航天工程的五大系统1 之一。其主要任务是制定航天器有效载荷 的探测计划，提出航天器有效载荷在轨业务运行的要求并监视和控制有效载荷在轨运 行；在测控系统和卫星系统的配合下完成卫星下行科学( 探测) 数据的接收、传输、 处理；以及科学数据的存储、归档、备份、发布i 】； 作为地面应用系统的一个分系统，数据处理分系统2 是地面应用系统的核心之一 它负责对星上下传的原始数据进行不同级别的数据处理，形成供科学研究进一步应用 的处理数据产品；另外，它还提供一个数据处理试验的平台，方便科学家进行模拟试 验、处理方法测试和升级。在整个数据处理过程中，操作员需要对每一个处理流程的 处理状态、处理结果、数据处理分系统所在的网络各主机的运行状态有足够的了解， 以便为进一步的操作控制提供充分的依据，从而保证最终获得科学家希望得到的数据 产品。因此，数据处理分系统中一个非常重要的子系统即为监视和控制子系统。 本课题的研究内容是平台+ 插件这种复用思想在数据处理分系统中的应用，即研 究数据处理分系统的平台+ 插件的设计与实现。由于时间限制，论文主要完成数据处 理分系统的监视和控制子系统。 本章主要阐述课题选题背景、意义，课题的发展历史、研究现状，并概括介绍本 文各章节的内容。 “ 1 1 选题的背景及意义 航天工程对国家和民族的发展具有深远的影响，它可以满足国防、信息产业、基 础科学、国土资源等领域各种不同的需求，对国家发展有着战略性的影响。作为航天 工程的五大系统之一，地面应用系统是航天工程科学探测目标能否实现的关键，也是 此类工程科学价值的最终体现。 从1 9 7 0 年东方红1 号卫星发射至今，我国的航天工程取得了长足的发展。每一 个航天任务都包括一个地面应用系统，从而也包含数据处理分系统。虽然不同的航天 器运行的姿态、轨道、装备的有效载荷、运行目的等均有不同，但不同航天器对应的 数据处理分系统除了在数据的处理方法方面有较大的区别外，其总体结构以及内部部 分子系统的功能都具有相似性。对这些具有相似功能的子系统重复开发显然会降低工 1 卫星及有效载荷运载、发射场、测控和地面应用，特定航天工程如载人航天工程包括七大系统。 2 一般整个工程分为系统、分系统、子系统，对应的设计人员为总设计师、主任设计师、主管设计师 7 山东大学硕士学位论文 程的开发效率，也使得开发人员很难从繁琐的工作中解脱出来，投入足够的精力去研 究数据处理算法。可复用系统的研究，将有助于改善这种状况。 中国科学院空间科学与应用研究中心( 下简称空间中心) 是为作者从事课题研究 提供工作环境的单位。在课题开始之前，该中心承担过地球双星探测工程以及载人航 天工程的数据处理分系统的研制；在课题研究过程中，空间中心正承担着绕月探测工 程的数据处理分系统的设计与实现工作。由于今后仍有可能承担此类工程的研发，空 间中心准备在绕月工程的研制过程中探索复用技术在此类分系统中的应用。尽管这种 探索可能影响绕月探测工程的数据处理分系统本身的研制进度，但会为今后此类工程 打下良好的基础。 在技术背景方面，计算机软件发展过程中产生的各种概念和思想，如面向过程方 法中使用的函数，面向对象方法中的类、继承、封装、多态等概念，组件规范，经典 的设计模式，平台+ 插件的系统设计思想都在软件复用领域体现着自己的特点( 虽然他 们主要的产生原因和应用领域未必是软件复用) 。综合复用效果、系统平台环境，开 发语言等因素，我们选择了平台+ 插件的思想作为可复用系统设计的指导思想；这种 可复用系统设计完成之后，可以在平台不变的情况下，通过开发不同的数据处理插件 来适应变化的环境和需求，使研究更集中于对数据的具体分析，从而提高研发效率。 1 2 课题发展和研究现状 源于航天工程的特殊性，国家只把数据处理分系统的工程任务交由为数不多的几 家单位来完成，这些单位在数据处理分系统的设计与实现方面积累了相当的经验。虽 然数据处理分系统的划分在不同的航天工程中不断的得以复用，但分系统内具体予系 统的研制却只针对特定的航天器，很少考虑功能扩展和升级问题，基本不具有可复用 性。另外，因为国内与国外交流的局限性和工程涉及的安全性，我们对国外的现状所 知甚少。 课题在技术方面的研究现状是，平台+ 插件的思想是一种比较成熟的思想，这种 思想把一个复杂庞大的系统分成多个部件( 插件) ，每一个部件保证其自身的独立性， 各个部件之间通过一个公共的渠道( 平台) 进行交互，进而实现整个软件的功能；这 种思想的使用可以促使系统不同部件的并行开发，提高软件的开发效率，其关键是定 义各个部件的外部接口。平台与插件的关系如图1 1 ： 8 山东大学硕士学位论文 p l a t f o r m 甲台部分提供各个插件 彼此访q j 的公共渠道 对插件必须实现韵功能 进行定义，对所有的插 件进行管理： 插件部分提供各种功能 的具体实现； 图1 1 ：平台与插件的关系图示 自平台+ 插件的思想产生之后，出现了许多使用这种思想的软件系统：e c l i p s e 、 m i c r o s o f to f f i c e 、p h o t o s h o p 等。在论文写作之前，我们还没有发现数据处理分系统 的平台+ 插件实现。虽然将平台+ 插件思想应用于数据处理分系统的研制是一种尝试， 但已有的各种平台+ 插件系统的运行实践证明这确实是一种可行的选择。 ” 1 3 论文主要工作和行文结构 论文作者在论文期间主要完成的工作包括学习数据处理分系统相关知识，研究现 有复用技术和思想，选择平台+ 插件思想设计和实现数据处理分系统的监视和控制子 系统，并通过分析这个子系统可以应对的环境变化和需求变化，证明了平台+ 插件思 想设计的软件具有的灵活性和扩展性。 8 论文的主要结构如下：本章介绍论文研究的对象，论文研究的意义和课题发展的 现状；在第二章中，论文将进一步描述课题领域的相关知识、课题愿景( v i s i o n ) 的提出、 可行性分析以及课题的需求；第三章介绍论文涉及的主要概念；平台和插件，对其他 的复用方法进行讨论，并交代了课题选择平台+ 插件作为中心复用思想的原因；第四 章和第五章是论文的重点，分别介绍了监视和控制子系统的平台部分和各种插件的设 计和实现；最后一章中归纳结论，对课题可能存在的问题进行了讨论，并对课题未来 的工作进行了展望。 ， 、 i 9 山东大学硕士学位论文 第2 章课题分析 本章首先介绍了数据处理分系统在航天工程中的位置，然后描述课题愿景的产 生、可行性分析，重点是课题的需求分析部分。 2 1 数据处理分系统在航天工程中的位置 在航天工程中的五大系统中，卫星及有效载荷系统主要完成星上有效载荷的研 制；运载系统主要负责用来发射卫星的火箭的研制工作；发射场承担卫星发射、上升 阶段的测控任务；而测控系统负责在卫星运行过程中对卫星进行遥测和遥控，是卫星 升空后，地面对卫星唯一的测量、跟踪与控制途径；地面应用系统主要完成有效载荷 运行计划的制定、有效载荷运行状态的监视、星上数据的接收、数据的处理、处理后 产品文件的归档、发布等等。 传统上一个地面应用系统( 包括绕月探测工程的地面应用系统) 由运行管理、数据 接收、数据处理、数据管理、科学应用与研究五个分系统组成，这五个分系统的功能 描述如下【l l ： 1 运行管理分系统：部署在地面应用系统的总部，主要负责星上有效载荷和地 面应用系统的业务运行管理，包括对有效载荷的监视、控制等； 2 数据接收分系统：部署在地面数据接收站( 如绕月探测工程中包括云南昆明 和北京密云两个接收站) ，主要负责接收并向地面应用系统总部转发卫星下行 的数据； 3 数据处理分系统3 ：部署在地面应用系统总部，它按照运行管理分系统制定下 发的业务运行计划，以数据驱动或时问驱动的方式自动运行，对下行的原始 数据进行处理，生成各种级别的数据产品，并送数据管理分系统归档； 4 数据管理分系统：部署在地面应用系统总部，主要负责数据的存储、备份、 存档与发布： 5 科学应用与研究分系统：部署在地面应用系统总部，主要负责制定科学计划， 组织、开展探测数据的专题研究和综合研究，生产科学应用数据产品和科学 普及产品等。 因此，数据处理分系统在航天工程中的位置可用图2 1 来表示： 卫星下行的原始数据是以二进制流格式存在的，处理功能把这个二进制流转换成具有特定含义的、载荷专家能 够识别和理解的物理量。因此，处理是载荷专家分析使用数据的前提，故而又称为。预处理 山东大学硕士学位论文 航 天 工 程 卫星 运载 地面应用 测控 发射场 运行管理 数据接收 羔盔瑟罂 科学研究 数据管理 图2 1 ：数据处理分系统在航天工程的位置图示 2 2 课题愿景( v i s i o n ) 的提出 作者在空间中心的指导老师胡钛副研究员一直承担着数据处理分系统的总体设 计和研制工作，曾参与设计完成了地球双星探测工程以及载人航天工程的数据处理分 系统，在数据处理分系统开发方面积累了相当丰富的经验。重复的对系统内相似功能 子系统的设计与实现促使胡钛产生一个想法：是否可以做一些可复用的处理子系统， 使今后具体子系统的实现能够构建在这些可复用的子系统之上，达到即降低工程的复 杂度，又不限制具体工程的设计和实现呢? 2 3 课题可行性分析 课题展开这前，我们在软件环境和硬件环境两个方面进行了调研，展开了对这个 愿景的可行性分析： 2 3 i 软件环境支持 空间中心对于数据处理分系统需求的熟悉以及地球双星探测工程和载人航天工 程的数据处理分系统研制积累的经验，有助于可复用系统的研究。作者在课题展开之 前对空间科学相关知识的一无所知，是课题研究工作展开的一大障碍，空间中心的这 一优势为清除这一障碍提供了支持；同时，正在研制的绕月探测工程的数据处理分系 统与课题研究工作有部分重叠；另外，在技术方面，各种复用方法和思想的存在，之 前我们对经典设计模式的学习、在编程方面积累的还算丰富的经验，都为课题的完成 提供了有力的支持。 2 3 2 硬件环境支持 空间中心可以提供计算机和办公环境，提供地球双星探测工程以及载人航天工程 的数据处理分系统的部分代码和设计文档，并允许我们参观这两个系统运行的机房和 山东大学硕士学位论文 全套系统界面，这将有利于我们对数据处理分系统获得全面的感性认识。 2 3 3 可能的限制 数据处理分系统是一个复杂的分系统。根据国内处理分系统研制单位对分系统划 分的经验，一个数据处理分系统往往包括了数据处理子系统、数据处理的监视控制子 系统( 下简称监视和控制子系统) 、数据处理调度管理子系统、数据再处理子系统等。 源于时间的限制，对处理分系统中所有子系统进行全面的研究是不现实的，课题只能 针对几个主要的子系统，并以此积累经验，为今后其他子系统的设计和实现做准备； 作者在绕月探测工程的数据处理分系统中承担了监视和控制子系统、数据再处理子系 统、执行器模块( 调度管理子系统的一部分) 、日志查看器的设计和实现工作，其中 监视和控制子系统相对最为重要4 ，因此课题把监视控制子系统作为主要的研究对象， 其他子系统通过移植平台和开发新的插件来实现。 基于以上考虑，接下来的需求分析以及第四、五章的平台和插件的设计，主要面 向监视和控制子系统。， 2 4 数据处理分系统综述 了解课题主要研究对象监视和控制子系统的功能需求之前，有必要先介绍一下整 个数据处理分系统及其各子系统的运行环境和功能。在可能的限制章节中提到的数据 处理分系统的划分，是业界经验的积累并进一步完善的结果，因为空间中心本身对这 种系统的划分具有充分的信心，因此我们的研究并不改变这种大的系统轮廓。 2 4 1 运行环境 数据处理分系统运行的软件环境一般包括； 1 操作系统：a i x 操作系统( 主要应用i b m 服务器) ，m i c r o s o f tw i n d o w s 操作系 统( 应用在各种工作站) ； 2 数据库系统：大型的数据库( 如o r a c l e ) ： 3 网路协议：主机之间一般通过t c p i p 协议互连。 硬件环境主要包括： 1 服务器：双机( 或者多机) 备份服务器； 2 工作站：若干微型机作为操作和控制终端。 4 在整个处理分系统中，监视和控制子系统虽然不是功能的核心，但却是操作员了解整个分系统运行状况的唯一 途径，是整个分系统中最重要的交互子系绕 山东大学硕士学位论文 3 存储设备：一个s a n 5 或其他存储设备； 4 其他设备：一些辅助设备如数字化仪、绘图仪、打印机等； 5 网络：系统内外均使用百兆或千兆以太网络链接。 2 4 2 功能性需求 作为地面应用系统的一部分，数据处理将和地面应用系统中的其他分系统，特别 是运行管理分系统和数据管理分系统协作，完成数据的处理、显示以及归档工作。具 体描述如下： 1 接受运行管理分系统的业务运行计划，根据业务运行计划内容生成和调整数 据处理的流程； 2 接受运行管理分系统的数据到达命令，并根据命令从数据管理分系统读取原 始数据； 3 根据调整后的数据处理流程，以及操作控制员通过监视控制界面发送的手动 调度命令，调度数据处理程序进行数据处理； 4 将未经过任何处理的原始数据文件处理成各级产品数据并生成各种质量报告 文件； 5 将各级产品数据、质量报告文件送到数据管理分系统归档存储； 6 对产品数据进行可视化，通过网络以曲线、直方图、三维立体图等方式展示 数据内容； 7 对数据处理各个软件的运行状态和数据处理状态进行监视和控制； 8 对存储在数据管理分系统的历史数据再处理，提供处理方法试验平台； 2 4 3 系统划分 在可能的限制章节中介绍了数据处理分系统的划分正常情况下，各个子系统的 协作方式如下：运行管理仿真子系统6 制定业务运行计划，发送给调度管理子系统， 调度管理子系统根据业务运行计划制定数据处理的流程并把这个处理流程转发给监 视控制子系统，监视控制子系统以人性化方式展现这些新的处理流程；调度管理子系 统在接收到运行管理仿真子系统发送的数据到达通知后，把数据管理仿真子系统管理 的数据拷贝到合适的存储区域，并调度数据处理程序集对这些数据进行处理( 按照处 5 s a ns t o r a g e a r e a n e t w o r k 是一种网络化存储基础设施。 6 单独开发数据处理分系统时，为了模拟地面应用系统的真实场景，需要运行管理仿真和数据管理仿真两个子系统， 来辅助完成对其他子系统的测试，这两个子系统最终并不交付 1 4 山东大学硕士学位论文 理流程) ；在整个数据处理过程中，数据处理程序集会把处理的状态和进度报告给调 度管理，调度管理再把这些信息转发给监视控制，监视控制子系统显示并存储这些信 息，供操作员参考。在处理进行的过程中，操作员也可以根据需要启动、终止、跳过 某个处理过程。数据处理完毕后，数据处理程序集会把处理结果和处理产品交由数据 管理仿真子系统。数据再处理子系统主要用于方法的仿真和试验，它是用来测试一个 新的处理方法的性能和精度的试验台。 2 4 4 课题主要研究对象在航天工程中的位置 根据可能的限制章节的描述，把课题研究的对象进一步细化，即可知课题主要研 究对象在航天工程中的位置，如图2 2 。 一 航 天 工 程 莲十圣 图2 2 ：课题主要研究对象在航天工程中的位置 2 5 监视和控制子系统需求分析 2 5 1 功能性需求一 1 在数据处理过程中，可以设置整个数据处理为自动运行方式或者人工控制方 式，可以查询某一个处理流程占用的计算机资源情况，在人工控制模式下， 操作员能够启动、终止、挂起、解挂某一处理流程： 2 能够启动或者终止数据处理分系统中某些子系统，如数据交换子系统和调度 管理子系统等； 3 能够定时查询网络中所有主机的资源使用状况，主要是主机的c p u 和内存使 用百分比； 4 能够定时巡检数据处理分系统中某些子系统的生存状态，如数据交换子系统 和调度管理子系统的存活状态； 5 根据运行管理分系统的业务运行计划，展示载荷数据的数据驱动处理流程和 时间驱动处理流程； 】5 山东大学硕士学位论文 6 在数据处理过程中能够监视各种数据处理流程的状态， 理百分比、占用计算机资源情况等； 7 能够监视整个数据处理分系统中各个主机的运行状态， 运行使用的c p u 和内存的占有率； 如处理程序状态、处 主要包括主机中系统 8 能够监视数据处理分系统中各个子系统，如调度管理子系统、数据交换子系 统的心跳状态； 9 能够对整个处理过程中产生的处理信息、状态信息、数据交换信息进行显示、 存储，供操作员进行参考； l o 日志功能，能够对操作员的操作进行记录； 2 5 2 非功能性需求 课题的目的是做一个可复用的子系统，所以代码实现和设计的最终产品的用户很 可能是编码者与设计者之外的人。因此，课题的设计和实现强调必须满足某些非功能 需求。如运行环境约束，代码设计和实现的约束等。 1 编程语言使用j a v a 语言编写； 2 因为软件运行的平台可能是a i x 、u n i x 、w i n d o w 等操作系统，所以软件实 现需要具有可移植性； 3 无论是平台部分还是具体的插件部分，应以代码复用为基本要求； 4 软件实现需要有完整的设计文档和帮助文档，供使用者了解设计的思路和实 现的使用方法，文档包括r o s e 文档、h t m l 帮助文档； 5 代码实现需要具有清晰性、简洁性、可读性；最好能够达到不参考文档也能 使用的效果；对于每一个p u b l i c 函数，必须有相应的注释，以说明方法的参 数、返回值、功能含义等； 6 类中方法需要对参数的合法性做出判断，类成员的可访问性越小越好； 7 对于程序中可能出现的异常应该适当的处理； 8 命名规则使用命名惯例，如： a ) 程序中使用的接口都使用l 开头；类和接口的名字应该包括一个或者多 个单词，每个单词的首字母大写，缩写形式尽量避免； b ) 包的命名应该是层次状的，用点号分割每一部分，每一部分使用小写和数 字( 数字较少使用) ； 1 6 c ) 方法的名字第一个字母要小写，方法名一般使用动词短语的形式。对于返 回b o o l e a 值的方法，尽量使用i s 开头的方法名称。获取类成员变量的值 使用g e t + 成员变量名称的方法；设置类成员变量的值使用s e t + 成员变量方 法；方法名称应该可以达到望文生义的效果； 、 d ) 设置类成员变量值的方法，应该尽量使得方法参数名称和成员变量名称一 致； e ) 常量可以全部使用大写，栈变量可以用缩写形式； 2 5 3 需求分析的用例图 系统的参与者只有操作员，操作员除了在自动运行模式下启动、终止、挂起、解 挂、设置系统运行为自动模式、检查进程的资源占用情况，启动和终止某些子系统的 生存状态之外，其他用例均由系统自动触发：监视控制子系统的需求用例图如图2 4 ： u s e c a s e v i e w 。 o on ，一毒， s t a r t ap r o c e s s i ) s t a r t s u b s 螂e m ( 2 ) m o i t o r s t a t eo f ap r o c e s s 图2 3 ：监视控制子系统的用例图示 注：图中用例名称的括号中的数字对应监视控制子系统功能性需求列表； 除了r o s e 文档，我们对每一个用例都进行了详细的用例规格说明，其统一模板 如图2 4 1 2 1 ： 1 7 山东大学硕士学位论文 a c t o r s 涉及用例的参与者 p r e c o n d i t i o v a ： 用例开始时，系统必须满足的状态 f l o wo f e v e n t s ：事件流，用例中实际的操作步骤 n 2 1 p o s t c o n d i t i o n sz用例结束时系统的状态 图2 4 ：监视控制子系统用例规格说明模板 2 6 小结 本章在说明课题研究对象在整个航天工程中的位置的同时，主要描述了数据处理 分系统特别是监视和控制子系统的需求。需求是指导我们进行设计和实现的总方针； 我们在监视和控制子系统的平台设计与实现和监视和控制子系统各种插件的设计与 实现章节中将覆盖需求分析中的每一个用例。 1 8 山东大学硕士学位论文 第3 章复用方式的选择 课题研究的焦点是平台+ 插件这种复用思想在数据处理分系统中的应用。但什么 是平台? 什么是插件? 软件产生以来都出现了什么复用技术和思想? 为什么选用平 台+ 插件而不选用其他复用方法呢? 本章通过讨论现有的复用方法、介绍平台和插件 的概念来回答这些问题。 3 1 复用方法讨论 软件复用就是将已有的软件成分用于构造新的软件系统，可以被复用的软件成分 一般称作可复用构件。无论对可复用构件原封不动地使用还是作适当的修改后再使 用，只要是用来构造新软件，则都可称作复用。软件复用不仅仅是对程序的复用，它 还包括对软件生产过程中任何活动所产生的制品的复用，如项目计划、可行性报告、 需求分析模型、设计模型、详细说明、源程序、测试用例等等【3 】。 软件复用的一个关键因素是抽象。抽象是对软件可复用对象的提炼和概括，即将 可复用对象的基本属性和相应的操作，从具体的语言、环境和其他细节中提炼出来。 软件的复用性很大程度上取决于对可复用对象的认识深度或者说可复用对象的抽象 层次。抽象层次越高，与具体环境和特定细节越无关，则它被未来系统复用的可能性 也越大。 自软件出现以来，人们就一直在探索各种各样的复用方法。这些复用方法各有特 点，也各有利弊。 3 1 1 源代码复用 最早的复用方式是把某代码段复制粘贴到另一个代码段。这种做法的结果是无论 我们什么时候修改代码( 如在添加新特性或修复b u g 时) ，必须考虑修改这段代码出 现的所有位置。面向过程方法中使用的函数( f u n c t i o n ) 、面向对象方法中使用的类继 承( i n h e r i t a l 脱) 改善了这种状况。 继承的含义是予类可以自动的复用父类的代码( 因此，类继承仍属于源代码复用 的范畴) ，它又可进一步划分为实现继承和接口继承。接口继承只继承方法，而实现 继承除了继承方法之外还继承实现。在实现继承中，子类中的实现与父类有非常紧密 的依赖关系，例如如果实现中发现子类继承下来的实现不合适解决新的问题，则父类 必须重写。不过这种依赖关系在接口继承中则不那么紧密，因为接口没有提供实现。 山东大学硕士学位论文 3 1 2 目标代码复用 。 目标代码复用是把源代码编译成目标代码后打成包进行复用的方式。当前大部分 编程语言的运行支持系统都提供了连接( l i n k ) 、绑定( b i n d i n g ) 等功能来支持这种复 用。目标代码复用主要包含静态链接库( l i b ) 和动态链接库( d l l ) 。 3 1 2 1 静态链接库( l i b ) 静态链接库是在编译阶段被连接的，生成的可执行文件不受库的影响，因此可以 只发布可执行程序而不发布库。其缺点是浪费资源，因为编译器在处理程序代码时， 会从静态链接库中恢复函数和数据并把他们和应用程序中的其他模块组合在一起，进 而生成可执行文件( 如果多个可执行程序链接了同一个库，则会出现该库的多个副本) 。 另外，如果静态链接库进行了修改，则任何使用这个库的可执行程序都需要重新编译 和连接，这不利于软件的升级和更新； 3 1 2 2 动态链接库( d l l ) 动态链接库是一个包含可由多个程序同时使用的代码和数据的库，它是在程序执 行的时候被动态的装入到进程的内存空间的( 因此可执行程序需要和库一起发布) 。在 不需要的时候，系统也可以把动态链接库卸出内存，以便释放内存空间供其他程序使 用。使用动态链接库作为目标代码复用有很多优点： i 使用较少的资源：当多个程序使用同一个函数库时，d l l 可以减少在磁盘和 物理内存中加载的代码的重复量( 可执行程序中只保存了函数的名称和地址， 而不是把函数和数据本身与应用程序结合在一起) 。 2 简化部署和安装：当d l l 中的函数需要更新或修复时，部署和安装d l l 不 要求重新建立程序与该d l l 的链接。此外，如果多个程序使用同一个d l l ， 那么多个程序都将从该更新或修复中获益。当您使用定期更新或修复的第三 方d l l 时，此问题可能会更频繁地出现。 使用d l l 需要注意：当某个程序或d l l 使用其他d l l 中的d l l 函数时，就 会创建依赖项。因此，该程序就不再是独立的，并且如果该依赖项被损坏，该程序就 可能遇到问题。例如，如果发生下列操作之一，则该程序可能无法运行：依赖d l l 升 级到新版本、修复了依赖d l l 、依赖d l l 被其早期版本覆盖、从计算机中删除了 依赖d l l 。这些操作通常称为d l l 冲突。如果没有强制实现向后兼容性，则该程 序可能无法成功运行嘲。 山东大学硕士学位论文 无论是l i b 还是d l l ，目标代码复用都有助于推广模块式体系结构：实现程序 模块化，相对独立的模块可以组成一个完整的程序。同时目标代码复用也可以帮助我 们开发要求提供不同语言版本的大型应用程序。另外，目标代码还可以对我们苦心经 营的源码起到保护的作用。 3 1 3 组件复用 c o m 和c o r b a 都是一种规范，都定义了客户程序与组件、组件与组件之间交 互的规范，因此我们把c o m 和c o r b a 都归为组件复用层次。当然，c o m 和c o r b a 出现的目的以及其主要的应用领域并不是软件复用，但他们在软件复用方面也显示了 自己的特点。 “。 3 1 3 1 组件对象模型( o 叫) ， j c o m 即组件对象模型，是一种以发布组件为发布单元的对象模型，这种模型使 各软件组件可以用一种统一的方式进行交互。c o m 即提供了组件之间进行交互的规 范，也提供了实现交互的环境( c o m 本身要实现一个称为c o m 库的a p i ，它提供诸o 毛。 如客户对组件的查询，以及组件的注册反注册等一系列服务，一般来说，c o m 库由 操作系统加以实现，我们不必关心其实现的细节) 嘲。 。一 c o m 在w i n d o w s 上实现的方式是d l l ( 进程内组件) 或e x e ( 进程外组件) ， 较之于普通的d l l ，c o m 做了更多的工作【4 l ： ， 1 为每一个组件定义的接口设定了唯一的标识：g u i d ( g l o b a lu n i q u ei d ) 。每一。 g u i d 是一个1 2 8 位的随机数，所以并不保证绝对的唯一性，但发生标识符 相重的可能性非常的小，因为g u i d 的产生考虑了空间( 网卡m a c 地址) 和时间特性。 2 定义了长久不变的接口。开发一个c o m 组件，首先要用i d l 语言定义一个 接口，该接口在今后的使用过程中不再轻易改变。接口不变性要求我们在定 义组件的接口时，必须充分考虑组件所提供功能的一般特性，以使接口描述 更为通用。但这种不变性又是相对的：在任何需要扩展组件功能的时候，客 户都可以创建一个新的接口，新的接口必然有新的名称和标识，而c o m 组 件支持实现多个接口的特性保证了c o m 组件对原有接口的支持。 q u e r a y i n t e r f a e e 函数的存在把c o m 组件支持的多个接口有效的联系在一起。 3 c o m 规范在客户和组件之间提供了一个间隔层，从而支持了组件的封装。 2 1 山东大学硕士学位论文 客户通过使用类厂、c o m 库、组件在注册表中的信息注册，获取对c o m 组 件的引用，进而使用c o m 组件； 组件c o m 复用性的优势； 1 因为组件之间交互的规范不依赖于任何特定的语言，所以c o m 也可以是不 同语言协作开发的一种标准。c o m 的个重要作用是用接口定义( i d l ) 语 言来描述组件。这样，客户端的开发就可以针对着i d l 来做。 2 与c + + 中类继承的方式不同，c o m 使用两种机制实现复用：包容和聚合。 在包容方式下，组件a 对象包含了组件b 对象，当组件a 需要用到组件b 的功能时，它可以简单的把实现交给组件b 来完成。在包容方式下，组件a 和b 具有相同的生命周期；在聚合方式下，组件a 只是简单的把组件b 的 接口递交给用户，组件a 并没有实现组件b 的接n ( q u e r y i n w r f a c e 是实现聚 合的关键) 。在聚合方式下，组件a 和b 的声明周期是彼此独立的。无论那 种复用方式，组件a 都可以完全复用组件b 的功能，就好像a 自己实现了b 的功能一样，而且当组件b 更新了版本或者增强了功能时，组件a 自动使用 新版本的组件b ，而不用重新编译或者重新设置1 6 】；。 c o m 的作用不单体现在可复用上，c o m 对参数传递过程中的数据传递做了封 装，使得数据传输可用性大大增强，体现出中间件( 跨语言、跨操作系统平台) 的特 点。因此，随着网络技术的飞速发展，c o m 在分布式应用领域正在扮演着越来越重 要的角色；另外，c o m 规范与微软的操作系统紧密的整合在一起，如果软件运行的 操作系统是w i n d o w s ，那么c o m 是一种不错的选择。但如果是u n i x 操作系统或者 考虑跨平台，则应该选择c o r b a ； 3 1 3 2 公共对象请求代理体系结构( c 0 r b a ) c o r b a ( c o m m o no b j e c tr e q u e s tb r e a k e r a r c h i t e c t u r e ，公共对象请求代理体系结 构) 是o m g ( o b j e c tm a n a g eg r o u p ) 提出的组件之间进行交互的又一个规范它使 用i d l ( 接口定义语言) 进行建模，以及采用i i o p ( i n t e m e t i n e r - o r b p r o t o c a l ) 即因 特网0 r b 互通协议进行客户和服务器之间的通信。 c o r b a 的出现是为了分布式环境提供技术支持手段，在分布式方面的应用才是 c o r b a 真正的舞台，但c o r b a 在可复用性上也体现了自己的特点： 1 跨平台和跨语言：c o r b a 使用的i d l 语言是一种描述语言，根据映射规则， 山东大学硕士学位论文 i d l 定义的接口可以方便映射到c + + 或者j a v a 。编组和解组的引入，可以保 证跨平台、跨语言。 2 跨网络：c o r b a 使对象数据的通信得以复用，因为底层网络通信的细节由 o r b 负责处理，它屏蔽了不同的底层网络协议，从而将客户与服务器从复杂 的网络编程中解脱出来； 3 1 4 框架复用 框架是一系列相互协作的类，这些类提供了特定应用程序设计需要的骨架 ( s k e l e t o n ) ，框架包含了应用程序基本协作的高层类，应用程序开发者只需要子类话这 些类，便可迅速构建可以工作的应用程序。框架定义了应用程序的结构，包括每一个 类的职责和协作，因此使用同一框架的应用程序都具有相同的“精神”( 相同的基本 行为) 。框架设计的目标是：一个基本的设计对于类似的应用程序是足够的，它应该 即可以简化同类系统的开发，又不限制应用程序的具体设计1 4 1 。 下面通过框架和其他概念的比较进一步阐述框架。 。 3 1 4 1 框架和设计模式 设计模式描述了软件设计过程中一些经常发生的问题，以及这些问题最佳的解决 方案 5 1 而框架则提供了可以工作的代码。在范围上框架要比设计模式的范围更大， 它通常包含了多个设计模式。另外，框架是针对的一系列类似的应用程序，它一般包 括一些可以复用的具体类以及大量接口( 或者抽象类) ，通过实现这些接口( 或者子+ 2 类话) 来实现用户自己的应用软件。 。7 3 1 4 2 框架和类库 框架肯定是一个大型的类库，但是类库中包含的是实现具体的功能的类，用户通 过使用这些类和调用他们的函数来复用，其复用的单元是类，用户需要自己利用这些 类来实现自己的逻辑。框架把同类应用程序的核心作为复用单元，并定义了所有使用 这个框架的应用程序的控制流。也就是说框架复用实际上复用的是控制流。 v l f c 是一个典型的框架，它是基于文档，视图接口的框架；这种框架把数据放在 文档中，各种各样的视图都可以访问这些数据。 。 框架复用需要设计人员专注于对领域需求的了解，积累同类系统开发的丰富经 验。 一 。 。 山东大学硕士学位论文 3 1 5 设计复用和分析复用嘲 设计复用受实现环境的影响较少，从而使可复用构件被复用的机会更多，并且所 需的修改更少。这种复用有三种途径，第一种途径是从现有系统的设计结果中提取一 些可复用的设计构件，并把这些构件应用于新系统的设计；第二种途径是把一个现有 系统的全部设计文档在新的软硬件平台上重新实现，也就是把一个设计运用于多个具 体的实现；第三种途径是独立于任何具体的应用，有计划地开发一些可复用的设计构 件。设计复用的一个典型代表是即框架复用。 分析复用是比设计复用更