Ruminations on the paper by Parnas and Clements. COMP2110/2510 Software Design Software Design for SE October 29, 2008

Transcription

1 Ruminations on the paper by Parnas and Clements COMP2110/2510 Software Design Software Design for SE October 29, 2008 Ideal Real Department of Computer Science The Australian National University 29.1

2 1 2 3 The Ideal Software 4 A Mathematical 5 The Real Software 6 Ideal Real 29.2

3 A Rational Design Ideal The purpose of this lecture is to discuss the paper A Rational Design process: How and Why to Fake It?" written in 1986 by David L Parnas and Paul C Clements (IEEE Transactions on Software Engineering, SE 12(2), pp ) Real 29.3

4 Who Is David Lorge Parnas? Essentially: one of the fathers of Software Engineering Currently: Professor of SE and Director of SQRL (Software Quality Research Laboratory), at Dept. CS&IS, Faculty of Informatics and Electronics, University of Limerick (Ireland) Previously: researcher at the Naval Research Laboratory (USA), professor of McMaster University (Canada) His most influential papers: On the Crireria to Be Used in decomposing Systems into Modules, 1972 (fundamentals of programming to interface and information hiding before modular and OO programming became the mainstream) On the Design and Development of Program Families, 1976 (anticipated the idea of Design Patterns) Designing Software for Ease of Extension and Contraction, 1979 (put requirements to the centre of the software development process, and introduced uses relationships for their analysis) A Rational Design process: How and Why to Fake It?, 1986 (discussed the importance of having a model of the design process which will guide creation of precise and open documentation of the software process) Ideal Real became a paragon of professional honesty and ethics for his stance on perspectives of software development for the Strategic Defense Initiative ( Star Wars ) in 1980s (see Software Aspects of Strategic Defense Systems, Comm. of ACM, 28(12), p , 1985) 29.4

5 Says On the profession: There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more. On the most-repeated mistake in SE: People tend to underestimate the difficulty of the task. Overconfidence explains most of the poor software that I see. Doing it right is hard work. Shortcuts lead you in the wrong direction and they often lead to disaster. On the modern UML fad: Imprecisely defined notation leads to software that is almost right. Software that is almost right is wrong. Undefiened Modelling Languages are quicksand (and bad idea). Advice for computer science/software engineering students:... pay more attention to the fundamental ideas rather than the latest technology. The technology will be out-of-date before they graduate. Fundamental ideas never get out of date. However, what worries me about what I just said is that some people would think of Turing machines and Goedel s theorem as fundamentals. I think those things are fundamental but they are also nearly irrelevant. I think there are fundamental design principles, for example structured programming principles, the good ideas in "Object Oriented" programming, etc Advice for his fellow professional: Stop the numbers game! Counting papers slows the rate of scientific progress. Ideal Real 29.5

6 The Ideal View of Software The analysis stage in the Waterfall Model Analysis es -gathering requirements -verifying requirements Design Product a SRS document describing information models Software Specification Ideal Real Phases (activities) Implementation Testing Maintenance Retirement es and Products are well defined and implemented consistently in a rational, error-free, way 29.6

7 The Ideal View of Software The design stage in the Waterfall Model Requirement s Analysis es - decide high-level architecture - do detailed design - reviews Design Product SDD describing modules, classes, interfaces, algorithms, data structures: as text and diagrams Software Design Document Ideal Real Phases (activities) Implementation Testing Maintenance es and Products are well defined and implemented consistently in a rational, error-free, way 29.6

8 What is Rational and why do we need it? Oxford English Dictionary: 3a based on or in accordance with reason or logic : I m sure there s a perfectly rational explanation. 7 Descriptive of methods of analysis and planning that make use of calculation to bring about a projected result. Ideal Real Why do we want a rational design process?: 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 29.7

9 The Mathematical How lay people think mathematicians work definitions proof (deductions, reasoning) new knowledge (theorems) Ideal Real axioms At least this is an impression if to judge about this from the documented accounts of their job published articles, books etc which present the results of their work 29.8

10 The Mathematical How mathematicians really work definitions? intuitions conjectures trials and errors dreams?? essentials of new knowledge theorems Ideal Real Proof (deduction, reasoning) strict new knowledge lemmata axioms This is what really happens in their heads 29.8

11 The Software Development The Ideal Software requirements Ideal analysis Real design implementation testing Time (minutes, hours, days...) 29.9

12 The Software Development The Real Software requirements Ideal analysis Real design implementation testing Time (minutes, hours, days...) 29.9

