Class diagrams

Class Diagrams

Depicting Classes and Static Relationships

UML Class Diagrams

Class diagrams allow us to express classes in UML Including attributes and methods

Class diagrams allow us to declare our classes (visually)

Classes in UML

Athlete

Fruit

Apple

HockeyPlayer

Person

Kiwi

ClassNames

Classes in UML

As you can imagine, the class shapes shown here are a major part of class diagrams Both forms are acceptable for classes that have

no attributes or methods The two empty blocks are used for holding

declarations of attributes and methods The top block is used to hold the class name

Attributes in Classes

Athlete

teamName: String

Person

age: Durationheight: Length

Fruit

numSeeds: Integer

Apple

skinColour: Colourdiameter: Length


Attributes are specified using the form: name : type This format is taken from Eiffel, which uses a

Pascal-like syntax Names are usually alphanumeric Types are logical types from the domain

In this example, an apple’s diameter is a quantity of type ‘Length’, which could be represented as a float or double in C++ or Java

Attribute Modifiers

Attributes can be read/write (default) or read only Attributes that are read only are preceded with the

modifier ‘/’ Attributes can be defined on the objects

(default) or the class Class attributes are preceded with the modifier ‘$’

Attribute Modifiers

Attributes can have different visibilities Public attributes, denoted with the modifier ‘+’, can be

accessed from outside the class Private attributes, denoted with the modifier ‘-’, can only be

accessed from within the class Protected attributes, denoted with the modifier ‘#’, can be

accessed from within the class, or any descendant (e.g. a subclass)


Athlete

+teamName: String

Person

/ age: Durationheight: Length

Fruit

-numSeeds: Integer

Apple

-skinColour: Colour#diameter: Length$carboRatio: Real

Operations in Classes

Person

+birthday()+getHeight(): Length Apple

+getSkinColour(): Colour+bite(depth: Length)

Operations in Classes

Operations can be defined, using the form:opName([in|out|inout] param1 : type1,…) : returnType

The modifiers in, out, and inout specify which direction(s) the parameters are to travel in: input to the operation out: output from the operation inout: input to the operation, possibly modified, then output

from the operation Often, if no modifier is specified, a parameter is assumed

to be input only (in) Again, type1 and returnType are types from the

application domain

Abstract Classes and Methods

Athlete{abstract}

+getPointsTotal() {abstract}

Abstract Classes and Methods

The class Athlete was declared abstract This is analogous to abstract classes in Java

The getPointTotals() method was declared abstract This means the method is not implemented in this class,

but left for a (concrete) subclass to implement This method being abstract makes it necessary for Athlete

to be declared an abstract class

Genericity in Classes

Genericity, or run-time determined types, in a class can be represented in UML This allows you to design classes to work on a group of

types, where the type is ‘generic’ at compile time

The type, specified at run-time, is an argument or parameter to the class This, such classes are called parameterized classes

Parameterized Classes

Printer

+print(item : T)

T

Parameterized Classes

Printer

+print(item : T)

T

ImagePrinter

<< bind >>

<Image>

Class Diagrams

Ok, so now we’ve seen what classes look like in UML

We now need to know how to define relationships between these classes

There are three types of relationships: A ‘is a type of’ B (inheritance) A ‘is associated with’ B (association) A ‘is a part of’ B (composition)

Inheritance

Fruit

Apple Kiwi

Inheritance

Fruit

Apple Kiwi

This is an alternatenotation

Multiple Inheritance

CDWriter

StorageDevice CDReader

Groups

Whenever we create a subclass, we are defining a new group of objects, that is a subset of the superclass’ group

To be even more complete, when we define inheritance, we usually use keywords to give details about those groups

Overlapping/Disjoint Groups

Overlapping/Disjoint Overlapping: Groups are overlapping if there are

objects that are members of both groups Disjoint: Groups are disjoint if there are no objects

that are members of both groups

Overlapping Groups

Overlapping/Disjoint Example: Say we have a superclass called

‘Movie’ Say we have two subclasses of ‘Movie’ called

‘Comedy’ and ‘Action’ Since it is possible for a movie to have both action

and comedy, the two groups are overlapping

Overlapping Groups

Movie

Comedy Action

overlapping

Overlapping Groups

ComedyAction

