Chapter 3 Object oriented concepts: UML

What is UML? The Unified Modelling Language is a

standard graphical language for modelling object
oriented software
 At the end of the 1980s and the beginning of 1990s, the
first object-oriented development processes appeared
 The proliferation of methods and notations tended to
cause considerable confusion
 Two important methodologists Rum Baugh and Booch
decided to merge their approaches in 1994.
 They worked together at the Rational Software
Corporation
 In 1995, another methodologist, Jacobson, joined the
team
 His work focused on use cases
 In 1997 the Object Management Group (OMG) started the
1process of UML standardization 12/23/2024
UML – Unified modeling language: Introduction
 UML focuses the concept of Booch, Rambaugh and Jacobson.
 Hence, UML provides constructs for a broad range of
systems and activities (e.g., distributed systems, analysis,
system design, deployment).
 System development focuses on three different models of
the system.
 The functional model, represented in UML with use case
diagrams, describes the functionality of the system from
the user’s point of view.
 The object model, represented in UML with class
diagrams, describes the structure of the system in terms
of objects, attributes, associations, and operations.
 The dynamic model, represented in UML with
interaction diagrams, state diagrams, and activity
diagrams, describes the internal behavior of the system.
UML diagrams
 Class diagrams
 describe classes and their relationships
 Interaction diagrams
 show the behaviour of systems in terms of how
objects interact with each other
 State diagrams and activity diagrams
 show how systems behave internally
 Component and deployment diagrams
 show how the various components of systems are
arranged logically and physically

3 12/23/2024
 UML features
 The diagrams to be interconnected to form a unified
model
 It has a detailed semantics, describing
mathematically the meaning of many aspects of its
notations.
 It has extension mechanisms, to represent
concepts that are not part of the core of UML.
 It has an associated textual language: called
Object Constraint Language (OCL) to formally state
various facts about elements of diagrams.
 The objective of UML is to assist in software
development.
 It is not a methodology, because it does not describe, in
a step-by-step way, how to do things.
4 12/23/2024
What constitutes a good model?
A model should
 use a standard notation
 be understandable by clients and users
 lead software engineers to have insights about
the system
 provide abstraction

Models are used:

 to help create designs
 to permit analysis and review of those designs.
 as the core documentation describing the
system.

5 12/23/2024
Essentials of UML Class Diagrams
 Class diagrams describe the data found in a software
system,
 many of the classes in diagrams correspond to things in
the real world.
 For example, in an airline reservation system: Flight,
Passenger and Airport are classes.
The main symbols shown on class diagrams are:
 Classes
 represent the types of data themselves
 Associations
 represent linkages between instances of classes
 Attributes
 are simple data found in classes and their instances
 Operations
 represent the functions performed by the classes and their instances
 Generalizations
 group classes into inheritance hierarchies 12/23/2024
6
Classes
A class is simply represented as a box with the name of the
class inside
 should be singular and start with a capital letter
 diagram may also show the attributes and operations
 This is done by dividing a class box into two or three
smaller boxes:
 Top box contains the class name, the next box

lists attributes, and the bottom box is operations.

 If you do not want to specify attributes or operations,

then you simply omit the box.

 The most detail, including type of attributes, whether

the feature is public (+) or private (−),

 The complete signature of an operation is:
operationName(parameterName: parameterType …):
returnType

7 12/23/2024
Associations and Multiplicity
An association is used to show how two classes
are related to each other
 The association is drawn as a line between the
classes.
 Symbols indicating multiplicity are shown at each
end of the association
 A multiplicity of 1 indicates that there must be
exactly one instance linked to each object at the
other end of the association
 Can be either zero or one object linked to an
object at the other end of the association,

8 12/23/2024
Labelling associations
 Each association can be labelled, to make
explicit the nature of the association

9 12/23/2024
Analysing and validating
associations
 Many-to-one
 A company has many employees,
 An employee can only work for one company.
 This company will not store data about the
moonlighting activities of employees!
 A company can have zero employees
 E.g. a ‘shell’ company
 It is not possible to be an employee unless
you work for a company

works For 1
Employee * Company

