Advanced Relationships

A relationship is a connection among things. In object-oriented modeling, the four most important relationships are dependencies, generalizations, associations, and realizations. Graphically, a relationship is rendered as a path, with different kinds of lines used to distinguish the different relationships.

Dependency

A dependency is a using relationship, specifying that a change in the specification of one thing (for example, class SetTopController) may affect another thing that uses it (for example, class ChannelIterator), but not necessarily the reverse. Graphically, a dependency is rendered as a dashed line, directed to the thing that is depended on. Apply dependencies when you want to show one thing using another.

A plain, unadorned dependency relationship is sufficient for most of the using relationships you'll encounter. However, if you want to specify a shade of meaning, the UML defines a number of stereotypes that may be applied to dependency relationships. There are 17 such stereotypes, all of which can be organized into six groups.

First, there are eight stereotypes that apply to dependency relationships among classes and objects in class diagrams.

Continuing, there are two stereotypes that apply to dependency relationships among packages.

Two stereotypes apply to dependency relationships among use cases:

You'll encounter three stereotypes when modeling interactions among objects.

One stereotype you'll encounter in the context of state machines is

Finally, one stereotype that you'll encounter in the context of organizing the elements of your system into subsystems and models is:

Generalization

A generalization is a relationship between a general thing (called the superclass or parent) and a more specific kind of that thing (called the subclass or child). For example, you might encounter the general class Window with its more specific kind, MultiPaneWindow. With a generalization relationship from the child to the parent, the child (MultiPaneWindow) will inherit all the structure and behavior of the parent (Window).

Most of the time, you'll find single inheritance sufficient. A class that has exactly one parent is said to use single inheritance. There are times, however, when multiple inheritance is better, and you can model those relationships, as well, in the UML. For example, below figure shows a set of classes drawn from a financial services application. You see the class Asset with three children: BankAccount, RealEstate, and Security. Two of these children (BankAccount and Security) have their own children. For example, Stock and Bond are both children of Security.

Two of these children (BankAccount and RealEstate) inherit from multiple parents. RealEstate, for example, is a kind of Asset, as well as a kind of InsurableItem, and BankAccount is a kind of Asset, as well as a kind of InterestBearingItem and an InsurableItem.

Parents, such as InterestBearingItem and InsurableItem, are called mixins because they don't stand alone but, rather, are intended to be mixed in with other parents (such as Asset) to form children from these various bits of structure and behavior.

A plain, unadorned generalization relationship is sufficient for most of the inheritance relationships you'll encounter. However, if you want to specify a shade of meaning, the UML defines one stereotype and four constraints that may be applied to generalization relationships.

First, there is the one stereotype:

Next, there are four standard constraints that apply to generalization relationships:

These two constraints apply only in the context of multiple inheritance. You'll use disjoint and overlapping when you want to distinguish between static classification (disjoint) and dynamic classification (overlapping).

Association

An association is a structural relationship, specifying that objects of one thing are connected to objects of another. For example, a Library class might have a one-to-many association to a Book class, indicating that each Book instance is owned by one Library instance. Furthermore, given a Book, you can find its owning Library, and given a Library, you can navigate to all its Books. Graphically, an association is rendered as a solid line connecting the same or different classes. You use associations when you want to show structural relationships.

There are four basic adornments that apply to an association: a name, the role at each end of the association, the multiplicity at each end of the association, and aggregation. For advanced uses, there are a number of other properties you can use to model subtle details, such as navigation, qualification, and various flavors of aggregation.

Navigation

Given a plain, unadorned association between two classes, such as Book and Library, it's possible to navigate from objects of one kind to objects of the other kind. Unless otherwise specified, navigation across an association is bidirectional. However, there are some circumstances in which you'll want to limit navigation to just one direction. For example, as below figure shows, when modeling the services of an operating system, you'll find an association between User and Password objects. Given a User, you'll want to be able to find the corresponding Password objects; but given a Password, you don't want to be able to identify the corresponding User.

Visibility

Given an association between two classes, objects of one class can see and navigate to objects of the other, unless otherwise restricted by an explicit statement of navigation. However, there are circumstances in which you'll want to limit the visibility across that association relative to objects outside the association. For example, as below figure shows, there is an association between UserGroup and User and another between User and Password. Given a User object, it's possible to identify its corresponding Password objects. However, a Password is private to a User, so it shouldn't be accessible from the outside (unless, of course, the User explicitly exposes access to the Password, perhaps through some public operation). Therefore, as the figure shows, given a UserGroup object, you can navigate to its User objects (and vice versa), but you cannot in turn see the User object's Password objects; they are private to the User. In the UML, you can specify three levels of visibility for an association end, just as you can for a class's features by appending a visibility symbol to a role name.

Qualification

