Re: [] Book

Date view Thread view Subject view Author view Attachment view

From: Stuart Kent (
Date: Mon 09 Sep 2002 - 19:35:52 BST


At 11:05 09/09/2002 -0700, Joaquin Miller wrote:

>>The key point about that discussion is that one must be able to look at 
>>an element of the semantics domain (which will be described in some 
>>language) and point to something in the real world and say "this element 
>>corresponds to that thing". Let me give a small example. It is hard to 
>>point to a thing in the world that corresponds to the class "Book". 
>>However, you can point to things (i.e. particular books) that correspond 
>>to objects (elements of the semantics domain) in a denotation of the 
>>class "Book"
>Thank you Stuart.  This is the first time i have seen any motivation 
>offered for excluding objects from the modeling language or excluding 
>classes from the semantics domain, or splitting UML into two parts, or 
>whatever it is that 2U is up to.  (My choice of words just indicates that 
>i don't grok it yet.)

>It is certainly true that there is nothing to point to, which is the (oh, 
>oh!  here goes:) denotation of 'book.'    This is the cause of much 
>trouble, and if 2U has found a way to avoid the trouble, that's great.

I sense doubt in your "tone". There is also a very pragmatic reason for our 

When I build models with most current UML tools I don't get to exercise the 
model until I get to writing code that implements it. When I write code I 
set up tests, with test data, that allow me to generate sample traces that 
I can then examine - either through a debugger, or by what my program 
reveals about its execution traces through the UI, what it writes to log 
files or standard output, and so on.

I would like to be able to exercise a model before it reaches the code 
stage and view it's traces "through the eyes" of the model. The semantics 
domain essentially defines the space of traces for a UML model. An instance 
of the semantics domain represents a trace of a particular model. The 
mapping from abstract syntax to semantics domain (the semantics) gives the 
rules for determining whether a trace is valid for a particular model. If I 
use a subset of UML which is executable, then this mapping will give the 
rules for calculating a trace from a starting state and with subsequent 
input of external events. So implementing the semantics domain metamodel 
and the semantics mapping metamodel will, at worst, provide a tool that 
allows one to set up traces manually and check whether or not they satisfy 
the model, and at best will give you a tool that directly interprets a 
model, if it is executable. In practice, one will probably get something 
in-between. Traces may be partially generated with some decisions made by 
the modeller. One can also imagine running the mapping backwards, and 
learning a model from a set of traces (e.g. when business modelling, you 
model the examples first, as it is often easier to talk examples to get an 
understanding of the more general concepts). Now imagine an MDA scenario 
where model maps to code, and then traces of executing code map to traces 
"through the eyes" of the model. By monitoring implementation traces, one 
could use the latter mapping to provide you with a "dashboard" application 
to view executing systems through the eyes of the business model, for 
example. And so on.

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).

>It is, though, pretty easy to convey to one's interlocutor what is meant 
>by 'book.'
>(Though, like all words, there will be what some call variants or 
>extensions around the central cluster.  Last week at the Berkeley art 
>museum i saw a book made from two cigarette packs, with illustrations 
>drawn on the white sides, opened flat, trimmed, and then folded together 
>and hand sewn.  And that is pretty close, compared to the various meanings 
>of 'book' in accounting, card games,  criminal prosecution, and bookmaking 
>(the other meaning of 'bookmaking'); card games being the outlier here.)
>wg mailing list

Date view Thread view Subject view Author view Attachment view