深入了解OpenOffice.org(二)

1. 分层架构

OpenOffice.org所基于的技术架构能够提供在UNIX和类UNIX系统上丰富的办公软件功能，并且这种架构能够被移植到其他很多的平台上。这是因为整个架构就是在平台无关性的思路下实现的。

整个OpenOffice.org中实际上只有不到10%的代码是与平台相关的，这些代码为上层的组件模块提供一个系统抽象层。由于C++编译器存在于每一个主要平台上，所以OpenOffice.org采用了C++作为主要的编程语言（最底层的部分代码由于效率等原因是C语言编写的）。这种实现方式允许OpenOffice.org移植到非常广泛的不同的平台上，采用面向对象语言也使得OpenOffice.org具有面向对象的技术架构。

图1是OpenOffice.org的分层架构图，总体上分为四层，每层由若干不同的子层/库组成，在图中用小方框表示。每层和每个子层/库都完成不同的功能。需要注意的是每个子层/库很可能不是对应于具体的某个源代码模块，而是相关的若干个模块。因为OpenOffice.org的源码模块众多，刚发布的时候还不到100个代码模块，而最近发布的OpenOffice.org 1.1.2已经到了150左右。模块之间的相互依赖关系可能是很复杂的，而且随着版本发布的更新不断有变化。所以从总体上把握OpenOffice.org分层模型的功能结构和依赖关系对于掌握整个OpenOffice.org的技术架构是很有帮助，也是至关重要的。

表1是OpenOffice.org 1.1.2源代码模块的功能描述表。在约150个模块当中，有将近30个模块是从其它开放源码社区获得的源代码。这些模块依照字母顺序排列，它们的功能描述尽管比较粗略，也会对理解整个OpenOffice.org的体系结构很有帮助。需要注意的是不同版本的OpenOffice.org包含的模块数目可能有不同，或有增删，而且有些模块也正在变更当中。

大致上讲，

• 系统抽象层（System Abstraction Layer）封装了所有系统相关的API并提供了共同的面向对象的API以平台无关的方式访问系统资源；

• 基础设施层（Infrastructure Layer）构建应用程序同平台无关的环境，为了向上提供组件和服务，这一层完整地包含了面向对象平台所需面向对象API的很多方面，包括组件模型、脚本解释、复合对象等等；

• 构架层（Framework Layer）为在不同应用间能够实现复用，提供每个应用和所有共享功能（例如公共对话框、文件访问或者配置管理等）所需的架构和环境；

• 应用层（Application Layer）提供所有的OpenOffice.org应用，这些应用的交互方式是基于若干底层的。

图2是OpenOffice.org 1.1.2源代码模块依赖关系树状图。这张图所描述的是OpenOffice.org中各个模块的编译依赖关系，实际的模块编译顺序也是根据这个依赖关系产生的。从图中我们大致可以看出OpenOffice.org的分层结构。最底部比较密集的区域是系统抽象层，在此之上非常密集的区域内的模块组成基础设施层，上部比较稀疏的区域是构架层，最顶部的若干模块组成应用层。

下面逐层描述它们的功能。

1. 系统抽象层

分层的系统架构是OpenOffice.org能够轻松移植到广泛而不同的系统平台上的重要因素之一。为此目的，OpenOffice.org架构中特别定义了一个称作“系统抽象层”的虚拟层。所有平台相关的实现都在这一层下发生，或者作为可选模块存在。所以理想状况下只要实现了系统抽象层提供的功能再把上面诸层所属的模块重新编译，OpenOffice.org就能够在新的平台上运行了。但如果想要实现所有功能，可选的平台相关模块也要进行移植。为了减少移植工作量，系统抽象层所提供的功能被缩减到每个平台上可用的最小集合。当然在某些平台上系统抽象层必须模拟某些不存在的功能，比如在没有本地多线程的环境下支持“用户境”线程。¹

系统抽象层包括如下四个子层/库：

• 操作系统层（Operating System Layer，OSL）封装了用来访问和使用系统资源（例如文件、内存、套接字、管道等）的操作系统功能。OSL是具有面向对象API的很薄的一层，和上层不同的是这里的面向对象API是C语言实现的API。C语言API的优势在于允许将该层用不同的实现语言移植到不同的平台上去，比如对于嵌入式系统或者互联网应用设备来说，汇编语言就可以用来实现这一层。

