It's useful to find and show associations that are needed to satisfy the information requirements of the current scenarios under development, and which aid in understanding the domain.
An association is a relationship between classes (more precisely, instances of those classes) that indicates some meaningful and interesting connection (see Figure).
In the UML, associations are defined as "the semantic relationship between two or more classifiers that involve connections among their instances."
Guideline: When to Show an Association?
Associations worth noting usually imply knowledge of a relationship that needs to be preserved for some duration - it could be milliseconds or years, depending on context. In other words, between what objects do we need some memory of a relationship!
For example, do we need to remember what SalesLine ltem instances are associated with a Saleinstance? Definitely, otherwise it would not be possible to reconstruct a sale, print a receipt, or calculate a sale total.
And we need to remember completed Sales in a Ledger, for accounting and legal purposes.
Because the domain model is a conceptual perspective, these statements about the need to remember refer to a need in a real situation of the world, not a software need, although during implementation many of the same needs will arise.
In the monopoly domain, we need to remember what Square a Piece (or Player) is on - the game doesn't work if that isn't remembered. Likewise, we need to remember what Piece is owned by a particular Player. We need to remember what Squares are part of a particular Board.
But on the other hand, there is no need to remember that the Die (or the plural, "dice") total indicates the Square to move to. It's true, but we don't need to have an ongoing memory of that fact, after the move has been made. Likewise, a Cashier may look up Product Descriptions, but there is no need to remember the fact of a particular Cashier looking up particular Product Descriptions.
Guideline: Why Should We Avoid Adding Many Associations?
We need to avoid adding too many associations to a domain model. Digging back into our discrete mathematics studies, you may recall that in a graph with n nodes, there can be (n - (n - l)) / 2 associations to other nodes - a potentially very large number. A domain model with 20 classes could have 190 associations lines! Many lines on the diagram will obscure it with "visual noise." Therefore, be parsimonious about adding association lines. Use the criterion guidelines suggested in this chapter, and focus on "need - to - remember" associations.
Perspectives: Will the Associations Be Implemented In Software?
During domain modeling, an association is not a statement about data flows, database foreign key relationships, instance variables, or object connections in a software solution; it is a statement that a relationship is meaningful in a purely conceptual perspective - in the real domain.
That said, many of these relationships will be implemented in software as paths of navigation and visibility (both in the Design Model and Data Model). But the domain model is not a data model; associations are added to highlight our rough understanding of noteworthy relationships, not to document object or data structures.
Applying UML: Association Notation
An association is represented as a line between classes with a capitalized association name.
The ends of an association may contain a multiplicity expression indicating the numerical relationship between instances of the classes. The association is inherently bidirectional, meaning that from instances of either class, logical traversal to the other is possible. This traversal is purely abstract; it is not a statement about connections between software entities.
The UML notation for associations
An optional "reading direction arrow" indicates the direction to read the association name; it does not indicate direction of visibility or navigation. If the arrow is not present, the convention is to read the association from left to right or top to bottom, although the UML does not make this a rule.
Guideline: How to Name an Association in UML?
Guideline Name an association based on a ClassName - VerbPhrase - ClassName format where the verb phrase creates a sequence that is readable and meaningful. Simple association names such as "Has" or "Uses" are usually poor, as they seldom enhance our understanding of the domain.
Association names should start with a capital letter, since an association represents a classifier of links between instances; in the UML, classifiers should start with a capital letter. Two common and equally legal formats for a compound association name are:
Applying UML: Roles Each end of an association is called a role. Roles may optionally have:
Applying UML: Multiplicity
Multiplicity defines how many instances of a class A can be associated with one instance of a class B.
Multiplicity on an association
For example, a single instance of a Store can be associated with "many" (zero or more, indicated by the *) Item instances.
Some examples of multiplicity expressions are shown in Figure.
The multiplicity value communicates how many instances can be validly associated with another, at a particular moment, rather than over a span of time. For example, it is possible that a used car could be repeatedly sold back to used car dealers over time. But at any particular moment, the car is only Stocked - by one dealer. The car is not Stocked - by many dealers at any particular moment. Similarly, in countries with monogamy laws, a person can be Married - to only one other person at any particular moment, even though over a span of time, that same person may be married to many persons.
The multiplicity value is dependent on our interest as a modeler and software developer, because it communicates a domain constraint that will be (or could be) reflected in software. See Figure for an example and explanation.
Multiplicity is context dependent
Rumbaugh gives another example of Person and Company in the Works - for association [Rumbaugh91]. Indicating if a Person instance works for one or many Company instances is dependent on the context of the model; the tax department is interested in many; a union probably only one. The choice usually depends on why we are building the software.
Applying UML: Multiple Associations Between Two Classes
Two classes may have multiple associations between them in a UML class diagram; this is not uncommon. There is no outstanding example in the POS or Monopoly case study, but an example from the domain of the airline is the relationships between a Flight (or perhaps more precisely, a FlightLeg) and an Airport (see Figure); the flying - to and flying - from associations are distinctly different relationships, which should be shown separately.
Guideline: How to Find Associations with a Common Associations List
Start the addition of associations by using the list in Table. It contains common categories that are worth considering, especially for business information systems.
Examples are drawn from the
Table Common Associations List
Example: Associations in the Domain Models
Case Study: NextGen POS
The domain model in Figure shows a set of conceptual classes and associations that are candidates for our POS domain model. The associations are primarily derived from the "need - to - remember" criteria of this iteration requirements, and the Common Association List. Reading the list and mapping the examples to the diagram should explain the choices. For example:
NextGen POS partial domain model
Case Study: Monopoly
See Figure Again, the associations are primarily derived from the "need - to - remember" criteria of this iteration requirements, and the Common Association List. For example:
Monopoly partial domain model
UML Related Interview Questions
|Adv Java Interview Questions||Java collections framework Interview Questions|
|Design Patterns Interview Questions||Rational robot Interview Questions|
|Web semantic Interview Questions||Spring MVC Framework Interview Questions|
|Advanced C++ Interview Questions||Advanced jQuery Interview Questions|
|XML DOM Interview Questions||Object Oriented Analysis and Design Interview Questions|
Object-oriented Analysis And Design
Iterative, Evolutionary, And Agile
Inception Is Not The Requirements Phase
Iteration 1 Basics
System 'sequence Diagrams
Requirements To Design-iteratively
Logical Architecture And Uml Package Diagrams
On To Object Design
Uml Interaction Diagrams
Uml Class Diagrams
Grasp: Designing Objects With Responsibilities
Object Design Examples With Grasp
Designing For Visibility
Mapping Designs To Code
Test - Driven Development And Refactoring
Uml Tools And Uml As Blueprint
Iteration 2 - More Patterns
Quick Analysis Update
Grasp: More Objects With Responsibilities
Applying Gof Design Patterns
Iteration 3 Intermediate Topics
Uml Activity Diagrams And Modeling
Uml State Machine Diagrams And Modeling
Relating Use Cases
Domain Model Refinement
More Ssds And Contracts
Logical Architecture Refinement
More Object Design With Gof Patterns
Designing A Persistence Framework With Patterns
Uml Deployment And Component Diagrams
Documenting Architecture: Uml & The N+1 View Model
More On Iterative Development And Agile Project Management
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.