Revision - Term 2

Fundamental Issues in Software Design

Software design faces many challenges. These are called fundamental issues. Solving them helps build software that works well, is easy to use, and doesn’t crash.

1. Meeting User Requirements

We must understand what users need and build the software accordingly.

Example: If you make a doctor app but don’t include easy access to patient history, doctors won’t like it.

Why it matters: If software doesn’t match user needs, nobody will use it.

2. Maintaining Simplicity

The design should be simple and not overloaded with features.

Example: A farming app with too many graphs will confuse farmers. Use simple charts.

Why it matters: Complex software causes confusion and errors.

3. Scalability

Software should handle more users and data as it grows.

Example: An online shop should work fast even if 10,000 users visit together.

Why it matters: Unscalable software becomes slow or crashes as users increase.

4. Performance

The software should run fast and use less memory.

Example: A video editor should render videos quickly, not take forever.

Why it matters: Slow software makes users angry and they may stop using it.

5. Security

Data should be safe from hackers.

Example: Banking apps must protect money and private info from theft.

Why it matters: Weak security can lead to hacking and user data loss.

6. Flexibility and Maintainability

Software should be easy to update and fix.

Example: If a clinic app wants to add video calls later, it should be easy to add.

Why it matters: If software is hard to change, it becomes outdated.

7. Handling Errors and Failures

Software should show helpful error messages and not crash.

Example: If a user enters the wrong date in a flight app, it should say “Invalid date.”

Why it matters: Good error handling keeps the app stable and easy to fix.

8. Usability

Software should be easy to learn and use.

Example: Hospital systems should be simple so even non-tech staff can use them.

Why it matters: Hard-to-use software causes mistakes and wastes time.

9. Interoperability

Software should work well with other software.

Example: A hospital app should share data with other hospitals.

Why it matters: If software can’t connect to others, it becomes less useful.

10. Cost and Time Management

The software should be finished on time and within budget.

Example: If a biotech app isn’t ready for a medical event, the company may lose money.

Why it matters: Delays and overspending make the project stressful and waste resources.

Cohesion and Coupling

In software design, cohesion and coupling are two important concepts. They help us build software that is easy to understand, maintain, and update.

Cohesion

Cohesion means how well the things inside a module or class work together to do one clear task.

High Cohesion

All parts of a module are related and do one job only.

Good design: Easy to understand, reuse, and maintain.

Example:

Product Module → manages product info

Cart Module → adds/removes items

Payment Module → handles payments

Account Module → manages user login

Each one focuses on its own job. That’s high cohesion.

Low Cohesion

A module does many unrelated things.

Bad design: Confusing, hard to fix.

Example:

If the Cart Module also handles login and user profile — it's doing too much. That’s low cohesion.

Coupling

Coupling means how much one module depends on another.

Low Coupling

Modules are independent and use well-defined communication like APIs.

Good design: You can change one module without affecting others.

Example:

You add PayPal in the payment module.

Since it’s separate, cart and product modules don’t need to change.

This is low coupling.

High Coupling

Modules are tightly connected and depend on each other.

Bad design: Changing one module breaks the other.

Example:

If Cart Module contains payment logic, then updating payment affects the cart too.

This is high coupling.

How They Work Together

High Cohesion + Low Coupling = Best design
Each part does one job and works independently.

Low Cohesion + High Coupling = Worst design
Modules do too much and are too dependent on each other.

Real-Life Example: Amazon

High Cohesion:

Product page only shows product info.

Cart handles only item selection.

Checkout handles only payment.

Low Coupling:

You can add new payment options without touching the product or cart modules.

Benefits of High Cohesion & Low Coupling

Easy to maintain
Easy to test and debug
Easy to reuse and update
Reduces bugs and confusion

"Good software design aims for high cohesion and low coupling to keep systems clean, modular, and easy to work with."

Function-Oriented Design (FOD)

Function-Oriented Design is a way of designing software by dividing the system into small functions.
Each function does a specific job, and all functions work together to achieve the final goal.

General Steps

Start by understanding what the software should do.

Break down high-level functions into smaller and detailed sub-functions.

Key Concepts

Divides Software into Functions

Each function takes input, processes it, and gives output.

Follows Top-Down Approach

Start from the main function and break it into smaller parts.

Uses Data Flow

Data moves from one function to another.

Use Data Flow Diagrams (DFD) to show this.

Focus on Processes, Not Objects

Unlike Object-Oriented Design, FOD focuses on tasks, not classes or objects.

Example: Online Library System

Main Function: Library System

Sub-Functions:

User Management (register, login)

Book Management (add, update, delete)

Search Books (by title, author)

Borrow/Return Books

Further Sub-functions:

registerUser(), loginUser()

addBook(), deleteBook()

Advantages of FOD

Easy to understand
Works well for small to medium projects
Functions can be reused

Disadvantages of FOD

Not good for complex systems
Difficult to update — one change can affect many functions
Less secure — data is shared between many functions

FOD Strategies

Data Flow Diagrams (DFD)

Show how data moves through the system.

Track how input turns into output using functions.

Types of DFD

Logical DFD: Focuses on what the system does.

Physical DFD: Shows how the system is actually built.

DFD Components

Entity: Source or destination of data (📦 Rectangle)

Process: Activity performed on data (⭕ Circle)

Data Store: Where data is kept (🟫 Open rectangle)

Data Flow: Arrows showing data movement (➡️)

DFD Levels

Level 0 (Context DFD): Shows whole system as one process

Level 1: Breaks system into major modules

Level 2: Shows detailed data flow inside each module

Rules for DFD

Every process must have at least one input and one output

Data stores must have at least one incoming and one outgoing flow

All flows go between a process, data store, or entity — no direct data store to entity

Data Dictionary

A data dictionary stores info about data items used in DFDs.

It tells what data is used, where, and how.

What it stores (Metadata):

Column names

Data types

Size

Description

Example Table:

Student ID Name Father_Name Course

101 Jack Abc M.Tech

102 Jerry Xyz MCA

Metadata Example:

Attribute Data Type Size Description

Student ID int 03 Student's ID

Name string 20 Student's Name

Father_Name string 20 Father's Name

Course varchar 10 Course Name

Types of Data Dictionary

Active Data Dictionary

Updates automatically when the database changes

Maintained by the database system

Passive Data Dictionary

Must be updated manually

Needs careful handling

Structured Analysis and Structured Design

Structured Analysis and Design is a step-by-step method to build a system by breaking it down into smaller parts using diagrams and logical models.

Structured Analysis

It focuses on what the system should do. It helps understand the current system and define new requirements.

Tools Used in Analysis Phase

DFD (Data Flow Diagram): Shows how data moves in the system

Data Dictionary: Defines data types and attributes

ER Diagram: Shows relationships between entities (like student–course)

Decision Trees / Tables: Shows decision rules clearly

State Transition Diagram: Shows how system reacts to changes

Process Specification (PSPEC): Explains logic of each process

Structured Design

It focuses on how the system will be built. It converts analysis into an implementation-ready design.

Key Design Elements

Modular Design: Break system into modules with high cohesion and low coupling

Structure Chart: Shows how modules interact (like a tree)

Interface Design: Focuses on UI/UX and how users interact

Database Design: Tables, relationships, and normalization

Control Flow: How processes and decisions are handled

Objectives of Structured Analysis & Design

Understand user needs clearly

Break system into smaller parts

Define relationships between parts

Ensure consistency and completeness

Improve communication

Support future growth (scalability)

Advantages

Clear understanding using diagrams Easy to update due to modular structure Better teamwork and communication Efficient use of resources Easy to scale in future

Disadvantages

Takes more time and documentation Hard to change later (rigid) Not good for fast/agile development

: "Structured Analysis and Design is best for large, clear projects where detailed planning, logical structure, and good documentation are needed."

UML (Unified Modeling Language)

UML is a visual language used to draw diagrams that show how a software system is designed.

UML is not a programming language — it helps in understanding and planning before coding.

It is a standard method, approved by ISO, used by developers, analysts, and clients.

UML helps both technical and non-technical people understand the system easily.

Why UML is Needed

Complex systems need clear planning
Non-programmers (like clients or managers) can understand the design
Saves time by allowing visual communication and planning

Major UML Diagrams (Most Important)

1. Class Diagram

Shows system’s classes, attributes, methods, and how they’re related.

Most commonly used in object-oriented design.

Example: Classes like User, Post, Comment in a social media site.

2. Use Case Diagram

Shows what users (actors) can do with the system.

Captures functional requirements.

Example: In an e-commerce site – Browse, Add to Cart, Checkout.

3. Sequence Diagram

Shows how objects interact over time in a scenario.

Example: Steps of transferring money in a banking app.

4. Activity Diagram

Like a flowchart. Shows the step-by-step process or workflow.

