UML in a nutshell


uml tools techniques

I don’t always reach for UML but when I do I always draw the wrong little diamond for aggregation vs. composition so maybe this will help me to use the right pen for the job next time!

Introduction

Unified Modeling Language (UML) is a graphical notation covering a wide variety of steps in software and system design. One of the core uses of UML is to design object oriented systems using classes, interfaces, relationships, and other simple graphical elements. The purpose of this document is to describe the most common elements of UML diagrams geared towards class design. All diagrams were created using the yUML website.

The Elements

Class

  • Just the class - no properties or other information

Simple class

  • A class with details. The name is at the top. The public fields (or properties) come next. They have a plus sign if they are public and a minus sign if they are private. Finally come the methods, again marked public or private with signs.

Class with details

Interface

  • Just the name - no details

Interface

  • With some details

Interface with details

Relationships

There are a few different kinds of relationships and deciding which one to use can be a bit confusing at first because it depends upon the intent of the relationship. Simple associations kind of ignore the two main types of associations and can be used for higher level UML diagrams. But being more specific is important as the design evolves and so understanding the difference between aggregation and composition is key. It really comes down to ownership and object lifecycle.

  • Aggregation – This is known as a has a relationship because the containing object has a member object. But here is the critical part: The member object can survive or exist without the enclosing or containing class, so it can have a meaning beyond the lifetime of the enclosing object. Example: A room has a table and the table can exist without the room.

  • Composition – This is known as a is a part of or is a relationship because the member object is part of the containing class and cannot existing or survive outside the context of the containing class. This also means that the lifetime of the member object ends with the lifetime of the enclosing object. Example: The IT Department is part of the Company. The IT Department cannot exist without the Company and has no meaning after the lifetime of the Company.

That said, let’s have a look at the ways to show various kinds of relationship and the characteristics of those relationships.

Simple association

Customers have a billing address

Simple association

The relationship between a Customer and their Orders is described by the action orders. So it reads a Customer orders an Order.

Simple association

Cardinality

A Customer can have zero or more Addresses. An Address must have exactly one Customer. Notice how the numbers are positioned on the line: the customer fact (zero or more) is written next to the Address class.

Cardinality

Directionality

An Order has an Address called billing and an Address called shipping. This does not say anything about the Address-to-Order relationship.

Directionality

Aggregation

A Company has exactly one Location. A Location has a Point.

Aggregation

Composition

The Company has exactly one Location. The Location does not exist outside of the context of the Company.

Composition

Other dependencies

Inheritance

Both the Contract and Salaried classes inherit from the Wages class.

Inheritence

The NightlyBillingTask class inherits (implements) the ITask interface

Implements

Depends On

The HttpContext class is dependent upon the Response class. The relationship reads as “the HttpContext class uses the Response class”. There is no has a or is part of a Response implied here. It is just plain usage.

Depends on

Complete Example

Here it all comes together with some extra annotations in the form of notes.

Complete UML class diagram


🔗 Share on LinkedIn