Figuring out just how to build a computing system is hard. We get it wrong frequently. So, we also get lots of books on systems analysis and design (or synthesis). Whereas analysis is generally focused on determining how a system works, design (or synthesis) is usually aimed at building a system. These books cover pretty much the same topics: databases, data structures, specifications, testing, and so on.

This book distinguishes itself from many similar books by using a collection of methods based on graphs to formalize the system synthesis (as opposed to design) and contains chapters on automata, user interfaces, and other topics that are not always seen in similar texts.

Chapters include:

• “Systems, Analysis, and Synthesis”: an introduction to the methods used in the book
• “Mathematical Background”: includes the basics of mathematical logic, sets and schemas (where a schema is a labeled graph describing the relationships between sets), as well as ways to programmatically represent these objects
• “Atoms”: An atom is the smallest unit in a model in this methodology. This chapter also covers automata of various sorts.
• “Data Structure Analysis”: includes functional dependencies and entity-relationship analysis, as well as a section on synthesizing a database using composition derived from functional dependencies. Interestingly, no attention is given to the subject of database normalization (although this is covered in an appendix)
• “Kernel Specifications”: The system kernel is the programmatic interface that sits in the middle of input handling, output handling, and the database. An extended example (an academic records system) is provided for specificity.
• “Database Technology”: covers SQL and transactions
• “Processes”: This is not necessarily the operating system (OS)-level processes, but might be mapped to such in some systems. A process here is an independent entity with its own internal state that communicates with other processes by passing messages.
• “Interfaces”: concerned mostly with human factors like readability and usability
• “Rules”: on rules, business rules, rule-based systems, decision tables, and the like
• “System Dynamics”: covers queueing models and control systems
• “Project Management”: information on costing, acceptance tests, documentation, and feasibility

There are also three appendixes, one on regular expressions and finite state automata, one on database normalization, and one containing answers to the exercises.

Interestingly there is little discussion of the various development methodologies, and the text more or less assumes something like a waterfall method. This is an odd choice in the current climate; while there are certainly many projects that are small enough to be developed with complete analysis up front, most projects will necessarily involve more agile methods. For systems over some size, agile methods are almost always used (there are exceptions, notably safety-critical systems). One problem is that agile almost always requires incremental development of data as well as process, so databases in real systems are rarely clean, almost never normalized, and frequently contain data that is not actually used (perhaps because there is no longer a need for it). Furthermore, non-SQL databases are increasingly common, and these come with different trade-offs in terms of how data is organized.

The section on queueing is nice, although it essentially concludes with, “You’ll have to simulate any real queueing system.” In the case of many real systems, the best simulation is observing the system itself. There’s little information on how to instrument a real system to gather data (not always an easy thing to do in real systems).

There are a few minor problems: In the introduction, there is a brief discussion of NP-complete problems, and it is implied (but not stated outright) that integer factorization is NP-complete. In fact, it is not known for sure how hard integer factorization is. In another section, the author says that there should be no comments in code unless the comments are written first. This is not always feasible: sometimes the comments are there to explain decisions made long after the original code is written.

On the whole though, this is a decent introduction to the subject. No systems analysis book ever really explains the deep down messiness of real systems, but an overview of what we’d ideally like our systems to be is not a bad thing at all. For the most part, the text is eminently readable and the math used is fairly well explained. This would make a nice undergraduate text in the field.