ANU COMP2110 Software Design in 2004 Lecture 24Slide 1 COMP2110 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 , Feb 1986.

ANU COMP2110 Software Design in 2004 Lecture 24Slide 2 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 COMP2110 Software Design in 2004 Lecture 24Slide 3 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 McMaster 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 A10 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 COMP2110 Software Design in 2004 Lecture 24Slide 4 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 are good current topics; but their editorial process is weaker, the quality is generally lower) 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 COMP2110 Software Design in 2004 Lecture 24Slide 5 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 COMP2110 Software Design in 2004 Lecture 24Slide 6 Implementation The Waterfall Software Process – Analysis phase time Requirements Analysis Design Phases (activities) Testing Maintenance Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. Processes -gathering requirements -verifying requirements Product a SRS document describing information models Software Requirements Specification Retirement

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

ANU COMP2110 Software Design in 2004 Lecture 24Slide 8 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 COMP2110 Software Design in 2004 Lecture 24Slide 9 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 COMP2110 Software Design in 2004 Lecture 24Slide 10 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 COMP2110 Software Design in 2004 Lecture 24Slide 11 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 COMP2110 Software Design in 2004 Lecture 24Slide 12 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 COMP2110 Software Design in 2004 Lecture 24Slide 13 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 COMP2110 Software Design in 2004 Lecture 24Slide 14 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 COMP2110 Software Design in 2004 Lecture 24Slide 15 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 COMP2110 Software Design in 2004 Lecture 24Slide 16 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 COMP2110 Software Design in 2004 Lecture 24Slide 17 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 COMP2110 Software Design in 2004 Lecture 24Slide 18 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 COMP2110 Software Design in 2004 Lecture 24Slide 19 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. - 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.

ANU COMP2110 Software Design in 2004 Lecture 24Slide 20 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.