Example: Login process – Enter ID → Password → Authenticate → Grant Access.

Object-Oriented Concepts Used in UML

Class: Blueprint of an object

Object: A real-world instance of a class

Inheritance: Child class inherits features from parent

Abstraction: Shows only important details

Encapsulation: Keeps data safe inside the object

Polymorphism: One function behaves differently based on context

Tools for Drawing UML Diagrams

Lucidchart – Easy and collaborative

Draw.io – Free and works online/offline

Visual Paradigm – Full-featured with templates

StarUML – Open-source and customizable

"UML helps visualize, plan, and communicate software designs clearly, making development easier for both programmers and non-programmers."

User Interface (UI) Design

User Interface Design means creating the screens and controls through which the user interacts with the software.

A good UI should be:

Attractive

Simple to use

Quick to respond

Easy to understand

Consistent on all screens

UI Design Principles

Structure – Organize info clearly

Simplicity – Keep interface easy and clean

Visibility – Show important options clearly

Feedback – Inform users of actions (like loading, errors)

Tolerance – Allow easy error correction and undo options

UI Design Process

Phase 1: User, Task, and Environment Analysis

Understand who will use the system

Study their skills, knowledge, and needs

Group users based on their profile

Phase 2: Interface Design

Identify tasks users need to do

Define objects and actions for those tasks

Plan how users will interact with the interface

Phase 3: Interface Construction

Build a prototype (sample UI)

Use it to test real-world usability

Keep improving the UI until it's approved

Phase 4: Interface Validation

Test if UI works correctly for all tasks

Check it handles real-world use cases and variations

"A well-designed UI improves user satisfaction, increases productivity, and reduces errors in software usage."

### **Q. What is UML? Explain using suitable example, all the diagrams of UML.** --- ### ✅ **UML (Unified Modeling Language)** UML is a **visual language** used to **draw diagrams** that explain how software will work. It helps developers, clients, and everyone understand the **plan of the system** before making it. It is **not a programming language**, only a **drawing method** for software. --- ### ✅ **Why UML is useful?** - It helps people **understand software easily** - Saves time by **planning everything before coding** - Clients and non-technical people can also **see and suggest changes** --- ### ✅ **Example**: For a **shopping app**, UML diagrams can show: - What users can do (like login, search, buy) - What parts the system has (like cart, payment) - How data flows - How users interact step by step --- ### ✅ **Types of UML Diagrams** #### 1. **Class Diagram** Shows different parts (classes) of the system and how they’re connected. **Example**: Classes like `User`, `Product`, `Order`. Each class has its own data (like name, price) and actions (like buy, search). --- #### 2. **Use Case Diagram** Shows **what users can do** in the system. **Example**: In a shopping app — Login, Browse Products, Add to Cart, Checkout. Users are shown as stick figures, actions as ovals. --- #### 3. **Sequence Diagram** Shows **step-by-step interaction** between parts of the system. **Example**: For online payment — User → Click Pay → System → Send to Bank → Get Response. --- #### 4. **Activity Diagram** Like a **flowchart**. Shows how a process works. **Example**: Login process — Enter ID → Enter Password → Check → Grant Access. --- #### ✅ Final Line to Write: **"UML diagrams help plan software properly, so developers build the right system and avoid confusion later."** ### **Q. What is a Data Dictionary? Write in brief about its types.** --- ### ✅ **Data Dictionary** A **data dictionary** is a **list of all data** used in the system, along with their **names, meanings, types, and details**. It is like a **dictionary for programmers**, where we can find out: - What data is used - What it means - What type it is (number, text, etc.) - Where and how it is used --- ### ✅ **Example**: | Field Name | Data Type | Size | Description | |-------------|-----------|------|------------------------| | Student_ID | Integer | 3 | Unique ID of student | | Name | String | 20 | Name of the student | | Course | Varchar | 10 | Course like B.Tech | --- ### ✅ **Types of Data Dictionary** #### 1. **Active Data Dictionary** - It **updates automatically** when the database changes - Maintained by the **DBMS (Database Software)** - ✅ No need to update it manually #### 2. **Passive Data Dictionary** - It is **updated manually** - It is **separate from the database** - ❌ Can become outdated if not updated properly **"A data dictionary helps in understanding and managing the data used in software systems clearly and correctly."** ### **Q. What is a Data Flow Diagram? What are its rules, components, and levels?** --- ### ✅ **What is a Data Flow Diagram (DFD)?** A **Data Flow Diagram (DFD)** is a **picture** that shows **how data moves** in a system. It tells us: - Where the data comes from - Where it goes - How it is processed It is used to **understand the system** before coding. --- ### ✅ **Components of DFD** 1. **Process** – ➤ Shows action or task (🔵 Circle) ➤ Example: “Verify Login” 2. **Data Store** – ➤ Where data is saved (🟧 Open rectangle) ➤ Example: “Student Records” 3. **Entity** – ➤ External users or systems (⬛ Rectangle) ➤ Example: “Student” or “Admin” 4. **Data Flow** – ➤ Shows movement of data (➡️ Arrow) ➤ Example: “Enter Name”, “Send Report” --- ### ✅ **Levels of DFD** 1. **Level 0 (Context Diagram)** ➤ Highest level ➤ Shows full system as one process ➤ Hides all details 2. **Level 1** ➤ Breaks Level 0 into **main processes** ➤ Shows **major data stores** and flows 3. **Level 2** ➤ Breaks Level 1 into **smaller processes** ➤ More detailed and specific --- ### ✅ **Rules of DFD** 1. Every **process** must have **at least one input and one output** 2. Every **data store** must have a **data flow in and out** 3. Data must move **between process, store, or entity** — not directly from **store to store** or **entity to entity** **"DFD helps in planning the system clearly by showing how data is handled step-by-step."** ### **Q. What do you understand by User Interface Design? Using suitable example, explain its phases.** --- ### ✅ **User Interface (UI) Design** User Interface Design means **creating the screens, buttons, and controls** that users see and use to interact with a software. A good UI should be: ✔ Easy to use ✔ Clear to understand ✔ Looks good ✔ Works fast ✔ Same design on all screens --- ### ✅ **Example** In a **food delivery app**, UI design includes: - Login screen - Search bar - Food menu - Cart button - Order tracking page All these must be simple, clear, and easy to use. --- ### ✅ **Phases of UI Design** #### **1. User, Task & Environment Analysis** - Understand **who the users are**, what they do, and where they use the software. - Example: Are they students, doctors, or shop owners? --- #### **2. Interface Design** - Plan the layout: **What buttons, text, or features** will be shown. - Example: In a login screen – we need a username field, password field, and login button. --- #### **3. Interface Construction** - Create a **sample or prototype** of the interface. - Try it out and improve it based on feedback. - This step is **repeated** until it looks and works well. --- #### **4. Interface Validation** - Test the UI to see if **real users can use it properly**, even in different situations. - Make sure it supports all actions the user needs. **"User Interface Design makes the software user-friendly, easy to understand, and smooth to operate."**

