Unit 1: Introduction to Programming

I. Foundations of Programming

Programming is the discipline of expressing a solution to a problem as a precise sequence of instructions that a computer can execute. The activity sits between two worlds: the human world of vague requirements and the machine world of exact operations. Everything in this unit depends on treating a program as a deliberate translation from one to the other.

Defining ideas the later sections rely on:

• Introduction to programming: Programming means designing, writing, testing and maintaining code so that a machine performs a task; it is problem-solving first and coding second. Example: the instruction "add two numbers and print the result" becomes c = a + b; printf("%d", c); in C.
• Program concept: A program is a finite, ordered set of instructions stored in memory that transforms input into output. It has three logical parts — input, processing, output (the IPO model).
• Software vs program: A program solves one task; software is a collection of programs plus documentation and data serving a broader purpose.
• Machine dependence: Instructions must map to operations the CPU understands, reached through translators (compiler or interpreter).

A. Characteristics of programming

Good programs share measurable qualities that distinguish working code from reliable code.

• Correctness: The program produces the expected output for all valid inputs; a payroll program computing wrong tax is useless however fast.
• Efficiency: Economical use of time and memory; an algorithm running in 2 seconds beats one running in 2 minutes on the same data.
• Reliability: Consistent behaviour across runs and inputs, including graceful handling of bad input.
• Readability: Clear naming, indentation and comments so another programmer can follow the logic.
• Portability: Ability to run on different machines or platforms with little change.
• Maintainability: Ease of correcting errors and adding features later.
• Robustness: Resistance to crashing on unexpected conditions such as division by zero or empty files.

II. Stages in Program Development

Software is built through a defined sequence of stages, each producing an output that feeds the next; skipping stages is the usual source of defective programs.

A. The development stages in order

• Problem definition: State precisely what must be solved, the inputs available and outputs required. Example: "read three marks, output average and pass/fail".
• Problem analysis: Identify the data, constraints and processing rules; decide the formula, here average = (m1+m2+m3)/3.
• Algorithm design: Devise the step-by-step logic, often as an algorithm or flowchart, before touching a keyboard.
• Coding: Translate the design into a programming language such as C, following its syntax rules.
• Compilation and translation: Convert source code to machine code; the compiler reports syntax errors that must be fixed.
• Testing and debugging: Run with sample and boundary data to expose logical errors, then locate and remove them.
• Documentation: Record purpose, logic, variables and usage for future readers, both inside the code (comments) and outside (manuals).
• Maintenance: Modify the deployed program to fix latent bugs, adapt to new needs or improve performance; typically the longest and costliest stage.

B. Types of errors encountered

• Syntax errors: Violations of language grammar caught by the compiler, e.g. a missing semicolon int a = 5.
• Logical errors: Program runs but gives wrong results, e.g. using + where * was meant; not caught by the compiler.
• Runtime errors: Failures during execution such as dividing by zero or accessing invalid memory.

III. Algorithms

An algorithm is a finite, well-defined sequence of steps that solves a problem or performs a computation, written independently of any programming language.

A. Definition and properties

An algorithm must satisfy strict conditions to be valid.

• Finiteness: It terminates after a finite number of steps.
• Definiteness: Each step is precise and unambiguous.
• Input: Zero or more quantities are supplied.
• Output: At least one result is produced.
• Effectiveness: Every operation is basic enough to be carried out exactly.

Worked example — sum of first N natural numbers:

Step 1: Start
Step 2: Read N
Step 3: Set sum = 0, i = 1
Step 4: Repeat while i <= N
            sum = sum + i
            i = i + 1
Step 5: Print sum
Step 6: Stop

B. Notations

Algorithms are expressed through recognised notations so that logic can be reviewed before coding.

• Pseudocode: Structured English mixing plain words with programming keywords (IF, WHILE, READ), readable yet close to code. Example: IF marks >= 40 THEN PRINT "Pass".
• Flowchart notation: A pictorial notation using standard symbols to show control flow (detailed in Section IV).
• Step-form notation: Numbered natural-language steps as in the example above, simple for beginners.
• Asymptotic notation: Symbols describing efficiency as input grows — Big-O for the worst case (O(n)), Omega (Ω) for best case, Theta (Θ) for tight bound. A linear scan of n items is O(n).

