RE: [wg@2uworks.org] Re: Book



Date view Thread view Subject view Author view Attachment view

From: Stuart Kent (stuart@mclellankent.com)
Date: Tue 10 Sep 2002 - 09:56:58 BST


At 09:23 10/09/2002 +0100, Moore, Alan wrote:
>I'm confused by your response Stuart:
>- you say objects and links may be declared in the model - is the semantic
>domain the metamodel for that model?
>- you say defining some constants - constant whats - classes, objects ...
>- you say must be in the start state of any trace - does that mean for the
>whole model, whatever model means.

Sorry, to explain this properly needs a paper with examples, which I 
haven't the time to write at the moment.

>I had thought (perhaps naively) that an object diagram would be a concrete
>syntax that mapped to instances of elements in the Semantic Domain, instead
>of the Abstract Syntax - but I can't work out whether that's what you're
>saying or not.

Yes, this is one use of object diagrams, and my message was not intended to 
preclude this use. The USE tool from Bremen 
(http://www.db.informatik.uni-bremen.de/projects/USE/) uses object diagrams 
(and, indeed, sequence diagrams to picture traces) in this way. However, 
the same notation (or very nearly the same notation - one has to be careful 
about how one labels things), can be used to specify prototypical examples 
that every denotation of the model in the semantic domain must conform to.

A constant will have a type, like parameters and attributes, which can be a 
class, for example. For model, I mean something expressed using the 
(abstract) syntax of the language in question (in this case UML).

The main point of my message was that the same, or very similar, 
diagrammatic notation can be interpreted in a number of different ways. 
This is particularly true of notations which refer to types of things (e.g. 
have labels like x:T). Such diagrams can be used to illustrate a particular 
example or instance of the model (an element of the semantics domain) or to 
specify a prototypical example, to which all instances should conform. In 
the latter case, one then has the choice of whether you interpret 'x:T' as 
'for all x:T', 'exists x:T', 'constant x:T', or, in some object diagrams 
you might just label an object ':T' and it may be linked from another 
object 'y:S' with label s, so the object ':T' might actually be 
representing the navigation expression 'y.s'. I am not saying we should 
have all these uses, I am just saying that these interpretations of such 
syntax are all possible, and we have to decide which ones we want and 
whether we want to supplement the notation with additional markings to make 
it clear which use the diagram is being put to.

If you're interested, I have a research project at the University, where we 
are looking to see how we can express constraints using a mixture of 
diagrammatic and textual notations. For example, we are embedding object 
diagrams in OCL, where we use OCL to introduce quantified variables and the 
like, and then use object diagrams with objects labelled with the name of 
the variables, so show how objects referred to by the variables should be 
configured. We are also using a diagrammatic notation inspired by Venn 
Diagrams which allows us to specify configurations when sets of objects are 
involved. I can send you a paper which goes through this in some detail.

Stuart


>Alan.
>
> > -----Original Message-----
> > From: Stuart Kent [mailto:stuart@mclellankent.com]
> > Sent: 09 September 2002 23:55
> > To: Joaquin Miller; wg@2uworks.org; discussion@2uworks.org;
> > puml-list@cs.york.ac.uk
> > Subject: [wg@2uworks.org] Re: Book
> >
> >
> > Joaquin
> >
> > 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: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".
> > >
> >
> > _______________________________________________
> > wg mailing list
> > wg@2uworks.org
> > https://2uworks.org/mailman/listinfo/wg
> >

Date view Thread view Subject view Author view Attachment view