Function Oriented Design (FOD) - CSU1296 - Shoolini U

Function Oriented Design

2025, April 03

1. Introduction to Function Oriented Design (FOD)

Function Oriented Design (FOD) is a structured approach to designing software by dividing the system into smaller, manageable functions. These functions collectively achieve the system's goal by following a logical flow of data and control. Instead of thinking in terms of 'things' (objects), FOD emphasizes 'actions' (functions).

1.1 What is FOD?

FOD models a software system by breaking it down into a hierarchy of functions. Each function performs a specific task and works together with others to achieve the overall system objective. Think of it like an assembly line where each worker (function) does one specific job to create the final product (software).

1.2 Why use FOD?

FOD is used because it aligns closely with how we naturally decompose problems—by thinking of the actions needed to solve them. It’s particularly useful when the system is process-centric and when the data flow between actions is more important than the data itself.

Real-World Scenario

Imagine designing an ATM software:

This mirrors a real ATM’s operation: each button you press calls a specific function. Simple to test, easy to debug, efficient to implement.

1.3 Core Philosophy of FOD

The philosophy of FOD is built on functional abstraction. The key question it answers is: "What does the system do?"—not "What is the system made of?" It prioritizes functional completeness and data flow.

1.3.1 Principles
1.3.2 Difference from Object-Oriented Design
Aspect Function-Oriented Design Object-Oriented Design
Focus Functions (Processes) Objects (Entities)
Decomposition Top-down Functional Bottom-up using Objects
Reusability Through functions Through inheritance and polymorphism

2. Decomposition Approach in Function Oriented Design (FOD)

Decomposition in FOD means breaking a large system into smaller functional units that are easier to design, implement, and maintain. This approach is hierarchical—starting from a general view and narrowing down into specific tasks.

2.1 Top-Down Design

This is the heart of FOD. Start from a high-level function and break it into sub-functions until each part is implementable and testable.

Real-World Analogy

Designing an e-commerce system:

This mirrors how managers delegate tasks: start with the big picture, break it down, and delegate.

2.2 Modularity & Reusability

Modularity means each function should perform a single, well-defined task. This reduces complexity and increases clarity. Reusability means once a module is built, it can be reused anywhere it's needed without rewriting code.

Key Features
Example: Banking System

2.3 Sequential Breakdown

FOD promotes designing functions in the order they are executed—step-by-step as the user interacts with the system or as a process unfolds.

Real-World Case: Railway Reservation
  1. searchTrain()
  2. selectTrain()
  3. enterPassengerDetails()
  4. makePayment()
  5. generateTicket()

Each function flows into the next, forming a clear, traceable path from input to output.

Benefits

3. Key Characteristics of Function Oriented Design (FOD)

FOD stands out for its emphasis on actions (functions), their order, and the data that flows between them. It structures the system based on processes, not objects or entities.

3.1 Function-Based Thinking

FOD models the system around what it does instead of what it has. The core unit is a function, not a class or object. Each function performs a specific job with clear inputs and outputs.

Real-World Analogy

In a restaurant:

There’s no “customer” object holding behavior. Just actions happening in order to deliver a result.

3.2 Data Movement Emphasis

FOD centers around how data flows from one function to another. Data Flow Diagrams (DFDs) are used to visualize this journey.

Example

In a student admission system:

Design Implication

3.3 Process Over Object

Unlike Object-Oriented Design (OOD), which emphasizes the “nouns” (objects/entities), FOD prioritizes “verbs” (actions/functions).

Design Paradigm Shift
Aspect Function-Oriented Object-Oriented
Design Core Processes (Functions) Entities (Objects)
Reusability Code-level (functions) Class-level (inheritance)
Data Focus Shared data passed around Encapsulated in objects
Example

ATM Transaction:

FOD simplifies and flattens the design into a sequence of operations, making it intuitive for linear, action-driven workflows.

4. Practical Example: Online Library System

Let’s implement Function Oriented Design (FOD) for an Online Library Management System. This example will demonstrate how FOD decomposes tasks, flows data, and organizes logic functionally.

4.1 Step-by-Step Breakdown

4.2 Code Snippets or Pseudocode

# Main Function
def librarySystem():
    userManagement()
    bookManagement()
    searchBooks()
    borrowReturnBooks()

# Level 1 Functions
def userManagement():
    registerUser()
    loginUser()
    logoutUser()

def bookManagement():
    addBook()
    deleteBook()
    updateBook()

def searchBooks():
    print("Search by title, author, or category...")

def borrowReturnBooks():
    borrowBook()
    returnBook()
    checkDueDate()

# Level 2 Functions
def registerUser():
    print("Registering new user...")

def loginUser():
    print("User login...")

def logoutUser():
    print("User logout...")

def addBook():
    print("Adding new book...")

def deleteBook():
    print("Deleting book...")

def updateBook():
    print("Updating book details...")

def borrowBook():
    print("Borrowing book...")

def returnBook():
    print("Returning book...")

def checkDueDate():
    print("Checking due date...")

Each function is independent and can be reused, tested, or modified without affecting unrelated functions.

4.3 Use Case Mapping

Let’s match real user actions with corresponding FOD functions.

User Action Mapped Function(s)
Register a new account registerUser()
Login to system loginUser()
Search for a book searchBooks()
Borrow a book borrowBook(), checkDueDate()
Return a book returnBook()
Admin adds a book addBook()

Each use case is implemented by a well-defined function or a sequence of functions, maintaining the principles of modularity and sequential decomposition.

5. Designing with Data Flow Diagrams (DFDs)

Data Flow Diagrams (DFDs) visually represent how data moves through a system. In Function Oriented Design, DFDs help map out the interactions between functions and data without diving into implementation details.

5.1 Purpose of DFDs

DFDs help in:

Real-World Scenario: Train Ticket Booking System

5.2 DFD Components

Rules

5.3 Real DFD Example: Online Library System

Level 0 (Context-Level DFD)

Single process: Library System

flowchart TD
  User -->|Register/Login| LibrarySystem
  Admin -->|Add/Remove Books| LibrarySystem
  LibrarySystem -->|Search Results| User
  LibrarySystem -->|Issue Confirmation| User
  LibrarySystem -->|Book Data Updates| Admin
Level 1 DFD Breakdown
flowchart TD
  A[User] --> B1[Register/Login]
  B1 --> D1[(User DB)]
  A --> B2[Search Book]
  B2 --> D2[(Book DB)]
  B2 --> A
  A --> B3[Borrow Book]
  B3 --> D2
  B3 --> A

Each process (Register/Login, Search Book, Borrow Book) connects entities to data stores, showing the system's internal flow in detail.

6. Levels and Rules of Data Flow Diagrams (DFDs)

DFDs are designed in levels of increasing detail. This staged approach helps in managing complexity by gradually revealing internal processes. Each level adds more depth without overwhelming the designer or viewer.

6.1 Level 0 (Context DFD)

This is the most abstract view of the system. The entire system is represented as a single process with external entities interacting via data flows.

Purpose
Example
flowchart TD
  User -->|Search Request| LibrarySystem[Library System]
  LibrarySystem -->|Search Results| User
  Admin -->|Add Books| LibrarySystem

6.2 Level 1 DFD

This expands the single process from Level 0 into major sub-functions or modules. Each process shows how data is processed in broad categories.

Example
flowchart TD
  User --> A1[Login/Register]
  A1 --> D1[(User DB)]

  User --> A2[Search Book]
  A2 --> D2[(Book DB)]
  A2 --> User

  Admin --> A3[Manage Books]
  A3 --> D2

6.3 Level 2 DFD

Breaks down each Level 1 process into detailed steps. Shows internal logic of modules.

Example: Decomposition of "Login/Register"
flowchart TD
  User --> B1[Enter Credentials]
  B1 --> B2[Validate Credentials]
  B2 --> D1[(User DB)]
  B2 --> B3[Show Dashboard]
  B3 --> User

This level is used when system complexity demands micro-level control and traceability of data processing steps.

6.4 DFD Design Rules

Why Rules Matter

Rules ensure the DFD remains logical, complete, and implementable. Violating them leads to confusion, miscommunication, and faulty designs.

7. Data Dictionaries in Function Oriented Design (FOD)

A Data Dictionary is like a glossary for your system’s data. It defines every data element used in Data Flow Diagrams (DFDs) to ensure clarity, consistency, and correctness in data handling across all functions.

7.1 What is a Data Dictionary?

A Data Dictionary stores metadata—data about the data. It lists names, types, sizes, and descriptions of every data item used in your design.

Key Elements

7.2 Why Use It?

Real-World Analogy

In a library, a catalog entry describes each book: title, author, ISBN, genre. Similarly, a data dictionary describes each data item in a system—clearly and formally.

7.3 Real Example Table: Student Information System

Attribute Data Type Size Description
Student_ID Integer 03 Unique identifier for each student
Name String 20 Full name of the student
Father_Name String 20 Father's full name
Course Varchar 10 Enrolled course name
Usage in DFD

If a DFD process reads "Student Data", the Data Dictionary explains exactly what fields that includes, ensuring design precision and implementation accuracy.

8. Active vs Passive Data Dictionaries

Data Dictionaries come in two types—Active and Passive—based on how they synchronize with the actual data system. Understanding both is essential to choosing the right one for your project needs in Function Oriented Design.

8.1 Active Data Dictionary

An Active Data Dictionary is tightly integrated with the database management system (DBMS). When the structure or schema of the database changes, the dictionary updates automatically.

Key Features
Real-World Scenario

In enterprise banking software, if a developer adds a new field accountType to the Customer table, the active data dictionary reflects that immediately—no manual updates needed.

8.2 Passive Data Dictionary

A Passive Data Dictionary exists separately from the database. Any changes in the database must be manually reflected in the dictionary. If not updated properly, it may go out of sync.

Key Features
Real-World Scenario

In academic projects or small businesses, developers may maintain Excel sheets listing all database tables and fields. When someone adds a new field, they must manually edit the sheet.

8.3 When to Use What?

Criteria Active Dictionary Passive Dictionary
Project Size Large-scale, enterprise Small, academic, prototype
Update Handling Automatic Manual
Consistency Risk Low High if not maintained
Best Use Case Live production systems Design documentation phase

Rule of Thumb: If your system evolves often and data accuracy is critical, use an Active Dictionary. If your system is static or early in design, a Passive Dictionary works fine.

9. Strengths & Weaknesses of Function Oriented Design (FOD)

Function Oriented Design is a powerful design method for process-driven systems. However, it also has limitations that must be understood before choosing it for a project.

9.1 Advantages of FOD

9.2 Disadvantages of FOD

9.3 When FOD Fails

FOD becomes problematic when:

Real-World Fail Case

In a hospital management system, using FOD for modules like Patient, Doctor, Pharmacy, and Billing causes issues. Each module needs to store and modify data frequently. Without data encapsulation, any module can overwrite critical information, leading to errors and breaches. OOD would be a better fit here.

10. Real-World Application & Best Practices of Function Oriented Design (FOD)

FOD remains a practical choice for many real-world systems when used appropriately. Applying it with discipline and best practices ensures clarity, maintainability, and success—especially in function-dominant workflows.

10.1 When to Choose FOD

FOD is ideal when the system is action-driven and doesn’t need complex state management or encapsulation.

Use FOD If:

10.2 Design First, Code Later

Jumping directly into code leads to fragile systems. FOD emphasizes design-first planning using DFDs and Data Dictionaries.

Best Practices
Real-World Tip

Use visual tools like draw.io or Lucidchart to create DFDs and review the system flow with stakeholders before starting implementation.

10.3 Integrating FOD in SDLC

FOD fits naturally into a plan-driven Software Development Life Cycle (SDLC) like the Waterfall Model.

Integration Stages
Tool Suggestions

FOD, when applied correctly, delivers robust, maintainable solutions—especially in environments where logic is more important than structure.