Association between objects. Thread-of-control. Class/object with methods. between classes. Role class. Method with implementation

Transcription

1 Roles & Patterns in Analysis, Design and Implementation Bent Bruun Kristensen Johnny Olsson Department of Computer Science, Aalborg University Fredrik Bajers Vej 7, DK-9220 Aalborg, Denmark fbbkristensen, Abstract. From a given set of abstraction mechanisms available in a language we form architectural abstractions for example design patterns and frameworks to support reuse of design. From recurring formations in concrete applications we conceive new abstraction mechanisms for example the role mechanism to be included in analysis and design notations as well as in programming languages. Concrete diagrams and programs probably including instances of design patterns have inspired the invention and design of the role mechanism. The role mechanism itself enables us to form new patterns and to revise existing patterns. Patterns to be used in analysis, design and implementation have an identical basic form a general idea to give a solution to a problem in a given context. However, patterns are classied as analysis patterns, design patterns and implementation patterns dependent on which phase in the development process they (best and most natural) support in terms of their level of abstractivity and degree of domain specicity. 1 Introduction Conceptual abstraction mechanisms and design patterns contribute to the further development of object-oriented programming, including the analysis, design and implementation phases. The evolution process of abstraction mechanisms and architectural abstractions is based on mutual inuence. From the available set of abstraction mechanism we form set of architectural abstraction to be reused in programming. The set of mechanisms supports and limits our formation of the concrete architectures, that in turn are further elaborated into abstract formations we turn these into catalogues of architectural abstractions. From available catalogues of architectural abstractions we form concrete applications by using/instantiating these. The recurring formations in the concrete applications inspire our understanding, and enables us to conceive new language mechanisms that capture the essence of the applications. We design language mechanisms, we integrate these into our languages, and we dene and implement them. The role is an example of a new abstraction mechanism based on a general understanding of phenomena and concepts the role is a natural element in our concept formation. Abstraction mechanisms and design patterns are used in object-oriented analysis and design This research was supported in part by the Danish Natural Science Research Council, No

2 ((Booch, 94) and (Rumbaugh et al., 91)) and implementation. Patterns to be used in analysis, design and implementation have the same general form a pattern expresses a general idea to give a solution to a problem in a given context. However, patterns do not address the same kind of problem domain, the context reects the specic domain, and accordingly, the kinds of solutions are dierent too. Patterns are classied as analysis patterns, design patterns and implementation patterns dependent on which phase in the development process they (best and most natural) support in terms of their level of abstractivity and degree of domain specicity. An analysis pattern is able to capture a problem in the application domain. A design pattern captures a problem in the model of the application domain it is a description of communicating objects and classes that are customized to solve a general design problem. An implementation pattern captures a problem the the realization of software in general and design patterns in particular (for which there may be several solutions). This classication of patterns is illustrated by the role mechanism. The role mechanism introduces new analysis patterns to be used in the modeling of an application domain. The role mechanism enables alternative organizations of design patterns it may eventually also introduce new design patterns. The role mechanism gives alternative possibilities for the implementation of design patterns it also introduces additional basic implementation patterns. Analysis patterns can be usable also in the design phase design patterns can be usable also in the implementation phase. Implementation patterns are more domain specic than design patterns, which are more specic than analysis patterns. Analysis patterns are more abstract than design patterns, which are more abstract than implementation patterns. Paper Organization. In section 2 we introduce conceptual abstraction mechanisms and patterns, and outline the evolution process of these. The evolution process is illustrated by experiments from which new analysis, design and implementation patterns originate. In section 3 we present a new analysis pattern based on the role mechanism. In section 4 we discuss the impact of the role mechanism on existing design patterns. In section 5 we discuss the relation between implementation patterns in terms of meta patterns and some general structures extracted form the the use of the role mechanism in design patterns. In section 6 we summarize the results of the paper. 2 Roles & Patterns In this section we discuss a conceptual abstraction mechanism (Kristensen & sterbye, 94), the role, and a category of architectural abstractions (Kristensen, 96), the design patterns. Both roles and design patterns are seen as supplementary abstractions to the class and object notation/language mechanisms that are available in the notation part of the objectoriented analysis and design methodologies and in object-oriented programming languages. In Figure 1, we illustrate the usual organization of an object-oriented structure in terms of (classes and) objects. The static aspect is organized in terms of generalization and aggregation hierarchies of the classes (not shown) as well as client-server relations between the classes, and the dynamic aspect is organized in terms of actual client-server relations between the object (illustrated as associations) as well as the method invocation structure, where a method of one object invokes a method of another, etc. Various possible sources of inspiration and motivation exist for the further development of object-oriented languages. One possibility is the invention of new abstraction mechanisms 2

