Applications of computers: requirements and complete worked cases

Use the earlier computer-foundation chapters when following this integrated case. The goal is to explain what an application must do, how its components cooperate, and what evidence establishes useful and dependable behaviour.

What you will learn

Connect domains to requirements; design and validate a complete marks-report task; reason about persistence, security, performance, and failures; test boundary and invalid inputs.

1. Applications: connect the task to the system

In education, computers organise learning material and assessment records. In scientific work, they process measurements and run models. In business, they manage transactions and reports. In embedded control, they read sensors and influence devices. In communication, they exchange information over networks.

For an exam answer, give a concrete task rather than just listing sectors. For deeper understanding, identify the input, processing, output, retained state, and failure conditions. A scientific model can produce a precise numerical result while relying on an inaccurate assumption; computation does not remove the need to evaluate the model.

A complete case study: design a marks-report task

Requirement: calculate an aggregate percentage for supplied subject records and explain invalid inputs. Each subject has obtained marks and its own maximum. The intended aggregate is total obtained marks divided by total maximum marks. This is different from an unweighted average of individual percentages.

Take two subjects: 45 out of 50 and 60 out of 100. Total marks are 105 out of 150, giving 70%. The average of the separate percentages is (90% + 60%)/2 = 75%. Both calculations are arithmetically valid, but only one matches this stated aggregate requirement. A real institution’s assessment rules determine which calculation is appropriate.

if no subject records exist:
    report "At least one subject is required"
    stop

total_obtained = 0
total_maximum = 0
for each subject:
    require numeric obtained and maximum
    require maximum > 0
    require 0 <= obtained <= maximum
    total_obtained += obtained
    total_maximum += maximum

percentage = 100 * total_obtained / total_maximum
display percentage rounded for presentation

Invariant: after each iteration, the running totals equal the sums for the records already processed. Initially both are zero, which is correct for zero processed records. Adding the next valid record preserves that statement. At termination, the totals cover all records. Validation ensures the denominator is positive and the obtained total cannot exceed it.

An invariant is a statement maintained across a sequence of steps. It connects the implementation to the required result. Testing examples checks selected executions; an invariant argument explains why the loop’s accumulation is correct under its assumptions.

Storage and privacy requirements are separate decisions. A calculation-only tool need not collect a student’s identity. If results are retained, define who can read or modify them, what “saved” promises, and how failures are reported. Collecting unnecessary identifying data creates responsibilities without improving the arithmetic.

2. Integrated practice: apply the earlier foundations

These are original practice questions, not previous-year questions. Use them to practise short explanations, structured answers, viva responses, and practical reasoning.

1. Short answer: define a computer and explain why programmability matters.
2. Short answer: distinguish data and information using the value 75.
3. Explain with a diagram: describe the processor, main memory, and input/output in a marks-report application.
4. Reasoning: why can a computer calculate accurately and still return an incorrect percentage?
5. Trace: find the successive totals and final percentage in the pseudocode above.
6. Performance: a task spends 6 seconds computing and 4 seconds waiting. If computation becomes twice as fast, find the new time and speedup.
7. Viva: explain why a touchscreen is both input and output, and why firmware is software.
8. Practical: inspect your device's CPU, RAM, and storage using system settings. Record capacities separately from processor clock information; do not change settings.

Use a systematic troubleshooting exercise

A report is correct on screen but absent after restarting the application. Write three hypotheses and describe evidence that distinguishes them: the application never saved, it saved to a different location, or saving failed. Avoid jumping straight to “the CPU is broken”. A master's student should be able to move from symptoms to testable explanations.

Worked reasoning exercise: a slow import

A task spends 12 seconds parsing input, 3 seconds calculating, and 5 seconds saving. Total elapsed time is 20 seconds. A four-times faster calculation takes 0.75 seconds, reducing total time to 17.75 seconds. Speedup is 20/17.75, approximately 1.13; the time reduction is 11.25%.

Now halve parsing time instead. New total is 6 + 3 + 5 = 14 seconds: approximately 1.43 times speedup and 30% less time. The important lesson is to identify the dominant cost. These stages are assumed sequential; if stages overlap, build a model of the actual overlap rather than adding durations blindly.

Three practical investigations

1. Observe state: create a disposable text file, save one change, make a second unsaved change, and compare the reopened file. Use a test file, not valuable work. Explain which state lived in memory and which was retained.
2. Distinguish quantities: record your device’s RAM and storage capacities. Explain why neither number states how many instructions a program completes per second.
3. Trace independently: change the toy-machine inputs to 9 and 4. Produce the PC, ACC, and result-memory trace before checking your answer. The stored result should be 13.

For each investigation, write what you observed, what it supports, and what it does not establish. One correctly reopened file does not prove durability under every possible crash. One fast task does not prove a machine is faster for every workload.

3. Revision checklist and next steps

• Define a computer without claiming it is infallible or human-like.
• Trace a real task through input, processing, output, memory, and storage.
• Explain how representations acquire meaning through encodings and context.
• Distinguish hardware, software, firmware, programs, and processes.
• Describe conceptual instruction execution without presenting it as a modern processor timing trace.
• Distinguish latency from throughput and calculate a bottleneck example.
• Support each characteristic with an example and a limitation.

Continue with Computer networks: foundations and end-to-end communication, then the remaining networking chapters. Binary arithmetic, logic gates, and detailed architecture belong to Unit 2; memory hierarchies and operating-system details follow in Unit 3.

Revision checkpoints

Explain the main mechanisms in your own words, reproduce the worked examples without looking, and answer the tagged questions before expanding their solutions. When an answer depends on assumptions, state them explicitly.

References and further reading

The supplied MCA syllabus defines the topic placement (Fundamentals of Computers, PDF page 9). The chapter explains its prerequisites and worked examples directly; the references support verification and optional further study. The explanations, examples, diagrams, and practice questions here are original teaching material.

• Harvard CS50, Lecture 0: introductory problem solving and binary representations.
• Operating Systems: Three Easy Pieces, Introduction to Operating Systems, by Remzi and Andrea Arpaci-Dusseau: processes, resource management, and persistence.
• Python documentation: floating-point limitations: representation error and numeric comparisons.
• Unicode Consortium: UTF encodings: bytes, code points, and encodings.
• Cornell computer architecture lecture: performance: performance metrics and Amdahl’s law.
• OSTEP: I/O devices: polling, interrupts, and DMA.
• MIT: automata, computability, and complexity: the boundaries of algorithmic computation.