Best Practices in Software Development: Principles of Good
Total Page:16
File Type:pdf, Size:1020Kb
Best Practices in Software Development: Principles of Good Design Ansgar Fehnker Based on slides by: Arend Rensink, Christoph Bockisch, Mira Mezini, Lodewijk Bergmans What is Good Software? . External criteria . Correctness, robustness, extensibility, efficiency, ease of use ... Stakeholders: . end user, e.g., a travel agent using a flight reservation system . persons who purchase the software, e.g., an airline executive acquiring or commissioning flight reservation systems . Internal criteria . Modularity, readability, reusability, ... Stakeholders: . IT professionals with access to the source . Only external factors matter in the end . but the key to achieving them is in the internal ones Patterns of Software Development 2 External vs. Internal Criteria Patterns of Software Development 3 External Criteria: Correctness . What is correctness? . the ability of a software product to perform its task . as defined by its specification . Examples of (in-)correct systems? Application . Due to complexity, methods for ensuring correctness will usually be conditional or layered . each layer relying on lower ones Hardware Patterns of Software Development 4 External Criteria: Robustness . What is robustness? . the ability of software to react appropriately to abnormal conditions . Examples of (non-)robust systems? . Difference robustness/correctness? . Correctness addresses the behavior of a system in cases covered by its specification . Robustness characterizes what happens outside of that specification Patterns of Software Development 5 External Criteria: Efficiency . What is efficiency? . place as few demands as possible on hardware resources: . processor time, memory, bandwidth, power . Examples of (in-)efficient systems? . A software case of split personality . Mr. Microsecond: shows an exaggerated concern for micro- optimisation. “Premature optimization is the root of all evil” . Dr. Abstract: “make it right before you make it fast” ... “next year’s computer model is going to be 50% faster anyway” . Some more aphorisms: . Donald Knuth: We should forget about small efficiencies, say about 97% of the time. Yet we should not pass up our opportunities in that critical 3% . Betrand Meyer: do not worry how fast it is unless it is also right Patterns of Software Development 6 External Criteria: Extensibility . What is extensibility? . the ease of adapting software to changes of specification . Examples of (non-)extensible systems? . A problem of scale . as software grows bigger, it becomes harder to adapt . a large software system resembles a giant house of cards in which pulling out any one element might cause the whole edifice to collapse . “legacy software”: software you are afraid to touch . Change is ubiquitous in software development . even in scientific computation, where we may expect the laws of physics to stay in place, our way of understanding and modelling physical systems will change . lesson: design for change! Patterns of Software Development 8 External Criteria: Extensibility . Two principles . design simplicity . decentralised architecture You know you have achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away. Antoine de Saint-Exupéry Patterns of Software Development 9 Bad Extensibility = + Patterns of Software Development 10 Good Extensibility = + Patterns of Software Development 11 Internal criteria: Reusability . What is reusability? . the ability of software elements to serve for the construction of many different applications . Examples of (non-)reusable components? . Software systems often follow similar patterns . it is possible to exploit this commonality and avoid reinventing solutions . by capturing such a pattern, a software component becomes more reusable . Erich Gamma, Ralph Johnson, Richard Helm, John Vlissides. "Design Patterns: Elements of Reusable Object-Oriented Software" (2nd edition), Addison Wesley, 1998 Patterns of Software Development 12 Extensibility & Reusability . Similar ideas are useful for improving both qualities; e.g.: . decentralized architectures . components are self-contained components . communication only through restricted and clearly defined interfaces . The term modularity will cover extensibility and reusability Software spends 60%-80% of its lifetime in maintenance! Patterns of Software Development 13 How is Modularity Achieved? . by decomposing a system into modules . what is a module? . what principles are applied during decomposition? . some characteristics of modularized systems . separate, distinct modules for each task . well-defined inputs and outputs . tested independently . maintenance in modular fashion Patterns of Software Development 14 Modularity (Betrand Meyer) . Bertrand Meyer. "Object-Oriented Software Construction" (second edition), Prentice Hall, 1997 . Single definition of modularity does not cover all aspects . as with software quality, we must look at modularity from more than one point of view . Requirements on a modular design method . five criteria, five rules, and five principles . criteria are independently aimed at characterizing modular design methods . rules follow from criteria . principles follow from criteria and rules Patterns of Software Development 15 Modularity: Five Criteria . A modular design method should satisfy five fundamental requirements: 1. Decomposability 2. Composability 3. Understandability 4. Continuity 5. Protection Patterns of Software Development 16 Criterion 1: Decomposability A software construction method satisfies Modular Decomposability if • it helps in the task of decomposing a software problem into a small number of less complex subproblems, connected by a simple structure, and independent enough to allow further work to proceed separately on each of them. Divide to conquer ... Patterns of Software Development 17 Criterion 1: Decomposability (continued) . Corollary of modular decomposability: division of labor (separation of concerns): . once you decompose a system into subsystems you should be able to distribute work on these subsystems among different groups . Difficult goal since it limits dependencies that might exist: . keep dependencies between subsytems to the bare minimum . dependencies must be known Patterns of Software Development 18 Criterion 2: Composability A design method satisfies Modular Composability if • it favours the production of software elements which may be freely combined with each other to produce new systems, possibly in environments quite different from the one in which they were initially developed. Compose to rule ... Patterns of Software Development 19 Criterion 2: Composability (continued) . The composability criterion yields software elements that will be sufficiently autonomous . I.e., sufficiently independent from the immediate goal that led to their existence . Context information removed or clearly identified . Serves reusability . the aim is to find ways to design software elements performing well- defined tasks and being usable in widely different contexts Patterns of Software Development 20 Criterion 2: Composability (continued) . Example: Unix shell conventions . Unix commands operate on sequential character streams as input, and produce an output with the same standard structure . This makes them composable through the | (pipe) operator: A | B represents a program which will take A’s input, have A process it, send the output to B as input, and have it processed by B Patterns of Software Development 21 Criterion 3: Understandability A method favours Modular Understandability if • it helps produce software in which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others. Patterns of Software Development 22 Criterion 4: Continuity A method satisfies Modular Continuity if • in the software architectures that it yields, a small change in a problem specification will trigger a change of just one module, or a small number of modules. change in spec change in modules Patterns of Software Development 23 Criterion 4: Continuity (continued) . Example: symbolic constants . style rule: instead of using numerical or textual constants directly, rely on symbolic names . the actual values only appear in a constant definition . if the value changes, the only thing to update is the constant definition . This rule is a wise precaution for continuity since constants, in spite of their name, are remarkably prone to change . it also improves understandability Patterns of Software Development 24 Criterion 5: Protection A method satisfies Modular Protection if • it yields architectures in which the effect of an abnormal condition occurring at run- time in a module will remain confined to that module, or at worst will only propagate to a few neighbouring modules. (this does not address the avoidance or correction of errors, but the aspect directly relevant to modularity: their propagation) Patterns of Software Development 25 Criterion 5: Protection (continued) . Example: validating input at the source . making every module that inputs data also responsible for checking input data validity is good for modular protection (assertions) . design-by-contract . Counter-example: undisciplined exceptions . exceptions make it possible to decouple the algorithms for normal cases from the processing of erroneous cases . but they must be used carefully to avoid hindering modular protection Patterns of Software Development 26 Modularity: Five Rules . From the criteria, five