## 1-Min Overview

> These are the **main challenges** a developer faces when designing software.
> If not handled well, software becomes slow, insecure, confusing, or useless.

---

## 11 Fundamental Issues (Learn with Real-Life Examples)

### 1. Meeting User Requirements
- Understand what users **actually need**.
*E.g., A doctor’s app must show patient history clearly or it’s useless.*

---

### 2. Maintaining Simplicity
- **Don’t overcomplicate** the design.
*Farmers need easy graphs, not confusing dashboards.*

---

### 3. Scalability
- Can the system **handle more users or data** in the future?
*E-commerce site built for 100 users may fail at 10,000 if not scalable.*

---

### 4. Performance
- Should run **fast** and **efficiently**.
*Video editing app must render videos quickly.*

---

### 5. Security
- Protect **data and access** from unauthorized users.
*Banking app must secure account info from hackers.*

---

### 6. Flexibility & Maintainability
- Easy to **update** or **fix bugs**.
*Clinic app should easily add online consultation features later.*

---

### 7. Error Handling
- Handle mistakes **gracefully**, not with crashes.
*Booking system should show "Invalid date" instead of crashing.*

---

### 8. Usability
- Easy to use, even for **non-tech users**.
*Hospital software should be nurse-friendly.*

---

### 9. Interoperability
- Must **work with other systems**.
*Hospital software should share patient data with other hospitals.*

---

### 10. Cost and Time Management
- Stay **within budget and deadlines**.
*Biotech app must be ready before a medical conference.*

---

## Sample 5-Mark Answer

> **Q: Explain any 5 fundamental issues in software design.**
> A:
> 1. **Meeting User Requirements** – The software must fulfill the actual needs of users.
> 2. **Simplicity** – Simple design helps reduce confusion and errors.
> 3. **Scalability** – Software should handle increasing users/data without crashing.
> 4. **Security** – Sensitive data must be protected from unauthorized access.
> 5. **Maintainability** – Software must be easy to update and fix when needed.

---

## Flash Quiz

1. Software should be easy to update → **Maintainability**
2. Sharing data with other systems → **Interoperability**
3. “Invalid date” instead of crash → **Error Handling**
4. App slows down with more users → Poor **Scalability**
5. Simple design helps avoid confusion → **Simplicity**
6. Software must fulfill actual user needs → **Meeting User Requirements**



## 1-Minute Overview

| Concept | Meaning |
|----------|--------|
| **Cohesion** | How **focused** a module is on a single task |
| **Coupling** | How **dependent** a module is on other modules |

**High Cohesion** + **Low Coupling** = Perfect software design
**Low Cohesion** + **High Coupling** = Confusing, buggy design

---

## COHESION (Stick together = One clear job)

### Definition:
> How tightly the parts of a single module/class **work together** to do **one job**.

### High Cohesion (GOOD):
- One module = One task
- Easy to understand
- Easy to test and reuse
- Changes don't affect unrelated code

Example:
A **Shopping Cart** module that only handles cart tasks like add/remove/view items.

---

### Low Cohesion (BAD):
- Module tries to do **too many unrelated things**
- Difficult to maintain or update

Example:
A **Cart** module that also handles login, payments, and product listings.

---

## COUPLING (Link = Dependency between modules)

### Definition:
> How much one module depends on another to work.

### Low Coupling (GOOD):
- Modules are **independent**
- Easy to update/replace modules
- Ideal in large systems

Example:
**Payment Module** and **Cart Module** communicate via API. You can update payment logic without changing the cart.

---

### High Coupling (BAD):
- Modules are tightly connected
- Changing one breaks the other
- Debugging becomes harder

Example:
**Cart** directly handles payment logic like credit card validation, so if payment rules change, cart must change too.

---

## How They Work Together

| Combo | Effect |
|-------|--------|
| High Cohesion + Low Coupling | Best Design (modular, maintainable, flexible) |
| Low Cohesion + High Coupling | Worst Design (spaghetti code, high risk of bugs) |

Think:
> Clean rooms in separate houses (low coupling) doing just their own job (high cohesion).

---

## Real-Life Example: **Amazon**

| Part | Cohesion | Coupling |
|------|----------|----------|
| Product Page | High: Only shows product details | Low: Doesn’t handle checkout |
| Cart | High: Only adds/removes items | Low: Doesn’t know payment details |
| Payment | High: Only does transactions | Low: Doesn’t know product logic |

---

