Chapter - 7: Object Oriented Design Using UML

Chapter - 7
Object Oriented Design Using UML

INTRODUCTION
 Object-oriented technology has received significant

attention in the software industry in the recent years.
 A variety of object-oriented programming languages have
been developed in the industry.
 The reason behind the popularity of object-oriented
technology is the important consideration of objects,
which are independent entities in the real world rather
than producers as in function-oriented design.
 Object-oriented design is centered at object modeling,
which is developed with strong engineering discipline.
2
OBJECT-ORIENTED ANALYSIS AND DESIGN
 Object-oriented analysis and design (OOAD) is a combined

approach to problem analysis and designing the solution.
 The OOAD method is strongly supported by a sound engineering
science called modeling.
 A model is an abstract representation of a system that enables
software engineers to understand the problem of an application
and to design the solution for the system.
 Modeling supports both application domain and the solution
domain.
 The application domain represents the real world situation of the
system but it is sometimes very difficult to clearly understand the
application domain to define the problem in a complete and
correct manner.
 The solution domain represents the system design specifications
that lead to the system implementation.
3
 OOAD has two important aspects, viz., object-oriented

analysis (OOA) and object-oriented design (OOD).
 Object-oriented analysis is concerned with the modeling of
the application domain.
 It focuses on the understanding of the physical environment,
stakeholders, processes, etc. Object-oriented design is
concerned with the modeling of the solution domain.
 Object- oriented design models include system design and
object design.
 Object-oriented design is converted into the implementation
of the system. Object-oriented software development
employs OOA and OOD for system implementation.
4
 Object-oriented software development concentrates on

producing better quality products that are able to provide
the following features:
◦ They are easier to maintain.
◦ It’s easier to include changing requirements in them.
◦ They promote reusability.
◦ They have great emphasis on modeling and design.
5
Table 7.1: OOA, OOD and OO implementation
Object-oriented analysis Object-oriented design OO implementation
- Focuses on the - Focuses on the solution - Focuses on object-
application domain for domain oriented
problem analysis programming
- Employs modeling
- Employs modeling tools tools for system and - Employs object-
for understanding the object design oriented
physical scenario programming
- Includes operations
languages for coding
- Includes objects and and attributes
and packaging
their interactions
- Covers nonfunctional
- Includes definitions of
- Mostly covers functional requirements
data and operations
requirements
- Adds implementation-
- Covers functional and
- Adds customer-specific specific details
nonfunctional features
views
- Adds platform-
specific details
6
Benefits of Object-Oriented Development
 Accelerates development and maximizes the
productivity.
 Easy maintenance and enhancement.
 Supports reuse.
 Reduces complexity.
 Improves quality.
 Robustness.
 Provides tool support.
 Improves team communication.
 Security and integrity of data.
7
OBJECT ORIENTED CONCEPTS
OBJECTS
 An object is a concrete entity or a thing that exists in the
real world or in an abstract way; for example, files,
employees, trains, television, cash, invoice, component,
node, guidelines, tax, etc.
 It can be characterized by definite values and actions.
Each object has its own responsibility. Each object
possesses state, behavior, and identity.
 State describes the static structure of an object, which
persists throughout its lifespan.
 The static structure is defined by its inherent properties
that an object encompasses at any given point of time.
8
Object State
 An object is defined by its attributes and a set of values.
The values have some type that may change over time.
 For example, a person has his name, age, height, weight,
residence, and qualification
Joe : Person
Joe is an object of type Person
Name : string
Age : int
Height : decimal
Weight : decimal
Residence : string
Properties of Person type objects
Qualification : string
9
Object Behavior
 Each object performs certain operations (positive or
negative) depending on its state and values.
 It means that each object behaves differently at different
times. Thus, state and its operations together define the
behavior of an object.
 Each object in a state has certain role in which it performs
responsibilities.
10
Object Behavior
 The different roles of Joe are illustrated in Figure Given
Below
Joe: Doctor Joe: Customer Joe: Driver Joe: Passenger

-Reg. number : string -Acount number : string -Lisence number : string -Passenger number : string
-Specialty : string -Branch : string -Vehicle number : void -Mode of transport : string
-Qualification : string -Address : string -Location : string -Source station : string
-Hospital : string -Account type : string -Speed : decimal -Destination station : string
+checkup() +Openaccount() +Driving() +Reservation()
+Diagnose() +Withdraw() +Register() +Cancellation()
+Supervise() +Deposit() +Followrules() +Enquiry()
11
Object Identity
• Identity helps to uniquely identify an object in the real
world.
• It contains certain values.
Joe : Person Bob : Person

Age : int = 22 Age : int = 22
Height : decimal = 5.2" Height : decimal = 5.6"
Weight : decimal = 47 kg Weight : decimal = 49
Qualification : string = MS Qualification : string = CA
Residence : string = MA Residence : string = USA
12
CLASSES
 A class is a set of objects that share a common structure,
common behavior, common relationships with other objects,
interactions, and common semantics.
 A class has common attributes and operations.
 Attributes are the properties of a class. An attribute is the
data value held by an object of the class.
 An operation is a service that can be requested by an object
in a class.
 An operation is implemented through methods of
programming languages. Each operation has a name, signature,
and its return type.
 A signature specifies the number and type of arguments
