COMP 2110 in 2004 Software Design Lecture 24

COMP 2110 in 2004 Software Design Lecture 24: the Parnas view of design process and product The Parnas paper is available online in the course ebrick David Lorge Parnas and Paul C Clements A rational design process: how and why to fake it IEEE Transactions on Software Engineering, SE-12(2), pp 251 -257, Feb 1986. ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 1

Who? when? where? when you encounter a reference to a work, ask: • who wrote it? (do they have a reputation? ) • where was it published? (does this source have a reputation, any editorial gate-keeper process, an aim of being a publisher for the scholarly record, or for hot news items, for considered and supported arguments, or for top of the head opinion? • when was it published? is it in response to debates and topics of interst only at the time, is it still relevant now? ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 2

Who are Parnas and Clements? • • Parnas is a very influential writer and thinker in the development of the field of Software Engineering. His paper “On the Criteria for to be used for Decomposing Systems into Modules” (1972) is one of the most heavily cited papers in software engineering. He is a Professor at the high class Mc. Master University in Canada, and also University of Limerick in Ireland. A famous study he made was a reverse engineering design study of the software for the avionics of the A 10 attack plane: he knows how to combine theory with practice. Clements now works at the (presitigous) Carnegie-Mellon Software Engineering Institute, and has written several books on Software Architecture since this paper (e. g. Software Architecture in Practice, by Len Bass, Paul Clements, Rick Kazman, Pearson Education, 2 nd edn 2004 ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 3

Where and when? IEEE Transactions in Software Engineering • IEEE is the world’s largest and most authoritative publisher of engineering (and computing) theory and practical theory • IEEE Transactions in X are the journals of record (the magazines such as IEEE Computer and IEEE Software good current topics; but their editorial process is weaker, the quality is generally lower). 1986 hmmm. old, before the Object-Oriented movement was as strong as now; don’t expect to find OO design specifically talked about - but the contrast of design process and product is still relevant and this paper is not completely out of date. ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 4

so what? so when these guys write in this journal about “faking” a process we had all better take notice! and give their arguments some thoughtful consideration ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 5

The Waterfall Software Process – Analysis phase Processes Requirements Analysis -gathering requirements -verifying requirements Product a SRS document describing information models Software Requirements Design Phases (activities) Specification Implementation Testing Maintenance Retirement ANU COMP 2110 Software Design in 2004 Lecture 24 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. Slide 6 time

The Waterfall Software Process – Design phase Processes Requirements Analysis - decide high-level architecture - do detailed design - reviews Design Phases (activities) Product SDD describing modules, classes, interfaces, algorithms, data structures: as text and diagrams Software Design Document Implementation Testing Maintenance Retirement ANU COMP 2110 Software Design in 2004 Lecture 24 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. Slide 7 time

What do they mean by Rational? "A rational design process" - what does "rational" mean here? " • look at the Oxford English Dictionary: • rational • 3. a. Based on, derived from, reason or reasoning. • 7. Descriptive of methods of analysis and planning that make use of calculation to bring about a projected result. ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 8

Why do we want a rational design process? because • the usual process of designing software is irrational and serious problems result from this state of affairs: cost of success, abandonment (and cost of failure), bloat • we would like to derive our programs from a statement of requirements in the same sense that theorems are derived from axioms in published mathematical proofs • Note the terms derive, published, mathematical proofs. . . ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 9

Why is this process an idealization? (why can’t we actually do it this way? ) • • nobody knows in advance exactly what is it that is being designed (the requirements are incomplete and inconsistent) there are many facts that become known later, so there are backtracking loops in the design process so we need to go back and change the design, not optimally we humans cannot manage large amounts of detail specs of the system change for external reasons during the process using humans implies we get human errors we use our favourite ideas, not ideas rationally derived from the particular requirements it is often sensible to make sub-optimal design decisions especially for reasons of cost ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 10

Why is an idealization useful? • • • We can follow an idealized rational process as closely as possible, even if we cannot follow it exactly in reality designers need guidance (see below) an ideal model is better than an ad hoc process a rational process provides a basis for a standard method provides a model for control and review ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 11

What does a rational design process have? At each stage of the process, we need to know: • what product we should work on next • what criteria the product should satisfy • who should do the work • what information the workers should use ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 12

A rational design process INPUT: The description of the system requirements is the input to the ideal, rational design process. OUTPUT: An architecture and a detailed design. Process: 1. Establish and Document the Requirements 2. Design and Document the Module Structure 3. Design and Document the Module Interfaces 4. Design and Document the "uses" relationships between modules 5. Design and Document the Module Internal Structures ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 13

Establish and Document the Requirements The ideal requirements document satisfies: • necessary: every statement should be valid for all acceptable software systems produced (no implementation details appear here) • sufficient: the document should be complete (any system satisfying the stated requirements must be acceptable) • honest: where information is incomplete the doc should say so • the document should be organized as a reference document - not as an introductory narrative Note: a complete and sufficient set of specs would be essential to act as the input if we did have a rational, automatic design process. ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 14

Design and Document the Module Structure • • one form of the resulting document is called a "module guide" the guide defines the responsibility for each module by stating the design decisions that will be encapsulated in the module • a module may consist of submodules • the document should reflect a tree structure, dividing the system into a small number of modules and treat each module in the same way until all modules are "quite small" Note: • we also call this the system architecture or high-level design. (this term now has stronger meaning: we expect more “structure” such as layers, pipelines, MVC in our architectures) • this process appears to echo a (old-fashioned) stepwise refinement process but it also lays down some good qualities of the description resulting from any process ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 15

Design and Document the Module Interfaces • • • the module interfaces must be relatively formal • describe interfaces using parameters, signatures, possibly pre- and post-conditions interface description must include a black-box description of the module – a statement of its purpose, what the module does - not how. just enough information to use the module and nothing more (this is also a property of design by contract) ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 16

Design and Document the "uses" relationships between modules • • The "uses" relationship is another view of a design: it may be an abstraction of the module interfaces or more detail. Can be represented as a matrix, for example. for modern OO we would use a class diagram Captures an important notion of interaction. Important for building subsets: answers the question can we build a part of the system using only a subset of modules? • staged delivery, fail-soft systems, program families. . . Note: other interactions between modules can also be documented, especially flows of control (and incoming event handling), data flows. for modern OO we can use other UML diagrams: sequence, state. . . ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 17

Design and Document the Module Internal Structures • • • explains the intent of the module to the programmer (implementer) of this module documents the effect of each function on any data structures - any side effects as well as pre- and post-conditions of the contract exception handling use pseudocode or partial program code a "verification" argument that the module's properties are sufficient to satisfy the specification allows an efficient review of the design before coding Note: in OO design many classes and methods are almost fully described by the interface alone. Systems where there are more substantial functions involved than just "handle" or "dispatch" events or manipulate simple data need more design work and documentation here. ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 18

Faking the ideal process The design process should produce the documents • in order if possible • with temporary gaps (noted) where information is missing even if the actual process is non-linear By comparison: Mathematical proofs are an artifact of the end of a lot of work - not a story of the process of discovery – but can be read as a rational, linear argument or exposition of the proof. ANU COMP 2110 Software Design in 2004 Lecture 24 - and then fill the gaps in. Do the same with software designs: so that the design document can be read as a – rational, – linear, – structured exposition of the design. Slide 19

Design document and design notebook Besides the design document: it is also useful to record all of the design alternatives and a reason why they were rejected. I would call this record a design notebook – which is not the final design – but it is a very useful adjunct to the design for the initial design team and for the later maintainer. If the design is only recorded as comments within the program code, this aspect is easily lost. ANU COMP 2110 Software Design in 2004 Lecture 24 Slide 20