THIS BOOK is about:

• The Unified Modeling Language (UML), and how to use it effectively

• Architecting your applications so that they're maintainable and extensible

• Analysis, so you know what you have to build

• Design techniques, so that you know how you're going to build your application

• Creating applications for stand-alone, client/server, and distributed environments

• Using both relational and object-oriented (OO) databases to make your objects persistent

• Collecting the right metrics to improve your development approach

• Applying OO patterns to improve the quality of your applications

• Testing approaches to ensure that your applications work

• User interface design, so your users can actually work with the systems that you build

• Coding applications in a way that makes them maintainable and extensible

Welcome to Building Object Applications. To make this book easier to work with it is divided into the following five parts:

Part I Introduction

1. Chapter 1 Where We've Been Before—Object-Oriented Concepts and Techniques

Part II Object-Oriented Analysis, Design, and Architecture

1. Chapter 2 Bubbles and Lines—Useful Diagrams for Object-Oriented Analysis and Design

2. Chapter 3 Improving Your Design—A Class-Type Architecture

3. Chapter 4 Reusing Your Development Efforts—Object-Oriented Patterns

4. Chapter 5 Development in the 90s and Beyond—Designing Distributed Object-Oriented Applications

What We'll Learn in This Chapter

I'm a strong believer in something called full life-cycle object-oriented testing (FLOOT), which involves testing your object-oriented applications throughout the entire system development life cycle (SDLC). We'll see that there are many reasons why you want to test throughout the entire SDLC, not the least of which is if you leave testing to the end of a project it typically doesn't get done properly. In this chapter we will discuss a number of testing techniques that together form a FLOOT process (there has to be a music joke in here somewhere).

AS A BROAD-FACED INTRODUCTION to object-oriented (OO) technology, this is one of the best books that I have read. It is well written, employing a style that makes it enjoyable to read and easy to understand. Although it covers a diverse range of topics, the coverage is balanced and the topic selection is well chosen.

Topics that usually receive only passing mention in other texts of this kind are included. The first part of the book looks at where we have been in the field and lays a foundation for the rest of the text by introducing general concepts. The second part focuses on architectural issues, and the subjects of object-oriented analysis, design, and patterns are introduced. The author chooses to feature UML notation in the short examples that are presented. The third part introduces OO matrics, user interface design, and OO databases and presents a brief survey of some OO languages. The fourth part of the book focuses on OO testing. All these subjects are covered in much greater detail in more specialized books—but that is to be expected in a book of this kind. Experienced practitioners may object to the omission of important topics and incomplete coverage of some subject areas, but this book is not meant to be a rigorous treatise on object technology; rather, it is a compelling early read for those interested in this area of software development.

In the basic model of communication complexity, Alice and Bob were all powerful, but deterministic. This means that in any stage, when one of the players needs to communicate a bit, the value of this bit is a deterministic function of the player's input and the communication so far. In this chapter, we study what happens when Alice and Bob are allowed to act in a randomized fashion. That is, the players are also allowed to “toss coins” during the execution of the protocol and take into account the outcome of the coin tosses when deciding what messages to send. This implies that the communication on a given input (x, y) is not fixed anymore but instead it becomes a random variable. Similarly, the output computed by a randomized protocol on input (x, y) is also a random variable. As a result, the success of a randomized protocol can be defined in several ways. The first possibility, which is more conservative (sometimes called Las-Vegas protocols), is to consider only protocols that always output the correct value f (x, y). The more liberal possibility is to allow protocols that may err, but for every input (x, y) are guaranteed to compute the correct value f(x, y) with high probability (sometimes called Monte-Carlo protocols). Similarly, the cost of a randomized protocol can also be defined in several ways. We can either analyze the worst case behavior of the protocol, or we can analyze the average case behavior.

This book surveys the mathematical field of communication complexity. whereas the original motivation for studying this issue comes from computer systems and the operations they perform, the underlying issues can be neatly abstracted mathematically. This is the approach taken here.

Communication

The need for communication arises whenever two or more computers, components, systems, or humans (in general, “parties”) need to jointly perform a task that none of them can perform alone. This may arise, for example, due to the lack of resources of any single party or due to the lack of data available to any single party.

In many cases, the need for communication is explicit: When we search files on a remote computer it is clear that the requests and answers are actually communicated (via electrical wires, optical cables, radio signals, etc.). In other cases, the communication taking place is more implicit: When a single computer runs a program there is some communication between the different parts of the computer, for example, between the CPU and the memory, or even among different parts of the CPU. In yet other cases, there is no real communication going on but it is still a useful abstraction. For a problem whose solution relies on several pieces of data, we can imagine that these pieces of data need to communicate with each other in order to solve the problem; in reality, of course, this communication will be achieved by a processor accessing them all.

Complexity

The notion of complexity is becoming more and more central in many branches of science and in particular in the study of various types of computation.

In the standard two-party model the input (x, y) is partitioned in a fixed way. That is, Alice always gets x and Bob always gets y. In this chapter we discuss models in which the partition of the input among the players is not fixed. The main motivation for these models is that in many cases we wish to use communication complexity lower bounds to obtain lower bounds in other models of computation. This would typically require finding a communication complexity problem “hidden” somewhere in the computation that the model under consideration must perform. Because in such a model the input usually is not partitioned into two distinct sets x1, …, xn and y1, …, yn, such a partition must be given by the reduction. In some cases the partition can be figured out and fixed. In some other cases we must use arguments regarding any partition (of a certain kind). That is, we require a model where the partition is not fixed beforehand but the protocol determines the partition (independently of the particular input). Several such “variable partition models” are discussed in this chapter.

Throughout this chapter the input will be m Boolean variables x1, …, xm, and we consider functions f: {0, l}m → {0, 1}. We will talk about the communication complexity of f between two disjoint sets of variables S and T. That is, one player gets all bits in S and the other all bits in T

Worst-Case Partition

The simplest variable partition model we may consider is the “worst-case” partition: split the input into two sets in the way that maximizes the communication complexity.

In this chapter, we briefly mention several relevant topics not covered in this book.

Noisy Channels

[Schulman 1992, Schulman 1993] present a variant of the two-party model, in which Alice and Bob are communicating using a noisy channel. That is, each bit that is sent by either Alice of Bob is flipped with some probability λ < 1/2 (which is independent from what happens in other transmissions). Say, a player may send the bit 0 but the other player will receive 1. The question is what is the communication complexity of computing a function f in such a model.

Note that if Alice and Bob use a protocol P that was designed for the standard (noiseless) model, each such flip may lead the two players to be in different places in the protocol tree, and hence all subsequent communication may be meaningless. A naive approach would be to send each bit ℓ times instead of only once, and let the receiver, upon receiving a block of ℓ bits, take the majority of these ℓ bits. Because the bits are flipped independently, we can see that if ℓ = O(log t), where t is the communication complexity of the original protocol P (and λ is fixed), then there is a good probability that all the t bits will arrive correctly. This solution uses O(t log t) bits. Schulman presented transformations that result in an O(t) protocol P′ (either randomized [Schulman 1992] or deterministic [Schulman 1993]) that fails in simulating P with exponentially small probability in t (and again, λ is fixed). For extensions, see [Rajagopalan and Schulman 1994]. These results generalize results of [Shannon 1948] for one-way communication.

The general communication problem may be described in the following terms: A system must perform some task that depends on information distributed among the different parts of the system (called processors, parties, or players). The players thus need to communicate with each other in order to perform the task. Yao's model of communication complexity, which is the subject of this chapter, is the simplest scenario in which such a situation occurs. Yao's model makes the following simplifying assumptions:

• There are only two parts in the system.

• Each part of the system gets a fixed part of the input information.

• The only resource we care about is communication.

• The task is the computation of some prespecified function of the input.

These assumptions help us concentrate on the core issue of communication. Despite its apparent simplicity, this is a very rich model that exhibits a nice structure and in which issues such as randomization and nondeterminism, among others, can be studied. We can also translate our understanding of this model to many other scenarios in which communication is a key issue.

The Model

Let X, Y, Z be arbitrary finite sets and let f: X × Y → Z be an arbitrary function. There are two players, Alice and Bob, who wish to evaluate f(x, y), for some inputs x ∈ X and y ∈ Y. The difficulty is that Alice only knows x and Bob only knows y. Thus, to evaluate the function, they will need to communicate with each other.

In this chapter we describe several other ways to use communication complexity for proving various results on Boolean circuits. These results differ from those in Chapter 10 in that they do not use the connection between the circuit complexity of f and the communication complexity ofthe corresponding relation Rf and in that the circuits considered here are not restricted to use only ∨ and ∧ gates but instead use richer families of gates.

Small Circuits

A Q-circuit is a directed acyclic graph whose gates are taken from a fixed family of gates Q. Each of the gates in the family takes as an input a sequence of bits that are either inputs of the circuit or outputs of previously computed gates and its output is also a bit. The circuit defines a function over {0, 1}m in the natural way. The cost of a circuit here is its size (the number of gates). The results proved in this section can be thought of as an extension of the results proven in Section 9.1 for decision trees (Q-circuits are different than decision trees over Q in that decision trees only apply functions from Q on the input variables). In particular, we get lower bounds for the size of threshold circuits.

Definition 11.1:The Q-circuits complexity of a function f, denoted SQ(f), is the minimum cost of a Q-circuit computing f.

Recall the definition of the measure Dworst (Definition 7.1).

Lemma 11.2: Denote cQ = maxq∈QDworst(q). Then, for all f, SQ(f) ≥ Dworst(f)/cQ.

In Chapter 3 we considered randomized communication complexity, where Alice and Bob are allowed to use randomness during the execution of protocols. In this chapter we apply various communication complexity measures and results to the study of randomness in other areas.

Quasirandom Graphs

Randomly chosen graphs have many nice properties. It is an interesting question whether we can construct a graph with some of the basic properties of random graphs. The following definition captures one family of such interesting properties.

Definition 13.1:Let G = (V, E) be a graph on N vertices. G is a k-quasirandom to within ε if, when choosing at random k vertices v1, …, vk from V, the induced subgraph H is distributed to within statistical distance of at most ε from the uniform distribution on the 2(½) k-vertex graphs (if vi = vj there is no edge connecting them).

The intuition is that if G was a truly random graph (that is, for every two vertices v1, v2 ∈ V the edge (v1, v2) is in E with probability 1/2), then each k vertex graph is equally likely to appear in G. It turns out that the distributional communication complexity of a certain function associated with the graph is closely related to its being quasirandom.

Definition 13.2:Let G be a graph on N = 2n vertices. The function EDGEG(x, y) on two n-bit strings x and y is defined to be 1 iff there is an edge between the vertices x and y in the graph G.