required to implement the operation.
13
CLASSES
 The properties and operations of a class can be shared by

other classes. A class can be refined into child classes
known as subclasses.
 A class that provides services to its subclass or other
classes is known as a superclass. A class allows other
classes to access services in a restricted manner.
 In UML, visibility is used for the implementation of
private, public, and protected access specifiers that inherit
the services from their superclass. “#” is used for
protected, “+” for public, and “–“ for private data and
operations of a class.
 Private access allows data to be accessed only by the class
itself.
14
CLASSES
 A typical structure of a class has three parts, viz., name,

attributes, and operations.
 An example of a class “Customer” for a retail store is
shown in Figure Given below.
Customer
Class name +Customer Name : String
-Customer ID : Integer Class attributes
#Address : String
-Mobile number : Single
#Register() : int
+Purchase() : float
-Edit() : string
-Delete() : string Class methods
-Close() : int
15
ABSTRACTION
 Abstraction focuses on the external view of an object and

supports the essential details of its implementation.
 It is widely used in object orientation to define a class
with its necessary details. Also, it is highly useful in
simulating the real view of an object.
 Its implementation depends on object-oriented
programming and software engineers to define data types
and methods for its implementation.
 It reduces the complexity of an object by defining it
through classes.
16
ABSTRACTION
Degree
+Name : string
+Completion {Abstract}()
UG PG Research
-UG credits -PG credits -Research credits
+Completion() +Completion() +Completion()
Figure 7.6: Abstract class Degree

17
ENCAPSULATION
 Encapsulation is possible only through abstraction. Thus,

abstraction and encapsulation are complementary to each
other.
 Encapsulation is a way of organizing data and methods into
a structure by concealing the way the object is
implemented, i.e., preventing access to data by any means
other than those specified.
 Due to encapsulation, cohesion of the module becomes
stronger whereas coupling between modules becomes
weaker.
 Objects provide services to other objects through
interfaces. Interfaces are implemented to use the services
provided by the object.
18
MESSAGE PASSING
 Objects communicate with each other by passing messages.

 A message is a request for an operation or a service.
 When a particular operation is to be performed, it is
requested by an object by sending a message to the object
for which the operation is defined.
 Messages are implemented through procedure or function
calls in the program. When the object receives the message,
it will look for and execute the corresponding method.
 A message has two parts, viz., object name and message
with its parameters.
 The getItem method can have itemID and itemName
parameters. It can be written as:
S = Objectstore.getItem(getName, getID);
19
INHERITANCE
 Inheritance is the mechanism that permits a class to share

the attributes and operations defined in one or more classes.
 The class which inherits from another class is called a
subclass (also called a derived class) and the superclass
(also called a base class) is a class from which another
class inherits the behavior and data.
 Inheritance decomposes software into a lower level of
components and therefore it reduces the software
complexity.
 This is possible by method overriding in object-oriented
programming. Inheritance is categorized into hierarchical
inheritances and multiple inheritances.
20
INHERITANCE
Computer
Mini computer Mainframe computer Micro Computer Super computer
Desktop computer Laptop computer
Figure 7.7: Two- level inheritance of a computer

21
INHERITANCE
Fabric
+Weaving()
+Knitting()
+Crocheting()
+Knotting()
Animal fabric Plant fabric Synthetic fabric
Wool Silk Cotton Jute Nylon Polyester
Man-made fabric
Figure 7.8: Multiple inheritance

22
POLYMORPHISM
 Polymorphism means an operation of a class behaves

differently on different data values.
 It is possible either by extending the capabilities of an
operation in the subclass or overriding the same operation
in the superclass.
 Polymorphism is one of the most important features of
object-oriented programming.
 For example, addition operation can be performed on
numbers to find the sum of numbers, on strings to
concatenate the strings, and on files to merge files.
23
POLYMORPHISM
ObjectsAdd
-ParameterList
+getData()
+addData()
NumberObject StringObject FileObject
+getData() +getData() +getData()

+AddData() +addData() +addData()
Figure 7.9: Polymorphism for ObjectsAdd operation
24
UNIFIED MODELING LANGUAGE (UML)
 Unified Modeling Language was firstly published by

the Object Management Group (OMG) in 1997 as an
open and industry-standard visual modeling language.
 Unified Modeling Language is a language for
specifying, visualizing, constructing, and documenting
the artifacts of software systems, as well as for
business modeling and other non-software systems .
 UML is a modeling language, not a programming
language.
 It provides graphical and semantical representations
for object-oriented software design.
25
EVOLUTION OF UML
 There are three methods of UML.
 The Booch Method: It was developed by Grady Booch.
◦ This approach was excellent for design and implementation of
projects. Booch was a primary player in the development of
object-oriented technique and primarily he was working in Ada
language.
 The OMT (Object Modeling Technique): This technique
was explored by J. Rambaugh et al.
◦ This was most suitable for analysis and data intensive
information systems.
 The Objectory: This is an object-oriented software
engineering approach and it was developed by Ivar
Jacobson.
◦ This method uses use cases for understanding the behavior of a
system. This method is useful in requirements capturing,
analysis, and high-level designs. 26
OBJECT RELATIONSHIPS
LINK AND ASSOICATION

 A link represents the relationship between objects whereas
an association is a relationship that connects classes.
 Association is indicated by a line. Association can be a
