Feedback: Software Development Paradigm TrapPeter Wolstenholme - 6/13/2006 Mark: Congratulations on a very fine article in Dr. Dobbs Journal. We should not accept poor quality software: take for example the DVD recorder which can easily be blocked by a bad sequence on the remote control, so that it has to be powered-off for a reset. This is a trivial problem, but suppose the same techniques are used to manage a nuclear power startion, or your automobile's engine management? Your 4th. paragraph hits the nail on the head: we need a drastic paradigm change. The real problem is with coding: even in the best languages, it doesn't really scale to large tasks. And it is always possible to get something more or less working, in almost any programming language, given enough effort. Many programmers enjoy this activity and can not see it is dangerous. A new software development paradigm has already been developed, in fact, mainly by Ferdinand Wagner, who has a solid hardware-engineering design background, both academic and practical, as well as considerable software skills and experience. He, with a few others, has written a book which has just been published, describing techiques which have been applied for over 15 years in real, serious projects, even at big companies like A.T.&T. The idea is to take the behaviour of software, well-separated from all data processing, and express it as finite state machines. Not the usual software-engineering course subset of an FSM as used by parsers for compilers, but the real thing as used in hardware design. Drawings are made of state-transition diagrams, with a dual-presentation editor which also shows tables of all the detail for each state. A specification of behaviour is developed this way, and tested. It has to take into account all of the nasty problems which might arise, and is developed until it is 100 % complete. Not just a pretty U.M.L. diagram, with details left for the coders. Something like M.D.A. but one develops platform-independent models only. Not just using FSMs where they are obvious, but applying the concept intensively to replace much of the usual control-flow code. Then this specification is loaded into the target system, and it is executed by a fixed program. The executor program hasn't been modified in the past few years, as it is very general and has no bugs. It runs a compressed version of the specification, and is very efficient. If, when testing the final system, one discovers an error in interpreting the requirements, then the code can't be patched: there isn't any. The specification has to be changed: perhaps an extra state added, and new transitions added. Working at a very abstract level, in fact. Any non-trivial project will need to have quite a few FSM, and a figure of 50 is not at all unusual, but there could be many cases where one FSM design - an object - is used in several instances in one project, each with different parameters. It is of course essential to find a good way of structuring the entire system to avoid problems, and it is usual to employ a strict hierarchy. This is fully discussed in the book. Rather than re-using code, one re-uses FSM designs, from one project to the next, and with changed parameters. These are far less fragile than code. Changes - if needed - to behaviour are quite easily made, with security because of the clean system structure and the high level of abstraction. O.K. there is also some conventional coding in any project, but it is easier to develop and handle because the coded areas are far less complex than in fully-coded projects. There is a real-time data base which manages all the input-output, parameters, inter-FSM communication etc. and the result is that a sort of project "skeleton" is provided on to which the "flesh" of any data-handling or user-interface software is attached. The book's details are at: http://www.crcpress.com/shopping_cart/products/product_detail.asp?sku=AU8086 I have just sent a copy to Ed Nisley, who also writes for Dr. Dobbs. The publisher is sending out review copies this month. Information can also be found at www.stateworks.com. Although the techology has been introduced into various companies, it was only by personal involvement in projects, and there is at present no marketing staff and no financial backing. We are currently developing some difficult Internet-related software - the RFC's are not too well written and existing products seem to be buggy - and hope to use this to get a bit of financial leverage to further develop a business. I am involved, and I find it is a pleasure to be able to discuss really tricky questions at a rather abstract level, rather than through code reviews. (I have also used the basic ideas in a few really trivial projects, in assembler with PIC micro-controllers, and found I could easily adapt to changes in the customer's requirements because of the very well-defined structure of my software, so I did not need to use testing/debugging as a major and time-consuming part of the development process. No-one should.) I am personally convinced that Wagner has made a working prototype of the long-sought silver bullet!
Regards, Peter Wolstenholme - 6/13/2006 Mark: Further to my long e-mail sent to you earlier today, I showed your article to Dr. Wagner. He agreees with your excellent analysis, but not with your proposals for multiprocessor systems. He reckons "it would not improve the software development (which still exists) but make it essentially more complex. Why should a system with 1000 processors be less complex than a system with 1000 threads (assuming that both realize the same tasks)?" A final remark from me: I think that we have confirmed that by designing system behaviour at a high level of abstraction it is easier to take into account all the problems arising when things go wrong with the external environment. I would go even further, although I don't have any hard evidence, in suggesting that a system designed in this way is less likely to do something stupid when a totally unforseen and therefore un-tested situation arises.
Regards, Mark Bereit - 6/14/2006 Peter, Thank you for your comments! The FSM model is one I enjoy a lot... and I've often complained that coding a state machine in C++ ends up suffering from my mechanical translation of approaches. I'm sure there are better tools for coding a state machine than C++! But I haven't experienced them. (Does VHDL count? It's OK for coding a state machine to be implemented for registered logic.) I'd be interested in knowing more about this approach... and I think some of the other responders to my article would be too. Mark Bereit Peter Wolstenholme - 6/15/2006 Mark: You can put anything from me on your web site: no problem! It might even help sell a few copies of our book - that is not so important for itself, but what we are keen to do is stimulate some serious public discussion of Wagner's concepts. Buy a copy (slightly cheaper at Barnes and Noble by the way) and read it over a weekend - you will be astonished. There are some published papers at www.stateworks.com (such as at ECBS 03 and 04) and also some short technical notes which are quite revealing on certain topics, but we find it takes some time for the "penny to drop" and the more skilled someone is at coding, the harder it is for him to see why he should write less code - and do much, much less testing after the project should have been delivered, and no "maintenance." Coding a single state machine in C++ or whatever is not so hard, but what we emphasis in the book is that big systems need to be built with lots of state machines, and in a well organised structure. These state machines are objects in a sense, and can only operate according to their built-in rules: although states are visible from the outside one does not change them from anywhere in a huge mass of code by writing to global variables (this sort of thing has really been done in big companies we won't name, I assure you !). In fact Wagner imported the concept from the hardware field, e.g. V.H.D.L. and his state machines are just the same concept. Many software experts know only a subset, as used in parsing text for compilers, for example, and get the wrong ideas. I have probably put too many ideas in this single e-mail already!
Regards, |