Re: Dependencies and associations



Date view Thread view Subject view Author view

Joaquin Miller (miller@joaquin.net)
Thu, 21 Jun 2001 08:47:21 -0700


This is real progress. Tony brings together a number of different and equally important points and presents a coherent whole. Of course, dependency is a catch-all term for things that can't be handled in any other way. The spec is explicit: "a term of convenience for a relationship other than ..." We are all slow to learn (though most not as slow as myself). Kilov and Ross, to pick just one example, have shown a long time ago how to be precise about different kinds of relationships. Tony's work below is easily recast along the lines of the ISO GRM standard and sorted using the notion of viewpoint. Then we can award the coveted 'p' to UML relationships. At 03:36 AM 6/21/2001, Tony Simons 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 > >========================================================================== Joaquin Miller Chief Architect Financial Systems Architects mailto:joaquin@acm.org http://community-ML.org Oakland, California phone: +1 (510) 336-2545 fax: +1 (510) 336-2546 PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3


Date view Thread view Subject view Author view