Re: Book

Date view Thread view Subject view Author view Attachment view

From: Stuart Kent (
Date: Mon 09 Sep 2002 - 23:55:04 BST


At 15:15 09/09/2002 -0700, Joaquin Miller wrote:
>I like the approach of having a formal semantics, and of having an 
>executable model.  I've been a supporter since i first heard of the work 
>years ago.  I even praise it publicly.  And i am a supporter of having 
>instance diagrams to figure out what the class diagrams might mean or 
>could not possibly mean or are may not be making sense about.  I second 
>the requests for them that are made on the Harmony MOF calls.

Thanks for the support.

>What i don't grok is:
>1.   why i can't have objects and links in my model.
>2.  if i do, what their image in the semantics domain is.

These are two good questions. Only time for short answers:

In answer to 1, I think you should be allowed to, and what you are saying 
(in answer to 2) is that any object configuration in the semantic domain 
must include the objects and links declared in your model. One way of 
viewing this is that by drawing object diagrams as part of your model, you 
are defining some constants, and the semantics interpretation of constants, 
is that they must map to values in the semantics domain which are there in 
the start state (of any trace) and remain constant in any development of 
the trace from that start state. Or, if you prefer, view them as 
existentially quantified variables: in any object configuration, of any 
trace, there must exist objects for to which the variables can evaluate, 
which also means that the requisite links must be exist between the objects.

But please note that there can be other interpretations of object diagrams 
"as part of the model". For example, one is where you don't interpret the 
objects as constants but as universally quantified variables (or more 
accurately some objects may be interpreted as universally quantified 
variables, and some as values of navigation paths from the former objects). 
For example, I might interpret the object diagram:

c link to l by role "library"
c link to p by role "publication"
p link to l by role "library"

By making c a universally quantified variable, and the other objects values 
of navigation expressions from c, giving rise to the constraint:
for all c:Copy, c.library = c.publication.library

There was a paper in UML'01 interpreting object (collaboration) diagrams in 
this way. I have also written some stuff on this.

Sequence/collaboration diagrams can be used in a similar way. They can be 
used as a notation for expressing particular elements of the semantic 
domain - particular traces, or they can be used to in a "universally 
quantified" sense to say e.g. that all invocations of a method on objects 
of this type must cause the following sequence of method calls to be made.

>(of course, maybe 1 is wrong and 2 is answered.  but you guys know i have 
>been asking about this right since the initial 2U submission.)
>My motivation for 1 is the practical necessity for a software architect to 
>     in the model,
>the configuration of the system.
>My motivation for 2 is first of all philosophical curiosity.  But 
>curiosity driven by the desire to eventually be able to simulate the 
>system i have specified.
>>And Jos Warmer has found building such tools from a semantic domain model
>>(as is presented in the OCL 2.0 model) very straightforward.
>> > So you see our motivation is not philosophical, but practical. It so
>> > happens that taking the trouble to define semantics in this way also means
>> > that we have a means of discussing subtle aspects of the meaning of the
>> > language, that tend to lead to lots of confusion and misunderstanding if
>> > not pinned down and explicitly modelled (viz. all the recent 
>> discussions on
>> > U2P definition of association and association generalization).
>To remove yourself from this list please mail
>with a message containing the word "unsubscribe".

Date view Thread view Subject view Author view Attachment view