OOAD Pocket book

Contents
Chapter 1. Class and class relationship ......................................................................................................... 3
Class Relationships .................................................................................................................................... 4
Dependency .............................................................................................................................................. 4
Association ................................................................................................................................................ 4
Aggregation and Composition .................................................................................................................. 6
Generalization ........................................................................................................................................... 7
Realization................................................................................................................................................. 8
Class attributes and methods visibility. .................................................................................................... 8
Class Diagram ............................................................................................................................................ 8
Chapter 2. OOP feature in Class.................................................................................................................... 9
Abstraction ................................................................................................................................................ 9
Encapsulation .......................................................................................................................................... 10
Polymorphism ......................................................................................................................................... 10
Inheritance .............................................................................................................................................. 11
Chapter 3. Class Design Principles .............................................................................................................. 11
Single Responsibility Principle (SRP) ....................................................................................................... 12
Open - Closed Principle (OCP) ................................................................................................................. 13
Liskov Substitution Principle (LSP) .......................................................................................................... 14
Interface Segregation Principle (ISP) ...................................................................................................... 15
Dependency Inversion Principle (DIP)..................................................................................................... 17
Chapter 4. Unified Modeling Language (UML) ........................................................................................... 17
UML Structure and Behavior Diagram .................................................................................................... 18
4+1 View ................................................................................................................................................. 19
Chapter 5. UML Diagrams ........................................................................................................................... 19
Use Case Diagram ................................................................................................................................... 20
Activity Diagram ...................................................................................................................................... 21
Class Diagram .......................................................................................................................................... 23
Object Diagram ....................................................................................................................................... 24
Sequence Diagram .................................................................................................................................. 24
1
Sivadasan Plakote

OOAD Pocket book

Communication Diagram ........................................................................................................................ 25
Timing Diagram ....................................................................................................................................... 26
Interaction Overview Diagram ................................................................................................................ 27
Composite Structure Diagram ................................................................................................................ 30
Component Diagram ............................................................................................................................... 32
Package Diagram..................................................................................................................................... 34
State Machine Diagram........................................................................................................................... 34
Deployment Diagram .............................................................................................................................. 36
Profile Diagram ....................................................................................................................................... 37
Chapter 6. Design Steps .............................................................................................................................. 39
UML 2.4 Diagrams ....................................................................................................................................... 41

2
Sivadasan Plakote

OOAD Pocket book

Chapter 1. Class and class relationship

The class is basic of software design and the class relationship shows how classes are linked to provide
the functionality in software.
Class and Object
The building blocks of any software design are Interface, Class and Object. An Interface is collection of
operations. A Class defines a Type and an Object is instance of Class. The Class has data fields and
methods wrapped in side. See Figure 1.1 example for interface, class and Object.

Figure 1.1
Consider following example for further discussion.
The near buy ATM center has an ATM machine. There is a place for customer to stand in queue waiting
for their turn to withdraw money. The ATM center has lost and found area. You will find an umbrella and
helmet in lost and found area.
How to identify a class? A class represent noun from problem description. Lets identify the classes in
above examples.
ATM center, ATM machine, Customer, Queue, Lost and Found Area, umbrella, helmet
There are three types of classes.
Boundary class
Controller class
Entity class
The boundary class handles the communication between system and the users.
The Controller class handles the flow of business logic and coordinates with other class for logic
implementation.
The Entity class handles information of the system.
3
Sivadasan Plakote

OOAD Pocket book

In Figure 1.2 you can see user communicate with boundary class. The boundary class accesses the
business logic from controller class and controller class finding the system information using entity class.

Figure 1.2

Class Relationships
There are four types of Class relationships.
Dependency
Association
Generalization
Realization
Lets look into each class relationships.

Dependency
In a dependency relationship a change in class can result into change in another class.

Figure 1.3
In Figure 1.3 Class1 has dependency with Class2. Any changes in Class2 can results into a change in
Class1.

Association
An Association relationship shows the connections between the Classes.
In association there can be different multiplicity at each end of the relationship for the classes.
One and only one
4
Sivadasan Plakote

OOAD Pocket book

Zero or many
One or many
Between m to n
m or n
Figure 1.4 shows one and only one multiplicity in association.

Figure 1.4
Figure 1.5 shows zero, one or many multiplicity in association.

Figure 1.5
Figure 1.6 shows one or many multiplicity in association.

Figure 1.6
Figure 1.7 shows m..n multiplicity in association.

Figure 1.7
Figure 1.8 shows m or n multiplicity in association.
5
Sivadasan Plakote

OOAD Pocket book

Figure 1.8
An association can be directed association or undirected association.
Figure 1.9 shows directed association.

Figure 1.9

Aggregation and Composition

Associations are two types namely Aggregation and Composition.
Aggregation represents whole and part relationship. Aggregation shows has a type relationship. For
example, Nest has a bird.
In Figure 1.10 the Class6 is part of Class5.

Figure 1.10
Figure 1.11 shows the example Nest has a bird in aggregation relationship.

Figure 1.11
Composition is stronger form of Aggregation. The additional constrain in composition is, whole class is
responsible for lifecycles of part class (creation and destroy) and the part may be belong to only one
composite class. Composition shows owns a type relationship. For example, Car owns a seat.

6
Sivadasan Plakote

OOAD Pocket book

In Figure 1.12 Class6 is part of Class5.

Figure 1.12
Figure 1.13 shows the example car owns a seat in aggregation relationship.

Figure 1.13
Another form of association is reflexive relation.
Reflexive association is where a class has association to itself.
Figure 1.14 shows example to reflexive relationship.

Figure 1.14
The Employee instance has role of manager of another Employee instance. The role manages with
multiplicity 0..* shows that Employee not necessary to have another Employees to manage.

Generalization
A generalization relationship is parent-child connection between classes. It shows is a or kind of type
relationship.
In Figure 1.15 Class 7 is parent of Class 8.

Figure 1.15
Figure 1.16 is example for generalization where SUV is generalized form of Car.

Figure 1.16

7
Sivadasan Plakote

OOAD Pocket book

Realization
The realization shows an interface implementation to a class.
In Figure 1.17 Class9 implements interface called interface2.

Figure 1.17
Figure 1.18 shows example for realization where Car is realizing Vehicle interface.

Figure 1.18

Class attributes and methods visibility.

The class attributes and methods can have one of the following visibilities.
Public (+): Class and Other classes have access to attributes and methods with public visibility.
Protected (#): Only class and subclasses have access to attributes and methods with protected visibility.
Package (~): The class and other classes in same package have access to attributes and methods with
package visibility.
Private (-): Only class has access to its attribute and methods with private visibility.

Class Diagram
The class diagram which explained under UML diagrams shows the static structure of a system or
subsystem using classes involved in system or subsystem. Figure 1.19 shows the class diagram for
previous ATM center example.

8
Sivadasan Plakote

OOAD Pocket book

Figure 1.19

Chapter 2. OOP feature in Class

Object Oriented Programming (OOP) languages fundamental concepts such as abstraction,
encapsulation, polymorphism and inheritance are considered while defining a Class.

Abstraction
The abstraction is a process or generalization showing the detail relevant to purpose.

Figure 2.1

9
Sivadasan Plakote

OOAD Pocket book

In Figure 2.1 as example for furniture shop to find number of furniture in shop, without Furniture
interface the programmer will be writing separate count for each type of furniture. With Furniture
interface as abstraction only one method is required to count the furniture in shop.

Encapsulation
The encapsulation allows information (data) hiding. The class hides the data from it clients, only the
methods in class can directly access the data. This protects the data integrity and prevents others from
setting invalid data.
Figure 2.2 shows class Shop with data and methods to access the data.

Figure 2.2
The public methods are the access points to Shops class fields. These methods are generally known as
getters and setters. A class that wants to access the field can access them through these getters and
setters.

Polymorphism
Polymorphism provides means of having different methods with same name acting differently based on
the object type that is acting upon. There are two types of polymorphisms, static (compile) and dynamic
(runtime).
There are three types of polymorphisms in object oriented programming; overloading, overriding and
dynamic method binding.
Overloaded methods have same name but different number of parameters or different types of
parameters.
Overridden methods are redefined in subclass with same signature (name, parameters and return type).

10
Sivadasan Plakote

OOAD Pocket book

Dynamic method binding is, at runtime program identify the subclass reference to call the method.
Example is classes implementing a interface.

Inheritance
Inheritance allows a derived (subclass) to have the properties (non private attributes and methods) from
its base class. By using inheritance program enhance the re-usability of the code.

Figure 2.3
In Figure 2.3 SavingAccount Class inherits the properties like account detail and related methods from its
base class Account Class.

Chapter 3. Class Design Principles

The class design principles help to avoid some of the bad design while designing software.
Some of the bad software designs are following.
Rigidity
Fragility
Immobility
Viscosity
Rigidity: Difficulty to make change in class structure. Every change results in subsequent change of
depending classes.

11
Sivadasan Plakote

OOAD Pocket book

Fragility: A change in one part of software result to break in other part of software, even there no
logical relationship with area where it is changed.
Immobility: Design does not support reusability of software.
Viscosity: Design make easy to do wrong changes in structure but difficult to make right changes.
In real world software development life cycle, requirements keep changing. A good software design is
resilient to changes.
The class design principles helps designer to avoid bad software design. Following are five class design
principles useful to design any software.
Single Responsibility Principle (SRP)
Open Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
In computer programming, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface
segregation and Dependency inversion) is a mnemonic acronym introduced by Robert C. Martin in the
early 2000s which stands for five basic principles of object-oriented programming and design.