binary, ternary, or n-ary relationship.
 Multiplicity defines how many instances of a class are
associated with the instances of another class. It can be
zero, one, or many.
 A “*” is used for many and a line without any multiplicity
indicates a one-to-one association.
 The number specifies the number of instances in the
association among classes.
27
 An association can also have attributes and it is

represented by a box on the association line with a loop.
 Role names are also used at the end of the association line
to uniquely identify the object at the same end of
association.
 A qualifier can be attached with the association at the
many side of the association line. It is indicated with a
small box on the end of the association line close to the
class diagram.
28
Project status
Engineers +Employee +Employer

* 1 Company
*
Project ID
Projects
Figure 7.10: Association with multiplicity and qualifier

29
AGGREGATION
 Aggregation is a kind of association that specifies a
“whole-part” relationship between the aggregator and its
components.
 The smaller objects are assembled together to create a
more generalized object. In aggregation, a single object is
treated as a collection of objects.
 The component object may be accessed through other
objects without going through the aggregator.
 The aggregator object is a more abstract object than its
component objects.
 A diamond is drawn at the assembly end of the
relationship to represent aggregation.
30
AGGREGATION
Figure 7.11: Aggregation of Wwindows system
Window system
1 1 * 0..2 1
Menu bar Title bar Pane Scroll bar Control box

1 2
1
1
Title Close button Indicator Arrow
31
COMPOSITION
 It is dependent on the lifetime of the composite object.

There exists a “has-a” relationship between the
composite and the component objects.
 The composite object has the ownership for the creation
and destruction of the component objAects.
 Composition is stronger than aggregation because here
there is dependency of component objects on the
composite object.
 For example, Students can register in a Course till its
existence. As the Course is closed there is no possibility
for student registration.
32
COMPOSITION
Figure 7.12: Composition for a course-student system
Course Students
1 *
33
GENERALIZATION
 Generalization represents a “is-a” relationship between

the parent (superclass) and child (subclass) classes.
 The subclass inherits the properties of the superclass.
 The parent class represents the most general class and the
child class is a more specific class.
 Generalization is implemented using inheritance in an
object-oriented programming language.
 Generalization allows finding attributes, operations, and
relationships in a parent class and then reusing them in
child classes.
 In UML, generalization is shown as an arrow from the
child to the parent, with a large hollow triangle at the
association end to the parent.
34
GENERALIZATION
Figure 7.13: Generalization for a telephone system
Telephone
Landline Wireless
35
DEPENDENCY
 Dependency is the relationship between two objects in

which a change in one object may affect the other object.
 For example, if an object A uses another object B, then A
depends on B. That is, A cannot be developed without
using B. Thus, class A and class B are coupled to each
other.
 The coupling between dependent objects can either be
loose (i.e., weak dependencies) or tight (i.e., strong
dependencies).
 Dependency is represented by a dashed directed line,
directed to the class which is depended upon with the
stereotype, which distinguish its kind.
36
DEPENDENCY
 A stereotype is a tag used to indicate the type of a

construct so that it can be distinguished from other
constructs.
 A stereotype is shown by guillemets (« »). Different
entities, attributes, and associations have different types.
 The stereotype extends and identifies their capabilities
with other types.
 Each stereotype has semantics associated with it.
 There are various types of stereotype dependencies, such
as «abstraction», «binding», «realization», «substitution»,
«usage», etc.
37
DEPENDENCY
Figure 7.14: Dependency relationship
«uses»
Withdraw
Transaction
money
38
REALIZATION
 Realization is a semantic relationship where one class

specifies a contract which another class carries out.
 In realization, one classifier provides the specifications and
the other classifier ensures the implementation.
 Realization is observed in the context of interfaces and
collaborations. Classes and components use realization.
 A realization dependency is shown with a dashed line with
a triangular arrowhead at the end, which corresponds to the
realized element.
 Realization allows reusing the operations of types and
interfaces, where a realization element is said to realize its
specification elements.
39
REALIZATION
«implementation class»
Student
sponsored student
Figure 7.15: Realization relationship
40
UML BUILDING BLOCKS
 As UML is a modeling language, various graphical

symbols are used for its diagrammatic representation.
 UML has various basic building blocks that describe the
objects, their roles, and their linking with other objects.
◦ Use case, Actor, Class,
◦ Interface, Component
◦ Package, Note
◦ Collaboration, Interaction
◦ State machine, Node
◦ etc.
41
USE CASE
 UML modeling uses abstraction for the representation of

the behavior of a system, which is shown by use case.
 A use case represents a set of functions performed by a
system for a specific goal.
 A use case does not describe the implementation details.
Use cases can be implemented by several users.
 Each user may use the system for a different purpose. The
system functionalities are decomposed into sub-functions
and these are represented by use cases.
 Use case is a logical description of system functionality.
Actors and use cases are connected by solid lines.
 A use case is drawn as an ellipse and labelled with its name
inside it. 42
USE CASE EXAMPLES
Create account login Check balance
Transaction Transfer update balance
43
ACTOR
 Actors can be the user of the system or other external

events.
 An actor may play different roles in systems and hence it
may interact with several use cases.
 A use case can be initiated by various actors. But each
actor has a unique name and description.
 Actors are represented by their roles.
 An actor is represented as a small stick person labelled
