Function Oriented Design

Function Oriented design is a method to software design where the model is decomposed into
a set of interacting units or modules where each unit or module has a clearly defined function.
Thus, the system is designed from a functional viewpoint.

Design Notations
Design Notations are primarily meant to be used during the process of design and are used to
represent design or design decisions. For a function-oriented design, the design can be
represented graphically or mathematically by the following:

Data Flow Diagram

Data-flow design is concerned with designing a series of functional transformations that
convert system inputs into the required outputs. The design is described as data-flow
diagrams. These diagrams show how data flows through a system and how the output is
derived from the input through a series of functional transformations.

Data-flow diagrams are a useful and intuitive way of describing a system. They are generally
understandable without specialized training, notably if control information is excluded. They
show end-to-end processing. That is the flow of processing from when data enters the system
to where it leaves the system can be traced.

67.5M
1.3K
 Exception Handling in Java - Javatpoint

Data-flow design is an integral part of several design methods, and most CASE tools support
data-flow diagram creation. Different ways may use different icons to represent data-flow
diagram entities, but their meanings are similar.

The notation which is used is based on the following symbols:

The report generator produces a report which describes all of the named entities in a data-
flow diagram. The user inputs the name of the design represented by the diagram. The report
generator then finds all the names used in the data-flow diagram. It looks up a data dictionary
and retrieves information about each name. This is then collated into a report which is output
by the system.
Data Dictionaries
A data dictionary lists all data elements appearing in the DFD model of a system. The data
items listed contain all data flows and the contents of all data stores looking on the DFDs in
the DFD model of a system.

A data dictionary lists the objective of all data items and the definition of all composite data
elements in terms of their component data items. For example, a data dictionary entry may
contain that the data grossPay consists of the parts regularPay and overtimePay.

                  grossPay = regularPay + overtimePay

For the smallest units of data elements, the data dictionary lists their name and their type.

A data dictionary plays a significant role in any software development process because of the
following reasons:

o A Data dictionary provides a standard language for all relevant information for use by
engineers working in a project. A consistent vocabulary for data items is essential
since, in large projects, different engineers of the project tend to use different terms to
refer to the same data, which unnecessarily causes confusion.
o The data dictionary provides the analyst with a means to determine the definition of
various data structures in terms of their component elements.

Structured Charts
It partitions a system into block boxes. A Black box system that functionality is known to the
user without the knowledge of internal design.
Structured Chart is a graphical representation which shows:

o System partitions into modules

o Hierarchy of component modules
o The relation between processing modules
o Interaction between modules
o Information passed between modules

The following notations are used in structured chart:

Pseudo-code
Pseudo-code notations can be used in both the preliminary and detailed design phases. Using
pseudo-code, the designer describes system characteristics using short, concise, English
Language phases that are structured by keywords such as If-Then-Else, While-Do, and End.

Object-Oriented Design
In the object-oriented design method, the system is viewed as a collection of objects (i.e.,
entities). The state is distributed among the objects, and each object handles its state data. For
example, in a Library Automation Software, each library representative may be a separate
object with its data and functions to operate on these data. The tasks defined for one purpose
cannot refer or change data of other objects. Objects have their internal data which represent
their state. Similar objects create a class. In other words, each object is a member of some
class. Classes may inherit features from the superclass.

The different terms related to object design are:

1. Objects: All entities involved in the solution design are known as objects. For
example, person, banks, company, and users are considered as objects. Every entity
has some attributes associated with it and has some methods to perform on the
attributes.
2. Classes: A class is a generalized description of an object. An object is an instance of a
class. A class defines all the attributes, which an object can have and methods, which
represents the functionality of the object.
3. Messages: Objects communicate by message passing. Messages consist of the
integrity of the target object, the name of the requested operation, and any other action
needed to perform the function. Messages are often implemented as procedure or
function calls.
4. Abstraction In object-oriented design, complexity is handled using abstraction.
Abstraction is the removal of the irrelevant and the amplification of the essentials.
5. Encapsulation: Encapsulation is also called an information hiding concept. The data
and operations are linked to a single unit. Encapsulation not only bundles essential
information of an object together but also restricts access to the data and methods
from the outside world.
 6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner where
