Another tool that helps us understand and manage complexity is the class/instance relationship. The term “class/instance relationship” is more commonly used in software than in hardware. A class is a construct that describes the general features of something, and an instance is a specific occurrence of the class. The instance is often referred to as the instantiation of the class.

The idea of class/instance is quite common. For example, if we referred to a model of a car (say, a Ford Explorer), that is the class, and an instance would be a specific Vehicle Identification Number (VIN). A part number refers to a class, and a serial number refers to an instance. In many computer languages, the class/instance relationship is explicitly supported. For example, when programming the Web interface of an online service application, we may use different instances of the class “Button” to represent different buttons on the interface that do different things (such as refresh the screen or submit information to the server) when we click on them.

We have already subtly made use of the class/instance relationship. A careful examination of Table 3.1 reveals that there are two analysts. We could have created a class called “Analyst,” listed it on the team roster, and then identified two instances of that class. The class/instance relationship is a useful way to manage complexity when an entity recurs many times and when classes can easily be instantiated. The 11 players on a soccer team and the 88 keys of a piano are instances of the classes “Player” and “Key,” respectively.

A related idea is the specialization/generalization relationship. This relationship describes the connection between a general object and a set of more specific objects.

As we will see in Part 2, the specialization operation is used extensively in design. In shopping for a house, choosing which house to buy for a given set of occupants, budget, and setting is a process of specialization. The general object is “House,” and specific objects could be different house styles, such as a colonial house, a Victorian house, and a modern house. In Team XT, we created three specializations of the generalization “Group”: a requirements development group, a design group, and a support group.

Specialization is akin to the concept of inheritance in object-oriented programming, in which a class can be created starting from a more general class, from which we inherit some attributes and functionality and to which we can add some new attributes and functionality.

Recursion occurs when the process or object uses itself within the whole. Said another way, it is the use of entities or relationships in a self-similar way. If a routine or function uses itself, or an approach used at one level of a system is used again at other levels within the system, this is recursion.

In the example of Team XT, we used a mild form of recursion. The entire sum of the members is a team. Then, within the team, there are three groups, each of which is a mini-team, as shown in Figure 3.4.

Recurrence is commonly and very explicitly used in software engineering. For example, in creating a network with nodes and edges, one possible implementation is to have a class “Node” that has an attribute “Neighbors” that is an array of Nodes. Thus, the class “Node” is defined recursively, in terms of itself.