软件组件技术在欧特克产品中的应用

曾邱雪

0 引言

“面向对象”最初的定义，是指：在具备封装、类型扩展性、继承、多态等特点的程序设计方法，随着软件产业的进一步发展，面向对象技术现在具备更加广泛的意义并且渗入到软件开发的各个方面。随着软件越来越庞大，要求越来越高，如何快速高质量地开发出优秀的软件，传统的软件开发方法已显乏力，开发和采用可复用的软件功能模块—软件组件技术便成为解决此问题的最佳方法之一。软件组件技术是一些可执行单元，可以通过独立的开发和配置，然后整合到各个独立的软件系统中去，是软件系统内被标识、符合某种标准要求的组成部分。在过去数年中，基于软件组件技术的开发方法备受关注，并且成功运用于多种大型软件中，取得了不错的效果。

1 组件技术的应用

通过采用恰当的组件技术，软件厂商得以通过降低投入，缩短开发周期和增加软件质量来达到提高收益的目的。近年来，基于组件的软件技术的成熟程度和推广速度日益增长，新的应用软件工程硕士开发技术和工具，是以组件作为关键，复用大粒度的对象，为的是快速的开发出应用软件。组件技术尤其适合由若干大型软件组成的软件套件，非常著名的例子，有微软公司的OFFICE办公套件以及Adobe公司的创新套件。通过采用软件组件技术，实现各个软件直接无缝地协同工作，极大挖掘了软件的功能，极大地方便和改善了用户对软件套件的学习和使用，提高用户对产品的忠诚度，提高了用户体验。

社会经济不断发展，为2D/3D计算机辅助设计软件行业，提供了巨大的发展机会，然而，随着业务的发展，新的业务品种不断增加，必须在原有业务系统上不断扩展改造，而且各个独立软件之间的协作需求不断出现。因此，必须寻求新的协同合作方案来解决这个问题。希望通过新方案的应用，达到在各个实现各个独立软件直接的无障碍交互，达到整合不同产品优势功能的目的，最终有效地帮助用户提高整个行业业务效率。

1.1 计算机辅助设计软件产业的需求

欧特克(Autodesk)公司是全球二维和三维设计、工程及娱乐软件的领导者，其代表产品有：AutoCAD, Revit,Inventor, 3dsMax, Maya等多款计算机辅助设计软件，横跨Windows, Mac, Andriod 和iOS等多个平台, 广泛运用于工业和娱乐行业。目前计算机辅助设计产业中，常见的有机械设计、多媒体设计、计算辅助分析、以及其它方面。终端用户往往需要同时使用几款软件以组合的方式来实现最终目标，这就产生了需要在几款软件之间进行交互的需求。如用户需要使用AutoCAD进行设计绘图，然后需要使用3dsMax进行渲染，又同时需要使用Revit进行建筑结构分析。由此可见，整个工作流程需要用户对各款软件都能熟悉使用，并且可能出现一个项目需要在多个软件里重复建模的工作，由此产生不小的冗余工作。初始阶段，这几款软件的文件格式是互不兼容的，软件的用户体验也完全不一样，导致用户上手学习难度极大，设计效率不高。

欧特克公司的产品设计师通过和用户的充分接触，深入探讨用户工作中的各个案例，分析和提炼用户反馈后总结出如下需求：

1) 各个软件的文件格式能互相兼容，实现在一个软件中建模，多个软件中使用的目的。

2) 各个软件的用户界面应具有同样风格，方便用户上手。

3) 各个软件中的相似功能应该具有类似或者一致的操作方式。

4) 各个软件之间能够互相协同工作，以提高用户工作效率。

5) 用户希望能够增加方便分享设计文档或资源的功能。

6) 用户希望在移动设备上运行轻量级别的设计软件。

1.2 软件开发的技术需求

上世纪80年代起，面向对象的软件开发思想迅速发展起来，这时的软件组件的含义就是类库。90年代后，组件的内涵进一步加强，聚合性、独立性和重用性进一步提高。目前，基于对象的组件软件体系结构中的组件是指可方便地插入到语言、工具、操作系统、网络系统中的二进制代码和数据。综合上述组件技术的优势，显然，组件技术即是实现此项需求的最佳选择。换一句话说，我们能够从上述用户需求中，提炼出其核心，就是希望各个软件能够互相“兼容”各个软件的文件格式、交互界面、设计流程以及通信交互方式等。

1.3 软件组件的提取

结合欧特克各个主要软件的特征，产品设计师和软件架构师协同合作，从高层次的用户工作流程开始，逐个分析用户案例并且提取出其涉及到的软件组件。从抽象的软件层，可以把组件类型划分成如下几个类别：

