The visual representation of a single component is described here. The
header of a component has two lines: the type of component is enclosed by guillemets on the first line and the name of the component is present on the second line. This was inspired by the UML notation. The header is the only things that does not change; the body of the component can be altered as the user needs. Basically there are two ways that change the body of each component – 1) which elements should be visualized (see Section 6.4 for filtering); 2) and how to visualize them (styles of representation).
Figure 6.1: OSGi component called “Gate” in all representation styles used by AIVA.
Figure 6.1 contains one OSGi component called “Gate” represented using various styles. All these styles are implemented by AIVA and are supposed to offer different experience based on user’s preferences. All these represen-
tations use similar grouping mechanism – Category Sets (see Section 5.3.5). Every element is grouped based on its type, which is also applied by UML. However AIVA uses yet another level of grouping based on shared character- istics of these types of elements. For example: cz.zcu.kiv.parkinglot.IArrivedDe- parturedis a provided service, thus it is in groupprovided_service. All provided
services and exported packages are exported/provided by component “Gate” thus they are grouped under Exportsmain group.
A single element is displayed in the classical way as nameOfElement: type. If it does not have any type defined (and also when the type is not important or is always the same), it is displayed only as nameOfElement. Types of elements are used, e.g., with CORBA components (e.g. Figure 6.2), unlike for OSGi, where elements are the names of interfaces, classes and packages (e.g. Figure 6.1).
Figure 6.2: How would AIVA represent a CORBA component. Tree representation is quite different from the UML. It presents the above described grouping in a tree structure, which is the most logical way how to present this type of information. This representation shows all groups, even the empty ones. The advantage of this representation is, that hierarchy is apparent on the first look. The disadvantage is that elements coincide with group names.
Please note that every representation style presents components from differ- ent component models in the same manner, compare CORBA component in Figure 6.2 with OSGi component in Figure 6.1(a). Both components are represented in the same way so it is easy to read components from any component model.
Grouped representation is the most similar to the UML one. It contains similar element listings like UML does, however it indicates their main group
on the left edge of component. This representation ignores all empty groups and does not bother user with their presence. The advantage is in clear distinction of element, type group and main group. This representation is not so oriented on hierarchy, which may be seen as a disadvantage.
Bookmark representation is the most innovative one. It is inspired by Telea’s [66] component browser. It uses bookmarks on the top part of the compo- nents to show only its subgroups. Elements are listed in the bottom part of component rectangle only when their parent group is selected. This rep- resentation shows all groups, even the empty ones. This representation is the most compact and is the best readable as it only shows the selected information. It should be used for applications composed from very com- plex components where it will show only the requested information. On the other hand it is quite useless for visualization of small components, where one wishes to see the whole inner structure all at once.
6.3.1 Interactive Features of Component Notation
Figure 6.3: Two info boxes used interactively
The ENT meta-model is able to hold more information than the names and types of components and elements. These additional information can say more about concrete component or element, for example: vendor of component, version range, filter of service or else. Such information can be easily accessed directly in the diagram.
To get more details about component, one has to simply click on the header of the component. An info box will immediately appear showing all informa- tion available for this component. A duplicate information about component name and type is also included, however it is extremely useful when the di- agram is zoomed out and the header of component is otherwise unreadable. Component info box is in the top of Figure 6.3 and additionally it shows the list of all “Tags” (see Section 5.3) used by this component. All tags are listed in following syntax: tagName=tagValue. Unused tags are not visible
as they lack meaning.
The info box providing more information about single element is accessed by simple hovering with mouse cursor over the element. This info box is shown in the bottom of Figure 6.3 and it only shows the list of all “Tags” used by this element. The name of element is not required in this case, because elements are accessible only when they are readable. This info box uses identical syntax for listing tags as component info box does; unused tags are not listed.