3 Association between objects Thread-of-control Class/object with methods Figure 1: Object-Oriented Structure based on a general understanding of phenomena and concepts. In this approach we either use the theory on concept formation as the denition in the mapping to language constructs or we explore subconcepts for example role of (the concept) concept as new abstraction mechanisms. Another possibility is to design reusable software elements by identifying recurring patterns in the object-oriented diagrams and programs. A design pattern (Gamma et al., 94) is a description of communicating objects and classes that are customized to solve a general design problem in a particular context. Other types of patterns are described in (Coad et al., 95), (Pree, 95), and (Coplien & Schmidt, 95). Roles. The role concept (Kristensen, 95) is a natural element in our daily concept formation. The concept has already shown useful in object-oriented methodologies (Rumbaugh et al., 91) and languages (Kristensen & sterbye, 96). We classify phenomena such as tennis player, lecturer, etc. as roles of the person concept. In addition to being a usual concept the role is characterized by the fact that it is always dependent on an ordinary (intrinsic) concept and has no identity alone, it can be added and removed dynamically, and the properties of a role are visible for certain clients only (including the properties of the intrinsic concept, but excluding those of other roles for the concept). Class Association between classes Role class Method with implementation Figure 2: Role Classes In Figure 2, we illustrate the role as an alternative to the usual simulation of roles (either by aggregating the roles as usual objects or by roles as specializations of the intrinsic concept). The scheme employs roleication, where a role class is bound to a class, is associated with other classes, and can have methods on its own. The roleication is modeled by the role mechanism similar to the class mechanism, but reecting the characteristics of the role 3

4 as a concept. The term subject is used to denote an object and the role, and intrinsic object refers to the object of the subject. "Role of" link Role of method Figure 3: Role Methods In Figure 3, we illustrate that not only classes, but also methods can have roles. The method of a role class can be a method role for a method of the intrinsic class. The behavioral eect is a combination of the behavior described by the two methods. Reviewer Conference Conference-Associate Participant Paper Person Author Figure 4: Roles of the Role Conference-Associate As an illustrating example, we consider a Person involved in the preparation and/or holding of a conference by adding the role Conference-Associate. This includes several roles, for example as a Participant, an Author, and a Reviewer. These roles then become roles of Conference-Associate roles of a role as illustrated in Figure 4. A method of for example Participant can utilize the methods of Conference-Associate in its description, but not vice versa. We model Participant, Author, and Reviewer as roles of Conference-Associate because the various relations to a given conference are related to these specic roles only (and not to Conference-Associate as a whole): A Participant is related to the Conference; an Author is related to the Paper, and a Reviewer is related to a Paper. An abstraction mechanism such as the role has the following characteristics: (1) It is a well-dened, basic building block. (2) It can be integrated with other mechanisms (for example inheritance and polymorphism) in the language/notation. (3) It can be used in the creative thinking about a problem. (4) Abstractivity in terms of classication, aggregation and specialization is available. 4

5 Patterns. A design pattern (Gamma et al., 94) is a general idea of a design solution to a general basic problem. The structure of a design pattern can be illustrated by a graphical representation of the classes in the pattern. We exemplify design patterns by the Decorator pattern. Component Operation() ConcreteComponent Operation() Decorator Operation() component->operation() ConcreteDecoratorA Operation() AddedState ConcreteDecoratorB Operation() AddedBehavior() Decorator::Operation(); AddedBehavior(); Figure 5: The Decorator Pattern The intent of the Decorator pattern (its structure is reproduced in Figure 5) is to \attach additional responsibilities to an object dynamically. Decorators provide a exible alternative to subclassing for extending functionality". The Component class denes the interface for objects that can have responsibilities added to them dynamically. The ConcreteComponent class denes an object to which additional responsibilities can be attached. The Decorator class maintains a reference to a Component object and denes an interface that conforms to Component's interface. The ConcreteDecorator class adds responsibilities to the Component. Design patterns such as the Decorator pattern are abstract, general design solutions for general classes of problems. Some characteristics of design patterns are: (1) They are informally dened in terms of problem, solution and consequences. (2) They always require instantiation to be mapped into a concrete implementation. (3) They represent interacting parts, systematic structures and relationships. (4) They are not atomic, and their use in design is at a larger level of granularity than classes/objects. Evolution Process. The development process of object-oriented language mechanisms and architectural abstractions can be seen as an evolution process (Kristensen, 96). From notation/language mechanisms we form concrete architectures in diagrams/programs from which we form more general abstractions, architectural abstractions. Inspired from architectural abstractions and other sources as for example concept formation we invent language mechanisms, typically abstraction mechanisms. Two evolution processes are mutually inuencing each other as illustrated in Figure 6: Mechanism Invention: In this process we invent an abstraction mechanism from architectural abstractions, seen as general ideas and solutions to problems (including examples 5

