Inferred Artefacts through Forward and Reverse Engineering

An experiment was undertaken to see the extent to which existing reverse and forward engineering tools could provide the basis for both producing inferred artefacts (as defined in chapter 3) and for describing an artefact’s features. The resultant inferred artefacts were analysed to ensure that the originals’ features were being preserved and that no erroneous or extraneous features had been added.

The assessment tool provides feedback upon the student submission. In our example, the students produced their UML diagrams using ArgoUML (Tigris, 2006), an open source CASE tool. They produced their Java source code using an IDE tool; either Eclipse (Eclipse Foundation, 2006) or JBuilder (Borland, 2008). An experiment was undertaken to investigate the round trip capabilities of these tools. The aim was to investigate their suitability for producing inferred artefacts and automating their description. A small Java program (using JBuilder) and a UML class diagram (using ArgoUML) was devised for testing purposes. This test program and its associated diagram contained features that would be typical of that expected from a student submission. The diagram and program comprised of a class inheritance hierarchy based around the concept of an employee and an additional class containing a main routine that interfaced with it. The main routine implemented a container relationship through the creation of a list of employees. Both tools supported the import and export of data through the XML Metadata Interchange (XMI) protocol (Object Management Group, 2007). The experiment consisted of forward engineering the UML diagram to produce source code (Figure 4.2) and reverse engineering the source code to produce a design diagram (Figure 4.3).

Inputs Design Diagram in Argo UML

Outputs Java Source Code

Intermediate output XMi representation of the design, Design diagram in JBuilder format

Figure 4.2 Forward Engineering: from Code to Diagram

Inputs Java Source Code

Outputs Design Diagram in ArgoUML

Intermediate output Design diagram in JBuilder format, XMi representation of the design,

Figure 4.3 Reverse Engineering: from Diagram to Code

The experiment raised some issues about the utilisation of these tools to produce inferred artefacts.

Forward engineering the design diagram successfully produced skeletal code for each class contained in the original diagram. The class names, attributes, methods and their parameters (with the exception of the constructors) were preserved in the process. It also preserved the inheritance hierarchy. However, the constructors of the child classes, the container relationship and its associated cardinality data were lost and not reflected in the inferred code. Java Source Code using JBuilder Produce Diagram in JBuilder Export diagram in XMI format Import XMI file into Argo UML Diagram in ArgoUML Tool Export to XMI format Import into JBuilder Generate diagram Java Source Code in JBuilder ArgoUML Design Diagram

Reverse Engineering the source code produced a diagram that preserved the number, name, methods, parameters and attributes of the classes. It also preserved the inheritance hierarchy. However, parameters into the constructors of the child classes and the container relationship were lost and not reflected in the diagram.

Hence, both reverse and forward engineering preserved the inheritance hierarchy and the signature of each class (though note the exception of parameters in class constructors). However, both processes failed to model the interaction (i.e. a container relationship). Further experimentation traced the problem to that of scoping for dynamically created objects. The XMI was not capturing the relationships embedded in the source code when the method of one class instantiated and created an object from another class.

An examination of the literature revealed that the problem of automatically reverse engineering a program’s dynamic behaviour is a topic of ongoing research (Merdes and Dorsch 2006). This is particularly challenging for object oriented programs as the gulf between static specification and run-time behaviour is particularly wide (De Pauw et al. 1994). Features such as dynamic- binding and polymorphism pose limitations to static analysis (Lienhard et al. 2007). Hence, tools that analyse source code provide satisfactory results for static diagrams but their suitability for the dynamic behaviour of an application is limited (Merdes and Dorsch, 2006).

This was a disappointing find and problematic for developing the feedback tool. The static models produced by both reverse and forward engineering could have formed the basis upon which a semi-automated approach to generating feedback could have been developed. This would have required manually modifying the models to reflect the submission’s dynamic behaviour. This semi-

automated approach was rejected as the resultant process would be too dependent upon the format and nuances of the models produced by the round- trip tools. Additionally, the pedagogic context was that of dynamically creating and manipulating objects. Hence, the tools used by the students could not be used to describe and infer artefacts from their submission. Consideration was given to finding or developing alternative tools. This was rejected as it would restrict the choice of tools that a tutor could ask the students to use. Consideration was also given to providing the students guidance on how to produce source code that circumvented this issue. However, the tool was meant to feed back to students on what they had done. It was considered to be pedagogically inappropriate to insist on a particular way of coding to ensure that the relationships were being picked up by the round trip process.

Hence, using round-trip engineering tools to infer and describe artefacts proved to be problematic. In retrospect, it would have been possible to remove the need for a round-trip tool and automate the description of the diagram and its source code as individual, separate entities. However, the focus of the research was upon comparison aspects of the tool and the evaluation of the feedback generated. Consequently, in order to progress the research, inferred artefacts were described by hand and produced through a manual analysis of the student submission.