Non-real associations?



Date view Thread view Subject view Author view

Ulf Schuenemann (ulf@cs.mun.ca)
Wed, 13 Mar 2002 17:21:06 -0330 (NST)


Hello, I hope someone can help me with (some of) my questions about the stereotyping of AssociationEnd as «association», «global», «local», «parameter», and «self». First, I wonder why these are stereotypes of the ends, and not the association itself. What would different stereotypes at the opposite ends of the same association mean? Second, «association» is described as ``specifies a real association.'' But what is a real association? Am I the only one missing an explanation here? If the other stereotypes correspond to the programming language concepts of global variable, local variable, procedure parameter, and implicit self parameter, this leaves instance variables (fields, data members) for ``real associations.'' Could one thus say that ``real associations'' are those genuinely modeled in the static model, without reference to behavior (similar to the data-oriented modeling of relations in E/R, from where OO borrowed many association modeling concepts)? If I interpret [Rumbaugh: Depending on Collaborations: Dependencies as Contextual Associations; JOOP 11(4) 1998] correctly then behavior-related links between objects originally were integrated into the static model only in form of dependencies. Only for uniformity all links had to be instances of some associations, so that the notion of something like ``non-real'' associations became accepted (``contextual association'' in Rum98). Third, can there be «local» and «parameter» association ends a multiplicity not allowing zero? This would seem to require the object to be always executing at least one operation... Wouldn't a Well-Formedness Rule make sense here (for non-active objects)? Upper bounds on the cardinality of «local» and «parameter» assocations seem to introduce constraints on recursion (of the operation (method) with these parameters (and locals)). Is there a useful example for such constraining? Is there a way to distinguish in a collaboration diagram the locals and parameters of different recursive activations of the same operation/method? I thought about (ab)using the notation for qualified association to express this - the qualifier would be the operation activation, which could be expressed in a collaboration diagram as the sequence number of the message triggering this activation. Fourth, it seems the UML spec implicitily assumes that all composition associations are of stereotype «association», when it says A composite object is similar to ... collaboration, but it is defined completely by composition in a **static** model. and that Attributes are semantical equivalent to composition, which is used to explain what Attributes are and to motivate alternative presentation forms of composition/composite objects. It should be clarified that this is only true for «association» compositions (and not rely on «association» being the default). The alternative is a general Well-Formedness Rule for associations that composition implies «association», something like (still wondering why there are stereotypes at each AssociationEnd): self.allConnections->exists(aggregation = #composite) implies self.allConnections->forAll(stereotype.name = "aggregation") I'd be happy if anyone could shed some more light on non-real associations than the UML specification and the textbooks I know do. Ulf Schuenemann -------------------------------------------------------------------- / Ulf Schuenemann phone:+1(709)738-3806 /*~, Department of Computer Science mailto:ulf@cs.mun.ca /___', Memorial University of Newfoundland -'# St. John's, NF, Canada


Date view Thread view Subject view Author view