- Email: [email protected]
Using CCS for the specification of inheritance
Microprocessing and Microprogramming 39 (1993) 93-96 North-Holland
93
Using CCS for the Specification of Inheritance Mary Buchanan, Bob Dickerson, Carol Britton and Martin Loomes School of Information Science, University of Hertfordshire, College Lane, Hatfield, Herts A L l 0 9AB, UK
1. I N T R O D U C T I O N The motivation for considering CCS [1] for object-oriented specification arose from the belief that such a language might be able to capture the heterarchical interaction between active objects [2]. Two of the perceived benefits of object-oriented design are the classification of object characteristics and inheritance. Inheritance is a hierarchical relationship between classes which enables the attributes and operations of classes to be shared. This paper describes an a t t e m p t to use CCS to specify subtype inheritance. A knowledge of CCS and of object-oriented design is assumed.
2. T H E S P E C I F I C A T I O N IN CCS
OF CLASSES
At a suitably high level of abstraction, we can specify an object by defining the operations exported in the interface. In CCS the specification of state and the operations on that state are encapsulated together in agents which have their own identity. In this experiment, we interpret a CCS agent expression as the interface to a class of objects.
3. T H E EQUIVALENCE AGENTS
OF
CCS
If we are to specify a class using inheritance, we need to know that it is in some way equivalent to the behaviour of the class defined directly. Equivalence in CCS is discussed in detail in [3]; here we briefly mention the concepts used in this paper.
Observation equivalence expresses the equivalence of two processes which as stand-alone processes can perform the same pattern of external communications, but whose internal behaviour m a y differ. Unfortunately, observation equivalence does not always equate agents which we might wish to interpret as equivalent [3, page 61]; however, such agents m a y sometimes be equated under testing equivalence [3]. Testing equivalence is the conjunction of the may and the must equivalences which can be determined by tests based on the sequences of actions which the agents can perform. Must and may pre-order relationships are also defined over agents. Observation equivalence, testing equivalence and the pre-orders can be tested using the Concurrency Workbench [4]. 4. I N H E R I T A N C E
Tlle different interpretations given to tile meaning of inheritance depend largely on whether inheritance is being used to achieve subtype hierarchies or to effect code-sharing without a type relationship. Subtyping is a form of inclusion polymorphism [5] in which a value of a subtype m a y be used in any context which requires a value of the supertype. A type conforms to another if it can be used in all contexts where the other type is expected. Conformance depends only on the interfaces of the types and not on the implementation. 5. T H E I D E N T I T Y
CARD
For the purpose of this discussion, we consider the specification of identity cards. Initially, an object of class Card has a card number. A card can be allocated to an individual owner such that the
M. Buchanan et aL
94
card receives a personal identity number (PIN) for the owner. When the card is deallocated, the PIN will be removed from the card. The Card class can be described in CCS as:
Card
de__!allocateCard.deallocateCard.Card
6. T H E EXPERIMENT TO DEFINE SUBTYPE INHERITANCE IN CCS
6.1. A n e w class d e f i n e d t o e x t e n d t h e b e h a v i o u r o f class C a r d Suppose we want
to define another
Card definition with an agent that defined the extra (changePin) behaviour required of CardSub. The only way that agents can communicate with one another is via their ports. The only ports that Card has are allocateCard and deallocateCard and we do not want to confine these ports to internal communication; in order to link in the new behaviour we need extra ports. Accordingly, we define a new agent, CardCD, which is congruent with Card but which has the potential for communication through ports other than allocateCard and deallocateCard. Consider the agents:
class,
CardPlus, having the same behaviour as Card
CardC
de=!allocateCard.-d.b.CardC
but with the additional operation that the PIN can be changed if desired. The CCS specification for C a r d P l u s is:
CardD
de=]a.deallocateCard.b.CardD
CardPlus CardPlusl
de=/ allocateCard.CardPlusl
If we compose CardC and CardD, and restrict the ports a and b so that only internal communication is possible via these ports, we have
def
= changePin.CardPlusl + deallocateCard.CardPlus
From the definitions of CardPlus and Card it is possible to observe that the former has a subtype relationship with the latter but there is nothing in the definition of either agent which makes the relationship obvious. This may not be a problena where such simple agents are being defined, but one can envisage the situation in which more complex agents have subtype relationships which are not easy to detect by inspection. If the definition of the supertype agent could be inherited by the subtype agent, then the relationship between the agents might be clearer. 6.2. I n h e r i t i n g t h e b e h a v i o u r o f class C a r d We want to ascertain whether it is possible to form a new class, CardSub, which inherits behaviour from Card and has the added behaviour that the PIN can be changed. CardSub is to have the same behaviour as CardPlus. We need to find a means of incorporating the Card definition within the CardSub definition. We could do this in CCS if we could compose the
CardCD
def
= ( C a r d C l C a r d D l \ { a ,b}
Testing on the Concurrency Workbench confirms that C a r d C D is congruent with Card. We shall use C a r d C D to try and establish if we can use it in an inheritance relationship. We want to define a new agent having the changePin behaviour which we can compose with CardCD to form an agent which is congruent with CardPlus. Consider C a r d E x t defined as:
CardExt
de_J a . C a r d E x t l
CardExtl
de_=]c h a n g e P i n . C a r d E x t l + -&CardExt
In order to link C a r d E x t in to CardCD, we relabel the a port in CardD:
CardDa
def
:
CardD[c/a]
Finally, we define CardSub as:
CardSub
def = (CardC]CardDalCardExt) \{a,b,c}
Using CCS for the specification of inheritance U n f o r t u n a t e l y , t e s t i n g on the C o n c u r r e n c y W o r k b e n c h shows t h a t CardSub a n d CardPlus are n o t observation e q u i v a l e n t a n d n e i t h e r a r e t h e y must e q u i v a l e n t . However, t h e y are may e q u i v a l e n t . T h u s we have t h a t while it is possible for CardSub a n d CardPlus to follow t h e s a m e sequences o f actions, we c a n n o t s a y t h a t t h e y must be able to follow such sequences at all t i m e s . T e s t i n g for p r e - o r d e r r e l a t i o n s h i p s shows t h a t
CardSub ~mustCardPlus. T h u s t h e r e are no actions which CardSub can p e r f o r m t h a t CardPlus c a n n o t also p e r f o r m b u t we know n o t h i n g a b o u t t h e e x t r a a c t i o n s t h a t CardPlus can p e r f o r m over a n d a b o v e t h e a c t i o n s of CardSub. W h e n we consider the e x p a n s i o n t h e o r e m , we discover t h a t CardSub m u s t allow one to allocateCard a n d deallocateCard b u t t h a t it m a y or m a y n o t allow one to changePin:
CardSub
= (allocateCard.r. (r.(b.CardC l deallocateCard.b.CardDJCardExt ) + change P in( b.CardCle.dealloeate Card.b.CardDICardExt 1))) \{a,b,c}
T h e silent a c t i o n after the allocateCard action is of no concern b u t it is followed by a choice of actions, t h e first of which has a leading r . If t h i s l e a d i n g 7- occurs, t h e n we no longer have a choice b e t w e e n the changePin a n d t h e deallocateCard a c t i o n s since changePin will have been p r e - e m p t e d . Once the l e a d i n g v has occurred, v i a an a u t o n o m o u s a c t i o n of t h e s y s t e m , t h e n t h e n e x t a c t i o n which can be t a k e n f r o m o u t side t h e s y s t e m m u s t be a deallocateCard r e g a r d less of w h e t h e r this is the a c t i o n a c t u a l l y w a n t e d . 6.3. The problem
with CardSub
T h e p r o b l e m of t h e silent r a c t i o n is caused by t h e a g e n t CardExt. T h e l e a d i n g ~ in -5.CardExt m e a n s t h a t silent a n d secret c o m m u n i c a t i o n can occur w i t h CardDa at p o r t c. Such an a c t i o n is b e y o n d the control o f t h e e n v i r o n m e n t in which CardSub finds itself so the b e h a v i o u r of CardSub is u n p r e d i c t a b l e .
95
6.4. A P a r t i a l S o l u t i o n Various a t t e m p t s were m a d e to o v e r c o m e the p r o b l e m of t h e u n w a n t e d p r e - e m p t i v e v b u t witho u t success. However, we were a b l e to arrive at a p a r t i a l solution; the s o l u t i o n is p a r t i a l b e c a u s e it leads to re-specification of t h e CardPlus beh a v i o u r . In o r d e r to p r e v e n t the u n w a n t e d silent c o m m u n i c a t i o n between CardExt a n d CardDa, we i n t r o d u c e an e x t e r n a l a c t i o n such t h a t the env i r o n m e n t has to actively request t h a t it w a n t s to d e a l l o c a t e a c a r d before a c t u a l l y a c t i v a t i n g the dealloeateCard action. In o r d e r to do this, CardExt is r e p l a c e d by CardFix defined as:
CardFix CardFixl
d~] a.CardFixl def
= changePin.CardFixl + requestDeallocate.-5.CardFix
C o n s i d e r CardSub2 defined as:
CardSub2
de]
= (CardCJCardDa]CardFix)
\{a,b,e} CardSub2
= (alloeateCard.v. ( change P in.( b.CardCJc.deallocate Card.b.CardDJCardF ix 1) + request Deallocate.( b.CardCJ c.deallocateCard.b.CardDJ -6.CardFix))) \{a, b, c}
T h e request Deallocate a c t i o n acts as a g u a r d in t h a t it is o n l y after a requestDeallocate t h a t CardDa and CardFix can c o m m u n i c a t e v i a a silent action. We have succeeded in r e m o v i n g the i n s t a b i l i t y in CardSub caused by t h e l e a d i n g v. However, CardSub2 does n o t m a t c h t h e specific a t i o n of CardPlus due to the presence of the e x t r a action, request Deallocate. CardSub2 is in fact c o n g r u e n t with C a r d P l u s F defined as:
CardPlusF CardPlusF1
deI
= allocateCard.CardplusF 1
de]
= changePin.CardPlusF1 + requestDeallocate. deallocateCard.CardPlusF
96
M. Buchanan et al.
CardSub2 can be considered to have inherited the behaviour of CardCD and to have extended the behaviour to include the changePin and requestDeallocate operations. If in a system we had Card and wanted to inherit from it to form a class having the behaviour of CardPlusF, then we could replace Card with CardCD (since they are congruent) and derive CardSub2 from it by inheritance. However, CardSub2 is not a subtype of Card due to the presence of the requestDeallocate action prior to deallocateCard.
7. D I S C U S S I O N We have had very limited success in our att e m p t to define subtype inheritance using CCS and even t h a t was achieved at the expense of adding much extra complexity to the parent Card class specification in the form of extra ports, defined in CardCD. CardSub has inherited the behaviour from CardCD such that it is a subtype of CardCD, but it does not have the intended behaviour in that it is not equivalent to CardPlus. CardSub models the behaviour in which the ability to changePin is nondeterministic. In the case of CardSub2 we have inherited the behaviour of CardCD but have realised equivalence with the behaviour of CardPlusF rather than with CardPlus. Moreover, CardSub2 is not a subtype of Card. CardSub2 models a form of inheritance in which not only have we added extra behaviour (ehangePin), but we have redefined the behaviour of an operation. We added the requestDeallocate operation in order to achieve stability and this has effectively redefined the dealloeateCard action such that it must be preceded by the requestDealloeate action. A m a j o r difficulty with the representation of inheritance in CCS arises from the need to link in new behaviour such that the required timeordering of operations is maintained. This was complicated for the simple agent CardCD and is likely to be much more difficult for complex agents. In addition, representing inheritance by the composition of agents in the manner we have
shown does not seem a very natural model of inheritance. 8. C O N C L U S I O N S We have only been able to specify inheritance in CCS by introducing extra complexity into the specification. Subtype inheritance was obtainable but at the expense of having unacceptable nondeterministic behaviour in the subtype. By modifying the behaviour of the sub-class to include the requestDeallocate action, a sub-class having deterministic behaviour was achievable by inheritance but the subtype relationship was sacrificed. CCS is essentially heterarchical and cannot easily capture the hierarchical relationships required for inheritance. In order to specify inheritance with a suitable degree of clarity, either we need a new calculus or we must find other ways of using an existing calculus. REFERENCES 1.
2.
3.
R.Milner. Communication and Concurrency. Prentice Hall International (UK) Ltd, 66 Wood Lane End, Hemel Hempstead, Herts HP2 4RG, 1989. Grady Booth. Object-Oriented Design With Applications. B e n j a m i n / C u m m i n g s , London, 1991. E.J.Baillie. Towards A Satisfaction Relation
Between CCS Specifications And Their Refineraents. PhD thesis, University of Hert4.
5.
fordshire, 1992. Cleaveland, Parrow, and Steffen. The Concurrency Workbench: a semantics-based tool for the verification of concurrent systems. Teclmical Report ECS-LFCS-89-83, LFCS, University of Edinburgh, Department of C o m p u t e r Science, University of Edinburgh, August 1989. Luca Cardelli and Peter Wegner. On Understanding Types, D a t a Abstraction, and Polymorphism. Computing Surveys, 17(4), December 1985.
93
Using CCS for the Specification of Inheritance Mary Buchanan, Bob Dickerson, Carol Britton and Martin Loomes School of Information Science, University of Hertfordshire, College Lane, Hatfield, Herts A L l 0 9AB, UK
1. I N T R O D U C T I O N The motivation for considering CCS [1] for object-oriented specification arose from the belief that such a language might be able to capture the heterarchical interaction between active objects [2]. Two of the perceived benefits of object-oriented design are the classification of object characteristics and inheritance. Inheritance is a hierarchical relationship between classes which enables the attributes and operations of classes to be shared. This paper describes an a t t e m p t to use CCS to specify subtype inheritance. A knowledge of CCS and of object-oriented design is assumed.
2. T H E S P E C I F I C A T I O N IN CCS
OF CLASSES
At a suitably high level of abstraction, we can specify an object by defining the operations exported in the interface. In CCS the specification of state and the operations on that state are encapsulated together in agents which have their own identity. In this experiment, we interpret a CCS agent expression as the interface to a class of objects.
3. T H E EQUIVALENCE AGENTS
OF
CCS
If we are to specify a class using inheritance, we need to know that it is in some way equivalent to the behaviour of the class defined directly. Equivalence in CCS is discussed in detail in [3]; here we briefly mention the concepts used in this paper.
Observation equivalence expresses the equivalence of two processes which as stand-alone processes can perform the same pattern of external communications, but whose internal behaviour m a y differ. Unfortunately, observation equivalence does not always equate agents which we might wish to interpret as equivalent [3, page 61]; however, such agents m a y sometimes be equated under testing equivalence [3]. Testing equivalence is the conjunction of the may and the must equivalences which can be determined by tests based on the sequences of actions which the agents can perform. Must and may pre-order relationships are also defined over agents. Observation equivalence, testing equivalence and the pre-orders can be tested using the Concurrency Workbench [4]. 4. I N H E R I T A N C E
Tlle different interpretations given to tile meaning of inheritance depend largely on whether inheritance is being used to achieve subtype hierarchies or to effect code-sharing without a type relationship. Subtyping is a form of inclusion polymorphism [5] in which a value of a subtype m a y be used in any context which requires a value of the supertype. A type conforms to another if it can be used in all contexts where the other type is expected. Conformance depends only on the interfaces of the types and not on the implementation. 5. T H E I D E N T I T Y
CARD
For the purpose of this discussion, we consider the specification of identity cards. Initially, an object of class Card has a card number. A card can be allocated to an individual owner such that the
M. Buchanan et aL
94
card receives a personal identity number (PIN) for the owner. When the card is deallocated, the PIN will be removed from the card. The Card class can be described in CCS as:
Card
de__!allocateCard.deallocateCard.Card
6. T H E EXPERIMENT TO DEFINE SUBTYPE INHERITANCE IN CCS
6.1. A n e w class d e f i n e d t o e x t e n d t h e b e h a v i o u r o f class C a r d Suppose we want
to define another
Card definition with an agent that defined the extra (changePin) behaviour required of CardSub. The only way that agents can communicate with one another is via their ports. The only ports that Card has are allocateCard and deallocateCard and we do not want to confine these ports to internal communication; in order to link in the new behaviour we need extra ports. Accordingly, we define a new agent, CardCD, which is congruent with Card but which has the potential for communication through ports other than allocateCard and deallocateCard. Consider the agents:
class,
CardPlus, having the same behaviour as Card
CardC
de=!allocateCard.-d.b.CardC
but with the additional operation that the PIN can be changed if desired. The CCS specification for C a r d P l u s is:
CardD
de=]a.deallocateCard.b.CardD
CardPlus CardPlusl
de=/ allocateCard.CardPlusl
If we compose CardC and CardD, and restrict the ports a and b so that only internal communication is possible via these ports, we have
def
= changePin.CardPlusl + deallocateCard.CardPlus
From the definitions of CardPlus and Card it is possible to observe that the former has a subtype relationship with the latter but there is nothing in the definition of either agent which makes the relationship obvious. This may not be a problena where such simple agents are being defined, but one can envisage the situation in which more complex agents have subtype relationships which are not easy to detect by inspection. If the definition of the supertype agent could be inherited by the subtype agent, then the relationship between the agents might be clearer. 6.2. I n h e r i t i n g t h e b e h a v i o u r o f class C a r d We want to ascertain whether it is possible to form a new class, CardSub, which inherits behaviour from Card and has the added behaviour that the PIN can be changed. CardSub is to have the same behaviour as CardPlus. We need to find a means of incorporating the Card definition within the CardSub definition. We could do this in CCS if we could compose the
CardCD
def
= ( C a r d C l C a r d D l \ { a ,b}
Testing on the Concurrency Workbench confirms that C a r d C D is congruent with Card. We shall use C a r d C D to try and establish if we can use it in an inheritance relationship. We want to define a new agent having the changePin behaviour which we can compose with CardCD to form an agent which is congruent with CardPlus. Consider C a r d E x t defined as:
CardExt
de_J a . C a r d E x t l
CardExtl
de_=]c h a n g e P i n . C a r d E x t l + -&CardExt
In order to link C a r d E x t in to CardCD, we relabel the a port in CardD:
CardDa
def
:
CardD[c/a]
Finally, we define CardSub as:
CardSub
def = (CardC]CardDalCardExt) \{a,b,c}
Using CCS for the specification of inheritance U n f o r t u n a t e l y , t e s t i n g on the C o n c u r r e n c y W o r k b e n c h shows t h a t CardSub a n d CardPlus are n o t observation e q u i v a l e n t a n d n e i t h e r a r e t h e y must e q u i v a l e n t . However, t h e y are may e q u i v a l e n t . T h u s we have t h a t while it is possible for CardSub a n d CardPlus to follow t h e s a m e sequences o f actions, we c a n n o t s a y t h a t t h e y must be able to follow such sequences at all t i m e s . T e s t i n g for p r e - o r d e r r e l a t i o n s h i p s shows t h a t
CardSub ~mustCardPlus. T h u s t h e r e are no actions which CardSub can p e r f o r m t h a t CardPlus c a n n o t also p e r f o r m b u t we know n o t h i n g a b o u t t h e e x t r a a c t i o n s t h a t CardPlus can p e r f o r m over a n d a b o v e t h e a c t i o n s of CardSub. W h e n we consider the e x p a n s i o n t h e o r e m , we discover t h a t CardSub m u s t allow one to allocateCard a n d deallocateCard b u t t h a t it m a y or m a y n o t allow one to changePin:
CardSub
= (allocateCard.r. (r.(b.CardC l deallocateCard.b.CardDJCardExt ) + change P in( b.CardCle.dealloeate Card.b.CardDICardExt 1))) \{a,b,c}
T h e silent a c t i o n after the allocateCard action is of no concern b u t it is followed by a choice of actions, t h e first of which has a leading r . If t h i s l e a d i n g 7- occurs, t h e n we no longer have a choice b e t w e e n the changePin a n d t h e deallocateCard a c t i o n s since changePin will have been p r e - e m p t e d . Once the l e a d i n g v has occurred, v i a an a u t o n o m o u s a c t i o n of t h e s y s t e m , t h e n t h e n e x t a c t i o n which can be t a k e n f r o m o u t side t h e s y s t e m m u s t be a deallocateCard r e g a r d less of w h e t h e r this is the a c t i o n a c t u a l l y w a n t e d . 6.3. The problem
with CardSub
T h e p r o b l e m of t h e silent r a c t i o n is caused by t h e a g e n t CardExt. T h e l e a d i n g ~ in -5.CardExt m e a n s t h a t silent a n d secret c o m m u n i c a t i o n can occur w i t h CardDa at p o r t c. Such an a c t i o n is b e y o n d the control o f t h e e n v i r o n m e n t in which CardSub finds itself so the b e h a v i o u r of CardSub is u n p r e d i c t a b l e .
95
6.4. A P a r t i a l S o l u t i o n Various a t t e m p t s were m a d e to o v e r c o m e the p r o b l e m of t h e u n w a n t e d p r e - e m p t i v e v b u t witho u t success. However, we were a b l e to arrive at a p a r t i a l solution; the s o l u t i o n is p a r t i a l b e c a u s e it leads to re-specification of t h e CardPlus beh a v i o u r . In o r d e r to p r e v e n t the u n w a n t e d silent c o m m u n i c a t i o n between CardExt a n d CardDa, we i n t r o d u c e an e x t e r n a l a c t i o n such t h a t the env i r o n m e n t has to actively request t h a t it w a n t s to d e a l l o c a t e a c a r d before a c t u a l l y a c t i v a t i n g the dealloeateCard action. In o r d e r to do this, CardExt is r e p l a c e d by CardFix defined as:
CardFix CardFixl
d~] a.CardFixl def
= changePin.CardFixl + requestDeallocate.-5.CardFix
C o n s i d e r CardSub2 defined as:
CardSub2
de]
= (CardCJCardDa]CardFix)
\{a,b,e} CardSub2
= (alloeateCard.v. ( change P in.( b.CardCJc.deallocate Card.b.CardDJCardF ix 1) + request Deallocate.( b.CardCJ c.deallocateCard.b.CardDJ -6.CardFix))) \{a, b, c}
T h e request Deallocate a c t i o n acts as a g u a r d in t h a t it is o n l y after a requestDeallocate t h a t CardDa and CardFix can c o m m u n i c a t e v i a a silent action. We have succeeded in r e m o v i n g the i n s t a b i l i t y in CardSub caused by t h e l e a d i n g v. However, CardSub2 does n o t m a t c h t h e specific a t i o n of CardPlus due to the presence of the e x t r a action, request Deallocate. CardSub2 is in fact c o n g r u e n t with C a r d P l u s F defined as:
CardPlusF CardPlusF1
deI
= allocateCard.CardplusF 1
de]
= changePin.CardPlusF1 + requestDeallocate. deallocateCard.CardPlusF
96
M. Buchanan et al.
CardSub2 can be considered to have inherited the behaviour of CardCD and to have extended the behaviour to include the changePin and requestDeallocate operations. If in a system we had Card and wanted to inherit from it to form a class having the behaviour of CardPlusF, then we could replace Card with CardCD (since they are congruent) and derive CardSub2 from it by inheritance. However, CardSub2 is not a subtype of Card due to the presence of the requestDeallocate action prior to deallocateCard.
7. D I S C U S S I O N We have had very limited success in our att e m p t to define subtype inheritance using CCS and even t h a t was achieved at the expense of adding much extra complexity to the parent Card class specification in the form of extra ports, defined in CardCD. CardSub has inherited the behaviour from CardCD such that it is a subtype of CardCD, but it does not have the intended behaviour in that it is not equivalent to CardPlus. CardSub models the behaviour in which the ability to changePin is nondeterministic. In the case of CardSub2 we have inherited the behaviour of CardCD but have realised equivalence with the behaviour of CardPlusF rather than with CardPlus. Moreover, CardSub2 is not a subtype of Card. CardSub2 models a form of inheritance in which not only have we added extra behaviour (ehangePin), but we have redefined the behaviour of an operation. We added the requestDeallocate operation in order to achieve stability and this has effectively redefined the dealloeateCard action such that it must be preceded by the requestDealloeate action. A m a j o r difficulty with the representation of inheritance in CCS arises from the need to link in new behaviour such that the required timeordering of operations is maintained. This was complicated for the simple agent CardCD and is likely to be much more difficult for complex agents. In addition, representing inheritance by the composition of agents in the manner we have
shown does not seem a very natural model of inheritance. 8. C O N C L U S I O N S We have only been able to specify inheritance in CCS by introducing extra complexity into the specification. Subtype inheritance was obtainable but at the expense of having unacceptable nondeterministic behaviour in the subtype. By modifying the behaviour of the sub-class to include the requestDeallocate action, a sub-class having deterministic behaviour was achievable by inheritance but the subtype relationship was sacrificed. CCS is essentially heterarchical and cannot easily capture the hierarchical relationships required for inheritance. In order to specify inheritance with a suitable degree of clarity, either we need a new calculus or we must find other ways of using an existing calculus. REFERENCES 1.
2.
3.
R.Milner. Communication and Concurrency. Prentice Hall International (UK) Ltd, 66 Wood Lane End, Hemel Hempstead, Herts HP2 4RG, 1989. Grady Booth. Object-Oriented Design With Applications. B e n j a m i n / C u m m i n g s , London, 1991. E.J.Baillie. Towards A Satisfaction Relation
Between CCS Specifications And Their Refineraents. PhD thesis, University of Hert4.
5.
fordshire, 1992. Cleaveland, Parrow, and Steffen. The Concurrency Workbench: a semantics-based tool for the verification of concurrent systems. Teclmical Report ECS-LFCS-89-83, LFCS, University of Edinburgh, Department of C o m p u t e r Science, University of Edinburgh, August 1989. Luca Cardelli and Peter Wegner. On Understanding Types, D a t a Abstraction, and Polymorphism. Computing Surveys, 17(4), December 1985.