Static and dynamic views of the software usually share common information. For example, they both typically include information about software artifacts and their relations. The overlapping information forms a channel for information exchange among the views. Examples of such infor- mation exchange are presented in this section. The methods used in this section are described in Sections 8.7, 8.8, and 8.9.
9.4.1 Merging dynamic information into a static view
In Shimba, run-time information can be attached to a Rigi dependency graph. During the execution of the target system, weight values are given to access, assign, and call arcs in Rigi. The weight values indicate how many times these relationships have been used during the execution. Further- more, Exception nodes and throw arcs are added according to their run-time usage. Figure 9.17 shows a Rigi graph to which run-time information has been added. To generate the dynamic infor- mation, breakpoints were set for all methods of the de.uni paderborn.fujaba. app.FujabaApp and
de.uni paderborn.fujaba.uml.UMLParam classes. In addition, exception java.util.MissingResourceException
was selected. FUJABA was used in the following way:
1. FUJABA was started, 2. a project was opened,
3. one parameter of a method of a class was removed, 4. the project was saved, and
5. FUJABA was exited.
In the Rigi view in Figure 9.17 a small dialog has been opened to show the attribute values of a throw arc entering the java.util.MissingResourceException node. The weight value of the arc indicates that the corresponding exception was thrown 221 times. The type of the exception and the large number of times it was thrown refers to an installation problem.
9.4.2 Slicing a Rigi view using SCED scenarios
The source of a known bug was traced in Section 9.3.5. To examine the structure of the parts of FUJABA that might contain the source of the bug, the initial Rigi graph in Figure 9.1, rep- resenting the whole FUJABA software, was sliced by a set of scenario diagrams that were gen- erated after the dialog in Figure 9.14 was opened. There are altogether 29 such scenarios. The Rigi graph in Figure 9.18 results from applying Algorithm 4 to the initial Rigi graph. The node
Figure 9.17: A corner of a Rigi view containing both static and dynamic information. The user has selected a throw arc from node java.util.Resource.getObject(String,Object) to node
java.util.MissingResourceException (the right most arc) and opened a dialog that shows the at-
tribute values of that arc. The opened dialog shows that java.util.MissingResourceException has been thrown 221 times at run-time (the weight value of the selected arc).
modifyButton actionPerformed(jawa.awt.event.ActionEvent) can be seen in the bottom left cor-
ner of the graph. The nodes, names of which have not been hidden, represent methods that can be called from it directly or indirectly. Such a chain of method calls, representing reachability of those methods from the modifyButton actionPerformed(java.awt.event.ActionEvent) method, can be easily found by running a simple script that makes a forward reachability query. The de- fault constructor of class UMLMethod belongs to this chain. This supports the conclusions of Section 9.3.5. By examining the scenarios we observed that when the modify button is pressed, a new method is created. We assumed that the new method is replaced with the old one. By running another script the node addToParam(UMLParam) can be found. It is placed in the bot- tom right corner of the graph. It is worth noting that it does not belong to the found chain of nodes. From this it can be concluded that the addToParam(UMLParam) method of class UML-
Method was not called (i.e., no parameters were added for methods) after the modify button was
pressed. Moreover, addToParam(UMLParam) method of class UMLMethod cannot be called in any circumstances from the method modifyButton actionPerformed(java.awt.event.ActionEvent) with the current implementation.
9.4.3 Raising the level of abstraction of SCED scenario diagrams using a high-level Rigi graph
An example of modifying SCED scenarios using the approach described in Section 8.9 is discussed
next. In FUJABA, classes that represent UML concepts belong to the package de.uni paderborn.fujaba.uml. The editors and dialogs used for defining and editing these concepts are defined in the pack-
age de.uni paderborn.fujaba.gui. For example, the dialog in Figure 9.14 is implemented as class
de.uni paderborn.fujaba.gui.PEMethod, and it is used for defining and editing methods that are
represented as instances of class de.uni paderborn.fujaba.uml.UMLMethod. Altogether 24 editor classes have the superclass de.uni paderborn.fujaba.gui.PropertyEditor, from which the individ- ual editors are derived. Figure 9.19 shows the class hierarchy of the editors. Similarly the class
de.uni paderborn. fujaba.uml.UMLIncrement is a super class for 46 classes that represent different
Figure 9.18: The graph resulting when the initial Rigi graph for FUJABA software in Figure 9.1 has been sliced by a set of scenarios
Figure 9.19: A Rigi view showing the class de.uni paderborn.gui.PropertyEditor and all its sub- classes
For capturing high-level information about the Model-View structure of the FUJABA class dia- gram editor static abstractions were made. First, class de.uni paderborn.gui.PropertyEditor and all its subclasses were collapsed into a single de.uni paderborn.gui.PropertyEditor2 node. Sec- ond, class de.uni paderborn.uml.UMLIncrement and all its subclasses were collapsed into a single
de.uni paderborn.uml.UMLIncrement2 node. Third, all classes that implement the java.awt.event.ActionListener
interface were collapsed into a single java.awt.event. ActionListener2 node. There were altogether 92 such classes. Those classes represent GUI items that are able to receive action events (e.g., user inputs). Hence, they represent the system border. Fourth, class de.uni paderborn.gui.PESelection and all its subclasses were collapsed into a single de.uni paderborn.gui.PESelection2 node. There are only six such subclasses. Class de.uni paderborn.gui.PESelection is used for providing the user a list to which she can add items using the add button and remove items using the remove button.
A set of SCED scenario diagrams were generated when reverse engineering the dynamic inter- action between model and view components of the FUJABA class diagram editor. Breakpoints were set for all methods of the following classes: UMLMethod, UMLParam, UMLClass, UM-
LAttr, PEMethod, PEParameter, PEClass, and PEVariable. The first four classes belong to the de.uni paderborn.fujaba.uml package, and the rest of them belong to the de.uni paderborn.fujaba.gui
package.
The usage included adding and editing methods, variables, and parameters. In addition, a new class was added to the class diagram. After applying the method of raising the level of abstrac- tion of SCED scenario diagrams using a high-level Rigi graph the number of scenarios was de- creased from 26 to 7 and the number of scenario items was decreased from 2038 to 513. Fig- ure 9.20 shows a corner of one of the resulting scenarios. The scenario shows a usage in which the parameter button of the dialog in Figure 9.14 (the dialog for editing methods) was pressed. That caused the dialog in Figure 9.2 (the dialog for editing parameters) to be opened. Using that dialog a new parameter was added to the method, and finally, the parameter was modified. The usage is clearly recognizable from the scenario. Furthermore, participants representing the
system border (javax.swing.AbstractButton and java.awt.event.ActionListener2), the view com- ponents (de.uni paderborn.gui.PropertyEditor2 and de.uni paderborn.gui.PESelection2), and the model components (de.uni paderborn.uml.UMLIncrement2) can be easily distinguished. Note, that the system border always communicates with the model components through the view com- ponents. The high-level scenario thus clarifies the user interaction as well as the communication between the view and the corresponding model components.
Figure 9.20: A high-level SCED scenario diagram showing the interaction between high-level static components that have been composed using Rigi.