## Sample 5-Mark Answer

> **Q: What are Cohesion and Coupling? Explain with examples.**
> A:
> - **Cohesion** is how focused a module is on doing one task. High cohesion makes modules easier to maintain and reuse.
> - **Coupling** is how much one module depends on another. Low coupling allows changes in one module without affecting others.
> - Example: In an e-commerce website, the **Cart module** with high cohesion only manages cart items. It communicates with the **Payment module** through APIs, showing low coupling. This makes the system flexible and easy to modify.

---

## Flash Quiz (Last-Min Prep)

1. Good design = (dash) → **High Cohesion, Low Coupling**
2. Cohesion is → **How tightly tasks in a module relate**
3. Coupling is → **How much modules depend on each other**
4. Cart + Payment using API = (dash) → **Low Coupling**
5. One module, one job = (dash) → **High Cohesion**
6. Spaghetti code = (dash) → **Low Cohesion + High Coupling**
7. Amazon product page = (dash) → **High Cohesion, Low Coupling**


## 1-Min Overview: What is Function-Oriented Design?

> A design method where **software is divided into small functions**, each doing a specific task.

- Focus is on **what the system should do** (functions), not on objects.
- Uses a **top-down** design approach.
- Helps in **breaking large systems into manageable tasks**.

---

## General Procedure (Very Short Answer Style)

1. **Start with what the system does**  
2. **Break it into high-level functions**
3. **Break those into smaller sub-functions**
4. **Connect them using data flow**

---

## Key Concepts (Must Memorize)

| Concept | Explanation |
|--------|-------------|
| Divides system into **functions** | Each function = 1 task (like login, search) |
| Follows **top-down approach** | Main → sub-function → sub-sub function |
| Uses **Data Flow Diagrams (DFDs)** | Shows how data moves from one function to another |
| Focus on **processes**, not objects | Opposite of Object-Oriented Design |

---

## Example: Online Library System

| Level | Function |
|-------|----------|
| Main Function | `LibrarySystem()` |
| Sub-Functions | `UserManagement()`, `BookManagement()` |
| Further Break | `registerUser()`, `loginUser()`, `addBook()` |

Think: Just keep dividing till each function is easy to implement.

---

## Advantages

- Easy to Understand  
- Reusable Functions  
- Good for Small/Medium Projects

---

## Disadvantages

- Not good for large/complex systems  
- Hard to maintain/modify  
- Less secure (data shared across functions)

---

## Design Strategies in FOD

| Tool | Use |
|------|-----|
| **DFD** | Shows flow of data between functions |
| **Data Dictionary** | Details about data elements |
| **Pseudo Code** | Simple code logic in English |
| **Structure Chart** | Shows function hierarchy and interaction |

---

## DFD (Data Flow Diagram) – Most Important

### Components:
| Symbol | Meaning |
|--------|---------|
| Circle | Process (e.g., “Login”) |
| Rectangle | Entity (e.g., “User”) |
| Open rectangle | Data Store |
| Arrow | Data Flow |

### DFD Levels:
| Level | Description |
|-------|-------------|
| **Level 0** | Big Picture (Context Level) |
| **Level 1** | Breaks big system into main functions |
| **Level 2** | Breaks main functions into smaller processes |

---

## Data Dictionary

> Think: Data **about** data

### Example:

| Field        | Type   | Size | Description           |
|--------------|--------|------|------------------------|
| StudentID    | Int    | 3    | Unique ID of student   |
| Name         | String | 20   | Name of student        |

### Types:
| Type | Description |
|------|-------------|
| **Active** | Auto-updated with DB changes |
| **Passive** | Manually updated |

---

## Sample 5-Mark Answer

> **Q: Explain Function-Oriented Design with its tools.**  
> A: Function-Oriented Design divides the system into small functions using a top-down approach. It focuses on processes and data flow. Tools used include Data Flow Diagrams (DFDs) to represent data movement, Data Dictionaries for storing metadata, Pseudo Code for process logic, and Structure Charts for hierarchy. This design is simple and reusable but less suitable for large or complex systems.

---

## Flash Quiz

1. FOD focuses on → **Functions**
2. DFD shows → **Data Flow**
3. Top-level DFD is → **Level 0**
4. Data Dictionary stores → **Metadata**
5. Opposite of Function-Oriented Design is → **Object-Oriented Design**


## 1-Min Summary

