Association

I define Association as a relationship between two classes in a UML class model. First, I use associations to show how objects connect. For example, I link Person and Address with an association named “lives” or “correspondence address”. Next, I name the association with a verb phrase. Then, I state the reading direction. In addition, I add multiplicities at each end. Consequently, I show how many objects may or must relate to each other.

I specify roles on the ends of associations. For example, I label one end “resident” and the other “home”. Moreover, I use role names to clarify meaning when I model similar associations. Also, I keep association names unique. Otherwise, navigation through the information model becomes confusing.

I use multiplicities to define counts. For example, I write 1 or 0..* to express exact or many. Therefore, I can model cases where one person has one residence and one correspondence address. Similarly, I can model that an address may serve many people. Because I imagine actual objects, I find multiplicities easier to decide. Thus, I encourage modelers to act out relationships mentally. In other words, I picture instances to check constraints.

I often use association classes when I need to attach properties to the link itself. For example, I add a ManagementInformation association class between Person and Address. Then, I store CreatedOn and CreatedBy for each specific link. Consequently, I enrich the relationship with metadata. However, I remain careful. In practice, novice users may misinterpret association classes. Therefore, I sometimes replace an association class with a normal class plus two associations. For instance, I convert the association class into an Order class linking Person and Product. This step clarifies multiplicities and behavior.

I derive functional requirements from associations. For example, a requirement “Show address” often remains incomplete. Thus, I refine it to “Show the correspondence address of the person who is the contact for the company”. In this way, I use associations to narrow the context. As a result, I reduce ambiguity. Additionally, I use association navigation to specify which objects a use case must touch. Furthermore, I document role names and multiplicities in the requirements text.

I follow heuristics to identify association classes. For example, I look for linguistic cues such as “how long”, “since when”, or “how often”. Moreover, I search for statements that mention properties of the relationship rather than properties of the objects. Consequently, I mark such statements as candidates for association classes. If the UML notation becomes hard to read, I model the concept as an ordinary class and two associations. This approach simplifies understanding and validation.

I give practical modeling tips. First, I prefer simple, clear names. Second, I imagine instances to choose multiplicities. Third, I validate association semantics with stakeholders. Finally, I keep diagrams readable. In addition, I document any constraints that UML cannot express. For example, I add textual requirements for special cases. Overall, I use associations to describe structure, to enable navigation, and to support precise requirements.