Black Boxes

Introduction

When you study object-oriented programming, or even procedural programming, you are taught the idea of abstraction.

For example, when you learn about OOP, you are told that the user should only see the public methods. Data members and the code to implement the public methods should be hidden away.

The public methods represent the objects interface. They tell the user of the object what are valid methods they can call. If the designer of the class is good, they have given you a description of what each method does abstractly. That is, they haven't told you how it's implemented, only its behavior.

You can think of an object as a black box. You feed in inputs (through arguments) and get back an output (through the return value).

Similarly, in procedural languages (like C), you pass in arguments to a function, and you get a return value as a result. The actual implementation is hidden away.

Why think about circuits as black boxes? For the same reason you think about functions as black boxes. It lets you focus on the important aspects of the function, but hides away detail. For example, you were taught how scanf() or cin works. This was explained at a high-level. However, do you really know the implementation? You probably don't. And, what's more, you don't have to!

The implementation is complex, and it may be difficult to remember all the details. Of course, some people look at the implementation when the description of what a function or object does is not clear. But if the description is clear, you don't have to care.

Conventions

As we draw black boxes, I want to make some conventions. Sometimes, I will draw the box itself, as in the diagram below. However, it's convenient to indicate inputs and outputs in certain ways.

We will follow these conventions:

If the black box is missing, it should then be easy to tell what are inputs, etc.

When you see the black box, you should think of the inputs (both data and control) as being provided from the outside world into the black box. Where do the inputs come from? Doesn't matter. Just think about it like programming. When you write a function, do you worry about who calls the function? You write a function to be useful in many situations. Same thing here.

When you see the outputs, think of that as being generated by the black box, and sent to whoever needs it. That is, the black box is sending data to the outside world.

In this example, x and y are data inputs. c is a control input. z1, z0 are outputs.

You'll also notice the box has labels on the inside. Think of the labels on the outside as arguments in a function call. Arguments are also called actual parameters.

Think of the labels on the inside as parameters. Parameters are also called formal parameters.

Thus, x is an input that comes from the outside world that is sent to the a input of the circuit. x is like an argument, while a is like a parameter.

Sometimes, both the names of the input from the outside world, and the input label on the circuit are the same. For example, c is both the name of the input from the outside world and the label on the box. Similarly, the output labels on the circuit, and the outputs to the outside world are named the same.

Summary

It's useful to draw the circuit using a black box, because it allows you to think about what's outside the box (data being sent into and out of the box) and also makes you think about what's inside the box (implementation).

Web Accessibility