Abstraction means that we concentrate on the essential properties and ignore, abstract from, details that are not relevant at the level we are currently working. Consider, for example, a typical sorting component. From the outside we cannot (and need not be able to) discern exactly how the sorting process takes place. We need only know that the output is indeed sorted. At a later stage, when the details of the sorting component are decided upon, then we can rack our brains about the most suitable sorting algorithm.

The complexity of most software problems makes applying abstraction a sheer necessity. In the ensuing discussion, we distinguish two types of abstraction: procedural abstraction and data abstraction.

The notion of procedural abstraction is fairly traditional. A programming language offers if constructs, loop constructs, assignment statements, and so on. The transition from a problem to be solved to these primitive language constructs is a large one in many cases. To this end, a problem is first decomposed into subproblems, each of which is handled in turn. These subproblems correspond to major tasks to be accomplished. They can be recognized by their description, in which some verb plays a central role (for example, read the input, sort all records, process the next user request, compute the net salary). If needed, subproblems are further decomposed into even simpler subproblems. Eventually we get at subproblems for which a standard solution is available. This type of (top-down) decomposition is the essence of the main-program-with-subroutines architectural style (see Section 11.4).

The result of this type of stepwise decomposition is a hierarchical structure. The top node of the structure denotes the problem to be solved. The next level shows its first decomposition into subproblems. The leaf nodes denote primitive problems. This is schematically depicted in Figure 12.1.

Figure 12.1. The idea of procedural abstraction

The procedure concept offers us a notation for the subproblems that result from this decomposition process. The application of this concept is known as procedural abstraction. With procedural abstraction, the name of a procedure (or method, in object-oriented languages) is used to denote the corresponding sequence of actions. When that name is used, we need not bother ourselves about the exact way in which its effect is realized. The important thing is that, after the call, certain prestated requirements are fulfilled.

This way of going about the process closely matches the way in which humans are inclined to solve problems. Humans too are inclined to the stepwise handling of problems. Procedural abstraction thus offers an important means of tackling software problems.

When designing software, we are inclined to decompose the problem so that the result has a strong time orientation. A problem is decomposed into subproblems that follow each other in time. In its simplest form, this approach results in input – process – output schemes: a program first has to read and store its data, next some process computes the required output from this data, and the result finally is output. Application of this technique may result in programs that are difficult to adapt and hard to comprehend. Applying data abstraction results in a decomposition which shows this affliction to a far lesser degree.

Procedural abstraction is aimed at finding a hierarchy in the program's control structure: which steps have to be executed and in which order. Data abstraction is aimed at finding a hierarchy in the program's data. Programming languages offer primitive data structures for integers, real numbers, truth values, characters and possibly a few more. Using these building blocks, we may construct more complicated data structures, such as stacks and binary trees. Such structures are of general use in application software. They occur at a fairly low level in the hierarchy of data structures. Application-oriented objects, such as 'paragraph' in text-processing software or 'book' in our library system, are found at higher levels of the data structure hierarchy. This is schematically depicted in Figure 12.2.

Figure 12.2. The idea of data abstraction

For the data, too, we wish to abstract from details that are not relevant at a certain level. In fact, we already do so when using the primitive data structures offered by our programming language. In using these, we abstract from details such as the internal representation of numbers and the way in which the addition of two numbers is realized. At the programming language level we may view the integers as a set of objects (0, 1, −1, 2, −2, ...) and a set of operations on these objects (+, −, ×, /, ...). These two sets together determine the data type integer. To be able to use this data type, we need only name the set of objects and specify its operations.

We may proceed along the same lines for the data structures not directly supported by the programming language. A data type binary-tree is characterized by a set of objects (all conceivable binary trees) and a set of operations on those objects. When using binary trees, their representation and the implementation of the corresponding operations need not concern us. We need only ascertain the intended effect of the operations.

Applying data abstraction during design is sometimes called object-oriented design, since the type of object and the associated operations are encapsulated in one component. The buzzword 'object-oriented' however also has a subtly different meaning in the context of design. We will further elaborate upon this notion in Section 12.3.

Languages such as Ada, Java and C++ offer a language construct (called package, class, and struct, respectively) that allows us to maintain a syntactic separation between the implementation and specification of data types. Note that it is also possible to apply data abstraction during design when the ultimate language does not offer the concept. However, it then becomes more cumbersome to move from design to code.

We noticed before that procedural abstraction fits in nicely with the way humans tend to tackle problems. To most people, data abstraction is a bit more complicated.

When searching for a solution to a software problem we will find that the solution needs certain data structures. At some point we will also have to choose a representation for these data structures. Rather than making those decisions at an early stage and imposing the result on all other components, you are better off if you create a separate subproblem and make only the procedural, implementation-independent, interfaces public. Data abstraction thus is a prime example of information hiding.

The development of these abstraction techniques went hand-in-hand with other developments, particularly those in the realm of programming languages. Procedures were originally introduced to avoid the repetition of sequences of instructions. At a later stage, we viewed the name of a procedure as an abstraction of the corresponding instruction sequence. Only then did the notion of procedural abstraction get its present connotation. In a similar vein, developments in the field of formal data type specifications and language notions for components (starting with the class concept of SIMULA-67) strongly contributed to our present notion of data abstraction.

As a final note, we remark that we may identify yet a third type of abstraction, control abstraction. In control abstraction, we abstract from the precise order in which a sequence of events is to be handled. Though control abstraction is often implicit when procedural abstraction is used, it is sometimes convenient to be able to explicitly model this type of nondeterminacy, for instance when specifying concurrent systems. This topic falls outside the scope of this book.

During design, the system is decomposed into a number of components and the relationships between those components are indicated. In another design of the same system, different components may show up and there may be different relationships between the components. We may try to compare those designs by considering both a typology for the individual components and the type of connections between them. This leads us to two structural design criteria: cohesion and coupling.

Cohesion may be viewed as the glue that keeps the component together. It is a measure of the mutual affinity of the elements of a component. In general we will wish to make the cohesion as strong as possible. In their classic text, Yourdon and Con-stantine (1975) identify the following seven levels of cohesion of increasing strength:

In a classic paper on structured design, (Stevens et al., 1974) provide some simple heuristics that may be of help in establishing the degree of cohesion of a component. They suggest writing down a sentence that describes the function (purpose) of the component and examining that sentence. Properties to look for include the following:

The levels of cohesion identified above reflect the cohesion between the functions that a component provides. Abstract data types cannot easily be accommodated in this scheme. Macro and Buxton (1987) therefore propose adding an extra level, data cohesion, to identify components that encapsulate an abstract data type. Data cohesion is even stronger than functional cohesion.

It goes without saying that it is not always an easy task to obtain the strongest possible cohesion between the elements of a component. Though functional cohesion may be attainable at the top levels and data cohesion at the bottom levels, we often have to settle for less at the intermediate levels of the component hierarchy. The tradeoffs to be made here are what makes design such a difficult, and yet challenging, activity.

