1. The problem

This project is concerned with the problem of detecting and managing overlaps and inconsistencies between partial software artefacts, constructed in the course of developing large software systems. The effective detection and management of these forms of interference is a requisite for ensuring the timeliness and reducing the cost of the software development process.

The distribution of responsibilities and roles among autonomous agents (e.g., customers, analysts, designers, developers) in the development of complex software systems results in the construction of many partial descriptions of these systems (or software artefacts), including requirement specifications, system designs and implementation components. These artefacts reflect the perspectives and goals of the agents involved in their construction. Differences between these perspectives and conflicts between the goals of the agents tend to manifest themselves as inconsistencies between the artefacts. Inconsistencies occur between artefacts, which overlap, that is they refer to common aspects of the system under development, and make assertions about these aspects, which are not jointly satisfiable. Overlaps and inconsistencies constitute two separate levels of interference in software development.

The traditional approach in software engineering is to try to avoid or eliminate interference as early as possible in the software development life cycle. This approach fails to recognise that interference is inevitable in system development and potentially useful since it may highlight conflicts between the agents and indicate aspects of systems that deserve further analysis. Furthermore, tolerating interference provides scope for innovative thinking, deferment of commitments, and exploration of alternatives. Clearly, there is a need to strike a balance between the preservation of multiple perspectives and the demands for consistency and coherence in group work during system development. In our view, the only way to achieve this is to "manage" rather than eradicate interference.

Managing interference involves the activities listed below. Each of these activities presents researchers and practitioners with challenging technical questions:

• Identification of overlaps and inconsistencies – How can we identify overlaps and detect inconsistencies between artefacts that might describe the system at different levels of abstraction, granularity and formality, and deploy different terms?
• Diagnosis of overlaps and inconsistencies – How can we provide diagnostic feedback on detected overlaps and inconsistencies highlighting the reasoning process underlying their detection, the importance of the premises involved, and the confidence of the conclusions drawn?
• Settlement of inconsistencies – How can we resolve an inconsistency or settle it in a way that reduces the underlying conflict and measure the progress made in this respect?
• Tracking and rationalisation – What sort of information do we need to preserve about the overlaps, the inconsistencies and the decisions made in their settlement? How this information should be represented to make sure that those who use the artefacts at different stages of a project and may not be those involved in the detection and settlement activities will be able to understand the decisions made? How this information should be collected without increasing substantially the cost of the development process?

2. The approach: The "Reconciliation" method

Reconciliation is a semi-automated method that we have been developing over the last few years in order to address the problems of managing interference between software artefacts modelled using object-oriented analysis and design languages. Our attention has been drawn to this class of languages because they provide limited or no support for the expression of formal semantics and thus they complicate further the activities of detecting overlaps and inconsistencies. In its current state of development, Reconciliation supports the identification of overlaps, and the detection and settlement of certain forms of inconsistencies (i.e. modelling discrepancies) between software specification and design artefacts.
 

3. Aims and objectives

Reconciliation detects of overlaps and inconsistencies between artefacts which describe the static structure of software systems, and suggests possible resolutions for these inconsistencies. To provide comprehensive support for interference management across the software development life cycle the method has to address the activities of diagnosis, tracking and rationalisation, and become applicable to artefacts that express behaviour. Developing the method further in this direction is the general aim of this project. This aim breaks down into the following objectives:

Objective 1: To extend Reconciliation for managing interference between software artefacts which express behaviour. This requires the selection of a single modelling framework, which allows the specification of artefacts that express both static and dynamic aspects of software systems and is compliant with the representation framework assumed by the similarity analysis mechanism of the method. To this end, our objective is to extend the method for the Unified Modelling Language, an analysis, modelling and design language that has these properties.

Objective 2: To extend the process model of Reconciliation to support the recording of arguments justifying the decisions made though the application of the method.

Objective 3: To develop a mechanism that will guide the agents about how to apply the method based on its process model, and trace what actually happens during the process for future reference.

Objective 4: To develop an overlap and inconsistency diagnosis mechanism that will highlight the reasoning process of similarity analysis underlying the detection of the overlaps and inconsistencies. This mechanism will provide indications of the confidence of the method in the detected overlaps and the significance of the detected inconsistencies.

Objective 5: To deliver a prototype for the method that will be available on an industrial software development platform supporting UML, and evaluate the method in at least one industrial case study.
 

4. Main research outcomes and methodology
 

Very early in the project we carried out a survey of the research that had been conducted to address the problem of managing inconsistencies in software models. The survey was conducted to identify the most recent developments in the field and re-assess in the light of the findings the viability of the project objectives and the methodology outlined in the project proposal. This was deemed necessary due to the elapse of a period of 11 months between the submission of the proposal of the project and the actual start of it.

The survey covered not only the work assuming object-oriented software modelling languages and frameworks but also strands of work assuming other sorts of modelling languages and frameworks, including:

