7.2 Defining the key abstractions as an initial step

Experience gained in numerous framework projects has proven that framework development requires sound domain knowledge. This is especially true in the initial steps of framework development. Of course, no methodology can provide the domain knowledge or the resulting domain language what can be expected from methodological guidelines are the priorities and the order in which to accomplish certain steps.

If a framework is developed from scratch, the critical first step is the identification and coarse-grained design of a domain's key abstractions. Class-Responsibility-Collaboration (CRC) cards can support that effort. The CRC card approach was presented by Beck and Cunningham (1989) at the OOPSLA'89 conference. CRC cards are helpful in finding objects/classes in general. Their value stems from the fact that they enforce a coarse-grained view on the domain's principal entities. Basically, they capture the class/interface name, its handful of responsibilities (not the methods, which represent a more detailed view) and whether there is a close relationship between the entities without having to specify the kind of relationship. Figure 7.2 shows the CRC cards of the abstract classes Component and Container in Java's Swing framework library. The overlapping of the two cards provides a visual clue that the two abstractions are closely related. That is also indicated in the Collaborations sections of the two cards. Note that CRC cards are plain US index cards as used in offices. Real paper cards are considered to be better suited for this purpose than computerized versions that are manipulated on screen by means of a software tool. Beck and Cunningham (1989) stress the value of physically moving the paper cards around for example, on a pin wall: 'When learners/designers pick up an object, they seem to more readily identify with it, and are prepared to deal with the remainder of the design from its perspective.'

Figure 7.2. Sample CRC cards for the Java Swing abstractions Component and Container

We suggest creating a separate CRC design that comprises only the abstract entities of the framework under development. We refer to that as the aCiRC cards (abstract Class/interface Responsibility Collaboration cards). The two aCiRC cards of the Java Swing framework are the one for Component and the one for Container and just those!

This leads us to a hint regarding the typical number of aCiRC cards in a framework design. The interesting conclusion from studying frameworks in various domains and of varying complexity regarding the overall number of classes and interfaces is that, first, the number of domain abstractions is not directly proportional to the number of classes and, second, the absolute number of domain abstractions is rather small. The typical number is between two and seven abstractions. Though this is only a rough rule of thumb, it gives a clue regarding the number of aCiRC cards you should expect.

aCiRC cards as basis for framework adaptations

If a framework already exists and is to be adapted, aCiRC cards are a valuable means of understanding the principal structure and interactions of the framework. If no aCiRC cards are available, we recommend writing them up in retrospect.