with its name
44
ACTOR
 some examples of actors are as follows:
Employee Account
Bank ATM
45
CLASS
 A class defines the static structure of an object. It
includes the attributes and the methods of an object.
 All objects of a class have the same attributes and
behavior.
 All objects can be distinguished with their attributes.
Classes are represented by rectangles which have three
compartments.
 The upper part represents the class name; the second part
is used for attributes; and the last part is used for
operation specifications.
 Attributes and operations are specified with their data
type. The parameters can be specified in the operations
46
CLASS
Some examples are as follows:
Employee Account
-EMP ID : int -Account number : int
-Name : string -Account holder : string
-Address : string -Bank name : string
-Designation : string -Balance : decimal
-Salary : decimal -Account type : string
+getName() : string +createAccount() : int
+getSalary() : decimal +depositMoney() : decimal
+getBonus() : decimal +withdrawMoney() : decimal
+getSeniority() : int +enquiry() : string
47
INTERFACE
 An interface defines communication socket to connect
with another class.
 It contains a set of operations that a class provides to the
other classes.
 Generally, interfaces are implemented through abstract
classes in which services of a class are defined. An interface
does not contain attributes.
 In UML an interface is shown as a class with the interface
stereotype written on it.
 Sometimes, type stereotype is also used for the
representation of an interface.
 It has only the operations that will be implemented by
other classes.
 A circle notation is also used to represent the interface
with a solid line to the class that supports it.
 In C++, it is specified by pure virtual functions.
48
INTERFACE
 For example, RegistrationRecord class can be used by
the RegisterStudent class for registration in the library.
 RegistrationRecord is supported by the Library class.
 Student registration is possible through this interface
that the library is using for registration.
«interface» Library
RegistrationRecord
+GenerateID() : int
+GetName() : string
+GetAddress() : string
RegistrationRecord
RegisterStudent
RegisterStudent
49
COMPONENT
 A component is an independent unit of execution. It is a
piece of software that implements a number of
interfaces.
 Components are implementation in the physical
architecture of the concepts that are replaceable in the
system.
 A component provides its services to other components.
A component instance has a name and a type.
 Components can be programs, DLLs, runtime linkable
images, and so on.
 A component is shown as a rectangle with two small
rectangles protruding from its side.
50
COMPONENT
For example, the StringHandling component performs

string operations that will implement stringOperations
interface.
StringHandling stringOperations
51
PACKAGE
 A package is used to represent the modular view of a
system.
 A package represents the part of a system which contains
several classes and it may in turn also contain other
packages.
 Packages are conceptual groupings of the system and
need not necessarily be implemented as cohesive
software modules.
 These are used to combine classes, components, nodes,
and other UML constructs. As a package consists of other
constructs, there exist dependencies among them.
 A package is drawn as a rectangle with tabs on it.
Dependencies are shown as dashed arrows.
52
PACKAGE
For example, the Result processing package depends on the

Evaluation package.
Result
Evaluation
processing
53
NODE
 A node is a physical object that can execute artifacts.
 It exists at run time and represents computational
resources such as memory and processing units.
 Nodes can vary in size and capability, from a simple
embedded device to a server form.
 Nodes are used in deployment diagrams. They show
how programs flow during their runtime environment
and at what device program is to be executed.
 Nodes are especially identified in the component
development environment such as J2EE, .NET, etc.
 A node is shown as a stylized cube with the name of the
node.
54
NODE
For example, a Web server running in a remote location

can access Database server, as it is shown below.
Databse server
web server
55
COLLABORATION
 Collaboration is the organization of various objects to
realize the behavior in a context.
 It also represents the interaction between software objects.
 It illustrates messages being sent between classes and
objects (instances).
 All the objects and their relations are wired together using
connectors to show the communication flow.
56
COLLABORATION
 Collaboration is shown as a rectangle with the object

name. For example, Temperature is recorded through the
Thermoscope device.
Temp
Thermoscope Temperature
57
INTERACTION
 The purpose of interaction is to show the messages
exchanged among objects.
 Each message is exchanged between objects in a specified
context.
 Interaction represents the dynamic behavior of the system.
 It shows the flow of control across objects.
 It is represented by an arrow with the message name
exchanged between the objects and it is shown as follows.
58
INTERACTION EXAMPLE
acknowledge
59
STATE MACHINE
 State machine represents the behavior of an object during

its lifetime.
 The state machine describes the single snapshot of the
execution of a system where objects interact with each
other.
 The state machine has events and states.
 A state is drawn as a rectangle with rounded corners. The
transitions between states are shown through arrows with
the actions performed by objects.
60
STATE MACHINE
The following example shows the state machine in which

an Idle computer machine moves to the Booting state as
you switch it on.
switch on
Idle Booting
61
NOTE
 A note is used to provide comments. Textual information

such as a comment, constraint definition, or method body
in UML diagrams can be described through notes.
 Notes are depicted by a rectangle with the top-right corner
folded over.
 A note is illustrated as follows.
It is a note symbol
62
UML DIAGRAMS
 Object-oriented modeling in UML is done using UML

diagrams.
 UML provides nine different diagrams. All these diagrams
are designed to visualize a system from different
perspectives.
 Designing of UML diagrams begin with requirements
analysis phase and move towards design, development and
implementation phases.
 These diagrams contain UML building blocks and object