• 运行时库（Runtime Library，RTL）提供所有的准平台无关的功能。这里提供字符串类的实现，也能够把字符串转换到不同的字符集，内存管理的功能也是在这里实现的。

• 标准模板库（Standard Template Library，STL）²在这里作为泛型容器类来使用。STL提供了列表、队列、栈、映射等模板/类的实现。

• 可视类库（Visual Class Library，VCL）³是OpenOffice.org的核心库之一。VCL的实现分为两个部分，一部分封装了对不同的底层GUI系统的所有访问方式，另一部分是完全平台无关的，包括面向对象的2-D图形API和OpenOffice.org使用的整个窗口部件集。这种纵向划分的方法保证了所有的窗口部件具有独立于不同平台上所用GUI系统的相同的行为方式，并且在所有平台上的外观感受和功能都是相同的。对打印功能的访问、剪贴板和拖放功能都是在VCL内实现的。

1. 基础设施层

• 虚拟操作系统层（Virtual Operating System Layer，VOS）为了更方便地使用文件、线程、套接字等系统资源，把操作系统层（OSL）的所有功能封装成了C++类。这些C++类提供了一个以面向对象方式访问所有系统资源的便捷途径。

• 工具库（Tools Libraries）⁴由提供辅助功能的很多小库组成，包括处理日期时间相关数据的公共实现，也包括结构化存储方式的实现，另外还包括通用注册表、类型安全管理、以及持久属性数据的实现。

• 通用网络对象（Universal Network Objects，UNO）⁵是OpenOffice.org所使用的组件技术。这种组件技术不依赖于任何图形子系统，而是很大程度上基于多线程和网络通讯的环境所提供的功能。
  UNO中的IDL编译器能够根据特定的接口定义产生二进制表示形式和相关的C头文件或者Java文件。这个二进制表示形式是平台和语言无关的，并在运行时编组远程函数调用的参数、或者为特定语言访问接口所提供的实现产生即时代码。这种技术的优点是减少了同时为不同语言绑定所产生的代码量，缺点是不仅对每种语言绑定所产生的代码都需要特定的后端支持，而且对每种编译器都需要一个运行时的桥接模块。
  很多UNO的部件都是作为UNO组件实现的，这有助于创建非常灵活的系统以及运行时的系统扩展。以提供新的桥接/通讯协议为例，UNO提供了本地和在网络上的访问组件的透明方式，其中在网络上的通讯是通过IIOP实现的。如果组件是做为共享库实现的，那么该组件就可以被UNO加载入程序的进程内存中。从而对组件的每一个访问都好像是函数调用一样，不需要任何远程函数调用所需的参数编组。

• 通用内容代理（Universal Content Broker。UCB）⁶允许所有的高层代码透明地访问不同类型的结构内容。UCB由一个核心和若干通用内容提供者（Universal Content Provider，UCP）组成，后者用来集成不同的访问协议。现有OpenOfficr.org UCP实现了对HTTP、FTP、WebDAV和本地文件系统上内容的访问。

• 复合对象（Compound Objects）提供了复合文档（比如电子表格被镶嵌进文字处理文件中）的功能。现在的OpenOffice.org支持复合文档和镶嵌多媒体播放器这样的可视控件，并且这个实现是平台无关的。复合文档的所有内容都以同OLE结构存储格式兼容的方式保存，这样以来，只要支持OpenOffice.org的平台就可以访问OLE复合文档。复合对象在Windows平台上的实现可以和OLE服务交互，所以可以和所有支持OLE的应用程序更紧密地结合。

• 脚本与Basic库（Scripting and Basic Libraries）⁷提供一个解释器，用以解释源代码并产生元指令。这些指令可以通过附带的元指令处理器直接执行，或者在模块/库里持久保存已备后用。UNO实现的所有上层应用组件所提供的功能都可以通过组件的脚本接口访问到，这就保证了采用OpenOffice.org UNO技术的新组件不需很大的成本就可以被完全脚本化。脚本接口也实现为组件，这就允许其他脚本语言轻松地集成进来。在OpenOffice.org 2.0中会集成BeanShell⁸（一种轻量级的Java解释器）和JavaScript。实际上随OpenOffice.org所附带的Basic是一个Basic方言。

1. 构架层

