Re: links & messages, and another puzzle



Date view Thread view Subject view Author view

Daniel Jackson (dnj@lcs.mit.edu)
Thu, 20 Jan 2000 22:00:23 -0800


stuart is right on the mark here. you have to distinguish the mathematical semantics of the notation from the "phenomenological" interpretation of the mathematical model. formal methods people often, unfortunately ignore this. for requirements this can be a disaster: you can end up with a spec that is completely formal but in a sense has no meaning. (this issue is discussed in detail, btw, in my father's book: Software Requirements and Specifications, Michael Jackson, Addison Wesley, 1995). one quibble though. in a conceptual model, a link doesn't mean the two objects "know about each other". it simply means that there is a property that holds for the pair. for example, in describing access control, i might have a set Privilege, and a relation dominates : Privilege -> Privelege where dominates relates privelege p1 to privelege p2 if having p1 is at least as good as having p2. just because ReadWrite dominates Read doesn't mean that one privilege "knows about" the other. here's a related question that's bothered me. we built a stock tracking program in which we specified a relation dollar : StockAmount -> Dollar that relates a stock amount (an abstract value associated with a stock, and in the US usually incremented in 1/64 of a dollar) to a dollar amount. is this relation fundamentally different from any other? it's tempting to say that it's a computable "function", or that it's just an issue of representation, but these distinctions don't stand much scrutiny. /daniel ----- Original Message ----- From: Stuart Kent <S.J.H.Kent@ukc.ac.uk> To: robert france <france@bach.cs.colostate.edu> Cc: <puml-list@cs.york.ac.uk> Sent: Thursday, January 20, 2000 1:47 AM Subject: Re: links & messages > 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 > > > > To remove yourself from this list please mail puml-list-request@cs.york.ac.uk > with a message containing the word "unsubscribe". >


Date view Thread view Subject view Author view