10 12/23/2024
Analysing and validating
associations
 Many-to-many
 An assistant can work for many managers
 A manager can have many assistants
 Assistants can work in pools
 Managers can have a group of assistants
 Some managers might have zero assistants.
 Is it possible for an assistant to have, perhaps
temporarily, zero managers?

Assistant * 1..** Manager

supervisor

11 12/23/2024
Analysing and validating
associations
 One-to-one
 For each company, there is exactly one board of
directors
 A board is the board of only one company
 A company must always have a board
 A board must always be of some company
1 1

Avoid unnecessary one-to-one associations

Avoid this do this

Open in Umple

12 12/23/2024
A more complex example
 A booking is always for exactly one passenger
 no booking with zero passengers
 a booking could never involve more than one
passenger.
 A Passenger can have any number of Bookings
 a passenger could have no bookings at all
 a passenger could have more than one booking

 The frame around this diagram is an optional feature

that any UML 2.0 may possess.
13 12/23/2024
Association classes
 Sometimes, an attribute that concerns two
associated classes cannot be placed in either
of the classes
 The following are equivalent

Reflexive associations

 It is possible for an association to connect a class to itself

14 12/23/2024
Directionality in associations
 Associations are by default bi-directional
 It is possible to limit the direction of an association
by adding an arrow at one end
 The user of this application can associate any
number of written notes with any day. An instance of
class Day would need to know about the instances of
Note associated with it; but
 it is not expected that if you have a Note, there will
be any need to determine the Day to which it
belongs
 Making associations unidirectional can improve
efficiency and reduce complexity, but might also
 limit the flexibility of the system.

15 12/23/2024
 Generalization
Specializing a superclass into two or more
subclasses
 A generalization set is a labelled group of
generalizations with a common superclass
 label describes the criteria used to
specialize the superclass into two or more
subclasses
 The label (sometimes called the discriminator)
describes the criteria used in the specialization
 It is clearest to unite all the generalizations in a set
using a single open triangle. You place the label next
to the open triangle

16 12/23/2024
Associations versus generalizations in object diagrams
 Associations describe the relationships that will
exist between instances at run time.
 When you show an instance diagram generated
from a class diagram, there will be an instance of
both classes joined by an association
 Generalizations describe relationships between
classes in class diagrams.
 They do not appear in instance diagrams at all.
 An instance of any class should also be
considered to be an instance of each of that
class’s super classes

17 12/23/2024
 The Process of Developing Class Diagrams
You can create UML models at different stages and with
different purposes and levels of details
 Exploratory domain model:
 Developed in domain analysis to learn about the domain
 not concerned with operations and polymorphism, nor with
many of the modeling principles
 System domain model:
 Models aspects of the domain represented by the system
 Contain domain classes, associations and attributes
 model represents data that will actually be manipulated and
stored by the system
 System model:
 Includes also classes used to build the user interface and system
architecture
 User interface classes such as windows, menus, commands and forms.
 Classes representing aspects of the system’s architecture such as
clients, servers, files and databases.
18 12/23/2024
System domain model vs System
model

19 12/23/2024
System domain model vs System model
 The system domain model omits many classes that
are needed to build a complete system
 Can contain less than half the classes of the
system.
 Should be developed to be used independently of
particular sets of
 user interface classes
 architectural classes

 The complete system model includes

 The system domain model
 User interface classes
 Architectural classes
 Utility classes: make parts of the system more
reusable, easier to maintain or easier to
connect to other systems.
20 12/23/2024
Suggested sequence of activities
 Identify a first set of candidate classes
 Add associations and attributes
 Find generalizations
 List the main responsibilities of each class
 Decide on specific operations
 Iterate over the entire process until the model is
satisfactory
 Add or delete classes, associations, attributes,
generalizations, responsibilities or operations
 Identify interfaces
 Apply design patterns
 Don’t be too disorganized. Don’t be too rigid
either.

21 12/23/2024
Identifying classes
 When developing a domain model you tend to discover
classes
 May found in source material such as requirements descriptions,
interview notes, or the results of brainstorming sessions.
 When you work on the user interface or the system
architecture, you tend to invent classes
 Needed to solve a particular design problem
 (Inventing may also occur when creating a domain
model)
 Reuse should always be a concern
 Frameworks: will contain many classes from that framework.
 System extensions: will incorporate many of the classes
