SOFA 2.0 repository editor v. 1.3.0 released. Changes »
SOFA 2.0 repository editor v. 1.0.149 released.
Work on the plug-in is started. History »
“ User's manual ”
“ Usage scenarios ”
“ UML diagrams ”
“ Java docs ”
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.