Basic microcomputer design

Before we start looking at computer architecture in detail we will revise the main components of a computer system and the basic fetch-execute

cycle. Figure 1.1 shows the major components of a computer system. These are the:

Central Processing Unit (CPU). This is the "brains" of the computer. It controls the other components by deciding what to do next. Memory. This is the part of the program that temporarily stores data and instruction for the CPU. I/O Subsystem. This is the part of the computer that interacts with the outside world. If a computer did not have an I/O system then it would not be useful for anything. Bus. This is the "wires" that connect the other three parts of the computer together. Buses are collections of wires that are individually either on or off (0 or 1). Everything connected to the bus sees the same status for each wire.

Now that we have seen the basic components of the system we need to revise how they interact. Figure 1.2 shows the basic fetch-execute cycle of a computer system. You will see in the remainder of this unit that this basic cycle, with a small variation, is the complete description of the activity of a CPU. The following textbook reading revises these concepts in more detail. It relates each of the components to real computers. It also covers operating system concepts that we will study later in the unit. Textbook: Englander, 1996, Section 1.2, pages 11-17.

Activity 1.1: This reading relates to real computer systems. Write down the specifications of your own computer system under the headings of CPU, Memory, I/O Subsystem and Buses. [Feedback]

We will now revise each of the components of a computer in more detail.

The CPU
In most modern computer systems the CPU is a single chip. In this unit we will also look inside the chip to study internal components. Figure 1.3 shows some of the main components of most CPUs.

In Figure 1.3 several internal components are shown:

Registers are temporary storage areas that retain their information between instructions. They usually hold 16, 32 or 64 bits of information. The control unit is the unit responsible for directing the other units inside the CPU. It usually interprets instructions after they have been loaded. The Arithmetic Logic Unit (ALU) performs arithmetic and logic operations on values in the internal registers. It performs operations such as addition, multiplications, logical AND, etc. The interface unit provides the external interface to the CPU. It performs the necessary operations to access memory and the I/O subsystem. Most CPUs also have one or more internal bus to connect the CPU's internal components. It is usually quite different to the computer's main bus as it is designed to work much faster.

Memory
The computer's main memory is used for storing instructions and data. In most modern computers this memory is volatile which means that it looses its memory when the power is removed. This means that main memory is not permanent storage and permanent data must be saved to a permanent medium such as disk or tape. In addition, main memory is usually a scarce resource so many schemes have been invented to make better use of the main memory available. Later in this unit we will study these schemes in more detail. Memory is divided into many identical storage cells. Each of them contain a fixed number of bits. Most modern computers have eight bit cells which are also called bytes. Each storage cell is given a unique address, which is also called the cell's location. Addresses start at zero and sequentially number each cell. It is important to note that a CPU only has two ways to access a memory location. It may read a location by transferring a copy of the cell to the CPU. Alternatively, it may write to a memory location. A write operation transfers a new bit pattern to the memory location overwriting its previous contents.

I/O Subsystems
The I/O Subsystem provides a consistent link to the many I/O devices attached to the computer system. The CPU must be able to access each device by a consistent interface. A CPU accesses devices via I/O ports. These are similar to internal registers or memory cells as they can be used to read information from a device or for the CPU to write data to the device. In this way the CPU can perform input and output to a device. There are two computer design techniques used for accessing I/O ports:

Access the port as a memory address. CPUs that implement this technique reserve a special range of memory addresses for I/O ports. This means that an instruction can access the port using the same instructions that access memory. Motorola 680x0 processors use this technique. Use a separate addressing mechanism. CPUs that reserve a separate address space for I/O ports must use special instructions for accessing the ports. Intel 80x86 processors use this technique.

A characteristic of I/O ports is that they do not always remember the data that is written to them. This is because the attached I/O devices may modify the ports independently from the CPU. This is useful for programs that want to check if an I/O operation has

completed (e.g., a mouse click has occurred). Such a program can check the I/O port periodically to check if the port has changed. You will expand your knowledge of the fourth component (buses) in Topic 2. In the next section we will look at numbering systems. It will be important to develop skills in computer oriented number systems so you can fluently discuss the internal operation of memory, the CPU and I/O modules.