The second structural criterion is coupling. Coupling is a measure of the strength of the intercomponent connections. A high degree of coupling indicates a strong dependence between components. A high degree of coupling between components means that we can only fully comprehend this set of components as a whole and may result in ripple effects when a component has to be changed, because such a change is likely to incur changes in the dependent components as well. Loosely coupled components, on the other hand, are relatively independent and are easier to comprehend and adapt. Loose coupling therefore is a desirable property of a design (and its subsequent realization). The following types of coupling can be identified (from tightest to loosest):

The various types of coupling emerged in the 1970s and reflect the data type concepts of programming languages in use at that time. For example, programming languages of that time had simple scalar data types such as real and integer. They allowed arrays of scalar values and records were used to store values of different types. Components were considered data-coupled if they passed scalars or arrays. They were considered stamp-coupled if they passed record data. When two components are control-coupled, the assumption is that the control is passed through a scalar value.

Nowadays, programming languages have much more flexible means of passing information from one component to another, and this requires a more detailed set of coupling levels. For example, components may pass control data through records (as opposed to scalars only). Components may allow some components access to their data and deny it to others. As a result, there are many levels of visibility. The coupling between components need not be commutative. When component A passes a scalar value to B and B returns a value which is used to control the further execution of A, then A is data-coupled to B, while B is control-coupled to A. As a result, people have extended and refined the definitions of cohesion and coupling levels.

Coupling and cohesion are dual characteristics. If the various components exhibit strong internal cohesion, the intercomponent coupling tends to be minimal, and vice versa.

Simple interfaces — weak coupling between components and strong cohesion among a component's elements — are of crucial importance for a variety of reasons:

The concept of information hiding originates from a seminal paper (Parnas, 1972). The principle of information hiding is that each component has a secret which it hides from other components.

Design involves a sequence of decisions, such as how to represent certain information, or in which order to accomplish tasks. For each such decision we should ask ourselves which other parts of the system need to know about the decision and how it should be hidden from parts that do not need to know.

Information hiding is closely related to the notions of abstraction, cohesion, and coupling. If a component hides some design decision, the user of that component may abstract from (ignore) the outcome of that decision. Since the outcome is hidden, it cannot possibly interfere with the use of that component. If a component hides some secret, that secret does not penetrate the component's boundary, thereby decreasing the coupling between that component and its environment. Information hiding increases cohesion, since the component's secret is what binds the component's constituents together. Note that, in order to maximize its cohesion, a component should hide one secret only.

It depends on the programming language used whether the separation of concerns obtained during the design stage will be identifiable in the ultimate code. To some extent, this is of secondary concern. The design decomposition will be reflected, if only implicitly, in the code and should be explicitly recorded (for traceability purposes) in the technical documentation. It is of great importance for the later evolution of the system. A confirmation of the impact of such techniques as information hiding on the maintainability of software can be found in (Boehm, 1983).

In a very general sense, the complexity of a problem refers to the amount of resources required for its solution. We may try to determine complexity in this way by measuring, say, the time needed to solve a problem. This is called an external attribute: we are not looking at the entity itself (the problem), but at how it behaves.

In the present context, complexity refers to attributes of the software that affect the effort needed to construct or change a piece of software. These are internal attributes: they can be measured purely in terms of the software itself. For example, we need not execute the software to determine their values.

Both these notions are very different from the complexity of the computation performed (with respect to time or memory needed). The latter is a well-established field in which many results have been obtained. This is much less true for the type of complexity in which we are interested. Software complexity in this sense is still a rather elusive notion.

Serious efforts have been made to measure software complexity in quantitative terms. The resulting metrics are intended to be used as anchor points for the decomposition of a system, to assess the quality of a design or program, to guide reengineering efforts, etc. We then measure certain attributes of a software system, such as its length, the number of if statements, or the information flow between components, and try to relate the numbers thus obtained to the system's complexity. The type of software attributes considered can be broadly categorized into two classes:

In this subsection, we are dealing with intracomponent attributes. Intercompo-nent attributes are discussed in Section 12.1.5. We may distinguish two classes of complexity metrics:

The easiest way to measure software size is to count the number of lines of code. We may then impose limits on the number of lines of code per component. In (Weinberg, 1971), for instance, the ideal size of a component is said to be 30 lines of code. In a variant, limits are imposed on the number of elements per component. Some people claim that a component should contain at most seven elements. This number seven can be traced back to research in psychology, which suggests that human memory is hierarchically organized with a short-term memory of about seven slots, while there is a more permanent memory of almost unlimited capacity. If there are more than seven pieces of information, they cannot all be stored in short-term memory and information gets lost.

There are serious objections to the direct use of the number of lines of code as a complexity metric. Some programmers write more verbose programs than others. We should at least normalize the counting to counteract these effects and be able to compare different pieces of software.

A second objection is that this technique makes it hard to compare programs written in different languages. If the same problem is solved in different languages, the results may differ considerably in length. For example, APL is more compact than COBOL.

Finally, some lines are more complex than others. An assignment statement such as:

a = b

looks simpler than a loop:

while (current = null) {current = current.next;}

although they each occupy one line.

Halstead (1977) uses a refinement of counting lines of code. This refinement is meant to overcome the problems associated with metrics based on a direct count of lines of code.

Halstead's method, also known as 'software science', uses the number of operators and operands in a piece of software. The set of operators includes the arithmetic and Boolean operators, as well as separators (such as a semicolon between adjacent instructions) and (pairs of) reserved words. The set of operands contains the variables and constants used. Halstead then defines four basic entities:

Figure 12.3 contains a simple sorting routine. Table 12.1 lists the operators and operands of this routine together with their frequencies. Note that there is no generally agreed definition of what exactly an operator or operand is, so the numbers given have no absolute meaning. This is part of the criticism of this theory.

Figure 12.3. A simple sorting routine

Using the primitive entities defined above, Halstead defines a number of derived entities, such as:

The above entities can only be determined after the program has been written. It is, however, possible to estimate a number of these entities. When doing so, the values for n₁ and n₂ are assumed to be known. This may be the case, for instance, after the detailed design step. Halstead then estimates program length as:

An explanation for this formula can be given as follows. There are n₁2n₁ × n₂2ⁿ₂ ways to combine the n given symbols such that operators and operands alternate. However, the program is organized and organization generally gives a logarithmic reduction in the number of possibilities. Doing so yields the above formula for

A number of empirical studies have addressed the predictive value of Halstead's formulae. These studies often give positive evidence of the validity of the theory.

The theory has also been heavily criticized. The underpinning of Halstead's formulae is not convincing. Results from cognitive psychology, such as Stroud's number, are badly used, which weakens the theoretical foundation. Halstead concentrates on the coding phase and assumes that programmers are 100% devoted to a programming task for an uninterrupted period of time. Practice is likely to be quite different. Different people use quite different definitions of the notions of operator and operand, which may lead to widely different outcomes for the values of entities. Yet, Halstead's work has been very influential. It was the first major body of work to point out the potential of metrics for software development.

