[ZODB-Dev] Re: [Zope3-dev] PROPOSAL: ZODB Relationships

[Phillip J. Eby]

At 11:02 PM 5/10/03 -0400, Shane Hathaway wrote:
>This is interesting stuff, but I have a few questions.
>
>On 05/09/2003 06:47 PM, Phillip J. Eby wrote:
>>teacher = AssociationEnd(multiplicity=(1,1))
>>courses = AssociationEnd(multiplicity=(1,None))  # if we use None for 
>>unbounded
>>Teaches = Association(teacher, courses)
>
>The code that stores the links in the association needs a way to find out 
>the name of the association, and this code doesn't provide a way. Nor are 
>the names of the ends provided.  The variable names 'teacher', 'courses', 
>and 'Teaches' are all local and not exposed.

All MOF "model elements", including associations and ends, have "name" and 
"annotation" fields.  I just didn't bother expressing them in the made-up 
example.


>It would be nice to fix that and reduce the verbosity at the same 
>time.  This is a common "one to many" association, and there ought to be a 
>simpler way to express that.

I was being explicit for clarity; not proposing a syntax.  Roche' wanted to 
understand the MOF concept.  I emphasized the parts we were discussing.


>   (A teacher can be assigned to zero courses, so the multiplicity of the 
> "courses" end should allow zero, shouldn't it?  And a course might lack a 
> teacher.)

If there were zero items on either end, there wouldn't be a link, so a 
lower bound of zero isn't really meaningful outside of a "known universe" 
of objects, or for validation at the Reference.  The MOF specs go into this 
a little bit in the "mathematical model of associations" part, IIRC.


>>teaches.add(aTeacher,aCourse)
>>aTeacher = Teaches.teacher.get(aCourse)
>>hisCourses = Teaches.courses.get(theTeacher)
>
>It surprises me that the ends would be available as attributes of the 
>association with attribute names matching the names of the ends.  Is that 
>the way MOF sees it?

Technically, no.  An Association is a "Namespace", like a Package or a 
Class, with its association end considered named contents, so a more 
literal mapping from MOF to Python at the M2 level would be 
Teaches["teacher"] rather than Teaches.teacher.

Again, though, I wasn't proposing syntax; just illustrating an idea.  Note, 
however, that Python on the M1 level uses attributes to access namespace 
contents of packages and classes, so it seemed a natural translation.


>>class Teacher:
>>     courses = Reference(Teaches.course)
>>class Course:
>>     teacher = Reference(Teaches.teacher)
>
>It occurs to me that neither the proposal nor this example provide a way 
>to tell Python the type exposed by the descriptors.  Teacher.courses is a 
>sequence (or perhaps a set) of Courses, while Course.teacher is a 
>Teacher.  Do we infer that from the multiplicity?  Hmm.

That could be made explicit, clearly.


>This is the first time I've heard of MOF.  Who is using it?

Well, anybody who uses UML, actually.  MOF is the OMG's metametamodel for 
the UML.  That is, all of the UML constructs are defined in terms of the 
MOF.  UML contains a very large number of complex constructs; MOF contains 
about 26 (give or take a few depending on the version).

Also, anybody who uses CORBA, because MOF is a metamodel for CORBA 
interfaces as well.

Oh yes, and anybody who uses modelling tools (such as UML drawing programs) 
that use the XMI format, because the XMI format is defined in terms of the 
MOF.  Such UML tools include Argo, Poseidon, MagicDraw, the NovoSoft UML 
toolkit and Novosoft Metadata Framework, the Eclipse Modelling Framework, 
and the System Modeling Workbench (SMW, a Python application).


>   What problems does it solve better than UML?

It's smaller and leaves out lots of things.  For example, it does not 
support N-way associations, or association attributes.  If we were 
discussing all the options that UML provides for associations, this would 
be an even more confusing discussion.  :)



>   UML is much more familiar to developers.  When you suggested 
> "association", I opened the UML book I have on my desk and found all the 
> terms I've been looking for.

Yep.  That's because UML and MOF are both standards published by the OMG, 
and they (understandably) want all their standards aligned.  Thus, it's 
easy to draw a UML diagram of the entire MOF model, or to model UML itself 
using the MOF.  MOF is the basis for all the OMG-specified modelling 
languages such as UML, CWM, SPEM, etc.


>We left out metadata from the proposal so we could get the proposal out 
>there.  Roche and I were hoping to put metadata into a future version of 
>the proposal.  However, MOF seems to deny the possibility of attaching 
>metadata to individual links.

Individual links?  If you do in fact mean *links*, then you are correct.


>   There are no association classes and only binary associations are allowed.

Right.


>   Maybe I misunderstood MOF, or maybe link metadata isn't important.

If it's attached to an individual link, then by definition it's not 
metadata, it's data - the M0 level.  (OMG specs, including UML, have a 
standard way of referring to various metalevels: M0 is "information", M1 
layer is "model", M2 is "metamodel", M3 is "metametamodel" and so on.)

It sounds, however, like I misunderstood your requirements.  The proposal 
looked like it was pointed at simple symmetric binary associations with no 
link attributes.  Thus, it seemed to me as though the desired functionality 
was in fact a small subset of the metamodel defined by the MOF, so I 
suggested it as a basis for terminology.  That's all.

As I've said repeatedly, I'm not advocating that we "use the MOF" in some 
way.  That would be as meaningless as saying we should "use UML" to do 
this.  I'm just suggesting that a lot of work has gone into the MOF specs 
to create a precise model, and it's one that will be easier to read and 
fully understand than the *far* more complex UML specifications.  After 
considerable study, I am at least under the illusion that I have a 
reasonable grasp of MOF.

By contrast, I am under no such illusion that I "understand" the UML 
specification, in the sense of being able to say what a UML diagram should 
translate to in code (viewed from a formal perspective).

However, if your requirements call for a richer association model, sure, go 
for it.  My inclination, though, is to consider N-ary associations and link 
attributes to be YAGNIs.  I rarely run into an N-ary association (or 
many-to-many association, for that matter) that isn't just as cleanly 
expressed as a set of binary associations.