The realisation of consistency checking is detailed in the following section. Firstly, inter
consistency checking is introduced, then the particulars of intra consistency checking are presented. As described in Chapter 4, the basic premise of the consistency checking approach is that following change detection and impact analysis, the consistency of potentially impacted entities can be analysed by applying consistency rules. The components of consistency rules, which are identified in Chaper 4, are obtained at implementation level in the following manner:
• File levelchange type (add, edit, delete) obtained from thegetFileLevelChangeTypeproperty
of theChangeDataobject
the values of types currently handled by the framework.
• Artefact element type derived from thetypeproperty of the artefact element in question. • Fine-grained artefact element type denoting hierarchical relationships between elements of a
specific artefact, which can take the value ofcontainer ormemberelement and is derived from the artefact element type. This categorisation is applicable to Java source code, UML class diagram and JUnit test artefacts due to their structural similarities.
• Existinginterandintratrace links connecting elements derived from the property values of edges connecting the given elements.
7.5.1
Inter Consistency Checking
In the following section the consistency management approach between heterogeneous artefacts is discussed. To derive inter consistency rules, three basic scenarios are considered based on the
file levelchange type. Therefore this section is divided into three subsections, which represent
the three categories offile levelchanges. In each subsection a number of scenarios, based on the artefact type, are introduced.
Delete File Level Change
Adelete file levelchange results in removing multiple artefact elements at the same time, thus at
the graph database level multiple nodes are affected.
Tables B.8, B.9 and B.10 in Appendix B show the derivation of consistency rules and that the rules are dependent on the specifics of the changed entity, the elements it is connected to, and the type of theintertrace link between them. In the current discussion,identityandsatisfaction
links are relevant. Anidentity intertrace link between two entities shows that they represent the same concept. On the other hand, asatisfactiontypeinterlink does not guarantee a one-to-one mapping between the two entities. Therefore, in case a Java class is deleted, a requirement may remain consistent. However, the same rule may not be applicable if the changed entity is a requirement, and the connected entity is a Java class.
Add File Level Change
The add file levelchange is the inverse operation of thedelete file levelchange and the same
example scenarios are applicable. In case new elements are added, no connections are in place between these and existing elements. Since consistency checking requires the existence of trace links, rules cannot be defined to cater for this scenario. However, in particular cases, which are specific to Java source code, UML class diagram and JUnit test artefacts,intraconnections may be utilised. For example a newly added class may implement an existing interface, which results
in the creation of anintralink between them.
Edit File Level Change
Edit file levelchanges result in modifications within existing artefacts and are summarised in
Table B.7 in Appendix B. Since further threeedit file levelchange scenarios exist -add, delete
and edit artefact element levelchanges -, consistency rules are derived accordingly. Firstly,
delete artefact element levelchanges are introduced in Table B.11 in Appendix B.
Establishing interrules for the add new artefact elementchange scenario in Java, JUnit and UML class diagram artefacts requires the intertrace links of the parent of the newly added artefact element. For example, when a new UML method is added to a UML interface, the elements connected to the UML interface through aninterlink may be inconsistent. As shown in Table B.12 in Appendix B, deriving rules in such a manner is applicable to artefacts which provide both member and container elements. Furthermore, in the specific case of adding a UML container element, existing intra connections do not provide sufficient information to createinter
consistency rules.
Edit artefact element levelchanges are summarised in Tables B.13 and B.14 in Appendix B. The
types of edited elements show that specific artefacts can be edited in a number of ways. For example Java member artefact elements can be changed by modifying theirsignature, such as renaming a method, or by editing thecontents, such as changing a method’s body.
7.5.2
Intra Consistency Checking
Intra rules are applicable in case ofedit artefact element level changes since in case of add
artefact element levelanddelete artefact element levelchanges,intralinks are added and deleted,
respectively. Table B.15 in Appendix B shows the intra rules applicable to Java source code, UML class diagram and JUnit test artefacts. Sinceintratrace links between requirement elements in a requirement specification, use case elements in a use case document, and lifeline elements in a sequence diagram artefact are not recorded in the current implementation of the framework,
no intrarules are applicable to these artefacts. Furthermore, despite the fact that conceptual
architecture and module view architecture artefacts are characterised by a structure in which certain elements may contain others, such as components and subcomponents, the framework presently handles these artefact elements individually.
7.5.3
Rule Implementation
Consistency checking rules are captured in a rule-base in an XML format and are parsed using the Java DOM API. XML was selected as a means of representing the different scenarios since it allows new rules to be added should the framework be extended with additional artefacts. Such flexibility provides further benefits from an implementation point of view, as adding further rules does not require the implementation to be altered. Listing 7.7 shows an excerpt of the rule-base, which represents adelete file levelchange. In this example a Java source code container artefact is removed, and the corresponding rule indicates that the connected UML sequence diagram member element is inconsistent.
<DeleteFileLevelChangeRule id="rule3"> <ChangedEntity >
<ArtefactType >JAVA_SOURCE_CODE </ArtefactType >
<FineGrainedElementType >Container </FineGrainedElementType > </ChangedEntity >
<ConnectedEntity >
<ArtefactType >SEQUENCE_DIAGRAM </ArtefactType >
<FineGrainedElementType >Member </FineGrainedElementType > </ConnectedEntity >
<InterLinkType >Identity </InterLinkType >
<StateOfConsistency >Connected entity is inconsistent.</ StateOfConsistency >
</DeleteFileLevelChangeRule >
Listing 7.7:Excerpt of XML rules capturing consistency rules.
7.5.4
Output
The results of consistency checking are captured in a ConsistencyCheckResult class, which associates a pair of changed artefact element with a potentially impacted element and an applicable consistency rule.
7.6
Change Propagation
In the current implementation of the ACM framework, change propagation is responsible for suggesting resolutions to users based on the results of consistency checking. Additionally, it is the last stage of the consistency management process, and therefore the final graph database update takes place in this stage prior to pulling new changes from the repository. Finally, users are presented with the results of consistency management, including a summary of the changes, their potential impact and consistency issues.
Similarly to consistency checking, change propagation can also be divided into two broad categories. Intra change propagation follows intra consistency checking when inconsistencies are resolved within an artefact. On the other hand, inter change propagation refers to the activity of resolving inconsistencies in heterogeneous artefacts.
7.6.1
Graph Database Update
The majority of database update operations take place in theChange detectionstage as described in Subsection 6.3.1.5. However, intertrace link maintenance, that is adding, removing and editing edges of the graph, is performed during change propagation. Moreover, nodes that have been previously labelled with thetobeRemovedannotation are removed from the database.
7.6.2
Inconsistency Resolution
The ConsistencyCheckResult object provides sufficient data to suggest resolutions to users.
It contains details about the changed artefact element, and the database nodes that may be inconsistent as a result. Based on this input, the framework differentiates two cases:
a, (Potential) inconsistencies
In this case, the framework suggests the user to apply the same change to inconsistent and potentially inconsistent elements that was previously performed on the changed artefact element.
b, No consistency issues
In this case a message is displayed to the user stating that the framework did not identify consistency issues following the specific change. However, the elements of the impact set are listed and the user can confirm these results by checking these elements either at the database or at the original artefact level.
7.6.3
Final Output of Consistency Management
The final output of the consistency management cycle is presented to the user at the end of change propagation. The output consists of a summary of the changes and (potential) inconsistencies. An ideal change propagation solution is automated as far as possible and therefore involves applying changes to inconsistent artefacts as automatically as possible. Additionally, the user should be able to configure which changes may be automatically applied and which modifications require manual input. This level of change propagation support is not within the scope of this work.