Movies

A Venn Diagram

Disjoint Groups

Overlapping/Disjoint Example: Say we have a superclass called ‘Book’ Say we have two subclasses of ‘Book’ called

‘Paperback’ and ‘Hardcover’ Since a book is either a paperback or a hardcover

book, the two groups are disjoint

Disjoint Groups

Book

Paperback Hardcover

disjoint

Disjoint Groups

Hardcover Paperback

Books

Complete/Incomplete Groups

Complete/Incomplete Complete: The groups listed contain all possible

objects that belong to the superclass’ group I.e. No more disjoint subclasses can be defined

Incomplete: The groups listed do not contain all possible objects that belong to the superclass’ group

Complete Groups

Complete/Incomplete Example: Consider our superclass ‘Book’ with its

subclasses ‘Hardcover’ and ‘Paperback’ Are there any other kinds of book?

The answer is ‘no’, this the groups are complete

Complete Groups

Book

Paperback Hardcover

disjoint, complete

Complete Groups

Hardcover Paperback

Books

Incomplete Groups

Complete/Incomplete Example: Consider our superclass ‘Movie’ with

its subclasses ‘Comedy’ and ‘Action’ Are there any other kinds of movie?

The answer is ‘yes’, this the groups are incomplete

Incomplete Groups

Movie

Comedy Action

overlapping, incomplete

Incomplete Groups

Action

Movies

Comedy

There aremore items

Completeness/Disjointness

We have seen examples for: Overlapping, incomplete Disjoint, complete

Is it possible to have groups that are: Overlapping, complete? Disjoint, incomplete?

What are some examples?

Overlapping, complete

What about sets of numbers? Say we have a superclass called ‘Number’ and three

subclasses called ‘Integer’, ‘Real’, and ‘Complex’ All numbers possible are represented, thus the groups are

complete Yet, the number 14, for example, falls into all three

categories It should be fairly obvious that 14 is both an Integer and a

Real number

Disjoint, Incomplete

What about living creatures? We may have a class ‘LivingThing’ and two

subclasses ‘Plant’ and ‘Animal’ Most biologists would agree that plants and

animals are disjoint Nothing is a plant and an animal

However, Fungi are not plants and are not animals The groups Plants and Animals are not complete

Group Separation

As you may have already noticed, class hierarchies are highly subjective You can often create subclasses of a given class using

several different attributes to distinguish subclasses For example, consider ‘Vehicle’

One set of subclasses might be ‘Aircraft’, ‘Boat’, ‘Automobile’

Another set might be ‘GasPowered’, ‘SolarPowered’, … Another might be ‘WheeledVehicle’, ‘WingedVehicle’, …

Group Separation

In the example, each set of subclasses may have different values for completeness and disjointness

Typically, which set of subclasses you choose depends on the problem domain For example, if it is irrelevant if a vehicle has wings or

wheels, we wouldn’t use those subclasses Perhaps we only care about arrival times and costs

Association

Associations between classes represent logical relationships objects of those classes might hold

For example, a ‘Person’ class might have an association ‘HomeAddress’ with another class ‘Location’ This is because an instance of Person might have

an instance of Location as its home address

Association

Keep in mind, associates deal with objects, rather than classes Thus they declare what associations are possible between

their instances There may be several instances of the association at any

time The number of instances changes over time One instance may hold several instances of the same

association

Association

An association contains: The name of the association

This name describes the association Multiplicity at each end of the association

This describes the number of instances that may occur at that end of the association

The role of the class at each end (optional) This is usually a name used to describe the instances with

respect to that association

The last two will be described individually

Association

Let’s illustrate these concepts with an example Say we have two classes, ‘Person’ and

‘MusicalInstrument’ , and an association called ‘Plays’

The association Plays represents all instances where a Person plays a Musical Instrument

Association

Person MusicalInstrumentPlays

We might have the following instances of ‘Plays’: Bob plays Piano Lucy plays Saxophone Lucy plays Trumpet Sue plays Drums

Association


The multiplicity of Person means: How many people can play a given

instrument? What is the answer?

Association


The multiplicity of Person means: How many people can play a given

instrument? Any number of people can play a

given instrument, including zero This is represented using 0..*

Association


The multiplicity of MusicalInstrument means: How many instruments can a person

play? What is the answer?

0..*

Association


The multiplicity of MusicalInstrument means: How many instruments can a person

play? A person may play zero instruments,

or any number of them Again, this is 0..*

0..*

Association


Essentially, an association could be considered a class itself Every instrument any person plays is

an instance of the Plays association Associations would have members

such as ‘name’, ‘multiplicity1’, ‘multiplicity2’, etc..

0..* 0..*

Association

Person MusicalInstrument0..* 0..*

Plays

Higher-Order Associations

Associations need not always be between 2 classes Associations can exist between 3 or more classes

as well

Composition

Composition is a relationship between two classes where one class is a part of another (an ‘is a part of’ relationship) If a class A is composed of classes B, C, and D,

we may say that A has components B, C, and D Compositions typically consist of a name, as well

as the multiplicity of the component

Composition

If a class ‘Car’ has a composition relationship with another class ‘Wheel’, we should agree that normally the multiplicity of Wheel is 4 (exactly)

‘Vehicle’, on the other hand, could have any number of wheels (0..*)

Composition is a special form of association It is important enough to have its own notation

Composition

Wing

Airplane

Propeller Fuselage Tail1 112

Aggregation

Aggregations is also a type of association, but again, a special one that is given its own notation This is because, like composition, it is very

common An aggregation is another relationship

between classes which says one class ‘is a part of’ another class

Aggregation vs. Composition

Both aggregation and composition represent the ‘is a part of’ relationship

The main difference is what the part represents In aggregation, the part (constituent) is

meaningful without the whole (aggregate) In composition, the part (component) is not

meaningful without the whole (container)


A side-effect of this difference is that a component is always a part of (at most) one container However, a constituent may be a member of

multiple aggregates


In UML, composition is considered a special case of aggregation where constituents belong only to a single aggregate This is why some tools (such as Rational Rose)

only have symbols for aggregation, and not composition

Aggregation

To illustrate an constituent, again, let’s use a few examples: A Forest is an aggregate of Trees A Program is an aggregate of Statements A Fleet is an aggregate of Ships A Deck is an aggregate of Cards

Aggregation

Parts of an aggregate are called constituents: A Tree is an constituent of Forest A Statement is an constituent of Program A Ship is an constituent of Fleet A Card is an constituent of Deck

Aggregation

These constituents share one common property: The constituents of an aggregate are usually the same type

Two other properties are also defined for aggregation: An object may be a constituent of more than one aggregate

simultaneously It is possible to have an aggregate without any constituents

Aggregation

An object may be a constituent of more than one aggregate simultaneously This is identified by the multiplicity of the

aggregate end of the association It is possible to have an aggregate without

any constituents This is identified by the multiplicity of the

constituent end of the association

Aggregation

Club

Member

1..*

1..*

Aggregation

Toybox

Toy

1..*

1

Aggregate Order

Aggregates can be ordered or unordered In ordered aggregates, the order of the constituents within

the aggregate is important In unordered aggregates, the order is unimportant

Ordered aggregates are indicated using the symbol [ordered] Unordered is the default for aggregates

Aggregate Order

Toybox

Toy

1..*

1

Magazine

Page

1..*

1

[ordered]

Aggregation and Composition

In programming, aggregation and composition are usually represented by class attributes

However, for clarity, in class diagrams, aggregation and composition should always be used instead of the attribute form This is because it allows the definition of the class

being used to be shown

Class Diagrams: An Example

Say we are writing a word processor A word processing document consists of a

number of paragraphs Each paragraph consists of a number of elements An element can be a character or an image

Class Diagrams: An Example

Element

Character Image

ParagraphDocument1 0..*

[ordered]

1 0..*

[ordered]

Class Types

In class diagrams, there are three basic types of classes: Entity classes: Used to model information and associated

behaviour of some phenomenon or concept such as an individual, a real-life object, or a real-life event

Boundary classes: Used to model interaction between the system and its actors

Control classes: Used to represent coordination, sequencing, transactions and control of other objects

Class Types

«control»MyControlClass

«boundary»MyBoundaryClass

«entity»MyEntityClass

Class Types: Alternate Notation

MyEntityClass

MyControlClass

MyBoundaryClass

Documents

Class diagrams