13 Why the cannot be Ideal? In most cases the people who commission the building of a software system do not know exactly what they want and are unable to tell us all that they know. Even if we knew the requirements, there are many other facts that we need to know to design the software. Many of the details only become known to us as we progress in the implementation. Some of the things that we learn invalidate our design and we must backtrack. Because we try to minimize lost work, the resulting design may be one that would not result from a rational design process. Even if we knew all of the relevant facts before we started, experience shows that human beings are unable to comprehend fully the plethora of details that must be taken into account in order to design and build a correct system. The process of designing the software is one in which we attempt to separate concerns so that we are working with a manageable amount of information. However, until we have separated the concerns, we are bound to make errors. Even if we could master all of the detail needed, all but the most trivial projects are subject to change for external reasons. Some of those changes may invalidate previous design decisions. The resulting design is not one that would have been produced by a rational design process. Human errors can only be avoided if one can avoid the use of humans. Even after the concerns are separated, errors will be made ( I err therefore I am! ). We are often burdened by preconceived design ideas, ideas that we invented, acquired on related projects, or heard about in a class. Sometimes we undertake a project in order to try out or use a favourite idea. Such ideas may not be derived from our requirements by a rational process. Often we are encouraged, for economic reasons, to use software that was developed for some other project. In other situations, we may be encouraged to share our software with another ongoing project. The resulting software may not be the ideal software for either project, ie, not the software that we would develop based on its requirements alone, but it is good enough and will save effort. Ideal Real 29.10

14 Why Idealization is useful? If the above is well known and accepted (it is!), why is all these activities conferences, workshops, commercial courses purporting to describe and teach you logical ways to design software? The reasons: we can follow an idealized rational process as closely as possible, even if we cannot follow it exactly in reality (this will help to achieve better results with all other conditions equal) designers need guidance (overwhelmed and unsure where to start, with a good understanding of the ideal process, we will be able to know how to proceed) an ideal model is better than an ad hoc process a rational process provides a basis for a standardized method easier to have good design reviews, to transfer people, ideas, and software from one project to another provides a model for control and review it becomes easier to measure the progress that a project is making (we can compare the project s achievements with those that the ideal process calls for, and identify areas in which we are behind or ahead) makes easier for the project s progress review by outsiders (essential for good management) Ideal Real 29.11

15 What does the Faking involves? The most useful form of a process description will be in terms of work products. For 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 Management of any process that is not described in terms of work products can only be done by mind readers. Only if we know which work products are due and what criteria they must satisfy can we review the project and measure progress. Ideal Real 29.12

16 A rational design process This is what we want: Input: The description of the system requirements is the input to the ideal, rational design process Output: An architecture and a detailed design : A Establish and Document the B Design and Document the C Design and Document the D Design and Document the uses-relationships between modules E Design and Document the Module Internal Structures Ideal Real 29.13

17 Establish and Document the 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 documentation should say so referenced: the document should be organized as a reference document not as an introductory narrative (harder but pays off in long term) Ideal Real A complete and sufficient set of specs would be essential to act as the input if we did have a rational, automatic design process

18 Design and Document the What is in the Module Guide: It defines the responsibilities of each of the modules by stating the design decisions that will be encapsulated by that module. The module may consist of submodules, or it may be considered to be a single work assignment. The document should reflect a tree structure, dividing the system into a small number of modules. It should treat each module in the same way until all modules are quite small A module guide is needed to avoid duplication, to avoid gaps, to achieve separation of concerns, and most of all, to help an ignorant maintainer to find out which modules are affected by a problem report or change request. If it is kept up-to-date, this document, which records our initial design decisions, will be useful as long as the software is used. A guide that was simply a list of those modules, with no other structure, would help only those who are already familiar with the system. The module guide should have a tree structure, dividing the system into a small number of modules and treating each such module in the same way until all of the modules are quite small. Note: Today, we usually call the module guide section 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. Ideal Real 29.15

19 Design and Document the Efficient and rapid production of software requires that the programmers be able to work independently. The module guide defines responsibilities but it does not provide enough information to permit independent implementation. A module interface specification must be written for each module. It must be formal and provide a black box picture of each module. The module interface section must include: 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 (which is also a property of design by contract) timing constraints and accuracy constraints, where necessary (esp. for real-time systems) definition of undesired events Ideal Real 29.16

20 Design and Document the module uses relationships The Uses Relationships section includes: 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 the entry in position (A,B) is true if and only if the correctness of program A depends on the presence in the system of a correct program B. For modern OO we would also 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... ) Modules A B C D A true false false B false false false C true true false D false true false Ideal Real 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, collaboration, state

21 Design and Document the Module Internal Structures The Internal Structure section: 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 (undesired events) handling use pseudocode or partial program code (the authors make no bone about using real chunks of code if their syntax can be verified by a compiler even better!) a verification argument that the module s properties are sufficient to satisfy the specification allows an efficient review of the design before coding Ideal Real 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

22 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. We can 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. Ideal Real 29.19