Re: links & messages



Date view Thread view Subject view Author view

robert france (france@bach.cs.colostate.edu)
Wed, 19 Jan 2000 17:52:55 -0700 (MST)


>One good reason is when using class diagrams to present, for example, patterns. Then it is important to show the connections that will be used by the pattern, whether transient or not. Agreed. >On the other hand, have you considered teaching heresy: that the associations of a class diagram can have several meanings? I think they can have several meanings in the context of a single development project (though many have disagreed with me on this!). I feel that semantics of models should vary with the level of abstraction when appropriate. For example, at the requirements (problem-oriented) level a Class Diagram should be a conceptual model (as advocated in methods/approaches such as Fusion and Syntropy), meaning that associations represent conceptual relationships between problem concepts represented as classes - a semantics as a set of tuples is appropriate at this level of abstraction; viewing links as references (as the term is used in programming languages) I think is inappropriate here; at the design levels the meaning of a Class Diagram should reflect a more computer-based solution-oriented view of the system (e.g., associations become more "concrete" in that they represent computer-based implementations of conceptual relationships; some additional solution-specific associations may also arise because of the particular solution modeled). If one views software development as the process of transforming models of systems expressed in "real-world" terms (conceptual models) to models expressed in terms of a programming language (implementations), then the above does not sound that strange. The difficult part is making the process systematic and traceable, so I can understand why some programmers may want to circumvent the process and start using a semantics that's more appropriate to a lower level of abstraction (identifying suitable abstractions requires considerable skill/experience and discipline). Traceability is one of the problems I'm trying to tackle in my work. It requires that concepts modeled at one level of abstraction be clearly mapped to corresponding concepts at lower levels of abstraction. The process of moving from one level of abstraction to a lower level of abstraction I call refinement, but as Andy pointed out to me at the OMG meeting this notion of refinement is broader than the one used in the formal methods community - he prefers to call it realization which I think is more appropriate. In a nutshell, I feel that when one talks about the meaning of a UML model they need to qualify their statements with the level of abstraction they are referring to ... (and I'm sure that others disagree with this; let's discuss!). Maybe I'm teaching heresy after all! Robert ==================================================================== Robert B. France, Assoc Professor | Tel: 970-491-6356 Computer Science Department | Fax: 970-491-2466 Colorado State University | Email: france@cs.colostate.edu Fort Collins, CO 80523 | www.cs.colostate.edu/~france/


Date view Thread view Subject view Author view