OBJECT ORIENTED ANALYSIS AND DESIGN (OOAD) REVISION

NOTES

The object-oriented paradigm took its shape from the initial concept of a
new programming approach, while the interest in design and analysis
methods came much later.

 The first object–oriented language was Simula (Simulation of real systems) that
was developed in 1960 by researchers at the Norwegian Computing Center.

 In 1970, Alan Kay and his research group at Xerox PARK created a personal
computer named Dynabook and the first pure object-oriented programming
language (OOPL) - Smalltalk, for programming the Dynabook.

 In the 1980s, Grady Booch published a paper titled Object Oriented Design that
mainly presented a design for the programming language, Ada. In the ensuing
editions, he extended his ideas to a complete object–oriented design method.

 In the 1990s, Coad incorporated behavioral ideas to object-oriented methods.

The other significant innovations were Object Modelling Techniques (OMT)

by James Rumbaugh and Object-Oriented Software Engineering (OOSE) by
Ivar Jacobson.

UML, (Unified Modeling Language): is a standardized modeling

language consisting of an integrated set of diagrams, developed to help
system and software developers for specifying, visualizing, constructing,
and documenting the artifacts of software systems, as well as for business
modeling and other non-software systems. The UML represents a
collection of best engineering practices that have proven successful in the
modeling of large and complex systems. The UML is a very important part
of developing object oriented software and the software development
process. The UML uses mostly graphical notations to express the design of
software projects. Using the UML helps project teams communicate,
explore potential designs, and validate the architectural design of the
software

Object-Oriented Analysis
Object–Oriented Analysis (OOA) is the procedure of identifying software
engineering requirements and developing software specifications in
terms of a software system’s object model, which comprises of
interacting objects.

The main difference between object-oriented analysis and other forms of

analysis is that in object-oriented approach, requirements are organized
around objects, which integrate both data and functions. They are
modelled after real-world objects that the system interacts with. In
traditional analysis methodologies, the two aspects - functions and data -
are considered separately.

Grady Booch has defined OOA as, “Object-oriented analysis is a method of

analysis that examines requirements from the perspective of the classes
and objects found in the vocabulary of the problem domain”.

The primary tasks in object-oriented analysis (OOA) are −

 Identifying objects

 Organizing the objects by creating object model diagram

 Defining the internals of the objects, or object attributes

 Defining the behavior of the objects, i.e., object actions

 Describing how the objects interact

The common models used in OOA are use cases and object models.

In the system analysis or object-oriented analysis phase of software

development, the system requirements are determined, the classes are
identified and the relationships among classes are identified.

The three analysis techniques that are used in conjunction with each other
for object-oriented analysis are object modelling, dynamic modelling, and
functional modelling.

1. Functional Modelling
Functional Modelling is the final component of object-oriented analysis. The
functional model shows the processes that are performed within an object
and how the data changes as it moves between methods. It specifies the
meaning of the operations of object modelling and the actions of dynamic
modelling. The functional model corresponds to the data flow diagram of
traditional structured analysis.
The process of functional modelling can be visualized in the following steps
−

 Identify all the inputs and outputs

 Construct data flow diagrams showing functional dependencies
 State the purpose of each function
 Identify constraints
 Specify optimization criteria
Functional Modelling gives the process perspective of the object-oriented
analysis model and an overview of what the system is supposed to do. It
defines the function of the internal processes in the system with the aid of
Data Flow Diagrams (DFDs). It depicts the functional derivation of the data
values without indicating how they are derived when they are computed, or
why they need to be computed.

Data Flow Diagrams

Functional Modelling is represented through a hierarchy of DFDs. The DFD is
a graphical representation of a system that shows the inputs to the system,
the processing upon the inputs, the outputs of the system as well as the
internal data stores. DFDs illustrate the series of transformations or
computations performed on the objects or the system, and the external
controls and objects that affect the transformation.

Rumbaugh et al. have defined DFD as, “A data flow diagram is a graph
which shows the flow of data values from their sources in objects through
processes that transform them to their destinations on other objects.”

The four main parts of a DFD are −

 Processes,
 Data Flows,
 Actors, and
 Data Stores.
The other parts of a DFD are −

 Constraints, and
  Control Flows.
Features of a DFD
Processes
Processes are the computational activities that transform data values. A
whole system can be visualized as a high-level process. A process may be
further divided into smaller components. The lowest-level process may be a
simple function.

Representation in DFD − A process is represented as an ellipse with its