The second class of intracomponent complexity metrics concerns metrics based on the structure of the software. If we try to derive a complexity metric from the structure of a piece of software, we may focus on the control structure, the data structures, or a combination of these.

If we base the complexity metric on the use of data structures, we may do so by considering, for instance, the number of instructions between successive references to one object. If this number is large, information about these variables must be retained for a long period of time when we try to comprehend that program text. Following this line of thought, complexity can be related to the average number of variables for which information must be kept by the reader.

The best-known structure-based complexity metric is McCabe's cyclomatic complexity (McCabe, 1976). McCabe bases his complexity metric on a (directed) graph depicting the control flow of a component. He assumes that the graph of a single component has a unique start and end node, that each node is reachable from the start node, and that the end node can be reached from each node. In that case, the graph is connected. If the component is a class consisting of one or more methods, then the control graph has a number of connected subgraphs, one for each of its methods.

The cyclomatic complexity, CV, equals the number of predicates (decisions) plus 1 in the component that corresponds to this control graph. Its formula reads

where e, n and p denote the number of edges, nodes, and connected subgraphs in the control graph, respectively.

Figure 12.4 shows the control flow graph for the example routine from Figure 12.3. The numbers inside the nodes correspond to the line numbers from Figure 12.3. The cyclomatic complexity of this graph is 13 − 11 + 1 + 1 = 4. The decisions in the component from Figure 12.3 occur in lines 2, 3 and 4. In both for loops, the decision is to either exit the loop or iterate it. In the if statement, the choice is between the then part and the else part.

McCabe suggests imposing an upper limit of ten for the cyclomatic complexity of a component. McCabe's complexity metric is also applied to testing. One criterion used during testing is to get a good coverage of the possible paths through the component. Applying McCabe's cyclomatic complexity leads to a structured testing strategy involving the execution of all linearly independent paths (see also Chapter 13).^[15]

Complexity metrics such as those of Halstead, McCabe, and many others all measure attributes which are in some sense related to the size of the task to be accomplished, be it the time in man-months, the number of lines of code, or something else. As such, they may serve various purposes: determining the optimal size of a component, estimating the number of errors in a component, or estimating the cost of a piece of software.

Figure 12.4. Control flow graph of the example routine from Figure 12.3

All known complexity metrics suffer from some serious shortcomings, though:

We may formulate these shortcomings as follows: complexity metrics tell us something about the complexity of a component (i.e. a higher value of the metric is likely to represent greater complexity), but a more complex component does not necessarily result in a higher value for a complexity metric. Complexity is made up of many specific attributes. It is unlikely that there will ever be one 'general' complexity metric.

We should thus be very careful in the use of complexity metrics. Since they seem to measure along different dimensions of what is perceived as complexity, the use of multiple metrics is likely to yield better insights. But even then the results must be interpreted with care. Redmond and Ah-Chuen (1990), for instance, evaluated various complexity metrics for a few systems, including the MINIX operating system. Of the 277 components in MINIX, 34 have a cyclomatic complexity greater than ten. The highest value (58) was observed for a component that handles a number of ASCII escape character sequences from the keyboard. This component, and most others with a large cyclomatic complexity, was considered 'justifiably complex'. An attempt to reduce the complexity by splitting those components would increase the difficulty of understanding them while artificially reducing its complexity value. Complexity yardsticks too can cause harm in misuse.

Finally, we may note that various validations of both software science and cyclomatic complexity indicate that they are not substantially better indicators of coding effort, maintainability, or reliability than the length of a component (number of lines of code). The latter is much easier to determine, though.

The high correlation that is often observed between a size-related complexity metric and a control-related complexity metric such as McCabe's cyclomatic complexity should not come as a surprise. Large components tend to have more if statements than small components. What counts, however, is the density with which those if statements occur. This suggests a complexity metric of the form CV/LOC rather than CV.

We may depict the outcome of the design process, a set of components and their mutual dependencies, in a graph. The nodes of this graph correspond to components and the edges denote relations between components. We may think of many types of intercomponent relations, such as:

The type of dependencies we are interested in are those that determine the complexity of the relations between components. The amount of knowledge that components have of each other should be kept to a minimum. To be able to assess this, it is important to know, for each component, which other components it uses, since that tells us which knowledge of each other they (potentially) use. In a proper design, the information flow between components is restricted to flow that comes about through method calls. The graph depicting the 'uses' relation is therefore often termed a call graph.

The call graph may have different shapes. In its most general form it is a directed graph (see Figure 12.5a).^[16] If the graph is acyclic, i.e. it does not contain a path of the form M₁, M₂, ..., M_n, M₁, the uses relation forms a hierarchy. We may then decompose the graph into a number of distinct layers such that a component at one layer uses only components from lower layers (Figure 12.5b). Going one step further, we get a scheme such as the one in Figure 12.5c, where components from level i use only components from level i + 1. Finally, if each component is used by only one other component, the graph reduces to a tree (Figure 12.5d).

Figure 12.5. Component hierarchies: (a) directed graph, (b) directed acyclic graph, (c) layered graph, (d) tree

There are various aspects of the call graph that can be measured. Directly measurable attributes that relate to the 'shape' of the call graph include:

We do not know of studies that try to quantitatively relate those measures to other complexity-related aspects such as debugging time, maintainability, etc. They may be used, though, as one of the parameters in a qualitative assessment of a design.

It is often stated that a good design should have a tree-like call graph. It is therefore worthwhile to consider the tree impurity of a call graph, i.e. the extent to which the graph deviates from a pure tree. Suppose we start with a connected (undirected) graph (such as the ones in Figure 12.5b-d, if we ignore the direction of the arrows). If the graph is not a tree, it has at least one cycle, i.e. a path from some node A via one or more other nodes back to A again. We may then remove one of the edges from this cycle and the result will still be a connected graph. We may continue removing edges from cycles until the result is a tree, as we did in the transition from Figure 12.5b to Figure 12.5c to Figure 12.5d. The final result is called the graph's spanning tree. The number of edges removed in this process is an indication of the graph's tree impurity.

In order to obtain a proper measure of tree impurity we proceed as follows. The complete graph K_n is the graph with n nodes and the maximum number of edges. This maximum number of edges is n(n − 1)/2. A tree with n nodes has (n − 1) edges. Given a connected graph G with n nodes and e edges, we define its tree impurity m(G) as the number of extra edges divided by the maximum number of extra edges:

This measure of tree impurity fits our intuitive notion of that concept. The value of m(G) lies between 0 and 1. It is 0 if G is a tree and 1 if it is a complete graph. If we add an edge to G, the value of m(G) increases. Moreover, the 'penalty' of extra edges is proportional to the size of the spanning tree.

