Although it is not a separate framework stage, traceability maintenance is integral to a successful consistency management process and is closely related to change detection and subsequent stages. Therefore it is discussed following an examination of change detection and prior to introducing the change impact analysis approach. Traceability maintenance encompasses the functionality to update inter trace links in the graph database following the detection of a modification and the identification of the changed entities and their corresponding change types. During change detection, the graph database is updated to reflect the latest state of artefacts, i.e. depending on the modification(s), new nodes may be added, and existing ones may be deleted or edited. Trace links may also be affected by the modification in question, such that new links are added or existing links are deleted.
The consequences of changes to inter trace links can be captured by formulating trace maintenance rules, which are described in Chapter 7. The rules depend on the specifics of the change provided byChange Data, and in summary, can be formulated based on the following: a) File level change type,
In case ofeditfile level changes: b) Artefact element level change type,
d) Artefact element type from which the fine-grained artefact element type can be established (child or parent element, discussed in Chapter 6).
4.5.3
Change Impact Analysis
Succeeding the modification of an artefact element, the aim of the change impact analysis of heterogeneous software artefacts in the ACM framework is to determine further elements possibly affected by the same modification. Input to this process is provided byChange Data. The output of change impact analysis is therefore the set of elements deemed to be affected by the modification. As mentioned in Chapter 2, change impact analysis can be performed utilising various approaches, such as structure-based, history-based and probabilistic methods. Following is a discussion of the approach presented in this work.
Impact Analysis as Property Graph Traversals
The impact analysis strategy of the ACM framework utilises the property graph representation of heterogeneous artefact entities and specifics of the change obtained through change detection. Therefore it falls in the category ofstructure-based impact analysis solutions, which it extends to cater for multiple artefact types. Traversing the artefact graph allows the identification of connected entities at the specified level. The approach stems from the assumption that nodes connected to a modified node may also be impacted by the same modification, depending on the link connecting them. The traversal can be described as abreadth-first searchand the approach currently caters for direct connections. Similarly to nodes, edges of the graph can also be described with a type property, which is a significant factor in traversals. Each node is connected to the start node through a specific link type expressed by the values of the type property, which define the scope of traversals.
The flow chart in Figure 4.5 describes the algorithm for traversals ofinterlinks. The input of traversals isChange Data, which makes it possible to identify the modified node, which is the starting point of the traversal, and to express specifics of the change type, which determines the subsequent steps. In case the start node was edited or deleted, it is possible to identify nodes connected to it, which are then added to the set of potentially impacted nodes, i.e. the output of impact analysis. In case the node was newly added to the graph, further details are required and in certain cases there is no straight forward way of identifying connected elements. In case the newly added node represents a class, the impact analysis algorithm cannot determine which other nodes may be connected. Exceptions are Java source code and JUnit artefacts, in cases where they connect to other classes or interfaces. However, if a member element is added, it is already connected to a class through anintralink, hence it is possible to visit the node representing the
container class. If the container class is connected to other nodes throughinterlinks, those nodes are traversed and added to the set of potentially impacted nodes. In summary, the algorithm is based on the change type and the types of elements. Traversals are based on link types. These are the three factors constituting change impact analysis using the property graph.
4.5.4
Consistency Checking
An essential component of artefact consistency management is the functionality to establish whether an element affected by a modification remains consistent, and hence need not be changed, or as a result of the modification, it has become inconsistent. The identification of inconsistencies falls under the responsibility of consistency checking in the ACM framework.
Listing 1 shows the overview of the consistency checking approach, which is based on the interplay of the outputs of previous framework stages supplying data about the specifics of the change and its potential impact, and consistency rules. Change Data, provides details of the modification(s) through which the changed entity can be located in the graph database. Additionally, properties captured in Change Data also play a crucial role in formulating consistency checking rules. Specifically, the change type property separates three cases from each other; add, edit and delete scenarios are processed differently.
Algorithm 1Consistency Checking Approach Overview.
1: input: ChangeData, Impact set
2: output: Artefact element is consistent, Artefact element is inconsistent, Artefact element is potentially inconsistent
3: begin
4: Evaluate the change type property value of the ChangeData object
5: if change type = add, no consistency rules can be derived
6: if change type = delete, evaluate changed and connected entity, and apply corresponding
7: consistency rule
8: if change type = edit, evaluate changed and connected entity, and the artefact element
9: level change type, and apply corresponding consistency rule
10: Create ConsistencyResult
11: end
Consistency Rules
Consistency rules take the form of if-then rules and are created based on the following information:
• Artefact level change type (add, edit, delete) • Artefact type
• Artefact element type, which also denotes hierarchical relationships between elements found within a specific artefact; certain elements contain others, or some elements are contained within others
• Fine-grained artefact element type derived from Artefact element type • Existing Inter and Intra trace links connecting elements
Specific examples of these aspects are given in Chapter 6.
Consistency checking is divided into two main categories. Inter consistency checkingtakes place between artefacts of different types, while intra consistency checking is performed between elements of the same artefact.
Finally, consistency rules represent three outcomes of consistency checking. An element connected to a modified element can be either consistent, inconsistent or potentially inconsistent. By flagging up potential inconsistencies, the framework applies a pessimistic approach to consistent checking, that is, if there is a chance of inconsistency, it is reported to the user who can decide about the course of action to take.
4.5.5
Change Propagation
Change Propagation is aimed at assisting users with re-establishing consistency by suggesting possible resolutions based on the output of consistency checking. Since the input includes information about the change and changed element, the potentially affected elements and their state of consistency, change propagation can provide users with further information on how to resolve inconsistencies. For example, in case a UML class is inconsistent as a result of editing a requirement in a requirement specification, the framework may suggest to edit the UML class. In case the outcome of consistency checking is that no consistency violations have been detected, the users are given a summary about the change and the results of consistency management. In case there is a (potential) inconsistency, users are given suggestions on possible resolutions. The framework provides a summary of the change and the (potentially) inconsistent elements.
4.6
Conclusions
The problem of artefact consistency management may be more effectively tackled using a comprehensive framework incorporatingtraceability creation and maintenance, change detection,
change impact analysis, consistency checking and change propagation techniques. This
at fulfilling the high-level requirements discussed in 4.2. This chapter introduced the framework and its underlying stages, and provided an overview of data representation and the approaches taken in each framework stage. In the following chapter design decisions pertaining to the framework architecture, artefact and trace link data representation are described.
5
CHAPTER
FIVE
ARCHITECTURE AND
DESIGN
The proposed holistic approach to artefact consistency management is realised in the design and implementation of a proof-of-concept system, theArtefactConsistencyManagement (ACM) framework. Following the formulation of the characteristics of an ideal consistency management solution, the first step towards the realisation of the holistic framework is the translation of high-level requirements to an overall architecture of the framework. This chapter presents the design strategy, the framework architecture and decisions made during the design process.
5.1
Design Strategy
The design process started by specifying and analysing the following: 1. the functional requirements of the system,
2. design constraints, and 3. quality attributes.
The framework design, due to the nature of this work, adopted a lightweight version ofAttribute
Driven Design (ADD), an approach for deriving software architectures characterised by a design
process based on software quality attributes [161].