Role of UML (Unified Modelling Language)

“It is a general-purpose, developmental modeling language in the

field of software engineering that is intended to provide a standard
way to visualize the design of a system”

● UML is NOT a design methodology

● UML is a language for representing/expressing/documenting the
design created using some methodology

First View

❖ UML provides a set of notations, to visualise or to graphically model the system.

❖ It has it’s own syntax (symbols and sentence formation rules) and semantics (meanings of
symbols and sentences)
UML —

Agree on OOD

Different ways of going about - Different notational systems

Booch - Rumbaugh - Jacobson

Object Management Group (OMG) adopted UML in 1997, ISO in 2005
A standard representation of the Object Oriented Design
 User View - Usecase Diagram

● Represents the user perception

of the system
● How the user is going to use the
system?

● Between user and system (user

interactions to the system)
● Represents the different usage
scenarios of the system
● Created as part of usecase
analysis in requirements phase

Basic Components - Usecase Diagram

● Actors (stick figure)
● Usecases (Ellipse)
● System Boundary
● Relationship (lines and arrows)
Usecase Diagram Contd…

Class Diagram

Examples from the Lab

Please note that…

● Associate the actors and use cases -- there shouldn't be any actor
or use case floating without any connection
● Be careful on specifying relationships

Object Oriented paradigm

An approach to the solution of problems in which all computations are

performed in the context of objects.

○ The objects are instances of classes, which:

■ are data abstractions
■ contain procedural abstractions that operate on the objects

○ A running program can be seen as a collection of objects collaborating to perform a

given task

6
 Classes

A class:
○ A unit of abstraction in an object oriented (OO) program
○ Template or blueprint of objects

○ A kind of software module

■ Describes its object structure (properties)
■ Contains methods to implement their behaviour

10
 A View of the procedural and object-oriented
paradigms

Instance Variables
Variables defined inside a class corresponding to data present in each instance
○ Also called fields or member variables

○ Attributes
■ Simple data
■ E.g. name, dateOfBirth

○ Associations
■ Relationships to other important classes
■ E.g. supervisor, coursesTaken

14
Organizing Classes into Inheritance Hierarchies

●Super classes
○ Contain features common to a set of subclasses

●Inheritance hierarchies
○ Show the relationships among super classes and subclasses
○ A triangle shows a generalization

17

An Example Inheritance Hierarchy

●Inheritance
○ Subclasses implicitly have the features defined in its superclasses
 Polymorphism

●A property of object oriented software by which an abstract operation may

be performed in different ways in different classes.
○ Requires that there be multiple methods of the same name
○ The choice of which one to execute depends on the object that is in a variable
○ Reduces the need for programmers to code many if-else or switch statements

21

Abstract Classes and Methods

●An operation should be declared to exist at the highest class in the

hierarchy where it makes sense
○ The operation may be abstract (lacking implementation) at that level
○ If so, the class also must be abstract
■ No instances can be created
■ The opposite of an abstract class is a concrete class
○ If a super class has an abstract operation then its subclasses at some
level must have a concrete method for the operation
■ Leaf classes must have or inherit concrete methods for all
operations
■ Leaf classes must be concrete

22
Dynamic binding

●Occurs when decision about which method to run can only be made at run
time
○ Needed when:
■ A variable is declared to have a superclass as its type, and
■ There is more than one possible polymorphic method that could be run
among the type of the variable and its subclasses

25

Concepts that Define Object Orientation

●The following are necessary for a system or language to be OO

○ Identity
■ Each object is distinct from each other object, and can be referred to
■ Two objects are distinct even if they have the same data
○ Classes
■ The code is organized using classes, each of which describes a set of
objects
○ Inheritance
■ The mechanism where features in a hierarchy inherit from superclasses
to subclasses
○ Polymorphism
■ The mechanism by which several methods can have the same name and
implement the same abstract operation.
26
 UML Class Diagram
• A type of static structure diagram

• In the design of a system, a number of classes 
are identified and grouped together that 
helps to determine the static relations 
between them.

Essentials of UML Class Diagrams 
●The main symbols shown on class diagrams are: 
○ Classes
● represent the types of data themselves 
○ Attributes
● are simple data found in classes and their instances 
○ Operations
● represent the functions performed by the classes and their instances 
○ Associations
● represent linkages between instances of classes
○ Generalizations
● group classes into inheritance hierarchies 
 Associations and Multiplicity 
