Overview
1.1 Systems and Complexity
1.1.1 Common Problems of Systems in Many Fields
1.1.2 Systems, Components, Interfaces, and Environments
1.1.3 Complexity
1.2 Sources of Complexity
1.2.1 Cascading and Interacting Requirements
1.2.2 Maintaining High Utilization
1.3 Coping with Complexity I
1.3.1 Modularity
1.3.2 Abstraction
1.3.3 Layering
1.3.4 Hierarchy
1.3.5 Putting it Back Together: Names make Connections
1.4 Computer Systems are the Same but Different
1.4.1 Computer Systems have no Nearby Bounds on Composition
1.4.2 d(technology)/dt is Unprecedented
1.5 Coping With Complexity II
1.5.1 Why Modularity, Abstraction, Layering, and Hierarchy arenât Enough
1.5.2 Iteration
1.5.3 Keep it Simple
What The Rest of this Book is About
Exercises
Overview
This book is about computer systems, and this chapter introduces some of the vocabulary and concepts used in designing computer systems. It also introduces âsystems perspectiveâ, a way of thinking about systems that is global and encompassing rather than focused on particular issues. A full appreciation of this way of thinking canât really be captured in a short summary, so this chapter is actually just a preview of ideas that will be developed in depth in succeeding chapters.
The usual course of study of computer science and engineering begins with linguistic constructs for describing computations (software) and physical constructs for realizing computations (hardware). It then branches, focusing, for example, on the theory of computation, artificial intelligence, or the design of systems, which itself is usually divided into specialities: operating systems, transaction and database systems, computer architecture, software engineering, compilers, computer networks, security, and reliability. Rather than immediately tackling one of those specialties, we assume that the reader has completed the introductory courses on software and hardware, and we begin a broad study of computer systems that supports the entire range of systems specialties.
Many interesting applications of computers require
coordination of concurrent activities
geographically separated but linked data
vast quantities of stored information
protection from mistakes and intentional attacks
interactions with many people
To develop applications that have these requirements, the designer must look beyond the software and hardware and view the computer system as a whole. In doing so, the designer encounters many new problemsâso many that the limit on the scope of computer systems generally arises neither from laws of physics nor from theoretical impossibility, but rather from limitations of human understanding.
Some of these same problems have counterparts, or at least analogs, in other systems that have, at most, only incidental involvement of computers. The study of systems is one place where computer engineering can take advantage of knowledge from other engineering areas: civil engineering (bridges and skyscrapers), urban planning (the design of cities), mechanical engineering (automobiles and air conditioning), aviation and space flight, electrical engineering, and even ecology and political science. We start by looking at some of those common problems. Then we will examine two ways in which computer systems pose problems that are quite different. Donât worry if some of the examples are of things you have never encountered or are only dimly aware of. The sole purpose of the examples is to illustrate the range of considerations and similarities across different kinds of systems.
Much wisdom about systems that has accumulated over the centuries is passed along in the form of folklore, maxims, aphorisms and quotations. Some of that wisdom is captured in the boxes at the bottom of these pages.
Everything should be made as simple as possible, but no simpler.
â commonly attributed to Albert Einstein; it is actually a paraphrase of a comment he made in a 1933 lecture at Oxford.
As we proceed in this chapter and throughout the book, we shall point out a series of system design principles, which are rules of thumb that usually apply to a diverse range of situations. Design principles are not immutable laws, but rather guidelines that capture wisdom and experience and that can help a designer avoid making mistakes. The astute reader will quickly realize that sometimes a tension, even to the point of contradiction, exists between different design principles. Nevertheless, if a designer finds that he or she is violating a design principle, it is a good idea to review the situation carefully.
At the first encounter of a design principle, the text displays it prominently. Here is an example, found on page 16.
Avoid Excessive Generality
If itâs good for everything, itâs good for nothing.
Each design principle thus has a formal title (âAvoid excessive generalityâ) and a brief informal description (âIf itâs good for âŚâ), which are intended to help recall the principle. Most design principles will show up several times, in different contexts, which is one reason why they are useful. The text highlights later encounters of a principle such as: avoid excessive generality. A list of all of the design principles in the book can be found on the inside front cover and also in the index, under âDesign principlesâ.
The remaining sections of this chapter discuss common problems of systems, the sources of those problems, and techniques for coping with them.