Structured Analysis and System Specification

I first read this book when it was new, and it made a world of difference in my results. In addition, I was introduced to distributed system design and finite state machines at about the same time, and that turned out to be a genuine winning combination. Some of the difficulties of Demarco's approach are tied into the use of single-threaded code, which was entirely normal at the time, but in the distributed, event-driven world, one escapes those design constraints, and then dataflow diagrams really come into their own. They work best when the processing nodes in a dataflow network can be treated as independent threads that run asynchronously to one another. Better yet, when those processes are designed as state machines, then the asynchronisms can be handled naturally. In addition, state machine tables make it easy to ensure that all possible combinations of state and input have been considered explicitly. Thus, I would not worry overmuch about "structured English mini-specs", because they are too caught up in the single-threaded programming model. Use state machines instead. However, the best part of dataflow diagrams is that the customers actually UNDERSTAND them. They are paying good money for our work, and they certainly deserve to be kept fully in the loop. No other way of representing a system does this well. Only dataflow diagrams. Bear in mind also that most object-oriented designs are still single-threaded, but the problems of single-threading when translating dataflow into executable code and those encountered in object-oriented work are different, so, paradoxically, it is not always easy to implement a classic dataflow diagram with object-oriented methods, and I think this is why dataflow diagrams have received so much less attention in the last ten or fifteen years than they did in the nineteen-eighties. Again, the key is to think in asynchronous, multi-threaded terms, and then dataflow diagrams and objects can fit together quite well. Typically I have a class called "task" or "process" with a "run" method that can be called by a simple round-robin scheduler, which is usually a very simple loop of just a few lines. Each instance of the base process class is a straightforward subclass containing an appropriate state machine, and the process objects are connected by queue objects for transmitting datapackets from one process to another. The end result is that I can often map a dataflow diagram straight onto very similar object-oriented code with little chance for misunderstanding. There are lots of variations on this basic theme, but the general idea is very widely applicable, and also runs very efficiently, since the scheduling overhead is trivial. Each process simply decides if it has any input waiting, and if not control returns to the scheduler almost instantly. No need to design a one-size-fits-all scheduler, when each process is best able to determine its "run-ability" in terms of its own unique requirements.

This book is a classic in the field. In its area may compare in clarity and rigor to the monumental "The Art of Computer Programming" by Donald Knuth. With the advent of OOP and UML, writing clear specifications (or "use cases") is crucial for the success of a design. Structured Analysis is an invaluable tool for deriving use cases from the flux of data. It is simply amazing that UML does not build on the solid foundation of Structured Analysis when it comes to use cases. This book has one significant drawback, though: it does not include events; in fact, it descourages their use. One possible excuse: the material is from 1979. Perhaps at the time the importance of events hadn't become clear yet. Recommended to be used in corroboration with newer books on the topic (such as "Structured Development" by Ward and Mellor).

Computer systems are best understood, designed, implemented, and documented when they are thought of as primarily information flows. The reason should be obvious- at the most essential level, that is all that they do and all that we humans need them to do. This book is all you need to learn how to understand, design,plan, and document the fundamental processing that will be involved in your system. Get this part right and you are well on your way to success with a system. Mess this part up, and no amount of Object Oriented buzz words will save your ass.

This book offers data flow as a simple and powerful metaphor for programming. The idea is this: look at a program as a black box that takes information in and spews information out, then at each stage refine this black box by breaking it out into individual ones. I read this book many years ago and it remains the most useful book on program design that I have read. It was written before object oriented programming but it adapts to it in an obvious way. Forget about UML. Data flow is the best way of presenting the elusive big picture view, that view of the forest that gets obscured by all those trees. It has the following virtues offered nowhere else: 1. It serves as a design tool that you can work with and refine to identify object classes. 2. It is easily understood by computer illiterate clients. 3. It allows programmers new to a project to quickly come up to speed.

If I had to own one book on software design, this would be it. Everywhere I've taken it, people have wondered if some of the examples were "their company." It was introduced to me by a former boss and is easily worth 10x the price of all the courses in "design" I had. Most design is done backwards. DeMarco explains why that is.