Single Responsibility Principle (SRP)

Single responsibility principle is originally from Structured Analysis and Systems Specification, 1979 by
Tom DeMarco.
A class should have only single responsibility and does one responsibility only and does it well. The class
has reason to change in responsibility; it should have one and only one reason to change.
The Disadvantages of not using SRP are following.
Different concepts are mixed together
Hard to understand code
Hard to change the code
Hard to use and re-use
Code duplication
The Advantages of using SRP are following.
Make class more robust.
Classes tend to be smaller
12
Sivadasan Plakote

OOAD Pocket book

Easier to understand
More stable and not changed very often
To know whether a class following single responsibility principle, define the class using a single sentence
may be without using AND. Before adding new responsibility to class verify against this sentence.
Example:
The weekly report class has responsibilities of collecting report data, compilation and printing. Any
change in one of it responsibility can change the weekly report class. See Figure 3.1.

Figure 3.1
In Figure 3.2 the responsibility of Weekly Report is divided logically into other class. Each classes having
single responsibility.

Figure 3.2

Open - Closed Principle (OCP)

Open closed principle is formulated by Bertrand Meyer.
A Software module should be both open for extension and closed for modification.
The behavior of the entities can be changed when there is requirement change. The existing entities are
not changed but the functionality is extended to program without modifying the existing source code.
Consider software which is production environment, any change in code will call for code review, testing
and other verification methods to validate the software. Code obeying OCP principle does not change
when it is extended, but allows extending itself adding new code.

13
Sivadasan Plakote

OOAD Pocket book

For example consider Class A which has some old clients B, C. A new client D need to use a modified
version of Class A.
Approach 1: Modify Class A to the needs of all clients B, C and D.
Problem: The changes can invalidate the requirements of the clients B and C which will be defects. Also
there is need for code review the Class A; test, redeploy Class A and the clients of Class A.
Approach 2: Copy Class A into a new Class A1 and make the changes in Class A1. Old clients Class B, and
D will continue to use the Class A and the new client D will can ClassA1.
Problem: This will lead to repetition of code and maintenance will be difficult.
Approach 3: Extends Class A to Class A1. Use abstraction and Polymorphism to implements new
requirements in Class A1
The approach 3 use the open-close principle by allowing Class A is open for new requirement by
extending to Class A1 but it is closed for any changes.
Example for Object oriented program following OCP shown in Figure 3.3

