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
 visibility  (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. Thus, it may not be necessary.

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 exercise: create an XML schema for UML.
--------------
CategoryUml