Hi Mitch

I was thinking we would use:

Class1 = <role1:1..3> Class2.
Class2 = <role2:0..*> Class1.

to express

assoc1 : Association (Class1, role1, 0..*, 1..3, role2, Class2)

The disadvantage is that we cannot mention the association name
(I wouldn't use it anyway) and I have to duplicate the
class names.

My hidden agenda is to have a notation which can express the essence
of UML class diagrams and which is EBNF like so that we can define
a grammar. We want to continue to use the Structure-shy Object pattern
with UML.

I think the simple extension I proposed is more EBNF like than
your association syntax.

-- Karl
--------------

From wand@ccs.neu.edu Tue Feb 11 12:10:37 1997
From: Mitchell Wand <wand@ccs.neu.edu>
To: Karl Lieberherr <lieber@ccs.neu.edu>
Subject: Re: UML notation and class dictionaries

>>>>> On Tue, 11 Feb 1997 11:36:27 -0500 (EST), Karl Lieberherr <lieber@ccs.neu.edu> said:

KL> To have a convenient notation to express UML diagrams textually,
KL> we extend the class dictionary notation as follows:

KL> An edge label may have an optional cardinality constraint part:
KL> The following are examples of legal edge labels:

KL> <l>
KL> <l:1>    	// same as <l>
KL> <l:0..*>
KL> <l:1..3>
KL> <l:1..*>

KL> The presence of those cardinality constraints allows us to express
KL> collections at a higher level of abstraction.

KL> Constraints = <l:0..*> Constraint.

This presupposes a navigability property: That the intent is that edge L (I'll
capitalize L for readability) lets you navigate from Constraints to
Constraint, but not necessarily vice-versa.

By contrast, associations in UML are bidirectional:  you can navigate them in
either direction (and often by different names, called "roles"), unless you
specify otherwise.

Mathematically, associations in UML are relations, whereas edges in this
proposal are multi-valued functions.

Also, UML allows you to specify cardinality constraints on both ends of an
association.  Here's another idea that incorporates more of the UML
functionality: 

assoc1 : Association (class1, role1, 0..*, 1..3, role2, class2)

This declares assoc1 to be an association navigable in both directions.  For
every object o1 of class class1, o1.role1 is a set of between 1 and 3 objects
of class2.  For every object o2 of class class2, o2.role2 is a set of any
number of objects of class class1.

class1 and class2 are required arguments; all others can be optional.  The
only semantic ambiguity would be for the case

Association (class1,role,constraint,class2)

which I'd think should default to

Association (class1, role, 0..*, constraint,class2)

meaning that this association is navigable in the forward direction under the
name "role", and that o.role yields a set of class2-objects satisfying
"constraint"; and symmetrically for 

Association (class1,constraint,role,class2). 

--Mitch