RE: Dependencies and associations



Date view Thread view Subject view Author view

Gonzalo Génova (ggenova@inf.uc3m.es)
Mon, 25 Jun 2001 13:59:24 +0200


Daniel, I know you don't like the definitions of dependency in the Standard. Anyway, here there are some quotations from v1.4 (draft): - A dependency states that the implementation or functioning of one or more elements requires the presence of one or more other elements [UML 2-37]. - A dependency specifies that the semantics of a set of model elements requires the presence of another set of model elements. This implies that if the source is somehow modified, the dependents probably must be modified [UML 2-78]. - A relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element) [UML B-6]. First definition deals with the idea of the required "presence"; in my understanding, if class A has a navigable association to class B, then class A requires the presence of class B to function, and so I say that A is dependent on B (for example, you cannot reuse A without reusing B; the inverse is not true). Regarding the second definition, if, for example, an operation's name changes in class B, then class A will have to be modified accordingly (if it invokes this operation): this matches your "code text dependence", but I think this applies too at a higher level. Finally, I agree the third defintion is too vague to be useful. Gonzalo -----Mensaje original----- De: Daniel Jackson [mailto:dnj@lcs.mit.edu] Enviado el: Friday, June 22, 2001 5:16 PM Para: puml-list@cs.york.ac.uk Asunto: RE: Dependencies and associations gonzalo, yes, that's one of the key points i make. i'm afraid i still don't understand your point of view though -- i don't see what you say that A is dependent on B! Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley 1995. /daniel At 07:29 AM 6/19/2001, Gonzalo Génova wrote: >Daniel, > >I have read and enjoyed your excellent lecture notes. You explain there how >a good design achieves navigability without incurring dependencies. Let me >simplify your reasoning and adapt it to UML: class A has a navigable >association to class B, and class C is a subclass of class B. At compile >time, A depends on B, but it does not depend on C. At run time, you can have >instances of A linked to instances of C, therefore you can navigate from >instances of A towards instances of C. You have achieved navigability from A >to C without dependency from A to C. > >But I think this is not in contradiction with what I had argued. At run-time >you have links, at compile-time you have associations. I said "navigability >creates a dependency", where I really meant "navigable associations create a >dependency". And this is true in the example: A has a navigable association >towards B that makes A dependent on B. > >BTW, I don't know the GoF book, could you give the full reference? > >Gonzalo > >-----Mensaje original----- >De: Daniel Jackson [mailto:dnj@lcs.mit.edu] >Enviado el: Friday, June 08, 2001 7:17 PM >Para: puml-list@cs.york.ac.uk; puml-list@cs.york.ac.uk >Asunto: RE: Dependencies and associations > > >gonzalo, > >At 12:20 PM 6/8/2001, Gonzalo Génova wrote: > >Daniel Jackson> associations and dependencies are completely different > >things. > > > Since navigability means knowing ... > > Second consequence, navigability creates a dependency > >no! navigability does not mean knowing, and it does not create a >dependency. that is arguably the central insight of most of the patterns in >the GoF book. an important part of design is figuring out how to achieve >navigability without incurring dependences. my lecture notes explain this >in detail (see below). > >/daniel > > >from intro to lecture 5 in >http://www.mit.edu/~6.170/Old-Fall00/handouts/lectures/lecture-notes.pdf > >... >The notion of dependence is essential for doing good software design. We’ll >define dependences, and see how the coupling they bring about causes >problems by making a program less flexible and harder to reason about. >We’ll examine three language constructs that can be used to reduce >dependences: procedures, global variables and Java interfaces. Interfaces >will be the most interesting and important of the three. > >We’ll see how, in an object-oriented language such as Java, the control >flow at runtime does not necessarily match the compile-time structure. This >will be exposed as mismatches between the object model and the module >dependence diagram. It’s a tricky notion, but a useful one, since it let’s >you use dynamic configuration to obtain flexibility. Java interfaces are >crucial support for this. Also, many of the design patterns we’ll see later >rely on this. >... > > > > >To remove yourself from this list please mail >puml-list-request@cs.york.ac.uk >with a message containing the word "unsubscribe". > > > > >To remove yourself from this list please mail puml-list-request@cs.york.ac.uk >with a message containing the word "unsubscribe". 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