• 应用架构库（Application Framework Library，SFX）⁹为所有的应用提供环境，每个应用所共享的而没有被其他层提供的功能都在这里实现。就程序结构来讲，每个应用都要实现一个壳（shell）和若干视图（view），SFX提供了所有的基础功能，所以应用只需补充特有的功能即可。
  这个架构库对于内容检测和集成来说也是结构合理的，模板管理和配置管理就在这里提供。SFX也和复合文档的一些方面相关，比如菜单和工具条的合并和设置。对所有应用的定制化功能也是由SFX提供的。

• 共享功能库（SVX Library）¹⁰为所有应用提供架构无关的共享功能。SVX的一部分实现了一个被若干应用用来做图形编辑和输出的完整的面向对象“画布”，这个“画布”还包含一个完整的3-D 引擎。另一部分实现了字体选择、颜色选择等公共对话框¹¹，而数据库连接¹²也是完全在这里实现的。

4. 应用层

所有的应用：文字处理应用¹³、电子表格应用¹⁴、演示文稿应用、图表应用等等，都是在这一层实现的。而这些实现实际上都是共享库，在运行时由应用架构进行加载。架构提供了所有这些应用的环境以及它们交互的功能。

2. UNO组件模型

现在开放系统世界里并没有每个人都接受的组件技术。桌面领域有KDE和GNOME，他们都把CORBA作为底层通讯方式的基础，但是高层的组件模型彼此完全不同。所以现在不可能写出在两种桌面环境都可用的组件。而且现在的CORBA规范中并没有包括组合文档和其他桌面软件相关的功能。

另一个问题是现大多数CORBA的设计实现都是用来通过远程服务运行分布式网络应用的。所以在桌面组件模型中采用这样支持完全网络通讯负荷的CORBA实现在大多数情况下都是错误的选择。Mozilla开源项目开始的时候就根据需要建立了一个可以轻松移植到不同平台上的轻量级组件模型，这就是XPCOM。

OpenOffice.org之所以采用自己的组件模型正是基于以上这些原因，以及为了提供一套与Microsoft Office相似的办公套件功能。OpenOffice.org套件提供的UNO组件技术满足了现代桌面应用对组件的所有需求。UNO也是在对象技术层面上形成的，该组件技术是OpenOffice.org API建立的基础。

UNO技术包含如下的特点：

• 开放：UNO支持所有流行的组件标准通讯协议，例如CORBA、JavaBeans、OLE（Windows Scripting Host、Visual Basic、Delphi等）、JavaScript、Python¹⁵、Perl¹⁶等脚本语言，以及C++和C语言的本地集成。其中C、C++、Java和Python都已经实现了完整的UNO绑定，而OpenOffice.org Basic、OLE和共同语言架构（Common Language Infrastructure，CLI）现在只支持访问UNO组件，还不能用来创建新的组件。

• 面向对象：UNO是面向对象的，支持聚集、集成、异常处理和多态这样的概念。

• 基于接口：UNO的功能被集成进接口里，具有相似功能区域的组件对同样的接口有访问权限，开发者将具有组件世界的真实感觉。

• 平台无关：UNO特意被设计成平台无关的，有OpenOffice.org的平台就有UNO。

• 支持异常：UNO提供对异常机制的支持，这意味着它可以被映射成嵌入的开发系统的出错处理机制，比如C++异常和Java异常。

• 开发系统无关：UNO可以用现在所有的流行开发环境和编程语言实现，包括C++、C、Visual Basic、Windows Scripting Host和所有支持COM的系统、CORBA、JavaBeans组件、以及OLE。

• 支持网络：基于UNO技术的组件可以在网络上通讯，也可以在远程服务器上实现功能，比如在互联网设备上提供完整的文字处理功能。

3. API，SDK，与UDK

OpenOffice.org 应用程序接口（Application Programming Interface，API）基于OpenOffice.org的UNO组件技术，由许多类CORBA的IDL定义¹⁷的接口所组成。UNO组件技术决定组件和应用如何相互通讯、某种编程语言如何访问API，而API定义了独立于特定编程语言的访问OpenOffice.org功能的接口。这种接口结构对于决定开发中需要重新实现应用到何程度非常重要。

OpenOffice.org API定义的接口具有如下特征：

• 完全是定义好的组件与环境的接口，可以轻松地组合起来满足特定对象的需求。

• 版本无关性，通用功能和特定版本所需要的功能被区分开来；

• 可扩展性，开发者可以从接口的一个最小集合开始逐步地增加应用的特性；

• 可重用性，总是尽可能地采用通用的接口定义。

与其他办公套件的API不同，OpenOffice.org并不是已有实现的简单反映，它是从应用和组件开发者的角度来设计的，所以提供了几乎所有的OpenOffice.org组件程序接口，并且可以集成新的组件。

1. 应用领域

OpenOffice.org API有很多应用领域。首先，为了自动运行某些任务可以编写典型的宏程序；其次，部分OpenOffice.org可以作为其他程序的组件运行，比如将OpenOffice.org当作JavaBeans组件来访问。另外，有一个非常有趣的应用是将OpenOffice.org的用户界面替换掉，并搭建一个完全不同的应用环境。

2. 结构规范

OpenOffice.org API的结构规范采用的是“接口与支持类”方式，而不是“实现－继承”方式。

“接口与支持类”方式意味者对象只通过接口进行通讯，支持类被用来提供实现。这样的设计思路是因为组件是高度地环境、语言、和版本无关的。“实现－继承”方式意味着部分实现的基类，而子类从中衍生接口并继承下来。不选择这种规范的原因是在较大的系统中会导致膨胀的接口和深度继承层次。而且，主要通过基类依赖于环境的组件，也是编程语言相关和高度版本相关的。

3. 对象模型

OpenOffice.org API是为UNO组件技术设计的，也是用它实现的。因此OpenOffice.org API是程序语言无关的，可以在C/C++、Java和好几种脚本语言中使用。对于其它语言来讲，只需要一个语言绑定就能够提供对整个OpenOffice.org API的访问。该API是基于以下的原型构造的：

• 实现类：类其实不是在OpenOffice.org API中实现的，在这里提及只是为了更好的理解。实现类实际上是使用真实的程序语言来实现服务。一般来讲，使用服务的开发者不需要处理API层次上的实现。而对象不是为应用而是为实现类翻译成实际语言概念，这点类似于Java现实类的实现。

• 服务：对象规范称为服务。你可以把服务想象为对支持服务的实现类和使用组件所提供服务的应用都有利的“合同”。服务通常描述实现的的接口和一套参数。虽然服务通常不翻译成实际语言概念，你也可以把它看作类似于Java的抽象类。

• 接口：API层次上某一方面的规范称之为接口。接口可被看作是“合同”内通过合法验证的文字模块，接口可以组合成整个“合同”。OpenOffice.org API中的接口非常类似于Java中的接口。

• 结构：普通的数据块可以被定义为结构，因此结构是不含方法的。结构的优势在于它们可以传送到不同的进程甚至不同的机器，这会大大提高了进程间通讯和远程调用的效率。使用Java实现时，结构可以表示为只有数据成员和get/set方法的类。

• 异常：异常是方法调用的非常规结果。正如在Java中一样，异常被用来处理出错。

• 常量/常量组/枚举：常量被分成两类，可以分组和赋值为数值和字符串值的常量，和包含数值固定集的枚举。在Java实现中，这两者都表示为具有常量数据成员的类。

4. 模块化分层

OpenOffice.org API是按照与Java及CORBA类似的层次模块概念来组织的，从上到下一共分为四层：

• 办公软件接口，比如对文字处理、电子表格、绘图和演示文稿的接口；

• 集成架构接口，使得能够集成进OpenOffice.org新的组件，比如配置管理和通用内容代理；

• 应用域无关接口，这类非常重要的接口包括属性访问、集合、流操作、附加脚本引擎和其他很多接口；

• 组件系统接口，这部分基础接口包括必要的处理对象模型的接口，比如生命期控制、查询、建立桥接、和实例化远程对象等接口。

5. SDK和UDK

OpenOffice.org软件开发工具包（Software Development Kit，SDK）¹⁸是OpenOffice.org的一个补充部件。它提供使用现有UNO组件与开发新组件编写应用所需要的工具、例程和文档。SDK的主要部分就是《OpenOffice.org开发者指南》¹⁹，这本超过1000页的内容全面的指南提供了OpenOffice.org API概念、UNO组件模型、和在不同应用上下文中如何使用API的详细介绍。这本《指南》对于利用SDK进行OpenOffice.org的二次开发具有非常重要的参考价值。利用OpenOffice.org API和SDK提供的其他资源，开发者可以在不修改OpenOffice.org源代码的情况下使用自己熟悉的编程语言，基于UNO组件构建新的应用。

