Consistency Checking and Change Propagation Approaches

A number of consistency checking solutions have been proposed in literature. This section briefly introduces the main concepts and groups of solutions contributing to artefact consistency management. Finkelstein discusses the technical challenges in consistency management [131], in an effort to analyse the requirements for constructing consistency management tools capable of handling heterogeneous and distributed information.

The discipline of Model Driven Engineering (MDE) aims to develop and maintain software through model transformations [132]. Using rules, a transformation translates a source artefact to a target artefact, both of which can be of different types ranging from concrete representations to more abstract models. Reviewing a taxonomy of transformations is beyond the scope of this thesis. However, it is important to mention that two specific types are directly relevant in the discussion of artefact consistency management. Firstly, synthesis turns a more abstract representation (e.g. design model) into a more concrete, lower level one (such as source code), a typical example being code generation, which can be classified as forward engineering. Secondly, reverse engineering provides an abstraction of higher-level artefacts from lower-level ones. Forward and reverse engineering together constitute round-trip engineering (RTE) [133]. Generative and transformational techniques are relevant since they implement means to handle the synchronisation (change propagation) of heterogeneous artefacts to re-establish consistency

between them following a change [134]. Synchronisations also utilise relationships between artefacts, called mappings.

Examples of code generation facilities include the Visual Studio class designer [135], which was created with the intention to keep source code and class diagrams synchronised. The IDE12 also provides the capability to generate source code from a class diagram and vice versa, where changes made to a class diagram are reflected in the source code, and alterations of the source code are also synchronised to the diagram. Additionally, the Eclipse plug-in, Objecteering [136] guarantees Java code-UML model consistency and Enterprise Architect’s template driven code generation engine [137] allows its users to perform forward engineering tasks.

Furthermore, the open source framework and code generation facility, the Eclipse Modeling Framework (EMF) [138], facilitates the generation of different representations of an application, such as source code written in Java and UML. Relatedly, the main aim of Executable UML [139] [140] is to use models of the system to directly execute the system. These models are complete enough to be executed. The Foundational UML (fUML) standard has been created to specify precise semantics for an executable subset of standard UML. Another key ingredient of Executable UML is the Action Language for Foundational UML (Alf), which provides a textual notation for UML behaviours that can be attached to a UML model and allows the specification of detailed behaviour. Executable UML allows its user to program, at a higher level of abstraction. Finally, various commercial tools provide round trip engineering functionality. Poseidon for UML [141], which can also be run integrated within Eclipse, makes it possible to maintain consistency between UML models and Java code. A major benefit of code generation solutions is their support for software development activities and enhancing developer productivity by reducing time spent on routine programming tasks. However, outside the scope of some specific application domains, such as parser generators [24], applications of the approach are limited and generating a complete functioning program that does not require human intervention remains a distant goal. Another interesting question these solutions raise is the level of detail the various design models can capture, and how accurately models can be mapped to an implementation. Although ADLs and UML also support some code generation, these solutions are not widely adopted in industry.

Some consistency checking solutions address more general consistency issues, independent from the actual domain of the models and not specific to MDE [52]. A substantial amount of work has been done in checking the consistency of both heterogeneous and specific artefacts. As an example of the first category, Nentwich et al. have developed xlinkit [142], a consistency checking service that is based on the XML, XLink and XPath technologies. The framework is implemented

as a web service and supports the management of the consistency of software specifications. This is achieved in a tolerant manner: the solution does not force the immediate resolution of inconsistencies as they are not always undesirable. The aim is to pinpoint inconsistencies so they can be handled by document owners when appropriate. Elements are connected by hyperlinks. One of the main contributions of this work is the creation of a set-based rule language, which is a restricted form of first-order logic expressing consistency constraints between distributed documents. Campbell et al. [143] provide an example of the second category of solutions. Their proposed approach checks inter-diagram structural and syntactical inconsistencies between UML diagrams of different types and detects structural problems within individual diagrams. The results of consistency checks are then presented to users who can address the issues manually. Additionally, Dimech and Balasubramaniam propose an automated approach to check conformance between Java source code and architectural models in UML [144]. The approach is implemented in an Eclipse plug-in, Card.

3.5

Evaluation

As mentioned at the beginning of this chapter, the aim of the evaluation of related approaches is to establish to what extent the issue of artefact consistency management has been addressed and to highlight which specific aspects have been in the focal point of research areas introduced in the survey.

The review of solutions and an analysis of the problem area revealed that the management of the consistency of software artefacts consists of multiple activities: a) managing changes requires mechanisms to detect modifications, b) it is essential that heterogeneous artefacts are linked and c) the impacts of any artefact being modified is assessed. Following these steps d) consistency checks can be carried and finally, e) consistency can be-re-established. The concept of this holistic view of artefact consistency management is discussed in detail in Chapter 4, however the approach is also utilised during evaluation, where these aspects allow the pinpointing of facets of the problem that have been more thoroughly investigated and automated compared to others. A major component of the evaluation is a comparison, illustrated by Table B.1, B.2, B.3 and B.4 in Appendix B, which is carried out using a subset of the reviewed solutions. The approaches selected were primarily the ones where tool support is available and ones where more than one aspect of artefact consistency management is applicable. Thus, for example traceability recovery solutions were not considered. However, a review of such solutions contributes to drawing conclusions about automation levels and artefact coverage. The comparison provides information about automation levels by analysing which aspects of artefact consistency management are

catered for. Additionally, the scope of solutions in terms of supported artefacts is highlighted, and it is also investigated if distributed development is supported. Finally, the analysis of artefact storage and link storage provide insights into implementation level specifics of the given solution. The issue of inconsistently evolving artefacts has not yet been sufficiently addressed in its entirety. The solution space for managing artefact consistency is diverse and the individual solutions approach the problem from various angles, which is a hindrance to performing a direct comparison. Notably, solutions stem from different research areas and their motivation and aims are significantly disparate: some may focus on trace link creation for a better comprehension of the system, while others may have the priority to minimise the side effects of modifications. The evaluation did not identify any solutions, which cater for all aspects of consistency management providing traceability creation and maintenance, change detection, impact analysis, consistency checking and change propagation. In most cases, a subset of these aspects is satisfied, either in an automated, semi-automatic (parts of the process can be automatic and mostly user input is required) or manual manner (the solution offers data or visualisation but the task is performed by the user).

In terms of supported artefacts, the evaluation revealed that most solutions concentrate on specific artefacts. This applies, in particular, to traceability-specific solutions and in cases where proof- of-concept tools have been developed to work with a subset of artefacts. A similar categorisation of solutions based on artefact types is discussed inSoftware Traceability: A Roadmap[35]. The automation of any aspect of artefact consistency management is a challenging problem and the reviewed solutions provide varying degrees of support for it. This problem is exacerbated when a given solution combines more than one aspect, and it is also impacted by which artefacts are catered for. It is apparent how strong of a link there is between the adoptability and success of an artefact management solution and how automated it is.

The implementation specifics analysed provide a further dimension to discovering differences between the approaches. Specifically, the results highlight that in terms of artefact representation solutions can be divided into two main categories: approaches that represent artefacts in an intermediary format, such as XML, and approaches that process artefacts in their original format.