Peter Rittgen
University College Borås, 501 90 Borås, Email: peter.rittgen@hb.se
Introduction
Metaphors are powerful cognitive instruments that help us in making sense of the world around us. We start using them already as very small children and they accompany us throughout our lives. Some authors go as far as claiming that all knowledge is metaphorical (Indurkhya 1994). But even if we do not subscribe to that position we cannot but admit that metaphors are an important cornerstone of human creativity (Seitz 1997). It therefore stands to reason that they might be useful in highly creative undertakings such as the development of information systems. The latter activity in par-ticular is fraught with a principal problem: Most stakeholders in the system are not knowledgeable in system design and they find it very difficult – if not impossible – to envision a system that does not yet exist. It is not there to look at or to play with and in early stages there is not even a rudimen-tary prototype that could be studied. To imagine how a future system might look like, what functions it will have and how it will support and shape my daily work is well beyond the powers of most potential users of such a system. In this context a metaphor can be a powerful device for building a bridge from the known to the unknown. It draws on ideas that people are familiar with from their everyday experience.
A simple example of a metaphor is that of a CD player. Most people have experience in operating a hardware player so that its design can be used as a template for that of the software player. The user interface of the latter will thus include images of the knobs, slides, dials, buttons, lamps, displays and all other devices found on a hardware player and the user will be able to operate it in a very similar way. This facilitates the use of the software player and a user manual is hardly required.
But the use of metaphors is not always as straightforward as that. In the case of more sophisticated information systems it can be hard to find a suitable metaphor and even harder to translate it into the system design. A common approach to facilitating the design of information systems is that
of design patterns. A design pattern is a very general model of a system’s architecture. It does not specify the design down to the smallest detail but only outlines the basic structure. It can be seen as a reusable solution to a commonly occuring problem. An example of such a design pattern is the Model-View-Controller architecture (MVC). The model component con-tains the business logic and data of the application. Views that are regis-tered to the model can access its data and present it to the user in a suitable form. The controller component accepts user input and triggers the corre-sponding functions in the model. The model notifies the views of resul ting changes in the data, which in turn update their displays accordingly. This architecture provides for a separation of concerns: The model is freed from dealing with the user interface and can instead focus on the functionality of the application domain.
Design patterns are typically not based on experiences from everyday life of users. They are often abstract and technology-oriented and do not appeal to intuition or common sense. That makes them unsuitable as a plat-form for communication between inplat-formation system stakeholders. There metaphors perform better. But design patterns do have a place in system design where they make a valuable contribution to well-structured, reus-able and less error-prone software. It is therefore worthwhile to investigate the question of how a metaphor can be translated into a design pattern in order to lower the communicative barriers between the stakeholders and to allow them to join in the co-design of “their” system. To this end we first introduce the Bunge-Wand-Weber ontology that is used to anchor both the metaphor language and the design pattern language; this facilitates the translation between the two languages. We then address the fundamental concepts of metaphors and design patterns and the respective languages. We proceed by specifying a translation based on structure-mapping theory and providing an example that employs the metaphor of the labour market to develop the architecture of an eService system.
Bunge-Wand-Weber Ontology
The Bunge-Wand-Weber ontology (BWW ontology) is an established tool for analyzing modeling languages. It is based on Mario Bunge’s ontology (Bunge 1977, Bunge 1979) and was later adapted by Yair Wand and Ron Weber to the information systems field (Wand and Weber 1989, Wand and Weber 1995, Weber 1997). According to this ontology the world consists of things that possess properties. Both of them exist irrespective of the human observer. The observer can only witness attributes that he takes for the properties of the things he observes. The things themselves are not ob-servable. In the BWW ontology an attribute is represented by a property
function over time that maps onto a property co-domain containing the possible property values. An intrinsic property belongs to an individual thing, a mutual property to two or more things. A whole-part relation is a property of an aggregate thing and a component thing. A resultant prop-erty of an aggregate is derived from the components, an emergent propprop-erty of an aggregate not (i.e. it is new). A complex property is made up of other properties. A class consists exactly of the things that share a set of charac-teristic properties. A natural kind is a class where all the characcharac-teristic properties are laws. “Laws reflect either natural or artificial constraints im-posed upon things.” (Wand and Weber 1990)
In the following sections we will use that ontology to anchor both the metaphor language and the design pattern language which facilitates the mapping between them.
Metaphors
A metaphor is a figure of speech that involves a transfer of meaning be-tween seemingly unrelated terms. It has its origins in the rhetoric of an-cient Greece where it was used to make a talk more interesting and easier to follow. When we say “The customer is king” we do not mean it literally. It is a metaphor that attributes to a customer many of the qualities that we typically associate with a king: influence, importance, power and so on. A metaphor can transfer complex meaning such as in that of a nation as “a ship of state” where the captain of the ship represents the government, the sea the flow of time, bad weather a crisis, lack of wind economic stagna-tion etc. An example of an informastagna-tion system metaphor is that of the desktop in windows environments. Metaphors are used in many disciplines such as organizational theory (Morgan 1997), architecture (Alexander et al. 1977), software development (Beck 2000), economics (McCloskey 1998) and information systems (Carroll et al. 1988, Gazendam 1999, Wal-sham 1991, Madsen 1994, Coyne 1995).
Fig. 1. Metaphor – concept and example
According to cognitive linguistics (Lakoff and Johnson 1980) a metaphor connects two conceptual spaces: the source (also called secondary system or vehicle) and the target (also called primary system or topic). The con-nection takes on the form of a mapping from source to target (see figure 1). As an example we might use the commonly known labour market with employers, job seekers, job announcements, applications etc. to explain the architecture of a yet-to-be-built eService market with eService providers, eService clients, eService offers, eService requests and so on.
The Metaphor Language (ML) is used to express the vehicle with which we anchor the metaphor in the stakeholders’ imagination (as well as the target). For this reason it must be a very simple language that closely re-sembles our “natural” or “intuitive” way of conceptualizing the world around us. A common and very basic approach is to view the world as a number of things that are related in some way. In the different modeling languages these things are called classes, objects, entities and so on. They can be on the instance or type level, i.e. they refer to individual things or sets of things, respectively. Likewise the relations between things can be termed links, associations, relations etc. Again we distinguish between type and instance level. For the Metaphor Language we make use of this rudimentary conceptualization: A metaphor model consists of entity types and transfer types. Entity types are sets of concrete things sharing common properties. Transfer types are ternary relation types where an entity of the second type is transfered from one of the first to one of the third. The first or third entity type must be active, i.e. its entities must be able to perform activities. These entities could be human beings, software artifacts or or-ganizations. Using ternary relation types is a simple way of introducing a dynamic element into the language without encumbering it with additional constructs. An example of a transfer is an employer who makes a job offer to a job seeker (shown in figure 2, on the type level). Often transfer types can be compared to simple communicative transactions but they can also describe material acts.
Table 1. BWW ontology of the Metaphor Language (ML)
ML construct BWW construct
ML-entity type BWW-natural kind of things
ML-active entity type BWW-natural kind of things that act on other things ML-transfer type BWW-characteristic mutual property of 3 things +
BWW-transformation
Figure 2 shows how the source of the labour market metaphor might look like. Job seekers register at the placement service by giving information on themselves and their qualifications. Employers hand in a description of each vacancy. It consists of a list of required qualifications. The placement service then compares required and provided qualifications and sends the employers the available information about matching candidates. Based on that employers can then decide to make a job offer which the job seeker in turn can accept or decline.
Fig. 2. The labour market metaphor (source)
Design Patterns
The design patterns used in the development of object-oriented software were introduced by Gamma et al. (1995). They have been influenced strongly by Alexander’s architectural design patterns where each pattern is defined as a three-part rule, which expresses a relation between a certain context, a problem, and a solution (Alexander 1979). The context describes the conditions under which the pattern can be applied. The problem is a
“system of forces” that the solution is supposed to balance. This definition is used in a slightly rephrased form also in software engineering: A design pattern is a solution to a recurring problem in a certain context. According to Trætteberg (2000) it involves:
1. a description of a problem and a possible solution, 2. examples of usages of the solution in actual designs, 3. reasons for why the solution actually solves the problem,
4. criteria for when to use and when to avoid this particular solution and 5. relations to other design patterns.
In object-oriented design the solution is often described as a class diagram that can be accompanied by some interaction diagram. Sometimes the term design pattern is used to refer to the solution alone.
Fig. 3. The observer design pattern (class diagram)
An example of the (solution part of a) design pattern is given in figure 3. It addresses the problem of maintaining consistency between related objects: How can we make sure that dependants are updated when the state of the object they depend on is changed? Such a situation arises when we have multiple views on the same data, e.g. a pie and a bar chart representing the same numerical data. If the numbers change we want to make sure that the respective views are updated accordingly. The solution that the observer pattern offers involves an Observer and a Subject class. These classes are abstract, i.e. they have no instances. Instead they are specialized into Con-creteObserver and ConcreteSubject. Each dependant is an instance of the former, the object they depend on is an instance of the latter. An observer can register at a subject by sending it an attach message. All registered ob-servers will be notified by the subject whenever its state changes. This is done by the notify operation that sends an update message to all attached
observers which in turn send a getState message to the subject to find out about the new state.
We use the Unified Modeling Language (UML, OMG 2003) to express the solution part of design patterns, in particular the class and sequence diagrams of UML. Ontological evaluations of the UML based on BWW have been done by Evermann and Wand (2001) and Opdahl and Hender-son-Sellers (2002). Table 2 lists the relevant constructs and their BWW equivalents according to Opdahl and Henderson-Sellers (2004).
Table 2. BWW ontology of some UML constructs
UML construct BWW construct
UML-class BWW-natural kind of things
UML-active class BWW-natural kind of things that act on other things UML-attribute [of
a class]
BWW-characteristic intrinsic property [that defines a natural kind and] that is not a law or a whole-part relation, but can be either resultant or emergent
UML-object BWW-thing UML-property [of
an object]
BWW-intrinsic property [of a thing] that is not a law or a whole-part relation, but can be either resultant or emergent BWW-intrinsic complex property (if the UML-property has a non-primitive type)
UML-association BWW-characteristic mutual property
UML-multiplicity characteristic state law about how many BWW-properties that a thing can possess
UML-object life-line
BWW-segment of a history UML-messsage BWW-binding mutual property UML-operation BWW-transformation
Translating Metaphors into Design Patterns
The translation of metaphors into design patterns is based on structure-mapping theory. It has originally been developed to describe the nature of analogies (Gentner 1983) but has later been adapted to metaphors (Gen tner et al. 1988). The central assumption of structure -mapping theory is that the likeness between the source and target domains of analogies or metaphors is not so much in the properties of the objects of each domain themselves but rather in the relations between them. In our example of the labour and eService markets an employer and an eService client have litt le in common but the relation between an employer and a job seeker on the one hand, and an eService client and an eService provider on the other hand is close: in
both cases the second offers a service to the first. In structure-mapping we define interpretation rules that map knowledge about a source domain into a target domain by relying on the syntactic properties of the knowledge domain alone and not on the specific content of the d omains.
The translation proceeds in two steps: metaphorical mapping and d esign mapping. In metaphorical mapping the terms of the source domain are translated into the corresponding terms of the target domain. In this step the structure of the source is largely conserved. The result is a model that is still expressed in ML but now refers to the target. It is therefore called the metaphor target model. The metaphorical mapping can be su pported by a translation table that shows how source and target terms are related. In table 3 some of the labour market terms are translated into their eService market equivalents. The resulting metaphor target model is shown in figure 4.
Table 3. Translation of some of the labour market terms
Source term Target term Employer eService client Job seeker eService provider Placement service eService broker Vacancy eService request
The second step, design mapping, translates the metaphor target model into the design pattern. The design pattern language is UML. As this step involves a mapping between different languages (i.e from ML to UML) it is more complex than metaphorical mapping. The ontological analysis of the two languages reveals that the constructs of the ML should be trans-lated into UML as shown in table 4.
Fig. 4. Metaphor target model of the eService market
Table 4. Mapping ML constructs onto UML
ML construct UML construct
ML-entity type UML-class
ML-active entity type UML-active class
ML-transfer type UML-association (ternary) + UML-operation (message)
The mapping from ML to UML is not surjective (i.e. it does not cover all UML constructs) even if we restrict the UML to the subset of constructs that are required for class and sequence diagrams. This means that we have to supply additional information which is not present in the metaphor when we want to create the design pattern. In particular we need to provide the time order of messages, attributes of classes, multiplicities and objects for the sequence diagram. Figures 5 and 6 show the result of this step, the class and sequence diagrams, respectively.
Fig. 5. The class diagram of the eService pattern
Fig. 6. The sequence diagram of the eService pattern
Conclusion
Developing an information system is a very complex task that requires the active collaboration of a substantial number of people, called stakeholders, if the system is to be successful. These people have to understand each
other (i.e. to speak the same language) and they have to agree on some common design for the system. This process is called co-design (Liu et al. 2002, Forsgren 1991). To really facilitate mutual understanding the com-mon language we use must reflect the hetorogenity of the stakeholders’ cultures, i.e. it must not be derived from any particular culture such as that of systems engineering. UML, for example, is not a suitable language for this task. But metaphors, on the other hand, provide the required features because they resort to knowledge that is rooted in common sense and therefore shared by everybody. We have introduced a simple language for expressing metaphors and suggested a way to translate them into patterns that can be used for system design. Finding a suitable metaphor is still a creative act (or maybe a stroke of genius) that can hardly be supported in a systematic way. But once it has been found we can provide some help in performing the ensuing steps.
References
Alexander C, Ishikawa S, Silverstein M with Jacobson M, Fiksdahl-King I and Angel S (1977) A pattern language: towns, buildings, construction. Oxford University Press, New York
Alexander C (1979) The Timeless Way of Building, Oxford University Press, New York
Beck K (2000) Extreme Programming explained. Addison-Wesley Longman, Reading, MA
Bunge M (1977) Ontology I: The Furniture of the World. Dordrecht, H olland. Bunge M (1979) Ontology II: A World of Systems. Dordrecht, Holland.
Carroll JM, Mack RL and Kellogg WA (1988). Interface Metaphors and User I n-terface Design. In: Helander M (ed) Handbook of Human-Computer Interac-tion. Elsevier Science Publishers, Amsterdam, The Netherlands, pp 67-85 Coyne R (1995) Designing Information Technology in the Postmodern Age: From
Method to Metaphor. The MIT Press, Cambridge, MA
Evermann J and Wand Y (2001) Towards Ontologically Based Semantics for UML Constructs. In: Kunii HS, Jajodia S, Sølvberg A (eds) Conceptual Mod-eling - ER 2001 - 20th International Conference on Conceptual ModMod-eling, Yokohama, Japan, November 27-30, 2001, Proceedings. Springer, Berlin, pp 354-367
Forsgren O (1991) Co-constructive computer applications: Core ideas and some complementary strategies in the development of a humanistic computer sci-ence. In: Bazewicz M (ed) Information systems architecture and technologies - ISAT' 91. Politechnika Wroclawska, Wroclaw, pp 45-53
Gamma E, Helm R, Johnson R and Vlissides J (1995) Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA Gazendam HWM (1999) Information System Metaphors. Journal of Management
Gentner D (1983) Structure mapping: A theoretical framework for analogy. Cog-nitive Science 7(2), 155-170
Gentner D, Falkenhainer B and Skorstad J (1988) Viewing metaphor as analogy: The Good, The Bad and The Ugly. In: Helma DH (ed) Analogical Reasoning: Perspectives of Artificial Intelligence, Cognitive Science and Philosophy. Kluwer, Dordrecht, The Netherlands, pp 171-177
Indurkhya B (1994) The Thesis That All Knowledge Is Metaphorical and Mean-ings of Metaphor. Metaphor and Symbolic Activity, 9(1), 61-63
Lakoff G and Johnson M (1980) Metaphors we live by. The University of Chicago Press, Chicago
Liu K, Sun L and Bennett K (2002) Co-Design of Business and IT Systems. In-formation Systems Frontiers 4(3), 251-256
Madsen KH (1994) A Guide to Metaphorical Design. Communications of the ACM 37(12), 57-62
McCloskey DN (1998) The Rhetoric of Economics. University of Wisconsin Press, Madison, WI
Morgan G (1997) Images of Organisation. 2nd
ed. Sage, Beverly Hills.
OMG (2003) Unified Modeling Language Specification: Version 1.5. Object Management Group, Needham, MA, USA. Online version available at http://www.omg.org/docs/formal/03-03-01.pdf
Opdahl AL and Henderson-Sellers B (2002) Ontological Evaluation of the UML Using the Bunge-Wand-Weber Model. Software and Systems Modeling 1(1), 43-67
Opdahl AL and Henderson-Sellers B (2004) A Template for Defining Enterprise Modeling Constructs. Journal of Database Management 15(2), 39-73 Seitz JA (1997) The development of metaphoric understanding: Implications for a
theory of creativity. Creativity Research Journal, 10(4), 347-353
Trætteberg H (2000) Model based design patterns. Position paper, Workshop on User Interface Design Patterns, CHI’2000, The Netherlands.
Walsham G (1991) Organizational metaphors and information systems research. European Journal of Information Systems 1(2), 83-94
Wand Y and Weber R (1989) An Ontological Evaluation of Systems Analysis and Design Methods. In: Falkenberg ED, Lindgreen P (eds) Information Systems Concepts: An In-Depth Analysis. North-Holland, pp 79-107
Wand Y and Weber R (1990) An Ontological Model of an Information System. IEEE Transactions on Software Engineering 16(11), 1282-1292
Wand Y and Weber R (1995) On the deep structure of information systems. In-formation Systems Journal 5, 203-223
