‘The Use of Pattems in Information System Engineering (HS _IDA-MD-01-001) Per Backlund (per.backlund @ida.his.se) Supervisor Benkt WanglerSubmitted by Per Backlund to the University of Sk6vde as a dissertation towards the degree of M.Sc. by examination and dissertation in the Department of Computer Science. 2001-05-29 certify that all material in this dissertation which is not my own work has been identified and that no material is included for which a degree has already been conferred upon me.‘The Use of Patterns in Information System Engineering Per Backlund (per.backlund @ida.his.se) Keywords: pattems, information system, information system development, analysis, patterns, organisational pattems, design pattems, deontic pattem, workflow patterns, process pattems, business patterns, classification. Abstract ‘The aims of this dissertation are to investigate the use and usefulness of pattems in Information Systems Engineering and to identify future areas of research, In order to. do this there is a need to survey different types of pattems and find a common concept of patterns. A pattern is based on experience found in the real world. A text or a model or a combination of the both can describe the pattem, A pattem is typically described in terms of context, forves, problem, and solution. These can be explicitly expressed or implicitly found in the description of the pattern. ‘The types of pattems dealt with are: object-oriented pattems; design pattems, analysis patterns; data model pattems; domain pattems; business patterns; workflow patterns and the deontic pattem. The different types of patterns are presented using the authors’ own terminology. “The pattems described in the survey are classified with respect to different aspects. The intention of this analysis is to forma taxonomy for pattems and to bring order into the vast amount of patterns. This is an important step in order to find out how pattems are used and can be used in Information Systems Engineering, The aspects used in the classification are: level of abstraction; text or model emphasis; product or process emphasis; life cycle stage usage and combinations of these aspects. Finally an outline for future areas of research is presented. The areas that have been considered of interest are: pattems and Information Systems Engineering methods; Patterns and tools (tool support for patterns); pattems as a pedagogical aid; the extraction and documentation of pattems and patterns and novel applications of information technology. Each future area of research is sketched out.Contents 1 INTRODUCTION. 1.1 AmMS AND OBIECTIVES.. 1.2 WAYOF WORKING. 1.3 THE OUTLINE OF THIS DISSERTATION. 2 PATTERNS. 2.1 MOTIVES FOR USING PATTERN: 2.2 PATTERN LANGUAGE. 3. EXAMPLES OF PATTERNS -mminmnomsonnannmnnennnnnmnonnnnnmmns LL 3.1 COAD’s AND LARMANS’ OBJECT-ORIENTED PATTERNS.. 3.2. DESIGN PATTERNS ACCORDING TOGAMMA ET AL. 3.21 Other Examples of Design Pattern 3.3. COPLIEN’S ORGANISATIONAL PATTERNS i 4 16 3.4 Hay’s DATA MODEL PATTERNS.. 3.5 FOWLERS” ANALYSIS PATTERNS.. 3.6 ELEKTRA PATTERNS. 3.7 AMBLERS’ PROCESS PATTERNS: 3.8 _ ERIKSSON'S AND PENKER’S BUSINESS PATTERNS. 3.9 WOHED’S DEONTIC PATTERN ., 3.10 WORKFLOW PATTERNS ACCORDING TO KIEPUSZEWSKIET AL. 3.1L RELATIONSHIPS BETWEEN PATTERNS. 4 A CLASSIFICATION OF PATTERNS, 4.1 TOWARDS A COMMON CONCEPT OF PATTERNS.. 4.1.1 Classification with Respect to the Level of Abstraction. 412 Classification with Respect to Text or Model Emphasis. 4.13 Classification with Respect to Product/Process 4.14 — Classification with Respect to the Life cycle Stages: 4.2. COMBINING DIFFERENT APPROACHES OF CLASSIFICATION. 4.2.1 Natural Language/Models and Product/Process. I4.22 Natural Language/Model and Life cycle Perspective. 4.23 Productiprocess and Life cycle Stage: 5 DISCUSSION .1n-essmevevnessemereeneccemerernecsemeneeenssemeeemecsemnnmessemmeeemescemessssnees SD wn ADVANTAGES AND DISADVANTAGES OF PATTERNS. a .2 EVALUATION OF THE WAY OF WORKING. .3 POSSIBLE FUTURE WORK. 5.3.1 Patterns and ISE methods 5.32 Tool Support for Patterns. 5.33 Extracting, Documenting, and Representing Panterns. 5.4 CONCLUDING REMARKS, nw REFERENCES. APPENDIX A 74 APPENDIX B ssesenseesnetormeeenesenestsnsstemnerimeenmernmenemtssenenetmantemnerimernmersemesneer APPENDIX C sessonseesmetonmeeentsnenesssmsstemetimeeemernmenemtssenesetmantemaerimernmersemesneer SO,Introduction 1 Introduction Computerised information systems (IS) have become a crucial part of most businesses today. The term IS is defined as a computerised system that conveys information between people over time and space. The IS is used to collect, store, manipulate, and. present information. Information systems have to be developed and then maintained throughout the entire life cycle, This process is referred to as Information Systems Engineering (SE). ISE requires many different competences, such as knowledge of: mathematics, logics, computer science, cognitive science, and economics. All these competencies are needed in order to construct, introduce, and maintain an information system. The life cycle of a system can (roughly) be described in the following terms (Alter, 1999): * Initiation ~ This is the process of defining the need of change in an existing system, * Development ~The development process consists of acquiring and configuring the hardware, software, and other resources necessary to implement the IS. © Implementation ~ This process aims to make the IS operational in the organisation. © Operation and maintenance — This phase is the ongoing operation of the IS. Operation and maintenance require that someone see to it that the system. operates according to the needs of the organisation, There is also a matter of ‘managing the changes that new demands from the organisation impose on the IS. The object-oriented community adopted the notion of pattems from the architect, Christopher Alexander in the beginning of the 1990's. Since then the use of pattems has spread to comprise, for example, software design and architecture, analysis, data modelling, and organisational issues. The concept of patterns has been adopted and used in many different ways in these diverse areas, There is, however, no common definition of what a pattem is and how it should be applied. There is a need to identify theIntroduction common features among, as well as the differences between, the different types of patterns in order to create a taxonomy! of pattems, ‘The concept of pattems has been used in many different areas, from software design to organisational issues, which span over the entire life cycle of an IS. However there is no Compilation of how pattems relate to the life cycle of an IS and in what ways they can the ISE process froma life cycle perspective. Furthermore, there is a need to investigate different types of pattems and discuss how they are related to each other in orckr to get an overview of the subject. 1.1 Aims and Objectives ‘The aim of this work is to survey and discuss the potential use and usefulness of patterns in information systems engineering throughout the whole life cycle. The work will provide a set of examples of such pattems and discuss how they may be used. It will also identify desirable propetties of pattems and suggest and discuss different classification schemes for patterns. The objectives to achieve this aim are: © To conduct an extensive literature survey in order to find out what has been written on the topic and compile some of that material, thereby giving a background that describes different perspectives of the problem area; * To define the concept of pattems and give an account of different types of patterns; © To outline a classification of patterns in order to be able to relate different types of pattems to each other; * Torelate the different types of pattems to the phases of the information systems life cycle. * To discuss how pattems may be used in ISE in the various phases of the IS life cycle. The discussion will be based on the classification of pattems mentioned above; "Taxonomy in the sense of a hierarchical structuring of knowledge about objects/concepts by subcategotising them according to some relevant qualities 2Introduction © To identify problem areas for future research, Since this dissertation is a research proposal the task of defining a possible future area of research is of great importance. 1.2 Way of Working This research proposal is of an explorative nature the intention is to use an inductive approach. This means that information will be extracted from various sources in order to gain knowledge about different types of pattems and thus proceed from specific facts toa general conclusion, ‘The work will begin with a study of literature. A study of literature is necessary since the amount of relevant material concerning pattems and information systems is extensive, There are a number of books that will contribute to an essential understanding of the subject of this dissertation, Research reports and articles will promote the understanding of the latest findings. Since some attention will be paid to novel areas the Intemet may be a useful source. It has been argued that the Intemet is an unreliable source of information. However it is possible to find relevant material and verify its reliability. In order to account for different types of pattems and classify those, it is important to make a thorough analysis of the material found in the survey of literature. This analysis will make the foundation for the discussion about the roles that patterns can play in different phases of the IS life cycle. ‘The analysis will be based on various schemes of classification that will be used to describe pattems fiom different views. ‘Since one of the objectives is to identify problems for further studies it is essential to explore potential areas of research. Describing these areas from different perspectives can be a means of doing this. 1.3 The Outline of This Dissertation In chapter 2a brief history of the concept of patterns is given in orckr to present a background for the concept. There is also a discussion on the motives for using pattems as well as a discussion about the concept of pattem language.Introduction Chapter 3 consists of presentations of different types of pattems found in the literature, ‘The different patterns are presented using the authors’ own teminology. In chapter 4 a common definition of the concept of pattems is presented. This definition is based on the results of the survey presented in chapter 3. Furthermore, the different types of pattems identified in the survey are classified according to different classification schemes, which focus on various aspects of the concept of pattems. Chapter 5 consists of a discussion and an evaluation of the way of working. The conclusions and future work are presented in the form of five possible research areas, “These areas are briefly described and a short outline for future work within each area is presented.Patterns 2 Patterns Christopher Alexander (Alexander et al, 1977) defines a pattern as a description of a problem, which occurs over and over again in our environment paired with a core solution to that problem, It is a core solution in the sense that it can be used a great number of times without ever doing things in the same way twice, Gamma et al. (1995) use Alexander's definition and claim that even though Alexander was talking about buildings and towns his discussion about pattems is true about object-oriented design patterns as well. Other authors (Coplien and Schmidt, 1995; Fowler, 1997; Rising, 2000; ELEKTRA, 1998b) have also adopted Alexander's ideas about patterns. According to Appleton (1997) a pattem is “the abstraction from a concrete form, which keeps recurring, in specific non-arbitrary contexts.” Appleton (1997) also states that a pattern is geared toward solving problems in design. A pattern is a description of a common problem and its solution written in a way so that other may leam fiom it and make use of it in similar situations (Appleton, 1997). According to Appleton (1997) a good pattem is characterised by the following: * It solves a problem: Pattems capture solutions, not just abstract principles or strategies. * Itis.a proven concept: Pattems capture solutions that are proved to work, * The solution isn’t obvious: The best pattems generate a solution toa problem indirectly. © It describes a relationship: Pattems don’t just describe how things should be done, but describe deeper system structures and mechanisms, A pattem is described as a solution to a problem ina given context. The patterns described by Appleton (1997), Coplien & Schmidt (1995) and Rising (2000) have the following parts in common: Name, problem, context, forces, solution, and resulting, context. In addition to these parts Appleton (1997) and Coplien & Schmidt (1995) describe the rationale of the pattern, Appleton (1997) also ads an example to illustrate how the pattem can be used as well asa description of related pattems and known uses. ‘The name of the pattem should be meaningful and descriptive in order to make it easy to refer to it and make discussions at a higher level of abstraction possible (Coplien & 5Patterns Schmidt, 1995; Rising, 2000; Appleton, 1997). By naming patterns in an expressive ‘way it is possible to improve communication. The problem should be clearly stated in order to describe the intent of the pattem (Coplien & Schmidt, 1995; Rising, 2000; Appleton, 1997), The context explains where the problem is founds it should explain the preconditions under which the solution seems to recur (Coplien & Schmidt, 1995; Rising, 2000; Appleton, 1997). The forces describe why the actual problem is hard to solve. They describe the factors that interact/conflict with one another and with the goals to be achieved (Coplien & Schmidt, 1995; Rising, 2000; Appleton, 1997). The solution states how the desired outcome should be achieved. This is not done by means of providing an implementation, but rather by describing the essence of the components and their relationships and responsibilities. This is due to the fact that the pattern should be possible to use over and over (Coplien & Schmidt, 1995; Rising, 2000; Appleton, 1997), Finally the resulting context gives a description of the state of the world when the pattem has been applied. The resulting context should not only say that the problem has been solved; it should include the consequences of applying the pattem, as well as problems and pattems that may arise from the new context (Coplien & Schmidt, 1995; Rising, 2000; Appleton, 1997). The rationale of a pattem gives an explanation of the rules in the pattem. The rationale can be said to establish the pattem in reality and in the context of other pattern languages (Coplien & Schmidt, 1995; Appleton, 1997). Gamma. et al. (1995) offer a similar definition of what elements a pattem should contain. They identify name, problem, solution, and consequences as the most essential parts of a pattern, Other authors, e.g. Dewar et al. (1999) discuss the problem of knowing how trustworthy and firmly established a patter is. There is a concem about whether a pattem should only mediate uncontroversial knowledge or if it may include new technique. Dewar et al, (1999) claim that since developers have different background knowledge and interests, a pattem description should include a status section ‘describing the confidence which may be placed in the pattern” (Dewar et al., 1999, p8), The idea of Providing a status section to describe the degree of faith one can put in a pattem originates fiom Alexander et al. (1977). Gamma et al. (1995) consider this problem in the sense that the design pattems do not describe any “new or unverified designs” (Gamma et al., 1995, page2).Patterns 2.1 Motives for using Patterns Since software development and information systems development is becoming more and more complex there is an emerging need for reuse of prior knowledge. Pattems have been proposed as a way of transmitting knowledge in order not to reinvent the wheel. A number of authors (Rising, 2000; Dewar et al., 1999) claim that using pattems: is a way to reuse expertise. Furthermore, pattems can appear across domains (Rising, 2000), i. it is possible to transfer knowledge between different domains (Fowler, 1997) in order to leam from the efforts of others. Dewar et al. (1999) argue that pattems should not be considered as being a methodology; they are rather complements to methodologies. Since a pattem has a limited scope (Dewar et al., 1999), being a solution toa problem ina certain context, it cannot be a methodology. Several authors (Fowler, 1997; Coplien & Schmidt, 1995; Ambler, 1998a; Rising, 2000; ELEKTRA, 19988), share the notion that one of the most important motives for using patterns is to transfer knowledge, both within a domain and between different domains. Although they describe different types of pattems this motif is common to their approaches. Gamma et al, (1995) deal with design patterns. The aim is to record experience about successful object-oriented software designs and make them more accessible to other developers, ie. reusability is an important advantage of using design patterns, Coad (1992, page 158) defines a pattem as “a fully realized form original, or model accepted or proposed for imitation.” This definition gives at hand that reuse is an important motive for using pattems. Pattems can become building blocks for design and construction, Larman (1998) discusses the need to follow a development process. The recompense of an iterative, incremental, use case driven process with an early emphasis on architecture is described. What are the advantages of using pattems in this process? Larman (1998) describes a number of uses of pattems in the development process from the early phases of analysis to patterns for persistent objects, which are used in the coding phase of a project. Ambler (19986) also deals with the development process, The Process patterns described are descriptions of how a suacessful object-oriented development process should be designed. The different phases in the process are described, at different levelsPatterns of detail, in order to convey knowledge and experiences about the object-oriented development process, ‘Wohed (2000a) argues that the main purpose of using (conceptual) pattems is to reduce the cost for the design and implementation of information systems. The idea of reuse is also an important part of object orientation and component-based development, However, Wohed (2000a) argues, the concept of pattem is not commonly used in the in the initial phases of information systems engineering, Partly this fact is due to the lack of standardised patterns collected in libraries. Another problem may be rooted in the high level of abstraction, which is quite commonly found in pattems. ‘The aspect of reuse in various settings and at different levels of granularity is found in the work of a number of authors, e.g, (Eriksson and Penker, 2000; Rising, 2000; Robertson and Stunch, 1993). Allen & Frost (1998) discuss the fact that model reuse is more efficient than code reuse, i.e. it is a good idea to reuse the products of analysis. ‘The concept of pattems does apply to this idea since one of the major benefits of patterns proposed by the pattem community is reuse. According to Eriksson & Penker (2000) the main reason for using pattems (in business modelling) is the possibility to reuse solutions. This means that the pattems describe common business modelling problems and their solutions. Pattems are meant to help modellers understand a problem situation in (business) modelling, Pattems can be viewed as complement to analysis methods. This can be compared to Fowler's (1997) description of pattems as being starting points for modelling. Eriksson & Penker (2000) also emphasise the fact that business pattems are not directly transferable to program, code 2.2 Pattern Language Alexander describes a pattern language as a system of pattems: “And all these rules of ‘thumb-or patterns-are part of larger systems which are languages.” (Alexander, 1979, page 202). This definition does not say anything about how the pattems are related to cach other, According to Alexander (1979) every person has a pattern language in his mind. In this sense the pattern language is the sum of a persons total knowledge. Appleton (1997) concludes that a pattern language is more than merely a catalogue of patterns. There should be rules and guidelines explaining how and when to apply the patterns. The structure of the language is the connections between the individual 8Patterns patterns. The most common way of achieving this connection is to simply add the names of the patterns related, Alexander et al. (1977) describe how pattems are related in a sequence based on the connections between the pattems. The pattems in a language reside in different levels, i, larger patterns are composed by a number of smaller ones, which in turn can be completed by other pattems, see Figure 1. This means that pattem, Ais incomplete unless it contains pattem B and C; pattern B is incomplete unless it contains pattern D and E and pattem C is incomplete unless it contains pattem F. Figure 1. A larger pattem can contain snuller pattems, which in tum can contain other pattems. “This feature can be seen in chapter3.2 where its shown that a threetie architecture ‘can contain a facade, ‘The contains-relationship between pattems means that in order to solve a problem according to pattern A, one must not only follow the instructions of that pattern but also consider the pattems embedded in it. According to Alexander et al. (197) a patter Janguage has the structure of a network. When a pattern language is used, itis used as sequence moving from larger patterns to smaller ones. But since the language isa network there is no single sequence that captures it,Patterns Figure 2. Applying a pattem provides a resulting context, in which a new problem may call for the use of another patem. ‘A pattem has been described as a tiple: problem, context and solution. In that sense a pattem language can be described as.a number of pattems that take you from one context to another, see Figure 2. That is: you have a problem in a certain context, the solution to that problem will provide a new context in which you may encounter another problem. 10Examples of Pattems 3 Examples of Patterns ‘The use of pattems in the software community has resulted in the development of different types of pattems, They cover diverse types of problems and are presented ina number of different ways. In order to give a flavour of the software patterns community some different types of pattems will be presented and exemplified. The following types of pattems have been identified (o be of interest in this work: © Object-Oriented pattems (Coad, 1992; Larman, 1998); * Design pattems (Gamma et al., 1995; Duell, 1997); © Organisational patterns(Coplien and Schmidt, 1995); © Data model patterns (Hay, 1996); © Analysis patterns (Fowler, 1997); * Domain pattems (ELEKTRA, 1998b); * Process pattems (Ambler, 19986) and Systems reengineering pattems (Dewar et al., 1999); and © Business pattems (Exiksson and Penker, 2000) © Deontic pattern (Wohed, 2000b) * Workflow pattems (Kiepuszewski et al,, 2000) 3.1 Coad’s and Larmans’ Object-Oriented Patterns An object-oriented patter is defined as “...an abstraction of a doublet, triplet, or or other small grouping of classes that is likely to be helpful again and again in object- oriented development.” (Coad, 1992, page153), Or as a “...named problen/solution pair that can be applied in new contexts, which advice on how to apply it in novel. situations” (Larman, 1998, page189). Object-pattems are typically presented in the form of generic models together with a text describing its applicability and guidelines for use. Object-oriented patterns deal low-level elements, such as classes and objects. Coad (1992) claims that the different types of associations (e.g. inheritance and aggregation) between classes are examples of patterns. An object-oriented pattern according to Coad inExamples of Pattems (1992), see Figure 3, is described using a tiple: the pattem, an example, and guidelines for use, In this particular case an item description consists of an item object and an item description object. The item description object has attribute values, which may apply to ‘mote than one item object. em temDescription, Figue 3. The item description pattem, From Coad, 1992) Coad (1992) claims that little is known about how patterns can be combined and applied over and over again in different contexts, If pattems can be standardized into larger units they can become building blocks for design and construction, Coad (1992) formulates a number of questions conceming (object-oriented) pattems: © _Isit possible to apply a systematic approach to discover and catalogue pattems? © Isthere a hierarchy of pattems? © What guidelines can be formed to promote the best use of patterns? © Are there any strategies for connecting different patterns to each other? ‘There hns been some work done in this direction, regarding object-oriented patterns, singe Coad (1992) formulated the above questions, Laman (1998) offers an example when he gives a more thorough description of GRASP pattems (General Responsibility Assignment Software Pattems). An example of a GRASP pattem is the Creator pattem. It deals with the problem of which class should be responsible for creating a new ‘instance of some class. Laman (1998) describes the Creator pattern as follows. Creator ‘Solution Assign class B the responsibility to create an instance of class A if one of the following is tue: " Baggregares A objects, = Beontains A objects. = B records instances of A objects. = Beclosely wses A objects. © B has the initalising cata that wil be passed to A when it is created ( thus B is an Expert with respect to creating A). = Bisacreaor of Acbjects. 12Examples of Pattems ‘fmore than one option applies, prefer a class B which aggregates or contains class A Problem ‘Who should be responsible for creating a new instance of some class’? ‘The creation of object is one of the most common activities in an object-oriented system, Consequently, itis useful o have a general principle for the assignment of ‘cation responsibilities. Assigned well, the design can support low coupling, increesed clarity, encapsulation, and reusebility. Example In the pointof-sale application, who should be responsible for creating a slesLinelten instance? By creator we should look for a class that aggregates, ‘contains, and 50 On, SalesLinelfem instances, Consider the pautial conceptual model iol...] (Laman, 1998, page 197) Sale ate time Consins Le Sales Product Lineltem |» pscrneasy | Specification quantity description price UPC AA pectial conceptual model describing the relationship between a Sale and a SalesLineltem, From (Laman, 1998) Since a Sale contains (in fact, aggregates) many SalesLineltem objects, the Creator ‘Patter suggests Sale isa good candidate to have the responsibility of creating SalesLineltem instances. “This leads to a design of object interactions in a collaboration diagram, as shown in Lal (Laman, 1998, page 198) sale Newmetind date arcutquntiy) time ‘SalesLineltem ‘Mabel inet Total A collaboration diagram describing how a SalesLineltem is created. From (Laman, 1998) 13Examples of Pattems ‘This assignment of responsibilities requires that a makeLinelem method be defined in Sale. (Larman, 1998, page 198) Being widely used is a desirable quality of a pattern, since the general idea is to transfer existing principles, which have been proved successful. Acoording to Larman (1998) object-oriented pattems form the basic principles of object technology that have to be mastered by any software developer. Furthermore, as can be seen from the examples presented, object-oriented pattems deal with rather low-level communication between objects. 3.2 Design Patterns according to Gamma et al. Gamma et al. (1995) introduce design pattems as a way to make it easier to reuse successful software designs and architectures, The Gammg-pattems are meant to facilitate the creation of reusable object-oriented design; hence design pattems are a type of object-oriented pattems. They are clearly technical in the sense that they identify the roles, collaborations, and responsibilities of classes and instances. The Gamma- patterns are comprehensive and give a thorough description of various design problems. Gamma et al. (1995) claim that a graphical notation is not sufficient in order to describe pattem; therefore the graphical notation has to be complemented by a text. There are other authors who describe design pattems but they will not be dealt with in detail in this dissertation since Gamma et al. (1995) provide a set of design pattems that can serve as an example of this phenomenon. A design pattem according to Gamma et al, (1995) is described in the following format: * Pattern Name and Classification. The patterns presented have names indicating, their intended use. There is also a classification of pattems in the following ‘groups: creational patterns, which help to make a system independent of how its objects are created; structural patterns, which deal with how classes and objects are composed into larger structures and; behavioural patterns, which are concemed with the assignment of responsibilities between objects. Behavioural patterns describe how objects are interconnected and communicating with each other. © Intent, The intent of a patter is a short statement describing what the pattem, does and what design problems it solves. 14Examples of Pattems Also Known As. If there are any other names for the pattern in question they are found under this caption, Motivation. The motivation for a pattem is typically described using a scenario that shows why the pattem is useful. The idea of this scenario is to illustrate the more abstract description of the pattem. Applicability, The different situations in which the pattem can be used are described. The aim is (0 belp the designer recognize the different situations when the pattem can be usefull ‘Structure. The structure of a pattem is presented as a graphical representation using an object-oriented notation. Participants, The participants are the classes and objects that take part in the pattern. There is also short description of their responsibilities. Collaborations. The collaboration describes how the different participants collaborate to carry out their responsibilities. Consequences. The consequences describe the benefits of using the actual pattern, This is typically done by presenting the advantages and explaining why they are favourable. Implementation. This part of the pattem describes the techniques for implementation, The different techniques are quite often described in terms of other pattems. If there are any language specific questions or possible pitfalls they are dealt with as well. Sample Code. The sample code consists of small parts of Smalltalk or C+ cock, which illustrate how the pattem can be realized in code. Known Uses. The known uses are examples from real systems in different domains, Related Patterns. The related pattems describe what other patterns there are that can be used in association with the actual pattem, The differences between similar patterns can be described in order to show in what situations they can be used,Examples of Pattems ‘As presented above, the design pattems according to Gamma et al, (1995) do not follow the triple: problem, contest, and solution, proposed by Alexander et al, (1977). However it is stated, “The design pattems in this book are descriptions of communicating abjects anid classes that are customized to solve a general design problem in a particular context, “ (Gamma et al., 1995, page 3). 3.2.1 Other Examples of Design Patterns Other authors deal with design pattems in a similar way as do Gamma et al. (1995). One such example is the support pattems presented by Fowler (1997). These patterns deal with the problems that occur when a computer system is to be built around the analysis, patterns. The type of patterns, which Fowler (1997) describe are in fact design pattems of the type that Gamma et al. (1995) and Larman (1998) deal with. One example of a support pattem is the multi-layered client-server architecture, Applicaton ayer Doman ayer Datease Figure 4, A three-tier architecture, ‘The location of the domain-tier in a three-tier client/server environment, see Figure 4, can be either on the clients, or on a new layer of processors, a domain server. In the former case the systems suppott is easier but there is a need for more powerful clients since a lot of the processing is done on them. If the domain tier is located on the server Side it is easier to control and update the domain services but on the other hand there is awhole new set of machines to maintain. There is a trade-off to be made between these 16Examples of Pattems solutions. One major benefit of the three-tier solution is the possibility to make a distinction between the presentation and application logic, see Figure 5, The pattem is described by a number of models accompanied by about 10 pages of text. Itis worth noticing that this pattem does not follow a fixed problem, context, and solution form. It is rather a description of an IS architecture, although it includes a background that motivates why such a solution is preferable as well as the possible problems connected to it. Pepticarion layer Domain myer Datetace Figure 5. “The application tier can be split into presentation logic and application logic. The application logic is responsible for converting the underlying domain types into types that the presentation logic can deal with, The application logic is also responsible for interpreting updates made via the presentation logic. From (Fowler, 1997). ‘The facade pattem is described as a way of organising the application logic, Several authors, e.g. (Gamma et al., 1995; Laman, 1998; Fowler, 1997) describe this pattern. Fowler and Gamma give thorough descriptions, see Appendix B, with examples and models, whereas Larman’s description is rather short. 17Examples of Pattems Facade ‘When a class is defined that provides a common interface to a disparate set of| interfaces, such as a Madem class, it is called a Facade-one of the Go” [my footnote] pattems The disparate interfaces may be to a set of functions, a framework, a group of other classes, ofa subsystem (local or remote). Facade Context/Problem A common, unified interface to a disparate set of interfaces-such as to a subsystem= is required, What to do? Solution Define a single class that unifies the interface and give it responsibility for ‘collaborating with the subsystem. (Laman, 1998), page 419. Fowler (1997) also present pattems for type model design templates, These describe Principles for turning conceptual models into software. The patterns are named: Implementing Associations, Implementing Generalization, Object Creation, Object Destruction and Entry Point, Some of these pattems, such as Object Creation, are also described by Gamma et al. (1995) and they deal with the same type of problems, as do the Gamma-patterns, 3.3 Coplien’s Organisational Patterns Organisational pattems are “used to shape a new organisation and its development process” (Coplien & Schmidt, 1995, page 183). According to Coplien & Schmidt (1995) organisational pattems should help us to both understand existing organisations and to build new ones. This is referred to as “generativity” Coplien & Schmidt (1995) and Coplien considers it the novel of his work in organisational pattems. Coplien & ‘Schmidt (1995, page 185) define the term organisation as: “a community of mutual interest, of the sort that forms naturally in any culture.” According to Coplien & ‘Schmidt (1995) an organisation is usually responsible for some deliverable. In order to produce that deliverable a project is formed. The activity within an organisation is called a process. This triple is what an organisational pattem deals with. Nomally an ? Gang of Four pattems fiom the book Design Patterns 18Examples of Pattems organisation is formed to meet a business need (Coplien & Schmidt, 1995). This can be done within an industry ora company. ‘The pattems described in “A Generative Development-Process Patter Language” by (Coplien & Schmidt, 1995) are divided into organisational patterns and process patterns. “Patter 4: Size the Schedule”, is quoted here to give an example of Coplien’s organisational patterns: ‘Problem There are no perfect criteria for screening team menibers Context ‘You are building a sofiware development organization to meet competitive costand schedule benchmarks, You are staffing up to meeta schedule in a given market Forees “Empowerment depends on competency and the distribution of knowledge and power. The worst team dynamics can be found in appointed teams, The best team > ant its associated role ny be splitjfto a set of actors anda se of associated roles reflecting the Srucure ofthe organisation. This also applies w je <> actor an its role. Coordination inks wil have to be defined berween the roles lcs Informal description Guidelines ‘Type: (ActorRoke Diagram) ‘Domain: Customer Servicing Usage Intention: Define wy (Meter Reading) ast ‘Founal description 4 Baly Figure 1. An example of an ELEKTRA business process pattem. From (ELEKTRA, 19986), ‘The ELEKTRA patterns consist of a formal description, an informal description, guidelines, and a body, The idea that a pattem should consist of a graphical description, and text conesponds to the pattern format of Gamma et al. (1995). ‘The formal description (or formal signature) is used to retrieve pattems that are appropriate for a certain situation, The formal description has a situation part and a usage intention part. The situation describes the applicability conditions. Stating the type and the domain of the pattem does this. ‘The informal description (or informal signature) is composed of the mandatory components: name, context, problem, forces, and solution; and the optional components: ritionale, consequences, authors, related pattems, related documents, 2BExamples of Pattems byperlinks, annotations, and known applications. The informal description provides information about how the pattem can be used. ‘The guidelines are meant to give a number of tips in order to facilitate the use of the pattern. ‘The second type of pattems in the ELEKTRA project is called change process patterns (ELEKTRA, 19986). The change process pattems deal with change management and human resource management. This type of pattems shows how change processes can take alternate routes, by describing the intentions for the different decision steps and the ‘means to achieve them (in terms of product pattems). (ELEKTRA, 19986) distinguishes between domain specific and domain independent patterns. A domain specific pattem can be used for different applications in a specific domain, whereas domain independent patterns can be used in different domains. 3.7 Amblers’ Process Patterns Ambler (1998a) concludes that not only the same types of problems occur across domains, Itis also the case that the strategies used to solve them recur, Ambler (1998) claims that these strategies can be described by process pattems, Dewar et al, (1999) introduce the notion of system reengineering pattems to describe the process of reengineering legacy systems. A process pattem is “a collection of general techniques, actions, andor tasks (activities) for developing object-oriented software.” (Ambler, 1998b, page 4) According to Ambler (1998b) a pattem describes what to be done without giving the exact details of how to do it. Ambler (1998b) argues that pattem can exist on different scales. © A task process patter describes the detailed steps to perform a specific task. “The task process patterns are identified as a key component of a software process, © A stage process pattern describes the steps of a single project stage. It is a higher-level pattern usually composed by several task process pattems, A stage process pattern organise the task process pattems and put them in a meaningful context, * A phase process pattern describes the interactions between the stage process patterns in one project phase, e.g, the delivery phase. 24Examples of Pattems Process pattems and organisational patterns go hand-in-hand according to Ambler (19986). A process pattem is meant to be used as a means for an organisation to shape a successful software process, In order to understand what process pattems are it is necessary to understand the Object-Oriented Software Process (OOSP). OOSP is described as serial in the large and iterative in the small (Ambler, 1998b). The Serial steps are: Initiate, Construct, Deliver, and Maintain and Support. These four parts of the OOSP are referred to as phases, see Figure 12. Within each phase there are a number of stages, which in tum can be divided into tasks. Initiate Construct Deliver Maintain &Support Define and validate Ten Not described in detail here. sustify | | anit Model thegnall requirements ts = [E-4 — DefineInitial | [Define ‘Management Infrastructure |} Generalize | | Program Documents Figue 12, The two first phases of the Object-Oriented Software Process (OOSP), From (Ambler, 1998). ‘The pattems are described at different levels. For example the Initiate Process pattem is described as in Figure 13. 3Examples of Pattems Initial Context Allocated Maintenance Changes From Maintain and Support Initiate Define and waite y Management Documents Justify | | initial Initial Requirements, reirements projec inrasuucture, Project Funding, Project Charter Define intial | [ Detine Mangement | | infrastructure Docurents Resulting Context Figue 13. The Initte Process Pattem. From Ambler (1998). ‘The elements of a Process pattem are name, forves, initial context, solution, and resulting context. The text descriptions may be complemented by graphical descriptions. The Initial context is described as the entry conditions to the phase in question and the resulting context is described as the exit conditions of the phase. In between these two contexts the tasks needed to achieve the resulting context are described. The stages and tasks are described in the same way as the processes of higher granularity. For example one task within the Define and validate initial requirements stage is called Use-Case Scenario Testing. The Us-Case Scenario pattem is desctibed by the following model, see Figure 14, In other words, this pattem describes how to create a Use-Case.Examples of Pattems ‘Choose the nent wp teen fg xs, Ye | Describe the’ eae fr Create a “hss Add new chs responsibility tothe ckss, Figure 14, "The Use-Case Scenario Testing Process pattem. From Ambler (1998) In fact, Ambler (1998b) describes process pattems as conceptually similar to design patterns and analysis patterns in the sense that they describe solutions to a common. problem without giving any details about the implementation. ‘The systems reengineering pattems that (Dewar et al., 1999) describe consist of name, status, example, context, problem, solution, consequences, and known uses. The systerm-reengineering patter describe a software process, and can hence be viewed asa type of process pattern. 3.8 Eriksson's and Penker’s Business Patterns Eriksson & Penker (2000) describe business pattems as a way (o reuse solutions when. modelling business systems. Pattems are generalised solutions to problems occurring in different business situations, which can be used as a complement to analysis methods. Eriksson & Penker (2000) emphasise the fact that a pattem is not invented: it is rather the knowledge and experience of practised modellers who have identified working solutions to common problems. Eriksson & Penker (2000) recognise three types of patterns, which are used in different phases of the development process. The three typesExamples of Pattems of pattems are: Business pattems, Architectural patterns, and Design patterns. Business patterns, in turn, are divided into three categories: Resource and rule pattems, which provide guidelines for modelling the rules and resources in a business domain. This type of pattems address issues Hike organisational structures and contract definitions. The resource and rule pattems provide help in modelling common business coneepts and situations as well as representing complex product information, The resource and rule pattems are said to be generic enough to be applicable in a number of different kinds of businesses, Some examples of resource and rule pattems are: actorsrole pattem, document pattem, employment pattem, and product data management pattem. ‘Three different goal pattems describe how high-level goals can be decomposed into sub-goals, how goals can be allocated to different processes, and how goals and problems are related to each other. The goal pattems are used in the early phases of business modelling, Process pattems, which are intended to support the creation of better workflow models and other types of process-oriented models. Eriksson & Penker (2000) use a business pattern template to express their pattems. ‘Their template include the following parts in a pattem description: ‘Name: a business pattem must have a distinct name that can be easily associated with it. Intent: he intent section explains what the pattern does and what problems it solve. Motivation: the motivation of a pattem gives an example of how the pattem can be used to solve a problem. The motivation of a pattem is closely attached to the forces that affect the pattem. Applicabil defined. The applicability part of the pattem helps the reader to recognize the problems that can be solved by applying the pattern. this is where the situations in which the pattem can be used are Structure: the structure of the pattem is described using a UML model.Examples of Pattems © Participants: this section describes the model elements from the structure section, * Consequences: the consequences section describes how the pattem support the ‘goals defined and how different tade-offs affect it, * Example: the example section provides a concrete implementation example, * Related patterns: this section present altemative or complementary pattems. * Source/credit: the source section gives credit to the inventor(S) of the pattem. Eriksson & Penker (2000) describe their pattems using both text and models (see Appendix A foran example). The models are created with an UML notation. Since UML provide a symbol to representa pattem it is found suitable for describing pattems. ‘The UML symbol used to represent a pattern is described in Figure 15. Figure 15. A patter is represented by a collaboration symbol in UML. The dashed box contains the classes used in the pattem. The pattem is sid to be parameterised. From Eriksson & Penker (2000) Ina mocklling tool supporting UML the pattem symbol may be expanded and the models representing the pattern are showed. The term definition pattern Figure 15 describes how temas are defined. When the pattem is expanded the structure of the pattern is shown using a class diagram Figure 16. Kiso ed communicate Tem “Tem Usige Concept Figure 16. A class diagram showing the structure of the Term Definition pattem, From Eriksson & Penker 2000). ‘A pattem can be parameterised, ie. the classes that are used in the pattem are listed in the dashed box. A parameterised pattem can be used in other pattems. This situation can be described by drawing a diagram Figure 17 that shows the concrete classes used in the 2Examples of Pattems implementation of the pattern. An object diagram can be said to exemplify the class diagram, it gives a snapshot of some situation in the system, Name Link Description Figue 17, ‘The use ofa patie in a specific case is described by assigning concrete classes to the role names in the formal parameter classes of the pattem, From Eriksson & Penker (2000) Eriksson & Penker (2000) state that the act of modelling a complex business requires the possibility to use multiple views. Each view focuses on some particular aspect of the business and is described by a number of models and texts. In order to provide a “tool” tomake these descriptions Eriksson & Penker introduce Business Extensions. The four business views are: Business vision: the business vision gives the overall vision of the business by modelling the goals of the business and the problems that need to be solved in ‘order to achieve these goals. Goals are modelled by using UML class diagrams, Business process: this view models the activities that create value to the business. Business processes model how processes and resources work together in order to achieve the goals modelled in the business vision, The interaction between processes is also shown, Business processes are modelled using UML activity diagrams complemented by a set of stereotypes defined in the Eriksson Penker Business Extensions. Business structure: the business structure describes the structure of the resourves in the business, These resources can be the structure of the organisation in which case one part of the madel can be viewed as a (type of) traditional organisational chart. The business structure can also describe the structure of the services andExamples of Pattems products provided by the business. UML class and object diagrams are used to model the business structure, © Business behaviour: the business behaviour view describes the individual behaviour of resources and processes and the interaction between them. The behaviour of each object is described in more detail. This description includes the behaviour in different states as well as the possible state transitions. Since state, action, and event are important parts of the behaviour view it is modelled using the UML dynamic diagrams: state chart, sequence, process (UML activity diagram with business extensions), and collaboration diagrams, An example of a business pattem, the Actor-Role pattem, is shown in Appendix A, 3.9 Wohed’s Deontic Pattern ‘A deontic object (Wohed, 20006) is an object that entails obligations and authorities. There are two different subclasses of deontic objects: atomic deontic objects and agreements. An atomic deontic object entails one obligation, for example to pay a debt. Agreements concem a number of different deontic objects and the obligations and authorities conceming them. An example of an agreement is the relationship between an. employer and an employee. The examples above show that deontic objects are social objects always concerning at least two parties. One party can be responsible for fulfilling some obligation to another party. The relationships between deontic objects can be regulated in terms of contracts. Decntic objects can be related to each other in various ways. Two examples of such relationships are: is context for and justification. The context of a deontic object is the agreement that specifies in which situation a deontic object can exist, A generic deontic pattern can be described as seen in Figure 18. One example of this, offered by Wohed (20006), is the appointment of a person as teaching assistant (one deontic object), which can exist only if there is an employment (another deontic object) for the person in question. In this case the employment provides the context for the teaching assistant. Deontic objects are managed by speech acts. A speech act “designates actions performed by linguistic means.” (Wohed, 2000b, page 74). One example of a speech act are the words: “I pronounce you husband and wife,” which, when spoken by the priest during the wedding ceremony, change the obligations of the married couple. 31Examples of Pattems wit << | -———— feprtiese — ¥ v Puy “Atomic Agent scone fr v Deontic justifies: object | onan tJ Rene ‘ ket Object level “ Meta level sti v Davao Object Template + one ir Repetto Role Atomic Agreement Resi fr ‘Template Templae iin 7 Figure 18, _A simplified generic deontic pattem, adapted from Wohed (2000b), where the speech acts has been excluded, The meta level represent the supertype ofthe deontic object ‘The actual objects exist al the object level. (van Gigch, 1991), According to Wohed (20006) some analysis pattems and data model pattems can be viewed as specialisations of the deontic pattem. One example is the employment pattem described in chapter 3.4. The employment pattem is also described by Fowler (1997) and Eriksson & Penker (2000). This patter is classified as an agreement where person and organisation are the parties involved as can be seen in Figure 19. 2Examples of Pattems Person Paty), Position mye Assignment . Role in _ | Employment ‘Paty Assignment) | —>| (Agreement) Party) | employer Position Organisation |/ Bole) (Paty) Figure 19, A description of the employment pattem fiom the deontic pattem point of views Adapted from Wohed (20006) 3.10 Workflow patterns according to Kiepuszewski et al. According to Kiepuszewski et al. (2000) conventional workflow mechanisms like task sequencing, split parallelism, join synchronisation and iteration have proven effective for business process automation. These mechanisms can be used in business process modelling. One possible way of promoting the use of ideas from workflow modelling is to use workflow pattems, as described by Kiepuszewski et al. (2000). Since there is a number of different workflow modelling languages it is important that the pattems are language independent, i. describing workflow concepts rather than language specific solutions or solutions that are dependent on a certain workflow engine, In fact the ‘workflow pattems found in Kiepuszewski et al. 2000) have been used as benchmarks fo evaluate commercial workflow engines. Workflow pattems consists of four parts: A description, which gives a short summary of what the pattem is to be used for; Examples, which give a few short examples of possible areas of use for the pattem; Problem description, which refers to possible problems associated with the pattem and finally; Suggested solutions, which describe how the pattem can be implemented. ‘The Discriminator pattern, one example of a workflow pattern, is described as follows by Kiepuszewski et al. (2000): 33Examples of Pattems Discriminator ‘This pattem can be seen as the converse of the multi-merge. t should be implied ‘when our semantics is that only one activity should be instantiated after merae, uy «6 A L®CANDS (disc) D a eS Description “The discriminator is a point ina workflow. process that waits for a number of incoming branches to complete before activating the subsequent activity. Fromthat ‘moment on it waits forall remaining branches to complete and ignores" them. Once all incoming branches have been triggered, il resets itself so that it can be triggered again, Examples © A paper needs to be sent to extemal reviewers. The paper is accepted if both reviews are positive, Bul ifthe firstreview thal atives is negative, the author(s) should be notified without having to wait forthe second review. © To improve query respome time, a complex search is sent to two different databases over the Intemet, ‘The first one that comes up with the result should proceed the flow. The second result is ignored. Problem Description ‘Some workflow engines (¢.g.Staffware, HP ChangeEngine, I-Flow) will not ‘generate the sevond instance of an activity ifthe fut instance is still active. ‘However, this does not provide a solution forthe discriminator since once the first instance ofthe activity finishes, the second instance will be created, ‘Suggested Solutions 1, There is. special construct that implements the discriminator semantics in Verve, 2, The discriminator semantics can be implemented in products suppocting, Casto Triggers. (see N-outof-M join for details). 3. Inall other workiow engines the discriminator semantics is hard or impossible to implemert. ‘The common design pattem is to use Cancel Activity, Once the first instance of the activity following the discriminator iscreated, the activities of the incoming, branches that still have not ‘completed can be cancelled. This way the second instance of the activity following the discriminator will not be created. This pattem is shown below. The problem with this solution is that if activities B and C are performed concurrently, activity D may sill end up being executed twice. ‘Moreover, the original semantics of the discriminator is to allow both B and CC to finish. In tis solution either B or C will get cancelled.Examples of Pattems Qverge Task E: ¥. FFB not completed, CAND iC not completed 2 >= Figure 20, The Discriminator pattem as presented by Kiepuszewski et al, (2000, Discriminator.ham) 3.11 Relationships between Patterns In section 2,2 the structure of a pattem language is defined as the connections between the individual patterns. What does these connections look like in some of the pattern languages described in this work? Some of the authors have actually provided graphs showing these connections, while others only provide information about these connections in text. There are advantages of describing the pattem language graphically since such a description can give a better overview of the language. (Gamma et al., 1995) provide a graphical overview; see Figure 21, of the design pattem relationships, which gives a good overview of the pattern language. 35Examples of Pattems werent esp Pov Baler 7 saungsapctiaten ? yak erage hr OST rynaere rh ana pa _oree / See) reper | ie = ragaohty Sean sae exper areata -geraann_-) YP ato ‘Figure 21, ‘The relationships between Design pattems, From (Gam et al., 1995) Coplien and Schmidt (1995) do not describe the relationships between Organisational patterns graphically. A graphical description, similar to the one above, of the relationships between Organisational pattems can be done, However, the result is a very complicated model with a vast amount of relationships.Examples of Pattems = “as] [mass] [ome ae oa = ‘Peter 1) a (Peter 5) (remem) Pemers Pease) | oeazen | [gases | [eatin] ~ | Same (Pomer6) ‘Patm7) Fae) ‘Pramerig) ‘Poser 1) oto | [esi], Pee) | [ump fen) [ee 5 (ans Figure 22, A model of the relationships between the different Organisational pattems. As this model shows, the great numbers of relations are hard to describe in this way. ‘The graphical description in Figure 22 shows that the relationships between the pattems in a pattem language can be quite complex ata relatively low number of pattems. In this case the number of pattems in the language is 42. A more readable way of showing, 37Examples of Pattems ‘some of these relations can be found in Appendix C. Such a description, however, requires a number of smaller graphs. Obviously, these have to be linked to each other in. order to retain information about the whole pattem language. ‘The pattems in ELEKTRA (1999) are organised in an intention hierarchy. The usage {intention is a part of the formal description (see chapter 3.6), which is used to form this hierarchy. The ELEKTRA patterns are organised by relating the usage intentions with AND, OR, and AND/OR connectors; see Figure 23, Define way to trade 1 4 Recennector a “Trade eleonicity “Trade electricity through through pool bilateral contracts “Trading of electricity through pool Actor+Role pattern Figure 23. Anexarrple of how usage intentions can be related using an AND/OR connector. The ‘connector generates the intention “tefine way to trade electricity”, ELEKTRA (1999) If the relationships between the pattems in a pattem language form the pattem language, the relations between different types of pattems can be said to form a “meta pattem, language”, which could serve as a road map of pattems. In order to construct such a road map there is a need to organise the different types of pattems, In more detail, there isameed to: © Classify the different types of pattems identified in this dissertation according to some classification scheme(s); * Relate different types of pattems to each other * Relate different types of pattems to the different phases of the life cycle; © Relate different types of pattems to different roles of actors in the life cycle; 38A Classification of Pattems 4 AClassification of Patterns In this chapter a classification of pattems will be formed. Furthermore, this classification will serve as a framework for a discussion about the possible use of patterns in the different phases of the life cycle of an IS. A classification is necessary in order to able to talk about pattems and relate different types of pattems to each other. We will present a number of different classification schemes in order to view the concept of pattems from different angles. Wohed (20006) claims that the concept of patterns is not commonly used in the initial phases of information systems development, ie. analysis and design. Acoording to ‘Wohed (2000b) this can be due toa lack of standardised patterns collected in libraries that support development tools. Another possible reason could be a lack of suitable patterns, One objective of this dissertation is to relate different types of patterns to the life cycle of an information system. This objective could be seen as an attempt to identify suitable pattems, or types of patterns, for the different phases of the life cycle of an information system, A first step in doing this is to classify the different pattems, which have been identified, in some appropriate way. Obviously such a classification can be made from a number of different criteria, ‘A hierarchical classification can possibly serve as an aid in seeing how different types of pattems are related to each other, Another feasible way of organising pattems is to see what different generic types of pattems that are possible to identify. These types of patterns can be related to the information system life cycle in order to establish their possible use in information systems engineering. Further ways of classifying pattems may be to investigate the emphasis on formal models; whether they deal with structure or process, or different combinations of the approaches described above. Yet another way of structuring pattems is to investigate in which part of the information system they are used or which types of problems they solve. Buschmann & Meunier (1995) describe a way of organising pattems according to the three axes: Granularity, functionality, and structural principles. This system of pattems deals with design patterns and cannot be applied as a whole to all kinds of patterns since it isa classification at a lower level. However, parts of Buschmann & Meunier (1995) ideas may be of use in classifying different types of pattems at a higher level. )A Classification of Pattems In order to make these different classifications possible there is a need to define what is ‘meant by a pattem in the context of this work, That is, to forma genetic concept of a pattern, which comprises the different types of pattems described in this work. 4.1 Towards a Common Concept of Patterns Patterns can be seen as systematised knowledge. The knowledge transferred in the different types of pattems described in this dissertation span over vast areas. There is not only a need to know how the different authors descrite this knowledge. There is also a need to find out how these pattems are related to each other and what they have in common, i. to make a classification, In orckr to make such a classification itis essential to identify a common concept of pattems. As can be seen from the different types of pattems described in this dissertation there is no such common concept. Different authors use different techniques to describe their pattems. The mast unifying idea of a pattem is that it should describe a solution that is based on experience and is known to work. The experience has to be made explicit and validated in order to form a pattern. This process is sometimes carefully described as with the ELEKTRA pattems and sometimes more briefly described as in Coplien’s Organisational pattems. ‘The pattem is to be found in the world of practice and described in some structured way, The original form of writing pattems, ie, context, problem, solution is not always made explicit but can be found implicit in the description of the pattem. The forces that are the reasons for using the pattem, can also be either explicit or implicit, These forces are important parts of the pattem since they help in describing the settings for a pattem. This is imperative since a pattem is to describe a well-known and proven solution toa problem. That is, the context/probleny/solution triple, and the forces can be found in the description of the pattern.A Classification of Pattems Name es es Forves Comprises Pattem >| oetne pune dc ty. . andr sit in me Problem | “SEE pl context x Sebves innew Text Model Problem spies Figure 24. A graphical description of how the different pars of a pattem are related to each other. For the purpose of the classification made in this dissertation a pattern can be defined as follows: A patter is based on experience found in the world of practice. A text or a ‘model or a combination of the both can describe it. The context, forces, problem, and solution can be explicitly expressed or implicitly found in the description of the pattern. This definition can be accompanied by Figure 24, We will refer to this definition of a pattern in the forthcoming chapters of this dissertation, Buschmann & Meunier (1995) distinguish the three parts: context, problem, and solution as essential parts in a description of a pattem. In order to support the understanding, comparison, and selection of pattems, Buschmann & Meunier (1995) have ackled aspects to the basic description of a pattem, These extensions are closely related to the ones of Gamma et al, (1995), as presented in chapter 3.2, The definition proposed in this work could easily be complemented with such a description schema. ‘However, for the purpose of the classification made in this work, there is no need for an extended description of that sort. 4.1.1 Classification with Respect to the Level of Abstraction Robertson & Strunch (1993) describe an analysis pattem as a part of a requirements specification that originates in one project and can be reused in other projects. In order to structure the elements of reuse, a classification of requirements patterns is offered. This classification arranges the patterns in a four-level hierarchy. Buschmann & 4A Classification of Pattems Meunier (1995) provide a similar classification, but with three levels: Architectural frameworks (describing the overall structure), Design pattems (describing smaller architectural units), and Idioms (dealing with implementation issues). ‘The domain level of abstraction (Robertson & Strunch, 1993) describes knowledge that is independent of projects. For example a loan has properties that are common, regardless of type of loan or hiting, The Subject matter level contains details about a specific field of knowledge. The different types of loans (see Figure 25) share the properties described at the domain level but ackls knowledge to its own subject matter area. For example: a loan is always a question of borrowing and retuming an object, in that sense a book loan and a car rental is similar. The third level, the specialised subject level, brings more detail to a specific view of a subject. For example Library loans at the subject matter level can be further specialised with regard to the type of book or ‘manuscript that is being loaned. At the project level it is possible to find models for reuse in specific projects. These similarities can be utilized when designing systems for different situations, At the project level, the pattems contain project specific details as well as the knowledge inherited down the path of the hierarchy. Loans Domain level Subject mater Video Car rental Library Det rental jon ot iw cia Reference ‘Specialised subject Book loan | | Magazine level work loan oan * NI Project level Project A Project B Figue 25, The four leveb of abstraction forma hierarchy where the lower levels inherit the ‘properties of the higher levels. Adapted from Robertson & Strunch (1993) 2A Classification of Pattems A hierarchical classification is used in ELEKTRA (1999) as described above in chapter 3.1L, For the purpose of the classification scheme in this chapter, we have adopted the abstraction levels of Robertson & Strunch (1993). The pattems dealt with in this dissertation are presented in Figure 26, Domain level etal. Kiepuszewski Woled Ambler Subject matter Hay Fowler level Project level Figue 26, ‘The differentypes of pattems classified according to their degree of abstraction. Coplien’s Organisational pattems are difficult to place in an abstraction hierarchy. On. one hand they are very specific in the way they are expressed, but on the other hand they can be used in a different types of projects. They are found at the project level since they can be used directly in order to organise a specific project. Process pattems can be classified in the same way as Organisational pattems since they describe the different steps in a software process. These steps are found at the project level, where, for example, Use Case modelling can be found as one specific activity in a software development process, In fact, a Process pattem can be a pattem for how Use Case modelling is performed in a software project. Ambler’s process pattems may reside on the domain level as well since they deal with knowledge independent of projects, ie. the steps in a software development process are the same no matter what the domain is. Gamma’s et al., Larman’s and Coad’s pattems can be classified as low-level pattems in this sense since they bring more detail about the implementation than do Data Model BA Classification of Pattems patterns (Hay), Analysis pattems (Fowler), and Business pattems (Eriksson & Penket). However, it must be noticed that Fowler deal with some of the problems that Gamma et al, describe (an example is to be found in chapter 3.2) It could be argued that Business pattems and Analysis pattems should be found at the Domain level, as is the Deontic pattern, However, as stated by Wobed (20006), Analysis patterns can be viewed as a specialisation of the Deontic pattem and thus the Kipuvewsi | Coad <<— ss iamn Wahed Natal Image descriptions pllming Rewiems ysis tazoduction Opention —Rephcen See Gevelepment Replies Figue 34. The two dimensions Model emphasis and life cycle stage combined. (One important task in the early phases (planning and requirements work) of the information system life cycle is to make the demands put on the system explicit and to formalise those demands. This is typically done in negotiation between different stakeholders (Pohl, 1994). The aim of the types of pattems used in these phases is to reuse former knowledge as a starting point for modelling, Pattems described by models would form a knowledge base for the developer/analyst rather than being. communicated to other stakeholders. Patterns described in natural language would probably be easier to communicate to the various stakeholders in the ISE process. 46A Classification of Pattems ‘The organisational patterns of Coptien and Ambler’ process pattems form a different category describing the software development process itself, The aim is to communicate knowledge to developers and project managers about the development process and this, is an issue of interest throughout the whole information system life cycle. ‘The ELEKTRA process pattems deal with issues concerning human resource ‘management and change management, Those process pattems classified as domain specific (as opposed to domain independent) form a different category, since they provide domain knowledge that could be used in the early phases of the information system life cycle. 4.2.3 Product/process and Life cycle Stages Hay <> Kipusewski Conc <_ Laman HEKIRA() —-+——> a Gtmact al. Fowler (12) hed 2 Prot <——> Fowler (12) <> Enkson & Erikson & oer ‘Penker — HLBKIRA@) — gowker (2) Fovder (12) ee Pros Pkloning Rewiremers jauistiontd Irmeckction Operon Replacement Spec. evelopment Figure 35, ‘The two dimensions producl/process and life cycle stages combined. ‘There isa distinct cluster of product patterns in the requirements specification phase. ‘This is an interesting fact since Wohed (2000b) claims that there is little or no use of patterns in the early phases of information systems development (see chapter 2.1), There does not seem to be a lack of pattems dealing with problems in these phases, so one conclusion must be that there are difficulties in applying the pattems in the situations a7A Classification of Pattems they are intended for. One reason for this may be that ISE methods do not support or incorporate the use of pattems. In fact, Dewar et al. (1999) claim that future methodologies might incorporate patterns. Another reason may be that the knowledge described in these types of patterns is actually knowledge in the heads of developers and analysts. If this is the case, there is no need for them in the analysis work. These patterns are of more use in other contexts. 58Discussion 5 Discussion In this, chapter the results of the literature survey and classification will be discussed and related to the areas of future research, which have been identified. This will be done by: 1. Discussing the potential benefits and advantages as well as risks and disadvantages of using patterns in the ISE process. ey Evaluating the way of working in this project. 3. Discussing the relevance of the classification made for the future possible areas of research. 4. Briefly presenting the possible areas of research that have been identified. 5. Giving an outline of possible future work within the areas of research that are found most interesting. 5.1 Advantages and Disadvantages of Pattems ‘A number of benefits and risks with patterns can be recognised. Since there are a number of different types of patterns the possible benefits and risks may differ with respect to the type of pattem discussed, Benefits and advantages: © Patterns make it possible to transfer knowledge between projects and areas, and thereby they promote reuse. Since reuse is an important issue in e.g. component based development, design pattems dealing with architectural issues would certainly be an interesting approach. Transferring knowledge is a matter of knowledge management. There are, potentially, a number of points of contact between these areas. The integration of pattems into information systems development methods would then form a knowledge-enabled process for information systems development. © Pattems can transfer knowledge fiom experienced developers and analysts to less experienced professionals and students. This approach to the use of pattems ‘would imply that patterns could be used as a educational aid, This in itself could constitute an area of research, 59Discussion © Patterns mediate common solutions that are proved to work. Pattems may be an effective way of communicating these solutions, i, it is the form of writing patterns that make them efficient. If this is the case, the various ways of writing patterns indicate that their efficiency may vary, Pattems with a madel emphasis, may constitute a slightly different group in this matter since the model itself is the pattem, However, these conceptual models have to be elaborated and explained in order to be useful for less experienced modellers. For example, an analysis pattem could be used to make a first cut model. The pattem would ‘guarantee that the most important entities and relationships are captured, Further elaboration is needed in order to find the attributes unique to the situation at hand, as well as identifying other entities that may fit within the pattem. This is also to be compared with the previous bullet, pattems as an educational aid. © The pattem form, describing a problem in its context and relating this toa solution may provide a simple form of writing. The form of writing pattems would give some kind of guarantee of including all the important details in. This, could be contrasted to the critique of the fixed form that has been proposed by some authors e.g. Fowler, (See bullet two in the list of risks and disadvantages.) © Patterns can be used as starting points for analysis and work. This seems to be a feasible property of a pattem, It indicates that the use of pattems is not a question of applying old solutions to new problems but rather a question of making sure that prior solutions can be adapted to new situations. (Compare this to item three in the list of risks and disadvantages.) © Pattems can provide a background and a setting for the solutions proposed. The context could provide information about why something is done rather than just, stating what should be done and fiw. This is a desirable property, since it adds to the understanding of the actions taken in the ISE process as well as the ‘structure of a solution. Risks and disadvantages: © There isa problem in deciding the level of abstraction that a pattem should have, too high a level of abstraction would make a pattem meaningless, Evidence of this can be seen in Rolland et al, (2000). There is a similar risk if pattems areDiscussion dealing with ‘trivial’ problems. That is, patterns should not be written about all kinds of problems, © The fixed form of writing pattems is a problem in itself since some situations are ‘not suitable to describe in this manner. For example, the results of the evaluation ofa pattem approach described in Rolland et al., (2000) shows that clusters of patterns are preferred to individual pattems since they give a broader and more complete solution. * There isa risk of conserving bad solutions if pattems are viewed as fixed solutions. That is, if pattem is applied without thorough analysis there isa risk of applying an unfeasible solution to the problem at hand. 5.2 Evaluation of the Way of Working ‘There is no common notion of what pattems are and how they can be used in ISE. This makes the process of finding relevant literature difficult. There is much waitten about patterns, but there seems fo be just as many opinions as there are authors on how patterns should be described. This makes it difficult both to decide what a pattem really is and according to what features they should be classified, There is a risk for excluding pattern approaches that should have been included. Since the aim of this project is to make a survey of the area and find out about the usefulness of pattems in ISE, there has been a need for an open mind and an explorative approach. This is the reason for exploring all the different types of pattems, which have been accounted for in this dissertation. Another risk when conducting a literature survey is the possibility of leaving important, sources out. However, the sources dealt with in this work constitute. firm enough foundation for the classification schemes presented. The classification schemes have been usefil to show the differences and similarities between the different types of patterns described. It has been useful in the sense that it has made them explicit and thereby bringing some order into the set of pattems presented in this work, Furthermore, these classification schemes have been formed in a way so that they can be used to study and classify additional types of patterns. ‘The classifications of pattems in this dissertation are informal in the sense that there is no unambiguous way to assign a certain type of pattem to a category. This negative aspect is due to the fact that the classification is based on aspects that are hard t0 6Discussion describe formally and precisely. One possible disadvantage with the classifications ‘made in this dissertation is that they are based on the semantics perceived by one person, It would be of interest to verify the usefulness of the classification schemes presented in this dissertation, Interviewing experienced developers could, for example, do this. 5.3. Possible Future Work ‘The following areas for future work have been identified: © Patterns and ISE methods, * Tool support for the use of pattems; © Extracting, documenting, and presenting pattems; Patterns as an educational aid; Patterns and novel applications of IT. Each area will be briefly accounted for in the following sections. Patterns and ISE methods ‘The incorporation of pattems in ISE methods has been recognised as an interesting area for future work by, e.g, Dewar et al. (1999). The benefit of creating a taxonomy of patterns, as has been done in this dissertation, is that it can facilitate the integration of pattems into ISE methods. For example, such integration will put demands on how pattern repositories should be organised. ‘There is also a need to establish a system of pattems in orckr to get an overview of the demands put on pattems in different phases of the ISE process and in the different situations of usage. The demands put on a pattem depend on the type of problem it is intended to deal with, These issues have to be further investigated. Furthermore, a framework for incorporating pattems into ISE methods must be established, In doing this itis important to be aware of the underlying philosophy of the method as pointed out by Nilsson (1995). ‘Tool support for the use of patterns ‘The issue of pattems and tools is closely related to the use of patterns in ISE methods. Firstly, various tools are used in the ISE process. That is, if pattems are to be integrated aQDiscussion into the ISE process these tools have to support the use of patterns in order to make them a part of the methodology. Obviously this type of integration calls for the utilisation of pattem repositories. In order to create such repositories there is a need for extended description schemes for pattems, Since there are a number of tools supporting various ISE methodologies on the market, a first step would be to conduct a too] evaluation with respect to the classification made in this dissertation, Such an evaluation could be performed in combination with an evaluation of methodologies since the two are closely related. Extracting, documenting, and representing patterns ‘The process of extracting and documenting pattems aims at condensing the knowledge of skilled practitioners and representing them in the form of a pattem, Obviously, the quality of the knowledge contained in the pattem has to be guaranteed. Doing this concern both issues of making sure that the right knowledge is extracted at the right level of abstraction, as well as finding the proper representation for this knowledge. Patterns as. an educational aid ‘The knowledge in the heads of skilled and experienced developers is most often hard to convey to less experienced people. This is of course a pedagogical problem. If pattems can be used to structure, extract, and transfer this knowledge, pattems may be viewed as an aid in bridging this educational gap. Understanding why things are done the way they are, is an important factor in gaining, deeper knowledge. The knowledge of why is often implicit but has to be made explicit for educational purposes. It is quite possible that pattems can provide the means for doing this. It is possible that the way pattems are described can add toa deeper understanding, e.g. by the fact that the forces behind a problem is clearly stated. That is, the problem is put into context, “There is no easy way of describing complex phenomenon such as for example the ISE process or the art of creating good software solutions. Yet this is what we have to deal with when we are to teach these things. "Abstraction is one of the fundamental ways that we as humans cope with complexity.” (Booch, 1994, page 41). Abstraction isa process of finding similarities between situations, objects and processes in the world, In. this sense abstraction can be viewed as a process of learning. eBDiscussion Patterns and novel applications of IT attems can be used as a diagnosis tool to decide the feasibility of different solutions. For example, if there is a pattern that describes a successful architecture this pattern can be used to evaluate other solutions. (One possible area of work may be to investigate the differences between suacessfull and less successful e-commerce solutions. This could be looked upon fiom a number of different points of view from architectural issues to customer's pattems of interaction in business-to-customer e-commerce, Furthermore, there is the issue of business-to-business e-commerce. In this area, it may be possible to deal with organisational patterns for inter-organisational processes and virtual organisations. Other types of patterns, such as business process patterns for inter- organisational business processes, may also be of interest from the business-o-business point of view, Inter organisational work could possibly be described in terms of cooperative patterns. In what ways can the concept of pattems be extended to comprise virtual organisations and e-commerce? ‘The first thtee problem areas form the most promising ateas for further research and will therefore be accounted for in more detail. Firstly, they have many points of contact, which indicate that it could be possible to find interesting research issues. These areas also have a foundation in current research and practice. For example, numerous ISE methods aim at integrating the use of components and components, and patterns can thus form a powerful combination. The issue of management and reuse of knowledge in organisations still has to be further addressed. 5.3.1 Patterns and ISE methods Although the idea of using patterns is quite widespread in a number of different areas it seems that there is hardly any explicit reference to the use of patterns in most information systems engineering methods. This could be an area of interest, to integrate the use of pattems in methods engineering, The main issue to be resolved is: How can pattems be used/reused? ‘There are a number of pattem types claiming to deal with problems in the early phases, of the IS life cycle. However, Wohed (20006) claims that there is little or no use of patterns in these phases. If this is the case, one reason may be that there is a lack of oDiscussion method support for patterns. The work within the area of patterns and ISE methods calls for an evaluation of how different types of patterns can be used in ISE methods, There are two major objectives: 1) To establish an instrument for the assessment of ISE methodologies with respect to pattems, 2) To perform an evaluation, both theoretical and practical, in order to validate this instrument. One possible goal with incorporating pattems into ISE methods is to increase the efficiency of the method. There are a number of different types of pattems, which can. be used in combination with any ISE method. This raises questions about how different patterns may be combined; what combinations of pattems that are efficient; and what combinations of pattems there are that would actually make the ISE method less efficient, In other words, there is a need for guidance in the use of pattems in the development process. Whichever way we choose to look at it, we still have to deal with the problem of how to present patterns. Process pattems, as presented by Ambler (19986), have much in common with typical information system engineering, In that case, a Process pattern is merely an alternative way of describing the phases in a method. Thus we have to deal questions that arise when a method is to be presented, An information system development method can be described as a process for developing an information system. If this process is described in terms of pattems, as done by Ambler, the difference between a method and a process patter is merely the form of the description. In fact Ambler’s process pattems describe away of working when developing software, There are a number of guidelines, the patterns, related toa number of model types that are produced in different stages of the life cycle. What about the way that these guidelines are described? The models used to describe a pattem (e.g. Figure 14) can be seen as a rather static way of describing the process of modelling Use-Cases. Is this really the way that developers work when they perform this task? King (1997) discusses the fact that information system developers have adopted methods and tools that have proven successful in software engineering. ‘The underlying assumption is that organisations can be engineered in a similar way to software. If this is the case, what are the implications for progess patterns as discussed in this dissertation?Discussion ‘Component-based development has been proposed as a solution to many of the problems faced by software development, Component-based development has evolved from the object-oriented paradigm of programming. In fact Coad (1992) discusses whether pattems can be standardised into larger units and become building blocks for design and construction. Pattems may be of use for describing components and how they may fit together. In this context it would be interesting to find out how ISE methods support the use of pattems and components and how such approaches may be further elaborated. This line of work would call for a careful and detailed study of an information systems engineering process in order to find out what is done in the different phases and how the use of pattems can contribute in various problem situations. It is possible to view the reference models, which are used by ERP? vendors as a type of pattern. They have similarities to e.g. analysis pattems. These reference models are used to develop an organisation being to use the ERP functionality provided by the ERP system, In fact, ERP vendors typically provide a method for implementing their system. A question of interest in this context is: In what ways can ERP systems be considered as examples of how pattems are brought to organisations? 5.3.2 Tool Support for Patterns Issues conceming tool support for patterns are closely related to the area of patterns and ISE methods. The area of pattems and tools can be looked upon in at least two ways: Firstly, the issue of how tools can support the use of pattems and secondly, patterns for the choice of tools (ie. what tools are good for what situations?). The issue of interest in this work is to investigate how the tools used in the ISE process can support the use of patterns. AA first step on this route would be to investigate what has been done on tool support for the use of pattems. For example, UML provides a patterns symbol, which could indicate that there are tools planned to support the use of pattems to some extent. What kind of tool support is needed in order to utilise the use of patterns in Information ‘Systems Engineering? The question about incorporating pattems into ISE methods > Enterprise Resource Planning,Discussion raises questions about tool support for pattems and pattem repositories. One major issue ‘would then be to create a pattem repository, Buschmann and Meunier (1995) discuss a description scheme that goes beyond the problem-context-solution triple. One intention of such a description scheme is to support the selection of pattems, Finding the characteristics of the types of pattems that are used in the different phases of the information systems life cycle and finding out what types of problems they would belp to solve are important issues concerning the selection of pattems. ‘Anextended description scheme could also be used in order to relate pattems to each ther (compare with section 5.3.3). Zimmer (1995) proposes an interesting classification scheme for the relations between the design pattems presented by Gamma et al. (1995), which categorise the relationships into three categories. A similar categorisation scheme could be used when relating pattems within other groups to each other as well as when. relating different types of pattems to each other. Finding relevant attributes that describe different types of patterns and relating them to each other is an important task in creating pattem repositories. A possible outcome of this work is a prototype showing how a pattems repository could be integrated into the ISE process. Another interesting approach is to propose a scheme for the integration of pattems into an existing CASE tool. There is support for patterns, at least to some extent, in madem CASE tools. This support mainly deals with repositories for the reuse of conceptual models or parts of conceptual models. However, there is 2 lack of support for other types of patterns. 5.3.3 Extracting, Documenting, and Representing Patterns ‘The area of research presented in this chapter has to do with the pattern form itself, ic, the style of writing pattems and presenting them. ‘There isa critique against using pattems describing them as canned solutions. This critique indicates that there is a need to investigate possible ways of guaranteeing the quality of pattems, meaning that the whole process of creating and using pattems needs to be studied, Furthermore, patterns cannot be used without thorough analysis since there is a risk for applying unfeasible solutions. Since pattems are meant to transmit solutions that are proven to work, the way of extracting this knowledge from experienced practitioners becomes interesting. Is finding patterns a matter of observing the world and reporting the result or is a more systematic oDiscussion way of working desirable? It is also a matter of making sure that the solutions described in the pattems are the right ones. It is also a matter of making sure that the solutions described in the pattems are the right ones, that they are found on a sufficient level of abstraction, and that they deal with the right type of problems, The process of extracting and validating a pattem is a process of deciding when a pattern becomes a pattern. Alexander et al. (1977) uses a classification scheme where the confidence of the pattem is described using stars (*#°). Three stars mean that the pattem is considered to be reliable. The process of extracting pattems has been described to some extent by, e.g. ELEKTRA (1998c) and Dewar et al. (1999). ‘The concept of pattem languages has been discussed in this dissertation. There are different ways of presenting a pattern language in order to provide a good overview and understanding. One issue of concem is how to find the appropriate pattem fora certain situation. Ifa pattem is not applicable in the situation where itis used, there is a risk of ending up with a worse solution than otherwise. One possible way to present a pattem language is in terms of a road map, ie. in the form of a graph. Figure 21 and Figure 22 may give an indication about the problems with a road map of pattems, Even though the number of pattems is rather small, the picture is overwhelmed with details. This problem could be dealt with in at least three ‘ways: The first way is to split the big map into a number of smaller ones. This could look like Appendix C. One problem with this approach is that the gain in clarity is done at the cost of overview. For example, there is a problem in seeing what connections there are to the end nocks in all the models in Appendix C, Another option is to abstract a number of smaller pattems into categories and relate these to each other and thereby forming a road map at a higher level of abstraction. A third way may be to reduce the number of relations between the different pattems in a similar way. This dissertation has showed that there are a vast number of different types of pattems covering many different areas of knowledge. If these different types of pattems are to be presented in a road map fashion, which would preferably be done at a high level of abstraction, the second option seems most feasible. “The approach taken by Gross & Yu (2000) may be interesting in relation to the question of bow pattem languages may be formalised, What are the links between the patterns in a patter language?Discussion It is not only the presentation of the pattem language that may constitute a problem. The ‘ways that the patterns themselves are presented vary, The different pattern authors presented in this dissertation represent different ways of presenting their pattems. The best way of presenting pattems is not obvious. ‘These variations in describing pattems may be due to the fact that different types of pattems are meant to solve different types of problems. However, it would be interesting to investigate how the presentation of a pattern can be optimised in orckr to be more efficient in conveying knowledge. It is probably the case that the ways of presenting a pattem vary with respect to the intended user. If the assumption that there is a need for different types of patterns in different phases of the life cycle holds, question like the ones below become interesting: © Which type of representation is good for what purposes? * How does the way we represent pattems affect their usefulness? * Inwhat ways can different types of pattems support the diverse views of the different actors/stakeholders in the information systems life cycle? 5.4 Concluding Remarks Why is classification of the type made in this project of interest for the areas of future work that will be identified in this chapter? Primarily, the different classification schemes will serve as foundation for the further analysis of pattems, which will be required in all of the possible areas of research. The classification schemes can also serve asa taxonomy that can be used when reasoning about pattems, Furthermore, the classification with respect to the life cycle stages will be useful in the incorporation of patterns into ISE methodologies. In order to make effective use of patterns, there is a need to maintain a pattem repository. This calls for a solution of how to classify pattems as well as a common concept for describing different types of pattems. There is no common idea of what a patter is, thus a categorisation/classification is needed in order to make a repository possible. To what extent have the objectives of this dissertation been met? There is a difference between a more formal classification scheme and a road map that relates different patterns to each other (Buschmann & Meunier, 1995). The approach taken in this work is more of a road map approach than a formal classification scheme. However, the @oDiscussion initial objectives of this work were to conduct a literature survey; define the concept of patterns; outline a classification of pattems; relate different types of patterns to each other; and discuss how different types of pattems relate to the information system life cycle, The road map approach has been a useful one in order to achieve these objectives. Another advantage with the approach taken in this work is that it gives a ‘good overview of the types of pattems identified in the literature survey. ‘The last objective to be met in this dissertation is to identify areas for future research, ‘This objective is met by the identification of five possible areas of research, which have been accounted for in section 5.3.References References Alexander, C. (1979) The Timeless Way of Building, Oxford University Press, New York. Alexander, C., Ishikawa, S. and Silverstein, M. (1977) A Pattern Language, Oxford University Press, New York, Allen, P, and Frost, S. (1998) Component-Based Development For Enterprise Systems Applying the SELECT Perspective, Camebridge University Press, Camebridge. Alter, S. (1999) Information Systems a management perspective, Addison-Wesley, Reading, Massachusetts, Ambler, S, W, (1998a) An Introduction to Process Pattems. An AmbySoft Inc. White Paper Last Accessed 2000 04 = 04 Ambler, S. W. (1998b) Process Patterns Building Large-Scale Systems Using Object Technology, Camebridge University Press, Camebridge. Appleton, B, (1997) Patterns and Software: Essential Concepts and Terminology Last Acoessed 2000 0411 < Avison, D. E, and Fitzgerald, G. (1995) Information Systems Development: Methodologies, Techniques and Tools, The McGraw-Hill Companies, London. Booch, G. (1994) Object-Oriented analysis and design with pplications, Addison Wesley Publishing Company, Menlo Park, Califomia. Buschmann, F, and Meunier, R. (1995) A System of Patterns, In Pattem Languages of Program Design, (Eds, Coplien, J. O. and Schmidt, D.C.) Adison-Wesley Publishing Company, Reading, Massachussets, Coad, P. (1992) Object-Oriented Patterns Communications of the ACM, 35, 152-159. Coplien, J. (1997) Organizational Pattems Last Accessed 2000 ~ - 26 Coplien, J. O, and Schmidt, D. C. (Eds.) (1995) Pattern Languages of Program Design, Adison-Wesley Publishing Company, Reading, Massachussets, 1References Dewar, R., Ashley, D, L., Poley, R. and Stevens, P, (1999) In EE Proceedings = Software, Vol. 146 n0 3 , pp. 145-152, Duell, M. (1997) Non-Software Examples of Software Design Pattems Last Accessed. 2000-03-20 ELEKTRA (1998a) Generic Patterns: The Silver Bullet? KTH, Stockholm. ELEKTRA (1998b) The Pattern Usage Framework UPI, UMIST, Manchester, Paris. ELEKTRA (1998c) The Pattems Model KTH, Stockholm, ELEKTRA (1999) , Vol. 1: Pattern Development UMIST, Paris 1, KTH, Manchester, Paris, Stockholm. Eriksson, H.-E. and Penker, M. (2000) Business Modeling with UML Business Patiems at Work, John Wiley & Sons, New York. Fowler, M. (1997) Analysis Patterns Reusable Object Models, Addison-Wesley, Menlo Park, California. Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995) Design Panerns Elements of Reusable Object-Oriented Software, Addison-Wesley Publishing Company, Reading Massachussets. Gross, D. and Yu, E. (2000) ) From Non-functional Requirements to Design through. Patterns In REFSQ Stockholm. Hay, D. C. (1996) Data Model Patterns Conventions of Thought, Dorset House Publishing, New York. Kiepuszewski, B., van der Aalst, W. and ter Hofstede, A. (2000) Workflow Patterns Last Accessed 2000 14/9 King, S. (1997) Information and Software Technology, 39, 323-330. Larman, C. (1998) Applying UML and Patterns An Introduction to Object-Oriented Analysis and design, Prentice Hall PTR, New Jersey. Nilsson, A. G. (1995) Utveckling av metoder for systemarbete - ett historiskt perspektiv Institutionen for Datavetenskap, Linkiping. Pohl, K. (1994) The three dimensions of requirements engineering: a framework and its application. Information Syst. 19, nDReferences Rising, L. (2000) Pattems: A Way to Reuse Expertise Last Accessed 2000-03-20 - Robertson, S. and Strunch, K, (1993) In Second Intemational Workshop on Software ReusabilityLueca, Italy. Rolland, C., Stima, J., Prekas, N., Loucopoulas, P., Persson, A. and Grosz, G. (2000) Evaluating a Pattern Approach in CAiSE 2000, Vol, 1789 (Eds, Wangler, B. and Bergman, L.) Springer, Stockholm, pp. 176-191. van Gigch, J. P. (1991) System Design Modeling and Metamodeling, Plenum Press, New York, Wangler, B. (2000) Lecture notes fiom the course Information Systems Engineering University of Skovde, Department of Computer Science. Skivde Wohed, P. (2000a) Conceptual Patterns for Reuse in Information Systems Analysis In CAISE 2000, Vol. 1789 (Eds, Wangler, B, and Bergman, L.) Springer, Stockholm, pp. 157-175. Wohed, P. (2000b) Schema Quality, Schema Enrichment, and Reuse in Information Systems Analysis Department of Computer and Systems Sciences Stockholm University/Royal Institute of Technology, Stockholm. Zimmer, W. (1995) Relationships between Design Patterns, In Patten Lanuages of Program Design, (Eds, Coplien, J, O. and Schmidt, D.C.) Adison-Wesley Publishing Company, Reading, Massachussets,Appendix A Appendix A ‘Appendix A gives an example of a Business Pattem (Eriksson and Penker, 2000), or to be more precise, a resource and rule pattern. Actor-Role Intent ‘The Actor Role pattem provides guidelines for using actor and role concepts, including how they should be separated and how they can be combined. Motivation Anactor is someone or something that functions on its own, such as a machine ora person. You can employ actors within a company. A role describes an actor taken by the actor, You cannot employ the role; itis defined and owned by the company or organization that uses it, For example, IBM employs Eric as a vice president of training; thus, Eric is an actor playing the role of VP of training. Anactor can have more than one role at the time, and the same role can be played by more than one actor. For example, one person can play the roles of a switchboard operator and receptionist at the same time; conversely, a number of different people {actors) can play the role of switchboard operator and receptionist. There are also situations in which two or more roles can be played by one person, though not simultaneously. For example, one person may play the role of a manager, whose job is to confirm incoming invoices. That same person may also play the role of a bookkeeper whose job is to book the invoices. However, this person, who can and is allowed to play both roles, cannot play them at the same time because be or she should not be responsible for both booking and confirming incoming invoices. The Actor-Role pattem makes it easier to model and describe the rules for such occasions, which can be very hard to model if the actor and the role are not properly separated. Another example is a system that handles sensitive data (such as strategic or military information) where the roles of system operator and system administrator need to be separated, because a system administrator adds or removes user accounts to the system, ‘whereas a system operator has access to data within the system. In this case, that has had the role of system administrator can never take on the role of system operator, because one would like to avoid the risk of a system administrator who creates an account for him- o herself and thus gains access to sensitive data. In this example, separating the roles eliminates a security risk. ‘A third use for the Actor-Role pattem is when an actor needs to be matched to different roles. Roles and actors have different attributes. Actors have attributes that describe competence, knowledge, and experience. Roles have attributes that describe operational directions (such as responsibility or the security level attached to that role) and, often, requirements for the actors who play those roles. These requirements can be based on. the actor's defined attributes-his or her competence, knowledge, and experience. This pattern helps to identify which actors are most qualified or even permitted to hav certain roles. If rules are assigned to different roles and there is no separation of actor and role, the rules are difficult or even impossible to express because a single entity involves both the m4Appendix A actor and the role, If the actor has several roles, there isa big risk that the roles will be simply lost in the model, or that the actor will be defined as having an aggregated role that may become very specialized for that actor and be intermingled with the actor’s attributes. The distinction of different roles becomes lost because the roles are not separated from the actors that play them, As stated, if in a military system that handle sensitive information the roles of system administrator and system operator are not separated, the system administrator can give hime or herself access to sensitive data and become a serious security hazard. Applicability ‘The Actor-Role pattem can be used in all problem situations in which there is a need to separate the actors from the roles. For example, a business rule fora bank could be that all large withdrawals must be approved by the bank’s office manager. But if the roles of office manager and bank clerk are not separated, and an actor is defined as just “employed ina tank,” it would be hard to express precisely which actors are allowed to approve to large withdrawals. The ActorRole pattem separates the bank emploee actors from the roles of office manager and bank clerk. Consider this example: In the healthcare industry, it may seem inappropriate for a surgeon to be also an assistant surgeon, Nevertheless, there may be situations in which an actor who is a surgeon may also work as an assistant to another surgeon. The actor in. this case has several roles, which are mutually exclusive. The ActorRole pattem models the actor (the Actor class), the different roles (the Role class) and the business rule to ensure that they are mutually exclusive (Actor-Role connection rule). Structure =| Context | * a exis in a is defined for Actor | * — physa > [Roe | Possible | ActorRole Connection = A restict Actor Role (Connection Rule Figure 36, The ActorsRole patter’s structure. ParticipantsAppendix A Context is the situation in which the actors exist and for which the roles are defined. The context in some way describes the situation, for example, with attributes such as working pace, work environment, or obligation of confidentiality. Actor class describes the actors. It can be people, machines, or similar items, The Actro class can have attributes such as competence, knowledge, skills, age, and culture; it can be specialized into subclasses. Role is a description that tells the actor how to function in a particular context. Typical characteristics associated with role are degree required or competence required. Role can also be specialized into subclasses. Possible Actor-Role Connection expresses possible or allowed connections between actors and roles. Though there may be connections or combinations of connections that are prohibited, the Possible Actor-Role Connection class expresses only those Connections that are allowed. Actor-role Connection Rule is the basis for the Possible Actor-Role Connection class, Objects can be defined as regular logic, that is, XOR and AND. The XOR rule means that only one of several possibilities is allowed at a certain point in time; AND means that all associated roles must be played at the same time. Consequences ‘The Actor-Role pattem enables the easy separation of actors and their attributes from the roles that they play. The roles are defined for a certain context, usually by a specific organization. One advantage of using the Actor-Role pattem is that you can identify roles that cannot be played at the same time by the same actor, along with certain actor requirements that are dependent upon the roles played, Using this pattem also makes it possible to locate and define certain connections, such as that a certain actor can play & set of roles in one context but not in another. NOTE If the Actor-Role pattern is always used in situations where a one-to-one relationship exists between the actor and the role, the using the Actor-Role pattern will lead to the definition of more classes than necessary and possibly make the modd more complex. Example Figure 37 shows an object diagram in which the context is a lottery. The lottery is an object of the Context class; there are three actors within the context: Miller, Smith, and ‘Mellbom. The possible roles within the context are lottery cashier (selling lotteries and handling payment), lottery participant (buying lotteries), and lottery manager (the person who amranges the lottery). ‘There are potential connections between Miller and the roles of lottery cashier, lottery participant, and lottery manager, meaning that Miller at some point in time can perform one or more of those roles. However, the Action-Role Connection Rule (XOR) states that the roles of a lottery participant and lottery manager cannot be played simultaneously - only one of the roles referenced can be valid at a time. This rule expresses the important constraint that a lottery manager cannot participate in his or her own lottery, a constraint that can possibly be enforced upon the model by legal means. This object diagram shows that the actor Smith can play the roles of lottery cashier and lottery participant and that the actor Mellbom can only have the role of lottery participant.Appendix A Object diagrams are used to exemplify a class diagram (in this case, a class diagram that shows a pattem at a certain moment or in a specific use); they express a snapshot of a real situation, Figure 37 is an object diagram for the pattem structure depicted in Figure 36, It contains only the rules that are the objects of the classes — Possible Actor-Role Connection rule — and not the links between the actors and the roles. In other words, this object diagram shows a situation in which actors and roles can be but are not yet connected to each other, Lowen Chess Rite Acar ‘Miler: Actor Teikaae Xone BieConmsticn Rue Loueey Panicpane Roie Tei ae Lote Manas Rue ‘Sin: Actor ‘Posshle Awe Malone Acker ‘Posshle Awe i Figure 37, An object diagram for the class diagram shown in Figure 36 In Figure 38, another object diagram, the actual connections between the actors and the roles have been added. In it, the actor Miller now plays the role of lottery manager, actor Smith plays the role of lottery cashier, and actor Mellbom has the role of lottery participant.Appendix A Aniticawe akComicn Millers Acer ReGmeis OK: AoE ‘Buk Lossy atin Rete Bsc Acare fokComin Lory Manag Rok ‘Sic Aor _— ‘Sips he oe Ambon Iowa casio RokeGmsstion L Malan Actor Pash Aone ke Cnet Maer plps treks Kueryrasicrne Figure 38, An object diagram that shows how actors and roles are connected ata certain moment ina cerain context. Related Patterns ‘The Actor-Role pattem can be combined with the Organization and Party pattern, discussed later in this chapter, typically by creating an association from the Role class in the Actor-Role pattem to the Organization Unit class in the Organization and Party pattern, then by connecting and defining it’s a specific part in the organization. For instance, in the lottery example, the roke of lottery manager can be assigned to the Power Ball, Lotto, or Keno organizational units; each unit handle a specific type of lottery, and each lottery manager is connected to one of these units, ‘The ActorRole patter can also be combined with the Employment pattern (also described later in this chapter), in which case the Person class in the Employment pattern would be exchanged with the Actor class in the Actor-Role pattem, For instance BAppendix A the actor/person Smith could have the role as lottery cashier, be employed in the Intemational Gambling Company, and have a position assignment that specifies when be started his full-time employment as a lottery cashier. The role would be modeled in the ActorRole pattem and the employment and position information would be madeled using the Employment pattern, ‘Source/Credit Its origin is unknown, but this pattem las been invoked to model mine-clearance systems used by the United Nations, A description of the concepts underlying this, pattern can be found in Murray r. Cantor’s book, Object-Oriented Project Management with UML (John Wiley & Sons, Inc., 1998),Appendix B Appendix B Appendix B gives an example of an Object Structural Design pattem from (Gamma et al,, 1995, pages 185-193). FACADE — Object Structural Intent Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher level interface that makes the subsystem easier to use, Motivation Structuring a system into subsystems helps reduce complexity. A common design goal is to minimize the communication and dependencies between subsystems. One way to achieve this goal is to introduce a facade object that provides a single, simplified interface to the more general facilities of a subsystem. ert dass FACADE riystemdiases Figure 39. Facade patter illustration. From (Ganima et al., 1995) Consider for example a programming environment that gives applications access to its compiler subsystem. This subsystem contains classes such as Scanner, Parser, ProgramNode, ByteCodeStream, and ProgramNodeBuilder that implement the compiler. Some specialized applications might need to access these classes directly. But mast classes of a compiler generally don’t care about details like parsing and code generation; they merely want to compile some code. For them, the powerful but low= level interfaces in the Compiler subsystem only complicate their task. To provide a higher-level interface that can shield clients from these classes, the compiler subsystem also includes a Compiler class. This class defines a unified interface to the compiler’s functionality. The Compiler class acts as a facack: It offers clients a single, simple interface to the compiler subsystem. It glues together the classes that implements compiler functionality without hiding them completely. The compiler 80Appendix B facade makes life easier for most programmers without hiding the lower-level functionality from the few that needs it. Stuck VahicNode Figure 40, A compiler facade, From (Gamma etal, 1995) Applicability Use the Facade pattem when you want to provide a simple interface to a complex subsystem. Suibsystems often get more complex as they evolve. Most patterns, when applied, result in more and smaller classes. This makes the system more reusable and easier to customize, but it also becomes harder to use for most clients that don’t need to customize it, A facade can provide a simple default view of the subsystem that is ‘good enough for most clients. Only clients needing more customizability will need to look beyond the facade. there are many dependencies between clients and the implementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability. you want to layer your subsystems. Use a facade to define an entry point to each Subsystem level, If subsystems are dependent, then you can simplify the dependencies between them by making them commiunicate with each other soley through their feades. Structure 81Appendix B a Facade Figure 41. Facade structure, From (Gamma et al, 1995) Participants © Facade (Compiler) © knows which subsystem classes are responsible fora request. (© delegates client requests to appropriate subsystem objects. © subsystem classes (Scanner; Parser, ProgramNode, etc.) ©. implement subsystem functionality. ‘© handle work assigned by the Facade object. ‘© have no knowledge of the Facade; that is, they keep no references to it. Collaborations * Clients communicate with the subsystem by sending requests to Facade, which forwards them to the appropriate subsystem objectts). Although the subsystem objects perform the actual work, the facade may have to do eork of its own to translate its interface to subsystems interfaces * clients that use the facade don't have to access its subsystem bjects directly. Consequenses ‘The Facade pattem offers the following benefits: 1. It shields clients from subsystem components, thereby reducing the number of objects that clients deal with and making the subsystem easier to use. 2. It promotes weak coupling between the subsystems and its clients. Often the components in a subsystem are strongly coupled. Weak coupling lets you vary the components of the subsystem without affecting its clients. Facades help layer a system and the dependencies between objects. They can eliminate complex or circular dependencies. This can be an important consequence when the client and the subsystem are implemented independently. Reducing compilation dependencies is vital in large software systems, You want to save time by minimizing recompilation when subsystem classes change. Reducing 82Appendix B compilation dependencies with facades can limit the recompilation needed for a small change in an important subsystem. A facade can also simplify porting systems to other platforms, because it’s less likely that building one subsystem requires building all others. 3. It doesn’t prevent applications fiom using subsystem classes if they need to. “Thus you can choose between ease of use and generality. Implementation Consider the following issues when implementing a facade: 1. Reducing client-subsystem coupling. The coupling between clients and the subsystem can be reduced even further by making Facade an abstract class with concrete subclasses for different implementations of a subsystem. Then clients can communicate with the subsystem through the interface of the abstract Facade class. This abstract coupling keeps clients from knowing which implementation of a subsystem is used, An altemative to subclassing is to configure a Facade object with different subsystem objects. To customize the facade, simply replace one or more of its subsystem objects. ey Public versus private subsystem classes. A subsystem is analogous to a class in that both have interfaces, and both encapsulate something-a class encapsulates state and operations, while a subsystem encapsulates classes, And just as it's useful fo think of the public and private interface of a class, we can think of the public and private interface of a subsystem, ‘The public interface to a subsystem consists of classes that all clients can aacess; the private interface is just for subsystem extenders, The Facade class is part of the public interface, of course, but it’s not the only part. Other subsystem classes are usually public as well. For example the classes Parser and Scanner in the compiler subsystem are part of the public interface, ‘Making subsystem classes private would be useful, but few objectoriented languages support it. Both C++ and Smalltalk traditionally have had a global name space for classes. Recently, however, the C-++ standardization committee added name spaces to the language [S94], which will yet let you expose just the public subsystem classes. ‘Sample Code L... This part of the pattem gives an extensive code example of the facade pattern, which has been excluded from this quotation. | Known Uses. ‘The compiler example in the Sample Code section was inspired by the Object- Works\Smalltalk compiler system [Par90). In the ET-+- application framework. [WGM88], an application can have built-in browsing tools for inspecting its objects at runtime. These browsing tools are implemented in a separate subsystem that includes a Facade class called “ProgrammingEnvironment.” This facade defines operations such, as InspectObject and InspectClass for accessing the browsers. An ET++ application can also forgo built-in browsing support. In that case, ProgrammingEnvironment implements these requests as null operations; that is, they do nothing. Only the ETProgrammingEnvronment subclass implements these requests with operations that display the comesponding browsers. The application has no knowledge 83Appendix B of whether a browsing environment is available or not; there’s abstract coupling between the application and the browsing subsystem. ‘The Choices operating system [CIRM93] uses facackss to compose many frameworks into one. The key abstractions in Choice are processes, storage, and acklress spaces, For each of these abstractions there is a corresponding subsystem, implemented as a framework, that supports porting Choices to a variety of different hardware platforms. ‘Two of these subsystems have a “representative” (Le., facade). These representatives are FileSystemInterface (storage) and Domain (address spaces). Process. | —>} Domain ee virtual memory framework Protect(Memory, Protection) RepaicFaulto AddressTransition — || vemoryObject >| MemoryObjetCache FindMemory(Addlress) BuikiCache() } [ ‘TwoLevelPageTable PersistentStore PageMemoryOjectCache ile Disk Figue 42, Virtual memory framework, From (Gamma et al, 1995) For example, the virtual memory framework has domain as its facade. A Domain represents an address space, It provides a mapping between virtual addresses and offsets into memory objects, files, or backing store. The main operations on Domain support adding a memory object at a pauticular address, removing a memory object, and handling page fault. As the preceding diagram shows, the virtual memory subsystem uses the following components intemally: © MemoryObject represents a chta store. © MemoryObjectCache caches the data of MemoryObjects in physical memory, ‘MemoryObjectCache is actually a Strategy (315) that localizes the caching policy. © AddressTranslation encapsulates the address translation hardware. ‘The RepairFault operation is called whenever a page fault interrupt occurs, The Domain finds the memory object at the address causing the fault and delegates the RepairFault 84Appendix B operation to the cache associated with that memory object. Domains can be customized by changing their components. Related Patterns Abstract factory (87) can be used with facade to provide an interface for creating subsystem objects in a subsystem-independent way. Abstract factory can also be used as analtemative to Facade to hide platform-specific classes, ‘Mediator (273) is similar to facade in that it abstracts functionality of existing classes. ‘However, Mediator’s purpose is to abstract arbitrary communication between colleague objects, often centralizing functionality that doesn’t belong in any one of them. A. mediator’s colleagues are aware of and communicate with the mediator instead of communicating with each other directly. In contrast, a facade merely abstracts the interface to subsystem objects to make them easier to use; it doesn’t define new functionality, and subsystem classes don’t know about it. Usually only one Facade object is required, Thus Facade objects are often singletons 27). 85.Appendix C Appendix C ‘The relationships between the Organisational patterns (Coplien and Schmidt, 1995) described in chapter 3.11 can be divided into a number of smaller models in order to show how they are connected to each other. Appendix C contains a few examples of these relationships. Architectaso Implements Pato 15) cad Omersip eee fatter 1) Pater 10) Engage ‘Qustomers Pane 20) Figure 43. The Code Ownership pattem related to other pattems.Appendix C ‘tiesto Send reegunan Bory Pato) Fabre Lacan ‘fame ratecnge Sppyince rm Tice cago ean eae Ema Pan B each ~ [= | Figure 44, The Engage Customers pattem related to other organisational pattemsFigure 45, Appendix C Engage QA (Patter 18) ‘stores @Patlem 20) ‘Shaping Circulation Reais (Patlem 26) ‘The Engge QA pattem related to olher pattems, Organisation Follows Location (Pate) Famiplions function (Patem 5) (Patlem 10) Figure 46. Engage ‘austomers (Panem 20) ‘The Fo follows function pattem related to other patterns. 88