relationships.
 The UML diagrams are divided into the following 4 + 1
different views. The “”+1” view is the user’s view, which
is a crosscutting view of all other views.
63
4+1 VIEW OF UML DIAGRAMS
Process view
Structural view Sequence diagram
Class diagram Collaboration diagram
Object diagram State diagram
Activity diagram
User's view
Use case diagram
Deployment view Implementation view

Deployment diagram Component diagram
64
4+1 VIEW OF UML DIAGRAMS
 User’s view: It is also known as analysis view. It focuses on

system functionalities, system services, and actors.
 Structural view: This is also known as design view. It
represents the structure of a system in terms of classes,
interfaces, and their relationships.
 Process view: This is also known as behavioral view. It
defines the flow of the system.
 Implementation view: This is also known as physical view. In
this view, components are assembled together to make a
complete physical system.
 Deployment view: This is also known as environmental view.
The components are identified for deployment as physical
nodes in the system.
65
USE CASE DIAGRAM
 “Use case” means what the different “uses” of a system are.
 Use case depicts the functions that the system provides the
actors.
 The use case diagram shows which actors interact with each use
case.
 It is primarily used to capture the user requirements. The user
requirements are represented in an abstract manner without a
description of their details.
 The behavior of a system can be observed through objects and
their relationships and interactions.
 The use case diagram results into the use case model, which has
actors, use cases, and the communication lines between them,
along with the events that occur.
 Use cases are also described with the use case scenarios.
66
USE CASE SCENARIO
 The use case scenario is the textual representation of use

cases and it covers all the following important aspects of the
system:
 System: This section provides the name of the system,
along with the name of authors, date, and version of the
system.
 Use case name and use case number: Generally, a
system has several use cases. Therefore, each use case
should be numbered and it should have a well-defined
name.
 Participating actors: These are the persons or systems
that interact with the developing system.
 Description: The working of a use case along with its
inputs and outputs is specified in this section. 67
USE CASE SCENARIO
 Preconditions: They describe the conditions that are

satisfied before a use case is initiated.
 Post conditions: They describe the conditions that are
satisfied after the completion of use cases.
 Flow of events: This is the main sequence of interactions
between actors and uses cases. The steps or events which
occur to complete a use case are described.
 Nonfunctional requirements: The nonfunctional
requirements are the quality factors that are considered in
the system. They include users, hardware, software,
project, and implementations issues.
 Reference documents: This section mentions the
important documents or references that are required to
understand use cases. 68
Example 7.1: Use case for a library management
system
Library Management System
Add Add book

membership
«library»
Delete Library catalogue
membership Delete book
Librarian
Check
Request
availability
membership
<<include>>
Enquire book
Issue book Library clerk

Calculate
Member overdue charges
<<include>>
Return book
69
Scenario 1: Request membership
System: Library management system
Use case name: Request membership Use case number: UC-01
Participating actors: Initiated by the member and the librarian
Description: Request membership process allows a member to get
membership from the librarian
Preconditions: Member should be a member of the organization
Post conditions: Membership form will be completed and verified by the
librarian
Flow of events: 1. Member will request to take membership from the
librarian
2. Librarian will provide the membership form
3. Member will complete the membership form and submit it
to the librarian
Nonfunctional requirements: An understandable membership form should
be designed
Reference documents: Member should be given a departmental membership
manual
70
Scenario 2: Add membership

Use case number: UC-02
Use case name: Add membership
Participating actors: Initiated by the librarian
Description: Librarian adds the member to the library management system
Preconditions: Membership form must be completed
Post conditions: Membership ID will be generated
Flow of events: 1. Librarian will submit the form in the system

2. System will generate the membership ID
Nonfunctional requirements: Membership ID should be unique for each

member
Reference documents: Details of membership documents
71
Scenario 3: Delete membership
Use case name: Delete membership Use case number: UC-03
Participating actors: Initiated by the member or the librarian
Description: Membership of a member will be deleted from the library

system
Preconditions: There should not be any due books or fee
Post conditions: The membership ID will be deleted from the library
Flow of events: 1. Member will request the librarian to withdraw the

membership
2. The librarian will check for any due of books or fees
3. Membership ID will be deleted from the library
Nonfunctional requirements: There should not be any dues of deleted ID
Reference documents: Librarian keeps record of deleted membership

72
Scenario 4: Enquiry book

Use case name: Enquiry book Use case number: UC-04
Participating actors: Initiated by the member
Description: Member will enquire for a book from the library clerk
Preconditions: Member should be a registered member of the library
Post conditions: Library clerk will check the availability of the book from
the library database
Flow of events: 1. Member will enquire for a book
2. Library clerk checks the availability from the library
database
3. Library clerk acknowledges the member
Sub-flow: 1. Check the availability of book in the system.
Nonfunctional requirements: Efficient searching of books from the library

database
Reference documents: List of books
73
Scenario 5: Issue book
Use case name: Issue books Use case number: UC-05
Description: Member will request to issue books from the library clerk
Preconditions: Member should be a registered member of the library
Post conditions: Library clerk will issue the available book
Flow of events: 1. Member will request the book

