An Association models a static and structural relationship between Actors, Classes, Data Types, Interfaces, Signals and Attributes (parts and ports) and Roles (parts and ports). An Association is assumed to be bi-directional unless an association arrow represents traversal direction. Note that traversal direction is a reflection of policy, it is does not indicate how the association is to be implemented.
Name direction shows the direction in which the association is to be read. Sometimes this is obvious and can be omitted.
Each Association must have a Role for each end of the Association. It is not necessary to name the Role and hence show the Role on the diagram. Role names are similar to Association direction names except that nouns are used instead of verbs, for example "Controller" instead of "Controls". Use of Role names and direction names on the same diagram is not recommended as this clutters the diagram with overlapping information.
You create an Association through the Class Diagram and Composite Structure Diagram. The View Options on the Class Diagram and Composite Structure Diagram allow you to either show or hide the Name and Role Name of an Association. In addition, on the Composite Structure Diagram you can show or hide the Multiplicity.
Note that when a Class Diagram shows an association or composite aggregation symbol starting from an Activity, that link symbol represents a Call Behavior Action, Central Buffer, Data Store, Input Pin or Output Pin, rather than an Association dictionary item. For more information, see the following topics:
On a Composite Structure Diagram, you can create Associations as shallow or deep. Unless you have a good reason to do otherwise, always create Shallow Associations. For more information about shallows and deep Associations, see
Shallow and deep associations.
In the Modeler panes, a short-cut symbol on the Association's icon indicates that the item is a stub. For more information, see
Stubs.
The access permissions you have to an Association are determined by the access permissions you have to the item at the start end of the Association.
• If you select the Associations folder in the Dictionary pane, the Contents pane displays the following information about each Association in the model: Aggregation, Start Class, Start Role, End Class and End Role.
• You can move the start or end of an Association to any Class, Data Type, Interface or Signal on a Class Diagram or Composite Structure Diagram.
The following sections provide information about how an Association is used in the model. For more information about a property, item, model part or diagram, click it.
• Multiplicity (Start Multiplicity Text or Start Multiplicity Uml, and End Multiplicity Text and End Multiplicity Uml through the automation interface)
• The multiplicity of an Association is defined through the drop-down list boxes on the Start Role and End Role tabs of an Association's Property Pages.
• The In Role box on the Start Role and End Role tabs of the Property Pages specifies the name of the linked Role.
• The When Qualified By box on the Start Role and End Role tabs of the Property Pages specifies the name of the linked Qualifier.
An Association is owned jointly by the two items it links, that is, if either item is deleted the Association is deleted as well. The access permissions you have to an Association are determined by the access permissions you have to the item at the start end of the Association.
Dependency - The Dependency is owned jointly by the Association and the other associated item. The access permissions you have to a Dependency are determined by the access permissions of the dependent item.
IO Flow - An IO Flow can be realized by an Association.
Role - The linked Roles specify the start and end roles for the Association. Note that the name of the linked Roles appears in the In Role boxes on the Start Role and End Role tabs of an Association's Property Pages.