Re: MML Questions



Date view Thread view Subject view Author view

Andy Evans (andye@cs.york.ac.uk)
Wed, 20 Dec 2000 13:17:01 -0000


Kerry, Thanks for your comments. I'll deal with the container issue first, because it is the most fundamental. As you say, the core package is the most critical to understand. This is because it we intended it to provided a *framework* within which all elements of the MML are plugged. When viewed in this way, we began to realise that there are certain "patterns" of relationships and constraints that are applicable to many of the concepts in a language. Many of these patterns are based on the idea of containment, although I am not convinced that this is the right word for it (hence Tony Simons possible confusion). What we tried to capture in the document are two general patterns to do with generalisation and instantiation. In both cases, we noticed that there is a "structure preserving relationship" between (a) generalisable elements and (b) instances and their classifiers based on their contents. For generalisable elements, this relationship seemed to say that the contents of a parent classifier are inherited by its children. For example, if a class contains attributes and methods, then so will its children, and the elements of the child will be have elements of the parent class as their parents. However, we now realise that this is just structural conformance (inheritance), and although useful, it is not really powerful enough for capturing all situations. What is really need is semantic conformance, i.e. all the instances of the child classifier must conform to instances of the parent classifier. Inheritance is an implementation oriented mechanism that satisfied this general constraint. Another point to note is that we use the classifier instance representation to assign a denotational meaning to concepts in MML. Some people have found this a little confusing as the UML 1.3 has a different view of an instance (but this can be resolved by a simple change of name). In the case of instantiation, there is a pattern which states that for all the contents of an instance of a classifier, each element must be an instance of the contents of the classifier. Thus, instances must be structurally conformant to their classifiers. For example, objects conform to their classes, because a class contains attributes, therefore, its instances (objects) contain slots that are instances of the attributes of the class. Furthermore, an attribute also contains its type, and a slot contains it values, and the values are instances of the type, and so on recursively. The nice thing about this pattern is that it gives a lot of guidance on how to structure the semantics of a particular language concept, whether it be a class, a package, or even a state machine. Since we wrote the paper, we have tried to pull out these patterns into separate packages which can be inherited using a Catalysis like import mechanim. If you are interested, there is a draft paper available at: http://www.puml.org/patterns.ps . Some of the issues you mention have been resolved here. At the end of the day, we want to make the task of building large meta-models a more structured, and incremental process, rather than ad-hoc guesswork, hence the patterns work. I'm also sure that the structure preserving patterns are probably well known in the theoretical arena, for example category theory has a notion of structure preserving maps between categories and their semantic domains. However, it would be really nice if a mathematician could provide feedback to confirm this. I'm also sure that once we get into UML 2.0, many more of these patterns will be identified. I've answered your specific questions below, but note that the work in the paper will probably replace much of the current core package: Best wishes, Andy ----- Original Message ----- From: "Kerry Raymond" <kerry@dstc.edu.au> To: <puml-list@cs.york.ac.uk> Sent: Wednesday, December 20, 2000 7:25 AM Subject: MML Questions > I'm reading "A Feasibility Study of Rearchitecting UML ..." and got stuck reading Section 4.2.1 (Core model concepts). Since I > assume it is fairly important to understand this section correctly, can someone please explain some of the well-formedness rules on > page 36: > > [3] The parents of a generalisable elements must be of the same type. > > I assume "type" here means "meta-type" as opposed to "type" as in "An Attribute has a type which is a Classifier" as shown in Fig 8? > > Also, I assume that "same" means same as the child (as the OCL suggests) and not same as the other parents? > > However, this rule seems very strong in that the type of the child cannot be a subtype (child) of the type of the parent? Looking at > 4.7.4, it seems that there is the concept of being of the same "kind". On the surface, requiring the child to be of the same kind as > the parent (or the type of the child "conformsTo" the type of the parent) would seem less restrictive. Is there some reason why the > stronger rule is used? Yes.. this could be weakened. > > [4] A generalisable element must conform to its parents. > > Not being an OCL expert, I'm not sure if I should read this rule as "if you conform, then you must be a child" or "if you are a > child, then you must conform" or both. The English version suggests the latter. > > If specific sub-classes can define their own conformsTo function, then presumably a grandchild can conform to its parent and its > parent conform to the grandparent, yet the grandchild does not conform to thegrandparent? Or is there some rule that forces all > conformsTo functions to minimally require the conformance given on page 38? > > Is this the intention or does this rule need to be applied recursively? > We intended conformance to be transitive. > [5] The elements of a class contain its attributes. > [6] The elements of an attribute contain its type. > > Looking at Fig 8, I see two associations with association ends called "elements" (Container to ModelElement, and Classifier to > Generalisable). Are these two separate containment relationships or is the one between Classifier and Generalisable intended as a > special case of the one betwen Container and ModelElement? If the latter, should this be understood as Classifiers can contain only > Generalisable? > It is intended as a specialisation of the contains relationship between classifier and classifier, thus a classifier may only contain generalisable elements. > In the absence of any rules prohibiting it, can such containments be circular? For example, a class X contains its attibutes which > contain their type(which is class X)? Similarly, can one ModelElement be contained within many Containers? > Yes, it can be circular, but this is necessary in some cases and must be ruled out in others. This I think raises the problem of the word container, which in general should not permit circularity. > As I undderstand [5] and [6], a class does not directly contain its attributes, but rather there is an intervening Set. Similarly for > attribute contains its type. However, in the example in Fig 26, the dog class appears to directly contain its breed attribute, and > the breed attribute appears to directly contain the type String. If the dog class had had a second string-valued attribute "colour", > would the type String have been shared between the two attributes or would there have been two separate types, each called String? > > Again, it may be my lack of OCL expertise, but the OCL of Rule 5 appears to be defining a Class's attributes in terms of > "allAttributes" which is in turn defined as being the union of attributes of a Class and its parents. This seems to be a circular > definition. > This is resolved in the new paper. > Thanks in advance for any insight anyone can shed. > Thanks for your comments. > Kerry > > =========================================================================== > Dr Kerry Raymond, Distinguished Research Fellow kerry@dstc.edu.au > CRC for Enterprise Distributed Systems Technology Ph: +61 7 3365 4310 > University of Queensland 4072 Australia Fax: +61 7 3365 4311 > ===================================================== www.dstc.edu.au/kerry > > > > > > To remove yourself from this list please mail puml-list-request@cs.york.ac.uk > with a message containing the word "unsubscribe". > >


Date view Thread view Subject view Author view