Functional Modeling in object oriented

analysis and design

Functional Modeling 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 Modeling 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 basic components of the DFD are:

1. External Entity:

External entity is the entity that takes information and gives information to the
system. It is represented with rectangle.
2. Data Flow:
The data passes from one place to another is shown by data flow. Data flow is
represented with arrow and some information written over it.
3. Process:
It is also called function symbol.It is used to process all the information.If there
are calculations so all are done in the process part.It is represented with circle
and name of the process and level of DFD written inside it.
4. Data Store:
It is used to store the information and retrieve the stored information.It is
represented with double parallel lines.
Some Guidelines for creating a DFD:
1. Every process must have meaningful name and number.
2. Level 0 DFD must have only one process.
3. Every data flow and arrow has given the name.
4. DFD should be logical consistent.
5. DFD should be organized in such a way that it is easy to understand.
6. There should be no loop in the DFD.
7. Each DFD should not have more than 6 processes.
8. The process can only connected with process, external entity and data
store.
9. External entity cannot be directly connected with external entity.
10. The direction of DFD is left to right and top to bottom representation.

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,
labeled 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 labeled.

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 labeled. 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 is 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.

Advantages and Disadvantages of DFD

Advantages Disadvantages

DFDs depict the boundaries of a system and DFDs take a long time to create, which
hence are helpful in portraying the may not be feasible for practical
relationship between the external objects purposes.
and the processes within the system.

They help the users to have a knowledge DFDs do not provide any information
about the system. about the time-dependent behavior, i.e.,
they do not specify when the
transformations are done.

The graphical representation serves as a They do not throw any light on the
blueprint for the programmers to develop a frequency of computations or the reasons
system. for computations.

DFDs provide detailed information about The preparation of DFDs is a complex

the system processes. process that needs considerable
expertise. Also, it is difficult for a non-
technical person to understand.

They are used as a part of the system The method of preparation is subjective
documentation. and leaves ample scope to be imprecise.

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.
 Object modelling develops the static structure of the software system in terms of
objects. Thus it shows the “doers” of a system.
 Dynamic Modelling develops the temporal behavior of the objects in response to
external events. It shows the sequences of operations performed on the objects.
 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 −
 Process − Processes imply the methods of the objects that need to be implemented.
 Actors − Actors are the objects in the object model.
 Data Stores − These are either objects in the object model or attributes of objects.
 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.
Structured Analysis and Structured
Design (SA/SD)
Structured Analysis and Structured Design (SA/SD) is a diagrammatic
notation that is designed to help people understand the system. The basic goal
of SA/SD is to improve quality and reduce the risk of system failure. It
establishes concrete management specifications and documentation. It focuses
on the solidity, pliability, and maintainability of the system.
Basically, the approach of SA/SD is based on the Data Flow Diagram. It is
easy to understand SA/SD but it focuses on well-defined system boundary
whereas the JSD approach is too complex and does not have any graphical
representation.
SA/SD is combined known as SAD and it mainly focuses on the following 3
points:

1. System
2. Process
3. Technology
SA/SD involves 2 phases:
1. Analysis Phase: It uses Data Flow Diagram, Data Dictionary, State
Transition diagram and ER diagram.
2. Design Phase: It uses Structure Chart and Pseudo Code.

1. Analysis Phase:

Analysis Phase involves data flow diagram, data dictionary, state

transition diagram, and entity-relationship diagram.
1. Data Flow Diagram:

In the data flow diagram, the model describes how the data flows through the
system. We can incorporate the Boolean operators and & or link data flow
when more than one data flow may be input or output from a process.

For example, if we have to choose between two paths of a process we can add
1. an operator or and if two data flows are necessary for a process we can add
an operator. The input of the process “check-order” needs the credit
information and order information whereas the output of the process would be
a cash-order or a good-credit-order.

2. Data Dictionary:

The content that is not described in the DFD is described in the data dictionary.
It defines the data store and relevant meaning. A physical data dictionary for
data elements that flow between processes, between entities, and between
processes and entities may be included. This would also include descriptions of
2. data elements that flow external to the data stores.
A logical data dictionary may also be included for each such data element. All
system names, whether they are names of entities, types, relations, attributes, or
services, should be entered in the dictionary.

3. State Transition Diagram:

State transition diagram is similar to the dynamic model. It specifies how much
time the function will take to execute and data access triggered by events. It
also describes all of the states that an object can have, the events under which
an object changes state, the conditions that must be fulfilled before the
transition will occur and the activities were undertaken during the life of an
object.

4. ER Diagram:

ER diagram specifies the relationship between data store. It is basically used in

database design. It basically describes the relationship between different
entities.

2. Design Phase:

Design Phase involves structure chart and pseudocode.

1. Structure Chart:

It is created by the data flow diagram. Structure Chart specifies how DFS’s
processes are grouped into tasks and allocate to the CPU. The structured chart
does not show the working and internal structure of the processes or modules
and does not show the relationship between data or data-flows. Similar to other
SASD tools, it is time and cost-independent and there is no error-checking
technique associated with this tool.
The modules of a structured chart are arranged arbitrarily and any process from
a DFD can be chosen as the central transform depending on the analysts’ own
perception. The structured chart is difficult to amend, verify, maintain, and
check for completeness and consistency.

2. Pseudo Code:

It is the actual implementation of the system. It is an informal way of

programming that doesn’t require any specific programming language or
technology.
Object Modeling Technique (OMT) is real world based modeling
approach for software modeling and designing. It was developed basically as a
method to develop object-oriented systems and to support object-oriented
programming. It describes the static structure of the system.
Object Modeling Technique is easy to draw and use. It is used in many
applications like telecommunication, transportation, compilers etc. It is also
used in many real-world problems. OMT is one of the most popular object-
oriented development techniques used now-a-days. OMT was developed
by James Rambaugh.

Purpose of Object Modeling Technique:

 To test physical entity before construction of them.
 To make communication easier with the customers.
 To present information in an alternative way i.e. visualization.
 To reduce the complexity of software.
 To solve the real world problems.
Object Modeling Technique’s Models:

There are three main types of models that has been proposed by OMT:
1. Object Model:

Object Model encompasses the principles of abstraction, encapsulation,

modularity, hierarchy, typing, concurrency and persistence. Object Model
basically emphasizes on the object and class. Main concepts related with
Object Model are classes and their association with attributes. Predefined
relationships in object model are aggregation and generalization (multiple
inheritance).

2. Dynamic Model:

Dynamic Model involves states, events and state diagram (transition diagram)
on the model. Main concepts related with Dynamic Model are states, transition
between states and events to trigger the transitions. Predefined relationships in
object model are aggregation (concurrency) and generalization.

3. Functional Model:

Functional Model focuses on the how data is flowing, where data is stored and
different processes. Main concepts involved in Functional Model are data, data
flow, data store, process and actors. Functional Model in OMT describes the
whole processes and actions with the help of data flow diagram (DFD).
Phases of Object Modeling Technique:

OMT has the following phases:

1. Analysis:
This the first phase of the object modeling technique. This phase involves the
preparation of precise and correct modelling of the real world problems.
Analysis phase starts with setting a goal i.e. finding the problem statement.
Problem statement is further divided into above discussed three models i.e.
object, dynamic and functional model.
2. System Design:

This is the second phase of the object modeling technique and it comes after
the analysis phase. It determines all system architecture, concurrent tasks and
data storage. High level architecture of the system is designed during this
phase.
3. Object Design:

Object design is the third phase of the object modelling technique and after
system design is over, this phase comes. Object design phase is concerned with
classification of objects into different classes and about attributes and
necessary operations needed. Different issues related with generalization and
aggregation are checked.

4. Implementation:
This is the last phase of the object modeling technique. It is all about
converting prepared design into the software. Design phase is translated into
the Implementation phase.

JSD, Jackson Structure Design is a methodology to specify and design systems in

which time factor is significant and system may be described using sequence of events.
Developed by Michael A. Jackson, this design method considers the fact that the design
of the system is an extension of the programme design. The purpose of this design
method is to create maintainable software. The method addresses all stages of the
software development life cycle. It has three phases:

1. Modeling phase - A JSD model starts with real world consideration. This phase is
a part of analysis process. The aspects of the real world relevant to the system being
developed are modeled in this phase.
2. Specification phase - This phase focuses on the specification. In this phase JSD
determines what is to be done? The previous phase i.e. the modeling phase provides the
basic for the system specifications to achieve the required functionality.
3. implementation phase - In this phase , JSD determines how to achieve required
functionality. Operational specifications are executed so that it expresses desired
system behavior in terms of some abstract machine.

Ways of working
 The basic principle of operation of JSD is that development must start with
describing and modeling the real world rather than specifying the function performed
by the system.
 The second principle states that an adequate model of a time ordered world must
itself be time ordered. The aim is to map progress in the real world on progress in the
system that models it.
 The third principle stetes way of implementing the system based on transformation
of specification in to efficient set of processes. These processes should be designed in a
manner to make them run on available software and hardware.
Steps for JSD software development
Originally presented by Jackson in 1983 the method consisted of six steps which are
following.
1. Entity /action step
2. Entity structure step
3. Initial model step
4. function step
5. system timing step
6. system implementing step
Later, some steps were combined to create a method with only three steps
1. Modeling stage (Analysis)
o Action step
o Structure step
2. Network stage (design)
o Initial model step
o Function step
o System timing step
3. Implementation stage (Realisation)
o System implementation step

Advantages of JSD
1. specially designed to handle real time problem.
2. JSD considers concurrent processing and timing.
3. JSD modeling focuses on time.
4. It provides functionality in the real world.
5. Excellent methodology for micro code application.

Disadvantages of JSD
1. JSD is a poor approach for high level analysis and data base design.
2. More complex due to pseudo code representation.
3. complex and difficult to understand.
4. less graphically oriented than SA/ SD and OMT.