Figure 3.3
Open-closed principle should not used for fixing defects in a class. If there is a defect it should be fixed in
same class not in derived class.

Liskov Substitution Principle (LSP)

Liskov substitution principle is formulated by Barbara Liskov.
For each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms
of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.

14
Sivadasan Plakote

OOAD Pocket book

In other words for each object d1 of type D there is an object b1 of type B such that for all programs P
defined in terms of B, the behavior of P is unchanged when d1 is substituted for b1, then D is a subtype
of B.
What Liskov says is, in a program subclass should be substitutable for their base class.
Example:
Consider we have base class Color and derived class Green extends base class Color, then we can write
Color c = new Green();
The client should not be aware of whether instance of base class or derived class is used. When instance
of base class Color passed to client works correctly then passing instance of derived class Green should
also work.
LSP is guideline to implement inheritance correctly. As inheritance is IS-A type relationship, a subtype
relation should exist between base and derived class. Inheritance should not be used when the
relationship between classes is IS-ALMOST-A.
Remember Square-rectangle problem. Though square is like a rectangle it is not a rectangle. When
height of the square changes it also changes width. In rectangle when height changes width does not
changes.

Interface Segregation Principle (ISP)

Interface Segregation Principle says, clients should not be forced to depend upon interfaces that they do
not use.
Disadvantage of not using ISP are following.
Clients are affected when there is change in method which they dont use
Change in one part of the program affecting other part of the program
Advantage of using ISP are following.
Specific interfaces are created of each type of client
Class will implements the interface which they required depends on the client using them
Avoids fat interfaces
Clients does not affect by change in the method which they dont use
Example:
interface Account {
15
Sivadasan Plakote

OOAD Pocket book

public void lock() ;
public void activate() ;
public void lowBalance() ;
}
interface Monitor {
public void notifyForBalance(double balance, Account ac) { /* */ }
}
In our example consider that we have two types of accounts, current account and saving account. For
the current account the minimum balance is amount of 100 and for saving account there is no need to
have minimum balance.
class SavingAccount implements Account{
public void lock() { /* */ }
public void activate() { /* */ }
public void lowBalance() { /* */ }
}
As per requirement saving account is free from having a minimum balance, but here saving account is
forced to have implementation for method lowbalance. We can redesign the interfaces as following.
interface Account {
public void lock() ;
public void activate() ;
}
Interface AccountMonitor {
public void lowBalance() ;
}
interface Monitor {
public void notifyForBalance(double balance, AccountMonitor acm) { /* */ }
}
class SavingAccount implements Account{
public void lock() { /* */ }
public void activate() { /* */ }
}
class CurrentAccount implements Account, AccountMonitor {
public void lock() { /* */ }
public void activate() { /* */ }
16
Sivadasan Plakote

OOAD Pocket book

public void lowBalance() { /* */ }
}
Now Saving account class is free from implementation of method lowbalance and does not know about
Monitor. The Monitor class is does not see what type of account it monitors.

Dependency Inversion Principle (DIP)

Dependency Inversion Principle says, Depend upon Abstractions. Do not depend upon concretions.
To explain more, when abstract class is extended by derived class, abstract class should not be
depended on derived class. But derived class can depend on abstract class. See Figure 3.4

Figure 3.4
An abstract class is more stable than implemented concrete class.
See example in Figure 3.5.

Figure 3.5

Chapter 4. Unified Modeling Language (UML)

The Unified Modeling Language or UML is used for following.
Modeling business process
Analysis, design and implementation of software system.

17
Sivadasan Plakote

OOAD Pocket book

The UML is created by Grandy Booch, Ivar Jacobson and Jim Rumbaugh. The UML specification is
maintained by Object Management Group. The current version of UML is 2.4, released in January 2011.
UML is a stand modeling language not a software development process. It is process independent and
could be used for different software process like water fall, iterative and incremental development
process.

UML Structure and Behavior Diagram

