Subject Name: Object Oriented Analysis and Design

Subject Code: IT-7002

Semester: 7th
Downloaded from be.rgpvnotes.in

UNIT-II

Software Development Life Cycle, SDLC for short, is a well-defined, structured sequence of stages in
software engineering to develop the intended software product.

SDLC Activities:
SDLC provides a series of steps to be followed to design and develop a software product efficiently. SDLC
framework includes the following steps:

Figure 2.1: SDLC Activities

Communication:
This is the first step where the user initiates the request for a desired software product. He contacts the
service provider and tries to negotiate the terms. He submits his request to the service providing
organization in writing.

Requirement Gathering:
This step onwards the software development team works to carry on the project. The team holds
discussions with various stakeholders from problem domain and tries to bring out as much information as
possible on their requirements. The requirements are contemplated and segregated into user
requirements, system requirements and functional requirements. The requirements are collected using a
number of practices as given -
o studying the existing or obsolete system and software,
o conducting interviews of users and developers,
o referring to the database or
o Collecting answers from the questionnaires.

Page no: 1 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Feasibility Study:
After requirement gathering, the team comes up with a rough plan of software process. At this step the
team analyzes if software can be made to fulfill all requirements of the user and if there is any possibility of
software being no more useful. It is found out, if the project is financially, practically and technologically
feasible for the organization to take up. There are many algorithms available, which help the developers to
conclude the feasibility of a software project.

System Analysis:
At this step the developers decide a roadmap of their plan and try to bring up the best software model
suitable for the project. System analysis includes Understanding of software product limitations, learning
system related problems or changes to be done in existing systems beforehand, identifying and addressing
the impact of project on organization and personnel etc. The project team analyzes the scope of the
project and plans the schedule and resources accordingly.

Software Design:
Next step is to bring down whole knowledge of requirements and analysis on the desk and design the
software product. The inputs from users and information gathered in requirement gathering phase are the
inputs of this step. The output of this step comes in the form of two designs; logical design and physical
design. Engineers produce meta-data and data dictionaries, logical diagrams, data-flow diagrams and in
some cases pseudo codes.

Coding:
This step is also known as programming phase. The implementation of software design starts in terms of
writing program code in the suitable programming language and developing error-free executable
programs efficiently.

Testing:
An estimate says that 50% of whole software development process should be tested. Errors may ruin the
software from critical level to its own removal. Software testing is done while coding by the developers and
thorough testing is conducted by testing experts at various levels of code such as module testing, program
testing, product testing, in-house testi g a d testi g the p odu t at use ’s e d. Ea l dis overy of errors
and their remedy is the key to reliable software.

Integration:
Software may need to be integrated with the libraries, databases and other program(s). This stage of SDLC
is involved in the integration of software with outer world entities.

Implementation:
This means installing the software on user machines. At times, software needs post-installation
configurations at user end. Software is tested for portability and adaptability and integration related issues
are solved during implementation.

Operation and Maintenance:

This phase confirms the software operation in terms of more efficiency and less errors. If required, the
users are trained on, or aided with the documentation on how to operate the software and how to keep
the software operational. The software is maintained timely by updating the code according to the changes
taking place in user end environment or technology. This phase may face challenges from hidden bugs and
real-world unidentified problems.

Disposition:
As time elapses, the software may decline on the performance front. It may go completely obsolete or may
need intense up gradation. Hence a pressing need to eliminate a major portion of the system arises. This

Page no: 2 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

phase includes archiving data and required software components, closing down the system, planning
disposition activity and terminating system at appropriate end-of-system time.

Object–Oriented Analysis (OOA) is the procedure of identifying software engineering requirements and
de elopi g soft a e spe ifi atio s i te s of a soft a e s ste ’s o je t odel, hi h o p ises of
interacting objects.
The primary tasks in object-oriented analysis (OOA) are:
 Find the objects
 Organize the objects
 Describe how the objects interact
 Define the behavior of the objects
 Define the internals of the 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
modeled after real-world objects that the system interacts with. In traditional analysis methodologies, the
two aspects - functions and data - are considered separately.

Controlling Events:
During system design, the events that may occur in the objects of the system need to be identified and
appropriately dealt with.
An event is a specification of a significant occurrence that has a location in time and space.
There are four types of events that can be modeled, namely:
Signal Event: A named object thrown by one object and caught by another object.
Call Event: A synchronous event representing dispatch of an operation.
Time Event: An event representing passage of time.
Change Event: An event representing change in state.

