Coherent
mechanism for dealing with classifier content inheritance
Andy Evans (28/9/00)
From: "Andy Evans" <andye@cs.york.ac.uk>
To: "Tony Clark" <anclark@dcs.kcl.ac.uk>;
Cc: "Suart kent" <S.J.H.Kent@ukc.ac.uk>
Sent: 28 September 2000 10:26 AM
Subject: Coherent mechanism for dealing with classifier content
inheritance
One idea that we had was to make use of an allContents() method
as a coherent mechanism for dealing with classifier content inheritance.
Generally, a Classifier's allContents include those of its parents provided
that they aren't related by generalisation.
context uml.staticCore.model.concepts.Classifier
allContents() : Set(Classifier)
elements->union(parents() -> iterate(parent.contents = Set{} |
contents->union(parent.allContents() -> reject(x |
self.elements -> exists(e | e-isChildOf(x))))
I think this gives us everything we need:
-
it is efficient as allContents is generated on the fly.
-
it applies at all levels: package, class, attribute
-
it supports renaming (to rename, we just make an explicit generalisation
between the contents that are to be renamed. Generalisation is the 'mapping
mechanism' - we don’t need any other notion of content mapping.
-
extension of contents is allowable, e.g. if we define a class X in
package A and an extended class X in package B, then we must define A.X
as a parent of B.X otherwise there will be duplicate contents in B and
the package will not be well-formed. I guess the tool could prompt this.
Alternatively, we could have a constraint which states that it must
always be true that if there exist elements of a parent classifier with
the same name as the elements of a child classifier then they must be related
by generalisation. We can implement this declarative statement in the tool
using @ to create the appropriate slots automatically in the tool.
Andy
next message
back to MMF page