[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [mdt-sbvr.dev] Class diagrams of metamodel -- INTERPRETINGCLASSDIAGRAMS of the SBVR XMI FILE
|
Dave,
Note that many would (and have) disagree(d) with the approach we took to
using the OMG's metamodel for the UML2 API and native serialization
format... Hindsight is 20/20. ;)
Cheers,
Kenn Hussey
Program Manager, EA/Studio
[Embarcadero Technologies Logo]
Embarcadero Technologies, Inc. | www.embarcadero.com
110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4
Kenn.Hussey@xxxxxxxxxxxxxxx
Mobile: 613-301-9105
-----Original Message-----
From: mdt-sbvr.dev-bounces@xxxxxxxxxxx
[mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx] On Behalf Of Dave Carlson
Sent: Thursday, April 24, 2008 10:13 AM
To: 'SBVR developer list'
Subject: RE: [mdt-sbvr.dev] Class diagrams of metamodel --
INTERPRETINGCLASSDIAGRAMS of the SBVR XMI FILE
This underscores Mark's assertion that we should design a separate
metamodel
for use in the tooling, and interpret the CMOF models delivered by the
specification as a definition of XMI serialization for SBVR. This is
different from the UML specification where the MOF metamodel is also the
basis for tool design and code generation.
>
> INTERPRETING CLASS DIAGRAMS of the SBVR XMI FILE
>
> To understand any SBVR Metamodel class diagrams generated
> from the SBVR XMI as SBVR 1.0 specifies them, they must be
> interpreted using what is in effect a UML PROFILE for SBVR
> 1.0 as found in Clause 13.2 of the SBVR 1.0 specification.
>
> Class diagrams generated from the SBVR XMI are NOT UML
> DIAGRAMS with UML semantics. They are UML notations with an
> SBVR semantics.
>
> I have attached a summary of Clause 13 with footnote
> references to the SBVR 1.0 specification.
>
> Donald
_______________________________________________
mdt-sbvr.dev mailing list
mdt-sbvr.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev
