Structuring Level: Category sets

Some traits and elements could be at particular times considered as unneces- sary information when analyzing a model of component-based application. For example, software architects are interested in other information than programmers. By using all information contained in both layers of an ENT- based model there could also be a danger of confusion when representing big and complex applications.

After representing a component-based application according to the Appli- cation level, the ENT classifier allows us to organize the model information using so called category sets. These sets are defined by selector operators on the trait classification which say how to group and filter traits.

Definition The category set over an ENT model is a pair Catset = (name, {(c, K, f )}) where name, c ∈ Identifiers are the names of the cat- egory set and its categories, and f = K × Tdef → boolean is a function which determines whether the given trait definition fits the (partial) classi- fier K.

For example, the E-N-T category set defined in Figure 5.10 has three groups. In the first group are elements that are contained in traits with role = {provided} in their classifier (this means those elements which the compo- nent exports). Required elements are similarly grouped as needs and ele- ments that are both provided and required are called ties. This category set gave the name to the ENT meta-model, as it captures the most fundamental split of any component’s interface element set.

Figure 5.10: The ENT category set E-N-T (Exports-Needs-Ties)

E : K = {(role = {provided})}, f = matches N : K = {(role = {required})}, f = matches

T : K = {(role = {provided, required})}, f = matches

More category sets are presented in [3], and category sets can be created by any user of the ENT meta-model if another point of view is needed.

Advanced Interactive

Visualization Approach

In this chapter a new visualization approach (Advanced Interactive Visual- ization Approach – AIVA) will be proposed. AIVA provides an alternative to the UML component diagrams – it is able to visualize the structure of any component-based application. It is driven by the aims defined in the Introduction Section 1.2 which were all addressed. These aims were: Visualize the structure of any component-based application as a graph diagram – because it is common practice in visualization of structure thus users are used to it. AIVA honors this aim.

Visualize a sufficient amount of detail – because details are needed to get the whole picture. AIVA uses the ENT meta-model as a data layer. The ENT is able to describe any component and any structure in much detail. A visualization using it can benefit from its advantages, which were mentioned earlier. Moreover, the ENT meta-model provides well structured and categorized information.

Provide ways to filter these details and work on different levels of detail interactively – because otherwise it is necessary to create multiple diagrams for the same structure, differing only in the number of details. These different diagrams or more precisely views should rather be provided “on the fly” driven by the needs of the user. The visualization should not be forced to always show all the information, but modify the provided infor- mation as the requirements changes. AIVA uses the ENT meta-model and interactive techniques to address this aim.

Maximize the advantages of interaction to boost the learning pro- cess – because it should help to understand the application faster and more easily. It should be able to help in any situation where it is important to

keep the scope of the application under control, while having at the same time, access to the details. These requirements are met in AIVA thanks to focus on human-computer interaction and by maximizing the advantages of several interactive techniques. Such visualization is not supposed to be used on the paper, however it can offer much better experience on computer. The content of this chapter covers research challenges, that drove the devel- opment of this approach; brief description of the approach itself, to empha- size how to solve the challenge; and lastly a thorough description of concrete solution.

6.1

Research Challenge

This section will summarize and discuss more deeply research challenges

that were solved as a part of this thesis. These are the problems that

we had to face before we even formulated the aims. The Introduction just shortly outlined them and some were already discussed in more depth. These research challenges were:

1. Diagrams are more complex then other known software structures. 2. Component details make diagrams even more complex than class dia-

grams are. It is thus because components may have much more types of elements.

3. Component-based software engineering is very complicated - there are dozens of component models and it is very hard to visualize them in a general way.

4. Developer roles have very different requirements on information con- tent.

We already discussed challenges with different developer roles sufficiently in Section 4.1. The research challenge in that section is in how to provide different types of information for these different development roles. However other challenges are still just vaguely defined – thus they will be defined in following subsections.