• formal specification languages (e.g. first-order logic, Z, LOTOS, KAOS)
• structured requirement specification templates (e.g. the modelling frameworks of Win-Win, VORD and DealScribe)
• state transition diagrams and state-based languages (e.g. SCR specifications), and
• conceptual graphs.

The findings of this survey re-confirmed that,

• the development of advanced algorithms for the detection of overlapping elements in independently developed software models,
• the provision of process guidance in detecting and handling different types of inconsistencies, and
• the diagnosis of the significance of inconsistencies as a means of deciding when and with what degree of priority to handle them

In the light of these findings, our work concentrated on the following four major tasks:

the development of algorithms for detecting overlaps in object-oriented models of system behaviour

the development of a framework for diagnosing the significance of detected inconsistencies in order to inform decisions about the handling of these inconsistencies

the development of an engine to enact the process models of the method and thereby offer (a) guidance to software developers in applying it and, (b) a mechanism  for keeping track of all the decisions made in this application

the development of a prototype to implement the main features of the method and enable the evaluation of it

The main results of the work in each of the above tasks are described in the rest of this section.

4.1 Overlap detection algorithm

An algorithm was developed to detect overlaps between models of object interactions expressed as UML sequence and/or collaboration diagrams. This algorithm formulates the detection of overlaps as an instance of the weighted bipartite graph matching problem. In this formulation, the messages of two interaction diagrams become the nodes of two disjoint parts of a single graph G (hence G is a bipartite graph), and are connected by edges which represent the assumption of an existence of an overlap relation between the connected messages. Each of the edges has a weight which is computed as belief in the falsity of the overlap relation represented by the edge.

The detection of the overlaps between the messages of the two interaction models is subsequently computed by selecting a subset S of the edges of G that has two properties: (a) it constitutes a morphism between the messages of the original object interaction models, and (b) it minimises the sum of the beliefs/weights of the edges in it. As proved in (Spanoudakis, 2000), the sum of the beliefs of the edges of the selected morphism S is an upper bound of the belief in the proposition that at least one of the overlap relations represented by the edges in S is wrong. The morphism S is selected by using the Hungarian algorithm.

The belief in the non existence of the overlap relation represented by an edge of G is computed on the basis of six independent counter-indicators of overlap relations between messages. These indicators are: (1) the indicator of non equivalent functional roles of the operations invoked by the messages, (2) the indicator of different message stereotypes, (3) the indicator of different message senders, (4) the indicator of different message receivers, (5) the indicator of different message activators, and (6) the indicator of different message activations (these are the closures of the operations invoked by the messages). Each of these indicators gives rise to a distinct belief in the absence of an overlap relation between two messages. These indicator-specific beliefs are computed by separate belief functions defined for each of the indicators. These belief functions satisfy the axiomatic foundation of Dempster-Shafer basic probability assignments and the axiomatic foundation of distance metrics. As a consequence, they are legitimately interpreted as distance belief functions, and some intuitive properties among their outputs (e.g. symmetry, triangularity) are guaranteed. The overall belief associated with an edge of G is computed by combining the indicator-specific beliefs computed for the edge using the rule of the orthogonal sum of the Dempster-Shafer theory of evidence.

A detailed description of the algorithm including the formalisation of the distance belief functions used by it and examples of its application can be found in (Spanoudakis 2000). The way in which overlaps detected by this algorithm are used in the context of the Reconciliation method is described in (Spanoudakis & Kim 2001, Spanoudakis & Kim 2003).

4.2 Framework for diagnosing the significance of inconsistencies

A framework was developed to support the diagnosis of the significance of inconsistencies based on the impact that these inconsistencies may have to different parts of software models. This impact is assessed on the basis of particular characteristics that the elements of the models that have given rise to the inconsistency may have. These characteristics, if present, propagate the effects of the inconsistency from the elements that have them to other parts of the models.

The diagnostic framework establishes characteristics which can propagate the effects of an inconsistency for all the main different kinds of elements of UML software models, including classes, association ends, operations and messages. These characteristics are the genericity and coordination capacity of classes, the functional essentiality of association ends, the charactericity of operations, and the functional dominance and coordinating capacity of messages.

The framework leaves it up to software engineers to decide which of these characteristics should be taken into account in the assessment of the significance of inconsistencies which arise as violations of specific consistency rules. To express such decisions, software engineers can specify significance criteria using a formal language, called "S-expressions". This language was also developed as part of the framework and was derived from the Object Constraint Language (OCL). The significance criteria determine the characteristic (or logical combination of characteristics) that should be taken into account in assessing the significance of inconsistencies which arise as violations of specific consistency rules.