IV. Flowchart

A flowchart is a diagrammatic representation of an algorithm that uses standardised symbols and directed arrows to show the sequence of operations and decisions.

A. Purpose and standard symbols

The purpose is to visualise control flow, making logic easier to design, communicate and debug than prose.

• Oval (terminal): Marks Start and Stop points.
• Parallelogram (input/output): Reading data or displaying results, e.g. "READ a, b".
• Rectangle (process): A calculation or assignment such as sum = a + b.
• Diamond (decision): A condition with Yes/No branches, e.g. is a > b?.
• Arrows (flow lines): Direction of control between symbols.
• Circle (connector): Joins parts of a flowchart split across space.

B. Advantages and limitations

• Advantages: Communicates logic visually; aids debugging by exposing wrong branches; serves as documentation; language-independent.
• Limitations: Becomes unwieldy for large programs; costly to redraw after changes; no fixed standard for complex constructs.

Example flow for checking pass/fail: Start → READ marks → decision marks >= 40? → Yes prints "Pass", No prints "Fail" → Stop.

V. Types of Programming Methodologies

A programming methodology is an organised approach to structuring code and controlling complexity; the choice shapes how a large problem is decomposed.

A. The principal methodologies

• Unstructured (monolithic) programming: A single sequence with jumps (goto); workable only for tiny programs, hard to debug as size grows.
• Procedural programming: Program organised as a set of procedures or functions called in sequence; C is procedural, e.g. main() calling calculate() and display().
• Structured programming: Uses only three control constructs — sequence, selection (if/switch) and iteration (for/while) — and avoids arbitrary jumps, yielding readable, testable code.
• Modular programming: Divides a program into independent modules each with a single responsibility, developed and tested separately, then combined.
• Object-oriented programming: Organises code around objects bundling data and behaviour, using encapsulation, inheritance and polymorphism; languages such as C++ and Java.

B. Structured versus object-oriented

Two dominant styles contrasted by their unit of organisation.

1. Structured/procedural: Centres on functions acting on separate data; data and logic are decoupled; suits computation-heavy tasks. Weakness: as data grows, tracking which function touches which data becomes hard.
2. Object-oriented: Centres on objects that own their data; encapsulation protects data behind methods; suits large evolving systems. Weakness: more design overhead and steeper learning curve for small tasks.

VI. Top-Down and Bottom-Up Program Development

These are two opposite strategies for decomposing a problem into manageable parts during the development cycle, both aiming at modular, maintainable programs.

A. Top-down development

Begins with the overall problem and progressively refines it into smaller sub-problems (stepwise refinement).

• Principle: Start from main, define high-level modules as stubs, then detail each lower level.
• Flow: Whole → major modules → sub-modules → individual functions.
• Strength: Clear overall structure early; good for well-understood problems.
• Weakness: Lower modules unavailable for real testing until late.

B. Bottom-up development

Begins by building and testing the smallest reusable components first, then combining them into larger units.

• Principle: Build reliable primitive functions, verify them, then assemble upward toward main.
• Flow: Individual functions → sub-modules → complete program.
• Strength: Reusable, well-tested building blocks; good where low-level details are known first.
• Weakness: Overall system behaviour emerges late, risking integration mismatches.

C. Case study — a student result-processing system

The two strategies applied to the same problem: compute and grade student results.

1. Top-down view: Define main(); break it into readMarks(), computeTotal(), computeGrade(), displayResult() as stubs; refine each — computeGrade() splits into threshold checks (>=40 pass, >=75 distinction). Development moves from the whole system downward, so the report layout is fixed before grade logic is coded.
2. Bottom-up view: First write and test computeGrade() and computeTotal() in isolation with sample marks; once each returns correct values, combine them under computeResult(), then wire that into main() and displayResult(). The tested pieces guarantee that assembly proceeds on a reliable base.

Practical outcome: real projects blend both — top-down for the high-level architecture and bottom-up for utility functions — giving a clear structure while reusing verified components.