ABSTRACTION is the act of representing essential features without including background details or explanations. As you move through the design process, the level of abstraction is REDUCED. At the highest level, a solution is stated in broad terms using the language of the problem domain. At lower levels, a more procedural orientation is taken. At the lowest level, the solution is stated so it can be directly implemented. PROCEDURAL ABSTRACTION — a named sequence of instructions with a specific, limited function. "open a door" — implies a long sequence (walk to it, grasp the handle, turn, pull, step aside) which the single word suppresses. DATA ABSTRACTION — a named collection of data describing a data object. "door" — has manufacturer, model, type, weight, dimensions. The procedural abstraction "open" makes use of information contained in the attributes of "door". CONTROL ABSTRACTION — implies a program control mechanism without specifying internal details. A semaphore is a control abstraction: it coordinates activities without exposing how. THE THREE LEVELS OF DESIGN ABSTRACTION in practice: architecture "the report service reads from the data warehouse" component "ReportBuilder.render(spec) → PDF" algorithm the actual paging and sorting logic

MODULARITY — software is divided into separately named and addressable components called MODULES, which are integrated to satisfy the problem requirements. "Modularity is the single attribute of software that allows a program to be intellectually manageable." WHY NOT ONE BIG MODULE? Because the effort to understand it grows faster than its size. Recall from the quality-attributes topic that n components have n(n−1)/2 possible interactions: 10 modules → 45 50 modules → 1225 100 modules → 4950 If every module could talk to every other, modularity would buy nothing. It works only because the design LIMITS which modules interact — which is exactly what low coupling means. WHY NOT INFINITELY MANY MODULES? Because integration cost rises with the number of interfaces. There is an optimum: cost │ ╲ total cost │ ╲ ╱ │ cost per╲ ╱ cost of │ module ╲ ╱ interfacing │ ╳ │ ╱ ╲___________ │ ╱ └──────────────────────────── number of modules ↑ region of minimum cost We know we should modularise, but we do NOT have a formula for the optimum M. Design methods and judgement fill the gap. COHESION — how strongly related the responsibilities of a single module are. WE WANT IT HIGH. Ranked worst to best: COINCIDENTAL unrelated things thrown together ("Utils", "Helpers", "Misc") LOGICAL related by category, chosen by a flag ("doOperation(opCode)") TEMPORAL related only by happening at the same time ("initialise()" doing ten unrelated setups) PROCEDURAL steps of one procedure, but on different data COMMUNICATIONAL operate on the same data SEQUENTIAL output of one part is input of the next FUNCTIONAL everything contributes to one single, well-defined task ← the goal (for classes: OBJECT cohesion — one entity's data and all operations on it) COUPLING — the degree of interdependence between modules. WE WANT IT LOW. Ranked worst to best: CONTENT one module reaches into another's internals — the worst; any change breaks the other COMMON modules share global data EXTERNAL modules share an externally imposed format or protocol CONTROL one passes a flag that controls the other's logic STAMP a whole data structure is passed when only part is needed DATA only the needed simple parameters are passed ← the goal MESSAGE communication only via messages/parameters, no shared state — lowest of all THE PAIRING IS THE POINT: high cohesion and low coupling together mean each module can be UNDERSTOOD, TESTED, CHANGED and REPLACED alone. Neither alone is sufficient — a module can be perfectly self-contained and still be a "Utils" dumping ground.

INFORMATION HIDING (Parnas, 1972) — modules should be specified and designed so that the information (algorithm and data) contained within a module is INACCESSIBLE to other modules that have no need for such information. THE PARNAS INSIGHT, which is subtler than "make fields private": decompose the system by hiding the things MOST LIKELY TO CHANGE. A module is a unit of DESIGN DECISION, not a unit of processing step. If a decision changes, exactly one module should need editing. WORKED — the classic KWIC example, two decompositions: (a) BY PROCESSING STEP: input → circular shift → alphabetise → output. Every module knows the shared data representation. Change from array-of-chars to a packed format and ALL FOUR modules change. (b) BY HIDDEN DECISION: a "line storage" module hides the representation entirely; the others go through its interface. Change the representation and ONE module changes. Both work. Only (b) is maintainable — and this is where the whole idea of encapsulation comes from. BENEFIT: because modules do not depend on each other's internals, changes and errors do not propagate. This is the concept that makes maintenance affordable. STEPWISE REFINEMENT (Wirth) — a top-down design strategy. Architecture is developed by successively refining levels of procedural detail. A hierarchy is developed by decomposing a macroscopic statement of function until programming-language statements are reached. Refinement is the complement of abstraction: abstraction suppresses low-level detail, refinement reveals it. FUNCTIONAL INDEPENDENCE — the direct result of separation of concerns, modularity, abstraction and information hiding. Achieved by developing modules with single-minded function and an aversion to excessive interaction with other modules. MEASURED BY the two criteria above: cohesion (high) and coupling (low). REFACTORING — a reorganisation technique that simplifies the design of a component without changing its function or behaviour. Examines redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed data structures, and any other design failure that can be corrected. SEPARATION OF CONCERNS — any complex problem can be handled more easily if it is subdivided into pieces that can each be solved and optimised independently. A CONCERN is a feature or behaviour specified as part of the requirements model. ASPECTS — a representation of a crosscutting concern, one that cuts across many modules (logging, security, transactions). Handled specially because normal modularity cannot localise them. DESIGN CLASSES — refine the analysis classes by providing design detail that enables implementation, and create a new set of design classes implementing a software infrastructure that supports the business solution.