It is not always easy, or even meaningful, to strive for a neat hierarchical decomposition. We will often have to settle for a compromise. It may for instance be appropriate to decompose a system into a number of clusters, each of which contains a number of components. The clusters may then be organized hierarchically, while the components within a given cluster show a more complicated interaction pattern. Also, tree-like call graphs do not allow for reuse (if a component is reused within the same system, its node in the call graph has at least two ancestors).

The call graph allows us to assess the structure of a design. In deriving the measures above, each edge in the call graph is treated alike. Yet, the complexity of the information flow that is represented by the edges is likely to vary. As noted in the earlier discussion on coupling, we would like the intercomponent connections to be 'thin'. Therefore, we would like a measure which does not merely count the edges, but which also considers the amount of information that flows through them.

The best-known attempt to measure the total level of information flow between the components of a system is due to Henri and Kafura (1981). Their measures were able to identify change-prone UNIX procedures and evaluate potential design changes. Shepperd (1990) studied the information flow measure extensively and proposed several refinements, thus obtaining a 'purer' metric. Using Shepperd's definitions, the information flow measure is based on the following notions of local and global data flow:

Using these notions of local and global data flow, Shepperd defines the 'complexity' of a component M as

where

A weak point of the information flow metric is that all flows have equal weight. Passing a simple integer as a parameter contributes equally to this measure of complexity as invoking a complex global data structure. The abstract-data-type architectural style easily results in components with a high fan-in and fan-out. If the same system is built using global data structures, its information flow metric is likely to have a smaller value. Yet, the information flow to and from the components in the abstract-data-type style generally concern simple scalar values only and are therefore considered simpler.

In a more qualitative sense, the information flow metric may indicate spots in the design that deserve our attention. If some component has a high fan-in, this may indicate that the component has little cohesion. Also, if we consider the information flow per level in a layered architecture, an excessive increase from one level to the next might indicate a missing level of abstraction.

During design, we (pre)tend to follow a top-down decomposition strategy. We may take a completely different stand and try to compose a hierarchical system structure from a flat collection of system elements. Elements that are in some sense 'closest' to one another are grouped together. We then have to define some measure for the distance between elements and a mathematical technique known as cluster analysis can be used to do the actual grouping. Elements in the same group are more like other elements within the same group and less like elements in other groups. If the measure is based on the number of data types that elements have in common, this clustering results in abstract data types or, more generally, components having high cohesion. If the measure is based on the number of data bindings between elements, the result is likely to have a low value for the information-flow metric.

The measure chosen, in a sense, determines how we define 'friendship' between elements. Close friends should be grouped in the same component while distant relatives may reside in different components. The various qualitative and quantitative design criteria that we have discussed above have different, but in essence very similar, definitions of friendship.

Though much work remains to be done, a judicious use of available design metrics is already a valuable tool in the design and quality assurance of software systems.

At the level of individual methods of an object-oriented system, we may assess quality characteristics of components by familiar metrics such as: length, cyclomatic complexity, and so on. At higher levels of abstraction, object-oriented systems consist of a collection of classes that interact by sending messages. Familiar intercomponent metrics which focus on the relationships between components do not account for the specifics of object-oriented systems. In this section, we discuss a few metrics specifically aimed at characteristics of object-oriented systems. These metrics are listed in Table 12.3.

WMC is a measure of the size of a class. The assumption is that larger classes are in general less desirable. They take more time to develop and maintain and they are likely to be less reusable. The formula is: WMC = Σⁿ_{i = 1} c_i, where c_i is the complexity of method i. For the complexity of an individual method we may choose its length, cyclomatic complexity, and so on. Most often, c_i is set at 1. In that case, we simply count the number of methods. Besides being simple, this has the advantage that the metric can be applied during design, once the class interface has been decided upon. Note that each entry in the class interface counts as one method, the principle being that each method which requires additional design effort should be counted. For example, different constructors for the same operation, as is customary in C++, count as different methods.

Classes in an object-oriented design are related through a subtype — supertype hierarchy. If the class hierarchy is deep and narrow, a proper understanding of a class may require knowledge of many of its superclasses. On the other hand, a wide and shallow inheritance structure occurs when classes are more loosely coupled. The latter situation may indicate that commonality between elements is not sufficiently exploited. DIT is the distance of a class to the root of its inheritance tree. Note that the value of DIT is somewhat language-dependent. In Smalltalk, for example, every class is a subclass of Object, and this increases the value of DIT. A widely accepted heuristic is to strive for a forest of classes, i.e. a collection of inheritance trees of medium height.

NOC counts the number of immediate descendants of a class. If a class has a large number of descendants, this may indicate an improper abstraction of the parent class. A large number of descendants also suggests that the class is to be used in a variety of settings, which will make it more error-prone. The idea thus is that higher values of NOC suggest a higher complexity of the class.

CBO is the main coupling metric for object-oriented systems. Two classes are coupled if a method of one class uses a method or state variable of the other class. The CBO is a count of the number of other classes with which it is coupled. As with the traditional coupling metric, high values of CBO suggest tight bindings with other components and this is undesirable.

In the definition of CBO, all couplings are considered equal. However, if we look at the different ways in which classes may be coupled, it is reasonable to say that:

If we view the methods as bubbles and the couplings as connections between bubbles, CBO simply counts the number of connections for each bubble. In reality, we consider some types of couplings worse than others: some connections are 'thicker' than others and some connections are to bubbles 'further away'. For the representation condition of measurement theory to hold, these empirical relations should be reflected in the numerical relation system.

Martin (2002) defines coupling measures at the package level:

Adding these numbers together results in a total coupling measure of a package P. The ratio I = C_e/(C_e + C_a) indicates the relative dependence of the environment to P with respect to the total number of dependencies between P and its environment. If C_e equals zero, P does not depend at all on other packages and I = 0 as well. If on the other hand C_a equals zero, P only depends on other packages and no other package depends on P. In that case, I = 1. I thus can be seen as an instability measure for P. Larger values of I denote a larger instability of the package.

RFC measures the 'immediate surroundings' of a class. Suppose a class C has a collection of methods M. Each method from M may in turn call other methods, from C or any other class. Let {R_i} be the set of methods called from method M_i. Then the response set of this class is defined as: {M} U_i {R_i}, i.e. the set of messages that may potentially be executed if a message is sent to an object of class C. RFC is defined as the number of elements in the response set. Note that we only count method calls up to one level deep. Larger values of RFC means that the immediate surroundings of a class is larger in size. There is, then, a lot of communication with other methods or classes. This makes comprehension of a class more difficult and increases test time and complexity.

The final object-oriented metric to be discussed is the lack of cohesion of a method. The traditional levels of cohesion express the degree of mutual affinity of the elements of a component. It is a measure of the glue that keeps the component together. If all methods of a class use the same state variables, these state variables serve as the glue which ties the methods together. If some methods use one subset of the state variables and other methods use another subset of the state variables, the class lacks cohesion. This may indicate a flaw in the design and it may be better to split it into two or more subclasses. LCOM is the number of disjoint sets of methods of a class. Any two methods in the same set share at least one local state variable. The preferred value for LCOM is 0.

