Object modelling using UML
Object-oriented Concepts
• Basic Mechanisms:
– Objects:
• A real-world entity.
• Consists of data (attributes) and functions
(methods)
• Examples: an employee, a book etc.
2
Object-oriented Concepts
– Class:
• Collection of objects
• Template for object creation
• Examples: set of all employees, different types of
book
3
Object-oriented Concepts
– Methods and message:
• Operations supported by an object
• Means for manipulating the data of other
objects
• Sending message
• Examples: calculate_salary, issue-book,
member_details, etc.
4
Object-oriented Concepts
– Inheritance:
• Allows to define a new class (derived class) by
extending or modifying existing class (base class)
• Represents Generalization-specialization
relationship
5
Object-oriented Concepts
– Multiple Inheritance:
• Subclass can inherit attributes and methods from
more than one base class
• Multiple inheritance is represented by arrows
drawn from the subclass to each of the base classes
6
Object-oriented Concepts
LibraryMember Base Class LibraryMember Base Class
Derived
Faculty Students Staff Faculty Students Staff
Classes
Multiple
Inheritance
UnderGrad PostGrad Research UnderGrad PostGrad Research
7
Object
modelling using UML
– UML is a modelling language
– Unified Modelling Language (UML) is a general purpose
modelling language.
– The main aim of UML is to define a standard way to
visualize the way a system has been designed.
– It is quite similar to blueprints used in other fields of
engineering. UML is not a programming language, it is
rather a visual language.
– The visual language is a system of communication
using visual elements.
8
UML
– Based Principally on
• OMT [Rumbaugh 1991]
• Booch’s methodology[Booch 1991]
• OOSE [Jacobson 1992]
• Odell’s methodology[Odell 1992]
• Shlaer and Mellor [Shlaer 1992]
9
UML
OMT
UML
Booch
OOSE Methodology
Different object modelling techniques in UML
10
UML diagrams
– Nine diagrams to capture different views
of a system
– Provide different perspectives of the
software system
– Diagrams can be refined to get the actual
implementation of the system
11
UML diagrams
– Views of a system
• User’s view
• Structural view(static model)
• Behavioral view(dynamic)
• Implementation view
• Environmental view
12
UML diagrams
Behavioural View
Structural View - Sequence Diagram
- Class Diagram - Collaboration Diagram
- Object Diagram
- State-chart Diagram
- Activity Diagram
User’s View
-Use Case
Diagram
Implementation View Environmental View
- Component Diagram - Deployment Diagram
Diagrams and views in UML
13
Use Case MODEL
Consists of set of “use cases”
Different ways in which system can be used by
the users
Corresponds to the high-level requirements
14
Use Cases
– Normally, use cases are independent of each
other
– Implicit dependencies may exist
15
Example of
Use Cases
– For library information system
• issue-book
• Query-book
• Return-book
• Create-member
• Add-book, etc.
16
Representation of
Use Cases
– Represented by use case diagram
– Use case is represented by ellipse
– System boundary is represented by
rectangle
– Users are represented by stick person
icon (actor)
– Communication relationship
between actor and use case by line
17
• System
Draw your system's boundaries using a
rectangle that contains use cases. Place actors
outside the system's boundaries.
• Use Case
Draw use cases using ovals. Label the ovals
with verbs that represent the system's
functions.
• Actors
Actors are the users of a system. When one
system is the actor of another system, label
the actor system with the actor stereotype.
• Relationships
Illustrate relationships between an actor and a
use case with a simple line.
• For relationships among use cases, use
arrows labeled either "uses" or "extends." A
"uses" relationship indicates that one use case
is needed by another in order to perform a task.
• An "extends" relationship indicates
alternative options under a certain use case.
Example of
Use Cases
Play Move
Tic-tac-toe game
Player
Use case model
22
Example 1: Use Case Model
register
Customer customer Clerk
register
sales
Sales Clerk
select
winners
Supermarket
Prize scheme
Manager
23
Relationships of
Use Cases
– Represent common behavior across different
use cases
• Generalization
• Includes
• Extends
24
Factoring Using
Generalization
Pay membership fee
Pay through credit card Pay through library pay card
Use case generalization
25
Class diagram
– Describes static structure of a system
– Main constituents are classes and their
relationships:
• Generalization
• Aggregation
• Association
• Various kinds of dependencies
26
Class diagram
– Entities with common features, i.e. attributes
and operations
– Classes are represented as solid outline
rectangle with compartments
– Compartments for name, attributes &
operations
– Attribute and operation compartment are
optional for reuse purpose
27
Example of
Class diagram
LibraryMember LibraryMember LibraryMember
Member Name Member Name
Membership Number Membership Number
Address Address
Phone Number Phone Number
E-Mail Address E-Mail Address
Membership Admission Date Membership Admission Date
Membership Expiry Date Membership Expiry Date
Books Issued Books Issued
issueBook( );
findPendingBooks( );
findOverdueBooks( );
returnBook( );
findMembershipDetails( );
Different representations of the LibraryMember class
28
• Class name: begin with Uppercase
Object name: begin with lower case(student
Member)
Attribute: property of a class, and define the
data object might contain.
Association Relationship
Library Member
1 borrowed by * Book
Association between two classes
30
Aggregation Relationship
– Represent a whole-part relationship
– Represented by diamond symbol at the
composite end
– It can be transitive
31
Aggregation Relationship
1 * 1
Document Paragraph * Line
Representation of aggregation
32
Composition Relationship
– Life of item is same as the order
1 *
Order Item
Representation of composition
33
Class Dependency
Example: client and server
Dependent Class Independent Class
Representation of dependence between class
34
Coding
• Objective of coding phase:
– transform design into code
– unit test the code.
35
Code inspection and code walk
throughs
• After a module has been coded,
–code inspection and code walk
through are carried out
–ensures that coding standards
are followed
–helps detect as many errors as
possible before testing.
36
Code review
• Code review for a model is carried out after the
module is successfully compiled and the all the
syntax errors have been eliminated.
• Normally, two types of reviews are carried out on
the code of a module.
• These two types code review techniques are code
inspection and code walk through.
37
Code Walk Through
• A few members of the development team
select some test cases:
– simulate execution of the code by hand using these
test cases.
• Discussion should focus on discovery of errors:
– and not on how to fix the discovered errors.
38
• The main objectives of the walk through are to
discover the algorithmic and logical errors in the
code.
• The members note down their findings to discuss
these in a walk through meeting where the coder of
the module is present.
• The team performing code walk through should not
be either too big or too small.
– Ideally, it should consist of between three to seven
members.
39
Code Inspection
• In contrast to code walk through, the aim of code inspection is
to discover some common types of errors caused due to
oversight and improper programming.
• In addition to the commonly made errors, adherence to coding
standards is also checked during code inspection.
• Good software development companies collect statistics
regarding different types of errors commonly committed by
their engineers and identify the type of errors most frequently
committed.
• Such a list of commonly committed errors can be used during
code inspection to look out for possible errors.
40
Commonly made errors
• Use of uninitialized variables.
• Nonterminating loops.
• Improper storage allocation and deallocation.
• Actual and formal parameter mismatch in
procedure calls.
• Jumps into loops.
41
