4.3System Development Techniques (Object Orientation, UML, Design, Testing)

A common way to lose points on system-development questions is fuzzily remembering the boundary between similar terms. Precisely nailing down the relative relationships between paired concepts — whether external or internal design is closer to the user's viewpoint, whether lower or higher coupling is better, which white-box coverage criterion is the strictest — is what directly translates into points at the AP level. This section walks through object orientation, UML, module design, and test techniques in the order of the development process.

4.3.1The development process and object orientation

• The development process flows: requirements definition -> external (basic) design (user-facing screens, reports, and interfaces) -> internal (detailed) design (developer-facing module structure, algorithms, and data structures) -> programming -> testing. Distinguish the viewpoint: external design is specification a user can review; internal design is implementation-oriented specification invisible to the user.
• The three pillars of object orientation are encapsulation (bundling data with the operations on it, achieving information hiding of unnecessary internal detail from the outside), inheritance (defining a new subclass that inherits the properties of an existing superclass, reusing common parts while adding differences), and polymorphism (the same method call executes different behavior depending on the actual runtime type of the object it is called on, realized via method overriding).
• Distinguish the roles: encapsulation = hiding, inheritance = passing down, polymorphism = the same call producing different behavior. For example, if a superclass "Shape" has an area() method that subclasses "Circle" and "Rectangle" each override with their own formula, the caller can invoke the same method without knowing the concrete shape type and still get the correct area — a classic example of polymorphism.

4.3.2UML and module decomposition

• The major UML diagrams: a class diagram shows the static structure among classes — association, aggregation, generalization (inheritance), etc.; a use case diagram shows externally observed behavior between actors (users) and use cases (system functions), useful during requirements definition; a sequence diagram shows messages exchanged between objects in chronological order, useful during design when tracing a flow of processing.
• Distinguish what each diagram captures: a class diagram = static structure; a sequence diagram = dynamic flow over time; a use case diagram = how functionality appears from outside. In a class diagram, generalization represents the superclass-subclass (inheritance) relationship, aggregation represents a loose "whole-part" ownership (a part can exist independently of the whole), and composition represents a stronger ownership (a part's lifecycle depends on the whole).
• Module decomposition quality is judged by coupling (the strength of dependency between modules) and cohesion (how tightly the elements within a module belong together). Lower coupling is better (loosely coupled modules are more independent and easier to maintain). Higher cohesion is better (a module devoted to a single purpose has the strongest, i.e. functional, cohesion). Do not mistakenly remember "higher coupling is better" — coupling and cohesion are evaluated in opposite directions.

4.3.3Test techniques and reviews

• A white-box test designs test cases by focusing on the program's internal structure (control flow). The coverage criteria, from weakest to strongest: statement coverage (C0) (execute every statement at least once), branch/decision coverage (C1) (execute both true and false of every branch at least once), condition coverage (C2) (execute both true and false of every individual condition at least once), and multiple condition coverage (cover every combination of conditions — the strictest, requiring the most test cases).
• A black-box test designs test cases by focusing only on the input/output specification, without looking at internal structure. The standard combination is equivalence partitioning (choosing representative values from equivalence classes—sets of inputs expected to produce the same result per the spec) and boundary value analysis (testing values at and around class boundaries, based on the empirical rule that bugs cluster near boundaries).
• Satisfying branch coverage (C1) automatically satisfies statement coverage (C0), but condition coverage (C2) does not automatically satisfy branch coverage (C1) (covering each individual condition's true/false does not guarantee the overall decision's true/false combinations are covered). A review is a manual quality-assurance activity examining code or documents. Distinguish a walkthrough (an informal format led by the author, walking through the work to gather feedback) from an inspection (a formal format led by a moderator with defined roles, and stricter).

Take an e-commerce system's "compute the coupon discount" feature to concretely compare test techniques. Say the spec is: "no discount if the purchase amount is under 3000 yen; 10% off from 3000 yen up to (not including) 10000 yen; 20% off from 10000 yen up." For black-box testing, equivalence partitioning identifies three equivalence classes from this spec — "under 3000," "3000 up to under 10000," "10000 and above" — and tests representative values from each (e.g. 1000, 5000, 15000 yen). But equivalence partitioning alone can miss off-by-one boundary bugs (e.g. mistakenly writing > instead of >=), so it is combined with boundary value analysis, testing values just before and after each boundary (2999, 3000, 9999, 10000 yen). For white-box testing, attention shifts to the branch structure of the implementation's if statements themselves. Suppose the implementation is a nested branch: if (amount >= 3000) { if (amount >= 10000) {20%} else {10%} } else {no discount}. Statement coverage (C0) is lenient, requiring only that every line execute once; branch coverage (C1) requires each if's true and false outcome to be exercised at least once; condition coverage (C2) goes further, tracking the true/false of each individual comparison operator. The tricky part is that satisfying condition coverage does not automatically satisfy branch coverage: in a decision combining multiple conditions with &&/||, covering each individual condition's true/false does not guarantee the overall decision's outcomes are covered, so multiple condition coverage is needed for stricter verification. How this discount logic is decomposed at design time is a module decomposition question: carving it out into a single-purpose module that only "computes the discount rate" gives it high cohesion, and keeping it separate from unrelated processing like order handling or inventory management keeps coupling low.

4.3.4Section summary

• External design = user viewpoint; internal design = developer viewpoint. Encapsulation = hiding; inheritance = passing down; polymorphism = same call, different behavior
• Class diagram = static structure; sequence diagram = chronological order; use case diagram = external view of functionality. Good design: low coupling, high cohesion
• White-box coverage strength: statement < branch < condition < multiple condition. Black-box testing = equivalence partitioning + boundary value analysis