开发者在OpenOffice.org中有时也会看到UDK和ODK这样的名称，它们与SDK有联系也有区别。UDK是UNO和SDK的合称，而ODK实际上是指SDK中的一个模块，也用来指SDK中OpenOffice.org架构和应用相关的高层部分。

4. 融合与发展

   1. 组件桥接

现在桌面环境下所流行的组件技术有KDE/KParts²⁰、GNOME/Bonobo²¹、CORBA、Mozilla/XPCOM²²、OLE/ActiveX和OpenOffice.org/UNO等，各种组件技术之间的交互并不方便。为了在不同的环境中提供办公软件的功能，就有必要支持不同的组件技术。由于OpenOffice.org的组件技术能够使用桥接方式访问其他组件，有可能将办公组件集成进不同的环境中，比如GNOME、KDE和Mozilla。在组件基本概念非常相似的环境中实现桥接是相当容易的，而其他环境下想要隐藏所有的概念差异并提供桥接功能可能会非常困难。但是在很多情况下开发者和用户必须要处理不同的概念和哲学。而且如果桥接需要处理复杂的参数和调用转换，效率问题可能会凸现出来。

由于OpenOffice.org UNO支持对OLE的桥接，所以OpenOffice.org已经能够作为一个ActiveX控件在IE等支持ActiveX的程序内运行。可惜的是UNO同GNOME/Bonobo桥接的项目开始后又中止了。而OpenOffice.org为Mozilla提供的插件也已经开发完成，将会集成在2.0版本中。OpenOffice.org为KDE中的Konqueror 制作的插件²³也已经实现了一些基本功能。

2. 本地部件架构

在VCL最初的设计中并不封装底层GUI系统的本地窗口部件或控件。平台相关部分实现了2-D图形“画布”以供VCL上层的平台无关部分使用，该“画布”将每个功能调用都重定向到了底层的GUI系统上。

后来为了使OpenOffice.org在各个平台上的观感更接近于本地系统，开始了一个称作本地部件架构（Native Widget Framework，NWF）²⁴的项目。NWF的基本方法是使用本地桌面环境/窗口管理器提供的可视部件替换当前的基于窗口系统API实现的可视类库。现在把OpenOffice.org集成进KDE²⁵的项目正在进行，其中就包括实现KDE本地部件架构²⁶、和基于Qt实现VCL插件²⁷的两个子项目。其他的针对GTK+、Win32、和Apple Aqua ²⁸的NWF实现也在进行当中。

本篇主要介绍了OpenOffice.org的技术体系结构。在这一体系结构中有很多闪光之处，比如跨平台的分层结构、虚拟操作系统概念、UNO组件模型、基于IDL的API和SDK等等，都对OpenOffice.org移植到众多平台上、并获得广泛的应用和赞誉贡献良多。实际上OpenOffice.org架构中还有一些优秀的特性，因为篇幅所限在这里没有详细介绍，比如基于UNO的数据库连接（SDBC）和通用内容代理/提供者（UCB/UCP）。这些技术架构的详细内容需要读者实际进行研究与开发才会有更深入的理解。

下一篇将会介绍OpenOffice.org的另一个优秀的技术特点：开放、可扩展和标准化的XML文件格式规范。

本文依据《创作共用约定》之“署名-禁止派生-非商业用途”方式发布，即你可以免费拷贝、分发、呈现和表演当前作品，但是必须基于以下条款：

• 署名：你必须明确标明作者的名字。

• 非商业用途：你不可将当前作品用于商业目的。

• 禁止派生：你不可更改、转变或者基于此作品重新构造为新作品。

对于任何二次使用或分发，你必须让其他人明确当前作品的授权条款。

在得到作者的明确允许下，这里的某些条款可以放弃。

此约定是法律文本（完整的协议）²⁹的简单易读概要。

模块

功能描述

accessibility

提供对辅助功能的支持

apache_java

包括Apache提供的Java工具，Xalan和XML-APIS³⁰

autodoc

从UNO IDL和C++源文件自动产生文档的工具

automation

自动测试架构

basctl

Basic集成开发环境

basic

Basic解释器和运行时库

berkeleydb

Sleepycat公司³¹提供的轻型数据库

bitstream_vera_fonts

Bitstream公司提供的用于拉丁语系文字的Bitstream Vera字体³²

boost³³

与C++标准库协作的一套可移植的C++库，将会包含进C++标准库中

bridges

实现UNO向C++（MS Visual C++、Sun Forte C++、gcc等）和Java等不同语言的桥接

chaos

在UCB之前使用，大部分已废弃，现在只实现邮件文档转移服务

codemaker

包含产生C++头文件、Java文件和IDL文件的程序，该程序是在unoidl编译器产生二进制格式注册表上工作的

comphelper

编写UNO组件所需的辅助类

configmgr

访问配置信息的注册表客户端UNO组件

config_office

配置编译环境

connectivity

数据库连接，包含了ODBC、JDBC、ADO、MySQL、dBase等数据库驱动的实现

cosv

用C++实现的工具库，包括对文件、字符串等的访问

cppu

除了Java之外所有的语言绑定所需的运行时库

cppuhelper

C++的UNO辅助类的实现

cpputools

UNO工具和运行时程序的集合

crashrep

程序崩溃后的汇报工具

curl³⁴

客户端的URL转换库

dbaccess

数据库访问层，包含从应用访问数据库相关的用户界面

desktop

产生office可执行代码，基于offmgr模块

dictionaries

拼写检查、同义词等功能所需的字典，现在只支持西方文字

dlcompat³⁵

Mac OS X/Darwin系统中与动态加载库函数dlopen(3)兼容的库

dmake³⁶

类似于GNU make和Sun Forte dmake的make工具

dtrans

实现剪贴板管理器、MIME类型管理、拖放功能等辅助功能

embedserv

实现OLE2的接口

eventattacher

基于组件的事件处理

expat³⁷

用C语言实现的轻型XML解析器

extensions

为各种目的提供的独立UNO组件，例如OLE、PGP、语音等

external

包含若干外部组件

extras

对程序正常运行至关重要的非代码性辅助文件

fileaccess

实现UCP的文件系统访问

filter

包含各种文件过滤器的实现

forms

实现窗体控件

fpicker

基于UNO实现了封装窗口系统文件对话框的文件拾取器

framework

集成不同环境（基于SFX和不基于SFX）中的应用组件

freetype³⁸

平台无关的字体引擎，特别用于亚洲字体

goodies

辅助类（例如3-D基本功能和图形管理器）与外部图形文件过滤器

gtk

与GNOME集成需要的模块

helpcontent

二进制格式的英文帮助内容，其他语言的帮助内容³⁹需要单独下载

i18n

旧的国际化架构，只支持西方语言

i18npool

新的国际化架构，支持西方语言，东亚语言和复杂文字排版

i18n_simple

国际化的UNO实现框架

i18nutil

国际化所需的工具

icu⁴⁰

IBM提供的Unicode国际化组件技术

idl

为所有基于SFX的组件由IDL生成所需的定义（头）文件

idlc

UNO的IDL编译器

instsetoo

生成可执行的安装包，即将升级到instsetoo_native

io

包括基本的UNO输入/输出流的服务和进程间通讯

javaunohelper

Java的UNO辅助类的实现

jpeg

JPEG图像格式过滤器

jurt

Java的UNO运行时库，包含UNO的Java绑定

jut

Java的UNO辅助工具的集合

jvmaccess

C++实现访问Java虚拟机

lingucomponent⁴¹

创建不同语言的字典、词典和其他相关工具

linguistic

UNO语言组件的封装和特定语言的实现

MathMLDTD

W3C制定的MathML DTD规范⁴²，用于公式的文件格式

moz

编译地址簿连接驱动所需的Mozilla的头文件和库

msfontextract

libmspack⁴³提供的解压CAB文件格式的工具，用以释放字体

nas

网络透明的C/S模式音频传输系统NAS⁴⁴，用以提供对音频的支持

neon⁴⁵

C接口的HTTP和WebDAV的客户端库，提供对UCP的支持

netbeans_integration

将SDK集成进NetBeans⁴⁶ IDE的组件技术

np_sdk

为Mozilla编写客户端插件需要的SDK

odk

为生成SDK进行第一步编译

offapi

包含特属于UNO组件的部分API，接口用IDL语言写成

officecfg

包含应用和组件的配置schema

offmgr

包含全局功能配置的资源和代码，基于sfx2，与svx模块紧密相关

offuh

生成UNO的C++头文件，任何API模块中产生代码的文件若有变化则须更新

openssl⁴⁷

支持SSL/TLS的开源工具包

package

实现打包压缩功能的UNO组件

padmin

打印机管理工具，用来在UNIX平台上配置打印机

psprint

产生PostScript代码，是当前UNIX平台上的打印方式，即将支持CUPS⁴⁸

