COMP2110 in 2004 Software Design Lecture 24: the Parnas view of design process and product

1. COMP2110 in 2004 Software DesignLecture 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), pp251-257, Feb 1986.

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?

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, andhas written several books on Software Architecture since this paper (e.g. Software Architecture in Practice, by Len Bass, Paul Clements, Rick Kazman,Pearson Education, 2nd edn 2004

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 Transactionsin 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). 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.

5. so what? so when these guys write in this journalabout “faking” a processwe had all better take notice! and give their arguments some thoughtful consideration

6. Processes-gathering requirements-verifying requirements Product a SRS documentdescribinginformation models Software Requirements Specification Requirements Analysis Design Implementation Phases (activities) Testing Maintenance Retirement Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. The Waterfall Software Process – Analysis phase time

7. ProductSDDdescribingmodules, classes, interfaces, algorithms, data structures:as text and diagrams SoftwareDesignDocument Processes - decide high-level architecture - do detailed design - reviews Requirements Analysis Design Implementation Phases (activities) Testing Maintenance Retirement Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. The Waterfall Software Process – Design phase time

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.

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 requirementsin the same sense that theorems are derived from axiomsin published mathematical proofs • Note the terms derive, published, mathematical proofs...

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

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

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

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: • Establish and Document the Requirements • Design and Document the Module Structure • Design and Document the Module Interfaces • Design and Document the "uses" relationships between modules • Design and Document the Module Internal Structures

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.

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 moduleby 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 modulesand 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 processbut it also lays down some good qualities of the description resulting from any process

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)

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...

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.

19. 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. Faking the ideal process

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.