Nuno Amálio, Susan Stepney, and Fiona Polack. Department of Computer Science, University of York, York, YO10 5DD, UK. {namalio,susan,fiona}@cs.york.ac.
Templates and Generics for Translating UML Class Diagrams into Z Nuno Am´alio, Susan Stepney, and Fiona Polack Department of Computer Science, University of York, York, YO10 5DD, UK {namalio,susan,fiona}@cs.york.ac.uk
Abstract. This paper explores the use of templates and generics in translating from class diagrams to formal descriptions. It presents an approach for the translation of UML class diagrams into Z, which builds on previous work, correcting problems found in those approaches. This allows a plug-and-play approach to different formalisations of UML semantics. As well as providing rigorous translation, we claim that our approach enhances the readability, conciseness and abstraction of the resulting Z specification. Keywords: Z, UML, translation, requirements specification.
1
Introduction
The Unified Modelling Language (UML) [1, 2] is widely used in industrial systems development. The language is a set of notations for describing a system from various views. These notations are recognised as being intuitive and the result of modelling experience. However, UML suffers from the usual problems of semiformal systems analysis and design notations – the UML models have weak semantics; there is substantial disagreement on the semantics of some key concepts (for example associations) – predicates on the state and behaviour of systems, expressed in OCL, are not integrated with the structure, expressed in the UML diagrams – this introduces potential for inconsistency and error – although there are approaches for checking the authenticity of UML diagrams, it is hard to verify the models expressed in UML, for example, to ensure that various required properties are correctly expressed To overcome these limitations, there have been many attempts to translate diagrammatic constructs into formal specification languages. These include translations to B [3], to Z [4–8], and Object-Z [9, 8]. In this paper, we consider translation of UML class model concepts to Z. There are advantages and disadvantages in this choice (these are considered in more detail in [10]). In its favour, Z allows free expression of most set and predicate concepts; it has relatively mature tool support for writing and checking descriptions; proof and refinement are well researched. The disadvantage of
2
Nuno Am´ alio, Susan Stepney, and Fiona Polack
Concept Attributes
Comments There are generics for different kinds of attributes (single valued, multi-valued, etc.), see appendix B.2. Association Role generics are essentially the same in purpose as those for atRoles tributes, but with different names to enhance readability and traceability; variants for composition are included (see appendix B.2). Class Exten- A class extension declares the set of object identities of the class, and sions a mapping from identities to the class intension (see text). Association The generic of the association class intension simply defines the roles Class Intensions of the classes participating in the association (see text). Table 1. Summary of Generics used in UML Translation
using Z to express object-oriented models is that the Z must capture the objectoriented semantics as well as the modelled concepts (compared, for example, to Object-Z). However, no current object-oriented formalism provides the range and variety of tool support; verification and development approaches are not yet mature; and, the object-oriented formalisms impose a semantics on the UML models, which may be appropriate for many systems but reduces the flexibility of the formal translation approaches. To provide a systematic approach to translation of UML class models to Z, and to provide the necessary traceability between the UML and the Z models, we propose a set of generics and templates. In Z, generics are very flexible; there are none of the constraints that, for example, the B Method imposes to ensure provability of system conjectures. There is a price to pay for this flexibility – the danger that a Z generic be instantiated in an inappropriate, or even contradictory, manner. (Type-constrained generics [11] have been proposed to address some of this problem, but are not yet fully supported.) In our translation, Z generics are used wherever possible, and template instantiations used where generics are inappropriate. Despite the flexibility of Z generics, many aspects of the UML translation are not sufficiently generalisable to use the generics (at all or alone). We provide a set of templates for the principal components of the UML class model. The templates express the structure of each element of the translation, and could form the basis for a tool-supported application-specific toolkit. Note that application-specific toolkit is one of the patterns identified in [12];our templates use or elaborate several other Z patterns – name predicates is the inspiration for separation of association rules into separate predicates, a source of much flexibility in the templates; name consistently is elaborated to define the conventions used in the pattern templates (see Appendix A). The generics proposed for the UML translation are listed in table 1; details of those not explained in the main text can be found in Appendix B. This paper concentrates on the use of templates in the translation of the UML association class and composition concepts; these are two of the UML concepts whose formal expression is often inadequate. The other UML class model concepts for which templates exist are listed in table 2. The full set of concepts
Templates and Generics for Translating UML Class Diagrams into Z
3
Concept Class
Templates 1. object identities of non-specialised classes expressed as given sets; object identities of specialised classes 2. class intensions for simple classes and subclasses 3. class extensions instantiating the extension generic, and expressing additional predicates Attribute 1. attribute types not directly available in Z 2. attribute definitions, instantiating the relevant attribute generic Association 1. role definitions, instantiating the relevant role generic 2. predicates expressing (a) link coherence (the object identities in a link do exist); (b) mutual reference (references to objects in the context of associations are mutual); (c) other constraints (which may be expressed in the OCL component of a UML model) 3. the complete association, including the extensions of the associated classes and the required predicates Generalisation 1. predicates expressing (a) the abstract property of superclasses; (b) state consistency (the state of an object whether viewed as a subclass instance or superclass instance must always be the same) 2. the complete generalisation, including superclass and subclass extensions and the the required predicates Subsystems / 1. Subsystem schemas, including the extension schemas of the subsysSystems tem’s classes, and property schemas of relations among the classes. 2. System schemas, including all the subsystem schemas. Table 2. Summary of additional Concepts for which Templates have been produced for UML Translation. See [13] for details.
is available in a technical report [13]. Our template approach provides a readable Z translation, and a modular approach to capturing UML semantics. Where a different semantic interpretation is required (for example in class hierarchies, or association classes) only a very few templates need to be modified. In this paper, we illustrate the use of the translation templates and generics for a simplified model of car ownership, figure 1. The template notation used is summarised in Appendix A.
2
Association Classes
In UML, an association class allows attributes (and methods) to be attached to an association. The association class is inherently bound to its association; the combinations of the association and the association class is semantically a single element of the class model [2, p. 157] The approach is illustrated for the association class, Registration, which adds a date attribute to the association between the classes Person and Car.
4
Nuno Am´ alio, Susan Stepney, and Fiona Polack Register date : DATE 0..5
Car brand : CARBRAND year : YEAR 1
attachedto
Person
1
owns
owner
name : NAME age : NAT tickets[0..*] : TICKET
wheel
wheels
tyre
Wheel
Tyre
model : WHMODEL 3,4,6
1
1
Fig. 1. UML class diagram used in the Illustrations. In this model, a Car must be owned by one Person; a Person can own up to five Car s. For each Car owned by a Person, there is a registration date, represented in the association class Register . Car s are composites, where the components are a number of Wheel s (three, four or six). Each Wheel in turn has component Tyres (one per Wheel ).
2.1
Auxiliary definitions
The definition of the association class requires the definition of the classes that are the terminals of the association component of the association class. A class in UML is represented in Z as an intension (AClass) and an extension (SClass). The class intension defines the properties that the set of objects of the class (instances) have in common. The class extension defines the set of objects of the class. Here, we summarise the translation of Person from templates and generics. Class intension. The class intension defines the attribute types, the attributes, and the roles of the class. 1. Attribute types. [13] provides templates for defining given sets and enumerations; here only given sets and Z’s natural numbers are used. The template for attribute types as given sets, and an illustration of its instantiation, are [ ATTRTYPE
,
ATTRTYPEi
∗
]
[NAME , TICKETS ]
2. Attributes. The template for attributes (below) describes how to link the attribute name (from the class model) with the appropriate attribute type construction. The type construction instantiates the appropriate attribute generic (Appendix B.2). In the illustration, name and age are single-valued attributes, and are declared using the Attrib generic; tickets is a list of values from the set, and instantiates the Attrib[].. generic, which requires parameters for both the attribute type and the multiplicity.
attrName
: attrGeneric [ ATTRTYPE ]
( n ) 8 ( n 1 . . n2 ) )
Templates and Generics for Translating UML Class Diagrams into Z
5
3. Roles. The association between Person and Car is defined according to UML conventions, in terms of the roles of its two ends. In the Person intension therefore, there is the role owns. This is defined by instantiation of the relevant role generic (Appendix B.2). Here, a Person owns between zero and five Car s; the generic is that for 0 . . m associations with no ordering of the linked instances, Role[].. ; like Attrib[].. , this takes parameters for the role type (here the identifier of the association class1 ) and the multiplicity. Here, the identity of the association class, derived as for Person, below, is IDREGISTER. Template. The class intension template is Cl Aattribute definition role definition
∗
∗
constraint on attributes/roles
∗
Illustration. The translation of the intension of class Person is APerson name : Attrib1 [NAME ] age : Attrib1 [ ] tickets : Attrib[ ].. [TICKET ](0 . . many) owns : Role[ ].. [IDREGISTER](0 . . 5) age ≥ 18
Class extension. The class extension expresses objects in terms of identities of instances of the class intension. The template, and its instantiation for the Person identities, are
, ID
[ ID CL
CLi
∗
]
[IDPERSON ]
Generic and Template. Class extensions are defined generically. The generic and the template that describes its instantiation are, SClass [IDCL, ATTRSCL] objIds : IDCL objAttrs : IDCL → 7 ATTRSCL
dom objAttrs = objIds 1
For normal associations, the identifier of the class at the opposite end of the association would be used instead; here we use the identifier of the association classes to allow access to its properties.
6
Nuno Am´ alio, Susan Stepney, and Fiona Polack
constraint on objects
S Cl SClass[ID CL , A Cl ][ cl Ids/objIds, cl Attrs/objAttrs] ∗
The generic provides a mapping from identities to the intension; the template instantiates the generic for a specific class, and renames the components of the generic with meaningful, names based on the class name (to avoid name clashing). Illustration. SPerson == SClass[IDPERSON , APerson][personIds/objIds, personAttrs/objAttrs] 2.2
Deriving the Z representation for the Association Class
Translation of association classes requires the definition of its class and association properties. Thus, like classes we have an intension and extension schema, and like normal associations (see [13]), an association properties schema. These definitions, however, present some differences from general classes and associations. The approach is illustrated for the association class, Register, which adds a date attribute to the association between the classes Person and Car, figure 1. Intension schema. The generic AAssocClass, factors the commonality of this kind of construct, each association class has two roles. The template of the association class intension schema (below right) includes the instantiation of the association class generic, and the definition of the attributes and extra roles (of other associations in which an association class may take part) of the association class. Generic and Template. AAssocClass [IDCL1 , IDCL2 ] assocEnd1 : IDCL1 assocEnd2 : IDCL2
constraint on attributes/roles
Illustration. The intension of the Register association class is ARegister AAssocClass[IDPERSON , IDCAR] date : Attrib1 [DATE ]
A Acl AAssocClass[ID CL1 , ID CL2 ] attribute definition ∗ role definition ∗ ∗
Templates and Generics for Translating UML Class Diagrams into Z
7
Extension schema. It is implicit in the semantics of association class that no two instances of an association class can have the same link-tuple (no link repetition rule). This extra property is added to the normal class extension. Template. The template of the extension schema includes the instantiation of the class generic in the declaration part, and states the no link repetition rule in the predicate; this rule says that distinct instances of an association class cannot have the same binding (component values) of the association-class generic intension schema (included in the intension schema of any association class).
S Acl SClass[ID ACL , A Acl ][ acl Ids/objIds, acl Attrs/objAttrs]
∀ ac1 , ac2 : acl Ids | ac1 6= ac2 • (λ A Acl • θAAssocClass)( acl Attrs ac1 ) 6= (λ A Acl • θAAssocClass)( acl Attrs ac2 )
(This is a case where constrained generics [11] would allow a full generic to be used.) Illustration. The instantiation of the association class extension template is SRegister SClass[IDREGISTER, ARegister ][regIds/objIds, regAttrs/objAttrs] ∀ ri1 , ri2 : regIds | ri1 6= ri2 • (λ ARegister • θAAssocClass)(regAttrs ri1 ) 6= (λ ARegister • θAAssocClass)(regAttrs ri2 )
Properties schema. The Z translation of any association (including association classes) uses a properties schema to enforce the consistency of links and other association constraints (possibly stated in OCL). Consistency of links involves link coherence (stating that links do actually exist) and mutual reference (stating that references to objects in the context of associations are mutual); both are implicit in the UML semantics. Following the Name Predicates pattern [14] we express each of these properties as separate templates. LinkCoherence Template. This checks that the references held by the roles of the association class and participant classes are defined in the extension schema of the referenced class. Note the optionality between Z terms, which is dependent on the multiplicity of the role.
8
Nuno Am´ alio, Susan Stepney, and Fiona Polack
LinkCoherence Acl Cl1 S Acl ; S Cl1 ; S Cl2
Cl2
∀ oac : acl Ids; o1 : cl1 Ids; o2 : cl2 Ids • ( acl Attrs oac ).assocEnd1 ∈ cl1 Ids ∧ ( acl Attrs oac ).assocEnd2 ∈ cl2 Ids ∧ ( cl1 Attrs o1 ). role1 ( ∈ 8 ⊆ ) cl2 Ids ∧ ( cl2 Attrs o2 ). role2 ( ∈ 8 ⊆ ) cl1 Ids
LinkCoherence Illustration. LinkCoherenceRegisterPersonCar SRegister ; SPerson; SCar ∀ r : regIds; p : personIds; c : carIds • (regAttrs r ).assocEnd1 ∈ personIds ∧ (regAttrs r ).assocEnd2 ∈ carIds ∧ (personAttrs p).owns ⊆ regIds ∧ (carAttrs c).owner ∈ regIds MutualReference Template. This states that the links of the association class instances and the links of the participant class instances reference each other; the optionality is as for link coherence.
MutualReference AssocCl Cl1 S AssocCl ; S Cl1 ; S Cl2
Cl2
∀ oac : assocCl Ids; o1 : cl1 Ids; o2 : cl2 Ids • (let o1 i == ( assocCl Attrs oac ).assocEnd1 • oac ( ∈ 8 = ) ( cl1 Attrs o1 i ). role1 )
(let o2 i == ( assocCl Attrs oac ).assocEnd2 • oac ( ∈ 8 = ) ( cl1 Attrs o2 i ). role2 ) ( ( ∀ oaci : 8 let oaci == ) ( cl1 Attrs o1 ). role1 • o1 = ( assocCl Attrs oaci ).assocEnd1 ) ( ( ∀ oaci : 8 let oaci == ) ( cl2 Attrs o2 ). role2 • o2 = ( assocCl Attrs oaci ).assocEnd2 )
MutualReference Illustration. MutualReferenceRegisterPersonCar SRegister ; SPerson; SCar ∀ r : regIds; p : personIds; c : carIds • (let pi == (regAttrs r ).assocEnd1 • r ∈ (personAttrs pi ).owns) ∧ (let ci == (regAttrs r ).assocEnd2 • r = (carAttrs c).owner ) ∧ (∀ ri : (personAttrs p).owns • p = (regAttrs ri ).assocEnd1 ) ∧ (let ri == (carAttrs c).owner • c = (regAttrs ri ).assocEnd2 )
Templates and Generics for Translating UML Class Diagrams into Z
9
OtherContraints Template. This states other constraints of an association. (Since there are none in our example, it is not illustrated here.)
OtherConstraints AssocCl S AssocCl S Cl1 ; S Cl2
constraint predicate i
Cl1
Cl2
+
Association Class Properties Template. This includes the participant class extensions and the required predicate schemas in the predicate.
AssocCl AssocCl Cl1 Cl2 S AssocCl ; S Cl1 ; S Cl2
LinkCoherence AssocCl Cl1 Cl2 MutualReference AssocCl Cl1 Cl2
OtherConstraints
AssocCl
Cl1
Cl2
Association Class Illustration. AssocClRegisterPersonCar SRegister ; SPerson; SCar LinkCoherenceRegisterPersonCar MutualReferenceRegisterPersonCar
2.3
Discussion
A common area of semantic confusion over association classes is the implicit constraint in the UML structure, ensuring that there is precisely one instance of the association class for each unique link of the association. Fowler [15] notes the tendency to ignore this constraint. Stevens [16] comments on the desirability or otherwise of such a constraint, and suggests that future UML versions allow semantical variations according to the modeller’s needs. Our approach supports the implicit UML 1.4 semantics, but also allows some semantic variability. For example, we provide role definitions allowing link repetition, which the UML 1.4 semantics does not permit, as experience shows that in some cases repetition is required [16].
3
Composition
In UML, ordinary associations exist when classes are independent concepts. Where one class is subordinate to another, for example where the instances of one class exist only or primarily in the context of the other, an aggregation or
10
Nuno Am´ alio, Susan Stepney, and Fiona Polack
a composition is defined. An aggregation simply states that such a subordination exists; in terms of the class model translation, it is indistinguishable from the equivalent ordinary association. However, a composition is a tighter concept, requiring that components (parts) be associated to a composite (or whole) throughout their existence. Compositions have the following rules: the part must be included in at most one composite at a time (unshared containment); if a composite is destroyed the parts must also be destroyed (deletion propagation). Translation of compositions involves the definition of the intensions and extensions of classes composite and part, the definition of the properties schema of composition, and the statement of the deletion propagation property. Here, our approach is illustrated for the two-level composition of figure 1. Extension and Intension schemas Intension and extension schemas of composites and parts are defined following the template of ordinary classes. There are specific generics for the role definitions of composites and parts (section B.2). Illustration The intensions of Car and Wheel include the instantiation of the relevant role generics. ACar brand : Attrib1 [CARBRAND] owner : Role1 [IDREGISTER] wheels : Role° C[ ].. [IDWHEEL]({3, 4, 6})
AWheel model : Attrib1 [WHMODEL] attachedto : Role}1 [IDCAR] tyre : Role1 [IDTYRE ]
Properties schema. Composition has the properties of an association, plus the additional UnsharedContainment property. Unshared Containment Template. This includes the extension of the composite; the predicate states the rule that the parts of any two distinct composite instances must be disjoint.
UnsharedContainment ClWhole S ClWhole
ClPart
∀ w1 , w2 : clWhole Ids | w1 6= w2 • disjointh( clWhole Attrs w1 ). parts , ( clWhole Attrs w2 ). parts i
Templates and Generics for Translating UML Class Diagrams into Z
11
Composition Properties Template. This includes the participant classes; the predicates are those of associations, plus that for unshared containment.
Comp ClWhole ClPart S ClWhole ; S ClPart
UnsharedContainment ClWhole
ClPart
LinkCoherence ClWhole ClPart MutualReference ClWhole ClPart
OtherConstraints
ClWhole
ClPart
Illustration. The unshared containment predicate and the properties schema is illustrated for the composition of car and wheels. UnsharedContainmentCarWheel SCar
CompCarWheel SCar ; SWheel
∀ c1 , c2 : carIds | c1 6= c2 • disjointh(carAttrs c1 ).wheels, (carAttrs c2 ).wheelsi
UnsharedContainmentCarWheel LinkCoherenceCarWheel MutualReferenceCarWheel
Deletion Propagation. The deletion propagation property of composition needs to be stated dynamically, through operations and a conjecture. Delete0 Template. We introduce a Delete operation, which removes a set of objects from a class extension. The template of this operation states that in the after-state of the operation the given objects are deleted from the class extension; it does not itself include deletion of the parts. The optional 0 is used if the class is a composite (hence with parts to delete). This template may be instantiated for any class.
ID CL cl Ids? ⊆ cl Ids cl Ids = cl Ids \ cl Ids? cl Attrs = cl Ids? − C cl Attrs
Delete Cl 0 ∆S Cl ; cl Ids? :
0
0
Delete0 Illustration. Delete is applied to the classes of the two-level composition. (Delete on Tyre has no ‘0’ as this class is not a composite).
12
Nuno Am´ alio, Susan Stepney, and Fiona Polack
DeleteWheel 0 ∆SWheel wheelIds? : IDWHEEL
DeleteCar 0 ∆SCar carIds? : IDCAR
wheelIds? ⊆ wheelIds wheelIds 0 = wheelIds \ wheelIds?
carIds? ⊆ carIds carIds 0 = carIds \ carIds? − carAttrs carAttrs 0 = carIds? C
wheelAttrs 0 = wheelIds? − C wheelAttrs
DeleteTyre ∆STyre tyreIds? : IDTYRE
tyreIds? ⊆ tyreIds tyreIds 0 = tyreIds \ tyreIds? − tyreAttrs tyreAttrs 0 = tyreIds? C PartsToDelete Template. If a class is a composite, its parts must also be deleted. The PartsToDelete operation selects the parts instances of each part class to be deleted, namely those that are referenced by the composite instances to be deleted. This operation is used to build up the Delete operation on composites.
ClWhole PartsToDelete ΞS ClWhole ; clWhole Ids? : ID CLWHOLE clPart1 Ids? : ID CLPART1 clParti Ids? : ID CLPARTi ∗ S clPart1 Ids? = { w : clWhole Ids? • ( clWhole Attrs w ). parts1 } S clParti Ids? = { w : clWhole Ids? • ( clWhole Attrs w ). partsi } ∗
PartsToDelete Illustration. WheelPartsToDelete ΞSWheel wheelIds? : IDWHEEL tyreIds? : IDTYRE
tyreIds? = {w : wheelIds? • (wheelAttrs w ).tyre}
CarPartsToDelete ΞSCar carIds? : IDCAR wheelIds? : IDWHEEL S wheelIds? = {c : carIds? • (carAttrs c).wheels}
Delete Template. The template of the delete operation of a composite is given below. In the declaration (before •), the extensions of the part classes and the inputs of the delete operations on parts are hidden (following the promotion
Templates and Generics for Translating UML Class Diagrams into Z
13
pattern). In the predicate (after •), we have a conjunction of operations: the instances of each part class are retrieved (operation PartsToDelete), the instances of each part class are actually deleted (Delete operations on parts), and the instances of the composite are deleted (Delete operation on composite). The operations delete on parts are either instantiations of the ordinary or composite (if the part is also a composite) delete operation templates. The operation delete on composite (Whole) is an instantiation of the ordinary delete operation template.
Delete ClWhole == ∃ ∆ SClPart1 ; clPart1 Ids? : ; ∆ SClParti ; clParti Ids? : ID CLPARTi ClWhole PartsToDelete ∧ Delete ClPart1 ∧ Delete ClParti ∗ ∧ Delete ClWhole 0
ID CLPART1 ∗ •
Delete Illustration. DeleteWheel == ∃ ∆STyre; tyreIds? : IDTYRE • WheelPartsToDelete ∧ DeleteTyre ∧ DeleteWheel 0
DeleteCar == ∃ ∆SWheel ; wheelIds? : IDWHEEL • CarPartsToDelete ∧ DeleteWheel ∧ DeleteCar 0
Conjecture Template. As in the pattern express implicit properties [12], we use a conjecture to test the assertion that deletion propagates through compositions. The required condition of the after state of any delete operation, that the input instances are deleted, is expressed in a separate template, CondPostDelete.
CondPostDelete Cl S Cl 0 cl Ids? : ID CL
cl Ids? ∩ cl Ids = ∅ cl Ids? ∩ dom cl Attrs 0 = ∅ 0
In the full conjecture, CondPostDelete is instantiated for each class in the composition(s). The conjecture asserts that the composite instances must be deleted, along with the instances of each part class, and any component parts of these part classes (if they are also compositions). The antecedent of the conjecture template introduces the state and after state of the system (instances are deleted from the collection of system instances), and the delete operation on a composite.
∆System; Delete ClWhole ` CondPostDelete ClWhole ∧ (∃ ClWhole PartsToDelete • CondPostDelete ClPart1 ∧ CondPostDelete ClParti ∗ ) [The deletion of sub-components] ∧ (∃ ClParti PartsToDelete • CondPostDelete ClSubPart1 ∧ CondPostDelete ClSubParti ∗ ) ∗
14
Nuno Am´ alio, Susan Stepney, and Fiona Polack
Conjecture Illustration. The conjectures for the two compositions of figure 1 are ∆System; DeleteWheel ` CondPostDeleteWheel ∧ (∃ WheelPartsToDelete • CondPostDeleteTyre) ∆System; DeleteCar ` CondPostDeleteCar ∧ (∃ CarPartsToDelete • CondPostDeleteWheel ) ∧ (∃ WheelPartsToDelete • CondPostDeleteTyre)
3.1
Discussion
Some earlier formalisations have addressed composition characteristics through operation specifications [6], and in terms of conjectures [8]. What is new here is the full expression of the additional constraints that are inherent to composition, the complete, extensible composition operations, and the conjecture on deletion for the whole structure. The authors are not aware of any other discussion of composition that incorporates more than one level. Here we illustrate it for the Car → Wheel → Tyre composition. Ongoing work is looking at (a) proving the conjecture for the example system and (b) generalising the proof to the template form. Given a template proof, two things follow. Firstly, if the translation templates are correctly instantiated, the instantiated template proof automatically generates the specific proof. (If OtherConstraints are present, they may have to be discharged explicitly.) Secondly, if there is doubt about the instantiation of the templates, reproving the conjecture increases confidence in the translation, at least for this part of the system.
4
Subsystems and Modularity
In translating large class models it is often convenient to group classes and the relationships among them into subsystems. The whole system is built up from all the subsystems. In our approach, we use Z schemas to represent subsystems and systems. When relationships among classes cross subsystems, additional subsystems may be created (e.g. an association between class A of subsystem S1 , and class B of subsystem S2 would be included in a third subsystem, S3 , including the extensions of the participant classes, and the association properties schema). Templates The subsystem schema template includes the extensions of the subsystem classes, and the relationships between those classes. The system schema template just includes the subsystem schemas.
Templates and Generics for Translating UML Class Diagrams into Z
Subsystem Subsys S Cli ; S Cli
Assoc
Cl Cl Generalisation Acl AssocCl ClSuper Cl Comp ClWhole Cl ClPart k1
SubSysi
∗
∗
k2
j
k3
l
;
System SubSys1
∗
15
w
∗
k4
p
∗ ∗
Illustration. We illustrate our modular approach by grouping the model of figure 1 into two subsystems (for this model one would suffice, we do this to illustrate the approach): the classes involved in the compositions are grouped in the SubsystemCar, and the remaining ones in SubsystemPerson.
5
SubsystemCar SCar ; SWheel ; STyre
SubsystemPerson SPerson; SRegister ; SCar
CompCarWheel
AssocClRegisterPersonCar
CompWheelTyre
System SubsystemCar ; SubsystemPerson
Tool Support
The templates presented in the paper are currently expressed and instantiated manually. A true application toolkit would require automation, which would in turn entail formalising (in some sense) the template concepts. Two possible approaches are envisaged. Firstly, a Z formalisation: the instantiable elements of the templates could be constrained to take suitable Z types; essentially, this requires a formal metamodel for templates which can be used to constrain the instantiation. More thoughts on Z tool support for patterns can be found in [14]. Secondly, a UML formalisation: all the official UML variants have published metamodels; each concept in the class model has a defined metastructure. Thus, the templates could be related directly to UML metaconcepts. UML metamodels are currently weak; they are inconsistent and incomplete, being defined in un-verified class models and OCL. However, work by pUML, in particular [17, 18], has produced a tool capable of inputting a metamodel description (at any meta-level) and checking the conformance of a model (or metamodel at the next lower level). The result is assurance that the specific UML model is a correct instantiation of the relevant UML metamodel. A combination of a correct UML model and a verifiable Z specification of the semantic content is attractive. At one level, is analogous to the formal metamodelling of [19], in which UML metamodel syntax and semantics are defined in B, and UML models are then checked against the metamodel and translated to B models that can be verified using the relatively advanced proof support for the B method. However, the template version would provide more flexibility to
16
Nuno Am´ alio, Susan Stepney, and Fiona Polack
vary both the model semantics and the orientation to specific types of system (the B work is specific to information system specification).
6
Conclusion
We present key examples of an extensive set of templates that can be instantiated to produce a formal (Z) specification of a system modelled in a UML class diagram and OCL predicates. We do not give detailed template translations for OCL statements; these would influence the writing of predicates such as OtherConstraints on appropriate parts of the model [13]. In general, the OCL notations are merely inelegant extensions of set- and predicate-based languages such as Z; however, in cases where significant amounts of information are expressed in OCL constraints, more systematic approaches to their translation would also required. There is other work in progress to formalise OCL (e.g. [20]). Our translation approach so far considers only UML class models at the specification level (ie design- and implementation-level concepts such as methods and visibility are ignored). In addition, the approach – – – –
supports only single-inheritance considers only binary associations does not distinguish aggregation and association does not explore generalisation of associations
The templates capture the semantic properties of the UML concepts, so that translators can concentrate on expressing the semantics of the modelled system. Once again we come across with the problems of UML 1.4 semantics. On the one hand the semantics is ambiguous and on the other it does not allow enough flexibility (e.g. link repetition). The templates are broken down to a level where variants of the UML concept semantics can be accommodated in most cases by replacing a low-level template. This also provides good traceability from diagram concept to model concept. The UML model and the Z specification complement each other. The UML model stresses overall structure abstractly, whilst the Z specification clarifies the detail. Z is useful not only at describing detailed system properties, but also at stating the intended semantics of the abstract UML model. Future work will involve the translation of UML statecharts by applying the ideas underlying this work, and possibly involving Circus [21] as statecharts present concurrent behaviour. We aim to develop a requirements specification technique that combines different modelling notations, exploring the strengths and weaknesses of each notation. Our approach, using generics and templates, enhances – the readability and abstraction of the Z specifications resulting from the UML translation
Templates and Generics for Translating UML Class Diagrams into Z
17
– the modularity and compositionality of our approach, making it very clear the distinct components of the UML model, making easy the combination of different diagrams, and allowing reuse – the traceability of the Z specification that is made easy by the modularity features and the naming conventions of our approach – the flexibility in the expression of system properties, by allowing some semantic variability in the UML – the complete approach to composition and association class Acknowledgements: This research was supported for Am´alio by the Portuguese Foundation for Science and Technology under grant 6904/2001.
References 1. OMG. Unified Modeling Language Specification, version 1.4. Object Management Group (2001). Available at http://www.omg.org/uml 2. Rumbaugh, J., Jacobson, I., Booch, G. The Unified Modeling Language Reference Manual. Addison Wesley Longman, Reading, Mass. (1999) 3. Nguyen, H. P. D´erivation De Sp´ecifications Formelles B a ` partir de Sp´ecifications Semi-Formelles. Ph.D. thesis, Laboratoire CEDRIC, Conservatoire National des Arts et M´etiers, Evry, France (1998) 4. Hall, A. Using Z as a specification calculus for object-oriented systems. In Hoare, C. A. R., Bjørner, D., Langmaack, H., eds., VDM ’90 VDM and Z– Formal Methods in Software Development, volume 428 of LNCS, pp. 290–318. Springer (1990) 5. Hall, A. Specifying and interpreting class hierarchies in Z. In Bowen, J., Hall, A., eds., Z User Workshop, Cambridge, Workshops in Computing, pp. 120–138. Springer (1994) 6. France, R. B., Grant, E., Bruel, J.-M. UMLtranZ: An UML-based rigorous requirements modeling technique. Technical report, Colorado State University, Fort Collins, Colorado, USA (2000) 7. Bruel, J.-M., France, R. B. Transforming UML models to formal specifications. In B´ezivin, J., Muller, P.-A., eds., UML’98: Beyond the Notation, Mulhouse, France, volume 1618 of LNCS. Springer (1998) 8. Dupuy, S. Couplage de notations semi-formelles et formelles pour la sp´ecification des syst`emes d’information. Ph.D. thesis, Universit´e Joseph Fourier, Grenoble I (2000) 9. Kim, S.-K., Carrington, D. A formal mapping between UML models and Object-Z specifications. In Bowen et al. [22], pp. 2–21 10. Am´ alio, N., Polack, F. Comparison of formalisation approaches of UML class constructs in Z and Object-Z. In ZB 20003, Turku, Finland, LNCS. Springer (2003). To be published 11. Valentine, S. H., Toyn, I., Stepney, S., King, S. Type-constrained generics for Z. In Bowen et al. [22], pp. 250–263 12. Stepney, S., Polack, F., Toyn, I. A Z patterns catalogue I, specification and refactoring. Technical Report YCS-2003-349, Department of Computer Science, University of York (2003) 13. Am´ alio, N., Polack, F., Stepney, S. Templates and generics for translating UML class diagrams into Z. Technical Report YCS-2003, Department of Computer Science, University of York (2003). Inpress
18
Nuno Am´ alio, Susan Stepney, and Fiona Polack
14. Stepney, S., Polack, F., Toyn, I. Patterns to guide practical refactoring: examples targetting promotion in Z. In ZB 20003, Turku, Finland, LNCS. Springer (2003). To be published 15. Fowler, M., Scott, K. UML Distilled. Addison-Wesley, 2nd edition (2000) 16. Stevens, P. On the interpretation of binary associations in the unified modelling language. Software and Systems Modeling, 1(1):68–79 (2002) 17. Alvarez, J., Clark, A., Evans, A., Sammut, P. An action semantics for MML. In Gogolla and Kobryn [23], pp. 2–18 18. Clark, A., Evans, A., Kent, S. Engineering modelling languages: A precise metamodelling approach. Available at http://www.puml.org/mml (2000) 19. Polack, F., Laleau, R. A rigorous metamodel for UML static conceptual modelling of information systems. In CAiSE 2001: Advanced Information Systems Engineering, Interlaken, Switzerland, volume 2068 of LNCS, pp. 402–416. Springer (2001) 20. Cengarle, M. V., Knapp, A. A formal semantics for ocl 1.4. In Gogolla and Kobryn [23], pp. 118–133 21. Woodcock, J., Cavalcanti, A. The semantics of Circus. In Bert, D., et al., eds., ZB 2002: Formal Specification and Development in Z and B, Grenoble, France, volume 2272 of LNCS, pp. 184–203. Springer (2002) 22. Bowen, J., et al., eds. ZB 2000: Formal Specification and Development in Z and B, York, UK, volume 1878 of LNCS. Springer (2000) 23. Gogolla, M., Kobryn, C., eds. UML 2001: The Unified Modeling Language. Toronto, Canada., volume 2185 of LNCS. Springer (2001)
A
Naming Convention Pattern
The Z pattern Name Consistently encourages the declaration and use of an explicit naming convention. The convention that we use has three elements, each presented here as a separate pattern elaboration.
Name Consistently (elaboration): Distinguish Class Elements Intent: The UML class concept is formalised as an intension (or type) and an extension (or set of objects). These need to be clear in the templates, and in the resultant Z, for traceability and ease of reading. Solution: Following Hall [4, 5], class extension schemas are preceeded by S. Class intension schemas are preceeded by the A. 2
Name Consistently (elaboration): Distinguish Generic Schemas Intent: distinguish specific elements of the Z language for readability Problem: This paper defines generic and template schemas, as well as giving actual Z descriptions. The templates and the Z descriptions instantiate generics. The templates, in particular, are not easy to read. It is desirable to be able to distinguish the generic schema definitions and their instantiations. Solution: Use a different font for the name of generic schemas, in definition and instantiation. Here, we use plain Roman font for generics, and default italic face for all other Z.
Templates and Generics for Translating UML Class Diagrams into Z
19
2
Name Consistently (elaboration): A language for templates Intent: Templates comprise fixed elements, elements to be substituted, various forms of optionality, and various forms of list. These elements must be clear in the templates. Solution: The following notational conventions are used here.
– substitutable parameters are placed between the bracket symbols and – optional elements are placed between and – the symbol 8 is used within brackets to denote optionality: (a 8 b) means “either a or b” Where a list of elements might be included, we introduce a general subscripted component within optional brackets with the following decorations:
elementi ∗ indicates a list of element1 to elementn , where the list may be empty elementi + indicates a list of element1 to elementn , where the list must – have at least one element –
2
B
Toolkits
B.1
Bounded Containers
This toolkit defines the bounded containers generics, so called because constraints are placed on the size of the container. The bounded powerset generics are defined below; two variants are provided depending on whether the container’s size is specified as a set of numbers (‘. .’ name-ending, size must be one of the numbers provided, includes ranges of numbers) or cardinal number (‘ n ’ name-ending, size must be number provided). In [13] we provide similar definitions for sequences, injective sequences and bags. bset.. [X ] == (λ r : bsetn [X ] == (λ n : B.2
• {xs : X | #xs ∈ r }) • bset.. [X ](n . . n))
UML
UML Multiplicity. Multiplicity constraints restrict the number of values (or references) held by association-ends and attributes. The loose constant many represents the UML ‘*’; UMLCard (cardinality) defines the set of multiplicity values; U M LCard is just a subset of UMLCard. many :
1
UMLCard == {x :
| x ≤ many}
UMLCard2 == UMLCard \{0, 1}
20
Nuno Am´ alio, Susan Stepney, and Fiona Polack
Role Generics In [13], we consider singleton and optional singleton roles, multivalued roles with no ordering, multivalued roles with ordering, and composition roles. The definitions of the first three are provided below. The singleton role generic (multiplicity ‘1’), is defined as a simple set; the optional-singleton is defined as a bounded-powerset whose size can be ‘0’ or ‘1’. Singleton and optional Singleton Role1 [X ] == X
Role01 [X ] == bset.. [X ](0 . . 1)
Multi-valued roles are further divided in without value repetition and with value repetition; multi-valued unordered roles without repetition are defined as bounded powersets; those with repetition as bags. Multi-valued unordered roles without repetition are defined as injective sequences; those with repetition as sequences. Variants of each multi-valued role are used if the multiplicity constraint is specified as a set of numbers (includes range) or a cardinal number. Each role definition is constrained to be within the multiplicity cardinality. Composition roles are divided into part roles and composition roles. Part roles are normal roles with an added naming convention (the symbol ° C is part of the role name). Composition roles differ from singleton and optional singleton role definitions also in naming conventions (symbol ‘}’); only two role definitions are provided in accordance with UML syntax (a part is associated with at most ‘1’ composite). The definition of these roles is omitted for brevity here (see [13]). Multi-valued with no ordering Role[ Role[ Role[
== bset.. [X ] ∩ ( UMLCard × ( X )) [X ] == bsetn [X ] ∩ (UMLCard2 × ( X )) ]n ]R.. [X ] == bbag.. [X ] ∩ ( UMLCard × (bag X ))
Role[
]Rn [X ]
].. [X ]
== bbagn [X ] ∩ (UMLCard2 × (bag X ))
Multi-valued with ordering Role.. [X ] == biseq.. [X ] ∩ ( UMLCard × (iseq X )) Rolen [X ] == biseqn [X ] ∩ (UMLCard2 × (iseq X ))
RoleR.. [X ] == bseq.. [X ] ∩ ( UMLCard × (seq X )) RoleRn [X ] == bseqn [X ] ∩ (UMLCard2 × (seq X ))
Attribute Generics Attribute generics have the same sorts of definition as singleton, optional-singleton, and multivalued roles, differing in naming conventions — Role is replaced by Attrib, e.g. Attrib , Attrib[].. , Attrib.. , etc.