2. Library clerk provides book if it is available in the library
database
3. Library clerk updates the system according to member ID
of the member
Nonfunctional requirements: Restricted number of books should be issued to
the member
Reference documents: Issue process and guidelines
74
Scenario 6: Return Book
Use case name: Return books Use case number: UC-06
Description: Member will return books
Preconditions: Return date should be within the specified time
Post conditions: Library clerk returns books
Flow of events: 1. Member will return the book
2. Library clerk checks the system for the return date
3. Library clerk updates the system and applies overdue
charges, if any
Sub flow: 1. Calculate the overdue charges
Nonfunctional requirements: Return records should be maintained
Reference documents: Return procedure and guidelines for overdue charges
75
Scenario 7: Add book

Use case name: Add book
Participating actors: Library clerk
Description: Library clerk will add books in the library database
Preconditions: Books should have a unique identification number
Post conditions: List of added books
Flow of events: 1. Library clerk adds the books
2. Library clerk checks the system for the quantity of
books
3. Library clerk updates the system
Nonfunctional requirements: There should be a unique number for each
book
Reference documents: Purchased book records
76
Scenario 8: Delete book

Use case name: Delete book
Participating actors: Library clerk
Description: Library clerk will delete books from the library database
Preconditions: Permission should be given by the librarian
Post conditions: Deleted books in a particular category
Flow of events: 1. Library clerk deletes the book
2. Checks the system for the quantity of books
3. Updates the system
Nonfunctional requirements: Book ID should be deleted

Reference documents: Deleted records
77
Example 7.2: Use case for tender management in
EtransQ system
Tender management in EtransQ
* * «extends»
*
Manage tender
Accept tender
* Supplier «uses»
* Publish tender
Fill tender
«extends»
*
Agent
«extends»
Search tender
*
*
Suggest tender
Transporter
78
Example 7.2: Mainline sequence of the
use case scenario
System: EtransQ
Use case name: Tender management Use case number: UC-001
Participating actors: Supplier, agent, and transporter
Description: Tender management feature allows suppliers to post tenders. With this
feature, transporters and agents can sort and search tenders with a single click. Once a
tender is published, its date can be altered.
Preconditions: The user posting the tender should be a supplier.
Post conditions: 1. Notifications are generated for all his associates.
2. Supplier will get an email notification.
Flow of events: 1. Supplier requests to upload the tender.
2. After filling the form, the transporter has to upload a file in
“pdf” format.
3. Once uploaded, the tender will be published on the specified date.
Sub-flow: 1.Search tender.
2. Publish tender.
3. Activate/deactivate tender.
Nonfunctional requirements: There should be the best deal available in the market in case
of a large shipment or have good relations with actors for a
prolonged time.
Reference documents: Tendering manual 79
USE CASE RELATIONSHIP
 Sometimes use cases are refined into smaller use cases or

use cases exchange information to each other.
 There exist some relationships between use cases.
 The goal is to reduce the complexities in the use case
models.
 There are four types of relations observed between use
cases:
◦ includes,
◦ communicates,
◦ extends, and
◦ generalizes.
80
INCLUDES
 There may exist commonalities in use cases.
 A use case may contain the behavior common to several
use cases.
 Use case is included in other use cases.
> Fee payment

e>
clud
<in
<
Student
registration <<inc
lud e>> Library
membership
81
COMMUNICATES
 The communication relationship is used to exchange
information between actors and use cases.
 The communication relationship is shown by drawing a line
between use cases and actors.
<<communicates>> Student <<communicates>>

registration
Administrator
Librarian
82
EXTENDS
 Extend relationship is used to extend a use case by adding
events in it.
 The extend use case may include the behavior of
extending use case. For example, student evaluation
extends to result preparation and student promotion.
«extends» Result preparation
Student evaluation
«extends»
Student
promotion
83
GENERALIZES
 It is used to specialize another use case or actor by adding or
removing its behavior.
 The child use case or actor inherits the behavior of its parent
use case or actor.
Pay via debit card
Pay bill
Pay via credit card
84
CLASS DIAGRAM
 The class diagram describes the structural description of the

system.
 Class diagram is prepared by establishing relationships
among classes.
 Class relationships are made using aggregation,
generalization, association and dependency relationships.
 During designing of class diagram, object oriented design
principles are applied to design an optimized class diagram.
 Class diagram can directly be implemented into the object
oriented programming language.
85
Figure 7.19: Class diagram for a library
management system
1 Library Catalogue
uses Consists of *
* -Name : string
-Total books : int Entered into
1
* -Created by : string Book
Library employee +AddBook() -Title : string
-Name : string +DeleteBook() -subject : string
-Adrress : string +Display() -Author : string
-LoginInfo : string +updateBook() -ISBN : int
-ContactInfo : string 1 -Copies : int
* +add()
service Library +delete()
+update()
-Name : string
+IsAvailable()
-Location : string 1
+ManageMember()
+ManageBook()
Librarian Library clerk +ManageEMP()
-LibraryID -LibraryID +ManageDatabase()
+ManageLibrary() +IssueBook() Reference book Course book
+Allowmembership() +ReturnBook()
+DeleteMembership() -ReferenceID -IssueID
+AddBook()
Member -DateofReturn
+DeleteBook()
-Name : string
-LibID : void
-Address : string
-DOB : int
-ContactNo : int Employee
Student
+UpdateInfo() -EmpID
-CourseName : string
+TakeMembership() -DeptName
-StudentID : void
+RemoveMembership() +CheckBookDetail()
+CheckBookDetail() +IssueBook()
+ReturnBook()
86
OBJECT DIAGRAM
 Object diagrams are the instances of class diagrams.

 From an implementation point of view, object diagrams
