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.