Uncovering Requirements With UML Class Diagrams Part 3

UML Class Diagrams are very effective at uncovering requirements. They give us insight into how the business thinks about objects and their relationships. And from that understanding, we think to ask questions we might otherwise overlook. In this part of our series, we look at how to represent when one object is made up of other objects. The two types of relationships we explore are composition and aggregation.

Catching Up on UML Class Diagrams

If you’ve found this article first, there are two that came before it.

1. Uncovering Requirements With UML Class Diagrams Part 1: Discusses how to represent objects and entities from a business perspective.
2. Uncovering Requirements With UML Class Diagrams Part 2: Discusses simple relationships between objects or entities.
3. Uncovering Requirements With UML Class Diagrams Part 3: This article.

So jump back to the other articles and get up to speed. We’ll wait for you here. As a reminder, in this series, we’re specifically focusing on using UML class diagrams for uncovering requirements – as part of analysis, not design. We’re talking about what the business needs, not how the solution will work. UML class diagrams can be used for both, and most tutorials are written for programmers doing design work. This one is written for people who work with requirements.

Relationships of Combination

When a collection of bananas are combined, we call them a bunch. Crows exist in a murder, and lions in a pride. Teams are made up of players. It is a deck of cards. An order is a collection of line items. We have always had the notions of both individual items (or people) and combinations existing as an interesting entity. Sometimes we treat them the same – you can eat a banana or a bunch. You can feed a lion or a pride. Sometimes, we deal with the combined entity. You shuffle a deck, you fulfill an order.

Understanding this type of relationship can be very important to understanding what your customer (aka “the business”) needs. You are describing the mental model of the business. Business people think about fulfilling an order, not “fulfilling all of the items on the order.” A user may want to archive the history (all the previous versions) of a file, or she may just want to keep the most recent version. Thinking about these concepts helps you uncover the requirements.

There are two jargon terms – aggregation and composition – that apply when we talk about multiple things as one combined thing. They have precise meanings.

• Composition – when one item is part of another item, the relationship is composition.
• Aggregation – when one item can be included in another item, the relationship is aggregation.

If that doesn’t make sense, this “formal” distinction will really mess you up:

Composition is a stronger form of aggregation where the whole and parts have coincident lifetimes, and it is very common for the whole to manage the lifecycle of its parts.

Scott Ambler

Here are some examples that may simplify things:

Composition

• A building is composed of one or more rooms (a room is part of a building)
• A plane is composed of a fuselage, one or more engines, and one or more wings (a wing is part of a plane)
• An order is composed of one or more line items (a line item is part of an order)

Aggregation

• A team includes more than one players
• A library includes more than one books
• A market includes one or more customers

Ambler’s definition makes sense, when you think about these examples. You could shut down a library without destroying the books – likewise, you could kick one of the players off a team and the team would still exist. That’s what he means by coincident lifetimes.

Drawing a Composition Relationship With Visio

To draw a composition relationship in Visio, you use the composition shape from the UML Static Structure stencil.

When you first drop this shape on the page to connect two classes, it looks like the following:

There is a solid black diamond on one end (the first end) and nothing on the other end. In UML, this is stating that an order is composed of line items. By default, Visio shows the “end names” as it did with the association shape. You can fix it the same way we did before. Right click on the line and select shape display options.

Then make the same modification we did before, to show the shape name and suppress the display of the “end names.”

Now you have the kind of display you want. Note the check marks at the bottom of the dialog – you only have to make this change once per class diagram. Unfortunately, Visio does not remember this change, so you have to do it once for every diagram (every new file, and every new tab within the same file). Annoying.

Double click on the line to update the information about this composition relationship.

You will end up with the following (we re-arranged it to make it easier to read):

Drawing an Aggregation Relationship With Visio

Drawing an aggregation relationship is almost the same as a composition relationship with Visio – it just requires an additional step.

In this example, a book club reviews books. You want to show that the book club includes members. Note – members can come and go without causing the book club to be disbanded. You can think of aggregation as membership in a combined entity.

First, use the composition shape again (the same as above), and update the properties as we just did. You will see

The Visio stencil does not include a special aggregation shape, so we will cheat by changing the formatting of the composition shape. Select (in the menu at the top of the window) format > line…

And in the dialog, you will change the display of the “Begin” end-point.

Aggregation is represented in UML Class Diagrams with the same diamond-shape as composition. The difference is that the shape is “empty” instead of being a solid black diamond. Click “Apply” and “OK” and you end up with what you want:

Note: If you change the format of the composition line first, and then change the properties (“Joins” etc), Visio will reset the line end to be a solid diamond again. It resets. Annoying. If you copy an aggregation line, the copy reverts to the solid diamond again too. Very annoying.

Next Up

Up to this point, you’ve learned how to define classes (and attributes), simple relationships (A book club reviews books, and a member reads books), and combinations of items as compositions and aggregations (an order is composed of line items, and a book club aggregates members).

Next, we will cover hierarchies, usually thought of as “Is a” relationships. A Sales Rep is an employee, and an employee is a person.

Uncovering Requirements With UML Class Diagrams Part 4: Generalization (inheritance) and how to use it.