Re: Sets and bags / Identity of a link



Date view Thread view Subject view Author view

stuart kent (stuart@mclellankent.com)
Wed, 24 Jan 2001 17:34:14 +0000


Perdita et al. > And I've lost it for the moment, but there's also still the old reference > to whether you can identify "the" link that's relevant in an interaction > diagram -- whereas of course with the static view there may not be one... Mmmm. On this topic, is it not the case that the only way one can invoke a message on another object is if you have a reference to it through one of your own queries (could be an attribute, could be a function, could be tied to an association - see my previous email on this topic) or through a temporary variable, such as a method parameter or a variable locally declared in the invoking method. So what we want seems to be a way of (a) indicating on a class diagram that objects of one class can know about objects of another class temporarily during the execution of a method, as well as showing what queries a class has (whether those queries are shown as attributes/methods on the class, or are linked to associations - Perdita's static view), and correspondingly (b) distinguishing between links corresponding to queries and links corresponding to temporary variables. Stereotypes could be used to do this in current tools. However, I would prefer to see e.g. dotted lines adopted to convey the distinction (wasn't this done in one of the precursors to UML...?). I think you can show which messages flow down which links on a collaboration diagram by placing the message next to the link. Links can be named at either end to indicated which association they correspond to. The real problem with a collaboration diagram is that it is hard to show the creation and deletion of links and objects, in relation to when the messages happen. There is a way out of this, by e.g. combining sequence diagrams with filmstrips (Catalysis), eith side by side or using the third dimension. There's a paper on my website about 3D modelling that discusses some of these issues. It may also be worth spreading the net wider. Objects tend to communicate by issuing and listening for events nowadays. How should we abstract out those connectiosn in our diagrams? Stuart -- ukc home - http://www.cs.ukc.ac.uk/people/staff/sjhk puml group - http://www.puml.org/


Date view Thread view Subject view Author view