The UML specifications classify the uml diagrams in to structure diagrams and behavior diagram.
Structure diagram shows static nature of the system.
Behavior diagram shows dynamic nature of the system when changes happen to system.
See Figure 4.1 showing static and dynamic diagrams.

Figure 4.1

18
Sivadasan Plakote

OOAD Pocket book

4+1 View
Philippe Kruchten developed 4+1 view for UML which breaks down a model into set of views. This 4+1
view help you show how each diagram capture specific aspect of the system. See Figure 4.2.

Figure 4.2
Logical view provides different parts of the systems, how they are made and how they interact with
each other. The UML diagrams in this view are class diagram, object diagram, sequence diagram,
communication diagram, interaction overview diagram, timing diagram, composite structure diagram
and state machine diagram.
Process view provides the activities in system. The UML diagram in this view is activity diagram.
Development view provides modules and components in system using system parts from logical view.
The UML diagrams in this view are component diagram and package diagram.
Physical view provides real life entities of the system. This view shows how different parts from logical
view, modules and component from development view are deployed. The UML diagram in this view is
deployment diagram.
Use Case view provides functionality of the system as use cases. The UML diagram in this view is use
case diagram.

Chapter 5. UML Diagrams

Before looking into each UML diagram, consider following business requirement for the discussions.
The near buy ATM center has an ATM machine. There is a place for customer to stand in queue waiting
for their turn to withdraw money. The ATM center has lost and found area. The items which are left by
customers in ATM center are placed in lost and found area for customer to find it later.
19
Sivadasan Plakote

OOAD Pocket book

We can use above requirement where ever possible as examples in our discussions.

Use Case Diagram

Use case diagram shows functionality of system. In a use case diagram Actor(s) is the user using the
functionalities of the system and use cases are the functionalities provides by the system.
Following are the use cases we can identify in our ATM center requirement.
Withdraws money
Login
Print receipt
Place item in lost and found area
Search lost and found area
Fetch item from load and found area

Figure 5.1
In Figure 5.1, the name ATM Center and the rectangle surrounds the use cases and actors is System
Boundary in use case diagram.

20
Sivadasan Plakote

OOAD Pocket book

The use case withdraws money <<include>> functionalities from other two use cases Login and Print
receipt. The use case Fetch item from lost and found area <<extends>> functionalities of use case
Search lost and found area. The use case Place item in lost and found area <<inherits>> the
functionalities from use case Fetch item from lost and found area.
The <<include> relationship in use case shows that include use case are reusable part of the
system.
The <<include>> use case have separate use case descriptions and avoid updating many
places when there is a change in description.
The behavior of <extend>> use case is found in the Extension session of the use case which
is extending it.
The <<inherits>> use case specify in Base use case session the name of inherited use cases.

Activity Diagram
The activity diagram shows how system will accomplish the functionalities it supports. Each use case will
have activity diagram explaining how its use case functionality is implemented.
We will take use case withdraws money to draw activity diagram. The activities in this use case can be
listed as following.
Ask customer to login
Select account type
Select withdrawal amount
Ask receipt required
Dispose money,
Print receipt
Figure 5.2 shows activity diagram for use case withdraws money.

21
Sivadasan Plakote

OOAD Pocket book

Figure 5.2
Note that Login and Print receipt are separate use cases and they will have own activity diagrams.
Activity diagram for Login use case is shown in Figure 5.3.

22
Sivadasan Plakote

OOAD Pocket book

Figure 5.3

Class Diagram
The class diagram shows the classes and their relationships implementing the functionality supported in
use case and collectively by system. In our requirement for use case withdraws money we can identify
the following classes.
Customer
Customer Session
Account
ATM Machine
Cash dispenser
Receipt printer
Customer Queue
The analysis mode class diagram for use case withdraws money can be shown as in Figure 5.4.

Figure 5.4
When you move from analysis model to design model, apply other class relationships to identify more
classes. See Figure 5.5.

Figure 5.5

23
Sivadasan Plakote

OOAD Pocket book

Object Diagram
An object diagrams show the instances of the classes participating in specific scenario.
In customer and account relationship, to show that Customer can have one Personal Account, object
diagram can be shown as in Figure 5.6.

