RE: Namespace.contents



Date view Thread view Subject view Author view

Waldin, Earl (Waldin@paranor.ch)
Mon, 11 Feb 2002 11:06:42 +0100


Since no one seems to have answered this yet, I'll take a stab at it. > From: Gonzalo Génova [mailto:ggenova@inf.uc3m.es] > > The current definition of the operation Namespace.contents is: > > The operation "contents" results in a Set containing all ModelElements > contained by the Namespace. > contents : Set(ModelElement) > contents = self.ownedElement -> union(self.namespace, contents) > > (UML Specification, version 1.4 page 2-64, version 1.3 page 2-55) > > The last line of this definition seems wrong, since the > "union" operation must have a single parameter. It can be a simple > typographic error, where the right text would be: > > contents = self.ownedElement -> union(self.namespace.contents) > > However, the interpretation of this expression is not what > the text says, but: "The operation "contents" results in a Set > containing all ModelElements contained by the Namespace plus > all ModelElements contained by the containing Namespace". In my opinion the above, typo-corrected OCL assertion is the correct one, and you're right in that the original natural-language description is incorrect. A more "correct" description would be: "The operation "contents" results is a Set containing all ModelElements owned by the namespace (i.e. directly contained) plus all ModelElements contained in any enclosing Namespace." The reason for the union(self.namespace.contents) is that NameSpaces may contain NameSpaces, resulting in a hierarchy of (nested) NameSpaces. A given NameSpace may "see" ModelElements defined in an outer, enclosing NameSpace at any level. You might expect this concept to be discussed in a section defining NameSpace or its semantics, but it's not. However, this interpretation is substantiated by the semantics of Package, which is a subclass of NameSpace. from UML 1.4 section 2.14.4.1 p. 2-197: "There may be relationships between elements contained in the same package, and between an element in one package and an element in a surrounding package at any level. In other words, elements "see" all the way out through nested levels of packages." (note - I prefer the term "enclosing" to "surrounding" because I think it is more accurate when talking about containment and nesting, but that's a niggle). also from UML 1.4 section 2.5.2.32 p. 2-47: "An element may also access any contents (public, protected, private, or package) of its own namespace or a containing namespace." Even though the quote from p. 2-47 above is actually from the section describing a Permission Dependency, it seems to have a lot of description about visibility in general. This is typical of the UML spec, where information is redundantly spread thoughout the document, and is often not found in the place you would expect to find it. What made all this namespace stuff confusing to me initially is the UML's distinction between "contents" and "allContents". My initial impression looking around in the UML spec in general was that "contents" consists of the directly owned elements and "allContents" contains additional elements. But the definition of "contents" for NameSpace contradicts this impression because it includes more than just the directly owned elements. In addition, NameSpace makes no distinction between "contents" and "allContents" (i.e., allContents for NameSpace is defined as self.contents). I found this very confusing. It's not until you look at NameSpaces that are also GeneralizableElements (e.g., Classifier and Package) that the difference becomes clearer. For these model elements "allContents" includes the contents as a Namespace (i.e., self.contents) plus all inherited public and protected ModelElements (see UML 1.4 p. 2-58 definition [10]). So in these cases, allContents extends contents with inherited elements. In addition, for a Package, contents includes imported elements (UML 1.4 p. 2-195 definition [1]). So, in my current understanding, "contents" is the usual NameSpace "stuff", which handles directly owned elements, NameSpace hierarchy, and imported elements. "allContents" extends "contents" with inherited elements. Of course, given the girth of UML 1.4 I am not sure that UML is consistent in using these two operations in this way. You may ask yourself (as I did) why NameSpace defines both contents and allContents, even though they are the same. I can only assume that they did this out of some need for uniformity. Either that, or some subtype of NameSpace, or OCL navigation to a subtype of NameSpace, references allContents. I'd be happy to know if anyone has a good answer to this. -Earl Waldin ---------------------------------------------------------------------- Earl Waldin tel: +41 31 828 9222 Paranor AG fax: +41 31 828 9299 Juraweg 14 email: ewaldin@paranor.ch CH-3046 Wahlendorf Switzerland ----------------------------------------------------------------------


Date view Thread view Subject view Author view