a language definition method for visual specification ...grammar also defines the syntax of the...

A Language Definition Method

for Visual Specification Languages

DISSERTATION

DER WIRTSCHAFTSWISSENSCHAFTLICHENFAKULTAT

DER UNIVERSITAT ZURICH

zur Erlangung der Wurdeeines Doktors der Informatik

vorgelegt vonYong Xia

vonChina

genehmigt auf Antrag von

Prof. Dr. Martin GlinzProf. Dr. Jurgen Ebert

Februar 2004

Die Wirtschaftswissenschaftliche Fakultat der Universitat Zurich, Lehrbereich Informatik, ges-tattet hierdurch die Drucklegung der vorliegenden Dissertation, ohne damit zu den darin ausge-sprochenen Anschauungen Stellung zu nehmen.

Zurich, den 23. Juni 2004*

Der Lehrbereichsvorsteher: Prof. Dr. Martin Glinz

*Datum der Promotionsfeier

Acknowledgements

I would like to thank my supervisor, Prof. Dr. Martin Glinz for his many valuable instructions

and constant support during this research. Under his careful guidance over the last four and half

years, I gradually learned that how to independently carry out research and find key issues of

the problems, which are very important in my future career.

My research has been partially funded by the Swiss National Science Foundation (Grant No.

20-53828.98 and No. 20-65097.01).

I would also like to thank Prof. Dr. Jurgen Ebert for his careful review of my thesis and many

valuable comments.

I should also thank Prof. Chaochen Zhou, Prof. Dr. Anne Haxthausen, Prof. Chris George,

Prof. Guoxin Song. It is their instructions during my previous studies in (i) International Insti-

tute for Software Engineering, United Nations University, (ii) Computer Science and Engineer-

ing Section, Department of Informatics and Mathematical Modelling, Technical University of

Denmark, and (iii) Department of Computer Science and Engineering, East China University

of Science and Technology that made my further researches possible.

I am also very grateful to James Dowdall in the Computational Linguistics Group of our depart-

ment for his English proof-reading.

Of course, I am grateful to my parents and my wife for their patience and love. Without them

this work would never have come into existence.

Finally, I wish to thank all the members in the Requirement Engineering Research Group

(RERG) in our department (IFI/UNIZH): Dr. Norbert Fuchs, Dr. Stefan Berner, Stefan Hofler,

Silvio Meier, Arun Mukhija, Dr. Johannes Ryser, Nancy Merlo Schett, Uta Schwertel and

Christian Seybold. My thanks also extend to all professors and staff in our department.

iii

iv

Department of Information Technology, University of Zurich Yong Xia

February, 2004

Abstract

Language definition is always an important topic in the field of computer science. For textual

specification and programming languages, there are already lots of mature methods of language

definition. However, for visual specification languages, especially the so called wide spectrum

graphical modelling languages, the existing solutions are far from satisfactory.

ADORA[27] is a modelling technique for requirements and software architecture that is

being developed in the Requirement Engineering Research Group, University of Zurich. The

acronym stands for Analysis and Description of Requirements and Architecture. ADORA and

UML are typical examples of wide spectrum graphical modelling languages.

In this dissertation, we propose a new method of defining visual specification languages,

which shall overcome the drawbacks of the existing definition methods. The ADORA Language,

which is used to model system requirements and software architecture, is selected as a vehicle

for demonstrating our method.

The following four aspects of language definition are particularly addressed:

• Syntax and static semantics definition

A text-based technique is given for the syntax and static semantics definition. We exploit

the fact that in a visual specification language, most syntactic features are independent

of the layout of the graph. So we map the graphical elements to textual ones and de-

fine the context-free syntax of this textual language in EBNF. Using our mapping, this

grammar also defines the syntax of the graphical language. Simple spatial and context-

sensitive constraints are then added by attributing the context-free grammar. Finally, for

handling complex structural and dynamic information in the syntax, most of which is also

called static semantics in the literature, we give a set of operational rules that work on the

attributed EBNF.

We also extend this set of operational rules to specify an advanced feature of ADORA,

which supports the specification of partial and evolutionary systems.

• Dynamic semantics definition

We propose a strategy of dynamic semantics definition for ADORA: instead of defining

a formal semantics for the whole language at one time, which can be too complex to be

v

vi

understood and used, we define semantics first only for each simple sublanguage. Then

an integration semantics, which specifies the interrelations and constraints among the

sublanguages, is defined to keep the language self-consistent. Examples on the integration

semantics are given to show how our strategy works. Our solution is also valid for other

wide spectrum graphical modeling languages.

• Refinement calculus

We define a formal refinement calculus for the structural view, behavioral view and user

view of the ADORA language. This ensures the evolutionary specification is written in

a controlled and systematic way, while the consistency and integrity checking during

the system refinement can be mechanically carried out by a tool based on our formal

definition.

• The reciprocal influences between the language definition and language design

During the process of formal definition of ADORA, we also continue to design the lan-

guage (e.g. the extension of ADORA for supporting partial and evolutionary specifica-

tion). We conclude that language design and language definition are not two independent

tasks. The study of the reciprocal influences between these two tasks improves the quality

of the language definition. A set of principles derived from our development of ADORA is

presented.

Our methods can also be used to define UML or any other wide-spectrum modeling lan-

guages in the near future. Compared with the existing works on the graphical modeling lan-

guage definition, our language definition is more understandable, easier to apply and practically

more useful. The achieved results on the refinement calculus, syntax and semantics definition

are also valuable for the similar research.

At the end of this dissertation, limitations, open questions and future works are discussed.

Zusammenfassung

Im Gebiet der Computerwissenschaft ist die Sprachdefinition seit je her ein wichtiges Thema.

Fur die textuellen Spezifikations- und Programmiersprachen existieren viele reife Methoden

der Sprachdefinition. Fur die visuellen Spezifikationssprachen, insbesondere der “graphischen

Modellierungssprachen mit grossem/breitem Spektrum” (engl. wide spectrum graphical mod-

eling languages), sind die vorhandenen Losungen jedoch bei weitem nicht zufrieden stellend.

ADORA[27] ist eine objektorientierte Methode zur Spezifikation von Anforderungen und

Beschreibung von Software-Entwurfen, welche in der Forschungsgruppe Requirements En-

gineering der Universitat Zurich entwickelt wird. ADORA steht fur ‘Analyse und Beschrei-

bung von Anforderungen und Architekturen’ oder als Akronym fur Analysis and Description

of Requirements and Architecture. ADORA and UML sind die typischen Bespiele der “graphis-

chen Modellierungssprachen mit grossem/breitem Spektrum”.

Diese Dissertation stellt somit eine neue Methode zur Definition von visuellen Spezifika-

tionssprachen vor, welche die Nachteile der vorhandenen Methoden uberwindet. Die Spezifika-

tionssprache ADORA, die zur Modellierung von Systemanforderungen und Softwarearchitek-

turen verwendet wird, dient als Medium zur Demonstration dieser Methode.

Die folgenden vier Aspekte der Sprachdefinition werden besonders erarbeitet:

• Definition der Syntax und der statischen Semantik

Fur die Definition der Syntax und der statischen Semantik wird eine textbasierte Tech-

nik verwendet. Wir haben herausgefunden, dass die meisten syntaktischen Merkmale

einer visuellen Sprache vom Layout des Graphen unabhangig sind. Deswegen werden die

graphischen Elemente auf die textuellen Elemente abgebildet und die kontextfreie Syntax

dieser so erhaltenen textuellen Sprache in EBNF definiert. Dank der Abbildung definiert

diese Grammatik ebenfalls die Syntax der graphischen Sprache. Einfache raumliche und

kontextsensitive Beschrankungen werden dann durch das Attributieren der kontextfreien

Grammatik hinzugefugt. Zur Behandlung komplex strukturierter und dynamischer Infor-

mation in der Syntax, was in der Literatur auch statische Semantik genannt wird, wird eine

Menge von operationalen Regeln, die auf der attributierten EBNF basiert, angewandt.

Diese Menge von operationalen Regeln wird erweitert, um eine besondere Eigenschaft

vii

viii

ADORAs – die Spezifikation partieller und evolutionarer Systeme –, beschreiben zu konnen.

• Definition der dynamischen Semantik

Die Definition der dynamischen Semantik in ADORA basiert auf folgender Strategie:

Anstatt der formalen Semantikdefinition fur die gesamte Sprache zu beschreiben, welche

zu komplex sein kann, um sie zu verstehen und zu benutzen, wird zuerst nur die Semantik

fur jede Untersprache definiert. Dann wird eine Integrationssemantik definiert, die den

Zusammenhang und die Beschrankungen zwischen den Untersprachen spezifiziert, um

die Sprache selbst-konsistent zu halten. Es werden Beispiele fur die Integrationssemantik

gegeben, um zu zeigen, wie die Strategie funktioniert. Dieser Losungsansatz ist auch fur

andere “graphischen Modellierungssprachen mit grossem Spektrum” gultig.

• Verfeinerungskalkul

Hier wird ein formales Verfeinerungskalkul fur die Strukturelle Einblendung, die Verhal-

tensorientierte Einblendung und die Benutzer-Einblendung von ADORA definiert. Dadurch

wird dem evolutionaren Spezifikationsstil in einer kontrollierten und systematischen Art

und Weise Rechnung getragen, wahrend die Konsistenz- und die Integritatskontrollen im

Laufe der Systemverfeinerung mittels eines Werkzeugs, das sich auf unsere formale Def-

inition stutzt, automatisch durchgefuhrt werden.

• Reziproke Einflusse zwischen der Sprachdefinition und dem Sprachentwurf

Wahrend des Prozesses der formalen Definition von ADORA wird der Sprachentwurf

(z.B. die Erweiterung der ADORA zur Unterstutzung der partiellen und evolutionaren

Spezifikationen) erweitert. Es hat sich herausgestellt, dass die Sprachdefinition und der

Sprachentwurf nicht unabhangig voneinander sind. Die Studien uber die reziproken

Einflusse zwischen diesen zwei Aufgaben helfen, die Qualitat der Sprachdefinition zu

verbessern. Einige Prinzipien, abgeleitet aus der Erfahrung mit der Sprachentwicklung

ADORAs, werden dargestellt.

Die vorgestellte Methode kann ebenfalls zur Definition der UML und anderer kunftiger

“graphischen Modellierungssprachen mit grossem Spektrum” angewendet werden. Im Vergle-

ich zu den existierenden Werken uber die Definitionen graphischer Modellierungssprachen, ist

unsere Sprachdefinition verstandlicher, verwendbarer und demzufolge nutzlicher. Die erzielten

Resultate uber das Verfeinerungskalkul, die Syntax- und Semantikdefinition sind fur gleichar-

tige Forschungsprojekte sehr wertvoll.

Am Schluss dieser Dissertation werden Limitationen, offene Fragen und kunftige Arbeiten

diskutiert.

Table of Contents

I Introduction 1

1 Background 7

1.1 Benefits of the Formal Language Definition . . . . . . . . . . . . . . . . . . . 8

1.2 Types of Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2.1 Textual Programming Languages . . . . . . . . . . . . . . . . . . . . 9

1.2.2 Textual Specification Languages . . . . . . . . . . . . . . . . . . . . . 10

1.2.3 Visual Programming Languages . . . . . . . . . . . . . . . . . . . . . 12

1.2.4 Visual Specification Languages . . . . . . . . . . . . . . . . . . . . . 12

1.3 Typical Graphical Modelling Languages . . . . . . . . . . . . . . . . . . . . . 13

1.3.1 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.3.2 Other Graphical Modelling Languages . . . . . . . . . . . . . . . . . . 14

1.4 Existing Language Definition Techniques . . . . . . . . . . . . . . . . . . . . 15

1.4.1 String Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.4.2 Graph Grammars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.4.3 The OMG-UML approach: Metamodeling . . . . . . . . . . . . . . . 22

1.4.4 pUML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.4.5 Abstract Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.4.6 Semantics Definition for Simple Graphical Modelling Languages . . . 29

1.4.7 The Refinement Calculus . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.4.8 Other Language Definition Issues . . . . . . . . . . . . . . . . . . . . 32

1.5 Syntax vs. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2 ADORA 37

2.1 General Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.2 View Transitions and Navigation of Hierarchy . . . . . . . . . . . . . . . . . . 41

2.2.1 View Transitions in the Structural View . . . . . . . . . . . . . . . . . 41

2.2.2 View Transitions in the Behavioral View . . . . . . . . . . . . . . . . . 45

2.2.3 View Transitions in the User View . . . . . . . . . . . . . . . . . . . . 46

2.2.4 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

ix

x TABLE OF CONTENTS

2.3 Integration of Aspect Views . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.3.1 Integration of Statechart and Object Hierarchies . . . . . . . . . . . . . 48

2.3.2 Integration of Scenariochart and Object Hierarchies . . . . . . . . . . . 52

2.4 Partial and Evolutionary Specification . . . . . . . . . . . . . . . . . . . . . . 54

2.4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.4.2 Extension of the ADORA Language . . . . . . . . . . . . . . . . . . . 56

2.4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

2.5 A Comparison between ADORA and UML . . . . . . . . . . . . . . . . . . . . 58

II Language Definition Method 61

3 Definition of Syntax and Static Semantics 63

3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.2 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.3 Definition of Context-free Syntax . . . . . . . . . . . . . . . . . . . . . . . . 65

3.3.1 A Naive Graphics to Text Mapping . . . . . . . . . . . . . . . . . . . 65

3.3.2 The Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.3.3 EBNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.3.4 Abstract Syntax vs. Concrete Syntax . . . . . . . . . . . . . . . . . . 72

3.4 Definition of Static Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.4.1 Capturing Hierarchical Structure . . . . . . . . . . . . . . . . . . . . . 74

3.4.2 Attributing the EBNF Grammar . . . . . . . . . . . . . . . . . . . . . 75

3.4.3 Operational Rules in the Structural View . . . . . . . . . . . . . . . . 76

3.4.4 Operational Rules in the Behavioral View . . . . . . . . . . . . . . . . 87

3.4.5 Operational Rules in the User View . . . . . . . . . . . . . . . . . . . 91

3.4.6 A Global Constraint in the Behavior Views . . . . . . . . . . . . . . . 95

3.4.7 Global Constraints in the User Views . . . . . . . . . . . . . . . . . . 98

3.4.8 Some other Global Constraints . . . . . . . . . . . . . . . . . . . . . . 100

3.5 Extension on Supporting the Evolutionary Specification . . . . . . . . . . . . . 101

3.5.1 Well-formedness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.5.2 The Conservative Extension in the Structure View . . . . . . . . . . . 103

3.5.3 The Conservative Extension in the Behavior View . . . . . . . . . . . . 110

3.5.4 The Conservative Extension in the User View . . . . . . . . . . . . . . 112

3.6 A Short Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

4 Dynamic Semantics 115

4.1 Our Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

TABLE OF CONTENTS xi

4.1.1 Using the Methods of Textual Languages . . . . . . . . . . . . . . . . 115

4.1.2 Assigning the Formal Semantics to Simple Sublanguages . . . . . . . . 116

4.1.3 Model Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

4.1.4 Model management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

4.2 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

5 Refinement Calculus 125

5.1 Refinement Calculus in the Structural View . . . . . . . . . . . . . . . . . . . 126

5.2 Refinement Calculus in the Behavioral View . . . . . . . . . . . . . . . . . . . 130

5.3 Refinement Calculus in the User View . . . . . . . . . . . . . . . . . . . . . . 132

5.3.1 Avoiding Conflicts between two Aspect Views . . . . . . . . . . . . . 132

5.3.2 Ensuring the Modularity . . . . . . . . . . . . . . . . . . . . . . . . . 134

5.4 Merits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

6 Other Language Definition Issues 137

6.1 Verification Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

6.2 Application of our Methods to other Languages . . . . . . . . . . . . . . . . . 138

6.2.1 Syntax Definition of UML . . . . . . . . . . . . . . . . . . . . . . . . 138

6.2.2 Dynamic Semantics Definition of UML . . . . . . . . . . . . . . . . . 141

6.3 Influences of Language Definition on Language Design . . . . . . . . . . . . . 142

6.3.1 Influence of Language Definition on Language Design . . . . . . . . . 142

6.3.2 Reciprocal Influences . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

III Summary 147

7 Conclusions 149

7.1 Merits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

7.2 Limitations and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Bibliography 157

A The complete ADORA mapping table 163

B Attributed EBNF Syntax on ADORA 169

C Operational Rules in the Structural View 175

C.1 Syntactic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

C.2 General Format of Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

C.3 Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

xii TABLE OF CONTENTS

C.4 Concretization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

C.5 Remark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

C.5.1 Explanation on Abstraction . . . . . . . . . . . . . . . . . . . . . . . . 183

C.5.2 Explanation on Concretization . . . . . . . . . . . . . . . . . . . . . . 185

C.5.3 Reflexive Abstract Relationships . . . . . . . . . . . . . . . . . . . . . 187

D Operational rules for the evolutionary specifications 189

D.1 Syntactical Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

D.2 Reflexive Abstract Relationships . . . . . . . . . . . . . . . . . . . . . . . . . 189

D.3 Abstraction - Incomplete Specification . . . . . . . . . . . . . . . . . . . . . . 190

D.4 Concretization - Incomplete Specification . . . . . . . . . . . . . . . . . . . . 193

E Other Global Constraints 197

E.1 Global Constraints in the User View . . . . . . . . . . . . . . . . . . . . . . . 197

List of Figures

1.1 An Example of Web Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.2 Core Package - Backbone (from UML 1.5) . . . . . . . . . . . . . . . . . . . . 23

1.3 Core Package Relationships (from UML 1.5) . . . . . . . . . . . . . . . . . . 24

1.4 Modelling of the OMT concept of Class . . . . . . . . . . . . . . . . . . . . . 29

2.1 An ADORA view of the heating system: base view + structural view + context

view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.2 A partial ADORA model of the heating system: base view + behavior view . . . 39

2.3 A scenariochart modeling the structure of the ManageLocalRoomTemperature

scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.4 A partial ADORA model of a heating control system: base view and structural

view (at a highly abstracted level only with the most fundamental objects and

their relationships). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.5 Syntax of ADORA diagrams that show partial models only. Diagrams a) and c)

are syntactically correct representations of the example model given in the text;

diagram a) is syntactically wrong. . . . . . . . . . . . . . . . . . . . . . . . . 42

2.6 x hints the suppressed information of the association x1 between Object B1 and

A, and Object B1. The interrelationship between x2 and x shows the hierarchy

among the associations and abstract relationships. . . . . . . . . . . . . . . . . 43

2.7 Fisheye Algorithm and Hierarchical Decomposition . . . . . . . . . . . . . . . 44

2.8 a typical sequence of view transitions after an object is abstracted. . . . . . . . 45

2.9 (a) a (Generic) statechart with inter-level transitions. (b) The equivalent (generic)

statechart without inter-level transitions. . . . . . . . . . . . . . . . . . . . . . 46

2.10 An abtract generic statechart . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.11 View Transitions in a scenariochart. . . . . . . . . . . . . . . . . . . . . . . . 48

2.12 Transitions t1, t2, and t3 are legal; t4 is illegal. . . . . . . . . . . . . . . . . . . 50

2.13 Transitions t2, t5 and t6 are legal; t1, t3 and t4 are illegal. . . . . . . . . . . . . 50

2.14 Tansitions t1 is legal. Note that S3 is embedded in S1 and S4 is embedded in

S2, while S1 and S2 are at the same hierarchical level. . . . . . . . . . . . . . . 50

xiii

xiv LIST OF FIGURES

2.15 Start States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.16 Undesirable Layout of Start States . . . . . . . . . . . . . . . . . . . . . . . . 51

2.17 Improper referential semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.18 A graph with a proper referential semantics . . . . . . . . . . . . . . . . . . . 53

2.19 Complete Specification vs. Incomplete Specification . . . . . . . . . . . . . . 55

3.1 A naive one-to-one graphics-to-text ADORA Mapping Table . . . . . . . . . . 66

3.2 An Excerpt of the ADORA Mapping Table (1) . . . . . . . . . . . . . . . . . . 67

3.3 An Excerpt of the ADORA Mapping Table (2) . . . . . . . . . . . . . . . . . . 68

3.4 Macro Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.5 A sample object hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.6 Context-sensitive constraints of associations: r1 is not well-formed, r2 is well-

formed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

3.7 Context-sensitive constraint of state transitions. Transitions t1, t2, t3 are legal,

t4 is illegal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3.8 View transitions with histories. . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.9 The process of hiding an object from an ADORA diagram. The original and the

final diagram are well-formed, the intermediate ones are not. . . . . . . . . . . 80

3.10 Concretizing an object A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3.11 Abstract relationship u is replaced by Abstract relationship v . . . . . . . . . . 85

3.12 a) A correct series of view transitions with recording the history; b) A wrong

series of view transitions without recording the history. . . . . . . . . . . . . . 88

3.13 An example of View Transitions on the User View . . . . . . . . . . . . . . . . 92

3.14 a) an model with unclear meanings: b)an improved model of a television. . . . 96

3.15 s1 and s2 are indirectly connected. . . . . . . . . . . . . . . . . . . . . . . . . 97

3.16 a) A Tree form of Scenariochart; b) A graph form of scenariochart with circular

scenarios-relations; c) A graph form of scenariochart with two scenarios sharing

the same component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.17 The first diagram is not well-formed, and the second and third diagrams are

well-formed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

3.18 Abstracting an object A: a) a view based on a complete specification; b) a view

based on an incomplete specification. . . . . . . . . . . . . . . . . . . . . . . 104

3.19 The specifications with complete structural views . . . . . . . . . . . . . . . . 106

3.20 Concretizing an object A : a) a view based on an complete specification; b) a

view based on a incomplete specification . . . . . . . . . . . . . . . . . . . . . 106

3.21 a) View transitions in the Behavioral View of an original ADORA model; b)

View transitions in the Behavioral View of an extended ADORA+ model . . . . 111

LIST OF FIGURES xv

4.1 An illegal integration of a scenariochart and a generic statechart. . . . . . . . . 118

4.2 Integration of a scenariochart into an object hierarchy. . . . . . . . . . . . . . . 118

4.3 Classes of the structural view and the behavioral view. . . . . . . . . . . . . . 120

5.1 A legal integration of a scenariochart and a generic statechart. . . . . . . . . . 133

6.1 An Excerpt of the UML Mapping Table . . . . . . . . . . . . . . . . . . . . . 139

A.1 The complete ADORA mapping table 1 . . . . . . . . . . . . . . . . . . . . . 163





C.1 Summary of the operational rules on abstraction – general situation . . . . . . . 183

C.2 Summary of the operational rules on abstraction – special situation 1 . . . . . 184

C.3 Summary of the operational rules on abstraction – special situation 2 . . . . . . 184



C.6 View transitions of an object concretization . . . . . . . . . . . . . . . . . . . 186

C.7 View transitions of an object concretization - step 2 . . . . . . . . . . . . . . . 186

C.8 View transitions of an object concretization - step 3 . . . . . . . . . . . . . . . 187

C.9 Reflexive abstract relationships . . . . . . . . . . . . . . . . . . . . . . . . . . 187

xvi LIST OF FIGURES

List of Tables

1.1 Derivation Process of a Sentence . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.2 Four Layer Metamodeling Architecture . . . . . . . . . . . . . . . . . . . . . 22

xvii

xviii LIST OF TABLES

Part I

Introduction

1

3

Motivation:

Language definition is always an important topic in the field of computer science. For textual

specification and programming languages, there are already lots of mature methods on language

definition. However, for the visual specification languages, especially those so called wide

spectrum graphical modelling languages (such as UML), the existing solutions are far from

satisfactory. For example, OMG uses metamodeling technology to define UML. The several

hundred pages of definition have considerable drawbacks in practice. Some serious examples

are: (i) the metamodels used for the definition of UML are too large to understand; (ii) the

extensive usage of “inheritance” makes the understandability of the metamodels even worse;

(iii) the mixture of the syntactical and semantical definition makes a formal language definition

(even only for the core parts) impossible.

What is more, the notion of partial and evolutionary specification has gained more and more

attention both in research and industry. It should be supported in the language level. The

problem of how to define this notation in an understandable way is not properly solved.

Research Goals:

At the requirement engineering research group in the Intitut fur Informatik, University of Zurich,

a wide spectrum visual specification language ADORA, which stands for Analysis and Description

of Requirements and Architecture, is designed.

We need a precise language definition for ADORA as a part of our effort to develop this

language. This language definition should overcome the major drawbacks of the existing ap-

proach.

We also notice that the language properties of ADORA, such as hierarchical decomposition

mechanism, the elaborate model integrity concept and the notation of partial and evolutionary

specification, are very challenging problems during the language definition, and they need to be

suitably defined.

So far the definition methods for visual specification languages are far less mature than

those for textual specification and programming languages. They are the main topic of this

dissertation. The language definition methods cover the following parts.

1. How to define the syntax and the semantics for the visual specification languages? What

else should also be defined?

2. Which techniques are used for the language definition? Why they are selected?

Main Results:

In this dissertation, a language definition method is proposed, which should overcome the short-

comings of the existing methods. The following four aspects of language definition are partic-

4

ular addressed in our method.

• Syntax and static semantics definition

A text-based technique is given for the syntax and static semantics definition. We exploit

the fact that in a visual specification language, most syntactic features are independent

of the layout of the graph. So we map the graphical elements to textual ones and de-

fine the context-free syntax of this textual language in EBNF. Using our mapping, this

grammar also defines the syntax of the graphical language. Simple spatial and context-

sensitive constraints are then added by attributing the context-free grammar. Finally, for

handling complex structural and dynamic information in the syntax, most of which is also

called static semantics in the literature, we give a set of operational rules that work on the

attributed EBNF.

We also extend this set of operational rules to specify an advanced feature of ADORA,

which supports the specification of partial and evolutionary systems.

• Dynamic semantics definition

We propose a strategy of dynamic semantics definition for ADORA: instead of defining

a formal semantics for the whole language at one time, which can be too complex to be

understood and used, we define semantics first only for each simple sublanguage. Then

an integration semantics, which specifies the interrelations and constraints among the

sublanguages, is defined to keep the language self-consistent. Examples on the integration

semantics are given to show how our strategy works. Our solution is also valid for other

wide spectrum graphical modeling languages.

• Refinement calculus

We define a formal refinement calculus for the structural view, behavioral view and user

view of the ADORA language. This makes the evolutionary specification to be written

in a controlled and systematic way, while the consistency and integrity checking during

the system refinement can be mechanically carried out by a tool based on our formal

definition.

• The reciprocal influences between the language definition and language design

During the process of formal definition of ADORA, we also continue to design the lan-

guage (e.g. the extension of ADORA for supporting partial and evolutionary specifica-

tion). We conclude that language design and language definition are not two indepen-

dent tasks. The study of the reciprocal influences between these two tasks improves the

quality of the language definition. A set of principles derived from our development of

ADORA are presented.

5

Structure:

The structure of this dissertation is given as follows.

In the first part of this dissertation, Chapter 1 introduces the background of language defini-

tion, which consists of

• different types of languages,

• typical graphical modelling languages, and

• existing language definition techniques, which include methods for syntax and semantics

definition.

ADORA is introduced in the second chapter. It will be used as a vehicle to demonstrate our

language definition method.

In the second part of the dissertation, the language definition method is introduced in detail.

The definition method for syntax and static semantics is given in Chapter 3. A strategy for

dynamic semantics definition is given in Chapter 4. Chapter 5 introduces a refinement calculus

for visual specification languages. Other language definition issues and the application of our

language definition method to UML are shortly discussed in Chapter 6. In Chapter 7, the

reciprocal influences between the language definition and language design will be discussed.

In the last part, the dissertation is concluded with the strength of our method, its limitations

and the future works.

Chapter 1

Background

A language becomes useful only when it is properly defined (implicitly or explicitly). This

is true for all languages: natural language (English, German, Chinese, etc.) and computer

languages (PASCAL, C++, (T)RSL, UML, ADORA , etc.).

Natural language is implicitly defined. In the thousands years of evolution of natural lan-

guage, people develop a common understanding for the structure of phrases and sentences, the

meaning of words, etc.

For artificial languages (including computer languages), this evolutionary process has very

few chance of existence. The most parts of artificial languages must be explicitly defined at the

very beginning. However, they can be defined informally or formally (i.e. they can be defined

by natural language, by compilers or by formal specifications).

In this dissertation, ‘language’ refers only to languages used in the software engineering

field. The definition of languages may include the following parts.

1. Syntax definition

Syntax is a set of rules for the construction of orthographically and grammatically correct

statements of a language.

2. Static semantics definition

Static semantics define how an instance of a construct should be connected to other in-

stances (of the same construct or other constructs) to be meaningful. Static semantics

is also called “well-formedness rules”. What is more, for a programming language, the

definition of code generation is also be considered as a part of “static semantics” (C.f. the

explanation of code generation). In this dissertation, we consider that code generation is

independent of static semantics.

3. Dynamical semantics definition

Dynamical semantics define the meaning of syntactically correct and well formed state-

ments of a language.

4. Refinement calculi

7

8 CHAPTER 1. BACKGROUND

The refinement calculi are notations and sets of rules for deriving a more detailed speci-

fication from an abstract one or an implementation/program from a specification.

5. Verification rules

Verification rules are used to check the correctness of programs and specifications with a

formal proof system.

6. Secondary notation

The secondary notation conveys additional meaning above and beyond the “official se-

mantics” of the specification language or it disambiguates syntactic structure in order to

assist in interpreting semantics [17].

7. Code generation

There are two types of code generation.

• Code generation is a technique, which translate a program with high a level pro-

gramming language (such as PASCAL, C, JAVA, etc.) into a program with machine

codes. In this situation, the definition of code generation is considered as a part of

static semantics in some literature.

• For a specification language, code generation is the technique of using programs

that build application and system code. The inputs of a basic “Code Generator” are

(i) the specifications or design models and (ii) templates.

8. Model simulation methods The methods of model simulation and code generation are

so far an optional part of definition for graphical modelling languages. The methods

of model simulation define an executable (software) model, which have the potential of

allowing developers to analyze dynamic properties early on without the need for imple-

mentation.

We will systematically talk about the above parts in the dissertation, though each part is not

explained at the same detailed level.

Generally speaking, syntax definition, semantics definition and refinement calculus are the

most important parts in the language definition. Therefore, they are the focuses of our definition

method, and the background on these three parts will be introduced in detail.

1.1 Benefits of the Formal Language Definition

The language is the media of communication among people and between human beings and

machines. Natural language is even syntactically informally defined, let alone semantically.

This brings nearly unlimited power to the expressiveness of natural language. Meanwhile, it

brings also the irregularities and ambiguities that may be partially acceptable in the communi-

cation among human beings, but very unwelcome in the communication between human beings

1.2. TYPES OF LANGUAGES 9

and computers. In the development of high quality software systems, it is impossible to use a

language without formal definition.

A formally defined syntax eases the learning process of the language. It is a necessity for a

computer’s interpretation. Only when a formal syntax is already defined, can a formal semantics

be given.

A formally defined semantics makes a formal (or sometimes even mechanical) refinement

and verification possible.

The benefits of formal language definition will be further discussed in Chapter 4.

1.2 Types of Languages

We divide the languages in software engineering into four groups: (i) textual programming

languages (ii) textual specification languages (iii) visual programming languages (iv) visual

specification languages

In the following sections, a brief introduction to the different types of language in the soft-

ware engineering field will be given. Moreover, the following aspects will also be discussed.

• Definition or characteristics of each type of language

• Typical examples of each type of language

• Syntax definition

• Semantics definition

• Formal verification, mechanical verification and formal refinement

• Other important aspects of each type of language

Note that the following subsections do not serve as a complete survey of textual program-

ming languages, textual specification languages, and visual programming languages. Only as-

pects relating to the language definition will be presented.

1.2.1 Textual Programming Languages

One of the important characteristics of the programming languages is that: a program written

in that language can be directly executed in a computer after compilation or interpretation.

Typical examples of textual programming languages are: Prolog, PASCAL, C, C++, JAVA,

C�, etc.

The definition of textual programming languages is relatively easy.

For the syntax definition, EBNF (Extended Backus-Naur Form) is a most efficient and

widely used method. EBNF form of syntax definition is easy for users to understand the lan-

guage syntax. A parser, which checks a context-free syntax of the textual programming lan-

guage, can also be automatically generated by inputting the EBNF form of syntax definition

and using some tools, such as YACC (Yet Another Compiler Compiler).


As the size of a textual programming language is usually small, there are not many context-

sensitive syntactical constraints. Therefore, they can easily be unambiguously defined with

some simple formal definition techniques (e.g. attributed EBNF, a first order logic, etc.).

EBNF-based syntax definition also provides an excellent base for the semantics definition.

A lot of mature methods (e.g. operational semantics, denotational semantics, axiomatic se-

mantics, etc.) have been given in the last four decades. They have proved to be efficient and

useful.

Every textual programming language, which is really used in research communities and

industries, has a formally defined syntax and a formal (static) semantics based on the syntax.

Otherwise, the computer can not parse and compile them.

Formal verification of a program is very expensive but feasible. Therefore, it is usually

applied only to the safety critical applications. There are two types of formal verification:

manual formal verification and mechanical verification. Both types of verification are possible

only when a formally defined syntax, semantics and verification rules are given. Theorem

Prover and Model Checking tools are two typical examples of mechanical verification, which

have proved to be really useful for safety critical parts of software systems.

Formal refinement is a complementary method to formal verification. There are quite a lot

of mature theories on the refinement calculus for textual programming languages. [54] is one

of the most famous works in the field of refinement calculus, which will be introduced in 1.4.7.

Just as with formal verification, formal refinement is also very expensive, and hence is used

only for the critical part of software systems.

1.2.2 Textual Specification Languages

Textual specification languages are used to describe the system specification. In the early days

of software development, most problems were not so complex. The requirements of software

systems were more or less clear. People directly wrote program codes instead of doing the work

of requirements analysis and writing a specification for the system. Later the systems became

more and more complicated, and people had to carefully make a system specification. How-

ever, the specifications were usually written in natural language, or structured natural language.

Only during the past years have people in industry recognized the importance of the formal

specification languages, and work on the formal syntax and formal semantics for them.

Compared with the textual programming languages, the expressiveness of textual specifi-

cation languages is much more powerful. Therefore, the definition of a textual specification is

usually more difficult. Note that in the following text, when we talk of specification languages,

we refer to the semiformal or formal ones. Natural languages will not be discussed in this

dissertation.

Just as with the textual programming language, textual specification languages are usually

1.2. TYPES OF LANGUAGES 11

syntactically defined in the EBNF form. Textual specification languages have more language

constructs than textual programming languages. However, they are not much more difficult to

define.

Defining the semantics of a specification language is more difficult than doing that for a

programming language. This is because the semantic domain of a specification language can

be somehow unspecified. There is lots of excellent and mature work on giving the semantics to

a textual specification.

Typical examples of early textual specification languages are: Z[69] , VDM[5], CSP[34],

CCS[48], DC[74], TLA+[43], PSL/PSA[70], RML[29], ESPRESO[45] and SPADES[46], etc.

Later, so called wide spectrum specification languages are designed for the applications in In-

dustry. These types of languages integrate into one language various styles:

• abstract or concrete

• applicative or imperative

• sequential or concurrent

A typical example of those wide spectrum specification languages is (T)RSL[63][64][73][37].

All of the textual specification languages have a formal syntax and a formal semantics on

the (core) syntax.

Just as with those of textual programming languages, formal verification and formal re-

finement of textual specification languages are very expensive, but useful for the small but

extremely critical parts of the system specification.

1.2.2.1 Programming Languages vs. Specification Languages

The differences between programming languages and specification languages are listed as fol-

lows.

• A program, which is written correctly in a programming language, can be executed in

a computer. A specification, which is written correctly in a specification language, usu-

ally can not be directly executed in a computer, though perhaps it can be automatically

translated into an executable program.

• The semantic domain of a programming language comprises either the basic types (e.g.

integer, real, char, etc.) or the types which is constructed from those basic types. The

semantic domain of a specification language may also include the “abstract” types, whose

instances are any objects of the real world. Note that this gives more difficulties when we

define the semantics for a specification. For example, in a denotational semantics, the

semantic function should be a continuous function on a semantic domain with a complete

partial order.


1.2.3 Visual Programming Languages

“A graph is worth of a thousand words.” Visual programming languages [68][13] use visual no-

tations or diagrams for expressing programming constructs. Visual programming languages are

two- or multi-dimensional, which makes syntax definition much more complex. Some graph

grammars, which are more powerful but also more complex than EBNF, are introduced to el-

egantly define the syntax of visual programming languages. Due to the complexity of graph

grammars, the language syntax defined in graph grammars is much more difficult to understand

than that defined in EBNF. However, for a two- or multi-dimensional visual programming lan-

guage, in which graph layouts play an important role in the language syntax and semantics,

grammatical approaches (e.g. graph grammars, attributed multiset grammars [51]) are the usual

solutions to the syntax definition.

There is also quite a lot of work on formal semantics. For example, spatial logic, textual or

visual operational rules are used to define the semantics. When the semantics is given visually,

diagrammatic reasoning can be used in the formal verification, although it seems to be very

unpractical in real applications. When the semantics are given in a textual form, formal verifi-

cation can be done in the same way as for the textual languages. There is not much influential

work on formal verification and refinement in the fields of visual programming languages.

It seems that visual programming languages are not really accepted in industry. They are

more complex than textual programming languages, but don’t have many extra advantages.

Some famous visual programming languages in the research community are: Prograph[14],

Pictorial Janus[28], Forms/3[7], etc.

1.2.4 Visual Specification Languages

On the contrary, visual specification languages have been accepted as an indispensable tool

in software development. Lots of manufacturers of visual programming languages are mov-

ing or have moved their focuses from developing tools for visual programming languages to

developing tools for visual specification languages (code generation, model simulation, model

generation from the codes, etc.).

The reason for wide acceptance of visual specification languages is that specifications usu-

ally need to be validated by customers and administrative staff, who are perhaps not familiar

with computer science at all. A semiformal graphical notation is really helpful for communica-

tions among computer professionals, customers and administrative staff.

Visual specification languages are also called graphical modelling languages. Entity Rela-

tionship Diagram (ERD)[10], Data Flow Diagram (DFD)[16], Statechart[30], and SADT[65]

are the early graphical modelling languages. OMT, OOSE, etc. are the first object oriented

modelling languages. Nowadays UML has become the dominating graphical modelling lan-

1.3. TYPICAL GRAPHICAL MODELLING LANGUAGES 13

guage. Just like RSL[63][64] in textual specification languages, UML is also a wide spectrum

visual specification language, as it integrates a loose coupled set of sublanguages with various

styles. In the Requirements Engineering Research Group of the University Zurich, we have

developed a modelling language for requirements and architecture called ADORA . It is also

a wide spectrum visual specification language, which, in contrast to UML, integrates a tightly

coupled set of sub-languages with various styles.

Because of the time constraint of our research and the space limit of this dissertation, our

research and all discussions in this dissertation focus only on the field of visual specification

languages. Nevertheless, our results can also be applied to the other language fields.

Before we start to talk of our methods, let us first review typical graphical modelling lan-

guages and the existing definition methods for visual specification languages.

1.3 Typical Graphical Modelling Languages

1.3.1 UML

At the center of the UML (Versions 1.2 to 1.5) are its nine kinds of modelling diagrams (nine

sublanguages).

• Use case diagrams

• Class diagrams

• Object diagrams

• Sequence diagrams

• Collaboration diagrams

• Statechart diagrams

• Activity diagrams

• Component diagrams

• Deployment diagrams

Each of the above nine sublanguages describes individual aspect of a software system.

Use case diagrams describe what a system does from the standpoint of an external observer.

The emphasis is on what a system does rather than how.

Class diagrams give an overview of a system by showing its classes and the relationships

among them. Class diagrams are static – they display what interacts but not what happens when

they do interact. To simplify complex class diagrams, one can group classes into packages. A

package is a collection of logically related UML elements.

Object diagrams show instances instead of classes. They are useful for explaining small

pieces with complicated relationships, especially recursive relationships.


Class and object diagrams are static model views. Interaction diagrams are dynamic. They

describe how objects collaborate.

A sequence diagram is an interaction diagram that details how operations are carried out –

what messages are sent and when. Sequence diagrams are organized according to time. The

time progresses as you go down the page. The objects involved in the operation are listed from

left to right according to when they take part in the message sequence.

Collaboration diagrams are also interaction diagrams. They convey the same information as

sequence diagrams, but they focus on object roles instead of the times that messages are sent.

In a sequence diagram, object roles are the vertices and messages are the connecting links.

Objects have behaviors and states. The state of an object depends on its current activity or

condition. A statechart diagram shows the possible states of the object and the transitions that

cause a change in state.

An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart di-

agrams are related. While a statechart diagram focuses attention on an object undergoing a

process (or on a process as an object), an activity diagram focuses on the flow of activities in-

volved in a single process. The activity diagram shows that how these activities depend on one

another.

A component is a code module. Component diagrams are physical analogs of class dia-

grams. Deployment diagrams show the physical configurations of software and hardware.

As lots of books and papers ([56], etc.) introducing UML are available, we will not give

more details here.

Note that UML is a language with loosely coupled sublanguages. It does not have an inte-

grated model. In UML, there are no constructs or mechanisms which enforce the integrity and

consistency checking at the language level.

1.3.2 Other Graphical Modelling Languages

Actually UML is a language which evolved from some early object-oriented graphical mod-

elling languages, such as Booch, OMT, OOSE, etc. The early object-oriented graphical mod-

elling languages evolve from the graphical modelling languages with the methodology of struc-

tural analysis and structural design, such as Entity Relationship Diagram, Dataflow Diagram,

Statechart, etc.

Among the early graphical modelling languages, ERD and Statechart are the most important

languages, which greatly influence the modelling languages of today. Statechart comes from

State Automaton. It has a strictly defined syntax and semantics, which are easily understandable

and applicable. Based on the formal semantics, some successful formal verification methods,

such as model checking, are set up. Therefore, it is an ideal modelling tool for safety critical

parts of a system, because of its expressiveness and its formal definition.

1.4. EXISTING LANGUAGE DEFINITION TECHNIQUES 15

1.4 Existing Language Definition Techniques

In this section, we will introduce the background on existing language definition techniques.

Much material is strictly based on [11] [12] [41] [51] [57].

1.4.1 String Grammar

Textual programming languages and textual specification languages are characterized as string

languages, or ”one dimensional languages”. The most famous grammatical approach of the

syntax definition of textual languages is string grammar.

Before we explain the concepts of grammars, let us first see a simple example.

There are a set of grammar rules in English, some of which are listed as follows.

1. <sentence>→<noun-phrase><verb><direct-object phrase>

2. <noun-phrase>→<proper-noun>

3. <noun-phrase>→<determiner><common-noun>

4. <proper-noun>→<Mary>

5. <determiner>→ a

6. <determiner>→ the

7. <common-noun>→ car

8. <verb>→ drives

9. <direct-object phrase>→<adjective-list><proper-noun>

10. <direct-object phrase>→<determiner><adjective-list><common-noun>

11. <adjective-list>→<adjective><adjective-list>

12. <adjective-list>→ ∅13. <adjective>→ big

14. <adjective>→ green

15. ...The sentence, Mary drives a big green car, is a syntactically correct sentence, because it can be

generated by the following transformations.

Derivation Rule Applied

<sentence> →<noun-phrase><verb><direct-object phrase> 1

→<proper-noun><verb><direct-object phrase> 2

→ Mary <verb><direct-object phrase> 4

→ Mary drives <direct-object phrase> 8

→ Mary drives <determiner><adjective-list><common-noun> 10

→ Mary drives a <adjective-list><common-noun> 5

→ Mary drives a <adjective><adjective-list><common-noun> 11

→ Mary drives a big <adjective-list><common-noun> 13


→ Mary drives a big <adjective><adjective-list><common-noun> 11

→ Mary drives a big green <adjective-list><common-noun> 14

→ Mary drives a big green <common-noun> 12

→ Mary drives a big green car 7

Table 1.1: Derivation Process of a Sentence

Any sentences, which can not be generated by a sequence of transformations based on the

grammatical rules, are syntactically wrong.

One dimensional computer language is defined similar to natural language, which is also

defined as a set of strings over an alphabet.

Languages of interest are not comprised of arbitrary sets of strings but rather of strings

having specified forms. The acceptable forms define the syntax of the language.

Following Chomsky [11] [12] the syntax of one dimensional language is specified using

a (phrase-structure) grammar. Grammars are composed of production rules (such as the 14

rules in the above example) which specify the composition of grammatical components (e.g.

sentence, noun-phrase in the above example).

The alphabet of a language consists of the indecomposable elements from which the strings

are constructed. These elements are called terminal symbols. In the above example, “Mary”,

“drives”, “a”, “big”, “the”, etc. are the terminal symbols. The symbols, which can appear on the

left side of “→” in the grammatical rules, are non-terminal symbols. A string which contains

only terminal symbols is a sentence (or a statement in the programming language).

Chomsky divided the phrase structure grammars into four types according to the form of the

productions in the grammar.

• Type 0 or unrestricted grammars allow productions to have any number of terminal or

non-terminal symbols on either side of the production.

• Type 1 or context-sensitive grammars allow productions to have the form

aAb → aXb

where A is a non-terminal symbol, X is a non-empty string of symbols, and a and b are

possibly empty strings. The production is understood to mean that “A can be replaced by

X in the context of a and b”.

• Type 2 or context-free grammar does not allow contexts. Its rules have the form

A → X

• Type 3 is also said to be regular grammars. In these grammars productions must be of the


form

A → aB or A → a

Where a is a terminal symbol and A and B are non-terminal symbols.

John Backus and Peter Naur used a system of rules to define the programming language

ALOGL 60. The method of definition employed is now referred to as Backus-Naur form, or

BNF. A BNF description of a language is a context-free grammar. Most of the textual program-

ming and specification languages are defined in the BNF or a slightly extended form of BNF

(EBNF).

1.4.1.1 Static Semantics

With the string grammar, we can only determine the context-free syntax correctness of a pro-

gram.

The static semantics of a programming language includes (i) code generation (the mean-

ing of the statements in a language in the view of a computer), (ii) definition of a meaningful

connection among an instance of a construct to other instances (of the same construct or other

constructs).

One way of formalizing this process, suggested by Knuth [41], is using attributes. Attributes

are values associated with each symbol and production rules specify how the attributes of the

left-hand and right-hand sides may be computed from the other. Attributed context-free gram-

mars are widely used for the specification of computer languages, where an attribute might

detail the type of an expression.

[57] gives a formal and clear definition and detailed examples of attribute grammars. Here

we just show parts of an example from that paper to demonstrate how the attribute grammars

look.

Suppose we have a simple desk calculation language, DESK. In DESK, one can write pro-

grams of the the form

PRINT < expression > WHERE < definitions > ,

where <expression> is an arithmetic expression over numbers and defined constants, and

<definitions> is a sequence of constant definitions of the form

< constant name > = < number >.

Each named constant applied in <definitions>, and <definitions> may not give multiple values

for a constant. For instance,the following is a DESK program:

PRINT x + y + 1 WHERE x = 1, y = 2.

In the following text, we specify the DESK langauge with an attribute grammar. An attribute

grammar (AG) consists of three components, a context-free grammar G, a finite set of attributes

A, and a finite set of semantic rules R: AG = <G, A, R>. G specifies the (context-free) syntax

of the target language, and A and R specify the static semantics of the language.


For simplicity, we make use of an assembly code for a simple one-register machine as the

target. The relevant assembly instructions are the following.

LOAD n, loads the value n into the register;

ADD n, increments the contents of the register with value n;

PRINT 0, prints the contents of the register;

HALT 0, halts the machine.

Parts of the context-free grammar G for DESK consists of the following elements:

N = { Program, Expression, Factor, ConstName, ConstPart, ...},

T = { ‘PRINT’, ‘WHERE’, ‘,’, ‘=’, ‘+’, Id, Number},

P = { Program → ‘PRINT’, Expression ConstPart,

Expression → Expression ‘+’ Factor,

Expression → Factor,

Factor → ConstName,

Factor → Number,

ConstName → Id,

... },...

We need to have the following attributes A.

code, synthesized target code;

name, synthesized name of a constant;

value, synthesized value of a constant or a number;

envs, synthesized environment (symbol table)

envi, inherited environment (symbol table)

ok, synthesized indicator of correctness.

The target code is a list of instructions of the form (operation code, argument). An environ-

ment is a list of binding of the form (name, value)

The (static) semantic rules R are associated with the productions as follows, using the no-

tation “production {semantic rules}”. Within a production, different occurrences of the same

grammar symbol are denoted by distinct subscripts.

(p1) = Program → ‘PRINT’, Expression ConstPart

{Program.code = if ConstPart.ok

then Expression.code + (PRINT, 0) + (HALT, 0) else (HALT, 0),

Expression.envi = ConstPart envs}(p2) = Expression1 → Expression2 ‘+’ Factor


{Expression1.code = if Factor.ok

then Expression2.code + (ADD, Factor.value) else (HALT, 0),

Expression2.envi = Expression1.envi,

Factor.envi = Expression1.envi}(p3) = Expression → Factor

{Expression.code = if Factor.ok then (LOAD, Factor.value) else (HALT, 0),

Factor.envi = Expression.envi}(p4) = Factor → ConstName

{Factor.ok = isin(ConstName.name, Factor.envi),

Factor.value = getvalue (ConstName.name, Factor.envi)}(p5) = Factor → Number

{Factor.ok = true, Factor.value = Number.value}(p6) = ConstName → Id

{ConstName.name = Id.name}(p7) ...

As usual in attribute grammars, we assume that the values of the intrinsic attributes Id.name

and Number.value of the terminal symbols are externally provided, e.g. by a lexical analyzer.

We have applied the following semantic functions (some of them written in a more conve-

nient infix notation):

if(c, v1, v2), if c yields true, returns v1 else returns v2;

+(1, 2), returns the catenation of lists 1 and 2;

isin(n, e), if the environment e contains a binding (n, x), returns true else return false;

getvalue (n, e), if the environment e contains a binding (n, x), returns x else return 0;

... ...

Note that the attributes and the (static) semantics rules specify two aspects of information:

(i) one is related to the code generation; (ii) and the other is related to the context-sensitive

constraints. The second aspect is also called context-sensitive syntax (c.f. Section 1.5). For

more explanation, please refer to [57].

1.4.2 Graph Grammars

There are two main generic approaches to visual language specification: graph grammars 1

in which graphs have labelled edges and nodes, and attributed multiset grammars. They are

originally proposed for defining any kind of visual languages, which are not necessary in the

fields of software engineering.

1Here we use graph grammars in a broad sense. It includes generalized string grammars (e.g. attributedshape grammar, tree grammar, positional grammars, etc.), graph grammar based methods (web grammars, plexgrammars, etc.)[51]


The idea of graph grammars is to interpret graphic models as mathematical graphs and to use

graph transformation rules to express the rules for constructing correct diagrams. Interpreting

diagrams written in a visual language as graphs is appealing because the graphs preserve the

information given by the graphic layout of the diagrams which is syntactically relevant to a

large extent in visual programming languages.

In this section, we will give a short introduction to graph grammars. In [51] there is an

excellent and detailed explanation of this topic for the readers interested in this subject.

In essence, all graph grammars can more or less be thought of as a kind of extension on string

grammars. In order to specify the syntax of visual languages, in contrast to string grammars,

they make the following extensions and modifications to cope with two-dimensional informa-

tion (such as graphic layout).

1. Terminals are interpreted as two-dimensional objects, such as straight lines, or arcs.

2. Attributes are also used to specify the spatial information (such as graphic layout), not

only the static semantics.

3. The one-dimensional concatenation in the production rules is extended to the multi-

dimensional concatenation. An example of this group of grammars is Positional Gram-

mars. Productions in a positional grammar have the form:

A → a1 REL1 a2 REL2 RELn−1 an

Where A is a non-terminal symbol, the ais are terminal or non-terminal symbols, and

RELi specifies the position of ai+1 relative to ai (an arbitrary spatial relationship between

ai+1 and ai).

4. The functionalities of the elements in the production rules are extended. These ap-

proaches make graph grammars essentially different from string grammars. And there-

fore, some researchers categorize only this group of grammars as true graph grammars.

The typical examples of this group of approaches are Web Grammar, Plex Grammar,

Attributed Programmed Graph Grammar, etc.

Here, we use an example of Web Grammar from [51] to show some general characteristics

of this group of graph grammars.

Web Grammar was proposed by Pfaltz and Rosenfeld [60]. Sentences generated by a web

grammar are directed graphs with symbols at the nodes. Such node-labelled graphs are

called webs. A web production replaces some sub-web inside of a host web and has the

form

α → βE


where α and β are webs and E is an embedding which specifies how β is to be connected

to the host web ω when α is replaced by β. The definition of the embedding must not

depend on the details of a particular host web since we can use the production to replace

α by β in any web containing α as a sub-web. Typically, an embedding is a logical

function which details how those nodes connected by a single edge to nodes in α are to

be connected to the nodes in β. These nodes are called the neighborhood of α. A web

production is said to be context-free if α contains only a single node. Analogously we can

define context-sensitive web productions. Figure 1.12 shows the form of all webs, which

is specified by a context free web grammar [23].

A � a

b

c

E = {(p, a) | (p, A) is a branch in the host web}

A � a

b

c

E = {(p, a) | (p, A) is a branch in the host web}

A

Language a

b

c

b

a

c

b

c

b

a

c

a a a ... a

b

c

Figure 1.1: An Example of Web Grammar

For a graph grammar specifying a real visual programming language, the first two extensions

are necessary. In most of cases, it has at least one of the last two extensions.

Graph grammars are really powerful tools in description of visual languages’ syntax. How-

ever, some price is paid for this powerfulness. One of the shortcomings of this method is that

graph grammar, unlike the context free grammar, such as EBNF, is much more difficult to read

and understand for humans. Moreover, only a restricted class of graphs can be described by

graph grammars such that a parser can be constructed directly and easily from the grammar.

For visual programming languages, graph grammars are good approaches. For the visual

specification language, in which layout is much less syntax-sensitive than the visual program-

ming language, graph grammars are not a good fit. I.e. we do not need to pay the price for the

powerfulness of the graph grammars.

An another grammatical specification formalism, which is used to specify the visual lan-

guage, are attributed multiset grammars. They are more complex, yet more expressive, than

2Source: Visual Language Theory, Kim Marriott and Bernd Meyer, Page 18.


the graph grammars. Therefore, attributed multiset grammars are also not a good choice for

definition of visual specification languages.

1.4.3 The OMG-UML approach: Metamodeling

The OMG-UML approach of the UML definition includes the following three parts.

1.4.3.1 Abstract Syntax

Metamodeling technique is used in the OMG-UML approach to define the syntax of UML. It

emerged with the design of entity-relationship-based modelling language. The principal idea

is to define the syntax of an entity-relationship-based language by a model that is expressed

either in the same language or in a simpler, also entity-relationship-based language. Principally

speaking, every definition of a modeling language is a metamodel, including definitions by

grammars or by formal logic. However, the term ‘metamodel’ is typically restricted to the

meaning described above.

Let us see the Metamodeling technique in OMG-UML approach in detail.

The UML metamodel is defined as one of the layers of a four-layer metamodeling architec-

ture.

Layer Description Example

Meta- The infrastructure for a MetaClass, MetaAttribute,

metamodel metamodeling architecture. MetaOperation

Defines the language for

specifying metamodels.

metamodel An instance of a meta- Class, Attribute, Operation,

metamodel. Defines the Component

language for specifying a model.

Model An instance of a metamodel. StockShare, askPrice,

Defines a language to describe an sellLimitOrder,

information domain. StockQuoteServer

User An instance of a model. Defines a <Acme SW Share 98789>,

Objects specific information domain 654.56, sell limit order

Table 1.2: Four Layer Metamodeling Architecture

The meta-metamodeling layer forms the foundation for the metamodeling architecture. The

primary responsibility of this layer is to define the language for specifying a metamodel. A

meta-metamodel defines a model at a higher level of abstraction than a metamodel, and is


typically more compact than the metamodel that it describes.

A metamodel is an instance of a meta-metamodel. The primary responsibility of the meta-

model layer is to define a language for specifying models. Metamodels are typically more

elaborate than the meta-metamodels that describe them, especially when they define dynamic

semantics.

A model is an instance of a metamodel. The primary responsibility of the model layer is to

define a language that describes an information domain.

User objects (a.k.a. user data) are an instance of a model. The primary responsibility of the

user objects layer is to describe a specific information domain.

Element

ModelElement

name : Name

{ordered}

+parameter

+constraint

isRoot : BooleanisLeaf : BooleanisAbstract : Boolean

GeneralizableElement

Namespace

+type

+type

Parameter

defaultValue : Expressionkind : ParameterDirectionKind

*

Constraint

body : BooleanExpression

Classifier

+owner+feature

{ordered}

*

{ordered}*

0 .. 1

0 .. 1

+typedFeature*

+typedParameter **

*+ownedElement

concurrency : CallConcurrencyKIndisRoot : BooleanisLeaf : BooleanisAbstract : Booleanspecification : String

OperationAttribute

initialValue : Expression

BehavioralFeature

isQuery : Boolean

StructuralFeature

multiplicity : Multiplicitychangeablity : ChangeableKindtargetScope : ScopeKindordering : OrderingKind

Method

+constrainedElement

body : ProcedureExpression

*

+Specification

1

1

1

+namespace

0 .. 1Feature

ownerScope : ScopeKindvisibility : VisibilityKind

ElementOwnership

visibility : VisibilityKindisSpecification : Boolean

Figure 1.2: Core Package - Backbone (from UML 1.5)

Based on the above architecture, the abstract syntax is presented in a simplified UML class

diagram (i.e. only the most basic constructs of a “normal” UML class diagram will be used)

showing the metaclasses defining the constructs and their relationships.

Here we show two examples of those UML metamodels in the notation of UML class di-

agram. The first figure shows the model elements that form the structural backbone of the

metamodel. The second figure shows the model elements that define parts of relationships.

The diagram also presents some of the well-formedness rules, which are mainly the multi-

plicity requirements of the relationships, and whether or not the instances of a particular sub-

construct must be ordered.


1111

11

11

name : Name

ModelElement+source

*

*

Relatitionship

Generalization

discriminator : Name

Flow

+sourceFlow+targetFlow

* *

+target

isNavigable : Booleanordering : OrderingKindaggregation : AggregationKindtargetScope : ScopeKindmultiplicity : Multiplicitychangeability : ChangeableKindvisibility : VisibilityKind

{ordered}

2 .. * Association

isRoot : BooleanisLeaf : BooleanisAbstract : Boolean

GeneralizableElement*

*

+generalization

+specialization

+child

+parent

+association

*+specifiedEnd

* *

+specification

Classifier

isActive : BooleanClass Attribute

initialValue : Expression

{ordered}*

+qualifier

+associationEnd

+connection

+participant

+powerRange *

0 .. 1+powertype

AssociationClass

AssociationEnd

0 .. 1

Figure 1.3: Core Package Relationships (from UML 1.5)

An example here is: an Association has at least two ordered AssociationEnds.

Finally, a short informal description in natural language describing each construct is sup-

plied. The description gives a syntactical and semantic explanation of constructs in a mixed

way.

For example, in the above Metamodel, connection is explained as follows.

An Association consists of at least two AssociationEnds, each of which represents a connec-

tion of the association to a Classifier.

1.4.3.2 Well-formedness Rules

The static semantics of UML meta-classes, except for multiplicity and ordering constraints,

are defined as a set of invariants of an instance of the meta-class. (Note that a meta-class is

not required to have any invariants.) These invariants have to be satisfied for the construct to

be meaningful. The rules thus specify constraints over attributes and associations defined in

the meta-model. Each invariant is defined by an OCL expression together with an informal

explanation of the expression.

Object Constraint Language (OCL) in UML is actually a variant of first order predicate

logic. Most of the constraints defined by OCL, in a sense, can also be thought of as some


context sensitive syntactical constraints.

Examples of Well-Formedness Rules which applied to the association are given as follows.

1. A constraint for Association: the AssociationEnds must have a unique name within the

Association

self .allConnections → forAll(r1 , r2 | r1 .name = r2 .name implies r1 = r2 )

2. A constraint for GeneralizableElement: Circular inheritance is not allowed

not self .allParents → includes(self )

1.4.3.3 Dynamic Semantics

The meanings of the constructs are defined using natural language. Again, this description in

natural language gives a syntactical and semantic explanation of constructs in a mixed way.

The example of the dynamic semantics for an Association is given as follows.

An association declares a connection (link) between instances of the associated

classifiers (e.g., classes). It consists of at least two association ends, each speci-

fying a connected classifier and a set of properties which must be fulfilled for the

relationship to be valid. (Note that this part is just the description of the abstract

syntax.)

...

In UML, Associations can be of three different kinds: 1) ordinary association, 2)

composite aggregate, and 3) shareable aggregate.

...

A shareable aggregation denotes weak ownership (i.e., the part may be included

in several aggregates) and its owner may also change over time. However, the se-

mantics of a shareable aggregation does not imply deletion of the parts when an

aggregate referencing it is deleted.

...

By the way, some concepts (such as inheritance), which are not necessary model elements

in the metamodel, will also be explained in this part. This, somehow, is only acceptable in an

informal language definition.

1.4.3.4 Strong Points and Shortcomings

Today the OMG-UML approach for defining UML is the most prominent representative of this

style of syntax definition, using an elaborate metamodeling technique with four layers of meta-

models. The idea of metamodeling is appealing, because (i) the syntax definition diagrams are


- at least in principle - easy to read for humans, and (ii) when constructing tools, the metamodel

can be directly used as a database schema for the repository of the tool and / or as a common

data exchange model.

However, syntax definition by metamodeling has considerable drawbacks in practice. Firstly,

for big languages such as UML, the metamodels become so large that understanding and nav-

igating through them becomes a difficult and tedious task for humans. UML makes the meta-

models more compact by extensively using inheritance. However, this makes the comprehen-

sion and navigation problem even worse. What is more, overusing of inheritance is also easy to

cause side effects.

Secondly, graphic metamodels are not powerful enough to express even the context-free

syntax of a graphic language completely. So the metamodel must be augmented by constraints

that must be expressed separately in a (typically textual) constraint language.

At last, OMG-UML approach mixes the syntax and semantics definition together. In order

to understand the syntax of UML, you must first understand some UML semantics. This makes

even the syntax definition (and the static semantics) alone very complex to understand, let alone

the (dynamic) semantics.

For example, it is very difficult to just find the syntactical definition and the syntactical

constraints (a.k.a. static semantics) of a UML construct: “generalization”. We need to first

look for the metamodels and search in all the class diagrams, which may contain the model

elements (e.g. Generalization, GeneralizableElement, Relationship, ModelElement, Classifer,

etc.) which in some way relate to the “generalization”. Then we should collect the diagrams,

the Well-Formedness rules, and the tedious syntactical and semantic description of those model

elements from the hundreds of pages of the document “UML Semantics”. The reason of col-

lecting the definition of relating model elements is: some properties of a model element are

not defined together with that model element, but together with other relating ones. For in-

stance, the property of “generalization”, circular inheritance is not allowed, is defined together

with GeneralizableElement. Only after the summarization of what we collect, can we have a

complete view of the syntactical definition of “generalization” and the constraints on it.

There are several reasons for the difficulty to understand the syntactical definition and con-

straints. Expect for the reasons, such as the mixed syntactical and semantic definition of UML

(e.g. using some UML semantics to define the UML syntax, etc.) and cross reference of the

model element in the textual rules and description, the semiformal (I.e. not formal) definition

of the language syntax and static semantics is certainly an important reason.

In principle, OMG-UML approach provides only a semi-formal language definition (both

on syntax and on semantics). We understand the difficulty of formally defining a wide spectrum

language, such as UML. However, for a language considered to be a standard in industry, we

should at least define the syntax and static semantics formally. This can be a basis for the formal


definition of the core semantics.

1.4.4 pUML

The precise UML (pUML) group aims to develop the Unified Modelling Language (UML) as a

precise (i.e. well defined) modelling language.

The basic strategies proposed by the pUML group are somewhat different from the OMG

meta-modeling technique mentioned in the last section. A meta-modelling facility, which com-

prises a language (MML) for defining modelling notations, a tool (MMT) which checks and

executes those definitions, and a method (MMM) are given.

More explanation and comments on the pUML approach are given as follows.

• MML is a metamodeling language, which in essence can also be seen as a subset of

UML. It is used to model the abstract syntax of UML, in a way similar to the OMG

approach. However, the organization of the modelling in the pUML approach is more

systematic [9]. An OCL-like constraint language is used to specify the context-sensitive

syntax (a.k.a. static semantics).

• The pUML group exploits the drawbacks of the metamodeling techniques: the gaps be-

tween the abstract syntax and the concrete syntax. A concrete UML syntax can only

be derived from the semantic interpretation of the meta-model (an abstract syntax of

UML). The pUML group asks “how can conformance to the definition be checked?”

in the OMG approach, and argues that “the mapping of concrete syntax to abstract syntax

(meta-model) needs a more systematic and unambiguous definition”. Therefore a set of

tools are developed to

– check, whether a given instance satisfies a (meta-)model;

– generate an instance, that satisfies a given (meta-)model.

• In the semantics definition, the early work of pUML advocates the following approach:

1. selecting the most basic elements of the UML;

2. giving a formal semantics to those basic elements in Z [19];

3. using those basic elements to set up a model of the whole language (actually giving

a semi-formal semantics to the whole language).

Most recently, they change their strategy with the following steps [9]:

1. precisely defining a metamodeling language (MML);

2. using this MML to define the abstract syntax;

3. together with an OCL-like constraint language to define the static semantics of

UML;


4. [42] tries to use MML not only to describe the static semantics but also the dynamic

semantics of UML. This work is ongoing.

In the first step, they claim that “precise” does not mean “formal”. In their approach

MML is defined by itself.

For the MMM, only some initial results are given.

Generally speaking, the approach of pUML is still in an experimental phase. The results

they achieve so far are better than what OMG does.

However, drawbacks of the metamodeling techniques are still not overcome. For instance,

the gap between the abstract syntax and the concrete syntax still exists in the metamodeling

approach. By the way, a tool being a (indispensable) part of the language definition is not a

good solution, as the correctness of the tool itself needs to be verified.

The diagrammatic reasoning [55], which is concerned with how humans or machines can

represent information using diagrams, and then reason (solve problems with, answer questions

from, etc.) using those diagrams, is far from maturity needed to be used in the field of language

definition. Therefore, the semantics defined by the meta-model does not bring much more than

that defined in nature language (I.e. the metamodel semantics does not provide a sound base for

formal verification and refinement.).

1.4.5 Abstract Graphs

Abstract graph is an approach that defines the syntax for visual specification languages. It

first transforms concrete diagrams written in a graphic modelling language into an abstract,

topology-preserving graph with typed nodes and edges. This graph is interpreted as a meta-

model of the language. Syntax information that cannot be expressed in this metamodel has to

be added using a logic-based constraint language.

The work in [20] is a typical example of this approach. Let us look at the metamodel of

OMT concepts of Class from their work:

In the above example, the concept of Class is modelled by a notation of Extended Entity

Relationship Diagram (EER). The static semantics (which is also called as context sensitive

constraints) is specified by GRAL, which is a Z-like assertion language.

Actually, [20][67] use this way to define all the constructs of OMT and Booch:

• EER is used to describe the abstract syntax.

• EER is not expressive enough to describe the context sensitive constraints (or even some

context free ones), a Z-like assertion language GRAL is employed to specify those con-

straints.

• What is more, the formal semantics for EER and GRAL are defined [18] and [22]. This

makes the whole approach relatively formal.


Figure 1.4: Modelling of the OMT concept of Class

Constraint : The class name space has to be unique in a systemOM2 : ∀c1, c2 : V class | c1 �= c2 • c1.name �= c2.name;

This is a quite attractive technique. Compared with the OMG metamodeling techniques, it

obviously has some advantages.

• Abstract graph uses EER to model the abstract syntax of OMT and Booch, and GRAL

to specify the context sensitive constraints (static semantics), while OMG metamodeling

technique uses a core UML to model the abstract syntax and OCL to specify the context

sensitive constraints. Both GRAL and OCL have a sound base. The difference is that

the intermediate language EER, which describes the syntax of OMT and Booch, has a

formal semantics [18]. On the contrary, the core UML does not have a formal semantics.

Therefore, the abstract graphs technique is quite attractive when the focus lies on getting

a sound syntactical basis for the construction of tools.

The limit of this approach is:

• Using an intermediate graphic language, such as EER, to semi-formally describe a graph-

ical modelling language may not be necessary. The transformation from the abstract syn-

tax to the concrete syntax of the target language is neither straightforward nor formally

defined. More important, the syntax definition is quite difficult and complex to read for

humans.

1.4.6 Semantics Definition for Simple Graphical Modelling Languages

For the programming language, [72] provides an excellent introduction on the formal semantics

(operational semantics, denotational semantics and axiomatic semantics) for the simple textual

programming languages.


There are a lot of mature methods of semantics definition for the simple graphical modelling

languages, such as State Automaton, Statechart, Petri Nets, Sequence Diagram, etc. They have

also proved to be useful and practical in safety critical applications in industry. For example,

[36] introduces the syntactical and semantic definition of Statechart.

There are also quite a lot of useful verification and refinement methods based on the defined

semantics. For example, [52][53] show verification methods on some transition systems, which

can be seen as variants of Statechart.

1.4.7 The Refinement Calculus

The most important early work on refinement calculus is proposed in [54]. The refinement

calculus is defined there as a notation and set of rules for deriving imperative programs from

their specification. In their approach, the derivations are carried out within a single language, in

which specifications and code are integrated.

In the following part, we give a short introduction to explain their approach.

1.4.7.1 Formal Definition of Refinement

Before we formally define the concept of “refinement”, we need to introduce some other con-

cepts.

The weakest pre-condition

Dijkstra introduces for program P and predicate R over the program variables, the weakest

pre-condition of R with respect to P . It is written as wp(P,R) .

The weakest pre-condition is intended to describe exactly those states from which execution

of P is guaranteed to establish R.

For example, the meaning of assignment in a programming language is defined as follows

for variable x, expression E, and post-condition R:

wp(”x := E”, R) = R[x \ E].

The notation [x \E] here denotes syntactic replacement in R of x by E in the usual way (avoid

variable capture etc.).

In [54] a program P is specified by giving both a pre-condition (not necessarily weakest)

and a post-condition; their pre-condition and post-condition predicates are abbreviated as pre

and post.

The weakest pre-condition

Symbol “�” is used to represent the relation of refinement. The formal definition is given as


follows.

Definition For programs P and Q, we say that P is refined by Q, written P � Q, iff for all

post-conditions post:

wp(P, post) ⇒ wp(Q, post)

The definition is explained informally by noting that any occurrence of P in a (proved

correct) program is justified by the truth of wp(P, post) at that point, for some predicate post.

No matter what post it is, the relation P � Q gives us wp(Q, post) as well, so that Q is similarly

justified: thus Q can replace P . Operationally, P � Q whenever Q resolves non-determinism

in P , or terminates when P might not.

This refinement relation is independent of the notion of specification, and can be evaluated

for any two constructs whose weakest pre-condition semantics are known. For example, we

have in a guarded command language

(a ≤ b → a := a − b) �� (b ≤ a → b := b − a)�

(a ≤ b → a := a − b) �� (b > a → b := b − a)

The first program is non-deterministic, executing either branch when a = b; the second

program is a proper (i.e., non-identical) refinement of it because this non-determinism has been

removed.

1.4.7.2 Laws of Refinement

The refinement calculus consists of a set of laws of refinement, which are in the form

before − refinementafter − refinement

side − condition

and by this we mean: ”if side-condition is universally valid, then

before − refinement � after − refinement”

Note that before − refinement denotes either specifications or executable constructs of a

part of the programm before refinement; and after − refinement denotes specifications or exe-

cutable constructs of a part of the program after refinement.

The refinement either strengthens a specification or introduces executable constructs into

the target programming language. Here we give 3 laws as examples. Note that �w partitions the

vector �v of program variables. What is more, occurrences of 0-subscripted variables �v0 in post

refer to the values held by those variables initially.


Law 1 Weakening the pre-condition; the new specification is more robust than the old (i.e., it

terminates more often)

�w : [pre, post ]

�w : [pre ′, post ]pre ⇒ pre ′

For example, n : [n > 0, n = n0 − 1] � n : [n ≥ 0, n = n0 − 1]

Law 2 Strengthening the post-condition; the new specification allows less choice than the old:

�w : [pre, post ]

�w : [pre, post ′]pre ⇒ (∀�w • post ′ ⇒ post)[ �v0\�v ]

For example, n : [true, n ≥ 0] � n : [true, n > 0]

...

Law 7 Introducing assignment:

�w : [post [ �v0 , �w\�v , �E ], post ]

�w := �E

For example, x : [true, x = x0 + y] � x := x + y.

...

Here we just give some examples to show the basic ideas of the refinement calculus. In

Chapter 5, we talk about how to define a refinement calculus for graphical modelling languages.

1.4.8 Other Language Definition Issues

The definition of visual specification languages is more complex than the definition of textual

programming/specification languages and visual programming languages.

As mentioned before, it also includes the definition of verification rules, secondary notation

and diagram layout, model management, model simulation, code generation methods, etc.

These parts of definition are not the focus of this dissertation and hence will not be discussed

in detail. However, they are still quite important and some of them will even be indispensable

parts in the future development of visual specification languages. As a dissertation should ex-

plain the topic of “language definition” in a systematic way, we still introduce some background

here.

More discussions on model management and verification rules can be seen in Chapter 4 and

Chapter 6


1.4.8.1 Secondary Notation and Diagram Layout

For programming languages and textual specification languages, some issues (e.g. issues re-

lating to tools) don’t need further consideration. However, for a visual specification language,

more issues need to be taken care of.

Secondary notation is one of these issues. The secondary notation conveys additional mean-

ing above and beyond the “official semantics” of the specification language or it disambiguates

syntactic structure in order to assist in interpreting semantics [17]. Research on the secondary

notation was carried out in the Requirements Engineering Research Group at the University of

Zurich. The details can be seen in [1].

Defining diagram layout is also an important part of the language definition. For example,

in UML there are some general constraints:

• Classes, objects, states should not be overlapped. Otherwise, the diagrams will not be

understandable at all.

• The relationships are allowed to cross each other.

These constraints make sure that a UML model is presented in a meaningful and understandable

way. Except for the constraints, the position information of the model elements are very useful

for the tool development. Though the diagram layout has no influences on dynamical semantics,

a pretty layout of a syntactically correct and well-formed model is much more understandable

than an ugly one. Surely providing a pretty layout is a very complex and mathematically chal-

lenging problem. It has therefore spawned a whole field of research named “Graph Drawing”

[15].

1.4.8.2 Model Simulation and Code Generation Methods

Software models play a more and more important role in software development in recent years.

However, models can be more than just static pictures. They could also be made into dynamic

entities (e.g., simulators).

Besides the traditional methods (e.g., formal verification and refinement) executable models

and code generation provide a useful alternative of allowing developers to analyze dynamic

properties of a software system before implementation.

Although the method definition on model simulation and code generation so far does not

really belong to the language definition, it will soon be an indispensable part of it. There is

already some work on model simulation and code generation [50][66]. Nevertheless a lot of

problems in these fields still need to be studied further.


Remarks

In the last several sections, we introduce all the necessary background knowledge for under-

standing the rest of dissertation. Please note that

• the introduction does not serve as a detail survey in those fields. For instance, only several

dialects of graph grammar are introduced in Section 1.4.2. Nevertheless, we provide

plenty of references, which provide detailed introductions to those fields.

• the forms (or formats) of some methods given in this chapter may look very different from

our own methods, which will be introduced in the rest of the dissertation for the visual

specification language definition. However, the key principles of the original methods

and our extended ones are similar. We extend those methods to make them applicable

in visual specification languages. For example, although the original form of refinement

calculus introduced in Section 1.4.7 is different from that of our refinement calculus in

Chapter 5. The basic idea of the original refinement calculus guides us to set up our own

calculus. That is why those methods are still introduced in this chapter.

1.5 Syntax vs. Semantics

Generally speaking, we use the term syntax whenever we refer to the notation of the language.

The meaning of a language is described by its semantics.

However, the differences between the syntax and dynamic semantics are sometimes not

so clear. For example, the discussion, whether the context-sensitive constraints on the syntax

belong to semantics or syntax, has a long history in the research community.

For programming languages, [58][47] think that the syntax encompasses all the compile-

time aspects, while (dynamic) semantics encompasses the run-time aspects.

However, this kind of classification has a weak point: as code generation belongs to the work

of a compiler, it is a kind of syntactical work according to [58] [47]. In fact, it interprets (or it is

better to say, gives meanings of) a program in a language, which the computer “understands”.

Therefore, some researchers divide the compile-time aspects into two parts: the part, which

can be described by a context free grammar, is called syntax; the other part: the context-sensitive

constraints (including type information) and code generation are called static semantics.

For graphic modelling languages, this problem seems even more complex, as most graphic

modelling languages are not executable.

In [56], the UML OMG group gives the following definitions. Note that the phrase in

parenthesis is added by the author to eliminate the possible ambiguities.

The syntax defines (i) what constructs exist in the language (ii) how the constructs are built up

in terms of other constructs.

1.5. SYNTAX VS. SEMANTICS 35

The static semantics defines how an instance of a construct should be connected to other in-

stances (of the same construct or other constructs) to be meaningful. Note they are also

called “well-formedness rules”.

The dynamic semantics defines the meaning of a well-formed construct.

However, this definition seems unacceptable to all the researchers in our community.

Actually, it is not always easy to distinguish the differences among dynamic semantics,

static semantics and syntax in some situations. There are some overlaps among them.

For example, in some visual specification languages, some constructs are built up from other

constructs with some context-sensitive constraints. Those constraints, which are called well-

formedness rules in [56], specify the relationship among the instances of constructs, to make

the “sentences” meaningful in the languages. And hence they can be called static semantics,

which is what the UML OMG group does.

On the other hand, they can also be classified into the syntax definition part, as they describe

how the constructs are built up in terms of other constructs. From the view of a tool developer,

all those context-sensitive constraints should also belong to the syntax, as they state how the

constructs are connected to one another. They refer only to the notation of the language and all

of them can be checked automatically by a tool statically. [35] states that those well-formedness

rules are merely syntactical constraints, which should belong to the syntactical condition.

There is no final conclusion on this debate. The author thinks that all these classifications

are reasonable in some sense. However, any of the single classifications can not cover all the

situations for a complex language.

Usually, the differences between the syntax and dynamic semantics are clear. And some

parts of those context-sensitive constraints (or well-formedness rules) can be considered both

as Context-sensitive syntax and as static semantics. Using which name just depends on the

users’ view.

Except the part of code generation, the static semantics includes the same part as the context-

sensitive does in graphical modelling languages. By the way, in this dissertation, code genera-

tion will be talked about as a separated part. Therefore, in this dissertation, we will mainly use

the name static semantics.

Chapter 2

ADORA

When we talk about the definition methods for visual specification languages, we need some

concrete visual specification language as a vehicle to explain the basic ideas of our methods.

We will use the ADORA language [26] [27] [40] as a sample graphic modelling language in

the rest of this dissertation.

The main characteristics of the ADORA language are:

• Use of abstract objects (instead of classes)

• Integration of all aspects of the system in one coherent model

• Hierarchical decomposition

• Support for a flexible, incremental modelling process. In particular, it supports partial

and evolutionary specification and allows tailoring the formality of ADORA models to the

problem at hand.

2.1 General Introduction

In this section, we give a brief introduction to ADORA. ADORA is a modelling technique for re-

quirements and software architecture that is being developed in the Requirements Engineering

Research Group at the University of Zurich. The acronym stands for Analysis and Description

of Requirements and Architecture. Figures 2.1 and 2.2 (taken from the specification of a dis-

tributed heating control system) give an impression of what ADORA models look like. At first

glance, ADORA diagrams look similar to UML diagrams. However, there are fundamental dif-

ferences between ADORA and UML [27]. Below, we summarize the distinguishing features of

ADORA.

Using abstract objects (instead of classes) as the basis of the model. Class models are

inappropriate when more than one object of a class and/or structural nesting of objects has to be

modeled [27] [4]. Therefore, ADORA uses abstract, prototypical objects instead of classes as

the conceptual core of the language. For example, in sample heating control system (see Figure

37

38 CHAPTER 2. ADORA

HeatingControlSystem

MasterModule

BoilerOperator

object object set scenario stateabstract relationship

HeatingOn LocalControlDisabled

communicate

display

RoomTempSensor: external

RoomControl

RoomModule

RadiatorValve

setRoomTemp

LocalControlEnabled

User

setDefault

setRoom

Control

LocalControlOff

LocalControlOn

Controller

element of theenvironment

controlBoiler(1,1)

controlValve(1,3)

readTemp (1,1)

(1,n)

setLocal

Settings

note RoomControl useslocal control parametersif local control is enabledand on. Else, defaultvalues (set by Master-Module) are used.

ManageLocalRoomTemperature...

RoomTempControlPanel...

communicate setState

BoilerControlPanel...

BoilerControl...

OperateHeatingSystem...

HeatingOff

association relationship

interrelationship

Figure 2.1: An ADORA view of the heating system: base view + structural view + context view

2.1), there is a single Master Module, but multiple room modules. In ADORA, we model these

entities as abstract objects and thus can make these cardinalities immediately visible. Moreover,

the Boiler Control Panel in the Master Module and the Room Control Panel in the Room Module

may have the same type. Hence, they would not be distinguishable in a class model, while with

abstract objects, we can model them separately and place them where they belong.

Integration of all aspects of the system in one coherent model. An ADORA model integrates

all modelling aspects (structure, data, behavior, user interaction . . . ) in one coherent model.

This allows us to introduce strong rules for consistency and completeness of models, reduces

redundancy, and makes the model construction more systematic.

Using an integrated model does of course not mean that everything is drawn in one single

diagram. From the integrated model, we can generate views pertaining to a given aspect. The

so-called base view of an ADORA model consists of the hierarchical structure of objects only.

Aspect views are generated by combining the base view with all information that is relevant for

the selected aspect.

For example, Figure 2.1 shows the structure view (which shows the static structure of the

system by combining the base view with directed relationships between objects/object sets)

and the context view (which shows all actors and objects in the environment of the modelled

system and their relationship with the system) of the whole heating control system. Figure 2.21

1In this figure, the triggering events and triggered actions/events are expressed in tabular form to make themodel more readable. They can be translated into the equivalent traditional form as an adornment of the state

2.1. GENERAL INTRODUCTION 39

Init, Monitoring Modifying

Y

Y

IN LocalControlEnabled.LocalControlOn

ActualTemp > Settings.CurrentTemp(now)

ActualTemp < Settings.CurrentTemp(now)

ActualTemp > Settings.DefaultTemp(now)

ActualTemp < Settings.DefaultTemp(now)

IN LocalControlEnabled

send open over controlValve

send close over controlValve

180 s IN Modifying

MonitoringModifying

10 s IN Reading

self.ReadSensorValue

ReadingReading

Y

N

Y

•

•

N

•

•

N

Y

•Y

Y

N

Y

•

•

N

•

•

N

Y

•YState Transition Tables for Controller

RoomModule

(1,n)

HeatingOff

HeatingOnLocalControlDisabled



RoomControl LocalControlEnabled

ManageLocalRoomTemperature...

receive onover setRoom

"enable" "disable"

Modifying

Monitoring

InitControllerSettings

Reading

LocalControlOff

LocalControlOn

note RoomControl uses local controlparameters if local control is enabledand on. Else, default values (set byMasterModule) are used.

note setRoom and controlValve arerelationships (see Fig. 2) that act aschannels for receiving/sending events.

receive off oversetRoom / send shutover controlValve

Figure 2.2: A partial ADORA model of the heating system: base view + behavior view

shows the behavior view (which shows the dynamic behavior of the system by combining the

base view with a statechart-based state machine hierarchy) of the Room Module in our heating

control system. Figure 2.3 shows the details of the scenarios ManageLocalRoomTemperature

using the notation of scenarioschart, whose style is derived from Jackson Diagrams. This is a

part of the user view of the system.

transition arrows in the diagrams.

40 CHAPTER 2. ADORA

ManageLocalRoomTemperature

TurnLocalControlOn

SetTemperature

InspectTemperature

TurnLocalControlOf

ManageTemperature

UseLocalControl

LocalControl

Sequence

IterationConcurrency

1 2 3

*II II

# #

Alternative

o o

Component

Figure 2.3: A scenariochart modeling the structure of the ManageLocalRoomTemperature sce-nario.

Hierarchical decomposition. ADORA systematically uses hierarchical decomposition for

structuring models. With the use of abstract objects, abstraction and decomposition mechanisms

can easily be introduced into the language. We recursively decompose objects into objects (or

other elements, like states). So we have the full power of object modelling on all levels of the

hierarchy and only vary the degree of abstractness: objects on lower levels of the decomposition

model small parts of a system in detail, whereas objects on higher levels model large parts or

the whole system on an abstract level.

With the mechanism of hierarchical decomposition, through the view transitions and the

ADORA navigation mechanism of object hierarchies, the system can be showed at different de-

tailed levels: from the most abstract architecture (c.f. Figure 2.4) to a moderate level with the

details of the interesting objects but only the skeleton of the surrounding objects or the unfo-

cused modules (c.f. Figure 2.1), and until every detail of the system (which cannot be showed

here as the paper is not large enough). As view transitions and the navigation of hierarchy

are very important background for understanding our language definition methods, they will be

introduced in a more detailed level in Section 2.2.1.2.

With the continuous research in our group, ADORA evolves itself. The detailed constraints

on the integration of object diagram and statechart, the rules on hierarchical decomposition and

view transitions, and the extension of the ADORA language to support partial and evolutionary

specification, which don’t exist in previous ADORA papers, will be introduced in detail in this

chapter. Together with the introduction of early versions of ADORA in [26] [27] [40], the newly

extended language parts in Section 2.2.2, 2.2.3, 2.3.1 and 2.4 are the necessary background for

understanding our language definition methods.

2.2. VIEW TRANSITIONS AND NAVIGATION OF HIERARCHY 41

HeatingControlSystem

MasterModule

HeatingOn

communicate

display


RoomControl ...

RoomModule

setRoomTemp

LocalControlEnabled

setDefault

setRoom

Control

readTemp (1,1)

(1,n)

setLocal


BoilerControlPanel...

BoilerControl...

Figure 2.4: A partial ADORA model of a heating control system: base view and structural view(at a highly abstracted level only with the most fundamental objects and their relationships).

2.2 View Transitions and Navigation of Hierarchy

2.2.1 View Transitions in the Structural View

The structural view in ADORA shows the static structure of the system by combining the base

view with directed relationships between objects/object sets.

2.2.1.1 Motivation

An integrated model for a system can be very complex for users to understand. The concept

of aspect views, which shows only one aspect of the model in a view, is introduced to improve

the understandability. However, the view of one aspect of a model can still be too complex.

Therefore, the mechanism of hierarchical decomposition is applied to further ease the reading

of the model. In the structural view, we can hide objects or make them visible again, which

causes the view transitions, to show the different focuses of a view. In the following text, a

snapshot of a structural view during the view transitions will also be called a view, when no

ambiguities arise.

The syntactic correctness (or well-formedness, c.f. Section 1.5 : “Syntax vs. Semantics”)

of an ADORA diagram not only depends on the information given in the diagram, but also on

information which is present in the model, but not visible in the particular diagram. At first

glance, this may look strange. However, it is a quite important feature if we want to guarantee

consistency between diagrams as well as between the overall model and a diagram that shows

a particular view of the model.

Example. Suppose we have a quite simple model of a system S consisting of objects

P,Q,X, Y and an association r from P to Q (c.f. Figure 2.5a). Furthermore, let P be em-

42 CHAPTER 2. ADORA

bedded in X and Q in Y . Now assume that we want to draw an overview diagram which shows

only the overall system and its two main components, X and Y . If we drew this diagram in the

way shown in Figure 2.5b, we would suppress two important facts:

• X and Y have inner components

• X and Y may exchange information (due to the relationship between P and Q).

During navigating in the object hierarchy, we don’t have any route sign, which may guide

us to the original view. Therefore, in this situation, ADORA requires us to model hints that point

at suppressed information (Figure 2.5c):

• Trailing dots are added to the names of X and Y to indicate that these objects contain

other objects that are not shown on the diagram. We also call these trailing dots an is-

partial indicator.

• A so-called abstract relationship (thick line) is drawn between objects X and Y to indicate

that at least one relationship from an inner element of X to an inner element of Y is

suppressed.

S X ...

Y ...

S X

Y

b) an Undesirable

Abstraction

c) a Good

Abstraction

S X

Y

P

Q

r

a)

Figure 2.5: Syntax of ADORA diagrams that show partial models only. Diagrams a) and c)are syntactically correct representations of the example model given in the text; diagram a) issyntactically wrong.

Another syntactical element in the structure view is the so-called interrelationship. It is used

to indicate the hierarchy among the associations and abstract relationships. Interrelationships

are graphically represented by dashed hairlines between the associated relationships. We ex-

plain the concept of interrelationship using the following example. Let us assume a model con-

sisting of four objects: A, B, B1 and B2 (Figure 2.6). We also assume that A has relationships

x1 and x2 to B1 and B2 respectively. Fig 2.6 shows a view when B1 is hidden. Consequently,

the association x1 connecting Objects A and B1 is also hidden from the view and an abstract

relationship x is generated. The interrelationship between association x2 and abstract relation-

ship x indicates that x is not only an abstraction of the hidden association connecting A and B1

but also an abstraction of association x2 (see also [40]). In the large models, interrelationships

are useful to help users catch the hierarchy information of the relationships at a glance.


A

B

B1

B2

x2

x

Figure 2.6: x hints the suppressed information of the association x1 between Object B1 andA, and Object B1. The interrelationship between x2 and x shows the hierarchy among theassociations and abstract relationships.

After these two examples, we give definitions of abstracting and concretizing an object,

which will be used in later sections.

From a view Γ of an ADORA model, if users want to get a more abstract one, they can

manually hide an object from Γ. This action is called abstracting an object. As showed in the

above examples in Figure 2.5 and Figure 2.6, a sequence of steps, which make other associated

language elements visible or invisible in Γ, will be carried out to make sure the well-formedness

of the new view. This process is called view transitions of abstracting an object.

Similarly, if users want to get a more concrete view from a view Γ of an ADORA model, they

can also make the originally hidden object in Γ visible again. This action is called concretizing

an object. Again, a sequences of steps, which make other associated language elements visible

or invisible in Γ, will be carried out. This process is called view transitions of concretizing an

object.

2.2.1.2 Criteria of View Transitions in the Structural View

There are some criteria in the view transitions in the Structural view in ADORA.

• Except type hierarchy, we hope to avoid the so-called “pop-up windows” 2 (I.e. we want

to avoid explosive zooming, such that the further revealed information should not be

shown in separated windows.).

• During the navigation, the most important context should always be kept.

I.e. When we explore (focus on) the components of Object A, A should be visible. And

we should keep the “father”, “grandfather” 3, ... of A visible.

The first criterium is relatively easy to understand. We give more explanation on the second

one.

2In many visual languages, in order to get the detailed information or some related information of a languageelement in a window/frame, a new independent window/frame will be popped up to show that information, whichis separated from its original context.

3It is just a metaphor, if Object C is directly embedded in Object D, D is “father” of C (c.f. Section 3.4.1). IfObject C is embedded but not directly in Object D, D can be the “grandfather” or a “ancestor” of C. Note that ifC is not embedded in D, but they share the same “ancestor”, D can be a “uncle”, “nephew” or “cousin” of C.

44 CHAPTER 2. ADORA

In Figure 2.7 4, if we want to know more about Object A, we can make Object D visible.

In ADORA, for a model used in an industrial project with thousands of objects, we have limited

space both on screen and paper. Therefore, we may want to hide some components of Object

E.

A ... E

A ... E ...

B

D

A

B

D

C

E

A

B C

D

A

B

D

C

E

A

B

D

C

E

F G

Two Sub-Trees

F G

F

G

F G

Focus moves from one sub-treeto the other

X

X

X ...

X

X

X

Figure 2.7: Fisheye Algorithm and Hierarchical Decomposition

In this case, we lose the information of E. However, losing the information of “uncles”

or some other “collateral relatives” is not a big problem. However, we should always have

the information of “father”, “grandfather”, “great-grandfather”, etc. When the focus is on a

component of A, A and X are not allowed to be hidden. I.e. in the Figure 2.7, if D is visible,

Object B, A and X should also be visible in the view; and if Object C is visible, A and X

should also be visible in the view. It is not important whether E, Object F , and Object G are

visible. Therefore, we always have the most important context!

2.2.1.3 One more Example in View Transitions

Here we give a typical example of view transitions in the structural view in Figure 2.8. It

demonstrates how the visual representations of relationships and interrelationships change due

to the view transitions.

When object A is abstracted (i.e. hidden from the view), the following sequence of steps is

required in order to produce a consistent and well-formed view of the underlying model.

1. Object A1 must be removed from the view because it is embedded in A.

2. Relationship r must be removed from the view because A1 is removed.

4Note that the Trees in the right part of Figure 2.7 (also the right parts of Figure 2.17 and Figure 2.18) are notparts of the model. They are used as a parable to illustrate the basic idea of the view transitions. Readers can justskip them.


C

B

s

ar

z

γ

δD ...

E ... F

A

C

B

s

r

z

αβD

A1

E ... F

a)

b)

Figure 2.8: a typical sequence of view transitions after an object is abstracted.

3. An abstract relationship ar, connecting D and B, has to be generated. It represents the

information that some object within D has a relationship to B.

4. Due to the generation of ar, interrelationships γ from s to ar and δ from ar to z must

also be generated in order to visualize relationship hierarchy.

5. The interrelationship α and β must be deleted. The reason for deleting α is obvious. β is

deleted because in the new view, β would be a transitive interrelationship whereas only

direct interrelationships are graphically represented.

This example gives users a rough idea about these transitions. In Appendix C.5, all possible

combinations of view transitions in the structural view (“abstract an object”) will be enumerated

and showed in figures.

2.2.2 View Transitions in the Behavioral View

The behavioral view in ADORA shows behaviors of the system by combining the base view with

a statechart-like state machine hierarchy. In essence, the behavior view can be seen as a special

statechart, in which a state can also be replaced by an object. We call it Generic Statechart

(also as Object-State-Chart) here. As explained in [24], a (generic) statechart without inter-

level transitions has much more advantages than the one with inter-level transitions. What is

more, the latter can always be translated into the former with the equivalent semantics (c.f.

Figure 2.9).

View transition in a generic statechart without inter-level transitions is not new. Actually, in

the early work on statechart, this concept has already been proposed.

In a structural view, introducing the concept of abstract relationship is meaningful, as it

46 CHAPTER 2. ADORA

A

D

B C

E

F

G

a

b

p/s

r/qy

z

A'

D'

B C

s

s' E

F

Gp/s

r/qy/t

z/t

a/s

S T

b/s't

( a )

( b )

Figure 2.9: (a) a (Generic) statechart with inter-level transitions. (b) The equivalent (generic)statechart without inter-level transitions.

helps the system architecture to be shown in a decomposable way. However, no corresponding

abstract transition will be introduced in a behavioral view, as it does not make the modelling of

system behavior more clear, but more complex. Instead, we advocate using the statecharts with-

out inter-level transitions. Only the statecharts without inter-level transitions are decomposable

(c.f. Figure 2.9b and Figure 2.10).

A'

D' ...

B C

a/s b/s't

Figure 2.10: An abtract generic statechart

Because we don’t have the constructs like abstract relationship and interrelationship, the

way of view transitions in the behavioral view is much rougher than that in the structural view:

we can not hide a specific state individually, but only a sub-statechart inside a state.

2.2.3 View Transitions in the User View

The user view combines the base view with the actors in the system environment, which the sce-

narios interact with, and all those abstract relationships, which model interactions between sce-

narios and objects. Scenariochart, which can be seen as an extension of Jackson Diagram[38],

is the major notation in the user view.

A scenario can be so complex that it should be divided into several relatively easier sub-

scenarios. That is to say, a super-scenario is defined by several sub-scenarios. The sub-scenarios


have different relations with the super-scenarios and among themselves. Therefore, scenari-

ochart (c.f. Figure 2.3) provides different notations to express those different relations.

• Component: in this relation, sub-scenarios are the components of its super-scenario.

Among the sub-scenarios, the temporal order of execution of those sub-scenarios is un-

specified.

• Sequence: in this relation, sub-scenarios are also the components of its super-scenario.

However, among the subscenarios, there is a temporal order of execution: according to

their scenario number, the sub-scenarios will be executed sequentially (from the smallest

number to the largest one). This is somehow similar to the sequence relation in Jackson

Diagram. Nevertheless, in Jackson Diagram, the sub-actions are executed sequentially in

the order of “from left to right” 5.

• Alternative: in this relation, only one sub-scenario will be selected to be executed. This

is the same as the alternative relation in Jackson Diagram.

• Concurrency: in this relation, all sub-scenarios will be executed concurrently. This is an

extension of Jackson Diagram, which is proposed in [25].

Note that there is no synchronization mechanism among the concurrency scenarios of the

same super scenario.

• Iteration: in this relation, sub-scenario will be executed iteratively. This is the same as

the iteration relation in Jackson Diagram.

In this section, we explain view transitions in the scenariochart using the example in Figure

2.11.

Similar to an object diagram, a scenariochart can also be composed and decomposed in the way

shown in Figure 2.11. However, rules on the view transitions are not as easy as we may imagine.

As a scenariochart does not stand alone in the user view, it needs to be integrated into the object

hierarchy of an ADORA model. This makes view transitions more complex. In Section 2.3.2, we

show how the scenario-charts are embedded in the object hierarchy of ADORA. More examples

on view transitions in the user view will be given in Section 3.4.5, where we formally introduce

the operational rules.

2.2.4 Remarks

An ADORA model, which integrates all the modules and all the aspects into one model, is

difficult to read and understand without suitable mechanisms of view transitions and hierarchy

navigation. Along with view separation and hierarchical decomposition, view transitions and hi-

erarchy navigation are also important mechanisms to help readers understand the ADORA model

5According to the langauge design principle of ADORA, language constructs should be context-free. Therefore,we add scenario numbers to sub-scenarios with sequence relation and use a black dot to denote super-scenarios inthe scenariochart.

48 CHAPTER 2. ADORA

ManageLocal

TurnLocalControlOn

Set Inspect

TurnLocalControlOff

ManageTemperature

UseLocalControl

LocalControl

12 3

ManageLocal

RoomTemperature ...

RoomTemperature

Temperature Temperature

ManageLocal

LocalControl

RoomTemperature

*...

ManageLocal

TurnLocalControlOn

TurnLocalControlOf

UseLocalControl

LocalControl

1 2 3

RoomTemperature

*

*

*

...

ManageLocal

TurnLocalControlOn ControlOff

ManageTemperature

UseLocalControl

LocalControl

12 3

RoomTemperature

*

* ...

TurnLocal

Figure 2.11: View Transitions in a scenariochart.

[40].

During the view transitions, we may ask the following questions: which elements should be

hidden, and which elements should be visible. Are there detailed and formal definitions on that?

In Chapter 3, we will define a set of operational rules to exactly specify the view transitions.

2.3 Integration of Aspect Views

2.3.1 Integration of Statechart and Object Hierarchies

In order to express the dynamical system behavior, in nearly every wide spectrum specification

language, we need a combination of an object model with a model of behavior and interaction.

In UML, this is done by adding sequence diagrams, collaboration diagrams and state machines

to the class diagrams. In ADORA , we integrate the behavior model into the object model.

In essence, the behavior view of ADORA can be seen as a combination of an object diagram

and a statechart. Like the normal statecharts, the hierarchical mechanism is also introduced in

the behavior view as a special statechart, in which a state can also be replaced by an object. It

is called Generic Statechart in ADORA.

Surely a statechart, an object diagram, and the hierarchical mechanism are not simply put

together in the generic statechart. The rationale of the integration is carefully and thoroughly

studied. The necessary model elements and mechanisms of the statechart and the object diagram

are employed in the ADORA language to meet the practical needs, and at the same time, they

are also correspondingly modified to avoid the possible syntactical and semantic conflicts of

2.3. INTEGRATION OF ASPECT VIEWS 49

the integration. In order to make this integration meaningful and fit with the language design

rationale, there are a set of constraints (a.k.a. static semantics) on the integration. The general

constraints in the behavior views of ADORA are: a transition may cross state boundaries (as

is usually allowed in the normal statechart), but can not cross object boundaries except the

boundary of the source /destination object.

A transition may connect a state or an object, and there are six situations in total. The

concrete constraints of those situations are given.

1. A transition leads from a pure state 6 to an object (which has an internal state).

In this case, the constraints are: the source state is embedded in another pure state S,

where

(a) S is at the same hierarchical level 7 as the destination object, or

(b) S is directly embedded in the destination object.

Transitions t2 and t3 in Figure 3.7 illustrate the two situations. The restriction that S must

be at the same hierarchical level as the destination object forbids the transition across the

object boundaries. The alternative restriction that S must be embedded directly in the

destination object allows the transition to cross the boundary of the destination object.

2. A transition leads from an object to a pure state.

In this case, the constraints are: the destination state is embedded in another pure state S,

where

(a) S is at the same hierarchical level as the destination object, or

(b) S is directly embedded in the source object.

Transitions t2 and t3 in Figure 2.12 illustrate the two situations. The restriction that S

must be at the same hierarchical level as the source object forbids the transition across

the object boundaries. An alternative restriction that S must be embedded directly in the

source object allows the transition to cross the boundary of the source object.

3. A transition leads from an object to an object.

In this case, the constraints are: either one object is directly embedded in the other object,

or they are at the same hierarchical level.

Figure 2.13 shows examples of the constraints here.

4. A transition leads from a pure state to a pure state.

In this case, the constraints are: there exist two states, S1 and S2, in the model, such that

6In the generic statechart, a pure state is a normal state, of which another pure state can be a component, butnot an abstract object. The formal definition will be given in Chapter 3.

7When two model elements are both directly embedded in a third one, these two model elements are at thesame hierarchical level. The formal definition will be given in Chapter 3.

50 CHAPTER 2. ADORA

X

C

t 1

t 2

A

S

T

U

t 3

t 4

Figure 2.12: Transitions t1, t2, and t3 are legal; t4 is illegal.

F

C

t 1

t 2 A

E

B

D

t 3

t 4

t5

t6

Figure 2.13: Transitions t2, t5 and t6 are legal; t1, t3 and t4 are illegal.

the source and destination states are embedded in these two states respectively, and these

two states, S1 and S2, are at the same hierarchical level.

Figure 2.14 shows an example of the constraints here.

A

S1

S3

S2

S4t1

Figure 2.14: Tansitions t1 is legal. Note that S3 is embedded in S1 and S4 is embedded in S2,while S1 and S2 are at the same hierarchical level.

5. A transition leads from a generic start state to a pure state or to an object.

A generic start state can be a start state, a start object, or a start object set. It is also

called “generic initial state”, which is composed of three parts: (i) a black dot, (ii) a

(pseudo)transition without a name and (iii) a (pseudo) pure state, a (pseudo) object, or a

(pseudo) object set. (c.f. Figure 2.15).

In this case, the constraints are the same as the constraints for a transition leads from a

pure state or an object to a pure state or an object respectively.

Figure 2.16 shows examples of undesirable layout of start state. There is a constraint in

the diagram layout of start state: the three parts of the language element should be in

the same hierarchical level. In particular, the transition connecting the black dot and the

state or object should not cross any state and object boundaries. As mentioned in Section


a) Start State

S

c) Start Object set

O

b) Start Object

O

Figure 2.15: Start States

AS1

S

Figure 2.16: Undesirable Layout of Start States

1.4.8, like any other layout constraints (e.g. objects should not be overlapped, etc.), this

constraint does not belong to the syntax definition of ADORA and will not be discussed

in detail in this dissertation.

As the constraints here specify how different notations are integrated in one wide spectrum

language without potential syntactical and semantic conflicts, part of them can actually be con-

sidered as integration semantics.

More Explanations

From the point of view of software engineering, the reason for introducing the above constraints

is to ensure the following two principles:

Information hiding. Each statechart describes a part of or the complete behaviors of an object.

And the transition of that statechart usually connects only states or objects in that object.

For pure states and objects in an object, transitions among them will be interpreted as the

changing of attributes in the later detailed design phase. Therefore, a transition across

the object boundaries (except the boundary of the source/destination object), which links

object or state outsides, implies that the attributes of an object are open to be accessed to

other objects. The above constraints make sure that the principle of information hiding

holds in our language.

Hierarchical structure. No transition across the object boundaries (except the boundary of

the source/destination object) makes the hiding of an object in the view transitions easier:

transition information will not be lost.

Readers, who are interested in the design principle on statechart and its integration into the

object hierarchies, can read [24].

52 CHAPTER 2. ADORA

2.3.2 Integration of Scenariochart and Object Hierarchies

In ADORA, all the aspect views are integrated in a single model. As mentioned in the last

section, the statecharts that represent the system behavior are integrated into the hierarchical

object model. Similarly, scenariocharts should not stand alone either.

But careful consideration is needed to achieve this integration. In the user view of ADORA,

there are also some similar criteria for the view transitions, as those described in Section 2.2.1.2.

• Scenarios should be included in a suitable object;

• During navigation, the most important context should always be kept;

• We want to avoid explosive zooming, i.e. showing scenariocharts in separate windows.

Embedding the scenarios of a scenariochart arbitrarily in objects leads to situations where

the object hierarchy and the scenario hierarchy are incompatible, which would require com-

plicated referential semantics and undesired effects when navigating the model. Figure 2.17

illustrates such an undesired situation.

A'...

AA'...

A

B

D

C

A'

Two Trees !

B'

D

B ...

A

B'...

B

C *

D1

ref {D, B', A'}ordered E2

ref ...

B'...E

C'

A

B

D

C

A'

B'

DE

C'

A

B

D

C

A'

B'

DE

C'

AA'...

B

C *

D1

ref ...E

2ref ...

B'

D

A'...

B'...

D

A

B

D

C

A'

B'

DE C'

Click Scenario Bto see the details.

Jum

pJum

p

E

E

E

E Click " ref {D, B', A'}ordered " in Scenario Dto see the details.

Figure 2.17: Improper referential semantics

Suppose that our focus is now on Object A. If we want to know the details of Scenario B,

we click on Scenario B. We know more details on Object A and Scenario B. Until this step,

we have a reasonable view transition. As Scenario D is embedded in another Object A′ (resp.

Object B′) and we do not want to lose the focus of A, we only show a “reference” with the

pretrace 8 of D.

8A pretrace of an object A is an ordered set of model elements that A is embedded in. The formal definition of


Now we want to know some further details of D , we click on the reference of D. Then

we also see more details of Object A′. Now we may have a problem: if we want to save some

space, A can be made invisible. In this case we may lose the information from “father” and

“grandfather” of Scenario D and jump to another “tree”. Actually, at first we want to see more

details of A. During this improper navigation, we may lose the information of A (i.e. we may

lose some important context!). This kind of integration is clearly unacceptable.

Modularity. Good modularity brings a lot of advantages in software development. It guarantees

also the principle of Information Hiding. Therefore, we design our scenario integration in a way

such that it obeys the principles of modularity and information hiding.

Therefore, we take the following language design decision: suppose that Scenario S is

embedded in Object O. Any sub-scenario S′ of S (S ′ describes part of the scenario S) should,

and must, be embedded in Object O or a component of O. Figure 2.18 shows an improved

notation of the integration of scenariochart into the object hierarchy.

A ... B

C ...*

A B

C *

B'

D

A

B

C

B'

D C'

Click Scenario C

to see the details.

A

B

C

B'

D C'

1

no focus jump !no focus jump !

Now, we want to know

the details of Scenario B.

B ...

A ... A

B

C

B'

D C'

E

E

E

One Graph

E2

C'

Figure 2.18: A graph with a proper referential semantics

Suppose that our initial focus is again on Object A. If we want to know more details of the

structure of scenario B, we click on Scenarios B and C one after another. Visualizing more

details of the scenariochart goes hand in hand with visualizing more details of the object A

where the scenariochart is embedded in. Moreover when navigating towards detail, we will

never lose the focus of A. It seems that “graphs” of the model structure are inevitable, because

scenarios are distributed among objects. However, as mentioned before, during the navigation

pretrace is given in Section 3.4.1.

54 CHAPTER 2. ADORA

of an ADORA model in the hierarchy of objects, states and scenarios, the most important context

and information should always be kept in sight. And during the integration, the hierarchy of

scenariochart shares the same styles as that in the hierarchical decomposition of the object

diagram and the generic statechart.

2.4 Partial and Evolutionary Specification

The notion of partial and evolutionary specification has gained attention both in research and

industry in the last few years. Software is more and more being developed in an evolutionary,

incremental manner. The distinction between development of new systems and evolution of

existing ones begins to disappear [44]. While many people regard this just as a process issue,

we are convinced that it is as well a language problem: without proper language support, the

process will not work.

In our research, we focus mainly on the language level and study how partial and evolu-

tionary specification can be expressed in the ADORA language and where the language has to

be modified or extended for this purpose. As a consequence, we syntactically and semantically

extend language elements of ADORA such that partial and evolutionary specifications can be

written in a controlled and systematic way.

For clarity, in the following text, sometimes we also call the extended language ADORA+ to

distinguish it from the original language.

2.4.1 Motivation

As mentioned in [44], “change” is a constant in software development. The change of require-

ments requires that the software system be developed in an evolutionary way. There are two

types of changes: one are planed changes, the other are unexpected, unforeseen ones.

For unforeseeable changes in software requirements, only a sophisticated process can help

to keep software developments still in a high quality. Nothing can be done at the language level.

However, some changes are predictable. For example, because of the limited resources

(lack of manpower, time, etc.), some system requirements cannot be implemented in the first

version. Some system functions need to be further augmented in the next version. Therefore,

we know those changes of the requirements before the system development. And the evolution

of the software development can be carried out in a planed way. In this case, some extensions

on a language level to support the incremental software development processes are useful and

necessary.

Consider the situation in Figure 2.19. Diagram a) and b) show two views of the same

specifications: a) shows a complete model in full detail; b) is an abstract view of the same

model which hides some details.

2.4. PARTIAL AND EVOLUTIONARY SPECIFICATION 55

a) View of a complete specification in full detail

Z

X

A

C

Y

B

t

s

A'

Z

X ...Y

B

b) The same specification as in a), but in a more abstract view

Z

X ...Y

B

c) A partial specification: details of X are not yet known

u

u

Figure 2.19: Complete Specification vs. Incomplete Specification

Now suppose a situation where we are incrementally developing this model and where we

have Z, X , Y , and B, but do not yet know the details of X . Obviously, drawing a model like Fig

2.19c) would be an adequate representation of this situation. In this case, the abstract relation-

ship from X to B is deliberately drawn to model the fact that there will be some relationship

from objects within X to B (In contrast to that, in Figure 2.19b, the abstract relationship is

generated as a representation of the hidden relationships t and s.).

This example demonstrates that we can model the structural view of a partial specification by

overloading the meaning of the is-partial indicator (the three dots) and the concept of abstract

relationship.

In the case of complete models, they indicate existing information which is hidden from the

current view.

In the new case of partial/incomplete models, they can either stand for hidden information

as before or for information when details have not yet been modelled.

The above introduced extension supports partial specifications. This in turn is required

for supporting the planed evolution of a requirements specification in an incremental software

development project.

In the following text, we introduce our extension on the structural view, behavioral view and

user view in detail.

56 CHAPTER 2. ADORA

2.4.2 Extension of the ADORA Language

2.4.2.1 The Is-partial Indicator

As sketched in the example above, we semantically extend the is-partial indicator. An is-

partial indicator is a three-dot symbol which is appended after the name of a component (e.g.

an object in the structural view, a state in the behavioral view, a scenario in the user view, etc.).

A component C with an is-partial indictor means:

• some components of C are hidden from the view (the original semantics); and/or

• the specification of C is not yet complete and will be refined by adding more components

in the further development (the extended semantics, which supports the mechanism of

partial and evolutionary specifications in ADORA).

Note that the first situation usually takes place during the view transitions. In the second

situation, we need to manually add or delete is-partial indicators.

2.4.2.2 The Structural View

In the structural view, except for the semantic extension of the is-partial indicator, we also

extend the semantics of abstract relationship. The abstract relationship construct is extended

similarly. An abstract relationship ar, which connects object A and object B originally means:

• during the view transition, an association, which connects

– a component of A and a component of B; or

– a component of A and B; or

– A and a component of B,

is hidden.

Now it includes a new meaning:

• an association, the details of which are still unclear, will be set up between

– a component of A and a component of B; or

– a component of A and B; or

– A and a component of B in the future refinement.

2.4.2.3 The Behavioral View

The generic statechart in Figure 2.9b is compositional, i.e. it can be viewed as a composition of

three black box components B, C, and D′ (c.f. Figure 2.10).

Except for the semantic extension of the is-partial indicator in the behavioral view, we do

not define any other extensions.

Please note that the extension of the is-partial indicator can only be applied for the generic

statecharts without inter-level transitions. I.e. only in the generic statecharts without inter-level

transitions, the is-partial indicator in a state means (i) either during the view transitions, the

2.4. PARTIAL AND EVOLUTIONARY SPECIFICATION 57

details in State D′ are temporarily hidden in the view (c.f. Figure 2.10); (ii) or some states and

their transitions may be added into this state in a further refinement.

2.4.2.4 The User View

Again we do not extend any other parts of the user view, except for extending the semantics of

the is-partial indicator, through which evolutionary information of scenarios can be recorded.

For example, an incomplete scenario S implies that special attention needs to be paid to the

design of scenarios around S, and the objects containing or connected to S.

2.4.3 Discussion

In the example in Figure 2.19, the diagram of b) and c) are syntactically identical, but indicate

different meanings. This is because the is-partial indicator and the abstract relationship in

ADORA+ have not only the original meanings, but also the extended ones. Alternatively, we

could introduce new notations to express the extended meanings of these two constructs. For

example, we could use two different colors or different symbols.

However, in a large model with the size of a real industrial project, the more different no-

tations used in a model, the more difficult it is for users to understand the model. Actually, the

original meanings and the extend ones are closely related. And in most cases, the original and

extended meanings are not needed to be distinguished. Therefore, we decide to use the same

notations.

What is more, the way of introducing the extension fits the general “top-down” approach

of software development and system refinement. As ADORA+ is compositional, the objects,

which specify the general structure of (sub-)systems, can be first defined and be viewed as a

composition of several black box components. Then they will be filled in with the relationships

and objects describing more details. Again those newly defined relationships and objects need

to be refined to the full detail level. During this process, with the help of a refinement calculus,

we can trace evolutionary changes. I.e. every evolutionary change should be carried out in a

controlled way and the well-formedness of the model should be always kept. We can also record

the impact of the refinement by using the is-partial indicator and the abstract relationship to

specify evolutionary information, when an object or a relationship is unclear at the current

phase.

There is another advantage of our extension. If we take high level design decisions based

on partial specifications (which is usually the case in incremental software development pro-

cesses), the explicit model of partiality provides the designers with information about what to

encapsulate in modules and where to design interfaces with special care.

For example, in the situation of Fig 2.19c, the requirements represented by object X should

58 CHAPTER 2. ADORA

be realized in a single, encapsulated module or component with a carefully designed interface

to the module(s) that realize(s) B. Theoretically every object in a software system should

have good interfaces and reusability. Practically, because of the limited resources (time, human

power, etc.), some good properties have to be sacrificed to some extent, if no big problems arise.

If making every object and module with good interfaces and good reusability is impossible, the

introduced mechanism reminds system developers at least to keep best quality of those objects

or modules, which are now incomplete and will be further refined.

2.5 A Comparison between ADORA and UML

UML uses a set of different models (sublanguages) to describe different aspects of a system,

while ADORA uses an integrated model to describe the whole system. Different aspects of the

model are expressed in the views of ADORA.

The user view in ADORA describes the system from users’ point of view. The notations of

the user view, compared with those of use case diagram in UML, are more sophisticated, as

they need to be integrated into the structural hierarchy of the integrated model. Both the user

view and use case diagrams have the similar basic concepts and describe the same aspects of

the system.

However, the UML use case diagram is not decomposable and has much weaker semantics

than the ADORA user view.

In ADORA, the structure view, which is similar to the class and object diagrams in UML

but uses abstract objects instead of classes and concrete objects, is used to specify the static

structure of the system. The advantages of our structure views over class and object diagrams

in UML are threefold:

• The structure view can model all the concepts, which class and object diagrams do. More-

over, by using abstract objects, the internal relationships among objects of the same class

can be clearly modelled. Hence abstract object models are more expressive than class and

object diagrams.

• Using the concept of abstract objects, the mechanism of hierarchical decomposition can

be naturally introduced in the ADORA model.

• In the dynamic model, we have to use abstract objects, instead of classes. Using abstract

objects in ADORA, instead of classes, the dynamic models and the static model(s) of a

system are possible to be integrated together.

In the behavior view in ADORA, it is similar to the combination of statechart and collabora-

tion diagram in the UML.

The behavior view in ADORA is also called generic statechart, as it has a very similar

semantics as that of the traditional statechart. However, in the generic statechart, a transition

2.5. A COMPARISON BETWEEN ADORA AND UML 59

can connect not only states but also abstract objects. What is more, just because a transition

can also connect abstract objects, it has a richer semantics than that of the transitions in the

traditional statechart. It behaves somewhat like the Message (Stimulus) in the collaboration

diagrams in UML.

The context view shows all actors and objects in the environment of the modelled system

and their relationships with the system. This view is like the context diagram of UML 2.0 (the

newest version), but from the perspective of requirements analysis.

As mentioned in [27], the most fundamental difference between ADORA and UML is the

concept of an integrated, hierarchically decomposable model in ADORA vs. a flat, mostly non-

decomposable collection of models in UML. For example, hierarchical structural and behavioral

models (c.f. Figure 2.1 and 2.2) could not be drawn with UML packages notation, as UML

packages are mere containers and only dependency links are allowed between packages. They

could not be expressed in class/object diagrams and dynamical diagrams of UML either, as none

of them supports the hierarchical decomposition mechanism.

In this dissertation, we choose the ADORA language as a vehicle for demonstrating our new

method of language definition for visual specification languages. The reasons are that the hier-

archical decomposition mechanism and the elaborate model integrity concept in ADORA make

the syntax and semantics definition of ADORA more challenging than the definition of any other

visual specification language. So if our method works for ADORA, it should also work for other,

less demanding visual specification languages, including UML.

60 CHAPTER 2. ADORA

Part II

Language Definition Method

61

Chapter 3

Definition of Syntax and Static Semantics

In our opinion, the syntax and static semantics for visual specification languages should be

formally defined. The reasons are given as follows.

1. For a wide spectrum visual or textual specification language, syntax and static semantics

may be very rich. However, in essence, they are far less complex than a dynamic semantic.

A formal syntax and static semantics are describable, understandable and applicable.

2. A language without a tool support will not be widely used in industry. The development

of a tool, which checks the syntax and static semantics of a language, requires that the

syntax and static semantics should be defined first. The formal definition of the syntax

and static semantic for that language is actually the specification of the tool.

While the formal method used for a normal application may be too expensive, for the

development of a language, which will be used for development of thousands of applica-

tions, a formal syntactical definition of that language is deserved anyway.

3. A formal syntax and static semantics are the basis of a formal dynamic semantics. They

are also indispensable, when we define a refinement calculus and verification rules.

As mentioned in the introduction, ADORA will be used as a vehicle for demonstrating our

methods of syntax and static semantics definition. As UML is the most popular visual speci-

fication language, we will also shortly show how our method can be applied to the syntax and

static semantics definition of UML in a later chapter.

3.1 Motivation

For the wide spectrum graphical modelling language, the current methods of syntax and static

semantics definition are far from satisfactory. For example, syntax definition by metamodel-

ing of OMG has considerable drawbacks. One of the drawbacks is that for wide spectrum

languages, the metamodels become so large that understanding and navigating through them

becomes a difficult and tedious task for humans. Overuses of inheritance in the OMG meta-

63

64 CHAPTER 3. DEFINITION OF SYNTAX AND STATIC SEMANTICS

models make the comprehension and navigation problem even worse. As introduced in Chapter

1, other approaches, e.g. graph grammar, are also not a good fit for definition of graphical

modelling languages.

The hierarchical decomposition mechanism, the elaborate model integrity concept and the

notion of partial and evolutionary specification in ADORA make the syntax and static semantics

definition of ADORA much more challenging than definitions of other graphic languages, such

as UML. In this chapter, we introduce a method for defining the syntax and static semantics of a

graphic modelling language, which shall satisfy these goals: (i) formal and without ambiguities

and conflicts, (ii) easy for humans to understand and master the language, and (iii) helpful for

tool developers to construct tools that support the language.

3.2 Basic Concepts

In this section, we introduce the four basic concepts of our syntax and static semantics definition

method.

Graphics to text mapping. Let GML be a given graphic modelling language the syntax of

which we want to define. We first define a textual modelling language TML such that there

exists an isomorphic (i.e. one-to-one) mapping from every language element of GML to a cor-

responding language element of TML. The mapping is defined in tabular form (cf. Figure 3.2).

As graphic modelling languages for requirements and architecture contain quite few elements

where the graphic layout is syntactically relevant, we can successfully construct such a textual

language and mapping. Having defined TML and an isomorphic GML-TML mapping, every

formal definition of the syntax for TML also defines the syntax of our original language GML.

Context-free syntax. We use EBNF (extended Backus-Naur form) for the definition of the

context-free syntax of the textual language TML. (E)BNF is a proven syntax definition tech-

nique which is easy to understand for humans and where we have mature and efficient tech-

niques for constructing parsers.

Static semantics: static context-sensitive constraints (a.k.a. Static context-sensitive syntax,

c.f. Section 1.5). The static semantics of graphic modelling languages is usually context-

sensitive. For example, the rule that an aggregation hierarchy must be acyclic is context-

sensitive. As long as these rules pertain to static syntax, (i.e. they constrain the static structure

of models), they can easily be defined by attributing the EBNF grammar. The attributes of an

EBNF production rule are logic formulae that must evaluate to true when the rule is evaluated.

Attribute parameters may be passed from rules to subrules and vice-versa.

Static semantics: dynamic context-sensitive constraints. (a.k.a. Dynamic context-sensitive

syntax, c.f. Section 1.5) Finally, the context-sensitive constraints of a graphic modelling lan-

guage may also contain dynamic rules. In ADORA for example, a diagram may be modified by

3.3. DEFINITION OF CONTEXT-FREE SYNTAX 65

adding more detail to the representation of an object. In this case, the graphic representation of

the relationships that this object has with other objects also must be modified. Formally describ-

ing such consistency rules is rather difficult, because they cannot be modelled with attributed

grammars. We use operational rules similar to those used for operational definition of language

semantics [73] to express such dynamic constraints.

3.3 Definition of Context-free Syntax

Using the ADORA language as an example, we demonstrate in this section how we define the

context-free syntax of a graphic modelling language in our approach.

3.3.1 A Naive Graphics to Text Mapping

Unlike the syntax of textual languages, the abstract syntax of ADORA can not simply be defined

in a pure graphical notation. Therefore, we try to enumerate all the graphical elements and their

possible combinations in the ADORA syntax, and map them into textual phrases (see Figure

3.1).

The mapping from the given graphic modelling language (the ADORA language in our case)

to an equivalent textual language is defined in tabular form (Figure 3.1). Every graphic model

element is uniquely mapped to a corresponding textual phrase.

For example, a rectangle with a string in the upper left edge in ADORA represents a single

abstract object with its name given by the string. This element is mapped to the textual phrase

object name end.

However, this naive mapping technique has a serious problem. Please look at the nonempty

entries of 4, 5, 6 and 7 of Figure 3.1. Actually, there are infinite possibilities of this kind of

graphical elements combination. Therefore the naive mapping of the language elements here

may result in a table with infinite lines. And we can never enumerate them all! We need to give

a more sophisticated mapping technique.

3.3.2 The Mapping

In this subsection, we introduce a more sophisticated graphics-to-text mapping technique which

avoids the problem of combinational explosion. We only give an excerpt of the mapping table

here. The full table can be found in Appendix A.

First we introduce some notations and meta symbols which will be used in our textual EBNF

syntax. Let x, y, z be non-terminal symbols.

• [x] denotes zero or one occurrence of x

• {x} denotes zero or many occurrence of x


name

Graphic element Equivalent textual element

object name end

object name annotation end

... …

state name end

... …

object name contain object name endend

object name contain object name end object name endend

object name contain state name endend

object name contain object name end state name endend

… …

name

name annotation

name

name(obj1)

name

name(obj1) name(obj2)

namename

name

name(obj1) name

1

2

3

4

5

6

7

Figure 3.1: A naive one-to-one graphics-to-text ADORA Mapping Table

• {x}1 denotes one to many occurrence of x

• x | y means either x or y

• x ∪ y means both x and y (i.e. one occurrence of x and one occurrence of y.).

However, the spatial relation between x and y is not specified

• z ::= . . . x : y . . . is a shorthand notation for the following two rules: z ::= . . . x . . .

and x ::= y.

Using such meta symbols and notations is a common technique used in defining the EBNF

syntax of a textual language. They are used to express the syntactically correct combinations

from the basic textual elements using a context free grammar.

After basic graphical elements are translated into textual strings/phrases, the syntactically

correct combinations of the basic graphic elements can be summarized by a set of EBNF rules

(c.f. Section 3.3.3).

What is more, if all the elements in the right side of an EBNF rules are defined (either in the

previous rows of the mapping table or in the previous EBNF rules), the term in the left side of

that rule is allowed to appear in a more complex graphic elements, such that an abstract visual

syntax can be defined in an understandable way.


For example, the graphic element in the first entry of the mapping table contains EBNF

rules, for example {system object chart}. Such a rule means that at this place any graphic

elements are allowed that translate to textual phrases satisfying the rule. With this technique,

here we summarize infinitely many situations: an object set contains one object, two objects,

two objects with one association, or three objects, ... (c.f. Nonempty entry 4, 5, 6 and 7 of Figure

3.1.) Actually the technique used here can also be thought as a kind of recursive definition.

name


object_set name {annotation}

[contains {system_object_chart}]

end

… …

object ***

association name numpair

from obj1:object

to obj2:object end

… …

pure_state name

end

start_state name

… …

name

name numpairname (obj1) name (obj2)

name {annotation}

{system_object_chart} 1

object_i ***I

name

transition t_condition/t_action

from obj_f : object_i

to obj_t : object_i end

transition t_condition/t_actionfrom obj_f:object_i

to s_t : state end

t_condition/t_action

t_condition / t_actionI I

name( obj_t )

I

name(obj_f)


from s_f : stateto s_t : state end


{statechart} [contains {statechart} ]1

end[contains {statechart} ]

1

name{statechart}

name (s_f)

name state ***

name (s_t)

{statechart}

name (s_t)


from s_f : state

to obj_t:object_i end


name (s_f)

name( obj_f )

name( obj_t )

I

1

2

3

4

5

6

7

8

9

10

11

Figure 3.2: An Excerpt of the ADORA Mapping Table (1)

Let us see another example. In the naive graphics to text mapping table, in order to map

“association”, we need to enumerate 16 (24) cases: an association can connect with two ob-

jects, two object sets, etc,. In the second nonempty entry in Figure 3.2 corresponding to the


textual phrase “object”, we introduce a graphical element, which will never appeared in any

real ADORA models. However, through this element, the mapping of “association” showed in

the third nonempty entry summarizes all these possible cases. Note that this kind of graphical

elements are also called “artificial graphical elements”, and will be marked with “∗ ∗ ∗” in the

mapping table.


scenario_norm name

end

scenario_alt name

end

name

{statechart}

name

{statechart}

... ...

scenario ***name

... ...

... ...

connection

whole sc:scenario

compo sc_c:scenario_alt

end

…

name(sc)

name(sc_c)

{statechart}

connection

whole sc:scenario

compo sc_c:scenario_norm

end

…

name(sc)

name(sc_c)

{statechart}

... ...

[ contains {statechart} ]

[ contains {statechart} ]1

1

scenario_seq name num_id

end

name

{statechart} #[ contains {statechart} ]1

Figure 3.3: An Excerpt of the ADORA Mapping Table (2)

In a word, by introducing some sophisticated mapping techniques (e.g. using the defined

EBNF grammar categories in the graphical notation to summarize the combinations of basic

graphic elements), we can map the whole language in a table with some dozens of lines (c.f.

Appendix A). Note that Figures 3.2 and 3.3 show only the mapping of the model elements,

which are necessary for reading the rest of this chapter.

Having done this mapping, we have a textual language that is equivalent to the original


graphic language.

By the way, for a better understandability, all the artificial graphical elements can also be

defined as a kind of “macro” definitions.

For example, the second and tenth nonempty entries in Figure 3.2 can also be defined as

shown in Figure 3.4. Any appearance of the graphical element in the left column can be replaced

by one of the graphical elements in the right column.

Graphic element Equivalent textual element... …

… …

name name {annotation}

{system_object_chart}name {annotation}

{system_object_chart} ...

name name{statechart}

name {statechart}

Figure 3.4: Macro Definitions

3.3.3 EBNF Syntax

The core part of the ADORA EBNF syntax will be listed in this section, and the complete syntax

definition can be found in Appendix B.

We start with some remarks.

• The non-terminal symbol names in our EBNF definition do not always have the same

meaning as these names have in the ADORA language. For example, the name “object” in

the EBNF grammar includes the types object, object set, external object, external object

set in the ADORA language. To avoid confusion, all references to symbol names in the

EBNF grammar are underlined in the following text (e.g. system object).

• The detailed definition of expression, operator, annotation, attribute, operation, t condition,

t action, etc. are not presented here, as most of them are defined in the same way as in

other textual specification/programming languages, such as Z, Java, etc. And their de-

tailed definition can been found in Appendix B.

• The meaning of abstract relationships and interrelationships are explained in section 2.2.1.


• In a system specification, the names of objects and object sets are unique. However, the

names of relationships, states, etc., are not unique. We need to define extra attributes,

such as “associationID”, to identify those elements. As this section serves the purpose of

explanation of our ideas on the syntax definition, for simplicity, we assume in this section

that these elements are also identified by their name. A more strict definition can be found

in Appendix B.

Specification

specification ::= { specification fragment }specification fragment ::= { model element }model element ::=

object | state | scenario | relationship | annotation

Types

Literal ::=

FloatingPointLiteral | IntegerLiteral | CharacterLiteral |StringLiteral | BooleanLiteral | NullLiteral

IntegerLiteral ::=

NonNegativeIntegerLiteral | NegativeIntegerLiteral

numpair ::=

NonNegativeIntegerLiteral “,” NonNegativeIntegerLiteral

. . .

Expression

. . .

Operator

. . .

Chart

system object chart ::= system object ∪ {system object | relationship | transition | connection}statechart ::= state ∪ {state | transition}. . .

Annotation

annotation ::= . . .

Objects/States/Scenario declarations

object ::= object i | singleton object e | object set e

system object ::= object i | state | scenario |singleton object e | object set e

object i ::= singleton object | object set | start object | start object set

singleton object ::= object name [obj body] end

start object ::= start object name [obj body] end

singleton object e ::= object name “: external” end


object set ::= object set name [obj body] end

start object set ::= start object set name [obj body] end

object set e ::= object set name “: external” end

env object ::= element of the environment name

obj body ::=

{annotation} [attributes {attribute}1]

[operations {operation}1] [contains {system object chart}1]

attribute ::= . . .

operation ::= . . .

stateobject ::= state | object i

state ::= pure state | start state

pure state ::= state name [contains {statechart}1] end

start state ::= start state name [contains {statechart}1] end

generic start state ::= start state | start object | start object set

...

scenario ::= scenario norm | scenario alt | scenario iter | scenario conc | scenario seq

scenario norm ::= scenario norm sc name [contains {statechart}1] end

scenario alt ::= scenario alt sc name [contains {statechart}1] end

scenario iter ::= scenario iter sc name [contains {statechart}1] end

scenario conc ::= scenario conc sc name [contains {statechart}1] end

scenario seq ::= scenario seq sc name NumberID [contains {statechart}1] end

...

Relationship/Transition/Connection declarations

relationship ::=

association | abstract relationship | interrelationship

association ::= association name numpair

from obj1:object to obj2:object end1

abstract relationship ::=

abstract relationship {name}connecting obj1:object and obj2:object end |abstract relationship {name}connecting obj:object and sc:scenario end |abstract relationship {name}connecting obj:object and e:env object end |abstract relationship {name}

1In a pure context-free grammar, it would obviously be simpler to state this rule just as: association ::= associ-ation name numpair from object to object end. However, when we later attribute this rule for expressing the staticcontext-sensitive constraints, we need to denote the identifiers obj1 and obj2. The same is true for other rules, forexample those defining transitions.


connecting sc:scenario and e:env object end

interrelationship ::= interrelationship

sub a:association

super ar:abstract relationship

end |interrelationship

sub ar1 : abstract relationship

super ar2 : abstract relationship

end

transition ::= transition t condition/t action

from obj f:object i to obj t:object i end |transition t condition/t action

from obj f:object i to s t:state end |transition t condition/t action

from s f:state to obj t:object i end |transition t condition/t action

from s f : state to s t: state end

t condition ::= . . .

t action ::= . . .

...

connection ::=

connection connectionID

whole sc:scenario compo sc c:scenario norm end |whole sc:scenario compo sc c:scenario alt end |whole sc:scenario compo sc c:scenario conc end |whole sc:scenario compo sc c:scenario seq end |whole sc:scenario compo sc c:scenario iter end

. . .

3.3.4 Abstract Syntax vs. Concrete Syntax

The abstract syntax 2 describes the fundamental structure of a language, which is mainly used

for human beings to understand the essence of the language syntax.

The concrete syntax concretizes the abstract syntax into a level of the lexical syntax. It

is machine-oriented and can be used directly for the construction of a language parser and

compiler.

2In some literature, the representation form of the abstract syntax is restrict to the abstract syntax tree.

3.4. DEFINITION OF STATIC SEMANTICS 73

The above presented EBNF grammar is an abstract syntax. In order to get the concrete

syntax, it needs to be further optimized and concretized.

For example, we have a model with two associations r1, r2 and two objects A,B. Both

associations connect A and B. According to the abstract syntax definition, when we parse r1

and r2, both A and B will be parsed twice. In a concrete syntax, some extra reference elements

will be added to improve the parsing efficiency.

In the metamodeling technique, metamodels are the abstract syntax of the graphic modelling

languages. A concrete syntax for the compiler design can only be derived from the semantic

interpretation of the metamodels. In the OMG UML definition, the metamodels are the core

part of UML. That is to say, in order to get a definition of the concrete syntax, we need first to

know the semantics of the core elements of the language. This kind of mixture of syntax and

dynamic semantics definition in OMG metamodeling is a taboo in a clean and formal language

definition.

Compared with the metamodeling technique, the derivation from the abstract syntax to the

concrete syntax in our EBNF-based approach is only a process of optimization, and hence much

easier and more straightforward. Actually, this is one of the most important advantages of our

approach.

3.4 Definition of Static Semantics

Even for textual programming languages, a context-free grammar is not powerful enough for

expressing the static semantics of the language. In a graphic modelling language, we have

additional spatial layout constraints that are also context-sensitive.

We define the static semantics (a.k.a. context-sensitive syntax) in a way that is well-proven

for EBNF grammars: we attach constraint attributes to the EBNF grammar rules. Every attribute

is a logic formula. Whenever an EBNF rule is evaluated, all attributes of this rule must be true.

Attributes are well suited for the specification of static context-sensitive constraints. How-

ever, in particular in the ADORA language, we also have dynamic context-sensitive constraints

that pertain to transformations of an ADORA model into another representation such that well-

formedness is preserved. Describing such constraints with an attributed grammar is hard or even

impossible. Therefore, dynamic constraints will be defined with operational rules (see section

3.4.3).

In the ADORA language, the hierarchical structure of objects is the most important source

of static context-sensitive constraints. In order to express these constraints, we introduce the

concept of a pretrace in the following subsection. Using this concept, we will then present

selected attributed EBNF grammar rules.


3.4.1 Capturing Hierarchical Structure

Every object that is part of a hierarchical structure is hierarchically embedded in one or more

other objects. For example, in Figure 3.5, A is embedded in A′, A′′ and in A′′′, A′ is embedded

in A′′ and in A′′′, etc. Only the outmost object A′′′ is not embedded. In order to get rid of this

exception we assume that every object is always embedded in itself.

A A′ A′′ A′′′

Figure 3.5: A sample object hierarchy

Let A ⇒ B denote the fact that A is directly embedded in B; that means there exists no X

such that A �= X �= B and A ⇒ X ⇒ B.

Now we define the pretrace of a system object X to be the ordered set3 of model elements

that X is embedded in. Formally, we use a simple recursive definition:

if exists a system object B �= X such that X ⇒ B then X.pre = {X,B.pre}ordered, otherwise

X.pre = {X}.

For example, for the objects of Figure 3.5 we have:

A.pre = {A,A′, A′′, A′′′}ordered, A′′.pre = {A′′, A′′′}ordered and A′′′ = {A′′′}.

⊃ and ⊇ are the usual mathematical subset relations. Due to the definition of pretraces,

A.pre ⊃ B.pre means that A is embedded in B. Additionally, we define a special subset

relation � for pretraces: A.pre � B.pre if and only if A ⇒ B.

In the example of Figure 3.5, we have

A.pre � A′.pre, A′.pre � A′′.pre, A′′.pre � A′′′.pre.

We call the pretraces of two system objects A and B to be hierarchically equivalent if and

only if there exists another system object X where both A and B are directly embedded in, or

both A and B are outmost objects that are not embedded at all. In formal terms, we write:

Hierarchical equivalence. A.pre � B.pre iff

∃X : system object • (A.pre � X.pre ∧ B.pre � X.pre) ∨(A.pre = {A} ∧ B.pre = {B})The intuitive meaning of A.pre � B.pre is that either A and B are at the same hierarchical

level within a common system object or they are both not embedded (except in themselves).

The pretrace of a system object includes this object itself. Although this makes the def-

inition of hierarchical equivalence more complex, it greatly simplifies the definition of the

context-sensitive constraints of ADORA in later sections.

3Ordered sets can be understood as list without multiple entries.


3.4.2 Attributing the EBNF Grammar

The static context-sensitive constraints can now be specified by attributing the EBNF grammar

(written with Boldface text in Italic shape). The attributes of an EBNF grammar rule must

be true whenever this rule is evaluated. In this section, we present two typical examples only.

The first one describes the context-sensitive constraints for associations, and the second one

describes those constraints for one kind of state transitions. The rest can be found in Appendix

B.In the declaration of an association, the constraint is:

association ::= association name numpair

from obj1:object to obj2:object

Constraints:

obj1.pre ⊃/ obj2.pre

∧obj2.pre ⊃/ obj1.pre

end

This means that if an object C is embedded in another object A (it can be one level embedded

or several levels embedded), an association connecting A and C is not allowed. In Figure 3.6,

r1 is not well-formed and r2 is well-formed.

A

B Cr 1

Dr 2

Figure 3.6: Context-sensitive constraints of associations: r1 is not well-formed, r2 is well-formed

The EBNF rule for transitions in the static semantics of the ADORA language needs several

attributes. Here we present one case of this rule where a transition leads from a state to an

object (which has an internal state). Intuitively, the constraint is that a state transition may cross

state boundaries (as it is usual in statecharts), but must not cross object boundaries except the

boundary of the destination object (c.f. Section 2.3.1).

transition::= . . .

. . . |transition t condition/t action

from s f:state to obj t:object i

Constraints:

∃ S:state • S ∈ s f.pre ∧ ( S.pre � obj t.pre ∨ S.pre � obj t.pre )

. . .


Stated in natural language, the constraint says that there must exist a state S in the pretrace

of the source state (with S being identical to the source state as a special case) such that S

is either directly embedded in the destination object or S is at the same hierarchical level as

the destination object (i.e. their pretraces are hierarchically equivalent). This constraint is

equivalent to the intuitive rule stated above. In the example of Figure 3.7, transitions t1, t2 and

t3 are well-formed, while transition t4 is not well-formed.

X

C

t 1

t 2

A

ST

U

t 3

t 4

Figure 3.7: Context-sensitive constraint of state transitions. Transitions t1, t2, t3 are legal, t4 isillegal.

3.4.3 Operational Rules in the Structural View

As we already mentioned at the beginning of section 3.4, there are complex context-sensitive

constraints that are hard or even impossible to express with constraint attributes. In ADORA,

a particular problem of this kind is the well-formedness of diagrams that show a (partial) view

of a larger underlying model. In contrast to languages such as UML, the well-formedness of

an ADORA diagram not only depends on the information given in the diagram, but also on

information which is present in the model, but not visible in the particular diagram. In Section

2.2.1, we show an example to explain why the introduction of complex dynamic constraints is

necessary.

In order to define such dynamic constraints, we introduce operational rules. The logical

structure of these rules is similar to the rules being used in the definition of operational semantics

for programming languages. However, we use a different notation in our work in order to make

the rules easier to understand. Only a few rules will be presented here as examples, and the

complete definition can be found in Appendix C.

3.4.3.1 General Format of Rules

Every operational rule has the following format.


Rule: rule-name (parameters)Given: M ; Γ; model elements

Condition: predicate pre

Assertion: predicate post

Next Rule: rule-name (parameters)

Rule names need not be unique; we may have more than one rule with the same name but with

different conditions. A rule is interpreted as follows: for any ADORA model M that contains the

given model elements and has a partial view Γ such that predicate pre is true, the application

of the rule modifies Γ so that predicate post becomes true. The application of the rule does

not modify anything that is not specified in predicate post. If the Next Rule field contains a

name, the rule(s) matching this name must be applied next in order to transform a well-formed

view Γ eventually into a new view Γ1 that is also well-formed. Rule execution stops when the

Next Rule field is empty or when the conditions (predicate pre) of all matching rules are false.

Parameters may be used to transfer information from a rule to the next one.

3.4.3.2 Meta-functions

We need the following meta-functions for determining the visibility of model elements in a

given partial ADORA model (typically represented in a diagram).

Let M be an ADORA model with X,Y, Z : model element, A,B,C,D : object, r :

association, u : abstract relationship and let Γ be a partial view of M .

• abstracted(X, Γ) is a boolean function that is true if and only if X is not visible in Γ due

to an explicit command (“abstract”) of a user.

• hidden(X, Γ) is a boolean function that is true if and only if X is not visible in Γ. For a

set of model elements, hidden({X,Y, Z}, Γ) means hidden(X, Γ) ∧ hidden(Y, Γ) ∧hidden(Z, Γ).

We define two functions for invisible model elements in order to reflect the fact that there

are two situations where a model element X becomes invisible due to a view transition:

(a) The users explicitly want X to be invisible in the new view;

(b) X must be invisible in a view because its “father” or “ancestor” 4 is also invisible in this

view.

After a view transition Γ → Γ′, according to situation (a), we have

abstracted(A, Γ′) ∧ hidden(A, Γ′),

where as in situation (b) we have

¬abstracted(A, Γ′) ∧ hidden(A, Γ′).

4Here “father” or “ancestor” are the same metaphor used in the previous chapter. if D.pre � C.pre, D is“father” of C; if Object D.pre ⊂ C.pre, D can be the “grandfather” or a “ancestor” of C.


For convenience we also define two meta-functions expressing the contrary of “abstracted”

and “hidden”.

• concretized(X, Γ) is a boolean function that is true if and only if uX is visible in Γ due

to an explicit command (“concretize”) of a user. By definition holds

concretized(X, Γ) = ¬abstracted(X, Γ) for all X and Γ.

• visible(X, Γ) is a boolean function that is true if and only if X is visible in Γ.

For a set of model elements, visible({X,Y, Z}, Γ) means visible(X, Γ)∧visible(Y, Γ)∧visible(Z, Γ). This function is defined for convenience only. By definition holds

visible(X, Γ) = ¬hidden(X, Γ) for all X and Γ.

Distinguishing between “abstracted” and “hidden” is necessary to keep a history record of

view transitions. For example, consider the situation given in Figure 3.8.

X A B (1) XA ...

(2)X ...

XA ...

X ... (5)

(3)

(4)

View transitionsdue to use commands:(1) Abstract B(2) Abstract A(3) Abstract A(4) Concretize A(5) Concretize A

Γ Γ Γ

Γ

ΓΓ

1 2

3

45

D

X A BD

Figure 3.8: View transitions with histories.

After transitions (1) and (2), we have

abstracted(A, Γ2) ∧ abstracted(B, Γ2) ∧ hidden(A, Γ2) ∧ hidden(B, Γ2)

After transition (3), however, we have

abstracted(A, Γ3) ∧ ¬abstracted(B, Γ3) ∧ hidden(A, Γ3) ∧ hidden(B, Γ3)

It is only due to this distinction that we can construct the views Γ4 and Γ5 as an inverse of

the previous hiding-operations.

• partial(A, Γ) is a boolean function that is true if and only if the name of A in Γ is followed

by three dots.

• The meaning of the ⊂ and � operators (c.f. Section 3.4.1) is extended to relationships as

follows.

– r(A,B) ⊃ u(C,D) if and only if A.pre ⊃ C.pre and B.pre ⊃ D.pre.


– r � u, if and only if r ⊂ u and there is no u1 in Γ, such that r ⊂ u1 ⊂ u.

Note that all the following functions will only be used in the view transitions of “concretization

of an object”.

• O⊇A if and only if O.pre ⊃ A.pre and for any object C if O.pre ⊇ C.pre ⊃ A.pre then

abstracted(C, Γ) is false.

In other words, O⊇A means that A is an ancestor of O, and any object, which is embed-

ded in A and at the same time contains O, is not directly abstracted by users.

For example, in view Γ3 of Figure 3.8, we have D⊇A, because D is embedded in

A and for any object Oi, which lies between A and D (including D, but excluding

A) in the hierarchy, abstracted(Oi, Γ3) is false (in this example, abstracted(B, Γ3) =

abstracted(D, Γ3) = false). On the other hand, in view Γ2, (D⊇A) is false.

• inbetween(r(A,B), u(C,D), u1(E,F ), Γ) is a boolean function that is true if and only

if

– hidden(r, Γ) is true, and

– r � u ∧ u ∈ Γ ∧ u1 ∈/ Γ and

– visible({E,F}, Γ) and

– If we added u1 into Γ, r � u1 � u would be true.

Here we give the intuitive meaning of this function.

inbetween(r(A,B), u(C,D), u1(E,F ), Γ) is true, when there exists an

abstract relationship u1(E,F ). If we added this abstract relationship u1 into the view, it

would be between the relationship hierarchy of Abstract relationship u and an Association

r.

• related(B,A) is a boolean function that is true if and only if B ∈ {D | D⊇E}, where

E ∈ {F | F ⊆ A}.

In the view transitions of ADORA, when Objects A and B are related, if A is abstracted

or concretized, maybe the visibility of B needs to be changed too. This is the reason that

we introduce this function.

• related(r(B,C), A) and related(u(B,C), A) are boolean functions that are true if and

only if either related(B,A) = true or related(C,A) = true.

Note that r(B,C) denotes an association connecting B and C and u(B,C) denotes an

abstract relationship connecting B and C.

What is more, related({r, u1, u2}, A) means related(r, A) ∧ related(u1, A) ∧related(u2, A).

In the view transitions of ADORA, when Objects A and r are related, if A is abstracted or

concretized, maybe the visibility of r needs to be changed too.

Note that if we specify the syntax and static semantics of ADORA in a “pure” declarative way,

these two functions (related(B,A) and related(r(B,C), A)) are not necessary. Readers can


just skip them when reading the operational rules.

As our specification serves also as a referential implementation model, these functions are

introduced for the sake of algorithm efficiency. In Chapter 7, more explanations will be given,

when we talk of the tool implementation of our syntax and static semantics of ADORA.

3.4.3.3 Rules for Abstracting an Object

In this subsection, we present the operational rules that describe the process of making an

ADORA diagram more abstract by hiding one of its objects.

ZX

A

C

Y

B

Z

C

Y

B

X ...

Z

C

Y

BX ...

r

s

rs

ar

s

α

Step 1 Rule “Hide an object”

Step 2 Rule “Abstract a relationship”

Step 3 Rule “Adjust interrelationships”

Z

C

Y

BX ...

ar

s

Figure 3.9: The process of hiding an object from an ADORA diagram. The original and the finaldiagram are well-formed, the intermediate ones are not.

Readers who do not want to dig into the formalisms can skip this part, and read the meanings

and explanations of these rules, which are presented at the end of this subsection.

The process is illustrated in Figure 3.9. In this example, three rules must be applied con-

secutively in order to transform a well-formed diagram into a more abstract one that is again

well-formed.

The dashed line in the bottom diagram of Figure 3.9 connecting the association s and the

abstract relationship ar is an interrelationship. It denotes the fact that ar is not only an abstrac-

tion of the hidden association r, but also of s.


Abstract an object

Rule Abstract an object (A)

Given: M ; Γ; A : object

Condition: visible(A, Γ)Assertion: abstracted(A, Γ)Next Rule: Hide an object - Group 1 (A)

Hide an object

Rule Hide an object (A)

Given: M ; Γ; X : object i; A : object

Condition: (A.pre � X.pre) ∧ visible({A, X}, Γ) ∧( ¬∃Y : object • (Y.pre ⊃ A.pre ∧ visible(Y, Γ)))

Assertion: hidden(A, Γ) ∧ partial(X, Γ)Next Rule: Abstract a relationship (A)

. . . . . .

Abstract a relationship

Rule Abstract a relationship (A)

Given: M ; Γ; X : object i; A, B : object;r(A, B) : association

Condition: (A.pre � X.pre) ∧hidden(A, Γ) ∧ visible({B, X, r(A, B)}, Γ)

Assertion: hidden(r(A, B)) ∧ ∃ar : abstract relationship •(ar(X, B) ∈ Γ) ∧ visible(ar, Γ)∧∀z : abstract relationship¬∃α : interrelationship • α(r, z) ∈ Γ

Next Rule: Adjust interrelationships (ar)

. . . . . .

Adjust interrelationships

Rule Adjust interrelationships (ar)

Given: M ; Γ; s : association; ar : abstract relationship

Condition: (s � ar) ∧ visible(s, Γ) ∧ ¬∃α : interrelationship • α(s, ar) ∈ ΓAssertion: ∃α : interrelationship • α(s, ar) ∈ ΓNext Rule: Adjust interrelationships (ar)



Given: M ; Γ; ar, z : abstract relationship

Condition: (ar � z) ∧ ¬∃α : interrelationship • α(ar, z) ∈ ΓAssertion: ∃α : interrelationship • α(ar, z) ∈ ΓNext Rule: Adjust interrelationships (ar)


Given: M ; Γ; s : association; ar, z : abstract relationship

Condition: visible(s, Γ) ∧ (s � ar � z) ∧ ∃α : interrelationship • α(s, z) ∈ ΓAssertion: ¬∃α : interrelationship • α(s, z) ∈ ΓNext Rule: Adjust interrelationships (ar)

. . . . . .

In the situation illustrated in Figure 3.9, the transformation starts with the “Abstract an

object” rule, which is initiated by users. According to its Next Rule clause, the “Hide an

object” rule will be automatically executed next, with the hidden object A as a parameter. After

that, “Abstract a relationship” rules have to be executed, again with the hidden object A as a

parameter. There exist several rules with this name. However, we show the sole rule which

applies in our example case (i.e. where the condition is true). Other rules will be given in

Appendix C. In the next step, “Adjust interrelationships” rules have to be executed. Three of

these rules are listed in this section. In our example, only the condition of the first of them is

true. So this rule is executed. According to the Next Rule clause,”Adjust interrelationship”

rules have to be executed again. However, in the new situation the conditions of all these rules

are false. Hence, rule execution terminates and the transformation is complete.

Here we give the meaning of the above rules applied in Figure 3.9 in words. The rules apply

to any model M and view Γ where we have object A.

Abstract an object This rule says that if A is visible, it will be abstracted. The next rule “Hide

an object” will be executed, and A will be as a reference passed to the next rule.

Hide an object The rule will be applied when (i) A is directly embedded in an Object X in M

and Γ, (ii) there are no visible objects embedded in A, and (iii) both A and X are visible

in the view Γ. After application of the rule, A is hidden from the view, and the name of

object X has three dots appended.

Abstract a relationship The rule in Group “Abstract a relationship” specifies the following

three points: (i) after object A is hidden, the association r connecting with A should also

be hidden in the view; and (ii) an abstract association ar connecting with X , in which

A is directly embedded, should be automatically generated in the view (note that only in

the view, not in the model); and (iii) any possible interrelationship connecting r should

be deleted from the view.


Adjust interrelationships In our example case, the precondition of the first rule in this group

is true: (i) the newly generated abstract association ar and the original association s form

a relationship hierarchy s � ar; (ii) and there is no interrelationship between them. After

application of the rule, an interrelationship will be generated.

3.4.3.4 Rules for Concretizing an Object

In this subsection, we present the operational rules that describe the process of making an

ADORA diagram more concrete by showing a previously hidden object. The process is il-

lustrated through an example (c.f. Figure 3.10).

Y

B

Y

B

Y

Bs

Rule "Concretize an object ( A )" & Rule "Show objects and associations" & Rule "Adjust objects' partial signs"

Rule "Adjust abstract relationships"

Z

C

X ...α

ar

s

Z

X

A ...

C

Z

X

A ...

Cα

ar

s

u

Z

X

A

C

Y

B

t

s

A'

Z

X

A

C

Y

Bs

tA'

u

Rule "Adjust abstract relationships"

Rule "Concretize an object ( A' )" & Rule "Show objects and associations" & Rule "Adjust objects' partial signs"

Step 1.

Step 2.

Step 3.

Step 4.

Y

B

Y

Bs

The Third Rule in the Group"Adjust abstract relationships"

Z

X

A ...

C

X

A ...

Cα

ar

s

u

Y

Bs

Z

X

A ...

C

u

Y

Bs

Z

X

A ...

C

u

ar

α

ar

The Second Rule in the Group"Adjust abstract relationships"

The First Rule in the Group"Adjust abstract relationships"

{Step 2.1

Step 2.2

Step 2.3

Figure 3.10: Concretizing an object A

Here, only the rules applied in the example in Figure 3.10 will be explained. Readers are

suggested to read the explanations and the operational rules listed at the end of this subsection

together.

The basic ideas of view transitions on abstracting/hiding and concretizing/showing an object

are very similar. Therefore, in this subsection we only explain the most important points of the

operational rules.

Through the example in Figure 3.10, we give a short explanation of the meaning of the

operational rules and their applications.


Concretize an object Rules in this group are executed because users want to make a selected

object visible, when it is hidden before.

In our example (c.f. Figure 3.10), this rule changes the attributes “abstract” of objects A

and A′ to false in Step 1 and Step 3.

Show objects and associations Rules in this group will be executed next. This rule does the

following:

• it makes object A itself visible in the current view;

• all the objects, of which object A is a component, will be made visible. What is

more, the attributes “abstract” of those objects will be changed to false. We call the

set of this kind of objects here Sc.

Note that the Sc set contains all the objects, whose properties are the same as Object

B mentioned in our rule.

• all the objects, which have the following three properties, will be visible in the new

view again.

– Those objects are invisible in the current view;

– the only reason of their invisibility is that they are the “descendant” of the ob-

jects in Set Sc;

– they are not abstracted by a user.

In other words, object A becomes visible, when (A⊇O) ∧ (O ∈ Sc).

Through this explanation, we can also understand the reason for introducing of the

operator ⊇.

• if an association is previously hidden, only because of the invisibility of the objects,

which are made again visible by this rule, will be also visible.

In our example, in Step 1 object A and in Step 3 object A′ are made visible.

Adjust objects’ partial signs adjusts (adds or deletes) the is-partial indictors of the objects,

which are changed from invisible to visible.

In our example, an is-partial indicator of object A is appended in the Step 1, and it is

deleted again in the step 3.

Adjust abstract relationship The intuitive meanings of the rules in this group are not so com-

plex, as they may look.

• The first rule says that if an association r is made visible, the abstract relationship

ar, which is generated because of r and is not connected by any interrelationship,

should be deleted from the view.

• The second rule says that, if ar mentioned in the first rule is connected by some

interrelationship, that interrelationship should be deleted from the view at first.

• The third rule says the situation in Figure 3.11. During the view transition, be-

tween an abstract relationship (u in our example in Figure 3.11) and the hidden


Y

B

Z

X A ... uY

B

Z

X A ...

v

Y

B

Z

X Ar

A'

(a) a complete view of an ADORA model

(b) an intermediate view of an ADORA model (not well-formed) (c) a well-formed view of an ADORA model

( replacement of u by v )

Figure 3.11: Abstract relationship u is replaced by Abstract relationship v

assoication, there could exist another abstract relationship (v in our example in Fig-

ure 3.11) in the relationship hierarchy. The former abstract relationship (u) should

be replaced by the later (v).

From this example, the meaning of the meta-function inbetween should be very

clear.

In our example, the right side of diagrams explains a sequence of changes by repeatedly

applying the rules in this group:

• in Step 2.1, an abstract relationship u is generated;

• in Step 2.2, the interrelationship α is deleted;

• in Step 2.3, the abstract relationship ar is deleted.

When all the preconditions of the rules in Group “Adjust abstract relationship” are false, the

rules in the next group “Adjust interrelationships” will be executed. This is stated in the group

rule name “Adjust abstract relationships (=⇒ Adjust interrelationships (A))”. In our example,

all the precondition of the rules in Group “Adjust interrelationships” are false. Therefore no

rules in that group are listed here. And the whole execution terminates.

After the above explanation, the operational rules will be listed as follows.

Concretize an object

Rule Concretize an object (A)


Condition: hidden(A, Γ)Assertion: ¬abstracted(A, Γ)Next Rule: Show objects and associations (A)


Show objects and associations

Rule Show objects and associations (A)


Condition: hidden(A, Γ) ∧ ¬abstracted(A, Γ)Assertion: ∀B : object • (B.pre ⊆ A.pre) →

(visible(B, Γ) ∧ ¬abstracted(B) ∧ (∀C : object•((∀r : association • (r(B, C) ∈ Γ ∧ visible(C, Γ)) → visible(r, Γ))∧(∀D : object • (D⊇B) →(visible(D, Γ) ∧ (∀C : object•((∀r : association • (r(D, C) ∈ Γ ∧ visible(C, Γ)) → visible(r, Γ))

Next Rule: Adjust objects’ partial signs (A)

Adjust objects’ partial signs

Rule Adjust objects’ partial signs (A)


Condition: true

Assertion: ∀B : object • ((related(B, A)∧(((¬∃C : object • hidden(C, Γ) ∧ C.pre � B.pre) → ¬partial(B, Γ))∧((∃C : object • hidden(C, Γ) ∧ C.pre � B.pre) → partial(B, Γ)))

Next Rule: Adjust abstract relationships (A)

Adjust abstract relationships (=⇒ Adjust interrelationships (A))

Rule Adjust abstract relationships (A)

Given: M ; Γ; A : object; ar : abstract relationship

Condition: related(ar, A) ∧ (¬∃r : association • hidden(r, Γ) ∧ (r � ar))∧(¬∃r1 : association, α : interrelationship • α(r1, ar) ∈ Γ)∧(¬∃ar1 : abstract relationship, α : interrelationship•α(ar1, ar) ∈ Γ ∨ α(ar, ar1) ∈ Γ)

Assertion: ar ∈/ ΓNext Rule: Adjust abstract relationships (A)



Given: M ; Γ; A : object; ar : abstract relationship∧Condition: related(ar, A) ∧ (¬∃r : association • hidden(r, Γ) ∧ (r � ar))∧

((∃r1 : association, α : interrelationship • α(r1, ar) ∈ Γ)∧(∃ar1 : abstract relationship, α : interrelationship•α(ar1, ar) ∈ Γ ∨ α(ar, ar1) ∈ Γ))

Assertion: (∀α : interrelationship, r1 : association, ar1 : abstract relationship•(α(r1, ar) ∈ Γ ∨ α(ar1, ar) ∈ Γ ∨ α(ar, ar1) ∈ Γ) → α ∈/ Γ)



Given: M ; Γ; A : object; r : association; ar : abstract relationship

Condition: related(ar, A) ∧ hidden(r, Γ) ∧ (r � ar) ∧∃ar2 : abstract relationship • inbetween(r, ar, ar2, Γ)

Assertion: ar2 ∈ ΓNext Rule: Adjust abstract relationships (A)

...

3.4.3.5 Remarks

The Given field and the parameters of the rule define the model elements being used as vari-

ables. Note that there are no free variables in the Condition predicate. Parameter variables are

externally bound; the other variables are bound to the existential quantifier.

The strict logic definition of the rules and the execution sequence are given in Appendix C.

There are about 30 operational rules in the complete definition.

3.4.4 Operational Rules in the Behavioral View

As explained in Section 2.2.2, the extended statechart (so called generic statechart), which is

introduced in detail in [24], is the major modelling notation in the ADORA behavior view. There

are no constructs, such as abstract relationship and interrelationship in the behavioral view. The

operational rules on view transition in the behavioral view are hence much simpler.

Figure 3.12a) shows the abstraction of a state (s6) in Step 1 and the concretization of another

state (s5) in Step 3.

In Figure 3.12 a), if we want to have an “abstracted” state s6, the whole generic statechart

will be hidden from the view (i.e. s9, s10, s11, t6 and t7 will be hidden from the view). When

this “abstracted” state s6 is concretized again in future, all the states s9, s10, s11, t6 and t7 will

be visible in the view again.


t1

t2

t3

S1

S2

S3

t4

t7

t5t6

S4

S5S6

S7

S8

S9

S10

S11

t1

t2

t3

S1

S2

S3

t4

t5

S4

S5

S6 ...

S7

S8

t1

t2

t3

S1

S2

S3

S4

S5 ...

t1

t2

t3

S1

S2

S3

t4

t5

S4

S5

S7

S8

t1

t2

t3

S1

S2

S3

t4

t7

t5t6

S4

S5S6

S7

S8

S9

S10

S11

t1

t2

t3

S1

S2

S3

t4

t5

S4

S5

S7

S8

t1

t2

t3

S1

S2

S3

S4

t1

t2

t3

S1

S2

S3

t4

t7

t5t6

S4

S5S6

S7

S8

S9

S10

S11

a) b) an Undesirable Series of View Transitions

Step 1: Abstract and hide statecharts in State S6


Step 3: Concretize and show statecharts in State S5



Step 3: Concretize and show statecharts in State S5

S6 ...

S6 ...

S5 ...

Figure 3.12: a) A correct series of view transitions with recording the history; b) A wrong seriesof view transitions without recording the history.

Nevertheless, there are still some points worthy of further explanation. They will be given

in the next subsection.

3.4.4.1 Meta-functions and some Notes on the Rules

The meta-functions of the operational rules and some notes on those are given as follows.

Let M be an ADORA model with X : model element; SO, SO1, SO2 : stateobject; t :

transition and let Γ be a partial view of M .

• Functions: abstracted(X, Γ), concretized(X, Γ), visible(X, Γ), hidden(X, Γ) have the

same meanings as those defined in the structural view. Note that the motivation of intro-

ducing those functions is the same as that in the structural view. One reason of introducing

these functions is that we want to keep the useful history information. In Figure 3.12a,

S6 is abstracted before S5. When S5 becomes “not abstracted”, S6 should remain to be

abstracted. That is say, the whole statechart should go to the latest situation or snapshot

before S5 is abstracted. The transition in Figure 3.12b is undesirable.


• partial(SO, Γ) is a boolean function that is true if and only if the name of SO in Γ is

followed by an is-partial indicator (three dots). When it is false, if there is an is-partial

indicator following the name of SO, it should be deleted.

• SO1⊇SO2 if and only if

1. SO1.pre ⊃ SO2.pre; and

2. for any stateobject SO3, if SO1.pre ⊇ SO3.pre ⊃ SO2.pre, then abstracted(SO3, Γ)

is false.

The motivation of introducing this operator and its intuitive meaning is just the same as

that in the structural view.

Some rule comments are given as follows.

• The second part of condition in the rule Abstract generic statecharts inside a state says

that this rule is only allowed to be applied to the following situation:

No transition crosses the border of that state, in which all generic statecharts

are hidden.

Actually, this is a weaker condition than what we state in Section 2.2.2, where view

transitions rules should only be applied to the statecharts without inter-level transitions.

• Just the same as those in the structural view, all the assertions mentioned in the above

rules are valid in the given model M . For example, the assertions, “SO3.pre ⊃ SO.pre”,

“SO1.pre ⊃ SO.pre”, etc., are valid in the model M . For the assertions only valid in the

given view Γ, they will be explicitly mentioned. For example, in hidden(SO, Γ), SO is

hidden only in the current view Γ. And Γ needs to be explicitly mentioned here.

• In the structural view and the behavioral view, some functions, such as partial, are

overloaded. I.e. in a structural view, Object A can be partial. However, in the same

model, A can also be not partial in a behavioral view. Later in Chapter 4, we give a con-

straint, “Behavioral views and structural views are not allowed to be combined in a single

ADORA view”, in the current development phase of ADORA. Therefore, no conflicts will

arise because of this overloading.

3.4.4.2 Operational Rules on View Transitions

The operational rules for view transitions in the behavioral view are given as follows.


Abstract generic statecharts inside a state/object

Rule Abstract generic statecharts inside a state/object (SO)

Given: M ; Γ; SO : stateobject

Condition: (¬abstracted(S, Γ)) ∧ ∀t : transition, so1, so2 : stateobject •(((t(so1, so2) ∈ M) ∧ (SO ∈ so1.pre)) → (SO ∈ so2.pre)) ;

Assertion: abstracted(SO, Γ)Next Rule: Hide generic statecharts inside a state/object (SO)

Hide generic statecharts inside a state/object

Rule Hide generic statecharts inside a state/object (SO)


Condition: ¬partial(SO, Γ)Assertion: partial(SO, Γ) ∧ ∀SO3, SO1, SO2 : stateobject, t : transition•

((SO3.pre ⊃ SO.pre) ∧ (hidden(SO3, Γ)))∧((SO1.pre ⊃ SO.pre) ∧ (SO2.pre ⊃ SO.pre)∧ (t(SO1, SO2) ∈ Γ) ∧ (hidden(t(SO1, SO2), Γ)))

Next Rule: ∅

Concretize generic statecharts inside a state/object

Rule Concretize statecharts inside a state/object (SO)


Condition: abstracted(SO, Γ)Assertion: ¬abstracted(SO, Γ)Next Rule: Show states/objects inside a state/object (SO)

Show states/objects inside a state/object

Rule Show states/objects inside a state/object (SO)


Condition: partial(SO, Γ)Assertion: ¬partial(SO, Γ) ∧ ∀SO1 : stateobject•

((SO1⊇SO) ∧ visible(SO1, Γ))Next Rule: Show transitions inside a state/object (SO)


Show transitions inside a state/object

Rule Show transitions inside a state/object (SO)


Condition: ∅Assertion: ∀SO1, SO2 : stateobject, t : transition•

((SO1.pre ⊃ SO.pre) ∧ (SO2.pre ⊃ SO.pre)∧visible({SO1, SO2}, Γ) ∧ t(SO1, SO2) ∈ M) → visible(t(SO1, SO2), Γ)

Next Rule: ∅

3.4.5 Operational Rules in the User View

Similar to the operational rules on view transitions in the behavioral view, the operational rules

in the user view are also relatively easy.

When we abstract a scenario Sc, Sc will be partial (i.e. an is-partial indicaotr will be

appended to the name of Sc.). What is more, all components of Sc (i.e. sub-scenarios of

Sc, sub-scenarios of the sub-scenarios of Sc, etc.) will be hidden. Surely, all the connections

connecting to the newly hidden scenarios will also be hidden.

When we concretize a scenario Sc, all sub-scenarios, which are hidden only because of

the abstraction of Sc, will be visible. The hidden connections connecting to the newly visible

scenarios will also be visible. What is more, if a newly visible scenario is embedded in a hidden

object, that object will also be concretized.

3.4.5.1 Meta-functions and some Notes on the Rules

The meta-functions of the operational rules and some notes on these are given as follows.

Let M be an ADORA model with X : model element; Sc, Sc1, Sc2, C, C ′, C ′′, C ′′′, D,E :

scenario; c : connection and let Γ be a partial view of M .

• Functions: abstracted(X, Γ), concretized(X, Γ), visible(X, Γ), hidden(X, Γ) have the

same meanings as those defined in the structural view. The reason for introducing these

functions is the same as those in the structural view and the behavioral view.

• The function part of(C,D) being true means Scenario C is a sub-scenario of Scenario

D and there is a connection between C and D. The relationship between C and D can be

one of the five types (c.f. Figure 2.3) specified in the scenariochart.

• indirect partof(C,D) is used to describe that Scenario C is a component of Scenario

D. However, there could be no connection between C and D. That is to say, C is not a

direct sub-scenario of D. It is formally defined as follows.

indirect partof(C,D) is true, if and only if


A ... B

C ...*

A B

C *

E2

B'

D ...1

Step 1:

Concretize the components of a scenario (B)

Show the components of a scenario (B)

Show connections of the componets of a Scenario (B)

B ...

A ...

A B

C *

E2

B'

D1

F *

Step 2:

Concretize the components of a scenario (C)

Show the components of a scenario (C)

Show connections of the componets of a Scenario (C)

In this case, Objects G and B' are also concretized.

Step 3:

Concretize the components of a scenario (D)

Show the components of a scenario (D)

Show connections of the componets of a Scenario (D)

G

Figure 3.13: An example of View Transitions on the User View

1. part of(C,D) is true, or

2. part of(C,E) and part of(E,D) are true, for any Scenario E in M , or

3. part of(C,E) and indirect partof(E,D) are true, for any Scenario E in M .

• We define a similar concept is part of Trace as the concept pretrace.

C.ispart returns an ordered set (a.k.a. list) of scenarios, of which Scenario C is a part (or

component).

C.ispart =

{C}ordered + D.ispart when part of(C,D) is true

{C}ordered

when there is no scenario D′ in M,

such that part of(C,D′) = true

where “s1 + s2” means union of s1 and s2 (Note that “∪” is for unordered sets). It means

“appending s2 after the last element of s1” for lists (ordered sets).


For example, in Figure 3.16a,

D.ispart = {D,C ′′′, C ′, C}ordered; C ′′′.ispart = {C ′′′, C ′, C}ordered;

E.ispart = {E,C ′′′, C ′, C}ordered; C ′′.ispart = {C ′′, C}ordered;

C.ispart = {C}ordered; C ′.ispart = {C ′, C}ordered.

• ⊃ and ⊇ are the usual mathematical subset relations. Due to the definition of

is part of Trace, C.ispart ⊃ D.ispart means indirect partof(C,D). Additionally, we

define a special subset relation � for is part of Trace: C.ispart � D.ispart if and only

if part of(C,D).

• Sc1⊃Sc2 if and only if

Sc1.pre ⊃ Sc2.pre and for any stateobject Sc3 if Sc1.pre ⊇ Sc3.pre ⊃ Sc2.pre,

then abstracted(Sc3, Γ) is false. The motivation for introducing this operator and its

intuitive meaning is just the same as those in the structural view and the behavioral view.

• Function concretize(O, Γ) is true, when Object O is concretized in the view Γ. The

effects of this action are just the same if users concretize Object O, which is specified in

Section C.4 and Appendix C.4.

• For some complex scenario, in order to explain temporal orders of the user-system re-

actions, we also allow a statechart to be embedded in a scenario. For simplicity, for the

statechart embedded in a scenario, it can only be either completely visible or completely

hidden in the view.

3.4.5.2 Operational Rules on View Transitions

Abstract the components of a scenario

Rule Abstract the components of a scenario (Sc)

Given: M ; Γ; Sc : scenario

Condition: ¬abstracted(Sc, Γ)Assertion: abstracted(Sc, Γ)Next Rule: Hide the components of a scenario (Sc)


Hide the components of a scenario

Rule Hide the components of a scenario (Sc)

Given: M ; Γ; Sc : cenarios

Condition: ¬partial(Sc, Γ)Assertion: partial(Sc, Γ) ∧ ∀Sc3, Sc1, Sc2 : scenario, c : connection•

((Sc3.ispart ⊃ Sc.ispart) ∧ (hidden(Sc3, Γ)))∧(((Sc1.ispart ⊇ Sc.ispart) ∧ (Sc2.ispart ⊃ Sc.ispart)∧(c(Sc1, Sc2) ∈ Γ)) → (hidden(c(Sc1, Sc2), Γ)))

Next Rule: ∅

Concretize the components of a scenario

Rule Concretize the components of a scenario (Sc)


Condition: abstracted(Sc, Γ)Assertion: ¬abstracted(Sc, Γ)Next Rule: Show the components of a scenario (Sc)

Show the components of a scenario

Rule Show the components of a scenario (Sc)

Given: M ; Γ; S : scenario

Condition: partial(Sc, Γ)Assertion: ¬partial(Sc, Γ) ∧ ∀Sc1 : scenario•

((Sc1⊃Sc) ∧ visible(Sc1, Γ))Next Rule: Show connections of the components of a scenario (Sc)

Show connections of the components of a scenario

Rule Show connections of the components of a scenario (Sc)


Condition: ∅Assertion: ∀Sc1, Sc2 : scenario, c : connection•

((Sc1.ispart ⊃ Sc.ispart) ∧ (Sc2.ispart ⊃ Sc.ispart)∧visible({Sc1, Sc2}, Γ) ∧ c(Sc1, Sc2) ∈ M) → visible(c(Sc1, Sc2), Γ)

Next Rule: ∅


Show objects containing visible scenarios

Rule Cancel the shortcut sign of a scenario (Sc)

Given: M ; Γ

Condition: ∅Assertion: ∀O : object, Sc1 : scenario•

(hidden(O, Γ) ∧ visible(Sc1, Γ)) → concretize(O,M)

Next Rule: ∅

3.4.6 A Global Constraint in the Behavior Views

In the above subsections, operational rules are used to specify the hierarchical constraints in the

structural view, the behavioral view and the user view of ADORA models.

As the hierarchical constraints involve quite a lot of language elements, they usually can

not be specified simply by attributing the EBNF grammar. Therefore, those constraints are also

called global constraints.

Except for those hierarchical constraints, there are also some other global constraints in

ADORA. Compared with the hierarchical constraints, they are much easier to describe. There-

fore, it is not necessary to describe them in the form of operational rules, in which a constraint

has to be expressed in a series of sequential steps to make constraints easily readable and im-

plementable. Using one first-order predicate logic formula will be expressive enough to specify

those non-hierarchical global constraints in most cases.

Compared with the simple context-sensitive constraints introduced in Section C.4, the global

constraints are relatively complex. Though they can be embedded into the EBNF context-free

grammar, the grammar with those embedded constraints will be difficult to read and understand,

as they involve too many language elements.

As readability and understandability play an important role in our language definition, we

separate the definition of those global constraints from the EBNF grammar, and list them in

extra sections.

Before, we introduce global constraints in the behavior view, let us first see an example.

3.4.6.1 A Case Study

Missing a generic start state 5 of a statechart is a common problem that causes misunderstand-

ing. See the following example,

For Figure 3.14a, because of the missing of a generic start state, there is a problem on the

semantics of the model. When the TV is switched on, which channel should it enter? Will it

5a generic start state can be a start state, a start object or a start object set. Note that a start state is also calledan initial state in some other statechart’s notation


one two

forward

threefour

Channel 4 Channel 3

Channel 2Channel 1

backward

forward

forward

forwardbackward

backward

backward

switch on switch off

Off

a)

one two

forward

threefour

Channel 4 Channel 3

Channel 2Channel 1

backward

forward

forward

forwardbackward

backward

backward

switch on switch off

Off

b)

Figure 3.14: a) an model with unclear meanings: b)an improved model of a television.

enter one of the four channels at random, or just enter a standby mode?

Figure 3.14b is semantically unambiguous.

In the next section, we can answer, whether this kind of error is an error of syntax / static

semantics (which can usually be mechanically checked) or of dynamic semantics (which usually

cannot be mechanically checked).

3.4.6.2 Formal Definition

As mentioned in [24] and Section 2.2.2, a generic statechart without inter-level transitions has

many more advantages than one with inter-level transitions.

In the ADORA language, we are allowed to model behaviors of a system using the notations

like that in Fig 2.9 (a). However, it is strongly recommended that the model of Fig 2.9 (a) be

changed into its semantically equivalent model of Fig 2.9 (b), which has no inter-level entry and

exit transitions. The latter is good for constructing large models from components, because it

makes the composition of generic statecharts possible.

By the way, if we use the second notation, we can even check the kind of errors in Figure

3.14a, which cannot be done by the notation of allowing inter-level transition.

We introduce the formal definition (related EBNF clauses, a meta-function, and a global

constraint) of the global constraint in the behavior views as follows.

Generic Statechart

generic statechart ::= { stateobject group }1

stateobject group ::= stateobject ∪ {stateobject | transition}generic start state ::= start state | start object | start object set

Let M is an ADORA model with so1, so2, so3 : stateobject, t : transition.

• tran rel(so1, so2,M) is a boolean function that is true if and only if


– there is t in M , such that it connects so1 and so2.

– there is so3 in M , such that tran rel(so1, so3,M) ∧ tran rel(so2, so3,M).

The intuitive meaning of tran rel(so1, so2,M) is: when tran rel(so1, so2,M) is true, so1 and

so2 are directly connected by a transition or indirectly connected through several transitions.

Please note that tran rel(so1, so2,M) has no direction. This means that s1 and s2 may be

connected as shown in Figure 3.15.

S1 S2S3

Figure 3.15: s1 and s2 are indirectly connected.

A Global Constraint

In any ADORA Model M , we have the following global constraint:

stateobject group constraint1 ∧ stateobject group constraint2

where

stateobject group constraint1 =

∀so1, so2 : stateobject, sog, sog1, sog2 : stateobject group•(tran rel(so1, so2,M) ∧ so1 ∈ sog1 ∧ so2 ∈ sog2) → (sog1 = sog2)∧(so1 ∈ sog ∧ so2 ∈ sog) → tran rel(so1, so2,M)

stateobject group constraint2 =

∀sog : stateobject group•(∃i : generic start state • i ∈ sog)∧(∀i1, i2 : generic start state • (i1 ∈ sog ∧ i2 ∈ sog) → (i1 = i2))

As this constraint involves the elements of the whole model, it will be very complex to spec-

ify by some attributed EBNF grammar clauses. Therefore, it is specified by a logical formula

in the whole model scope.

Now the intuitive meanings of the above constraint are:

1. If two stateobject are directly or indirectly connected, they belong to the same stateobject group;

If two stateobject belong to the same stateobject group, they are directly or indirectly con-

nected.

2. There is exactly one generic start state in each stateobject group.

Although the problem mentioned in Figure 3.14 still exists in the (generic) statechart with

inter-level transitions, the error can be mechanically checked in the (generic) statechart without

inter-level transitions.


What is more, the new well-formedness rule also implies that

• A stateobject group contains several pure states, transitions and object is.

• A stateobject group at least contains one state or one object i.

• A transition connects two states, two object is, or one state and one object i.

In Fig 2.9 (b) there are 3 stateobject groups: (A′), (B, C, D′) and (S, T, E, F, G). What is

more, a generic start state should be added to each group. In Fig 2.2, there are two stateobject groups

within object i “Controller” at the same hierarchical level: (“Reading”) and (“Init”, “Modify-

ing” and “Monitoring”). Similarly, each group has also a generic start state.

We advocate using the notation of the generic statechart without inter-level transitions. Ex-

cept for achieving a better hierarchical structure, using the generic statechart without inter-level

transitions helps a better “syntactical/static semantical” checking.

In the ADORA language, we can check the existence of the generic start state, when the

notation of the generic statechart without inter-level transitions is used. Therefore, the errors

in Figure 3.14 will be treated as errors of the syntax and statical semantics. And they can be

mechanically checked.

However, for the generic statechart with inter-level transition, this kind of errors will be

considered as an error of the dynamical semantics, and can not be checked mechanically. See

the examples in Fig 2.9a: there are 3 stateobject groups (A), (B, C, E, F , G), (D). It seems

that the first two groups need generic start states, and the last one doesn’t. The existence of

the generic statechart is dependent on the semantics of the diagram. That is why it is nearly

impossible to automatically check this kind of errors in the generic statechart with inter-level

transactions.

In this subsection, we give an example of global constraints in the behavior view. This

example will also be used in the Chapter 6.3, where we talk about the reciprocal influences

between the language definition and language design.

3.4.7 Global Constraints in the User Views

The EBNF grammar of the scenariochart and part of the mapping table is showed in Section

3.3.3 and Figure 2.3.

There are some global constraints in the user view. Some examples will be given as follows.

First we define some meta-functions, which will be used in the constraints.

Let M be an ADORA model with C,D,E : scenario.

• component sce(C,D) is true if and only if Scenario C is a component of Scenario D,

while Scenario C is a normal scenario (I.e. C is in the form of scenario norm: the second

line of the table in Figure 3.3).

• sequence sce(C,D) is true if and only if Scenario C is a component of Scenario D, while

Scenario C is a scenario with a sign of “sequence”. (I.e. C is in the form of scenario seq:


the fourth line of the table in Figure 3.3).

• alternative sce(C,D) is true if and only if Scenario C is a component of Scenario D,

while Scenario C is a scenario with a sign of “alternative”.

• concurrency sce(C,D) is true if and only if Scenario C is a component of Scenario D,

while Scenario C is a scenario with a sign of “concurrency”.

• iteration sce(C,D) is true if and only if Scenario C is a component of Scenario D, while

Scenario C is a scenario with a sign of “iteration”.• The function part of(C,D) is defined in Section 3.4.5. The relationship between C and

D can be one of the five types (c.f. Figure 2.3) specified in the scenariochart:part of(C, D) = component sce(C, D) ∨ iterative sce(C, D) ∨ sequence sce(C, D) ∨

alternative sce(C, D) ∨ concurrency sce(C, D)

Now we give some examples of formal constraints in the user view with their intuitive meanings.

• All relations between a scenario and its component scenarios belong to the same type.

component sce(C,D) → (∀E : scenario • ¬(sequence sce(E,D)∨alternative sce(E,D) ∨ concurrency sce(E,D) ∨ iteration sce(E,D)))

∧ sequence sce(C,D) → (∀E : scenario • ¬(component sce(E,D)∨alternative sce(E,D) ∨ concurrency sce(E,D) ∨ iteration sce(E,D)))

∧ alternative sce(C,D) → (∀E : scenario • ¬(sequence sce(E,D)∨component sce(E,D) ∨ concurrency sce(E,D) ∨ iteration sce(E,D)))

∧ concurrency sce(C,D) → (∀E : scenario • ¬(sequence sce(E,D)∨alternative sce(E,D) ∨ component sce(E,D) ∨ iteration sce(E,D)))

∧ iteration sce(C,D) → (∀E : scenario • ¬(sequence sce(E,D)∨alternative sce(E,D) ∨ concurrency sce(E,D) ∨ component sce(E,D)))

• Circular scenarios-relation is not allowed. That is to say, if Scenario C is a (indirect)

component of Scenario D, D can not be a (indirect) component of Scenario C.

indirect partof(C,D) → ¬indirect partof(D,C)

For example, the scenariochart in Figure 3.16b is not well-formed.

• The scenario chart should be in a form of tree, not graph.

(part of(C,D) ∧ part of(C,E)) → D = E

For example, the scenariochart in Figure 3.16c is not well-formed.

• The sequence numbers of any two sequence scenarios of their super scenario should be

different.

∀D,C,E : scenario • (sequence sce(C,D) ∧ sequence sce(E,D)) →(C.sequencenum �= E.sequencenum)


C

C' C''

C'''

D E

C

C'

C'' D

C'''

a ) b )

C

C' C''

C'''

D E

c )

Figure 3.16: a) A Tree form of Scenariochart; b) A graph form of scenariochart with circu-lar scenarios-relations; c) A graph form of scenariochart with two scenarios sharing the samecomponent.

The complete set of constraints is defined in Appendix E.1.

3.4.8 Some other Global Constraints

Except for the global constraints to graphical model elements, there are also some constraints to

the textual model elements, which need to be specified just as in textual specification/programming

languages.

A typical example in the functional view of ADORA is given as follows.

message ::=

{“receive” message contents “over” a:association |“receive” message contents “from” obj:object |... ... }

The association and the object, which are mentioned in a message, should exist in the model

(they can be hidden or visible). The formal description is as follows.

Let M be the ADORA model being syntactically checked. The formal constraint is:

a ∈ M ∧ obj ∈ M

Actually, there are quite a lot of non-hierarchical global constraints in the ADORA language.

They exist in the behavioral view, the user view, the functional view, etc. They specify both

graphical model elements and the textual ones.

Note that

3.5. EXTENSION ON SUPPORTING THE EVOLUTIONARY SPECIFICATION 101

• this dissertation serves the purpose of introduction of a new language definition method,

instead of giving a complete specification of ADORA; and

• with the introduction of new concepts in the community of software engineering, the

design on the ADORA language evolves too. Especially, Requirement Engineering Re-

search Group in University of Zurich is now intensively working on extending ADORA to

support the mechanisms of aspect oriented specification.

Therefore, in the Appendix and here, a few details on the language definition, such as some

global constraints, which are simple to define and perhaps will be changed in the next version

of the language, are intentionally left open.

3.5 Extension on Supporting the Evolutionary Specification

In Section 2.4, we have defined an extension to ADORA , which supports partial and evolu-

tionary specification. We have also defined an extended semantics in natural language for the

extended language.

Now we think about a set of well-formedness rules for the extended language.

First we need to define the concept of “well-formedness” of the extended languages.

3.5.1 Well-formedness

As mentioned in the last section, an ADORA model is well-formed, if and only if

• it can be successfully parsed by the defined EBNF grammar (c.f. Appendix B); and

• it conforms to the simple context-sensitive constraints, which are defined by attributing

the EBNF grammar (c.f. Appendix B); and

• for all its partial views, they can be derived from a well-formed ADORA model by apply-

ing the operational rules.

Before we define the well-formedness for the extended language, let us first see an example

in Figure 3.17.

The three diagrams show some incomplete specifications in the structural view. From Fig-

ure 3.17a, we don’t know (i) the details of Object X; or (ii) how many other objects and their

properties in Object X . However, no matter how Object X is completely specified in future, the

refined specification can not evolve itself to Figure 3.17a using the available operational rules

in Appendix C. The reason is: both Object C and Object Y don’t have any hidden components;

however, Abstract Relationship oops implies that at least one object of them has hidden compo-

nents. This conflict will not be solved no matter how the surrounding objects, such as Object X ,

are further refined. In a word, Figure 9a can not be a well-formed view, which is transformed

from a well-formed complete specification.


X

√

√

a)

b)

c)

blabla (1,n)

oops (1,1)

X... YA

C

B

blabla (1,n)

oops (1,1)Y...

A

C

B

blabla (1,n)

oops (1,1)

YA B

c ...

X...

X...

Figure 3.17: The first diagram is not well-formed, and the second and third diagrams are well-formed.

Before we give a definition of “well-formedness” for an ADORA+ model based on an in-

complete speciation, we first define a related concept.

A complete structural view is defined as a structural view of an ADORA model without model

elements (e.g. object, object set, etc.) being hidden.

A complete behavioral view is defined as a behavioral view of an ADORA model without

model elements (e.g. state, generic statechart, etc.) being hidden.

A complete user view is defined as a user view of an ADORA model without model elements

(e.g. scenario, scenariochart, etc.) being hidden.

The upper diagram of Figure 2.5a is a complete structural view of an ADORA model based

on a complete specification; while Figure 2.5b is a complete structural view of an ADORA model

based on an incomplete specification. Note that a complete structural view of an ADORA model

based on an incomplete specification should look the same as a partial structural view (in which

some model elements are hidden) of an ADORA model based on a complete specification. This

is the language design principle of our conservative extension on the structural view of ADORA .

Now, the formal definition of a well-formed model is given as follows.

An ADORA model M based on an incomplete specification is defined to be well-

formed when there exists a well-formed ADORA model M ′ based on a complete

specification whose complete structural view, complete behavioral view and com-

plete user view can be transformed into the corresponding complete structural view,

complete behavioral view and complete user view of M by view transitions. The

view transitions in turn are defined in the grammar by the operational rules (c.f.

Section 3.4.4 and 3.4.5 and Appendix C).

Through this definition, we can theoretically determine the well-formedness of an evolu-

tionary specification (c.f. Figure 3.17).

As we achieve a conservation extension in the next several sections, the above definition can

also be simplified as:


... when there exists a well-formed ADORA model M ′ based on a complete spec-

ification whose complete structural view, complete behavioral view and complete

user view can be transformed into the corresponding structural view, behavioral

view and user view of M by view transitions ...

3.5.2 The Conservative Extension in the Structure View

3.5.2.1 The Extended Operational Rules

Our conservative extension should keep the original good features of the language. We extend

the operational rules, which guide the view transition in the structural view of ADORA+ . As

shown in Figure 3.18, the view transitions in ADORA and ADORA+ look very similar (and

actually also “work” very similarly).

In fact, most of the operational rules given in Section C.3 can be applied for the incomplete

specification without any changes. But there are still some differences between two sets of the

operational rules.

• Existence of three model elements in an ADORA model

– In the structural view of an ADORA model, three model elements (abstract relationship,

interrelationship and is-partial indicator) appear in the view, only because some ob-

jects and relationships are hidden. In the model resp. the complete structural view

of the model, they don’t exist at all.

– In the structural view of an ADORA+ model, abstract relationship and is-partial in-

dicator, which record evolutionary information, may exist also in the model and the

complete structural view. Therefore, some rules must be extended or added to cope

with those more general situations.

• Deletion and regeneration of abstract relationships

– In a model based on a complete specification, an abstract relationship does not exist

in the model, but may exist in a structural view. Therefore, if an abstract relationship

should disappear from the current view during the view transitions, it will just be

deleted. Even if the two objects, with which it connects, become visible in future, it

is not necessary to be generated.

– In a model based on an incomplete specification, an abstract relationship may exist

in the model. In an another word, an abstract relationship can be explicitly created

by a user in the model. In Figure 3.18 Γa1 is a complete view based on a complete

specification. In this view, no abstract relationship can exist. Γb1 is a complete view

based on an incomplete specification. In this view, abstract relationships (e.g. u)

may exist. During the view transitions, if it should disappear in the current view, it


will not be deleted from the model, but only from the current view. When the two

objects, with which it connects, become again visible, it must also be visible.

Abstraction. Now we talk about our extension of the operational rules on abstraction. From

the simple example in Figure 3.18, we can see that two view transitions based on a complete

specification and a incomplete specification (from Γa3. to Γa6. and from Γb1. to Γb4. in Figure

3.18) are just the same. This is just what we want to achieve for a conservative extension of our

operational rules.

Nevertheless, some rules have to be changed/added to cope with the extended semantics of

those three language elements.

Z

X A ...

C

Y

B

Z

C

Y

B

X ...

Z

C

Y

BX ...

u

s

ar

s

α

Step a1 Rule "abstract an object" &

Rule "Hide an object"

Step a2 Rule "Abstract a relationship"

Step a3 Rule "Adjust interrelationships"

Z

C

Y

BX ...

ar

s

u

s

a)

Z

X A ...

C

Y

B

Z

C

Y

B

X ...

Z

C

Y

BX ...

u

s

ar

s

α

Step b1 Rule "abstract an object" &


Step b2 Rule "Abstract a relationship"

Step b3 Rule "Adjust interrelationships"

Z

C

Y

BX ...

ar

s

u

s

b)

Z

X A ...

C

Y

Bs

Z

X

A

C

Y

B

t

s

A'

t

Step I Rule "Abstract an object" &


Step II Rule "Abstract a relationship"

Γa1

Γa3

Γa6

Γb1

Γb4

Figure 3.18: Abstracting an object A: a) a view based on a complete specification; b) a viewbased on an incomplete specification.

The example in Figure 3.18 is used to explain our extension of the operational rules.

As the property of “an object being manually partial” is not mentioned at all in the groups

of “Abstract an object”, “Hide an object” and “Adjust interrelationships”, rules in those groups

can be used for the incomplete specification without extension. Their explanation can be seen

in Section 3.4.3.3.


The rules in Group “Abstract a relationship” has to be extended. In order to compare the

original ones with the extended one, we list all the rules of this group, which are related to the

example in Figure 3.18 .



Given: M ; Γ; X : object i; A, B : object; r(A, B) : association

Condition: (A.pre � X.pre) ∧ hidden(A, Γ) ∧ visible({B, X, r(A, B)}, Γ)Assertion: hidden(r(A, B)) ∧ ∃ar : abstract relationship • (ar(X, B) ∈ Γ) ∧

visible(ar, Γ) ∧ ∀z : abstract relationship¬∃α : interrelationship • α(r, z) ∈ ΓNext Rule: Adjust interrelationships (ar)


Given: M ; Γ; X : object i; A, B : object; u(A, B) : abstract relationship

Condition: (A.pre � X.pre) ∧ hidden(A, Γ) ∧ visible({B, X}, Γ) ∧ u(A, B) ∈/ M ∧ u(A, B) ∈ ΓAssertion: u(A, B) ∈/ Γ ∧ ∃ar : abstract relationship • (ar(X, B) ∈ Γ) ∧

visible(ar, Γ) ∧ ∀z : abstract relationship¬∃α : interrelationship • α(u, z) ∈ ΓNext Rule: Adjust interrelationships (ar)

Rule Abstract a relationship : incomplete specification (A)

Given: M ; Γ; X : object i; A, B : object; u(A, B) : abstract relationship

Condition: (A.pre � X.pre) ∧ hidden(A, Γ) ∧ visible({B, X}, Γ) ∧ u(A, B) ∈ M ∧ u(A, B) ∈ ΓAssertion: u(A, B) ∈/ Γ ∧ ∃ar : abstract relationship • (ar(X, B) ∈ Γ) ∧

visible(ar, Γ) ∧ ∀z : abstract relationship¬∃α : interrelationship • α(u, z) ∈ ΓNext Rule: Adjust interrelationships (ar)

. . . . . .

The first rule in Group “Abstract a relationship” specifies the following three points: (i) after

object A is hidden, any association connecting with A should also be hidden in the view; and

(ii) an abstract relationship ar connecting with X , in which A is directly embedded, should be

automatically generated in the view (note that only in the view, not in the model); and (iii) any

interrelationship should be deleted from the view. This rule is applied in Step II in Figure 3.18a.

The second rule in Group “Abstract a relationship” specifies also three points. The last two

points are the same as the first rule. The first one is different, and it says: after object A is

hidden, any abstract relationship, which connects with A and does not belong to the model (i.e.

it was automatically generated.), should also be deleted from the view. It is applied in Step a2

in Figure 3.18a.

The above two rules are the original ones for the complete specification. However, they are


not adequate to deal with the situation of the incomplete specification (c.f. Step b2 in Figure

3.18b). Therefore, a third rule, to whose name a syntax sugar “incomplete specification”

is appended, needs to be added in Group “Abstract a relationship”. The first point of this rule

specifies: after Object A is hidden, any abstract relationship, which connects with A and belongs

to the model (i.e. it is manually generated from users.), should also be hidden in the view (note

that it should not be deleted.). The other two points are the same as those in the first two rules.

Note that u ∈ M holds before and after applying this group of rules.

Concretization. There are more changes on the operational rules of “concretization”. They

will be explained through an example in Fig 3.20. Note that the specifications with complete

structural views are given in Fig 3.19.

a) A complete Specification with a complete structural view

Z

X

A

C

Y

B

t

s

A'

Z

X A ...A ...

C

Y

B

u

s

b) An Incomplete Specification with a complete structural view

Figure 3.19: The specifications with complete structural views

Y

B

Y

B

Y

Bs

Step 1 Rule "Concretize an object" & Rule "Show an object" & Rule "Delete objects' partial signs"

Step 2 Rule "Adjust abstract a relationship"

Z

C

X ...a

ar

s

Z

X

A ...

C

a)

Z

X

A ...

Cα

ar

s

Y

B

Y

B

Y

B

Step 1 Rule "Concretize an object" & Rule "Show an object" & Rule "Delete objects' partial signs"

Step 2 Rule "Adjust abstract a relationship"

Z

C

X ...a

ar

s

Z

X

A ...

C

b)

Z

X

A ...

Cα

ar

s

s

u

u

u

Figure 3.20: Concretizing an object A : a) a view based on an complete specification; b) a viewbased on a incomplete specification

First we list two extended meta-functions. Let M be an ADORA model with X : model element;

A,B,C,D,E, F : object; r : association; ar, u, u1 : abstract relationship; and let Γ be a

partial view of M .

• inbetween(ar(A,B), u(C,D), u1(E,F ), Γ) is a boolean function that is true if and only

if


– ar � u ∧ ar ∈ M ∧ ar ∈/ Γ, and

– u ∈ Γ ∧ u1 ∈/ Γ, and

– visible({E,F}, Γ), and

– If we added u1 into Γ, r � u1 � u would be true.

In this case, function “inbetween” is overloaded, such that it can also be used in our

extended langauge.

• abs rel(ar(A,B), u(C,D), Γ) is a boolean function that is true if and only if

– ar ∈/ Γ ∧ ar ∈ M is true, and

– u ∈/ Γ, and

– visible({C,D}, Γ), and

– If we added u into Γ, ar � u would be true.

– there exists no u1 in Γ, such that ar ⊃ u1.

Compared with the original meta-functions 6, the first parameters of those two functions are

abstract relationships, instead of associations. The intuitive meanings of those two extended

functions are nearly the same as the old ones. The reason for introducing these two functions is

that a manually added abstract relationship behaves somehow similar to an association. When

two objects connecting that abstract relationship are visible, this abstract relationship must also

be visible.

Now we give the rules used in the example in Fig 3.20.

As there are no changes on rules in the groups “Concretize and object” and“Adjust interre-

lationship” for the part of object concretization, rules in those two groups will not be showed

here. The view transitions based on a complete specification and an incomplete specification in

those two steps are exactly the same.

We need to extend the rule in the group “Show objects and associations”.

6For simplicity, we do not explain the meta-function of abs rel in Section 3.4.3.2. Please refer to Appendix Cto see the formal definition.





Condition: hidden(A, Γ) ∧ ¬abstracted(A, Γ)Assertion: ∀B : object • (B ⊆ A) →

(visible(B, Γ) ∧ ¬abstracted(B) ∧ (∀C : object•((∀r : association • (r(B, C) ∈ Γ ∧ visible(C, Γ)) → visible(r, Γ))∧ ∗(∀ar : abstract relationship • (ar(B, C) ∈ M ∧ visible(C, Γ)) → ar ∈ Γ)))∧ ∗ ∗(∀D : object • (D⊇B) →(visible(D, Γ) ∧ (∀C : object•((∀r : association • (r(D, C) ∈ Γ ∧ visible(C, Γ)) → visible(r, Γ)) ∗(∀ar : abstract relationship • (ar(D, C) ∈ M ∧ visible(C, Γ)) → ar ∈ Γ)))))) ∗ ∗

Next Rule: Delete objects’ partial signs (A)

The clauses with “∗” are used to handle the ADORA model without the extension on sup-

porting the partial and evolutionary specification, and the clauses with “∗∗” are extended to

handle the manually generated abstract relationships. In the second diagram of Fig 3.20 (b), u

is generated because of the above rule.

Delete objects’ partial signs

Rule Delete objects’ partial signs (A)


Condition: true

Assertion: ∀B : object • (related(B, A,Γ)∧(¬∃C : object • hidden(C, Γ) ∧ (C � B) ∧ (¬man g partial(B, M)) → ¬partial(B, Γ)))


In the group “Delete objects’ partial signs”, one rule needs to be added. The newly defined

rule adds a meaning, which says if an object is manually made as partial, the three dots will be

kept after the name of object, even when all its embedded objects are visible in the view.

These two rules are used in Step 1 of Figure 3.20b. Let us see the next step. For the incom-

plete specification, we need to extend the first two rules in the group “Adjust abstract relationships”.


Adjust abstract relationships



Condition: related(ar, A, Γ) ∧ (¬∃r : association • hidden(r, Γ) ∧ (r � ar))∧(¬∃ar3 : abstract relationship • (ar3 ∈/ Γ) ∧ (ar3 ∈ M) ∧ (ar3 � ar))∧ ∗ ∗(¬∃r1 : association, α : interrelationship • α(r1, ar) ∈ Γ)∧ ∗(¬∃ar1 : abstract relationship, α : interrelationship • α(ar1, ar) ∈ Γ ∨ α(ar, ar1) ∈ Γ)

Assertion: ar ∈/ ΓNext Rule: Adjust interrelationships (A)


Given: M ; Γ; A : object; r : association; ar : abstract relationship∧Condition: related(ar, A, Γ) ∧ (¬∃r : association • hidden(r, Γ) ∧ (r � ar))∧

(¬∃ar3 : abstract relationship • (ar3 ∈/ Γ) ∧ (ar3 ∈ M) ∧ (ar3 � ar))∧ ∗ ∗((∃r1 : association, α : interrelationship • α(r1, ar) ∈ Γ)∧ ∗(∃ar1 : abstract relationship, α : interrelationship • α(ar1, ar) ∈ Γ ∨ α(ar, ar1) ∈ Γ))


Next Rule: Adjust interrelationships (A)

In the above two rules, the clauses with ∗ exist in the original rules to handle the original

ADORA models. The clauses with ∗∗ are extended to handle the extended ADORA models

(especially the manually added abstract relationships). The reason for introducing these two

clauses with ∗∗ are exactly the same as the extension of the meta-functions and the rules in

the group “Show objects and assoications”: a manually added abstract relationship behaves

somehow similar to an association. Therefore, a manually added abstract relationship should

also be treated as an association. These two rules guide the view transition in Step 2 of Figure

3.20b. The second rule is first applied to delete Interrelationship α, and the first rule is then

applied to delete Abstract relationship ar.

3.5.2.2 Merits

Most of original operational rules can be reused. Fewer than 10 rules need to be modified or

added to make the new set of operational rules applicable in the extended ADORA. The strict

formal definition and corresponding detailed explanations can be found in Appendix D.

Now we summarize the merits of our extension:

• Just introducing some new constructs to support evolutionary specification is not too dif-

ficult. However, every extended construct should be carefully validated to make sure that

they are really acceptable to users. Here, we achieve a smallest extension: instead of


introducing new constructs, we extend the semantics of the original constructs to make

the extended ADORA support evolutionary specification.

• We also get a conservative extension. That is to say, our extension satisfies the following

two criteria:

– For the extended operational rules, if we throw away the parts relating to the evo-

lutionary specification, they are the same as, or at least totally consistent with the

original rules in Appendix C.

– The result of view transitions of applying the extended rules to a specification with-

out any extended constructs is the same as that of applying the original rules.

Therefore, the original good features (e.g. the mechanism of hierarchical decomposition)

and the original (static) semantics (e.g. the operational rules) are maximally kept. And

the extension causes no conflicts on both syntax and semantics with the original language.

• Based on our formal definition, the evolutional changes are traceable. That is to say,

important evolutionary information (e.g. the effects of adding or deleting an is-partial

indicator in an object with a rather high-level system abstraction) is formally specified

and documented in the extended ADORA models, which can be exploited in the further

refinement of the models by applying our refinement calculus (c.f. Chapter 5).

3.5.3 The Conservative Extension in the Behavior View

As what we have done in the structural view, we also want to achieve a conservative extension

here. The operational rules for view transition for the behavioral view are much easier, so is the

extension. We need only to slightly modify 3 rules in two groups.

In the group “Hide statecharts inside a state/object”, we add an extra condition.

Hide generic statecharts inside a state/object



Condition: ¬partial(SO, Γ)∨(partial(SO, M) ∧ ∃SO1 : stateobject • (SO1.pre ⊃ SO.pre) ∧ visible(SO1, Γ))

Assertion: partial(SO, Γ) ∧ ∀SO3, SO1, SO2 : stateobject, t : transition•((SO3.pre ⊃ SO.pre) ∧ (hidden(SO3, Γ)))∧((SO1.pre ⊃ SO.pre) ∧ (SO2.pre ⊃ SO.pre)∧(t(SO1, SO2) ∈ Γ) ∧ (hidden(t(SO1, SO2), Γ)))

Next Rule: ∅

The original rule is:



Given: ...

Condition: ¬partial(SO, Γ)Assertion: ...

Next Rule: ...Let us look at the example in Figure 3.21

S1

S3 S4

S2

S5 S6

...

...S1 ...S2

a) Statecharts inside State S1

is abstracted in the original ADORA Model.

b) Statecharts inside State S2

is abstracted in the extended ADORA Model.+

a1

a2

b1

b2

Figure 3.21: a) View transitions in the Behavioral View of an original ADORA model; b) Viewtransitions in the Behavioral View of an extended ADORA+ model

Note that Diagram b1 is not well-formed in the original ADORA model. However, it is well-

formed in our extended language, which means that S2 will be further refined. Some statecharts

will possibly be added into S2, although there are already some components inside S2.

Therefore we conservatively extend our rules by adding an extra condition, whose intuitive

meaning is: if the is-partial indicator is manually added to a stateobject, we can also abstract

the embedded generic statecharts inside that stateobject.

Similarly we also need to modify the original rule in Group “Show states/objects inside a

state/object” and add a rule there.

Show states/objects inside a state/object



Condition: partial(SO, Γ) ∧ (¬partial(SO, M))Assertion: ¬partial(SO, Γ) ∧ ∀SO1 : stateobject•

((SO1⊇SO) ∧ visible(SO1, Γ))Next Rule: Show transitions inside a state (SO)

In this rule, the only difference is that in the Condition item, add a constraint, which ex-

plicitly says that SO is partial and the is-partial indicator is not manually added. I.e. this rule

covers the situations in the original ADORA model.




Condition: partial(SO, Γ)∧(partial(SO, M) ∧ ∃SO1 : stateobject • (SO1.pre ⊃ SO.pre) ∧ hidden(SO1, Γ))

Assertion: ∀SO1 : stateobject•((SO1⊇SO) ∧ visible(SO1, Γ))

Next Rule: Show transitions inside a state/object (SO)This rule covers the situations in the extended ADORA+ model. Just as shown in Figure 3.21b,

the hidden statecharts will be visible again and the is-partial indicator will be kept nevertheless.

It can be easily proved that our extension is conservative.

3.5.4 The Conservative Extension in the User View

As what we have done in the structural view and the behavioral view, we also want to achieve

a conservative extension in the user view. The extended operational rules for view transition

are as simple as those in the behavioral view. We need only to slightly modify the rules in the

groups “Hide the components of a scenario” and “Show the components of a scenario”, and add

a rule in Group “Show the components of a scenario”.

As the explanations of this extension are nearly exactly the same as those in the behavioral

view, here we only list the extended rules.

Hide the components of a scenario

Rule Hide the components of a scenario (Sc)

Given: M ; Γ; Sc : cenarios

Condition: ¬partial(Sc, Γ) ∨ partial(Sc, M)Assertion: partial(Sc, Γ) ∧ ∀Sc3, Sc1, Sc2 : scenario, c : connection•

((Sc3.ispart ⊃ Sc.ispart) ∧ (hidden(Sc3, Γ)))∧(((Sc1.ispart ⊇ Sc.ispart) ∧ (Sc2.ispart ⊃ Sc.ispart)∧(c(Sc1, Sc2) ∈ Γ)) → (hidden(c(Sc1, Sc2), Γ)))

Next Rule: ∅

Show the components of a scenario



Condition: partial(Sc, Γ) ∧ (¬partial(Sc, M))Assertion: ¬partial(Sc, Γ) ∧ ∀Sc1 : scenario•

((Sc1⊇Sc) ∧ visible(Sc1, Γ))Next Rule: Show connections of the components of a scenario (Sc)

3.6. A SHORT SUMMARY 113



Condition: partial(Sc, Γ) ∧ partial(Sc, M)Assertion: ∀Sc1 : scenario • ((Sc1⊇Sc) ∧ visible(Sc1, Γ))Next Rule: Show connections of the components of a scenario (Sc)

Similar to the extension in the behavioral view, it can be easily proved that our extension is

conservative.

3.6 A Short Summary

Now we shortly summarize what we have done in this Chapter.

Mapping First we use a sophisticated mapping technique to translate ADORA into an equiva-

lent textual language (here called “T-ADORA”). If we defined the syntax of this textual

language, with the reverse mapping, we also have the syntax of ADORA (the visual one).

Therefore, in the following steps, we only concentrate only on the syntax of T-ADORA.

Context free syntax An EBNF grammar is used to describe the context free syntax.

Static semantics As discussed in Section on “Syntax vs. Semantics”, static semantics in this

thesis is also called context sensitive syntax.

Simple static semantics The constraints in the simple static semantics involve only a

few language elements. Therefore, they can be described by constraint attributes of

the EBNF grammar.

Complex static semantics Some constraints are very complex such that they can not be

described in a single EBNF grammar clause. Those constraints describe the relations

of lots of language elements of the whole ADORA model, and therefore are also

called global constraints. Complex static semantics are specified in the following

ways.

• A first order logic formula is used to describe the simple global constraints.

Actually, the attributes in the attributed EBNF grammar are also written in a

first order logic. The differences are: in attributes, the logic variables are re-

stricted only to the model elements, which appears in that attributed EBNF

clause; while in global constraints, the logic variables involve the whole model

elements.

• Operational rules are used to describe the complex global constraints (such as

view transitions). Operational rules are in essence a serial of first order logic

formulae, which in pre- and post-condition forms. They make complex well-

formed rules easily readable and implementable.


More discussion on readability and implementation of the operational rules will

be in Chapter 7.

Conservative extension The syntax and static semantics, especially the operational rules, are

conservatively extended here to support the extended language features supporting partial

and evolutionary specification.

In the next two chapters, we talk about the dynamic semantics of ADORA, and the refinement

calculus based on the static and dynamic semantics.

Chapter 4

Dynamic Semantics

For any useful language, a semantics definition is indispensable work. For any language, at

least a semantics using natural language should be assigned to the language syntax.

4.1 Our Strategy

The advantages of using formal semantics are unquestionable. However, a totally formal se-

mantics for the complete syntax of a wide spectrum visual language may still be unsuitable,

because of the following reasons:

• Today’s computers are not powerful enough to handle the complex semantics and mathe-

matical rules. For instance, computers are of little help for the mechanical verification of

large systems. The computational model stays the same as that of 50 years before.

• Computer science is still not developed enough. And the computer professionals are still

at the level of craftsmen, instead of engineers.

However, we can also see some very successful application of formal methods, such as the

model checking in the field of hardware design. Based on the above thoughts, we give our

strategies of semantics definitions.

4.1.1 Using the Methods of Textual Languages

The methods, such as visual operational rules and diagrammatic reasoning, are introduced in

some papers to give semantics to visual programming languages. As it is even more difficult to

define semantics for specification languages than to do those for programming languages, the

semantics given in the above methods for visual specification languages will be very difficult to

read and understand.

In our method, after mapping the visual specification language to an equivalent textual visual

language, we can apply the same semantics definition methods used in textual visual languages

115

116 CHAPTER 4. DYNAMIC SEMANTICS

to that mapped textual visual language and hence to the target visual specification language.

That is to say, a semantics is first assigned to the textual elements and operators. After this

assignment, it is also assigned to the corresponding target visual constructs through the reverse

mapping.

All the methods of giving semantics to the textual specification languages can be used in

our methods with few adjustments.

4.1.2 Assigning the Formal Semantics to Simple Sublanguages

The wide spectrum visual specification languages, such as ADORA and UML, are usually com-

posed of a set of tightly or loosely coupled simple visual languages. For example, UML is

composed of class diagram, statechart, sequence diagram, etc. ADORA integrates all aspects

of the system into one coherent model. However, views can be generated from that integrated

model pertaining to a specific aspect. Each view is actually a simple sublanguage, such as

statechart, object diagram and scenarios-chart.

After we discuss how we should define the semantics, we should also think of the following

problems:

1. Should we define a formal semantics for the whole syntax?

2. If not, which part should be formally defined? And how should they be defined in an

understandable way?

The meanings of the formal semantics are threefold:

1. For the language designers themselves: giving a formal semantics helps language design-

ers to find potential semantic conflicts among the language constructs.

2. For the readers: a unambiguous formal semantics helps users to master the languages.

3. For the users: based on formal semantics, a set of formal verification and refinement rules

can be deduced. Therefore, users can do the formal verification and formal refinement,

when they use this language to develop a software system.

Point 1 is theoretically valid. Formalizing the language definition forces us to think about

the problems in ways that we would not otherwise have to. And hence, it is easier to find

potential problems. However a very large language will result in a very complicated formal

semantics, which makes the checking of semantic conflicts almost impossible.

Point 2 and Point 3 are only valid for simple visual specification languages (e.g. statechart,

etc.). Even for a wide spectrum textual specification language, the formal semantics will be

very complex. A typical example is that a denotational semantics for RSL occupies more than

320 A4 pages [49] [2]. Few people will read such a complex semantics. The verification rules

and refinement rules are very difficult to be deduced from that semantics.

Visual specification languages are even more complex than textual specification languages.

Giving a formal semantics to the complete syntax of a wide spectrum visual specification lan-

4.1. OUR STRATEGY 117

guage does not help readers to understand the language, and is not useful for future formal

verification and refinement.

We have a lot of successful examples of the application of formal methods on some small

visual specification languages, such as the Buchi Automata [3] in model checking, etc. The

inferences from such examples are: formal verification and formal refinement can also only

be fulfilled by using simple languages, and mechanical verification is only possible for simple

languages. In our method, we only give the formal semantics to each simple sublanguage (e.g

statechart in ADORA ). The reasons for this are:

• A formal semantics for a wide spectrum visual language is certainly too difficult to give.

Even when we have a formal semantics, it is too long and complex for people to under-

stand. It may not help a lot on checking the consistency of all the language constructs.

• Giving a formal semantics to the whole specification language will not help the verifica-

tion and refinement work anyway, because the rules of verification and refinement can be

too complex for human beings and computers to apply in industry.

• On the other hand, when we design the critical parts of the system, we should only use

a restricted sublanguage, which has a formal, understandable and applicable semantics.

And then we can do some efficient formal refinement and verification works.

In fact, even for the simple sublanguages, we should only define the formal semantics for

the core syntax, to make sure that the semantics is concise enough to actually be applicable.

For each simple sublanguage of UML, there are lots of mature methods on semantics defi-

nition in literature [71]. As mentioned previously, each aspect view of ADORA can be thought

of as a sublanguage of ADORA , and its semantics definition is not far from the semantics defi-

nition of a UML sublanguage or other simple graphical modelling languages. Therefore, in this

dissertation we omit the concrete semantics definition for a simple sublanguage of ADORA.

4.1.3 Model Integration

The ADORA language can be thought of as a language with a set of tight coupled sublanguages.

The advantages of this type of languages are: the model set up using a language with tight

coupled sublanguages is easier to check the potential conflicts among its sub-models.

However, for this type of languages, we need to think of the problem of model integration

in the language definition.

Our approach defines a formal semantics to each sublanguage separately. ADORA is a

language, which consists of a set of semantically tight coupled sublanguages. When those

sublanguages are integrated together, how can we make sure that there are no conflicts among

the constructs and operators of each sublanguage? What is the semantics of this “integration”?

A formal semantics for those integrating mechanisms should also be defined, in order to

check the potential conflicts.


4.1.3.1 Integration Semantics

As mentioned previously, one advantage of ADORA over UML is that ADORA provides the

mechanism to check the consistency among different types of aspect views. The integrity check-

ing is not only at the application level (model level), but also at the language level (metamodel

level). Due to the limit of space, here we will only show three examples of the integrity check-

ing.

• Conflicts between two aspect views.

WB

C *

1DY

2EX

Figure 4.1: An illegal integration of a scenariochart and a generic statechart.

In the above example, Scenario C can be decomposed into two sequentially executed sub-

scenarios: first D then E. At the same time, in Object W there is a generic statechart,

where Object X precedes Object Y . This brings a conflict on the temporal order of

Scenarios D and E, which should not be allowed.

• Violation of the modularity. A good modularity brings lots of advantages to software de-

Figure 4.2: Integration of a scenariochart into an object hierarchy.

velopment. It also guarantees the principle of Information Hiding. Therefore, we design

our language in a way such that good properties in software engineering can be kept as

many as possible in an ADORA model.

Suppose that Scenarios S is embedded in Object O. A sub-scenario S′ of S (S ′ describes

part of the scenario of S) should and must be embedded in Object O or a component of O.

In the above example, Scenario F in Object Y , which is not a component of W , destroys

the principle of a good modularity.


The property of modularity also guarantees that the principle in the ADORA language

design: “during the navigation of the ADORA model in the hierarchy of objects, states

and scenarios, the most important information should always be kept”. That is to say,

except type hierarchy, the referential semantics in the form of “pop-up” windows should

be avoided. During the integration, the hierarchy of scenariochart should share the same

styles, e.g. fisheye style, the style of hierarchical decomposition, in the object diagram

and the generic statechart.

In Section 5.3, we will further explain the problems mentioned in the above two examples.

• Clashes of different views.

As we know, between two objects there can exist both associations and transitions. And

the operational rules for hiding/showing an object are different in the structural view and

in the behavioral view. This causes some problems.

Some constraints, which solve this kind of clashes, in the integration semantics of ADORA

are:

– An ADORA view can be a combination (i) of base views, structural views, user

views and context views; or (ii) of base views and behavioral views; or (iii) ...

– Behavioral views and structural views are not allowed to be combined in a single

ADORA view.

Here we use an example to explain why in the current version of ADORA, we need the

constraint that behavioral views and structural views are not allowed to be combined in a single

ADORA view.

Suppose we have a complete model in Figure 4.3a, in which the structural view and the

behavioral view is shown together.

• When we abstract object A, A and association r will be hidden and an abstract relation-

ship ar will be generated. However, A is a part of a statechart. When A is hidden, the

visibility of all other language elements, which are in the same stateobject group, should

be changed correspondingly. We have two solutions.

1. All transitions in the same stateobject group as A becomes invisible, while all other

language elements are kept unchanged (c.f. 4.3b).

This solution also has a drawback. In many models, showing some states (also some

objects) is only meaningful when a complete statechart is shown. For example, the

states S and T bring nearly no information to users in Figure 4.3b.


2. All language elements in the same stateobject group as A becomes invisible. At

the same time, the visibility of language elements related to the elements in that

stateobject group should be changed correspondingly. For example, in Figure 4.3d,

association s will be hidden and an abstract relationship as will be generated.

The drawback of this solution is clear. When we just want to abstract an object X ,

too many other states and objects, which are independent from X from the view of

system structure, may also be affected.

• When we want to abstract generic statecharts inside object O (i.e. we want to abstract

some behavioral information), we also have two solutions. One is shown in Figure 4.3c:

objects in the generic statecharts inside object O should be kept unchanged, such that

some structural information still remains in the diagram. The other solution is shown in

Figure 4.3d. Again, both solutions have their own advantages and disadvantages.

A

S T

a/st

OB C

D

a)

S T

O ...C

D

b)

B

A

O ... B C

D

c)

O ...C

D

d)

r

s

s

s

r

ar

ar

as

Figure 4.3: Classes of the structural view and the behavioral view.

During the language design of ADORA , the following should be considered:

1. Do we really need to combine the structural view and the behavioral view in a single

view?

2. If yes, which solutions we should adopt, when the problems mentioned above appear?

Actually, we consider the problem of view clashes not as a language definition problem, but

as a language design problem, which can only be solved through the language validation (c.f.


Section 6.3). Note that the ADORA langauge is still evolving (e.g. Requirement Engineering

Research Group in University of Zurich is now intensively working on extending ADORA to

support the mechanisms of aspect oriented specifications.) In the next version of ADORA, we

may cancel this constraint and allow the integration of behavioral views and structural views.

From the view of language definition, most of our operation rules on the structural and the

behavioral views can be reused. Some slight changes on our operational rules are needed, such

that two sets of rules can be intertwined in a reasonable way.

4.1.3.2 Integration Semantics vs. Refinement Calculus and Verification Rules

Integration semantics covers the semantics on the integration of two or more different aspect

views in ADORA (e.g. the scenariochart and the generic statechart, the generic statechart and

the object diagram, etc.).

Usually, the semantics is formally defined in a form, in which the meanings of language

constructs are easy to understand. Then a refinement calculus or verification rules are derived

from that formal definition. Derivation process makes the refinement calculus or verification

rules repeat parts or the whole information of the semantics definition.

On the other hand, the refinement calculus or verification rules are defined in a form, in

which logic and algebraic inferences are easy to carry out. When the semantics is not difficult

to understand, it can also be directly defined in the form of refinement calculus or verification

rules.

In this chapter, we will not give the formal definition of the integration semantics of ADORA.

As an alternative, the integration semantics will be defined in the form of a refinement calculus

in Chapter 5.

4.1.4 Model management

Definition of an integration semantics may not be necessary for a wide spectrum specification

language with a set of loosely coupled sublanguages, such as UML. However, there is only

very weak semantics specifying the relations and constraints among the sublanguages. In [56],

a short section called “Model Management” describes that weak semantics. From the view of

semantics definition, it is much easier to define those weak semantics than to define the integrity

constraints mentioned in the last section.

Formal semantics for model management may even be unnecessary, as few conflicts among

the elements of different sublanguages need to be checked from the view of language design.

In essence, the integrity checking and consistency checking among the sub-models are not

supported at the language level in UML. They can be only done at the application level. The

disadvantage is obvious: the model, which is set up using a language with loosely coupled


sublanguages, such as UML, is hard to check the potential conflicts among its sub-models.

4.2 Remarks

Our strategy for semantics definition of a wide spectrum graphic specification language can be

described in the following three steps.

1. Derive a corresponding textual specification language (TSL) through a mapping table to

and define a syntax and syntactical constraints/static semantics on that TSL.

2. Define dynamic semantics to each sublanguage using the existing methods for simple

graphical modelling languages.

3. Define an integration semantics among those sublanguages for a language with a set of

tight coupled sublanguages, such as ADORA.

4. Define model management for a language with a set of loosely coupled sublanguages,

such as UML.

One limitation of the integration semantics is that it mainly describes the static constraints

among the sublanguages. Therefore, many application-dependent properties, which specify

the interrelations of submodels and involve the dynamic semantics, cannot be formally proved

based on that integration semantics (or more exactly on the refinement calculus or verification

rules derived from the integration semantics).

A common semantic base: in literature there is another approach on definition of a wide spec-

trum graphic specification[21]. The idea is: if the semantics of all the sublanguages are defined

in a common notation, the following two aims can be achieved:

• the constraints on the language elements of different sublanguages can be specified by

this common notation;

• during the future system development, the possible conflicts among sub-models, which

are written in different sublanguages, can be checked, when a common semantic base is

theoretically provided. What is more, based on the common semantic framework even

some “model checking” algorithms can be theoretically constructed.

As we mentioned before, the wide spectrum specification languages are so complex that

giving a complete semantics to the whole language with a unified notation is nearly impossible.

Even when we achieve such a semantics, few can understand it, let lone use it.

Nevertheless, this approach is still feasible if we have reasonable definition methods. Here

we give a possible one, which is described in the following steps.

1. As we know, software systems used in different fields or domains are quite different, a

wide spectrum specification language can be used to describe all kinds of those applica-

tions. However, a formal semantics definition does not necessarily cover all aspects of

4.2. REMARKS 123

the language. That is to say, we can define different semantics to a language, when it is

used in a different domain.

2. In a certain domain, some properties of the application system are very important, which

we would like to formally, or even automatically, prove. Then only a part of semantics

relating to those properties is needed to be given to all sublanguages. This makes seman-

tics much simpler, from which we can derive applicable refinement and verification rules

and even algorithms checking those properties.

Some research results, such as [21], show the above approach is quite promising, though

there are still lots of open problems. Note that in this method, the language definition (at least

the semantics definition) is also related to the domain of applications, which will be specified

by that language.

In summary, we list the following points:

• A semantics with natural language is not enough. There are two reasons: (i) natural lan-

guage itself is not precise enough to define a semantics of a language; (ii) and a semantics

defined by natural language does not help the consistency checking of the language itself.

It does not provide any theoretical base of further development of a refinement calculus

and verification rules for the language. The latter is important when the language is used

to develop some safety critical system or the critical part of a usual application system.

• Compared with natural language, some semi-formal definitions (such as metamodeling)

are much better. A graphical model of the language (the metamodel) helps users under-

stand syntax, syntactical constraints / statical semantics, and dynamical semantics of the

language. The definition is more systematical and understandable. However, the defini-

tion using metamodeling technique is not totally formal, and therefore, it does not directly

provide a theoretical base on development of refinement and verification rules of the sys-

tem. The semi-formal definition methods still cause some ambiguities on the meanings

of languages.

• As mentioned before, a formal semantics for a wide spectrum specification language is

not only difficult to define and understand, but also not very meaningful, as the formal

refinement and verification rules are difficult to be derived from that complex definition.

Defining a formal semantics to sublanguages separately is a good choice. Actually only

the most critical parts of the system can afford the price of formal refinement and verifi-

cation due to their complexity. Those parts are usually specified by a single sublanguage

instead of the whole language. In this sense, defining semantics to sublanguages sepa-

rately is practically sufficient.

Actually most existing papers in literature on semantics definition for UML [71] only

concentrate on one sublanguage.

• The sublanguages of a wide spectrum graphic specification language are not totally in-


dependent from one another. An integration semantics should be given to describe the

inter-relations and constraints of the language elements among different sublanguage. It

is especially important for the language with a set of tight coupled sublanguages.

• A common complete semantics to all the sublanguages is too complex. However, a com-

mon partial semantics to all the sublanguages is still a good alternative. In this case, only

a few aspects will be specified in the semantics definition.

Chapter 5

Refinement Calculus

Though refinement calculi were originally introduced for programming languages (c.f. Section

1.4.7), they are now increasingly used in specification languages.

A refinement calculus is a notation and set of rules for correctly:

• deriving a detailed specification from an abstract one, or

• deriving a program from a specification.

As mentioned previously, the formal syntax and semantics definition of languages brings

two major advantages:

• Giving a precise definition of the languages. This helps users to learn and use the lan-

guages.

• Formal Refinement Calculi and Verification Rules can only be set up, when the formal

syntax and formal semantics are first defined. Language is the medium to describe and

implement software systems, while refinement calculi and verification rules provide a

solid base for the development process. The formal definition of syntax, semantics and

refinement calculi/verification rules are essential, when the languages are applied in the

development of the safety-critical software systems.

There are three kinds of refinements, which are carried out during the following different

software development phases.

• After requirements elicitation, users and developers only have very rough ideas about the

system. The topics of this phase of software development are generally what functions

are needed in which modules. How those modules are designed will not be discussed.

During this refinement process, a highly abstract function in a module will be delegated

to several less abstract functions in sub-modules. There are still no design concerns in the

sub-modules.

• Refinements are also applied, when we work on the architecture design based on our

requirements analysis. At this point, some general design principles need to be decided.

• Refinements are also very useful tools for derivation of a detailed design of the system

125

126 CHAPTER 5. REFINEMENT CALCULUS

from a architectural design.

As ADORA is mainly used for analysis and description of the system requirements and ar-

chitecture, refinement calculus is mainly proposed for these two kinds of refinements. Actually,

the core ideas of hierarchical decomposition in ADORA are also very close to the concepts of

these two kinds of refinements here. What is more, the formally defined static semantics and

integration semantics serve as a sound base for the these refinements.

The rules of the last kind of refinement can only be given, when we have a formal dynamic

semantics. As we mentioned in Chapter 4, a formal dynamic semantics for a wide spectrum

specification language is not very meaningful. It should only be given to sublanguages of that

wide spectrum language. Therefore, in most cases, a refinement calculus for the third develop-

ment phrase is only defined for sublanguages, instead of the whole wide spectrum specification

language. And hence this part of refinement will not be the focus of this dissertation.

There is much work on refinement calculi for a simple graphic modelling language [6][59].

By the way, in the literature, there is also another classification on refinements: structural

refinement and behavioral refinement. Structural refinement focuses on the structure of the

system and its subsystems. It details the internal structure of each refined module. Most of the

work in the first two kinds of refinement belongs to structural refinement. Behavioral refinement

details the behavior of the system components. Most work in the last kind of refinement belongs

to behavioral refinement.

5.1 Refinement Calculus in the Structural View

Our extended language fits the typical ”top-down” approach of software development and sys-

tem refinement. As ADORA+ is compositional, the objects, which specify the general structure

of (sub-)systems, can first be defined and viewed as a composition of several black box com-

ponents. Then they will be filled in with the relationships and objects describing more details.

Again those newly defined relationships and objects need to be refined to the full detail level.

During this process, we want to trace evolutionary changes and record the impact of the

refinement. Therefore, the is-partial indicators and the abstract relationships will be used to

specify evolutionary information, when an object or a relationship between objects is unclear at

the current phase.

In order to specify an evolutionary system in a controlled way, a refinement calculus is pro-

posed here. Compared with UML, the characteristic, integration of all aspects of the system

in one coherent model, makes ADORA a set of tightly coupled sub-languages (if the aspect

views are considered as sub-languages). The well-formedness rules can syntactically and se-

mantically reduce the conflicts among the different aspects views. Especially for evolutionary

specifications, they also guarantee the integrity of a system. Therefore, we should always keep

5.1. REFINEMENT CALCULUS IN THE STRUCTURAL VIEW 127

the model and the views well-formed, when we design an evolutionary system (e.g. adding

an abstract relationship to the specification). Our refinement calculus, which is composed of a

set of logic constraints, serves this purpose. In essence, together with the extended operational

rules (c.f. Section 3.5.2.1), it can also be seen as a constructive definition of the well-formed

model and views respectively.

A natural language description of the calculus, which is applied in the following four situa-

tions, is detailed below.

making an object partial When system developers think that an object should be further de-

fined, but still cannot decide how this object should be refined, they can just add an

is-partial indicator after the name of that object. In this situation there is no special con-

straint.

adding an abstract relationship When system analysts and software architects think that Ob-

ject A and Object B or their components should have some relationships, but the details

can still not be decided, they can add an abstract relationship between them. The con-

straints are:

1. either A or B should be partial (in the model, not only in view);

2. if there already exists an abstract relationship between A and B, no new abstract

relationship should be added;

3. after the abstract relationship is newly added, some interrelationship should be ad-

justed. The principle of this adjustment is the same as that of the operational rules

in Section 3.4.3.3.

deleting the is-partial indicator of an object After an object A, which was made “partial” be-

fore, is fully specified, it can be made “not partial” again. I.e. the previous manually

added is-partial indicator of A can be deleted. There is one constraint, which prevents an

object from being “not partial”:

• if there exists a manually added abstract relationship connecting A and another ob-

ject B in the model and the view, and B is not partial in the model and the view,

A must remain “partial”. In this case, in order to guarantee the consistency of the

ADORA model, the manually added abstract relationship and this is-partial indicator

should be both deleted.

What is more, after deleting the is-partial indicator of Object A,

• A should also be visible in the view, when all directly embedded objects of A are

“not partial” in the current view.


deleting an abstract relationship After two objects A and B are fully specified, and no associ-

ations will be added between A and B or their components, the previously added abstract

relationship can be deleted. There are two constraints in this case:

1. the abstract relationship cannot just be deleted in the view, unless no association

between the components of A and B is hidden in the view;

2. if the abstract relationship is deleted, some interrelationship should be adjusted.

The formal definition of the refinement calculus has a similar notation as that of operational

rules. We give the formal definition of the refinement calculus and its meta-functions as follows:

Let M be an ADORA model with A : object, ar : abstract relationship and let Γ be a partial

view of M .

• man g partial(A, Γ,M) is a boolean function, which is true when the action of “making

an object partial (A)” happens. Surely when this action happens, partial(A,M) becomes

true. By the way, when A is partial in the model, it is also partial in the view. I.e.

partial(A,M) → partial(A, Γ).

• man g absrel(ar(A,B), Γ,M) is a boolean function, which is true when the action of

“adding an abstract relationship (ar)” happens. Similar to the function

man g partial(A, Γ,M), when man g absrel(ar(A,B), Γ,M) is true, we have ar ∈M . We also have (ar ∈ M) → (ar ∈ Γ).

Refinement in the Structural View

Rule making an object partial (A)


Condition: ∅Assertion: man g partial(A, Γ, M) → (partial(A, Γ) ∧ partial(A, M))

Rule adding an abstract relationship (ar)

Given: M ; Γ; A, B : object; ar : abstract relationship

Condition: visible({A, B}, Γ)Assertion: man g absrel(ar(A, B), Γ, M) → (Constraint1 ∧ Constraint2 ∧ Constraint3)

Rule deleting the is-partial indicator of an object (A)


Condition: partial(A, M) ∧ Constraint4

Assertion: (¬man g partial(A, Γ, M)) → ¬partial(A, M) ∧ Constraint5

5.1. REFINEMENT CALCULUS IN THE STRUCTURAL VIEW 129

Rule deleting an abstract relationship (ar)

Given: M ; Γ; A, B : object; ar(A, B) : abstract relationship

Condition: (ar ∈ M)Assertion: (¬man g absrel(ar(A, B), Γ, M)) → ((ar ∈/ M)∧

(Constraint6 → (ar ∈ Γ)) ∧ ((¬Constraint6) → ((ar ∈/ Γ) ∧ Constraint3)))where

• Constraint1 ≡ partial(A, M) ∨ partial(B, M)

• Constraint2 ≡ (∀ar1 : abstract relationship • ar1(A, B) ∈ Γ →(ar1 = ar)) ∧ ar(A, B) ∈ M

• Constraint3 ≡ (ar ∈ Γ) ∧(∀α : interrelationship, as : abstract relationship, r : association•(ar � as ↔ α(ar, as) ∈ Γ) ∧ (as � ar ↔ α(as, ar) ∈ Γ)∧(r � ar ↔ α(r, ar) ∈ Γ) ∧ (¬(r � as) → α(r, as) ∈/ Γ))

• Constraint4 ≡ ∀B : object, ar : abstract relationship•ar(A, B) ∈ Γ → (partial(B, M) ∨ (¬(ar(A, B) ∈ M)))

• Constraint5 ≡ ((∀Ai : object • (Ai � A) ∧ visible(Ai, Γ)) → (¬partial(A, Γ)))

• Constraint6 ≡ ¬∃r : association • (∀Ak, Bk : object•hidden(r(Ak, Bk), Γ)∧(((Ak ⊃ A) ∧ (¬∃Ai : object • (Ak.pre ⊇ Ai.pre ⊃ A.pre) ∧ visible(Ai, Γ)))∧((Bk ⊃ B) ∧ (¬∃Bi : object • (Bk.pre ⊇ Bi.pre ⊃ B.pre) ∧ visible(Bi, Γ)))))

Note that:

• The rule structure is nearly the same as that of the operational rules. As the constraints

here are much easier, they do not need to be written as a sequence of rules to enhance the

understandability. Therefore, the item of “Next Rule” is unnecessary.

• The first three formally specified constraints one to one correspond to the three explana-

tions for “adding an abstract relationship” in natural language.

The fourth formal constraint corresponds to the explanation for “deleting the is-partial

indictor of an object”; while the fifth says that after this action, the object should be “not

partial” in the view, when all its directly embedded objects are visible.

The sixth and the third formally specified constraints correspond to the two explanations

for “deleting an abstract relationship” in natural language respectively.


• Constraint6 specifies a constraint, which is far more complex than what is stated in

natural language (c.f. the natural language explanation in the first point of “deleting

an abstract relationship”.). Surely we can explain these constraints in every detail with

natural language in half a page. However, this explanation, just as the natural language

explanation for the operational rules in Chapter 3, will look very awkward and redundant.

Here, we can see that a formal definition can specify constraints in a much more precise

and concise way. This can not be achieved by an explanation in natural language.

• For each of the rules, when the condition is evaluated to be false, the refinement specified

by those rules is not allowed to be carried out.

• Especially for ADORA+, whether a model element belongs to a model or to its corre-

sponding (structural) view is very important information. In ADORA, all the model el-

ements except is-partial indicator, abstract relationship and interrelationship can belong

both to a model and to its corresponding view. When they belong to both, they are vis-

ible in that view. If they only belong to the model but not the view, they are hidden in

that view. Note that is-partial indicator, abstract relationship and interrelationship ex-

ist neither in a complete (structural) view nor in a model of ADORA. They exist in a

view, only when some objects and associations are hidden in that view. However, in

ADORA+, when we manually add an object or an abstract relationship, is-partial indi-

cator, abstract relationship and interrelationship can both belong to a model and to its

corresponding view.

• Here the refinement calculus includes the semantic constraints relating to the extended

constructs for modelling the evolutionary information. In the following sections, it will

also include the rules specifying the integrity and consistency of the different aspect views

of the model, as these play an important role in the refinement process.

Generally speaking, all the syntactic constraints on the language play certain roles in the

refinement process. Nevertheless, we restrict the refinement calculus only at the semantics

level.

5.2 Refinement Calculus in the Behavioral View

Similar to what is extended in the structural view, we also give a refinement calculus for the

behavioral view. It can be applied in the following two situations (c.f. Figure 2.9b and Figure

2.10):

making a state/object partial Making a state/object partial in the behavioral view is very sim-

ilar to making an object partial in the structural view. When system designers think that a

5.2. REFINEMENT CALCULUS IN THE BEHAVIORAL VIEW 131

state/object should be further defined, but still cannot decide how this state/object should

be refined in the behavioral view, they can just add an is-partial indicator after the name

of that state/object.

As explained in the previous subsections, in order to design a generic statechart in a de-

composable way, for example introducing is-partial indicator to represent evolutionary

information, we need a constraint:

• the state/object being made partial should be in a stateobject group without inter-

level transitions 1.

deleting the is-partial indicator of a state/object After a state/object S, which was made “par-

tial” before, is fully specified, it can be made “not partial” again. In this case, no special

constraint is needed.

A formal definition of these two situations is given as follows.

Refinement in the Behavioral View

Rule making a state/object partial (SO)

Given: M ; Γ; SO : stateobject; sog : stateobject group

Condition: SO ∈ sog ∧ ∀t : transition, so1, so2 : stateobject•((so1 ∈ sog ∧ so2 ∈ sog ∧ t(so1, so2) ∈ sog) ∧ so1.pre � so2.pre)

Assertion: man g partial(SO, Γ, M) → (partial(SO, Γ) ∧ partial(SO, M))

Rule deleting the is-partial indictor of a state/object (SO)


Condition: ∅Assertion: (¬man g partial(SO, Γ, M)) → ((¬partial(SO, M))∧

((∀SO1 : stateobject • (SO1.pre ⊇ S) ∧ visible(SO1, Γ)) → ¬partial(SO, Γ)))Note the following points:

• The rule structure is the same as that for the structural view.

• man g partial(A, Γ,M) is a boolean function, which is true when the action of “making

a state/object partial (SO)” happens. Surely when this action happens, partial(SO,M)

becomes true. By the way, when SO is partial in the model, it is also partial in the view.

I.e. partial(SO,M) → partial(SO, Γ).

1In order to be compatible with other graphical languages, we do not forbid the usage of the generic statechartswith inter-level transition. Only when users use ADORA with our extended construct is-partial indicator, shouldthey obey our “minimal” constraint: the part of the statechart, which relates to the extended construct, should beinter-level transitions free.


• in a generic statechart, a transition can not only connect a state but also an object. An

object being partial has two meanings:

– some structural information is hidden or needs to be further refined (e.g. an object

and its corresponding associations are hidden, etc.); and

– some behavioral information is hidden or needs to be further refined (e.g. a generic

statechart is hidden).

In order to avoid the misunderstanding, there is a constraint in the integration semantics:

the structural view and the behavioral view are not allowed to be combined together (c.f.

Section 4.1.3.1).

5.3 Refinement Calculus in the User View

When we further refine a currently not fully specified scenario with is-partial indicator, the

newly specified sub-scenarios should be conformed to the constraints mentioned in Section

4.1.3.1. The constraints are defined by a set of rules, which compose the refinement calculus.

We will organize the rules in the refinement calculus according to their application scopes.

5.3.1 Avoiding Conflicts between two Aspect Views

When we refine a scenariochart, we should try to avoid the possible conflicts between the user

views and other views. Here most problems are the conflicts between the scenariochart and the

generic statechart.

First we list the constraints on the refinement of scenariocharts in natural language.

In a scenarios-chart, some “sub-scenarios” have a temporal order. When they are embedded

in a generic statechart, the latter may bring them another temporal order. This causes con-

flicts. Therefore, the following constraints are defined for each type of relationships between

the super- and sub-scenarios.

Component scenarios: Usually they can be embedded in objects, which belong to the same

statechart group. No constraints in this relation (c.f. Figure 5.1).

Iteration scenario: As each scenario has at most one sub-scenario, which is an iteration sce-

nario, the problem mentioned above does not exist.

Sequence scenarios, Alternative scenarios, Concurrency scenarios : In these relations, sub-

scenarios are not allowed to be embedded in objects, which belong to the same statechart group.

(c.f. Figure 4.1 in Chapter 4)

Now, we will give the formal definition of the above part of the refinement calculus.

5.3. REFINEMENT CALCULUS IN THE USER VIEW 133

WB

C *

DY

EX

Figure 5.1: A legal integration of a scenariochart and a generic statechart.

Refinement in the User View: avoiding conflicts between behavioral view and user view

Rule Refinement Scenario into Component Scenarios(D)

Given: M ; Γ; C, D : scenario

Condition: ∅Assertion: component sce(C, D)

Rule Refinement Scenario into Iteration Scenario(D)

Given: M ; Γ; C, D : scenario

Condition: ∅Assertion: interation sce(C, D)

Rule Refinement Scenario into Sequence Scenarios(D)

Given: M ; Γ; D : scenario

Condition: ∅Assertion: ∀C, E : scenario, SO1, SO2 : stateobject, sog1, sog2 : stateobject group•

((C.pre � SO1.pre) ∧ (E.pre � SO2.pre)∧sequence sce(C, D) ∧ sequence sce(E, D)∧(SO1 ∈ sog1) ∧ (SO2 ∈ sog2)) → (sog1 �= sog2)

Rule Refinement Scenario into Alternative Scenarios(D)



((C.pre � SO1.pre) ∧ (E.pre � SO2.pre) ∧ alternative sce(C, D)∧alternative sce(E, D) ∧ (SO1 ∈ sog1) ∧ (SO2 ∈ sog2)) → (sog1 �= sog2)


Rule Refinement Scenario into Concurrency Scenarios(D)



((C.pre � SO1.pre) ∧ (E.pre � SO2.pre) ∧ concurrency sce(C, D)∧concurrency sce(E, D) ∧ (SO1 ∈ sog1) ∧ (SO2 ∈ sog2)) → (sog1 �= sog2)

where

• the rule structure is the same as that in Section 5.1.

• the above used functions are explained in Section 3.4 and Appendix E.1.

5.3.2 Ensuring the Modularity

In this part, there is one constraint, which prevents the connections connecting super- and sub-

scenarios from crossing the object border. This guarantees the modularity of ADORA.

Refinement in the User View: ensuring the modularity

Rule Refinement Scenario(D)

Given: M ; Γ; A, B : object; C, D : scenario

Condition: part of(C, D)Assertion: ((C.pre � A.pre) ∧ (D.pre � B.pre)) → (A.pre � B.pre)

Note the following points:

• The rule structure is the same as that in Section 5.1.

• The function part of(C,D) is defined in Section 3.4.7.

• The rule showed above specifies the constraint, which can be applied to the example in

Figure 4.2. Its intuitive meaning is that for two directly connected scenarios (one is the

subscenario of the other), they will be:

1. either embedded in a same object

2. or in two objects. One of these two objects is embedded in the other object.

Note that while refinement calculi for the structural views and the behavioral views concern

the effects of a partially specified part to others in the same aspect view, the rules here, which

guarantee the integrity and consistency of the integrated ADORA model, specify the effects of a

partial specification in one aspect view to other aspect views.

5.4 Merits

In essence, the refinement calculus expresses the same constraints as those in the integration

semantics in Section 4.1.3.1, but for another purpose and in another form: integrity semantics

5.4. MERITS 135

is given for the understanding of the language; refinement calculus is defined for the software

development process.

We give a formal semantics definition and a refinement calculus in a constructive way. They

not only give a precise language definition but also intend to be used in the ADORA tool. When

an object is hidden or concretized, consecutive view transitions are carried out automatically

based on our operational rules in the ADORA tool to guarantee the well-formedness of the

ADORA model. Similarly, during the system refinement, all the constraints will be mechanically

checked by the tool to guarantee the integrity, consistency, and freedom from conflicts in the

resulting model.

Chapter 6

Other Language Definition Issues

In this chapter, we first discuss the definition of verification rules. In the second part of this

chapter, we show the application of our method to UML. Lastly, we discuss the influences of

language definition on language design.

6.1 Verification Rules

A formal verification is a formal proof of the correctness of programs or specifications1.

Suppose we have a specification S. In the software development process, we want to obtain

a program or a more detailed specification P . During the refinement process, if we obey all

the logical rules provided by the refinement calculus, we will achieve P which satisfies certain

properties specified by S.

Verification rules do not specify any constraints during the development process. It is used

to check whether the achieved P satisfies certain properties specified by S or not.

Verification rules can contain the same information as what refinement calculus does, but in

another form which is more suitable for the purpose of verification.

In ADORA , a set of verification rules can be derived from the formal defined integration

semantics2. As the verification rules and the rules defined in our refinement calculus contain

nearly the same information, we skip the definition of verification rules here.

1Here specification refers to the architectural design and detailed design written in a (semi-)formal specificationlanguages, such as VDM, Z, (T)RSL, UML, ADORA, etc.

2As mentioned previously, the integration semantics in this dissertation is defined in the form of a refinementcalculus.

137

138 CHAPTER 6. OTHER LANGUAGE DEFINITION ISSUES

6.2 Application of our Methods to other Languages

In this dissertation, we select the ADORA language as a vehicle for demonstrating our new

method of language definition for graphic modelling languages. We do so for two reasons.

Firstly, the hierarchical decomposition mechanism and the elaborate model integrity concept

in ADORA are challenging problems when defining more than just the context-free syntax for-

mally. So if our approach works for ADORA, it should also work for other, less demanding

graphic languages. Secondly, we needed a precise syntax definition of ADORA as part of our

effort to develop this language.

Of course, our method can also be applied to other graphical modelling languages, espe-

cially those wide spectrum ones.

6.2.1 Syntax Definition of UML

For the definition of the syntax of UML, our method can be applied in quite a similar way to

what we do for ADORA: (1) setting up a mapping table which defines an equivalent textual

expression for every graphical element and constructor in UML; (2) defining the context-free

syntax of UML with EBNF on the translated textual form; (3) adding context-sensitive syntax

rules by attributing the context-free grammar to describe the spatial information in the UML.

As UML lacks a sound and elaborate concept for inter-diagram integrity checking, an attributed

grammar should be expressive enough to describe the whole UML syntax. Defining operational

rules for parts of the syntax will most probably not be necessary.

6.2.1.1 Some Simplified Examples

Here we give some examples to explain our method.

In Figure 6.1, UML graphical elements are mapped to their equivalent textual elements.

After this isomorphic mapping, we have a transformed textual modelling language, which

can be defined in EBNF form. Just as with the definition of ADORA , the context sensitive

constraints are specified by an attributed EBNF syntax.

Specification

specification ::= ∪{ diagram }diagram ::= ...

...

model element ::= class | association | inheritance | ...

...

Types

6.2. APPLICATION OF OUR METHODS TO OTHER LANGUAGES 139


… …

class name

attribute

attributes_def

operation

operations_def

property

properties_def

end

... …

inheritance

superC cla:class

subC cla_sub:class

end

… …

name

attribute_def

operation_def

…name(cla_sub)

name(cla)

Figure 6.1: An Excerpt of the UML Mapping Table

...

name ::= identifier

...

classConcurrency Type ::=

“Sequential” | “Guarded” | “Active” | “Synchronous”

...

Classes/Objects/States/...

class ::= class name [class body] property properties def end

...

class body ::= [attributes {attributes def}1]

[operations {operations def}1]

attributes def ::= ...

operations def ::= ...

properties def ::= ...

classConcurrency Type

Is Abstract

...

inheritanceTrace

...

Associations/Inheritances/...

...


inheritance ::= inheritance r name numpair

superC cla:class subC cla sub:class

Constraints:

(cla sub ∈/ cla.inheritanceTrace) ∧((cla sub.Is Abstract = true) → (cla.Is Abstract = true)) ∧...

end

...

6.2.1.2 Remarks

• Some notations in the above EBNF grammar are just the same as those in Section 3.3.

Further explanations are given as follows:

– After UML is translated to the textual language through mapping table, most parts

of syntax definition (e.g. attributes def, operations def) are very similar to the defi-

nition of textual programming languages, such as Java.

– Some properties of class are not explicitly expressed in the UML diagrams and

can be only specified in a UML tool environment (e.g. a class can be specified as

“sequential”, “guarded”, etc., for its “concurrency” property). They belong to a part

of UML syntax and here are specified in EBNF form.

– There are also some other properties in class, which do not directly belong to the

language syntax. However, they are used in some context sensitive constraints of the

language. They can also be considered as syntactical functions. Such an example

is “inheritanceTrace”, which actually is a syntactical function for class. Similar to

“pretrace” in Section 3.4.1, it is a set containing all superclasses of that class in a

partial order. With this kind of functions, we can simply use a first order logic to

specify some context sensitive constraints. The above example gives two constraints

on inheritance: (i) circular inheritance is not allowed; and (ii) a concrete class can

not be a superclass of an abstract class.

• Though in this section, only a fragment of the UML attributed EBNF syntax is defined

through some simplified examples, it nevertheless shows how our method defines UML.

A small part of the UML 1.5 core is defined by using our syntax definition method. From

our definition, we think that our technique is nevertheless simpler and more systematic

than the metamodeling technique used in the OMG definition of UML 1.5 [56]. For exam-

ple, when looking for a precise definition of “class” in the OMG metamodel (which also

implies inspecting the inherited and associated properties of “class”), the reader has to in-

spect five metamodel diagrams and about three pages of OCL constraints – and the meta-

6.2. APPLICATION OF OUR METHODS TO OTHER LANGUAGES 141

model does not provide the reader any roadmap for systematically navigating through this

material in order to find the relevant information. In our attributed EBNF grammar we

need fewer rules and we provide a simple and straightforward navigation strategy: rule

inspection starts with the rule where “class” appears on the left side. Then the reader has

to inspect recursively all rules that appear on the right side of an inspected rule.

In essence, our EBNF grammar (in a textual form) and OMG’s metamodel (in a graphi-

cal form) describe the structure of the language (the language constructs and the relationships

among those constructs). The constraints on this language structure are described in textual

forms both in our approach and in the OMG-UML technique: we use an attribution of the

EBNF grammar and operational rules, OMG uses OCL. As we define the language structure

and its constraints both in a textual form, our language definition can be organized in a com-

paratively easier and more systematic way. For users, it is also easier to read it in a systematic

way. Moreover, as our constraints are embedded in the EBNF grammar, they are more concise

(no elements in metamodel diagrams need to be additionally referred to) and straightforward.

For the language structure part only, someone likes “EBNF” style; others like “metamodel-

diagram” style. It is just a question of taste. But we think our method is better to specify both

the language structure part and structural constraints part.

6.2.2 Dynamic Semantics Definition of UML

Our strategy fits the definition of dynamic semantics for UML too.

There are a lot of papers defining the dynamic semantics for UML in the software engineer-

ing conferences [71]. Nearly all of them give a formal semantics for each sublanguage of UML

separately.

As mentioned before, UML is a language with loosely coupled sublanguages. In UML, there

exist some constructs with very weak semantics for model integrity and consistency. However,

there is no enforcement of the integrity and consistency checking at the language level. There-

fore, we do not need to define the integration semantics for UML, nor can we define such

semantics.

In our view, even for a language with a set of loosely coupled sublanguages, it is necessary

to provide some kind of “bridge”, which connects the sublanguages. In Chapter 4, we introduce

an alternative approach: using a common semantic notation to define a partial semantics of all

the UML sublanguages. It is especially efficient for loose coupled wide spectrum languages,

such as UML.


6.3 Influences of Language Definition on Language Design

A good language definition favors a good language;

a good language favors a good language definition.

— C.A.R. Hoare

The task of language design is that we create a new language, which is suitable in certain sit-

uations. The motivation of introducing every language construct (language elements, language

operators, etc.) is the focus of this task. Besides, we also need to consider the expressiveness of

languages.

The task of language definition is the definition of syntax, semantics, verification rules,

refinement calculi, secondary notation, etc.

As mentioned before, the work introduced in this dissertation is a part of the ADORA devel-

opment. During the formal definition of the ADORA Language, we also continue our effort to

design the ADORA Language.

In the process of the formal definition, we find:

• The styles of some constructs defined in the first project phase using natural language are

inconsistent;

• The meanings of some constructs are unspecified or unclear. Sometimes they are even

contradictory. Therefore, we need to change the styles of some constructs definition, and

introduce or delete some language elements.

Moreover, there are always some new ideas proposed from the software community and our

group. Therefore, we also need to extend ADORA to support those new concepts and mecha-

nisms.

During the further development of the ADORA Language, we find that language design and

language definition are not independent at all. The reciprocal influences of these two tasks need

to be studied.

6.3.1 Influence of Language Definition on Language Design

Before we formally (or rigorously) define a language, generally this language has already been

created. That is to say, most of the language constructs and language elements are fixed. The

meaning of each single language construct or language element is more or less clear.

The questions:

• why the language constructs and the language elements are included in the language?

• how those language elements and constructs can be used in a practical situation?

are already carefully considered.

However, there are always some open issues that need to be solved in the language design.

6.3. INFLUENCES OF LANGUAGE DEFINITION ON LANGUAGE DESIGN 143

Sometimes, we have more than two choices of introducing a language construct or a lan-

guage element, or of the forms of the language constructs and elements being introduced. All

of them satisfy the needs of the practice. How can we choose one from them? Or when we have

difficulties in defining the semantics, verification rules, or even syntax for certain language

constructs, should we rethink the language design?

In the process of our formal language definition, we find language definition has quite a

lot of influence on language design. The following principles help us to answer the above

questions.

6.3.1.1 Good Mathematical Properties

From the practical experiences and theoretical research [33], the operators with interesting

mathematical properties, such as being symmetrical, being reflexive, help the formal defini-

tion of semantics, future theory proof, formal verification and refinement. Therefore, when it

is possible, the language constructs and operators with good mathematical properties should be

selected during the language design.

6.3.1.2 Ease of the Language Definition

Some language elements are very difficult to formally define in a simple way. In this case, we

should select other elements, which also satisfy practical needs, but are easy to define. When

there is no other choice, we should ask ourselves, whether those elements are really needed?

Are there any other elements, which can replace those elements and are easy to define? Must

those elements be introduced in the language in these forms? We give an example as follows.

One-dimensional language

We have an observation: most visual specification languages, after a simple one-to-one map-

ping, can be easily translated into one-dimensional languages. That is to say, the layout informa-

tion in visual specification languages carries only few semantics information. As shown in the

previous chapters, the context free syntax and one dimensional notation bring more advantages.

The scenariochart in ADORA, which originally had the same style as that of Jackson Dia-

gram, is a good example here. The sequence action in our scenariochart and the original Jack-

son Diagram destroys this rule. The criterion of “easy for the language definition” guides us to

change the original style. Therefore, during the language definition process, we add a number

to each sequential action. What is more, a black cycle is used to denote the super-scenario in

the scenariochart. The current version of scenariochart is one-dimensional.

Actually, most visual specification languages can be designed as, or at least close to, one-

dimensional languages. For example, the old version of scenariochart is changed to be a one-


dimensional language with only few modifications.

6.3.1.3 Better Tool Supports

A language needs tool supports to make it useful. Interpreter, Compiler, Editor, Theorem Prover,

and Model Checking Tool are often used tools for a language.

For some reasons, a good language design can make a language having better tool supports

than another does. And usually, this can only be discovered when we formally define this

language.

The problem of the generic start states of statechart in Section 3.4.6.1 is a good example.

Before we formally define the syntactical correctness resp. well-formedness of statechart,

during the previous language design we never considered that problem.

The design decision “whether each stateobject group must have a generic start state” makes

the syntactical correctness / well-formedness definition stronger. I.e. the errors (or at least

ambiguities) in Figure 3.14 can be checked during compiling time.

6.3.1.4 Harmonious to other Language Constructs and Mechanisms

Sometimes, we have an instinct feeling that some language elements, language mechanisms,

or their meanings are introduced in an awkward way. Maybe they also satisfy the needs of the

practice. But somehow they look unharmonious to other language constructs or mechanisms.

A formal analysis helps the language designer to find the reasons, and redesign the language.

When we formally define a language, one important task is to analyze the language, their

constructs, the relationships among the language constructs, and the language mechanisms etc.

in a formal, mathematical way. Through this process, we may find the reason of the awkward-

ness, and detect the possible potential conflicts.

A good example to explain the relationship between the language definition methods and

the language design is the scenarios-chart.

Our scenarios-chart has the same style of Jackson Diagram. The strong point of our scenarios-

chart and the Jackson Diagram is: they ignore the details (e.g. conditions), and focus on the

general structure of the system.

However, it also brings the problems, when the sequential scenarios are embedded in the

temporal-ordered “generic states”, some conflicts arise. In this case, we need to change our

language design and keep our language constructs harmonious to others.

This kind of problems is usually only discovered during the formal semantics definition.

6.3. INFLUENCES OF LANGUAGE DEFINITION ON LANGUAGE DESIGN 145

6.3.2 Reciprocal Influences

In the above examples, we are mainly talking about the influences of language definition on

language design. However, these influences usually are not unidirectional. Different language

design results in different strategies of language definition. And most of the above mentioned

influences are reciprocal.

Part III

Summary

147

Chapter 7

Conclusions

In this dissertation, a novice language definition method for the visual specification languages

is given. Its basic ideas, merits and limitations are distributed in the previous chapters. In this

chapter, we summarize the merits, limitations, further research directions and future work.

7.1 Merits

• We propose an innovative syntax and static semantics definition. We do not claim that

constructing a textual modelling language through a mapping technique and defining its

syntax with an EBNF grammar are new ideas. Our contribution is to demonstrate that this

technique is feasible for a complex graphic modelling language and that it can be used

not just as an internal representation in a tool, but as a reference both for the human users

of the language and for the tool builders.

– Compared with the metamodeling technique, our method overcomes the shortcom-

ings of metamodeling techniques (e.g. overusing inheritance in the metamodeling

technique, mixing of syntactic and semantic definition, which makes the syntax

difficult to understand and semantics ambiguous, in the metamodeling technique,

unnecessary complexity of using graph grammar for graphic modelling language,

etc.)

What is more, our syntax is also better organized. In essence, our EBNF grammar

(in a textual form) and the metamodel (e.g. the OMG metamodel) (in a graphical

form) describe the structure of the language (the language constructs and the rela-

tionships among those constructs). The constraints on this language structure are

described in textual forms both in our approach and in the OMG-UML technique:

we use an attribution of the EBNF grammar and operational rules; OMG uses OCL.

As we define the language structure and its constraints both in a textual form, we

149

150 CHAPTER 7. CONCLUSIONS

think that our language definition is comparatively easier to be organized in a more

systematic way. For users, it is also easier to read it in a systematic way. Moreover,

as our constraints are embedded in the EBNF grammar, they are more concise (no

elements in metamodel diagrams need to be additionally referred to) and straight-

forward.

– Graph grammars extend string grammars [51] (e.g. EBNF) in the following points:

(i) terminals are interpreted as two-dimensional objects; (ii) attributes are used to

specify the spatial information; (iii) the one-dimensional concatenation in the pro-

duction rules is extended to multi-dimensional concatenation; and (iv) the function-

alities of the elements in the production rules are augmented. Compared with the

graph grammars, in a sense, our EBNF based definition method can also be some-

how thought of as an extended string grammar: the terminals in our grammar are

actually also the two-dimensional object, after reverse mapping from the textual

modelling language to the graphical modelling language. The difference is: in most

graph grammars, those two-dimensional objects are basic graphical elements, such

as straight line, arc, etc. In our method, those “two-dimensional objects” are basic

model elements, such as object, association, etc. That is to say, the abstract levels of

the terminals in the two approaches are different. As our grammar is not intended

to be used in fields such as image processing, our interpretation is suitable for our

purposes. Furthermore, as our interpretation makes a graphic modelling language

nearly one dimensional, attributes in our approach are mainly used to specify con-

text sensitive syntax (static semantics), instead of spatial information. The third and

fourth extensions in graph grammars are not necessary in our approach at all. In

other words, our approach extends the string grammar in a suitable way to be ex-

pressive enough to handle the typical graphic modelling languages. At the same

time, it is far from the complexity of graph grammars. Note that graph grammars

are certainly more expressive, but the extra expressiveness is not useful for our pur-

poses, but much more difficult to use and understand.

– Abstract syntax and concrete syntax

Our approach of the EBNF syntax definition provides a natural connection between

the abstract syntax and concrete syntax. Unlike the metamodeling technique, in

which a concrete syntax for the compiler design can only be derived from the se-

mantic interpretation of the metamodel (an abstract syntax), the derivation from the

abstract syntax to the concrete syntax in the EBNF-based approach is only a process

of optimization, and hence much easier and more straightforward.

– Implementation

Our syntactical definition with EBNF grammars is easier to implement than the def-

7.1. MERITS 151

inition with meta-models (c.f. the point of “Abstract syntax and concrete syntax”).

We use a first order predicate logic to define static semantics. Usually an arbi-

trary first order predicate logic formula are not computable. However, when we

build an ADORA parser/compiler, as the number of model elements in a concrete

ADORA model is limited, we are able to implement the first order predicate logic

constraints by enumerating all the model elements.

From the implementation point of view, the complexity of our operational rules im-

plementation is also lower than that of the descriptive constraints implementation

with many combination of quantifiers (∀ and ∃). What is more, as mentioned in

Section 3.4.3.2, the introduction of some meta-functions, such as “related()”, op-

timize the implementation algorithm: not all objects and associations need to be

dealt with, but only the possible “related” ones. Just as our method has a natural

connection between the abstract syntax and concrete syntax, our definition of the

static semantics part serves both as an abstract langauge specification and also as a

referential implementation model.

– Readability and Preciseness

Our method has a better understandability than other semi-formal or formal tech-

niques: For example, our mapping table is much easier to understand than the meta-

models in the OMG approach.

In particular, our way of defining dynamic context-sensitive constraints with oper-

ational rules is original. We demonstrate that these operational rules are a clean

and elegant way of dealing with hierarchy and with partial models and that they

are nicely integrated with our grammar-based definition of context-free syntax. The

advantage of operational rules over a declarative set of constraints is that quite com-

plex syntactic rules can be expressed as a series of sequential steps, each of which

being easily readable and implementable.

As mentioned in the points “Abstract syntax and concrete syntax” and “Implemen-

tation”, our syntax definition is easy both for users to master the language and for

the tool developers to construct tools that support the language.

Compared with the natural language description, our definition is not so readable,

if readers do not have the necessary computer science background. The explana-

tions of the operational rules Chapter 3 and refinement calculus in Chapter 5 can be

thought of as a kind of language definition with natural language. It looks awkward,

redundant and is not so precise.

All in all, the syntax and static semantics definitions with natural language are im-

precise, informal, but readable. The definitions with the OMG metamodeling tech-

nique are a little less readable than our approach and not totally formal. Our ap-


proach is totally formal, and achieve an acceptable degree of readability.

– Moreover, the defined syntax of a graphical modelling language using our EBNF-

based method is very similar to that of a textual specification language or program-

ming language. Therefore, the existing semantics definition techniques, which are

used in defining semantics of textual specification or programming languages, can

also be applied to a graphical modelling language with only a few changes. There-

fore, our method provides an excellent base for the definition of semantics, a refine-

ment calculus and verification rules.

We do not dismiss the other syntax definition techniques for visual specification languages

(e.g. metamodeling techniques [56][9] and abstract graphs [18][67]) as being bad or

obsolete. Our approach is meant to be an alternative that avoids problems of the existing

techniques.

Note that a formal and complete syntax definition for wide spectrum graphic modelling

languages (e.g. ADORA and UML), which are a set of tightly or loosely coupled sim-

ple graphic modelling languages (e.g. statechart, MSC, Petri Net), is a significant work

worthy of much more attention than what the existing researches are devoted to. After a

careful survey, we do not find any work similar to our approach. Metamodeling is a semi-

formal approach even for the context-free syntax definition. In other literature, the work

on syntax definition is only for simple graphic modelling languages, and most of them

are just by-products of semantics definition. This is not acceptable for a wide spectrum

graphic modelling language with a rich syntax, where integration conflicts of different

sub-languages must be eliminated and constraints on the numerous constructs have to be

precisely specified.

• We provide a practical dynamic semantics definition strategy. A formal semantic is useful

for (i) formal consistency checking of the language itself, (ii) unambiguous understand-

ability, and (iii) formal refinement and verification.

Our approach can achieve aim (iii) and part of aim (i). OMG-UML gives only a semantics

using natural language and semi-formal metamodels, and achieves none of the above

aims. The other work on formal semantics for wide spectrum graphic languages does not

have better results than ours. For example, pUML approach is not a formal approach,

but a semiformal one, which can not totally achieve aim (iii) and (i). It seems that our

approach is the best which can be achieved.

Compared with other approaches of giving a formal semantics to the whole wide spectrum

language, our strategy is less ambitious but more practical: we focus first on what we can

7.2. LIMITATIONS AND FUTURE WORK 153

practically achieve, and let the problems, either which we can not solve or for which we

can only get very complex and inapplicable results, open.

Again, our strategy is not intended to be a replacement of others. On the contrary, our

approach can be a complement to others; Other approaches may also help us (i) to find a

better and simplified definition (especially the definition of integration semantics); (ii) or

at least to enhance our insights of the language and language semantics.

• We give a helpful analysis of the influence of the language definition on the language

design. This analysis also helps us to finish a part of the ADORA language design work,

and elaborate and validate the language constructs.

• We conservatively extend the ADORA language to support the partial and evolutionary

specification and define an applicable refinement calculus.

A model should record system information, which includes evolutionary information. As

evolutionary information is so closely coupled with system information, it should not be

separated from system information and classified only into the field of software process.

Therefore, at the language level the concept of evolutionary specification being supported

is useful and necessary. We conservatively extend the semantics of two constructs: the

is-partial indicator and the abstract relationship in ADORA to express evolutionary infor-

mation in the system. Based on the extended semantics, we also define a static semantics

(well-formedness rules) and a refinement calculus for the structural, behavioral, and user

views of ADORA . This makes the evolutionary specification be written in a controlled

and systematic way, while the original good properties of ADORA are perfectly kept.

All the syntax, static semantics, and refinement calculus are formally defined in this disser-

tation. This helps particularly for the development of a tool, which automatically checks the

syntax and semantics of an ADORA model and mechanically controls the evolutionary devel-

opment of a software system. By the way, our extension approaches and language definition

methods for syntax, semantics and refinement calculus can also be applied to other graphical

modelling languages with some adjustments.

7.2 Limitations and Future Work

In this section, we first list limitations, and open problems of our work. Then, we discuss further

research directions and future work.

• The syntax and static semantics definition:

When used by humans, our syntax definition technique requires mental effort for translat-


ing graphic concepts into textual ones and vice-versa, using the mapping table. Therefore,

our approach is limited to languages where this mapping is easy and straightforward. As

we discussed in the paper, there is always an easy mapping when the graphic layout

of the diagrams has little or even no syntactic relevance. With few exceptions, this is

the case for requirements and architecture modelling languages. In this family of lan-

guages, only sequence diagrams have a strongly layout-dependent syntax. Moreover,

other techniques such as metamodeling also require substantial mental effort for com-

bining a graphic language (the metamodels) with a textual language (the constraints), as

metamodeling diagrams need extra textual constraints (e.g. OCL) to specify the static

semantics (context-sensitive syntax).

• The strategy of the dynamic semantics definition:

We do not give a complete definition on dynamic semantics, but a definition strategy. In

order to make our strategy practical, we use the current semantics definition method for

definition of each sublanguage of a wide spectrum graphical modelling language. They

can be in different notations without any relations among one another. Therefore, an

integration semantics, which connects those semantics definitions of sublanguages, are

essential. So far our definition on integration semantics mainly focuses on the constraints

on static semantics. Many interrelations of the dynamic semantics of sublanguages are

not captured owing to lack of a common semantic base.

• The research on the reciprocal influences:

In this field, some very interesting questions arise. Now the usual approach of a language

design and definition is: first we design a language, according to the needs of practice.

Later we try to give a formal definition on syntax and semantics. If the formal semantics

is too complex, we give up the formal definition and use an informal or semi-formal

one. If no formal verification rules and refinement calculus are available, we just use the

informal, even ill-defined, methods in the software development process. This approach

should take the most responsibility of the immaturity of the software industry. Should

we adopt another approach? At the beginning of the language design, we should already

consider the formal syntactical and semantic definition. When there are difficulties on

defining an easily applicable semantics to some language constructs and mechanisms, we

would like to sacrifice the expressiveness of the language and take out those constructs

and mechanisms from the language. This makes a formal development of software using

that language possible.

On the other hand, the current researches on formal methods are far from being prac-

tically applicable. How well the above mentioned alternative works can not be really

proved. However, the topic on the reciprocal influences of language design and language

7.2. LIMITATIONS AND FUTURE WORK 155

definition needs much more attention. Our research is just a first attempt. To the best

of our knowledge, no work has been done on this topic. Many of our views need to be

further validated and systematized.

• Extension of the ADORA language to support the partial and evolutionary specification:

As we know, our work on supporting evolutionary specifications is the first try in this

field. It has to be done in a very careful way, and the extension is really “conservative”.

Whether new constructs need to be introduced is not clear in the current research phase.

A radical extension needs to be further validated.

• Language validation:

A question from colleagues of our community is often raised during this research work.

Why do we mainly use ADORA , instead of UML, as a vehicle to demonstrate our defini-

tion method in this dissertation?

Actually, for definition of context free syntax and simple context sensitive syntax, we can

also use UML to demonstrate our method. However, in order to show that our method

is also suitable for the language with more demanding features, such as the hierarchical

decomposition mechanism and the elaborate model integrity concept, a language with

complex structural information, such as ADORA , is a good choice.

Again, the hierarchical decomposition mechanism makes ADORA easy to be extended to

support concept of evolutionary specification and partial models. The refinement calculus

is also set up based on the elaborate model integrity concept. These also make us select

ADORA .

Then another question arises: are the hierarchical decomposition mechanism and the

model integrity concept really practically useful?

In [8], we made an experiment on validation of the ADORA language. With the contin-

uous extension of ADORA , the validation work will be carried out further. On the other

hand, the real validation work should be carried out in some real industrial projects, and

the language should be accepted by the industrial users, not only its designers (The bait

should be tasty for the fish, not for the fisherman1). In this aspect, we still have much

work to do. And this is always difficult work! On the other hand, UML has more or less

the same problem.

The last question is: why we not use an extended “stereotyped UML” as a vehicle to

demonstrate our language definition method?

Surely our extension approaches and language definition methods for syntax, semantics

and refinement calculus can also be applied to other graphical modelling languages with

1An adage from German Language: Der Koder muss dem Fisch schmecken - und nicht dem Fischer.


some adjustments. For example, we can extend UML to a “stereotyped UML” with part

of the above mentioned features of ADORA (introduction of hierarchical decomposition

mechanism and is-partial indicator in another way, etc). We can also easily translate our

semantics and the refinement calculus from a normal first order predicate logic into OCL.

However, this extension of UML makes the target model unnecessarily complicated, and

brings no more values than ADORA does. Research on a small language can often inspire

some new ideas, which can not be achieved by only restricting to a big language such

as UML. And keeping great variety in our research community is valuable, even for the

further development of UML.

• Future work:

With the development in the software engineering field, the ADORA language will also

evolve. Existing constructs will be modified and new concepts will be supported. Corre-

spondingly, the language definition will not be frozen, but evolve too.

We will validate the other extension possibilities for ADORA. A process for ADORA should

also be proposed accordingly to better support the evolutionary development of a soft-

ware system. What is more, the formal definition of the extended ADORA on syntax,

static semantics (well-formedness rules) and the refinement calculus provides a sound

base to develop a tool, which implements the above mentioned rules and checks the well-

formedness of the ADORA model dynamically.

A prototype ADORA tool is now being built and will be further developed in Require-

ment Engineering Research Group in University of Zurich. This prototype ADORA tool

includes the following functions:

– syntax checking of the ADORA language and the ADORA+ language;

– static semantics checking of the ADORA language;

– part of static semantics checking of the ADORA+ language;

– a lot of other functions (e.g. the implementation of the fisheye algorithm, version

controlling, etc.), which are beyond the scope of this dissertation.

Bibliography

[1] S. Berner, Model visualization for the Specification Language ADORA (in German) Ph.D.

Thesis, University of Zurich, 2002

[2] D. Bolignano and M. Debabi. RSL: An Integration of Concurrent, Functional and Im-

perative Paradigms. Technical Report LACOS/BULL/MD/3/V12.48, Bull LaCoS Team,

1993.

[3] Johan Bengtsson, W. O. David Griffioen, Kare J. Kristoffersen, Kim Guldstrand Larsen,

Fredrik Larsson, Paul Pettersson, Wang Yi, Verification of an Audio Protocol with Bus

Collision Using UPPAAL. Proceeding of 8th International Conference on Computer Aided

Verification (CAV) 1996: 244-256.

[4] S. Berner, S. Joos, M. Glinz, and M. Arnold, “A Visualization Concept for Hierarchical

Object Models”, Proceedings 13th IEEE International Conference on Automated Software

Engineering (ASE-98), pp. 225-228, 1998

[5] Dines Bjorner and C.B. Jones, editors. The Vienna Development Method: The Meta-

Language, Lecture Notes in Computer Science Vol. 61. Springer-Verlag, 1978.

[6] Ralph-Johan Back, Luigia Petre and Ivan Porres Paltor. Formalising UML Use Cases in

the Refinement Calculus Turku Centre for Computer Science TUCS Technical Report No.

279, 1999.

[7] M. M. Burnett, Seven programming language issues. In Burnett, M. M., Goldberg, A., and

Lewis, T. G., editors, Visual Object-Oriented Programming. Prentice Hall and Manning,

Greenwich, CT, 1994.

[8] Stefan Berner, Nancy Schett, Yong Xia, Martin Glinz An Experimental Validation of the

ADORA Language. Technical Report 99.07, Institut fur Informatik, University of Zurich,

1999.

[9] T. Clark, A. Evans, S. Kent, S. Brodsky, and S. Cook A Feasibility Study in Resarchi-

tecting UML as a Family of Languages using a Precise OO Meta-Modeling Approach

http://www.puml.org

157

158 BIBLIOGRAPHY

[10] P. P-S. Chen, The Entity Relationship Model - Towards a Unified View of Data, ACM

Transactions on Database Systems, Vol. 1, No. 1, March 1976, pp. 9-36.

[11] N. Chomsky, Syntactic Structures, Mouton, The Hague, 1957.

[12] N. Chomsky, Aspects of the Theory of Syntax, MIT Press, Cambridge, 1965.

[13] S. K. Chang, Principles of Visual Programming Systems, Prentice Hall, 1990.

[14] P. T. Cox, and T. Pietryzkowsky, Using a pictorial representation to combine dataflow

and object-orientation in a language-independent programming mechanism In Glinert, E.

P., editor, Visual Programming Environments: Paradigms and Systems. IEEE Computer

Society Press, Los Alamitos, CA, 1990.

[15] G. DiBattista, P. Eades, R. Tamassia and I.G. Tollis, Graph Drawing: Algorithms for the

Visualization of Graphs Prentice Hall, 1998.

[16] T. DeMarco, Structured Analysis and System Specification, Yourdon Press, New York,

1978.

[17] N. Dulac, T. Viguier, N. Leveson, and M-A. Storey, On the Use of Visualization in Formal

Requirements Specification Proceeding of Requirements Engineering Conference, 2002.

[18] J. Ebert, and A. Fronk, Operational Semantics of Visual Notations, Technical Report 8,

Institute for Software Technology, University of Koblenz, 1997.

[19] T. Clark, and A. Evans Foundations of the unified modeling language 2nd Northern

Formal Methods Workshop, Ilkley, electronic Workshops in Computing. Springer-Verlag,

1998.

[20] J. Ebert, and R. Suttenbach, An OMT Metamodel, Technical Report 13, Institute for

Software Technology, University of Koblenz, 1997.

[21] P. Fradet, D. Le Metayer, and M. Perin. Consistency checking for multiple view software

architectures, Proc. of the Joint European Software Engineering Conference and Symp.

on Foundations of Software Engineering, ESEC/FSE’99, 1999.

[22] A. Franzke, GRAL 2.0: A Reference Manual, Technical Report 3, Institute for Information

Technology, University of Koblenz, 1997.

[23] K. S. Fu, Syntactic Pattern Recognition and Applications, Prentice Hall, 1982.

BIBLIOGRAPHY 159

[24] M. Glinz, Statecharts For Requirements Specification - As Simple As Possible, As Rich

As Needed, Proceedings of the ICSE 2002 Workshop on Scenarios and State Machines:

Models, Algorithms, and Tools, 2002.

[25] M. Glinz, An Integrated Formal Model of Scenarios Based on Statecharts, In Schafer, W.

and Botella, P. (eds.) Software Engineering - ESEC ’95. Proceedings of the 5th European

Software Engineering Conference, Sitges, Spain. Berlin, etc.: Springer (Lecture Notes in

Computer Science 989), 1995, pp 254-271.

[26] M. Glinz, S. Berner S. Joos, J. Ryser, N. Schett and Y. Xia, The ADORA Approach to

Object-Oriented modeling of Software, Proceedings of CAiSE’01 13th Conference on

Advanced Information Systems Engineering, Lecture Notes in Computer Science Vol.

2068, Springer, Berlin Heidelberg, 2001, pp 76-92.

[27] M. Glinz, S. Berner, and S. Joos, “Object-oriented modeling with ADORA”. Information

Systems 27, 6 (2002), pp. 425-444.

[28] Ch. Geiger, R. Hunstock, G.Lehrenfeld, W.Mueller, J. Quintanilla, C.Tahedl, and A. We-

ber Visual Modeling and 3D-Representation with a Complete Visual Programming Lan-

guage - A Case Study in Manufacturing In Proceedings of the 1996 IEEE Symposium on

Visual Languages, Sept. 3-6, Boulder, CO, 1996.

[29] S. J. Greenspan, J. Mylopoulos, A. Borgida, Capturing More World Knowledge in the

Requirements Specification. Proc. 6th Intern. Conference on Software Engineering, 1982,

pp. 225-234.

[30] D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer

Programming, 8:231–274, 1987.

[31] B. Henderson-Sellers and A. Bulthuis, Object-Oriented Metamethods, Springer, New

York, 1997.

[32] B. Henderson-Sellers, “Some Problems with the UML V1.3 Metamodel”, Proc. 34th

Annual Hawaii International Conference on System Sciences, IEEE Computer Society,

2001.

[33] C.A.R. Hoare and Jifeng He, Unifying Theories of Programming, Prentice-Hall Interna-

tional, 1998.

[34] C.A.R. Hoare, Communicating Sequential Processes, Prentice-Hall International Series

in Computer Science, 1985.

160 BIBLIOGRAPHY

[35] D. Harel and B. Rumpe, Modeling Languages: Syntax, Semantics and All That Stuff Part

I: The Basic Stuff, Research Report

[36] D. Harel and M. Politi, Modeling Reactive Systems with Statecharts: The STATEMATE

Approach, McGraw-Hill, 1998.

[37] Anne Haxthausen and Yong Xia, Linking DC together with TRSL, In Proceedings of 2nd

International Conference on Integrated Fromal Methods (IFM’2000), Schloss Dagstuhl,

Germany, Lecture Notes in Computer Science Vol.1945, Springer Verlag, November 2000.

[38] Michael Jackson, Jackson Development Methods: JSP and JSD, in Encyclopaedia of

Software Engineering, John J Marciniak ed; John Wiley & Sons, 1994.

[39] M. Jarke, R. Gallersdorfer, M.A. Jeusfeld, M. Staudt, S. Eherer, ConceptBase - A Deduc-

tive Object Base for Meta Data Management. Journal of Intelligent Information Systems

4, 2 (1995), pp. 167-192.

[40] S. Joos, ADORA-L – A modeling language for specifying software requirements. (in Ger-

man), PhD Thesis, University of Zurich, 1999.

[41] D. E. Knuth, The genesis of attribute grammars, In P. Deransart and M. Jourdan, editors,

Attribute Grammars and their Applications, volume 461, LNCS, Springer-Verlag, 1990

[42] Anneke Kleppe and Jos Warmer Unification of Static and Dynamic Semantics of UML

Klasse Objecten, Soest, Netherlands.

[43] Leslie Lamport Specifying Concurrent Systems with TLA+ Calculational System Design.

M. Broy and R. Steinbrggen, editors. 3 March 1999

[44] M. Lehman, Software’s Future: Managing Evolution, IEEE Software 15, 1, 1998.

[45] J. Ludewig, ESPRESO - A System for Process Control Software Specification. IEEE

Transactions on Software Engineering SE-9 (1983), pp. 427-436.

[46] J. Ludewig, M. Glinz, H. Huser, G. Matheis, H. Matheis, M.F. Schmidt, SPADES - A

Specification and Design System and its Graphical Interface. Proc. 8th Intern. Conference

on Software Engineering, 1985, pp. 83-89.

[47] B. Meek, The Static Semantics File, ACM Sigplan Notice, Vol 25 No. 4, April 1990.

[48] R. Milner Communication and Concurrency Prentice Hall International Series in Com-

puter Science, 1989.

BIBLIOGRAPHY 161

[49] R. E. Milne The semantic foundations of the RAISE specification language. Technical

Report RAISE/STC/REM/11, STC/STL, Harlow, UK, 1990.

[50] Jeff Magee, Nat Pryce, Dimitra Giannakopoulou, Jeff Kramer, Graphical animation of

behavior models. Proc. ICSE 2000, 499-508.

[51] K. Marriott and B. Meryer, Visual Language Theory, Springer, Berlin, 1998.

[52] Zohar Manna and Amir Pnueli The Temporal Logic of Reactive and Concurrent Systems :

Specification Springer-Verlag, 1992.

[53] Zohar Manna and Amir Pnueli Temporal Verification of Reactive Systems: Safety

Springer-Verlag, 1995.

[54] C. Morgan and Trevor Vickers On the Refinement Calculus Springer-Verlag, 1994.

[55] N. H. Narayanan (Ed.) Reasoning with diagrammatic representations: Papers from the

1992 AAAI Spring symposium Menlo Park, CA: AAAI Press, 1992.

[56] OMG. OMG Unified Modeling Language Specification Version 1.5, OMG document

(2003). http://www.omg.org/technology/documents/formal/uml.htm

[57] Jukka Paakki, Attribute Grammar Paradigms – A High-Level Methodology in Language

Implementation ACM Computing Surveys, Vol. 27, No. 2, June 1995

[58] F. G. Pagen, Formal Specification of Programming Languages, Prentice-Hall 1981.

[59] Richard F. Paige and Jonathan S. Ostroff, An Object-Oriented Refinement Calculus De-

partment. of Computer Science, York University, Toronto. CS-1999-07, 1999.

[60] J. L. Pfaltz and A. Rosenfeld, Web Grammars, In Proc. First Int. Joint Conference on

Artificial Intelligence, 1969.

[61] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, Object-Oriented Modeling

and Design, Prentice Hall, Englewood Cliffs,1991.

[62] J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language Reference Manual.

Addison-Wesley, Reading, 1999.

[63] The RAISE Language Group. The RAISE Specification Language. The BCS Practitioners

Series. Prentice Hall Int., 1992.

[64] The RAISE Method Group. The RAISE Development Method. The BCS Practitioners

Series. Prentice Hall Int., 1995.

162 BIBLIOGRAPHY

[65] D. Ross, “Structured Analysis (SA): A Language for Communicating Ideas”. IEEE Trans-

actions on Software Engineering, SE-3, 1 (Jan. 1977). pp. 16-34.

[66] Rational Rose, IBM Rational Rose http://www.rational.com/

[67] R. Suttenbach and J. Ebert, A Booch Metamodel, Technical Report 5, Institute for Software

Technology, University of Koblenz, 1997.

[68] Nan C. Shu, Formal: A Forms Oriented Visual Directed Application Development System,

Computer, Vol. 18, No. 8, Aug. 1985, pp38-49.

[69] J. M. Spivey, Understanding Z - A Specification Language and its Formal Semantics.

Cambridge Tracts in Computer Science 3. Cambridge University Press, 1988.

[70] D. Teichroew, and E. Hershey, PSL/PSA: A Computer Aided Technique for Structured

Documentation and Analysis of Information Processing Systems, IEEE Transactions on

Software Engineering 3,1 (Jan 1977), pp 41-48.

[71] UML, The International Conference on the Unified Modeling Language (from year 1998

to year 2002) http://www.umlconference.org/

[72] G. Winskel, The Formal Semantics of Programming Languages: An Introduction, The

MIT Press, 1993.

[73] Yong Xia and C. W. George, “An Operational Semantics for Timed RAISE”, Proceedings

of the World Congress on Formal Methods, FM’ 99, Lecture Notes in Computer Science

Vol.1709, Springer, Berlin, 1999, pp. 1008-1027.

[74] Chaochen Zhou, C.A.R. Hoare and A.P. Ravn A Calculus of Durations Information

Processing Letter, 40, 5, pp. 269-276, 1991.

Appendix A

The complete ADORA mapping table


object name {annotation}

end

object name:external

{annotation} end

object_set name {annotation}

end

object_set name:external

{annotation} end

pure_state name


end

scenario_norm name

end

name {annotation}

{system_object_chart}

name {annotation}

{system_object_chart}

name:external{annotation}

name:external

{annotation}

name

{statechart}

name

{statechart}


[contains {system_object_chart} ]

1

1

1

[contains {system_object_chart} ]1

start_state name

end[contains {statechart} ]

1

name{statechart}

start_object name {annotation}

end

name {annotation}

{system_object_chart} [contains {system_object_chart} ]1

start_object_set name {annotation}

end

name {annotation}

{system_object_chart}[contains {system_object_chart} ]

1

Figure A.1: The complete ADORA mapping table 1

163

164 APPENDIX A. THE COMPLETE ADORA MAPPING TABLE


element_of_the_environment

name

object ***

object_i ***

scenario ***

name

name

I

name

name

scenario_iter name

end

scenario_conc name

end

scenario_seq name num_id

end

name

{statechart}

name

{statechart} | |

name

{statechart} #

*


from obj1:object

to obj2:object endname numpair

name (obj1) name (obj2)




1

1

1

scenario_alt name

end

name

{statechart} [ contains {statechart} ]1

state ***name


165


abstract_relationship name

connecting obj1:object

and obj2:object end

abstract_relationship {name}

connecting obj:object

and sc:scenario end


connecting obj:objectand e:env_object end


connecting e:env_object

and sc:scenario end

{name}

{name}

{name}

name(e)

name(obj1) name(obj2)

name(obj)

name(obj)

name(sc)

{name}name(sc)

name(e)


from obj_f:object_i



from obj_f:object_i

to s_t : state end


from s_f : state



from s_f : state

to s_t : state end


t_condition / t_action



I

name(obj_f )

I

name(obj_t )

I

name(obj_f)

I

name(obj_t )


from obj:object

to eo:env_object endname numpair

name(obj) name(eo)

name (s_f)

name (s_f)


from obj:object

to eo:env_object endname numpair

name(obj) name(eo)

name (s_t)

name (s_t)




connection

whole sc:scenario

compo sc_c:scenario_alt

end

…

name(sc)

name(sc_c)

{statechart}

…name(sc_c)

{statechart}

| |

…

name(sc)

name(sc_c)

{statechart} #

name(sc)

name(sc)

name

[statechart]

connectionwhole sc:scenario

compo sc_c:scenario_concend

connection

whole sc:scenariocompo sc_c:scenario_seqend

connection

whole sc:scenariocompo sc_c:scenario_iterend

connection

whole sc:scenario

compo sc_c:scenario_norm

end

…

name(sc)

name(sc_c)

{statechart}

*


167


a

ar

interrelationship

sub a:association

super ar:abstract_relationship

end

ar1

ar2

interrelationship

sub ar1:abstract_relationship

super ar2:abstract_relationship

end


Appendix B

Attributed EBNF Syntax on ADORA

Specification 1

specification ::= { specification fragment }specification fragment ::= { model element }model element ::=object | state | scenario | relationship | annotation

Chart

system object chart ::= system object ∪ {system object | relationship | transition | connection}

statechart ::= state ∪ {state | transition}pure statechart ::= statechart

generic statechart ::= { stateobject group }1

stateobject group ::= stateobject ∪ {stateobject | transition}

scenariochart ::= scenario ∪ {scenario | connection}

Types

DateType ::= Bool | Nat | Int | Real | Char | String | SelfDefinedType

SelfDefinedType ::= ListTyp | StructureTyp | ...

Literal ::= FloatingPointLiteral | IntegerLiteral | CharacterLiteral |StringLiteral | BooleanLiteral | NullLiteral

1We finished the syntax definition for the most part of the ADORA langauge. As the ADORA langauge is stillevolving (e.g. Requirement Engineering Research Group in University of Zurich is now intensively working onextending ADORA to support the mechanisms of aspect oriented specifications), the language definition is notfrozen, but will evolve too. Therefore, a few details on the syntax definition are intentionally left open here.

169

170 APPENDIX B. ATTRIBUTED EBNF SYNTAX ON ADORA

IntegerLiteral ::=NonNegativeIntegerLiteral | NegativeIntegerLiteral

numpair ::=num1:NonNegativeIntegerLiteral “,” num2:NonNegativeIntegerLiteralConstraints: num1 ≤ num2

num id ::= NonNegativeIntegerLiteral

obj name ::= namerel name ::= namevar name ::= nameoper name ::= namename := identifierst name ::= StringLiteralsc name ::= StringLiteral

. . .

Expression

expression ::= logicalExpression | algebraicExpressionlogicalExpression ::= quantifiedExpression | unaryExpression | atomicExpression

quantifiedExpression ::= (“forAll” | “exists”) var name · logicalExpressionunaryExpression ::= “¬” logicalExpressionatomicExpression ::= Term RelOp TermTerm ::= var name | Literal

algebraicExpression ::= binaryExpression | statementExpression | ...binaryExpression ::= expression (“&” | “|” | “→” | “↔” ) expressionstatementExpression ::= var name AlgOp expression...

Operator

RelOp ::= “=” | “<” | “>” | “≤” | “≥” | “�=”

AlgOp ::= “:=” | ...

. . .

Annotation

annotation ::= . . .

171

Objects/States/Scenario declarations

object ::= object i | singleton object e | object set e

system object ::= object i | state | scenario |singleton object e | object set e

object i ::= singleton object | object set | start object | start object setsingleton object ::= object obj name [obj body] endstart object ::= start object name [obj body] endsingleton object e ::= object obj name “: external” endobject set ::= object set obj name [obj body] endstart object set ::= start object set name [obj body] endobject set e ::= object set obj name “: external” endenv object ::= element of the environment obj nameobj body ::={annotation} [attributes {attribute}1][operations {operation}1] [contains {system object chart}1]

attribute ::= [“var”] VariableDeclaration “;” VariableDeclarationVariableDeclaration ::= var name “:” DateType

operation ::= [“local”] OperationSignature LocalVariable precondition postcondition “end operation”OperationSignature ::= “operation” oper name “(” parameterlist “)”LocalVariable ::= [“local var”] VariableDeclaration “;” VariableDeclaration

precondition ::= “entry” expressionpostcondition ::= “exit” expression

stateobject ::= state | object istate ::= pure state | start statepure state ::= state st name stateID [contains {statechart}1] endstart state ::= start state st name stateID [contains {statechart}1] endgeneric start state ::= start state | start object | start object setscenario ::= scenario norm | scenario alt | scenario iter | scenario conc | scenario seqscenario norm ::= scenario norm sc name [contains {statechart}1] endscenario alt ::= scenario alt sc name [contains {statechart}1] endscenario iter ::= scenario iter sc name [contains {statechart}1] endscenario conc ::= scenario conc sc name [contains {statechart}1] endscenario seq ::= scenario seq sc name NumberID [contains {statechart}1] end

Relationship/Transition/Connection declarations

relationship ::=association | abstract relationship | interrelationship


association ::= association rel name numpairfrom obj1:object to obj2:objectConstraints:

obj1.pre ⊃/ obj2.pre ∧ obj2.pre ⊃/ obj1.preend

abstract relationship ::=abstract relationship {rel name} a relationshipIDconnecting obj1:object and obj2:object end |abstract relationship {rel name} a relationshipIDconnecting obj:object and sc:scenario end |abstract relationship {rel name} a relationshipIDconnecting obj:object and e:env object end |abstract relationship {rel name} a relationshipIDconnecting sc:scenario and e:env object end

interrelationship ::= interrelationship interrelationshipIDsub a:associationsuper ar:abstract relationshipend |interrelationship interrelationshipIDsub ar1 : abstract relationshipsuper ar2 : abstract relationshipend

transition ::= transition transitionID t condition/t actionfrom obj f:object i to obj t:object iConstraints:(obj f.pre � obj t.pre) ∨ (obj f.pre � obj t.pre) ∨ (obj f.pre � obj t.pre)end |transition transitionID t condition/t actionfrom obj f:object i to s t:stateConstraints:∃ S:state • S ∈ s t.pre ∧ ( S.pre � obj f.pre ∨ S.pre � obj f.pre)end |transition transitionID t condition/t actionfrom s f:state to obj t:object iConstraints:∃ S:state • S ∈ s f.pre ∧ ( S.pre � obj t.pre ∨ S.pre � obj t.pre)end |transition transitionID t condition/t actionfrom s f:state to s t:stateConstraints:∃ S1, S2:state • (S1 ∈ s f.pre) ∧ (S2 ∈ s t.pre) land (S1 � S2)end

173

t condition ::= message “∧” con attribute | message | con attributecon attribute ::= logicalExpression

message ::={“receive” message contents “over” a:association |“receive” message contents “from” obj:object |“receive” message contents “from” eo:env object}1 {& message}

message contents ::= StringLiteralt action ::= message sending “∧” manipulation part | message sending | manipulation part

message sending ::={“send” message contents “over” a:association |“send” message contents “to” obj:object}1 {& message sending}

manipulation part ::= algebraicExpression. . .

connection ::=connection connectionID

whole sc:scenario compo sc c:scenario norm end |whole sc:scenario compo sc c:scenario alt end |whole sc:scenario compo sc c:scenario conc end |whole sc:scenario compo sc c:scenario seq end |whole sc:scenario compo sc c:scenario iter end

. . .

Appendix C

Operational Rules in the Structural View

In order to make the contents of this dissertation complete, the complete rules set, which are written in

the pre/post-condition form, are listed as follows. They may also help users to understand the previous

section.

We list the whole syntactic functions here.

C.1 Syntactic Functions

Let M be an ADORA model with X, Y, Z : model element, A, B, C, D, E, F : object,

r : association, u, u1, u2, u3 : abstract relationship and let Γ be a partial view of M .

• abstracted(X, Γ) is a boolean function that is true if and only if X is not visible in Γ because of

the command of the users, instead of the invisibility of its outer Objects (in which X is embedded).

• concretized(X, Γ) is a boolean function that is true if and only if users make X is visible in Γ.

By definition holds

concretized(X, Γ) = ¬abstracted(X, Γ) for all X and Γ.

• visible(X, Γ) is a boolean function that is true if and only if X is visible in Γ.

For a set of model elements, visible({X, Y, Z}, Γ) means visible(X, Γ) ∧ visible(Y, Γ) ∧visible(Z, Γ).

• hidden(X, Γ) is a boolean function that is true if and only if X is not visible in Γ. This function

is defined for convenience only. By definition holds

hidden(X, Γ) = ¬visible(X, Γ) for all X and Γ.

• partial(A, Γ) is a boolean function that is true if and only if the name of A in Γ is followed by

three dots. When it is false, if there are three dots following the name of A in Γ, they should be

deleted.

• The meaning of the ⊂ and � operators is extended to relationships as follows.

– r(A, B) ⊃ u(C, D) if and only if A.pre ⊃ C.pre and B.pre ⊃ D.pre.

– r � u, if and only if r ⊃ u and there is no u1 in Γ, such that r ⊃ u1 ⊃ u.

– u1(A, B) ⊃ u2(C, D) if and only if A.pre ⊃ C.pre and B.pre ⊃ D.pre.

175

176 APPENDIX C. OPERATIONAL RULES IN THE STRUCTURAL VIEW

– u1 � u2, if and only if u1 ⊃ u2 and there is no u3 in Γ, such that u1 ⊃ u3 ⊃ u2.

• O�⊇A if and only if O.pre ⊇ A.pre, visible(A, Γ) and for any object C if C.pre ⊃ A.pre and

O.pre ⊇ C.pre then hidden(C, Γ) is true.

According to this definition if visible(O, Γ) then O = A.

• O⊇A if and only if O.pre ⊃ A.pre and for any object C if C.pre ⊇ A.pre and O.pre ⊇ C.pre

then abstracted(C, Γ) is false.

• inbetween(r(A, B), u(C, D), u1(E, F ), Γ) is a boolean function that is true if and only if


– r � u ∧ u ∈ Γ ∧ u1 ∈/ Γ and

– visible({E, F}, Γ) and

– r � u1 � u, if we would add u1 into Γ.

• abs rel(r(A, B), u(C, D), Γ) is a boolean function that is true if and only if


– u ∈/ Γ and

– visible({C, D}, Γ) and

– r � u, if we would add u into Γ– there exists no u1 in Γ, such that r ⊃ u1.

• related(B, A) is a boolean function that is true if and only if B ∈ {D | D⊇E}, where E ∈ {F |F ⊆ A}.

• related(r(B, C), A) and related(u(B, C), A) are boolean functions that are true if and only if

either related(B, A) = true or related(C, A) = true.

What is more, related({r, u1, u2}, A) means related(r, A) ∧ related(u1, A) ∧ related(u2, A).

C.2 General Format of Rules

Every operational rule has the following format.

Rule rule-name (parameters)Given: M ; Γ; model elements

Condition: predicate pre

Assertion: predicate post

Next Rule: rule-name (parameters)

Rule names need not be unique; we may have more than one rule with the same name but with differ-

ent conditions. A rule is interpreted as follows: for any ADORA model M which contains the given

model elements and has a partial model Γ such that predicate pre is true, the application of the rule

modifies Γ so that predicate post becomes true. The application of the rule does not modify anything

that is not specified in predicate post. If the Next Rule field contains a name, the rule(s) matching this

name must be applied next in order to transform a syntactically correct view Γ eventually into a new

view Γ1 which is also syntactically correct. When the conditions (predicate pre) of all matching rules

C.3. ABSTRACTION 177

in the group are false, the next executed group of the rules is indicated by the second part of the group

name (in the brackets). When the second part of the group name is “=⇒ ∅” or the Next Rule field is

marked by a “∅” symbol, rule execution stops. Parameters are used to transfer information from a rule to

the next one.

C.3 Abstraction

Abstract an object




Hide an object

Group 1.



Condition: (A.pre � X.pre) ∧ visible({A, X}, Γ)∧(¬∃Y : Object • (Y.pre ⊃ A.pre ∧ visible(Y, Γ)))

Assertion: hidden(A, Γ) ∧ partial(X, Γ)Next Rule: Abstract a relationship - Group 1 (A)



Condition: (A.pre � X.pre) ∧ visible({A, X}, Γ)∧(∃Y : Object • (Y.pre ⊃ A.pre ∧ visible(Y, Γ)))

Assertion: hidden(A, Γ) ∧ partial(X, Γ)Next Rule: Hide an object - Group 2 (A)


Given: M ; Γ; A : object;Condition: (A.pre = {A}) ∧ visible(A, Γ) ∧ (¬∃Y : Object • (Y.pre ⊃ A.pre ∧ visible(Y, Γ)))Assertion: hidden(A, Γ)Next Rule: Abstract a relationship - Group 1 (A)



Given: M ; Γ; A : object;Condition: (A.pre = {A}) ∧ visible(A, Γ) ∧ (∃Y : Object • (Y.pre ⊃ A.pre ∧ visible(Y, Γ)))Assertion: hidden(A, Γ)Next Rule: Hide an object - Group 2 (A)

Group 2. (=⇒ Abstract a relationship (A))


Given: M ; Γ; A, X : object

Condition: (X.pre ⊃ A.pre) ∧ visible(X, Γ)Assertion: hidden(X, Γ) ∧ ∀O : object ∀r : association ∀x, y, z : abstract relationship•

((x(X, O) ∈ Γ) → (¬∃α : interrelationship • α(x, y) ∈ Γ))∧((r(X, O) ∈ Γ) → (hidden(r, Γ) ∧ ¬∃β : interrelationship • β(r, z) ∈ Γ))

Next Rule: Hide an object - Group 3 (A, X)

Group 3.

Rule Hide an object (A, X)


Condition: true

Assertion: ∀O : object¬∃x : abstract relationship • (x(X, O) ∈ Γ)Next Rule: Hide an object - Group 2 (A)


Group 1. (=⇒ ∅)


Given: M ; Γ; A, B : object; r(A, B) : association

Condition: (A.pre = {A}) ∧ hidden(A, Γ) ∧ visible({B, r(A, B)}, Γ)Assertion: hidden(r(A, B))∧

(∀z : abstract relationship¬∃α : interrelationship • α(r, z) ∈ Γ)Next Rule: Abstract a relationship - Group 1 (A)



Condition: (A.pre = {A}) ∧ hidden(A, Γ) ∧ visible(B, Γ)Assertion: (∀z : abstract relationship¬∃α : interrelationship • α(ar, z) ∈ Γ)Next Rule: Abstract a relationship - Group 4 (A, ar)

C.3. ABSTRACTION 179



Condition: (A.pre � X.pre) ∧ hidden(A, Γ) ∧ visible(X, Γ)∧Assertion: ∀B, C, D : object∀x, y : abstract relationship •

(x(A, B) ∈ Γ ∧ y(D, C) ∈ Γ) → (¬∃α : interrelationship • α(x, y) ∈ Γ)Next Rule: Abstract a relationship - Group 2 (A)

Group 2.



Condition: true

Assertion: ∀O : object¬∃x : abstract relationship • x(A, O) ∈ ΓNext Rule: Abstract a relationship - Group 3 (A)

Group 3. (=⇒ ∅)


Given: M ; Γ; X : object i; A, B : object; r(A, B) : association

Condition: (A.pre � X.pre) ∧ (¬(B.pre � X.pre)) ∧ hidden(A, Γ) ∧ visible({B, X, r(A, B)}, Γ)Assertion: hidden(r(A, B)) ∧ ∃ar : abstract relationship • (ar(X, B) ∈ Γ) ∧

∀z : abstract relationship ¬∃α : interrelationship • α(r, z) ∈ ΓNext Rule: Adjust interrelationship (A, ar)

Note: this rule specifies a special case of what the next rule does!


Given: M ; Γ; X : object i; A, B, C, D : object; r(C, D) : association

Condition: (A.pre � X.pre) ∧ (¬(B.pre � X.pre)) ∧ hidden({A, C}, Γ)∧visible({X, B}, Γ) ∧ (C.pre ⊇ A.pre ∧ D�⊇B)

Assertion: hidden(r(C, D)) ∧ (∃ar : abstract relationship • (ar(X, B) ∈ Γ)) ∧∀z : abstract relationship ¬∃α : interrelationship • α(r, z) ∈ Γ

Next Rule: Adjust interrelationship (A, ar)


Given: M ; Γ; X : object i; A, B : object

Condition: (A.pre � X.pre) ∧ (B.pre � X.pre) ∧ hidden(A, Γ)∧visible(B, Γ)

Assertion: ∀r : association • hidden(r(A, B), Γ)Next Rule: Abstract a relationship - Group 3 (A)


Group 4.

Rule Abstract a relationship (A, ar)


Condition: true

Assertion: ar(A, B) ∈/ ΓNext Rule: Abstract a relationship - Group 1 (A)

Adjust interrelationships (=⇒ Abstract a relationship - Group 3. (A))

Rule Adjust interrelationships (A, ar)


Condition: (s � ar) ∧ visible(s, Γ) ∧ ¬∃α : interrelationship • α(s, ar) ∈ ΓAssertion: ∃α : interrelationship • α(s, ar) ∈ ΓNext Rule: Adjust interrelationships (A, ar)


Given: M ; Γ;; as, ar : abstract relationship

Condition: (as � ar) ∧ visible(as,Γ) ∧ ¬∃α : interrelationship • α(as, ar) ∈ ΓAssertion: ∃α : interrelationship • α(as, ar) ∈ ΓNext Rule: Adjust interrelationships (A, ar)



Condition: (ar � z) ∧ ¬∃α : interrelationship • α(ar, z) ∈ ΓAssertion: ∃α : interrelationship • α(ar, z) ∈ ΓNext Rule: Adjust interrelationships (A, ar)



Condition: visible(s, Γ) ∧ (s � ar � z) ∧ ∃α : interrelationship • α(s, z) ∈ ΓAssertion: ¬∃α : interrelationship • α(s, z) ∈ ΓNext Rule: Adjust interrelationships (A, ar)


Given: M ; Γ; as, ar, z : abstract relationship

Condition: visible(as,Γ) ∧ (as � ar � z) ∧ ∃α : interrelationship • α(as, z) ∈ ΓAssertion: ¬∃α : interrelationship • α(as, z) ∈ ΓNext Rule: Adjust interrelationships (A, ar)

C.4. CONCRETIZATION 181

C.4 Concretization




Condition: hidden(A, Γ)Assertion: ¬abstracted(A, Γ)Next Rule: Show objects and assoications (A)





(visible(B, Γ) ∧ ¬abstracted(B) ∧ (∀C : object•((∀r : association • (r(B, C) ∈ Γ ∧ visible(C, Γ)) → visible(r, Γ))∧(∀D : object • (D⊇B) →(visible(D, Γ) ∧ (∀C : object•((∀r : association • (r(D, C) ∈ Γ ∧ visible(C, Γ)) → visible(r, Γ))

Next Rule: Adjust objects’ partial signs (A)

Adjust objects’ partial signs

Rule Adjust objects’ partial signs (A)


Condition: true

Assertion: ∀B : object • ((related(B, A)∧(((¬∃C : object • hidden(C, Γ) ∧ C.pre � B.pre) → ¬partial(B, Γ))∧((∃C : object • hidden(C, Γ) ∧ C.pre � B.pre) → partial(B, Γ)))





Condition: related(ar, A) ∧ (¬∃r : association • hidden(r, Γ) ∧ (r � ar))∧(¬∃r1 : association, α : interrelationship • α(r1, ar) ∈ Γ)∧(¬∃ar1 : abstract relationship, α : interrelationship•α(ar1, ar) ∈ Γ ∨ α(ar, ar1) ∈ Γ)




Given: M ; Γ; A : object; ar : abstract relationship∧Condition: related(ar, A) ∧ (¬∃r : association • hidden(r, Γ) ∧ (r � ar))∧

((∃r1 : association, α : interrelationship • α(r1, ar) ∈ Γ)∧(∃ar1 : abstract relationship, α : interrelationship•α(ar1, ar) ∈ Γ ∨ α(ar, ar1) ∈ Γ))






Assertion: ar2 ∈ ΓNext Rule: Adjust interrelationships (A)


Given: M ; Γ; A : object; r : association

Condition: hidden(r, Γ)Assertion: ∃u : abstract relationship • (abs rel(r, u, Γ) ∧ related(u, A)) → (u ∈ Γ)Next Rule: Adjust interrelationships (A)


Rule Adjust interrelationships (A)


Condition: true

Assertion: (∀α : interrelationship, ar, as : abstract relationship, r : association •((related({ar, as}, A)) ∧ (ar � as ↔ α(ar, as) ∈ Γ))∨((related({r, as}, A)) ∧ (r � as ∧ visible(r, Γ)) ↔ α(r, as) ∈ Γ))

Next Rule: ∅

C.5. REMARK 183

C.5 Remark

C.5.1 Explanation on Abstraction

The following diagram tries to summarize most situations of abstracting an object.

C

B

s

ar

z

γ

δD ...

E ... F

A

C

B

s

r

z

αβD

A1

E ... F

a)

b)

Figure C.1: Summary of the operational rules on abstraction – general situation

We use this diagram to explain the meanings of the operational rules.

When object A is abstracted, a sequence of transitions of the model occur:

1. The embedded object A1 should be also hidden from the view (This is specified by Rules “Hide

an object - Group 1”).

2. Association r will be also hidden (by rules “Abstract a relationship - Group 3”).

3. An abstracted relationship ar, which connects object D and B, will be generated (by rules

“Abstract a relationship - Group 3”). Notice that the previous hidden association r connects

object A, which is directly embedded in object D. That is why, an abstracted relationship

connecting D is generated.

4. Interrelationship α and β will be deleted (by rules “Adjust interrelationships”).

5. Interrelationship δ and γ will be generated (by rules “Adjust interrelationships”). Notice that,

there exists no interrelationship ϕ connecting association s and abstract relationship z,

while s ⊃ ar and ar ⊃ z hold in the model.

Some groups of rules, which are not mentioned above, are given to specify some special situations.

See the following diagrams.

In the Fig C.2, if there exist objects inside object A (such as object A1) and there exist associations

or abstract relationships connecting with those embedded objects (such as association r1), all of

them (including interrationships connecting associations and abstract relationships, such as η)


A

C

B

s

r

z

αβD

A1r1

E ...F

CB

s

z

γ

δD ...

ar

E ... F

η

Figure C.2: Summary of the operational rules on abstraction – special situation 1

should be hidden or deleted, when Object A is hidden. This is specified by rules “Hide an object - Group

2” and “Hide an object - Group 3”.

A

C

B ...

s

ar1

z

αβD

A1

E ...F

CB

s

z

γ

δD ...E ... F

ar


In the Fig C.3, if there exists abstract relationships connecting with object A, such as

abstract relationship ar1, they will be deleted when A is abstracted. What is more,

the interrelationships connecting them, such as interrelationship α, will also be deleted. This is

specified by rules “Abstract a relationship - Group 1” and “Abstract a relationship - Group 2”.

Fig C.4 gives the situation that object A is an outermost object. Rules “Hide an object - Group 1”

and “Abstract a relationship - Group 1” specify this situation.

The situation in Fig C.5 is specified by rules “Adjust interrelationships”. If there is an

abstract relationship as, where as ⊃ ar holds after view transitions, an interrelationship γ will be

generated.

C.5. REMARK 185

A

C

B

s

r

F

A1

CB

sF


C

B ...

as

ar

z

γ

δD ...

E ... F

A

C

B ...

as

r

z

αβD

A1

E ... F

a)

b)


C.5.2 Explanation on Concretization

The following diagrams try to summarize most situations of concretizing an object.

We have a specification, which is shown in Fig C.6. Suppose a user did the following steps sequen-

tially:

1. abstract object F ,

2. abstract object A,

3. abstract object J ,

4. abstract object F1,

5. abstract object D,

6. concretize object A

After Step 5, the diagram is like Fig C.7.

After Step 6 (concretize object A), the diagram is like Fig C.8.

We can see the following intuitive meanings from these 3 diagrams.


A

C

I

B

D

G

s

rH

E

F

E1

F1

Jt

Figure C.6: View transitions of an object concretization

I

G ... ar

H

Figure C.7: View transitions of an object concretization - step 2

1. Once an object (in this example, object A) is concretized, all the objects, which contain the

concretized object, will also become concrete and visible (in this example, object B and object D

will be visible. See the rules of “Concretization - Show objects and association”).

2. All the objects, which are embedded in the above “concretized” objects will become visible, if:

• they are not abstracted, and

• they are not embedded in an abstracted object.

(in this example, object E and C becomes visible; object F, F1, J are still invisible, because they

are abstracted. See the rules of “Concretization - Show objects and association”). Here, we can see

the usage of meta-functions “abstracted” and “hidden” again. The history of the view transitions

plays an important role. I.e. after concretization of A, only the objects, which are hidden because

of the abstraction of A, will be visible.

3. As object A is again visible, association r, which connects with object A and object I , will

become visible (See the rules of “Concretization - Show objects and association”).

4. As object J is still invisible, abstract relationship ar will still be there (See the rules of “Con-

cretization - Adjust abstract relationship”. Actually no preconditions of the rules in that subsection

are true. Therefore, ar keeps unchanged).

5. As object F1 is still invisible, however, E1 is visible. According to the third rule in “Concretiza-

tion - Adjust abstract relationship”, an abstract relationship as will be generated.

6. At last, interrelationships will be adjusted, according to the following rule:

C.5. REMARK 187

A

C

I

B

D

G ... ar

as

r

HE ...

E1 ...

Figure C.8: View transitions of an object concretization - step 3

• if and only if there are two abstract relationship ar and as, or a association r and an

abstract relationship as, where r � as or ar � as holds, there exists an interrelationship

between them.

C.5.3 Reflexive Abstract Relationships

Because in ADORA we treat reflexive abstract relationships differently from normal abstract relation-

ships, here we use a separate section to explain them.

A'

AB'

Br

A' ... B' ...ar

A'

A r

A'

A Cr

A' ...

hide A; hide B

hide A ; hide C

A' ...

Diagram 1 Diagram 2 Diagram 3

hide A

Figure C.9: Reflexive abstract relationships

As shown in Figure C.9, syntactically correct view transitions of abstracting an object look normally

like Diagram 1.

However, in the situations shown in Diagram 2 1 and Diagram 3 2, no reflexive abstract relationships

1There is an association connecting two objects, both of which are parts of a common object, and one of thosetwo object is abstracted.

2An object, which is a part of another object, has a reflexive association and this object with a reflexive associ-ation is abstracted.


will be generated. The reason is that reflexive abstract relationships do not provide truly important

information during modelling processes.

Appendix D

Operational rules for the evolutionary

specifications

In this section, we list the full set of operational rules for the evolutionary specifications.

D.1 Syntactical Functions

Most of the syntactical functions and other notations are the same as that in Appendix C. In this subsec-

tion only the extended functions will be listed.

• inbetween(ar(A, B), u(C, D), u1(E, F ), Γ) is a boolean function that is true if and only if

– ar � u ∧ ar ∈ M ∧ ar ∈/ Γ and

– u ∈ Γ ∧ u1 ∈/ Γ and

– visible({E, F}, Γ) and

– r � u1 � u, if we would add u1 into Γ.

• abs rel(ar(A, B), u(C, D), Γ) is a boolean function that is true if and only if

– ar ∈/ Γ ∧ ar ∈ M is true, and

– u ∈/ Γ and

– visible({C, D}, Γ) and

– ar � u, if we would add u into Γ– there exists no u1 in Γ, such that ar ⊃ u1.

D.2 Reflexive Abstract Relationships

In ADORA, manually generated reflexive abstract relationships are not allowed.

189

190APPENDIX D. OPERATIONAL RULES FOR THE EVOLUTIONARY SPECIFICATIONS

D.3 Abstraction - Incomplete Specification

Abstract an object




Hide an object

Group 1.



Condition: (A.pre � X.pre) ∧ visible({A, X}, Γ)∧(¬∃Y : Object • (Y.pre ⊃ A.pre ∧ visible(Y, Γ)))

Assertion: hidden(A, Γ) ∧ partial(X, Γ)Next Rule: Abstract a relationship - Group 1 (A)



Condition: (A.pre � X.pre) ∧ visible({A, X}, Γ)∧(∃Y : Object • (Y.pre ⊃ A.pre ∧ visible(Y, Γ)))

Assertion: hidden(A, Γ) ∧ partial(X, Γ)Next Rule: Hide an object - Group 2 (A)


Given: M ; Γ; A : object;Condition: (A.pre = {A}) ∧ visible(A, Γ) ∧ (¬∃Y : Object • (Y.pre ⊃ A.pre ∧ visible(Y, Γ)))Assertion: hidden(A, Γ)Next Rule: Abstract a relationship - Group 1 (A)


Given: M ; Γ; A : object;Condition: (A.pre = {A}) ∧ visible(A, Γ) ∧ (∃Y : Object • (Y.pre ⊃ A.pre ∧ visible(Y, Γ)))Assertion: hidden(A, Γ)Next Rule: Hide an object - Group 2 (A)

D.3. ABSTRACTION - INCOMPLETE SPECIFICATION 191

Group 2. (=⇒ Abstract a relationship (A))



Condition: (X.pre ⊃ A.pre) ∧ visible(X, Γ)Assertion: hidden(X, Γ) ∧ ∀O : object ∀r : association ∀x, y, z : abstract relationship•

((x(X, O) ∈ Γ) → (¬∃α : interrelationship • α(x, y) ∈ Γ))∧((r(X, O) ∈ Γ) → (hidden(r, Γ) ∧ ¬∃β : interrelationship • β(r, z) ∈ Γ))

Next Rule: Hide an object - Group 3 (A, X)

Group 3.

Rule Hide an object (A, X)


Condition: true

Assertion: ∀O : object¬∃x : abstract relationship • (x(X, O) ∈ Γ)Next Rule: Hide an object - Group 2 (A)


Group 1. (=⇒ ∅)


Given: M ; Γ; A, B : object; r(A, B) : association

Condition: (A.pre = {A}) ∧ hidden(A, Γ) ∧ visible({B, r(A, B)}, Γ)Assertion: hidden(r(A, B))∧

(∀z : abstract relationship¬∃α : interrelationship • α(r, z) ∈ Γ)Next Rule: Abstract a relationship - Group 1 (A)



Condition: (A.pre = {A}) ∧ hidden(A, Γ) ∧ visible(B, Γ)Assertion: (∀z : abstract relationship¬∃α : interrelationship • α(ar, z) ∈ Γ)Next Rule: Abstract a relationship - Group 4 (A, ar)



Condition: (A.pre � X.pre) ∧ hidden(A, Γ) ∧ visible(X, Γ)∧Assertion: ∀B, C, D : object∀x, y : abstract relationship •

(x(A, B) ∈ Γ ∧ y(D, C) ∈ Γ) → (¬∃α : interrelationship • α(x, y) ∈ Γ)Next Rule: Abstract a relationship - Group 2 (A)


Group 2.



Condition: true

Assertion: ∀O : object¬∃x : abstract relationship • x(A, O) ∈ ΓNext Rule: Abstract a relationship - Group 3 (A)

Group 3. (=⇒ ∅)


Given: M ; Γ; X : object i; B, C, D : object; r(C, D) : association

Condition: (A.pre � X.pre) ∧ hidden({A, C}, Γ) ∧ visible({X, B}, Γ)∧(¬(B.pre � X.pre)) ∧ (C.pre ⊇ A.pre ∧ D�⊇B)

Assertion: hidden(r(C, D)) ∧ (∃ar : abstract relationship • (ar(X, B) ∈ Γ)) ∧∀z : abstract relationship ¬∃α : interrelationship • α(r, z) ∈ Γ



Given: M ; Γ; X : object i; A, B, C, D : object; u(C, D) : abstract relationship

Condition: (A.pre � X.pre) ∧ hidden({A, C}, Γ) ∧ visible({X, B}, Γ)∧(u(C, D) ∈ M) ∧ (¬(B.pre � X.pre)) ∧ (C.pre ⊇ A.pre ∧ D�⊇B)

Assertion: (u ∈/ Γ) ∧ (∃ar : abstract relationship • (ar(X, B) ∈ Γ)) ∧∀z : abstract relationship ¬∃α : interrelationship • α(u, z) ∈ Γ



Given: M ; Γ; X : object i; A, B : object

Condition: (A.pre � X.pre) ∧ (B.pre � X.pre) ∧ hidden(A, Γ)∧visible(B, Γ)

Assertion: ∀r : association • hidden(r(A, B), Γ)∧∀ar : abstract relationship • ((ar(A, B) ∈ M) → (ar(A, B) ∈/ Γ)

Next Rule: Abstract a relationship - Group 3 (A)

Group 4.

Rule Abstract a relationship (A, ar)


Condition: true

Assertion: ar(A, B) ∈/ ΓNext Rule: Abstract a relationship - Group 1 (A)

D.4. CONCRETIZATION - INCOMPLETE SPECIFICATION 193

Adjust interrelationships (=⇒ Abstract a relationship - Group 3. (A))



Condition: (s � ar) ∧ visible(s, Γ) ∧ ¬∃α : interrelationship • α(s, ar) ∈ ΓAssertion: ∃α : interrelationship • α(s, ar) ∈ ΓNext Rule: Adjust interrelationships (A, ar)


Given: M ; Γ;; as, ar : abstract relationship

Condition: (as � ar) ∧ visible(as,Γ) ∧ ¬∃α : interrelationship • α(as, ar) ∈ ΓAssertion: ∃α : interrelationship • α(as, ar) ∈ ΓNext Rule: Adjust interrelationships (A, ar)



Condition: (ar � z) ∧ ¬∃α : interrelationship • α(ar, z) ∈ ΓAssertion: ∃α : interrelationship • α(ar, z) ∈ ΓNext Rule: Adjust interrelationships (A, ar)



Condition: visible(s, Γ) ∧ (s � ar � z) ∧ ∃α : interrelationship • α(s, z) ∈ ΓAssertion: ¬∃α : interrelationship • α(s, z) ∈ ΓNext Rule: Adjust interrelationships (A, ar)


Given: M ; Γ; as, ar, z : abstract relationship

Condition: visible(as,Γ) ∧ (as � ar � z) ∧ ∃α : interrelationship • α(as, z) ∈ ΓAssertion: ¬∃α : interrelationship • α(as, z) ∈ ΓNext Rule: Adjust interrelationships (A, ar)

D.4 Concretization - Incomplete Specification




Condition: hidden(A, Γ)Assertion: ¬abstracted(A, Γ)Next Rule: Show objects and associations (A)






(visible(B, Γ) ∧ ¬abstracted(B) ∧ (∀C : object•((∀r : association • (r(B, C) ∈ Γ ∧ visible(C, Γ)) → visible(r, Γ))∧(∀ar : abstract relationship • (ar(B, C) ∈ M ∧ visible(C, Γ)) → ar ∈ Γ)))∧(∀D : object • (D⊇B) →(visible(D, Γ) ∧ (∀C : object•((∀r : association • (r(D, C) ∈ Γ ∧ visible(C, Γ)) → visible(r, Γ))(∀ar : abstract relationship • (ar(D, C) ∈ M ∧ visible(C, Γ)) → ar ∈ Γ))))))

Next Rule: Delete objects’ partial signs (A)

Delete objects’ partial signs

Rule Delete objects’ partial signs (A)


Condition: true

Assertion: ∀B : object • (related(B, A,Γ)∧(¬∃C : object • hidden(C, Γ) ∧ (C.pre � B.pre)∧(¬man g partial(B, M)) → ¬partial(B, Γ)))





Condition: related(ar, A, Γ) ∧ (¬∃r : association • hidden(r, Γ) ∧ (r � ar))∧(¬∃ar3 : abstract relationship • (ar3 ∈/ Γ) ∧ (ar3 ∈ M) ∧ (ar3 � ar))∧(¬∃r1 : association, α : interrelationship • α(r1, ar) ∈ Γ)∧(¬∃ar1 : abstract relationship, α : interrelationship • α(ar1, ar) ∈ Γ∨α(ar, ar1) ∈ Γ)


D.4. CONCRETIZATION - INCOMPLETE SPECIFICATION 195


Given: M ; Γ; A : object; ar : abstract relationship∧Condition: related(ar, A, Γ) ∧ (¬∃r : association • hidden(r, Γ) ∧ (r � ar))∧

(¬∃ar3 : abstract relationship • (ar3 ∈/ Γ) ∧ (ar3 ∈ M) ∧ (ar3 � ar))∧((∃r1 : association, α : interrelationship • α(r1, ar) ∈ Γ)∧(∃ar1 : abstract relationship, α : interrelationship • α(ar1, ar) ∈ Γ∨α(ar, ar1) ∈ Γ))








Given: M ; Γ; A : object; u, ar : abstract relationship

Condition: related(ar, A) ∧ (r ∈/ Γ ∧ u ∈ M) ∧ (r � ar) ∧∃ar2 : abstract relationship • inbetween(u, ar, ar2, Γ)



Given: M ; Γ; A : object; r : association

Condition: hidden(r, Γ)Assertion: ∃u : abstract relationship • (abs rel(r, u, Γ) ∧ related(u, A)) → (u ∈ Γ)Next Rule: Adjust interrelationships (A)



Condition: (ar ∈/ Γ) ∧ (ar ∈ M)Assertion: ∃u : abstract relationship • (abs rel(ar, u, Γ) ∧ related(u, A)) → (u ∈ Γ)Next Rule: Adjust interrelationships (A)



Rule Adjust interrelationships (A)


Condition: true

Assertion: (∀α : interrelationship, ar, as : abstract relationship, r : association •((related({ar, as}, A)) ∧ (ar � as ↔ α(ar, as) ∈ Γ))∨((related({r, as}, A)) ∧ (r � as ∧ visible(r, Γ)) ↔ α(r, as) ∈ Γ))

Next Rule: ∅

Appendix E

Other Global Constraints

In the above two appendixes, operational rules are used to specify the hierarchical constraints of ADORA mod-

els.

As the hierarchical constraints involve quite a lot of language elements,they usually can not be spec-

ified simply by attributing the EBNF grammar. Therefore, those constraints are also called global con-

straints.

Except for those hierarchical constraints, there are also some other global constraints in the ADORA model.

Compared with the hierarchical constraints, they are much easier to describe. Therefore, it is not nec-

essary to describe them in the form of operational rules, in which a constraint has to be expressed in a

series of sequential steps to make the constraint easily readable and implementable. Using one first-order

predicate logic formula will be expressive enough to specify those non-hierarchical global constraints.

The non-hierarchical global constraints exist in the structural view, the behavioral view, the user

view and functional view of the ADORA . As this dissertation does not serve as the specification of the

ADORA language, but mainly explains a method of the language definition, we will not list the complete

definition of global constraints. In the next section, we list the the non-hierarchical global constraints in

the user view as an example to show how they are defined.

E.1 Global Constraints in the User View

First we define some meta functions, which will be used in the constraints.

Let M be an ADORA model with C, D, E : scenario.

• To achieve a better understandability, we introduce following seven syntactical functions.

– component sce(C, D) is true if and only if Scenario C is a component of Scenario D, while

Scenario C is a normal scenario (I.e. C is in the form of scenario norm: the second line of

the table in Figure 3.3).

– sequence sce(C, D) is true if and only if Scenario C is a component of Scenario D, while

Scenario C is a scenario with a sign of “sequence”. (I.e. C is in the form of scenario seq:

the fourth line of the table in Figure 3.3).

197

198 APPENDIX E. OTHER GLOBAL CONSTRAINTS

– alternative sce(C, D) is true if and only if Scenario C is a component of Scenario D,

while Scenario C is a scenario with a sign of “alternative”.

– concurrency sce(C, D) is true if and only if Scenario C is a component of Scenario D,

while Scenario C is a scenario with a sign of “concurrency”.

– iteration sce(C, D) is true if and only if Scenario C is a component of Scenario D, while

Scenario C is a scenario with a sign of “iteration”.

– The function part of(C, D) being true means C is a sub-scenario of D. The relationship

between C and D can be one of the five types (c.f. Figure 2.3) specified in the scenariochart:

part of(C, D) = component sce(C, D) ∨ iteration sce(C, D) ∨ sequence sce(C, D) ∨alternative sce(C, D) ∨ concurrency sce(C, D)

– indirect partof(C,D) is used to describe that one scenario can be a component of

another scenario, though there is no direct connection between them. It is true, if

and only if:

1. part of(C,D) is true, or

2. part of(C,E) and part of(E,D) are true, for any Scenario E in M , or

3. part of(C,E) and indirect partof(E,D) are true, for any Scenario E in M .• Ispart of Trace is a concept, which is similar to the concept pretrace.

C.ispart returns an ordered set (aka list) of scenarios, of which Scenario C is a part (or compo-

nent).

C.ispart =

{C}ordered + D.ispart when part of(C, D) is true

{C}orderedwhen there is no scenario D′ in M,

such that part of(C, D′) = truewhere “s1 + s2” means union of s1 and s2 (“∪”) for unordered sets. It means “appending s2 after

the last element of s1” for lists (ordered sets).

• Is normalScenario(C) returns true, when Scenario C is a normal scenario, which does not has

the sign of an alternative scenario, a sequence scenario, a concurrency scenario, or an iteration

scenario.

Now we give the complete set of formal constraints in the user view with their intuitive meanings.

• All the relations between a scenario and its component scenarios are the same.

component sce(C, D) → (∀E : scenario • ¬(sequence sce(E, D)∨alternative sce(E, D) ∨ concurrency sce(E, D) ∨ iteration sce(E, D)))

∧ sequence sce(C, D) → (∀E : scenario • ¬(component sce(E, D)∨alternative sce(E, D) ∨ concurrency sce(E, D) ∨ iteration sce(E, D)))

∧ alternative sce(C, D) → (∀E : scenario • ¬(sequence sce(E, D)∨component sce(E, D) ∨ concurrency sce(E, D) ∨ iteration sce(E, D)))

∧ concurrency sce(C, D) → (∀E : scenario • ¬(sequence sce(E, D)∨

E.1. GLOBAL CONSTRAINTS IN THE USER VIEW 199

alternative sce(E, D) ∨ component sce(E, D) ∨ iteration sce(E, D)))∧ iteration sce(C, D) → (∀E : scenario • ¬(sequence sce(E, D)∨

alternative sce(E, D) ∨ concurrency sce(E, D) ∨ component sce(E, D)))

• Circular scenarios-relation is not allowed. That is to say, if Scenario C is a (indirect) component

of Scenario D, D can not be a (indirect) component of Scenario C.

indirect partof(C, D) → ¬indirect partof(D, C)For example, the scenariochart in Figure 3.16b) is syntactically wrong.

• The scenario chart should be in a form of tree, not graph.

(part of(C, D) ∧ part of(C, E)) → D = E

For example, the scenariochart in Figure 3.16c) is syntactically wrong.

• The sequence numbers of any two sequence scenarios of their super scenario should be different.

∀C, D, E : scenario • (sequence sce(C, D) ∧ sequence sce(E, D)) →(C.sequencenum �= E.sequencenum)

• Each scenario can at most have one iteration component as subscenario. This constraint is ex-

pressed as

∀C, D, E : scenario • (iteration sce(C, D) ∧ iteration sce(E, D)) → (C = E)

• If a scenario has alternative components, it has at least two such components.

∀C, D : scenario• (alternative sce(C, D) → (∃E : scenario•alternative sce(E, D)∧E �=C))

• If a scenario has sequence components, it has at least two such components.

∀C, D : scenario • (sequence sce(C, D) → (∃E : scenario • sequence sce(E, D)∧E �= C))

• If a scenario has concurrency components, it has at least two such components.

∀C, D : scenario • (concurrency sce(C, D) → (∃E : scenario • concurrency sce(E, D) ∧E �= C))

• Is normalScenario(C) is true if and only if C is in the form of scenario norm (the second line

of the table in Figure 3.3).

• Each scenariochart are in the form of a “forest”, which is consisted of several rooted trees. And

for each “tree”, the “root” scenario should be a normal scenario.

∀C : scenario • (C.ispart = {C}) → is normalScenario(C)

200 APPENDIX E. OTHER GLOBAL CONSTRAINTS

Resume

Name Yong Xia

Birthday 07-September-1972

Birthplace Shanghai

Nationality Chinese

Education and Research Activities09/1979 - 07/1991 Primary School, Middle School and High School in Shanghai

09/1991 - 07/1995 Department of Computer Science and Engineering

East China University of Science and Technology

Bachelor of Engineering in Computer Science

09/1995 - 07/1998 Department of Computer Science and Engineering

East China University of Science and Technology

Master of Engineering in Computer Science

Under the supervision of Prof. Guoxin Song

09/1997 - 10/1998 International Institute for Software Technology

United Nations University

Research Fellow

Under the supervision of Prof. Chaochen Zhou and Prof. Chris George

10/1998 - 04/1999 Computer Science and Engineering Section

Department of Informatics and Mathematical Modelling

Technical University of Denmark

Visiting Researcher

Under the supervision of Prof. Dr. Anne Haxthausen

05/1999 - 02/2004 Department of Information Technology

University of Zurich

Ph.D. Student and Research Assistant

Under the supervision of Prof. Dr. Martin Glinz

Zurich, January 2004

201

a language definition method for visual specification ...grammar also defines the syntax of the...

Documents