Handling Boundary Conditions:

The system design phase needs to address the initialization and the termination of the system as a whole
as well as each subsystem. The different aspects that are documented are as follows:
o The start–up of the system, i.e., the transition of the system from non-initialized state to steady
state.
o The termination of the system, i.e., the closing of all running threads, cleaning up of resources, and
the messages to be sent.
o The initial configuration of the system and the reconfiguration of the system when needed.
o Foreseeing failures or undesired termination of the system.
o Boundary conditions are modeled using boundary use cases.

Software Development Paradigm:

The software development paradigm helps developer to select a strategy to develop the software. A
software development paradigm has its own set of tools, methods and procedures, which are expressed
clearly and defines software development life cycle. A few of software development paradigms or process
models are defined as follows:

Waterfall Model:
Waterfall model is the simplest model of software development paradigm. It says the all the phases of
SDLC will function one after another in linear manner. That is, when the first phase is finished then only the
second phase will start and so on.

Page no: 3 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Figure 2.2: Waterfall Model

This model assumes that everything is carried out and taken place perfectly as planned in the previous
stage and there is no need to think about the past issues that may arise in the next phase. This model does
not work smoothly if there are some issues left at the previous step. The sequential nature of model does
not allow us go back and undo or redo our actions.
This model is best suited when developers already have designed and developed similar software in the
past and are aware of all its domains

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

Object Modelling:
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

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.
D a i Modelli g a e defi ed as a a of des i i g ho a i di idual o je t espo ds to e e ts,
eithe i te al e e ts t igge ed othe o je ts, o e te al e e ts t igge ed the outside o ld .
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

Page no: 4 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

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

Structured Analysis vs. Object Oriented Analysis:

The Structured Analysis/Structured Design (SASD) approach is the traditional approach of software
development based upon the waterfall model. The phases of development of a system using SASD are:
 Feasibility Study
 Requirement Analysis and Specification
 System Design
 Implementation
 Post-implementation Review
Now, we will look at the relative advantages and disadvantages of structured analysis approach and object-
oriented analysis approach.

Advantages/Disadvantages of Object Oriented Analysis:

Advantages Disadvantages
Focuses on data rather than the procedures as in Functionality is restricted within objects. This may
Structured Analysis. pose a problem for systems which are intrinsically
procedural or computational in nature.
The principles of encapsulation and data hiding It cannot identify which objects would generate an
help the developer to develop systems that cannot optimal system design.
be tampered by other parts of the system.
The principles of encapsulation and data hiding The object-oriented models do not easily show the
help the developer to develop systems that cannot communications between the objects in the system.
be tampered by other parts of the system.
It allows effective management of software All the interfaces between the objects cannot be
complexity by the virtue of modularity. represented in a single diagram.
It can be upgraded from small to large systems at a
greater ease than in systems following structured
analysis.

Advantages/Disadvantages of Structured Analysis:

Advantages Disadvantages
As it follows a top-down approach in contrast to bottom- In traditional structured analysis models, one
up approach of object-oriented analysis, it can be more phase should be completed before the next
easily comprehended than OOA. phase. This poses a problem in design,
particularly if errors crop up or requirements
change.

Page no: 5 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

It is based upon functionality. The overall purpose is The initial cost of constructing the system is
identified and then functional decomposition is done for high, since the whole system needs to be
developing the software. The emphasis not only gives a designed at once leaving very little option to
better understanding of the system but also generates add functionality later.
more complete systems.
The specifications in it are written in simple English It does not support reusability of code. So,
language, and hence can be more easily analyzed by non- the time and cost of development is
technical personnel. inherently high.

Object Modeling Technique:

The object modeling techniques is an methodology of object oriented analysis, design and implementation
that focuses on creating a model of objects from the real world and then to use this model to develop
object–oriented software. Object modeling technique, OMT was developed by James Rambaugh. Now-a-
days, OMT is one of the most popular object oriented development techniques. It is primarily used by
system and software developers to support full life cycle development while targeting object oriented
implementations.
OMT has proven itself easy to understand, to draw and to use. It is very successful in many application
domains: telecommunication, transportation, compilers etc. The popular object modeling techniques are
used in many real world problems. The object-oriented paradigm using the OMT spans the entire
development cycle, so there is no need to transform one type of model to another.

Phase of OMT:
The OMT methodology covers the full software development life cycle. The methodology has the following
phase.
1. Analysis - Analysis is the first phase of OMT methodology. The aim of analysis phase is to build a
model of the real world situation to show its important properties and domain. This phase is
concerned with preparation of precise and correct modelling of the real world. The analysis phase
starts with defining a problem statement which includes a set of goals. This problem statement is
then expanded into three models; an object model, a dynamic model and a functional model. The
object model shows the static data structure or skeleton of the real world system and divides the
whole application into objects. In others words, this model represents the artifacts of the system.
The dynamic model represents the interaction between artifacts above designed represented as
events, states and transitions. The functional model represents the methods of the system from the
data flow perspective. The analysis phase generates object model diagrams, state diagrams, event
flow diagrams and data flow diagrams.
2. System design - The system design phase comes after the analysis phase. System design phase
determines the overall system architecture using subsystems, concurrent tasks and data storage.
During system design, the high level structure of the system is designed. The decisions made during
system design are:
o The system is organized in to sub-systems which are then allocated to processes and tasks,
taking into account concurrency and collaboration.
o Persistent data storage is established along with a strategy to manage shared or global
information.
o Boundary situations are checked to help guide trade off priorities.
3. Objects design - The object design phase comes after the system design phase is over. Here the
implementation plan is developed. Object design is concerned with fully classifying the existing and
remaining classes, associations, attributes and operations necessary for implementing a solution to
the problem. In object design:
o Operations and data structures are fully defined along with any internal objects needed for
implementation.
o Class level associations are determined.
o Issues of inheritance, aggregation, association and default values are checked.

Page no: 6 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

4. Implementation - Implementation phase of the OMT is a matter of translating the design in to a

programming language constructs. It is important to have good software engineering practice so
that the design phase is smoothly translated in to the implementation phase. Thus while selecting
programming language all constructs should be kept in mind for following noteworthy points.
o To increase flexibility.
o To make amendments easily.
o For the design traceability.
o To increase efficiency.

Object Model:
o It represents the static structure of the application.
o It specifies to whom it happens to.
o Operations in an object model corresponds to events in dynamic model and functions in functional
model.
o It is represented using class diagrams.

Dynamic Model:
o It represents the essential behavior of the application.
o It specifies when it happens.
o Dynamic model describes the control structure of the objects. It defines decisions which are
dependents of object values and which can cause action to change object values and invoke their
functions.
o It is represented using state diagrams.

Functional Model:
o It represents what the application does and not how it does.
o It specifies what happens.
o It describes functions to be invoked by operations in object model and actions in dynamic models.
o It is represented using data flow diagrams.

Data Flow Diagram:

Data Flow Diagram (DFD) provides a visual representation of the flow of information (i.e. data) within a
system. By drawing a Data Flow Diagram, you can tell the information provided by and delivered to
someone who takes part in system processes, the information needed in order to complete the processes
and the information needed to be stored and accessed. This article describes and explains Data Flow
Diagram (DFD) by using a food ordering system as an example.
A context diagram is a data flow diagram that only shows the top level, otherwise known as Level 0. At this
level, there is only one visible process node that represents the functions of a complete system in regards
to how it interacts with external entities. Some of the benefits of a Context Diagram are:
o Shows the overview of the boundaries of a system
o No technical knowledge is required to understand with the simple notation
o Simple to draw, amend and elaborate as its limited notation
The figure below shows a context Data Flow Diagram that is drawn for a Food Ordering System. It contains
a process (shape) that represents the system to model, in this case, the "Food Ordering System". It also
shows the participants who will interact with the system, called the external entities. In this example,
Supplier, Kitchen, Manager and Customer are the entities who will interact with the system. In between
the process and the external entities, there are data flow (connectors) that indicate the existence of
information exchange between the entities and the system.

Page no: 7 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Figure 2.3: Data Flow Diagram

Context DFD is the entrance of a data flow model. It contains one and only one process and does not show
any data store.
Level 1 DFD
The figure below shows the level 1 DFD, which is the decomposition (i.e. break down) of the Food Ordering
System process shown in the context DFD. Read through the diagram and then we will introduce some of
the key concepts based on this diagram.

Figure 2.4: Level 1 DFD

Page no: 8 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Object Modeling Techniques:

OMT was developed as an approach to software development. A fundamental assumption of OMT is that
object-oriented thinking represents a more natural and intuitive way for people to reason about reality,
although this claim has been severely questioned
The purposes of modeling are:
o Testing physical entities before building them (simulation)
o Communication with customers
o Visualization (alternative presentation of information)
o Reduction of complexity.