There are obviously many more metrics that aim to address the specifics of object-oriented systems. Most of these have not been validated extensively, though. Several experiments have shown that the above set does have some merit. Overall, WMC, CBO, RFC and LCOM have been found to be the more useful quality indicators.

These metrics for example were able to predict fault-proneness of classes during design, and were found to have a strong relationship to the maintenance effort. The merits of DIT and NCO remain somewhat unclear.

Note that many of these metrics correlate with class size. One may expect that larger classes have more methods, more descendants, more couplings with other classes, etc. (El Emam et al., 2001) indeed found that class size has a confounding effect on the values of the above metrics. It thus remains questionable whether these metrics tell more than a plain LOC count.

In a functional decomposition, the intended function is decomposed into a number of subfunctions that each solve part of the problem. These subfunctions themselves may be further decomposed into yet more primitive functions, and so on. Functional decomposition is a design philosophy rather than a design method. It denotes an overall approach to problem decomposition which underlies many a design method.

With functional decomposition, we apply divide-and-conquer tactics. These tactics are analogous to, but not the same as, the technique of stepwise refinement as it is applied in 'programming in the small'. Using stepwise refinement, the refinements tend to be context-dependent. As an example, consider the following pseudo-code algorithm to insert an element into a sorted list:

procedure insert(a, n, x);
begin insert x at the end of the list;
    k:= n + 1;
    while elementk is not at its proper place
    do swap elementk and elementk - 1;
    k:= k-1
    enddo;
end insert;

The refinement of a pseudo-code instruction such as element_k is not at its proper place is done within the context of exactly the above routine, using knowledge of other parts of this routine. In the decomposition of a large system, it is precisely this type of dependency that we try to avoid. The previous section addressed this issue at great length.

During requirements engineering, the base machine has been decided upon. This base machine need not be a 'real' machine. It can be a programming language or some other set of primitives that constitutes the bottom layer of the design. During this phase too, the functions to be provided to the user have been fixed. These are the two ends of a rope. During the design phase we try to get from one end of this rope to the other. If we start from the user function end and take successively more detailed design decisions, the process is called top-down design. The reverse is called bottom-up design.

In their pure form, neither the top-down nor the bottom-up technique is likely to be used all that often. Both techniques are feasible only if the design process is a pure and rational one. And this is an idealization of reality. There are many reasons why the design process cannot be rational. Some of these have to do with the intangibles of design processes per se, some originate from accidents that befall many a software project. Parnas and Clements (1986) list the following reasons, amongst others:

Design exhibits a 'yo-yo' character: something is devised, tried, rejected again, new ideas crop up, etc. Designers frequently go about in rather opportunistic ways. They frequently switch from high-level, application domain issues to coding and detailed design matters, and use a variety of means to gather insight into the problem to be solved. At most, we may present the result of the design process as if it came about through a rational process.

A general problem with any form of functional decomposition is that it is often not immediately clear along which dimension the system is decomposed. If we decompose along the time axis, the result is often a main program that controls the order in which a number of subordinate components is called. In Yourdon's classification, the resulting cohesion type is temporal. If we decompose with respect to the grouping of data, we obtain the type of data cohesion exhibited in abstract data types. Both these functional decompositions can be viewed as an instance of some architectural style. Rather than worrying about which dimension to focus on during functional decomposition, you had better opt for a particular architectural style and let that style guide the decomposition.

At some intermediate level, the set of interrelated components comprises the software architecture as discussed in Chapter 11. This software architecture is a product which serves various purposes: it can be used to discuss the design with different stakeholders; it can be used to evaluate the quality of the design; it can be the basis for the work-breakdown structure; it can be used to guide the testing process, etc. If a software architecture is required, it necessitates a design approach in which, at quite an early stage, every component and connection is present. A bottom-up or top-down approach does not meet this requirement, since in both these approaches only part of the solution is available at intermediate points in time.

Parnas (1978) offers the following useful guidelines for a sound functional decomposition:

Obviously, the above guidelines are strongly interrelated. It has been said before that a strictly hierarchical tree structure of system components is often not feasible. A compromise that often is feasible is a layered system structure as depicted in Figure 12.6.

Figure 12.6. A layered system structure

The arrows between the various nodes in the graph indicate the uses relation. Various levels can be distinguished in the structure depicted. Components at a given level only use components from the same, or lower, levels. The layers distinguished in Figure 12.6 are not the same as those induced by the acyclicity of the graph (as discussed in Section 12.1.5) but are rather the result of viewing a distinct set of components as an abstract, virtual machine. Deciding how to group components into layers in this way involves considering the semantics of those components. Lower levels in this hierarchy bring us closer to the 'real' machine on which the system is going to be executed. Higher levels are more application-oriented. The choice of the number of levels in such an architecture is a (problem-dependent) design decision.

This work of Parnas heralds some of the notions that were later recognized as important guiding principles in the field of software architecture. The idea of a minimal subset to which extensions are defined is very similar to the notion of a product-line architecture: a basic architecture from which a family of similar systems can be derived. The layered approach is one of the basic architectural styles discussed in Section 11.4.

The data flow design method originated in the early 1970s with Yourdon and Constantine. In its simplest form, data flow design is but a functional decomposition with respect to the flow of data. A component is a black box which transforms some input stream into some output stream. In data flow design, heavy use is made of graphical representations known as data flow diagrams (DFDs) and structure charts. Data flow diagrams were introduced as a modeling notation in Section 10.1.3.

Data flow design is usually seen as a two-step process. First, a logical design is derived in the form of a set of data flow diagrams. This step is referred to as structured analysis (SA). Next, the logical design is transformed into a program structure represented as a set of structure charts. The latter step is called structured design (SD). The combination is referred to as SA/SD.

Structured analysis can be viewed as a proper requirements engineering method insofar as it addresses the modeling of some universe of discourse (UoD). It should be noted that, as data flow diagrams are refined, the analyst performs an implicit (top-down) functional decomposition of the system as well. At the same time, the diagram refinements result in corresponding data refinements. The analysis process thus has design aspects as well.

Structured design, being a strategy to map the information flow contained in data flow diagrams into a program structure, is a genuine component of the (detailed) design phase.

The main result of structured analysis is a series of data flow diagrams. Four types of data entity are distinguished in these diagrams:

We illustrate the various process steps of SA/SD by analyzing and designing a simple library automation system. The system allows library clients to borrow and return books. It also reports to library management about how the library is used by its clients (for example, the average number of books on loan and authors much in demand).

At the highest level, we draw a context diagram, a data flow diagram with one process, denoting 'the system'. Its main purpose is to depict the interaction of the system with the environment (the collection of external entities). For our simple library system, this is done in Figure 12.7. This diagram has yet to be supplemented by a description of the structure of both the input and output to the central process.

Figure 12.7. Context diagram for library automation

