Re: Dependencies and associations



Date view Thread view Subject view Author view

Daniel Jackson (dnj@lcs.mit.edu)
Fri, 22 Jun 2001 11:41:38 -0400


tony, your points are well taken and you raise some fundamental issues. a few comments: 1. it's quite possible to interpret associations uniformly at different stages. in the approach i teach, they always denote state and their constraints denote state invariants. in object models of code, i admit the _additional_ interpretation that an association represents a field, but the notion of association as state component still holds. 2. your explanation of what dependences are explains a lot of the confusion. but i don't agree with you when you say: Likewise, in analysis, the notion of dependency X->Y is defined early on as a relationship between X and Y such that changes to Y will affect X in some way. This is entirely reasonable as an abstract definition of dependency. this seems to be entirely _unreasonable_, and the source of the kind of problems we're having! it's just far too vague to be useful. joaquin's quote (from the UML spec?) about dependences: The spec is explicit: "a term of convenience for a relationship other than ..." horrifies me (although it's hardly surprising given the style in which UML is typically presented). my point of view is that there's not much use in a notion that's so vaguely defined you don't even know what it's for. 3. some observations on what dependence means. -- like many notions in software analysis, it's really the converse that we're interested in. we want to infer that A does NOT depend on B, so that changes to B can be made in such a way that A remains unaffected. -- defining dependence is really tricky. it's wrong to say that A depends on B if a change to the code of B will affect the behaviour of A: that would make almost everything dependent, and it would make the dependence relationship transitive (rendering it useless). -- the criterion is more like this: that A depends on B if a failure of B alone to satisfy its spec will affect A's ability to satisfy its spec. then if A depends on B and B depends on C, a failure of C to satisfy its spec might adversely change the execution of B, but this will not induce a dependence of A on C, since A depends only on B meeting its spec, and this can be done even if C fails to. -- having developed such a notion, determining what constitutes a dependence in a language such as Java is a separate (and non-trivial) question. exceptions, for example, have to be considered carefully. -- there are simpler notions of dependence worth exploring too -- eg. A must be recompiled if B's text changes. 4. i quite agree that the confusion of two different design processes in UML -- roughly the Booch vs. OMT approach -- is the root of many problems. and i applaud your desire to match notations and semantics to method. that said, i do think that it's desirable and possible to have notations that have semantics and analyses that are independent of any method. we've tried hard to achieve this independence with Alloy. /daniel At 06:36 AM 6/21/2001, you wrote: >This is to add to earlier comments by Joaquin Miller, Daniel Jackson >and Andy Evans. I share their feeling about the imprecision with which >these terms are defined, but can shed some different light on the >problem. > >Argument 1: a Universal notation > >Part of the reason why we have difficulty in relating notions of >association and dependency in UML is that they have different natural >interpretations at different stages in the OOAD process. I don't think >any of the previous discussion made this explicit. > >In analysis, associations are just semantic relationships between >classifier concepts; the directionality is usually not an issue, so >whether X depends on Y, or vice-versa, does not arise. At this stage, >the physical interpretation of an association is not fixed (it may >eventually become a reference, or not - it could be engineered away, >or replaced by an association class, the equivalent of a linker >entity in ERM). We just think of an association as a semantic >relationship in a conceptual model of the domain. > >Likewise, in analysis, the notion of dependency X->Y is defined >early on as a relationship between X and Y such that changes to Y >will affect X in some way. This is entirely reasonable as an abstract >definition of dependency. According to this, it would be possible >to think of a directed association as some kind of dependency, but >UML doesn't seem to make any judgement about this, since the >directionality of associations is not a major issue in analysis and >so whether or not there is an intention for associations to overlap >with dependencies doesn't arise. > >The problems come when you translate this into the design stage, in >which associations are supposed to represent structural links, whereas >dependencies are used to show any remaining non-structural relationships >between classes, such as temporary relationships with method argument >classes. This tends to reinforce the view that associations and >dependencies are disjoint things - you should choose one or the other, >and cannot have both. I also get the distinct impression that a >dependency is a catch-all term for things that can't be handled in any >other way. > >The discontinuity between analysis and design views is a problem. It >arises because UML is a *universal* notation that is deployed with >different meanings at different stages of development. The discontinuity >is a challenge to those who propose a strong "seamless transition" from >analysis to design, a concept with which I disagree. > >Argument 2: an Eclectic notation > >Others have challenged the basic premise of mixing undirected semantic >associations with navigable client-server relationships, all within the >same model. > >For example, if you interpret a UML class diagram as an ERM, then the >use of associations is appropriate and suitable transformations can be >applied to handle 1:M, 1:1, M:N and optional relationships, with the >outcome of an optimised data model in 3NF. This is, after all, where >the notion of association came from, semantic data modelling. > >However, if you interpret a UML class diagram as a RDD graph of client- >server dependencies, then the connections between them are all navigable >dependencies of some kind (whether we call them associations or dependencies >seems immaterial) and suitable transformations include applying the Mediator >pattern to aggregate over tightly-coupled subsystems and remove their >internal connections, or applying the Template Method pattern to convert >multiple dependencies to a single one. Generally, a different strategy >is used to decrease the client-server coupling and, eventually, the number >of structural connections needed to represent them. > >Either of these two design procedures is appropriate; each of them would >deliver a completely different model, optimised for different purposes >(data dependency; client-server functional dependency). I think that some >of the association/dependency indecision results from not knowing what >kind of model we are trying to build. > >UML seems to represent both perspectives in the same diagram, with the >result that a developer does not have any guidance regarding in which >direction he should progress the design. The "design forces" (to use a >GoF term) are equally balanced. So, UML diagrams are eventually used >only to record information, and are not so productive in directing further >work on the design. > >All this arises because UML is an *eclectic* notation, it mixes in the >same model notations that originated in quite different original design >approaches. While seeming fair and democratic, the result is a confused >picture, which mixes design forces and so is not really productive. > >Conclusions > >The way out of this is to identify individual, coherent design processes, >select models that best capture the handle on the problem with respect to >each design process, then invest the notations with semantics that support >the model. > >Trying to precisely define all the current elements of UML within one >single framework is rather like constructing a mathematical model of the >phlogiston theory of combustion. Fine, we can create precise models of >negative particle weights and so forth, but have we even got the basic >conceptual framework right? I think this should come first. > >The above arguments were first articulated in my and Ian Graham's >"30 things" paper, published in Kilov, Rumpe and Simmonds, Behavioural >Specifications of Businesses and Systems, KAP, 1999: > >http://www.dcs.shef.ac.uk/~ajhs/abstracts.html#uml30thg >http://www.dcs.shef.ac.uk/~ajhs/papers/uml30thg.ps > > >--Tony > > >Previously, Joaquin Miller summarised: > >----------------------- >Daniel Jackson wrote: > >does anyone share my depressing sense that UML and all these discussions we >have about it seem to create more heat than light? > >we share that sense. we'd like to do something about that. > >Andy Evans wrote: > >One of the problems is that we don't have a language (other than > English) to >describe precisely what the abstractions (associations, dependencies, >aggregation, etc, etc) mean. > >we agree. we'd like to fix that. > > >Another problem is that the abstractions have many possible meanings > (each of >which has advantages and disadvantages in terms of intuitiveness, simplicity, >etc). We must accept that there is no one right abstraction or semantics. > >no one right. but every right abstraction has an exact meaning. >or so we hope. >------------------------ > > >========================================================================== > >Dr Anthony J H Simons a.simons@dcs.shef.ac.uk >Senior Lecturer in Computer Science http://www.dcs.shef.ac.uk/~ajhs >Director of Teaching > >Department of Computer Science tel: (+44) 114 22 21838 >University of Sheffield dept: (+44) 114 22 21800 >Regent Court, 211 Portobello Street fax: (+44) 114 22 21810 >SHEFFIELD, S1 4DP univ: (+44) 114 22 22000 >United Kingdom > >========================================================================== > > > > > >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