name written inside it and contains a fixed number of input and output data
values.

Example − The following figure shows a process Compute_HCF_LCM that

accepts two integers as inputs and outputs their HCF (highest common
factor) and LCM (least common multiple).

Data Flows
Data flow represents the flow of data between two processes. It could be
between an actor and a process, or between a data store and a process. A
data flow denotes the value of a data item at some point of the
computation. This value is not changed by the data flow.

Representation in DFD − A data flow is represented by a directed arc or

an arrow, labelled with the name of the data item that it carries.

In the above figure, Integer_a and Integer_b represent the input data flows
to the process, while L.C.M. and H.C.F. are the output data flows.

A data flow may be forked in the following cases −

 The output value is sent to several places as shown in the following

figure. Here, the output arrows are unlabelled as they denote the
same value.
  The data flow contains an aggregate value, and each of the
components is sent to different places as shown in the following
figure. Here, each of the forked components is labelled.

Actors
Actors are the active objects that interact with the system by either
producing data and inputting them to the system, or consuming data
produced by the system. In other words, actors serve as the sources and
the sinks of data.

Representation in DFD − An actor is represented by a rectangle. Actors

are connected to the inputs and outputs and lie on the boundary of the
DFD.

Example − The following figure shows the actors, namely, Customer and
Sales_Clerk in a counter sales system.

Data Stores
Data stores are the passive objects that act as a repository of data. Unlike
actors, they cannot perform any operations. They are used to store data
and retrieve the stored data. They represent a data structure, a disk file, or
a table in a database.

Representation in DFD − A data store is represented by two parallel lines

containing the name of the data store. Each data store is connected to at
least one process. Input arrows contain information to modify the contents
of the data store, while output arrows contain information retrieved from
the data store. When a part of the information is to be retrieved, the output
arrow is labelled. An unlabelled arrow denotes full data retrieval. A two-way
arrow implies both retrieval and update.

Example − The following figure shows a data store, Sales_Record, that

stores the details of all sales. Input to the data store comprises of details of
sales such as item, billing amount, date, etc. To find the average sales, the
process retrieves the sales records and computes the average.

Constraints
Constraints specify the conditions or restrictions that need to be satisfied
over time. They allow adding new rules or modifying existing ones.
Constraints can appear in all the three models of object-oriented analysis.

 In Object Modelling, the constraints define the relationship between

objects. They may also define the relationship between the different
values that an object may take at different times.

 In Dynamic Modelling, the constraints define the relationship between

the states and events of different objects.

 In Functional Modelling, the constraints define the restrictions on the

transformations and computations.
Representation − A constraint is rendered as a string within braces.

Example − The following figure shows a portion of DFD for computing the
salary of employees of a company that has decided to give incentives to all
employees of the sales department and increment the salary of all
employees of the HR department. It can be seen that the constraint
{Dept:Sales} causes incentive to be calculated only if the department is
sales and the constraint {Dept:HR} causes increment to be computed only
if the department is HR.

Control Flows
A process may be associated with a certain Boolean value and is evaluated
only if the value is true, though it is not a direct input to the process. These
Boolean values are called the control flows.

Representation in DFD − Control flows are represented by a dotted arc

from the process producing the Boolean value to the process controlled by
them.

Example − The following figure represents a DFD for arithmetic division.

The Divisor is tested for non-zero. If it is not zero, the control flow OK has a
value True and subsequently the Divide process computes the Quotient and
the Remainder.
Developing the DFD Model of a System
In order to develop the DFD model of a system, a hierarchy of DFDs are
constructed. The top-level DFD comprises of a single process and the actors
interacting with it.

At each successive lower level, further details are gradually included. A

process is decomposed into sub-processes, the data flows among the sub-
processes are identified, the control flows are determined, and the data
stores are defined. While decomposing a process, the data flow into or out
of the process should match the data flow at the next level of DFD.

Example − Let us consider a software system, Wholesaler Software, that

automates the transactions of a wholesale shop. The shop sells in bulks and
has a clientele comprising of merchants and retail shop owners. Each
customer is asked to register with his/her particulars and is given a unique
customer code, C_Code. Once a sale is done, the shop registers its details
and sends the goods for dispatch. Each year, the shop distributes Christmas
gifts to its customers, which comprise of a silver coin or a gold coin
depending upon the total sales and the decision of the proprietor.

The functional model for the Wholesale Software is given below. The figure
below shows the top-level DFD. It shows the software as a single process
and the actors that interact with it.

The actors in the system are −

 Customers

 Salesperson
  Proprietor

In the next level DFD, as shown in the following figure, the major processes
of the system are identified, the data stores are defined and the interaction
of the processes with the actors, and the data stores are established.

In the system, three processes can be identified, which are −

 Register Customers

 Process Sales

 Ascertain Gifts

The data stores that will be required are −

 Customer Details

 Sales Details

 Gift Details
The following figure shows the details of the process Register Customer.
There are three processes in it, Verify Details, Generate C_Code, and
Update Customer Details. When the details of the customer are entered,
they are verified. If the data is correct, C_Code is generated and the data
store Customer Details is updated.
The following figure shows the expansion of the process Ascertain Gifts. It
has two processes in it, Find Total Sales and Decide Type of Gift Coin. The
Find Total Sales process computes the yearly total sales corresponding to
each customer and records the data. Taking this record and the decision of
the proprietor as inputs, the gift coins are allotted through Decide Type of
Gift Coin process.

Levels of DFD
DFD(data flow diagram) can be drawn to represent the system of different
levels of abstraction. Higher level DFDs are partitioned into low levels-
hacking more information and functional elements. Levels in DFD are
numbered 0, 1, 2 or beyond. Here, we will see mainly 3 levels in data flow
diagram, which are: 0-level DFD, 1-level DFD, and 2-level DFD.
0-level DFD:
It is also known as context diagram.It’s designed to be an abstraction view,
showing the system as a single process with its relationship to external
entities. It represent the entire system as single bubble with input and
output data indicated by incoming/outgoing arrows.
1-level DFD:
In 1-level DFD, context diagram is decomposed into multiple
bubbles/processes.in this level we highlight the main functions of the system
and breakdown the high level process of 0-level DFD into subprocesses.

2-level DFD:
2-level DFD goes one step deeper into parts of 1-level DFD.It can be used to
plan or record the specific/necessary detail about the system’s functioning.
 1. Object Modelling (static)
Object modelling develops the static structure of the software system in
terms of objects. It identifies the objects, the classes into which the objects
can be grouped into and the relationships between the objects. It also
identifies the main attributes and operations that characterize each class.

The process of object modelling can be visualized in the following steps −

 Identify objects and group into classes

 Identify the relationships among classes
 Create user object model diagram
 Define user object attributes
 Define the operations that should be performed on the classes
 Review glossary
Class Diagram:

Class Diagram gives the static view of an application. A class

diagram describes the types of objects in the system and the
different types of relationships that exist among them. This
modeling method can run with almost all Object-Oriented Methods.
A class can refer to another class. A class can have its objects or
may inherit from other classes.

UML Class Diagram gives an overview of a software system by

displaying classes, attributes, operations, and their relationships.
This Diagram includes the class name, attributes, and operation in
separate designated compartments.

Class Diagram helps construct the code for the software application
development.

Essential elements of A UML class diagram

Essential elements of UML class diagram are:

1. Class Name
2. Attributes
3. Operations

Class Name

The name of the class is only needed in the graphical representation

of the class. It appears in the topmost compartment. A class is the
blueprint of an object which can share the same relationships,
attributes, operations, & semantics. The class is rendered as a
rectangle, including its name, attributes, and operations in sperate
compartments.

Following rules must be taken care of while representing a class:

1. A class name should always start with a capital letter.

2. A class name should always be in the center of the first
compartment.
3. A class name should always be written in bold format.
4. An abstract class name should be written in italics format.

Attributes:
An attribute is named property of a class which describes the object
being modeled. In the class diagram, this component is placed just
below the name-compartment.

A derived attribute is computed from other attributes. For example,

an age of the student can be easily computed from his/her birth
date.
Attributes characteristics

 The attributes are generally written along with the visibility

factor.
 Public, private, protected and package are the four visibilities
which are denoted by +, -, #, or ~ signs respectively.
 Visibility describes the accessibility of an attribute of a class.
 Attributes must have a meaningful name that describes the
use of it in a class.

Relationships
There are mainly three kinds of relationships in UML:

1. Dependencies
2. Generalizations
3. Associations

Dependency

A dependency means the relation between two or more classes in

which a change in one may force changes in the other. However, it
will always create a weaker relationship. Dependency indicates that
one class depends on another.

In the following example, Student has a dependency on College

Generalization:

A generalization helps to connect a subclass to its superclass. A

sub-class is inherited from its superclass. Generalization relationship
can't be used to model interface implementation. Class diagram
allows inheriting from multiple superclasses.

In this example, the class Student is generalized from Person Class.

Association:

This kind of relationship represents static relationships between

classes A and B. For example; an employee works for an
organization.

Here are some rules for Association:

 Association is mostly verb or a verb phrase or noun or noun

phrase.
 It should be named to indicate the role played by the class
attached at the end of the association path.
 Mandatory for reflexive associations
In this example, the relationship between student and college is
shown which is studies.

Multiplicity

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.

Let's say that that there are 100 students in one college. The
college can have multiple students.

Aggregation

Aggregation is a special type of association that models a whole-

part relationship between aggregate and its parts.
For example, the class college is made up of one or more student.
In aggregation, the contained classes are never totally dependent
on the lifecycle of the container. Here, the college class will remain
even if the student is not available.

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.

For example, if college is composed of classes student. The college

could contain many students, while each student belongs to only
one college. So, if college is not functioning all the students also
removed.

Example of UML Class Diagram:

ATMs system is very simple as customers need to press some
buttons to receive cash. However, there are multiple security layers
that any ATM system needs to pass. This helps to prevent fraud and
provide cash or need details to banking customers.

Below given is a UML Class Diagram example:

Class Diagram in Software Development
Lifecycle
Class diagrams can be used in various software development
phases. It helps in modeling class diagrams in three different
perspectives.
1. Conceptual perspective: Conceptual diagrams are describing
things in the real world. You should draw a diagram that represents
the concepts in the domain under study. These concepts related to
class and it is always language-independent.

2. Specification perspective: Specification perspective describes

software abstractions or components with specifications and
interfaces. However, it does not give any commitment to specific
implementation.

3. Implementation perspective: This type of class diagrams is

used for implementations in a specific language or application.
Implementation perspective, use for software implementation.

Dynamic Modelling
After the static behavior of the system is analyzed, its behavior with respect
to time and external changes needs to be examined. This is the purpose of
dynamic modelling.

Dynamic Modelling can be defined as “a way of describing how an individual

object responds to events, either internal events triggered by other objects,
or external events triggered by the outside world”.

The process of dynamic modelling can be visualized in the following steps −

 Identify states of each object

 Identify events and analyze the applicability of actions
 Construct dynamic model diagram, comprising of state transition
diagrams
 Express each state in terms of object attributes
Validate the state–transition diagrams drawn

The following diagrams are used for dynamic modelling

1. Interaction diagrams :a) sequence diagrams

b) collaboration diagrams

2.Activity diagrams

3. Usecase diagrams
 4. State-machine diagrams

1. Sequence diagrams
Sequence Diagrams –
A sequence diagram simply depicts interaction between objects in a
sequential order i.e. the order in which these interactions take place. We can
also use the terms event diagrams or event scenarios to refer to a sequence
diagram. Sequence diagrams describe how and in what order the objects in
a system function. These diagrams are widely used by businessmen and
software developers to document and understand requirements for new and
existing systems.

Sequence Diagram Notations –

1. Actors – An actor in a UML diagram represents a type of role where it

interacts with the system and its objects. It is important to note here that an
actor is always outside the scope of the system we aim to model using the
UML diagram.

Figure – notation symbol for actor

We use actors to depict various roles including human users and other
external subjects. We represent an actor in a UML diagram using a stick
person notation. We can have multiple actors in a sequence diagram.
For example – Here the user in seat reservation system is shown as an
actor where it exists outside the system and is not a part of the system.
 Figure – an actor interacting with a seat reservation system

2. Lifelines – A lifeline is a named element which depicts an individual

participant in a sequence diagram. So basically each instance in a sequence
diagram is represented by a lifeline. Lifeline elements are located at the top in
a sequence diagram. The standard in UML for naming a lifeline follows the
following format – Instance Name : Class Name

Figure – lifeline

We display a lifeline in a rectangle called head with its name and type.
The head is located on top of a vertical dashed line (referred to as the
stem) as shown above. If we want to model an unnamed instance, we
follow the same pattern except now the portion of lifeline’s name is left
blank.
Difference between a lifeline and an actor – A lifeline always
portrays an object internal to the system whereas actors are used to
depict objects external to the system. The following is an example of a
sequence diagram:
 Figure – a sequence diagram

3. Messages – Communication between objects is depicted using messages. The

messages appear in a sequential order on the lifeline. We represent messages
using arrows. Lifelines and messages form the core of a sequence diagram.
Messages can be broadly classified into the following categories :

Figure – a sequence diagram with different types of messages

 Synchronous messages – A synchronous message waits for a reply

before the interaction can move forward. The sender waits until the
receiver has completed the processing of the message. The caller
continues only when it knows that the receiver has processed the
previous message i.e. it receives a reply message. A large number of calls
in object oriented programming are synchronous. We use a solid arrow
 head to represent a synchronous message.

Figure – a sequence diagram using a synchronous message

 Asynchronous Messages – An asynchronous message does not wait for

a reply from the receiver. The interaction moves forward irrespective of
the receiver processing the previous message or not. We use a lined
arrow head to represent an asynchronous message.

 Create message – We use a Create message to instantiate a new object

in the sequence diagram. There are situations when a particular message
call requires the creation of an object. It is represented with a dotted
arrow and create word labelled on it to specify that it is the create
Message symbol.
For example – The creation of a new order on a e-commerce website
 would require a new object of Order class to be created.

Figure – a situation where create message is used

 Delete Message – We use a Delete Message to delete an object. When

an object is deallocated memory or is destroyed within the system we use
the Delete Message symbol. It destroys the occurrence of the object in
the system.It is represented by an arrow terminating with a x.
For example – In the scenario below when the order is received by the
user, the object of order class can be destroyed.

Figure – a scenario where delete message is used

 Self Message – Certain scenarios might arise where the object needs to
send a message to itself. Such messages are called Self Messages and are
 represented with a U shaped arrow.

Figure – self message

For example – Consider a scenario where the device wants to

access its webcam. Such a scenario is represented using a self
message.

Figure – a scenario where a self message is used

 Reply Message – Reply messages are used to show the message being
sent from the receiver to the sender. We represent a return/reply
message using an open arrowhead with a dotted line. The interaction
moves forward only when a reply message is sent by the receiver.
 Figure – reply message

For example – Consider the scenario where the device requests a

photo from the user. Here the message which shows the photo
being sent is a reply message.

Figure – a scenario where a reply message is used

 Found Message – A Found message is used to represent a scenario

where an unknown source sends the message. It is represented using an
arrow directed towards a lifeline from an end point. For example:
Consider the scenario of a hardware failure.
 Figure – found message

It can be due to multiple reasons and we are not certain as to what

caused the hardware failure.

Figure – a scenario where found message is used

  Lost Message – A Lost message is used to represent a scenario where
the recipient is not known to the system. It is represented using an arrow
directed towards an end point from a lifeline. For example: Consider a
scenario where a warning is generated.

Figure – lost message

The warning might be generated for the user or other

software/object that the lifeline is interracting with. Since the
destination is not known before hand, we use the Lost Message
symbol.

Figure – a scenario where lost message is used

4. Guards – To model conditions we use guards in UML. They are used when we
need to restrict the flow of messages on the pretext of a condition being met.
Guards play an important role in letting software developers know the
constraints attached to a system or a particular process.
For example: In order to be able to withdraw cash, having a balance
greater than zero is a condition that must be met as shown below.

Figure – sequence diagram using a guard

A sequence diagram for an emotion based music player –

Figure – a sequence diagram for an emotion based music player

The above sequence diagram depicts the sequence diagram for an emotion
based music player:
1. Firstly the application is opened by the user.
2. The device then gets access to the web cam.
3. The webcam captures the image of the user.
4. The device uses algorithms to detect the face and predict the mood.
5. It then requests database for dictionary of possible moods.
6. The mood is retrieved from the database.
7. The mood is displayed to the user.
8. The music is requested from the database.
9. The playlist is generated and finally shown to the user.

Uses of sequence diagrams –

 Used to model and visualise the logic behind a sophisticated function,

operation or procedure.
 They are also used to show details of UML use case diagrams.
 Used to understand the detailed functionality of current or future systems.
  Visualise how messages and tasks move between objects or components in a
system.

2. Collaboration diagrams
Unlike a sequence diagram, a collaboration diagram shows the relationships
among the objects. Sequence diagrams and collaboration diagrams express
similar information, but show it in different ways.
Because of the format of the collaboration diagram, they tend to better
suited for analysis activities (see Activity: Use-Case
Analysis). Specifically, they tend to be better suited to depicting simpler
interactions of smaller numbers of objects. However, if the number of
objects and messages grows, the diagram becomes increasingly hard to
read. In addition, it is difficult to show additional descriptive information
such as timing, decision points, or other unstructured information that can
be easily added to the notes in a sequence diagram. So, here are some use
cases that we want to create a collaboration diagram for:
 Model collaborations between objects or roles that deliver the functionalities

of use cases and operations

 Model mechanisms within the architectural design of the system

 Capture interactions that show the messages passing between objects and

roles within the collaboration

 Model alternative scenarios within use cases or operations that involve the

collaboration of different objects and interactions

 Support the identification of objects (hence classes) that participate in use

cases

 Each message in a collaboration diagram has a sequence number.

 The top-level message is numbered 1. Messages sent during the same call

have the same decimal prefix but suffixes of 1, 2, etc. according to when

they occur.
Notations of Collaboration Diagram
Objects

An object is represented by an object symbol showing the name of the

object and its class underlined, separated by a colon:
Object_name : class_name
You can use objects in collaboration diagrams in the following ways:
 Each object in the collaboration is named and has its class specified

 Not all classes need to appear

 There may be more than one object of a class

 An object’s class can be unspecified. Normally you create a collaboration

diagram with objects first and specify their classes later.

 The objects can be unnamed, but you should name them if you want to

discriminate different objects of the same class.

Actors

Normally an actor instance occurs in the collaboration diagram, as the

invoker of the interaction. If you have several actor instances in the same
diagram, try keeping them in the periphery of the diagram.
 Each Actor is named and has a role

 One actor will be the initiator of the use case

Links

Links connect objects and actors and are instances of associations and each
link corresponds to an association in the class diagram
Links are defined as follows:
 A link is a relationship among objects across which messages can be sent.

In collaboration diagrams, a link is shown as a solid line between two

objects.

 An object interacts with, or navigates to, other objects through its links to

these objects.
  A link can be an instance of an association, or it can be anonymous,

meaning that its association is unspecified.

 Message flows are attached to links, see Messages.

Messages

A message is a communication between objects that conveys information

with the expectation that activity will ensue. In collaboration diagrams, a
message is shown as a labeled arrow placed near a link.
 The message is directed from sender to receiver

 The receiver must understand the message

 The association must be navigable in that direction

Steps for Creating Collaboration Diagrams

1. Identify behavior whose realization and implementation is specified

2. Identify the structural elements (class roles, objects, subsystems)

necessary to carry out the functionality of the collaboration

 Decide on the context of interaction: system, subsystem, use case

and operation

3. Model structural relationships between those elements to produce a

diagram showing the context of the interaction

4. Consider the alternative scenarios that may be required

 Draw instance level collaboration diagrams, if required.

 Optionally draw a specification level collaboration diagram to

summarize the alternative scenarios in the instance level sequence

diagrams

Collaboration Diagram Example

 3. Activity diagrams
 An activity diagram visually presents a series of actions or flow of
control in a system. Activities modeled can be sequential and
concurrent. In both cases an activity diagram will have a beginning (an
initial state) and an end (a final state).

Basic Activity Diagram Notations and Symbols

 Initial State or Start Point

 A small filled circle followed by an arrow represents the initial action
state or the start point for any activity diagram. For activity diagram
using swimlanes, make sure the start point is placed in the top left
corner of the first column.

 Activity or Action State

 An action state represents the non-interruptible action of objects. You
can draw an action state in SmartDraw using a rectangle with rounded
corners.


 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.

 Object Flow
 Object flow refers to the creation and modification of objects by
activities. An object flow arrow from an action to an object means that
the action creates or influences the object. An object flow arrow from
an object to an action indicates that the action state uses the object.

 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. You can also label one
of the paths "else."


 Guards
 In UML, guards are a statement written next to a decision diamond
that must be true before moving next to the next activity. These are
not essential, but are useful when a specific answer, such as "Yes,
three labels are printed," is needed before moving forward.

 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.


 Time Event
 This refers to an event that stops the flow for a time; an hourglass
depicts it.

 Merge Event
 A merge event brings together multiple flows that are not concurrent.

 Sent and Received Signals

 Signals represent how activities can be modified from outside the
system. They usually appear in pairs of sent and received signals,
because the state can't change until a response is received, much like
synchronous messages in a sequence diagram. For example, an
authorization of payment is needed before an order can be completed.

 Interrupting Edge
 An event, such as a cancellation, that interrupts the flow denoted with
