A Fusion Of Formats

March 1, 2010

An important part of every text is its format. As we discovered while working on this project, the right type of format is particularly important when documenting computer products. We first started by looking at a Wiki and recreating it with our own “improved” template. Before gaining insight into the actual content, we tried to devise a structural organization that we would expect to see in a document of this type.

Our Template

We were planning on including the following categories:

1. Description

2. Consumer

2.1. Usage

2.2. Code Samples

2.3. Eclipse 3.x

3. Producer

3.1. Usage

3.2. Code Samples

3.3. Eclipse 3.x

4. Related Materials

4.1. Related Services

4.2. Related API’s

4.3. See Also

Clearly our focus was on including as much relevant content as we could. However, as we started familiarizing ourselves with the core services and their usage, a number of questions arose. Do we have information for all of the categories? Are these the kind of categories a new developer would expect to see? How would our documentation be different from the Wiki that already exists?

Looking for an answer we decided to review the Design Patterns book, a well known authority for modern software developers. There certainly are similarities between the design patterns in Object Oriented programming and the core services in Eclipse. The most obvious example would be that both the GoF and our team are trying to present a general approach, instead of a detailed code implementation. Nevertheless, with Design Patterns the focus appears to be on their structure and development while for the core services we would like to document the features, relationships and applicability. Therefore, some of the categories that appear for each one of the Design Patters are not necessarily relevant to our format. A short list of the ones that we could use was compiled by Brent.

The Design Patterns

1. Intent

2. Motivation

3. Applicability

4. Implementation

5. Related Patterns

Most of the items from this list were already present in our initial template, but organized differently. Perhaps, the authors of the Design Patters book found good reasons to use these categories. We can certainly learn from their experience and transform our template into a closer resemblance of the aforementioned categories. The idea will improve our document by contributing the Intent and Motivation paragraphs which were overlooked to some extent in our template. However, from working on the e4 core services we know that there still remain pieces of information which we have to fit in the document. May be this is a good place to borrow from the legend in computer software: Microsoft. Chris reviewed the .NET documentation which has couped in many aspects with issues similar to the ones we are encountering. For instance, an example can sometimes be worth million words. The example can be in the form of a case study, a snipped of code or a list of relevant terms. Anything that helps demonstrate the power and flexibility of the services would be helpful.


1. Case Study

2. Relevant Terms

3. Code examples

4. Diagram

5. Flexible template

The above list of contributions can add “the missing piece” to our format and help us create a new template which encompasses most of the relevant categories for our documentation. It will likely continue to evolve as we continue working on the project but it can make for a good starting point for our discussions.

Revised Template

1. Description (+Intent)

2. Relevant Terms

3. Motivation: Case Study

4. Applicability and Usage

5. Implementation

5.1. Code Examples

6. Related Services

7. Diagram

We may also retain the ability to skip certain sections if necessary, providing for a flexible template. By mixing our own experience and expectations, together with the experience of the renown Design Patterns experts as well as the .NET documenters and, last but not least, with the valuable contributions from the Eclipse development team and our professor Christina Penner, we are on our way to creating a better and more useful documentation.

The GoF book uses a consistent structure for documenting each of their services and as we have discussed repeatedly now on the applicability of their model to ours, I’ve taken a look at their structure and will outline my thoughts on each of their sections. I will list out the section and my thoughts on it’s applicability to our project:


A brief (1 sentence) description of what the pattern does. e.g. “Provide an interface for creating families of related or dependent objects without

specifying their concrete classes.” I like this as it’s quick, doesn’t require a lot of effort, let’s you quickly get an understanding of what it does and I think can be used in our model.

Also Known As

I don’t think we really need this.


This section speaks to why the pattern is useful and to what problem it solves, really why it exists in the first place. This is an excellent candidate for our services which may not be obvious for some of the less generic ones and gives excellent context to learning about what it actually does. It’s slightly longer than the others (2 – 3 paragraphs) which I think would be an appropriate goal length for ours as well.


