Dujjd

1. Chapter-4
Function Oriented Design

2. Contents
• Design Principles
• Module-Level Concepts
• Design Notation and Specification
• Structured Design Methodology

3. Function Oriented Design
• It focuses on Function.
• It is depends on “what the system does”
• System is divided into many smaller subsystem
known as Function.
Shared Memory
F1
F2 F3
F4 F5

4. Function Oriented Design
E.g. ATM Functions: Withdraw() Deposit() Transfer()
•Function oriented design follows SDLC methodology.
Withdraw()
Pin verification
Amount
Print

5. • The design activity begins when the
requirements document for the software to
be developed.
• The design of a system is essentially a
blueprint or a plan for a solution for the
system.
• A design methodology is a systematic
approach to creating a design by applying of
a set of techniques and guidelines.

6. Design Principles
• Software design is the process of designing the
components of software.(eg. architecture,
Modules).
• In software designing we transform user
requirements into some suitable form, which
helps the programmer in software coding and
implementation.
• Eg. Designing of restaurant system.

7. Design Principles
• Design principles:
Problem partitioning/Decomposition :
It refers to break down a complex system
into components or smaller system.
Abstraction:
It means to describe the external behavior
of that component without knowing its
internal details.

8. Design Principles
• Design principles:
Modularity:
It means the division of software into
separate modules which are differently and
integrated later on in to obtain complete
functional software.

9. Design Principles
• Design principles:
Top down and bottom up approach:
The top down approach start with
identification of main component and then
decomposing them into more detailed sub
components.
The bottom up approach begins with lower
details and moves to words upward to form
main components.

10. Questions
What is the main purpose of problem
partitioning?
a) To make the problem more complex
b) To divide a large problem into smaller,
manageable parts
c) To avoid solving the problem altogether
d) To increase the size of the program

11. Questions
In the top-down approach, development
starts with:
a) Writing low-level functions first
b) Designing high-level modules and then
refining them into smaller parts
c) Writing all the code in a single step
d) Combining different pre-written
functions

12. Questions
Which of the following best describes
abstraction?
a) Hiding implementation details and showing
only relevant features
b) Writing long and complex code
c) Making the problem more difficult
d) Repeating the same code multiple times

13. Questions
In the bottom-up approach, development
starts with:
a) Implementing smaller components first and
then integrating them into a complete system
b) Writing the entire program at once
c) Designing the main structure before
implementing details
d) Ignoring small components

14. Module-Level Concepts
• A module is a logically separable part of a program.
• Coupling and cohesion are two Modularization
criteria, which are often used together.
• Independent modules: if one can function
completely without the presence of other
• Independence between modules is desirable
– Modules can be modified separately
– Can be implemented and tested separately
– Programming cost decreases

15. Coupling
• Coupling is the degree of interdependence
between software module.
• Coupling between modules is the strength of
interconnections between modules
• Coupling shows the relationship between
modules.
• Eg.
Registe
r
Login

16. Coupling
• Coupling refers to the degree of
interdependence between software modules.
• High coupling means that modules are closely
connected and changes in one module may
affect other modules.
• Low coupling means that modules are
independent, and changes in one module have
little impact on other modules.

17. Coupling
• Uncoupled: No interdependent on each other

18. Coupling
•Loosely coupled: not depends on each other.
•"Loosely coupled" modules have weak interconnections

19. Coupling
•Highly Coupled: Strongly depend on each other. "Highly
coupled" modules are joined by strong interconnection

20. Cohesion
• Cohesion characterized the inter-module
bond.
• Is measure of strength of relationship between
different functionalities within a module.
• Cohesion considers this relationship.
• Interested in determining how closely the
elements of a module are related to each other.

21. Cohesion
Register
Validation
Already exists
Upload profile
picture
Upload user data
Response handling
A
B
C

22. • Cohesion of a module represents how tightly
bound are the elements of the module
• Gives a handle about whether the different
elements of a module belong together
• High cohesion is the goal
• Cohesion and coupling are interrelated
• Greater cohesion of modules, lower coupling
between module.

