While traditional transformation systems manifest a predetermined stateless behavior, and analysis of these is focused on how inputs are deterministically transformed into outputs, reactive systems are state-based, and exhibit a dynamic stimulus-response behavior. Basically, the reactive system under development (SUD) interacts with its environment by exchanging messages. Events in the environment arrive as stimuli to the SUD, and system responses are converted into actions in the environment. One of the recurring themes in the book, which is highlighted by the system engineering argument, is the importance of the environment. The argument states that the assumptions about the environment, plus the design specification, determine the properties of the resulting system, once the SUD is introduced. As a consequence, Wieringa advocates a more thorough environment specification than is usually done.
Wieringa focuses on specification techniques, describing their notations, explaining their semantic details, and offering some guidelines for their correct use. These techniques are arranged into four groups:
Once these types of notations are thoroughly surveyed, Wieringa wraps up the discussion of specification techniques with a chapter devoted to requirements-level system architectures, similar in spirit to the Object Management Group's model-driven architecture approach.
In the final part of the book, three different specification methodologies are described to illustrate how they combine different notations. Those methodologies are postmodern structured analysis (a Yourdon-style variant of structured analysis), Harel et al.'s Statemate, and a subset of the unified modeling language (UML), where the author introduces communication diagrams to ensure coherence between static structure diagrams (object and class diagrams) and behavior descriptions (statecharts).
Finally, in the last chapter, Wieringa presents "not yet another method" (NYAM), "the gist of existing methods," where he acknowledges that there is no silver bullet, and no single recipe for all specification problems. In fact, not all notations need to be used for all systems. The proper choice depends on the SUD functionality, and the notation's intended use (from informal prototypes to formal model checking).
In short, the author does his best to cover a wide range of specification techniques, and offers valuable insight into their underpinnings, complementing his discussions with case studies, exercises, and an uncommonly well-written glossary. The origins and rationale behind some of Wieringa's ideas can be found in the bibliographic remarks, along with some gems in the bibliography that deserve further reading.
The major shortcoming I found in this book was in its deviation from terminology and notation standards. For example, the author dismisses common terms, such as use cases or nonfunctional requirements, because of their possible connotations. In the first case, he prefers to use the term "service," although his focus on delivered value is akin to Constantine's essential use cases . With respect to nonfunctional requirements, which have "the connotation that whether this property is present cannot be objectively decided" (p. 44), Wieringa misses the opportunity to use the goal analysis technique, which Gilb advocates , and about which it is clearly stated in this book that "all critical attributes can be specified in measurable testable terms."
Wieringa introduces his own share of new notations and variants (even the overly complex UML is somewhat expanded). We do not need more new models and notations, however; we certainly need better tools, and more practitioners to effectively apply known techniques . With regard to this need, Wieringa's book is of value for practitioners, and food for thought for thinkers in general, and researchers in particular. If you want to fully understand the details of, and parallelisms between, specification notations, Wieringa is one of the best places to start.
-- Fernando Berzal, ACM Computing Reviews, 2003
 Gilb, T.: Principles of Software Engineering Management. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1988.
 Wiegers, K.: Read my lips: No new models!. IEEE Software 15, 5(1998), 10-13.
Davis has collected an interesting set of his previous essays on relevant issues for the software practitioner. He has appended a few questions at the end of each essay. That is all there is about actual debates in this book. The questions might stir debates in a classroom setting, or simply make you position yourself from a different point of view. This collection of essays is worth a look.
Funnily, a recurring theme in some essays is the use (and abuse) of software tools and techniques. The software development community has lived through many "silver bullets," which tend to be temporary fads. Oversold techniques are often easy to follow and misuse, because if they fail, they can be blamed, and our own egos are therefore protected. Unfortunately, that makes us look like lemmings (one of Davis' landmark essays). Throughout the book, you will be reminded that there are proven techniques that work, and produce moderate gains. Even "silver bullets" are good when properly used, obviously.
Management topics are covered in a whole section of the book. The author, a manager himself, describes the hard knocks that rookie managers suffer, and their most common mistakes, and even notes that a good manager has to disobey orders sometimes. As an entrepreneur, the author shares the lessons he learned at his own startup, as well as Ed Bersoff's lessons learned at BTG, providing an invaluable retrospective for those who aim to create a new company.
Another section of the book addresses requirements, one of the author's pet topics. He makes it clear that requirements have to do with understanding, not just with documentation. Requirements describe the external view of a system (namely, its phenotype), hence its object-oriented analysis limitations, as detailed in one of the essays. Some of the other essays in this section provide a good overview of the complete analysis phase, emphasizing requirements elicitation, triage, and volatility (as well as its inherent impact on estimation).
As someone who has worked in the industry, and also at universities, the author devotes another set of essays to technology transfer. The gap between researchers and practitioners is discussed, a gap that, surprisingly, exists in requirements engineering, where engineers are supposed to be able to understand their users' needs. As any good analyst would do, the author dissects the academic system, and highlights the severe limitations of the current educational model, where instructors usually don't have real-life experience in the topics they are supposed to teach, and incentives usually interfere with the ability to obtain practical research results.
Some personal recollections from the author complete the miscellaneous set of essays in the book. Since it could not be any other way, the perennial question about software development as an art or as engineering also crops up; a funny essay written by Jim Sanders highlights the parallels between writing music and writing software.
Even though most of the essays in this book are not new, they are as relevant today as they were when they were originally published. Two-thirds of the essays in this book will be familiar to IEEE Software readers, because they are rehashed from this bimonthly magazine (this fact should come as no surprise, since Davis is the former editor in chief). Despite this apparent lack of novelty, the topics covered by these essays deserve to be revisited with the benefit of hindsight, given that the current situation is not much different from what it was a few years ago. Moreover, the few essays that haven't been published before, and those that are harder to find, are valuable; they round off this excellent book.
This book deserves a place on any software engineer's bookshelf, next to Glass' book . Like that book, this one will "make you think about the things you might have been taking for granted." At least, it will make you keep your brain in gear, an essential quality for software engineers settled into their daily routines.
If you think you are already acquainted with Davis' recommendations, let his common sense and sagacity become widely known and passed on. Get a copy of this book for your manager if you are a developer, for your boss if you are a manager, or for your partners if you are an entrepreneur. I did.
-- Fernando Berzal, ACM Computing Reviews, 2005
Facts and Fallacies of Software Engineering. Addison-Wesley Professional, Boston, MA, 2002.
This book is outstanding because of its peculiar organization. The book unfolds as an actual software project (two parallel projects, actually). The two case studies weave together the concepts covered, which are introduced at the points of the projects when they are most useful, lowering the learning curve. From a pedagogical point of view, the recurring use of the same case studies throughout the book is much better than devising unrelated examples for each topic covered (in spite of the typical, well-understood, fairly unimaginative, and, to some extent, boring point of sale (POS) system). Even though you may find this technique repetitious at times, since it often returns to the same underlying concepts to reinforce explained ideas, every experienced instructor uses this basic teaching technique. In any case, the projects follow an iterative process, so the book just reflects what actually happens in practice.
With respect to the book's contents, Larman demystifies the unified process. He focuses on its inception and elaboration phases, where most of the analysis and design work is done. Even though the book title focuses on unified modeling language (UML) and patterns, the books goes far beyond the use of UML diagrams to communicate ideas, and Gang of Four (GoF)  design patterns to codify design best practices. Fortunately, the misleading title may attract the people who can benefit most from the contents of the book, namely, those developers who want to expand their development skills. Larman also addresses analysis techniques, such as use case modeling , which are wrongly identified as "object-oriented analysis," when there is nothing object-oriented about them . It is a stretch these days to talk about "object-oriented analysis."
The book mainly focuses on object-oriented design and its underlying principles, which are presented as "general responsibility assignment software principles." These are no more than general heuristics on how responsibilities should be assigned to software classes. Their discussion is noteworthy, but is also harder to understand for novice designers, because it requires a higher abstraction capability, a priceless ability for any self-respecting practitioner. Larman does a great job of introducing basic concepts and patterns, while demonstrating how to use UML to our advantage.
Apart from its in-depth coverage of object-oriented design, the book also presents other techniques that are useful in software development. These include the functionality-usability-reliability-performance-supportability (FURPS+) requirements categorization system; use cases, à la Cockburn; and the application of design by contract ideas, during the early phases of the project, by means of operation contracts. Larman also covers layered architectures, package design guidelines, and the N+1 view model for describing "the big ideas of the system." Some readers may feel that their pet techniques deserve a more in-depth treatment, which is virtually impossible if we take into account the broad scope of the book. For those interested in the details, Larman provides pointers to more information.
In summary, this is probably the best book I have seen on object-oriented design at the introductory level. Although it requires previous object-oriented programming knowledge (preferably in Java), it is easy to follow. The book is an ideal choice for self-learning, because it provides insight beyond the "how" of techniques, and explains the "why" behind them. Use it as a starting point, before attempting to fully understand more expert-oriented titles, if you are relatively new to object orientation. Use it as a refresher, to see how everything fits together, if you are more experienced.
-- Fernando Berzal, ACM Computing Reviews, 2005
Design Patterns. Addison-Wesley, Boston, MA, 1995.
 Cockburn, A.: Writing Effective Use Cases. Addison-Wesley, Boston, MA, 2001.
 Davis, A.M.: Great Software Debates. IEEE Computer Society, Los Alamitos, CA, 2004.
As Robert L. Glass points out in his introduction, and his book title suggests, this book is built around "a laundry list of facts and fallacies about building software". But there is something special in that laundry list: it tries to collect what we ought to know about software development but we frequently forget to remember, as well as some beliefs we give for granted although they are, at least, misleading (just plain wrong for Mr. Glass).
Given its topic, it is not surprising that the book original title was "Fifty-Five Frequently Forgotten Fundamental Facts (and a Few Fallacies) about Software Engineering", alias the F-Book. Somehow, the book title was shortened for marketing reasons and it lost the emphasis it put on the importance of the topics discussed.
The book is clearly written and easy to read, full of wisdom and with some doses of wit, just as the columns "Bob" Glass periodically writes for Communications of the ACM and IEEE Software. Moreover, the facts it examines are essential to software development activities and, although their references might change, their fundamentals will never be outdated. That makes this book a great book in comparison to the myriad of computer books which are written about the hottest topic of the day and whose relevance will not last much longer than trade magazines.
The facts and fallacies in this book cover the whole software life cycle, although several underlying themes recur throughout the book, such as the inherent complexity of software development (remember that software systems are probably the most complex systems ever built by humans) and the irrational hype which plagues our field (as exemplified by one-size-fit-alls advocates).
While you will find some classic facts such as "Adding people to a late project makes it later", as well as discussions of poor estimation and unstable requirements as the most common causes of project failure, you will also find some shocking facts and all of them will give you food for thought. Here is a sample of what I found particularly enlightening:
Apart from the 55 facts which are dissected in the first part of the book, the author has chosen ten common misunderstandings in software engineering. These fallacies include pearls such as "given enough eyeballs, all bugs are shallow" (Fallacy 8), "the way to predict future maintenance costs and to make product replacement decisions is to look at past cost data" (Fallacy 9), and "to estimate cost and schedule, first estimate lines of code" (Fallacy 6). You will probably find yourself nodding as you read this part of the book and you will probably get shocked by some of the ideas you will find in this entertaining book, if not merely disturbed or plainly annoyed.
Why don't we learn to read program before we try to learn how to write them? That's the usual way we would learn a new language. Moreover, "60 percent of software's dollar is spent on maintenance, and 60 percent of that maintenance is enhancement" (the 60/60 rule) and "understanding the existing product consumes roughly 30 percent of the total maintenance time."
Some people might the book style somewhat irritating, since its contents are presented as more or less independent sections. Those sections collect Glass' wisdom in snippets which include a discussion of a particular fact, the controversy surrounding the fact, and some pointers to further reading. Although academics might prefer an alphabetical listing of hundreds of references, I have particularly enjoyed the short annotated bibliographic entries which are scattered throughout the book, in spite of the duplications which unavoidably appear when a particular reference is cited in several places. Somehow, almost every classic reference has its place in the F-Book.
This book is an invaluable resource for those people preparing to be software engineers in the future and also for those practitioners which want to refresh what they ought to know or just to reinforce what they believe in spite of existing controversies (mostly from "hypesters"). Since the book covers topics which are usually controversial, this book will also give you arguments for the next time you will find yourself trying to refrain your team of doing things the wrong way. If you love software development, you'll love this book. Enjoy it!
-- Fernando Berzal, Dr. Dobb's Journal ERCB, 2003
-- Fernando Berzal, Dr. Dobb's Journal ERCB, 2002
Why is software design so hard? Maybe because there aren't any guidelines for developing successful working systems. And although many design methods have been proposed, most too often teach us nothing more than their proponents' methodology and not how to make the best use of them.
Most classical analysis and design books fall short of telling us when to use the methods and techniques they advocate. Since there are no silver bullets (that is, no "one-size-fits-all" method in software engineering) and, as P.J. Plauger says in Programming on Purpose: Essays on Programming Design, "we often cannot articulate why we do what we do when we do it," our experience ends up being the only guide we have when facing new projects. This leads many software projects to failure, rather than repeatable successes.
The patterns movement has filled a niche by cataloging well-crafted solutions to many analysis and design problems (see, for example, Erich Gamma et al.'s Design Patterns: Elements of Reusable Object-Oriented Software or Martin Fowler's Analysis Patterns: Reusable Object Models). But even before the patterns fad, P.J. Plauger disseminated simple but powerful ideas in dozens of magazine articles and a column, mainly in late Computer Language magazine. In some sense, Programming on Purpose complements the pattern approach because patterns are usually employed to describe solutions at the architectural level, while the principles Plauger describes are focused on detailed design and coding.
Programming on Purpose is the keystone of a three-volume collection of essays he wrote between 1986 and 1993. This volume focuses on software design while the others collect articles on people and technology. In spite of its somewhat dated context (part of it was written before the widespread use of object-oriented techniques, WIMP interfaces, and other prevailing practices), the ideas and principles in this book are surprisingly fresh. In fact, Plauger's observations are timeless and will be always relevant to software professionals because they tackle the problem of mastering complexity that lies at the heart of software development.
Programming on Purpose presents excellent discussions on a wide range of design methods and techniques, from the stepwise refinement used in top-down design to the use of grammars to parse input data (left-to-right design) or a structure approach to build programs that model the structure of the output data (right-to-left design). A total of 12 design methods are presented, along with their strengths and weaknesses. Although Plauger's design methods categorization technique is somewhat artificial, the book's value is in no way diluted since all methods are put into a context of guiding you using analogies and advice.
Apart from his survey of software design methods, Plauger provides some interesting nuggets such as three essays on demystifying object-oriented programming (a novel trend when the essays were written), some ideas on software development that could seem to be counterintuitive ("software design heresies," as Plauger calls them), and a curious approach to teaching software engineering that could be an eye-opener for many instructors.
A couple of chapters with interesting references to further reading and Plauger's view on landmark software design publications complete this superb book. Programming on Purpose is a must have book for anyone involved in professional software development.
In software development, reuse is The Holy Grail. Reusing existing software artifacts is the most cost-effective way to reduce development time and effort. But code snippets and finished software components are not the only artifacts which can be reused. I am sure you already reuse your prior development experience when facing new challenges. This book is just about that. The Gang of Four (GoF) - as the authors are popularly known - try to record experience in object-oriented design to help developers improve their programming skills. As the book preface says...
As other software development best practices, design patterns help us develop more flexible and maintainable software through the use of well-designed interfaces which encapsulate particular implementations. This book proposes a modular approach which encourages the use of object composition and delegation over class inheritance in order to reduce coupling among classes.
The GoF's book is an essential catalog of object-oriented design templates. Each template or pattern can be used as a starting point to develop new object-oriented software, and also in the process of refactoring (i.e. reorganizing and redesigning) existing software systems. Each pattern in this book abstracts key issues of common design structures, is analyzed in depth and is labeled with a short name in order to facilitate communication among developers. Pattern names broaden our technical vocabulary and make easier for us to discuss possible solutions and their trade-offs.
This book discusses each design pattern in self-contained chapters. Each chapter labels the design pattern, presents the problem it intends to solve, describes its solution, and addresses the consequences which could derive from the use of the design pattern in real systems. Some code snippets (in C++ and Smalltalk) illustrate the inner details of each pattern and references to known uses of each pattern are also included, although you will find that you have probably used most patterns in your best projects.
As stated above, patterns are studied separately, although they are organized into three main categories:
The book organization, its quick index, and its diagrammatic roadmaps make it a worthwhile reference to keep at hand on your favorite shelf. This -now famous- book is the flagship publication of a growing community whose interest in well-designed software complements the traditionally academic focus on software development techniques and methodologies. Methodologies teach us how to solve development projects, design patterns show us elegant solutions to those problems.
Networks pervade our lives. As graphs representing interconnected systems, they can represent social interactions, economic relationships, power grids, computer networks, Web links, bibliographic citations, or biochemical processes. Whether the networks are social, economic, technological, or biological, their study has spurred a lot of interest over the past decade or so.
The Web established a market for many popular books on networks. Some of these have been entertaining and informative—for example, Duncan Watts's Six Degrees or Albert-Laszlo Barabasi's Linked. However, they aren’t rigorous enough for more demanding readers. Those wishing to plumb the depths of networks have had to make their way through countless research papers, which necessarily offer a fragmented view of any field. Even worse, network research terminology is often confusing, given the youth of this field and the different specialties contributing to it. Hence, Ted G. Lewis's textbook offering a panoramic view of this emerging research area is welcome.
According Lewis, network science reflects the combination of graph theory, control theory, and cross-discipline applications. Calling it a science, however, is probably an overstatement—the kind of hype that has made some people dismiss network research as a passing fad or fabrication, ignoring important lessons this field can teach us.
The subtitle might also be misleading. Lewis has written the book with graduate students in mind, so it's more theory than applications. This is partially justified because Lewis has tried to separate the wheat from the chaff to produce a valuable textbook. In this yet-to-mature field, theoretical models are the wheat while particular applications are usually the chaff. This is because new observations and a better understanding of the studied processes often make research results obsolete in a quite short period of time.
After some introductory material on the historical roots of networks and a brief overview of graph theory, Lewis analyzes some of the most popular network models that researchers have proposed to formulate hypotheses about observed phenomena. These range from Watts-Strogatz small worlds and Barabasi-Albert scale-free networks to flow, influence, and netgain networks.
Traditional graph theory has typically focused on network static properties, which Lewis also uses to study different network classes. However, modern network models focus on the dynamic behavior of interconnected systems. Lewis concentrates on four network properties:
The final chapters turn to economics and biology as promising application domains for network theory. Lewis posits that netgain networks might be useful models for investigating how economic markets behave, that while biological network models show promise as research tools.
Lewis has made an extraordinary effort to provide a first textbook in this fascinating field. However, being first also has some disadvantages. Apart from typos that might be unavoidable in a first edition, especially if publishers want to cut proofreading and editing costs, I found some explanations more convoluted than necessary, even misleading at times. For instance, when discussing a classical paper on the Web topology as a directed graph, Web links are mistaken for physical network connections. Web nodes—that is, Web pages—are incorrectly identified as "nodes that send messages such as email" (page 159). Fortunately, such glaring errors are few, but they're unsettling in any textbook because they raise some doubts about its overall rigor and thoroughness.
The text is generally clear, but somewhat wordy and repetitive. The book feels as if it's written from course notes. Some repetition is desirable and even necessary in oral presentation, but it isn't as welcome in written form. For instance, the detailed introductions to each chapter almost summarize all the material in the chapter itself, thus virtually removing any pleasant surprise you might find from delving into the details. I find detailed summaries more useful at the end of chapters, rather than the beginning.
Lewis concludes each chapter with some exercises as well as interesting issues—even open research questions—that are "left as an exercise to the reader." He provides some Java software tools that support the exercises. (He even discusses some code snippets in the text—something I thought often distracted from the main discussion.) The software tools are invaluable for readers to experiment on their own, because many network issues can only be resolved through computer simulations followed by some curve fitting. All in all, I would recommend Lewis's textbook for graduate students and professionals with a keen interest in network models. Those with a more general interest might start with the popular books, then proceed with this book for a more thorough study. Despite its theoretical slant, casual readers can easily skip the mathematics and still glean much from this book.
-- Fernando Berzal is a member of the IEEE Computer Society and a senior member of the ACM. Contact him at firstname.lastname@example.org.