In the context of an association, one of the most common modeling idioms you'll encounter is the problem of lookup. Given an object at one end of an association, how do you identify an object or set of objects at the other end? For example, consider the problem of modeling a work desk at a manufacturing site at which returned items are processed to be fixed. As below figure shows, you'd model an association between two classes, WorkDesk and ReturnedItem. In the context of the WorkDesk, you'd have a jobId that would identify a particular ReturnedItem. In that sense, jobId is an attribute of the association. In the UML, you'd model this idiom using a qualifier, which is an association attribute whose values partition the set of objects related to an object across an association. You render a qualifier as a small rectangle attached to the end of an association, placing the attributes in the rectangle, as the figure shows.

Composition

There is a variation of simple aggregation, composition, that does add some important semantics. Composition is a form of aggregation, with strong ownership and coincident lifetime as part of the whole. Parts with non-fixed multiplicity may be created after the composite itself, but once created they live and die with it. Such parts can also be explicitly removed before the death of the composite.

This means that, in a composite aggregation, an object may be a part of only one composite at a time. For example, in a windowing system, a Frame belongs to exactly one Window. This is in contrast to simple aggregation, in which a part may be shared by several wholes. For example, in the model of a house, a Wall may be a part of one or more Room objects.

As below shows, composition is really just a special kind of association and is specified by adorning a plain association with a filled diamond at the whole end.

Association Classes

In an association between two classes, the association itself might have properties. For example, in an employer/employee relationship between a Company and a Person, there is a Job that represents the properties of that relationship that apply to exactly one pairing of the Person and Company.

In the UML, you'd model this as an association class, which is a modeling element that has both association and class properties. An association class can be seen as an association that also has class properties, or as a class that also has association properties. You render an association class as a class symbol attached by a dashed line to an association as in below figure:

Constraints

UML defines five constraints that may be applied to association relationships.

First, you can distinguish if the association is real or conceptual:

Second, you can specify that the objects at one end of an association (with a multiplicity greater than one) are ordered or unordered:

Next, there are three properties, defined using constraint notation, that relate to the changeability of the instances of an association.

Finally, there are three defined constraints that relate to the changeability of the instances of an association:

 Finally, there is one constraint for managing related sets of associations:

Realization

A realizationis a semantic relationship between classifiers in which one classifier specifies a contract that another classifier guarantees to carry out. Graphically, a realization is rendered as a dashed directed line with a large open arrowhead pointing to the classifier that specifies the contract.

Most of the time, you'll use realization to specify the relationship between an interface and the class or component that provides an operation or service for it. An interface is a collection of operations that are used to specify a service of a class or a component. For example, as below figure shows, a class (such as AccountBusinessRules in an order entry system) in a system's design view might realize a given interface (such as IRuleAgent). That same interface (IRuleAgent) might also be realized by a component (such as acctrule.dll) in the system's implementation view. Note that you can represent realization in two ways: in the canonical form (using the interface stereotype and the dashed directed line with a large open arrowhead) and in an elided form (using the interface lollipop notation).

You'll also use realization to specify the relationship between a use case and the collaboration that realizes that use case, as below figure shows. In this circumstance, you'll almost always use the canonical form of realization.

Common Modeling Techniques

Modeling Webs of Relationships

When you model these webs of relationships,

• Don't begin in isolation. Apply use cases and scenarios to drive your discovery of the relationships among a set of abstractions.
• In general, start by modeling the structural relationships that are present. These reflect the static view of the system and are therefore fairly tangible.
• Next, identify opportunities for generalization/specialization relationships; use multiple inheritance sparingly.
• Only after completing the preceding steps should you look for dependencies; they generally represent more-subtle forms of semantic connection.
• For each kind of relationship, start with its basic form and apply advanced features only as absolutely necessary to express your intent.

Remember that it is both undesirable and unnecessary to model all relationships among a set of abstractions in a single diagram or view. Rather, build up your system's relationships by considering different views on the system. Highlight interesting sets of relationships in individual diagrams.

Reading:
bind - http://www.excelsoftware.com/csharp_models.pdf
derive - http://www.devshed.com/c/a/Practices/Class-Relationships/3/
friend - http://www.csci.csusb.edu/dick/samples/uml1b.html and http://www.jeckle.de/files/UML1_2/apndxa.pdf
instanceOf - http://programmers.stackexchange.com/questions/101157/how-do-you-annotate-instantiation-in-uml-class-diagrams and http://www.devshed.com/c/a/Practices/Class-Relationships/3/                   
instantiate - http://www.devshed.com/c/a/Practices/Class-Relationships/3/ and http://www.cems.uwe.ac.uk/~jsa/UMLJavaShortCourse09/CGOutput/Unit4/unit4%280809%29/page_08.htm
powertype - http://www.jeckle.de/files/UML1_2/apndxa.pdf
refine - http://www.devshed.com/c/a/Practices/Class-Relationships/3/
use - http://www.devshed.com/c/a/Practices/Class-Relationships/3/