from the original system.
 Similar systems: to obtain useful insights about the current
application.
22 12/23/2024
 A simple technique for discovering domain
classes
 Look at a source material such as a
description of requirements
 Extract the nouns and noun phrases
 Eliminate nouns that:
 are redundant
 represent instances
 are vague or highly general
 not needed in the application
 Pay attention to classes in a domain model
that represent types of users or other
actors
23 12/23/2024
Identifying associations and attributes
 Start with classes you think are most central and important
 Decide on the clear and obvious data it must contain and its
relationships to other classes.
 Work outwards towards the classes that are less important.
 Avoid adding many associations and attributes to a class
 A system is simpler if it manipulates less information
 As you add an association or attribute, make sure it is
relevant to the application – that it will be needed to
implement some requirement. For
 example, you might be tempted to add many different
attributes to a class Person: name, height, weight,
dateOfBirth, educationLevel etc.
 But do you really need all this information in your
application?
 representing that information in your model adds unnecessary
complexity.
24 12/23/2024
 Tips about identifying and
specifying valid associations
 To find out whether an association should exist,
ask yourself if one class
 possesses
 controls
 is connected to
 is related to
 is a part of
 has as parts
 is a member of, or
 has as members of some other class in your

model
 Specify the multiplicity at both ends

25 Label it clearly. 12/23/2024
Tips about identifying and specifying valid
attributes
 Look for information that must be maintained about each class
 Several nouns rejected as classes, may now become attributes
 An attribute should generally contain a simple value
 It is not good to have many duplicate attributes
 If a subset of a class’s attributes form a coherent group, then
create a distinct class containing these attributes
 E.g. string, number

26 12/23/2024
An example (attributes and
associations)

27 12/23/2024
Allocating responsibilities to
classes
A responsibility is something that the system is required to
do.
 Each functional requirement must be attributed to one of
the classes
 All the responsibilities of a given class should be clearly
related.
 If a class has too many responsibilities, consider
splitting it into distinct classes
 If a class has no responsibilities attached to it, then it is
probably useless
 When a responsibility cannot be attributed to any of the
existing classes, then a new class should be created

 To determine responsibilities
 Perform use case analysis
 Look for verbs and nouns describing actions in the
system description 12/23/2024
28
Categories of responsibilities
 Setting and getting the values of attributes
 Creating and initializing new instances
 Loading to and saving from persistent storage
 Destroying instances
 Adding and deleting links of associations
 Copying, converting, transforming,
transmitting or outputting
 Computing numerical results
 Navigating and searching
 Other specialized work

29 12/23/2024
An example (responsibilities)
• Creating a new regular
flight
• Searching for a flight
• Modifying attributes of a
flight
• Creating a specific flight
• Booking a passenger
• Canceling a booking

30 12/23/2024
Prototyping a class diagram on
paper
 As you identify classes, you write their names on
small cards
 As you identify attributes and responsibilities, you
list them on the cards
 If you cannot fit all the responsibilities on one card:
 this suggests you should split the class into two related
classes.
 Move the cards around on a whiteboard to arrange
them into a class diagram.
 Draw lines among the cards to represent
associations and generalizations.

 Reading assignment
 Class responsibilities card in detail
31 12/23/2024
Difficulties and Risks when creating class
diagrams

 Modeling is particularly difficult skill

 Even excellent programmers have difficulty
thinking at the appropriate level of abstraction
 Education traditionally focus more on design
and programming than modelling
 Resolution:
 Ensure that tem members have adequate
training
 Have experienced modeller as part of the
team
 Review all models thoroughly

32 12/23/2024
Interaction Diagrams
 Interaction
diagrams are used to model
the dynamic aspects of a software
system
 They help you to visualize how the system
runs.
 An interaction diagram is often built from a
use case and a class diagram.
 The objective is to show how a set of
objects accomplish the required
interactions with an actor.

33 12/23/2024
Interactions and messages
 Interaction diagrams show how a set of actors and
objects communicate with each other to perform:
 The steps of a use case, or
 The steps of some other piece of functionality.

 The set of steps, taken together, is called an

interaction.

 Interaction diagrams can show several different