Next, this top-level diagram is further decomposed. For our example, this could lead to the data flow diagram of Figure 12.8 (which is the same as Figure 10.3). In this diagram, we have expanded the central process node of the context diagram. A client request is first analyzed in a process labeled 'preliminary processing'. As a result, one of 'borrow title' or 'return title' is activated. Both these processes update a data store labeled 'catalog administration'. Client requests are logged in a data store 'log file'. This data store is used to produce management reports.

Figure 12.8. Data flow diagram for library automation

For more complicated applications, various diagrams could be drawn, one for each subsystem identified. These subsystems in turn are further decomposed into diagrams at yet lower levels. We thus get a hierarchy of diagrams. As an example, a possible refinement of the 'preliminary processing' node is given in Figure 12.9. In lower-level diagrams, the external entities are usually omitted.

Figure 12.9. Data flow diagram for 'preliminary processing'

The top-down decomposition stops when a process becomes sufficiently straightforward and does not warrant further expansion. These primitive processes are described in minispecs. A minispec serves to communicate the algorithm of the process to relevant parties. It may use notations such as structured natural language, pseudocode, or decision tables. Example screen layouts can be added to illustrate how the input and output will look. An example minispec for 'process request' is given in Figure 12.10.

The contents of the data flows in a DFD are recorded in a data dictionary. Though this name suggests something grand, it is nothing more than a precise description of the structure of the data. This is often done in the form of regular expressions, such as the example in Figure 12.11. Nowadays, the static aspects of the data tend to be modeled in ER diagrams; see Chapter 10.

The result of structured analysis is a logical model of the system. It consists of a set of DFDs, augmented by descriptions of its constituents in the form of minispecs, formats of data stores, and so on. In the subsequent structured design step, the data flow diagrams are transformed into a collection of components (subprograms) that call one another and pass data. The result of the structured design step is expressed in a hierarchical set of structure charts. There are no strict rules for this step. Textbooks on the data flow technique give guidelines, and sometimes even well-defined strategies, for how to get from a set of data flow diagrams to a hierarchical model for the implementation. These guidelines are strongly inspired by the various notions discussed in Section 12.1, most notably cohesion and coupling.

Figure 12.10. Example minispec for 'process request'

Figure 12.11. Example data dictionary entries

The major heuristic involves the choice of the top-level structure chart. Many data-processing systems are essentially transform-centered: input is read and possibly edited, a major transformation is done, and the result is output. One way to decide upon the central transformation is to trace the input through the data flow diagram until it can no longer be considered input. The same is done, in the other direction, for the output. The bubble in between is as the central transform. If we view the bubbles in a DFD as beads, and the data flows as threads, we obtain the corresponding structure chart by picking the bead that corresponds to the central transformation and shaking the DFD.^[18] The processes in the data flow diagram become the components of the corresponding structure chart and the data flows become component invocations. Note that the arrows in a structure chart denote component invocations, whereas the arrows in a data flow diagram denote flows of data. These arrows often point in opposite directions; a flow of data from A to B is often realized through an invocation of A by B. Sometimes it is difficult to select one central transformation. In that case, a dummy root element is added and the resulting input-process-output scheme is of the form depicted in Figure 12.12.

Figure 12.12. From data flow diagram to structure chart

Because of the transformation orientation of the structure chart, the relations between components in the graph have a producer-consumer character. One component produces a stream of data which is then consumed by another component. The control flow is one whereby components invoke subordinate components so as to realize the required transformation. There is a potentially complex stream of information between components, corresponding to the data flow that is passed between producer and consumer.

The major contribution of structured design is found in the guidelines that aim to reduce the complexity of the interaction between components. These guidelines concern the cohesion and coupling criteria discussed in Section 12.1.

The best-known technique for design based on data structures originated with Jackson (1975). The technique is known as Jackson Structured Programming (JSP). Essentials of JSP have been carried over to Jackson System Development (JSD). JSP is a technique for programming-in-the-small and JSD is a technique for programming-in-the-large. We discuss both techniques in turn.

The basic idea of JSP is that a good program reflects the structure of both the input and the output in all its facets. Given a correct model of the data structures, we may straightforwardly derive the corresponding program from the model. It is often postulated that the structure of the data is much less volatile than the transformations applied to the data. As a consequence, designs that take the data as their starting point should be 'better' too. This same argument is also used in the context of object-oriented analysis and design.

JSP distinguishes elementary and compound components. Elementary components are not further decomposed. There are three types of compound component: sequence, iteration and selection. Compound components are represented by diagrams (also called Jackson diagrams or structure diagrams) or some sort of pseudocode (called structure text or schematic logic). The base form of both representations are given in Figure 12.13. In the structure text, 'seq' denotes sequencing, 'itr' denotes iteration, 'sel' denotes selection, and 'alt' denotes alternatives.

Figure 12.13. Compound components in Jackson's notation

Most modern programming languages have structures (loops, if statements and sequential composition) for each of these diagrammatic notations or, for that matter, the corresponding pseudocode for the structure of data. The essence of Jackson's technique is that the structure diagrams of the input and output can be merged, thus yielding the global structure of the program.

To illustrate this line of thought, consider a fragment from a library system. The system keeps track of which books from which authors are being borrowed (and returned). From this log, we want to produce a report that lists how often each title is borrowed. Using Jackson's notation, the input for this function could be as specified in Figure 12.14.^[19] A possible structure for the output is given in Figure 12.15.

The program diagram to transform the log into a report is obtained by merging the two diagrams; see Figure 12.16. The structure of the resulting program can be derived straightforwardly from this diagram (see Figure 12.17).

This merging of diagrams does not work for the lower levels of our problem, 'process mutation' and its subordinate nodes. The cause is something called a structure clash: the input and output data structures do not really match. The reason is that the input consists of a sequence of mutations. In the output, all mutations for a given book are taken together. So, the mutations have to be sorted first. We have to restructure the system, for instance as depicted in Figure 12.18.

A clear disadvantage of the structure thus obtained is that there is now an intermediate file. Closer inspection shows that we do not really need this file. This is immediately clear if we depict the structure as in Figure 12.19.

Figure 12.14. Log of books borrowed and returned, in JSP notation

Figure 12.15. Report of books borrowed, in JSP notation

Figure 12.16. Result of merging the input and output diagrams

Figure 12.17. Top-level structure of the program to produce a report

Here, we may invert component A1 and code it such that it serves as a replacement of component B2. Alternatively (and in this case more likely), we may invert B1 and substitute the result for component A2. In either case, the first-in-first-out (FIFO) type of intermediate file between the two components is removed by making one of the components a subordinate of the other.

Figure 12.18. Restructuring of the system

Figure 12.19. A different view of the system

This example shows the fundamental issues involved in the use of JSP:

If we choose a linear notation for the structure diagrams, the result falls into the class of 'regular expressions'. Thus, the expressive power of these diagrams is that of a finite automaton. Some of the structure clashes crop up if the problem cannot be solved by a finite automaton.