a lightning bolt.


 Swimlanes
 Swimlanes group related activities into one column.


 Final State or End Point

 An arrow pointing to a filled circle nested inside another circle
represents the final action state.
 

Example:
Usecase diagrams
A use case diagram is a dynamic or behavior diagram in UML. Use case
diagrams model the functionality of a system using actors and use cases.
Use cases are a set of actions, services, and functions that the system needs
to perform. In this context, a "system" is something being developed or
operated, such as a web site. The "actors" are people or entities operating
under defined roles within the system.
Use case diagrams are valuable for visualizing the functional requirements of
a system that will translate into design choices and development priorities.
They also help identify any internal or external factors that may influence
the system and should be taken into consideration.
They provide a good high level analysis from outside the system. Use case
diagrams specify how the system interacts with actors without worrying
about the details of how that functionality is implemented.

Basic Use Case Diagram Symbols

and Notations
System
Draw your system's boundaries using a rectangle that contains use cases.
Place actors outside the system's boundaries.

Use Case
Draw use cases using ovals. Label the ovals with verbs that represent the
system's functions.

Actors
Actors are the users of a system. When one system is the actor of another
system, label the actor system with the actor stereotype.
Relationships
Illustrate relationships between an actor and a use case with a simple line.
For relationships among use cases, use arrows labeled either "uses" or
"extends." A "uses" relationship indicates that one use case is needed by
another in order to perform a task. An "extends" relationship indicates
alternative options under a certain use case.

Example:
State machine diagrams
tate machine diagram typically are used to describe state-dependent
behavior for an object. An object responds differently to the same
event depending on what state it is in. State machine diagrams are
usually applied to objects but can be applied to any element that has
behavior to other entities such as: actors, use cases, methods, subsystems
systems and etc. and they are typically used in conjunction with interaction
diagrams (usually sequence diagrams).
For example:
Consider you have $100,000 in a bank account. The behavior of the
withdraw function would be: balance := balance - withdrawAmount;
provided that the balance after the withdrawal is not less than $0; this
is true regardless of how many times you have withdrawn money from the
bank. In such situations, the withdrawals do not affect the abstraction of the
attribute values, and hence the gross behavior of the object remains
unchanged.
However, if the account balance would become negative after a
withdrawal, the behavior of the withdraw function would be quite different.
This is because the state of the bank account is changed from positive to
negative; in technical jargon, a transition from the positive state to the
negative state is fired.
The abstraction of the attribute value is a property of the system, rather
than a globally applicable rule. For example, if the bank changes the
business rule to allow the bank balance to be overdrawn by 2000 dollars, the
state of the bank account will be redefined with condition that the balance
after withdrawal must not be less than $2000 in deficit.
Note That:
 A state machine diagram describes all events (and states and transitions for
a single object)
  A sequence diagram describes the events for a single interaction across all
objects involved
Basic Concepts of State Machine Diagram
What is a State?

Rumbaugh defines that:

"A state is an abstraction of the attribute values and links of an object. Sets
of values are grouped together into a state according to properties that
affect the gross behavior of the object."

State Notation

Characteristics of State Machine Notations

There are several characteristics of states in general, regardless of their
types:
 A state occupies an interval of time.
 A state is often associated with an abstraction of attribute values of an entity
satisfying some condition(s).
 An entity changes its state not only as a direct consequence of the current
input, but it is also dependent on some past history of its inputs.

State

A state is a constraint or a situation in the life cycle of an object, in which a

constraint holds, the object executes an activity or waits for an event.
A state machine diagram is a graph consisting of:
 States (simple states or composite states)
 State transitions connecting the states
Example:
Characteristics of State
 State represent the conditions of objects at certain points in time.
 Objects (or Systems) can be viewed as moving from state to state
 A point in the lifecycle of a model element that satisfies some condition,
where some particular action is being performed or where some event is
waited

Initial and Final States

 The initial state of a state machine diagram, known as an initial pseudo-
state, is indicated with a solid circle. A transition from this state will show the
first real state
 The final state of a state machine diagram is shown as concentric circles. An
open loop state machine represents an object that may terminate before the
system terminates, while a closed loop state machine diagram does not have
a final state; if it is the case, then the object lives until the entire system
terminates.

Example:

Events

An event signature is described as Event-name (comma-separated-

parameter-list). Events appear in the internal transition compartment of a
state or on a transition between states. An event may be one of four types:
1. Signal event - corresponding to the arrival of an asynchronous message or
signal
2. Call event - corresponding to the arrival of a procedural call to an operation
3. Time event - a time event occurs after a specified time has elapsed
4. Change event - a change event occurs whenever a specified condition is met
Characteristics of Events
 Represents incidents that cause objects to transition from one state to
another.
 Internal or External Events trigger some activity that changes the state of
the system and of some of its parts
 Events pass information, which is elaborated by Objects operations. Objects
realize Events
 Design involves examining events in a state machine diagram and
considering how those events will be supported by system objects

Transition

Transition lines depict the movement from one state to another. Each
transition line is labeled with the event that causes the transition.
 Viewing a system as a set of states and transitions between states is very
useful for describing complex behaviors
 Understanding state transitions is part of system analysis and design
 A Transition is the movement from one state to another state
 Transitions between states occur as follows:
1. An element is in a source state
2. An event occurs
3. An action is performed
4. The element enters a target state
 Multiple transitions occur either when different events result in a state
terminating or when there are guard conditions on the transitions
 A transition without an event and action is known as automatic transitions

Actions

Action is an executable atomic computation, which includes operation calls,

the creation or destruction of another object, or the sending of a signal to an
object. An action is associated with transitions and during which an action is
not interruptible - e.g., entry, exit

Activity

Activity is associated with states, which is a non-atomic or ongoing

computation. Activity may run to completion or continue indefinitely. An
Activity will be terminated by an event that causes a transition from the
state in which the activity is defined
Characteristics of Action and Activities
 States can trigger actions
  States can have a second compartment that contains actions or activities
performed while an entity is in a given state
 An action is an atomic execution and therefore completes without
interruption
 Five triggers for actions: On Entry, Do, On Event, On Exit, and Include
 An activity captures complex behavior that may run for a long duration - An
activity may be interrupted by events, in which case it does not complete
occur when an object arrives in a state.
Simple State Machine Diagram Notation

Entry and Exit Actions

Entry and Exit actions specified in the state. It must be true for every entry /
exit occurrence. If not, then you must use actions on the individual
transition arcs
 Entry Action executed on entry into state with the notation: Entry /
action
 Exit Action executed on exit from state with the notation: Exit / action
Example - Entry / Exit Action (Check Book Status)

This example illustrates a state machine diagram derived from a Class -

"BookCopy":
Object-Oriented Design
Object–Oriented Design (OOD) involves implementation of the conceptual
model produced during object-oriented analysis. In OOD, concepts in the
analysis model, which are technology−independent, are mapped onto
implementing classes, constraints are identified and interfaces are
designed, resulting in a model for the solution domain, i.e., a detailed
description of how the system is to be built on concrete technologies.

The implementation details generally include −

 Restructuring the class data (if necessary),

 Implementation of methods, i.e., internal data structures and algorithms,

 Implementation of control, and

 Implementation of associations.

Grady Booch has defined object-oriented design as “a method of design

encompassing the process of object-oriented decomposition and a notation
for depicting both logical and physical as well as static and dynamic models
of the system under design”.

After the analysis phase, the conceptual model is developed further into an
object-oriented model using object-oriented design (OOD). In OOD, the
technology-independent concepts in the analysis model are mapped
onto implementing classes, constraints are identified, and
interfaces are designed, resulting in a model for the solution
domain. In a nutshell, a detailed description is constructed
specifying how the system is to be built on concrete technologies

The stages for object–oriented design can be identified as −

 Definition of the context of the system

 Designing system architecture

 Identification of the objects in the system

 Construction of design models

 Specification of object interfaces

System Design
Object-oriented system design involves defining the context of a system
followed by designing the architecture of the system.

 Context − The context of a system has a static and a dynamic part. The static
context of the system is designed using a simple block diagram of the whole
system which is expanded into a hierarchy of subsystems. The subsystem
model is represented by UML packages. The dynamic context describes how the
system interacts with its environment. It is modelled using use case
diagrams.

 System Architecture − The system architecture is designed on the basis of the

context of the system in accordance with the principles of architectural design
as well as domain knowledge. Typically, a system is partitioned into layers a

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 −

  Bottom–up approach in program design

 Programs organized around objects, grouped in classes

 Focus on data with methods to operate upon object’s data

 Interaction between objects through functions

 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.

Grady Booch has defined object–oriented programming as “a method of

implementation in which programs are organized as cooperative collections
of objects, each of which represents an instance of some class, and whose
classes are all members of a hierarchy of classes united via inheritance
relationships”.