Software Engineering

Mattu University
Engineering and Technology College
Department of Computer Science

Software Engineering

Target Dept.:- Computer Science 3rd year Regular

Prepared by: Diriba.G (MSc in CSE)

 Chapter Two

Unified Modelling Language(UML)

Engineering and Technology College Mattu University

 Overview of UML
 What UML stands for?
 Why do you need to learn UML?

 UML stands for Unified Modelling Language.

 UML is a standard language for specifying, visualizing, constructing, and

documenting the artifacts of software systems.
 UML is different from the other common programming languages like
C++, Java, and COBOL etc.
 UML is a pictorial language used to make software blue prints.

 UML is generally used to model software systems but it is not limited within
this boundary. It is also used to model non software systems as well like
process flow in a manufacturing unit etc.
 Basics of UML
 During the early 1990s, there were around 50 O-O methodologies

among them:
 Rumbaugh’s Object Modelling Technique (OMT): Class and Associations

 Shlaer-Mellor (Object-Oriented Analysis/Design (OOA/D),

 Booch Method : Categories and Subsystems

 Wirfs-Brock(Class/Responsibility/Collaboration)CRC,

 Coad/Yourdon Methodology : Class, Object, Class-&-Object

 Jacobson Object-Oriented Software Engineering (OOSE): Use case driven

 The Need for Standardization

 There are many methods and notations competing with each other that users are
distracted by the decisions they need to make.
Cont’d…
 A single, common language is desirable because it can be used for all

development methods, used throughout the project lifecycle, and used for
different application technologies.

 The Unification

 Based on the fact that differences between the various methods were
becoming smaller.

 Jim Rumbaugh and Grady Booch decided at the end of 1994 to unify
their work within a single method: the Unified Method.

 A year later they were joined by Ivar Jacobson and the Unified Method
was transformed into UML- the Unified Modelling Language.
 Goal of UML
 A picture is worth a thousand words, this absolutely fits while discussing about
UML.

 UML diagrams are not only for developers but also

 for business users,
 common people and
 anybody interested to understand the system.
 So it must be clear that UML is not a development method rather it accompanies
with processes to make a successful system.

 The goal of UML can be defined as a simple modelling mechanism to model

all possible practical systems in today’s complex environment.
 Where can the UML be used?

 A conceptual model of UML:

 A conceptual model can be defined as a model which is made of concepts and their
relationships.

 A conceptual model is the first step before drawing a UML diagram.

 It helps to understand the entities in the real world and how they interact with
each other.

 Conceptual model of UML can be mastered by learning the following

three major elements:

 UML building blocks

 Rules to connect the building blocks

 Common mechanisms of UML

 Building Block of UML
 UML Building Blocks: The building blocks of UML can be
defined as:
1. Things
2. Relationships
3. Diagrams

1. Things – the abstractions

 Things: are the most important building blocks of UML. Things can be:

A. Structural
B. Behavioural

C. Grouping

D. An notational //adding of notes

Cont’d…
A. Structural things
 The Structural things define the nouns, static part of the model.

 They represent physical and conceptual elements.

 Following are the brief descriptions of the structural things.

 Class:

 Class represents set of objects having similar responsibilities.

 Interface:

 Interface defines a set of operations which specify the responsibility of a

class.
Cont’d…

Collaboration:

 Collaboration defines interaction between elements.

 Component:

 Component describes physical part of a system.

 Node:

 A node can be defined as a physical element that exists at run time.

Cont’d…
B. Behavioral things:
 A behavioral thing consists of verbs, dynamic, represent behavior over
time and space(State of object/class change from time to time)
Following are the behavioral things:

 Interaction:
 Interaction is defined as a behavior that consists of a group of
messages exchanged among elements to accomplish a specific task.

 State machine:.(Waiting, sleeping)

 State machine is useful when the state of an object in its life cycle is
important. It defines the sequence of states an object goes through
in response to events. Events are external factors responsible for
state change.
Cont’d…
C. Grouping things:
 A grouping thing can be defined as a mechanism to group elements of a UML
model together.
 There is only one grouping thing available:
 Packages:
 Package is the only one grouping thing available for gathering structural and
behavioural things.
D. Annotation things:
 Annotation things can be defined as a mechanism to capture remarks,
descriptions, and comments of UML model elements. Note is the only one an
notational thing available.
 Note: is used to render comments, constraints etc. of an UML element.
Cont’d…
2. Relationships – tie things together
 Relationship is another most important building block of UML.

 It shows how elements are associated with each other and this
association describes the functionality of an application.
 There are four kinds of relationships available.

1. Dependency:
2. Association
3. Generalization
4. Realization
Cont’d…
 Dependency (uses):
 Dependency is a relationship between two things in which change
in one element also affects the other one.

 Association
 Association is basically a set of links that connects elements of an
UML model. It also describes how many objects are taking part in
that relationship.
Cont’d…
 Generalization (is-a):
 Generalization can be defined as a relationship which connects a
specialized element with a generalized element.
 It basically describes inheritance relationship in the world of
objects.

 Realization:
 Realization can be defined as a relationship in which two elements
are connected. One element describes some responsibility which is
not implemented and the other one implements them. This
relationship exists in case of interfaces.
Cont’d…
A sematic relationship between classifier where in one classifier specify the
contract that another classifier is guaranteed to carry out.

Valida Validate
tion users

Here validate users is an action( why?) in which validation is realized on and

represented by use cases
3. Diagram
 Diagrams is the graphical representation of a set of elements and

help to visualize a system from different perspectives(angles)

 May contain any combination of things and relationships
 UML diagrams includes
 Modelling with UML
Why modelling?
 To simplify the system
 For better understanding
 For documentation
 To provide template
An overview of UML diagram
1. Use case diagram
2. Sequence diagram
3. Class diagram
4. State-chart diagram
5. Activity diagram
6. Component diagram
7. Deployment diagram
 1. Use case Diagram
 Use cases are used during requirements elicitation and analysis to
represent the functionality of the system.
 Use cases focus on the behaviour of the system from an external
point of view.
 Use case diagrams are consists of actors, use cases and their
relationships.
 A use case describes a function provided by the system that yields a
visible result for an actor.
 An actor describes any entity that interacts with the system (e.g., a
user, another system, the system’s physical environment).
 The diagram is used to model the system/subsystem of an
application. A single use case diagram captures a particular
functionality of a system.
 So to model the entire system numbers of use case diagrams are used.
Cont’d…
Use case Diagram Notations
Cont’d…
1. Use case Notation:
 Use case is represented as an eclipse with a name inside it. It may
contain additional responsibilities.
 A set of scenarios that describes an interaction between a user and a
system, including alternatives.

 A use case describes what a system does; not how.

Cont’d…
How to find Use Cases?
 What are the system tasks for each actor you have identified?

 Does the actor need to be informed about certain occurrences in

the system?
 Will the actor need to inform the system about sudden, external
changes?
 Does the system supply the business with the correct behaviour?

 Can all features be performed by the use cases you have identified?

 What use cases will support and maintain the system?

 What information must be modified or created in the system?

Cont’d…
2. Actor Notation:
 An actor define roles that users can play.
 An actor can be defined as some internal or external entity that
interacts with the system.
 An actor is anything that exchanges data with the system.
 An actor can be a user, external hardware, or another system.
 An actor is shown as a stick figure in a use case diagram depicted
"outside" the system boundary.

Doctor Patient Student

Cont’d…
 How to find Actor ?
 Actors:
 Supply/use/remove information

 Use the functionality.

 Will be interested in any requirement.

 Will support/maintain the system.

 The system’s external resources.

 The other systems will need to interact with this one.

Cont’d…
Documenting Actor characteristics
 Brief Description:
 What or who the actor represents?
 Why the actor is needed?
 What interests the actor has in the system?
 Actor characteristics might influence how the system is developed:

 The actor's scope of responsibility.

 The physical environment in which the actor will be using the
system.
 The number of users represented by this actor.
Cont’d…
3. Relationship Notation:
 Relationships between actors and use cases
 are represented by directional or non-directional edges
 May relate two use cases
 May relate two actors, or

 May relate a use case and an actor

Cont’d…
The purposes of use case diagrams can be as follows:
 Used to gather requirements of a system.

 Used to get an outside view of a system.

 Identify external and internal factors influencing the system.

 Show the interacting among the requirements are actors.

Cont’d…
Cont’d…
What is the difference with the previous use case? Ans:R/ship between
use case and Privacy between Actor and use case!

Sell Item

Reorder
<<Includes>>
Sales Clerk
Login

Add to Stock
<<Includes>>

<<Includes>>

Generate
Report

Manager
Cont’d…
 Example2:Use case diagram representing the order management
system.
 So if we look into the diagram then we will find three use cases (Order, Special-order
and Normal Order) and one actor which is customer.
 The Special-order and Normal Order use cases are extended from Order use case. So
they have extends relationship.
 Another important point is to identify the system boundary which is shown in the
picture.
Cont’d…
 Uses Cases can be related
 Extends Relationship
 To represent seldom invoked use cases or exceptional
functionality
 Denoted as dashed lines or paths with an open arrow-head
pointing an extension use case
 Includes Relationship

 To represent functional behavior common to more than one use

case.
 Denoted as dashed lines with an open arrow-head pointing at the
inclusion use case and are labelled with the <<include>>
keyword (stereotype).
Cont’d…
 <<extends>> relationships model
exceptional or seldom invoked cases
 The exceptional event flows are factored
Passenger out of the main event flow for clarity
 The direction of an <<extends>>
relationship is to the extended use case
 Use cases representing exceptional flows
PurchaseTicket can extend more than one use case.

<<extends>>

<<extends>>
<<extends>>
OutOfOrder <<extends>> TimeOut

Cancel NoChange
Cont’d…
 <<includes>> relationship represents
common functionality needed in more
than one use case
Passenger  <<includes>> behavior is factored out
for reuse, not because it is an exception
 The direction of a <<includes>>
relationship is to the using use case
PurchaseMultiCard (unlike the direction of the
PurchaseSingleTicket <<extends>> relationship).

<<includes>>

CollectMoney
<<extends>> <<extends>>
<<extends>>

NoChange Cancel Cancel

Cont’d…
Cont’d…

 Pay Bill is a parent use case and Bill Insurance is the child use case.

(generalization)

 Both Make Appointment and Request Medication include Check

Patient Record as a subtask.(include)

 The extension point is written inside the base case

 Pay bill; the extending class Defer payment adds the behaviour of

this extension point. (extend)

Cont’d…
Use Case Documentation / Description

 The Use Case documentation needs information like:

 List of Actors

 List of Business Rules (BR)

 List of User Interfaces (UI)

 The template will be the same as the essential use case

documentation except that the “Include” and “Extend” part will be

exercised (included) at this level.
Cont’d…
 Use Case Description for login
Cont’d…

 Use Case Description for Sell item

Cont’d…
General steps in Use case Modelling
 Identify actors from problem definition
 Identify use cases
 Identify relationships
 Use symbols for representing use cases and actors with in a
boundary
 Define use case description
 2. Sequence Diagram
 Sequence diagrams are used to formalize the behavior of the system and to visualize

the communication among objects.

 A sequence diagram is an interaction diagram. From the name it is clear that the

diagram deals with some sequences, which are the sequence of messages flowing
from one object to another.
 The sequence diagrams includes:-
 The actor who initiate the use case.

 The object which accept the flow of action.

 The arrow in which the starting and ending point of action is identified.

 The iteration loop in which process repeatedly checked until the required data is
matched.
Cont’d…

Basic symbols and components

Cont’d…

Basic symbols and components…

Cont’d…

Basic symbols and components…

Cont’d…
Message and Actions
 A message is a communication between two objects, or within an object, that is
designed to result in some activity.
 This activity involves one or more actions, which are executable statements that result
in
 changes in the values of one or more attributes of an object,
 or the return of some value(s) to the object that sent the message,
 or both

 There are 5 kinds of actions that the UML explicitly supports: -

 Call and Return
 Create and Destroy
 Send
Cont’d…
Common Message Symbols
Cont’d…
 Call action
 the sender assumes that the receiver is ready to accept the message,
 and the sender waits for a response from the receiver before proceeding

 Return action
 A return action is the return of a value to the caller, in response to a call
action
Cont’d…
Common Message Symbols…
Cont’d…
Common Message Symbols…
Cont’d…
 Create action
 A create action creates an object
 It tells a class to create an instance of itself

 Destroy action
 A destroy action destroys an object
 It tells an object to destroy itself
 An object can perform a destroy action on another object, or on itself
Cont’d…
 Send action
 A send action sends a signal to an object
 A signal is an asynchronous communication between objects
 One object “throws” a signal to another object that “catches” the signal
 The sender of the signal does not expect a response from the receiver (unlike
the sender of a call action)
 Exceptions are the most common type of signals

 In the UML, a send action is represented as an arrow with a half

arrowhead at the lifeline of the receiving object

: Class Object: Class

action name
Cont’d…
 Example 1: - Modelling a sequence diagram for the log-in use case
from the on-line Bookstore Case Study.
The main-flow of events that are involved is: -
1. The CUSTOMER clicks the Log-in button on the Home Page.
2. The system displays the Log-in Page.
3. The CUSTOMER enters his/her user ID and password. The
CUSTOMER clicks the OK button.
4. The system validates the log-in information against the ACCOUNT
table in the database.
5. CUSTOMER is an authorised user; the system displays the Personal
Home Page to the CUSTOMER
Cont’d…
Cont’d…
There are 3 types of analysis classes:
• boundary classes
• entity classes
• control classes
Instances of each of these analysis classes are called objects.
1. Boundary objects
• is an object with which an actor associated with a use case
interacts.
• if the actor is human, the boundary object may be a window,
screen, dialog box, or menu
• if the actor is non-human, the boundary object may be
application program interfaces (APIs)

boundary object
Cont’d…
2. Entity objects
• is an object that contains long-lived information, such as that
associated with databases.
• will be mapped to a table (part of the database) in the design phase

entity object
3. Control objects
• is an object that embodies application logic
• correspond with system actions (not actions taken by actors)
• are often used to handle things such as coordination and sequencing
• are also useful for calculations involving multiple entity objects

control object
Cont’d…

 Using the previous example (the log-in use case of the Online
Bookstore), we can identify that
 the HomePage and Log-in Page objects are boundary objects,
 whereas the Account object is an entity object.
 Therefore, taking this into account, we can draw a new interaction
diagram.
Cont’d…
Cont’d…
 Use Case: Register
 Main flow of events:
1. The CUSTOMER clicks the REGISTER button on the Home Page.
2. The system displays the Register Page.
3. The CUSTOMER enters all of the required information.
4. The CUSTOMER clicks the SEND button.
5. The system checks that all of the required information were entered.
If
yes, the system update the CUSTOMER’s record in the CUSTOMER
and ACCOUNT tables in the database. System displays OK message.
 Objects:-
 CUSTOMER: actor
 CUSTOMER and ACCOUNT: entity objects
 Home Page and Register Page: boundary objects
Cont’d…
Cont’d…
 Case Study: Order Books
 Main Flow of events: -
1. The CUSTOMER enters the keyword for a book and clicks
the
SEARCH button on the personal Home Page.
2. The system displays the matching books on the web Page.
3. The CUSTOMER chooses the desired book and clicks the
ADD TO
SHOPPING CART button on the web page.
4. The system adds the book into the CUSTOMER’s Order
table in the
database.
 Objects:
 Customer: actor
 Home Page: boundary object
 Book and Order: entity object
 3. Class Diagram
 We use the class diagram to model the static structure of a system,

 thus Class diagram describing the elements of the system and the

relationships between them.

 These elements and the relationships between them do not change

over time.
 For example, students have a name and ID number and attend various courses.

 The class diagram is without doubt the most widely used UML diagram.
Cont’d…

Objects
 A system contains numerous different individuals.

 Individuals might be not only persons but also animals, plants,

inanimate objects, artifacts, etc. that can be identified uniquely.

 For example, as part of her IT Studies program, Helen Lewis attends the lecture
Object-Oriented Modelling (OOM) at the university.

 Helen Lewis, IT Studies, and Object-Oriented Modelling are individuals

(concrete objects) in a university administration system and are in a relationship
with one another.
Cont’d…
Objects…

Example of an object diagram

Cont’d…

Classes

 A class is the construction plan for a set of similar objects that appear

in the system to be specified.

 Classes can characterize, for example, persons (e.g., students), things

(e.g., buildings), events (e.g., courses or exams), or even abstract

concepts such as groups.

 In object-oriented programming languages like Java, programs are

created based on classes.

Cont’d…

Classes…

Definition of a class in UML and Java.

Cont’d…
Class Notation …
 In a class diagram, a class is represented by a rectangle that can be
subdivided into multiple compartments.
 The first compartment must contain the name of the class, which
generally begins with a capital letter and is positioned centred in bold
font.

representation of class and its characteristics

Cont’d…
Attributes…
 An attribute has at least a name.

 The type of the attribute may be specified after the name using : Type.

 Possible attribute types include primitive data types, such as integer and string,
composite data types, for example a date, an enumeration.
Operation…
 Operations are characterized by their name, their parameters, and the type of their
return value.
 When an operation is called in a program, the behaviour assigned to this operation
is executed.
 In a class diagram, the operation name is followed by a list of parameters in
parentheses.
Cont’d…
Visibilities of attribute and operation can be explained in below table
Cont’d…
Example 1(see the #Sign in front of attribute and operation)
Cont’d…
Class relationships
Cont’d…
Class relationships…
 Association: Associations are similar to classes, in that
they can have attributes and operations attached to them.
 Relationship between two or more to involve connection.
Cont’d…
Class relationships…
 Aggregation: Relationships between the whole and components
(specific).
Cont’d…
Class relationships…
 Composition: The composition relationship is represented by a straight line with a
black diamond at one end. In UML, it can exist between two or more classes. It is a part
of the association relationship.
Cont’d…
 Generalization (inheritance): The relationship between
superclass and subclass.

 Dependency: Change in one class can change (affect) the

behavior of another class
Cont’d…
Creating a class diagram
Ex: Information system of a university
 A university consists of multiple faculties which are composed of
university various institutes. Each faculty and each institute has a
name. An address is known for each institute.
 Each faculty is led by a dean, who is an employee of the university.
 The total number of employees is known. Employees have a social
security number, a name, and an e-mail address. There is a distinction
between research and administrative personnel.
 Research associates are assigned to at least one institute. The field of
study of each research associate is known. Furthermore, research
associates can be involved in projects for a certain number of hours,
and the name, starting date, and end date of the projects are known.
Some research associates teach courses. They are called lecturers.
 Courses have a unique number (ID), a name, and a weekly duration in
hours.
Cont’d…
1. Identifying the classes
 First, we must identify the elements that occur in the system
University( identify the classes)
Cont’d…
2. Identifying their attributes
 We can now describe our classes in more detail using attributes.
Cont’d…
3. Identifying the relationship between classes
 Classes can be linked with one another in three ways. They can be in a sub-
/superclass relationship (generalization), be related by means of an aggregation, or
linked via associations.
 4. State chart Diagram
 It describe the behavior of an individual object as a
number of states and transitions between these states.
 A state represents a particular set of values for an object.
 Consists state, transition, events and activities.
 We have start and exit objects/states.
 A state is a condition that an object satisfies.
Cont’d…
Basic components of a state-chart diagram –
 Initial state – We use a black filled circle represent the initial state of
a System or a class.

 Transition – We use a solid arrow to represent the transition or

change of control from one state to another.

 State – We use a rounded rectangle to represent a state. A state

represents the conditions or circumstances of an object of a class at an
instant of time.
Cont’d…
 Fork – We use a rounded solid rectangular bar to represent a Fork
notation with incoming arrow from the parent state and outgoing
arrows towards the newly created states.

 Join – We use a rounded solid rectangular bar to represent a Join

notation with incoming arrows from the joining states and outgoing
arrow towards the common goal state.
Cont’d…
 Self transition – We use a solid arrow pointing back to the state itself
to represent a self transition.

 Composite state – We use a rounded rectangle to represent a

composite state also. We represent a state with internal activities using
a composite state.

 Final state – We use a filled circle within a circle notation to

represent the final state in a state machine diagram.
Cont’d…
Steps to draw a state-chart diagram
 Identify the initial state and the final terminating states.

 Identify the possible states in which the object can exist (boundary

values corresponding to different attributes guide us in identifying

different states).

 Label the events which trigger these transitions.

Cont’d…

Example: Airport Check-in

 5. Activity Diagram
 An activity diagram describes a system in terms of
activities.
 Activities are states that represent the execution of a set of
operations. The completion of these operations triggers a
transition to another activity.
 Activity diagrams are similar to flowchart diagrams in
that they can be used to represent control flow (i.e., the
order in which operations occur) and data flow
 Activity diagram Shows the flow of information activities
using, flow controls.
Cont’d…
 Activity Diagram Symbols
Cont’d…
 Activity Diagram Symbols …
Cont’d…
 Activity Diagram Symbols …
Cont’d…
 Activity Diagram Symbols …
Cont’d…
Cont’d…
Example to illustrate the activity of performing selling
an item to a customer.
 6. Component Diagram
 A component diagram, describes the organization and
wiring of the physical components in a system.
 It provides: Components and Interfaces
 Component – communicate with another component through its
interface.

Component

interface
Cont’d…
 Component Diagram shapes and symbols
Cont’d…
 Component Diagram shapes and symbols…
Cont’d…
 Component Diagram shapes and symbols…
Cont’d…
 Components can represent:
 Files (source code) or Help file
 Tables (data base)
 Applications
 Server
 Clients
Cont’d…
Example: online student registration system
data access
Admission officer
admission officer
<<infrastructure>>
access option security

data access
Registration
Registration

<<application>> data access

Edit
admission officer edit

data access
Grade Submission/Report <<infrastructure>>
Grade submition/report persistence persistence

data access
Transfer case
Transfer case

data access Withdrawal/clearance

Withdrawal case

data access
Add and Drop case DB
Add and Drop

MEU Registrar

Fig . component diagram for MEUOSR system

 7. Deployment Diagram

 deployment diagram describes the physical deployment of

information generated by the software program on hardware
components.
 Show:
 the hardware for the system,
 the software that is installed on that hardware, and
 the middleware used to connect separate machines on one another.
Client Interface
Web server
End user
Security
Browser

DB server Appn.java

Database
 Cont’d…

 Deployment diagram symbols and notation

 Cont’d…

Ex: Deployment diagram

Cont’d…
 Cont’d…

Ex: Deployment diagram for Apple iTunes applications

 Cont’d…
 The iTunes setup can be downloaded from the iTunes website,

 and also it can be installed on the home computer.

 Once the installation and the registration are done, iTunes application
can easily interconnect with the Apple iTunes store.

 Users can purchase and download music, video, TV serials, etc. and
cache it in the media library.

 Devices like Apple iPod Touch and Apple iPhone can update its own
media library from the computer with iTunes with the help of USB
or simply by downloading media directly from the Apple iTunes store
using wireless protocols, for example; Wi-Fi, 3G, or EDGE.
 Diagram Extension

 UML provides a number of extension mechanisms enabling the

modeler to extend the language.
 In this section, we describe two such mechanisms, stereotypes and
constraints.
 A stereotype is a string enclosed by angle brackets (e.g.,
<<subsystem>> ), which is attached to a UML element, such as a
class or an association. This enables modelers to create new kinds of
building blocks that are needed in their domain. For example, during
analysis, we classify objects into three types: entity, boundary, and
control.
 A constraint is a rule that is attached to a UML building block. This
allows to represent phenomena that cannot otherwise be expressed
with UML
Cont’d…

Examples of stereotypes (UML class diagram)

Examples of constraint (UML class diagram)

End of Chapter Two