UML and Design Patterns: June 2013

Object diagrams model the instances of things contained in class diagrams. An object diagram shows a set of objects and their relationships at a point in time.

You use object diagrams to model the static design view or static process view of a system. This involves modeling a snapshot of the system at a moment in time and rendering a set of objects, their state, and their relationships.

With the UML, you use class diagrams to visualize the static aspects of your system's building blocks. You use interaction diagrams to visualize the dynamic aspects of your system, consisting of instances of these building blocks and messages dispatched among them. An object diagram covers a set of instances of the things found in a class diagram. An object diagram, therefore, expresses the static part of an interaction, consisting of the objects that collaborate, but without any of the messages passed among them. In both cases, an object diagram freezes a moment in time, as shown below:

Common Properties

An object diagram is a special kind of diagram and shares the same common properties as all other diagrams, that is, a name and graphical contents that are a projection into a model. What distinguishes an object diagram from all other kinds of diagrams is its particular content.

Object diagrams commonly contain:

Objects
Links

Like all other diagrams, object diagrams may contain notes and constraints.

Object diagrams may also contain packages or subsystems, both of which are used to group elements of your model into larger chunks. Sometimes, you'll want to place classes in your object diagrams, as well, especially when you want to visualize the classes behind each instance.

Common Uses

You use object diagrams to model the static design view or static process view of a system just as you do with class diagrams, but from the perspective of real or prototypical instances. This view primarily supports the functional requirements of a system, that is, the services the system should provide to its end users. Object diagrams let you model static data structures.

When you model the static design view or static process view of a system, you typically use object diagrams in one way:

To model object structures

Common Modeling Techniques

Modeling Object Structures

To model an object structure,

Identify the mechanism you'd like to model. A mechanism represents some function or behavior of the part of the system you are modeling that results from the interaction of a society of classes, interfaces, and other things.
For each mechanism, identify the classes, interfaces, and other elements that participate in this collaboration; identify the relationships among these things, as well.
Consider one scenario that walks through this mechanism. Freeze that scenario at a moment in time, and render each object that participates in the mechanism.
Expose the state and attribute values of each such object, as necessary, to understand the scenario.
Similarly, expose the links among these objects, representing instances of associations among them.

For example, below figure shows a set of objects drawn from the implementation of an autonomous robot. This figure focuses on some of the objects involved in the mechanism used by the robot to calculate a model of the world in which it moves. There are many more objects involved in a running system, but this diagram focuses on only those abstractions that are directly involved in creating this world view.

Forward and Reverse Engineering

Forward engineering (the creation of code from a model) an object diagram is theoretically possible but pragmatically of limited value. In an object-oriented system, instances are things that are created and destroyed by the application during run time. Therefore, you can't exactly instantiate these objects from the outside.

Reverse engineering (the creation of a model from code) an object diagram is a very different thing. In fact, while you are debugging your system, this is something that you or your tools will do all the time.

To reverse engineer an object diagram,

Chose the target you want to reverse engineer. Typically, you'll set your context inside an operation or relative to an instance of one particular class.
Using a tool or simply walking through a scenario, stop execution at a certain moment in time.
Identify the set of interesting objects that collaborate in that context and render them in an object diagram.
As necessary to understand their semantics, expose these object's states.
As necessary to understand their semantics, identify the links that exist among these objects.

If your diagram ends up overly complicated, prune it by eliminating objects that are not germane to the questions about the scenario you need answered. If your diagram is too simplistic, expand the neighbors of certain interesting objects and expose each object's state more deeply.

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/

UML and Design Patterns

Pages

Sunday, 23 June 2013

ATM Application UML Diagrams

Thursday, 20 June 2013

Introduction to Rational Rose

Sunday, 2 June 2013

Object Diagrams

Common Properties

Contents

Common Uses

Common Modeling Techniques

Modeling Object Structures

Forward and Reverse Engineering

Advanced Relationships

Dependency

Generalization

Association

Realization

Common Modeling Techniques

Modeling Webs of Relationships

About Me

Visitors