Figure 5.6

Sequence Diagram
The sequence diagram shows how system will perform the functionality defined by use case using
classes. The sequence diagram is time dependent with interactions are shown in the order it takes place.
For use case withdraws money the sequence diagram can be shown as in Figure 5.7.

Figure 5.7
The sequence diagram has five different types of message arrows. See Figure 5.8.

24
Sivadasan Plakote

OOAD Pocket book

Figure 5.8
The objects and classes participating in sequence diagram shows what responsibilities are given them to
implement the functionalities of the use case. These responsibilities are becomes attributes and
methods for the classes.
From use case withdraws money, Customer Session has following attributes:
Customer details
Type
Amount
Balance
From use case withdraws money, Customer Session has following methods:
Start session
End session
Set account Type
Withdraw money

Communication Diagram
The Communication diagram shows which are the participants connected for an interaction. The
diagram shows the link and messages passed between the participants in the system.
For use case withdraws money the communication diagram can be shown as in Figure 5.9.

25
Sivadasan Plakote

OOAD Pocket book

Figure 5.9
A participant name is shown with <object name> : <class> in sequence diagram. The line between
participants is called link. The messages are numbered to show how interaction happens in system. A
participant can call a message to itself when it has self link.
There are UML tool which generates communication diagram from sequence diagram as you can see
from our case study both diagrams show how participants interacts to perform the functionalities
defined in use case.
Most used UML diagrams for any systems design are use case diagram, activity diagram, class diagram
and sequence diagram. For a use case you may have multiple activity diagrams, class diagrams,
sequence diagrams or any other diagrams are required to explain the system design to others.

Timing Diagram
The Timing diagram shows timing information associated with events in an interaction. Timing diagrams
are commonly used for real-time systems or embedded systems.
For examples you may have requirement that interaction cannot take more than 10 seconds to
complete or message cannot take more than 5 seconds to return. In our case study we will add following
requirement to demonstrate timing diagram.
After customer enter login detail ATM machine should not take more than 5 seconds to display the
result.
To create a timing diagram we can start work from using sequence diagram. Participants and events in
timing diagrams are participants and events from your sequence diagram. For use case withdraws
money, the timing diagram to for start customer session can be shown as Figure 5.10.
26
Sivadasan Plakote

OOAD Pocket book

Figure 5.10
Timing constrain in timing diagram can be show in different ways. See table 5.1.
Timing Constraint
Description
{t..t+5s}
Duration of event or state must be less than 5 seconds.
{<5s}
Duration of event or state must be less than 5 seconds.
{>2s, <5s}
Duration of event or state must be greater than 2 seconds but less than 5
seconds.
{t}
Duration of event or state must be equal to t where t is relative value in time.
{t..t*5}
Duration of event or state must be value of t in multiple of 5 times where t is
relative value in time.
Table 5.1

Interaction Overview Diagram

The interaction overview diagram shows different interactions woks together to implement system
functionality. Interaction overview diagram looks similar to activity diagram except that each activity in
interaction overview could be a sequence, communication and timing diagram. Each of the diagrams in
interaction overview is part of flow which shows how system functionality will be implemented.

27
Sivadasan Plakote

OOAD Pocket book

Top of the interaction overview diagram has title which is life lines section show participants in the
diagram. Each diagrams as title which shows type of diagram and the activity name for that interaction
diagram.
For use case withdraws money, the interaction overview diagram can be shown as Figure 5.11.

28
Sivadasan Plakote

OOAD Pocket book

Figure 5.11

29
Sivadasan Plakote

OOAD Pocket book

Composite Structure Diagram

The composite structure diagram shows high-level view of system parts. This diagram is suitable to
represent following model.
Internal structure of class, component, use case or system
Port available on class to use
Collaboration among object to achieve system objective
Internal Structure shows parts inside a class and their relationship. For example consider a class Book
which contains Page, Toc, Appendix and Index.

