Difference between revisions of "Modularization"

From Apache OpenOffice Wiki
Jump to: navigation, search
 
(43 intermediate revisions by 5 users not shown)
Line 1: Line 1:
−
== OpenOffice.org Modularization ==
+
{| align=right style="margin-left: 15px; border:1px solid #aaaaaa; background-color:#f9f9f9; padding:5px; font-size: 95%;" class=box
 +
|---
 +
|
 +
'''''Project Tools'''''<br>
 +
* [http://modularization.openoffice.org/servlets/ProjectHome            Project home]
 +
* [http://modularization.openoffice.org/servlets/ProjectMemberList      Membership]
 +
* [http://modularization.openoffice.org/servlets/ProjectNewsList        Announcements]
 +
* [http://modularization.openoffice.org/servlets/ProjectMailingListList Mailing lists]
 +
* [http://modularization.openoffice.org/servlets/ProjectDocumentList    Documents&amp;files]
 +
* [http://modularization.openoffice.org/source/browse/modularization    Version control]
 +
* [http://modularization.openoffice.org/servlets/ProjectIssues          Issue tracker]
  
−
Often the question arises why is OpenOffice.org not more modular. There are several aspects of modularization:
+
'''''[[Modularization/To-Dos|To-Dos]]'''''<br>
 +
'''''[[Modularization/Efforts|Efforts]]'''''
 +
<DPL>category=Modularization
 +
category=Effort
 +
count=2</DPL>
 +
* [[Modularization/Efforts|...]]
 +
'''''[[Modularization/Articles&Tutorials|Articles&Tutorials]]'''''
 +
<DPL>category=Modularization
 +
category=Article|Tutorial
 +
count=2</DPL>
 +
* [[Modularization/Articles&Tutorials|...]]
 +
* [[Modularization/IRCLOGS|IRCLOGS]]
 +
|}
  
−
== Views on Modularization ==
+
Lead: [[KR|Kay Ramme]], [[User:Liutao|LiuTao]] Co-Lead: Xiuzhi Cheng
  
−
=== User View ===
+
... by now OOo has been regarded as the only real alternative office suite,
 +
sometimes hard to build, often admired for its feature completeness,
 +
somewhat beaten because of the memory footprint, understood to have one
 +
of the most classical graphical user interfaces ever, loved to recover
 +
MS documents, and so on ...
  
−
From the user point of view there are several modules:
+
==The Modularization Project==
−
* Word Processor
+
Many words may be used for OOo, though small is not with them :-)
−
* Spreadsheet Module
+
OOo is a huge project, with lots of code and a more or less monolithic
−
* Impress Module
+
architecture.
−
* Database Module
+
−
* Core Modules
+
−
* Desktop Integration
+
−
* Filter Modules
+
−
and many more.
+
  
−
=== Architectural View ===
+
It seems a hero is needed ... we want to move out to fill this position ...
  
−
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
+
... to Improve and Support Modularization of OOo.
−
* System Abstraction Layer
+
−
* Infrastructure Layer
+
−
* Framework Layer
+
−
These layers themselves can contain some layers again, helper and wrapper layer and so on.
+
  
−
=== Source Code ===
+
===The Build Wizard===
−
The Source Code itself is group im more than 150 modules, each of these can be build in one pass.
+
A prototype of the Build Wizard may be started directly: [http://modularization.openoffice.org/dist/launch.jnlp Build Wizard]
  
−
Each compilation unit and each C++ class also can be viewed as a module.  
+
===IRC===
 +
Meet us on IRC. Every Tuesday we do meet on IRC to discuss progress and state, goals and the weather.
  
−
=== Libraries ===
+
<center>Channel: ''irc.freenode.net#ooom12n''</center>
 +
<center>Time: ''3:00pm PEK / 9:00am HAM / 4:00am New York / 1:00am SFO''</center>
  
−
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.
+
===DOING===
 +
#Docbook support configurable. ( Just uploaded the unfinished extension [[File:DocBook.zip.gz]] )
 +
#new configure tree node
 +
[[Image:Newconfituretreenode.JPG]]
  
 +
==OtherLinks ==
 +
[http://wiki.services.openoffice.org/wiki/modularization_org Original wiki page of modularization]<br>
 +
[http://wiki.services.openoffice.org/wiki/Modularization_more_goals  Here comes more goals]<br>
 +
[http://wiki.services.openoffice.org/wiki/Modularization_build_wizardattachment  build_wizardattachment]<br>
  
−
== 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]]
 +
[[Category:Redoffice]]
 +
[[Category:Modularization]]

Latest revision as of 05:40, 3 August 2010

Project Tools

To-Dos
Efforts

Articles&Tutorials

Lead: Kay Ramme, LiuTao Co-Lead: Xiuzhi Cheng

... by now OOo has been regarded as the only real alternative office suite, sometimes hard to build, often admired for its feature completeness, somewhat beaten because of the memory footprint, understood to have one of the most classical graphical user interfaces ever, loved to recover MS documents, and so on ...

The Modularization Project

Many words may be used for OOo, though small is not with them :-) OOo is a huge project, with lots of code and a more or less monolithic architecture.

It seems a hero is needed ... we want to move out to fill this position ...

... to Improve and Support Modularization of OOo.

The Build Wizard

A prototype of the Build Wizard may be started directly: Build Wizard

IRC

Meet us on IRC. Every Tuesday we do meet on IRC to discuss progress and state, goals and the weather.

Channel: irc.freenode.net#ooom12n
Time: 3:00pm PEK / 9:00am HAM / 4:00am New York / 1:00am SFO

DOING

  1. Docbook support configurable. ( Just uploaded the unfinished extension File:DocBook.zip.gz )
  2. new configure tree node

Newconfituretreenode.JPG

OtherLinks

Original wiki page of modularization
Here comes more goals
build_wizardattachment

Retrieved from "https://wiki.openoffice.org/w/index.php?title=Modularization&oldid=177075"
Personal tools