Metaphors

Kent Beck is one of the most influential people in modern software engineering. He is the father of the eXtreme Programming methodology, the CRC cards and the first one to envision the use of software patterns (see section 1.3.6). One of the fundamental issues in XP is the importance of using metaphors.

In [Beck, 2002] the author informally defines the idea of a metaphor as well as a set of concepts that are related to them. For the purpose of this discussion it it interesting to take a look at some of them:

• Metonymy is to refer to a whole by a part
• A simile is an explicit comparison
• An analogy is an explicit comparison where the parts are connected
• And a metaphor is the linking two sets of concepts; The understanding itself of one set of concepts in terms of another

A metaphor is made of a source, a target and a mapping. According to Beck, what makes metaphors useful is ``the game of is/is not'', which helps thinking about the problem and understanding it. A metaphor is best understood if it is based in a ``ground metaphor'', that is it has a physical experience basis.

Metaphors are constantly used in software design. Icons, for instance, in a graphical user interface are based on metaphors (the pencil, the paint bucket or the sand clock). But is probably in the XP community where this concept has become especially important. A key point to the XP methodology is what they call System Metaphor which is a simple shared story of how the system works[Beck, 1999]. That is a story that everyone - costumers, programmers, a nd managers - can tell about how the system works. A proper system metaphor supports four basic aspects of system building: common vision, shared vocabulary, generativity and architecture. It is also sometimes seen as a valid substitution for what in most methodologies is called the system architecture [West, 2002].

Some authors go even beyond this use of metaphor and claim that in object-oriented design a program is a metaphor of the real world [Noble et al., 2002]. The authors argue that the objects used in the object-oriented program are not the same kind as real-world objects. Objects in the design are not ``abstractions'' of the real-world objects because real objects are not instances of the software ones, rather the relationship between software objects and external objects can be seen as a ``metaphor''.

But how does this concept relate to the ones previously introduced? It is our opinion that the use of the metaphor concept in software engineering is misleading. Most of the times when talking about a system metaphor what we are actually doing is to describe a model. Let us remember that a model does not need to either be formal or to completely describe a system under study and the correctness of a model is only measured in relation to how well it accomplishes its purpose. The purpose of a conceptual model can be, as already commented in section 1.2.2, to communicate ideas. This is basically the same idea as the system metaphor.

The only problem with using the metaphor as a driving force throughout the development is that it promotes the idea that the system is static in two ways. First, a real metaphor is usually difficult to find but even more difficult to change once adopted. Conceptual changes introduced later in the development may contradict one of the underlying ideas in the metaphor. Although the metaphor can then be updated, chances are that it will then become misleading. On the other hand, if we think on models we think on a continuous of different models that evolve from the most abstract and conceptual one we may have in the very initial phases to the executable model or code itself. This idea of the model being able to describe the system at different levels of abstraction is also lost when using the system metaphor paradigm.