The reasoning about the satisfaction of a significance criterion by the elements of the models that have given rise to an inconsistency is approximate, that is the framework incorporates a reasoning mechanism that calculates a belief in the satisfaction of the criterion. This belief is calculated from beliefs in the assumption that the elements involved in an inconsistency have the particular characteristics required by the criterion and thus they satisfy it. The latter beliefs are computed by functions defined and associated with the individual characteristics within the framework. These functions satisfy the axiomatic foundation of Dempster?Shafer basic probability assignments and therefore, they are legitimately interpreted as such. The beliefs computed for the satisfaction of the significance criteria are used to rank and prioritise the inconsistencies detected as violations of the rules associated with these criteria.

The reason for advocating an approximate reasoning approach in the diagnosis framework is the need to assess whether a model element has a characteristic at different stages in the evolutionary life of a software model during which the model cannot be guaranteed to provide an accurate description of the system under development and its domain.

A description of the framework at an early stage of its development is presented in (Spanoudakis & Kim 2000, Spanoudakis & Kasis 200). A full account of the framework, its formalisation, and results from a set of experiments conducted to evaluate it are presented in (Spanoudakis & Kim 2002, Spanoudakis et al. 2003).

4.3  Inconsistency management process modelling and enactment

A central aspect of the new design of Reconciliation developed in the IMOOSD project is the guidance of software engineers through the activities of inconsistency management by the enactment of a process model. This process model specifies:

(a) the tools that implement the algorithm outlined in Section 5.1 and may be invoked to identify overlapping elements in models, and the conditions under which these tools can be activated,
(b) the consistency rules that may be checked against the overlapping elements in the models, and the conditions which determine when these rules can be checked to detect inconsistencies,
(c) the significance criteria that may be taken into account to diagnose the significance of detected inconsistencies, and the conditions under which the diagnosis on the basis of these criteria can be activated, and
(d) the possible actions for handling inconsistencies and the conditions under which each of these actions can be applied.

This process model is specified in UML as an instance of a process meta-model which realises a contextual and decision oriented approach to process modelling. The process meta-model was originally developed in the ESPRIT project NATURE in the mid nineties. According to this meta-model a process is described as a graph of contexts. A context represents a decision to pursue a specific goal/intention or take an action in a given situation. A situation is a condition over the state of the software model(s) being manipulated by the process. The situation and the decision or action that may be taken in a context constitute parts of its specification.

To support the specification of the inconsistency management process of Reconciliation, we introduced two extensions to the NATURE's process meta-model. The first of these extensions was introduced to establish a scheme for specifying situations for processes that are to be enacted upon UML models. The second extension was introduced to establish a scheme for specifying the actions required for managing inconsistencies (in Reconciliation both the consistency rules to be checked and the ways of diagnosing and handling inconsistencies are specified as actions associated with specific contexts in the process model). These extensions were necessary since the NATURE's meta-model did not determine how to specify context situations and actions. This was because this meta-model was aimed at specifying process models that could be applied to software models specified in different modelling languages and notations, and therefore the scheme(s) for specifying situations and actions would inevitably have to be defined in reference to these languages and notations.

To specify the situations and actions required for the Reconciliation processes, we defined operations which can be used to: (1) retrieve elements from UML models that satisfy a particular condition, (2) modify elements in UML models, (3) generate new elements in UML models, (4) save newly generated elements in UML models, and (5) evaluate the significance of inconsistencies in a particular set of detected inconsistencies according to a specific criterion of significance (see Subsection 3.2 above) and rank them in descending order of their significance. Situations and actions are specified as ordered sequences of operations of these kinds. The operations introduced and the schemes for specifying situations and actions are described in (Spanoudakis & Kim 2001).

As part of the IMOOSD project, we also developed an engine to enact the process model of Reconciliation. This engine interprets the process model of the method and, based on it, it generates the possible decisions/actions that may be taken in a given situation (i.e. state) of the models being reconciled, presents these decisions/actions to developers, and acts according to the decision/action selected or other instructions given by them. It also keeps track of the entire sequence of the decisions and actions taken in the course of enacting the process model. The developed process enactment engine and the algorithm it implements are described in (Spanoudakis & Kim 2001, Spanoudakis & Kim 2003).

4.4  Development of method prototype and evaluation

A prototype to implement the method has been developed. This prototype incorporates a tool for detecting overlaps in object interaction models and the process enactment engine. The prototype has been implemented on the top of Rational Rose  (i.e., a CASE tool supporting UML) using the application programming interface (API) available to extend the functionality of this tool.

The models which are subject to inconsistency management are collections of UML class models and sequence diagrams. The process models of the method and the traces of the enacted processes are also represented as UML class models. The developed prototype and the results of a case study that we have carried out to evaluate various aspects of the method are reported in (Spanoudakis and Kim 2003)

References

Project proposal

• Spanoudakis G., (1999): "IMOOSD: Interference Management in Object-Oriented Software Development - Case for Support", Project Proposal