DIT 0305: OBJECT

ORIENTED
ANALYSIS AND
DESIGN
 DIT 0305: Object Oriented Analysis and Design

INTRODUCTION TO OOAD
Object-oriented analysis and design (OOAD) is a software engineering approach that
models a system as a group of interacting objects. Each object represents some entity of interest
in the system being modeled, and is characterized by its class, its state (data elements),
and its behavior.
Object-oriented analysis (OOA) applies object-modelling techniques to analyze the
functional requirements for a system. Object-oriented design (OOD) elaborates the
analysis models to produce implementation specifications. OOA focuses on what the system
does, OOD on how the system does it.

Object-Oriented Programming
Object-oriented programming (OOP) is a programming paradigm based upon objects (having
both data and methods) that aims to incorporate the advantages of modularity and reusability.
Objects, which are usually instances of classes, are used to interact with one another to design
applications and computer programs.
The important features of object–oriented programming are:
i. Bottom–up approach in program design
ii. Programs organized around objects, grouped in classes
iii. Focus on data with methods to operate upon object’s data
iv. Interaction between objects through functions
v. Reusability of design through creation of new classes by adding features to existing
classes

Some examples of object-oriented programming languages are C++, Java, Smalltalk, Delphi,
C#, Perl, Python, Ruby, and PHP.

Exercise:
1. Discuss the advantages and disadvantages of object orientation.
2. Differentiate between object oriented programming and structured programming.

Basic Concepts and Terminologies of Object–Oriented Systems

1. Object
An object is a real-world element in an object–oriented environment that may have a physical
like a customer, a car, etc. or an intangible conceptual existence like a project, a process, etc.
It is an instance of a class. Each object has three properties.

Properties of an object
i. Identity: it is that property of an object which distinguishes it from all others in the
system. It is the name held within an object. For example; student, lecturer, book etc.
ii. State: it determines the characteristic properties of an object as well as the values of
the properties that the object holds. For example; for a student, name, Registration
number, gender, age, course etc.
iii. Behavior: it represents externally visible activities performed by an object in terms of
changes in its state. For example; a student can attend classes, sit for exams, pay fees
etc.

2. Class

2|Page
 DIT 0305: Object Oriented Analysis and Design

A class represents a collection of objects having same characteristic/properties that exhibit

common behavior. It gives the blueprint or description of the objects that can be created from
it. Creation of an object as a member of a class is called instantiation. Thus, object is an instance
of a class. It is a template from which objects are created.

3. Encapsulation
Encapsulation is the process of binding both attributes and methods together within a class.
Through encapsulation, the internal details of a class can be hidden from outside. It permits the
elements of the class to be accessed from outside only through the interface provided by the
class.

4. Data Hiding
Typically, a class is designed such that its data (attributes) can be accessed only by its class
methods and insulated from direct outside access. This process of insulating an object’s data is
called data hiding or information hiding.

5. Message Passing
Any application requires a number of objects interacting in a harmonious manner. Objects in a
system may communicate with each other using message passing. Suppose a system has two
objects: obj1 and obj2. The object obj1 sends a message to object obj2, if obj1 wants obj2 to
execute one of its methods.
The features of message passing are:
Message passing between two objects is generally unidirectional.
Message passing enables all interactions between objects.
Message passing essentially involves invoking class methods.
Objects in different processes can be involved in message passing.

6. Inheritance
Inheritance is the mechanism in which a sub class acquires some or all its characteristics from
the base class. Inheritance that permits new classes to be created out of existing classes by
extending and refining its capabilities. The existing classes are called the base classes/parent
classes/super-classes, and the new classes are called the derived classes/child
classes/subclasses. The subclass can inherit or derive the attributes and methods of the super-
class(es) provided that the super-class allows so. Besides, the subclass may add its own
attributes and methods and may modify any of the super-class methods. Inheritance defines an
“is – a” relationship.

Example
From a class Mammal, a number of classes can be derived such as Human, Cat, Dog, Cow, etc.
Humans, cats, dogs, and cows all have the distinct characteristics of mammals. In addition,
each has its own particular characteristics. It can be said that a cow “is – a” mammal.

