Difference between revisions of "Intent/Architecture"

Revision as of 03:21, 26 January 2011

One of the primary purpose of Intent is to allow several users (developers, architects, project managers...) to collaborate around a software design. Consequently, different users must be able to concurrently access and edit a same Document. To achieve this goal, Intent has been based on a distributed architecture, relying on the Repository concept.

Another important feature of Intent is its extension capabilities, whether it concerns the support of custom DSLs for describing model fragments, the definition of new Intent clients, the synchronization of new informations or the technology used to store and manage Intent's datas.

A distributed architecture relying on a Repository

Intent actually consists of loosely coupled components, each one of them being registered as clients of a shared Repository.

Repository : fundamental properties

In order to wrap the concrete technology used to store the Document and manage concurrent accesses, we have defined the Repository interface.

Any Repository must provides the following features :

• access to any element of the Document from an URI (REST-oriented API)
• provide transactional mechanisms for saving/rolling back changes made on the Document
• notify all subscribed clients of any modification made on listened elements

Many concrete technologies can be used to fulfill this contract : one can define a Repository using CDO, an other would choose to implement it using EJBs... The default implementation uses the EMF and the Eclipse Workspace.

In Intent, the Repository will be used to store the Document, as well as many other informations (compiled version of described models, traceability links, synchronization or compilations issues...).

Intent : a set of Repository clients

Intent is less a software than several softwares communicating through a shared Repository. Each clients can ask the Repository to be notified on any modifications made on precise elements. Thanks to this notification mechanism, clients will be able to communicate in order to achieve complex tasks.

File:Repository.png

Let us quickly describe the minimal set of clients needed by Intent to work :

• the Authoring tool, which is for now on the only tool that users will actually interact with. This tool is an Eclipse editor allowing users to edit a Document, to search for all documentation parts related to a concern or a model element, to display compilation or synchronization errors associated to the described models, providing code completion and quick-fixes…

• the Compiler (Tangler) is used to generate the models described inside the Document. It is notified of all modifications made on any Modeling unit of the Document, and reacts by updating the generated models. If the generated models contain validation errors, or if the compiler detects syntax errors inside a Modeling Unit, the authoring tool will be notified and will display error markers to users. Quick-fixes may be proposed to allow users to quickly fix compilation or validation issues.

• the Synchronizer, which purpose is to synchronize the informations described in the Document with the user's development artifacts and environment. For example, if an user writes in its Document that the target platform must use CDO 4.0, and that his current target platform uses CDO 3.0, a synchronization issue will be detected. The authoring tool will be notified and will display error markers to users. Quick-fixes may be proposed to user to fix this synchronization issue (in the previous example, update the constraints declared in the Document or update the target platform).

• the Indexer, which maintains a light-weight index of the Document. It has been defined to quickly obtain a Document structure without having to load it entirely (used for example in the Eclipse's project explorer).

• the Documentation Generator (Weaver), which generates a paper 'documentation(textile, HTML, Latex, PDF...) from the Document. It can be configured to be launched automatically whenever the Document is modified, or manually.

An extensible tool

Extending existing clients

As the purpose of Intent is to make documentation writing as simple as possible, many Intent clients have the capability of being extended :

• Authoring tool
  • Extension to provide new DSL languages, that can be used inside Modeling Units to describe model fragments

• Compiler
  • Extension to provide new validation rules (for example : a bundle dependency must allays includes version numbers)
  • Extension to provide new quick-fixes faced to validation or syntax

errors

• Synchronizer
  • Extension to provide new synchronization capabilities. For example, by defining a new synchronization provider, Intent will be able to detect synchronization issues between the description of an Acceleo template (inside the documentation) and the actual template used to generate code (inside the user's workspace). This synchronizer provider may define quick-fixes for synchronization issues (for example : update the Acceleo template to match its definition inside the Document and re-launch a code generation).

Defining new clients for Intent

It is possible to easily define new clients for Intent, whether it is for providing new features needed by your customers or new ways of editing the Document. By registering your client to the Intent Repository, it will be able to react of any change made on the Document, and to therefore to communicate with the other clients.

For example, one can perfectly imagine an on-line authoring tool based on Orion or a GMF editor allowing to represent the Document as a diagram. If you have an interesting idea for a new Intent client, or specific needs that Intent does not fulfill yet, do not hesitate to contact us.

Defining your own Repository

As Intent do not rely on any technology regarding the Repository, new implementation can be easily defined.