psprint_config

PostScript打印机的配置文件集合

python

Python⁴⁹语言运行环境，用以支持UNO-Python桥接

pyuno

实现UNO-Python桥接

qadevOOo

自动化完成产品的测试

rdbmaker

由二进制格式注册表产生子集或进行反射

readlicense

自述文件和许可证文件

readlicense_oo

OpenOffice.org自述文件和许可证文件

regexp

GNU C库⁵⁰提供的正则表达式处理程序，用C++做了封装

registry

通用注册表的实现

remotebridges

包含进程间UNO桥接的UNO服务，例如IIOP桥接

res

包含位图、图标、光标文件这样的典型资源文件

ridljar

生成Java类文件，udkapi模块中任何产生代码的文件若有变化则须更新，该模块还包含一些Java实现的核心API，例如Any类型

rsc

资源编译器，从用户界面的文字描述生成二进制描述

rvpapi

用Java实现远程通讯的接口

sablot

来自于Ginger联盟⁵¹的C++实现的XSLT处理器

sal

系统抽象层，集成了所有支持平台的底层API，定义平台无关的C语言API

salhelper

系统抽象层的辅助类

sandbox

基于Java 的安全管理器

sane

支持SANE⁵²接口扫描设备的文件

sax

XML SAX⁵³解析和输出的UNO组件

sc

电子表格应用组件

scaddins

电子表格应用的附件

sch

图表应用组件

scp

安装脚本文件，即将升级到scp2

scptools

打包工具

sd

演示文稿应用组件和绘图应用组件，它们由相同的代码基产生

sdk_oo

为SDK进行第二步编译，生成最终的完整工具包

setup2

安装程序的实现，即将升级到setup_native的本地安装方式

sfx2

SFX是应用架构的核心模块

shell

实现某些shell命令的工具，例如网络代理设置和命令行邮件

sj2

提供对嵌入式Applet程序的支持，也用Java实现了JavaScript引擎

smoketest

安装程序的粗略测试

so3

包含组合文档对象的基础实现部分，也实现了OLE桥接

solenv

编译环境（solar）

soltools

solar编译环境所需的工具

sot

与Microsoft Office兼容的存储实现方式

starmath

数学公式应用组件

stlport⁵⁴

多平台的标准C++模板库的实现

stoc

基本UNO服务

store

可信赖、可恢复的存储所需的包含文件和数据流的文件访问，由registry使用

svtools

基于VCL的工具集

svx

2-D与3-D绘图引擎，以及其他与应用架构无关的共享库

sw

文字处理应用组件

sysui

实现与桌面系统环境的集成

testshl

旧的测试脚本，已废弃

testshl2

新的测试脚本

testtools

测试工具

toolkit

用UNO工具包和控件实现VCL

tools

包含字符串、时间、日期、流等基本类

transex3

本地化工具

twain

支持TWAIN⁵⁵图像获取设备标准的文件

ucb

UCB核心的实现和相关辅助服务，也包括各种UCP

ucbhelper

使用UCB和实现UCP需要的C++辅助类

udkapi

包含属于UNO核心的部分API，接口用IDL语言写成

udm

C++工具类，实现对HTML、XML、和组合数据类型等的支持

unixODBC⁵⁶

非Windows平台上提供的支持ODBC的开源软件

UnoControls

包含非直接调用VCL的UNO控件，这些控件使用抽象窗口工具包

unoil

生成Java类文件，offapi模块中任何产生代码的文件若有变化则须更新

unotools

提供基于UNO的API的辅助类

unzip

自由的infozip⁵⁷压缩库

uui

提供UCB图形用户界面的组件

vcl

可视类库，窗口管理与基本控件库，也包含用户界面的系统抽象层

virgule

实现获取击键事件、操纵键盘映射的功能

vos

虚拟操作系统层

wizards

应用中向导所需的基本宏和库

x11_extensions

X-Window扩展库中render相关的头文件

xml2cmp

实现UNO组件描述的处理器

xmlhelp

以UCP方式实现的帮助

xmloff

XML的输入/输出过滤器

xmlscript

实现XML对脚本的支持

XmlSearch

用Java实现的对XML的查询引擎

zlib⁵⁸

一个没有法律风险的自由软件，实现数据压缩功能

表 1 OpenOffice.org 1.1.2源代码模块的功能描述表

图 2 OpenOffice.org 1.1.2源代码模块依赖关系树状图