Types of Inheritance
i. Single inheritance: it is a type of inheritance in which a subclass derives/acquires it
characteristics from a single super-class.
ii. Multiple inheritance: it is a type of inheritance in which a subclass derives/acquires it
characteristics from more than one super-classes.
iii. Multilevel inheritance: it is a type of inheritance in which a subclass derives/acquires
it characteristics from a super-class which in turn is derived from another class and so
on.

3|Page
 DIT 0305: Object Oriented Analysis and Design

iv. Hierarchical inheritance: A class has a number of subclasses each of which may have
subsequent subclasses, continuing for a number of levels, so as to form a tree structure.
v. Hybrid Inheritance: A combination of multiple and multilevel inheritance so as to
form a lattice structure.

The following figure depicts the examples of different types of inheritance.

7. Polymorphism

4|Page
 DIT 0305: Object Oriented Analysis and Design

Polymorphism is originally a Greek word that means the ability to take multiple forms. It is a
mechanism in which different objects react differently to the same message.
Example
Let us consider two classes, Circle and Square, each with a method findArea(). Though the
name and purpose of the methods in the classes are same, the internal implementation, i.e., the
procedure of calculating area is different for each class. When an object of class Circle invokes
its findArea() method, the operation finds the area of the circle without any conflict with the
findArea() method of the Square class.

Types of Polymorphism
i. Compile time Polymorphism (or Static polymorphism)
Polymorphism that is resolved during compiler time is known as static polymorphism.
Method overloading is an example of compile time polymorphism.
Method Overloading: This allows us to have more than one method having the same
name, if the parameters of methods are different in number, sequence and data types of
parameters.
ii. Runtime Polymorphism (or Dynamic polymorphism)
Dynamic polymorphism is a process in which a call to an overridden method is resolved
at runtime. Method Overriding is what allows a subclass to replace methods on the
superclass with their own behaviour.

EXERCISE:
i. What is Object-Oriented Analysis? What is Object-Oriented Design? What is Object-
Oriented Analysis and Design?
ii. What are the main underlying concepts of Object Orientation?
iii. What do we mean by SBI of an object?
iv. What is inheritance? Discuss types of inheritance with example.
v. What is the difference between Multilevel and Multiple Inheritance?
vi. What is the difference between publicly derived inheritance and privately derived
inheritance?
vii. What do you mean by polymorphism? How Polymorphism is achieved at compile time
and run time? Give an example of the polymorphism.
viii. What is the difference between Polymorphism and Overloading?
ix. What do you mean by overloading of a function? When do you use this concept? Give
an example of function overloading.
x. What is method overriding? When does it occur? Explain with examples.
xi. What do you mean by data hiding? How to implement data hiding in C++? Give an
example.

5|Page
 DIT 0305: Object Oriented Analysis and Design

CLASSES
Terms and Concepts
A class is a description of a set of objects that share the same attributes, operations,
relationships, and semantics. Graphically, a class is rendered as a rectangle
i. Names: Every class must have a name that distinguishes it from other classes.

ii. Attributes: it is a named property of a class that describes a range of values that
instances of the property may hold. A class may have any number of attributes or
no attributes at all. An attribute represents some property of the thing we are
modelling that is shared by all objects of that class.
For example, every wall has a height, width, and thickness; we might model our
customers in such a way that each has a name, address, phone number, and date of
birth.
Graphically, attributes are listed in a compartment just below the class name.
Attributes may be drawn showing only their names.
iii. Operations: it is the implementation of a service that can be requested from any
object of the class to affect behavior. A class may have any number of operations
or no operations at all.

Rectangle

add()
grow()
move()

For example, all objects of the class Rectangle can be moved, resized, or queried for their
properties. Graphically, operations are listed in a compartment just below the class attributes.
Operations may be drawn showing only their names, as in Figure.

Access specifiers/Access modifiers/Class Visibility

They restrict the access of a class, constructor, data member and method in another class. They
define how the members (attributes and methods) of a class can be accessed.

There are three major types of access modifiers:

6|Page
 DIT 0305: Object Oriented Analysis and Design

i. Public: denoted by a positive sign (+). The access level of a public modifier is
everywhere. It can be accessed from within the class, outside the class, within the
package and outside the package.
ii. Private: denoted by a negative sign (-). The access level of a private modifier is only
within the class. It cannot be accessed from outside the class.
iii. Protected: denoted by a hash sign (#). The access level of a protected modifier is within
the package and outside the package through child class. If you do not make the child
class, it cannot be accessed from outside the package.

Relationships in Classes
Generalization and Specialization
Generalization and specialization represent a hierarchy of relationships between classes, where
subclasses inherit from super-classes.

1. Generalization
In the generalization process, the common characteristics of classes are combined to form a
class in a higher level of hierarchy, i.e., subclasses are combined to form a generalized super-
class. It represents an “is – a – kind – of” relationship. For example, “car is a kind of land
vehicle”, or “ship is a kind of water vehicle”.

2. Specialization
Specialization is the reverse process of generalization. Here, the distinguishing features of
groups of objects are used to form specialized classes from existing classes. It can be said that
the subclasses are the specialized versions of the super-class.

The following figure shows an example of generalization and specialization.

3. Link
A link represents a connection through which an object collaborates with other objects.
Through a link, one object may invoke the methods or navigate through another object.
A link depicts the relationship between two or more objects.

4. Association
Association is a group of links having common structure and common behavior. Association
depicts the relationship between objects of one or more classes. A link can be defined as an
instance of an association.

7|Page
 DIT 0305: Object Oriented Analysis and Design

Degree of an Association
Degree of an association denotes the number of classes involved in a connection. Degree may
be unary, binary, or ternary.
i. A unary relationship connects objects of the same class.
ii. A binary relationship connects objects of two classes.
iii. A ternary relationship connects objects of three or more classes.

Cardinality Ratios of Associations/Multiplicity

Cardinality of a binary association denotes the number of instances participating in an
association. There are three types of cardinality ratios, namely:
i. One–to–One: A single object of class A is associated with a single object of class B.
ii. One–to–Many: A single object of class A is associated with many objects of class B.
iii. Many–to–Many: An object of class A may be associated with many objects of class B
and conversely an object of class B may be associated with many objects of class A.

5. Aggregation
In this technique, all objects have their separate lifecycle. However, there is ownership such
that child object can’t belong to another parent object. For example consider class/objects
department and teacher. Here, a single teacher can’t belong to multiple departments, but even
if we delete the department, the teacher object will never be destroyed.

6. Composition
A composition is a specialized form of Aggregation. It is also called "death" relationship. Child
objects do not have their lifecycle so when parent object deletes all child object will also delete
automatically. For that, let’s take an example of House and rooms. Any house can have several
rooms. One room can’t become part of two different houses. So, if you delete the house, room
will also be deleted.

IDENTIFICATION OF OBJECTS FROM A PROBLEM DOMAIN.

Analysis activities include:
i. Identifying objects (often from use cases as a starting point)
ii. Identifying associations between objects
iii. Identifying general attributes and responsibilities of objects
iv. Modeling interactions between objects

Do examples:
Leave exercises.

8|Page
 DIT 0305: Object Oriented Analysis and Design

PHASES IN OBJECT-ORIENTED SOFTWARE DEVELOPMENT

The major phases of software development using object–oriented methodology are object-
oriented analysis, object-oriented design, object-oriented implementation and object oriented
testing.

1. Object-oriented analysis
Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a
conceptual model of the information that exists in the area being analyzed. The sources for the
analysis can be a written requirements statement, a formal vision document, interviews with
stakeholders or other interested parties. The result of object-oriented analysis is a
description of what the system is functionally required to do, in the form of a conceptual
model. That will typically be presented as a set of use cases, one or more UML class
diagrams, and a number of interaction diagrams.

2. Object-oriented design
Object-oriented design (OOD) transforms the conceptual model produced in object-
oriented analysis to take account of the constraints imposed by the chosen architecture
and any non-functional – technological or environmental – constraints, such as transaction
throughput, response time, run-time platform, development environment, or programming
language. The concepts in the analysis model are mapped onto implementation classes
and interfaces. The result is a model of the solution domain, a detailed description of how the
system is to be built.

3. Object-oriented implementation
In this stage, the design model developed in the object design is translated into code in an
appropriate programming language or software tool. The databases are created and the specific
hardware requirements are ascertained.

4. Object-oriented testing
Once the code is in shape, it is tested using specialized techniques to identify and remove the
errors in the code.

9|Page
 DIT 0305: Object Oriented Analysis and Design

UNIFIED MODELLING LANGUAGE (UML)

UML stands for Unified Modeling Language. UML is a standard language for specifying,
visualizing, constructing, and documenting the artifacts of software systems. It is a way of
visualizing a software program using a collection of diagrams.

Why Unified?
UML is unified across several domains:
Across historical methods and notations (Booch’s methodology, OMT and Objectory).
Across the development life cycle phases.
Across application domains.
Across implementation languages and platforms.
Across development platforms.
Across internal concepts.

The importance of Modeling

Through modeling, we achieve four aims.
1. Models help us to visualize a system as it is or as we want it to be.
2. Models permit us to specify the structure or behavior of a system.
3. Models give us a template that guides us in constructing a system.
4. Models document the decisions we have made.

Goals of UML
The primary goals in the design of the UML are as follows:
i. Provide users with a ready-to-use, expressive visual modeling language so they can
develop and exchange meaningful models.
ii. Provide extensibility and specialization mechanisms to extend the core concepts.
iii. Be independent of particular programming languages and development processes.
iv. Provide a formal basis for understanding the modeling language.
v. Encourage the growth of the OO tools market.
vi. Support higher-level development concepts such as collaborations, frameworks,
patterns and components.
vii. Integrate best practices.

UML Tools
There are many tools available in the market to generate UML diagrams. Some are desktop
based while others can be used online. Following is a curated list of tools which can be used
for the creation of UML models:
i. Microsoft Visio
ii. Star UML
iii. Argo UML
iv. Dia
v. Visual Paradigm
vi. U-Model
vii. UML lab
viii. Enterprise Architect

Types of UML Diagrams

10 | P a g e
 DIT 0305: Object Oriented Analysis and Design

The current UML standards call for 13 different types of diagrams: class, activity, object, use
case, sequence, package, state, component, communication, composite structure, interaction
overview, timing, and deployment.
These diagrams are organized into two distinct groups:
i. Structural diagrams
ii. Behavioral or interaction diagrams

1. Structural UML diagrams: These are used to represent a static view of a system.
It represents a part of a system that makes up the structure of a system. A structural
diagram shows various objects within the system.
They include Class diagram, Object diagram, Package diagram, Component diagram,
Deployment diagram.

2. Behavioral UML diagrams: They represents the functioning of a system. It deals

with the moving or dynamic parts of the system. Shows how the system behaves and
interacts with itself and other entities (users, other systems). They show how data
moves through the system, how objects communicate with each other, how the passage
of time affects the system, or what events cause the system to change internal states.
They include: Activity diagram, Use case diagram, State machine diagram.

3. Interaction diagrams: It is a subset of behavioral diagrams. It is used to visualize

the flow between various use case elements of a system. Interaction diagrams are used
to show an interaction between two entities and how data flows within them.
They include: Sequence diagram, Collaboration diagram.

EXERCISES:
i. What is the UML?
ii. What are the three ways and perspectives to Apply UML?

UML DIAGRAMS

1. USE CASE DIAGRAM

A use case diagram shows a set of use cases and actors and their relationships. Use case
diagrams give a graphic overview of the actors involved in a system, different functions needed
by those actors and how these different functions interact.

Symbols and notations

i. Actors: these are entities that interface with the system. They can be people or other
systems. Actors, which are external to the system they are using, are depicted as stylized
stick figures.
ii. Use cases: represents what the actors want your system to do for them. Figure depicts
some use cases, shown as ovals
A use case must be a complete flow of activity, from the actor’s point of view, that
provides value to the actor. A use case is a specific way of using the system by using
some part of the functionality.
iii. Boundary: shows the distinction between the inside of the system and the system
environment.

11 | P a g e
 DIT 0305: Object Oriented Analysis and Design

Ways of reusing use cases

i. Includes: You have a piece of behavior that is similar across many use cases. Break
this out as a separate use-case and let the other ones “include” it.
ii. Extends: A use-case is similar to another one but does a little bit more. Put the normal
behavior in one use-case and the exceptional behavior somewhere else

EXERCISE:
i. What are Use Case Diagrams?
ii. Define Use case.
iii. What are Actors? What are Three Kinds of Actors?
iv. Consider the Bookshop specified below.
The bookshop has a number of books from different titles. Each book may appear in
two versions: hard-cover or soft-cover and thus may have two different prices. A user
shops for a book by searching for the book title and receiving the prices of available
versions of the title. Afterwards, the user either pays the price and buys the book using
a credit card or cancels the purchase. Credit card payment concerns a credit card
number, name of the owner, expiration date and the amount to be withdrawn. A credit
card payment should be authorized by the bank. The bookshop owner can add books
(of possibly new titles) to its stock.
1. Draw a use case diagram for the system
2. Give a detailed description of each use case
v. Consider a transport company specified below.
The company owns a number of vehicles of different sizes, which can transport goods.
A client submits a request for transportation by specifying the size of the package to be
transported, its source and destination. The distance between source and target
determines the amount of time during which the vehicle will be en route. The company

12 | P a g e
 DIT 0305: Object Oriented Analysis and Design

then sends an offer to the client by finding the first possible period during which a
vehicle of an appropriate size is available. If the client agrees with the terms of the offer,
it provides an account number and the authorization to withdraw the amount of the offer
from the account. Upon a successful transaction with the bank (given the account
information provided by the user), the amount of money will be transferred to the
company’s account and the company will schedule the transport as specified in the
offer.
1. Draw a use case diagram for the system
2. Give a detailed description of each use case
vi. nm

2. CLASS DIAGRAM
Class diagrams shows the classes in a system, attributes, and operations of each class and the
relationship between each class.
A class has three parts. Name at the top, attributes in the middle and operations or methods at
the bottom. Many related classes are grouped together to create class diagrams. Different
relationships between classes are shown by different types of arrows.

UML Class Notation

Essential elements of A UML class diagram

i. Class Name: represents the name of the class.
ii. Attributes: is a named property of a class which describes the object being modeled.
iii. Operations: methods performed by the class. Services the class provides.
iv. Relationships: These are; dependencies, generalizations, associations.
A dependency means the relation between two or more classes in which a change in
one may force changes in the other. For example: a student has a dependency on
College.
A generalization helps to connect a subclass to its superclass. For example; a class
Student is generalized from Person Class.
Association represents static relationships between classes A and B. For example; an
employee works for an organization.
 Aggregation
Aggregation is a special type of association that models a whole- part relationship
between aggregate and its parts.
 Composition:
The composition is a special type of aggregation, which denotes strong ownership
between two classes when one class is a part of another class.

A relationship can be one of the following types:

13 | P a g e
 DIT 0305: Object Oriented Analysis and Design

Multiplicity/Cardinality
A multiplicity is a factor associated with an attribute. It specifies how many instances of
attributes are created when a class is initialized. If a multiplicity is not specified, by default one
is considered as a default multiplicity. One-to-One, One-to-Many, and Many-to-Many.

Class Visibility/Access specifier

The +, - and # symbols before an attribute and operation name in a class denote the visibility
of the attribute and operation.

Class Diagram Example: Order System

14 | P a g e
 DIT 0305: Object Oriented Analysis and Design

EXERCISE:
i. Draw a UML class symbol that has the following specification. The class is called
“Customer”. It has four attributes: name (which is text), address (also text), balance (a
number), and credit rating (type currently unknown). It has one operation:
“printStatement()”, which has no parameters or return value.
ii. Consider these three classes: Rectangle, Circle, and Line, which are subclasses of a
general Shape class. These classes have operations drawRectangle(), drawCircle(), and
drawLine() respectively. Each of these methods cause the appropriate shape to be
drawn. Draw a UML class. Is this system exhibiting polymorphism or not?
iii. Discuss object diagrams. Show it’s similarities and differences with a class diagram.

3. SEQUENCE DIAGRAM
Sequence diagrams in UML show how objects interact with each other and the order those
interactions occur. It’s important to note that they show the interactions for a particular
scenario. The processes are represented vertically and interactions are shown as arrows.
A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages;
Interaction diagrams address the dynamic view of a system.

Symbols and Notations

i. Object: Represents a class or object in UML.
ii. Lifeline: Represents the passage of time as it extends downward. This dashed vertical
line shows the sequential events that occur to an object during the charted process.
Lifelines may begin with a labeled rectangle shape or an actor symbol.
Lifeline Notation

15 | P a g e
 DIT 0305: Object Oriented Analysis and Design

iii. Activation box: Represents the time needed for an object to complete a task. It is placed
on the lifeline to indicate that an object is active during an interaction between two
objects. The length of the rectangle indicates the duration of the objects staying active.
In a sequence diagram, an interaction between two objects occurs when one object
sends a message to another. The use of the activation bar on the lifelines of the Message
Caller (the object that sends the message) and the Message Receiver (the object that
receives the message) indicates that both are active/is instantiated during the exchange
of the message.

iv. Messages
An arrow from the Message Caller to the Message Receiver specifies a message in a sequence
diagram. A message can flow in any direction; from left to right, right to left or back to the
Message Caller itself.
The message arrow comes with a description, which is known as a message signature, on it.

Types of messages in a sequence diagram

i. Synchronous message
Represented by a solid line with a solid arrowhead. This symbol is used when a sender must
wait for a response to a message before it continues. The diagram should show both the call
and the reply.
ii. Asynchronous message
Represented by a solid line with a lined arrowhead. Asynchronous messages don't require a
response before the sender continues. Only the call should be included in the diagram.

iii. Call Message

A call message defines a particular communication between lifelines of an interaction, which
represents an invocation of operation of target lifeline.

16 | P a g e
 DIT 0305: Object Oriented Analysis and Design

iv. Return Message

A return message defines a particular communication between lifelines of an interaction, which
represents the pass of information back to the caller of a corresponded former message.

v. Self Message
A self message defines a particular communication between lifelines of an interaction, which
represents the invocation of message of the same lifeline.

vi. Recursive Message

A recursive message defines a particular communication between lifelines of an interaction,
which represents the invocation of message of the same lifeline. It's target points to an
activation on top of the activation where the message was invoked from.

vii. Create Message

A create message defines a particular communication between lifelines of an interaction, which
represents the instantiation of (target) lifeline.

viii. Destroy Message

A destroy message defines a particular communication between lifelines of an interaction,
which represents the request of destroying the lifecycle of target lifeline.

17 | P a g e
 DIT 0305: Object Oriented Analysis and Design

ix. Duration Message

A duration message defines a particular communication between lifelines of an interaction,
which shows the distance between two time instants for a message invocation.

Example of a Sequence Diagram

EXERCISES:
To give an exam, an instructor first notifies the students of the exam date and the material to
be covered. She then prepares the exam paper (with sample solutions), gets it copied to produce
enough copies for the class, and hands it out to students on the designated time and location.
The students write their answers to exam questions and hand in their papers to the instructor.
The instructor then gives the exam papers to the TAs, along with sample solutions to each
question, and gets them to mark it. She then records all marks and returns the papers to the
students. Draw a sequence diagram that represents this process. Make sure to show when each
actor is participating in the process. Also, show the operation that is carried out during each
interaction, and what its arguments are.

4. COLLABORATION DIAGRAM
A collaboration diagram is an interaction diagram that emphasizes the structural organization
of the objects that send and receive messages.
It is similar to a Sequence diagram except that activation boxes are already action. We have a
link of association between the objects and messages are represented by arrows between the
objects. Sequence of message exchange is shown by prefixing some numbering scheme on the
messages.
It still uses actors and objects.
Example of UML collaboration showing the structure of ATM program.

18 | P a g e
 DIT 0305: Object Oriented Analysis and Design

5. ACTIVITY DIAGRAM
Activity diagrams represent workflows in a graphical way. They can be used to describe the
business workflow or the operational workflow of any component in a system.
An activity diagram is a special kind of a state chart diagram that shows the flow from activity
to activity within a system. The most important shape types: ellipses represent actions,
diamonds represent decisions, bars represent the start (split) or end (join) of concurrent
activities, a black circle represents the start (initial node) of the workflow, an encircled black
circle represents the end (final node). Arrows run from the start towards the end and represent
the order in which activities happen.

Activity Diagram Notations

i. Initial State or Start Point: The starting state before an activity takes place is
depicted using the initial state. A process can have only one initial state. We use a
black filled circle to depict the initial state of a system.

19 | P a g e
 DIT 0305: Object Oriented Analysis and Design

ii. Final State or End State: A final action state is shown using a circle surrounding
a small solid filled circle. An activity diagram may have only one initial action state,
but may have any number of final action states.

iii. Activity or Action State: An action state represents the non-interruptible action of
objects. Represented using a rectangle with rounded corners.

iv. Action Flow: Action flows, also called edges and paths, illustrate the transitions
from one action state to another. They are usually drawn with an arrowed line.

v. Decisions and Branching: A diamond represents a decision with alternate paths.

When an activity requires a decision prior to moving on to the next activity, add a
diamond between the two activities. The outgoing alternates should be labeled with
a condition or guard expression (guards are a statement written next to a decision
diamond that must be true before moving next to the next activity. For example;
YES or NO).

vi. Synchronization: A fork node is used to split a single incoming flow into multiple
concurrent flows. It is represented as a straight, slightly thicker line in an activity
diagram.
A join node joins multiple concurrent flows back into a single outgoing flow.
A fork and join mode used together are often referred to as synchronization.

20 | P a g e
 DIT 0305: Object Oriented Analysis and Design

vii. Swimlanes: Swimlanes group related activities into one column.

Activity Diagram Examples

Activity Diagram for ATM

21 | P a g e
 DIT 0305: Object Oriented Analysis and Design

EXERCISES:
i. Activity diagram of the online examination system.

6. STATE DIAGRAM (STATE CHART DIAGRAM)

State diagrams are similar to activity diagrams. They are very useful to describe the behavior
of objects that act differently according to the state they are in at the moment. A statechart
diagram shows a state machine, consisting of states, transitions, events, and activities.
Statechart diagrams address the dynamic view of a system.

STATE DIAGRAM NOTATIONS

22 | P a g e
 DIT 0305: Object Oriented Analysis and Design

i. State: A state is a condition during the life of an object which it may either satisfy some
condition for performing some activities, or waiting for some events to be received. An
object remains in a state for a finite amount of time. For example, a Heater in a home
might be in any of four states: Idle, Cooling, Heating, Initiating and Active.
ii. Transition: A transition is a relationship between two states indicating that an object
in the first state will perform certain actions and enter the second state when a specified
event occurs and specified conditions are satisfied. Transition fires means change of
state occurs.
iii. Initial state: it is indicated with a solid circle. A transition from this state will show the
first real state
iv. Final state: We use a filled circle within a circle notation to represent the final state in
a state machine diagram.

Example: An ordering system

7. COMPONENT DIAGRAM
A component diagram displays the structural relationship of components of a software system.
UML Component diagrams are used to represent different components of a system.
Components communicate with each other using interfaces. The interfaces are linked using
connectors.
A component diagram shows the organizations and dependencies among a set of components.
Use component diagrams when you are dividing your system into components and want to
show their interrelationships through interfaces.

Component Diagram Notations

i. Component: A component is a replaceable and executable piece of a system whose
implementation details are hidden. A component provides the set of interfaces that a
component realizes or implements. A component can be represented as just a rectangle

23 | P a g e
 DIT 0305: Object Oriented Analysis and Design

with the component's name and the component stereotype text and/or icon. The
component stereotype's text is "<<component>>" and the component stereotype icon is
a rectangle with two smaller rectangles protruding on its left side.

ii. Component Interfaces: The interface show how components are wired together
and interact with each other.

Types of interfaces
a. Provide Interface: Provided interfaces define "a set of public attributes and
operations that must be provided by the classes that implement a given interface".
b. Required Interface: Required interfaces define "a set of public attributes and
operations that are required by the classes that depend upon a given interface".

iii. Dependencies: Although you can show more detail about the relationship between
two components using the ball-and-socket notation (provided interface and required
interface), you can just as well use a dependency arrow to show the relationship
between two components.
iv. Component Assemblies: Components can be "wired" together using to form
subsystems, with the use of a ball-and-socket joint.

v. Port: A port (definition) indicates that the component itself does not provide the
required interfaces (e.g., required or provided). Instead, the component delegates
the interface(s) to an internal class.

24 | P a g e
 DIT 0305: Object Oriented Analysis and Design

Component diagram for Online Shopping System

8. DEPLOYMENT DIAGRAM
A deployment diagram shows the hardware of your system and the software in that hardware.
Deployment diagrams are useful when your software solution is deployed across multiple
machines with each having a unique configuration.
A deployment diagram shows the configuration of run-time processing nodes and the
components that live on them.

Deployment Diagram Notations

i. Component: A component is a grouping of classes that work together closely.
ii. Node: A node, represented as a cube, is a physical entity that executes one or more
components, subsystems or executables. A node could be a hardware or software
element.

iii. Connection: A connection depicts the communication path used by the hardware
to communicate usually indicates the method i.e. TCP/IP. This is represented by a
solid line between two nodes. It shows the path of communication between nodes.

iv. Artifact: Artifacts represent concrete elements in the physical world that are the
result of a development process. Examples of artifacts are executable files, libraries,
archives, database schemas, configuration files, etc.

25 | P a g e
 DIT 0305: Object Oriented Analysis and Design

Example of a deployment diagram.

9. PACKAGE DIAGRAM
Package diagram is UML structure diagram which shows packages and dependencies between
the packages.
A package is rendered as a tabbed folder - a rectangle with a small tab attached to the left side
of the top of the rectangle. If the members of the package are not shown inside the package
rectangle, then the name of the package should be placed inside.

Dependency
Dependency defines a relationship in which changes to one package will affect another
package. Importing is a type of dependency that grants one package access to the contents of
another package.

26 | P a g e
 DIT 0305: Object Oriented Analysis and Design

ROBUSTNESS ANALYSIS
Robustness analysis provides an approach to the structuring of problem situations in which
uncertainty is high, and where decisions can or must be staged sequentially. Robustness
analysis is a way for filling the gap between analysis (the what) and design (the how).

ROBUSTNESS ANALYSIS DIAGRAM

Robustness diagram is a nonstandard diagram type that is not supported by UML specification,
although it uses UML concepts. It uses stereotyped objects defined in UML: boundary object,
entity object and control object.

Robustness Analysis Objects/Elements

i. Boundary Object – Represents the interfaces between the actors and the system. Used
by actors when communicating with the system. These represent software elements
such as screens, reports, HTML pages, or system interfaces that actors interact with.
ii. Entity Object – Manages the information the system needs to provide the required
functionality.
iii. Control objects – The “glue” between boundary objects & entity objects,
implementing the logic required to manage the various elements and their interactions.
Also known as process elements or simply as controllers.

Other elements include:

27 | P a g e
 DIT 0305: Object Oriented Analysis and Design

iv. Actors. This is the same concept as actors on a UML use case diagram.
v. Use cases (optional). Because use cases can invoke other use cases you need to be able
to depict this on your robustness diagrams.

Why do Robustness Analysis?

It bridges the gap between Requirements and Design.
i. Sanity Check: Tests the language in the Use Case description. Nouns from the Use Case
get mapped onto objects. Verbs from the Use Case get mapped onto actions.
ii. Completeness Check: Discover the objects you need to implement the use cases.
Identify alternative courses of action.
iii. Object Identification: Decide which methods belong to which objects.

Robustness Diagram – 4 Connection Rules

Keep in mind that both boundary objects and entity objects are nouns and that controllers are
verbs. Nouns can’t talk to other nouns, but verbs can talk to either nouns or verbs.
Four basic connection rules which should always be mind:
1. Actors can only talk to boundary objects.
2. Boundary objects can only talk to controllers and actors.
3. Entity objects can only talk to controllers.
4. Controllers can talk to boundary objects, entity objects, and other controllers, but not
to actors.

28 | P a g e
 DIT 0305: Object Oriented Analysis and Design

Example 1: Robustness Analysis Diagram for search product.

1. Customer visits application home page.
2. Customer clicks Search button.
3. Search page is displayed by the system.
4. Customer enters search criteria.
5. The system validates the criteria provided.
6. The system looks up the catalog to find the products that meet the criteria.
7. Search results page is displayed with the products fulfilling the criteria.
Refine Search Results. The following steps are added:
8. Customer refines search results by providing additional criteria.
9. Steps 5–7 are re-executed.

Example 2: Robustness Analysis Diagram for search product.

1. Customer visits the Shopping cart page.
2. Customer clicks the Buy button.
3. The system displays the Order details form where the required data to complete the
order (name, phone number, email, shipping and billing addresses, payment method)
needs to be provided.
3.a. The system will retrieve information of the customer in order to populate a list of
default values.
4. Customer fills in data and submits Order details form by clicking the Confirm button.
5. The system records the order.
5.a. It retrieves shopping cart elements to add them to the order.
6. The system displays the Order created page.

29 | P a g e
DIT 0305: Object Oriented Analysis and Design

30 | P a g e