系统架构师论文-论基于构件的软件开发(测井资料处理与解释集成软件)

论基于构件的软件开发

–测井资料处理与解释集成软件

[摘要]

去年初，单位承担了新立的“测井资料处理与解释集成软件"项目，目的是集成目前国内零敬的测井解释方法，我有幸参加该项目，并负责软件系统平台设计和部分开发工作，在项目的实施过程中，我充分进行基于构件的软件开发，复用成熟的商业构件和本单位的构件资源库，同时考虑了本项目开发资源的进一歩复用，形成了绘制组件包，数据交换组件和数值计算组件包等。基于构件开发，大大提高了软件的质量，缩短软件的开发周期。开发的软件目前在石油测井几个油田现场使用，并得到用户的好评。本文就在本项目中如何进行基于构件开发进行描述，并在复用构件的使用和丰富方面谈一些自己看法。

[正文]

2004年3月，我有幸参加了单位软件开发项目一一 “测井资料处理与解释集成软件"，并负责系统平台设计和部分开发工作，本项目是由中国石油天然气集团公司科技部的测井软件类项目，在项目立项之前，国内测井行业为了提高石油解释的分析和决策能力，在解释方法方面广泛与各大高校进行合作，经过长时间的积累，形成的非常多而且实用的方法和处理模型，并开发了简单的使用系统，但这些应用非常零散，不统一，无法协调工作，处理效率
低，多个解释系统之间没有必然联系，而且数据格式多种多样，不利于测井的精细解释和综合应用。本项目的目的是为了提升综合决策能力，提高石油解释的准确率，考察了解国内流行的测井资料处理解释方法，将成形和半成形的解释方法进行筛选和整理，集成到统一的系统平台上，増强一体化处理功能和商业化能力，并有偿反馈给石油测井现场用户使用。
在本项目立项前，单位承担了较多的软件开发项目，软件开发方法一直在改进更新。单位早期的软件以数值计算为主，主要采用面向过程开发方法，但随着软件的复杂度増加，可视化要求和开发效率，在面向过程方法不能满足要求的情况下，开发方法转为面向対象方法，实现界面编程，可视化操作交互，开发效率得到大幅度提升，但是这种方法也存在一些不足，无法有效实现资源复用，多个项目之间的资源复用仅限于部分开发过程和偶尔可以复用的模块类，新项目很少能借鉴老项目，即使存在明显类似的项目也无法有效复用，出现了多个项目组软件界面不统一，操作习愦不一致等情况，因为新项目只注重眼前效率和操作适应性，根本没有夸虑以后的复用，导致重复开发，浪费人力物力。因此，在面向対象开发方法的基础上进行改进，采用基于构件的开发方法，在每一次项目中，尽可能地考虑以后可重用的部分，以构件形式进行设计开发，虽然在部分的开发工作可能増加，但是多项目综合考虑,大大提升软件的开发效率。而且，本单位大部分项目为测井类软件项目，在软件的设计思路和最终成品上看，很多部分非常相似甚至雷同，几个连续项目存在联系，基于构件开发的软件方法在本单位更能体现作用-
在“测井资料处理与解释集成软件"项目的设计和实施过程中，我使用了基于构件开发的方法，充分利用公认的构件技术-C0M/DC0M和AD0等，使用已有的商业构件-Xtreme和Esstentails等，复用单位的构件资源数据转换组件，并开发了新的构件，如绘制组件包，数据交换组件和数值计算组件包等。
本软件系统以测井解释分析为主，主要包括图件绘制、用户交互操作、数值处理和数据存储等几个部分，我将软件设计为C/S四层体系架构。客户端应用程序采用Microsoft Visual C-开发，本单位已经购买了 Xtreme的使用权，Xtreme是基于VC的MFC框架的界面构件，它是微软的合作伙伴，能经过简单的几歩向导就能产生美观的软件界面，它生成的界面具有一致性，対于测井解释集成应用，统一的界面可以降低软件的学习难度，増强软件的易用性，使用Xtreme,我非常方便地实现了界面设计和开发工作。
图件绘制基于GDI和GDI+开发，每个绘制対象采用单独的一个类进行封装，绘制的载体対象派生于MFC的窗口类，其他対象派生于同一个基类，基类设计足够的消息响应函数，対象采用重载虚函数或者操作自动定向，实现鼠标响应，属性修改和递归型子対象管理。绘制载体类和基类封装在一起，形成绘制核心库，其他対象单独以MFC扩展动态库实现，一个或者几个対象设计成一个扩展対象库，如果要増加和删除某个対象，只需修改相应的扩展动态库。这样，只需要绘制核心库与必要的绘制対象扩展库，就可以提供相应的绘制功能，而且绘制的対象可以定制并进行二次开发。在某些绘制图件的设计中，考虑到箕法的难度,直接利用较为成熟的绘制构件-Gigasoft Pro Essentials,如等值线图，区块三维分布图和多井连通图等图件的绘制算法，核心绘制部分直接接由Essentials完成用户交互响应由対象封装。
测井解释的核心部分是解释方法，每种测井项目有多种解释方法，而每种解释方法又有多个解释模块，因此解释方法的设计是相対复杂的。在考虑到测井解释的流程化处理和模块动态増减的要求，采用COM组件技术进行了模块设计。例如常规测井解释项目，包含POR、CLASS、SAND和CRA等多种解释方法，而这些解释方法都包含几个解释过程，如POR包含泥质含量计算，渗透率计算、孔隙度计算和含水饱和度计算，将上面的每个过程设计为功能完整封装的COM组件，当用POR解释方法进行资料处理时，依次调用处理过程完成解释。由于采用组件方法设计，方法模块可以动态添加，如果在POR的基础上需要添加含油饱和度计算模块，只需要设计相应模块，动态添加到POR的管理队列中。在解释方法分解设计的同时，将多种相同的数值计算方法进行提取抽象，形成满足自己需求的数值计算组件包，方便多种解释方法的复用，并为新的解释方法研究提供强大的计算能力。
在软件设计开发中，数据的存储最为繁琐，由于测井解释面対多种数据格式，如国内Forward软件使用wis （WellLogging Information Sysetm测井信息系统）数据文件，国外GeoFrame 使用的 Lis（Log Information Standard）、eXpress 使用的 XTF（ eXchange Tape Format可交换带格式）格式和DPP使用的CMS格式等，这些测井软件使用相当广泛，如果本项目软件能进入市场，这些格式都需要兼容，但是将这些格式都作为应用対象很难实现或者不可能
实现。在数据储存方面，我直接采用Sql Server数据库存储，存储结构设计采用国际标准结构，国际石油标准化组织POSC制定了一套EPICENTCY石油数据存储标准，这种结构被石油系统厂泛采用，可以存储石油系统多行业数据，如测井、录井、钻井和开发类数据等，直接采用已有标准可以满足复杂的存储要求，避免重新设计格式的存储能力限制。数据访问采用ADC数据访问组件，实现数据通讯和交换。在数据库的数据录入方面，我充分利用了本单位其他项目开发的数据格式转换组件，用于支持多种测井数据的解码和编码，由于以往项目的数据操作是基于文件系统（CIF格式），内部封缓了固定CIF文件格式转换功能，我将组件进行了适当修改，将基于CIF文件格式的操作改为内存操作方法，实现向数据库录入。在数据库和解释模块之间，我设计了数据交换组件，因为测井解释的特殊性，一次解释需要获得数据非常多，一次解释处理至少需要二三条曲线，测井采样间隔一般为0.01米左右,2000米井段每条曲线传输数据量就有100多K,如果需要处理成像数据，数据量更大，可能有几十兆，甚至上百兆，由解释模块或测井图件直接采用ADO进行数据库访问，每次解释会多次访问数据库，势必会降低软件的执行效率和处理的稳定与连续性。数据交换组件将一次解释数据全部读出，打成固定格式的数据包GDS （Global Data Storage）, GDS可以以文件形式存放和内存形式交换，应用模块只处理GDS数据包，完成各种应用后，按照同样的格式传回数据库，优化处理性能，而且基于GDS构件的应用还可以扩展开来，GDS不一定只与我们设计的数据库进行交换，如果需要増加其他存储方式数据库，只要知道详细的存储结果，开发访问组件，GDS就能与其相联进行信息处理，新的数据格式也是一样，只要提供了访问组接口，也能够进行测井解释。
开发过程中，我充分利用已有的构件，也充分地考虑了本项目开发资源的进一歩复用，开发了绘制组件包、数据交换组件和数值计算组件包等构件，完善单位的可供复用的构件库，积累和固化知识财富。到目前为止，绘制组件包和数据交换组件已经在新项目测井数据采集平台使用，效果非常好。
基于构件的软件开发，可以缩短软件产品的开发周期，提高软件质量，但是如果构件选择不当或使用方法不当，也会带来一些麻烦，在构件的使用上，我也走了一些弯路，如在使用Xtreme上，由于购买了它的源代码，曾将某些绘制模块建立在其源代码级别的紧密耦合，当Xtreme提供的新的版本后，这些紧密耦合的模块无法适应新版本，如果想继续应用，必须再进行同样的开发工作，最后我放弃了某些紧密耦合的功能，将绘制交互与Xtreme完全隔离开，后续的版本升级再没有带来任何问题，类似的教训还有很多，总结分析后，我认为在基于构件的开发中主要注意一些问题：如项目开发不要与已有构件紧密耦舍，防止构件升级带来的影响；构件的使用一定要进行严格的测试与审核；不要勉强应用某些构件，如使用巨大构件的其中某个微小部分，虽然功能很适合应用，但可能影响软件效率；新项目必须注意构件库的积累，只有这样才能充分体现基于构件开发的便利；新构件功能一定要完整，文档及接口定义明晰，否则难以复用。
在本项目的开发工作完成后，相比以往的开发项目，开发周期明显缩短，软件的质量明显提高，用户软件雄护要求也减少了，而且其扩展性非常强大，目前该解释软件已经在华北油田、长庆油田和土哈地质研究院进行了现场应用，得到了用户的一致认可。通过这次案例，我认为在软件系统的复杂性不断増长的情况下，基于构件的开发能有效提高软件质量、积累和固化知识财富，并有效地缩短软件产品的开发周期，提高了软件生产效率。