Enhance your performance in BSCS courses at KASB Institute of Technology in Karachi with effective study notes. Learn tips on creating and organizing study materials for success., studying BSCS at KASB Institute of Technology in Karachi can be a rewarding experience with the right approach and dedication. By following the study notes provided in this article and utilizing available resources, you can enhance your learning and academic performance in the BSCS program. Remember, consistency and hard work are key to achieving success in your academic journey at KASB Institute of Technology.
Study Notes BSCS at KASB Institute of Technology, Karachi.
Programming Fundamentals (Core) – Comprehensive Study Notes
Course Overview
| Attribute | Details |
|---|---|
| Course Title | Programming Fundamentals |
| Focus | Core concepts of computer programming: algorithms, variables, data types, control structures, functions, arrays, pointers, file I/O, and basic data structures |
| Prerequisites | None (introductory course) |
| Common Languages | C, C++, Python, Java (these notes use language-agnostic pseudocode with C/Python references) |
PART 1: Introduction to Programming
1.1 What is Programming?
Programming (also called coding) is the process of designing and writing instructions (code) that a computer can execute to perform specific tasks or solve problems. A set of instructions is called a program or software.
Levels of Programming Languages:
| Level | Description | Examples | Advantages | Disadvantages |
|---|---|---|---|---|
| Machine Language (1GL) | Binary code (0s and 1s) directly executed by CPU | 10110000 01100001 | Fastest execution; no translation needed | Extremely difficult for humans to write/read; hardware-specific |
| Assembly Language (2GL) | Mnemonic codes representing machine instructions | MOV AL, 61h | More readable than machine language; still efficient | Still hardware-specific; requires assembler |
| High-Level Language (3GL) | Human-readable syntax; compiled or interpreted | a = 97 |
Portable across platforms; easier to write/debug | Slower execution (requires translation) |
| Fourth-Generation Language (4GL) | Domain-specific; very high-level (database queries, report generation) | SQL: SELECT * FROM users |
Very concise; less coding required | Limited to specific domains |
| Fifth-Generation Language (5GL) | Declarative; logic-based (AI, rule-based systems) | Prolog rules | Solves problems using constraints | Niche applications |
1.2 The Programming Process
| Step | Description | Output |
|---|---|---|
| 1. Problem Analysis | Understand the problem; identify inputs, outputs, constraints | Problem specification document |
| 2. Algorithm Design | Develop step-by-step solution (flowchart, pseudocode) | Algorithm |
| 3. Coding (Implementation) | Translate algorithm into programming language | Source code (.c, .py, .java files) |
| 4. Compilation/Interpretation | Convert source code to machine-executable form | Executable (.exe, .out) or bytecode |
| 5. Testing & Debugging | Run program; find and fix errors (syntax, logic, runtime) | Working program |
| 6. Maintenance | Update program to fix bugs or add features | Updated versions |
1.3 Algorithms and Flowcharts
Algorithm: Finite sequence of well-defined, unambiguous instructions to solve a problem.
Example Algorithm (Find Average of Three Numbers):
Step 1: Start Step 2: Input three numbers A, B, C Step 3: Compute Sum = A + B + C Step 4: Compute Average = Sum / 3 Step 5: Output Average Step 6: End
Flowchart Symbols:
| Symbol | Name | Meaning |
|---|---|---|
| ▭ (oval) | Terminator | Start or end of program |
| ▭ (parallelogram) | Input/Output | Read data or print results |
| ▭ (rectangle) | Process | Assignment or arithmetic operation |
| ◇ (diamond) | Decision | Conditional branch (if-else) |
| ○ (circle) | Connector | Connects flowchart parts |
| → (arrow) | Flow line | Direction of program flow |
PART 2: Basic Programming Concepts
2.1 Variables and Constants
Variable: Named memory location that can store a value that may change during program execution.
# Python count = 10 # integer variable price = 49.99 # float variable name = "Alice" # string variable is_valid = True # boolean variable
Constant: Named value that cannot change after initialization.
// C #define PI 3.14159 const int MAX_USERS = 100;
Naming Rules (most languages):
-
Must start with letter (a-z, A-Z) or underscore (_)
-
Can contain letters, digits, underscores (no spaces)
-
Cannot use reserved keywords (
if,while,return, etc.) -
Case-sensitive (
Count≠count)
2.2 Data Types
| Type | Description | Size (typical) | Range (typical) | Examples |
|---|---|---|---|---|
| int | Integer (whole numbers) | 2-4 bytes | -2,147,483,648 to 2,147,483,647 | 42, -17, 0 |
| float | Single-precision floating point | 4 bytes | ±1.5×10⁻⁴⁵ to ±3.4×10³⁸ | 3.14, -0.5, 2.0 |
| double | Double-precision floating point | 8 bytes | ±5.0×10⁻³²⁴ to ±1.7×10³⁰⁸ | 3.14159265359 |
| char | Single character | 1 byte | ASCII: -128 to 127 or 0 to 255 | ‘A’, ‘9’, ‘&’ |
| bool | Boolean (true/false) | 1 byte | true (1) or false (0) | true, false |
| string | Sequence of characters | Varies | N/A | “Hello World” |
2.3 Operators
Arithmetic Operators:
| Operator | Operation | Example | Result |
|---|---|---|---|
| + | Addition | 5 + 3 | 8 |
| – | Subtraction | 5 – 3 | 2 |
| * | Multiplication | 5 * 3 | 15 |
| / | Division | 5 / 2 | 2.5 (Python); 2 (C integer division) |
| % | Modulus (remainder) | 5 % 2 | 1 |
| ** | Exponentiation (Python) | 2 ** 3 | 8 |
| // | Floor division (Python) | 7 // 2 | 3 |
Relational (Comparison) Operators:
| Operator | Meaning | Example | Result |
|---|---|---|---|
| == | Equal to | 5 == 3 | false |
| != | Not equal to | 5 != 3 | true |
| > | Greater than | 5 > 3 | true |
| < | Less than | 5 < 3 | false |
| >= | Greater than or equal to | 5 >= 5 | true |
| <= | Less than or equal to | 3 <= 5 | true |
Logical Operators:
| Operator (C/Python) | Meaning | Truth Table |
|---|---|---|
| && (C) / and (Python) | Logical AND | T && T = T; T && F = F; F && T = F; F && F = F |
| || (C) / or (Python) | Logical OR | T || T = T; T || F = T; F || T = T; F || F = F |
| ! (C) / not (Python) | Logical NOT | !T = F; !F = T |
2.4 Type Conversion
Implicit (Automatic) Conversion: Compiler automatically converts one type to another.
int a = 10; double b = a; // int → double (10.0)
Explicit (Type Casting): Programmer manually converts type.
// C double x = 7.5; int y = (int)x; // y = 7 (truncates) // Python x = 7.5 y = int(x) # y = 7
PART 3: Control Structures
Control structures determine the order in which statements are executed.
3.1 Sequential
Statements execute in order (top to bottom). This is the default.
a = 5 b = 10 c = a + b print(c) # Outputs: 15
3.2 Selection (Conditional)
if Statement:
// C if (condition) { // executed if condition is true }
# Python if condition: # executed if condition is true
if-else Statement:
if (condition) { // executed if condition is true } else { // executed if condition is false }
if-else if-else (Ladder):
if (score >= 90) { grade = 'A'; } else if (score >= 80) { grade = 'B'; } else if (score >= 70) { grade = 'C'; } else { grade = 'F'; }
Switch Statement (C/C++/Java):
switch (day) { case 1: printf("Monday"); break; case 2: printf("Tuesday"); break; default: printf("Invalid day"); }
Note: Python does not have a switch statement (if-elif used instead; match-case in Python 3.10+).
3.3 Iteration (Loops)
while Loop: Repeats while condition is true (zero or more times).
# Python count = 1 while count <= 5: print(count) count += 1
// C int count = 1; while (count <= 5) { printf("%d", count); count++; }
do-while Loop (C/C++): Executes at least once (condition checked at end).
int count = 1; do { printf("%d", count); count++; } while (count <= 5);
for Loop: Combines initialization, condition, and increment in one line.
# Python for i in range(1, 6): # i = 1,2,3,4,5 print(i)
// C for (int i = 1; i <= 5; i++) { printf("%d", i); }
Nested Loops: Loop inside another loop.
for i in range(1, 4): # outer loop for j in range(1, 4): # inner loop print(f"{i},{j}")
3.4 Jump Statements
| Statement | C | Python | Effect |
|---|---|---|---|
| break | break; |
break |
Exits the innermost loop/switch |
| continue | continue; |
continue |
Skips rest of iteration; jumps to next |
| return | return value; |
return value |
Exits function; returns value |
| goto | goto label; |
Not available | Jumps to labeled statement (avoid) |
PART 4: Functions (Modular Programming)
4.1 What is a Function?
Function: Reusable block of code that performs a specific task. Benefits: modularity, reusability, easier debugging, reduced code duplication.
4.2 Function Components
| Component | Description | Example |
|---|---|---|
| Return Type | Type of value returned (void if none) | int, float, void |
| Function Name | Identifier used to call function | calculateArea |
| Parameters | Inputs received by function | int length, int width |
| Function Body | Statements that execute | return length * width; |
4.3 Function Examples
C:
#include <stdio.h> // Function declaration (prototype) int add(int a, int b); int main() { int result = add(5, 3); // function call printf("Sum: %d", result); return 0; } // Function definition int add(int a, int b) { return a + b; }
Python:
def add(a, b): """Returns sum of a and b""" return a + b result = add(5, 3) print(f"Sum: {result}")
4.4 Parameter Passing Mechanisms
| Mechanism | C | Python | Description |
|---|---|---|---|
| Pass by Value | Default | – | Copy of value passed; original unchanged |
| Pass by Reference | Via pointers | Default (for mutable objects) | Address/reference passed; original can be modified |
4.5 Variable Scope
| Scope | Description | Lifetime |
|---|---|---|
| Local | Declared inside function; accessible only within that function | Created on function entry; destroyed on exit |
| Global | Declared outside all functions; accessible throughout program | Entire program execution |
| Static | Preserves value between function calls | Entire program execution (but only accessible within function) |
int global = 100; // global variable void func() { static int count = 0; // static variable (retains value) int local = 10; // local variable count++; global++; }
4.6 Recursion
Recursion: Function that calls itself (directly or indirectly).
Recursion vs. Iteration:
| Aspect | Recursion | Iteration |
|---|---|---|
| Termination | Base condition required | Loop condition required |
| Memory usage | More (each call adds stack frame) | Less (single stack frame) |
| Speed | Slower (function call overhead) | Faster |
| Code readability | Elegant for some problems (trees) | Often simpler for linear problems |
| Stack overflow risk | Yes (deep recursion) | No |
Example (Factorial):
def factorial(n): if n <= 1: # base case return 1 else: # recursive case return n * factorial(n - 1) # factorial(5) = 5 * 4 * 3 * 2 * 1 = 120
Example (Fibonacci):
def fibonacci(n): if n <= 1: return n return fibonacci(n - 1) + fibonacci(n - 2)
PART 5: Arrays and Strings
5.1 Arrays (One-Dimensional)
Array: Collection of elements of same data type stored in contiguous memory locations.
C Array Declaration and Initialization:
int numbers[5]; // declaration (uninitialized) int scores[5] = {85, 90, 78, 92, 88}; // declaration + initialization int values[] = {1, 2, 3}; // size inferred (3) // Accessing elements (0-indexed) scores[0] = 95; // first element int x = scores[2]; // third element (78)
Common Array Operations (C):
int arr[5] = {10, 20, 30, 40, 50}; // Traversal for (int i = 0; i < 5; i++) { printf("%d ", arr[i]); // Output: 10 20 30 40 50 } // Sum int sum = 0; for (int i = 0; i < 5; i++) { sum += arr[i]; } // sum = 150 // Search (linear) int target = 30; int found = 0; for (int i = 0; i < 5; i++) { if (arr[i] == target) { found = 1; printf("Found at index %d", i); break; } }
Python Lists (dynamic arrays):
numbers = [10, 20, 30, 40, 50] # list (size can change) numbers.append(60) # add element numbers.insert(2, 25) # insert at index 2 numbers.remove(40) # remove by value print(numbers[1]) # access element (20)
5.2 Arrays: Two-Dimensional (Matrices)
// C – 3 rows, 4 columns int matrix[3][4] = { {1, 2, 3, 4}, {5, 6, 7, 8}, {9, 10, 11, 12} }; // Access element int val = matrix[1][2]; // row 1, column 2 = 7 // Traversal for (int i = 0; i < 3; i++) { // rows for (int j = 0; j < 4; j++) { // columns printf("%d ", matrix[i][j]); } printf("\n"); }
# Python (list of lists) matrix = [ [1, 2, 3, 4], [5, 6, 7, 8], [9, 10, 11, 12] ] print(matrix[1][2]) # 7
5.3 Strings
C Strings: Null-terminated character arrays.
char str1[20] = "Hello"; // automatic null terminator '\0' char str2[] = "World"; char str3[6] = {'H', 'e', 'l', 'l', 'o', '\0'}; // explicit null terminator // String functions (string.h) #include <string.h> strlen(str1); // returns length (5 – excludes '\0') strcpy(dest, src); // copies src to dest strcat(dest, src); // appends src to dest strcmp(str1, str2); // compares (0 if equal)
Python Strings:
message = "Hello World" print(len(message)) # length print(message[0]) # first character ('H') print(message[6:11]) # slicing ("World") print(message.upper()) # "HELLO WORLD" print(message.split()) # ['Hello', 'World']
PART 6: Pointers (C/C++ specific)
6.1 Pointer Basics
Pointer: Variable that stores memory address of another variable.
int num = 42; // ordinary integer variable int *ptr = # // pointer to integer (stores address of num) printf("%d", num); // prints 42 (value) printf("%p", &num); // prints address of num printf("%p", ptr); // prints same address printf("%d", *ptr); // dereference: prints 42 (value at that address)
Pointer Operators:
| Operator | Name | Meaning |
|---|---|---|
& |
Address-of | Returns memory address of a variable |
* |
Dereference | Returns value stored at address pointed to |
6.2 Pointers and Arrays
Array name acts as pointer to first element.
int arr[5] = {10, 20, 30, 40, 50}; // These are equivalent: arr[0] == *(arr + 0) // 10 arr[1] == *(arr + 1) // 20 arr[2] == *(arr + 2) // 30 // Pointer arithmetic int *p = arr; // points to arr[0] p++; // now points to arr[1]
6.3 Dynamic Memory Allocation (C)
Allocate memory at runtime (heap).
#include <stdlib.h> // malloc – allocates memory (uninitialized) int *ptr = (int*)malloc(5 * sizeof(int)); // array of 5 ints // calloc – allocates and initializes to zero int *ptr2 = (int*)calloc(5, sizeof(int)); // all zeros // realloc – resize previously allocated memory ptr = (int*)realloc(ptr, 10 * sizeof(int)); // now 10 ints // free – deallocate memory free(ptr);
6.4 Pointers to Functions
#include <stdio.h> int add(int a, int b) { return a + b; } int main() { int (*funcPtr)(int, int) = add; // pointer to function int result = funcPtr(5, 3); // call through pointer (result = 8) return 0; }
PART 7: Basic File I/O
7.1 File Operations (C)
| Operation | Function | Description |
|---|---|---|
| Open file | fopen() |
Opens file; returns file pointer |
| Close file | fclose() |
Closes file; flushes buffers |
| Read character | fgetc() |
Reads one character |
| Write character | fputc() |
Writes one character |
| Read string | fgets() |
Reads a line |
| Write string | fputs() |
Writes a string |
| Formatted read | fscanf() |
Reads formatted data |
| Formatted write | fprintf() |
Writes formatted data |
File Opening Modes:
| Mode | Description |
|---|---|
"r" |
Read (file must exist) |
"w" |
Write (creates or truncates) |
"a" |
Append (writes at end) |
"r+" |
Read and write |
"w+" |
Read and write (truncates) |
"a+" |
Read and append |
Example (Write to File):
#include <stdio.h> int main() { FILE *fp = fopen("data.txt", "w"); if (fp == NULL) { printf("Error opening file!"); return 1; } fprintf(fp, "Hello World\n"); fprintf(fp, "Number: %d\n", 42); fclose(fp); return 0; }
Example (Read from File):
FILE *fp = fopen("data.txt", "r"); if (fp == NULL) { printf("File not found!"); return 1; } char buffer[100]; while (fgets(buffer, 100, fp) != NULL) { printf("%s", buffer); } fclose(fp);
7.2 File Operations (Python)
# Write to file with open("data.txt", "w") as file: file.write("Hello World\n") file.write(f"Number: {42}\n") # Read from file with open("data.txt", "r") as file: content = file.read() # entire file # or for line in file: print(line.strip()) # line by line
PART 8: Error Types and Debugging
8.1 Types of Errors
| Error Type | Description | Example | Detection |
|---|---|---|---|
| Syntax Error | Violates language grammar rules | printf("Hello" (missing closing parenthesis) |
Compiler/Interpreter |
| Runtime Error | Occurs during program execution | Division by zero; file not found | Program crashes during execution |
| Logic Error | Program runs but produces incorrect output | Using = instead of == in condition; incorrect formula |
Testing/debugging |
| Semantic Error | Code meaning is wrong (language rule satisfied but logic flawed) | int x = 10 / 0; (undefined behavior) |
Compiler may warn; testing |
8.2 Debugging Techniques
| Technique | Description |
|---|---|
| Print statements | Insert printf()/print() to trace variable values and execution flow |
| Step-through debugging | Execute program line by line using debugger (gdb, VS Code debugger, PyCharm) |
| Breakpoints | Pause execution at specific lines to inspect state |
| Watch variables | Monitor value changes of specific variables during execution |
| Code review | Have another programmer examine code (pair programming, pull requests) |
| Rubber duck debugging | Explain code line by line to inanimate object (often reveals errors) |
PART 9: Introduction to Data Structures
9.1 What are Data Structures?
Data structure: Way of organizing and storing data in a computer so it can be accessed and modified efficiently.
9.2 Basic Data Structures
| Structure | Description | Operations | Use Cases |
|---|---|---|---|
| Array | Contiguous memory; fixed size | Access: O(1); Insert/Delete: O(n) | Fixed-size collections; matrix operations |
| Linked List | Nodes connected by pointers; dynamic size | Access: O(n); Insert/Delete (at head): O(1) | When frequent insertions/deletions needed |
| Stack (LIFO) | Last-In, First-Out | Push, Pop, Peek: O(1) | Function call stack; undo/redo; expression evaluation |
| Queue (FIFO) | First-In, First-Out | Enqueue, Dequeue: O(1) | Print spooling; task scheduling; BFS in graphs |
| Hash Table | Key-value pairs; uses hash function | Average Insert/Delete/Search: O(1); Worst: O(n) | Dictionaries; caches; database indexing |
| Tree | Hierarchical structure with root and children | Search: O(log n) average (balanced) | File systems; expression parsing; HTML DOM |
| Graph | Nodes (vertices) + edges (connections) | Varies by algorithm | Social networks; GPS navigation (shortest path) |
9.3 Stack Implementation (C)
#define MAX 100 int stack[MAX]; int top = -1; void push(int value) { if (top >= MAX - 1) { printf("Stack Overflow\n"); return; } stack[++top] = value; } int pop() { if (top == -1) { printf("Stack Underflow\n"); return -1; } return stack[top--]; } int peek() { return stack[top]; } int isEmpty() { return top == -1; }
9.4 Queue Implementation (C – Circular)
#define MAX 100 int queue[MAX]; int front = 0; int rear = -1; int count = 0; void enqueue(int value) { if (count == MAX) { printf("Queue Full\n"); return; } rear = (rear + 1) % MAX; queue[rear] = value; count++; } int dequeue() { if (count == 0) { printf("Queue Empty\n"); return -1; } int value = queue[front]; front = (front + 1) % MAX; count--; return value; }
Summary Table for Revision
1. Data Types (C)
| Type | Size (bytes) | Format Specifier | Example |
|---|---|---|---|
| int | 2 or 4 | %d | int x = 10; |
| float | 4 | %f | float pi = 3.14f; |
| double | 8 | %lf | double big = 3.14159; |
| char | 1 | %c | char letter = 'A'; |
| (void) | – | – | pointer types |
2. Loop Comparison
| Loop | Condition Check | Executes at least once | Use case |
|---|---|---|---|
| for | Top | No | Known iteration count |
| while | Top | No | Unknown iteration count (entry-controlled) |
| do-while | Bottom | Yes | Must execute at least once (exit-controlled) |
3. Memory Sections (C)
| Section | Contents | Lifetime |
|---|---|---|
| Code (Text) | Program instructions | Entire run |
| Data (Static) | Global and static variables | Entire run |
| Stack | Local variables, function parameters, return addresses | Function call duration |
| Heap | Dynamically allocated memory (malloc/calloc) | Until freed |
Glossary of Key Terms
| Term | Definition |
|---|---|
| Algorithm | Step-by-step procedure for solving a problem |
| Variable | Named storage location for data (value can change) |
| Constant | Named value that cannot be changed after initialization |
| Function | Reusable block of code that performs a specific task |
| Array | Collection of elements of same type, stored contiguously |
| Pointer | Variable that stores a memory address (C/C++) |
| Recursion | Function that calls itself |
| Stack | LIFO data structure (push/pop) |
| Queue | FIFO data structure (enqueue/dequeue) |
| Heap (memory) | Region for dynamically allocated memory |
| IDE | Integrated Development Environment (VS Code, PyCharm, Code::Blocks, Eclipse, IntelliJ) |
| Compiler | Translates entire source code to executable (C, C++, Java) |
| Interpreter | Executes source code line by line (Python, JavaScript, Ruby) |
| Debugger | Tool to step through code and inspect variables (gdb, pdb, IDE built-in) |
Sample Pseudocode Reference
Input/Output:
INPUT variable OUTPUT "message", variable
Assignment:
variable ← expression
Conditional:
IF condition THEN
statements
ELSE IF condition THEN
statements
ELSE
statements
END IF
Looping:
WHILE condition DO
statements
END WHILE
FOR variable ← start TO end DO
statements
END FOR
Function:
FUNCTION name(parameters)
statements
RETURN value
END FUNCTION
Recommended Textbooks
-
Kernighan, B.W. & Ritchie, D.M. The C Programming Language (2nd ed.). Prentice Hall. (“K&R C” – classic reference)
-
Deitel, P.J. & Deitel, H.M. C: How to Program. Pearson.
-
Downey, A. Think Python (2nd ed.). O’Reilly. (Free online)
-
Cormen, T.H. et al. Introduction to Algorithms (4th ed.). MIT Press. (Data structures and algorithms)
-
Sedgewick, R. & Wayne, K. Algorithms (4th ed.). Addison-Wesley. (Java; algorithms focus)
These notes provide a comprehensive foundation for an introductory programming course. Mastery requires practice: write code regularly, debug systematically, and trace through examples step-by-step.
Study Notes: Application of Information and Communication Technologies (ICT) in General Education
1. What is ICT in Education?
Information and Communication Technology (ICT) refers to all technologies used to handle telecommunications, broadcast media, intelligent building management systems, audiovisual processing, and network-based control and monitoring functions.
In education, ICT means using digital tools, hardware, software, and internet-based resources to enhance teaching, learning, and administration.
Key Components of ICT
| Component | Examples |
|---|---|
| Hardware | Computers, tablets, interactive whiteboards, projectors, printers |
| Software | Learning management systems (LMS), word processors, simulation software |
| Networks | Internet, intranet, Wi-Fi, cloud services |
| Digital content | E-books, educational videos, podcasts, online courses |
| Communication tools | Email, forums, video conferencing, chat apps |
2. Rationale for Using ICT in General Education
Why integrate ICT?
| Reason | Explanation |
|---|---|
| Access to information | Instant access to global knowledge resources |
| Engagement | Interactive content increases student motivation |
| Differentiation | Adapts to diverse learning styles and paces |
| Collaboration | Enables group work beyond classroom walls |
| Real-world preparation | Digital literacy essential for modern careers |
| Efficiency | Automates grading, attendance, record keeping |
| Lifelong learning | Supports education beyond formal schooling |
3. Major Applications of ICT in the Classroom
A. Teaching & Instruction
| Application | Description |
|---|---|
| Presentation tools | PowerPoint, Prezi, Google Slides for visual lessons |
| Interactive whiteboards | Smartboards for touch-based annotation and media |
| Digital simulations | Virtual labs (e.g., PhET for science) |
| Educational software | Drill-and-practice (e.g., Khan Academy, Duolingo) |
| Video lessons | Pre-recorded or flipped classroom (YouTube, Edpuzzle) |
B. Learning Management Systems (LMS)
| LMS Platform | Key Features |
|---|---|
| Google Classroom | Assignment distribution, grading, class discussions |
| Moodle | Open-source, quizzes, forums, tracking |
| Canvas | Integrations, analytics, mobile app |
| Microsoft Teams for Education | Video meetings, file sharing, OneNote class notebooks |
C. Assessment & Feedback
| Tool/Application | Use Case |
|---|---|
| Online quizzes | Google Forms, Kahoot!, Quizizz – instant feedback |
| Plagiarism detection | Turnitin, Grammarly |
| E-portfolios | Seesaw, Google Sites – showcase student work |
| Grading automation | ZipGrade, LMS rubrics |
D. Communication & Collaboration
| Tool | Purpose |
|---|---|
| Teacher-parent, teacher-student communication | |
| Forums (e.g., Padlet, Discourse) | Asynchronous discussion |
| Video conferencing (Zoom, Meet) | Remote classes, virtual office hours |
| Collaborative documents (Google Docs) | Real-time group writing and editing |
E. Content Creation by Students
| Activity | ICT Tool |
|---|---|
| Digital storytelling | Canva, Adobe Spark, Book Creator |
| Podcasts | Anchor (Spotify for Podcasters) |
| Videos | WeVideo, iMovie, Screencastify |
| Presentations | Google Slides, Prezi, Genially |
| Coding & game design | Scratch, Code.org, Tynker |
F. Administrative Applications
| Task | ICT Tool |
|---|---|
| Attendance tracking | QR codes, biometric systems, LMS check-ins |
| Timetabling | Automated schedulers (e.g., TimeTabler) |
| Fee management | School ERP systems (e.g., Fedena, Classter) |
| Parent portals | Real-time access to grades and updates |
4. ICT Integration Models (Frameworks)
SAMR Model (Puentedura)
Describes levels of technology integration:
| Level | Description | Example |
|---|---|---|
| Substitution | Tech replaces tool with no change | Typing instead of handwriting |
| Augmentation | Tech replaces with slight improvement | Using spellcheck while typing |
| Modification | Redesigns task significantly | Sharing draft online for peer review |
| Redefinition | Creates new, previously impossible task | Global collaboration via video conference |
TPACK Framework (Mishra & Koehler)
Three knowledge domains overlap:
-
Technological Knowledge (TK)
-
Pedagogical Knowledge (PK)
-
Content Knowledge (CK)
Effective teaching requires intersection of all three (TPACK).
5. Benefits of ICT in General Education
| Benefit | Detailed Explanation |
|---|---|
| Personalized learning | Adaptive software adjusts difficulty; students pace themselves. |
| Increased motivation | Gamification (badges, leaderboards) engages digital natives. |
| 24/7 access | Cloud resources allow learning anytime, anywhere. |
| Rich multimedia | Combines text, audio, video, animation for deeper understanding. |
| Global classrooms | Virtual exchanges, e-pals, cultural collaborations. |
| Immediate feedback | Auto-graded quizzes provide instant correction. |
| Reduced administrative load | Teachers spend more time on instruction. |
6. Challenges & Limitations
| Challenge | Description | Mitigation Strategy |
|---|---|---|
| Digital divide | Unequal access to devices and internet | Provide school devices; offline content; community Wi-Fi |
| Teacher training | Lack of ICT competency | Ongoing professional development; peer mentoring |
| Distraction | Students off-task using entertainment | Classroom management software; clear guidelines |
| Cybersecurity & privacy | Data breaches, inappropriate content | Firewalls; COPPA/FERPA compliance; digital citizenship lessons |
| Cost | Hardware, software, maintenance | Open-source software; government grants; BYOD policies |
| Over-reliance | Reduced handwriting, mental math, face-to-face skills | Balanced integration; offline activities |
| Technical support | Breakdowns disrupt learning | On-site IT support; backup plans |
7. ICT Tools Categorized by Educational Goal
| Goal | Recommended Tools |
|---|---|
| Present content | PowerPoint, Nearpod, Pear Deck, YouTube |
| Practice skills | Quizlet, Kahoot!, IXL, Duolingo, Mathletics |
| Create artifacts | Canva, Adobe Express, Book Creator, Scratch |
| Collaborate | Google Workspace, Padlet, Trello, Miro |
| Assess understanding | Socrative, Formative, Google Forms, Mentimeter |
| Manage classroom | ClassDojo (behavior), Google Classroom (assignments) |
| Communicate | Remind (mass texts), Seesaw (parent updates) |
| Teach coding | Code.org, Scratch, Replit (text-based) |
8. Best Practices for ICT Integration
DOs
-
✅ Align technology with learning objectives (not tech for tech’s sake).
-
✅ Provide clear instructions and technical support.
-
✅ Use active learning strategies (create, collaborate, debate).
-
✅ Ensure accessibility (closed captions, screen reader compatibility).
-
✅ Teach digital citizenship (privacy, copyright, online safety).
-
✅ Start small; scale successful tools.
DON’Ts
-
❌ Assume students already know how to use educational tech.
-
❌ Replace teacher with screens entirely.
-
❌ Ignore data privacy laws.
-
❌ Overload students with too many platforms.
-
❌ Neglect offline, hands-on activities.
9. ICT in Different Subject Areas (Examples)
| Subject | ICT Application Example |
|---|---|
| Language Arts | Google Docs for peer editing; blogging platforms; audiobooks |
| Mathematics | GeoGebra (visual geometry); Desmos (graphing); Prodigy (game-based) |
| Science | Virtual labs (Labster); PhET simulations; data logging sensors |
| Social Studies | Google Earth (historical sites); primary source archives (Library of Congress) |
| Foreign Language | Duolingo; Tandem (language exchange); subtitled videos |
| Arts | Digital painting (Krita); music composition (Soundtrap); stop-motion animation |
| Physical Education | Wearable fitness trackers; video analysis of techniques |
10. Emerging Trends in ICT for Education
| Trend | Description |
|---|---|
| Artificial Intelligence (AI) | Adaptive tutors (e.g., Carnegie Learning); automated essay scoring; chatbots for FAQs |
| Virtual & Augmented Reality (VR/AR) | Immersive field trips (Google Expeditions); anatomy in 3D |
| Learning Analytics | Data dashboards to predict at-risk students |
| Gamification & serious games | Minecraft: Education Edition; Classcraft |
| Mobile learning (m-learning) | Smartphones as learning devices; microlearning apps |
| Open Educational Resources (OER) | Free textbooks (OpenStax); Creative Commons media |
| Blockchain for credentials | Verifiable digital diplomas |
11. Sample Lesson Integration (Example)
Subject: Grade 7 Geography – Climate Change
ICT Tools Used: Google Slides, Padlet, PhET simulation (Greenhouse Effect), Flip (video responses)
Lesson Flow:
-
Engage: Watch a 3-min video on climate change (YouTube).
-
Explore: Use PhET simulation – students adjust CO₂ levels and observe temperature change.
-
Explain: Small group discussion on Padlet – share observations.
-
Elaborate: Create a 90-second Flip video explaining one cause and one solution.
-
Evaluate: Teacher rubric based on science accuracy and presentation quality.
12. Glossary of Key ICT-in-Education Terms
| Term | Definition |
|---|---|
| Asynchronous learning | Not real-time (e.g., recorded lessons, forums) |
| Synchronous learning | Real-time (e.g., live video class) |
| Flipped classroom | Students watch video lectures at home; do activities in class |
| BYOD | Bring Your Own Device |
| LMS | Learning Management System |
| OER | Open Educational Resources (free to use/adapt) |
| Digital divide | Gap between those with/without access to ICT |
| Digital citizenship | Responsible use of technology |
| Cloud computing | Storing and accessing data via internet |
| Gamification | Applying game elements to non-game contexts |
Summary – Key Takeaways for Revision
-
ICT in education includes hardware, software, networks, and digital content.
-
Major applications: teaching, LMS, assessment, communication, content creation, administration.
-
Two key frameworks: SAMR (Substitution to Redefinition) and TPACK (Tech + Pedagogy + Content).
-
Benefits: personalization, motivation, access, immediate feedback.
-
Challenges: digital divide, training, distraction, cost, privacy.
-
Best practices: align with goals, teach digital citizenship, balance online/offline.
-
Emerging trends: AI, VR/AR, learning analytics, OER.
Revision Questions
-
What is the difference between substitution and redefinition in the SAMR model?
-
List three specific ICT tools for formative assessment.
-
Explain two strategies to overcome the digital divide in a rural school.
-
How can a teacher use TPACK to plan a science lesson on the water cycle?
-
Name one benefit and one challenge of using AI tutors.
DISCRETE STRUCTURES – Complete Study Notes
PART 1: PROPOSITIONAL LOGIC
1.1 Propositions and Logical Operators
Definition: A proposition (or statement) is a declarative sentence that is either true (T) or false (F) , but not both.
| Example | Proposition? | Truth value |
|---|---|---|
| “The sky is blue.” | Yes | T (typically) |
| “2 + 2 = 5” | Yes | F |
| “What time is it?” | No (question) | — |
| “x + 3 = 7” | No (open sentence — depends on x) | — |
| “This statement is false.” | No (paradox) | — |
Logical operators (connectives):
| Operator | Symbol | Meaning | Truth condition |
|---|---|---|---|
| Negation | ¬p or ~p or p̄ | “not p” | True when p is false |
| Conjunction | p ∧ q | “p and q” | True only when both p and q are true |
| Disjunction | p ∨ q | “p or q” (inclusive) | True when at least one is true |
| Exclusive or (XOR) | p ⊕ q | “p or q but not both” | True when exactly one is true |
| Implication (conditional) | p → q | “if p then q” | False only when p true and q false |
| Biconditional | p ↔ q | “p if and only if q” | True when p and q have same truth value |
1.2 Truth Tables
Truth table for basic operators (p, q ∈ {T, F}):
| p | q | ¬p | p ∧ q | p ∨ q | p ⊕ q | p → q | p ↔ q |
|---|---|---|---|---|---|---|---|
| T | T | F | T | T | F | T | T |
| T | F | F | F | T | T | F | F |
| F | T | T | F | T | T | T | F |
| F | F | T | F | F | F | T | T |
Key points about implication (p → q):
-
Vacuous truth: When p is false, p → q is true regardless of q.
-
Equivalent forms: p → q ≡ ¬p ∨ q
-
Contrapositive: p → q ≡ ¬q → ¬p
-
Converse: q → p (not logically equivalent)
-
Inverse: ¬p → ¬q (not logically equivalent)
Example (vacuous truth): “If 2 + 2 = 5 (false), then I am the Pope (false)” — the statement is true (vacuously) because the antecedent is false, even though the consequent is also false. This seems counterintuitive but is necessary for logical consistency.
1.3 Logical Equivalences
Definition: Two compound propositions are logically equivalent (≡) if they have identical truth values for all possible truth values of their variables.
Important logical equivalences (laws):
| Law | Equivalence |
|---|---|
| Identity | p ∧ T ≡ p, p ∨ F ≡ p |
| Domination | p ∨ T ≡ T, p ∧ F ≡ F |
| Idempotent | p ∨ p ≡ p, p ∧ p ≡ p |
| Double negation | ¬(¬p) ≡ p |
| Commutative | p ∨ q ≡ q ∨ p, p ∧ q ≡ q ∧ p |
| Associative | (p ∨ q) ∨ r ≡ p ∨ (q ∨ r), (p ∧ q) ∧ r ≡ p ∧ (q ∧ r) |
| Distributive | p ∨ (q ∧ r) ≡ (p ∨ q) ∧ (p ∨ r), p ∧ (q ∨ r) ≡ (p ∧ q) ∨ (p ∧ r) |
| De Morgan’s | ¬(p ∧ q) ≡ ¬p ∨ ¬q, ¬(p ∨ q) ≡ ¬p ∧ ¬q |
| Absorption | p ∨ (p ∧ q) ≡ p, p ∧ (p ∨ q) ≡ p |
| Negation (complement) | p ∨ ¬p ≡ T, p ∧ ¬p ≡ F |
| Implication | p → q ≡ ¬p ∨ q |
| Contrapositive | p → q ≡ ¬q → ¬p |
| Biconditional | p ↔ q ≡ (p → q) ∧ (q → p) ≡ (p ∧ q) ∨ (¬p ∧ ¬q) |
Example (De Morgan’s Law application): “It is not true that both the sky is blue and grass is green” is equivalent to “Either the sky is not blue OR grass is not green.”
1.4 Predicate Logic (First-Order Logic)
Definition: Extends propositional logic by introducing predicates (properties of objects), quantifiers, and variables.
| Component | Notation | Meaning |
|---|---|---|
| Predicate | P(x) | “x has property P” (e.g., “x is prime”) |
| Universal quantifier | ∀x P(x) | “For all x, P(x) is true” |
| Existential quantifier | ∃x P(x) | “There exists an x such that P(x) is true” |
| Uniqueness quantifier | ∃!x P(x) | “There exists exactly one x such that P(x) is true” |
Domain (universe of discourse): The set of all possible values for a variable.
Negating quantifiers (De Morgan’s laws for quantifiers):
| Statement | Negation |
|---|---|
| ¬∀x P(x) ≡ ∃x ¬P(x) | “Not all are P” ≡ “Some are not P” |
| ¬∃x P(x) ≡ ∀x ¬P(x) | “There is no P” ≡ “All are not P” |
Example (negation): Let the domain be integers.
∀x (x > 0) → “Every integer is positive” (false)
¬∀x (x > 0) ≡ ∃x ¬(x > 0) ≡ ∃x (x ≤ 0) → “There exists an integer that is non-positive” (true, e.g., x = 0 or x = -1)
Nested quantifiers:
| Statement | Meaning |
|---|---|
| ∀x ∀y P(x,y) | For all x and all y, P holds |
| ∃x ∃y P(x,y) | There exist x and y such that P holds |
| ∀x ∃y P(x,y) | For each x, there exists some y (possibly depending on x) such that P holds |
| ∃x ∀y P(x,y) | There exists an x such that for all y, P holds |
Example (order matters):
∀x ∃y (x + y = 0) is true for integers (for every x, choose y = -x).
∃y ∀x (x + y = 0) is false for integers (there is no single y that works for all x).
PART 2: SET THEORY
2.1 Basic Definitions and Notation
Definition: A set is an unordered collection of distinct objects (elements).
Notation:
-
Roster form: S = {1, 2, 3, 4, 5}
-
Set-builder form: S = {x | x is a positive integer less than 6}
-
Element membership: a ∈ S (“a is an element of S”), a ∉ S
Special sets:
| Set | Notation | Description | |
|---|---|---|---|
| Empty set | ∅ or {} | Set with no elements | |
| Natural numbers | ℕ | {0, 1, 2, 3, …} (definition varies; sometimes starts at 1) | |
| Integers | ℤ | {…, -2, -1, 0, 1, 2, …} | |
| Positive integers | ℤ⁺ or ℕ⁺ | {1, 2, 3, …} | |
| Rational numbers | ℚ | {p/q | p, q ∈ ℤ, q ≠ 0} |
| Real numbers | ℝ | All numbers on the number line | |
| Complex numbers | ℂ | {a + bi | a, b ∈ ℝ} |
2.2 Set Operations
| Operation | Notation | Definition | Venn diagram region | |
|---|---|---|---|---|
| Union | A ∪ B | {x | x ∈ A ∨ x ∈ B} | All of both circles |
| Intersection | A ∩ B | {x | x ∈ A ∧ x ∈ B} | Overlap of circles |
| Difference (relative complement) | A \ B or A – B | {x | x ∈ A ∧ x ∉ B} | A only (not overlap) |
| Complement (absolute) | Aᶜ or Ā | {x ∈ U | x ∉ A} | Everything outside A |
| Symmetric difference | A Δ B | (A \ B) ∪ (B \ A) | Non-overlap regions |
Universal set (U): The set of all possible elements under consideration — context-dependent.
2.3 Set Identities (Analogous to logical equivalences)
| Law | Identity |
|---|---|
| Identity | A ∪ ∅ = A, A ∩ U = A |
| Domination | A ∪ U = U, A ∩ ∅ = ∅ |
| Idempotent | A ∪ A = A, A ∩ A = A |
| Double complement | (Aᶜ)ᶜ = A |
| Commutative | A ∪ B = B ∪ A, A ∩ B = B ∩ A |
| Associative | (A ∪ B) ∪ C = A ∪ (B ∪ C), (A ∩ B) ∩ C = A ∩ (B ∩ C) |
| Distributive | A ∪ (B ∩ C) = (A ∪ B) ∩ (A ∪ C), A ∩ (B ∪ C) = (A ∩ B) ∪ (A ∩ C) |
| De Morgan’s | (A ∪ B)ᶜ = Aᶜ ∩ Bᶜ, (A ∩ B)ᶜ = Aᶜ ∪ Bᶜ |
| Absorption | A ∪ (A ∩ B) = A, A ∩ (A ∪ B) = A |
| Complement | A ∪ Aᶜ = U, A ∩ Aᶜ = ∅ |
2.4 Set Relations (Subset, Superset, Equality)
| Relation | Notation | Definition |
|---|---|---|
| Subset | A ⊆ B | Every element of A is also in B: ∀x (x ∈ A → x ∈ B) |
| Proper subset | A ⊂ B | A ⊆ B and A ≠ B |
| Superset | A ⊇ B | B ⊆ A |
| Equality | A = B | A ⊆ B and B ⊆ A |
Power set: P(A) = {S | S ⊆ A} — the set of all subsets of A.
-
|P(A)| = 2^{|A|} (if A is finite)
Example: A = {1, 2}
P(A) = {∅, {1}, {2}, {1, 2}} (4 = 2² subsets)
Cartesian product: A × B = {(a, b) | a ∈ A ∧ b ∈ B}
-
|A × B| = |A| × |B|
-
A × B ≠ B × A (unless A = B or one is empty)
Example: A = {1, 2}, B = {x, y}
A × B = {(1, x), (1, y), (2, x), (2, y)}
2.5 Cardinality (Size of a Set)
| Type | Definition | Example | ||
|---|---|---|---|---|
| Finite | Set has finite number of elements | {a, b, c} has | S | = 3 |
| Countably infinite | Can be put in one-to-one correspondence with ℕ | ℤ, ℚ are countable | ||
| Uncountable | Cannot be put in one-to-one correspondence with ℕ | ℝ is uncountable (Cantor’s diagonal argument) |
PART 3: FUNCTIONS
3.1 Definition and Terminology
Definition: A function f: A → B is a relation that assigns exactly one element of B (the codomain) to each element of A (the domain).
| Term | Notation | Meaning | |
|---|---|---|---|
| Domain | Dom(f) or A | Set of all inputs | |
| Codomain | Cod(f) or B | Set of all possible outputs | |
| Range (image) | f(A) = {f(a) | a ∈ A} | Set of actual outputs (subset of codomain) |
| Preimage | f⁻¹(b) = {a ∈ A | f(a) = b} | Set of inputs that map to b |
3.2 Properties of Functions
| Property | Definition | Test |
|---|---|---|
| Injective (one-to-one) | f(a₁) = f(a₂) ⇒ a₁ = a₂ | Horizontal line test (actual line test: each y appears at most once) |
| Surjective (onto) | ∀b ∈ B, ∃a ∈ A such that f(a) = b | Range = Codomain |
| Bijective | Both injective and surjective | One-to-one correspondence; invertible |
Examples (f: ℝ → ℝ):
| Function | Injective? | Surjective? | Bijective? |
|---|---|---|---|
| f(x) = 2x + 1 | Yes | Yes | Yes |
| f(x) = x² | No (f(2)=4, f(-2)=4) | No (codomain ℝ, range [0,∞)) | No |
| f(x) = eˣ | Yes (strictly increasing) | No (range (0,∞)) | No |
| f(x) = x³ – x | No (f(0)=0, f(1)=0, f(-1)=0) | Yes (odd degree polynomial) | No |
3.3 Inverse and Composition
Inverse function: If f: A → B is bijective, then f⁻¹: B → A exists, defined by f⁻¹(b) = a where f(a) = b.
Composition: (g ∘ f)(x) = g(f(x)), defined when f: A → B and g: B → C.
Properties of composition:
-
(f ∘ g) ∘ h = f ∘ (g ∘ h) (associative)
-
f ∘ g ≠ g ∘ f generally (not commutative)
-
If f and g are injective, then f ∘ g is injective.
-
If f and g are surjective, then f ∘ g is surjective.
-
If f and g are bijective, then f ∘ g is bijective, and (f ∘ g)⁻¹ = g⁻¹ ∘ f⁻¹.
PART 4: RELATIONS
4.1 Binary Relations
Definition: A binary relation R from set A to set B is a subset of A × B. If (a, b) ∈ R, we write a R b.
Domain of R: dom(R) = {a ∈ A | ∃b ∈ B such that (a, b) ∈ R}
Range of R: ran(R) = {b ∈ B | ∃a ∈ A such that (a, b) ∈ R}
4.2 Relations on a Set (A → A)
Definition: A relation on a set A is a subset of A × A.
| Property | Definition | Example (A = {1,2,3}, R = {(1,1), (1,2), (2,2), (3,3)}) |
|---|---|---|
| Reflexive | ∀a ∈ A, (a, a) ∈ R | Has (1,1), (2,2), (3,3) → reflexive |
| Symmetric | ∀a,b ∈ A, if (a,b) ∈ R then (b,a) ∈ R | (1,2) in R but (2,1) not in R → NOT symmetric |
| Antisymmetric | ∀a,b ∈ A, if (a,b) ∈ R and (b,a) ∈ R then a = b | Holds vacuously because no (b,a) pairs for distinct a,b |
| Transitive | ∀a,b,c ∈ A, if (a,b) ∈ R and (b,c) ∈ R then (a,c) ∈ R | (1,2) and (2,2) → (1,2) ∈ R ✓; (1,1) and (1,2) → (1,2) ∈ R ✓ |
4.3 Equivalence Relations
Definition: A relation R on A is an equivalence relation if it is:
-
Reflexive
-
Symmetric
-
Transitive
Equivalence classes: For each a ∈ A, [a] = {x ∈ A | x R a} is the equivalence class of a.
-
Partition of A into disjoint equivalence classes.
Example: Let A = ℤ, define a R b if a ≡ b (mod 3) (i.e., a – b divisible by 3).
Reflexive: a – a = 0 divisible by 3.
Symmetric: if a – b divisible by 3, then b – a divisible by 3.
Transitive: if a – b and b – c divisible by 3, then a – c divisible by 3.
Equivalence classes: [0] = {…, -3, 0, 3, 6, …}, [1] = {…, -2, 1, 4, 7, …}, [2] = {…, -1, 2, 5, 8, …}. Partition of ℤ into 3 classes.
4.4 Partial Orders
Definition: A relation R on A is a partial order if it is:
-
Reflexive
-
Antisymmetric
-
Transitive
Notation: Often ≤ is used for partial orders.
Hasse diagram: Graphical representation of a partial order, omitting reflexive and transitive edges.
Comparability: a and b are comparable if a ≤ b or b ≤ a.
Total order (chain): A partial order where every pair of elements is comparable.
Example: (ℤ⁺, |) where a | b means “a divides b”.
Reflexive: a | a.
Antisymmetric: if a | b and b | a, then a = b (for positive integers).
Transitive: if a | b and b | c, then a | c.
Not a total order because 2 and 3 are not comparable (2 ∤ 3, 3 ∤ 2).
Maximal, minimal, greatest, least elements:
| Term | Definition |
|---|---|
| Maximal | No element greater than a (i.e., ∄x such that a < x) |
| Minimal | No element smaller than a |
| Greatest (maximum) | All elements ≤ a |
| Least (minimum) | All elements ≥ a |
PART 5: COMBINATORICS
5.1 Basic Counting Principles
Sum rule: If a task can be done in m ways OR in n ways (with no overlap), total = m + n.
Product rule: If a task requires doing subtask 1 in m ways AND subtask 2 in n ways, total = m × n.
Example (product rule): How many 2-digit numbers are there? First digit: 1-9 (9 ways), second digit: 0-9 (10 ways). Total = 9 × 10 = 90.
Inclusion-Exclusion Principle (for two sets): |A ∪ B| = |A| + |B| – |A ∩ B|
Generalized (for three sets):
|A ∪ B ∪ C| = |A| + |B| + |C| – |A∩B| – |A∩C| – |B∩C| + |A∩B∩C|
5.2 Permutations (Order matters)
| Scenario | Formula | Example |
|---|---|---|
| Permutations of n distinct objects | n! = n × (n-1) × … × 1 | 5! = 120 ways to arrange 5 books |
| Permutations of n taken r at a time | P(n,r) = n! / (n-r)! | 10 runners, how many ways for gold/silver/bronze? P(10,3) = 10×9×8 = 720 |
| Permutations with repetition | nʳ | 10-digit PIN: 10¹⁰ possibilities |
| Permutations with indistinguishable objects | n! / (n₁! n₂! … n_k!) | “MISSISSIPPI”: 11 letters, 4 I, 4 S, 2 P = 11!/(4!4!2!) |
5.3 Combinations (Order does NOT matter)
| Scenario | Formula | Example |
|---|---|---|
| Combinations of n taken r at a time | C(n,r) = n! / (r!(n-r)!) = (n choose r) | 52 cards, choose 5 for poker hand: C(52,5) = 2,598,960 |
Properties of C(n,r):
| Property | Formula |
|---|---|
| Symmetry | C(n,r) = C(n, n-r) |
| Pascal’s identity | C(n+1, r) = C(n, r-1) + C(n, r) |
| Sum of row | Σ_{r=0}ⁿ C(n,r) = 2ⁿ |
| Binomial theorem | (x + y)ⁿ = Σ_{r=0}ⁿ C(n,r) xⁿ⁻ʳ yʳ |
5.4 Binomial Coefficients and Pascal’s Triangle
Pascal’s Triangle (rows 0-5):
Row 0: 1 Row 1: 1 1 Row 2: 1 2 1 Row 3: 1 3 3 1 Row 4: 1 4 6 4 1 Row 5: 1 5 10 10 5 1
Each entry = sum of two above: C(n,r) = C(n-1, r-1) + C(n-1, r)
5.5 Pigeonhole Principle
Simple form: If n items are placed into m boxes and n > m, then at least one box contains at least 2 items.
Generalized form: If n items are placed into m boxes, then at least one box contains at least ⌈n/m⌉ items.
Example: Among any 13 people, at least 2 were born in the same month (12 months, 13 people → ⌈13/12⌉ = 2).
Example (more advanced): Show that any set of 10 integers from {1,…,100} contains two subsets with equal sum. There are 2¹⁰ – 1 = 1023 non-empty subsets, but possible sums range from 1 to 100+99+…+91 = 955. Pigeonhole: 1023 subsets → at least two with same sum.
PART 6: GRAPH THEORY
6.1 Basic Definitions
Definition: A graph G = (V, E) consists of:
-
V: set of vertices (nodes)
-
E: set of edges (pairs of vertices)
Types of graphs:
| Type | Edge representation | Parallel edges? | Loops? |
|---|---|---|---|
| Simple graph | unordered pairs (undirected) | No | No |
| Multigraph | unordered pairs | Yes | No |
| Pseudograph | unordered pairs | Yes | Yes |
| Directed graph (digraph) | ordered pairs (u → v) | Yes (if allowed) | Yes (if allowed) |
6.2 Graph Terminology
| Term | Definition | ||
|---|---|---|---|
| Adjacent vertices | Connected by an edge | ||
| Incident edge | Edge that touches a vertex | ||
| Degree of vertex (deg(v)) | Number of edges incident to v (loops count twice) | ||
| Indegree (digraph) | Number of incoming edges | ||
| Outdegree (digraph) | Number of outgoing edges | ||
| Path | Sequence of vertices where consecutive vertices are adjacent; no repeated vertices | ||
| Trail | Sequence of vertices where edges may repeat, but usually defined without vertex restriction | ||
| Circuit (cycle) | Path that starts and ends at same vertex with length ≥ 3 | ||
| Complete graph Kₙ | All pairs of distinct vertices connected; | E | = n(n-1)/2 |
| Cycle graph Cₙ | n vertices in a cycle; deg(v) = 2 for all v | ||
| Wheel graph Wₙ | Cₙ with one extra vertex connected to all cycle vertices | ||
| Bipartite graph | Vertices can be partitioned into two sets with edges only between sets (no edges within a set) | ||
| Complete bipartite K_{m,n} | All possible edges between sets of sizes m and n |
Handshaking theorem: Σ_{v∈V} deg(v) = 2|E|
-
Corollary: The number of vertices of odd degree is even.
6.3 Graph Isomorphism
Definition: Two graphs G₁ = (V₁, E₁) and G₂ = (V₂, E₂) are isomorphic if there exists a bijection f: V₁ → V₂ such that {u,v} ∈ E₁ iff {f(u), f(v)} ∈ E₂. (Edge-preserving bijection).
Invariants for non-isomorphism (properties preserved under isomorphism):
-
Number of vertices
-
Number of edges
-
Degree sequence (sorted list of degrees)
-
Number of cycles of each length
-
Connectivity properties
Example: Are G₁ (square with diagonal) and G₂ (K₄ minus one edge) isomorphic? G₁ has a vertex of degree 2 and two vertices of degree 3; G₂ has two vertices of degree 2 and two of degree 3. Wait, check carefully — best to test by exhaustive mapping.
6.4 Eulerian and Hamiltonian Paths
| Concept | Definition | Condition (theorem) |
|---|---|---|
| Eulerian circuit | Circuit that uses every edge exactly once | Connected graph + all vertices even degree |
| Eulerian trail (path) | Path that uses every edge exactly once (not necessarily closed) | Connected graph + exactly 0 or 2 vertices of odd degree |
| Hamiltonian circuit | Circuit that visits every vertex exactly once | No simple necessary & sufficient condition (NP-complete problem) |
| Hamiltonian path | Path that visits every vertex exactly once | No simple condition |
Example (Bridges of Königsberg): Four land masses, seven bridges. Graph has 4 vertices with degrees 3,3,3,5 (all odd). No Eulerian circuit or trail (impossible to cross each bridge exactly once).
6.5 Planar Graphs
Definition: A graph is planar if it can be drawn in the plane without edge crossings.
Euler’s formula for connected planar graphs: V – E + F = 2, where F = number of faces (including the unbounded outer face).
Corollaries:
-
For planar graphs with V ≥ 3: E ≤ 3V – 6
-
For bipartite planar graphs: E ≤ 2V – 4
Non-planar graphs: K₅ (complete graph on 5 vertices) and K₃,₃ (complete bipartite 3×3) are non-planar (Kuratowski’s theorem: a graph is planar iff it contains no subdivision of K₅ or K₃,₃).
6.6 Graph Coloring
Definition: A k-coloring of a graph assigns one of k colors to each vertex such that no two adjacent vertices share the same color.
Chromatic number χ(G): Minimum number of colors needed to color G.
Famous theorem (Four Color Theorem): Every planar graph is 4-colorable (χ(G) ≤ 4).
| Graph | χ(G) | Notes |
|---|---|---|
| Bipartite graph | 2 | Also converse: χ(G)=2 iff G is bipartite (no odd cycles) |
| Complete graph Kₙ | n | All vertices adjacent |
| Cycle Cₙ | 2 if n even, 3 if n odd | Odd cycles require 3 colors |
| Wheel graph Wₙ | 4 if n odd, 3 if n even (for n≥4) | — |
PART 7: TREES
7.1 Definition and Properties
Definition: A tree is a connected acyclic undirected graph.
Properties of trees:
| Property | Formula/Statement | ||||
|---|---|---|---|---|---|
| Edges | E | = | V | – 1 | |
| Unique path | Between any two vertices, exactly one simple path | ||||
| Leaves | Every tree with at least 2 vertices has at least 2 leaves | ||||
| Adding any edge | Creates exactly one cycle | ||||
| Removing any edge | Disconnects the graph |
7.2 Rooted Trees
Definition: A rooted tree is a tree with one vertex designated as the root.
Terminology:
| Term | Definition |
|---|---|
| Parent | The vertex directly above given vertex (toward root) |
| Child | A vertex directly below given vertex |
| Siblings | Vertices with same parent |
| Ancestor | Parent, parent’s parent, etc. |
| Descendant | Child, child’s child, etc. |
| Leaf (external node) | Vertex with no children |
| Internal node | Vertex with at least one child |
| Level (depth) | Number of edges from root |
| Height | Maximum depth of any node |
Binary tree: Each node has at most 2 children (left and right).
Full binary tree: Each node has 0 or 2 children.
Complete binary tree: All levels filled except possibly last, which is filled left to right.
7.3 Tree Traversals
| Traversal | Order of visiting nodes (binary tree) | Example (root, left, right) |
|---|---|---|
| Preorder | Visit root, traverse left subtree, traverse right subtree | Root → Left → Right |
| Inorder | Traverse left subtree, visit root, traverse right subtree | Left → Root → Right |
| Postorder | Traverse left subtree, traverse right subtree, visit root | Left → Right → Root |
| Level-order (BFS) | Visit nodes level by level (top to bottom, left to right) | Root, then all depth 1, etc. |
7.4 Spanning Trees
Definition: A spanning tree of a connected graph G is a subgraph that is a tree and includes all vertices of G.
Minimum spanning tree (MST): Spanning tree with minimum total edge weight (for weighted graphs).
Algorithms to find MST:
| Algorithm | Strategy | Complexity (with efficient data structures) |
|---|---|---|
| Kruskal’s | Sort edges by weight, add smallest edge that doesn’t form a cycle | O(E log E) or O(E log V) |
| Prim’s | Grow tree from starting vertex, always add shortest edge connecting tree to new vertex | O(E log V) with binary heap |
PART 8: NUMBER THEORY (BASICS)
8.1 Divisibility and Modular Arithmetic
Definition: a | b (a divides b) if ∃ integer k such that b = a·k.
Division algorithm: For integers a and positive integer d, there exist unique integers q (quotient) and r (remainder) such that:
a = d·q + r, where 0 ≤ r < d.
Modular arithmetic: a ≡ b (mod m) iff m | (a – b).
8.2 Greatest Common Divisor (GCD)
Definition: gcd(a, b) = largest positive integer d such that d | a and d | b.
Euclidean algorithm:
-
Let a₁ = max(a,b), b₁ = min(a,b)
-
Compute a₁ = b₁·q + r (0 ≤ r < b₁)
-
If r = 0, gcd = b₁
-
Else set new a₂ = b₁, b₂ = r, repeat
Example: Find gcd(252, 105)
252 = 105·2 + 42
105 = 42·2 + 21
42 = 21·2 + 0
gcd = 21
Extended Euclidean algorithm: Finds integers x, y such that ax + by = gcd(a, b).
8.3 Prime Numbers
Definition: p > 1 is prime if its only positive divisors are 1 and p.
Fundamental theorem of arithmetic: Every integer greater than 1 can be uniquely expressed as a product of primes (up to order).
Infinitude of primes (Euclid’s proof): Assume finite list p₁,…,pₙ. Consider N = p₁·p₂·…·pₙ + 1. N is either prime (not in list) or divisible by a prime not in list. Contradiction. Therefore infinite primes.
8.4 Modular Inverses and Cryptography (RSA motivation)
Definition: a has an inverse modulo m if ∃ a⁻¹ such that a·a⁻¹ ≡ 1 (mod m). Exists iff gcd(a, m) = 1.
Fermat’s little theorem: If p is prime and a is not divisible by p, then a^{p-1} ≡ 1 (mod p).
PART 9: PROOF TECHNIQUES
9.1 Direct Proof
Structure: Assume P is true. Use logical steps to deduce Q is true. (P → Q)
Example: Prove: If n is even, then n² is even.
Proof: If n is even, then n = 2k for some integer k. Then n² = (2k)² = 4k² = 2(2k²), which is even. ∎
9.2 Proof by Contraposition
Structure: Prove ¬Q → ¬P instead of P → Q (logically equivalent).
Example: Prove: If n² is odd, then n is odd.
Proof by contraposition: Assume n is even (¬Q). Then n = 2k, n² = 4k² = 2(2k²), which is even (¬P). Therefore if n² is odd, n cannot be even, so n is odd. ∎
9.3 Proof by Contradiction
Structure: Assume P ∧ ¬Q. Derive a contradiction (R ∧ ¬R). Therefore P → Q is true.
Example: Prove √2 is irrational.
Proof: Assume √2 is rational. Then √2 = a/b in lowest terms. Squaring: 2 = a²/b² → a² = 2b². Thus a² is even → a is even (a = 2k). Then (2k)² = 2b² → 4k² = 2b² → 2k² = b² → b² even → b even. But then a and b both even, contradicting “in lowest terms.” Therefore √2 is irrational
Object Oriented Programming (Core) – Complete Study Notes
Course Overview
Object Oriented Programming (OOP) is a programming paradigm that organizes software design around objects rather than functions and logic. An object is a self-contained entity that contains both data (attributes/properties) and methods (functions/procedures) that operate on that data. OOP aims to increase flexibility, maintainability, and reusability in software development.
Core Languages: Java, C++, Python, C#, JavaScript, PHP
Prerequisites: Basic programming concepts (variables, loops, conditionals, functions), familiarity with at least one programming language.
PART 1: FUNDAMENTAL CONCEPTS
1.1 What is Object Oriented Programming?
Definition: OOP is a programming methodology based on the concept of “objects” that contain data (fields/attributes) and code (methods/procedures) that manipulate that data. Objects are instances of classes, which act as blueprints or templates.
Procedural vs. Object Oriented Programming:
| Aspect | Procedural Programming | Object Oriented Programming |
|---|---|---|
| Organization | Functions and data are separate | Data and methods are bundled together (encapsulation) |
| Data access | Data is freely passed between functions | Data is hidden from outside (information hiding) |
| Code reuse | Limited (through functions only) | High (inheritance, composition) |
| Modularity | Functions and global variables exist independently | Classes are self-contained modules |
| Real-world mapping | Does not map well | Maps directly to real-world entities (objects) |
| Examples | C, Pascal, FORTRAN, COBOL | Java, C++, Python, C#, JavaScript, Ruby |
1.2 The Four Pillars of OOP
| Pillar | Definition | Benefit |
|---|---|---|
| Encapsulation | Bundling data and methods together, and hiding internal state from external access | Security, prevents accidental modification, modularity, reduced complexity |
| Inheritance | Creating new classes (derived/child classes) from existing classes (base/parent classes), inheriting properties and behavior | Code reuse, hierarchical classification, extensibility |
| Polymorphism | The ability of objects of different classes to respond to the same method call in their own way (many forms) | Flexibility, extensibility, clean code (open/closed principle) |
| Abstraction | Hiding complex implementation details and exposing only essential features to the user | Simplicity, reduces complexity, focuses on “what” not “how” (interface vs. implementation) |
Mnemonic: “A PIE” (Abstraction, Polymorphism, Inheritance, Encapsulation) – but standard order often presented as: Encapsulation, Inheritance, Polymorphism, Abstraction . Any order is acceptable if you understand each concept.
PART 2: CLASSES AND OBJECTS
2.1 Class Definition
Definition: A class is a blueprint or template for creating objects. It defines the structure (data members) and behavior (member functions/methods) that objects of that class will have.
Analogy:
-
Class = Cookie cutter (blueprint)
-
Object = Cookie (instance created from the cutter)
2.2 Syntax Examples (Multiple Languages)
Java Example:
public class Car { // Data members (attributes/fields) - Encapsulation through private access private String brand; private String model; private int year; // Constructor (called when object is created) public Car(String brand, String model, int year) { this.brand = brand; this.model = model; this.year = year; } // Method (behavior) public void startEngine() { System.out.println(brand + " " + model + " engine started."); } // Getter (accessor) public String getBrand() { return brand; } // Setter (mutator) public void setBrand(String brand) { this.brand = brand; } } // Creating an object (instance of Car class) Car myCar = new Car("Toyota", "Camry", 2023); myCar.startEngine(); // Output: Toyota Camry engine started.
C++ Example:
class Car { private: string brand; string model; int year; public: // Constructor Car(string brand, string model, int year) { this->brand = brand; this->model = model; this->year = year; } void startEngine() { cout << brand << " " << model << " engine started." << endl; } }; Car myCar("Honda", "Civic", 2022); myCar.startEngine();
Python Example:
class Car: def __init__(self, brand, model, year): # Constructor self.brand = brand # Public attribute (by convention) self.model = model self.__year = year # Name mangling for private attribute (not truly private) def start_engine(self): # Method print(f"{self.brand} {self.model} engine started.") # Getter (property) @property def year(self): return self.__year # Setter @year.setter def year(self, value): if value > 1885: # First car invented ~1886 self.__year = value my_car = Car("Tesla", "Model 3", 2023) my_car.start_engine()
2.3 Object Lifecycle
| Stage | Description | Actions |
|---|---|---|
| Declaration | Reference variable created | Car myCar; (Java/C++) or my_car = None (Python) – no object yet |
| Instantiation | Memory allocated for object | new Car(...) (Java/C++), no explicit keyword in Python (Car(...)) |
| Initialization | Constructor called to set initial state | Car(...) constructor executes |
| Usage | Methods called, attributes accessed/modified | myCar.drive(), myCar.speed = 60 |
| Destruction | Object destroyed (garbage collection or explicit delete) | delete myCar (C++), automatic (Java/Python GC) |
2.4 Constructor Types
| Constructor Type | Description | Example (Java) |
|---|---|---|
| Default constructor | No parameters; provided automatically if no constructor defined | Car() { } |
| Parameterized constructor | Takes parameters to initialize object with specific values | Car(String brand, String model) { ... } |
| Copy constructor | Creates a new object as copy of existing object | Car(Car other) { this.brand = other.brand; ... } |
| Constructor overloading | Multiple constructors with different parameter lists | Car(), Car(String brand), Car(String brand, String model) |
Constructor Chaining (Calling one constructor from another):
-
Java:
this(...)must be first statement -
C++: Initializer list
: Car(brand, model); or delegating constructors (C++11) -
Python:
__init__cannot directly call another__init__; use class methods or composition -
C#:
this(...)similar to Java
2.5 Destructors and Garbage Collection
| Language | Destructor/Finalizer | Garbage Collection |
|---|---|---|
| Java | finalize() (deprecated; not guaranteed) |
Automatic (GC) – cannot force immediate collection |
| C++ | ~ClassName() (destructor) |
Manual (delete) or smart pointers (RAII) |
| Python | __del__() (not guaranteed; called when reference count reaches zero) |
Automatic (reference counting + cycle detection) |
| C# | ~ClassName() (finalizer) |
Automatic (GC) |
Rule of Three (C++): If a class defines a destructor, copy constructor, or copy assignment operator, it should define all three (or explicitly delete them). This ensures proper resource management (especially for dynamic memory, file handles, network sockets). (Updated to Rule of Five in C++11: move constructor and move assignment added.)
PART 3: ENCAPSULATION (DATA HIDING)
3.1 Access Modifiers (Access Specifiers)
| Modifier | Class | Package | Subclass (inheritance) | World (any class) |
|---|---|---|---|---|
| private | Yes | No | No | No |
| default (package-private) | Yes | Yes | No | No |
| protected | Yes | Yes | Yes | No |
| public | Yes | Yes | Yes | Yes |
3.2 Language-Specific Access Modifiers
| Language | Keywords | Notes |
|---|---|---|
| Java | private, default (no keyword), protected, public |
Default = package-private (no keyword) |
| C++ | private:, protected:, public: (within class) |
Can be applied to individual members or sections. Also friend functions/classes bypass access. |
| Python | Conventions only (no strict enforcement) | _single_underscore = “protected” (convention); __double_underscore = name mangling (hides from outside; _ClassName__attribute still accessible). No true private. |
| C# | private, internal, protected, protected internal, public |
internal = assembly (project) only; protected internal = subclass OR assembly |
3.3 Getters and Setters (Accessors and Mutators)
Purpose: Control access to private data members; validate input before modification; maintain invariants.
Java Example:
public class BankAccount { private double balance; // Getter (accessor) public double getBalance() { return balance; } // Setter (mutator) with validation public void setBalance(double balance) { if (balance >= 0) { this.balance = balance; } else { throw new IllegalArgumentException("Balance cannot be negative."); } } // Alternative: Provide behavior instead of getter/setter public void deposit(double amount) { if (amount > 0) { this.balance += amount; } } }
When to use getters/setters:
-
Use getter/setter when you need validation, logging, or change notification (JavaBeans convention)
-
Avoid getter/setter for trivial fields if internal representation is unlikely to change (direct field access can be allowed within the same class) – Some OOP purists argue getters/setters break encapsulation anyway because they expose internal data structure. Use behavior methods instead.
Rule of thumb: Expose behavior, not data. Ask “what does the object DO?” not “what data does it HOLD?”
3.4 Information Hiding Benefits
| Benefit | Explanation |
|---|---|
| Security | Prevents unauthorized or accidental modification of internal state |
| Reduced coupling | Changes to internal implementation do not affect external code |
| Maintainability | Bugs isolated to the class; can change implementation without breaking dependents |
| Validation | Centralized validation through setters (one place to enforce invariants) |
| Flexibility | Future changes (replacing internal data structure, adding caching) require no changes to client code |
PART 4: INHERITANCE
4.1 Definition and Terminology
Inheritance: A mechanism where a new class (derived/child/subclass) is created from an existing class (base/parent/superclass), inheriting its attributes and methods.
Terminology:
-
Base class (parent class, superclass): The class being inherited from
-
Derived class (child class, subclass): The new class that inherits from the base class
-
“IS-A” relationship: Inheritance should model “is-a” (a Dog is an Animal; a Car is a Vehicle)
-
“HAS-A” relationship: Composition – a Car has an Engine (not inheritance)
4.2 Syntax Examples
Java:
// Base class (Parent) public class Animal { protected String name; public Animal(String name) { this.name = name; } public void eat() { System.out.println(name + " is eating."); } public void sleep() { System.out.println(name + " is sleeping."); } } // Derived class (Child) public class Dog extends Animal { private String breed; public Dog(String name, String breed) { super(name); // Call parent constructor (must be first statement) this.breed = breed; } // Override parent method (polymorphism) @Override public void eat() { System.out.println(name + " the dog is eating kibble."); } // New method specific to Dog public void bark() { System.out.println(name + " says Woof!"); } } // Usage Dog myDog = new Dog("Rex", "German Shepherd"); myDog.eat(); // Rex the dog is eating kibble. (Overridden) myDog.sleep(); // Rex is sleeping. (Inherited) myDog.bark(); // Rex says Woof! (Specific to Dog)
C++:
class Animal { protected: string name; public: Animal(string name) : name(name) {} virtual void eat() { cout << name << " is eating." << endl; } void sleep() { cout << name << " is sleeping." << endl; } virtual ~Animal() {} // Virtual destructor for proper cleanup }; class Dog : public Animal { string breed; public: Dog(string name, string breed) : Animal(name), breed(breed) {} void eat() override { cout << name << " the dog is eating kibble." << endl; } void bark() { cout << name << " says Woof!" << endl; } };
Python:
class Animal: def __init__(self, name): self.name = name def eat(self): print(f"{self.name} is eating.") def sleep(self): print(f"{self.name} is sleeping.") class Dog(Animal): def __init__(self, name, breed): super().__init__(name) # Call parent constructor self.breed = breed def eat(self): # Override print(f"{self.name} the dog is eating kibble.") def bark(self): print(f"{self.name} says Woof!")
4.3 Types of Inheritance
| Type | Description | Diagram | Example |
|---|---|---|---|
| Single inheritance | One base class, one derived class | Parent ← Child |
Java, C# (classes) – single inheritance only for classes |
| Multilevel inheritance | Chain of inheritance: Grandparent → Parent → Child | A ← B ← C |
Animal ← Mammal ← Dog |
| Hierarchical inheritance | Multiple derived classes from single base class | A → B, A → C, A → D |
Shape → Circle, Shape → Rectangle, Shape → Triangle |
| Multiple inheritance | Derived class inherits from multiple base classes | A B \ / C |
C++ (class Derived : public Base1, public Base2); Java/C# allow multiple inheritance of interfaces only |
| Hybrid (Diamond) inheritance | Combination of multiple and multilevel | A / \ B C \ / D |
Can cause diamond problem (ambiguity for members inherited from A via two paths) – resolved by virtual inheritance in C++ |
4.4 Diamond Problem (Multiple Inheritance Ambiguity)
Problem: When a class inherits from two classes that both inherit from the same base class, ambiguity arises about which ancestor members are inherited.
Animal
/ \
Mammal Bird
\ /
Bat (which eat() method? from Mammal or from Bird?)
Solutions:
| Language | Solution |
|---|---|
| C++ | Virtual inheritance: class Mammal : virtual public Animal; virtual base class ensures only one copy of Animal members |
| Java, C# | No multiple inheritance for classes (prevents diamond problem). Multiple inheritance of interfaces (which contain no implementation) is allowed. |
| Python | Method Resolution Order (MRO) – C3 linearization algorithm determines which parent class method is used (left to right, depth-first). |
4.5 Super/Parent Class Access
| Language | Keyword | Usage |
|---|---|---|
| Java | super |
super.method() – call parent method; super() – call parent constructor (must be first statement) |
| C++ | BaseClassName:: |
Animal::eat(); use scope resolution operator |
| Python | super() |
super().method(); also super().__init__() for constructor |
| C# | base |
base.method(); base() for constructor |
PART 5: POLYMORPHISM
5.1 Definition and Types
Polymorphism (Greek: “many forms”): The ability of objects of different classes to respond to the same method call in their own way.
| Type | Compile-time (Static) | Runtime (Dynamic) | Mechanism |
|---|---|---|---|
| Compile-time polymorphism | Yes | No | Method overloading, operator overloading |
| Runtime polymorphism | No | Yes | Method overriding (virtual functions), interfaces |
5.2 Method Overloading (Compile-time)
Definition: Multiple methods in the same class with the same name but different parameter lists (different number, type, or order of parameters). Compiler decides which method to call based on arguments at compile time.
Rules:
-
Must differ in parameter list (number, type, or order of parameters)
-
Return type alone is NOT sufficient to distinguish overloaded methods
-
Can have different access modifiers
-
Can throw different exceptions
Java Example:
public class Calculator { // Overloaded methods with same name "add" public int add(int a, int b) { return a + b; } public int add(int a, int b, int c) { return a + b + c; } public double add(double a, double b) { return a + b; } public String add(String a, String b) { return a + b; // String concatenation } } // Usage: Calculator calc = new Calculator(); calc.add(5, 10); // Calls first method (return 15) calc.add(5, 10, 15); // Calls second method (return 30) calc.add(5.5, 2.2); // Calls third method (return 7.7) calc.add("Hello", "World"); // Calls fourth method (returns "HelloWorld")
C++ Operator Overloading (form of compile-time polymorphism):
class Complex { double real, imag; public: Complex operator+(const Complex& other) { Complex result; result.real = this->real + other.real; result.imag = this->imag + other.imag; return result; } }; Complex c1, c2, c3; c3 = c1 + c2; // Calls overloaded operator+
5.3 Method Overriding (Runtime Polymorphism)
Definition: A derived class provides its own implementation of a method already defined in its base class. The method to be executed is determined at runtime based on the actual object type, not the reference variable type.
Rules for Overriding:
-
Method signature (name + parameters) must be the same
-
Return type must be same or covariant (subclass of original return type)
-
Access level cannot be more restrictive than overridden method
-
Cannot override
private,static, orfinalmethods (Java) -
Use
@Overrideannotation (Java) oroverridespecifier (C++11) to avoid mistakes
Java Example:
class Animal { public void sound() { System.out.println("Animal makes a sound."); } } class Cat extends Animal { @Override public void sound() { System.out.println("Cat meows."); } } class Cow extends Animal { @Override public void sound() { System.out.println("Cow moos."); } } // Runtime polymorphism demonstration: Animal myAnimal; myAnimal = new Animal(); myAnimal.sound(); // "Animal makes a sound." myAnimal = new Cat(); myAnimal.sound(); // "Cat meows." (Cat's sound() called at runtime) myAnimal = new Cow(); myAnimal.sound(); // "Cow moos." (Cow's sound() called at runtime)
C++ Example with virtual:
class Animal { public: virtual void sound() { // virtual enables runtime polymorphism cout << "Animal makes a sound." << endl; } virtual ~Animal() {} // virtual destructor for proper cleanup of derived objects }; class Cat : public Animal { public: void sound() override { // override specifier (C++11) optional but recommended cout << "Cat meows." << endl; } }; // Usage: Animal* ptr = new Cat(); ptr->sound(); // Cat meows. (polymorphic call, dynamic dispatch) delete ptr;
5.4 Virtual Functions (C++ specific)
| Specifier | Effect |
|---|---|
virtual |
Member function can be overridden in derived class; enables dynamic dispatch (runtime binding) |
override (C++11) |
Indicates function overrides a virtual function in base class; compiler checks |
final (C++11) |
Prevents further overriding in derived classes |
Pure virtual (=0) |
Makes class abstract (cannot be instantiated) |
Virtual Table (vtable): Compiler creates table of virtual function addresses for each class. Each object has a hidden pointer (vptr) to its class’s vtable. When virtual function is called, the correct function is looked up in vtable. This causes a small runtime overhead (one extra dereference per virtual call). This is why virtual functions are not used for lightweight “Plain Old Data” (POD) types unless necessary.
5.5 Abstract Classes and Interfaces
| Concept | Definition | Can be instantiated? | Can have method bodies? | Supports multiple inheritance? |
|---|---|---|---|---|
| Abstract class | Class that cannot be instantiated; may contain abstract methods (no body) | No | Yes (concrete methods allowed) | No (single inheritance) |
| Interface | Contract that specifies what a class can do (method signatures only, historically) | No | Default/static methods allowed in recent Java/C# | Yes (multiple interfaces) |
Java Abstract Class Example:
abstract class Shape { protected String color; public Shape(String color) { this.color = color; } // Abstract method (no body) public abstract double area(); // Concrete method (with body) public void displayColor() { System.out.println("Color: " + color); } } class Circle extends Shape { private double radius; public Circle(String color, double radius) { super(color); this.radius = radius; } @Override public double area() { return Math.PI * radius * radius; } }
Java Interface Example:
interface Drawable { void draw(); // abstract method (implicitly public abstract) // Default method (Java 8+) – has body; allows interface evolution default void print() { System.out.println("Printing..."); } // Static method (Java 8+) static void display() { System.out.println("Display interface"); } } interface Resizable { void resize(double factor); } // Class implementing multiple interfaces: class Rectangle implements Drawable, Resizable { private double width, height; public void draw() { System.out.println("Drawing rectangle."); } public void resize(double factor) { width *= factor; height *= factor; } }
Comparison Table:
| Feature | Abstract Class | Interface (modern, Java 8+) |
|---|---|---|
| Inheritance | Single (class can extend only one abstract class) | Multiple (class can implement many interfaces) |
| State (fields) | Can have instance variables (state) | Cannot have instance variables (except static final constants) |
| Constructors | Yes | No |
| Method implementations | Can have fully implemented methods, abstract methods, final methods | Can have abstract, default, static methods |
| Access modifiers | All allowed | Methods are implicitly public (except private methods in Java 9+) |
| When to use | “IS-A” relationship with shared code | “CAN-DO” relationship (capability); unrelated classes sharing behavior; multiple inheritance of type |
PART 6: ABSTRACTION
6.1 Definition and Importance
Abstraction is the concept of hiding complex implementation details and exposing only the essential features of an object. It focuses on what an object does rather than how it does it.
Real-world analogy: You drive a car using the steering wheel, pedals, and gear shift (interface). You do not need to understand how the engine, transmission, or fuel injection system works (implementation). This is abstraction.
6.2 Ways to Achieve Abstraction in OOP
| Mechanism | Description | Example |
|---|---|---|
| Abstract classes | Classes that cannot be instantiated; define abstract methods | Shape class with area() abstract method |
| Interfaces | Contracts specifying method signatures | Drawable interface with draw() method |
| Encapsulation | Hiding data and exposing only public methods | BankAccount with deposit(), withdraw() methods |
| Method overloading | Same method name, different parameters | print(int), print(String) |
| Private methods | Internal helper methods hidden from outside | validateInput() method used only within class |
6.3 Abstraction vs. Encapsulation
| Aspect | Abstraction | Encapsulation |
|---|---|---|
| Focus | What an object does (interface) | How an object does it (implementation) |
| Purpose | Reduce complexity; hide implementation details | Protect data integrity; hide data structure |
| Technique | Abstract classes, interfaces, public methods, public API | Private fields, getters/setters, private methods, internal state |
| Level | Design level (high-level architecture) | Implementation level (code-level) |
| Example | Vehicle interface with start(), stop() methods |
engine field private; start() method handles starting logic internally |
Relationship: Abstraction is achieved through encapsulation. You hide the implementation (encapsulation) so you can present a simplified interface (abstraction).
PART 7: ADVANCED OOP CONCEPTS
7.1 Static Members (Class Members)
Definition: Members (variables or methods) that belong to the class itself, not to individual objects. There is only one copy of a static variable shared by all objects of the class.
| Member Type | Belongs to | Accessed via | Memory allocation | Initialization |
|---|---|---|---|---|
| Instance (non-static) | Each object | Object reference (obj.member) |
Per object | Per object (in constructor) |
| Static (class) | The class | Class name (ClassName.member) or object reference (bad practice) |
Once (shared) | Once (static initializer or when class loaded) |
Java Example:
public class Counter { // Static variable (shared across all instances) private static int totalCount = 0; // Instance variable private int instanceCount; public Counter() { totalCount++; this.instanceCount = totalCount; } // Static method (can only access static members directly) public static int getTotalCount() { return totalCount; } // Instance method (can access both static and instance members) public int getInstanceCount() { return instanceCount; } } // Usage: Counter c1 = new Counter(); // totalCount = 1 Counter c2 = new Counter(); // totalCount = 2 Counter c3 = new Counter(); // totalCount = 3 System.out.println(Counter.getTotalCount()); // 3 (static method called via class) System.out.println(c1.getInstanceCount()); // 1 (instance method) System.out.println(c2.getInstanceCount()); // 2 System.out.println(c3.getInstanceCount()); // 3
C++ Static Members:
class Counter { private: static int totalCount; // Declaration only (within class) int instanceCount; public: Counter() { totalCount++; instanceCount = totalCount; } static int getTotalCount() { return totalCount; } int getInstanceCount() const { return instanceCount; } }; // Definition and initialization outside class (required before C++17) int Counter::totalCount = 0;
7.2 Constants and Immutability
| Language | Constant Declaration | Immutable Class |
|---|---|---|
| Java | final keyword |
All fields final; no setters; class final (no subclassing) to preserve immutability; defensive copying in getters if fields are mutable (Date, collections) |
| C++ | const keyword |
Member functions marked const; fields can be const or accessed via const reference |
| Python | Conventions (no true constants) ALL_CAPS variable name |
Use @property with no setter; do not expose mutable attributes; return copies of internal mutable objects |
| C# | const (compile-time), readonly (runtime) |
Similar to Java |
Immutable Class Example (Java):
public final class ImmutablePerson { private final String name; private final int age; private final List<String> hobbies; // Mutable type public ImmutablePerson(String name, int age, List<String> hobbies) { this.name = name; this.age = age; // Defensive copy: create new ArrayList to prevent caller from modifying internal state this.hobbies = new ArrayList<>(hobbies); } public String getName() { return name; } public int getAge() { return age; } // Return defensive copy or immutable view public List<String> getHobbies() { return new ArrayList<>(hobbies); // defensive copy // Alternative: return Collections.unmodifiableList(hobbies); } }
Benefits of Immutability:
-
Thread-safe without synchronization
-
Simplifies reasoning (can’t change unexpectedly)
-
Can be shared freely (no defensive copies needed in many contexts)
-
Cache-friendly (hashcode constant)
7.3 Composition over Inheritance
Principle: Favor composition (has-a) over inheritance (is-a) to increase flexibility and reduce coupling.
| Aspect | Inheritance (IS-A) | Composition (HAS-A) |
|---|---|---|
| Relationship | “A Dog IS-A Animal” | “A Car HAS-A Engine” |
| Code reuse | Inherits whole interface and implementation | Reuses functionality by delegating to contained object |
| Coupling | Tight coupling (changes in parent affect children) | Loose coupling (contained object can be swapped) |
| Flexibility | Fixed at compile time | Can change at runtime (dynamic composition) |
| When to use | True “is-a” relationship; no other option; stable hierarchy | Almost always preferred unless “is-a” clearly holds and will not change |
Java Composition Example:
// Inheritance (less flexible) class Car extends Engine { ... } // Bad: A Car is not an Engine // Composition (preferred) class Car { private Engine engine; // HAS-A relationship public Car(Engine engine) { this.engine = engine; } public void start() { engine.start(); // Delegation } // Can change engine at runtime public void setEngine(Engine engine) { this.engine = engine; } }
Dependency Inversion Principle (SOLID – D): Depend on abstractions (interfaces), not concretions. Composition allows injecting dependencies via constructor, making code testable and flexible.
PART 8: EXCEPTION HANDLING
8.1 Exception Handling in OOP
Definition: A mechanism to handle runtime errors (exceptions) gracefully, separating error-handling code from normal code.
Benefits:
-
Separates normal code from error-handling code (cleaner)
-
Propagates errors up the call stack (don’t need to check return codes at every level)
-
Groups errors by type (exception hierarchy)
-
Ensures resource cleanup (finally block or try-with-resources)
8.2 Java Exception Hierarchy
Object
└── Throwable
├── Error (unrecoverable: OutOfMemoryError, StackOverflowError, VirtualMachineError)
└── Exception (recoverable)
├── RuntimeException (unchecked: NullPointerException, ArrayIndexOutOfBoundsException, IllegalArgumentException)
└── Checked exceptions: IOException, SQLException, ClassNotFoundException
| Exception Type | Checked at compile time? | Must handle? | Examples |
|---|---|---|---|
| Checked | Yes | Yes (catch or declare in throws clause) |
IOException, SQLException, ClassNotFoundException |
| Unchecked (RuntimeException) | No | No (but good practice to handle) | NullPointerException, ArithmeticException, ArrayIndexOutOfBoundsException |
| Error | No | No (should not attempt to recover) | OutOfMemoryError, StackOverflowError |
Java Exception Handling Syntax:
try { // Code that may throw an exception FileReader file = new FileReader("data.txt"); BufferedReader br = new BufferedReader(file); String data = br.readLine(); int result = 10 / 0; // throws ArithmeticException } catch (FileNotFoundException e) { System.out.println("File not found: " + e.getMessage()); e.printStackTrace(); } catch (ArithmeticException e) { System.out.println("Cannot divide by zero."); } finally { // Always executes (whether exception or not) System.out.println("Cleanup operations (close files, release resources)"); // Note: try-with-resources (Java 7+) is preferred for AutoCloseable resources }
Try-with-resources (Java 7+):
try (FileReader fr = new FileReader("data.txt"); BufferedReader br = new BufferedReader(fr)) { String data = br.readLine(); // Automatic closing of resources (AutoCloseable) } catch (IOException e) { e.printStackTrace(); }
Custom Exception:
public class InsufficientFundsException extends Exception { private double amount; public InsufficientFundsException(double amount) { super("Insufficient funds. Short by: " + amount); this.amount = amount; } public double getAmount() { return amount; } } // Throwing custom exception public void withdraw(double amount) throws InsufficientFundsException { if (balance < amount) { throw new InsufficientFundsException(amount - balance); } balance -= amount; }
8.3 C++ Exception Handling
#include <iostream> #include <stdexcept> class InsufficientFundsException : public std::exception { private: double amount; public: InsufficientFundsException(double amount) : amount(amount) {} const char* what() const noexcept override { return "Insufficient funds"; } double getAmount() const { return amount; } }; // Throwing and catching: try { if (balance < amount) { throw InsufficientFundsException(amount - balance); } } catch (const InsufficientFundsException& e) { std::cout << e.what() << ": short by "
Database Systems (Core) – Comprehensive Study Notes
Unit 1: Introduction to Database Systems
1.1 Definition of a Database
-
Database: A shared, integrated collection of logically related data stored together to serve multiple applications.
-
Database Management System (DBMS): Software that defines, creates, maintains, and controls access to the database (e.g., MySQL, PostgreSQL, Oracle, SQL Server, MongoDB).
1.2 File-Based System vs. Database Approach
| Aspect | File-Based System | Database Approach |
|---|---|---|
| Data redundancy | High (duplicate data in multiple files) | Controlled (minimized by centralization) |
| Data inconsistency | Common (updates missed in some files) | Avoided (single source of truth) |
| Data sharing | Difficult (application-specific formats) | Easy (standard interface, concurrent access) |
| Data independence | None (programs tied to file structure) | High (logical and physical independence) |
| Security | Limited (file-level only) | Granular (user, role, view-level) |
| Integrity constraints | Programmer-enforced (error-prone) | DBMS-enforced (declarative) |
| Concurrent access | No control (corruption risk) | Full ACID transactions |
1.3 Advantages of DBMS
-
Redundancy control – eliminates duplicate storage
-
Consistency maintenance – ensures data correctness
-
Data sharing & concurrency control – multiple users can access simultaneously
-
Data independence – separates logical schema from physical storage
-
Security enforcement – authentication, authorization, views
-
Backup & recovery – protects against system failures
-
Integrity constraints – rules enforced by DBMS (e.g., unique keys, foreign keys)
-
Query optimization – efficient retrieval via query processor and indexes
1.4 Disadvantages of DBMS
-
High initial cost (software, hardware, training)
-
Complexity (requires skilled DBAs)
-
Performance overhead for simple, small-scale applications
-
Single point of failure (unless replicated)
1.5 Database System Architecture (Three-Schema Architecture)
| Level | Description | View | Example |
|---|---|---|---|
| External Level (User View) | Individual user’s perspective | Subset of data, customized views | Clerk sees only customer orders |
| Conceptual Level (Logical Schema) | Overall structure of the entire database (entities, attributes, relationships) | Community view (all users) | Tables: Student(ID, Name, Major) |
| Internal Level (Physical Schema) | How data is stored physically on storage devices | Indexes, hashing, file organization | B+ tree index on Student.ID |
Data Independence:
-
Logical Data Independence: Change conceptual schema (add attribute) without changing external schemas.
-
Physical Data Independence: Change internal schema (add index) without changing conceptual schema.
1.6 Database Users and Roles
| User Type | Role |
|---|---|
| End Users | Query and update data (naïve via forms/APIs, or sophisticated via SQL) |
| Database Administrator (DBA) | Manages DBMS: backup, recovery, security, tuning, schema definition |
| Database Designer | Defines tables, constraints, relationships |
| Application Programmer | Writes programs that interact with database (Java, Python, PHP) |
1.7 Database Languages
| Language | Purpose | Commands |
|---|---|---|
| DDL (Data Definition Language) | Define and modify database schema | CREATE, ALTER, DROP, TRUNCATE |
| DML (Data Manipulation Language) | Insert, update, delete, retrieve data | INSERT, UPDATE, DELETE, SELECT |
| DCL (Data Control Language) | Manage permissions and security | GRANT, REVOKE |
| TCL (Transaction Control Language) | Manage transactions | COMMIT, ROLLBACK, SAVEPOINT |
Unit 2: Data Models
2.1 What is a Data Model?
-
Data Model: A set of concepts and rules for describing the structure of a database (data types, relationships, constraints, operations).
2.2 Evolution of Data Models (Historical Timeline)
Hierarchical (1960s) → Network (1970s) → Relational (1980s–present) → Object-Oriented (1990s) → NoSQL (2000s–present)
2.3 Hierarchical Model
| Feature | Description |
|---|---|
| Structure | Tree-like (parent-child relationship); one-to-many |
| Record type | Segment (like a record) |
| Relationship | Represented by physical pointers (links) |
| Example | IMS (IBM Information Management System) |
| Limitations | Many-to-many relationships difficult; data redundancy |
2.4 Network Model
| Feature | Description |
|---|---|
| Structure | Graph (records can have multiple parents) |
| Relationship | Represented by sets (owner–member) using pointers |
| Example | CODASYL (Conference on Data Systems Languages) |
| Limitations | Complex navigation; schema changes difficult |
2.5 Relational Model (Most Widely Used)
| Feature | Description |
|---|---|
| Inventor | E.F. Codd (1970, IBM) |
| Structure | Tables (relations) with rows (tuples) and columns (attributes) |
| Relationships | Represented by foreign keys (not physical pointers) |
| Language | SQL (Structured Query Language) |
| Advantages | Data independence, set-oriented operations, mathematical foundation (relational algebra) |
2.6 Object-Oriented and Object-Relational Models
| Feature | Description |
|---|---|
| Object-Oriented | Extends OO programming concepts to databases (objects, classes, inheritance, methods) |
| Example | ObjectDB, db4o |
| Object-Relational | Hybrid: relational tables + object extensions (user-defined types, inheritance, methods) |
| Example | PostgreSQL (some features), Oracle (object-relational features) |
2.7 NoSQL Models (For Big Data and Distributed Systems)
| Model | Data Structure | Best For | Examples |
|---|---|---|---|
| Key-Value Store | Hash table (key → value) | Session storage, caching | Redis, DynamoDB, Riak |
| Document Store | JSON/BSON documents (semi-structured) | Content management, catalogs | MongoDB, CouchDB, Firestore |
| Column-Family Store | Sparse, wide-column tables (rows + dynamic columns) | Analytics, time-series, IoT | Cassandra, HBase, Bigtable |
| Graph Database | Nodes (entities) + edges (relationships) + properties | Social networks, fraud detection, recommendation | Neo4j, Amazon Neptune, JanusGraph |
Unit 3: Relational Model Concepts
3.1 Terminology
| Relational Term | Informal Equivalent | Definition |
|---|---|---|
| Relation | Table | Set of tuples (rows) |
| Tuple | Row, Record | Single entity instance in a table |
| Attribute | Column, Field | Named property of a relation |
| Domain | Data type | Set of allowed values for an attribute |
| Degree | Number of columns | arity of relation |
| Cardinality | Number of rows | number of tuples |
| Schema | Table definition | Relation name + attribute names + domains |
| Instance | Table content | Set of tuples at a point in time |
3.2 Relational Schema Notation
STUDENT(StudentID: INTEGER, Name: VARCHAR(50), Major: VARCHAR(30), GPA: DECIMAL(3,2)) Primary Key is underlined: StudentID Foreign Key is italicized (or indicated separately)
3.3 Properties of Relations
-
Unordered rows – order of tuples does not matter (set semantics, not list).
-
Atomic (single-valued) attributes – each cell contains exactly one value (first normal form).
-
No duplicate rows – every tuple is unique (primary key enforces this).
-
Attribute names unique – within a relation.
-
Domain constraint – each attribute value must be from its domain.
Unit 4: Relational Algebra (Formal Query Language)
4.1 What is Relational Algebra?
-
Definition: A formal, procedural query language consisting of operations that take one or more relations as input and produce a new relation as output.
-
Importance: Theoretical foundation for SQL; every SQL query can be translated into relational algebra.
4.2 Selection (σ) – Filtering Rows
| Notation | σ <condition> (Relation) |
|---|---|
| Operation | Selects tuples satisfying a predicate (WHERE clause) |
| Example | σ<sub>GPA > 3.5</sub> (STUDENT) → students with GPA above 3.5 |
4.3 Projection (π) – Filtering Columns
| Notation | π<sub>attribute list</sub> (Relation) |
|---|---|
| Operation | Retrieves specified columns, eliminates duplicate rows |
| Example | π<sub>Name, Major</sub> (STUDENT) → name and major columns only |
4.4 Union (∪)
| Notation | R ∪ S |
|---|---|
| Condition | R and S must be union-compatible (same degree, corresponding domains compatible) |
| Operation | All tuples that are in R or in S (or both) |
| Example | π<sub>Name</sub>(STUDENT) ∪ π<sub>Name</sub>(FACULTY) → names of persons who are students or faculty |
4.5 Intersection (∩)
| Notation | R ∩ S |
|---|---|
| Condition | Union-compatible |
| Operation | Tuples that are in both R and S |
| Example | π<sub>Name</sub>(STUDENT) ∩ π<sub>Name</sub>(EMPLOYEE) → persons who are both students and employees |
4.6 Set Difference (−)
| Notation | R − S |
|---|---|
| Condition | Union-compatible |
| Operation | Tuples in R but not in S |
| Example | π<sub>Name</sub>(STUDENT) − π<sub>Name</sub>(GRADUATED) → students who have not yet graduated |
4.7 Cartesian Product (×)
| Notation | R × S |
|---|---|
| Operation | Concatenates every tuple of R with every tuple of S; degree = degree(R) + degree(S) |
| Example | STUDENT × COURSE → every possible student–course combination (unfiltered) |
4.8 Join Operations
A. Theta Join (θ-join) and Equi-Join
| Notation | R ⋈<sub>θ</sub> S |
|---|---|
| Definition | σ<sub>θ</sub> (R × S) |
| Equi-join | Join condition is equality (θ uses =) |
| Example | STUDENT ⋈<sub>Student.Major = Dept.DeptName</sub> DEPARTMENT |
B. Natural Join (⋈)
| Notation | R ⋈ S |
|---|---|
| Definition | Equi-join on all common attributes, with duplicate columns removed |
| Requirement | R and S share at least one attribute with same name |
| Example | STUDENT ⋈ ENROLLMENT → students joined with their enrollments on common StudentID |
C. Outer Joins
| Type | Description | Example |
|---|---|---|
| Left Outer Join (⟕) | All tuples from left relation, matching from right (NULLs where no match) | STUDENT ⟕ ENROLLMENT (students without enrollments included) |
| Right Outer Join (⟖) | All tuples from right relation, matching from left | ENROLLMENT ⟖ COURSE (courses with no enrollments included) |
| Full Outer Join (⟗) | All tuples from both relations | STUDENT ⟗ ENROLLMENT |
4.9 Division (÷)
| Notation | R ÷ S |
|---|---|
| Definition | Tuples from R that match with all tuples from S |
| Use case | “Find students who have taken all required courses” |
| Example | ENROLLMENT ÷ REQUIRED_COURSES → students enrolled in every required course |
4.10 Rename (ρ)
| Notation | ρ<sub>newName</sub> (R) or ρ<sub>newName(att1, att2…)</sub> (R) |
|---|---|
| Use | Rename relations or attributes (for self-joins or disambiguation) |
4.11 Relational Algebra Example
Query: “Find names of students who have taken CS101 course.”
π<sub>Name</sub> ( STUDENT ⋈ (σ<sub>CourseID = 'CS101'</sub> (ENROLLMENT)) )
Query: “Find students who have taken All courses offered by the CS department.”
π<sub>StudentID</sub> (ENROLLMENT) ÷ π<sub>CourseID</sub> (σ<sub>Dept = 'CS'</sub> (COURSE))
Unit 5: Structured Query Language (SQL)
5.1 SQL Data Types
| Data Type | Description | Example |
|---|---|---|
| INT, INTEGER | Whole numbers | 42, -5 |
| SMALLINT | Smaller range integer | – |
| DECIMAL(p,s), NUMERIC(p,s) | Fixed-point decimal (p = total digits, s = decimal places) | DECIMAL(10,2): 1234567.89 |
| FLOAT, REAL | Approximate floating point | 3.14159 |
| CHAR(n) | Fixed-length character string (padded with spaces) | CHAR(10): ‘John ‘ |
| VARCHAR(n) | Variable-length character string (max n) | VARCHAR(50): ‘John Doe’ |
| TEXT | Large variable-length string | Long descriptions |
| DATE | Date (YYYY-MM-DD) | ‘2025-05-10’ |
| TIME | Time (HH:MM:SS) | ’14:30:00′ |
| TIMESTAMP | Date and time | ‘2025-05-10 14:30:00’ |
| BOOLEAN | TRUE or FALSE | TRUE |
| BLOB | Binary large object | Images, audio, video |
5.2 Data Definition Language (DDL)
CREATE TABLE
CREATE TABLE Student ( StudentID INT PRIMARY KEY, Name VARCHAR(50) NOT NULL, Major VARCHAR(30), GPA DECIMAL(3,2) CHECK (GPA >= 0.0 AND GPA <= 4.0), EnrollmentDate DATE DEFAULT CURRENT_DATE ); CREATE TABLE Course ( CourseID CHAR(8) PRIMARY KEY, Title VARCHAR(100) NOT NULL, Credits INT DEFAULT 3 ); CREATE TABLE Enrollment ( StudentID INT, CourseID CHAR(8), Semester VARCHAR(10), Grade CHAR(2), PRIMARY KEY (StudentID, CourseID, Semester), FOREIGN KEY (StudentID) REFERENCES Student(StudentID) ON DELETE CASCADE, FOREIGN KEY (CourseID) REFERENCES Course(CourseID) );
ALTER TABLE
-- Add a column ALTER TABLE Student ADD COLUMN Email VARCHAR(100); -- Modify a column ALTER TABLE Student MODIFY COLUMN GPA DECIMAL(4,2); -- Rename a column (syntax varies by DBMS) ALTER TABLE Student RENAME COLUMN Name TO FullName; -- Drop a column ALTER TABLE Student DROP COLUMN Email; -- Add a constraint ALTER TABLE Student ADD CONSTRAINT unique_email UNIQUE (Email);
DROP TABLE
DROP TABLE Enrollment; -- removes table and data DROP TABLE Student CASCADE; -- also drops dependent objects (foreign keys)
5.3 Data Manipulation Language (DML)
SELECT (Query) – Full Syntax
SELECT [DISTINCT] column1, column2, ... FROM table1 [JOIN table2 ON condition] [WHERE condition] [GROUP BY column1, column2] [HAVING group_condition] [ORDER BY column1 [ASC|DESC], column2 ...] [LIMIT n];
Basic SELECT Examples
-- Retrieve all columns SELECT * FROM Student; -- Specific columns, with condition SELECT Name, GPA FROM Student WHERE Major = 'Computer Science'; -- Distinct values SELECT DISTINCT Major FROM Student; -- Sorting SELECT Name, GPA FROM Student ORDER BY GPA DESC; -- Pattern matching (LIKE: % = any string, _ = single character) SELECT Name FROM Student WHERE Name LIKE 'J%'; -- starts with J -- NULL handling SELECT Name FROM Student WHERE GPA IS NULL; -- not IS NULL
Aggregate Functions
| Function | Description | Example |
|---|---|---|
| COUNT(*) | Number of rows | SELECT COUNT(*) FROM Student; |
| COUNT(column) | Number of non-NULL values | SELECT COUNT(GPA) FROM Student; |
| AVG(column) | Average of values | SELECT AVG(GPA) FROM Student WHERE Major = 'CS'; |
| SUM(column) | Sum of values | SELECT SUM(Credits) FROM Enrollment; |
| MIN(column) | Minimum value | SELECT MIN(GPA) FROM Student; |
| MAX(column) | Maximum value | SELECT MAX(GPA) FROM Student; |
GROUP BY and HAVING
-- Average GPA by major (excluding NULL GPAs) SELECT Major, AVG(GPA) AS AvgGPA FROM Student WHERE GPA IS NOT NULL GROUP BY Major; -- Majors with average GPA > 3.0 SELECT Major, AVG(GPA) AS AvgGPA FROM Student GROUP BY Major HAVING AVG(GPA) > 3.0;
INSERT
-- Insert a single row (all columns) INSERT INTO Student VALUES (1001, 'Alice Smith', 'CS', 3.8, '2024-09-01'); -- Insert specific columns INSERT INTO Student (StudentID, Name, Major) VALUES (1002, 'Bob Jones', 'Math'); -- Insert multiple rows INSERT INTO Student (StudentID, Name, Major) VALUES (1003, 'Carol Lee', 'CS'), (1004, 'David Kim', 'Physics');
UPDATE
-- Update single row UPDATE Student SET GPA = 3.9 WHERE StudentID = 1001; -- Update multiple rows UPDATE Student SET Major = 'Data Science' WHERE Major = 'CS';
DELETE
-- Delete specific rows DELETE FROM Student WHERE StudentID = 1002; -- Delete all rows (but keep table structure) DELETE FROM Student; -- use TRUNCATE Student; for faster removal
5.4 JOINs in SQL
Inner Join (Natural Join equivalent)
-- Students and their enrollments SELECT s.Name, e.CourseID, e.Grade FROM Student s INNER JOIN Enrollment e ON s.StudentID = e.StudentID; -- Multiple joins SELECT s.Name, c.Title, e.Grade FROM Student s JOIN Enrollment e ON s.StudentID = e.StudentID JOIN Course c ON e.CourseID = c.CourseID;
Left Outer Join
-- All students (even those with no enrollments) SELECT s.Name, e.CourseID FROM Student s LEFT OUTER JOIN Enrollment e ON s.StudentID = e.StudentID;
Self-Join (using aliases)
-- Find faculty members who work in same department SELECT f1.Name, f2.Name, f1.Dept FROM Faculty f1 JOIN Faculty f2 ON f1.Dept = f2.Dept AND f1.FacultyID <> f2.FacultyID;
5.5 Subqueries (Nested Queries)
-- Subquery in WHERE clause SELECT Name FROM Student WHERE StudentID IN (SELECT StudentID FROM Enrollment WHERE CourseID = 'CS101'); -- Subquery with comparison operator SELECT Name, GPA FROM Student WHERE GPA > (SELECT AVG(GPA) FROM Student); -- Subquery in FROM clause (derived table/alias required) SELECT AVG(MajorAvg) FROM (SELECT Major, AVG(GPA) AS MajorAvg FROM Student GROUP BY Major) AS DeptAverage; -- Correlated subquery (references outer query) SELECT s1.Name, s1.GPA FROM Student s1 WHERE s1.GPA > (SELECT AVG(s2.GPA) FROM Student s2 WHERE s2.Major = s1.Major);
5.6 Set Operations in SQL
SELECT Name FROM Student UNION -- UNION ALL includes duplicates SELECT Name FROM Alumni; SELECT StudentID FROM Enrollment WHERE CourseID = 'CS101' INTERSECT -- Not supported in all DBMS; use INNER JOIN instead SELECT StudentID FROM Enrollment WHERE CourseID = 'CS102'; SELECT StudentID FROM Enrollment WHERE CourseID = 'CS101' EXCEPT -- MINUS in Oracle SELECT StudentID FROM Enrollment WHERE CourseID = 'CS102';
5.7 Views (Virtual Tables)
-- Create a view CREATE VIEW CS_Student_View AS SELECT StudentID, Name, GPA FROM Student WHERE Major = 'Computer Science'; -- Query a view (same as table) SELECT * FROM CS_Student_View WHERE GPA > 3.5; -- Updateable views (restrictions apply) UPDATE CS_Student_View SET GPA = 3.7 WHERE StudentID = 1001; -- Drop view DROP VIEW CS_Student_View;
5.8 Indexes
-- Create index on single column CREATE INDEX idx_student_name ON Student(Name); -- Create composite index CREATE INDEX idx_enrollment_student_course ON Enrollment(StudentID, CourseID); -- Unique index (enforces uniqueness) CREATE UNIQUE INDEX idx_unique_email ON Student(Email); -- Drop index DROP INDEX idx_student_name;
Unit 6: Normalization
6.1 Purpose of Normalization
-
Minimize redundancy (duplicate data) and update anomalies.
-
Reduce insertion, deletion, and modification anomalies.
-
Improve data integrity and consistency.
6.2 Anomalies (without normalization)
| Anomaly Type | Example (in denormalized table) |
|---|---|
| Insertion Anomaly | Cannot add a new course until at least one student enrolls |
| Deletion Anomaly | Deleting the last enrolled student for a course deletes the course record |
| Update Anomaly | Changing a course title requires updating multiple rows (risk of inconsistency) |
6.3 Functional Dependency (FD)
-
Definition: A → B (A functionally determines B) if, for any two tuples with same value in A, they must have same value in B.
-
Notation: A → B (read: “A determines B”)
-
Types:
-
Trivial FD: B ⊆ A (e.g., {StudentID, Name} → StudentID)
-
Non-trivial FD: B ⊈ A (e.g., StudentID → Name)
-
Completely non-trivial FD: A ∩ B = ∅ (e.g., StudentID → Major)
-
Closure of attributes (A⁺): All attributes functionally determined by A.
Candidate Key: Minimal set of attributes that functionally determines all other attributes (superkey with no proper subset being a superkey).
Primary Key: One candidate key selected as the main identifier.
6.4 Normal Forms (1NF, 2NF, 3NF, BCNF)
| Normal Form | Condition | Violation Example |
|---|---|---|
| 1NF | All attributes atomic (no repeating groups or multivalued attributes) | Student has “PhoneNumbers” column with multiple values |
| 2NF | 1NF + no partial dependency (no non-key attribute depends on part of a composite candidate key) | In (StudentID, CourseID) → InstructorName (depends only on CourseID) |
| 3NF | 2NF + no transitive dependency (no non-key attribute depends on another non-key attribute) | StudentID → DeptID, DeptID → DeptHead (DeptHead transitive on StudentID) |
| BCNF (Boyce-Codd Normal Form) | Stronger than 3NF: For every non-trivial FD X → Y, X must be a superkey | If StudentID, Major → Advisor (but Advisor → Major) – BCNF violation |
6.5 Normalization Process (Step-by-Step Example)
Unnormalized Table:
STUDENT_COURSE(StudentID, Name, Major, (CourseID, Title, Grade))
1NF (Remove repeating groups):
STUDENT_COURSE(StudentID, Name, Major, CourseID, Title, Grade)
2NF (Remove partial dependencies):
STUDENT(StudentID, Name, Major) COURSE(CourseID, Title) GRADE(StudentID, CourseID, Grade)
3NF (Remove transitive dependencies): (No transitive dependency in above)
If we had: STUDENT(StudentID, Name, DeptID, DeptHead)
-
Functional dependencies: StudentID → DeptID, DeptID → DeptHead
-
DeptHead transitively depends on StudentID (via DeptID)
-
Decompose: STUDENT(StudentID, Name, DeptID) and DEPARTMENT(DeptID, DeptHead)
6.6 Denormalization
-
Definition: Intentional introduction of redundancy (violating normal forms) to improve query performance in read-heavy systems.
-
Trade-off: Faster SELECT queries at the cost of slower UPDATE/INSERT and potential anomalies.
-
Used in: Data warehouses, reporting databases, NoSQL document stores.
Unit 7: Transaction Management
7.1 What is a Transaction?
-
Transaction: A logical unit of work that consists of one or more database operations (reads/writes) that must be executed atomically.
Example (Bank transfer):
BEGIN TRANSACTION;
UPDATE Account SET Balance = Balance - 100 WHERE AccountID = 101;
UPDATE Account SET Balance = Balance + 100 WHERE AccountID = 102;
COMMIT;
7.2 ACID Properties
| Property | Description | Ensured By |
|---|---|---|
| Atomicity | All operations in transaction complete successfully, or none are applied (all-or-nothing) | Transaction log, recovery manager |
| Consistency | Transaction brings database from one valid state to another (preserves integrity constraints) | DBMS constraints + application logic |
| Isolation | Concurrent transactions do not interfere; appear to execute serially | Concurrency control (locking, timestamping) |
| Durability | Once committed, changes persist even after system failure | Write-ahead logging (WAL), backups |
7.3 Transaction States
Active → Partially Committed → Committed ↓ ↓ ↓ Failed → Aborted → (Terminated) ↓ Aborted
7.4 Concurrency Control Problems (When Transactions Interfere)
| Problem | Description | Example |
|---|---|---|
| Lost Update | One transaction overwrites another’s uncommitted update | T1 reads X=5, T2 reads X=5, T1 writes X=6, T2 writes X=7 → lost T1’s update |
| Dirty Read | One transaction reads uncommitted data by another (which may roll back) | T1 writes X=5, T2 reads X=5, T1 rolls back → T2 has invalid data |
| Non-Repeatable Read | Same query yields different results within a transaction | T1 reads X=5, T2 updates X=6, T1 reads X=6 → inconsistent |
| Phantom Read | New rows appear or disappear between two reads | T1 counts students (10), T2 inserts new student, T1 counts students (11) |
7.5 Isolation Levels (ANSI SQL)
| Isolation Level | Dirty Read | Non-Repeatable Read | Phantom Read | Concurrency |
|---|---|---|---|---|
| READ UNCOMMITTED | Possible | Possible | Possible | Highest |
| READ COMMITTED | Not possible | Possible | Possible | High |
| REPEATABLE READ | Not possible | Not possible | Possible | Medium |
| SERIALIZABLE | Not possible | Not possible | Not possible | Lowest (but correct) |
SQL Syntax:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; BEGIN TRANSACTION; -- transaction operations COMMIT;
7.6 Locking Mechanisms
| Lock Type | Description | Permissions |
|---|---|---|
| Shared Lock (S) | Read lock; multiple transactions can hold shared lock on same item | Read only |
| Exclusive Lock (X) | Write lock; only one transaction can hold exclusive lock | Read and write |
Two-Phase Locking (2PL) Protocol:
-
Growing Phase: Transaction only acquires locks (no releases).
-
Shrinking Phase: Transaction only releases locks (no acquisitions).
Strict 2PL (most common): All locks held until COMMIT or ROLLBACK (prevents cascading aborts).
Deadlock: Two or more transactions each waiting for the other to release a lock.
Deadlock handling:
-
Deadlock prevention: Acquire all locks at once (but reduces concurrency).
-
Deadlock detection: Wait-for graph, DBMS chooses a victim (rolls back one transaction).
-
Timeout: Abort transaction that waits too long.
Unit 8: Database Design and Entity-Relationship (ER) Modeling
8.1 Database Design Phases
Requirements Analysis → Conceptual Design (ER Model) → Logical Design (Relational Schema) → Physical Design (Indexes, Storage)
8.2 ER Model Components
| Component | Symbol (Chen Notation) | Description | Example |
|---|---|---|---|
| Entity | Rectangle | Real-world object (noun) | Student, Course, Department |
| Attribute | Oval | Property of an entity | Name, GPA, Credits |
| Relationship | Diamond | Association between entities | Enrolls, Teaches, WorksIn |
| Weak Entity | Double rectangle | Entity that cannot exist without owner entity | Dependent (of Employee) |
| Key Attribute | Underlined oval | Uniquely identifies entity | StudentID, CourseID |
| Multivalued Attribute | Double oval | Multiple values allowed | PhoneNumbers |
| Derived Attribute | Dashed oval | Calculated from other attributes | Age (from DateOfBirth) |
| Composite Attribute | Oval connected to sub-ovals | Attribute composed of parts | Address (Street, City, Zip) |
| Identifying Relationship | Double diamond | Relationship connecting weak entity to owner | DependentOf |
8.3 Cardinality Constraints (Relationship Types)
A. Cardinality Ratio (maximum)
| Type | Description | Example |
|---|---|---|
| 1:1 (one-to-one) | One entity in A relates to at most one in B | Employee manages Department (Manager) |
| 1:N (one-to-many) | One entity in A relates to many in B | Department has many Employees |
| M:N (many-to-many) | Many entities in A relate to many in B | Student enrolls in Course |
B. Participation (minimum cardinality)
| Type | Description | Represented By |
|---|---|---|
| Total (mandatory) | Every entity must participate | Double line (or “1” in min-max notation) |
| Partial (optional) | Entity may or may not participate | Single line (or “0” in min-max notation) |
Min-Max Notation Example:
-
Department (1,N) → Employee (0,N) → “Each department has at least 1 employee (1) and may have many (N); each employee may belong to 0 or 1 department (0,1)”
8.4 Converting ER Diagram to Relational Schema
| ER Component | Mapping Rule |
|---|---|
| Regular Entity | Create a table with all simple attributes. Primary key = key attribute of entity. |
| Composite Attribute | Include its constituent simple attributes (not the composite itself). |
| Multivalued Attribute | Create a separate table with foreign key to owner entity + the multivalued attribute (composite primary key). |
| 1:1 Relationship | Add foreign key from one table to the other (choose side with total participation or place both FKs optional). |
| 1:N Relationship | Add foreign key from the “many” side table referencing the “one” side table. |
| M:N Relationship | Create a new (associative) table with foreign keys referencing both entities; primary key is (FK1, FK2). |
| Weak Entity | Create table with foreign key referencing owner; primary key = owner’s PK + weak entity’s partial key. |
Unit 9: Physical Database Design and Indexing
9.1 Indexing Overview
| Index Type | Structure | Best For | Overhead |
|---|---|---|---|
| B+ Tree | Balanced tree (root → internal → leaf nodes) | Equality and range queries (WHERE col = value OR col BETWEEN) | Moderate (tree maintained on updates) |
| Hash Index | Hash table (key → bucket) | Exact equality only (col = value) | Low (but no range queries) |
| Bitmap Index | Bitmaps for each distinct value | Low-cardinality columns (gender, status) | Low (but updates expensive) |
| Clustered Index | Data rows stored in index order | Primary key, range scans | High (only one per table) |
| Non-Clustered Index | Separate structure pointing to data rows | Secondary keys, lookups | Moderate (multiple allowed) |
9.2 When to Create Indexes (Guidelines)
Create index on:
-
Primary key columns (automatically indexed by most DBMS)
-
Foreign key columns (speeds up joins)
-
Columns frequently used in WHERE, JOIN, ORDER BY, GROUP BY clauses
-
Columns with high selectivity (many distinct values)
Avoid indexes on:
-
Small tables (full table scan is cheaper)
-
Columns frequently updated (INSERT, UPDATE, DELETE overhead)
-
Columns with low selectivity (e.g., gender: ‘M’/’F’ – bitmap index may help)
-
Columns not used in queries
9.3 Query Optimization (Conceptual)
-
DBMS query optimizer chooses execution plan based on statistics (table sizes, index selectivity, distribution).
-
Scan vs. Seek: Full table scan (O(n)) vs. Index seek (O(log n)).
-
Use EXPLAIN (or equivalent) to analyze query plans:
EXPLAIN SELECT * FROM Student WHERE Major = 'CS';
Unit 10: Database Security
10.1 Security Mechanisms
| Mechanism | Description |
|---|---|
| Authentication | Verifying user identity (password, biometric, multi-factor) |
| Authorization | Granting permissions to authenticated users (GRANT/REVOKE) |
| Views | Restrict access to specific rows/columns |
| Encryption | Protect data at rest (storage) and in transit (TLS/SSL) |
| Audit Trails | Logs of all database activities (for compliance, forensic analysis) |
10.2 SQL Privileges (GRANT and REVOKE)
-- Grant privileges GRANT SELECT, INSERT ON Student TO user1; GRANT ALL PRIVILEGES ON Department TO user2 WITH GRANT OPTION; -- can pass privileges GRANT SELECT ON Student TO PUBLIC; -- all users -- Revoke privileges REVOKE INSERT ON Student FROM user1; REVOKE GRANT OPTION FOR SELECT ON Student FROM
Digital Logic Design (Core) – Comprehensive Study Notes
These notes cover the fundamental principles of digital logic design, including number systems, Boolean algebra, logic gates, combinational and sequential circuits, and digital system design. Suitable for undergraduate students in computer engineering, electrical engineering, and computer science.
Part 1: Number Systems and Codes
1.1 Number Systems
Digital systems represent information using discrete voltage levels. The binary system (base-2) is fundamental because electronic devices easily represent two states (ON/OFF, HIGH/LOW).
Common Number Systems:
| System | Base | Digits | Example |
|---|---|---|---|
| Binary | 2 | 0, 1 | 1011₂ |
| Octal | 8 | 0-7 | 273₈ |
| Decimal | 10 | 0-9 | 473₁₀ |
| Hexadecimal | 16 | 0-9, A-F | 1F3₁₆ |
Positional Notation: Each digit’s value depends on its position (weight).
For base *r* and digits dᵢ (i = 0 from right, position i weight = rⁱ):
N = ∑ dᵢ × rⁱ
Example (Binary 1101.101₂):
1101.101₂ = 1×2³ + 1×2² + 0×2¹ + 1×2⁰ + 1×2⁻¹ + 0×2⁻² + 1×2⁻³
= 8 + 4 + 0 + 1 + 0.5 + 0 + 0.125 = 13.625₁₀
Binary Weights (powers of 2):
| n | 2ⁿ | n | 2⁻ⁿ |
|---|---|---|---|
| 8 | 256 | 1 | 0.5 |
| 7 | 128 | 2 | 0.25 |
| 6 | 64 | 3 | 0.125 |
| 5 | 32 | 4 | 0.0625 |
| 4 | 16 | 5 | 0.03125 |
| 3 | 8 | 6 | 0.015625 |
| 2 | 4 | 7 | 0.0078125 |
| 1 | 2 | 8 | 0.00390625 |
| 0 | 1 | — | — |
1.2 Base Conversion
Binary → Decimal: Sum of weights (as above).
Decimal → Binary (Integer part): Repeated division by 2, collect remainders from last to first.
Example: Convert 25₁₀ to binary
25 ÷ 2 = 12 remainder 1 (LSB)
12 ÷ 2 = 6 remainder 0
6 ÷ 2 = 3 remainder 0
3 ÷ 2 = 1 remainder 1
1 ÷ 2 = 0 remainder 1 (MSB)
Read remainders upward: 25₁₀ = 11001₂
Decimal → Binary (Fractional part): Repeated multiplication by 2, collect integer parts from first to last.
Example: Convert 0.625₁₀ to binary
0.625 × 2 = 1.250 → integer 1 (MSB)
0.250 × 2 = 0.500 → integer 0
0.500 × 2 = 1.000 → integer 1 (LSB)
0.625₁₀ = 0.101₂
Binary ↔ Octal: Group binary digits in threes (from radix point). Each group of 3 bits = 1 octal digit.
Example: 10 110 001 101.010 ₂ = 2 6 1 5 . 2 ₈
Binary ↔ Hexadecimal: Group binary digits in fours. Each group of 4 bits = 1 hex digit.
Example: 1011 0001 1101.1010 ₂ = B 1 D . A ₁₆
Octal ↔ Hexadecimal: Convert via binary (octal → binary → hex, or hex → binary → octal).
1.3 Binary Arithmetic
Binary Addition: Same as decimal addition (0+0=0, 0+1=1, 1+1=0 carry 1, 1+1+carry=1 carry 1).
| A | B | Cin | Sum | Cout |
|---|---|---|---|---|
| 0 | 0 | 0 | 0 | 0 |
| 0 | 0 | 1 | 1 | 0 |
| 0 | 1 | 0 | 1 | 0 |
| 0 | 1 | 1 | 0 | 1 |
| 1 | 0 | 0 | 1 | 0 |
| 1 | 0 | 1 | 0 | 1 |
| 1 | 1 | 0 | 0 | 1 |
| 1 | 1 | 1 | 1 | 1 |
Binary Subtraction (unsigned): Use borrowing. Or use two’s complement method (add negative number).
Binary Multiplication: Shift and add (like decimal).
Example: 1101₂ (13) × 1011₂ (11):
1101
× 1011
1101 (×1, shifted 0)
1101 (×1, shifted 1)
0000 (×0, shifted 2)
1101 (×1, shifted 3)
10001111₂ = 143₁₀
1.4 Signed Binary Numbers
Sign-Magnitude: Most significant bit (MSB) = sign (0 = positive, 1 = negative); remaining bits = magnitude.
Range: -(2ⁿ⁻¹ – 1) to +(2ⁿ⁻¹ – 1) for n bits. Has two zeros (+0 and -0).
One’s Complement: Negative number = complement all bits of positive number. Range: -(2ⁿ⁻¹ – 1) to +(2ⁿ⁻¹ – 1). Still has two zeros.
Two’s Complement (standard in digital systems): Negative number = complement all bits and add 1.
Range: -2ⁿ⁻¹ to +(2ⁿ⁻¹ – 1). Single zero.
Two’s Complement Conversion (n bits):
-
Positive: same as unsigned binary
-
Negative: write magnitude in binary, complement all bits, add 1
Example (4-bit, n=4): Represent -5
+5 = 0101
Complement: 1010
Add 1: 1011₂ = −5 (in 2’s complement)
Two’s Complement to Decimal (n bits):
-
If MSB = 1 (negative), complement all bits, add 1, convert to decimal, add minus sign.
-
If MSB = 0 (positive), convert directly.
4-bit Two’s Complement Table:
| Binary | Unsigned | Signed |
|---|---|---|
| 0000 | 0 | 0 |
| 0001 | 1 | 1 |
| … | … | … |
| 0111 | 7 | 7 |
| 1000 | 8 | -8 |
| 1001 | 9 | -7 |
| 1010 | 10 | -6 |
| 1011 | 11 | -5 |
| 1100 | 12 | -4 |
| 1101 | 13 | -3 |
| 1110 | 14 | -2 |
| 1111 | 15 | -1 |
Two’s Complement Addition/Subtraction:
-
Add numbers as unsigned binary
-
Ignore final carry out of most significant bit
-
Overflow occurs if: two positives sum to negative; two negatives sum to positive
Overflow detection: Overflow = Cin_MSB ⊕ Cout_MSB (XOR of carry into and out of sign bit)
1.5 Binary Codes
Binary Coded Decimal (BCD): Each decimal digit encoded as 4-bit binary (0000 to 1001). 1010-1111 unused.
| Decimal | BCD | Decimal | BCD |
|---|---|---|---|
| 0 | 0000 | 5 | 0101 |
| 1 | 0001 | 6 | 0110 |
| 2 | 0010 | 7 | 0111 |
| 3 | 0011 | 8 | 1000 |
| 4 | 0100 | 9 | 1001 |
Example: 394₁₀ = 0011 1001 0100 (BCD)
Excess-3 Code: BCD + 0011 (3). Self-complementing.
Gray Code: Consecutive numbers differ in exactly one bit. Used in position encoders (reduces errors).
| Decimal | Binary | Gray |
|---|---|---|
| 0 | 000 | 000 |
| 1 | 001 | 001 |
| 2 | 010 | 011 |
| 3 | 011 | 010 |
| 4 | 100 | 110 |
| 5 | 101 | 111 |
| 6 | 110 | 101 |
| 7 | 111 | 100 |
Binary to Gray: g₀ = b₀ ⊕ b₁, g₁ = b₁ ⊕ b₂, …, g_{n-1} = b_{n-1} ⊕ 0? More precisely: gᵢ = bᵢ ⊕ bᵢ₊₁ (for i = 0 to n-2); msb g_{n-1} = b_{n-1}).
Gray to Binary: b_{n-1} = g_{n-1}; bᵢ = gᵢ ⊕ bᵢ₊₁ (for i = n-2 down to 0)
ASCII (American Standard Code for Information Interchange): 7-bit code (extended to 8 bits) for characters. ‘A’ = 65₁₀ = 41₁₆ = 1000001₂. ‘a’ = 97₁₀ = 61₁₆ = 1100001₂. ‘0’ = 48₁₀ = 30₁₆ = 0110000₂.
Parity Bit: Extra bit appended to make number of 1s odd (odd parity) or even (even parity). Simple error detection (single bit errors).
Part 2: Boolean Algebra and Logic Gates
2.1 Boolean Algebra Axioms and Theorems
Basic Axioms (Huntington):
| OR | AND | NOT |
|---|---|---|
| x + 0 = x | x · 1 = x | |
| x + 1 = 1 | x · 0 = 0 | |
| x + x = x | x · x = x | |
| x + x̄ = 1 | x · x̄ = 0 | |
| x + y = y + x (commutative) | x · y = y · x | |
| (x+y)+z = x+(y+z) (associative) | (x·y)·z = x·(y·z) | |
| x + (y·z) = (x+y)·(x+z) (distributive) | x·(y+z) = x·y + x·z | |
| (x̄)̄ = x | (involution) |
DeMorgan’s Theorems (critical for logic simplification):
-
(x + y)̄ = x̄ · ȳ
-
(x · y)̄ = x̄ + ȳ
Generalized DeMorgan:
(x₁ + x₂ + … + xₙ)̄ = x₁̄ · x₂̄ · … · xₙ̄
(x₁ · x₂ · … · xₙ)̄ = x₁̄ + x₂̄ + … + xₙ̄
Absorption Theorems:
x + x·y = x
x· (x + y) = x
x + x̄·y = x + y
x· (x̄ + y) = x·y
Consensus Theorem:
x·y + y·z + x̄·z = x·y + x̄·z (the term y·z is redundant)
(x+y)·(y+z)·(x̄+z) = (x+y)·(x̄+z)
2.2 Logic Gates
Basic Gates:
| Gate | Symbol | Expression | Truth Table (A,B) | Description |
|---|---|---|---|---|
| AND | & | F = A · B | 00=0, 01=0, 10=0, 11=1 | Output HIGH only if ALL inputs HIGH |
| OR | ≥1 | F = A + B | 00=0, 01=1, 10=1, 11=1 | Output HIGH if ANY input HIGH |
| NOT (Inverter) | ○ | F = Ā | 0=1, 1=0 | Inverts input |
| NAND | & ○ | F = (A·B)̄ | 00=1, 01=1, 10=1, 11=0 | AND followed by NOT (universal gate) |
| NOR | ≥1 ○ | F = (A+B)̄ | 00=1, 01=0, 10=0, 11=0 | OR followed by NOT (universal gate) |
| XOR | =1 | F = A ⊕ B | 00=0, 01=1, 10=1, 11=0 | Output HIGH if inputs DIFFER |
| XNOR | =1 ○ | F = A ⊙ B | 00=1, 01=0, 10=0, 11=1 | Output HIGH if inputs EQUAL |
Buffer: F = A (used to drive high fanout, no logic change).
Universal Gates (NAND and NOR): Any logic function can be implemented using only NAND gates or only NOR gates.
NAND as Universal:
-
NOT: Ā = (A·A)̄ (NAND with both inputs tied together)
-
AND: A·B = (A·B)̄̄ = NAND followed by inverter (NAND + NAND as NOT)
-
OR: A+B = (Ā·B̄)̄ = NAND of inverted inputs (using NAND as NOT to create Ā, B̄, then NAND)
NOR as Universal: Similar construction.
2.3 Logic Families (Brief)
| Family | Technology | Characteristics |
|---|---|---|
| TTL (Transistor-Transistor Logic) | Bipolar junction transistors | 5V supply; fast; high power; obsolete in new designs but still in legacy |
| CMOS (Complementary Metal-Oxide-Semiconductor) | MOSFETs (pMOS + nMOS) | Low power; wide voltage range (2-6V); high noise margin; standard for modern ICs |
| LVTTL/LVCMOS | Low voltage variants | 3.3V, 2.5V, 1.8V versions for reduced power |
| ECL (Emitter-Coupled Logic) | Bipolar differential | Very fast; high power; used in high-speed systems |
Important parameters: Propagation delay (t_pd), power dissipation, fanout (max number of inputs driven), noise margin, input/output voltage levels (V_IL, V_IH, V_OL, V_OH).
Part 3: Boolean Function Minimization
3.1 Minterm and Maxterm Representations
Minterm (Standard Product Term): AND of all variables (complemented or not) such that function = 1 for that combination.
Maxterm (Standard Sum Term): OR of all variables such that function = 0 for that combination.
For n variables: 2ⁿ minterms (m₀ to m_{2ⁿ-1}) and 2ⁿ maxterms (M₀ to M_{2ⁿ-1}).
Example (3 variables A, B, C):
-
Minterm m₃ (A=0, B=1, C=1): Ā·B·C
-
Maxterm M₃ (A=0, B=1, C=1): A+B̄+C̄ (since maxterm = 0 for that combination, need inverted literals relative to minterm)
Canonical SOP (Sum of Products): Sum of minterms where function = 1.
F(A,B,C) = Σ m(1,3,5,6) = m₁ + m₃ + m₅ + m₆ = ĀB̄C + ĀBC + AB̄C + ABC̄
Canonical POS (Product of Sums): Product of maxterms where function = 0.
F(A,B,C) = Π M(0,2,4,7) = M₀·M₂·M₄·M₇ = (A+B+C)·(A+B̄+C)·(Ā+B+C)·(Ā+B̄+C̄)
Conversion between Σm and ΠM: F = Σ m(list) = Π M(remaining indices)
3.2 Karnaugh Maps (K-maps)
K-maps provide graphical minimization of Boolean functions (up to 6 variables). Adjacent cells differ in one variable (Gray code ordering).
2-Variable K-map:
B 0 1 A 0 m0 m1 1 m2 m3
3-Variable K-map (A, B, C):
BC
00 01 11 10
A 0 m0 m1 m3 m2
1 m4 m5 m7 m6
4-Variable K-map (A, B, C, D):
CD
00 01 11 10
AB
00 m0 m1 m3 m2
01 m4 m5 m7 m6
11 m12 m13 m15 m14
10 m8 m9 m11 m10
Rules for Minimization:
-
Groups must be rectangular and contain 2ᵏ cells (1,2,4,8,16)
-
Groups must be as large as possible (prime implicants)
-
Groups may wrap around edges (top to bottom, left to right)
-
Each 1 must be covered at least once
-
Minimize number of groups and number of literals per product term
-
Don’t cares (X) can be used as 0 or 1 to enlarge groups, but do not need to be covered
Prime Implicant: Largest possible group of 1s (including don’t cares as needed) that cannot be enlarged.
Essential Prime Implicant: Prime implicant that covers at least one 1 not covered by any other prime implicant.
Procedure:
-
Circle all prime implicants
-
Identify essential prime implicants (must include)
-
Cover remaining 1s with minimal additional prime implicants
SOP from K-map: OR together product terms for each group (variables that are constant within group).
POS from K-map: Group 0s (instead of 1s) to find complement F̄, then complement result, OR directly using maxterm grouping.
Don’t Cares (X): Used when output is unspecified for certain input combinations. Increases minimization possibilities.
3.3 Quine-McCluskey Tabular Method
For functions with >6 variables, Quine-McCluskey (QM) algorithm is systematic.
Steps:
-
List minterms in binary by number of 1s (groups)
-
Compare each minterm with all minterms in next group; combine if differ in one bit (dash notation)
-
Repeat until no further combinations possible
-
Identify prime implicants
-
Construct prime implicant chart
-
Find essential prime implicants
-
Solve covering problem
QM is programmable and guarantees minimum solution. Computationally intensive for large n.
3.4 Multi-Level Logic Minimization
Two-level logic (SOP, POS) is standard for small functions. Multi-level logic uses factoring to reduce area/share gates. Example: F = A·C + A·D + B·C + B·D = (A+B)(C+D) (factored form uses 2 OR, 1 AND instead of 4 AND, 1 OR). Tradeoffs: speed vs. area, testability.
Techniques: Factoring, decomposition, extraction, substitution.
Part 4: Combinational Logic Circuits
4.1 Arithmetic Circuits
Half Adder (HA): Adds two 1-bit numbers (A, B). Outputs Sum (S) and Carry out (C_out).
-
S = A ⊕ B (XOR)
-
C_out = A · B (AND)
Full Adder (FA): Adds three 1-bit numbers (A, B, C_in). Outputs Sum (S) and C_out.
-
S = A ⊕ B ⊕ C_in
-
C_out = A·B + A·C_in + B·C_in = A·B + C_in·(A ⊕ B)
Ripple Carry Adder (RCA): Chain of full adders. Simple but slow (propagation delay O(n)). Delay = n × t_FA.
Carry Lookahead Adder (CLA): Precompute carries using generate (G) and propagate (P).
-
G_i = A_i · B_i (generate carry when both inputs 1)
-
P_i = A_i ⊕ B_i (propagate carry when at least one input 1)
-
C_{i+1} = G_i + P_i·C_i
-
C₁ = G₀ + P₀·C₀
-
C₂ = G₁ + P₁·G₀ + P₁·P₀·C₀
-
C₃ = G₂ + P₂·G₁ + P₂·P₁·G₀ + P₂·P₁·P₀·C₀
Faster (log n delay) but more hardware.
Subtractor: Use two’s complement addition. A − B = A + (B̄ + 1). Can convert adder to subtractor with XOR gates (controlled inverter) and C_in = 1.
Carry Save Adder (CSA): Compress three numbers to two (sum and carry) without carry propagation. Used in multipliers.
Multipliers:
-
Array multiplier: AND gates generate partial products; CSA + CPA sum partial products. O(n²) gates, O(n) delay.
-
Booth multiplier: Recoding reduces number of partial products for signed multiplication.
-
Wallace tree: Reduces partial products in parallel; faster than array.
4.2 Comparators, Decoders, Encoders
Magnitude Comparator: Compares two n-bit numbers A and B.
-
A = B: all bits equal (XNOR)
-
A > B: first position (from MSB) where A_i = 1, B_i = 0, and higher bits equal.
-
A < B: symmetric.
Decoder: n inputs, 2ⁿ outputs. Output i = 1 for input binary value i.
| Enable (E) | A1 | A0 | Y3 | Y2 | Y1 | Y0 |
|---|---|---|---|---|---|---|
| 0 | X | X | 0 | 0 | 0 | 0 |
| 1 | 0 | 0 | 0 | 0 | 0 | 1 |
| 1 | 0 | 1 | 0 | 0 | 1 | 0 |
| 1 | 1 | 0 | 0 | 1 | 0 | 0 |
| 1 | 1 | 1 | 1 | 0 | 0 | 0 |
2-to-4 Decoder Truth Table (active high outputs).
Encoder: 2ⁿ inputs (one-hot), n outputs. Active input encoded as binary.
Priority Encoder: Outputs binary code of highest priority active input (e.g., highest index has priority). Useful for interrupt controllers. Example: 4-to-2 priority encoder (3 highest priority).
Multiplexer (MUX): Selects one of 2ⁿ inputs to output based on n select lines.
2-to-1 MUX: F = S̄·I₀ + S·I₁
4-to-1 MUX: F = S₁̄·S₀̄·I₀ + S₁̄·S₀·I₁ + S₁·S₀̄·I₂ + S₁·S₀·I₃
Demultiplexer (DEMUX): Routes single input to one of 2ⁿ outputs based on select lines.
Using MUX to implement logic:
-
With n select lines, implement any n+1 variable function (use one variable as data input)
-
Example: 4-to-1 MUX (2 selects) can implement any 3-variable function.
4.3 Read-Only Memory (ROM) and Programmable Logic
ROM (Read-Only Memory): Array of memory cells programmed during manufacturing (mask ROM) or after (PROM, EPROM, EEPROM, Flash).
Internally: Decoder (address lines select word line) → OR plane (bit lines). Any combinational function can be implemented as truth table stored in ROM.
PLA (Programmable Logic Array): AND plane (product terms) followed by OR plane (sum terms). Both planes programmable.
PAL (Programmable Array Logic): AND plane programmable; OR plane fixed. Simpler than PLA.
FPGA (Field-Programmable Gate Array): Configurable logic blocks (LUTs, flip-flops), programmable interconnect, I/O blocks. LUT (look-up table) typically 4-6 inputs implements any function of those inputs.
CPLD (Complex Programmable Logic Device): Macrocells (AND-OR plus flip-flop), smaller than FPGA, non-volatile.
4.4 Hazards and Glitches
Static Hazard: Output momentarily changes when it should remain constant (0 or 1) due to unequal propagation paths.
-
Static-1 hazard: Output momentarily 0 when should remain 1 (in AND-OR implementations).
-
Static-0 hazard: Output momentarily 1 when should remain 0 (in OR-AND implementations).
Dynamic Hazard: Output changes multiple times when should change only once.
Glitch: Unwanted pulse at output.
Removal: Add redundant prime implicants (hazard cover terms) to ensure all paths accounted for. Use only essential prime implicants? No: need extra terms.
Mitigation: Synchronous design (state changes on clock edge) avoids glitch propagation. For asynchronous, hazard-free logic required.
Part 5: Sequential Logic Circuits
5.1 Latches and Flip-Flops
Latch: Level-sensitive (transparent when clock/control high or low). Changes output during enable pulse.
Flip-Flop (FF): Edge-triggered (changes only on clock edge – rising or falling). More robust for synchronous systems.
SR Latch (NOR-based): Set (S) and Reset (R) inputs.
| S | R | Q | Q̄ | State |
|---|---|---|---|---|
| 0 | 0 | Q | Q̄ | Hold (previous) |
| 0 | 1 | 0 | 1 | Reset (Q=0) |
| 1 | 0 | 1 | 0 | Set (Q=1) |
| 1 | 1 | 0 | 0 | Invalid (both outputs 0) |
SR Latch (NAND-based): Active low inputs (S̄, R̄).
Gated SR Latch: Enable (E) + S,R. When E=1, behaves like SR latch; E=0, holds.
Gated D Latch: One data input D, enable E.
-
E=1: Q = D (transparent)
-
E=0: Q holds
D Flip-Flop (positive edge-triggered): On rising edge of clock (CLK), Q = D. Otherwise holds. Constructed from two D latches in master-slave configuration.
JK Flip-Flop: J=set, K=reset. No invalid state.
| J | K | CLK | Q_next |
|---|---|---|---|
| 0 | 0 | ↑ | Q (hold) |
| 0 | 1 | ↑ | 0 (reset) |
| 1 | 0 | ↑ | 1 (set) |
| 1 | 1 | ↑ | Q̄ (toggle) |
T Flip-Flop: Single input T. Toggles when T=1, holds when T=0.
-
T=0: Q_next = Q (hold)
-
T=1: Q_next = Q̄ (toggle)
Characteristic Equations:
-
D FF: Q_next = D
-
JK FF: Q_next = J·Q̄ + K̄·Q
-
T FF: Q_next = T ⊕ Q
Flip-Flop Timing Parameters:
-
Setup time (t_su): Minimum time data must be stable before clock edge
-
Hold time (t_h): Minimum time data must be stable after clock edge
-
Propagation delay (t_cq, t_pcq): Clock edge to output valid
-
Minimum clock period: T_clk ≥ t_pcq + t_logic + t_su (for combinational logic between FFs)
Metastability: When setup/hold times violated, output can oscillate or settle to intermediate voltage for unpredictable duration. Mitigated by synchronizers (two or more FFs in series).
5.2 Registers and Shift Registers
Register: Group of D flip-flops sharing a common clock, storing n bits.
Shift Register: Cascaded FFs where output of one is input to next. Data shifts on each clock.
| Type | Description | Applications |
|---|---|---|
| SISO (Serial In, Serial Out) | Single input, single output; data shifted through | Delay line, time delay |
| SIPO (Serial In, Parallel Out) | Serial input; parallel output of all stages | Serial-to-parallel converter (UART receiver) |
| PISO (Parallel In, Serial Out) | Parallel load; serial output | Parallel-to-serial converter (UART transmitter) |
| PIPO (Parallel In, Parallel Out) | Parallel load and read | Storage register (e.g., memory buffer) |
| Bidirectional | Can shift left or right | Barrel shifter, general purpose |
Universal Shift Register: Modes: hold, shift left, shift right, parallel load. Controlled by mode select lines.
Ring Counter: Shift register with feedback from last output to first input. Single 1 circulates (n states) or single 0 circulates. Decodes uniquely without extra logic. Johnson counter (twisted ring): feedback inverted; 2n states.
5.3 Counters
Asynchronous (Ripple) Counter: Flip-flops not clocked simultaneously. Each FF output clocks next FF. Simple but slow (propagation delays accumulate).
Synchronous Counter: All FFs clocked by same clock. Faster (delay independent of bits). More complex decode logic.
Binary Up Counter: Counts 0000 → 0001 → … → 1111 → 0000.
-
For T FFs: T_i = 1 (for LSB) or AND of all lower bits (e.g., T₂ = Q₁·Q₀ for 3-bit)
Binary Down Counter: Decrement.
Up/Down Counter: Control signal Up/Down. T_i = 1 if all lower bits match appropriate pattern (all 1s for up, all 0s for down, depending).
BCD Counter (Decade Counter): Counts 0000 to 1001 (0-9), resets to 0000 at 1010.
Modulo-N Counter (Mod-N): Counts 0 to N-1. Uses reset logic or load to (2ⁿ − N) for preset start.
Modulo-N with load: Load N on terminal count.
5.4 Finite State Machines (FSMs)
FSM = Set of states, transitions between states, outputs. Two types:
| Type | Output depends on | Mealy | Moore |
|---|---|---|---|
| Moore | Current state only | Output = F(state) | Output changes only on clock edges |
| Mealy | Current state + inputs | Output = F(state, input) | Output can change asynchronously (combinational path from input) |
FSM Design Steps (Synchronous Moore/Mealy):
-
State diagram (circles = states, arrows = transitions labeled input/output for Mealy; input/output for Moore output in state circle)
-
State transition table (present state, next state, output)
-
State assignment (assign binary codes to states)
-
Derive next state logic (using K-maps)
-
Derive output logic (combinational)
-
Implement with flip-flops (D, JK, or T) and gates
State Encoding Options:
-
Binary: Minimum flip-flops (⌈log₂ n⌉), complex next state logic
-
One-hot: n flip-flops, simple next state logic (one FF per state; exactly one FF=1 at any time). Better for FPGAs.
-
Gray code: Adjacent states differ in one bit (reduces glitches).
State Reduction (Minimization): Equivalent states have same output and same next states for all inputs. Use implication chart or row matching.
FSM Optimization:
-
State encoding affects area and speed
-
Don’t cares in transition table allow minimization
-
Mealy generally has fewer states than Moore, but output timing more complex
FSM Examples: Sequence detector (detect 1011), vending machine, traffic light controller, UART receiver.
Part 6: Memory and Programmable Logic
6.1 Memory Organization
Memory Architecture:
-
Address lines (n): Select specific memory location (2ⁿ locations)
-
Data lines (m): Bits per location (word size)
-
Memory size: 2ⁿ × m bits
-
Address decoder: Maps address to word line (selects one row of storage cells)
Read operation:
-
Address applied to address lines
-
Chip enable (CE) and output enable (OE) asserted (if present)
-
Decoder selects word; data read from sense amplifiers
-
Data appears on data outputs
Write operation:
-
Address applied
-
Data applied to data inputs
-
Write enable (WE) asserted
-
Decoder selects word; data written to storage cells
Memory Types:
| Memory Type | Volatile | Read/Write | Speed | Use |
|---|---|---|---|---|
| SRAM (Static RAM) | Yes | Read/Write | Fast | Cache, register files, small fast memory |
| DRAM (Dynamic RAM) | Yes (refreshed) | Read/Write | Medium | Main memory (commodity) |
| SDRAM (Synchronous DRAM) | Yes | Read/Write | Medium-high | Computer RAM (DDR) |
| ROM (Mask ROM) | No | Read only (factory) | Medium | Firmware, boot code |
| PROM (Programmable ROM) | No | Write once (user) | Medium | Low volume firmware |
| EPROM (Erasable PROM) | No | UV-erasable, reprogrammable | Medium | Development, prototypes |
| EEPROM (Electrically EPROM) | No | Byte-erasable, reprogrammable | Medium | Configuration, serial EEPROM |
| Flash (Flash Memory) | No | Block-erasable, reprogrammable | Medium-high | SSDs, USB drives, firmware |
6.2 Programmable Logic Devices (Overview)
| Device | AND Plane | OR Plane | Flip-Flops | Capacity |
|---|---|---|---|---|
| PROM | Fixed (decoder) | Programmable | Optional | Small |
| PLA | Programmable | Programmable | Optional | Small-medium |
| PAL | Programmable | Fixed | Optional | Small-medium |
| CPLD | Multiple PAL-like blocks | – | Yes (macrocells) | Medium (hundreds of FFs) |
| FPGA | LUT-based (6 inputs typical) | – | Yes (many) | Large (millions of FFs) |
Artificial Intelligence (Core) – Comprehensive Study Notes
Part 1: Foundations of Artificial Intelligence
1.1 Definition and Goals
Definition: Artificial Intelligence (AI) is the branch of computer science concerned with building systems that exhibit intelligent behavior — perceiving, reasoning, learning, and acting autonomously to achieve goals.
Four Main Goals (Russell & Norvig):
| Goal | Description |
|---|---|
| Act humanly | Pass the Turing Test (conversational behavior indistinguishable from human) |
| Think humanly | Model cognitive processes (cognitive modeling / cognitive architecture) |
| Think rationally | Use formal logic to derive correct conclusions (laws of thought) |
| Act rationally | Achieve goals given available information (rational agent approach – most modern AI) |
Turing Test (Alan Turing, 1950):
A human interrogator converses with a human and a machine via text. If the interrogator cannot reliably distinguish the machine from the human, the machine passes.
Chinese Room Argument (Searle, 1980):
Counterargument to Turing Test: syntactic symbol manipulation (following rules) does not equal semantic understanding. A person following rules to produce Chinese outputs does not understand Chinese.
Strong AI vs. Weak AI:
| Term | Definition | Current Status |
|---|---|---|
| Weak AI (Narrow AI) | Systems designed for a specific task (chess, face recognition, translation) | Achieved; widely used |
| Strong AI (AGI – Artificial General Intelligence) | System with human-level general intelligence across any domain | Not yet achieved |
| Superintelligence | Intelligence vastly exceeding human level in all domains | Hypothetical / future |
1.2 History of AI (Brief Timeline)
| Era | Key Developments |
|---|---|
| 1940s–1950s | McCulloch-Pitts neurons (1943), Turing Test (1950), Dartmouth Workshop (1956) – AI named |
| 1950s–1970s | Early successes: Logic Theorist, GPS (General Problem Solver), ELIZA. Then AI Winter (limited compute, unrealistic promises) |
| 1980s | Expert systems boom (rule-based), backpropagation for neural nets, then second AI Winter (expert systems too brittle) |
| 1990s | IBM Deep Blue beats Kasparov (1997), probabilistic methods, Bayesian networks, reinforcement learning |
| 2000s–2010s | Machine learning dominates, deep learning revolution (ImageNet 2012), AlphaGo beats Lee Sedol (2016) |
| 2020s | Large Language Models (GPT, BERT, Llama), generative AI (image, video, music), multimodal models |
1.3 Intelligent Agents
Definition: An agent is anything that perceives its environment through sensors and acts upon that environment through actuators.
Agent Function: f:Percept History→Action
Performance Measure: Objective criterion for success (e.g., speed, accuracy, safety, efficiency).
| Agent Type | Complexity | Description | Example |
|---|---|---|---|
| Simple Reflex Agent | Low | Responds to current percept using condition-action rules | Thermostat, light switch |
| Model-Based Reflex Agent | Low-Medium | Maintains internal state to handle partially observable environments | Vacuum cleaner robot |
| Goal-Based Agent | Medium | Chooses actions to achieve a specified goal | Navigation system (GPS) |
| Utility-Based Agent | High | Maximizes a utility function (trade-offs, preferences) | Self-driving car (safety vs. speed vs. comfort) |
| Learning Agent | Highest | Improves performance over time through experience | Recommendation system, AlphaGo |
Properties of Environments (PEAS – Performance, Environment, Actuators, Sensors):
| Property | Dichotomy | Meaning |
|---|---|---|
| Observability | Fully observable vs. Partially observable | Agent can see complete state? |
| Determinism | Deterministic vs. Stochastic | Next state determined solely by current state and action? |
| Episodicity | Episodic vs. Sequential | Independent episodes or long-term consequences? |
| Dynamics | Static vs. Dynamic | Environment changes while agent deliberates? |
| Continuity | Discrete vs. Continuous | Finite set of states/actions vs. infinite |
| Number of agents | Single vs. Multi-agent | Other agents (cooperative, competitive, adversarial) |
Example – Chess playing:
-
Fully observable (board state visible)
-
Deterministic (rules fixed)
-
Sequential (moves build to endgame)
-
Static (opponent’s move only after your move)
-
Discrete (finite moves)
-
Multi-agent (adversarial)
Part 2: Problem Solving by Search
2.1 Problem Formulation
Components of a Search Problem:
| Component | Definition | Example (Route finding) |
|---|---|---|
| Initial state | Starting configuration | Arad |
| Actions (operators) | Possible moves from a state | Go to Sibiu, Go to Timisoara, etc. |
| Transition model | Result of action: Result(s, a) = s’ | In(Arad) + Go(Sibiu) → In(Sibiu) |
| Goal test | Determines if state is goal | In(Bucharest) |
| Path cost | Cost of sequence (usually additive) | Distance in km, travel time |
State space: Set of all states reachable from initial state.
Solution: A path from initial state to goal state.
Optimal solution: Path with lowest path cost.
2.2 Tree Search vs. Graph Search
Tree Search: May revisit states (exponential redundancy).
Graph Search: Keeps explored set (closed list) to avoid revisiting.
function TREE_SEARCH(problem):
frontier = {initial state}
loop:
if frontier empty: return failure
choose leaf node from frontier
if node contains goal: return solution
expand node, add children to frontier
function GRAPH_SEARCH(problem):
frontier = {initial state}
explored = empty set
loop:
if frontier empty: return failure
choose leaf node from frontier
if node contains goal: return solution
add node to explored
expand node, add children to frontier
(if not already in frontier or explored)
Frontier data structure determines search strategy (LIFO, FIFO, priority queue).
2.3 Uninformed (Blind) Search Strategies
No additional information beyond problem definition.
| Algorithm | Frontier | Completeness* | Optimal* | Time | Space |
|---|---|---|---|---|---|
| Breadth-First Search (BFS) | Queue (FIFO) | Yes | Yes (uniform cost) | O(bᵈ) | O(bᵈ) |
| Uniform Cost Search (UCS) | Priority queue (lowest path cost) | Yes | Yes | O(b^(1+⌊C*/ε⌋)) | O(b^(1+⌊C*/ε⌋)) |
| Depth-First Search (DFS) | Stack (LIFO) | No (infinite trees) | No | O(bᵐ) | O(bm) |
| Depth-Limited Search | Stack with depth limit | No (if limit too low) | No | O(bˡ) | O(bl) |
| Iterative Deepening DFS (IDDFS) | DFS iteratively increasing depth limit | Yes | Yes (uniform cost) | O(bᵈ) | O(bd) |
| Bidirectional Search | Two frontiers (forward + backward) | Yes | Yes | O(bᵈ/²) | O(bᵈ/²) |
*Completeness = guaranteed to find a solution if one exists.
*Optimality = guaranteed to find lowest-cost solution.
Notation:
-
b = branching factor (max children per node)
-
d = depth of shallowest goal
-
m = max depth of tree (may be infinite)
-
l = depth limit
-
C* = cost of optimal solution
-
ε = minimum edge cost (positive)
When to use which:
-
BFS: Small state space, uniform cost, goal shallow.
-
UCS: Positive edge costs, need optimal solution.
-
DFS: Very large/deep tree, memory constrained, don’t need optimal.
-
IDDFS: Unknown depth, tree large, want completeness + memory efficiency.
-
Bidirectional: Goal known, reversible actions, branching factor symmetric.
2.4 Informed (Heuristic) Search
Heuristic function h(n): Estimated cost from node n to goal. Must be admissible (never overestimate true cost) for optimality in A*.
Greedy Best-First Search:
-
Evaluation function: f(n) = h(n)
-
Expands node believed closest to goal
-
Often incomplete (can get stuck), not optimal
-
Space: O(bᵐ) (worst case)
-
Example: Straight-line distance to Bucharest (geographical)
A Search (Most Important Informed Algorithm):*
-
Evaluation function: f(n) = g(n) + h(n)
-
g(n) = actual cost from start to n
-
h(n) = heuristic estimate from n to goal
-
-
Combines UCS (g) and Greedy (h)
Properties of A*:
| Condition | Result |
|---|---|
| h(n) is admissible (never overestimates true cost) | Tree-search A* is optimal |
| h(n) is consistent (monotonic) (h(n) ≤ c(n,a,n’) + h(n’)) | Graph-search A* is optimal |
| Heuristic is consistent | f(n) never decreases along path |
| With consistent heuristic | A* expands states in order of increasing f(n) |
Admissible heuristics example (8-puzzle):
-
h₁ = number of misplaced tiles (admissible? Yes – each tile must move ≥ 1)
-
h₂ = Manhattan distance (sum of moves each tile away from goal – admissible? Yes – each tile must move at least Manhattan distance)
Dominance: If h₂ dominates h₁ (h₂(n) ≥ h₁(n) for all n) and both admissible → h₂ expands fewer nodes (better).
Weighted A (trade optimality for speed):* f(n) = g(n) + w·h(n), w > 1. Faster but not optimal.
2.5 Local Search and Optimization
Use when: Path to goal irrelevant; only goal state matters.
| Algorithm | Method | Pros | Cons |
|---|---|---|---|
| Hill Climbing (Greedy Local Search) | Move to neighbor with highest value; stop at peak | Simple, low memory | Local maxima, plateaus, ridges |
| Random Restart Hill Climbing | Run hill climbing multiple times from random starts | Better chance of global optimum | No guarantee |
| Simulated Annealing | Accept worse moves with probability decreasing over time | Can escape local maxima | Parameters (temperature schedule) |
| Local Beam Search | Keep k best states at each step; explore from all | Parallel exploration | Can converge to same local optimum |
| Genetic Algorithms (GA) | Selection, crossover, mutation on population | Robust for complex spaces | Expensive, many parameters |
Simulated Annealing Probability of accepting worse move:
P=e−(Enew−Eold)/T
where T (temperature) decreases over time.
Part 3: Adversarial Search (Game Playing)
3.1 Minimax Algorithm
Definition: Recursive algorithm for deterministic, two-player, zero-sum games (one player’s gain is other’s loss).
Values:
-
MAX player (maximizes outcome)
-
MIN player (minimizes outcome)
Minimax Recursion:
Minimax(s)={Utility(s)if terminal statemaxaMinimax(Result(s,a))if MAX turnminaMinimax(Result(s,a))if MIN turn
Properties:
-
Time: O(bᵈ) (exhaustive)
-
Space: O(bd) (depth-first)
-
Complete and optimal for fully observable, deterministic games
3.2 Alpha-Beta Pruning
Idea: Prune branches that cannot influence final decision.
Alpha (α): Best value MAX can guarantee so far (lower bound).
Beta (β): Best value MIN can guarantee so far (upper bound).
Pruning rules:
-
Alpha cut-off: If current MIN node value ≤ α, prune remaining children (MAX won’t choose this branch)
-
Beta cut-off: If current MAX node value ≥ β, prune remaining children (MIN won’t choose this branch)
Effect: Optimal pruning reduces nodes examined from O(bᵈ) to O(bᵈ/²) (best case) – doubles achievable depth.
Order matters: Examine best moves first for more pruning (move ordering heuristics).
3.3 Heuristic Evaluation Functions
For games too large for full minimax (chess, Go), evaluate non-terminal states using heuristic function.
Good evaluation function should:
-
Correlate strongly with winning probability
-
Compute quickly
-
Use features (material, piece-square tables, mobility, king safety)
Cutoff test: Instead of terminal test, use depth limit + quiescence search (avoid horizon effect by exploring volatile positions deeper).
Part 4: Knowledge Representation and Reasoning
4.1 Ontology and Epistemology
| Term | Definition |
|---|---|
| Ontology | What exists in the world? Categories, objects, relationships, properties |
| Epistemology | What can be known? Beliefs, knowledge, degrees of certainty |
Ontological commitment: What categories does the representation assume?
Epistemological commitment: What is the degree of belief (true/false, probability, fuzzy)?
4.2 Propositional Logic
Syntax:
-
Atoms (propositional symbols): P, Q, R (True/False)
-
Logical connectives: ¬ (NOT), ∧ (AND), ∨ (OR), → (implication), ↔ (biconditional)
Semantics:
| P | Q | ¬P | P ∧ Q | P ∨ Q | P → Q | P ↔ Q |
|---|---|---|---|---|---|---|
| F | F | T | F | F | T | T |
| F | T | T | F | T | T | F |
| T | F | F | F | T | F | F |
| T | T | F | T | T | T | T |
Inference rules:
| Rule | From | Deduce |
|---|---|---|
| Modus Ponens | α → β, α | β |
| Modus Tollens | α → β, ¬β | ¬α |
| And Elimination | α ∧ β | α (and β) |
| And Introduction | α, β | α ∧ β |
| Or Introduction | α | α ∨ β |
| Resolution | α ∨ β, ¬β ∨ γ | α ∨ γ |
Resolution refutation: To prove KB ⊧ α, show (KB ∧ ¬α) is unsatisfiable (empty clause).
Limitations of propositional logic:
-
Cannot represent objects and relationships systematically
-
Need separate proposition for every instance (e.g., Sunny_Day1, Sunny_Day2, …)
-
No variables or quantifiers
4.3 First-Order Logic (FOL) / Predicate Logic
Components:
-
Objects: People, numbers, houses, etc.
-
Relations: Unary (properties), n-ary (relationships) – e.g., Brother(John, Mary)
-
Functions: Map objects to objects – e.g., father_of(John)
Syntax:
-
Constants: john, 5, red
-
Variables: x, y, z
-
Predicates: Brother(x,y), Student(john)
-
Functions: plus(x,y), age(john)
-
Quantifiers:
-
∀ (Universal): “for all” – ∀x Person(x) → Mortal(x)
-
∃ (Existential): “there exists” – ∃x Sister(x, john) ∧ Person(x)
-
Quantifier duality:
-
¬∀x P(x) ≡ ∃x ¬P(x)
-
¬∃x P(x) ≡ ∀x ¬P(x)
Inference in FOL: Universal instantiation, existential instantiation, generalized modus ponens, unification, forward/backward chaining, resolution.
Unification: Finding substitution θ such that two literals become identical.
-
Unify(Knows(John, x), Knows(John, Mary)) = {x/Mary}
-
Unify(Knows(John, x), Knows(y, Bill)) = {y/John, x/Bill}
-
Unify(Knows(John, x), Knows(x, Bill)) = fail (occurs check needed)
4.4 Knowledge Engineering
Process:
-
Identify the task – What questions will be asked?
-
Assemble relevant knowledge – Consult experts, documents
-
Decide on vocabulary – Predicates, functions, constants
-
Encode general knowledge – Axioms, rules
-
Encode specific problem instance
-
Query the KB – Use inference
-
Debug and refine
Example (Family relationships):
∀x,y Parent(x,y) → Person(x) ∧ Person(y) ∀x,y Mother(x,y) → Parent(x,y) ∧ Female(x) ∀x,y Father(x,y) → Parent(x,y) ∧ Male(x) ∀x,y Sibling(x,y) → ∃p Parent(p,x) ∧ Parent(p,y) ∧ x ≠ y
Part 5: Planning
5.1 Classical Planning
Definition: Finding a sequence of actions to achieve a goal from an initial state.
Representation (PDDL – Planning Domain Definition Language):
| Component | Syntax | Example |
|---|---|---|
| Initial state | Logical conjunction | At(Home) ∧ Have(Milk) ∧ ¬Have(Bananas) |
| Goal state | Conjunction (positive literals) | At(Supermarket) ∧ Have(Bananas) |
| Action schema | Action(Go(x,y), PRECOND: At(x), EFFECT: At(y) ∧ ¬At(x)) |
Action representation (STRIPS):
Action(Go(x,y):
PRECOND: At(x)
EFFECT: At(y) ∧ ¬At(x))
5.2 Planning Algorithms
Forward state-space search (progression): Start from initial state, apply actions until goal. Branching factor: number of applicable actions. Prone to irrelevant actions.
Backward state-space search (regression): Start from goal, find actions that lead to it (relevant actions). Less branching factor.
Partial-Order Planning (POP): Plans with steps not fully ordered. Represented as:
-
Steps: Actions in the plan
-
Orderings: A ≺ B (A before B)
-
Bindings: Variable equalities/inequalities
-
Causal links: A →⁽ᵖ⁾ B (A achieves precondition p for B)
Threat: Step C that could undo p (delete effect). Must be resolved by ordering or constraints.
GraphPlan: Builds planning graph (levels of actions and propositions). Extracts plan using backward search.
Part 6: Reasoning Under Uncertainty
6.1 Probability Basics
Definition: Probability quantifies uncertainty over possible worlds.
Axioms of probability:
-
0 ≤ P(ω) ≤ 1 for each outcome ω
-
∑ωP(ω)=1
-
For mutually exclusive events: P(A ∨ B) = P(A) + P(B)
Conditional probability:
P(A∣B)=P(A∧B)P(B)(if P(B) > 0)
Product rule: P(A ∧ B) = P(A|B) P(B) = P(B|A) P(A)
Bayes’ rule (Bayes’ theorem):
P(A∣B)=P(B∣A)P(A)P(B)
Normalization: For hypotheses H_i with mutually exclusive and exhaustive:
P(Hi∣E)=P(E∣Hi)P(Hi)∑jP(E∣Hj)P(Hj)
Independence: A and B independent if P(A|B) = P(A) or P(A ∧ B) = P(A)P(B)
Conditional independence: A and B independent given C:
P(A ∧ B | C) = P(A|C) P(B|C)
6.2 Bayesian Networks (Belief Networks)
Definition: Directed acyclic graph (DAG) representing conditional dependencies between variables.
Components:
-
Nodes: Random variables
-
Edges: Direct influence (parent → child)
-
Conditional probability table (CPT): For each node, P(node | parents)
Joint distribution from BN:
P(X1,…,Xn)=∏i=1nP(Xi∣Parents(Xi))
Example (Burglar Alarm):
Variables: B (Burglary), E (Earthquake), A (Alarm), J (John calls), M (Mary calls)
BN Structure: B → A ← E, A → J, A → M
P(B)=0.001, P(E)=0.002
P(A|B,E): T=0.95, T/F=0.29, F/T=0.94, F/F=0.001
P(J|A): 0.90 if A=T, 0.05 if A=F
P(M|A): 0.70 if A=T, 0.01 if A=F
Inference types:
-
Causal (predictive): P(J | B) – down the arrows
-
Evidential (diagnostic): P(B | J) – up the arrows
-
Intercausal (explaining away): P(B | J ∧ E) – between causes of common effect
Exact inference: Variable elimination (exponential worst-case).
Approximate inference: Rejection sampling, likelihood weighting, Gibbs sampling (MCMC).
6.3 Bayesian Inference & Naïve Bayes Classifier
Naïve Bayes assumption: Features are conditionally independent given class label.
P(C∣F1,…,Fn)∝P(C)∏i=1nP(Fi∣C)
Used for classification (spam detection, document classification).
Part 7: Machine Learning (Core)
7.1 Types of Learning
| Type | Definition | Input | Output | Example |
|---|---|---|---|---|
| Supervised Learning | Learn mapping from input to output using labeled examples | (x, y) pairs | f: x → y | Classification, regression (spam filter, house price) |
| Unsupervised Learning | Find patterns in unlabeled data | x only | Clusters, latent structure | Clustering (k-means), dimensionality reduction (PCA) |
| Reinforcement Learning | Learn actions to maximize reward | State, action, reward | Policy: state → action | Game playing, robotics, autonomous driving |
7.2 Supervised Learning Algorithms
| Algorithm | Type | Key Idea | Pros | Cons |
|---|---|---|---|---|
| Decision Trees | Classification/Regression | Recursive partition using information gain | Interpretable, handles mixed data | Overfitting, unstable |
| k-Nearest Neighbors (k-NN) | Classification/Regression | Majority vote of k closest neighbors | Simple, no training | Slow prediction, curse of dimensionality |
| Linear Regression | Regression | Fit line minimizing squared error | Fast, interpretable | Linear assumption only |
| Logistic Regression | Binary Classification | Sigmoid of linear function | Probabilistic, linear decision boundary | Linear boundary |
| Support Vector Machines (SVM) | Classification | Maximum margin hyperplane | Effective in high dimensions | Kernel choice, less interpretable |
| Neural Networks (Deep Learning) | Classification/Regression | Layered non-linear transformations | Universal approximator | Data hungry, black box |
| Naïve Bayes | Classification | Apply Bayes theorem (feature independence) | Fast, works with small data | Independence assumption often violated |
Ensemble Methods:
-
Bagging (Bootstrap Aggregating): Train multiple models on resampled data; average predictions (Random Forest).
-
Boosting (AdaBoost, Gradient Boosting, XGBoost): Train models sequentially, each correcting previous errors.
-
Random Forest: Many decorrelated decision trees; reduces variance.
7.3 Inductive Bias
Definition: Assumptions made by a learning algorithm to generalize beyond training data.
Examples:
-
Decision trees: prefer short trees (Occam’s razor)
-
k-NN: similar inputs → similar outputs (smoothness)
-
Linear regression: linear relationship
No Free Lunch Theorem (Wolpert): No single algorithm universally outperforms others across all problems. Bias must match the problem domain.
7.4 Evaluation and Validation
| Metric | Formula | Best For |
|---|---|---|
| Accuracy | (TP+TN)/(TP+TN+FP+FN) | Balanced classes |
| Precision | TP/(TP+FP) | Minimize false positives (spam detection) |
| Recall (Sensitivity) | TP/(TP+FN) | Minimize false negatives (cancer detection) |
| F1 Score | 2·(P·R)/(P+R) | Harmonic mean of precision & recall |
| Specificity | TN/(TN+FP) | True negative rate |
| ROC-AUC | Area under ROC curve | Overall classifier quality |
Confusion Matrix:
| Predicted Positive | Predicted Negative | |
|---|---|---|
| Actual Positive | TP | FN |
| Actual Negative | FP | TN |
Cross-Validation:
-
k-Fold: Split data into k folds; train on k-1, validate on 1; repeat k times.
-
Leave-One-Out (LOO): k = N (training on all but one). High variance, expensive.
Bias-Variance Tradeoff:
-
Bias: Error from wrong assumptions (underfitting)
-
Variance: Error from sensitivity to training data (overfitting)
-
Total error = Bias² + Variance + Irreducible error
Learning curves: Plot training and validation error vs. training set size.
7.5 Unsupervised Learning
Clustering Algorithms:
| Algorithm | Method | Best For | Complexity |
|---|---|---|---|
| k-means | Partition into k clusters; minimize within-cluster variance | Spherical, equal-size clusters | O(n·k·i) |
| Hierarchical (Agglomerative) | Bottom-up merging of closest clusters | Hierarchical relationships, any shape | O(n³) naive, O(n²) with efficient methods |
| DBSCAN | Density-based (neighbors within ε) | Arbitrary shapes, noise detection | O(n log n) with indexing |
| Gaussian Mixture Models (GMM) | Probabilistic soft clustering | Elliptical clusters, uncertainty | O(n·k) |
Dimensionality Reduction:
-
Principal Component Analysis (PCA): Linear projection maximizing variance.
-
t-SNE / UMAP: Non-linear; preserves local structure (visualization).
Part 8: Reinforcement Learning (Core)
8.1 Markov Decision Processes (MDP)
Components:
-
S: Set of states
-
A(s): Set of actions available in state s
-
P(s’ | s, a): Transition probability (Markov property: next state depends only on current state and action)
-
R(s, a, s’): Reward function (or R(s), R(s,a))
-
γ: Discount factor (0 ≤ γ < 1) – weights near-term vs. future rewards
-
π: Policy – mapping from state to action
Return (Cumulative discounted reward):
Gt=rt+1+γrt+2+γ2rt+3+…=∑k=0∞γkrt+k+1
Value functions:
-
State-value (V^π(s)): Expected return starting from state s following policy π
-
Action-value (Q^π(s,a)): Expected return starting from state s, taking action a, then following policy π
Bellman equations (optimal):
V∗(s)=maxa∑s′P(s′∣s,a)[R(s,a,s′)+γV∗(s′)]
Q∗(s,a)=∑s′P(s′∣s,a)[R(s,a,s′)+γmaxa′Q∗(s′,a′)]
8.2 Planning vs. Learning
| Model known | Model unknown | |
|---|---|---|
| Transition probabilities known | MDP solved via dynamic programming (Value iteration, Policy iteration) | — |
| Model unknown | — | Model-free RL (Q-learning, SARSA, Policy Gradient) |
Dynamic Programming (Model-based):
-
Policy iteration: Evaluate policy, then improve (greedy)
-
Value iteration: Repeatedly apply Bellman backup until convergence
8.3 Model-Free Reinforcement Learning
Q-Learning (Off-policy – learns optimal policy independent of behavior policy):
Q(s,a)←Q(s,a)+α[r+γmaxa′Q(s′,a′)−Q(s,a)]
SARSA (On-policy – learns value of current policy):
Q(s,a)←Q(s,a)+α[r+γQ(s′,a′)−Q(s,a)]
Key differences:
-
Q-learning uses max over next actions (risk-seeking)
-
SARSA uses actual next action (more conservative in risky environments)
Exploration vs. Exploitation:
-
ε-greedy: With probability ε choose random action; otherwise choose best action
-
Softmax (Boltzmann): Weighted by temperature
-
Upper Confidence Bound (UCB): Add uncertainty bonus to action value
Deep Q-Networks (DQN): Use neural networks to approximate Q-values, with experience replay and target network (stabilizes training).
Policy Gradient Methods (REINFORCE, PPO, A3C): Optimize policy directly without value function. Work well in high-dimensional continuous action spaces.
9. Quick Revision Checklist
Foundations
-
Define AI, rationality, agent, environment
-
PEAS components (Performance, Environment, Actuators, Sensors)
-
Agent types (simple reflex, model-based, goal-based, utility-based, learning)
-
Environment properties (observability, determinism, dynamics, continuity, episodicity, multi-agent)
Search
-
Breadth-First Search (complete, optimal if uniform cost, O(bᵈ) space/time)
-
Depth-First Search (not complete for infinite trees, not optimal, O(bm) space)
-
Iterative Deepening (complete, optimal, O(bd) space, O(bᵈ) time)
-
Uniform Cost Search (complete, optimal, priority queue)
-
Heuristics: admissible, consistent
-
A* algorithm: f = g + h, optimal if h admissible/consistent
-
Hill climbing, simulated annealing (accept worse moves with decreasing probability)
-
Minimax with alpha-beta pruning (O(bᵈ/²) best case)
Knowledge & Logic
-
Propositional logic: connectives, truth tables, resolution
-
First-Order Logic: constants, variables, functions, predicates, quantifiers (∀, ∃)
-
Unification and substitution
-
Forward/backward chaining, resolution refutation
Uncertainty
-
Bayes’ rule: P(A|B) = P(B|A)P(A)/P(B)
-
Bayesian networks: DAG + CPTs, conditional independence
-
Naïve Bayes classifier
Machine Learning
-
Supervised vs. unsupervised vs. reinforcement learning
-
Train/test split, cross-validation (k-fold)
-
Metrics: accuracy, precision, recall, F1, ROC-AUC
-
Bias-variance tradeoff, overfitting vs. underfitting
-
k-NN, decision trees, linear/logistic regression, SVM, neural networks basics
-
k-means, PCA
Reinforcement Learning
-
MDP: S, A, P, R, γ, π
-
Value function V(s) vs. Q(s,a)
-
Bellman optimality equations
-
Q-learning update: Q(s,a) ← Q + α[r + γ max Q(s’,a’) – Q(s,a)]
-
Exploration vs. exploitation (ε-greedy)
Computer Networks (Core) – Comprehensive Study Notes
These notes cover the essential concepts of computer networking, from fundamental principles to advanced topics. The content is designed for undergraduate and graduate students in computer science, information technology, and related fields, with practical insights for implementation and troubleshooting.
Part 1: Foundations of Computer Networks
1.1 What is a Computer Network?
A computer network is a system of interconnected computing devices (computers, servers, printers, IoT devices, etc.) that can communicate and share resources with each other through communication protocols over wired or wireless connections.
Key Insight: The fundamental purpose of a network is to enable resource sharing, improve communication speed and reliability, increase cost efficiency, and enhance security through centralized management.
1.2 Why Study Computer Networks?
The key advantages of computer networks include:
| Advantage | Description |
|---|---|
| Resource Sharing | Hardware (printers, scanners) and software can be shared among multiple users |
| Communication | Email, messaging, video conferencing, and collaboration tools |
| Centralized Management | Easier administration, software updates, and backups |
| Cost Efficiency | Sharing expensive resources reduces overall costs |
| Scalability | Networks can grow from small to large seamlessly |
| Reliability | Redundancy and alternative communication paths |
| Security | Centralised security policies and access control |
1.3 Basic Terminology
| Term | Definition |
|---|---|
| Node | Any device connected to a network (computer, printer, router) |
| Host | Any device that sends or receives data (often synonymous with node) |
| Link | Physical or logical communication pathway connecting nodes |
| Bandwidth | Maximum data transfer rate (usually in bits per second) |
| Throughput | Actual rate at which data is successfully transferred |
| Latency | Time delay between sending and receiving data |
| Protocol | A set of rules governing communication between devices |
| Packet | A unit of data formatted for transmission across a network |
| Topology | Physical or logical arrangement of nodes and links |
Part 2: Network Classification
2.1 By Geography (Scale)
| Type | Full Form | Geographic Span | Typical Speed | Example |
|---|---|---|---|---|
| PAN | Personal Area Network | Within a person’s reach (few meters) | Low (1-10 Mbps) | Bluetooth headset, phone-watch connection |
| LAN | Local Area Network | Single building or campus (up to few km) | High (100 Mbps – 100 Gbps) | Office network, school computer lab |
| MAN | Metropolitan Area Network | City-wide (5-50 km) | Medium-high | Cable TV network, city wifi |
| WAN | Wide Area Network | Country or continent-wide (100-1000+ km) | Varies (links slower than LAN) | The Internet itself |
| GAN | Global Area Network | Planet-wide (satellite) | Varies | Satellite communication systems |
2.2 By Network Architecture
| Type | Description | Advantages | Disadvantages |
|---|---|---|---|
| Peer-to-Peer (P2P) | All computers are equal; each can act as client and server | No dedicated server required; simple; inexpensive | Poor security; difficult to manage beyond 10-12 computers |
| Client-Server | Dedicated server(s) provide services; clients request them | Centralised management; better security; scalable | Higher cost; single point of failure risk |
2.3 By Topology
Network topology refers to the physical or logical arrangement of nodes and links.
| Topology | Diagram Description | Advantages | Disadvantages | Common Use |
|---|---|---|---|---|
| Bus | Single central cable (backbone) with tap connections | Simple; cheap; easy to extend | Single point of failure; collisions common | Obsolete (except in some industrial) |
| Star | All nodes connect to central hub/switch | Easy to troubleshoot; robust (one node fails, others work) | Central hub is single point of failure | Most common in LANs |
| Ring | Each node connects to two others in a circle | Efficient; predictable performance | Single break breaks entire network; complex reconfiguration | Partial in SONET/SDH |
| Mesh | Each node connects to multiple others | Highly redundant; fault-tolerant | Expensive; complex wiring | WAN backbones; military |
| Tree (Hierarchical) | Root node with branches; parent-child relationships | Scalable; easy to manage | Root node failure affects many | Large organisations |
| Hybrid | Combination of two or more topologies | Flexible; combines benefits | Complex design and management | Large enterprise networks |
2.4 By Transmission Medium
| Type | Description | Examples |
|---|---|---|
| Wired Networks | Use physical cables for transmission | Twisted pair (Ethernet), Coaxial cable, Fiber optic |
| Wireless Networks | Use electromagnetic waves for transmission | Wi-Fi, Bluetooth, Cellular (4G/5G), Satellite |
Part 3: The OSI Reference Model
The Open Systems Interconnection (OSI) model is a conceptual framework standardised by the International Organization for Standardization (ISO) to understand and design network communication .
3.1 The Seven Layers (Bottom to Top)
| Layer | Name | Function | Data Unit | Example Protocols/Devices |
|---|---|---|---|---|
| 7 | Application | Network services to user applications | Data | HTTP, SMTP, FTP, DNS, Telnet |
| 6 | Presentation | Data translation, encryption, compression | Data | SSL/TLS, JPEG, MPEG, ASCII, EBCDIC |
| 5 | Session | Session management, authentication, checkpointing | Data | NetBIOS, RPC, PPTP, SMB |
| 4 | Transport | End-to-end delivery, reliability, flow control | Segment (TCP) / Datagram (UDP) | TCP, UDP, SCTP |
| 3 | Network | Routing, logical addressing, path determination | Packet | IP, ICMP, IGMP, ARP (often associated), Routers |
| 2 | Data Link | Node-to-node delivery, error detection, framing | Frame | Ethernet, Wi-Fi (802.11), PPP, Switches, Bridges |
| 1 | Physical | Transmission of raw bits over medium | Bits (1/0) | Cables, Hubs, Repeaters, Modems |
3.2 Mnemonic to Remember the Layers (Bottom to Top)
“Please Do Not Throw Sausage Pizza Away”
-
Physical
-
Data Link
-
Network
-
Transport
-
Session
-
Presentation
-
Application
Top to Bottom Mnemonic: “All People Seem To Need Data Processing”
3.3 Key Characteristics of the OSI Model
| Characteristic | Description |
|---|---|
| Layer Independence | Each layer provides services to the layer above |
| Encapsulation | Each layer adds its own header (and sometimes trailer) to data |
| Peer Communication | Each layer communicates logically with its peer layer on another device |
| Standardisation | Allows different vendors’ equipment to interoperate |
| Modularity | Easier to develop, debug, and maintain |
3.4 Encapsulation Process (Data Flow)
When data travels down the OSI stack on the sending device:
Application (Layer 7) : [User Data] Presentation (Layer 6) : [Data] (may add formatting) Session (Layer 5) : [Data] (may add session info) Transport (Layer 4) : [TCP/UDP Header] + [Data] → Segment/Datagram Network (Layer 3) : [IP Header] + [Segment/Datagram] → Packet Data Link (Layer 2) : [MAC Header] + [Packet] + [FCS Trailer] → Frame Physical (Layer 1) : Bits onto medium
The receiving device reverses this process, stripping headers at each layer until the original data reaches the application.
3.5 OSI vs. TCP/IP Model
The OSI model is theoretical and pedagogical. The TCP/IP model is the practical implementation used on the Internet .
| OSI Layer | TCP/IP Model (4 layers) | Protocols |
|---|---|---|
| Application (7), Presentation (6), Session (5) | Application Layer | HTTP, FTP, SMTP, DNS |
| Transport (4) | Transport Layer | TCP, UDP |
| Network (3) | Internet Layer | IP, ICMP, ARP |
| Data Link (2), Physical (1) | Network Access (Link) Layer | Ethernet, Wi-Fi, PPP |
Part 4: Transmission Media
4.1 Classification
| Category | Types | Characteristics |
|---|---|---|
| Guided (Wired) | Twisted Pair, Coaxial, Fiber Optic | Physical cable; secure; higher speeds; limited distance |
| Unguided (Wireless) | Radio waves, Microwaves, Infrared | No physical cable; convenient; subject to interference |
4.2 Detailed Comparison of Guided Media
| Medium | Bandwidth | Max Distance | Cost | Interference Susceptibility | Security | Common Use |
|---|---|---|---|---|---|---|
| Twisted Pair (UTP/STP) | Up to 10 Gbps | 100 meters (for Gigabit) | Low | High (without shielding) | Low | LAN, telephone |
| Coaxial Cable | Up to 1 Gbps | 500 meters (thicknet) | Medium | Medium | Medium | Cable TV, broadband |
| Fiber Optic (Multimode) | Up to 100 Gbps | 2 km | High | Very low | High | Building backbones |
| Fiber Optic (Singlemode) | Up to 400+ Gbps | 40-80+ km | Very high | Very low | Very high | Long-haul WAN |
UTP/STP Difference:
-
UTP (Unshielded Twisted Pair): No shielding; cheaper but more interference (Cat5e, Cat6)
-
STP (Shielded Twisted Pair): Has shielding; more expensive but better noise immunity (Cat6a, Cat7)
4.3 Ethernet Cable Categories (UTP)
| Category | Max Bandwidth | Max Frequency | Typical Use |
|---|---|---|---|
| Cat5e | 1 Gbps | 100 MHz | Home networking (older installations) |
| Cat6 | 1 Gbps (55m), 10 Gbps (33m) | 250 MHz | Enterprise networks |
| Cat6a | 10 Gbps (100m) | 500 MHz | Data centers, high-speed networks |
| Cat7 | 10 Gbps (100m) | 600 MHz | Shielded; data centers (not standardised by TIA) |
| Cat8 | 25-40 Gbps | 2000 MHz | Short-range data center connections (30m max) |
4.4 Wireless Media
| Type | Frequency Range | Range | Data Rate | Characteristics |
|---|---|---|---|---|
| Radio Waves (Wi-Fi) | 2.4 GHz, 5 GHz, 6 GHz | 30-100m (indoors) | Up to several Gbps | Penetrates walls; subject to interference |
| Bluetooth | 2.4 GHz | 10-100m | Up to 3 Mbps (Classic) to 50+ Mbps (LE) | Short-range device connection |
| Cellular (4G/5G) | 600 MHz – 39 GHz | Kilometers (cell tower) | 10 Mbps (4G) to 10 Gbps (5G under ideal) | Wide-area mobile communication |
| Satellite | 1-40 GHz | Global | 10-100+ Mbps | Remote areas, broadcasting |
| Infrared | 300 GHz – 400 THz | 10m (line-of-sight) | Up to 100 Mbps | Remote controls, short-range (nearly obsolete) |
Part 5: The TCP/IP Protocol Suite
5.1 Internet Protocol (IP)
IP (Internet Protocol) is the principal communications protocol for relaying datagrams across network boundaries. It is responsible for addressing and routing packets from source to destination .
IP Versions:
| Feature | IPv4 | IPv6 |
|---|---|---|
| Address Size | 32 bits | 128 bits |
| Address Format | Dotted decimal (192.168.1.1) | Hexadecimal (2001:0db8:85a3:0000:0000:8a2e:0370:7334) |
| Number of Addresses | ~4.3 billion | 3.4 × 10³⁸ |
| Header Size | 20-60 bytes | 40 bytes fixed |
| Security | Optional (IPsec extension) | Built-in IPsec |
| Configuration | Manual or DHCP | Stateless Address Autoconfiguration (SLAAC) or DHCPv6 |
IPv4 Address Structure:
-
32 bits divided into 4 octets (8 bits each)
-
Example:
192.168.1.1=11000000 10101000 00000001 00000001
5.2 IPv4 Address Classes (Historically)
| Class | Leading Bits | First Octet Range | Subnet Mask | Network Bits | Host Bits |
|---|---|---|---|---|---|
| A | 0 | 1-126 | 255.0.0.0 (or /8) | 8 | 24 |
| B | 10 | 128-191 | 255.255.0.0 (or /16) | 16 | 16 |
| C | 110 | 192-223 | 255.255.255.0 (or /24) | 24 | 8 |
| D (Multicast) | 1110 | 224-239 | N/A | N/A | N/A |
| E (Reserved) | 1111 | 240-255 | N/A | N/A | N/A |
Note: Classful addressing is obsolete (replaced by CIDR since 1993). The network/host boundary is now defined by the subnet mask (CIDR notation: 192.168.1.0/24).
5.3 Special IPv4 Addresses
| Address Range | Purpose |
|---|---|
| 0.0.0.0/8 | “This” network (source address only) |
| 127.0.0.0/8 (127.0.0.1) | Loopback (localhost)—packets never leave device |
| 169.254.0.0/16 | Link-local (APIPA)—automatic configuration when DHCP fails |
| 224.0.0.0/4 | Multicast addresses |
| 255.255.255.255 | Limited broadcast (local network only) |
Private IP Addresses (Not Routable on Internet):
| Class | Address Range | CIDR | Number of Addresses |
|---|---|---|---|
| A | 10.0.0.0 – 10.255.255.255 | 10.0.0.0/8 | 16,777,216 |
| B | 172.16.0.0 – 172.31.255.255 | 172.16.0.0/12 | 1,048,576 |
| C | 192.168.0.0 – 192.168.255.255 | 192.168.0.0/16 | 65,536 |
Network Address Translation (NAT): Translates private IP addresses to public IP address(es) for Internet access. Conserves public IPv4 addresses and adds security by hiding internal network structure.
5.4 Subnetting and CIDR
Subnetting: Dividing a single IP network into smaller subnetworks (subnets) to improve performance, security, and manageability.
CIDR (Classless Inter-Domain Routing): Uses a slash notation (e.g., /24) to specify network prefix length, replacing classful addressing.
Subnet Mask Calculation Example:
-
Network:
192.168.1.0/24 -
Subnet mask:
255.255.255.0(24 bits network, 8 bits host) -
Usable hosts: 2⁸ – 2 = 254 (network address + broadcast address subtracted)
Key Subnetting Formulas:
-
Number of subnets: 2ⁿ (where n = number of borrowed bits)
-
Number of hosts per subnet: 2ᵐ – 2 (where m = remaining host bits)
-
Block size (increment): 256 – (last non-zero octet of mask)
5.5 Transmission Control Protocol (TCP)
TCP is a connection-oriented, reliable transport layer protocol that ensures data is delivered error-free and in order .
Key TCP Features:
| Feature | Description |
|---|---|
| Connection-Oriented | Three-way handshake establishes connection before data transfer |
| Reliable | Acknowledgements and retransmissions guarantee delivery |
| In-Order Delivery | Sequence numbers allow reordering of out-of-order packets |
| Flow Control | Sliding window prevents sender from overwhelming receiver |
| Congestion Control | Algorithms (Slow Start, Congestion Avoidance) prevent network collapse |
| Error Detection | Checksum validates header and data integrity |
TCP Three-Way Handshake:
Client Server | | |------ SYN (seq=x) ------------>| | | |<--- SYN-ACK (seq=y, ack=x+1)---| | | |------ ACK (ack=y+1) ---------->| | |
TCP Segments: Maximum Segment Size (MSS) is the maximum data payload a TCP segment can carry (usually MTU minus IP header minus TCP header).
5.6 User Datagram Protocol (UDP)
UDP is a connectionless, unreliable transport layer protocol with minimal overhead .
Key UDP Features:
| Feature | Description |
|---|---|
| Connectionless | No handshake; send immediately |
| Unreliable | No acknowledgements or retransmissions |
| No Ordering | Packets may arrive out of order |
| Low Overhead | Only 8-byte header (vs 20+ bytes for TCP) |
| No Congestion Control | Sends regardless of network conditions |
When to Use UDP:
-
Real-time applications (VoIP, video streaming, online gaming) where speed matters more than perfect reliability
-
DNS queries (short request-response)
-
DHCP, SNMP, TFTP
-
Broadcasting/multicasting
5.7 TCP vs. UDP Comparison
| Feature | TCP | UDP |
|---|---|---|
| Connection | Connection-oriented | Connectionless |
| Reliability | Reliable (ACKs, retransmissions) | Unreliable (no ACKs) |
| Ordering | In-order delivery guaranteed | No ordering |
| Flow Control | Yes (sliding window) | No |
| Congestion Control | Yes | No |
| Error Checking | Yes (checksum) | Yes (checksum only) |
| Header Size | 20-60 bytes | 8 bytes |
| Speed | Slower | Faster |
| Applications | Web (HTTP), Email (SMTP), File (FTP), SSH | VoIP, Video streaming, DNS, DHCP |
5.8 Key Application Layer Protocols
| Protocol | Port | Transport | Purpose |
|---|---|---|---|
| HTTP | 80 | TCP | Web browsing (unencrypted) |
| HTTPS | 443 | TCP | Secure web browsing (encrypted) |
| FTP | 20 (data), 21 (control) | TCP | File transfer |
| SSH | 22 | TCP | Secure remote access, file transfer |
| Telnet | 23 | TCP | Unsecure remote access (obsolete) |
| SMTP | 25 | TCP | Email sending |
| POP3 | 110 | TCP | Email retrieval (basic) |
| IMAP | 143 | TCP | Email retrieval (advanced) |
| DNS | 53 | UDP (mostly), TCP (zone transfers) | Domain name resolution |
| DHCP | 67 (server), 68 (client) | UDP | Dynamic IP configuration |
| SNMP | 161 | UDP | Network management |
| NTP | 123 | UDP | Time synchronisation |
| SMB/CIFS | 445 | TCP | Windows file sharing |
| RDP | 3389 | TCP | Remote Desktop Protocol |
Part 6: Network Devices
6.1 Classification by OSI Layer
| Device | OSI Layer | Function | Intelligence |
|---|---|---|---|
| Hub | Physical (Layer 1) | Repeats signal to all ports | None |
| Repeater | Physical (Layer 1) | Regenerates signal to extend distance | None |
| Bridge | Data Link (Layer 2) | Connects two network segments; filters based on MAC addresses | Basic |
| Switch | Data Link (Layer 2) or Multilayer | Forwards frames based on MAC address table (L2) | Significant |
| Router | Network (Layer 3) | Forwards packets based on IP address; connects different networks | High |
| Gateway | Application (Layer 7) | Translates between different protocols | Very high |
| Modem | Physical (Layer 1/2) | Converts digital to analog for phone/cable lines | Basic |
| Access Point (AP) | Data Link (Layer 2) | Connects wireless devices to wired network | Moderate |
6.2 Detailed Switch vs. Router Comparison
| Feature | Switch (Layer 2) | Router (Layer 3) |
|---|---|---|
| Address Type | MAC address (physical) | IP address (logical) |
| Forwarding Decision | Based on MAC address table | Based on routing table |
| Network Scope | Single network segment/broadcast domain | Connects different networks |
| Broadcast Handling | Forwards broadcasts within VLAN | Does not forward broadcasts |
| Traffic Isolation | VLANs can create separate networks | Naturally separates networks |
| Performance | Generally higher (hardware switching) | Lower (software routing or slower hardware) |
| Security | Limited (MAC filtering, VLANs) | Strong (ACLs, NAT, firewall features) |
6.3 VLANs (Virtual LANs)
VLANs logically segment a physical switch into multiple isolated networks at Layer 2 .
Benefits:
-
Improved security (traffic segregation)
-
Better performance (reduced broadcast domains)
-
Flexibility (users can be grouped by function, not physical location)
-
Cost savings (fewer physical switches needed)
VLAN Tagging (802.1Q): Adds a 4-byte tag to Ethernet frames to identify VLAN membership when multiple VLANs share the same trunk link.
6.4 Firewalls
Firewalls are network security devices that monitor and control incoming/outgoing traffic based on predefined rules .
| Type | OSI Layer | Operation | Performance |
|---|---|---|---|
| Packet Filtering | Layer 3-4 | Inspects headers (IP addresses, ports, protocol) | Fast |
| Stateful Inspection | Layer 3-4 | Tracks connection state; allows return traffic | Slower but more secure |
| Application (Proxy) | Layer 7 | Deep packet inspection for specific applications | Slowest, most secure |
| Next-Generation (NGFW) | Layers 3-7 | Combines stateful inspection with application awareness, IPS, etc. | Moderate to fast |
Deployment Modes:
-
Network-based: Hardware appliance protecting entire network
-
Host-based: Software firewall on individual device (Windows Defender, iptables)
-
Cloud-based: Firewall-as-a-Service (FWaaS) for cloud environments
Part 7: Network Security Fundamentals
7.1 Core Security Goals (CIA Triad)
| Goal | Definition | Example |
|---|---|---|
| Confidentiality | Data is accessible only to authorised parties | Encryption (SSL/TLS), access controls |
| Integrity | Data is not altered in transit | Hashing, checksums, digital signatures |
| Availability | Systems and data are accessible when needed | Redundancy, DDoS protection, backups |
7.2 Common Network Attacks
| Attack | Description | Mitigation |
|---|---|---|
| DDoS (Distributed Denial of Service) | Overwhelm target with traffic from multiple sources | Rate limiting, traffic filtering, CDN, specialised DDoS protection |
| Man-in-the-Middle (MitM) | Attacker intercepts communication between two parties | Encryption (TLS/SSL), mutual authentication |
| ARP Spoofing | Attacker sends fake ARP replies to associate their MAC with legitimate IP | Dynamic ARP inspection (DAI), static ARP entries |
| DNS Spoofing | Attacker corrupts DNS cache or responses | DNSSEC, secure DNS (DoH, DoT) |
| Phishing | Trick user into revealing credentials via fake communication | User awareness training, email filtering, MFA |
| Packet Sniffing | Capturing unencrypted network traffic | Encryption (TLS/VPN), switched networks (not hubs) |
| Replay Attack | Capturing and retransmitting valid data transmission | Timestamps, nonces, sequence numbers |
7.3 Essential Security Technologies
| Technology | Purpose | Standard/Protocol |
|---|---|---|
| IPsec | Encrypt IP packets (VPNs) | IPsec (AH, ESP, IKE) |
| SSL/TLS | Encrypt web traffic | HTTPS, SSL/TLS 1.2/1.3 |
| SSH | Secure remote access | TCP port 22 |
| VPN | Extend private network over public internet | IPsec, OpenVPN, WireGuard |
| 802.1X | Port-based network access control | EAP, RADIUS |
| WPA3 | Secure Wi-Fi encryption | Replaces WPA2 (deprecates WEP, TKIP) |
| Firewall | Traffic filtering | Stateful inspection, NGFW |
7.4 Network Access Control (NAC)
NAC ensures that only compliant, authenticated devices can connect to the network. Uses:
-
802.1X authentication (port-based)
-
RADIUS (Remote Authentication Dial-In User Service) – centralises authentication
-
Endpoint compliance checks (antivirus, OS patches)
7.5 Zero Trust Model
The Zero Trust security model assumes no implicit trust, even within the network perimeter. Key principles :
-
Never trust, always verify (all access is authenticated and authorised)
-
Least privilege access (users get only necessary access)
-
Micro-segmentation (isolating workloads)
-
Continuous monitoring (real-time inspection)
Part 8: Essential Protocols in Detail
8.1 Address Resolution Protocol (ARP)
ARP maps IP addresses to MAC addresses within a local network .
ARP Operation:
-
Host sends ARP broadcast (“Who has IP address 192.168.1.1?”)
-
Host with that IP replies with its MAC address
-
Sender caches the mapping for future use
ARP Issues:
-
ARP spoofing/poisoning: Attacker sends fake ARP replies to associate their MAC with a legitimate IP
-
ARP is unauthenticated – no verification that reply is legitimate
8.2 Dynamic Host Configuration Protocol (DHCP)
DHCP automatically assigns IP addresses and configuration to devices .
DHCP Operations (DORA Process):
| Step | Packet Type | Direction | Description |
|---|---|---|---|
| 1 | Discover | Client → Server | Client broadcasts” “I need an IP” |
| 2 | Offer | Server → Client | Server offers available IP address |
| 3 | Request | Client → Server | Client accepts the offer |
| 4 | Acknowledgment | Server → Client | Server confirms lease details |
Lease Duration:
-
Default: Several hours to days
-
Renewal: Client attempts to renew at 50% of lease time
8.3 Domain Name System (DNS)
DNS translates human-readable domain names (www.example.com) to IP addresses (192.0.2.1).
DNS Hierarchy:
Root (.) → Top-Level Domains (TLD: .com, .org, .pk) → Second-Level (example.com) → Subdomain (www.example.com)
DNS Resolution Types:
-
Recursive query: DNS server finds answer on client’s behalf (common)
-
Iterative query: Client follows referrals to each authoritative server
DNS Record Types:
| Record | Purpose | Example |
|---|---|---|
| A | IPv4 address | example.com → 93.184.216.34 |
| AAAA | IPv6 address | example.com → 2606:2800:220:1:248:1893:25c8:1946 |
| CNAME | Canonical name (alias) | www.example.com → example.com |
| MX | Mail exchange server | example.com → mail.example.com (priority 10) |
| NS | Name server | example.com → ns1.example.com |
| PTR | Reverse lookup (IP → name) | 34.216.184.93.in-addr.arpa → example.com |
| TXT | Text information (SPF, verification) | “v=spf1 include:_spf.google.com ~all” |
8.4 Internet Control Message Protocol (ICMP)
ICMP is used for error reporting and diagnostic functions, primarily via ping and traceroute.
Common ICMP Message Types:
| Type | Code | Description |
|---|---|---|
| 0 | 0 | Echo Reply (ping response) |
| 3 | 0-15 | Destination Unreachable (network, host, port, protocol, etc.) |
| 8 | 0 | Echo Request (ping) |
| 11 | 0 | Time Exceeded (TTL expired in transit; used by traceroute) |
Part 9: Wireless Networking
9.1 Wi-Fi Standards (IEEE 802.11)
| Standard | Frequency | Max Data Rate (theoretical) | Range (indoor) | Key Features |
|---|---|---|---|---|
| 802.11b | 2.4 GHz | 11 Mbps | 35m | Obsolete |
| 802.11a | 5 GHz | 54 Mbps | 35m | Obsolete |
| 802.11g | 2.4 GHz | 54 Mbps | 35m | Obsolete |
| 802.11n (Wi-Fi 4) | 2.4/5 GHz | 600 Mbps | 70m | MIMO introduced |
| 802.11ac (Wi-Fi 5) | 5 GHz | 3.5 Gbps | 70m | MU-MIMO, beamforming |
| 802.11ax (Wi-Fi 6/6E) | 2.4/5/6 GHz | 9.6 Gbps | 70m+ | OFDMA, better efficiency, 6E adds 6 GHz band |
| 802.11be (Wi-Fi 7) | 2.4/5/6 GHz | 46 Gbps | Similar | 320 MHz channels, 16 streams (emerging) |
9.2 Wi-Fi Security
| Protocol | Status | Key Features | Weaknesses |
|---|---|---|---|
| WEP | Obsolete (1999-2004) | RC4 encryption, 40/104-bit keys | Easily cracked (weak RC4, IV reuse) |
| WPA | Obsolete (2003-2018) | TKIP encryption (still RC4-based) | Vulnerable to KRACK; deprecated |
| WPA2 | Still used but superseded | AES-CCMP (strong encryption), 4-way handshake | Vulnerable to KRACK; requires PMF |
| WPA3 | Current standard (2018-) | SAE (instead of PSK) strengthens password security; GCMP-256 (optional) | Widespread AP/device support still limited |
| WPA3-Enterprise | Current standard | 192-bit encryption (GCMP-256), more secure authentication | Higher complexity |
Wi-Fi Security Best Practices:
-
Use WPA3 (or WPA2 if WPA3 unavailable)
-
Disable WPS (Wi-Fi Protected Setup) – known vulnerability
-
Use strong, complex passwords
-
Enable PMF (Protected Management Frames) where supported
-
Implement 802.1X for enterprise environments
9.3 Wireless Network Modes
| Mode | Description | Use Case |
|---|---|---|
| Infrastructure | Devices connect to Access Point (AP) | Most home/office networks |
| Ad-Hoc (IBSS) | Devices connect directly peer-to-peer | Temporary connections |
| Mesh | Multiple APs cooperate to provide coverage | Large areas, outdoor, smart homes |
| Repeater/Wireless Range Extender | Extends coverage of existing network | Dead zones in home/office |
Part 10: Key Terms and Concepts (Glossary)
| Term | Definition |
|---|---|
| Bandwidth | Maximum data transfer capacity of a network/link (bits per second) |
| Throughput | Actual data transfer rate achieved |
| Latency | Delay between sending and receiving data |
| Jitter | Variation in packet arrival times (important for real-time applications) |
| MTU (Maximum Transmission Unit) | Largest packet/frame size that can be transmitted (typically 1500 bytes for Ethernet) |
| MAC Address | 48-bit unique identifier assigned to network interfaces |
| IP Address | Logical address identifying device on network |
| Subnet Mask | Defines network and host portions of IP address |
| Default Gateway | Router that connects a network to other networks (usually to Internet) |
| Broadcast | Packet sent to all devices on a network |
| Multicast | Packet sent to specific group of devices |
| Unicast | Packet sent to single specific device |
| NAT (Network Address Translation) | Translates private IPs to public IP(s); enables multiple devices to share single public IP |
| Port Forwarding | Directs external traffic to specific internal IP and port |
| DMZ (Demilitarised Zone) | Network segment exposed to Internet; isolates public-facing servers |
| PoE (Power over Ethernet) | Delivers power and data over same Ethernet cable |
| QoS (Quality of Service) | Prioritises certain traffic types over others |
| VLAN | Logical segmentation of physical network |
| Trunk | Link carrying traffic for multiple VLANs (802.1Q tagging) |
| Access Port | Switch port carrying single VLAN |
| STP (Spanning Tree Protocol) | Prevents network loops in redundant topologies |
| CDP/LLDP | Cisco Discovery Protocol / Link Layer Discovery Protocol – neighbour discovery |
| ARP | Maps IP addresses to MAC addresses within local network |
| TTL (Time To Live) | Limits packet lifetime (prevents routing loops); also determines hop count in traceroute |
| RTT (Round Trip Time) | Time for packet to travel to destination and back |
| Three-Way Handshake | TCP connection establishment (SYN, SYN-ACK, ACK) |
| TCP Flags | SYN, ACK, FIN, |
Software Engineering – Detailed Study Notes
These notes provide a comprehensive overview of software engineering, covering the software development lifecycle, process models, requirements engineering, design principles, testing, maintenance, project management, and quality assurance. These notes are designed for computer science and software engineering students.
Part A: Foundations of Software Engineering
Unit 1: Introduction to Software Engineering
1.1 Definition and Scope
Software Engineering is the systematic application of engineering principles, methods, and tools to the development, operation, and maintenance of software.
Key definitions (IEEE, 1990):
-
The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software (engineering).
-
The study of approaches as in (1).
1.2 Difference Between Programming and Software Engineering
| Aspect | Programming (Coding) | Software Engineering |
|---|---|---|
| Focus | Writing code to solve immediate problem | Entire lifecycle: requirements, design, coding, testing, deployment, maintenance |
| Scale | Small programs (single developer or small team) | Large systems (many developers, often distributed teams) |
| Process | Informal, ad‑hoc | Formalised, documented, repeatable processes (e.g., agile, waterfall, spiral) |
| Quality | Correctness (does it work?) | Correctness, reliability, maintainability, scalability, security, usability, performance, safety |
| Risk management | Minimal | Planned risk assessment and mitigation (technical, schedule, budget, personnel, security) |
| Documentation | May be minimal (comments in code) | Comprehensive requirements, design, test plans, user manuals, maintenance guides |
| Team structure | Individual or few programmers | Cross‑functional teams (analysts, architects, developers, testers, QA, project managers, technical writers, DevOps). |
1.3 Software Crisis and Emergence of Software Engineering
Software Crisis (late 1960s): Inability to develop large, reliable, cost‑effective software systems on time and within budget.
Symptoms:
-
Projects over budget and behind schedule
-
Low reliability and frequent failures
-
High maintenance costs (often exceeding development costs)
-
Difficulty in accommodating changing requirements (software rot)
-
“The mythical man‑month” – adding more programmers to late project makes it later (Brooks’ law).
Response: 1968 NATO Conference on Software Engineering coined the term “software engineering”. Emergence of structured programming, software lifecycle models, formal methods, project management disciplines.
1.4 Software Quality Attributes (ISO/IEC 25010 – Quality Model)
| Quality Attribute | Description | Measure / Example |
|---|---|---|
| Functional suitability | Degree to which software meets stated and implied needs (correctness, completeness, correctness of results). | Number of defects found in testing; accuracy of calculated results. |
| Reliability | Ability to perform required functions under stated conditions for specified period. | Mean time between failures (MTBF), mean time to recovery (MTTR) after failure, probability of failure‑free operation. |
| Performance efficiency | Performance relative to amount of resources used under stated conditions. | Response time (seconds), throughput (transactions/sec), memory usage (MB), CPU utilisation (%). |
| Usability | Ease of use, learnability, user satisfaction. | Task completion time, error rate, system usability scale (SUS) score, user satisfaction survey. |
| Security | Protection of information and data from unauthorised access, confidentiality, integrity, availability. | Number of vulnerabilities (penetration testing), compliance with security standards (ISO 27001, NIST), time to patch vulnerabilities. |
| Compatibility | Ability to exchange information with other systems and perform required functions in shared environment. | Number of API integration failures, interoperability certification. |
| Maintainability | Ease of modification to correct faults, improve performance, or adapt to changed environment. | Cyclomatic complexity, code duplication percentage, time to fix a bug, effort to implement new feature (person‑hours). |
| Portability | Ability to be transferred from one hardware/software environment to another. | Effort to port (person‑days), number of platform‑specific code changes (if any). |
Unit 2: Software Development Life Cycle (SDLC)
2.1 Generic SDLC Phases
| Phase | Activities | Artifacts (Documents/Outputs) |
|---|---|---|
| Requirements Engineering (Analysis). | Elicit, analyse, specify, validate, manage requirements | Business requirements document (BRD), software requirements specification (SRS), use case diagrams, user stories, acceptance criteria |
| Design | Architecture design (high‑level), detailed design (low‑level), database design, user interface design | Software design document (SDD), architecture diagrams (UML component, deployment), class diagrams, sequence diagrams, database schema (ER diagram), API specifications |
| Implementation (Coding) | Write source code according to design standards, perform unit testing, conduct code reviews, configure version control | Source code (in repository), unit test suite (JUnit, pytest, Mocha), build scripts (Maven, Gradle, Cargo), code review comments |
| Testing | Integration testing, system testing, acceptance testing, performance testing, security testing | Test plan, test cases, defect reports, test summary report |
| Deployment | Prepare release, install in production environment, migrate data, verify successful deployment | Release notes, installation guide, deployment script, verification test results |
| Maintenance | Corrective (bug fixes), adaptive (environment changes), perfective (enhancements), preventive (future issues). | Change requests, maintenance logs, updated documentation |
2.2 Software Process Models
| Model | Description | When to Use | Advantages | Disadvantages |
|---|---|---|---|---|
| Waterfall | Linear sequential phases: requirements → design → implementation → testing → deployment → maintenance. Each phase completes before next begins (no overlap). | Requirements are well‑understood, stable, unlikely to change; project is short; team not large. | Simple, easy to understand, clear milestones, enforces discipline, produces documentation at each phase. | Inflexible to requirement changes (requires returning to earlier phase), user sees product only at end, risk of building wrong product if requirements misunderstood. |
| V‑Model | Extension of waterfall; testing phases paired with development phases (unit testing with coding, integration testing with detailed design, system testing with high‑level design, acceptance testing with requirements). | Life‑critical systems, safety‑critical (aerospace, medical devices) where verification and validation are required at each stage. | Emphasises verification and validation, test planning occurs early, high quality. | Same rigidity as waterfall, more documentation overhead. |
| Iterative (Incremental) | Build system in small increments; each increment adds functionality tested and delivered; repeat until complete. | Large system that can be partitioned; unclear requirements but can be defined incrementally; early delivery of subset needed. | Early partial product (reduces risk), easier to incorporate feedback, manageable increments. | Overall architecture must be designed upfront; increments may be incomplete. |
| Spiral (Boehm, 1988). | Risk‑driven model: each iteration (loop) includes (1) determine objectives/alternatives/constraints, (2) identify and resolve risks, (3) develop and verify next‑level product, (4) plan next iteration. | Large, complex, high‑risk projects where requirements are uncertain. | Explicit risk management, adapts to changes, can incorporate other models (waterfall, prototyping) within loops. | Complex (requires risk assessment expertise), costly, may over‑emphasise documentation. |
| Prototyping | Build simplified working model (prototype) to clarify requirements, gather user feedback, refine requirements, then develop final product. | Unclear user requirements, novel systems, user interface intensive (UI/UX). | Clarifies requirements, reduces misinterpretation, improves user satisfaction, detects errors early. | May lead to “throwaway prototype” with schedule pressure to use incomplete prototype as final product; user expectations may be unrealistic. |
| Agile (e.g., Scrum, Kanban, XP). | Iterative, incremental, collaborative; adaptive planning, empirical process control; cross‑functional teams; deliver working software frequently (2‑4 weeks). | Projects with changing requirements, high customer involvement, small to medium teams, dynamic market. | Responds quickly to changes, high customer satisfaction, early and continuous delivery of value, minimal bureaucracy. | Less predictable (no fixed plan), requires high customer and team engagement, may lack documentation (technical debt). |
Part B: Requirements Engineering
Unit 3: Requirements Engineering (RE)
3.1 Requirements Types
| Type | Description | Example |
|---|---|---|
| Functional Requirements | Describe what the system must do (behaviour, functions, calculations, data processing). | “The system shall compute tax based on user’s income and deductions using the following formula: Tax = (Income – Deductions) × 0.30 – Tax Credits.” |
| Non‑Functional Requirements (quality attributes). | Describe how the system performs its functions (constraints on behaviour). | “The system shall respond to search queries in less than 2 seconds for 95% of requests under peak load (10,000 concurrent users).” |
| Domain Requirements | Constraints derived from the application domain (laws, regulations, standards, business rules). | “The system must comply with GDPR (General Data Protection Regulation) regarding storage of personal data (right to erasure, data portability).” |
| User Requirements | High‑level statements from user perspective (natural language, use cases, user stories). | “As a registered customer, I want to view my order history so that I can track previous purchases.” |
| System Requirements | Detailed specification of system behaviour (structured, often technical). | “The OrderHistory module shall retrieve all orders associated with CustomerID from the Orders table (SQL database) and display them in reverse chronological order (newest first).” |
3.2 Requirements Elicitation Techniques
| Technique | Description | Best for | Potential Issues |
|---|---|---|---|
| Interviews | One‑on‑one or group sessions with stakeholders (open‑ended or structured). | Understanding stakeholder goals, implicit needs. | Time‑consuming, may miss unarticulated needs, interviewer bias. |
| Questionnaires (Surveys) | Written set of questions (closed‑ended, rating scales, open‑ended) distributed to many stakeholders. | Large number of stakeholders, geographically distributed, initial broad requirements. | Low response rate, ambiguous answers, no follow‑up. |
| Workshops (JAD – Joint Application Development) | Facilitated group sessions with stakeholders, users, analysts, developers to identify and prioritise requirements. | Large, complex projects where consensus needed; conflicting stakeholder interests. | Requires skilled facilitator, strong‑willed participants may dominate, logistically heavy. |
| Observation (Ethnography) | Analyst observes users in their work environment to understand tasks, pain points, unarticulated needs. | When users cannot articulate their needs (or their stated behaviour differs from actual). | Time‑consuming, may influence behaviour (Hawthorne effect), limited generalisability. |
| Document Analysis | Review existing documents (business process manuals, standard operating procedures, user guides, regulations, contracts). | Legacy systems, software replacement, regulatory requirements. | Documents may be out‑of‑date, incomplete, contradictory. |
| Prototyping | Build preliminary version (low‑fidelity — paper, mockups, wireframes; high‑fidelity — interactive, working subset) to elicit feedback. | Unclear user interface requirements; when users learn by seeing. | May be misinterpreted as final product; scope creep. |
| Use Cases (and User Stories). | Write user scenarios describing interactions between actor and system; user stories in agile (As a… I want… so that…). | Capturing functional requirements in user‑understandable format. | May emphasise specific scenarios at expense of exceptions or non‑functional requirements. |
3.3 Requirements Documentation (Software Requirements Specification – SRS)
IEEE 830‑1998 recommended structure:
-
Introduction (purpose, scope, definitions, references, overview)
-
Overall description (product perspective, user characteristics, assumptions, dependencies)
-
Specific requirements (functional, non‑functional, external interface requirements – user, hardware, software, communications)
-
Appendices (use case diagrams, models, input/output specifications)
Characteristics of well‑written SRS:
| Characteristic | Meaning | Violation Example |
|---|---|---|
| Correct | Accurately describes intended functionality; no contradictions | “The system shall display customer name” but customer name not in data model. |
| Unambiguous | Single interpretation; quantifiable terms (no “quick”, “user‑friendly”, “efficient”). | “The system shall respond quickly” – no clear metric. |
| Complete | All requirements included (functional, non‑functional, external, design constraints). | Missing security, performance, or reliability requirements. |
| Consistent | No internal contradictions; consistent terminology. | One section says “order number is 10 digits”, another says “15 digits”. |
| Verifiable (testable). | Existence of cost‑effective process to check whether software meets requirement. | “User interface shall be easy to learn” – subjective, not quantifiable. |
| Modifiable | Structured, no redundancy (use cross‑references). | Same requirement repeated in multiple sections, likely to be updated inconsistently. |
| Traceable | Forward trace (from requirement to design, code, test) and backward (from code, test to requirement). | Requirement not linked to any test case or code module; orphan requirement. |
3.4 Requirements Validation and Verification
-
Validation (“building the right product”) – ensure requirements capture customer’s real needs. Methods: reviews/inspections, prototyping, use case walkthroughs.
-
Verification (“building the product right”) – ensure product conforms to requirements (testing, inspections, analysis).
Unit 4: Software Design
4.1 Design Concepts
| Concept | Definition | Example |
|---|---|---|
| Abstraction | Focus on essential characteristics while ignoring irrelevant details. | Abstract class Vehicle with method move(), subclasses Car, Ship implement move() differently. |
| Modularity | Decompose system into smaller, independent, interchangeable modules (cohesion and coupling). | Separate modules for Login, Cart, Payment, Inventory. |
| Cohesion (intra‑module). | Degree to which elements within a module belong together (functional cohesion highest, coincidental lowest). | PaymentProcessor module: methods validateCard(), chargeCard(), sendReceipt() (functionally cohesive). |
| Coupling (inter‑module). | Degree of interdependence between modules (lowest coupling best). | ShoppingCart module passes orderTotal (value) to PaymentProcessor – data coupling (low). Not shared global variables – stamp coupling (medium). |
| Information Hiding (encapsulation). | Hide internal details of module behind stable interface. | Class BankAccount only exposes public methods deposit(amount), withdraw(amount). Internal representation (balance variable) is private. |
| Separation of Concerns (SoC). | Divide into distinct sections, each addressing separate concern (presentation, business logic, persistence). | Model‑View‑Controller (MVC) pattern: Model (data), View (UI), Controller (business logic). |
4.2 Design Principles (SOLID)
| Acronym | Principle | Description | Example Violation |
|---|---|---|---|
| S | Single Responsibility (SRP) | A class should have one, and only one, reason to change. | Class User handles both authentication (login) and database persistence (save()). |
| O | Open‑Closed (OCP) | Software entities should be open for extension but closed for modification. | Adding new Shape (e.g., Triangle) requires modifying AreaCalculator class. Better: Shape interface with area() method; AreaCalculator works with Shape. |
| L | Liskov Substitution (LSP) | Subtypes must be substitutable for their base types without altering program correctness. | Square subclass of Rectangle – setting width also sets height (breaks expected rectangle behaviour). |
| I | Interface Segregation (ISP) | Clients should not be forced to depend on interfaces they do not use. | Interface Worker has methods work(), attendMeeting(), fileReport(). Robot implements Worker but attendMeeting() is meaningless. Better: split into Workable, MeetingAttendee, Reportable. |
| D | Dependency Inversion (DIP) | High‑level modules should not depend on low‑level modules; both should depend on abstractions. Abstractions should not depend on details; details depend on abstractions. | Class NotificationService directly instantiates EmailSender (concrete). Better: depends on MessageSender interface; EmailSender implements MessageSender. |
4.3 Unified Modeling Language (UML)
Structural Diagrams:
| Diagram | Purpose | Key Elements |
|---|---|---|
| Class Diagram | Static structure: classes, attributes, methods, relationships (association, inheritance, composition, aggregation). | Classes, attributes, operations, multiplicities (0..1, 1, 0.., 1..), association end names, generalisation (inheritance), composition (filled diamond), aggregation (hollow diamond). |
| Component Diagram | High‑level structure of system components and dependencies. | Components, interfaces (provided/required), dependencies. |
| Deployment Diagram | Physical deployment of artifacts on hardware nodes (servers, workstations, devices). | Nodes (hardware), execution environments (virtual machines, containers), artifacts (executables, libraries). |
Behavioural Diagrams:
| Diagram | Purpose | Key Elements |
|---|---|---|
| Use Case Diagram | High‑level functional requirements from user perspective: actors (users, external systems) and use cases (functions). | Use case (ellipse), actor (stick figure), association (line), include (dashed arrow with <<include>>), extend (<<extend>>), generalisation (hollow arrow). |
| Activity Diagram | Workflow, business process, algorithmic flow (similar to flow chart but with concurrency). | Start/end nodes, activity (rounded rectangle), decision (diamond), merge, fork (concurrency start), join (concurrency end), swimlanes (partitions). |
| Sequence Diagram | Time‑ordered interaction between objects (message passing). | Lifelines (vertical dashed line), activation boxes (when object is active), messages (solid arrow → synchronous, dashed arrow → asynchronous), return messages (dotted arrow), loops, alt (alternative interaction), opt (optional). |
| State Machine Diagram | Behaviour of single object responding to events over time (state transitions). | State (rounded rectangle), initial state (filled circle), transition (arrow with event/guard/action), final state (filled circle inside circle). |
Unit 5: Software Testing
5.1 Testing Levels
| Level | Scope | Artifacts Tested | Testers | Typical Environment |
|---|---|---|---|---|
| Unit Testing | Individual component (function, method, class) | Source code, individual modules | Developer | Development environment (IDE) with mocking framework (Jest, Mockito, unittest). |
| Integration Testing | Interaction between modules (interfaces, APIs, data flow) | Integrated modules, databases, external services | Developer or dedicated tester | Integration environment (stubs for unavailable services). |
| System Testing | Entire system (end‑to‑end) against functional and non‑functional requirements | Complete software system | Independent test team (QA) | Staging environment (mirror of production). |
| Acceptance Testing (User Acceptance Testing – UAT). | Validate system meets user requirements and business needs | Complete software system, user workflows | End users, business analysts, product owners | Staging environment (or training environment). |
5.2 Testing Techniques
Black‑Box (functional): Test based on requirements, specification (no knowledge of internal code).
| Technique | Description | Test Case Example |
|---|---|---|
| Equivalence Partitioning (EP). | Divide input domain into classes where behaviour likely same; test one value from each class. | Age input: valid (18‑65) – test 30; invalid under 18 – test 15; invalid over 65 – test 70. |
| Boundary Value Analysis (BVA). | Test boundaries between equivalence classes (min‑1, min, max, max+1). | Age input: boundaries at 18‑65 – test 17, 18, 65, 66. |
| Decision Table Testing | Table of causes (conditions) and effects (actions); test all combinations (for complex business rules). | Insurance premium calculation (age, driving history, vehicle type) – generate combinations of conditions. |
| State Transition Testing | Test transitions between states based on events (e.g., finite state machine). | ATM: Idle → Card Inserted → PIN Entered → Valid PIN → Transaction Selection → Dispense Cash → Card Ejected. |
| Use Case Testing | Test end‑to‑end flows (main success scenario, alternative, exception). | E‑commerce checkout: add to cart → enter address → select payment → place order (success, credit card declined, insufficient funds). |
White‑Box (structural): Test based on internal code structure.
| Coverage Type | Metric | Level |
|---|---|---|
| Statement Coverage | Percentage of executable statements executed | Basic; may miss branches. |
| Branch Coverage (decision coverage). | Percentage of decision outcomes (true/false of each branch) executed | Stronger than statement coverage. |
| Path Coverage | Percentage of all possible paths through code (combinatorial explosion – often impractical) | Very strong; impractical for complex code. |
| Condition Coverage | Percentage of boolean sub‑expressions evaluated both true and false | |
| MC/DC (Modified Condition/Decision Coverage – DO‑178C for aerospace). | Each condition independently affects decision outcome | Highest (mandated for safety‑critical avionics software). |
5.3 Testing Pyramid
/\
/ \ E2E (Acceptance) tests – few, slow, expensive
/----\
/ \ Integration tests – more, faster
/--------\
/ \ Unit tests – many, very fast, cheap
/------------\
/______________\
Goal: Most tests at unit level (fast, cheap, localised failures); fewer integration tests; minimal end‑to‑end tests (slow, brittle, expensive to maintain).
Unit 6: Software Maintenance
6.1 Types of Maintenance
| Type | Description | Typical Effort (%) |
|---|---|---|
| Corrective | Fix defects (bugs, logic errors, performance issues) discovered after deployment. | ~20‑30% |
| Adaptive | Modify software to work in changed environment (new OS version, new hardware, new database, new API). | ~15‑25% |
| Perfective | Enhance functionality, improve performance, add new features, improve code maintainability (refactoring). | ~40‑60% |
| Preventive (proactive). | Make changes to prevent future problems (code reorganisation, adding comments, improving documentation, adding tests, removing duplication). | ~5‑10% |
6.2 Maintenance Challenges
-
Legacy systems (large, old, no documentation, original developers unavailable)
-
Technical debt (shortcuts taken to meet deadlines, making future changes expensive)
-
Regression (fixing one bug introduces new bugs – requires comprehensive regression testing)
-
Configuration management (tracking versions, changes, builds, deployments)
-
Dependency management (upgrading libraries, frameworks, ensuring backward compatibility)
Unit 7: Software Project Management
7.1 Project Planning and Estimation
Estimation techniques:
| Technique | Description | When to Use |
|---|---|---|
| Expert Judgment (Delphi). | Consult experienced developers; converge anonymously to avoid bias | Initial estimates, small projects, when historical data lacking. |
| Analogy (Comparison). | Compare to similar completed project; adjust for differences. | Well‑defined project types (similar technology, domain, size). |
| Function Point Analysis (FPA). | Measure software size based on user functions (inputs, outputs, inquiries, files, interfaces). | Projects where function‑oriented estimation is valuable (e.g., business information systems). |
| COCOMO II (Constructive Cost Model). | Parametric model based on size (KLOC) and cost drivers (product, platform, personnel, project attributes). | Early estimation, industry‑historical data available. |
| Wideband Delphi | Structured group consensus with multiple rounds; each expert estimates independently, then discuss, then re‑estimate. | When expert opinion matters; reduce bias. |
| Use Case Points (UCP). | Based on number and complexity of actors, use cases, technical and environmental factors. | Early in project when use cases defined, but detailed design not yet complete (OO projects). |
7.2 Risk Management
| Step | Description | Output |
|---|---|---|
| Risk Identification | Brainstorm, review checklists, lessons learned, SW‑H securitisation | Risk list (risk entry) |
| Risk Assessment (Qualitative/Quantitative). | Probability (0‑1) and impact (cost, schedule, quality). | Risk probability/impact matrix, risk exposure (probability × impact). |
| Risk Prioritisation | Rank risks by severity | Prioritised risk list |
| Risk Mitigation Planning | Develop strategies: avoid, transfer (insurance, outsourcing), mitigate (reduce probability/impact), accept (contingency plan). | Risk mitigation plan (actions, owner, timeline, contingency budget). |
| Risk Monitoring | Periodic review; track triggers (risk condition). | Updated risk status, revised mitigation plans. |
7.3 Project Scheduling (Gantt Charts, Critical Path)
Critical Path Method (CPM): Identify longest path through task network; tasks on critical path have zero slack (delay → project delay).
Earned Value Management (EVM) :
| Metric | Formula | Interpretation |
|---|---|---|
| Planned Value (PV) (Budgeted Cost of Work Scheduled – BCWS). | Sum of budgets for tasks scheduled | Baseline (planned) cost at point in time |
| Earned Value (EV) (Budgeted Cost of Work Performed – BCWP). | Sum of budgets for tasks actually completed (× % complete). | Value of work actually accomplished (in budget terms). |
| Actual Cost (AC) (Actual Cost of Work Performed – ACWP). | Actual cost incurred | Actual expenditure |
| Schedule Variance (SV) | EV – PV | Negative → behind schedule |
| Cost Variance (CV) | EV – AC | Negative → over budget |
| Schedule Performance Index (SPI) | EV / PV | <1 → behind schedule |
| Cost Performance Index (CPI) | EV / AC | <1 → over budget |
| Estimate at Completion (EAC) (forecast). | AC + (Budget at Completion – EV) / CPI (if typical variance). | Expected final cost |
Unit 8: Quality Management
8.1 Quality Assurance vs. Quality Control
| Aspect | Quality Assurance (QA) | Quality Control (QC) |
|---|---|---|
| Focus | Process – prevent defects | Product – identify defects |
| Activities | Process audits, process definition, standards, training, reviews, metrics | Testing (unit, integration, system, acceptance), inspections, code reviews |
| Timing | Throughout development lifecycle | After build (testing phase) or during build (unit testing) |
| Goal | Build quality in | Verify quality out |
8.2 Standards and Models
| Standard | Focus | Requirements |
|---|---|---|
| ISO 9001 (Quality Management). | Generic, any industry | Documented quality management system (QMS), process approach, continuous improvement, customer focus. |
| CMMI (Capability Maturity Model Integration). | Software process improvement (levels 1 to 5). | Level 2 (Managed): Project management, requirements management, configuration management. Level 3 (Defined): Standardised processes. Level 4 (Quantitatively Managed): Statistical control. Level 5 (Optimising): Continuous process improvement. |
| IEEE 730 (Software Quality Assurance). | SQA plans, activities, deliverables. | SQA plan content (purpose, references, management, documentation, standards, reviews, testing, problem reporting, configuration management, tools, SQA records). |
8.3 Reviews and Inspections
| Type | Formality | Participants | Purpose |
|---|---|---|---|
| Peer Review (colleague checking). | Informal | Developer(s) + one or two peers | Catch obvious errors; improve readability |
| Walkthrough | Semi‑formal | Developer, facilitator, scribe, other developers, QA | Understand design; find anomalies by explanation. |
| Inspection (Fagan). | Formal – structured process | Author, moderator, reviewer, reader, scribe – separate roles, checklist, defect logging, follow‑up | Detect defects (earliest stage); measure process quality. |
Unit 9: Software Configuration Management
9.1 SCM Activities
| Activity | Description | Tools |
|---|---|---|
| Identification | Assign unique identifier to work products (version number, revision). | Semantic versioning (MAJOR.MINOR.PATCH) |
| Version Control (revision control). | Track changes to files; coordinate multiple developers working on same files. | Git, Subversion (SVN), Mercurial, Perforce |
| Change Control (Change Management). | Evaluate, approve, track change requests; maintain audit trail. | Jira, Bugzilla, GitHub Issues, Trello |
| Build Management | Automate compilation, testing, packaging, deployment. | Jenkins, GitLab CI, GitHub Actions, Travis CI, CircleCI, Maven, Gradle |
| Release Management | Package, version, tag, and deploy releases. | Artifactory, Nexus, Docker Registry, GitHub Releases |
9.2 Branching Strategies (Git)
| Strategy | Description | Use Case |
|---|---|---|
| Trunk‑Based | All developers commit to single branch (trunk/main). Frequent (daily) commits, short‑lived feature branches. | Continuous integration, high‑velocity teams, DevOps. |
| Git Flow | Permanent branches: main, develop; temporary branches: feature, release, hotfix. | Complex releases, multiple environments, formal release process. |
| GitHub Flow | Simple: main branch always deployable; feature branches merge after review. | Web applications, continuous deployment, small teams. |
Part C: Advanced Topics
Unit 10: Software Metrics
10.1 Types of Metrics
| Category | Examples | Purpose |
|---|---|---|
| Product Metrics | Lines of code (LOC), cyclomatic complexity, depth of inheritance, coupling between objects, number of classes, function points. | Measure product attributes (size, complexity, maintainability). |
| Process Metrics | Defect density (defects/KLOC), review efficiency (defects found per hour), test coverage (% lines/branches covered), effort variance (plan vs. actual). | Monitor and improve development process. |
| Project Metrics | Schedule variance, cost variance, earned value metrics, milestone completion rate, staff turnover. | Track project health, predict completion. |
10.2 Defect Metrics
-
Defect density = Total defects / KLOC (thousand lines of code). Benchmark varies by industry (aerospace: <1 defect/KLOC; web apps: 10‑20 defects/KLOC).
-
Defect removal efficiency (DRE) = Defects found before release / (Defects found before release + Defects found after release) × 100%. Target >95% for high‑criticality systems.
Unit 11: Ethics in Software Engineering
11.1 ACM/IEEE Code of Ethics (8 Principles)
| Principle | Summary |
|---|---|
| 1. Public | Software engineers shall act consistently with public interest; disclose dangers; consider health, safety, environment. |
| 2. Client and Employer | Act in best interest of client/employer, consistent with public interest; avoid conflicts of interest; keep confidential information. |
| 3. Product | Ensure products meet highest professional standards; realistic estimates; adequate testing; full documentation; reject bribery, kickbacks, deceptive claims. |
| 4. Judgment | Maintain integrity and independence; not be coerced into unethical actions; provide objective evaluations. |
| 5. Management | Promote ethical management; ensure fair compensation; provide good working conditions; proper credit for intellectual property. |
| 6. Profession | Advance integrity and reputation; support colleagues; report violations; provide continuing education; participate in professional societies. |
| 7. Colleagues | Support colleagues; credit properly; review work fairly; assist in professional development. |
| 8. Self | Engage in lifelong learning; promote ethical approaches; maintain professional competence. |
11.2 Ethical Issues Specific to Software Engineering
| Issue | Example | Ethical Conflict |
|---|---|---|
| Privacy | Collecting user data without consent; selling personal data; inadequate security leading to breach | Business value vs. user privacy; shareholder profit vs. data protection. |
| Intellectual Property (IP). | Copying code from open‑source project without complying with licence (e.g., GPL requiring disclosure), software piracy. | Reuse efficiency vs. respecting licences. |
| Safety‑Critical Systems | Defective software in medical device, autonomous vehicle, aircraft controls, nuclear plant. | Meeting deadlines vs. thorough testing; cost reduction vs. safety. |
| Algorithmic Bias (Discrimination). | Hiring algorithm discriminates based on race/gender; loan approval algorithm denies credit to protected group (disparate impact). | Performance (proxy variable accuracy) vs. fairness. |
| Whistleblowing | Discovering employer’s illegal or unethical product; reporting to authorities or public. | Loyalty to employer vs. public interest (Hippocratic oath). |
Sample Exam Questions
-
Explain the difference between software engineering and programming. Discuss the key software quality attributes from ISO/IEC 25010.
-
Compare the Waterfall and Agile (Scrum) process models. Under what conditions would you choose one over the other?
-
Describe the structure and content of a Software Requirements Specification (SRS) as per IEEE 830. What are the characteristics of a well‑written requirement?
-
Explain SOLID principles of object‑oriented design. Provide a violation example for each principle and how to refactor it.
-
Differentiate black‑box and white‑box testing. Describe equivalence partitioning and boundary value analysis with example.
-
What is the testing pyramid? Why is it important to have more unit tests than end‑to‑end tests?
-
Explain the four types of software maintenance (corrective, adaptive, perfective, preventive). Which consumes the largest portion of maintenance budget and why?
-
Define earned value management (EVM). Explain PV, EV, AC, SV, CV, SPI, CPI. If a project has SPI = 0.85 and CPI = 0.90, what does this indicate?
-
Describe the ACM/IEEE Code of Ethics principles relevant to software engineering. Give an example of an ethical dilemma involving algorithmic bias.
-
Explain the purpose and content of a formal technical inspection (Fagan inspection). How does it differ from a walkthrough?
Theory of Automata – Complete Study Notes
Part 1: Foundations of Automata Theory
1. Introduction to Automata Theory
Definition
Automata Theory is the branch of computer science and mathematics that studies abstract machines (automata) and the computational problems they can solve. It forms the theoretical foundation for compiler design, formal languages, parsing, and computability.
Why Study Automata Theory?
| Application | Description |
|---|---|
| Compiler design | Lexical analysis (finite automata) and parsing (pushdown automata) |
| Text processing | Pattern matching using regular expressions and finite automata |
| Programming languages | Formal specification of syntax (context-free grammars) |
| Artificial intelligence | State-based reasoning, planning, and game theory |
| Verification | Model checking of software and hardware systems |
| Computability | Understanding which problems can (or cannot) be solved by computers |
| Complexity theory | Classifying problems by difficulty (P vs NP) |
Basic Terminology
| Term | Definition | Example | ||||
|---|---|---|---|---|---|---|
| Symbol | An atomic, indivisible unit | a, b, 0, 1 | ||||
| Alphabet (Σ) | A finite, non-empty set of symbols | Σ = {a, b}, Σ = {0, 1} | ||||
| String (Word) | A finite sequence of symbols from an alphabet | “abba”, “101” | ||||
| Empty string (ε) | String with no symbols | ε | ||||
| Language | A set (finite or infinite) of strings over an alphabet | L = {ε, a, aa, aaa, …} | ||||
| **Length of string ( | w | )** | Number of symbols in string | “aba” | = 3 | |
| Concatenation | Joining two strings | “ab” + “cd” = “abcd” |
String Operations
| Operation | Notation | Example (Σ = {a, b}) | Result | ||
|---|---|---|---|---|---|
| Length | w | w = “abba” | 4 | ||
| Empty string | ε | — | — | ||
| Concatenation | uv | “ab” ◦ “ba” | “abba” | ||
| Reverse | wᴿ | “abc”ᴿ | “cba” | ||
| Powers | wⁿ (n ≥ 0) | “ab”³ | “ababab” (³ times) | ||
| Substring | Sequence of consecutive symbols | “bba” in “abbaa” | Yes | ||
| Prefix | Starting substring | “ab” in “abbc” | Yes | ||
| Suffix | Ending substring | “bc” in “abbc” | Yes | ||
| Kleene star | Σ* | Σ = {a, b} | {ε, a, b, aa, ab, ba, bb, aaa, …} (all finite strings) | ||
| Kleene plus | Σ⁺ = Σ* – {ε} | Σ = {a, b} | {a, b, aa, ab, ba, bb, aaa, …} |
Language Operations
| Operation | Notation | Description | |
|---|---|---|---|
| Union | L₁ ∪ L₂ | Strings in L₁ or L₂ (or both) | |
| Intersection | L₁ ∩ L₂ | Strings in both L₁ and L₂ | |
| Concatenation | L₁L₂ = {uv | u ∈ L₁, v ∈ L₂} | All concatenations |
| Kleene star | L* = ∪_{i≥0} Lⁱ | ε + L + LL + LLL + … | |
| Positive closure | L⁺ = ∪_{i≥1} Lⁱ | L + LL + LLL + … (no ε unless L already contains ε) | |
| Complement | \bar{L} = Σ* \ L | All strings over Σ not in L | |
| Reversal | Lᴿ = {wᴿ | w ∈ L} | All reversed strings |
2. Formal Languages
Chomsky Hierarchy
| Language Type | Grammar Type | Automaton | Recognition Complexity | Example | ||
|---|---|---|---|---|---|---|
| Type 0 (Recursively enumerable) | Unrestricted grammar | Turing machine | Recognizable (may not halt on no) | L = { ww | w ∈ Σ* } (accepting) | |
| Type 1 (Context-sensitive) | Context-sensitive grammar | Linear-bounded automaton (LBA) | EXPSPACE | L = { aⁿbⁿcⁿ | n ≥ 1 } | |
| Type 2 (Context-free) | Context-free grammar (CFG) | Pushdown automaton (PDA) | Polynomial (O(n³)) | L = { aⁿbⁿ | n ≥ 0 } | |
| Type 3 (Regular) | Regular grammar (RG) | Finite automaton (FA) | Linear O(n) | L = { aⁿbᵐ | n, m ≥ 0 } | (regular; note: n not tied to m) |
Proper inclusion: Regular ⊂ Context-free ⊂ Context-sensitive ⊂ Recursively enumerable
Part 2: Finite Automata
3. Deterministic Finite Automata (DFA)
Definition
A Deterministic Finite Automaton (DFA) is a 5-tuple: M = (Q, Σ, δ, q₀, F)
| Component | Name | Description |
|---|---|---|
| Q | Finite set of states | {q₀, q₁, q₂, …} |
| Σ | Input alphabet | Finite set of input symbols |
| δ | Transition function | δ: Q × Σ → Q (deterministic) |
| q₀ ∈ Q | Start state | Initial state before reading input |
| F ⊆ Q | Set of final (accepting) states | Any state in F after reading input means acceptance |
Transition Function and Extended Transition Function
The extended transition function δ^ extends δ to strings:
-
Base: δ^(q,ε)=q
-
Recursive: δ^(q,wa)=δ(δ^(q,w),a) for w ∈ Σ*, a ∈ Σ
Language Accepted by a DFA
L(M)={w∈Σ∗∣δ^(q0,w)∈F}
DFA Example
Design DFA for L = { w ∈ {a, b}* | w ends with “ab” }
States: Q = {q₀, q₁, q₂}
Start: q₀
Final: F = {q₂}
Transition table:
a b
q₀ q₁ q₀
q₁ q₁ q₂
q₂ q₁ q₀
Transition diagram:
a b
┌─────┐ ┌─────┐
↓ │ ↓ │
q₀ ────→ q₁ ←──── q₂ ←─┘
↑ a b ↑
└───────────────┘
b
DFA Minimization
Two states p and q are equivalent (indistinguishable) if:
-
For every input string w, δ^(p,w)∈F iff δ^(q,w)∈F.
Minimization algorithm (Table-filling method) :
-
Mark all pairs (p, q) where p ∈ F and q ∉ F (or vice versa).
-
Repeat: If (p, q) is not marked and there exists a symbol a such that (δ(p, a), δ(q, a)) is marked, then mark (p, q).
-
Continue until no more marks.
-
States that remain unmarked are equivalent → merge into single state.
Minimal DFA is unique up to renaming of states.
4. Nondeterministic Finite Automata (NFA)
Definition
An Nondeterministic Finite Automaton (NFA) is a 5-tuple: M = (Q, Σ, δ, q₀, F)
Same as DFA except the transition function:
-
δ: Q × (Σ ∪ {ε}) → P(Q) (power set of Q)
-
ε-transitions: Transitions on empty string (no input consumed)
Language Accepted by an NFA
A string w is accepted if there exists at least one path from q₀ to some final state f ∈ F, where the concatenation of edge labels along the path equals w (ε transitions consume no input).
NFA to DFA Conversion (Subset Construction)
Subset construction:
| Step | Action |
|---|---|
| 1 | Start state of DFA = ε-closure({q₀}) |
| 2 | For each DFA state (set of NFA states) and for each input symbol a, compute new state = ε-closure(δ(T, a)) |
| 3 | Mark any DFA state containing an NFA final state as final |
| 4 | Repeat until no new states appear |
ε-closure(T): Set of all NFA states reachable from any state in T using zero or more ε-transitions only.
NFA Advantages
| Characteristic | DFA | NFA |
|---|---|---|
| Definition | Deterministic | Nondeterministic (multiple choices) |
| ε-transitions | No | Yes |
| State explosion | Minimal (but NFA→DFA may cause explosion) | Potentially smaller (for NFA spec) |
| Implementation | Straightforward (simulate δ) | Virtual simulation via subset construction |
5. Regular Languages
Definition
A language is regular if it can be recognized by a DFA (or NFA or regular expression).
Closure Properties of Regular Languages
| Operation | Closure property |
|---|---|
| Union (L₁ ∪ L₂) | Regular (if L₁, L₂ regular) |
| Intersection (L₁ ∩ L₂) | Regular |
| Complement ( \bar{L} ) | Regular |
| Concatenation (L₁L₂) | Regular |
| Kleene star (L*) | Regular |
| Reversal (Lᴿ) | Regular |
| Difference (L₁ \ L₂) | Regular |
| Homomorphism (h(L)) | Regular |
| Inverse homomorphism (h⁻¹(L)) | Regular |
Pumping Lemma for Regular Languages
Statement: If L is a regular language, then there exists a pumping length p ≥ 1 (number of states in a DFA for L) such that for any string s ∈ L with |s| ≥ p, s can be split into three parts, s = xyz, satisfying:
-
|xy| ≤ p
-
|y| ≥ 1
-
For all i ≥ 0, xyⁱz ∈ L
Application (Proving non-regularity) :
To prove L is not regular:
-
Assume L is regular (for contradiction).
-
Choose appropriate s ∈ L with |s| ≥ p.
-
Show that for every possible split xyz satisfying |xy| ≤ p and |y| ≥ 1, there exists i (usually i = 0 or 2) such that xyⁱz ∉ L.
-
Conclude contradiction, so L is not regular.
Example: L = { aⁿbⁿ | n ≥ 0 } is not regular.
-
Proof: Choose s = aᵖbᵖ. Since |xy| ≤ p, y consists only of a’s (say y = aᵏ, k ≥ 1). Then xy²z = aᵖ⁺ᵏbᵖ not in L (unequal counts of a and b). Contradiction.
Limitations of Finite Automata
Finite automata cannot:
-
Count unboundedly (e.g., equal numbers of a’s and b’s: aⁿbⁿ)
-
Match balanced parentheses (nested structures)
-
Recognize palindromes (wwᴿ with |w| unlimited)
-
Recognize languages requiring memory proportional to input length
6. Regular Expressions (RE)
Definition
A regular expression (over alphabet Σ) is a pattern that describes a regular language. It is defined recursively:
| Base | Description | Language |
|---|---|---|
| ε | Empty string | {ε} |
| ∅ | Empty language (no strings) | ∅ |
| a (for any a ∈ Σ) | Single symbol | {a} |
Recursive rules (if R and S are regular expressions):
| Expression | Language | Description | |
|---|---|---|---|
| **R | S** (alternation) | L(R) ∪ L(S) | Union |
| RS (concatenation) | L(R)L(S) | Concatenation | |
| R* (Kleene star) | (L(R))* | Zero or more repetitions | |
| (R) | L(R) | Grouping (parentheses) |
Precedence (highest to lowest):
-
Parentheses: ( )
-
Kleene star: *
-
Concatenation (implicit)
-
Union: |
Regular Expression Examples
| Language | Regular Expression | ||
|---|---|---|---|
| Strings over {a, b} that end with “ab” | (a | b)*ab | |
| Strings of even length | ((a | b)(a | b))* |
| Strings with at least one ‘a’ | (a | b)* a (a | b)* |
| Strings with exactly two a’s | b* a b* a b* | ||
| Strings over {a, b}: no two consecutive a’s | (b | ab)* (ε | a)? |
Equivalence: Regular Expression ↔ DFA/NFA
-
RE → NFA (Thompson’s construction) : Build NFA inductively from RE components.
-
DFA/NFA → RE (Arden’s Theorem, state elimination) : Eliminate states one by one, writing regular expressions on edges.
Part 3: Context-Free Grammars and Pushdown Automata
7. Context-Free Grammars (CFG)
Definition
A Context-Free Grammar (CFG) is a 4-tuple: G = (V, T, P, S)
| Component | Name | Description |
|---|---|---|
| V | Variables (non-terminals) | Finite set of syntactic categories |
| T | Terminals | Finite set of alphabet symbols (T ∩ V = ∅) |
| P | Production rules | Finite set of rules of form A → α (A ∈ V, α ∈ (V ∪ T)*) |
| S ∈ V | Start symbol | Initial variable |
Derivations and Language
Derivation: Sequence of rewriting steps, starting from S, replacing variables by the right-hand side of the production until no variables remain.
Language of CFG: L(G) = { w ∈ T* | S ⇒* w } (all strings of terminals derivable from S).
Leftmost derivation: Always replace the leftmost variable.
Rightmost derivation: Always replace the rightmost variable.
Examples of CFGs
| Language | CFG | |
|---|---|---|
| L = { aⁿbⁿ | n ≥ 0 } | S → aSb | ε |
| L = { balanced parentheses } | S → (S) | SS | ε | |
| L = { wwᴿ | w ∈ {a, b}* } (palindromes) | S → aSa | bSb | ε | a | b |
| L = { aⁿbᵐ | n ≤ m ≤ 2n } | S → aSb | aSbb | ε |
| L = { aⁿbᵐcᵖ | n, m, p ≥ 0 } | S → XY; X → aX | ε; Y → bYc | ε |
Parse Trees
A parse tree (derivation tree) shows the hierarchical structure of a derivation.
Properties:
-
Root: Start symbol S
-
Leaves: Terminals (reading left to right yields derived string)
-
Internal nodes: Variables
Ambiguity: A CFG is ambiguous if there exists a string with two distinct parse trees (or two distinct leftmost derivations).
Example ambiguous grammar: S → S + S | S * S | a
-
String “a + a * a” has two parse trees (different evaluation order).
Unambiguous grammars (for arithmetic expressions with precedence):
E → E + T | T T → T * F | F F → (E) | a
Normal Forms (for parsing algorithms)
Chomsky Normal Form (CNF) : All productions of form:
-
A → BC (B, C ∈ V, non-terminals)
-
A → a (a ∈ T)
-
S → ε (only allowed if original grammar contains ε)
Conversion to CNF:
-
Add new start symbol S₀.
-
Remove ε-productions (A → ε), except possibly S → ε.
-
Remove unit productions (A → B).
-
Convert productions with >2 variables into binary form (create new intermediate non-terminals).
-
Convert terminals in productions with >1 symbol: replace a with Xₐ (new non-terminal → a).
CYK Algorithm (Cocke-Younger-Kasami): Parses strings in O(n³) time using CNF.
8. Pushdown Automata (PDA)
Definition
A Pushdown Automaton (PDA) is a 6-tuple: P = (Q, Σ, Γ, δ, q₀, F, Z₀)
| Component | Name | Description |
|---|---|---|
| Q | States | Finite set of states |
| Σ | Input alphabet | Finite set of input symbols |
| Γ | Stack alphabet | Finite set of stack symbols |
| δ | Transition function | δ: Q × (Σ ∪ {ε}) × Γ → finite subsets of Q × Γ* (nondeterministic) |
| q₀ ∈ Q | Start state | Initial state |
| Z₀ ∈ Γ | Start stack symbol | Initially on stack |
| F ⊆ Q | Final states (accepting condition) |
Configuration: (q, w, α) where q ∈ Q, w ∈ Σ* (remaining input), α ∈ Γ* (stack contents, top at left).
Acceptance Modes
| Mode | Condition |
|---|---|
| Accept by final state | PDA is in a final state after reading all input (stack may be non-empty) |
| Accept by empty stack | Stack is empty after reading all input (final state may be anything) |
Equivalence: Accept by final state and accept by empty stack are equivalent (may add ε transitions to empty stack or reach final state).
Deterministic vs. Nondeterministic PDA
| PDA Type | Deterministic (DPDA) | Nondeterministic (NPDA) |
|---|---|---|
| Transitions | At most one move per (q, a, Z) | Multiple possible moves |
| Language class | Deterministic context-free languages (DCFL) | Context-free languages (CFL) |
| Proper inclusion | DCFL ⊂ CFL | (some languages require nondeterminism) |
| Example requiring NPDA | L = { wwᴿ } (palindromes) | Cannot be recognized by DPDA |
PDA Construction from CFG
Given a CFG in Greibach Normal Form (GNF) or general form, construct PDA with:
-
One state (or two states)
-
Simulates leftmost derivation via stack
-
Top-down parser (leftmost derivation):
PDA (simulating leftmost derivation) transitions:
-
For variables: For variable A on stack (top), replace with production RHS in reverse (since leftmost derivation replaces leftmost variable). For each production A → α, add: δ(q, ε, A) ∋ (q, αᴿ)
-
For terminals: Match with input: δ(q, a, a) = (q, ε) for all terminals a
Resulting PDA accepts by empty stack equivalent to CFG derivation.
CFG from PDA
Given PDA (accept by empty stack), construct CFG with:
-
Non-terminals: Each [p, X, q] meaning “from state p to state q, pop X and produce net input string”
-
Productions: Based on state transitions
Part 4: Turing Machines and Computability
9. Turing Machines (TM)
Definition
A Turing Machine (TM) is a 7-tuple: M = (Q, Σ, Γ, δ, q₀, F, B)
| Component | Name | Description |
|---|---|---|
| Q | States | Finite set of states |
| Σ | Input alphabet | Σ ⊆ Γ \ {B} (blank) |
| Γ | Tape alphabet | Finite set (contains Σ and B) |
| δ | Transition function | δ: Q × Γ → Q × Γ × {L, R} (deterministic; nondeterministic possible) |
| q₀ ∈ Q | Start state | |
| F ⊆ Q | Final (accepting/halting) states | |
| B ∈ Γ \ Σ | Blank symbol |
Configuration: (q, tape-content, head-position)
One-step relation: (q, w, i) ⊢ (q’, w’, i’) via transition δ(q, tape[i]) = (q’, new-symbol, direction), update tape at i and move head left/right.
Language accepted by TM:
-
Turing-acceptable (recognizable) : TM halts in final state on input w.
-
Turing-decidable (recursive): TM halts (in accept or reject state) on all inputs (total function). No infinite loops.
Variants of Turing Machines
| Variant | Equivalent to standard TM? | Notes |
|---|---|---|
| Nondeterministic TM | Yes | Simulate by deterministic TM with breadth-first search |
| Multi-tape TM | Yes | Simulate k tapes on 1 tape with track markers |
| Multi-head TM | Yes | Simulate by multi-tape (or single tape with markers) |
| Two-way infinite tape | Yes | Simulate with folded tape |
| Offline TM (separate read-only input tape + work tape) | Yes | Input tape read-only; work tape used for storage |
10. Decidability and Undecidability
Decidability Classes
| Class | Description | Halts on all inputs |
|---|---|---|
| Recursive (decidable) | Problem solved by TM that always halts (yes/no answer) | Yes |
| Recursively enumerable (RE) | TM that halts if answer is YES; may loop if NO | No guarantee |
| co-RE | Complement of RE; halts if answer is NO; may loop if YES | No guarantee |
Universal Turing Machine
There exists a TM U that simulates any other TM M on input w (provided encoding of M and w on U’s tape). The halting problem for a TM is the question of whether TM M halts on input w.
Halting Problem:
-
Input: ⌈M⌉ (coding of TM M) and input string w
-
Output: YES if M halts on w; NO otherwise
Theorem: The halting problem is undecidable (no TM decides it).
Proof: By diagonalization. Assume H decides halting. Construct TM D that, on input ⌈M⌉, calls H on (⌈M⌉, ⌈M⌉) and does the opposite (loop if H says halt, halt if H says loop). Contradiction when D runs on its own encoding.
Undecidable Problems (examples)
| Problem | Description | Status |
|---|---|---|
| Halting problem | Does TM M halt on input w? | Undecidable |
| Membership (for TM) | Given ⌈M⌉ and w, does M accept w? | Undecidable (halting is reducible) |
| Emptiness for TM | Does L(M) = ∅? | Undecidable |
| Equivalence for TM | L(M₁) = L(M₂)? | Undecidable |
| Post Correspondence Problem (PCP) | Sequence of tiles (uᵢ, vᵢ) has a match? | Undecidable |
| Context-free grammar ambiguity | Is a given CFG ambiguous? | Undecidable |
| Total TM (always halts) | Is a given TM total (always halts on all inputs)? | Undecidable (Rice’s theorem: any non-trivial property of RE languages is undecidable) |
Rice’s Theorem: Any non-trivial property of the language of a Turing machine is undecidable. (Non-trivial means: some RE languages have the property, some do not.)
Part 5: Computational Complexity
11. Complexity Classes
Time Complexity
Definition: For a TM M that halts on all inputs, the time complexity is a function t(n) = maximum number of steps M takes on any input of length n.
Big-O notation: f(n) = O(g(n)) if ∃ c, n₀ such that f(n) ≤ c·g(n) for all n ≥ n₀.
Space Complexity
Definition: For a TM M that halts on all inputs, the space complexity is s(n) = maximum number of tape cells M uses on any input of length n.
Major Complexity Classes
| Class | Full name | Definition | Examples |
|---|---|---|---|
| P | Polynomial time | Problems solvable in O(nᵏ) time for some constant k | Sorting, shortest path, matrix multiplication |
| NP | Nondeterministic polynomial time | Problems solvable by nondeterministic TM in polynomial time (or: solutions verifiable in polynomial time) | SAT, Hamiltonian path |
| NP-complete | Hardest problems in NP | A problem in NP such that every NP problem reduces to it in polynomial time | SAT, 3-SAT, CLIQUE, TSP |
| NP-hard | At least as hard as NP (not necessarily in NP) | A problem such that every NP problem reduces to it (could be harder) | Halting problem (NP-hard, undecidable) |
| EXPTIME | Exponential time | Solvable in O(2ᵖ⁽ⁿ⁾) time (p polynomial) | Some games (checkers, chess generalized) |
| PSPACE | Polynomial space | Solvable with polynomial tape cells (time may be exponential) | Quantified Boolean formula (QBF), generalized geography |
| L | Logarithmic space (deterministic) | Solvable using O(log n) space | Graph reachability (in DAG) |
| NL | Nondeterministic logarithmic space | Verifiable in log space | Graph reachability in general directed graphs |
Relationship between classes
PSPACE
↑
EXPTIME
↑
NP ← P (probably proper)
↑
NL
↑
L
Known inclusions:
-
L ⊆ NL ⊆ P ⊆ NP ⊆ PSPACE ⊆ EXPTIME
-
NL ⊆ P (by Savitch’s theorem)
-
P ≠ EXPTIME (by time hierarchy theorem)
-
P ⊆ NP (open question whether P = NP)
12. NP-Completeness
Definition
A problem Π is NP-complete if:
-
Π ∈ NP
-
Every problem in NP is polynomial-time reducible to Π (Π is NP-hard).
Significance
If any NP-complete problem is in P, then P = NP (and many open problems would be solved).
Proving NP-Completeness
-
Show Π ∈ NP (exhibit polynomial-time verifier or nondeterministic TM)
-
Choose known NP-complete problem Π’ (e.g., 3-SAT)
-
Construct polynomial-time reduction f from Π’ to Π
-
Show: x ∈ Π’ ⇔ f(x) ∈ Π
Canonical NP-Complete Problems
| Problem | Definition | Used for reductions |
|---|---|---|
| SAT (Boolean satisfiability) | Is there a satisfying assignment of variables for given CNF formula? | First NP-complete (Cook-Levin) |
| 3-SAT | CNF formula with exactly 3 literals per clause | Most common starting point |
| Clique | Does graph G contain a clique of size k? | Reduce 3-SAT to Clique |
| Vertex Cover | Does G have vertex cover of size ≤ k? | Reduce Clique to Vertex Cover |
| Hamiltonian Path | Does G have simple path visiting each vertex? | Reduce 3-SAT |
| TSP (Decision) | Is there traveling salesman tour of length ≤ k? | Reduce Hamiltonian cycle |
| Subset Sum | Is there subset of S summing to target T? | Reduce 3-SAT or partition |
Cook-Levin Theorem (1971)
SAT (Boolean satisfiability) is NP-complete (first such problem). All other NP-completeness proofs are via reductions from SAT (or 3-SAT).
Quick Revision Tables
Table 1: Hierarchy of Languages and Automata
| Grammar Type | Automaton | Language | Example |
|---|---|---|---|
| Type 3 (Regular) | DFA / NFA | Regular | a*b* |
| Type 2 (Context-free) | Pushdown Automaton | Context-free | aⁿbⁿ |
| Type 1 (Context-sensitive) | Linear-bounded automaton | Context-sensitive | aⁿbⁿcⁿ |
| Type 0 (Unrestricted) | Turing machine | Recursively enumerable | Halt (no) |
Table 2: Language Closure Properties
| Operation | Regular | CFL | CSL | RE |
|---|---|---|---|---|
| Union | Yes | Yes | Yes | Yes |
| Intersection | Yes | No | Yes | Yes |
| Complement | Yes | No | Yes (by Immerman–Szelepcsényi: NL = co-NL) | No (complement of RE is not RE, except co-RE) |
| Concatenation | Yes | Yes | Yes | Yes |
| Kleene star | Yes | Yes | Yes | Yes |
| Homomorphism | Yes | Yes | No (for general languages) | Yes (? for RE) |
Table 3: Decision Problems
| Problem | Regular | CFL | CSL | RE (Undecidable for TM) |
|---|---|---|---|---|
| Membership (w ∈ L) | Decidable | Decidable | Decidable | Undecidable (for TM) |
| Emptiness (L = ∅) | Decidable | Decidable | Undecidable | Undecidable |
| Finiteness (L finite) | Decidable | Decidable | Undecidable | Undecidable |
| Equivalence (L₁ = L₂) | Decidable | Undecidable | Undecidable | Undecidable |
| Ambiguity (CFG) | — | Undecidable | — | — |
Table 4: Complexity Class Quick Reference
| Class | Time bound | Space bound | Characteristic | Example |
|---|---|---|---|---|
| P | O(nᵏ) | polynomial | Easy (tractable) | Sorting, shortest path |
| NP | O(nᵏ) (nondet) | polynomial | Verifiable in P | SAT, TSP |
| NP-complete | (nondet) | polynomial | Hardest in NP | 3-SAT |
| PSPACE | exponential (possible) | O(nᵏ) | Solvable with polynomial space | QBF |
| EXPTIME | O(2ᵖ⁽ⁿ⁾) | exponential | Exponential time | Generalized chess, checkers |
Exam Tips for Theory of Automata
-
Know DFA and NFA definitions (5-tuple and 6-tuple), design from language descriptions, convert NFA→DFA (subset construction), DFA minimization.
-
Pumping lemma: For regular languages (and also for CFL, later) – apply to prove non-regularity (choose s wisely, break into xyz, find contradiction).
-
CFG → PDA and PDA → CFG conversion methods.
-
Chomsky Normal Form (CNF) : Conversion steps and CYK algorithm (if required).
-
Undecidability via reducibility: Prove that halting problem is undecidable; show other undecidable results by reducing halting to them.
-
NP-completeness: Prove by (1) showing Π ∈ NP, (2) reduction from known NP-complete Π’ (e.g., 3-SAT) to Π in polynomial time.
-
Chomsky hierarchy: Type 0-3 languages, grammars, automata, and containment relationships.
-
P vs NP: Understand definition (P = deterministic polynomial time; NP = verifiable in polynomial time), implications of P = NP.
-
Rice’s Theorem: Any nontrivial property of recursively enumerable languages is undecidable. Apply to show properties of TMs are undecidable (e.g., “Does TM ever move left?”).