6 Mechanism Invention: Language Mechanisms Abstraction Formation: Language Mechanisms Concrete Applications Concrete Architecture Architectural Abstractions Architectural Abstractions Figure 6: Evolution Processes of abstract pieces of programs). We apply architectural abstractions in actual concrete programs we identify the use of similar architectural abstractions to form similar fundamental and central parts of our programs. Over time we conceive a language mechanism to replace the use of architectural abstractions for the identied purpose. We invent the abstraction mechanism we dene it, we integrate it in our language, and we implement it. A mechanism is designed and dened, including its syntax and semantics as part of a language/notation. The mechanism is supposed to subsume one or more architectural abstractions, and intended to capture a natural element in the abstraction process. At the programming language level the mechanism has a general implementation, hidden by the language implementation. The success of a mechanism depends among others on weather it truly replaces a number of architectural abstractions, weather it is integrated with the rest of the language/notation (especially the other abstraction mechanisms), its naturalness and usefulness in the abstraction process, how comfortable the user is with its implementation, and the eciency of the implementation. Abstraction Formation: In this process, we rst form concrete architectures, next we form more abstract versions of these. By means of language mechanisms we design and construct formations and organizations as concrete architectures including both structure and behavior, at a higher level than what we can express directly by the given mechanisms. From experience with several of such concrete architectures we form more general and abstract formations and organizations architectural abstractions. The success of an architectural abstraction depends among others on how general an idea is captured by the abstraction, how simple and powerful the abstraction is (not cluttered by complicated structure and behavior), if there are many important applications of it, if it can be integrated with other abstractions (is basic and orthogonal with respect to these), and if it is still identiable in the code after it has been applied. The role concept is an example of a possible language mechanism and architectural abstraction that interplays in the evolution process. 6

7 3 Title: Roles in Analysis During the experiments with the role abstraction mechanism several ideas for new patterns have appeared. They are all very simple in nature, inspired from various application domains, and still very immature. A role based pattern, called Title, is presented (Olsson, 96). Title is described as an analysis pattern. Title can also be seen as a new design pattern then with a dierent intent etc. We use an extract from the format of the description of design patterns in (Gamma et al., 94) for our description of Title as an analysis pattern. Intent. To ensure the varying behavior and state, a role representing the behavior and state is handed from one object to another. Motivation. Title is motivated from an example that shows the modeling aspects of this pattern. A city always has a person playing the role as a mayor. When one person stops playing the role as mayor, it is handed over to another person as shown on Figure 7. Mayor Mayor Valdemar Valdemar Gorm Gorm Figure 7: Transfer of the Mayor Role The reference to the mayor is always the same, although the person behind the title changes. The static structure is shown on Figure 8. Mayor Person Figure 8: Illustration of the Mayor Role Applicability. Use the Title pattern in the following case: A title is transferred from one item to another. The varying behavior is separated into interchangeable objects. 7

