Chapter 13

Object Oriented Analysis & Design Using UML

13.0 Introduction

For the development of application software of a real-life system, the requirements are to
be found out first by analyzing its different activities. The task is not quite easy because
most users of the system cannot specify the requirements very clearly and effectively.

Again, the phase of software design cannot start unless system users’ requirements are
thoroughly understand. To reduce total development time, the design process may be
started in parallel for only the well understood portions along with the analysis of the
remaining portions.

The implementation phase (coding, testing, etc) can be started only when prototype design
of some portions becomes ready. Thus system analysis, design and implementation can go
in tandem for a large complex system.

The success of a software project depends on the proper understanding of the system
going through the above mentioned 3-steps of analysis, design and implementation.
These three steps follow a lifecycle.

There are three software development lifecycle models – waterfall model, spiral model
and incremental iterative model.

For small projects, waterfall model can be used. In this case, full system analysis gets
completed first and then the design phase starts. Again the implementation phase starts
only after completion of the design phase.As most real life systems are complex,
revelation of the total system requirements is not possible allowing a short time period of
analysis. Therefore waterfall model can be applied only for small systems.

The spiral model is most suitable when software development can be tackled as a whole,
starting with a rough understanding and then gradually refining the system incorporating
finer details.

The incremental iterative model is most suitable when a project can be divided into sub-
systems and parallel development activities of the subsystems can be carried out
simultaneously.
Whatever may be the model chosen for a project, the phases of analysis, design and
implementation should be carried out most systematically and scientifically keeping
documentation details for each stage.
For object-oriented analysis and design (OOA & OOD) and documentation, a software
engineering tool called Unified Modeling Language (UML) has been developed in the
recent past. It has now been found that for implementation OOP language may not be
used, but OOA & OOD using UML can be regarded as the most scientific approach for
understanding a real-life system for software development. This chapter deals with the
details of UML tools used for object-oriented analysis, design and documentation.

13.1 Unified Modeling Language

UML is a way to model a system for software development. In the process of modeling,
there are four distinct phases – Inception, Elaboration, Construction and Transition.
Software development can be regarded as a Unified Process having four above mentioned
stages. During inception phase, analysis gets started when developers discuss with the
users and the domain experts. An overview of the system requirements are identified and
modeled in the use case diagrams first.

From these use cases the design team identifies the sub-systems and the related problem
domain objects initiating the elaboration phase. The class/objects diagrams with their
data and function members are then identified and elaborated. The system’s behavioral
diagrams help defining the member functions of the respective classes and objects
correctly and scientifically.

The construction or the coding phase starts after full or partial completion of the
elaboration phase. Final coding may demand some changes in the design for proper
implementation with fine-tuning.

The final transition phase deals with the deliverables of the product to customers and
activities (like training, field-testing, etc) associated with the handing over tasks.

The UML is a notional and semantic language that can be used at different stages of the
software development. The UML has been developed by combining the bests of Grady
Booch’s method, Jim Rumbaugh’s Object Modeling Technique(OMT), and Ivar
Jacobson’s use-case method. In 1995, the UML got the support of the Object
Management Group (OMG) as a standard of object-orientation.

The results of system analysis and design are reported and documented in UML using
several diagrams, which can be divided into two main types – Structural diagrams and
Behavioral diagrams.

13.1.1 Structural Diagrams:

Class and Object Diagram -- containing classes and objects, including

attributes and functions, identified for the system or sub-system being developed along
with roles, associations and relationship existing between different classes.
Object diagrams deal with [system] specific instances (to help design by showing
examples) whereas class diagrams give more generic descriptions.

Component and Deployment Diagram – A component diagram shows

how components of a system / sub-system interact with each other. A deployment diagram
models interacting sub-systems of a system.

13.1.2 Behavioral Diagrams:

Use Case Diagram – It is the starting point of the analysis phase where
interacting actors (users) along with their use-cases are identified. It identifies the main
flow of events in a system or sub-system. Use case diagrams help identifying different
users and their requirements for fulfillment of the ultimate goal.

Activity Diagram – Different activities involved in use cases can be

identified and mapped in activity diagrams.

Sequence Diagram – It records the interactions between actors and objects

and between objects to objects. That is, inter-object messages and external events or
commands are identified and recorded in this diagram maintaining proper time sequence.

Collaboration Diagram – This diagram helps modeling message synchronization

and events collaboration while objects interact to produce the desired outputs.

Statechart Diagram – Used to visualize the change of states with respect

to occurrence of events and actions that can be taken thereafter. It is very similar to a state-
transition diagram.

UML has dealt with many other diagrams but their introduction is kept pending till you
become familiar with its foundation concepts.

For modeling systems in UML, you can take help of an Object-Oriented Computer Aided
Software Engineering (OO-CASE) tool like Rational Rose of the Rational Software or
Visio of Microsoft, etc. A CASE tool can ensure software building much faster and in a
guided and well-coordinated manner. Even in absence of a CASE tool, the UML concepts
and diagrams can help every one who is assigned with the job of system analysis and
design.

UML diagrams can be drawn, even by hand, using simple plain pens and papers.

Once object-oriented analysis and design of a system using UML diagrams are made
available, coding for implementation can be carried out choosing any programming
language. The UML diagrams help bringing out the inner mystery of a system in totality
as well as in finer details. For these reasons UML is becoming so popular day-by-day.
 13.2 Use Case Diagrams

Unified Modeling starts with the drawing of use-case diagrams where the system’s users
and their main activities are mapped as simply as possible. It does not go into any details
but tries to capture a gross overview. It definitely identifies who are involved in using the
system and how each one is supposed to interact to achieve the ultimate goal of quality,
speed and efficiency.

Try to identify each user’s requirements and expectations. Use case diagrams are drawn
after gathering relevant information by interviewing different users, managers, etc and
mapping their expectations with respect to all inputs and outputs. From use-case diagrams
one can determine the interfaces needed between the system and its users.

Use-case diagrams can model normal process flow of a system involving both “men and
machines”. Error handling functionality can also be identified wherever needed.

13.2.1 How to Draw a Use-Case Diagram

There are two main notational components – Actors and Use-Cases. Actors are users
like, say purchase clerk, accounts clerk, supervisor etc, and their Use-cases may be like
place order, arrange payment, check stores, etc (Fig-13.1). These two components can
have some kind of associations, which can be shown by drawing straight lines between
them. Thus association becomes another notational component. An actor may have nil,
one or more associations as shown in fig-13.1. Just see the symbols used to represent
actors (special icon) and use-cases (ovals) in a use-case diagram. Actors remain outside
the system boundary and are capable of using the system. Actors need not be people, they
may be other system or computer as well.

Use cases are the actions taken by the users of a system. Use cases can also be
regarded as a testable component of the end product. Naming of actors and use-cases are
very important. For naming use-cases, a verb (like place order) must be included, whereas
for naming actors – a noun (like purchase-clerk) will be preferred.

A use case diagram does not go into any details, it simply tells who are the users of the
system and what they are capable of doing. It gives an idea to the development team
exactly what are the expectations of different users from the system being developed. For
a software development process, the system boundary will include several software pieces
that perform some functions for the satisfaction of the users.

The association between an actor and a use-case establishes a relationship between the
two. In fact, association or relationship indicates the role an actor plays while running the
use-case software module. A single user can play different roles with different use-case
modules and that is why multiple associations or relationships are quite possible.
In object technology, generalization and inheritance is a commonly used technique.
Therefore, actors may have parent-child relationship, use-cases may also have parent-child
relationships.
 Fig-13.1 Use Case Diagram of a Purchase-Payment System

13.2.2 <<include>> and <<extend>> Relationships

Including and excluding are the two ways of relating use-cases with each other. The
include relationship indicates that a use-case will include the functionality from another
use-case to perform its task. Similarly, an extend relationship indicates that a use-case
may be extended by another use-case. The following is the notation used for include
relationship (fig-13.2) –

<<include>>
Including use-case ------------------------------- Included use-case

Fig-13.2 include relationship

The including use-case needs functionality from the included use-case. A dashed line
and an open arrow connect the two. The word <<include>> is written some where along
the arrow as shown in fig-13.2. The identification of included use-cases during the
process of software development helps reuse of codes and components in java programs.
The ‘extend’ relationship is similar to ‘include’ relationship notation except the use of the word
<<extend>> instead of the word include. The extended use-case can inherit functionality
from the extending (parent) use-case. Fig-13.3 shows how two use cases can have ‘extend’
relationship along with include relationships.

Create <<include>>
report ---------------- Save report <<extend>> Inform
-------------- customer
-----------------------
Update
Team-leader report <<include>>

Fig-13.3 Combined include-extend relationship

The task of breaking down individual use-cases into finer details is the main task of a
system analyst. Your experience and helpful suggestions from your seniors will guide you
in making the correct and proper detailing. As a suggestion it can be said that whereever
you find a “verb” in the users’ requirement statements, you can take that as a use-case
candidate or a functionality of some use-cases already identified.

13.3 Activity Diagrams

Activity diagrams should be drawn after the use-case detailing. Activity diagrams try to
model the workflow for the use-cases. Activity diagrams can show the flows within a
use-case as well as between use cases. It describes the conditions and the actions to be
taken for each situation to make the use-cases valid for implementation.
There are three basic notational components used in an activity diagram – activities,
states and transitions. An activity is also called an active state.

Prepare pay-bills
(a)

clerk transitions
(b)

Start select employee do billing save the bill end

state
State (activity-1) (activity-2) (activity-3)
 Fig-13.4 (a) use-case and (b) its activity diagram
In fig-13.4, observe how one simple use-case can be described in details by an activity
diagram. Very often it becomes necessary to add guards and decision points in
transitions so that workflow can change directions according to the change of situations.

Fig-13.5 Activity diagram with guards and decision points

Select Do billing
employee

Insert
decision [new employee] bill

[existing employee]
Guards

Update bill

Just see how transition paths can change (fig-13.5) according to the case of tackling a new
employee or an existing one.

Activity diagrams also can also take care of events and triggers, and make use of
swimming lanes to enhance the readability of a complex activity diagram. (Study fig-
13.6)

Events are indicators of actions that have to take place. The Logon event triggers the
validate method with two arguments (uid and passwd) and the program control thus moves
in a particular direction indicated by a transition arrow. In fig-13.6 two swim lanes have
been used to clearly show the flow of control between client-activities and server-
activities.

Fork allows parallel processes to begin and joins allow those processes to catch up and
resume as a single process flow. The load employee record activity invokes two
processes, loading employee details and loading the salary details, which can go in parallel
but further action can only be taken when they join together after completion of each one.

Examine the thick line and link arrows used to indicate the fork and join activities. The
activity diagram also indicates the states reached after every successful or erroneous
operation. Such detailing helps a developer at the stage of design and implementation of a
software package.
Fig-13.6 Activity Diagram with Events, Swim lanes & Fork/Join

Swim lane 1 Swim lane 2

User (client) Back office (Server) activities

Validate (uid, passwd)

validat
logo
[invalid]e [valid]
validate
Display Not d
error valid

End state

Load employee record

Select employee
load

[load error]
Display error
[error] Employee
[error] details

Salary
details

Display on
user screen

Employee details loaded

Update or
insert new
Save record

Saving [error saving] Saved state

error
display
 13.4 Sequence Diagram

The sequence diagram is one of the two types of interaction diagram used in UML. The
other type of interaction diagram is the collaboration diagram. Sequence diagram models
object interactions that are taking place in time sequence and providing detailed
behaviour which can help defining the member functions of a class related to any
particular use-case.

Sequence diagram has two main notional components – active objects and messages
that are passed between communicating objects. Active objects may be actors or objects
created from any class. Active objects and messages can be diagramed as shown in fig-
13.7.

ObjectTwo
ObjectOne

| |
| [condition] |
| Message |
| |

Fig-13.7 Two main components used in a Sequence Diagram

Messages can contain conditions (like success or failure) that restrict them from being
sent unless met. A condition is shown within [...] brackets directly above the message
name. There are four types of messages possible – synchronous, return, asynchronous
and flat. In fig-13.7 one synchronous message has been shown. Return messages are
drawn as dashed lines with open arrows. For further details you can consult J.T. Roff’s
book – UML A Beginner’s Guide, published by Tata-McGraw Hill edition 2003.

To read a sequence diagram, note the following: --

Identify the actors and the objects.
Identify the messages in the order of control flow.
Identify error-handling occurrences.
To draw a sequence diagram, take help of the following steps: --
Choose the workflow that you are going to model.
Lay out objects from left to right.
For each workflow, include messages and conditions, if any.
Draw a combined generic sequence diagram.

Fig-13.8 shows the interactions taking place between a user and one credit-card handling
kiosk selling tickets for a cinema-show. The kiosk is controlled by a computer: Server
and the software object: CreditService.
 Fig-13.8 A Sequence Diagram showing interactions between a User & three IT Objects

user Active objects

:kiosk :Server :CreditService

insertCard(customer)

pickDate(date)

Offer(seatChoice)
Select(seats) Submit(order)
Charge(cust,amount)

authorize
OK
Print(order)

Note : Control Rectangle notations are used when IT objects are involved in a sequence diagram.

In earlier chapters we have seen how classes are defined and objects are created out of
those class definitions. We will now see how to use UML notations to represent classes.
Classes have relationships with other classes as described through activity and sequence
diagrams.

Modeling class diagrams is an iterative process like any other UML diagrammatic
modeling process. Class diagrams are used to indicate where data members reside and
what methods are available with each class. Those data members and methods made
available for external use are declared as public.
 There are four notational components for class diagrams. They are – Classes,
Relationships, Multiplicity and Roles.
Classes are the main components of a class diagram. Each class must include relevant data
and methods important in the context of the system being developed. The notational
representation of a class in UML is shown in fig-13.9.

Fig-13.9 Notational Representation of a Class

ClassName Access Visibility

+ Public
+ data1 : type1 - Private
# data2 : type2
- data3 : type1 . . .
# Protected

+operation1(par:type): ret_type
-operation2(par:type):ret_type
#operation3(par:type):ret_type
-----

A class box is divided into three compartments – class-name, attributes or data, and the
list of methods. The access visibility of both data and methods are also indicated using
the symbols +, -, and #. Actors like users can also be represented by a class where user-
name and password can be the attributes and login(), logout(), changePasswd(), .. can be
used as the methods.

Relationship between two classes can be associated with a line and an association name.

In fig-13.10 the class employee is associated with another class department having the
association –name works-for. Many employees (*) can work for a single (1) department.
The use of symbol * tells that many employees can work for a department. This is an
indication of multiplicity which is specified by a number (12) or a range of numbers
 (3..20) or any number(*) to show that how many objects of that class can be related to
one object of another class.

supervisor * association name

Self
* 1
association employee department
Works-for
0..1

Works-on Association Class

----- hour

project Project
code
store
Qualified association

Fig-13.10 An Example of Class Relationships with Multiplicity and Roles

Class relationship can also include roles to indicate what one class does for the second.
Self-association with a class is also possible. An employee can act as a supervisor of a
department that has been indicated by the self-association in fig-13.10. Try to guess what
multiplicity of that self-association is trying to indicate.

Also note that qualified association and association class can also be used in drawing
class relationships.

It is quite possible to have classes without any attributes but having methods only. It is
also possible to have classes with only attributes but not with any method.

Objects: Instances of a Class or Classes

The notation of an object is a box with the text Object Name : Class Name typed inside
it. When an object is modeled with attribute values, a particular value in the attribute
compartment is shown as attribute name = object’s value.

Class attributes can also be specified with data types, initial or default values,
multiplicity, etc.

To model a class diagram – analyze the use-case diagram to detect classes with their
associations and then the attributes and operations involved with each class. Hint – to find
the first batch of classes, identify all the nouns. Verbs used with respect to a single
common noun will be the operations belonging to that class. Then identify the
attributes whose values will be essentially required to ensure an object uniquely.

13.5 Collaboration Diagrams

Collaboration diagrams are used to model the interactions taking place between objects
and the roles played by them to perform any function of a use-case. It indicates which
objects and roles are used to accomplish different tasks. Communication between the
objects and their roles, described in a collaboration diagram, takes place through
messages.

Classes do nothing at run time, everything is done by their instantiated objects.

Objects in a collaboration diagram can be represented as

ObjectX ObjectY : ClassY : ClassZ

Object of an Named Object of a class Unnamed Object of a class

Unknown Class

In addition to object instances, object instance roles can also be shown in a collaboration
diagram as
/RoleX

/RoleY : ClassY

ObjectZ/RoleZ

Associations can be carried from the class diagram to the collaboration diagram in the
form of association roles. Multiplicity can also be added to association role. Let us now
have a look at a collaboration diagram (fig-13.11). Three objects – - :orderTaker,
:itemDB and :creditBureau are interacting by passing messages like Request (order,
customer), checkCredit (customer), etc in between them to process a request of purchase
of items through credit card facility. Specially observe that the sequence numbers are
assigned to messages in the order of 1,2, ... etc. They are numbered in the order of
execution sequence. The arrows indicate which object passes message to which other
 object. More than one message can be passed through a single association role or link. In
that case message numbering can be made as N.1, N.2, N.3 ,......., etc. ( where N stands
for the message sequence).

Request(order,customer) 2:cost=reserve
(order)
:orderTaker :itemDB

1: checkCredit (cust) 3: debit (cust,cost)

:creditBureau

13.11 Collaboration diagram of a process for credit card purchasing