Both in the functional decomposition and in the data flow design methods, the problem structure is mapped onto a functional structure. This functional structure is next mapped onto a program structure. In contrast, JSP maps the problem structure onto a data structure and the program structure is derived from this data structure. JSP is not much concerned with the question of how the mapping from problem structure to data structure is obtained.

Jackson System Development (JSD) tries to fill this gap. JSD distinguishes three stages in the software development process:

The first step in JSD is to model the part of reality we are interested in, the UoD. JSD models the UoD as a set of entities, objects in the real world that participate in a time-ordered sequence of actions. For each entity, a process is created which models the life cycle of that entity. Actions are events that happen to an entity. For instance, in a library the life cycle of an entity Book could be as depicted in Figure 12.20. The life cycle of a book starts when it is acquired. After that it may be borrowed and returned any number of times. The life cycle ends when the book is either archived or disposed of. The life cycle is depicted using process structure diagrams (PSDs). PSDs are hierarchical diagrams that resemble the structure diagrams of JSP, with its primitives to denote concatenation (ordering in time), repetition, and selection. PSDs have a pseudocode equivalent called structure text which looks like the schematic logic of JSP.

Figure 12.20. Process structure diagram for the entity Book

Process structure diagrams are finite state diagrams. In traditional finite state diagrams, the bubbles (nodes) represent possible states of the entity being modeled while the arrows denote possible transitions between states. The opposite is true for PSDs. In a PSD, nodes denote state transitions and arrows denote states.

Figure 12.21. Process structure diagram for the entity Member

Following this line of thought, an entity Member can be described as in Figure 12.21: members enter the library system, after which they may borrow and return books until they cease to be a member.

The modeling stage is concerned with identifying entities and the events (actions) that happen to them. These actions collectively constitute the life cycle of an entity. As with other design methods, there is no simple recipe to determine the set of entities and actions. The approach generally taken has a linguistic stance. From notes, documentation, interviews and the like, we may draw up a preliminary list of actions and entities. One heuristic is to look for real-world objects with which the system is to interact. Since a library is all about books, an entity Book immediately suggests itself. From statements such as 'members borrow books', we may infer that an event Borrow occurs in the life cycle of both books and members. Once such a preliminary list is made up, further reflection should lead to a precisely demarcated life cycle of the entities identified.

Entities are made up of actions. These actions are atomic, i.e. they cannot be further decomposed into subactions. Actions respond to events in the real world. The action Acquire that is part of the life cycle of the entity Book is triggered when a real-world event, the actual acquisition of a book, takes place. In the process structure diagram, actions show up as leaf nodes.

Events are communicated to the system through data messages, called attributes. In a procedural sense, these attributes constitute the parameters of the action. For the action Acquire, we may have such attributes as ISBN, date-of-acquisition, title and authors.

Entities have attributes as well: local variables that keep information from the past and collectively determine its state. The entity Book for example may retain some or all of the information that was provided upon acquisition (for example, ISBN, title). Entities also have two special attributes. First, the identifier attribute uniquely identifies the entity. Second, each entity has an attribute that indicates its status. This attribute can be viewed as a pointer to some leaf node of the process structure diagram.

Each entity can be viewed as a separate, long-running, process. In the library example, each book and each member has its own life cycle. The processes though are not completely independent. During the network stage, the system is modeled as a network of interconnected processes. This network is depicted in a system specification diagram (SSD). JSD has two basic mechanisms for interprocess communication:

Recall that the actions Borrow and Return occur in the life cycle of both Book and Member (see Figures 12.20 and 12.21). Such common actions create a link between these entities. As a consequence, the life cycles of these entities are synchronized with respect to these events.

If a member wants to borrow a book, certain information about that book is required. A Member entity may obtain that information by inspecting the state vector of the appropriate Book entity. This type of communication is indicated by the diamond in Figure 12.22. In an implementation, state vector communication is usually handled through database access.

Figure 12.22. State vector (SV) communication between Member and Book

If our system is to log information on books being borrowed, we may model this by means of a datastream from an entity Book to an entity Log. A datastream is handled on a FIFO basis; it behaves like the UNIX filter. The notation for the datastream type of communication is given in Figure 12.23.

The final stage of JSD is the implementation stage, in which the concurrent model that is the result of the network stage is transformed into an executable system. One of the key concepts for this stage is program inversion: the communication between processes is replaced by a procedure call, so that one process becomes a subordinate of another process. This is very similar to the notion of program inversion as present in JSP.

Figure 12.23. Datastream (DS) communication between Book and Log

The global process model of the method described in (Booch, 1994) is shown in Figure 12.28. It consists of four steps, to be carried out in roughly the order shown. The process is iterative, so each of the steps may have to be done more than once. The first cycles are analysis-oriented, while later ones are design-oriented. The blurring of activities in this process model is intentional. Analysis and design activities are assumed to be under opportunistic control. It is therefore not deemed realistic to prescribe a purely rational order for the activities to be carried out.

Figure 12.28. The process model of Booch (Source: G. Booch, Object-Oriented Analysis and Design, ©1994, Benjamin Cummings Publishing Company. Reproduced by permission of Addison Wesley Longman.)

The first step is aimed at identifying classes and objects. The purpose of this step is to establish the boundaries of the problem and to obtain a first decomposition. During analysis, the emphasis is on finding meaningful abstractions from the application domain. During design, objects from the solution domain may be added. The major outcome of this step is a data dictionary containing a precise description of the abstractions identified.

The second step is concerned with determining the behavior and attributes of each abstraction, and the distribution of responsibilities over components of the system. Attributes and desired behavior are identified by analyzing typical usage scenarios. As this process proceeds, responsibilities may be reallocated to get a more balanced design, or be able to reuse (scavenge) existing designs. The outcome of this step is a reasonably complete set of responsibilities and operations for each abstraction. The results are documented in the data dictionary and, at a later stage, in interface specifications for each abstraction. The semantics of usage scenarios are captured in sequence and communication diagrams (termed interaction diagrams and object diagrams, respectively, in (Booch, 1994)).

The third step is concerned with finding relationships between objects. During analysis, the emphasis is on finding relationships between abstractions. During design, tactical decisions about inheritance, instantiation, and so on are made. The results are shown in class diagrams, communication diagrams, and 'module diagrams', which show the modular structure of a system.

Finally, the abstractions are refined to a detailed level. A decision is made about the representation of each abstraction, algorithms are selected, and solution-oriented classes are added where needed.

The most notable characteristics of Booch's method are:

The Fusion method for object-oriented analysis and design has two major phases: analysis and design. Its global process model is shown in Figure 12.29.

The analysis phase is aimed at determining the system's objects and their interactions. The static structure is shown in a class diagram (called an object model in Fusion) and documented in a data dictionary. The dynamics are shown in the interface model. The interface model consists of a life cycle model for each object, denoted by a regular expression (i.e., a flat representation of a state machine diagram) and a specification of the semantics of each operation in a pre- and postcondition style. The analysis process is assumed to be an iterative process. This iteration stops when the models are complete and consistent.

