| | |  | Software Engineering | Home » » » Structured Analysis and System Specification | | | | | | | Product Promotions: | | | | | Description: | | This classic book of tools and methods for the analyst brings order and precisions to the specification process as it provides guidance and development of a structured specification. Covers functional decomposition; data dictionary; process specification; system modeling; structured analysis for a future system. Suitable for practicing systems analysts. | | | Product Details: | | | Author:
| Tom Demarco | | Paperback:
| 348 pages | | Publisher:
| Prentice Hall | | Publication Date:
| May 21, 1979 | | Language:
| English | | ISBN:
| 0138543801 | | Product Length:
| 9.2 inches | | Product Width:
| 6.9 inches | | Product Height:
| 0.9 inches | | Product Weight:
| 1.35 pounds | | Package Length:
| 9.2 inches | | Package Width:
| 7.0 inches | | Package Height:
| 0.9 inches | | Package Weight:
| 1.3 pounds | | Average Customer Rating:
|  based on 8 reviews |
| | | | Customer Reviews: | |
Average Customer Review:
 ( 8 customer reviews )
Write an online review and share your thoughts with other customers.
Most Helpful Customer Reviews
31 of 31 found the following review helpful:
 Read this classic first!Mar 05, 1999
By Philip M. Gennuso
"philscorner"
This book on analysis and requirements specification is well worth the read. It really is the classic exposition of structured analysis and it is remarkable how many of the ideas presented are still in use. The only section I found somewhat out of date was the material on data access diagrams, which I have never seen anyone actually use in any shop I have worked with. Otherwise this book would rate 5 stars. The language and style is clear and practical without being patronizing. Examples are plentiful so if you want, you can actually go through each step. If you have done this sort of thing professionally you will find yourself reading rapidly. So much of this work is already a part of your knowledge. With that said, even if you have been working in the field a number of years you will still find information that is new and revealing. As such it is a reference, a review and a tutorial.
17 of 17 found the following review helpful:
Changed the way I look at programmingAug 09, 2002
By Martin P. Cohen
"Seeker"
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.
12 of 12 found the following review helpful:
A classic and worth the priceJun 07, 2000
By Deirdre Saoirse
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.
5 of 5 found the following review helpful:
Still very valuable.Apr 29, 2007
By Dave Johnson
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.
The foregoing is hardly the whole story, but this general approach has worked well for me for almost thirty years. Thus, I heartily recommend Demarco's book to all software designers and system analysts. If you are not already fluent with dataflow design, then you should waste no time becoming so. Your clients will be much happier for it, and that is always good for business.
5 of 5 found the following review helpful:
Simply a classic in the fieldJun 19, 2005
By FILIP Marius
"adna"
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).
See all 8 customer reviews on Amazon.com
| | |
|