Numbering Systems
To allow us to talk fluently about low level computer concepts we need to use appropriate systems to describe the contents of registers, memory, I/O ports, etc. In this section we will look at binary and hexadecimal numbers which are the main numbering systems for use with low level computers. Techniques for converting these numbers to our familiar decimal counting system will be studied. We will also look at how we can represent negative numbers in computers and how they can be manipulated. Codes are also another technique to allow us to easily interpret the contents of register and memory so we will briefly look at the ASCII code. Finally we will discuss how we can store numbers with more that eight bits in a machine that had eight bit addressable storage cells.

Binary and hexadecimal numbers

As you know from previous units, computers store everything in 1's and 0's. If we want to exactly describe what the contents of a memory cell or a register then we would have to write the complete number of bits. For example, if the number 3 was stored in a byte in memory then the exact contents of the byte could be described as: 0000011 If a 32-bit register contained the decimal number 234,567 then the exact contents of the register would be (don't worry about the conversion): 00000000000000111001010001000111 You can probably see that working with binary numbers soon becomes very verbose and prone to error. For this reason, people who frequently work with low level computer architecture use hexadecimal numbers as shorthand. Hexadecimal numbers (hex for short) directly represent binary numbers by assigning a digit to each group of four binary digits. The following table shows the hex digits for each possible combination of four binary digits. Notice that the first 10 digits correspond to the normal decimal system that you are

used to. The remaining 6 had to be taken from somewhere so the letters 'A' to 'F' have been chosen. binary 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111 hex 0
1 2 3 4 5 6 7 8 9 A B C D E F

Hex allows us to exactly represent a byte with two hex digits, a 16-bit value with four hex digits and a 32 bit value with eight hex digits. This is much more compact than a binary representation. So for example, the above two binary numbers can be represented in hex as: 03 and 0039447 If you examine these numbers by themselves you will have an interpretation problem. Is the number 23 a decimal or a hexadecimal number? In the above context it is obvious which is which. However, this will not always be the case. We will follow the C/C++ convention of writing hex numbers with a preceding '0x' or '0X' string. For example, the above two numbers will be written as: 0x03 and 0x0039447 The same problem arrises when we write binary numbers. Does 10 represent a binary number or the usual decimal ten? To distinguish binary numbers we will precede the number with the string '0b' or '0B'. For example, the binary number 10 will be written as: 0b10 We will use both these conventions for all binary and hex numbers that appear from now on in the unit materials. In the case where the context is clear we will omit these prefixes. The following textbook reading describes hexadecimal and binary numbers and how to work out the decimal equivalents. Although it is easier to use a calculator you are required to learn the manual procedures. You will find with practice that it is quicker to convert small numbers manually. Textbook: Englander, 1996, Section 2.0-2.2, pages 30-36. Englander, 1996, Section 2.6, pages 44-46. Activity 1.2: For this activity you should work out the answers manually. 1. What is the hexadecimal equivalent of the following binary numbers?

0b11111 0b100110 0b101100000001

0b101010101010

2. What is the binary equivalent of the following hex numbers? 0xFF 0x101 0x123 0x100A 0xABCD 3. What is the decimal and hexadecimal equivalent of the following binary numbers? 0b111 0b1000 0b11111111 0b101010101 0b1000000000000000 4. What is the decimal and binary equivalent of the following hexadecimal numbers? 0xA 0xA0 0x1A 0xFFFF 0x1000

The last reading discussed how to find the decimal equivalents of binary and hex numbers. We also have to convert in the other direction. That is, we need to convert from decimal to binary and from decimal to hexadecimal numbers. The following reading shows you two ways to do this. You should concentrate on the second method and use it in the activities given below.

Activity 1.3: For this activity you should work out the answers without a calculator. If you have difficulty with the first one then check you answer in this topic's feedback section before attempting the remainder. What is the binary and hexadecimal equivalent of the following decimal numbers?

We have concentrated in this section on the conversion of numbers between three bases (binary, decimal and hexadecimal). You may have noticed in the textbook readings that there is also a lot to learn about arithmetic in the various bases. However, for the purposes of this unit you do not need to know how to do this. When arithmetic arises we can always convert hex and binary numbers to decimal and do the arithmetic. If the answer is required in the other base then we convert the decimal answer to the base.

There is one further attribute of computer numbers that we have not discussed. That is how to represent negative numbers. Representing negative numbers is discussed in the next section.

Representing signed numbers

So far in this topic we have dealt only with positive numbers. You will be aware that most computer languages have an integer data type that allows programs to store negative as well as positive numbers. These can generally be called signed numbers. So how are these stored in memory and registers? There are two techniques commonly used to store negative numbers. Early computer systems used a technique called 1's complement. Modern computer systems use a technique called 2's complement. We will examine both these techniques. The 2's complement technique will be the one used through the remainder of this unit.

1's complement
1's complement stores a negative number as the complement (logical NOT) of the positive number. For example, the numbers -2 to +2 are stored in 16 bit registers as: number binary 0000 0000 0000 0010 2 1 0 -1 -2 0000 0000 0000 0001 0000 0000 0000 0000 1111 1111 1111 1110 1111 1111 1111 1101 hex 0x0002 0x0001 0x0000 0xFFFE 0xFFFD

Notice that this technique results in the most significant bit (MSB) being a 1 for negative numbers and a 0 for positive numbers. Another attribute of this system is that the value with all 1 bits (i.e. 0xFFFF in this case) does not have a positive equivalent in the normal number system. It is commonly called negative zero since its complement is zero. The following reading describes 1's complement in a round about way. It shows why this technique was chosen by describing how addition and subtraction are done. The text shows how the system would work using a decimal number equivalent. While reading this you should remember that it's the binary 1's complement that we are studying. Textbook: Englander, 1996, Section 4.4, pages 97-104.

Activity 1.4: For this activity you should work out the answers manually. 1. What is the 1's complement binary and hexadecimal equivalent of the following decimal numbers? Assume 16-bit representation. 23 -3 -255 -1234 2. 2. What is the decimal equivalent of the following 16-bit 1's complement numbers? 0xF 0xFFFF 0xFFF7 0xFFF0

2's compliment
2's complement stores a negative number as the complement (logical NOT) of the positive number plus one. For example, the numbers -2 to +2 are stored in 16 bit registers as: number binary 0000 0000 0000 0010 2 1 0 -1 -2 0000 0000 0000 0001 0000 0000 0000 0000 1111 1111 1111 1111 1111 1111 1111 1110 hex 0x0002 0x0001 0x0000 0xFFFF 0xFFFE

Notice that this technique again results in the most significant bit (MSB) being a 1 for negative numbers and a 0 for positive numbers. This system also eliminates the redundant negative zero value so it can represent one more signed value than 1's complement. The following reading describes 2's complement in the same round about way as the text described 1's complement. It shows why this technique was chosen by describing how addition and subtraction are done. The text shows how the system would work using a decimal number equivalent. While reading this you should remember that its the binary 2's complement that we are studying.

Activity 1.5: For this activity you should work out the answers manually.

1. What is the 2's complement binary and hexadecimal equivalent of the following decimal numbers? Assume 16-bit representation and compare your answers to Activity 1.4. 23 -3 -255 -1234

2. What is the decimal equivalent of the following 16-bit 2's complement numbers? 0xF 0xFFFF 0xFFF7 0xFFF0

In this section we have examined the representation of integers in computer systems. There are several things we have skipped over or avoided. We have not examined closely how arithmetic is done in binary and hex numbers. In general this is not important for this unit. If you wish to check the results of computer arithmetic in the practical part of this unit then you must either use a calculator or convert numbers to decimal equivalents and then do decimal arithmetic. A large area we have not mentioned at all is how to represent fractions in the computer. We will briefly look at this problem in a later topic where will see how floating point numbers are represented. We will not look at these at all in the practical part of this unit. Next, we will examine another way to look at the contents of memory cells and registers. Instead of interpreting them as numbers we can interpret them as codes.

Codes
Another way of interpreting binary numbers is by assigning a property to each bit pattern. Looking at this another way, we can assign a bit pattern or code to a number of properties. In this section we will look at assigning codes to symbols of an alphabet. We can assign a certain binary code for each symbol so that whenever this code appears it can be interpreted as that symbol. We can also develop input and output devices which reproduce the symbol whenever they are presented with the bit pattern through an I/O port. The most common of these codes at the present time is ASCII (American Standard Code for Information Interchange). It is a 7 bit code that represents 96 printable characters and 32 control characters. Figure 1.4 shows a table of ASCII codes.

To find the code for one of the ASCII symbols we read the first three bits from the top of the table and the next four bits from the left-hand side. For example, the letter capital C ( 'C') has binary code 1000011. ASCII is not the only code available. EBCDIC (Extended Binary Coded Decimal Interchange Code) is used extensively by IBM mainframe equipment. A new 16-bit code called Unicode is also gaining acceptance by users of the Internet. Because of the large number of codes possible, symbols from many languages can be included in Unicode. Textbook: Englander, 1996, Section 3.0-3.2, pages 59-69. Activity 1.6: 1. How is the string "Catch 22" stored in ASCII? 2. How is the string "Catch 22" stored in EBCDIC? 3. What English phrase is stored as the following ASCII hex code? 48 65 6C 6C 6F 20 77 6F 72 6C 64 21

You will also notice from the above reading that codes can be used to store useful things besides language symbols. We will not study these in this unit. Finally, we now look at how we can store large binary objects (numbers, codes, etc.) in memory that is normally organised as addressable 8-bit units.

Storing large binary objects

An interesting question arises when we wish to store multi-byte objects in byte addressable storage. For example, suppose we have the 32-bit number value 0x12345678. This must be stored in four bytes in memory, so let's suppose they are addresses 0x400, 0x401, 0x402 and 0x403. There are two possibilities: address 0x400 0x401 0x402 0x403 option1 12 34 56 78 option2 78 56 34 12

At first glance the first of these methods appears the most obvious way to store numbers. It stores the big end of the number first and is called big-endian byte order. It means that the address of the 32-bit number is the address of the most significant byte. However, the second techniques which stores the little end first (little-endian byte order) is also used. For example, all Intel 80x86 processors are little-endian. This technique has the advantage that bytes are stored in the same order as bits so that the least significant bits have the lowest memory address. There has been considerable debate about which ordering is more appropriate. In fact the names little-endian and big-endian reflect the non-agreement of computer system designers. These terms are taken from Jonathon Swift's novel Gulliver's Travels where a religious war broke out between two sides who broke their eggs at the big end (bigendians) and those who broke their eggs at the little end (little-endians). The issue is similarly unresolved. In general, the byte order is not noticeable in a program. You will need to understand the byte order when examining dumps of memory, which display large binary numbers as separate bytes. However, the main difficulty with the alternate approaches is when data is transferred between machines with different architectures. Any data unit greater than one byte long will have its byte ordering reversed so a conversion will have to be made.

Systems Design

In large-scale embedded systems, an element of systems design is the partitioning of functions into hardware and software components. In the past, the hardware structure of a system was usually predetermined and it remained to develop the software to coordinate and control the hardware units. Advances in VLSI have blurred the line between hardware and software components. Often it is cost-effective to delay decisions about which functions should be implemented in hardware and which should be in software. Providing performance in hardware means that the software design can be structured for adaptability and performance considerations can be considered secondary. For this type of design, it is necessary for the system architecture to be made up of stand-alone components which can be implemented in either hardware or software.

Parallelism

Many software systems can be structured as a set of parallel communicating processes. Parallel processes have been considered as a natural and necessary construct for the design of real-time systems. Embedded systems must often perform to very strict time constraints. A multiple process/multiple processor approach or a very fast sequential provide adequate performance. Sequential programs are easier to design, implement, verify and test than parallel ones. Time dependancies between processes are hard to formalize, control and verify. The design process should be considered as a two-stage activity: 1. Identify the logical design structure - the components of a system and their inter-relationships. 2. Realize this structure in a form which can be executed. This can be considered detailed design. One of the problems with parallelism is determining at which stage decisions about parallelism should be made. Another problem is that existing algorithms, which may be very efficient on sequential machines, often do not map well onto parallel systems.

User Interface Design

The quality of the user interface is the key system attribute as far as most users are concerned. Without a well designed interface, a system will not be used to its full potential or will be discarded by users. Interface design should be user-centred. This means that an interface should interact with users in their terms, should be logical and consistent, and should include facilities to help users with the system and to recover from their mistakes. Designing an interface metaphor is a good way to help users with a system.

User-Centred Design Principles The designer should always bear in mind that system users have a task to accomplish and the interface should be oriented towards that task. The most fundamental principle in user interface design is that the interface must be designed to suit the needs and abilities of the individual user. Users should not be forced to adapt to an interface because it is convenient to implement or because it is suited to the system designer. The second principle of interface design is that the user interface must be consistent. Interface consistency means that system commands and menus should have the same format, parameters should be passed to all commands in the same way, and command punctuation should be similar. Subsystems which offer the same facilities as a menu should display these menus in the same way. A consistent interface means that when a user takes time to learn about one command of the interface that knowledge is applicable to all other commands in the system. The third principle of interface design is that the interface should have built-in `help' facilities. These should be accessible from the user's terminal and should provide different levels of help and advice. These should range from very basic information on how to get started with the system up to a full description of system facilities and how to use them. Interface Metaphors

One way to achieve consistency is to establish a consistent metaphor for user interaction with the computer system. A metaphor is a scheme of representing system entities in such a way that they can be equated with other entities familiar to the system user. The best known metaphor is the desktop metaphor. Interface Metaphor: The Control Panel o The entities which may be represented on a control panel are: 1. Buttons: picking a button causes a single action to be initiated. 2. Switches: may be set at a number of positions to move a system from one state to another. 3. Menus: collections of buttons or switches which may be made visible and selected. 4. Lights: activated to show that some action is taking place. 5. Signs: visible representations of the system state. WIMP (Windows, Icons, Menus and Pointing) interfaces where the user has multiple windows, menus, iconic object representations and a pointing device are likely to be the most important class of interfaces for future systems. Menu systems are good for casual users because they have a low learning overhead. They can be difficult to use when the number of options is very large. Graphical information display should be used when it is intended to present trends and approximate values. Digital display should only be used when precision is required. Command language interfaces may be popular with regular experienced system users because complex commands can be created and because they can be faster to use than menu systems. WIMP Interfaces o The advantages include: It is easy to learn and use. Instead of a single screen, the user has multiple screens (windows) for system interaction. Switching from one task to another does not necessarily mean the complete loss of information generated during the first task.

 It offers fast, full-screen interaction rather than the line-oriented interaction required by command interfaces. It requires a high-resolution display for effective presentation and this means that graphical presentation of information is straight-forward.

Design Specification
Outline All descriptions should clearly state all design decisions and choices and a brief justification. 1. Scope o system objectives o hardware, software, externally defined data bases, human interfaces, etc. o major design constraints, limitations 2. Design Description
1.

2.

data description 1. review of data flow 2. review of data structure derived program structure

criteria for determining the modules 2 2 interfaces within structure 2. Modules for each module: processing narrative interface description other modules used data organization pseudo-code algorithm comments 2. File Structure and Global Data o external file structure logical structure logical record description
o

access method o global data 3. Test provisions

test guidelines o special considerations 2. Appendices

o

What Is Software? In the context of a book on software design, it should be obvious that we are concerned with designing software. It is far from clear, however, just what that phrase means. We can approach software from many different perspectives, each with its own implications for design. In this book, we emphasize software as a medium for the creation of virtualitiesthe world in which a user of the software perceives, acts, and responds to experiences. The creation of a virtual world is immediately evident in computer games, which dramatically engage the player in exploring the vast reaches of space, fighting off the villains, finding the treasuresactively living in whatever worlds the game designer can imagine and portray. But the creation of worlds is not limited to game designers. There is also a virtual world in a desktop interface, a spreadsheet, and the Internet. The difference between interface and world was recognized by the designers of the Xerox Starthe progenitor of the modern graphical user interfacein their focus on what David Liddle (Chapter 2) refers to as the user's conceptual model. Later projects have used other termssuch as conceptual model, cognitive model, users model, interface metaphor, user illusion, virtuality, and ontologyall carrying the connotation that a space of existence, rather than a set of devices or images, is being designed. The term virtuality highlights the perspective that the world is virtual, in a space that is neither a mental construct of the user nor a mental construct of the designer. Today, we are all familiar with the virtuality of the standard graphical user interfacewith its windows, icons, folders, and the like. Although these virtual objects are loosely grounded in analogies with the physical world, they exist in a unique world of their own, with its special logic and potentials for action by the user. The underlying programs manipulate disk sectors, network addresses, data caches, and program segments. These underpinnings do not appearat least when things are working normally in the desktop virtuality in which the user works. Software is not just a device with which the user interacts; it is also the generator of a space in which the user lives. Software design is like architecture: When an architect designs a home or an office building, a structure is being specified. More significantly, though, the patterns of life for its inhabitants are being shaped. People are thought of as inhabitants rather than as users of buildings. In this book, we approach software users as inhabitants, focusing on an how they live in the spaces that designers

create. Our goal is to situate the work of the designer in the world of the user. The view of software that we adopt in this book is, of course, not the only appropriate or valuable one. Designers can master software, like any technology, only by understanding it from contrasting perspectives. These perspectives provide a larger context for our discussions. Software engineering The phrase software design is often used to characterize the discipline that is also called software engineeringthe discipline concerned with the construction of software that is efficient, reliable, robust, and easy to maintain. The substantial body of literature on software design as an engineering activity (for example, Pfleeger, 1991; Rumbaugh, 1991; Blum, 1992; Brooks, 1975, 1995), is complementary to the concerns developed in this book. Interface design In a way, the title of this book is misleading. Bringing Design to Software implies that the object of design is software, leaving out considerations of the interface devices that are the inevitable embodiment of software for the user. Design cannot be neatly divided into compartments for software and for devices: The possibilities for software are both created and constrained by the physical interfaces. In today's world of computer applications, the vast majority of applications present themselves to users in a standard waya visual display with a keyboard and mouse. But the future of computing will bring richer resources to physical human computer interactions. Some new devices are already in use on a modest scalefor example, pen-based personal digital assistants (PDAs), virtualreality goggles and gloves, and computers embedded in electromechanical devices of all kinds. Researchers are exploring further possibilities, including tactile input and output devices, immersive environments, audio spaces, wearable computers, and a host of gadgets that bear little resemblance to today's personal computer or workstation. Many current textbooks and reading collections on humancomputer interaction (for example, Shneiderman, 1992; Dix et al., 1993; Preece et al., 1994; and Baecker et al., 1995) include sections on interface devices. As experience with a wider variety of devices accumulates, the design of interaction based on new combinations of devices and software will be an important emerging topic in what we havefor the momentcalled software design. Humancomputer interaction

Whenever someone designs software that interacts with people, the effects of the design extend beyond the software itself to include the experiences that people will have in encountering and using that software. A person encountering any artifact applies knowledge and understanding, based on wide variety of cognitive mechanisms grounded in human capacities for perception, memory, and action. Researchers in humancomputer interaction have studied the mental worlds of computer users, developing approaches and methods for predicting properties of the interactions and for supporting the design of interfaces. Although it would be overstating the case to say that the cognitive analysis of humancomputer interaction has led to commonly accepted and widely applied methods, there is a substantial literature that can be of value to anyone designing interactive software (for example, Card et al., 1983; Norman and Draper, 1986; Carroll, 1991; Helander, 1988). Practical applications of HCI research are promoted by organizations such as ACM SIGCHI, the Human Factors and Ergonomics Society (see Perlman et al., 1995), and the Usability Professionals Association. Art The experience of a person who is interacting with a computer system is not limited to the cognitive aspects that have been explored in the mainstream literature on humancomputer interaction. As humans, we experience the world in aesthetic, affective, and emotional terms as well. Because computing evolved initially for use in the laboratory and the office, noncognitive aspects have been largely ignored, except by creators of computer games. Yet, whenever people experience a piece of software whether it be a spreadsheet or a physics simulationthey have natural human responses. They experience beauty, satisfaction, and fun, or the corresponding opposites. As computing becomes integrated into technologies for entertainment, and as the typical user moves from the well-regimented office to the home recreation room, software designers will need to focus more on the affective dimensions of human response (see, for example, Laurel, 1993). We can learn from the history of other human communication media, and can adapt the principles and techniques of novelists, film makers, composers, visual artists, and many other designers in what are loosely called the arts. Designing for the full range of human experience may well be the theme for the next generation of discourse about software design. What Is Design? Perhaps even more difficult than the task of defining software is the task of defining design. A dictionary provides several loosely overlapping meanings, and a glance at the design section in a library or bookstore

confuses the issue even more. Although we label it with a noun, design is not a thing. The questions that we can ask fruitfully are about the activity of designing. The authors of our chapters did not produce a simple definition; rather, each contributes to an answer by providing a perspective on what people do when they design. Design is conscious People may refer to an object as being well designed whenever it is well suited to its environment, even if this suitability resulted from a process of unintentional evolution. In this book, we concentrate on what happens when a designer reflects on and brings focus to the design activity. Complex systems can evolve without a coherent master designfor example, cities (see Alexander, 1964) and the Internet (see Krol, 1994) but even in these cases, conscious design is at work in creating the individual pieces and relationships that make up the whole. Consciousness about designing does not imply the application of a formal, consistent, or comprehensive theory of design or of a universal methodology. Systematic principles and methods at times may be applicable to the process of design, but there is no effective equivalent to the rationalized generative theories applied in mathematics and traditional engineering. Design consciousness is still pervaded by intuition, tacit knowledge, and gut reaction. Design keeps human concerns in the center All engineering and design activities call for the management of tradeoffs. Real-world problems rarely have a correct solution of the kind that would be suitable for a mathematics problem or for a textbook exercise. The designer looks for creative solutions in a space of alternatives that is shaped by competing values and resource needs. In classical engineering disciplines, the tradeoffs can often be quantified: material strength, construction costs, rate of wear, and the like. In design disciplines, the tradeoffs are more difficult to identify and to measure. The designer stands with one foot in the technology and one foot in the domain of human concerns, and these two worlds are not easily commensurable. As an example, it is easy for software designers to fall into a singleminded quest, in which ease of use (especially for beginning users) becomes a holy grail. But what is ease of use? How much does it matter to whom? A violin is extremely difficult for novices to play, but it would be foolhardy to argue that it should therefore be replaced by the autoharp. The value of an artifact may lie in high-performance use by virtuosos, or in ease of use for some special class of users, such as children or people

with disabilities. There is room for the software equivalents of high-strung racing cars alongside automatic-transmission minivans. In Chapter 5, Paul Saffo explores the dimensions of what matters to consumers of high technology. He introduces a concept that he calls the threshold of indignationthe point in the tradeoff curve where, for different groups of users, the perceived value is exceeded by the perceived hassle. A multidimensional understanding of what concerns users is critical to an understanding of where new software and electronics technologies will lead in practice. Design is a dialog with materials The ongoing process of designing is iterative at two levels: iteration by the designer as a piece of current work develops, and iteration by the community as successive generations reveal new possibilities for the medium. The cycle of an individual designer's reflection in action is described in detail in an interview with Donald Schn (Chapter 9), and is illustrated in Shahaf Gal's account of a student mechanical-design project (Chapter 11). As Schn and Gal point out, designing is inherently complex every choice by the designer has both intended and unintended effects. Designing is not a process of careful planning and execution, but rather it is like a dialog, in which the dialog partnerthe designed object itself can generate unexpected interruptions and contributions. The designer listens to the emerging design, as well as shapes it. Design always implies a medium of construction, and new technologies bring with them new domains for design. Architecture as we know it appeared with the technology for building with stone. Graphic design emerged with the technologies of printing, and modern product design flourished with the development of plastics that expanded the possible variety of forms for everyday products. The computer has produced the field of interaction design, in which new kinds of virtualities can be created and modified with a velocity that is unprecedented. The effect of new prototyping media on industries as a whole is reflected in a discussion of the cultures of prototyping by Michael Schrage in Chapter 10. Design is creative It is one thing to lay out a list of criteria for good design. It is quite another thing to do design well. Many books have been written on systematic methods for design, and in particular for the design of interfaces and interactive systems (for example, Hix and Hartson, 1993; Newman and Lamming, 1995). These texts provide useful guidance, yet designing is a creative activity that cannot be fully reduced to standard steps, and that cannot even be comprehended as problem solving. As David Kelley

argues in Chapter 8, a designer lacks the comforting restraints of a wellorganized engineering discipline, because designing is inherently messy; it includes, but goes beyond, the ability to be creative in solving problems. It begins with creativity in finding the problemsenvisioning the needs that people have but do not recognize. For the artistdesigner, depicted by Gillian Crampton Smith and Philip Tabor in Chapter 3, interaction design is more an art than a scienceit is spontaneous, unpredictable, and hard to define. The skill of the artist designer is not reducible to a set of methods, and is not learned through the kind of structured curriculum that serves in science and engineering. On the other hand, it is not a mysterious gift. There is a long and rich tradition of education in the design fields; it draws on the interaction between learner and teacher, designer and critic. Design is communication Previous sections have described the interaction between the user and his world, and the interaction between the designer and her materials. What matters most is the interaction between these two interactions. A virtuality is neither just what the designer thinks it is, nor what any particular user thinks it is. It exists in the ongoing dialog between designers and users. To succeed in designing, we need to understand how designers convey meaning. At a surface level, designed artifacts communicate content. As Crampton Smith and Tabor point out, even an object as mundane as a railway timetable conveys meanings at multiple levels. Skilled designers in every discipline know how to manage these layers of meaning. In addition, an active artifactwhether it be a computer program or a coffee maker communicates to users about its use. A device as apparently simple as a door communicates to its users through convention. A door with a flat plate near shoulder level says "Push me!" One with a round knob says "Twist here." Although these messages are constrained by the physical mechanisms, they are also a matter of convention and learning, as every tourist finds out in trying to deal with everyday objects in an unfamiliar culture. John Rheinfrank and Shelley Evenson (Chapter 4) explain how these physical affordances are one constituent of a broader design language in which a variety of meanings is being communicated, including the functional, the cognitive, the connotative, and the aesthetic. Whenever a designer constructs an object for human use, she is drawing on a background of shared design language in the community and culture. As is true of any human language, what is visible in a statement is only a small part of the full picture. A hearer of the sentence "Im going to kill you!" cannot interpret the intended meaning without knowing the

situational contextwas it said to a friend walking onto the tennis court, in an anonymous note mailed to the President, or by a parent to a child who has just left dirty clothing on the bathroom floor again? The literal meaning is but the shadow of the meaning in context. The same is true for the artifacts that we build, including software: People do not approach them in isolation. Every object appears in a context of expectations that is generated by the history of previous objects and experiences, and by the surroundings in the peripherythe physical, social, and historical context in which the object is encountered. In Chapter 7, John Seely Brown and Paul Duguid describe the border resources that every designer draws on in creating something that is new and that inevitably also takes meaning from what came before. They argue that widespread blindness to the periphery in software design has led to designs that may extend the literal functionality of traditional forms, but that are inappropriate in the larger human context. Design has social consequences Much of the discussion on software design uses examples from generic mass-distribution software, such as word processors, operating systems, spreadsheets, graphics programs, and games. Although many key concerns of software design are addressed in these applications, others are not. These highly visible applications are part of a larger picture that includes a vast number of vertical applications (for example, a medical-office billing application) and systems designed for a specific workplace setting. In these more targeted applications, the designer can see and take into account the specific effects of the design on the people who will inhabit it. In Chapter 14, Sarah Kuhn looks at the organizational aspects of software design, which come to center stage when we build integrated computer systems for specific organizations and workplaces. The needs and concerns of the people in those workplaces can lead to complexand, at times, controversialdesign considerations, which we can address only by making the social and political dimensions an explicit part of the analysis and of the design dialog. The designer takes on a role that includes organizational as well as technical design, and can enlist workers directly in this process through techniques such as participatory design. In Chapter 6, Peter Denning and Pamela Dargan introduce a technique for addressing work content as the central focus of design, which they call action-centered design. Their experience in working with traditional software engineering techniques has pointed out areas of failure, which designers can address by shifting attention to the structure of the work rather than concentrating on the structure of the information systems that support the work.

Design is a social activity In concentrating on the activity of an individual designer, we can fall into the error of assuming that the overall quality of a design is primarily a result of the qualities and activities of the creative individual. As Kelley points out, the designer operates in a larger setting, which is both facilitated and constrained by interactions with other people. In Chapter 12, Donald Norman dramatically recounts how design in a large organization is shaped by factors and forces that transcend the considerations of an individual designer. He describes two levels at which an organization constrains the space of possible designs: the explicit level of working with the differing goals and needs of the many parties in a large organization, and the tacit effect of an organization's unique culture. Norman's saga of how organizational structures can complicate the activity of designing is complemented by Laura De Young's analysis of what a software development organization can do to facilitate customeroriented design (Chapter 13). De Young draws examples from her work as a consultant and from the experience of Intuitthe producer of the extremely successful home financial application, Quickento identify the principles that designers can follow within any organization to focus the design process on the quality of the user's experience. How Do Software and Design Fit Together? As the preceding sections make clear, you will not find a simple definition of software design in the rest of this book. Although the book initially emerged from a gathering intended to produce such a definition, the dialog led instead to a flowering of distinct perspectives, which expanded in unique directions from a common core of issues. In developing those perspectives into a book, we have worked to enrich the dialog among them. Each chapter explores its authors' chosen concerns, in its authors' voices. Interleaved with the chapters are brief profiles, each describing a successful project or program that exemplifies the book's concepts in practice. The resulting text requires work from you. It is not digested and homogenized into a single message that a software designer can conveniently summarize and apply. The integration will come as you consider how the questions that are raised here might apply to your own concerns and activities. What is common to all the authors is a concern for the situated nature of designa sensitivity to the human context in all its richness and variety.