Fusion's design phase results in four models, which are essentially derived in the order indicated in Figure 12.29. Object interaction graphs resemble communication graphs. They describe how objects interact at run time: what objects are involved in a computation and how they are combined to realize a given specification. Visibility graphs describe how the communications between objects are realized. For each object, it is determined which other objects must be referenced and how. Different kinds of references are distinguished, taking into account aspects such as the lifetime of the reference and whether references can be shared. Next, the object model, interaction graphs, and visibility graphs are used to derive a description of each class. The operations and the initial set of attributes for each object are established at this stage. Finally, the inheritance relations are decided upon and depicted in the inheritance graph, which is a class diagram. The class descriptions are then updated to reflect this inheritance structure.

Figure 12.29. The process model of Fusion

The most notable characteristics of Fusion are:

The Rational Unified Process (RUP) is a full process model; see also Section 3.3. RUP has a number of workflows, such as a requirements workflow, analysis and design workflow, and test workflow, and four phases: inception, elaboration, construction, and transition. Workflows describe the activities to be carried out, while the phases indicate the organization along the time axis. Most workflows extend over most phases.

Here, we discuss the analysis and design workflow, in which the requirements are transformed into a design. RUP is an iterative process, so this transformation is carried out in a number of iterations as well. The first iterations take place in the elaboration phase of RUP. In that phase, the architecture of the system is determined. The RUP way of doing architectural design reasonably fits the global workflow model discussed in Section 11.2. In subsequent iterations, concerning the lower-level design, the main activities are analyze behavior and design components.

The purpose of the analyze behavior step is to transform the use cases into a set of design elements that together serve as a model of the problem domain. It is about what the system is to deliver. It produces a black-box model of the solution. The purpose of the design elements step is to refine the definitions of the design elements into classes, relationships, interfaces, and so on. In this activity, the black-box, what model is turned into a white-box, how model.

During both activities, the design is reviewed and the results are fed back into the next iteration.

Notable characteristics of RUP are:

Quite a few attempts have been made to classify design methods along various dimensions, such as the products they deliver, the kind of representations used, or their level of formality. A simple but useful framework is proposed in (Blum, 1994). It has two dimensions: an orientation dimension and a model dimension.

In the orientation dimension, a distinction is made between problem-oriented techniques and product-oriented techniques. Problem-oriented techniques concentrate on producing a better understanding of the problem and its solution. Problem-oriented techniques are human-oriented. Their aim is to describe, communicate, and document decisions. Problem-oriented techniques usually have one foot in the requirements engineering domain. Conversely, product-oriented techniques focus on a correct transformation from a specification to an implementation. The second dimension relates to the products, i.e. models, that are the result of the design process. In this dimension, a distinction is made between conceptual models and formal models. Conceptual models are descriptive. They describe an external reality, the universe of discourse. Their appropriateness is established through validation. Formal models on the other hand are prescriptive. They prescribe the behavior of the system to be developed. Formal models can be verified.

Using this framework, we may classify a number of techniques discussed in this book as in Table 12.5. The four quadrants of this matrix have the following characteristics:

The above arguments relate to characteristics of the problem to be solved. There are several other environmental factors that may impact the choice of a particular design technique and, as a consequence, the resulting design (similar arguments hold for the software architecture; see Chapter 11):

The above quotes hint at some important questions still left unanswered in our discussion of object-oriented methods:

The goal of requirements engineering is to model relevant aspects of the real world, the world in which the application has to operate. Requirements engineering activities concern both capturing knowledge of this world and modeling it. The language and methods for doing so should be problem-oriented (domain-oriented). They should ease communication with users as well as validation of the requirements by users. Most object-oriented methods assume that the requirements have been established before the analysis starts. Of the four processes distinguished in Chapter 9 (elicitation, specification, validation, and negotiation), object-oriented methods by and large only cover the requirements specification subprocess. Though many object-oriented methods have incorporated use-case analysis, the purpose of it is primarily to model the functional behavior of the system rather than to elicit user requirements.

A rather common view of proponents of object orientation is that object-oriented analysis (OOA) and object-oriented design (OOD) are very much the same. OOD simply adds implementation-specific classes to the analysis model. This view, however, can be disputed. OOA should be problem-oriented; its goal is to increase our understanding of the problem. The purpose of design, whether object-oriented or otherwise, is to decide on the parts of a solution, their interaction, and the specification of each of these parts. This difference in scope places OOA and OOD at a different relative 'distance' from a problem and its solution, as shown in Figure 12.30.

Figure 12.30. The 'distance' between OOA, OOD and a problem and its solution

There are good reasons to distinguish OOA-type activities and OOD-type activities, as is done in Fusion, for example. During design, attention is focused on specifying how to create and destroy objects, on identifying generalizations (abstract, if necessary) of objects in order to promote reuse or maintainability, and so on. An object Publication as a generalization of Book and Journal need not be considered during analysis, since it does not increase our understanding of the domain. On the other hand, an object such as identification card may well disappear from the model during design.

Most software development organizations have accumulated a lot of experience in developing software following the traditional, function- or process-oriented style. A lot of legacy software has been developed and documented that way. As a consequence, knowledge of these methods is still required in many an organization.

Many organizations have switched to some kind of object-oriented analysis and design approach. Hard evidence of increased productivity or quality has not been determined, though. Several experiments have been done to test the effectiveness of the object-oriented paradigm, and the results do seem to indicate some deeper problems. For example, in one experiment it was tested how effective object-oriented models are as the main vehicle of communication between the typical customer and the developer (Moynihan, 1996). It was found that the traditional, functional models were easier to understand, provoked more questions and comments, gave a more holistic understanding of the business, and better helped to evaluate likely implementations. In another experiment, it was tested whether novice analysts are able to develop requirements more easily with certain methods than with others, and whether they learn to use certain methods more readily than others (Vessey and Conger, 1994). Again, the results were negative for object orientation: novice analysts were better able to apply the process-oriented method and significant learning only occurred for the process-oriented method.

In a similar vein, Arisholm and Sjøberg (2004) found that novice users have fewer problems maintaining systems that have centralized control compared to systems having delegated control. In a centralized control style, one or a few large classes are in control. These large classes coordinate the work of a lot of smaller classes. This resembles the hierarchical main-program-with-subroutines architectural style. In a delegated style, responsibilities are distributed over a larger set of classes. Proponents of object orientation usually advocate a delegated control style. It seems one needs a certain maturity to be effective with this style.

The inheritance mechanism of object orientation needs to be handled with care too, as noted in Section 12.1.6. Deep hierarchies require one to comprehend design or implementation units that may be far apart. Such designs tend to be error prone (Bieman et al., 2001) and more difficult to inspect (Dunsmore et al., 2002), because of the delocalized nature of information in them.

There may well be some truth in the observation that users do not think in objects; they think in tasks. From that point of view, use-case analysis may be seen as one way to introduce a functional view into an otherwise object-oriented approach.