Model Management addresses the problem of managing an evolving collection of models, by capturing the relationships between models and providing well-defined operators to manipulate them. In this paper, we describe two such operators for manipulating hierarchical Statecharts: Match, for finding correspondences between models, and Merge, for combining models with respect to known correspondences between them. Our Match operator is heuristic, making use of both static and behavioural properties of the models to improve the accuracy of matching. Our Merge operator preserves the hierarchical structure of the input models, and handles differences in behaviour through parameterization. In this way, we automatically construct merges that preserve the semantics of Statecharts models. We illustrate and evaluate our work by applying our operators to AT&T telecommunication features. 1

The development of complex software systems is a complex and lengthy activity that involves the participation and collaboration of many stakeholders (e.g. customers, users, analysts, designers, and developers). This results in many partial models of the developing system. These models can be inconsistent with each other since they describe the system from different perspectives and reflect the views of the stakeholders involved in their construction. Inconsistent software models can have negative and positive effects in the software development life-cycle. On the negative side, inconsistencies can delay and increase the cost of system development; do not guarantee some properties of the system, such as safety and reliability; and generate difficulties on system maintenance. On the positive side, inconsistencies can facilitate identification of some aspects of the system that need further analysis, assist with the specification of alternatives for the development of the system, and support elicitation of information about it. The software engineering community has proposed many techniques and methods to support the management of inconsistencies in various software models. In this paper, we present a survey of these techniques and methods. The survey is organized according to a conceptual framework which views inconsistency management as a process composed of six activities. These activities are the detection of overlaps, detection of inconsistencies, diagnosis of inconsistencies, handling of inconsistencies, tracking of inconsistencies, and specification and application of a management policy for inconsistencies. This paper also presents the main contributions of the research work that has been conducted to support each of the above activities and identifies the issues which are still open to further research. 1.

The construction of a complex software system involves many agents with different perspectives or views of the system they are trying to describe or model. This gives rise to many partial specifications -- viewpoints. These viewpoints may "interfere" with each other that is the goals of the agents may be mutually interdependent. This interference is inevitable and acceptable in system development. In this paper we examine how interference can be "managed " and the tasks that this entails. We summarise ongoing research and suggest new research directions.

ion. Requirements may be distinguished based on the abstraction level of their description. A requirement may be further defined by add new details defined in more specialized subrequirements. Through specialization of abstract requirements, or generalization of detailed requirement, a requirement abstraction hierarchy can be defined. . Development p roperties . Requirements may be distinguished based on their development properties. For example, a requirement may have just been proposed. Late r, it may be accepted or rejected. . Representational properties. Requirements may be distinguished based on their representation. A requirement may begin as an informal sketch, then become a natural language sentence (e.g., "The system shall ..."). Finall y, more formal representations, such as UML, Z, or predicate cal- Requirements Interaction Management - Definition and scope 6 1999 William N. Robinson Requirements Interaction Management GSU CIS 99-7 culus, may be used to express a requir...

esses the relationship between development objects [9]. In order to identify such a relationship, particularly in the context of multiple views, areas of overlaps between these views must also be identified. Such overlaps may be made explicit by the development methods deployed (e.g., syntactic overlaps) or may require (domain) analysis in order to discover and express them. It is worth noting at this point however that the notion of inconsistency described above provides a technical basis for detecting, deriving and analysing logical inconsistencies. We have also studied the notion of conflicts which do not always manifest themselves as logical inconsistencies. The pre-requisites for conflicts to occur are also overlaps (expressible by some rule(s)), but conceptually one could regard them as different. In fact the term "interference" has been used to cover the "problems" arising from these different kinds of overlap [11].

Although overlap between specifications -- that is the incorporation of elements which designate common aspects of the system of concern -- is a precondition for specification inconsistency, it has only been a side concern in requirements engineering research. This paper is concerned with overlaps. It defines overlap relations in terms of specification interpretations, identifies properties of these relations which are derived from the proposed definition, shows how overlaps may affect the detection of inconsistency; shows how specifications could be rewritten to reflect overlap relations and still be amenable to consistency checking using theorem proving; analyses various methods that have been proposed for identifying overlaps with respect to the proposed definition; and outlines directions for future research. 1. Motivation In software engineering settings where different stakeholders may have conflicting requirements for the system to be built, there is no point in worrying about t...

Multiperspectives naturally arise out of co-operative work in applying appropriate technologies to construct different parts of an application. The representation styles of various perspectives can be highly heterogeneous and open-ended since those perspectives should be presented in a form appropriate to each participant in the software development process. This makes it difficult to provide consistency checking and integration mechanisms for the perspectives. This paper presents an approach of dealing with automated consistency checking for multiperspective software specifications regardless of their heterogeneity of representation. We apply expressive graph notations called Conceptual Graphs (CGs) as visual consistency checking notations. The combination of underlying logical reasoning and graph-based reasoning of CGs provide a powerful consistency checking mechanism. Our framework is illustrated with excerpts of a case study using Unified Modeling Language (UML).

This paper describes our experiences in restructuring multi-perspective requirements specifications in order to identify and analyse inconsistencies and manage change. A partial, heterogeneous and reasonably large requirements specification from a NASA project was analysed and decomposed into a structure of "viewpoints", where each viewpoint encapsulates partial requirements of some system components described in the specification. Relationships between viewpoints were identified which included not only the interactions explicitly stated in the requirements but also some implicit and potentially problematic inter-dependencies. The restructuring process and a first informal analysis of the resulting relationships enabled the detection of inconsistencies and the definition of some interesting domain-dependent consistency rules. We believe that this restructuring into viewpoints also facilitated requirements understanding through partitioning, and requirements maintenance and evolution th...

Reconciliation is a method which supports the detection and verification of overlaps and the resolution of certain forms of inconsistencies between requirements specifications expressed in an object-oriented framework. The method identifies a set of candidate overlaps between two specifications by analysing their similarity. These overlaps are assessed by the authors of the specifications. If the authors disagree with the overlaps identified by analysis, the method guides them through an exploration activity aimed at (1) identifying inconsistencies in the modelling of the specifications with respect to the overlaps indicated by them, and (2) resolving these inconsistencies in a way which ensures that the results of further analysis will converge with overlaps indicated by the authors. This paper provides an overview of the method focusing on the process of identifying and resolving inconsistencies between specifications. Keywords: inconsistency management, requirements engineering, obj...

Abstract not found