398 Chapter 32 ■ Conclusion Some people fear that more systematic methods will reduce the scope for individual creativity. In addition, automation tends to mean that fewer people are needed than would otherwise be required. The introduction of new methods has always been linked with the erosion of skills and job losses. In England, the Luddites revolted against employers who replaced their labor by machinery, then reduced wages and the number of jobs. Thus more effective methods often imply: ■ reduced skill (deskilling) ■ lower wages ■ fewer jobs and at the same time a small, highly skilled elite to carry out the difficult tasks. The argument for using systematic approaches is that simple tasks should be made simple – there is no point in struggling to design a software component when there is an easy way. So a method can be empowering, creating time to spend on intrinsically difficult tasks. In conclusion, there is a tension between, on the one hand, the desire of an individ- ual software engineer to exercise their individual creativity and, on the other hand, the wish of organizations to systematize methods and exercise quality control. Reflecting the current diversity, there are a number of suggestions for the future of methods and tools for software development. Software tools Some people see software tools as the future. They see such tools as UML editors, com- pilers, linkers, debuggers, version control software and test frameworks as a means of assisting or automating parts of development. This would improve productivity and software quality. This approach has as its apotheosis the complete automation of soft- ware development along with the elimination of creativity and skill. Amongst others, the proponents of agile methods have reacted against this approach, arguing that tools can constrain and debilitate development. They argue that tools should be used judiciously, as appropriate. Indeed some valuable tools, such as a whiteboard, need not be automated at all. Requirements engineering Some people believe that eliciting and clarifying requirements is the single major prob- lem of software engineering. They concentrate on devising methods and notations that not only accurately capture users’ requirements but also ensure that the developer meets the requirements. The challenge here is to address the problem of communication between user and developer. One has a knowledge of the problem domain; the other has a knowledge of the technology. Their common ground is natural language. 32.7 ● Future methods and tools BELL_C32.QXD 1/30/05 4:29 PM Page 398 32.7 Future methods and tools 399 Formal methods Formal (mathematical) methods are beginning to be used and may become popular, par- ticularly for safety-critical systems. There are two related techniques – formal specifica- tion and formal verification. These methods offer the promise of completely reliable soft- ware – software that has been proved to meet its specification. These approaches begin by documenting the users requirements in a formal mathe- matically based language such as Z. Two factors seem to have inhibited the take-up of these methods: one is the prob- lem of communication with the user, when the specification is expressed in a specialist language such as Z. The second problem is the training of developers in the non-trivial methods used to transform the specification into an implementation. Declarative programming languages Logic programming languages, such as Prolog, are used in developing expert systems. Functional programming languages such as LISP and Haskell, offer the promise of directly expressing what a program should do rather than how it should do it. These languages exist and have an excellent pedigree, but there are problems with executing the programs at an acceptable speed. Their acceptance into mainstream software devel- opment therefore remains speculative. UML After years of rivalry with competing notations, the “three amigos”, Ivar Jacobson, Grady Booch and James Rumbaugh, came together with the single diagrammatic nota- tion UML. It is now the prevalent notation for describing software, but it is only a doc- umentation notation, not a method or a technique. The unified process, suggested by the same authors, came along soon afterwards. There can be no doubt that UML will continue to be important and, indeed, dom- inate the scene for some time. There are, however, problems with UML. First, it is a graphical notation and therefore there are limitations on the ease with which dia- grams can be processed using a software tool. For example, it is desirable to convert diagrams into code and to check for consistency between diagrams. Second, the semantics – the real meaning – of UML has not been defined with the same thor- oughness that the semantics of programming languages has been analyzed. This lim- its any fundamental understanding of the meaning of UML diagrams. Third, while UML is a large and comprehensive notation, there are some things it cannot describe. For example, data flow diagrams are not a part of UML, and the information in a data flow diagram cannot be described in UML. Now it may be that diagrams such as dataflow are redundant, but alternatively it may be that they still have a useful role in design. Components and reuse If only complex software could be constructed by simply taking existing components off the shelf and combining them. This is the aim of component-based software BELL_C32.QXD 1/30/05 4:29 PM Page 399 400 Chapter 32 ■ Conclusion engineering. Such components need to be useful, easy to use and interoperable. They also need to be reliable, fast, secure and scalable. They need to work across net- works, the internet and with web browsers. At the time of writing, the major players in the software industry are offering tech- nologies that claim to meet these goals. Let us look at some of the history of software development methods. In the early days of computing, the hardware was the challenge and programming was considered to be easy – an undemanding activity very similar to clerical work. The first programmers were exclusively women because it was considered unsuitable work for men. Fairly soon it was realized that programming demanded a logical approach and abstract thinking. (Regrettably, sexism asserted itself and the women were replaced by men.) As the problems of software production began to restrict the application of com- puters, the principle of the division of labor was applied to software development. First, the job of the analyst was separated from that of the programmer. Later, with the inven- tion of high-level languages, operating systems and packages, the work of applications programmers was distinguished from that of systems programmers. Sometimes looking at the past helps us to visualize the future. Arguably there have been a number of significant milestones in the history of software engineering. The first was high-level languages, such as Fortran and Cobol, that allowed programmers to express solution in problem-oriented rather than machine-oriented notations. Next was structured programming, the idea that some constructs (such as goto) are dangerous and that design is important. Then came object-oriented design and programming as a way of modularizing software. While each of these innovations was significant, none of them has dramatically solved the problem of ensuring that software is reliable and useful. Perhaps the lesson of his- tory is that there is no silver bullet that can be applied to these problems. Arguably this is because software has an inherent complexity which cannot be eliminated. The demise of applications programming has been regularly predicted for many years, and yet the demand for programmers is ever-increasing. What methods are likely to be used in the future? What is likely to happen to the jobs of those involved in software development? Today, the cost of software generally overwhelms the cost of the hardware it runs on. Software production is labor-intensive and developers are in short supply. A major rem- edy offered is to provide developers with more powerful tools – usually computer based. Examples are UML editors, high-level languages and software development environments. 32.9 ● The future of software engineering 32.8 ● History BELL_C32.QXD 1/30/05 4:29 PM Page 400 Summary 401 In the short-term future, it seems likely that we will continue to see enormous effort spent in developing tools and in ensuring that a set of tools fits together in an integrat- ed manner. At the same time we can expect that end users will carry out their own sys- tem development using software packages that require them to know little about the computer. Coupled with the availability of inexpensive applications packages, the appli- cations programmer seems (as ever) doomed. In the long term, the nature of programming itself could be transformed by a declar- ative style of programming in which the programmer describes a solution to a problem rather than having to specify explicitly how that solution is to be obtained. While the applications programmer may vanish, the role of the systems programmers may be enhanced. Their mission will be to develop products of high quality – reliable, powerful and easy to use. The skills involved in their development may be considerable – not least in the requirement to create demonstrably reliable software, perhaps using for- mal, mathematical approaches. At the other end of the spectrum, the analyst will not become extinct. Their role will be to guide users and an organization in making best use of the available packages. The general trend seems to be: ■ the increasing scrutiny of the software development task ■ systematization of software development ■ the division of labor amongst specialists ■ the automation of tasks using tools ■ software reuse. Summary Software development methods have changed dramatically in the past and look set to do so in the future. The trend is towards the increased use of packages, program generators and automated tools. Long-term, traditional procedural programming languages may vanish to be replaced by declarative languages (functional and or logic languages) – at least for application programming. There is sometimes a tension between the desire to exercise control during project management and the individual programmer’s desire for autonomy. One thing is certain: software engineering will continue to be supremely challeng- ing, creative and enjoyable. BELL_C32.QXD 1/30/05 4:29 PM Page 401 402 Chapter 32 ■ Conclusion Further reading • Ed Yourdon is one of the gurus of software development. In this book he gives a very readable account of the problems with software development today. The book con- tinues by giving a survey of the possible remedies for the problems. It’s altogether a very readable book, free of technicalities and free with opinions. The title reflects the author’s opinion that American programmers are under threat from competition from programmers in Asia – who are paid less, but are better! Edward Yourdon, Decline and Fall of the American Programmer, PTR Prentice Hall, 1993. The sequel to Decline and Fall, which is much more optimistic about the future of the American programmer, provided that they take the initiative and learn about new technologies, like Java: Edward Yourdon, Rise and Resurrection of the American Programmer, PTR Prentice Hall, 1995. A possible future for software development is described in the following reference. Have the predictions turned out to be correct? A.J. Wassermann, The future of pro- gramming, Communications of the ACM, 25(3) (March 1982). Exercises • 32.1 Compare and contrast the following two approaches to software development: 1. placing trust in individual skills 2. relying on systematic methods. 32.2 Compare and contrast the following approaches to software reuse: ■ Unix filters ■ object-oriented classes. 32.3 “Programming is easy.” Discuss. 32.4 “Software engineering is just programming, and programming is just hacking.” Discuss. 32.5 “The scrutiny of software development methods, together with the imposition of stan- dards and procedures for quality assurance has taken all the fun out of it.” Discuss. 32.6 “The tasks involved in software engineering are going to dramatically change over the next five to ten years. In particular, conventional programming will no longer exist.” Discuss. 32.7 Predict the future of software engineering. BELL_C32.QXD 1/30/05 4:29 PM Page 402 Further reading 403 An extensive treatment of the issue of de-skilling is given in: P. Kraft, Programmers and Managers: The Routinization of Computer Programmers in the United States, Springer Verlag, 1984. There have been several exciting accounts of the personal outlook and work methods of programmers. They give insights into how programming is actually done. They also contribute to the folklore of programming. The first, classic book is: G. Weinberg, The Psychology of Computer Programming, Van Nostrand Reinhold, l971. An example of a book on how programmers actually work. In the book, the author reports on interviews with notable programmers: Susan Lammers, Programmers at Work, Microsoft, 1986. Steven Levy, Hackers: Heroes of the Computer Revolution, Anchor Books, 1994. BELL_C32.QXD 1/30/05 4:29 PM Page 403 BELL_C32.QXD 1/30/05 4:29 PM Page 404 APPENDICES BELL_Z01.QXD 1/30/05 4:32 PM Page 405 BELL_Z01.QXD 1/30/05 4:32 PM Page 406 Case studies are used throughout this book to illustrate the explanations. They are also used as the basis for some of the exercises at the end of chapters. Some cases are spe- cific to particular chapters, while others are used (in different ways) in a number of chapters. The cases are designed to capture the reader’s interest and to be typical of a range of applications. They are also applications that are familiar to most readers. The cases could also act as projects that can be carried out in parallel with studying the book. The cases are: ■ an ATM ■ a word processor ■ a computer game ■ a library ■ a patient monitoring system. Each application is presented as an outline requirements specification. Note that they are not offered as model specifications. On the contrary they are presented as specifi- cations for review and criticism, in particular as exercises for Chapter 4 on requirements engineering. The ATM has a screen, a card reader, a small printer, a cash dispenser and a keyboard. The keyboard has numeric buttons, an enter key and a clear key. On both the left and right of the screen are three buttons that allow selection of any options displayed on the screen. The ATM is connected to the bank via a telephone line. The ATM provides facilities to: ■ dispense cash ■ display the current balance. A.1 ● The ATM APPENDIX A Case studies BELL_Z02.QXD 1/30/05 4:32 PM Page 407 . diagrams are not a part of UML, and the information in a data flow diagram cannot be described in UML. Now it may be that diagrams such as dataflow are redundant, but alternatively it may be that they. program generators and automated tools. Long-term, traditional procedural programming languages may vanish to be replaced by declarative languages (functional and or logic languages) – at least for application. They are also applications that are familiar to most readers. The cases could also act as projects that can be carried out in parallel with studying the book. The cases are: ■ an ATM ■ a word