SOFA 2.0 Editor - GUI Repository Designer for Eclipse

NEWS

2007-06-10

SOFA 2.0 repository editor v. 1.3.0 released. Changes »

2007-02-10

SOFA 2.0 repository editor v. 1.0.149 released.

2006-10-21

Work on the plug-in is started. History »

MANUALS

Compiling and installation

User's manual

Usage scenarios

Developer's manual

UML diagrams

Java docs

Author MaViNes (c)

ARTICLES

OSGI Framework

Eclipse plugin basics

RCP basics

SWT draw basics

jFace tips

SWT Linux/Windows differences

Author MaViNes (c)

Table of contents | Next >>

Chapter 1. Introduction.

This guide is aimed to user who has at least basic knowledge of the Sofa 2.0 system. The plug-in is developed as the extension for the Sofa 2 project which was developed by the students and researchers team. The plug-in supports work with repository and cushion parts of the Sofa 2 system. To get more knowledge about the Sofa 2 project reader should refer to the http://sofa.objectweb.org/

The plug-in is developed accordingly to the component model requirements. It supports creation and editing of all properties defined by the Sofa 2.0 meta-model. Also it provides 2 different kinds of creating entities in the repository. The first is direct work with repository part. The 2nd is generation of needed entities using the cushion extension of the Sofa 2.0 project. To know more about the cushion extension reader should refer to the http://sofa.objectweb.org/docs/cushion.html

Using the plug-in user can create frame and architecture entities almost in 1 click. Appropriate wizards will guide user through the process of creation needed entities. When user works directly with repository it is possible to create frame and place needed interface onto its borders. Interfaces can be of provided and required types. Then, when interfaces are placed, it is possible to edit interface properties and set needed name, version, connection-type, and also the most important - it is possible to write name, version, and signature of an interface-type which will be assigned to the interface. It is important to remember that interface-type should be set for each interface.

Then user can move to the creation of architectures. Each architecture must implement one or more frames. This is strictly defined by the meta-model. So, when creating an architecture, the appropriate wizard will ass to choose what frame should be implemented by the fresh architecture. When the frame is chosen it is possible to finish wizard and see the fresh architecture drawn on the draw area. When the architecture is created, all frames, which are implemented by it bypass their interfaces to be visible on the architecture's borders. Now user can create subcomponents inside the architecture. There is a wizard which helps to create needed subcomponent properly. If subcomponent is instantiated by frame which already has interfaces than all of those interfaces are visible on borders of the subcomponent. The same is valid if the subcomponent is instantiated by an architecture, which has interfaces, received from implemented frames.

When there are subcomponents with interfaces inside architecture, it is possible to draw links between interfaces. The current meta-model allows almost any linking between interfaces.

When working with the cushion extension of the Sofa 2.0 system, it is possible to generate needed architectures, frames, interface types using appropriate cushion commands. When a frame is generated, it is possible to edit it and add interfaces to its borders. And then all interfaces should have appropriate interface types defined. In this case all needed interface types must be generated before any interface is created. So, the entities generation sequence looks like this: firstly user should generate some interface types, then several frames and then several architectures. Then it is possible to add interfaces to frames and assign previously generated interface types to interfaces. And then it is possible to point which architecture implements which frame. Also it is possible to add subcomponents to an architecture. Then all changes should be saved and committed to the running working server. In fact, when an entity is generated using cushion, a trace of this entity is shown in the repository and is visible via the direct repository editor of the plug-in. But it is not recommended to change this trace. It is not completed locally, so when changes are done directly on the repository server, then synchronization will be lost and it will be required to checkout changed entity to the local cushion project.



Table of contents | Next >>

Learn More