8 Structure. In its general structure, the Title role may be attached to specializations of the Component class, see Figure 9. Title Component Concrete ComponentA Concrete ComponentB Figure 9: The Title Pattern Participants. Title { denes the varying behavior and state for the subject (intrinsic object and role). A references to the subject is a reference to the role instance. Component { the interchangeable part of the subject. { implements the behavior of the object. ConcreteComponent subclasses { each subclass implements the concrete behavior of the object. Collaborations. Title handles the static methods of the subject. Title is the interface for the client. A ConreteComponent handles the varying behavior of a subject. A clients request for methods not in the interface of the Title object is implicitly handed to the ConcreteComponent object. The Title role is forwarded to another object either by the client or the ConcreteComponent. Consequences. The varying behavior is separated and organized in a generalization hierarchy. Many Component objects may be created. An alternative to subclassing. 8

9 Implementation. The pattern is implemented as a role class and a specialization hierarchy of the Component class. One implementation concern is which object handles the transfer of the role from one object to another? If the change of object is handled by the delivering Component object, then it needs a reference to the role, and a reference to Title has to be given to the receiving object. When change of object is handled by the client, the object does not need a reference to its role. 4 Roles in Design Patterns As mentioned Title can also be dened as a new design pattern (with a dierent description than the one given in the previous section) but with an identical structure. However, in general we have not invented new design patterns based on the role mechanism. Instead, we have inspected some existing design patterns in order to construct alternative descriptions of these by utilizing the role mechanism (Olsson, 95) and (Olsson, 96). This is because the role mechanism is not yet a part of common programming languages. We have selected 3 design patterns, Strategy, State and Bridge, each of which gives alternative insight into the possibilities of the role mechanism. Finally, we compare the role mechanism with its closest counterpart among the design pattern, the Decorator. 4.1 Strategy This section contains a short description of the Strategy design pattern, followed by an examination of how a structure based on roles may simplify the structure of the Strategy pattern. 1. Intent: Dene a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. 2. Applicability: (a) When many classes dier only in their behavior (dierent algorithms). An alternative to subclassing. (b) The algorithms can be changed dynamically. (c) The algorithm uses data that clients should not know about. (d) Behavior of classes separated into classes. statements. 3. Structure: See Figure Consequences: (a) Families of related algorithms. (b) Greater exibility and more reuse. (c) Choice of implementation. (d) Client must be aware of dierent strategies. (e) Creation overhead for Strategy objects. An alternative to large conditional (f) Communication overhead between Strategy and Context objects. 9

10 Client AlgorithmForward strategy Algorithm Strategy Context StrategyA StrategyB StrategyC Figure 10: The Structure of Strategy Application. The Strategy pattern is applied in an example with mathematical computation. An integral function takes rst order functions and an interval as arguments and compute the numerical value of the integral in the interval. The integral function has dierent strategies for the numerical computation. The choice of strategy is due to criteria such as precision and time constraints. Strategy is applied as follows: the Integral class takes as arguments a function and the interval for which to compute the integral. Integral has a method SetStrategy to set the strategy for an Integral instance. Invoking an Integral object implies an invocation of a default astrategy object to perform the actual computation of the integral value. Integral delegates the function and interval to its instance of a astrategy. The strategies for calculating the integral value are relatively simple and do not dier much in computation, so the criteria for choosing one or another are not important here. The purpose is to show the principles of Strategy. The structure of the Integral class and its computation strategies are shown on Figure 11. Client IntegralValue astrategy Value Strategy Integral SumLeftBar Sum CenterBar SumLeft RightBar Figure 11: Example of an Application of Strategy Restructuring. Figure 12 illustrates an alternative structure for Strategy with roles. The Integral class is implemented as a role bound to one of the Strategy classes. The Integral method Value is a method role of the method Value in the Strategy class (if Value in Integral is not a method role of a method in Strategy then Strategy needs at reference for the Integral role). In the following the structure is examined. 10

11 Client IntegralValue Value Integral Strategy SumLeftBar SumCenter Bar SumLeft RightBar Figure 12: Restructuring of Strategy 1. Intent: Algorithms are encapsulated and interchangeable independent on the client { unless at instantiation time where the client has to declare the initial strategy. 2. Applicability: (a) The varying behavior is separated into interchangeable objects. (b) Algorithms can be changed dynamically. (c) Data is hidden to the client. (d) Simple and exible structure. 3. Consequences: (a) Algorithms are related in a role generalization hierarchy. (b) The reuseability and exibility is the same as in the original structure. (c) An algorithm may have several implementations. (d) Clients can vary the strategy role. (e) Many strategy roles can be created. (f) The communication overhead is less than in the original structure. Change of strategy is a transfer of the Integral role to another Strategy object. The main problem with this structure is that the Integral role cannot have strategies for more than type of computation, because the role can only be a role of one type of strategy. 4.2 State This section gives a short description of the State pattern and examines an alternative structure for Strategy. 1. Intent: To allow an object to alter its behavior when its internal state changes. The object will appear to change its class. 2. Applicability: 11

12 (a) When an object's behavior depends on its altering state. (b) To avoid operations with large conditional statements that depend on the object's state. 3. Structure: See Figure 13. Handle Handle state State Context Concrete StateA Concrete StateB Figure 13: The Structure of State 4. Consequences: (a) State specic behavior is localized and delegated to separate objects. (b) State transitions are made explicit. (c) State objects can be shared. Deposit Withdraw Deposit Withdraw state State Account Observation State Normal State Credit State Figure 14: Illustrating Example of State Application. The illustrating example of the State pattern is a bank account example. An account class, Account, has a balance showing the amount of money on the account and methods for withdrawing and depositing money. Depending on the balance, the account has dierent states such as observation state if the balance is low or below zero, credit state if the owner of the account has a good repute, and normal state. Each state gives the WithDraw and Deposit methods of the Account class a certain behavior. For instance in the observation state, WithDraw limits the amount to withdraw. Each state and its specic behavior is separated from the Account class into some State classes, see Figure 14. WithDraw and Deposit requests are forwarded to the actual State class which handles the request and eventually change the state (the balance) of the account. 12

13 Restructuring. Figure 15 shows a structure where the states are represented as roles of the Account class. A client knows an account through one of the State roles. Client WithDraw Deposit State Account Observation State Normal State Credit State Figure 15: Restructuring of State 1. Intent: The object really changes its class, because its change of state is achieved by changing the role by which it is accessed. 2. Applicability: (a) The (intrinsic) object remains the same, when the role changes. (b) Delegation of state-specic behavior to individual classes is possible. 3. Consequences: (a) State specic behavior is localized and put into one object. (b) State transitions are made explicit by change of role. (c) State objects cannot be shared, because a State role can only be role of one object at a time. Communication overhead between State and Account is minimized, because the original explicit forwarding mechanism is avoided. The main problem with this structure is that the client is involved in the change of state. 4.3 Bridge This section gives a short presentation of the Bridge pattern, followed by an examination of an alternative structure for Bridge. 1. Intent: Decouple abstraction and implementation to let them vary independently. 2. Applicability: (a) Avoid permanent binding between abstraction and implementation by splitting these into two classes. 13

14 (b) Both abstraction and implementation should be extensible by subclassing. (c) Changes in the implementation of an abstraction should have no impact on clients. (d) Sharing of implementation by abstraction classes. 3. Structure: See Figure 16. Operation OperationImp Abstraction imp Implementor Refinded Abstraction ConcreteA Implementor ConcreteB Implementor ConcreteC Implementor Figure 16: The Structure of Bridge 4. Consequences: The consequences of the pattern are all implicitly described under the applicability. Application. Consider the implementation of a portable Window abstraction in a user interface toolkit. This abstraction should enable us to write applications that work on both the X Window System and IBM's Presentation Manager (PM). An abstract class Window may abstract over the platform-specic implementation subclasses XWindow and PMWIndow. Furthermore, the Window abstraction should cover dierent kinds of windows. However, it is inconvenient to let the Window abstraction cover both dierent kinds of windows and platforms. To support an IconWindow specialization of the Window class for both platforms, two classes have to be implemented: XWindowIcon and PMWindowIcon. Bridge solves this by putting windows abstractions and implementations into separate classes, and let them vary independently. A request to a window abstraction class forwards the request to its actual implementation class, see Figure 17. DrawText DrawRect DrawText DrawLine Abstraction imp WindowImp DrawBorder DrawCloseBox IconWindow Transient Window XWindow Imp PMWindow Imp Figure 17: Example of an Application of Bridge 14

15 Restructuring. The restructuring of Bridge is a generalization of the restructuring of State and Strategy. In Figure 18 this structure implies that abstraction-classes are implemented as roles, and implementation-classes as classes. DrawText of Abstraction is a method-role of the same in WindowImp. DrawRect applies DrawLine in WindowImp to draw a rectangle. DrawRect DrawText DrawText DrawLine Abstraction WindowImp DrawBorder Draw CloseBox XWindow Imp PMWindow Imp Icon Window Transient Window Figure 18: Restructuring of Bridge 1. Intent: Abstraction and implementation are decoupled, and they can vary independently. 2. Applicability: (a) No permanent binding between abstraction and implementation. (b) Both abstraction and implementation are extensible by subclassing. (c) Implementations are hidden to clients. (d) Abstractions may share an implementation. 4.4 Roles and the Decorator Pattern In this section the role mechanism is used to model the Decorator design pattern. This comparison is interesting because among the design patterns the Decorator is the one that best captures the properties of the role mechanism. 1. Intent: See description in section Applicability: (a) When extension by subclassing is impractical. (b) For responsibilities that can be withdrawn. 3. Structure: See Figure Consequences: 15

16 (a) Avoid subclass explosion. (b) Recursive nesting allows multiple responsibilities. (c) A component and its component are not identical. (d) Run-time overhead in space and time. Write VirtualPrint Print Decorator component BoxPrint Special Underline Print Underline Print Figure 19: Example of Use of Decorator Application. An example of using Decorator is a Windows system, where Print is a window class for leaving messages to the user like in the Console Window in the X Windows System. Print has one method Write sending a text-string to the window. The Print window might change style of its output formatting, for example, important message may be underlined or written in a text-box. This additional behavior of the Print class is controlled by attaching Decorators to Print and change the reference for the output-window to a Decorator object. Additional behavior of the Print window may be added successively by attaching more decorators in a chain structure. The class structure of this example is shown on Figure 19. Restructuring. Because the Decorator pattern has a another basic structure than the other patterns examined another restructuring is considered. Figure 20 shows a role based structure of Decorator. 1. Intent: Responsibilities can be attached dynamically to an object, however, only one additional responsibility can be attached. 2. Applicability: (a) The structure is an alternative to subclassing. (b) The responsibility can be withdrawn and another can be attached. 3. Consequences: 16

17 Write Write Print Decorator BoxPrint Special Underline Print Underline Print (a) Subclass explosion is avoided. Figure 20: Restructuring of Decorator (b) A component and its decorator have the same (intrinsic) identity. (c) Run-time overhead in space and time is limited. Because the structure allows only one additional responsibility it does not satisfy a very basic demand of the pattern. To summarize, design patterns such as State, Strategy, and Bridge can be restructured into role-based structures with various benets. This indicates that the role abstraction may introduce new design patterns. 5 Roles in Implementation In the previous section we have examined the use of the role mechanism for alternative structuring of design patterns. From the examples some common, basic structures have been identied. These common structures are potential general implementation structures. Meta patterns (Pree, 95) can be seen implementation patterns too dening some terminology and principles for the implementation of software in general, but for design patterns in particular. This section relates the common structures from the previous section to the composition techniques for meta patterns. The purpose is to investigate the potential of the role mechanism for implementation support (Olsson, 96). Strategy, State and Bridge can all be described by the 1:1 Connection meta pattern. This section elaborates on this by describing the common structures from the previous section by the 1:1 Connection pattern. All structures are based on one role bound to an object. The meta patterns are concerned with (terminology and principles of) single classes or groups of classes together with their interactions. A template method is a calling method and the hook methods are the methods called. A given method can be both a template method and hook method, depending on the other method considered. The concept of template and hook methods is independent of the distribution of the methods between classes. A class containing a template method is a template class and a class containing a hook method is a hook class. 17

18 Implementation Structure I. In its general version, Structure I is related to the 1:1 Connection meta pattern as shown on Figure 21. The varying behavior of a class is decoupled and arranged in a generalization hierarchy. The change of behavior is performed by the client. 1:1 Connection metapattern T href H T() H() Template Hook Figure 21: Structure I. 1:1 Connection Pattern This structure does not use delegation to handle the varying behavior, because the varying behavior is placed outside the object in a role. In the original design patterns, the template class delegates responsibility to the current hook class. Structure I's division into the role class as a template class and the intrinsic object as the hook class is less obvious, because the role does not necessarily use methods of the hook class. That depends on the specic application. In Section 4.3, it is shown that Bridge is a decoupling of the independently varying abstraction and implementation. Structure I can be related to Bridge in that respect that Structure I is varying its abstraction, while the implementation remains the same. Behavioral change of a subject applying Structure I is reected in a change of class of the subject. Structure I means less communication between the role and the object compared to the original structure. If the intrinsic object needs to the apply varying behavior, the object needs a reference to the role. A main problem with Structure I is that a change of behavior require the client to change a reference, because the varying behavior is located in the interchangeable roles. The consequence is that the change of role requires explicit handling of the change. Implementation Structure II. Described by a meta pattern, Structure II is shown on Figure 22. As it can be seen, the class is regarded as the template class, and the roles as 18

19 hook classes. In relation to delegation, the class is the receiver and the roles the delegates. The receiving object delegates explicitly the varying behavior to the delegates. 1:1 Connection metapattern T href H T() H() Hook Template Figure 22: Structure II. 1:1 Connection Pattern Structure II has little to oer when the template methods are in the object and the hook method in the roles, because the transparency to the object through roles is not used. Structure II might be preferable when delegates use methods and attributes in the receiving object. Change of role require the same explicit task as described in Structure I. Implementation Structure III. Structure III described by a meta pattern is shown in Figure 23. The role acts as the template class, and the classes as hook classes. Structure III satises the most demands for State and Strategy (and Bridge). Delegation is handled implicitly by the roleication mechanism. All methods of the hook class are visible through the role. As an special feature, template methods in the role can be method roles of hook methods in the varying hook classes. Less delegation means less complexity and more ecient development and execution processes. In general, delegation is an alternative to subclassing with the negative consequence that behavioral changes of an object do not imply that the object is regarded as belonging to another class. Structure III resolves this by letting change of behavior reect the change of class as well. Structure III has one main disadvantage. Only one delegate object is possible at the time, because the template role can only be role of one object. In addition, a template role cannot be instantiated without also being bound to a hook object, i.e. the initial delegate object has to be declared by the client. As the Bridge pattern illustrates, Structure I and Structure III can be generalized. In its general form, the structure is used for separating abstraction and implementation. 19

20 1:1 Connection metapattern T href H T() H() Template Hook Figure 23: Structure III. 1:1 Connection Pattern Both structures implies "real" change of class when the behavior of the object intensionally changes. Structure I is applicable for the change of class when the change is performed by the client, and Structure III is applicable when the change of object is an internal action to the object. 6 Summary The evolution process of abstraction mechanisms and architectural abstractions, for example design patterns, is based on mutual inuence. Based on the role mechanism as an example we summarize our results as follows: Patterns to be used in analysis, design and implementation have identical basic form a general idea to give a solution to a problem in a given context. Analysis patterns, design patterns and implementation patterns are dierent with respect to the level of abstractivity and the degree of domain specicity. The role mechanism introduces new analysis patterns. Analysis patterns are used to model an application domain. The role mechanism enables alternative organizations of design patterns. mechanism may introduce new design patterns. The role The role mechanism gives alternative implementations of software in general and the structure of the solution part of design patterns in particular. The role mechanism introduces additional implementation patterns. 20

21 The interplay between conceptual abstraction mechanisms and design patterns exemplied by the role mechanism contributes to the further development of object-oriented analysis, design and implementation. This paper contributes by presenting an understanding of the evolution of abstraction mechanisms and architectural abstractions. The understanding is illustrated by examples of new role-based analysis, design and implementation patterns. References G. Booch: Object Oriented Analysis and Design with Applications. Benjamin/Cummings, P. Coad, D. North, M. Mayeld: Object Models: Strategies, Patterns, & Applications. Prentice Hall, J. O. Coplien, D. C. Schmidt: Pattern Languages of Program Design. Addison-Wesley, E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns: Elements of Reusable Object- Oriented Software. Addison-Wesley, B. B. Kristensen, K. sterbye. Conceptual Modeling and Programming Languages. SIGPLAN Notices Vol.29, No.9, B. B. Kristensen. Object-Oriented Modeling with Roles. Proceedings of the 2nd International Conference on Object-Oriented Information Systems, B. B. Kristensen, K. sterbye. Roles: Conceptual Abstraction Theory & Practical Language Issues. To appear in Theory and Practice of Object Systems (TAPOS), B. B. Kristensen. Architectural Abstractions and Language Mechanisms. To appear in: Proceedings of the Asia Pacic Software Engineering Conference '96, J. Olsson: Conceptual Programming with Design Patterns. Aalborg University, J. Olsson: Language Mechanisms and Design Patterns. Masters Thesis. Aalborg University, W. Pree: Design Patterns for Object-Oriented Software Development. Addison-Wesley, J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen: Object-Oriented Modeling and Design. Prentice Hall