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.. Refle
Trang 1398 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 individindivid-ual 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
Trang 2Formal 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 verificaspecifica-tion These methods offer the promise of completely reliable soft-ware – softsoft-ware 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 notanota-tion 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
Trang 3400 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 applicainven-tions 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
Trang 4In 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
Trang 5402 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
Trang 6An 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.
Trang 8APPENDICES
Trang 10Case 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