Re: Book



Date view Thread view Subject view Author view Attachment view

From: Joaquin Miller (miller@joaquin.net)
Date: Tue 10 Sep 2002 - 00:14:30 BST


Thanks, Stuart.  This all sounds good.  Can you get it in your current 
Infrastructure submission and slip it in under the deadline?

As you know, 3C UML 2 includes the quantifiers, so we can say the different 
things you discuss below.

There is a third use for objects in a model, and that is as examples, which 
illustrate how things might work, but do not prescribe either that they 
must, or that they ever will.  (This use is intended to show a typical 
course, but is not prescriptive: for example, it will use data that may 
never appear in the system.)

The three roughly correspond to these on a blueprint:

There shall be a door here, this wide.  (constant)
This is the typical joist to wall connection.  (universal (though there may 
be exceptions to "typical."))
The areas of random laid stone shall look more or less like this.  (example)

...

As for collaborations, we feel they are better understood in terms of roles.

>Joaquin
>
>>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:Copy
>l:Library
>p:Publication
>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 specify,
>>     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 puml-list-request@cs.york.ac.uk
>>with a message containing the word "unsubscribe".
>
>
>
>
>To remove yourself from this list please mail puml-list-request@cs.york.ac.uk
>with a message containing the word "unsubscribe".
>


PGP Fingerprint:
CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3

Date view Thread view Subject view Author view Attachment view