are dependent upon class diagrams.
 Object instances are created, destroyed, and modified
during the execution of the system.
 Object diagrams also represent the structural view of a
system but they are the snapshot of a system at a
particular moment.
 The data values are shown with the objects.
 An object diagram is closer to the actual system behavior.
87
Figure 7.20: Object diagram for a library
management system
CSIT : Library
L : Library employee M1 : Member
SE : Book
LCT : Library Catalogue LC : Library employee
88
SEQUENCE DIAGRAM
 Objects interact by passing messages along with their

signatures.
 Upon receiving a message, an object triggers the execution
of a method and in turn sends a message to another object.
 Such interaction of objects is represented pictorially
through interaction diagrams.
 The interaction diagram has two forms: sequence diagram
and collaboration diagram.
 Both diagrams represent the dynamic behavior of the
system.
89
SEQUENCE DIAGRAM
 A sequence diagram shows the interaction among objects by
passing messages in a time- based sequence.
 The diagrammatic representation of a sequence diagram has two
dimensions: vertical dimension and horizontal dimension.
 The vertical dimension has vertical dashed lines that participate
in the interaction represent object’s lifeline.
 The object’s lifeline states the existence of the object at a
particular point of time.
 The messages that they exchange are arranged in time sequence.
Object names are written inside the box at the head of the
vertical lines and these are underlined.
 The vertical lines indicate timing that progresses downwards.
The horizontal dimension represents different objects without
any ordering.
90
SEQUENCE DIAGRAM
• A vertical thin rectangle called activation symbol on lifeline shows
the period during which an object is active.
• During the activation period, an object performs an action either
directly or through its subparts.
• The action being performed by the object is labeled in text next to
the activation symbol. Activation can be merged or split into parts.
• Objects communicate through messages passed among them. A
message is shown as a horizontal solid arrow from the lifeline of
one object to the lifeline of another object.
• When an object calls itself, then message arrow may start and
finish on the same object’s lifeline.
• The message arrow is labeled with the message name and its
argument values.
• Sometimes, messages are labeled with sequence number to show
the sequence of the message in the overall interaction.
91
Figure 7.21: Sequence diagram for a library
management system
Member Librarian Library clerk Library catalogue Book Library
Request membership
Provide membership form

Submit membership form
Add in the library
Assign Library ID
Ack with Library ID
Enquire a book
Search for book
Search result
Ack book availability

Request for issue
Issue book Update catalogue
92
COLLABORATION DIAGRAM
 A collaboration diagram is also used to represent object

interaction.
 objects are represented as and when they come in the system
and numbered messages are sent from one object to another.
 The number in the message is the sequence in the object
interactions. Messages are shown along the association line
with their directions of movement.
 Collaboration diagram does not show time as a separate
dimension, so the sequence of messages and the concurrent
threads must be determined using sequence numbers.
 The collaboration diagram shows the context in which
interaction occurs among objects.
93
Figure 7.22: Collaboration diagram for a
library management system
Librarian Library catalogue
4. Assi
5.
A d gn
d i Li
n t br a
3. Submit membership form
2. Provide membershipform
he r y
1. Request membership
lib ID
6. Ack with library ID
13. Update catalogue
8. Search for a book

rar
y
9. Search result
Library
7. Enquire a book
11. Request for issue
10. Ack bookavailability
12. Issue book
Member Library clerk
94
STATE CHART DIAGRAM
 An object goes through various states to show the

behavior of a system.
 The state changes whenever an event occurs.
 State chart diagrams consist of states and transitions.
 A state represents a condition satisfied by the attributes of
an object.
 It is drawn as a rounded rectangle with its name inside it.
 A small filled circle represents the initial states and a circle
surrounding the small filled circle is indicated as final state.
 A transition is represented by an arrow between one state
to another state with the event name in it causing
transition.
95
Figure 7.23: State chart diagram for a
Initial state
Request for issue Request for return

Not
available Returned
Check availability Return book
Not Available
valid
Valid member
Valid
Issue book
Issued
96
ACTIVITY DIAGRAM
 An activity diagram also illustrates the dynamic view of a
system.
 The activity diagram is basically a kind of state chart
diagram that represents the procedural flow of controls form
one activity to another.
 An activity can be described as an operation of the system.
 Action states are shown as a rounded rectangle. The
completion of an action state is shown by an arrow.
 The branching conditions are shown with a small diamond
box that represents the alternative paths.
 The outgoing arrows are labelled with a condition or guard
expression.
 The outgoing arrows represent the set of all possible
outcomes.
97
Figure 7.24: Activity diagram for a library
management system
Member Library Library Library
clerk catalogue
Enquire book Enter ISBN Check availability
Ack book availability Search result
Issue request Check membership Valid member
Yes
Issue book
No
Message box
98
COMPONENT DIAGRAM
• Component diagrams represent the implementation view of

the software in a system.
• A component diagram is made by connecting components
through dependency relationships.
• Components are the different parts of a system. They can
be source code components, executable components, binary
components, business components, etc.
 There are five components in this system and these are
