From: Gonzalo Genova (firstname.lastname@example.org)
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. Saludos, Gonzalo -----Mensaje original----- De: Ivan Porres [mailto:email@example.com] Enviado el: Wednesday, January 22, 2003 12:55 PM Para: firstname.lastname@example.org 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 classes. > 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. Yes. 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, Ivan > > Gonzalo > > ========================================================================== > > Gonzalo Genova email@example.com > Research and Teaching Assistant http://www.ie.inf.uc3m.es/ggenova/ > Department of Computer Science http://inf.lab.inf.uc3m.es/ > Carlos III University of Madrid http://www.uc3m.es/ > > 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- > firstname.lastname@example.org > with a message containing the word "unsubscribe". To remove yourself from this list please mail email@example.com with a message containing the word "unsubscribe".