Re: links & messages



Date view Thread view Subject view Author view

Stuart Kent (S.J.H.Kent@ukc.ac.uk)
Thu, 20 Jan 2000 09:47:41 +0000


I broadly support Robert's point of view on this. However I would like to make a distinction between the precise mathematical semantics of a model and the interpretation we give to that model vis a vis the thing in the real world we are trying to model. Thus we can have a mathematical semantics for class diagrams, e.g. based on relations, which tells us, given an object diagram, whether that object diagram satisfies the class diagram or not. However, when conceptual modeling we will interpret a link between two objects as just meaning that they know about each other in some way. At that level we make no distinction between whether the link is calculated or stored, whether it is public or private, and so on. I model networks and services in telecomms, and, in that domain, I interpret object diagrams as bunches of routers, interface cards, cables between routers, etc. When modeling close to the implementation level we may choose to interpret links as indicating that an object has a (probably private) stored reference to another object. This is encoded e.g. by mapping associations to private attributes when mapping the model to an OOPL. Another interpretation, which is much more in the spirit of Eiffel, is to treat associations and attributes as representing accessors, and restricting operations to represent mutators. One can then mark separately which accessors are stored, which are private, public and so on. I personally prefer this approach, as it shifts the emphasis more towards using UML to document interfaces in a visual way which is where I think it is more useful. If you don't take this approach then you lose a visual representation of interfaces - they just become list of operations in a class. (I relaise that this, alternative, interpretation is not the norm and, so that students don't get confused, do not generally teach this approach except on advanced courses where they might grasp the difference.) I don't care whether you like this interpretation or not (well, actually, I care deeply, but I currently haven't the time to enter into a discussion on this topic). My point is that one can come up with a mathematical semantics that suits all levels (at least in this case); the difference between them is how we choose to interpret those models, by which I mean what rules we decide on in mapping those models to a programming language or (in our minds) to situations in the world. It is a difference between giving a precise (denotational) semantics to a language and interpreting one language into, possibly, many others by saying what the translation rules are (and information may be lost or new information added on this translation). And often the target language is implicit, and the translation rules are informal, implicit and down to intuition. If we are saying that the mathematical semantics of UML must be different for different modelling concepts, then we must accept that, although the surface, concrete syntax may look similar, the languages are actually different, and mapping from one level to another requires a translation of language, not just a mapping of a more abstract model into a more concrete one (both models written in the same language). I have been working on the latter and that is hard enough. I believe we should try to keep to the same language for as long as possible, restricting realisation to mappings between models writ in that language. Finally, if we look at the way UML is used (or abused) in practice, the stereotype mechanism has given rise to a horde of different languages. I don't believe this is necessary - it has probably come about because developers have been given too much freedom to play at language design. I think this is unhelpful in the long run - every developer on the planet will have their own hidden, implicit semantics for UML symbols. And this will help their communication? I believe we can be much more ruthless and come up with a common kernel of concepts, with a precise semantics, that will work in a number of different modelling contexts - it boils down to choosing how to connect link and object to the actual thing being modelled, which is (in general) an informal and intuitive connection. Stuart _________________________________________________________________ s.j.h.kent@ukc.ac.uk, http://www.cs.ukc.ac.uk/people/staff/sjhk


Date view Thread view Subject view Author view