Incremental Elaboration of Scenario

Imperial College of Science, Technology and Medicine

University of London

Department of Computing

Incremental Elaboration of Scenario-

Based Specifications and Behaviour

Models Using Implied Scenarios

Sebastian Uchitel

A thesis submitted in fulfilment of the requirements for the degree of Doctor of Philosophy in the Faculty of Engineering of the University of London, and for the Diploma of the Imperial College of Science,

Technology and Medicine.

February 2003

Abstract

The design of concurrent systems is a complex task prone to subtle errors that can have serious consequences. Behaviour modelling has proved to be successful in helping uncover flaws at design time; however, it has not had a widespread impact on practitioners. There are two important reasons for this. Firstly, behaviour model construction remains a difficult task that requires considerable expertise. Secondly, the benefits of behaviour analysis appear at the end of the model construction effort. In contrast, scenario-based specifications are relatively easy to use, have a wide acceptance in industry and are well suited for developing first approximations of intended behaviour; however, they are still maturing with respect to rigorous semantics and analysis tools. The main aim of this thesis is to develop a practical and effective process for elaborating system behaviour models and scenario-based specifications by exploiting the potential benefits of both while ameliorating their shortcomings.

This thesis proposes an approach for incremental elaboration centred on the notion of implied scenarios. Implied scenarios identify gaps in scenario-based specifications. These gaps are the result of mismatches between the behavioural and architectural aspects of specifications such as message sequence charts (MSCs). Due to the partial nature of scenario-based specifications, implied scenarios cannot be determined a priori to be undesired behaviour. Thus, by iteratively validating implied scenarios we can drive the elaboration of system models. Four artefacts are the outcome of the incremental elaboration process we propose. The first is a scenario-based specification that has been evolved from its original form to cover important aspects of the concurrent nature of the system that were under-specified or absent in the original specification.

In addition, the specification may have new, elicited functionality that was not present in previous versions. The second is a behaviour model that captures the component structure of the system. The third and fourth artefacts are behaviour models that serve as a system constraint and property respectively. These three behaviour models provide the basis for modelling and reasoning about system design.

In addition to the process itself, the thesis has a number of more specific contributions. Firstly , we introduce the notion of implied scenario as indicators of gaps in scenario-based specifications. Secondly , we define a synthesis algorithm for constructing minimal architecture models. Thirdly , we provide an implied scenario detection method for regular MSC specifications that consists of bMSCs, hMSCs, and negative scenarios. Fourthly , we propose a negative scenario language for documenting rejected implied scenarios. Finally, we have developed an extension of the Labelled Transition System Analyser tool that supports the elaboration process.

Para Vanina con todo mi amor.

Acknowledgements

Firstly, I would like to express my most sincere gratitude and appreciation to my supervisor Jeff

Kramer for his guidance and encouragement. His experience and insight have not only been invaluable for my work on this thesis but also for my development as a researcher. His friendship and support have made my experience as a PhD student an unforgettable one (for all the good reasons!). I am also deeply indebted to Jeff Magee for all the stimulating discussions and suggestions. Embarking on a technical discussion with him is an incredibly challenging and fun experience.

Special thanks to Daniel Yankelevich who saw over my first steps towards my Ph.D. in Buenos

Aires before leaving to London. I am also indebted to Paola Inverardi who convinced me not to give up, reminded me what research is about, and pushed me to come to Imperial. I also want to thank Alex Wolf for his support and for the advice he gave me up in cold L’Aquila. Daniel,

Paola, and Alex have given me invaluable advice over the years.

I wish to thank Bashar Nuseibeh for his support, constant advice, and for organising the fruitful

RE meetings. I am grateful to the RE group, Alessandra, Andrew, Artur, George, Luncheng,

Oliver, Siv (and his news cuttings) and Will, for the fun and constructive technical and nontechnical Friday lunch discussions.

I am grateful to the friends and colleagues at Imperial who have made working on this PhD enjoyable, sharing coffees, lunches, discussions and advice. In particular, Anne, Arosha, Emil,

Krish, Morris, Naranker, Nicodemos, Nicola, Roberto, Sophia, Susan, Tyrone, and my office mates Gulden, Ioannis, Johnny, Radmilla, Theo, and Xiang. A special thank you goes to Robert

Chatley who also worked hard implementing part of the tool discussed in this thesis.

Contrary to popular belief, PhD candidates have an extra-college life, or at least I did thanks to quite a few Londoners . I can't thank them all and enough, but I need to at least thank Charlotte and Kurt for developing Nansen Village (and for accepting me back after 20 years!), Maribel,

José Javier, Tito, Daniela, for the "picadas" in house 40 front garden, the brazilian bunch (Celso

- o amigo da bruxa -, Sibeli, Huascar, Adriana, Cristiano and Rubia) for not rubbing in the

World Cup disaster; Kaveh for taking me to see Saturday, all the Cohens for adopting me

(again!), Dan for the endless discussions, Sula for her "hola, como estas", Theo for his parties and the argentine mob (Naza, Diego, the Andys, Sol, Fede, James, Emi and Gaby) for everything.

The support of my family, Sarita, Osvaldo and Laura, who watched over me from a distance while I worked towards my degree, has been invaluable. My dad's passion for research has obviously a lot to do with me pursuing this Ph.D. I am very grateful for that. My well-being was constantly monitored by my mum who worried sick if on a Monday morning I appeared off-line in Yahoo Messenger (even if it was a bank holiday!). Throughout the duration of my Ph.D., I have many times remembered my grandfathers Pablo and Isaac, they have been and will always be a source of inspiration.

I must also thank people in Buenos Aires who supported my Ph.D. adventure: Mónica and

Damian who let me move away from Lemma; Irene, Aida, Victor, Dan, Patricia, Marcelo, and

Edu (the dc.uba.ar bunch) who all helped in very different ways; Marta and Tito for forgiving my stealing their daughter (la nena); and all my friends who make every visit back home an unforgettable event.

Last but not least, I would like to thank Vanina, my wife, for her love. This thesis, quite simply, could not have been completed without her. Gracias!

Financial support for this work has been provided by the Department of Computing (FCEyN) at

University of Buenos Aires, FOMEC, ORS, EPRSC under BEADS (GR/M24493) grant,

ESPIRIT under grant 24962-C3DS, Fundación Antorchas, and the British Council.

Table of Contents

Abstract............................................................................................................................3

Acknowledgements..........................................................................................................7

Table of Contents ............................................................................................................9

List of Figures................................................................................................................13

Chapter 1 Introduction...........................................................................................17

1.1

Motivation ................................................................................................................. 17

1.2

Implied Scenarios ...................................................................................................... 19

1.3

Overview of the Elaboration Process ........................................................................ 20

1.4

Formal Overview of the Elaboration Process............................................................ 22

1.5

Contributions ............................................................................................................. 24

1.6

Thesis Outline............................................................................................................ 25

Chapter 2 Background............................................................................................27

2.1

Scenario-Based Specifications .................................................................................. 27

2.2

Sequence Charts ........................................................................................................ 29

2.2.1

Basics .................................................................................................................... 29

2.2.2

Managing Multiple Sequence Charts.................................................................... 34

2.2.3

Semantics............................................................................................................... 38

2.2.4

Analysis ................................................................................................................. 40

2.2.5

Expressiveness and Model Checking .................................................................... 42

2.3

Collaboration Diagrams............................................................................................. 43

2.4

Use Cases................................................................................................................... 43

2.5

Use Case Maps .......................................................................................................... 44

2.6

Summary and Discussion .......................................................................................... 44

Chapter 3 Specifying Positive Scenarios ...............................................................47

3.1

Basic Message Sequence Charts................................................................................ 47

3.2

High-level message sequence charts ......................................................................... 50

3.3

Positive message sequence chart specifications ........................................................ 50

3.4

Discussion.................................................................................................................. 53

3.5

Summary.................................................................................................................... 54

Chapter 4 Behaviour Models .................................................................................55

4.1

Labelled Transition Systems ..................................................................................... 55

4.1.1

Parallel Composition ............................................................................................ 58

10

4.1.2

Hiding ....................................................................................................................61

4.1.3

Equivalences ..........................................................................................................61

4.1.4

Describing LTSs with FSP.....................................................................................63

4.2

System Architecture...................................................................................................65

4.3

Architecture Models...................................................................................................67

4.3.1

Synthesis of Architecture Models...........................................................................67

4.3.2

Comparing Architecture Models ...........................................................................74

4.4

Summary ....................................................................................................................77

Chapter 5 Implied Scenarios.................................................................................. 79

5.1

Some Examples..........................................................................................................79

5.2

Definitions and Properties..........................................................................................81

5.3

Discussion ..................................................................................................................82

5.4

Summary ....................................................................................................................85

Chapter 6 Implied Scenario Detection .................................................................. 87

6.1

Trace Models..............................................................................................................88

6.2

Trace Model State Space Reduction ..........................................................................93

6.2.1

Heuristics...............................................................................................................94

6.2.2

Assessment .............................................................................................................97

6.3

Implied Scenario Detection using LTSA ...................................................................98

6.4

Discussion ................................................................................................................102

6.5

Summary ..................................................................................................................105

Chapter 7 Specifying Negative Scenarios............................................................ 107

7.1

Basic Negative Scenarios.........................................................................................107

7.1.1

Syntax and Semantics ..........................................................................................108

7.1.2

Implied Scenario Detection .................................................................................110

7.2

Abstract Negative Scenarios ....................................................................................113

7.2.1


7.2.2


7.3

After/Until Negative Scenarios ................................................................................117

7.3.1


7.3.2


7.4

Consistency Checking..............................................................................................121

7.5

Discussion ................................................................................................................122

7.6

Summary ..................................................................................................................123

Chapter 8 Implementation & Validation............................................................ 125

8.1

Tool Support ............................................................................................................125

11

8.2

A Passenger Transportation System ........................................................................ 128

8.2.1

Introduction......................................................................................................... 128

8.2.2

Elaboration Process............................................................................................ 128

8.2.3

Summary.............................................................................................................. 141

8.3

Industrial Case Study............................................................................................... 142

Chapter 9 Discussion and Evaluation..................................................................145

9.1

On Elaboration......................................................................................................... 145

9.2

On Convergence ...................................................................................................... 148

9.3

On End Products...................................................................................................... 149

9.4

Critical Evaluation................................................................................................... 154

9.4.1

Ease of learning .................................................................................................. 154

9.4.2

Early payback...................................................................................................... 155

9.4.3

Incremental gain for incremental effort .............................................................. 156

9.4.4

Multiple use......................................................................................................... 157

9.4.5

Integrated use...................................................................................................... 157

9.4.6

Ease of use........................................................................................................... 157

9.4.7

Efficiency............................................................................................................. 158

9.4.8

Orientation toward error detection..................................................................... 158

9.4.9

Focused analysis ................................................................................................. 159

9.4.10

Evolutionary development .............................................................................. 159

Chapter 10 Conclusions ..........................................................................................161

10.1

Summary of Contributions ...................................................................................... 161

10.2

Future Work............................................................................................................. 162

10.3

Closing Remarks ..................................................................................................... 163

Bibliography ................................................................................................................165

List of Figures

Figure 1.1 – Scenario for a Boiler Control system ..................................................................... 20

Figure 1.2 – Simplified view of the elaboration process ............................................................ 21

Figure 1.3 – Detailed view of the elaboration process................................................................ 22

Figure 2.1 – Example of a scenario described using narrative text............................................. 28

Figure 2.2 – Example of a sequence chart .................................................................................. 30

Figure 2.3 – Elements of a sequence chart.................................................................................. 30

Figure 2.4 – Sequence chart with event labels............................................................................ 32

Figure 2.5 – High-level message sequence chart ........................................................................ 35

Figure 2.6 – Sequence chart for an unreadable swipe card scenario........................................... 35

Figure 2.7 – Component and system states in sequence charts................................................... 36

Figure 2.8 – Expressing alternative behaviour using only scenario composition....................... 37

Figure 3.1 – Positive MSC specification for a Boiler Control system........................................ 49

Figure 3.2 – Weak sequential composition of bMSCs Analysis and Register............................ 51

Figure 3.3 – Elements of the detailed overview of Section 1.4 discussed in Chapter 3 ............. 54

Figure 4.1 – Component model for Database ............................................................................. 57

Figure 4.2 – Component model for Control................................................................................ 60

Figure 4.3 – LTS for (Database||Control) ................................................................................... 60

Figure 4.4 – LTS for (Database||Control)/{data, query}............................................................. 61

Figure 4.5 – Trace equivalent LTSs............................................................................................ 62

Figure 4.6 – FSP for Database .................................................................................................... 63

Figure 4.7 – LTS with and END state......................................................................................... 64

Figure 4.8 – FSP for process SeveralQueries ............................................................................. 64

Figure 4.9 – LTS for SeveralQueries illustrating sequential composition in FSP ...................... 64

Figure 4.10 – Architecture model synthesis algorithm ............................................................... 68

Figure 4.11 – Behaviour of Control component in bMSC Analysis........................................... 69

Figure 4.12 – FSP code for HMSC_Control............................................................................... 70

Figure 4.13 – Composition of Control’s behaviour in all bMSCs .............................................. 70

Figure 4.14 – Control component model .................................................................................... 71

Figure 4.15 –Actuator component model ................................................................................... 71

Figure 4.16 –Sensor component model....................................................................................... 71

Figure 4.17 – Database component model.................................................................................. 71

Figure 4.18 – Architecture model for the Boiler Control system ............................................... 71

Figure 4.19 – Terminating LTS model for AuxUser .................................................................. 72

Figure 4.20 – Extended version of the Secure Door system ....................................................... 73

Figure 4.21 – FSP Code for the Secure Door system ................................................................. 73

14

Figure 4.22 – New LTS for User................................................................................................. 73

Figure 4.23 – MSC for exemplifying ordering of architecture models .......................................75

Figure 4.24 – Component model for Figure 4.23 ........................................................................75

Figure 4.25 – Alternative component model for B......................................................................76

Figure 4.26 – Second MSC for exemplifying ordering of architecture models ..........................76

Figure 4.27 – Component models for Figure 4.26 ......................................................................77

Figure 4.28 – Alternative component model for E......................................................................77

Figure 4.29 – Elements of the detailed overview of Section 1.4 discussed in Chapter 4............78

Figure 5.1 – First implied scenario of the Boiler Control system ...............................................80

Figure 5.2 – Example of MSC with implied scenario but no non-local choice...........................84

Figure 5.3 – Elements of the detailed overview of Section 1.4 discussed in Chapter 5..............85

Figure 6.1 – Example of a non-regular MSC specification .........................................................87

Figure 6.2 – Control component model extended with coordination actions..............................89

Figure 6.3 – Trace model for the Boiler Control system.............................................................93

Figure 6.4 – Portion of the Coordinator model ...........................................................................95

Figure 6.5 – FSP code for detecting implied scenarios using LTSA.........................................100

Figure 6.6 – First implied scenario detected by LTSA..............................................................102

Figure 6.7 – Two bMSCs for a Transport System.....................................................................104

Figure 6.8 – Property violation trace .........................................................................................105

Figure 6.9 – Deadlock trace.......................................................................................................105

Figure 6.10 – Elements of the detailed overview of Section 1.4 discussed in Chapter 6..........106

Figure 7.1 – Example of a basic negative scenario ...................................................................108

Figure 7.2 – LTS of basic negative scenario of Figure 7.1........................................................111

Figure 7.3 – Second implied scenario of the Boiler Control system .........................................113

Figure 7.4 – Basic negative scenario resulting from Figure 7.3................................................113

Figure 7.5 – Third implied scenario of the Boiler Control system............................................114

Figure 7.6 – Example of an abstract negative scenario .............................................................115

Figure 7.7 – Abstract negative scenario with alphabet extension .............................................115

Figure 7.8 – Constraint LTS for Figure 7.6...............................................................................116

Figure 7.9 – Constraint LTS for Figure 7.7...............................................................................116

Figure 7.10 – Fourth implied scenario of the Boiler Control system ........................................117

Figure 7.11 – Example of an after/until negative scenario........................................................118

Figure 7.12 – Constraint for negative scenario in Figure 7.11 ..................................................121

Figure 7.13 – FSP code for detecting implied scenarios using LTSA.......................................122

Figure 7.14 – Elements of the detailed overview of Section 1.4 discussed in Chapter 7..........124

Figure 8.1 – MSC-LTSA: the hMSC editor ..............................................................................126

Figure 8.2 – MSC-LTSA: the bMSC editor ..............................................................................126

15

Figure 8.3 – MSC-LTSA: Synthesised FSP.............................................................................. 126

Figure 8.4 – MSC-LTSA: Validation ....................................................................................... 126

Figure 8.5 – MSC-LTSA:Negative Scenario............................................................................ 127

Figure 8.6 – MSC-LTSA: Model Animation............................................................................ 127

Figure 8.7 – Initial version of the PTS specification ................................................................ 129

Figure 8.8 – Implied scenario of the PTS specification (Iteration 1)........................................ 130

Figure 8.9 – Amendment to the PTS specification (Iteration 1) ............................................... 130

Figure 8.10 – Re-factored version of the PTS specification (Iteration 1)................................. 131

Figure 8.11 - Implied scenario of the PTS specification (Iteration 2)....................................... 132

Figure 8.12 – Amendment to the PTS specification (Iteration 2) ............................................. 132

Figure 8.13 – Implied scenario of the PTS specification (Iteration 3)...................................... 132







Figure 8.20 – Amendments to the PTS specification (Iteration 6) ........................................... 135

Figure 8.21 – Extension of PTS specification to describe a non-terminating system............... 135




Figure 8.25 – First version of amendment to the PTS specification (Iteration 9)..................... 138

Figure 8.26 – Inconsistency introduced by Incorrect Vehicle Dispatch (v1)............................ 138

Figure 8.27 – Inconsistency introduced by Incorrect Vehicle Dispatch (v2)............................ 138

Figure 8.28 – Final amendment to the PTS specification (Iteration 9)..................................... 139

Figure 8.29 – Implied scenario of the PTS specification (Iteration 10).................................... 139

Figure 8.30 – Amendment to the PTS specification (Iteration 10) ........................................... 140

Figure 8.31 – Implied scenario of the PTS specification (Iteration 11).................................... 140

Figure 8.32 – Amendment to the PTS specification (Iteration 11) ........................................... 141

Figure 9.1 – Modified Control component model .................................................................... 151

Figure 9.2 – Modified Database component model .................................................................. 151

Figure 9.3 – FSP code for modified Database and Control components .................................. 151

Figure 9.4 – FSP code for verifying design solution ................................................................ 152

Figure 9.5 – FSP code for verifying correct transport dispatch ................................................ 153

Figure 9.6 – Property LTS for verifying correct transport dispatch.......................................... 153

Figure 9.7 – LTSA output indicating a property violation........................................................ 154

16

Chapter 1

Chapter 1 Introduction

1.1 Motivation

Systems characterised as concurrent and distributed are widely used in applications that range from television sets and train signalling systems to e-commerce and stand-alone PC-based software applications. The design of the software for such systems is generally complex, with a high possibility that subtle errors will cause erroneous behaviour. Some of these errors may have catastrophic consequences in terms of money, time, or even human life [Clarke and Wing

1996]. Consequently, support for pre-development and pre-deployment reasoning about system behaviour is crucial.

A traditional engineering approach to the construction of complex systems is using models. A model is an abstract representation of a specific part, or aspect of a system that can be studied to increase confidence on the adequacy of the product to be built. Engineers use models because the cost of constructing them is significantly lower that building the actual system, and because models provide opportunities for analysis and the detection of design errors early in the development process thereby allowing cheaper fixes.

Behaviour models are precise, abstract descriptions of the intended behaviour of a system. They structure systems as autonomous, concurrent entities and describe how they interact. Behaviour models have solid mathematical foundations that can be used to support rigorous analysis and mechanical verification of properties. Effective techniques and tools have been developed for this purpose and have shown that behaviour modelling and analysis are successful in uncovering the subtle errors that can appear when designing concurrent and distributed systems [Clarke and

Wing 1996, Cleaveland and Smolka 1996].

Although there is substantial benefit to be gained in using behaviour models for developing complex system, industry has been slow in assimilating behavioural modelling and verification technologies. Practitioners are not convinced that the benefit of rigorous and automated analysis justifies the cost of constructing such models. We believe the reasons for this are twofold.

Firstly, the construction of behaviour models remains a difficult task that requires considerable expertise in behaviour model notations. Secondly, and perhaps more importantly, the benefits of behaviour analysis appear at then end of the considerable effort of constructing behaviour

18 Chapter 1. Introduction models. Behaviour analysis and verification techniques have been developed under the assumption that a comprehensive description of the system behaviour (up to some level of abstraction) has been constructed. Thus, they are generally not well suited for providing early feedback on partial system descriptions.

How can the construction of behaviour models be significantly simplified? Can we provide automated or semi-automated procedures to assist engineers in building initial approximations of the intended system behaviour? Is it possible to provide engineers with feedback, and therefore benefits, early in the behaviour model construction process? We believe these questions can be answered positively, and that scenario-based specifications can play an important role in the answer to these questions.

Scenario-based specifications, such as message sequence charts (MSCs) [ITU 1996] and UML sequence diagrams [OMG 2002], are popular as part of requirement specifications. Scenarios describe how system components, the environment and users work concurrently and interact in order to provide system level functionality. Their simplicity and intuitive graphical representation facilitates stakeholder involvement and makes them popular for conveying and documenting requirements. Each scenario is a partial description which, when combined with all other scenarios contributes to the overall system description.

Although scenarios are widely used in industry, their use is mainly informal, with no precise semantics associated with the scenario description (e.g. [Carroll 1995, Harmon and Watson

1998, Jacobson et al 1999]). Consequently, analysis techniques and tools have restricted applicability, often limited to syntactic consistency checks (e.g. [Rational 2002]). Of course, there has been work on providing precise semantics to scenario-based specifications (e.g.

[Heymer 2000, ITU 1996, Katoen and Lambert 1998, Reniers 1999]) and developing semantic analysis tools (e.g. [Ben-Abdhallah and Leue 1998, Holzmann et al 1997, Wakahara et al

1989]). However, the main tendency has been to view scenario-based specifications as another behaviour specification language. Yet there is a fundamental difference between scenario-based specifications and behaviour modelling approaches. Scenario specifications naturally result in partial descriptions. They depict a series of examples of what the system is expected to do. In the best of cases, these examples cover most common system behaviours and the main exceptions. Expecting stakeholders to produce, in one go, a set of scenarios that cover all possible system traces is unrealistic and impractical; thus, existing analysis tools and techniques developed under the assumption of complete (or even relatively complete) specifications cannot tackle the partial nature of such specifications. They do not detect gaps in the specification that, if not elaborated, could result in costly errors later on in the development process.

Section 1.2 Implied Scenarios 19

How can scenario-based specifications be used to support rigorous analysis and automated verification of system behaviour given that these specifications are normally very partial descriptions? Can we provide tools that support the elaboration of scenario-based specifications? We believe that it is possible and that behavioural models can play a useful role.

Describing systems as autonomous, concurrent entities that interact in order to implement system level functionality is a perspective that scenario-based specifications such as message sequence charts (MSCs) hold in common with behaviour models. Yet, in a way, they can be considered to provide dual system views. On the one hand, scenario-based specifications focus on sequences of interactions between collaborating entities. On the other hand, behaviour models focus on the collaborating entities , and study the different sequences of interactions these entities can produce. Scenario specifications are still maturing with respect to rigorous semantics and analysis tools, yet have a wide acceptance in industry and are well suited for preliminary, partial descriptions of system behaviour. Behaviour models have not had such a widespread impact on practitioners; nevertheless, they boast an important mathematical foundation, effective tools for behaviour analysis, and have proven be success in uncovering flaws in fully developed system models. Summarising, there is benefit to be gained by balancing the potentials and shortcomings of approaches based on scenarios and behaviour models.

Scenario notations such as MSCs (see Figure 1.1) describe two distinct aspects of a system.

Firstly, they depict a series of examples of what constitutes acceptable system behaviour. These examples consist of sequences of messages – called traces – that system components are expected to send each other. Secondly, scenario notations outline the high-level architecture of the system. Scenarios depict with vertical arrows, or instances , which system components are involved in providing the intended system behaviour. They also describe component interfaces because they illustrate which messages are being sent and received by each component. In this thesis, by architecture we mean the system components and their interfaces.

20 Chapter 1. Introduction

Typical run

Sensor Database Control on

Actuator pressure pressure pressure query data off command

Figure 1.1 – Scenario for a Boiler Control system

Implied scenarios indicate gaps in a scenario-based specification that are the result of specifying the behaviour of a system from a global perspective yet expecting the behaviour to be provided in a local component-wise fashion, by independent entities with a local view of the system. If the specified architecture does not provide components with a rich enough local view of what is happening at a system level, components may not be able to enforce the intended system behaviour. Effectively, what may occur is that each component, from its local perspective, may believe that it is behaving correctly, yet from a system perspective the behaviour may not be what is intended. These additional system traces resulting from the inadequate local view of components are called implied scenarios .

Behaviour models are particularly well suited for reasoning about implied scenarios:they can be used to rigorously analyse how a set of components, which comply with the architecture described in the scenario-based specification, behave when working together. In particular, we can analyse to see if they exhibit any traces that have not been explicitly specified in the scenario-based specification.

1.3 Overview of the Elaboration Process

Given that scenario-based specifications are partial system descriptions, it would be erroneous to assume implied scenarios necessarily indicate incorrect behaviour. An implied scenario may simply mean that an acceptable scenario has been overlooked and that the scenario specification needs to be completed. By adding the implied scenario, the partial description of system behaviour is extended. Alternatively, the implied scenario may represent unacceptable behaviour and therefore require careful documentation of the undesired situation so that it can be avoided when further elaborating the system architecture. Ultimately, the decision of whether to accept or reject an implied scenario depends on the problem domain. In other words, implied scenarios need to be validated with stakeholders. Consequently, by detecting and validating implied scenarios it is possible to drive the elaboration of scenario-based specifications.

Section 1.3 Overview of the Elaboration Process 21

Message Sequence

Chart Specification

Traces

& Arch itecture

Traces

Architecture

Model Synthesis

Trace Model Synthesis

Architec ture Mo del

Trace

Mode l

Model Check

Evolve specification Implied Scenario

Figure 1.2 – Simplified view of the elaboration process

Figure 1.2 depicts a simplified version of the proposed elaboration process. The bottom portion shows the validation of implied scenarios with stakeholders, while the top portion describes in a simplified manner how implied scenarios are detected by essentially constructing two behaviour models. The first is an architecture model, which is synthesised using both behavioural and architectural information of the specification. This model is the parallel composition of a series of component behaviour models. Each component behaviour model corresponds to a component described by the specification and is synthesised to interact with its environment using only the messages that are allowed at its interface. In addition, if all component behaviour models are composed in parallel, we can show that the resulting system can exhibit all the traces specified in the MSC. Furthermore, we can show that it is minimal with respect to trace inclusion, i.e. that any other model that preserves the component structure and component interfaces, and exhibits all specified traces provides at least all the traces of our architecture model. This means that any behaviour exhibited by the architecture model that has not been specified explicitly in the MSC specification is an implied scenario.

To detect the existence of implied scenarios in the architecture model we use another behaviour model. This model, called the trace model , is synthesised using only the set of traces described by the MSC specification. We do not use the architectural information of the MSC to construct this model. By doing so, if the MSC specification determines a regular language, we can capture precisely the set of traces described by the MSC specification. The trace model is used in combination with the architecture model to detect implied scenarios. Implied scenario detection thus consists of verifying if the architecture model can exhibit a trace that the trace model cannot. We use a model checker to verify trace inclusion, and can prove that the regular MSC has implied scenarios if and only if the model checker outputs one as a counter example.

The implied scenario detection and validation cycle facilitates the elaboration of four artefacts.

The first is the MSC specification itself that then covers more aspects of the system behaviour; in particular, it covers more aspects concerning the concurrent nature of the system to be developed. The other three artefacts are the architecture and trace models (described above), and

22 Chapter 1. Introduction a constraint model (described below) that provide the basis for reasoning about and elaborating the design of the system. These models also provide the basis for further analysis such as if subsequent design decisions satisfy the evolved MSC specification. To further explain the artefacts produced by the proposed elaboration process we present our approach more formally and in more detail.

1.4 Formal Overview of the Elaboration Process

To explain the elaboration process formally we need to introduce a more detailed view (see

Figure 1.3). The terminology, synthesis algorithms and artefacts of this elaboration process are described and justified in the succeeding chapters of this thesis. Additionally, Figure 1.3 is repeated in Chapters 3 to 7 to show the topics discussed in each chapter in the context of the proposed elaboration process.

In order to accommodate implied scenario acceptance and rejection, we use an extended MSC language comprised of two parts: a positive part ( PSpec ) that specifies the intended system behaviour and a negative part ( NSpec ) that specifies the behaviours that the system is expected not to exhibit. The semantics of the language determines a set of traces for each part. We use

L ( PSpec ) and L ( NSpec ) to denote the sets of maximal traces determined by the positive and negative parts of the specification.

Positive

Scenarios

( PSpec )

Negative

Scenarios

( NSpec )

Architecture

Traces

( L(PSpec)

)

Traces

( L(PSpec)

)

Traces

( L(NSpec)

)

Architecture Model

Synthesis

Minimal Architecture Model ( A )

L ( PSpec ) ⊆ mt ( A ) A = ( A

1

L A n

)

Trace Model

Synthesis

Constraint Model

Synthesis

Trace Model ( T ) mt ( T ) = L ( PSpec )

(

Model Check mt ( A C ) ⊆ mt ( T )) ?

Constraint Model ( C ) mt ( C ) = L ( NSpec ) − 1

Positive or Negative Scenario Implied Scenario ( i ) i ∈ ( mt ( A ) \ L ( PSpec ) \ L ( NSpec ))

Figure 1.3 – Detailed view of the elaboration process

From the MSC specification, we synthesise three different behaviour models in the form of labelled transition systems (LTS) [Keller 1976] where transitions are labelled with the messages that components send each other. Using the positive system traces, L ( PSpec ), and architectural information, architecture model synthesis builds the architecture model ( A ) as the parallel composition of component models A

1

,…, A n

where the alphabet of A i

coincides with the

Section 1.4 Formal Overview of the Elaboration Process 23 interface of component i . Thus, we have A =( A

1

||…|| A n

) where || is the LTS parallel composition operator, and L ( PSpec ) ⊆ mt ( A ) where mt ( A ) is the set of maximal traces exhibited by LTS A 1 . In addition, A can be proven to be the minimal model (with respect to trace inclusion) that complies with the MSC architecture and that includes all the specified traces ( L ( PSpec )). Thus, traces in mt ( A )\ L ( PSpec ) are implied scenarios. The second behaviour model we build is the trace model ( T ). This model is built from the set of positive system traces ( L ( PSpec )), ignoring the specified architecture, such that mt ( T )= L ( PSpec ) holds if L ( PSpec ) is regular. The third behaviour model we build is the constraint model ( C ). This is built from the set of negative system traces ( L ( NSpec )) so that it captures the complement of the traces the system should not exhibit: mt ( C )= L ( NSpec ) -1 .

From the perspective of MSC specifications with both positive and negative scenarios, the notion of implied scenario must be qualified. We are interested in traces that are exhibited by the architecture model ( A ), that have not been specified in the positive part of the MSC specification ( L ( PSpec )) and that have not already been explicitly rejected by stakeholders and hence included in the negative part of the MSC specification ( L ( NSpec )). Thus, we are interested in the following set of implied scenarios: ( mt ( A )\ L ( NSpec ))\ L ( PSpec ).

Consequently, to check for the existence of implied scenarios we need to check if the set

( mt ( A )\ L ( NSpec ))\ L ( PSpec ) is an empty set. We can show that if we compose the architecture model ( A ) with the constraint model ( C ) we are subtracting from the set of maximal traces of A those that are prohibited in the MSC specification; that is mt ( A || C )= mt ( A )\ L ( NSpec ). This relies on the way we build the constraint behaviour model and the fact that parallel composition of

LTSs forces synchronisation on shared message labels. Thus, ( mt ( A )\ L ( NSpec ))\ L ( PSpec ) is an empty set if mt ( A || C ) ⊆ L ( PSpec ) holds. We can model check for this because assuming

L ( PSpec ) is regular, we have a model that captures L ( PSpec ) precisely: the trace model T . In essence, we check for maximal trace inclusion of T in A || C using the model checking features of the LTSA tool [Magee and Kramer 1999]. This produces an implied scenario ( i ) as a counterexample if the inclusion does not hold ( i ∈ ( mt ( A )\ L ( NSpec ))\ L ( PSpec )).

According to the outcome of implied scenario validation by stakeholders, the positive or negative part of the scenario specification is updated. The result is a new specification ( PSpec ’,

NSpec ’) that determines two new sets of traces L ( PSpec ’) and L ( NSpec ’). If a positive scenario is added as a result of accepting an implied scenario, the specification is extended

( L ( PSpec ) ⊂ L ( PSpec ’) and L ( NSpec ) = L ( NSpec ’)). If a negative scenario is added as a result of rejecting an implied scenario, the specification is strengthened ( L ( PSpec )= L ( PSpec ’) and

1

Maximal traces correspond to infinitely long executions of outgoing transitions.

A , or executions that end in states with no

24 Chapter 1. Introduction

L ( NSpec ) ⊂ L ( NSpec ’)). Either way, the scenario-based specification is elaborated to cover at least one further aspect of the concurrent nature of the system being described.

In addition, accepting an implied scenario and extending the positive part of the specification may lead to a new extended architecture model A ( tr ( A ) ⊆ tr ( A ’)|

α (A)

) 2 , which in turn may lead to introducing more implied scenarios into the specification. This means that a new system behaviour has been added to the specification, behaviour that was not present in the original architecture model. Thus, new system functionality can be elicited. On the other hand, if an implied scenario is rejected and the negative part of the MSC specification is strengthened, then we obtain a specification with fewer implied scenarios: ( mt ( A ')\ L ( NSpec ’))\ L ( PSpec ’) ⊆

( mt ( A )\ L ( NSpec ))\ L ( PSpec ). By repeating this process of detection and validation of implied scenarios, it is possible to iteratively elaborate scenario-based specifications and behaviour models and possibly converge to a state where there are no more implied scenarios to be validated.

As mentioned before, four artefacts are produced as the result of the incremental elaboration process. The first is a MSC specification that has been evolved from its original form to include further aspects of the concurrent nature of the system and possibly further functional aspects too. The second is the trace model. This model captures precisely the traces the system is expected to exhibit. The third is the architecture model, which captures the intended system architecture, but which may exhibit additional unspecified behaviour. The fourth is the constraint model, which captures the properties that the architecture model should comply with if it is to avoid the negative scenarios and provide only the specified system behaviour.

The architecture model provides the basis for modelling and reasoning about system design. In fact, it is the model that needs to be further developed through architectural and design decisions as designers move towards implementation. This provides the basis for a sound implementation.

The three behaviour models should help developers to reason about their designs. Furthermore, the constraint model can help in the design process as it models the properties that the architecture model must satisfy.

1.5 Contributions

The main contribution of this thesis is a novel process for incremental elaboration of scenario based specifications and behaviour models using implied scenarios . In addition to the process itself, the thesis has a number of more specific contributions. Firstly , we introduce the notion of

2 tr ( A ’ )|

α (A)

is the set of traces of A ’ projected onto the alphabet of A .

Section 1.6 Thesis Outline 25 implied scenario as an indicator of gaps in scenario-based specifications. Secondly , we define a synthesis algorithm for constructing minimal architecture models. Thirdly , we provide an implied scenario detection method that works with hMSCs and behavioural constraints.

Fourthly , we propose a negative scenario language for documenting rejected implied scenarios.

Finally , we have developed a tool that supports the proposed elaboration process

The work presented in this thesis is based on and extends several papers that have been published in the last three years [Uchitel and Kramer 2001, Uchitel et al 2000, Uchitel et al

2001, Uchitel et al 2002a, Uchitel et al 2002b, Uchitel et al 2002c]. This thesis should be regarded as the definitive account of the work.

In this thesis, we present both the theoretical and practical aspects involved in using implied scenarios for the elaboration of scenario-based specifications and behaviour models. All aspects are first exemplified in the context of a toy example based on a Boiler Control system. In

Chapter 2, we discuss some background work on scenario-based specifications in general and sequence chart notations in particular. In Chapter 3 we present a scenario-based specification language for documenting intended system behaviour. In Chapter 4, we discuss behaviour models and relate scenario-based specifications to them by defining the notion of architecture model. Chapter 5 introduces implied scenarios and Chapter 6 how these can be detected through behaviour model analysis. Chapter 7 motivates and presents negative scenarios. With all elements in place, in Chapter 8 we present an in depth case study and the tool developed for supporting the elaboration process. An extensive discussion and evaluation is in Chapter 9 and conclusions in Chapter 10.

Chapter 2

Chapter 2 Background

In this chapter, we give an account of scenario-based specifications in general and focus in more detail on issues that are related to sequence chart notations as these are extensively used in this thesis.

Scenarios are becoming an increasingly popular means for describing system behaviour. A scenario is a narrative description of how users, system components and the environment interact for the completion of a certain goal. Scenarios are stories, and as such, they are an effective means of facilitating communication among people. They are used in a variety of different settings that range from requirements engineering (e.g. [Holzmann et al 1997]) and formal specifications (e.g. [Reniers 1999]) to code synthesis (e.g. [Harel 2001]) and test case specification and generation (e.g. [Grabowski 1994]).

Within the literature, many different definitions of scenarios can be found (e.g. [Carroll 1995,

Jacobson et al 1999, Quatrani 1998, Texel and Williams 1997]). There are significant differences in terms of the syntax, features, semantics and more significantly, in terms of their intent. Most of these differences are motivated by the setting in which scenarios are being described in. However, there are some main aspects on which authors seem to coincide:

• Scenarios describe a sequence of events [Pearsall 1998] or activities [Carroll 1995].

• Scenarios refer to interactions between independent entities. Entities can be users, the system [Carroll 1995] (or possibly parts of it such as hardware, software, subsystems, objects [Jacobson et al 1999]) and the environment [ITU 1996].

The need to document scenarios has motivated the development of many scenario-based notations. Many authors have proposed using mixture of textual and pictorial techniques. These go from structured and narrative text [Weidenhaupt et al 1998], to storyboards of annotated cartoon panels, video recordings, and scripted prototypes [Carroll 1995, Robertson and

Robertson 1999]. An example of a narrative text scenario is Figure 2.1.

28 Chapter 2. Background

An employee swipes his card through the card reader that is attached to the company's entrance gate, the door controller sends the card information to the security system, which starts recording through the entrance security camera and unlocks the gate. Once the User has gone through the gate, the door controller signals the security system, which orders the camera to stop recording.

Figure 2.1 – Example of a scenario described using narrative text

An important issue with scenarios is their level of abstraction of their content. Scenarios can be concrete [Carroll 1995] or instance [Potts et al 1994] scenarios that refer to specific entity names and argument values. Scenarios can also be more abstract and provide "an idealised but detailed description of a specific instance … of interaction" [Young and Barnard 1987]. These scenarios are sometimes called type or abstract scenarios [Rolland et al 1996], and Figure 2.1 can be considered to be of this kind. However, we could make the scenario concrete by including the name of the employee, employee identifier, and security codes. The level of detail of the scenario can also be incremented by including more entities such as sensors or the network, or more interactions such as detailed aspects of the communication protocol between door controller and security system, or details of how the door controller detects that the user has gone through the gate. Furthermore, the scenario could be extended with alternative outcomes, for instance that the card is unreadable (as in scenario families in [Potts et al 1994] or scenario trees in [Hsia et al 1994]). In addition, scenario pre- and post-conditions, such as that the scenario occurs in working hours and the status of the employee in the security database is

"in site", can be included (as in [Heymans and Dubois 1998]).

Textual notations for documenting scenarios have been widespread in industry for some time

[Weidenhaupt et al 1998] and demonstrations of their effectiveness date back to the 1984 Los

Angeles Olympic Message System developed by IBM [Gould et al 1987]. However, these notations tend to be rather informal and, although useful for documentation and informal analysis, make automated processing of scenarios and rigorous or semi-rigorous analysis very difficult. Thus, textual scenario specifications do not serve well our purpose of using rigorous and automated techniques for developing scenario-based specifications. There has been significant research on controlled English (e.g. [Adriaens and Schreurs 1992]) and grammars for English (e.g. [Jurafsky and Martin 2000]), which constrain the structure of English sentences in order to make texts more amenable to automated processing. However, these techniques have yet to produce impact in industry in general. Furthermore, according to Fuchs and Schwitter, if controlled languages are to be used in requirements (or scenario) specifications the panorama is even more complex and further syntactic and semantics constraints for controlled languages must be introduced [Fuchs and Schwitter 1996].

Section 2.2 Sequence Charts 29

One of the most widespread approaches to documenting scenarios is using sequence charts.

Sequence charts have been used to describe system behaviour for some time, and examples of their use can be traced back to the late 80’s. They have been used, to exemplify service conventions in the International Standard Organisation’s (ISO) Open Systems Interconnection

(OSI) [ISO 1987] and in several ISDN service recommendations of the International Telephone and Telegraph Consultative Committee (CCITT) [CCITT 1988a, CCITT 1988b]. The latter, reconverted into the International Telecommunications Union (ITU), has undertaken a standardisation process resulting in a language called message sequence charts (MSCs), which has undergone several revisions since its first version in 1992 [ITU 1992, ITU 1993, ITU 1996,

ITU 2000]. For an account on the standardisation of message sequence charts by the telecommunication industry, refer to [Grabowski et al 1993].

In addition to being the starting point for MSCs, sequence charts constitute the core of a plethora of existing graphical scenario-based languages. The most notorious of these is the

UML [OMG 2002] notation for scenarios, sequence diagrams, which strongly resembles sequence charts. There are countless variations of sequence charts in the literature; in particular in research literature where a variety of different features and interpretations are being explored.

As we show next, sequence charts have the advantage of being very intuitive and simple, facilitating sequence chart elaboration and automated processing. For more pointers on scenarios in general, refer to [Carroll 1995, CREWS 1999, Jarke et al 1998].

In the remainder of this section we discuss sequence charts in order to introduce the main concepts related to scenario descriptions and address some of the existing syntactic and semantic variations that appear in other sequence chart-based languages. We present these variations by discussing different aspects of scenario-based specifications rather that describing each specific language separately. For a detailed survey on sequence charts refer to [Krüger

2000].

2.2.1 Basics

Sequence charts are a widespread a graphical notation for documenting scenarios (see Figure

2.2 and Figure 2.3). In sequence charts, vertical lines called instances are used to describe the entities that participate in the scenario. Instances can be used to represents varied kinds of entities such as users, hardware and software subsystems or objects; we discuss this further down. Interactions between instances are shown as arrows called messages . The source of a

30 Chapter 2. Background message indicates which instance initiates the interaction. Messages labels are normally considered to define the type of interaction, thus having the same sending and receiving instances throughout all scenarios. The points on instances where an arrow starts from and finishes are called send and receive events . An event can be considered the phenomenon observed by an instance because of an interaction. A sequence chart is interpreted time-wise in a top-down fashion; an event on an instance occurs before all other events of the same instance that appear below it. In addition, the direction of messages also provides information on the order in which events occur; a receive-event must never occur before its corresponding sendevent. For this reason, as a convention, messages are required to be drawn horizontally or with a downward slope. These assumptions on how time is represented in sequence charts determine a partial ordering of events. We discuss ordering of events in detail further on. In the remainder of the presentation, we use the terms message, instance and event to refer to the three basic syntactical elements in scenario notations based on sequence charts.

Employee enters building

User Door Controller swipeCard userId unlock openDoor closedoor closed

Security

System

Camera startRecording stopRecording

Figure 2.2 – Example of a sequence chart

Sequence chart name

Example

A

Send-event x

Message label

B y

C

Instance name

Instance

Message

Receiveevent

Figure 2.3 – Elements of a sequence chart

Instances

As mentioned above, in sequence charts vertical lines or instances represent the entities participating in the scenario. In general, we say that an instance represents a component . By

Section 2.2 Sequence Charts 31 component, we mean a part or element of a larger whole [Pearsall 1998], which in our case is a system. In other words, by component we refer generically to software and hardware systems and subsystems, users, processes, and software components (as in [Szyperski 1998] for example) among others. According to the context for which a particular scenario-based language has been designed, instances can be given a more restricted interpretation. For example in a high-level approach to scenarios that focuses on the distinction between system and environment, scenarios might use one vertical line to represent the system to be developed and other lines only for external actors such as existing systems and people or organisations. On the other hand, in the context of UML, a lower level of abstraction can be used and instances can model objects [Quatrani 1998, Texel and Williams 1997]. Whatever the level of abstraction in which instances are interpreted, the common assumption is that they represent independent entities that have capabilities for interacting with their environment.

Messages

Messages in sequence charts represent interactions between instances. However, as in the case of instances, they are also given a range of interpretations according to the context in which sequence charts are used. In particular, the interpretation of a message relies heavily on the interpretation of the instances that are involved in the interaction. For example, when at least one of the components involved is a person, messages model physical interactions. This includes examples such as typing data into a console, swiping a security card or delivering a package. In cases where people are not involved, a message can model a remote procedure call, message passing, method invocation, rendezvous, or an exception being raised and caught.

Messages usually involve only two instances, a sender and a receiver. However, messages can be used to model broadcast and multicast interactions.

Despite the different semantics that can be given to messages, three characteristics apply to all interpretations. Firstly, a message explicitly identifies the components involved in an interaction. Secondly, a message identifies, by means of the arrows source, the component that initiates the interaction. Thirdly, a message determines the point (an event) in which the interaction is observed by an instance involved in the interaction.

Event Ordering

The semantics of messages impacts considerably on how time is modelled in a sequence diagram. As mentioned before, it is assumed that an event on an instance occurs before all other events of the same instance that appear below it. In addition, it is also assumed that a receiveevent must never occur after its corresponding send-event. These two assumptions determine a partial ordering of events that specifies the relative order in which events may occur over time.



User a b c

Door Controller

Security

System

Camera swipeCard e d openDoor closedoor f g h i userId unlock closed k l n m stopRecording o p

Figure 2.4 – Sequence chart with event labels

Let us return to the example of the employee entering a secure building, which we now depict in

Figure 2.2 with labelled events only to facilitate the following explanation on event ordering.

This scenario states, for example, that the reception of message stopRecording (event p ) can occur after the sending of message startRecording (event k ). In other words that k < p . This is because event n is further down than k on the Security System instance ( k < n ) and p is the receive-event corresponding to the send event n ( n < p ). However, the converse is not so, the reception of message stopRecording (event p ) cannot occur before the sending of message startRecording (event k ).

We say that the ordering of events is partial because not all pairs of events are temporally related. For example, there is no relative ordering between the reception of startRecording

(event o ) and the reception of message unlock (event f ). This is reasonable if we think of messages as taking an unknown amount of time to reach their destination. A priori, different messages could have different delays, and thus the ordering of the reception of these messages cannot be assumed.

The partial ordering of events we have presented and which is the common core for most approaches based on sequence charts is based on minimal assumptions on the temporal relation between events. These assumptions can be too weak when using specific interpretations of messages. For example, consider the message s wipeCard in Figure 2.2. The message corresponds to a physical interaction between a user that wishes to enter the company premises and a door controller placed at one of the entrances. In this case, the send-event (when the employee swipes the card) might be considered to occur at the same time as the receive event

(when the card controller detects and-or reads the swipe card). Similarly, if a message represents a rendezvous, send and receive events can also be considered to occur simultaneously. In these cases, we say that the communication between components is synchronous . In the case of message userId , where the card reader sends the card information to a remote database to validate access permissions of the employee, it may not be reasonable to consider synchronous communication. Network latency may need to be taken into account, forcing the receive-event


(when the database receives the query) to occur after the send event (when the door controller sends the query ). We call this kind of communication asynchronous . Existing scenario-based languages assume either synchronous or asynchronous communication or allow both. When considering both kinds of communication, different notations are used. For example, in sequence diagrams synchronous and asynchronous messages are differentiated by using filled and hollow arrowheads [Rumbaugh et al 1999]. Sometimes, asynchronous messages are drawn with a downward slant to indicate that time elapses from its emission to its reception.

If we assume that messages starRecording and unlock model asynchronous communication, then the correct interpretation of the sequence chart is that the reception of the startRecording is temporally unrelated to that of unlock . Thus, message reception of both messages could occur in either order, not guaranteeing that the camera records when the employee goes through the door.

If we assume that these messages model synchronous communication, then the correct interpretation of the scenario is that the security camera receives the order to start recording before the unlock message is even sent. The same situation holds if we assume that start and stop recording messages are asynchronous; when stopRecording is sent, it is not guaranteed that startRecording has been received. However, startRecording must occur before stopRecording .

In the context of asynchronous communication, additional constraints on the ordering of events can arise if assumptions on the message queuing that handle the asynchronous messages [Alur et al 1996, Muscholl et al 1998]. For example, if a unique first-in first-out (FIFO) message queue is assumed to buffer all messages sent in the system, it would enforce a first-in first-out policy that would constrain certain event orderings. Such assumption would guarantee that unlock is received after startRecording is. However, it does not guarantee that unlock is sent after startRecording is received. Other assumptions that introduce different constraints on the ordering of messages are assuming each component has one FIFO queue that buffers the messages that are sent to it, or assuming that there is a FIFO queue for every pair of communicating components.

Extensions to Sequence Charts

There have been many extensions to the basic sequence chart notation presented above. We have already mentioned the inclusion of different message types to distinguish synchronous and asynchronous communication and queues to impose restrictions on event orderings. Other extensions include the explicit use of time to describe delays, timeouts and deadlines (e.g. [Ben-

Abdhallah and Leue 1997a, ITU 1996, Kosiuczenko and Wirsing 2000]), the dynamic creation and termination of instances (e.g. [ITU 1996]), parametric message and use of data (e.g. [Engels et al 1999, Haugen 2001]), local or component state labelling (e.g. [Krüger et al 1999]), global or system state labelling (e.g. [Rudolph et al 1996]), liveness conditions [Harel and Damm


1999], iterative and exceptional behaviour (e.g. [ITU 1996]), and mechanisms for combining scenarios. We discuss the latter in more detail in following sections.

2.2.2 Managing Multiple Sequence Charts

Scenarios, and sequence charts in particular, are partial descriptions. One scenario conveys relatively little information as it describes one of usually infinite possible system behaviours.

Thus, in the context of requirements engineering or system specification, scenarios need to be combined together to provide a more complete view of how a system is expected to behave.

Typically, scenarios are provided by different stakeholders and address different system functionalities. The conjunction of all scenarios provides a system description. However, choosing the right abstractions for combining scenarios is not a minor issue. Sequence charts have been extended in many very distinct ways in order to tackle this problem. We categorise them in three groups based on the following ideas: scenario composition, state identification, and triggers.

Scenario Composition

In the approach adopted by the International Telecommunication Union (ITU) [ITU 1996] focus is on providing scenario specifications with a means for managing complexity. Simple sequences of behaviour are described using an extension of sequence charts called basic message sequence charts (bMSCs). In addition, three basic constructs for combining bMSCs are provided: vertical, horizontal and alternative composition. Vertical composition of two bMSCs combines them sequentially. The system behaviour is determined by the behaviour of the first bMSC followed by the behaviour determined by the second one. Vertical composition introduces a subtle issue: events in the first scenario do not necessarily occur before all events of the second scenarios. The partial ordering of events determined by vertical composition is the result of the syntactical composition of the two scenarios: “placing one bMSC at the bottom of another one and then linking the instances they have in common…” [Reniers 1999]. Horizontal composition of two bMSCs amounts to considering they occur in parallel. In the case that both bMSCs have “some or all instances in common, it is assumed that the behaviour of the common instance(s) is the interleaving of the behaviours of these instance(s) in the separate bMSCs”

[Reniers 1999]. Alternative composition defines a set of possible MSCs that can be considered vertically composed with some initial MSC. In other words, it defines a set of alternative behaviours as the continuation of a given scenario. The underlying notion of scenario composition is that they can be used as building blocks to describe behaviour that is more complex.


Several syntactic constructs, equivalent in terms of expressiveness [Reniers 1999], are provided by the ITU standard for specifying scenario composition: inline expressions, MSC reference expressions and high-level MSCs, the last being the widely adopted (e.g. [Alur et al 1996,

Reniers 1999, Rudolph et al 1996]). High-level Message Sequence Charts (hMSCs) are directed graphs where each node references either an hMSC or a bMSC. Edges indicate the acceptable ordering of scenarios, thus allowing stakeholders to reuse scenarios within a specification and to introduce sequences, loops, and alternatives of bMSCs. Figure 2.5 depicts an hMSC with two nodes, one of which refers to the sequence chart we have presented previously. In order for the hMSC to be well defined, the other node (Unreadable Swipe Card) should be referring to either existing bMSCs or hMSCs. An arrow with a black filled circle as its tail indicates the initial starting point of the hMSC. In addition, the smaller black circle is a convenient way of reducing the number of edges that the hMSC has, and in this way increasing understandability; it can be simply considered an empty scenario.

Unreadable swipe card

User Door Controller swipeCard errorMsg log

Security

System


Unreadable

Swipe Card

Figure 2.5 – High-level message sequence chart

Figure 2.6 – Sequence chart for an unreadable swipe card scenario

The advantage of the hMSC approach is that it allows stakeholders to break up a scenario specification into manageable parts in a simple, intuitive, and operational way, and to show how these different parts relate. On the other hand, as explained by Rudolph et al [Rudolph et al

1996], scenario composition can lead to a large number of very short scenarios that must be composed in complex ways to describe the system's overall behaviour. This mitigates against the advantage of using scenario notations for depicting significant portions of system behaviour.

A common variation of hMSCs is that of high-level message sequence graphs (e.g. [Alur and

Yannakakis 1999]), these correspond to flat hMSCs, in other words hMSCs in which nodes are only allowed to reference bMSCs. We discuss hMSC semantics in Section 2.2.3 and provide a formal definition in Chapter 3

State Identification

An approach that differs significantly from the scenario composition approach is the identification of common component or system states throughout a set of scenarios (e.g.

[Koskimies et al 1998, Krüger et al 1999, Rudolph et al 1996, Somé et al 1995, Whittle and


Schumann 2000]). The assumption here is that the scenario specification is describing a statemachine that models the behaviour of system components. Thus, instances in a bMSC are considered to model both a set of states in the state-machine (which we call component states) and the events that fire state change (called labelled transitions). Thus, in the scenario specification, every space between consecutive events is called a scenario state (see Figure 2.7, right), and is considered to refer to component state. The relation between scenario and component states is many to one, meaning that several scenario states can refer to the same component state. Thus, scenario states in different bMSCs that refer to the same component state provide information of how the scenarios are related.

There are two basic mechanisms for identifying component states. The first is to allow stakeholders to tag scenario states (e.g. [Krüger et al 1999]). Typically, labels that describe the state of the component are placed on scenario states (see Figure 2.7, left); if two states in a scenario appear with the same label, they are considered to refer to the same component state.

The second approach avoids the needs for explicit state labelling in scenarios, and instead provides rules for identifying component states. These rules are usually based on domainspecific knowledge and additional information of the system being specified. For example,

SCED [Koskimies et al 1998] synthesises statecharts [Harel 1987] while applying some assumptions in order to decide whether two scenario states represent the same statechart state.

Another example is the work of Whittle and Schumann [Whittle and Schumann 2000], which uses an Object Constraint Language (OCL) specification that states pre- and post-conditions for scenario messages. The OCL specification is traversed with the MSCs to produce a valuation of state variables for each scenario state. Scenario states that have equivalent valuations are considered to represent the same component states.

Scenario 1

A B x

Waiting y

Ready for operation z

Idle

C

Model the same

A B

Waiting a

Ready for operation b c

C

Models a system state

Models a component state

Model the same system state

Figure 2.7 – Component and system states in sequence charts

Scenario states


A variation of identifying component states is that of system states [Rudolph et al 1996]. Instead of identifying component states on instances, labels that cover all instances of a scenario are used to mark a specific system state (see Figure 2.7), which essentially models the state in which each component is in at a particular moment. Identically labelled system states refer to the same system state.

An advantage of explicitly labelling component or system states is that they can be used to enrich scenario descriptions with additional information. This information can come from specifications that have different system viewpoints or from domain-specific knowledge. In addition, incorporating component or system state information may provide means for progressively moving into a more detailed design description. Compared with scenario composition, identifying states allows complex component behaviour including alternative behaviours to be described in bMSCs of any length. For example, in Figure 2.7we have two bMSCs with a system state labelled Ready for operation. This means that if the system is in bMSC Example 2 and messages x and y occur, then, instead of message z occurring, the system could now continue with b and c. Thus, the system state has introduced alternative behaviour.

To introduce the same alternative using scenario composition, we would need to split the scenarios exactly where the "Ready for operation" state, to then introduce some composition mechanisms to establish all possible alternative behaviour (see Figure 2.8). Although the specified behaviour is the same, we have had to split scenarios into smaller parts (some with only one message in them!) that may not be meaningful on their own.

Example 2.1

A B x

C

Example 3.1

A B a

C y

Example 3.2

A B

Example

2.1

Example

3.1

Example 2.2

A B z

C

C b c

Example

2.2

Example

3.2

Figure 2.8 – Expressing alternative behaviour using only scenario composition

The ITU provides a notation that resembles that of state labelling. Its MSC standard [ITU 1996] includes the notion of local and global conditions, which could be interpreted as component and system states. However, ITU has not assigned any semantics to these syntactic elements.

Several meanings to these constructs have been proposed. Component and system state identification is one of the possibilities being studied.


In UML [Rumbaugh et al 1999], sequence diagrams allow introducing state information; however, it is not clear how this information affects the composition of different scenarios

[Harmon and Watson 1998, Jacobson et al 1999, Quatrani 1998, Texel and Williams 1997]. To understand the relation between sequence diagrams it is usually necessary to refer to the statechart descriptions.

Triggers

The third mechanism for combining sequence charts (and scenarios in general) is using triggers or pre-conditions. Instead of relating scenarios to each other, information on when each scenario can occur is provided. This approach is popular in informal development methods [Carroll

1995, Quatrani 1998, Texel and Williams 1997] where scenarios are provided with a precondition normally stated in natural language. The pre-condition can refer informally to a state in which the scenario may occur or to a sequence of events that trigger the scenario. Other possibilities for describing pre-conditions are OCL or temporal logic, while scenario triggers can be specified using temporal logic or sequence chart like notations [Harel and Damm 1999].

An advantage of using triggers is that scenarios are loosely coupled. In contrast with scenario composition methods such as hMSCs where the whole set of scenarios must fit together in one graph, triggers permit expression of the context of scenarios independently of existing scenarios. However, this same characteristic is a disadvantage in handling a scenario specification as a whole. This is especially acute when triggers are the only mechanism for specifying relations between scenarios.

2.2.3 Semantics

In the previous section, we introduced the intuition of sequence charts and related concepts such as components, instances, events, messages, interactions and time. We have also mentioned some of the different interpretations that exist of these concepts. We now discuss the techniques for defining these interpretations and more importantly the implications of such techniques on the purpose and utility of scenario-based specifications in the light of the development process as a whole.

Techniques

In terms of how semantics for scenario-based languages are defined, existing work is quite varied. We identify three broad categories: informal, algorithmic and abstract semantics. The first category corresponds to scenario languages with no precise semantics that are used in the context of informal development methods (e.g. [Carroll 1995]) and in some UML-based development methods such as the Unified Software Development Process [Jacobson et al 1999]

Section 2.2 Sequence Charts 39 and others (e.g. [Harmon and Watson 1998, Quatrani 1998, Texel and Williams 1997]). Books presenting these methods usually devote one or two chapters to scenarios, providing general intuition in natural language supported with examples. Although useful for documentation and informal analysis, the lack of a precise interpretation of scenarios makes rigorous analysis of scenarios and formal verification of system compliance to requirements extremely difficult.

The second category includes approaches in which the semantics of a scenario specification is implicit, given by means of a translation algorithm. Using an algorithm to translate scenario specifications into other notations can determine a precise interpretation if the target notation has a well-defined semantics. However, this procedure is rather operational and does not provide an intuitive and abstract meaning to scenario specifications. Subtle aspects of the semantics may be, and usually are, buried in the synthesis algorithm. Some approaches translate scenario specifications into statecharts (e.g. [Khriss et al 1999, Koskimies et al 1998, Krüger et al 1999, Whittle and Schumann 2000]). In these cases, it is important to distinguish between the several different interpretations of statecharts that exist [Damm et al 1997, Harel et al 1987,

Maraninchi and Halbwachs 1996]; however, this is not always the case. Furthermore, approaches that build individual statecharts for each component do not always explain how these statecharts are to be composed to provide the overall system behaviour. We believe that this is crucial as many subtle design issues can lead to errors when concurrent interacting components are composed. Other efforts based on translation have focused on producing SDL specifications (e.g. [Ichikawa et al 1991]), hierarchical state machines (e.g. [Bordeleau 1999]) and other state machine based formalisms (e.g. [Klose and Wittke 2001]).

Finally, the third category includes work in providing a formal abstract semantics for scenariobased languages. The difference with the previous category is that the semantics is defined in an abstract manner rather than by a translation algorithm. Formalisation work includes the use of process algebras [ITU 1996, Reniers 1999], partial orders [Alur et al 2000], pomsets [Katoen and Lambert 1998], büchi automata [Ladkin and Leue 1995] and petri-nets [Heymer 2000]. In many cases synthesis algorithms are also provided but not as a means for defining scenario semantics. In some cases, they are developed for producing the input of model checkers

[Holzmann et al 1997]. If so, algorithms must be shown to preserve the semantics of the specification.

Design vs. early-requirement oriented semantics

Although the differences among approaches to scenario semantics can be considered a technical issue, the choice of mechanisms can strongly impact the role of scenario-based specification within the development process. Consequently, it also impacts on practical and research issues.

There are two fundamentally different approaches to scenario semantics.


Many authors consider scenario specifications to describe high-level design of system components. In other words, that a scenario specification directly determines a state machine for each system component [Harel and Damm 1999, Ichikawa et al 1991, ITU 1996, Koskimies et al 1998, Krüger et al 1999, Reniers 1999, Rudolph et al 1996, Wakahara et al 1989, Whittle and

Schumann 2000]. These approaches take on a design-oriented perspective, in which scenario descriptions are a design document in their own right.

A different interpretation of scenario specifications considers them to be describing system functionality. In other words, that a scenario determines a set of acceptable behaviours for which many designs could be found. This view is taken by many informal approaches to scenarios (e.g. [Carroll 1995]) as well as approaches using semantics based on partial ordering of events [Alur et al 2000, Alur et al 1996, Ben-Abdhallah and Leue 1997b]. This perspective introduces the problem of finding a design (or possibly many) for a given scenario specification and proving that the design satisfies the specifications requirements [Alur et al 2000].

Compared to the design-oriented approach discussed previously, this approach seams to be more suitable in an early-requirements-oriented view phase.

2.2.4 Analysis

As stated in the motivation of this work, a crucial point in the development of concurrent systems is pre-development and pre-deployment reasoning about system requirements and design. Therefore, providing scenario-based languages with adequate syntactic and semantic constructs for specifying requirements is not enough. Scenario-based approaches must provide tools for analysing such specifications. Unfortunately, the amount of efforts in this direction has been significantly less than the number focused on notations, features and semantics.

Nevertheless, there are a number of efforts in producing techniques for analysis of scenariobased specifications, many of which focus on checking for syntactic consistency (e.g. [Alur et al

1996, Rational 2002]). These checks depend on the features included in the sequence charts and can usually be prevented using appropriate editing tools. Some examples of what may be checked are that:

• Message labels are used consistently with respect to message initiator, recipients and parameters.

• Instance names correspond to declared components.

• Nodes in hMSCs refer to existing bMSCs.

• Timers have corresponding timeout.


However, when dealing with concurrent systems, syntactic correctness is not enough, analysis of semantic implications of specifications is crucial. Many authors have focused on specific system properties and have produced ad-hoc algorithms that can check their validity. For example, in sequence chart specifications that use asynchronous communication, a component can flood another by sending it an unbounded number of messages that the receiver cannot manage to process. This situation, called process divergence , can be detected using syntactic checks [Ben-Abdhallah and Leue 1997b] (i.e. no translation to a semantic model is needed), and have been implemented in the MESA tool [Ben-Abdhallah and Leue 1998]. Another property detected by the same tool is that of non-local choice [Ben-Abdhallah and Leue 1997b]. When using hMSCs, a given choice of sequence charts determined by the hMSC may be underspecified if the initial events of the different alternatives correspond to different components. In these cases for all components to agree on the scenario to follow a distributed choice among several components is needed. Race conditions where queues introduce or fail to enforce event orderings determined by scenarios have been studied by [Alur et al 1996]. Finally, general properties based on recognising patterns of communication have also been studied [Muscholl et al 1998]. Our work focuses on a different property, realisability which we define formally in

Chapter 5. This is complementary to other efforts in analysis and verification of scenario-based specifications. However, in contrast to other approaches to property verification, the violation of realisability is not an indication of an incorrect specification, it signals an aspect of the specification that needs to be further elaborated.

There has have also been important efforts in performing analysis of sequence chart specifications with additional information provided by different kinds of specifications [Andolfi et al 2000, Rational 2002, Somé et al 1995, Tsiolakis 2001, Whittle and Schumann 2000]. For example, tools such as Rational Rose [Rational 2002] can check that messages sent between instances in a sequence diagram correspond to public methods of the instance’s class. Whittle and Schumann [Whittle and Schumann 2000] combine sequence charts with Object Constraint

Language (OCL) specifications to detect inconsistencies. Sequence charts can also be used to derive system performance models [Andolfi et al 2000] and for schedulability analysis [Slomka et al 1998].

Additionally, there has been work on verifying user-specified properties on sequence chart based specifications. For example, in a template matching approach is proposed. Users can specify patterns of interaction, where message labels can be abstracted away using placeholders.

The TEMPLE tool [Holzmann et al 1997] can be used to exhaustively search the behaviour specified by a sequence chart specification in order to detect concrete interactions that match a given template. Another approach to sequence chart specification analysis is the use of standard

42 Chapter 2. Background model checking tools [Holzmann et al 1997]. Here sequence charts are used to synthesise behaviour models specified in Promela, which is the input language of the SPIN model checker.

Properties must then be written in temporal logic, and can then be checked against the synthesised model.

2.2.5 Expressiveness and Model Checking

The expressiveness of sequence chart based languages and the complexity of model checking them has been studied extensively in the last few years. Focus has been on message sequence charts (MSCs) and message sequence graphs (MSGs) adopting a trace-based semantics and asynchronous communication. Results show that in general, the expressiveness of these languages does coincide with regular languages in the sense of [Aho et al. 1986], and that model checking problems are undecidable. Authors have studied ways of characterising the expressiveness of these languages, and ways of defining subsets of them that make them amenable to analysis.

In [Henriksen et al. 1999] regular MSC specifications (sets of sequence diagrams with asynchronous communication) are defined as those whose set of specified traces can be represented with a finite automaton. Numerous positive model checking complexity results can be demonstrated for regular MSCs [Alur and Yannakakis 1999, Morin 2001, Muscholl and

Peled 1999].

Regular MSCs can be characterised as MSC that are both channel bounded MSCs [Alur and

Yannakakis 1999] and MSO definable [Henriksen et al. 1999]. The channel bounded property states that for all traces specified by the MSC specification the number of messages stored in message channels at any stage (due to the asynchronous communication) is bounded by a finite natural number. MSO languages are those in which the set of specified traces is definable in

Monadic Second Order (MSO) logic. [Henriksen et al. 1999, Morin 2001]. Based on MSO’s several other model checking complexity results have been reached (e.g. [Madhusudan and

Meenakshi 2001]).

Finitely generated MSC languages are those definable by a high-level MSC [Henriksen et al.

2000]. Not all finitely generated MSC languages are regular MSC languages; however, the bounded property guarantees regularity over finitely generated MSC languages [Henriksen et al.

2000]. This is a relevant result as in this thesis we use finitely generated MSC languages and need to guarantee regularity. [Morin 2001] provides a insightful overview of these and other main results on expressiveness and model checking of MSCs. Finally, characterisations of MSG languages based on Mazurkiewicz traces have also led to several complexity results (e.g.

[Muscholl and Peled 1999]).

Section 2.3 Collaboration Diagrams 43

In this thesis, we rely on the properties of the boundedness condition to construct from a given

MSC specification, a finite labelled transition system that precisely captures its specified set of traces.

In addition to sequence diagrams, UML provides another notation for describing interactions among objects. Collaboration diagrams contain similar information to sequence diagrams, but emphasize the structure of the system rather than the sequence of the messages. Links between objects should represent object associations. While numbered method calls on the links indicate the order in which the calls are expected to occur. Thus, the actual sequencing is not the main focus. Collaboration diagrams are not well suited for describing partial ordering of messages as a total ordering mechanism (numbered method calls) is used to show the ordering of messages.

They are not well suited either for describing asynchronous messages as sequence numbers are associated with the message rather than the message sending or receiving events. Finally, as the diagrams focus on system structure, long scenarios consisting of several tens of messages may become unreadable in a collaboration diagram (in the same way sequence diagrams may not be suitable to depict the way a large number of objects collaborate).

In most practitioner-oriented bibliography, it is common to find scenarios described along side of use cases. The precise relation between these two concepts is generally given quite informally. Authors have different views of what relationship exists between the scenarios and use cases. For example in [Texel and Williams 1997] use cases are considered “a statement of functionality required of the software” while a “scenario is a formatted description of the steps required for the completion of a use case”. According to Ivar Jacobson [Jacobson 1995], scenarios are use case instances; scenario describe interactions between objects while use cases describe interactions between different object models. In the context of UML [Jacobson et al

1999], a use case is a set of actions that a system performs that yields an observable result of value to a particular actor. On the other hand, a scenario is a sequence of actions that may not be observable to the system environment. In general, it is fair to say that use cases are considered more abstract and less detailed than scenarios. Thus, literature generally states that several scenarios can correspond to one use case, explaining the different ways the use case may develop in a finer grained description of the system. Use cases take an external system view

44 Chapter 2. Background separating actors from the system to be developed, and thus are a convenient mechanism for defining the system boundary. As a result, use cases do not, and should not according to

Jacobson [Jacobson 1995], reveal the internal architecture of the system to be developed.

Sequence diagrams, for instance are particularly well suited for the latter as they can describe how the different components within the system interact to provide the functionality being used in the use case.

2.5 Use Case Maps

Buhr and his group have developed a notation called Use Case Maps [Buhr 1998] (UCMs) that allow the description of scenarios at a more abstract level in terms of sequences of responsibilities over a set of components. UCMs do not model explicit inter-component communication as scenario notations such as sequence charts do. UCMs can be used as an abstract specification for the construction of MSC specifications [Bordeleau 1999]. In addition, it is possible to view use cases as a more abstract than use cases maps. While the former describe system functionality from an external point of view, without revealing information on the architecture of the system, UCMs do provide an abstract view of how the functionality flows through the different system components.

2.6 Summary and Discussion

In this section, we have provided an overview of scenario-based specifications. We have discussed scenarios in general, a particular notation for scenario called sequence charts , and within this notation, relevant aspects such as language features, semantics, and analysis. We have also discussed some prominent notations that are related to sequence charts in particular and scenario-based specifications in general.

We now present a short discussion explaining where the approach we present stands with respect to the background we have presented. A more detailed discussion on salient aspects of the approach is presented at the end of the thesis.

One of the aims of the approach presented in this thesis has been to develop techniques that can help elaborate scenario-based specifications. Consequently, we have chosen to focus on sequence charts that, in addition to being widely accepted, have the advantage over free text based scenario notations of being an intuitive, graphical representation that is amenable to computer processing. From the range of sequence chart notations that exist, we have taken a

Section 2.6 Summary and Discussion 45 minimalist approach, excluding advanced features such as queues, time delays, timeouts and deadlines, dynamic creation and termination of instances and data. Although there is benefit in extending the expressiveness of sequence charts, this mitigates against their simplicity and intuitiveness; features that have been crucial in the wide adoption of sequence chart notations in industry. In addition, as we demonstrate in this thesis, there is much benefit to be gained even when using a very basic sequence chart notation

The notion of scenario specifications as partial specifications is central to our choice of sequence chart semantics. If scenario specifications are partial, each scenario is simply an example of system execution. Thus, the notion of trace is central in the notation’s semantics.

Although we discuss in subsequent chapters state machines that provide the specified traces, scenarios do not specify these in a direct manner. Consequently, we have adopted a trace-based semantics. However, the notion of state machine is central to this thesis. As explained before scenario-based specifications can help elaborate behaviour models. In fact, studying the implications of constructing state-based formalisms that provide the traces specified in sequence diagrams is a key to driving the elaboration of both these behaviour models and scenario-based specifications.

From the different approaches to specifying the relation between sequence charts, the choice of not using state identification is the most important. State identification introduces the concept of system and component state, which may not be appropriate at initial stages of the scenario specification elaboration process. In addition, state identification would not be a consistent choice with respect to trace-based semantics. Ruling out state identification, has left us with a binary choice: sequence chart composition and triggers. We have chosen hMSCs, which have had a bigger impact in sequence chart approaches. However, the concepts and general framework we present are independent of this choice. As we describe further on implied scenarios arise independently of the choice of scenario integration constructs. The specific algorithms we present are, of course, dependent on the choice of hMSCs.

We have chosen to interpret messages as synchronous communication between instances for two main reasons. Firstly, asynchronous communication in sequence charts makes most kinds of analysis intractable. In particular checking the existence of implied scenarios, which is central to this thesis, in an asynchronous setting with hMSCs is undecidable. Secondly, bounded asynchronous communication can be modelled using synchronous communication and buffer abstractions.

In terms of analysis is where the major difference between our approach and existing ones arise.

In essence, the perspective that existing approaches to analysis of sequence chart specifications has been no different to those used in the analysis of specifications in general. Yet, there is a

46 Chapter 2. Background fundamental difference between scenario-based specifications and other approaches. Scenario specifications naturally result in partial descriptions. They depict a series of examples of what the system is expected to do. In the best of cases, these examples cover most common system behaviours and main exceptions. Expecting stakeholders to produce, in one go, a set of scenarios that cover all possible system traces is both unrealistic and impractical. Thus, existing analysis tools and techniques developed under the assumption of complete (or even relatively complete) specifications cannot tackle the partial nature of such specifications and support a basic question such as which are the gaps in the specification that could, if not elaborated, result in costly errors further on in the development process. This is the question we pursue when checking for implied scenarios. Implied scenarios drive the elaboration process we present in this thesis.

Chapter 3

Chapter 3 Specifying Positive Scenarios

In this section, we present a scenario-based language that we use throughout this thesis to specify intended system behaviour. We say that this language specifies positive scenarios to distinguish it from the scenario-based notation we introduce in a subsequent chapter for specifying behaviour that a system is expected not to exhibit; we refer to these scenarios as negative scenarios. In this chapter, we also introduce a toy system that we use to motivate and illustrate the definitions, algorithms and concepts we introduce throughout the thesis. The toy system is based on a Boiler Control system where a Control unit operates a Sensor and an

Actuator to control the pressure of a steam boiler. A Database is used as a repository to buffer

Sensor information while the Control unit performs calculations and sends commands to the

Actuator .

The language we introduce in this chapter is a syntactic subset of the International

Telecommunication Union (ITU) standard for message sequence charts [ITU 1996]. We use basic and high-level message sequence charts, but interpret them with a trace-based semantics and weak sequential composition.

3.1 Basic Message Sequence Charts

A basic message sequence chart (bMSC) describes a finite interaction between a set of components (see Analysis , Initialise , Register and Terminate in Figure 3.1). Each vertical arrow, called instance, represents a component. Each horizontal arrow represents a message, its source on one instance corresponds to a message output and its target on a different instance corresponds to a message input. We refer to message outputs and inputs as events. In addition, we use the term instance and component interchangeably. The formal definition of bMSCs is presented below. Note that a message label uniquely identifies the sending and a receiving component.

Definition 3.1 (Basic Message Sequence Charts) A basic message sequence chart (bMSC) is a structure b = ( E, L, I, M, instance, label, order ) where:

• E is a countable set of events that can be partitioned into a set of send and receive events that we denote send ( E ) and receive ( E ).

48 Chapter 3. Specifying Positive Scenarios

• L is a set of message labels. We use α ( b ) to denote L .

• I is a set of instance names.

• M : send ( E ) → receive ( E ) is a bijection that pairs send and receive events. We refer to the pairs in M as messages.

• instance : E → I maps every event to the instance on which the event occurs. Given i ∈ I , we denote { e ∈ E | instance ( e )= i } as i ( E ).

• label : E → L maps events to labels. We require for all ( e,e ’) ∈ M that label ( e )= label ( e '), and if ( v,v ’) ∈ M and label ( e )= label ( v ) then instance ( e )= instance ( v ) and instance ( e ')= instance ( v ’).

• order is a set of total orders ≤ i

⊆ i ( E ) × i ( E ) with i ∈ I and ≤ i

corresponding to the top-down ordering of events on instance i .

Time in bMSCs is represented top-down. This means that an event is considered to occur strictly after all the events that are further up on the same instance. We model this relation on each instance with the total ordering ≤ i

presented above. The temporal relation between events on different instances is given by the messages of the bMSC. Contrary to the ITU interpretation of messages, where asynchronous communication is assumed, we consider messages to be synchronous, i.e. message send and receive events are blocking 3 . Thus, send and receive events of the same message (( s,r ) ∈ M ) are considered to occur simultaneously. From the ordering of events on instances and the synchronisation of events given by messages, temporal relations between events on different instances can be inferred. For instance, the sending of message command on instance Control must occur after the sending of message data by Database .

However, not all events can be related temporally; for instance, we cannot infer a relation between the sending of command and the sending of the last pressure message. This means that we can define a partial ordering of events based on the ordering of events on instances and the synchronisation of events given by messages. The formal definition is as follows:

Definition 3.2 (Ordering of Events) Given a bMSC ( E, L, I, M, instance, label, order ) where order is the set of total orders ≤ i

, we define the pre-order p ⊆ E × E to be the reflexivetransitive closure of U i ∈ I

≤ i

∪ M ∪ M − 1 and the pre-order < ⊆ send ( E ) × send ( E ) to be the restriction of p to elements of send ( E ).

With this interpretation of time, we need to introduce the notion of valid bMSCs. Informally, a bMSC is valid when no message arrows cross each other and events are not superimposed at the

3 Note that the introduction of bounded asynchronous communication can be modelled by introducing buffer abstractions to decouple the message passing.

Section 3.1 Basic Message Sequence Charts 49 same point of an instance. This is equivalent to requiring that the pre-order < of a bMSC be a partial ordering of events. In the remainder of this thesis, we assume all bMSCs are valid.

Definition 3.3 (Valid bMSCs) A bMSC ( E, L, I, M, instance, label, order ) is valid only if its ordering of send events < is a partial order. In other words that e ’< e and e ’< e implies e’=e .

Initialise

Sensor Database on

Control Actuator

Register

Sensor Database pressure

Control Actuator

Analysis

Sensor Database query data

Control Actuator command

Initialise

Register

Terminate

Sensor Database off

Control Actuator

Analysis Terminate

Figure 3.1 – Positive MSC specification for a Boiler Control system

The semantics of a bMSC is given by a set of sequences of message labels or traces . The set is determined by its partial ordering of events. However, as send and receive events occur simultaneously, we can restrict the partial order to only send-events. In the case of Figure 1.1, the bMSC semantics determines a set of two traces (We denote traces between triangular brackets): ⟨ on, pressure, pressure, query, data, command, pressure, off ⟩ and ⟨ on, pressure, pressure, query, data, pressure, command, off ⟩ . Note that the difference between the two traces is that the command message and the last pressure message appear in different order. This is because their send events are not causally related in the scenario’s partial ordering of events.

According to the definitions, both must occur after the sending (and receiving) of message data but before sending (and receiving) message off .

Definition 3.4 (Linearisations) Let b = ( E, L, I, M, instance, label, order ) be a bMSC and < its partial ordering of events. In addition, Let label : E* → L* be an extension of label : E → L to words over E and L . A word v over the alphabet L is a linearisation of b only if there is a word w over E that is a total ordering that extends <, and label ( v ) = w .

Definition 3.5 (bMSC Semantics) Given a bMSC b , we define the language of b as a set L ( b ) of traces where L ( b ) = { w | w is a linearisation of b }.

Note that because all partial orders can be extended (under the assumption of the axiom of choice) to total orders, we have that a valid bMSCs has at least one linearisation.


3.2 High-level message sequence charts

A high-level MSC (hMSC) provides the means for composing bMSCs. It is a directed graph where nodes represent bMSCs and edges indicate their possible continuations (see bottom right of Figure 3.1). hMSCs also have an initial node, which is indicated using an arrow with a black filled circle as its tail. The ITU standard includes hMSCs and permits hierarchies by allowing nodes to refer to a new hMSC. To simplify this presentation we have omitted this feature; however, it could be introduced to our approach.

Definition 3.6 (High-level Message Sequence Charts) A high-level message sequence chart

(hMSC) is a graph of the form ( N, E, s o

) where N is a set of nodes, E ⊆ ( N × N ) is a set of edges, and s

0

∈ N is the initial node. We say that n is adjacent to n ’ if ( n, n ’) ∈ E . A (possibly infinite) sequence of nodes w = n

0

, n

1

, … is a path if n

0

= s

0

, and n i is adjacent to n i+1 for 0 ≤ i < | w |. We say a path is maximal if it is not a proper prefix of any other path.

3.3 Positive message sequence chart specifications

Positive MSC specifications consist of a set of bMSCs, an hMSC and a function that maps every node in the hMSC to a bMSC. For simplicity, we assume that all bMSCs have the same set of instances and that messages are used consistently throughout them. In addition, we assume the mapping from hMSC nodes to bMSCs to be bijective. Thus, several nodes referring to the same bMSC are represented with several copies of the same bMSC, and each node referring to an individual copy. This allows us to simplify by referring to bMSCs instead of the nodes that are mapped to them. All these assumptions help to simplify our presentation but could be dropped easily.

Definition 3.7 (Positive Message Sequence Chart Specifications) A positive message sequence chart (MSC) specification is a structure PSpec = ( B, H, f ) where B is a set of bMSCs,

H =( N, A, s

0

) is an hMSC, and f : N → B is a bijective function that maps hMSC nodes to bMSCs.

We use α ( PSpec ) = { l | ∃ b ∈ B .

l ∈α ( b )} to denote the alphabet of the specification.

The semantics of a positive MSC specification is given, as for bMSCs, by a set of traces. The hMSC together with the mapping of nodes to bMSCs shows how the system can evolve from one scenario to another. There are two possible interpretations of this evolution. The first is to assume that all components wait until all events of a bMSC have occurred before moving on to the next bMSC. This implies that there is an implicit synchronisation scheme used by components to know when a scenario has been completed. As MSCs are a notation for making

Section 3.3 Positive message sequence chart specifications 51 explicit how components interact to provide system level functionality, we take the position that assuming implicit synchronisation is not appropriate. We adopt the second and more accepted approach to hMSC semantics in which components move into subsequent scenarios in an unsynchronised fashion. This interpretation is referred to as using weak sequential composition, and is the one adopted by the ITU [ITU 1996] among others.

Definition 3.8 (Weak Sequential Composition of bMSCs) Let b = ( E, L, I, M, instance, label, order ) and b ’ = ( E ’ , L ’ , I ’ , M ’ , instance ’ , label ’ , order ’) be two bMSCs with disjoint sets of events. Their weak sequential composition of is denoted ( b • b ’) and is defined by the bMSC ( E

∪ E ’ , L ∪ L ’ , I ∪ I ’ , M ∪ M ’ , instance ∪ instance ’ , label ∪ label ’ , order

•

) where order

• is the set of total orders ≤ • i such that e ≤ • i

e ' if one of the following hold:

• e ≤ i

e '

• e ≤ ’ i

e '

• ( e ∈ i ( E ) and e ’ ∈ i ( E ’))

Additionally, we define sequential composition to be left associative. In other words that

( b • b’ • b’ ’) = (( b • b ’) • b’ ’).

Analysis Register

Sensor Database pressure query data

Control Actuator command

Figure 3.2 – Weak sequential composition of bMSCs Analysis and Register

For example, the bMSCs Analysis • Register (see Figure 3.2) determines two possible traces:

⟨ query, data, command, pressure ⟩ and ⟨ query, data, pressure, command ⟩ . Note that in the latter, even though pressure is from the second bMSC of the sequential composition, it occurs before command, which is from the first bMSC of the sequential composition. This occurs because message pressure is independent of command, i.e. there is no causal relation between the send events of these messages in ( Analysis • Register ). This is not surprising as the messages involve different components, and as there are no explicit synchronisation mechanisms to enforce a particular ordering of these messages, any interleaving can occur. If strong sequential composition semantics were used, command would be forced to occur before pressure . As explained before, we consider this interpretation inappropriate, as it would assume an implicit synchronisation between components.

Note that the weak sequential composition of valid bMSCs is always a valid bMSC. This is because a) the union of countable sets is countable, b) ≤ • i can be proven to be total orderings straightforwardly, and c) the pre-order <

•

of send events is a partial order. Item c) can be proven

52 Chapter 3. Specifying Positive Scenarios by assuming that e ’<

• e, e ’<

• e , and e’= e . If e’ and e are events of the same bMSC, then we have a contradiction because the composed bMSCs are assumed to be valid. If not then there must be a message from an event in the second bMSC to an event in the first bMSC. This cannot be so according to the definition of sequential composition.

Although the sequential composition of two bMSCs with infinitely countable events is a valid bMSC, it does yield a counter-intuitive bMSC. Suppose we have A and B bMSCs with infinitely many events. The bMSC ( A • B ) has linearisations of the form w

A

.w

B

where both w

A

and w

B

are infinitely long. These linearisations are counter-intuitive because the w

B

part of the linearisation would never be reached in an execution of the system. This situation arises because the events in the composite bMSC cannot be enumerated in the same order as its linearisations. The elements of the composite bMSC can be enumerated by assigning odd numbers to the elements of the first bMSC and even numbers to the elements of the second. However, this enumeration would not be a total ordering that extends the partial order of the composite bMSC.

Nonetheless, the situation described above does not occur in the setting of MSC semantics we use. As we define below, all sequential compositions are made over a first parameter that has a finite number of events.

We now define the semantics of positive MSC specification. The traces defined by a positive

MSC specification are those of any sequential composition of bMSCs according to a maximal path in the specification’s hMSC.

Definition 3.9 (Maximal bMSCs) Let PSpec = ( B, H, f ) be a positive MSC specification. We say that a b is a maximal bMSC in PSpec if there is a maximal path n

1

, n

2

, … in H such that b = f ( n

1

) • f ( n

2

) • …. Note that renaming of events of f ( n i

) may be necessary if the hMSC defines cycles.

Definition 3.10 (Positive MSC Specification Semantics) Let PSpec be a positive MSC specification with a set of instances I . We define the behaviour or language of PSpec as a set

L ( PSpec ) of traces, where L ( PSpec ) = { w ∈ L ( b ) | b is a maximal bMSC of PSpec }.

Note that the semantics we use is trace-based. This differs from many other approaches that use state-machine-based semantics (for example, the ITU approach [ITU 1996]). We discuss the significance of this difference in the Discussion chapter.

Section 3.4 Discussion 53

3.4 Discussion

The notation we use to describe the positive part of MSC specifications is a syntactic subset of that of the International Telecommunication Union standard Z.120 for MSCs [ITU 1996].

However, in terms of the semantics there is a significant difference. The ITU standard adopts a state-based semantics, where every MSC specification is considered to determine a state machine. In contrast, we adopt a trace-based semantics; meaning that the hMSC together with its bMSCs determine a set of system traces for which many state machines could be built.

However, we do coincide with the ITU and others (e.g. [Rudolph et al 1996]) in the use of weak sequential composition.

In addition to the ITU, many authors consider scenario-based specifications from a state-based semantic perspective (e.g. [Reniers 1999, Rudolph et al 1996]). The rationale is that scenariobased specifications can be used to describe the high-level design of system components, that they are design documents in their own right. This design-oriented or late-requirements perspective tends to support the transition from scenario-based notations to traditional design notations and techniques more easily. This design oriented perspective is also taken by approaches that use synthesis as the primary source of describing scenario semantics (e.g.

[Krüger et al 1999] [Somé et al 1995] [Koskimies et al 1998, Whittle and Schumann 2000]. In contrast, we believe that scenario-based specifications are particularly well suited for providing partial descriptions of the intended system behaviour. Consequently, we interpret scenario specifications as describing system functionality, not design. However, we do also study the implications of trying to build state-based models that provide the set of specified traces. Many informal approaches to scenarios (e.g. [Carroll 1995]) also consider scenarios to be examples of system behaviour rather than design documents. They envisage the use of scenarios very early in the requirements process. This is also true for other approaches based on trace semantics such as [Alur et al 2000, Ben-Abdhallah and Leue 1997b, Katoen and Lambert 1998].

In [Uchitel and Kramer 2001] we pursued a different line of work. We studied scenario-based specifications from a more design-oriented perspective using state machine based semantics.

The algorithm presented in this paper is a simplified version of the one presented there. The main difference is that in this setting we do not have to deal with state labels. Although the version in [Uchitel and Kramer 2001] can be used in the current approach, the algorithm presented here produces clearer FSP code.


3.5 Summary

This chapter presents a notation for documenting positive scenarios. By positive scenarios, we refer to examples of intended system behaviour. The notation is a syntactic subset of the ITU message sequence chart (MSC) standard [ITU 1996], including basic and high-level MSC. The semantics for the notation is defined in terms of sequences of messages, or traces, using weak sequential composition of basic MSCs. In later chapters of this thesis, we extend the language to include negative scenarios for describing behaviour that a system is expected not to exhibit. In terms of the overview of Section 1.4, we have introduced the highlighted parts of the diagram below.

Positive

Scenarios

( PSpec )

Negative

Scenarios

( NSpec )

Architecture

Traces

( L(PSpec)

)

Traces

( L(PSpec)

)

Traces

( L(NSpec)

)

Positive or Negative Scenario

Architecture Model

Synthesis


L ( PSpec ) ⊆ mt ( A ) A = ( A

1

L A n

)

Trace Model

Synthesis

Constraint Model

Synthesis


(



Implied Scenario ( i ) i ∈ ( mt ( A ) \ L ( PSpec ) \ L ( NSpec ))

Figure 3.3 – Elements of the detailed overview of Section 1.4 discussed in Chapter 3

Chapter 4

Chapter 4 Behaviour Models

In the previous chapter, we presented a sequence chart based language for describing intended system behaviour. However, sequence chart notations not only describe system traces, they also outline the high-level architecture of the system being described. They depict in a very clear manner, which are the system components that are involved in providing the intended system behaviour and which messages they are capable of sending and receiving. This notion of architecture associated with sequence chart based specifications motivates studying system models that preserve the architecture associated with a sequence chart based specification and that provide the specified system behaviour. In this chapter, we discuss the construction of such models. To do so, we first introduce labelled transitions systems (LTSs), which we use to model component and system behaviour; we then introduce FSP which is a textual notation for describing LTSs, and then go on to introduce architecture behaviour models and algorithms for building them.

4.1 Labelled Transition Systems

We now present labelled transitions systems (LTS) [Keller 1976], which is the formalism we use to model system and component behaviour. LTSs have been widely used for specifying and analysing distributed systems [Clarke et al 1989, Ghezzi et al 1991, Magee et al 1997,

Rabinovich 1992]. A LTS is a state transition system where transitions are labelled. We use a

LTS to model each component of a MSC specification and use transitions labels to model the messages components send and receive. In addition, we use an operation on LTS called parallel composition (based on the || composition operator used in CSP [Hoare 1985]) to model the system that results from composing components such that they execute asynchronously but synchronize on all shared message labels. Besides defining LTSs and parallel composition, we present some additional operators on and properties of labelled transitions systems that are used in the remainder of this thesis. The definitions of this section have been adapted from [Cheung

1994] and [Giannakopoulou 1999]. Main differences are the result of introducing successful termination states.

Definition 4.1 (States and Labels) We define States as the universal set of states where states π and ε are designated as the error and end states. We define Labels as the universal set of

56 Chapter 4. Behaviour Models message labels and Labels

τ

= Labels ∪ { τ } where τ is denote an internal component action that is unobservable to other components.

Definition 4.2 (Labelled Transition Systems) A LTS P is a structure ( S , L , ∆ , q ) where

• S ⊆ States is a finite set of states.

• L = α ( P ) ∪ { τ } where α ( P ) ⊆ Labels is a set of labels that denotes the communicating alphabet of P .

• ∆ ⊆ ( S \{ π , ε } × L × S ) defines the labelled transitions between states, and

• q ∈ S is the initial state.

The LTS that has π as its only state - ({ π }, Labels

τ

, {}, π ) – is referred to as the error LTS, denoted Π . LTSs of the form P =({ ε }, L ,{}, ε ) is referred to as successfully terminated LTSs, denoted Σ

L

. We say that a LTS P is deterministic if there are no transitions labelled with τ and

( s , l , s

1

) ∈ ∆ .

and ( s , l , s

2

) ∈ ∆ implies s

1

= s

2

, otherwise it is non-deterministic. In addition we say that a label l is enabled in a state s if there is a state s ' such that ( s , l , s ' ) ∈ ∆ .

As an example, consider the following LTS that models the Database component: Database :

({0, 1, 2}, { pressure , query , data }, {(0, pressure , 1), (1, pressure , 1), (1, query , 2), (2, data ,

0)}, 0). Figure 4.1 represents this LTS graphically. Note that the numbers depicted in states have no particular meaning; they are simply references that permit referencing to states, facilitating explanations involving the LTS. The convention used in our diagrams is that states are numbered with integers, where zero identifies the initial state.

Note that the definition of LTS includes a special message label τ , and two special states π and

ε . The label τ is not used in the example of above; it models an internal action that is not observable to other LTSs. The fact that this label is not observable becomes relevant when composing several LTS and forcing them to synchronise on shared labels. States π and ε model an error state and an end state respectively. Note that no transitions originate from these states.

We discuss them in depth when we explain how to detect implied scenarios in Chapter 6.

Returning to the LTS of the Database component, we now follow its transitions from the initial state to explain the behaviour that it models. Starting in state 0, the Database and can only perform one action: it can interact with its environment through message pressure and then move to state 1. In state 1, the Database has a choice, it can do query and move to state 2, or do pressure and remain in state 1. Finally, when in state 2, the Database can return to the initial state by performing data .

Section 4.1 Labelled Transition Systems 57

0 pressure

1 query pressure

2 data

Figure 4.1 – Component model for Database

Thus, by following a path of transitions in the LTS we are exploring one of the behaviours that the LTS models. An execution of the LTS is a sequence of states and transition labels that can be followed in a LTS. Executions are denoted between triangular brackets for clarity. Thus, an example of an execution of the Database LTS is ⟨ 0, pressure , 1, pressure , 1, query , 2, data , 0, pressure , 1 ⟩ . However, we are particularly interested in maximal executions, in other words executions that cannot be extended any further. In the case of the Database LTS, all maximal executions are infinitely long. However, this is not always the case: if a LTS has a state with no enabled transitions, then it has some finite maximal executions.

Definition 4.3 (Executions) Let P = ( S , L , ∆ , q ) be a LTS. An execution of P is a sequence w = q

0 l

0 q

1 l

1

…of states q i

and labels l i

∈ L such that q

0

= q and q i q i+1

for all 0 ≤ i <| w / 2 |.

An execution is maximal if it is not a proper prefix of another execution. We also define ex ( P ) = { w | w is an execution of P }. An execution is terminating if it reaches an end state, and an LTS is terminating if it has a terminating execution. An LTS is called a terminating LTS if it has a terminating execution.

Executions reveal part of the structure of a LTS: its states. However, given a LTS we want to compare it with traces described by a scenario-based specification. Thus, we introduce the notion of trace that is essentially the visible phenomena of an execution. A trace of a LTS is a sequence of observable labels such that can be produced by an execution of the LTS. For example ⟨ pressure , pressure , query , data , pressure ⟩ is a trace of the LTS in Figure 4.1.

To define trace, we introduce the notion of projection of a word over a given alphabet, where a word is essentially a sequence and an alphabet is a set of elements from which words can be build.

Definition 4.4 (Projection) Let w be a word w

0 w

1 w

2 w

3

…and A an alphabet. The projection of w onto A , which we denote w |

A

, is the result of eliminating from the word w all elements w i such that w i

∉ A .

Definition 4.5 (Traces) Let P be a LTS. A word w over the alphabet α ( P ) is a trace of P is there is an execution w ' of P such that w = w '|

α (P)

. Note that traces do not include τ actions. We also define tr ( P ) = { w | w is a trace of P }.

58 Chapter 4. Behaviour Models

The notion of trace is not entirely adequate for comparing LTSs with the behaviour described by a MSC specification. Recall that the behaviour specified by the latter is in terms of linearisations that include all the messages of a maximal bMSC. For example, the sequence on, pressure, query is not a trace specified by the specification of Figure 3.1. In fact, there is no finite sequence of events in the set of specified traces of the MSC in Figure 3.1. This interpretation of MSCs does not fit well with traces in the setting of LTSs, which do not have to be maximal executions. Consequently, we introduce the notion of a maximal trace.

Definition 4.6 (Maximal Traces) Let P be a LTS. A word w over the alphabet α ( P ) is a maximal trace of P is there is a maximal execution w ' of P such that w = w '|

α (P)

. We also define mt ( P ) = { w | w is a maximal trace of P }.

Note that a maximal traces are not traces that cannot be extended; they are traces that are the result of maximal execution of a LTS. Thus, maximal traces are either infinite or lead to states that have no enabled transitions. We denote traces of LTS in the same way we do for traces defined by MSC specifications, between triangular brackets.

4.1.1 Parallel Composition

To model systems that are the result of several components interacting, we introduce the parallel composition operator. Given two LTSs P

1

and P

2

, we denote P

1

|| P

2

the LTS that models their joint behaviour. The joint behaviour is the result of both LTSs executing asynchronously but synchronising on all shared message labels. This means that any of the two LTSs can perform a transition independently of the other LTS, so long as the transition label is not shared with the alphabet of the other LTS. Shared observable labels have to be performed simultaneously.

Observability of labels signifies that the LTSs never synchronise on τ since they represent internal behaviour. When considering error and successfully terminated LTSs, parallel composition works slightly differently. Composing an error LTS with any other LTS results in an error LTS, this models that failure of one process signifies the failure of the system as a whole, and is used, as we show further on, for model checking if LTSs verify safety properties.

Finally, successful termination of a parallel composition depends on the successful termination of all terminating LTSs. The parallel composition operator has only one restriction, if a terminating process is composed with a non-terminating one, the alphabet of the former must include the alphabet of the latter. This restriction is in concordance with [Hoare 1985]. Note that the definition below can be extended easily to parallel composition of an arbitrary number of processes: P

1

||…|| P n

.


Definition 4.7 (Transits) A LTS P = ( S , L , ∆ , q ) transits with a label l into an LTS P ', denoted as P → P ’, if:

• P ' = ( S , L , ∆ , q ') where q ' ≠π , q ' ≠ε and ( q, l, q ) ∈ ∆ , or

• P '= Π , and ( q, l, π ) ∈ ∆ , or

• P '= Σ

L

, and ( q, l, ε ) ∈ ∆ .

The transit relation can be extended naturally to a sequences of labels w=w

1

…w n by defining P

1

P n+1

to hold if there are P i

such that P i

 → P i+1

. In addition, we define

P →

•

P ’ if there is a sequence w ’ such that w ’|

α (P)

= w and P → P ’.

Definition 4.8 (Parallel Composition of LTS) Let P

1

and P

2

be LTSs where P i

= ( S i

, L i

, ∆ i

, q i

).

Their parallel composition is denoted P

1

|| P

2

and is defined if P i

is terminating and P j

is nonterminating implies α ( P j

) ⊆α ( P i

). The parallel composition P

1

|| P

2

returns an LTS as follows:

• If P

1

= Π or P

2

= Π , then P

1

|| P

2

= Π

• If P i

≠Π , P i

is terminating implies P i

= Σ

L i

then P

1

|| P

2

= Σ

L 1

∪ L 2

• If P i

≠Π , then P

1

|| P

2

is an LTS ( S

1

× S

2

, L

1

∪ L

2

, ∆ , ( q

1

, q

2

)) where ∆ is the smallest relation that satisfies:

P

1

P

1

|| P

2

 l

 l

P

1

′

P

1

′ || P

2

( l ∉ α ( P

2

))

P

1

P

2

|| P

2

 l

 l

P

2

′

P

1

|| P

2

′

( l ∉ α ( P

1

))

P

1

P

1 l

|| P

2

P

1

′ l

P

2

P

1

′ || l

P

2

′

P

2

′

( l ≠ τ )

To illustrate parallel composition, consider the LTS of Figure 4.14. This LTS corresponds to a possible model for the Control component. If we compose this LTS with that of the Database component described previously we obtain an LTS ( Database || Control ) with the following state space: {(0, 0), (0,1), (0,2), (0,3), (0,4), (1,0), (1,1), (1,2), (1,3), (1,4), (2,0), (2,1), (2,2),

(2,3), (2,4)}. The shared labels of both LTS are query and data , thus all other transition labels can be executed independently by each LTS. For this reason, from the initial state (0, 0), Control could do start and take the composite LTS to state (0, 1) or Database could do pressure and take the composite LTS to state (1, 0). However, in state (1, 3) Database cannot perform query , because Control can only perform command in state 3. Thus, the Database has to wait for

Control to perform command so the composite state is (1, 1) and then both LTS can move simultaneously to (2, 2). The graphical representation of ( Database || Control )


on query data

0 1 2 3

off command

Figure 4.2 – Component model for Control

Figure 4.3 depicts the parallel composition of Database and Control . States {0, 1, 2, 3, 4, 5, 6} represent the composite states {(0,0), (1,0), (1,1), (2,2), (0,3), (1,3), (0,1)}. Several composite states have not been depicted, as they are not reachable from the initial state. on

0 pressure on query data

1 pressure

2 off pressure

3 4 command pressure off

Figure 4.3 – LTS for (Database||Control) command pressure

5 pressure

6

The set of traces of the LTS resulting from a parallel composition has some interesting properties with respect to the traces of the composed LTSs (which are discussed in [Hoare

1985]). For example, if the composed processes have the same alphabet, then the set of traces of their parallel composition is the intersection of their individual set of traces.

Property 4.1 Let P and Q be LTSs, if α ( P )= α ( Q ) then tr ( P || Q )= tr ( P ) ∩ tr ( Q ).

A more general property that implies the one above is the following (note we use “*” to denote the operation that given a set of symbols produces the set of all strings over the symbols of the set).

Property 4.2 Given P and Q LTSs, we have that tr ( P || Q )={ w ∈ A* | w |

α (P)

∈ tr ( P ) and w |

α (Q)

∈ tr ( Q )} where A=( α ( P ) ∪α ( Q )).


4.1.2 Hiding

An operation that we use during the process of construction LTS to model the system described by a scenario-based specification is that of hiding . Hiding a label in a LTS makes all transitions with that label unobservable to the environment of the LTS. Thus, given an LTS P , and a set of observable actions A , the hiding of A in P denoted P \ A is obtained from P by substituting all transitions labelled with actions in A with τ transitions. For example, we may want to hide message labels data and query from the LTS ( Database || Control ) to avoid other LTSs from synchronising on them and to simplify the composite LTS. The result is shown in Figure 4.3 where transitions labelled “tau” represent τ transitions.

on pressure on tau tau command pressure

0 1 pressure

2 off pressure

3 4 command pressure off

Figure 4.4 – LTS for (Database||Control)/{data, query}

5 pressure

6

Definition 4.9 (Hiding) The hiding of a set of labels A in a LTSs P = ( S, L, ∆ , q ) is denoted P \ A and is defined by the LTS ( S, L \ A, ∆ ’ , q ) where ∆ ’ is the smallest relation satisfying the rules:

P

P

 l

τ

P ′

P ′

( l ∈ A )

P  l

P  l

P ′

P ′

( l ∉ A )

4.1.3 Equivalences

Throughout the thesis we compare different LTSs to see if the behaviour they model is the same. Various notions of equivalence can be used to compare LTSs, including strong and weak equivalence [Milner 1989] and trace and failures-divergence equivalence [Hoare 1985]. In the context of this thesis, we use two different equivalences. The first is trace equivalence , where two LTSs are considered equivalent if they are capable of producing the same set of traces. We use this to compare different LTSs that provide the behaviour specified in a MSC specification.

Note that the fact that a state is an error or end states is not relevant in the definitions of these equivalences.


Definition 4.10 (Trace equivalence) Given two LTSs P and Q , we say that they are trace equivalent if tr ( P ) = tr ( Q ).

An example of trace equivalent LTSs is shown subsequently. In this case, both LTS have the set of trace {< a,b >, < a, c >}. Note that a transitions labelled with a set of traces is simply a compact way of depicting a set of transitions where each one is labelled with an element of the set. a {b, c}

0 1 2 a a c

0 1 2 b

Figure 4.5 – Trace equivalent LTSs

3

Note that two trace equivalent LTSs P and Q , are do not always have the same set of maximal traces. In other words tr ( P ) = tr ( Q ) does not imply mt ( P ) = mt ( Q ).

The second equivalence is used in the context of some of the proofs of this thesis. It is a much stronger equivalence relation than that of trace equivalence, and as such, it preserves many behavioural properties.

Definition 4.11 (Strong Semantic Equivalence) Given a LTS ( S, L, ∆ , q ), the strong equivalence “~” is the union of all relations R ⊆ S × S satisfying that if ( s, t ) ∈ R then

• ( s, a, s ’) ∈∆ implies ∃ t ’. ( t, a, t ’) ∈∆ and ( s ’ , t ’) ∈ R

• ( t, a, t ’) ∈∆ implies ∃ s ’. ( s, a, s ’) ∈∆ and ( s ’ , t ’) ∈ R

• s = π iff t = π

• s = ε iff t = ε

In particular, strong equivalence is a congruence [Milner 1989], which means that the following properties hold:

Property 4.3 Given a LTSs P, Q, R , and a set of labels A, the following properties of strong semantic equivalence hold:

• If P ~Q then ( P || R )~( Q || R )

• If P ~Q then ( P \ A )~( Q \ A )


Throughout this thesis we say that a LTS P is minimal with respect to equivalence relation E if it there is no LTSs in its equivalence class that has the fewer states. For example the LTSs on the top of Figure 4.5 is the minimal LTS with respect to trace equivalence in the equivalence class that contains the LTS on the bottom of Figure 4.5. Minimising P with respect to E is the process of constructing a minimal LTS Q with respect to E such that P and Q ’ are equivalent

(with respect to E).

4.1.4 Describing LTSs with FSP

Up to now, we have discussed LTSs and defined them either graphically or by giving their states, alphabet, transitions and initial state. Although these representations work well for LTSs with few states, they become impractical when defining larger LTSs. For this reason, Magee et al have proposed a simple process algebra notation called Finite State Processes (FSP) to textually specify LTSs [Magee et al 1997, Magee et al 1998]. In addition, they have built the

Labelled Transition System Analyser (LTSA) tool [Magee and Kramer 1999] that inputs FSP code to produce and analyse LTSs.

FSP is a specification language with well-defined semantics in terms of LTSs, which provides a concise way of describing LTSs. Each FSP expression E can be mapped onto a finite LTS, we use lts ( E ) to denote the LTS that corresponds to it. We now discuss briefly the syntax of FSP.

An example of the FSP code that could be written for the Database component is as in Figure

4.6. In FSP, process names start with uppercase letters and actions start with lowercase ones.

The code for the Database defines a FSP processes called

Database

and an auxiliary process

ReadyForQuery

. Auxiliary processes are local to the FSP process in which they have been defined. Database is defined using the action prefix operator “

->

” and recursion. The process is defined to start by doing pressure

and then becoming local process

ReadyForQuery

.

ReadyForQuery

, introduces the choice operator “

|

” and is defined to do pressure

and return to being

ReadyForQuery,

or to do data

followed by query

and then become the

Database

process.

Database = (pressure -> ReadyForQuery),

ReadyForQuery = (pressure -> ReadyForQuery

| data -> query-> Database).

Figure 4.6 – FSP for Database

Processes can also reach a state where no further actions are possible. This is specified in FSP using the process keyword

END

and corresponds to the successful termination LTS Σ . Thus, the

64 Chapter 4. Behaviour Models process

OneQuery = (pressure -> data -> query -> END)

defines the LTS of

Figure 4.7. pressure data query

0 1 2 E

Figure 4.7 – LTS with and END state

A process with an

END

state can be sequentially compose with an auxiliary process by using the sequential composition operator: “

;

”. Thus, the FSP code below defines the LTS depicted in

Figure 4.9.

SeveralQueries = (OneQuery;Reset),

Reset = (reset -> OneQuery_DB).

Figure 4.8 – FSP for process SeveralQueries pressure data query

0 1 2 3 reset

Figure 4.9 – LTS for SeveralQueries illustrating sequential composition in FSP

There is another composition operator in FSP: the parallel composition operator. This operator, which is denoted “

||

” is defined with to preserve the semantics of LTS parallel composition.

Thus, given two FSP processes P and Q, we have: lts (

P||Q

) = lts (

P

)|| lts (

Q

).

In FSP processes that are defined by composing two non-auxiliary processes are called composite and their names are prefixed with

||

. Thus the parallel composition of the FSP processes for the Database and Control components is

||DB_Ctrl =

(Database||Control)

.

In addition, FSP also has a hiding operator denoted “\” which preserves the semantics of the

LTS hiding operator. Thus, to specify the LTS of Figure 4.4 the correct FSP code is

||DB_Ctrl = (Database||Control)\{data, query}

.

Finally, FSP has two keywords that are used just before the definition of a process and that force LTSA to perform a complex operation on the process. The first keyword, minimal, makes LTSA construct the minimal LTS with respect to strong semantic equivalence; the second, d eterministic

, makes LTSA construct the minimal LTS with respect to trace

Section 4.2 System Architecture 65 equivalence. If there are no traces leading to

END

states that are proper prefixes of other traces, then d eterministic

preserves

END

states. This means that a trace in the original process leads to an

END

state if and only if the trace leads to an

END

state in the determinised process.

Summary of FSP

If x

and y

range over actions, and

P

and

Q

range over FSP processes. FSP introduces the following operators:

• Action prefix “

->

”:

(x->P)

describes a process that initially engages in the action x and then behaves as described by the auxiliary process

P

.

• Choice “

|

”:

(x->P|y->Q)

describes a process which initially engages in either x

or y

, and whose subsequent behaviour is described by auxiliary processes

P

or

Q

, respectively.

• Recursion : the behaviour of a process may be defined in terms of itself, in order to express repetition.

• End state “

END

”: describes a process that has terminated successfully and cannot perform any more actions.

• Sequential composition “

;

”:

(P;Q)

where

P

is a process with an

END

state, describes a process that behaves as P and when it reaches the

END

state of

P

starts behaving as the auxiliary process

Q

.

• Parallel composition “

||

”:

(P||Q)

describes the parallel composition of processes

P and

Q

.

• Trace equivalence minimisation “ deterministic

”: deterministic P describes the minimal trace equivalent process to

P.

If no terminating traces are proper prefixes of other traces, then it also preserves

END states.

• Strong semantic equivalence minimisation “ minimal

”: minimal P

describes the minimal strong semantic equivalent process to

P

.

In the previous chapter, we have defined a positive MSC language and discussed its trace semantics: given a positive MSC specification PSpec we have defined its semantics in terms of the language or set of traces it defines; which we denote L ( PSpec ). We now define three more concepts associated with the meaning of a positive MSC specification: system architecture, component interfaces and component structure. Subsequently, we describe how to build LTS

66 Chapter 4. Behaviour Models models that comply with both the trace semantics of a positive MSC specification and the architectural aspects it defines.

By component structure of a positive specification PSpec we refer to the components that appear as instances in any bMSC of PSpec . Thus, the component structure of the Boiler Control system, according to Figure 3.1, is a set of four components: Control , Sensor , Database and

Actuator .

Definition 4.12 (Component Structure) Let PSpec = ( B , H , f ) be a positive MSC specification.

The component structure of PSpec denoted comp ( PSpec ) is the set { i | ∃ b = ( E , L , I , M , instance , label , order ) ∈ B and i ∈ I }. We say that c is a component of PSpec if c ∈ comp ( PSpec ).

Given a component c of PSpec , the interface of c is the set of message labels determined by the send and receive events of the specification that occur on an instance of that component.

Definition 4.13 (Component Interfaces) Let PSpec = ( B , H , f ) be a positive MSC specification and let c be a component of Spec . The interface of c is the set of message labels α ( c ) = { l | ∃ b =

( E , L , I , M , instance , label , order ) ∈ B and ∃ e ∈ E such that label ( e ) = l and instance ( e ) = c }. We also refer to the interface of c as its alphabet.

In the Boiler Control system, the alphabets of its four components are: α ( Sensor )={ pressure, on, off }, α ( Database )={ data, query, pressure }, α ( Control )={ on, off, query, data, command }, and α ( Actuator )={ command }. Note that in the definition of component interface we do not distinguish between message labels corresponding send-events from those corresponding to receive-events. Although the definition could be changed easily to make such distinction, in principle this is not necessary: from a behavioural point of view, as we consider messages in bMSCs to model synchronous communication, a distinction between sending and receive events is not needed.

Having defined the component structure of a positive MSC specification and the interface of a component, we now define system architecture:

Definition 4.14 (System architecture) The system architecture defined by a positive MSC specification is the specification’s component structure and the interface of each of its components.

Section 4.3 Architecture Models 67

Having defined our modelling formalism, we are now ready to introduce the notion of architecture model. As commented before, we wish to build a model that complies with the description given by a positive MSC specification. This means building a model that takes into account both the architecture and the behaviour described by the MSC specification. Thus, the model should be the parallel composition of a collection of LTSs, where each LTS models a component in the MSC specification. Furthermore, the LTS modelling a component of the MSC specification should have its corresponding interface, which means that the alphabet of the LTS should coincide with that of the component it models. Finally, the composite system model should be able to exhibit all the traces described in the MSC specification. We define architecture models those LTS models that preserve the component structure and component interfaces while exhibiting all specified traces.

Definition 4.15 (Architecture models) Let PSpec =( B , H , f ) be a positive MSC specification and let A i

be LTSs with i a component in comp ( PSpec ). We say that an LTS A is an architecture model of PSpec only if A =( A

1

||…|| A n

), α ( A i

) = α ( i ), and L ( PSpec ) ⊆ mt ( A ).

For the Boiler Control system, an architecture model is one that is the result of composing in parallel four LTSs. One with alphabet with { pressure, on, off } modelling the Sensor component, another with alphabet { data, query, pressure } modelling the Database component, a third modelling the Control component with alphabet { on, off, query, data, command } and a fourth model for the Actuator component with alphabet { command }. In addition, all traces defined by the semantics of the MSC specification must be traces of the composition of these four LTSs.

The notion of architecture model is weak in that it permits additional unspecified behaviour.

This interpretation is consistent with the fact that scenario specifications are partial descriptions, where typically only a subset of significant system traces has been explicitly specified. In addition, as we show further on, strengthening the condition L ( PSpec ) ⊆ mt ( A ) to L ( PSpec ) = mt ( A ) would result in MSC specifications with no architecture models.

4.3.1 Synthesis of Architecture Models

We now discuss how architecture models are built from MSC specifications. In particular, we describe the algorithm of Figure 4.10, which can be used to build component models, i.e. a LTS for a component specified in a positive MSC specification. If all component models are built

68 Chapter 4. Behaviour Models using this algorithm, their parallel composition can be shown to be an architecture model of the

MSC specification.

The algorithm works by translating a positive MSC specification into a behaviour model specification in FSP. Using LTSA, a graphical representation of the LTS for each component can be built (most LTS figures in this thesis have been generated by LTSA), and build the interleaved model resulting from their parallel composition. In addition, LTSA can be used to animate the model or rigorously check if it satisfies certain properties, in particular we use it to check for the existence of implied scenarios.

The algorithm synthesises one component model at a time. We illustrate it by explaining how it builds the FSP code for the Control component of the Boiler Control system. void SynthesiseComponent(Specification S, Component c) {

print “\\-----” + c.name()+ “-----“;

\\ Get component behaviour in all bMSCs

ForEach bMSC b in S.getbMSCs() print c.name() + “_” + b.name() + “ = ” + getBehaviour(c, b);

\\ Link behaviour according to hMSC

print “HMSC_” + c.name()+ “ = ” + S.gethMSC().getInitialNode().id();

\\ first map nodes to behaviour and to their adjacent nodes

ForEach Node n in S.gethMSC().getNodes() b = S.gethMSCs().map(n); string nodes_behaviour = c.name() + “_” + b.name(); print n.id() + “=” + nodes_behaviour + “;” + n.id() + “_Adj”;

\\ second connect nodes according to hMSC arcs

ForEach Node n in S.gethMSC().getNodes() print n.id() + “_Adj) = (” + getAdjacent(n, S.gethMSC()) + “)”;

\\ Determinise, minimise and hide internal actions.

print “deterministic ”+ c.name() +“ = HMSC_”+c.name()+“/{intAction}.”;

}

String getBehaviour(Component c, bMSC b) {

String s;

Instance i = b.getInstance(c);

for (int a = 0 ; a < i.size() ; a++) s = s + i.getEvent(a).label() + “->”;

s = s + “END”;

return s;

}

String getAdjacent(Node n, hMSC H)

String s;

if (H.getAdjacents(n) = 0) s = “END”;

else ForEach Node m in H.getAdjacents(n) s = s + “ intAction -> ” + n.id() + “|”;

return s;

}

Figure 4.10 – Architecture model synthesis algorithm

Given a positive MSC specification and a component to be synthesised, the algorithm constructs an FSP process that has the same traces as the projection of the MSC behaviour onto the alphabet of the component. First, the algorithm builds one FSP process for each bMSC in the

Section 4.3 Architecture Models 69 specification. Each of these processes exhibits the same behaviour as exhibited by the component in the bMSC. For instance, the algorithm builds the following FSP code to model the behaviour of the Control component in bMSC Analysis :

Control_Analysis =

(query -> data -> command -> END)

. This FSP process specifies the LTS of Figure

4.11. query data command

0 1 2 E

Figure 4.11 – Behaviour of Control component in bMSC Analysis

As one process for each bMSC is built, the algorithm must combine all these processes to model the behaviour of the component as it traverses bMSCs according to the hMSC. Thus, the second step of the algorithm is to build a process that models the behaviour defined by the hMSC. In the case of the Control component, this process is called “

HMSC_Control

”. In order to generate a more comprehensible FSP output, we build such process by defining several auxiliary processes. We build two auxiliary processes per hMSC node. One is used to model the mapping from hMSC nodes to bMSCs; the other is used to model the possible continuations of the node according its adjacent nodes in the hMSC. When synthesising the Control component, if we assume that the node referencing bMSC Analysis and Register have node id numbers 2 and 1, then the sub-processes that are built for node 2 are:

N2 =

Control_Analysis;N2_Adj and

N2_Adj = (intAction->N1).

The first of these processes describes node 2 as behaving as in

Control_Analysis and then continuing as described in

N2_Adj

. The second process describes node 2 as having node 1 as its only continuation. Thus, when the Control is at

N2

, it behaves as described in

Control_Analysis

and then goes on to

N1.

To initialise the component correctly, we define

HMSC_Control

to start as the initial node of the hMSC (

N0

). Note that we use intAction

to introduce choices when a node has several adjacent nodes in the hMSC. For example, process

N1_Adj

is defined as

(intAction -> N1 | intAction -> N2 | intAction -> N3) because

N1

has three adjacent nodes. Subsequently, we hide the label intAction

.

The complete FSP code for the

HMSC_Control

component is shown in Figure 4.12, its corresponding LTS is shown in Figure 4.13. Note that in the depiction of the LTS we have added some additional graphics to illustrate how the different auxiliary processes are linked together.


HMSC_Control = N0,

N0 = Control_Initialise;N0_Adj,

N1 = Control_Register;N1_Adj,

N2 = Control_Analysis;N2_Adj,

N3 = Control_Terminate;N3_Adj,

N0_Adj = (intAction -> N1),

N1_Adj = (intAction -> N1 | intAction -> N2 |

intAction -> N3),

N2_Adj = (intAction -> N1),

N3_Adj = (intAction -> N0).

Figure 4.12 – FSP code for HMSC_Control intAction

Control_Initialise

N0

on

N3

off

Control_Terminate

Control_Register intAction

N1 intAction intAction

N2 query

Control_Analysis data command intAction intAction

Figure 4.13 – Composition of Control’s behaviour in all bMSCs

The third and final step required is to make intAction

unobservable and to minimise with respect to trace equivalence using the hiding operator and the deterministic

keyword of

FSP. Consequently, the FSP code for the Control component is: deterministic

||Control = HMSC_Control\{intAction}

and results in the behaviour model depicted in Figure 4.14.

Section 4.3 Architecture Models 71 on query data

0 1 2 off command

Figure 4.14 – Control component model

3 on pressure

0 command

Figure 4.15 –Actuator component model pressure query

0 1 2 pressure off

Figure 4.16 –Sensor component model

0 1 pressure

2 data

Figure 4.17 – Database component model

The algorithm described above must be applied to all components appearing in the MSC specification. The synthesis models for the other three components of the Boiler Control system are shown above. Once a LTS for each component has been synthesised, the complete system is their parallel composition, which in FSP is done using the operator “

||

”. In the case of the

Boiler Control system, the final architecture model is defined by the following FSP code

||Architecture = (Control || Sensor || Database || Actuator) and determines the behaviour depicted in Figure 4.18. query

0 on

1 pressure stop

2 pressure

3 pressure start

4 query

5 data

6 pressure

7 pressure

8 pressure data command

9 10 command command pressure off

Figure 4.18 – Architecture model for the Boiler Control system

The synthesis algorithm described above behaves slightly differently when processing a specification with bMSCs that have no adjacent nodes in the hMSC. Let us go back to the small example presented in Chapter 2 that describes the security system for controlling entrance to a company’s site (Figure 2.2, Figure 2.5, and Figure 2.6). When synthesising the FSP code for

72 Chapter 4. Behaviour Models component User the algorithm produces the following processes describing the component’s behaviour in bMSCs (Note that the bMSC Init corresponds the connection point Figure 2.5):

User_Employee_enters_building = (swipeCard -> openDoor -> closeDoor -> END).

User_Unreadable_swipe_card = (swipeCard -> errorMsg->END).

User_Init = END.

Supposing bMSCs Init, Employee_enters_building , and Unreadable_swipe_card are numbered

0, 1, and 2, then the remaining output of the synthesis algorithm would be:

HMSC_User = N0,

N0 = User_Init;N0Adj,

N1 = User_Employee_enters_building;N1Adj,

N2 = User_Unreadable_swipe_card;N2Adj,

N0Adj = (intAction -> N1 | intAction -> N2),

N1Adj = (endAction -> END),

N2Adj = (intAction -> N0). deterministic ||AuxUser = HMSC_User\{intAction}. minimal ||User = AuxUser\{endAction}

Note that for

N1

, as it does not have any adjacent nodes, the LTS is sent to an

END

state via endAction

. This introduces in the resulting process a state that models the final state of the component when it cannot do any more actions (see state 4 in Figure 4.19). swipeCard openDoor closeDoor endAction

0 1 2 3 errorMsg

Figure 4.19 – Terminating LTS model for AuxUser

E

The need for explicitly sending the component to an

END

via endAction

instead of simply defining

N1Adj

as

END

is because the keyword deterministic

preserves trace equivalence. This is not sufficient because architecture models are defined in terms of maximal trace inclusion. We illustrate the problems that deterministic

can introduce by extending the specification of the security system with the bMSC and hMSC of Figure 4.20. In this case, the synthesised FSP code for User is that Figure 4.22. Had we used

N3Adj = END

and

N1Adj = END

, or

N3Adj = (intAction -> END)

and

N1Adj = (endAction ->

END)

for that matter, then the resulting LTS would have been that of Figure 4.19. This would not be correct; for it to be an architecture model, the parallel composition of the components described in the security system should have in the set of maximal traces it defines, all the traces

Section 4.3 Architecture Models 73 specified by the MSC specification. However, for the extended version of the security system, if the LTS for the User is that of Figure 4.19 then the parallel composition does not exhibit maximal trace < swipeCard, openDoor > (recall that traces are maximal executions of the LTS) because it is capable of performing closeDoor . For this reason we must allow the User to move into a state where no more messages, and in particular closeDoor , can occur.


Door not closed properly

Unreadable

Swipe Card

Door not closed properly

User Door Controller swipeCard userId unlock openDoor

Security

System

Camera startRecording alarm

Security

Guard

Figure 4.20 – Extended version of the Secure Door system

User_Employee_enters_building = (swipeCard ->

openDoor -> closeDoor -> END).

User_Unreadable_swipe_card = (swipeCard -> errorMsg

->END).

User_Init = END.

User_Door_not_closed_properly = (swipeCard ->

HMSC_User = N0,

N0 = User_Init;N0Adj,

N1 = User_Employee_enters_building;N1Adj,

N2 = User_Unreadable_swipe_card;N2Adj,

N3 = User_Door_not_closed_properly;N3Adj,

N0Adj = (intAction -> N1 | intAction -> N2

| intAction -> N3),

N1Adj = (endAction -> END),

N2Adj = (intAction -> N0),

N3Adj = (endAction -> END). deterministic ||AuxUser = HMSC_User\{intAction}. minimal ||User = AuxUser\{endAction}.

Figure 4.21 – FSP Code for the Secure Door system swipeCard openDoor {closeDoor, tau}

0 1 2 errorMsg

Figure 4.22 – New LTS for User

E

A simple argument can be used to show that the model synthesised by our algorithm is an architecture model of the MSC specification used as input. Firstly, in concordance with the definition of architecture models, the synthesised model is the parallel composition of LTSs

74 Chapter 4. Behaviour Models such that there is one for each component appearing in the MSC specification. Secondly, it is trivial to see that each LTS has the same alphabet as its corresponding component in the MSC specification. Finally, it is necessary to prove that the synthesised model exhibits all traces specified by the MSC specification. Given a bMSC b , it follows from the definition of bMSCs that the partial ordering of events < of b extends the total ordering of events ≤ i

of any component instance of b . Consequently, this also holds for all maximal bMSCs of a positive

MSC specification. Thus, all traces w ∈ L ( PSpec ), when projected onto the alphabet of an instance i must be of the form lbl ( e

1

).

lbl ( e

2

)… were e

1

e

2

… is a total ordering of events of the i in some maximal bMSC. It is clear, from the algorithm presented above, that the synthesised component model A i

only exhibits traces that are result from total ordering of events of instance i of some maximal bMSC. This is because the components follow the behaviour specified for them in each bMSC continuing from bMSC to bMSC according to the hMSC. The endAction labels guarantee that all specified traces that are proper prefixes of other specified traces appear as maximal traces in the component LTS. Thus, we have L ( PSpec )|

α (i)

= mt ( A i

).

Lemma 4.1 Let PSpec be a positive MSC specification. If A =( A

1

||…|| A n

) is the synthesised architecture model of PSpec then L ( PSpec )|

α (i)

= mt ( A i

) for all i ∈ comp ( PSpec ).

In addition, as all synthesised component models A i

can exhibit the projection of a specified trace w onto their own alphabets ( w |

α (i)

∈ mt ( A i

)), it follows from Property 4.2 that the synthesised architecture model can exhibit w ( w ∈ ( A

1

||…|| A n

)). In conclusion, the model synthesised from a positive MSC specification is an architecture model.

Theorem 1 If A is the model resulting from applying the architecture model synthesis procedure to a positive MSC specification PSpec , then A is an architecture model of PSpec .

4.3.2 Comparing Architecture Models

Having built an architecture model, we would like to assess how close the model is to the specified behaviour compared to other architecture models. In fact we are interested in minimal architecture models, those that include as few non-specified traces as possible. Thus, an intuitive approach would be to define an ordering of architecture models based on maximal trace inclusion: given two architecture models A and A ’, we would define A ≤ A ’ if and only if mt ( A )

⊆ mt ( A ’). However, this definition does not produce intuitive results when comparing models that have non-specified deadlock traces (a deadlock trace is a trace that leads to a state with no enabled transitions). Consider the following trivial example: suppose we have a positive MSC specification consisting of the bMSC in Figure 4.23. The architecture model our synthesis

Section 4.3 Architecture Models 75 algorithm produces for this specification consists of the four component models depicted in

Figure 4.24. The set of maximal traces described by the composition of these four components is {< m1 , m2 >, < m3 , m4 >, < m1 , m4 >, < m4 , m1 >}. Thus, it introduces two non-specified traces:

< m1 , m4 > and < m4 , m1 >. These traces lead to deadlocks in which components B and C are in their states numbered with 2 and are expecting messages that the other cannot perform.

Let us now consider the LTS NewB for component B . This model extends the traces that the first

LTS for B can do. Now, after performing m1 , it cannot only do m2 , but also m3 . In fact, we have mt ( B ) ⊆ mt ( NewB ). NewB introduces local maximal traces of B , that according to the specified scenarios, B never performs. Intuitively, we would expect A || B || C || D ≤ A || NewB || C || D .

Yet, this is not the case: if we compose models for components A , C , and D with NewB the resulting composite LTS has the following set of traces: {< m1 , m2 >, < m3 , m4 >, < m1 , m4, m3 >,

< m4 , m1, m3 >}. The set of maximal traces of the new composite model is not included nor includes the set of maximal traces of the former model. The problem is that the non-specified deadlock traces < m1 , m4 > and < m4 , m1 > in the previous model have been extended to the following non-specified traces in the new model: < m1 , m4, m3 >, < m4 , m1, m3 >.

Sc1

A B C

Sc2

B C D m1 m4 m3 m2

Sc1 Sc2

C

0

Figure 4.23 – MSC for exemplifying ordering of architecture models m1

A m1

B m3

0 E 0 E m2 m2 m4

D

E 2 0 m3

Figure 4.24 – Component model for Figure 4.23 m4

E

2

76 Chapter 4. Behaviour Models m1

NewB m3

0 E 2

{m2, m3}

Figure 4.25 – Alternative component model for B

Consequently, defining the order of architecture models as maximal trace inclusion does not adequately capture our intuition of what a minimal architecture model is. In essence, the problem is dealing with deadlock states. The non-specified, deadlock traces that the first architecture model exhibits are not maximal traces of the second model. Thus, we need to introduce a weaker notion of ordering based on traces rather than maximal traces.

Definition 4.16 If A and A ’ are architecture models of a positive MSC specification PSpec , then

A ≤ A ’ if tr ( A ) ⊆ tr ( A ’).

With this notion of ordering, if there were a minimal architecture model, all its infinite nonspecified traces would be exhibited by all other architecture models. Additionally, all finite nonspecified traces (i.e. all deadlock traces) would still be exhibited by all other architecture models but as prefixes of other non-specified traces. This means that all architecture models always exhibit the non-specified behaviour of minimal architecture models.

Note that another appealing approach to defining the order between architecture models that does not work is to define the ordering based on the trace inclusion of the LTSs that conform the architecture models. In other words A

1

||…|| A n

< A

1

’||…|| A n

’ if and only if mt ( A i

) ⊆ mt ( A i

’) for

1 ≤ i ≤ n . However, this definition does not work either. Consider a MSC specification with only one bMSC (depicted in Figure 4.26). Clearly, the architecture model of Figure 4.27 is as close as one can get to the specified behaviour: it consists of only one trace, <m5>, which is the only trace specified by the MSC of Figure 4.26. However, if we used the LTS depicted in Figure 4.28 to model component E instead, the resulting architecture model would also provide exactly the specified behaviour. Yet, it does not hold that mt ( E ) ⊆ mt ( NewE ’), and consequently that E || F <

NewE || F .

Sc1

E F m5 Sc1

Figure 4.26 – Second MSC for exemplifying ordering of architecture models

Section 4.4 Summary 77

E m5

F m5

0 E 0 E

Figure 4.27 – Component models for Figure 4.26

NewE m5 m5

0 1 E

Figure 4.28 – Alternative component model for E

Having defined a notion of order between architecture models, we can prove that the architecture models synthesised by the algorithm presented previously are in fact minimal.

Property 4.4 If A is the synthesised architecture model of positive MSC specification PSpec , then for any architecture model A ’, we have A ≤ A ’.

The above property can be proved as follows. Suppose PSpec is a positive MSC specification, A

= ( A

1

||…|| A

|I|

) the synthesised architecture model of PSpec , A ’ = ( A

1

'||…|| A

|I|

') an architecture model of PSpec , and w ∈ tr ( A ). If w ∈ L ( PSpec ), then as L ( PSpec ) ⊆ mt ( A ’) we have w ∈ mt ( A ’) and consequently w ∈ tr ( A ’). If w ∈ tr ( A )\ L ( PSpec ), then as w ∈ tr ( A ) there must be an execution e ∈ E ( A i

) for every i , such that tr ( e ) = w |

α (i)

. In addition, from Lemma 4.1, we know that w |

α (i) must be a prefix of some word w ’|

α (i)

∈ L ( PSpec ).

We now prove by reaching a contradiction that there is an execution e ’ ∈ E ( A ’) such that tr ( e ’)

= w |

α (i)

: suppose there is an A i

’ that cannot execute w |

α (i)

. This means A ’ cannot execute w ’. This is absurd because w ’ ∈ L ( PSpec ) and L ( PSpec ) ⊆ mt ( A’ ). Consequently, for every i, we have that A i

’ can execute w |

α (i)

. Thus, there is an execution e ’ ∈ E ( A ’) such that tr ( e ’) = w . This means that w ∈ tr ( A ’) and A ≤ A ’

4.4 Summary

In this chapter, we have discussed the architectural aspects associated with a sequence chart notation such as the one presented in the previous chapter. The architecture defined by a MSC specification is the component structure and component interfaces that are given by bMSCs. We have introduced labelled transition system (LTS) for modelling concurrent systems, defined

78 Chapter 4. Behaviour Models architecture models 4 as LTS models that capture both the architecture and the behaviour described in a positive MSC specification, and provided algorithms for constructing such models. In terms of the overview of Section 1.4, we have introduced the highlighted parts of the diagram below.

Positive

Scenarios

( PSpec )

Negative

Scenarios

( NSpec )

Architecture

Traces

( L(PSpec)

)

Traces

( L(PSpec)

)

Traces

( L(NSpec)

)


Architecture Model

Synthesis


L ( PSpec ) ⊆ mt ( A ) A = ( A

1

L A n

)

Trace Model

Synthesis

Constraint Model

Synthesis


(





4 Note that in [Uchitel et al 2001] and [Uchitel et al 2002a] we referred to architecture models as implementation models. The terminology was changed as it caused some confusion.

Chapter 5

Chapter 5 Implied Scenarios

In the previous chapter, we introduced a rather weak notion of architecture model. Instead of requiring architecture models to provide the traces described in the MSC specification exactly, we required only trace inclusion ( L ( PSpec ) ⊆ mt ( A )). As mentioned before, this is a reasonable notion considering that scenario specifications are inherently partial descriptions.

It is interesting to study how close an architecture model can be to the behaviour explicitly described in a positive MSC specification. Is it possible to construct an architecture model that captures exactly the specified behaviour? It turns out that in some cases this is not possible; that for some MSC specifications all architecture models of the specification exhibit traces that have not been specified in the MSC specification. Moreover, as discussed further on, these traces are particularly interesting as they uncover important gaps of the partial system description that should be elaborated. In this section, we explain why these situations occur and define the notion of an implied scenario. Subsequently, we show how implied scenarios can be detected.

Applying the synthesis algorithm presented in Section 4.3.1, we can construct a FSP model for the MSC specification of Figure 3.1. Once the FSP specification is fed into the LTSA tool, we can animate our model to see how it behaves. In Figure 5.1, we show a trace (using the bMSC syntax for clarity), which can be executed in our system model. The trace shows how the

Control component is accessing the Database and receiving information from a previous activation of the Sensor . This is clearly not specified behaviour; there is no trace in the language defined by of our MSC specification that has a prefix as shown in Figure 5.1. The

MSC specification states that after initialising Sensor there must be some data registered into the Database before any queries can be done. Note that as the pressure message and the query message involve the Database , the trace of Figure 5.1 cannot be a result of the interleaving of messages in some maximal bMSC determined by the high-level MSC of Figure 3.1.

80 Chapter 5. Implied Scenarios

Sensor Database on pressure off on pressure query data

Control Actuator

Figure 5.1 – First implied scenario of the Boiler Control system

This means that our architecture model is introducing non-specified system behaviour. We could try to build another architecture model that does not include this trace. However, we have shown that the synthesised model is minimal with respect to trace inclusion. Thus, we must conclude that the unspecified trace of Figure 5.1 appears in all architecture models of the MSC specification. How is this possible? It clearly concerns the requirement that architecture models preserve the system's component structure and component interfaces. If we analyse the MSC specification from an architectural point of view, we can see that what is happening is reasonable. The Control component cannot observe when the Sensor has registered data in the

Database , thus if it is to query the Database after data has been registered at least once, it must rely on the Database to enable and disable queries when appropriate. However, as the Database cannot tell when the Sensor has been turned on or off , it cannot distinguish a first registration of data from others. Thus, it cannot enable and disable queries appropriately. Succinctly, components do not have enough local information to prevent the system execution shown in

Figure 5.1. Note that each component is behaving correctly from its local point of view, i.e. it is behaving according to some valid sequence of bMSCs. The problem is that each component is following a different sequence of bMSCs! The Sensor , Control and Actuator are going through scenarios Initialise , Register , Terminate , Initialise , Analysis , Register . However, the Database is performing Initialise , Register , Analysis , Register . We use the term "implied scenario" (taken from [Alur et al 2000]) to refer to system executions such as the one shown in Figure 5.1.

Let us look at a much simpler example. Consider the positive MSC specification of Figure 4.23: there are two very simple scenarios that appear as alternatives from the initial hMSC node. In one scenario, components A and B start by communicating m1 , and then B send m2 to C . In the other scenario C and D initiate the scenario by performing m4 and then C sends m3 to B .

However, the scenario in which m1 and m4 both occur has not been explicitly specified. The question is, how can we build an architecture model that provides both of the specified scenarios yet prevent a scenario with messages from m1 and m4 ? The answer is that it is not possible to do so. To prevent m1 and m4 from occurring, some form of coordination between

Section 5.2 Definitions and Properties 81 the pairs A , B and C , D is needed. However, in order for the behaviour model to be an architecture model, the only communication between the pairs can be via messages m2 and m3 .

However, if any of them were used, then all traces of the model would start with m2 or m3 . This would mean that the model would not include the specified traces as these must start with either m1 or m4 . In conclusion, it is impossible to construct an architecture model that does not have traces with prefixes < m1 , m4 > and < m4 , m1 >.

5.2 Definitions and Properties

An implied scenario is a sequence of message labels that appears as a trace prefix in all the architecture models of a positive MSC specification, yet that is not a prefix of any specified trace. The sequence < on , pressure , off , on , query > is an implied scenario of the MSC specification of the Boiler Control system. The sequences < m1 , m4 > and < m4 , m2 > are implied scenarios of the MSC specification of the Security system. We provide the formal definition of implied scenarios below.

Definition 5.1 (Implied Scenarios) Given a positive MSC specification PSpec , a trace w is an implied scenario of PSpec if for any architecture model A , w is a trace of A and cannot be extended in A to become a trace in PSpec . More formally, w is an implied scenario of PSpec if for any architecture model A of PSpec , w .

y ∈ mt ( A ) implies w.y

∉ L ( PSpec ) .

In informal discussion on implied scenarios, we use the term to refer to non-specified traces that have a prefix that is an implied scenario in the sense of Definition 5.1

The following property provides some more insight on what is occurring with the components in an implied scenario. It states that the projection of an implied scenario onto the alphabet of a component is a prefix of a trace specified by a maximal bMSC projected onto the same alphabet. This means that in an implied scenario, each component is following a valid path in the hMSC. In other words, each component is behaving correctly in terms of its local view (i.e. its interface)

Property 5.1 If w is an implied scenario of MSC PSpec then for each instance i there is a maximal bMSC b i

such that w |

α (i) is a prefix of L ( b i

)|

α (i)

.

This can be proven as follows: if w is an implied scenario of PSpec , and A = A

1

||…|| A n

is the synthesised architecture model for PSpec , then from the definition of implied scenario there is a

(possibly empty) sequence y such that w.y ∈ mt ( A ) and w.y

∉ L ( PSpec ). This means that w |

α (i)

∈ tr ( A i

), and from Lemma 4.1, we then know that w |

α (i)

is a prefix of L ( PSpec )|

α (i)

. From the

82 Chapter 5. Implied Scenarios definition of L ( PSpec ), we conclude that there must be a maximal bMSC b i such that w |

α (i) is a prefix of L ( b i

)|

α (i)

.

Not all positive MSC specifications have implied scenarios; a trivial example is the MSC specification depicted in Figure 4.26. Such specifications are said to be realisable, and their minimal architecture models are said to realise the specification [Alur et al 2000].

Definition 5.2 (Realisability) Given PSpec a positive MSC specification and A an architecture behaviour model, A is a realisation of PSpec if L ( PSpec ) = mt ( A ). We say that a PSpec is realisable if there is a realisation of PSpec .

5.3 Discussion

Implied scenarios are the result of specifying the global behaviour of a system that is realised component-wise. Components have local views of what is occurring at a system level, and from these restricted views, they must coordinate to provide the specified system behaviour.

However, if the system architecture does not provide components with enough local information

(i.e. a strong enough local view), the components may not be able to avoid unspecified system behaviour, even if the are behaving correctly in terms of local behaviour.

A first and natural reaction to implied scenarios may be that some peculiarity of the proposed

MSC notation or semantics is producing, as a side effect, these unexpected traces. This is not the case, as the concept of implied scenarios is independent of the notation used to specify system behaviour. In particular, the use of weak sequential composition in the semantics of hMSCs is not the cause for implied scenarios. It is perfectly possible to have implied scenarios using strong sequential composition. The specification of Figure 4.23 does not even require sequential composition of bMSCs, yet it exhibits two implied scenarios. The concept of implied scenario applies even if the set of specified system traces is defined by extension or using regular expressions as in ([Chu and Liu 1988]) instead of using MSCs.

Implied scenarios are the result of a mismatch between the required behaviour and the required architecture of a system: it is not always possible to provide an arbitrary set of traces with a fixed system architecture. However, more importantly, implied scenarios indicate gaps in a system specification.

An implied scenario may be an acceptable system trace that has been overlooked by stakeholders. This is not surprising as scenario-based specifications are inherently partial. It is reasonable to assume that stakeholders do not provide a comprehensive set of examples of how the system is expected to behave. In this case, the implied scenario should be added to the specification in order to extend it covering a case that had not been

Section 5.3 Discussion 83 explicitly described in the original system description. It is also possible, however, that the implied scenario does represent unwanted system behaviour. This means that the implied scenario is a result of a partial description of the system architecture. The architecture description may be missing a component or certain components may require extended interfaces to enhance their local views of the system behaviour. The existence of implied scenarios that describe unwanted system behaviour means that the system architecture needs to be further elaborated or at least that careful documentation is required so as to ensure that design decisions are taken at some point to prevent the scenario from happening. Considering that scenario-based specifications are used at early stages of the development process, particularly in requirements definition, the latter may be more appropriate (we return to this in Chapter 7).

The term implied scenario was first used by Alur et al [Alur et al 2000]. The authors defined the notion of implied scenario and realisability for specifications containing a finite set of bMSCs in an asynchronous communication setting. However, the problem underlying that of implied scenarios, the mismatch of behaviour and architecture, has been studied before. The most notorious example is that of protocol synthesis. In protocol synthesis (e.g. [Kapus-Kolar 1999,

Saleh 1996]), given a specification of the intended system traces (called services), the goal is to automatically construct a distributed implementation of the system behaviour according to a given architectural specification. The resulting implementation is required to provide exactly the specified service. Consequently, the difficulty of protocol synthesis consists in introducing in an automated manner; the additional component synchronisations that make the implementation provide the service precisely, with no additional unspecified behaviours. It is clear that the assumptions in the protocol synthesis problem are quite different from those underlying implied scenarios. In protocol synthesis, the assumption is that the service specification is complete, and that the problem is to refine the architecture to provide the specified services and no more.

However, in the context of scenario-based specifications, the completeness assumption does not hold. The specification of system behaviour is partial, and consequently, it makes no sense to try to avoid implied scenarios because we do not know, a priori, if they represent intended or undesired system behaviour.

Leue et al [Ben-Abdhallah and Leue 1997b], have studied a related problem called non-local choice. In this case, authors are interested in checking when components can choose different scenarios in a scenario graph. We are interested in observable behaviour, thus the notion of implied scenarios is defined more abstractly, in terms of traces of observable events and not on the MSC syntax. Although, to some degree, the intent of non-local choice is similar to that of implied scenarios, they are not semantically equivalent. Non-local choices are implied scenarios; nevertheless the converse is not the case. For example, the specification below has

84 Chapter 5. Implied Scenarios two implied scenario: y1, forward, x2 and x1, forward, y2 ; however, it is not a case of non-local choice. Several methods for detecting non-local choice have been developed [Ben-Abdhallah and Leue 1997b, Ben-Abdhallah and Leue 1998, Helouet 2001].

Scenario 1

A B x1 forward

C x2

D

Scenario 2

A B y1 forward

C y2

D

Scenario 1 Scenario 2

Figure 5.2 – Example of MSC with implied scenario but no non-local choice

Kai Koskimies and Erkki Mäkinen [Koskimies and Mäkinen 1994] have used inference procedures based on work by Biermann and Krishnaswamy to synthesise state machines from scenarios: from a set of basic MSCs, the algorithm builds a state-machine for each component such that it can realise its own responsibilities described by the set of scenarios. As the process tries to keep the number of states of the state-machine minimal, over-generalisations can occur at a component level. This means that the component state-machines may perform sequences of actions that have not been specified in the original scenarios. These over-generalisations are not implied scenarios; firstly, because they occur at a component level instead of at a system level; secondly, because they are an artefact of the synthesis algorithm, not an inherent consequence of the set of scenarios used as an input. The over-generalisations arise from minimising the number of states of each component state machine. Nevertheless, a similarity with implied scenarios is that these over-generalisations can be used to drive the elaboration of component models [Systä

1997, Systä 2000] in a similar way implied scenarios can drive the elaboration of system models

(as we show in subsequent chapters).

In conclusion, implied scenarios indicate gaps in the system specification that should be taken to stakeholders for validation. By doing so, the specification can be iteratively elaborated. An important comment is that implied scenarios expose subtle mismatches between the architecture and behaviour. Even in a toy example such as the Boiler Control system, the implied scenario we have discussed cannot be detected trivially by observing the specification. Thus, there is great value in automatically detecting and validating implied scenarios as they force stakeholders to address subtle yet crucial points regarding the concurrent nature of the system they are specifying. In the next chapter we discuss how to detect implied scenarios.


5.4 Summary

In this chapter, we have introduced the notion of implied scenarios and realisability. We have given some important properties of implied scenarios and provided an extensive discussion on why they occur. Implied scenarios are central to the elaboration process that we present in this thesis; in terms of the overview of Section 1.4, we have introduced the highlighted parts of the diagram below.

Positive

Scenarios

( PSpec )

Negative

Scenarios

( NSpec )

Architecture

Traces

( L(PSpec)

)

Traces

( L(PSpec)

)

Traces

( L(NSpec)

)


Architecture Model

Synthesis


L ( PSpec ) ⊆ mt ( A ) A = ( A

1

L A n

)

Trace Model

Synthesis

Constraint Model

Synthesis


Model Check

( mt ( A ) ⊆ mt ( T )) ?




Chapter 6

Chapter 6 Implied Scenario Detection

We have shown how an architecture model can be constructed from a positive MSC specification. We have also shown that it is possible for this model to exhibit implied scenarios, and commented on how these can help elaborate MSC specifications if detected and validated with stakeholders. Consequently, detecting implied scenarios is an important issue.

Our approach to implied scenario detection is conceptually very simple. We know how to construct an architecture model and that this model includes all specified traces and is minimal with respect to trace inclusion. If we build a model that captures exactly the set of traces defined by the MSC semantics – the trace model – we could compare its traces with those of the minimal architecture model. Any trace in the latter that is not a trace of the new model would then correspond to an implied scenario. Of course, to build a precise model of the specified traces we would have to ignore the architectural requirements specified in the scenarios. In addition, such a (finite) model would only be possible if the MSC behaviour corresponds to a regular language [Ullman and Hopcroft 1979], which is not always the case. An example of such case is shown in Figure 6.1.

S1

C1 a

C2 C3 b

C4

S1

S2

C1 C2 c

C3 C4

S2

Figure 6.1 – Example of a non-regular MSC specification

Definition 6.1 (Regular MSC Specifications) A MSC specification PSpec is said to be regular if L ( PSpec ) is a regular language. Otherwise, PSpec is said to be non-regular.

Non-regular MSCs are not realisable; there is no finite LTS that can model the language. Thus, there can be no set of finite LTS such that their composition models it either. Fortunately, there are decision procedures that can be used to guarantee that a MSC specification determines a regular language [Henriksen et al 2000a]. These decision procedures are based on the boundedness condition, which is defined in terms of the communication graph of a set of

88 Chapter 6. Implied Scenario Detection bMSCs. In our setting, a communication graph would have has a node for each component; the set of arcs would be the transitive closure of the set of arcs defined by the fact that two components communicate over a message. The boundedness condition states that for all cycle in the hMSC, the communication graph for the bMSCs in that cycle determines one non-empty set of fully connected components. In Figure 3, the condition does not hold as there are two sets of fully connected components in the communication graph resulting from the only hMSC cycle:

{ C1, C2 } and { C3, C4 }. In the rest of this thesis we assume bounded, and consequently regular

[Henriksen et al. 2000], MSC specifications. We now explain how we build a model of the intended system behaviour from such positive MSC specifications.

One of the difficulties of building a LTS model that captures the specified traces of a positive

MSC specification is that such model cannot be constructed compositionally from the bMSCs appearing in the MSC specification. This is because of the weak sequential composition used in hMSC semantics. Components may move asynchronously from one bMSC to another, thus a message from a bMSC that appears before another bMSC in a maximal path of the hMSC is not guaranteed to occur before the messages of the latter bMSC.

Our approach is to build a set of component LTS models that extend (in terms of architectural capabilities) those described in the MSC specification. The extension is that components must request permission of a Coordinator component before moving from one bMSC to another. In addition, we build a Coordinator that enables and disables component entry requests to bMSCs guaranteeing that components do not follow different sequences of bMSCs.

It is important to note that in this section we define a model that is not an architecture model.

Firstly, because we have added a component into the system that has not been specified in the

MSC specification: the Coordinator. Secondly, because the LTS models for components appearing in MSC specifications have an extended alphabet that includes labels that do not appear in the MSC specification. Note that it is not our intention to propose a refined architecture or design solution that avoids implied scenarios. This would be incorrect, as it would assume that implied scenarios are unwanted system traces. This is not necessarily so. Our intention is to build an artefact that allows us to detect implied scenarios by comparing its traces against those of a minimal architecture model.

The reason we choose the Coordinator approach is that it is possible to show that all implied scenarios exhibited by an architecture model are the result of components exhibiting behaviours described by different paths in the hMSC (see Property 5.1 in page 81). Consequently, if we

Section 6.1 Trace Models 89 build components and coordinate them in such a way that they all go through the same hMSC path, implied scenarios are avoided. We now show how this can be done.

In the previous section, we have presented a synthesis algorithm that builds LTS models for each component appearing in a positive MSC specification. The LTS models we now build are an extension of those; we call them extended component models. Instead of using an internal action for linking component behaviours corresponding to each bMSC, we use a coordination action. Coordination actions are labelled with a component name and a bMSC name; they model the request of the component to enter the bMSC. For component Control, the coordination actions that we use are

Control.Initialise

,

Control.Register

,

Control.Analysis

,

Control.Terminate

. Figure 6.2 depicts the final behaviour of the extended Control component.

It is clear that that the behaviour resulting from hiding coordination actions in an extended component E i

is trace equivalent to that of the component model synthesised for the architecture model. Thus, the above proposition motivates the construction of a Coordinator component

Coord that synchronises on component coordination actions and forces components to follow the same maximal bMSC. The resulting system, ( E

1

||…|| E n

|| Coord ), restricted to the MSC alphabet does not exhibit any implied scenarios; it is an exact model of the specified MSC traces. In summary, we use a Coordinator component that keeps track of the path (maximal bMSC) being taken by the leading component and that forces all other components lagging behind to follow the same path. We now define such a Coordinator. s_Control_Initialise

0 1 s_Control_Terminate on s_Control_Register s_Control_Analysis query

2 3 4 s_Control_Register

5 6 data

7 off command

Figure 6.2 – Control component model extended with coordination actions

The Coordinator state space consists of states that model a path in the hMSC and the position of each component in that path. However, there is no need to keep track of the whole path followed by components (which is fortunate as the path is potentially infinite). It suffices to record the bMSCs the leading component has gone through and which the components further behind have not yet reached. The sequence can be thought as the destiny of the component that is furthest behind and that is being decided by the component that is furthest in front. For example, the state ( 2, 2, 2, 1, Initialise .

Register ) corresponds to the Boiler Control System state

90 Chapter 6. Implied Scenario Detection where components Sensor , Database and Control are in bMSC Register while Actuator is in bMSC Initialise and has not requested the Coordinator for permission to move into Register .

Definition 6.2 (Coordinator) Let PSpec = ( B, H, f ) be a positive MSC specification and

E

1

, … ,E n

the extended components synthesised from PSpec . The LTS ( S, L, ∆ , q ) is a

Coordinator for PSpec if

• L = { i.b | i ∈ comp ( PSPec ) and b ∈ B }

• S ⊆ {( p

1

, … , p n

, d ) | 0 < p i

≤ | d |, d is a non-empty sequence of B }

• q = ( 1, 1, 1, 1, b

0

) , where b

0

is the initial bMSC according to H

• (( p

1

, … , p n

, d ) , i .

b, ( q

1

, … ,q n

, d ’) ∈ ∆ ) where d = d

1 d

2

… d m iff

T1 - if p i

= m, then ( d m

, b ) ∈ H, d ’ = d .

b, q i

= p i

+ 1, and for all j ≠ i, q j

= p j

T2 - if p i

< m and ∃ j .

p j

≤ p i

, then d ’ = d, b = d i+1

, q i

= p i

+ 1, and ∀ j ≠ i .

q j

= p j

T3 - if p i

= 1 and ∀ j ≠ i .

p j

> p i

, then d ’ = d

2

… d m

, b = d

2

, q i

= 1, and ∀ j ≠ i, q j

= p j

1

Rules T1, T2 and T3 guarantee that access to bMSCs by components is granted correctly. Rule

T1 states that the leading component ( i ) can move from its current bMSC ( d m

) to any valid bMSC ( b ) only if both bMSCs are adjacent in the hMSC, and that the sequence of bMSCs to be followed by the rest of the components is extended with b . For example, from state (2, 2, 2, 1,

Initialise .

Register ) there is, according to rule T1, a transition labelled Control.Analysis that leads to state (2, 2, 3, 1, Initialise.Register.Analysis

). This transition represents the Control component that having completed its part of bMSC Register , requests (and gets) permission to move to bMSC Analysis .

Rules T2 and T3 state that any component that is not leading ( p i

< m or p i

= 1 ) can only move to the bMSC that is dictated by sequence d . However, according to rule T3, if a component is last

( p i

= 1 ) and all other components are ahead of it, the first element of the sequence of bMSCs can be discarded (as all components have completed the bMSC, there is no need to keep record of it). Rule T2 determines that there is a transition from (2, 2, 3, 1, Initialise.Register.Analysis

) to

(2, 3, 3, 1, Initialise.Register.Analysis

) labelled Database.Analysis

. This corresponds to the

Database component following the Control component into bMSC Analysis . Rule T3 determines that the component Actuator can move into bMSC Register leading from state (2, 3,

3, 1, Initialise.Register.Analysis

) to (1, 2, 2, 1, Register.Analysis

).

We now argue why the extended components and the coordinator that we have defined above can be used to model the traces of an MSC specification.

Let PSpec be a positive MSC specification, E

1

, … ,E n

extended component models for instances i with H the set of all coordination actions and Coord the Coordinator model for PSpec .

From the definition of the Coordinator, L ( PSpec ) ⊆ mt (( E

1

||…|| E n

|| Coord )\ H ) can be proven in a

Section 6.1 Trace Models 91 straightforward manner. The opposite inclusion , mt (( E

1

||…|| E n

|| Coord )\ H ) ⊆ L ( PSpec ) requires explanation. It is clear that mt (( E

1

||…|| E n

|| Coord )\ H ) ⊆ mt ( A ) where A is the minimal architecture model of PSpec . Thus, we must prove that mt (( E

1

||…|| E n

|| Coord )\ H ) contains no implied scenarios. Let w be an implied scenario and let us assume that that w ∈ mt (( E

1

||…|| E n

|| Coord )\ H ). Consequently, using Property 4.2 we have w |

α (i)

∈ mt ( E i

)|

α (i) for each instance i . From the construction of Coord , it follows that all E i

must be following the same path in the hMSC thus there is a maximal bMSC b such that w |

α (i)

∈ L ( b )|

α (i)

. This implies that w ∈

L ( PSpec ) which is a contradiction as w is an implied scenario.

Theorem 2 Let PSpec be a positive MSC specification, E

1

, … ,E n

the set of synthesised extended components from PSpec and H is the set of all coordination actions. If Coord is a Coordinator of PSpec then mt (( E

1

||…|| E n

|| Coord )\ H ) = L ( PSpec ).

The problem with the Coordinator definition presented above is that its state space is not finite.

The reason we have an infinite set is that the sequence of bMSCs in a Coordinator state can be infinite. This occurs because a component can increase the distance between itself and the last component infinitely. For example from state (1, 1, 1, 1, Register ) where all components are in bMSC Register , the component Actuator could loop through Register infinitely while the rest of the components stay where they are. Alternatively, components Sensor and Database could loop (together) infinitely through Register leaving Actuator behind.

There is, however, a way to get round this. Consider states of the form (n+1, n+1, 1, 1,

Initialise.Register

1

…Register n

). Database and Sensor components can loop infinitely through bMSC Register , augmenting the distance with component Control . However, as Control does not participate in Register the fact that the bMSC has been completed several times is irrelevant.

Thus, Control could avoid going through the bMSC altogether. Alternatively, as loops are unbounded, the fact that components such as Database and Sensor have completed the loop many times is also irrelevant with respect to their future behaviour.

The fact is that in order for a component to increase infinitely the distance between itself and another component, the first must be able to loop in the hMSC through bMSCs in which the second component does not participate (i.e. does not appear interacting with any other component). This always holds for MSC specification corresponds that correspond to regular languages, because these must be channel bounded [Henriksen et al. 2000].

Consequently, we can introduce an equivalence relation among Coordinator states: a state is equivalent to another if one is the result of eliminating loops from the other such that the no components are half way through the loops being eliminated.

92 Chapter 6. Implied Scenario Detection

Definition 6.3 (Ordering and Equivalence of Coordinator States) Let s =( p

1

, … ,p n

,d

1 d

2

… d m

) and s ’ = ( q

1

, … , q n

, d ’) be Coordinator states. We define ≡ ⊆ ( S × S ) as the symmetric closure of

≤ ⊆ ( S × S ), and define ≤ ⊆ ( S × S ) to be the transitive closure of R ⊆ ( S × S ) where s R s ’ if and only if ∃ a, b such that

• 0 ≤ a ≤ b ≤ m

• d a

= d b

,

• d ’ = d

1 d

2

… d a-1 d b

… d m

• ∀ i .

p i

≥ b or p i

< a

• ∀ i .

if p i

≥ b then q i

= p i

( b a )

• ∀ i .

if p i

< a then q i

= p i

According to the definition above, ( n , n , 1, 1, Initialise.Register

1

…Register n’

) ≤ ( n ’, n ’, 1, 1,

Initialise.Register

1

…Register n

) for all n ≤ n ’. In addition, for the construction of the finite

Coordinator in the Boiler Control System we use the minimal equivalent state of ( n +1, n +1, 1,

1, Initialise.Register

1

…Register n

) which is (2, 2, 1, 1, Initialise.Register

1

)

Having defined an equivalence relation among Coordinator states, we can now introduce a finite state Coordinator component by performing a quotient on the state space of our previous

Coordinator component definition.

Definition 6.4 (Finite Coordinator) Let the LTS ( S, L, ∆ , q ) be a Coordinator component for a positive MSC specification PSpec . A finite Coordinator component is the LTS ( S

≡

, L, ∆

≡

, q ) where S

≡

= { s | s ∈ S and for all s ’ ∈ S, if s ≡ s ’ then s ≤ s ’} and ( s

1

, i .

b, s

2

) ∈ ∆

≡ iff ( t

1

, i .

b, t

2

) ∈

∆ where s

1

≡ t

1

, and s

2

≡ t

2

.

Furthermore, from the definition of (non-finite) Coordinator and under the assumption that the

MSC specification is regular, it is simple to show that the equivalence relation defined previously is a subset of the strong semantic equivalence relation defined in the previous chapter[Milner 1989] among Coordinator states.

Proposition 1. Let PSpec be a regular positive MSC specification, Coord a (non-finite)

Coordinator of PSpec . If s and s ’ are Coordinator states then s ≡ s ’ implies s ~ s ’.

Proposition 2. Let PSpec be a regular positive MSC specification. If Coord f is a finite

Coordinator of PSpec and Coord is a Coordinator of PSpec then Coord f is strongly equivalent to

Coord .

As strong equivalence is a congruence [Milner 1989], we have mt (( E

1

||…|| E n

|| Coord f

)\ H ) = mt (( E

1

||…|| E n

|| Coord )\ H ). As a result, we now know how to construct a behaviour model that

Section 6.2 Trace Model State Space Reduction 93 has the same traces as those defined by an MSC specification. We call this model the trace model, and for the Boiler Control system, the model is that of Figure 6.3. on pressure query data pressure

0 1 2 pressure

3 4 off command command

Figure 6.3 – Trace model for the Boiler Control system

5 pressure

6.2 Trace Model State Space Reduction

Although the state space of the Coordinator LTS we have defined is finite, it can be extremely large. In fact, its state space grows exponentially with respect to the number of components in the MSC specification; this is consistent with the complexity results discussed in [Alur and

Yannakakis 1999]. The size of the Coordinator state space is in the order of (CB) C where B is the number of basic MSC and C the number of components. The size of the state space can be explained as follows: the equivalence relation defined on the Coordinator states allows the elimination of a loop from the sequence of bMSCs in a state if there is no component currently in the loop. The worst case is that the hMSC defines one big loop of length B and components are positioned in such a way that every component is in a different iteration of the loop. As there are C components, the maximum length of the sequence of bMSCs is in the order of CB. In addition, each component can be in a different position in the sequence of bMSC, thus the resulting state space is of size (CB) C .

The size of the Coordinator state space is large, in part, because we are constructing the

Coordinator taking into account very little information from bMSCs. In other words, our

Coordinator accepts combinations of requests to enter bMSCs that never occur. This is because the interactions between components in order to complete bMSCs and move on prevent certain sequences of coordination actions from occurring. Consequently, it is possible to trim the size of the Coordinator considerably introducing some heuristics that take into account the dependencies between components in bMSCs.

In the remainder of the section, we discuss some of the rules that used to reduce the size of the reachable state space of the Coordinator. The rules have not been designed to obtain a

Coordinator is the minimal Coordinator that can ensure no implied scenarios. Nor have they been designed to be non-overlapping (i.e. rules that do not restrict the same transition). They are

94 Chapter 6. Implied Scenario Detection simply a set of constraints they we have found effective for reducing to a tractable size (in some examples up to 90%) the state space of the Coordinator.

6.2.1 Heuristics

In this section, we propose a number of heuristics for reducing the size of the Coordinator state space. We claim these heuristics preserve the traces of the Coordinator component. For each heuristic, we provide an intuition on why this occurs together with some exemplification.

A first approach to reducing the reachable Coordinator state space is to look at the components with which a given component must interact in order to complete a bMSC and move on. A component can be allowed to move to the next bMSC if all the components that it needs to interact with (directly or indirectly) in order to complete a bMSC are not lagging behind.

Definition 6.5 (Component Dependencies) Let b = ( E, L, I, M, instance, label, order ) be a bMSC and c ∈ I . The dependencies of c is the set Dep ( b, c ) = { c ’ ∈ I | ∃ e, e ’ such that e < e ’ , not e ’< e, instance ( e ) = c and instance ( e ’) = c ’}

Definition 6.6 (Reduction Rule 1) The transition relation of the coordinator ∆ ⊆ ( S × L × S ) must satisfy that ( p

1

, …, p n

, d )  → ( p

1

’ , …, p n

’ , d ’) then ∀ i ≠ c ( i ∈ Dep ( b, c ) then p i

≥ p c

)

For example if we have the following state (2, 1, 2, 2, Register.Analysis

), although rules T1-T3 allow a transition labelled Actuator.Register

, this transition in practice is never taken. When the synthesised components are put together, the Control component can never complete bMSC

Analysis if component Database has not completed Register . This is because Actuator must interact with Control in bMSC Analysis , which in turn must interact with component Database .

Thus, we can restrict the transition labelled Actuator.Register

.

An entirely different approach to reducing the size of the reachable state space is based on giving priorities to components that wish to move on to their next bMSC. The difference with the criteria presented above is that now we constrain sequences of requests by components that in principle may occur when combining the synthesised components. However, we introduce constraints that do not affect the behaviour of the overall system.

Let us look closely the states described below (we have omitted some transitions and transition labels to simplify the example):

Section 6.2 Trace Model State Space Reduction 95

A : (2, 1, 1, 1, Analysis.Register)

Database.Register

B : (2, 2, 1, 1, Analysis.Register)

Control.Register

C : (2, 1, 2, 1, Analysis.Register)

Control.Register

D : (2, 2, 2, 1, Analysis.Register)

Database.Register

Figure 6.4 – Portion of the Coordinator model

From node A there are two transitions, one in which the Database moves to bMSC Register in node B and another in which the Control component moves into bMSC Register in C.

However, from B and C it is possible to move the other component to bMSC Register in node D.

Once in node D it does not matter if Database of Register moved into Register . This is true even if either were the leading component that is determining the sequence of bMSCs to be followed by the rest.

Consequently, what can be done is a sort of partial order reduction [Kurshan et al 1998], where the transition from A to B or from A to C is eliminated. Similarly to partial order reduction, the choice of the transition to be removed must be made carefully. Nevertheless, a fundamental difference is that, in this case, the choice must be made using information in the bMSCs rather than just looking at transition labels.

Let us explore the consequences of removing transition ( A , B ). In this case the Database component has to wait until the Control component has moved to bMSC Register before it itself can move. This implies that the pressure message (see bMSC Register in Figure 3.1) cannot occur until the Control has finished bMSC Analysis . In other words, pressure cannot occur until command (see bMSC Analysis in Figure 3.1) has occurred. This clearly imposes an incorrect restriction on the behaviour of the overall system: the occurrence of pressure is independent of the occurrence of command .

On the other hand, if transition ( A , C ) is restricted, then Control has to wait for Database before moving to bMSC Register . This does not restrict any system behaviour, as the Control component can never finish bMSC Analysis before Database does. Thus by the time the Control component can choose to move to the next bMSC, Database has always been able to choose.

Thus, informally, the criterion for partial order reduction of the state space of the Coordinator is:

“given two components, if one can always finish a bMSC before the other, then it must have priority to move on to the next bMSC over the other”. More formally, we can define an order in which components can complete a bMSC and thus be able to choose to move on to the next bMSC. We then can allow a component to move only if all other components that can complete the bMSC strictly before it have already moved on.


Definition 6.7 (Component Completion Order) Let b = ( E, L, I,

λ

, <, tgt ) be a bMSC and c ≠ c ’ ∈ I . The completion order of b is defined as follows: ( c, c ’) ∈ Completion ( b ) if and only if e

≤ e ’ where e and e ’ are maximal events of c and c ’ with respect to < c and < c’ or c has no events in b .


1

, …, p n

, d )  → ( p

1

’, …, p n

’ , d ’) where d = d

1 d

2

…d m implies for all i such that ( i, c ) ∈ Completion ( d pc

) and ( c, i ) ∉ Completion ( d pc

) then p i

> p c

Returning to our previous example we have Completion ( Analysis ) = {( Sensor, Database ),

( Sensor, Control ), ( Sensor, Actuator ), ( Database, Control ), ( Database, Actuator ), ( Actuator,

Database ), ( Actuator, Control )}. Thus, in node A , the transition labelled Control .

Register is restricted because i = Database violates the rule.

For the next rule, let us suppose that the bMSC of Figure 3.2 is a node of the hMSC with

Register as one of its adjacent nodes. The bMSC, according to the previous reduction rule, has no component with priority over others. This is because we have

Completion ( Analysis • Register )= {( Sensor, Database ), ( Database, Sensor ), ( Control, Actuator ),

( Actuator, Control )}, and consequently there are no two components c, c ’ such that ( c, c ’) ∈

Completion ( Analysis • Register ) and ( c ’, c ) ∉ Completion ( Analysis • Register ). This means that in a Coordinator state such as (2, 1, 1, 1, ( Analysis • Register ).

Register ) components Database ,

Control , and Actuator are all allowed to move to bMSC Register . However, as Sensor has moved on to Register , we know that Database must have completed bMSC Analysis • Register and can move on to Register . Thus, we can prioritise Database over Control and Actuator .


1

, …, p n

, d )  → ( p

1

’ , …, p n

’ , d ’) where d’ = d

1 d

2

…d m implies ∃ e, l, i, j such that i ≠ c, j ≠ c, λ ( e ) = ( l, i ), λ ( tgt ( e )) = ( l,j ), e and tgt ( e ) are maximal events of i and j with respect to < i and < j then p i

> p c if and only if p j

> p c

Finally, simpler rules can be introduced to avoid components taking an excessive lead or lagging behind too much. Essentially, there is no point in allowing a component to move two bMSC ahead of the rest because it is not able to perform any communication until another component has caught up with it. The same reasoning can be applied for the last component; there is no point in allowing it to lag behind by more than one bMSC.


1

, …, p n

, d )  c → s if s is the minimal Coordinator state such that s ≤ ( p

1

’ ,

…, p n

’ , d ’) where d’ = d

1 d

2

…d m and p c

= m implies ∃ i such that i ≠ c and p i

= m .

Section 6.2 Trace Model State Space Reduction 97


1

, …, p n

, d )  → s ( p

1

’ , …, p n

’ , d ’) where d’ = d

1 d

2

…d m implies that if p c

=

2 then that there is more than one i such that i ≠ c and p i

< 2 .

6.2.2 Assessment

We have implemented an algorithm that builds the FSP specification for the Coordinator of a

MSC specification. The implementation is integrated into the LTSA as part of the tool we have developed to support the elaboration process we discuss in this thesis. In Chapter 9, we discuss the tool in more detail. Here, we comment on the effectiveness of the heuristics for reducing the state space of the Coordinator component.

We have already discussed an upper bound for the size of the Coordinator state space: (CB) C . In reality, the reachable state space is smaller. Additionally, if the heuristics presented above are used, the reachable state space is considerably less than the upper bound. The following table shows the upper bounds and reachable state space sizes using and without using heuristics for two MSC specifications. The first is the Boiler Control system that we discussed extensively.

The second is a case study we discuss in Chapter 8. Note that there is no information available for the reachable states of the Coordinator for the passenger transport system when not using heuristics. This is due to the synthesis process running out of memory because of the enormous state space of the coordinator.

Reachable states using heuristics

Control

System

Railcar Control

System

171 4414

Reachable states without heuristics

Upper bound: (CB) C

30637 N/A

≈ 22.5 x 10

10

Table 6.1-Compared Coordinator State Space Size

As explained previously, the heuristics we present are not designed to obtain a minimal

Coordinator. Nor are they designed to be non-overlapping (i.e. rules that can restrict the same transition). They are simply a set of constraints they we have found effective for reducing to a tractable size the state space of the Coordinator. The above table shows that the reductions obtained with our heuristics are substantial and have been essential for making the approach tractable. The heuristics can certainly be improved; we intend to work further in this direction.


6.3 Implied Scenario Detection using LTSA

As discussed previously, to detect implied scenarios we now need to compare mt ( A ) and

L ( PSpec ). Now that we have discussed how to build a trace model T such that mt ( T )= L ( PSpec ). we discuss how LTSA can be used to detect implied scenarios. LTSA does not provide a function for checking maximal trace equivalence ( mt ( A )= mt ( T )); therefore, comparing mt ( A ) and mt ( T ) must be done indirectly. We know that mt ( T ) ⊆ mt ( A ), thus mt ( A ) ⊆ mt ( T ) is all that needs checking. We first use LTSA to verify tr ( A ) ⊆ tr ( T ) by declaring T as a safety property and verifying A against it. If this holds, what remains to be checked is that all finite maximal traces of A are also maximal traces in T . There are two kinds of finite maximal traces that A can exhibit, deadlocks and successful terminations. As T is deadlock free, A should be so too.

Deadlock freedom can be checked with LTSA. For checking that A and T coincide in terms of successful terminations, we need to model successful termination explicitly as LTSA does not provide automated checks that consider end states. By doing so, checking A against property T verifies if all successfully terminating traces in A, are also that of T .

Summarising, if A does not violate safety property T and A is deadlock free, then mt ( A ) ⊆ mt ( T ),

Spec has no implied scenarios, and A is a realisation of Spec . On the other hand, as discussed further on, if either check fail, then Spec has implied scenarios and LTSA provides an example of one.

We now show that the implied scenario detection approach we propose always produces an implied scenario if the specification has one, and that it never produces traces that are not implied scenarios. To do so, we first we discuss the need for modelling successful termination explicitly, then introduce the notion of deadlock formally and prove some properties of the minimal architecture models the algorithm of Section 4.3.1 synthesises.

LTSA provides three model checking features: progress, safety and deadlock-freedom verification. As explained before, we need to verify mt ( A ) ⊆ mt ( T ), in other words that all maximal traces of A are maximal traces of T . For this purpose, verification of progress (a particular kind of liveness property) is irrelevant; in contrast, verification of safety properties and deadlock detection can be exploited. Safety properties in LTSA are modelled using deterministic LTSs. A property described by an LTS P models all the traces (with respect to alphabet α ( P )) that are considered "good" behaviours. Consequently, all traces exhibited by an

LTS that when projected onto α ( P ) are not traces of P , are considered property violations.

Model checking of property violations is performed by extending an LTS P that has been declared using the FSP property keyword, with the error state π , and transitions labelled l to

Section 6.3 Implied Scenario Detection using LTSA 99

π from every state s in which l is not enabled. Thus, when an arbitrary LTS is composed with the property, all traces that violate the property lead to the error state. Consequently, property violation can be checked by verifying if error state π is reachable in the composed model.

Returning to the problem of verifying mt ( A ) ⊆ mt ( T ), we can now approximate this by using T as a safety property and thus checking tr ( A ) ⊆ tr ( T ). However, to extend this result to mt ( A ) ⊆ mt ( T ) we need to check that all finite maximal traces of A are also maximal traces in T . As explained above, there are two kinds of finite maximal traces, deadlocks and successful terminations.

Verifying deadlock-freedom can be done in LTSA; however, there are no analysis regarding end states. Thus, in order to compare traces leading to end states in A and T we need to model these cases in using error states, deadlock states or transition labels (These three solutions correspond to the verification capabilities of LTSA: safety checks, deadlock-freedom and safety checks respectively). The simplest solution is to use the label endAction

that is already present in the synthesis algorithms presented in previous sections. If this label is not hidden in synthesised component models, then the occurrence of endAction

signals that the A and T have reached an end state.

The addition of endAction

is an artefact needed to perform implied scenario detection in

LTSA, and is not required in the general framework we present in this thesis. Thus, we only refer to endAction

in the remainder of this section, where we consider it to be observable in all synthesised components. A consequence of this is that all component models, and both architecture and trace models are deterministic. In addition, and to simplify proofs of this section, we consider the component interfaces to include endAction

, and finite traces specified in an MSC specification to have endAction

as their last message. It is simple to see that properties described in previous chapters can be extended to these changes.

We now introduce the notion of deadlock formally and prove some properties of the minimal architecture models the algorithm of Section 4.3.1 synthesises.

Definition 6.12 (Deadlocks) Given a LTS P =( S , L , ∆ , q ), we say that a state s ∈ S is a deadlock state if s ∉ { ε , π } has no enabled transitions. We say that a trace w is a deadlock trace in P if there is an execution e in ex ( P ) such that e |

α (P)

= w and the last state in e is a deadlock state.

In a synthesised architecture model A =(( A

1

||…|| A n

), all deadlock traces correspond to implied scenarios: suppose w is a deadlock trace in A, if it were a trace of L ( PSpec ) then, from Lemma

4.1 of page 74, for all components A i

we have w|

α (i)

∈ mt ( A i

). Furthermore, from the component synthesis algorithm we know that w|

α (i)

must always lead to the end state in A i

. Thus, in the parallel composition of all A i

trade w must lead to the end state in A . This is a contradiction as

100 Chapter 6. Implied Scenario Detection we had assumed that w is a deadlock trace. Thus, we have w ∉ L ( PSpec ). Let us suppose there is an architecture model A ' and an extension y to w such that w.y

∈ mt ( A ') and w.y

∈ L ( PSpec ) then as A is minimal w.y

∈ tr ( A ) which is absurd as A is deterministic and w is a deadlock trace. Thus we have that w is an implied scenario.

Property 6.1 Let A be the synthesised architecture model of a positive MSC specification

PSpec . If w is deadlock trace, then w is an implied scenario of PSpec .

Another property of interest of is all traces of a minimal architecture model A that are not traces of a trace model T are implied scenarios: suppose w ∈ tr ( A )\ tr ( T ), then w ∉ mt ( T ) and w ∉ L ( PSpec ). Furthermore, any extension y to w results in w.y

∉ L ( PSpec ). Consequently, given any architecture model A ' and an extension y to w such that w.y

∈ mt ( A ') we have w.y

∉ L ( PSpec ).

Thus, w is an implied scenario.

Property 6.2 Let A be the synthesised architecture model of a positive MSC specification

PSpec and T an LTS model such that mt ( T ) = L ( PSpec ). If w ∈ tr ( A )\ tr ( T ) then w is an implied scenario.

From the properties above, we know that to detect implied scenario we need to check for the following trace inclusion tr ( A ) ⊆ tr ( T ) and for deadlocks in A.

In Section 6.1 we have shown how to build the trace model T with extended component models and a finite coordinator:

T =( E

1

||…|| E n

|| Coord f

)\ H . Checking for trace inclusion in LTSA is straightforward; it can be done using the code in Figure 6.5. Firstly, we define declare the

TraceModel

process as deterministic.

This force LTSA to construct the minimal trace equivalent LTS to

TraceModel

while preserving

END states. Secondly, using the FSP property keyword, we extend the LTS with an error state π , and transitions labelled l to π from every state s in which l is not enabled. We then compose the safety property with the architecture model (see process

ImpScenarioCheck

) and use the safety check feature of LTSA to analyse if the error state π is reachable in the composed model.

…/* FSP code for ArchitectureModel and TraceModel with endAction not hidden */… property ||ImpScenarioProperty = TraceModel.

||ImpScenarioCheck =(ImpScenarioProperty||ArchitectureModel).

Figure 6.5 – FSP code for detecting implied scenarios using LTSA

The declaring

TraceModel

as a safety property and checking it

ArchitectureModel guarantees that a property violation example is produced by LTSA if and only if there is a trace of the

ArchitectureModel

that is not a trace of

TraceModel

. Furthermore, when

Section 6.3 Implied Scenario Detection using LTSA 101 performing safety checks, deadlock detection is also performed. As the

TraceModel

has all labels enabled on every state, any deadlock of the composite process is also a deadlock in the

ArchitectureModel

. Thus, from the properties discussed above, any output produced by

LTSA is an implied scenario.

What remains to be discussed is if an implied scenario is guaranteed to be detected if the original specification has implied scenarios. In other words, we need to prove the following property:

Property 6.3

Let A =(( A

1

||…|| A n

), be the synthesised architecture model of a positive MSC specification PSpec . If w is an implied scenario of PSpec then there is a trace w ’ ∈ tr ( A ) such that w ’ is a deadlock trace or w ’ ∉ tr ( PSpec ).

This property can be proved as follows: suppose w is an implied scenario of PSpec , from

Property 5.1 and Lemma 4.1, we know that w |

α (i)

∈ tr ( A i

). Thus, we have w ∈ tr ( A ) and consequently, there must be a trace w ’ and an extension y for w such that w ’= w .

y ∈ mt ( A ). From the definition of implied scenarios, we know that w ’ ∉ L ( PSpec ). Thus we have a trace w ’ ∈ mt ( A )\ L ( PSpec ). Because w ’ is maximal, there are 3 different cases to analyse. Firstly, when w ’ is an infinite trace; secondly when w ’ is a deadlock (and consequently finite) trace; and finally when w ’ is a finite trace that leads an

END

state. Note that A has no error states so its finite traces are either deadlocks or successfully terminating.

If w ’ is infinite, then w ’ ∉ L ( PSpec ) implies w ’ ∉ tr ( PSpec ). Thus, we have a trace w ’ ∈ tr ( A ) such that w ’ ∉ tr ( PSpec ). If w ’ deadlock trace, then we have found a trace w ’ ∈ tr ( A ) such that w ’ is a deadlock trace. Finally, if w ’ is finite and leads to an

END

state we have two possibilities: if w ’ ∉ tr ( PSpec ) then we are done. If w ’ ∈ tr ( PSpec ) then w ’ can be extended with a trace y ’ such that w ’ y ’ ∈ L ( PSpec ). Because we have w ’ y ’ ∈ mt ( A ), from Lemma 4.1 in page 74, we know that there must be a component A i

in A such that w ’ y ’|

α (i)

∈ mt ( A i

) and where w ’ y ’|

α (i)

extends w ’|

α (i)

.

However, as A i

is deterministic then the state that the component is in when A executes w ’|

α (i) cannot be an

END

state. This is a contradiction stemming from the assumption w ’ ∈ tr ( PSpec ), thus we have w ’ ∉ tr ( PSpec ).

Consequently, from the three cases discussed above, we have proved Property 6.3, which together with Property 6.1 and Property 6.2, prove that by performing a safety check and a deadlock check on

ImpScenarioCheck

, we are guaranteed to find an implied scenario in A if and only if the positive MSC specification has one. In addition, as LTSA performs a deadlock check automatically every time a safety check is run, performing a safety check on

ImpScenarioCheck

suffices to detect implied scenarios. Furthermore, when performing a

102 Chapter 6. Implied Scenario Detection safety check on

ImpScenarioCheck,

LTSA outputs a trace if there is a deadlock or a property violation. The trace outputted by LTSA is an implied scenario, and in the case of safety violations, its last message label is the first message of the implied scenario that corresponds to unspecified behaviour. This point in the implied scenario is where the architecture model deviates from specified behaviour.

In the Boiler Control System, the LTSA output indicating that an implied scenario exists is shown in Figure 6.6. It corresponds to the implied scenario we have been discussing in previous sections (see Figure 5.1).

Trace to property violation in DetProperty:

on

pressure

off

on

query

Figure 6.6 – First implied scenario detected by LTSA

6.4 Discussion

Alur et al proposed the first implied scenario detection algorithm [Alur et al 2000]. However, due to the restricted scenario language (finite sets of finite bMSCs) the issue of constructing architecture models and detecting implied scenarios is limited to a finite set of finite traces. In

[Uchitel et al 2001], we extended their work to include high-level MSCs allowing specification of an infinite number of (possibly infinite) system traces but restricting our approach to synchronous component communication and bounded MSCs. Our setting can be extended to allow for bounded asynchronous communication by using buffer abstractions; however, this may lead to untractable state explosion. Alur et al have extended their initial work to include hMSCs in [Alur et al 2001], they also restrict their approach to bounded MSC specifications. An important difference in our work is that, as we discuss further on, the method we propose can be extended to be used with negative scenario specifications. This is crucial in the setting we are proposing for system model elaboration. We compare our work with that of Alur et al in more detail in subsequent chapter once we have introduced all the elements that comprise the elaboration process we propose.

The other implied scenario detection algorithm that has been developed is by Henry Muccini

[Muccini 2001]. The algorithm supports hMSCs and synchronous communication, and performs an efficient syntactic analysis of the scenario specification; at the expense of failing to detect all implied scenarios. The result of the detection process is not a trace corresponding to an implied

Section 6.4 Discussion 103 scenario, but a collection of elements in the specification’s hMSC that produce the implied scenario. As we discuss further on, this may be problematic when validating implied scenarios and further elaborating the scenario specification. We return to Muccini’s work in subsequent chapters.

The implied scenario detection method discussed in [Uchitel et al 2001] differs significantly from the one presented in this thesis. The previous method [Uchitel et al 2001] is based on verifying if a minimal architecture model satisfies a specially tailored safety property. Although the detection method works with non-regular MSC specifications, it is not complete with constrained minimal architecture models. This is because the safety property synthesis is tightly coupled with the architecture model synthesis. Thus, the method is not adequate in the elaboration process we describe in this thesis.

Next, we would like to refer to the methods used by the protocol synthesis to avoid unspecified services. As discussed before, these unspecified services could be considered implied scenarios, thus, if they are to be avoided, there is in a way an implicit detection of the situations in which these may occur. The methods used by in protocol synthesis are, in some respects similar to the

Muccini’s approach. The service specification is analysed syntactically and points in which a deviation may occur in the synthesised implementation, additional synchronisation mechanisms are introduced. However, an important difference is that service specifications are given using regular expressions or process algebra with no synchronisation operators. Using either of these, instead of the partial orderings defined by bMSCs weak sequential semantics, considerably simplifies the task of detecting where behavioural deviations may occur.

The mechanism we use for detecting implied scenarios is based on analysing if a behaviour model satisfies a given property. From this perspective, there is a significant amount of related work. In particular, there has been extensive work on coping with the state-explosion problem of model checking (see [Cleaveland and Smolka 1996] for an overview). This body of work has enabled model checkers in general, and LTSA in particular, to cope with the complexity of model checking properties such as the ones used for implied scenario detection. Managing state explosion and efficiency is not the primary focus of the work presented in this thesis. We have developed some heuristics for reducing the size of the property (the trace model) that we construct. However, the main issue has been to bring the state space to a tractable size in order to allow for experimentation using implied scenarios to drive the elaboration process. Future work will certainly address issues of complexity.


On Deadlock and Implied Scenario Detection.

As discussed extensively this chapter, a particular case of implied scenarios is that of deadlocks.

All deadlock traces of a synthesised architecture model are implied scenarios. However, it is not the case that all implied scenarios are deadlock traces. In fact, the minimal architecture model of the Boiler Control system shown in Figure 4.18 does not have deadlock states; however, it does have implied scenarios. Interestingly, in many cases, when deadlock traces are present, by performing a safety check against the trace model, one obtains more diagnostic information than if only a deadlock check is performed. This is because when using a model checker for deadlock detection, the output produced is a trace that leads to the deadlock state. When an implied scenario is detected, LTSA shows where the system deviates from specified behaviour. This deviation is the cause for the system eventually reaching a deadlock state. Thus, while implied scenario detection shows the cause of the deadlock (where things went wrong), deadlock detection buries the cause in the middle of a potentially very long trace.

Vehicle at Terminal

Terminal 1 Vehicle Terminal 2 Passenger 2 buyTicket displayGate enter setDestination departReq departAck alert100 arriveReq arriveAck arrived exit

Vehicle at

Terminal

Vehicle not at

Terminal

Vehicle not at Terminal

Passenger 1 Terminal 1 buyTicket

Vehicle Control Centre Terminal 2 requestVehicle orderVehicle setDestination alert100 departReq departAck displayGate enter arriveReq arriveAck arrived setDestination departReq departAck orderAck alert100 arriveReq arriveAck arrived exit

Figure 6.7 – Two bMSCs for a Transport System

As an example, consider the positive MSC specification of Figure 6.7 (These scenarios correspond to the case study that we discuss in Chapter 8). If we check for implied scenarios, we would obtain the output of Figure 6.8 from LTSA. It is the result of a property violation and indicates that in a trace of only two messages, the architecture model can deviate from specified behaviour. The implied scenario corresponds to when a passenger at each terminal buys a ticket.

Note that in the MSC specification we have omitted prefixes “ t1

.” and “ t2

.” for clarity, but they are needed to distinguish messages sent and received by the different terminals). If only a deadlock-freedom check were performed on the architecture model, we would obtain the output of Figure 6.9. Note how the messages of the implied scenario (in boldface), which are the cause of the deadlock, have not even appeared together in the trace.


In short, by checking trace inclusion of the architecture model in the trace model, it is possible to obtain better feedback on deadlocks of the architecture model than by performing deadlock checks. The former provides in a shorter trace, the cause for the deadlock, while the latter provides the whole deadlock trace, burying the cause in the deadlock trace itself.

Trace to property violation in DetProperty: t2.buyTicket t1.buyTicket

Figure 6.8 – Property violation trace

Trace to DEADLOCK:

t2.buyTicket

t2.displayGate

t2.setDestination

t2.departReq

t2.departAck

t1.alert100

t1.arriveReq

t1.arriveAck

t1.arrived

t1.buyTicket

t1.requestCar

t2.orderCar

STOP

Figure 6.9 – Deadlock trace

6.5 Summary

Summarising, in this chapter we explained how to detect implied scenarios in a positive MSC specification. We described how from a positive regular scenario specification ( PSpec ), using the traces it defines ( L ( PSpec )), a trace model can be built ( T = ( E

1

||…|| E

1

|| Coord f

)\ H ) such that it describes exactly the specified traces ( mt ( T ) = L ( PSpec )). We have also shown how the to detect implied scenarios by model checking mt ( A ) ⊆ mt ( T )) In terms of the overview of Section

1.4, we have introduced the highlighted parts of the diagram shown below. Note that in the figure, the model check is performed on a constrained architecture model ( A || C ). We introduce constraint models in the next chapter.


Positive

Scenarios

( PSpec )

Negative

Scenarios

( NSpec )

Architecture

Traces

( L(PSpec)

)

Traces

( L(PSpec)

)

Traces

( L(NSpec)

)


Architecture Model

Synthesis


L ( PSpec ) ⊆ mt ( A ) A = ( A

1

L A n

)

Trace Model

Synthesis

Constraint Model

Synthesis


Model Check

( mt ( A ) ⊆ mt ( T )) ?




Chapter 7

Chapter 7 Specifying Negative

Scenarios

In this section, we motivate the need for documenting implied scenarios that are deemed unacceptable system behaviour by stakeholders. We call these negative scenarios, introduce a notation for documenting them, and discuss how implied scenarios can be detected in the presence of negative scenarios. In fact, we provide three kinds of negative scenarios. The first is a very simple notation that allows stakeholders to rapidly reject implied scenarios, in a push button style, and to continue checking for more implied scenarios. The other two notations are more expressive, and are needed to allow taking the MSC specification to a state where all implied scenarios have been validated.

7.1 Basic Negative Scenarios

Let us suppose that the implied scenario of Figure 5.1 is taken back to stakeholders for validation. In addition, suppose that stakeholders understand that a query is retrieving old information from the Database because the last pressure reading is from a previous Sensor session. Consequently, they decide that the implied scenario is unacceptable system behaviour.

A first reaction could be to require stakeholders to review the MSC specification they have provided and to correct it to avoid the mismatch that gives rise to the implied scenario.

However, the only way to avoid the implied scenario is through design. Stakeholders would have to contrive mechanisms, such as additional synchronisation messages and/or new components, to prevent the implied scenario from occurring. This approach is unsatisfactory for a number of reasons. Stakeholders may lack the technical skills to make such design decisions; taking such design decisions at an early requirement stage may be undesirable; and finally, having to stop the process of model elaboration to solve design issues may be inopportune.

We believe that documenting rejected implied scenarios and then producing more feedback in terms of implied scenarios can make the elaboration process more dynamic. In addition, it would allow explicit documentation of undesired situations as opposed to doing so implicitly by providing a design solution. Thus, we extend the notions discussed in previous sections to include negative scenarios, a notation for documenting behaviour that the system is expected

108 Chapter 7. Specifying Negative Scenarios not to have. We now define a simple form of negative scenario and explain how to detect implied scenarios when this form of negative scenarios is used.

7.1.1 Syntax and Semantics

We depict basic negative scenarios as bMSCs with three additional characteristics (see Figure

7.1). The first is that the last message is crossed out, we call it the proscribed message; the second is that the crossed out message is separated from previous messages by a dashed line.

The part of the bMSC that is above the dashed line is called precondition. The third difference is the black dot and arrow on the top part of the scenario. Intuitively, the meaning of basic negative scenarios is that once a trace described by the precondition has occurred, the next message should not be the proscribed message. The dotted line is to convey that the precondition must occur completely before the crossed out message is proscribed (i.e. partial orderings between the proscribed message and messages in the precondition are not considered).

The black dot and arrow are to emphasise that the precondition describes system behaviour from its initial state. As an illustration, consider Figure 7.1. This negative scenario specifies that the system may not exhibit traces with the following prefix: on , pressure , off , on , query .

Neg1

Sensor Database on pressure off on

Control Actuator

Precondition query

Proscribed message

Figure 7.1 – Example of a basic negative scenario

Formally, a basic negative scenario can be defined as a pair ( p, l ) where p is a bMSC modelling the negative scenarios precondition, and l is the label of the proscribed message. In terms of expressiveness, basic negative scenarios are very limited. This is deliberate as we wish to keep this notation as simple as possible. Our intention is to use basic negative scenarios to reject implied scenarios in a very simple, push-button way. Undoubtedly, moving from the implied scenario of Figure 5.1 to the negative scenario of Figure 7.1 is trivial for whoever decides on rejection. Simplicity in rejecting implied scenarios is crucial if we are to have a dynamic elaboration process.

In the remainder of this thesis, given an implied scenario w = w

1 lw

2

, where l is the point where the w deviates from specified behaviour, we say that a negative scenario results from rejecting w

Section 7.1 Basic Negative Scenarios 109 if it has been constructed with a bMSC that models w

1

and proscribes message l .

In practical terms, this is equivalent to, using the LTSA output to trivially build Neg1 . Consequently, the negative scenario of Figure 7.1 results from rejecting the implied scenario of Figure 5.1.

Definition 7.1 (Basic Negative Scenarios) A negative scenario n is a pair ( p, l ) where p is a bMSC, and l is a message label. We use α ( n ) to denote α ( p ) ∪ { l }.

We must now define what basic negative scenarios mean in the context of MSC specifications.

We need to consider that MSC specifications comprise both a positive and a negative part. The positive part consists of a high-level MSC and its corresponding basic MSCs; this corresponds to our previous definition of positive MSC specifications. The negative part consists of a set of basic negative scenarios. Additionally we require labels to denote messages consistently in both positive and negative parts of a MSC specification.

Definition 7.2 (MSC Specifications) A MSC specification is a structure Spec =( PSpec, NSpec ) where PSpec a positive MSC specification as described in Chapter 3 and NSpec is a set of negative scenarios. We require α ( NSpec ) ⊆ α ( PSpec ) and use α ( Spec ) to denote the union of the alphabets of the scenarios in PSpec and NSpec .

Definition 7.3 (Basic Negative Scenario Semantics) Let Spec = ( PSpec, NSpec ) be a MSC specification, and n = ( p, l ) a basic negative scenario in NSpec . The set of traces proscribed by n is L ( n ) = { w.l.w

’ ∈ α ( Spec )* | w ∈ L ( p )}. We also define L ( NSpec ) as the union of the all L ( n ) with n ∈ NSpec .

An initial approach to the semantics of a MSC specification could be to consider it as the set of traces specified by the positive part that are not proscribed by the negative part of the specification. However, we actually expect no such trace. This would signify an inconsistency in the specification, as the trace would be both described as acceptable and unacceptable behaviour. We therefore introduce the notion of inconsistency:

Definition 7.4 (Inconsistent MSC Specifications) Given a MSC specification Spec =( PSpec,

NSpec ). The specification is said to be inconsistent when if L ( PSpec ) ∩ L ( NSpec ) ≠∅ .

The addition of a basic negative scenario to a MSC specification does not always result in an inconsistency. In particular, this is the case if the basic negative scenario is the result of rejecting an implied scenario. By definition, an implied scenario is not part of the specified behaviour, thus a basic negative scenario resulting from it does not subtract traces from the positive part of a MSC specification. In the Boiler Control system example, the behaviour in

Figure 5.1 describes an implied scenario because no specified behaviour can have the prefix: on ,

110 Chapter 7. Specifying Negative Scenarios pressure , off , on , query . It follows that the negative scenario of Figure 7.1 does not proscribe any traces from those specified in Figure 3.1. Thus, we have the following property:

Property 7.1 Let Spec = ( PSpec, NSpec ) be a consistent MSC specification. Let w be an implied scenario of PSpec and n the basic negative scenario resulting from rejecting w . Adding n to

NSpec results in a consistent MSC specification.

In the work presented in this thesis we are interested in using negative scenarios to document rejected implied scenarios thus we assume consistent MSC specifications. We discuss how to check for consistency in Section 7.4.

7.1.2 Implied Scenario Detection

Although negative scenarios do not alter the traces specified by the positive part of a specification, they do provide useful information. Negative scenarios can be thought of as properties that the behaviour model for the system to be developed must satisfy. In our example, we expect the behaviour model for the Boiler Control system to not exhibit the following initial behaviour: on , pressure , off , on , query .

In addition, negative scenarios provide information as to whether a certain implied scenario corresponds to undesired system behaviour. Thus, we need to reformulate the detection of implied scenarios in the context of MSC specifications that have negative scenarios. We are now interested in detecting implied scenarios that have not been explicitly proscribed by the negative part of the MSC specification. In other words, instead of checking mt ( A ) ⊆ L ( PSpec ) with A the minimal architecture model of the positive scenarios PSpec , we now need to check mt ( A )\ L ( NSpec ) ⊆ L ( PSpec ). Thus, we need to build a model Constrained ( A ) such that mt ( Constrained ( A )) = mt ( A )\ L ( NSpec ).

Note that the notion of implied scenario does not change; however the implied scenarios we are interested in for validation do change.

In essence, what we do is for each basic negative scenario n =( p, l ) we build a deterministic LTS c such that mt ( A || c ) = mt ( A )\ L ( n ). We rely on parallel composition to do the actual constraining as it forces both LTSs to synchronise on shared labels. Thus, we build c in such a way that it keeps track of the negative scenario’s precondition p . When p occurs, then the LTS does not allow l from occurring immediately, while all other message labels are enabled. Note that we require determinism to avoid introducing deadlocks in the composition of the constraint with the architecture model.

Summarising, we build a deterministic LTS c to model all possible traces on the alphabet

α ( Spec ) that are not proscribed by n ( tr ( c )= α ( Spec )* \ L ( n )). Building such a LTS is

Section 7.1 Basic Negative Scenarios 111 straightforward, we provide a declarative definition for such constraints and exemplify by applying the definition to the negative scenario shown in Figure 7.1. The resulting LTS is that of Figure 7.2.

Definition 7.5 (Basic Negative Scenario Constraint) Given a MSC specification Spec and a basic negative scenario n = ( p, l ), the LTS constraint for n is ( S, α ( Spec ) , ∆ , q ) where: a. S = P ∪ { f } where P = { w | w is a prefix of w ’ ∈ L ( p )}. b. q ∈ S such that | q | = 0 . c. ∆ ⊆ ( S × α ( Spec ) × S ) such that ( s, m, s ’) ∈ ∆ if c1. s ∈ P \ L ( p ) , s ’ ∈ P and s.m = s ’, or c2. s ∈ L ( p ) , s ’= f, and m ≠ l, or c3. s = s ’= f, or c4. s ∈ P \ L ( p ) , s ’= f, and there is no s ’’ ∈ P such that s.m = s ’’.

The LTS must keep track of the occurrence of the negative scenario’s precondition and disallow the proscribed message from occurring. To do so, the LTS must have a state for each prefix of a trace specified in the negative scenario plus an additional final state (see rule a. of the above definition). The state modelling the empty prefix is the initial state (see rule b.). In Table 7.1 we show the mapping from states of LTS in Figure 7.2 to prefixes. on

{command, data, off, pressure,

} pressure

{command, data, off, on,

}

{command, data, on, pressure,

} off

{command, data, off, pressure,

} on {command, data, off, on,

}

0 1 2 3 4

Figure 7.2 – LTS of basic negative scenario of Figure 7.1

5

{command, data, off,

on, pressure, query}

2

3

4

5

0

1

⟨⟩

⟨ on ⟩

⟨ on, pressure ⟩

⟨ on, pressure, off ⟩

⟨ on, pressure, off, on ⟩ f

Table 7.1 – Prefixes modelled by states of Figure 7.2

LTS transitions link states such that the proper prefix modelled by the target state is the concatenation of the prefix modelled by the source state and the transition’s label (see rule c1.).

112 Chapter 7. Specifying Negative Scenarios

This ensures that the LTS keeps track of traces that could lead to the proscribed behaviour. For example, the transition from state 3 to state 4 is labelled on which is consistent with the prefixes modelled by the states: on , pressure , off and on , pressure , off , on .

States modelling traces specified by the negative scenario’s precondition (state 3 in Figure 7.2) model that the precondition has occurred and that the proscribed message must not be allowed to occur. These states are linked with the final state with a transition for each message label of the precondition’s alphabet that is not proscribed (see rule c2.). Thus, state 3 in Figure 7.2 there are transitions to state 4 labelled on , off , and pressure but not query .

The final state models the case when there is no need to keep track of the behaviour and all message labels are allowed to occur (see rule c3). This state should be reached in two different cases. The first is if the precondition has occurred and the proscribed message has been forced to not occur. For example, once the sequence on , pressure , off , on, pressure has occurred, there is no need to keep track of the precondition; any sequence of message labels should be allowed.

The second case is when the trace that LTS is tracking does not coincide with the precondition.

For example, if on , off occurs, then the precondition never is satisfied and all message labels should be allowed from then on. In these cases, the precondition can no longer occur; thus, no constraining is necessary and all message labels should be allowed. Consequently, for every state s modelling a proper prefix and every message label m not enabled in s , a transition labelled m to the final state is added (see rule c4.).

We now have a deterministic LTS c built from a negative scenario n =( p, l ) such that mt ( c )= α ( Spec )* \ L ( n ). In addition, we know that the architecture model of Spec is deterministic as it is the parallel composition of deterministic components. Thus, from Property 4.1 (which follows from the definition of parallel composition) it follows that mt ( A || c )= mt ( A )\ L ( n ).

Furthermore, this result can be extended to a set of basic negative scenarios. Thus if we have a specification Spec = ( PSpec, NSpec ) with NSpec ={ n

1

, … ,n m

}, and we build a constraint c i

for each n i

then mt ( A || C ) = mt ( A )\ L ( NSpec ) where C = ( c

1

||…|| c n

). The parallel composition of the constraints of all negative scenarios of a MSC specification Spec is called the constraint model of Spec .

Consequently, we can compare the traces of the constrained architecture model A || C against those of the trace model T to detect implied scenarios that have not been validated. This amounts to checking mt ( A || C ) ⊆ mt ( T ), or as shown in Section 6.3, to checking A || C against model T declared as a property and checking that A || C is deadlock free. In our example, if we compose the minimal architecture model of the Boiler Control system (see Figure 4.18) with the

Section 7.2 Abstract Negative Scenarios 113

LTS constraint shown in Figure 7.2, and then check for trace inclusion against the trace model of Figure 6.3 we obtain the LTSA output of Figure 7.3.

Trace to property violation in ImpliedScenarioCheck: on pressure query data command off

Figure 7.3 – Second implied scenario of the Boiler Control system

Neg2

Sensor Database on pressure query data

Control Actuator command off

Figure 7.4 – Basic negative scenario resulting from Figure 7.3

The newly detected implied scenario reveals another consequence of the mismatch between the specified behaviour and architecture: the Control component can terminate the Sensor session immediately after having queried the Database . This cannot be a specified trace because the hMSC in Figure 3.1 states that after an Analysis bMSC a Register bMSC must occur. As in the previous implied scenario, the cause lies in the components’ lack local information on what is occurring at system level. The Control component cannot see when new information has been stored in the Database so it cannot tell when it is allowed to turn the Sensor off . The Sensor is not aware of queries to the Database and hence has insufficient information to disallow being turned off by Control .

As before, this new implied scenario may or may not be acceptable system behaviour.

Consequently, it must be validated with stakeholders; and according to the response, a negative or positive scenario would be added to the MSC specification.

7.2 Abstract Negative Scenarios

Let us assume that the stakeholders deem that the new implied scenario mentioned above represents an undesired behaviour. Thus, we obtain a new negative scenario (Figure 7.4) from

114 Chapter 7. Specifying Negative Scenarios which a new constraint can be built to check for further implied scenarios. By repeating this process, one would expect to eventually reach a specification such that its architecture model, restricted by all negative scenarios, does not exhibit more implied scenarios. However, with the basic negative scenario notation presented before, this is rarely the case.

Consider the MSC specification of the Boiler Control system of Figure 3.1 together with negative scenarios of Figure 7.1 and Figure 7.4. If we check for further implied scenarios, we obtain the following LTSA output.

Trace to property violation in ImpliedScenarioCheck: on pressure pressure off on query

Figure 7.5 – Third implied scenario of the Boiler Control system

The implied scenario is a variation of the first implied scenario we encountered (Figure 5.1).

The difference is that two pressure messages are occurring in this scenario. Clearly, if we add another negative scenario for this case, we then find a similar implied scenario with three pressure messages. Consequently, this process does not converge to a specification where all implied scenarios have been validated.

Stakeholders may add several basic negative scenarios rejecting examples with increasing number of pressure messages. However, at some point, a more abstract explanation is needed indicating what these negative scenarios have in common that makes them unwanted behaviour.

The fact is that the number of pressure messages is irrelevant. The reason why these implied scenarios are unwanted behaviour is that query should never occur immediately after on . A more expressive negative scenario notation is needed.


Basic negative scenarios are inadequate because they only specify prefixes of the traces to be prohibited. In the above case, we need to prohibit traces that exhibit some sequence of messages that does not necessarily have to occur at the beginning of the trace. These more expressive negative scenarios consist of a precondition p, a proscribed message l and do not have a black dot and arrow on the top. This is to indicate that the negative scenario does not specify prefixes.

An additional feature is that the alphabet of the precondition can be explicitly extended with a set of labels. The text " Alphabet Extension: ALL " on the top right corner of the scenario in

Figure 7.6 extends the alphabet of the precondition to have all the message labels of the scenario

Section 7.2 Abstract Negative Scenarios 115 specification. In Figure 7.7, the precondition's alphabet is extended with { r } making the preconditions extended alphabet the following { p, q, r }.

Neg3

Sensor Database

Alphabet Extension:ALL

Control Actuator on query

Figure 7.6 – Example of an abstract negative scenario

Neg4

Sensor q

Alphabet Extension: {r}

Database Database p m

Figure 7.7 – Abstract negative scenario with alphabet extension

The alphabet of preconditions impacts the traces that abstract negative scenarios proscribe. The fact that a message label is not in the precondition’s alphabet means that the occurrence of such message labels is irrelevant with respect to the satisfaction of the precondition. Consider Figure

7.7, similarly to the semantics of basic negative scenarios, this negative scenario is considered to proscribe the sequence of the form … p, q, m …. However, it is also considered to proscribe traces of the following form … p, s, q, m …. This is because the precondition does not predicate on the occurrence of message labels that do not belong to its alphabet (in this case s ). The extension of the precondition's alphabet in Figure 7.7 means that the negative scenario does not proscribe traces with the following sequences: … p, r, q, m …

In short, preconditions proscribe with respect to their own alphabet. This means that negative scenarios can abstract away certain message labels used in the MSC specification. This capability is an important difference with respect to the negative scenarios defined previously.

Note that the negative scenario of Figure 7.6 does not abstract away any message labels as the precondition’s alphabet has been extended with the keyword “All”. We now define abstract negative scenarios and their semantics formally.

Definition 7.6 (Abstract Negative Scenarios) A negative scenario n is a pair ( p, E, l ) where p is a bMSC, E is a set of message labels and l is a message label. We use α ( n ) to denote

α ( p ) ∪ E ∪ { l }.

Definition 7.7 (Abstract Negative Scenario Semantics) Let Spec = ( PSpec, NSpec ) be a MSC specification, and n =( p, E, l ) an extended negative scenario in NSpec . The set of proscribed traces by n is L ( n ) = { x.y.l.z ∈ α ( Spec )* | y |

A

∈ L ( p )} where A = α ( p ) ∪ E .

As before, we need to extend the definition of MSC specifications to allow abstract negative scenarios. In addition, we continue to assume that MSC specifications are consistent. However, we no longer have some guarantees that negative scenarios does not introduce inconsistency, as

116 Chapter 7. Specifying Negative Scenarios we did with basic negative scenarios resulting from rejecting implied scenarios. However, the

LTS constraints described in the next section can be used to detect inconsistencies. We discuss how to this is done in Section 7.4.


The criterion for detecting implied scenarios is as was introduced basic negative scenarios. We need to constrain the architecture model in such a way that it does not exhibit traces that have been proscribed by an extended negative scenario. As before, we build a LTS c such that mt ( c )= α ( n )* \( L ( n )|

α (n)

) however we now use α ( n ) and L ( n )|

α (n)

instead of α ( Spec ) and L ( n ) because of the abstraction capability of these negative scenarios. Now we are only interested in keeping track of message labels in the alphabet of the precondition section. The only other difference with basic negative scenarios is that we now need to detect occurrences of the precondition not only as prefixes of system traces but at any point of the system execution. We now provide the formal definition of such LTS and explain the definition in terms of the LTS depicted in Figure 7.8 that corresponds to the negative scenario in Figure 7.6.

Definition 7.8

(LTS Constraint) Given a MSC specification Spec and a negative scenario n = ( p, E, l ) the LTS constraint for n is ( S, α ( n ) , ∆ , q ) where: a. S = { w | w is a prefix of w ’ ∈ L ( p )} b. q ∈ S such that | q | = 0 c. ∆ ⊆ ( S × α ( n ) × S ) such that ( s, m, t ) ∈ ∆ if c1. s ∈ S \ L ( p ) , and t is the largest suffix of s.m in S c2. s ∈ L ( p ) , m ≠ l, and t is the largest suffix of s.m in S on p q

0

{off, pressure, data, command, query}

1 on

{off, pressure, data, command, query}

Figure 7.8 – Constraint LTS for Figure 7.6

0

{m, q, r}

1

{m, p} p

2 r

{q, r}

Figure 7.9 – Constraint LTS for Figure 7.7

The main difference with the definition of LTS constraint for basic negative scenarios is in rule c1. When in a state s that is a prefix of the precondition, if a message m occurs that does not extend s into another prefix of the precondition, then the tracking of the precondition must be

Section 7.3 After/Until Negative Scenarios 117

“reset”. This does not mean going back to the initial state of the LTS, we must go back to the longest suffix of s.m

that is a prefix of the precondition. For example, the state 1 of the LTS in

Figure 7.8 models that on has occurred and that now query must be constrained. This is consistent with the fact that there are no outgoing transitions from state 1 labelled query . Now, if on where to occur again, the LTS should stay in state 1 because it must continue to constrain the occurrence of query . This did not occur using basic negative scenarios because there, preconditions modelled prefixes of system traces. Thus, once the system failed to follow the precondition there was no need to constrain any behaviour. Rule c2 of the definition has been changed consistently with the criteria explained above: apart from constraining l all other message labels must "reset" the LTS so it can continue to track for the precondition.

We now have a deterministic LTS c built from a negative scenario n such that mt ( c ) = α ( n )*

\( L ( n )|

α (n)

). From the definition of parallel composition, we have Property 4.2 and then that mt ( A || c )= mt ( A )\ L ( n ).

Consequently, if we return to our Boiler Control system example, we can constrain the architecture model with the LTS that in Figure 7.8 and check for further implied scenarios. The

LTSA output is shown in Figure 7.10.

Trace to property violation in ImpliedScenarioCheck: on pressure pressure query data command off

Figure 7.10 – Fourth implied scenario of the Boiler Control system

7.3 After/Until Negative Scenarios

The implied scenario shown in Figure 7.10 is similar to the second implied scenario we detected, that of Figure 7.4. As before, the difference is that now two pressure messages are occurring instead of one. The real problem is that the Sensor is being turned off immediately after an Analysis scenario. Although in this particular case, we could produce an abstract negative scenario that prohibits this negative scenario and others with different number of pressure messages, in many cases the expressiveness of abstract negative scenarios is not sufficient. For this reason we introduce after/until negative scenarios.


The essence of why the implied scenario shown in Figure 7.10 is not acceptable behaviour is that after a query the Sensor should not be turned off until more pressure information has been saved in the Database . From our experience with implied scenarios, we have found that the

After/Until structure for expressing negative scenarios is convenient and appears frequently when rejecting implied scenarios. In addition, independently of expressiveness issues, after/until negative scenarios can help capture a more abstract explanation of the scenarios that are to be proscribed.


We now define after/until negative scenarios, which essentially allows us to prohibit the occurrence of a message within a scope. These scenarios have three sections called after , not and until . Sections after and until are bMSCs that determine the scope in which the message in the not section should be proscribed. In Figure 7.11 we depict an after/until negative scenario for the Boiler Control system example; it states that after query has occurred, off is not allowed until pressure occurs. Both after and until sections are interpreted relative to their alphabets (as with abstract negative scenarios). Thus, we allow extending the alphabets of both sections independently.

ExtNeg2

After

Sensor

Alphabet Extension: {}

Database Control Actuator query

Not off

Until pressure


Figure 7.11 – Example of an after/until negative scenario

We now define negative scenarios and their semantics formally. We use w [ i,j ] to note the subtrace of w that starts on message i and ends on message j of w .

Definition 7.9 (After/Until Negative Scenarios) An after/until negative scenario is a structure n =( a, E a

, l, u, E u

) where a and u are bMSCs modelling the after and until sections of the negative scenario, l is the proscribed message label and E a

and E u are sets of message labels that extend the alphabets of the after and until sections. In addition, we require l ∉ α ( u ) ∪ E u

. We refer to the alphabet of n as α ( n )= α ( a ) ∪ Ea ∪α ( u ) ∪ Eu ∪ { l }.

Section 7.3 After/Until Negative Scenarios 119

Definition 7.10 (After/Until Negative Scenario Semantics) Let Spec = ( PSpec, NSpec ) be a

MSC specification, and n =( a, E a

, l, u, E u

) an after/until negative scenario in NSpec . The set of proscribed traces by n is L ( n ) = { w ∈ α ( Spec )* | ∃ ijk : i < j < k, w [ i,j ] is a minimal sub-trace of z such that w [ i,j ]|

A

∈ L ( a ), w k

= l , and for all sub-trace w ’ of w [ j + 1,k 1 ], w ’|

U

∉ L ( u )} where A =

α ( a ) ∪ E a

and U = α ( u ) ∪ E u

.

As before, we no longer have any guarantee on the consistency of a specification that has been extended with an after/until negative scenario. However, the LTS constraints described in the next section can be used to detect inconsistencies. We discuss this in Section 7.4.


The criterion for detecting implied scenarios is the same as before. We build a LTS c such that mt ( c )= α ( n )* \ L ( n )|

α (n)

. However, there are two new issues: one is that there are two sections to keep track of (after and until) instead of only one (precondition). The other is that these two sections may have different alphabets. We now provide the formal definition of such LTS and explain the definition in terms of the negative scenario in Figure 7.11.

Definition 7.11 (LTS Constraint) Given a MSC specification Spec, a negative scenario n = ( a,

E a

, l, u, E u

) and sets A = α ( a ) ∪

E a and U = α ( u ) ∪

E u

.

The LTS constraint for n is ( S, α ( n ) , ∆ , q ) where: a. S = P a

∪ P u where P a

= { w | w is a proper prefix of some trace in L ( a )} and P u

= {( w a

, w u

) | w a is a prefix of some trace in L ( a ) , and w u is a proper prefix of a trace in L ( u )}. b. q ∈ P a such that | q | = 0 . c. ∆ ⊆ ( S × α ( n ) × S ) such that ( s, m, t ) ∈ ∆ if all the following hold: c1. If s ∈ P a

, and s.m

|

A

∉ L ( a ), then t is the largest suffix of s.m

|

A in P a c2. If s ∈ P a

, and s.m

|

A

∈ L ( a ), then t =( t a

, t u

) ∈ P u

, t a

= s.m

|

A

, and | t u

|= 0 c3. If s =( s a

, s u

) ∈ P u

, s a

.m

|

A

∉ L ( a ), s u

.m

|

U

∉ L ( u ), then t =( t a

, t u

) ∈ P u

, t a is the largest suffix of s a

.m

|

A in P a

, and t u is the largest suffix of s u

.m

|

U in P u c4. If s =( s a

, s u

) ∈ P u

, s a

.m

|

A

∉ L ( a ), and s u

.m

|

U

∈ L ( u ), then t = s a

.m

|

A c5. If s =( s a

, s u

) ∈ P u

, s a

.m

|

A

∈ L ( a ), and s u

.m

|

U

∉ L ( u ), then t =( t a

, t u

) ∈ P u

, t a

= s a

.m

|

A

, and | t u

|= 0 c6. If s =( s a

, s u

) ∈ P u

, s a

.m

|

A

∈ L ( a ), s u

.m

|

U

∈ L ( u ), and m ∈ A , then t =( t a

, t u

) ∈ P u

, | t u

|= 0 , and t a

= s a

.m

c7. If s =( s a

, s u

) ∈ P u

, s a

.m

|

A

∈ L ( a ) , s u

.m

|

U

∈ L ( u ) , and m ∉ A , then t is the largest suffix of s a in

P a

The LTS must keep track of the after section, and then prevent the proscribed message from occurring while keeping track of the until section. To keep track of the after section we use

120 Chapter 7. Specifying Negative Scenarios states to model prefixes of traces specified by the section (as we did before with preconditions).

However, to keep track of the until section there is an additional complication: it may be possible for a sequence of messages satisfying the until section to include message labels of the after section. In this case, once the until section is satisfied, part of the after section may have already occurred. Thus the LTS must go back to an appropriate state that models the portion of the after section that has occurred while tracking the until section. Consequently, while keeping track of the until section we must also do so for the after section. This is why states in the until part of the LTS model two prefixes, one for prefixes of the until section, and the other of the after section.

Regarding the part of the LTS tracking the after section, the definition introduces some changes with respect to LTSs tracking preconditions. The differences arise when a proper prefix of the after section is completed; in these cases we must start tracking the until section (see rule 2c of above definition). Additionally, there is no need to have states modelling traces that are in the language of the after section (see P a

of rule a.). Note that we need to project extensions of prefixes with message m onto the alphabet of the after section as it may be the case that m is a label belonging only to the until section.

Regarding the portion of the LTS that keeps track of the until section, there is a transition from one pair to another if the after and until prefixes of the later extend those of the former (see rule c3.). Exceptions are again related to when a proper prefix of the after or until sections are completed (see rules c4 to c7). If the occurrence of m completes the until prefix but not the after one, then we must go back to tracking the after section (see rule c4.). On the other hand, if m completes the after prefix but not the until prefix, then m must be prohibited until the until section occurs starting from this moment. Thus, the until prefix must be reset (see rule c5.).

Finally, in the case of both prefixes being completed by m, we must differentiate cases according to whether m is in the alphabet of the after section or not. If it is (rule c6.), then the after section has just been completed and (as in rule c5.) the until prefix must be reset. If m is not in the alphabet of the after section (rule c7.), then once the after section was completed, no messages within its alphabet occurred and the until section has been completed. Consequently, we must allow the occurrence of the proscribed message and start tracking the after section.

The final LTS for the negative scenario of in Figure 7.11 is shown in Figure 7.12.

Section 7.4 Consistency Checking 121 on

0 1

{pressure, query} on pressure

Figure 7.12 – Constraint for negative scenario in Figure 7.11

We now have a LTS c built from a negative scenario n such that mt ( c ) = α ( n )*\ L ( n )|

α (n)

, and from Property 4.2, we have mt ( A || c )= mt ( A )\ L ( n ). Consequently, if we return to our Boiler

Control system example, we can constrain the architecture model with the LTS that corresponds to the negative scenario shown in Figure 7.11 (see Figure 7.12), and check for further implied scenarios. Now, LTSA reports no safety errors; thus, we can conclude that we have a MSC specification for which all implied scenarios have been validated. We say these specifications are stable with respect to implied scenarios. When a specification reaches such a state the elaboration process based on detecting and validating implied scenarios is complete.

As mentioned previously, in this thesis we are interested in using negative scenarios to document rejected implied scenarios. Thus, we expect to users of our approach to define consistent MSC specifications. In other words, we expect traces that have been specified using positive scenarios not to be proscribed by negative scenarios. Clearly, inconsistencies can be introduced inadvertently by stakeholders, especially when introducing abstract and after/until negative scenarios. However, even using basic negative scenarios, inconsistencies can be introduced. Undoubtedly, for the process discussed in this thesis to be effective, automatic methods for checking the consistency of the MSC specification are needed.

Consistency detection can be performed using LTS by declaring the constraint model of the specification as a safety property. This adds an error state to the constraint model such that any trace that was previously proscribed by the model leads to the error state. Consequently, consistency can be checked by verifying the trace model, which captures the traces described by the positive part of the specification, against the constraint model declared as a safety property.

Summarising, to check for consistency using LTSA, the process

ConsistencyCheck of the following FSP code must be model checked.

122 Chapter 7. Specifying Negative Scenarios property ||ConstraintModelProperty = ConstraintModel.

||ConsistencyCheck = (ConstraintModelProperty||TraceModel).

Figure 7.13 – FSP code for detecting implied scenarios using LTSA

7.5 Discussion

Our inclusion of negative scenarios in MSC specifications is, to the best of our knowledge, novel. The ITU standard [ITU 1996] and others (e.g. [Harel and Damm 1999]), allow the inclusion of conditions in bMSCs to constrain the occurrence of a scenario. This differs from our use of negative scenarios in two ways. Firstly, we present separate constructs for specifying positive and negative behaviour. Secondly, negative scenarios do not constrain or restrict the positive part of the specification. Rather, we expect both parts of a MSC specification to be nonoverlapping (i.e. consistent). This stems from our motivation for negative scenarios: the need to document rejected implied scenarios. Our use of preconditions in basic and abstract negative scenarios is similar to the use of pre-charts in [Harel and Damm 1999].

Outside MSCs, the idea of using scenarios to describe undesirable situations is not novel. In particular there has been increasing attention in using negative scenarios or "misuse cases"

[Sindre and Opdahl 2001] for facilitating the elicitation of non-functional requirements

[Alexander 2002] and for assessing security requirements [McDermott and Fox 1999].

The After/Until notation for negative scenarios is inspired by work on property specification patterns [Dwyer et al 1998, Dwyer et al , Smith et al 2002]. However, these patterns do not allow expressing properties that include sequences of messages. Thus, we have taken their

After/Until pattern and produced an MSC-syntax to allow specification of sequences and facilitate the adoption of the notation by MSC users. Other possibilities for specifying negative scenarios include temporal logic and regular expressions. Temporal logic requires considerable expertise and is not well suited for describing sequences of events. Regular expressions can be cumbersome for describing partial ordering of events [Holzmann 1990]. Although in our experience the After/Until notation has been adequate for expressing negative scenarios, further research in this direction is needed. We believe that additional constructs of negative scenarios could be taken from [Smith et al 2002], furthermore, Smith’s approach could be extended to specify message sequences and thus using their whole framework for specifying more elaborate negative scenarios.

A notably different approach based on MSCs is that of Harel and Damm. They have developed an extension to MSCs called Live Sequence Charts (LSCs) [Harel and Damm 1999]. These

Section 7.6 Summary 123 charts can distinguish between mandatory-universal behaviour from provisional-existential behaviour. Universal behaviour is related to the notion of liveness, while existential behaviour is related to the more common approach to scenarios, that of examples of system behaviour. We interpret the positive part of MSC in the existential sense. The distinction between universal and existential behaviour is an important one, and should be made at some point in the development process. Our work is set in a previous stage, when it is more important to elaborate partial system descriptions to capture significant aspects of the potential system behaviour. Liveness can also play a role in driving the elaboration of scenario-based specifications and behaviour models and we plan to investigate into this in future work. A key difference with LSCs is that these depart from the idea of a scenario as a simple intuitive notation that can be (and is) easily adopted by a wide range of stakeholder. We believe that much benefit can and should be gained from the kind of simple scenario languages being used today, and hence prefer simpler approaches to scenarios.

In our approach, the set of positive traces are not expected to overlap with the set of negative traces; in other words, we assume positive and negative parts of MSC specifications to be consistent. Allowing and managing inconsistency in requirement specifications may deliver benefit (e.g. [Hunter and Nuseibeh 1998]). Although we do not focus on this issue, it may provide another source for driving the elaboration of scenario-based specification.

7.6 Summary

Summarising, in this chapter we have described three notations for specifying negative scenarios ( NSpec ). In addition, we have explained how using the traces such specifications define ( L ( NSpec )), a constraint model can be built ( C ) such that it constrains the minimal architecture model A from exhibiting proscribed traces ( mt ( A || C ) = mt ( A )\ L ( Nspec )). We have also shown how the to detect non-proscribed implied scenarios by model checking

( mt ( A || C ) ⊆ mt ( T )). In terms of the overview of Section 1.4, we have introduced the highlighted parts of the diagram shown below.


Positive

Scenarios

( PSpec )

Negative

Scenarios

( NSpec )

Architecture

Traces

( L(PSpec)

)

Traces

( L(PSpec)

)

Traces

( L(NSpec)

)


Architecture Model

Synthesis


L ( PSpec ) ⊆ mt ( A ) A = ( A

1

L A n

)

Trace Model

Synthesis

Constraint Model

Synthesis


(





Chapter 8

Chapter 8 Implementation & Validation

Previous chapters have presented the different parts of the elaboration process we propose. We now present the tool we have developed to support the elaboration process and discuss the case studies we have carried out in order to evaluate our approach. We discuss two case studies: a fictitious personal transportation system and a real medium-sized industrial case study. For the former, we describe in detail the implied scenario detection-validation cycles and show how the initial MSC specification is gradually elaborated. In addition, we discuss the underlying requirements and properties that are elicited through the process.

We have developed a prototype tool that fully supports the different aspects of our approach.

The tools, which we call LTSA-MSC, is an extension of LTSA that incorporate all the MSCrelated aspects of the work presented in this thesis. The tool relies on the model-checking facilities, FSP code editor, and general interface structure that LTSA already provided and that has been implemented by Jeff Magee. In addition, we have a command line synthesis tool that inputs a text file containing an MSC specification and outputs an FSP specification that can be used in the standard version of LTSA.

The implementation is in Java and consists of two main packages: the first package, mainly work by Robert Chatley, is an MSC editor that allows graphical edition of hMSCs, bMSCs and negative scenarios. This package also controls the workflow of the elaboration process, calling synthesis procedures, calling model checking procedures, requesting acceptance or rejection of implied scenarios and adding validated scenarios to the positive or negative part of the specification accordingly. The second part of the tool, implemented by the author, consists of the synthesis algorithms described in Sections 4.3.1 and 6.1 and heuristics of Section 6.2. The implementation, together with some examples (including the ones used throughout this thesis), is available at [Uchitel 2001]

Users can create a scenario specification graphically using the MSC Editor pane. The hMSC editor allows creating, linking and rearranging bMSC nodes (see Figure 8.1). Double clicking on a node or selecting a tab labelled with a bMSC name leads to the bMSC editor (Figure 8.2).

126 Chapter 8. Implementation & Validation

The bMSC editor allows adding instances and messages to the scenario. Messages are inserted by default at the end of the bMSC with the same sending and receiving instances as previous occurrences of the message label. In addition, messages can be reorganised in the bMSC.

Figure 8.1 – MSC-LTSA: the hMSC editor Figure 8.2 – MSC-LTSA: the bMSC editor

Figure 8.3 – MSC-LTSA: Synthesised FSP Figure 8.4 – MSC-LTSA: Validation

At any point, the user can press the synthesis button (depicted as ) to generate the FSP code for the three main behaviour models (architecture, trace and constraint models) and the property declarations needed for verifying consistency and detecting implied scenarios. The FSP code is displayed in the FSP Edit window (see Figure 8.3). Two safety properties can be modelchecked. The first is

ConsistencyCheck,

which verifies if there is an inconsistency between the positive and negative parts of the MSC specification. The second is

ImpliedScenarioCheck,

which detects implied scenarios. These can be chosen from the combo-box located on the tool bar (in Figure 8.3

ImpliedScenarioCheck

is selected).

Section 8.1 Tool Support 127

Checks are performed by using the Check Safety command of the Check Menu; this corresponds to the way properties are checked in the standard version of LTSA. Alternatively, a more direct way of executing implied scenario detection is with button . The button is an extension that we have added to the tool. When the button is pressed, the implied scenario detection property is automatically selected, the safety property check is executed, the model checker output is used to construct a graphical bMSC representation of property violation (the implied scenario), and the user is requested to classify the bMSC as a positive or negative scenario (see Figure 8.4).

If the scenario is classified as negative, a basic negative scenario is automatically generated (see

Figure 8.5). If the scenario is classified as positive, the user is prompted for a name for the new scenario, a new bMSC is built and its corresponding node is added to the hMSC. Normally, the user then extends the new bMSC with some additional messages and link the bMSC node to other nodes in the hMSC.

Figure 8.5 – MSC-LTSA:Negative Scenario Figure 8.6 – MSC-LTSA: Model Animation

The resulting further elaborated MSC specification can then be used to re-synthesise FSP code and continue searching for more implied scenarios. Alternatively, once new FSP code has been generated, standard LTSA features can be used to reason and further develop system design.

The designer can edit the FSP code for the architecture model, visualise component or system behaviour, use the model-checking features to check for domain-specific safety properties, and animate the model (see Figure 8.6).

The MSC-LTSA tool described above was of crucial importance in the case study evaluation of out approach. Without the FSP synthesis features, the size of the MSC specifications would have been unmanageable. In addition, by using the tool throughout the case studies, we

128 Chapter 8. Implementation & Validation identified aspects of the tool that needed further development. Note that the MSC-LTSA does not support the graphical edition of abstract and after/until negative scenarios. For these types of scenarios, we have used the command line version of the synthesiser. We now discuss two case studies we carried out to evaluate our approach. We first present a case study on a transportation system; we then report on our experience in a medium-sized industrial case study.

8.2 A Passenger Transportation System

8.2.1 Introduction

This case study is presented from the stakeholders’ point of view, with implied scenarios that must be accepted or rejected. We play the stakeholders role in taking these decisions.

Obviously, for each implied scenario, a stakeholder could give many different responses. This is particularly so, when rejecting an implied scenario: a stakeholder could come up with a number of different negative scenarios ranging from the basic negative scenario that only avoids the rejected implied scenario, to expressive negative scenarios that could take specification to a stable state with respect to implied scenarios. We have tried to keep the “foresight” of the stakeholder feedback to a minimum. This has the risk of producing a long (and perhaps tedious) case study but avoids “magic” steps and serves to show how the elaboration process can work even with only minimal effort and insight from stakeholders.

Throughout the case study, we do not explain why implied scenarios are present or discuss the behaviour models. The emphasis is on how implied scenarios drive the elaboration process from the stakeholders' point of view.

The setting is that of a personal transportation system (PTS) inspired by the example in [Harel and Kugler 2000]. Initially we know only that system consists of high-speed vehicles that transport one person at a time. Passengers can only embark at terminals, where they must buy a ticket to the destination terminal.

8.2.2 Elaboration Process

Let us suppose that stakeholders have initially provided only the two scenarios depicted in

Figure 8.7. The scenarios include two passengers, two terminals, one vehicle and a control centre. Note that by starting this case study from such a partial specification we wish to show that the approach can work even in the presence of very little initial scenario scenarios information.

Section 8.2 A Passenger Transportation System 129

A stakeholder explanation of the scenarios could be as follows: “In the first scenario, a passenger arrives at Terminal 2 and buys a ticket to another terminal. As the transport is at the terminal, the departure gate of the requested vehicle is announced. The passenger enters the transport and the terminal initiates the departure procedure by setting the vehicle’s destination. departReq and departAck are part of the departure procedure. The vehicle starts moving towards its destination and when it is 100 meters away from Terminal 1, it sends an alert. This is part of the arrival procedure, in which among other things the vehicle is directed to a specific terminal gate. The procedure continues with arriveReq , arriveAck and arrived . Finally the passenger exits the transport.”

Vehicle at Terminal

Terminal 1 Vehicle Terminal 2 Passenger 2 enter setDestination buyTicket displayGate departReq departAck alert100 arriveReq arriveAck arrived exit

Vehicle at

Terminal

Vehicle not at

Terminal

Vehicle not at Terminal

Passenger 1 Terminal 1 Vehicle Control Centre Terminal 2 buyTicket requestVehicle orderVehicle setDestination departReq departAck alert100 arriveReq displayGate enter arriveAck arrived setDestination departReq departAck orderAck exit alert100 arriveReq arriveAck arrived

Figure 8.7 – Initial version of the PTS specification

“The second scenario shows what happens when a passenger arrives at a terminal where there are no transport vehicles. In this case, once the passenger has bought a ticket, the terminal requests a vehicle to the control centre. The centre relays the request to the other terminal, where there is a vehicle waiting. Terminal 2 initiates the departure procedure (as in the previous scenario) and the transport departs. The arrival procedure is similar to the one described before.

Once the vehicle has arrived, the Terminal informs the waiting passenger of the departure gate and the scenario is similar to the previous one.”

The two scenarios are modelled as bMSCs and are marked as initial nodes in the hMSC of

Figure 8.7. This is to simplify the diagram; formally, an empty bMSC that can continue with either of the nodes of Figure 8.7 would be needed as an initial node.

Given this partial specification, we can now start checking for implied scenarios. These should raise questions in the stakeholders’ minds and prompt them to add further information relevant to the system requirements. At worst, it should force stakeholders to simply accept or reject

130 Chapter 8. Implementation & Validation implied scenarios in an almost mechanical way. In either case, the result is a richer set of scenarios that will exemplify many of the policies that the stakeholders have in mind.

Implied Scenario 1


Terminal 2 Passenger 2 buyTicket

Figure 8.8 – Implied scenario of the PTS specification (Iteration 1)

The first check for implied scenarios results in a very short scenario (see Figure 8.8). If this simple trace is shown to stakeholders for validation, it is likely to raise some of the following questions: what happens if two requests for transportation occur at the same time? Is this possible? Alternatively, should there be some kind of mechanism that avoids such a situation?

Should the system implement a first come first serve policy, or does the passenger at Terminal 2 get priority since the vehicle is already there?

These questions can lead to new scenarios that provide a more complete description of the system behaviour. However, regardless of the questions that stakeholders ask themselves due to this implied scenario, they must decide if the feedback they have received is a prefix of some acceptable system behaviour or if the system should not exhibit traces that start as shown in the implied scenario.

Let us assume that the implied scenario represents acceptable system behaviour, and that passengers may arrive and request transportation at any time. Consequently, stakeholders complete their specification with the scenario of Figure 8.9 and include it in the hMSC.

Simultaneous Requests

Passenger 1 Terminal 1 Vehicle buyTicket alert100 arriveReq arriveAck displayGate enter arrived setDestination departReq departAck requestVehicle orderVehicle enter setDestination departReq departAck orderAck exit exit

Control Centre Terminal 2 Passenger 2 buyTicket displayGate alert100 arriveReq arriveAck arrived

Vehicle at

Terminal

Vehicle not at

Terminal

Simultaneous

Requests

Figure 8.9 – Amendment to the PTS specification (Iteration 1)


The scenario shows how the vehicle that travels from Terminal 1 to Terminal 2 services the request of Passenger 2 and also answers the call from Terminal 1 for a vehicle to service

Passenger 1. Once the vehicle is at Terminal 1 and Passenger 2 has exit the vehicle, the scenario evolves as “Vehicle at Terminal 1”. In fact, to stress this, the specification could be re-factored as in Figure 8.10.

Passenger at Terminal 2

Terminal 1 Vehicle Terminal 2 Passenger 2 buyTicket displayGate enter setDestination departReq departAck alert100 arriveReq arriveAck arrived exit

Fetch Vehicle For Terminal 1

Passenger 1 Terminal 1 Vehicle Control Centre Terminal 2 buyTicket requestVehicle orderVehicle setDestination departReq departAck alert100 arriveReq arriveAck arrived order.ack

Simultaneous Requests


Vehicle requestVehicle alert100 arriveReq arriveAck arrived

Control Centre Terminal 2 Passenger 2 buyTicket displayGate orderVehicle enter setDestination departReq departAck order.ack

exit

Passenger at Terminal 1 travels

Passenger 1 Terminal 1 displayGate enterRailCar

Vehicle setDestination departReq departAck exitRailCar

Terminal 2 alert100 arriveReq arriveAck arrived

Simultaneous

Requests

Fetch Vehicle for Terminal 1

Passenger at

Terminal 2

Passenger at

Terminal 1 travels

Figure 8.10 – Re-factored version of the PTS specification (Iteration 1)

Figure 8.11 is the result of the second implied scenario check. As before, this may raise new questions, such as: can a terminal set a destination to a vehicle before its passenger has got on, even when the vehicle is not needed at another terminal? If so, would this trigger the departure of the vehicle? What happens if a passenger misses his or her transport? Assuming stakeholders reject the implied scenario, then the decision is documented with the following negative scenario (Figure 8.12). Note that as this is the straightforward rejection of an implied scenario, it is not possible for the negative scenario to contradict the positive scenarios that have been provided previously. Thus, there is no need for a consistency check. Examples of negative scenarios that require consistency checking are discussed later.



Vehicle Terminal 2 Passenger 2 buyTicket displayGate setDestination

Figure 8.11 - Implied scenario of the PTS specification (Iteration 2)

Incorrect Vehicle Dispatch

Vehicle Control Centre Terminal 2 Passenger 2 buyTicket displayGate setDestination


The next implied scenario (Figure 8.13) is, in some respects, similar to the previous one (Figure

8.11). Again, it seems that Terminal 2 is setting the destination before Passenger 2 has entered the transport, and before a request from Terminal 1 has been relayed to it. Let us assume that the implied scenario is also rejected. At this stage, the stakeholders could produce an abstract negative scenario that prohibits both this implied scenario and the previous one, and could also make the reason explicit as to why these represent unacceptable system behaviour. However, for now, let us assume that this third implied scenario is simply rejected as is, leading to the negative scenario in Figure 8.14.


Passenger 1 Terminal 1 Vehicle buyTicket

Terminal 2 setDestination

Passenger 2 buyTicket displayGate


Incorrect Vehicle Dispatch (2)


Terminal 2 Passenger 2 buyTicket displayGate setDestination



The next implied scenario (Figure 8.15) raises some interesting issues. It differs from the initial section of bMSC “Simultaneous Requests” in that Terminal 2 dispatches its passenger before getting any notice of passengers waiting at the other terminal. Should Terminal 1 and the

Control Centre behave as specified in “Simultaneous Requests”? As before, even if stakeholders do not ask themselves these questions explicitly, completing the implied scenario and placing it in context with other scenarios helps to answer these questions implicitly. Let us assume the

MSC specification is completed as shown in Figure 8.16. This new scenario shows a Control

Centre unaware of the fact that the vehicle that it is ordering is no longer at Terminal 2, which acknowledges the orderVehicle message even though it has already sent the vehicle.



Vehicle Terminal 2 Passenger 2 buyTicket displayGate enter setDestination


Control Centre orders a vehicle that is not there


Vehicle Control Centre Terminal 2 Passenger 2 buyTicket displaySign enter setDestination requestVehicle alert100 arriveReq arriveAck arrived departReq departAck orderVehicle orderAck exit

Control

Centre orders a vehicle that is not there

Simultaneous

Requests

Passenger at

Terminal 1 travels


Passenger at

Terminal 2


Up to this point, we have not had to discuss the consistency of the MSC specificationas we have introduced basic negative scenarios derived directly from implied scenarios. However, now that have introduced a new positive scenario, we must check that it does not contradict existing negative scenarios. In the case of the new scenario in Figure 8.16, LTSA reports no inconsistencies. From now on, we discuss consistency only if a new scenario introduces inconsistency.

The next implied scenario (Figure 8.17) is another case of a vehicle being dispatched for no reason. As the third implied scenarios referring to the same kind of unwanted behaviour, it is likely that a stakeholder would try to formulate a more abstract negative scenario that states when vehicles should not be dispatched. However, to emphasise the point that simple acceptance or rejection of implied scenarios can still drive the elaboration process forward, we

134 Chapter 8. Implementation & Validation assume that a more abstract negative scenario is not proposed and that the implied scenario is simply rejected as is (Figure 8.18).



Control Centre Terminal 2 requestVehicle setDestination



Incorrect Vehicle Dispatch (3)


Vehicle Control Centre Terminal 2 requestVehicle

Passenger 2 buyTicket displayGate setDestination




Control Centre Terminal 2 requestVehicle orderVehicle setDestination



We now have a specification consisting of 3 negative scenarios and 5 bMSCs. A new check produces the implied scenario depicted in Figure 8.19. It describes to a new situation: a passenger at Terminal 2 has requested a transport and been shown the departure gate; however, before boarding, the vehicle is dispatched in response to an order from Control Centre. This raises the obvious question as to whether a Terminal can dispatch a vehicle without its passenger. If so, should the passenger request another one? Or does the Terminal register that the vehicle has departed without its passenger? The scenario produced in response to the implied scenario shows that a vehicle can depart without its passenger (Figure 8.20); however, it does not clarify what happens with the passenger left behind; this emerges later.


Passenger at Terminal 2 misses transport


Vehicle Control Centre Terminal 2 Passenger 2 buyTicket displayGate requestVehicle orderVehicle setDestination alert100 arriveReq arriveAck arrived departReq departAck orderAck

Passenger at

Terminal 2 misses

Transport

Control


Simultaneous

Requests


Passenger at

Terminal 1 travels

Passenger at

Terminal 2

Figure 8.20 – Amendments to the PTS specification (Iteration 6)

The resulting specification now has a total of 6 bMSCs and 3 negative scenarios. In addition, it has no more implied scenarios to be validated. Thus, starting from two very simple scenarios we have elaborated the specification considerably. The process must stop here, unless stakeholders collaborate with more scenarios and these generate new implied scenarios. Considering that the specification it is still partial in many respects, it is reasonable to assume that stakeholders will provide some more scenarios. A reasonable extension of the specification would be to describe the system as one with continuous execution. What happens once the transport is in Terminal 1?

Are there no more journeys allowed? Clearly not, once the vehicle is in Terminal 1, it should be used to serve more transport requests.

Suppose the specification is to be extended to model a system that is in continuous operation.

This is quite easy, as depicted in Figure 8.21. Note that had we started out with a specification of a continuously operating system (such as the one depicted in Figure 6.7) we would have obtained the same implied scenarios as described previously. (Note that the black dot used in the hMSC of Figure 8.21 is used simply to reduce the number of arrows in the picture.)

Vehicle returns to Terminal 2

Passenger 1 Terminal 1 Vehicle buyTicket displayGate enter setDestination departReq departAck exit

Terminal 2 alert100 arriveReq arriveAck arrived

Control


Simultaneous

Requests


Passenger at

Terminal 2 misses

Transport

Passenger at

Terminal 1 travels

Passenger at

Terminal 2

Vehicle returns to

Terminal 2

Figure 8.21 – Extension of PTS specification to describe a non-terminating system

The addition of bMSC “Vehicle returns to Terminal 2” gives rise to a new implied scenario

(Figure 8.22). The scenario depicts Terminal 1 requesting the Control Centre to fetch a vehicle for a passenger. The Control Centre has delayed its request to Terminal 2 and the vehicle that was to be sent to Terminal 1 manages to travel to Terminal 1 and back again. Furthermore, the passenger for whom the Control Centre was obtaining a vehicle has already finished his trip! In

136 Chapter 8. Implementation & Validation previous scenarios, Terminal 2 would have made transparent to the Control Centre that the vehicle being requested to Terminal 1 was being sent. This could be the case here too. However, we assume that stakeholders could argue as follows: the control centre can never delay a request for a vehicle more than a few seconds, which is considerably less than the time the vehicle would take to go from one terminal to another; thus, the implied scenario can never occur.

Consequently, a negative scenario rejecting Figure 8.22 is added (not depicted).


Passenger 1 buyTicket

Terminal 1 alert100 arriveReq arriveAck arrived displayGate enter setDestination departReq departAck

Vehicle requestVehicle

Control Centre enter setDestination departReq departAck

Terminal 2 Passenger 2 buyTicket displayGate alert100 exit



Passenger 1 Terminal 1 Vehicle Control Centre buyTicket alert100 arriveReq arriveAck arrived displayGate enter setDestination departReq departAck requestVehicle orderVehicle setDestination departReq departAck orderAck exit alert100 arriveReq arriveAck arrived enter

Terminal 2 Passenger 2 buyTicket displayGate


The next implied scenario (Figure 8.23) is the first resulting from the cyclic behaviour of the transport system. It raises an issue not resolved when Implied Scenario 6 was detected: what

Section 8.2 A Passenger Transportation System 137 happens to passengers that miss their transport. In Figure 8.23 the vehicle sent by Terminal 2 to

Terminal 1 in response to Control Centre’s order, left Passenger 2 behind. Once the vehicle is back, can the Passenger 2 board? We assume that this is not possible, and that passengers who have missed their transport must buy a new ticket at the Terminal. Thus, the implied scenario is rejected as is (not depicted).

The next implied scenario detected describes a similar situation to that of Figure 8.17. Here, the transport has been sent from Terminal 2 to Terminal 1 to service a request of a passenger waiting there. The passenger has been transported back to Terminal 2, and now we have two requests coming in to the system, one at each terminal. Again, as in scenario Figure 8.17,

Terminal 2 is sending the vehicle to Terminal 1 before having received a request from control centre and before a passenger has boarded. At this point, stakeholders could reject the scenario as was done previously for incorrect vehicle dispatching situations. However, as the number of scenarios regarding the same situation increases, one would certainly expect that stakeholders would develop some form of more abstract explanation of why this scenario (and the others encountered previously) should be rejected. An initial attempt could be the abstract scenario of

Figure 8.25.


Passenger 1 Terminal 1 Vehicle Control Centre Terminal 2 buyTicket requestVehicle alert100 arriveReq orderVehicle setDestination departReq departAck orderAck displayGate enter arriveAck arrived setDestination departReq departAck exit alert100 arriveReq arriveAck arrived buyTicket setDestination



Since this is not a basic negative scenario, it may conflict with the positive scenarios and inconsistencies may be introduced. A check reveals the inconsistency depicted in Figure 8.26.


Incorrect Vehicle Dispatch (v1)



Figure 8.25 – First version of amendment to the PTS specification (Iteration 9)

Inconsistency

Vehicle Terminal 2 Passenger 2 enter setDestination buyTicket displayGate

Figure 8.26 – Inconsistency introduced by Incorrect Vehicle Dispatch (v1)

It is clear that this initial version of Incorrect Vehicle Dispatch is wrong. The problem is in the alphabet of the after clause. The alphabet only includes labels buyTicket and displayGate , and it does not assert anything on the occurrence of other message labels. Consequently, it states that after a passenger has bought a ticket and been informed of the departure gate setDestination is not allowed, no matter what other messages are sent among components. For this reason, the negative scenario is prohibiting a behaviour specified in the positive part of the specification.

This inconsistency shows that the abstract negative scenario must be modified. If the label p2.enterRailCar

is added to the alphabet of the abstract scenario, we again obtain the following inconsistency. The problem is still the alphabet of the after scope. If orderVehicle is added to the alphabet, no inconsistencies are found.

Inconsistency


Vehicle Control Centre requestVehicle

Terminal 2 orderVehicle setDestination


Figure 8.27 – Inconsistency introduced by Incorrect Vehicle Dispatch (v2)


Incorrect Vehicle Dispatch (v3)

Alphabet Extension: {orderVehicle,

p2.enterRailCar}


Figure 8.28 – Final amendment to the PTS specification (Iteration 9)

A check now obtains the implied scenario of Figure 8.29. This is, again, a similar situation to a previous scenario. A passenger fails to board the requested vehicle, which is sent off to attend to another request at the other terminal. Once the vehicle is back, the passenger is not allowed on until the button is pressed again. We again assume that stakeholders now produce a negative scenario that provides an abstract explanation of when passengers are allowed to enter vehicles.


Passenger 1 Terminal 1 Vehicle Control Centre buyTicket alert100 arriveReq arriveAck arrived displayGate enter setDestination departReq departAck requestVehicle orderVehicle setDestination departReq departAck orderAck exit alert100 arriveReq arriveAck arrived enter buyTicket

Terminal 2 Passenger 2 buyTicket displayGate



Missed Vehicle must pay again!

After


Vehicle Terminal 2 Passenger 2 buyTicket departAck

Not enter

Until

Alphabet Extension: {} buyTicket



Passenger 1 Terminal 1 Vehicle Control Centre Terminal 2 buyTicket requestVehicle orderVehicle setDestination departReq departAck orderAck alert100 arriveReq arriveAck displayGate enter arrived setDestination departReq departAck alert100 arriveReq arriveAck arrived exit buyTicket requestVehicle setDestination departReq departAck enter alert100 arriveReq arriveAck arrived displayGate enter setDestination departReq departAck alert100 exit




Control Centre is quick!

After

Terminal 1 Vehicle


Control Centre Terminal 2 requestVehicle

Not alert100

Until

Alphabet Extension: {} orderVehicle


The after/until negative scenario does not introduce any inconsistencies. Implied scenarios detection produces the scenario depicted in Figure 8.31. It corresponds to the case where the vehicle is back before the Control Centre requests the vehicle. We have encountered such a situation in Figure 8.22. As then, we introduce a negative scenario illustrating Control Centre can never delay a request for a vehicle more than a few seconds, considerably less than the time the vehicle would take to go from one terminal to another (Figure 8.32). We now have obtained a specification with no more implied scenarios left to be validated.

8.2.3 Summary

Starting from two very simple scenarios, by detecting implied scenarios we have extended the specification to a total of 6 bMSCs and 3 negative scenarios. Having then simply modified the specification to model continuous behaviour, the elaboration process took the specification to a total of 7 bMSCs and 8 negative scenarios, 5 of which are basic negative scenarios, 1 is an abstract negative scenario and 2 are After/Until negative scenarios.

However, more importantly, we have elicited several aspects of the system that were not expressed in the first version of the MSC specification:

• Passengers can arrive concurrently at different terminals (Implied Scenario 1).

• Vehicles being sent to terminals to pick up passengers may piggyback passengers going to that terminal (Implied scenario 2).

• A terminal may not dispatch a vehicle until either a passenger has boarded it or the terminal has been requested to send the vehicle to another terminal (Implied scenarios 2,

3, and 5).

• Terminals do not reveal to the control centre the fact that a requested vehicle by the control centre has already been sent to the required destination (Implied scenario 4)


• Terminals may not wait for passengers to board a vehicle if an order by the Control

Centre is received (Implied scenario 6)

• The Control Centre reacts to requestVehicle messages significantly faster than the time it takes a transport to travel from one terminal to another (Implied scenario 7)

• Passengers that miss their transport must repay their ticket to board the vehicle (Implied scenario 8)

An important comment is that the issues described above have been introduced into the MSC specification through very basic acceptance and rejection of implied scenarios. Up to the tenth implied scenario, no abstract or after/until scenarios are used. Clearly, a limitation of the approach is that the issues pointed out above, have been implicitly introduced in the specification. However, by proposing hypothetical situations, the process can provoke stakeholders to consider more abstract system requirements. The two after/until negative scenarios and the abstract negative scenario do, however, capture more abstract properties of the system that are related to the last two items of the above list.

Finally, MSC specification for the Passenger Transport system is undoubtedly still partial in many respects. Implied scenarios cannot be the only driver for elaboration of scenario-based specifications. Stakeholder intervention is always crucial and other techniques for driving the elaboration process are needed to complement our approach.

8.3 Industrial Case Study

Our second case study was conducted in a very different fashion. Instead of speculating on stakeholders answers to detected implied scenarios, we used an existing prototype as an oracle to indicate whether the implied scenarios corresponded to acceptable or unacceptable system behaviour. The case study is a medium-sized industrial project involving the behaviour specification of instances of a software architectural style being developed at Philips. The architectural style involves a horizontal communication protocol that supports the building of product families of television sets [Ommering 2000].

We were provided (in confidence) with a Visual Basic prototype, developed by Rob van

Ommering of Philips Research, which we used to develop a first set of scenarios. The scenarios we chose left the prototype in the same protocol state as it had started in. Thus all the scenarios we built were, in the hMSC, alternatives that lead back to the initial node of the hMSC. Our iterations to complete the initial scenario specification were as follows. Firstly, we checked for implied scenarios. Secondly, if an implied scenario was found, we replayed it on the prototype.

Section 8.3 Industrial Case Study 143

In the case that the prototype was not able to perform such a sequence of messages, we would document the implied scenario as negative. On the other hand, if the prototype could perform the sequence of messages, we would continue to use the prototype until it reached the protocol’s initial state. The resulting history of message passes could then be added trivially to the MSC specification as a positive scenario.

The implied scenarios gave us clues for exploration of the prototype. This exploration lead to the discovery of situations that had not arisen in the first set of scenarios we chose. However, when the implied scenario detection and validation cycle converged to a stable state with no more implied scenarios, we had not elicited all the prototype’s behaviour. This is reasonable, implied scenarios can not be expected to elicit the complete system behaviour. They do however serve as useful questions for eliciting some relevant situations. Additionally, had we interacted with stakeholders instead of a prototype, more scenarios might have been elicited.

Chapter 9

Chapter 9 Discussion and Evaluation

In this chapter, we discuss and evaluate the elaboration process we propose in this thesis.

Discussions on several specific aspects of the process and their related work appear at the end of previous chapters. In Chapter 2, where background on scenario notations is given, we discuss our choice of sequence-charts as the core scenario-notation and our decisions on features, scenario composition, and semantics. Discussion in Chapter 3 is centred on comparing our use of sequence charts for specifying intended system behaviour with that of other authors. Chapter

4 does not have a section titled “Discussion”; however, throughout it we do discuss the soundness of synthesis algorithms and how architecture models can be compared. The discussion in Chapter 5 is of significant importance as it addresses the nature of implied scenarios, a notion that is central to this thesis. Chapter 6 presents a discussion on related work in the area of implied scenario detection. Additionally, in Chapter 6 we examine the relation between implied scenario and deadlock detection. In Chapter 7, we discuss related work regarding negative scenarios. Finally, in Chapter 8 we present a short discussion on the case studies that we conducted. What remains to be discussed, and is presented in this chapter, is the elaboration process as a whole. In addition, we present a critical evaluation of our work organised according to the criteria defined by Clarke et al in [Clarke and Wing 1996].

9.1 On Elaboration

The first aspect we discuss is in what way the process we present in this thesis facilitates the elaboration of scenario-based specifications and behaviour models. By elaboration, we mean extending the specification and models to describe previously unspecified functionality, or to proscribe situations that had not been explicitly forbidden previously. The elaboration occurs by detecting implied scenarios, which are scenarios that have not been neither explicitly described as desired nor undesired behaviour, and taking them back to stakeholders for validation.

Undoubtedly, elaboration is not merely a classification of implied scenarios into acceptable or unacceptable behaviour. In other words, it is more than partitioning the traces captured by the architecture model ( mt ( A )) into two sets: one of acceptable system behaviour L ( PSpec ) and another of unacceptable system behaviour ( L ( NSpec )). By detecting and validating implied scenarios, developers can discover functionality that did not appear in nor was implied by the

146 Chapter 9. Discussion and Evaluation original specification: when confronted with an implied scenario, if stakeholders consider it correct behaviour they must complete the scenario by adding messages to the end of it. They must also link the new bMSC into the hMSC. Although this always extends the behaviour specified by the MSC specification ( L ( PSpec ) ⊂ L ( PSpec new

)), it may also extend the architecture model ( tr ( A ) ⊂ tr ( A new

)|

α (A)

). The latter occurs if the implied scenario is extended and inserted into the MSC specification in a way that the original architecture model cannot imitate.

Simple examples of architecture model extension occur when new message labels or component instances are introduced into a specification as the result of the acceptance of an implied scenario and the subsequent amendment of the positive MSC specification. More subtle examples that do not involve extending the alphabet of the architecture model can be found in the Passenger Transport System case study. For instance, the initial system specification

( PSpec

0

, NSpec

0

) is used to synthesis a minimal architecture model ( A

0

) which is then checked for implied scenarios. The detected implied scenario (Figure 8.8) presents the case of two passengers at different terminals requiring transport. Executing the trace shown in Figure 8.8 eventually takes the model A

0

to a deadlock. Validation of the implied scenario leads to the extension of PSpec

0

with a scenario that explains how the system should behave when passengers at different terminals request transport (Figure 8.9). The resulting specification

( PSpec

1

, NSpec

1

) satisfies L ( PSpec

0

) ⊂ L ( PSpec

1

) and L ( NSpec

0

) = L ( NSpec

1

). The new minimal architecture model ( A

1

) synthesised from ( PSpec

1

, NSpec

1

) also extends the previous architecture model ( tr ( A

0

) ⊂ tr ( A

1

)). In particular, A

1

does not deadlock when two passengers at different terminals require transport.

The acceptance of an implied scenario does not necessarily lead to a specification with fewer implied scenarios to be validated, in other words it is seldom the case that (( mt ( C || A )\ mt ( T ) ⊂ mt ( C new

|| A new

)\ mt ( T new

)). Furthermore, architecture model extension due to implied scenario acceptance can introduce new implied scenarios. Thus, the discovery of new required behaviour can lead to the detection of more implied scenarios and, in turn, to the discovery of new system behaviour. In contrast, rejecting negative scenarios does reduce the number of implied scenarios that remain to be validated (( mt ( C || A )\ mt ( T ) ⊆ mt ( C new

|| A new

)\ mt ( T new

)). This is because the architecture and trace models remain the same ( T = T new

, A = A new

) but there is a new constraint that restricts the behaviour of A new

.

An important comment is that the detection and validation of implied scenarios does not drive the elaboration process in an arbitrary direction. It forces the MSC specification to be evolved to cover additional aspects of the concurrent nature of the system being described; stakeholders must address these aspects as they need to be clearly specified given that the required functionality is to be implemented in a specific concurrent architecture.

Section 9.1 On Elaboration 147

Validation of implied scenarios consists in presenting stakeholders, users and domain experts with hypothetical situations that need to be clarified in the scenario specification. Thus, the elaboration process we present provides an opportunity for eliciting and elaborating requirements. We have tried to enhance this by providing two main negative scenario notations.

Our intention is to facilitate the step from rejecting individual traces to the elaboration of more abstract safety properties. We hypothesise that the repetition of implied scenarios that correspond to the same type of undesired system behaviour can lead stakeholders to develop abstract explanations as to why a series of rejected implied scenarios correspond to undesirable behaviour. In this way, the elaboration process can facilitate moving from an operational description of negative scenarios to a more declarative one. However, the notations we provide for specifying abstract negative scenarios are of a limited scope, and we do not provide guidance as to how to elaborate abstract properties from a several negative scenarios. These are limitations of our approach.

Van Lamsweerde et al also aim to support the elaboration of requirements from scenarios. They propose a technique for inferring declarative requirements in the form of temporal logic from

MSCs [Lamsweerde and Willemet 1998]. The temporal formulae can be fed into the KAOS approach (e.g. [Lamsweerde et al 1995]) linking operational descriptions with goal-based specifications. This addresses one of the important limitations of scenario-based specifications as tools for requirement elicitation. Scenarios address operational characteristics of the system rather than high level-goals that explain the reasons for such operationalisation. In our approach, there is no support for elaborating goals from positive scenarios, but there is limited support to do so from negative ones.

However, there are significant differences with [Lamsweerde and Willemet 1998]. Firstly, their use of negative scenarios and exclusion rules is to avoid overgeneralisations resulting from the inference rules applied to positive behaviours. This is different from our use of negative scenarios that are used to document unwanted scenarios (not overgeneralisations) that are implied by the required behaviour and architecture. In addition, we integrate negative scenarios

(once they have been specified) into the behaviour models with no stakeholder intervention.

However, exclusion rules may require weakening through human intervention to avoid inconsistencies. Moreover, this weakening must be done at the temporal logic level instead of the scenario level. Finally, the more complex a scenario is, the more candidate goal specifications generated are likely to be irrelevant to some specific concern. Thus, several rules

(that must be applied by stakeholders) are provided to help “clean up” scenarios. In contrast, implied scenarios address relevant issues regarding the concurrent nature of the system being specified and that result from a partial specification of such system. These issues should be

148 Chapter 9. Discussion and Evaluation clarified and result in an extended system description or, in the case of rejected implied scenarios, in relevant system safety properties.

We believe that Lamsweerde's approach is complementary to ours. While we focus on elaboration of partial operational scenario descriptions, and the construction of models to enable reasoning about design, Lamsweerde et al focus on the elaboration of declarative requirements and reasoning about goals.

Systä et al (e.g. [Koskimies et al 1998, Mäkinen and Systä 2001]) also support incremental elaboration of scenario-based specifications and behaviour models. Their work focuses on a component level, presenting stakeholders with component behaviour that may be the result of over-generalisation introduced by their learning algorithm. Our work is on a system level, presenting stakeholders with behaviours implied by the specified system behaviour and architecture.

The waterfall model is a systematic sequential approach to software development. Development processes following the model are supposed to proceed linearly first fully completing the requirements definition before commencing the design phase. It is widely accepted that such approach can introduce the problem of artificially stages in order to start the next phase. The spiral life cycle model [Boehm 1988] is thought to (partially) address this problem by advocating incremental development where requirements and design are revisited periodically.

Moreover, approaches such as the Twin-peaks model [Nuseibeh 2001] advocate a “finer-grained spiral development life cycle” that “highlights the concurrent, iterative process of producing progressively more detailed requirements and design specifications”. The underlying concept in the Twin peaks model is that system requirements and constraints are intertwined [Swartout and

Balzer 1982]. Elaboration based on implied scenarios fits well within this perspective of intertwined requirements and design.

9.2 On Convergence

From our experience, the number of rejected implied scenario tends to surpass the number of accepted ones towards the end of the elaboration process. Thus, the elaboration process can be seen to have two phases: the first is an expansion phase in which new functionality is added to the positive part of the specification and the architecture model; the second is a contraction phase, where the negative part of the specification is strengthened and the number of implied scenarios to be validated starts decreasing. Can we guarantee that we will reach a stage where there are no more implied scenarios to validate? In other words, does the elaboration process converge? The answer to this question depends on the problem domain. From the discussion

Section 9.3 On End Products 149 above, it is clear that by constantly accepting implied scenarios, new functionality can be constantly introduced. Thus, if we consider the set of message labels to be infinite, the elaboration process cannot be guaranteed to converge.

Even considering a finite set of message labels, the process may not converge to a stable state.

We have shown previously that with the expressive power of the basic negative scenarios, convergence may not be possible. A infinite set of these basic negative scenarios is needed to proscribe the occurrence of traces of the form ⟨ on , pressure , …, pressure, off , on , query ⟩ in the

Boiler Control system (see Page 113). From our experience, we have found the abstract and after/until negative scenario notations to be sufficiently expressive to reach MSC specifications where implied scenarios have been covered. However, we have not attempted to prove this. An additional issue is whether stakeholders will make the step from rejecting individual negative scenarios to providing abstract properties that proscribe negative scenarios. Clearly, this depends on the stakeholders ability to abstract general properties from simple cases.

Consequently, in practice we cannot guarantee convergence.

Stopping the iterative process before converging to a stable specification does not make the process’ results worthless. Each iteration produces its own benefits and potentially provides four more elaborated artefacts that have an increased value to developers. The artefacts are a scenario-based specification, and three behaviour models. We discuss their utility in the next subsection.

9.3 On End Products

At each iteration the process we describe in this thesis produces four artefacts: a scenario-based specification and three behaviour models. The utility of scenario-based specifications has been proven by their widespread acceptance in industry. They provide a clear, intuitive account of how system components, the environment and users work concurrently and interact in order to provide system level functionality. The added value that the process we propose has given to the initial MSC specification is that it has been evolved so to cover some important aspects of the concurrent nature of the system being described. In addition, the new specification may have been evolved to include functionality that was not present in the original specification.

One of the limitations of our approach is that we do not facilitate the elaboration or elicitation of declarative requirements or goals. Scenarios are operationalisations of requirements or goals; the former describe how the latter are provided by system components. The differences are slightly blurred when considering abstract and after/until negative scenarios, because these

150 Chapter 9. Discussion and Evaluation allow the capture of abstract system properties. At any rate, by proposing hypothetical situations

(implied scenarios), the elaboration process can provoke stakeholders to consider system requirements and goals that had not been taken into account previously.

The elaboration process constructs three behaviour models, which in contrast with the MSC specification, are not an input of the process. Thus, they are new products rather than elaborate versions of the original input. However, as explained previously, each process iteration will produce more elaborate behaviour models than before. The first behaviour model product of the elaboration process is the trace model. This model captures precisely the traces the system is expected to exhibit ( mt ( T )= L ( PSpec )). The second is the architecture model that captures the intended system architecture and provides the intended system behaviour ( A =( A

1

||…|| A n

) and mt ( A ) ⊆ L ( PSpec ). However, it may exhibit additional unspecified behaviour, in other words implied scenarios. The third behaviour model is the constraint model, which captures the properties that the architecture model should comply with if it is to avoid system behaviour described as undesirable ( mt ( C || A ) ∩ L ( NSpec )= ∅ ). Furthermore, if there are no more implied scenarios to be validated, then the constraint model captures the properties that the architecture model should comply with if its is to provide exactly the specified positive behaviour

( mt ( C || A )= L ( PSpec )).

The architecture model provides the basis for modelling and reasoning about system design. It is the model that needs to be further developed in order to move towards implementation.

Architectural and design decisions can be modelled and verified to check that the system model satisfies the constraint model thereby providing the specified system behaviour without any additional unspecified traces. The three behaviour models help developers to reason about their designs and to rigorously analyse if new design decisions are correct. Furthermore, the constraint model can help drive the design process as it models the properties that the architecture model must satisfy once new design elements have been added.

As an example, consider the Boiler Control system that we have discussed extensively throughout this thesis. Recall that one of the negative scenarios (Page 115) stated that the

Control component is not allowed to query the Database immediately after turning on the

Sensor. When the implied scenario that gives rise to this negative scenario was discussed, we said that there should be some new pressure message saved into the Database before the query can be performed. The reason for this implied scenario is that the Control component cannot track when information is saved into the Database ; hence, it cannot query at appropriate times.

In addition, the Database cannot enable and disable queries to prevent the Control component from querying at inappropriately moments because it cannot distinguish when the Sensor has been turned on or off .

Section 9.3 On End Products 151

To avoid the behaviours proscribed by the negative scenario, the Database and the Control component clearly need to be coordinated in some way. Thus, we can propose modifications to the architecture model in order to solve the deficiency. Furthermore, if these modifications are modelled by adapting the architecture model we already have, we can then check if the new model continues to provide the specified positive behaviour (captured by the trace model) and satisfies the constraint that corresponds to the negative scenario.

One possible design solution is to introduce a new interaction between Control and Database components. We introduce a new reset message that Control component sends to the Database before starting the Sensor . The new component LTSs are shown in Figure 9.1 and Figure 9.2 and can be compared to the previous versions (that were constructed mechanically) depicted in

Figure 4.14 and Figure 4.17 of page 71. reset on query data

0 1 2 3 4 off command

Figure 9.1 – Modified Control component model

pressure query

0

reset reset

1

pressure

2

data

Figure 9.2 – Modified Database component model

NewControl = (reset -> on -> On),

On = (off -> NewControl | query -> data -> command -> On).

NewDatabase = (reset -> NewDatabase | pressure -> NotEmpty),

NotEmpty = ( reset -> NewDatabase | pressure -> NotEmpty | query -> data -> NewDatabase).

Figure 9.3 – FSP code for modified Database and Control components

A new system model can be constructed by composing in parallel the two behaviour models depicted above together with the behaviour models for the Sensor and Actuator that where synthesised in Chapter 4. The FSP code for the new system model (process

NewSystem

) is shown in Figure 9.4 Section A.

152 Chapter 9. Discussion and Evaluation

We can now verify that the new system model does not violate the constraint model Neg3 . This constraint model has been synthesised from the negative scenario that we are trying to avoid. To perform the verification (see Figure 9.4 Section B) we declare Neg3 as a safety property, compose the new system model with it, and use the LTSA safety check to verify if there is a property violation. We can also check if the new system model continues to provide the intended system behaviour. To do so (see Figure 9.4 Section C) we hide the reset message in the new system model and declare the resulting model as a property. By checking the original trace model against the property we can verify if all traces specified by the positive part of the scenario specification are still being provided by the new system model. Finally, we can also check that the new system model does not introduce new unspecified behaviour by comparing it against the minimal architecture model. This is done (see Figure 9.4 Section D) by declaring the original architecture model as a property and composing it with the new system model.

// Section A

||NewSystem = (NewDatabase || NewControl || Actuator || Sensor).

// Section B property ||PropNeg3 = Neg3.

||CheckAgainstNeg3 = (NewSystem || PropNeg3).

// Section C property ||PropNewSystem = NewSystem \{reset}.

||CheckHasAllPositiveTraces = (PropNewSystem || TraceModel).

// Section D

||PropArchitecture = ArchitectureModel.

||CheckNoNewBehaviours = (NewSystem || PropArchitecture).

Figure 9.4 – FSP code for verifying design solution

If the three checks described above do not produce property violations (which they do not), we know that the design decisions introduced in the new system model are suitable. They resolve the problem described by the constraint model, without loosing intended system behaviour and without introducing new, unspecified behaviour.

In addition to using the three behaviour models to verify the correctness of new design decisions, we can also use the models to check if domain specific system properties hold.

For instance, let us take the Passenger Transportation system discussed in previous chapters and assume that we stop the elaboration process after the ninth iteration. We can now check if vehicles are correctly dispatched in the system model. We model correct dispatching of vehicles

Section 9.3 On End Products 153 in Figure 9.5. The property

PDispatch

shows that departAck

is expected to occur as a result of a passenger entering the vehicle or of an order from the control centre. The LTS for the property is depicted in Figure 9.6. If we compose the property with the constrained architecture model, we learn that the property does not hold. The output of the model checker is depicted in

Figure 9.7

Dispatch = ({{p1, p2}.enter, {t1, t2}.orderVehicle} -> Ready),

Ready = ({{p1, p2}.enter, {t1, t2}.orderVehicle} -> Ready |

{t1, t2}.departAck -> Dispatch). property ||PDispatch = Dispatch.

||CheckDispatch = (PDispatch || ConstrainedArchitectureModel).

Figure 9.5 – FSP code for verifying correct transport dispatch

{{p1, p2}.enter, {t1, t2}.orderVehicle}

-1 0 1

{t1, t2}.departAck

{t1, t2}.departAck

{{p1, p2}.enter, {t1, t2}.orderVehicle}

Figure 9.6 – Property LTS for verifying correct transport dispatch

Summarising, the elaboration process we describe in this thesis produces four artefacts at the end of each iteration: a scenario-based specification that has been elaborated through successive detection and validation cycles, and three behaviour models. The architecture model provides the basis for modelling and reasoning about system design. The constraint and trace models aid verification of the design decisions introduced into the architecture model.

154 Chapter 9. Discussion and Evaluation

Trace to property violation in PropDispatch:

t2.buyTicket

t2.displayGate

p2.enter

t2.setDestination

t2.departReq

t2.departAck

t1.alert100

t1.arriveReq

t1.arriveAck

t1.arrived

p2.exit

t1.buyTicket

t1.displayGate

p1.enter

t1.setDestination

t1.departReq

t1.departAck

t2.alert100

t2.arriveReq

t2.arriveAck

t2.arrived

t2.buyTicket

t2.displayGate

p1.exit

t2.setDestination

t2.departReq

t2.departAck

Figure 9.7 – LTSA output indicating a property violation

The critical evaluation of the work presented in this thesis is organised according to the evaluation criteria defined by Clarke et al in [Clarke and Wing 1996]. The authors state that they have learnt from experience which kinds of formal methods and tools have the most impact. To be attractive to practitioners, the authors argue that designers should strive to make methods and tools satisfy the following criteria: ease of learning, early payback, incremental gain for incremental effort, multiple use, integrated use, ease of use, efficiency, orientation toward error detection, focused analysis and evolutionary development. We evaluate our work against each of these criteria.

9.4.1 Ease of learning

Notations and tools should provide a starting point for writing formal specifications for developers who would not otherwise write them. The knowledge of formal specifications needed to start realizing benefits should be minimal [Clarke and Wing 1996].

Section 9.4 Critical Evaluation 155

This criterion motivates the work presented in this thesis and our choice of scenario-based languages. Several aspects of the work we present contribute to making the process we propose easy to learn:

• We use scenarios as the main communication device. Scenarios can be understood easily and have become widespread in industry.

• We restrict the sequence chart notation to its very basic features. We do not include more complex constructs such as message queues, parametric messages, dynamic creation and termination of instances, and gates.

• We adopt a simple trace-based semantics, which coincides with the intuitive understanding of sequence charts. One of the controversial issues on the semantics is the use of weak sequential composition. As discussed previously, although this is the standard and widely adopted semantics for hMSCs, it is not a crucial point of our approach. The whole process we have described applies in the context of strong sequential composition. The most complex part of the semantics we have proposed is related to the more expressive negative scenario notations. However, as discussed previously, there is no need to use these more expressive notations in order to obtain substantial benefit from the approach.

• Process feedback is in the same format as process input. All users manage are scenarios.

Furthermore, users do not need to understand what implied scenarios are. They can just be interpreted as questions, hypothetical system executions that must be accepted or rejected. Rejection can be trivially performed by adding a basic negative scenario to the specification. Acceptance is also extremely simple, it mainly requires knowledge of the problem domain to explain how the system behaves once it has performed the implied scenario.

• Behaviour models, behavioural properties and model checking can be completely ignored by the novice user. From the elaboration of scenario-based specifications perspective, these concepts do not need to be known at all. In addition, the process that inputs a scenario-based specification and outputs an implied scenario is completely automated.

9.4.2 Early payback

"Methods and tools should provide significant benefits almost as soon as people begin to use them" [Clarke and Wing 1996].

We believe that early payback, or early return on investment, is crucial. As discussed in Section

1.11.1 we believe it is one of the main reasons for the slow acceptance rate of behaviour

156 Chapter 9. Discussion and Evaluation modelling technology by practitioners. Early payback is one of the motivations of our work.

Our interest in scenario-based specifications is centred on the fact that they are suitable for providing partial descriptions of system behaviour. In addition, implied scenarios can appear in very sparse specifications. Moreover, we believe that the more partial the specification, the more opportunities for elaboration using implied scenarios. For example, the Personal Transport system case study started from two very simple scenarios and produced one implied scenario that kick started the iteration process. The first six iterations extended the specification to a total of 6 bMSCs and 3 basic negative scenarios. Only then some slightly more complex modification was needed to be made which then led, after 6 more iterations, to a specification with a total of

7 bMSCs and 9 negative scenarios, 3 of which model more abstract behaviour properties. In conclusion, it is not necessary to have a comprehensive system description to start using the ideas presented in this thesis and therefore producing benefits early in the modelling process.

9.4.3 Incremental gain for incremental effort

Benefits should increase as developers get more adept or put more effort into writing specifications or using tools [Clarke and Wing 1996].

The most advanced part of the method we propose is the use of the more expressive negative scenario notations. The meaning of abstract and after/until negative scenarios may be more (but not excessively) complex to grasp for the inexperienced user. As explained and demonstrated before, not using these notations still provides substantial benefits. However, if the more expressive notations are used abstract system properties can be elicited, which is clearly beneficial. In addition, the elaboration process may converge to a scenario-specification with no more implied scenarios.

Undoubtedly, the major increment in benefit arises with increased expertise in the analysis of the behaviour models that the process constructs. Rigorous and automated analysis of behaviour models has proven to be successful in uncovering the subtle errors that appear when designing complex software-based systems. Unfortunately, in many cases the cost of building such models outweighs the benefits provided by rigorous and automated analysis. This is because most approaches require a comprehensive description of the system and system properties to be explicitly modelled by someone with considerable expertise and domain knowledge. The process we propose provides the models that constitute the basis for reasoning about system design. Thus, we facilitate the transition into using traditional behaviour modelling approaches and analyses with varying level of complexity.


9.4.4 Multiple use

It should be possible to amortize the cost of a method or tool over many uses. For example, it should be possible to derive benefits from a single specification at several points in a program’s life cycle: in design analysis, code optimisation, test case generation, and regression testing

[Clarke and Wing 1996].

The elaboration process we propose has a very specific usage. It elaborates scenario-based specifications and behaviour models by detecting and validating implied scenarios.

Consquently, it derives benefits both in the requirements world, particularly in requirement elicitation, documentation and specification, and in the design world, specifically in the modelling and analysing system architecture and behaviour. More importantly, it facilitates the transition from requirement oriented scenarios descriptions to design oriented models such as behaviour models. Benefits of the actual process in other "points in a program's life cylce" cannot be derived directly, however, the products of the elaboration process can provide substantial benefits in other phases of the life cycle.

9.4.5 Integrated use

Methods and tools should work in conjunction with each other and with common programming languages and techniques. Developers should not have to “buy into” a new methodology completely to begin receiving benefits. The use of tools for formal methods should be integrated with that of tools for traditional software development, for example, compilers and simulators


To a large extent, we have already discussed this point before. Our choice of scenario-based specifications is motivated by exactly the same criteria described by Clarke et al in "Integrated use". Our criterion is to try to provide benefits using the tools and methods that practitioners use today.

9.4.6 Ease of use

Tools should be as easy to use as compilers, and their output should be as easy to understand


We have developed a tool that supports the elaboration process we have presented. Although it is fully functional, it is still a prototype. Hence many usability issues need to be addressed.

However, the process as a whole, as stated in Section 9.4.1, is easy to understand and adopt. All process inputs and outputs are scenarios, users do not require understanding implied scnearios, behaviour model, nor model checking; they do need to understand the problem domain well

158 Chapter 9. Discussion and Evaluation enough to answer whether an implied scenario is acceptable or unacceptable behaviour. Clearly, to move into the behaviour modelling side, more knowledge is required. However, the tool we have developed is based on LTSA which is used extensively for behaviour modelling and analysis in academic and industrial settings.

9.4.7 Efficiency

Tools should make efficient use of a developer’s time. Turnaround time with an interactive tool should be comparable to that of normal compilation. Developers are likely to be more patient, however, with completely automatic tools that perform more extensive analysis [Clarke and

Wing 1996].

We have not focused the work in this thesis on efficiency. Consequently, the time-efficiency of the tool we have developed is sub-optimal. However, our tool has proven sufficiently efficient to manage the case studies that we have discussed in Chapter 8. Two aspects of the process can affect time-efficiency. The first is behaviour model synthesis, of which the only complex part is the construction of the coordinator model. In Section 6.2 we discussed some heuristics for reducing the model's state space, and consequently it's the synthesis time; more work needs to be done in this direction. In addition, the prototype implementation has not focused on efficiency either. Thus, significant improvements could be made in the choice of data structures and algorithms used for model synthesis. The other aspect that can affect time-efficiency (and space-efficiency) is the actual model checking of the implied scenario detection property.

Clearly, our approach relies heavily on and is limited by the efficiency of the underlying modelchecking technology. However, state of the art model checkers, such as LTSA, have proven to manage efficiently large behaviour models [Cleaveland and Smolka 1996].

9.4.8 Orientation toward error detection

Methods and tools should be optimised for finding errors, not for certifying correctness. They should support generating counterexamples as a means of debugging [Clarke and Wing 1996].

The orientation of the process we have presented is not toward error detection but toward specification elaboration. Implied scenarios are not errors; they signal gaps in the scenariobased specification. Nevertheless, counterexamples are central to the process: implied scenarios are generated as counterexamples of the realisability of the scenario specification, and provide the basis for elaborating the specification once they have been accepted or rejected.


9.4.9 Focused analysis

Methods and tools should be good at analysing at least one aspect of a system well, for example, the control flow of a protocol. They need not be good at analysing all aspects of a system [Clarke and Wing 1996].

There are two answers to this issue. On one hand, the analysis performed by our elaboration process is extremely focused. It only considers one system property, realisability, and by finding implied scenarios, it drives the elaboration process forward. However, from a different perspective, the analysis is very general as it leads to elicitation of varied kinds of functionality, and produces behaviour models on which many kinds of analyses can be performed.

Methods and tools should support evolutionary system development by allowing partial specification and analysis of selected aspects of a system [Clarke and Wing 1996].

From the discussions presented above, it is clear that our approach is designed for elaborating partial specifications; and that the concept of evolution, which we call elaboration, is central to the work in this thesis. Implied scenarios can support the elaboration of partial specifications.

However, they are not effective in all cases: some system specifications do not exhibit implied scenarios because components communicate extensively between each other or because components concurrency is limited by request-reply communication patterns. For these kinds of systems, implied scenarios are not a useful mechanism for evolutionary system development.

This is a limitation of our approach. In these cases, other mechanisms for evolving specifications and behaviour models are needed; we believe that domain dependent liveness conditions could serve this purpose.

Chapter 10

Chapter 10 Conclusions

The most general goal of the work in this thesis has been to develop techniques to aid the modelling and analysis of concurrent and distributed systems. Our starting point has been to study the relationship between scenario-based specifications and behaviour models, which has motivated the main goal of this thesis: to develop practical and effective techniques with tool support for constructing and elaborating behaviour models and scenario-based specifications, exploiting their potential benefits yet ameliorating their shortcomings. Our work has resulted in an iterative process that drives the elaboration of scenario-based specifications by analysing the gaps in the system specification that need to be clarified due to the concurrent nature of the system. These gaps are signalled by implied scenarios, which are detected by the construction and rigorous analysis of behaviour models.

10.1 Summary of Contributions

The main contribution of this thesis is a process for elaborating scenario-based specifications and behaviour models by detecting and validating implied scenarios. The process facilitates the evolution of MSC specifications to cover aspects of the concurrent nature of the system being described. The process includes the potential to include functional aspects of the system missing in the initial version. It also facilitates the construction of behaviour models that can then be used to elaborate and reason rigorously about system design. Consequently, the elaboration process not only assists in elaboration of a scenario description of the desired and undesired system behaviour, which is related to the requirement elicitation and specification phase. It also bridges the design phase by providing models that allow designers to reason about and refine the system design.

162 Chapter 10. Conclusions

In addition to the elaboration process, there are also a number of more specific contributions.

Firstly, we introduce the notion of implied scenario as indicators of gaps in scenario-based specifications. Secondly, we define a synthesis algorithm for constructing minimal architecture models. Thirdly, we have developed a method for implied scenario detection that works with regular MSC specifications consisting of bMSCs, hMSCs and negative scenarios. Fourthly, we have defined a negative scenario language for rejecting implied scenarios and describing system properties. Finally, we have developed a tool that allows editing MSC specifications, fully automates the construction of behaviour models and implied scenario detection, supports the elaboration process as a whole and is integrated into a model-checking tool that supports behaviour analysis of concurrent and distributed systems.

10.2 Future Work

In the future, we envisage working in two different directions. On the one hand, we intend to continue to improve the techniques we have already developed, focusing mainly on the efficiency and usability of the tool set we have developed. In particular, improvements can be made on managing state explosion when checking for implied scenarios and in the size of the state space of the coordinator model that we use for building the trace model of a MSC specification. A useful extension to the tool we have developed is to include techniques for managing scenarios specifications such as re-factoring techniques (e.g. [Helouet and LeMaigat

2000]).

On the other hand, we intend to conduct research into other properties (apart from realisability) that could be used to drive the elaboration of scenario-based specifications and behaviour models. In particular, we believe that the use of domain specific safety and liveness properties, and inconsistencies between positive and negative specified behaviour could be used for this purpose. Additionally, we intend to explore extensions to the MSC language that we have used: one is the use of alternative scenario combination mechanisms, such as triggered scenarios.

Another is the integration of multiple viewpoints expressed in scenario-based specifications; this introduces non-trivial problems such as combining specifications developed at different levels of abstraction. The use of time and probability information in scenario-based specifications is also an area that we intend to examine.

Section 10.3 Closing Remarks 163

10.3 Closing Remarks

The need for pre-development and pre-deployment reasoning about the system behaviour has been addressed by software engineers and software engineering researchers for many years. To this end, a significant effort has been made in developing modelling notations, automated analysis techniques and tool support. However, supporting the construction and elaboration of behaviour models has been largely neglected. Model construction and elaboration are engineering activities in their own right, and developing support for these activities is a key challenge. Support which complements existing behaviour modelling notations, analysis techniques and tools should provide sound model-based engineering methods for software development.

Bibliography

[Adriaens and Schreurs 1992] Adriaens, G. and Schreurs, D. "From Cogram to Alcogram: Towards a

Controlled English Grammar Checker" in proceedings of the 14th International Conference on

Computational Linguistics (COLING'92) , Nantes, 1992. pp. 595-601.

[Aho et al 1986] Aho, A.V., Sethi, R. and Ullman, J.D. Compliers: Principles, Techniques and Tools :

Addison-Wesley, Reading, Mass., 1986.

[Alexander 2002] Alexander, I. "Misuse Cases help To Elicit Non-Functional Requirements", 2002.

Available at http://easyweb.easynet.co.uk/iany/consultancy/misuse_cases.

[Alur et al 2000] Alur, R., Etessami, K. and Yannakakis, M. "Inference of Message Sequence Charts" in proceedings of the 22nd IEEE International Conference on Software Engineering (ICSE'00) , Limerick,

2000. pp. 304-313.

[Alur et al 2001] Alur, R., Etessami, K. and Yannakakis, M. "Realizability and verification of MSC graphs" in proceedings of the 28th International Colloquium on Automata, Languages, and Programming

(ICALP'01) , Crete, 2001. Orejas, F., Spirakis, P.G. and Leeuwen, J.v. eds. Lecture Notes in Computer

Science 2076, Springer, pp. 797-808.

[Alur et al 1996] Alur, R., Holzmann, G.J. and Peled, D. "An Analyser for Message Sequence Charts" in proceedings of the 2nd International Conference on Tools and Algorithms for the Construction and

Analysis of Systems (TACAS'96) , Passau, 1996. Lecture Notes in Computer Science 1055, Springer, pp.

35-48.

[Alur and Yannakakis 1999] Alur, R. and Yannakakis, M. "Model Checking of Message Sequence

Charts" in proceedings of the 10th International Conference on Concurrency Theory (CONCUR'99) ,

Eidenhoven, 1999. Baeten, J.C.M. and Mauw, S. eds. Lecture Notes in Computer Science 1664, Springer, pp. 114-129.

[Andolfi et al 2000] Andolfi, F., Aquilani, F., Balsamo, S. and Inverardi, P. "Deriving QNM from MSCs for Performance Evaluation of Software Architectures" in proceedings of the 2nd International Workshop on Software and Performance (WOSP'00) , Ottawa, 2000. ACM, pp. 47-57.

[Ben-Abdhallah and Leue 1996a] Ben-Abdhallah, H. and Leue, S. "Architecture of a Requirements and

Design Tool Based on Message Sequence Charts". Technical Report 96-13, Electrical and Computer

Engineering, University of Waterloo, Ontario, 1996a.

[Ben-Abdhallah and Leue 1996b] Ben-Abdhallah, H. and Leue, S. "Syntactic Analysis of Message

Sequence Chart Specifications". Technical Report 96-12, Electrical and Computer Engineering,

University of Waterloo, Waterloo, 1996b.

[Ben-Abdhallah and Leue 1997a] Ben-Abdhallah, H. and Leue, S. "Expressing and Analyzing Timing

Constraints in Message Sequence Charts". Technical Report 97-04, Electrical and Computer Engineering,

University of Waterloo, Waterloo, 1997a.

[Ben-Abdhallah and Leue 1997b] Ben-Abdhallah, H. and Leue, S. "Syntactic Detection of Process

Divergence and Non-Local Choice in Message Sequence Charts" in proceedings of the 3rd International

Conference on Tools and Algorithms for the Construction and Analysis of Systems (TACAS'97) , 1997b.

Brinksma, E. ed. Lecture Notes in Computer Science 1217, Springer, pp. 259-274.

[Ben-Abdhallah and Leue 1998] Ben-Abdhallah, H. and Leue, S. "MESA: Support for Scenario-Based

Design of Concurrent Systems" in proceedings of the 4th International Conference on Tools and

Algorithms for the Construction and Analysis of Systems (TACAS'98) , Lisbon, 1998. Steffen, B. ed.

Lecture Notes in Computer Science 1384, Springer, pp. 118-135.

[Biermann and Krishnaswamy 1976] Biermann, A.W. and Krishnaswamy, R. Constructing Programs from Example Computations. IEEE Transactions on Software Engineering vol. 2(3) , pp. 141-153, 1976.

[Boehm 1988] Boehm, B. A Spiral Model of Software Development and Enhancement. IEEE Computer vol. 21(5) , pp. 61-72, 1988.

166

[Booch et al 1998] Booch, G., Rumbaugh, J. and Jacobson, I. The Unified Modeling Language User

Guide : Addison-Wesley, 1998.

[Bordeleau 1999] Bordeleau, F. "A Systematic and Traceable Progression from Scenario Models to

Communicating Hierarchical Finite State Machines". Ph.D. Thesis, SCS , Carleton University, 1999.

[Broy and Krüger 1998] Broy, M. and Krüger, I. "Interaction Interfaces - Towards a Scientific

Foundation of a Methodological Usage of Message Sequence Charts" in proceedings of the 2nd IEEE

International Conference on Formal Engineering Methods (ICFEM'98) , Brisbane, 1998. Staples, J.,

Hinchey, M.G. and Liu, S. eds. IEEE Computer Society, pp. 2-15.

[Buhr 1998] Buhr, R.J.A. Use Case Maps as Architectural Entities for Complex Systems. IEEE

Transactions on Software Engineering vol. 24(12) , pp. 1131-1155, 1998.

[Campbell 1992] Campbell, R.L. Will the real scenario please stand up? SIGCHI Bulletin vol. 24(2) , pp.

6-8, 1992.

[Carroll 1995] Carroll, J.M. (ed.) Scenario-based design: envisioning work and technology in system development . Wiley, New York, 1995.

[CCITT 1988a] CCITT. "Interworking between the digital subscriber system layer 3 protocol and the signalling system 7 ISDN. User Part". Recommendation Q.699, International Telephone and Telegraph

Consultative Committee (CCITT), Geneva, 1988a.

[CCITT 1988b] CCITT. "Stage 2 of the method for characterization of services supported by an ISDN".

Recommendation Q.65, International Telephone and Telegraph Consultative Committee (CCITT),

Geneva, 1988b.

[Cheung 1994] Cheung, J.C. "Tractable and Compositional Techniques for Behaviour Analysis of

Concurrent Systems". PhD Thesis, Department of Computing , Imperial College of Science, Technology and Medicine, 1994.

[Chu and Liu 1988] Chu, P.M. and Liu, M.T. "Protocol synthesis in a state transition model" in proceedings of the IEEE International Computer Software and Applications Conference (COMPSAC'88) ,

Chicago, 1988. pp. 505-512.

[Clarke et al 1989] Clarke, E.M., Long, D.E. and McMillan, K.L. "Compositional Model Checking" in proceedings of the 4th Annual Symposium on Logic in Computer Science (LICS'89) , Pacific Grove, 1989. pp. 353-362.

[Clarke and Wing 1996] Clarke, E.M. and Wing, J.M. Formal Methods: State of the Art and Future

Directions. ACM Computing Surveys vol. 28(4) , pp. 626-643, 1996.

[Cleaveland and Smolka 1996] Cleaveland, R. and Smolka, S.A. Strategic Directions in Concurrency

Research. ACM Computing Surveys vol. 28(4) , pp. 607-625, 1996.

[CREWS 1999] CREWS. "Cooperative Requirements Engineering With Scenarios", 1999. Available at http://Sunsite.Informatik.RWTH-Aachen.DE/CREWS/.

[Damm et al 1997] Damm, W., Josko, B., Hungar, H. and Pnueli, A. "A compositional real-time semantics of STATEMATE designs" in proceedings of the International Symposium on

"Compositionality: The Signifcant Difference" , Bad Malente, 1997. Roever, W.P.d., Langmaack, H. and

Pnueli, A. eds. Lecture Notes in Computer Science 1536, Springer, pp. 186-238.

[Dwyer et al 1998] Dwyer, M., Avrunin, G.S. and Corbett, J.C. "Patterns in Property Specifications for

Finite-State Verification" in proceedings of the 21st IEEE International Conference on Software

Engineering (ICSE'99) , Los Angeles, 1998. pp. 411-420.

[Dwyer et al 2002] Dwyer, M., Avrunin, G.S. and Corbett, J.C. "Specification Patterns Web Site.", 2002.

Available at http://www.cis.ksu.edu/santos/spec-patterns.

[Engels et al 1999] Engels, A., Feijs, L. and Mauw, S. "MSC and data: dynamic variables" in proceedings of the 9th SDL Forum , Montreal, 1999. Dssouli, R., Bochmann, G.V. and Lahav, Y. eds. Elsevier Science

Publishers, pp. 105-120.

167

[Fuchs and Schwitter 1996] Fuchs, N.E. and Schwitter, R. "Attempto Controlled English (ACE)" in proceedings of the 1st Workshop on Controlled Language Applications (CLAW'96) , Leuven, 1996.

[Ghezzi et al 1991] Ghezzi, C., Jazayeri, M. and Madrioli, D. Fundamentals of Software Engineering,

Chapter 6 : Prentice Hall, 1991.

[Giannakopoulou 1999] Giannakopoulou, D. "Model Checking for Concurrent Software Architectures".

PhD Thesis, Department of Computing , Imperial College of Science, Technology and Medicine, 1999.

[Glinz 1995] Glinz, M. "An Integrated Formal Model of Scenarios Based on Statecharts" in proceedings of the 5th European Software Engineering Conference (ESEC'95) , Sitges, 1995. Schäfer, W. and Botella,

P. eds. Lecture Notes in Computer Science 989, Springer, pp. 254-271.

[Glinz 2000] Glinz, M. "A Lightweight Approach to Consistency of Scenarios and Class Models" in proceedings of the 4th IEEE International Conference on Requirements Engineering (ICRE'00) ,

Schaumburg, 2000. pp. 49-58.

[Gould et al 1987] Gould, J.D., Boies, S.J., Levy, S., Richards, J.T. and Schoonard, J. The 1984 Olympic

Message System: A Test of Behavioural Principles of System Design. Communications of the ACM vol.

30(9) , pp. 758-769, 1987.

[Grabowski 1994] Grabowski, J. "Test Case Generation and Test Case Specication with Message

Sequence Charts". PhD Thesis, Institute for Informatics and Applied Mathematics , Universitat Bern,

1994.

[Grabowski et al 1993] Grabowski, J., Graubmann, P. and Rudolph, E. "The standardization of Message

Sequence Charts" in proceedings of the Software Engineering Standards Symposium , Brighton, 1993.

IEEE Computer Society Press, pp. 48--63.

[Harel 1987] Harel, D. Statecharts: A visual formalism for complex systems. Science of Computer

Programming vol. 8(3) , pp. 231-274, 1987.

[Harel 2001] Harel, D. From Play-In Scenarios to Code: An achievable Dream. IEEE Software vol. 34(1) , pp. 53-60, 2001.

[Harel and Damm 1999] Harel, D. and Damm, W. "LSCs: Breathing Life into Message Sequence Charts" in proceedings of the 3rd IFIP International Conference on Formal Methods for Open Object-Based

Distributed Systems , New York, 1999. Kluwer Academic, pp. 293-312.

[Harel and Kugler 2000] Harel, D. and Kugler, H. "Synthesizing State-Based Object Systems from LSC

Specifications" in proceedings of the 5th International Conference on Implementation and Application of

Automata (CIAA'2000) , 2000. Lecture Notes in Computer Science 2088, Springer,.

[Harel et al 1987] Harel, D., Pnueli, A., Schmidt, J. and Sherman, R. "On the formal semantics of

Statecharts" in proceedings of the Symposium on Logic in Computer Science (LICS'87) , Ithaca, 1987.

IEEE Computer Society, pp. 54-64.

[Harmon and Watson 1998] Harmon, P. and Watson, M. Understanding UML: The Developers Guide :

Morgan Kaufmann Publishers, San Fransisco, 1998.

[Haugen 2001] Haugen, O. "From MSC-2000 to UML 2.0 - The Future of Sequence Diagrams" in proceedings of the 10th International SDL Forum , Copenhagen, 2001. Reed, R. and Reed, J. eds. Lecture

Notes in Computer Science 2078, Springer, pp. 38-51.

[Helouet 2001] Helouet, L. "Some Pathological Message Sequence Charts, and How to Detect Them" in proceedings of the SDL Forum 2001 , 2001. Reed, R. and Reed, J. eds. Lecture Notes in Computer


[Helouet and LeMaigat 2000] Helouet, L. and LeMaigat, P. "Decomposition of Message Sequence

Charts" in proceedings of the 2nd Workshop on SDL and MSC , Grenoble, 2000. Science, E. ed.

[Henriksen et al 1999] Henriksen, J.G., Mukund, M., Kumar, K.N. and Thiagarajan, P.S. "Towards a

Theory of Regular MSC Languages". BRICS Report RS-99-52 , Department of Computer Science,

Aarhus University, Aarhus, 1999.

168

[Henriksen et al 2000a] Henriksen, J.G., Mukund, M., Kumar, K.N. and Thiagarajan, P.S. "On Message

Sequence Graphs and Finitely Generated Regular MSC Languages" in proceedings of the 27th

International Colloquium on Automata, Languages and Programming (ICALP'2000) , Geneva, 2000a.

Montanari, U. ed. Lecture Notes in Computer Science 1853, Springer, pp. 675-686.

[Henriksen et al 2000b] Henriksen, J.G., Mukund, M., Kumar, K.N. and Thiagarajan, P.S. "Regular

Collections of Message Sequence Charts" in proceedings of the 24th International Symposium on

Mathematical Foundations of Computer Science (MFCS'00) , Szklarska Poreba, 2000b. Lecture Notes in

Computer Science 1893, Springer, pp. 405-414.

[Heymans and Dubois 1998] Heymans, P. and Dubois, E. Scenario-Based Techniques for Supporting the

Elaboration and the Validation of Formal Requirements. Requirements Engineering Journal vol. 3(3-4) , pp. 202 - 218, 1998.

[Heymer 2000] Heymer, S. "A semantics for MSCs based on Petri net components" in proceedings of the

2nd Workshop on SDL and MSC (SAM'00) , Grenoble, 2000.

[Hoare 1985] Hoare, C.A.R. Communicating Sequential Processes : Prentice Hall, Englewood Cliffs, New

Jersey, 1985.

[Holbrook III 1990] Holbrook III, H. A Sceanrio-Based Methodology for Conducting Requirement

Elicitation. ACM SIGSOFT Software Engineering Notes vol. 15(1) , pp. 95-104, 1990.

[Holzmann 1990] Holzmann, G.J. Protocol Synthesis (Chapter 10) in Design and Validation of Computer

Protocols . Prentice Hall, 1990.

[Holzmann et al 1997] Holzmann, G.J., Peled, D. and Redberg, M.H. Design Tools for Requirement

Engineering. Bell Labs Technical Journal vol. 2(1) , pp. 86-95, 1997.

[Hsia et al 1994] Hsia, P., Samuel, J., Gao, J., Kung, D., Toyoshima, Y. and Chen, C. Formal Approach to Scenario Analysis. IEEE Software vol. 11(2) , pp. 33-41, 1994.

[Hunter and Nuseibeh 1998] Hunter, A. and Nuseibeh, B. Managing Inconsistent Specifications:

Reasoning, Analysis and Action. ACM Transactions on Software Engineering and Methodology vol. 7(4) , pp. 335-367, 1998.

[Ichikawa et al 1991] Ichikawa, H., Itoh, M., Kato, J., Takura, A. and Shibasaki, M. SDE: Incremental

Specification and Development of Communications Software. IEEE Transactions on Computers vol.

40(4) , pp. 553-561, 1991.

[ISO 1987] ISO. "Information processing systems - Open Systems Interconnection - Service conventions". , International Standards Organization, 1987.

[ITU 1992] ITU. "Message Sequence Charts". Recommendation, International Telecommunications

Union. Telecommunication Standardization Sector, 1992.

[ITU 1993] ITU. "Message Sequence Charts". Recommendation Z.120, International

Telecommunications Union. Telecommunication Standardization Sector, 1993.


Telecommunications Union. Telecommunication Standardisation Sector, 1996.


Telecommunications Union. Telecommunication Standardisation Sector, 2000.

[Jackson 2001] Jackson, M. Problem Frames: Analyzing and Structuring Software Development

Problems : Addison-Wesley, 2001.

[Jacobson 1995] Jacobson, I. The Use-Case Construct in Object-Oriented Software (Chapter 12) in

Scenario-based design: envisioning work and technology in system development , Carroll, J.M. ed. Wiley,

New York, 1995.

[Jacobson et al 1999] Jacobson, I., Rumbaugh, J. and Booch, G. The Unified Software Development

Process : Addison-Wesley, Harlow, 1999.

169

[Jarke et al 1998] Jarke, M., Bui, X.T. and Carrol, J.M. "Dagstuhl Workshop on Scenario Management".

Workshop Report , Saarbrücken, 1998. Available at http://www.dagstuhl.de/98061/Report/.

[Jurafsky and Martin 2000] Jurafsky, D. and Martin, J.H. Context-Free Grammars for English (Chapter 9) in Speech and Language Processing . Prentice Hall, Upper Saddle River, 323-357, 2000.

[Kapus-Kolar 1999] Kapus-Kolar, M. More Efficient Funcitonality Decomposition in LOTOS.

Informatica vol. 23(4) , pp. 259-273, 1999.

[Katoen and Lambert 1998] Katoen, J.P. and Lambert, L. "Pomsets for Message Sequence Charts" in proceedings of the 1st Workshop on SDL and MSC (SAM'98) , Berlin, 1998. Shaker, pp. 197-208.

[Keller 1976] Keller, R. Formal verification of parallel programs. Communications of the ACM vol. 19(7) , pp. 371-384, 1976.

[Khriss et al 1999] Khriss, I., Elkoutbi, M. and Keller, R.K. "Automating the Synthesis of UML

StateChart Diagrams from Multiple Collaboration Diagrams" in proceedings of the UML'98: Beyond the

Notation , 1999. Bezivin, J. and P., M. eds. Lecture Notes in Computer Science 1618, Springer-Verlag, pp.

132-147.

[Klose and Wittke 2001] Klose, J. and Wittke, H. "An Automata Based Interpretation of Live Sequence

Charts" in proceedings of the 7th International Conference on Tools and Algorithms for the Construction and Analysis of Systems (TACAS'01) , Genoa, 2001. Margaria, T. and Yi, W. eds. Lecture Notes in

Computer Science 2031, Springer, pp. 512-527.

[Kosiuczenko and Wirsing 2000] Kosiuczenko, P. and Wirsing, M. "Towards an Integration of Message

Sequence Charts and Timed Maude" in proceedings of the 5th World Conference Integrated Design and

Process Technology (IDPT'00) , Dallas, 2000. pp. 23-44.

[Koskimies and Mäkinen 1994] Koskimies, K. and Mäkinen, E. Automatic Synthesis of State Machines from Trace Diagrams. Software Practice and Experience vol. 24(7) , pp. 643-658, 1994.

[Koskimies et al 1998] Koskimies, K., Männistö, T., Systä, T. and Tuonmi, J. Automated Support for

Modeling OO Software. IEEE Software vol. 15(1) , pp. 87-94, 1998.

[Krüger et al 1999] Krüger, I., Grosu, R., Scholz, P. and Broy, M. From MSCs to Statecharts in

Distributed and Parallel Embedded Systems , Rammig, F.J. ed. Kluwer Academic Publishers, 61-71,

1999.

[Krüger 2000] Krüger, I.H. "Distributed System Design with Message Sequence Charts". PhD Thesis,

Institut für Informatik , Technischen Universitat München, 2000.

[Kurshan et al 1998] Kurshan, R., Levin, V., Minea, M., Peled, D. and Yenigun, H. "Static Partial Order

Reduction" in proceedings of the Tools and Algorithms for the Construction and Analysis of Systems

(TACAS'98) , Lisbon, 1998. Steffen, B. ed. Lecture Notes in Computer Science 1384, Springer, pp. 345-

357.

[Ladkin and Leue 1995] Ladkin, P.B. and Leue, S. Interpreting Message Flow Graphs. Formal Aspects of

Computing vol. 7(5) , pp. 473-509, 1995.

[Lamsweerde et al 1995] Lamsweerde, A.v., Darimont, R. and Massonet, P. "Goal-Directed Elaboration of Requirements for a Meeting Scheduler: Problems and Lessons Learnt" in proceedings of the Second

IEEE International Symposium on Requirements Engineering , York, 1995. IEEE CS Press, pp. 194-203.

[Lamsweerde and Willemet 1998] Lamsweerde, A.v. and Willemet, L. Inferring Declarative

Requirements Specifications from Operational Scenarios. IEEE Transactions on Software Engineering vol. 24(12) , pp. 1089-1114, 1998.

[Leue 1994] Leue, S. "Methods and Semantics for Telecommunications Systems Engineering". PhD

Thesis, Department of Computer Science and Applied Mathematics , University of Berne, 1994.

[Madhusudan and Meenakshi 2001] Madhusudan, P. and Meenakshi, B. Beyond Message Sequence

Graphs. , 2001.

170

[Magee and Kramer 1999] Magee, J. and Kramer, J. Concurrency: State Models and Java Programs :

John Wiley & Sons Ltd., New York, 1999.

[Magee et al 1997] Magee, J., Kramer, J. and Giannakopoulou, D. "Analysing the Behaviour of

Distributed Software Architectures: a Case Study" in proceedings of the 5th IEEE Workshop on Future

Trends of Distributed Computing Systems , Tunis, 1997. pp. 240-245.

[Magee et al 1998] Magee, J., Kramer, J. and Giannakopoulou, D. "Software Architecture Directed

Behaviour Analysis" in proceedings of the 9th IEEE International Workshop on Software Specification and Design (IWSSD-9) , Ise-shima, Japan, 1998. pp. 144-146.

[Mäkinen 1994] Mäkinen, E. On the Relationship between Diagram Synthesis and Grammatical

Inference. International Journal of Computer Mathematics vol. 52(1) , pp. 129-137, 1994.

[Mäkinen and Systä 2001] Mäkinen, E. and Systä, T. "MAS – An Interactive Synthesizer to Support

Behavioral Modeling in UML," in proceedings of the 23rd IEEE International Conference on Software

Engineering (ICSE '01) , Toronto, 2001. pp. 15-24.

[Maraninchi and Halbwachs 1996] Maraninchi, F. and Halbwachs, N. "Compositional semantics of nondeterministic synchronous languages" in proceedings of the 6th European Symposium on Programming

(ESOP'96) , 1996. Lecture Notes in Computer Science 1058, Springer, pp. 235-249.

[Mauw and Reniers 1999] Mauw, S. and Reniers, M.A. Operational Semantics for MSC'96. Computer

Networks and ISDN Systems vol. 31(17) , pp. 1785-1799, 1999.

[Mauw and Winter 1993] Mauw, S. and Winter, T. A Prototype Toolset for Interworkings. Philips

Telecommunication Review vol. 51(3) , pp. 41-45, 1993.

[McDermott and Fox 1999] McDermott, J.P. and Fox, C. "Using Abuse Case Models for Security

Requirements Analysis" in proceedings of the 15th Annual Computer Security Applications Conference

(ACSAC'99) , Phoenix, 1999. IEEE Computer Society Press, pp. 55-67.

[Meijs 2000] Meijs, F.A. "Connecting Message Sequence Charts". Technical Report - Research Paper ,

Philips Research, 2000.

[Millo and Perlis 1979] Millo, R.A.D. and Perlis, R.J.L.a.A.J. Social Processes and Proofs of Therorems and Programs. Communications of the ACM vol. 22(5) , pp. 271-280, 1979.

[Milner 1989] Milner, R. Communication and Concurrency : Prentice-Hall, London, 1989.

[Morin 2001] Morin, R. "On Regular Message Sequence Chart Languages and Relationships to

Mazurkiewicz Trace Theory" in proceedings of the International Conference on the Foundations of

Software Science and Computation Structure (FOSSACS'01) , Genova, 2001. Honsell, F. and Miculan, M. eds. Lecture Notes in Computer Science 2030, Springer, pp. 332-346.

[Muccini 2001] Muccini, H. "Implied Scenario Detection" in proceedings of the Workshop on Scenarios and State Machines at the International Conference of Software Engineering (ICSE'01) , Orlando, 2001.

IEEE Press,.

[Mullender 1993] Mullender, S. What Good are Models and What Models are Good? (Chapter 2) in

Distributed Systems . Addison-Wesley, Wokingham, 1993.

[Muscholl and Peled 1999] Muscholl, A. and Peled, D. "Message Sequence Graphs and Decision

Problems on Mazurkiewicz Traces" in proceedings of the 24th International Symposium on Mathematical

Foundations of Computer Science (MFCS'99) , Szklarska Poreba, 1999. Lecture Notes in Computer


[Muscholl and Peled 2000] Muscholl, A. and Peled, D. "Analyzing Message Sequence Charts" in proceedings of the SAM'00, 2nd Workshop on SDL and MSC , Grenoble, 2000. pp. 108-122.

[Muscholl et al 1998] Muscholl, A., Peled, D. and Su, Z. "Deciding Properties of Message Sequence

Charts" in proceedings of the 1st International Conference on the Foundations of Software Science and

Computation Structure, (FOSSACS'98) , Lisbon, 1998. Lecture Notes in Computer Science 1378,

Springer, pp. 226-242.

171

[Nuseibeh 2001] Nuseibeh, B. Weaving Together Requirements and Architecture. IEEE Computer vol.

34(3) , pp. 115-117, 2001.

[OMG 2002] OMG. "Unified Modelling Language", 2002. Available at http://www.omg.org/.

[Ommering 2000] Ommering, R.V. "Examples of Horizontal Communication". Internal Report , Philips

Research, Eindhoven, 2000.

[Pearsall 1998] Pearsall, J. (ed.) The new Oxford dictionary of English . Oxford University Press, Oxford,

1998.

[Potts et al 1994] Potts, C., Takahashi, K. and Anton, A.I. Inquiry-Based Requirements Analysis. IEEE

Software vol. 11(2) , pp. 21-32, 1994.

[Quatrani 1998] Quatrani, T. Visual modeling with Rational Rose 2000 and UML : Addison Wesley,

Reading, Mass., 1998.

[Rabinovich 1992] Rabinovich, A. "Checking Equivalences Between Concurrent Systems of Finite

Agents" in proceedings of the 19th International Colloquium on Automata, Languages and Programming

(ICALP'92) , Vienna, 1992. Lecture Notes in Computer Science 623, Springer, pp. 696-707.

[Rational 2002] Rational. Rational Rose, 2002. http://www.rational.com/.

[Reniers 1999] Reniers, M.A. "Message Sequence Chart. Syntax and Semantics". Ph.D. Thesis, ,

Eindhoven University of Technology, 1999.

[Robertson and Robertson 1999] Robertson, S. and Robertson, J. Mastering the Requirements Process :

ACM Press, Harlow, England, 1999.

[Rolland et al 1996] Rolland, C., Achour, C.B., Cauvet, C., Ralyte, J., Sutcliffe, A., Maiden, N.A.M., M.

Jarke, Haumer, P., Pohl, K., Dubois, E. and Heymans, P. "A Proposal for a Scenario Classification

Framework". CREWS Report 96-01, Cooperative Requirements Engineering with Scenarios (ESPRIT

Long Term Research Project 21.903), 1996. Available at http://Sunsite.Informatik.RWTH-

Aachen.DE/CREWS/.

[Rudolph et al 1996] Rudolph, E., Graubmann, P. and Grabowski, J. "Tutorial on Message Sequence

Charts '96" in proceedings of the IFIP TC6 WG6.1 International Conference on Formal Description

Techniques (FORTE'96) , Kaiserslautern, 1996. Gotzhein, R. and Bredereke, J. eds. IFIP Conference

Proceedings 69, Kluwer, pp. 1629-1641.

[Rumbaugh et al 1991] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W. Object-

Oriented Modeling and Design : Prentice Hall, London, 1991.

[Rumbaugh et al 1999] Rumbaugh, J., Jacobson, I. and Booch, G. The Unified Modeling Language

Reference Manual : Addison-Wesley, Harlow, 1999.

[Saleh 1996] Saleh, K. Synthesis of Communication Protocols. Computer Communication Review vol.

26(5) , pp. 40-59, 1996.

[Sindre and Opdahl 2001] Sindre, G. and Opdahl, A.L. "Templates for Misuse Case Description" in proceedings of the 7th International Workshop on Requirements Engineering: Foundation for Software

Quality , Interlaken, 2001.

[Slomka et al 1998] Slomka, F., Zant, J. and Lambert, L. "Schedulability Analysis of Heterogeneous

Systems for Performance Message Sequence Chart" in proceedings of the 6th International Workshop on

Hardware/Software Codesign , Seattle, 1998.

[Smith et al 2002] Smith, R.L., Avrunin, G.S., Clarke, L.A. and Osterweil, L.J. "Propel: An Approach

Supporting Property Elucidation" in proceedings of the IEEE International Conference on Software

Engineering (ICSE'02) , Orlando, 2002.

[Somé et al 1995] Somé, S., Dssouli, R. and Vaucher, J. "From Scenarios to Timed Automata: Building

Specifications from User Requirements" in proceedings of the Asia Pacific Software Engineering

Conference (APSEC'95) , 1995. pp. 48-57.

172

[Swartout and Balzer 1982] Swartout, W. and Balzer, R. On the Inevitable Intertwining of Specification and Implementation. Communications of the ACM vol. 25(7) , pp. 438-440, 1982.

[Systä 1997] Systä, T. "Automated Support for Constructing OMT Scenarios and State Diagrams in

SCED". Technical Report A-1997-8, Department of Computing, University of Tampere, Tampere,

Finland, 1997.

[Systä 2000] Systä, T. "Static and Dynamic Reverse Engineering Techniques for Java Software Systems".

Ph.D Thesis, Dept. of Computer and Information Sciences , University of Tampere, 2000.

[Szyperski 1998] Szyperski, C. Component Software. Beyond Object Oriented Programming : Addison

Wesley, Harlow, England, 1998.

[Texel and Williams 1997] Texel, P.P. and Williams, C.B. Use Cases Combined with Booch, OMT, and

UML : Prentice-Hall, Upper Saddle River, 1997.

[Tsiolakis 2001] Tsiolakis, A. Integrating Model Information in UML Sequence Diagrams. Electronic

Notes in Theoretical Computer Science vol. 50(3), 2001.

[Uchitel 2001] Uchitel, S. LTSA-MSC Tool, 2001. http://www.doc.ic.ac.uk/~su2/Synthesis/.

[Uchitel and Kramer 2001] Uchitel, S. and Kramer, J. "A Workbench for Synthesising Behaviour Models from Scenarios" in proceedings of the International Conference on Software Engineering (ICSE'01) ,

Toronto, 2001. IEEE Computer Society, pp. 188-197.

[Uchitel et al 2000] Uchitel, S., Kramer, J. and Magee, J. "From Sequence Diagrams to Behaviour

Models" in proceedings of the Workshop on Transformations in UML (WUTML), satellite event of the

European Joint Conferences on Theory and and Practice of Software (ETAPS'01) , Genoa, 2000.

[Uchitel et al 2001] Uchitel, S., Kramer, J. and Magee, J. "Detecting Implied Scenarios in Message

Sequence Chart Specifications" in proceedings of the Joint 8th European Software Engineering

Conference (ESEC'01) and 9th ACM SIGSOFT Symposium on the Foundations of Software Engineering

(FSE'01) , Vienna, 2001. ACM Press, pp. 74-82.

[Uchitel et al 2002a] Uchitel, S., Kramer, J. and Magee, J. "Detecting Implied Scenarios in the Presence of Behaviour Constraints" in proceedings of the International Workshop on Validation and

Implementation of Scenario-based Specifications (VISS'02) a satellite workshop of the 5th European Joint

Conferences on Theory and Practice of Software (ETAPS'02) , Grenoble, 2002a. 65, Electronic Notes in

Theoretical Computer Science,.

[Uchitel et al 2002b] Uchitel, S., Kramer, J. and Magee, J. "Negative Scenarios for Implied Scenario

Elicitation" in proceedings of the 10th ACM SIGSOFT Symposium on the Foundations of Software

Engineering (FSE'02) , Charleston, 2002b.

[Uchitel et al 2002c] Uchitel, S., Kramer, J. and Magee, J. Synthesis of Behavioural Models from

Scenarios. IEEE Transactions on Software Engineering vol. To appear.(, 2002c.

[Ullman and Hopcroft 1979] Ullman, J.D. and Hopcroft, J.E. Introduction to Automata Theory,

Languages, and Computation : Addison-Wesley, Reading, Mass., 1979.

[Wakahara et al 1989] Wakahara, Y., Kayuda, Y., Ito, A. and Utsunomiya, E. ESCORT: An Environment for Specifying Communication Requirements. IEEE Software vol. 6(2) , pp. 38-43, 1989.

[Weidenhaupt et al 1998] Weidenhaupt, K., Pohl, K., Jarke, M. and Haumer, P. Scenarios in System

Development: Current Practice. IEEE Software vol. 15(2) , pp. 34-45, 1998.

[Whittle and Schumann 2000] Whittle, J. and Schumann, J. "Generating Statechart Designs from

Scenarios" in proceedings of the 22nd International Conference on Software Engineering (ICSE'00) ,

Limerick, Ireland, 2000. pp. 314-323.

[Young and Barnard 1987] Young, M.R. and Barnard, P.B. "The Use of Scenarios in Human-Computer

Interaction Research: Turbocharging the Tortoise of Cumulative Science" in proceedings of the

Conference on Human Factors in Computing Systems and Graphics Interface (CHI/GI'87) , Toronto,

1987.

173

Incremental Elaboration of Scenario

Incremental Elaboration of Scenario-

Based Specifications and Behaviour

Models Using Implied Scenarios

Sebastian Uchitel

Abstract

Para Vanina con todo mi amor.

Acknowledgements

Table of Contents

List of Figures

Chapter 1

Chapter 1 Introduction

Chapter 2

Chapter 2 Background

Instances

Messages

Event Ordering

Extensions to Sequence Charts

Scenario Composition

State Identification

Triggers

Techniques

Design vs. early-requirement oriented semantics

Chapter 3

Chapter 3 Specifying Positive Scenarios

Chapter 4

Chapter 4 Behaviour Models

Summary of FSP

Chapter 5

Chapter 5 Implied Scenarios

Chapter 6

Chapter 6 Implied Scenario Detection

λ

On Deadlock and Implied Scenario Detection.

Chapter 7

Chapter 7 Specifying Negative

Scenarios

Chapter 8

Chapter 8 Implementation & Validation

Chapter 9

Chapter 9 Discussion and Evaluation

pressure query

reset reset

pressure

data

Chapter 10

Chapter 10 Conclusions

Bibliography

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib