Examining the UML Models: Static Models - Relationships

(Page 5 of 13 )

The classes on your class diagrams can have three basic kinds of relationships:

• Binary association

• Dependency

• Generalization

These relationships are discussed in the following sections.

Binary Association

The binary association is the most common class relationship. It simply specifies that (exactly) two classes are associated, meaning that they interact or are related in some way. You usually create a binary association relationship between two classes when an instance of one class eventually will communicate with an instance of the other class.

For example, a Customer class can have a binary association relationship to a ShoppingBasket class, to indicate that an object of type Customer communicates with one of type ShoppingBasket class. Your binary associations can also specify the way that the classes will be implemented. If you double-click a binary association, you’ll see the UML Association Properties dialog box, where you can specify the properties for the association, determining not only the business semantics of the association, but also the design decisions about the way the association is implemented.

In Exercise 5-9, you’ll add a ShoppingBasket class to your class diagram and give it a binary association relationship to the Customer class.

---

EXERCISE 5-9

1. Open the MyClassDiagram static structure diagram.

2. Add a new class named ShoppingBasket to the diagram.

3. Add a binary association between the Customer and ShoppingBasket classes.

4. Right-click the binary association and select Shape Display Options from the pop-up menu to open the UML Shape Display Options dialog box.

5. Select the Name option. Deselect the First end name option and the Second end name option. Then click OK.

6. Double-click the binary association to open the UML Association Properties dialog box.

7. Type Buying in the Name field.

8. Select forward from the Name Reading Direction list.

9. In the Association Ends section, select the End1 association end and change its name to Customer. Change its multiplicity to 1.

10. Select the End2 association end and change its name to ShoppingBasket. Change its multiplicity to 0..*. Select the IsNavigable property. Your UML Association Properties dialog box should look like Figure 5-18.

Figure 5-18.  UML Association Properties dialog box

  11.  Click OK.

---

Figure 5-19 shows the binary association between the Customer and ShoppingBasket classes. The association is named Buying. The association ends indicate how the association will be implemented. By specifying that the ShoppingBasket association end is navigable (IsNavigable is selected), you indicate that the Customer class is able to navigate to the ShoppingBasket class. Furthermore, VEA adds an arrowhead to the association end. The Customer association end isn’t navigable, which means that the ShoppingBasket class doesn’t have navigation access to the related Customer class. The multiplicity of 1 for Customer means that each instance of ShoppingBasket relates to only one Customer. The multiplicity of 0..* for ShoppingBasket means that each Customer can have zero or many ShoppingBasket instances.

Figure 5-19.  Binary association between the Customer and ShoppingBasket classes

If you double-click the Customer class, select the Code Generation Options category in the UML Class Properties dialog box, and click the Preview code button, your generated code will look like Listing 5-2. Remember that you need to connect the association ends to the two classes to generate the code shown in Listing 5-2.

Listing 5-2. Code Generated for the Customer Class with a Binary Association

1 Imports TopPackage.MyNamespace
2 Namespace MyNamespace
3
4    Public Class Customer
5
6      Public Name As String
7
8      Public Address As String
9
10     Private ShoppingBasket As
         System.Collections.ArrayList
11
12     Public Function GetList (ByVal customerTypeID As
         Integer) As Object
13
14     End Function
15
16     Public ReadOnly Property CustomerStatus () As
         Boolean
17        Get
18
19       End Get
20
21     End Property
22
23     Public Sub New ()
24
25     End Sub
26
27     Protected Overrides Sub Finalize ()
28
29     End Sub
30
31    End Class ' END CLASS DEFINITION Customer
32
33 End Namespace ' MyNamespace

You can see that the binary association is implemented through line 10, which is an array of objects (the instantiated ShoppingBasket classes). If you set the multiplicity of ShoppingBasket to 1, your code will be generated like this instead:

Private ShoppingBasket As MyNamespace.ShoppingBasket

Dependency Relationship

The dependency relationship specifies that one class has a build dependency on another class, but does not maintain a permanent link to an object of that class. Changes to a class will affect all classes that are dependent on that specific class. Usually, the dependency relationship indicates that the dependent class is invoking at least one operation on the class on which it depends. The dependency relationship doesn’t have any impact on the code generation, although it features in the project references.

In Exercise 5-10, you’ll add two classes, named VIPCustomer and Bonus, to your class diagram and create a dependency relationship between those two classes.

---

EXERCISE 5-10

1. In the MyClassDiagram static structure diagram, add a new class named VIPCustomer.

2. Add a new class named Bonus to the diagram.

3. Add a dependency relationship between the VIPCustomer and Bonus classes.

---

In Figure 5-20, you can see that the class VIPCustomer is dependent on the Bonus class. VIPCustomer would be dependent on Bonus, if, for example, Bonus provides access to some customer bonus points that must be present for the VIPCustomer class to function properly. Having the dependency relationship between the VIPCustomer and Bonus classes tells the developers that any changes made to the Bonus class might affect the VIPCustomer class. This fact must be taken into consideration when deciding on whether to implement the change and how it should be tested.

Figure 5-20.  Dependency relationship between the VIPCustomer and the Bonus classes

Next: Generalization Relationship >>
 

More .NET Articles
More By Apress Publishing

Comments On: Examining the UML Models: Static Models

>>> Be the FIRST to comment on this article!

Buy this book...

This article is excerpted from Enterprise Development with Visual Studio .NET, UML, and MSF written by John Erik Hansen and Carsten Thomsen (Apress, 2004; ISBN: 1590590422) Buy this book now.