Re: UML metamodel

Here is something I helped put on C2 that may be of help:

A draft relational schema for UML class diagrams.

Box
----
boxID (pk)
boxType (C=class, P=package, I=Interface, etc...)
boxTitle
isAbstract (if title is to be in italics)
titleSideNote
stereoRef
bottomNote
boxConstraint
elidedFormat (blank=none, T=title-only, E=elipses, C=circle)

AttribMethods
----------
amName (attribute or method name)
amType (A=attribute, M=method, blank=unspecified)
boxRef (fk to Box table)
pathName (Example: "Appliance::")
declaration (Example: constructor or initializer string)
amReturnTypeInfo (Example: "Integer" - goes to the right)
stereoRef (fk to StereoTypes table)
amAttachedNote
visability (Example: "#" for "private")
amConstraint
isClassScope (underlined)
[PK: amName + boxRef]

Links
-----
linkID (pk, possible auto-gen, see note)
fromBoxRef (fk to "from" box)
toBoxRef (fk to "to" box)
linkType (Inheritance, Aggregation...)
linkDescript (example: "has")
fromQntyRef (fk to Quantities)
toQntyRef
fromDescript
toDescript
linkFromNote (note on the "from" side of line)
linkMidNote (note for the middle of line)
linkToNote
qualifierDescript
constraintDescript
[pk needs study, may be many links between 2 boxes]

linkRelations
-------------
fromLinkRef
toLinkRef
lrType (C = constraint)
lrDescript (example: "Or")

Associations [Not sure yet if we need this. See note]
------------
linkRef
boxRef
assocNote
[pk: linkRef + boxRef]

stereoTypes
-----------
stereoID (pk)
stereoDescript

Quantities
----------
qntyID (pk)
qntyDescript [redundant?]
rangeType (N=number range, M=many, NM=number-to-many, L=list)
lowQnty (if applicable)
hiQnty (if applicable)
qntyList (if applic., if too complex for a range)


Notes

I rolled attributes and methods into one entity because they are so
similar. Some may disagree with this decision. Note that in some
languages the distinction can be blurry, at least externally. Plus, one
might want to change it back and forth during design time when things
are not settled yet. Thus, entities are purposely "wide" in this
design. One only has to change the "type" instead of move info from one
entity to another, and risk losing attributes along the way when
attributes are not relevant for a particular "type".

Generally we should avoid coding view-specific info, but it may not be
fully avoidable. Perhaps treat render requests as a preference or
default rather than hard attributes. A renderer or browser should
ideally be able to zoom in and zoom out, collapse large boxes into more
compact forms, etc. But defaults might be helpful if one is using only
a static renderer.

To make a single digit for Quantities, use the same start and end
value. The display engine should automatically consolidate them.

The "Associations" table is an attempt to handle cases where
associations are between one "link" and one "box". The examples I have
seen may just have been visual shortcuts, in which case such
associations are really just a regular link between two boxes.

In some cases I have shown one or two letter abbreviations for certain
codes. Maybe a fuller name is more appropriate. However, it is assumed
that users don't edit many of these columns directly, and thus
pull-down lists can be supplied to select the proper abbreviations
internally.

Reader excercise: create an XML schema for UML.

-T-

.