X -SCTL/MUS: A Formal Methodology to Evolve Multi-Perspective SoftwareRequirements Specifications ∗

Ana Belen Barragans Martınez, Ph.D. Student and Jose J. Pazos Arias, Ph. D. AdvisorTelematic Engineering Department. University of Vigo. 36200 Vigo. Spain

{belen, jose}@det.uvigo.es

Abstract

The objective of this thesis is to extend the formalmethodology of refinement of requirements specificationsSCTL/MUS to a multi-perspective environment wherecoexist requirements specifications which belong to eachstakeholder involved in the software development of thesystem. To reach this goal, the new methodology (referredto as X -SCTL/MUS) bets on using a viewpoint-basedapproach which allows to gather and maintain (possiblyinconsistent and incomplete) information gathered frommultiple sources. It explicitly separates the descriptionsprovided by different stakeholders, and concentrates onidentifying and resolving conflicts between them.

Keywords: Requirements Refinement, Viewpoints, Un-specification, Specification Evolution, Inconsistency, Multi-Perspective Environment.

1. Introduction

Large-scale software development must satisfy manypeople and organizations, with differing viewpoints regard-ing a proposed software system. In recent years, more andmore attention has been given to problems in requirementsdevelopment that can be effectively addressed by acknowl-edging the importance of multiple views. Viewpoints are ameans for separating concerns in software development inaccordance with a variety of criteria, such as the interestsand perspectives of agents, the development strategies andmethods or the notations employed. Inherently to any ap-proach based on multiple views, the need of checking andmanaging the consistency between the different viewpointsarises, being necessary to verify that the different specifica-tions do not impose contradictory requirements. Viewpointsowners need method, automated reasoning and tool sup-

∗This work was partially supported by the Xunta de Galicia Basic Re-search Project PGIDT01PX132203PR.

port for resolving inconsistencies. The role of such supportwould be to generate, and present participants with alterna-tive resolutions to choose from. This doctoral proposal is anextension to a multi-perspective scenario of the SCTL/MUSmethodology [8] which is focused on the field of refinementof requirements specifications.

2. Starting Point and Problem Identification

SCTL/MUS methodology [8] proposes an incrementaldevelopment model which formalizes system evolutions bydefining unspecified elements which can evolve into spec-ified ones. To achieve it, an extension of classical La-beled Transition Systems, referred to as MUS (Model ofUnspecified States), is used to model the system. The ele-ments of a MUS graph can be specified as: true (1), false(0) and unspecified ( 1

2 ) which can evolve into 1 or 0. Thismethodology also defines a temporal logic SCTL (SimpleCausal Temporal Logic) with causal and many-valued se-mantics, with six levels of satisfaction which allow us toreason about system evolutions. In recent work, we try toapply SCTL/MUS to a multi-perspective environment [1].From this experience, we have found both the next strengthsof the methodology to be employed in this kind of envi-ronments: (i) the incomplete nature of MUS models offerssupport to partial specifications of the system (viewpoints)since the unspecification concept allows to distinguish for-bidden behaviors from those which have not been speci-fied yet, (ii) the many-valued nature of SCTL allows bothto cuantify in the specification the level of agreement be-tween agents and to reason in presence of unspecificationphenomena, and (iii) its high degree of formality; and thefollowing lacks: (a) it only provides a mechanism of detec-tion of potential inconsistencies which guides to the stake-holders with proposals of refinement of their partial modelswhich avoid the appearance of the real inconsistency, (b) itneither supports the inconsistency management nor the rea-soning in presence of it (overspecification phenomena), and(c) it neither provides negotiation activities nor resolutionof conflicts.

Proceedings of the 26th International Conference on Software Engineering (ICSE’04)

0270-5257/04 $20.00 © 2004 IEEE

3. Thesis Objectives

This thesis establishes the objectives listed below:- To present a methodology tolerant with inconsistency

[4]. The decision of deferring the resolution of inconsisten-cies is a prudent measure when developers work with in-complete models, avoiding precipitate decisions when theydo not have sufficient information at their disposal yet.Therefore, the methodology must allow, always it is pos-sible, to reason in presence of inconsistency.

- It must generate revisions of the agents’ specificationseither to resolve an inconsistency, or to verify a desirableproperty of the global system over a set of perspectives.These revisions can include refinements of the system (lossof unspecification). However, this notion of refinement isnot sufficient to address the resolution of particular con-flicts. In these cases, we must weak some initial require-ment which is too much restrictive.

- As is noted in [6], global consistency cannot be provedthrough local consistency checking (for example, three per-spectives can be consistent when compared pairwise butinconsistent when taken together). Our model sets out amechanism of global consistency checking.

4. From SCTL/MUS to X -SCTL/MUS

In the current state of our research, the main problemswe have found and the proposed solutions are listed below:

Perspectives Representation: Our proposal makes useof a dual scheme. We employ SCTL logic to elicit the re-quirements and scenarios of each stakeholder and we makeuse of MUS graphs to internally represent each viewpointfor merging and validation purposes.

Formalization of Inter-Perspective Relationships:Given a pair of MUS viewpoints, we distinguish the nextrelationships: (a) they describe behaviors at the same levelof abstraction or not, and (b) within the former category, weconsiderate several levels of overlap between views: totallyoverlapped, partially overlapped and independent.

Viewpoints Merging: We will need to reason aboutproperties of the composed system. In order to combine aset of viewpoints with the aim of obtaining a merged modelthat reflects the degree of consistency, we extend the setof specification values of X -MUS1 models by adding onevalue that explicitly represents an inconsistency arisen fromthe merging process (EXM[a] ∈ {0, 1

2 , 1, INC}). Havinga X -MUS model that explicitly represents conflicting spec-ification values facilitates the identification and localizationof the sources of the inconsistency. Moreover, we can ver-ify properties of the global system over the X -MUS model,

1X -MUS denotes a MUS model obtained from a merging process.EM[a] denotes the specification value of action a in state E of view M.

having the possibility of reasoning and obtaining relevantconclusions in presence of inconsistency [6] always that theinconsistencies do not affect to the part of the model we areanalyzing. In this way, once the inconsistency is flagged, itis possible to make progress in the development and to de-lay its resolution. The different views will be combined indifferent ways depending on the inter-perspective relation-ships established between them.

Inconsistency Detection and Handling: The detectionof inconsistencies in X -SCTL/MUS takes place inside themerging process. When one or more inconsistencies aredetected, their level of impact must be analyzed and mea-sured to decide how to act: to delay their resolution andto continue the analysis and reasoning or to try to resolvesome or all of them – in this case, it may be interesting toprioritize the resolutions. One primary classification of in-consistencies will distinguish between real inconsistencies(type I) that explicitly identify conflicting specification val-ues from two or more stakeholders, and potential inconsis-tencies (type II) which are produced when unspecified val-ues are involved in the merging process. Depending on theirevolution, they could lead to future inconsistencies (type I).

Construction of a Many-Valued Model-Checker: Themodel-checker developed in the SCTL/MUS methodologycannot be applied over the X -MUS models.

Perspectives Revision: Once the combined analysis isdone, a set of changes over the X -MUS model is gener-ated either to make it to satisfy the desired property (if itdid not) or to resolve the inconsistency. Translation of thesechanges should be made back into each one of the origi-nating views with the goal of providing to the stakeholdersdifferent alternatives to choose from them the more suit-able. These alternatives (expressed in SCTL) will representpartial modifications of the original perspectives. It is nec-essary to define a measure of both the risk that entails tomaintain an inconsistency and the benefits generated by itsresolution to prioritize between actions of management.

Revision of the Concept of Refinement: The alterna-tives provided to the stakeholders in SCTL/MUS suggestedevolutions of the specification values in order to increasetheir level of knowledge, that is, unspecified values ( 1

2 )could be refined into specified ones (true or false). Theconcept of refinement will be generalized by the concept ofevolution which allows specification values to evolve fromthe higher levels of knowledge (from true to false and viceversa) since it is the only way to achieve an agreement be-tween conflicting parties. The main drawback that this newmodel introduces is that implies the lack of the characteris-tic of preserving properties in X -SCTL/MUS. It requires,therefore, to evaluate again the satisfaction of propertieswhich previously were satisfied.

Proceedings of the 26th International Conference on Software Engineering (ICSE’04)

0270-5257/04 $20.00 © 2004 IEEE

5. Expected Contributions

X -SCTL/MUS allows the specification of software re-quirements based on multiple perspectives and makes thefollowing contributions: (a) it allows the incremental de-velopment of the perspectives what each stakeholder has,facilitating the task division and decreasing the develop-ment complexity, (b) X -SCTL/MUS allows to formally ver-ify properties over X -MUS models which represent explic-itly overspecification and unspecification phenomena (if adetected inconsistency does not permit to continue the rea-soning, appropriated actions will be generated to resolve it);and (c) the generated alternatives are expressed in SCTL.

6. Related Work

The use of multiple views in software development isnot a new technique. The first viewpoint-oriented approachwas introduced in 1979 [5], but the concept of a viewpointwas not formalized until fifteen years later [7]. Viewpoint-oriented methods were originally developed to assist withrequirements definition in a software engineering environ-ment and subsequent research has followed a similar di-rection. Research in multiple views has later focused onmaking the approach explicit by addressing issues relatedto notations, analysis, tool integration, and benefits. Mul-tiple views have been used in requirements elicitation, do-main modeling, requirements definition and specification,program development systems, and software design reuse.From all characterizations of “views” which appear in theliterature, we can highlight [3] where Easterbrook defines aperspective as “a description of an area of knowledge whichhas internal consistency and an identifiable focus of atten-tion”. For sake of adequacy and completeness during re-quirements elicitation it is essential that the viewpoints ofall parties involved be captured and eventually integrated ina consistent way. Two kind of approaches have emerged. Inthe centralized approach, the viewpoints are translated intosome logic-based “assembly” language for analysis global;viewpoint integration then amounts to some form of con-junction. In the distributed approach, viewpoints have spe-cific consistency rules associated with them; consistencychecking is made by evaluating the corresponding rules onpair of viewpoints. X -SCTL/MUS opts for an interme-diate mechanism allowing autonomous evolution of eachview except when it is necessary to verify global properties(views are merging and a mechanism of global consistencychecking is applied). Consequently, a characteristic of anymultiple-viewed approach is that intersections between theviews of the different agents will inevitably appear whichimplies that inconsistencies can arise. Spanoudakis et alpresent in [9] a survey of the techniques and methods thatthe software engineering community has proposed to sup-

port the management of inconsistencies in various softwaremodels. The majority of methods for inconsistency detec-tion and handling are semi-formal or manual, and althoughthe degree of formality is higher in more recent multiple-viewed approaches (KAOS, xlinkit and PREview), they donot fulfill all our exigencies. This reason together with thestrengths of SCTL/MUS makes us to prefer to adapt the lat-ter instead of employing one of the literature.

7. Evaluation and Preliminary Conclusions

Work is now concentrating on the primary implemen-tation of a prototype which supports the X -SCTL/MUSmethodology. We are currently focused on the developmentof the algorithms of merging and inconsistency detection.The next goal is to develop the algorithms of the model-checker and of generation of alternatives from the analysisinformation. As earlier mentioned, the main drawback ofX -SCTL/MUS is the lack of conservation of properties un-der certain circumstances. To deal with the problem of over-head that having to reevaluate the properties’ satisfactionsupposes, we will propose the inclusion in the methodologyof one suitable tool that reuses verification efforts [2].

References

[1] B. Barragans Martınez, J. Garcıa Duque, J. Pazos Arias,A. Fernandez Vilas, and R. P. Dıaz Redondo. RequirementsSpecification Evolution in a Multi-Perspective Environment.In COMPSAC 2002, pages 39–44. IEEE CSP, August 2002.

[2] R. P. Dıaz Redondo, J. J. Pazos Arias, A. Fernandez Vilas, andB. Barragans Martınez. ARIFS: Reusing Formal VerificationEfforts in a Requirements Specification Stage. In Workshopon Model-Based Software Reuse (ECOOP’16), June 2002.

[3] S. Easterbrook. Domain Modelling with Hierarchies of Alter-native Viewpoints. In ISRE. IEEE CSP, 1993.

[4] A. Finkelstein, D. Gabbay, A. Hunter, J. Kramer, and B. Nu-seibeh. Inconsistency Handling in Multi-Perspective Specifi-cations. IEEE TSE, 20(8):569–578, August 1994.

[5] G. P. Mullery. CORE - A Method for Controlled RequirementSpecification. In ICSE’4, pages 126–135, Munich, Germany,September 1979. IEEE CSP.

[6] B. Nuseibeh, S. Easterbrook, and A. Russo. Making Incon-sistency Respectable in Software Development. Journal ofSystems and Software, 58(2):171–180, September 2001.

[7] B. Nuseibeh, J. Kramer, and A. Finkelstein. A Frameworkfor Expressing the Relationships Between Multiple Views inRequirements Specification. IEEE Transactions on SoftwareEngineering, 20(10):760–773, October 1994.

[8] J. Pazos Arias and J. Garcıa Duque. SCTL-MUS: A FormalMethodology for Software Development of Distributed Sys-tems. A Case Study. Form. Asp. of Comp., 13:50–91, 2001.

[9] G. Spanoudakis and A. Zisman. Inconsistency Managementin Software Engineering: Survey and Open Research Issues.In Handbook of Software Engineering and Knowledge Engi-neering, pages 329–380. World Scient. Pub. Co., 2001.

Proceedings of the 26th International Conference on Software Engineering (ICSE’04)

0270-5257/04 $20.00 © 2004 IEEE