the lower or sub-classes can import, implement, and re-use allowed variables and
functions from their immediate superclasses.This property of OOD is called an
inheritance. This makes it easier to define a specific class and to create generalized
classes from specific ones.
7. Polymorphism: OOD languages provide a mechanism where methods performing
similar tasks but vary in arguments, can be assigned the same name. This is known as
polymorphism, which allows a single interface is performing functions for different
types. Depending upon how the service is invoked, the respective portion of the code
gets executed.

Software Measurement: A measurement is a manifestation of the

size, quantity, amount, of a product or process. The software measurement process is
defined and governed by ISO Standard.

Need for Software Measurement: 

Software is measured to: 

 Create the quality of the current product or process.
 Anticipate future qualities of the product or process.
 Enhance the quality of a product or process.
 Regulate the state of the project in relation to budget and schedule.

Classification of Software Measurement: 

There are 2 types of software measurement: 

1. Direct Measurement: In direct measurement, the product, process, or thing is
measured directly using a standard scale.
2. Indirect Measurement: In indirect measurement, the quantity or quality to be
measured is measured using related parameters i.e. by use of reference.

Metrics: 

A software metric is a measure of software characteristics which are measurable

or countable. Software metrics are valuable for many reasons, including
measuring software performance, planning work items, measuring productivity,
and many other uses.
. 
Software metrics will be useful only if they are characterized effectively and
validated so that their worth is proven. There are 4 functions related to software
metrics: 
1. Planning
2. Organizing
3. Controlling
4. Improving

 Characteristics of software Metrics: 

1. Quantitative: Metrics must possess quantitative nature. It means metrics can be

expressed in values.
2. Understandable: Metric computation should be easily understood, and the
method of computing metrics should be clearly defined.
3. Applicability: Metrics should be applicable in the initial phases of the
development of the software.
4. Repeatable: The metric values should be the same when measured repeatedly
and consistent in nature.
5. Economical: The computation of metrics should be economical.
6. Language Independent: Metrics should not depend on any programming
language.

Size Oriented Metrics

LOC Metrics
It is one of the earliest and simpler metrics for calculating the size of the computer
program. It is generally used in calculating and comparing the productivity of
programmers.

Following are the points regarding LOC measures:

1. In size-oriented metrics, LOC is considered to be the normalization value.

2. It is an older method that was developed when FORTRAN and COBOL
programming were very popular.
3. Productivity is defined as KLOC / EFFORT, where effort is measured in person-
months.
4. Size-oriented metrics depend on the programming language used.
5. As productivity depends on KLOC, so assembly language code will have more
productivity.
 6. LOC measure requires a level of detail which may not be practically
achievable.
7. The more expressive is the programming language, the lower is the
productivity.
8. LOC method of measurement does not apply to projects that deal with visual
(GUI-based) programming. As already explained, Graphical User Interfaces
(GUIs) use forms basically. LOC metric is not applicable here.

Advantages of LOC
1. Simple to measure

Disadvantage of LOC
1. It is defined on the code. For example, it cannot measure the size of the
specification.
2. It characterizes only one specific view of size, namely length, it takes no
account of functionality or complexity
3. Bad software design may cause an excessive line of code
4. It is language dependent
5. Users cannot easily understand it

Cyclomatic Complexity
Cyclomatic complexity is a software metric used to measure the complexity of a program.
Thomas J. McCabe developed this metric in 1976.McCabe interprets a computer program as
a set of a strongly connected directed graph. Nodes represent parts of the source code
having no branches and arcs represent possible control flow transfers during program
execution. The notion of program graph has been used for this measure, and it is used to
measure and control the number of paths through a program. The complexity of a computer
program can be correlated with the topological complexity of a graph.

How to Calculate Cyclomatic Complexity?

McCabe proposed the cyclomatic number, V (G) of graph theory as an indicator of
software complexity. The cyclomatic number is equal to the number of linearly
independent paths through a program in its graphs representation. For a program
control graph G, cyclomatic number, V (G), is given as:

              V (G) = E - N + 2 * P

E = The number of edges in graphs G

N = The number of nodes in graphs G

P = The number of connected components in graph G.

Example: