 

LIBRARY

Michigan State
Unlverslty

 

 

 

PLACE IN RETURN BOX
to remove this checkout from your record.
TO AVOID FINES return on or before date due.

 

DATE DUE DATE DUE DATE DUE

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

use macs-ma

 

 

 

INTEGRATING INFORMAL AND FORMAL APPROACHES
TO OBJECT-ORIENTED ANALYSIS AND DESIGN

By

Yz'le Enoch Wang

A DISSERTATION

Submitted to
Michigan State University
in partial fulﬁllment of the requirements
for the degree of

DOCTOR OF PHILOSOPHY

Department of Computer Science

May 10, 1998

Advisor: Professor Betty H. C. Cheng

INTEGR-

ll l5 Clr'dlly
mg}: the nwi
where its cum
of software. it :1
to rigort.)u.~l}' (
natatiuns

HIP

construct a ft

tit"! r ‘
JILHFII Cdl
5‘

ABSTRACT
INTEGRATING INFORMAL AND FORMAL APPROACHES TO
OBJECT-ORIENTED ANALYSIS AND DESIGN
By
Yz'le Enoch Wang

It is clearly evident that the impact of software is Signiﬁcantly increasing. Accord-
ingly, the need to have high assurance in software’s correctness increases for systems
where its correct operation is imperative. As a means to facilitate the development
Of software, formal software speciﬁcations are gaining increasing attention as a means
to rigorously document requirements and design information Since the well-deﬁned
notations are amenable to automated processing for numerous analysis tasks, in-
cluding veriﬁcation of the correctness of resulting systems. However, attempting to
construct a formal speciﬁcation directly from an informal, high-level requirements
document can be challenging. Formal descriptions potentially involve considerable
syntactic details and may require careful planning and organization on the part of
the developer in order to develop modular (easily-decomposed and amenable to reuse)
Speciﬁcations. In contrast, object-oriented analysis and development techniques, such

as the Object Modeling Technique (OMT), comprising diagramming techniques that

 

0,, .

mitt use of '11:“; ':
bdudaihnur

l

l v- ' A
dhkmﬂwuxm_

repulse fortml.
tex'eopment pr. u
spatttatit._ttts the

bitten levels of

make use of intuitive and easy to understand graphical notations, are extensively
used today. However, the informal nature of the diagramming notations and the lack
of well-deﬁned semantics pose the potential to introduce errors in the development
process, particularly as the systems become more complicated. The objective of this
research is to introduce formal semantics to the graphical notations of OMT, includ-
ing a formal deﬁnition of their integration, and to propose a process to conduct a
stepwise formal, rigorous reﬁnement of the diagrams during the design phase. The
development process should enable a semi-automated generation of executable formal
speciﬁcations that can be used to simulate the behavior and check the consistency

between levels of speciﬁcation reﬁnements.

© Copyright May 10, 1998 by Yile Enoch Wang
All Rights Reserved

T0 my (lift

to my 1

to my gra

To my dear wife, whose companionship is a blessing from God;

to my parents, who raised me to be a faithful Christian;

to my grandparents, who shed their unconditional love on me.

 

 

lat-hid Slnt‘t‘ft‘ll :1
rhcattIragerItettt atu
rat to thank Dr.
C Pijarrowslzi for
tittrzmittre.

lrotrld also 1
Chen. Gretel V. C
in the Software l
‘riz-izrss in the p.

finally. I trot;

331 must of all (

75"” Mm, .
“.5 forward I

ACKNOWLEDGMENTS

I would Sincerely like to thank my advisor, Dr. Betty H.C. Cheng, without whose
encouragement and wisdom, this dissertation would not have been possible. I also
wish to thank Dr. Philip K. McKinley, Dr. Anthony S. Wojcik, and Dr. Bryan
C. Pijanowski for their constructive suggestions and commitment for being on my
committee.

I would also like to thank Gerald C. Gannod, William E. McUmber, Yonghao
Chen, Gretel V. Coombs, Laura A. Campbell, Andrew S. Chen, and other members
in the Software Engineering Research Group for all their friendship, support, and
kindness in the past ﬁve years.

Finally, I would like to thank my wife, Tong, for all her support, understanding,
and most of all conﬁdence in me. I appreciate the sacriﬁces She has made and am

looking forward to more time together with her.

vi

 

lISI OF TABLE
llSI OF FIGL'R

1 Introduction
lPr-ohlern Dew

l‘l SIIIrtItarx oil
3Deﬁr3i Itiotts . .

‘54 Organization

2 Background
2.1 Object Rimle-
33 Formal .\lt7 ‘ l
13 S p(Illtdll'tﬁ
240 USjE‘tI .\.‘(J(lt
3 Related Wor
‘31
Jl FtJllli'dllZ [dih-
97 ‘
1* -\Jll~ ”OlJJi‘i'P'
33 c . .
o_5[tr1a1 l( -

4 Object Mod.

TABLE OF CONTENTS

LIST OF TABLES x
LIST OF FIGURES xi

1 Introduction 1
1.1 Problem Description and Motivation .................... 2
1.2 Summary of Research Contributions .................... 4
1.3 Deﬁnitions ................................... 6
1.4 Organization of Dissertation ......................... 7

2 Background 8
2.1 Object Modeling Technique Overview .................... 8
2.2 Formal Methods ............................... 12
2.3 Speciﬁcation Languages Used in Project .................. 18
2.4 Object Model Formalization ......................... 21
3 Related Work 30
3.1 Formalization of Object-Oriented Modeling Approaches .......... 30
3.2 Non-Object-Oriented Based Approaches .................. 49
3.3 Systematic Approaches to Reﬁnement of Analysis Information for Design 55
4 Object Model Formalization Revisited 60
4.1 The Derivation of Algebraic Speciﬁcations ................. 60
4.2 Distinguished Sort .............................. 61
4.3 An added formalization rule ......................... 62
4.4 Formal Representation of Algebraic Speciﬁcation ............. 65
5 Dynamic Model Formalization 67
5.1 Preliminary Formalization .......................... 68
5.2 Formalizingstate diagrams of individual objects .............. 71
5.3 Concurrent State Formalization ....................... 86
5.4 Integration with Other OMT Models .................... 94
5.5 Summary ................................... 98
6 Functional Model Formalization 99
6.1 The Data Flow Diagram (DFD) ....................... 101
6.2 DFD Notation Modiﬁcation ......................... 103
6.3 Integrating the Functional Model into OOD ................ 110

vii

i. 'I‘ '1 l
61 Fllllt‘llttlldl .\I..
It.) lit-.3193 atltII‘I \3‘3'

.36 Summary

7 Model lutegr:
7.1 Integratiun of
7.3 The Corretrtt.
.3

I. Spti‘lﬁtdltul.
71 Analysis of .‘I
8 Design Proce
‘l O'I'E‘l'l'lﬂt' Ui-
iil IhePrI'mt-sr
5.3 The Design
3.4 Summary

9 Case Study
9.1 The Project
7 Focus of th.
3 Overview o:
l

3

'1'.
9'.
‘1

3 System 1.3

5}'Stem De:
Design Ana
Summary

9

93
'3.‘

19 Conclusion

it} .
«1 Summary I
23.2 I '

Impact ()f '
BIBLIOGRA‘.

viii

6.4 Functional Model Formalization ....................... 116
6.5 Integration with Object and Dynamic Models ............... 145
6.6 Summary ................................... 146
7 Model Integration and Analysis 147
7.1 Integration of the Three Models of OMT .................. 147
7.2 The Correctness, Consistency, and Completeness of the Formalization Rulesl51
7.3 Speciﬁcation Analysis Techniques ...................... 153
7.4 Analysis of Model Integration ........................ 158
8 Design Process 165
8.1 Overview of Strategies Proposed Approach ................. 168
8.2 The Proposed Rigorous Design Process ................... 171
8.3 The Design Process Applied to An Example ................ 178
8.4 Summary ................................... 206
9 Case Study 209
9.1 The Project .................................. 210
9.2 Focus of the Case Study ........................... 213
9.3 Overview of the Requirements Analysis ................... 213
9.4 System Level Modeling ............................ 215
9.5 System Design ................................ 225
9.6 Design Analysis and Reﬁnement ....................... 245
9.7 Summary ................................... 267
10 Conclusions and Future Investigations 269
10.1 Summary of Contributions .......................... 270
10.2 Impact of Research and Future Investigations ............... 273
BIBLIOGRAPHY 276
APPENDICES 284
A The Object Model Formalization Rules 284
B The Dynamic Model Formalization Rules 286
C The Functional Model Formalization Rules 291
D Complete LOTOS speciﬁcation for Disk Manager Behavior 296
E Instantiated LOTOS speciﬁcation for Disk Manager 299
F LSL speciﬁcations 301
G LOTOS speciﬁcation for revised Disk Manager 303

H Complete LOl

ix

H Complete LOTOS speciﬁcation of EN FORMS for static analysis 306

 

3.1 The models t

LIST OF TABLES

8.1 The models that will be developed during a given iteration of design . . . 173

l .A 111611131111} 5
13 A generlt‘ til;
3.3 .An (.Iperat It
3.1 .A dt’lll.rldllHI
2.3 A Larch alIv
3.6 .A typical L(.
..I BasiIC ap 1TH;
2.5 HIgh-lexil 5t
.ASIII'Iple I31.
111. The Corn» \‘Y ,
3113mm cm 11

31'. Sun mar} II

-\.J

~13 ASIIIIIIEE" 31.,
214 .Ahtgh luv
15 .eAhi g-h 1+th

Iv

The ACT (

A Sample 5

he 3mm;
medal

41
A?
43

A 111110131 5
'A t‘ph'dl 5
The State.

A C07] 7

5.1
3.?
5.3
5.1 r:
)3 The Std? (I
73.1 T11; ‘pft
J5 A San};1
39f I“ d n ,
. TAII'
3‘1 Spp(lﬁ(ae
3.153 , ‘ -.
. l~ SdUlplp SI
5.}
r 3 ill-Ural
1‘ r I
t“) ‘ 31:3,;
"J

l

LIST or FIGURES

2.1 A predicate speciﬁcation of integer square root ............... 14
2.2 A generic algebraic speciﬁcation of stack .................. 15
2.3 An operational speciﬁcation of integer square root ............. 16
2.4 A denotational speciﬁcation of boolean expression ............. 18
2.5 A Larch algebraic speciﬁcation of table ................... 19
2.6 A typical LOTOS process algebra speciﬁcation ............... 21
2.7 Basic approach to formalization ........................ 22
2.8 High-level structure of LSL speciﬁcations .................. 23
2.9 A simple object model ............................ 25
2.10 The corresponding algebraic speciﬁcation of Figure 2.9 .......... 25
2.11 Summary of Object Model Semantics .................... 26
2.12 Summary of Object Model Semantics (continued) ............. 27
2.13 A simpliﬁed disk manager .......................... 27
2.14 A high-level Storage class speciﬁed in Larch ................ 28
2.15 A high-level Storage class speciﬁed in ACT ONE ............. 29
4.1 The ACT ONE Speciﬁcation for person .................. 63
4.2 A sample object model that contains attributes for object O ....... 64
4.3 The automatically generated formal speciﬁcation from the sample object
model ................................... 65
5.1 A typical statechart .............................. 70
5.2 A typical state diagram ........................... 72
5.3 The state diagram for the Compressor object ............... 78
5.4 A Compressor class and its behavior speciﬁed in LOTOS ......... 80
5.5 The state diagram for Storage ........................ 83
5.6 The speciﬁcation (in Full LOTOS) of the Storage (1) ........... 83
5.7 The speciﬁcation (in Full LOTOS) of the Storage (2) ........... 84
5.8 A sample state diagram with interleaving dynamic models ........ 88
5.9 The aggregation concurrent state diagram for Disk Manager ....... 91
5.10 The LOTOS speciﬁcation for a simpliﬁed Disk-Manager ......... 92
5.11 Speciﬁcation for a simpliﬁed Disk_Manager with hidden internal gates . . 93
5.12 Sample state diagram with instantiated parameters of distinguished sorts 95
5.13 LOTOS speciﬁcation of the sample state diagram ............. 96
6.1 A typical data ﬂow diagram ......................... 101
6.2 An OFM that contains services of an individual object .......... 105
6.3 An OFM of an integer stack object ..................... 105
xi

 

 

6.1 A system level
6.3 AII 313151 >1.II‘~'
5131111115
116 .All 8131:.“ 111;!
6.7 An $13151 \\“.t'
6.3 An 513111 wit
119 81519111 1e\‘e1 1.
5.111 A simpliﬁed I1
6.11 The 0111 for
6:13 The 0151 hr
513 The 311131 1«
6.11 The ACT (‘13
6.173 The ACT (15
6.16 The Full 1.11"
nuns and
6.1". The Full LU
110115 101 :
5.15 A typical 51:“:
6.19 A pan of 11}.
530 The forumliz
6.31 The form-£1111
6.32 The Full U;
101 8(3th
1133 The Full LC
110113 for
6.34 The 1.81. spe
625 The Proof 01

I1 The ﬁnrruat
n‘) ‘
I. he error II.
..3 .e testing
II sing am *1
is) An exhausri
I6 .11 interacti
51 T1113 1.0771111
.1")
; Models in I1
K .
{I The sysiezu
;1 The ACT 0'
:"J The S‘A.“("I'1
.535 TI 1 1 3
.Ie “ -
; ~ ‘ «513(f UH
me ~.
“ ‘ ~ Ir-m

33 I; 1.23;: ‘1 a
11" “N i

xii

6.4 A system level OF M derived during analysis ................ 107
6.5 An SRFM shows how a system service is implemented in terms of object

services .................................. 108
6.6 An SRF M that introduces an additional internal function ......... 108
6.7 An SRF M with split and aggregate data flows ............... 109
6.8 An SRFM with reﬁned input and output data ﬂows ............ 110
6.9 System level object functional model for Disk Manager .......... 112
6.10 A simpliﬁed disk manager .......................... 113
6.11 The OFM for Storage ............................. 113
6.12 The OFM for Compressor .......................... 114
6.13 The SRFM for Disk_Manager.Retrieve ................... 114
6.14 The ACT ONE speciﬁcation for Disk Manager ............... 119
6.15 The ACT ONE speciﬁcation for Storage .................. 120
6.16 The Full LOTOS speciﬁcation for Disk Manager with algebraic speciﬁca-

tions and distinguished sort ....................... 123
6.17 The Full LOTOS speciﬁcation for Disk Manager with pre- and postcondi-

tions for services ............................. 126
6.18 A typical state diagram ........................... 128
6.19 A part of the reﬁned ACT ONE speciﬁcation for Disk Manager ..... 135
6.20 The formalization of the reﬁned data items shown in Figure 6.7 ..... 139

6.21 The formalization of the data duplicator and selector shown in Figure 6.8 141
6.22 The Full LOTOS speciﬁcation for Storage with pre— and postconditions

for services ................................. 143
6.23 The Full LOTOS speciﬁcation for Compressor with pre- and postcondi-

tions for services ............................. 144
6.24 The LSL speciﬁcation for the reﬁned Disk Manager ............ 144
6.25 The proof of the example constraint using LP ............... 145
7.1 The format of formal speciﬁcations ..................... 149
7.2 The error in the behavior speciﬁcation of the Storage detected by LSA . 158
7.3 The testing process used to test the behavior of Disk Manager ...... 160
7.4 Using accept_test testing process to test the speciﬁed Disk Manager . . . 161
7.5 An exhaustive test using process accept-test ................ 162
7.6 An interactive simulation of the process composed for testing ....... 164
8.1 The formalization process dimension of the suggested framework ..... 169
8.2 Models in the order of development ..................... 174
8.3 The system object model for Disk Manager ................ 179
8.4 The ACT ONE speciﬁcation for system level object model of Disk Manager179
8.5 The system functional model for Disk Manager .............. 181
8.6 The speciﬁcation for Disk Manager that speciﬁes its services and propertie8182
8.7 The system dynamic model for Disk Manager ............... 182
8.8 The complete Full LOTOS speciﬁcation for system level object model of

Disk Manager ............................... 183
8.9 The testing process used to analyze the behavior of Disk Manager . . . . 184

 

 

H11 15111g1211r’.-
111111? 1111111151 11'.
8.7;? The ACT ON
5.13 The objmjt 111
3.11 The ohjeei (1A
5.1-5 The 5111311111 11?
5.15 The 51113111111. .1‘
3.7... The object 11.:
3.15 The ohjeet I1
5.9 T119 Spuihzd
5.311 An exaIIIII‘II-

5.31 The service I

3512 The service r
5.33 The reﬁ'II-I-Iil
5.31 The 151. 5;»
3'1? The proof 0:
An example
.AII exarII Ip‘o
AII exarup ml
The reﬁ 1111
The {9115011

The 191; '111‘1

J

(' .1“)

1 ‘1?)

Jr) 3’) ‘
1”. . - II.)
(”p I.) 0—) V
(.9 w

(I)

All

The 11111111 11

(111181111

II -l
(:3 (I
Q

(”PA

(I‘

SA 551111; (Mr (_

IigI‘I-lm

. 119 (19:51;
:3 The form
he fauna
97 he trans
0; check I
.5 The trans
r for sin
n he fIIrII
F” eonrlii'
7;. .A test p.
H The tram

8.10
8.11
8.12
8.13
8.14
8.15
8.16
8.17
8.18
8.19
8.20
8.21
8.22
8.23
8.24
8.25
8.26
8.27
8.28
8.29
8.30
8.31
8.32

8.33
8.34

8.35

9.1
9.2
9.3
9.4
9.5

9.6

9.7

9.8
9.9

9.10

xiii

Using accept_test testing process to analyze the speciﬁed Disk Manager . 185
The reﬁned object model for Disk Manager ................. 189
The ACT ONE speciﬁcations for object models of Storage and Compressor 189
The object functional model for Storage .................. 190
The object dynamic model for Storage ................... 191
The speciﬁcation for object Storage in Full LOTOS ............ 192
The speciﬁcation for object Storage in Full LOTOS ............ 193
The object functional model for Compressor ................ 194
The object dynamic model for Compressor ................. 194
The speciﬁcation for Compressor in Full LOTOS ............. 195
An example reﬁned object model ...................... 196
The service reﬁnement functional model for function Input of Disk Manager196

The service reﬁnement functional model for function Output of Disk Manager197
The reﬁned ACT ONE speciﬁcation for Disk Manager ........... 197
The LSL speciﬁcation for the reﬁned Disk Manager ............ 198
The proof of the example constraint using LP ............... 198
An example dynamic model for object 0 .................. 200
An example SRF M for service S 1 of object O ............... 200
An example reﬁned dynamic model for object O .............. 201
The reﬁned dynamic model for Disk Manager ............... 202
The revised reﬁned dynamic model for Disk Manager ........... 202
The reﬁned ACT ONE speciﬁcation for Disk Manager ........... 203
The reﬁned dynamic model for Disk Manager that is composed by parallel

dynamic models .............................. 205
The composed speciﬁcation for Disk Manager ............... 205
Using accept_test testing process to analyze the behavior of the reﬁned

Disk Manager (1) ............................. 206
Using accept-test testing process to analyze the behavior of the reﬁned

Disk Manager (2) ............................. 207
A high-level view of the architecture .................... 212
The design models of EN FORMS at the system level ........... 216
The formal speciﬁcation automatically generated from system models (1) 217

The formal speciﬁcation automatically generated from system models (2) 218
The transcript of running LSA over EN FORMS formal speciﬁcation to

check inter-model consistency ...................... 219
The transcript of running LOLA over ENFORMS formal speciﬁcation

for simulation ............................... 220
The formal speciﬁcation with algebraic speciﬁcations and pre/post-

conditions ................................. 222
A test process for the reﬁned formal speciﬁcation of ENFORMS . . . . 223
The transcript of testing that runs OneExpand of LOLA over the reﬁned

EN FORMS formal speciﬁcation .................... 224

The transcript of testing that runs TestE'zpand of LOLA over the reﬁned
ENFORMS formal speciﬁcation .................... 226

 

9.11 Th9 {093111199 1191:
9.1“} The (11.351111 1111 11
9.13 The 31111111111111.1-
914 The formal 11pm
pre 'p11~‘1~1‘-.1
9.13 The design 1111-
9.16 The “1111;111:1111
93.1- The 31111111111119!
9.15 The {111111111 1;:
and pro; 11
99T1ed1\"1111;

9.3“ T16 31111111
9.31 The 2111111111213
932 The formal .
PT? 'lme-1
:33 The SRHT 1'1
31 The 2111111111;1
93-3 The reﬁned 1f
9135 The 131111111111"
modeT of
:3; T9: d3~'ne1111i1
' aUILJIli‘i'
STEHTS 1n

9‘3 Th9 r1 ﬁnpd

9111Thed1<1znr
31The 21111311111
Of CIIU'T"
3:21 The rexiwd
. 3 The 21111111111
1'1? behax'i1'1r
- qvntzn'c (TINT
W iﬁeation
:—--1 sing expa
9F '
u part of t‘
W pendix I
«~‘Jl
9311 3 “51“ d
93C! 6 TUHIAT
zetranser
91"» T9 13 reﬁnu
p 9 119 {PC
:‘ C ”at [1n
r. ‘ UTHI‘HIJV ‘
.112 T5 1 1 :1.
FIT‘T. IJIW
‘1': OP‘
I1 3 313
d“ ' 9 .3
.. dr4|4f1(j '

9.11
9.12
9.13
9.14

9.15
9.16
9.17
9.18

9.19
9.20
9.21
9.22

9.23
9.24
9.25
9.26

9.27
9.28

9.29
9.30
9.31

9.32
9.33

9.34

9.35
9.36

9.37
9.38
9.39

9.40
9.41
9.42

9.43

xiv

The reﬁned object model for ENFORMS: an overview of the architecture 228

The design models for Name_Server ..................... 229
The automatically generated formal speciﬁcation for Name_Server . . . . 230
The formal speciﬁcation for Name-Server with algebraic speciﬁcations and
pre/post-conditions ............................ 231
The design models for Archive_Server .................... 232

The automatically generated formal speciﬁcation for Archive Server ( 1) . 233
The automatically generated formal speciﬁcation for Archive Server (2) . 234
The formal speciﬁcation for Archive-Server with algebraic speciﬁcations

and pre/post-conditions ......................... 235
The design models for Client ......................... 236
The automatically generated formal speciﬁcation for Client ........ 237
The automatically generated formal speciﬁcation for Client ........ 238
The formal speciﬁcation for Client with algebraic speciﬁcations and

pre/post-conditions ............................ 239
The SRF M for Retrieve service of ENFORMS .............. 240
The automatically generated formal speciﬁcation for the SRFM of Retrieve 240
The reﬁned design model for ENFORMS ................. 241
The automatically generated formal speciﬁcation from the reﬁned dynamic

model of ENFORMS .......................... 242
The dynamic models composed in parallel ................. 244
The automatically generated formal speciﬁcation that describes the con-

stants in the reﬁned models of ENFORMS .............. 246
The reﬁned object model for EN FORMS with Channel object ..... 248
The design models for channel ........................ 248
The automatically generated formal speciﬁcation from the design models

of Channel ................................. 250

The revised design models (with a Channel object) composed in parallel 251
The automatically generated formal speciﬁcation that synchronizes the

behavior of individual objects ...................... 253
Syntax checking and semantics analysis of the reﬁned enforms formal spec-

iﬁcation .................................. 254
Using expansion transformation to detect synchronization error ..... 255
A part of the EFSM transformed from the LOTOS Speciﬁcation in Ap-

pendix H .................................. 256
The reﬁned dynamic model of Client .................... 257
The formal speciﬁcation for the reﬁned Idle state of Client ........ 258
The transcript of expansion transformation after the behavior of the Client

is reﬁned .................................. 258
The test process for the reﬁned formal speciﬁcation of ENFORMS . . . 259
Communication among individual objects are hidden ........... 260
The test process is rejected by the reﬁned behavior speciﬁcation of EN-

FORMS .................................. 261

The added operations and equations that are resulted by the SRFM of
Figure 9.23 ................................ 262

 

9.44 The trarrsrripr r
are addml
94.3 The further rr-fi
9.46 The hirmal an
9.4? The result oi T
refined . .

 

XV

9.44 The transcript of Testhrpand test after necessary operations and equations

are added ................................. 263
9.45 The further reﬁned dynamic model of Client ................ 265
9.46 The formal speciﬁcation for the reﬁned Idle state of Client ........ 266

9.47 The result of TestExpand after the behavior of the Client object class is
reﬁned ................................... 267

 

 

Chapter

Introdu<

it E clearly evidcr:
trniingi}: the rim:
S'stems Where its
in; increasing am

ntairrriation since

{Oi numerous

and
~3>iEnis. Haiufm'v
inf

[V‘T ' i .
J mal. hlgirlf‘t

[flip ”U. . '
,2 mail} lllVUlV-

Off”. ' '
Wildliiiin on Y

Chapter 1

Introduction

It is clearly evident that the impact of software is signiﬁcantly increasing [1]. Ac-
cordingly, the need to have high assurance in software’s correctness increases for
systems where its correct operation is imperative. Formal speciﬁcations are gain-
ing increasing attention as a means to rigorously document requirements and design
information since the well-deﬁned notations are amenable to automated processing
for numerous analysis tasks [2], including veriﬁcation of the correctness of resulting
systems. However, attempting to construct a formal speciﬁcation directly from an
informal, high—level requirements document can be challenging. Formal descriptions
potentially involve considerable syntactic details and may require careful planning and

organization on the part of the speciﬁer in order to develop modular speciﬁcations.

 

1.1 PI‘OblCI

.l rnrrplernurrtary a;
in; irritations. F ii r 7.
used as a pupular t '

taught as an alijm-n

 

largely due to its >i:
and. behavioral. at;
inc functional tnmli
similar to entity-ruin
ofastatediagrarn. .
{trier t0 ellectiwly 1

deﬁned method to it

u; :nree separate. in

{hill may help to (‘i

One approarlt ti

3:J‘ﬂht'ation5: and '

CrLILS

Q

trim a “rim

at; Pi'i'x'" “ '
-rrng speciiit'

Mall-303061] as l

'C-nr':
1 H‘JEYIES. d(¢"(
,. l ;_

l'.

“-.;‘.‘.*.’li’ -‘ ‘
mildllUH rulv

\

i"

safer t" “
was. illiljij'

2

1.1 Problem Description and Motivation

A complementary approach to describing requirements is the use of graphical model-
ing notations. For example, the Object Modelng Technique (OMT) [3] is extensively
used as a popular object-oriented modeling technique in industry and is commonly
taught as an object-oriented methodology in academic settings. Its popularity is
largely due to its simple notation and the notational support for describing struc-
tural, behavioral, and functional aspects of a system through the object, dynamic,
and functional models, respectively. The object model is represented in a notation
similar to entity-relation (ER) diagrams [4]. The dynamic model is described in terms
of a state diagram. And the functional model is captured by a data ﬂow diagram. In
order to effectively use OMT, particularly for design purposes, there must be a well-
deﬁned method to integrate the three models. Otherwise, OMT is only a combination
of three separate, independent models that provide little more than intuitive diagrams
that may help to clarify some ideas within the corresponding, separate models.

One approach that takes advantage of the automated processing afforded by formal
speciﬁcations and the ease of use provided by graphical modeling techniques is to
construct a well-deﬁned syntax and semantics for the graphical models in terms of
an existing speciﬁcation language. A signiﬁcant advantage to formalizing a modeling
notation such as OMT is that it has a uniform notational support for modeling
requirements, design, and detailed design information. Therefore, the corresponding
formalization rules for diagrammatic models can be used to perform analysis and

design tasks throughout the development process, rather than be limited to a speciﬁc

 

phaét? dig” require II;
:3_.:tiriillg notatiuns
Huttever. Stilli?’ l
ge'trait speeihra: it i:
fahngin. Thus full;
furthermore. the l
resulting models. l
tian of the formal
nni‘els. from \Vlllt‘
he: Approach The
and reﬁnement 0f

5:»: graphical not a

Thesrs Stateme
{gig-p formal .5755?

TN] for the

rec
Wining Qittli?
- ,Rv‘

:_ 17

.156 a re . '
Lu objeryg-

a.” ,p
r ,. 41"
.. flu-{l 7r ‘
11 (Odﬁ- 5‘

t

B P
{:e.

'4";‘5m€nt

3

phase (e.g., requirements), as is the case with numerous speciﬁcation languages and / or
modeling notations.

However, some features of the formal speciﬁcations, such as the equations in a1-
gebraic speciﬁcations, cannot be represented by graphical notations in an intuitive
fashion. Thus fully automated generation of formal speciﬁcations is not realistic.
Furthermore, the formalization rules can only derive formal speciﬁcations from the
resulting models, but cannot help to conduct the development process. The applica-
tion of the formal speciﬁcations may be limited by the fact that their corresponding
models, from which the speciﬁcations are generated, are derived in an informal, ad
hoc approach. Therefore, a process that supports a formal and rigorous development
and reﬁnement of analysis and design information with the use of formal semantics

for graphical notations is necessary.

Thesis Statement: The objective of the proposed research is threefold: (1) de-
velop formal syntax and semantics for all three OM T models; (2) develop a formal
deﬁnition for the integration of all three models; and (3) develop a reﬁnement process
for reﬁning analysis information into design information. These three tasks will de-
ﬁne a new object-oriented design paradigm that supports rigorous analysis of 0M T’s
graphical models through speciﬁcation execution, consistency veriﬁcation, and stepwise

reﬁnement.

 

 
  

1.2 Summit

Th5 section give in

Formalization of

dynamic intuit-ls in 1
page of Tetnpt ital
an individual Ulljl“
the state diagram
The state diagram.
s’tthranized LOT
ratiﬁcation of lllt

executable sperili

Formalization C

no tiihject-orierrt

flint"? .
._tlt)naJ “10‘“ ~.
. “‘ ‘1

“eta! .llot'F-l .32
V‘ -. - ll

l'J'h‘erzt

An snr

tlif: (on?
v\ 1 ' '
(‘3‘ prot-

'«
nrn -
“5 fur derir'i
n ;

rit-

snﬁ , B
d.\.(d ”l“

4

1.2 Summary of Research Contributions

This section gives highlights of the four major contributions of this research.

Formalization of Dynamic Model. New rules are proposed to formalize the
dynamic models in terms of process algebra speciﬁcations expressed in LOTOS (Lan-
guage of Temporal Ordering Speciﬁcation) speciﬁcations. In OMT, the behavior of
an individual object is modeled as a state diagram. The proposed rules formalize
the state diagrams for individual objects in terms of LOTOS behavior speciﬁcations.
The state diagrams of concurrent, communicating objects are formalized in terms of
synchronized LOTOS behavior speciﬁcations. The formalization enables the precise
speciﬁcation of the behavior of objects and the simulation of system behavior through

executable speciﬁcations.

Formalization of Functional Model. In order to integrate the functional models
into object-oriented technology, the functional model of OMT has been modiﬁed. Two
functional models, Object Functional Model (OFM) and Service Reﬁnement Func-
tional Model (SRFM), are introduced. An OFM captures the services provided by an
object. An SRF M describes how a service of an object is implemented in terms of
the services provided by the object at a lower level of abstraction. In addition, guide-
lines for deriving algebraic speciﬁcations from the object and functional models are
given. Based upon algebraic speciﬁcations, pre- and postconditions are introduced to
describe the requirements and constraints for services. The pre- and postconditions

of services enable symbolic execution of the high-level design model thus providing a

 

 

means to perform ~.~

 

situate derelupnn-t

integration of tin
three trrntp‘nétrn'n‘ A13
re derived in lilt' t
aritnamic model 1
the models with r'
negation is awhi-
Ltaiization rules.
derived from the t
sated and retirees.
liathiet'ed by («m
according to the
Dian object if ,
- 1 ft
The integrat i«

CI" v.1?»
me‘emi’lliarv ..
. c

f”mil ~ .
mfﬁ‘rﬁfd,

i‘l’l ‘,
“ii in
‘u

means to perform simulation, veriﬁcation, and validation during the early phases of

software deveIOpment.

Integration of the Three Complementary Models. The integration of the
three complementary models is three-fold. First, the functional and dynamic models
are derived in the context of object models. By associating a functional model and
a dynamic model to every individual object, the conflicts can be resolved between
the models with respect to their respective development philosophies. Second, the
integration is achieved through the underlying formal semantics imposed by the for-
malization rules. By sharing common language constructs among the speciﬁcations
derived from the object, functional, and dynamic models, the three models are inte-
grated and represented in terms of a single formal speciﬁcation. Third, the integration
is achieved by composing: (1) the dynamic models of concurrent objects hierarchically
according to the system structure speciﬁed in the object model; and (2) the SRFMs
of an object in terms of the services provided by the aggregate objects.

The integration and formalization of the three models that describe a system from
complementary aspects enable designers to perform analysis tasks by using the derived
formal speciﬁcations. In addition, based upon the formalization and integration,
a design process that incorporates formal speciﬁcations in a transitional, parallel

successive reﬁnement approach [5] is also possible.

Process for Model Construction, Speciﬁcation, and Reﬁnement. Based

on the investigations into the formalization and integration of the models of OMT, a

 

lazgn process, 15 pr
uparallel with the

of the rigorous ilia'

 

 

 

and designers ran it

|
anhiguities. in midi
understand the am
even with the rust ,.

model reﬁnement t:

ea'ner stages of ml
v .

1'3 Deﬁni

51.??? our researrh
as. it 18 import;
.isene}: and can:

on Va '~

allluns apply-

0
Correct me

““1 Still he

Ill
' C
0
. Q ‘-
- “en

design process is proposed to facilitate the development of formal design speciﬁcations
in parallel with the development of OMT’S semi-formal, graphical models. Because
of the rigorous mathematical foundation of formal speciﬁcations, both customers
and designers can have a more precise means to describe the design thus avoiding
ambiguities. In addition, symbolic simulation of the design can help designers better
understand the design as well as facilitate the communication among designers and
even with the customers. And ﬁnally, speciﬁcation analysis can be performed during
model reﬁnement of the design process to detect and eliminate design ﬂaws during

earlier stages of software development.

1 .3 Deﬁnitions

Since our research focuses on the application of formal methods and the design pro-
cess, it is important for us to clarify what we mean by the terms correctness, con-
sistency, and completeness. These terms have been given different meanings based
on various perspectives [6, 7], but for the remainder of the dissertation, the following

deﬁnitions apply.

0 Correctness: after a reﬁnement of a service, the postcondition of the services
can still be satisﬁed.

0 Consistency: the formal speciﬁcations derived from the models (1) do not
have syntactical and semantic errors, (2) do not have deadlocks among concur-
rent, communicating objects, and (3) the test cases that are satisﬁed by the
design speciﬁcation of a higher level abstraction can still be satisﬁed after one
reﬁnement iteration.

o Completeness: the formal speciﬁcations describe all the required functionali-
ties as well as the behavior of the system under all circumstances.

 

1.4 Organl

The remairnler ml ll!
ﬁfth]; Oi)]€t.‘l .\ir nit’
gaggigges that will
the object model u‘
ter 4 revisits the t
nation rule. Chap
in terms of the U
malel into ohjm-t-
functional models.
El‘ we integrated
the enrreSporn‘lirr;
and to perfartri s;
”ill-”LS a Stepwise :
Si’t‘v‘i'iheations. C

lib-39933 l0 3 lay-LI,

LI

7

1.4 Organization of Dissertation

The remainder of this dissertation is organized as follows. Chapter 2 gives an overview
of the Object Modeling Technique (OMT), formal methods, the formal speciﬁcation
languages that will be used, and preliminary investigations into the formalization of
the object model of OMT. Chapter 3 discusses work related to this research. Chap-
ter 4 revisits the object model formalization and introduces an additional formal-
ization rule. Chapter 5 describes the formalization of the dynamic model of OMT
in terms of the LOTOS speciﬁcation language. Chapter 6 integrates the functional
model into object-oriented technology and discusses the formalization rules for the
functional models. Chapter 7 discusses how the object, functional, and dynamic mod—
els are integrated in terms of their underlying formal semantics. It also discusses how
the corresponding speciﬁcations can be used to simulate the behavior of the system
and to perform speciﬁcation analysis. Chapter 8 proposes design process that con-
ducts a stepwise reﬁnement of design by using the diagrammatic models and formal
speciﬁcations. Chapter 9 describes a case study that applies the proposed design
process to a large-scale project, EN FORMS. Chapter 10 gives the conclusions and
discusses future investigations. Appendices A through H give complete formalization

rules and formal speciﬁcations generated from OMT models.

 

 

 

Chapter

Backgro

This thapt er preset

lSOVEN'ieWEd. lllt‘l

l

:it'el}: Next. the E

r,
l l

ital}: the lorrrra

2.1 Objec

TL, "- '
.ne Uhjf‘Ci .llodi .

:33” ' ' '
- n3, to fatrrlite
?" -

I; :r r '
te diagrarrrrnir.

Chapter 2

Background

This chapter presents background material relevant to the dissertation research. OMT
is overviewed, including how it is used during the analysis and design phases, respec—
tively. Next, the speciﬁcation languages Larch and LOTOS are brieﬂy introduced.

Finally, the formalization of the object model is overviewed.

2.1 Object Modeling Technique Overview

The Object Modeling Technique (OMT) is a methodology developed by Rumbaugh,
et al [3], to facilitate object-oriented analysis and design (00A and OOD). It includes

three diagramming techniques to describe different aspects of a system.

2.1.1 Complementary diagramming techniques

The essence of the Object Modeling Technique is to build a model of an application

domain during the analysis of a system that can be augmented with implementation

 

legals during the ii

 

sheet model. dg'urr'.
ii a system. ERl‘ll tr
implementation «let.

[be gibjett diazranﬁ

Object Model.
tutld that is impr
three diagrams. lt
their relationships
it is straightlortt‘a
The object diagra
made-ls are based.
that can be \‘alua‘

SITE llle diagram-a

Sent classes: line».

if association lint
relief"
.-.lull>lrl]

)SI trip

Dynamic Mode

1115‘: the beha

'3- i
L65"? - ..
“5rd

I Q]

details during the design phase. The modeling consists of three orthogonal models,
object model, dynamic model, and functional model, each depicting different features
of a system. Each model is applicable during all stages of development and acquires
implementation detail as the development progresses. The models are represented as

the object diagram, state diagram, and data ﬂow diagram, respectively.

Object Model. An object diagram is used to capture information about the real
world that is important to an application. Thus it is the most important of the
three diagrams. It describes the static objects in a system by showing their identity,
their relationships to other objects, their attributes, and their operations. Therefore,
it is straightforward to derive abstract data types (ADT) from the object diagrams.
The object diagram forms a basic framework upon which the dynamic and functional
models are based. The diagram provides an intuitive visual representation of a system
that can be valuable in the communication between the customers and the developers
since the diagrams serve to document the structure of a system. In OMT, boxes repre-
sent classes; lines between boxes represent associations; empty, solid circles at the end
of association lines represent different multiplicities; diamonds represent aggregation

relationships; triangles represent inheritance relationships.

Dynamic Model. A state diagram graphically represents the dynamic models that
describe the behavioral aspects of a system concerned with events, time, and changes.
Each state diagram depicts the state and event sequences allowed in a system for one

class of objects. The notation used for dynamic models is a variation of Harel’s

 

StaIet‘hart noration

 

transitions. ln (llll
events that trineer
diagrams. Punt-tit a:
diagram: operation:

functional .\lod
grams is the lililt
Data ﬂow diagram
and data ﬂows. r
the operations in

artistraints for \‘a

2.1.2 Requ

in GMT. the oh

i

(7.".4 .
l
. Ere aspects of
[in .. '
mat-tic model

I
r . .

liﬁer n
‘dll. ' -
dlt Dill-J]

“ l. P
dam

(«is .
{HUT-Ff 5,.

10
Statechart notation [8], where ovals represent states; arcs with arrows represent state
transitions. In OMT, rounded rectangles represent states; labels on arrows represent
events that trigger state transitions. State diagrams also reference the other OMT
diagrams. Functions in a data ﬂow diagram correspond to the actions from the state
diagram; Operations on objects in the object diagram are modeled as events in a state

diagram.

Functional Model. The functional model, depicted in the form of data ﬂow dia-
grams, is the third dimension of the three orthogonal modeling techniques of OMT.
Data ﬂow diagrams (DFD) consist of nodes and arcs, which correspond to processes
and data flows, respectively. The data ﬂow diagram also speciﬁes the meaning of
the Operations in the object model and the actions in the dynamic model, as well as

constraints for values within an object model.

2.1.2 Requirements Analysis

In OMT, the objective of requirements analysis is to devise a precise, concise, un-
derstandable, and correct model of the real-world [3]. The analysis models describe
three aspects of objects: static structure (object model), sequencing of interactions
(dynamic model), and data transformation (functional model).

The object model describes real-world object classes and their relationships to each
other, and it should be the ﬁrst model to be derived from a problem statement because
the static structure of a system is usually better deﬁned, less dependent on application

details, more stable as the solution evolves, and easier for humans to understand.

 

During the analysi~

 

and operations. arv
prepared: inherit.

ohjeet model at the

 

 

and reﬁnements.

The dynamic tn
«*i‘tieets. it is the s
or more scenarios. '
eternal display for
include all signals.
has-d upon the st:
diagram. which ie
event flow diagra:
”litigant for each

tier.“ . .
"*5 the Object

53.

a1} . ~
eient ﬁt iW di
The function;

noat consider

.Lut laerg
-‘ ( ‘
.ii

11
During the analysis phase, modeling entities, such as classes, associations, attributes,
and operations, are identiﬁed; a data dictionary that contains all modeling entities
is prepared; inheritance relationships between object classes are identiﬁed. The ﬁnal
object model at the end of the analysis phase is obtained through repetitive iterations
and reﬁnements.

The dynamic model shows the time—dependent behavior of the system and the
objects. It is the second model to be derived during the analysis stage. Initially, one
or more scenarios (a scenario is a sequence of events) that show the major iterations,
external display formats, and information exchanges are prepared. The events, which
include all signals, inputs, decisions, interrupts, transitions, and actions, are identiﬁed
based upon the scenarios. And each scenario is described in terms of an event trace
diagram, which is an ordered list of events between different objects. In addition,
event ﬂow diagrams that depict events between classes are derived. Finally, a state
diagram for each object class with nontrivial dynamic behavior that describes the
events the object receives and sends is obtained based upon the event trace diagrams
and event ﬂow diagrams.

The functional model that shows data dependency and how values are computed
without considering sequencing, decisions, or object structure is the last model to
be derived. In OMT, similar to the process used in structured analysis, input and
output values of the system are ﬁrst identiﬁed. A top level data ﬂow (DFD) diagram
is developed according to the input and output values. Then each nontrivial process
is recursively expanded into a low-level DFD until every process corresponds to a

function. A description for each function, which can be in natural language, math-

 

entatit‘al {’Qllalltth‘

once the DP D has

2.1.3 Desigt'

0}le decomposes

System Design.
guidelines for the
this Stage. object
isto provide. co
tasks. decisions

3f? made. The i

flit ‘
....:n the attatys

W to be i
re.» .
«adg This St.

fill r‘r .

12
ematical equations, pseudo—code, or some other appropriate form, should be written

once the DF D has been reﬁned to a sufﬁcient level of detail.

2.1.3 Design

OMT decomposes the design phase into system design and object design stages [3].

System Design. The objective of the system design stage is to establish high-level
guidelines for the object design and to make global decisions concerning the design. In
this stage, objects are grouped into subsystems according to services that the system
is to provide, concurrency is identiﬁed, subsystems are allocated to processors and
tasks, decisions about data store management and software control implementation
are made. The implicit presumption of all these activities is that the models obtained

from the analysis phase are sufﬁciently detailed to contribute to this phase.

Object Design. During the object design, decisions about how the classes are
going to be implemented according to the strategy chosen during system design are
made. This stage includes determining the data structure of attributes, algorithms

for operations, association design, and addition of internal objects, and so on.

2.2 Formal Methods

A formal method is characterized by a formal speciﬁcation language and a set of rules
governing the manipulation of expressions in that language. A formal speciﬁcation

language provides [9]:

 

o a synthetic d
o a Sfrttunt‘tt‘ (I

o a satt.~'f.rrtt~t.

tintpletnent }

Turtnal spet‘ilit a

 

‘ analysis results at.
eret‘ntion :111 (’Xt't".
steps {refinements
There exists in;
can be partitioned
ﬁctitious are cornxt

denotational.

2'2‘1 AXiOn‘.

The Grit/mam 3::

”TEL-T ' F

rlllt‘bg Of

“T 7.
4 ll ‘1 ‘ 11 1
dldCIlldllCdl

l1] h‘_:'.1
pdhlde

My»,

a ffjr

It

13

o a syntactic domain: the notation in which the speciﬁcations are written.
0 a semantic domain: a universe of elements that may be speciﬁed, and

o a satisfaction relation: indicates which elements in the semantic domain satisfy
(implement) which speciﬁcations in the syntactic domain.

Formal speciﬁcations can be checked by tools that help explore the consequences
of analysis results and design decisions [2], detect logical inconsistencies [10], simulate
execution [11], execute symbolically [12], and prove the correctness of implementations
steps (reﬁnements) [13].

There exists many types of formal specifications. Formal specification languages
can be partitioned according to a high-level classiﬁcation [14]. The formal speci-
ﬁcations are commonly categorized into three classes: axiomatic, Operational, and

denotational.

2.2.1 Axiomatic speciﬁcations:

The axiomatic approach to speciﬁcation implicitly deﬁnes the semantics of a pro-
gramming language by a collection of axioms and rules of inference, which enable
the proof of properties of programs, such as program correctness, in terms of speci-
ﬁed input/ output relations. The assertions about programs can be proven by either
a mathematical or an operational deﬁnition and mathematical reasoning. The ax-
ioms are rules of inferences that can be regarded as theorems within the framework
of mathematical semantics. The objective of the axiomatic formal speciﬁcation is
to provide a formal system that enables a proof to be constructed using only the

uninterpreted speciﬁcation text.

 

Axiomatic 5pm".

 

and algebraic spec:

Predicate speciﬁd
|

,5, pritlltjdte Sper'lllt
:hat a given irnplet
required {uric-tional
tanstrnctiyity. Tl.
iatilitates speciﬁer
and other beliayio
“Jill Spat“? €llil.'lt‘r'lt
dare that. given 2
its square root.

\

W
M

Fig

I4
Axiomatic speciﬁcations can be further classiﬁed into predicate speciﬁcations [15]

and algebraic speciﬁcations [16].

Predicate speciﬁcations:

A predicate speciﬁcation explicitly describes properties of the behavior of a system
that a given implementation must satisfy. The speciﬁcations describe the system’s
required functionality. Predicate speciﬁcations are not bound by the constraint of
constructivity. The properties can be stated separately and then combined, which
facilitates speciﬁcation modularity. The properties include input/output constraints
and other behavior conditions, such as fault tolerance, safety, security, response time,
and space efﬁciency. Figure 2.1 contains a predicate speciﬁcation describing a proce-
dure that, given an appropriate argument, 3:, computes an integer approximation to

its square root.

 

Precondition S Postcondition
Precondition: :1: 2 O A integer(x);
Postcondition: Vi : 0 S i g :t: : abs(x — result x result) 3 abs(x — i x i)

 

 

Figure 2.1: A predicate speciﬁcation of integer square root

 

Algebraic speciﬁcations:

An algebraic speciﬁcation is a mathematical description language, based largely on

equations, commonly used to specify abstract data types (ADT). An ADT is a well-

 

 

defined data $11111”
sert'it‘eS. The prop

An algebraic st

0 Sort is): lllt‘

Operation. .~

syntacticallj
0 Arrow or f
speciﬁt-atittr
ln Figure 233‘

given 111 the Lari:

\

al ~
1"‘3 o
.1 -
is. instead of d
C‘éllOH

IS Stirruar

15
deﬁned data structure described by the available services and properties of these
services. The properties of the data type are speciﬁed in terms of equations.
An algebraic speciﬁcation typically consists of

o Sort{s): the names of the abstract data types being described.

0 Operati0n(s): the services applicable to instances of the abstract data type and
syntactically describe how they have to be invoked (signatures).

o Axioms or theorems: formally describe the semantic properties of the algebraic
speciﬁcation.

In Figure 2.2, an algebraic speciﬁcation describing the prOperties of the stack is

given in the Larch speciﬁcation language.

 

Stack: 111i;

introduces
new: —> S
push: E, S —> S
p0p: S —> S

asserts V s: S, e: E
pop (new) :2 new
p01) (push(e, 5)) == 8

Figure 2.2: A generic algebraic speciﬁcation of stack

 

2.2.2 Operational speciﬁcations:

An operational speciﬁcation [17] gives one solution that satisﬁes the required proper-
ties, instead of describing the required behaviors. Commonly, the operational speciﬁ-

cation is similar in format to a program. This approach has an advantage in that the

 

tperatiutzal

being spet'it
slit-are sys
tial prt‘npertf

I v
lUCZ'E'.’ that:

a Simple in;

2.2.3 1:

Th“ diff

its. . 1

0r ,. 9‘
a liltmti:

”t
‘lri‘i- l

H31l01

1X dffi

11)]

.JTS TU): st.

16
operational speciﬁcations can be executed directly as a rapid prototype of the system
being speciﬁed. Thus the speciﬁers and their clients can obtain feedback about the
software system quickly. The disadvantages are that it is difﬁcult to extract the essen-
tial properties that the system must fulﬁll and the speciﬁcations tend to be relatively
longer than behavioral speciﬁcations. The operational speciﬁcation in Figure 2.3 gives

a simple implementation algorithm to compute the square root of an integer.

 

int sqrt (int x)
reguires x 2 0;

effects
i=0;
Whileixi<x
i=i+1§gd

ifabs(i x i-x) > abs((i- 1) x (i-1)-x)
then return i - 1
else return i

 

 

Figure 2.3: An operational speciﬁcation of integer square root

 

2.2.3 Denotational speciﬁcations:

The denotational speciﬁcation [18] maps a speciﬁcation directly to its meaning, called
its denotation. The denotation is usually a mathematical value, such as a number
or a function. No interpreters are used; a valuation function maps a speciﬁcation
directly to its meaning.

A denotational deﬁnition is more abstract than an operational deﬁnition, since it

does not specify computation steps. Its high-level, modular structure makes it espe-

 

(”tally useful to lat. _
tan he studied “it;
:he implement t )T t»:

n. be represent .-

he implemented as

 

Therefore. dent:
tion and less al at It:
it tan be stated in
designers.

Figure 2.4 Slim
cleaned by an ex:
133.35 an express'tt

EXDTE‘SSlOI): 51 E31

. ‘-

a set of values... C

s_

to “1%: A 1)

a
.hereiore. 3 cm'

.. f A
V‘ll’TE' 0 0.

17
cially useful to language designers and users, since the individual parts of a language
can be studied without having to examine the entire deﬁnition. On the other hand,
the implementor of a language is left with more work. The numbers and functions
must be represented as objects in a physical machine, and the valuation function must
be implemented as the processor.

Therefore, denotational semantics is more abstract than an operational speciﬁca-
tion and less abstract than an axiomatic speciﬁcation. Like an algebraic speciﬁcation,
it can be stated in modules, which makes it especially useful to system analysts and
designers.

Figure 2.4 shows a denotational speciﬁcation of boolean expressions. The value
denoted by an expression depends on the state because it may contain variables. E
maps an expression onto a function from states to boolean values. For a particular
expression, 5, Elk]: _S_ —> _B_o<_)l is a function from _S_ to M, which corresponds to
a set of values. States, S, is the set or data-type of functions from identiﬁers, ﬁe,
to _V_al_t;e_. A particular state, a, is a particular function from variables to values.
Therefore, a speciﬁc value is obtained by evaluating the expression _E_[[e]|a: 1335;],
where or gives the state in terms of identiﬁers and their values. Suppose o[[:t:][ = trite

and 0[y] = false then the boolean expression :1: and n_ot y can be evaluated as:

E122 and n_0t 31ch

= E11310 A El n_0t yla
= E19310 A nElz/la

= lel A "Ulyl

= tr_ue A nhlie

= m

 

18

 

Ease:

e::=a_nde|
e_o_re|
petsl
tonal
£a_1§§|

5

List

6 :2: syntax for identiﬁers

E: Egg; —> E —> 5291

EI[€ a_n_d_ 5’]0 = E[[e]]0 /\ E]€']]0
E[[e g €']]a = E[[5]|a V E[[€']]o
E[[ got 5]]0 = -: El]e]]o

El] _tr_u§ ]]0 = true

E[[ fag ]]a = false

Elela = GM

0: Szﬂea Value

Figure 2.4: A denotational speciﬁcation of boolean expression

 

2.3 Speciﬁcation Languages Used in Project

This section overviews two speciﬁcation languages that will be used in the formaliza-

tion of OMT.

2.3.1 Larch

The Larch family of speciﬁcation languages [19] uses a two-tiered approach to formal
speciﬁcations in which one tier, the Larch Shared Language (LSL), is an algebraic

speciﬁcation language used to specify pr0perties that are independent of a particular

 

 

.A..v .‘ '1'.
p‘l:.':ral.t
. - ~ 5 "
;tl..t‘1l'Ll.

d

: .
vrf. ‘1
tut. b(L‘AI‘

inlSli

as used

9h, " I'
LP Lll't‘lt

19
programming language and paradigm. Algebraic speciﬁcations can be used to describe
object-oriented software in a straightforward manner, using abstract data types as
the basic unit in software speciﬁcation. Accordingly, the basic unit of speciﬁcation
in LSL is the trait, which axiomatizes theories about functions and data types that
are used in programs. A collection of general purpose traits that are designed for
constructing application-speciﬁc traits is called a trait handbook [19]. The other tier,
the Larch Interface Language (LIL), speciﬁes program behavior and programming
language interfaces. For example, LCL [20] is a LIL for the C language that speciﬁes
program behavior in terms of predicate logic and function and procedure interfaces in
terms of C syntax. In Figure 2.5, an algebraic speciﬁcation describing the properties
of the table is given in the Larch speciﬁcation language. There are three operators for
the table: create a new table, add an integer, and test for membership. The properties
stated in the asserts section indicate that there are no elements in a newly created

table and an existing element can be found using a linear search.

 

Table: trait

includes Integer

introduces
new: —+ Tab
add: Tab, Ind, Val —+ Tab
6: Ind, Tab —+ 8001

asserts V i il: Ind, v: Val, 12: Tab
'1 (i 6 new);
i6add(t, i1,v) ==i=ilVi€t

Figure 2.5: A Larch algebraic speciﬁcation of table

 

 

 

2.3.2 LC

LOTOS was
nitgatiott 51‘1““
specification "
simple extent
(assists of an
bra. Full LOT
behayiors alur
The algeli.
Shared Langtt
Speciﬁt'atitms.
consisting of s.-
be the entire
The genera
parameters. w

With *1“ )

org

20

2.3.2 LOTOS

LOT OS was originally designed to specify the behavior of networking and commu-
nication systems [21]. Basic LOTOS, based upon process algebras (an operational
speciﬁcation) [22, 23, 24], contains the primitives that enable speciﬁers to model
simple external, observable behaviors without data exchange; Full LOTOS [21, 25]
consists of an algebraic speciﬁcation language [26], ACT ONE, and a process alge—
bra. Full LOTOS enables speciﬁers to specify both abstract data types and external
behaviors along with process communication and value passing.

The algebraic speciﬁcation language, ACT ONE, which is similar to the Larch
Shared Language, is used to describe the abstract data types that are used in LOTOS
speciﬁcations. A system, as a whole, can be speciﬁed as a single process, possibly
consisting of several subprocesses. Each subprocess is considered to be a process, and
thus the entire system may be viewed as a hierarchy of processes.

The general form of a Full LOTOS event consists of a gate and a list of interaction
parameters, where each parameter can either be a value offered at the gate (labeled
with “1”) or a variable accepted at the gate (labeled with “?”). An example is as
follows: 9 !3 ?data: Nat;. This event offers value 3 and accepts a value of sort Nat
(natural number) for variable data at gate 9.

A behavior expression models the activity of a process. Behavior expressions
are built from actions and other behavior expressions by using a predeﬁned set of

operations: action preﬁx, choice, parallel composition, enable, and disable.

 

 

for 6
his spet
s at typ
The rho

l,lh~'.'€ kill

pfOCt

2.4 4

ll LET} 115i
Chjdpis

he

«1”. 101'; d:

l
‘ .

r-
M p,» . t
-JD-r
u!)
Bllliltl.
pl'ilk'ldte -

$39.:

 

 

21
For example, Figure 2.6 shows a typical LOTOS process algebra speciﬁcation. In
this speciﬁcation, process statel has two gates in the form of [a,b] and a parameter
s of type S. Keyword noexit speciﬁes that the process state does not terminate.
The choice operator, [], captures the notion that two alternative choices are possible.

Once an event occurs, then the choice for the path to take is determined.

 

process statel [a,b] (s: S): noexit:=
b ?k:K; b !b(s,k);
state1 [a,b](s)
[l

a ?d:D;

statel [a,b](s)
endproc

Figure 2.6: A typical LOTOS process algebra speciﬁcation

 

2.4 Object Model Formalization

When using OMT, the object model is central to the construction of the other two
models. While this dissertation focused on the formalization of the dynamic and
functional models, an overview of the formalization of the object model is included
for completeness sake and to provide context for the dissertation.

Bourdeau and Cheng [27] identiﬁed a subset of the object model notation ap-
propriate for describing requirements and added formal syntax and semantics to the
notations. In object diagrams, rectangles enclose the names of classes, where a class
describes a particular type of object in the system. Relationships between objects,

called associations in OMT, are speciﬁed by connecting the classes involved in the

 

 

relationship by
models expresr
turepresent at
asystetn. lt n

In Bonnie.
instance dingy;

toteryiew of I ll

lot-m

22
relationship by a line with the name of the association centered on the line. Object
models expressed in the context of requirements analysis are referred to as A-schemata
to represent analysis object schemata. An A-schema describes the static structure of
a system. It consists of a set of classes and associations among those classes.
In Bourdeau and Cheng’s formalization, the semantics of the A-schemata and
instance diagram notations are described by an algebraic formalization. A graphical

overview of this formalization process is given in Figure 2.7.

 

 

 

 

 

OMT semantics
A—Schemata > m
formalized as : testing?“ formalized as
I
v i v
31:31:18; ons > Algebras

algebraic semantics

Figure 2.7: Basic approach to formalization.

 

In this ﬁgure, the arrow labeled “OMT semantics” represents the currently in-
formal concept of consistency between an instance diagram and an A-schema. The
arrow labeled “algebraic semantics” represents the formal concept of consistency be-
tween an algebra and an algebraic speciﬁcation that has been well-developed in the
literature [28]. In Bourdeau and Cheng’s formalization, A-schemata are formalized
as algebraic speciﬁcations, and instance diagrams are formalized as algebras. As a
result, the OMT semantics, which were previously not well-deﬁned, are now described

in terms of an algebraic semantics.

 

 

 

firs
.11 1,, .0I
_‘rjtdl‘l L'
f‘J'VT '. ‘
Ll. ‘LlLAiLn

BU ll

aretu l
iﬁlnynt
trait isl
the nun
define

hash: ax
inthnieg
and j

\

23

First, the semantics of classes, objects, and object-states will be given. Next, the
semantics of associations will be addressed, and ﬁnally, the combination of all of the
formalizations will be presented in order to describe the semantics of A-schemata.

Bourdeau and Cheng used the Larch Shared Language (LSL) [19] to illustrate how
these basic formalisms are incorporated into a structured, algebraic speciﬁcation. In
Figure 2.8, SPECNAME is the name of the speciﬁcation module. The sorts that
are to be considered as the parameters of the module are given in the parameter list
following the name of the trait. Includes indicates other traits upon which the given
trait is built. The introduces section itemizes function signatures, each of which gives
the number and types of input arguments and result type of a function. Asserts
deﬁnes the constraints for the speciﬁcation. When using LSL, one assumes that a
basic axiomatization of Boolean algebra is a part of every trait. This axiomatization
includes the sort BOOL, the Boolean constants true and false, the connectives ‘A’

and ‘V’, implication ‘=>’, and negation ‘—.’,

 

SPECNAME ( parameters ) : trait
includes
list of pre-existing speciﬁcation modules to be used
introduces
syntax declarations for functions are listed here
asserts
axioms are listed here

Figure 2.8: High-level structure of LSL speciﬁcations

 

 

 

2.4.1 1

a v
9

[‘E‘l b 011'
5. Fauna

,f. 7 .4
us a ML”.

512116 5 0'

for it; put

I

lt‘

‘JT cu,
ICI‘

r _I

*5 Hf
"~_l->

24

2.4.1 Semantics for Classes and Object States

Let S be an A-schema, and let C = {C1, . . . ,Cn} be the set of class names given in
S. Formally, each class name C,- E C, where 1 S i g n, is considered to be the name
of a sort (type). For each class name C,, a sort Ci-STATES is introduced, which
characterizes the set of states that are possible for any Ci-object. For each object-
state 3 of class C,, s is speciﬁed with the signature (syntax and type speciﬁcations

for input arguments and output value)

8 I —) Ci-STATES

States are nullary functions with no input arguments, therefore they are considered to
be constants. For every class C,, the set of possible states deﬁned by Ci-S TA TES must
include a state undefC“ in which case the state of C, is undeﬁned. The corresponding

signature is

undefci : ——+ Ci-STATES'

For every pair of object-states 31 and 82 of C,- (including undefci), 31 7!: 32. In order
to bind a Ci-object to one of its possible states, a valuation function, $, is introduced

with the signature

$ : C, —> Ci-STATES ,

for each class name C. E C. Figure 2.9 contains a simple object model that has

an object class C and its states 31 and 82 (the target of double-headed arrows).

 

figure 2.

Times 3

‘5‘.-
{:5
ru.
:ng ,1 _

25
Figure 2.10 shows its corresponding A—schema 83, containing object-states 31 and 32.

Figures 2.11 and 2.12 give a summary of the formalization of the object models.

 

 

 

 

 

Figure 2.9: A simple object model

 

 

SCHEMA_diagram: traﬁ;
includes CLASS_C

CLASS_C: trait

introduces
err_C : -> C
82 : -> C_STATES
31 : -> C_STATES
state_C : C -> C_STATES
asserts

fbraﬂ x, y: C_STATES
(x=s2 / y=sl) => (X"=y);

Figure 2.10: The corresponding algebraic speciﬁcation of Figure 2.9

 

Figure 2.13 shows an object diagram of a simpliﬁed disk manager [27, 29] that is
composed of (represented by a diamond) Storage and Compressor. The disk manager
stores compressed data in the Storage and decompresses data that is retrieved from

the Storage. We will use this example throughout this dissertation.

 

Deﬁnitio
let C be

0:. lid? 1
(0m) 1
tutti) t

i0.\l3] l
re:
pal?

[0314) l

ions) 1

is a
10316) 1

3 pt ‘1

15 at

they

26

 

Deﬁnition (Semantics of object models) :
Let 0 be an object model. Let R be a binary association in 0 relating objects from classes D1 and
D2. The semantics of O is an algebraic speciﬁcation satisfying the following data.

(0M1) Each class C in the object model 0 is denoted by a sort of the same name.
(0M2) For each class C, a sort C—S TAT ES is introduced as well as two nullary functions given by

undefc : —-> C—STATES , errc : ——) C .

(0M3) Each object-state s, for which a double-headed arrow leads from a class C to the oval
containing 3, is denoted by a function with signature 3 : —> C—STATES , and for every
pair of object-states 31 and 32, the axiom 31 7E 32 is included.

(0M4) For each class C, a valuation function ‘$’ is introduced with the signature
3 : C —> C-STATES
The valuation of the error object is added as an axiom:
$(errc) = undefc

(0M5) If there is a double-headed arrow labeled a (to indicate an attribute), leading from a class
C to a class D (which depicts an attribute a of C), then the function signature

a:C—>D ,

is added to speciﬁcation for class C.

(0M6) If the class D in rule (0M5) is an external class, then the trait for D is included by the
speciﬁcation for C. If D has no parameters, then the clause

includes
CLASS-D

is added. If D has parameters p1, . . . , pk, and there is a line connecting each p,- to a class qi,
then the following clause is added:

includes
CLASS-p1. ..., CLASS-pk,
CLASS-D ( q1 for p1, ..., Q]. for pk)

Figure 2.11: Summary of Object Model Semantics

 

 

tour; .

(0)18] '
3 T
dr‘.

10319)

27

 

(0M7) Association R is denoted by the predicate

R:D1,D;c —> BOOL.

(0M8) The endpoints of association R determine a set of axioms. Suppose the Dl-endpoint depicts
a multiplicity of m and the Dg-endpoint depicts a multiplicity of n. Then the axioms are
derived by the following steps:

1. Decompose the m-to—n association R into an m-to-l and l-to—n binary association,

2. Determine the second-order speciﬁcations, P1 and P2, of each of these associations using
the basis schemata,

3. Calculate the “intersection”, P, of the speciﬁcations P1 and P2,

4. Unfold and skolemize P, yielding a set of ﬁrst—order axioms that are included in the
trait for R.

(0M9) Error object constraints are introduced:
(Vd1le,d2:Dz O R(eerl,d2)/\d1;/: 87‘7‘0l => ﬁR(d1,d2)) ,

(Vd1 : D1,d2 : Dz I R(d1,err02) Adz 9‘: £1702 => ﬁR(d1,d2))

Figure 2.12: Summary of Object Model Semantics (continued)

 

 

 

Disk
Manager

9
t I

Storage Compressor

“‘3

Figure 2.13: A simpliﬁed disk manager

 

 

 

 

 

 

 

 

 

 

 

 

28
Applying the Object model formalization, Figure 2.14 contains the Larch speci-
ﬁcation for the Storage Object class. Empty and non_empty are two states for the
Storage class objects. The axiom in the asserts part speciﬁes that the two states are

mutually exclusive.

 

CLASS_Storage : trait

introduces
orr-Storage : ->Storage
empty : —> Storage_STATES
non_ompty : -> Storage_STATES
Stato_Storage : Storage -> Storage_STATES
asserts

ﬂora" x, y : Storage_STATES
(xsempty /\ y=non_empty) 8) (x ‘= y);

Figure 2.14: A high-level Storage class speciﬁed in Larch

 

Given the similarity between LSL and ACT ONE, both of which are algebraic
speciﬁcationsthe previous discussion and deﬁnitions are also applicable to the ACT
ONE syntax. As a means to facilitate the integration between the Object and dynamic
models, we will use ACT ONE syntax instead of LSL to specify the Object model in
the remainder of this dissertation. Figure 2.15 contains the ACT ONE speciﬁcation
for the Storage Object class. Respectively, the sorts and opns parts declare the sorts
and specify the operators (constants are nullary Operators) along with the signature
for the type. The eqns section lists the equational axioms that the Operators must
satisfy. Empty and non_empty are two states for the Storage class Objects. The axiom

in the eqns part speciﬁes that the two states are mutually exclusive.

29

 

type CLASS_Storege is Boolean

sorts
Storage. Storage_STATES
opns
err_Storege : ->Storege
empty : -> Storage_STATES
non_empty : -> Storage_STATES
Stete_Storege : Storage -> Storage-STATES
eqns

forall x, y : StoragejTATES
ofsort Bool
(x=empty /\ y=non-empty) => (x '= y);

Figure 2.15: A high-level Storage class speciﬁed in ACT ONE

 

Ch

R003

Inerth

Chapter 3

Related Work

In this chapter, we overview related work. The related work is grouped into three
categories: formalization of object-oriented development techniques, formalization of

non-object-oriented approaches, and systematic reﬁnement approaches.

3.1 Formalization of Object-Oriented Modeling

Approaches

This section introduces object-oriented modeling approaches. TROLL [30] and
ROOA [31] propose formal semantics for the models. ROOA and the Fusion

method [7] provide detailed guidelines that facilitate the derivation of models.

30

3.1.1

Overvi

system
is a It?!
htegrai
tion :34
.is 3 cc

plflpen

Forma

Th6 pr

l
3‘3 an

Tsz

Emilie £1

‘

i

1.

:Ji’JH-Jl
_‘C‘LE‘

31

3.1.1 TROLL—A Language for Ob ject-Oriented Speciﬁcation
of Information Systems
Overview

Jungclaus et al. developed a formal speciﬁcation language, TROLL [30], to support
the requirement speciﬁcation phase in the early stages of object-oriented information
systems development, including OMT. The underlying formal semantics of TROLL
is a temporal logic [32]. Using object-oriented structuring mechanisms, TROLL
integrates elements of algebraic speciﬁcations of data types [33], process speciﬁca-
tion [34, 35], the speciﬁcation of reactive systems [36], and conceptual modeling [37].
As a consequence of the integration, TROLL is able to specify both the structural

properties of objects via attributes and the behavior of objects through events.

Formalization Approach

The primary speciﬁcation construct of TROLL is the class template that includes
declarations for data types, attributes, and events, constraints on the observable states
and on the evolution of attribute values, effects of events, behavior speciﬁcation, and
object activities. A class speciﬁcation is composed of a class template speciﬁcation
and an identiﬁcation mechanism that is used to distinguish individual objects of the
class.

TROLL also provides the abstraction mechanisms, specialization and role, to de-
scribe an object from different aspects. Specialization describes objects belonging to

subclasses that depend on observable properties (attributes) whereas roles describe

 

'35: [arm
C: n]
TROLL.
Ciﬁlllptrll'
atria-:15 l
for
ter;

3.2 1
mm

9
f‘“n‘-,-.
fi‘.‘\!]1

 

32
objects belonging to subclasses that depend on certain situations during an object’s
life (occurrence of events).

Composite objects that are composed of other objects are also supported by
TROLL. In TROLL, a composite object is speciﬁed by including speciﬁcations of
component objects in the composite object speciﬁcation and synchronizing the inter-
actions between component objects.

For a system comprising interaction objects, TROLL uses relationships and in-
terfaces to deﬁne the interconnections among relatively independent objects. The
relationship construct supports the speciﬁcation of communication and constraints
among objects. Using relationship constructs, the interconnection and communica-
tion patterns among separately deﬁned objects can be deﬁned; the constraints among
instances of classes can be described. The interface construct is used to deﬁne ob
ject interfaces that are accessible to other objects, thus providing an information

encapsulation mechanism.

Comparison with our approach

Similar to our approach, TROLL also proposes a set of formalization rules for ob ject-
oriented models. Its formalization rules cover all three basic aspects of an object-
oriented system (static, dynamic, and functional). The formalization is similar to
ours in that objects are formalized as ADTs and dynamic behavior is speciﬁed as
event sequencing patterns. However, TROLL was proposed for use in the require-
ments analysis phase but not for design. TROLL has a new speciﬁcation language

that currently lacks tool support offered by other existing speciﬁcation languages.

Ill? advam
constructs it
to formalize

derivation 0

3.1.2 R
Overview

list} nguri
iriemed an
aset of mi
spaiﬁra‘iio
8316111. Ti
ration aga

UnliSSitIIllS

L.
, R
{I .iI
( l
0;in »
J l-I‘H'

33
The advantage of designing a new speciﬁcation language is that the structure and
constructs of the language may ﬁt the formalization objective very well. In addition
to formalization rules, speciﬁc guidelines are also needed to facilitate analysts in the

derivation of the formal speciﬁcations during analysis.

3.1.2 Rigorous Object-Oriented Analysis
Overview

The Rigorous Object-Oriented Analysis (ROOA) [38, 31, 39] formalizes object-
oriented analysis notations in terms of the LOTOS speciﬁcation language and includes
a set of rules to conduct object-oriented analysis. The resulting formal, executable
speciﬁcations of ROOA integrate the static, dynamic, and functional properties of a
system. The speciﬁcations are amenable to checking the conformance of the speciﬁ-
cation against the original requirements and may be used to detect inconsistencies,

omissions, and ambiguities early in the development process.

Analysis process

ROOA advocates a development process for object-oriented analysis. The process
includes three stages: object model derivation, object model reﬁnement, and formal
speciﬁcation derivation.

At ﬁrst, a high-level, informal object model is built by using any of the usual
object-oriented analysis methods, such as the methods of Coad and Yourdon [40] and

OMT [3]. During the reﬁnement stage, the object model is completed by adding in—

p

[f (Isn‘t

. ..tl
bl di’u
_. l
ﬁche ‘,
‘. ‘ ~ .»
:ghslsl

delta:

Form:

in);

Where

34
terface objects, static relationships, and attributes; the dynamic behavior is identiﬁed
by deﬁning interface scenarios, event trace diagrams (ETDs), object communication
table (OCT), and adding message connections; the object model is structured into
subsystems or aggregates to achieve modularity. Finally, formal speciﬁcations are
derived to specify the static, dynamic, and functional properties of the system. This
stage consists of the following steps: creating the object communication diagram
(OCD); specifying the class templates as LOTOS processes and ADTs; composing
objects; prototyping the object model by executing the LOTOS speciﬁcations; and

reﬁning the speciﬁcations according to the results of the rapid prototyping.

Formalization approach

ROOA formalizes objects in terms of LOTOS processes and abstract data types,
where the LOTOS processes are used to specify the dynamic behavior of the objects,
and the abstract data types (ADTs), given as parameters of the processes, are used
to specify the state information of the objects. An object that merely plays the role
of an attribute of another object is speciﬁed as a single abstract data type in ROOA.
In order to avoid design issues, ROOA, proposed for use in the analysis phase, deﬁnes
ADTs that contain only the necessary information to allow the speciﬁcation to be
prototyped with state information and values to be passed during the inter-object
communication.

ROOA uses a class template, which is speciﬁed as a LOTOS process deﬁnition
with ADTS as parameters, to represent common features of objects of the same kind.

A class that represents a collection of objects consists of a class template and an

0M id

' .l .
urzqurij~

spurifia:
that de
Ii;
ratios
‘3pr '81
68:59:;

may

Con

35
object identiﬁer. An object identiﬁer is an instance of a special LOTOS ADT used to
uniquely identify objects. An Object, a member of a class, is created by instantiating
a class template and is assigned a unique identiﬁcation value.

In ROOA, each object attribute is formalized as an ADT; each object service
is formalized as an operation of an ADT. ADT operations that belong to an object
speciﬁcation are referenced as LOTOS value declarations in the corresponding process
that describes the behavior of the object.

The communication between objects are formalized in terms of LOTOS communi-
cation constructs that include full synchronization, interleaving, and synchronization
operators. Two objects that communicate and exchange data are speciﬁed as two pro-
cesses that are synchronized through events on a gate. Complex object interactions

may be built of simpler interactions by using the LOTOS composition Operators.

Comparison with our approach

ROOA is similar to our approach in that both use the LOTOS formal speciﬁcation
language to formalize the object-oriented models. However, ROOA focuses on for-
mal speciﬁcation derivation during the analysis phase, while we focuses on the design
phase. The formalization rules of ROOA do not treat the data properties of an object
as an ADT but formalize every attribute as an ADT. The approach that ROOA uses
to specify the dynamic features of objects is entirely different from what we proposed.
ROOA deﬁnes states as sets of attribute values and formalizes states as process pa-
rameters. In contrast, we recognized that the date types and their corresponding

values are not available neither during the analysis nor the high-level design stages.

3.1.1
Over

Calm
Dirt t
merita
‘Ttriair
B‘Jujrh
from E
9W. t
[553mm

1 ..
‘E‘wac

36
Therefore we symbolically formalized the states in terms of processes of process al-
gebras and focused on the behavior in different states of an object. The functional
aspect, which is another important feature of a system, is not fully addressed in
ROOA. This may leave the speciﬁcation incomplete for the design phase. We feel
that there is too much design information included in the analysis information, such
as the attributes and services provided by individual objects. This may interfere with
design decisions. However, its introduction of the object identiﬁer is interesting and

may be worth investigating further.

3.1.3 The Fusion Method

Overview

Coleman et al. [7] proposed the Fusion object-oriented development method to sup-
port the entire software development life cycle, including analysis, design, and imple-
mentation. It can be used to develop sequential object-oriented systems as well as
certain restricted types of concurrent systems. By integrating and extending OMT [3],
Booch [41], CRC [42], and formal methods, Fusion attempts to provide a direct route
from a requirements deﬁnition to a programming language implementation. How-
ever, the use of formal methods in the context of Fusion does not have the typical
connotation. No speciﬁc formal speciﬁcation language is used to describe the models.
Instead, sets of informal check lists expressed in natural language for different phases
of software development are given to check the completeness and consistency of the

models.

-r 1
l . o
J‘ .*.
k l-éll;

r“: '
NV 1’]

37

The approach

Fusion includes a set of models and a process for software development. The graphical
notations of the models are based on the existing, well-known notations, such as those
of OMT [3] and Booch [41] methods. The development process divides the software
life cycle into phases and indicates what should be done in each phase. Guidelines
give the order of the tasks to be completed within phases and the criteria that indicate

when to move to the next phase in order to ensure that development makes progress.

Analysis. The analysis phase of Fusion is mainly based on OMT [3] with some
variations. Unlike OMT, the individual objects during the analysis of Fusion have no
interface and no dynamic behavior. Instead, Fusion focuses on the intended behavior
of the system during the analysis phase. The analysis results in three models: system
object model, life-cycle model, and operation model.

The system object model deﬁnes the static structure of the information of a system
in terms of a set of objects to be built. It is derived by eliminating the classes and
relationships that belong to the environment in the original object model. The life-
cycle model characterizes the allowable sequencing of system operations and events
to describe how the system communicates with its environment from creation until
its termination. The Operation model depicts the behavior (effect) of each system
operation by deﬁning their effect (by using preconditions and postconditions) in terms
of the state change it causes and the output events it sends. The life-cycle model and

the operation model together specify the behavior of a system.

 

lbs inf
l‘lillflhlt’lll‘}
models [a
possible 5.}

l0 PllSllft'.’ ‘

other.

Design.
methods.
defiiiitiur
CRC. wl
producer
Object lI
model.
for 1
l5 deriw.
in Ubjﬁ.
Cbiilff‘lll

m‘i'diél. 2

C 1

$1

« v
,. 1...
(I)
—.
H

d‘JSJr-‘P

1p"L

ll] Q‘l ff]

ailr"
l“‘]{

38
The informal checklist given by Fusion includes the completeness checking and
consistency checking. The intent of completeness checking is to ensure that the three
models (system object, life-cycle, and operation) cover all the static information,
possible system scenarios, and system operations. The consistency checking is used
to ensure that the information expressed by different models are consistent with each

other.

Design. The design phase of Fusion is based upon the CRC [42] and Booch [41]
methods. During design, Fusion introduces software structures to satisfy the abstract
deﬁnitions generated during analysis. The systematic design process is derived from
CRC, whose main goal is to explore object interactions from the operation model
produced during analysis. During design, four models are developed and refined:
object interaction model, visibility model, class description model, and inheritance
model.

For each system Operation in the operation model, an object interaction model
is derived to show how functionality is distributed across the objects of a system.
An object interaction model deﬁnes the sequences of messages that occur between a
collection of objects to implement a certain operation. Based on the object interaction
model, a visibility model is derived for each class to describe the object communication
paths in the system. A visibility model shows how a class is referenced. A class
description model for a particular class collates information from the system object
model, object interaction model, and visibility model to derive the methods, data

attributes, and object-valued attributes of the class, respectively. Given the functional

 

lltﬁlllllflll o
refwrenre st
derripiiuii
thriiiam‘l

.‘lll [ill

than} 51: n

the dis:

Compa;

fills Pip;
dex'eltpr
the cons
the dew
be used
Eh. ling,
infmria
Sptf'iﬁp
Pl‘l'puse
Station

minty

39
deﬁnition of operations in the object interaction models, the consequences to the class
reference structures in the visibility models, and the class speciﬁcations in the class
description models, commonalities and abstraction can be identiﬁed to introduce an
inheritance model for the classes of the system.
All the models produced during the design phase can be checked against the
analysis models. In addition, rules are also given to check the consistencies among

the design models.

Comparison with our approach

This approach is an attempt to integrate the best aspects of different well-known
development methods. Similar to our approach, Fusion proposes checklists to check
the consistency between the models in order to eliminate errors introduced during
the development process. Although formal methods are mentioned and claimed to
be used, there is no use of formal speciﬁcation languages for representing the mod-
els, thus preventing rigorous analysis of the models and leaving the checklists in an
informal format. Our approach introduces formal speciﬁcations in terms of a formal
speciﬁcation language beginning with the analysis phase. Our development paradigm
proposed for design focuses on a stepwise reﬁnement that is based on formal speci-
ﬁcations. Our approach has signiﬁcant advantage over the Fusion approach in that
mathematical reasoning about the properties of the target system and formal, rig-
orous consistency checking between models are possible. However, the development
paradigm for analysis and design of Fusion is easier to follow than that of OMT and

may be useful for our design paradigm development.

3.1.4
Overvii

The Ra

I
lllflllllf
Dfﬂ'Eff’.
Lfllllf“
-. ,1
)ldlll'jg
Octal.
in Si,

level

l'nil

flu;

40

3.1.4 The Uniﬁed Method

Overview

The Rational Corporation founded by Grady Booch and James Rumbaugh has been
attempting to develop a uniﬁed method that can be used as a standard method for
object-oriented software development. Joining forces with other software development
methodologists (e.g., Ivar Jacobson, Bran Selic, etc.), Rational has made signiﬁcant
progress in the past year (1997). The promising products of Rational include the
Uniﬁed Modeling Language (UML) [43, 44, 45, 46], which has been adopted as the
standard object modeling language by the Object Management Group (OMG) in
October 1997, the Object Constraint Language (OCL) [47] that uses simple logic
for specifying invariant properties of systems comprising sets and relationships be—
tween sets, and a development process, Objectory [48], that covers the entire software

development life cycle.

Uniﬁed Modeling Language (UML)

The Uniﬁed Modeling Language (UML) is a language for specifying, visualizing, con-
structing, and documenting the artifacts of software systems, as well as for business
modeling and other non-software systems [44]. The primary goals of UML are as
follows:

0 Provide users with a ready-to-use, expressive visual modeling language to be
used to develop and exchange meaningful models.

0 Provide extensibility and specialization mechanisms to extend the core concept.

0 Be independent of particular programming languages and development pro-
cesses.

0P1

difvréhr.

human

\Z']

41

0 Provide a formal basis for understanding the modeling language.
0 Encourage the growth of the 00 tools market.

0 Support higher-level development concepts such as collaborations, frameworks,
patterns, and components.

Integrate the best software engineering development practices.

UML focuses on providing ( 1) a common metamodel (which uniﬁes semantics of
different object modeling approaches), and (2) a common notation (which provides a
human rendering of these semantics).

The semantics of UML diagrams are described in terms of the UML metamodel.
The UML metamodel is described in a combination of graphic notation, natural
language, and formal language.

The abstract syntax for UML diagrams is provided as a model described in a
subset of UML notation, consisting of a UML class diagram and a supporting natural
language description. (In this way, UML is bootstrapping itself in a manner similar
to how a compiler is used to compile itself.) The well-formedness rules for UML
diagrams are provided using a formal language, Object Constraint Language, and
natural language (English). Finally, the semantics for UML diagrams are described
primarily in natural language, but may include some additional notation, depending
on the part of the model being described.

In terms of the views of a model, the UML deﬁnes the following graphical dia-
grams:

0 Use case diagram: describes the relationship among users and use cases (sce-
narios that a system is used) within a system.

0 Class diagram: describes the types of objects in the system and the various
kinds of static relationships that exist among them.

42

0 Behavior diagrams: describe different perspectives of the behavior of the
objects.

— Statechart diagram: shows the sequences of states that an object or
an interaction goes through during its life in response to received stimuli,
together with its responses and actions.

— Activity diagram: is a variation of a state machine in which the states are
activities representing the performance of operations and the transitions
are triggered by the completion of the operations. (It represents a state
machine of procedure itself; the procedure is the implementation of an
Operation on the owning class.)

— Interaction diagrams: describe how groups of Objects collaborate in
some behavior.

* Sequence diagram: shows an interaction arranged in time sequence.

4: Collaboration diagram: shows an interaction organized around the
objects in the interaction and their links to each other.

0 Implementation diagrams: show aspects of implementation, including
source code structure and run-time implementation structure.

— Component diagram: shows the dependencies among software compo-
nents, including source code components, binary code components, and
executable components.

— Deployment diagram: shows the conﬁguration of run-time processing
elements and the software components, processes, and objects that live on
them.

Object Constraint Language (OCL)

OCL is a formal language that can be used to express side-effect-free constraints.
UML uses OCL to specify the well-formedness rules of the UML metamodel. In the

context of UML modeling, OCL can be used for a number of different purposes [47]:

e To specify invariants on classes and types in the class model.

0 To specify type in invariants for Stereotypes (concrete examples).
0 To describe pre- and postconditions on Operations and Methods.
0 To describe Guard on transitions in state diagrams.

e To specify constraints on operations.

Bel

éhilt

sent

ptirr

Dbrra

(I)

319 E

a:

43

Because OCL is a pure expression language (declarative language with no side
effect), the state of the system will never change because of an OCL expression,
even though an OCL expression can be used to specify a state change, e.g., in a
postcondition.

As a typed language, OCL provides a set of predeﬁned types, with associated
operations, for modelers. The predeﬁned types, including Boolean, Integer, Real,
String, etc., are independent of any object model and part of the deﬁnition of OCL.
In the context of UML, all types / classes from the UML model are types in OCL that
are attached to the model.

OCL expressions can refer to types, classes, interfaces, associations and data types.
All attributes, association-ends, methods, and operations without side-effects (change

the state of the system) that are deﬁned on these types can be used.

Objectory process

Objectory [48] is a process developed by Rational to support the full life cycle of
software development. Ob jectory advocates a controlled iterative process, with strong
focus on architecture. It is a use-case driven, object-oriented process, using UML as
a notation for its models.

The Objectory process can be described in two dimensions: time and process
components. In terms of time, the Objectory process divides a development cycle

into four consecutive phases:

0 Inception phase: establishes the business case for the system and delimits the project
scape.

o ElabOration
the WeCt

. ConsllUCllC
is ready to

 

0 Transition

Similar 10 Oll

porterrts that Ob

o Requiremen
velopers an
supplemenll

o Analysis an
phase.

0 Implement;

0 Test: verift

Comparison a

Rational's prod

quite different i:

l'lll. orig:

girl.
:15?le our am.

he notation in.

er ‘7 V
.mmnhuadi

.llalmt‘ rnt3(],.[

a , .
m object are in

flat: »
a ﬂow refiner

44
e Elaboration phase: analyzes the problem domain, establishes a sound architectural

foundation, develops the project plan and eliminates the highest risk elements of
the project.

0 Construction phase: iteratively and incrementally develops a complete product that
is ready to transition to its user community.

0 Transition phase: transitions the software to the community.

Similar to other software development processes, the four engineering process com-

ponents that Objectory has are:

0 Requirements capture: describes what the system should do and allows the de-
velopers and the customers to agree on that description. A use-case model and
supplementary requirements are the results of this component.

0 Analysis and design: shows how the system will be realized in the implementation
phase.

0 Implementation: produces the sources that will result in an executable system.

0 Test: verifies the entire system.

Comparison with our approach

Rational’s products share a lot of similarities with our approach, yet they are still
quite different in several aspects.

UML originated from OMT [3], Booch’s method [49], and OOSE [50]. OMT is
used in our approach as the graphical front end. The OMT notation is a subset of
the notation included in UML, with the exception that data flow diagrams are not

explicitly used in UML. The Activity diagram in UML shares similar concepts with our
dynamic model reﬁnement. Both of them are intended to describe how the methods of
an Object are implemented. Our newly introduced SRFM that focuses on describing

data ﬂow reﬁnement does not have a counterpart in UML. While UML notation is the

tr‘irial prt;
frontvetid ;
lorrrral set
methods 2
operators
purpt‘rse.

defined 1‘.
l0 Slipper
of OCL.

and utili
maphha
ll is arttf

Englllf‘tl
lahgqa,
Coilfasr

l fit.
L: if)

45
crucial product component from Rational, OMT notation only serves as the graphical
front—end in our approach. The emphasis and focus of our approach are the underlying
formal semantics. OCL in UML allows users to specify pre- and postconditions for
methods and operations, and guarding conditions for state diagrams. In our approach,
operators deﬁned in the algebraic speciﬁcations (in ACT ONE) are used for the same
purpose. Since OCL uses methods depicted in Class diagrams instead of Operators
deﬁned in well-deﬁned algebraic speciﬁcations, no rewriting mechanism is available
to support a rigorous reasoning of the pre- and postconditions expressed in terms
of OCL. The Objectory process covers the entire life cycle of software development
and utilizes UML notation. Our design process focuses on utilizing formalized OMT
graphical notations to conduct a stepwise reﬁnement during the design phase, while
it is anticipated that the technique can be extended to the implementation phase of
software development.

In general, the underlying motivation and philosophy of Rational’s and our ap-
proach are quite different. Rational attempts to introduce standardized notation for
object-oriented modeling as well as a development process that utilizes the UML no-
tation. A large amount of design effort of Rational’s Objectory process is contributed
to demystify the design process. Concerned with the lack of familiarity of the software
engineering community with formal methods, only a light-weight formal speciﬁcation
language, OCL, is introduced to describe a part of the system during modeling. In

Contrast, the motivation of our research from the beginning has been to introduce
formal methods into software development. In order to alleviate the difficulty of

usulg fOrmal methods and textual, abstract formal notation, we chose OMT as the

naphtha
hahhirt

Eilltl 59R

merit of

", r.
ltllllldl

3JJE

OVer

46
graphical front-end and formalized its notation. A well-deﬁned formal speciﬁcation
framework with sound mathematical foundation forms the basis of our formalization
and serves as the back-end of the approach. Our design process is developed to utilize
the formalized and integrated graphical notation in order to systematically employ
formal methods during the design process. The process advocates a stepwise reﬁne-
ment of design. Because well-deﬁned formal speciﬁcations constitute the underlying
formal semantics of the graphical notation, rigorous analysis and speciﬁcation analy-
sis are amenable to designers. Therefore our research serves to provide a means for
developers to move from an easy-to-use graphical modeling technique to the beneﬁts

of a formal description of a system amenable to automated analysis.

3.1.5 The Real-Time Object-Oriented Modeling
Overview

Real-Time Object-Oriented Modeling (ROOM) [51, 52] is an object-oriented method
for real-time systems developed originally at Bell-Northern Research by Bran Selic
and Garth Gullekson. ROOM is a method for developing real-time software that com-
bines the object paradigm with advanced domain-speciﬁc modeling concepts. Special
emphasis is placed on modeling the architectural levels of software that are key to re-
liability, understandability, and evolvability. The method is also distinguished by its
ability to take advantage of computer-based automation (through executable mod-
els, reuse, and automatic code generation) for better product quality and greater

Productivity.

 

The approach

ROOM includes

nization irarnew

The modeling

time modeling 1

 

principle of nsin
the modeling in:
discontinuities i:
Actors: are oh jet-
models are com]
along protocols
described by R
protocols. and '

In terms of

0 Actor cla

° ROOthl;

ROOM alsl
ROOM speciﬁc

47

The approach

ROOM includes a modeling language, a set of modeling heuristics, and a work orga-

nization framework.

The modeling language. The ROOM modeling language was developed as a real-
time modeling language rather than as a general-purpose language. Based upon a
principle of using the same set of models for all phases of the development process,
the modeling language is developed to avoid introducing any arbitrary or unnecessary
discontinuities into the development process. The key concept in ROOM is an actor.
Actors are objects that are independent, concurrently active logical machines. ROOM
models are composed of actors that communicate with each other by sending messages
along protocols. Actors may be hierarchically decomposed, and may have behaviors
described by ROOMcharts, a variant of Harel’s state charts. Descriptions of actors,
protocols, and behaviors can all be reused through inheritance.

In terms of the views of a model, ROOM deﬁnes the following graphical diagrams:

0 Actor class diagram: captures all high-level structures of a system.

0 ROOMchart: captures the high-level behavior of actors.

ROOM also has a standard ROOM linear form that can be used to represent
ROOM speciﬁcations, described in terms of graphical diagrams, in textual format.
This enables ROOM to subject its model speciﬁcation to some type of analysis. Given

the executable nature of ROOMcharts, formal analytical approaches to validation is

possible. \'alitl.-.

are spttiﬁt‘d in l

 

Modeling heu
dmndmghm
derelopment pr
talidation and

the basis for th

\l'ork organi
mixed with cr
experience wit

Opulent metht;

C0Inparison

ROOM and c
proach attetrt

0mm pron

all? different.

the interactir.

[Dammit for tl

altar. sis. HM

51':
i k

to.
"In; The

“ v S

48
possible. Validation of ROOM models is primarily by execution of scenarios, which

are speciﬁed in terms of test cases.

Modeling heuristics. Based upon the modeling language, ROOM provides a set
of modeling heuristics to conduct model development. The heuristics include a model
development process that advocates an iterative approach to model construction and
validation and heuristics that pertain to the architecture Of a system, which forms

the basis for the system’s long-term evolution.

Work organization. Work organization refers to the top-level process issues in-
volved with creating products and managing projects. Based upon actual industrial
experience with large complex projects, ROOM advocates a product-oriented devel-

opment methodology.

Comparison with our approach

ROOM and our approach share a number of similarities. Both ROOM are our ap-
proach attempt to use the same set of models for all phases of the software devel-
opment process. Although the speciﬁc modeling techniques of the two approaches
are different, both of them focus on modeling individual objects, their behavior, and
the interaction between active, concurrent objects. The executable nature of the se-
mantics for the behavior model enables both approaches to perform formal validation
analysis. However, ROOM has special strength in describing static structures of a
System. The key difference between the two approaches is that our approach has a

well-deﬁned, solid mathematical foundation in terms of process algebras and algebraic

specificati-
mtre rigrt

Ralph C

3.2

This sect
approarl
to iorrne

data hot

3.2.1

Overri.

llll‘r»,
“‘45 {1

49
speciﬁcations, whereas ROOM relies on rigor deﬁnition of ROOMcharts. This enables
more rigorous analysis methods amenable to our speciﬁcations other than validation

analysis only.

3.2 N on-Ob ject-Oriented Based Approaches

This section gives an overview of the formalization of three non-Object-oriented based
approaches. SAZ [53] and Semmen’s method [54] both use the Z speciﬁcation language
to formalize structured development methods. France [55] formalized an extended

data ﬂow diagram in terms of an algebraic speciﬁcation language.

3.2.1 SAZ Method

Overview

The SAZ Project [53] combines the beneﬁts of the Structured Systems Analysis and
Design Method (SSADM), comprising data flow and entity—relationship diagrams,
with that offered by the Z speciﬁcation language. In SAZ, Z can be used either as a

pure quality assurance tool or as an integral systems analysis technique.

Formalization approach

There are two uses of Z in the SAZ project. The simpler one is its use for quality
audits. A formal data model is prepared after requirements analysis and formal
mOdels of logical processing are derived at the end of requirements speciﬁcation in

terms of Z speciﬁcations by a third party in conjunction with the development process.

If any prt
to he rch
The
process
include:
physica
tion Oi
par i ll"
comp:

p
([1 llll

50
If any problems or ambiguities are identiﬁed in the Z speciﬁcations, alterations have
to be referred back to the development team.

The other approach is to integrate the use of Z into the SSADM development
process to conduct a rigorous, formal software development. The SSADM method
includes ﬁve modules: feasibility, requirements analysis and speciﬁcation, logical and
physical design. The system state of the logical data model (LDM), which is a varia-
tion of Entity-Relationship models, and parts of the functional requirements that are
particularly complex or critical are then presented in the speciﬁcation language Z. It
comprises three main elements: the speciﬁcation of the system state (or a sub-model
of the state), the speciﬁcation of critical processing, and the speciﬁcation of selected
inquiries. The speciﬁcations can also be reﬁned with the development of the system.

The principal beneﬁts of the integrated method are:

e the ability to express features of the functional system requirements that are not
well documented or which have been omitted from the SSADM requirements

speciﬁcation;

0 the expression of all functional requirements in a common, mechanically-

checkable notation;

e the ability to provide (formal or informal) reasoning about, for instance, pre-

conditions to operations;

0 the facility for concise expression of error processing.

 

Compa

SAZ is 2
in order
logical
terpart-
llp'rlllli'd
focuses
tions. .
lll hilt
Sophis
icate

ernpl.

ltgra

Edéhh

3.2.

51

Comparison with our approach

SAZ is also an attempt to introduce formalisms into a software development process
in order to eliminate inconsistency, ambiguity, and incompleteness. The formalized
Logical Data Structure (LDS, the diagrammatic part of LDM) and DF D have coun-
terparts in our approach. Its formalization mechanism is entirely different from our
approach. Z is a speciﬁcation language based on set theory. SAZ’s speciﬁcation
focuses on obtaining a state speciﬁcation of the system, which comprises type deﬁni-
tions, entity types, entity sets, and relationships that represent the state of a system.
In addition, SAZ is currently still a proposed methodology and, so far, there is no
sophisticated tool support. Our approach is based upon algebraic speciﬁcation, pred-
icate speciﬁcation, and process algebras. We advocate an systematic approach to
employ formal methods during software design process in a stepwise fashion. The in-
tegration of the OMT graphical models and formal methods also makes our approach

easier for the developers to use.

3.2.2 Yourdon and Z

Overview

For the Yourdon modeling approach, Semmens and Allen [54] have developed a Z
Syntax for the Entity Relationship diagrams (ERDs), Data Flow diagrams (DFDs),

and data dictionary to integrate formal methods with structured analysis.

lormaliz

Initially. i
schema tj
illlf’ft. re;
are cloth
schentas
upon th
tion sch
Of erati
the dia
lhi
Speciﬁ-
t‘art h»:
lofted

. - 1
their

Com

52

Formalization approach

Initially, Z speciﬁcations are derived from ERDs. During this stage, basic types and
schema types are deﬁned corresponding to the attributes of each entity and the en-
tities, respectively; state schemas for the instances of each entity and its subtypes
are derived; relationships in the diagram are declared; the entity and relationship
schemas are combined to provide a complete speciﬁcation of the system state. Based
upon the formal speciﬁcations derived from ERDs, DFDs are formalized as Z Opera-
tion schemas. The DFD does not give enough information to specify completely the
operations, but some parts of the Operation schemas can be obtained directly from
the diagram and the data dictionary.

The result of the analysis by using the proposed integrated method is a formal
speciﬁcation that describes both static and dynamic properties of the system. These
can help to signiﬁcantly reduce the chances of speciﬁcation errors remaining unde—
tected until later phases of the life cycle when conventional, informal methods are

used.

Comparison with our approach

Semmen’s approach is another attempt to formalize models of structured software
development method. Its formalization of ERDs is similar to SAZ’S formalization
of LDS, which is a variation of ERD. Since the dynamic behavior of the system in
the Yourdon modeling approach refers to DFDs instead of state diagrams, Semmen’s

approach, unlike ours, formalizes DFDs as a means to formally describe the dynamic

heharior c
and objec
olapphca
better so
formalin

duce fort

lorrnaliz

3.2.3
OVerv

france
errand
Contra
RM 111 a

applir

Porn

fﬂti:

llll (Jr

53
behavior of the system. The difference that lies in the nature of structured methods
and object-oriented methods puts Semmen’s and our approaches in distinct ﬁelds
of application. By proposing a stepwise development framework, our approach may
better serve the software development process rather than only providing a set of
formalization rules. Although Semmen’s method is proposed as a means to intro—
duce formalisms into analysis for structured methods, the information captured and

formalized from DFDs is also applicable to our approach.

3.2.3 Semantically Extended Data Flow Diagrams
Overview

France deﬁned a semantically Extended DFD (ExtDFD)[55] based on a control-
extended DFD (C-DFD), which is a DFD supplemented with notation for describing
control dependencies among its elements, associated with formal semantics. By giving
formal semantics to the C-DFD, ExtDFD allows the speciﬁers to investigate desired

application properties and verify semantic decompositions of data transformations.

Formalization approach

ExtDF D formalizes C-DFD in terms of algebraic speciﬁcations. The components of
C-DFD, including the data and state transformation, asynchronous ﬂows, external
entities, and data stores, are formalized as processes; and a C-DFD is semantically

interpreted as a system of communicating processes. Processes, speciﬁed algebraically

by algebraic Sill

 

and events and I
The sernanti
up fashion iron

losing approac-

l. Derive AS
supphed

called th

2. Derive a
amongl
the Sly”?

DFD. is

3' Dtrive
the 5y,

resUltir

GlVOn ll

and I/O Cor

Mi .

54
by algebraic state transition systems (ASTSS) [56, 57], are composed of sets of states
and events and classes of behaviors.
The semantics of a C-DFD are speciﬁed in terms of ASTSs generated in a bottom-
up fashion from ASTSs that describe the individual C-DF D components in the fol-

lowing approach:

1. Derive ASTSs characterizing the behavior of each C-DFD component from specifier-
supplied descriptions. The resulting set of ASTSs, together with the C—DFD, is

called the Basic Interpreted C—DFD.

2. Derive an ASTS characterizing the synchronous interactions that can take place
among C-DFD components from the Basic Interpreted C-DFD. This ASTS is called
the Synchronous Interaction Speciﬁcation (SIS). The SIS, together with the C—

DFD, is called Basic ExtDFD.

3. Derive an ASTS characterizing the permissible time-dependent relationships among
the synchronous interactions specified in the SIS from the Basic ExtDFD. The

resulting ASTS is called the Behavioral Speciﬁcation (85).

Given the formal semantics of C-DFDS in terms of ASTSs, syntactic consistency
and I/O consistency are deﬁned for the ExtDFD in order to formally and rigorously

verify the consistency between levels of reﬁnements.

Comparison with our approach

Although ASTS, the underlying formal speciﬁcation language, is also an algebraic

speciﬁcation language similar to LSL and ACT ONE, the ExtDFD is signiﬁcantly

Int

9..

r U

55
different from our approach. The ExtDFD is proposed for structured methods; our
approach is intended for object-oriented methods. The ExtDF D does not contain
any model that is similar to the object model. The integration of the data ﬂow
information and control information in ExtDF D is achieved from extending the DFDs
by including state and control information, whereas the integration of the two models
in our approach is achieved in terms of the underlying formal semantics of the models.
In ExtDFD, the formalization rules only formalize C-DFDs in terms of ASTSs but
do not contribute to model integration. In our approach, the three OMT models are
formalized in terms of algebraic speciﬁcations, predicate speciﬁcations, and process
algebras. The integration among the models are achieved in terms of the underlying
formal semantics of the models. In addition, our approach also includes a design

process to take advantage of the formalization and integration techniques.

3.3 Systematic Approaches to Reﬁnement of Anal-

ysis Information for Design

In this section, we describe two approaches that advocate rigorous, systematic reﬁne-

ment for software development.

3.3.1

OrerVie
IBM 3
other des
[liiitt‘ié
to its it

develop

form;

l'DM

Seccit
and (i‘

Ifﬁﬁg

56

3.3.1 Vienna Development Method (VDM)

Overview

VDM [58, 59] was originally developed to be used for language deﬁnition and com-
piler design in the 1960’s. The original objective was to develop a systematic design
process that progresses from a rigorous deﬁnition of a given programming language
to its implementation. Later, the objective was broadened to include the systematic

development and reﬁnement of designs.

Formalization approach

VDM includes both a formal description language (META-IV) and a systematic de—
velopment process. The VDM design is a series of speciﬁcations in META-IV, starting
with an abstract speciﬁcation of the functions that the system will perform. Each
speciﬁcation in the series is a reﬁnement of the previous one that is more concrete
and closer to the implementation. Proof obligations that ensure the correctness of the
reﬁnement are identiﬁed and must be fulﬁlled by further development and reﬁnement.

The VDM [59] speciﬁcation language constructs include: modules, interfaces, type
deﬁnitions, state deﬁnitions, value deﬁnitions, function deﬁnitions, and operation
deﬁnitions. A VDM speciﬁcation deﬁnes a set of states and a set of operations that
rely on and transform the states. A single Operation is speciﬁed in terms of pre— and
postconditions. Given a speciﬁcation, the design phase realizes data objects by data
reiﬁcation (reﬁnement) in high-level design stages and develops control constructs

to satisfy postconditions by Operation decomposition in low-level design stages. In

addition to tilt

 

obligations art"

operation deft?

Comparison

VDM also lOt‘l.
process. It is I
The formal s;
Stepwise iashi
for data reifit
that ensure t‘.

benefit our It

57
addition to the rules that conduct data reiﬁcation and operation decomposition, proof
obligations are also given by VDM to guarantee the correctness of data reiﬁcation and

operation decomposition.

Comparison with our approach

VDM also focuses on stepwise design and correctness preservation in the reﬁnement
process. It is function-oriented and is suitable for structured development methods.
The formal speciﬁcations are derived directly from requirements and reﬁned in a
stepwise fashion without assistance of intuitive graphical models. However, its rules
for data reiﬁcation and operation decomposition, particularly, the proof obligations
that ensure the correctness of reﬁnement are worthy of further investigation and may

beneﬁt our formalization of the design paradigm.

3.3.2 Correctness preserving program reﬁnements
Overview

Based on Dijkstra’s work [60], Back [61] proposed a program development approach
that deals with reﬁnements concerned with data representations, control structures,
program transformation rules, and implementation of procedure. In addition, the
total correctness of a program can be syntactically proved (not semantically argued)
by reasoning about the correctness of reﬁnement steps in a formal system with a set

of axioms and proof rules.

Theapp

The 11nd»;
hpcl,
udcmn
omrﬁn
lllfrfilllf
Bar
hehn
langna

shni

lf‘llli

Cm

58

The approach

The underlying logic that carries out proofs of program properties is an inﬁnitary
logic, Law, which is an extension of ordinary ﬁrst-order logic, that allows disjunctions
and conjunctions over a countably inﬁnite number of formulas and quantiﬁcations only
over ﬁnite sequences of variables. There are also inference rules that have a countably
inﬁnite number of premises.

Back used the language of descriptions to describe state transformations, that is,
the language is used to specify a program. The primitive statement constructs of the
language includes: a nondeterministic assignment, control structures of composition,
selection, iteration, and nondeterministic binary choice.

Having a set of theorems for proving reﬁnement correctness in terms of weakest
preconditions, Back further proposed a top-down stepwise reﬁnement using descrip-
tions. The proposed formal development approach allows the use of proof rules for

reﬁnement to establish the correctness of the reﬁnement steps.

Comparison with our approach

Both Back’s and our approaches advocate a stepwise reﬁnement during the software
development process. However, Back’s approach deals with the reﬁnement of low-
level program development and algorithm design, whereas ours focuses on high-level
speciﬁcation reﬁnement during the design process. The application areas of Back’s
method and ours are totally different. Back’s approach mainly treats the develop-

ment of procedures and assumes that the Speciﬁcation of program termination can be

mount
rhea
10 llit‘

hnhe

acquired and directly represented in terms of wa. Our speciﬁcation derivation may
serve as the preceding stage for Back’s method. This method is directly applicable
to the implementation of the detail design speciﬁcation and may be valuable for our

further research when we move from design to the implementation phase.

Chapter 4

Object Model Formalization

Revisited

In this chapter, we re-examine the object model formalization and introduce a new

formalization rule for the object model.

4.1 The Derivation of Algebraic Speciﬁcations

Although the algebraic speciﬁcation shown in Figure 2.15 can be used for requirements
analysis purposes, it does not provide sufficient design information for implementation
such as attributes and operations. The original intent of the object diagram formal-
ization [27] was to deﬁne formal semantics for the high-level object diagram used in
the analysis phase, where these speciﬁcations should be amenable to reﬁnement to
include design details. However, the acquisition of such detailed speciﬁcations is not

easy to obtain and requires more information than can be directly determined from

60

S‘i'Sl t?

erati

iOl

61
the formalized object diagrams. Since the design stage typically introduces more de-
tails about operations that describe the system behavior, we use information from
the functional and dynamic models to contribute to the design speciﬁcations.

The functional model represents the operations and data transformations of the
system in terms of data flow diagrams. At the most detailed level, each of the op-
erations, or processes, are operators of objects depicted in the object model. The
process bubbles in a data flow diagram determine the services of the system, thereby
deﬁning the operators for the objects and the events, actions, and activities in the
dynamic model. From the formalization perspective (see Chapter 6), the signature
of a given operator for an object is determined by the input and the output data
ﬂows to/ from the corresponding process bubble. This signature information is used
in both the object model deﬁnition during the design stage and in the dynamic model

speciﬁcation.

4.2 Distinguished Sort

In a speciﬁc problem domain, by sharing some commonality, a set of objects can
be abstracted into a class. In the world of software engineering, the commonality is
represented as attributes that are expressed in terms of speciﬁc data values. In the
corresponding algebraic speciﬁcation for a class of objects, each attribute is repre-
sented by a data sort that denotes a range of values for the attribute. In order to
refer to the set of sorts for attributes of an object class, a sort that represents the

object class and a tuple operator can be introduced into the algebraic speciﬁcation.

The sort
the tip
- ttrihnt
SUI I IO,l
struct '

of an t

its att
rigors

ft.

Ll"

,.
.14-
VT

62

The sort of the Object class is deﬁned as distinguished sort, which is sometimes called
the type of interest or data sort [19]. The tuple operator is proposed to contain the
attributes of an object to form a value of the distinguished sort. The distinguished
sort together with the tuple operator are like a typical record type declaration con-
struct provided by most programming languages. If, for some reason, the attributes
of an object class cannot be identiﬁed, an abstract sort can be declared as the dis-
tinguished sort instead. The abstract distinguished sort may be reﬁned into sorts of
its attributes later during the design process when it is necessary. In order to achieve
rigorous speciﬁcation, we insist that every object class must have a distinguished sort.

For instance, every person in our society has a gender and a social security number
(SSN). In the world of computer science, this commonality is represented as attributes
for the person class. In terms of algebraic speciﬁcations, the Person distinguished sort
with Gender and SSN as attributes results in the LOTOS speciﬁcation in Figure 4.1.

In this speciﬁcation, the tuple operator is also named Person.

4.3 An added formalization rule

In addition to the object model formalization rules given in Section 2.4, another
rule, OM10, is added to formalize the attributes of an Object class in terms of a
distinguished sort. The attributes of an object are a list of variable-type pairs in
OMT’s object model. The motivation for this rule is to enable access to individual
attribute values. The object class and types of attributes are formalized as sorts of

algebraic speciﬁcations. A tuple that maps from the sorts of attributes to the sort

0i the?
II] ter

l“trial

63

 

type Person is

sorts
Person, Gender, Nat

opns
male : —> Gender
female : -> Gender
Person : Gender, Nat -> Person
getgender : Person -> Gender
getssn : Person -> Nat

eqns

forall p: Person, 5: Nat, g: Gender
ofsort Person
Person (getgender(p), getssn(p)) = p
ofsort Gender
getgender(Person(g,s)) = g
ofsort Nat
getssn(Person(g,s)) = s
endtype

Figure 4.1: The ACT ONE speciﬁcation for person

 

of their corresponding object class is also introduced. The variables are formalized
in terms of operations that map from the sort of the object class to the sorts of the

variables.

lllrgtj

Title I

64

 

OM10 The attributes, in the form of variable-type pairs, of an object class are formalized as sorts and a
tuple that maps attribute types to the distinguished sort that represents the object class.
For Object 0, given attributes a1 : A1,a2 : A2,...,an : An (where a1,a2,...,an are
variables and A1,A2, ...,An are types), create the following expression in LOTOS
speciﬁcation
typedef 0 is
sorts
C), 14-1, i4-2, . .., zl-n
opns
0 : A-1, A_2, ..., A-n ——> 0
get_a-1 : 0 ——) A_l
get_a_2 : O —-) A_2
get an : O —) A-n
eqns
forall a_1: A-1, a_2: A_2, ..., a_n: A.n
ofsort.A_1
get_a_1(0(a_1, a_2, ..., a_n)) = a_1
ofsort A_2
get_a_2(0(a_1, a_2, ..., a-n))
ofsort A_n
get_a.n(0(a-1, a_2, ..., a_n))

(1.2

II
.9
:3

endtype

 

Regardless of whether attributes are given to object 0, sort 0 is treated as the dis-
tinguished sort. Figure 4.2 gives a sample object diagram. Based upon formalization

rule OM10, the automatically generated formal speciﬁcation is shown in Figure 4.3.

 

 

 

d1: D1
d2: D2
d3: D3

 

 

 

Figure 4.2: A sample object model that contains attributes for object O

 

typedef
sor

op:

Mi 3

SEI 0

o ’:
‘7‘ « ,
357k

If.I
J1 to
II".-
“AME

lye"
Illa' II
wa

65

 

typedef 0 is

sorts
0, D1, D2, D3

opns
0 : D1, D2, D3 -> 0
get_d1 : 0 -> Di
get_d2 : 0 -> D2
get_d3 : 0 -> D3

eqns
forall d1: 01, d2: D2, d3: D3
ofsort Dl
get_d1 (0(d1, d2, d3)) = d1;
ofsort D2
get_d2 (0(d1, d2, d3)) = d2;
ofsort D3
get_d3 (0(d1, d2, d3)) = d3;
endtype

Figure 4.3: The automatically generated formal speciﬁcation from the sample object
model

 

4.4 Formal Representation of Algebraic Speciﬁca-
tion

An algebraic speciﬁcation can be represented as a tuple (<1), 1", \II, gt), where <I> is a
set of sorts, P is a set of operators with their signatures, \11 is a set of axioms, and
(b (E (1)) is a distinguished sort. The operators I‘ can be classiﬁed into four categories:
generators, observers, extensions, and auxiliaries. The generators create all the values
of the distinguished sort. The extensions are the remaining operators, such as delete,
whose range is the distinguished sort. The observers are the operators whose domain
includes the distinguished sort and whose range is some other sort. The auxiliaries

are similar to observers but the domain does not include the distinguished sort.

 

 

_——_.._.__ _ __

66
In order to facilitate the discussion of the dynamic model formalization, we orthog-
onally classify the operators as modiﬁers and non-modiﬁers. The modiﬁers include
generators and extensions, whose range is the distinguished sort; the non-modiﬁers
consist of observers and auxiliaries, whose range is some other sort. Thus I‘ is parti-
tioned into two mutually exclusive sets, 9 and O, where Q is the set of modiﬁers and
O is the set of non-modiﬁers. According to this classiﬁcation, operator 0 in Figure 4.3

is a modiﬁer; operators get_d1, get_d2, and get_d3 are non-modiﬁers.

Ch

1’.
AU

ll} [’3

liar

Ld.

Chapter 5

Dynamic Model Formalization

The dynamic model in OMT [3] is based on David Harel’s statecharts [8]. In our
formalization [62, 63], we retain the hierarchical structure and most of the syntactic
notations of statecharts. The OMT approach for creating state diagrams is to create
numerous scenarios, generate event trace and event ﬂow diagrams from the scenarios,
and then create state diagrams from the event diagrams. Although this ad hoc ap-
proach may be useful in determining necessary operations of objects and interactions
between objects, the lack of explicit formal semantics makes the derived dynamic
models inherently exempt from formal, automated analysis. Therefore we deﬁne a
formal semantics for the dynamic model so that formal speciﬁcations can be derived
for the reasoning and analysis at the intra—model and inter-model levels.

We have chosen LOTOS as the formal speciﬁcation language to describe the dy-
namic models of OMT. The major motivations for selecting LOTOS as the target

speciﬁcation language are as follows.

67

68

o It has a sound mathematical foundation deﬁned in terms of process algebras
and algebraic speciﬁcations so that formal analysis can be conducted.

0 It provides support for integrating algebraic speciﬁcations with process algebras.
o It supports concurrency.
0 There are numerous support and analysis tools.

0 The behavior speciﬁcations are executable thus enabling behavior simulation
and requirements validation.

o It has been accepted as an ISO standard and has been successfully used for
numerous industrial projects [64, 65, 66].

The remainder of this chapter is organized as follows. Section 5.1 discusses a
preliminary formalization of the state diagrams. Section 5.2 gives the formalization
of the dynamic models for individual objects. Section 5.3 shows how concurrent state
diagrams are formalized. Section 5.4 discusses the integration of the dynamic model

with two other models. Section 5.5 summaries the chapter.

5.1 Preliminary Formalization

In OMT, a state diagram is used to describe the aspects of a system that are concerned
with time and change, flow of control, interactions, and sequencing of operations
in a system of concurrently active objects. In general, this objective is ambitious.
Accordingly, we restrict the dynamic model to describe only the (observable) behavior

of a system. (Unless otherwise noted, behavior refers to observable behavior.)

Observable behavior. The observable behavior of an object, as the name implies,

refers to its interactions with the environment and the sequences of interactions that

69
can take place. The interactions can be observed outside of the object; the environ-
ment can either be other objects or the system environment.
Deﬁnition-1: Observable Behavior: Observable behavior is deﬁned to be in-
teractions (inter-object communication and object operations) between the object and

its environment and the interaction pattern.

Dynamic model. In most cases, interaction is a synonym for communication.
Here, the interaction includes the inter-object communication and the action ini-
tiation and reaction of the objects. The inter-object communication is the communi-
cation between objects. Therefore, the behavior of an object consists of all its possible
communication and operation sequences with the environment.

Deﬁnition-2: Dynamic Model: The dynamic model formally speciﬁes all the
possible interaction patterns of an object; inter-object communication and object op-

erations are considered interactions.

Communication model. The communication mechanism is not explicitly ad-
dressed in OMT [3]. The state diagrams in the text imply a broadcasting communi-
cation mechanism. Figure 5.1 shows a typical Harel statechart (with a broadcasting
communication mechanism [67]), whose notation is used in OMT and other process-
control modeling systems, including RSML [68]. The condition, in( G), under which
event f triggers the state transition from B to C is valid in statechart notation. How-
ever, when the statechart is introduced into an Object-oriented methodology without

any modiﬁcation, potential problems arise. Since A and D are two concurrent states,

70
they are actually the dynamic models of two independent objects in OMT. Because
the class objects are encapsulated information, information is passed only by meth-
ods, the only inter-object communication mechanism. Obviously, condition “D is in
G” is not visible to A, and therefore it is invalid to use dynamic models of OMT in

exactly the same way as the original statechart is used [67].

 

 

 

 

ﬂ-—-—-—-——_q

 

 

Figure 5.1: A typical statechart

 

With respect to information encapsulation, one key characteristic of any object-
oriented methodology is that a change in an object is not visible to external objects.
The only means that a change can be reﬂected to other objects is through inter-object
communication. Accordingly, the inter-Object communication is the only communi-
cation mechanism in the formalized model; the visible events of an object are carried
by the inter-object communication external to the object.

Deﬁnition-3: Communication Model: Inter—object communication is the only

communication mechanism in the formal model.

71

5.2 Formalizingstate diagrams of individual ob-

jects

In this section, we briefly introduce the formalization of the dynamic model in

terms of a LOTOS speciﬁcation. In order to facilitate our discussion and the

presentation of the formalization, a state diagram is represented as a tuple D =

(S, 23 A) A, (p) C1 Ea ill, A) 6) {pa C) 80) CO), “There

S is a ﬁnite set of states; so is the initial state in D
E is a ﬁnite set of events
A is a set of variables

A is a set of actions and activities, and A g I‘ (P are operators deﬁned in
the corresponding algebraic speciﬁcations derived from object and functional
models)

(I) is a set of data sorts deﬁned in the corresponding algebraic speciﬁcation

C is a set of guarding conditions; c0 represents an empty condition that always
holds (true)

5 is a set of external events to be triggered

if) : S x )3 X C t—> S; tb is a transition function mapping S x E x C to S (1,!) can
be a partial function)

A : S l—> A; A is a function that associates a state with an activity (A can be a
partial function)

6 : S x E x C t——> A; 6 is a function that associates a transition with an action

(,0 : S x E t—> 2"”; cp is a function that maps a state and an event to a set of
variable-data-sort pairs that are associated with the event

C : S x E x C +—+ E; C is a function that maps a transition to an external event
to trigger

In the process of bringing formalisms into the dynamic model, we introduced

some new notations in order to enhance the formality of the state diagrams (The

lli’Oél

simil

72
most recent release of UML [69, 70] indicates that its state diagram is also using a
similar set of notations.)

Figure 5.2 gives a typical state diagram with an initial state
and three state transitions. A label on an arc in the format of
e(d1 : D1,d2 : D2,...,d,, : Dn)[c]/a(dx1,dm2,...,dxm)"0.e’(dy,,dy2,...,dm) denotes
an event 6, data items (d1, d2, ..., dn) associated with the event e, a guarding
condition c, the corresponding action a, and the event 6’ of object O to be triggered.

The remainder of this section introduces formalization rules for each component
of a state diagram. The application of these formalization rules yields a portion of

the formal speciﬁcation of the corresponding state diagram.

 

el(d11:Dll,d12:DlZ ..... d1m:Dlm)[cl]
/al(d12,dlm)"01.e2(dl l,d13)

  
 

 

eZ(d21:D21,d22:D22 ..... d2n:D2n)[c2]/a2

e3/a2"02.el

Figure 5.2: A typical state diagram

  

 

 

5.2.1 State

The derivation and justiﬁcation of object states is one of the most difﬁcult issues for
dynamic modeling. The root of this difﬁculty is that the role of the states is not

clearly deﬁned within OMT. With the formal deﬁnition of the dynamic model given

73
in Deﬁnition-2, it is straightforward to ascertain that the basic function of the states
is to describe the different interaction sequences.
Since the formalized object model requires that every leaf class contain a distin-
guished sort (type of interest), we model the behavior of a leaf class as an individual
state diagram, whose states are determined by partitioning the values of the distin-

guished sort into classes.

 

DFR-l The object states S are formalized as LOTOS processes.
For every state 3, s E S, create the following LOTOS expression
process 5 : noexit :=
endproc

 

Given that most transitions involve attribute value changes, the processes that

formally specify the states are associated with a parameter of the distinguished sort.

 

DFR—2 Every process that formally specifies a state 3 is associated with a parameter :r of the distinguished
sort 4).
For every state 3, s E S, and distinguished sort 45 E <I>, create the following LOTOS expression
process 5 (x: (p): noexit z:
endproc

 

5.2.2 Communication model and event

An event is deﬁned as inter-process communication because only the observable ex-
ternal behavior is well-deﬁned and thus can be modeled. While this convention may
seem restrictive, it is well-deﬁned and exactly models the communication in the real

world; it also achieves information encapsulation in the event deﬁnition.

fora gin
observable lit
Therefore. tl:

The gate
world and is
events of thr
corrrrnunicati

that correspt

x

DFR‘3 The eve
commun
event5,j
E L. E]
For ever
or. Q]

pri
en

\

for those

fOlmalize the

\

on Its type (it

 

74
For a given object, the use of an operator determines whether it corresponds to
observable behavior (that is, inter-object communication) or is internal to the object.
Therefore, the inter-object communication is a subset of the object Operators, F.
The gate construct in LOTOS is used to describe the interface to the external
world and is able to accept and deliver data. It is straightforward to specify the
events of the dynamic model as gates in LOTOS speciﬁcations. The inter-Object

communication (message passing) is modeled as an event arriving at a certain gate

 

that corresponds to a speciﬁc operator.

 

DFR-3 The events of an object together with the events to be triggered are formalized as the inter-object
communication external to the object, which is a subset of I‘ (set of the object Operators). The
events, 2, and events to be triggered, E, in a state diagram D are specified as a formal gate list
[2 U E] for the processes in S.

For every state 3, s E S, distinguished sort (p, events 2, and events to be triggered E (d) E
<I>, E Q P), create the following expression

process 5 [E U E](x: (t): noexit 2:

endproc

 

For those events that are associated with arguments, the following rule is used to

formalize the event deﬁnition.1

 

1The notations x,- : a,- and (x,,a,-) are used interchangeably, both of which represent a variable
and its type declaration.

 

Dill-4

‘

In
objec‘

the cc

‘\

I)FIt-5

is Cc
Si iii.

3:1}

D (7:, \

75

 

DFR—4 Attribute pairs 9:,- : a,- (data items) associated with an event e are formalized as variable decla-

rations ?x,~ : 0,- associated with a LOTOS gate e.
For every state 3 and event 6 (s E S,e 6 E), distinguished sort 4), events 2, and events to
be triggered E (d) 6 Q,E (_Z I‘), if the partial function cp maps (s,e) to pairs x1 : a1,x2 :
a2,...,x,, :an, a non-empty subset of A x Q ({(x1,a1), (x2,a2), ..., (xn,an)} E 2"”), create
the following expression

process 5 [E U E](x: a): noexit :=

e ?x1:a1, ?$2 202, ..., III?” :a,,;
endproc

If the partial function go maps (s,e) to an empty set (no associated attribute for event e),
create the following expression
process 5 [E U E](x: (b): noexit :2
9:
endproc

 

In some cases, a transition may be associated with a triggerable event of another
Object. This case is formalized as a value declaration of the data to be transferred at

the corresponding gate.

 

DFR—5 An event to be triggered, e’, is formalized as a value declaration (Iy,) at a LOTOS gate.

For every state 3, event 6, and condition c (s E S,e E E, c E C), distinguished sort (,3, events
2, and events to be triggered E. (o 6 Q, E _C_ I‘), if the partial function 6 maps (s,e,c) to a
triggerable event e’, create the following expression

process 5 [E U E](x: rt): noexit z:

e’ lyl, lyg, ..., lym;

endproc,
where {y1, y2, ..., ym}, a subset of {3:1, 1:2, ..., 2:”, x}, is speciﬁed in the corresponding state
diagrams.

 

5.2.3 Condition

A condition, in the form of predicates, is used to describe circumstances under which a
state transition can take place. We formalize guarding conditions as LOTOS guarded
expressions in form of a predicate preceding a behavior expression, which becomes

possible when the predicate holds.

—_—

DfR-G Aguard
For ever
5:. and c
01.1") I a
non-ow

 

procei
e ?
endpr
where I

A predica

of an Optj'rat'

\-

DFR-7 A new]
Boolean
Given a
50” 0.
sons .\'

Spec
type:
0F

endt
proc
end;
ends

\

5.2.4 A

The activiti.

abehal’ior s
'i

{11%pr all? Sp<

aSr \~.
Jperdtor

 

76

 

DFR—6 A guarding condition c is formalized as a guarded expression [c].

For every state 3, event 6, and condition c (s E S, e E E, c E C), distinguished sort 4), events
2, and events to trigger E ((15 E (I), 2 C_: I‘), if the partial function (p maps (s,e) to pairs 2:1 :
01,32 : a2,...,:1:,, : an, a non-empty subset ofA x <I> ({(zrl,a1), (x2,a2), ..., (:rn,an)} 6 2A“) a
non-empty subset of sorts <I> ({al , a2, ..., an} E 24’), and c aé c0, create the following expression

process 5 [2 U E](x: (1)): noexit :=

e ?$1 101, ?$2 I (12, ..., ?.’13n : (In; ([C] —) ...)

endproc,

where 31,32, ..., 3:” are variables to hold the attributes associated with the event.

 

A predicate that is newly introduced in a guarding condition is formalized in terms

of an operation of Boolean sort in the algebraic speciﬁcation section.

 

DFR—7 A newly introduced predicate in a guarding condition is formalized as an operation of type
Boolean in the algebraic specification section.
Given object D, for every state 3, event 6, condition c (s E S, e E 2, c E C), distinguished
sort 43, and predicate p introduced in condition c, if 331,32, ...,mn are the arguments for p of
sorts X1, X2, ..., X", create the following expression
specification D [2 U E](x: 45): noexit
typedef 43 is Boolean
opns
p: X1,X2,...,X,, —> Bool
endtype

process 5 [2 U E](x: d): noexit :=

end proc
endspec

 

5.2.4 Action and activity

The activities and actions are deﬁned as operators in the algebraic speciﬁcation (ac-
tions are considered instantaneous; activities may occur over a period of time). Since
a behavior speciﬁcation in LOTOS can reference the operators that are deﬁned in the
algebraic speciﬁcation part, we model the actions and activities in the state diagrams

as operator references in the LOTOS speciﬁcation. The difference between activities

{labeled grag
termine. it i
should be m

An actiaz

 

operator (de

 

DFR-8 An ac
COHESD'

For err

maps t

C # C0.
expires

pro

“Or
F0:
an.
In;

77
(labeled graphically as “do: activity”) and actions is not straightforward to de-
termine. It depends on the experience of the designer to determine which operators
should be modeled as activities and which operators should be modeled as actions.
An action can be formalized in terms of a value declaration by a reference to an

operator (deﬁned in the algebraic speciﬁcation) at the corresponding gate.

 

DFR—S An action a is formalized in terms of a value declaration la by an Operator reference at the
corresponding gate e.
For every state 3, event e, and condition c (s E S, e E Z, c E C), if the partial function (,0
maps tuple (s,e) to sorts a1,a2, ..., an (a non-empty subset of sorts (I) ({a1,a2, ...,an} 6 2°»,
0 ¢ co, and the partial function 6 maps tuple (s, e) to an action a (a E A), create the following

expression
process 5 [E U E](x: o): noexit :=
e 72:1 :al, ?:1:2 :az, ?:r,, : an;
(M -+ e !a(y1. y2. ym))
endproc,
where {y1, y2, ..., ym}, a subset of {2:1, 2:2, ..., at", x}, is speciﬁed in the corresponding state
diagrams.

 

With the built-in internal event, 2', predeﬁned in LOTOS, we are able to specify the
activities as value declarations preceded by an internal event, which can be interpreted

as “the return of a result takes time to complete.”

 

DFR-9 An activity a is formalized as a value declaration la at the corresponding gate 6 preceded by a
nondeterministic internal event 2'.
For every 3, 3 E S, distinguished sort qﬁ, events 2, events to be triggered E (d) E (D, 2 Q I‘),
and arguements y1, y2, ..., yn of sorts Y1, Y2, ..., Yn for activity a, if the partial function /\
maps state 3 to an activity a (a E A), create the following expression
process 5 [E UE](x: 43, y; :Yl, y; : Y2, yn : Yn): noexit :=

i; e !a(y1. yz. yn);
endproc

 

Consider the state diagram of the Compressor object shown in Figure 5.3. As
a notation convention in the discussion of diagrams and speciﬁcations for diagrams,

the italic font will be used to denote diagram components and the courier font will

denote:
tion in
the rim
('L‘rmpltj
as acti
done E
the to

result:

y’h

78
denotes speciﬁcation components. The compress and decompress operations transi-
tion from state idle to compression and then to decompression, respectively. Since
the compress and decompress operations, which may take some duration of time to
complete, cannot be considered instantaneous, they should no longer be modeled
as actions, but, instead, considered as activities in the corresponding states. The
done event, (denoted by an unlabeled arrow leaving an activity state), representing
the completion of compression or decompression, activates the actions to return the

results and trigger state transitions.

 

 

[ Compressor: c

 

 
   
     
    
    

  

 

 

 

 

/ W
decompress(d:D) compress(d:D)
W compression
decompress(d) compress(d)
\ j

 

Figure 5.3: The state diagram for the Compressor object

 

Figure 5.4 contains a complete LOTOS speciﬁcation for the Compressor class
based on the formalization rules presented thus far (the exception is that the con-
struction of speciﬁcations for transitions which is discussed next). The speciﬁcation
describes both the abstract data type and the behavior of a Compressor object. The
ﬁrst part of the speciﬁcation describes the abstract data type of the object class in
terms of ACT ONE; the second part captures the object behavior in terms of pro-
cess algebras. The expression “i;cornpresslcompress(data)” exactly models the

compress activity in the state diagram. The behavior speciﬁcatoin captures:

ol

F!)

5.2.

The
Obj. 6..

aim

79

o The Compressor is initially in idle state.

a A decompress request triggers the transition from idle state to decompression
state.

a In the ldecompression! state, the Compressor performs the decompression
activity.

0 Upon the completion of the decompression activity, the Compressor returns
the decompresed data and transitions back to idle state.

0 A compress request triggers the transition from idle state to compression
state.

0 In the lcompressionl state, the Compressor performs the compression activity.

0 Upon the completion of the compression activity, the Compressor returns the
compresed data and transitions back to idle state.

5.2.5 Transitions

The change of state caused by an event is a transition. Although an event, inter-
object communication, or internal event, is the cause of a transition, the transition is
actually triggered by the corresponding action or activity.

However, a state transition does not necessarily imply a state change. Only those
transitions whose starting state is different from its ending state can cause a state
change. Since only modiﬁer operators can trigger a state change, the state transition

that is ﬁred by a non-modiﬁer does not change state.

 

DFR—lO A transition can cause a state change if and only if the action that corresponds to a transition
is defined as a modifier Operator.
For every state 3 and event 6 (s 6 S,e E E), if the partial function 1p does not map tuple
(s,e) to state 3 (3 ¢ ¢(s,e)), then the partial function 6 maps tuple (s,e) to a modiﬁer
operator (6(s,e) E 0); if the partial function 6 maps tuple (s,e) to a non-modiﬁer operator
(6(s,e) E 9), then the partial function 11) maps tuple (s,e) to state 3 (s = w(s,e)).

 

 

 

speciﬁ
library
Nat
endlib
type (
sort
Co:
opn-
um

co:

de:

5 i:
eqn;

fc

endty
helm
Idle
wher:
pro

Em
PM

9111
Ends1

80

 

speciﬁcation Compressor [compress, decompress] (c: Compressor): noexit

ﬁbmary
NaturalNumber
endlib
type Compression is NaturalNumber
sorts
Compressor, Data
(urns
undef_data : -> Data
compress : Data -> Data
decompress : Data -> Data
sizeof : Data -> Nat
eqnw
forall 1:: Data ofsort Nat

sizeof(undef_data) = O;
ofsort Bool
sizeof(x) = 0 => x = undef_data;
sizeof(x) ge sizeof(compress(x)) = true;
sizeof(x) 1e sizeof(decompress(x)) = true;
ofsort Data
decompress(compress(x)) = x;
endtype
behavior
Idle_State [compress, decompress] (c)
where
process Idle_State[compress,decompress]: (c: Compressor)
noexit:=
compress ?data:Data; Compress_State[compress,decompress] (c, data)
[I
decompress ?data:Data; Decompress_State[compress,decompress] (c, data)
endproc
process Compress_State [compress,decompress] (c:Compressor,data:Data): noexit:=
i; compress !compress(data);
Idle_State[compress,decompress] (c)
endproc
process Decompress_State[compress,decompress](c:Compressor,data:Data)::noexitu:
i; decompress !decompress(data); Idle_State[compress,decompress] (c)
endproc
endspec

Figure 5.4: A Compressor class and its behavior speciﬁed in LOTOS

 

81
The state transitions in the dynamic model of OMT are formalized in terms of

LOTOS process instantiations.

 

DFR—ll The state transitions are formalized as process instantiations.
For every state 3 and event e (s E S, e E Z), distinguished sort at, events 23, and events to be
triggered E (d) E Q, 2 Q P), if the partial function 90 maps (3, e) to pairs 2:1 : a1,a:2 : a2, ...,:rn :
an, a non-empty subset of A x Q ({(x1,a1),(:rz,a2),..., (zn,a,,)} 6 2““), the partial function
6 maps tuple (s, e) to an action a (a E A), the partial function d) maps tuple (s, e) to a. state
3’ (s’ e S), and a is of sort ()5, create the following expression
process 5 [2 U E](x: d): noexit z:
e ?2:1 :01 ?:2:2 :a2 ?:r,, : an;
S’lE U Shah/1.312. yml)
endproc
if a is not of sort q), create the following expression
process 5 [E U E](x: d): noexit 2:
e ?2:1:a1?:r2:a2 711:" :an;
e !a(y1, y2, ym);s’[EUE](x)
endproc

 

In cases, where there are multiple state transitions from a single state, the multi-
ple transitions are speciﬁed as multiple process instantiations composed by a choice

operator (“[1”).

 

DFR-12 Multiple state transitions from a single state are formalized as process instantiations composed
by a choice Operator (adding more transitions may add more choice Operators.
For every state 3, events e1 and e2 (3 E S, 61,82 6 2), distinguished sort ()3, events 2, and
events to be triggered E (d E Q, 2 g P), if e1 79 eg, the partial function (p maps tuple (s,el)
to {$11 2 011,112 I (112,...,$1n I {11"}, (3,82) 130 {$21 I (121,1722 2 (122,...,$2j I a2j} (where
{($11,011).)$12,012),---,($1main)},{($21,021),($22,022),---,($2j,02j)} E 2Ax¢ly the partial
function 6 maps tuple (3, e1) to al, (8,62) to a2 (a1,a2 6 A), and the partial function 1,!) maps
tuple (3, cl) to 31:, (3, eg) to 32:, create the following expression‘
process 5 [2 U E](x: d): noexit :=
e1 ?:1:11 :a11 11:12 : 012 ?:r1,,:a1,,;
6: lai(yn 1112 yim): silleEMX)

82 ?.’€21 $021 ?$22 I (122 ?£E2J‘ 1021';

62 !32(y21 3122 312k); 5242 UEKX)
endproc

 

‘The expression may differ according to DFR—lO depending on the sort of a,.

 

5.2.6

Given

ferrna

DFR-l.‘

82

5.2.6 State diagram

Given the formalization rules for the components of a state diagram, we are able to

formalize the diagram in terms of its components.

 

DFR—13 A state diagram can be formalized as either a LOTOS speciﬁcation or a LOTOS process
deﬁnition.
For state diagram D = (S, 2, A,A, Q, C,E, 1,1), A, 6, «,9, C, so, c0), we can have either
process D [2 U E] (x: a) :noexit :=
$0 [3 U E] (X)
where
( algebraic specification )
( process definitions )
endspec

OR

speciﬁcation D [2 U E] (x: a) :noexit
( algebraic specification )

behaviour
50 [>3 U 5] (X)

where
( process definitions )

endspec,

where the ﬁrst format is used if the process will be composed within other speciﬁcations to
form more complex behavior speciﬁcations; the second format is used if the speciﬁcation is a
top level speciﬁcation.

 

An example. Figure 5.5 gives a dynamic model for Storage that corresponds to a
part of the object diagram given in Figure 2.13. Its corresponding class and behavior
speciﬁcations are given in Figures 5.6 and 5.7.

In Figure 5.5, the empty and non_empty states are formalized as the empty_state
and non_empty_state processes, respectively in Figures 5.6 and 5.7. The events,
insert, retrieve, and delete, are formalized as the three gates visible to the
external objects. The guarding conditions are “count(s) gt Succ(0)” and
“count(s) eq Succ(0)”. Since empty_state is the default state that a Storage

object enters when it is initially created, the behavior of a Storage object is speciﬁed

I I

Speci
librar

Boc
endli

80!

Up;

9Q

9116

83

 

 

l Storage:s l

inscrt(d:D,k:K)/insert(s,d,k)
insert(d:D,k:K)/insert(s,d,k)

U retrievc(k:K)/retrieve(s,k)
delete(k:K)[count=l ]/delcte(s.k)

delete(k:l()[count>l ]/dclete(s,k)
L /

 

 

Figure 5.5: The state diagram for Storage

 

 

speciﬁcation Storagefinsert,retrieve,delete] (3: Storage): noexit
ﬁbrary
Boolean, NaturalNumber
endlib
sorts
Storage, Data, Key
opns
new : -> Storage
undef_Data: -> Data
undef_Key : -> Key

count : Storage -> Nat
retrieve : Storage, Data, Key -> Data
delete : Storage, Key -> Storage
- eq _ : Data, Data -> 8001
_ eq _ : Key, Key -> 8001
eqns
ﬂora“ d: Data, k, k1, k2: Key, 3: Storage
ofsort Nat

count(new) = O;

count(insert(s,d,k)) = Succ(0) + count(s);
ofsort Data

retrieveP(new,d,k) = undef_Data;

(k1 eq k2) => retrieve (insert(s,d,k2),k1)= d;

not(k1 eq k2) => retrieve (insert(s,d,k2),k1) = retrieve (3, k1);
ofsort Storage

delete(new,k) = new;

(k1 eq k2) => delete(insert(s,d,k2),k1)=s;

not(k1 eq k2) => delete(insert(s,d,k2),k1)= insert(de1ete(s,k1),d,k2);

endtype

Figure 5.6: The speciﬁcation (in Full LOTOS) of the Storage (1)

 

enu
pn

ends

Shin

93p:

PTOQ

all {3'

U151

84

 

behavior
empty_state[insert,retrieve,delete] (s)
where
‘process empty_state[insert,retrieve,delete](s: Storage): noexit:=
insert? d : Data ? k : Key;
non-empty_state[insert,retrieve,delete](insert(s,d,k))
endproc
process non_empty_state[insert,retrieve,delete](s: Storage): noexit:=
retrieve ?k:Key; retrieve !retrieve(s,k);
non_empty_state[insert,retrieve,delete](s)
[I

insert ?dzData ?k:Key;
non_empty_stateEinsert,retrieve,delete](insert(s,d,k))
i]

delete ?k:Key; (
[count(s) gt Succ(0)] ->
non_empty_state[insert,retrieve,delete](delete(s,k))
[l
[count(s) eq Succ(0)] ->
empty_state[insert,retrieve,delete](delete(s,k))
)
endproc
endspec

Figure 5.7: The speciﬁcation (in Full LOTOS) of the Storage (2)

 

as “empty_state[insert,retrieve,de1ete](new).” This speciﬁcation enables a
Storage object to enter the empty state when it is ﬁrst initialized. The transition from
empty to non_empty triggered by the insert event is formalized in the empty_state

process as:

insert?d : D?k : K ; non_empty_state [insert , retrieve , delete] (insert (3 , d , k) ).

The speciﬁcation “insert ?d:D ?k:K;” indicates that the process is to wait for
an event to occur at the insert gate. In addition, two data values of type D and K

must also be associated with the upcoming event at gate insert.

 

 

the:

DOD

H011

3p;

85
Once an insert event with the two required data values occurs at the insert
gate, the insert action is performed and the transition from the empty state to the

non_empty state is triggered. The transition is formalized as the process instantiation

non_empty_stateEinsert,retrieve,de1ete](insert(s,d,k)),

where “insert(s,d,k)” executes the insert action, and the instantiation of the
non_empty_state process makes the object leave the empty state and enter the
non_empty state.

In the speciﬁcations of both empty_state and non_empty_state processes, sort
S, which includes all the data values relevant to a Storage object, is formalized as
a process parameter. The “insert(s,d,k)” Operation of sort S, which formalizes
the insert action, inserts the newly received data associated with its key into the
storage space and thereby derives the updated storage. The result of this action is
that the storage is no longer empty. Consequently, the non_empty_state process is
instantiated with parameter “insert (8 ,d,k))” that represents a non-empty storage

object.

5.2.7 Summary.

So far, we have addressed the formalization of the state diagram for an individual
object. Objects that consist of an aggregation of objects are modeled by parallel

composition constructs, addressed in the following discussion.

5.3

A tyr
isinn
ered <
statet

I]
p059 ]

opera

86

5.3 Concurrent State Formalization

A typical system is usually composed of concurrent subsystems. In a system that
is implemented by an object-oriented approach, the objects can always be consid-
ered concurrent. In OMT, this concurrency is modeled as aggregate concurrency; in
statecharts, it is modeled with AND states.

The parallel composition operators of LOTOS provide sufficient semantics to com-
pose parallel and concurrent processes. There are three types of parallel composition

operators:

0 Full interleaving: No communication and synchronization between processes.
0 Full synchronization: Every action must be synchronized.

0 Normal synchronization: Only a select set of actions are synchronized.

In the previous sections, we have shown that the formalization of the object and
the dynamic models are inter-related by attributes, operations, events, gates, and state
transitions. Similarly, the formalization of the concurrent composition in the state
diagram is related to the aggregation associations that are identiﬁed and speciﬁed in
the object diagrams.

Theoretically, all the objects in a system are concurrent. In order to manage large,
complex systems, we advocate a hierarchical approach to modeling the concurrent
behavior that follows the system structure described in the object diagrams. The
following rules describe the relationship between the aggregation relationship in the

object model and the synchronization in the dynamic model.

 

DfR-l

Dill-l
DfR-l

S}r1(
eurre
sync]
in te

servi

Slall
Sert'

”Tide

of ti
Ber-l,
‘1

.‘.¥

in}:

87

 

DFR-14 Every aggregate object is responsible for composing the behavior of its concurrent aggregation
objects to form one behavior specification.

DFR—l5 The behavior of every aggregation Object must be composed by and only by its aggregate Object.

DER-16 Only when there is an association between two aggregation objects, can the aggregate Object
model the corresponding synchronization between the two objects.

 

Synchronization mechanism and notations. The synchronization between con-
current object dynamic models are speciﬁed by name binding. If two dynamic models,
synchronized in a state diagram, share a common service, which is described as a gate
in terms of LOTOS, the two dynamic models are synchronized through the shared
service. The services (gates) modeled in the dynamic models for individual Objects
can be considered as parameterized services. When an object is composed with other
concurrent objects in parallel, the names of its services can be substituted by ac-
tual names in the composition state diagram, such as the one shown in Figure 5.9.
The dynamic models that share common actual names of services are synchronized
through the shared services.

In OMT, dashed lines are used to separate concurrent dynamic models in a given
state diagram. If two concurrent dynamic models in a state diagram share no common
service, they are composed in terms of interleaved LOTOS process algebras. However,
under some circumstances, even if two dynamic models share common services, we
still want to compose them as interleaving dynamic models. This happens when both
of the objects use the same actual service to synchronize with objects other than
each other. A new notation is introduced to represent the forced interleaving. The

notation has three parallel lines drawn in vertical to the dashed line that separates

the inter

dtnamie

The 1'

that onlj

88

the interleaving dynamic models. A sample diagram is given in Figure 5.8, where

dynamic models d2 and d3 are interleaved.

 

 

O

 

 

 

f...

d2 d3

————————

l

bud—--I-Iﬂ—“a—‘n-H

 

 

L

Figure 5.8: A sample state diagram with interleaving dynamic models

p. _

j

 

The following rules use LOTOS’ normal synchronization construct [21] indicating

that only a selected set of gates are synchronized.

ln tl
0f Slam

and am:

Sptejﬁfa

89

 

DFR—l7 In a state diagram that composes dynamic models of concurrent objects, the dynamic
behaviors are synchronized through shared services.
The state diagram D = (S, 2, A, A, Q,C,E, i/J,)\,6, 90, C, so,c0) composed of
D1=(51,21,A1,A1,4’1,01,31,1/J1,/\1,51,‘P1,Ci,810,C0),
Dz = (52,£2,A2,A2.‘1’2,Cz,52,1l’2,A2r52,¢2,C2,320,CO), ------ r
and Bu 2 (Sn,2,,,A,,,An,Qn,C,,,E,,,i/Jn,/\n,6,,,gon,cn,sno,c0) is formalized as:
speciﬁcation DESI U 22 U U 2,. U E] (x:¢,x1:¢1,x2 d2 , . . . ,xn:d>,,): noexit
(algebraic specification>
behaviour
80 [SUE] (X)
| [T1] |
(D1[21 U 51] (X1)
I [T2] |
(Dz [22 U 32] (X2)
I [T3] |
( .....
| [Tn] l
Dn [2,, U 3,] (x,,)
D)
where
(process definitions)

endspec,
where T1, T2, ..., Tn are shared services.

DFR-18 In a state diagram, the interleaving dynamic models are grouped together in terms of
LOTOS interleaving process algebras.
Ifstate diagrams DI =(51,21,A1,A1,¢1,CI.31.¢1,A1,51,991,C1,810,CO),
Dz = (52,532,1)2,Amq’erczﬁzrll’z,A2,52,<P2.C2,820,Co), ------ ,

and Dn : (Sn:2n,AnaAniénaCmSnall’naAnadna‘pnaCnasnOyCO) are interleaVing d)"
namic models in a given state diagram, the following speciﬁcation shall be generated:
behaviour

(

DIEEIUEIJ (X1)
Ill
D2EE2U52] (X2)
III
III
D,,[2,,UE.,,] (xn)

 

In the object diagram shown in Figure 2.13, a Disk Manager is an aggregation
of Storage and a Compressor (notice the one-to-one relationship between aggregate
and aggregation objects speciﬁed both in the diagram and in its corresponding formal

speciﬁcation). Hence, the possible synchronizations and communication are between

Dist
It’lll
lllr’ll
syri-
ape
50f

the?

per

out

(‘trr

d--’
Cl.
L‘Vn

33h

Di:

COT]

90

Disk Manager and its two components. Figure 5.9 contains the aggregated concur-
rent state diagram for the Disk Manager class. The dashed lines indicate that the
individual state diagrams are active in parallel. The individual dynamic models are
synchronized through shared services. The state diagram captures that: (1) the input
operation is implemented in terms of the compress and insert operations of Compres-
sor and Storage, respective, and (2) the output operation is implemented in terms of
the decompress and retrieve operations of Compressor and Storage, respective.

Figure 5.10 gives the major parts of the speciﬁcation with the descriptions of
Storage and Compressor omitted (a complete LOTOS speciﬁcation is given in Ap-
pendix D).

The expression “Storage [ins,ret,del] I [ins,ret] lDisk_Manager [input,
output,com,dec,ins,ret]” speciﬁes that processes Disk_Manager and Storage
communicate and synchronize through actual gates ins and ret. Storage’s formal
gates, insert, retrieve, and delete are substituted by the actual gates ins, rot, and
del, respectively. These two processes, in fact, model the communication and
synchronization between their corresponding objects. The communication and
synchronization between Disk Manager and Compressor are similarly modeled.

Since the services com, dec, ins, ret, and del are actually internal services to object
Disk Manager, they can be hidden from the external objects by using the gate hiding
construct provided by LOTOS. Thus only gates input and output are externally visible.
Any design decision or implementation change to the Disk_Manager will not affect
other objects that are externally related to Disk_Manager, as long as the behavior

speciﬁcation of implementation meets the Disk_Manager’s original individual behavior

91

 

 

Disk_Manager

/ Storage \

ins(d:D.k:K)/insert(d,k)
ins(d:D,k:K)/insen(d.k)

ﬂ UR ret(k:K)/retrieve(k)
delete(k:K)[count= 1 ]/delete(k)

delete(k:K)[count>1]/deletc(k)

~---—-—-_-—-—-——--—_-_--—————-——-———-——_-_-——-—---—————_--a

 

 

 

Disk_Manager

output(k:K)"Storage.ret(k)

 
   
      
 

input(d:D,k:K)"Compressor.com(d)

com(d: D)"Storage.ins(d,k) ret(d:D)"Compressor.dec(d)

dec(d:D)/output(d)
........................................................ l

Compressor

dec(d:D) com(d:D)

decompression 0

Figure 5.9: The aggregation concurrent state diagram for Disk Manager

  
      

compression

compress(d)

 

 

 

 

specificati

type Disk
endtype
behavior

(Storag
llius,r
Disk_!a
|[com,d
Compres
where
process
idleli
endproc
process
input
ll
output
Endprm
process
com ?d

l

ret ?d

l

dec ?d
endpro.
Process

Pr0cess

endSPEC

92

 

speciﬁcation DiskJianager [input , output , com , dec , ins , ret , delete]
(ds: Disk_Manager, 8: Storage, c: Compressor)
type Disk_Manager_REF is Disk_Manager, Storage, Compressor
endtype
behavior

(Storage[ins,ret,del] (s)

Ifins,ret]l

Disk_Manager[input,output,com,dec,ins,ret,del] (ds))

l[com,dec]l

Compression[com,dec] (c)

where

process Disk_Manager [input , output , com, dec , ins , ret , delete] : noexit:=
id1e[input,output,com,dec,ins,ret,delete] (ds)

endproc

process idle [input,output ,com,dec,ins ,ret,delete] (ds: Disk_Manager) : noexit:=
input ?dzD ?k:K; com !d !k; wait[input,output,com,dec,ins,ret,delete](ds, k)
[1
output ?sz; ret !k; wait[input,output,com,dec,ins,ret,delete](ds, k)

endproc

process wait [input ,output ,com,dec, ins ,ret ,delete] (ds:Disk_Manager,k:K) : noexit:=
com ?d:D; ins !d !k; idle[input,output,com,dec,ins,ret,de1ete] (ds)

[1

ret ?dzD; dec !d; wait[input,output,com,dec,ins,ret,delete](ds, k)
[l
dec ?dzD; output !d; idle[input,output,com,dec,ins,ret,delete] (ds)
endproc
process Storage[insert,retrieve,de1ete] (3: Storage): noexit :=
....... ()1rzittecl .... ...
process Compressor [compress,decompress] (c: Compressor): noexit :2
....... Omitted
endspec

Figure 5.10: The LOTOS speciﬁcation for a simpliﬁed Disk_Manager

 

speciﬁcation that only contains services input and output. Figure 5.11 shows how the
internal gates com, dec, ins, ret, and del are hidden in the LOTOS speciﬁcation,
denoted by the hide keyword.

In order to perform analysis on the state diagrams that compose the dynamic
models of concurrent objects, the parameters of distinguished sorts may be instan-

tiated. Rules DFR-19 and DFR-20 formalizes the constants, newly introduced by

DEV

fl)
H~
:17

to?

93

 

speciﬁcation DiskJianager[input,output] (ds: Disk_Manager, 3: Storage, c: Compressor)
type Disk_Manager_REF is Disk_Manager, Storage, Compressor
endtype
behavior
hide com,dec,ins,ret,de1ete in
(Storage[ins,ret,de1] (s)
|[ins,ret]|
Disk_Manager[input,output,com,dec,ins,ret,del] (ds))
I [com,dec] l
Compression[com,dec] (c)
where

endspec

Figure 5.11: Speciﬁcation for a simpliﬁed Disk_Manager with hidden internal gates

 

the instantiation of parameters of distinguished sort, in terms of LOTOS algebraic
speciﬁcation. The formalization rules introduce a nullary operation for each of the
newly introduced constant and use equations to specify the equality among the con-
stants. Speciﬁcally, DFR-19 introduces equations asserting that a constant is equal

to itself and every two constants of the same sort are not equal.

DF

Df

Elli-

SI) ii

an.

94

 

DFR—19 If e is a constant, of sort C, introduced by the instantiation of parameter :1: of distinguished
sort 0 for object 0 in a state diagram, then create the following expression
type 0 is
sorts

endtype
DFR-20 For all constants c1,c2, ..., c,, of sort C introduced in object 0, create the following expression

type 0 is Boolean
sorts

cccccc

eqns
ofsort C
c1 eq c1 = True;
02 eq C2 = True;
03 eq C3 = True;
c1 eq C2 = False;
c1 eq C3 = False;
c1 eq on = False;

c,,_1 eq c" = False;
endtype

For instance, the state diagram in Figure 5.12 introduces constants storage, dm01,
and zip for the Storage, Disk Manager, Compressor objects, respectively. The corre-

sponding algebraic speciﬁcation generated to describe the newly introduced constants

and their relationships is given in Figure 5.13.

5.4 Integration with Other OMT Models

We have, in fact, implicitly addressed the integration of the object, functional, and
dynamic models through the discussion of the formalization of the dynamic model.

The LOTOS speciﬁcation in Figures 5.4, 5.6, and 5.7 contain two typical examples

95

 

 

Disk_Manager
/ Storage: s=storage \

ins(d:D.k:K)/insert(d,k)
ins(d:D,k:K)/insert(d,k)

a U” ret(k:K)/retrieve(k)
delete(k:K)[count= l ]/delete(k)

delete(k: K)[count> l ]/delete(k)

 

 

 

Disk_Manager: dm=dm01
output(k:K)"Stroage.ret(k)

   

input(d:D,k:K)"Compressor.com(d)

  
  

ret(d:D)"Compressor.dec(d)

   

com(d:D)AStorage.ins(d,k)

  

dec(d:D)/output(d)

[- ————————————————————————————————————————————————————————

Compressor: c=zip

      

 

 

 
    
 

dec(d:D) com(d:D)
decompress(d): compress(d)

 

 

 

k 1

Figure 5.12: Sample state diagram with instantiated parameters of distinguished sorts

 

specif.
type I
of

eq;

eﬂdtg
“he

Wt

911

96

 

speciﬁcation Disk_Manager [input , output , com , dec , ins , ret , delete] :noexit
type Disk_Manager_REF is Disk_Manager, Storage, Compressor

opns
storage : -> Storage
dm01 : -> Disk_Manager
zip : Compressor

eqns

ofsort Bool

endtype

behavior

storage eq storage = True;
undef_Storage eq undef_Storage = True;
storage eq undef-Storage = False;
undef_Storage eq storage = False;

dm01 eq dm01 = True;

undef_Disk_Manager eq undef_Disk_Manager = True;
dm01 eq undef_Disk_Manager = False;
undef_Disk_Manager eq dm01 = False;

zip eq zip = True;

undef_Compressor eq undef_Compressor = True;
zip eq undef_Compressor = False;
undef_Compressor eq zip - False;

Iﬁde com, dec, ins, ret, del in
(Storage[ins,ret,del] (storage)

I[ins,ret]l

Disk_Manager[input,output,com,dec,ins,ret,del] (dm01))

l[com,dec]|

Compression[com,dec] (zip)

endspec

Figure 5.13: LOTOS speciﬁcation of the sample state diagram

 

WI

85:

IIL‘I

int

HIE

Sid

97
that illustrate the integration. Although the formalization of the functional model
will be addressed in Chapter 6, the services and operators whose availability we have
assumed and discussed intensively in this chapter are both derived from functional
models. The object and functional models together contribute to the formation of
the algebraic speﬁcation in our formalization rules.

In general, the use of LOTOS does not automatically lead to an integration of the
formal speciﬁcations of the three models, though its constructs allow algebraic spec-
iﬁcations and process algebras to share common language primitives thus providing
a possibility to integrate the two types of speciﬁcations. In our formalization, the
integration of the three models is achieved through explicitly imposing certain rela-
tionships upon the constructs of algebraic speciﬁcations and process algebras. The
integration is three-fold. First, the dynamic model is derived in the context of object
models. This approach to modeling provides a degree of integration between the two
models. Second, the integration is achieved in terms of the formalization of individual

state diagrams. The integration includes:
0 The distinguished sort in algebraic speciﬁcations serves as state process param-
eters in process algebras.

o Operators deﬁned in algebraic speciﬁcations serve as actions and activities in
state diagrams.

o The data types used in process algebras are deﬁned in algebraic speciﬁcations.

0 Services (externally accessible operators) deﬁned in algebraic speciﬁcations serve
as gate lists for process algebras.

o The parameters associated with operators serve as attributes associated with
events.

Obj

In ‘
O.)
and
p05
intt
€118
as I

[We]

98
Third, the integration is achieved by composing the dynamic models of concurrent

objects hierarchically according to the system structure speciﬁed in the object model.

5.5 Summary

In this chapter, we introduced a set of formalization rules for the dynamic model of
OMT. The formalization enables the precise speciﬁcation of the behavior of objects
and the simulation of system behavior through executable speciﬁcations. The pro-
posed formalization also integrates the object, functional, and dynamic models in an
intuitive fashion that facilitates analysis and design. Furthermore, the integration
enables system developers to check both intra— and inter-model consistency, as well
as to conduct system development in a stepwise fashion, where consistency between

two adjacent levels of reﬁnement can be checked.

Th
sen
m0
rid
in

inf

Ob~
H14;

ter:

Chapter 6

Functional Model Formalization

The data ﬂow diagram (DFD) was ﬁrst introduced in structured design for repre-
senting data and the processes that transform data [71, 72]. Since the DFD visually
models a system in terms of input/output data flows and processes as well as pro-
vides a means to systematically decompose a system, it has been successfully used
in the development of transaction systems, whose primary objective is to process
information [6].

Based on notions such as modularity, abstraction, encapsulation, and reuse,
object-oriented development methods have advantages over structured methods in
modeling, maintenance, and reuse. In order to present the functional aspect of sys—
tems and objects, many object-oriented approaches have attempted to incorporate
DFDs into the object-orientation paradigm [3]. However, no well-deﬁned approach or
method has been developed thus far. The difﬁculty is due to the incompatible philoso-
phies of structured and object-oriented methods, particularly with respect to their

contradictory system decomposition strategies. The structured approaches decom-

99

fnr I

an d

Sine

betr

O‘i'Ffr \-

100
pose systems according to functionality while the object-based approaches conduct
decomposition according to the static object structure. Therefore, how to use and
integrate the DFD, as a powerful and useful tool that describes the functionalities of
systems and objects, into the object-oriented methods warrants further investigation.

Given the fundamental philosophical differences, there have been two strategies

for handling the situation. One strategy advocates a concurrent development of DFDs
and object models, followed by an explicit association of the processes to objects [3].
Since this approach does not deal with the fundamental, philosophical difference
between the structured and object-oriented methods, the association of processes
with object methods at the end of the design phase is nearly impossible. The other
strategy warns, and even avoids the use of DFDs, for fear that it will irrevocably bias
subsequent object modeling towards a function-orientation [7, 73, 74].

Considering the fundamental contradiction between structured and object-
oriented methods and the successful application of DFDS in the history of software de-
velopment, neither approach discussed above is satisfactory. This chapter attempts to
integrate DFDs into object-oriented methods without violating the object-orientation
philosophy [75]. The proposed approach extends DFDs and introduces formal seman-
tics to functional models in terms of algebraic speciﬁcations. The formalization of

the DFD is developed in the context of the formalizations for the object model that
provides the static structure of the objects and the dynamic model that describes the
behavior, thereby enabling integration in terms of their underlying formal semantics.

The remainder of the chapter is organized as follows. Section 6.1 gives a brief

overview of the background of DFDs. Sections 6.2 and 6.3 show how the DFD is

allr

101
extended and integrated into object-oriented methods. Section 6.4 discusses the
formalization of functional models in terms of algebraic speciﬁcations. Section 6.5
summarizes the integration of functional model with object and dynamic models.

Section 6.6 gives the summary of this chapte.

6.1 The Data Flow Diagram (DFD)

Notations for DFDs. There are numerous variations of data flow diagrams; F ig-
ure 6.1 shows a typical conventional DFD drawn with the primitive notations, where
a rectangle represents an external entity, a circle represents a process or transforma-
tion, a labeled arrow represents a data ﬂow, and a pair of parallel lines represents a

data store.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Data
store
Data item External
External Input information .
7 , entity
entity Process tcrrnediate data flow 9mm" .
inform. n
Output
information External
Process —' entity
E l I 'f . Output
xterna nput in ormatron - - -
entity > Process ntennediate data ﬂow information External
entity

 

 

 

Figure 6.1: A typical data ﬂow diagram

 

In addition, notations for real-time systems were also introduced by Ward [76]

and Hatley [77] to capture the control information and the data ﬂows. Since the

lllt

the

Di
ere.
of (

tha

dete

men

0f 01
lOgei
the s
Objec

Stil’ﬁ

102
statechart is used in OMT to describe the dynamic aspects of a system, which already
includes the control information, only the primitive notations are needed to depict

the functional aspects in our object-oriented models.

DFDs in structured and object-oriented designs. Structured design is an it-
erative reﬁnement process in which the DFD serves as a powerful tool. The purpose
of design is to decompose a system into small pieces according to functionality, so
that the ﬁne-grained pieces can be directly implemented by programming languages.
In each reﬁnement step, processes in the DFDs are further decomposed into more
detailed DFDs. A process that cannot be further decomposed will be directly imple-
mented as a function.

In an object-oriented design, a system is usually decomposed into a collection
of objects that communicate with each other. The services provided by the objects
together with the inter-object communications carry out the functionalities for which
the system is intended. Since the DFD models the functionality of a system or an
object, it is also called a functional model in the object community. Although the
services provided by individual objects may specify a certain aspect of functionality,
without DFDS, it is difficult to capture the overall required functionality and to verify
whether the requirements are satisﬁed.

There are two advocated strategies that deal with the functional model in the
object community. One strategy is used in the object modeling technique (OMT) [3],
where the functional models are developed and reﬁned in parallel with the object and

dynamic models during the analysis phase. Then, during the detailed design phase,

 

Al

 

 

theprt
its 3551
lnngt
model
rnore<
Re
spnn
tseof

mudel

5.2

in 0rd
alld RX

l'nl

0bl9C1-(

103
the processes of the functional models are assigned to individual objects according to
its associated input / output data flows and data stores. Since the philosophies under-
lying the DFD and the object model differ dramatically, the integration of different
models during the later stages of the software development life cycle is considerably
more difficult and perhaps even impossible [78].

Recognizing that the concept of functional modeling directly conﬂicts with the
spirit of object—orientation, Booch [73] and de Champeaux [74] both warn against the
use of even throw-away functional models in order to avoid irrevocably biasing object
modeling towards a function orientation. The latest revision of the Uniﬁed Model-
ing Language (UML) [70, 69] also omitted the functional model from its notations.
However, this strategy goes to such an extreme that little information about the func-
tional aspects of a system is covered in the proposed models [79]. This deﬁciency may
have an impact and pose difficulties during the design stages, since one of the major
purposes of design is to provide implementation details for the functions required for

the system.

6.2 DFD Notation Modiﬁcation

In order to make use of the functional model while retaining the spirit of object-
orientation in object-oriented design, it is necessary to modify the DF D notations
and redeﬁne the role of a functional model.

Unlike the structured approaches, functions are distributed into objects in the

object-oriented methods. Thus we model: (1) the services provided by individual

104
objects, and (2) how the services of individual, aggregate objects can be composed
to implement the services of their corresponding aggregation object. Accordingly, we
prOpose two types of functional models, object functional model (OFM) and service
reﬁnement functional model (SRFM), where the only notations for both models are
external objects, processes, and data flows. Since a data store is modeled in terms of
an object in the object-oriented methods, an explicit data store notation is no longer
needed. All the interactions with a data store object are modeled as communications

with the services associated with the object that represents the data store.

6.2.1 Object function model

Deﬁnition-1: Object functional model: identiﬁes and describes the services pro-
vided by an object and the data ﬂows that flow in and out of services.

Figure 6.2 contains an OF M that illustrates the services provided by an object,
03, and how data items ﬂow into and out of the services S,. The rounded rectangle
represents the object with its name in the upper left rectangle. The process bubbles
(ovals) represent the services. The labeled arrows represent the data ﬂows. The
ground wires associated with services represent the accesses to the internal data of
objects, which is invisible to external objects. For instance, in Figure 6.3, the OF M
of an integer stack object provides services push, pop, and top. All three services need
to access the internal data structure in order to accomplish the required functionality.
This internal data access is represented by ground wires.

Unlike conventional DFDs, the OFM only contains services accessible to external

objects; the operations/ functions internal (private) to the object are not of concern

105

 

lnl

 

 

ln4

 

\

u 1

~01

5

Out L

 

Out;

 

1
]gm
N

Out;

 

Out4_

 

 

 

r

01

S3
@
SS

 

J

Figure 6.2: An OFM that contains services of an individual object

 

 

Stack

 

Integer

 

k

.6 I

J

 

Pop

Integer

Integer

 

Top

 

J

Figure 6.3: An OFM of an integer stack object

 

106

to the OF M, and therefore are not represented in the OF M. Given that the services
will be ultimately implemented as functions, we further require that every process
bubble have at most one output data flow that represents the return value from a
service. This constraint guarantees that there is only one return value from any
service. Indeed, the return value can be of any simple or complex data type.

In Figure 6.2, S1 is a service that has an input and an output data flow that are
I n1 and Outl, respectively. S3 has two input data ﬂows and shares 1712 with S2. S1,
S2, and 53 can be considered as functions with input parameters and return values.
S4 and S5 only have output and input data ﬂows, respectively. Example uses for two
such operations are: (1) an operation that sets an attribute of an object only requests
input parameters, and (2) an operation that retrieves an attribute and returns the

value without input.

6.2.2 Service reﬁnement functional model

Deﬁnition-2: Service reﬁnement functional model (SRFM): models a sys-
tem/object service in terms of the services/operations provided by the aggregate ob-
jects.

Unlike structured modeling approaches, functions are distributed into objects in
the object-oriented methods. The SRFM shows how the service of a target system or
an aggregation object is implemented in terms of the services/ operations provided by
the aggregate objects. Figure 6.4 shows a system level functional model, the highest

level of abstraction for an OFM that is comparable to a Level 0 data ﬂow diagram,

developed during the analysis phase. The SRFM for service S2 of the system is

107
illustrated in Figure 6.5, where S2 is composed of three services, 03.S1, 09.S1, and
08.S2, provided by aggregate objects 03, 09, and 08, respectively (the dashed oval
encapsulates system service SQ). Similar to conventional DFDS, SRFMS focus on
showing how data ﬂows among services provided by the aggregate objects. The order

in which the services are triggered is captured in the dynamic models (state diagram)

but not in SRFMs.

 

 

 

Inl A Outl
Av 31 >

> 52 ——>

In3 X Out3 _
xv '

In4 Am OM44

 

 

 

Figure 6.4: A system level OFM derived during analysis

 

The SRFM given in Figure 6.5 is relatively simple, because the services provided
by aggregate objects are adequate to compose service S2. When services provided by
aggregate objects are inadequate to compose the services of the aggregation object,
additional internal functions for the aggregation object need to be introduced. For
example, in Figure 6.6, an additional internal function F ring, which might convert

data types, is introduced to process the output from 08.52 and generate the input for

108

 

] Out2

 

Figure 6.5: An SRFM shows how a system service is implemented in terms of object
services

 

09.51. Unlike external services, an internal function represents a functional compo-
nent that is imperative, together with aggregate object services, to construct a service
of an aggregation object. The internal function does not have to be literally imple-
mented as a function or a procedure. It may even be implemented as a piece of code
inside the service of the aggregation object. Since each function of an aggregation
object or service provided by an aggregate object has only one output data ﬂow and
circular data flow is not allowed, the services and functions of a SRFM construct an

acyclic directed graph.

 

 

Figure 6.6: An SRF M that introduces an additional internal function

 

109

6.2.3 Data reﬁnement

In addition to the reﬁnement of services, an SRF M may also be used to describe
data reﬁnement. When reﬁning services of aggregation objects in terms of services
of aggregate objects, a data ﬂow at one level of abstraction may consist of two or
more data ﬂows of a lower level of abstraction. For example, the input and output
data ﬂows, I n1 and Ooutl, for service S1 in Figure 6.4 are reﬁned into two input
ﬂows (Inll and In12) and two output ﬂows (Out18 and Out14) shown in Figure 6.7.
A solid box with one inﬂow and multiple outﬂows represents data splitting, where
each split data line is a part of the original data line, and the split data lines are
mutually exclusive; a solid box with multiple inﬂows and one outﬂow represent data
aggregation. The diagram shows that: (1) the input data ﬂow I n1 splits two input
data ﬂows, I ml and I n12, that ﬂow into O3.S2 and 09.S3 respectively; and (2) the
output data ﬂow consists of two data ﬂows, Out18 and Out14, that ﬂow out of the
corresponding services provided by the aggregate objects. The semantics of the new
notations, data aggregation and splitting, will be further discussed and formalized in

Section 6.4.

 

 

Figure 6.7: An SRF M with split and aggregate data ﬂows

 

110

Another type of data ﬂow reﬁnement occurs when input/outﬂow of a service is
supplied to multiple services without further splitting into ﬁner-grained data ﬂows
(data duplicator), or the input / output data ﬂow of a service is one out of a set of data
ﬂows (data selector). In order to represent this data duplicator/selector relationship,
a graphical construct, empty box, is introduced. In Figure 6.8, input data I n1 might
be used by both services 03.S2 and 09.S3; output data Outl can be either 0ut18 or
0ut14, but not both. The data duplicator/selector in the ﬁgure also requires I n1,
I ml, and I n12 to be at least mutual convertible types (values of the types can be
converted into each other); the same constraint applies to Outl, Out18, and 0ut14.
The uses of the services along with their data ﬂows in the SRFMs must be consistent

with the services and data ﬂows depicted in the corresponding OFMs.

 

 

Figure 6.8: An SRFM with reﬁned input and output data ﬂows

 

6.3 Integrating the Functional Model into OOD

Instead of developing functional models in parallel with object models or exclud—

ing functional models from the object-oriented design, the OFM together with the

111

SRFM can be used and integrated in the object-oriented design without violating the

philosophy underlying OOA and OOD.

6.3.1 System level object functional model and reﬁnement

The system level OFM, a special OFM whose object is the target system, can be
obtained from the results in the analysis stage. In fact, the system level functional
model describes the functionalities that are required to be implemented in the target
system. (The detailed rules for transformations from analysis to design is beyond the
scope of this dissertation.) Figure 6.9 shows the system functional model for Disk
Manager. As a notation convention in the discussion of diagrams and speciﬁcations
for diagrams, the italic font will be used to denote diagram components and the
courier font will denotes speciﬁcation components. There are two services, insert and
retrieve, that satisfy the requirement that the system should be able to store and
retrieve data. The insert service takes data and its corresponding key as input, and
stores them inside Disk Manager. The retrieve service outputs the data according to
the key it receives. Service insert does not have explicit output. It either stores data
in the internal data structure of Disk Manager or passes data to an aggregate object.
However, from a perspective external to Disk Manager, the implementation details
about how data is to be processed and stored is not of interest.

After the system is decomposed into aggregate objects and their corresponding
OFMs are constructed, the services in the system level object functional model can

be refined in terms of the services provided by the aggregate objects. Each SRFM

112

 

 

] Disk_Manager]

( D

Data

\
//

Key

K m Dta
ey >& a >

 

 

 

L s

Figure 6.9: System level object functional model for Disk Manager

 

shows how a service of the system is implemented in terms of services provided by
the aggregate objects.

Figure 6.10 illustrates the simpliﬁed Disk Manager with aggregate objects Storage
and Compressor. The OFMs for Storage and Compressor are shown in Figures 6.11
and 6.12, respectively. Figure 6.13 shows the SRF M for the Retrieve service of the
Disk Manager, whose system functional model is given in Figure 6.9. The SRFM
(Figure 6.13) depicts how operation Retrieve of Disk Manager is implemented by
composing Retrieve and Decompress services provided by aggregate objects Storage
and Compressor, respectively.

In order to ensure the consistency between the different functional models, the
SRFMS need to be checked against OFMs to make sure the referenced services to-
gether with their input / output data ﬂows are consistent with their counterparts de-

picted in OFMs. If we check the SRFM in Figure 6.13 against the OFMS in Fig-

113

 

 

 

 

 

 

 

 

Disk
Manager
Storage Compressor

 

 

 

 

 

 

w 3.4..\

Figure 6.10: A simpliﬁed disk manager

 

 

] Storage I

f N

Data

Ke A Data

Key

 

4' Delete

1

. Z I

Figure 6.11: The OFM for Storage

 

 

 

114

 

] Compressor ]

( ﬂ

Data Data

$ Compress v

 

Data

 

 

 

 

L J

Figure 6.12: The OFM for Compressor

 

 

 

’
.........

Figure 6.13: The SRFM for Disk_Manager.Retrieve

 

ures 6.11 and
associated u‘itl
data ilovvs are «

During the

pleteness and s

  
   

 

 

Serrice incom
gate obje

aggregate

Service red til
\
object se
system 5

the systr

Service in
Sociated with
more services
to take. Intr

minimiZe t1] (3

pleteness issi

115
ures 6.11 and 6.12, we will ﬁnd that the number of input and output data ﬂows
associated with Storage.Retrieve and Compressor.Decompress and the labels of the
data ﬂows are consistent with services Retrieve and Decompress.
During the service reﬁnement process, two types of design defects, service incom-

pleteness and service redundancy, can be detected.

Service incompleteness: If a system service cannot be refined in terms of the aggre-

 

gate object services, then either the aggregate objects or the services provided by

aggregate objects are not sufficient to support the system services.

Service redundancy: If every system service is already modeled in terms of aggregate

 

object services and an aggregate object service 0,.Sj has not been used by any
system service, then aggregate object service 0,.Sj is redundant in the context of

the system functionality.

Service incompleteness implies either more services need to be identiﬁed and as-
sociated with aggregate objects or more objects need to be introduced to provide
more services. The nature of the services that are needed determine which approach
to take. Introducing services to existing objects should be given higher priority to
minimize the number of objects. If this approach cannot resolve the service incom-
pleteness issue, new objects need to be introduced. If the object that contains a
redundant service is a newly designed object (in contrast to a reused object), then
the redundant service should be excluded from the corresponding OFM in order to

achieve conciseness and preciseness.

Tilt

live

' 00
do:

581"

Th

Dre

an

n

116

6.3.2 Object functional model and reﬁnement

The object functional modeling and service reﬁnement functional modeling is an itera-
tive process. Similar to the system level object functional modeling and its reﬁnement,
the objects obtained in the previous iteration of modeling are further decomposed into
aggregate objects, and their corresponding services are further reﬁned in terms of the

services provided by the aggregate objects.

6.4 Functional Model Formalization

The OFMS and the SRF Ms are tightly coupled with the object and dynamic models.
In order to integrate the three models formally, the functional models are formalized

in terms of algebraic speciﬁcations and process algebras. In this section, we introduce

the formalization rules for the OF M and the SRFM.

6.4.1 Formalization of the object functional model

The OFM speciﬁes the services that an object provides to the external world. In our
proposed formalization rules, the input / output data items are formalized as sorts of
an algebraic speciﬁcation. Sorts are similar to the programming language concept of
type, but it is important not to confuse these concepts. Sorts represent disjoint non-
empty sets of values and are used to indicate the domains and ranges of operators.
A sort can be implemented as different types in a speciﬁc language. Since the im-

plementation details are gradually added during the design process, we choose sorts

instead Of ill
rule forrnaliz'

”11.1 Each d3
For all ll
declaratii

In order I

resenting an

\
PPR-2 FOr ever
undef.s

\

The servi
external worl
Though obje:
projects [31].
ture of Opera
from tuples (

a sort for its

117
instead of types of a speciﬁc programming language to represent data. The following

rule formalizes the data ﬂows in an OFM.

 

FFR—l Each data item in an OFM is formalized as a sort in the corresponding algebraic specification.
For all the data items, D,(1 g i g n), in an OFM, create the following expression in the sort
declaration part of an ACT ONE specification of Full LOTOS

sorts

D_1, D_2, ..., D_n

 

In order to handle potential exceptions, we also introduce a nullary operator rep-

resenting an undeﬁned data value for each sort.

 

FFR-2 For every sort, S , used in the object specification, introduce Operator
undef_s: —) S.

 

The services provided by an object are the only means for interaction with the
external world. The gates in Full LOTOS speciﬁcations serve an analogous purpose.
Though object services are formalized as operators of algebraic speciﬁcations in some
projects [31], this approach has not been adopted in this research because of the na-
ture of operators of algebraic speciﬁcations. That is, an operator represents a map
from tuples of values to values; its signature is a tuple of sorts for its domain and
a sort for its result. The objective of an operator is to describe the mathematical
relationship between sorts of values. Thus the operators are often used to capture
the properties of systems. Though procedures/ functions of a speciﬁc programming
language share some similarity with operators of algebras, there is a fundamental dis-
tinction between the two. A procedure / function consists of a sequence of data/ control
operations that are intended to perform certain actions on data, whereas operations

deﬁned in algebraic speciﬁcations describe mathematical relations between sorts. The

[Of

110‘

rnl

he;

rul

PM

GO

118
former focuses on operation, the latter focuses on prOperty. Therefore services are
not formalized as operators of algebraic speciﬁcations in our proposed formalization
rules. Instead, the services are formalized in terms of gates in a Full LOTOS speci-
ﬁcation to capture the interface of an object with its external world. The following

rule formalizes the services in an OFM.

 

FFR—3 Each service in an OFM is formalized as a gate that is associated with input and output in the
corresponding Full LOTOS specification.
For all the services, S,(1 g i g n), with inputs, 1,, (1 S ij 3 IL] (1,- represents the permutation of
the input data), and outputs, 0,, in the OF M of object OBJECT, create the following expression

speciﬁcation OBJECT [51, S2, ..., Sn] :noexit :=
(II! 51 : T1, 111,, 1:12 1112, ..., illlil 111”1| -> 01 Ill)
(Ill 32 2 i2, 212,, 122 2122, ..., l2|12| :12|12| -> 02 1k)
(* Sn 1 2:1" 211", 2'1ﬂ 211", ..., inllul 21",,“ -> 0n *)

opns
SI 111, [12, ‘l 11”,] —> 01
52 12,, I22, , 12”,, ‘> 02
Sn . II", 11", a [nun] > 0n

endtype endspec

 

Since LOTOS does not currently support typed gates [80], the input/output ar-
guments for gates/ services are given in annotations delimited by the (* and *) pairs.
For those services without input arguments, the left side of the arrow “->” will be
left blank; for those services without output arguments, a special sort “Void”, repre-
senting an empty set, is used as the output argument. The i’s represent parameter
variables of the corresponding sorts. Currently the description of services in terms of

typed gates are not supported by LOTOS. Therefore, in order to facilitate the analy-

SlS

as l

515

5.4;
The
or

0f

119
sis of the automatically generated formal speciﬁcation, the services are also described
as operations in the opns section of algebraic speciﬁcation.

According to formalization rules FFR-l, FFR—2, and FFR-3, the OFMS for
system Disk Manager and object Storage lead to the generation of the algebraic
speciﬁcations in Figures 6.14 and 6.15, respectively. Sort Void is a special sort that
indicates no value will be returned. The Storage algebraic speciﬁcation of includes
Disk\_Manager, because the aggregate object usually uses the data sorts deﬁned by

the corresponding aggregation object.

 

speciﬁcation Disk_Manager [Insert, Retrieve] : noexit z:
(* Insert : d: Data, d: Key -> Void *)
(* Retrieve : k: Key -> Data *)
type Disk_Manager is
sorts
Data, Key, Void
opnus
undef_Data: -> Data
undef_Key : -> Key

Insert : Data, Key -> Void
Retrieve : Key -> Data
endtype
endspec

Figure 6.14: The ACT ONE speciﬁcation for Disk Manager

 

6.4.2 Derivation of pre— and postconditions for services

The rules given thus far have focused on how to formalize the graphical notations in an
OFM in terms of LOTOS constructs. Next, we discuss an extension to the formalized

OFM to include pre— and postconditions in order to further describe services.

120

 

speciﬁcation Storage [Insert, Retrieve] : noexit z:
(* Insert : d: Data, k: Key -> Void *)
(* Retrieve : k: Key -> Data *)
type Storage is Disk_Manager
sorts
Storage
opns
Insert : Data, Key -> Void
Retrieve : Key -> Data
endtype
endspec

Figure 6.15: The ACT ONE speciﬁcation for Storage

 

Algebraic speciﬁcations for Objects

Before pre- and postconditions for services can be addressed, we must investigate the
abstract algebraic speciﬁcations generated from the FRMs that describe the prOperties
of objects. The algebraic speciﬁcations form the foundation upon which pre- and
postconditions of services can be stated and about which the properties of the objects
can be reasoned.

Although such algebraic speciﬁcations cannot be generated automatically, we are
not without some general ideas of how to construct these speciﬁcations. The sorts
and services depicted and formalized in the previous subsections together with the
results of requirements analysis may all serve as clues to derive algebraic speciﬁcations.
Some high—level guidelines, denoted by GL-X, will be given in the following discussion
about algebraic speciﬁcation derivation.

The derived algebraic speciﬁcations shall include a set of sorts that represent

the attributes for objects, a set of operators, and a set of axioms that describes

121
the prOperties of objects in terms of attributes and their operators. The operators
together with axioms should be sufﬁcient to support the construction of pre— and
postconditions.

The purpose of the algebraic speciﬁcations is to describe the properties of the
modeled objects. Pre— and postconditions of services are themselves expressions of
the properties of an object at a certain time. Since attributes may change over
time, operators that manipulate the attributes need to be introduced to reﬂect and
describe the potential change. Based upon the operators, pre- and postconditions
can be constructed to assert the property of an object before and after an external

service is invoked.

 

GL-l Sufﬁcient operators for the sorts declared in the algebraic speciﬁcation shall be provided to
construct pre— and postconditions.

 

The operators of data sorts only represent a set of manipulations that may be
applied to corresponding sorts. The exact semantics of the Operators are described
through axioms. Therefore, without a set of axioms, no reasoning can be performed

against pre— and postconditions.

 

GL-2 If reasoning about pre— and postconditions is expected, related axioms for algebraic speciﬁca-
tions need to be derived.

 

Formalization of attributes.

An algebraic speciﬁcation is a high-level abstraction intended to describe a class of

objects instead of a particular object. For instance, the algebraic speciﬁcation given

122

in Figure 4.1 only describes the abstract data types of a class of objects, it provides
no means to represent a particular object with concrete values for it attributes. In
order to present individual objects, a mechanism, other than algebraic speciﬁcations,
that can represent objects in terms of concrete values for their attributes is desired.

As mentioned previously, in Full LOTOS, in which algebraic speciﬁcations is a
component, a speciﬁcation can have a set of parameters of sorts that are deﬁned in
algebraic speciﬁcations. This capability provides a convenient mechanism to describe
individual objects. By making the distinguished sort of an object class as a parameter
of its Full LOTOS speciﬁcation, we are able to represent particular objects. According
to the formalization rules for dynamic models, processes of a Full LOTOS speciﬁcation
represent states of an object, therefore the distinguished sort is also formalized as a

parameter for the corresponding processes of the speciﬁcation.1

 

FFR-4 The set of attributes of an object is formalized as a parameter of the distinguished sort for the
corresponding Full LOTOS specification.
For object class 0, and its distinguished sort 4) and a set of services 2, create the following
speciﬁcation 0 [2] (0 : a5) : noexit :2

expression endspec

 

Based upon the guidelines to derive algebraic speciﬁcations and rule FFR—4,
the Full LOTOS speciﬁcation for Disk Manager is given in Figure 6.16, where the
italic text denotes the newly added speciﬁcation components to what was previously
derived in Figure 6.14. Sort Disk is the distinguished sort for Disk Manager. Since the

design is still at a high level, the distinguished sort does not contain other sorts but

 

1This is related to the formalization of the dynamic model, in which processes represent object
states.

123
is an abstract sort representing the potential attributes of Disk Manager. Operators
insert and retrieve are derived to describe potential manipulations on sort Disk.
The services provided by Disk Manager imply that data items may be inserted into
and retrieved from Disk Manager thus giving guidance for the derivation of operators
for sort Disk. Though the operators and the services share similar names, it is not a

necessity.

 

speciﬁcation Disk_Manager [Insert, Retrieve] (disk: Disk) :noexit :2
(* Insert : d: Data, k: Key -> Void *)
(* Retrieve : k: Key -> Data *)
type Disk_Manager is
sorts
Data, Key, Void
Disk (* Distinguished sort *)
opns
undef_Data: -> Data
undef_Key : -> Key
empty : -> Disk

insert : Disk, Data, Key -> Disk
retrieve : Disk, Key -> Data
eqns

forall disk: Disk, data: Data, 1:], k2: Key
ofsort Data
retrieve (empty, key) = undeﬂData;
retrieve (insert( disk, data, 1:1), k2) = if k1=k2 then data
else retrieve(disk, k2)
endtype
endspec

Figure 6.16: The Full LOTOS speciﬁcation for Disk Manager with algebraic speciﬁ-
cations and distinguished sort

 

Pre- and postconditions for services.

The services along with their input / output data ﬂows only describe the interfaces of

an object to the external world. The object properties exhibited by services as well

124
as constraints for services cannot be represented by gates and their corresponding
signatures alone. In order to describe the constraints and requirements for object
services, we make use of concepts used in the Larch Interface Languages (LILs) [19].
The speciﬁc approach is to use pre- and postconditions to depict requirements and
constraints for a service. Thus the speciﬁcation of a service consists of a service

declaration followed by a body of the form:

 

<service declaration)
requires <requirement expression)
modiﬁes <modification expression>
ensures <ensuring expression)

 

For every service, we presume two states for the objects: the state when the ser-
vice is invoked, the pre-state, and the state when it terminates, the post-state. More
speciﬁcally, the pre- and post-states represent two sets of values of the attributes of
an object. In order to refer to the values contained by the attributes of a distin-
guished sort in the pre- and post-states of a service, the postﬁx Operators " and ’,
respectively, are introduced. When applied to a variable/ parameter of a simple sort,
for instance variable x of sort 5, x" and 33’ yield the stored value in pre- and post-
states, respectively. When applied to a variable / parameter of a complex sort, such as
a distinguished sort containing sorts for attributes, A and ’ yield a tuple containing
the values stored in the variable or parameter.

A requires clause (precondition) is used to state restrictions on the values in the

pre-state of both attributes of the corresponding object and parameters for the service.

125
An omitted requires clause is equivalent to the weakest possible requirement, “requires
true”.

A modiﬁes clause states which attribute(s) of the object can be changed during
the invocation of the service. Unless an attribute of an object is listed in the modiﬁes
clause, the service must not change the value of the attribute, and the attribute must
have the same value in the pre- and post-states. If no modiﬁes clause is given, then
nothing may be changed.

An ensures clause (postcondition) places requirements and constraints on the func-
tionality of a service. It relates the pre-state and post-state of a service. The reserved
keyword result represents the value/ output (if any) returned by the service.

Figure 6.17 shows the speciﬁcation for Disk Manager with pre- and postconditions
for services Insert and Retrieve, delimited by (*, *) pairs. For service Insert: the
requires clause of Insert requires that the input parameters of sort Data and Key
contains valid values; the modiﬁes clause states that the values of the attributes of
sort Disk will be changed when Insert is invoked; the ensures clause guarantees
that after the attribute disk is changed, its value will reﬂect the fact that a pair of
data and key is inserted. The ensures clause for service Retrieve ensures that the

returned value will be exactly what retrieve (disk,k) describes.

Integrating pre— and postconditions into dynamic models.

Our speciﬁcation approach is attempting to integrate the Larch and LOTOS spec-
iﬁcation frameworks in order to provide a three-pronged approach to speciﬁcation,

where the algebraic speciﬁcations provide the integration mechanism since both Larch

126

 

speciﬁcation Disk_Manager [Insert, Retrieve] (disk: Disk) :noexit :=
(* Insert : d: Data, k: Key -) Void *)
(* requires d eq undef_Data = false and k eq undef_Key = false *)
(... modiﬁes disk *)
(* ensures disk’ eq insert(disk“, d, k) = true *)
(* Retrieve : k: Key -> Data *)
(It requires disk eq empty = false and k eq undef_Key = false *)
(* ensures result = retrieve (disk, k) *)
type Disk_Manager is
sorts
Data, Key, Void, Disk
opns
undef_Data: -> Data
undef_Key : -> Key

empty : -> Disk
insert : Disk, Data, Key -> Disk
retrieve : Disk, Key -) Data

eqns

forall disk: Disk, data: Data, k1, k2: Key
ofsort Data
retrieve (empty, key) = undef_data;
retrieve (insert(disk, data, k1), k2) = if k1=k2 then data
else retrieve(disk, k2)
endtype
endspec

Figure 6.17: The Full LOTOS speciﬁcation for Disk Manager with pre— and postcon-
ditions for services

 

and LOTOS have algebraic components. In both cases, the algebraic speciﬁcations
provide the foundation to describe and reason about properties of objects. The ser-
vices/ functions speciﬁcations describe the services accessible to the external world as
well as the pre- and postconditions that shall be satisﬁed. The process algebras depict
the behavior of the objects and illustrate how the services / functions are invoked and
interact during the life cycle of their objects. However, the services/ functions in our
approach are more abstract than those typically speciﬁed in the Larch Interface Lan-

guage, whose interfaces are usually speciﬁed in the syntax of a speciﬁc programming

127
language. Since LOTOS does not currently support speciﬁcations for pre- and post-
conditions of services, they are currently introduced as annotations for Full LOTOS
speciﬁcations. A new language that supports our needs, where services/ functions, to-
gether with their pre- and postconditions, of an object need to be explicitly developed;
and corresponding tools are also desired to support the construction, refinement, and
analysis of these heterogeneous speciﬁcations.

Though service declarations and pre- and postconditions speciﬁcation are not
explicitly supported by LOTOS currently, we can still formalize them in terms
of constructs provided by LOT OS. The functional models and dynamic mod-
els share some common features, one of which is that the actions invoked by
events in the dynamic models usually are services/functions deﬁned in functional
models. Figure 6.18 gives a typical state diagram with an initial state and
three state transitions. A label on an arc in the format of e(d1 : D1,d2
D2,...,d,, : Dn)[c]/a(d,,,,dx,,...,dxm)"0.e’(dy,,dy,,...,dy,) denotes an event 6, data
items (d1,d2, ...,dn) associated with the event e, a guarding condition c, the corre-
sponding action a (with parameters dx,,d,,,, ..., dxm), and the event e’ of object O to
be triggered. An event is a request for a services that occurs at a gate representing
the corresponding service (see FFR—3). Usually, if the service is not further reﬁned
into internal functions and services provided by aggregate objects, then the event
will directly trigger the service to which it refers to. Either a service or an inter-
nal function is invoked, the associated pre— and postconditions can be speciﬁed in

the corresponding process algebras that describe the dynamic behavior of the object.

128
The related formalization rules along with the rules for the dynamic model together

contribute to generate formal speciﬁcations in terms of process algebras.

 

cl(dll:Dll,d12:D12 ..... dlm:Dlm)[cl]

/a1(d12.d1m)"01.e2(d1l,d13) .
‘ 82

 

 

 

e3/a2"02.e1

Figure 6.18: A typical state diagram

 

In Chapter 5, we developed a formalization for dynamic models. We will not go
into the details of that formalization, but, instead, concentrate on integrating pre- and
postconditions into the process algebras generated according to the dynamic model
formalization rules given in Chapter 5.

Usually, both pre- and postconditions are used to describe the properties and con-
straints of a service/function in terms of the pre- and post-states of the attributes
of their corresponding object in addition to the input and output data. Since the
value of an attribute may change after a service/ function is triggered, a mechanism is
needed to save the pre-state values of attributes. In the course of the dynamic model
formalization, we introduced a local variable to save the values of attributes when
a process, representing a state in the dynamic model, is entered. The values of the
attributes may be changed by a service/function invoked by an event, thus making

the object transition into another state. Therefore, the values stored in the local vari-

129
able represent the attributes of the object in the pre-state of the services/functions.
The following rule formalizes the introduction of a variable to store the value of the

attributes prior to the execution of a service.

 

FFR—5 The pre-state of the attributes of an object is stored in a local variable when a process, representing
a state in the dynamic model, is entered.
For object class 0, and its distinguished sort d and a set Of services 2, if p is a process, representing
a state in the dynamic model, defined in the process algebras, then create the following expression
that introduces local variable PRE to store values Of attributes at the entrance of the process
speciﬁcation 0 [E] (o : d) : noexit z:

process I? [2] (0 : rt) : noexit :=
( let PRE:= o in

)

endproc

endspec

 

A non-trivial (not a true Boolean expression) precondition, expressed in a requires
clause, refers to input parameters of a service / function and attributes in the pre-state
of the corresponding object in order to state the conditions that must be satisﬁed
before the service/ function can be invoked. A guarding condition of a transition in
the dynamic models is used to describe circumstances under which a state transition
can take place. We formalize both the guarding conditions of the dynamic models and
the preconditions of the functional models in terms of guarded expressions supported
by LOTOS. Only when both the guarding conditions and the preconditions hold can

the corresponding service/ function be invoked.

130

 

FFR-6 The guarding condition and the precondition that are associated with the action of a state
transition are conjuncted and formalized in terms of a guarded expression in LOTOS process

algebras.
Suppose event e (associated with arguments x1 : a1,x2 : a2, ...,xn : on), condition c. action a (a
refers to a service/function and is associated with parameters y1, y2, ym, if event e directly

refers to service a, then the y's and x’s are identical too). together constitute a state transition
from state 3 of an object with distinguished sort (b and services 2, if p is the precondition for
service/function a, create the following expression
process 8 [E] (O: (b): noexit :=
e ?xl :al, ?x2:a2, ..., ?xn :an;
([C and pl —) <a(y12 y‘Z: yni)>)
endproc

 

The postcondition, expressed in an ensures clause, of a service/function states
the conditions that must be satisﬁed at the termination of the service/ function. If
it is formalized in the process algebras fashion similar to the formalization rule for
preconditions in FFR—6, then a guarding expression is introduced. The guarding
condition serves to check whether the postcondition is satisﬁed before leaving the
state of the corresponding object. Speciﬁcally, for FFR-6, the guarding expression
will be given after <a(y1, yg, ..., ym)> in order to ensure that the postcondition is

satisﬁed.

 

FFR—7 The postcondition that is associated with the action of a state transition is formalized in terms
of a guarded expression in LOTOS process algebras.
Suppose event e (associated with arguments x1 : a1,x2 : a2, ...,xn : an), condition c, action
a action a (associated with parameters y1, y2, ym, if event e directly refers to service a,
then the y's and x's are identical too), together constitute a state transition from state 3 of an
object with distinguished sort d and services 2, if p and q are the pre- and postconditions for
service/function a, create the following expression

process 8 [21(0: 45): noexit :=

e ?x1:a1, ?x2:a2, ..., ?xn2an;
([C and pi -) <a(yl! y?! '°° ym)>);
([q]——>...)

endproc

131

There is no doubt that FFR—7 is a legitimate formalization rule for postcondi-
tions. However, unless we presume that the invoked service / function performs certain
actions that either modify the attributes of an object or returns a value, then it is
impossible to check whether the postcondition is satisﬁed. It is only during the later
stages of software development, when individual services/functions already have a
speciﬁc implementation, that we can make such a presumption. During the early
stages of design, when services/functions are not implemented, the postcondition
cannot be analyzed and checked, but, instead, can only serve as a speciﬁcation. In
order to facilitate the validation, veriﬁcation, and analysis of design, we further inves-
tigated the use of postconditions and developed two alternative formalization rules.
Given these two rules, the derived formal speciﬁcation of an object is amenable to
symbolic execution for simulation purposes.

A postcondition contains assertions about constraints/ requirements in three ba-
sic format categories. The ﬁrst category includes the assertions of the form:
“result := <expression>.” This form of postcondition is usually associated with
services/ functions that return values. The expression on the right hand side of key—
word result speciﬁes the value to be returned in terms of the Operators of the alge-
braic speciﬁcation for the corresponding object. Since the exact return value of a
service/function is not available during the early stages of design, in order to facil-
itate design analysis and simulation, the abstract, declarative return value given in

the assertion, result = <expression>, is used for symbolic execution.

132

 

FFR—S The postcondition that is associated with the action of a state transition, in the form Of result =
(expression), is formalized in terms of a value declaration in LOTOS process algebras.
Suppose event 6 (associated with arguments x1 : a1,x2 : a2, ...,xn : an), condition c, action a
(associated with parameters y1, y2, ym, if event e directly refers to service a, then the y's
and x's are identical too), together constitute a state transition from state 3 of an Object with
distinguished sort 45 and services 2, if q is an expression, in the form Of result = op (zl, z2, ..., 2;)
(Op is an operator defined in the corresponding algebraic specifications, 2,- (1 5 i g l) is a subset
of y,- (1 5 i g m) and attributes) within the postcondition for service/function a, then create the
following expression

process 8 [E] (o: (b) : noexit :=

e ?xlzal, ?x2za2, ..., ?xnzan;
([c and p] —) e! op(21. 22. 31))
endproc

 

The modiﬁes clause lists the object attributes that may be changed during the
execution of a service/function. As a consequence, the ensures clause that follows
the modiﬁes clause always describes the constraints/requirements on the changes
of the speciﬁed attributes. Among the descriptions of attribute changes, several

(C a ’9 C‘ A ”

assertions have the form: 0 := or o .a : , where 0 represents the

set of attributes, and a represents one attribute. This format deﬁnes the second
category of assertions of postconditions. Similar to the ﬁrst category, the second
category of assertions speciﬁes the value, in terms of operators of the corresponding
algebraic speciﬁcations, to be assigned to the corresponding attributes. Since the
service/function at such an early phase of design does not change the attributes
speciﬁed in the modiﬁes clause, we use the abstract value given in the second category
of assertions to facilitate the validation and veriﬁcation of design. For instance, the
speciﬁcation in Figure 6.17 gives the pre— and postconditions for services Insert and
Retrieve. During the design phase, no implementation of the service is available

for Retrieve. However, its postcondition result = retrieve (disk, k) precisely

133
speciﬁes the returned value in terms of algebras. Therefore, retrieve (disk, k)
can be used symbolically to simulate the system behavior or to validate the design

during design phase.

 

FFR—9 The postcondition that is associated with the action of a state transition can be formalized in
terms of a local variable declaration in LOTOS process algebras.
Suppose event e (associated with arguments x1 : a1,x2 : a2,...,x,, : an), condition c, ac-
tion a(associated with parameters y1, y2, ym, if event e directly refers to service a. then
the y’s and x's are identical too), together constitute a state transition from state 3 of an
object with distinguished sort rt and services 2, if Q is a set of expression, in the form of
o".a, = op,- (z,,,z,~,,...,z,-,)(1 S i g k) (op,- is an operator defined in the corresponding al-
gebraic specifications, 2,). (l g j S l) is a subset of y,- (1 S i S m) and attributes) within the
postcondition for service/function a, create the following expression

process 8 [E](o: d): noexit :=
e ?x1:a1, ?x2za2, ..., ?xn :an;

([c and p] —>
(let POST.a1 := op1(zl,,zl,,... 21,),
POST.a2 := op2(22,.222.--- Z21):
POST.a;c := opk(zk,,zk,,... 2;“) in
)
)
endproc

 

An assertion in a postcondition that does not belong to either of the ﬁrst two
categories falls into the third category that describes the constraints/requirements
to a service/functions indirectly. By indirectly, we mean that the speciﬁcations of a
postcondition only assert the conditions that shall be satisﬁed after the execution of
the service rather than giving a symbolic value that can be rewritten by the algebraic
constructors. Thus we are not able to use the abstract values to represent the return
value of a service or the attributes after modiﬁcation. If a postcondition contains such
an assertion of the third category, the only applicable formalization rule is FFR—7.
Since the services/functions, at such a high level of design, do not cause any actual

change to object attributes nor return a speciﬁc value, no mechanism exists to verify if

134
a postcondition of the third category can be satisﬁed. Therefore, symbolic execution
and analysis are not possible. However, in most cases, the postconditions can be
covered by the assertions of the ﬁrst two categories, thus enabling us to perform

formal analysis.

6.4.3 Formalization of the service reﬁnement functional
model

This subsectiOn discusses the formalization of the service reﬁnement functional model

(SRFM).

Formalization of reﬁned objects.

The purpose of the SRFM is to reﬁne the services of aggregation objects in terms
of services provided by aggregate objects. Therefore, the formalization of SRFMS
leads to the reﬁnement of the existing algebraic speciﬁcations that correspond to
aggregation objects. Since the reﬁnement is based upon existing models and their
corresponding algebraic speciﬁcations, the reﬁned algebraic speciﬁcations should in-

clude their speciﬁcations before the reﬁnement for reference use.

135

 

FFR—lO The refinement of object 0, results in a refined algebraic specification, S-REF, that includes
additional operators and axioms.
For every object 0 that is further refined into a set of aggregate Objects 01, O2, 0,,, create
the following expression
type 0_RF.F is

endtype

FFR—ll In a refined algebraic specification for an object (or system), the algebraic specifications for
the aggregate objects are included in order to make use of the services defined in the aggregate
Objects.

For every object 0 that is further refined into a set of aggregate objects 01, 02, 0", create
the following expression
type 0-REF is 01, 02, ..., 0,,

endtype

 

For instance, given the SRFMS for the services of Disk Manager, the algebraic spec-

iﬁcation Disk-Manager will be reﬁned to form a new speciﬁcation, Disk-Manager-REF.

 

type Disk_Manager_REF is Storage, Compressor, Disk_Manager

endtype

Figure 6.19: A part of the reﬁned ACT ONE speciﬁcation for Disk Manager

 

Formalization of internal functions and data reﬁnement.

Similar to the formalization of services in OF Ms, new internal functions introduced
in the SRFMS are declared along with the services as annotations. Since the internal
functions are not accessible to external objects, they are not formalized in the gate

list of the corresponding speciﬁcation.

136

 

FFR—12 Each internal function in an SRFM is declared along with services as annotations and Operators
of algebraic specification.
For all the internal functions, F,(1 _<_ i g n), with inputs, 1,,(1 g ij 3 [1,] (I,- represents the
permutation of the input data), and outputs, 0,, in the OFM of object OBJECT, create the
following expression
speciﬁcation OBJECT [< service list>]] :noexit :=

(‘1‘ F1 2 2.112111, 2.12 2112, ..., illlil 211”” -> 01 *)
(* F2 : 221 :I2,, 222 :122, ..., 22”“ :I2,,2, -> 02 *)
(* Fn : i1" :11", i1" :11”, ..., inunl :InuﬂI -> On *)

opns
F1 3 [1,, I12, ..., 11”” '> 01
F2 2 I21, I22, ..., Izllzl -> 02
F" I I1", 11", ..., Inllnl '> 0n

endtype endspec

 

According to this rule, function F un3 introduced in Figure 6.6 is formalized as
FUTL3 : out54 : Out64 —> Out33 in the corresponding reﬁned algebraic speciﬁcation. In
addition to the function declaration, pre- and postconditions shall also be speciﬁed
for the internal functions.

The splitting/aggregation data ﬂow reﬁnements described in SRFMs (denoted
by solid box) map an abstract sort into a set of sorts, which is similar to a record or
struct type deﬁnition in commonly used programming languages. The formalization is
achieved by redeﬁning the abstract sort in terms of a set of LOTOS sorts, operations,
and equations. However, there is a signiﬁcant difference between the splitting and
aggregation data ﬂow reﬁnements. The composition of aggregate data ﬂows form a
data item that will be supplied to a process to perform a data transaction. Therefore,

all the inﬂows, and only those inﬂows, shall constitute the data components for the

137
refined data sort. This feature of data aggregation introduces a constraint to the
functional models: if there are multiple data aggregations, given in functional models,
for the same outﬂow data item, then their inﬂows must be identical to each other.
The constraint requires that there only be one reﬁnement for every data item. Unlike
data aggregation, when a data is split into a set of outﬂows, it does not necessarily
imply that the outﬂow data items cover all data components of the split data type.
It only speciﬁes that the split data item shall, at least, contain the data items to
which the outﬂow data items correspond. Thus a speciﬁc data splitting cannot itself
be formalized as a record data type. Instead the union of data splitting for the same

split data item shall be formalized in terms of record data items.

138

 

FER-13 If a data flow D is aggregated into a set of data flows, D1, D2, D", then D is rede-
fined/refined as a set of Operations that constitute D from D1, D2, D,, and single out D1,
D2, ..., Dn from D.

For every data flow D that is aggregated into a set of data flows, D1, D2, Dn, create the
following expression
sorts
D-l, D_2, ..., D_n
opns
D :D_1, D.2, ..., D_n ——> D
get_d-1 : D —-> DJ
get_d_2 : D —-> DJ

get_d_n : D —> D_n

eqns
forall d_1: D_1, d-2: D_2, ..., d_n: D_n
ofsort D_l
get_d_1(D(d_1, (1.2, ..., d_n)) = d_1
ofsort D.2

get_d_2(D(d_1, d_2, d-n)) = v-2

ofsort D_n
get_d_n(D(d_1, d_2, ..., d_n))

II
P“
3

FFR-14 All the data splittings for a data flow D together with D is redefined / refined as a record data

type.
For data flow D and all the sets of data flows, 5'1, S2, Sn, into which D is split, if data items
D1, D2, Dm cover all the data items in S,- (1 g i g n) and do not contain redundant data
items, then create the following expression
sorts
DJ, 0.2, ..., D_n
opns

D:D-1,D_2,...,D_n ——> D
get_d_1 : D —+ DJ
get_d_2 : D —-+ DJ

get_d.n : D —> D_n
eqns

forall d-1: D_1, d_2: D_2, ..., d.n: D_n
ofsort D_1

get_d-l(D(d-l, d-2, ..., d_n)) = d_1
ofsort D_2

get_d_2(D(d_1, d_2, ..., d_n)) = (1.2
ofsort D_n

get_d_n(D(d_1, d.2, ..., d_n)) = d_n

 

139
Given formalization rules FFR—13 and FFR—14, the SRFM in Figure 6.7 will
result in a redeﬁnition of Outl and In1 (assuming that there is only one data splitting

for In1). The diagram is formalized in Figure 6.20.

 

sorts
Outl, 0ut14, 0ut18, In1, In11, In12
opns
Outl : 0ut14, 0ut18 -) Outl
get_out14 : 0ut1 -> 0ut14
get_out18 : Outl -> 0ut18
In1 : In11, In12 -) In1
get_in11 : In1 —> In11
get_in12 : In1 -> In12
eqns
forall outl: 0ut1, out14: 0ut14, out18: 0ut18, in1: In1, in11: In11, in12: In12
ofsort 0ut14

get_out14(0ut1(out14,out18)) = out14;
ofsort 0ut18

get_out18(0ut1(out14,out18)) = out18;
ofsort In11

get_In11(In1(in11, in12)) = in11;
ofsort In12

get_In12(In1(in11, in12)) = in12;

Figure 6.20: The formalization of the reﬁned data items shown in Figure 6.7

 

The axiom presented in Figure 6.20 states that: (1) S1 is fully implemented in
terms of 03.32 and 09.33; (2) the input of 51 is split into input for 03.S2 and 09.53;
(3) the output of SI comprises the outputs from O3.S2 and Og.S3.

The duplicator/ selector data ﬂow reﬁnement requires or implies that the involved
data types are mutually convertible. So that for any pair of mutually convertible
data types, D1 and D2, two operators, D1_2_D2 and D2_2.Dl, and corresponding

axioms are introduced to describe the mutual convertibility. The difference between

140
a duplicator and a selector lies in that the former can have multiple effective outﬂows
while the latter can have only one effective inﬂow at a given time. The mutual
exclusiveness between the inﬂows of a data selector has direct impact on its semantics
and the formalization. This issue will be further addressed in the discussion of the

formalization of service composition.

 

FFR-15 If a data flow D is duplicated to or selected from a set of data flows, D1, D2, Dn, Operators
D.2_Dl, Dl_2_D, D.2_D2. D2.2.D, D-2_D,,, and Dn_2_D, in the formats of
opns
D_2_D1: D —) D1
D_2_D2: D —) D2

D.2_D,,: D —> D,,

are introduced in the refined algebraic specification. In addition, the following axioms are used to
specify the mutual convertibility:

eqns
forall x: D
ofsort D
D1.2_D (D_2_Dl (x)) = x;
022.0 (13.2.02 (10) = x;

Dn_2_D (D_2_D,, (x)) = x;

 

Given formalization rule FFR-15, the SRF M in Figure 6.8 will introduce
Operators In1_2_In11, In11_2_In1, In1_2_In12, In12_2_In1, 0ut1_2_0ut14,
0ut14_2_0ut1, 0ut1_2_0ut18, and 0ut18_2_0ut1. The diagram is formalized in

Figure 6.21.

Formalization of service composition.

The SRFM only presents which aggregate object services and internal functions are
composed to implement a higher-level object service and illustrates how information

ﬂows among services and functions. The control information and the order in which

141

 

opns
In1_2-In11: In1 -> In11
In11_2_In1: In11 -) In1
In1_2-In12: In1 -) In12
In12_2_In1: In12 -> In1
0ut1_2-0ut14: 0ut1 -> 0ut14
0ut14_2_0ut1: 0ut14 -> Outl
0ut1_2-0ut18: 0ut1 -) 0ut18
0ut18_2_0ut1: 0ut18 -> 0ut1
eqns
forall x: In1, y: 0ut1
ofsort In1
In11_2-In1(In1_2-In11(x))
In12_2_In1(In1_2_In12(x))
ofsort 0ut1
0ut14_2_0ut1(0ut1.2_0ut14(y)) = y;
0ut18.2_0ut1(0ut1_2_0ut18(y)) y;

Xi
Xi

Figure 6.21: The formalization of the data duplicator and selector shown in Figure 6.8

 

the services and functions are activated are beyond the sc0pe of functional models;
they are described in dynamic models. However, the functional model does capture
the data dependency relationships between the services provided by aggregate objects.
Since each service has at most one output data ﬂow and circular data ﬂow is not
allowed, each SRFM forms an acyclic directed graph where services are depicted
as vertices and data ﬂows as directed edges. Therefore, algebraic axioms can be
introduced to describe the constraints on the hierarchical acyclic directed structure
in which the aggregate object services are related with each other. Because the
services are speciﬁed in terms of pre- and postconditions, we pursue the use of the
pre- and postconditions as a means to impose design constraints.

The pre— and postconditions of two services, suppose 31 and 32, that share a

common data ﬂow are related. If the output data ﬂow of 31 serves as an input data

142
ﬂow of 32, a basic constraint is that the postcondition of 31 does not imply false of
the precondition of 32, in other words, they are not contradictory. Thus we impose a
veriﬁcation obligation upon SRFMS to check that the pre- and postconditions of two

adjacent services do not form a contradiction.

 

FFR—16 The post- and preconditions of two adjacent services in a SRFM shall not form a contradiction.
For any two services 31 and 32 in a SRFM, if (1) the output of 31 serves as an input of 32, (2)
p,, and q,, are the pre- and post conditions for 31, and (3) p,2 is the precondition for s2, create
and prove the following expression
(p,,,=>((q,,1 and p8,) eq false)) = false

 

Figure 6.22 and 6.23 show the speciﬁcations for Storage and Compressor with pre-
and postconditions for the corresponding services. Given the SRFM in Figure 6.13,
according to rule FFR—16, the postcondition of service Storage.Retrieve and
the precondition of service Compressor.Decompress can be analyzed to check the
consistency of function reﬁnement. Since the result of Storage .Retrieve will be fed
into Compressor.Decompress, given the pre- and postconditions of the two services,
the constraint is
(s neq empty =>(resu1t=retrieve(s,k) and result eq undef_d) eq false)=false.

There are basically two approaches to perform the consistency checking. One
is to conduct a manual proof; the other is to use proof tools. Unfortunately, there
is currently no sophisticated proof tool for the algebraic speciﬁcations of LOTOS.
Since ACT ONE is a subset of the LSL of Larch, we translated the LOTOS algebraic
speciﬁcations into LSL speciﬁcations and used Larch Prover (LP) [19] to check the
consistency of pre-and postconditions. The corresponding LSL speciﬁcations are given

in Appendix F. Figure 6.24 gives the LSL speciﬁcation for the reﬁned Disk Manager.

143

 

speciﬁcation Storage [Insert, Retrieve] (s: S) :noexit :2
(* Insert : d: Data, k: Key -) Void *)
(It requires d eq undef_Data = false and k eq undef_Key = false *)
(... modiﬁes s 4:)
(* ensures 3’ eq insert(s‘, d, k) = true *)
(* Retrieve : k: Key -) d: Data *)
(... requires 3 eq empty = false ...)
(... ensures result = retrieve (s, k) *)
type Storage is Disk_Manager
sorts
S, Data, Key
opns
empty : -> 3
insert : S, Data, Key -) S
retrieve : S, Key -> Data
eqns
forall s: S, data: Data, k1, k2: Key
ofsort Data
retrieve (empty, key) = undef_data;
retrieve (insert(s, data, k1), k2) = if k1=k2 then data
else retrieve(s, k2)
endtype
endspec

Figure 6.22: The Full LOTOS speciﬁcation for Storage with pre- and postconditions
for services

 

The proof obligation is simpliﬁed to " (s=empty)=>" (retrieve(s ,n) =undef_d) and
given in the implies clause (the logic simpliﬁcation can also be assisted by tools, such
as PVS [81]). Figure 6.25 shows the result of the proof by using LP.

By using the induction proof method provided by LP, we have reached a point
that shows Current subgoal: false (in Figure 6.25) that means there are cases
that yield false for the constraint. The proof detects an inconsistency between the
postcondition of Storage.Retrieve and the precondition of Compressor.Decompress,
thus requiring us to perform a further inspection into the problem. This problemm

is further discussed in Chapter 8 in the context of the overall development process.

144

 

speciﬁcation Compressor [Compress, Decompress] (c: C) :noexit :=
(* Compress : d: Data —) Data *)
(It requires :1 eq undef_Data 'it)
(It ensures result = compress(d) and size(result) 1e size(d) *)
(* Decompress : d: Data -> Data *)
(* requires d eq undef_Data 10:)
(... ensures result = decompress(d) and size(result) ge size(d) *)
type Storage is Disk_Manager, NaturalNumber
sorts
C (* Distinguished sort *)
opns
compress : Data -> Data
decompress : Data -> Data
size : Data -> Nat
eqns
forall data: Data
ofsort Bool
size(data) ge size(compress(data)) = true;
size(data) 1e size(decompress(data)) = true
endtype
endspec

Figure 6.23: The Full LOTOS speciﬁcation for Compressor with pre— and postcondi-
tions for services

 

 

Disk_ref (D, K): trait
includes Storage(D,K) , Compressor(D)
implies
V s: S, n: N
~(s=empty) => ~(retrieve(s,n) = undef_d);

Figure 6.24: The LSL speciﬁcation for the reﬁned Disk Manager

 

145

 

LP2: display proof

Conjecture Disk_refTestTheorem.1: ~(s = empty) => ~(retrieve(s, n) = undef_d)

Attempting a proof by depth 2 structural induction on ‘8’
Level 2 subgoal 2 (basis step) for proof by induction on s:

~(insert(empty, n1, n2) = empty)

=> ”(retrieve(insert(empty, n1, n2), n) = undef_d)

Current subgoal: ~((if n = n2 then n1 else undef_d) = undef_d)

Attempting a proof by depth 2 structural induction on ‘n’
Level 3 subgoal 1 (basis step) for proof by induction on n:

~((if O = n2 then n1 else undef_d) = undef_d)

Attempting a proof by depth 2 structural induction on ‘nl’
Level 4 subgoal 1 (basis step) for proof by induction on n1:

~((if 0 = n2 then 0 else undef_d) = undef_d)

Attempting a proof by depth 2 structural induction on ‘n2’
Level 5 subgoal 2 (basis step) for proof by induction on n2:

~((if O = succ(0) then 0 else undef_d) = undef_d)

Current subgoal: false

Attempting a proof by normalization

LP3:

Figure 6.25: The proof of the example constraint using LP

 

6.5 Integration with Object and Dynamic Models

The functional model is integrated with the object and dynamic models in terms of

the underlying formalization rules. The integration is three-fold. First, both OFMs

and SRFMs are derived in the context of object models. This approach to modeling

provides a degree of integration between the two models.

Second, the integration is achieved by sharing common language constructs among

speciﬁcations derived from the object, functional, and dynamic models. The integra-

tion includes:

0 Operators deﬁned in algebraic speciﬁcations are used to deﬁne pre- and post-
conditions for services.

0 Services deﬁned by functional models serve as actions and activities in state
diagrams.

o Alge
repla
enab

O The l

and 2

0 Servi
gate

0 The
C0115]

0 The
tiate
Third.

111% t0 the

6.6 5

In this Ch
integrated
formal]y a
f0r derivir
Dre- and I
for SQFVir-e
high‘lm'gl

and \‘alida

TOr pre‘ an

cont];Cts t

l;

146

o Algebraic speciﬁcations used to describe the postconditions of a service can
replace the service reference in the process algebraic speciﬁcation in order to
enable symbolic simulations.

0 The data types used in process algebras are deﬁned in the functional models
and are formalized in terms of algebraic speciﬁcations.

0 Services (externally accessible operators) deﬁned in functional models serve as
gate lists for process algebras.

o The pre— and postconditions speciﬁed during functional modeling impose extra
constraints to the corresponding actions in the dynamic models.

0 The postconditions speciﬁed during functional modeling can be used to instan-
tiate the corresponding actions in the dynamic models.

Third, the integration is achieved by composing the SRFMs hierarchically accord-

ing to the system structure speciﬁed in the object model.

6.6 Summary

In this chapter, we showed how the functional model is modiﬁed, formalized, and
integrated into object-oriented design. Formalization rules are also introduced to
formally and rigorously specify both the OFMs and SRFMS. In addition, guidelines
for deriving algebraic speciﬁcations are given. Based upon algebraic speciﬁcations,
pre- and postconditions are introduced to describe the requirements and constraints
for services. The pre- and postconditions of services enable symbolic execution of the
high-level design model thus providing a means to perform simulation, veriﬁcation,
and validation during the early phases of software development. Proof obligations
for pre- and postconditions of adjacent services in SRFMs serve as a means to detect

conﬂicts that may be introduced into design during reﬁnement.

 

Cha] i

 

 

Mod

We have,
dynamic ;
eXpliCit 1};
dynamic

ization,

7.1 1

In gEHGra
formal Sp
StruCtS a,
primitives
our forma

“111308ng

Chapter 7

Model Integration and Analysis

We have, in fact, implicitly addressed the integration of the object, functional, and
dynamic models through the discussion of their formalization rules. This chapter
explicitly summarizes the integration of the three models and discusses the static and
dynamic analysis of inter-model and intra-model integration enabled by the formal-

ization.

7 .1 Integration of the Three Models of OMT

In general, the use of LOTOS does not automatically lead to an integration of the
formal speciﬁcations of the object, functional, and dynamic models, though its con-
structs allow algebraic speciﬁcations and process algebras to share common language
primitives thus providing a possibility to integrate the two types of speciﬁcations. In
our formalization, the integration of the three models is achieved through explicitly

imposing certain relationship upon the three models as well as the constructs of al-

147

148
gebraic speciﬁcations, predicate speciﬁcations, and process algebras. The integration
is three-fold.

First, the functional and dynamic models are derived in the context of object
models. By associating a functional model and a dynamic model to every individual
object, we resolved the conﬂicts between the models with respect to their respec-
tive development phiIOSOphies. The functional model and dynamic model describe
the services and dynamic behavior of their corresponding object, respectively. Thus
the modeling technique provides a degree of integration between the three models.
A formal speciﬁcation for a speciﬁc object shall be derived from three models: ob—
ject model, object functional model, and dynamic model. The three complementary
models of an object describe different aspects of the object and forms a single formal
speciﬁcation.

Figure 7.1 shows an outline of a speciﬁcation derived from object, functional, and
dynamic models. The words in bold fonts are keywords; the words in “< >” pairs are
the components of formal speciﬁcations.

The components of a formal speciﬁcation includes:

0 Class name: identiﬁes a class of objects that share the same interfaces, attribute
types, and behavior.

0 Services: services provided/needed by a class of objects.

O Distinguished sort: a sort that consist of sorts of all the attributes to a class of
objects.

0 Services specification: speciﬁes the signatures and pre- and postconditions of the
services ( the pre- and postconditions shall be supplied by speciﬁers).

o Algebraic specification: speciﬁes the properties that an object may have in terms
of algebraic speciﬁcations ( this part of speciﬁcations shall be supplied by speci-

ﬁers).

149

 

speciﬁcation (class name) [<services>] (<distinguished sort>) noexit:=

(... .......................... ...)
(* <services specifications) *)
(* .......................... ...)
typedef

endtype
(starting state) [<services>] (<distinguished sort>)
process <state name) [<services>] (<distinguished sort>) noexit:=

endproc
endspec

Figure 7.1: The format of formal speciﬁcations

 

0 Behavior specification: speciﬁes the patterns that an object interacts with other
objects.

0 State name: identiﬁes different states in which an object may be during its life
cycle.

0 Starting state: the state that an object enters after being instantiated.

A speciﬁcation depicts four aspects of a class: identity, interface, functionality, and
behavior. Class name and the distinguished sort together contribute to the identity of
classes and objects. Services describe the interface of a class. Services specifications
delineate the functionalities that the services provide. Behavior specifications, state
names, and the starting state capture the behavior of a class. With the exception
of a part of the algebraic speciﬁcations that specify the properties of objects and
the pre- and postconditions that describe services provided by object classes, all
other components of the formal speciﬁcations can be automatically generated from

diagrammatic models according to our formalization rules.

150

Second, the integration is achieved by sharing common language constructs among

speciﬁcations derived from the object, functional, and dynamic models. The integra-

tion includes:

The distinguished sort in algebraic speciﬁcations serves as state process param-
eters in process algebras.

Operators deﬁned in algebraic speciﬁcations are used to deﬁne pre- and post—
conditions for services.

Services deﬁned by functional models serve as actions and activities in state
diagrams.

Operators deﬁned in algebraic speciﬁcations can be used to substitute services
referenced in process algebras.

The data types used in process algebras are deﬁned in algebraic speciﬁcations.

Services (externally accessible operators) deﬁned in functional models serve as
gate lists for process algebras.

The parameters associated with operators serve as attributes associated with
events.

The pre- and postconditions speciﬁed during functional modeling impose extra
constraints to the corresponding actions in the dynamic models.

The postconditions speciﬁed during functional modeling can be used to instan-
tiate the corresponding actions in the dynamic models.

Third, the integration is achieved by composing (1) the dynamic models of concur-

rent objects hierarchically according to the system structure speciﬁed in the object

model, and (2) the SRFMs of an object in terms of the services provided by the

aggregate objects.

151

7 .2 The Correctness, Consistency, and Complete-

ness of the Formalization Rules

Since both the formalization and integration of the models greatly rely on the formal-
ization rules, it is worthwhile to discuss the correctness, consistency, and completeness
of our proposed formalization rules. The informal graphical notations do not have
precise semantics. The purpose of formalization rules are two-fold. First, the rules
introduce precise meaning to the graphical notations. Second, the rules provide a

graphical front-end for the constructs of formal speciﬁcations.

Correctness. Although the informal graphical notations do not have precise seman-
tics, they still have underlying general semantics. The formalization rules attempt to
give precise meanings to the graphical notations by introducing formal speciﬁcations
to describe the graphical models. A formalization rule can be considered correct if
it imposes the right semantics to the graphical notations. Because, there is no spe-
ciﬁc, formal deﬁnition for the semantics of graphical notations, we have no means to
formally prove the correctness of the formalization rules. Given this situation, the
correctness of the formalization rules is pursued in the context of general reasoning,
which is justiﬁed in the chapters of formalization, the model construction and use

presented by Rumbaugh [3], and empirical experience through the case studies.

Consistency. If the formalization rules do not conﬂict with each other, they can
be considered consistent. From the perspective of graphical notations, because each

graphical notation is formalized in terms of one language construct of formal spec-

152
iﬁcations, the formalization rules are consistent from the perspective of graphical
notations. From the perspective of formal languages, the consistency of formalization
rules can be discussed under two circumstances. First, for the formalization rules
whose corresponding constructs of formal speciﬁcation language are not related with
each other in the formal speciﬁcations, consistency is automatically inherited from the
perspective of formal speciﬁcations. Second, for the formalization rules whose corre-
sponding constructs of formal speciﬁcation language are related with each other, be-
cause the relationship is maintained through language semantics developed by Larch
and LOTOS, the consistency of the formalization rules can be reduced to the consis-
tency between different types of speciﬁcations in Larch and LOTOS. Neither Larch
nor LOTOS has addressed this consistency issue. However, the large number of appli-
cations of Larch and LOTOS have not reported any inconsistency between different

types of formal speciﬁcations thus far.

Completeness. Since the rules serve as a bridge between informal graphical no-
tations and language constructs of formal languages, the completeness of the rules
can be discussed from two perspectives. From the perspective of formal languages,
the rules can be considered complete if every part of a formal speciﬁcation has corre-
sponding graphical notations from which formal speciﬁcations can be automatically
generated. From the perspective of graphical notations, the rules can be considered
complete if every graphical notation can be described in terms of formal speciﬁcations.

Because the axioms of algebraic Speciﬁcations cannot be easily expressed by graphical

153
notations, our formalization rules only preserve the property of completeness from the

perspective of graphical notations.

7 .3 Speciﬁcation Analysis Techniques

The integration and formalization of the three models that describe a system from
complementary aspects enable designers to perform analysis tasks by using the derived
formal speciﬁcations.

LOTOS is a formal abstract description language that can be used to precisely
describe a system, abstracting away realization details. This is particularly useful
in the design and analysis of the behaviors of systems that contain communicating
objects, where the interactions often have complex interdependencies. LOTOS is
based upon several mathematical models that make it possible to check the validity
of the speciﬁcation, ensuring the correctness of the design. Because our formalization
and integration rules can serve to derive a single, integrated formal speciﬁcation for an
object from its corresponding object, functional, and dynamic models, both static and
dynamic analysis tasks can be performed for speciﬁcation analysis by using available
LOTOS tools. Currently, a rich set of LOTOS tools [82] are available for analyzing
LOTOS speciﬁcations. Among the available tools, TOPO [64, 83], LOLA [84, 85, 86,

87], SMILE [88, 89], and XELUDO [90] for Full LOTOS are promising tools.

0 TOPO is a toolset that supports product realization from LOTOS speciﬁca-
tions. TOPO includes tools to perform static semantics analysis, speciﬁcation
investigation (cross references, data type dependencies, etc), and it is able to
generate C or Ada code that may be compiled into a prototype.

154

o LOLA is a transformational and state exploration tool with applications to
testing, simulation, and debugging. The transformation functionality allows the
generation of the equivalent Extended Finite State Machines (EFSM) [91]1 from
given LOTOS speciﬁcations. The execution functionality enables designers to
simulate LOTOS speciﬁcations in a stepwise fashion. The testing functionality
calculates the dynamic response of a system speciﬁcation to a test according to
the testing equivalence prOperly.

o SMILE is a symbolic evaluation tool for LOTOS. It contains functions for the
analysis of the abstract data type part of the speciﬁcation, execution and de-
bugging of the LOT OS speciﬁcation or parts thereof, transformation of (parts
of ) the speciﬁcation into strong equivalent EFSMs.

o XELUDO is a toolset that support speciﬁcation transformation and execution.
The execution functionality allows step-by-step execution of a speciﬁcation. The
symbolic expansion transformation functionality generates equivalent symbolic
trees of a speciﬁcation.

TOPO and LOLA, which cover most of the critical functionalities for LOTOS
speciﬁcation analysis, are two intensively used tools in this research. Our discussion of

speciﬁcation analysis will focus on the functionalities provided by TOPO and LOLA.

7.3.1 Static analysis

A static semantic checker for full LOTOS can check the consistency between the
algebraic and behavior speciﬁcations, such as operator references, parameter types,
and so on. Therefore, given a formal speciﬁcation that describe a set of corresponding
models, inconsistencies among models that are introduced during the the construction
of a diagram will be detected by such a semantics checker. LSA (LOTOS semantics
analyzer) included in TOPO is an example of such a semantics checker. Figure 5.6

and 5.7 of Chapter 5 show an instance of static analysis performed by LSA.

 

1EFSMs are ﬁnite state machines that have output functions associated with transitions or states.

155

The underlying formal semantics Of LOTOS is a Labeled Transition System
(LTS) [92, 93]. Based upon the formal semantics described by the LTS, equiva-
lence between behaviors Of LOTOS speciﬁcations is also deﬁned [92]. The expansion
transformations provided by LOLA produces a compressed version Of Extended Finite
State Machines (EF SM) from a given LOTOS behavior speciﬁcation. The behavior
of the generated EFSM is equivalent to the original LOTOS Speciﬁcation. The effect
Of an expansion is the removal Of the most complex LOTOS Operations (e.g., paral-
lel Operators) from the speciﬁcation, producing an equivalent speciﬁcation in terms
Of action preﬁx, behavior choice, guards, and choice, etc. This transformation can
be used for state exploration, deadlock detection, deriving efﬁcient implementations,
etc. Because the dynamic models Of the individual objects can be synchronized by
parallel Operators, we can use the expansion transformation tO check if the behavior
Of the synchronized Objects can be expressed in terms Of an equivalent EFSM without
parallel Operators. This transformation can be considered as a static analysis Of state
exploration. A deadlock detected by the transformation suggests that the behavior

Of the communicating Objects has a synchronization conﬂict.

7.3.2 Dynamic analysis

Although a static expansion transformation can exhaustively explore all the possible
execution paths for a given LOTOS speciﬁcation, the variables in the given LOTOS
speciﬁcation are treated symbolically during the static analysis. Therefore, potential

problems and conﬂicts caused by variable instantiation cannot be detected by static

156

analysis. By running a test (a formal speciﬁcation Of desired behavior) in parallel
with the target speciﬁcation, we are able to instantiate the variables in the given
speciﬁcation thus dynamically analyzing its behavior. This type Of dynamic analysis
is based on the deﬁnition Of Testing Equivalence [94] Of LOTOS Speciﬁcations. If
the behaviors exhibited by two LOTOS speciﬁcations cannot be distinguished from
external Observation, then the speciﬁcations are considered to be testing equivalent.
Therefore, if none Of the execution paths of a test running in parallel with the spec-
iﬁcation under test results in a deadlock, then the test and the speciﬁcation under
test can be considered testing equivalent to one another. That is, we can assert that
the speciﬁcation under test satisﬁes (or passes) the test.

LOLA provides functionality that enables designers to analyze the behavior Of a
given Speciﬁcation dynamically in terms Of Testing Equivalence [84]. Tests are passed
by specifying a test process and Obliging it tO synchronize with the behavior under
test. The successful termination Of a test in a given execution consists in reaching a
state where the termination event (usually speciﬁed as success) is Offered. A test does
not terminate in a given execution if it reaches a deadlock situation. The results Of
the test are classiﬁed into three classes: Reject, Must Pass, and May Pass. If all the
execution paths terminate successfully, then the test is a Must Pass. If there is least
one execution that leads to the successful termination, then the test is considered May
Pass. Otherwise, the test is rejected, the speciﬁcation under test will not satisfy/ pass
the test under any means.

We can use this functionality provided by LOLA tO check the behavior Speciﬁ-

cations derived from design models. The ability tO Specify test cases enables us to

157

perform dynamic analysis on the design models. Given this analysis tOOl, test cases
can be Speciﬁed tO check the property Of a given speciﬁcation. The variables in the
speciﬁcation under test can also be instantiated with concrete values to detect com-
munication conﬂicts between interacting Objects. Furthermore, if the speciﬁcations
derived from models Of different levels Of abstraction both pass the same set Of testing
processes, they can be considered testing equivalent tO each other in the context Of the
given set Of testing processes. That is, their design models are considered consistent
in terms Of testing equivalence.

The executable nature Of LOTOS behavior speciﬁcations enables designers tO in-
teractively execute any LOTOS speciﬁcation in a stepwise fashion, assigning values to
the variables deﬁned in the speciﬁcation and examining the response Of the speciﬁca-
tion. We can use this functionality tO simulate the behavior Of design models in order
tO achieve a better understanding Of the design as well as a means to communicate
with customers and team members Of software development. In addition, we can use
the interactive execution to detect defective design models. If either a static or a
dynamic analysis Of the behavior Of a given speciﬁcation leads to a deadlock, we can
recover the paths to deadlocks by investigating the log ﬁles, then run the speciﬁcation
interactively in accordance with the deadlock paths. Such a stepwise execution may

help tO identify the cause Of deadlock.

158

7 .4 Analysis Of Model Integration

The speciﬁcation analysis techniques discussed in the previous section can be used tO

perform analysis Of model integration.

7.4.1 Inter-model analysis

Based on our formalization rules, beginning with the initial stages Of modeling, the
models are no longer considered disjoint. A static semantic checker for full LOTOS,
LSA (LOTOS semantics analyzer), included in TOPO [64, 83], checks the consis-
tency between the algebraic and behavior speciﬁcations, such as Operator references,
parameter type, and so on. For example, an error in the behavior speciﬁcation in
Figures 5.6 and 5.7 was detected by LSA, where the transcript Of the semantic check-
ing with LSA is given in Figure 7.2. Further investigation reveals that the error
was caused by an incorrect Operator reference in the behavior speciﬁcation (derived
from the state diagram), retrieve(s) that should have been retrieve(s, k). Therefore
given a formal deﬁnition for the .model integration, inconsistencies between models
that may be introduced in the construction Of a diagram can be detected when the

corresponding formal speciﬁcations are analyzed.

 

lsa -1 /home/wangyi/Research/Tools/TOPO/stdlib/mod-is
-p com2 com2.lfe

com2.lot:116: lsa: undefined operation: retrieve

*** lsa: errors detected

Figure 7.2: The error in the behavior speciﬁcation Of the Storage detected by LSA

 

159

7.4.2 Intra—model analysis

Model integration is also achieved by composing concurrent Objects hierarchically
according to the system structure that is speciﬁed in the Object model.

The beneﬁts brought by this integration include the ability tO reﬁne both the struc-
ture and the behavior Of a system in a parallel, hierarchical, and systematic fashion.
In addition, a behavior speciﬁcation, Obtained by composing concurrent aggrega-
tion Objects, can be checked against the behavior speciﬁcation Of their corresponding
individual aggregate Objects tO guarantee the consistency between the behavior spec-
iﬁcations during the reﬁnement and development processes. For example, prior tO the
design stage, the Disk Manager may have a simple behavior speciﬁcation with input
and output as the only gates. In order tO validate the behavior speciﬁcation, a set Of
test processes, can be written in LOTOS tO simulate the environmental events. Then
the same set Of test processes can also be used to test the reﬁned and concurrent
behavior speciﬁcation, where the reﬁned speciﬁcation must also satisfy all the test
processes before it can be accepted.

The testing equivalence between two process algebras means that one cannot
detect the difference Of the behavior from outside the processes in terms Of testing.
Currently, we term intra—model consistency as the test equivalence in terms Of the
LOTOS speciﬁcation language. This type Of intra—model consistency checking is
already supported by several tOOls designed for Full LOTOS, such as LOLA [84].

The process “accept-test” in Figure 7.3 was used tO test the behavior Of the Disk

Manager before it was decomposed intO Storage and Compressor. This testing prO-

160
cess can also be used tO test the behavior speciﬁed in Figure 5.10 tO check if it is
also satisﬁed by the modiﬁed speciﬁcation. In process accept_test, three data items
associated with keys 0,1, and 2, respectively are given, then two items Of data with

keys 0 and 2 are requested.

 

process accept_test [input, output, success] : noexit :=
let x:D=Hex(b),y1:K=succ(O),yO:K=O,y2:K=succ(succ(O)) in
input !x !yO;
input !x !yl;
input !x !y2;
output !yO; output ?dx: D;
output !y2; output ?dx: D;
success;
stop
endproc

Figure 7.3: The testing process used tO test the behavior Of Disk Manager

 

Figure 7.4 captures the transcript Of oneerrpand, a testing command in LOLA, that
composes the behavior Of disk manager in parallel with the testing process accept-test
through gates input and output, and executes a random trace Of the composed process.
The success event that appears in the tenth step shows that the test successfully
terminates.

Since the behavior speciﬁcation Of Disk Manager only has a small number Of states,
we can exhaustively explore all the possible executions. Figure 7.5 shows such a test.
(For those cases with a large number Of states, LOTOS has facilities for performing
partial analysis.) There are three types Of termination for the testing analysis: must,
may, and reject. If the test terminates for every execution Of the composed process,
then the result is a must pass. If the test does not terminate for any execution, then

the test is a reject. If the test terminates for at least one execution, then it is a

161

 

101a> oneexpand 10 success accept_test -v
oneexpand 10 accept_test O 1 -v

Composing behaviour and test :

accept_test [input,output,success]
I [input ,output] I
(hide com,dec,ins,ret,delete in
storage [ins,ret,de1ete]
l[ins,ret,de1ete]|
disk_manager_1 [input,output,com,dec,ins,ret,delete]
l[com,dec]l
compression [com,dec]

)
1 input ! hex(b) of d ! O of k;
2 input ! hex(b) of d ! succ(O) of k;
3 input ! hex(b) of d ! succ(succ(0)) of k;
4 output ! O of k;
5 i;
6 output ! decompress(data(entry(compress(hex(b)).0)));
7 output ! succ(succ(0)) of k;
8 i;
9 output ! decompress(data(entry(compress(hex(b)),
succ(succ(0)))));

10 success;

Process Test - accept_test
Test result SUCCESSFUL EXECUTION.

Transitions generated = 10

Figure 7 .4: Using accept_test testing process to test the speciﬁed Disk Manager

 

may pass result. The result Of the test in Figure 7.5 is a may pass. In this test, ﬁve
executions were performed, where two Of the executions were successful, and three
were aborted due tO deadlock.

In Figure 7.6, we conducted a step-by-Step interactive simulation Of the original
behavior speciﬁcation composed with the test process tO determine the source Of the
deadlock problems. In the ﬁrst seventeen steps Of the simulation, there were no choices

for the developer to make. At the eighteenth step, three choices were presented tO

162

 

lola> testexpand -1 success accept_test -v -y
testexpand -1 success accept_test -v 0 -y

Rewriting expressions in the specification.
Rewriting done.

Analysing unguarded conditions.

Analysis done.

Composing behaviour and test :

accept_test [input,output,success]
l[input,output]l
(hide com,dec,ins,ret,delete in
storage [ins,ret,delete]
I[ins,ret,delete]l
disk_manager_1 [input,output,com,dec,ins,ret,de1ete]
l[com,dec]l
compression [com,dec]

)
Exploration Tree lTransitsI States
0 - 10 / 7 - 9 / 7 - 10 / 4 - 6 / 4 - 8/ I 18| 17
Analysed states = 17
Generated transitions = 18
Duplicated states = 0
Deadlocks = 3

Process Test - accept_test
Test result MAY PASS.

5 executions analysed:

successes =
stops -
exits
cuts by depth

I
OOOJN

Figure 7.5: An exhaustive test using process accept_test

 

163
the developer. This nondeterminism is introduced due tO gate hiding in the behavior
speciﬁcation Of Disk Manager. Hiding the gates transformed the explicit event into
an internal event 2'. The three internal events appearing in a choice construct resulted
in nondeterminism. The ﬁrst choice may lead tO a success event; the last two choices
will result in deadlock. This interactive simulation analysis answers why deadlocks
were detected in the previous testing. However, since the detected deadlocks were
caused by hidden gates, which were only hidden for the purposes Of testing, it is not

a real problem and will not cause deadlocks when the gates are not hidden.

164

 

lola> step success accept_test

Rewriting expressions in the specification.
Rewriting done.

Analysing unguarded conditions.

Analysis done.

Composing behaviour and test :
accept_test [input,output,success]
l[input,output]|
(hide com,dec,ins,ret,de1ete in
storage [ins,ret,delete]
I[ins,ret,de1ete]l
disk_manager_1 [input,output,com,dec,ins,ret,delete]
l[com,dec]l
compression [com,dec]
)
1. [ 1] input ! hex(b) of d ! O of k;
<n>,Undo,Menu,Refused,Sync,Print,Trace,Exit,?> 1
==> input ! hex(b) of d ! O of k;
........... (omitted)
<n>,Undo,Menu,Refused,Sync,Print,Trace,Exit,?> Trace

1. [ 1] - input ! hex(b) of d l 0 of k;

2. [ 1] - i; (* com ! hex(b) of d *)

3. [ 1] - i;

4. [ 1] - i; (* com ! compress(hex(b)) *)

5. [ 1] - i; (* ins ! compress(hex(b)) ! O of k *)

6. [ 1] - input ! hex(b) of d ! succ(O) of k;

7. [ 1] - i; (* com ! hex(b) of d *)

8. [ 1] - i;

9. [ 1] - i; (* com ! compress(hex(b)) *)

10. [ 1] - i; (* ins ! compress(hex(b)) ! succ(O) of k *)
11. [ 1] - input ! hex(b) of d ! succ(succ(0)) of k;

12. [ 1] - i; (* com ! hex(b) of d *)

13. [ 1] - i;

14. [ 1] - i; (* com ! compress(hex(b)) *)

15. [ 1] - i; (* ins ! compress(hex(b)) ! succ(succ(0)) of k *)
16. [ 1] - output ! O of k;

17. [ 1] - i; (* ret ! 0 of k *)

<n>,Undo,Menu,Refused,Sync,Print,Trace,Exit,?> Menu
18. [ 1] i; (* ret ! data(entry(compress(hex(b)),O)) *)
[ 2] choice d_189:d []
i; (* com ! d_189 *)
[ 3] choice d_191zd []
i; (* dec ! d_191 *)

<n>,Undo,Menu,Refused,Sync,Print,Trace,Exit,?>

Figure 7.6: An interactive simulation Of the process composed for testing

 

Chapter 8

Design Process

If the Objective Of software requirements analysis is tO achieve a comprehensive under-
standing Of software requirements for the target system, then the purpose Of design
is tO apply various techniques and principles for the purpose of deﬁning a device, a
process, or a system in suﬁ‘icient detail to permit its physical realization [95]. Given
requirements Speciﬁcations derived from the requirements analysis stage, software de-
sign is the ﬁrst step in the development process that involves a signiﬁcant amount
Of engineering effort. The primary Objective Of software design is to build mod-
els/Speciﬁcations with sufﬁcient detail such that there is enough information to de-
velop the corresponding source code. A design process typically incorporates intuition
and judgment based on the experience Of engineers in building similar systems, a set
Of principles and / or heuristics that guide the evolution Of the system, a set Of criteria
that enable quality tO be judged, and an iterative process that ultimately leads tO a

ﬁnal design representation [6].

165

166

Several design methods [3, 7, 41, 51, 72, 96] have been proposed during the last
three decades. However, unlike other engineering disciplines, such as mechanical or
electronic engineering, where strict mathematics is heavily involved in the design,
little or no mathematics is explicitly employed by most Of the proposed software de-
sign methods. This can be partly due tO the nature Of concrete mathematics, the
foundation Of computing, which is more abstract and perceived tO be more diﬂicult
tO master and manipulate than general mathematics. We will not go into an in-depth
discussion about concrete mathematics at this point. Nonetheless, mathematics is
the only means that we have, thus far, to achieve precise descriptions Of software
systems. The application Of formal methods tO software engineering attempts tO in-
troduce mathematical rigor as well as systematic methods into software development.
The well-deﬁned notations used by the formal methods are amenable tO automated
processing for numerous analysis tasks [2], including veriﬁcation Of correctness Of re-
sulting systems. Based on investigations by Dart et al. [97] and Brinkkemper [98],
Fraser et al. [5] classiﬁed design methods intO three categories according tO the degree

Of formal methods that are involved.

0 The informal category includes the techniques that do not have complete sets
of rules to constrain the models that can be created. Natural language and un-
structured pictures are typical examples.

 

o The semi formal category includes the techniques that have deﬁned syntax.
Typical instances are diagrammatic techniques with precise rules that specify
conditions under which constructs are allowed and textual and graphical de-
scriptions with limited checking facilities. Example methods include entity-
relationship diagrams and variations on data/control flow diagrams [97, 98].

 

o The formal category includes the techniques that have rigorously deﬁned syn-
tax and semantics. There is an underlying theoretical model against which a

 

167

description expressed in a mathematical notation can be veriﬁed. Speciﬁcation
languages based on predicate logic are typical instances. Example methods in-
clude Petri nets, state machines, Z (Zed), and VDM [97, 98, 99/.

Although formal speciﬁcations are gaining increasing attention as a means to
rigorously document requirements and design information given that the well-deﬁned
notations are amenable tO automated processing for numerous analysis tasks [2], most
Of the popular design methods fall into the semiformal category. This phenomenon
can be partly attributed to the fact that (1) formal methods research has largely
focused on the development Of formal notation and inference rules, and (2) the nota-
tion and the conceptual grammar Of formal speciﬁcation languages require familiarity
with discrete mathematics and symbolic logic that most practicing software engineers,
designers, and implementors do not have [5].

Most design techniques in the semiformal category use various diagrammatic tech-
niques with formal syntax for graphical notations to specify design models. However,
the lack Of formal semantics Of graphical notations deprives designers Of analysis
techniques that can help designers tO detect and eliminate design error during the
early stages Of software development process. In order to take advantages Of both
the intuitive diagrammatic and rigorous formal techniques, the integration Of the two
approaches is clearly motivated.

This chapter prOposes a design method, based upon our formalization and inte-
gration rules in the previous chapters, that provides designers with both intuitive
diagrammatic and formal methods techniques. The remainder Of the chapter is or-

ganized as follows. Section 8.1 gives a brief discussion Of strategies for incorporating

168
formal methods into software development and an overview Of our proposed design
approach. Section 8.2 brieﬂy describes the graphical models, the formal speciﬁcations
used tO describe these models, and the proposed design process. Section 8.3 gives a
detailed presentation about the models and the design process through the model and

design Of an example. Section 8.4 gives the summary Of this chapter.

8.1 Overview of Strategies Proposed Approach

In this section, a brief discussion Of the strategies that incorporate formal speciﬁca-
tions into design is given tO serve as background and provide context for our research.

Then a short description Of the proposed approach is presented.

8.1.1 The integration strategies

Fraser et al. [5] developed a taxonomy for describing and assessing strategies that in-
corporate formal speciﬁcation techniques in software development. Our design process
adheres tO the taxonomy. The framework consists Of two dimensions: formalization
support and formalization process. From the formalization support dimension, the
techniques are divided into computer assisted and unassisted categories according to
whether the formalization process is supported by computer or not. In the formaliza-
tion process dimension (shown in Figure 8.1), there are two approaches: direct and
transitional. The transitional approach can be further divided into sequential and

parallel successive reﬁnement approaches. The deﬁnitions are as follows:

169

Direct: directly moving from informal requirements tO formal speciﬁcations without
the use Of (semiformal) intermediate speciﬁcations.

Transitional: moving from informal requirements tO formal speciﬁcations through
the use Of (semiformal) intermediate representations. There are two further
reﬁnements Of transitional approaches.

Sequential: formal speciﬁcations are derived from a ﬁnal set Of semiformal
models.

Parallel successive reﬁnement: the semiformal speciﬁcations are produced
through successive reﬁnements, where the formal speciﬁcations are derived
from the semiformal speciﬁcations in parallel with the reﬁnement process.

 

Software development process

 

 

 

 

 

Analysis 1 Design 1 Implementatiop
I I
. Direct use of formal speciﬁcations i
I >I Direct approach
I derivation of formal speciﬁcations I
I I
i Semiformal design techniques \ i
I = ;: Sequential approach
I I
1 ﬁnal model : ("mm“)
i Stepwise reﬁnement of semi formal speciﬁcations i
I . . . . Parallel successive
: Denvr g formal specrﬁcauons reﬁnement approach
' v (transitional)
.L -------- 1 ------------------------------------- -,
1 Formal speciﬁcations :

Informal software requriements Formal specification of design

Figure 8.1: The formalization process dimension Of the suggested framework

 

Among the strategies that produce formal speciﬁcations, the computer-assisted,
parallel approach appears tO be the most promising. During the design process Of
this type Of approach, the semiformal methods guide the stepwise reﬁnement. At

each design step, the computer-assisted supporting tools facilitate the generation Of

170
formal speciﬁcations from newly reﬁned semiformal models. The derived, reﬁned
formal speciﬁcations can be veriﬁed against the formal speciﬁcations Of the higher-
level abstraction in order tO eliminate design inconsistencies. Detected problems may
also be traced back t0 the semiformal models. Thus the techniques Of this category
have the potential Of enabling semiformal and formal Speciﬁcations to be developed in
a synergistic fashion during the design reﬁnement process. However, tO date, there do
not appear tO be examples Of a computer-assisted transitional—parallel formalization

strategy [5].

8.1.2 The proposed approach

The Objective Of our investigation is to propose a design process that employs the
computer-assisted transitional-parallel formalization strategy. The Object Modeling
Technique (OMT) [3] is the semiformal design technique upon which our proposed
method is based.

We formalized the three OMT models and integrated their corresponding formal
speciﬁcations in terms Of the underlying semantics in Section 2.4 and Chapters 4,
5, 6, and 7. Based upon the proposed formalization rules, programs can be written
to generate formal speciﬁcations directly from the semiformal models Of OMT. The
Object model is formalized in terms Of algebraic speciﬁcations [27] that provide a
framework Of the formal speciﬁcations; the formalization Of the functional model [75]
introduces formal interface functions and pre- and postconditions for services provided

by the system; the dynamic model is formalized in terms Of process algebras [62, 63]

171
that capture the dynamic behavior Of the Objects. The formal speciﬁcations generated
from different models are complementary, and they, together, form a single formal
speciﬁcation Of an Object. Based on the formalization and integration Of the three
models and the design process Of OMT, we have proposed a stepwise design process

that conducts design activities in an iterative fashion.

8.2 The Proposed Rigorous Design Process

In this section, a formal, rigorous development paradigm for design is proposed. The
design paradigm explicitly addresses the consistency between the formal speciﬁcations
Of two adjacent levels Of abstraction thus enabling stepwise reﬁnement and consistency

checking.

8.2.1 Format of formal Speciﬁcations

Figure 7.1 in Chapter 7 shows an outline Of a speciﬁcation that describes an Object
class, including its identity, interface, functionality, and behavior. The formal spec-
iﬁcations that describe the OMT models serve as the foundation Of our prOposed
design process that employs a parallel transitional approach that incorporates formal

speciﬁcations into design.

8.2.2 Design models

Figure 8.2 shows the graphical models and the order in which they should be devel-

Oped during the development process. In this ﬁgure, a rectangle represents a model

172
to be developed, an arrow describes a dependency relationship, a dashed arrow indi-
cates iteration, the numbers in the upper left hand corner indicate the order that the
model should be developed in a given iteration. The prOposed deveIOpment paradigm
includes iterations Of model reﬁnement where each subsequent iteration adds more
design detail. In Figure 8.2, the ﬁrst three models are system level Object, functional,
and dynamic models that describe the structural, functional, and dynamic behavioral
aspects Of a system, respectively. The subsequent three models capture information
that is similar tO the ﬁrst three models, except they depict the structural, functional,
and behavioral features Of Objects at a level more detailed than that at the system
level. The service reﬁnement functional model reﬁnes a service Of an Object in terms
Of the services provided by its aggregate Objects at a lower level Of abstraction. The
reﬁned dynamic model reﬁnes the dynamic behavior Of an Object in terms Of its inter-
action with Objects at a lower level Of abstraction. The composed parallel dynamic
model is a composition Of a set Of dynamic models of Objects that are synchroniz-
ing with each other. Once the composed parallel dynamic model at a certain level
Of abstraction is Obtained and analyzed, the development enters the next iteration
Of model reﬁnement and derivation. Table 8.1 describes the models and the formal
speciﬁcations that are derived from the corresponding models. The double lines are
used tO separate the (1) models that describe the system as a whole, (2) individual

aggregate Objects, and (3) the composition Of the aggregate Objects.

173

 

[ Models

[ Use

[ Formal Specifications

 

 

(System-Level)
Object Model

depicts the static structure Of
a system

derives class name and
class attributes

 

(System-Level)
Functional
Model

contains services provided by
a system

derives services and
service specifications

 

(System-Level)
Dynamic Model

speciﬁes all the possible
interaction patterns Of a
system

derives state names,
behavior specifications,
and starting states

 

Reﬁned Object
Model

decomposes an Object into
aggregate Objects and
describes the
inter-relationship between
the aggregate Objects

derives class name and
class attributes

 

 

 

Dynamic Model

interaction patterns of an
Object

Object contains services provided by derives services and
Functional an object service specifications
Model (OFM)

Object speciﬁes all the possible derives state names,

behavior specifications,
and starting states

 

 

Service
Reﬁnement
Functional
Model (SRFM)

models a system/Object
service in terms Of the
services provided by
aggregate Objects

reﬁnes algebraic
specifications

 

Reﬁned
Dynamic Model

reﬁnes the dynamic behavior
model Of a system/Object
and expresses its behavior in
terms Of the interaction with
aggregate Objects

reﬁnes states and
behavior specifications

 

Composed
Parallel
Dynamic Model

 

 

composes the dynamic
models Of an Object and its
corresponding aggregate
Objects in parallel

 

composes behavior
specifications

 

Table 8.1: The models that will be developed during a given iteration Of design

 

174

 

 

(System)
Object Model

 

 

 

 

 

2 (System)
Functional Model

 

 

 

 

 

 

(System)
Dynamic Model

 

 

 

 

 

l

 

4” Reﬁned (System)

Object Model

 

 

 

 

 

l

 

5/2
< Object Functional Model

 

 

 

 

Iterations
—- of Design
Reﬁnement

ll
61) 62/3

Service Reﬁnement Object Dynamic Model
Functional Model

 

 

 

 

 

 

 

 

 

 

 

 

 

 

l

 

 

Reﬁned (System)
Dynamic Model

 

 

 

 

 

 

 

3 Composed Parallel
Dynamic Model * ‘ ‘ _]

 

 

 

 

 

Figure 8.2: Models in the order Of development

 

8.2.3 Design process

Booch [49] asserted: “We have observed two traits that are common to virtually all
of the successful object-oriented systems we have encountered, and noticeably absent
from the ones that we count as failures: {1) the existence of a strong architectural
vision; (2) the application of a well-managed iterative and incremental development
life cycle.” Our investigation attempts tO address the second trait for successful

development Of systems.

175

The prOposed design paradigm focuses on the process in order tO facilitate a step-
wise reﬁnement Of designs. Since formal speciﬁcations can be generated for each
reﬁnement step, analysis and veriﬁcation technique can be used tO check the consis-
tency and correctness Of design. Instead Of providing speciﬁc decomposition heuristic
methods, the proposed design process serves as a framework within which decompo-
sition heuristics can be conducted and design consistency can be checked. Sufﬁcient
freedom is left tO designers tO choose appropriate decomposition approaches during
design; decomposition heuristics is outside the scope Of this research.

The design process contains iterations Of model development that are introduced
in the preceding discussion. For each step Of model development during a given iter-
ation, corresponding formal speciﬁcations are derived or reﬁned. As a consequence, a
progressive, incremental development Of formal speciﬁcations can be performed con-
currently with the development Of graphical models. At the end Of each iteration,
analysis Of formal speciﬁcations can be performed to check the consistency Of diagrams

and their reﬁnements.

System design and architectural styles. The ﬁrst 8 steps of model and formal
speciﬁcation development are considered at the system design level. Since the Object
being decomposed in step 4 is a system, architectural styles [100, 101, 102] should
be taken into consideration tO facilitate the decomposition. An architectural style is
a recurring pattern Of system organization that provides an abstract architecture for
some family Of applications [103] (e.g., client-server architectural style). Based upon

the analysis results, choosing a speciﬁc architectural style for design is a step that

176

transforms the results Of requirements analysis to design. Since the decomposition
Of a system is typically dependent upon the creativity, wisdom, and experience Of
a designer, we leave freedom for designers tO determine which architectural style
tO use. The proposed design framework provides the necessary means for designers
tO describe various architectural styles by using graphical models that can then be

analyzed according tO their formal speciﬁcations.

Detailed design and design patterns. After the ﬁrst iteration (8 steps), indi-
vidual Objects are subject to decomposition and reﬁnement in order to achieve higher
modularity and cohesion for implementation purposes. An Object is subject tO decom-
position, unless it can be directly implemented by programming languages. Design
patterns are descriptions Of communicating Objects and classes that are customized to
solve a general design problem in a particular context [104]. The designers can choose
various design patterns as means tO Object decomposition for detailed designs. We
employ the same philosophy for detailed design as we did for system design: freedom
is left tO the designers tO determine which design pattern or decomposition approach
to use; the design process only provides the necessary means for designers to specify
their design models and the formalization Of the OMT models enable the automated

analysis Of the user’s design.

8.2.4 Consistency checking of reﬁnements

The advantage Of a computer-assisted transitional-parallel approach is that the formal

speciﬁcations can be used tO perform rigorous analyses during the design process in

177
order to detect and eliminate design errors. The available formal analysis has already
been discussed in Chapter 7. Here we particularly emphasize two types Of analysis tO

conduct during the design process.

Consistency checking for function reﬁnement. SRFMS describe the reﬁne-
ment Of the services. An SRFM captures the data dependency relationships between
the services provided by aggregate Objects. Therefore, algebraic assertions can be in-
troduced tO describe the constraints on the hierarchical acyclic directed structure in
which the aggregate Object services are related with each other. Because the services
are speciﬁed in terms Of pre- and postconditions, we make use Of them as a means
to Specify design constraints and proof Obligations. Given two services 51 and 32, if
the output data ﬂow Of 31 serves as an input data ﬂow Of 82, a basic constraint is
that the postcondition Of 31 Should not imply the falseness Of the precondition for 32,
in other words, they are not contradictory. Thus we impose a veriﬁcation Obligation
upon SRFMS tO check that the pre- and postconditions Of two adjacent services are

not contradictory.

Speciﬁcation analysis for behavior reﬁnement. Since the proposed design pro-
cess advocates an approach that generates formal speciﬁcations in parallel with the
successive reﬁnement Of semiformal design models, a behavior speciﬁcation, Obtained
by composing concurrent aggregation Objects, can be checked against the behavior
speciﬁcation Of their corresponding individual aggregate Object tO detect inconsis-

tency. In order tO validate the behavior speciﬁcation, a set Of test processes, can

178
be written in LOTOS tO simulate the environmental events. Then the same set Of
test processes can also be used to test the reﬁned behavior Speciﬁcation, where the
reﬁned speciﬁcation must also satisfy all the test processes before it can be accepted.
In addition to the consistency checking, behavior simulation can also be conducted

in order to interactively verify and validate the design.

8.3 The Design Process Applied to An Example

This section gives detailed descriptions about the design models and their correspond-
ing formal speciﬁcations in the order that they are developed during the proposed
design process. In order tO facilitate the understanding Of the models and the design
process, a simple sample system is developed. The sample system is a Disk Manager
that stores data. Each step of the process is described in the remainder Of this section,
where the step number is enclosed in parenthesis. Although some diagrams and the
corresponding formal speciﬁcations have appeared in the previous chapters, in order

to facilitate the reading, we present them again in this chapter.

System Level Object Model (1). The ﬁrst step in the process is tO create the
system level Object model, the highest level (most abstract) Of the Object model. It
depicts the system as a single entity tO be developed, and it establishes the starting
point for system development. Given the requirements speciﬁcations Of analysis, this
is the ﬁrst step Of design. Usually, requirements analysis may generate an Object

model that includes multiple Objects. Some Of the Objects represent environment

179
entities; some describe a part Of the target system to be developed. Therefore, by
giving the system level Object model, software engineers clearly identify the software
system to be deveIOped. A system level Object model generates a framework for
speciﬁcation within which speciﬁcations for functional and dynamic features Of the
system will be ﬁlled.

Figure 8.3 shows the system level Object diagram for Disk Manager. Since Disk
Manager is the only object tO be built at the system level, there is only one Object.
Conceptually, every part Of the system will be organized under Object Disk Manager,
thus forming a set Of hierarchically aggregated Objects. The formal speciﬁcation (in
Figure 8.4) for the Object diagram only contains a speciﬁcation declaration, where

detailed information will be added based on the development Of the model.

 

 

Disk
Manager

 

 

 

Figure 8.3: The system Object model for Disk Manager

 

 

speciﬁcation Disk_Manager [gates] : noexit
type Disk_Manager is

endtype
endspec

Figure 8.4: The ACT ONE speciﬁcation for system level Object model Of Disk Man-
ager

 

180

System Level Object Functional Model (2). A system level Object functional
model (OFM) describes the services, in terms Of data ﬂow diagrams, provided tO the
external world by the system. This model is the highest level (most abstract) Object.
Given a system level OFM, the formalization rules in Chapter 6 can be used tO
automatically generate speciﬁcations that describe the services in terms Of a LOTOS
gate list. Meanwhile, based upon the requirements analysis results and the services
identiﬁed in the system level OFM, algebraic speciﬁcations can be derived by designers
tO describe the properties Of the Object. A set Of high-level guidelines that describes
how tO derive algebraic speciﬁcations is given in Chapter 6. In order to capture the
functionalities Of the services, pre- and postconditions for the services should also be
speciﬁed by designers in terms Of the Operations Of algebraic speciﬁcations.

The system level OFM for Disk Manager is given in Figure 8.5, where services,
including their interface signatures, that Disk Manager provides tO the external world
are depicted in terms Of processes and input / output data ﬂows. This diagram intro-
duces three data types, Data, Key, and Void, and two Operations, Input and Output,
to the ACT ONE algebraic speciﬁcations in Figure 8.4. The ground wires associated
with services Input and Output indicate that the services need tO access internal data
structures in order to carry out the required functionality. The speciﬁcation (Fig-
ure 8.4) augmented with algebraic Speciﬁcations that describe the prOperties Of the
Disk Manager is given in Figure 8.6. The algebraic speciﬁcation that describes the
prOpertieS Of the Disk Manager is derived by the designer based upon the services

Of the Object. Since LOTOS currently does not support typed gates and pre- and

181
postconditions, the input / output arguments for services and their corresponding pre-

and postconditions are given in annotations delimited by the (* and *) pairs.

 

 

 

 

[ Disk_Manager [
r 1
\“Data\‘
/
Key Q Data
-— ——>
\ J

 

Figure 8.5: The system functional model for Disk Manager

 

System Level Dynamic Model (3). Similar to the system level functional model,
the system level dynamic model is the Object dynamic model for the system to be
developed. Based upon the system functional model, the system level dynamic model
captures the dynamic behavior (interaction patterns) Of a system in terms of the
services that the system provides. According tO the formalization rules given in
Chapter 5, a formal speciﬁcation in terms Of process algebras can be automatically
generated from the dynamic model, where the newly introduced Speciﬁcation is largely
under the ‘behavior’ section Of the speciﬁcation.

The system level dynamic model in Figure 8.7 contains only one state, Idle, associ-
ated with two transitions. If an event for either Input service or Output service occurs,

the corresponding Operation will be triggered. In Figure 8.8, the formal speciﬁcation

182

 

speciﬁcation Disk_Manager [Input, Output] (disk: Disk) :noexit :=
(*I Input : d: Data, k: Key -> Void l*)
(*lrequires (1 eq undef_Data = false and k eq undef_Key = false |*)
(*lmodiﬁes disk l*)
(*lensures disk’ eq input(disk“, d, k) = true l*)
(*l Output : k: Key -> Data |*)
(*lrequires disk eq empty = false and k eq undef_Key = false I*)
(*lensures result = output (disk, k) l*)

type DiskJ‘lanager is

sorts
Data, Key, Void, Disk
opnns
undef_Data : -> Data
undef_Key : -> Key
empty : -> Disk
input : Disk, Data, Key -> Disk
output : Disk, Key -> Data
eqns

forall disk: Disk, data: Data, k1, k2: Key
ofsort Data
output (empty, key) = undef_data;
(k1 = k2) => output (input(disk, data, k1), k2) = data

not(k1 = k2) => output (input(disk, data, k1), k2) = output(disk, k2)
endtype
endspec

Figure 8.6: The speciﬁcation for Disk Manager that speciﬁes its services and prOper-
ties

 

is augmented with the process algebras (delimited by “behavior” and “endproc”) that

capture the dynamic behavior Of Disk Manager depicted in the system dynamic model.

 

 

 

 

[ Disk_Manugcr: drn I
r N
C input(d:D.k:KVinput(d.k)
L oulwtlszlloulputlk) j

 

Figure 8.7: The system dynamic model for Disk Manager

 

183

 

speciﬁcation Disk_Manager [Input, Output] (disk: Disk) :noexit :=
(*I Input : d: Data, k: Key -> Void l*)
(*lrequires d eq undef_Data = false and k eq undef_Key = false |*)
(*lmodiﬁes disk l*)
(*lensures disk’ eq input(disk‘, d, k) = true |*)
(*l Output : k: Key -> d: Data |*)
(*lrequires disk eq empty = false and k eq undef_Key = false I*)
(*Iensures result = output (disk, k) |*)

type Disk_Manager is

sorts
Data, Key, Void, Disk
opns
undef_Data : -> Data
undef_Key : -> Key
empty : —> Disk
input : Disk, Data, Key -> Disk
output : Disk, Key -> Data
endtype
opnns
output : Disk, Key -> Data
eqns

forall disk: Disk, data: Data, k1, k2: Key
ofsort Data
output (empty, key) = undef_data;
(k1 = k2) => output (input(disk, data, k1), k2) = data
not(kl = k2) => output (input(disk, data, k1), k2) = output(disk, k2)
endtype
behavior
Idle [Input, Output] (empty)
where
process Idle [Input, Output] (disk: Disk) :noexit :=
(let PRE = disk in
Input ? d:Data ? k:Key;
[not(d eq undef_Data] and not(k eq undef_Key)] ->
(let POST = input(PRE,d,k) in Idle [Input, Output, Void] (POST))
[1

Output ? k:Key;
[not(PRE eq empty) and not(k, undef_Key)] ->
Output ! output(PRE, k); Idle [Input, Output] (PRE)
)
endproc
endspec

Figure 8.8: The complete Full LOTOS speciﬁcation for system level Object model Of
Disk Manager

 

184

Because a behavior speciﬁcation in Full LOTOS is executable, given the speciﬁca-
tion for Disk Manager, simulation and symbolic testing can be conducted tO perform
design veriﬁcation and validation. In order tO conduct simulation and testing, we
instantiated sorts Data and Key in terms Of predeﬁned sorts HexString and Natu-
ralNumber that are well deﬁned with complete algebraic theories. The instantiated
Speciﬁcation is given in Appendix E. The process “accept_test” in Figure 8.9 was
used tO test the behavior Of the Disk Manager before it was decomposed into Storage
and Compressor. In process accept_test, four data items associated with keys 4,1,3,
and 2, respectively are given, then two data items of data with keys 1 and 3 are
requested. The test process checks whether the Disk Manager returns correct values

in accordance with the corresponding keys.

 

process accept_test [input, output, success] : noexit :=
input !Hex(0) !succ(succ(succ(succ(0))));
input !Hex(3)+9 !succ(O);
input !Hex(5) !succ(succ(succ(0)));
input !Hex(8) !succ(succ(0));
output !succ(O); output !3+Hex(9);
output !succ(succ(succ(0))); output ! hex(S);
success;
stop
endproc

Figure 8.9: The testing process used tO analyze the behavior Of Disk Manager

 

Figure 8.10 captures the transcript Of oneexpand, a testing command in LOLA,
that composes the behavior Of Disk Manager in parallel with the testing process

accept_test through gates Input and Output, and executes a random trace Of the

185

composed process. The success event that appears in the 9th step shows that the

test successfully terminates. This implies that the returned values by Disk Manager

are correct.

 

lola> oneexpand 10 success accept_test -v
oneexpand 10 accept_test 0 1 -v

Rewriting expressions in the specification.
Rewriting done.

Analysing unguarded conditions.

Analysis done.

Composing behaviour and test :

accept_test [input,output,success]
I[input,output]l
idle [input,output] (empty)

input
input
input
input
output
output
output
output

(OWNOSU'IhCDMO-b

! hex(O) ! succ(succ(succ(succ(0))));
! 3 + hex(9) ! succ(O);
! hex(S) ! succ(succ(succ(0)));
! hex(8) ! succ(succ(0));
! succ(O);
! 3 + hex(9);
! succ(succ(succ(0)));
! hex(5);

SUCCGSS;

Process Test - accept_test

Test result

SUCCESSFUL EXECUTION.

Transitions generated = 9

Figure 8.10: Using accept_test testing process to analyze the speciﬁed Disk Manager

 

Similarly, other testing cases can also be written tO check the behavior Of the Disk

Manager. In addition, a stepwise simulation can also be conducted to further analyze

the behavior Of Disk Manager. Since the behavior Speciﬁcations, case testing, and

stepwise simulation are event-based, both case testing and Simulation enables the

186
designers tO detect design ﬂaws that two or more related behavior sequences are

inconsistent.

Reﬁned (System Level) Object Model (4). Decomposition is one of the most
important activities during design. Although decomposition heuristics is outside the
scope Of this research, it is necessary tO give an overview because Of its importance
during design.

Decomposition heuristics is an important issue Of design and is interwoven with
design reﬁnement during the design process. At each step Of design reﬁnement, de-
composition may be performed in order to decompose a part Of a system into smaller
modules for implementation. Software architectures and design patterns are two ma-
jor decomposition heuristics that have gained extensive interest in recent years. They

are also applicable during our proposed design process.

Software architecture: The component structure of a program or system, their in-
terrelationships, and principles and guidelines governing their design and evo-
lution over time [100].

Architectural style: A recurring pattern of system organization that provides an
abstract architecture for some family of applications [103].

Design pattern: Descriptions of communicating objects and classes that are cus-
tomized to solve a general design problem in a particular context [104].

Software architecture has long been recognized as an important issue for software
development [6] and has recently received signiﬁcant attention [101, 102]. The emer-
gence Of research in software architecture is due tO two primary reasons [100]. One
reason is that over the years designers have begun tO develop a shared repertoire of

methods, techniques, patterns, and idioms for structuring complex software systems.

187

The other reason is that the practice Of application development for different domains
now, after many years Of hard work, has resulted in reusable frameworks for product
families. The concern Of software architecture mainly focuses on the organization and
the connection Of the components Of a large system. The architecture style refers tO
a class Of architectures that share common characteristics. We, the Software Engi-
neering Research Group at Michigan State University, have further characterized the
architectural style in terms Of architectural topology, characteristics/constraints Of
components, and characteristics Of connections between components [105]. The most
popular architectural styles include client-server, pipeline, layered, and SO on.

Design patterns [104] provide reusable design blocks that help tO alleviate software
complexity during system design (for Simple systems) and detail design stages. They
supply the designers with design alternatives that have proven tO be successful. Design
patterns can be used for architecture design if a system is simple.

Though a design process and design decomposition have entirely different scopes
Of concern, there is a close relationship between the two. A design process focuses
on providing a process tO facilitate the decomposition and reﬁnement Of design in-
formation. Architectures and patterns focus on the advantages and disadvantages
Of different architectural styles and design patterns and their ability to solve speciﬁc
types of problems. Thus choosing a certain architectural style or design pattern is an
important step during design.

During the Object-oriented design process, the Objects are decomposed into sets
Of ﬁner-grained Objects in order tO achieve modularity that reduces complexity. This

decomposition activity is facilitated by Object model reﬁnement in our proposed de-

188

Sign process. A reﬁned Object model depicts the decomposition Of Objects Of a higher
level Of abstraction. Since a reﬁned Object model decomposes an Object into aggregate
Objects, it looks like a tree structure with a root and a set Of leaves. In this step,
architectural styles as well as design patterns should also be taken into consideration
in order to conduct better decomposition. The former is applicable for a system and
the latter for the decomposition Of an individual Object. During the ﬁrst iteration Of
reﬁnement, where the reﬁnement Of a system-level Object model decomposes a system,
architectural styles Should be considered. For Object decomposition, existing design
patterns may help the designers tO conduct the reﬁnement process. From the reﬁned
Object model, frameworks Of formal Speciﬁcations for newly introduced Objects can
be automatically generated by using our proposed formalization rules.

We have thus far achieved a relatively complete formal speciﬁcation in Full LOTOS
for the Disk Manager. The term “complete” used here means that the speciﬁcation
includes the static, functional, and behavioral description Of an Object instead Of
implying that the design is completed. In order tO conduct the design to a more
detailed level, further reﬁnement is needed.

Figure 8.11 gives a reﬁned Object model for Disk Manager. The reﬁned Object
model shows that Disk Manager is composed Of aggregate Objects Storage and Com-
pressor. The Object diagram in Figure 8.11 generates two speciﬁcation frameworks for
Objects Storage and Compressor in Figure 8.12. Once the aggregate Objects, Storage
and Compressor, are further speciﬁed in terms Of functional and dynamic models,
more design details Of Disk Manager can be added by using formal speciﬁcations

generated by aggregate Objects.

189

 

 

Disk
Manager

9
l 1

Storage Compressor

 

 

 

 

 

 

 

 

 

 

 

Figure 8.11: The reﬁned Object model for Disk Manager

 

 

speciﬁcation Storage [gates] : noexit
type Storage is Disk_Manager

endtype
endspec

speciﬁcation Compressor [gates] : noexit
type Storage is Disk_Manager

endtype
endspec

Figure 8.12: The ACT ONE speciﬁcations for Object models Of Storage and Compres—
sor

 

Object Functional (5) and Dynamic Models (6a). The OFM describes the
services provided by an individual Object to its external world. When an aggregate
Object is introduced into a system for the ﬁrst time during the reﬁnement Of Object
models, its corresponding OFM should also be developed to specify what services the
Object provides. Similar to the system-level OFM, based upon OFMs for individual
Objects, formal speciﬁcations that describe the signatures Of the services can be au-
tomatically generated according to formalization rules, and pre- and postconditions

that describe the behavior Of services derived by designers.

190

Based upon the OF M for an Object, an Object dynamic model can be developed
tO capture the dynamic behavior (interaction patterns) Of the Object in terms Of the
services provided by the Object. The formal speciﬁcations that are automatically
derived from dynamic models describe the behavior Of the Objects in terms Of process
algebras.

Similar tO the process used tO generate formal speciﬁcation for the Disk Manager,
Figures 8.13, 8.14, 8.17, and 8.18 contain the OFMS and dynamic models for Objects
Storage and Compressor, respectively. Their corresponding speciﬁcations in Full LO-
TOS are given in Figures 8.15, 8.16, and 8.19. The used rules include 0M1, 0M2,
OM10, DFR—l, DFR—2, DFR—3, DFR—4, DFR—6, DFR—7, DFR-8, DFR—ll,

DFR-12, DFR—13, FFR—l, FFR—Z, FFR-3, and FFR-4.

 

 

I Storage [
f \
\.I)aia\‘
/ Key :

Key a Data
__ _.

—_l_

 

 

\ J

Figure 8.13: The Object functional model for Storage

 

191

 

 

[ Storagezs

r w
( insert(d:D,k:K)/insert(s.d,k)

 

insert(d:D.k:K)/insen(s.d,k)

' retrieve(k:K)/retrieve(s,k)
delete(k: K)[count= 1 ]/delete(s.k)

delete(k:K)[count>1]/delete(s.k)

K J

 

 

Figure 8.14: The Object dynamic model for Storage

 

Service Reﬁnement Functional Model (6b). The description of a service re-
ﬁnement functional model involves a few subtleties because its derivation involves
several models at different levels Of abstraction. Figure 8.20 gives an example Of a
reﬁned Object model.

In Figure 8.20, Object O is a more abstract Object model that is decomposed
(reﬁned) into objects 01, 02, ..., On in the reﬁned Object model. Objects O, 01,
02, ..., O,, are all associated with corresponding OF Ms identifying the services they
provide. If S is a service provided by O, then its corresponding SRFM depicts how S
is composed in terms Of the services provided by O], 02, ..., On. However, the SRF M
only illustrates the data transformation among the provided services, the control
information and the order in which the provided services are activated are not in the
scope Of SRF M. However, the SRFMS do capture the data dependency relationships
between the services provided by aggregate Objects. Therefore, algebraic axioms can

be speciﬁed tO describe the constraints on the SRFM in which the aggregate Object

speci

A

AAAAAAA
.. a .. H

type

elldt
ends

 

Fl

192

 

speciﬁcation Storage [Insert, Retrieve, Delete] (8: S) :noexit :=
(*| Insert : d: Data, k: Key -> Void l*)
(*lrequires d eq undef_Data = false and k eq undef_Key = false l*)
(*Imodiﬁes s It)
(*lensures 3’ eq insert(s‘, d, k) = true |*)
(*| Retrieve : k: Key -> d: Data I*)
(*lrequires 8 eq empty = false l*)
(*Iensures result = retrieve (s, k) |*)
(*| Delete : k: Key -> Void l*)
(*Irequires k eq undef_Key = false and 8 eq empty = false|*)
(*Imodiﬁes s |*)
(*Iensures 3’ eq delete(s‘, k) = true |*)
type Storage is Disk_Manager, NaturalNumber
sorts
type S is (*l Distinguished sort 1*)
empty I insert (S, Data, Key)

endtype

opns
retrieve : S, Key -> Data
delete : S, Key -> S
count : S -> Nat

eqns

forall s: 8, data: Data, k1, k2: Key
ofsort Data
retrieve (empty, key) = undef_data;
retrieve (insert(s, data, k1), k2) = if k1=k2 then data
else retrieve(s, k2);
delete (empty, key) = empty;
delete (insert(s, data, k1), k2) = if k1=k2 then 8
else delete(s, k2);
count (empty) = 0;
count (insert(s, data, key)) = Succ(count(s));
endtype
endspec

Figure 8.15: The speciﬁcation for Object Storage in Full LOTOS

 

193

 

behavior
Empty_State [Insert, Retrieve, Delete] (empty)
where
process Empty_State [Insert, Retrieve, Delete] (3: S) : noexit :=
(let PRE = s in
Insert ?dzD ?k:K;
(let POST = insert(PRE, d, k)
in None_Empty_State [Insert, Retrieve, Delete] (POST))
endproc
process None_Empty_State [Insert, Retrieve, Delete] (8 : S) : noexit :=
(let PRE = s in
Retrieve ?k:K;
[not(s eq empty)] ->
Retrieve ! retrieve (PRE, k);
None_Empty_State [Insert, Retrieve, Delete] (PRE)
ll
Insert ?d:D ?k:K;
[not(d eq undef_Data) and not(k eq undef_Key)] ->
(let POST = insert(PRE, d, k) in
None_Empty_State [Insert, Retrieve, Delete] (POST)
)

[1

Delete ?k:K;
[not(k eq undef_Key) and not(s eq empty)] ->
([count(s) gt Succ(0)] ->
(let POST = delete (PRE, k)
in None-Empty_State [insert, retrieve, delete] (POST))
[l
[(count(s) eq Succ(0)) and (delete(s,k) eq empty)] ->
(let POST = delete (PRE, k)
in Empty_State [insert, retrieve, delete] (POST))
)
)
endproc
endspec

Figure 8.16: The Speciﬁcation for Object Storage in Full LOTOS

 

194

 

I Compressor I

r D

Data a Data

— ——>
Data Data

— Decompres —’

. 1

Figure 8.17: The Object functional model for Compressor

 

 

 

 

I Compressor: c I

decompress(dzD)

decompression

decompress(d)

 
   

compress(dzD)
compressron
compress(d)

Figure 8.18: The Object dynamic model for Compressor

       

 

 

services are related with each other. Because the services are speciﬁed in terms Of
pre- and postconditions, we can use them to describe design constraints.

In Figures 8.21 and 8.22, the SRFMS for services Input and Output provided by
Disk Manager are illustrated. The constraints introduced by the reﬁnement Of the
service Output is described in terms Of ACT ONE axioms in Figure 8.23. Given
the SRFM in Figure 8.22, according to the formalization rules for SRFMS in Chap-
ter 6, the postcondition Of service Storage.Retrieve and the precondition Of service
Compressor.Decompress, which are given in Figures 8.15, 8.16, and 8.19 respectively,

should be consistent. The conjunction Of the two can be analyzed tO check the con-

 

 

 

specﬂ

A
I

I

 

type

endq
bEht

“rhe.

 

 

195

 

speciﬁcation Compressor [Compress, Decompress] (c: C) :noexit :=
(*I Compress : d: Data -> Data |*)
(*lrequires d eq undef_Data = false |*)
(*lensures result = compress(d) and size(result) 1e size(d) l*)
(*l Decompress : d: Data —> Data |*)
(*lrequires d eq undef_Data = false |*)
(*lensures result = decompress(d) and size(result) ge size(d) |*)
type Storage is Disk_Manager, NaturalNumber
sorts
C (*I Distinguished sort |*)
opns
compress : Data -> Data
decompress : Data -> Data
size : Data -> Nat
eqns
forall data: Data
ofsort Bool
size(data) ge size(compress(data)) = true;
size(data) le size(decompress(data)) = true;
decompress(compress(data)) = data;
endtype
behavior
Idle_State [Compress, Decompress]
where
process Idle_State [Compress, Decompress] : noexit:=
Compress ?dzD; Compress_State [Compress, Decompress] (d)
[l
Decompress ?dzD; Decompress_State [Compress, Decompress] (d)
endproc
process Compress_State [Compress, Decompress] (dzD): noexit:=
i; Compress ! compress(d); Idle_State [Compress, Decompress]
endproc
process Decompress_State [Compress, Decompress] (dzD): noexit :=
i; Decompress ! decompress(d); Idle_State [Compress, Decompress]
endproc
endspec

Figure 8.19: The Speciﬁcation for Compressor in Full LOTOS

 

 

196

 

 

 

 

 

pg 53-53

Figure 8.20: An example reﬁned Object model

 

sistency Of function reﬁnement. Since the result Of Storage.Retrieve will be supplied
tO Compressor.Decompress, given the pre— and postconditions Of the two services, the
constraint is

((s neq empty =>(resu1t=retrieve(s,k) and result neq undef_Data) eq false)=false).
The equation speciﬁes that, given a non-empty Storage Object, the retrieved data
for key k should be a valid data item that can be fed into the Decompress service

provided by the Compressor Object.

 

 
   
 
     
     
 

Disk_Managerlnput

Data Compressor.

Compress

 

Key Storage.

Insert

 

Figure 8.21: The service reﬁnement functional model for function Input Of Disk Man-
ager

 

There are basically two approaches tO performing the consistency checking. As

mentioned previously, due tO the lack Of proof tOOl support for ACT ONE spec-

197

 

  

Disk_Manager.Output

  
  
   

 
 
 

Storage.
Retneve

Data

 
 

Compressor.
Decompress

  

Figure 8.22: The service reﬁnement functional model for function Output Of Disk
Adanager

 

 

type Disk_Manager_REF is Storage, Compressor, Disk_Manager
eqns
forall s: S, d: Data, k: Key
ofsort Bool
not(s=empty) => not(retrieve(s,k) = undef_Data) = true
endtype

Figure 8.23: The reﬁned ACT ONE speciﬁcation for Disk Manager

 

iﬁcations, we translated the speciﬁcations into LSL in order to use LP to check
for consistency between pre- and postconditions. The corresponding LSL speciﬁ-
cations are given in Appendix F. Figure 8.24 gives the LSL speciﬁcation trans-
lated from the ACT ONE speciﬁcation for the reﬁned Disk Manager given in Fig-
ure 8.23. The translation is currently performed manually, though a parer can be
written to perform the translation automatically. The prOOf Obligation is simpliﬁed
tO ”(s=empty) =>"(retrieve(s,n)=undef_d) and is given in the implies clause (the
simpliﬁcation can also be assisted by tools, such as PVS). Figure 8.25 shows the result

Of the proof using LP.

198

 

Disk_ref (D, K): trait
includes Storage(D,K) , Compressor(D)
implies
V s: S, n: N
~(s=empty) => ~(retrieve(s,n) = undef_d);

Figure 8.24: The LSL speciﬁcation for the reﬁned Disk Manager

 

 

LP2: display proof

Conjecture Disk_refTestTheorem.1: ~(s = empty) => ~(retrieve(s, n) = undef_d)

Attempting a proof by depth 2 structural induction on ‘8’
Level 2 subgoal 2 (basis step) for proof by induction on s:

~(insert(empty, n1, n2) = empty)

=> ~(retrieve(insert(empty, n1, n2), n) = undef,d)

Current subgoal: ~((if n = n2 then n1 else undef-d) = undef_d)

Attempting a proof by depth 2 structural induction on ‘n’
Level 3 subgoal 1 (basis step) for proof by induction on n:

~((if O = n2 then n1 else undef_d) = undef_d)

Attempting a proof by depth 2 structural induction on ‘n1’
Level 4 subgoal 1 (basis step) for proof by induction on n1:

~((if O = n2 then 0 else undef_d) = undef_d)

Attempting a proof by depth 2 structural induction on ‘n2’
Level 5 subgoal 2 (basis step) for proof by induction on n2:

~((if 0 = succ(O) then 0 else undef_d) = undef_d)

Current subgoal: false

Attempting a proof by normalization

LP3:

Figure 8.25: The prOOf Of the example constraint using LP

 

199

By using the induction prOOf method provided by LP, we reach a point that Shows
Current subgoal: false (in Figure 8.25), which means there are cases that leads
tO false under that constraint. The prOOf detects an inconsistency between the post-
condition Of Storage.Retrieve and the precondition Of Compressor.Decompress, thus
requiring us tO perform a further inspection into the problem. Further investigation
reveals that the Storage.Retrieve Operation is Speciﬁed to return undef.d if it is given
a key that has never been inserted into the storage. In this case the precondition Of
Compressor.Decompress, which speciﬁes that the input is not an invalid value, cannot
be satisﬁed. This situation must be taken into consideration when the dynamic model

Of Disk Manager is reﬁned.

Reﬁned (System) Dynamic Model (7). Once the services Of Object O are re-
ﬁned in terms Of services provided by aggregate objects 01, 02, ..., On, and the
dynamic models Of 01, Oz, ..., 0,, are derived, the dynamic model Of O is reﬁned
accordingly. The reﬁned dynamic model substitutes the services Of O with services
provided by 01, 02, ..., 0,, and interacts with the dynamic models Of 01, 02, ...,
On. From the reﬁned dynamic model, a speciﬁcation in terms Of process algebras can
be automatically generated. The speciﬁcation describes the reﬁned behavior Of the
corresponding Object. For instance, Figure 8.26 Shows an example dynamic model for
Object O. The dynamic model contains only one state. Whenever an event 51 occurs,
the two arguments associated with the event are taken, the corresponding service, SI

is triggered tO provide the requested service.

200

 

( Sl(xl:Sl. x2:SZ)/Sl(xl.x2)

L M

 

 

Figure 8.26: An example dynamic model for Object O

 

Figure 8.27 shows an example SRF M that reﬁnes service 81 Of Object O in terms
Of the services provided by Objects 01 and 02 that constitute O. In this diagram, the
data ﬂows and the related services are depicted. Service 02.53 takes the output Of

service 01.82 as input, thus having a data dependency.

 

 

Figure 8.27: An example SRFM for service S 1 Of Object O

 

The dynamic model in Figure 8.28 further reﬁnes the dynamic model Of Object 0
given in Figure 8.26 according to the SRF M in Figure 8.27. The diagram depicts the
behavior sequence Of Object O for a given event that requests for service 51. Once
0 receives a request for service 31: ( 1) 51 Of O takes two input arguments; (2) feeds
them intO 01.32; (3) takes the output from Ol.S2 and feeds it into 02.83; (4) then

takes the output from 02.83 and returns it tO the caller Of service SI.

201

 

 
 

Sl(xl:Sl. x2:SZ)"Ol.SZ(xI.x2)

   
 

02-53(35‘V5‘”) Oiszry: ssrozssry)

Figure 8.28: An example reﬁned dynamic model for Object O

 

Based upon the SRFMS, the dynamic model Of Disk Manager is further reﬁned
and given in Figure 8.29. Three intermediate states 1S1, 1S2, and 1S3 are added in or-
der to describe the reﬁned dynamic behavior. The reﬁned dynamic model reﬂects the
fact that the services Input and Output Of Disk Manager are implemented in terms
Of the services provided by Objects Storage and Compressor. However, the reﬁned
dynamic model was derived before we conducted the consistency for the SRFMS. As
we have shown in the above discussion, the returned value from Storage.Retrieve,
under some circumstances, may be undef_Data, which is contradictory tO the pre-
condition for Compressor.Decompress. This needs to be addressed in the reﬁned
dynamic model. Therefore a guarding condition is added tO the transition that trig-
gers the Compressor.Decompress event in order tO guarantee that the value passed
to Compressor.Decompress is valid. In addition, once an invalid value is returned
from Storage.Retrieve, the state Of Disk Manager should return to Idle instead Of
conducting further transactions. The revised dynamic model is given in Figure 8.30.
The corresponding reﬁned speciﬁcation in terms Of process algebras is given in Fig-

ure 8.31. The formalization rules used tO generate the formal speciﬁcation include

 

202
DFR—l, DFR—2, DFR—B, DFR-4, DFR—5, DFR—6, DFR—7, DFR-8, DFR—ll,

DFR-12, and DFR-13.

 

 

Disk_Manager: dm 1
F

  
  

output(k:K)"Stmage.ret(k)

 

input(d.‘ D.k : K VY‘COinpressor.com(d)

 

 

t D

Figure 8.29: The reﬁned dynamic model for Disk Manager

 

 

 

  
      
  

Disk_Manager: dm
r1 1 i
output(k: K )‘Storagereukl
input: d:D.k : K )‘Compressorcomt d)

reudzDildl=undef_DataI 0 - . couldzDVSlorugeJnsldk)
dec(d:Di/outputrd

 
 

 

 

I

Figure 8.30: The revised reﬁned dynamic model for Disk Manager

 

Composed Parallel Dynamic Model (8). Given the reﬁned dynamic model Of
Object O and dynamic models Of aggregate Objects 01, 02, ..., On, a parallel dynamic
model can be composed tO model communication and interaction Of the aggregate
Objects. In the parallel dynamic model, the reﬁned dynamic model Of O and the
dynamic models Of 01, 02, ..., On communicate with each other. With respect to

information encapsulation, one key characteristic Of any Object-oriented methodology

203

 

type Disk_Manager_REF is Storage, Compressor, Disk_Manager
behaviour
Idle [Input,Output,Compress,Decompress,Insert,Retrieve]
where
process Idle[Input,Output,Compress,Decompress,Insert,Retrieve]::noexit:::
Input ?dzD ?k:K; Compress !d !k;
ISl[Input,Output,Compress,Decompress,Insert,Retrieve](k)
[l
Output ? sz; Retrieve ! k;
IS2[Input,Output,Compress,Decompress,Insert,Retrieve]
endproc
process ISl [Input ,Output ,Compress ,Decompress, Insert,Retrieve] : noexit :=
Compress ?dzD; Insert !d !k;
Idle[Input,Output,Compress,Decompress,Insert,Retrieve]
endproc
process IS2 [Input , Output ,Compress ,Decompress , Insert ,Retrieve] : noexit z:
Retrieve ?d:D;
([d eq undef_Data] ->
Idle[Input,Output,Compress,Decompress,Insert,Retrieve]
[]
[not(d eq undef_Data)] -> Decompress !d;
ISS[Input,Output,Compress,Decompress,Insert,Retrieve]
)
endproc
process I33 [Input ,Output ,Compress ,Decompress , Insert,Retrieve] : noexit :=
Decompress ?dzD; Output !d;
Idle[Input,Output,Compress,Decompress,Insert,Retrieve]
endproc
endspec

Figure 8.31: The reﬁned ACT ONE speciﬁcation for Disk Manager

 

is that a change in an Object is not visible tO external Objects. The only means that
a change can be reﬂected tO other Objects is through inter-Object communication.
Accordingly, the inter-Object communication is the only communication mechanism
in the formalized model; the visible events Of an Object are realized by the inter-Object
communication external tO the Object. The inter-Object communication is described
in terms Of LOTOS gate synchronizations (see Chapter 5). Formal speciﬁcations

can also be automatically generated from the composed parallel dynamic model (see

204
Chapter 5). The formal speciﬁcations precisely capture the dynamic interaction Of the
corresponding models. In addition tO behavior simulation, the formal speciﬁcations
can used tO perform consistency checking against output O’s original dynamic model
before reﬁnement.

Since the reﬁned dynamic model Of Disk Manager triggers the services provided
by Storage and Compressor, a dynamic model that comprises the three behavioral
dynamic models in parallel is constructed in Figure 8.32. The corresponding formal
speciﬁcation include both speciﬁcations for Storage and Compressor, in addition to
that for Disk Manager, in Full LOTOS. The speciﬁcations for Storage and Compressor
are treated as a Single complex process instead Of as separate speciﬁcations because
of the speciﬁcation structure Of the LOTOS language. The entire speciﬁcation is
given in Appendix G. The speciﬁcation given in Figure 8.33 describes how the three
dynamic models are composed in parallel in terms Of LOTOS.

Given the reﬁned LOTOS speciﬁcation for Disk Manager in Figure 8.33, we can
use the same set Of testing processes for Disk Manager that were developed before the
reﬁnement and decomposition to check the consistency Of the reﬁned models. F ig-
ures 8.34 and 8.35 captures the transcript Of oneexpand that composes the behavior
Of the reﬁned Disk Manager in parallel with the testing process accept_test (given
in Figure 8.9) through gates Input and Output, and executes a random trace Of the
composed process. The success event that appears in the 35th step in Figure 8.34
shows that the test successfully terminates. This result implies that the values re-

turned by Disk Manager are correct. If the internal events, 1, are removed from the

205

 

I Disk_Manager I
( Storage: 3 \

( ins(d:D.k:K)/insen(d.k)

insld:D.k:K)/insert(d.k) .

ret(k: K )lretrieve(k)

delete(k: K )[count=l I/delete(k)
delete(k: K )[count>l l/deletelk)

l' ....................................................................
Disk_Manager: dm

output! k: K Y‘Storagcretl k)
input(d' 0.1:: K Y‘Compressorcormd)

   
 

ret(d:D)[d!=undef_Data] Ionipressordecid) com(d:D)"Storage.ins(d.k)
dec(d:D)/output(d

Compressor: c

dec(d‘ D) ( com(d'D)

decompress(d ):

 
   
 

 

compress( d)

  
 

    

 

 

k J

Figure 8.32: The reﬁned dynamic model for Disk Manager that is composed by

parallel dynamic models

 

 

type Disk_Manager_REF is Storage, Compressor, Disk_Manager
behaviour

hide Compress, Decompress, Insert, Retrieve, Delete in
Storage [Insert, Retrieve, Delete] l[Insert, Retrieve]|

Idle [Input, Output, Compress, Decompress, Insert, Retrieve]

l[Compress, Decompress]| Compressor [Compress, Decompress]

endspec

Figure 8.33: The composed Speciﬁcation for Disk Manager

 

206
result, we can ﬁnd that the execution result is identical tO that given in Figure 8.9

(the testing process for Disk Manager before reﬁnement).

 

lola> oneexpand 50 success accept_test -v -i
oneexpand 50 accept_test 0 1 -v -i

Composing behaviour and test :

accept_test [input,output,success]
|[input,output]|
(hide ins,ret,del,com,dec in
storage [ins,ret,del]
l[ins,ret,del]l
idle [input,output,com,dec,ins,ret,de1]
l[com,dec]l
compression [com,dec]

Figure 8.34: Using accept_test testing process tO analyze the behavior Of the reﬁned
Disk Manager (1)

 

8.4 Summary

In this chapter, based upon the formalization and integration Of the models Of OMT
(presented in Section 2.4 and Chapters 4, 5, and 6), we prOposed a design process
that facilitates the deveIOpment Of formal design speciﬁcations in parallel with the
development Of OMT’s semi-formal, graphical models. Because Of the rigorous math-
ematical foundation Of formal speciﬁcations, both customers and designers can have
a more precise means to describe the design thus avoiding ambiguities. In addition,
symbolic simulation Of the design can help designers better understand the design as

well as facilitate the communication among designers and even with the customers.

207

 

1 input ! hex(O) ! succ(succ(succ(succ(0))));
2 i; (* com ! hex(O) *)

3 i;

4 i; (* com ! compress(hex(0)) *)

5 i; (* ins ! compress(hex(0)) ! succ(succ(succ(succ(0)))) *)
6 input ! 3 + hex(9) ! succ(O);

7 i; (* com ! 3 + hex(9) *)

8 i;

9 i; (* com ! compress(3 + hex(9)) *)

10 i; (* ins ! compress(3 + hex(9)) ! succ(O) *)
11 input ! hex(S) ! succ(succ(succ(0)));

12 i; (* com ! hex(S) *)

13 i;

14 i; (* com ! compress(hex(5)) *)

15 i; (* ins ! compress(hex(5)) ! succ(succ(succ(0))) *)
16 input ! hex(8) ! succ(succ(0));

17 i; (* com ! hex(8) *)

18 i;

19 i; (* com ! compress(hex(8)) *)
20 i; (* ins ! compress(hex(8)) ! succ(succ(0)) *)
21 output ! succ(O);
22 i; (* ret ! succ(O) *)
23 i; (* ret ! compress(3 + hex(9)) *)
24 i; (* dec ! compress(3 + hex(9)) *)
25 i;
26 i; (* dec ! 3 + hex(9) *)
27 output ! 3 + hex(9);
28 output ! succ(succ(succ(0)));
29 i; (* ret ! succ(succ(succ(0))) *)
30 i; (* ret ! compress(hex(5)) *)
31 i; (* dec ! compress(hex(5)) *)
32 i;
33 i; (* dec ! hex(5) *)
34 output ! hex(5);
35 success;

Process Test
Test result

accept_test
SUCCESSFUL EXECUTION.

Transitions generated = 35

Figure 8.35: Using accept_test testing process tO analyze the behavior Of the reﬁned
Disk Manager (2)

 

 

208
Finally, consistency can be checked during model reﬁnement Of the design process to
detect and eliminate design ﬂaws during earlier stages Of software development. A

simple example that employed the prOposed process tO conduct design is also given.

Chapter 9

Case Study

As a means tO Obtain empirical credibility [106] for our research, we applied the for-
malization and integration rules and design process tO an industrial project. This
chapter shows a case study that applied our prOposed integration and formalization
rules and design process to an industrial project, the Environmental Information Sys-
tem (ENFORMS) [107, 108], developed by the Software Engineering Research Group
(SERG) at Michigan State University over a three year period involving 15 software
developers. The remainder Of this chapter is organized as follows. Section 9.1 intro-
duces background information about the project. Section 9.2 discusses the focus Of
the case study. An overview Of the requirements analysis for ENFORMS project is
given in Section 9.3. Section 9.4 describes the system level modeling Of ENFORMS.
Based upon the system modeling, Section 9.5 discusses the system design Of EN—
FORMS. The design analysis and reﬁnement Of ENFORMS is given in Section 9.6.

A summary and conclusions drawn from the case study are given in Section 9.7.

209

 

210

9.1 The Project

During this decade, NASA will launch many new platforms into earth orbit, including
the satellites that will make up the Earth Observing System (EOS). The remotely
sensed data Obtained from EOS can be used tO promote global and national security,
extend international cooperation, and improve our ability to understand and man-
age global environmental, economic, and social problems. In the past, NASA and
other agencies have focused on the acquisition Of data rather than the integration or
the dissemination Of data. Many organizations addressing grand challenge problems,
such as those deﬁned by earth sciences, require the integration Of both physical and
human resource databases in an interactive manner. Such a capability allows reason-
ably informed policy analysts and related staff tO query an “Environmental Science
Workstation” SO as tO better understand how human uses impact our natural resource
base.

Scientiﬁc research addressing global change continues tO generate large quantities
Of information for analysis and understanding. However, the volume, distributed
nature, and diversity Of this information prohibits convenient access by many potential
users, including policy analysts, federal agency staﬁ, and local township planners.

ENFORMS [107, 108] has been developed tO facilitate the access, integration,
and analysis Of data relevant to a regional study that has local and global impacts.
Speciﬁcally, information from studies Of the Saginaw Bay Watershed region has been
used tO populate the ENFORMS archive. ENFORMS is the result Of a multidis-

ciplinary effort, largely sponsored by NASA, EPA, USDA, and the Consortium Of

211
International Earth Science and Information Network (CIESIN). The project team
consists Of researchers and practitioners from ﬁelds including computer science, en-
tomology, ecology, land and resource management, sociology, and geography. The
project team is divided into user needs analysts, application scientists, and computer
scientists.

There were several motivating factors that led to the selection Of the Saginaw
Bay Watershed region as the focus Of the regional study [107, 108]. The Saginaw Bay
Watershed region is located in central Michigan around the mouth Of the Saginaw Bay
Of Lake Huron. It is over 8,700 square miles in size. Large areas are devoted toward
industry and agriculture. Several state and national forests are located in the area.
There is also one major river in the area (Saginaw River) with many tributaries that
ﬂow into the Saginaw Bay. Thus, the entire watershed aﬁects the quality Of the Great
Lakes. The region is an excellent area tO study how humans affect the environment
because the major types Of land uses exist in the area. In addition, the Saginaw Bay
Watershed region is an important resource for the state Of Michigan as well as for the
United States. It is the center Of some Of the most productive agricultural soils in the
country. It contains several large industrial centers and thus supports many facets Of
the states’ economy.

The Saginaw Bay Watershed region has been identiﬁed by several United States
government agencies (e.g. EPA and USDA) as an area Of environmental concern
due tO the massive amount Of soil erosion that occurs in the area. The Great Lakes

Commission has reported that nearly 606 million tons Of soil are lost annually from

212
the Great Lakes area, at the cost Of over 3 billion US. dollars worth Of lost nutrients
and productivity [109].
The Objective Of ENFORMS is tO provide users with convenient access tO large
amounts Of multimedia information that may be distributed across many sites. Fig-
ure 9.1 shows a high-level View Of the organization, where the rectangles represent

participating sites.

 

in ”
m «is
ﬂ

Legend

m o W
“‘5‘ I [:1 Server processes

— Connection

 

 

 

 

 

Figure 9.1: A high-level view Of the architecture

The main requirements Of the system are threefold. First, the archive itself is
potentially large, and thus some sort of selective browsing mechanism is necessary
to help the user navigate through the archive. In order to keep the system ﬂexible
for new users and new features, it it was necessary that the system design be able

to support a variety Of browsing mechanisms and not be tightly coupled with either

213
the user interface or the user interface technology [110]. Second, information items
may be stored in a variety Of forms [111]: simple databases and data ﬁles, images,
documents, GIS maps, animations, parameterized models, and SO on; accordingly, the
system must be able tO determine which software tOOls are needed tO examine each
item. Finally, when accessing the archive, the distributed nature Of the stored items
should be transparent to the user with regards to the browser [111]; this requirement
also suggests that the system Should be able tO Operate both as a stand-alone system

and as a component Of a distributed system.

9.2 Focus of the Case Study

ENFORMS is a relatively large system that cost about 10 person years. In this
case study, we focus on the requirement that the distributed nature of the stored
items should be transparent to the user with regards to the browser when accessing the

archive. The case study shows that:
o The formalization and integration rules for OMT models can help the designers
to derive more precise and integrated descriptions Of the design.
0 The proposed design process facilitates the reﬁnement Of design information.

0 Based on the formal speciﬁcations derived from OMT models, analysis can be
performed tO check design consistency and to facilitate the understanding about
the design.

9.3 Overview of the Requirements Analysis

This section focuses on the distributed query feature Of the ENFORMS system.

214

A high-level description Of requirements analysis based on [112] is given as follows
tO provide an overview.

From the most abstract point Of View, the ENFORMS system allows a user tO
gain access to an archive Of data, where the identiﬁcation Of the data Of interest is
achieved by browsing related indices (i.e., a classiﬁcation scheme) about the data.

The ENFORMS uses a browse-analysis approach for decision support. Browsing
is the method used tO facilitate the construction Of queries about topics Of interest,
retrieval Of data related to those interests. Analysis services utilize data that is
retrieved from the archive after browsing.

In the browse-analysis framework, each browse-analysis task begins in the browse
state, where a user browses based on the type Of search model being employed. Search
models can vary from hierarchical and spatial to thematic. Once the search criteria
have been deﬁned, data is retrieved, placing the browse-analysis task in the retrieve
state. If a search is successful (i.e., desired data has been found), the browse-analysis
task transitions into the analysis state, where a user can analyze the data using tOOls
that can manipulate the data.

From the user perspective, there will be two modes Of Operation, browsing and
analysis. Browsing is a process that results in the selection of datasets from the data
archive. Selected datasets become part Of a project that may be used by the analysis
services. Analysis services provide tOOlS for exploring and manipulating the content
Of selected data sets. Analysis services allow for data tO be subsetted, aggregated
both spatially and temporally, and the results displayed in a variety Of manners. The

results Of data analyses are data products, and the sequence Of Operations that deﬁne

215
a given product (the product speciﬁcation) can be used to represent the data product
rather than tO actually require the product tO be explicitly stored.

While original sources Of data may be single repositories (i.e., the EPA mainframe),
users have been moving towards network topologies in terms Of both computer use and
data distribution. The ENFORMS system has been designed and implemented with
the assumption that users, as well as the data that they wish tO access, is distributed in
nature. Figure 9.1 depicts this idea Of an archive that is accessible via many different
network sites and by many different users. In order for EN FORMS tO be usable by
a wide group Of users, it must be able to Operate within the distributed computing
paradigm. Requirements R01004 and R04001 are from the original requirement

analysis document [112].

R01004 The system must provide distributed data access services.

RO400l The system will provide services that allow for the transparent
distribution Of data across a network Of data archives.

9.4 System Level Modeling

Based on the requirement analysis, the system level Object model, Object functional
model (OFM), and dynamic model shown in Figure 9.2 give a description Of the
system tO be develOped at a very high level Of abstraction. The Object model iden-
tiﬁes the ENFORMS system that includes both data archives and corresponding
data indices as the target system for development. The OFM depicts three services,
Browse, Retrieve, and Analysis, that the system is supposed tO provide. Based on

data indices, service Browse takes user input and formulates retrieve request. Ser-

216

vice Retrieve retrieves records from data archives for given retrieve requests. Service

Analysis performs analysis on the retrieved records according tO user input. The

dynamic model captures the behavior Of the system where a Retrieve service request

must be preceded by Browse requests, and Analysis service request must be preceded

by Retrieve requests.

 

 

ENFORMS

 

 

data_archive: Data_Archives
data_indices: Data_lndices

 

 

 

 

 

Ezequest

_Result
—>

5is_Result
—’

 

System level object model
I ENFORMS I

r W
User_ln put - Quer

———- Browse
Query_Reqr.est Query

Retrieve
Analysis_Request Anal .
l

—-1 @

k : J

 

System level object functional model

 

I ENFORMS: e I

 

 

   

 

 

f \
Browse (ui:User_lnput) Retrieve(qr: Query_Request)
/ Browse(ur) [not(isvalid(qr))]
okjﬂmwse (ui:User_lnput)
/ Browse(ur)
Browse(ui: ser__lnput) Retrieve(qr: Query_Request)
/ Browse(ui [isvalid(qr)]/ Retrieve(qr)
Analysis(ar: Analysis_Request)
IAnalysis(ar)
k J
System level dynamic model

Figure 9.2: The design models Of EN FORMS at the system level

 

Figures 9.3 9.4 show the formal speciﬁcation Of the system. The formalization

rules used tO generate the formal speciﬁcation include OMl, 0M2, OM10, DFR-l,

DFR—2, DER-3, DFR—4, DFR—6, DFR-7, DFR—8, DFR—ll, DFR-12, DFR-

13, FFR-l, FFR—Z, FFR—3, and FFR—4. The speciﬁcation can be automatically

generated by applying the formalization rules given in the previous chapters. The

speciﬁcations generated automatically from the diagrams give a formal description

217
Of the services that the system provides and the behavioral dynamic aspects Of the

system.

 

specification ENFORMS [Browse, Retrieve, Analysis] (e: ENFORMS) : noexit

(* Browse: ui: User_Input -> Retrieve_Request *)
(* Retrieve: rr: Retrieve_Request -> Retrieve_Result *)
(* Analysis: ar: Analysis-Request -> Analysis_Result *)
library

Boolean
endlib
type ENFORMS is Boolean

sorts

Data_Archives, Data_Indices, User_Input, Retrieve_Request,

Retrieve_Result, Analysis_Request, Analysis_Resu1t, ENFORMS
opns

undef_Data_Archives : -> Data_Archives

_ eq _ : Data_Archives, Data_Archives -> 8001

undef_Data_Indices : -> Data_Indices

- eq _ : Data_Indices, Data_Indices -> 8001

undef-User_Input : -> User_Input

_ eq _ : User_Input, User_Input -> 8001

undef_Retrieve_Request : -> Retrieve_Request

_ eq _ : Retrieve_Request, Retrieve_Request -> Bool

undef_Retrieve_Resu1t : -> Retrieve_Result

_ eq _ : Retrieve_Result, Retrieve_Result -> 8001

undef_Analysis_Request : -> Analysis_Request

_ eq _ : Analysis_Request, Analysis_Request —> 8001

undef_Analysis_Result : -> Analysis_Result

_ eq _ : Analysis_Resu1t, Analysis_Result -> 8001

undef_ENFORMS : -> ENFORMS

_ eq _ : ENFORMS, ENFORMS -> 8001

Browse: User_Input -> Retrieve_Request

Retrieve: Retrieve_Request -> Retrieve_Result

Analysis: Analysis_Request -> Analysis_Result

isvalid : Retrieve_Request -> 8001

ENFORMS : Data-Archives, Data_Indices -> ENFORMS
getArchives : ENFORMS —> Data_Archives

getIndices : ENFORMS -> Data_Indices

endtype

Figure 9.3: The formal speciﬁcation automatically generated from system models (1)

 

The automatically generated speciﬁcation should be syntactically correct. Inter-

model checking can be performed tO check the consistency between the three models

218

 

behavior
Browse?ui:User_Input; Browse!Browse(ui); Browse[Browse,Retrieve,Ana1ysis](e)
where
process Browse[Browse,Retrieve,Analysis](e:ENFORMS):noexit:=
Browse?ui:User_Input; Browse!Browse(ui);
Browse[Browse,Retrieve,Analysis](e)
[l
Retrieve?rr: Retrieve_Request;(
[isvalid(rr)] -> Retrieve!Retrieve(rr);
Analysis[Browse,Retrieve,Analysis](e)
[1
[not(isvalid(rr))] -> Browse[Browse,Retrieve,Analysis](e)
)
endproc
process Analysis[Browse,Retrieve,Analysis](e:ENFORMS):noexit:=
Browse?ui:User_Input; Browse!Browse(ui);
Browse[Browse,Retrieve,Ana1ysis](e)
[l
Analysis?ar:Analysis-Request; Analysis!Analysis(ar);
Analysis[Browse,Retrieve,Analysis](e)
endproc
endspec

Figure 9.4: The formal speciﬁcation automatically generated from system models (2)

 

Of the EN FORMS system (see Figure 9.2). We use the LOTOS semantics analyzer
(LSA) [64, 83] tO ensure that the sorts and Operations used in the dynamic models
are previously modeled in the Object and functional models and have corresponding
deﬁnitions in the automatically generated formal speciﬁcation. Figure 9.5 gives the
transcript that runs LSA over the formal speciﬁcation shown in Figure 9.3. The
successful termination Of the analysis indicates that no inter-model inconsistency is
detected by LSA.

Although the automatically generated formal speciﬁcation does not include a SO-
phisticated algebraic speciﬁcation that describe the properties Of EN FORMS, the

executable feature Of the process algebras that describes the dynamic aspect Of the

219

 

(131 aynow: > topo enforms_systemOl -v -s

TOPO_3R6 (Mon Jan 23 15:19:15 MET 1995) /usr/local/LOTOS/Tools/TOPO
semantics analysis ...

lfe enforms_system01.lot > Ta01614

mv Ta01614 enforms_system01.lfe

lsa -1 design -p enforms_system enforms_system.lfe

<132 aynow: >

Figure 9.5: The transcript Of running LSA over ENFORMS formal speciﬁcation to
check inter-model consistency

 

system enables designers and end customers tO symbolically execute the formal spec-
iﬁcation. The simulation provides an intuitive means to understand the system’s
functionality and behavior and a concrete approach that facilitates the communica-
tion among designers and customers. Figure 9.6 Shows a transcript Of the execution Of
the formal speciﬁcation by using LOLA. Because no constants for the sorts are intro-
duced in the automatically generated formal speciﬁcation, the interactive simulation
is quite high-level. NO concrete values is given during the simulation process. The
interactive execution conﬁrms the requirement that a Browse request must precede a
Retrieve request, a Retrieve request must precede an analysis request.

The formal speciﬁcation automatically generated from diagrammatic models prO-
vides a framework into which algebraic speciﬁcation can be added by designers. In
order tO further specify the prOpertieS Of ENFORMS and to perform better simula-
tion and analysis, more effort is needed to supply a well-deﬁned algebraic speciﬁcation
for ENFORMS. Figure 9.7 shows the reﬁned formal Speciﬁcation for ENFORMS

with a better-deﬁned algebraic speciﬁcation manually derived by using the guidelines

 

‘Fl

 

 

220

 

[ 1] analysis ! analysis(ar_18);
<n>,Undo,Menu,Refused,Sync,Print,Trace,Exit,?> 1

==> analysis ! analysis(ar_18);

[ 1] browse ? ui_19:user-input;
[ 2] analysis ? ar_20:analysis_request;

<n>,Undo,Menu,Refused,Sync,Print,Trace,Exit,?> t

[ 1] - browse ? ui_4:user-input;

[ 1] browse ! browse(ui_4);

[ 2] - retrieve ? rr_14:retrieve_request;
[ 1] - [isvalid(rr_14) = true]->

retrieve ! retrieve(rr_14);
[ 2] - analysis ? ar_18:analysis_request;
[ 1] - analysis ! analysis(ar_18);

<n>,Undo,Menu,Refused,Sync,Print,Trace,Exit,?>

Figure 9.6: The transcript Of running LOLA over EN FORMS formal speciﬁcation
for simulation

 

given in Chapter 6. The reﬁned Speciﬁcation captures system properties, and con-
tains pre- and postconditions that depict the functionalities Of Browse and Analysis
services.

In the reﬁned formal speciﬁcation, two Operations (Browse and Retrieve), four
constants (dataArchives, dataIndices, valid_Retrieve_Request, valid_Retrieve_Result),
and a section that describes the properties Of the Operations in terms Of equations
are introduced into the algebraic speciﬁcation part Of the formal speciﬁcation. The
Signatures Of the newly introduced Operations Browse and Retrieve are different from

that Of the original services Browse and Retrieve in Figures 9.3 and 9.4: Operation

221
Retrieve has an additional input argument Of sort Data_Archives; Operation Browse
has additional input argument Of sort Data_Indices. The additional input arguments
reﬂect the fact that internal data structures are involved for services Browse and Re-
trieve. The involvement Of internal data structures is already expressed in terms Of
the ground wire in the corresponding OFM for services Browse and Retrieve in Fig-
ure 9.2. The two constants, dataArchives and dataIndices, Of high-level abstraction,
represent the available data archives and data indices. Constants valid_User.Input,
valid.Retrieve_Request and valid-Retrieve_Result refer to the valid request arguments
for services Browse and Retrieve, and the result that Retrieve issues. Given the con-
stants, the equation section precisely deﬁnes the semantics Of Operations is Valid and
Retrieve. Since the distributed query feature is the focus Of this case study, services
Browse and Analysis are not further reﬁned.

The newly introduced Operations are used tO describe the functionalities Of the
services in terms Of pre- and postconditions. The pre— and postconditions for ser-
vice Retrieve state that for a given valid retrieve request, ENFORMS checks the
data archives and returns a valid result. Based upon the formalization rules for the
pre- and postconditions, the pre- and postconditions are also integrated into the prO-
cess algebra section Of the speciﬁcation, thus enabling more concrete simulation and
testing.

Figure 9.8 contains a test process for the reﬁned speciﬁcation Of ENFORMS. The
test process contains two consecutive browse-retrieve tests each Of which speciﬁes that

after a Browse service request, given a valid retrieve request, the ENFORMS system

 

- A.
‘

“_—

1:2...

E;

 

222

 

specification ENFORMS [Browse, Retrieve, Analysis] (e: ENFORMS) : noexit

(* Browse: ui: User_Input -> Retrieve_Request *)
(# ensures result = Browse (ui, getIndices(e)) *)
(* Retrieve: rr: Retrieve_Request -> Retrieve_Result *)
(* requires isValid(rr) *)
(* ensures result = Retrieve (rr, getArchives(e)) *)
(* Analysis: ar: Analysis_Request -> Analysis_Result *)
library
Boolean
endlib

type ENFORMS is Boolean
sorts
Data_Archives, Data_Indices, User_Input, Retrieve_Request,
Retrieve_Result, Analysis_Request, Analysis_Resu1t, ENFORMS
opns
dataArchives : -> Data_Archives
dataIndices : -> Data_Indices
valid_User_Input : -> User_Input
valid_Retrieve_Request : -> Retrieve_Request
valid_Retrieve_Result : -> Retrieve_Result
Retrieve : Retrieve_Request, Data_Archives -> Retrieve_Result
Browse : User_Input, Data_Indices -> Retrieve_Request
eqns
forall rr, rrx, rry: Retrieve_Request, da: Data_Archives
ofsort Bool
isValid (valid-Retrieve_Request) True;
isValid (undef_Retrieve_Request) False;
isValid (valid_Retrieve_Result) = True;
valid_Retrieve_Request eq valid_Retrieve_Request = True;
undef_Retrieve_Request eq undef_Retrieve_Request ‘ True;
undef_Retrieve_Request eq valid_Retrieve_Request False;
rrx eq rry = rry eq rrx;
ofsort Retrieve_Result
isValid (rr) => Retrieve (rr, da) = valid_Retrieve_Result;
not(isValid(rr)) => Retrieve (rr, da) = undef_Retrieve_Result;

endtype

behavior

endspec

Figure 9.7: The formal speciﬁcation with algebraic speciﬁcations and pre/post-
conditions

 

223
should return a valid result. If both tests are satisﬁed by the given system, a success

event is reached.

 

process test [Browse, Retrieve, Analysis, success] : noexit :=
Browse ! valid_User_Input;
Browse 7 rr: Retrieve_Request;
Retrieve ! valid_retrieve_request;
Retrieve ? rr: Retrieve_Result;
([isValid(rr)] -> Browse ! valid_User_Input;
Browse ? rr: Retrieve_Request;
Retrieve ! valid_retrieve_request;
Retrieve ? rr: Retrieve_Result;
([isValid(rr)] -> success; stop))
endproc

Figure 9.8: A test process for the reﬁned formal speciﬁcation Of EN FORMS

 

OneExpand is a LOLA function that makes a random symbolic execution Of the
current behavior. We use it tO test the reﬁned ENFORMS speciﬁcation. The test
process and the behavior speciﬁcation are composed in parallel, synchronizing all the
gates, except for the success event. LOLA analyzes whether the executions reach the
success event or not. A testing transcript that runs OneExpand with process test is
Shown in Figure 9.9. The test reaches the success event at the ninth step Of symbolic
execution.

Unlike OneExpand, which picks up a random symbolic execution, TestExpand can
perform an exhaustive test that explores all the symbolic execution paths of a speciﬁed
system. Figure 9.10 shows the testing transcript that applies the LOLA TestExpand
Operation tO the reﬁned ENFORMS formal speciﬁcation. Although unlimited depth

Of exploration is permitted for the exhaustive test, there is actually only one execution

 

 

224

 

lola> oneexpand -1 success test 23 -v
oneexpand -1 test 23 1 -v

Rewriting expressions in the specification.
Rewriting done.

Analysing unguarded conditions.

Analysis done.

Composing behaviour and test :

test [browse,retrieve,ana1ysis,success]
l[browse,retrieve,ana1ysis]|

browse ? ui_8:user_input;

browse ! browse(ui_8,getindices(e_7));

browse [browse,retrieve,analysis] (e-7)

1 browse ! valid_user_input;

2 browse ! browse(valid_user_input,getindices(e_7));
3 retrieve ! valid_retrieve_request;

4 retrieve ! valid-retrieve_result;

5 browse ! valid_user_input;

6 browse ! browse(valid_user_input,getindices(e_7));
7 retrieve ! valid-retrieve_request;

8 retrieve ! valid_retrieve_result;

9 success;

Process Test = test
Test result SUCCESSFUL EXECUTION.

Transitions generated = 9

Figure 9.9: The transcript Of testing that runs OneExpand Of LOLA over the reﬁned
EN FORMS formal Speciﬁcation

 

 

225
path for the given test process. During the exhaustive exploration Of testing, 9 states
are analyzed, 9 transitions are generated, but no deadlock is detected. The execution
reached the success event at the ninth step. Because no deadlock is detected during
the exhaustive testing, MUST PASS is given as the test result indicating that the
success event is always reached. The symbolic test, thus far, has shown very promising
testing results. Based upon the testing result, we can conﬁdently claim that for valid
retrieve requests, the designed system is very likely tO return a valid result. Since the
Objective Of testing is tO detect errors in design instead .Of proving correctness, the
fact that no design ﬂaw is reported after a large amount Of exhaustive testing does

not guarantee that the design is ﬂawless.

9.5 System Design

The system design Of the ENFORMS system is based on the design presented

in [112].

Overview

ENFORMS is designed as a distributed system, where the functionality Of the sys-
tem is realized through a collection Of communicating software components. The
distributed Operation Of ENFORMS is supported via a client-server architectural
style. In this style, servers accept requests over a network, perform the relevant ser-
vices, and return the results. The Client is a software component that requests the

services. In the case Of the ENFORMS client, the purpose Of the requested services

_L— “I

ﬁx.

 

226

 

lola> test success test -y -i
testexpand -1 success test -s -v 0 -y

Rewriting expressions in the specification.
Rewriting done.

Analysing unguarded conditions.

Analysis done.

Composing behaviour and test :

test [browse,retrieve,analysis,success]
|[browse,retrieve,analysis]I

browse ? ui_8:user_input;

browse ! browse(ui_8,getindices(e_7));

browse [browse,retrieve,analysis] (e_7)

Analysed states =
Generated transitions
Duplicated states

Deadlocks =

II
0000

test
MUST PASS.

Process Test
Test result

successes
stops

exits

cuts by depth

II
OOOH

Figure 9.10: The transcript Of testing that runs TestExpand Of LOLA over the reﬁned
ENFORMS formal speciﬁcation

 

is tO support the functionality realized at the GUI level. The requests that may be
issued by a client are categorized intO two types. First, Query requests may be issued
for selecting data items from data archives. Second, Server Table requests may be
issued for determining the set Of available servers. For each Of these cases, the com-
munication between a client and a server is essentially hidden from the user. That
is, the underlying details Of establishing connections and transmitting messages are

handled without user intervention.

227

Two main types Of servers are supported by EN FORMS. The ﬁrst is an Archive
Server that manages the searching and the manipulation Of items for an archive
site. The services provided by an archive server directly support the Query request
described above. The other type Of server supported by ENFORMS is referred tO
as the Name Server. The name server is responsible for maintaining a table Of the
active archive servers, referred tO as the Server Table. The address and port number
Of the name server is established prior tO the activation Of ENFORMS, such that
when an archive server is activated, the location Of the name server is already known.
Using this information, the archive server sends a registration message tO the name
server, providing its address for communicating with clients. The name server then
stores that information as an entry in the server table. Likewise, when an archive
server is deleted, the corresponding entry in the server table is removed. The name
server is also responsible for handling server table requests from clients.

Multiple archive servers may be active at one time, where each server provides
services for a particular archive site. However, a single instance Of a name server
answers the server table requests for the entire collection Of clients in ENFORMS.
An additional characteristic Of the distributed Operation Of ENFORMS is that a
client may send requests to any active archive server, and, likewise, an archive server
can provide services tO any Of the active clients. The relationship between the name
server, the archive servers, and the clients is illustrated in the architectural overview
shown in Figure 9.11. Figure 9.11 describes that the ENFORMS system is composed
Of (diamond) multiple (0 or more) clients and Archive Servers, and a Single Name

Server.

"ii

4.331;:

 

228

 

 

ENFORMS

<>

N ame_Server

 

 

 

 

 

 

 

 

 

 

 

Que Re ister
1 'y g a

Client I : : I Archive_Server

Query

 

 

 

 

 

 

Figure 9.11: The reﬁned Object model for EN FORMS: an overview Of the architec-
ture

 

The execution Of the ENFORMS system is initiated by activating the name
server. The archive servers are then typically activated, followed by any number Of
clients, although the system does not preclude the possibility Of activating the clients
before the archive servers. During the normal Operation Of the system, archive servers
and clients may be started or stopped at any time, while the name server remains

continuously active.

9.5.1 Design models for individual Objects

The Object, functional, and dynamic models for Name_Server are given in Figure 9.12.
Services Register and GetTable are provided by Name_Server for external services.

The Register service accepts registration requests from Archive Servers and puts

229
the corresponding records into Server Table. Service GetTable returns the current

Server- Table upon a request from Client.

 

 

 

N S I Name_Server: ns—I
ame_ erver ( \

 

 

server_table: Server_Table

 

 

Register(dan: Data_Archive_Name. 3: Address)
Object Model lRegister(da. 8)

L Name_Server I .
Data_Archive_l\£me \ pollRQ
\
Register
/ _

Address _

GetTable/GetTableO
Server_Table
GetTable ‘—>
1

x Z J k J
Object Functional Model Dynamic Model

 

 

 

 

 

 

 

Figure 9.12: The design models for Name_Server

 

The formal speciﬁcation automatically generated from the design models Of
Name_Server is shown in Figure 9.13. The formalization rules used tO generate the for-
mal speciﬁcation include OMl, 0M2, OM10, DFR—l, DFR-2, DFR—3, DFR-4,
DFR—6, DFR—7, DFR—8, DFR-ll, DFR—lZ, DFR-13, FFR—l, FFR—2, FFR—3,
and FFR—4. The formal speciﬁcation in Figure 9.14 extends the speciﬁcation in Fig-
ure 9.13 with well-deﬁned algebraic speciﬁcations, supplied by the speciﬁers according
to the guidelines given in Chapter 6, that describe the properties Of Name_Server and
pre- and postconditions that capture the functionalities Of the services.

The Object, functional, and dynamic models for Archive_Server are given in Fig-

ure 9.15. Service Query is provided by Archive_Server. During the initialization Of

 

:ﬁ—L— — A -

 

230

 

specification Name_Server [Register, GetTable] (ns: Name_Server) : noexit

 

(* Register: dan: Data_Archive_Name, a: Address -> Void *)
(* GetTable: -> Server_Tab1e *)
library
ENFORMS, Boolean
endlib
type Name_Server is ENFORMS, Boolean L]
sorts I
Name_Server, Server_Table, Data_Archive_Name, Address, Void I
opns I
undef_Name_Server : -> Name_Server u
_ eq _ : Name_Server, Name_Server -> 8001
undef_Server_Table : -> Server_Tab1e
_ eq _ : Server-Table, Server_Table -> 8001
undef_Data_Archive-Name : -> Data_Archive_Name
_ eq _ : Data_Archive_Name, Data_Archive_Name -> 8001
undef_Address : -> Address
_ eq _ : Address, Address -> 8001

Register : Data_Archive_Name, Address -> Void
GetTable : -> Server_Table

Name_Server : Server_Table -> Name_Server
getTable : Name_Server -> Server_Table
eqns
forall st: Server_Table
ofsort Server-Tab1e
getTable (Name_Server(st)) = st;
endtype

behavior
pollRQ [Register, GetTable] (ns)

where

process pollRQ [Register, GetTable] (ns: Name_Server) : noexit :=
Register ? dan: Data_Archive_Name ? a: Address; Register !Register(dan, a);
pollRQ[Register, GetTable] (ns)
[]
GetTable; GetTable ! GetTable; pollRQ [Register, GetTable] (ns)
endproc
endspec

Figure 9.13: The automatically generated formal speciﬁcation for Name_Server

 

231

 

specification Name_Server [Register, GetTable] (ns: Name_Server) : noexit

(* Register: dan: Data_Archive_Name, a: Address -> Void *)
(* ensures ns’ = Name_Server(insert(getTable(ns‘), dan, a)) *)
(* GetTable: -> Server_Table *)
(* ensures result = getTable(ns) *)
library
ENFORMS, Boolean
endlib

type Name_Server is ENFORMS, Boolean

sorts
Name_Server, Server_Tab1e, Data_Archive_Name, Address
opns
empty : -> Server-Table
insert : Server_Tab1e, Data_Archive_Name, Address -> Server_Table
getAddress : Server_Tab1e, Data_Archive_Name —> Address
delete : Server_Tab1e, Data_Archive_Name -> Server_Table
eqns

forall st: Server-Tab1e, dan1, dan: Data_Archive_Name, a: Address
ofsort Address

getAddress (empty, dan) = undef_Address;

dan1 eq dan => getAddress (insert(st, dan1, a), dan) = a;

not(dan1 eq dan) =>

getAddress (insert(st,dan1,a),dan) = getAddress (st,dan);

ofsort Server_Table

delete (empty, dan) = empty;

danl eq dan => delete (insert(st, dan1, a), dan) = st;

not(dan1 eq dan) =>
delete (insert(st,dan1,a),dan) = insert(delete(st,dan),dan1,a);

getTable (Name_Server(st)) = st;
endtype

behavior

endspec

Figure 9.14: The formal speciﬁcation for Name_Server with algebraic speciﬁcations
and pre/post-conditions

 

 

232
an Archive_Server, it registers its name and address tO a Name Server, then enters
the pollRQ state tO wait for query requests from Clients. The Query service accepts
query requests from Clients, performs the corresponding query, and returns the result

Of the query.

 

 

I Archive_Servcr : as I

r W

" e_Server.Register(getArchiveName(dan). getAddress(as))

 

Archive_Server

 

data_archive_name: Data_Archive_Name
data_archvie: Data_Archive Query(qr“. Query_Request. a: Address)
address: Address [HORISM é dress(a))]

 

 

 

Object Model

  

 

ery_Request. azAddress)
[isMyAd ess(a)]

do: Query
_Result Query(qr)

Object Functional Model Dynamic Model

[Archiveﬁerver I

   
 
 
  

Query_Request

 

 

Address

 

Figure 9.15: The design models for Archive_Server

 

The formal Speciﬁcation automatically generated from the design models Of
Archive_Server is shown in Figures 9.16 and 9.17. The formalization rules used tO
generate the formal speciﬁcation include OMl, 0M2, OM10, DFR—l, DFR—2,
DFR—3, DFR-4, DFR-6, DFR—7, DFR-8, DFR-9, DFR—ll, DFR—12, DFR-
13, FFR—l, FFR-2, FFR—3, and FFR-4. The formal speciﬁcation in Figure 9.18
extends the speciﬁcation with well-deﬁned algebraic speciﬁcations, supplied by the

speciﬁers according to the guidelines given in Chapter 6, that describes the properties

233
of Archive_Server and pre— and postconditions that captures the functionalities of the

services.

 

specification Archive_Server[Query,Name_Server_Register]
(as:Archive_Server):noexit

(* Query: qr: Query_Request, a: Address -> Query_Result *)
library
ENFORMS, Boolean
endlib
type Archive_Server is ENFORMS, Boolean
sorts

Archive_Server, Data_Archive_Name,

Data_Archive, Address, Query_Request, Query_Result
opns

undef_Archive_Server : -> Archive_Server

_ eq _ : Archive_Server, Archive-Server -> 8001

undef_Data_Archive_Name : -> Data_Archive_Name

_ eq _ : Data_Archive_Name, Data_Archive_Name —> 8001

undef_Data_Archive : -> Data_Archive

_ eq _ : Data_Archive, Data_Archive -> 8001

undef_Address : -> Address

_ eq _ : Address, Address -> 8001

undef_Query_Request : -> Query_Request

_ eq _ : Query_Request, Query_Request -> 8001

undef_Query_Result : -> Query_Result

_ eq _ : Query_Resu1t, Query_Result -> 8001

Query : Query_Request, Address -> Query_Resu1t

isMyAddress : Address, Archive_Server -> 8001

Archive_Server : Data_Archive_Name, Data_Archive, Address -> Archive_Server

getArchive : Archive_Server -> Data_Archive

getAddress : Archive-Server -> Address

getArchiveName : Archive_Server -> Data_Archive_Name
eqns

forall dan: Data_Archive_Name, da: Data_Archive, a: Address,
as: Archive_Server, qr: Query_Request
ofsort Data_Archive_Name
getArchiveName (Archive_Server(dan, da, a)) = dan;
ofsort Data_Archive
getArchive (Archive_Server(dan, da, a)) = da;
ofsort Address
getAddress (Archive_Server(dan, da, a))

a;
endtype

Figure 9.16: The automatically generated formal speciﬁcation for Archive Server ( 1)

 

234

 

behavior
Name_Server_Register !getArchiveName(as) !getAddress(as);
pollRQ [Query, Name_Server_Register] (as)
where
process pollRQ [Query, Name_Server,Register] (as: Archive_Server) : noexit :=
Query ? qr: Query_Request ? a: Address; (
[isMyAddress(a, as)] -> Query [Query, Name_Server_Register] (as, qr, a)
[]
[not(isMyAddress(a, as))] -> pollRQ [Query, Name_Server_Register] (as))
endproc
process Query[Query,Name_Server_Register]
(as:Archive_Server,qr:Query_Request,a: Address):noexit:=
1; Query ! Query (qr, a); pollRQ [Query, Name_Server_Register] (as)
endproc
endspec

Figure 9.17: The automatically generated formal speciﬁcation for Archive Server (2)

 

The object, functional, and dynamic models for Client are given in Figure 9.19.
Service Query is provided by Client. During the initialization time, a client retrieves a
Server Table that contains the current available archive servers from the name server,
then enters the idle state to wait for query requests from EN FORMS GUI. Once a
query request occurs, the client looks up the server table, issues the query request
to the corresponding archive server, waits for the query result from the archive, then
returns the result of the query.

The formal speciﬁcation automatically generated from the Client design models
is shown in Figure 9.20. The formalization rules used to generate the formal speci-
ﬁcation include 0M1, 0M2, OM10, DFR—l, DFR—Z, DFR—3, DFR-4, DFR-5,
DFR—8, DFR—ll, DFR—12, DFR—13, FFR—l, FFR—2, FFR-3, and FFR—4. The
formal speciﬁcation in Figure 9.22 extends the speciﬁcation in Figures 9.20 and 9.21

with well-deﬁned algebraic speciﬁcations, supplied by the speciﬁers according to the

235

 

specification Archive_Server [Query, Name_Server_Register]
(as: Archive,Server) : noexit

(* Query: qr: Query_Request, a: Address -> Query-Resu1t *)
(* ensures result = Query (qr, getArchive (as)) *)
library
ENFORMS, Boolean
endlib

type Archive_Server is ENFORMS, Boolean
sorts
Data_Archive_Name, Data_Archive, Address,
Archive_Server, Query_Request, Query_Resu1t
opns

ofsort Bool
isMyAddress (a, as) = a eq getAddress(as);
isValid (valid_Query_Request) = true;
ofsort Query_Result
isValid (qr) => Query(qr, da) = valid_Query_Resu1t;
not(isValid(qr)) => Query(qr, da) = undef_Query_Result;
endtype

behavior

endspec

Figure 9.18: The formal speciﬁcation for Archive_Server with algebraic speciﬁcations
and pre/post-conditions

 

guidelines given in Chapter 6, that describes the properties of Client and pre- and
postconditions that capture the functionalities of the services.

Similar to what we have done to the system level design model of ENFORMS
(see Figure 9.2), simulation and analyses can also be performed by manipulating the

derived formal speciﬁcations for the objects introduced above.

236

 

 

 

 

 

 

 

 
 

 

l Client: (2 I
f \
Client
“Name_Server GetTableO
server_table: Server_Table
Object Model
, Nune_Scrver.Gct ab|c(sl: Server_Tablc)

l C [rent I

F V

Query(dan: Data _ Arthive_Name. quucry_chucsl)

Data_Archive_Name AArcWWtAddmsugctTablctc), dan))

\ @ Qum, chsull ®
—.
___,_,...——-~ :

Query_chuesl

 

 

 

 

L Archive_Server.Qiery(qr: Query_Rcsull)/Qucry (qr)

J x J

Object Functional Model Dynamic Model

Figure 9.19: The design models for Client

 

9.5.2 The SRFM and reﬁned dynamic model for ENFORMS

Given the design models of the aggregate objects Client, Name Server, and
Archive_Server, the services of ENFORMS at the system level can be reﬁned in
terms of the services provided by the aggregate objects. Because the case study fo—
cuses on the distributed query feature of ENFORMS, the SRFM of service Retrieve
of EN FORMS is given in Figure 9.23. The formalization rules used to generate the
formal speciﬁcation include FFR—lO, FFR-ll, FFR—13, and FFR—14.

The SRFM shows how ENFORMS makes use of the Query service supplied by the
Client object in the client-server design architecture to implement the Retrieve func-
tionality. The examination of services Retrieve and Query reveals that the input data
ﬂows of the two are incompatible: the input data ﬂow for Retrieve is Retrieve-Request
while those for Query are Data_Archive_Name and Query-Request. This leads to the

data ﬂow reﬁnement of Retrieve_Request in the SRF M. The graphical notation splitter

237

 

specification Client [Query, Name_Server_GetTab1e, Archive_Server_Query]
(c: Client) : noexit

(* Query: qr: Query_Request, dan: Nata_Archive_Name -> Query_Result *)

library
ENFORMS, Boolean
endlib

type Archive_Server is ENFORMS, Boolean

sorts
Data-Archive_Name, Address, Query_Request,
Query_Result, Server_Tab1e, Client

opns
undef_Data_Archive_Name : -> Data_Archive_Name
- eq _ : Data_Archive_Name, Data_Archive_Name -> 8001
undef_Address : -> Address
_ eq _ : Address, Address -> Bool
undef_Query_Request : -> Query_Request
_ eq _ : Query_Request, Query_Request -> Bool
undef_Query_Result : -> Query_Resu1t
_ eq _ : Query_Result, Query_Result -> Bool
undef_Server_Table : —> Server_Table
_ eq _ : Server_Tab1e, Server_Table -> 8001
undef_Client : -> Client
_ eq _ : Client, Client -> 8001

Client : Server_Table -> Client
getTable : Client -> Server_Table
eqns
forall st: Server_Table
ofsort Server_Table
getTable (Client(st)) = st;
endtype

Figure 9.20: The automatically generated formal speciﬁcation for Client

 

238

 

behavior

Name_Server_GetTable;
Init [Query, Name_Server_GetTable, Archive_Server_Query] (c)

where

process Init [Query, Name_Server-GetTable, Archive_Server_Query]
(c: Client) : noexit :=
Name_Server_GetTable ? st: Server_Table;
Idle [Query, Name-Server_GetTable, Archive_Server_Query] (c)
endproc

process Idle [Query, Name_Server_GetTable, Archive_Server_Query]
(c: Client) : noexit :=
Query ? dan: Data_Archive_Name ? qr: Query_Request;
Archive_Server_Query ! dan ! getAddress(getTab1e(c), dan);
WaitQuery [Query, Name_Server_GetTab1e, Archive_Server_Query] (c)
endproc

process UaitQuery [Query, Name_Server_GetTable, Archive_Server_Query]
(c: Client) : noexit :=
Archive_Server_Query ? qr: Query_Result; Query ! qr;
Idle [Query, Name_Server_GetTable, Archive_Server_Query] (c)
endproc
endspec

Figure 9.21: The automatically generated formal speciﬁcation for Client

 

(the solid box) splits Retrieve_Request into Data_Archive_Name and Query-Request.
The SRFM also indicates that the output of Query is directly used as the output of
Retrieve. The formal speciﬁcation automatically generated from the SRFM is given
in Figure 9.24.

In the formal speciﬁcation further reﬁned (by a developer) for ENFORMS,
data sort Retrieve_Request is reﬁned as a tuple of sorts Data_Archive_Name and
Query-Request. This reﬁnement is speciﬁed in terms of newly introduced operations

Retrieve_Request, get_data_archive_name, get_query_request, and their corresponding

 

239

 

specification Client [Query, Name_Server_GetTab1e, Archive_Server_Query]
(c: Client) : noexit

(* Query: qr: Query_Request, dan: Nata_Archive_Name -> Query_Result *)

library
ENFORMS
endlib

type Client is ENFORMS
sorts
Data_Archive_Name, Address, Query_Request,
Query_Resu1t, Server_Tab1e, Client

opns
empty : -> Server_Table
insert : Server_Table, Data_Archive_Name, Address -> Server_Table
getAddress : Server_Tab1e, Data_Archive_Name -> Address
delete : Server_Table, Data_Archive_Name -> Server_Table
eqns

forall st: Server_Table, dan1, dan: Data_Archive_Name, a: Address
ofsort Address
getAddress (empty, dan) = undef_Address;
danl eq dan => getAddress (insert(st, dan1, a), dan) = a;
not(dan1 eq dan) =>
getAddress (insert(st, dan1, a), dan) = getAddress (st, dan);

ofsort Server_Table
delete (empty, dan) = empty;
danl eq dan => delete (insert(st, dan1, a), dan) = st;
not(dan1 eq dan) =>
delete(insert(st,dan1,a),dan) = insert(delete(st,dan),dan1,a);
getTable (Client(st)) = st;
endtype

behavior

endspec

Figure 9.22: The formal speciﬁcation for Client with algebraic speciﬁcations and
pre/post-conditions

 

240

 

    
  

ENFORMS.Retrieve

  
     
     

Data_Archive_Name
> A Query_Result
_< Client.Query

Query_Request _

 

Retrieve_Request Retrieve_Result

 

 

 

Figure 9.23: The SRFM for Retrieve service of ENFORMS

 

 

type ENFORMS_REF is ENFORMS, Name_Server, Archive_Server, Client
opns
Retrieve_Request : Data_Archive_Name, Query_Request -> Retrieve_Request
get_data_archive_name : Retrieve_Request -> Data_Archive_Name
get_query_request : Retrieve_Request -> Query_Request
Retrieve_Result2Query_Result : Retrieve_Result -> Query_Resu1t
Query_Result2Retrieve_Result : Query_Result -> Retrieve_Result
eqns
forall dan, dan1, dan2: Data_Archive_Name, qr: Query_Request,
rr: Retrieve_Result, qu: Query_Resu1t
ofsort Data_Archive_Name
get_data_archive_name (Retrieve-Request(dan, qr)) = dan;
ofsort Query_Request
get_query_request (Retrieve_Request(dan, qr)) = qr;
ofsort Retrieve_Result
Query_Resu1t2Retrieve_Result(Retrieve_Result2Query_Result(rr)) = rr;
ofsort Query_Result
Retrieve_Resu1t2Query_Result(Query_Result2Retrieve_Result(qu)) = qu;

 

endtype

Figure 9.24: The automatically generated formal speciﬁcation for the SRFM of Re-
trieve

 

241

equations. The formalization rules FFR—14 and FFR-15 are given in Chapter 6.

Operations Retrieve_Result2Query_Result and Query_Result2Retrieve_Result together

with the related equations specify that sorts Query-Result and Retrieve_Result are

convertible to one another.

Based upon the SRFM given in Figure 9.23, the dynamic model of EN FORMS

is also reﬁned in order to reflect the design that the Retrieve service of ENFORMS

is realized in terms of the Query services supplied by Client. Figure 9.25 gives the

reﬁned dynamic model of EN FORMS. Since the object models describe the primary

static structure of a system, they are not affected by the SRFMS.

 

 

I ENFORMS: e ]

 

F

Retrieve(qr: Query_Request)

Browse (ui:User_lnput) [not(isvalid(qr))]

/ Browse(ur)
Browse (ui:User_lnput)

/ Browse(ur)
Browse

 
   
 

get_Query_Request(qr))

Browse(uizUse lnput)

/ Browse(ui)
Client.Query(qr)
lRetrieve(Query_Result2Retrieve_Resultqr))

v

Analysis(ar: Analysis_Request)
/Analysis(ar)

 

Figure 9.25: The reﬁned design model for ENFORMS

Retrieve(qr: Query_Request)[isValid(qr)]
"Client.Query(get_Data_Archive_Name(qr),

 

 

242

In the reﬁned dynamic model, a state, WaitQuery, is added to reﬂect the design
that the Retrieve service of ENFORMS is realized in terms of the Query services
supplied by Client. The changed part of the model speciﬁes that: (1) once a Retrieve
request occurs, the input argument is processed to split into Data_Archive_Name and
Query-Request, (2) the request is redirected to a Client object for a Query service, (3)
the system enters WaitQuery state to wait for the query result from the Client, and (4)
after getting the query result from the Client, the system returns the converted result
to the end user. The formal speciﬁcation automatically generated from the reﬁned
dynamic model is shown in Figure 9.26. The formalization rules used to generate the
formal speciﬁcation include DFR-l, DFR—Z, DFR—3, DFR—4, DFR—5, DFR-6,

DFR-7, DFR—8, DFR—ll, DFR-IZ, and DFR-13.

 

process Browse [Browse, Retrieve, Analysis, Client_Query] (e: ENFORMS) : noexit :=
Browse ? ui: User_Input; Browse ! Browse (ui, getIndices(e));
BrowseEBrowse, Retrieve, Analysis, Client_Query] (e)
[]
Retrieve ? rr: Retrieve_Request; (
[isValid(rr)] ->
Client_Query ! get_data_archive_name (rr) ! get_query_request (rr);
WaitQuery [Browse, Retrieve, Analysis, Client_Query] (e)
[I
[not(isValid(rr))] ->
BrowseEBrowse, Retrieve, Analysis, Client_Query] (e)
)

endproc

process WaitQuery[Browse,Retrieve,Ana1ysis,Client_Query](e:ENFORMS):noexit:=
Client_Query ? rr: Query_Result; Retrieve ! Query_Result2Retrieve_Result (II);
Analysis [Browse, Retrieve, Analysis, Client_Query] (e)
endproc

Figure 9.26: The automatically generated formal speciﬁcation from the reﬁned dy-
namic model of ENFORMS

 

 

;_.=A_-‘ __~

 

 

243

9.5.3 Composing the objects in parallel

The analysis of the formal speciﬁcations of individual objects enables designers to
detect design ﬂaws brought by inter-model inconsistency and incorrect behavior mod-
eling for individual objects. Since the individual objects are designed to coordinate
with each other in order to implement the functionalities introduced at a higher level
of abstraction, it is necessary to compose the dynamic models of the concurrent ob-
jects and check if the objects, together, can realize the necessary functionalities (as
depicted by the dynamic model in Figure 9.27).

For this case study, the analysis is focused on checking whether the objects designed
in the client-server architectural style will realize the distributed query transparently.
Figure 9.27 gives a state diagram that composes the dynamic models of ENFORMS,
Client, Name_Server, and Archive_Server in parallel.

In the state diagram, the parameters of the distinguished sorts (Name_Server,
Client, and Archive_Server) for the objects are instantiated. Both the Client and
Name-Server objects are given empty server tables. Several data archives to which
ENFORMS must provide access are described in [112]. Two of the data archives are

used to instantiate the two Archive_Server objects.

STORET Ambient Water Quality Data: STORET archives data resulting
from the chemical analysis of water samples taken periodically from selected
sites. Samples are not necessarily taken at regular intervals for all sites. For each
sample, STORET gives a site description (latitude/longitude or landmarks)
where the sample was taken, date and time of sample, depth of sample, and

an analysis of the sample (water temperature, nutrient levels, dissolved oxygen,
etc.). The STORET archives are available via the EPA mainframe.

Permit Compliance System (PCS) Data: PCS contains data on permitted
surface water discharge sites, such as storm drains and waste discharge pipes.

244

 

l ENFORMSJC l
ﬁ

Retrieve(qr: Query_Request)

Browse (ui:User_lnput) [not(isvalid(qr})]

/ Browse(ur)

 
   
  
 
 

. Name_Server: ns=Name_Server(empty)
Browse (ui User_Input)
/ Browse(ur)

Registeﬂdan: Data_Archive_Name. it: Address)
lRegistcr(da. a)

A

GetTablc/GetTableO

Retrieve(qr. Query_Request)| isValid(qr)]
“Client.Query(get__Data_Archive_Name(qr),
get_Query_Request(qr))

Browse(ui:Use Input)
[Browse(ui)

Client Query(qr)
lRetrievc(Quer)_ ResultZRetn'eve _Resultqr))

Anal ysi s( art Anal ysis_Request)
/Analysis(ar)

——-——--—-——-—-—--———-—--‘-——-—————-i

Client: c=Client(empty)

"Name_Server.GetTable()

 
 

Name_Serve .GetTable(st: Server_Table)

Query(dan; Data_Archive_Name, qr:Query_Request)
“Archive_ServerQuery(dan. getAddress(getTable(c). dan))

A
w

Archive_Server.Query(qr: Query_Result)/Query (qr)

p_—-----—__——-———__—--—-—-——.-_--———---——-——————¢_-——---——-—-—-——--—----—----——q¢--——---.

Archive_Server: as=Archive_Server(pcs. pcs_db. 4899) Archive_Server: as=Archive_Scrver(storet. storet_db. 5699)

 
  
   
     

 
   
  
    
     

Nzu e_Server.Registcr(getArchiveName(dan). getAddress(as)) e_Server.Register(getArchiveName(dan). getAddress(as))

Query(qr. Query_Request. a: Address)
[not(isMyAddress(a))]

Query(qr: Query_Request. azAddress)
[not(isMyAddress(a))]

Query(qr: O ery_Request. asAddress)
[isMyA . css(u)]

do: Query

Query(qr) Query(qr)

 

Figure 9.27: The dynamic models composed in parallel

 

 

245
For each permit, an ID code for the discharging facility is given. The type of

discharge is described and the limits on the discharges are speciﬁed. The PCS
data is available via the EPA mainframe, and from Great Lakes Envirofacts.

Since the design is at a very high level of abstraction, it is neither necessary nor
realistic to describe the two data archives in detail in terms of algebraic speciﬁcations.
Instead, we introduce constants storet and pcs to represent the archive names, and
storet_db and pcs_db to represent the archives for S TORET and PCS, respectively.
Similarly, instead of developing a complete theory that describes the addresses for
the Archive Server objects, constants 4899 and 5699 of sort Address are randomly
chosen to refer to the two Archive_Server objects.

Based upon the formalization rules DFR—lS and DFR—19 given in Chapter 5,
algebraic speciﬁcations can be automatically generated to describe the newly intro-
duced constants. The ACT ONE speciﬁcation in Figure 9.28 speciﬁes the constants
in terms of nullary operations; it also asserts that every constant is equal to itself but

distinguished from other constants of the same sort.

9.6 Design Analysis and Reﬁnement

This section describes the analysis of diagrams via their formal speciﬁcations. It also

discusses the reﬁnement of the models based on errors detected during analysis.

9.6.1 Design ﬂaw detected in models

Chapter 5 introduces name binding as the mechanism that synchronizes the dynamic

models of the concurrent objects. During the process that synchronized the dy-

246

 

type ENFORMS_REF is ENFORMS, Name_Server, Archive_Server, Client

 

opns
pcs : -> Data-Archive_Name
pcs_db : -> Data_Archive
storet : -> Data_Archive_Name
storet_db : -> Data_Archive 1"
4899 : -> Address
5699 : -> Address
eqns

ofsort Bool
pcs eq pcs = True;
storet eq storet = True;
undef_Data_Archive_Name eq undef_Data_Archive_Name = True;
pcs eq undef_Data_Archive_Name = False;
undef_Data_Archive_Name eq pcs = False;
storet eq undef_Data_Archive-Name = False;
undef_Data_Archive_Name eq storet = False;
pcs eq storet = False;
storet eq pcs = False;
pcs-db eq pcs_db = True;
storet_db eq storet_db = True;
undef_Data_Archive eq undef_Data_Archive = True;
pcs_db eq undef_Data_Archive = False;
undef_Data_Archive eq pcs_db False;
storet_db eq undef_Data_Archive = False;
undef-Data_Archive eq storet_db False;
pcs_db eq storet_db = False;
storet_db eq pcs_db = False; -
4899 eq 4899 = True;
5699 eq 5699 = True;
undef_Address eq undef-Address = True;
4899 eq undef_Address = False;
undef_Address eq 4899 = False;
5699 eq undef_Address = False;
undef_Address eq 5699 = False;

Figure 9.28: The automatically generated formal speciﬁcation that describes the con-
stants in the reﬁned models of ENFORMS

 

247

namic models through name binding, we encountered a problem. Since a Client
object can communicate with multiple Archive_Server objects, the service request
Archive_Server. Query of the Client object shall be bound with the Query services
provided by both of the Archive Server objects. Because the two Archive_Server ob-
jects are interleaved with one another (represented by the three parallel lines on their
border), given the semantics of LOTOS, either of them can respond to a Query request
from the Client object once they are bound. Thus nondeterminism results. Since the
nondeterminism is not a feature of the intended design, it must be eliminated.

A further investigation reveals that there is a modeling flaw in our design. The
distributed system is designed in terms of a client-server architecture. An underly-
ing communication mechanism between clients and servers is assumed in the system
design. However, the assumption is not modeled in the design, thus resulting in
the nondeterminism during the communication between clients and servers. In order
to eliminate the nondeterminism, the design models need to be reﬁned in order to

incorporate the assumed communication support.

The Channel object class. Figure 9.29 shows a reﬁned object model that intro-
duces a Channel object class to facilitate the communication between Client objects
and Archive_Server objects.

The modeling of Channel is relatively simple, because we do not intend to model
the entire operating system and networking support in this case study. Figure 9.30
gives the three OMT models for Channel. The Channel class is modeled exclusively

to be used by the Client object to communicate with the two Name_Server objects.

 

 

248

 

 

ENFORMS

<>

Name_Server

l .
Client Archive_Server
Channel

Figure 9.29: The reﬁned object model for ENFORMS with Channel object

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I Channel: c ]

 

Channel (
Send (qr: Query_Request. a: Address)[a eq 4899]

"Channel4899(qr «
Object Model k.

 

    
     

 

 

 

Channel4899(qr: Query_Result)
/ Send(qr)

Channe15699(qn Query_Result)
/ Send(qr)

 

 

 

 

 

 

[ Channel 1
e R est
Qu [L equ WaitChanne15699
Qu y_Result

0 Send (qr: Query_Request. a: Address)[a eq 5699]

Address “Channcl5699(qr. a)
\
Object Functional Model Dynamic Model

Figure 9.30: The design models for channel

 

249

A Channel object provides a Send service that accepts Data_Archive-Name and
Address and returns Query_Result. A Channel object is designed to redirect a Query
request from a Client object to the corresponding Archive Server object whose address
is speciﬁed in the request, wait for the query result from the Archive_Server object,
and then deliver the query result back to the requesting Client object. The formal
speciﬁcation automatically generated from the OMT models of Channel is contained
in Figure 9.31. The formalization rules used to generate the formal speciﬁcation
include 0M1, 0M2, OM10, DFR—l, DFR—Z, DFR-3, DFR-4, DFR—5, DFR—S,

DFR—ll, DFR—12, DFR-13, FFR—l, FFR—2, FFR—3, and FFR—4.

The revised state diagram. The revised state diagram that composes the dy-
namic models of individual objects in parallel is given in Figure 9.32. In the revised
diagram, a dynamic model of a Channel object is incorporated. The dynamic models
are also synchronized through name binding.

In the state diagram, the dynamic models of the individual objects are synchro-

nized as follows:
0 The two Archive-Server objects are interleaved.

o The Client_Query service request from ENFORMS’s front-end is synchronized
with the Query service provided by the Client object by sharing name Query.

0 The Archive-Server. Query service request from the Client object is synchronized
with the Send service provided by the Channel object by sharing the actual name
Archive_Query.

o The Name_Server.GetTable service request from the Client object is synchro-
nized with the GetTable service provided by the Name_Server object by sharing
the actual name GetTable.

o The Name_Server. Register service requests from the two Archive_Server objects
are synchronized with the Register service provided by the Name_Server object
by sharing the actual name Register.

 

F*—_— .—

250

 

specification Channel [Send, Channel4899, Channe15699] (c: Channel) :
noexit

typedef Channel is ENFORMS, Channel
sorts
Channel
endtype

behavior
Idle [Send, Channel4899, Channe15699] (c)

where

process Idle [Send, Channel4899, Channe15699] (c: Channel): noexit :=
Send ? qr: Query_Request ? a: Address; (
[a eq 4899] -> Channel4899lqr !a;
WaitChannel4899 [Send, Channel4899, Channe15699] (c)
I]
[a eq 5699] -> Channe15699!qr !a;
WaitChanne15699 [Send, Channel4899, Channe15699] (c)
)

endproc

process WaitChannel4899 [Send, Channel4899, Chann615699] (c: Channel): noexit :
Channe14899 ?qr:Query_Resu1t; Sendlqr;
Idle[Send, Channel4899, Channe15699] (c)
endproc

process WaitChanne15699 [Send, Channel4899, Channe15699] (c: Channel): noexit :
Channe15699 ?qr:Query_Result; Sendlqr;
Idle[Send, Channel4899, Channe15699] (c)
endproc
endspec

Figure 9.31: The automatically generated formal speciﬁcation from the design models
of Channel

 

-..—4*.-

1’

251

 

l ENFORM52e I
K
Retrievet qr: Qierleequcst)
Inot(i5VIlid(qf))I

Browse (ui:User_lnput)

Retn'eve(qr: Query_RequcstHisVaIidiqr)!
"Query(get_Duu_Arc hivc_Nante(qr).
get,Query_Requcsttqr))

Browse (ui:User_lnput)
/ Browse(ur)

  
  

Name_Server. ns=Name_Server(cmptyl

Registeﬁdan: Data_Archive_Name. a: Address)
lRegistertda. a)

GetTubIchctTabld)

Browse(uizUse‘ Input)

I Browse(ui)

Analysis(ar: Analysis_Request)
lAnalysisIar)

Querytqr)
lRetrie vet Query_ResultZRetrieve_Resultqr))

-------—_---—---_--------_-_--___-__--.4

I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
l
I
I
I
I
I
I
I
I
l
I
I
I
I
I
I
I
I
I
I
I
I
l
l
I
I
I
I
I
I
I
I
I
l
I
I
I
1
I
I
I
I.
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
l

CIICDII C: Clicnt(cmpty) Channel' (=ch
GetTableO

Archive_Qucry (qr: Query_Request. a: Address)la eq 4899]

AArchive_Query-I . :
WaitChumel4899

Archive_Quet-y4899(qr: Query_ResuIt)
I Archive_Query(qr)

Archive_Query5699(qr. Query_ResuIt)
I Arthive_Query(qr)

0|

    
  
  
  
 

   
 

GetTabIe(st: s ervet_Table)

Query(dan: Data_Archive_Name. qr:Query_Request)
AArt:hive_Query(dam, getAddress(getTable(c). dan))

Archive_Query(qr: Query_ResultVQuery (qr)

Archive_Query (qr: Query_Request, it: Address)“: eq 5699!
"Archive_Query5699(qr. a)

Archive_Server; as:A1-chivc_Scrvcr(pcs, pcs_db, 4899) Archive_Server: as=Archive_Server(storet. storet_db. 5699)

 
   
     

Re 'stertgetArchiveNameman). getAddressusn R isterigetArthiveNamewan). getAddressusD

[not(isMyAddress(a. as)”

[not(isMyAddress(a. a))]

    

I
I
I
I
I
I
I
I
I
I
I
I
I
Archive_Query4899(qr. Query_Requcst. 3: Address) I Archive_QuerySw‘X qr: Query-Request. 8: Address)
I
I
I
I
I
I
I
I
I
I
I
I
I
I

 

 

: I do: Query
_ __,_ __
Queryt qr) : Query(qr)
k . /

 

Figure 9.32: The revised design models (with a Channel object) composed in parallel

 

252

o The Channe14899 service request from the Channel object is synchro-
nized with the Query service provided by the Archive-Server object, whose
Data_Archive_Name is pcs and Address is 4899, by sharing the actual name
Archive_Query4899.

o The Channel5699 service request from the Channel object is synchro-
nized with the Query service provided by the Archive_Server object, whose
Data-Archive_Name is pcs and Address is 5699, by sharing the actual name
Archive-Query5699.

The formal speciﬁcation in Figure 9.33 can be automatically generated from the
state diagram (Figure 9.32) in which the behavior of individual objects are synchro-
nized. The nature of process algebra speciﬁcations synchronizes the processes that
specify the behavior of the individual objects through shared LOTOS gates. The
formalization rules used to generate the formal speciﬁcation include DFR—l9 and

DFR—20.

9.6.2 Static analysis

The transcript in Figure 9.34 shows that the formal speciﬁcation1 passes the syn-
tax checking and semantics analysis by LFE (a syntax analyzor) and LSA [64, 83],

respectively. This indicates

o The formal speciﬁcation, including both parts that are automatically generated
and manually added, is syntactically correct.

0 The algebraic speciﬁcations of individual objects are semantically consistent.

o The application of name binding through which the behavior of objects are
synchronized does not result in inconsistency.

 

1Appendix H contains the formal speciﬁcation automatically generated from the SRFM (Fig-
ure 9.23 and 9.24), the reﬁned dynamic model of ENFORMS (Figure 9.25 and 9.26), and the state
diagram that synchronizes behavior of individual objects (Figure 9.32 and 9.33).

....

 

253

 

specification ENFORMS_REF [Browse, Retrieve, Analysis, Query, GetTable,
Archive_Query, Register, Archive_Query4899, Archive_Query5699]
(e: ENFORMS): noexit

(* Browse: ui: User_Input -> Retrieve_Request *)

(* ensures result = Browse (ui, getIndices(e)) *)

(* Retrieve: rr: Retrieve_Request -> Retrieve_Result *)
(* requires isValid(rr) *)

(* ensures result = Retrieve (rr, getArchives(e)) *)

(* Analysis: ar: Analysis_Request -> Analysis_Result *)
library

ENFORMS, Name_Server, Archive_Server, Client, Boolean, Channel
endlib

behavior

(Browse ? ui: User_Input;

Browse ! Browse (ui, getIndices(e));

Browse [Browse, Retrieve, Analysis, Query] (e)

l[Queryll

(Client [Query, GetTable, Archive_Query] (Client(empty))

l[GetTable,Archive_Query]I

(Name_Server [Register, GetTable] (Name_Server(empty))

l[RegisterJI

(Channe1[Archive_Query, Archive_Query4899, Archive_Query5699] (channel)

I[Archive_Query4899,Archive_Query5699]I

(Archive_Server [Archive_Query4899,Register]
(Archive_Server(pcs,pcs_db,4899))

Ill

Archive_Server [Archive_Query5699,Register]
(Archive_Server(storet, storet_db, 5699))

)))))

endspec

Figure 9.33: The automatically generated formal speciﬁcation that synchronizes the
behavior of individual objects

 

254

 

<99 aynow:~ >topo enforms -v -syntax

TOPO_3R6 (Mon Jan 23 15:19:15 NET 1995) /usr/local/LOTOS/Tools/TOPO
syntax analysis ...

lfe enforms.lot > Ta01755

mv Ta01755 enforms.lfe

<100 aynow:~ >topo enforms -v -s -1 design

TOPO_3R6 (Mon Jan 23 15:19:15 MET 1995) /usr/local/LOTOS/Tools/TOPO
semantics analysis ...

lfe enforms.lot > Ta01777

mv Ta01777 enforms.lfe

lsa -1 design -p enforms enforms.lfe

Figure 9.34: Syntax checking and semantics analysis of the reﬁned enforms formal
speciﬁcation

 

The expansion transformations provided by LOLA [84, 85, 86, 87] produces a
compressed version of an Extended Finite State Machine (EFSM) from a given LO-
TOS behavior speciﬁcation. The behavior of the generated EFSM is equivalent to the
original LOTOS speciﬁcation. The effect of an expansion is the removal of the most
complex LOTOS operations (e.g., parallel operators) from the speciﬁcation, produc-
ing an equivalent speciﬁcation in terms of action preﬁx, behavior choice, guards, and
choice, etc. This transformation can be used for state exploration, deadlock detection,
deriving efficient implementations, etc.

Because the dynamic models of the individual objects are synchronized by par-
allel operators, we can use the expansion transformation to check if the behavior of
the synchronized objects can be expressed in terms of an equivalent EFSM without
parallel operators. This transformation can be considered a static analysis of state
exploration. A deadlock detected by the transformation suggests that the behavior

of objects has a synchronization problem. Figure 9.35 shows the transcript of such

 

255
an expansion. The expansion transformation explored 191 states and generated 373
transitions. The 4 deadlocks detected by the expansion transformation suggests that
there is a problem with behavior synchronization among the communicating objects.
We need to investigate the EFSM generated by the expansion transformation to look

into the deadlock problem.

 

expand -1

Rewriting expressions in the specification.
Rewriting done.

Analysing unguarded conditions.

Analysis done.

Analysed states = 191
Generated transitions = 373
Duplicated states = 183
Deadlocks = 4

Removing Parameters.

Figure 9.35: Using expansion transformation to detect synchronization error

 

Figure 9.36 shows a part of the EFSM generated from the LOTOS speciﬁcation
given in Appendix H. The four processes in Figure 9.36 leads the behavior of the
EFSM to deadlocks. A further investigation of the four processes reveals that the
deadlocks are caused by the synchronization between the Client and Channel ob-
jects. When the Client object raises a Archive-Query service request with constant
undef_Address as the argument for Address to the Channel object, the Channel object
enters a deadlock because the dynamic model of Channel (see Figure 9.30) did not

specify how to react for address other than 4899 and 5699.

 

256

 

process duplicate3 [browse,retrieve,analysis,query,gettable,archive_query,register,
archive_query4899,archive_query5699] : noexit :=
register ! storet ! 5699;
stop
endproc
process duplicate4 [browse,retrieve,analysis,query,gettable,archive_query,register,
archive_query4899,archive_query5699] : noexit :=
register ! pcs ! 4899;
stop
endproc
process duplicate9 [browse,retrieve,analysis,query,gettable,archive_query,register,
archive_query4899,archive_query5699] (rr_92:retrieve_request) : noexit :=
archive-query ! get_query_request(rr_92) ! undef_address;
stop
endproc
process duplicate17 [browse,retrieve,analysis,query,gettab1e,archive_query,register,
archive_query4899,archive_query5699] (rr_92:retrieve_request) : noexit :=
archive_query ! get_query_request(rr_92) ! undef_address;
stop
endproc

Figure 9.36: A part of the EFSM transformed from the LOTOS speciﬁcation in
Appendix H

 

Two approaches are available to eliminate the deadlock: (1) further reﬁne the
dynamic model for the Channel object to handle Send request with addresses other
than 4899 and 5699, or (2) add a guarding condition to the dynamic model for the
Client object to ensure that the Address argument is valid before issuing the request
for the service provided by the Channel object. Since the Client object is our focus
of design, we choose the latter approach. Figure 9.37 shows a reﬁned dynamic model
for the Client object class. A guarding condition is associated with the Query service.

If the argument of sort Address is not valid, constant undef_Query_Result is returned

-1. .. .

l

 

257
to the requesting object, otherwise, the Archive-Query service of the Channel object

will be requested to pass the request to the corresponding Archive Server object.

 

 

i Client: c I
(

"Name_Server.GetTabIe()

  

Name_Server.Get able(st: Server_Table)

Query(dan: Data_Archive_Name, anuery_Request)
[not(getAddress(getTable(c),dan) eq undef_Address)]
"Archive_Server.Query(dan, getAddress(getTable(c). dan))

ow

Archive_Server.Query( qr: Query_Result)/Query (qr)

Query(dan: Data_Archive_Name. qr:Query_Request)
[getAddress(getTabIe(c).dan) eq undef_Address]
L /Query(undef_Query_Result)

 

 

Figure 9.37: The reﬁned dynamic model of Client

 

The changes made in the reﬁned dynamic model only affect the speciﬁcation of
the Idle state of Client. Figure 9.38 contains the automatically generated formal
speciﬁcation for the reﬁned Client object. The formalization rules used to generate
the formal speciﬁcation include DFR—l, DFR—Z, DFR-3, DFR—4, DFR—5, DFR-
6, DFR—7, DFR—ll, DFR—12, and DFR—13.

After the changed speciﬁcation for the modiﬁed dynamic model of the Client
object class is extended to the formal speciﬁcation in Figure 9.33, another expansion

transformation is conducted to perform a static analysis of the synchronization. The

 

258

 

process Idle [Query, Name_Server_GetTable, Archive_Server_Query]
(c: Client) : noexit :=
Query ? dan: Data_Archive_Name ? qr: Query_Request;
([getAddress(getTab1e(c),dan) eq undef-Address]
-> Query ! undef_Query_Result;
Idle [Query, Name_Server_GetTab1e, Archive_Server_Query] (c)
I]
[not(getAddress(getTable(c),dan) eq undef_Address)]
-> Archive_Server_Query ! qr ! getAddress(getTable(c), dan);
WaitQuery [Query, Name_Server_GetTable, Archive_Server_Query] (c))
endproc

Figure 9.38: The formal speciﬁcation for the reﬁned Idle state of Client

 

transcript of the expansion transformation is given in Figure 9.39. No deadlock is

detected after the behavior of the Client class is reﬁned.

 

expand -1

Rewriting expressions in the specification.
Rewriting done.

Analysing unguarded conditions.

Analysis done.

Analysed states = 205
Generated transitions = 415
Duplicated states = 211
Deadlocks = O

Removing Parameters.

Figure 9.39: The transcript of expansion transformation after the behavior of the
Client is reﬁned

 

259

9.6.3 Dynamic analysis

Figure 9.8 contains a test process that dynamically analyzes the behavior of EN-
FORMS before reﬁnement. We can check the testing equivalence [94]2 between
the behavior of EN FORMS before and after the reﬁnement by applying the given
test process to the reﬁned behavior speciﬁcation. Since new constants are intro-
duced during the reﬁnement process, the test process is also adapted to reﬂect
the change. In the test process of Figure 9.40, the two valid_Retrieve_Request
constants are substituted by retrieve_request (pcs , val id_query_request) and

retrieve_request (storet, valid_query_request).

 

process test [Browse, Retrieve, Register, GetTable, success] : noexit :=
Browse ! valid_User_Input;
Browse ? rr: Retrieve_Request;
Retrieve ! retrieve_request (pcs, valid_query_request);
Retrieve ? rr: Retrieve_Request;
([isValid(rr)] -> Browse ! valid_User_Input;
Browse ? rr: Retrieve_Result;
Retrieve ! retrieve_request (storet, valid_query_request);
Retrieve ? qr: Retrieve_Result;
([isValid(rr)] -> success; stop))
endproc

Figure 9.40: The test process for the reﬁned formal speciﬁcation of EN FORMS

 

Because this case study focuses on checking whether the objects designed in the
client-server architectural style will realize the distributed query transparently, the
services, other than Browse, Retrieve, and Analysis, through which the individual ob-

ject communicate and synchronize with each other are hidden from external access.

 

2Two processes are considered testing equivalent to each other if no difference of their behavior
can be detected from external testing.

260
This is described in terms of LOTOS gate hiding construct by hiding the correspond-
ing gates of the behavior speciﬁcation given in Figure 9.33. The modiﬁed behavior

speciﬁcation is shown in Figure 9.41.

 

behavior

hide Query, GetTable, Archive_Query, Register,
Archive_Query4899, Archive_Query5699 in
(Browse ? ui: User_Input;
Browse ! Browse (ui, getIndices(e));
Browse [Browse, Retrieve, Analysis, Query] (e)
l[Queryil
(Client [Query, GetTable, Archive_Query] (Client(empty))
I[GetTable,Archive_Query]l
(Name_Server [Register, GetTable] (Name_Server(empty))
I[Register]l
(Channe1[Archive-Query, Archive_Query4899, Archive_Query5699] (channel)
I[Archive_Query4899,Archive_Query5699]l
(Archive_Server[Archive_Query4899,Register](Archive_Server(pcs,pcs_db,4899))
Ill
Archive_Server[Archive_Query5699,Register]
(Archive_Server(storet, storet-db, 5699)))))))

Figure 9.41: Communication among individual objects are hidden

 

If the test process in Figure 9.40 can always reach the success event for the be-
havior speciﬁcation given in Figure 9.41, then we can assert that the behavior of
ENFORMS before and after reﬁnement preserve testing equivalence for the given
test. Unfortunately, the transcript generated by TestExpand in Figure 9.42 shows
that no success event is reached during the exhaustive test. Instead, 30 deadlocks are

detected and the test is rejected.

261

 

 

lola> test -1 success test -y
testexpand -1 success test -y

Composing behaviour and test :

test [browse,retrieve,register,gettable,success]
I[browse,retrieve,analysis,gettable,register]I
(hide query,gettable,archive_query,register, ‘
archive_query4899,archive_query5699 in
browse ? ui_27:user_input;

browse ! browse(ui_27,getindices(e_26)); n,
browse [browse,retrieve,analysis,query] (e_26) I.
l[queryll

client [query,gettable,archive_query] (Client(empty))
l[get-table,archive_query]l
name_server [register,gettable] (name_server(empty))
l[registerJI
channel[archive_query,archive_query4899,archive_query5699] (channel)
l[archive_query4899,archive_query5699]I
archive_server [archive_query4899,register]
(archive_server(pcs,pcs_db,4899))
Ill
archive_server [archive_query5699,register]
(archive_server(storet,storet_db,5699))

)
Analysed states = 91
Generated transitions = 90
Duplicated states ' 0
Deadlocks = 30
Process Test = test
Test result = REJECT.

successes = 0

stops = 30
exits = O
cuts by depth = 0

Figure 9.42: The test process is rejected by the reﬁned behavior speciﬁcation of
ENFORMS

 

262

Reviewing the log ﬁle generated by TestExpand reveals that the deadlock is caused
by speciﬁcation incompleteness. The SRFM in Figure 9.23 reﬁnes data sort Re-
trieve_Request in terms of Data_Archive_Name and Query_Request and introduces sort
conversion operations for Query_Result and Retrieve_Result. However, the Boolean
operation is Valid Operation for both Retrieve_Request and Retrieve_Result sorts are
not further speciﬁed to cover the newly introduced operations. In the behavior spec-
iﬁcation, the is Valid operation of Retrieve_Request is used in Client to check if the
input is valid. In the test process the is Valid of Retrieve_Result is issued to check
whether the returned result is valid. Therefore, the less speciﬁed Boolean operations
result in deadlocks during the execution of TestExpand. The operations and equa-
tions are added to the algebraic speciﬁcation of the reﬁned ENFORMS to cover the
data reﬁnement of Figure 9.23. The speciﬁcation in Figure 9.43 shows the added

operations and equations.

 

type ENFORMS_REF is ENFORMS, Name_Server, Archive-Server, Client, Channel
opns
isValid : Data_Archive_Name -> Bool
isValid : Query_Result -> 8001
eqns
forall qr: Query_Request, dan: Data_Archive_Name, qu: Query_Result
isValid (qr) = not(qr eq undef_Query-Request);
isValid (dan) = not(dan eq undef_Data_Archive_Name);
isValid (Retrieve_Request(dan, qr)) = isValid (dan) and isValid (qr);
isValid (qr1) = not (qr1 eq undef_Query_Result);
isValid (Query_Result2Retrieve_Resu1t(qr1)) = isValid(qu);

endtype

Figure 9.43: The added operations and equations that are resulted by the SRF M of
Figure 9.23

 

 

“ﬂ
J

‘t— ....x ...—..—

 

263
After adding the necessary Operations and equations into the reﬁned algebraic
speciﬁcation of ENFORMS, another round of exhaustive testing is executed. The
transcript of the test is shown in Figure 9.44. Fortunately, there are two execution
paths that led to the success event during the exhaustive exploration test. However,
the 80 deadlocks detected by the test are still discouraging. A further analysis is

necessary in order to determine the cause of the deadlocks.

 

lola> test -1 success test -y
testexpand -1 success test -s -y

Rewriting expressions in the specification.
Rewriting done.

Analysing unguarded conditions.

Analysis done.

Composing behaviour and test :

Analysed states = 293
Generated transitions 294
Duplicated states
Deadlocks = 80

II
0

test
MAY PASS.

Process Test
Test result

82 executions analysed:

I
I0

successes -
stops -

exits

cuts by depth

IIIII
0000
0

Figure 9.44: The transcript of TestExpand test after necessary operations and equa-
tions are added

 

ENFORMS is designed in terms of a client-server architectural style that reﬂects

and utilizes the distributed nature of the system. The execution of the ENFORMS

264

system is initiated by activating the name server. The archive servers are then typ-
ically activated, followed by any number of clients, although the system does not
preclude the possibility of activating the clients before the archive servers. There-
fore, it is very likely that a client starts and accepts a service request before the
corresponding archive server is ready to serve. Under this circumstance, the client
is not able to return a valid query result. Our investigation of the log ﬁle generated
by TestExpand identiﬁes a large number of these cases that have led to deadlocks.
However, under some circumstances, even when the two Archive_Server objects are
started and registered before the Client object accepts a Query request, deadlock still
appears. A stepwise interactive simulation that recovers the path to deadlock reveals
that the deadlock is caused by the current design that the Client object only acquires
a Server_T able during its initialization time but not afterwards. If the following se-

quence of events occurs, a deadlock will be produced.

1. The Client object starts and acquires an empty server table from the
Name-Server object.
2. The two Archive_Server objects are started and registered.

3. The Client object accepts a Query request from the test process.

4. The Client returns constant undef_Query_Result because there is no available
archive server.

5. The returned result leads the test process into a deadlock.

The above analysis indicates that a copy of an obsolete server table possessed by
the Client object will fail the test. There are many means of design that can handle
this problem in the context of a distributed system. The straightforward but not

necessarily optimal approach used in the case study is to let the Client object acquire

 

 

265
a copy of an up—to-date server table from the Name Sever object before it attempts
to request services from Archive_Server objects. The reﬁned dynamic model for the
Client object class is given in Figure 9.45. The formalization rules used to generate
the formal speciﬁcation include DFR—l, DFR—2, DFR—3, DFR-4, DFR—S, DFR-

6, DFR-7, DFR—ll, DFR—lZ, and DFR-13.

 

I Client: c I

F \

hamgServcr GetTablcO

Name_ServerGet ablet st: Server_Table)

Query(dan: Data_Archive_Name. qr:Query_Request)
AI‘lathScrvcr.Gv:tTable()

 
  
  

Name_ServerGetTablet st: Server_Table)
I getAddress(st.dan) eq undef_Address]
/ Query(undef_Qucry_Result)

    
   
  

Name_ServerGet 'able( st: Server_Table)
[not(getAddres Ldan) eq undef_Address)]

A’Chivc-Semr‘oucmqr Query-Resuwo' 0' (qr) "Arcluve Sev erQuctymr getAddress(st. dam)

 

 

Figure 9.45: The further reﬁned dynamic model of Client

 

In the reﬁned dynamic model, a new state, WaitTable, with associated transitions
are introduced, and the transition that leaves from Idle state given a Query service re-
quest is modiﬁed. The formal speciﬁcation automatically generated from the changed
parts of the dynamic model is given in Figure 9.46.

Figure 9.47 shows the execution of the TestExpand after the design of the Client

object class is reﬁned. In all, there are 802 states analyzed and 913 transitions

266

 

process Idle [Query, Name_Server_GetTable, Archive_Server_Query]
(c: Client) : noexit :=
Query ? dan: Data_Archive_Name ? qr: Query_Request;
Name_Server-GetTable;
HaitTable [Query, Name_Server_GetTable, Archive_Server_Query] (c, qr, dan)
endproc

process WaitTable [Query, Name_Server_GetTable, Archive_Server_Query]
(c: Client, qr: Query_Request, dan: Data_Archive_Name) : noexit :=
Name_Server_GetTable ? st: Server_Table;
([getAddress(st,dan) eq undef_Address] ->

Query ! undef_Query_Result;
Idle [Query, Name_Server_GetTable, Archive_Server_Query] (c)
[]
[not(getAddress(st,dan) eq undef_Address)] -> h;
Archive_Server_Query ! qr ! getAddress(st, dan);
HaitQuery [Query, Name_Server_GetTable, Archive_Server_Query] (c))
endproc

Figure 9.46: The formal speciﬁcation for the reﬁned Idle state of Client

 

generated during the exhaustive test. Among the 160 execution paths, 112 reach the
success event, 48 result in deadlock. The designed ENFORMS system may pass the
test process given in Figure 9.40.

Our further study shows that all 48 deadlocks can be attributed to the nature
of distributed components. That is, the client cannot be guaranteed that all archive
servers will be active upon enter into EN FORMS. In this context, we can assert that
the client-server design of ENFORMS realizes the retrieve function over a distributed

data archives transparently.

h.

267

 

 

lola> test -1 success test -y
testexpand -1 success test -s -y

Rewriting expressions in the specification.
Rewriting done.

Analysing unguarded conditions.

Analysis done.

Composing behaviour and test :

Analysed states = 802

Generated transitions = 913

Duplicated states = 0 I
Deadlocks = 48 :n.

Process Test = test
Test result = MAY PASS.

160 executions analysed:

successes = 112

stops = 48
exits = O
cuts by depth = 0

Figure 9.47: The result of TestExpand after the behavior of the Client object class is
reﬁned

 

9.7 Summary

In this chapter, through the application of the design process and the formalization

 

rules to a portion of ENFORMS, we have determined the following:

o The formalization and integration rules for OMT models can help the designers
to derive more precise and integrated descriptions of design.

0 The proposed design process facilitates the reﬁnement of design.

0 Based on the formal speciﬁcations derived from OMT models, analysis can
be performed to check design consistency and to facilitate understanding and
communication about the design.

268

Four problems were detected during the reﬁnement process through various anal-
ysis techniques:

0 An underlying communication mechanism between clients and servers is as-
sumed in the system design. However, this assumed support was not modeled
in the design, and resulted in nondeterminism during the communication be-
tween clients and servers.

0 A Client object may issue invalid requests to Archive_Servers and result in
deadlock condition.

 

0 Data reﬁnement in the SRF M of EN FORMS brought in incompleteness to
algebraic speciﬁcation. The corresponding operations in the algebraic speciﬁ-
cations are obligated to be further reﬁned.

-. : ...-...“-
e ‘1
4 I
I
A
.-

0 An obsolete copy of a server table held by the Client object will cause a deadlock
condition.

 

Chapter 10

Conclusions and Future

Investigations

Formal speciﬁcations are gaining increasing attention as a means to rigorously doc-
ument requirements and design information since the well-deﬁned notations are
amenable to automated processing for numerous analysis tasks [2], including veri-
ﬁcation of the correctness of resulting systems. However, attempting to construct a
formal speciﬁcation directly from an informal, high-level requirements document can
be challenging. Formal descriptions potentially involve considerable syntactic details
and may require careful planning and organization on the part of the speciﬁer in order
to develOp modular speciﬁcations.

A complementary approach to describing requirements is the use of graphical
modeling notations. The intuitive diagrammatic notations are easy to understand
and facilitate model construction. However, the lack of formal semantics of graphical

notations deprives designers of analysis techniques that can help designers to de-

269

270
tect and eliminate design errors during the early stages of the software deveIOpment
process.

In order to take advantages of both the intuitive diagrammatic and rigorous formal
techniques, the integration of the two approaches is clearly motivated. Therefore, the
major motivation for our research was to provide developers with a means to take
advantage of the beneﬁts of an easy to use, graphical-based modeling approach with
the advantages afforded by formal approaches to software development, all within the
context of facilitating technology transfer [113].

In this dissertation, we reﬁned and introduced formalisms to the three comple-
mentary OMT models: object, functional, and dynamic models. An integration of the
three models is achieved in terms of the underlying formal semantics. Based upon the
formalization and integration, rigorous analyses can be applied to the formal speciﬁ-
cations to perform speciﬁcation analysis. In addition, a design process that employs
the formalization, integration, and analysis techniques is prOposed. A case study that
applied the proposed formalization rules and design process to an industrial project

is also discussed.

10.1 Summary of Contributions

There are three primary objectives for this research.

0 Improve and facilitate the software development process for software engineers,
with particular emphasis on the early stages of software development.

0 Provide a modeling and speciﬁcation technique that integrates informal and
formal techniques, thereby enabling rigorous analyses in the early stages of
development.

271

o Exploit and integrate existing formal methods technologies.

In order to help practicing software engineers, we solicited input from numerous
industrial organizations and contacts to determine what graphical, object-oriented
modeling techniques were commonly used. OMT was determined to be one of the
most widely used object-oriented modeling techniques, but it suffered from a lack
of ability on the part of software developers to determine ambiguity and incom-
pleteness problems in the early stages of development. In addition, OMT contains
simple, graphical models that are also used by other object-oriented modeling nota-
tions. Therefore, another advantage of this research is that any formalizations that
we develop are not speciﬁc to OMT.

Accordingly, the main objective of the formalization rules is to (1) introduce for-
mal semantics to the graphical notations, and (2) integrate the models in terms of the
underlying formal semantics. These rules also make the models amenable to auto-
matic formal speciﬁcation generation. Given an integrated, single formal speciﬁcation
for each object, automated speciﬁcation analysis can be performed.

From the formal methods community, we identiﬁed Larch and LOTOS to be com-
monly used speciﬁcation languages with rich tool support. In addition, the approach
proposed by Larch to describe design entities in terms of a two-tiered language is
also incorporated in the formal speciﬁcation technique of this research. The large
number of available LOTOS tools greatly enhance the analyses applicable to the for-
mal speciﬁcations. The currently available speciﬁcation analysis techniques include

(1) consistency checking among the three models of a single object, (2) behavior

 

 

 

272
simulation and analysis for single objects, (3) synchronization analysis for multiple
communicating objects, and (4) speciﬁcation simulation and debugging for commu-
nicating objects.

The contribution of this dissertation research is four-fold.

o Formalization of Dynamic Model.

Nineteen formalization rules have been developed to formalize the dynamic
models in terms of LOTOS process algebra speciﬁcations. The formalization of
the state diagrams is deﬁned within the context of the object model formaliza-
tion [27]. The formalization enables the precise speciﬁcation of the behavior of
objects and the simulation of system behavior through executable speciﬁcations.

0 Formalization of Functional Model.

Two functional models, Object Functional Model (OFM) and Service Reﬁne-
ment Functional Model (SRFM), are introduced in order to integrate the func-
tional models into ob ject-oriented technology. Two guidelines for deriving alge-
braic speciﬁcations are given. Sixteen formalization rules have been introduced
to formalize the functional models in terms of algebraic and predicate speci-
ﬁcations. The pre— and postconditions of services enable symbolic execution
of the high-level design model thus providing a means to perform simulation,
veriﬁcation, and validation during the early phases of software development.

0 Integration of the Three Complementary Models.

The integration of the three complementary models is three-fold. First, the func-
tional and dynamic models are derived in the context of object models. Third,
the integration is achieved by composing the dynamic models and SRFMS hier-
archically according to the system structure speciﬁed in the object model. The
integration and formalization of the three models enable designers to perform
analysis tasks by using the derived formal speciﬁcations.

0 Process for Model Construction, Speciﬁcation, and Reﬁnement.

A design process has been developed to facilitate the deveIOpment of formal
design speciﬁcations in parallel with the development of OMT’s semi-formal,
graphical models. The rigorous mathematical foundation of formal speciﬁca-
tions provides a more precise means to describe the design thus avoiding ambi-
guities. The symbolic execution of the design speciﬁcations can help designers
better understand the design as well as facilitate the communication among
designers and even with the customers. Speciﬁcation analysis can be performed
during model reﬁnement of the design process to detect and eliminate design
ﬂaws during earlier stages of software development.

273

10.2 Impact of Research and Future Investigations

The formal description technique of this research is unique. It provides a means to
use an integrated, single formal speciﬁcation framework to describe different aspects
of an object, yet the descriptions of the diﬂ'erent aspects are integrated rather than
isolated. The graphical front-end (that is, the OMT models) of the technique makes
it more user-friendly and easy to use for general software designers. The proposed
design process provides a guideline for designers to systematically utilize this formal
technique during the design phase in a stepwise, incremental fashion. The speciﬁ-
cation analysis enabled by the formal technique can help designers to detect design
ﬂaws during earlier stages of software development. Although OMT was chosen as
the graphical front-end, this back-end formal technique can also be applied to other
graphical notations with some straightforward modiﬁcations.

Several avenues of research appear promising for future investigations.

0 UML has been adopted as a standard notation for object-oriented modeling [43,
44, 45, 46]. Given the fact that OMT is one of the original graphical notations
from which UML evolve, our back-end formal technique can be directly extended
to UML notation. However, in UML, the services and functionalities are not
explicitly modeled, no counterparts for OF Ms and SRFMS of our notations are

identiﬁed. More effort is necessary to address this issue.

0 The results of the case study performed in this dissertation are quite encourag-

ing. Four design ﬂaws were detected by the formal technique in our case study.

 

 

274

However, in order to gain more empirical experience and to reﬁne and ﬁne tune

the proposed techniques, more case studies should be conducted.

The research focused on applying formal techniques during the design phase
of software development. Given that the Larch LIL is speciﬁc to programming
languages and LOTOS can produce prototype source code in C and Ada, the
research investigations can be extended to the implementation phase. Based on
the framework of the current formal techniques, automatic or semi-automatic,
computer assisted source code generation is a potentially promising research

topic.

Before the proposed technique can be accessible to general software developers,
tools that support graphical model construction, formal speciﬁcation genera-
tion, and corresponding maintenance facilities must be developed ﬁrst. Without
tool support, the advantages of the techniques will be more difﬁcult to exploit.
The case study required the manual generation of all of the formal speciﬁcations

according to proposed rules, an extremely tedious and cumbersome endeavor.

The description of the signatures and pre- and postconditions of services pro-
vided by objects is not directly supported by LOT OS. Thus the descriptions,
originated from Larch’s LIL technique, are enclosed as annotations currently.
In order to fully exploit our formal technique, it is necessary to extend LOTOS
to include facilities with the similar expressiveness of Larch’s LIL language.
The recently proposed ELOTOS [80] has stronger expressiveness power, further

research is also needed to investigate how to use ELOTOS in our formal descrip-

 

..-x._-.—_._...—
a;

 

275
tions. However, the drawback is that currently there is limited tool support for

ELOTOS.

Although intuitive graphical notations are used to develop the formal models,
the textual presentation of the results of formal analysis may be difﬁcult for
most designer with limited background in mathematics and formal methods.
Further research and investigation on how to visually present the results of the

formal analysis in an intuitive fashion is necessary.

Although speciﬁcation and modeling errors can be relatively easy to detect
with existing tools, the current tool support of LOTOS does not have a friendly
environment for speciﬁcation debugging. Better tool support for debugging is
also desirable to facilitate a designer’s ability to identify and locate the cause

of design errors.

BIBLIOGRAPHY

 

Bibliography

[1] W. W. Gibbs, “Software’s chronic crisis,” Scientiﬁc American, pp. 86—95,
September 1994.

 

‘3'
I

[2] J. M. Wing, “A Speciﬁer’s Introduction to Formal Methods,” IEEE Computer,
vol. 23, pp. 8—24, September 1990.

- .‘z-

[3] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, Object-
Oriented Modeling and Design. Englewood Cliffs, New Jersey: Prentice Hall,
1991.

[4] J. D. Ullman, Principles of Database Systems. Computer Science Press, 1983.

[5] M. D. Fraser, K. Kumar, and V. K. Vaishnavi, “Strategies for incorporating
formal speciﬁcations,” Communications of the ACM, pp. 74—86, October 1994.

 

[6] R. S. Pressman, Software Engineering: A Practitioner’s Approach. McGraw
Hill, fourth ed., 1997.

[7] D. Coleman, P. Arnold, S. Bodoff, C. Dollin, H. Gilchrist, F. Hayes, and P. Jere-
maes, Object-Oriented Development, The Fusion Method. Object-Oriented Se-
ries, Prentice Hall, 1 ed., 1994.

[8] D. Harel, A. Pneuli, J. P. Schmidt, and R. Sherman, “On the formal semantics of
statecharts,” in Proceedings of the 2nd IEEE' symposium on Logic in Computer
Science, pp. 54—64, 1987.

[9] J. V. Guttag and J. J. Horing, Larch: Language and Tools for Formal Speciﬁ-
cation. New York, New York: Springer—Verlag, 1993.

 

[10] S. Garland and J. Guttag, “A guide to LP, the Larch prover,” Technical Report
TR 82, DEC SRC, December 1991.

[11] P. van Eijk, “The design of a simulator tool,” in The Formal Description Tech-
nique LOT OS (P. van Eijk, C. Vissers, and M. Diaz, eds.), pp. 351~390, Elsevier
Science Publishers B.V., 1989.

[12] A. Fantechi, S. Gnesi, and C. Laneve, “An expressive temporal logic for basic
LOTOS,” in Formal Description Techniques, II (S. Vuong, ed.), pp. 261—276,
Elsevier Science Publishers B.V., 1990.

276

277

[13] C. B. Jones, Systematic Software Development Using VDM. Prentice Hall In-
ternational Series in Computer Science, Prentice Hall International (UK) Ltd.,
second ed., 1990.

[14] J. Wing, “Role of formal speciﬁcations (discussion group symmary in NRL
invitational workshop on testing and proving, 1986),” vol. 11, pp. 65—67, Oct.
1986.

[15] D. Gries, The Science of Programming. Springer-Verlag, 1981.

[16] J. Bergstra, J. Heering, and P. Klint, Algebraic Speciﬁcation. Addison Wesley,
1989.

[17] S. F ickas, “Automating the transformational development of software,” IEEE
Transactions on Software Engineering, vol. SE-ll, pp. 1268—1277, November
1985.

[18] J. Stoy, The Scott-Strachey Approach to Programming, ch. Denotational Seman-
tics. Cambridge: MIT Press, 1977.

[19] J. V. Guttag, J. J. Horning, K. J. S.J. Garland, A. Modet, and J. Wing, Larch:
Languages and tools for formal speciﬁcation. Texts and Monographs in Com-
puter Science, Springer-Verlag, 1993.

[20] J. Guttag and J. Horning, “Introduction to LCL, a Larch / C interface language,”
tech. rep., Digital Equipment Corporation, Systems Research Center, July 29
1991.

[21] T. Bolognesi and E. Brinksma, “Introduction to the ISO speciﬁcation language
LOTOS,” in The Formal Description Technique LOTOS (P. H. J. V. Eijk, C. A.
Vissers, and M. Diaz, eds), pp. 23—73, North-Holland, 1989.

[22] R. Milner, “A calculus of communicating systems,” in Lecture Notes in Com-
puter Science 92, Springer-Verlag, 1980.

[23] C. Hoare, Communicating Sequential Processes. Englewood Cliffs, New Jersey:
Prentice Hall International, 1985.

[24] J. Bergstra and J. W. Klop, “Process algebra for synchronous communication,”
in Information and Control 60, pp. 109—137, 1984.

[25] K. J. Turner, ed., Using Formal Description Techniques — An Introduction to
ESTELLE, LOT OS, and SDL. Wiley, 1993.

[26] H. Ehrig and B. Mahr, Fundamentals of Algebraic Speciﬁcation. Berlin:
Springer-Verlag, 1985.

[27] R. H. Bourdeau and B. H. C. Cheng, “A formal semantics of object models,”
IEEE Transactions on Software Engineering, vol. 21, pp. 799—821, October
1995.

l

 

278

[28] M. Wirsing, “Algebraic speciﬁcation,” in Handbook of Theoretical Computer
Science (J. van Leeuwen, ed.), ch. 13, Amsterdam: Elsevier Science Publishers
and MIT Press, 1990.

[29] B. H. C. Cheng, E. Y. Wang, and R. H. Bourdeau, “A graphical environment
for formally developing object-oriented software,” in Proc. of IEEE 6th Inter-
national Conference on Tools with Artiﬁcial Intelligence, November 1994.

[30] R. Jungclaus, G. Saake, T. Hartmann, and C. Sernadas, “TROLL—a language
for object-oriented speciﬁcation of information systems,” ACM Transactions on
Information Systems, 1996.

[31] A. M. D. Moreira, Rigorous Object-Oriented Analysis. PhD thesis, Department
of Computing Science and Mathematics, University of Stirling, August 1994.

[32] R. Jungclaus, “Modeling of dynamic object systems -— a logic-based approach,”
in Advanced Studies in Computer Science, Vieweg Verlag, 1993.

[33] H. Ehrig and B. Maher, Fundamentals of Algebraic Speciﬁcation 1: Equations
and Initial Semantics. Springer-Verlag, 1985. '

[34] C. Hoare, “Communicating sequential processes,” Communications of the ACM,
pp. 666—677, August 1978.

[35] R. Milner, A Calculus of Communicating Systems. Springer-Verlag, 1990.

[36] E. A. Emerson, “Temporal and model logic,” in Formal Models and Semantics
(J. van Leeuwen, ed.), pp. ”995—1072”, Elsevier Science Publishers BB, 1990.

[37] G. Engles, M. Gogolla, U. Hohenstein, K. Hulsmann, R. Lohr-Richter, G. Saake,
and H. E. Ehrich, “Conceptual modeling of database applications using an
extended ER model,” Data Knowledge Engineering, vol. 9, no. 2, pp. ”157—
204”, 1992.

[38] A. M. D. Moreira and R. G. Clark, “Rigorous object-oriented analysis,,”
in International Symposium on Object-Oriented Methodologies and Systems
(ISOOMS), pp. 65-78, Springer-Verlag, September 1994.

[39] A. M. D. Moreira and R. G. Clark, “Adding rigour to object-oriented analysis,”
Software Engineering Journal, vol. 11, no. 5, pp. 270-280, 1996.

[40] P. Coad and E. Yourdon, Object-Oriented Analysis. Englewood, New Jersey:
Yourdon Press, Prentice Hall, 1990.

[41] G. Booch, Object-oriented Design with Applications. Redwood City, California:
Benjamin/Cummings Pub. Co., 1991.

[42] K. Beck and W. Cunningham, “A laboratory for teaching object-oriented think-
ing,” in ACM OOPSLA ’89 Conference Proceedings, 1989.

‘A ‘-‘_ 53‘! ‘5‘;

 

279

[43] Rational Software Corporation, 2800 San Tomas Expressway, Santa Clara, CA
95051-0951, UML Summary, 1.1 ed., September 1997.

[44] Rational Software Corporation, 2800 San Tomas Expressway, Santa Clara, CA
95051-0951, UML Semantics, 1.1 ed., September 1997.

[45] Rational Software Corporation, 2800 San Tomas Expressway, Santa Clara, CA
95051-0951, Notation Guide, 1.1 ed., September 1997.

[46] M. Fowler and K. Scott, UML Distilled: Applying the Standard Object Modeling
Language. Addison-Wesley, 1997.

[47] Rational Software Corporation, 2800 San Tomas Expressway, Santa Clara, CA
95051—0951, Object Constraint Language Speciﬁcation, 1.1 ed., September 1997.

[48] Rational Software Corporation, 2800 San Tomas Expressway, Santa Clara,
CA 95051-0951, Rational Objectory Process 4.1 - The UML Process, 4.1 ed.,
September 1997.

[49] G. Booch, Object-Oriented Analysis and Design with Applications. The Ben-
jamin/ Cummings Publishing Company, Inc., second ed., 1994.

[50] I. Jacobson, Object-Oriented Software Engineering: A Use Case Driven Ap-
proach. Addison-Wesley, 1994.

[51] B. Selic, G. Gullekson, and P. T. Ward, Real- Time Object-Oriented Modeling.
Wiley professional computing, New York: Wiley & Sons, 1994. 525p.

[52] B. Selic, G. Gullekson, J. McGee, and I. Engelberg, “ROOM: An object-oriented
methodology for developing real-time systems,” in Proceedings of the Fifth
International Workshop on Computer-Aided Software Engineering (G. Forte,
N. H. Madhavji, and H. A. Muller, eds), (10662 Los Vaqueros Circle, PO Box
3014, Los Alamitos, CA 90720—1264), pp. 230—240, IEEE, IEEE Computer So-
ciety Press, July 1992.

[53] F. Polack, M. Whiston, and K. Mander, “The SAZ project: Integrating SSADM
and Z,” in First International Symposium of Formal Methods Europe (J. Wood-
cock and P. Larsen, eds.), (Denmark), pp. 540—557, Springer-Verlag, April 1993.

[54] L. Semmens and P. Allen, “Using Yourdon and Z: an approach to formal spec-
iﬁcation,” in Proc. of Fifth Annual Z user Group Meeting, (Oxford), Springer-
Verlag, December 1991.

[55] R. B. France, “Semantically extended data ﬂow diagrams: A formal speciﬁca-
tion tool,” IEEE Transactions on Software Engineering, vol. 18, pp. 329—346,
April 1992.

[56] E. Astesiano, A. Giovini, and G. Reggio, “Data in a concurrent environment,” in
International Conference on Concurrency, (New York), Springer-Verlag, 1988.

 

280

[57] E. Astesiano and G. Reggio, “SMoLCS-driven concurrent calculi,” in TAP-
SOFT ’87, (New York), Springer-Verlag, 1987.

[58] P. Lucas, “VDM: Origins, hopes, and achievements,” in VDM-Europe Sympo-
sium 1987: A Formal Method at Work (D. Bjorner, C. Jones, M. M. an Airchin-
nigh, and E. Neuhold, eds), pp. 1—18, March 1987.

[59] C. B. Jones, Systematic Software Development using VDM. Prentice Hall, 1990.
[60] E. W. Dijkstra, A Descipline of Programming. Prentice-Hall, 1976.

[61] R. J. R. Back, Correctness Preserving Program Reﬁnements: Proof Theory and
Applications. Mathematical Centre, 1980.

[62] E. Y. Wang, H. A. Richter, and B. H. C. Cheng, “Formalizing and integrating
the dynamic model within OMT,” in IEEE Proceedings of the 19th International
Conference on Software Engineering, (Boston, MA), pp. 45—55, IEEE, May
1997.

[63] E. Y. Wang, H. A. Richter, and B. H. C. Cheng, “Formalizing and integrat-
ing the dynamic model within OMT,” Tech. Rep. MSU-CPS-96-13, Michigan
State University, March 1996. Submitted to IEEE Transactions of Software
Engineering, under revision.

[64] A. Azcorra, J. Quemada, and J. Mafias, “LOTOS tool survey.”

[65] P. van Eijk, “Tools for LOTOS speciﬁcation style transformation,” in Formal
Description Techniques, 11 (S. Vuong, ed.), pp. 43—51, Elsevier Science Publish-
ers B.V., 1990.

[66] J. A. Maﬁas, T. de Miguel, J. Salvachlia, and A. Azcorra, “Tool support to
implement LOTOS formal speciﬁcations,” Computer Networks and ISDN Sys-
tems, vol. 25, pp. 815-839, 1993.

[67] D. Hare], “Statecharts: A visual formalism for complex systems,” Science of
Computer Programming, vol. 8, pp. 231-274, July 1987.

[68] N. G. Leveson, M. E. Heimdahl, H. Hildreth, and J. D. Reese, “Requirements
speciﬁcation for process-control systems,” IEEE Transactions on Software En-

gineering, vol. 20, pp. 684-707, September 1994.

[69] Rational Software Corporation, Santa Clara, CA 95051-0951, UML Notation
Guide, 1.0 ed., January 1997.

[70] Rational Software Corporation, Santa Clara, CA 95051-0951, UML Semantics,
1.0 ed., January 1997.

[71] W. P. Stevens, G. J. Myers, and L. L. Constantine, “Structed design,” IBM
Systems Journal, vol. 13, no. 2, pp. 115—139, 1974.

 

281

[7 2] E. N. Yourdon and L. L. Constantine, Structured Design. Yourdon Press, 1978.

[73] G. Booch, “What is and what isn’t object-oriented design?,” American Pro-
grammer, vol. 2, no. 7-8, pp. 14-21, 1989.

[74] D. D. Champeaux, “Object-oriented analysis and top-down software develop-
ment,” in European Conference Object-Oriented Programming, Lecture Notes
in Computer Science, pp. 360-376, Springer-Verlag, 1991.

[75] E. Y. Wang and B. H. C. Cheng, “Formalizing and integrating the functional
model into object-oriented design,” in Tenth International Conference on Soft-
ware Engineering and Knowledge Engineering, (San Francisco Bay, USA), June
1998.

[76] P. Ward and S. Mellor, Structured Development for Real— Time Systems. New
York: Yourdon Press, 1985.

[77] D. Hatley and I. Pirbhai, Strategies for Real Time System Speciﬁcation. New
York: Dorset House Publishing, 1987.

[78] D. E. Monarchi and G. I. Puhr, “A research typology for object-oriented analysis
and design,” Communications of the ACM, vol. 35, pp. 35—47, September 1992.

[79] R. G. Fichman and C. F. Kemerer, “Object-oriented and conventional analysis
and design methodologies,” IEEEE Computer, pp. 22—39, October 1992.

[80] E. ot LOTOS, “Working draft on enhancements to LOTOS.” Source: ISO / IEC
JTCl/SC21/WG7.

[81] N. Shankar, S. Owre, and J. Rushby, “The PVS proof checker,” reference man-
ual, March 1993.

[82] A. Azcorra, J. Quemada, and J. Manas, “LOTOS tool survey,” Tech. Rep.
R/1.2.3-UPM/1, ETSI Telecomunicacion Ciudad Universitaria s/n, E-28040
Madcid, Spain, 1991.

[83] J. A. Maﬁas, T. de Miguel, T. Robles, J. Salvachua, G. Huecas, and M. Veiga,
“TOPO: Quick reference: Front-end — version 3R1.”

[84] J. Q. Vives, S. P. GOmez, and D. L. LOpez, “LOLA: Quick reference version
3R6.”

[85] J. quemada, A. Fernandez, and J. A. Manas, “LOLA: Design and veriﬁcation of
protocols using LOTOS,” in IBERIAN Conference on Data Communications,
(Lisbon), May 1987.

[86] J. Quemada, S. Pavon, and A. Fernandez, “State exploration by transformation
with LOLA,” in Workshop on Automatic Veriﬁcation Methods for Finite State
Sy stems, (Grenoble), June 1989.

l‘“-"“'“"‘_‘—.~
- ‘ =I

 

 

 

 

282

[87] S. Pavon and M. Llamas, “The testing functionalities of LOLA,” in Formal De-
scription Techniques (J. Quemada, J. A. Manas, and E. Vazquez, eds), vol. III,
pp. 559—562, IF IP, Elsevier Science B.V. (North-Holland), 1991.

[88] H. Eertink, SMILE User Manual. University of Twente, Department of Com-
puter Science and Department of Electrical Engineering, P. O. Box 217, 7500
AE Enschede, The Netherlands.

[89] P. van Eijk and H. Eertink, “Desing of the LotosSphere symblic LOTOS simu-
lator,” in Formal Description Techniques (E. V. J. Quemada and J. A. Manas,
eds), pp. 577—580, Madrid, Spain: IF IP, North-Holland, 1990.

[90] T. L. Group, XEL UDO User Manual. The LOTOS group, University of Ottawa,
January 1994.

[91] J. E. Hopcroft and J. D. Ullman, Introduction to Automate Theory, Languages,
and Computation. Addison-Wesley, 1979.

[92] T. Bolognesi and M. Caneve, “Equivalence veriﬁcation: Theory, algorithems
and a tool,” in The Formal Description Technique LOTOS (P. van Eijk, C. Vis-
sers, and M. Diaz, eds), pp. 303—326, Elsevier Science Publishers B.V., 1989.

[93] E. Brinksma, “A theory for the derivation of tests,” in The Formal Description
Technique LOTOS (P. van Eijk, C. Vissers, and M. Diaz, eds), pp. 235—248,
Elsevier Science Publishers B.V., 1989.

[94] R. de Nicola and M. Hennessy, “Testing equivalences for processes,” Theoretical
Computer Science, vol. 34, pp. 83—133, November 1984.

[95] E. S. Taylor, Interim Report On Engineering Design. Massachusetts Institute
of Technology, 1953.

[96] B. Myers, Composite Structured Design. Van Nostrand, 1978.

[97] S. A. Dart, R. J. Ellison, P. H. Feiler, and A. N. Habermann, “Software devel-
opment environment,” IEEE Computer, pp. 18—28, Novemember 1987.

[98] J. N. Brinkkemper, Formalization of Information Systems Modelling. PhD the-
sis, Katholieke Universiteit te Nijmegen, June 1990.

[99] S. R. Schach, Software Engineering. Richard D. Irwin Inc. and Aksen Associates
Inc., 1990.

[100] D. Garlan and D. Perry, “Introduction to the special issue on software archi-
tecture,” IEEE Transaction on Software Engineering, vol. 21, April 1995.

[101] D. C. Luckham, J. Vera, and S. Meldal, “Three concepts of system architec-
ture,” Tech. Rep. CSL-TR-95-674, Stanford University, Computer Science De-
partment, July 1995.

 

 

283

[102] M. Shaw, R. DeLine, and G. Zelenik, “Abstractions and implementations for
architectural connections,” in Proc. 3rd Intl. Conf. on Conﬁgurable Distributed
Systems, 1996.

[103] D. Garlan, R. Allen, and J. Ockerbloom, “Architectural mismatch: Why reuse
is so hard,” IEEE Software, vol. 12, pp. 17—26, November 1995.

[104] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Pattern. Addison
Wesley, 1994.

[105] B. H. C. Cheng, Y. Chen, G. C. Gannod, W. McUmber, and E. Y. Wang,
“Discussion of architecture style.” Private communication, April 1995.

[106] I. Kant, Critique of Pure Reason. Hackett, Indianapolis, IN., 1996.

[107] R. H. Bourdeau, B. H. C. Cheng, and B. Pijanowski, “A regional information
system for environmental data analysis,” Photogrammetric Engineering 63 Re-
mote Sensing, vol. 62, July 1996. Special issue on “Remote Sensing and Global
Environmental Change”.

[108] R. H. Bourdeau, B. Pijanowski, and B. H. C. Cheng, “A decision support system
for regional environmental analysis,” in Proc. of 25th International Symposium
on Remote Sensing and Global Environmental Change: Tools for Sustainable

Development (Vol. II), (Graz, Austria), pp. 223—233, 1993.

[109] Great Lakes Committee, “Keeping it on the land: improving Great Lakes
water quality by controlling soil erosion and sedimentation,” The Aduisor,
vol. June/July, 1992.

[110] B. H. C. Cheng, R. H. Bourdeau, and G. C. Gannod, “The object-oriented
development of a distributed multimedia environmental information system,”
in Proc. of IEEE 6th International Conference on Software Engineering and
Knowledge Engineering, pp. 70-77, June 1994.

[111] J. L. Sharnowski, G. C. Gannod, and B. H. C. Cheng, “A distributed multi-
media environmental information system,” in Proc. of IEEE Int. Conference
on Multimedia and Computing Systems, (Washington, DC), pp. 142-194, May
1995.

[112] R. H. Bourdeau, B. H. C. Cheng, and G. C. Gannod, “A requirements analysis
report for a regional decision support system,” Technical Report MSU-CPS-94—
70, Michigan State University, Department of Computer Science, A714 Wells
Hall, East Lansing, 48824, November 1994.

[113] D. Craigen, S. Gerhart, and T. Ralston, “Formal methods reality check: Indus-
trial usage,” IEEE Transactions on Software Engineering, vol. 21, pp. 90—98,
February 1995.

 

APPENDICES

 

f1

 

Appendix A

The Object Model Formalization
Rules

The formalization rules for the object model are given in this Appendix.
Deﬁnition (Semantics of object models) :

Let 0 be an object model. Let R be a binary association in 0 relating objects from

classes D1 and D2. The semantics of O is an algebraic speciﬁcation satisfying the

following data.

(0M1) Each class C in the object model (9 is denoted by a sort of the same name.
(0M2) For each class C, a sort C-S TA TES is introduced as well as two nullary functions given by

undefC : —-> C-STATES , errc : —> C .

(0M3) Each object-state s, for which a double—headed arrow leads from a class C to the oval
containing 3, is denoted by a function with signature 3 : -) C-STATES , and for every
pair of object-states 31 and 32, the axiom sl 54$ 32 is included.

(0M4) For each class C, a valuation function ‘$’ is introduced with the signature
3 : C —) C-STATES
The valuation of the error object is added as an axiom:

$(errc) = undefc

(0M5) If there is a double-headed arrow labeled a (to indicate an attribute), leading from a class
C to a class D (which depicts an attribute a of C), then the function signature

a:C—~>D ,

is added to speciﬁcation for class C.

(0M6) If the class D in rule (0M5) is an external class, then the trait for D is included by the
speciﬁcation for C. If D has no parameters, then the clause

includes

CLASS-D

284

 

 

 

285

is added. If D has parameters p1, . . . , pk, and there is a line connecting each p,- to a class q,-,
then the following clause is added:

includes
CLASS-p1. .. ., CLASS-p;c ,
CLASS-D ( ql for m. ---. (1;. for Pk)

(0M7) Association R is denoted by the predicate

RIDI,D[¢ —i BOOL .

(0M8) The endpoints of association R determine a set of axioms. Suppose the Dl-endpoint depicts
a multiplicity of m and the Dg-endpoint depicts a multiplicity of n. Then the axioms are
derived by the following steps:

1. Decompose the m-to—n association R into an m-to—l and l-to—n binary association,

2. Determine the second-order speciﬁcations, P1 and P2, of each of these associations using
the basis schemata,

3. Calculate the “intersection”, P, of the speciﬁcations P1 and P2,

4. Unfold and skolemize P, yielding a set of ﬁrst-order axioms that are included in the
trait for R.

(0M9) Error object constraints are introduced:
(le : Dl,d2 :02 o R(eer,,d2) A d1¢ errp1 => “'R(d1,d2)) 1
(le I Dl,d2 Z D2 . R(d19 87702) A d2 # 87702 3 ﬁR(d1!d2))

(OM10) The attributes, in the form of variable-type pairs, of an object class are formalized as sorts
and a tuple that maps attribute types to the distinguished sort that represents the object
class.

For object 0, given attributes a1 :A1,a2 : A2, ...,an :An (where a1,az, ...,an are variables and A1, A2, ...,/in
are types), create the following expression in LOTOS speciﬁcation
typedef 0 is
sorts
O, A_1, A_2, . . . , A.n
opns
0 : A-1, A-2, ..., A_n —> 0
get_a_l : O ——> A_1
get_a.2 : O —) A_2

eqns

forall a_1: A_1, a-2: A_2, ..., a_n: A_n
ofsort A-1

get_a_l(0(a_1, a_2, ..., a-n)) = a-1
ofsort A-2

get_a.2(0(a-1, a_2, ..., a-n)) = (1.2
ofsort A_n

get_a.n(0(a-1, a_2, ..., a.n)) = a_n

endtype

 

 

Appendix B

The Dynamic Model Formalization
Rules

The formalization rules for the dynamic model are given in this Appendix. Rules
DFR—l to DFR-13 are for simple state diagrams; rules DFR-14 to DFR—20 are
for concurrent state diagrams.

DFR-l The object states S are formalized as LOTOS processes.

For every state 3, s E S, create the following LOTOS expression
process 5 : noexit :2

endproc

DFR-2 Every process that formally specifies a state 3 is associated with a parameter :1: of the distinguished
sort 45.
For every state 3, s E S, and distinguished sort (1) E (P, create the following LOTOS expression
process 5 (x: 43): noexit 2:
endproc

DFR—3 The events of an object together with the events to be triggered are formalized as the inter-object
communication external to the object, which is a subset of I‘ (set of the object operators). The
events, 2, and events to be triggered. E, in a state diagram D are specified as a formal gate list
[)3 U E] for the processes in S.

For every state 3, s E S, distinguished sort ()5, events 2, and events to be triggered E ((25 E
(I), E g I‘), create the following expression

process 5 [2 U E](x: (b): noexit :2

endproc

DFR-4 Attribute pairs 2:, : a, (data items) associated with an event e are formalized as variable decla-

rations ?:c.' : a,- associated with a LOTOS gate e.
For every state 3 and event 6 (s 6 5,8 6 E), distinguished sort ()5, events 2, and events to
be triggered E (d 6 (LE 9 P), if the partial function 4p maps (s,e) to pairs 11 : a1,a:2 :
a2,...,:cn : an, a non—empty subset of A x <I> ({(x1,a1), (2:2,a2), ..., (:rn,an)} 6 2Ax°), create
the following expression

process 5 [23 U E](x: d): noexit :=

e ?x1:a1,?zg:a2....,?xn:an;

endproc
if the partial function (,0 maps (s,e) to an empty set (no associated attribute for event e),
create the following expression '
process 5 [2 U E](x: ct): noexit :=

3;

endproc

286

..- n. _.—_< -..—

287

DFR-5 An event to be triggered, e’, is formalized as a value declaration at a LOTOS gate.

For every state 3, event e, and condition c (s 6 3,6 6 S,e 6 C), distinguished sort (23, events
2, and events to be triggered E (<13 6 Q, 2 Q I‘), if the partial function 6 maps (s,e,c) to a
triggerable event 8’, create the following expression

process 5 [2 U E](x: ct): noexit :2

e'!y1, !yg, !ym;

endproc.
where {y1, y2, ..., ym}, a subset of {11:1, 11:2, ..., xn, x}, is speciﬁed in the corresponding state
diagrams.

DFR-6 A guarding condition c is formalized as a guarded expression [c].

For every state 3, event e, and condition c (s E S, e E E, c E C), distinguished sort oi, events
23, and events to trigger E (d E Q, 2 g I‘), if the partial function cp maps (3, e) to pairs 2:1 :
a1,;c2 :az, ...,xn :an, a non-empty subset ofA x Q ({(x1,a1), (12,02),..., (xn,an)} E 21””), a
non-empty subset of sorts Q ({a1,a2, ..., an} E 2‘”), and c 76 c0, create the following expression

process 5 [2 U E](x: (b): noexit z:

e ?zl :al, ?932 202, ?xn : an; ([c] —) ...)

endproc,

where 2:1, 2:2, ..., 2:" are variables to hold the attributes associated with the event.

DFR-7 A newly introduced predicate in a guarding condition is formalized as an operation of Boolean
in the algebraic specification section.
Given object D, for every state 3, event 6, condition c (s E S, e E 2, c 6 C), distinguished
sort ¢, and predicate p introduced in condition c, if 11,32, ...,:cn are the arguments for p of
sorts X1, X2, ..., X“, create the following expression
specification D [E U E](x: (t): noexit
typedef (b is Boolean
opns
p: X1,X2,...,Xn ——-) Bool
endtype

process 5 [E U E](x: ¢)3 noexit :2

endproc
endspec

DFR—8 An action a is formalized in terms of a value declaration !a by an Operator reference at the
corresponding gate e.
For every state 3, event e, and condition c (s E S, e 6 E, c E C), if the partial function (,0
maps tuple (s, e) to sorts a1,a2, ..., an (a non-empty subset of sorts Q ({a1,a2, ...,an} E 2‘”)),
c 76 co, and the partial function 6 maps tuple (s, e) to an action a (a E A), create the following

expression
process 5 [E U E](x: (b): noexit :=
e 71:1 :al, ?z2 : a2. 72,, :an;
(lCl -+ e !a(y1. y2. yml)
endproc,
where {y1, y2, ..., gm}, a subset of {2:1, 9:2, ..., :13", x}, is speciﬁed in the corresponding state
diagrams.

DFR-9 An activity a is formalized as a value declaration la at the corresponding gate e preceded by a
nondeterministic internal event 2'. ~
For every 3, s E S, distinguished sort gb, events 23, events to be triggered E. (4) E Q, E g I‘),
and arguements y1, y2, ..., yn of sorts Y1, Y2, ..., K, for activity a, if the partial function A

 

'v

E

. hh‘~-h“-
.n I

‘—
s-
h‘

 

 

288

 

maps state 3 to an activity a (a E A), create the following expression
process 5 [E UE](x: (15,311 : Y1, yg : Y2, yn : Yn): noexit :=

i; e !a(y1, 3’2: ”-0 y”)-
endproc

DFR—lO A transition can cause a state change if and only if the action that corresponds to a transition
is defined as a modifier Operator.
For every state 3 and event 6 (s 6 5,6 6 E), if the partial function w does not map tuple
(s,e) to state 3 (s 9:9 w(s,e)), then the partial function 6 maps tuple (s,e) to a modiﬁer
operator (6(s,e) E 9); if the partial function 6 maps tuple (s,e) to a non-modiﬁer operator
(6(s,e) E 9), then the partial function it maps tuple (s,e) to state 3 (s = w(s,e)).

DFR-ll The state transitions are formalized as process instantiations.
For every state 3 and event e (s E S, e E E), distinguished sort ¢, events E, and events to be
triggered E (d) E Q, E Q I‘), if the partial function 90 maps (3, e) to pairs 2:1 : a1,2:2 : a2, ...,zn :
an, a non-empty subset ofA x Q ({(z1,a1), (:22, a2), ..., (:rn,a,,)} E 2AX‘D), the partial function
6 maps tuple (s, e) to an action a (a E A), the partial function 111 maps tuple (s,e) to a state .~
3’ (s' E S), and a is of sort 4), create the following expression

.L..-’ V

.‘A

‘..\_.

process 5 [E U E](x: d2): noexit := ,...
e ?21 :al, 7232 : a2, ?xn :a,,;
s’[2 usuaul. y2. y...»

endproc

if a is not of sort (b, create the following expression
process 5 [2 U E](x: rt): noexit z:

 

e ?x1 :al, 72:2 102, ?zcn :an;
e !a(y1, yg, ym);s’[2 UE](x)
endproc

DFR—12 Multiple state transitions from a single state are formalized as process instantiations composed
by a choice Operator.
For every state 3, events el and e2 (3 E S, e1,e2 E E), distinguished sort 43, events 2, and
events to be triggered E. (d 6 Q, 2 g I‘), if e1 96 e2, the partial function «p maps tuple (3, e1)
to {2:11 : a11,212 : a12,...,:rln : am}, (3,82) to {1:21 : 021,122 : 022,...,:1:2j : agj} (where
{($11,011),)$12,012),m,($1n,ain)},“$21,020,($22,022),---,($2j,02j)} E 2M”: the partial
function 6 maps tuple (s,el) to a1, (3, eg) to a2 (a1, a2 6 A), and the partial function 1,12 maps
tuple (3, e1) to 31:, (3, eg) to 32' , create the following expression1
process 5 [2 U E](x: 45): noexit 2:
61 ?2311 20.11, ?1212 1012, ..., ?zln 101”;
61 !31(y11, 3112, ..., ylm); Slip: UEMX)

[l

62 ?121 1021, 27115222022, ..., 73:2): Iagj;
82 !32(3/21. 3122. 3121:): 52'[2 U 3[00
endproc

 

DFR-l3 A state diagram can be formalized as either a LOTOS speciﬁcation or a LOTOS process
deﬁnition.
For state diagram D = (S, 2, A, A, Q, C,E,1,b, A,6,cp, C, so, c0), we can have either
process D [2 U E] (x: (15) :noexit :=
$0 [2 U E] (X)
where
( algebraic specification )
( process definitions )
endspec

OR

 

1The expression may differ according to DFR—lO depending on the sort Of a,.

 

289

speciﬁcation D [E U E] (x: o) :noexit
( algebraic specification )

behaviour
50 [E U El (X)

where
( process definitions )

endspec,

where the ﬁrst format is used if the process will be composed within other speciﬁcations to
form more complex behavior speciﬁcations; the second format is used if the speciﬁcation is a
top level speciﬁcation.

DFR-l4 Every aggregate Object is responsible for composing the behavior Of its concurrent aggregation
Objects to form one behavior specification.

DFR-15 The behavior Of every aggregation Object must be composed by and only by its aggregate Object.

DFR-16 Only when there is an association between two aggregation objects. can the aggregate Object
model the corresponding synchronization between the two Objects.

DFR—l7 In a state diagram that composes dynamic models of concurrent Objects, the dynamic
behaviors are synchronized through shared services.
The state diagram D = (S, E, A, A, Q, C,E, w, /\,6,(p, C, 30, c0) composed of
D1 = (Si,21,1)1,A1,‘1’1,Chanda,A1,51,<P1,C1,310,Co),
Dz = (52, 22,1‘2: A2, 4’2, (72,52,1/12, A2,52,W2,C2, 820,00),
...... , and Du = (Sn,Zn,An,An,Qn,Cn,En,ibn,An,6n,cpn,(n,sno,co) is formalized as:
speciﬁcation DESI U 22 U U 2,, U £](x:¢,x1:¢1,x2 432 , . . . ,xn:¢n): noexit
(algebraic specification)

behaviour
80 [SUE] (X)
l [T1] I
(01531 U El] (X1)
l[TEJI
(1)2[22 U 52] (12)
l [T3] l
( .....
l [Tn] l
Bu [2,, U En] (xn)
D)
where
(process definitions)
endspec,

where T1, T2, ..., Tn are shared services.

DFR-18 In a state diagram, the interleaving dynamic models are grouped together in terms of L0-
TOS interleaving process algebras.
If state diagrams D1 = (51, 21,A1)Ala¢lvclvsliwliA1761,”p1$C19810)CO),
D2 = (52, 22,A2) A2,‘I’2, 02,52,1/J2, A2,52,<P2,C2,320,CO),
...... , and Dn = (Sn, EmAn, An, Qn, Cmin, if)", An,6n,<pn, (n, sno, Co) are interleaving dy-

‘

 

 

290

namic models in a given state diagram, the following speciﬁcation shall be generated:

behaviour

(
Dl [21 U E:1] (X1)
l l I
Dz [22 U 32] (X2)
| l |
| l |
1),, [2,, u 3..) (xn)

)

DFR—19 If e is a constant. Of sort C, introduced by the instantiation Of parameter :i: of distinguished
sort 0 for Object 0 in a state diagram, then create the following expression
type 0 is
sorts

‘i‘A‘TF V

4.“-..4_
1“. .I u

endtype
DFR-20 For all constants c1 , C2, ..., cﬂ Of sort C introduced in Object 0. create the following expression

type 0 is Boolean
sorts

eqns
ofsort C
c1 eq c1 = True;
c2 eq C2 = True;
C3 eq C3 = True;
c1 eq c2 = False;
c1 eq C3 = False;
c1 eq 0,, = False;

cn_1 eq cn = False;

 

 

 

Appendix C

The Functional Model
Formalization Rules

The formalization rules for the functional model are given in this Appendix. Rules
FFR—l to FFR—ll are for simple OFMS; rules FFR—12 to FFR—16 are for SRFMS.

FFR-l Each data item in an OFM is formalized as a sort in the corresponding algebraic specification.
For all the data items, D,-(1 g i g n), in an OFM, create the following expression in the sort
declaration part Of an ACT ONE specification Of Full LOTOS

sorts
D-1, D_2, ..., D-n

FER-2 For every sort, S, used in the Object specification, introduce Operator undef_s: —> S.

FFR—3 Each service in an OFM is formalized as a gate that is associated with input and output in the
corresponding Full LOTOS specification.
For all the servicess, S,(1 g i S n), with inputs, Ii). (1 5 ij 5 IL] (I,- represents the permutation Of
the input data), and outputs, 0,, in the OFM Of Object OBJECT, create the following expression

speciﬁcation OBJECT [81, S2, ..., Sn] :noexit :=
0' 31 : ill 2111, ha :112, ..., illlil:lll11l -> 01 I")
(* 32 : £21 :121, 1'22 :122, ..., izllzl :Izu2| -> 02 *)
(‘ Sn 1 i1" :11", i1" :11", ..., inllnl :Inllnl -> On ‘)

oooooo

opns
51 : Ill, [12, ..., 11”“ -> 01
52 : [21, 122, ..., 12|12| -> 02
Sn 3 [1", Ila, ..., Inllnl "> On

endtype endspec

FFR—4 The set Of attributes Of an Object is formalized as a parameter Of the distinguished sort for the
corresponding Full LOTOS specification.

For Object class 0, and its distinguished sort (I) and a set Of services 2, create the following
speciﬁcation 0 [2] (o : ¢) : noexit :=

expression endspec

291

 

 

292

FFR-5 The pre-state Of the attributes Of an Object is stored in a local variable when a process, representing
a state in the dynamic model, is entered.
For Object class 0. and its distinguished sort «:5 and a set Of services 2, if p is a process, representing
a state in the dynamic model, defined in the process algebras, then create the following expression

that introduces local variable PRE to store values Of attributes at the entrance Of the process
speciﬁcation 0 [E] (o : o5) : noexit :=

process p [2] (o : ct) : noexit :=
(let FRI-2:: o in

)

endproc

endspec

FFR—6 The guarding condition and the precondition that are associated with the action Of a state
transition are conjuncted and formalized in terms Of a guarded expression in LOTOS process

phlx. I A “EL—..-

algebras.
Suppose event e (associated with arguments 2:1 : a1,r2 : a2, ...,:rn : an), condition c. action a1 . _
(associated with parameters y1, y2, ym, if event e directly refers to service a, then the y's

and :c's are identical too), together constitute a state transition from state 3 Of an Object with
distinguished sort 4) and services 2, if p is the precondition for service/function a, create the

following expression
process s [E](o: ¢): noexit :=
0 ?I1 :01, ?12 :02, ..., ?In :an;
([c and p] —+ (a(yl, y2, ... yn,)>)
endproc

FFR—7 The postcondition that is associated with the action of a state transition is formalized in terms
Of a guarded expression in LOTOS process algebras.
Suppose event e (associated with arguments x1 : a1,a:2 : a2, ...,:rn : on), condition c, action a
action a (associated with parameters y1, y2, ym, if event e directly refers to service a, then the
y's and x's are identical too), together constitute a state transition from state 3 Of an Object with
distinguished sort rt and services 23, if p and q are the pre- and postconditions for service/function

a, create the following expression
process s [23(0: ¢): noexit :8

 

e ?31 :al, ?r2:a2, .... ?rn :an;
([c and p] —) <s(y1. y2, ym)>); F1.
([q]—->. . .)
endproc
FFR—8 The postcondition that is associated with the action Of a state transition, in the form of result = . ‘
(expression), is formalized in terms of a value declaration in LOTOS process algebras. E]
Suppose event e (associated with arguments r1 : a1,:r2 : a2, ...,:cn : an), condition c, action a -[

action a (associated with parameters y1, y2, ym, if event e directly refers to service a, then the
y's and :r's are identical too). together constitute a state transition from state 3 Of an Object with
distinguished sort d) and services 2, if q is an expression, in the form Of result = op (21,22, ...,21)
(op is an Operator defined in the corresponding algebraic specifications, 2,- (1 g i g l) is a subset
Of y,- (1 5 i g m) and attributes) within the postcondition for service/function a, then create the

 

10 refers to a service/function.

 

293

following expression
process s [23(0: ¢): noexit :=
e ?21 :a1. ?r2 :a2, ..., ?In :an;
([c and p] -+ e! Op(21, 22, ... 21))
endproc

FFR-9 The postcondition that is associated with the action Of a state transition can be formalized in
terms Of a local variable declaration in LOTOS process algebras.
Suppose event e (associated with arguments 1:1 : a1,:r2 : a2,...,a:n : on), condition c. ac-
tion a(associated with parameters y1, y2, ym, if event e directly refers to service a, then
the y’s and x's are identical tOO), together constitute a state transition from state 3 Of an
Object with distinguished sort 43 and services 2, if Q is a set of expression, in the form Of
o".a,~ = op,- (z,,,z.-,,...,z,-,)(1 g i g k) (op,- is an Operator defined in the corresponding al-
gebraic specifications, z,,. (1 g j g l) is a subset Of y,- (l g i g m) and attributes) within the
postcondition for service/function a, create the following expression

process s [23(0: ¢): noexit :3

0 ?$1 :01, ?12 :02, ..., ?xn :0”;
([c and p] —+
(let POST.“ := 0p1(211 le23°'° 21,)!
P0512112 :8 op2(22,.z22,... 22,).
P03T.ak :3 opk(zk,,zk2,... 2}") in
)
)
endproc

FFR-lO The refinement of Object 0, results in a refined algebraic specification, S_REF, that includes
additional Operators and axioms.
For every Object 0 that is further refined into a set Of aggregate Objects 01, O2, 0". create

the following expression
type OJU-ZF is

endtype

FFR-ll In a refined algebraic specification for an Object (or system), the algebraic specifications for
the aggregate Objects are included in order to make use Of the services defined in the aggregate
Objects.

For every Object 0 that is further refined into a set Of aggregate Objects 01, 02, On, create

the following expression
type 0_REF is 01, 02, ..., 0,.

endtype

FFR-12 Each internal function in an SRF M is declared along with services as annotations and Operators
Of algebraic specification.
For all the internal functions, F,(1 g i _<_ n), with inputs, 1,1.(1 _<_ i, 3 IL] (I,- represents the
permutation Of the input data), and outputs, 0,, in the OFM of Object OBJECT. create the

 

 

294

following expression
speciﬁcation OBJECT [< service list>]] :noexit :=

(i F1 : 1:11:11“ £12 :112, ..., illlil :Illlil -> 01 *)
(’ F2 : igl :121, i22 :122, ..., i2|12| :I2l12l -) 02 ")
(‘ Fn : i1" :11", 11" ill", ..., inllﬂl :Inllnl -> On ‘)
typedef OBJECT is
opns
F1 : Ill, [12, ..., Illlll -> 01
F2 : [21, [22, ..., Izllzl -> 02

Fn 2 11", 11”, ..., [nllﬂl ‘) On

endtype endspec

FFR—l3 If a data flow D is aggregated into a set of data flows, D1, D2, Dn, then D is rede-
fined / refined as a set Of Operations that constitute D from D1, D2, D" and single out D1,
D2, D" from D.
For every data flow D that is aggregated into a set Of data flows, DI. D2, Dn, create the

following expression
sorts
DJ, 0.2, ..., D_n
opns
D : 0.1, 0.2, ..., 0.11 —> D
get-d-1 : D —) D-l
get_d-2 : D —) D_2

get_d-n : D —> DJ:

eqns
forall (1.1: 0.1, (1.2: 0.2, ..., d_n: D-n
ofsort D-1
get_d-1(D(d-1, d-2, ..., d-n)) = d-1
ofsort D..2
get_d-2(D(d_1, d_2, ..., d-n)) = (1.2

ofsort DJ:
get_d-n(D(d_1, d_2, ..., d-n)) = (1.11

FFR—l4 All the data splittings for a data flow D together with D is redefined/ refined as a record data
type.
For data flow D and all the sets Of data flows, SI, S2, Sn, into which D is split, if data items
DI, D2, Dm cover all the data items in S,- (1 g i g n) and do not contain redundant data

 

 

 

295

items, then create the following expression

sorts
D_1, D.2, ..., D.n

opns
D: D-1, D.2, ..., D-n —) D
get_d_1 : D —) D_1
get_d..2 : D —) D.2
get d-n : D —> D_n

eqns

forall (1-1: D-1, d_2: D.2, ..., d-n: D_n
ofsort D-l

get_d-1(D(d_1, d-2, ..., d_n)) = d-1
ofsort D-2

get_d_2(D(d_1, (1-2, ..., (1.71)) = d_2
ofsort D-n

get_d_n(D(d-l, d_2, ..., d-n)) I (1.11

FFR-15 If a data flow D is duplicated to or selected from a set Of data flows, D1, D2, Dn, Op-
erators D-2.Dl, D1.2_D, D-2.D2, D2_2.D, D.2.Dn, and Dn-2.D, in the formats Of

opns
D.2-D]: D —) D1
D.2-D2: D —> D2

D.2-Dn: D —) 0,.

are introduced in the refined algebraic specification. In addition, the following axioms are used to
specify the mutual convertibility:

eqns
forall x: D
ofsort D
Dl.2_D (D.2-D1 (x)) = x;
D2.2-D (D.2-D2 (x)) I x;

Dn._.2-D (D.2-Dn (x)) = x;

FFR—16 The post- and preconditions of two adjacent services in a SRFM shall not form a contradiction.
For any two services 31 and 32 in a SRFM, if (1) the output Of 31 serves as an input Of 32, (2)
p,1 and q,, are the pre- and post conditions for 81. and (3) p32 is the precondition for s2. create

and prove the following expression
(p,1=>((q,1 and p”) eq false)) I false

 

 

 

Appendix D

Complete LOTOS speciﬁcation for
Disk Manager Behavior

specification Disk_ManagerEinput,output,com,dec,ins,ret,de1ete] : noexit

library
Boolean, NaturalNumber, HexString
endlib

type GenericData is NaturalNumber, HexString
endtype

type Data is GenericData renamedby
sortnames
D for HexString
K for Nat
Opnnames
sizeof for Length
endtype

behavior

hide com, dec, ins, ret, del in
Storage[ins,ret,del] I[ins,ret,del]| id1e[input,output,com,dec,ins,ret,de1]
l[com,dec]l compression[com,dec]

where
process idle[input,output,com,dec,ins,ret,delete]:noexit:=
input ?d:D ?k:K; com !d ; wait[input,output,com,dec,ins,ret,delete](k)
[]
output ?k:K; retlk; wait[input,output,com,dec,ins,ret,delete](k)
endproc

process waitEinput,output,com,dec,ins,ret,delete](k:K):noexit:=
com?d:D;insldlk;idle[input,output,com,dec,ins,ret,de1ete]
[J
ret?d:D;dec!d;wait[input,output,com,dec,ins,ret,delete](k)
[]
dec?d:D;output!d;idleEinput,output,com,dec,ins,ret,delete]
endproc

296

297

process Storage[insert,retrieve,delete]:noexit:=
Empty_state[insert,retrieve,delete](new)

where
type Storage is Boolean, NaturalNumber, Data
sorts
S
opns
undef_d : -> D
undef_s : -> S
count : S -> Nat
insert : S, D, K-> S
retrieve S, K -> D
delete S, K -> S
_ eq _ : D, D -> 8001
- eq _ K, K -> 3001
eqns
forall d: D, k, k1, k2: K, s: S
ofsort Nat
count(new) = 0;
count(insert(s, e)) = Succ(O) + count(s);
ofsort D
retrieve(new, k) = undef-d;
k1 eq k2 => retrieve(insert(s,d,k2),kl) = d;
not(kl eq k2) => retrieve(insert(s,d,k2),k1)=retrieve(s,k1);
ofsort S
delete(new, k) = new;
k1 eq k2 => delete(insert(s,d,k2),k1)=s;
not(kl eq k2) =>de1ete(insert(s,d,k2),k1)=delete(s,k1);
endtype

process Empty_State[insert,retrieve,delete](s:S):noexit:=
insert ?d:D ?k:K; None_Empty_State[insert,retrieve,delete](insert(s,d,k))
endproc

process None_Empty_State[insert,retrieve,delete](8:8):noexit:=
retrieve ?k:K; retrieve !retrieve(s,k);
None_Empty_State[insert,retrieve,delete](3))
[J
insert ?d:D ?k:K;
None_Empty_State[insert,retrieve,delete](insert(s,d,k))
[]
delete ?k:K; (
[count(s) gt Succ(0)] ->
None_Empty_State[insert,retrieve,de1ete](delete(s,k))
[I
[count(s) eq Succ(0)] ->
Empty_State[insert,retrieve,delete](delete(s,k)))
endproc
endproc

process compression [compress, decompress] : noexit :=

298

Idle_State [compress, decompress]

where
type Compression is NaturalNumber, Data
opns
compress : D -> D
decompress : D -> D
eqns
forall x: D

ofsort Bool
sizeof(x) ge sizeof(compress(x)) = true;
sizeof(x) 1e sizeof(decompress(x)) = true;
ofsort D
decompress(compress(x)) = x;
endtype

process Idle-State [compress, decompress] : noexit :—
compress ?datazD; Compress_State[compress,decompress](data)

[]

decompress?data:D;Decompress_State[compress,decompress](data)
endproc

process Compress_State[compress,decompress](data:D):noexit :-
i; compress !compress(data); Idle_State[compress,decompress]

endproc

process Decompress_State[compress,decompress](data:D):noexit .-
i; decompress!decompress(data);Idle_State[compress,decompress]
endproc
endproc
endspec

 

Appendix E

Instantiated LOTOS speciﬁcation
for Disk Manager

specification Disk_Manager [Input, Output] : noexit
(* Input :D: Data, k: Key -> Void *)
(* requires d eq undef_d = false and k eq undef_k = false *)
(* modifies disk *)
(* ensures disk’ eq inputhisk‘, d, k) = true *)
(* Output : k:Key -> HexString *)
(* requires disk eq empty = false and k eq undef_k = false *)
(* ensures result = output (disk,k) *)

library
Boolean, HexString, NaturalNumber

endlib

type Disk_Manager is Boolean, HexString, NaturalNumber

sorts
Disk
opns
empty : -> Disk
input : Disk, HexString, Nat -> Disk

output : Disk, Nat -> HexString
undef_d : -> HexString
undef_k : -> Nat
eqns
forall disk: Disk, d,x: HexString, k, k1, k2: Nat, y: HexDigit
ofsort BOOl
undef_d eq undef_d = true;
undef_k eq undef_k = true;
undef_k eq 0 = false;
k ge 0 => succ(k) eq undef_k = false;
Hex(y) eq undef_d = false;
(y + x) eq undef_d = false;
ofsort HexString
output (empty, k) = undef_d;
(k1 eq k2) => output(input(disk,d,k1),k2) = d;
not(kl eq k2) => output(input(disk,d,k1),k2) = output(disk,k2);
endtype

299

TTT—T"‘3EEZI

- .3.

i7“ “‘

 

300

behavior
Idle[Input, Output] (empty)
where .
process Idle [Input, Output] (disk: Disk) :noexit:=
Input ?dzhexString ?k:Nat; Idle [Input, Output](input(disk,d,k))
[]
Output ? kzNat; Output ! output(disk, k); Idle [Input, Output](disk)
endproc
endspec

 

Appendix F

LSL speciﬁcations

Disk (D, K): trait

introduces
empty : —> Disk
input : Disk, D, K -> Disk
output : Disk, K -> D
delete : Disk, K —> Disk
undef_d : -> D

asserts

Disk generated by empty, input

\forall d: D, k, k1: K, disk: Disk

output (empty, k) == undef_d;

output (input(disk,d,k), k1) == if (k=k1) then d
else output(disk,k1);

delete (empty, k) == empty;

delete (input(disk,d,k), k1) == if (k=k1) then disk
else delete(disk,k1);

Storage (D, K): trait

includes Natural

introduces
empty : -> S
count : S -> N
insert : S, D, K -> S
retrieve : S, K -> D
delete : S, K -> S
undef_d : -> D
undef_s : -> S

asserts

S generated by empty, insert

\forall d, d1, d2: D, k, k1, k2: K, s, 31, 82: S
count(empty) == ;

count(insert(s, d, k)) == succ(count(s));
~(insert(s,d,k) = empty);

301

 

 

302

retrieve(empty, k) == undef_d;

retrieve(insert(s, d, k2), k1) == if (k1 = k2) then d
else retrieve(s, k1);

delete(empty, k == empty;

delete(insert(s, d, k2), k1) == if (k1 = k2) then 8
else delete(s, k1);

Compressor (D): trait

includes Natural

introduces
compress : D -> D
decompress : D -> D
size : D -> N
asserts

\forall d : D

size (compress(d)) <= size(d);
size (d) <= size(decompress(d));
decompress(compress(d)) = d;

Disk_ref (D, K): trait
includes Storage(D,K), Compressor(D)
implies

\forall s: S, n: N
~(s=empty) => ~(retrieve(s,n) = undef_d);

 

Appendix G

LOTOS speciﬁcation for revised

Disk Manager

specification Disk_Manager [input, output] : noexit

library
Boolean, NaturalNumber
endlib

type Disk-Manager is
sorts
D, K
endtype

behavior

hide com, dec, ins, ret, delete in
Storage[ins, ret, delete]
l[ins, ret]|
idleEinput, output, com, dec, ins, ret, delete]
l[com, dec]!
compression[com,dec]

where

process idle [input, output, com, dec, ins, ret, delete]

: noexit :=

input ?dzD ?k:K; com !d !k; wait[input,output,com,dec,ins,ret,de1ete](k)

[1

output ?k:K; ret !k; wait[input, output, com, dec, ins, ret, delete](k)

endproc

process wait [input, output, com, dec, ins, ret, delete] (k: K) : noexit :
com ?d:D; ins !d !k; idle [input, output, com, dec, ins, ret, delete]

[]

ret ?dzD; dec !d; waitEinput, output, com, dec, ins, ret, delete](k)

[J

dec ?dzD; output !d; idle [input, output, com, dec, ins, ret, delete]

endproc

303

 

304

process Storage [insert, retrieve, delete] : noexit :=

(*behaviour*)
Empty [insert, retrieve, delete] (new)

where
type Storage is Boolean, NaturalNumber
sorts
S, D, K, E
opns
new : -> S
undef_d : -> D
undef_s : -> S
count : S -> Nat
insert : S, D, K -> S
retrieve S K
delete S K
_ eq _ : E, E -> 8001
_ eq _ D D
_ eq _ K K

eqns
forall d: D, k, k1, k2: K, s: S, e, e1, e2: E
ofsort Nat
count(new) = 0;
count(insert(s, d, k)) = Succ(O) + count(s);
ofsort D
retrieve(new, k) = undef_d;
k eq k1 => retrieve(insert(s,d,k), k1) = d;
not(k eq k1) => retrieve(insert(s,d,k), k1) = retrieve(s,k1);
ofsort S
delete(new, k) = new;
k1 eq k2 => delete(insert(s, d, k2), k1) = s;

not(kl eq k2) => delete(insert(s, d, k2), k1) = delete(s, k1);

endtype

process Empty [insert, retrieve, delete] (s: S): noexit :=
insert ? d : D ? k : K;
None_Empty [insert, retrieve, delete] (insert(s, d, k))
endproc

process None_Empty [insert, retrieve, delete] (s: S): noexit :=
retrieve ? k : K; retrieve ! retrieve (s, k);
None_Empty [insert, retrieve, delete] (s)
[I
insert ? d : D ? k : K;
None_Empty [insert, retrieve, delete] (insert(s,d,k))
[]
delete ? k : K; (
[count(s) gt Succ(0)] ->
None_Empty [insert, retrieve, delete] (delete(s,k))
[]
[count(s) eq Succ(0)] ->
Empty [insert, retrieve, delete] (delete(s,k))

 

 

)
endproc
endproc

process compression [compress, decompress] : noexit :=

(*library
NaturalNumber
endlib*)

(*behavior*)
Idle [compress, decompress]

where
type Compression is NaturalNumber
sorts
D
opns
compress : D -> D
decompress : D -> D
sizeof : D -> Nat
eqns
forall x: D
ofsort Bool
sizeof(x) ge sizeof(compress(x)) = true;
sizeof(x) 1e sizeof(decompress(x)) = true;
ofsort D
decompress(compress(x)) = x;
endtype

process Idle [compress, decompress] : noexit :=

compress ? data: D; Compress [compress, decompress] (data)

[J

decompress ? data: D; Decompress [compress, decompress] (data)
endproc

process Compress [compress, decompress] (data: D) : noexit :=
i; compress ! compress (data); Idle [compress, decompress]
endproc

process Decompress[compress, decompress] (data: D) : noexit :=
i; decompress ! decompress (data); Idle [compress, decompress]
endproc
endproc

endspec

 

 

Appendix H

Complete LOTOS speciﬁcation of
ENFORMS for static analysis

specification ENFORMS_REF [Browse, Retrieve, Analysis, Query, GetTable,
Archive_Query, Register, Archive_Query4899,
Archive_Query5699] (e: ENFORMS): noexit

(* Browse: ui: User_Input -> Retrieve_Request *)

(* ensures result = Browse (ui, getIndices(e)) *)

(* Retrieve: rr: Retrieve_Request -> Retrieve_Result *)
(* requires isValid(rr) *)

(* ensures result = Retrieve (rr, getArchives(e)) *)

(* Analysis: ar: Analysis_Request -> Analysis_Result *)
library

ENFORMS, Name_Server, Archive_Server, Client, Boolean, Channel
endlib

type ENFORMS_REF is ENFORMS, Name_Server, Archive_Server, Client, Channel
opns
Retrieve_Request : Data_Archive_Name, Query_Request -> Retrieve_Request
get_data_archive_name : Retrieve_Request -> Data_Archive_Name
get_query_request : Retrieve_Request -> Query_Request
Retrieve_Resu1t2Query_Result : Retrieve_Result -> Query_Result
Query_Result2Retrieve_Result : Query_Result -> Retrieve_Result

pcs : -> Data_Archive_Name
pcs_db : -> Data_Archive
4899 : -> Address
5699 : -> Address
storet : -> Data_Archive_Name
storet_db : -> Data_Archive
channel : -> Channel

eqns

forall dan, dan1, dan2: Data_Archive_Name, qr:
Query_Request, rr: Retrieve_Result, qr1: Query-Result
ofsort Data_Archive_Name
get_data_archive_name (Retrieve_Request(dan, qr)) = dan;

306

 

307

ofsort Query_Request

get_query_request (Retrieve_Request(dan, qr)) = qr;

ofsort Retrieve_Result

Query_Result2Retrieve_Result(Retrieve_Resu1t2Query_Result(rr)) = rr;

ofsort Query_Result

Retrieve_Result20uery_Result(Query_Result2Retrieve_Resu1t(qr1)) = qr1;

ofsort BOOl

endtype

behavior

pcs eq pcs = True;

storet eq storet = True;
undef_Data_Archive_Name eq undef_Data_Archive_Name = True;
pcs eq undef_Data_Archive_Name = False;
undef_Data_Archive_Name eq pcs - False;
storet eq undef_Data-Archive_Name = False;
undef_Data_Archive_Name eq storet False;
pcs eq storet = False;

storet eq pcs = False;

pcs_db eq pcs_db = True;

storet_db eq storet_db = True;
undef_Data_Archive eq undef_Data_Archive = True;
pcs_db eq undef_Data_Archive = False;
undef_Data_Archive eq pcs_db = False;
storet_db eq undef_Data_Archive = False;
undef_Data_Archive eq storet_db = False;
pcs_db eq storet_db = False;

storet_db eq pcs_db False;

4899 sq 4899 True;

5699 eq 5699 True;

undef_Address eq undef_Address = True;
4899 eq undef_Address = False;

undef_Address eq 4899 = False;
5699 sq undef_Address = False;
undef_Address eq 5699 = False;

(Browse ? ui: User_Input;

Browse ! Browse (ui, getIndices(e));

Browse [Browse, Retrieve, Analysis, Query] (e)
l[QueryJI

(Client [Query, GetTable, Archive_Query] (Client(empty))
l[GetTable,Archive_Query]I

(Name_Server [Register, GetTable] (Name_Server(empty))
l[Register]|

(Channel[Archive_Query, Archive_Query4899, Archive_Query5699] (channel)
l[Archive_Query4899,Archive_Query5699]l

(Archive_Server [Archive_Query4899, Register]

(Archive_Server(pcs, pcs_db, 4899))

Archive_Server [Archive_Query5699, Register]

where

(Archive_Server(storet, storet_db, 5699)))))))

 

 

308

process Browse [Browse, Retrieve, Analysis, Client_Query](e:ENFORMS):noexit:=

Browse ? ui: User_Input; Browse ! Browse (ui, getIndices(e));
BrowseEBrowse, Retrieve, Analysis, Client_Query] (e)

I]

Retrieve ? rr: Retrieve_Request; (
[isValid(rr)] -> C1ient-Ouery !get_data_archive_name(rr)

!get_query_request (rr);
HaitQuery[Browse, Retrieve, Analysis, Client_Query](e)

I]
[not(isValid(rr))] -> Browse[Browse,Retrieve,Ana1ysis,Client_Query](e)
)
endproc
process WaitQuery [Browse, Retrieve, Analysis, Client_Query] (e: ENFORMS) ?

: noexit := 3
Client_Query ? rr: Query_Result; Retrieve ! Query_Result2Retrieve_Resu1t (rr); ]
Analysis [Browse, Retrieve, Analysis, Client_Query] (e) ]

endproc ]

process Analysis [Browse, Retrieve, Analysis, Client_Query] (e: ENFORMS)
: noexit :=
Browse ? ui: User_Input;
Browse ! Browse (ui, getIndices(e));
BrowseEBrowse, Retrieve, Analysis, Client_Query] (e)
[1
Analysis ? ar: Analysis_Request;
Analysis! Analysis (ar);
Analysis[Browse, Retrieve, Analysis, Client_Query] (e)
endproc

 

(testsssssssssso:ssssChannelsssssssssssssssssssssssssss)
process Channel [Send, Channel4899, Channe15699] (c: Channel) : noexit :=

Idle [Send, Channel4899, Channe15699] (c)

where

process Idle [Send, Channel4899, Channe15699] (c: Channel): noexit :=
Send ? qr: Query_Request ? a: Address; (

[a eq 4899] -> Channel4899 ! qr ! a;
waitChannel4899 [Send, Channel4899, Channe15699] (c)

 

[]
[a eq 5699] -> Channe15699 ! qr ! a;

waitChann915699 [Send, Channel4899, Channe15699] (c)
)

endproc

process waitChannel4899 [Send, Channel4899, Channe15699] (c: Channel): noexit :
Channel4899 ? qr: Query_Result; Send ! qr;
Idle[Send, Channel4899, Channe15699] (c)
endproc

process waitChanne15699 [Send, Channel4899, Channe15699] (c: Channel): noexit :

309

Channe15699 ? qr: Query_Result; Send ! qr;
Idle[Send, Channel4899, Channe15699] (c)
endproc
endproc

(ssssssssssssssssssssssssssssssClientsssssss*sssssssttssssssssssss*ss)

process Client [Query, Name_Server_GetTable, Archive_Server_Query] (c: Client)
: noexit :=

Name_Server_GetTable;
Init [Query, Name_Server_GetTable, Archive_Server_Query] (c)

where
F.
process Init [Query, Name_Server_GetTable, Archive_Server_Query] (c: Client) ]
: noexit := i.
(let PRE: Client = c in h;

Name-Server_GetTable ? st: Server_Table;
(let POST: Client = C1ient(st) in

Idle [Query, Name_Server_GetTable, Archive_Server_Query] (POST))
)

endproc

process Idle [Query, Name-Server_GetTable, Archive_Server_Query] (c: Client)
: noexit :=
Query ? dan: Data_Archive_Name ? qr: Query_Request;
Archive_Server_Query ! qr ! getAddress(getTable(c), dan);
WaitQuery [Query, Name_Server_GetTable, Archive_Server_Query] (c)
endproc

process WaitQuery [Query, Name_Server_GetTable, Archive_Server_Query] (c: Client)
: noexit :=
Archive_Server_Query ? qr: Query_Result;
Query ! qr; Idle [Query, Name_Server_GetTable, Archive_Server_Query] (c)
endproc
endproc

(testes:ssssssssssssssssArchive Serverssssessssssssssssssssssssssssss)

process Archive_Server [Query, Name_Server_Register] (as: Archive_Server)
: noexit :=

 

Name_Server_Register !getArchiveName(as) !getAddress(as);
pollRQ [Query, Name_Server_Register] (as)

where

process pollRQ [Query, Name_Server_Register] (as: Archive_Server) : noexit :=
Query ? qr: Query_Request ? a: Address; (
[isMyAddress(a, as)] -> Query [Query, Name_Server_Register] (as, qr)
[]
[not(isMyAddress(a, as))] -> pollRQ [Query, Name_Server_Register] (as))
endproc

310

process Query [Query, Name-Server_Register]
(as: Archive_Server, qr: Query_Request) : noexit :=
i; Query ! Query (qr, getArchive(as));
pollRQ [Query, Name_Server_Register] (as)
endproc
endproc

(*ssstssstsss*ssssssssssname_serverssss*sstssss*sss***************)
process Name_Server [Register, GetTable] (ns: Name_Server) : noexit :=
pollRQ [Register, GetTable] (ns)
where
process pollRQ [Register, GetTable] (ns: Name_Server) : noexit :=
(let PRE: Name_Server = us in
Register ? dan: Data_Archive_Name ? a: Address;

( let POST: Name_Server = Name_Server(insert(getTable(PRE), dan, a)) in
pollRQ[Register, GetTable] (POST))

 

[J
GetTable; GetTable ! getTable(ns); pollRQ [Register, GetTable] (ns)
)

endproc

endproc

endspec

 

"‘illllillllllllllllES