As a general modeling approach, OMT may be used to model all types of work.
OMT proposes three main types of models:
Dynamic Model:
The dynamic model represents a state/transition view on the model. Main concepts are states, transitions
between states, and events to trigger transitions. Actions can be modeled as occurring within states.
Generalization and aggregation (concurrency) are predefined relationships.
The dynamic model represents the time–dependent aspects of a system. It is concerned with the temporal
changes in the states of the objects in a system. The main concepts are:
o State, which is the situation at a particular condition during the lifetime of an object
o Transition, a change in the state
o Event, an occurrence that triggers transitions
o Action, an uninterrupted and atomic computation that occurs due to some event.
o Concurrency of transitions.
A state machine models the behavior of an object as it passes through a number of states in its lifetime
due to some events as well as the actions occurring due to the events. A state machine is graphically
represented through a state transition diagram.

States and State Transitions

State:
The state is an abstraction given by the values of the attributes that the object has at a particular time
period. It is a situation occurring for a finite time period in the lifetime of an object, in which it fulfils
certain conditions, performs certain activities, or waits for certain events to occur. In state transition
diagrams, a state is represented by rounded rectangles.

Parts of a state:
o Name: A string differentiates one state from another. A state may not have any name.
o Entry/Exit Actions: It denotes the activities performed on entering and on exiting the state.
o Internal Transitions: The changes within a state that do not cause a change in the state.
o Sub–states: States within states.

Initial and Final States:

The default starting state of an object is called its initial state. The final state indicates the completion of
execution of the state machine. The initial and the final states are pseudo-states, and may not have the
parts of a regular state except name. In state transition diagrams, the initial state is represented by a filled
black circle. The final state is represented by a filled black circle encircled within another unfilled black
circle.

Transition:
A transition denotes a change in the state of an object. If an object is in a certain state when an event
occurs, the object may perform certain activities subject to specified conditions and change the state. In
this ase, a state−t a sitio is said to have occurred. The transition gives the relationship between the first

Page no: 9 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

state and the new state. A transition is graphically represented by a solid directed arc from the source state
to the destination state.
The five parts of a transition are:
o Source State: The state affected by the transition.
o Event Trigger: The occurrence due to which an object in the source state undergoes a transition if
the guard condition is satisfied.
o Guard Condition: A Boolean expression which if True, causes a transition on receiving the event
trigger.
o Action: An un-interruptible and atomic computation that occurs on the source object due to some
event.
o Target State: The destination state after completion of transition.

Example:
Suppose a person is taking a taxi from place X to place Y. The states of the person may be: Waiting (waiting
for taxi), Riding (he has got a taxi and is travelling in it), and Reached (he has reached the destination). The
following figure depicts the state transition.

Figure 2.5: State Transition Diagram

Events:
Events are some occurrences that can trigger state transition of an object or a group of objects. Events
have a location in time and space but do not have a time period associated with it. Events are generally
associated with some actions.
Examples of events are mouse click, key press, an interrupt, stack overflow, etc.
Events that trigger transitions are written alongside the arc of transition in state diagrams.
Example:
Considering the example shown in the above figure, the transition from waiting state to Riding state takes
place when the person gets a taxi. Likewise, the final state is reached, when he reaches the destination.
These two occurrences can be termed as events Get_Taxi and Reach_Destination. The following figure
shows the events in a state machine.

Figure 2.6: State Machine

External and Internal Events:
External events are those events that pass from a user of the system to the objects within the system. For
e a ple, ouse li k o ke −p ess the use a e e te al e e ts.

Page no: 10 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Internal events are those that pass from one object to another object within a system. For example, stack
overflow, a divide error, etc.

Deferred Events:
Deferred events are those which are not immediately handled by the object in the current state but are
lined up in a queue so that they can be handled by the object in some other state at a later time.

Event Classes:
Event class indicates a group of events with common structure and behavior. As with classes of objects,
event classes may also be organized in a hierarchical structure. Event classes may have attributes
associated with them, time being an implicit attribute. For example, we can consider the events of
departure of a flight of an airline, which we can group into the following class:
Flight_Departs (Flight_No, From_City, To_City, Route)

Activity:
Activity is an operation upon the states of an object that requires some time period. They are the ongoing
executions within a system that can be interrupted. Activities are shown in activity diagrams that portray
the flow from one activity to another.

Action:
An action is an atomic operation that executes as a result of certain events. By atomic, it is meant that
actions are un-interruptible, i.e., if an action starts executing, it runs into completion without being
interrupted by any event. An action may operate upon an object on which an event has been triggered or
on other objects that are visible to this object. A set of actions comprise an activity.

Entry and Exit Actions:

Entry action is the action that is executed on entering a state, irrespective of the transition that led into it.
Likewise, the action that is executed while leaving a state, irrespective of the transition that led out of it, is
called an exit action.

Scenario:
Scenario is a description of a specified sequence of actions. It depicts the behavior of objects undergoing a
specific action series. The primary scenarios depict the essential sequences and the secondary scenarios
depict the alternative sequences.

Diagrams for Dynamic Modelling

There are two primary diagrams that are used for dynamic modelling:
Interaction Diagrams:
Interaction diagrams describe the dynamic behavior among different objects. It comprises of a set of
objects, their relationships, and the message that the objects send and receive. Thus, an interaction
models the behavior of a group of interrelated objects. The two types of interaction diagrams are:
o Sequence Diagram: It represents the temporal ordering of messages in a tabular manner.
o Collaboration Diagram: It represents the structural organization of objects that send and receive
messages through vertices and arcs.

State Transition Diagram:

State transition diagrams or state machines describe the dynamic behavior of a single object. It illustrates
the sequences of states that an object goes through in its lifetime, the transitions of the states, the events
and conditions causing the transition and the responses due to the events.

Concurrency of Events:
In a system, two types of concurrency may exist. They are:

Page no: 11 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

System Concurrency:
Here, concurrency is modelled in the system level. The overall system is modelled as the aggregation of
state machines, where each state machine executes concurrently with others.
Concurrency within an Object
Here, an object can issue concurrent events. An object may have states that are composed of sub-states,
and concurrent events may occur in each of the sub-states.
Concepts related to concurrency within an object are as follows:
(a) Simple and Composite States
A simple state has no sub-structure. A state that has simpler states nested inside it is called a composite
state. A sub-state is a state that is nested inside another state. It is generally used to reduce the complexity
of a state machine. Sub-states can be nested to any number of levels.
Composite states may have either sequential sub-states or concurrent sub-states.
(b) Sequential Sub-states
In sequential sub-states, the control of execution passes from one sub-state to another sub-state one after
another in a sequential manner. There is at most one initial state and one final state in these state
machines.

Figure 2.7: Concept of Sequential Sub-States

(c) Concurrent Sub-states
In concurrent sub-states, the sub-states execute in parallel, or in other words, each state has concurrently
executing state machines within it. Each of the state machines has its own initial and final states. If one
concurrent sub-state reaches its final state before the other, control waits at its final state. When all the
nested state machines reach their final states, the sub-states join back to a single flow.

Figure 2.8: Concurrent Sub-State

Functional Model:
The functional model handles the process perspective of the model, corresponding roughly to data flow
diagrams. Main concepts are process, data store, data flow, and actors.
The entire OMT software development process has four phases: Analysis, system design, object design,
and implementation of the software. Most of the modeling is performed in the analysis phase. The
recommended method incorporates the following activities

Page no: 12 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

1. Develop a Problem Statement.

2. Build an Object Model:
a) Identify object classes.
b) Develop a data dictionary for classes, attributes, and associations.
c) Add associations between classes.
d) Add attributes for objects and links.
e) Organize and simplify object classes using inheritance.
f) Test access paths using scenarios and iterate the above steps as necessary.
g) Group classes into modules, based on close coupling and related function.
3. Build a Dynamic Model:
a) Prepare scenarios of typical interaction sequences.
b) Identify events between objects and prepare an event trace for each scenario.
c)Prepare an event flow diagram for the system.
d) Develop a state diagram for each class that has important dynamic behaviour.
e) Check for consistency and completeness of events shared among the state diagrams.
4. Build a Functional Model:
a) Identify input and output values.
b) Use data flow diagrams as needed to show functional dependencies.
c)Describe what each function does.
d) Identify constraints.
e) Specify optimization criteria.
5. Verify, iterate, and refine the three models:
a) Add most important operations to the object model.
b) Verify that classes, associations, attributes and operations are consistent and complete, check with
problem statement.
6. Iterate steps to complete the analysis

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.
Ru augh et al. ha e defi ed DFD as, A data flo diag a is a g aph hi h sho s the flo of data alues
from their sources in objects through processes that transform them to their destinations on other
o je ts.
The four main parts of a DFD are:
o Processes
o Data Flows
o Actors
o Data Stores.
The other parts of a DFD are:
o Constraints
o Control Flows.

Page no: 13 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

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

Figure 2.9: Example of DFD

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.

Figure 2.10: Example of DFD

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.

Page no: 14 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Figure 2.11: Example of DFD

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.

Figure 2.12: Example of DFD

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.

Page no: 15 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Figure 2.13: Example of DFD

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.

Figure 2.14: Example of DFD

Developing the DFD Model of a System:
In order to develop the DFD model of a system, hierarchies 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

Page no: 16 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Figure 2.15: Top-Level DFD

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

Figure 2.16: Example of DFD

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.

Page no: 17 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Figure 2.17: DFD of Customer Process

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.

Figure 2.18: DFD of Gift Process

Advantages and Disadvantages of DFD

Advantages Disadvantages
DFDs depict the boundaries of a system and hence are DFDs take a long time to create, which may not
helpful in portraying the relationship between the be feasible for practical purposes.
external objects and the processes within the system.
They help the users to have a knowledge about the DFDs do not provide any information about the
system. time-dependent behavior, i.e., they do not
specify when the transformations are done.
The graphical representation serves as a blueprint for They do not throw any light on the frequency of
the programmers to develop a system. computations or the reasons for computations.
DFDs provide detailed information about the system The preparation of DFDs is a complex process
processes. that needs considerable expertise. Also, it is
difficult for a non-technical person to understand.
They are used as a part of the system documentation. The method of preparation is subjective and
leaves ample scope to be imprecise.

Page no: 18 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Classification of Operations:
In this step, the operation to be performed on objects are defined by combining the three models
developed in the OOA phase, namely, object model, dynamic model, and functional model. An operation
specifies what is to be done and not how it should be done.
The following tasks are performed regarding operations:
o The state transition diagram of each object in the system is developed.
o Operations are defined for the events received by the objects.
o Cases in which one event triggers other events in same or different objects are identified.
o The sub–operations within the actions are identified.
o The main actions are expanded to data flow diagrams.

Relationship between Object, Dynamic, and Functional Models:

The Object Model, the Dynamic Model, and the Functional Model are complementary to each other for a
complete Object-Oriented Analysis.
o Object modelling develops the static structure of the software system in terms of objects. Thus it
sho s the doe s of a s ste .
o Dynamic Modelling develops the temporal behavior of the objects in response to external events. It
shows the sequences of operations performed on the objects.
o Functional model gives an overview of what the system should do.

Functional Model and Object Model:

The four main parts of a Functional Model in terms of object model are:
o Process: Processes imply the methods of the objects that need to be implemented.
o Actors: Actors are the objects in the object model.
o Data Stores: These are either objects in the object model or attributes of objects.
o Data Flows: Data flows to or from actors represent operations on or by objects. Data flows to or
from data stores represent queries or updates.

Functional Model and Dynamic Model:

The dynamic model states when the operations are performed, while the functional model states how they
are performed and which arguments are needed. As actors are active objects, the dynamic model has to
specify when it acts. The data stores are passive objects and they only respond to updates and queries;
therefore the dynamic model need not specify when they act.
Object Model and Dynamic Model
The dynamic model shows the status of the objects and the operations performed on the occurrences of
events and the subsequent changes in states. The state of the object as a result of the changes is shown in
the object model.

OBJECT DIAGRAM

Figure 2.19: Object Diagram

Page no: 19 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

An object diagram models a group of objects and their links at a point of time. It shows the instances of
the things in a class diagram. Object diagram is the static part of an interaction diagram. Example: The
following figure shows an object diagram of a portion of the class diagram of the Banking System.

STATE DIAGRAMS:
The state diagram in the Unified Modeling Language is essentially a Hare state chart with standardized
notation which can describe many systems, from computer programs to business processes.
In UML 2 the name has been changed to State Machine Diagram. The following are the basic notational
elements that can be used to make up a diagram:
Filled circle, representing to the initial state, hollow circle containing a smaller filled circle, indicating the
final state (if any)and Rounded rectangle, denoting a state. Top of the rectangle contains a name of the
state. Can contain a horizontal line in the middle, below which the activities that are done in that state are
Indicated Arrow, denoting transition. The name of the event (if any) causes this transition labels the arrow
body. A guard expression may be added before a "/" and enclosed in square-brackets (event Name [guard
Expression]), denoting that this expression must be true for the transition to take place. If an action is
Performed during this transition, it is added to the label following a "/" (event Name [guard
Expression]/action).
Thick horizontal line with either x>1 lines entering and 1 line leaving or 1 line entering and x>1 lines
leaving. These denote join/fork, respectively.

