Directed Relationships

Directed relationships are binary relationships-- usually between solution domain elements-- in which one end is designated as the source and the other end as the target.

Dependency

Dependency is the most general type of directed relationship.

UML defines three types of dependencies: usage, realization, and deployment.

Usage  Dependencies

Usage dependencies are the most common.

This means that the client uses services provided by the provider. More generally, this means that changes to the provider may require changes to the client. This could happen if, for example, someone changes the name of a Provider method that is called by the client.

Less generally, a dependency usually indicates that the client explicitly references the provider in some way.

A provider can be referenced by the client as a super class or the type of a field, parameter, return value, or local variable:

class Client extends Provider {
   Provider someField;
   Provider someMethod(Provider someParam) {
      Provider someLocal;
      ...
   }
   ...
}

Usage dependencies are transitive: if A depends on B and B depends on C, then implicitly, A depends on C (although we generally wouldn't represent this in a diagram).

The UML Standard Profile specifies several types of usage dependencies:

Of course dependencies can exist between other types of UML elements.

·       Elements in a client package depend on elements in a provider package, therefore the client package depends on the provider package:

·       The withdraw funds use case explicitly invokes the verify PIN use case before funds can be withdrawn. he withdraw funds use case implicitly invokes the handle overdraft use case if the customer attempts to withdraw too much.

·       An eStore component depends on other components to realize the Inventory and Accounting interfaces:

·       Changes to the Provider.java file (a UML artifact) may require us to re-compile the Client.java file. (This is the kind of information that might be expressed in a build file.):

Notes:

Although conceptually useful, I rarely see or use dependency arrows between classes.

Realization

Realization (also called implementation) is the relationship between an abstraction and a concrete implementation.

For example, the relationship between an interface and the classes that implement it:

Components can also realize interfaces, and collaborations (i.e., interacting objects) realize components:

Notes

·       In Java realization translates into implementation:

class Natural implements Nummeric, Comparable, Serialiable { ... }

·       Scala doesn't have interfaces, instead it has traits (which I represent in UML as a class icon with the <<trait>> stereotype).

·       Interface members include properties (attributes and references), operations, and receptions. A reception is an operation that is automatically invoked when an object realizing the interface receives a message.