Programmers keep meeting the same problems: one shared object, many kinds of products, many listeners waiting for news. Design patterns are the tried answers. Then come bugs, and testing is how you find them before users do. This note covers both, the way the book orders them.
Chapter 1 of the PECTAA Computer Science 11 book is Software Development. Section 1.6 introduces design patterns and section 1.7 covers software debugging and testing. This note is for FSc Part 1 (1st year, Class 11) students in Lahore, Faisalabad, Sargodha, Rawalpindi, Multan, Gujranwala and the other Punjab boards. Gujrat district comes under the Gujranwala board. PECTAA writes the books. Your own board sets your paper.
What to know
Design patterns. A design pattern is a proven way to solve a problem that appears again and again in software. Think of it as a template: you adapt it to your program instead of inventing a fresh answer each time.
The book describes four commonly used patterns:
- Singleton. Make sure one particular object or resource is created only once in a program, then reuse that same one wherever it is needed. A single settings object shared by the whole app is a typical use.
- Factory. Like a workshop that knows how to make different products. You say what you want and receive the finished item, without handling the details of how it is built.
- Observer. One source keeps a list of interested watchers. When something changes, the source tells all of them, so nobody has to keep checking.
- Strategy. Like a toolbox. Several ways of doing a job are kept ready, and the right one is picked for the task at hand.
Why use patterns (section 1.6.2). The book lists three gains: less code complexity through a clear structure, more code reuse through proven solutions, and better communication because developers share a common vocabulary. The result is software that is flexible, maintainable and easy to understand. A side box mentions that the Model-View-Controller (MVC) pattern is used in web development frameworks.
Debugging (section 1.7.1). A bug is a mistake in software that makes it behave unexpectedly. Debugging means finding bugs and changing the code to fix them. The book names three aids:
- Debuggers: tools that let you step through code, inspect variables and watch the program run.
- Print statements: lines that show variable values at chosen points.
- Code reviews: other developers read your code to spot errors.
Testing (section 1.7.2). Testing checks that software meets its requirements and works as expected. The book arranges it as a ladder, from small parts to the whole system:
- Unit testing: each small unit, such as one function or method, is tested on its own.
- Integration testing: units are joined and their interaction is checked, including interface errors and data flow between modules.
- System testing: the complete system is tested as one, for functionality, performance, security and compliance with requirements.
- Acceptance testing: decides whether the software is ready for release. It is often done by end-users or clients, so it is also called User Acceptance Testing (UAT).
Key points
- Patterns solve design problems; testing finds faults. Do not mix the two in answers.
- Debugging and testing are different. Testing shows that something is wrong. Debugging finds the cause and fixes it.
- Order matters. Unit, integration, system, acceptance: small to big, developer to user.
Worked examples
Example 1. Pick the pattern. A school app must show the same login session everywhere, and only one session object should exist. Answer: Singleton, because one object is created once and reused.
Example 2. Pick the pattern. A weather screen, an alert box and a log must all update when a new temperature arrives. Answer: Observer. The temperature source tells every watcher about the change.
Example 3. Pick the testing level. A function that adds marks returns the right total when checked alone. When joined with the report-card module, totals show in the wrong column. Answer: The function passed unit testing. The fault appears at integration testing, where data flows between modules.
Example 4 (class activity style). Write a unit test idea for a function square(n).
Answer: Call square(4) and check that the result is 16; call square(0) and check 0; call square(-3) and check 9. Each check tests the unit alone.
Common mistakes in the exam
- Saying unit testing tests the whole program. That is system testing.
- Saying acceptance testing is done by programmers. The book says it is often done by end-users or clients.
- Confusing Factory and Strategy. Factory builds objects for you. Strategy chooses which method to use for a task.
- Calling print statements a testing level. They are a debugging aid.
- Leaving out benefits. A "why use patterns" answer needs the three gains: less complexity, more reuse, a shared vocabulary.
Exam technique
- For a pattern question, give the name, a one-line meaning and a small real example.
- For testing, list the four levels in order and say what each checks.
- Use the book's words "in isolation", "interaction", "as a whole" and "ready for release" as anchors.
- Check your board's notice for the topics in your paper.
Practice questions
- Define a design pattern. Answer: A common, reusable solution to a problem that recurs in software development, used like a template.
- Which pattern lets you choose a method from several ready options? Answer: Strategy.
- Name three debugging aids from the book. Answer: Debuggers, print statements and code reviews.
- Which testing level checks data flow between modules? Answer: Integration testing.
- What is another name for acceptance testing? Answer: User Acceptance Testing (UAT).
Ready to practise this? Continue in 1st Year Computer Science.