A diagrammatic approach to the semantics of OO modelling notations is proposed. This is based on an innovative and expressive notation dubbed ''constraint diagrams'', which can be used to precisely characterise a range of sophisticated, static constraints on OO models. Other notations, such as those found in UML, can be viewed as projections of constraint diagrams. Work on using constraint diagrams at the core of a 3D modelling notation is also briefly described as a means of similarly providing the semantics of diagrams imposing constraints on dynamic behaviour

Ali Hamie

Division Computing

Franco Civello

John Howse

Richard Mitchell

Stuart Kent Ali

English

Crossref

Semantics through Pictures

Kent, Stuart

Hamie, Ali

Howse, John

Civello, Franco

Mitchell, Richard

Kent Academic Repository

Semantics through PicturesStuart Kent, Ali Hamie, John Howse, Franco Civello, Richard Mitchell1Division of Computing,University of Brighton, Lewes Rd., Brighton, UK.http://www.biro.brighton.ac.uk/biro/index.html, biro@brighton.ac.ukfax: ++44 1273 642405, tel: ++44 1273 642494Abstract. A diagrammatic approach to the semantics of OO modelling notations is proposed.This is based on an innovative and expressive notation dubbed “constraint diagrams”, which canbe used to precisely characterise a range of sophisticated, static constraints on OO models. Othernotations, such as those found in UML, can be viewed as projections of constraint diagrams.Work on using constraint diagrams at the core of a 3D modelling notation is also brieflydescribed as a means of similarly providing the semantics of diagrams imposing constraints ondynamic behaviour.1 IntroductionThis paper outlines a pictorial approach to constructing a precise semantics for object-oriented modelling notations. There are at least four reasons why one might want tobuild a precise semantics:1. To clarify meaning leading to refinements of the notation.2. To clarify meaning for developers using the notation.3. To clarify meaning for tool developers, thereby increasing the likelihood of inter-operability between tools at a semantic level (e.g. code generated from different tools for the same model has the same behaviour). 4. To support semantic checking of models, automated if possible. This includes checking that implementations meet their specifications, checking internal con-sistency of components, and checking for inconsistencies and conflicts between components. (1) just requires the semantics to be written down in a precise form. (2) and (3) requireit to be written down in a form which developers and tool developers can easily under-stand. In addition, it would be desirable for (3) to provide a semantics in a form whichdirectly assists the construction of tools, e.g. the automation of (4).We propose that the semantics is given in terms of an expressive and innovative dia-grammatic modelling notation, dubbed constraint diagrams, which can be used to pre-cisely characterise a range of sophisticated, static constraints on OO models and whichis particularly targeted on (2) and (3) (with some impact on (1) and (4)). A 3D notationbased on constraint diagrams may be similarly used to characterise the semantics ofdynamic behaviour. In essence, our notation is rich enough to characterise a model thatwould otherwise require many different kinds of diagram. The latter can then beviewed as projections of this model. 1. This research was partially funded by the UK EPSRC under grant number GR/K67304Section 2 briefly surveys some of the notations used for describing OO models foundin UML (UML) and Catalysis (d’Souza and Wills, 1997). Section 3 introduces con-straint diagrams and contract boxes. Section 4 outlines how these could be used to givea semantics, and discusses how the approach could be extended to other diagrams inUML.2 Generic Descriptors: Perspectives on a ModelIn essence an OO model is the set of states it is allowed to enter, where a state can bevisualised as an object diagram (snapshot), together with the set of allowed pathsthrough those states. These sets are in general infinite, or at best very large, so impossi-ble to enumerate. Therefore modellers need notations that are able to define very largesets in only a few diagrams. UML calls these notations generic descriptors. Essentiallygeneric descriptors provide ways of writing rules or constraints which determinewhether any particular snapshot or filmstrip is allowed in a model or not. Here we con-sider type and state diagrams (from UML) combined with invariants and action speci-fications (from Catalysis).2.1 Type DiagramsType diagrams define most of the language that can be used in snapshots and con-strains cardinalities of links between objects. The type diagram for the specification ofa library system is given in Figure 1.Only types and association rolenames appearing in the type model may appear in snap-shots. Furthermore the number of links in a snapshot corresponding to a particularassociation may not exceed the cardinality constraints declared on the type model, forany objects of the types associated. For example, focusing on the (unlabelled) associa-tions between  and  and  and 	, a loan object may be linked withFigure 1: Type model for library			 				only one user and one copy, though user and copy objects may be linked to many loanobjects.2.2 State DiagramsA state diagram places constraints on both the static and dynamic models. The statediagram for the type 	, in the context of the , is given in Figure 2.This is essentially UML nota-tion, though we allow naviga-tion expressions labelling thetransitions. For example thediagram indicates that whenthe action  is per-formed on the object identifiedthrough  with as the copy argument, then,provided  is in the state, the effect willbe to move it into the state.The constraints on the staticmodel imposed by a state dia-gram are the introduction ofnew states and the relationships between them. In particular, states at the same nestinglevel are disjoint, so an object can only be in one state at a time.The constraints on the dynamic model are on the transitions: for example, Figure 2says that when a  action is performed on the library, the copy involved is ,and that copy is in the  state, then the effect will be to put that copy in the state. This may be expressed, if desired, as a pre/post specification fragment for theaction  (see Kent 1997).2.3 InvariantsDiagrams currently in use in OO modelling, can not express all required static con-straints. This is demonstrated in (Kent 1997). For example, in the library system wewould like to say that a copy on hold is only available for lending to the user whoreserved it, whereas a copy on the shelf is available to all users who are registered andactive. Such constraints can not be expressed diagrammatically in UML, and someform of textual annotation is required. (Kent 1997) shows how this and other con-straints may be written using the mathematical language of Catalysis.2.4 Action SpecificationsSimilarly, diagrams in UML can not express all constraints on dynamic behaviour. Forexample, in the case of , the state diagram of Figure 2 does not say that a new,loan object must be created recording the fact that the copy has been loaned out to theFigure 2: State Diagram for 				∈ 		user. Again such constraints have to be written using a textual notation. In Catalysisthey are expressed precisely as pre/post conditions or contracts written in the mathe-matical language.3 Constraint Diagrams and Contract BoxesConstraint diagrams (Kent 1997) are a diagrammatic notation for expressing staticconstraints on models. They build upon the effectiveness of snapshots in illustratingthe import of constraints on a model. They may be viewed as a generalization of snap-shot notation (i.e. UML object diagrams) – one constraint diagram represents a set ofsnapshots, which is more expressive than type diagrams. They make use of Venn dia-gram notation, with some extensions, to show relationships between the values of nav-igation expressions. They also show types and states as the sets of objects of that typeor in that state, respectively.Figure 3 is a constraint diagram for the invariant stated in Section 2.3 on page 3. Read-ing the diagram starting from the object , part of that invariant is read off as follows:for all libraries , and for all copies  in the collection of  that are on hold,  is avail-able for lending to the (single) user associated with the reservation that  is on hold for.The state diagram of Figure 2 with transitions removed is also a constraint diagram,showing the relationships of sets of objects in different states:  and  aredisjoint, so an object can’t be in both states at the same time; they are contained in, so if an object is  or  it must be accessible.Contract boxes (Gil and Kent 1997) are a diagrammatic notation for showing dynamicconstraints, that would otherwise be expressed textually using pre/post conditions(contracts). A contract box is shown in Figure 4. It is a pair of constraint diagramslinked by object lifelines. The constraint diagrams show constraints on the objectsinvolved in or affected by the action associated with the box (in this case ). Thetop diagram is a general characterisation of the pre-state, and the bottom of the post-state. The lifelines are a visual aid to identifying how specific objects are affected byFigure 3: Constraint Diagram				the action. For example, in Figure 4 a lifeline makes it clear that the copy object ismoved from being available to out.4 Pictorial SemanticsIt appears that constraint diagrams and contract boxes can be used to express most, ifnot all, static and dynamic constraints that can be expressed with invariants and con-tracts. This includes constraints imposed by type diagrams – cardinality constraints arejust a particular form of invariant; and constraints imposed by state diagrams, whichcontribute to the type model (dynamic types) and action contracts.Thus using one notation – constraint diagrams and contract boxes (which are just pairsof constraint diagrams), it is possible to express a model with a rich set of constraints,that otherwise requires a range of different diagrams and textual annotations in othernotations. This suggests that constraint diagrams and contract boxes could be used togive a semantics to the other notations. This could help to make the semantics easier tounderstand, and provide an alternative approach to tool support for semantic checking,through the direct comparison of diagrams (see Kent, 1997 and Gil and Kent, 1997, formore specific ideas). The semantics could be formalised by grounding the semantics ofFigure 4: Contract Box											constraint diagrams and contract boxes in a formal language such as Larch (Guttag &Horning 1993), adopting an approach similar to (Hamie & Howse, 1997).In terms of the meta-model semantics currently proposed for UML, a model of (theabstract syntax of) our notations would have to be built, with well-formedness rules (asinvariants or operations) to describe the mapping of all the UML diagrams (whoseabstract syntax is also encoded as OO models) into this model. Then, when the state ofthe meta-model was instantiated with a particular system model, all parts concernedwith UML diagrams could be stripped away and no information would be lost.Contract boxes are just one part of a series of 3D notations currently under develop-ment (Gil & Kent 1997). Not only can these notations be used in their own right formodelling, it emerges that they can also be regarded as a visualisation of a singleunderlying semantic model, of which 2D notations such as sequence, collaboration andactivity diagrams are just projections. An important result of this work is the identifica-tion of other projections (some 3D, some 2D) which are more precise and richer thancurrent notations, but just as simple and intuitive. Indeed, it may be that this workresults in a general improvement to existing 2D notations, which was one of the rea-sons stated in the Introduction for doing semantics work.Much work remains to be done. The details need to be worked out for the mappingsbetween our notation and standard 2D notations such as UML. The precise semanticsof the former also need to be worked out, to ensure the integrity of the notation and toexplore its expressiveness, as well as help with provision of tool support. Tools envis-aged include assistance with: 3D visualisation; derivation of 2D and 3D projections;generation of the complete 3D model from projections; use of the complete model toperform integrity checks on the projections; and checking the integrity of the completemodel itself.ReferencesCook S. and Daniels J. (1994) Designing Object Systems, Prentice Hall Object-Ori-ented Series.D’Souza D. and Wills A. (1997) Component-Based Development Using Catalysis,book submitted for publication, manuscript available at http://www.iconcomp.com.Gil Y. and Kent S. (1997) Three Dimensional Models, submitted to ICSE98, availableat http://www.biro.brighton.ac.uk/biro/index.htmlGuttag J. and Horning J. (1993) Larch: Languages and Tools for Formal Specifica-tions, Springer-Verlag.Hamie A. and Howse J. (1997) Interpreting Syntropy in Larch, Technical ReportITCM97/C1, University of Brighton, available at http://www.biro.brighton.ac.uk/biro/index.html.Kent S. (1997) Constraint Diagrams: Visualising Assertions in Object-Oriented Mod-els, to appear in Procs. OOPSLA97, ACM Press.UML (1997) Unified Modelling Language v1.0, Rational Software Corporation, avail-able at http://www.rational.com.

Component-Based Development Using Catalysis, book submitted for publication, manuscript available at http://www.iconcomp.com.

Constraint Diagrams: Visualising Assertions in Object-Oriented Models,

Designing Object Systems, Prentice Hall Object-Oriented Series.

Interpreting Syntropy in Larch,

Three Dimensional Models, submitted to ICSE98, available at http://www.biro.brighton.ac.uk/biro/index.html Guttag

Unified Modelling Language v1.0, Rational Software Corporation, available at http://www.rational.com.

http://kar.kent.ac.uk/21446/1/Semantics_through_Pictures.pdf

Semantics through Pictures

Abstract

Similar works

Full text

Available Versions

Crossref

Kent Academic Repository