book management, member management, library EMP
management, library catalog, and library main system.
99
Figure 7.25: Component diagram for a
Book Member Library EMP

management management management
Library
system
Library
catalogue
User interface
100
DEPLOYMENT DIAGRAM
 A deployment diagram shows the configuration of runtime

processing elements at the customer site.
 It is a graph of nodes connected by communication
associations.
 A deployment diagram is a kind of graph made up of
components connected by communication associations.
 Nodes may contain component instances; this indicates that
the component lives or runs on the node.
 There are three nodes used in this system and these are
client desktop, application server, and database server.
101
Figure 7.26: Deployment diagram for a
Client desktop Application server
Library
Library
Management
Management
Source code
Source code
Database server
My SQL
2000
102
OOAD PROCESS
 OOA focuses on the problem domain and OOD concentrates on
the solution domain.
 OOA and OOD help OOP in implementation of the system.
 OOA, OOD, and OOP work together for the development of
software.
 The main activities of object-oriented software development are
as follows:
• Project initiation
• Requirement engineering
• System design
• Object design
• Implementation
• Testing
• Deployment 103
OBJECT ORIENTED ANALYSIS AND
DESIGN PROCESS
Development phases OOAD activities
Use case analysis

Project initiation
Class diagram
Requirements engineering
Interaction diagram
Subsystem decomposition
System design
Class diagram
Object design specification
Implementation Object-oriented
programming
Testing Object-oriented testing
Installation
Deployment
104
SUMMARY
 OOAD is an approach for analysis and design, which
focuses on modeling rather than design.
 There are various building blocks of object-oriented
development, such as objects, classes, encapsulation,
abstraction, message passing, inheritance, and
polymorphism.
 Unified Modeling Language (UML) is a language for
specifying, visualizing, constructing, and documenting the
artifacts of software systems as well as for business
modeling and other non-software systems.
 It combines OOSE, OMT, and the Booch method. UML is
an object- oriented modeling language where the real world
situation is viewed as a set of objects that interacts each
other. 105
SUMMARY
 Most commonly used object relationships in object-oriented
modeling language are association, generalization,
aggregation, composition, realization, and dependency.
 UML provides nine different diagrams.
 The UML diagrams are divided into following 4 + 1
different views, viz., users’ view, structural view, process
view, implementation view, and the deployment aspects.
 Object-oriented software development employs OOA,
OOD, and OOP.
 Object-oriented software development has several activities
and these are project initiation, requirement engineering,
system design, object design, implementation, testing, and
deployment.
106

Chapter - 7: Object Oriented Design Using UML

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chapter - 7: Object Oriented Design Using UML

Transféré par

Droits d'auteur :

Formats disponibles

Chapter - 7

Object Oriented Design Using UML

 Object-oriented technology has received significant

 Object-oriented analysis and design (OOAD) is a combined

 OOAD has two important aspects, viz., object-oriented

 Object-oriented software development concentrates on

Joe: Doctor Joe: Customer Joe: Driver Joe: Passenger

Joe : Person Bob : Person

 The properties and operations of a class can be shared by

 A typical structure of a class has three parts, viz., name,

 Abstraction focuses on the external view of an object and

Figure 7.6: Abstract class Degree

 Encapsulation is possible only through abstraction. Thus,

 Objects communicate with each other by passing messages.

 Inheritance is the mechanism that permits a class to share

Mini computer Mainframe computer Micro Computer Super computer

Desktop computer Laptop computer

Figure 7.7: Two- level inheritance of a computer

Animal fabric Plant fabric Synthetic fabric

Wool Silk Cotton Jute Nylon Polyester

Figure 7.8: Multiple inheritance

 Polymorphism means an operation of a class behaves

NumberObject StringObject FileObject

+getData() +getData() +getData()

Figure 7.9: Polymorphism for ObjectsAdd operation

 Unified Modeling Language was firstly published by

LINK AND ASSOICATION

 An association can also have attributes and it is

Engineers +Employee +Employer

Figure 7.10: Association with multiplicity and qualifier

Figure 7.11: Aggregation of Wwindows system

Menu bar Title bar Pane Scroll bar Control box

 It is dependent on the lifetime of the composite object.

Figure 7.12: Composition for a course-student system

 Generalization represents a “is-a” relationship between

Figure 7.13: Generalization for a telephone system

 Dependency is the relationship between two objects in

 A stereotype is a tag used to indicate the type of a

Figure 7.14: Dependency relationship

 Realization is a semantic relationship where one class

Figure 7.15: Realization relationship

 As UML is a modeling language, various graphical

 UML modeling uses abstraction for the representation of

Create account login Check balance

Transaction Transfer update balance

 Actors can be the user of the system or other external

 some examples of actors are as follows:

Some examples are as follows:

For example, the StringHandling component performs

For example, the Result processing package depends on the

For example, a Web server running in a remote location

 Collaboration is shown as a rectangle with the object

 State machine represents the behavior of an object during

The following example shows the state machine in which

 A note is used to provide comments. Textual information

 Object-oriented modeling in UML is done using UML

Deployment view Implementation view

 User’s view: It is also known as analysis view. It focuses on

 The use case scenario is the textual representation of use

 Preconditions: They describe the conditions that are

Add Add book

Issue book Library clerk

System: Library management system