3C Clear Clean Concise UML
Previous Contents Next
communityUML 2torial
An association is used when the modeler wishes to represent some structure of things in the system or its environment.
For each association there are roles for the associated model elements. Each of these elements is bound to one or more of these roles.
The invariants of the association are a collection of statements that, among them, mention each of the roles of that association at least once. The meaning of the association is provided by those statements.
An association also has roles for actions. These actions include the action that establishes the association and the action that terminates the association. (Since UML 2 enables the modeller to use abstraction throughout the model, these action are not required to be specified, if the modeler prefers not to do so.)
The
statements of an association are constraints on the elements in the association. The
statements may mention the types and observable properties of the elements as well as the
actions of objects in the association.
Q: In what ways does UML 2 association differ from UML 1 association?
A: The 3C submission for UML 2 uses association where UML 1 uses link, and uses association type where UML 1 uses association. The submission says that the choice of names for the concepts of UML should be made by the A&D Task Force after discussion.
Another choice of terms would be link and link type; with association as a synonym for link type. Another, of course, is to stick with the UML 1 style of having a different name for each concept.
Q: OK. So then: In what ways does UML 2 association differ from UML 1 link?
A: Association in UML 2 is a first class concept. An association type may defined without specifying the particular classes that are linked.
An association has roles. Each role specifies a type that an object bound to that role must satisfy. (More on types soon in this tutorial.) Any object may be bound to a role of an association, so long as it satisfies the specified type, and independently of what class that object may have been created from.
Q: How would this be useful?
A: This allows the specification of a library of reusable generic association types. Such a library might be project specific, reused by several projects in a company, or even adopted as OMG technology. In the case of an OMG technology, the types specified for each role of a generic association type would be a CORBA object type (and so, would be specified using IDL).
Q: Just what do you mean by 'role'?
A: That is the next topic.
Q: You say the meaning of the association is provided by statements. What are these statements, exactly?
A: A UML 2 model is made of:
-- model elements (like objects, actions, and associations, as well as types and roles)
-- statements about those model elements
Statements about an association include the number of elements in each role (multiplicity), whether the association is navigable in one direction or another (navigability), what actions must be taken if one or another element is removed from the association (composite aggregation), and other statements the modeler specifies. The statements may be entered in property sheets provided by a tool, as OCL, or as text.
Q: Wait a minute! I thought multiplicity and navagability were part of the association end.
A: Well, that's right! The UML 1 association end is a concept that combines one of the roles of that association with some of the statements about an association. The UML 1 association end as role is a placeholder for one of the associated elements; the UML 1 association end as statements are those statements that mention the element bound to that role.
(Keep in mind, what UML 1 calls an association is called an association type in UML 2. What UML 1 calls an link is called an association in UML 2. However, the ADTF may decide it prefers to stick with the UML 1 terminology.)
Q: So, does UML 2 have association ends?
A: Yes and no.
Q: ?
A:
Previous Contents Next RunningExample
The OMG
mark, UML, is a trademark of
Object Management Group, Inc. (OMG).
During development of this web site, please send
comments to Joaquin Miller. mailto:joaquin@acm.org
Copyright © 2000 Financial Systems Architects