An association is used to show how two classes are related to each 
other. Symbols indicating multiplicity are shown at each end of the 
association

Labelling associations 
○ Each association can be labelled, to make explicit the nature of 
the association 
Analyzing 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 

Analyzing and validating associations
●Avoid unnecessary one­to­one associations
 Association classes 

Grade???

Association classes 
○ Sometimes, an attribute that concerns two associated classes 
cannot be placed in either of the classes 
○ The following are equivalent
 Generalization 
●Specializing a superclass into two or more subclasses
○ A generalization set is a labeled group of generalizations with a 
common superclass
○ The label (sometimes called the discriminator) describes the 
criteria used in the specialization

Relationships
 Composition
A composition is a strong kind of aggregation 
■ if the aggregate is destroyed, then the parts are destroyed as 
well 

Composition Example
 Abstract class
• When the concrete implementation of methods
are left for the subclasses.
• Can contain both abstract and non-abstract methods

Abstract class
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

Don’t be too disorganized. Don’t be too rigid either.

 SWE 2022-23

Object Diagrams
○ A link is an instance of an association
■ In the same way that we say an object is an instance of a class
A class diagram can generate an infinite number of object diagrams
 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.

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.
Three main types of Interaction Diagrams

● Sequence

● Timing

● Communication

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.
Sequence diagrams – an example

Sequence diagrams –
same example, more details
 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

Exercise:
A caller calls to his/her friend (Recipient): Complete the diagram by
choosing the appropriate messages.
 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

21

State diagrams – an example

○ tic-tac-toe game

22
State diagrams – an example with conditional
transitions

State diagram of a CourseSection class

25

Computations in State Diagram

○ Activities

○ Actions

26
 State diagram – an example with activity

29

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

30
 Nested substates

● A state diagram can be nested inside a state.

● The states of the inner diagram are called substates.

33

State diagram – an example with substates

34
 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.
○ Is used to understand the flow of work that an object or component performs

○ Graphical representations of workflows (performed by object or component) of

stepwise activities and actions with support for choice, iteration and
concurrency.

○ One of the strengths of activity diagrams is the representation of concurrent

activities.

37

Activity Diagram Notation

● Activity diagram uses rounded rectangles to imply

a specific system function
● Arrows to represent flow through the system.
● Decision diamonds to depict a branching decision
(each arrow emanating from the diamond is
labelled).
● Solid horizontal lines to indicate that parallel
activities are occurring.

38
 Representing concurrency

■ A fork has one incoming transition and

multiple outgoing transitions.
● The execution splits into multiple
concurrent threads.

41

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.

42
Activity Diagram Notation …..

45

Activity diagrams – an example

46
 49

Surprise Test – 4 Marks

● Consider a bulb with a push down switch. The bulb initially remains off.
When the switch is pushed down, the bulb is on. Again when the switch is
pushed up, the bulb turns off. The lifecycle of the bulb continues in this way
until it gets damaged.

Draw State Diagram – Give meaningful names for the states and the
events. Show the actions in each of the states.
Usecase

❖ A usecase represents one particular way the system

will be used.
❖ In general, a use case should cover the full sequence of
steps from the beginning of a task until the end.
❖ A use case should describe the user’s interaction with the
system and not the computations the system performs.
❖ A use case should only include actions in which the actor
interacts with the computer.

From the problem definition,

● Identify the actors
● Identify the usecases. Write down description
● Draw diagram indicating how they are related

Eg: Library System

Actors :- Borrower, Clerk
Borrower:
—
Search book
—
Place book on hold
—
Listing the books borrowed
.....
Clerk
—
All above usecase
—
Check out an item
—
Check in an item
—
........
Scenario

A scenario is an instance of a use case

•It expresses a specific occurrence of the use case
—a specific actor ...
—at a specific time ...
—with specific data.

—
While a usecase itself might drill into a lot of detail about every possibility,
a use-case diagram can help provide a higher-level view of the
system.
—
Use case diagrams can be a good communication tool for stake
holders.
Inclusions
• Allow one to express commonality between several different use cases.

• Are included in other use cases

—Even very different use cases can share sequence of actions.
—Enable you to avoid repeating details in multiple use cases.

• Represent the performing of a lower-level task with a lower-level goal.

Example of generalization, extension and

inclusion

12