23. Levels of Cohesion
• There are many levels of cohesion.
–Coincidental
–Logical
–Temporal
–Communicational
–Sequential
–Functional
• Coincidental is lowest, functional is highest
• Scale is not linear
• Functional is considered very strong

25. Difference between coupling and
cohesion
Feature Coupling Cohesion
Definition
Connection between two
modules
Strength of connection within
a module
Focus Relationship between modules Relationship within a module
Preference
Should be low for better
flexibility
Should be high for better
organization
Effect on
Maintenance
Harder to modify, as changes
affect many modules
Easier to modify, as changes
are within the module
Effect on
Reusability
Harder to reuse modules due
to dependencies
Easier to reuse as modules are
independent
Effect on
Debugging
More errors due to
dependency on other modules
Fewer errors as the module is
self-contained
Example
A module directly accessing
another modules data (bad)
A module handling only login
functions (good)

26. Questions
What does cohesion refer to in software
design?
a) The number of modules in a program
b) The degree to which the elements of a
module belong together
c) The dependency between two different
modules
d) The speed of execution of a module

27. Questions
What does coupling refer to in software
design?
a) The degree of dependency between
modules
b) The number of functions in a module
c) The speed of program execution
d) The number of variables in a module

28. Questions
Low coupling in a system means:
a) Modules are highly dependent on each
other
b) Modules can function independently
with minimal interaction
c) Modules cannot communicate at all
d) The system becomes harder to maintain

29. Questions
Which of the following is a disadvantage
of high coupling?
a) Increases flexibility
b) Makes it difficult to modify or maintain
a module
c) Improves reusability
d) Reduces dependency between modules

30. Design Notation & Specification
• Software design notation and specification are
essential for effectively planning, developing, and
communicating software system designs.
• While designing, a designer needs to record his
thoughts and decisions and to represent the design.
• For this, design notations are used.
• Design specification has to be precise and complete
that it can be used as a basis of further development
by other programmers.

31. • Design specification uses textual structures,
with design notation.
• Let us see few analysis and design tools used
by software designers:
1)Data Flow Diagram
2)Pseudo-Code
3)Decision Tables
4)Data Dictionary
5)structure chart

32. Data Flow Diagram
• Data flow diagram is graphical representation of flow
of data in an information system.
• It is capable of depicting incoming dataflow, outgoing
data flow and stored data.

33. Pseudo-Code
• Pseudo code is written more close to programming
language.
• It may be considered as augmented programming
language, full of comments and descriptions.
Task: add two numbers :
Start
Get two numbers
Add them
Print the answer
End

34. Decision Tables
• A Decision table represents conditions and the
respective actions to be taken to address them, in a
structured tabular format.

35. Data Dictionary
• Data dictionary is the centralized collection
of information about data. It stores meaning and origin
of data, its relationship with other data, data format
for usage etc.
• Data dictionary has rigorous definitions of all names in
order to facilitate user and software designers

36. Structure Charts
• Every computer program has a structure.
• The structure chart of a program is a graphic
representation of its structure.
• In a structure chart a module is represented by a
box with the module name written in the box.

37. Structure Chart
Symbols are used in construction of structure
chart.
Module:
–it represent process or task.
–Control Module: A control module
branches to more than one sub module.
–Sub Module: Sub Module is a module which
is the part (Child) of another module.

38. Structure Chart
–Library Module: Library Module are
reusable and invokable from any module.

39. Structure Chart
Conditional Call
–it is represented by small diamond at base
of the module.
–It represents that control module can select
any of the sub module on the basis of some
condition.

40. Structure Chart
Loop (Repetitive call of module)
–It represents the repetitive execution of
module by the sub module.
–A curved arrow represents a loop in the
module.

41. Structure Chart
Data Flow
–It represents the flow of data between the
modules. It is represented by a directed
arrow with an empty circle at the end.