| Term | Meaning |
|------|---------|
| **Structured Analysis** | Understand what the system should do (requirements) |
| **Structured Design** | Decide how the system will be built (design modules, UI, database, etc.) |

**Think like this:**  
> First → Analyze what the user wants (Structured Analysis)  
> Then → Design how to build it (Structured Design)

---

## Objectives of Structured Analysis & Design (Easy 5-mark Question)

| Purpose | Meaning |
|---------|---------|
| Understand Requirements | Know exactly what user needs |
| Break Down System | Divide system into small, manageable parts |
| Define Relationships | Connect components logically |
| Ensure Completeness | Nothing should be left or repeated |
| Improve Communication | Helps devs and clients understand each other |
| Enable Scalability & Maintainability | Easier to grow and fix the system later |

---

## Structured Analysis Phase: (What the system should do)

### Focus: **Understand user’s needs + system behavior**

### Tools Used:
| Tool | Purpose |
|------|---------|
| **Data Flow Diagram (DFD)** | Shows flow of data (input → process → output) |
| **Entity-Relationship Diagram (ERD)** | Shows tables/entities and relationships |
| **Process Specification (PSPEC)** | Explains process logic using simple language or flowcharts |
| **Data Dictionary** | Explains every data field (e.g., `StudentID: Integer`) |
| **Decision Trees / Tables** | Shows logic or choices made by system |
| **State Transition Diagrams** | Shows states and transitions (e.g., Login → Logged In) |

---

## Structured Design Phase: (How the system will work)

### Focus: **Convert analysis into working design**

### Techniques Used:

| Component | Meaning |
|-----------|---------|
| **Modular Design** | Divide system into **modules** with **low coupling, high cohesion** |
| **Structure Chart** | Tree diagram showing module relationships and data flow |
| **Interface Design** | Decide how the **user will interact** (UI/UX) |
| **Database Design** | Plan **tables**, **keys**, and **normalization** |
| **Control Flow Design** | Decide the **order of actions and decisions**

---

## Advantages

- Easy to understand
- Easy to maintain
- Improves communication
- Efficient system design
- Scalable system structure

---

## Disadvantages

- Time-consuming
- Not suitable for fast/agile projects
- Hard to change once finalized

---

## Sample 5-Mark Answer

> **Q: What is Structured Analysis and Design?**  
> A: Structured Analysis is used to study what the system should do using tools like DFDs and ERDs. Structured Design focuses on how to implement it using modules, structure charts, and interface design. It helps build well-organized, maintainable systems.

---

## Flash Quiz (20 sec)

1. DFD shows → (dash) → **Data Flow**
2. ERD shows → (dash) → **Entity Relationships**
3. Design phase shows → (dash) → **How to build**
4. Structured Design makes system → **Modular**
5. PSPEC is used to → **Explain process logic**
6. State Transition Diagram shows → **States and transitions**


## 1-Minute Overview: What is UML?

- **UML** is like the **blueprint** of software.  
- It’s **not a programming language** — it’s a **visual language**.  
- It shows how a system **works**, how users **interact**, and how the parts are **connected**.

> **Think of UML like a movie storyboard — it helps you plan the story (software) before you shoot (code).**

---

## Why is UML Needed? (Super Important 3-mark Q)

| Reason | Explanation |
|--------|-------------|
| Collaboration | Teams and business users need a common language |
| Communication | Explains ideas visually — no need to know code |
| Saves Time | Everyone understands early — fewer changes later |

---

## Main UML Diagrams You Must Know

Use this trick: **CUAS** = **Class, Use case, Activity, Sequence**

---

### Class Diagram (Structure of Software)

- Shows **classes**, their **attributes**, **methods**, and **relationships**
- Like: `User`, `Post`, `Comment` with connections

Think: **Static Design View**  
🛠 Used in: Object-Oriented Programming

---

### Use Case Diagram (User ↔ System)

- Shows how **users interact** with system
- Actors: Human/User or external systems  
- Use Cases: Tasks like “Login”, “Register”, “Checkout”

Think: **Functional View**  
🛠 Used in: Requirement gathering

---

### Activity Diagram (Flow of Activities)

- Like a **flowchart**
- Shows steps, decisions, and loops
- Good for modeling processes (e.g., login, payment)

Think: **Workflow View**  
🛠 Used in: Process modeling

---

### Sequence Diagram (Time-wise Communication)

- Shows **who talks to whom, in what order**
- Helps understand **scenarios** like “Transfer Money”  
- Shows **messages** between objects over time