Figure 2.20: State Diagram

A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on
nodes. To describe a web site, for example, a deployment diagram would show what hardware
components ("nodes") exist (e.g., a web server, an application server, and a database server), what
software components ("artifacts") run on each node (e.g., web application, database), and how the
different pieces are connected (e.g. JDBC, REST, RMI).The nodes appear as boxes, and the artifacts
allocated to each node appear as rectangles within the boxes. Nodes may have sub nodes, which appear as
nested boxes. A single node in a deployment diagram may conceptually represent multiple physical nodes,
such as a cluster of database servers.

Page no: 20 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Execution Environment Node Device nodes are physical computing resources with processing memory and
services to execute software, such as typical computers or mobile phones. An execution environment node
(EEN) is a software computing resource that runs within an outer node and which itself provides a service
to host and execute other executable software elements.
SIGNIFICANCE:
These are the important for the design of any project done by the software designer
APPLICATION AREA:
Used in all IT companies for Designing

DESIGN PATTERNS
One way to describe object design Afte ide tif i g ou e ui e e ts a d eati g a do ai odel, the
add methods to the software classes, and define the messaging between the objects to fulfill the
e ui e e ts .

PHASES OF Unified Process:

The Unified Process has emerged as a popular iterative software development process for building object
oriented systems.
Unified process is an iterative process, risk driven process and architecture centric approach to software
development. It comes under software development process.
The Unified Software Development Process or Unified Process is a popular iterative and incremental
software development process framework. The best-known and extensively documented refinement of
the Unified Process is the Rational Unified Process (RUP).
I. Inception:
Inception is the initial stage of project. It deals with approximate vision, business case, scope of project and
vague estimation. Initial stage of project approximate vision Business case and scope vague estimate
Inception is the smallest phase in the project, and ideally it should be quite short. If the Inception Phase is
long then it may be an indication of excessive up-front specification, which is Contrary to the spirit of the
Unified Process.
The following are typical goals for the Inception phase.
Establish a justification or business case for the project
Establish the project scope and boundary conditions
Outline the use cases and key requirements that will drive the design tradeoffs outline one or more
candidate architectures Identify risks prepare a preliminary project schedule and cost estimate The
Lifecycle Objective Milestone marks the end of the Inception phase.
Advantages of Inception
Estimation or plans are expected to be reliable. After inception, design architecture can be made easily
because all the use cases are written in detail.
II. Elaboration:
During the Elaboration phase the project team is expected to capture healthy majority of the system
requirements. However, the primary goals of Elaboration are to address known risk factors and to establish
and validate the system architecture. Common processes undertaken in this phase include the creation of
use case diagrams, conceptual diagrams (class diagrams with only basic notation) and package diagrams
(architectural diagrams).Refined vision Core architecture Resolution of high risk Identification of most
requirement and scope Realistic estimate
III. Construction:
Construction is the largest phase in the project. In this phase the remainder of the system is built on the
foundation laid in Elaboration. System features are implemented in a series of short, time boxed iterations.
Each iteration results in an executable release of the software.
It is customary to write full text use cases during the construction phase and each one becomes the start of
a new iteration. Common UML (Unified Modeling Language) diagrams used during this phase include
Activity, Sequence, Collaboration, State (Transition) and Interaction Overview diagrams. The Initial
Operational Capability Milestone marks the end of the Construction phase.

Page no: 21 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Design the elements

Preparation for deployment
IV. Transition:
The final project phase is Transition. In this phase the system is deployed to the target users.
Feedback received from an initial release (or initial releases) may result in further refinements to be
incorporated over the course of several Transition phase iterations. The Transition phase also includes
system conversions and user training. The Product Release Milestone marks the end of the Transition
phase.

Page no: 22 Follow us on facebook to get real-time updates from RGPV

 We hope you find these notes useful.
You can get previous year question papers at
https://qp.rgpvnotes.in .

If you have any queries or you want to submit your

study notes please write us at
[email protected]