Figure 5.12
From Figure 5.12 class diagram you can see that Book has reference to Toc and Page object. The Page
object can have association to Toc object for easy access. But the class diagram confuses you by showing
that Page can be associated to any Toc object which is incorrect. The Page object can associate with only
a particular Toc object.
Figure 5.13 shows Internal Structure of Book class.

30
Sivadasan Plakote

OOAD Pocket book

Figure 5.13
Port, Required and Provided Interface
A Port is interaction point between class and others. The class can have interfaces associate with ports.
A class can realize two types of interfaces. First type is provided interface which other class uses to
access class function. Second type is required interface which is required by class to implement the
function. See Figure 5.14.

Figure 5.14
The Collaboration show objects working together to accomplish some functionality. Collaboration
diagrams show the role objects are playing in a scenario.
Figure 5.15 is collaboration diagram for withdraw money in ATM example.

31
Sivadasan Plakote

OOAD Pocket book

Figure 5.15
Alternate representations of collaboration diagram for withdraw money is shown in Figure 5.16.

Figure 5.16

Component Diagram
The component diagrams shows the different blocks (parts) in software. Each component performs key
functionality of the system. A component could be created as part of the software or taken out of the
box from a third party.
As classes, component can generalize and associate with other classes and components. Components
should design as loosely coupled so that change in one component does not affect others.
As class diagram, component diagram can show provider and required interfaces. Though component
diagram shows these interfaces it is actually the underlying classes which will have direct relation with
these interfaces. In Figure 5.17 transaction manager has provided interface called transaction and
required interface called Logger. The transaction managers required interface Logger connect to Log4js
provided interface Logger.
32
Sivadasan Plakote

OOAD Pocket book

Figure 5.17
We can also use stereotype notation to show provider and required interfaces in components as shown
in Figure 5.18.

Figure 5.18
Along with provider and required interfaces component diagram show the artifact which contains the
named component. Figure 5.19 is part of the component diagram for ATM example.

Figure 5.19
33
Sivadasan Plakote

OOAD Pocket book

Package Diagram
The package diagram shows how classes and interfaces are grouped into packages and the dependency
among packages.
Figure 5.20 shows part of the package diagram for ATM example.

Figure 5.20

State Machine Diagram

The state machine diagram or state diagram shows state of an object or system and events which is
causing change in state. This diagram is commonly used for real-time application, device programming,
and games design etc.
A state diagram has state, transition, behavior and trigger. See Figure 5.21

Figure 5.21
34
Sivadasan Plakote

OOAD Pocket book

In Figure 5.21 running and stop are two states, apply break and release break are triggers or events
which is causing state to change.
The state diagram can also have initial and final psuedostate. A behavior in state explains what current
behavior of object in active state is. In Figure 5.22 do run engine is behavior happens while object has
running state. A behavior ends its own or by trigger making to exit the state.

Figure 5.22
A trigger is an event that may cause transition of object from one state to another. Trigger can have
guard condition when it evaluate to true transition can happen.
An object can have internal behavior and internal transition while it is in current state. The internal
behaviours are entry and exit. The entry behavior happens as soon as object enter to current state. The
exit behavour happenes immediate before completion of the state.
An internal transition does not change the state of the object. It shows reaction of the object for
particular trigger happens in that state. See Figure 5.23.

Figure 5.23
An object can have multiple states at the same time known as composite state. In composite states
more than one state diagrams are executed in parallel. See Figure 5.24.

35
Sivadasan Plakote

OOAD Pocket book

Figure 5.24
In composite state, when state is active each region become active and state diagrams are start
executing. When trigger on the composite state occurs the state is completed.
Fork and Join can be used in state diagram to show branching and joining of concurrent states as shown
in Figure 5.25.

Figure 5.25

Deployment Diagram
The deployment diagram shows physical view of the system, how software is assigned to different
hardware and their communication.
A deployment diagram contains one or more node showing device and/ or software deployed. An
artifact can be shown inside a node indicating artifact is deployed in that node. Listing artifacts names
inside the node is easier then drawing artifacts symbol for each artifact. See Figure 5.26.
36
Sivadasan Plakote

OOAD Pocket book

Figure 5.26
A node can be hardware or software resource hosting artifacts. Examples for hardware node are
Desktop PC, Server, disk drive, Machine etc. Examples for software node are operation system, J2ee
Environment, Application server, Web server, Database server.
Communication path shows the nodes communicates at runtime. Figure 5.27 is part of the deployment
diagram for ATM example.

Figure 5.27

Profile Diagram
The profile provides lightweight mechanism to extend UML, specific to a platform like J2EE, Dot Net or
specific to a domain like financial, telecommunication, health etc. Profile uses stereotypes, tagged
values and constraints to extend UML.

37
Sivadasan Plakote

OOAD Pocket book

A stereotype shows that an element has special meaning or purpose. If a stereotype has icon, element
can be displayed with icon.
A tagged value provides information about associated stereotype. A stereotype may have more than
one tagged value associated.
A constraint imposes a rule or restriction of model.

Figure 5.28
A stereotype extends itself from a UML Meta class. In Figure 5.28 example Servlet is a stereotype
extending from Component Meta class using special notation for extension. The Servlet stereotype has
tagged values and a constraint.
One or more profiles may be applied to a package that is extended from same Meta class as long as they
do not have conflicting constraints. Applying a profile to a package means that it is allowed to apply the
stereotype defined in profile but not required.
Applying Servlet profile to Web application package allows using Servlet profile in Web application
model.
Applying elements of Servlet profile to customer data class in web application. See Figure 5.29

38
Sivadasan Plakote

OOAD Pocket book

Figure 5.29
Tagged values and constraint from profile are applied to model.

Chapter 6. Design Steps

You will be starting your software analysis with user requirement. Following steps will guide you from
requirement to design of software.
Use Case Model
1.
2.
3.
4.
5.

Open main use-case diagram.

Find all the use-cases and actors from the problem statement and requirements.
Create actors and use-cases
Drag and drop all the actors and use-cases and give proper relationships.
Prepare user-case specifications documents and perform details study on requirement.

Business Model
1. From the use-case specification document create activity diagrams under respective use-cases.

Logical View
Analysis Model
1. Identify all the nouns from problem statement and requirement document. Create classes for all
the nouns as key abstraction class.
2. Find out the analysis mechanism to be applied for the project (e.g. persistence, reliability).
3. Identify analysis classes (boundary, control, entity) for each use-case.
4. There will be one Boundary class between actor and use-cases.
5. For each use-case there will be one Control class.
6. Most probably the key-abstraction classes we will convert to entity classes.
7. Identify the responsibilities of use-case and delegate these responsibilities to classes (e.g.
//method-name)
8. Identify the attributes.

Design Model
39
Sivadasan Plakote

OOAD Pocket book

1. Create a sequence diagram for each use-case.
2. Create class diagram for each use-case packages and named as VOPC (view of participating
classes)
3. Under the design model create packages for different software packages and drag (create) the
respective classes to the packages.
4. Identify the subsystems.
5. Identify the interface for subsystems.
6. Create package for subsystem interfaces named as interfaces and drag and drop all the
interfaces.
7. Move boundary classes to interface package and change the stereo type to proxy.
8. Create packages for three layers (application, business, middleware).
9. Put respective packages into respective layers.

Process View
1. Identify the system as process driven or thread driver or both.
2. Identify the active classes and passive classes.
3. Allocate process for active classes and threads (if needed) for passive classes.
4. Process diagram can be represented through component diagram.

Deployment View
1.
2.

Identify the process nodes and device nodes (configuration, protocol, media).
Map the process to node.

Subsystem Design (Only for subsystem development)

1. In basic flow sequence diagram replace boundary classes with subsystem interfaces and remove
the actors
2. The message should not come from interface (make it proxy)
3. Represent the internal activity of sub-system through sequence diagram.
4. Create class and communication diagrams.

40
Sivadasan Plakote

OOAD Pocket book

UML 2.4 Diagrams

41
Sivadasan Plakote