Think: **Timeline View**  
🛠 Used in: Scenario-based design

---

## Object-Oriented Concepts in UML (Write These in Theory Questions)

| Concept       | Simple Meaning |
|---------------|----------------|
| Class        | Blueprint of object |
| Object       | Instance of class |
| Inheritance  | Child inherits from parent |
| Abstraction  | Show only what matters |
| Encapsulation | Protect data (use private/protected) |
| Polymorphism | One function, many forms |

---

## 🛠 Tools for Making UML Diagrams (Mention 2 if asked)

1. **Draw.io** – Free, online, easy to use  
2. **Lucidchart** – Collaborative diagramming  
3. **StarUML** – Open-source tool  
4. **Visual Paradigm** – Professional, all-in-one tool  

---

## Write: Sample 3-Mark Answer

> **Q: What is a Use Case Diagram?**  
> A: A Use Case Diagram shows the **interactions between users (actors) and the system**. It helps identify the **functional requirements** of the system. Each use case represents a task like “Login”, “Place Order”, etc. It is useful during the **requirement analysis** phase.

---

## Flash Quiz (Last-Minute Recall – 20 sec)

1. UML stands for (dash) → **Unified Modeling Language**  
2. Use Case Diagrams show (dash) → **User-System Interactions**  
3. Class Diagrams show → **Classes, attributes, methods**  
4. Activity Diagrams are similar to → **Flowcharts**  
5. Sequence Diagrams show → **Time-ordered communication**


## 1-Min Summary: What is User Interface Design?

**User Interface Design** means:
> Designing how users interact with software — **the screen they see, the buttons they press, and how smooth everything feels.**

Imagine your favorite app — if it looks good, works fast, is easy to understand — that’s good UI Design.

---

## Key Features of a Good UI (Must Memorize)

A good UI is:

| Feature       | Meaning (Easiest Way)                        |
|---------------|-----------------------------------------------|
| Attractive  | Looks nice and pleasant                      |
| Simple      | Easy to use, no confusion                    |
| Responsive  | Works fast, reacts quickly                   |
| Clear       | You know exactly what to do                  |
| Consistent  | Same style across all screens                |

---

## UI Design Principles (Super Important)

Use this trick: **SSVFT**

| Principle     | Meaning (Remember with Real-Life Example)                                |
|---------------|---------------------------------------------------------------------------|
| Structure   | Arrange info clearly (like your notes)                                   |
| Simplicity  | Keep it clean, avoid clutter (like clean room = easy to find stuff)      |
| Visibility  | Show only what’s needed (don’t hide things like exam hall instructions)  |
| Feedback    | Give response (like “Answer submitted” or “Error!”)                      |
| Tolerance   | Allow mistakes (Undo button, autosave, etc.)                             |

---

## 4 Phases of UI Design Process (Very Likely Question)

Learn this 4-step cycle: **Analyze → Design → Build → Check**

### Phase 1: User, Task, Environment Analysis
- Study the **users** (age, skills, knowledge)
- Understand **what tasks** they need to do
- Check **environment** (device, lighting, etc.)

Think: Who will use it? What for? Where?

---

### Phase 2: Interface Design
- Plan what the **user needs to do**
- Identify **objects** (like "buttons", "menus") and their **actions**

Think: What are the parts and what can I do with them?

---

### Phase 3: Interface Construction
- Build a **prototype** (rough version of UI)
- Test and improve it again and again until ready

Think: Try–Test–Improve (like drafts before final project)

---

### Phase 4: Interface Validation
- Final check: Can the user **really use it easily** in real life?

Think: Does it work in real-world use cases?

---

## How to Write Perfect 3-5 Mark Answers (Template Style)

> **Q: What are the principles of UI Design?**  
> A: The principles of UI Design are:
> 1. **Structure** – Organize content meaningfully.  
> 2. **Simplicity** – Keep interface clean and easy.  
> 3. **Visibility** – Show necessary info only.  
> 4. **Feedback** – System should give responses.  
> 5. **Tolerance** – Allow user mistakes safely.

---

## Quick Fill-in-the-Blank Style Practice (Revise in 30 sec)

1. UI is the (dash) view that users interact with. → **front-end**
2. A good UI should be (dash) and (dash) to understand. → **attractive**, **clear**
3. UI design has (dash) main phases. → **4**
4. Phase 3 of UI design is called (dash). → **Interface Construction**
5. Feedback in UI means (dash). → **showing responses to user actions**