Guard conditions can also be used to restrict a message being sent. Guards are placed in
between the sequence number and the message text.

Iterations can easily be modeled in a collaboration diagram. Suppose a message is to be

sent to 5 objects. In that case the message will take the form of N.[1 .. 5] : Message text.
To study a collaboration diagram – identify the objects, then identify the sequence of
events and finally summarize the overall intentions. This study actually helps writing the
program codes.

13.6 Statechart Diagram

It models how an object changes state when a method is invoked. A statechart diagram is
composed of states, transitions and events. Transitions are used to show flow from one
state to another. Open arrows indicate the directions. A hollow diamond with one or
more entry paths and two or more exit paths indicates a decision point.

Synchronization bars are used in a statechart diagram to show where states need to catch
up or wait for others. It imposes concurrency control.

A typical statechart diagram has been shown in fig-13.12. It has three distinct states.
•Initial state
unlock

Available lock Locked buy Sold

Time out

exchange

Fig-13.12 A Statechart Diagram of a ticket booking process

Events are usually indicated directly on the path of a transaction form one state to another.
They indicate what caused the state to change. Actually events indicate what triggers a
state transition and actions indicate what happens when an event occurs. There are five
basic action types – entry, exit, do (while within a state), include (invokes another sub-
statechart) and event driven (like event-name (parameters) [guard-condition] / action).

To model a statechart: --

Identify the entities (use-cases or objects) that need further detailing.

Identify start and end state for each entity.
Determine events related to each entity.
Create the statechart starting with the start event.
Decompose a state into sub-state where necessary.

13.7 Implementation Diagrams

There are two types of implementation diagrams – component diagrams and deployment
diagrams. Component diagram models relationships between software pieces and
deployment diagram models relationship between hardware pieces.

Software components (like source code, binaries, executables, scripts, command files,
etc) along with their relationships are described in a component diagram. The notational
model of a component is a rectangle with two small rectangles on its left edge.
Component relationships are illustrated by dependencies (shown by a dashed line with
an open arrow at the end). Carefully study the component diagram shown in fig-13.13.

<<database>>
account
Fig-13.13 Component Diagram with Dependency
(Component)

dependency

transactions
update [interface]
(component)

ATM GUI
Realization

Components can be contained within another component. There is no limit to such

component nesting. A dependency can be stereotyped with <<includes>>, <<imports>>,
etc labels as and when necessary.

Deployment Diagram

Deployment diagrams are used to model hardware pieces and their relationships. Nodes
are used to represent hardware pieces. Communication associations between nodes are
shown with solid lines drawn from one node to another. The means of communication
can be indicated by stereotypes like << WAN>>, <<http>>, <<usb>> etc along the
nodes connecting solid line. Fig-13.14 shows a combination of nodes, communication
associations, components and classes/objects. Along with those when dependencies are
also added using dashed lines ending with open arrows between components, an
Physical View-Deployment
Implementation diagram gets formed. Thus, software and hardware requirements for a
system, being developed, can be understood from its Implementation diagram.

Fig-13.14 Deployment Diagram with Components and Communication Association

Server:BankServer • Nodes Contain Components

+ Classes/Objects
Data Base
Server Data Access Component • Combine Comp Diagram +
Node Deployment Diag. + Dependencies
WEB Server Component to Model Implementation
Diagram

<<WAN>>
Client:ATMkiosk

Client WEB Browser Component

node

For drawing an Implementation diagram, go through the following steps –

• Identify the nodes,

• Identify communication associations required,
• Identify the components, classes and interacting Objects,
• Identify dependencies between components, classes/objects,
• Identify GUIs to be realized for user interactions.

Conclusions

UML is a subject by itself. Its full features cannot be described in a chapter. It has been
included in this book to give an idea about object oriented software engineering and to
show how classes/objects, their associations and interactions can be identified and
described by taking help of different types of UML diagrams.
Coding and testing of programs written in either java or any other languages can be done
quite easily by a group of developers, once the UML diagrams are made available to them.
Therefore, a java programmer should learn how to read UML diagrams.

Just keep a note that the Object Management Group (OMG) sets vendor-neutral
software standards. UML as a software development tool has been recommended by OMG
for the analysis, design and development of any system.

For testing, every class is tested by creating objects first and then integration tests are
performed at the sub-system levels and finally at the system level.

System documentation, field trials and customer training are also included as deliverables
in a software project. Although BlueJ has not followed the UML notations exactly, it has
been able to give a flavor of UML to its user to some extent.