The book uses this section to give a quick (bulleted) list of some situations when to use this pattern. Another excellent candidate for our services, a quick list to highlight some scenarios when you’d want to use a particular service.


A (graphical) representation of what the pattern looks like, UML diagrams. I don’t think this is overly helpful to our cause the “structure” of the service I don’t feel is particularly important to how it’s used or implemented. Really the implementation details will figure out the structure as need be but there is not necessarily a common one. A simple example is Loggers which can be implemented in and have drastically different structures depending on the targeted output.


This section of the book details the participants as show in the structure; if we don’t need a structure section we don’t need this either.


Who does what; again not needed for our format.


This section talks about the benefits and liabilities of using each pattern. I don’t have a definite answer but I don’t know that this would be that helpful for talking about the risks and rewards in using a specific service. There may not even be another way in some cases, which is where we differ in concept from the book in that they are taking a collection of practices that are a bit of the “wild west” in how they are done and attempting to pull out the good parts and standardize them into patterns whereas a lot of our services are simply THE way you do something.


This section is a little closer to the metal and gives hints and considerations when implementing the pattern. It will do things like highlight languages, language constructs or features etc. that suit a particular pattern well and provide some issues to think about in the implementation. Something akin to this would be useful as a brief section in the details on the producer of a service, some things to consider when implementing it that the developer may not have thought of otherwise.

Sample Code

Self explanatory and as previously discussed we are trying to avoid discussing the services at this level.

Known Issues

<insert any 1 of many jokes about the current state of the code/documentation here> This section talks about certain implementations of the services in different software packages and some known issues regarding them. Not applicable for us.

Related Patterns

Related services would certainly be applicable… “People using this service have also bought services X, Y and Z” a’la Amazon.

In summary, the sections I think we can borrow (copy) are:

  1. Intent
  2. Motivation
  3. Applicability
  4. Implementation
  5. Related Patterns (Services)

To give it the 5 W’s test, we have the Who and the When in Applicability, we have the  Why between Intent and Motivation. The What is sort of implied in Intent and Motivation but perhaps we should still include a description of exactly what the service is? The Where is missing completely, and we should include a Usage section perhaps on how to use it, not from a code level but more abstractly, like to say “query the context for it” etc. The Related Patterns (Services) section provides some good further information, but looking at some of the sections we skipped from the book, I would think it may also be useful to add a section called something like Tips or Extra Info to have a spot to put any other tidbits of information that would be useful. The book formalized them into their own sections because they had enough of it for each pattern, but in our case I think we may just have some tidbits here and there and it would be more consistent just to have a little section to put them in.

This post was just an initial flyby of the style used in the book, the real test on applicability will be trying to fill the sections we’ve thought of to see how it really fits. This is a perfect example of an article of clothing looking like it’ll fit in the store and being 3 sizes to small when you bring it home; you just don’t know until you try it on.

Service Template

February 12, 2010

*** Posted on our no longer used Google site on Feb 4 by Brent ***

The service template formatting is complete and can be found at “http://wiki.eclipse.org/e4/Doc/Template&#8221;. The structure isn’t set in stone so if it makes sense we can consider evolving it further.

Documentation Template

February 12, 2010

*** Posted on our no longer used Google site on Jan 30 by Chris ***

In our Jan-29 meeting, we decided upon a documentation format which includes, for each service:

1. A basic description of what function the service performs or why it exists. Information this section is not expected to be specific to e4.

2. An “In Eclipse e4” section which describes how the service is approached in e4. It can include a design description, necessary definitions, important considerations. This is also the place where relationships to other services will be noted. This section should remain code-agnostic.

3. A “Usage” section which gives code examples for how to use the service.

Attached is a sample of what such document will could look like.

The media for development and deployment of the documentation are still TBD, but we’d like to integrate as closely as possible into the existing Eclipse structure.