7.4 Supported Component Models
7.4.3 SOFA 2
SOFA 2 loader is able to work with two different types of sources – 1) remote SOFA repository and 2) local project directory. In both cases all information required by loader are stored in special SOFA definition files called ADL, with structure based on type of source. SOFA is a hierarchical component model thus components can be created from other components. SOFA rec- ognizes several types of building blocks and “Assembly” is the top entity. A simple assembly is in Listing 7.8. It uses another entity “Architecture” as a building blocks, architecture stands for basic component in SOFA. Every assembly defines a top level architecture and the list of subcomponents. The top level architecture defines how does the whole application look, in other words it is the main component.
Architecture is composed of the implementation and definition part. Defini- tion part is called “Frame” and it is the lowest level entity. Implementation is just a class that implements what was defined in frame. Any architec- ture can have a list of subcomponents. Frames define which interfaces are provided and required and which communication style is used. This struc- ture is valid for both types of source, however the remote repository is more oriented on versioning which is already a part of all ADL files.
Listing 7.8: Assembly entity defined by local ADL file
<?xml v e r s i o n=” 1 . 0 ” e n c o d i n g=”UTF−8”?>
<a s s e m b l y name=” o r g . o b j e c t w e b . d s r g . s o f a . e x a m p l e s . logdemo . assm . ←- LogDemo” top−level−a r c h=” s o f a t y p e : / / o r g . o b j e c t w e b . d s r g . s o f a . ←-
e x a m p l e s . logdemo . a r c h . LogDemo”> <s u b c o m p o n e n t name=” l o g g e r ” a r c h=” s o f a t y p e : / / o r g . o b j e c t w e b . d s r g . ←- s o f a . e x a m p l e s . logdemo . a r c h . L o g g e r ” /> <s u b c o m p o n e n t name=” t e s t e r ” a r c h=” s o f a t y p e : / / o r g . o b j e c t w e b . d s r g . ←- s o f a . e x a m p l e s . logdemo . a r c h . T e s t e r ” /> </assembly>
SOFA might have a complex structure, however the loader is quite straight- forward as it needs only to analyze a list of XML files. The user can select between two modes – first can load application from a repository and second will work with local files. The format of XML file varies based on the type of source. Loader uses SOFA libraries to connect to the remote repository and “Cushion” tool for local project directory searches. It uses one assem- bly as an input for the whole analysis, because assembly defines the whole application. Loader then creates the tree of dependencies and prepare all ADL files for future analysis.
At the end SOFA loader has to find all relations between all components. It recognize two types of relations – 1) hierarchical, which are already known and 2) non-hierarchical, which has to be analyzed. Non-hierarchical relations can be created only between components on the same level of hierarchy in the scope of subcomponents. When all these relations are discovered the analysis process ends.
AIVA - The Implementation
The concept of AIVA was introduced in Chapter 6. Here we will provide some implementation details, that are relevant to its design and architecture, but the description will not go as low as an algorithmic level of details. Some techniques were already suggested in Chapter 6. These techniques require user-defined data, however the design of how are these data created was not discussed. These information are also part of this chapter.AIVA was implemented as a plug-in for the ComAV platform. It implements all features described earlier in Chapter 6 and can make advantage of features that are offered by the ComAV as mentioned in Chapter 7. Therefore this implementation does not have to develop its own user interface, create its own loaders of component-based applications or worry about mechanisms used to save or load user data. All of this is accomplished by design, as was mentioned earlier, so AIVA implementation is just one of visualization approaches that will use advantages of ComAV.
8.1
Visual Editors
This Section will describe visual editors that had to be designed so users might make use of several AIVA features. These features are namely Cat- egory Sets, described in Section 6.4, and conditional rules, described in Section 6.8. These visual editors are used to create user-defined data, that are used to personalize the view provided by AIVA.