42. Structure Chart
Control Flow
–It represents the flow of control between
the modules.
–It is represented by a directed arrow with a
filled circle at the end.

43. Structure Chart
 Physical Storage
–It is that where all the information are to be
stored.

44. Example
Structure chart for an Email server

45. Example
Structure chart for an Email server

46. • consider the structure of the following program, whose structure is shown in Figure .
main ()
{
int sum , n, N, a[MAX ];
readnums (a, &N); sort (a, N); scanf (&n);
sum = add_n (a, n); printf ( sum );
}
readnums (a, N)
int a[], *N;
{
:
}
sort (a, N)
int a[], N;
{
:
if (a[i] > a[t]) switch (a[i], a[t ]);
:
}
/* Add the first n numbers of a */
add_n (a, n)
int a[], n;
{
:
}

47. Figure : The structure chart of the
sort program

48. STRUCTURED DESIGN METHODOLOGY
• SDM views software as a transformation function
that converts given inputs to desired outputs
• The focus of SD is the transformation function
• Uses functional abstraction
• Goal of SDM: Specify functional modules and
connections
• Low coupling and high cohesion is the objective
Transformation
functions
Input Output

49. Steps in SD
• Draw a DFD of the system
• Identify most abstract inputs and most
abstract outputs
• First level factoring
• Factoring of input, output, transform
modules
• Improving the structure

50. Data Flow Diagrams
• SD starts with a DFD to capture flow of data in the
proposed system
• DFD is an important representation; provides a high
level view of the system
• Start with identifying the inputs and outputs
• Work your way from inputs to outputs, or vice versa
• Label each arrow carefully

51. Example 1 – counting the no. of
different words in a file

52. Identify most abstract inputs and
most abstract outputs
Identify the Most Abstract Inputs
•These are the core raw data or high-level
requirements that the system needs to process.
•They are not detailed or pre-processed; rather,
they define what the system needs at the highest
level.
•Examples:
– User requirements

53. Identify most abstract inputs and
most abstract outputs
Identify the Most Abstract Outputs
•These are the high-level results or outcomes that
the system produces.
•They do not include specific formatting or fine-
grained details but represent what the system is
ultimately meant to deliver.
•Examples:
– Final reports or processed information

54. Identify most abstract inputs and
most abstract outputs
Example: A Banking System
•Most Abstract Input: "User requests account
balance"
•Most Abstract Output: "Display account balance"

55. Example 1 – counting the no. of
different words in a file

56. Example 2 – ATM

57. First Level Factoring
• First-level factoring is the initial breakdown of a
system into its major functional components.
• It helps in:
– Dividing the system into modules
– Identifying major processing functions
– Establishing data flow between components

58. First Level Factoring
•For each most abstract input data item, specify a
subordinate input module
•The purpose of these input modules is to deliver
the data items
•For each most abstract output data element,
specify an output module
•For each central transform, specify a subordinate
transform module
•Inputs and outputs of these transform modules are
specified in the DFD

59. Example 1

60. Example 2

61. Factoring Input modules
• The transform that produced the data is treated as
the central transform.
• Then repeat the process of first level factoring.
• Input module being factored becomes the main
module
• A subordinate input module is created for each
data item coming in this new central transform
• A subordinate module is created for the new
central transform

62. Example 1

63. Factoring Central Transforms
• Factoring i/o modules is straight forward if the DFD is
detailed.
• No rules for factoring the transform modules.
• Top-down refinement process can be used.
• Determine sub transforms that will together
compose the transform.
• Treat the transform as a problem in its own right.
• Draw a data flow graph.
• Then repeat the process of factoring.

64. Example 1

65. Assignment
1. Explain design principles in function oriented design.
2. Explain Module-Level Concepts with the help of
Coupling and Cohesion
3. Explain design notation and specification in detail.
Construct structure chart for email server.
4. List the steps in structure design methodology. design
the SDM structure for below system. Get one world file
which contain information about our college and count
the different words from that world file.
5. Differentiate between cohesion and coupling.