RE: namespace & element ownership

Date view Thread view Subject view Author view Attachment view

From: Gonzalo Genova (
Date: Fri 14 Feb 2003 - 16:03:49 GMT

Hola Ivan,

I have several questions regarding your answers some weeks ago:

1. If the definition of an element can be spread among different packages,
what does it mean, that a package OWNS an element (represented in the
metamodel by an aggregation). I don't consider this a true ownership,
therefore I would not use an aggregation. Or else, confirm it as
ownership/aggregation and forbid spreading definitions.

2. In favor of the interpretation that the definition of an element can be
spread among different packages, you say that all associations at the
metamodel level are bidirectional. True. But SHOULD they? I rather think
that the metamodel should be modified according to the principle that an
element cannot be modified outside its owner package, therefore suppressing
bidirectional associations among elements from different packages. You don't
need putting all model elements in the same package, you only need
restricting usage of bidirectional associations.

3. If C is a subclass of A, and the designer changes the definition of A,
this implies a problem for C. Yes, but at least C KNOWS that it depends on
A. I think we have a worse issue when you change the definition of C outside
of its owner package; that is, looking only to the "main" definition of C
would not be enough to determine all its dependencies.


-----Mensaje original-----
De: Ivan Porres []
Enviado el: Wednesday, January 22, 2003 12:55 PM
Asunto: RE: namespace & element ownership

Hola Gonzalo,

> It seems in UML v1.4 that a namespace owns the NAMES of the elements it
> contains, but not the DEFINITIONS of the elements. 
I disagree. UML 1.4, page 5-4 shows that there is an aggregation between
Namespace and ModelElement with the ends named namespace and ownedElement. A
namespace owns its model elements, not the names of the model elements.

> Then, an element's
> definition could be spread among different packages. 
This is how UML works since all associations at the metamodel level are
bidirectional (they are relations). 

Take as an example the metamodel association
AssociationEnd.participant<->Classifier.association from page 5-3 of the UML
1.4 standard. This metamodel association implies that if we "connect" two
classes with an association, we have to modify the definition of the

> For example, you
> could
> declare class A in package P, and then declare in package Q that A is a
> subclass of B.
> But this seems incorrect to me. 

But if we declare that C is a subclass of A in package R we may also have
modularity/encapsulation issues. What happens if the definition of A is
changed by the designer?

> I think an element should not be modified
> out of the owner package or namespace. 
Then all model elements should be in the same package!

>I would like to hear some opinions
> about this.
I understand your point, but there is no general solution. What you can do
is define well-formed rules for your specific profile. In the previous
example you could define a WFR like

context Classifier:
  self.generalization.forAll(lambda g: g.namespace==self.namespace)

This forces a class and its generalizations in the same namespace. The
syntax is not OCL but I am sure you get the idea.

There are many things in UML 1.4 that do not make too much sense. A
recursive example: data types are model elements. There is a data type
called "Name" (page 5-10). Therefore an instance of "Name", since it is also
a model element, has an attribute called name of type "Name".

Un saludo,


> Gonzalo
> ==========================================================================
> Gonzalo Genova              
> Research and Teaching Assistant
> Department of Computer Science
> Carlos III University of Madrid
> Escuela PolitÚcnica Superior
> Avda. de la Universidad, 30
> 28911 LeganÚs - Madrid - Spain
> Tel. (34) 91 624 91 07
> Fax (34) 91 624 91 29
> To remove yourself from this list please mail puml-list-
> with a message containing the word "unsubscribe".

To remove yourself from this list please mail
with a message containing the word "unsubscribe".

Date view Thread view Subject view Author view Attachment view