Fundamental Approaches to Software Engineering: Third International Conference, FASE 2000 Held as Part of the Joint European Conference on Theory and ... (Lecture Notes in Computer Science, 1783) 3540672613, 9783540672616

Citation preview

Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis and J. van Leeuwen

1783

3

Berlin Heidelberg New York Barcelona Hong Kong London Milan Paris Singapore Tokyo

Tom Maibaum (Ed.)

Fundamental Approaches to Software Engineering Third International Conference, FASE 2000 Held as Part of the Joint European Conferences on Theory and Practice of Software, ETAPS 2000 Berlin, Germany, March 25 – April 2, 2000 Proceedings

13

Series Editors Gerhard Goos, Karlsruhe University, Germany Juris Hartmanis, Cornell University, NY, USA Jan van Leeuwen, Utrecht University, The Netherlands Volume Editor Tom Maibaum King’s College London Department of Computer Science Strand, London WC2R 2LS, UK E-mail:[email protected]

Cataloging-in-Publication Data applied for

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Fundamental approaches to software engineering : third international conference ; proceedings / FASE 2000, held as part of the Joint European Conferences on Theory and Practice of Software, ETAPS 2000, Berlin, Germany, March 25 - April 2, 2000. Tom Maibaum (ed.). - Berlin ; Heidelberg ; New York ; Barcelona ; Hong Kong ; London ; Milan ; Paris ; Singapore ; Tokyo : Springer, 2000 (Lecture notes in computer science ; Vol. 1783) ISBN 3-540-67261-3

CR Subject Classification (1991): D.2, D.3, F.3 ISSN 0302-9743 ISBN 3-540-67261-3 Springer-Verlag Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer-Verlag. Violations are liable for prosecution under the German Copyright Law. Springer-Verlag is a company in the BertelsmannSpringer publishing group. © Springer-Verlag Berlin Heidelberg 2000 Printed in Germany Typesetting: Camera-ready by author, data conversion by Boller Mediendesign Printed on acid-free paper SPIN 10719952 06/3142 543210

Foreword

000 r

o

r r

o

o o

r

o

r or

ur o ro r r o o

o ur o ro o r u r ou

u o

o r

o

r o

o

or

r o

r

r

o u or r r ou o ro u o o u o oo oo u or r o r o or r r o o r or r o o o ou r o o r o u o r o r u r r o o r o o u oo o r o r o r ro r o ro or o o ro o o o r u o r o r ro r o r o o o ur r r r or u o o o r o o r o r o o o r or u r r r r or o o o or u o r ou r r r r r o o r or r r or r r ro r o 000 u u r r o or u o r ou u ur or o o o r ro o oo ro 000 o r o r or o o

r r

u r u

r r r

¨ o

u r r

o r

r ro r

r oor

r

o

o

u

r r

o u o

uro u ro

u r o or r o

r r

¨ r o

o r o o

u

u

r r r

ro or o

o

o urr

VI

Foreword

o

o o r u r r u r u o o

u u o r

o ur

r

o o

o r 000 r u uro uro uro

ou o

o

o

o ro r

r o

o r

o u u r

r r oo o ro o r u r ur o o r ¨ r u r r r or u o o r o r u r o r r o r r¨ u o¨ or o o r r¨ u r r or u r ur r r r¨ u rou

or o o o o

r r o r o

r

u o o o

o or

ro

o o r oo o or ro r u or or o u r or o r oo o r o o o uro r or ro r r

r u r o

o

o

o o

or or r r

r

r ro

r

000

r

r or

o r

o

r

Preface

r

r

i

r r

r rig r r r i g r

i

r

i i r ri i gi i i i g i i r r r r r r r i i i r r gi r ir gi ri g ig i i i gi ri g ri i i gr i g r r i ri i r r i i r r ri r r r r r i ri i r gi ri g r r i – i – r

r gr i

–

i r

r ig i r r gr ri i r

ig i

i i g r

ig r

ri

ri g i i i

r r r r r r i i g i g gi ri g i i r gi ri g r r r

i

ri g

r g ri g r i

i g r r i i r i

r gr gi

gi gr

i

i

i i g r gr i gi r i r – ri i r r r i – i i i – r i gi ri

i

r r ii i r gi ri g rig r gi r i i i i i i ig r i r i i i i i ri g r

i

–

–

i i r

i r i i

ri g r i i g gi r r rr r ii

i i

r i r ri

i ri

gi

i i

i i

r i i

r

r

ri g

ri i ri

i g

r

r r

gi

ri g

i gi

g

i rg

r

ri g r gi

ri g

r r r

i

i

gi

i

ii

ri

VIII

Preface

r gr

i

g

i

i ri r

i i ig

i r ig

r

r i ri i ri i i rr i i ri i r ri i i ri i i ri r r g ri g i ir i g g ri i i i i i r i i ri i ri r r i i ri r i

i ri i

i ri r r r

r i

i

0 i

i

ri i i r i r i i g r 21 r r i r r i r r r ig i i rig i g

g

r r r

r i ri i

r

ig

ri

i

g i r i

rg

r i

i

ri

ir

i

r i

r i ri ¨

i

r i r

r

i

r

gr r

r

i i

ri r r i i r i i

r

i r

r

r r

i

i i i r r r gi ri g r r i i g i i r r r i r r gi r r i r r i r i r ir i i r i r r r i

rigi

r

i r

ri

r i i i r i i g r g i i r ri i r r rr r i r i i i i gi r i r i

r

r

i i ir i r r i r g

i g

r r r i r r r i

i r

ig

i

i

r ri r

i i i i r ri g i

r ir

i

i

r i ii

i

r

ii

Referees





Preface

ir i

gr

r

i g

r 2000

r

i

i

ri i g

ri g

r

r

i i g

ir

r i

rg

i g i

r r i

IX

r

r i r i gr r i

i

Table of Contents

Invited Papers n

n

n n

n

n

..............

..............................................

n

n

n

n

.................

n z

Real-Time Systems n

n

................

n

.....................

n ¨

...........................

Formally Engineering Systems n

n

n

n

n

n

n

nn .................................

n

n

.........

n n n n n n ...................................................... ¨

¨

XII

Table of Contents

Software Engineering n

n

n n .....................................

nn z-

............

n a

z-

n

n n

...................

n

n

n

x

...............

Object Orientation ¨

n

n ................

n

n

n

n

n

z n n

n

n

n n

n

.........

n ...............

n n .......................................................

Formally Engineering Systems n

n n n n .............................................

Theory and Applications n n n n .......................................................... -

Table of Contents

n n n

n x

n

n

n

n ...

n n n n n n ................................................... z n

n

n

n

..................

Case Studies n n

n

n ¨ n

n

n n n .................................... n

n

n

.................

Demonstrations n ¨ n n

¨

-

............................... z n .

n ¨ ¨

...................................................... -

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

XIII

Essay on Software Engineering at the Turn of Century l y l

i

Institute of Informatics, Warsaw University Banacha 2, 02-097 Warsaw, Poland [email protected]

Abstract. Presents a personal view of the development of software engineering and its theoretical foundations, assesses the current state, lists (some) unresolved problems and identifies (some) directions of fruitful research. The Y2K problem is ignored.

0

Disclaimer t

i 2000

t

t

l t i t t l

j

t i t

t t

i

t

t ti i i i t

t

t t i l ti l i i t i t t it l l i i l y t i it lt t t i y i t l lt

it

it y l it t l

t

t

l l

t

l y lt l y

t i

t

i

t

l

t ti y y

t t

i ti i t

i

y i t t i i lt

i t

i t i

t

i y t t i lj t t i i 1 it i

l i it t ti

i

y

l l t

t i i l il t i

t i

ty l l i

l i

i l

i

i i l l y j i

t

i il l

t i t l t t 1

l l it

l y l t

l i t t i 2000 00

t tt y t it i

l i

tt y l

t

t t i i t t i

y i t i l ty

y t

t t

it t t l t

t i

t y t

t i

t

t

t t i

i t l i

Software Engineering. Report on a conference sponsored by the NATO Science Committee. Garmisch, Germany, 7th to 11th October 1968. Editors: Peter Naur and Brian Randell. January 1969.

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 1–20, 2000. c Springer-Verlag Berlin Heidelberg 2000 

2

Wladyslaw M. Turski

l

2

i

t t l lt l l y t

y y t il l ti i t i i i l i i i y l y i l l y l l i i i i i il ity

1

t

t i l t il l l it t l t i t ti i t i

t i

t i t i

t ti

t y t

i y

l t j t i

t ti

i

l l l i

t

t i

t t

i

it l

t

Background i t

l l t t ti i it lt i l y i l l ti l ti t l t i i j t l l y t ti l i it l t t i i t y t i i ti i 3 0 b.c. it iz t il i t t t t t t t i i z t t l l i j t t t t t t lt it t it t t t ti t t i t l it t t il t t t t i i t i t i t l l t t t t t ti i t t ii t t t t lt it t i i l t t i t l t l l y lt 0 it i y t t l y y t i 22 b.c. t l l y i a.d. 2 l t t i it i l 00 l i t ti j t t i l t t l t ity t t t t y l y 0 y t t ti l it y t t t l y il l i i ti l y y lt i t li i ti ti t t i i ti i it i t li i i 2 2 b.c. il l i il t lt t i li t ti l l i i i i t l ity i t i t ti i t it y t ti y i t t t j t y t t i i ti i it i t ti i t y t t ti t t j t t i y t l l t i it ti t t t t i t y t t l l y i i l t l i t l it t ti i t i l y it il l i lt t i i t il t t t y t l l l t i lt i i t t ti l i i l l i i y i t i l t i t t l i l it t

Essay on Software Engineering at the Turn of Century

t

l i t t it i l t i i t

i

i t

i

t

t lt l y t t t t t

i t l l y t i l y i t

t t l

y

i t

t i y l i lt l t li t l i t i i tl it i i l y i t y t l i t i

ti

t

3

i

y

t y l

t l

lt t

it

t

i

ii t t i il 2 t i l i l it t l i it t tti t it i l l l i t ti t t l l y t i t t i l l t y t t i l ti t t li it i lt i ti i i l y y tt ti i t l i i t it i t t t l il i t ti t t i ti ii t ti t t t i t t t t i il ity t t i t y i l t i t t t i t t l l ti l il t i t t tl ti i y lt i t l it it i l i t i t i t ity t

yl i t i t l y l l t ti t t t i t l y i l l y ti i t t t t l t it t l t i t t t t t t y i il t l y i l t l t t y it t i t i l t t i li t i i t t l i t t l i t i t l it t l i t i t

t

t

i

l l y lt t t t l lt i l t i t it

t

t t i it i

t i

ti

t ti t

l l y

l i

i t i t i tl y

t li t l y i l l t t t li i it it i yl i t i t i t i i t ilt t i t l i

ti

t

3

l ty t t

fl l y

l

i lt l y l t t t l i l i ti it i ty it i l i t l l l it i t t t ti i ti i t ti t l it

t tl t i t l l y l y tt i t t t it l y t l l il y t i

i

t yl

l

i t ti l y t

it

$

t

i ity i y

4

Wladyslaw M. Turski

2

A Bit of History i

t l i y

y t i t lt i t t l i y t ti i i i i l i it t i y i i y l l i t it t t t y t t t i y t it t i z i y i l ll i t t t ll l y i i y i ty t l l yi t it i i l y t t i ti i i i t l y i t t t i i t l t i l l lt t t y l y ti l i t t ti t t i i t it l t ti l i ti ti t i i t t t i it i l l y t t t ti i l i tl y t t l y ti l l t t t ti t t ti t l i il i ti l il l i t t t i t y y l l it i t t l i t t ti t t il it t t t t l y l l i ti l ity t ti it ti l l y i t t i t it t i t ity t t i t t t l t l it t t it t it t it t ti i t y t il i {P }p{Q} t i l t t l l t ti t il y i li t t i i t i ti t i l y i t ti ti l t t l t t t t 20 y i ti it l y i y t t ti l l y i l i t t i i t t ti i t 0 y t l l y fl i i l i t i i i i l l y l t li l y it t t i i l i l l i l l l it t i t tl y it t {P }p{Q} t i l i i t l l i t t t i i l i l l i l l i i ti t i i t t i t ti t t i i l i t i i {P }p{Q} i ti i p t t l t i t t ti p i t i ti t i it i l lt t i it i t l it i lt i t t ti l l y t i i t i t i t t l y i i lt i l l i it l i ti lt i l t i i t ly t i l t i i i t i l i t i t l l ti t ti l it i ity l y it t i i ti t i l y lit i i t ti it t l t i l y t t l l y l it i il y ti l

Essay on Software Engineering at the Turn of Century

t i ity t t t i t it y i l it i t l lt l t ti i ti t it i l it i i i i ti t it i y t it t i l l l y t t it t i ti l y t l i i t l t t t i t l y t y t t l y it i t i il y i i l y y ti i t t i 0 t t l lt i li t i ti t i lt i l l t l i t t t t l y y t t ti t i i t t i t l y i t l y t i i it i t i i t i y lt t t tt i i t y il ity t t t t it l y l l y t ti il y il l t l i l y t t t i t y t ti l l y t t i l y i t t l i t t t ti t i i t t t i t t l lt i l i l t t l i t t t i t tt t i i t i l y i l i i t i y l t t t i t y y t t i t l y t l l i it t t t t i t {P }p{Q} i i l lt i l i i i fl

t

t

i {P }p{Q} ti

i

ti l l y t

5

i

i

t {P }p{Q} i tl y i i i t i t i t l ity l y t i i it i l t t t it l i l z t t l it t l y l t t t l tt t t i ti t t t t t ti il l t t l y ity i t t y l i it t i t l i t ity i l i it t t i t l ity l t l l y i il l i l i ti l i t y ti t t it t t ti t t ty l t l y t t it i lti y i l i l l t l t i y t l t y t ti l y t l i y t t 0 t t t t l i i l y t t l ity t

i

i t t

t y t l y

l i it i t i t i t l l ti i t ti y l t ti

it t ti ti i

ti t t t i t l

l y

l t l

t

l l l i t ti t t l t i lt i t i ty y

t

i

l it

t t i l y i ti l l y l t it i l t t i t it i y

6

Wladyslaw M. Turski

lt t t l t l t il l l y l l t t l l y t t t t tt l lt t ti i t ti t t l y t t i i t t t t l i t t i it i l ti i ti t ii t t i i it l i ty t i t l t t il ity it t t t t i ti t t t l y l li t t t t ti l l y t t l y t i

i t l y t i

t tl y

ti

t

t

it t

i t t

lt i l it t i l y i t i i i t

i i

it t i i

t t i t t i il y l t t t t t il l t i i t ti t l l i t ti l i l t ti l i t t t i t y t t l t i it t i l t i t t i i t i t ti i l l i l ity l t i ti

i

t

l y

l i

t it t

t l y i

t t l

t

i l l i l l y t

ti t t l it t y it i t ti ti l l i i l ti t it t i t ti t t t t i t t t t t i t t t ti l i t i t t it t i t t y t y i y t t l it l l y t t t y l i i t t y ly t t t t y y l i iz

t t l

j t t i ity y i tl y i t i t l i ti l l y l i t lt t t it t t t t t j ity ti i ti t i i it l i l it i t t t t t t il y i t t t ti i ty ti i t i i i ti t i i ti l l t t t t t lt i tl y t i l t j ity t t ti it i t i i i y t y t ti i y t lt t l t l t i t i t t y t i t t it i t fl l y i iz i i li t tti l i t t i l i ti l y t t

Essay on Software Engineering at the Turn of Century

i t

tt

7

l y i t

l t ti i j t i t t t y i ty i l l y l ti i i ti i li it l i l ti i ti lfl t ti t t i l i t i l i i t y t l i i t y ii l i ty i t t t it i t l i ti t il l il y l l t it i t ti i t y i l l i ti l y t i t ti t t t i l y it y l i ti t i i i l t ti i i t i ii l ti t i i l i i t l l i ti t i t y ti l t ti t t il l t i it t i l i ti t i l i ity t i i ti 2 t t t t t i i i i l t {P }p{Q} i i i l it i t t i t l i l l i ti t y t i t t it t t l t ii l ti t y t ti i t t i t i i t y t i t t t it i ti l t ti l i l y i i l y t it i t i i l lt i i t t l it i t t i t t {P }p{Q} i t t t l ity t y t i t t t l i i y j t l i l y t t t i i it l t t t t y t i t t i t l ity i t i li t t y t ti t l it i t lt i i t i i it ti j t t it ii l l t t l l y l l t y i tl y t i t it t t l ll it l t i t t i t t t {P }p{Q} l i t l t i i it i it i t y t t l t t l y t t t il l t l l ti l l y i i t t li t t t l l t i l i l l l ity t y t t t t t t i y i ti t t t t t l y t i it t it i ity t i l y i i l iz i it y t i t i t l ity t fl t i t i i it t i t t i lt i l t i l ti t i lt t y t t j t ti t i l t i t l l y t i it l i t i t t t y t i l l t l y lt

2

At the Garmisch Conference, A. Perlis prophetically observed: Almost all users require much less from a large operating system than is provided.

8

Wladyslaw M. Turski

t y

t

l ti i l ti ti it t i t i t i Ctrl Alt it l l t t t t i l l y t lt t i y i l il t l i i t t t t i i i i it t ti t ti l l y i t y it t y i ti t i ti t t i t y t t i {P }p{Q} t i it p t t t t i ti t i i i t l i it i t t t l t i t t t {P }p{Q} i it i i l i it i l l y i t t t lt it t l t t l y t ti t ti y i i ti i y i it i l l it i ti l

t i i t ti i t

t

i

t t

3

t

y

Del

i

l

A Linguistic Aside l i

t i t it l it iz l l i i l t i t l l

i

l i

4

it i tt t i t t t tt t i t t i i t ti l y i tl y i t l lt i i

i t t t t

t i

t l l l t ity i ly i

l it i it t

ti

t t l y i

A Short Treatise on Model Theory with Applications i ti t

y

t t

ti

l l y t ty i

l t t y

l

t l i ii l y i t t l it t t D, T t t D t y l t t y t i D t i T t t t i t l

ll

li i t it t l t t t it i i l y i l l t i it i it i t π t it i t l t lt i ti t i i li it t t it t i it i t t t l l

i

t

i

l it

t

t

t t

t i t

ti i l i i t i ii l

y 3

t

t y l i ti l it l i ti i t tt y T i i D T lT, D i t i i t t ti t t t t t t t i i t t t t t t i t D, T t y l l i t i t t ti t i i t ¨ l t i lt i l l l t i it ti i i t i ti ti t y i

Essay on Software Engineering at the Turn of Century

l y i l l t t i it i t

9

t

i tl y t t it ti t l t y T i t l i i i t l l i t t t t t y l it i t i t t ti i i i it t i it i l t t il y ti l i t t t tl y l i l t t y t y i il i i i ti ti i t t l l l it ti t l it ti t it t y i it t t l t i t y it i t t l t y t t li it t t lt t i t t it y t i it i l l y t t t t y t i t t l t y i l l W it l t ti l lM t y it t ti l l i t t t it i t l ti i i l i l t t t M, T lt i t t t W, T i i l t i ti t t i i t t t t t T t t i W i t y i t i t l i l i t t t t y i i li t l il i t t it ti i ti ti i t lt i t l i ti t t i l i l t t t T i i l i t ti i t ti t y i t t lt t i l t t t i y i l l l l t t t i i ti l y i it i l l y t y l ti i l t t t t t l ity i t y ti tl y i i ti i t W, T l W i l t l i l t i t i i it y t i ti t t i l i l t t t t l t t ti l t t t t i t t y i it l l l y t l t t y i l lt t l i t y i l lit i t t l iz i i y i tl y i t i t

5

Specifications

t

t i l t lt i

i

i

t l

t i l

it i t

t t t

t l l l t l t i ti it i ti i t i t y l y y it t lt i i t t l it l i ti i i t t

i lt t t t t l y t i i l i it i i ti ti ti t i tt

ti t t t t t y t l i ti i t i i i ti t i i i l i t {P }p{Q} i t i ti t i t t i i tt t t t t it i ti t l i ti i i l it t l l l t i ti t

10

Wladyslaw M. Turski

i

ti il t i l ity t i l y t i t i t t ti t t l t l i ti lt t i ti i li ti ti y t t i ti i t l i i i l y i ti t yi l i ti t t l t it i it i l ti ti l it i tti l l t i ti i it i i i l y y t i t i t t i t t ti l l y t l t l i ti l ti t i t i t l ity t i t i y l lt i l t ti ti l l y t t i t l i ti l t t t t l l t t i t ti i l t ti t l tl t i t i t t i l l y i t it l l l y t t i l y l i ti i t i lt j t i t i t i it l lt i l t t l i t ti ti i t ty i it t t i i t i t t ly t l i t t li it i ti l l i t tt t i t t il l t i y l i ti i t i ti i ty t t l t ii i l t ti l t y i l y i i it t l l y t ti t t t i ti l i i it l l y l t t y t i t i l i y t ti l i t t t t t y i t i it l t i li ti l i t t it t l y l y i l t t ti t t l t l i t i t t t i ti i l l y l ity i t t t t t t y3 t i ti i it l l y t i l ity it y l t y t t l i t t t t l i ti t t y y ly i ti it i i y i t t i it t l i ti i i t t i t i t y i l l t i l l y i t l i l i ti t l i lt i t t i t l i ti t ti t t ti y i i i ti t l i t ti l l i t t t i ti t l i i i t t t i t t l t fl t i l l l l y i t it t i i t i t tt i t ti l y t t t i t y i l l l i t i t i t t ti t t t i l y t l t it i i t l it it i t 2000 ti

3

This is not to say that I advocate the other extreme, vividly described at the Garmisch Conference by R. M. Graham:We build systems like the Wright brothers built airplanes - build the whole thing, push it off the cliff, let it crash, and start over again.

Essay on Software Engineering at the Turn of Century

y

i

t

it i l t t t lt i i t i y i il t t l t t i t li t i y i il l y i l y i t i t t i t i t t i t t t y i l t t t l i y l t t t t li i ti i ti l l y t y lt t y t l l y ti i l l t ti lt t i t l lt i t t i i l t t i t t i i l i t t t t it i t i t ti t π t y l it i t l it ti i t il ity t i t t ti l l t t ti l l y i t {P }p{Q} i i l i t l i i ti i i i t i ti i i l lt y l y t t y ti t i t l i t i ti i il y i i t t l l y i l t t il y i t l ti t i t {P }p{Q} i i l i t y t t t i t t i l ity t l t y t t t t t t y l l t y l t y t i i t i t l i t i l t y t i l t l l l i ti t t it y t y i i t t t i ity t i ti l t t t t t t li i t l ti l l y t i t t t l i l y t i t l t il y li i ti i y i lt t t i ti i i i ti i l i t t it t t t i l it t i t {P }p{Q} i i l i t i i ii it i l t l t it il l t y t t l t t y t t t t ti i t t l l y i t l i i ti t l t t i l y t l t y i lt i t i i t t i i ti l i ti l i it i i i t i t l i t t y t i li t ty l i t i t i t l it i l y t t t t t i i l t lt y t i ti i l i i t t t i i l y t t l ti t t i lt t i t t t t t t i t t t i i t il ity t l i t y i lt i t l i it l t t y i lt i i it t ti l l y i l l i

t ill y

11

12

Wladyslaw M. Turski

y t

i t tl y t i l i lt i l l i t i lt i l t i t i t l it i tt t t l y i t i l l i lt i t i t ti ti lt i t t y i lt i t t i t ti i t y i lt i i i ti li it i t l i t lt i i it i ti it i i l i i i l i i l y i it i t i t l i ity y ti i li t t t it t i il t i t l i i ti i ti l t i l t i t t t {P }p{Q} ity i y i l i l i i ti l i i ti l t i t ti l i l it t i i y i t t i li i ti t lt y t t l i i t ti l i il ity t l il t i t i ity t l l t t li t t t it i t i 4 yt i t i i l y t i t t i lj l t i l y i y t l i ity l i t t ti l i l t t i t y tl y t i t t ti l i i ti i lt i i i i i t i t i l i ti t j t i t i i t ti i il l t t il ly i i i ti i it i l y t l i t l ity t i l i i i l y t i ti t t t i i t y t t ti i il y i l ll i l i t it t i t t it t it l i l t t i t t t i l i l il l t i t t l i i l it j t y t t t l i t i l l y i i t l l i t t t i tt t t i l i ti l i ti i i l y ti l y l i it i l i t i i t l li i ti tl t t i l i ti i l t i l t ti t y t i l l y t l i t l i ti i y

4

For the vast majority of software engineers, the perennial question of whether (undefined = undefined’) ≡ true or (undefined = undefined’) ≡ false is of precious little significance and even less consequence. There, what matters is that undefined should never be encountered and — if it happens — should raise all sorts of alarms. The same, of course, goes for similar concerns with other errors of design: while they could be viewed as a fertile ground for subtle considerations, in the bread–earning community the need to avoid them is dominant, and the guarantee that errors, if made, will not remain undetected is a prime concern.

Essay on Software Engineering at the Turn of Century

i t

l

t ti t t l l y

t i

i t t l l ti

ti l y i i t i t tt t i t i t it i Σ t t

2 3

l y it i i i

t

i i t

i

l l l it

t i

l

y t i t iy t i t t it i l t it t t t t i t i t l i y t i i i it i ti t t t li t t y t it i ji y l t l l i ti t ti t t l l i

i ti

it

l i

l i ti

13

i

ti l i ti

ti

l

t

t i

ti

t

iy y

i t t t t t l it t l i ti i tt t t i i i il l i t l l t i l i y i y t l i l ilt i l l l i ti t j l l l i it i l t l i

l i li i {α}i U B

U Σ→Σ B Σ×Σ →Σ

ti ti

t t i i ti s 1 , s2 ∈ Σ t i t l p 1 , p2 ls2 , p2 l lu s1 , αu p y u ∈ U ls1 , p1 y b∈B lb s1 , s2 , αb p1 , p2 t i y t l l i t t t i l y t ll l i it l l l ity it i t t t t i l l ti ti l i ti y i l t ti l i ti t t t i ti t t U B t ti t t t t ti il ity l l ti t l it y tl y i t ti ti t l i t i l l t t i t t t l li t t t t y

6

Production of Software i i

l i l t

i y

t t t

– –

t lt l y t y

i it

i

i i

ti

t

i

l

t

i

il i

ti

l ity

lt i

t

t i l

t t

t i

it t

t

i

y

t j i tl y

i

l

y i

i ti

y t

i

i

t t

t

t t

y i t y l i

l

ti ti t

14

Wladyslaw M. Turski

y t

l l y

y i i t il it i l t i t it i t t it t i y t i ti i t it t l i t ti t it t i ti y t i l i t ti i t t t i t i t it t t it l i lt i t t it t i l y i t i it t ti t i ti y t it l y t t t it t t t i t i ti l li i t ti t t l t t y t l t y i t ti l li t t t i t l l t i l t t t i t lt t t t y l t i tl y l i t ti l i l i t t t t l it l i t i it t l y t l t i l l lt i i t i i t i i i i i t il it i t t i i i t l y il i it i t it i it i l t i i t j i ti t i i l t t t ti i y i l l y t l l ti l i ti t i i i y t ti l t t t i l i l i i l t ti i t t t i t t i i ti i t i t i t l l t i l t i it i t t t l i t ti t i t t i ity i i i i l l y lt t i l t ti l y i t l l i lt i i i l li i t t t t i t i ti i i it i t ly t i i l it t l l i y i t i t it t l t y t y t l t y l t ti t l it t y t t i ity t l t t ty i ti i t tt t t t it i ti l y t t i l y t t y j t y t t i y i t ti t iz y i i t t it t t i l it i t il y t t t il l i i t l l l t y t

t y t l y t t t 5

t

l i

t t i

l

y l t t l l t i ti l

t

i t5 t l

y t

y t t i ti ti

i t

t

i t t i l t

It is large systems that are encountering great difficulties. We should not expect the production of such systems to be easy. — K. Kolence at the Garmisch Conference

Essay on Software Engineering at the Turn of Century

t

i

l

i ti

t i l l y t

t

i

y ti

ti l l y i t t i t it y l i i i i l l i t t t ti l i t l i i t t t t ll i ti i l it

t i

t

tt i t l t i l i ili it t t t t i t i t l t y t i l l l l i ti y i l i ti t t l t it l t i y t l t y t t l y

l t t

i

i l

ti it l

t

t t

l

i

i l y i y

t

i t ti tl y i l i

tt t

t

i t y

l

t i t t l i i t

t ti l l t i i t t

y it i

t it ti t

l i

i

l li ti

6

7

l y t

t

y t l 6 t i t t t i t t ti t l t t t i l t t i ti l l y y l t

l li y i t t t i l l t i ti iz t t tt t i l y i it t t i t t i l l 7 i i y t i

it

t

it t

i

i i

i

l y l l i l l t

i

i i ty t i t t t i i t y i i i t i i fly ti l l i t ti ti i t l t l i l t t t l l ti it i t i i i li t i i t t t j t t i i l i l y t t X l l lt T t y ti l j t t i y i y t 2X 0. X l l l t 0. T 2T t tt i ti l t t l t i i y i t t i i t i t y t t l l y t it i i l t l l t i l t l i t t t t l it i t t t t it li t t t ii

t

t t l i l y i ti t

i y t

ti l l i

ti

t

t i i t ti

15

i ti

i il ity i

cf. K. Samelson at the Garmisch Conference:By far the majority of problems raised here are quite unspecific to software engineering, but are simply management problems. ... Perhaps programmers should learn management before undertaking large scale jobs. In a hard to describe way it is indeed the organisation, as distinct from individuals it employs, that gains the relevant experience. Of course, the employees, each in her/his special way, also gain experience from the completed tasks, but there seems to be a clear synergy effect, making the combined gain larger than the sum of individual ones.

16

Wladyslaw M. Turski

y i

l i

t

l t t i

l i t

i t t t l l i i i l i t t y t t it i i l l it l t t

l y i t i l i i y i ti t i tt t t i i t it t i ti l tt i it i li t t i t t ti i ti t t ilt i ti i i t i t i ti i t i i i l t y i t i t fl ti t t t y i ti yi l i t l i ti t t t ti i

y i

i

i

t

t

t t

t l t t t i

l y i i

tt l i i

i y l it t l t t

i

l y

it i

i t

y ti l y i i t t l t

t t t

t

l l t tt l y y il i t i j l i

l i i l ti t i

Programming for Behaviour ti

i lt i l

t

it i i ti t i ity

l y t i i l i t i t 30 y y t ti l iz t i i y l it t l t t l l i i t i it i l t t l i y l i l zzl i l i t i it i l t i t t i ity l i ti l i t t t t i i li t t t t i l t t y l l i l y t i l l y l lt t t t i t t t t i t it i t l i t it t i i i l i i ti t i i i l t it i t t t it l t tt t y i t it i y lt t y t i j t y t y l lt ti i ti l it t l l t l l t t lt t y t i i t l i t y i i t i t ti it t t y l t l i i i y i l i t it i ll ti l l y t i l i t t i l l i l lt i

7

t it

i t

l i i t i l lt i t l l ti it i t

y t

i t

t i

t t

i i

i

l y

t

y ti

l i ti i it t il l l t yt i t i ity it i

Essay on Software Engineering at the Turn of Century

i

l

l

l

t it

t

i i ti l l – –

ti

l lt i

t t it

i

l lt i l l lt ti tl y t

t i

l t

i t

il i t

i l y

t it

l l t i l lt i t i i i i l ti t j t l t i i t i ti y ti i t i i t lt i t i t it i t t t ti i t ti i t lt i i t t li l y l i i t ti l y l it i tl y i t t t i t t ti t l l l i t l i li t t l l t l y t l li it i t i t il l t ti tl y it t i i ti i it t il ti lt it it i l t i t t t t l i

t i t i i ti t

i

t

it

i t

i

t i t

i i

y

l l l ti t it i

17

t

ti l ti l t l t t

l

l it l t t i

ti t

t i l lt i i

i i

t i

i y

l

i i t t

i l t l it i do i t R t i t i t l do before S t i fl S – t it it t i i i l i i i t i t t t t i t t i t t t t i t t tt y t l j ti t t t t l l ti i i i t t tt i y t t t t t it t y l t t l l ti i i t i t t t

–

t as long as R y t t l l y

t t i

l

l lt

iy

l ti l ty l ity t l l ti i ti t ti l i it i t t t l l l i l t t i i l i t ti l i i i t t t ll i it i t ti t ti i l y y i ti i i l t tt i t ti tt t y t i ti l i i i i l y ti l t l li i ti t i i l i it tt i i ti i

18

Wladyslaw M. Turski

t

8

l i

l i

i

i 8 l i it

t y t l i i t i l i it t l y l l t i y t i l y l l t y t i it i i l i t i t ti i i i t l i i il i i ii it l l t ly t l t i t t l lt i i ll y i l tt l it i t i l i t ti t ti i l l l i t t i t ti lt i t l i i ti ly l t l l i t l il i t l it t i t y l t it t i it i t it t t y l il i i i t t it l y t lt i il l i y ti t t ilt i it i i i l i t it t i t i ti t it i l i t it it y l it t i t l li l it t l i l t i t t ti t i t li t t it i t i t i t i il i t t t t t ti t y it i t t i t t l i t i i ti lt i t t i i l l y i t i i i j t t i t i i l t l li y i l i ti t t t t t j t i l i t i t i i l l y t l i t t i ti l l t t t t t i t i t t t t l ti t t y i t i i i l t ti i l t t l lt i t y y t l i it l i ity t i y t i t t lt i it i i t t l t ti t ti t i t l i t i i l t t l it i t t ti t t i tt t t i lt t i i it i t t it i l t ti t y t t tt i l t ti i t i l t ti ti t it t l t t it t t i l y y t y t i l t i l t ti ti l y i t l l t t i t i t t t ti t i i l l ti t i y t t i lt t ti i l i t t ti t l l y l t il it i i i t y i l ii l t l y t ti t i t t i fl y t l t i il it i i t it i t t t t t ti y t i ti t ti l i ti

ti

I am using the expression “time-like” in order to avoid any suspicion that what is implied is the well-behaved, uniform time of classical physics and theology.

Essay on Software Engineering at the Turn of Century

ti i i t t

it t t t l t t i

t t i

i

t

t

i l l y

ti i

ti

ti

i t

l lit t i t i i i

i i t t t t l lit t t i t t t t ti t i t t t it t i i i it i t ti t i t t t t t t i t t i ti l y t t i t t i t lt l y i i l t lt t y i tl y y t t t

t t i t t y l ti t t ti t i y i t t ti ti i l t lt y ti t ti l y t ti t t t t i i i it 9 i l i ity i l i ti i i t t i ti y l l l i

t

ti

t i i t i i i ti

t t y t l i li t ti i y il l t i t it i y l it t l t i ti il

t

and and t t

i i t

i

y

y

i y

→

and t

19

t i

i lt t i l i

i

ti t

i

t t

y

t i

→ →

l i ti l y l lt il t l y t i t t it t l i i t ti i l y i t y t i t t i it l ti i ti P, P → α t i y t i ti i t t i t i α ti t t t t ti y i P j t i ti α t i ti y l lt i y i l t t t l fl t t i i ti i i t t il l t i ti l t t l ity t i lt i i t l i t ti t t τ >0 t t t ti ti t t y t l t τ t y y l i t i t it i l t τ i l i l y t i i t y t l i i t i i t y t i l l y l l tt t t l it t i t t i l l lt i l i t i il l i t t l y i t ti i i l i t t i l l ll i i l l y 9

t t t

On closer scrutiny, the apparently insurmountable implementational difficulties of this approach turn out much less forbidding.

20

Wladyslaw M. Turski

i i

l lt i

t

l y

t

t li i t

i l l y t t i l i il it i

i i t

it

i

l ll i i

l

i i l t i l

i t

i t

it

t

l

t l l i t l l y i i lt y i ti l i lt t i t t t i l l l l t t t i i t l y t l i t t l t l l i t l i l i l l i t il l i t ti t i t i t t y i t i il t i t t t i t t i i t t t t y l l t t l

8

i i ti l lt i l tti

t

t ti l y t i

ti

ity t i

l t t

y

y i

Conclusions i

i ti l l y i t l lt l l y t it t t 0 y t t i l l ity t l t l t t ti t l i tl y il it t t i i i l t t t l l i t l y i l i it i l y t i i t l ti i ti t t li i ti i l l y l i l it i l l y i l li l l l ity l t l i ti i ti l l i l y t i i l i l t l l t ti i t t i y t i t il l i t i y i t i l y l lt i t t t ti l l t ti i i ti l y t y t l l t t t i ti il i it i i l i t t t i ti y t i t ti t t ti ti ti t i t t i t l i i i t i i l y i t l lt i i ti t l t l y t i t t l t y t l t t t t ti l i i y t i t i t i i i t t i t t t l lt i t i l i l y t t i l l i l l y i t t i il i t t it t i i t l l t

l t it

t

y t

i

t it

t

t

i

ti ti

t

Memex Is Not Enough Richard Mark Sol ey Object Management Group, Inc. Needham, Massachusetts

Turning his t hinking final l y from t he appl icat ion of science t o mil it ary needs, in 1946 t he great scient ist and research organizer Dr. Vannevar Bush of t he Unit ed St at es’ wart ime Office of Scient ific Research and Devel opment wrot e a seminalpaper ent it l ed As We May Think. In it , he chal l enged us t o discover way s t o encode, l ink and in generalmake more accessibl e t he huge st ore of human knowl edge devel oped t o t hat dat e. In t he l ast decade, t he emergence of t he Worl d Wide Web has been hel d up as t he embodiment of t hat hal f-cent ury -ol d vision. Whil e t his is a reasonabl e y cl aim, even if t rue it is simpl y not enough. Human beings, and more import ant l our sil icon-based informat ion processors, do not simpl y encode, st ore and index st at ic dat a; t hey creat e new dat a every nanosecond. Links between st at ic dat a, st al e t he moment t hey are creat ed, are simpl y not enough; t he realchal l enge is to l ink t he informat ion processing power we have direct l y. At t he core of t his effort must be sufficient consensus for int erfaces not onl y t o st ore and l ink dat a, but t o forward and l ink comput at ionalpower. This effort has informal l y been underway for decades, wit h t housands of “st ovepiped” sy st em t hrown t oget her wit hout any pl anning. We must renew our effort s t o agree st andards for l inking informat ion asset s, for mundane (but economical l y crit ical ) “business t o consumer” as wel las “business t o business” suppl y /service-chain ems as wel l . int egrat ion, and for more int erest ing probl Ty pical l y such st andardizat ion effort s have cent ered on t he l owest l evel s of t he int eroperabil ity prot ocolst ack, incl uding t he phy sicalcabl e or t he by t et ransfer l evel . Even newer approaches based on document ty pe ext ensions (e.g., XML) have focussed onl y on dat a movement . Unfort unat el y , it is t he much more difficul t piece of t he puzzl e t hat is required for t rue processing power sy nchronizat ion: t ransact ional , persist ent , secure appl icat ion int erfaces (at t he evel ) are l ower l evel ) and market -specific int erface definit ions (at t he higher l absol ut el y crit ical . Memex—t he avail abil ity of l inked, indexed dat a—is a great st art ing point for int egrat ing t he sum t ot alof human knowl edge, as Bush saw a hal f cent ury ago. d focus on By simpl y impl ement ing t his vision we abandon it ; inst ead we shoul providing t rue appl icat ion-l evelint egrat ion across worl dwide networks so t hat knowl edge may be shared t he moment it is discovered.

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 21–21, 2000. c Springer-Verlag Berlin Heidelberg 2000 

From Play-In Scenarios to Code: An Achievable Dream (Preliminary Version, January 2000) i

l

The Weizmann Institute of Science, Rehovot, Israel. [email protected]

Abstract. We discuss the possibility of a complete system development scheme, supported by semantically rigorous automated tools, within which one can go from an extremely high-level, user-friendly requirement capture method, which we call play-in scenarios, to a final implementation. A cyclic process consisting of verification against requirements and synthesis from requirements plays an important part in the scheme, which is not quite as imaginary as it may sound.

i li

i

l l

i

i li

l i j i i i ii l

i l 0 i l i i l i l l i l i l l i i i l iz i 3 l l l i i l ii i i i i i l fl i i 0 l l l i i i i l i l i i i i l i i i i i i i i i 1 i i li i i i l i l i l l i l i i i i i ll i i l i i i i l i i 2 ii l i i i i 1

2

li i

l fl i l l 3 i i i

i

l i i i i

l i

i i il

Of course, there are many other possible choices for a language to specify behavior, including such visual languages as Petri nets [29] or SDL diagrams [33], and more algebraic ones like CCS [24] and CSP [19]. This would be like saying that when you build a car all you need are the structural things — body, chassis, wheels, etc. — and an engine, and you then merely stick the engine under the hood and you are done. . .

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 22–34, 2000. c Springer-Verlag Berlin Heidelberg 2000 

From Play-In Scenarios to Code: An Achievable Dream

il

i i

i i

23

i

i

3

system model structure

behavior

l

Fig. 1.

l i l l

i i l

i

l

l i

l i i

i

l l

2

i

l i i l

l i

i i l l

i

l

l il i

i

i il il i i l i l l i i i

i i i l

i i

li i

l

i il i i

20

i

l l

l l

i l l i i l i li li li l j i i l l i l i i j i l i li i i i l 0 i i l i i l l l i l l i visual formalisms i 0 l i l l j i i i l l 3 i 3 i i l i i l i li i l i i i i l i i i i i l i i li i i i j i l i i l i j l i l il i i l i l

i

24

David Harel

i li

i

i i

i

i

i j

i

i

l

l i l l

i l i l l i

i i

l i i

i

j

i

l

i l i

j l

i l

li i l i i l l l i li

i

30

i

i

l

i l XUML

j

2

i

i

i

3 i l

l X-UML i l

i

i

il i l l

i i i l i i

i

2 i

i

l l

i 30

i i

i i Base-UML i i l i l l l Executable-UML 3 l l i il i l l l i li l i l i i l i i i l l i l l i il li i i l i i l l i i l i i li i i l ∗

i

l

∗

l i

l l

i

i

2

i i i

l

l l l i i i i i i i i i i

∗

4

i

l l i i

l l

3 i l l l

l

4

l l i

i

j

3

i

j

j i

3

i

i

l

l

l l 3

20 l

l i

l i i i

li l l

i

2

i

l l i

i

i

i li

l i

i

i

i

i

j i i

i i

l

i

l i

i

i

l i

l i

i

The UML has several means for specifying more elaborate aspects of the structure and architecture of the system under development (for example, packages and components), but we shall not get into these here. Our emphasis is on classical object-oriented structure and full behavior. See also [11] for a more detailed discussion of various kinds of model execution that one might desire.

From Play-In Scenarios to Code: An Achievable Dream

25

code generation

code system model structure

behavior

(Base-UML or SA/SD)

Fig. 2.

l

i

l l i

l

l i

i

l l

l i i

i

l l

i i

i

i l l

l i

i

l i

l i

l l

i i i

i

il l

i i

i

i

i

l

l l

i

i i

i

i l l

ll i

i

i

i l

i

i i l

i ll i i

i

l

l l

i i i 22 23 i i l i i i i i i il l i i i l il l fl l i i i i il l l l i i l il l i i fl i i l l i l i i i i i i l i l j i i message sequence charts MSCs i i ll l l i i iz i l 2 i i i i l i l i l l sequence diagrams i i i i i j i i i l i l i l i use-cases 2 l l i i l l i i

i

i 2

26

David Harel

i

li

i

i

i

i

i

l i

i 5

l i

l i

i j i il i i i l l il l i

i

l

i i

i i

3 code generation

code system model structure

testing and debugging; model execution

use-cases behavior

requirements development methodologies

(message sequence charts)

(Base-UML or SA/SD)

l i

Fig. 3.

i i i

i

l i

l iz

i

i l

from

il

i

i i i

l l l

i

j i

i i i i i i i 5

i

l li ra l i l

i

l i i er l l i j i i l l

i i il i i i j i i i i i 2 i

l l j j

i i i

i

l

i i li

i i i i l l j i

i l j

l l i

i l

ii

l i j i i l l

li

l

l

l i i

i

l i l l i l

i

il l l i

We mention tasks and processes here, since although we couch much of our discussion in the terminology of object-orientation and the UML, there is nothing special to objects in what we are discussing.

From Play-In Scenarios to Code: An Achievable Dream

l

i

l i

i i

i

l

l

l

∗

∗ i

i

l

i

i i i

l i i

6

l

l ∗

l

27

i

i

3 i

i

l i i l

l l i i l i l

i

l

li i

l i i i

i i

l

i

i i

l i

i i

i l i i

i l l i j i l i

i

i

l i i

i

l l A

i

7

fl i

i B

i

i

i l l li B

A

i i

li

i i l i i l ll i i i i l i l il l i i l i

l

l

i i

i

i l

i

i

i

i

i

i

i

i

i

3

i ii

i i

i

l

i

l

i l i i

i

i l

i

i i l i

i i l i

l i l A ij

i i i

l

7

il l i i i l i i

i

l

6

i

i

il

l l l

l

i

i

l

i

i

i

l

i i

i

i

i i

i

i

i i l

i i l i

i i

l i

i

l i

i

i

i

You can’t simply prepare a collection of 1000 scenarios and call that your system. How would it operate? What would it do under general dynamic circumstances? How are these scenarios related? What happens if things occur that simply do not fall under any of the scenarios? And on and on. Rhapsody actually executes its Base-UML models by generating code from them and running the code in a way that is linked to the visual model.

28

David Harel

i

i

l

i

i i i i

i i zzl

l

i

i

i l l l

i i l

i i

l

may possibly i i i j ... 8 i i i

i

l l i i

i

i i l l must ii i

il l

i i li

i i

2

i i i l i l i l i

i

i

i

i i l i 3 30

i

i

i

i i

l i

li

i

i

i l

i i

i l i

l l

i i zi

i

i

i

i

l

il l

i i i anti-scenarios i

l l i l i i l dis l l

i

il i i

ll i

i l l live sequence charts LSCs i l i i i l i i i l l i i i i i l i l l l l l i l l l i i ii i i i l i l l l i i i l i i i l iz i i i i i i l i l i l i l i i i i i i l l li l i i l i l l i i i l i l li l i i

∗ i

i i

i

i l

∗

i

i l

i

i

li

i l

i i

i

i i i i

hot l i i i i i

∗

i l

i i

8

l i

i

l l i i j i

i i i li i

l i

i l l i

l

i j

i

l i i

Usually, however, there is a minimal, often implicit, requirement that there should be at least one run of the system that winds its way correctly through any specificed sequence chart.

From Play-In Scenarios to Code: An Achievable Dream

29

code generation

code system model structure verification

use-cases behavior

requirements

synthesis

(LSCs or temp. logic)

(Base-UML or SA/SD)

l i

Fig. 4.

i

i

i i il i i l

l l i

i

l i

3

l i l l i

i

i i

i

li i

l

l

i

l 9

i i l i i i i l i i i l i i i verification i i l li 0 l l l i i i i i i i i l i i i i l l i i l i i i i l l iz i i i l ll i i i i i l i l i i i i i i l i i not l l il li i i i having i i i i i i il li i li l i i l i i i i i l l i l i i i l i l l i i l i l l ll i 2 3 l i i i 2 i l i i 9

Requirements could equally well have been specified using some powerful form of temporal logic with path quantifiers; see, e.g., [22, 23] or certain kinds of timing diagrams [32].

30

David Harel

i

l

l i l li

li l ll i il l

i

i i 20

i i

l i

i i l

i i j l

il ii

synthesis l

i

i il l

l i

l i

l

i l

i l

i l l

i izi

l l i

i

i l

i l

i i

i l ll i l li li i l l i l i

i i l l

i l

i

i

i

l l

i

i

l i li

l

l

il i

i

i i i

i

i i l

i

l

l

i l

i i i

i i i i

i can i i

i

l

i

l

l i i

l iz

i i i i i ll i 2 2 l

l i

i

32 l i l i l

i l i

3 izi

i

i

li

i i

i

i i

l

l l

l i l li

l l i

l li i

i i i

i

l l

i i

l l l

i

l l i il i l

l l l i

i l

i

il l l i i i l

i i

i

l

i i

i i

i i i

l i

i i

j

l iz i

l l l

i i l

i i

i l i

i i ii i

i

i i i i

i

l

l l

iz

il l i l

i

l i i l

l i

i any i

i

l i i

i

i

i l i i i i

i

i i l

l l i ll i i l i i l

l l l

l

l

l i

i iz i

l i l il l

3

From Play-In Scenarios to Code: An Achievable Dream

i

i

i i

i l l

i

i

il i il l il l

i

l

l

il i i

i

i li i li

i

i

i

l i

i

l i ii

i l l

i

i i i

i

i

i i

l i

i

l

i j i

i i i i

l il i

i

i

i i l i

l li i il i l i

i

iz i i

i fl l i l i i i l il l i i il i il l l i i il l

il i ∗

∗

∗

l

i

i ii

i l i

il l i

i i ii l

i l

l l i

i

l i l il i

i l

i

i i l l i l il ll i l i i l l fl i i i i l l i i i i l

l li

l i

l i

l

i l

l i

i l l l

i

il l i i l

i l

i

i

i i il l

i

i i l l i

i

i l

ii j l i i l il l i l l i i i ll i il i

li

i i l

l in

l

i l l

i

i i

i

i i l

l

i

i

i

i li

l

i

l i play-in scenarios

li

l out

i i

i

∗

i

i

i

i ii

l

i i

∗

i i

l

l l

j ∗

ll i

l l

31

i i l l l l

l i l

i

32

David Harel code generation

code system model

use-cases

model-code association

structure play-out scenarios and

play-in scenarios

verification

behavior

requirements methodologies and

synthesis (LCSs or temp. logic)

(Base-UML or SA/SD)

i

Fig. 5.

i i don’t i l

l can’t

i

l

l

i i

i i

i l

i i

i

l

i

l l

l l

l

i

l

il l

i

l i

i i

l i

i i

l l

i

l l

i

il l i l

i

i

l

References [1] [2] [3] [4] [5]

[6] [7]

Booch, G., Object-Oriented Analysis and Design, with Applications (2nd edn.), Benjamin/Cummings, 1994. Clarke, E.M., O. Grumberg and D. Peled, Model Checking, Mit Press, 1999. Constantine, L. L., and E. Yourdon, Structured Design, Prentice-Hall, Englewood Cliffs, 1979. Cook, S. and J. Daniels, Designing Object Systems: Object-Oriented Modelling with Syntropy, Prentice Hall, New York, 1994. Damm, W., and D. Harel, “LSCs: Breathing Life into Message Sequence Charts”, Proc. 3rd IFIP Int. Conf. on Formal Methods for Open Object-based Distributed Systems (FMOODS’99), (P. Ciancarini, A. Fantechi and R. Gorrieri, eds.), Kluwer Academic Publishers, 1999, pp. 293–312. DeMarco, T., Structured Analysis and System Specification, Yourdon Press, New York, 1978. Dijkstra, E.W., “Notes on Structured Programming”, in Structured Programming, Academic Press, New York, 1972.

From Play-In Scenarios to Code: An Achievable Dream [8]

[9]

[10] [11] [12] [13] [14]

[15]

[16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26]

[27]

[28]

33

Floyd, R.W., “Assigning Meanings to Programs”, Proc. Symp. on Applied Math., (Vol. 19: “Mathematical Aspects of Computer Science”), American Math. Soc., Providence, RI, pp. 19–32, 1967. Harel, D., “Statecharts: A Visual Formalism for Complex Systems”, Sci. Comput. Prog. 8 (1987), 231–274. (Preliminary version appeared as Tech. Report CS84-05, The Weizmann Institute of Science, Rehovot, Israel, Feb. 1984.) Harel,D., “On Visual Formalisms”, Comm. Assoc. Comput. Mach. 31:5 (1988), 514–530. Harel, D., “Biting the Silver Bullet: Toward a Brighter Future for System Development”, Computer (Jan. 1992), 8–20. Harel, D., and E. Gery, “Executable Object Modeling with Statecharts”, Computer (July 1997), 31–42. Harel, D., and H. Kugler, “Synthesizing Object Systems from Live Sequence Charts”, submitted for publication, 1999. Harel, D., H. Lachover, A. Naamad, A. Pnueli, M. Politi, R. Sherman, A. ShtullTrauring, and M. Trakhtenbrot, “STATEMATE: A Working Environment for the Development of Complex Reactive Systems”, IEEE Trans. Soft. Eng. 16 (1990), 403–414. (Preliminary version in Proc. 10th Int. Conf. Soft. Eng., IEEE Press, New York, 1988, pp. 396–406.) Harel, D., and A. Pnueli, “On the Development of Reactive Systems”, in Logics and Models of Concurrent Systems, (K. R. Apt, ed.), NATO ASI Series, Vol. F-13, Springer-Verlag, New York, 1985, pp. 477-498. Harel, D., and M. Politi, Modeling Reactive Systems with Statecharts: The STATEMATE Approach, McGraw-Hill, 1998. Hatley, D., and I. Pirbhai, Strategies for Real-Time System Specification, Dorset House, New York, 1987. Hoare, C.A.R., “An Axiomatic Basis for Computer Programming”, Comm. Assoc. Comput. Mach. 12 (1969), 576–583. Hoare, C.A.R., “Communicating Sequential Processes”, Comm. Assoc. Comput. Mach. 21 (1978), 666–677. I-Logix, Inc., products web page, http://www.ilogix.com/fs prod.htm. Jacobson, I., Object-Oriented Software Engineering: A Use Case Driven Approach, ACM Press/Addison-Wesley, 1992. Manna, Z., and A. Pnueli, The Temporal Logic of Reactive and Concurrent Systems: Specification, Springer-Verlag, New York, 1992. Manna, Z., and A. Pnueli, Temporal Verification of Reactive Systems: Safety, Springer-Verlag, New York, 1995. Milner, R., A Calculus of Communicating Systems, Lecture Notes in Computer Science, Vo. 92, Springer-Verlag, Berlin, 1980. MSC: ITU-T Recommendation Z.120: Message Sequence Chart (MSC), ITU-T, Geneva, 1996. Pnueli, A., “Applications of Temporal Logic to the Specification and Verification of Reactive Systems: A Survey of Current Trends”, Current Trends in Concurrency (de Bakker et al., eds.), Lecture Notes in Computer Science, Vol. 224, Springer-Verlag, Berlin, 1986, pp. 510–584. Pnueli, A., and R. Rosner, “On the Synthesis of a Reactive Module”, Proc. 16th ACM Symp. on Principles of Programming Languages, Austin, TX, January 1989. Pnueli, A., and R. Rosner, “On the Synthesis of an Asynchronous Reactive Module”, Proc. 16th Int. Colloquium on Automata, Languages and Program-

34

[29] [30] [31] [32]

[33] [34] [35] [36]

David Harel ming, Lecture Notes in Computer Science, vol. 372, Springer-Verlag, Berlin, 1989, pp. 652–671. Reisig, W., Petri Nets: An Introduction, Springer-Verlag, Berlin, 1985. Rumbaugh, J., I. Jacobson and G. Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, 1999. Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy and W. Lorensen, ObjectOriented Modeling and Design, Prentice Hall, 1991. Schlor, R. and W. Damm, “Specification and verification of system-level hardware designs using timing diagrams”, Proc. European Conference on Design Automation, Paris, France, IEEE Computer Society Press, pp. 518 – 524, 1993. SDL: ITU-T Recommendation Z.100, Languages for telecommunications applications: Specification and description language, Geneva, 1999. Selic, B., G. Gullekson and P. T. Ward, Real-Time Object-Oriented Modeling, John Wiley & Sons, New York, 1994. Ward, P., and S. Mellor, Structured Development for Real-Time Systems (Vols. 1, 2, 3), Yourdon Press, New York, 1985. Documentation of the Unified Modeling Language (UML), available from the Object Management Group (OMG), http://www.omg.org.

Parallel Refinement Mechanisms for Real-Time Systems Paul Z. Kolano1, Richard A. Kemmerer2, and Dino Mandrioli3 1

Trusted Systems Laboratory, Lockheed Martin M & DS – Western Region 3200 Zanker Road, San Jose, CA 95134 U.S.A. [email protected] 2 Reliable Software Group, Computer Science Department, University of California, Santa Barbara, CA 93106 U.S.A. [email protected] 3 Dipartimento di Elettronica e Informazione, Politecnico di Milano, Milano 20133, Italy [email protected]

Abstract. This paper discusses highly general mechanisms for specifying the refinement of a real-time system as a collection of lower level parallel components that preserve the timing and functional requirements of the upper level specification. These mechanisms are discussed in the context of ASTRAL, which is a formal specification language for real-time systems. Refinement is accomplished by mapping all of the elements of an upper level specification into lower level elements that may be split among several parallel components. In addition, actions that can occur in the upper level are mapped to actions of components operating at the lower level. This allows several types of implementation strategies to be specified in a fairly natural way, while the price for generality (in terms of complexity) is paid only when necessary. The refinement mechanisms are illustrated using a simple digital circuit and a much more complex example is sketched.

1 Introduction Refinement is a fundamental design technique that has often challenged the „formal methods“ community. In most cases, mathematical elegance and proof manageability have exhibited a deep trade-off with the flexibility and freedom that are often needed in practice to deal with unexpected or critical situations. A typical example is provided by algebraic approaches that exploit some notion of homomorphism between algebraic structures. When applied to parallel systems, such approaches led to the notion of observational equivalence of processes [8] (i.e. the ability of the lower level process to exhibit all and only the observable behaviors of the upper level one). Observational equivalence, however, has been proved too restrictive to deal with general cases and more flexible notions of inter-level relations have been advocated [5]. The issue of refinement becomes even more critical when dealing with real-time systems where time analysis is a crucial factor. In this case, the literature exhibits only a few, fairly limited proposals. [3] is the origin of the present proposal. [6] addresses the issue within the context of timed Petri nets and the TRIO language. In this approach, a system is modeled as a timed Petri net and its properties are described as TRIO formulas. Then, mechanisms are given that refine the original net into a more detailed one that preserves the original properties. The approach is limited, however, T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 35-50, 2000. © Springer-Verlag Berlin Heidelberg 2000

36

Paul Z. Kolano, Richard A. Kemmerer, and Dino Mandrioli

by the expressive power of pure Petri nets, which do not allow one to deal with functional data dependencies. In [11], a system is modeled by an extension of finite state machines and its properties are expressed in a real-time logic language. Refinement follows a fairly typical algebraic approach by mapping upper level entities into lower level ones and pursuing observational equivalence between the two layers. In this case, observable variables (i.e. variables that are in the process interface), must be identical in the two levels. This leads to a lack of flexibility, as pointed out above, that is even more evident in time dependent systems where refined layers must also guarantee consistency between the occurrence times of the events. In this paper, we propose highly general refinement mechanisms that allow several types of implementation strategies to be specified in a fairly natural way. In particular, processes can be implemented both sequentially, by refining a single complex transition as a sequence or selection of more elementary transitions, and in a parallel way, by mapping one process into several concurrent ones. This allows one to increase the amount of parallelism through refinement whenever needed or wished. Also, asynchronous implementation policies are allowed in which lower level actions can have durations unrelated to upper level ones, provided that their effects are made visible in the lower level exactly at the times specified by the upper level. For instance, in a phone system, many calls must be served simultaneously, possibly by exploiting concurrent service by many processors. Such services, however, are asynchronous since calls occur in an unpredictable fashion at any instant. Therefore, it is not easy to describe a call service that manages a set of calls within a given time interval in an abstract way that can be naturally refined as a collection of many independent and individual services of single calls, possibly even allowing a dynamic allocation of servers to the phones issuing the calls. In Section 8, we outline how this goal can be achieved by applying the mechanisms described in this paper. Not surprisingly, generality has a price in terms of complexity. In our approach, however, this price is paid only when necessary. Simple implementation policies yield simple specifications, whereas complex specifications are needed only for sophisticated implementation policies. The same holds for the proof system, which is built hand-in-hand with the implementation mechanisms. Furthermore, the proof system is amenable both for traditional hand-proofs, based on human ingenuity and only partially formalized, and for fully formalized, toolsupported proofs. Finally, although experience with the application of the proposed mechanisms is still limited, it is not difficult to extract from meaningful examples suitable guidelines for their systematic application to many real cases. This work is presented in the context of ASTRAL, which is a formal specification language for real-time systems with the following distinguishing features: • It is rooted in both ASLAN [1], which is an untimed state machine formalism, and TRIO [7], which is a real-time temporal logic, yielding a new, logic-based, process-oriented specification language. • It has composable modularization mechanisms that allow a complex system to be built as a collection of interacting processes. It also has refinement mechanisms to construct a process as a sequence of layers, where each layer is the implementation of the layer above. • It has a proof obligation system that allows one to formally prove properties of interest as consequences of process specifications. This proof system is incremental since complex proofs of complex systems can be built by composing small proofs that can be carried out, for the most part, independently of each other. ASTRAL’s proofs are of two types. Intra-level proofs guarantee system properties on the basis of local properties that only refer to a single process type.

Parallel Refinement Mechanisms for Real-Time Systems

37

Inter-level proofs guarantee that layer i+1 is a correct implementation of layer i without the need to redo intra-level proofs from scratch. In this paper, we resume the issue of ASTRAL layering mechanisms and the interlevel proofs, which were addressed in a preliminary and fairly restrictive way in [3]. This paper is structured as follows. Section 2 provides the necessary background on the ASTRAL language. Section 3 summarizes previous purely sequential refinement mechanisms. Section 4 motivates the need for their extensions through a simple running example and illustrates the essentials of the generalized and parallel refinement mechanisms. Section 5 shows their application to the running example. Section 6 presents the proof obligations needed to guarantee implementation correctness and section 7 applies them to the running example. Section 8 briefly summarizes a more complex example. Finally, section 9 provides some concluding remarks. For the sake of conciseness in this paper, we concentrate only on the essentials. Complete technical details can be found in [9].

2 ASTRAL Overview An ASTRAL system specification is comprised of a single global specification and a collection of state machine specifications. Each state machine specification represents a process type of which there may be multiple, statically generated, instances. The global specification contains declarations for the process types that comprise the system, types and constants that are shared among more than one process type, and assumptions about the global environment and critical requirements for the whole system. An ASTRAL process specification consists of a sequence of levels. Each level is an abstract data type view of the process being specified. The first („top level“) view is a very abstract model of what constitutes the process (types, constants, variables), what the process does (state transitions), and the critical requirements the process must meet (invariants and schedules). Lower levels are increasingly more detailed with the lowest level corresponding closely to high level code. The process being specified is thought of as being in various states, where one state is differentiated from another by the values of the state variables, which can be changed only by means of state transitions. Transitions are specified in terms of entry and exit assertions, where entry assertions describe the constraints that state variables must satisfy in order for the transition to fire, and exit assertions describe the constraints that are fulfilled by state variables after the transition has fired. An explicit non-null duration is associated with each transition. Transitions are executed as soon as they are enabled if no other transition is executing in that process. Every process can export both state variables and transitions. Exported variables are readable by other processes while exported transitions are callable from the external environment. Inter-process communication is accomplished by inquiring about the values of exported variables and the start and end times of exported transitions. In addition to specifying system state (through process variables and constants) and system evolution (through transitions), an ASTRAL specification also defines system critical requirements and assumptions about the behavior of the environment that interacts with the system. Assumptions about the behavior of the environment are expressed by means of environment clauses that describe the pattern of calls to external transitions, which are the stimuli to which the system reacts. Critical requirements are expressed by means of invariants and schedules. Invariants represent requirements that must hold in every state reachable from the initial state, no matter what the behavior of the external environment is, while schedules represent

38

Paul Z. Kolano, Richard A. Kemmerer, and Dino Mandrioli

additional properties that must be satisfied provided that the external environment behaves as assumed. Invariants and schedules are proved over all possible executions of a system. A system execution is a set of process executions that contains one process execution for each process instance in the system. A process execution for a given process instance is a history of events on that instance. The value of an expression E at a time t1 in the history can be obtained using the past operator, past(E, t1). There are four types of events in ASTRAL. A call event, Call(tr1, t1), occurs for an exported transition tr1 at a time t1 iff tr1 was called from the external environment at t1. A start event, Start(tr1, t1), occurs for a transition tr1 at a time t1 iff tr1 fires at t1. Similarly, an end event, End(tr1, t1), occurs if tr1 ends at t1. Finally, a change event, Change(v1, t1), occurs for a variable v1 at a time t1 iff v1 changes value at t1. Note that change events can only occur when an end event occurs for some transition. An introduction and complete overview of the ASTRAL language can be found in [2]. The example system used throughout the remainder of the paper is shown in figure 1. This system is a circuit that computes the value of a * b + c * d, given inputs a, b, c, and d. The ASTRAL specification for the circuit is shown below. PROCESS Mult_Add EXPORT compute, output CONSTANT dur1: pos_real VARIABLE output: integer TRANSITION compute(a,b,c,d: integer) ENTRY [TIME: dur1] TRUE EXIT output = a * b + c * d

AXIOM TRUE INVARIANT FORALL t1: time, a, b, c, d: integer ( Start(compute(a, b, c, d), t1) → FORALL t2: time ( t1 + dur1 ≤ t2 & t2 ≤ now →past(output, t2) = a * b + c * d))

3 Sequential Refinement Mechanism A refinement mechanism for ASTRAL was defined in [3]. In this definition, an ASTRAL process specification consists of a sequence of levels where the behavior of each level is implemented by the next lower level in the sequence. Given two ASTRAL process level specifications PU and PL, where PL is a refinement of PU, the implementation statement, hereafter referred to as the IMPL mapping, defines a mapping from all the types, constants, variables, and transitions of PU into their corresponding terms in PL, which are referred to as mapped types, constants, variables, or transitions. PL can also introduce types, constants and/or variables that are not mapped, which are referred to as the new types, constants, or variables of PL. Note that PL cannot introduce any new transitions (i.e. each transition of PL must be a mapped transition). A transition of PU can be mapped into a sequence of transitions, a selection of transitions, or any combinations thereof. A selection mapping of the form TU == A1 & TL.1 | A2 & TL.2 | ... | An & TL.n, is defined such that when the upper level transition TU fires, one and only one lower level transition TL.j fires, where TL.j can only fire when both its entry assertion and its associated „guard“ Aj are true. A sequence mapping of the form TU == WHEN EntryL DO TL.1 BEFORE TL.2 BEFORE ... BEFORE TL.n OD, defines a mapping such that the sequence of transitions TL.1; ...; TL.n is enabled (i.e. can start) whenever EntryL evaluates to true. Once the sequence has started, it cannot be interrupted until all of its transitions have been executed in order. The starting time of the upper level transition TU corresponds to the starting time of the sequence (which is not necessarily equal to the starting time

Parallel Refinement Mechanisms for Real-Time Systems

39

of TL.1 because of a possible delay between the time when the sequence starts and the time when TL.1 becomes enabled), while the ending time of TU corresponds to the ending time of the last transition in the sequence, TL.n. Note that the only transition that can modify the value of a mapped variable is the last transition in the sequence. This further constraint is a consequence of the ASTRAL communication model. That is, in the upper level, the new values of the variables affected by TU are broadcast when TU terminates. Thus, mapped variables of PL can be modified only when the sequence implementing TU ends. The inter-level proofs consist of showing that each upper level transition is correctly implemented by the corresponding sequence, selection, or combination thereof in the next lower level. For selections, it must be shown that whenever the upper level transition TU fires, one of the lower level transitions TL.j fires, that the effect (i.e. changes to variables) of each TL.j is equivalent to the effect of TU, and that the duration of each TL.j is equal to the duration of TU. For sequences, it must be shown that the sequence is enabled iff TU is enabled, that the effect of the sequence is equivalent to the effect of TU, and that the duration of the sequence (including any initial delay after EntryL is true) is equal to the duration of TU.

4 Parallel Refinement Mechanism In the sequential mechanism, refinement occurs at the transition level, where the behavior of each upper level transition can be specified in greater detail at the lower level. We now extend the ASTRAL refinement mechanism to include process level refinement, which allows a process to be refined as a collection of components that operate in parallel. For example, a reasonable refinement of the Mult_Add circuit is shown in figure 2. Here, the refinement of the system consists of two multipliers that compute a * b and c * d in parallel and an adder that adds the products together and produces the sum. This refinement cannot be expressed in the sequential mechanism due to the parallelism between the two multipliers. The new parallel mechanism introduced below, however, easily expresses this refinement.

a b

a a*b+c*d

b

c

c

d

d

Fig. 1. Mult_Add circuit

*

a*b+c*d +

*

Fig. 2. Refined Mult_Add circuit

In parallel refinement, an upper level transition may be implemented by a dynamic set of lower level transitions. To guarantee that an upper level transition is correctly implemented by the lower level, it is necessary to define the events that occur in the lower level when the transition is executed in the upper level. It must then be shown that these events will only occur when the upper level transition ends and that the effect will be equivalent. Like the sequential refinement mechanism of [3], an IMPL mapping is used, which describes how items in an upper level are implemented by items in the next lower level. The items of the upper level include variables, constants, types, and transitions. In addition, the implementation mapping must describe how upper level expressions are transformed into lower level expressions.

40

Paul Z. Kolano, Richard A. Kemmerer, and Dino Mandrioli

The following sections only discuss the transition mappings. A complete description of the IMPL mapping is given in [9]. 4.1 Parallel Sequences and Selections A natural but limited approach to defining parallel transition mappings is to extend the sequential sequence and selection mappings into parallel sequence and selection mappings. Thus, a „||“ operator could be allowed in transition mappings, such that „P1.tr1 || P2.tr2“ indicates that tr1 and tr2 occur in parallel on processes P1 and P2, respectively. With this addition, the compute transition of the Mult_Add circuit could be expressed as the following. IMPL(compute(a, b, c, d)) == WHEN TRUE DO (M1.multiply(a, b) || M2.multiply(c, d)) BEFORE A1.add(M1.product, M2.product) OD,

where M1 and M2 are the multipliers and A1 is the adder. Although parallel sequences and selections work well for the example, they do not allow enough flexibility to express many reasonable refinements. For example, consider a production cell that executes a produce transition every time unit to indicate the production of an item. In a refinement of this system, the designer may wish to implement produce by defining two „staggered“ production cells that each produce an item every two time units, thus effectively producing an item every time unit. The upper level production cell PU and the lower level production cells PL.1 and PL.2 are shown in figure 3. Note that the first transition executed on PU is init, which represents the „warm-up“ time of the production cell in which no output is produced.

PU

init

PL.1 PL.2

Fig. 3. Production cell refinement This refinement cannot be expressed using parallel sequences and selections because there is no sequence of parallel transitions in the lower level that corresponds directly to produce in the upper level. When produce starts in the upper level, one of the lower level produce’s will start and when produce ends in the upper level, one of the lower level produce’s will end and achieve the effect of upper level produce, but the produce that starts is not necessarily the produce that achieves the effect of the corresponding end. 4.2 Parallel Start, End, and Call Mappings The desired degree of flexibility is obtained by using transition mappings that are based on the start, end, and call of each transition. For each upper level transition TU, a start mapping „IMPL(Start(TU, now)) == StartL“ and an end mapping „IMPL(End(TU, now)) == EndL“ must be defined. If TU is exported, a call mapping „IMPL(Call(TU, now)) == CallL“ must also be defined. These mappings are defined at time now, which is a special global variable that holds the current time in the system; thus, the mappings are defined for all possible times.

Parallel Refinement Mechanisms for Real-Time Systems

41

Here, StartL, EndL, and CallL are well-formed formulas using lower level transitions and variables. For the most part, the end and call mappings will correspond to the end or call of some transition in the lower level, whereas the start mapping may correspond to the start of some transition or some combination of changes to variables, the current time, etc. Call mappings are restricted such that for every lower level exported transition TL, Call(TL) must be referenced in some upper level exported transition call mapping IMPL(Call(TU, now)). This restriction expresses the fact that the interface of the process to the external environment cannot be changed. For parameterized transitions, only the call mapping may reference the parameters given to the transition. Any parameter referenced in a call mapping must be mapped to a call parameter of some lower level transition and the corresponding start mapping must contain the same transitions as the call mapping. Thus, the start and end parameters are taken from the associated set of unserviced call parameters. With these mappings, the initialize and produce transitions can be mapped as follows. Note that the parallelism between PL.1 and PL.2 is implied by the overlapping start and end times of produce on each process and not by a built-in parallel operator. IMPL(Start(initialize, now)) == now = 0 & PL.1.Start(produce, now) IMPL(Start(produce, now)) == IF now mod 2 = 0 THEN PL.1.Start(produce, now) ELSE PL.2.Start(produce, now) FI

IMPL(End(initialize, now)) == now = 1 IMPL(End(produce, now)) == IF now mod 2 = 0 THEN PL.1.End(produce, now) ELSE PL.2.End(produce, now) FI

5 The Mult_Add Circuit The specification of the refinement of the Mult_Add circuit in figure 2 is shown below using the new parallel refinement mechanism. Each multiplier has a single exported transition multiply, which computes the product of two inputs. The adder has a single transition add, which computes the sum of the two multiplier outputs. PROCESS Multiplier EXPORT multiply, product VARIABLE product: integer TRANSITION multiply(a, b: integer) ENTRY [TIME: 2] EXISTS t: time (End(multiply, t)) → now - End(multiply) ≥ 1 EXIT product = a * b

PROCESS Adder IMPORT M1, M1.product, M1.multiply, M2, M2.product, M2.multiply EXPORT sum VARIABLE sum: integer TRANSITION add ENTRY [TIME: 1] M1.End(multiply, now) & M2.End(multiply, now) EXIT sum = M1.product + M2.product

The lower level consists of two instances of the Multiplier process type, M1 and M2, and one instance of the Adder process type, A1. The output variable of the upper level process is mapped to the sum variable of the adder (IMPL(output) == A1.sum). The duration of the compute transition is the sum of the multiply transition and the add transition in the lower level (IMPL(dur1) == 3). When compute starts in the upper level, multiply starts on both M1 and M2. When compute ends in the

42

Paul Z. Kolano, Richard A. Kemmerer, and Dino Mandrioli

upper level, add ends on A1. When compute is called in the upper level with inputs a, b, c, and d, multiply is called on M1 with inputs a and b and multiply is called on M2 with inputs c and d. IMPL(Start(compute, now)) == M1.Start(multiply, now) & M2.Start(multiply, now)

IMPL(End(compute, now)) == A1.End(add, now) IMPL(Call(compute(a, b, c, d), now)) == M1.Call(multiply(a, b), now) & M2.Call(multiply(c, d), now)

6 Proof Obligations for Parallel Refinement Mechanism The goal of the refinement proof obligations is to show that any properties that hold in the upper level hold in the lower level without actually reproving the upper level properties in the lower level. In order to show this, it must be shown that the lower level correctly implements the upper level. ASTRAL properties are interpreted over execution histories, which are described by the values of state variables and the start, end, and call times of transitions at all times in the past back to the initialization of the system. A lower level correctly implements an upper level if the implementation of the execution history of the upper level is equivalent to the execution history of the lower level. This corresponds to proving the following four statements. (V) (C) (S) (E)

Any time a variable has one of a set S of possible values in the upper level, the implementation of the variable has one of a subset of the implementation of S in the lower level. Any time the implementation of a variable changes in the lower level, a transition ends in the upper level. Any time a transition starts in the upper level, the implementation of the transition starts in the lower level and vice-versa. Any time a transition ends in the upper level, the implementation of the transition ends in the lower level and vice-versa.

If these four items can be shown, then any property that holds in the upper level is preserved in the lower level because the structures over which the properties are interpreted is identical over the implementation mapping. 6.1 Proof Obligations Instead of proving directly that the mappings hold at all times, it can be shown that the mappings hold indirectly by proving that they preserve the axiomatization of the ASTRAL abstract machine, thus they preserve any reasoning performed in the upper level. This can be accomplished by proving the implementation of each abstract machine axiom. The proof obligations are shown in figure 4 and are written in the specification language of PVS [4], which will be used to assist the proofs in the future. To perform the proofs, the following assumption must be made about calls to transitions in each lower level process. impl_call: ASSUMPTION (FORALL (tr_ll: transition_ll, t1: time): Exported(tr_ll) AND Call(tr_ll, t1)(t1) IMPLIES (EXISTS (tr_ul: transition_ul): (FORALL (t2: time): IMPL(Call(tr_ul, t2)(t2)) IMPLIES Call(tr_ll, t2)(t2)) AND IMPL(Call(tr_ul, t1)(t1))))

Parallel Refinement Mechanisms for Real-Time Systems

43

This assumption states that any time a lower level exported transition is called, there is some call mapping that references a call to the transition that holds at the same time. This means that if one transition of a „conjunctive“ mapping is called, then all transitions of the mapping are called. That is, it is not possible for a lower level transition to be called such that the call mapping for some upper level transition does not hold. For example, consider the mapping for the compute transition of the Mult_Add circuit „IMPL(Call(compute(a, b, c, d), now)) == M1.Call(multiply(a, b), now) & M2.Call(multiply(c, d), now)“. In this case, impl_call states that any time multiply is called on M1, multiply is called on M2 at the same time and vice-versa. An assumption is also needed to assure that whenever the parameters of an upper level exported transition are distributed among multiple transitions at the lower level, the collection of parameters for which the lower level transitions execute come from a single set of call parameters. For example, in the Mult_Add circuit, the upper level compute transition may be called with two sets of parameters {1, 2, 3, 4} and {5, 6, 7, 8} at the same instant. In the lower level implementation, the multiply transition of each multiplier takes two of the parameters from each upper level call. Thus, in the example, multiply is enabled on M1 for {1, 2} and {5, 6} and on M2 for {3, 4} and {7, 8}. Without an appropriate assumption, M1 may choose {1, 2} and M2 may choose {7, 8}, thus computing the product for {1, 2, 7, 8}, which was not requested at the upper level. The impl_call_fire_parms assumption given in [9] prevents this. impl_end1: OBLIGATION (FORALL (tr1: transition, t1: time): IMPL(End(tr1, t1)(t1)) IMPLIES t1 ≥ IMPL(Duration(tr1))) impl_end2: OBLIGATION (FORALL (tr1: transition, t1: time, t2: time): t1 = t2 - IMPL(Duration(tr1)) IMPLIES (IMPL(Start(tr1, t1)(t1)) IFF IMPL(End(tr1, t2)(t2)))) impl_trans_mutex: OBLIGATION (FORALL (tr1: transition, t1: time): IMPL(Start(tr1, t1)(t1)) IMPLIES (FORALL (tr2: transition): tr2 ≠ tr1 IMPLIES NOT IMPL(Start(tr2, t1)(t1))) AND (FORALL (tr2: transition, t2: time): t1 < t2 AND t2 < t1 + IMPL(Duration(tr1)) IMPLIES NOT IMPL(Start(tr2, t2)(t2)))) impl_trans_entry: OBLIGATION (FORALL (tr1: transition, t1: time): IMPL(Start(tr1, t1)(t1)) IMPLIES IMPL(Entry(tr1, t1))) impl_trans_exit: OBLIGATION (FORALL (tr1: transition, t1: time): IMPL(End(tr1, t1)(t1)) IMPLIES IMPL(Exit(tr1, t1)))

impl_trans_called: OBLIGATION (FORALL (tr1: transition, t1: time): IMPL(Start(tr1, t1)(t1)) AND Exported(tr1) IMPLIES IMPL(Issued_Call(tr1, t1))) impl_trans_fire: OBLIGATION (FORALL (t1: time): (EXISTS (tr1: transition): IMPL(Enabled(tr1, t1))) AND (FORALL (tr2: transition, t2: time): t1 - IMPL(Duration(tr2)) < t2 AND t2 < t1 IMPLIES NOT IMPL(Start(tr2, t2)(t2))) IMPLIES (EXISTS (tr1: transition): IMPL(Start(tr1, t1)(t1)))) impl_vars_no_change: OBLIGATION (FORALL (t1: time, t3: time): t1 ≤ t3 AND (FORALL (tr2: transition, t2: time): t1 < t2 AND t2 ≤ t3 IMPLIES NOT IMPL(End(tr2, t2)(t2))) IMPLIES (FORALL (t2: time): t1 ≤ t2 AND t2 ≤ t3 IMPLIES IMPL(Vars_No_Change(t1, t2)))) impl_initial_state: OBLIGATION IMPL(Initial(0)) impl_local_axiom: OBLIGATION (FORALL(t1):IMPL(Axiom(t1)

Fig. 4. Parallel refinement proof obligations

44

Paul Z. Kolano, Richard A. Kemmerer, and Dino Mandrioli

In the axiomatization of the ASTRAL abstract machine [9], the predicate „Fired(tr1, t1)“ is used to denote that the transition tr1 fired at time t1. If Fired(tr1, t1) holds, then it is derivable that a start of tr1 occurred at t1 and an end of tr1 occurred at t1 + Duration(tr1). Additionally, since an end of tr1 can only occur at t1 when Fired(tr1, t1 - Duration(tr1)) holds and the time parameter of Fired is restricted to be nonnegative, it is known that an end can only occur at times greater than or equal to the duration of the transition. In the parallel refinement mechanism, the start and end of upper level transitions are mapped by the user, so it is unknown whether these properties of end still hold. Since the axioms rely on these properties, they must be proved explicitly as proof obligations. The impl_end1 obligation ensures that the mapped end of a transition can only occur after the mapped duration of the transition has elapsed. The impl_end2 obligation ensures that for every mapped start of a transition, there is a corresponding mapped end of the transition, that for every mapped end, there is a corresponding mapped start, and that mapped starts and mapped ends are separated by the mapped duration of the transition. The other obligations are the mappings of the ASTRAL abstract machine axioms. The impl_trans_mutex obligation ensures that any time the mapped start of a transition occurs, no other mapped start of a transition can occur until the mapped duration of the transition has elapsed. The impl_trans_entry obligation ensures that any time the mapped start of a transition occurs, the mapped entry assertion of the transition holds. The impl_trans_exit obligation ensures that any time the mapped end of a transition occurs, the mapped exit assertion of the transition holds. The impl_trans_called obligation ensures that any time the mapped start of an exported transition occurs, a mapped call has been issued to the transition but not yet serviced. The impl_trans_fire obligation ensures that any time the mapped entry assertion of a transition holds, a mapped call has been issued to the transition but not yet serviced if the transition is exported, and no mapped start of a transition has occurred within its mapped duration of the given time, a mapped start will occur. The impl_vars_no_change obligation ensures that mapped variables only change value when the mapped end of a transition occurs. The impl_initial_state obligation ensures that the mapped initial clause holds at time zero. Besides the abstract machine axioms, the local proofs of ASTRAL process specifications can also reference the local axiom clause of the process (which is empty (i.e. TRUE) in the Mult_Add circuit). Since this clause can be used in proofs and the constants referenced in the clause can be implemented at the lower level, the mapping of the local axiom clause of the upper level must be proved as a proof obligation. The impl_local_axiom obligation ensures that the mapped axiom clause holds at all times. In order to prove this obligation, it may be necessary to specify local axioms in the lower level processes that satisfy the implementation of the upper level axiom clause. To prove the refinement proof obligations, the abstract machine axioms can be used in each lower level process. For example, to prove the impl_initial_state obligation, the initial_state axiom of each lower level process can be asserted. 6.2 Correctness of Proof Obligations The proof obligations for the parallel refinement mechanism given in figure 4 are sufficient to show that for any invariant I that holds in the upper level, IMPL(I) holds in the lower level. Consider the correctness criteria (V), (C), (S), and (E) above. (V) is satisfied because by impl_initial_state, the values of the implementation of the variables in the lower level must be consistent with the values in the upper level. Variables in the upper level only change when a transition ends and at these times, the implementation of the variables in the lower level change consistently by

Parallel Refinement Mechanisms for Real-Time Systems

45

⊥

⊥

impl_trans_exit. (C) is satisfied because the implementation of the variables in the lower level can only change value when the implementation of a transition ends by impl_vars_no_change. The forward direction of (S) is satisfied because whenever an upper level transition fires, a lower level transition will fire by impl_trans_fire. The reverse direction of (S) is satisfied because whenever the implementation of a transition fires in the lower level, its entry assertion holds by impl_trans_entry, it has been called by impl_trans_called, and no other transition is in the middle of execution by impl_trans_mutex. (E) is satisfied because (S) is satisfied and by impl_end1 and impl_end2, any time a start occurs, a corresponding end occurs and vice-versa. More formally, any time an invariant I can be derived in the upper level, it is derived by a sequence of transformations from I to TRUE, I f1/a1 I1 f2/a2 ... fn/an TRUE, where each transformation fi/ai corresponds to the application of a series fi of first-order logic axioms and a single abstract machine axiom ai. Since the implementation of each axiom of the ASTRAL abstract machine is preserved by the parallel refinement proof obligations, a corresponding proof at the lower level IMPL(I) f1´/impl_a1 IMPL(I1) f2´/impl_a2 ... fn´/impl_an TRUE can be constructed by replacing the application of each abstract machine axiom ai by impl_ai. Additionally, each series fi of first-order logic axioms is replaced by a series fi′ that takes any changes to the types of variables and constants into consideration. ⊥

⊥

⊥

⊥

7 Proof of Mult_Add Circuit Refinement This section shows the most notable cases of the parallel refinement proof obligations for the Mult_Add circuit. The full proofs can be found in [9]. The obligations below were obtained from the corresponding obligations in figure 4 by expanding the IMPL mapping appropriately, replacing quantification over transitions with the actual transitions of the Mult_Add circuit, rewriting the Curried PVS form (e.g. Start(tr1, t1)(t2)) to its ASTRAL equivalent (e.g. past(Start(tr1, t1), t2)), and performing some minor simplifications. For the impl_end2 obligation, the following must be proved. FORALL t1: time ( past(M1.Start(multiply, t1 - 3), t1 - 3) & past(M2.Start(multiply, t1 - 3), t1 - 3) past(A1.End(add, t1), t1)) ↔

For the forward direction, it must be shown that add ends on A1 at t1, thus starts at t1 - 1. From the antecedent, multiply ends on both M1 and M2 at t1 - 1 so the entry assertion of add holds on A1 at time t1 - 1. A1 must be idle or else from the entry of add, multiply ended in the interval (t1 - 2, t1 - 1), which is not possible since multiply was still executing on M1 and M2 in that interval. Therefore, add starts at t1 - 1 on A1, thus ends at t1. The reverse direction is similar. For the impl_trans_exit obligation, the formula below must be proved. FORALL t1: time ( past(A1.End(add, t1), t1) FORALL a, b, c, d: integer → ( past(M1.Start(multiply(a, b), t1 - 3), t1 - 3) & past(M2.Start(multiply(c, d), t1 - 3), t1 - 3) past(A1.sum, t1) = a * b + c * d)) →

By the exit assertion of add, past(A1.sum, t1) = past(M1.product, t1 - 1) + past(M2.product, t1 - 1). From the entry of add, multiply ends on both M1 and M2 at t1 - 1. Since multiply ends on M1 and M2 at t1 - 1, it starts on M1 and M2 at t1 - 3 for two pairs of parameters (a, b) and (c, d), respectively, which were provided by the

46

Paul Z. Kolano, Richard A. Kemmerer, and Dino Mandrioli

external environment. By the exit assertion of multiply, past(M1.product, t1 - 1) = a * b and past(M2.product, t1 - 1) = c * d, so past(A1.sum, t1) = a * b + c * d. Thus, impl_trans_exit holds. The impl_trans_fire obligation is given below. FORALL t1: time ( EXISTS t2: time ( t2 ≤ t1 & past(M1.Call(multiply, t2), t1) & past(M2.Call(multiply, t2), t1) & FORALL t3: time ( t2 ≤ t3 & t3 < t1 → ~ ( past(M1.Start(multiply, t3), t3) & past(M2.Start(multiply, t3), t3)))) & FORALL t2: time ( t1 - 3 < t2 & t2 < t1 → ~ ( past(M1.Start(multiply, t2), t2) & past(M2.Start(multiply, t2), t2))) past(M1.Start(multiply, t1), t1) → & past(M2.Start(multiply, t1), t1))

To prove this obligation, it is first necessary to prove that M1.Start(multiply) and M2.Start(multiply) always occur at the same time. This can be proved inductively. At time zero, both M1 and M2 are idle. By impl_call, if multiply is called on either M1 or M2, multiply is called on both M1 and M2. At time zero, multiply cannot have ended, thus the entry assertion of multiply is true, so if both are called, both fire. If neither is called, then neither can fire. For the inductive case, assume M1.Start(multiply) and M2.Start(multiply) have occurred at the same time up until some time T0. Suppose multiply occurs on M1 (the M2 case is similar), then M1 was idle, multiply has been called since the last start, and it has been at least one time unit since multiply ended on M1. M2 cannot be executing multiply at T0 or else M1 must also be executing multiply by the inductive hypothesis, thus M2 must be idle. Similarly, it must have been at least one time unit since multiply ended on M2. By impl_call, multiply must have been called on M2 since it was called on M1. Thus, multiply is enabled on M2, so must fire. Therefore, M1.Start(multiply) and M2.Start(multiply) always occur at the same time. Based on this fact, the following two expressions are equivalent. FORALL t3: time ( t2 ≤ t3 & t3 < t1 → ~ ( past(M1.Start(multiply, t3), t3) & past(M2.Start(multiply, t3), t3)))

FORALL t3: time ( t2 ≤ t3 & t3 < t1 → ~past(M1.Start(multiply, t3), t3) & ~past(M2.Start(multiply, t3), t3))

Since nothing has started in the interval (t1 - 3, t1), nothing can end in the interval (t1 - 1, t1 + 2), thus the entry assertion of multiply on M1 is satisfied at t1. Since the entry of multiply holds, multiply has been called but not yet serviced, and M1 is idle, multiply starts on M1 at t1. Since multiply always starts on both M1 and M2 at the same time as shown above, impl_trans_fire holds. The remaining proof obligations were all proved in a straightforward manner. Therefore, the lower level is a correct refinement of the upper level and the implementation of the upper level invariant, shown below, holds in the lower level.

Parallel Refinement Mechanisms for Real-Time Systems

47

FORALL t1: time, a, b, c, d: integer ( M1.Start(multiply(a, b), t1 - 3) & M2.Start(multiply(c, d), t1 - 3) FORALL t2: time → ( t1 + dur1 ≤ t2 & t2 ≤ now past(A1.sum, t2) = a * b + c * d)) →

8 Parallel Phone System The previous example has shown that the parallel refinement mechanism can express the parallel implementation of a simple system in a simple and straightforward manner. Furthermore, the proof obligations for a simple implementation were themselves simple. In this section we briefly outline how our mechanisms can be applied to the specification and refinement of a much more complex case such as the control of a phone system. The system considered here is a slightly modified version of the phone system defined in [2]. It consists of a set of phones that need various services (e.g. getting a dial tone, processing digits entered into the phone, making a connection to the requested phone, etc.) as well as a set of central controls that perform the services. Due to space limitations, this example cannot be described in full detail. Thus, we limit ourselves to an informal description of the main steps of the refinement process and refer the interested reader to [9] for the complete description and proof. The specification of the central control, which is the core of the whole system, is articulated into three layers. The goal of the top level is to provide an abstract and global view of the supplied services in such a way that the user can have complete and precise knowledge of the external behavior, both in terms of functions performed and in terms of service times, of the central control but the designer still has total freedom on implementation policies. In fact, as a result, the description provided in [2] is just an alternative implementation of the top level description given here, which differs from this version in that services are granted sequentially rather than in parallel. To achieve our goal (i.e. to allow the implementation of services both asynchronously in parallel and strictly sequentially, as suggested by figures 5 and 6), the top level is specified such that a set of services can start and a set of services can end at every time unit in the system (for simplicity we assume discrete time). In these figures, Ti_si.Pk denotes providing service si to phone k. The service of a phone is split into the beginning of servicing and the completion of servicing through two transitions: Begin_Serve and Complete_Serve. In other words, instead of assigning ASTRAL transitions to single services or groups thereof, we only make the beginning and the end of services visible at the top level. In this way, we do not commit too early to a fixed duration of the implementation of the service, stating only when a service will begin and when it will be completed. Thus, the durations of Begin_Serve and Complete_Serve are set to „serve_dur“, where 2*serve_dur is chosen to be a divisor of the duration of every service. A parameterized variable „serving(P)„ records when each phone P began being serviced so that it can complete being serviced at the appropriate time. When serving(P) changes to true for a phone P at time t, P began being served at t serve_dur. Thus, when the duration of the function that was serving the phone elapses from this time, Complete_Serve carries out the effect of the function on the phone’s state and resets serving for that phone to false.

48

Paul Z. Kolano, Richard A. Kemmerer, and Dino Mandrioli T1_s1.P1

T1_s1.P1

T2_s2.P1 T2_s2.P2 T1_s1.P1

T1_s1.P2

T1_s1.P2

T2_s2.P1

T2_s2.P2

Fig. 6. Sequential implementation of different services on several phones

T1_s1.P2

T2_s2.P1

idle

ready_to_dial

ringing

...

alarm

10

27

34

...

0

T2_s2.P2

Fig. 5. Parallel implementation of different services on several phones

Fig. 7. Implementation of the phone state

To allow both a sequential and a parallel implementation, it is necessary for the top level specification to allow the possibility of multiple actions occurring at the same time without actually requiring multiple actions to occur. This is achieved by limiting the number of phones that can be serviced at any given time to be less than a constant „K_max“. In the sequential refinement, K_max is mapped to one, indicating that only one phone at a time can be serviced. In the parallel refinement, K_max is mapped to the sum of the capacities of the individual servers, indicating that as many phones as it is possible for the servers to serve can be serviced in parallel. Let us now look at the parallel implementation of the top level central control. As mentioned earlier, this is achieved through two refined layers. In the first refinement, the central control is split into several parallel processes, each of which is devoted to a single service of the top level central control. Thus, there is a process devoted to giving dial tone, a process devoted to processing entered digits, and so on. Each one of these processes executes two transitions that correspond to Begin_Serve and Complete_Serve at the top level. The main issue in this step is the mapping of the global state of the central control into disjoint components to be assigned to the different lower level parallel processes. That is, the „Phone_State(P)“ variable in the top level, which holds the state of each phone P (Phone_State can take the values idle, ready_to_dial, ringing, ...), needs to be split among all the servers in the lower level. In the ASTRAL model, however, only a single process can change the value of a variable, thus it is not possible to let all of the lower level servers change the same variable directly. A solution to this problem is to split Phone_State into a set of „timestamp“ variables, with one timestamp for each possible state of a phone. Each server is then allocated the timestamp variables associated with the phone state(s) it is responsible for. The state of a phone is the state associated with the timestamp that has last changed among all the servers. Figure 7 illustrates such a state variable mapping. In this figure, each component is managed by a different process and the current state of the phone is „ringing“ because the corresponding timestamp component holds the maximum value. Finally, in the third layer of the central control, each second level server is refined by a parallel array of „microservers“, where each microserver is devoted to processing the calls of a single phone. Each microserver picks a phone from the set of phones waiting for the service according to some, possibly nondeterministic, policy and inserts its identifier into a set of served phones through a sequence of two transitions. The union of the elements of these sets over all the microservers implements the set of phones that are being served on the upper level server.

Parallel Refinement Mechanisms for Real-Time Systems

49

This example demonstrates that the parallel refinement mechanism can be used to express very complex parallel implementations. Not surprisingly, such generality is obtained at the cost of complicating the proofs of the proof obligations as shown in the major proofs of the phone system refinement, which were completed in [9]. We are confident that the approach adopted in this and other examples can be applied in a fairly similar way to a collection of real-life cases. As a result, we should obtain a general and systematic method for driving the specification and refinement of parallel and asynchronous systems.

9 Conclusions, Future Work, and Acknowledgments ASTRAL aims to provide a disciplined and well-structured way of developing realtime systems. To achieve this goal it stresses modularization and incremental development through several refinement levels. In this paper, we presented an approach to accomplish these refinement steps in a flexible, general, and yet rigorous and provably correct way. A key feature of the proposed mechanism is the exploitation of parallelism so that global actions at a high level of abstraction may be described as individual transitions that can be refined at a lower level as several concurrent and cooperating activities. Our approach allows more generality and flexibility than the few independent ones available in the literature, which are more algebraic in nature (for an up-to-date survey of formal refinement methods see [5]). Although our experience in the application of the mechanisms to problems of practical interest is still limited, we have already developed a number of case studies that show that the approach naturally scales up. Besides those summarized in this paper, we also mention the management of a hydroelectric reservoir system based on a real-life project. Early methods guiding the user throughout the development of reallife cases have already been extracted from these experiences [9]. As usual, when moving towards complex applications, the support of suitable tools is fundamental. ASTRAL is already equipped with several prototype tools [10] that allow the user to edit and manage complex specifications as well as providing support for their analysis. In particular, proof obligations can be automatically produced from specifications, and proofs are supported by both model checking and deductive facilities. The model checker can check the critical requirements of a particular instance of a specification over a finite time interval. ASTRAL has been encoded into the language of the PVS theorem prover to support deductive reasoning. The ASTRAL toolset currently supports the sequential refinement mechanism of [3], but does not yet support the parallel refinement mechanism of this paper. To support the new mechanism, the design portion needs to incorporate a slightly different specification structure, an algorithm is needed to transform upper level expressions to lower level expressions using the implementation mapping, and the proof obligations must be incorporated into the current ASTRAL-PVS library for use with the theorem prover. It may be possible to use the PVS rewriting mechanism directly to transform upper level items to lower level items. This work is currently under way. In addition to tool support, more parallel refinements will be developed to test the expressiveness and applicability of the new parallel mechanism. The authors would like to thank Klaus-Peter Loehr for his participation in the development of the parallel mechanism and Giovanna Di Marzo for her valuable comments. This research was partially supported by NSF Grant No. CCR-9204249 and by the Programma di scambi internazionale of the CNR.

50

Paul Z. Kolano, Richard A. Kemmerer, and Dino Mandrioli

References 1.

Auernheimer, B. and R.A. Kemmerer. ASLAN User’s Manual. Technical Report TRCS84-10, Department of Computer Science, University of California, Santa Barbara, Mar. 1985. 2. Coen-Porisini, A., C. Ghezzi, and R.A. Kemmerer. „Specification of Realtime Systems Using ASTRAL“. IEEE Transactions on Software Engineering, Sept. 1997, vol. 23, (no. 9): 572-98. 3. Coen-Porisini, A., R.A. Kemmerer, and D. Mandrioli. „A Formal Framework for ASTRAL Inter-level Proof Obligations“. Proc. of the 5th European Software Engineering Conf., Sitges, Spain, Sept. 1995. 4. Crow, J., S. Owre, J. Rushby, N. Shankar, and M. Srivas. „A Tutorial Introduction to PVS“. Workshop on Industrial-Strength Formal Specification Techniques, Boca Raton, Florida, Apr. 1995. 5. Di Marzo Serugendo, G. „Stepwise Refinement of Formal Specifications Based on Logical Formulae: From CO-OPN/2 Specifications to Java Programs“. Ph.D. Thesis no. 1931, EPFL, Lausanne, 1999. 6. Felder M., A. Gargantini, and A. Morzenti. „A Theory of Implementation and Refinement in Timed Petri Nets“. Theoretical Computer Science, July 1998, vol. 202, (no. 1-2): 127-61. 7. Ghezzi, C., D. Mandrioli, and A. Morzenti. „TRIO: a Logic Language for Executable Specifications of Real-time Systems“. Jour. of Systems and Software, May 1990, vol. 12, (no. 2): 107-23. 8. Hennessy, A. and R. Milner. „Algebraic Laws for Nondeterminism and Concurrency“. Jour. of the ACM, Jan. 1985, vol. 32, (no. 1): 137-61. 9. Kolano, P.Z. „Tools and Techniques for the Design and Systematic Analysis of Real-Time Systems“. Ph.D. Thesis, University of California, Santa Barbara, Dec. 1999. 10. Kolano, P.Z., Z. Dang, and R.A. Kemmerer. „The Design and Analysis of Real-time Systems Using the ASTRAL Software Development Environment“. Annals of Software Engineering, vol. 7, 1999. 11. Ostroff, J.S. „Composition and Refinement of Discrete Real-Time Systems“. ACM Transactions on Software Engineering and Methodology, Jan. 1999, vol. 8, (no. 1): 1-48.

Applying RT-Z to Develop Safety-Critical Systems t

¨ l

k r [email protected]

pr

Abstract.

pp r

r

pr r r

1

r

r r

r p

p r

r r

r

r

r

r r

r

p

r r

r p r

r

Introduction t

i t ty it i l y t l t 3 i t l i t i l t t t j ity t i j t ty it i ly t li y t i ti t l t i ti i i l t i ti t t t it t i t i ti t ll ti i l i t l i l it l i ti t ty it i l y t ti ti t i l t t l i i t t l ty it i l y t t t i t t t t y i t t ti i y t i y l ll iyi t l it i t it i t i t l t t l y lt i l ti 3 t t i ll t iy t y i t l i i l i lt i t it t i y t t t l t i t t t l i i l t y i i ji t t ty it i l y t t t i l yi t l l it t t t t i it i l i i t l l l t l t i t t l l i t t i t tl y i lt t t l l y t i ti i t l l ti i ti it i i t t it t i l l i t t it i t t t l t t t t l y t t t i t t i lt t t l t i l l y

y t

i

i

l t i t il l t i t

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 51–65, 2000. c Springer-Verlag Berlin Heidelberg 2000 

r

t i tl y i i

¨

t ti

l i t ti l ti

t

l t

t i

it ti

t

i

i

i t l l y iy lt i y t i l t i i t t t t i t i t ty it i l y t t il lt t t it it t t it i l l y i t t t ty it i l y t il it t t i t t i i il t y t i i l y t i ti il y t i i l l t i t i t i ti l i ti i l i t t t t l l i t y ti 3 i t t i ti t l t ty it i l y t t l ti it i t i ti l i t i il y t t y i ti t it t t i t t t t t it t i ti l t y it i il lt t y i li i ti

t

i

2

Overview of RT-Z

i t i i t t ti ti l y i y t ification units i t y t i i t t it i t ti i t i t ti i l y t i i t it y t i y t

i l i

t t i t i l i

i i ti tl i it i t ti l i t il i it t l t 3 ti l y t i ti l l t i t i i i l i ti i i i y l l speci ti it t t t i y t t t i y i ti it i y y t t t it t i t i ti it i t t it t i l l i t ti it it t ti t t t l l t i l i it t t t ti t l i t it i t t t t i t t t t i l i t t t it i t t t l i t t i i t t i lt i t i t i ti it it lsections ti i t i t t t l l t l t tl y t ti it y aggregate y t i ti it i ti it y it il y y t ti t l ll it i lt i i ti t i ti it i t ti

pp

i ti

i

t

p

i t

t i t i it t l i t il t

t

3

i ti tl y iy

t t

r

it

t ti lt t

t

l

t ti

t i t

l i

t

t y t

t t

i

i

i

i

t

t

y

Developing Safety-Critical Systems t i

ti

i

i

l i t l i t

safety i t t t l l l l i y t z i t t t it t i t i i t

t

i t i ti t t i t t ty it i l y t i it i l i i t i l l i t y t t i t accidents i i l t t t l t i i ti i i i ti t t ty t y t ti l l y t i t t i t t ti hazard i t t t y t t t i t i t t i y t il ll i it l y

l ty t t i it i

t

it i t

ti

i t it i

t t

t lt

t i

t

i t t t y t i t i it i t y t i t l y i t ty t t i t t t t i y t it i i it i t ti t y t i z t l y t t t i fl i t tl y ty l t i t ti it i i i and t i t i y t t lt t t i fl y t y t i t i ti i t t l t l ti t l y t i t system ty y i i t t t t l y t i z t t i t t y t i t t i t i ti ti i lt i t z t t l t t ti i t t l t y ty it i l y t i t i l i ti l i ti l t t i i t t ly i t l t t i ty it i l y t i tl y ty i i t i i l l y y t ty t l i t lt it l y t t t l y it i lt t t t l i t i t t t l l ti t l y y t l y it t i t l i t t t t ly t t i l i i t i ti t l i i l lt i l lt i i t t i l l y it t l i i t t i ly i t l i li i y t l t t ti tt y t i t i it i t z t t i ti i i t t t t i

t

r

¨

i

t i

4

i

ti

t

t

i

t

t t

i

t

Case Study: Railway Network t

t

t l i il ity t ty it i l y t l i ti il y t t l l i i t it i t l y ty it i l t il i l t i t t t i t t i il it t t t t l t t il y t t i t l l l ity t it i l t t t t it i t t t it l l t i t t t i l lt t i t li t y i t l iz il i l t i it i l it t t i ti l il y t i t l t tt ti t t t tl i il l i t t l t t il y t t t t y t t ti i t i t y t i t i ti i i t i ti y t z i i lt t i i t t y t i l t y t i y t i t i t ty t i t 1 il lt i il y t l t i t i i i l t il y l i i t t i t il y i tt i t ti t il y l i t t l i i t i i t i l y t i z t t i ti il y t t ity i t l the state in which a train is in a railway crossing and its gates are not closed, t t t t l t l l ii t t t i i l i t il y l i t t y t i i t t it t t i y t t t i lt l iz t i i t t i t it t i t it i i t t y t t t it i t l i i t t i t t l i t l l i t i t i t t tl y iy t i t t t i ti i t y t i i t lt i t t t i i t t i t li t it t t i ti t i i t l l iz t i t i i t t t i t t i t y t t t l l y l i l y t t y t t t i i i t t t t t l i t t l l t il y t t t l y t it i it ti t t i t t t l il y t it i i it i i l l y i t t i it t t t i ti i t y t i i t t t t t i t i t i t t i t i ti t

1

r r

r

r

r

pp

p

r

railway crossing

railway line railway network

Fig. 1. y t

t t i i l l

t 4.1

t

l

ti l t ti l

y

traffic line

it

t

it

t t it t

t

it

t

System Requirements t

t i

y t t

i t

ti

ti

it RailwayNetwork l l y t il y t t it TechnicalPars

t

it i t

i

ti

TechnicalPars t l t ti t i l t ti t l t i t lt i i CONSTANTS ti l t t il y t il y i CROSS

i lt

t ty lt

l t t t i t l it i

SPEC. UNIT t

t

lt i l y TYPES & t it l i RAIL

l il y

t

t t

i

i

l l y i l

TRAIN

il y

TRAIN RAIL CROSS il y l i

t

i

i runs through RAIL dom runs through t

i

i

t

t

t y i t

t it

ti t

i y

t

ti

t t l

t i t

1

i i

RAIL

t 2

t ti lt i

y

il y

i

i t

i CROSS

ti l ti

ran runs through

CROSS

t il y t i t y i t it t t t i il y i lt ti t t t t l il y i t i il y l i t t ti t lt l y l i l y

i t

t t

i

t l t t t il γup γdown t t t

r 1

2

γdown

¨

r RAIL dom 1 r c runs through i lt i t t t i t il y

t t

T+

RAIL CROSS γup CROSS T+

dom r t

t

2

r 1

rc

l t

runs through 6R 2 r c

t

t i

r 1

R γdown c

rc

l t il y

t

ti t

i

t

t i

t

END UNIT SPEC. UNIT RailwayNetwork

EXTENDS TechnicalPars

EXTENDS l t i t l l it i i t i ti it l l t t i i t y t i 2 l t il y t i t l i t l l t il y t i t i t l t i t i t it ty i t LOCAL ti LOCAL channel enterN exitN of type TRAIN RAIL channel enterC exitC of type TRAIN RAIL CROSS channel lowering raising down up of type CROSS i

t

t l enterN t il y t t l enterC exitC il y i ti l y up lowering raising lt t t i t t t t i lt l y l i ti l y

t

i

it

t

exitN tt ti l il y l i t t t y i t t i t t ti l i lt l y

BEHAVIORAL PROPERTIES li i ti 3 t t i t t t t t l t ty it i l y t i t y t z t l l y t i t t i i i t BEHAVIORAL ti i i lt t tl y iy t t i t t y i t ti i ti i t i t l t ti il i t ti t i i t l i t t i t lt t lt i t y i t t ti i it i i l 2

r

r r

r r

r p

rk r

r r

rk

r r

r

r p r r rk r r

t y i t t t l down

it i i

y t

i t ti y t l t ty t i t PROPERTIES i t t t ti l t i l ti 3 y l l i ti t t l i

r p

rk

p r p r r

rr r

pp

p

r

SafeRailwayCrossing i il y l i rail t i lt i i t lt t il y i i t lt l y l t l t i t

cross t t t t i t t t i

ti t

l t t

SafeRailwayCrossing rail RAIL cross CROSS last enterC last exitC last down last up last raising last enterC last down

ti t t i

i i

i i t l y t

T

R last exitC cross runs through rail R maxR last up last raising i

i

il y t l t ti l t ti i t ti t l y lt

i i t

y

t t ti t y t l it i t s i

t iy t lt ty t i t ti t s ti lX i l ti t it t t t i ti i i t i l l y i l t t t t ti  t i t l

il i t t

Behavior s X sat t T r RAIL tr TRAIN c CROSS SafeRailwayCrossing rail r cross c s t enterC  tr r c last enterC s t exitC  tr r c last exitC s t down  c last down

t il ity

t i l y t il y t i t i t y

t t

t t

t t

t il y it t

t

t

i t t l

i

END UNIT i lt t tl y i 4.2 t t i

ti t it y t iy ti

y t

i t

t

t

i lt

t it i t

il lt t t t t y

t

t

t t

i

t

i t t ti

System Design t t ty t i t i t y t il y t i i t t y t t t gate t lt ti t i t it i t i t t controller i t i l l t i t t ti t t t it i t t i t i

i

t t t

t

t i y

train i t i t t t

r

i t i t

t

y t l l i

¨

l enterN exitN exitC t t l l i t l lower t i ti it t

SPEC. UNIT RailwayNetworkDesign

t raise l t t

t y t

i

EXTENDS TechnicalPars

LOCAL channel enterN exitN of type TRAIN RAIL channel enterC exitC of type TRAIN RAIL CROSS channel lower raise lowering raising down up of type CROSS SUBUNITS i ti y t t t i t t i train TRAIN spec. unit Train gate CROSS spec. unit Gate controller spec. unit Controller BEHAVIOR physical t i li

t

t y t

i t

i

ti

it

i

t i y i li t Behavior   train id Behavior Behavior  id TRAIN enterN exitN exitC controller Behavior lower   raise i

y t ti

it

id CROSS

t

ti

gate id Behavior

END UNIT i ti it t t t il ity it t l t i t y t i l y ti t y t t t l l y t l l t il y t i t t t t i t it t t i t t t l t i ti it t t ti t t l i t t t l l it t t t i t i SPEC. UNIT

t

l l y

l

i t t

l

l l i t

Train

INTERFACE channel enterN exitN of type RAIL channel enterC exitC of type RAIL BEHAVIOR i t it t t il y

i t

y t it

y

CROSS t Behavior i il y l i t it

l l y ti

pp

i t



t

i t

l l l

t y t t t t 1r c 2r c

p

i y t Wait t i t il y t i t l i il y l i ti y i t ti l

Behavior 

r

X

RAIL

i

END UNIT y t ti i tl y i i it 4.3

t

t

t it il y

Wait

t

1

exitC r c

rc

ti ti

2r

t

i

i

i t i t

l

enterC r c

t t t t

t

c

Wait T+ exitN r

Skip

t l l i

t t

Wait T+ enterN r

i

t

ti t i t l i it t i t lT+ t t t t il y l i i it t t t t t y i t t i c i t i t t t

t i i

c runs through( r ) +

Wait T

r

i l l

t i

X

y t t t i

i it

l

Software Specification i t

y

t i t

t

i

t

ti

t il y

t

i

ti

i t t t l l t

t

tl y i l

t t

t t

t

SPEC. UNIT

i t

t

t

t

l l

t l y

SCInterface

INTERFACE i t t t t

t y t t t t

t

l l

t t i l l lt t t y t i i i it i t y t i t t t t i lenterC i t l t i t y t ti l y t t y t i i t il y i t t t l l i t i t t t ii l i t y t i it i t tt t y t i i t t il y 3 i il l y t t t i i t y t l up down lowering raising i l lt t t it i t t t t t t l l t i

t

channel enterN exitN of type TRAIN channel exitC of type TRAIN RAIL channel lower raise of type CROSS

RAIL CROSS

END UNIT 3

r r p

p r

r

r

r

k

r r

r

r r

0

r

¨

SPEC. UNIT Controller

EXTENDS TechnicalPars SCInterface

BEHAVIORAL PROPERTIES t i t t i t t t i t t i t l il y t t ti il l i i t t lt y t i t i t l y t t l i t y t t t i t t l l i t i t il y i t i t l y t t t t l l i t TrainInCrossing i il y l i rail t it t i t t t i t i

t

l l i l i t

ty y

t

i t lt i i t l l i i ti t t y t i

t t

t i

t t t t

ti l t

il y i crs t t l y lt

TrainInCrossing rail RAIL crs CROSS last enterN last exitC T crs

runs through

rail

R

last enterN

1

R last exitC

rail crs

i i t t t i t t i t t t l l Behavior s X sat t T r RAIL tr TRAIN c CROSS T t s t enterN  tr r 1t t TrainInCrossing rail r crs c last enterN s t −exitC  − tr r c − last exitC − lower c live from t R 1 r c −R γdown c r c − −l t s t R 1 R γdown c  − lower c raise c − lower c −− − s  − raise c −− t R 1 r c −R γdown c t t i tr t t t il y i c r t ti i t t t i t t i t lt l y l t t i t t R 1rc l y l t t t t t t t t i

t t

t

il y l i r t t t t t i i t l i t R 1rc t i t i lt i t l t t t i γdown c t −R γdown c t t lt t l t t t i l t ilt i l t il y i c l

t t

t

ly t

END UNIT 4.4

Software Design

t i i

ti t i

iy t

l li ty i t

t t

it t

l t

t t l

t

t t l

y l l ty

pp

t t t

safety

p

t

t

i l t ty

i t l t t l ti t ti l l y i it

l y t t t i t it i t i i it i l l y lt t

SPEC. UNIT ControllerDesign

r

t i

ty

t

il y ti ti l t t ti l i

t gen control lt t i t i t t l l t ty lt l t l t t

EXTENDS TechnicalPars SCInterface

SUBUNITS safety spec. unit SafetyComp gen control spec. unit ControlComp BEHAVIOR l ll it i t − − it t i t t t l t l raise li t y i ti ti l y i t t t i ty t tt l i i lt i t ty lt lower li t t t y i ti t t l i tl y t t t y t l t l t

y ty t

i ti i

t t i

t l t i t t t t ty l i

l t t t

t t

t i l y i i t t l t t

t

Behavior  safety Behavior −−−raise − −− −−enterN − −− −−exitN − −− −−exitC − −− gen control Behavior END UNIT i t

l l y t i

iyi

tl i i t ti

t l t

t

t

i

i

t ti

ti it i

i i

t i

t t

t i

t

l ti

t ti y t

ti t

t l t

ti t

SPEC. UNIT SafetyComp TYPES & CONSTANTS it i t t t t ti t t t t Δop

l

t t l t

ty

t t i i t t t lt i t t t t t i y t t ti t i t l t l t t t l ti l i i t i i t t i ti t

t it i i t i

EXTENDS TechnicalPars SCInterface l ti

t ti t

t i t t ti

t ti t

i i ti

l y t

r

¨

TrainStatus GateStatus STATE t it i ti t lt t t

t

ty

phase Δop

In −Out Down −Up lt t i il y l i il y

Δop

T+

R phase

t

i t t ty t t t t i i t t it t t i i lt i t train in rail t i t t t ty i sched time lt t t i i t t i i t t tl y t t t t l t i t

t ti l t i t t i i lt i i lt i

State train status TRAIN → TrainStatus train in rail TRAIN →  RAIL sched time TRAIN →  CROSS →  T gate status CROSS → GateStatus dom sched time dom train in rail {tr TRAIN | train status tr In} ∀ cr CROSS | gate status cr Up • ∀ tr TRAIN | tr ∈ dom train in rail ∧ cr ∈ runs through |{train in rail tr }| • sched time tr cr γdown cr

R

OPERATIONS li l y t t i enterN i t tt t il y l i

ty

t t

t

ti

i

t

ti t

t

l ty

il y

tt t

i ti l

enterN ΔState id TRAIN × RAIL train status first id

Out



train status train status ⊕ {first id → In} train in rail  train in rail ⊕ {id } sched time  sched time ⊕ {first id → 1 second id } gate status  gate status

BEHAVIOR t Behavior i t ty t tt ty t i y t i t i i ti y ti it it t Phase

t t t t t it

ti

l l t t y l i l l y t t t i i t t

t t t l i ti

i t l t l i it i i i Phase it t i t phase t i t t t t

pp

t l y

i

t

t t

t

p

i

r

t i

it i

Behavior 

Cycle − Phase − −phase−Phase

Phase 

TrainCtrl

TrainCtrl i i i t t t il y l i t i t it i i ly Δop t i t il lenterNX ti it i

t t i ti

ti

t

ty t enterN i i ti i t ly t

t

t l l l ti

Cycle

t t ti l t

t ti

y t t

t t

TrainCtrl  X − enterN id TRAIN − RAIL − Wait Δop enterNX par enterNInMap id − X

2

END UNIT i

i iy i

t lt i

5

ti l

t t ti

ty

t t

t

t

t

t t i

il ity l i

t

Related Work tl y

t t i t

i i

l i t

i

i t l i t i i t i ti l ti i t i t i l l i y t t i t l i l l y lt t t j t it t i t l iz l i t ll t y t i i t lt tt t y ti t t l i i t it t l t ti t y i

l t i yi

l t ti i t ti l yi i i l i t l i ti ty it i l y t l i i l i i i i l i i it

i i t i t t l l t t i t

i

l i

i t l i

li il iyi

i iyi

l ti t t t i l y it

l i t

l t

t

i t

ti l y lt i y t t i ti t t l it i i i t ti t t it t t iy t t i t it t il t ti l t t i ti

r

t

¨

t i t t

t yi

t

t tl y

t il l

l l

l

i

6

t

i ti

t

l i it t i t y i t t y t y t t t li t i l it t y il ity t t t t t t t iy i i t ti t i l i t t ty it i t i t y i t t ti i t t t i t t i y t ti t t i i t t t t it i y t l i t ti t it t i i t t t t t t y ti t t l y l l t iy fl t t t it i i t l y t y t i t y i t i t t l t it t

ti

ti t

t

i t

t

i t it t y y i l l t ti y t t t y l y l i t

t t t

i

t t l

t

l ll t

y t

Conclusion

i t i ti t i i t t ti i i lt t t l t t it i ly t i i t l t t i t i t i i y t y i li ty it i l y t i i t ti lt t ty i ti 3 it i t t l i t t i t l y ty it i l t t ti t t y i t t t t ti l lt it i i t t ti t

–

it

t l y t i i ti l i t ti

t i

–

l i

–

t

l i it i

ty ti

t

l t t ti

t

i t l

l l y t t

i

y t

iy

ti

i

l l t

t

t

i

t it

t

t t

t l l

t

i y t

ti

i il t t t t lt it t t

i

t

y it it iy

i it l t

t

t t t i l y t t ti i l l y i t

l l y t

y l i l l i ti

t l

y

t

l l l y

t i t

i ty i t

t t t

i

l t i t l i l t it i ly t t i it ti ti j i t t i t t y t t t i i ti t it ti i t t lt i i

t

l t t t

pp

p

r

Acknowledgement y t t

t ti

i t it i i

i t

t

y

l l

t

References r k r Proceedings of the 1st International Conference on Integrated Formal Methods pr r r r r r r k r k r r FME’93: IndustrialStrength Formal Methods 0 LNCS p 0 pr r r r r Theories and Experiences for Real-Time System Development r p r rr k r Formal Methods for Open Object-Based Distributed Systems (FMOODS ’97) p p r pr r r ZUM ’98: The Z Formal Specification Notation r p pr r r r r Proceedings of INFORSID ’97 r r r p r r r IEEE Software ¨ r p r Proceedings 15th International Conference on Computer Safety, Reliability and Security pr r ¨ pp r r r p r r Proceedings 16th International Conference on Computer Safety, Reliability and Security pr r 0 r r r r r r r r r r r p r r r Formal Methods for Real-Time Computing r r r Safeware: System Safety and Computers r r p r pr r IEEE Transactions on Software Engineering 0 0 p r Proceedings of the 20th International Conference on Software Engineering p 0 p r r ¨ r r k r Proceedings of the 1st International Conference on Integrated Formal Methods pr r k Using Z: Specification, Refinement, and Proof r

A Process Algebra for Real-Time Programs nn n

k

m m 0 m [email protected]

m

Abstract. m m m

m m m

m

m

m

m m

m

m m

1

m m m

m m

m

Introduction

n

w w n n

w

n

l

ln w

n l

n n

n n

l n

n

n l l

n

n l n

n

l l l

l nn w

n n n

l l n

w n n

l ln l n l ln l

n

l l n w

l l n

n n

n l

n

n

ll l

n

l n

n n

n l

l

n

n n

n

n

n n

l

n

n n

l lw

l

n

n ln

n

l lw w

n

n n n

n

ln w

n

n n n l

n

l

l

n



T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 66–81, 2000. c Springer-Verlag Berlin Heidelberg 2000 

n n n l n n n n l n n n n n n n w n mm

m

m

n

n l n l n

l n

w n lk n

l

m

n

n

l n n n

n

n n

n

n l l w n n k l n

n

2

Programmable Logic Controllers n

l n n l l n l l w kn n l

–

l

lk l l n n ln n n l

– n

w w

Polling: n l n l Computing:

n l l n n l

n

n

n n n

w

nn

l

n

n

l

n

n n n l n n n

n

n

n l

kw

l

n

n n

n l

n l

n

l w n

l n

n

n

n

n n l l

n n n

n

n ln

n ln n

n

l

n

l ln

n

n n

n

l

n

n

n

l n

n

n l

l n ln

l l

k

l n

w l lw

n n l

Updating: n

n

l lw n

n

n

–

n

l

n

n n n n l

l

n

n

–

w

n ln n

n

nl n n

l

n

n n

n

n

n n

n n n

n

n n

n n

n w n

n n

updating polling

computing

updating polling

computing

updating polling

polling

PLC

computing

input values

Input

output values

Output

Time max. cycle time

max. cycle time

max. cycle time

l

Fig. 1.

m m

3

The Definition of GPLC-Automata

n n

l

n n

w

l l ln

l

n

n

n

n

w

n

n

n w

l

l l

n w n n

n

n n

n

n l

n

n n l n n n l l n n n l l l l n l l l ln l ln l ln n n n true n l l ln n w n n l n n ln l n n n l w wl l n l n w n n n w n n n n n n n l lw l l n n l w n n n l n n l n l n n n n n n n l n n l n n n n n n n n n n n l l ln n l l l n ln n fl n n fl n fl n n n l n n w n n l

m

B B

fl

0



,

not hr

t1

 hr out:=pg

idle

m m

m

purge t1

0 fl out:=id

not t1 out:=ig

hr out:=id burn

ignite not t2 out:=bn

t2

fl and hr

t2

Fig. 2. A gas burner controller as GPLC-Automaton. w n

n

n

n l n l l

l lw n w w l l n −

w

l

n

n

n

− w

n

n

l l

l

w −

?

− −

−−

l l −

n n − n −− l lw 

−−

− n

n n

l l

w

n

nn n l

n

n

– – Σ− – − – − – Ω− – −−−−−

– –

?−

0

n

l

n − −

n l n l w ln w

n w n

n l l

l lw n

l n l

Definition 1 (GPLC-Automaton). n − Σ

–

w

df

l

n

−

n n

n l Ω −−−−−

n 0

n l l

−

−

n −Ω

l l l l −− −Ω −− Σ −− n l n n l n n

−−

n −− n

n

n

(

Ω)

−−?−

0

R

−−

– Σ − −

Ω

−−

1−

nn n

0

−Ω

( )}

−− Σ

2−

1

2

−−

− −−−−−

( )}

−−−−−

1

2

fl wl l −− Σ n n n n

−−−−− − −−−−− n l n n

n n −− w l lw l ln n l n l n n ln lw n

l n l

n

l

true

n

n n

l false n n w

n l

n n l

n n n

n n

l n l n n l l l l wn w n

n n

n

n n

n

4 n

−Ω

n

n n n n n l n n n l n n l n l lw n n n l n l lw n nn n n l l − − n l n n n n l n n n n n nn n n n n n n n

l

n n

−−

w

l lw n l Σ n n

−

l

l n n n

n

n n n l l n l n l n n n l l l l l n n n l l n l l l l wl l n n l w l n

l n

n w n

l lw n n l

n l

The Timed Automaton Semantics of GPLC-Automata nw

n

n n n

n

n l n n n n n− n

n

n

nT − n n

m

T −

n1

l

−− − −− Σ n −− Σ n − − − −Ω −−

n n

l n n n n

l

w n l l

n n

n

n

l l

n n

l

kn

m

lk

l n l n

l

n l n n

l n

n

l

n

n n l n lk n

l

n

l n n

n

l

n n

n n

n n

w

n

lk

w

n

n

l ln

n l ln

n

n n w l lw

n

w wl l

n

n l ln

k l l n

n n

n

n

l n

l l

n l ln n

n

n

n

w l

l ln

n

n

n

w n

n l

l n n l n n

n n n nwl ln l n n w l n l w l w n n k l l n n n n n l n n l n n n k l n l n n l n n w n l l l l n l w

Definition 2 (Timed Automata semantics of GPLC-Automata). T − − Σ Ω −−−−− 0 − − − − −− − 0 – – – – – –

− −− − Σ − − Σ − − − − Ω − − − −− − − − − lk df − Σ −− − l l − df − n n −− −− df − − Σ − − Ω− − obs − − −

− − −

df

l

n

df

1

m m

n m



ϕ ,true,{x} −−−−−−−− poll ,0 0] X = X-1;

INC / [ X < 100] X = X+1;

S1

STOP

j m

mm

m

m 3

m

m m m

m k

j m L m

m

z

j k m L

Analysing UML Active Classes and Associated State Machines

3.5

137

Determining the L-States L

L ACL

j

m

3

j k

j m

SM

j

m

m m

m

m

j L

m

m m

k m

m

m

history

j

m m

L

Casl

spec L-State = Ident and Configuration and Attributes and Event Queue and History then free types State ::= Ident : Configuration, Attributes, History, Event Queue Ident : terminated ......

Ident terminated

m

m

j

m

m m

m

spec Event Queue = Set[Event] then sort Event Queue preds no dispatchable event : Event Queue %% checks whether there is no dispatchable event : Event Event Queue %% checks whether a given event in the queue may be selected for dispatching ops put : Bag[Event ] Event Queue Event Queue %% adds some events to the queue remove : Event Event Queue Event Queue %% removes an event from the queue ......

138

G. Reggio et al.

3

PROBLEM

m

3 m

m

m

m

j m

m

2

m

m m

m after 0

after m

m

m

m m

m

m

m

m

m

j

j

m k

m

m

m k

m k j

m m

m

m m

L

Determining the L-Transitions

3.6 L

L

2 3

m

m

m

3 m

m

m

m SM

m

2

L j 2

3

m

m m m

m L

L m

m

m

Analysing UML Active Classes and Associated State Machines

139

S, {} receiving E

receiving E1

S, { E} dispatching E

S, { E1}

receiving E S, { E1,E}

S1 , {}

State

l

s −− s 

......

m m

m

m m

m m

m m

sans serif font

m

m

Dispatching an Event m m

k k

j not frozen dispatchable m

z

m

ev L in evs

m

t

e queue

Receive Events Dispatch ev, conf, e queue conf 1 , e queue 1 m ev conf conf 1 e queue 1

not frozen(conf) dispatchable(ev, e queue) Dispatch(ev, conf, e queue) = conf 1 , e queue 1 in evs,t,∅ id : conf, attrs, history, e queue −−−−−−−− id : attrs, conf 1 , history 1 , e queue 2 e queue 2 = Receive Events(e queue 1 , in evs, attrs, history, t) history 1 = active states(conf), attrs, , t & history

Executing an Action m k m

j frozen m

L in evs

m t out evs Receive Events

140

G. Reggio et al.

Exec id, attrs, conf conf 1 , attrs 1 , out evs, loc evs m conf attrs 1 loc evs

j id conf 1 out evs

Exec(id, attrs, conf) = conf 1 , attrs 1 , out evs, loc evs in evs,t,out evs id : conf,attrs,history,e queue −−−−−−−−−−−−− id : attrs 1 ,conf 1,history 1,e queue 1

frozen(conf)

e queue 1 = Receive Events(e queue, in evs loc evs, attrs, history, t) history 1 = active states(conf), attrs, , t & history

j

Receiving Some Events m k − frozen no dispatchable event m m

m

k

L in evs

m

t

Receive Events frozen(conf)

no dispatchable event(e queue) in evs,t,∅ id : conf, attrs, history, e queue −−−−−−−− id : attrs, conf, history 1 , e queue 1 e queue 1 = Receive Events(e queue, in evs, attrs, history, t) history 1 = active states(conf), attrs, , t & history

Being Destroyed j m

m z k

not frozen

not frozen(conf)

dispatchable(destroy, e queue) in evs,t,∅ id : conf, attrs, history, e queue −−−−−−−− id : terminated

3.7

Constraints m

m

m

m m m m m 2

3

2 30 A constraint is a semantic condition or restriction expressed in text. In the metamodel, a Constraint is a BooleanExpression on an associated ModelElement(s) which must be true for the model to be well formed. . . . Note that a Constraint is an assertion, not an executable mechanism. It indicates a restriction that must be enforced by correct design of a system.

2

Analysing UML Active Classes and Associated State Machines

m

m z SM

ACL

141

m L

m

Casl

Casl

m

m

Casl m Casl

m m

m

m

m L − Φi

Cn SM

C1 ACL Casl m

m Φi

ACL SM i 1, . . . , n

m Ci m

m

m m

PROBLEM m m

m OP1

OP m

m m

m

m S

C int X, Y = 0; class diagram:

state chart:

Op(int n); Op1();

{X>Y}

Op1/ Y = Y+1 S1

k m

Op(n) / X = n;

m

m

j m

m

m k

m m k

m m

m

4

Auxiliary Functions

Receive Events : Event Queue × Set[Event] × Attributes × History × Time → Event Queue e queue 1 m e queue 1 Receive Events e queue, evs, attrs, history, t e queue m evs m t history TimeOccur attrs history ChangeOccur

142

G. Reggio et al.

j

PROBLEM m m

m

j m

k m m

j m Receive Events

m Receive Events(e queue, evs, attrs, history, t) = put(TimeOccur(t, history)

ChangeOccur(attrs, history)

TimeOccur

evs, e queue)

ChangeOccur

Dispatch : Event × Configuration × Event Queue → Configuration × Event Queue conf 1 , e queue 1 m Dispatch ev, conf, e queue e queue e queue 1 ev conf conf 1 m

Some transitions triggered by an event

m

m

SM

E

m

Sset 1

S

S

r

E (X 1 ,...,Xn ) 1

E (X 1 ,...,Xn )

1

[cond 1 ] / act 1

1

1

[cond k ] / act k 1

S

1

1 1

S

.........

Sset Sset h r m

actqi i i

.........

r

r

1 k1

S

r 1

h

m 1, . . . , r q

active states(conf) = Sset

Sset’

S

.........

i

k1i , . . . , krii h i i=1 Eval(condqi [pj /xj ], attrs)

r

r kr

Siqi i m

m i

r

condqii m

j m 1, . . . , h

r

r

[cond k ] / act k

[cond 1] / act 1

1

1, . . . , h 1, . . . , h m condqii

= True

Dispatch(E(p1 , . . . , pn ), conf, e queue) = conf 1 , remove(E(p1 , . . . , pn ), e queue) conf 1 = run(. . . run(conf, Si , actq11 [pj /xj ], S1q1 ) . . . , actqhh [pj /xj ], Shqh )

active states

run

Configuration m

m m

m

Analysing UML Active Classes and Associated State Machines

m

PROBLEM m m

m

m m m

m

m PROBLEM m m

ACL m

j m 2

3 m

PROBLEM m m

m

m

m

3

m Op m

m

m Op m

m 3

m 2

m

3 S

C int X = 0;

Op1(n,m) / X = m * n;

Op1(n,m) / X = m+n;

{ X = X - n; O1.Op’(n); }

Op(int n) Op1(int n, int m)

S1

m

m

m m

No transitions triggered by a deferred event m SM m E E m m Sset PROBLEM 3 m

143

m Sset E

m k k m m m j Sset

E p1 , . . . , pn

active states(conf) = Sset Dispatch(E(p1 , . . . , pn ), conf, e queue) = conf, e queue

m

144

G. Reggio et al.

5

Conclusions and Related Work k

m

z

m m k

m

m

m

m

k m m

k m

m

m

k m

m

m

m

m m

m

j

m m

m

m

m

m

m m m m

k

m

m

m

k

k

m

z

k m m

m

fl

m m

m m

m m

m

k

m

m m m

m

m

z

m m

m

m

m

m m

m

k m m

m

z

m m

k m

2 m m

m m

m

m k

m m

k m

m m

k

m m

m m

m m

m

m

Analysing UML Active Classes and Associated State Machines

m

145

3

0 k j

m

m

m m

k m

m

m z m

Casl mm

m

z

k m

m

z

m

m

m

References [1] E. Astesiano, A. Giovini, F. Mazzanti, G. Reggio, and E. Zucca. The Ada Challenge for New Formal Semantic Techniques. In Ada: Managing the Transition, Proc. of the Ada-Europe Conference, Edimburgh, 1986, pages 239–248. University Press, Cambridge, 1986. [2] R. Breu, R. Grosu, F. Huber, B. Rumpe, and W. Schwerin. Systems, Views and Models of UML. In M. Schader and A. Korthaus, editors, The Unified Modeling Language, Technical Aspects and Applications. Physica Verlag, Heidelberg, 1998. [3] E. Coscia and G. Reggio. A Proposal for a Semantics of a Subset of MultiThreaded Good Java Programs. Technical report, Imperial College - London, 1998. [4] G. Costa and G. Reggio. Specification of Abstract Dynamic Data Types: A Temporal Logic Approach. T.C.S., 173(2):513–554, 1997. [5] M. Gogolla and F. Parisi-Presicce. State Diagrams in UML- A Formal Semantics using Graph Transformation. In M. Broy, D. Coleman, T. Maibaum, and B. Rumpe, editors, Proc. ICSE’98 Workshop on Precise Semantics of Modeling Techniques(PSMT’98), Technical Report TUM-I9803, 1998. [6] K. Lano and J. Bicarregui. Formalising the UML in Structured Temporal Theories. In B. Rumpe H. Kilov, editor, Proc. of Second ECOOP Workshop on Precise Behavioral Semantics, ECOOP’98, Munich, Germany, 1998. [7] J. Lillius and I Paltor. Formalising UML State Machines for Model Checking. In R France and B. Rumpe, editors, Proc. UML’99, LNCS. Springer Verlag, Berlin, 1999. [8] P.D. Mosses. CoFI: The Common Framework Initiative for Algebraic Specification and Development. In M. Bidoit and M. Dauchet, editors, Proc. TAPSOFT ’97, number 1214 in LNCS, pages 115–137, Berlin, 1997. Springer Verlag. [9] OMG. White paper on the Profile Mechanism – Version 1.0. http://uml.shl.com/u2wg/default.htm, 1999. [10] The CoFI Task Group on Language Design. Casl Summary. Version 1.0. Technical report, 1998. Available on http://www.brics.dk/Projects/CoFI/Documents//Summary/.

146

G. Reggio et al.

[11] G. Reggio, E. Astesiano, C. Choppy, and H. Hussmann. A Casl Formal Definition of UML Active Classes and Associated State Machines. Technical Report DISITR-99-16, DISI – Universit` a di Genova, Italy, 1999. [12] J. Rumbaugh. Some questions relating to actions and their parameter, and relating to signals. Private communication, 1999. [13] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. Object Technology Series. Addison-Wesley, 1999. [14] UML Revision Task Force. OMG UML Specification, 1999. Available at http://uml.shl.com.

Software as Learning: Quality Factors and Life-Cycle Revised* José Hernández-Orallo and Mª José Ramírez-Quintana Universitat Politècnica de València. Dep. de Sistemes Informàtics i Computació Camí de Vera s/n, E-46071, València, Spain E-mail: {jorallo, mramirez}@dsic.upv.es

Abstract. In this paper Software Development (SD) is understood explicitly as a learning process, which relies much more on induction than deduction, with the main goal of being predictive to requirements evolution. Concretely, classical processes from philosophy of science and machine learning such as hypothesis generation, refinement, confirmation and revision have their counterpart in requirement engineering, program construction, validation and modification in SD, respectively. Consequently, we have investigated the appropriateness for software modelling of the most important paradigms of modelling selection in machine learning. Under the notion of incremental learning, we introduce a new factor, predictiveness, as the ability to foresee future changes in the specification, thereby reducing the number of revisions. As a result, other quality factors are revised. Finally, a predictive software life cycle is outlined as an incremental learning session, which may or may not be automated.

1

Introduction

Software engineering was considered a pure science just two or three decades ago. Theoretical and formal methods were prevalent. Nowadays, we have a much more realistic conception of software engineering as an experimental science [6]. Empirical studies of real problems are encouraged and their conclusions are usually much more successful in practice than theoretical results. Moreover, many times theoretical studies are not applicable because in the end they do not model the software construction process. In our opinion, the formal methods in software engineering cannot be fully exploited due to still frequent conceptions of software as being “from specification to final product”. This does not take maintenance nor the generation of that specification into account. Fortunately, there is an increasing interest in requirements elicitation and evolution as the most important topics in software engineering. Requirements Engineering has made some important things patently clear: the need to take the context of a computer *

This work has been partially supported by CICYT under grant TIC 98-0445-C03-C1.

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 147-162, 2000. © Springer-Verlag Berlin Heidelberg 2000

148

José Hernández-Orallo and Mª José Ramírez-Quintana

system into consideration, i.e., “the real-world environment in which the system operates, including the social structure and the people therein” and the fact “that requirements are always incomplete; each stage involves identifying new requirements based on experiences from previous stages… and requirements and design affect each other” [8]. The other two fundamental (and more classical) areas of research for improving the economics of software have been reusability and modifiability, the latter being more relevant when a particular system is already implemented. The maintenance cost is greatly reduced by improving the modifiability and/or extensibility software quality factors. Another neglected but fundamental question is whether we are able to reduce the modification probability. The idea is to ‘predict’ requirement evolution as much as possible, in order to minimise the remaking of software as a trace of this evolution. In order to gain greater benefits, this “predictive model of requirements” should be made upon previous models by reusing parts of other specifications and taking context into account. It should be explicitly stated that this predictive character of the model must be preserved during the remainder of the life-cycle: the design must be conceived to maintain the generality of the model, validation must be made according to this general model, and, more importantly, future modifications must consist of coherent revisions, not extensional ‘patches’ to the model. With the appearance of new approaches, such as adaptive software [28] or intelligent software [30], which include techniques and languages for further generalisation, an empirical and theoretical study of when a generalisation of the model is useful and how it should be done seems necessary. The flippancy here would be to start from scratch or to reinvent the wheel. As we will see in the following sections, predictive modelling in particular and philosophy of science in general historically been able to provide us very useful terminology and tools to select the most likely or the most informative model. This paper tries to emphasise the benefits of adapting the paradigm of theory construction to software, and to recognise and situate the role of induction in software engineering. In fact, recent popular subjects in the field such as adaptive software or intelligent software are in essence inductive. However, none of them use inductive tools and techniques in an explicit way. Induction, as we use throughout this paper, is the process of theory abstraction from facts. Karl Popper proposed [36] the concept of verisimilitude as the level of agreement with the facts. Since there are an infinite number of theories which cover a finite number of examples, the question of verisimilitude must be contrasted with all the possible future examples that may appear in a given context. The quandary of whether there is any way to know, a priori, if a given hypothesis will be followed by future experiences in that context is obvious. If we know the initial distribution of hypotheses in that context, the plausibility of the hypothesis can be obtained in a Bayesian way. Since this initial distribution is generally unknown, many different measures of the quality of theories have been proposed in philosophy of science and Machine Learning (ML), generally in an informal way. From these, there are two main trends ([39]): descriptional induction ([5]), which is usually related to the simplicity criterion (or Occam’s Razor) and the view of learning as compression; and

Software as Learning: Quality Factors and Life-Cycle Revised

149

explanatory induction ([39]), which is more closely related to coherence, cohesion or ‘consilience’ criteria ([41]). In 1978, Rissanen formalised Occam’s Razor under the Minimum Description Length (MDL) principle, quickly spreading over the theory and practice of ML and predictive modelling. In his later formulation ([5]), the MDL principle advocates that the best description of a given data is the shortest one. Apart from all the methodological advantages of simplicity, the major reason for using the MDL principle is that it usually avoids over-specialisation (underfitting) and overgeneralisation (overfitting). From here it is usually argued that “the shorter the hypothesis the more predictable it is”. On the contrary, ‘consilience’ or coherence refer to the idea that the data must be covered by the same general rule. Thagard ([41]) postulated that “explanatory coherence” is more important for durability than prediction and confirmation: “a hypothesis exhibits explanatory coherence with another if it is explained by the other, explains the other, is used with the other in explaining other propositions, or if both participate in analogous explanations”. Another related notion is that of intensionality ([19]), which is based on the avoidance of extensional patches to the theory. The convenience of both these trends will be studied for the case of software, in order to obtain predictive and coherent models for the requirements which will improve software quality factors. In the ML literature [31], there is a classical paradigm that is necessary for problems of medium or large complexity: incremental learning. The evidence is obtained incrementally and new evidence can appear which may force the revision of the model. Revision is then the most important process in incremental learning and is motivated by two kinds of errors: anomalies (cases which are not explained by the current theory) and novelties (new cases which are not covered). The incremental paradigm is the most appropriate one for software. The paper is organised as follows. In Section 2 we introduce an analogy between software development and theory induction, which we contrast with previous (and very debated) analogies between software development and deduction and mathematics. Section 3 reviews many software quality factors under the inductive paradigm. A new quality factor, ‘predictiveness’, is defined and is related to other software quality factors such as functionality, validation, reusability, modifiability, … Section 4 introduces a new life-cycle as an incremental learning session which attempts to reduce prediction errors. The automation is discussed, as applied to declarative programming (logic programming), because the techniques and stages required for the new life-cycle (ILP, evaluation, transformation, revision, etc.) are much more mature than in any other paradigm. Finally, Section 5 concludes the paper with a discussion of the practical relevance of this work and future directions.

2

Programs as Scientific Theories

The statement “programs are scientific theories” or, alternatively, “software is a learning process” summarises the main idea developed in this section. Before

150

José Hernández-Orallo and Mª José Ramírez-Quintana

presenting this analogy, we will review the most well-known analogies in order to understand software development. In our opinion, these analogies have failed to capture the essence of software, although partial mappings have been useful. 2.1 Existing Analogies The use of analogies with pure mathematics to formalise the processes of computer programming was greatly influenced and promoted by the seminal paper from Hoare [24]. This first analogy, known as “Verifiers’ Analogy”, established that proofs are to theorems as verifications are to programs: Verifiers’ Analogy Mathematics Programming

theorem proof

↔ ↔

program verification

After the first successes of some simple programs of algorithmic nature, the debate began precisely from the side of mathematics, exemplarised by the influential paper by De Millo, Lipton and Perlis [13]. The preceding analogy was criticised and replaced by the following one, which is based on the idea that programs are formal whereas the requirements for a program are informal: Mathematics

De Millo-Lipton-Perlis Analogy Programming

↔ ↔ ↔

theorem proof imaginary formal demonstration

specification program verification

The new trends in automated programming, popularised by the logic programming community, were very difficult to conciliate with an analogy with mathematics as a social science. Thus, the analogy was revised once again [38]: Automated Programming Analogy Mathematics Programming

problem theorem proof

↔ ↔ ↔

specification program program derivation

However, Colburn [11] affirms that “for unless there is some sort of independent guarantee that the program specifications, no matter how formally rendered, actually specify a program which solves the problem, one must run the program to determine whether the solution design embodied by the specification is correct”. In this way, he postulates that software is the final test for validating the specification.

Software as Learning: Quality Factors and Life-Cycle Revised

151

Finally, Fetzer reopened the debate and introduced an analogy between computer programs and scientific theories [17]: Fetzer’s Analogy Mathematical Proofs

Syntactic Entities: Semantic Significance: Causal Capability:

Yes No No

Scientific Theories

Yes Yes No

Computer Programs

Yes Yes Yes

In our opinion, the difference between scientific theories and programs in causal capability disappears if we consider software to be a learning process (which shares the same paradigm with philosophy of science but has causal capability), where the learned theory (the program) can be used to interact with the environment. 2.2 Scientific Theories and Programs The assumption that there is an “independent guarantee” that the specification is correct for a given problem is rather optimistic in the context of modern software development, where requirements and, consequently, applications are very complex. It is impossible to completely and definitely establish the intended behaviour that the system should show. Current methodologies end up accepting the dynamic character of requirements, and include loops back to each of the stages, including a loop to requirement elicitation. Then it is finally recognised that requirements are never completely stated, that they evolve and that they are related to the environment, the context of specifications, the ‘reality’. The same idea is implicitly suggested by the maxim that “testing can be used to show the presence of bugs, but never to show their absence” [15], although applied to a restricted view of software. The extended maxim “requirements cannot be fully validated, just invalidated” conforms perfectly with Popper’s conception of scientific methodology [36] where scientific hypotheses can possibly be shown to be false but can never be shown to be true. This impels us to looking for more realistic conceptions of programming. We propose a new analogy between scientific methodology and programming methodology which shows the numerous links that can be established: Programs as Scientific Theories Analogy Science Programming ↔ reality requirements context ↔ problem problem ↔ experimentation data cases / interviews / scenarios ↔ construed evidence requirements ↔ evaluation analysis ↔ best hypothesis specification ↔ refinement transformation ↔ theory program ↔ verisimilitude correctness ↔ anomalies exceptions

152

José Hernández-Orallo and Mª José Ramírez-Quintana confirmatory experiments confirmation revision background knowledge technical books science text books

↔ ↔ ↔ ↔ ↔ ↔

testing validation modification SW. repositories technical/programmer's doc. user documentation

The difference between best hypothesis and theory in Science is less than the difference between specification and program in software engineering. In both cases, however, a hypothesis-specification is not usually predictive/operational and it must be refined/transformed into a more manageable and applicable form, by the use of mathematisation/formalisation and a proper engagement with the background knowledge / repositories. As we have stated, the analogy should be well understood by regarding programs not only as simple scientific theories which predict the outputs for given inputs but also as systems that interact with an environment or reality according to the ontology and hypotheses that have been learned, i.e., interactive learning systems. This ‘new’ analogy offers many equivalences to work on and many of the results in one field can be applied to the other. Therefore, following this comparison, Figure 1 shows how deduction and induction are more or less used depending on the stage of the development of a scientific theory or a software system. Problem Experimentation Data Background Knowledge

S c i e n c e

GENERATION Hypotheses

EVALUATION Hypothesis

REFINEMENT Theory

CONFIRMATION

Use Cases, Interviews Repositories, other SW systems

1 Ind

Requirements

2 Ind/Ded

3 Ind/Ded

4 Ded

Predictions

REVISION

S o f ANALYSIS Specification t TRANSFORMATION w Program a VALIDATION r Behaviour e ELICITATION

5 Ind/Ded

MODIFICATION

Fig. 1. Main stages in scientific theories and software systems development.

It is remarkable that, in some way, the philosophy of science and software engineering are complementary in experience and techniques because they have focused primarily on different stages. For instance, the third and fourth stages (of a more engineering character) have been thoroughly addressed on the software side, especially the stage that is called ‘transformation’, which includes design and codification. In automated programming,

Software as Learning: Quality Factors and Life-Cycle Revised

153

this transformation stage is the most important one, because it is not convenient to directly execute the specification, and it is necessary to transform it by using program transformation techniques and further analyses [35]. The final program evolves from the specification to better performance characteristics, while still preserving semantics. On the contrary, the first and second stages have been traditionally addressed by philosophy of science. Only recently these stages have been taken into consideration and they are included in the software construction paradigm under the banner of “requirement engineering”. However, it is not usually recognised in the literature that the techniques should be mainly inductive. The information transmitted from the user to the developer is incomplete and inexact. The developer must complete and explain it by inductive methods. This inference process has recently given name to a different approach to software engineering: inductive programming [33]. According to Partridge: “The science of creating software is based on deductive methods. But induction, deduction’s ignored sibling, could have a profound effect on the future development of computer science theory and practice”. In our opinion, this effect will come true if both inferences can be effectively combined. Finally, our concern is not to present software engineering as an experimental science but to show that each program can be seen as a scientific theory and that each software problem can be seen as a learning problem. We will work under this analogy for the rest of the paper, mostly investigating the implications from theory formation and revision to program generation and modification. From theory formation we will translate the debate between descriptive and explanatory approaches to theory construction in science (see [39] for some contrasted positions in this debate). From theory revision (and abduction) we will try to identify which kind of software modifications are preferable: minimal extensional modifications or deeper coherent ones.

3

A Revision of Software Quality Factors

As we stated above, the role of the specification as a tentative hypothesis forces a revision of many software quality factors. The factors that are more directly related to the compliance with the specification are functionality, completeness, correctness, reliability and robustness. Other factors which are indirectly related such as testability, traceability, adaptability, flexibility, reusability, generality, maintainability /modifiability, practical modularity/granularity, ideal modularity or module independence, coupling, cohesion, efficiency/performance, comprehensibility and intelligibility will be discussed later1. The main factors are classically defined in terms of “the specification” or “requirements” ([26], [27]): Functionality: the degree to which a system “satisfies stated or implied • needs”.

1

For the factors that are not explicitly defined here, we refer to [26] and [27].

154

José Hernández-Orallo and Mª José Ramírez-Quintana

•

Completeness: usually assumed in functionality, it is the degree to which a system or component implements all required capabilities. Correctness: is the fundamental part of functionality (jointly with • completeness): the degree to which software, documentation, or other items meet specified requirements (classical view) or meet user needs and expectations, whether specified or not (modern view). Reliability: “the ability of a component to perform its required functions • under stated conditions for a specified period of time”. Robustness: “the degree to which a system or component can function • correctly in the presence of invalid inputs or stressful environmental conditions”. Most of them deal with “stated or implied needs”, “required capabilities”, “specified requirements”, “expectations, whether specified or not” and “required functions”. However, the question arises of what software feature measures the correctness of this specification or specified requirement wrt. the “stated or implied needs”. In our opinion, a new factor is required to measure the goodness of the requirement elicitation stage and the whole process of specification (hypothesis) revision during the overall life-cycle: Definition 3.1. Software Predictiveness Predictiveness is the degree to which the software system predicts present and future requirements in the context where the requirements are originated. The key issue is that the behaviour of a program is seen as a prediction given from the hypothetical specification. The analogy from incremental learning is now as follows: software construction is an incremental process. The new goal is not necessarily to achieve the highest accuracy at the end of a first prototype or version (or even with the ‘last’ version), but to maximise the cumulative benefits (prediction hits) obtained throughout the entire life of the software. Consequently, some concepts must be redefined. If we regard functionality equivalent to predictive accuracy, we must reconsider the components of functionality. Functionality or predictiveness includes: • correctness (prediction for normal situations), • robustness (prediction for environment or abnormal situations), • reliability (minimisation of anomalies), and • completeness (minimisation of novelties). Since a modification is required when there is a lack of functionality, modifiability (which includes extensibility) should cover both prediction errors (anomalies) and failure to predict (novelties). The former are motivated by a lack of correctness or reliability and the latter by a failure of robustness or completeness. Finally, maintainability is redefined as considering both the predictiveness and modifiability factors. That is to say, it weights the frequency and scope of modifications. For instance, a software system can be non predictive at all and highly modifiable, resulting in a maintainable software. Conversely, a software system can be not modifiable at all but, if it has been predictive for changing requirements, then the resulting cost of maintenance could still be low.

Software as Learning: Quality Factors and Life-Cycle Revised

155

Next we deal with how the learning/science analogy for software helps to redefined many of these and other quality factors in a more detailed way. 3.1 Functionality and Validation In the reorganisation made after the introduction of predictiveness, one may still question why we have included reliability inside functionality. The reason that has been argued is that, since the requirements are never definite, reliability depends more on the accuracy of the requirements elicitation than on the rest of the design and implementation phases. However, the relationship between these later phases and reliability is, at first glance, not related to the predictiveness factor. We will see that this is not the case, and even the later phases of the software life-cycle can be better understood using the analogy with a learning session. For example, it is widely accepted that redundancy compromises reliability because inconsistencies can easily arise, and checking them is sparse and consequently more difficult. An initial reflection would suggest that the removal of redundancies is the key to reliability. In [42], Gerard Wolff establishes the correlation between software and information compression in a direct way, arguing that “the process of designing well structured software may be seen as a process of information compression”. Although the parallel between automated programming and pattern recognition was recognised by Banerji in the eighties [4], Wolff reminds us that patterns such as iteration, function, procedure or sub-routine, and the idea of recursion are all forms of information compression. The same applies to objectoriented abstraction through the use of inheritance. The paradox arises when conditional statements (if.. then.. else and cases) are well justified by this approach. However, it has been recognised that the number of “cases” or “exceptions” in software increases the possibility of errors (and makes modifiability difficult). Moreover, there is a maintainability measure, known as cyclomatic complexity [25], which measures exactly this, the number of conditions in the source. In this way, an intensional model (with few exceptions) seems much easier to check. In particular, apart from reusability, object-oriented methodologies (and especially the polymorphism technique) improve reliability because they generally eliminate long cases and exceptions with a considerable increase in code length. As the software becomes more complex and requirements evolve during software validation, validation is finally applied to a whole which can be influenced by requirements elicitation errors, design errors or implementation errors. However, the idea of intensional and coherent models and structures applies to all the stages and must be preserved from specification to final code. 3.2 Reusability The coherence and simplicity criteria are have long been known to improve reusability (keep in mind the claims keep methods coherent and keep methods small [37]). However, intensionality is more important for reusability than simplicity. For instance, we can make a very simple program work for a given specification or data,

156

José Hernández-Orallo and Mª José Ramírez-Quintana

but if we have no foresight, the software will be not useful to slight changes in the specification. In this case, the problem resides in selecting the ‘easy’ or ‘extensional’ solutions, the most specific ones instead of the most general ones. This avoidance of application specific procedures, methods, modules, etc, is directed by the following classical guidelines [37]: provide uniform coverage: if input conditions can occur in various • combinations, write methods for all combinations, not just the ones that you currently need. broaden the method as much as possible: try to generalise argument types, • preconditions and constraints, assumptions about how the method works, and the context in which the method operates. Take meaningful actions on empty values, extreme values, and out-of-bound values (anomalies). Often a method can be made more general with a slight increase in code. In addition, reusability is based on again taking advantage of the effort made in previous software components. Although there are some approaches where the reused parts can be modified (adapted) from project to project [12], the ideal option is to reuse it exactly as it was, benefiting from all the acquired validation, something that is guaranteed by encapsulation, restricting that the module could be modified at the moment of reusability. 3.3 Modifiability Whatever the software system is, predictiveness cannot be complete and, unavoidably, prediction errors will sometimes occur. In that case a question we must ask ourselves is whether making predictive software, i.e., reducing modification frequency, entails an increase in the cost of modification, thus eventually compromising overall maintenance. To answer this, we would need to know what kind of software is most maintainable in the following way: • it predicts specification changes in order to reduce the number of future changes to software. • once a failure in prediction occurs, the modification can be made smoothly. The question is how are these two properties compatible and to what extent. It is well known that redundancy also compromises modifiability, but, at the same time, every software developer knows that excessive compression (cryptic models, code or documentation) also hinders modifiability. Wolff’s new concept of software [42] is based on compression, based on the fact that short software is more manageable and that the reduction of redundancy eases modifiability and extensibility. In the end, despite its predictive shortcomings, the MDL principle (as a preference for compressed models) is not valid for software development because it has been experimentally proved that extremely compressed models are not appropriate for reusability, as for other software quality factors, such as comprehensibility, testability and modifiability itself. Is there then any good compromise between compression and avoidance of redundancy? The answer is again to realise that avoidance of redundancy can be achieved without excessive compression. In other words, there are an infinite number

Software as Learning: Quality Factors and Life-Cycle Revised

157

of irreduceable models (without redundancy), such as intensional models, which are not the most compressed models. The explanatory paradigm of ML and philosophy of science is the most appropriate one to ensure functionality, reusability, modifiability and maintenance. Some other factors such as traceability, modularity, cohesion, comprehensibility and intelligibility can also be partially redefined under the paradigm of machine learning or philosophy of science (especially the explanatory view). For instance, performance can be seen in terms of lazy vs. eager learning methods [29]. Eager learning works with a model, whereas lazy learning predicts each new instance by comparing it with old cases. In the case of software, eager learning obviously requires more effort at development time and revision is more complicated, but performance and reusability are not compromised. Nevertheless, from the ML experimental and theoretical results on the complexity of lazy methods, a medium or large size predictive system must necessarily be based on eager learning methods, and, in the following, we will take for granted that this is the case.

4

Predictive Software Life-Cycle

In section 2, the five main common stages between science and software were presented just as they are, without explicit influence between them. The analogy is now exploited to re-design the software life-cycle with the goal of making it predictive, and introducing model revision as one of the most important (and reiterative) stages. 4.1 A New Life Cycle Figure 2 represents a mixture between an automated software construction cycle and scientific theory evolution. The terminology is used indistinctly, by either borrowing a term from philosophy of science (or ML) or by using a term from software engineering. The process begins by gathering the data and partial requirements of the problem and inducing a first model from these examples usually with the help of background knowledge which consists of reusable software components of previous projects and some other information about the domain of the reality from which the problem originates. The next stages are quite similar to the classical or automated life-cycles, depending on the degree of formalisation of the model and the automation of the transformation stage. The first result of the process is a program which can be contrasted / validated with more use examples or with real operation. This comparison may trigger a partial or whole revision of the model, which is followed by a rederivation of the program. Obviously, this cycle could be more detailed depending on the automated or nonautomated character of each stage. For instance, in a non-automated developing schema, an analysis stage could be introduced between an induced partial

158

José Hernández-Orallo and Mª José Ramírez-Quintana

specification and the model, without using previous software. The design would convert this initial model into a refined model by using the repositories. Data + Partial Requirements Requirements Changes

SW Repositories + Domain Ontology

Generation and Selection Reuse

Contrastation

Revision

Intensional Model Transformation

Program Application

Behaviour

Fig. 2. Predictive Software Life-Cycle

4.2 Towards the Automation of the Predictive Life-Cycle As the analogy suggests, at present, the goal would be to (partially) automate the process by using techniques from ML. However, automated inductive methods are not yet ready for most of the complex software problems we face. Nonetheless, specifications are getting increasingly more complex and more data-based, and ML techniques are becoming more powerful to justify the inductive software paradigm practically and economically. Partridge [33] presents some successful cases of automated construction of software from sample data. There are two generic approaches for research towards this difficult goal: 1) to evolve simple, fully-automated software systems into more complex systems; and 2) to develop semi-automated systems. Both approaches highlight a revival of declarative paradigms, because declarative languages are more mature for automating the stages of the previous life-cycle, and more intelligible. For the first via, logic programming is clearly the most appropriate paradigm at present. Inductive Logic Programming (ILP) [32] represents the automation of the stage of generation and selection from examples and background knowledge. The automation of the transformation stage is ensured by many years of research in transformation techniques (see e.g. [35]). The automation of the revision of the model can be found in works usually originated in non-monotonic approaches inside AI, by using logical theories [9] or more software specific approaches [1]. Finally, the application stage is performed directly through SLD-resolution or after a specialisation stage (see e.g. [2]) for improving performance.

Software as Learning: Quality Factors and Life-Cycle Revised

159

The problems of scalability appear at all the stages, but more critically in the first stage. From the first recovery of specifications by using ILP [10], and after the application for inducing simple algorithms shown in part III of [7], the prospect of ILP for program synthesis has sometimes been discredited and biased. Nowadays, ILP is addressing more complex problems, so the predictive declarative programming paradigm can address medium-complexity problems, such as web-agents, controllers in changing environments, software assistants, and the like. Nonetheless, we must recognise the main problems of ILP for software engineering: background knowledge usage bottleneck and knowledge mobilisation [18]. For the second via, the most important issue is the intelligibility of software, i.e., if some part of the model (or the code) is automatically generated from the user’s requirements, it must be intelligible to humans, in order to ensure good coordination with manually generated software and allowing for manual maintenance and revisions. In this case, the use of declarative languages is even more justified.

5.

Conclusions and Future Work

This paper has focused on the view of programs as scientific theories or, more precisely, software development as learning. This analogy forces a reconsideration of the quality factors of software and the software construction life-cycle. New software characteristics are distinguished, mainly that software must be predictive, in order to minimise future modifications, and other software factors are redefined. Induction will be more important than deduction in the future, when automation is possible for complex systems. Software systems must receive feedback from the user about the quality of its task: adequacy to user’s needs, efficiency, robustness, etc., and they must update to the user’s demands dynamically. In other words, software systems must learn from the environment and user’s needs, in an interactive way quite similar to query or interactive learning [3]. The recent aim for automation of induction has driven us to highlight and encourage the productive translations of ML techniques to software engineering. Although full automation is not possible at the moment, the analogy, the revision of factors and the new life-cycle are useful for traditionally developed software. This is the keypoint of the paper, to highlight that a change in attitude (or paradigm) in software construction can be useful in practice even without any automation at all. In a broader context, many historical traits of the short life of software engineering (in contrast to the long life of philosophy of science) can also be better understood. For instance, many techniques and paradigms of software engineering in the last decades can be seen as tools and mechanisms to ease compression while preserving intensionality (avoidance of exceptions), such as structured programming, objectoriented programming, encapsulation, polymorphism, etc. Moreover, the emphasis placed on the inductive phase of modelling to make software more predictive matches the increasing relevance that requirement elicitation has been acquiring in software engineering theory and practices in the last decade.

160

José Hernández-Orallo and Mª José Ramírez-Quintana

At present, the authors are developing inductive algorithms and systems for other more powerful declarative languages, for which transformation and specialisation techniques are also developed [35], [2]. In particular, the induction of functional logic programs has been attempted [20][21] in order to allow the acceptance of more expressive and complex requirement cases as examples, which is usual in software applications. The system FLIP [16] is specially designed to induce recursive programs and it also supports the use of background knowledge, with the long-term goal of automating [22] more and more parts of the whole process. As future work, from a much more practical point of view, software is a very appropriate place to experiment new techniques from AI and ML (see e.g. [40]). Moreover, AI and ML can expand their commercial applications in this area. Many ML paradigms and techniques [31] can be used in different processes and stages of software construction: evaluation criteria like cross-validation, query learning [3], reinforcement learning applied to constructive languages [23], explanation-based learning, [14], data mining for knowledge-based software, analogical reasoning, casebased reasoning, genetic computation, etc. In summary, our analogy also shows that until machine intelligence (and ML) approaches human ability more closely, fully automated programming will remain a fallacy. In the meantime, in accordance with the analogy presented here and in an effort to reach the Utopia of “intelligent software” [30], a more prosperous methodology for software construction could be devised from the nascent “predictive software”.

Acknowledgements First of all, the authors would like to thank Jesús Alcolea for the introduction to Fetzer’s work. Other people have helped to develop these ideas: Jaume Agustí, Vicent Pelechano and Enrique Hernández. Finally, this work also benefited from a short discussion held with John Lloyd, Steve Muggleton and Luc de Raedt about the possibilities of the use of ILP for software practice at the the “JICSLP'98 CompulogNet Area Meeting on Computational Logic and Machine Learning” [20].

References 1. Alferes, J.J.; Leite, J.A.; Pereira, L.M.; Przymusinska, H.: Przymusinski, T.C. “Dynamic Logic Programming”, in Freire et al. (eds) Proc. Joint Conf. of Declarative Prog., pp. 393408, 1998. 2. Alpuente, M.; Falaschi, M.; Vidal, G. “Partial Evaluation of Functional Logic Programs” ACM Trans. on Programming Languages and Systems, 20(4):768-844, 1998. 3. Angluin, D. “Queries and concept learning” Machine Learning 2, No. 4, 319-342, 1988. 4. Banerji, R.B. “Some insights into automatic prog. using a pattern recognition viewpoint” in Biermann et al. (eds.): Automatic program construction techniques, Macmillan, 1984. 5. Barron, A.; Rissanen, J.; Yu, B. “The Minimum Description Length Principle in Coding and Modeling” IEEE Transactions on Information Theory, Vol. 44, No. 6, 2743-2760, 1998.

Software as Learning: Quality Factors and Life-Cycle Revised

161

6. Basili, V.R. “The Experimental Paradigm in Software Engineering” in Rombach et al. (eds.) Experimental Software Engineering Issues, LNCS no. 706, Springer-Verlag, 1993. 7. Bergadano, F.; Gunetti, D. Inductive Logic Programming, The MIT Press, 1996 8. Berry, D.M.; Lawrence, B. “Requirements Engineering” IEEE Software, 26-29, Mar. 1998. 9. Botilier, C.; Becher, V. “Abduction as belief revision” Art. Intelligence 77, 43-94, 1995. 10. Cohen, W. “Recovering Software Specifications with Inductive Logic Programming” in K. Ford, (ed.), Proc. of the AAAI Conference, pages 142-148, Seattle, WA, 1994. 11. Colburn, T.R. “Program Verification, Defeasible Reasoning, and Two Views of Computer Science” in Minds and Machines 1, 97-116, 1991. 12. Davis, M. J. “Adaptable, Reusable Code” Symp. on Sw Reusability, Seattle, apr. 1995, ACM. 13. De Millo, R.; Lipton, R.J, Perlis, A.J. “Social Processes and Proofs of Theorems and Programs” Communications of the ACM 22 (5), 271-280, 1979. 14. Dietterich, T.G.; Flann, N.S. “Explanation-Based Learning and Reinforcement Learning: A Unified View” Machine Learning, 28, 169-210, 1997. 15. Dijkstra, E.W. “Notes on Structured Programming” in O.Dahl et al. (eds.) Structured Programming, New York, Academic Press 1972. 16. Ferri, C.; Hernández-Orallo, J.; Ramírez-Quintana, M.J. “The FLIP System. From Theory to Implementation”, submitted to Machine Learning, Special Issue on ILP’99. 17. Fetzer, J.H. “Philosophical Aspects of Program Verification” Minds & Machines 1, 197216, 1991. 18. Flener, P. and Yilmaz, S. “Inductive synthesis of recursive logic programs: achievements and prospects”, The Journal of Logic Programming, 41, 141-195, 1999. 19. Hernández-Orallo, J.; García-Varea, I. “Explanatory and Creative Alternatives to the MDL Principle”, Foundations of Science, Kluwer, to appear. 20. Hernández-Orallo, J.; Ramirez-Quintana, M.J. “Induction of Functional Logic Programs”, Lloyd (ed.) JICSLP'98 CompulogNet Meeting on Computational Logic and ML, 49-55, 1998. 21. Hernández-Orallo, J.; Ramírez-Quintana, M.J. “A Strong Complete Schema for Inductive Functional Logic Programming”, in Flach, P.; Dzeroski, S. (eds.) Inductive Logic Programming’99 (ILP'99), in LNAI 1634, pp. 116-127, Springer-Verlag 1999. 22. Hernández-Orallo, J.; Ramírez-Quintana, M.J. “Predictive Software”, submitted to Automated Software Engineering Journal, Special Issue on Inductive Programming. 23. Hernández-Orallo, J. “Constructive Reinforcement Learning”, International Journal of Intelligent Systems, Wiley, to appear. 24. Hoare, C.A.R. “An Axiomatic Basis for Computer Programming” Communications of the ACM 12, 576-580, 583, 1969. 25. IEEE Std. 982.1-1988 “IEEE Standard Dictionary of Measures to Produce Reliable Software” The IEEE, June, 1988. 26. IEEE/ANSI Std. 610.12 “IEEE Standard Glossary of Software Engineering Terminology” The IEEE, February, 1991. 27. ISO/IEC 9126, “Information technology. Software Product Evaluation. Quality characteristics and guidelines for their use” Intl. Org. for Standardization and Intl. Electrotechnical Commission, 1991. 28. Lieberherr, K.J. Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns, PWS Publishing Company, Boston, 1996. 29. López de Mántaras, R.; Armengol, E. “Machine Learning from examples: Inductive and Lazy Methods” Data & Knowledge Engineering 25, 99-123, 1998. 30. Maes, P. “Intelligent Software” Scientific American 273 (3), September, 1995. 31. Mitchell, Tom M., Machine Learning, McGraw-Hill International Editions, 1997. 32. Muggleton, S.; De Raedt L. “Inductive Logic Programming — theory and methods” Journal of Logic Programming, 19-20:629-679, 1994.

162

José Hernández-Orallo and Mª José Ramírez-Quintana

33. Partridge, D. “The Case for Inductive Programming” IEEE Computer, pp. 36-41, Jan 1997. 34. Pettorossi, A.; Proietti, M., “Rules and Strategies for Transforming Functional and Logic Programs” ACM Computing Surveys, Vol. 28, no. 2, June 1996. 35. Pettorossi, A.; Proietti, M., “Developing Correct and Efficient Logic Programs by Transformation” Knowledge Engineering Review, Vol. 11, No. 4, December 1996. 36. Popper, K.R., Conjectures and Refutations: The Growth of Scientific Knowledge Basic Books, New York 1962, Harper, New York, 1965, 1968. 37. Rumbaugh, J.; Blaha, M.; Premerlani, W.; Eddy, F.; Lorensen, W., Object-Oriented Modeling and Design, Prentice Hall 1991. 38. Scherlis, W.L.; Scott, D.S. “First Steps Towards Inferential Programming” in R.E.A. Mason (ed.) Information Processing 83, pp- 199-212, 1983. 39. Shrager, J.; Langley, P., Computational Models of Scientific Discovery and Theory Formation, Morgan Kaufmman, 1990. 40. Srinivasan, K.; Fisher, D. “Machine Learning Approaches to Estimating Software Development Effort” IEEE Transactions on Software Engineering, Vol. 21, No. 2, Feb. 1995. 41. Thagard, P. “Explanatory coherence”, Behavioural & Brain Sciences, 12 (3), 435-502, 1989. 42. Wolff, J.G. “Towards a new concept of software”, Software Engineering J., IEE, Jan. 1994.

What Is ‘Mathematicalness’ in Software Engineering? — Towards Precision Software Engineering — i t

1

n

h

t

t t k [email protected]

t

Introduction h

in

hu n ivi i h i theoretical computer science n industrial software development n ? n h in vi in ; h i n hi n h i u i n n v n n h hy i i n n i n in in e.g. h ni n in in yn i n in in hi vi in h y u u y h n h uni h y in n in u i in i in vi in u h i n n underlying logics h i ni i.e. hy i i n n h i u i n h un y in i hy i i n i inductive in in i n hi in u iv n u hy i h i i in vi in h hy i i iv n u in n n u v n hi u u i h hy i n h n v hy i h i vi i n n h i i i n n i n u i

n h h h n u i u ni n i n u un i n hi h i n in deductive y u h deductive un y in i v nin i ui ni n h hi h n i u n in un h n v in h n h i n h n u h i hi h i n hi n h i n i n n h h i i n living h i hi h ordinary mathematics n y working h i i n in h n h i n 7 h i iy h i h n in h u v h i u u i in h i i n v h i ; i.e. h u v really mathematically h i h i ; u are they really mathematical? h y uy i h h i v n? u h u i n h h n hin i h i n y v y u iv n h v i h hi u i n T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 163–177, 2000. c Springer-Verlag Berlin Heidelberg 2000 

t k

n

iv y h vi in h i n v i.e. n h i cultural properties commonly kept by working mathematicians hi in ny in u h u h in h i i n u u h n u u y u i n y n i i h i i in h y hi nu y n h n h u ni i n h i n i n i y i vi

n

u

in i n

n in

h h h in hy in

v

ni i n h h i i n

h

h h n

i

n i

u

y

n h

n

ni h i n i h

n hi u i n i n yz ivi i in h i i n n i v v i u y in misconceptions hin hi h un un y v n h in i y in h in u i v n h u h u hi ny ni u u v n n in h n i n2 i i u h i n n h i h vi in in h i i n n i in h n h i i n hi h h n i n i n yz h i n n h i i n n h i u in h i n i n in i n i h h i i iy n n h i ; i.e. h n n n u u un in v n e.g. hi u n i n n etc. n u u un in h i u n h n n v n mathematical n in in hi h Precision Software Engineering n h i hi n n n n h i in y i in u inin h n y izin hi n n in u i y i i i in h u u n in in i uy h i n u i

2

Is ‘Logicalness’ ⇐⇒ ‘Mathematicalness’?

n hi i n n yz h i n in h vi i i n n h i i i n n v u u y h i n h h i n y h y y i etc. i in h i i h i i h i i n h u h n h i hi h i i h v i i i n hi i u

n i

n i n h

iy h i

i

u

h i n u iv

in h h u h h

in

h h

i y

i

u i n hi h i (mathematico-) logical h i

hin i h i i n ny i i i i n i y u n u ; i.e. h n i n n h

t

n in y

h h v h

h i

h

h i u h n h

i

iz

i n

h i h

in §

i h

h n in h h in h in y u in h u u u u h

t

i in

n h

in

i

y

y

i

i

i i n i i h i n i hi i i i n u h v n ivi y u i i n vi in h i u in h i i n vi in h ni i n u u y n yz h h i i i n uni y

ny

ii i in h i i h i i n e.g. n i u nn 2 h in h i i n i un n in u i i h i i i y ni i h i i

iv n y ii i n

u i n

hin h h ii i u ni i n n n h y u y n y zin hy in h i i n i y u hh iiy in h i i u h ii i h h in in h i i n n h i i the logic for ordinary mathematics; 2 h i n yz h h i i vi in i irrelevant in y h i hi h in h i i n v n v u y

v

h

hy in i.e. i

h

u h n un un i i n u ? hi i reductionistic n u

u

n u

∀x. x−1 · x ∀x. e · x ∀x, y, z. x · y · z

h ni

v y hi

ii h

h h h n n n un i n y i nn in in y

n i

i i i

in n h

i

i i n n h i h in

i ;

e, x, x · y · z.

u n v y i

u u

h i h n u ni

in

h

i i n

n

vi

in h v h u i n i ih n n i un y h h in y h v n y ny ni n h i i

u n i

n n

y h

n

i h

u

i hi h u u u h i i u h i u u u in y n u hni u n u h u u in i n i i iv in n u hi y y i in h i pragmatic i ni n in h i i n hi i u h in u h i i i n yz i u not h i u u h i u n ny

n h h h n u v y u u n i u h u u in i n

in h i i n ni n n h in v in in y h

h i hni u i h i

u n iy

t k

cf. e.g. u u i

n u n y u

in

E.g. in v in

n h

n h h i i i h i n n in meaningless y n n yz u h yn i in ii h i n i n u h reductionistic u h vi in in ui i n n h i h y in n n v y h i h y i u i h n h iv n u h h y Platonic world i y

h

i

h

i

h

u

i

y

h y u h in y n h n in i n y i n u h i i n semantics in v y v u h i i n y i n u y yn n h in h i i n

ii i h i i i y in h i i n n u iz i hi “mathematical logic neither helps our imagination in the ivin mathematical world nor gives any hints for proving theorems about our mathematical world; the logical structure shown by mathematical logic has hardly any relation to our i of living ordinary mathematics.” v i in h i

i n

h

i h

n i

i i n i

i

y

h i u

iy h

i

i.e. y

h

h n h i h y iv

in i n

n mathematical logicians themselves are actually working mathematicians! h y in h i i n in i n h in y h i u h i n ni i n n h i i i n n in y in h i i n h i vi in n in y h i ui i n h i i i n v in y h i h v in h n h i vi i syntactically hi in h i i n iv in h hi in y h i i.e. in y h i i h v h ; h n h y vi i semantically Software formalists h n y hi n i h n n in n in n h n i y h h i vi h v hi vi in i ui i i n n in y h i u i never h i n h i i n n n i i

h

n u

h in

v i i n h i y yn i y u h v n h i i i n h i i n n n

h v i n n h i u i n h h h h i h h i u in v y i y n yn u i h i i n yz in y h i in h i i n n h h h n hin ni y n h i iy in n u n u in v y i u nn ih ini u yn i.e. h i u n y h n u in u h i i n h i h i i h n in u h i in n u n u

t

t

ny

yn h n h n ni y v n in i n h n in ih i v h h h h n i h u ivi y i h h y hin u h i n h h i i n in u h hi h y

3

h

n n y i u yn i h u h yn i ni u i n u h ni i in i n n h n i n i i n u ivi y i un i v y hi h n in n y h i hi h in ni y h h n yn i y n i n i v h h u ivi y

Are Formal Proofs Imperative?

h h h n in §2 ; i.e. h n i n h i i n h i i h in h u h h n u h n iv in y ny

i h u i n i i n h in h n

y nv iy h h n ih y u y u h v h h h i h u h i ii n in h v hi i ii y v i i n i ih n h n

h

h u h

i

u

h

u in u iv i n n n

n in u in in y h h in in §2

i u i v ni n y h i i i n i i n y unnin n u n y v i i n i n y n in ? u h u ivi y ?

i in h i i n u ivi y n i ih u ivi y n in i v y i u i h un semantical contents in h i n i i u h n un i h h un i h v i i h un syntactical objects n in u h ni n n n i in u h y n i un h n i iv in i h X  n ≤ i nX n ≡ n  uiv n i n in u y h i iv y u xy⇒x≤y x, y ∈ X h n i i ivi h x≡y⇒xy x, y ∈ X u i n v hi ivi h y in y nz n n h n i n n n u iv in h v y y n

n h u hy i h un h n n in h i y y i h n in in h n v n u i in hi n 2 h i ih in n hi i i n y v y hni n n in ny n in

i u i y in i nu in hi h n vi nn in h n in i i n n n in h i hi h n y i n n

t k

in

h u i h un n n u h h i h in i u v n i h i i n u ny n y hi u ivi y u h h i n n n nh hi u u i in u ivi y i h n in i h hi i n y un i u i i n un i u h formal mathematician h h i y y h u in v n h hi i i n i in h i h i y u v hi nn v h i h y u i u u h i i n h n u h h i i nh h v hi u ivi y hi h h v v u in h h u i y n inin uiv n h i n n h v non-formal but rigorous h i i n n h u h ivi i u h h i i n h h n in n h y n i programmers in mathematics h h h v i n un i h ni n in h i software engineers have been handicapped already compared with mathematicians n in h n i i h h i n u u y u n in n hin y h u n u h i u ivi y h n i ni n y u y in u n h h i i h h i i n h y u h n i h h u ivi y nh ui u h h i i n un un i i n u h un iy i y u h i y in i.e. yn i ni u i n in ni i in i n u h i i.e. ni n n h i i n u y h h in y h i i n n un n u h h i i n h n i h u in h in h i h ny hi h n y v y in n in n h i i n in h i u i in y hi h u iv iy in y u h y n v h i h y h y v in un n u h u y n u i.e. fl h y trivial in n u h h i i n n n n h i i in in u h ivi y y h n n h v n i u h u y ivi n in vin y u ivi y n in h ih ni hin in h v yn i hin in ; i.e. in h h i i n u i in u ivi y i hu h y i i u n u in i in n vin h i i i i n h n h i u iv ni i in i n u h i h no mathematical logicians, theoretical computer scientists, nor software formalists have ever written a paper in which their theorems are proved formally h i ny h n y h i iy h i y in h n §2 u y

t

t

n in u v h n h i y h n h y i u y h n i h y u n ny u y u u ih u h u y y h n n in n in vin i u y h v h i i n n in vin h h i i n n n in i i ni u ih n i ii y n n i hin iv n u n in ivi i u h i nin n vin i n h i iy ; h ivi i u n in h u h i n vin h in h i i n in h u i y n vin u h h i It is quite unfair to request that only software engineers must prove the correctness of their products formally. h u h i i u h h in n in u i i.e. u u h i u in h v y n h i iy n i ny y u n h u iy h i u n in n i n h i n u n u iy u n h in i ii y n n n in h i i n in in i h i n h i i h n n i h i i n in h in hin h i i h n the statement of the theorem itself is true in most cases v n i h i in h y n in i u fl h n i i n in i n v i y in h n h v n h n n in h n i v y i n u hi vin u y n i u i h i in i i v i i n h h i y u n the correctness of correctness proofs n h n in u h n ni n v hi hi u i n in in i i y hi h n i n v i i n in h n h in 7 iv hin n hi h n nn n i u y u n v y v i i n vi y i n n i in v n in hi h n i ui i i h in h y i i n in in in h i i n n h n i n n h h v i i n in h n h in i ii ui h iy ivi i in h i i n hi h h n u u y i v u ivi y i h i v i h h in nv n i n i h u ny n v n v n h u h n v in hi h cf. i n 7 h n h v i i ni i i h in ivi u u n nn i n h n i n in h ii hi h i.e. u in h n u n v h n i h n h h i v n y in macro structures in n h i

t k

4

The Software-Mathematics Structural Correspondence

n hi h

i n n yz h u u n n n i y u in h i u u n u iv in i n h y i y iv h i i i n i n in v i n in ui i ni i i.e. n u iv i y hi h in ui i ni i y h y in h u u i i.e. v u i hi hi n h in ui n u y n n n in n i ; cf. ¨ u n in y 7 Table 1.

h

ui n

u y

Programming t

n n Logic t

h h n u iv in hi i microscopic n reductionistic vi in h ny n h h i h u y h i n n v n i n h n in n n y h ni y h n h y uiv n in h iv h in h n h i h i n n u h i n n n i in h y h i n i n i n h in ui iv y n n u ni i n u in ni n i n u y vi ny u u n v h in h in v y u iu n u y u i hi h in in v hi h i h i n n in in i h v u i u in n u u n i in un n n in i i n n n in in i in n n h n u iv in hh n h h i u y i u in § h u i h hi h i ui i u i in u i v n h v hin h hi n u iv in h h i n in ; i.e. hi h iv hin ni n n y n in n h i i n h n u iv in h hi n y i ui u y h programming-in-smalls v hi n y in n n i h programming-in-larges v h n n n n n n u u un in v n n h u in h i ivi i v i u v nu i y hi n n i h n in 2 n n y z hi Software-Mathematics Structural Correspondence u y h h u n y i i h n n h n in

t

Table 2.

h

u u

t

n n

n

Software Development t

t

n

h

Mathematical Activity

t

t

t

(Repetitive Loop, Conditional, ... etc.)

(Mathematical Induction, Case Analysis, ... etc.)

(Useful Combination of Control Structures )

(Conventional Technique for Fragmental Proof)

t

t

t

t

(Collection of Operations on Common Data)

t

t

(Collection of Lemmata on a Mathematical Notion)

tt

t

(Specific Combination of (Possible) Classes and Specific use of their Interdependencies)

t t

(Specific Combination of Subgoals (Lemmata) and Specific use of their Interdependencies)

tt

t t

(Specific Combination of Specification of Components)

t

i

(Collection of Basic Definitions and the Main Theorem)

t

t

t

(Structure formed by Definitions, Theorems & Proofs)

t

t

(Basic Framework for Mathematical Thinking with Common Vocabulary)

• Basic Constrol Structure vs. Elementary Proof Step h v h n n n basic control structure n elementary proof step i ni y in h n h n u in h E.g. u ni ii n n h u in i n ii n n h i un i n i in i n in i in in ii n n n in u i n n un • Idiom vs. Proof Technique n idiom in in i u u v n ni i n y in h e.g. h in ni y nu h y i i h i in u i n

i n

n u u

n i u h n i in i n

n iv u n in

in i n i n n n y i n in i n ni proof technique; nu in n reductio ad absurdum n

• Abstract Data Type vs. Theory on a Mathematical Notion n abstract data type class in h i n i i i n i n in n n n u h v n in i i n n i n n ii n n i i n n y n u u y ini u theory on a specific mathematical notion n n i n i n n y i in n n ih u h h y y i u h h y n h i n i ni u h y h u hi i n ini u hi n n i n n n i i h i h y hi n h • Design Pattern vs. Proof Tactics design pattern i i in i n i inh i n i n n h h

n n

v

i

n n n

t k

h

i h i n i n n h i proof tactics i i n nv n i n n n u h h h u in v h i h n h u n n i n h n ny in h i h i h ini u h y n n u ii y h i n i n hi h i u v h n u v ii n n i n n n i in h i • Software System vs. Mathematical Theory n i in h i n hi n hi u n n h y i n yz h n i i.e. y n h i h i in h h i i n n in n in h i;h n h i u i n n h n i i in ui iv h n h n h n software system i v in i i i n h in ihi nvi n n n i i n i n v i u n n in in n n h ; h n n h i n i i n n in h n n h i h i y mathematical theory n h n n h i ni i n ni i n n h h main theorems hi h h h i i n n h i u in h in h ny u i i y ni i n n h i n y u h ni i n h h i i h i h y hi u n n n ivi in in y • h

un i n i i n h in h h y in • h i i n n n n hi h i u v in h ; • h i n i n hi n n • n n hi h i vi library n h y n n i n n i u • ni i n h i n i n h n ni i n un i n i i n h y • ni i n u ii y n i n u in n n ih ni i n n n n n

e.g. ca. hi in n n

h n h h ivi

y h i h

n n un i n ; n

n h i u i n ih u i in h y ; i

h i n h n in The Lambda Calculus h > × in ×2 u h i h in h y n in ny in in in

h h ;

; n n

n u

iv

in h

n y

ui h

hi v

n n in v y hi h i

in i ; u h ; in v u 2 n u h

t

t

• Architectural Pattern vs. Theory Strategy n architectural pattern i i n i n i i n n n in n h n n n n in ih n n nvi n n h y hi h i ui i h hi hi u n h n n i iv n partial i i n; i.e. hi i i ni h i nn uni u y n h n un i n h n n n hi u n h i n u in y ni h h i i strategy for developing a mathematical theory i h iz i in in i ni i n i n h i.e. h n in h n n v i n u ii y in λ uu i in y i i n h h hu h h i.e. h n u n u i n h n h v v h i n h i h i vi h in y n i n n h i u u i n h h iv y v in h u i n h y u h u u n hi h h n n h hu h h n n h u i n y ; h n h hu h h i h n iy similar n u i hi h h in y n n h n i n u i ni iy i i n n h i i n i n iv y h v n in hi h y y i ui ny n h i h i ; in hi h y i.e. vi h in y n vi u i n i n u n i in h y v i u i in y h v h n h n n n y n h i h i n n u h hi u n n h y i n h h • Domain vs. Mathematical Field domain h i n i v u y i n h in u h v u y i i n i nin n i i n i u i i y mathematical field n i n n v u y h i hin in i i n i y in h i i n h i hin ih h u iy hi n y u h in u i y ≤ hi n h i i n i n in u i i n h in n y i n n y i i un n i n h n y i ≤ x y x≤y n y ≤x y in i i i u n h n h h h λ uu i h n n n y i n h i u h h u inv i u h uu n u i.e. nv i n i n u i n i n u i n h i n h h i v u y in λ u u n iv h i hin in in v in i i v i u ui Differences between Software Engineers and Working Mathematicians h v n h u u n n in n in in n u u in h i There is, however, an essential dif-

t k

ference between software engineering and mathematics in handling such macro structures. h i i n v y i u in u in h i h i u u h y v y u y n yz i i i n u h u u e.g. un h n ii n n u h ii n n ii n n h i n u i n v i y etc. n in h i u u u h hi u n u h nn n i n n in v y in ui iv n ii nn h y h v un u h u u u u h v n v n yz h i i u i i n

i

n

n

i u u y n n h v n n yz n y inv i n i n y n ii n n ii n h in n h n hi u ihh n n n in h n i u y u n y hh n n u un i h n n v h ii n n ii n n y n n hi hi u h h u u n in ui in i y u h v y i h y u u

ih

v u

h n

i

u hh i

h

hi h i n e.g. h n; h u y u h u n n ii n

n

h i

h h u n i i i n n h i h h n ii n v h hi u n h n ih u n u ih nn y u v h n h u

h

h i in

h v n i i n u h u Most of them, however, are at the level of description h y n h n y i h i i u n y i n u u in u h i u i ni n i n h n i in u u y u i n h i i i u y u y u h u u in n u in y i h hi h i i i y n u v i n i n y n h i u h i u i

u v

5

Towards Precision Software Engineering h v i u h h y i i h u i n ih h i

i n n

n i

u u u h

n in u h

in uy hi u

h n

i

n in in u n ny i h u u in hi u i i n n u u v u ini u h y mini-theory h h u u hi h h h in n i y n n h u h ini h y u iy i u i h u u e.g. inv i n h u u i n hi n inv i n n n h h u u i v y h u u n ii n i

h ih

n

y i

t

n ii n i n y hi n ad hoc in h n h y y in h n ini h i n u in vin h u u h n n ui in i n i iu i n i y h i i n ii y u in n i v ad hoc u i h h i n n h y n iv y u v in h i n h i i n y n h i u h h i h i n

u

t

v i n u h i n u h i i u u u ini h y h i h i n hi u u h n y ui u ih in n safely u u h u u in u y vin i n efficiently hi h i u i n in h i i.e. in un u u h i u u u h ; h n u h u u h i i n u h u h y n y etc.; u h h i n h i u u in h i y vin h i n h in u u h i products; n y

u h n uy h i Precision Software Engineering hi h i n empirically useful ni h i n h i ad hoc h h i i n y n i h i u h n ui n u n y vi y h n h hi h h i ii n n in h

i i in n in in i i in u ni ad hoc ini u u u i h i u u i u in etc. hi h vi in h u h i ny v i i n in i h i u i n in u in i ui u u h ini in

i n i n n ii n n in in h i h i n in vi in n n h h n hi h h y h i y describe ih n u n iz i n n i h i n v h n y n h h h n ii n n in in i u y analyze u u n u h i n logically ad hoc u logically consistent u practically useful ini h i n u u h u u n h i n h i hi h n in in iv in n n in in n h i u i n h i h vi generic h i n h n u u i n hi h v ad hoc ini h i n u u n h i h u h ini h i un n n i h i

n i

n n i

i

Precision Software Engineering is not already-established discipline u h v in in hi h h h ii ii n n in in h i ni n n y i n i h n h hi h u h ni ii h i n i i n cf. in 7 n y i n y n i i h n n h i n in in n y h h n ii n n h n ii n u n n h n h vi n u h u n hi h v h i n i cf. y 7

t k

n h v y ii u n ui in in n u u i in n in h y 7 n h n i v h i nv i u i i n in y i in h i i n in y i i n n u n iz h v u y h in h n n y zin i h in v y i u y in y n n y inin i i inv i n h i i n in n ny u u in h n n in n h in in i u u h n u u i n 7 hi h h iz i h n i in y n i u u in v n; n h n i n h in u n in i y i 7 n h i i n h i vin h in in n ni i n i y u u i n in n u i i ni in hni u e.g. y h v u h un i n n i n i i i n v i u i n n i n n h n u n yz i u y h n in n in n iv y ih in v y i u n nn h h v n ny in h i n h y h h n n n in n h i h h v h in v ; i.e. i hin h in in n u y h h i i vi in in in h i i n n h n v y u i i u h y u i n in v n h i n h i h h i n n h n in 2 hi h h v un in y i h ii n n in in y Abstract Software Engineering u in h n abstract n h in i i ii n n in in i ih abstract (mini-)theories ii y u u u u in n n h h u u n y i n in v etc. hi i ui n u h n u i in y un y i v y n ; i.e. u i u i n u i n i u i n h n h h i i n n u i h n i n u n ih n u h y h n h y in i in y v y n h i i.e. v i u nu y i Z Q n C i hi h n y in u n i v n i h i u u i n n hi u n n h h n h n in in h n ii n n in in n n in in i i in ih in n in n i n y v hi h y i n h n software engineering can become a truly n engineering field like other conventional ones, e.g. aircraft engineering.

t

t

Acknowledgements t t

t

t

tt t

t

k

t

t t

t t

k t t t

t t

t t

t t t t t ø

t t t t

t t

t

t

t

t t t k

k t

t t

t t

t t

k t

t t

t

t t t k t

t

t t

t

t

k t t k

t t

t t

k

k t t k

k

k

t t t

t k

t t kt t t

t

t

t

fl t t

k

tt

k

t

t

t

t t

k t

t

t t

t t

t

t

k

References t

t

ø t ø t ø

t

k t

t t

t

t t t t t k

t t

k t

t ¨

t

¨

t t

t

A Formal Approach to Heterogeneous Software Modeling Alexander Egyed and Nenad Medvidovic University of Southern California Computer Science Department Los Angeles, CA 90089-0781, USA {aegyed,neno}@sunset.usc.edu

Abstract. The problem of consistently engineering large, complex software systems of today is often addressed by introducing new, “improved” models. Examples of such models are architectural, design, structural, behavioral, and so forth. Each software model is intended to highlight a particular view of a desired system. A combination of multiple models is needed to represent and understand the entire system. Ensuring that the various models used in development are consistent relative to each other thus becomes a critical concern. This paper presents an approach that integrates and ensures the consistency across an architectural and a number of design models. The goal of this work is to combine the respective strengths of a powerful, specialized (architecture-based) modeling approach with a widely used, general (design-based) approach. We have formally addressed the various details of our approach, which has allowed us to construct a large set of supporting tools to automate the related development activities. We use an example application throughout the paper to illustrate the concepts.

1 Introduction The software community places great hopes on software modeling notations and techniques to ease a variety of development challenges. The intellectual toolset available to software developers has been steadily enriched with more powerful and more comprehensive models. At the same time, the growing number of heterogeneous models has resulted in an observable split within this community: one part of the community is working on and with special-purpose development models; another part focuses on general-purpose models. Special-purpose models tend to focus on individual software development issues and are typically accompanied by powerful analytical evaluation tools. General-purpose models, on the other hand, address a wider range of issues that arise during development, typically resulting in a family of models that span and relate those issues. This split has impacted the two communities’ visions of how software development challenges are best addressed. A special-purpose approach is typically centered around a single design notation with a narrow modeling and analysis focus (e.g., an architecture description language, or ADL [14]). A general-purpose approach embraces a family of design notations with a much broader, system-wide focus (e.g., the Unified Modeling Language, or UML [1]). Thus, for instance, UML emphasizes T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 178-192, 2000. © Springer-Verlag Berlin Heidelberg 2000

A Formal Approach to Heterogeneous Software Modeling

179

modeling practicality and breadth, while ADLs tend to emphasize rigor and depth. Both these perspectives are needed to address the broad spectrum of rapidly changing situations that arise in software development. Our previous work has demonstrated that the two perspectives can indeed play complementary roles in modeling and analyzing software architectures [10,12,16]. We have recently begun using combinations of the general- and special-purpose approaches to aid us in the task of sound software refinement: refining high-level software models (i.e., architectures) into lower-level models (i.e., designs and implementations) in a manner that preserves the desired system properties and relationships [7]. This paper discusses the issues we have encountered in attempting to bridge the two perspectives and the solutions we have developed to address those issues. In particular, we have augmented our ADL-based approach to modeling, analysis, simulation, and evolution of architecturally relevant aspects of a system (e.g., systemlevel structure and interactions, performance, reliability), with the strengths of UML: supporting a broad range of both high- and low-level development concerns with a widely adopted, standard notation. Integrating an ADL-based approach with UML is a non-trivial task. One difficulty arises from the difference in the modeling foci, language constructs, and assumptions between an ADL and UML. Therefore, the first critical challenge is to ensure that the model, as specified in the ADL, is transferred into UML as faithfully as possible, and vice versa. Another difficulty is a by-product of the numerous modeling notations within UML (component, class, object, state chart, use case, activity, etc. diagrams): one view of a system model, as depicted in one notation (e.g., class diagram), may be inconsistent with another view, as depicted in another notation (e.g., activity diagram). Thus, the second critical challenge is to ensure that changes made in one view are reflected as faithfully as possible in another. We have developed and exploited two techniques to deal with these two challenges. They are illustrated in Figure 1. The figure depicts the relationship between the UML modeling constructs (“Core UML”) and the constructs of an ADL, such as Rapide [6] or C2 [18]. As indicated in the figure, only a certain, small number of ADL constructs can be represented in “Core UML”. This should come as no surprise since, as discussed above, ADLs are special-purpose notations that tend to favor rigor and formalism - concepts that are less present in UML due to its practitioner-oriented, general-purpose nature. UML Meta-Model Extension However, UML provides a mechanism that allows “Core UML” to be exRapide tended to address new modeling needs (depicted Core UML C2 by the “UML Extensibility Derived Mechanism” ellipse in Elements Figure 1). We exploit this feature of UML to address the first challenge: supporting the transformation of an ADL model into a Fig. 1. Extending and Augmenting UML; challenges to repUML model and vice resent ADL and analysis Constructs in UML.

180

Alexander Egyed and Nenad Medvidovic

versa.1 The second challenge deals with ensuring the consistency across UML’s modeling notations. Since this area has not been addressed by the designers of UML, the strategy we pursue is to augment UML with constructs that maintain the relationships among the modeling elements across different notations (depicted by the “View Analysis Constructs” ellipse in Figure 1). In tandem, the two techniques allow us to specify, refine, and integrate the heterogeneous models supported by an ADL and by the different UML notations, alleviating the shortcomings of both languages in the process. The remainder of the paper is organized as follows. Section 2 presents our approach to software architecture modeling, analysis, and simulation. Section 3 outlines our technique for transferring architectural decisions into UML. Section 4 focuses on ensuring the consistency among UML models, both across different UML notations and across levels of abstraction (e.g., high-level vs. low-level design). Our conclusions round out the paper.

2 Our Approach to Architecture-Based Development The concepts discussed in this paper are independent of the application domain, the specifics of the chosen architectural style, and the modeling language(s). For illustration purposes, we have selected the C2 architectural style [18]. C2 serves solely as a vehicle for exploring our ideas. It allows us to discuss the development issues relevant at the architectural level and motivates the discussion of transforming an architectural model into UML. This section also highlights certain approaches to software modeling and analysis that are not available in UML. An architecture in the C2 style consists of components, connectors (buses), and their configurations. Each component has two connection points, a “top” and a “bottom.” Components communicate solely by exchanging messages. The top (bottom) of a component can only be attached to the bottom (top) of one bus. It is not possible for components to be attached directly to each other: buses always have to act as intermediaries between them. However, two buses can be attached together. We illustrate the above concepts with an example. The architecture we use is a logistics system for routing incoming cargo to a set of warehouses, shown in Figure 2. The DelPort, Vehicle, and Warehouse components are objects that keep track of the states of a delivery port, a transportation vehicle, and a warehouse, respectively. Each may be instantiated multiple times in a system. The DelPortArt, VehicleArt, and WarehouseArt components are responsible for graphically depicting the states of their respective objects to the end-user. The CargoRouter organizes the display based on the actual number of port, vehicle, and warehouse instances in the system. The Clock provides consistent time measurement to interested components, while the NextShipment component determines when cargo arrives at a port, keeps track of available transport vehicles at each port, and tracks the cargo during its delivery to a warehouse. The GraphicsBinding component renders the drawing requests sent from the CargoRouter using a graphics toolkit, such as Java’s AWT. The five connectors

1

Note that a portion of Rapide falls outside this “extended UML” in Figure 1. This is a reflection of the fact that UML is not always able to support all features of a given ADL [12].

A Formal Approach to Heterogeneous Software Modeling

181

receive, filter, and route the messages sent by components to their appropriate recepients. Clock ClockConn

2.1 Architectural Analysis DelPort

Vehicle

Warehouse

To support architecture modeling, analysis, implementation, and StateConn NextShipment evolution, we have developed a ArtistConn formal type system for software architectures [8,11,13]. We treat Warehouse DelPortArt VehicleArt every component specification at Art the architectural level as an RouterConn architectural type. We distinguish CargoRouter architectural types from basic types BindingConn (e.g., integer, boolean, string, array, record, etc.). A component has a Graphics Binding name, a set of internal state variables, a set of interface Fig. 2. Architecture of the cargo routing system elements, an associated behavior, and (possibly) an implementation. Each interface element has a direction indicator (provided or required), a name, a set of parameters, and (possibly) a result. Component behavior consists of an invariant and a set of operations. The invariant is used to specify properties that must be true of all component states. Each operation has preconditions, postconditions, and (possibly) a result. Like interface elements, operations can be provided or required. The preconditions and postconditions of required operations express the expected semantics for those operations. We separate the interface from the behavior, defining a mapping function from interface elements to operations. This function is a total surjection: each interface element is mapped to exactly one operation, while each operation implements at least one interface. An interface element can be mapped to an operation only if the types of its parameters are subtypes of the corresponding variable types in the operation, while the type of its result is a supertype of operation’s result type. This property directly enables a single operation to export multiple interfaces. This set of definitions allows us to formally treat two distinct development activities: evolution of individual components via subtyping [8] and analysis of an architecture for conformance among interacting components. In this paper we focus on the latter. The left side of Figure 3 shows the relevant definitions of interface 2 parameter conformance and operation conformance. The right side of Figure 3 is a reflection of our experience that components need not always be able to fully interoperate in an architecture, but that mismatches should be allowed under certain situations (e.g., COTS reuse). The two extreme points on the spectrum of type conformance are: minimal type conformance, where at least one service (interface and 2

The definitions are specified in Z, a language for modeling mathematical objects based on first order logic and set theory [17]. Z uses standard logical connectives (∧, ∨, ⇒, etc.) and set-theoretic operations(∈, ∪, ⊆, etc.). The complete formal defintion of the type system is given in [11].

182

Alexander Egyed and Nenad Medvidovic

Fig. 3. Formal specification of architectural type conformance predicates

corresponding operation) required by each component is provided by some other component along its communication links; and full type conformance, where every service required by every component is provided by some component along its communication links. 2.2 Example of Architectural Analysis We illustrate architectural type conformance with a simple example drawn from the cargo routing application (recall Figure 2). Figure 4 shows partial models of the DelPort and DelPortArt components, specified in the C2SADEL ADL [13]. The two components are intended to interact in the cargo routing system (i.e., there is a communication path between them in the architecture via StateConn and ArtistConn). In the example from Figure 4, DelPortArt requires one service: unloadShipment, which is mapped to its operation or1. DelPort provides an operation, op1, with a matching interface (as required by the interface parameter conformance predicate in Figure 3). Thus, to establish type conformance, we must make sure that the pre- and postconditions of the two operations are properly related as specified in the operation conformance and minimal type conformance predicates in Figure 3. To do so, we must establish that the following relationships hold: • DelPortArt or1 pre ⇒ DelPort op1 pre (s ∉ contents) ⇒ true

Since DelPort’s op1 does not have any preconditions, the right-hand side (RHS) of the implication becomes true. Therefore the entire implication evaluates to true regardless of the truth value of its left-hand side (LHS). • DelPort op1 post ⇒ DelPortArt or1 post ((~cap = cap + ShpSize(s)) ∧ (s ∈ ~cargo)) ⇒ (s ∈ ~contents)

A Formal Approach to Heterogeneous Software Modeling component DelPortComponent is { state { cap : Int; max_cap : Int; cargo : \set Shipment; ShpSize : Shipment -> Int } invariant { cap \eqgreater 0 \and cap \eqless max_cap; } interface { prov ip1: unloadShipment(s : Shipment); req ir1: Tick(); } operations { prov op1: { let s : Shipment; post (~cap = cap + ShpSize(s)) \and (s \in ~cargo); } req or1: { let time : STATE_VARIABLE; post ~time = 1 + time; } } map { ip1 -> op1 (s -> s); ir1 -> or1 (); } }

183

component DelPortArtComponent is { state { selects : \set Int; UniqueID : Int \x Int -> Int; } invariant { #selects \eqgreater 0; } interface { prov ip1: selectShipment(port : Int; shp : Int); req ir1: unloadShipment(s : Shipment); } operations { prov op1: { let pid : Int; sid : Int; post (#~selects = #selects + 1) \and (UniqueID(pid,sid) \in selects); } req or1: { let s : Shipment; contents : STATE_VARIABLE; pre (s \not_in contents); post (s \in ~contents); } } map { ip1 -> op1 (port -> pid, shp -> sid); ir1 -> or1 (s -> s); } }

Fig. 4. Partial specification of the DelPort and DelPortArt components. # denotes set cardinality; ~ denotes the value of a variable after the operation executes; STATE_VARIABLE is a placeholder for any basic type

The two matching interface elements (unloadShipment) of the DelPort and DelPortArt components have matching parameters (s), which are mapped to the respective components’ operation variables (also s). DelPortArt’s variable contents is of type STATE_VARIABLE, which is intended to generically describe 3 the internal state of another component in a required operation. contents can be unified with the DelPort internal state variable cargo, so that the implication becomes ((~cap = cap + ShpSize(s)) ∧ (s ∈ ~cargo)) ⇒ (s ∈ ~cargo)

This implication is of the form (A ∧ B) ⇒ B and is also true: an implication can be false only if its RHS (B) evaluates to false; however, in this case that would result in the LHS (A ∧ B) also evaluating to false, making the implication true. We have thus established that, at the least, minimal type conformance holds in the architectural interaction between DelPort and DelPortArt. 2.3 Architectural Simulation The example above demonstrate how an architecture can be analyzed statically for desired properties. Another way in which we have been able to analyze C2-style architectures has been through early simulations of applications, built based on the applications’ architectural models. To this end, we have exploited C2’s event-based nature: one can rapidly construct a partial implementation of an architecture that mainly focuses on the components’ external (asynchronous message) interfaces. For example, a prototype of the cargo routing application discussed above was initially implemented and later augmented to include a foreign-language user interface by a single developer in a matter of hours [2]. Our support tools also allow insertion of event monitors and filters to explicitly observe message traffic and assess dynamic properties of the architecture. Any inconsistencies in the architecture not detected by 3

For a more formal and in-depth treatment of STATE_VARIABLE types, see [11]

184

Alexander Egyed and Nenad Medvidovic

type conformance checking, such as inconsistencies in component interaction protocols, are likely to manifest themselves during simulations. 2.4 Tool Support The activities described in this section (architecture modeling, analysis, simulation, implementation, and evolution) are supported by DRADEL, a component-based development environment [13], and a light-weigt simulation and implementation infrastructure [9]. Three of DRADEL’s components are particularly relevant to this discussion (a fourth component will be discussed in Section 3): • The TopologicalConstraintChecker component analyzes an architecture for adherence to design heuristics and architectural style rules. Currently, this component ensures the rules of the C2 style, but can be easily replaced with components enforcing other kinds of design rules. • The TypeChecker component implements the rules of our architectural type system, briefly discussed in Section 2.1. The TypeChecker automatically performs the conformance checks such as those shown in Section 2.2. • The CodeGenerator component automatically generates architecture implementation skeletons discussed in Section 2.3. The skeletons are generated based on a component’s architectural model specified in C2SADEL: all message generation, marshalling, and unmarshalling code is produced, as is a stub for the component’s internal (application-specific) behavior. Component stubs are then completed manually. The amount of effort needed to complete a stub depends on the desired faithfulness of the prototype implementation to the final system and it can range from a few to several hundred lines of code.

3 Refining an Architectural Model into a UML Model Once an architectural model is constructured and its analysis and simulation demonstrate the presence (or absence) of properties of interest, the model can be used as a basis for system design and implementation. This requires the transfer of information from the architectural model to a (high-level) design and subsequent refinement of that design. One way to effectively accomplish this task is by transferring the application model from an ADL to a notation better suited for addressing lower-level design issues. We employ UML [1] to that end. UML is a semi-formally defined design language with a large, extensible set of modeling features that span a number of modeling diagrams (see Section 1). Our previous work has studied in depth the relationsip between ADLs and UML [10,12,16]. One outcome of this research has been a set of well-defined strategies one could employ to meaningfully transfer an ADL model into UML. Based on this work, we have recently augmented the DRADEL environment discussed in Section 2.4 to include UMLGenerator, a component that transforms a C2SADEL specification into a UML model. UMLGenerator uses a set of formally defined rules that specify how each C2SADEL construct is transformed into a corresponding (set of) UML construct(s). The rules make use of predefined UML constructs, as well as stereotypes, UML’s built-in extensibility mechanisms. Stereotypes allow the addition

A Formal Approach to Heterogeneous Software Modeling

185

of attributes to existing modeling elements (via tagged values) and the restriction of modeling element semantics (via constraints). The constraint portion of a stereotype is formally specified in UML’s Object Constraint Language (OCL) [19]. For example, the compositional rules of the C2 architectural style, discussed in Section 2, can be specified using a UML stereotype as follows. Stereotype C2Architecture for instances of meta class Model [1] A C2 architecture is made up of only C2 model elements. SELF.OCLTYPE.MODELELEMENT->FORALL(ME|ME.STEREOTYPE= C2COMPONENT OR ME.STEREOTYPE = C2CONNECTOR OR ME.STEREOTYPE = C2ATTACHOVERCOMP OR ME.STEREOTYPE = C2ATTACHUNDERCOMP OR ME.STEREOTYPE = C2ATTACHCONNCONN)

[2] Each C2Component has at most one C2AttachConnAbove. LET COMPS=SELF.OCLTYPE.MODELELEMENT->SELECT(ME|ME.STEREOTYPE=C2COMPONENT), COMPS->FORALL(C | C.ASSOCEND.ASSOCIATION->SELECT(A | A.STEREOTYPE = C2ATTACHCONNABOVE)->SIZE SELECT(ME|ME.STEREOTYPE=C2COMPONENT), COMPS->FORALL(C | C.ASSOCEND.ASSOCIATION->SIZE > 0)

[5] Each C2Connector must be attached to some connector or component. LET CONNS=SELF.OCLTYPE.ELEMENTS->SELECT(E|E.STEREOTYPE=C2CONNECTOR), CONNS->FORALL(C | C.ASSOCEND.ASSOCIATION->SIZE > 0)

The above stereotype describes only one portion of C2 and is accompanied by other stereotypes defining C2 components and connectors, their interactions, and the internal makeup of individual components and connectors as specified in C2SADEL [13]. This complete specification of C2 concepts in terms of UML stereotypes was used as the basis for implementing the UMLGenerator component. Figure 5 shows a partial and somewhat simplified set of C2SADEL-to-UML transformation rules as encoded in the UMLGenerator. Internal Component Object → Class State Variable → Class Private Attribute Component Invariant → Tagged Value + Class Documentation Provided Operation → Class Operation Required Operation → Class Documentation Operation Pre/Post Condition → Pre/Post Condition on Class Operation Message Return Type → Return Type on Class Operation Message Parameter → Parameter (Name + Type) on Class Operation Architecture Configuration (explicit invocation) → (Object) Collaboration Diagram Component Instance → Internal Component Object Class Instance Connector Instance → «Interface» Class Instance Component/Connector Binding → Object Link (instance of an association) Component → «C2-Component» Class Internal Component Object → «C2-Component» Class Attribute Component Top Interface → «Interface» Class Component Bottom Interface → «Interface» Class Outgoing Message → «Interface» Class «out» Operation Incoming Message → «Interface» Class «in» Operation Fig. 5. Excerpt from the rule set for transforming C2SADEL into UML. «» denotes stereotypes

186

Alexander Egyed and Nenad Medvidovic

DeliveryPort

Clock : ClockCom ponen

(from Logi cal View)

ports : Del iveryPortTy pe_SET 18: reques t

unloadShipment()

ClockConn : ClockConn

DeliveryPortsComponent stat e_var : Deli veryPort sComponent

16: notification 17: notification DelPort : DeliveryPort

Vehicles : W arehous es : Vehicles Com ponent 6: reques t W areh ous es Com pon ent

3: r eques t

4: reques t

5: reques t

IB ot tom DeliveryPortsCom ponentCom ponent

StateConn : StateConn 2: n otification 1: reques t Ar tis tConn : Artis tConn

Incom ing Ship me ntHand ler : Incom ing Ship me ntHand lerCom pon ent

13: notification 11: notification DeliveryPortArtist : DeliveryPortArtistCom ponent

newShipmentCompleted() getDeliveryPortsCompleted() unloadShipmentCompleted() newShipment() getDeliveryPorts() unloadShipment()

ITopDeliveryPortsComponentComponent

12: notification

VehicleArtis t : VehicleArtis tCom ponent

9: reques t

W arehous eArtis t : W areh ous eArtis tCom p onent

10: reques t

8: reques t RouterConn : RouterConn

7: notification CargoRouter : Car goRou terCom pon en

15 : requ es t B inding Conn : BindingConn 14: notification Graphics B inding

Fig. 6. Partial UML model of CargoRouter architecture (using Rational Rose™)

The UML specification resulting from this transformation is stored as a Rational Rose model [15]. A portion of the Rose model for the cargo router architecture from Figure 2 is shown in Figure 6: it depicts the entire architecture as a UML collaboration diagram (left) and the attributes of and class diagram corresponding to the DeliveryPort component (right). This automatically generated Rose model is consistent with the architectural model and is used as the basis for further, possibly manual refinement of the architecture as discussed below. TM

4 Design Refinement and Analysis Architectural refinement enables us to transform our C2 architecture into a (highlevel) UML design. Since that design will likely be further refined into lower-level designs (and an implementation), those subsequent refinements may become inconsistent with the original architecture. This is particularly likely if the refinements are done manually. This section will discuss how a refinement can be automated by employing a technique that augments UML (recall Figure 1). 4.1 View Integration Framework To enable automated design analysis we have devised and applied a view integration framework, accompanied with a set of activities and techniques for identifying mismatches in an automatable fashion [3]. This approach exploits redundancy between

A Formal Approach to Heterogeneous Software Modeling

187

views: for instance, if view A contains information about view B, this information can be seen as a constraint on B. The view integration framework is used to enforce such constraints and, thereby, the consistency across the views. In addition to constraints and consistency rules, our framework also defines what information can be exchanged and how it can be exchanged. This is critical for automating the process of identifying and resolving inconsistencies since direct comparison between views is usually infeasible. Our framework has three major activities: • Mapping identifies related pieces of information and thereby describes what information is overlapping. Mapping is often done manually, e.g., via naming dictionaries and traceability matrices. • Transformation simplifies (i.e., abstracted) detailed views or generalizes specific views. This activity describes how information can be exchanged and results in derived modeling information. • Differentiation traverses the model to identify mismatches. Mapping indicates what information should be compared; Transformation indicates how that information should be compared. We will illustrate these concepts using the cargo router exaRouteCollection ample. Figure 7 depicts an excerpt theStorage of its design in UML in the form aWarehouse of a class diagram. This design theWarehouseCollection varies considerably from the highRefrigeratedStorage level design we generated in SecaSurplus aDeficiency tion 3. As the design is further modified, it will become increasingly difficult to see whether the availableGoods theTimeNeeded changes are consistent with the aPort original architecture, depicted in Figure 2. Again, note that the Fig. 7. Design Refinement of CargoRouter architectural and design views show distinct but overlapping information; this redundancy between the views is used in the form of constraints in helping to verify consistency. It has been our observation that the major challenge of view integration is not the actual comparison of views (Differentiation) but instead the Transformation and Mapping of modeling information [3]. Since Mapping tends to be predominantly manual, Transformation becomes the key enabling technology for automated view integration. We, therefore, discuss it on more detail. 4.2 Transformation Figure 8 captures the three major dimensions of view transformation [3]. Software modeling views can be seen as abstract or concrete on the one hand, and generic or specific on the other. The abstract-concrete dimension was foreshadowed in Section 3 where the C2 architecture was the abstract view and the generated UML model was the concrete view. Note that a view’s level of abstraction is relative. Thus, for in-

188

Alexander Egyed and Nenad Medvidovic generic

specific Translation

abstract

(e.g., collaboration to sequence diagram)

a) b)

Abstraction (e.g., between class diagrams)

c)

concrete

C2SADEL class state

sequence collaboration

class state

sequence collaboration

Consolidation (e.g., sequence to state diagram)

Fig. 8. Two dimensions of views with three dimensions of view transformations. Paths a-d denote possible transformation paths from concrete-specific to abstract.

stance, the derived UML model depicted in Figure 6 is concrete relative to the C2 view but abstract relative to the class diagram in Figure 7.4 The generic-specific dimension denotes the generality of modeling information. For instance, a class diagram naturally describes a general relationship between classes, whereas a sequence diagram describes a specific scenario. Another way of saying this is that constructs in general views must capture the union of all specific views, and that a specific view must fit within the boundaries of its respective generic one. The level of generality/specificity is, again, in the eye of the beholder (e.g., a view is more generic than some views and more specific than others). Having two dimensions of views implies three types of transformation axes: Abstraction to capture vertical transformation, Consolidation to capture horizontal transformation, and Translation to capture transformation within a single quadrant (both input and output views are of the same category). We have also observed that often only uni-dimensions transformations can be fully automated (e.g., [4,5]) - usually going from concrete to abstract or from specific to generic. The framework depicted in Figure 8 allows us to combine simple transformation techniques to enable more complex transformations in support of the integration of C2SADEL and UML. Figure 8 depicts one such complex transformation going from the lower right quadrant (e.g., a concrete sequence diagram) to the upper left quadrant (e.g., an abstract class diagram). The three paths (“a” to “c”) indicate the three alternative transformation scenarios on how to get there. Path “a” first abstracts the sequence diagram and then consolidates it to yield a class diagram view. Path “b” first consolidates and then abstracts. Path “c” consolidates, translates, and abstracts. There are of course other variations using additional translations. The translation step may seem redundant since it does not seem to put us any closer to the target quadrant. Nevertheless, translation can help us in circumventing a non-existing transformation by translating to another view that can be abstracted/consolidated or by switching to a more reliable abstraction/consolidation method not available within the current view.

4

Note that the implementation is the most concrete view of a system.

A Formal Approach to Heterogeneous Software Modeling

189

Derived = {A,D} = {ω={α,ζ},β}

Derived = {A,B,D} = {α,τ= {β,δ},ζ={γ,δ}}

α aPort

β

κ

γ

aSurplus

Original

ω

Available Goods

= {A,B,C,D} = {α,β,γ,δ}

ζ

aWare house

δ τ

Fig. 9. Representation of Abstraction Transformation (multiple views and their storage)

The right hand-side of Figure 8 depicts existing transformations our approach currently supports (e.g., concrete class to abstract class, sequence to state, etc.). Note that a few arrows are double-headed, with the second head drawn in a light gray shade. These cases denote examples where the reverse transformation is semi-automated. 4.3 Implication of Transformation for Consistency Checking Complex transformations are not just a serial execution of individual transformations. To enable complex transformations we also need to address the issue of how to capture and maintain modeling information – in particular, how to handle derived modeling information [3]. Thus, transformation methods need to be integrated in order to avoid the two fundamental problems that may arise: 1. Transformation Redundancy: a modeling element should be transformed at most once using the same transformation method, thus avoiding transformation redundancy. 2. Multiple Derived Results: multiple transformations of a modeling element using different transformation methods may result in multiple results. The model must therefore support multiple interpretations. Figure 9 demonstrates both issues using relation abstraction (a method that collapses relations among multiple modeling elements into simpler relations). The bottom-most layer on the left hand-side shows an excerpt of the class diagram from Figure 7 with four classifiers (boxes) and a number of relations (links) between them. The middle layer is more abstract in that the classifier aSurplus has been eliminated and a more abstract relation (τ) has been created to replace it. The top-most layer further eliminates the classifier availableGoods. We now have three views. If we were to store the views separately, we might eventually introduce inconsistencies between them. For instance, any changes to the bottom view would require updates to all its higher-level abstractions. This would likely become unmanageable in a largescale system with a large number of user-created views plus all their transformations. Furthermore, if we again take the bottom view and abstract aSurplus away, we are

190

Alexander Egyed and Nenad Medvidovic

duplicating both effort and storage since we are not aware of the previous abstraction. The right hand-side of Figure 9 depicts a possible solution for these two problems. It suggests using an n-ary relationship among modeling elements. The figures on the left are now simply projections of the model on the right. The underlying model on the right minimizes information duplication. Note that UML does not support n-ary relationships among many of its modeling elements, partially motivating our decision to augment it. Revisiting Figure 1, the problem of how to deal with derived modeling elements can only be solved by augmenting the model.

missing clock components and connectors DelPort

W arehouse

StateConn

IncommingShipmentHandler

DeliveryPortArtist

VehicleArtist

Vehicles

illegal component interaction ArtistConn

W arehouseArtist

... Fig. 10. Except of Abstracted Class Diagram

4.4 Consistency Checking The issues discussed in sections 4.1 and 4.2 form the foundation that allows us to check the relative consistency of two or more UML models. Thus, in order to ensure the consistency of the UML model in Figure 7 with respect to the original C2 architecture in Figure 2 (or Figure 6) we can automatically derive the transformation paths, perform the actual transformations (the refinement of the C2 model and the abstraction of the class diagram), and then compare their respective results (two class diagrams at similar levels of abstraction). Figure 10 shows an excerpt of the abstraction from Figure 7 using a set of abstraction rules discussed in Section 4.2 and completely specified in [4]. We can now observe that the architecture differs from the design in several ways: the design does not include the Clock component or its related connector and depicts some component interactions (e.g., DelPort to Warehouse) that are not defined in the architecture. Although it is possible that both these cases are results of deliberate design decisions, transformation has enabled us to easily compare the two views and quickly highlight their inconsistencies. The human designer can then either address the inconsistencies or ignore them. To date, we have automated a part of our view integration framework in a tool called UML/Analyzer [3]. The abstracted view depicted in Figure 10 can be derived automatically using our tool.

5 Conclusion This paper addressed architectural modeling using a specialized approach, C2, and showed how it can be used to complement a general-purpose modeling language, UML. We discussed the benefits of C2 and UML as well as the need for integrating

A Formal Approach to Heterogeneous Software Modeling

191

their respective strengths. The integration of C2 and UML is not a trivial undertaking and we introduced two techniques to enable it: constraining UML and augmenting it. We showed how to represent C2 in UML (Section 3) in order to illustrate constraining UML and how to perform complex transformations and view integration (Section 4) in order to illustrate augmenting UML. This paper also presented formal approaches to software development to support a variety of development activities (specification, analysis, and modeling). Formalism plays a major role during all of those activities. Formalism is also the foundation of automation. The benefits of automation were illustrated throughout this paper. In Section 2, we discussed the analytic powers of special-purpose models like C2. Using C2 we were able to automatically analyze static and dynamic properties of our system. Automation then helped us in further refining our special-purpose C2 model into a general-purpose UML model (Section 3). This automated refinement capability removed a major obstacle to model integration since no manual labor was required in making tools and models work together. Finally, automation supported us during model validation. We illustrated automated consistency checking between views and demonstrated this using a C2 architecture and its corresponding UML design (Sec. 4). To date, we have automated many of the concepts discussed in this paper and created two tool suites: SAAGE (Dradel+Rose) to enable architectural modeling and refinement; and UML/Analyzer (also integrated with Rose) to enable automated transformations and consistency checking. It is our long-term vision to further extend the automation support to other aspects of the software life cycle.

6 Acknowledgements This research is sponsored by DARPA through Rome Laboratory under contract F30602-94-C-0195 and by the Affiliates of the USC Center for Software Engineering: http://sunset.usc.edu/CSE/Affiliates.html.

7 References 1. Booch, G., Jacobson, I., Rumbaugh, J.: The Unified Modeling Language User Guide, Addison-Wesley, 1998 2. DARPA. Evolutionary Design of Complex Software (EDCS): Demonstration Days 1999. http://www.if.afrl.af.mil/programs/edcs/demo-days-99/ 3. Egyed, A.: “Integrating Architectural Views in UML,” Qualifying Report, Technical Report, Center for Software Engineering, University of Southern California, USC-CSE-99-514, http://sunset.usc.edu/TechRpts/Papers/usccse99-514/usccse99514.pdf, 1999 4. Egyed, A. and Kruchten, P.: Rose/Architect: a tool to visualize software architecture. Proceedings of the 32nd Annual Hawaii Conference on Systems Sciences (1999) 5. Koskimies, K., Systä, T., Tuomi, J., and Männistö, T. (1998) “Automated Support for Modelling OO Software,” IEEE Software, January, pp. 87-94.

192

Alexander Egyed and Nenad Medvidovic

6. Luckham, D.C. and Vera, J.: “An Event-Based Architecture Definition Language.” IEEE Transactions on Software Engineering, vol. 21, no. 9, pages 717734, September 1995. 7. Medvidovic, N., Egyed, A., and Rosenblum, D.S.: Round-Trip Software Engineering Using UML: From Architecture to Design and Back. In Proceedings of the Second International Workshop on Object-Oriented Reengineering (WOOR’99), Toulouse, France, September 6, 1999. 8. Medvidovic, N., Oreizy, P., Robbins, J.E., and Taylor, R.N.: Using ObjectOriented Typing to Support Architectural Design in the C2 Style. In Proceedings of the Fourth ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE4), pp. 24-32, San Francisco, CA, October 16-18, 1996. 9. Medvidovic, N., Oreizy, P., and Taylor, R.N.: Reuse of Off-the-Shelf Components in C2-Style Architectures. In Proceedings of the 1997 Symposium on Software Reusability (SSR'97), pp. 190-198, Boston, MA, May 17-19, 1997. Also in Proceedings of the 1997 International Conference on Software Engineering (ICSE'97), pp. 692-700, Boston, MA, May 17-23, 1997. 10. Medvidovic, N. and Rosenblum, D.S.: Assessing the Suitability of a Standard Design Method for Modeling Software Architectures. In Proceedings of the First Working IFIP Conference on Software Architecture (WICSA1), pp. 161-182, San Antonio, TX, February 22-24, 1999. 11. Medvidovic, N., Rosenblum, D.S., and Taylor, R.N.: A Type Theory for Software Architectures. Technical Report, UCI-ICS-98-14, Department of Information and Computer Science, University of California, Irvine, April 1998. 12. Medvidovic, N., Rosenblum, D.S., Robbins, J.E., Redmiles, D.F.: Modeling Software Architectures in the Unified Modeling Language. In submission. 13. Medvidovic, N., Rosenblum, D.S., and Taylor, R.N.: A Language and Environment for Architecture-Based Software Development and Evolution. In Proceedings of the 21st International Conference on Software Engineering (ICSE'99), pp. 44-53, Los Angeles, CA, May 16-22, 1999. 14. Medvidovic, N., and Taylor, R.N.: A Classification and Comparison Framework for Software Architecture Description Languages. IEEE Transactions on Software Engineering, to appear, 2000. 15. Rational Software Corporation, Rational Rose 98: Using Rational Rose 16. Robbins, J.E., Medvidovic, N., Redmiles, D.F., and Rosenblum, D.S.: Integrating Architecture Description Languages with a Standard Design Method. In Proceedings of the 20th International Conference on Software Engineering (ICSE'98), pp. 209-218, Kyoto, Japan, April 19-25, 1998. 17. Spivey, J.M.: The Z notation: a reference manual. Prentice Hall, New York, 1989. 18. Taylor, R.N., Medvidovic, N., Anderson, K.N., Whitehead, E.J., Jr., Robbins, J.E., Nies, K.A., Oreizy, P., and Dubrow, D.L.: A Component- and Message-Based Architectural Style for GUI Software. IEEE Transactions on Software Engineering, vol. 22, no. 6, pp. 390-406, 1996. 19. Warmer, J.B., Kleppe, A.G.: The Object Constraint Language: Precise Modeling With UML, Addison-Wesley, 1999

Formal Specification of Object-Oriented Meta-modelling ¨ l

l

ll

Abstract.

lm

l

l l

m

m

l

l

m

l

l

ll

l l

l

m

l

l meta-modelling m l m

l

m m

m ll

Boom m

m m ll

ll

m l

m l m m

l

1

ll m

ll

ll

m

l m

ll

m m

m

l l

Introduction m

j

m

m

i

m i i

x

i

m m

i

i

m

m

i m

im

ii

i

i i

m

i

i

i

m i

m

i

i i

i i

i i

i

m i i i m

i j i

i i m

m

i m m

i m

i i

m i m

i

i

i

x

i

i i i

i i

i

i

m

l

m i i

i m

i i i

i i m

i

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 193–207, 2000. c Springer-Verlag Berlin Heidelberg 2000 

i i

j m m

i i

i m

i

¨

i m

i

i i mi

m

m

i

i i

i

m

i

i i

m

m i

i i m

i

i i

m ii m i ii

m

m im ii i m i i m xi Formal Methods m http://www.comlab.ox.ac.uk/archive/formal-methods. html m i i m im i j i i i fl m mm i i i m j i m m ii i m i i j i i i i i m j i j i m i i i ii i i i i i j i i m i i i j i modelling language j i specification method j j i i i i i m m ii i i i i m i i m m i i i i i ii x i m ii i m i i mi m i i m i i i j i ii i i ii i i i m m i i i i i j i i i i ii i i m ii i i j i i i i i i m i i m i i i i i j i m i im i m i i m i i ii x i m m m m m i i m j i m i i i i x i i m m i i i i m i i m m i m mi m i i m m i i m i m m i i m i i i i i i m m i i i i m i i i i i i i x i m i i m i i i m i x i m i i i

j i

m i

i

fl xi

i

m i

m l

i

m

i

m

i

i

ll

m

i

m

2

Boom – A Framework for Formal Specification i

m m m m i i i

i

m

Boom

i

i

i

j

i

i m

ii m

i i m

Odal i

m

x i i i i

im m i m

i

m i i

i

i i

j π

i i i i

j xim

Odal i

i mi

m

Odal

mii π

x m

i

i m

m

i

i

mmi i

i localization principle im i i i i i i i i i x m i i j m i j i i i i m i m i i i i i i i j i i m i i mi i i i i i i i i im i i m i m i i i m i m i i m Boom x i m i m i i i m x i i i i m Boom i m i m i m i i i i m im m Boom i i i m i i i i i

Boom

i

i

i

m i i

i

ii ii xi Boom i

i m

Boom i

i i

m

m

ConnectionType

Connection

AssociationRule

* Declaration

Link *

* *

Instance

Env *

* EntityType

Operation

Fig. 1.

Boom

Action

*

¨

i i

Boom

i

i

xim

x m i m i

i

i

i i

mi

i

i

m

i i

i

xi i x

i Boom m m i i

i

m

i

i i ii

m

m

i

x

xi i i

Boom

i i i

Boom

i

i

i

Class-like Constructs i

i

m

i

x

i

i

i

m i

i

i

i

m i i

i i

i

i

i

i

i

i

i

m

i

i

i

i

m

i

i

i i

i m

i

i im i i i

i i

j

i

i

i i i

i x

i i m

i j

m

i

m

i i

i

i

i

i

i

i

i

i i

mii i x m

i i

i

m

Odal

i

i

m i

i

i

i i

i i im

i i

i i i

m

Boom

i i Odal x i

j

Boom

i

m

i

i i i

i i

i i i

i i

i

i i

x

i

i i

i

i i

i i i

i i

i

i

i xi

x

Boom i

i i

i

i i

Boom

i

i

i

i

m i i i

i

i

m

i

Boom

m

i i

i

i

i

i

m i

Boom

2.1

m i

i

Boom

i

i

j

i

x m i i i

i m

m l

m

class Instance variables origin : Declaration, links : Link* invariant origin = null methods initialize (o : Declaration, c : Connections) : Instance origin := o; foreach con in c do links add con createLink () entityType () : EntityType origin instanceKind () evaluateAction (a : Action) : Boolean ... . . .

x m i

i i i

i i

class Declaration superclass Instance variables operation : Operation*, connection : Connection*, instanceType : EntityType, name : Name invariant name = null and instanceType = null methods addConnection (c : Connection) : Boolean if self lookupConnection (c name ()) = null and ruleset allowedConnection ( self instanceKind (), c target () instanceKind (), c connectionType ()) then connection add c; true else false lookupConnection (n : Name) : Connection collect c in connection suchthat c name () = n instanceKind () : EntityType instanceType createInstance () : Instance instanceType source () new (self, connection) . . .

i

i m

m

i

m

i

m i i

i

i

i xi

i

i i

i

i

i

i

ruleset

i

i ii

i i

i true

Relationships i

Boom

i

i i i

i

i

i i

i

i i

i i

i

i

i i

i i

m

i

2.2

m i addConnection ii m i i

ll

i

class Connection variables name : Name, target : Declaration, instanceType : ConnectionType invariant target = null and name = null and instanceType = null methods target () : Declaration target connectionType () : ConnectionType instanceType createLink () : Link Link new (self) . . .

i i

i i i

i

i i

i class Link variables origin : Connection value : Instance* invariant origin = null methods connectionType () : ConnectionType origin connectionType () . . .

¨

m

i i

i Boom i

i i i

i

im i i i i i

i m

i i

i

i

x m

i

x i i i i x m

i

m

i i

i m i

i

i

i

Mapping Language Entities onto Boom Classes x i i m i m

i

i

m

i

m m

i

i

i

m

i

i

i

i m i i

i m

i

m

x m

m

i i

i

i m

i

i i

m i

i

m x m

i i

m

i m

i

i m

Boom

i

i i

i i

i m

x

i

i i

m

i m m

i

i

i

j j

m i

j i

i i

m i

i Boom i

i

Boom

i

m i Boom

i

m i i

i

m m

i i

Boom

i

i m

i

i Boom

i

i i

m

Boom m Boom

m

i

i

i

i

i

m

i m

m i

mi m i Boom i i m i

m

Boom

m

i

Boom

m

fli

m i i

j i

Boom

i i

i

i i m

i

i

xm i i i i m i i m i m i i

i

i

Boom

m i

i m

i

i

2.3

i i

i i m i

i

x m

i

i ii

m

i i

m i

i i

i

i i

m

i

i

i

i

m i

i

i

m i

i i

i m

i m

i i

m l mapping mapping mapping mapping

i

i

i

Boom

i i i i

m

i

i

Boom

i i

ll

(EntityType new (CLASS, Declaration)); (EntityType new (OBJECT, Instance)); (ConnectionType new (POINTERDECLARATION, Connection)); (LinkType new (POINTER, Link));

add add add add

j m

m

m i m

x i i m i

i

i

i

i

i i

i i Boom m i i i i i i x i m kind of source, kind of target, kind of connection

m x m i i i i i x i

x i i i

i

i

i i

ruleset add (AssociationRule new (CLASS, CLASS, POINTERDECLARATION));

i

i

i m

i i i

m

i

i

m

i

i i

Boom

m

m i

i

m i

m

i

m

i

i

i

i i

i

i

i i

m

i x m

i

i

1

POINTER− DECLARATION

CLASS * *

OBJECT

POINTER *

Fig. 2.

m

m

m

x

l

m l l

i

x

m

x

m im

x

i

i x

i

i

i i i i

m

m

i i i

i i ii i Boom

i

i

i i

i

i im i i instance-of i m m i i i

i i i

m i i

m i

i i

ii

¨

m

–

i

i

i i

i

i

i

i

i

i m

–

i

i

i m

–

i mi i i

i i m

–

i

i

m i

i

i i

i

m

i

m

m

m i

i

i

i

i

i i i

i

i j

i

i

i

i

i

i j j

m i i

i

i

m m

m

m

i

3

Formal Specification of UML Using Boom i

i

x m i

i i

i i i

i

Boom i

m x

i

i

m

i

i i

i i

i Boom

Boom

Boom

m

i

i

i

i

i

i

i i 3.1

Class Construct i

i i i

i i

j

m i

i i i

i i i i

i i

i m i

i

m

i

i m

m

i i

i i i i

i i i i i

i i i

i i

im

i

i

i

Boom

i

i

i

Boom

i

m

i i i

i

m i

i

m i

m m

i Boom i m

i

i

im i i i i i i multiplicity x

i i i im i

i

x

m

i Boom

i

i

m l

i

m

i

i

i

m i

i i

i

i

i

i

i

i

i

i

i i

j

m

i m i i

i

m

i

m

i m

m

i add add add add add add add

i

i i i i Boom

Boom

Odal x

i

(EntityType new (CLASS, Declaration)); (EntityType new (DATATYPE, Declaration)); (EntityType new (OBJECT, Instance)); (EntityType new (DATAVALUE, TokenInstance)); (ConnectionType new (ATTRIBUTE, MultiplicityConnection)); (LinkType new (ATTRIBUTELINK, NumberedLink)); (AssociationRule new (CLASS, DATATYPE, ATTRIBUTE));

m i

i i

CLASS

OBJECT

Fig. 3.

i

m

i

m

i

j i

i

i

i

i

i

mapping mapping mapping mapping mapping mapping ruleset

i

i

i

i

i

i

m j

Boom

m

i

i

i

i

j

m

m

i

ATTRIBUTE

*

ATTRIBUTE− LINK

DATATYPE

*

l

i i

DATAVALUE

l

m m

m i

Odal

1

*

m

i i

3.2

ll

i

i

i

i m

Boom

Association Construct

i i i m i i i i i

i im i i m

i

i

m

i

i

i

i multiplicity

i

i m

i m

m

i

i i i

i

i

x i

i

i i

i i i

m

i i i i i i i

¨

i

i

i

i

i m

i i m

m

i m i i i

i i i i

i i i

i

i i

x i

i

i m

i

i i

i Boom i i i m

i i i

i

i

i x i

i i

i

i i

i x

i

i i i

i

i Boom

i i

i i m

i

x

Odal

i

i

mapping add (EntityType new (ASSOCIATION, AssociationDeclaration)); mapping add (ConnectionType new (ASSOCIATIONEND, MultiplicityConnection)); ruleset add (AssociationRule new (ASSOCIATION, CLASS, ASSOCIATIONEND));

im i

i

j

i i m

i m

i i

i x

i

i

Boom

m

ii i

i

i

i

Boom

i

x

i

mapping add (EntityType new (LINK, Instance)); mapping add (LinkType new (LINKEND, SingleLink));

m

m

i i

i

i

i

2..*

Fig. 4.

m

m

i

i m i Odal

i m

i

i

m

CLASS

1

*

LINK

1

ASSOCIATION− END

ASSOCIATION

LINKEND

OBJECT

l

i

i

i i

m

i

Boom

i

i

i i

i

i 3.3

Package Construct i

i

i i

m i

m m

m

i

m

i i i

m

i m

m l

i

i

m

i

i i

i m

m

m

x

i

i im x

i

i i

xi m i

i

i i

i

i i

i

i i i

j

i i x m i i i

i

i i

i

i Boom

i

Boom

i

im i

ll

i

x

x

i

i i

i

i

i

i

i

x i i i

i

i

i

m

m

i

i

i

i

i i i

Boom

i

x

i

i i

i

i

i

i

mi i i m

i i m

i i

ii i

i m

i m i

i

i i

i

i

mapping add (EntityType new (METAPACKAGE, NamespaceDeclaration)); mapping add (EntityType new (METACLASS, MetaDeclaration));

i

m m

i i

i i

i

i i

m i

i

i m

i i

i i

i

mapping add (ConnectionType new (CONTENTSDECLARATION, ContentsConnection)); mapping add (LinkType new (CONTENTS, Link)); ruleset add (AssociationRule new (METAPACKAGE, METACLASS, CONTENTSDECLARATION));

i i

i

i i

i m i

i

i

i

mapping add (EntityType new (PACKAGE, NonInstantiableDeclaration));

m

m

i i

i i

3.4

i i

Class and Association Constructs Revisited i

j

i

i m m

i m i

x m i

i i im

m

Boom

i

i

i

¨ 1

CONTENTS− DECLARATION

*

CONTENTS

METAPACKAGE

PACKAGE

Fig. 5.

m

m i m im m i

i

m

m

i i

i

x

*

CLASS

l

i i i

i

i m m

i

i

i i

x

i i i

Boom

i

i m i

i i m m m

i

i

i m

m i i

i i

i i i

i

i ii ii i i i m

METACLASS

i i i

i

1

i

i ii i

i m

i

i

i

m i i i i

i

i m

m

i

i i

i i

i

i i

mapping replace (EntityType new (METACLASS, NamespaceDeclaration)); ruleset add (AssociationRule new (METACLASS, METACLASS, CONTENTSDECLARATION));

x m i i

m

i

i i i

i i

i

i i i

i i

i

i i

i

m

i

i

i i m

i

i i

Boom

i

m i

i m

i i

i

i i

i Boom i

i

i

i

i mapping mapping ruleset ruleset

add add add add

(EntityType new (EntityType new (AssociationRule (AssociationRule

(ASSOCIATIONCLASS, AssociationDeclaration)); (LINKOBJECT, Instance)); new (ASSOCIATIONCLASS, DATATYPE, ATTRIBUTE)); new (ASSOCIATIONCLASS, CLASS, ASSOCIATIONEND));

1 CONTENTS− DECLARATION

METACLASS 1

ATTRIBUTE

* CLASS

ATTRIBUTE− LINK

CONTENTS *

Fig. 6. m

m

m

m l

l

*

*

ASSOCIATION− CLASS

LINKOBJECT

m

2..*

ASSOCIATION− END

*

LINKEND

m

l

l

m l

i

m

x m

im

i

i i i

Boom

ll

xi i

i 3.5

Other Meta-modelling Approaches m

i

Meta Object Facility i m m j m i i mm

MOF m

i i m

m

m

i

m

m

i

m i

m i

i m CDIF

i

i

m

i

m i

m

ii

m

m x

m

m

i

i

i m

j

i

m m i Entity-Relationshipm m im m i m i i m i i

Concluding Remarks i

m

Boom

i m

m

m i

j m

m

i

m

i

i

i m

i

i m m

i

i

i m

i

i

i

xi m

i i m m

xi i i m

m

i

im m

m

i

i i i

i

i

i

i

CASE Data Interchange Format i i i fl m m i Attribute m m m m m m m m i i i i i

m

m m i

m ii

m

4

i

i i

m

i i i m

m

i

i

x m

i m

m

i

m

i i

i im i

i m

m

m i j m

m i

i

Boom

i i

i

i m

m

i

i

¨

i

Boom

i

i

i

i

i

i i

i i

m

i

i

m

i i

i

m

m m

i

m m

m

i

i

m

i

i

i

x

i

i i j i

m i m

i

i

i i m i ii m m m i

i i

m i

i

j i j mi i

i

Boom

i mm

Boom

i

i x

j

Boom i

im i m

i

m

Boom

i

Boom

i

i m xi i i i i i m

i i Boom

m j m ii

ii

m i

i mi

i m

i

i i m

i

m i

i i

i

m

m

i ii

m

i m

i m i

i

m i

i fl xi x i

m

i

m

i

References Object-Oriented Design with Applications ¨

m l Computer Systems and Software Engineering. Proceedings of CompEuro’92 m l l l l EIA/IS-107: CDIF / Framework for Modeling and Extensibility ml l l mm ) l l Recommendation Z.100 (03/93) - CCITT specification and description language (SDL) ml m The Unified Software Development Process l ¨ Object-Oriented Software Engineering: A Use Case Driven Approach l l l m CONCUR’93: 4th International Conference on Concurrency Theory Lecture Notes in Computer Science 715 l

m l

m

ll

l l l l l Information and Computation Meta Object Facility (MOF) Specification m l m m { } m m m l m m OMG Unified Modeling Language Specification, version 1.3 m ¨ m l l l l m m m Proceedings PSMT’98 Workshop on Precise Semantics for Software Modeling Techniques ¨ ¨ m l ¨ m l ll l m Proceedings of UML’99 – The Unified Modeling Language: Beyond the Standard, Lecture Notes in Computer Science 1723 l ¨ lm m l l ll Proceedings of the Unified Modeling Language: UML’98: Beyond the Notation, Lecture Notes in Computer Science 1618 l The Corba Reference Guide : Understanding the Common Object Request Broker Architecture l l Working with Objects: The OOram Software Engineering Method l m l m l ObjectOriented Modeling and Design ll l l l ll Real-Time Object-Oriented Modeling l Object Orientation in Z l l

π

l

l

Information and Computation

Verification of Object Oriented Programs Using Class Invariants 

n

n

n

n l

n

n

l n [email protected] [email protected]

n

Abstract. n n n n l n n n n

n n n n n

n n n n

l

l

l l

n

n

l fl

n n n

l

1

n n

n

ll nn

n

n n n n

n

n n n n n

l

l

l n

ll

l

n

n

Introduction l

m l mm

y m

mm m l

l l l y l m m

m m m

m

m

m m

y m

m

m

m l l contract m

l l y

l

l l y m m

l y l

l

l

l l

l l l l

y l

l

l y m

l y m

l

m

m

l

y

l l

n

l



l l

n n k n

n

l

n k nn

n n

n

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 208–221, 2000. c Springer-Verlag Berlin Heidelberg 2000 

n

l l n

n n

n l

n

y m

l

n

n

m

l

n

l l

y

n

y y

l ll y

l l l

m

m

l l

m y

y reentrance

m m y vulnerability m

m m lm m y

l l call-back l

y

lm lm

m l

l

y l

m m

m

m

m

l

l lm

l

l l

l

l l

l

l

l

l y

l m m

ly

l

l

9

m m

l l y

l l m

l

l l y

m

m

2

Framework

2.1

Programming Language y l m

mm y

m

l

m l l l l

m l y

l m

l y y y l l y y

y

l

y y l

y

y

y

dynamic type m m l y y

l m y y

2.2

l

l l D C

m

m

m m

l y l l l

l y C

l y y

y l type safe y m l l l l

l

y

m m y

D

Object References l null

l null m l l

m m

l

l null

n

n

m m

y

l

l y

m l y

l m y

m l this l y l y

l l y m

l y

m m y

y

y o.x

y

m

y

l

A

y

y

m l y

m y m m y l l

< m B

l

y l l y

l y

l

m

fl m l y

y

m m m m

o

l l y

m

l y

new C()

C l

l

y

m

new

l l l

l y y

ly

y null

C

constructor l l m

l m

A< B m o

m m

y y

l null

l l

l y l l m y y ly m

l

l l l

l l

l

m

l

l y 2.3

Assertion Language l l m l

l y l l y y l y

l

l l

l l l l l y m y m

l m

y l

y

l l

this y

m y

m l

m

m

l

l m

l

l l

l y l

l l

y

l l y

l l

l y Definition: y o

null

P l o.P

y C o o.P P this/o l l y m this this

y

C

l null

n

2.4

n

n

l

n

n

Proof System m l

m l y

m y l y m

m mm

m

y

m

m l

l l m

m

l l

y

m

l l y

m l

y

l ll l

m

m l

l l lm l

m l l l y

– –

y m m

m yl begin

l l l

end

l m l l

m l m l

l l

new

m

C l l

l l l

pre void m(void) begin Q1 ... // code without method calls R1 o1 .method1(); Q2 . . . Rn−1 on−1 .methodn−1(); Qn ... // code without method calls Rn end post l loi .m

y m

m

Q1 l l

R1

Qn

y i l l local code segments m y y Rn m

y

Ri , Qi+1 Qi , Ri m y m

n

n

l l l l

l

ll l

l

l

Q1

this.pre Rn

this.post

y

Qi

Ri

Ri

Qi+1

Pi

y l l

l Qi Pi Ri y Ri o.m m l

m

m m m

l l m

l l

l

m m l

i

postm l l l

l

l y

l l

m

l llocal proof obligations

l l l

mm l l

l l prem prem

m

y

m

m l l y

2.5

m m

y

y Ri

i

Qi+1

i

m

l lo.m

m

postm

l

l

l Qi+1

i

m

m

m l

Proving Pre- and Postconditions for Methods m

m

Notation – – – – –

d o , s o o.m m o m m m mC D< C fl D

y m y m y m y m static y m l C o m D y C Cm l D< C

o m

o o

m

l l

s (o)

y

l

n

y

n

y mm l m m y l l l

l

m dynamic binding m y

n

l

n

n

l m

y y

y m

l ll o.m l y

m

l

l

l

m

m

l

m

m

l

l l y m

m

l

m 1

l y

l m

m

premD postmC

– premC – postmD m y

l l

o.preo:m o.m

m

o.posto:m

m

y l l

d

l

D< C

y

o

C

o.premC o.m y

y true o

m

y

m

m

y

m

l l new C

o.postmC

m d

o

C

d

o

C

m d

o

C o

o

m

y

m

l l

m y

l l

C l

m

y y

1

m

l

C

l l l l

m l

m ll

y

m l

l

n

l n

n

3

n

Class Invariants y l

m

l

m

ly m m

y

y l y

m m y mm

m l y

m m y

l l

invariants invariant l m ly m

m l

l

y

l l y l l m y

l

l m l

l

mm

m ly l

m

l l

o

l l y l

l m

IC l

ll y o

m m o.I

y

l l m

l true o.I

y l l class representation l l

y

l l y

y

y

y

m

m o.I

m

y o.P

m l C l y m

o P

l y

m l

m

y y

m l l y

Proof obligation: postMD postMC

IC preMC

D< C

ID

o.prem o.postm

o postm

preMD

l l Axioms: o.I

o I o prem

l

m l

l

l

l y

IC

l l y m

l l d

o.I

o

l y

C

m y

l l l C

y

m

C C C d o d o o.IC o.prem o.premC o.postm o.postmC

l l l

l

n

n

l m m

l l

l m l

m

n

l

n

n

m D

preMC

l l

m

l

preMD C l

l 3.1

Where Do Class Invariants Hold? l

m

l

y

l l l l

m l

l l

m

l l l

l l l l

l

l

m

l

l

l m

l y

l y

l

l l

l

l

Definition 1. A class invariant IC is l if it holds for all existing objects of type C during the following points of program execution: – at the beginning of any method execution, except for a new object at the beginning of the execution of its constructor – at the end of any method execution. 3.2

Proof Obligations for Class Invariants y

m

l l

l y y

l 3.3

l

m

l

Simple Case m l y m

y y l

l l

c m

l m

C

prem

y

true bodyc IC I bodym postm

IC

n

y

n

m m y m α

m l β

l l m n α

m

re-entrance l m m l y m α y m n

l l m

l l l

m

l m

l

l

l l

y

l

l l

mm y m

l m

l

l l

m

– assumption l lassume – obligation prove

y

y m

l m

y

y m

l l

l m

y m

m

m o l o l l forward-backward

pm y l l y

y l

p lm

m l l l l

y

Definition 2. When object reference o of type D occurs in invariant IC , we say that objects of class C are l l to (objects of ) class D. o is called the l ly . Given an execution state, an object α is m l l y l l to an object β if a change to β can invalidate the invariant of α. l l l l l 3.4

l

l

l

lm Referencing Vulnerable Objects l

l

l l

x

l IC x

m

l l

null x

C y l y null

ln l

l y

x > n.x l lm

l

l

m l

n

l l

n

n

l

l l

l

n

n

l

l

m l m l

m

lm

y

y l

l l l

l logical variables m l B

l y m l A

3.5

l l l

o

B

y

y m y

m

this X

X

m

m

y X.o

m y

null

A

y

Proof System m M l

m

l C

ly

l l

m

C

2

l l

l

y

l r1 . . . rk i n

p 1 , . . . , pm pre p1 .I . . . pm .I X1 .r1 this X1 null ... Xk .rk this Xk null Q1 M pi m y lthis Qi Pi Ri l l m Pi m l loi .Mi Ri oi .preMi l l Ri I Xj null l l y l ly rj Xj I Ri m l l q1 , . . . , qm Qi oi .postMi q1 .I . . . qm .I Rn post Remarks y

ad 1 m m

l

m

M l l y

ad 2 y m 2

M

n n

n

l y

y

Pi

m

l l n n

l n

C

n

B

l n

n

n

n B

n

n

ad 3 preMCi − preMDi m y l l oi m

ad 6

4

y

l

m

l l D< C oi m

oi postMi −

oi preM i postMDi − postMCi y m

Example m l

l

B

A

l

l l

ly B l Bm y l A l

l

A

A

l

y l l

B

−IA : x>ref.y− class A begin B ref; int x; end −IB : true− class B begin int y; void dec() begin −Q1 − y:=y-1; −R1 − end; void inc() begin −Q2 − y:=y+1; −R2 − end end

Q1

l y dec

l

IA

X.ref

this−X

null − y

l y

N − X.x > X.ref.y

X

l R1 X.x > N − y X.x > N l l X.ref.y this.y

inc

dec

N− m

N

m R1

X.x

mm l X.x > X.ref.y

m l y

n

n

R2 m l

l

5

n

l

n

n

X.I

Soundness and Completeness fly

m l l y m

m

l l l l

m true

m

l l m

m

y m

m

m

m l

m

Definition 3. An e of program P is a terminating transition sequence ln l1 σ0 − . . . − σn where the σi denote program states and each label li either denotes 1. a local tranisition, i.e., a sequence of local steps, corresponding to a local code segment, not involving method calls or object creation; which local transitions are allowed is defined by the semantics of the programming language that is used and is not of interest here; 2. or a method call o.m ; 3. or a return transition, corresponding to the termination of a method; which method is terminated is determined by the balance of calls and returns in the previous part of the execution sequence. l y

y

l

m

m

l null

l

l l

ll

m

y

Q P R m y R l l e m e l

m l l

P

l l m P y Q

l ll

y l l σ σ

l l ll l

Theorem 1 (Soundness). Let a program be given with all proof obligations satisfied and an execution sequence with all class invariants holding in σ0 . Then all class invariants hold for all objects at all states σi in the transition sequence. Proof

m m

l l

σi

e

i

y l ll m

l l i>

e

l

l

σ0 −1 . . . −n σn

m i

l

m y

n

li Qj σi−1

n

Pj y l l α l Rj σi α.ID D C α.ID σi−1 α σi−1 α σi this σi α.IC σi D l l C r y m Rj σi R X null X I X l l l m l y l l X α α l Rj σi α.I σi m li m l loj .Mj σi−1 σi l l m m l l l l σi σi y oi .preMj σi−1 y m y Rj σi−1 l l m l l pre σi l y pk l m pk .I Xk .rk this Xk null l y Xk Q1 σi li l l l m Qj σi l l y l l l this σi−1

l

C

m

y

m

D σi l l X null

m

l

end of proof l l

m m y

l

y

l

Theorem 2 (Completeness). Let a program be given of which all executions satisfy at method calls the corresponding preconditions and at both calls and returns all class invariants. Then there exists an annotation of the program and the classes such that all proof obligations are fulfilled. m

l l l

m y ll l

l m l

m l

y

m

l

y y m l y

y

l

m

l

y mm l

6

l m y

m l l

l y

l

m y

m

m

m

Conclusion l

l

ly m

l

l

m l

n

l l y

n

y

n

l

n

n

y

l l l l m

m ly

l y y

l

l

m

References n

n

A Logic of Object-Oriented Programs n n n A Parallel Object-Oriented Language: Design and semantic foundations n n

n l n

n

ln

The Java programming language, 2nd ed.

l

n rent programs

l Verification of sequential and concurn l Reasoning about dynamically evolving process structures: A proof theory for the parallel object-oriented language POOL n n l n n Reasoning about Classes in Object-Oriented Languages: Logical Models Tools n n l An axiomatic basis for computer programming n n nk Upgrading the pre- and postcondition technique n l l n n l n n Toward Reliable Modular Programs l n n n l n k n n A behavioral notion of subtyping nn n n l The Temporal Logic of Reactive and Concurrent Systems n l Object-Oriented Software Construction n ll

n ¨ll Logical foundations for typed object-oriented languages n n n n n Specification and verification of object-oriented programs l n n n k Component software : Beyond object-oriented programming n l l The Object Constraint Language n l

Verification of Object-Z Specifications by Using Transition Systems: Application to the Radiomobile Network Design Problem Pabl o Gruer, Vincent Hil aire, and Abder Koukam Universit´e de Technologie de Belfort Montb´eliard 4 rue du chˆ ateau 90010 Belfort Cedex, FRANCE [email protected]

Abstract. This paper presents a technique for verifying specifications which uses the object-oriented state-based language Object-Z. The technique is based upon translation of Object-Z specifications into transition systems. The translation of Object-Z into a transition system allows one to use established techniques and tools in order to verify the specifications. We present the basis of our translation approach and then illustrate it by a case study. The case study consists in proving properties of our antennae parameter setting problem specification.

1

Introduction

Formalspecificat ion must ful fil ltwo rol es. The first is t o provide t he underl y ing rat ional e for t he sy st em under devel opment . The second is t o guide subsequent design and impl ement at ion phases. For exampl e, t he modelchecking approach a rel at ed t o t he specificat ion. Furmay be very usefulin order t o verify a formul t hermore t his verificat ion can be carried out aut omat ical l y using modelchecking t ool s. Whil e most specificat ion formal isms are suit ed for t he first rol e, few enabl e aut omat ic verificat ion of sy st ems propert ies. e at t ent ion. FurAmong specificat ion formal isms, Z [7] has received considerabl t hermore, t here exist object orient ed ext ensions of t his formal ism, such as Object Z [1], which al l ow for cl ass st ruct ured specificat ions. These formal isms are wel l suit ed for concise and comprehensibl e descript ion of software but aut omat ic anal y sis t ool s are very rare, and oft en rest rict t o sy nt act ic checking. Our approach consist s in t ransl at ing an Object specificat ion t owards a t ransit ion sy st em. Transit ion sy st ems are behavioralmodel s of software sy st ems which can provide an operat ionalsemant ic t o specificat ions. Moreover, wit h t ransit ion sy st ems, one can use est abl ished t echniques [5] and t ool s, such as STeP [4], in order t o prove some propert ies of Object -Z specificat ions. Nevert hel ess, defining t t ask. The richness of t he an operat ionalsemant ics for Object -Z is a difficul specificat ion l anguage, t hat benefit s from t he first order predicat e not at ion, is one of t he reasons of t he difficul ty . For inst ance, operat ions described by quant ified predicat es oft en produce a set of t ransit ions rat her t han a singl e t ransit ion. T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 222–236, 2000. c Springer-Verlag Berlin Heidelberg 2000 

Verification of Object-Z Specifications by Using Transition Systems

223

Yet , t he set of t ransit ions represent s an at omic operat ion and, in order for t he semant ic t o be correct , t his at omicity must be preserved in some fashion. This paper present s a verificat ion t echnique based on t ransl at ion rul es of Object Z specificat ions int o t ransit ion sy st ems. Rat her t han an exhaust ive present at ion of t he t ransformat ion rul es, we address some difficul t ies t hat originat e in t he richness of t he specificat ion l anguage. We do not present a formalt reat ment of y, t his quest ion in t his paper, but il l ust rat e it wit h t he case st udy . Consequent l t his work shoul d be considered as t he resul t of an experience on verificat ion of Object -Z specificat ions by means of t ransit ion sy st ems, wit h STeP as t he verificat ion t ool . The generalorganizat ion of t his paper is as fol l ows. Sect ion 2 int roduces Object -Z and t ransit ion sy st ems. Sect ion 3 present s t he main idea of t he verificat ion t echnique, i.e., t ransforming an Object -Z cl ass int o a t ransit ion sy st em. Sect ion 4 present s t he ant enna paramet er set t ing probl em, it s specil y sect ion 5 ficat ion and it s verificat ion wit h t he STeP environment . Event ual concl udes wit h an out l ine of fut ure research.

2 2.1

Basic Concepts Object-Z

Object -Z [1] is a formalspecificat ion l anguage which ext ends Z [7] by int roducing object -orient at ion. Bot h are based upon set t heory and first order predicat e l ogic. Specificat ion writ t en in t hose l anguages incl ude two part s: t he sy st em st at e and operat ions on st at es. Operat ions are const rained by pre and post condit ions. Specificat ion of an operat ion is encl osed in a definit ion scope cal l ed schema. Object -Z al l ows t o group port ions of t he st at e and rel at ed operat ions in a cl ass schema. It al l ows modul arity , composit ion and inherit ance. We propose an exampl e of an Object -Z cl ass based upon t he “heap of matches” game. Two pl ay ers, ident ified as pl ay er 0 and pl ay er 1, al t ernat e in t aking mat ches from a heap. The pl ay er whose t urn has arrived decides whet her he t akes one, two or t hree mat ches. The pl ay er who t akes t he l ast mat ch is t he game’s l ooser. The Object -Z descript ion of t he game cl ass is t he fol l owing: Game heap : N turn : [0 ..1] INIT heap = 46 turn = 0

224

Pablo Gruer, Vincent Hilaire, and Abder Koukam

Move Δ(heap, turn) take? : [1..3] heap take? heap = heap − take? turn = 1 − turn

2((turn = 0 ) − (turn = 1)) 2((turn = 1) − (turn = 0 )) Variabl es heap and turn specify respect ivel y t he number of mat ches in t he heap and t he current pl ay er ident ity . St at es are seen as bindings of modelvariabl es t o val ues: t he st at e of an object of t he Game cl ass is det ermined by t he val ue bound t o variabl es heap and turn. Al lObject − Z cl asses incl ude a schema ass. The Move schema named INIT t o specify t he set of init ialst at es of t he cl specifies t he cl ass operat ion, a game move, and il l ust rat es some not at ionalconvent ions of Object − Z . The Δ st at ement indicat es t he port ion of t he st at e t hat is modified by t he operat ion. Schemas t hat define operat ions are spl it t ed in two zones by a short horizont all ine. The upper zone specifies t he port ion of st at e invol ved in t he operat ion and t he operat ion paramet ers. The l ower zone is occupied by predicat es t hat express operat ion condit ions. Anot her not at ional convent ion refers t o t he so-cal l ed before/after predicat es. Primed variabl e names ue t o which t he variabl e is bound aft er t he operat ion, unprimed denot e t he val variabl e names denot e t he val ue t o which t he variabl e was bound before t he operat ion. Consequent l y , predicat es wit hout primed variabl es can be seen as operat ion precondit ions and predicat es wit h mixed primed and unprimed variabl es describe t he effect of t he operat ion on t he st at e (i.e., t he variabl e binding). Final l y , a variabl e name fol l owed by t he quest ion mark (?) dist inguishes an operat ion’s input paramet er and a variabl e name fol l owed by t he excl amat ion mark (!) dist inguishes an operat ion’s out put paramet er. As for operat ion schemat a, t he cl ass schema can be separat ed in two zones by a short horizont all ine. The l ower zone, if present , incl udes one or more t emporall ogic formul as, t he hist ory ow t o express invariant s. As we wil lexamine in t he sequel , hist ory invariant s al l l iveness and safety const raint s on t he comput at ions an object of t he cl ass can undergo, see [6] for a discussion on Object − Z cl asses and hist ory invariant s. In our exampl e, t he given invariant s st at e t hat game pl ay ers shoul d al t ernat e in execut ing game moves. From t he given specificat ion of Move operat ion, t his const raint is sat isfied by al lt he possibl e comput at ions of any inst ance of t he game and t he hist ory invariant s coul d be omit t ed. 2.2

Transition Systems

We int end t o use t ransit ion sy st ems t o provide a semant ics t o cl asses of Object − ass is t he set of compuZ . The int ended meaning or “ty pe” of an Object -Z cl

Verification of Object-Z Specifications by Using Transition Systems

225

t at ions t hat object s of t he cl ass can undergo. A t ransit ion sy st em is a compact represent at ion of a set of comput at ions and t herefore appears as an adequat e represent at ion for t he semant ics of an Object -Z cl ass. Furt hermore, a number s of verificat ion t echniques have been defined t o check t ransit ion sy st em model against t emporall ogic formul as. udes a set − of ty ped variabl es, A t ransit ion sy st em S =< −, Σ, −e , −c , Θ > incl ement ary t ransit ions, a set −c of compound t rana set Σ of st at es, a set −e of el sit ions and an init ialcondit ions Θ. Variabl es − = −i − −o − −p group in t hree lcommon cl asses: input (−i ), out put (−o ) and privat e (−p ). We assume t hat al ty pes and most of t he cl assicalty pe const ruct ors are avail abl e, as it is t he case for STeP. A st at e s − Σ is a val uat ion of t he privat e variabl es. As for Z specificat ions, t he st at e is det ermined by t he val ue t o which each variabl e is bound. e, we wil lnot e s[v ] t he val ue bound t o v in st at e s. Nat uIf v − −p is a variabl ral l y , st at e s considered as a val uat ion funct ion can be induct ivel y ext ended t o expressions of any kind. Part icul arl y t he init ialcondit ion Θ is a predicat e such y if s0 [Θ] = t rue. We say t hat s0 sat isfies Θ, t hat , s0 is an init ialst at e if and onl which is not ed s0 Θ. y t he el ement ary and t he compound t ranThe set s −e and −c cont ain respect ivel sit ions. Bot h represent st at e changes, i.e., funct ions of t he kind: Σ − P Σ. aGeneral l y , an el ement ary t ransit ion τ − −e is described by it s t ransit ion rel t ion ρτ , i.e., a conjunct ion of predicat es. As for t he Z not at ion, we adopt t he before/after convent ion t o writ e t hose predicat es. Among many possibl e general forms for a t ransit ion rel at ion, we adopt t he fol l owing: ρτ = Pre(τ ) − (v1 = Exp1 ) − −−−− (vn = Expn ) where Pre(τ ), a predicat e wit h onl y unprimed variabl es, is t he t ransit ion’s precondit ion: s is a source st at e for τ if and onl y if s Pre(τ ). For each conjoint es. (vi = Expi ), vi − −p − −o and Expi is an expression wit hout primed variabl es which change val ue as a The set −v1 , −−−, vn −− −p −−o is t he subset of variabl consequence of t he t ransit ion t riggering. Final l y , in t he case of el ement ary t ransit ions, unl ess ot herwise st at ed, we assume t hat for each v − −v1 , −−−, vn −, t here is an unwrit t en conjoint (v = v ), meaning t hat variabl es t hat do not appear in ρ(τ ) are supposed t o be l eft unchanged by t he t ransit ion. Compound t ransit ions are subset s of el ement ary t ransit ions not ed [τ1 ; −−−; τn ]. Compound t ransit ions shoul d be considered as at omic: component s of compound t ransit ions do not int erl eave wit h ot her t ransit ions of S . We int roduce compound lbe t ransit ions t o account for t he at omicity of Object -Z cl ass operat ions, as wil es of t ransit ion seen in sect ion 3.1. We not e − (ρτ ) t he set of primed variabl y if: rel at ion ρτ . A compound t ransit ion [τ1 ; −−−; τn ] is coherent if and onl = j − − (ρτi ) − − (ρτj ) = ? −τi , τj − [τ1 , −−−, τn ] −i −

A comput at ion of t ransit ion sy st em S =< −, Σ, −e , −c , Θ > is a sequence σ : s0 , s1 , −−−, sj , −−− east one of t he fol l owing of st at es such t hat s0 Θ and for every si , i − 0 , at l possibil it ies is verified:

226

Pablo Gruer, Vincent Hilaire, and Abder Koukam

−There is a τ − −e such t hat si Pre(τ ) and si+1 − τ (si ). −There is a coherent compound t ransit ion [τ1 ; −−−; τn ] − −c t hat verifies what e −be t he set of component s of τc enabl ed in si (i.e., fol l ows. Let E = −τ1e , −−−, τm e e − ? and si+1 − τ1e (si ) − −−−− τm (si ). for al lj , si Pre(τj )), t hen E = We not e C(S ) t he set of al lcomput at ions of t ransit ion sy st em S .

3 3.1

Verification Technique From Object-Z Classes to Transition Systems

A cl ass specificat ion writ t en in Object -Z can bee seen as t he descript ion of an abst ract machine. Object s of t he cl ass are inst ances capabl e of producing comput at ions of t he machine, as sequences of st at e changes caused by operat ions. The aim of t he proposed t ransformat ion is t o obt ain, from t he definit ion of t he cl ass, writ t en in Object -Z, a compact represent at ion of t he set of comput at ions an object of t he cl ass can produce. This represent at ion is int ended t o t ake t he form of a t ransit ion sy st em. The int ended resul t of t he t ransformat ion is a t ripl e (S , A , −) where S =< −, Σ, −e , −c , Θ > is a t ransit ion sy st em as defined in sect ion 2 .2 , A and − are set s of l inear t emporall ogic (LTL) formul as cal l ed respect ivel y axioms and hist ory invariant s. A simpl e Object-Z cl ass definit ion has t he fol l owing el ement s: ClassName type definitions constant definitions state schema initial state schema operations history invariants An Object-Z cl ass named cl is charact erized by t he fol l owing set s. Attr (cl ) is a set of cl ass at t ribut es, decl ared in t he state schema, Param(cl ) is a set of operat ion paramet ers. Bot h are subset s of a set of ident ifiers such t hat Attr (cl )− Param(cl ) = ?. State(cl ) − Attr (cl ) −− − Val is t he set of cl ass st at es, a subset of t he finit e part ialfunct ions from at t ribut es t o val ues. The set Val cont ains al lpossibl e val ues of at t ribut es of any ty pe. Final l y , Op(cl ) is t he set of cl ass operat ions. We int roduce t he auxil iary funct ions πi : Op(cl ) − P Param(cl ) and πo : Op(cl ) − P Param(cl ) t hat give respect ively t he set of input and out put paramet ers of an operat ion. We expl ain now t he t ransl at ion of a simpl e Object-Z cl ass named cl t owards l ust rat e it a model(S cl , A cl , − cl ), wit h S cl =< −cl , Σ cl , −ecl , −ccl , Θc l > and il wit h t he heap of matches game. We st at e t hat :



πi (o), −ocl = πo (o) −pcl = Attr (cl ), −icl = o Op(cl)

o Op(cl)

Verification of Object-Z Specifications by Using Transition Systems

227

so t hat , for t he Game cl ass we have −pGame = −heap, turn−, −iGame = −take?− Game = ?. and −o ares at t ribut es St at e schema of t he form [declaration part −Ax1 ; −−−; Axn ] decl and, opt ional l y , st at es a l ist of axioms rel at ive t o decl ared at t ribut es. Axioms araAx1 , −−−, Axn are first order predicat es on t he at t ribut es defined in t he decl t ion part . We st at e t hat : A

cl

= −Ax1 , −−−, Axn −

The generalform of t he init ialst at e schema is INIT =  [Pr1 ; −−−; Prm ] where ass at t ribut es. We st at e t he Pri (i − [1..m]) are first order predicat es on t he cl t hat : Θcl = Pr1 − −−−− Prm so t hat , for t he Game cl ass we have ΘGame = (heap = 46) − (turn = 0 ). The cl ass operat ions OperationName =  [declaration part −predicate list] are t he port ion of t he specificat ion which is t ransl at ed t owards t he t ransit ions of S cl . In many cases, an operat ion gives rise t o a set of el ement ary t ransit ions. Let ement ary t ransit ions resul t ing from operat ion −o = −τ1 , −−−, τi −be t he set of el o − Op(cl ). We dist inguish t he fol l owing cases: et on (i.e., −o = −τ −), t hen τ − −ecl . −if − o is a singl et τc = [τ1 ; −−−; τn ] − −ccl , provided −if −o = −τ1 , −−−, τn −, wit h n > 1 t hen l t hat τc is coherent . Given t he richness of t he Object -Z l anguage, a det ail ed definit ion of al lt he t ransl at ion rul es from operat ions int o t ransit ions is a difficul t t ask. We wil l il l ust rat e some aspect s of t he t ransl at ion principl es t hrough t he Game exampl e and al so t hrough t he case st udy . Operat ion Move of t he Game cl ass gives rise t o l ows. The predicat e wit h unprimed at t ribut es det ermines t ransit ion τ Move as fol t he precondit ion: Pre(τ Move ) = (heap − take?). The predicat es wit h mixed unprimed and primed at t ribut es det ermine t he rest of t he t ransit ion rel at ion. In t he case of t he Game exampl e, t he t ransit ion rel at ion is st raight forward: ρτ Move = (heap − take?) − (heap = heap − take?) − (turn = 1 − turn) and we have: −Game = − Move = −τ Move −. Final l y , t he history invariants part of t he cl ass specificat ion cont ains a l ist of LTL formul as H1 , −−−, Hp . We st at e: − cl = −H1 , −−−, Hp −

2

2

So t hat we have − Game = − ((turn = 0 ) − (turn = 1)), ((turn = 1) − (turn = 0 ))−. Operat ions t hat t ransl at e t o compound t ransit ions are ty pical l y t hose which are specified by quant ified formul as. In t he case st udy we present rul es t o obt ain compound t ransit ions from operat ion specificat ions in which varis of nat uralint egers. abl es bound by quant ifiers have finit e ty pes, such as int erval

228

3.2

Pablo Gruer, Vincent Hilaire, and Abder Koukam

Validity, Satisfiability, and Consistency

We present now t he meaning of set s A and − t hat have been int roduced in sect ion 3.1. We use t he fact t hat comput at ions of t ransit ion sy st ems can be model s of LTL formul as. Mat hemat icall ogic gives a precise meaning t o t he word model, by defining t he sat isfact ion rel at ion between “universe of discourse” ent it ies as. Let us begin by a quick remind of LTL formul as (model s) and l ogic formul and t heir sat isfact ion rel at ion. LTL ext ends predicat e cal cul us wit h new l ogicaloperat ors such as , −, , , l -formed formul as so are cal l ed t he t emporaloperat ors. If F1 and F2 are wel F1 , F1 −F2 , F1 and F1 . St at e formul as are formul as wit hout t emporal operat ors. St at e-quant ified formul as are formul as such t hat t emporaloperat ors do not appear in t he scope of quant ifiers. es are The nat uralmodelfor LTL formul as on a set V = −v1 , −−−, vn −of variabl t he so cal l ed Chains, i.e., sequences of val uat ions of V not ed:

2

2 3

3

σ : s0 , −−−, sj , −−− wit h, for al lj , sj : V − Dom(V ), where Dom(V ) denot es t he domain where al lvariabl es of V t ake t heir val ues. We not e s[v ] t he val ue of variabl e v −V l ows. If F is a st at e in st at e s. The sat isfact ion rel at ion ( ) is defined as fol y if sj F formul a, t hen (σ, j ) F , i.e σ sat isfies F at posit ion j , if and onl as, t he rel at ion is defined (i.e., sj [F ] = t rue). If F1 and F2 are t emporalformul y if (σ, j + 1) F1 ; (σ, j ) F1 −F2 if and induct ivel y : (σ, j ) F1 if and onl li such t hat j ≤ i < k , onl y if t here exist s k − j such t hat (σ, k ) F2 and for al F1 if and onl y if (σ, j ) t rue −F1 ; (σ, j ) F1 if and onl y (σ, i) F1 ; (σ, j ) a F is not ed if (σ, j ) − − F1 . The set of chains t hat sat isfy an LTL formul Sat (F ). Given an Object-Z cl ass cl and it s associat ed semant ic ent ity (S cl , A cl , − cl ), t he cl = −A1 , −−−, Am −of axioms defines t he st at e space of cl as t he set : set A

3

3

2

−s − Σ cl −s

A1 − −−−− Am −

In ot her words, t he axioms rest rict t he set Σ cl of st at es of t he t ransit ion sy st em id. in order t o ensure t hat A cl is val To define t he meaning of t he hist ory invariant set , l et us remind sect ion 2 .2 , where we defined t he set C(S ) of comput at ions of a t ransit ion sy st em. We st at e t hat S cl is consist ent , wit h t he set − cl = −H1 , −−−Hn − of hist ory invariant s if = ?. In ot her words, − cl is expect ed t o be sat isfiabl e Sat (H1 − −−−− Hn )−C(S cl ) − cl rel at ivel y to S .

4 4.1

Case Study The Radio-Mobile Network Example

In order t o il l ust rat e t he specificat ion and verificat ion approach, we choose an exampl e from t he Radio-Mobil e Network (RMN) design probl em. Radio-mobil e

Verification of Object-Z Specifications by Using Transition Systems

229

Fig. 1. Ant enna paramet er set t ing probl em

communicat ion rel ies on a network of ant ennae t o cover a given area of t errit ory , in order t o ensure communicat ion services such as mobil e phones. The design of a RMN incl udes t hree main st ages: ant ennae posit ioning, paramet er set t ing and frequency al l ocat ion. We are concerned here wit h t he paramet er set t ing st age: once t he ant ennae l ocat ions have been det ermined in t he posit ioning st age, t he paramet er set t ing probl em deal s wit h t he issue of Qual ity of Service (QoS) opt imizat ion. The ant enna em has y et been present ed. Indeed, [3] gives an impl ement ed paramet er probl sol ut ion t o t he probl em, and in [2 ] we specify t he probl em and we simul at e t he specificat ion. For each ant enna, t hree paramet ers need general l y t o be adjust ed: emission udes severalaspect s, such as power, t il t and azimut h. On t he ot her hand, QoS incl coverage, t raffic, int erference and handover. To opt imize QoS, a t rade-off must be found. For inst ance, coverage and handover ask for higher emission power whil e int erference avoidance asks for l esser radio energy . ve t he paramet er set t ing probl em, t he area t o cover is part it ioned In order t o sol int o a set of meshes whose size vary from 2 5 t o 10 0 square met ers, depending on t he ty pe of l and, as il l ust rat ed by figure 1, which resumes t he paramet ers set t ing probl em. For t he sake of cl arity , we rest rict our exampl e t o t he of emission power set t ing probl em, of which we present now a formaldescript ion. Given a set A = l ow−a1 , −−−, an − of ant ennae and a set M = −m1 , −−−, mk − of meshes, t he fol ing funct ions define t he radio-propagat ion upon t he considered area. Funct ion l ows t o cal cul at e t he mesh-l ocalvariat ion of t he fiel d Fade : M − A − R al ect ric emit t ed by each ant enna. Funct ion Power : A − R gives t he radio-el l ows t o cal cuemission power of each ant enna. Funct ion F : M − A − R al l at e t he fiel d int ensity in any mesh, due t o each ant enna emission. As a mat t er

230

Pablo Gruer, Vincent Hilaire, and Abder Koukam

of fact , for mesh mi and ant enna aj , t he fiel d int ensity can be cal cul at ed as e F (mi , aj ) = f (Fade(mi , aj ), Power (aj )), for a given funct ion f . In t his exampl we assume t hat f is simpl y t he product between emission power and at t enuat ion: F (mi , aj ) = Fade(mi , aj ) −Power (aj )

4.2

Specification

The specificat ion of t he ant ennae paramet er set t ing probl em is st ruct ured in t hree cl asses. The first specifies t he t errain upon which ant ennae are sit uat ed, t he second specifies an ant ennae and t he l at t er specifies t he sy st em as a whol e. We suppose t hat ant ennae and meshes numbers are fixed and known. They are owing schema. specified by t he fol l Ty pes MESHID and ANTENNAID al l ow t o ident ify each mesh and each ant enna. Const ant funct ion Fade gives, for each ant enna, t he fiel d at t enuat ion in any mesh and t hereby al l ows t o cal cul at e fiel d int ensity in any mesh, due t o evel s, as any ant enna. We adopt t he view of ident ify ing discret e emission power l defined by ty pe POWERLEVEL. The onl y st at e variabl e is Field which, for any mesh, gives a fiel d int ensity vect or indexed by t he set of ant ennae ident ifiers, t he cont ribut ion of each ant enna t o t he mesh’s fiel d. Operat ion ChangeField al l ow t o cal cul at e t he cont ribut ion of an ant enna t o t he fiel d aft er a change in ant enna’s emission power. Operat ion MeasureField ret urns, for a given ant enna, t he fiel d it cont ribut es t o any mesh. Operat ion DetectInterference ret urns, for a given ant enna, t he indicat ion of whet her it int erferes anot her ant enna in any mesh. Terrain n:N k :N

[• • • • •• • • • • ••• • • •] [• • • • •• • • • ••• ••]

n k ) − (index = 0 ) − (lock = FREE ) We used t he STeP model -checker t o verify t he sat isfiabil ity of t he hist ory invariant s of cl ass CommunicationSystem, on a simpl e communicat ion sy st em composed of two ant ennae and t en meshes. The STeP model -checker proves or refut es val idity of LTL formul as rel at ivel y t o a t ransit ion sy st em. t o est abity of hist ory invariant H one must act ual l y est abl ish t hat l ish t he sat isfiabil − H is not val id. Concerning our case st udy , we checked separat el y each one of t he t hree t emporalformul as of cl ass CommunicationSystem. For inst ance, t he sat isfiabil ity of t he first formul a was checked by est abl ishing t hat formul a id. − − ((op = SetAllPowers) − (op = SetField )) was not val We first verified some propert ies of separat ed cl asses. For t he Antenna cl ass, we verified t he sat isfiabil ity of formul a F1 = (Coverage − Covmin ) wit h Covmin being a minimalnumber of covered meshes. This property represent s t he possibil ity of an import ant resul t t o be obt ained, i.e., an ant enna covering at l east a minimalnumber of meshes. As al ready ment ioned, t he STeP model -checker proves or refut es val idity of LTL formul as rel at ivel y t o a t ransit ion sy st em. Consequent l y , STeP was asked t o verify formul a (Coverage < Covmin ). A count erexampl e was rapidl y est abl ished by STeP. The number of st at es visit ed by t he

3

3

2

236

Pablo Gruer, Vincent Hilaire, and Abder Koukam

model -checker was 48. Next we verified a safety property , expressed by formul a F2 = ((Coverage ≤ k ) − (EmmissionPower < 10 0 )), t o mean t hat even when al lmeshes are covered by an ant enna, t he maximalpower l evelis not exceded. This property was refut ed by STeP wit h a count erexampl e, t hereby mot ivat ing a change in t he Antenna specificat ion. The modified version sat isfied F2 , but verify ing t his formul a t ook considerabl e amount s of t ime, visit ing more t han 2 0 0 0 0 0 st at es.

2

5

Conclusion

Formal isms l ike Z and Object -Z incl ude in a unique specificat ion l anguage two import ant concept ualdomains. On one side, by adopt ing t he first order predicat e not at ion, t hey bel ong t o t he specify with logic real m. On t he ot her side, as t hey describe sy st em st at e and operat ions on st at es, Object -Z al so rel at es t o es of specificat ion. In t his work on verificat ion of Object more operat ionalsty l Z specificat ions we propose some rul es t o t ransform an Object -Z cl ass int o a t ransit ion sy st em, in order t o use verificat ion t ool s such as t he STeP environes, we present t he approach by appl y ing it t o a ment . Rat her t han generalrul case-st udy . The proposed informalrul es t ransform operat ions of t he cl ass in set s of simpl e t ransit ions grouped in indivisibl e compound t ransit ions t o represent d concent rat e on a bet t er underoperat ions of t he cl ass. Fut ure research shoul st anding of probl ems rel at ed t o t he t ransformat ions from Object -Z operat ions t owards compound t ransit ions, t hat preserve! t he propert ies of operat ions exldefined pressed wit h first order predicat es. Formalpresent at ion of a set of wel t ransformat ion rul es is al so necessary t o consol idat e t he approach.

References 1. Roger Duke, Paul King, Gordon Rose, and Graeme Smith. The • bject-• specification language. Technical report, Software Verification Research Center, Department of Computer Science, University of Queensland, AUSTRALIA, 1991. 2. V. Hilaire, T. Lissajoux, and A. Koukam. • • • • • • • • • • • • • • • • • • • • •• • • • • • • • • • • • • • •• ••• • • • • • • • • • • • . In International Conference on Advanced Computer Systems ACS’98, 1998. 3. T. Lissajoux, V. Hilaire, A. Koukam, and A. Caminada. Genetic algorithms as prototyping tools for multi-agent systems: Application to the antenna parameter setting problem. In Springer Verlag, editor, Lecture Note in Artificial Intelligence, number 1437 in LNAI, 1998. 4. Z. Manna, N. Bjoerner, A. Browne, and E. Chang. STeP: The Stanford Temporal Prover. Lecture Notes in Computer Science, 915:793–??, 1995. 5. Zohar Manna and Amir Pnueli. Temporal Verification of Reactive Systems: Safety. Springer, 1995. 6. Graeme Paul Smith. An Object-Oriented Approach To Formal Specification. PhD thesis, University of Queensland, 1992. 7. J. M. Spivey. The Z Notation: A Reference Manual. Prentice Hall, 1992.

A Model for Describing Object-Oriented Systems from Multiple Perspectives Torsten Nelson, Donald Cowan, and Paulo Alencar Computer Systems Group, University of Waterloo {torsten,dcowan,alencar}@csg.uwaterloo.ca

Abstract. We present work on a formal model for the composition of objectoriented modules, or hyperslices, which represent different perspectives on the system being built. With the model, we should be able to study existing approaches such as subject-oriented programming, as well as extend other objectoriented languages, such as the UML, to accommodate the use of hyperslices. We show here a sample of the specification language that accompanies the formal model, and a small example of its use.

1 Introduction The idea of dividing a system description into various perspectives, each of which portrays some aspect of the system, has been the topic of recent intensive research. Techniques such as subject-oriented programming [9] and aspect-oriented programming [14] explore the possibilities of having multiple representations of the same entity from the problem domain. The need arises for a formal model that brings together what is common about the various multiple-perspective methods, particularly within the objectoriented paradigm. Such a model would allow for strengthening of existing techniques with the possibility for formal proofs and consistency checks, and serve as the basis for extending popular design and implementation languages with multiple-perspective capabilities. This work attempts to fill this gap. In section 2 we discuss the need for multiple-perspective decomposition and present its different categories. We then discuss issues related to multiple-perspective decomposition restricted to the object-oriented paradigm in section 3. Section 4 shows the proposed model, followed by a small example of its use in section 5.

2 Multiple-Perspective Decomposition One of the most widely accepted tenets of software development is the fact that complex problems must be divided into smaller parts that are easier to understand and work with. Traditional approaches to modeling such as structured analysis and object orientation take a top-down approach, where a system is decomposed into several parts, each of which is again decomposed until each part is simple and cohesive. The parts are then implemented independently and composed to form the desired software system. The exact nature of the entities that form each part varies between approaches, but typically T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 237–248, 2000. c Springer-Verlag Berlin Heidelberg 2000 

238

Torsten Nelson, Donald Cowan, and Paulo Alencar

each unit of the decomposition is encapsulated in a procedure (functional decomposition), module, or class (object decomposition). It is common to think of each of these units as pieces in a larger puzzle, all of which fit together to form the solution. Recently, new approaches to problem decomposition have been the subject of research. It is often useful to view the entire problem from a single perspective, discarding all the problem elements that are not relevant to the perspective, and thereby reducing problem complexity. The problem then becomes easier to understand and manage than when viewed in its entirety. In contrast to the top-down approach for functional decomposition mentioned in the previous paragraph, each perspective can be thought of as a glass sheet with some aspect of a painting: one sheet may have a black outline of the painting; another, its colors; others may have shadings, textures, and so on. Superimposing all glass sheets forms the complete painting. What distinguishes this “multiple-perspective” decomposition from other forms of divide-and-conquer is the fact that the decomposed parts are not disjoint. In other approaches to decomposition, any entity from the problem domain appears in only one of the pieces after decomposition - no entity appears in more than one piece. By contrast, an entity may appear in any number of perspectives, and its definition can be different in each perspective. We frame our concept of perspective in software engineering rather broadly using the following two definitions. – A description of a software system has multiple perspectives if it is explicitly divided into two or more partial descriptions, and there are entities from the problem domain that appear in more than one partial description. – A method uses multiple perspectives if it enforces the description of software with multiple perspectives and provides rules governing how perspectives are related to one another. These definitions allow a wide variety of methods to be thought of as using multiple perspectives. We divide them into three categories according to the kind of partial description used: architectural, domain-specific, and user-defined perspectives. Our research focuses on methods that allow user-defined perspectives. In order to clarify the relationships among the proposed models, we discuss the three categories of multipleperspective methods. 2.1 Architectural Perspectives Structured analysis methods such as the one proposed by Gane and Sarson [8] use two different diagrams to describe a system: a module hierarchy chart describing the division of the system into modules, and a data flow diagram describing how data was transferred between the modules. Each diagram represents a partial description of the system, and contains representations of the same entities from the problem domain, and therefore fit our definition of a perspective. Modern object-oriented analysis and design methods such as the Object Modeling Technique (OMT) [18], Coad and Yourdon [5], UML [3], and others, all use different perspectives to describe a software system. However, in all of the above, the perspectives are defined by the method and reflect different modeling or descriptive capabilities. For instance, a model may define

A Model for Describing Object-Oriented Systems from Multiple Perspectives

239

structural relationships between entities, such as containment or association, while another may define behavioral aspects of each entity. Each perspective is usually described using a different language. This kind of description is often called an architectural perspective since each represents a certain aspect of the system’s architecture. An important characteristic of architectural perspective decomposition is that it is independent of the problem domain. Dividing a problem into structural and behavioral views tells you nothing about the problem itself [13]. 2.2 Domain-Specific Perspectives There are other methods that allow the use of predefined perspectives, but instead of reflecting architectural aspects, the perspectives represent aspects of a specific problem domain. An example of this kind of method is the ISO standard for Open Distributed Processing (ODP) [11], which is geared towards the description of distributed systems. In ODP, systems may be described from any of five viewpoints. The five were chosen because they represent different and important perspectives relevant to the domain of distributed systems. These are domain-specific perspectives. 2.3 User-Defined Perspectives (Hyperslices) Other methods allow for the decomposition of a problem into user-defined perspectives. These depend on the domain of concern, and therefore may be different from problem to problem. Also, the number of perspectives is not limited or predefined by the method. Methods supporting this type of decomposition were first developed for use in requirements elicitation, where it is common to have different stakeholders who have different ideas about the problem at hand, all of which must be captured. All perspectives are usually, but not always, described using the same language. Various approaches have been proposed that allow user-defined perspectives. The approaches work at various levels of abstraction, and give different names to the units of decomposition. Table 1 lists some of these approaches. Approach ViewPoints [7] Role models [15] Contracts [10] Aspect-oriented programming [14] Subject-oriented programming [9]

Unit name viewpoint role contract aspect subject

Level of abstraction requirements analysis design design implementation implementation

Table 1. Approaches to decomposition with multiple user-defined perspectives As can be seen from the table, the field is quite overloaded with different terminology for similar concepts. In recent work, Tarr et al. have coined the terms MultiDimensional Separation of Concerns (MDSC) to designate the discipline of multipleperspective decomposition, and hyperslice to designate a unit of decomposition that follows this discipline, at any level of abstraction [20].

240

Torsten Nelson, Donald Cowan, and Paulo Alencar

The most appropriate definition of hyperslice for our purposes is Daniel Jackson’s concept of view: “A view is a partial specification of the whole program, in contrast to a module, which is a specification - often complete - of only part of the program” [12]. A hyperslice, like a “view”, specifies some aspect of the entire program. The form of decomposition afforded by hyperslices is useful in many levels of software design. During requirements elicitation, for instance, the engineer often has to deal with many different people who are stakeholders in the system to be developed. Each of these stakeholders may have different perceptions about the problem at hand and of the desired behavior of the system. Hyperslices are a natural way of representing each stakeholder’s perspective on the system so that later a coherent picture can be formed. The same advantages found at the requirements analysis phase carry over into later phases. Having design and implementation modules that correspond to user requirements provides easy requirements tracing. In the next section we discuss the use of hyperslices with object-oriented systems. While the ideas behind MDSC are useful, there are issues that must be tackled when applying it, One of the most pressing of which is is consistency. When we allow more than one representation of an entity, we must somehow ensure that the representations do not contradict each other. Being able to detect inconsistencies and deal with them is one of the challenges of MDSC, and formal models that allow reasoning are an indispensable aid towards achieving this goal. Easterbrook et al. have studied mechanisms for dealing with inconsistencies when using requirements-level hyperslices [6]. There are also conflicts that do not manifest themselves as logical inconsistencies, but as a form of interference between hyperslices; the goals of the viewpoints may be mutually interdependent and actions taken by one may cause undesired behavior in the other. This is analogous to the problem of feature interaction in telephone systems [4]. A formal model should aid in the detection of such interactions. There is yet no formal model to allow a comparative study of the properties of the various existing approaches to hyperslices; our work intends to fill that gap. However, mention should be made of Ku [19], a formal object-oriented language for hyperslices currently under development at Imperial College. Once our model and Ku are both complete, it will be interesting to compare analytical results derived from the two independent studies.

3 Object-Oriented Hyperslices While the concepts behind MDSC (Multi-Dimensional Separation of Concerns) are widely applicable, much of the work in the field involves its use together with the object-oriented paradigm. Many of the shortcomings of object-orientation are addressed by MDSC. Among these are rigid classification hierarchies, scattering of requirements across classes, and tangling of aspects related to various requirements in a single class or module. For a detailed treatment and motivation for the use of multiple perspectives in object-orientation, we refer the reader to Tarr et al. [20].

A Model for Describing Object-Oriented Systems from Multiple Perspectives

241

We are interested in the subset of MDSC that deals with object-oriented systems. We consider a hyperslice to be a module that conforms to some accepted model of object-orientation, made up of classes and class relationships such as containment and inheritance. For an object-oriented system to fit into the category of MDSC, however, there must be entities from the problem domain that appear in more than one module. That is, there must be classes in different modules that represent separate aspects of the same entity. Since a hyperslice is meant to be a complete encapsulation of some relevant aspect of the system, the classes in a hyperslice should not have any links to classes of other hyperslices. Each hyperslice should be a well formed unit that can be understood in isolation. As an example, one of the hyperslices in a system may be concerned with displaying information about the various objects that concern the system. The classes in this hyperslice should have methods to output information, and whatever attributes that are relevant to these methods. Other attributes or methods, such as those concerned with synchronization, or with some form of computation over the data, should not appear in this hyperslice. However, the hyperslice should contain all classes that have an output aspect to them. Splitting an object-oriented description into various hyperslices gives a level of separation of concerns that offers significant advantages over traditional approaches. Among these advantages are the following: Requirements-based modularization since entities are allowed to appear in more than one unit of decomposition, and to be only partially specified in any one unit, it is possible to have units that encapsulate a single requirement from the problem domain. For instance, if some of the data is to be stored and retrieved from a network server, a hyperslice would be defined containing all classes that have data belonging in the server. Each class would have only enough detail defined to allow the relevant storage operations to be performed. The same classes might appear in other hyperslices, but no mention of server storage would be found in them. Decentralized development since classes can be represented differently in different hyperslices, classes need no longer be owned by developers who are responsible for all details regarding that class, but each developer can be responsible for a part of the shared class. Unanticipated composition designs for separate programs can be thought of as hyperslices of an integrated application; a hyperslice-enabled method would allow the developer to describe how the programs are to be joined together. Software evolution along the same lines, features can be added to existing systems as separate hyperslices; this would allow changes to be made without requiring modifications to existing designs. An example of hyperslices applied to evolution can be found in [2]. 3.1 Composing Hyperslices Since each hyperslice is a plain object-oriented module, it can in theory be described using any object-oriented language, at any level of abstraction. Having defined the hyperslices, they must now be composed to form a complete system. This is where the

242

Torsten Nelson, Donald Cowan, and Paulo Alencar

MDSC paradigm differs from other approaches to decomposition. Some approaches, such as that advocated by module interconnection languages, define interfaces for modules, with provided and required functionality, and match provided functions with required ones across modules. Others, such as frameworks, use inheritance as the basic composition mechanism. In MDSC, each hyperslice is well formed and independent, and does not require other hyperslices. There are classes, however, that exist in various hyperslices. In order to form the desired system, we must establish the correspondence between these classes. Correspondence is the specification of what elements match between hyperslices, and the semantics of each match. There are many ways in which matching can affect the overall behavior of the system. Matched classes may have complementing behavior, or one’s behavior may override the other, or they may interact in more complex ways. The granularity of correspondence is an issue. Using classes as the unit of correspondence (also called join point [14]) seems to be too coarse. There are many different ways in which we may wish to specify that entire classes are matched, and the model would require a large variety of different correspondence operators. On the other hand, using single program statements is too fine-grained. Specifying correspondence would require understanding implementation details, and would be very complex. In our model, we choose the middle road and use methods as the smallest elements that can be matched. Ossher and Tarr argue in favor of this approach [16]. We define correspondence operators that allow methods to be matched with various different semantics. The semantics describe what method bodies are executed in response to a method call. Another issue with regard to correspondence is object binding. This is the specification of how objects of classes with corresponding methods are bound to each other at runtime. The description of correspondence is class-based, meaning that a method from a class is said to correspond to a method in another class. However, the semantics of correspondence are observed during method invocation on particular runtime objects. If a method invocation results in the execution of a method in an object of a different class, we must be able to determine exactly what the target object is. The binding specification describes how to determine correspondence between runtime objects.

4 The Hyperslice Model We are interested in studying object-oriented hyperslices with operation-level correspondence. A language to allow hyperslice composition is under development. This is a class-based language that uses methods as the smallest indivisible unit. It is not meant to be an executable object-oriented language, but a means to specify formally compositions that can be done in any object-oriented design or implementation language. The language has two parts, one for class definition and one for composition. The model allows us to study properties of techniques that use operation-level correspondence such as subject-oriented programming [9], and serves as a semantic basis for the extension of other object-oriented languages with the required mechanism for multi-dimensional separation of concerns. Since subject-oriented programming already represents an embodiment of MDSC at the implementation level, one of our interests is in extending design-level languages such as UML.

A Model for Describing Object-Oriented Systems from Multiple Perspectives

243

4.1 Class Language The class language defines the classes present in the system, as well as the call graph between the methods of these classes. The semantics of correspondence are specified in terms of transformations in the call graph structure. Each class is defined as a set of methods. A method has a name and a list of other methods that it calls. The internal state of a method is irrelevant. Each method call in this list is decorated with the modal symbols 2 (always) and (possibly). At this stage, the language is untyped, and does not support parameters to methods, or return values. Data attributes are not modeled. Instead, they may be represented as methods, the data being the internal state of the method. In fact, any method that does not call any other methods can be thought of as an attribute. This approach is related to the one used by Abadi and Cardelli in their object calculus [1]. Figure 1 shows the syntax of the class language, while figure 2 shows a sample class definition.

3

hyperslice ::= class{class} class ::= class name “{” method{, method} “}” method ::= name[ “(” { called-method } “)” ] called-method ::= 2name|3name name ::= an identifier containing letters, hyphens, or a period. The period separates class names from method names.

Fig. 1. Class definition language syntax

class Tree {nodes, find( 2 nodes, 3 travel-left, 3 travel-right ), travel-left (2 nodes), travel-right (2 nodes) }

Fig. 2. Sample class definition

Note that the names inside the parenthesis are not arguments, but the list of methods that the method calls. In the example above, the class named Tree has four methods. The methods find, travel-left, and travel-right will always call method nodes. The method find may, in addition, call methods travel-left and travel-right. The method call list may contain methods from other classes, specified by stating the class and method names separated by a period (as in Tree.find). 4.2 Composition Language A composition is specified using calling contexts. At the highest level is the program calling context. By default, in any context, calling a method results in that method being executed. Method correspondence expressions can be used to change the effects of method calls. An expression is formed by two method names connected by a correspondence operator. Each expression can also introduce new calling contexts that have scope limited to the execution of the method that precedes the context.

244

Torsten Nelson, Donald Cowan, and Paulo Alencar Operator Unidirectional a followed-by b a preceded-by b a replaced-by b Bidirectional a merge b = a followed-by b ∧ b followed-by a a swap b = a replaced-by b ∧ b replaced-by a

Call Execution a a a

a; b b; a b

a b a b

a; b b; a b a

Table 2. Method correspondence operators Table 2 shows the correspondence operators and their meaning in terms of method calls and executions. The semicolon is used to denote sequence: a; b means that method a will be executed and immediately followed by the execution of method b. The bidirectional operators merely combine unidirectional ones and exist to add brevity to specifications. Many others are possible besides the two shown previously. Figure 3 shows the syntax of the composition language. context ::= “{” {expression} “}” expression ::= name[context] | name[context] operator name[context] operator ::= followed-by | preceded-by | replaced-by | merge | swap

Fig. 3. Composition language syntax

Composition expression examples: a{b followed-by c} Calls to a will result in the execution of a. During the execution of a, calls to b will result in the execution of b, followed by the execution of c. x{p followed-by q} preceded-by y{r swap q} A call to x will result in the execution of y followed by the execution of x. In the execution of y, calls to r are replaced with the execution of q, and calls to q are replaced with the execution of r. In the execution of x, calls to p will result in the execution of p followed by the execution of q. 4.3 Object Binding The composition operators are described at the class level. However, their effects are at the object level. A correspondence operator defines what happens when a call is made to a specific object. That call may result in the execution of methods in a different object. We need a way to determine the object referred to in the execution. Once that is determined, objects are bound to each other throughout their lifetime. If there is a correspondence expression that matches a method call in a class a to a method execution in a different class b, there must be a binding expression detailing

A Model for Describing Object-Oriented Systems from Multiple Perspectives

245

how objects of class a are to be bound to objects of class b. A binding expression has the form a operator b, where a is the class that has the method called, b is the class that has the method executed in response to the call, and operator is a binding operator. There can only be one binding expression involving any given pair of classes. Currently, our language supports only three binding operators: binds-to-unique, binds-to-any, and binds-to-all. The expression a binds-to-unique b means that an object of class a is bound to any object of class b, as long as b has not yet been bound to any other object of class a. If such an object does not exist, one must be created. Another kind of binding is binds-to-any. The expression a binds-to-any b means that an object of class a can be bound to any existing object of class b. Finally, binds-to-all means that an object of class a will be bound to all existing objects of class b. The effect of binds-to-unique is to create a one-to-one correspondence between objects. If a binds-to-unique b, then for each object of class a there will be an object of class b. The effect of binds-to-any is to create a many-to-one correspondence. If a binds-to-any b, a single object of class b is sufficient; all objects of class a can bind to that object. Finally, binds-to-all creates a many-to-many correspondence. In this case, when a method is called on an object of class a, the corresponding method of class b will be executed for all objects of class b.

5 Example: Concurrent File System In this example we will take two independent modules, a simple file system and a concurrency control unit, and consider them as two hyperslices, or separate aspects, of an integrated system. The system is to give support for concurrency to the file system. Hyperslice 1: file system A simple file system hyperslice contains two classes: File and Directory. Both allow read and write operations. Hyperslice 2: shared buffer The shared buffer hyperslice contains a single class, Mutex, which encapsulates a shared buffer for use in a concurrent environment by multiple threads. The shared buffer contains three methods: read, write, and cs. Many readers can access the buffer at the same time, but writers require exclusive access. The cs method implements the critical section, which is where the buffer is actually manipulated. Our intention is to combine the two hyperslices to produce a file system that supports execution in a concurrent environment, i.e., that allows many simultaneous users to read from a file or directory, but requires exclusive access to write in either of them. Figure 4 shows the class definitions for the two hyperslices. class File { read( ), write( ) } class Directory { read( ), write( ) } class Mutex { read( 2 cs ), write( 2 cs ), cs( ) }

Fig. 4. Class definitions

246

Torsten Nelson, Donald Cowan, and Paulo Alencar

The Mutex class provides synchronization for the desired system. Our intent is for users to still be able to use the File and Directory classes normally. However, before the file system operations can be used, the synchronization process must happen. This means that the appropriate Mutex method must be executed before the file system method. We use a correspondence expression to make sure that this happens, and that the appropriate file system method is executed when the Mutex object enters the critical section. The four required correspondence expressions are shown in figure 5.

File.read replaced-by Mutex.read { cs replaced-by File.read } File.write replaced-by Mutex.write { cs replaced-by File.write } Directory.read replaced-by Mutex.read { cs replaced-by Directory.read } Directory.write replaced-by Mutex.write { cs replaced-by Directory.write }

Fig. 5. Correspondence expressions

The four expressions have similar structures. Let’s examine the first line. When the user calls the read method of a File object, the read method of a Mutex object will be executed instead. The method will go through the read access protocol for the shared buffer. When it becomes possible to read the shared buffer, the cs method will be called. However, the context specified that File.read be executed instead. The file is then read. When File.read returns, the rest of the Mutex.read method is executed, releasing any locks that may be necessary. Figure 6 shows the flow of control between the hyperslices.

File

System

Mutex

File.read called Mutex.read executed Mutex.cs called File.read executed File.read terminates

Mutex.read terminates

Fig. 6. Flow of control after correspondence

A Model for Describing Object-Oriented Systems from Multiple Perspectives

247

File binds-to-unique Mutex Directory binds-to-unique Mutex

Fig. 7. Object binding expressions The effect of the binding expressions, shown in figure 7 is to ensure that each File or Directory object will have its own Mutex object. This will allow each file to have its own concurrency access; while a file is being read, a different file can be written. Had we used binds-to-any, instead, we would have all files sharing a single Mutex object, which would have the effect of only allowing the file system to write to a single file at a time. This illustrates how the behavior of the system can be modified by changing the binding expressions.

6 Work in Progress Many issues still need to be tackled before the model can be used as a basis for the extension of object-oriented approaches. The language is still untyped, and methods support neither arguments nor return values. Dealing with these will require work on the semantics of the correspondence operators, since the parameters or return types of a called method may differ from those of the executed method. The language also needs support for inheritance and more complex types of object binding. We use transformations to achieve the desired semantics mandated by the correspondence operations. Since conventional object-oriented languages offer no primitives that are equivalent to these operators, the model becomes more useful if the systems described can be converted into systems in the conventional object-oriented model. This can be accomplished by a set of semantics-preserving transformations that would modify the existing classes to apply the functionality dictated by the correspondence operators. The formal model underlying the language is under development using the PVS language and theorem prover [17].

7 Conclusion We are providing the formal infrastructure for reasoning about multiple-perspective object-oriented systems. Our model is based on method-level correspondence, and is simple yet capable of describing the complex relationships that are necessary for this form of separation of concerns. We use call graphs to define the structure of individual hyperslices. Correspondence operations are used to specify changes in the call graph structure, and binding operators specify how runtime objects are matched. The example shown in this work is small, but illustrates the potential for using the model languages in hyperslice composition. Once the model has been further expanded to include more object-oriented mechanisms such as inheritance, we intend to use it for formal reasoning about systems defined in many of the existing approaches such as subject-oriented programming. In particular, we are interested in consistency checking, a constant problem when using

248

Torsten Nelson, Donald Cowan, and Paulo Alencar

this form of decomposition. We also wish to use our semantic infrastructure as the basis for extending other object-oriented languages with multiple-perspective capabilities.

References [1] Martin Abadi and Luca Cardelli. A Theory of Objects. Springer-Verlag, 1996. [2] Paulo Alencar, Donald Cowan, Carlos Lucena, and Torsten Nelson. Viewpoints as an evolutionary approach to software system maintenance. In Proceedings of IEEE International Conference on Software Maintenance, October 1997. [3] Grady Booch, James Rumbaugh, and Ivar Jacobson. Unified Modeling Language User Guide. Addison-Wesley, 1998. [4] E. J. Cameron, N. Griffeth, Y.-J. Lin, M. Nilson, and W. Schnure. A feature interaction benchmark for IN and Beyond. In W. Bouma and H. Velthuijsen, editors, Feature Interactions in Telecommunications Systems, pages 1–23. IOS Press, 1994. [5] P. Coad and E. Yourdon. Object-Oriented Analysis. Prentice Hall, 1989. [6] Steve Easterbrook and Bashar Nuseibeh. Using ViewPoints for inconsistency management. Software Engineering Journal, 11(1):31–43, January 1996. [7] A. Finkelstein, J. Kramer, B. Nuseibeh, L. Finkelstein, and M. Goedicke. Viewpoints: a framework for integrating multiple perspectives in system development. International Journal of Software Engineering and Knowledge Engineering, 2(1):31–57, 1992. [8] C. Gane and T. Sarson. Structured Systems Analysis: Tools and Techniques. Prentice Hall, 1979. [9] William Harrison and Harold Ossher. Subject-oriented programming (a critique of pure objects). In Proceedings of OOPSLA ’93, pages 411–428. ACM, 1993. [10] I. M. Holland. Specifying reusable components using contracts. In Proceedings of ECOOP ’92, 1992. Lecture Notes in Computer Science no. 615. [11] ISO. ITU Recommendation X.901-904 – ISO/IEC 10746 1-4: Open Distributed Processing – Reference Model – Parts 1-4. ISO, 1995. [12] Daniel Jackson. Structuring Z specifications with views. ACM Transactions on Software Engineering and Methodology, 4(4):365–389, October 1995. [13] Michael Jackson. Software Requirements and Specifications: a lexicon of principles, practices and prejudices. Addison-Wesley, 1995. [14] Gregor Kiczales, J. Lamping, A. Mendhekar, C. Lopes, J. Loingtier, and J. Irwin. Aspectoriented programming. In Proceedings of ECOOP ’97, 1997. [15] Bent Bruun Kristensen. Roles: Conceptual abstraction theory and practical language issues. Special Issue of Theory and Practice of Object Systems (TAPOS) on Subjectivity on ObjectOriented Systems, 1996. [16] Harold Ossher and Peri Tarr. Operation-level composition: a case in (join) point. In Proceedings of the 1998 ECOOP Workshop on Aspect-Oriented Programming, 1998. [17] S. Owre, J. M. Rushby, and N. Shankar. PVS: A prototype verification system. In Deepak Kapur, editor, 11th International Conference on Automated Deduction (CADE), volume 607 of Lecture Notes in Artificial Intelligence, pages 748–752, Saratoga, NY, June 1992. Springer-Verlag. [18] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen. Object-Oriented Modeling and Design. Prentice Hall, 1991. [19] Mark Skipper and Sophia Drossopoulou. Formalising composition-oriented programming. In Proceedings of the 1999 ECOOP Workshop on Aspect-Oriented Programming, 1999. [20] Peri Tarr, Harold Ossher, William Harrison, and S. Sutton. N degrees of separation: Multidimensional separation of concerns. In Proceedings of the 21st International Conference on Software Engineering, pages 107–119, 1999.

Stepwise Introduction and Preservation of Safety Properties in Algebraic High-Level Net Systems m

j

l

k

l

l padberg, hoffmann, gajewsky @cs.tu-berlin.de

1

l

Abstract.

l

l l

l ll

l

l

l

l

l l

l

k ll

l

ll

ll

l

k

l

l l

l

l

m

Keywords:

m

m

1

m

m

Introduction m

m

m

m k

m m

m

m x

m m

m

m m

m m

m m m 1

l

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 249–265, 2000. c Springer-Verlag Berlin Heidelberg 2000 

l

l

l

k

m

m

m

m m

m

m

m

m

m m m m

m

m

m

m m

m

m

m

m x m

m

m

m m

m

m

k

m

m

m

m m

m

m

m m

m m

m m

m

m

m m x

x m

m

m

x

k m

m

m

m m m

m m m m

m

m

m

m m

m

m

x

k m

m m

x

x mm x m

x m

mm

k

2

Example: Medical Information System m m

m

x m m

m

m

m

m

m

m

m m

m

m

m

m m

m

m m m m m

k

m m

k m

Taking blood pressure

k Spec

DrF

bl(PatId)

m m BC

m m

m BC-Spec

Dr.Frank

blood test

k

bl(PatId) Taking blood count

m BC

m

getpat(bl(PatId)) = PatId bl_count_wanted(PatId)= true v(Bl,PatId)

Taking blood pressure

values for blood test

m

v(Bl,PatId)

m

Doctor

Notifying the doctor

DrF

doctor

getpat(v(Bl,PatId)) = PatId bl_count(PatId)= true

m BC m

m k

BC

m BC

m m sorts: opns :

x

BC-Spec k ...

m m

x

mk m m

k

m AN ame Dr. F rank, Dr. Brown . . . Dr. F rank, doctor k k doctor m

ADoctor MBC

m m BC

Smith, M iller, . . . m k

m

m

k rint

L_INT

K_INT

R_INT

getpat(PatRecord) = PatId getpat(Patient)=PatId Prescr=get_Prescr(PatRecord) bl_test_wanted(Prescr)=true bl_pressure_wanted(Prescr)=true

Empty Net

Empty Net

Taking blood pressure and blood test

PatRecord

Patient

PRM PRS

ward documents

patient at ward

S

Smith

M

Miller

PRS

mk_patrec(Smith)

PRM

mk_patrec(Miller)

S M

[(a, patient at ward ) (d, ward documents )]

rint

u

K

L

r

v

m m

m

r

R u v L ←− K −− R

m m m

r

g L− G

m G

m

x

rint m

m

x m m BVM12 m BC

m BC rint

k

m

rint

m

Smith, patient at ward − mk patrec Smith, . . . , ward documents − M iller, patient at ward − mk patrec M iller, . . . ward documents rint

m R INT m

m m m m 2

BVM3

l

l l

BVM1 BVM2

m rint

rint

x

m

m R INT

R INT

k

m BC

rint m m k m m m m k m a, patient at ward −− d, ward documents M a d m getpat a d − AP atRecord a − AP atient a, patient at ward −− d, ward documents m k rtg−tbp blood pressure Taking blood pressure and blood test m BVM1 m BVM2 R TG-TBP m m m m L TG-TBP m BVM1

m

m

m

k

m

k

getpat d

Taking rtg−tbp

BVM2 m

K_TG-TBP

Taking blood pressure

bl(PatId)

blood test

Taking blood pressure and blood test getpat(PatRecord) = PatId getpat(Patient)=PatId Prescr=get_Prescr(PatRecord) bl_pressure_wanted(Prescr)=true bl_test_wanted(Prescr)=true PatRecord ward documents

Patient

R_TG-TBP

all places, no transitions, no arcs

L_TG-TBP

Taking blood pressure and blood test getpat(PatRecord) = PatId getpat(Patient)=PatId Prescr=get_Prescr(PatRecord) bl_pressure_wanted(Prescr)=true bl_test_wanted(Prescr)=true

bl(PatId) blood test

PatRecord ward documents

patient at ward

Patient patient at ward

rtg−tbp x m rpp x m m for hypertension test

m

m BVM2 m BVM2 x rpp

m BVM3 m values schedule fl

x m

m place preserving

rpp

m

k

m m

L_PP

K_PP

R_PP

Taking blood pressure and blood test

getpat(PatRecord) = PatId getpat(Patient)=PatId Prescr=get_Prescr(PatRecord) bl_pressure_wanted(Prescr)=true bl_test_wanted(Prescr)=true

getpat(PatRecord) = PatId getpat(Patient)=PatId Prescr=get_Prescr(PatRecord) bl_pressure_wanted(Prescr)=true bl_test_wanted(Prescr)=true

PatRecord

Patient patient at ward

ward documents

all places, no transitions, no arcs

Taking blood pressure and blood test

bl(PatId)

blood test

bl(PatId) blood test

PatRecord

Patient patient at ward

ward documents

v(BPd,BPs,PatId) values for hypertension test v(BPd,BPs,PatId) Planning Next Measurement

(PatId,date)

schedule

getpat(v(BPd,BPs,PatId)) = PatId hypert(PatId)= true

rpp

L_TG-NP

K_TG-NP

v(BPd,BPs,PatId)

schedule

Planning next measurement getpat(v(BPd,Bps,PatId)) = PatId hypert(PatId)= true

(PatId,date)

Doctor

Notifying the doctor

doctor

getpat(v(Bl,PatId)) = PatId bl_count(PatId)= true v(Bl,PatId)

all places, no transition, no arcs

values for hypertension test

R_TG-NP

values for hypertension test schedule

v(BPd,BPs,PatId) Notifying and Planning getpat(v(BPd,Bps,PatId)) = PatId hypert(PatId)= true getpat(v(Bl,PatId)) = PatId bl_count(PatId)= true

(PatId,date) doctor Doctor

v(Bl,PatId) values for blood test

values for blood test

rtg−np m

x m

m rtg−np

m m

m a, patient at ward −−

m BVM d, ward documents

Taking blood pressure and blood test

DrF

getpat(PatRecord) = PatId getpat(Patient)=PatId Prescr=get_Prescr(PatRecord) bl_pressure_wanted(Prescr)=true bl_test_wanted(Prescr)=true

blood test

PatRecord ward PRM documents

PRS

Dr.Frank

bl(PatId)

Patient patient S at ward

S

Smith

M

Miller

bl(PatId) M PRS

mk_patrec(Smith)

PRM

mk_patrec(Miller)

v(BPd,BPs,PatId) Taking blood count values for hypertension test

getpat(bl(PatId)) = PatId bl_count_wanted(PatId)= true

v(BPd,BPs,PatId) Notifying and Planning

Doctor

getpat(v(BPd,BPs,PatId))= PatId hypert(PatId)= true getpat(v(Bl,PatId))=PadId bl_count(PatId)= true

(PatId,date)

DrF

doctor v(Bl,PatId) schedule

v(Bl,PatId) values for blood test

m BVM m

x

x m

m BVM m m

3

m

Safety Introducing and Preserving Rules m

m m

m k m

x

m

m

m m m

m

x

m m

m

k

Definition 1 (Algebraic High-Level Net System). An algebraic high-level (AHL) net system is given by N SP EC, A, P, T, pre, post, cond, m  with – SP EC − − SPEC−: an algebraic specification with SP EC Σ, E (see [EM85]), – A −− Alg SPEC −a SP EC algebra, – P : the set of places, – T : the set of transitions, – pre, post T − TOP X − P the pre- and postcondition functions of T , defining for each transition with adjacent arcs the arc inscriptions and the weight, (see Def. 15 for −-operator) – cond T − −f in EQN S Σ the function that maps each transition to a finite set of conditions over the signature with variables representing the firing conditions, and – m  − A − P the initial marking (see Def. 15). m m

m

m

k

x

m

m a, p m

a −A

k p −P

m

k

k

m

m

k

m k

x m m

m

m

m

k

x m

m m

m QAHLSys m

m

m m

Definition 2 (AHL Net System Morphisms and Categories). Given two SP ECi , Ai , Pi , Ti , prei , posti , condi , m i for i , AHL net systems Ni then an algebraic high-level (AHL) net system morphisms f N1 − N2 given by f fΣ , fA , fP , fT with – – – –

fΣ fA fP fT

SP EC1 − SP EC2 is a specification morphism, A1 − VfΣ A2 is a homomorphism in Alg SPEC1 , P1 − P2 maps places to places in Set, and T1 − T2 maps transitions to transitions in Set,

and the following abbreviations fΣ − fP TOP 1 X − P1 − TOP 2 X − P2 – finsc – fM fΣ , fA − fP A1 − P1 − A2 − P2 # – fC −f in fΣ for the induced mappings of arc inscriptions, markings, respectively conditions, are called

loose – for any t − T1 we have finsc pre1 t − pre2 fT t finsc post1 t − post2 fT t – fC −cond1 − cond2 −fT 1 p − m 2 fP (p) m k N1 – fM m – A1 − VfΣ A2 m m fA m m This class of morphisms gives rise to the category QAHLSys. transition preserving if they are loose and – finsc −pre1 pre2 −fT finsc −post1 post2 −fT j m – fC −cond1 cond2 −fT This class of morphisms gives rise to the category AHLSys. place preserving if it is a loose morphism and the following place preserving conditions hold: – fΣ SP EC1 − SP EC2 is persistent, that is for the corresponding free functor FfΣ Alg SPEC1 − Alg SPEC2 we have VfΣ −FfΣ − ID (see [EM85]). fΣ − fT −p – − fP p p− for all p − P1 and fP p − fΣ − fT (see Def. 17 for pre and post sets) j – fT , fP , and fΣ are injective fM m 1 k – m 2 fP m – fC −cond1 cond2 −fT transition gluing if it is a loose morphism and the following holds: – fP and fΣ are isomorphisms 1 m 2 k – fM m s. t. for t − T – fT is surjective 2 2 pre2 t2 t fT−1 (t2 ) finsc pre1 t , and analogously for post, mm m

– cond2 t2 t fT−1 (t2 ) fC −cond1 t for t2 − T2 mm m m

m

m m

m

k

m

m

m Example 1 (Morphisms in Example). m

m

m

m

m

__ j

m

k

m m

m

m

m

Definition 3 (Strict Morphisms). Given a transition preserving AHL net fΣ , fA , fP , fT and Ni SP ECi , system morphism f N1 − N2 with f i for i , . f is called Ai , Pi , Ti , prei , posti , condi , m 1. marking strict 1 p m 2 fP (p) the initial marking of the source net is placewise if fM m equal to the target net. 2. strict if it is marking strict, and moreover fP , fT , and fΣ are injective, and fΣ is strict in SPEC. u

v

u

v

Definition 4 (PP-Rules). A pair r, f is called pp-rule, if r L ←− K −− R is a rule with strict transition preserving morphisms u, v and a place preserving morphism f L − R with f −u v. Definition 5 (TG-Rules). A pair r, f is called tg-rule, if r L ←− K −− R is a rule with strict transition preserving morphisms u, v and a transition gluing morphism f L − R with f −u v. Example 2 (Rules in Example).

x m

x

m m m

m

m

Definition 6 (Safety Property, Formulas, Translations). 1. The set of static formulas − is given inductively: For λ a, p − A − P we have the atoms λ a, p − −. Furthermore (ϕ1 − − − −ϕ1 − − , and (ϕ1 − −, ϕ2 − − − ϕ1 − ϕ2 − −). The validity of formulas is given w. r. t. the marking of a net. Let m − be a marking of N then: m − N λ a, p iff λ a, p − m, and A−P m − N −ϕ1 iff − m − N ϕ1 , and m − N ϕ1 −ϕ2 iff m − N ϕ1 − m − N ϕ2 . 2. Let ϕ be a static formula over N . Then ϕ is a safety property. The safety property ϕ holds in N under m iff ϕ holds in all states reachable from m: m − N ϕ −− −m − [m− m − N ϕ  − N ϕ. For the initial marking m  we also write N − ϕ instead of m fΣ , fA , 3. The translation −f of formulas over N1 along a morphism f fP , fT N1 − N2 to formulas over N2 is given for atoms by λ f A a , fP p −f λ a, p −−f ϕ , −f ϕ1 − The translation of formulas is given recursively by −f −ϕ −f ϕ1 − −f ϕ2 and −f ϕ −f ϕ . ϕ2

Definition 7 (Safety Preserving Morphism). A morphism f N1 − N2 is called safety preserving, iff for all safety properties ϕ we have N1 − ϕ − N2 − −f ϕ . m m

m m

Definition 8 (Safety Preserving Rule and Transformation). Given a rule r L ← K − R in an HLR system and an arbitrary morphism f L − R. The pair r, f is a safety preserving rule, iff 1. f is a safety preserving morphism 2. given a net N1 , and an occurrence g1 L − N1 , the direct transformation r N1 − N2 yields a safety preserving morphism f N1 − N2 . (r,f )

We denote the direct transformation by N1 − N2 and call it safety preserving transformation, short sp-transformation.

k

m m

m

−

m

x m

m

k

m

Theorem 1 (PP-Rules are Safety Preserving [PGE98]). Proof. m

k m m

m

m m

k m

x

Theorem 2 (TG-Rules are Safety Preserving). Proof.

k m

m

fl x m m

m

j

QAHLSys k m m

m

k

m m m m

m

m m

k

k

m

m R

m R N2

m N2

Definition 9 (Safety Introducing). Given a rule r L ← K − R and a safety property ϕ over R s. t. R − ϕ. If o R − N2 is safety preseving for r all transformations N1 − N2 , r is called safety introducing rule. Definition 10 (SI-Rule). A rule of the form r

−← −− R is called si-rule.

Example 3 (SI-Rule in Example). 2 a, patient at ward −− d, ward documents Theorem 3 (SI-Rules are Safety Introducing and Preserving). Proof. R

N

k o R− N R m m m − −− R m

m

N j m m

Main Conceptual Result 11 (Stepwise Development of Safe Models). The concept of introducing safety properties (see Definition 10) enables development of an AHL net system hand-in-hand with its safety properties. The safety property has to be proven only once for the right-hand side of the rule. Subsequent refinement by si-rules, pp-rules, or tg-rules does not only preserve the explicitly introduced, but also all implicit safety properties (see Theorems 1, 2, and 3). Hence, employing these kinds of rules in the development of a system supports the development of safe models.

4

Conclusion m m m

m

m

m

j m

m m

m

m

−

m x

m

m

m m

m

x m

m

m m

m

m m m k

m m

k

m x m

k x

m

m m

m

m

m m

m x m

m

m

m m

References l

FunSoft Engineering

l Automated Software

k High-Level Replacement Systems with Applications to Algebraic Specifications and Petri Nets l ll l l k l

k l

l

ll l Math. Struc. in Comp.

Science Fundamentals of Algebraic Specification 1: Equations and Initial Semantics l EATCS Monographs on Theoretical Computer Science l l l l l l l k

k

l l

l l l l Validation and Verification of Software Process Models ¨ l k

l

k ll erence Manual

Design/CPN. A Refk

Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use l l l High-Level Petri-Nets: Theory and Application Information and Computation l The Temporal Logic of Reactive and Concurrent Systems, Specification k l l l Information Systems Abstract Petri Nets: A Uniform Approach and Rule-Based Refinement l l k l l l l l l Applied Categorical Structures l l l Mathematical Structures in Computer Science k l l l mental approaches to Software Engineering

Funda-

Petri Nets l EATCS Monographs on Theoretical Computer Science ll l l Advances in Petri Nets 87

A

Review of High-Level Replacement Systems fl

l l l

l

l

l

l

l

l M

l

C u

v

Definition 12 (Rules and Transformations). A l r L −− K −− R in C consists of the objects L, K and R, called left-hand side, interface (or gluing object) and right-hand side respectively, and two u v u v morphisms K −− L and K −− R with both morphisms K R L u, v − M , a distinguished class of morphisms in C. u v g1 g3 (1) g2 (2) Given a rule r L −− K −− R a r G − H, from an object G to an object H is given G c1 C c2 H by two pushout diagrams g1 g (1) and (2) in the category C. The morphisms L − G and R −3 H are called u occurrences of L in G and R in H, respectively. By an occurrence of rule r L − v K − R in a structure G we mean an occurrence of the left-hand side L in G. o





o





∗

A G H, short transformation, between objects G and H means G is isomorphic to H or there is a sequence of n direct transformations: r1 r2 r G G G . . . n Gn H.

Definition 13 (High-Level Replacement System). Given a category C together with a distinguished class of morphisms M then C, M is called a HLR-category if C, M satisfies the HLR-Conditions (see [EGP99]). ll

l Q

l l

Definition 14 (Q: Refinement Morphism [Pad99]). Let QCat be a category, so that C is a subcategory C QCat and Q a class of morphisms in QCat. 1. The morphisms in Q are called Q-morphisms, or refinement morphisms. 2. Then we have the following Q-conditions: Closedness: Q has to be closed under composition. Preservation of Pushouts: The inclusion functor I C QCat preserves f

pushouts, that is, given C − I(f )

D

g

f

− B a pushout of B

I(g )

g

− A −

I(f )

C in

I(g)

C, then I C − I D − I B is a pushout of I B − I A − I C in QCat. Inheritance of Q-morphisms under Pushouts: The class Q in QCat is closed under the construction of pushouts in QCat, that is, given f

g

f

g

C − D − B a pushout of B − A − C in QCat, then f Q f Q. Inheritance of Q-morphisms under Coproducts: The class Q in QCat is f closed under the construction of coproducts in QCat, that is, for A − B f

and A − A

 f +f

A −

B  we have f, f  B



Q

f

f

Q provided the coproduct



B of f and f exists in QCat. u

v

3. A Q-rule r, q is given by a rule r L − K − R in C and a Q-morphism q u v q L R, so that K − L − R K − R in QCat. l

Q

l

Lemma 1 (Q-Transformations [Pad99]). Let C, QCat, Q , and I satisfy the Q-conditions. Given a Q-rule r, q and a transformation G

r

C QCat H in C

q∈Q

defined by the pushouts (1) and (2), then there is a unique q  Q, such that q  ◦c1 c2 and q  ◦g1 g3 ◦q r in QCat. The transformation G H, q  G H , or short G H

q

(r,q )

o

g1

u

g1

q

−L−

R in QCat.

K

(1)

g

H, is called Q-transformation. R −3

− G is pushout of G

L

c1



G o

'



v

R g3

(2) 

C q ∈Q

c2 7





H

k

B

Algebraic High-Level Net Sytems

Definition 15 (Category CMON of Free Commutative Monoids). Let P be a set. Then P ⊕ , λ, is called the free commutative monoid generated by P , s.t. for all u, v, w P ⊕ the following equations hold: – – – –

λ v u v

P⊕ λ λ v v, v w u v w w v

w

P

Elements w of the free commutative monoid P ⊕ are called linear sums. They can be represented as w N and p P . They can be p∈P λp p with coefficients λp considered as multisets. Free commutative Monoids together with set-based monoid homomorphism define the category CMON. Definition 16 (Operations of Free Commutative Monoids). Free commutative monoids imply the operations , , and on linear sums. These are the obvious addition, subtraction and comparison of coefficients on linear sums.  Let M1 , M2 P ⊕ with M1 p∈P λp p and M2 p∈P λp p, then

P

M1 M2 M1 M2 M1 M2 M1  M2

, if p , if p

P P

p∈P p∈P

P

P λp λp P λp λp λp λp p λp − λp p, if M1

M2

Lemma 2 (Induced Functions of Place Vector). Let m A P ⊕ Then we have ⊕ ⊕ ⊕ m P A . Similarily, let m TOP X P . Then we have m P TOP X . Definition 17 (Pre- and Post Set). Given an AHL net system N T, pre, post, cond, m then we define

b

p

X post t

p

t

TOP X

T

⊕

p

t

TOP X

T

⊕

SP EC, A, P,

t∈T

and p

X pre t t∈T

Definition 18 (Restrictions of Place Vector). Given m A P ⊕ and let P   ⊕  ⊕ P , then there is m1 A P and m2 A P P such that m m1 m2 . We define m|P m1 . Moreover there are two important special cases: 1. P  2. P 

p denoted with m|p fP P0 for some function fP

P0

P , denoted with m|fP

Lemma 3 (Restrictions are Compatible with Monoid-Operations). Let P  P and m A P ⊕ and p P1 . Then we have m m |P m  m |P m m fM m |fP fM m1|fP

m|P m|P m|P  m|P m|P m|P fM m m2|fP (p) m1 p

m2 fP p

Ready-Simulation Is Not Ready to Express a Modular Refinement Relation l l

l l

l

LIFC, Univ. Franche-Comt´e, 16, route de Gray, 25030 Besan¸con Cedex France {bellegar,julliand,kouchna}@lifc.univ-fcomte.fr, http://lifc.univ-fcomte.fr

Abstract. The B method has been successfully used to specify many industrial applications by refinement. Previously, we proposed enriching the B event systems by formulating its dynamic properties in LT L. This enables us to combine model-checking with theorem-proving verification technologies. The model-checking of LT L formulae necessitates that the B event system semantics is a transition system. In this paper, we express the refinement relation by a relationship between transition systems. A result of our study shows that this relation is a special kind of simulation allowing us to exploit the partition of the reachable state space for a modular verification of LT L formulae. The results of the paper allow us to build a bridge between the above view of the refinement and the notions of observability characterized as simulation relations by Milner, van Glabbeek, Bloom and others. The refinement relation we define in the paper is a ready-simulation generalization which is similar to the refusal simulation of Ulidowsky. The way the relation is defined allows us to obtain a compositionality result w.r.t. parallel composition operation. For complex systems, it is important in practice to associate a design by refinement with a design by a parallel composition of their components. This refinement relation has two main applications: – it allows the splitting of the refined transition system into modules; – it allows the construction of complex systems by a parallel composition of components. It makes sense to qualify the refinement relation as being modular.

1

Introduction m y

m

l

m m

m l m

m m y m m l y l l y Matra Transport International Marconi Avionics Limited

y l l y

m

l

l l l SPECTRUM

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 266–283, 2000. c Springer-Verlag Berlin Heidelberg 2000 

y m y m m ´ EOR ´ MET y GEC-

Ready-Simulation Is Not Ready to Express a Modular Refinement Relation

m y

m

y m

l

m l

l l l

m

l l

l m y m

y

l

y m l y m

l l y

m ll l

l m

l l

l l l

ly l

l

m

l

m l l l

l

y

l l y

m m

y

lm m

l

m l m l lm

l

l l m

m l

l m

l ll m m l

m l l

y y y

m

m m m

l

l l l m

y l

m

m l

m l

l l

m

m

m m

l

y

m

m

m

m l l

l

m y

y

m y m

m

m

l

y m

l

m y

l ll l ll l m

l l

2

m y

m l m

y

y

m

267

l

m

m

l

l

m

Preliminaries l y

l

m transition systems l Definition 1. ( and between two set of states 1 and S1 S2 and by

transitions systems m

m 

predicate transformers) Given a relation S2 S1 2 ( 1 2 ), we define

268

Fran¸coise Bellegarde, Jacques Julliand, and Olga Kouchnarenko def

– –

1

1

2

1

2

def

2

2

2

2

1

1

2

2

l

2 1

1

m

1

1

l

l

m

m l

Proposition 1. For any relation we have: – For any – For any

1,

2

1,

2

subsets of subsets of

l l

from a set

2,

1

1

1,

1

to a set

2

2 2

(

2 ),

1

1

2

1

2

. .

l l y y

– – –

S

identity l

S

S1

m

l

S2

def

1

2

2

3

y m

–

m

y Proposition 2. Let be

2

. Then

.

l m

m

l

m

Definition 2. (Galois connections) Let 1 and 2 be two sets of states. A γ , where connection from S1 to S2 is a pair of monotonic functions S1 S2 S2 S1 and γ , such that S1 γ and γ S2 . γ

l l

m

m

l l S1

y m

l

l

m

2

m

1

S2

m

Proposition 3. (Connections generated by a binary relation on states) is a connection from S1 to S2 , If 1 2 , then the pair S2 to S1 . and is a connection from

3

Behavioral Semantics of Systems Derived from the B Design l l

y m

m m

m

l

l m l l

m

l l l

Ready-Simulation Is Not Ready to Express a Modular Refinement Relation

269

l m l l

y

y

def

variables l

l l y

n

l l

l l l m l m

l

n

n

1

l l

n

1

1 1

m

m

l

l y l l

m y

l

l l linvariant m l y

y

l y

y

m

l

m y l l

l y

m A

b

def

y l l

a

path

m l y l l

l

−

−

n

a def

n−1

1

a1

an−1

−

n

2

y

TS

1

n−1

1 1

y

−

m 1

y

−

A

l

−

− def

l

y

actions A

l

−

l  A

m

l

− b

− − c

m

TS

b y

y l

m l l l −

y

4

−1

l

m

l



− −

 − −1

−

−

Modular Refinement Relation y

1

2 A m l

2

l l y

2

2

2

l

2

y m

m mm l y

m l m refinement

2

1

1 A y 1

m new l y l l l m

A gluing

1

l l 1

A

2

y y

m

2

m 1

1

m

270

Fran¸coise Bellegarde, Jacques Julliand, and Olga Kouchnarenko

4.1

Modular Refinement as State Space Partition l

m

l y

l

l

2

l l

1

l

y

Definition 3. (Glued states) The state as 2 1 , iff 2 2 1 .

2

2

is l

to

m 1,

1

written

μ q2 q1 μ

q2

Fig. 1.

l

l

l l

l

l l

y

m

l

1

2

m

2

l

1

− 2 − 2

2 1 2

− 1

1

μ 2

1

l

− 2

l

m l l y

y 1

m l 1

1

lm

1

Definition 4. (Equivalence class name) Let be an equivalence class of iff, for a state 2 , we have 2 −μ . The state 1 1 is the name of 2 1. 4.2

Modular Refinement as a Relation m

m l m

y

m l

m l l l m l l

l l y m lm

−1

m

l m l y m l

l l

l m

y

l m

m

l

m l

m l m

l

Ready-Simulation Is Not Ready to Express a Modular Refinement Relation

271

l l

From a Refined Transition System to One of Its Abstraction l l 2 1 l l m

A

m new m A non observable m

1

m

2

A

2

y

1

m

l

y

m

l

m

m

τ

q1 a q1

τ

τ a

Fig. 2.

m

l

l

m

l y

l

m

l A

def

1τ

A

−

1

−− − τ na

−−

−A

−

τ aτ

−−

m

a

1τ

−

a

− l

l y

− m

−

l l

a

−

l m

l l

l m

m n

l l m

m

l

l

 1 A 1 − 1 1 −and  2 A 1τ − 2 2 −be Definition 5. Let 1 2 respectively a transition system and its refinement. Let be in A 1 . The relation − 2 − 1 is defined as the greatest binary relation included into and satisfying the following clauses: 1. (strict transition refinement) 2 − − − 1− 2 1 2. (stuttering transition refinement) 2

1

−

2

τ

−2

− a 2 −2

− − 2

1

− − 1− s.t.

−

1

2

a

−2

a

−1

− 2

− − 1− s.t.

− − 1− 2

1

−

− − 2

1

− 1

a

−1

272

Fran¸coise Bellegarde, Jacques Julliand, and Olga Kouchnarenko ρ

@@ @@ ρ − @@@ − @

1

2

o

`

a

τ 

− 1 ? _

− 2

?? ρ ?? a − ?? 

− − 2

3. (lack of new deadlock) 4. (non -divergence)

2

2

1

−

− −

1

9

2 2

τ

−

9

2 − 1 − τ − −τ − − 2 2

l

l

y l

m

T S1

τ

m

l m lm

l

1

−−−− −−− y l

m

T S2

1

l

m

2

y

m

T S2

T S1

···

•

• ooo~ μ ooo ~~ o μ ooo ~~~ ~ ooo o • • •

···

•

an−1

an



?

•@ • OOO • OOO • @@ OOO μ OOO μ O O @ O O μ @@ OOO O OOO OOOOO @ • • • an • 

7

g

O

O





an−1

g

_



m

···

m

Fig. 3.

l m



···

m

l y y l

new m

2

l y m

y

l y

y l l y

y

y l l y

l l T S1

m l m

y

l l

T S2

l

From an Abstract Transition System to One of Its Refinement  1 A 1 − 1 1 −and  2 A 1 τ − 2 2 −be Definition 6. Let 1 2 respectively a transition system and its refinement. Let be in A 1 . The relation − 1 − 2 is the greatest binary relation included into −1 and satisfying the following clause:

Ready-Simulation Is Not Ready to Express a Modular Refinement Relation

(non-determinism) − − − 2 − 1

− − 2

1 a

a

a 

− 1 − 1

−1

1

ξ

@@ @@ ξ @@ − @@

− − − 2 2 s.t.

− − a 2− 2 −2

1

2



− 1 ? ,

− −

2

273

− 2



?? ??ξ − − ??

a





− − 2

y m l internal m

l

m

m

T S1

l

1

y • O

···

•

m

2

~ ~~ ~ ~ ~~ a ?

n• nn~n~~ n n n μ nnn ~~~ ~ nnn n • • •



7

?

O

• O





a

•

l

−A

m

m l

y m m 2

y

m

m

1

l l l

2

y new

l y

m

m

m

m

m

m l l m

2 −μ

l

l

m lm − 2 −μ l m

l

m

l l l m

1

···

m 1

l l

•

m l 1

2

···

m

l y

m A m l l

• μ

m

y

T S2

•

μ

Fig. 4.

−

a

a

···

l

m

2

1

y

1

m

l l

−

1 1

l y

l

l

2 −

l l l l

1

m

m

2

l

l l y

m l

l l

−

1

l

l l

l

274

Fran¸coise Bellegarde, Jacques Julliand, and Olga Kouchnarenko

τ

q1 b

a

a

q1

τ τ

τ

b

a

l

Fig. 5.

5

Modular Refinement as a Simulation

m

l

m l l m

η l

m m y

ready

m

η

l 2

l

−1

m

1

l l

l l l y

m

def

simulation l

m l Modular Refinement as a τ -Simulation

5.1

m m l

m m

l 

2

η

l η  η l m l

l

m

1

l l

l y

l

m m l

m

l

η

y l ’

y

η

m m

l l

lm

l

l

l −

2

m

l η

−1 −

def

1

−2 −

2

η

def

 i I

l

− 

1

2

μ

2

η

m

2

i

l m l

1

i i

y

l

η

−

1

m 

η

2

m

m m η m l

2η 1

1

l l

m l

Ready-Simulation Is Not Ready to Express a Modular Refinement Relation

Definition 7. ( η ) Let  2 A 1τ 2 2 and two transition systems and η be a relation from 2 to τ a − −1 a −1 η η 2 η 1 if and only if 2 2 1 η

2

y

1

η m l

2

m

y m

l l m

1

τ a

Definition 8. ( 2 2 , we define

τ a

l

2

2

m

2

η m l

2

l

2

m

2

l

m

lm

l

τ a

l 2

l l

m

m

2

τ a

m

1

y

predicate transformer) Given the relation 2 2 2 by − a − 2 . 2 2 2

2

def

2

l m

y m l m

τ a

2

τ a

l l y

l m y

m l l l

y

 1 A 1 1 be η 2 1 . Define for all A 1.

1 1 −1

η m l

1

m l

275

lm m

2

η m l

2

2

y

1

Lemma 1. Let η be the relation between the two transition systems 2  1 A 1 1 1 . Let γ be the Galois connec 2 A 1τ 2 2 and 1 tion η  η . Then, we have τ a

Proof.

m

i

γ

2

m

l

i

τ a

m

l

1

i

2 τ a

m

lm

y

i

2

l

l l

i

l 

1 i−I 1 2

i’

i

m

l

y

l

1

i

γ lm

1

m

2

i τ a

τ a

γ

2

 2

i



i−I

l



 l

l



i−I

i−I τ a



τ a 2

τ a

2

i

1

2

i

l 

i

 l

y 1

l l

i i−I

1

i

276

Fran¸coise Bellegarde, Jacques Julliand, and Olga Kouchnarenko

Theorem 1. Let η be the relation between the two transition systems  1 A 1 1 1 . Then 2 η 1 .  2 A 1τ 2 2 and 1 l

l y

m

m

l

m

y

y

m

5.2

l l ly

m

Modular Refinement as a Generalization of the Ready-Simulation m y

l

m

m

l

η

l

m l l l

y y

mm

η m l l l

l

l y

2

readies

y A m

1

y

2

Theorem 2. Let 1 transition systems. If Proof.

2

a

2

 2 A 1τ readies

q2 s.t. q2 ηq1

2

2 2

a

2 2

be two

.

ly

y

l m ly

m

2

l 2

l

η m l l

l l m l y A 1τ

1

readies

y y

m l

1

 1 A 1 1 1 and η 1 then readies 1

mm mm

1

m l

l

m l l

l l

1 A 1  2 A 1τ Definition 9. Let 1 1 1 and 2 2 2 be respectively a transition system and its refinement. Let be in A 1 . The relation −1 and satisfying the 1 2 is the greatest binary relation included into following clause:  a readies 1 readies 2 (readies) 1 1 1− 1 2 q2 s.t. q1 ξq2

Theorem 3. Definition 6 and Definition 9 are equivalent. Proof. m

ly

mm mm m

y

m l

l y m lm y

m l

l

l

y l

Ready-Simulation Is Not Ready to Express a Modular Refinement Relation

6

277

Compositionality of the Modular Refinement l η

l l y m

m

ly

l ll m m l m l ll m

y

m

l

m

m l l

l

m l

m

Definition 10. (Parallel composition) Let i i A i i i and j j A j j j be two transition systems. The parallel composition of i and def − −  A τ where is the set of the ( j is i j i and − − is the union of A i and A j , is the product of i and j . Let j ), A , the transition relation is defined by combining A τ , for individual actions in parallel as follows.

α

1

[PAR1]

− k α − − − − −

m

l lm

2

m

Theorem 4. Let 1. 2.

2

4

4

2

η η

1

3

3

1

η

2

Proof.

m l ll m

and

1

4

η

− −

3.

m

l

m

2

3

1

3

2

a

− 2

− 4

4

1

4

η

− 1

3 3

2

2

a 1 a

2

τ

− − 4 2 − − 2 η − 1 3 y

− − 4 2

3

2

2

4

η

1

− 4

A

3

− 2

α

A

− 1

A S

4

1 1

3

l l

η

τ 1

a

l

− 1

− 2

a

2

a

− 1

1

A

y

3

m

l 2

y

η l

S

− 2

2

3

S

2 − 1

η

4

4

4

l

y − 2 − 2

4 1

l 4

l

def

4

a − 2 2 2 − − 2 η 1 y

l

m l S

S

l

We have:

l l

1

− k α − − −

l ll m

m η l l

l l y

α

[PAR2]

y − − 2

1

1

a

2 1

4 − 1

l 1

3

− 2

4

τ

278

Fran¸coise Bellegarde, Jacques Julliand, and Olga Kouchnarenko τ

4

4

− 4

l y 1

a

1

− 1

1

A

− 2

4

− 1

a

− − 4 2

S

− 1

1 − 2

− − 4 2

3

1

m m m m

7

l

l m

a

3

ly

A

2 η − 2 − − 4 2

3

l

m ly

3

y 2 − − y 2 − 1 3 2 4 − − − 4 1 3 2

1 − a 2 2

1 − 1

− − 2

4 s.t. − 2 4

− 3

3

m m l l

m

α

3

− − − 2 2 s.t.

m

1

− 3

l

y

l

m l y

m

η m

l

Example m

l

m l m m l m l m l m m m m l

m m m m l l y m l l l

l l

m

y l l y ly m

l

m

l l m

A

l

l m l

’

l

m

l

l

l y

l m

l l ly

y

y m

m l

y l l

m

m

l l m

m l l l l

m

m

y

m

b

l ly l l y l l l l l l m l

l l l

m m

b

5

l l

l

l

y

m

1

b l

m

m

l l l l l y

Ready-Simulation Is Not Ready to Express a Modular Refinement Relation

l l

m l

m

279

m

l

m l l

l

m y

2

m

l

l l y

−

def

l

−

−

m

m

y

l

l

l l l m

m

y

m l

m

2

y

l l

m l

l m

y

1

y

y m

y m

y

m

m m

l l

l

m l m

l

y

m 1 − 12

− 11

l

m

l l

1

l l

1

m

− 11

1

m l

m y

l

m l

m l y

m l l l

− 12

1

m

m l

l l l y l l

l y 1

m

y

m

m fl l l

y

fl

l m

m

y l l

m m

y

l 1

1

l

m

m l l y

8

Application y

l

l

y

m y

m

m y

l

m

m

m m l

y m

y

l m m

l m

l

y

l y

m y

m l l

y m

m

l

l l l l

y

m m

m m

y

m m y

m l m

m

y m l m

280

Fran¸coise Bellegarde, Jacques Julliand, and Olga Kouchnarenko

l l y y m m

l l l y m

l l

y

9

m l

l

l l

m

y

l l l m

m

m

m l

m

l

l m lm ly

m

l

ly y m l y

m fly m lm

m

l

l m

Conclusion and Related Works l l

m

l

m

l y

y y

l m y

m m l

m m

y

m m m

l

m

m

l y y

m m

l

l y m l l η l y y m η l l y l refusal simulation y l y l m l l l y m l l m l m m l m l η l m l l m m l l 1 m l m l m l 2 1 y ly m m l m l l l y m l m l y l l m l l l l l  l y l m y m l m l m l divergence sensitive stability respecting completed simulation l ’ m m m m l m l m m m l l m ’ m m m l m l l ll m l l m m m l m l y m y m m l l lm l m l l y

Ready-Simulation Is Not Ready to Express a Modular Refinement Relation

l y

y l y

m m l

l y

y

281

m

l

References [1] J. R. Abrial. The B Book. Cambridge University Press - ISBN 0521-496195, 1996. [2] J. R. Abrial. Extending B without changing it (for developing distributed systems). In 1st Conference on the B method, pages 169–190, Nantes, France, November 1996. [3] J. R. Abrial. Constructions d’automatismes industriels avec B. In Congr`es AFADL, ONERA-CERT - Toulouse, France, May 1997. Invited lecture. [4] J. R. Abrial, E. B˝ orger, and H. Langmoeck. Specifying and Programming the Steam Boiler Control. LNCS 1165. Springer Verlag, 1996. [5] J. R. Abrial and L. Mussat. Specification and design of a transmission protocol by successive refinements using B. LNCS, 1997. [6] J. R. Abrial and L. Mussat. Introducing dynamic constraints in B. In Second Conference on the B method, LNCS 1393, pages 83–128, Montpellier, France, April 1998. Springer Verlag. ´ EOR: ´ [7] P. Behm, P. Desforges, and J.M. Meynadier. MET An industrial success in formal development. In Second conference on the B method, LNCS 1393, Montpellier, France, April 1998. Springer Verlag. Invited lecture. [8] F. Bellegarde, J. Julliand, and H. Mountassir. Model-based verification through refinement of finite B event systems. In Formal Method’99 B User Group Meeting, CD-ROM publication, 1999. [9] B. Bloom. Ready Simulation, Bisimulation, and the Semantics of CCS-Like Languages. PhD thesis, MIT, August 1989. [10] B. Bloom, S. Istrail, and A. R. Meyer. Bisimulation can’t be traced. Journal of the ACM, 42(1):232–268, January 1995. [11] R. J. van Glabbeek. The linear time - branching time spectrum II: The semantics of sequential systems with silent moves. In Proc. CONCUR’93, Hildesheim, Germany, LNCS 715, pages 66–81. Springer-Verlag, August 1993. [12] J. Julliand, F. Bellegarde, and B. Parreaux. De l’expression des besoins `a l’expression formelle des propri´et´es dynamiques. Technique et Science Informatiques, 18(7), 1999. [13] J. Julliand, B. Legeard, T. Machicoane, B. Parreaux, and B. Tatibouet. Specification of an integrated circuits card protocol application using B and linear temporal logic. In Second conference on the B method, LNCS 1393, pages 273– 292, Montpellier, France, April 1998. Springer Verlag. [14] J. Julliand, P.A. Masson, and H. Mountassir. Modular verification of dynamic properties for reactive systems. In International Workshop on Integrated Formal Methods (IFM’99), York, Great Britain, 1999. [15] L. Lamport. A temporal logic of actions. 16:872–923, May 1994. [16] C. Loiseaux, S. Graf, J. Sifakis, A. Bouajjani, and S. Bensalem. Property preserving abstractions for the verification of concurrent systems. Formal Methods in System Design, 6:1–35, January 1995. [17] R. Milner. Communication and Concurrency. Prentice Hall Int., 1989. [18] H. Mountassir, F. Bellegarde, J. Julliand, and P.A. Masson. Coop´eration entre preuve et model-checking pour v´erifier des propri´et´es LTL. In submission AFADL’2000, 2000.

282

Fran¸coise Bellegarde, Jacques Julliand, and Olga Kouchnarenko

[19] O. Ore. Galois connections. Trans. Amer. Math. Soc., (55):493–513, February 1944. [20] A. Pnueli. System specification and refinement in temporal logic. In Proc. 12th Conf. Found. of Software Technology and Theor. Comp. Sci., New Delhi, India, LNCS 652, pages 1–38. Springer-Verlag, December 1992. [21] L. E. Sanchis. Data types as lattices : retractions, closures and projections. RAIRO Informatique Th´ eorique et Applications, 11(4):329–344, 1977. [22] J. Sifakis. Property preserving homomorphisms of transition systems. In Proc. Logics of Programs Workshop, Pittsburgh, LNCS 164, pages 458–473. SpringerVerlag, June 1983. [23] H. Treharne, J. Draper, and S. Schneider. Test case preparation using a prototype. In Second conference on the B method, LNCS 1393, pages 293–312, Montpellier, France, April 1998. Springer Verlag. [24] I. Ulidowski. Equivalences on observable processes. In Proceedings of the 7th Annual IEEE Symposium on Logic in Computer Sciences IEEE, New-York, IEEE Computer Society Press, pages 148–161, 1992.

Init

RoL

q0 L ExL

ExR

q1 U ExL

U

RoL

ExR

RoL

q2

q3 L

L

RoR ExR

q5

q4 U

ExL

U RoL

q6 ExR

L

ExL

q7

Fig. 6.

y

m

Ready-Simulation Is Not Ready to Express a Modular Refinement Relation

('/

('5

&' $'

y

Fig. 7.

ly

m

Init

q0

L ExL

ExR q1 U

U

q3

q2

ExL

L

ExR L

q5 q4

ExR

ExL U

U

q6

L

ExR

ExL

q7

Fig. 8.

y

m

283

Java Program Verification via a Hoare Logic with Abrupt Termination i i iv l

ui i

i

iv i ij {marieke,bart}@cs.kun.nl

Abstract. i li i i i li iv l i l i i i i i l i l i i i i l i i l i v lv l i i i i i l v l i v i v lvi il l i l

1

i

ui l l

i ul

i

i

l

i

i

l

i i l i i i i

i

i

ii

i

i

l

i

i i i i

li l

i

i i

l il l i

v

i i

i lu i

i l

l i

u

i l i

i u ul

i l l i i u i

i

i l

l l

i

i i

i

i l i li l ul

i

l

Introduction i

i

ij

i l i i u

i u ii u

l u i i l i l i i l i i ul i i l i

i i li

u

i l

i

i i l

i i i i l l i

i

ul i l u l u i li il i i i ul i i i l u i i il i u i i i i l i

u i li

u i l l u

i

u il

i

l i i

u i

l

i l

l l

l l

u i

i

i i l i

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 284–303, 2000. c Springer-Verlag Berlin Heidelberg 2000 

i i

i

l i

il i

l

i i

ii

i

v

l l i l i

i

i

i

i l u i i ju i

i

vi

i

il l i i

l i ul u

i

i

l

l

i

i

u l

l

u

i u

i i

i

i u l l

l

i

li l i

i l i l

i u i

l i

u l l ii i l l

i i u i l l l i i

i

u l

i l

i

for l

l return

i

il i i i

i

i i

i i

i e.g. u

l l u

l i l l uli i u i i l l u i lu i

u i i i

l l

i

il l l i

i

i

l

lift Self

Self i u

l

i

u

i

u

ii i

u l i l l

i l

e.g. i ii l

u i

i l u

u i

i u

0 i

i

ii u

i

u u

i

i u u i

i

ui i

i

i

i i u

i

i il u l

uli i il l

l l

l l i

l ii i

l i li

u u

i

Self

Self

i l l l i

i i

i ji

l i l il li l l

l

u

u

u

l

i i

i l i li

i l

i Self StatAbn

i StatAbn

u i i

iu i

u u u

stat

l li l i l

Exception

Self i

i

StatAbn

l

Return

u Break

StatAbn il l i l l e.g. i i u StatResult i l i i i i

Self

Out

i i

i

u

Continue

i i

i Self l l u i u

i

il l

i

i

Out i u i

u i

i

i i

u

ul l i l i i

i

u l i i u l i u i

i

i

u i

i Self

i i

i l

ui i u i

i

Self

ul

Out

ExprAbn

i

i

i l l

il l

i

u u

i u u

ul i ExprResult i

u i i u il l u ui l i i uli i u i i l i il l u i i i i i l il l i i ul i l u u i ul i l i li u l u l i i i l ii i ul il l i u i i i l ju i i u i i l i l i i e.g. i l i l l i i l i i l i i i i l u i l i i u i l i ul i l u i l i i i i i ul i i l u i i i i i u u i i i i Break Return ul i i l i l i l l l u i l j i i i u u u i u j i i i l l i i ju 0 l i u i l i i i l i l l i i l i i i u u i i i i i l l i i i l l i i i fl i u i i u l i i i i

i u u

Out

iu i u i

u i

i i

expr

u u

i

u

u

u Out

i

l li

i

Self i

i

l l uli i ExprAbn i i

l i i u u

l i

ii

i

i i i l i

i

u

i ul l i u l l l

l l

i u u

l

i l i i i il l ul i l i i u l

i l 0 u i i

i

i

i

l ui i i u i l i l i

v

i i ul i i

2

i

i i u u l l l u i

i

vi

i

l i

u i i u u u

i

i

i

l i l i

il l l i i i

l i i i

u i i

i u u

i

i

i

i

i

i

l l

Basic Type Theory and Logic

i l i i

l u

i i

l l il l i l i l i

i

l

l i l i

i

u

l l il i

i

l

u i i l α, β, . . . σ τ l l l l u σ, τ, σ1 , . . . , σn

u

i

l

i i

i nat bool string

i def

TYPE

uil u

l

il l 2

bot unit up α

u i

i i i ul i l l i

lab1 σ1 , . . . , labn σn i lab1 σ1 . . . labn σn u i ii i

u i

unit i

i

i

u

lift α l

1

l l

i lift i

u lα l

lu i λx σ. M l l u l lab1 l i i NL i Mi σi ii l l u lab1 σ1 , . . . , labn σn M1 , . . . , labn Mn i N lab1 σ1 , . . . , labn σn i i u i N.labi M σi i l l l i σi i il l l l u lab1 σ1 . . . labn σn labi M i N lab1 σ1 ... labn σn i i u i i i l xi σi i i n Li xi τ L1 x1 . . . labn xn Ln xn τ CASES N OF lab1 x1 i u i l i i i l l u u ui i β η i ul i i l i bool l lu i ju i i ju i i l i i i u i 1

i l lu

i i

v

l ll i

i l 2

l l i

i

ll i i

i

catch

i l

i

li

i

i

l

l l

ill i i l l

i il iv

switch

u

ll

l li

i

i i

l i iv

li

v

i

i

ul l i u i x IF ϕ THEN M εx σ. ϕ x i nat i i l l l

3

i

ll i true σ. ϕ x σ. ϕ ELSE N M, N li σ u lu l i i i

false ul ϕ l lu

i i

i u i i l l

ii i ii i

l

u i

Basics of Hoare Logic ii

l l i i

l i l l u i li i i ii l il l l i l l i l i ul i l l l l i i l i P S Q i l P S Q l i l i P Q i l i u u l l i l i S i l u i u i l P S Q i i P l i x if S l u i x i l l uli i i Q l i x l P S Q x i l i P l i x then S i x i l l uli i x Q l l l ul P S Q

Q T R

P S T R

P

comp

C S Q

P

C T Q

P if C then S else T Q P

C S P

P while C do S P

C

if

while

P i while ul i l l l i i l i l i l ul i i l l l i i ul il ii i i i l while true do skip i P i i P skip P u l i ul l l u P while true do skip P false ii u i i ul ul i u li l l u ui i i u ul i i l i l l i i i i l l i i l i i i l l i ul l il i

P

C

i

n S P

P while C do S P

i C

> G, f ◦ tG and f k G, tG → H, tH k by composition.

and a f > G, tG i

ty i

t

lt

i

t

i t lt l i lt t t t y t i it l t i ti t i t l l ty it i y i l ti l i i li ti t t t t l TG-typed graph rule i ty K, tK R, tR

t t i

i t t

t i

t t l ti

ti li

l t

i t t y GraphT G il i t l l t i t t y GraphP TG i l t l t t ti l i l t t t i it l r L, tL L, tL ← K, tK → R, tR t ty TG l, r -ty

Foundations for Software Configuration Management Policies

t

309

i lt L, tL i t t t t l t it t t t li l i t i t R, tR i i it L, tL lt t i it L, tL t i t K, tK t i t it y t R, tR l l i ti -ty l -ty l i t i l f f L , fK , fR -ty i t i l it t it t t tt i i t it i it i t t y RuleT G y Rule TG i Rule i lt lt i RuleT G

Definition 2 (Typed Graph Transformation System Specification). A ty t ti y t i ti t t i ti G TG, P, π consists of a type graph TG, a set of rule names P and a mapping π P →| RuleT G |, associating with each rule name a TG-typed rule. Definition 3 (Morphisms of Typed Graph Transformation Systems). G → G A morphism of tgts-specifications (tgts-morphism), f f T G , fP from G TG, P, π to G TG , P , π is given by an injective type graph morphism fT G TG → TG and a mapping fP P → P between the sets of π fP p for all p ∈ P . rule names, such that fT>G π p i t t i ti i t y l l TGTS l l i it t ty G∩G t t t t G Notation G G t π i π P ∩π P l t t P G i l l t i i i t t i ti G TG , P, π direct derivation p/m G G, tG i lp t i G, tG ⇒ H, tH y t l l i l t i i m L, tL → G, tG i i L, tL

l o

m

G, tG

K, tK

r 

h

k l o



R, tR



D, tD

r







H, tH l

r

π p L, tL ← K, tK → i GraphT G output p/m G, tG t input H, tH t G, tG ⇒ H, tH G p1 /m1 , . . . , pn /mn t i i m1 , . . . , mn i p 1 , . . . , pn ti G t tt t t t it i t i t i t i ti t l l i ti i i Der G t i G t

R, tR G, tG i l l ⇒ H, tH derivation G, tG i l i t i i ti i t i t t Gi t Der G l l i ty l

Proposition 1 (Preservation of Behavior). Let f G → G be a tgts-morphism. For each derivation d

f T G , fP ⇒ G, tG

310

Francesco Parisi-Presicce and Alexander L. Wolf

H, tH with d p1 /m1 . . . pn /mn in Der G there is a deriva⇒ fT>G H, tH in Der G , where f d tion f d fT>G G, tG > fT>G G, tG ⇒ fP p1 /fT G m1 . . . fP pn /fT>G mn . Moreover, fT d G, tG ⇒ H, tH . fT G H, tH t i t t l l

y lt i

t i t t

i G i

ty

l i i i t context it i t m

i

t

i i

t i t t t i l i ti

ti tt

i

lt i t

t

G’

l i t t t l i t

Definition 4 (Application Conditions). – An l i ti it i for a match m L → G is a total graph morphism ci L → L i . – A it i application condition ci is satisfied by m if there exists a (total) graph morphism n Li → G such that n ◦ ci m. – A t i application condition ci is satisfied by m if there is no (total) graph morphism n Li → G such that n ◦ ci m. – A it i l l is a rule p with a set of application conditions Cond and a derivation p/m G, tG ⇒ H, tH takes place only if the match m satisfies every condition in Cond. i i i

Notation t i a→b a→ci lt t y t t y b ×d c

3

t lt

t t

l l

t y i

t t y y b a c i il l b→d c→d

t

t

i

Formalization of CM Policies l l y

l i y

t i i t t l i t i t

i t

y t t i i

t

t l

t ti check in i l i y i t t i lt it t l l i t i il l t t

t ti

ti checked out t t i l i

i li l i y

i l l y iy i t l l i i t

t t y l l

l l t

i i l i ti

t

i t current i t it y l ti i t ti i t

t

i t t

t ti

i i

iy t i i t

i

t

t

Definition 5 (Policy). A policy A is a triple T, P os, N eg where – T C, T G is the type of the policy consisting of a set C of labels and a type graph T G

Foundations for Software Configuration Management Policies

311

– P os is a C, T G -graph transformation system – N eg is a set of C, T G -graphs and C, T G -graph morphisms The three components are denoted by T A , P os A and N eg A , respectively and GP os A denotes the set of graphs generated by P os A (starting from the empty graph). Interpretation t t i t ty t l i y it ty T G i i ti t i t it i it l it l ti t l y t t ii t i i i lt i l y l l ti t l li C ti l t i t ii i t t P os A i i t ti l l y t t t t l i y i t t t y i i t l t t i t i t t t t i t i l y y H ∈ N eg A i i t t t t i i H i i t y i N →E t i i N eg A i i t t t t i i N t l it t i l E l l y G i t l y H i t i i H →G Gi t l y N →E i y i ti i N →G t t i E→G t t N →E→G N →G l t l y y t Gi t l y N eg A i y G∈Gi N → E ∈ N eg A

t

Example 1. REV t t l l t lt y it t l i y i t ty

t t l lt t

t

it i l i it l TR

il lt t ii L K

t l t l l ti i t i i ti t t t t l l i i t tt ti t t l l - t ti t t i l y - t ti t ti t i t t it t ii t lt l i lt t t ti it i

it ti t

t

t t

t

l iz t i t i t l i y l y K → R i

l i y t

t i t t ti t ti t i - t t ii P os REV t i -i l ii lt t l l t i - t - t l y t l t t i i t l i t t l

312

Francesco Parisi-Presicce and Alexander L. Wolf

P os REV l t i t t l l l ti i i ti l l t i ti l l ti l it ty l t ti l l ti t i i t t l i N eg REV t i l y t t ti ii it l t t t t ti t

t

i l t t lt i t i t

t

t t

ti l y

ti

t

t ii

Definition 6. A policy A is t if GP os A satisfies N eg A , i.e., if its rules cannot generate a graph containing an unwanted graph. A coherent policy A is l if any graph not in GP os A is rejected by N eg A , i.e., if the positive and negative parts of A describe all the graphs over T A C, T G Example 2. t t i t i l t t l i y i t l y ii ii i y t t

t l

t t l

t

l

l y

t -

l i y REV i i - t ti t t ti t i t il t l y y t i t - t ti t

t t

t l i i it i l lt i y H ∈ N eg A t i t ity i H → H NOT t i t t i N →E i N eg A i l l t t t N eg A t t it l H←H→H N ←N →E t t t t i l i i y i t i t i i t t P os N eg i l i i ti l i y P ES i i t t l y t lt i ti t t i ti i ti l i y OP T i l l y i t l y t lt t i i i i ti l i y t l y t t t l y t ti i ti l i y il t t t i GP os P ES ⊆ GP os OP T t y t y OP T i l t y P ES i l it ti l i t lt i it t i l iz y t t l t it y OP T ti ti Definition 7 (Subsumption). A policy A a policy B of the same type C, T G if GP os B ⊆ GP os A and N eg A ⊆ N eg B . i

l iz

y

i

t

l i i

Definition 8 (Policy Morphism). A policy morphism f policies A and B is a triple fT , fP , fN where

A → B between

fC , fT G CA , T GA → CB , T GB is a pair consisting of a total – fT function and a total (untyped) graph morphism

Foundations for Software Configuration Management Policies

313

– fP P os A → P os B and fN N eg B → N eg A are tgts-morphisms as in Def.3 with respect to the type morphism fT . l i y A t t l t l lt Remark 1. t t i fN i i t t t t t l i y B t t ty i i l y t t i t t ty i i y fT l i y B l lt l fP i i t t t l i y A t t l lt t y A i t ty A B t t i t l t l i y i A → B t B A i i l t t fP lt t rules t t l i i t y t y t t i fP P os A → P os B y t GP os A ⊆ GP os B l i y

i

i t

il y

it i fN

fP t i

i

t i i fT G li t it i

fC

ti i

i t

i ti l l i

it t l t

t t t i

Theorem 1. The category P OLICY of policies and policy morphisms is closed under finite colimits t it i l y t t t l l t t t t t

t t l i y l i y A1 A0 A2 y t i t ti t i t l i i Ai t ti it 3

t

4

A0 → A2 A0 → A1 t t it i l l i y t t t t i l

i i

Relationships Between Policies t i l i

T0 it i

ti

i

i ti C0 , T G0

ti

t

t

i i

l

y i i

i i l i i t t i t l i i l i i t ty T C, T G l i t t t t y ty ty T1 C1 , T G1 i t t t → C1 , T G1 y l l i t -t ti

i C0 , T G0 fT lt i l i i t l t t i t N eg A N eg B t t i t l ti l i y t G i it i

i i i

– – –

y it A y A y t A

y ti t i B i B

t

i i t t i

i

ti ti

t

y B

l l y Definition 9 (Negative Strategies). For sets of morphisms N eg A and N eg B , define

314

Francesco Parisi-Presicce and Alexander L. Wolf

– CA N eg A , N eg B N eg A ∪ N eg B NB → EA EB NA → EA ∈ – CD N eg A , N eg B {NA N eg A , NB → EB ∈ N eg B } ∪{HA HB HA ∈ N eg A , HB ∈ N eg B } – DA N eg A , N eg B N eg A ∩ N eg B y CA N eg A , N eg B i it i t it i ti t t y tl t it i t y t l i i t it i t i i i t y t l i i i l y i t

Interpretation i t y l i y A y l i y B y i i t l i i DA N eg A , N eg B i it i t y i t t y ti l y i y CD N eg A , N eg B i it i t t

l i i t t

t t i

ti ti t

ti

t t t P os A l i i A

B

t l t t i P os B t t i t

t it i

y t

Definition 10 (Positive Strategies). Given graph transformation systems P os A and P os B , define – CA P os A , P os B – CD P os A , P os B – DA P os A , P os B

P os A ∩ P os B {pA pB pA ∈ P os A , pB ∈ P os B } P os A ∪ P os B

Interpretation t y CA P os A , P os B t t y t P os A P os B ti t t y t y DA P os A , P os B i l l lt i GP os A ∪ GP os B l it t t i y t i t ti t l t t t i t t y t y CD P os A , P os B t t i y t i t i i t i t y P os A y P os B l i i i y l ti t t y t ti t t ti t Definition 11. Given policies A and B, the combination of A and B with strategies X and Y is denoted by X, Y A, B and is the policy C where P os C X P os A , P os B and N eg C Y N eg A , N eg B for X, Y ∈ {DA, CD, CA} t

l t

i i

l i i

i

t

i

t

l i ti

t

it i Proposition 2. If A and B are policies such that there exists a policy morphism from A to B, then 1. DA, DA A, B 2. CA, CA A, B

B A

Foundations for Software Configuration Management Policies

315

i l i i i l i i i t i l i y ti l t t l i i t it t t t t t t l i y i t i t y i i t i t l i y i i t t i i ti l t t i ti i l i t i it i t extreme y i t t i t t ti l i i t i i i l l y ti l y ti t t i t t ti ti t t l i i t it

i t l i t i i t y t t l i i t i ti i t i l y t t i i l i i t t t t l i i l l t

Proposition 3. 1. If A and B are coherent, then C herent 2. There exist coherent policies A and B such that D coherent.

CA, CA A, B is co-

l ti

Proof. t i GP os C N eg A ∪ N eg B i G ∈ N eg C i t y t A G ∈ N eg A t Bi i i t ty l lt a b l i y A ty it i l t t t t i ty i l y t t P os D ty b t t

t t i

DA, DA A, B is not

⊆ GP os A ∩ GP os B N eg C i H ∈ GP os C t it B t i ti t A i G ∈ N eg B t l i i i ti i lt B l y l ti t ty a b t l i i t l l b ty a t l i i t i it ty a t y it i N eg D

l t t y t

t

t

t

t

t

Proposition 4. If A and B are coherent, then CA, X A, B is coherent for any X ∈ {CA, CD, DA} Proposition 5. (a) For any X ∈ {CA, CD, DA}, if X, CA A, B is coherent, then so are X, CD A, B and X, DA A, B (b) There exist coherent policies A, B, P , and Q such that CD, DA P, Q and CD, CD A, B are not coherent. i l l l i

it

i l i y t

t t

l

t

i

t

il

Theorem 2. If DA, CA A, B is coherent, then X, Y A, B is coherent for any X, Y ∈ {CA, CD, DA} Example 3. t i t l i y REV t

l i y V AR t l

t

ty t

ti

t

i

TR TV i t

t i

t

316

Francesco Parisi-Presicce and Alexander L. Wolf

t P os V AR -i l lt t l l t - t l y

ti

t i i t i - t

lt t

i t lt t t P os V AR l t i l t t i t it i i ti l l ti N eg V AR t i l y t i t it l t t t t t ti

i it i y t t l i i REV it two i t i t l

TR

l i y M

CLAIM t t

i t i

i t

t i

i t t ty

i

l l i

l y

ti

t

- t ti t t t ti t t it t

t

i

l l l ti t ti t t t

t t

t ii

t t

ti i

t

t

l i y t

ty ti

DA, CA REV, V AR i

l y i

t

t

l REV V AR t t t l REV i t t l i P os V AR t t no i t t l i ti t TR it

ti i ty

t

t

t V AR i V AR ti

t

t

t

t

t i i l y t

ti

l DA, CA i

l iz t it

t i l i i i l i y i

t

t t it i t

Theorem 3. Let A and B be coherent policies over types TA and TB , respectively, and fA T → TA , fB T → TB type morphisms with f T → TA T TB . Denote by A∗ and B∗ the policies A and B, respectively, viewed over the type TA T TB . The policy DA, CA A∗, B∗ is coherent if and only if the policy DA A∗, B∗ , N EG is coherent, where n}. N EG {n ∈ N eg A∗ ∪ N eg B∗ f > f < n

Foundations for Software Configuration Management Policies

t i t t DA, CA A∗, B∗ it t t t ty t l t i ti it i l

t t l i y l t i li

t

317

t i

l l

-

l i i

Definition 12. Policies A and B over the same type are GP os A GP os B and N eg A N eg B .

i l t if

Proposition 6. Policies A and B are equivalent if and only if A subsumes B and B subsumes A. Theorem 4. Given closed policies A and B, DA, CA A, B is coherent if and only if A and B are equivalent

5

Conclusion i

i

i

t t i t

–

y t t

t ti l t ti

t

il l t

t

t

i

t

il t l

it t l i i

l i ti t t

t i i

lt t

DA CA CD t l i y ili i tti l i i t t l t t l i y i t t t y t i ti it l 0 t i i t l i i i t it i l ti t l t i il t t ti y t i l i l i i l t l lt t l i y t it y

i

t

t -

t ti

y y

t ti l

l i i

iyi

y

l i y

l l y t t

ti t

l

l

t i t t it i t lt i i

i t

l

t ti

lt

t it i l l

i

t

l

ti y t t lt l t i ity t i i it i t il i l l i t ti t t t l l ti i ti l l i y t

t

t t l ti l

l i t l i i

t t

i ti

l l l l l ty it i l t

– t i

i

l l t t l t t

t t

i

ti l i

i

t

–

t l l t t t

l i i y ti y P os l l

i l y it N eg l l it i t

t l l t i ti t t lt t t t lt t i t l i i t t l i y t t t il l ti t

l ii i t t

l iti

318

Francesco Parisi-Presicce and Alexander L. Wolf

References [1] B. Berliner. CVS II: Parallelizing Software Development. In Proceedings of 1990 Winter USENIX Conference, pages 341–352. USENIX Association, January 1990. [2] A. Carzaniga. Distributed Versioning System Manual, Version 1.2. Department of Computer Science, University of Colorado, Boulder, Colorado, June 1998. [3] R. Conradi and B. Westfechtel. Version Models for Software Configuration Management. ACM Computing Surveys, 30(2):232–282, June 1998. [4] A. Corradini and R. Heckel. A compositional approach to structuring and refinement of typed graph grammars. In Proc. SEGRAGRA’95 (Graph Rewriting and Computation), volume 2 of ENTCS, pages 167–176. Elsevier, 1995. [5] M. Große–Rhode, F. Parisi Presicce, and M. Simeoni. Spatial and temporal refinement of typed graph transformation systems. In Proc. MFCS’98 (Mathematical Foundations of computer Science), volume 1450 of Lecture Notes in Computer Science, pages 553–561, 1998. [6] M. Große–Rhode, F. Parisi Presicce, and M. Simeoni. Refinements of graph transformation systems via rule expressions. In Proc. Sixth Intl. Workshop on Theory and Application of Graph Transformations (TAGT’98), Lecture Notes in Computer Science, 1999. To appear. [7] D. Heimbigner and S. Krane. A Graph Transformation Model for Configuration Management Environments. In SIGSOFT ’88: Proceedings of the Third Symposium on Software Development Environments, pages 216–225. ACM SIGSOFT, November 1988. [8] Y.-J. Lin and S.P. Reiss. Configuration Management with Logical Structures. In Proceedings of the 18th International Conference on Software Engineering, pages 298–307. Association for Computer Machinery, March 1996. [9] T. Mens. Conditional Graph Rewriting as an Underlying Formalism for Software Evolution. In Proceedings of the International Symposium on Applications of Graph Transformation with Industrial Relevance, Lecture Notes in Computer Science. Springer-Verlag, 1999. To appear. [10] F. Parisi Presicce. Transformations of graph grammars. In Proc. 5th Int. Workshop on Graph Grammars, volume 1073 of Lecture Notes in Computer Science, pages 426–442, 1996. [11] M.J. Rochkind. The Source Code Control System. IEEE Transactions on Software Engineering, SE–1(4):364–370, December 1975. [12] G. Rozenberg, editor. Handbook of Graph Grammars and Computing by Graph Transformation, volume 1. World Scientific, New Jersey, 1997. [13] W. Tichy. Tools for Configuration Management. In Proceedings of the International Workshop on Software Versioning and Configuration Control, pages 1–20, January 1988. [14] W.F. Tichy. RCS, A System for Version Control. Software—Practice and Experience, 15(7):637–654, July 1985. [15] A. van der Hoek, A. Carzaniga, D.M. Heimbigner, and A.L. Wolf. A Reusable, Distributed Repository for Configuration Management Policy Programming. Technical Report CU–CS–849–98, Department of Computer Science, University of Colorado, Boulder, Colorado, September 1998. [16] B. Westfechtel. A Graph-Based System for Managing Configurations of Engineering Design Documents. International Journal of Software Engineering and Knowledge Engineering, 6(4):549–583, December 1996.

Analyzing Non-functional Properties of Mobile Agents

Irisa/Inria, Campus Universitaire de Beaulieu, 35042 Rennes, France {fradet,issarny,rouvrais}@irisa.fr

Abstract. The mobile agent technology is emerging as a useful new way of building large distributed systems. The advantages of mobile agents over the traditional client-server model are mainly non-functional. We believe that one of the reasons preventing the wide-spread use of mobile agents is that non-functional properties are not easily grasped by system designers. Selecting the right interactions to implement complex services is therefore a tricky task. In this paper, we tackle this problem by considering efficiency and security criteria. We propose a language-based framework for the specification and implementation of complex services built from interactions with primitive services. Mobile agents, Rpc, remote evaluation, or any combination of these forms of interaction can be expressed in this framework. We show how to analyze (i.e. assess and compare) complex service implementations with respect to efficiency and security properties. This analysis provides guidelines to service designers, enabling them to systematically select and combine different types of protocols for the effective realization of interactions with primitive services.

1

Introduction h .

h

h-

h .

h h

h

h

. h .

h Rpc-

1

-

. .

h

h

.

Rpc Rpc h

h

h

h

h

9. h h

h 1

h

h

h

h h

h h h

.

h vice versa .

In our context, we consider them both as degenerate forms of mobile agents. Remote evaluations execute remotely the code on a single server. A Rpc amounts to sending a request (not a code) to a primitive service.

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 319–333, 2000. c Springer-Verlag Berlin Heidelberg 2000 

320

Pascal Fradet, Val´erie Issarny, and Siegfried Rouvrais

h

h h

h

.

Pda .

h

h

h

h

. h h

Rpc h

-

h h

h

.

h

h

-

h

h

h

-

h

-

.

h

h

h h

.

h

h

h

-

.

h h h.

h . . h

h

h

h

-

.

h

h h h Rpc

h

. h h

.

h

h

h

h .

h

h

h

h

. h

h

h

.

h

h

h h

h

h

. h

.

2

h .

h

h

h

h h

h

h

.

h

h

h fl

.

h h h

h

h

h

h .

.

2

Functional Models of Interactions . .

h . .

. .

.

h

Analyzing Non-functional Properties of Mobile Agents

. -

. h

h

. h

h

h h

h

h

-

.

h

h

h h

. h

h h

2.1

. h h

h h concrete level Rpc h h h

.

h

h abstract level

-

h

321

h

-

h .

Abstract Language

h

. h . Service

Treatment . Data h -

h h h h

h h . h

h

e

h 2 .

E ::= (E, ..., E) where

|

fE

|

d

f ∈ Primitive = Service ∪ Treatment and d ∈ Data

Fig. 1.

Ea : Expa → Env → V alue Ea [[(E1 , . . . , En )]] e = (Ea [[E1 ]] e, . . . , Ea [[En ]] e) Ea [[f E]] e = (e f ) (Ea [[E]] e) Ea [[d]] e = ed

Fig. 2.

322

Pascal Fradet, Val´erie Issarny, and Siegfried Rouvrais

h

Examples. h s

h

h d

.

-

h t

h

.

h

tsd h

h .

Rpc h

h

h d

. h s t

d h h

h

h . .

h

.

h

h

h .

h

h h t

t

h

h

h

h

h

.

h t s1 d1 , s2 d2 , t3 s3 d3

2

h h d3 h . .h t

t3 s2

t3 s3 d3 h

-

s3

h

h

h d2

h s1

h s2 d2 fl h

h

d1 fl h

h

h

.

h . s1

s2

h

h

s3

h

.

h h

2.2

.

Concrete Language

h

h

. -

.

h -

. . . h

h

h

Rpc A

. D. h h

-

-

h

Cps

. h

f

. A

h

Analyzing Non-functional Properties of Mobile Agents

f

. h Cps f

h h f Ad

h go h

A

A d.

h h

j

h

. j2.

. h

h h

.

h

.

d

h h i

goi,j

fd

323

h

h

h h h h end -

.

E ::= let (r1 , ..., rn ) = A D in E A ::= f A | goid1 ,id2 A | end D ::= (D1 , ..., Dn ) | d | r

|

D

where f ∈ P rimitive, idi ∈ Place, and d ∈ Data

Fig. 3.

Ec : Expc → Env → V alue Ec [[let (r1 , ..., rn ) = A D in E]] e = (λ(r1 , . . . , rn ).Ec [[E]] e)(Ac [[A]] e (Dc [[D]] e)) Ec [[D]] e = Dc [[D]] e Ac [[f A]] e Ac [[goid1 ,id2 A]] e Ac [[end]] e

= e f (Ac [[A]] e) = Ac [[A]] e = λd.d

Dc [[(D1 , ..., Dn )]] e Dc [[d]] e

= (Dc [[D1 ]] e, ..., Dc [[Dn ]] e) = ed

Fig. 4.

Examples. h h Rpc . . . . 2

ts d h h

h h

.

Actually, even if some migrations could be deduced from the locations of base services, the go functions are needed to specify where treatments are to be executed.

324

Pascal Fradet, Val´erie Issarny, and Siegfried Rouvrais

h s

t .

h

d h

.

h

d in in s

h h

h

goc,1 s t go1,c end

let r1 r1

h Cps h

goc,1 go1,c . h -

h

t

h

goc,1 s go1,c end t end r1

let r1 let r2 r2 h

s

. c Rpc-

h

d in

h

. .

.

h 2

.

h

h

s3 Rpc s3

t3

h let let let let r4 -

h h

. .

h

h s1

h s1

s2

h h

goc,3 s3 t3 go3,c end d3 goc,2 s2 go2,c end d2 goc,1 s1 go1,c end d1 , r2 t end r3 , r1

r1 r2 r3 r4

in in in in

h h

-

h

h h

h h

-fl

h s2 let let let let r4

h

.

h h

h

s 1 s2

h 2

r1 r2 r3 r4

h s3

Rpc goc,3 s3 go3,c end d3 t3 end r1 goc,2 s2 go2,1 s1 go1,c end t end r3 , r2

h

h

d1 , d2

-

- .

h .

-

h h

in in in in

.

Analyzing Non-functional Properties of Mobile Agents

S1

S1

s1(d1,s2 d2)

d1 + s2 d2

s1(d1,s2 d2)

d1 + s2 d2

t

s2 d2

S2

d1 + d2

t

C

S2

C

d2

t3

d3 + t3

t3(s3 d3)

d3

s3 d3

S3

t3

S3

(a) Concrete expression 1

(b) Concrete expression 2

h

Fig. 5. 2.3

325

From Abstract to Concrete Expressions h

h

. h

h

h

h

h

h

h

h

.

h

h

p

h . . h h

h h h

h h h

.

h h

h

h

h

-

h t3 s 3

h

. .

s2

s1

t

h

h h

s3

t 3 s3

. .

t3 .

h

.

h h

h

h

. -

p . h Abs2Conc

h h

ll h h

.

Abs2Conc h h -

h

h h

l . .

. .

326

Pascal Fradet, Val´erie Issarny, and Siegfried Rouvrais

Abs2Conc h

h

SubExp h

E SubExp t3 s3

SubExp t3 s3 s2

h

E1 , . . . , En

l.

t s1 d1 , s2 d2 , t3 s3 d3

t3 s3 d3

t s1 d1 , s2 d2 , t3 s3 d3

s2 d2 , t3 s3 d3

Abs2Conc : Expa → List(List(Primitive)) → (Expc, Env) Abs2Conc E nil e = (E, e) Abs2Conc E (l.ll) e = let (E1 , ..., En ) = SubExp(l,E) in let (X1 , e1 ) = Agent[[(E1 , . . . , En )]] l client end e in let (X2 , e2 ) = Abs2Conc E[ri /Ei ] ll e1 in (let (r1 , . . . , rn ) = X1 in X2 , e2 ) Agent : Expa → List(Primitive) → Place → Cont → Env → (Exp, Env) Agent[[E]] nil i k e = (goclient,i k E , e) Agent[[(E1 , . . . , f Ei , . . . , En )]] (f.l) i k e = Agent[[(E1 , . . . , Ei , . . . , En )]] l (p f ) (f (go(p f ),i k)) e[f ← λc.λ(x1 , . . . , xn ). c (x1 , . . . , e f xi , . . . , xn )]

h

Fig. 6.

h Agent.

h h h

h Agent h

h end p.

h Cps

h

-

-

h h h

h h

. Cps e

h

goi,j fl .

h

h

h h

h Ec , ec

Property h

h

Abs2Conc Ea ll ea ⇒ Ea Ea ea

Ec Ec ec

Abs2Conc h

.

h h

Analyzing Non-functional Properties of Mobile Agents

h

h . h

h

h h Abs2Conc h

327

h h

w.r.t h h

h

h

.

h .

2 n−1

n

h p

h hp h

.

Abs2Conc.

3

Analyzing Performance and Security Properties h .

h

h

h . h

h

j

... . via . h

h

h

j h .

h

h

h h

.

. 3.1

Performance h

h es h

h

h ef . h .

es h

ef

sf . . sf size x 3 . . .

h

h h h size f x .

h . h

es h h .

3

h

h

h h

f

h f

h

h

h

h

.

. h ef

h h CostE ef h raison d’etre es

. goi,j

Numerical values are easy to normalize and compare whereas symbolic values are more generic and represent more faithfully the reality. Both fit in our framework and we do not dwell on this issue any further in this paper.

328

Pascal Fradet, Val´erie Issarny, and Siegfried Rouvrais

. h

h

-

goi,j A h

h

E

h di . h h

CostA ef h go h h i j .

h

h h

αi,j

Sum d d s

αgo

h

h h

h

h

h h

h

h h

h

Sum d . . h

h

h h

h

. h h

Source A d. h

A

αi,j s h

ri

h

h i

h

j

. . h

.

CostE : Expc → Env → Size CostE [[let (r1 , . . . , rn ) = A D in E]] ef = let (d1 , . . . , dn ) = Ac [[A]] ef (Dc [[D]] ef ) in CostE [[E]] (ef [ri ← di ]) + CostA [[A]] ef (Source[[A]]) (Dc [[D]] ef ) CostE [[D]]ef =0 CostA [[f A]] ef s d CostA [[goi,j A]] ef s d CostA [[end]] ef s d

= ef f (CostA [[A]] ef s) d = CostA [[A]] ef s d + if i = j then 0 else αi,j (s + Sum d) =0

Source[[f A]] Source[[goi,j A]] Source[[end]]

= es f + Source[[A]] = αgo + Source[[A]] =0

Fig. 7.

h

Example. h d ← s ←

ef es h h h

h t h let

E, ef

tsd

s ← λx. 7 t ← λx.xdiv 5 t ← Kb h s h h h h s . h ll h

h

4

Abs2 Conc t s d

ll ef in CostE E

Mb t

ef

Kb

Analyzing Non-functional Properties of Mobile Agents

h j

go αgo Rpc

h

h

h

h

h h

h

h . . Kb

h Mb

h h

h

Kb .

h h h

. h

h 3.2

i 7 2 .2 . . . Kb Mb 6 2 .2 . h

h

h

.

αi,j

h

329

.

h

Security h h

-

h

h

. h

.

h . h .

h

h h

h

h

h h

h

h

. h

j

h .

.

es

h

h h

h

ef .

f

h ef

h

h . .

. h h -

. h h

h h .

.

h 

h d.

ConfE h

d

. .

h .

. h h

h ef

 ⊥ h j

h Lub h h

h

h

h

h

4

h sf

-

h

h

f

h

h .

4

h

h es

h ConfA

h Lub A

-

h

client h

h h h

.

When there is no knowledge on the security of a place, the lowest security level should be taken.

330

Pascal Fradet, Val´erie Issarny, and Siegfried Rouvrais

h h



h d

es p . h

h

h

h

c

h

h

h

h

h goi,j

h

h

h h j αi,j .

i

h

ConfE : Expc → Env → Bool ConfE [[let (r1 , . . . , rn ) = A D in E]] ef = let (d1 , . . . , dn ) = Ec [[A]] ef (Dc [[D]] ef ) in ConfE [[E]] (ef [ri ← di ]) ∧ ConfA [[A]] ef client (Lub [[A]]) (Dc [[D]] ef ) ConfE [[D]] ef = true

F

ConfA [[X]] ef p c d

= ( d c) es p ∧ Case X in f A : ef f (ConfA [[A]] ef p c) d goi,j A : ( d c) αi,j ∧ ConfA [[A]] ef j c d end : true

F

Lub Lub Lub Lub

[[t A]] [[s A]] [[goi,j A]] [[end]]

= = = =

(es t) Lub [[A]] Lub [[A]] Lub [[A]] ⊥

h

Fig. 8.

h

h

h . h

-

h h h h

h h

h

4

. h h

h h

j

h .

Practical Uses of the Model h .

h

h h

h

h Rpc

h

h

.

Corba h h

.

h

h h

h

Analyzing Non-functional Properties of Mobile Agents

.

h h

h

h h

h .

h

h .

h

331

h

h

h

h

h

h

.

h h h

h

. . h

h h . .

h

.

h – Refinement of component.

h . h

h

h

h

h

. .

h

h

h

.

h

h .

h

h

h

h

h

h h

h

.

h

h

h h

Rpc. .

– Verification. h . h h – Adaptation.

h

h

h

h

-

h

h .2

h h

h

.

h

h -

h h

.

. h

h

h

h

.

h

h

h

-

h -

h

.

.

h h

h

h -

h

.

5

Conclusion h

-

.

vs

Rpc h

. . .

. h

h

h h

h

332

Pascal Fradet, Val´erie Issarny, and Siegfried Rouvrais

.

h

2 h

h

.

h

h h h .

Rpc

h h

h

h

h

. h π-

.

. . h .

h

-

-

h

h

h

h

h

.

h

h

h

h

h

. .

h

h .

h h

h h

-

..

h

. .

h

h

h

h

-

h h

.

h.

h

h

h

.

2

h

h . .

. h .

h

-

h h -

. .

. .

h

h

h

h h

.

h

-

h h h

h h h Aster Rpc h

h

. h .

h

h

h h h

h .

-

Acknowledgments h 5

h

h C3ds

j

5

.

Control and Coordination of Complex Distributed Services. Esprit Long Term Research Project Number 24962 - www.newcastle.research.ec.org/c3ds

Analyzing Non-functional Properties of Mobile Agents

333

References [1] L. Cardelli. Abstractions for mobile computations. In Jan Vitek and Christian D. Jensen, editors, Secure Internet Programming, Security Issues for Mobile and Distributed Objects, volume 1603 of LNCS, pages 51–94. Springer, 1999. [2] Antonio Carzaniga, Gian Pietro Picco, and Giovanni Vigna. Designing distributed applications with mobile code paradigms. In R. Taylor, editor, Proceedings of the 19th International Conference on Software Engineering (ICSE’97), pages 22–32. ACM Press, may 1997. [3] David M. Chess, Colin G. Harrison, and Aaron Kershebaum. Mobile agents: Are they a good idea? Research report RC 19887, IBM Research Division, T. J. Watson Research Center, Yorktown Heights, NY 10598, february 1994. [4] David Garlan and Mary Shaw. An introduction to software architecture. In V. Ambriola and G. Tortora, editors, Series on Software Engineering and Knowledge Engineering, Vol 2, Worlds Scientific Publishing Company, pages 1–39. 1993. [5] IKV++ GmbH. Grasshopper - www.ikv.de/products/grasshopper/index.html. [6] L. Ismail and D. Hagimont. A performance evaluation of the mobile agent paradigm. In Proceedings of the Conference on Object-Oriented Programming, Systems, Languages, and Applications, pages 306–313, 1999. [7] Val´erie Issarny and Titos Saridakis. Defining open software architectures for customized remote execution of web agents. Autonomous Agents and Multi-Agent Systems Journal. Special Issue on Coordination Mechanisms and Patterns for Web Agents, 2(3):237–249, september 1999. [8] Dag Johansen. Mobile agent applicability. In 2nd International Workshop on Mobile Agents, MA’98, Stuttgart, Germany, volume 1477 of Lecture Notes in Computer Science, pages 80–98. Springer, september 1998. [9] Danny B. Lange and Mitsuru Oshima. Seven good reasons for mobile agents. Communications of the ACM, Multiagent Systems on the Net and Agents in Ecommerce, 42(3):88–89, march 1999. [10] Nenad Medvidovic and Richard N. Taylor. A framework for classifying and comparing architecture description languages. SIGSOFT Software Engineering Notes, 22(6):60–76, november 1997. [11] Jonathan T. Moore. Mobile Code Security Techniques. Technical Report MSCIS-98-28, University of Pennsylvania, Department of Computer and Information Science, may 1998. [12] Gian Pietro Picco. Understanding, Evaluating, Formalizing, and Exploiting Code Mobility. Ph.d. thesis, Politecnico di Torino, Italy, february 1998. [13] John C. Reynolds. The discoveries of continuations. Lisp and Symbolic Computation, 6(3/4):233–248, november 1993. [14] T. Sander and C. Tschudin. Towards mobile cryptography. In Proceedings of the IEEE Symposium on Research in Security and Privacy, Research in Security and Privacy, Oakland, CA, may 1998. IEEE Computer Society Press. [15] T. Sekiguchi and A. Yonezawa. A calculus with code mobility. In Chapman and Hall, editors, Proc. 2nd IFIP Workshop on Formal Methods for Open Object-Based Distributed Systems (FMOODS), pages 21–36, London, 1997. [16] Markus Straßer and Markus Schwehm. A Performance Model for Mobile Agent Systems. In H. R. Arabnia, editor, Proceedings of the International Conference on Parallel and Distributed Processing Techniques and Applications PDPTA’97, pages 1132–1140, Las Vegas, 1997.

Specification of an Automatic Manufacturing System: A Case Study in Using Integrated Formal Methods k

m ¨

l

m l m [email protected]

m

Abstract. l

m m integrated formal method m lm CSP-OZ m l m ll l m l l m m architectural view

l m l

m

m l ll

l

m l

l

1

m

l

ll

Introduction m

m w

m

w

m

m

m

m x m

m m

m software

w m

m m

m

w

w

m m

m

m

m

w m m

m

m m

w m

m

x w w m

m w m



m

m

ll l

m

mm l

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 334–348, 2000. c Springer-Verlag Berlin Heidelberg 2000 

m

w m

m

m 1

w m m m

w m

m

w w

m

m m

m

holonic manufacturing system m w m kw m fl x m m m w m w m w m w k w k w k w k mm w w m

activities m m m

w m

m m

m

m

w m

m w

w

mm

m

w

m

fl w

m

m k

w m m

m

m

m

m w k m

m

w k

w w m

w mm

m

w

m m

x

mm

m

m m

communications m m

m

x

m

w

m

x

k

w

m

m m

k m

x

mm k

m

w k m

m deadlock-freedom

k m

m w

w

m m

m 1

k l

ml

m

m

2

CSP-OZ object-oriented formal method x w

m

m

w m

m

mm m

w channels

k

m m

m

m

m

w w fl m x m

m w Name formal parameters inherit superclass

inherited superclasses

chan channelname main . . .

channel definitions CSP-Part

type and constant definitions state schema, initial state schema operation schemas m

Z-Part

attributes m x

methods m w

m

m

m

enable

effect predicates w m m m

x

m w

m

m

input m w fl w mm object references O w w x m O m inherit m m m w x

m

m

m

chan x m

mm x

m output x mm m

O .m w

simple m m

O

mm

m.O m

m m m

m m

m w

x synchronisation constraint data-independent m

m m

m

w

m

Buffer

m

Element Element Buffer chan put [ elem Element ] chan get [ elem Element ] main put x → get x → main Init contents

P Element

contents

?

contents ≤ enable put

effect put Δ contents elem Element

?

contents

contents ∪ {elem}

contents enable get

effect get Δ contents elem Element

contents

elem ∈ contents contents contents \ {elem} contents put w m

get x

m

m

m

m Δ

m

m

m

put

get

m m

w m

w w

Buffer 2.1

CSP Operators x m

w

→ w

x m

w

m

w

fl

m

x

m

– – |||

m

||A

w

w

A m

x

m m

A

m

– \A – 2

x

A m

x

m – name ← name m

fl

m

m

name

name ||| a A •

m

P a

m x

P a w

w

w

a

timeout

A m

w

m

P Q w P

m P m P

w Q k Q

m

m m 00

3

Specification x w

m

m m

m w m

w

m Out w k T ,T ,... A B

w

m w k x m

k

m

m

In

m w m

m

m

w k m C

w k In → A → B → C → Out w k w m w m

m w k m w m

w w

m

w m

m

w k

w

ww k w m w m

m w

m

x

w

w k

m w

m

object-oriented m m w

m w m

m

class diagram m m m m w

w

m w m

x w generalisation

x m

m

classes w associations

m

w

m w

compositions m w w w w k m active mm m

w

x m m

communication m m m w

m

w m w m w

m m m m

k m

m w

m m

mm

w

names

m

m w

m

w

m

Communication

Wzm

requst

Machine

Hts

listen

full offer loadMachineHts loadHtsMachine order

Store full loadMachineHts loadHtsMachine

111 000 000 111 000 111 000 000 111 111 000 111

setPosition arrived

acquireOrder newOrder

gotoMachine Driver

Acquisition

whichPosition

m

Fig. 1. m m

w

Machine k cation w

m

m

m Wzm Hts m w

m

m

Store

m m

m

w CommuniHts m Driver

k mm

m w m

Acquisition Hts

m m

Driver

Acquisition Class specifications. w w

m w

w m

w

m

w m

Workpiece Hts

m

w k

Wzm m

Store Workpiece Hts {T1 , T2 } Machines Stores ∪ Wzm Coord Status Coord w mm m w k w k

N

Wzm Store

{A, B , C } {In, Out }

m w k m × N , Status {finished , notFinished } Machine m m m m m w m

Machine id Machines chan full [ h Hts m {id } b B ] chan loadHtsMachine [ h Hts m {id } w Workpiece ] chan loadMachineHts [ m {id } h Hts, w Workpiece ] Init contents P Workpiece contents ? capacity N 1 contents ≤ capacity effect full b B b

contents

capacity

enable loadMachineHts contents 

?

effect loadMachineHts Δ contents h Hts, w Workpiece w ∈ contents

enable loadHtsMachine contents < capacity

effect loadHtsMachine Δ contents h Hts, w Workpiece contents

contents ∪ {w } w

w

m

m

x

m

w k m

m

m

m

w

w

m

w Communication m w

w m x mm

w m m

m

LISTEN w mm

w

mm w

w

synchronous m m m mm w m w m x mm m w m m w x m m w m mm w m mm w w m m w mm m BROADCAST to from comm m

Communication BROADCAST to, comm ||| rec to • comm x .rec y → SKIP SKIP LISTEN from, comm ||| sender from • comm from x y → SKIP SKIP

Wzm m Communication w m conjunction parallel composition

Machine m w w m

m k

w

m

w m w k m

w k w

w w

m Communication Wzm m k w

m Wzm

w m w

m w m

m w

m m

w

m

w m m k

w m

m

Wzm inherit Machine, Communication chan process, choose, noOffers chan request [ h Hts m {id } b B ] chan offer [ h Hts m {id } cost N ] chan order [ h Hts m {id } ] main FULL ||| WORK FULL full x → FULL WORK FINDHTS loadHtsMachine x → process → FINDHTS loadMachineHts x → WORK FINDHTS BROADCAST Hts, request LISTEN Hts, offer CHOOSE CHOOSE choose → order x → SKIP CHOOSE 2 noOffers → FINDHTS Init offers status

status Status offers Hts × N orderTo Hts enable request status

effect request h Hts, b B

finished

b effect offer Δ offers h Hts, cost offers

 finished

contents 

?

enable choose

N offers a  h, cost

offers 





effect choose Δ offers, orderTo

∃ n ∈ N orderTo , n offers ∧ ∀ h, m offers n ≤ m offers offers Hts × N \ { orderTo , n } effect order h Hts h

enable noOffers offers



orderTo

w m

main w

w choose

m w

m m

m

w

m

w

Hts w Driver Acquisition w w m

w

m

Hts Acquisition w

m

k m

k

m Driver Acquisition Hts m

Acquisition w w k

w w m

w

w m

k

w

m

w m w k full

k ASK w

m

m

x

w m

m

w w m

m m

Acquisition

Hts m

k

w

m

w Acquisition master Hts inherit Broadcast chan newOrder [ ord Wzm × B ] chan whichPosition [ pos Coord ] chan listen [ h {master } wzm Wzm b B ] chan offer [ h {master } wzm Wzm cost N ] chan order [ h {master } wzm Wzm ] chan requestsThere, noRequests, emptyRequests, acquireOrder main acquireOrder → whichPosition x → FINDORDER FINDORDER LISTEN Wzm, listen requestsThere → ASK offer x → order x → newOrder x → main emptyRequests → FINDORDER emptyRequests → FINDORDER 2 noRequests → FINDORDER 2 noRequests → FINDORDER ASK ||| ma Machines • full x ma y → SKIP Init currRequests P Wzm × B currRequests ? orderFrom Wzm position Coord

m w m m

m

effect newOrder Δ currOffers ord Wzm × B first ord orderFrom, ord ∈ currRequests currOffers ? effect whichPosition Δ pos Coord pos

effect emptyRequests Δ currRequests currRequests

position

enable noRequests currRequests

enable requestsThere

?

currRequests 

effect listen Δ currRequests wzm Wzm, b

B

currRequests

currRequests ∪ { wzm, b }

enable offer currRequests 

? ?

effect order Δ orderFrom wzm Wzm

?

orderFrom effect offer Δ wzm Wzm, cost

wzm

N

∃ b ∈ B wzm, b ∈ currRequests ∧ ∀ m, q ∈ currRequests • dist position, target wzm, b ≤ dist position, target m, q function target determines the position of the target of the request cost dist position, place wzm effect full Δ currRequests wzm Wzm, b

B

currRequests currRequests \ { w , f • if f then next w wzm ∧ b ∨ if ¬ f then prev w wzm ∧ ¬ b }

m

m

m

k

w

w

System specification. m w compoHts Acquisition m m w w

m

m m

m Driver m

Hts w

m

m m Driver Acquisition A {whichPosition} Hts w Driver Acquisition {setPosition, setId , arrived , gotoMachine, newOrder , acquireOrder } m w w Wzm w m request offer w w k m w Hts

B Hts

Wzm compoHTS id Hts id ||B Driver id ||A Acquisition id m

m

\ A ∪ B listen ← request

m

m

m w loadHtsMachine w

m

w

m

m

m m

m w

m simple Store In

w C D

m

loadMachineHts.In w loadMachineHts.A

x m Wzm A

Store In ||C ||| hts Hts • compoHTS hts ||D ||| wzm Wzm • Wzm wzm ||E Store Out

AutoManuSystem

w

m

w

{loadMachineHts.In, full .T .In, full .T .In}, {loadMachineHts.A, loadMachineHts.B , loadMachineHts.C , loadHtsMachine.T .A, loadHtsMachine.T .B , loadHtsMachine.T .C , loadHtsMachine.T .A, loadHtsMachine.T .B , loadHtsMachine.T .C ,

m

full .T .A, full .T .B , full .T .C , full .T .A, full .T .B , full .T .C , request , offer , order }, {loadHtsMachine.T .Out , loadHtsMachine.T .Out ,

E

full .T .Out , full .T .Out }. m

m

m

m m m

m w

w

m

w k

m

mm

mm

m m

k k

4

m

m

m

m

m w

x

ww

m

Verification m

m

m

w

k

w m

m m

w m m m

m

w

w

m

w m

w

m w Workpiece m

... 0 × ... 0

m m

m Coord

w

m

k

w w k

m

m any m x

k 2

w k

2

m m l m

k m m

m k w

w k k k w k

m m

k m l

m

x

m

ll

m l m

m

w m

m

w k

m

w

hiding

process w k

w

w k

w m

x m

m m

w

w

w m

k

00

m w

w

m

w

m m w

5

m

k

Conclusion w

m w

w m

m

w m

x w m

m m

m

m

m

m w

m k

m m

w w m m

k

m

k m

w

m

w

x

m m w mm

m

m x w w

m

References m

m l Manual

m

l Computer Standards and Interfaces Failures-Divergence Refinement: FDR2 User

m m Formal Methods for Open Object-Based Distributed Systems (FMOODS ’97) l m m ll

m m l ll Proceedings of the 1st International Conference on Integrated Formal Methods (IFM) μ l Semantics of specification languages m ll

l m Int. Conf. of Formal Engineering

Methods (ICFEM) Communicating Sequential Processes ll l m The 20th International Conference on Software Engineering (ICSE’98) m l m l Proceedings of the European Joint Conference on Theory and Practice of Software l m LNCS m OMG Unified Modeling Language Specification m

Revised working draft on enhancements to LOTOS

(V4) The Theory and Practice of Concurrency m

m

m

m Proceedings of FME 1997 m

m

ll

l l m

LNCS

The Object-Z Specification Language

l

m

l The Z Notation: A Reference Manual m m m l l m

l l m

ll m l

l

m

m International Symposium on Future Software Technology (ISFST) ¨m

¨ m

l m m Holonic manufacturing systems

A Case Study on Using Automata in Control Synthesis Thomas Hune and Anders Sandhol m 

m m v m {baris,sandholm}@brics.dk

m

Abstract. m m v

m m

m m

v

m

m

Mona

m

v

m m

1

m

Introduction

In t he fol l owing we wil ldescribe some pract icalexperience on sy nt hesizing programs for t he LEGO® RCX™ sy st em. The sy nt hesis is based part l y on an exist ing simpl e program and part l y on an aut omat on generat ed by t he t oolMona [7]. l y if a Writ ing cont rolprograms can oft en be an error prone t ask, especial number of specialcases must be t aken int o account . Time is oft en spent on handl ing specialcase or fail ure sit uat ions rat her t han sol ving t he act ualprobl em at hand. A number of different met hods and t ool s have been devel oped t o ease t his t ask. One wel lknown met hod is based on a cont rolaut omat on running in paral l elwit h t he act ualprogram [12 , 13]. The aut omat on cont rol s t he input and out put event s of t he program. This is a way of rest rict ing t he sequences of I/O act ions occurring. The aut omat a cont rol l ing t he I/O act ions can be specified in different way s, y in some suit abl e not at ion, or by a l ogicalformul a. e.g. by specify ing it direct l We have chosen t he l at t er approach. There are various l ogics which coul d be used as specificat ion l anguage. We have chosen t o use monadic second order l ogic over lM2L has a number of nice st rings (M2L) [2 ] for a number of reasons. First of al propert ies such as being expressive and succinct . For inst ance, having second order quant ificat ion M2L is more expressive t han LTL. Furt hermore, t here are succinct M2L-formul ae of size n which have minimalcorresponding aut omat a of non-el ement ary size. Secondl y , t he t oolMona [7] impl ement s a t ransl at ion from M2L formul ae t o minimaldet erminist ic aut omat a (MDFA) accept ing t he l anguage specified by t he formul a. The aut omat a generat ed do not cont ain any 

m

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 349–362, 2000. c Springer-Verlag Berlin Heidelberg 2000 

m

m

accept ance condit ion for infinit e execut ions so we wil lonl y be considering safety propert ies. The met hod we st udy here is a variat ion of cl assicalsy nt hesis as described in e.g. [10 , 12 ], in t hat t he met hod is part l y based on an exist ing cont rolprogram. The aim of t he sy nt hesis described here is t o rest rict t he behavior of an exist ing (hopeful l y very simpl e) cont rolprogram such t hat it sat isfies cert ain given propert ies. The execut ions of t he exist ing cont rolprogram are rest rict ed by t he cont rolaut omat on having I/O event s as al phabet . These event s define t he int erface between t he exist ing cont rolprogram and t he specificat ion. For st udy ing t he met hod we wil ll ook at a cont rolprogram for a moving crane. We have impl ement ed t he met hod for t his exampl e in t he LEGO® RCX™ sy st em [9]. Using t he LEGO® RCX™ sy st em is int erest ing for at l east two reasons. l y t he programFirst of al lt he environment of t he RCX™ sy st em and especial ming l anguage is quit e rest rict ed, so it is not obvious t hat impl ement ing t he met hod is feasibl e at al l . Secondl y , using t he LEGO® RCX™ sy st em one can buil d act ualphy sicalsy st ems for t est ing t he cont rolprograms. We have buil t t he crane and used it wit h different cont rolprograms. The l anguage running on t he LEGO® RCX™ brick (RCX™ l anguage) is an assembl y -l ike l anguage wit h a few high l evelfeat ures, l ike a not ion of t ask or process. Programs are writ t en on a PC and downl oaded t o t he RCX™ brick where t hey are int erpret ed. 1.1

Related Work

The use of finit e st at e aut omat a for cont rol l ing sy st ems is not novel . Ramadge and Wonham [12 ] give a survey of cl assic resul t s. The met hod used in t his paper has been used successful l y in [13], a t oolfor specify ing and generat ing int eract ive Web services. Our met hod for cont rolsy nt hesis is used as an int egralpart of t o define safety const raint s. In fact , via use of a powerfulmacro mechanism [1] t he met hod has been used t o ext end t he Web programming l anguage in wit h concept s and primit ives for concurrency cont rol , such as, semaphores and monit ors. 1.2

Outline of the Paper

lout l ine t he met hod. A short present at ion of t he In t he fol l owing sect ion we wil LEGO® sy st em is given in Sect ion 3. In Sect ion 4 t he crane exampl e is present ed. The l ogic-based specificat ion l anguage is present ed in Sect ion 5, and t he merge of aut omat a wit h t he RCX™ code in Sect ion 6. Final l y , Sect ion 7 rounds off wit h concl usions, and suggest ions for fut ure work.

2

Outline of the Method

The two main component s of t he sy nt hesis is a basic cont rolprogram and an aut omat on. From t hese two component s we generat e a cont rolprogram which

m

is ready for use. We do not have any specialrequirement s t o what a cont rol program is, l ike no side effect s, since in our case t he cont rolprogram is t he onl y program running on t he RCX™ brick. The int erface between t he two component s is a predefined set of I/O act ions. This wil lty pical l y be al lcommands in t he program for reading sensors or manipul at ing act uat ors. Given a basic cont rolprogram and an impl ement at ion of t he aut omat on we merge t hese. Each inst ruct ion in t he basic cont rolprogram using one of t he I/O l ing t he aut omat on act ions is t ransformed t o a sequence of inst ruct ions first cal and based on t he response from t he aut omat on performing t he act ion or not . Sect ion 6.3 wil ldiscuss different approaches t o what shoul d happen, when a given act ion is not al l owed by t he aut omat on. Since t he aut omat on is invoked onl y when t he basic cont rolprogram is about t o make an I/O act ion, it can onl y rest rict t he possibl e I/O behaviors of t he cont rolprogram, not add new I/O act ions. Onl y l ooking at sequences of I/O act ions t he basic cont rolprogram must t herefore be abl e t o generat e al lseut ion. Since t he aut omat on wil lprune away unwant ed quences present in t he sol sequences, t he basic cont rolprogram might al so generat e unwant ed sequences. The basic cont rolprogram shoul d not impl ement any kind of priority scheme, lnot l ead unl ess one is sure t hat combining t his wit h t he safety specificat ion wil t o deadl ocks. The hope is t hat writ ing such basic cont rolprograms shoul d be a simpl e t ask. In generalt he basic cont rolprogram coul d be one al way s being abl e t o read any sensor and give any command t o t he act uat ors. This amount s t o generat ing t he st ar operat ion of t he input al phabet . However, t here wil loft en be a correspondence between input and out put which it woul d be nat uralt o have in a basic t he cont rolprogram. This is t he case in t he exampl e shown l at er. One coul d see t he basic cont rolprogram as impl ement ing t he met hod for cont rol l ing t he sequences of I/O act ions and t he aut omat on defining t he al l owed pol icy for t hese. This suggest s t hat wit h one impl ement at ion of a basic cont rol program it is possibl e t o t est different specificat ions or st rat egies (pol icies) onl y by changing t he cont rolaut omat on. Therefore, a fast (aut omat ic) way of get t ing an impl ement at ion of an aut omat on from a specificat ion and merging t his wit h t he cont rolprogram al l ows for t est ing different specificat ions fast .

3

The LEGO® System

The st udies we have conduct ed are based on t he LEGO® RCX™ sy st em and t he associat ed RCX™ l anguage. The l anguage is an assembl y l ike l anguage wit h some high l evelconcept s l ike concurrent t asks. The l anguage is rest rict ed in a number es and al l ows onl y t en of way s, e.g. it is possibl e t o address onl y 32 int eger variabl t asks in a program. Furt hermore, one cannot use sy mbol ic names in programs. However, we have not encount ered probl ems wit h t he ment ioned rest rict ions during our experiment s. ing A smal loperat ing sy st em is running on t he RCX™ wit h processes for handl I/O and one process running an int erpret er for t he RCX™ l anguage. The RCX™

m

m

brick has t hree out put port s (for mot ors and l ight s) and t hree input port s. Four kinds of sensors for t he input port s are suppl ied by LEGO®: t ouch, t emperat ure, rot at ion, and l ight .

3.1

The RCX™ Language

A program consist s of a col l ect ion of at most t en t asks. There is no specialway lvariabl es are shared, providing a way of t o communicat e between t asks but al communicat ion. A t ask can st art anot her t ask wit h t he command StartTask(i) and st op it wit h t he command StopTask(i). St art ing a t ask means rest art ing it from t he beginning. That is, t here is no command for resuming t he execut ion of a t ask nor spawning an ext ra “inst ance” of a t ask. The l anguage has some commands for cont rol l ing t he act uat ors, t he main ones being On(li) and Off(li) where li is a l ist of port s. The commands SetFwd(li) and SetRwd(li) set s t he direct ion of t he port s in li t o forward and reverse respect ivel y . There are al so a number of inst ruct ions for manipul at ing es. Al lof t hese t ake t hree int eger argument s. The first argument specifies variabl t he t arget variabl e, t he second t he ty pe of t he source, and t he t hird t he source. The most import ant ty pes of sources are: variabl es (t he t hird argument is t hen t he number of t he variabl e), const ant s (t he t hird argument is t hen t he val ue), and sensor readings (t he t hird argument is t hen t he number of t he sensor). These ty pes of sources can be used in t he inst ruct ion SetVar(i,j,k) for assigning a val ue t o a variabl e. In t he inst ruct ions for cal cul at ing l ike SumVar(i,j,k), SubVar(i,j,k), and MulVar(i,j,k) sensor readings are not al l owed. Loops can be defined in two way s, eit her by t he Loop(j,k) inst ruct ion or by t he While(j,k,l,m,n) inst ruct ion. The argument s of t he Loop indicat es how many t imes t he body shoul d be it erat ed in t he same way as t he source of t he inst ruct ions for cal cul at ing. The While l oop is it erat ed as l ong as t he condit ion specified by t he argument s is sat isfied. The first two and l ast two argument s at ion specify t he sources of a comparison as in an assignment and l specifies a rel from t he set {=, , =}. There is al so a condit ional , If(j,k,l,m,n), wit h t he condit ion specified as in t he While const ruct and an Else branch can be specified as wel l . One can bl ock a t ask for a given t ime using t he Wait(j,k) st at ement . When t he specified t ime has passed, execut ion of t he t ask is resumed. During execut ion a t ask is eit her enabl ed or bl ocked. A t ask can be bl ocked by a StopTask(i) inst ruct ion, by a Wait(j,k) inst ruct ion, or by finishing it s execut ion (reaching t he end of t he code). Init ial l y onl y t ask zero is enabl ed. The ed t asks are execut ed in a round robin fashion, where each t ask execut es enabl one inst ruct ion and t hen l eaves cont rolfor t he next t ask. The st at ement s present ed above const it ut e t he part of t he RCX™ l anguage which we have used for impl ement ing cont rolaut omat a.

m

4

Example

As an exampl e we wil ll ook at a crane which we wil lprogram in t he RCX™ l anguage. We have buil t t he crane and t est ed it wit h different cont rolprograms. The crane is run by t hree mot ors connect ed t o t he RCX™. One mot or is driving t he wheel s, one is t urning t he t urret around, and one is moving t he hook up and down. The input for t he t hree mot ors are t hree t ouch sensors, which is al l t he RCX™ brick has room for. This means we can onl y t urn mot ors on and off. Therefore t he crane al t ernat es between moving forward and backward each t ime l ed in a t he mot or is t urned on. The direct ion of t urret and t he hook is cont rol simil ar way . A very basic cont rolprogram for t he crane coul d consist of four t asks. One t ask for set t ing up t he sensors and mot ors, and st art ing t he ot her t asks. For each of t he t hree input s, one t ask for monit oring input and cont rol l ing t he mot or y . Task 1 for monit oring sensor 0 woul d t hen be correspondingl BeginOfTask 1 Loop 2, 0 ’An infinite loop SetFwd "0" ’Set direction of motor 0 to forward SetVar 1, SENSOR, 0 ’Var1 := Sensor0 While VAR, 1, 3, CONST, 1 ’While Var1 != 1 SetVar 1, SENSOR, 0 EndWhile On "0" ’Start motor 0 Wait CONST, 100 ’Wait SetVar 1, SENSOR, 0 ’Var1 := Sensor0 While VAR, 1, 3, CONST, 1 ’While Var1 != 1 SetVar 1, SENSOR, 0 EndWhile Off "0" ’Stop motor 0 Wait CONST, 100 ’Wait ... repeat the code replacing SetFwd "0" with SetRwd "0" ... EndLoop EndOfTask

The Wait st at ement s ensures t hat one t ouch of t he sensor is not read as two t ouches. We coul d of course have t est ed for t his but for our exampl e t his wil l do. The two ot her t asks for cont rol l ing t he remaining two mot ors l ook simil ar, onl y t he numbers of variabl es, sensors and mot ors are different . l ust rat ing t he present ed met hod we choose t o pl ace t he For t he purpose of il fol l owing const raint s on t he behavior of t he crane. First of al lwe onl y want one t hing happening at a t ime, so we wil lnot al l ow for two mot ors t o be t urned on at t he same t ime. Pressing t he t ouch sensor coul d now be seen as a request lt he mot ors which t he cont rolprogram may grant (and st art t he mot or) when al are st opped. Moreover, we want t hat moving t he hook has higher priority t han t he wheel s and t he t urret . Request s from t he ot her two are handl ed in order of arrival . The first const raint on t he behavior is basical l y mut ualexcl usion which ement in t he RCX™ l anguage (t his is an int egrat ed part of is nont rivialt o impl

m

m

t he impl ement at ion of t he aut omat a-based approach described in Sect ion 6). On t op of t his we have a mixed priority and queue scheme.

5

Logic-Based Specifications

Basical l y we coul d keep t he init ialsimpl e cont rolprogram if we had a way of pruning out some unwant ed execut ions. To be abl e t o impl ement t he const raint s we have t o change t he init ialcont rolprogram sl ight l y . This is done by considering t ouching a sensor as a request . The mot or can be t urned on when t he request is accept ed. Even wit h t hese changes t he program is st il la simpl e t o writ e. Execut ion of t he program gives rise t o a sequence of event s. In our case we wil l consider input (request s), and two kinds of out put (st art and st op mot or) as event s. We t hen impl ement t he aut omat on accept ing t he l anguage over t hese event s sat isfy ing t he int roduced const raint s. Wit h t his approach we can t hus keep t he cont rolprogram simpl e. Tradit ional l y , cont roll anguages are described by aut omat a which are in some ogic cases a good formal ism t o work wit h. However, having experience in using l for specify ing propert ies, we wil lt ake t hat approach here. In t his sect ion we describe t he use of a l ogic formal ism from which we can aut omat ical l y generat e aut omat a.

5.1

Terminology

An automaton is a st ruct ure A = (Q, q in , Σ, →, F ), where Q is a set of st at es wit h init ialst at e q in ∈ Q, Σ is a finit e set of event s, →⊆ Q × Σ × Q is t he t ransit ion σ rel at ion, and F ⊆ Q t he set of accept ance st at es. We shal luse q1 → q2 t o denot e (q1 , σ, q2 ) ∈→. A sequence w = σ0 σ1 . . . σn−1 ∈ Σ is said t o be accepted by t he aut omat on A if t here exist s a run of A which reads t he sequence w and ends up in an accept ing st at e q. So we have q1 , . . . , qn−1 ∈ Q and q ∈ F , such σn−1 σn−2 σ σ ldenot e by L(A) t he language t hat q in →0 q1 →1 . . . → qn−1 → q. We shal recognized by an aut omat on, t hat is, L(A) = { w ∈ Σ | A accept s w }. In order t o be abl e t o define t he not ion of a l egalcont roll anguage, one part it ions t he event set Σ int o uncontrollable and controllable event s: Σ = Σu ∪ l abl e event s can be disabl ed by t he cont rolaut omat on at any Σc . The cont rol t ime, whereas t he uncont rol l abl e ones are performed aut onomousl y by t he sy st em wit hout any possibl e int erference by t he cont rolaut omat on, which merel y has e event has occurred. Thus a t o accept t he fact t hat t he part icul ar uncont rol l abl cont roll anguage must in some sense, which is defined precisel y bel ow, respect t he uncont rol l abl eness of cert ain event s. Furt hermore, since our met hod onl y al l ows rest rict ions concerning safety propert ies, it does not make sense t o have osed l anguages as cont roll anguages. That is, we define t he not ion non-prefix-cl of cont roll anguage as fol l ows.

m

Let pre(L) denot e t he prefix cl osure of a l anguage L, and l et unc(L) denot e cl osure of L under concat enat ion of uncont rol l abl e event s. That is, l et pre(L) = { v ∈ Σ | ∃w ∈ Σ : vw ∈ L } and unc(L) = { vw ∈ Σ | v ∈ L ∧ w ∈ Σu }. l ed a control language if it sat isfies t he Al anguage, L over Σ = Σu ∪ Σc is cal two propert ies pre(L) = L and unc(L) = L. When using det erminist ic finit e st at e aut omat a t o specify set s of sequences, checking for prefix cl osedness is easy . One just has t o make sure t hat al lt ranarl y , checking sit ions from non-accept ing st at es go t o non-accept ing st at es. Simil cl osure under concat enat ion of uncont rol l abl e event s is st raight forward for det erminist ic aut omat a. What is new here, in comparison t o t he use of our met hod in [13], apart from l abl e and t he new domain of LEGO® RCX™ robot s, is t he part it ion int o cont rol uncont rol l abl e event s and t he resul t ing addit ionalrest rict ions and comput at ions. 5.2

Specification Logic

It woul d be nice if inst ead of convert ing t he informalrequirement in Sect ion 4 int o an aut omat on, one coul d writ e it formal l y in a specificat ion formal ism cl oser t o nat urall anguage. That is, we woul dl ike t o be abl e t o writ e somet hing l ike t he fol l owing. – Onl y one mot or can be t urned on at a t ime; – If t he wheel s get t urned on, t hen t he hook must not be request ing and t he wheel s must have been t he first t o make a request ; and – If t he t urret get s t urned on, t hen t he hook must not be request ing and t he wheel s must have been t he first t o make a request . We t herefore t urn t o a formal ism t hat is as expressive as finit e st at e aut omat a and y et st il lal l ows for separat ion of t he decl arat ivel y specified requirement s (previousl y our cont rolaut omat on) and t he operat ionalpart of t he cont rolprogram (t he exist ing RCX™ program). Experience has shown t hat l ogic is a suit abl e specificat ion formal ism for cont roll anguages. For t he purpose of defining cont rol l ers for LEGO® RCX™ robot s, we have chosen t o use M2L. One might argue in favor of ot her specificat ion formal isms such as high-l evelPet ri Net s [6] or Message Sequence Chart s [11]. Being a l ogic formal ism, however, M2L has t he advant age t hat specificat ions can be devel oped it erat ivel y , t hat is, one can easil y add, del et e, and modify part s of a e t ext ualformat . Moreover, t he formal ism in specificat ion. It al so has a readabl use shoul d be simpl e enough t hat a runt ime checker, such as an aut omat on, can act ual l y be cal cul at ed and downl oaded t o t he RCX™ brick. Thus, M2L is powerfuland y et just simpl e enough t o act ual l y subject it t o aut omat ed comput at ion. anguage for defining cont rolrequirement s Experience in using M2L as a l has shown t hat onl y t he first -order fract ion of t he l ogic is used in pract ice [1,

m

m

13]. We shal lt hus consider onl y first order quant ificat ions, t hough second-order quant ificat ions coul d be added at no ext ra cost . The abst ract sy nt ax of t he l ogic is given by t he fol l owing grammar: φ ::= ∃p : φ | ∀p : φ | ¬φ | φ ∧ φ | φ ∨ φ | φ ⇒ φ | σ(t) | t < t t ::= p | t + 1 That is, M2L has t he const ruct s: universaland exist ent ialquant ificat ions over first order variabl es (ranging over posit ions in t he sequence of event s), st andard bool ean connect ives such as negat ion, conjunct ion, disjunct ion, and impl icat ion, and basic formul ae, σ(t), t o t est whet her an event σ can be found at posit ion t, so has operat ions and t < t , t o t est whet her posit ion t is before posit ion t . It al on t erms, such as, given a posit ion t one can point out it s successor (t + 1), and simpl e t erm variabl es (p). A formul a φ in M2L over t he event set Σ wil l– when int erpret ed over a finit e sequence of event s w – eit her eval uat e t o t rue or t o fal se and we shal l y . The language associat ed wit h φ is writ e t his as w |= φ or w |= φ, respect ivel anguage associat ed wit h an M2L formul a is L(φ) = { w ∈ Σ | w |= φ }. The l guarant eed t o be regul ar. In fact , it has been known since t he sixt ies t hat M2L charact erizes regul arity [2 , 4]. The Mona t oolimpl ement s t he const ruct ive proof of t he fact t hat for each M2L formul a t here is a minimaldet erminist ic finit e st at e aut omat on accept ing t he l anguage of t he formul a. That is, Mona t ransl at es a part icul ar M2L formul ae, φ, int o it s corresponding minimaldet erminist ic finit e st at e aut omat a (MDFA), A, such t hat L(φ) = L(A). Example 1. Let Σ = {a, b, c}. The M2L formul a to l eft ∀p, p : (p < p ∧ a(p) ∧ a(p )) =⇒ ∃p : p < p < p ∧ b(p )





 ()*+  i  / /.-,

 ) /.-, ()*+  



 ()*+ / /.-,



is t rue for sequences in which any two occurrences of a wil lhave an occurrence of b in between. Using Mona, one can comput e t he aut omat on corresponding t o t he formul a above. The resul t ing aut omat on appears t o t he right . Example 2. Wit h t his l ogic-based specificat ion l anguage in pl ace, we can writ e a specificat ion of t he requirement s given in t he exampl e. The l ogic-based specificat ion l ooks quit e compl ex at first . However, because of it ’s modul ar st ruct ure we find it easier t o handl e t han t he aut omat on. The basic formul ae for t he el ement s of t he al phabet are req1(t), req2(t), req3(t), turnon1(t), turnon2(t), turnon3(t), turnoff1(t), turnoff2(t), and turnoff1(t). The first t hree are uncont rol l abl e event s of t he al phabet and t he rest are cont rol l abl e event s of t he al phabet . A predicat e is t rue if t he event at posit ion t is t he ment ioned event . Using t hese basic predicat es we can define some basic predicat es l ike al lmot ors are st opped by :

m

off1(t) = (∀t : t < t ⇒ ¬turnon1(t )) ∨ (∀t : (t < t ∧ turnon1(t )) ⇒ ∃t : t < t ∧ t < t ∧ turnoff1(t )) Simil arl y , we define predicat es off2(t) and off3(t) and using t hese we can define a predicat e, alloff(t), specify ing t hat al lt he mot ors are t urned off. al l off(t) = off1(t) ∧ off2 (t) ∧ off3(t) We can specify t hat mot or 1 has been request ed t o be t urned but has not y et been t urned on by t he fol l owing predicat e: request 1(t) = ∃t : t < t ∧ req1(t ) ∧ (∀t : (t < t ∧ t < t) ⇒ ¬turnon1(t )) Predicat es request2(t) and request3(t) are specified simil arl y . Using t his we can define a predicat e specify ing t hat t he first request which has not been acknowl edged is one. req1first(t) = req1(t) ∧ ∀t : (t < t ∧ request1(t ) ∧ ∀t : (t < t ∧ t < t) ⇒ ¬request1(t )) ⇒ ((req2 (t ) ⇒ ∃t : t < t ∧ t < t ∧ ¬req2 (t )) ∧ (req3(t ) ⇒ ∃t : t < t ∧ t < t ∧ ¬req3(t ))) arl y . Wit h Again, predicat es req2first(t) and req3first(t) are specified simil t hese basic predicat es as buil ding bl ocks we can give a specificat ion cl osel y rel at ed t o t he informalrequirement s of t he exampl e. ∀t : (turnon1(t) ∨ turnon2(t) ∨ turnon3(t)) ⇒ al l off(t) ∧ ∀t : turnon2(t) ⇒ (¬req1(t) ∧ req2 first(t)) ∧ ∀t : turnon3(t) ⇒ (¬req1(t) ∧ req3first(t)), An informalspecificat ion for t he cont rolof t he crane cont aining t hree propert ies was given in Sect ion 5.2 . Each of t hese propert ies corresponds t o one of t he l ines in t he predicat e above. For inst ance t he first l ine of t he predicat e specifies t hat if a mot or is t urned on t hen al lt he mot ors are t urned off. This corresponds t o t he first property t hat onl y one mot or can be t urned on at a t ime. Simil ar for t he remaining two l ines and propert ies. Since our basic cont rolprogram specifies t he order of t he event s in t he indil vidualt asks (first req, t hen turnon, and t hen turnoff), t his specificat ion wil define t he want ed behavior. From t his specificat ion Mona generat es t he minimaldet erminist ic aut omat on which has 46 st at es and 2 76 t ransit ions (six from each st at e). e in such a way t hat Shoul d we want t o change t he cont roll anguage of our exampl al lt hree t asks have equalpriority , t he overal lst ruct ure of t he cont rolaut omat on woul d change. As t he fol l owing exampl e wil lshow, modify ing t he l ogicalformul a is indeed quit e comprehensibl e in t he case of t he LEGO® crane requirement s.

m

m

Example 3. Say t hat we woul d l ike t o change t he requirement s such t hat al l mot ors are given equalpriority , t hat is, t hey wil lbe t urned on in a first come first served manner. Using t he l ogic-based specificat ion, al lwe have t o do is t o change t he l ast two l ines of our specificat ion sl ight l y resul t ing in t he fol l owing fifo requirement . ∀t : (turnon1(t) ∨ turnon2(t) ∨ turnon3(t)) ⇒ al l off(t) ∧ ∀t : turnon1(t) ⇒ req1first(t) ∧ ∀t : turnon2(t) ⇒ req2 first(t) ∧ ∀t : turnon3(t) ⇒ req3first(t). Not e t hat t he sub-formul ae, such as, alloff() and req2first() are reused at ivel y easy t o change t he from t he previous specificat ion. As we can see it is rel specificat ion using t he previousl y defined primit ives. From t his specificat ion Mona generat es an aut omat on wit h 79 st at es and 474 t ransit ions.

6

Merging Automata and RCX™ Code

Given a cont rolaut omat on and t he basic cont rolprogram, one can sy nt hesize t he compl et e cont rolprogram. In t his sect ion we describe how t o t ransl at e an aut omat on int o RCX™ code and how t his is merged wit h t he exist ing RCX™ d be cl ear cont rolprogram. For our exampl e we have done t his by hand. It shoul from t his sect ion t hat onl y st andard t echniques are used and t hese can easil y be carried out aut omat ical l y. 6.1

Wrapping the RCX™ Code

The execut ion of t he basic cont rolprogram is rest rict ed t o sequences al l owed by a cont rolaut omat on as fol l ows. First l y , RCX™ code is generat ed for t he cont rol aut omat on and t hen t his code is merged wit h t he exist ing RCX™ code. Merging RCX™ code wit h an aut omat on can in some sense be considered a program t ransformat ion. Each st at ement invol ving a request or writ ing t o an out put port ock of code t hat t est s whet her t he operat ion is l egalaccording is repl aced by a bl t o t he cont rolaut omat on. For our exampl e an act ion shoul d be del ay ed if t he cont rolaut omat on does not al l ow it . Transforming t he code for t urning mot or 0 on, wil ll ead t o t he fol l owing piece of code. While VAR, 4, 3, CONST, 1 ’While automaton has not accepted the command SetVar 31, CONST, 1 ’Arg := on0, the argument for the automaton GoSub 0 ’Run the automaton SetVar 4, VAR, 22 ’Local success:= global success EndWhile On "0" ’Execution of the actual command

m

We have chosen t o impl ement t he aut omat on as a subrout ine. Since argument s for subrout ines are not al l owed in t he l anguage, passing an argument t o t he aut omat on has t o be done via a gl obalvariabl e. Simil arl y , since a subrout ine ues are al so pl aced in gl obalvariabl es for t he cannot ret urn a val ue, ret urn val process t o read. The whil el oop del ay s t he act ion unt ilt he aut omat on accept s execut ion of it . 6.2

Implementing Mutual Exclusion and Automata

However, t he idea described above is not sufficient since we wil lnot al l ow more em t asks t o use t he aut omat on simul t aneousl y . In t he RCX™ l anguage t he probl is obvious since we are using shared variabl es for passing argument s and resul t s. In general , we al so need excl usive access t o t he aut omat on since t he out come of t he aut omat on depends on it s st at e when execut ion begins. If a process accesses e might be t he aut omat on whil e it is used by anot her process, t he st at e variabl corrupt ed. Therefore we must have excl usive access t o t he aut omat on. In our impl ement at ion we have used Dijkst ra’s al gorit hm t o impl ement mut ualexcl usion between severalprocesses [3]. But any correct mut ualexcl usion es but t his al gorit hm woul d of course do. The al gorit hm uses some shared variabl is no probl em in t he RCX™ l anguage since al lvariabl es are shared. There are no got os in t he RCX™ l anguage. Therefore, we have used an ext ra whil el oop and a success variabl e for each t ask. Except from t hese det ail s, t he al gorit hm is fol l owed direct l y. An aut omat on is impl ement ed in t he st andard way by represent ing t he t ransit ion rel at ion as nest ed condit ional s of dept h two branching on t he current st at e and t he input sy mbolrespect ivel y . The current st at e and t he input sy mbolis represent ed by one variabl e each. This gives us a way t o combine t he run of an aut omat on wit h t he execut ion of st andard RCX™ code wit h wrapped input /out put st at ement s. 6.3

Variations of the Method

In t he exampl e an act ion is del ay ed if t he cont rolaut omat on does not grant permission at once. Depending on t he probl em t o be sol ved t he act ion t aken when permission is not grant ed can vary . That is, t here are various way s of handl ing t his t emporary l ack of cont rol l er acknowl edgment : – as in t he above exampl e where t he t ask is busy wait asking t he cont rol l er over and over whet her it s l abelhad been enabl ed; but – one coul d al so simpl y cancel or ignore t he st at ement request ing permission and cont inue execut ion. This coul d be done by repl acing t he busy wait ing whil el oop by an if st at ement . The former woul d oft en be t he preferred approach in cases where t he int ernal st at e of t he code is import ant , such as, in our exampl e, or in a t rain gat e conl er. The l at t er woul d be a good choice in cases where t he code is writ t en in t rol

m

m

a react ive sty l e, const ant l y changing out put act ion based on newl y read input , e.g. in aut onomous robot s. The property impl ement ed by t he aut omat on in t he exampl e was specific t o t he probl em. One coul d al so imagine using t he met hod for generalpropert ies icious sequences of act ions. This l eaves e.g. for prot ect ing hardware against mal at l east two opt ions of where t o put t he aut omat on: – as in t he exampl e above where t he aut omat on was put alongside the wrapped RCX™ code. Pl acing t he code impl ement ing t he aut omat on at t his l evel seems a nat uralchoice when deal ing wit h propert ies about t he behavior of ving a part icul ar probl em. a specific RCX™ program sol – If t he property is of a more generalkind, one shoul d rat her pl ace t he aut omat on at the level of the operating system. So far we have onl y considered unt imed propert ies. One coul d easil y imagine d open for a using aut omat a wit h discret e t ime as cont rolaut omat a. This woul whol e new range of propert ies t o be specified, e.g. a minimum del ay between two act ions. In t he exampl e it woul d be possibl e t o specify propert ies l ike t hat a minimum t ime of 5 seconds shoul d pass between st opping t he crane and st art ing t o move t he hook. d be real ized by having a variabl e represent ing t he On t he RCX™ t his coul discret e t ime. This variabl e coul d be updat ed by a t ask consist ing of an infinit e l oop wait ing for one t ime unit and t hen updat ing t he variabl e. Assuming variabl e number zero represent s t he t ime, it coul d be updat ed by : SetVar 0, CONST, 0 Loop CONST, 0 Wait CONST, 10 SumVar 0, CONST, 1 EndLoop

7

’Initialize the timer ’An infinite loop ’Wait for 1 sec. ’Update the timer

Conclusion

We have used cont rolaut omat a in conjunct ion wit h basic cont rolprograms for sy nt hesizing compl et e cont rolprograms. Using t his met hod one can add t o a basic cont rolprogram a cont rolaut omat on which wil lensure cert ain safety propert ies are sat isfied. We have used M2L t o specify t he cont rolaut omat a and t he Mona t oolt o t ransl at e formul ae int o aut omat a. The approach has been impl ement ed in t he set t ing of t he LEGO® RCX™ sy st em. This has al l owed for t he possibil ity of t est ing t he impl ement at ions on realphy sicalsy st ems. Based on our experiment s we find t he met hod wel lsuit ed for sy nt hesis of ike t he ones we have used. We find t he programs ensuring safety propert ies l main advant age of t he met hod is t he ease of t est ing different specificat ions. The separat ion of t he act ive cont rolprogram and t he rest rict ing aut omat on al so al l ows for ensuring (new) safety specificat ions t o exist ing cont rolprograms. In

m

crit icalsy st ems one might consider t he aut omat on onl y for monit oring act ions, not rest rict ing t hese, t o avoid deadl ocks. The main disadvant age of t he met hod is t he rest rict ion t o safety propert ies. Since t he al lconcurrent t asks must access t he aut omat on t here is a danger of t his becoming bot t l eneck. Future work There is an overhead connect ed wit h gaining excl usive access t o t he aut omat on and running it . How much t ime is spent on gaining access t o t he aut omat on of course depends on t he arrivalof input event s. It woul d be int erest ing t o cal cul at e some specific t imes for t his given some input sequences. at ing RCX™ programs t o t imed model s support ed by Uppaal[8] A t oolfor t ransl exist s [5]. Using Uppaalone can “measure” t he t ime spent by a program from an input is read unt ilt he response arrives. The exampl e present ed in t his paper onl y has one component (one crane) y imposed on t hat part icul ar compoand t he cont rolrest rict ions are consequent l nent onl y . One coul d easil y imagine having severalcomponent s in a dist ribut ed environment working t o achieve a common goal . By use of modul ar sy nt hesis y sis [13] one can st at ical l y inand dist ribut ed cont rol[12 ] via independence anal fer informat ion about which const raint s t o put l ocal l y on t he component s and which t o put on t he (most oft en necessary ) cent ralcont rol l er.

References

v ¨ Grundl. Math.

v v m m v m m http://www.brics.dk/∼brabrand/thesis/ m m Z. Math. Logik m

munications of the ACM

mm

Com-

m

m m m Transactions of the American Mathematical Society m Proceedings of Fourth International Workshop on Formal Methods for Industrial Critical Systems High-level Petri Nets – Theory and Application MONA Version 1.3 User Manual v m m v In Springer International Journal of Software Tools for Technology Transfer Software developers kit v m http://www.legomindstorms.com/ mm m m ACM Transactions on Programming Languages and Systems m The Computer Journal

m m Proceedings of the IEEE m v Engineering, FASE’98

m m

v

m

Fundamental Approaches to Software m v

Formal System Development with KIV l l

l

l l

l

m ¨ {balser,reif,schellhorn,stenzel,thums}@informatik.uni-ulm.de

1

Overview l

m l

m

l m

l m

–

m l

l l

m

m

m l

m

l

m

m lm m m l l l

– –

l

mm m m

l

m

l

l

lm

l

l

l

l l l ll

l

m l m l m lm

l

l l

l

l l

l l m

m

2

m lm m l

l 9

m

Specification Language l l l

m l

l l m

m l

l

m

m

lm m m

l m lm

m

m

m l

m m

m

l l

m m

m l

m

m

l

l m

m l l

m

l

l l

l m

m

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 363–366, 2000. c Springer-Verlag Berlin Heidelberg 2000 

l

l m lm

l

m

m

l

m m l

mm

m m

l

m l l

m

m m

m m

l m

m l

m

m m l l development graphs m l m l l l

m l l l

l m theorem base m l l l m

l m

m m m

m

3

Proof Support l proof tactics

m

m

m l

m m

l

l l

m l

lm m

m lm

l m

l

m

m

m

m

m

heuristics l l

l

m

l l l

lm l l

l m

m l

l l

l

l l simplifier

l

m

l

l

l l

m m l

m

m l m l

l l l l l

lm m

l m l m

m

proof engineering m

lm m

l m

l

l l m

l l l

l m l

l

m l

l

m

l l

l m l

l m l

m

l l

l

fl

l

m l m

l

m

l l l

m

l l9

l correctness management m l

l

m

l m

l l

m l m

l

4

m m l l l l

l l

l

lm m

m

User Interface l

l

l m l l

m

m

m

l

l

m lm l

m l l

l m l m

l

l m m

l

l m

l l l m

l

m l

m l m l

l l l m

l l

m l l m l l m

l l

l

m

l l l

l

l l

l l l m l

l

l m l

l

m

l l

m

l m

m

m m lm

l

m

l

l l

l

m

mm

l l

m m

l

l l

m l l l

m mm

m l

l l l m

l l m

m l m l m

m l

l l l m

References 1

Common Criteria for Information Technology Security Evaluation, 1 1

Version 2.0

1 ¨ daVinci Drawing ’94. Proceedings

¨

1

DIMACS Workshop on Graph (

Verifikation abstrakter Zustandsmaschinen ¨ 1 (

¨

¨ ¨ ¨ Computer Science Logic 1 First Order Dynamic Logic 1 Information Technology Security Evaluation Criteria, Version 1.2 1 1 2nd Conf. on Rewriting Techniques and Applications. Proceedings 1 ¨ KORSO: Methods, Languages, and Tools for the Construction of Correct Software – Final Report 1 1 1 Assurance

COMPASS’95 – Tenth Annual Conference on Computer ( 1

11 Automated Deduction – A Basis for Applications 1 1 Proceedings

Foundation of Software Technology and Theoretical Computer Science. 1 1

1 Journal of Universal Computer Science (J.UCS) 1

(

1

More About TAS and IsaWin — Tools for Formal Program Development o 1

m n n 2

n

n n

m

m

n

m

n

n

o

o

n n n m n

n n

n

m n

m n

m

n m m n n n m n

n n

n

¨

m n

n

n n m

2

o

m n [email protected] ¨ n m n ¨ [email protected]

n

Abstract. n n n

1

¨

n m

n m n n

m n

m

m m n

Introduction n n

o n

o n o

oo

n

n on n n n o o

o o

o

n n o

n n

n n

n on

n on n

o o o

o

n

n

o o

o

o n oo o o n n o no nn n o n oo o o o o o oo o n n o o o n o on o n n oo o on o

n

n

n

n

n on

o on n

fl

o

o n o

n

oo

n o

o o o

n n

o n oo

o o o

n n n o

n n n on

n n

n

The Transformation Application System TAS o

o

o o o

n o n

on

o o

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 367–370, 2000. c Springer-Verlag Berlin Heidelberg 2000 

o o o

n

n

n n

¨

n

n

n n on o on n o n n n on o o on on n o n n o o n n o on on o n o n

o

n on

Fig. 1. on

on

n o o o

o

n o o o no o o o o n o

n on nn on n o n o n

o n on

n n

n n

o o

n n

n o

o

n

n

o on

o oo o

n o o n

n

n o n o

o

n o n o

n

o

n o o

o

o on

o n

on

n

o

o on n

no on

on

n

on

n o o o

n n o on on notepad n n n o n o n construction area n

on on

n

n

n

m

m

m n

n

pointing n n on o o o n o on n o o o o on o no on o correctness-preserving refinement n n on o n o o n n on o n n o n n on n n o o n o

IsaWin n o on o on

o o

n

o

o oo o on n

o o

n

o

o

n

n o on

n n

o

n o on o n on n n n n on o on n no

on n

n

o on

n o n

n

What’s New? n n n no

o n

n o o no

n o

on n n

n

o

o n n

n o o

on o n

n

on o

n on n

quiet o o

n n

o

n o o

n

on o n

o nn

n

o

n o

o on o n

n

n n o

o on o o

n o n

on no no o

o n

o o

n o o o

on

– Search functions oo o n o on o o n on n n n o on o o n oo – transformation library o n o on o o no n o o n o n n o on o o n o on o n o generation o n o on o o – o interactive hypertext n on n o n n o on n o n n n – filer n o n n on o o reuse of developments o n on o n o on o n o on – n n n on o o o on o refinement calculus n n o –

n o n

on n n

¨

n

More Information o

o

n n

n n

n

n

n o

n o

n

n

o n

oo

o

n n on no

o on

o

http://www.informatik.uni-bremen.de/~agbkb/

System Requirements o o o

n

n

n

n on n

o n n

n

o

o

o n

n n

n o

o

o

n

n on o o

o

o

o n

n

o

n n n n o o

on n

n

References n n Refinement Calculus n n n n n n m User Interfaces for Theorem Provers UITP ’96 n n n n http://www.cs.york.ac.uk/~nam/uitp96/proceedings.html n ¨ n n n n n n m n m m n n m n n n TAPSOFT 97’: Theory and Practice of Software Development n m n n ¨ n n n n n m n n nm n m m n n n FM’99 — Formal Methods. Proceedings, Vol. II n m n n ¨ n n ¨ n n n n m n m m n n m n n n n Fundamental Approaches to Software Engineering FASE’99. Joint European Conferences on Theory and Practice of Software ETAPS’99 n m n n ¨ n n n n n m m n n n m Journal of Functional Programming m m n n TACAS 2000 — Tools and Algorithms for the Construction and Analysis of Systems n n n Isabelle - A Generic Theorem Prover m n n



1

o 1

p

o

m

fl

m oo

m

o

m o

o

o m o o mm

o

o

oo

o om

o

o o

o

m

o

k

o

o o

o

o

o

o

m o

o

o

om o

m

m

o j

o o

o m mm o o o

o

o

o

o o o

o

o

o m om

om fl

m om

o o m

o o o

o

o

o o

o o

om m on

o

o o om

o o

o

m

o

o

n

o

o o o o mm

o

o

o

o k o

mm

fl o mo

m

o

ppo

m

o

o o o o

–

o o

m

o

–

fl o mo o

m

o

o

o

o

o –

o

o

m k

–



o o

o o

p n p n

o

o o m http://maude.csl.sri.com mm o o

om

–

n

om

m o

p n

o p n

oo o o

2

o 4

o

o m

k

o

o op n on no n no n

n n o

4

2

k 2

n o n n

2 3

2

o 3

o

fl m m o

o

o

o o

on

n o

.

T. Maibaum (Ed.): FASE 2000, LNCS 1783, pp. 371–374, 2000. c Springer-Verlag Berlin Heidelberg 2000 

on

n

.

m o m

o o km

o

m

o

o

o fl o

o om o List o Set m o o om

o

o o o o fl m

m o m o

m o

m

o mo o o

o

o

o o

m o

o

o

o

o o om m

o o om o

o

o

o

o om m

o

o

o o

o

o

o

fmod ASSOC-IDP is protecting QID . sorts List Set . subsorts Qid < List Set . op __ : List List -> List [assoc] . *** list concatenation op _,_ : Set Set -> Set [assoc comm] . *** set union op {_} : List -> Set . *** set of a list var I : Qid . var S : Set . vars L P Q : List . eq S,S = S . eq L L = L . *** set and list idempotence ceq L P Q = L Q if {L} == {Q} and {L P} == {L} . eq {I} = I . eq {I L} = I,{L} . endfm

o

o

o

reduce ’a ’b ’c == ’a ’b ’c ’b ’a ’b ’c

o o

o

o o om m o

om

o m o o ’a ’b ’a ’b ’c ’b ’a ’b ’c

META-LEVEL

fl o

fl o

U

(

U

T − t −− t T

o

T

o

T

U − −T , t−−− −T , t −

m o U META-LEVEL m o o k o o o U META-LEVEL o Term Module o m m o t T o t m T mo ( o o m m t f(a,g(b)) mo FOO a b o o o Foo m t ’f[−’a−Foo,’g[−’b−Foo]] META-LEVEL m o o o o m m om o o meta-apply o m mo o m o o o

fl

t

o o o −−

m

o

t

o

op meta-apply : Module Term Qid Substitution MachineInt -> ResultPair .

n

o T

m

m

m t o

mo o m

o m

o o

m o

t o

o

om m om

m

T

o

m

o

om m o m

o j

om m

o

o

m o

m

m

o o

(m

o o

o

o

fl o o o m t om t o

m

m o mo

mo m

T meta-apply o o

(

o m o findAllRewrites o o o o o m o o

j

m

fmod META is protecting META-LEVEL . sort TermSet . subsort Term < TermSet . var T : Term . var S : Substitution . var L : Qid . vars TL Before After : TermList . vars OP SORT : Qid . var N : MachineInt . op first : ResultPair -> Term . op ~ : -> TermList . eq ~, TL = TL . eq TL, ~ = TL . op {} : -> TermSet . op _|_ : TermSet TermSet -> TermSet [assoc comm id: {}] . op meta-apply1 : Term Qid MachineInt -> Term . op findAllRewrites : Term Qid -> TermSet . op findTopRewrites : Term Qid MachineInt -> TermSet . op findLowerRewrites : Term Qid -> TermSet . op rewriteArguments : Qid TermList TermList Qid -> TermSet . op rebuild : Qid TermList TermSet TermList -> TermSet . eq meta-apply1(T, L, N) = first(meta-apply([’FOO], T, L, none, N)) . eq T | T = T . eq first({T, S}) = T . eq findAllRewrites(T, L) = findTopRewrites(T, L, 0) | findLowerRewrites(T, L) . eq findTopRewrites(T, L, N) = if meta-apply1(T, L, N) == error* then {} else meta-apply1(T, L, N) | findTopRewrites(T, L, N + 1) fi . eq findLowerRewrites({OP}SORT, L) = {} . eq findLowerRewrites(OP[TL], L) = rewriteArguments(OP, ~, TL, L) . eq rewriteArguments(OP, Before, T, L) = rebuild(OP, Before, findAllRewrites(T, L), ~) . eq rewriteArguments(OP, Before, (T, After), L) = rebuild(OP, Before, findAllRewrites(T, L), After) | rewriteArguments(OP, (Before, T), After, L) . eq rebuild(OP, Before, {}, After) = {} . eq rebuild(OP, Before, T, After) = OP[Before, T, After] . eq rebuild(OP, Before, (T | TS), After) = (OP[Before, T, After]) | rebuild(OP, Before, TS, After) . endfm

mo o

FOO o o om f(a, g(b))

’one

reduce findAllRewrites(’f[{’a}Foo,’g[{’b}Foo]], ’one).

o o

n

.

m

o m

m

o

mo o m o

m

o m oo m m k ( o

o o

o

o o

oo om

m

oo o o

o

o m

o m o

o o

o

o

o o

(

o

m

o m

o o j

o

o o

o o

o fl

m k

mo ok o

o

o

.

fl n

o

m o o k o

o

o

n

om

on n n . . . o n

o

n n

o k o

o o

o k o

o

oo o

o

o o

o

o

m

m m

om m

n

n o

o

pp

on

.

n n n n on o o n o . p on n p o n n n o . n n on n http://maude.csl.sri.com. n n o n n n o . n on p o n oo fl on n n o . n • •• • • • • •• • • • •• • • • • • • • • ••• • •• • • • • • • •• • • • • • • . o p . http://maude.csl.sri.com. n n o . fl on n n n o . n . o • •• • • • •••• •• ••• • • •• •• • • • • • • • ••••• • • • • •• • • • ••• • • • •••• • ••• • • o o • ••• ••• • •• • • •• • •• • • •• •• •••• • • • • • • •• • • • •• • •• . . http://www.elsevier.nl/cas/tree/store/tcs/free/noncas/pc/volume4.htm. n n o . n n n fl o . n . n . n o • •• •••• •• • • • • •• • • • • • •• • • • •• •• • • • • • ••• ••• •• • •• • • •• • • ••• • •• • • ••• • •• • • • •• •••• • • • •••• ••• • • • •• • • • • • p . n o n. fl o pp on o n . . . n o . o . on on n o n o o on n . • • •• •• •••• • • • • • • •• • • • •• • •• . . nn n . o. no n n onfl n o po n o p . • • • •• •• • • • • •• • .

Author Index

n

7

n

n n

7 n

7 n n ¨

n v 7 k v n k

7 n

7

7 7

n

v

v

7 7

n

7

7

nn n

n n

k

n

7 n n

n v nn 7

n n

k

nk

k

v n

n

¨v

7

nn

7 n

7 n n

n 7

k a

n n 7 n

v n n

7

v

n n nn n

n

n n

k

k

n n nn

7

n

n ¨ ¨n ¨

n n n

n

k k

n n

n k

k

7

7