1.3.1 交互界面组件

此组件的主要功能，是根据工程设计软件的特性，实现一套高效、用户友好的通用交互界面库，包括：程序主体框架、程序菜单、个性化的工具条、状态栏。通过采用该组件，可以使不同产品具有相似的交互界面，极大提高用户的软件使用效率，方便用户学习，并且能提高用户忠诚度。在软件工程方面，通过采用组件技术，可以减少各个软件在界面上的冗余代码，让各个产品团队能专注于各自的核心功能。

1.3.2 网络服务组件

随着互联网运用的兴起，各种基于网络的运用遍地开花，如云计算服务、资讯订阅、网络搜索、用户交流等功能，也将会出现在欧特克的各个产品中。本组件将实现基础网络组件的功能，以达到用户注册一个帐号，就能在欧特克各个产品上使用的目的，并且各个产品只需要简单集成本组件即能具有网络服务功能。

1.3.3 文件格式组件

本组件实现统一的文件格式，用于实现用户在各个软件之间传递设计模型的目的。其最终目的是让各个产品能公用一种文件格式，最终达到无障碍交互。

1.3.4 材质库组件

此组件实现了对2D/3D软件中常用的材质库的浏览、编辑和保存，以实现不同产品中共同功能模块的共享，在降低软件开发难度的同时达到提高用户认同度的目的，并且让用户只需要学会一款产品中的功能，就能掌握几款软件中同样功能的目的。本组件还能保证几种软件使用同样的材质，扫除在交互期的障碍。

1.3.5 渲染引擎组件

渲染引擎是图形类软件的核心技术。本组件的目的是打造特殊与欧特克的跨平台图形引擎，在掌握核心技术的同时能够提高软件的质量。

1.3.6 许可证组件

每一个收费产品都必须拥有许可证部件来授权合法用户，以保证生产厂商的版权。本组件的目的就是为欧特克所有产品提供通用的许可证组件，方便各个软件产品的集成的同时能够简化用户的激活步骤，并且为多个产品同时授权提供技术基础。

1.3.7 其它

欧特克许多产品，还具有其它一些可以组件化的模块，比如用户反馈模块，提供了收集用户使用软件的信息功能，并且能够从海量数据中生成报表，方便产品设计师查询、分析用户使用习惯，最终优化产品设计提高产品质量。

1.4 软件组件的实现

1.4.1 需求分析

软件组件项目有着一个显著的特点，那就是它的用户首先是使用本组件的软件产品，然后还可能有终端用户。简单地说，就是一个软件组件首先是被另外一个软件产品使用，集成到某一个产品中，然后伴随这个产品发布到最终的用户手中。毫无疑问，每个软件产品都有着各自的开发背景，自然就会形成特殊的风格和特点，而这又会促使它们对组件的要求有着一定的差异性。举一个简单的例子，每一款软件产品都有着各自独特的网络服务，如 A产品可能提供网络存储服务，而 B产品提供用户互动支持，显然它们对网络组件就有着不同的侧重点。由此，总结出软件组件项目需求分析中需要注意的有：

根据项目周期，提前向用户（包括软件产品团队，终端用户）发出用户需求收集请求。这是因为组件项目的开发时间往往是比软件产品的开发时间提前一段3到6个月。

收到软件产品团队需求之后，需要迅速归纳分析各方需求，并且组织相关人员分析、评价。往往还需要在各个产品团队之间进行协调和取舍。这是一个迭代的过程，一般需要进行多次。

需求分析中应恰当考虑有可能出现的需求变动。

需求分析完成之后，发出报告给各个软件产品团队进行确认和签收。

1.4.2 设计与实现

软件组件项目的设计与实现除了需要遵循一般的软件设计准则之外，还有的其特殊之处。主要体现在：

软件组件项目需要提供大量的API，因此软件框架首先就考虑如何组织这些API。

软件组件项目需要提供良好的兼容性，框架需要支持多种需求，并且要考虑向前和向后的兼容性。

软件组件项目需要方便用户集成，并且提供良好的集成文档。

软件组件项目需要提供良好的扩展性。

软件组件项目需要提供良好的性能。

软件组件项目可能需要跨平台。

软件组件项目需要考虑如何测试。

软件组件项目需要考虑组件与组件之间的相互依赖。

为了在软件组件中达成上述目标，我们在软件组件项目中经常采用下列设计模式：

1) 单件模式

单件模式常常用来创建组件的管理者（有些书籍中也会称管理者为一种模式），通过管理者来管理组件和设置全局属性。这是因为组件中常常需要提供接口，给用户来设置一些针对组件的全局选项，如组件的内存处理方式，组件的延时加载选项等。

2) 桥梁模式

此模式常常用于组件的C++ API中，主要的思想就是在 API类中不添加真正的实现代码，而是通过一个桥梁来转换到另外一个实现类中，达到保证API类内存状态稳定，达到保证组件库的兼容性的目的。虽然此模式会增加一定的代码量，但是相对于其带来的好处，还是非常值得使用的。

3) 策略模式

通过采用策略模式，可以为同一个接口提供不同的实现，达到为不同的需求提供不同服务的目的。这是因为，不同的用户对同一个功能可能需要采用不同的算法或者实现，但是，其上层接口往往是一样的，因此经常使用策略模式来封装一种算法（或实现），并使得它们可以互换。其典型实现，如图1所示：

图1 策略模式

4) 装饰模式

通过采用装饰模式，可以方便地为不同用户提供不同的服务。不同用户所使用的功能往往不相同，如 A用户可以使用上述1，2，3功能，而B用户却只需要1这一个功能，因此我们常常使用装饰模式来方便用户选择他需要的功能。其典型实现，如图2所示：

图2 装饰模式

5) 命令模式

通过命令模式，可以方便向软件用户反馈组件中出现的命令，方便用户对此做出正确反映。其典型实现，如图3所示：

图3 命令模式

6) 观察者模式

通过观察者模式，可以方便实现软件组件和一个或者多个用户的通信合作，一般用于组件向软件端回调一些函数。其典型实现，如图4所示：

图4 观察者模式

1.4.3 组件的测试

编码工作完成后需要进行软件组件的测试工作，它主要包括两个方面：

1) 传统的测试项目

类似于传统的软件测试，根据项目设计文档进行测试，但是其一显著特点是进行大量的 API测试和在有限的环境中尽量模拟真实的运行环境进行测试。

2) 集成测试和兼容性测试。

这是属于软件组件项目特殊的测试项目，那就是需要测试软件组件能否满足用户提出来的集成需求测试，这往往需要团队和软件产品团队协同合作完成。另一方面就是需要测试组件项目的兼容性，主要指的是向上兼容性，因此这个测试需求仅仅出现于版本更新的项目上。

1.4.4 发布与技术支持

软件组件项目在发布之后并没有真正的结束，通常需要为接下来的集成工作提供技术支持甚至修改软件组件。根据上面提到的，组件项目往往比使用它的软件产品项目提前3到6个月，实际上软件组件的集成工作一般都开始与软件组件即将完成的时候，一直延续到完成之后的一段时间。这个时候组件项目需要为集成工作，提供大量的支持工作，解决项目中出现的问题。

1.5 经验和心得

组件项目有的特殊的用户和定位，因此其具有不同于一般软件项目的特点。根据作者多年软件组件开发经验，得出以下经验和心得：

1) 开始阶段的需求沟通非常重要，由于组件项目先于产品团队开发，因此需要催促产品团队提供需求，并且需要在充分沟通的前提下平衡各方的需求。而且需求肯定会有一定的变化，需要早做准备。

2) API架构时期，需要组件团队的开发人员和用户团队的开发人员积极沟通，争取以最简单的方式实现健壮的API框架。API用法越简单越好。

3) 从项目开始就注意项目文档，并且把它作为一个任务来追踪。

4) 在API框架以及主要功能完成的前提下，尽早提交产品团队进行集成，测试。

5) 很多重要的问题往往在产品集成之后才能暴露出来，如兼容性，产品性能问题，需要提前为此做好准备。

6) 理智面对用户在项目后期提出的新的需求或者变更，需要妥善讨论并且和各个用户沟通之后再确认是否接受此更新。

2 组件技术实施效果分析

欧特克产品在采用组件技术后，显著地避免了各个产品各自实现一些常用模块的现状，减低了代码的冗余度，提高了开发速度。更加重要的是，用户对这些改变提供了积极的反馈，欧特克公司将继续深化此解决方案并且在此基础之上推出软件套件策略。

3 结束语

由于移动操作系统的兴起，开发软件的差异导致组件也是多种多样，对软件组件技术带来新的机会和挑战，毫无疑问组件技术本身也会在需求的推动下不断前进。

[1]郑人杰，殷人昆，陶永雷. 实用软件工程[M].北京：清华大学出版社，2004

[2]Ira Pohl 著.陈朔鹰，马锐，薛静锋，吕坤 译. C++教程[M].北京：人民邮电出版社，2007

[3]（美）弗里曼（Freeman，E.）等著. Oreily Taiwan公司译.Head First 设计模式（中文版）[M].北京：中国电力出版社，2007

[4]陈文实，孟宪宇，李赛男. 中间件技术的应用及前景[J].辽宁：辽宁工学院学报(自然科学版)，2004年3期