RE: [mdt-sbvr.dev] SBVR-uml designation.gif

[Mark H Linehan <mlinehan@xxxxxxxxxx>]

My prototype tool focussed on the rules & semantic formulation side of
SBVR, and (so far) has implemented very little of the vocabulary side.  So
I didn't have to deal with the meaning/representation/expression concepts.
However, I did deal with texts as one kind of bindable target.  For that, I
maintained a "literal pool" of texts, similar to what any compiler or
interpreter would implement.   This approach is basically the same as
advocated by Stan.  The texts are owned by the pool, which itself is owned
by what I called a "project" but would be better understood as being owned
by a fact model.  Each unique text appears just once in the literal pool,
and any unused texts are deleted when I save the in-memory EMF model to a
file.
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research

phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxx

mdt-sbvr.dev-bounces@xxxxxxxxxxx wrote on 04/23/2008 10:59:53 PM:

> I didn't realized that's what was intended by the dashed line in Figure
8.4.
> So if Representation is an association class, then its subclasses
> (Designation, Definition, FactTypeForm, etc) are also association
classes.
> It seems very odd to me for Definition to be an association class.  I'll
> need to think about that one...
>
> This would imply that Expression really must be a first class independent
> object in the model, and a Designation is an association between a
concept
> and an expression.  A Defintion is also an association between an
expression
> and a concept.
>
> Mark, in your prototype tool, how did you handle creation and management
of
> independent expression (text) objects?
>
> Dave
>
> >
> > I agree with Stan's observation on April 12 that an SBVR
> > "representation" is an association class,  I believe it
> > doesn't show up that way in the CMOF file because CMOF
> > doesn't support association classes.  But Figure 8.4 in the
> > SBVR specification makes it quite clear that "representation"
> > is an association class.
> >
> > Since EMF doesn't support association classes, we are still
> > left with modeling "representation" as a class in EMF.
> > Semantically, it is quite clear that a representation owns
> > neither the corresponding meaning nor the corresponding expression.
>
>
> _______________________________________________
> mdt-sbvr.dev mailing list
> mdt-sbvr.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev