Difference between revisions of "Modularization"

From Apache OpenOffice Wiki
Jump to: navigation, search
Line 1: Line 1:
== OpenOffice.org Modularization ==
+
== The Modularization project==
  
Often the question arises why is OpenOffice.org not more modular. There are several aspects of modularization:
+
This project is designed to optimize the architecture,custom-tailor a concrete product of OpenOffice which the end-user can select their favorite features and make the OOo kernel more and more smaller.
  
== Views on Modularization ==
+
== Purpose of Modularization ==
  
=== User View ===
+
1. end-user can custom-tailor the features of OOo .<br>
 +
2. developers only need build and update part of the module to update the OOo.<br>
 +
3. Splitting the OOo to kernel(smaller is better) and apps to enable the office vendors can custom-tailor their products. Just like Linux kernal and Mozilla core.<br>
  
From the user point of view there are several modules:
+
== Plans of Modularization ==
* Word Processor
+
1.independent Apps.<br>
* Spreadsheet Module
+
2.build on installed OOo, small developer packages.<br>
* Impress Module
+
3.smaller, independent packages.  <br>
* Database Module
+
* Core Modules
+
* Desktop Integration
+
* Filter Modules
+
and many more.
+
  
=== Architectural View ===
+
== Benchmarks ==  
 +
1.encapsulation <br>
 +
2.unambiguously defined, consistent and minimal interfaces <br>
 +
3.dependencies always shall have tree-shape, no circles (small dependency circles up to about 5 compilation units or 2 larger modules may be necessary sometimes) <br>
  
The [http://www.openoffice.org/white_papers/tech_overview/tech_overview.html#27 Architectural OverView] shows a very stripped down overview. In reality we will find up to 20 layers below an Application module. All code which can be shared among the Application modules has been moved to core modules. Examples for such layers are
 
* System Abstraction Layer
 
* Infrastructure Layer
 
* Framework Layer
 
These layers themselves can contain some layers again, helper and wrapper layer and so on.
 
  
=== Source Code ===
+
== ToDos ==
The Source Code itself is group im more than 150 modules, each of these can be build in one pass.
+
1.make modules to be brief, completely pure, and not cotain other modules' stuff.<br>
 +
2.List features of Modules , and then divide them into primary features, and secondary features. <br>
 +
3.Form a dictionary(or Tree) of Features-Files(Source Code).From which we will know the relationship of the sources and the features. <br>
 +
4.Make the secondary features to be extentions or optional installtion.<br>
 +
Etc...<br>
  
Each compilation unit and each C++ class also can be viewed as a module.
+
== Work in progress ==
  
=== Libraries ===
 
  
Often libraries are build on per (source code/CVS) module basis, sometimes several libraries are built in one CVS module. Attention: at many places the runtime dependencies of the library modules differs from the build sequence of CVS modules.
+
== Other Links ==
 
+
 
+
== Goals of Modularization ==
+
When viewing the list of problems, one can see some terms repeated often. In reverse, those lead to some goals (items are not necessarily distinct):
+
 
+
* Reducing dependencies
+
**  implementation dependencies (improve maintainability, testability, correctness)
+
**  build time dependencies (reduce build effort, also accelerate development)
+
**  run time dependencies (improve runtime efficiency)
+
* Maintainability
+
**  clear points of responsibility - one piece of code for each task
+
**  changes have less risk, because they most times only affect a clearly separated amount of code
+
**  code is easier to understand, if module's tasks and interfaces are clearly defined
+
* Testability
+
**  modules can be tested in isolation
+
* Runtime efficiency
+
**  only needed modules are loaded, leading to less memory usage and faster startup
+
* Correctness
+
**  less regression, because changes have fewer side effects
+
**  better tests, because tests can concentrate on sharply separated units
+
 
+
== Principles of Modularization ==
+
How does one recognize a module? What is a "good" module?
+
* encapsulation
+
* unambiguously defined, consistent and minimal interfaces
+
* dependencies always shall have tree-shape, no circles (small dependency circles up to about 5 compilation units or 2 larger modules may be necessary sometimes)
+
 
+
== Review of the Current Structure ==
+
 
+
=== Possibilities ===
+
The current structure does not only have problems, but also provides some possibilities on which further modularization might build up.
+
 
+
* The system abstraction layer provides a lot of independence from platforms and enables, though OpenOffice.org is a huge project, relatively easy portability.
+
* UNO allows to write components which enforce modularization, because they are only accessible via well defined interfaces.
+
 
+
=== General Problems ===
+
''List problems here, if they occur at many places or are of principal nature.''
+
 
+
* Selective Installation of Application modules doesn't save disk space for the User.
+
* Amount of modules and their dependencies is impossible to overview for Developers, this leads to
+
**  maintainability problems
+
**  code complexity
+
**  long build times
+
* Architectural/source code modules are not clearly separated from each other by interfaces. Instead clients depend on implementation details of the module. Often it is not really defined what shall be interface and what was meant as implementation only. Consequences:
+
**  complexity - as it is unclear which functions of a module are for public use and which are not
+
**  avoidable build time - as dependant source code needs to be rebuild, when implementation details of a module are changed
+
**  maintainability problems - because when changing implementation details of a module, it is unclear which client code will be influenced and how.
+
* There is a lot of duplicate code for the same tasks in parallel use cases. This leads to problems with
+
**  performance - because of increased code size in memory
+
**  maintainability - because to change one feature, it is often necessary to change a lot of different locations in code; sometimes even nobody knows which all those locations would be
+
* Large circular dependencies among compilation units. There are several cases where one or a few hundred compilation units are circular dependent on each other. This means:
+
** testing problems - none of them can be tested in isolation, unit tests are nearly impossible
+
** maintainability problems - lots of regression, because a change in one of those files may cause side effects in a few hundred others
+
 
+
=== Specific Suggestions for Improvement ===
+
''List suggestions here, if they are already related to concrete locations in the code or specific architectural concepts.''
+
  
 
[[Category:Build_System]]
 
[[Category:Build_System]]

Revision as of 01:12, 8 April 2009

The Modularization project

This project is designed to optimize the architecture,custom-tailor a concrete product of OpenOffice which the end-user can select their favorite features and make the OOo kernel more and more smaller.

Purpose of Modularization

1. end-user can custom-tailor the features of OOo .
2. developers only need build and update part of the module to update the OOo.
3. Splitting the OOo to kernel(smaller is better) and apps to enable the office vendors can custom-tailor their products. Just like Linux kernal and Mozilla core.

Plans of Modularization

1.independent Apps.
2.build on installed OOo, small developer packages.
3.smaller, independent packages. 

Benchmarks

1.encapsulation
2.unambiguously defined, consistent and minimal interfaces
3.dependencies always shall have tree-shape, no circles (small dependency circles up to about 5 compilation units or 2 larger modules may be necessary sometimes)


ToDos

1.make modules to be brief, completely pure, and not cotain other modules' stuff.
2.List features of Modules , and then divide them into primary features, and secondary features.
3.Form a dictionary(or Tree) of Features-Files(Source Code).From which we will know the relationship of the sources and the features.
4.Make the secondary features to be extentions or optional installtion.
Etc...

Work in progress

Other Links

Personal tools