types of communication.
 E.g. method calls, messages send over the network
 These are all referred to as messages.

34 12/23/2024
Elements found in interaction diagrams
 Instances of classes
 Shown as boxes with the class and object identifier
underlined

 Actors
 Use the stick-person symbol as in use case diagrams

 Messages
 Shown as arrows from actor to object, or from object to
object

35 12/23/2024
Creating interaction diagrams
 You should develop a class diagram and a use
case model before starting to create an
interaction diagram.

 There are two kinds of interaction diagrams:

 Sequence diagrams
 Communication diagrams

36 12/23/2024
Sequence diagrams – an example

37 12/23/2024
Sequence diagrams
 A sequence diagram shows the sequence of messages
exchanged by the set of objects performing a certain task
 The objects are arranged horizontally across the diagram.
 An actor that initiates the interaction is often shown on
the left.
 The vertical dimension represents time.
 A vertical line, called a lifeline, is attached to each object
or actor.
 The lifeline becomes a broad box, called an activation box
during the live activation period.
 A message is represented as an arrow between activation
boxes of the sender and receiver.
 A message is labelled and can have an argument list
and a return value.

38 12/23/2024
Sequence diagrams –
same example, more details

39 12/23/2024
Sequence diagrams –
an example with replicated messages
 An iteration over objects is indicated by an asterisk
preceding the message name

40 12/23/2024
Sequence diagrams –
an example with object deletion
 If an object’s life ends, this is shown with an X at the
end of the lifeline

41 12/23/2024
Communication diagrams – an example

42 12/23/2024
Communication diagrams
 Communication diagrams emphasise how the
objects collaborate in order to realize an
interaction
 A communication diagram is a graph with the
objects as the vertices.
 Communication links are added between objects
 Messages are attached to these links.
 Shown as arrows labelled with the message name
 Time ordering is indicated by prefixing the
message with some numbering scheme.

43 12/23/2024
Communication diagrams –
same example, more details

44 12/23/2024
Communication links
 A communication link can exist between two
objects whenever it is possible for one object to
send a message to the other one.

 Several situations can make this message

exchange possible:

1. The classes of the two objects have an association

between them.
 This is the most common case.
 If all messages are sent in the same direction, then
probably the association can be made unidirectional.

45 12/23/2024
Other communication links

2. The receiving object is stored in a local variable of

the sending method.
 This often happens when the object is created in the
sending method or when some computation returns
an object .
 The stereotype to be used is «local» or [L].

3. A reference to the receiving object has been

received as a parameter of the sending method.
 The stereotype is «parameter» or [P].

46 12/23/2024
Other communication links

4. The receiving object is global.

 This is the case when a reference to an object can be
obtained using a static method.
 The stereotype «global», or a [G] symbol is used in this
case.

5. The objects communicate over a network.

 We suggest to write «network».

47 12/23/2024
How to choose between using a
sequence or communication diagram
 Sequence diagrams
 Make explicit the time ordering of the interaction.
 Use cases make time ordering explicit too
 So sequence diagrams are a natural choice when you
build an interaction model from a use case.

 Make it easy to add details to messages.

 Communication diagrams have less space for this

48 12/23/2024
How to choose between using a
sequence or communication diagram
 Communication diagrams
 Can be seen as a projection of the class diagram
 Might be preferred when you are deriving an interaction
diagram from a class diagram.
 Are also useful for validating class diagrams.

49 12/23/2024
Communication diagrams and patterns
 A communication diagram can be used to represent
aspects of a design pattern

50 12/23/2024
State Diagrams
 A state diagram describes the behaviour of a
system, some part of a system, or an
individual object.
 At any given point in time, the system or object is
in a certain state.
 Being in a state means that it is will behave in a specific
way in response to any events that occur.
 Some events will cause the system to change
state.
 In the new state, the system will behave in a different
way to events.
 A state diagram is a directed graph where the
nodes are states and the arcs are transitions.
51 12/23/2024
State diagrams – an example
 tic-tac-toe game (also called noughts and crosses)

52 12/23/2024
States
 At any given point in time, the system is in one
state.

 It will remain in this state until an event occurs

that causes it to change state.

 A state is represented by a rounded rectangle

