Chapter 2

Basic Object Oriented Design

using Unified Modeling Language
(UML)
Outline

 Introduction to UML
 Importance of modeling
 Principles of modeling
 Object oriented modeling
 Overview of UML
 Structural Modeling
 Classes
 Relationships
 Diagrams
Outline (cont…)

 Behavioral Modeling
 Use cases
 Use case diagrams
Introduction

 Getting started is the most difficulty part of any new

process.
 In software modelling, the first thing you need to do is
understand what are you going to model and ultimately
develop.
 Creating a highest form details about a system--use case
diagram--is an almost natural point of origin for the
software design.
 A use case diagram is an excellent way to communicate
to management, customers, and other non-development
people what a system will do when it is completed.

4
Introduction to UML
UML – Introduction (cont…)

 What?
 A modeling language for visualizing, specifying, constructing and
documenting the artifacts of a software system.

 Why?
 UML is a industry standard modeling language.

 Where?
 Design phase (most of the time).

 How?
 That is what the subject is about.
UML Applicable Domains

 Enterprise information systems

 Banking and Financial services
 Telecommunications
 Transportation
 Defense
 Retail
 Medical electronics
 Scientific
 Distributed web-based services
Overview of UML

Visualizing

Documenting
UML Specifying

Constructing
UML is a Language for Visualizing

 Problems with non-standard modeling (textual):

 Communicating conceptual models to others is error-
prone unless everyone involved speaks the same
language.

 There are some things about a software system you

can't understand unless you build models.

 If the developer who created the code never wrote

down the models that are in his or her head, that
information would be lost forever.
UML is a Language for Specifying

 Specifying means building models that are precise,

unambiguous and complete.

 UML addresses the specification of all important

decisions regarding:
 Analysis
 Design
 Implementation
UML is a Language for Constructing

 UML models can be directly connected to various

programming languages such as Java, C#, VB etc.

 Forward engineering

 Reverse engineering

 Round trip engineering

Forward Engineering Example

Customer public class Customer

{
- cid private int cid;
- cname private String cname;
- mobile private String mobile;
- email private String email;

public void purchase( ) { … }

public void login( ) { … }
+ purchase( )
public void logout( ) { … }
+ login( )
public void search( ) { … }
+ logout( )
}
+ search( )
 Reverse Engineering Example

class Customer Customer

{
private int cid;
- cid
private String cname;
- cname
private String mobile;
- mobile
private String email;
- email
public void purchase( ) { … }
public void login( ) { … }
public void logout( ) { … } + purchase( )
public void search( ) { … } + login( )
} + logout( )
+ search( )
Roundtrip Engineering Example

Customer class Customer

{
private int cid;
- cid
private String cname;
- cname
private String mobile;
- mobile
private String email;
- email
public void purchase( ) { … }
public void login( ) { … }
+ purchase( ) public void logout( ) { … }
+ login( ) public void search( ) { … }
+ logout( ) }
+ search( )
UML is a Language for Documenting

 UML addresses the documentation of a system's

architecture and all of its details.

 UML provides a language for expressing

requirements and for tests.

 UML provides a language for modeling the activities

of project planning and release management.
Classes
 Classes

 A class is a collection of similar (attributes, operations,

relationships) objects.

 Classes are used to capture the vocabulary of the system.

 Class is represented as a rectangle in UML.

Classes - Example
 Classes - Name

 A class name is a textual string.

 Every class must have a name that distinguishes it from every

other class.

 A class name may contain alphabets, digits and underscore.

 A class name always starts with a uppercase letter.

Classes – Name (cont…)

Simple names

Path name
 Classes - Attributes

 An attribute is a named property.

 These attributes are similar for all the objects of the class.

 Graphically the attributes are listed in a compartment below the

class name.

 The first letter in the attribute name will be in lowercase and the
first letter of the rest of the words will be in uppercase.
 Classes – Attributes (cont…)

 Attributes may be represented only with names or along with the

type and an initial value.
 Classes - Operations

 An operation is an implementation of service that can be

requested from any object of the class to affect its behavior.

 These operations are similar for all the objects of the class.

 Operations are listed in a compartment below the attributes

compartment.
 Classes – Operations (cont…)

 An operation may be represented only with its name or along with

the parameters or with the return type.
Relationships
 Relationships

 The classes in the models generally collaborate with each other in a

number of ways.

 Most of the classes will have connections with other classes known as
relationships.

 Six main relationships:

 Dependency
 Generalization
 Association
 Aggregation
 Composition
 Realization
 Relationships - Example

Dependency

Generalization

Association
 Dependency

 A dependency is a relationship.
 Dependency is represented graphically
as a dashed directed line.
 The dependency is directed towards the
thing being used.
 One object dependent on the other
object. Example: object Event
dependent on object Window. Event
cannot occur independently without
Window.
 Example : object Channel dependent on
object FilmClip. Channel reliable on
FilmClip to occur
 29
Dependency – Example

Object Commission is dependent on the object Sale. If one salesperson made

no sales, he will gain no commission at all. His commission is based on how
much sales he could make for a period.
 Generalization

Example : shape is parent class for

 Generalization is often called as rectangle, circle and polygon. Square is a
“is-a” relationship. child to a rectangle
 Generalization is a relationship
between a general thing and a
specific thing.
 Generalization specifies that the
object of a child can be used at
any place where the object of the
parent is used.
 Generalization is represented as a
solid directed line with a large
open arrow head pointing
towards the general thing.
 Association

 An association is a structural relationship. It specifies that objects of one class are

connected to objects of another class.
 An association can be specified between two classes or between more classes.
 An association is represented graphically as a solid line connecting two things.
 Object can exist independently. Example : Subject and Lecturer can exist without
each other.
 Dialog box and Control can also exist independently. Control can exist in dialog
box or any interface.
 Association - Name

 An association can have a name. It specifies the type of relationship

between the things it is connecting.

 We can give a direction to the name by providing a direction triangle that

point in the direction you intend to read the name

 Person works for certain company.

 Or these object can exist independently. Person is self-employed, work at

home or housewife. Company does not need any more person or operated
on-line.
 Association - Role

 A class plays a specific role in an association relationship.

 The role is represented under the association and close to the class
icon.
 Association - Multiplicity

 While modeling, it is important to specify how many objects may be connected across
an association.
 That “how many” is known as the multiplicity of the association.
 35
Example :

One customer must have between one and five bank accounts

One bank account must belong to one up to two customers*.

One person can have many employer. Company can 1 or more employee
 Association - Aggregation

 While modeling, sometimes we might want to represent “Whole/Part”

relationship. In this relationship, one thing acts as whole, while the other
thing is a part of this whole thing.

 Such relationship is known as aggregation or also called as “has-a”

relationship.

 An aggregation is represented graphically by adorning an association

with a open diamond at the whole end.
Association – Aggregation (cont…)

• Weak relationship

• Department is part of Company

• Company can still exist even there

is no Department

• Never totally dependent on

Department

• Example : company has many

department. If company deleted,
department will not destroy.
 Association - Composition

• While modeling, sometimes we might want to

represent “Whole/Part” relationship. In this
relationship, one thing acts as whole, while the other
thing is a part of this whole thing.

• Such relationship is known as composition or also

called as “has-a” relationship.

• A composition is represented graphically by adorning

an association with a filled diamond-head at the
whole end.
Association - Composition

• Strong relationship
• Object dependent with one another
• College will never exist independent of Student
• College must have Student. Without Student, College
will be closed
 40
Realization

 This relationship is between a

class (or supplier) that defines Example : Student that realises an interface class
the functionalities and a class WWW. This relationship states that during the Week
Without Wall (WWW), a student must join and
(or client) that will realize or
organise events for their registered subjects
perform the functions.
 In OOP, this can be
represented by an interface
class as the supplier, and a
concrete class that implements
the interface as the client.
 One concrete class can
implement more than one
interface class.
Common Modeling Techniques -
Modeling Simple Dependencies

 To model this using relationship:

 Create a dependency pointing from the class with the operation to the
class used as a parameter in the operation.
Common Modeling Techniques -
Modeling Single Inheritance
Common Modeling Techniques -
Modeling Structural Relationships
Diagrams
 Diagrams

 Modeling (creating blueprints) is about creating a simplification

or abstraction of the end software system.

 Modeling involves creating different diagrams.

 A diagram is a collection of vertices and edges according to

graph theory (mathematics). In UML, these vertices are things
and edges are replaced with relationships.
 Diagrams (cont…)

Diagrams

Structural Behavioral
Diagrams Diagrams

Class Object Implementation Use Case State Chart Activity Interaction

Diagrams Diagrams Diagrams Diagrams Diagrams Diagrams Diagrams

Component Deployment Sequence Collaboration

Diagrams Diagrams Diagrams Diagrams
 Visibility

 The visibility feature of a classifier allows us to specify the

accessibility of a certain classifier feature.

 Four access specifiers in UML:

Symbol Name Description

+ Public Accessible by all other classifiers
# Protected Accessible only by the descendents and the classifier itself
~ Package Accessible by all the classifiers with the same package
- Private Accessible only by the classifier in which they are available
 Visibility - Example

Student

- sid
- sname private
- rollno
protected # email
# mobno
+ register( )
+ login( ) public
+ logout( )
Class Diagram
 Class diagram

 Class diagram is used to model the static design view of the

system.

 A class diagram contains:

 Classes
 Generalization, dependencies and associations
 Class diagram – Common Uses

 Class diagrams are commonly used for:

 Modeling the vocabulary of the system
 Modeling the relationships
 52
Class Diagram example
Object Diagram
 Object diagram

 An object diagram allows us to model the instances of classes in

a class diagram.

 Object diagrams are used to model the static design view of the
system.

 An object diagram contains:

 Objects
 Links
Class and Object Diagrams
Behavioral Modeling
 Behavioral Modeling

 Behavioral modeling involves modeling the dynamic aspects of

the software system.

 The dynamic aspects comprises of the behavior represented as:

 Messages
 States
 Activities and more…
Use Case Diagram
 Use Cases

 Use cases specify what the system does for its users.

 A use case specifies part of the functionality provided by the

system.

 Use case concept was introduced by Ivar Jacobson

Use Case Diagrams

 Use Case diagrams show the various activities the users can
perform on the system.
 System is something that performs a function.

 They model the dynamic aspects of the system.

 Provides a user’s perspective of the system.

60
 Use Cases (cont…)

 An use case is defined as “a set of actions performed by the

system, which produces an observable result that is, typically, of
some value to one or more actors or other stakeholders of the
system”.

 Use cases are connected to actors through associations.

 Use Cases (cont…)

 Use case is one of the classifiers in UML.

 An instance of use case is known as a scenario.

 Use case is graphically represented as a hollow ellipse.

Use Cases – Example

Order
Library :: Make
product
Reservation

Simple Names Validate Path Name

user
 Actors

 An actor is one which uses or interacts with the software system

(subject).

 Actor can be a person or another system (logical or physical).

 Use case is always initiated by an actor by sending a message.

 Actors (cont…)

 Actors are of two types:

 Active actors
 Passive actors

 Actor is graphically represented as a stickman or as a class

symbol stereotyped as actor.
Organizing Use Cases - Generalization
Use Case Diagrams

 Use case diagrams model the static use case view of a software
system.

 Specifies what the system does.

 Use case diagram contains:

 Use cases
 Actors
 Associations, dependencies and generalizations
Use Case Diagram – Example
Use Case Diagram – Example
 Example:
University Record System (URS)

 A University record system should keep information about

its students and academic staff.
 Records for all university members are to include their id
number, surname, given name, email, address, date of
birth, and telephone number.
 Students and academic staff each have their own unique ID
number: studN (students), acadN (academic employee)
 In addition to the attributes mentioned above:
 Students will also have a list of subjects they are enrolled in. A
student cannot be enrolled in any more than 10 subjects.
 Academic employees will have a salary, and a list of subjects
they teach. An academic can teach no more than 3 subjects.

70
Some Actions Supported by URS

 The system should be able to handle the following commands.

 Add and remove university members (students, and academic
staff)
 Add and Delete subjects
 Assign and Un-assign subjects to students
 Assign and Un-assign subjects to academic staff.

71
Use Case Diagram - URS System 72

URS
add member

system del member

academic
User/admin add subject

del subject

assg subject

unass subject

enrol subject

student
unenrol subject
Use Case Diagrams

 A set of ACTORS : roles of users can play in interacting with the

system.
 An actor is used to represent something that interacting to system.

 A set of USE CASES: each describes a possible kind of interaction

between an actor and the system.
 Uses cases are actions that a user takes on a system

 A number of RELATIONSHIPS between these entities (Actors and

Use Cases).
 Relationships are simply illustrated with a line connecting actors to use
cases.

73
Use Case Diagrams - Actors

 An actor is a user of the system playing a particular role.

 Actor is shown with a stick figure.
 An actor is named with a noun using capitalisation-case style
such as Customer, Workstation or Bank.

Employer Employee Client

74
Use Case Diagrams – Use Cases

 Use case is a particular activity a user can do on the system.

 Is represented by an ellipse.
 Following are two use cases for a library system.
 A “verb + noun” phrase is used to name a use case such as
Check (verb) Balance (noun)

Borrow book Reserve book

75
Use Case Diagram – Example1 (Library) 76

library system

Borrow book

client employee
Reserve book

Order title

Fine payment
supplier

A Library System.
Use Case Diagram for Student 77
Assessment Management System

Grade system
Record
grades

Student
View grades

Teacher Distribute
Report cards

Create report
cards
Printing administrator
 Use Case Vs Scenarios

 Each use case is one or more scenarios.

 Add Subject Use Case :
 Scenario 1 : Subject gets added successfully.
 Scenario 2 : Adding the subject fails since the subject is
already in the database.
 Enroll Subject Use Case:
 Scenario 1 : Student is enrolled for the subject.
 Scenario 2 : Enrollment fails since the student is already
enrolled in the subject.

 Each scenario has a sequence of steps.

78
Scenarios

 Each scenario has a sequence of steps.

 Scenario 1 : Student is enrolled for the subject.
 Student chooses the “enroll subject” action.
 Check the student has enrolled in less than 10 subjects.
 Check if the subject is valid.
 Assign the subject to the student.

79
Scenarios

 Each scenario has a sequence of steps.

 Scenario 2 : Enrolling fails since the student is already
enrolled in 10 subjects.
 Student chooses the “enroll subject” action.
 Check the student has enrolled in less than 10 subjects.
 Return an error message to the student.

80
Use Case Diagrams - Relationships

 Inclusion
 Inclusion enables to reuse one use case's steps inside another
use case.

 Extension
 Allows creating a new use case by adding steps to existing
use cases

 Generalization
 Allows child use cases to inherit behavior from parent use
cases

81
 82
Links

interactions between actors and use cases, and between use cases themselves
<<include>>
indicates a use case (or base) needs to use functionality of another use case (or child) to
perform its task
Apply <<include>>
Check
Driving Qualification
License

<<extend>>
link means optional operations for a certain use case

<<extend>>
Order Search
Foods Package
 83
Use Case Example
(self service machine)

Self service machine

Buy a product
Self service machine
customer
Collect Money

Collector
Self service machine

Restock

Supplier
 84

• use cases Reserve Car (the base) and

Buy Insurance (the child) are connected
using an <<extend>> link.
• base has an optional operation defined by
the child.
• a client is given an option to buy
insurance while booking a car.

• use cases Generate Bills (the base)

and Calculate Payment (the child)
are connected using <<include>>
link.
• the base requires another
functionality from the child.
• calculating payment based on the
type of client has to be done before
a bill can be generated