Using ViewPoints for inconsistency management

Easterbrook, Steve; Nuseibeh, Bashar

doi:10.1049/sej.1996.0004

Cited by 136 publications

(96 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Viewpoint-oriented requirements management has become a commonly used paradigm among researchers [11,12,18,26]. Viewpoint-oriented methods concentrate on capturing separate descriptions that together form the complete specification.…”

Section: Related Workmentioning

confidence: 99%

Feature Interaction and Dependencies: Modeling Features for Reengineering a Legacy Product Line

Ferber

Haag

Savolainen

2002

Software Product Lines

View full text Add to dashboard Cite

Abstract. Reengineering a legacy product line has been addressed very little by current product line research activities. This paper introduces a method to investigate feature dependencies and interactions, which restricts the variants that can be derived from the legacy product line assets. Reorganizing the product line assets with respect to new requirements requires more knowledge than what is easily provided by the classical feature-modeling approaches. Hence, adding all the feature dependencies and interactions into the feature tree results in unreadable and unmanageable feature models that fail to achieve their original goals. We therefore propose two complementary views to represent the feature model. One view shows the hierarchical refinement of features similar to common featuremodeling approaches in a feature tree. The second view describes what kind of dependencies and interactions there are between various features. We show two examples of feature dependencies and interactions in the context of an engine-control software product line, and we demonstrate how our approach helps to define correct product configurations from product line variants.

show abstract

Section: Related Workmentioning

confidence: 99%

Feature Interaction and Dependencies: Modeling Features for Reengineering a Legacy Product Line

Ferber

Haag

Savolainen

2002

Software Product Lines

View full text Add to dashboard Cite

show abstract

“…As mentioned above, relationships between viewpoints were either ignored or briefly mentioned (as it happens, e.g., in the IEEE Std. 1471, the Zachman framework, or most EAFs), or implicitly defined using the names of the related elements (e.g., [6,7,8,9,10,24]). The problem is that without explicitly representing correspondences we cannot reason about them, nor properly tackle the integration and consistency issues mentioned above.…”

Section: Expressing Correspondences: Related Workmentioning

confidence: 99%

“…This is a serious problem for large-scale distributed systems in which the viewpoints are indeed separately specified, and in which this simplistic assumption does not hold. The majority of approaches that deal with the problem of inconsistency among viewpoints (see, e.g., [6,7,8,9,10,24]) are also based on this oversimplified assumption, which hinders their applicability to many complex systems. Making an analogy with the common 2D representation of 3D figures, this is like drawing independently the three orthographic views of a figure but without defining any correspondence lines between them.…”

Section: Introductionmentioning

confidence: 99%

Well-formed Rules for Viewpoint Correspondences Specification

Romero

Vallecillo

2008

2008 12th Enterprise Distributed Object Computing Conference Workshops

View full text Add to dashboard Cite

show abstract

“…The final step is to incorporate what can be consistently accepted from the economy cluster, for example e 2 . 4 Notice Since the safety cluster is given lower priority in L3, both sentences s 2 and s 4 cannot be consistently kept. One has to give up either s 2 or s 4 .…”

Section: The Light Control Examplementioning

confidence: 99%

“…For example, in [4], consistency checking rules are combined with pre-defined lists of possible actions, but with no policy or heuristics on how to choose among alternative actions. The entire approach relies on taking decisions based on an analysis of the history of the development process (e.g., past inconsistencies and past actions).…”

Section: Related Workmentioning

confidence: 99%

Reasoning About Requirements Evolution Using Clustered Belief Revision

Rodrigues

Garcez

Russo

2004

Advances in Artificial Intelligence – SBIA 2004

View full text Add to dashboard Cite

During the development of system requirements, software system specifications are often inconsistent. Inconsistencies may arise for different reasons, for example, when multiple conflicting viewpoints are embodied in the specification, or when the specification itself is at a transient stage of evolution. These inconsistencies cannot always be resolved immediately. As a result, we argue that a formal framework for the analysis of evolving specifications should be able to tolerate inconsistency by allowing reasoning in the presence of inconsistency without trivialisation, and circumvent inconsistency by enabling impact analyses of potential changes to be carried out. This paper shows how clustered belief revision can help in this process. Clustered belief revision allows for the grouping of requirements with similar functionality into clusters and the assignment of priorities between them. By analysing the result of a cluster, an engineer can either choose to rectify problems in the specification or to postpone the changes until more information becomes available.

show abstract

Using ViewPoints for inconsistency management

Cited by 136 publications

References 10 publications

Feature Interaction and Dependencies: Modeling Features for Reengineering a Legacy Product Line

Feature Interaction and Dependencies: Modeling Features for Reengineering a Legacy Product Line

Well-formed Rules for Viewpoint Correspondences Specification

Reasoning About Requirements Evolution Using Clustered Belief Revision

Contact Info

Product

Resources

About