Attribute	Data Type	Size	Description
Student ID	int	03	Student's ID
Name	string	20	Student's Name
Father_Name	string	20	Father's Name
Course	varchar	10	Course Name

Revision - Term 2

Fundamental Issues in Software Design

1. Meeting User Requirements

2. Maintaining Simplicity

3. Scalability

4. Performance

5. Security

6. Flexibility and Maintainability

7. Handling Errors and Failures

8. Usability

9. Interoperability

10. Cost and Time Management

Cohesion and Coupling

Cohesion

High Cohesion

Low Cohesion

Coupling

Low Coupling

High Coupling

How They Work Together

Real-Life Example: Amazon

Benefits of High Cohesion & Low Coupling

Function-Oriented Design (FOD)

General Steps

Key Concepts

Example: Online Library System

Advantages of FOD

Disadvantages of FOD

FOD Strategies

Data Flow Diagrams (DFD)

Types of DFD

DFD Components

DFD Levels

Rules for DFD

Data Dictionary

What it stores (Metadata):

Types of Data Dictionary

Active Data Dictionary

Passive Data Dictionary

Structured Analysis and Structured Design

Structured Analysis

Tools Used in Analysis Phase

Structured Design

Key Design Elements

Objectives of Structured Analysis & Design

Advantages

Disadvantages

UML (Unified Modeling Language)

Why UML is Needed

Major UML Diagrams (Most Important)

1. Class Diagram

2. Use Case Diagram

3. Sequence Diagram

4. Activity Diagram

Object-Oriented Concepts Used in UML

Tools for Drawing UML Diagrams

User Interface (UI) Design

UI Design Principles

UI Design Process

Phase 1: User, Task, and Environment Analysis

Phase 2: Interface Design

Phase 3: Interface Construction

Phase 4: Interface Validation