containing the name of the state.

 Special states:
 A black circle represents the start state
 A circle with a ring around it represents an end state

53 12/23/2024
Transitions
 A transition represents a change of state in
response to an event.
 It is considered to occur instantaneously.

 The label on each transition is the event that

causes the change of state.

54 12/23/2024
State diagrams – an example of transitions
with time-outs and conditions

12/23/2024 55
State diagrams – an example with
conditional transitions

56 12/23/2024
Activities in state diagrams
 An activity is something that takes place while the
system is in a state.

 It takes a period of time.

 The system may take a transition out of the state in

response to completion of the activity,

 Some other outgoing transition may result in:

 The interruption of the activity, and
 An early exit from the state.

57 12/23/2024
State diagram – an example with activity

58 12/23/2024
Actions in state diagrams
 An action is something that takes place effectively
instantaneously
 When a particular transition is taken,
 Upon entry into a particular state, or
 Upon exit from a particular state

 An action should consume no noticeable amount

of time

59 12/23/2024
State diagram – an example with actions

60 12/23/2024
State diagrams – another example

61 12/23/2024
Nested substates and guard conditions
 A state diagram can be nested inside a state.
 The states of the inner diagram are called
substates.

62 12/23/2024
State diagram – an example with
substates

63 12/23/2024
Activity Diagrams
 An activity diagram is like a state diagram.
 Except most transitions are caused by internal events,
such as the completion of a computation.

 An activity diagram
 Can be used to understand the flow of work that an
object or component performs.
 Can also be used to visualize the interrelation and
interaction between different use cases.
 Is most often associated with several classes.

 One of the strengths of activity diagrams is the

representation of concurrent activities.

64 12/23/2024
Activity diagrams – an example

65 12/23/2024
Representing concurrency
 Concurrency is shown using forks, joins and
rendezvous.

 A fork has one incoming transition and multiple

outgoing transitions.
 The execution splits into two concurrent threads.

 A rendezvous has multiple incoming and multiple

outgoing transitions.
 Once all the incoming transitions occur all the outgoing
transitions may occur.

66 12/23/2024
Representing concurrency
 A join has multiple incoming transitions and one
outgoing transition.
 The outgoing transition will be taken when all incoming
transitions have occurred.
 The incoming transitions must be triggered in separate
threads.
 If one incoming transition occurs, a wait condition occurs at
the join until the other transitions occur.

67 12/23/2024
Swimlanes
 Activity diagrams are most often associated
with several classes.
 The partition of activities among the existing
classes can be explicitly shown using swimlanes.

68 12/23/2024
Activity diagrams – an example with
swimlanes

69 12/23/2024
 Implementing Classes Based on
Interaction and State Diagrams
 You should use these diagrams for the parts of
your system that you find most complex.
 I.e. not for every class

 Interaction, activity and state diagrams help you

create a correct implementation.

 This is particularly true when behaviour is

distributed across several use cases.
 E.g. a state diagram is useful when different conditions
cause instances to respond differently to the same
event.

70 12/23/2024
Example

71 12/23/2024
 Difficulties and Risks in Modelling
Interactions and Behaviour
 Dynamic modelling is a difficult skill
 In a large system there are a very large number of
possible paths a system can take.
 It is hard to choose the classes to which to allocate each
behaviour:
 Ensure that skilled developers lead the process, and
ensure that all aspects of your models are properly
reviewed.
 Work iteratively:
 Develop initial class diagrams, use cases, responsibilities,
interaction diagrams and state diagrams;
 Then go back and verify that all of these are consistent,
modifying them as necessary.
 Drawing different diagrams that capture related, but
distinct, information will often highlight problems.
72 12/23/2024
Assignment 5
1. Why use a standard modeling language?
2. Draw a class diagram corresponding to the following
situations.
 An organization has three categories of employee:
professional staff, technical staff and support staff. The
organization also has departments and divisions. Each
employee belongs to either a department or a division
Assume that people will never need to change from one
category to another.
3. Compare and contrast Class diagrams versus entity-
relationship diagrams
 Reading assignment:
 Object Diagrams
 Aggregation and its hierarchy
 Composition and Interface
 Object Constraint Language (OCL)
73 12/23/2024