the possibility of CASE design tools providing complete automation of design pat- ... From our point of view CBR can be applied successfully to the automation of.
Using CBR for Automation of Software Design Patterns Paulo Gomes, Francisco C. Pereira, Paulo Paiva, Nuno Seco, Paulo Carreiro, José L. Ferreira, Carlos Bento CISUC – Centro de Informática e Sistemas da Universidade de Coimbra. Departamento de Engenharia Informática, Polo II, Universidade de Coimbra. 3030 Coimbra {pgomes, camara}@dei.uc.pt, {paiva, nseco,carreiro}@student.dei.uc.pt, {zeluis, bento}@dei.uc.pt http://REBUILDER.dei.uc.pt
Abstract.1 Software design patterns are used in software engineering as a way to improve and maintain software systems. Patterns are abstract solutions to problem categories, and they describe why, how, and when can a pattern be applied. Their description is based on natural language which makes the automation of design patterns a difficult task. In this paper we present an approach for automation of design pattern application. We focus on the selection of what pattern to apply and where to apply it. We follow a Case-Based Reasoning approach, providing a complete framework for pattern application. In our approach cases describe situations for application of patterns.
1
Introduction
Software engineers and programmers deal with repeated problems and situations in the course of software design. This lead to the development of software design patterns [1], which can be defined as a description of an abstract solution for a category of design problems. One of the main advantages of patterns is design reusability. Another main advantage is that the application of design patterns improves and makes software maintenance easier – design for change. Software design patterns are described in natural language, not having a formalization. This is due to the abstract level of the design patterns, which makes the application of design patterns a human dependant task. Existing approaches to pattern application using computer tools [2-5], need the help and guidance of a human designer. This is especially true in the selection of the design pattern to apply. It is difficult to automate the identification of the context in which a pattern can be applied. Human designers must also identify which are the objects involved in the pattern application. The automation of this task opens the possibility of CASE design tools providing complete automation of design pat-
1
This work was partially supported by POSI - Programa Operacional Sociedade de Informação of Portuguese Fundação para a Ciência e Tecnologia and European Union FEDER, under contract POSI/33399/SRI/2000, by program PRAXIS XXI.
terns, and the offering new functionalities that can help the software designer to improve systems, and do better software reuse. Case-Based Reasoning [6, 7] can be defined as a way of reasoning based on past experiences. Each of these experiences is stored in a repository and is called a case. A case represents a specific situation, and can have different formats, depending on what is an experience. Normally, a case comprises three parts: problem – describing the problem and context situation; solution – describing the solution applied to this specific problem; and justification – an explanation of how the solution solves the problem. Usually the Case-Based Reasoning (CBR) cycle [8] comprises four main steps: retrieve, reuse, revise and retain. The first phase is responsible for the search and retrieval of cases from the case library. Commonly this is done using an indexing structure that identifies the relevant cases for the target problem, and then applies a similarity metric, which ranks the retrieved cases. In the reuse phase, the CBR system modifies one or more retrieved cases adapting them to the target problem situation. Revising the solutions generated by the previous phase is the next step. Most of the times this step is performed using domain specific heuristics, or domain models. The last phase is the retaining (or learning) of the new generated solution in the form of a new case, thus closing the CBR cycle. This allows the system to evolve in time. From our point of view CBR can be applied successfully to the automation of software design patterns. In this paper we present an approach that addresses this problem. Our approach considers a case to be a situation where a design pattern was applied to a specific software design (in the form of Unified Modeling Language – UML [9] class diagram). Cases are stored in a case library and indexed using a general ontology (WordNet [10]). The CBR framework that we propose selects which pattern to apply to a target design problem generating a new design. It can also learn new cases from the application of design patterns. This approach has been implemented in REBUILDER, a CASE tool which provides new functionalities based on CBR capabilities. In the next section we describe in more detail what is a design pattern, and we present an example to illustrate the issues related to pattern application. Section 3 presents our system – REBUILDER – so that the reader can have a better perspective on the context in which this work was developed. Section 4 describes our approach, starting with the model architecture for the design pattern application, and then describing the case representation, case library, pattern operators, and the various sub modules. Section 4 illustrates what was described in the previous section, showing how our approach can be applied to a specific situation. Finally we present the advantages and limitations of our approach, and compare our system with other related works.
2 Software Design Patterns A software design pattern describes a solution for an abstract design problem. This solution is described in terms of communicating objects that are customized to solve
the design problem in a specific context. A pattern description comprises four main elements: • Name – is the description which identifies the design pattern, and is essential for communication between designers. • Problem – describes the application conditions of the design pattern and the problem situation that the pattern intends to solve. It also describes the application context through examples or object structures. • Solution – describes the design elements that comprise the design solution, along with the relationships, responsibilities and collaborations. This is done at an abstract level, since a design pattern can be applied to many different situations. • Outcome – describes the consequences of the pattern application. Most of the times patterns present trade-offs to the designer, which need to be analyzed. Eric et al. [1] describe a catalog comprising 23 design patterns, and give a more detailed description for each pattern consisting on: pattern name and classification, pattern intent, other well-known names for the pattern, motivation, applicability, structure, participants, collaborations, consequences, implementation example, sample code, known uses, and related patterns. From these items, we draw attention to the participants and to the structure. The participants describe the objects that participate in the pattern, along with their responsibilities and roles. These objects play an important role in our approach. The structure is a graphical representation of the design pattern, where objects and relations between them are represented. A Pattern is classified based on its function or goal, which categorizes patterns as: creational, structural, and behavioral. Creational patterns have the main goal of object creation, structural patterns deal with structural changes, and behavioral patterns deal with the way objects relate with each other, and the way they distribute responsibility. As an example of a design pattern we briefly present the Abstract Factory design pattern (see [1], page 87). The intent of this pattern is to provide an interface for creation of families of objects without specifying their concrete classes. Basically there are two dimensions in objects: object types, and object families. Concerning the type of objects, each type represents a group of objects having the same conceptual classification, like window or scrollbar. The family of objects defines a group of objects that belong to a specific conceptual family, not the same class of objects. For example, Motif objects and MS Window objects, where Motif objects can be windows, scrollbars or buttons, which exist in MS Window objects but do not have the same visual characteristics. Suppose now, that an user interface toolkit is being implemented. This toolkit provides several types of interface objects, like windows, scroll bars, buttons, and text boxes. The toolkit can support also different look-and-feel standards, for example, Motif, MS Windows, and Macintosh. In order for the toolkit to be portable, object creation must be flexible and can not be hard coded. A solution to the flexible creation of objects depending on the look-and-feel, can be obtained through the application of the Abstract Factory design pattern. This pattern has five types of participating objects: • The Abstract Factory object declares an interface for operations that create abstract products. • Concrete Factory objects implement the operations to create concrete products.
• Abstract Product objects declare an interface for a type of product object. • Concrete Product objects define a product object to be created by the corresponding concrete factory, and also implement the Abstract Product interface. • Client objects use only interfaces declared by Abstract Factory and Abstract Product classes. A possible solution structure for the problem posed by the interface toolkit is depicted in Figure 1. The pattern participants are: abstract factory (WidgetFactory), concrete factories (MSWindowsFactory and MotifFactory), abstract products (Window and ScrollBar), concrete products (MSWindowsWindow, MotifWindow, MSWindowsScrollBar, and MotifScrollBar), and client (Client). The create methods in the factories are the only way that clients can create the interface objects, thus controlling and abstracting object creation.
Figure 1 - The structure of the application of the Abstract Factory design pattern to the interface toolkit problem.
The main consequences of this pattern is that it isolates concrete classes, makes exchanging product families easy, and promotes consistency among products.
3
REBUILDER
Our approach to design pattern application is integrated in a CASE tool based on CBR, named REBUILDER. The main goal of REBUILDER is to provide intelligent help for software developers in the design phase. This includes: retrieval of past designs based on similarity concepts; suggestion of new designs; verification of design constraints; evaluation of design properties; learning of new design knowledge; application of software design patterns; and other functionalities. The design pattern application is one of the modules included in the CBR engine (see Figure 2). REBUILDER is a tool intended to be used within a corporation environment, centralizing the corporation past designs in its knowledge base. There are two types of
users interacting with the system. Software designers, using REBUILDER as an UML editor, and a system administrator with the main task of keeping the knowledge base (KB) consistent and updated. In order for a CASE tool to be used, the design language must be intuitive and human-centered. This is also true for software design where it is common the use of visual languages to represent designs. One worldwide software design language is the Unified Modeling Language [9], best known as UML. This language provides a representation for all the software development phases. By choosing UML as the representation language, we are providing the user with a design standard. Figure 2 shows the architecture of REBUILDER. It comprises four main modules: UML editor, KB manager, KB, and CBR engine. The UML editor is the system frontend for the software designer, comprising the working space for design. The KB management is the interface between the KB and the system administrator. It provides access to various sub modules of knowledge, allowing the administrator to add, delete, or change knowledge from the KB, and fine-tuning it. Knowlegde Base
CBR Engine Retrieval
Adaptation
Case Library Verification
Patterns
WordNet Case Indexes
Analog y Learnin g
Knowledge Base Manager
UML Editor Software Designer
KB Administrator
Data Type Taxonomy
Figure 2 - The architecture of REBUILDER.
The KB comprises four modules: data type taxonomy, case library, case indexes, and WordNet. The data type taxonomy provides is-a relations between data types used in UML. This structure is used when the system has to compute the similarity between data types. The case library stores the design cases, each one representing a software design. They are stored in UML files created by the editor. The case indexes are used for case retrieval, allowing a more efficient retrieval. WordNet is a lexical reference system [10], used in REBUILDER as a general ontology that categorizes case objects. The CBR engine performs all the inference work in REBUILDER. It comprises six sub modules: retrieval, analogy, adaptation, patterns, verification, and learning. The retrieval module searches the case library for designs or design objects similar to the query2. The most similar ones are presented to the user, allowing the user to reuse these designs or part of them. Retrieved designs can also suggest new ideas to the designer, helping him to explore the design space. The analogy module maps designs 2
We use the term query, to refer to the current design, or part of it, in which the designer is working.
from the case library, to the query design. The resulting mapping establishes the knowledge transfer from the old design to the query design. Analogy goes further than case retrieval, creating new designs. The adaptation module can be used to adapt a past design (or part of it) to the query design using design composition. The main usage of this module is in combination with retrieval. The patterns module is the implementation of our approach to software design pattern application, which is the subject of this paper. The verification module checks the current design for inconsistencies. The learning module acquires new knowledge from the user interaction, or from the system interaction.
4 Software Design Pattern Application using CBR This section presents how software design patterns can be applied to a target design using CBR. We start by describing the patterns module, and then we describe each of its parts in more detail. 4.1 Architecture Figure 3 presents the architecture of the patterns module. It comprises three phases: retrieve applicable Design Pattern Application (DPA) cases, select best DPA case, and apply selected DPA case. A DPA case describes the application of a specific design pattern to a software design (the next sub section describes the case representation in detail). The first phase uses a target class diagram as the problem, and searches the DPA case library for DPA cases that match the problem. Then the retrieved DPA cases are ranked and the best one is selected for application, which is performed in the next step. The application of the DPA case uses the design pattern operators and yields a new class diagram, which is then used to build a new DPA case. This new case is stored in the DPA case library. Class Diagram
Retrieve Applicable DPA cases
DPA Case Library
Select Best DPA case
Design Pattern Operators
Apply Selected DPA case
Figure 3 - Software design pattern application module.
New Class Diagram
4.2 DPA Case Representation A DPA case describes a specific situation where a software design pattern was applied to a class diagram. Each DPA case comprises: a problem and a solution description. The problem describes the situation of application based on: the initial class diagram, and the mapped participants. The initial class diagram is the UML class diagram to which the software design pattern was applied. Like the names indicate it is the premodification diagram. The mapped participants are specific elements that must be present in order for the software design pattern to be applicable. Participants can be: objects, methods or attributes. Each participant has a specific role in the design pattern and it is important for the correct application of the design pattern. Each pattern has it’s specific set of participants. Once the participants are identified the application of a design pattern follows a specific algorithm that embeds the pattern actions. Mapping the participants is performed to select a role for some of the objects, attributes and/or methods in initial class diagram. It is important to describe the types of participants defined in our approach. Object participants can be classes or interfaces, attribute participants correspond to class attributes, and method participants correspond to object methods. Each participant has a set of properties: • Role of the participant in the design pattern (Role : String); • Object playing the role (Object : class or interface), or in case of attribute or method participant the object to which the attribute or method belongs; • Method playing the role (Method : method) in case of a method participant; • Attribute playing the role (Attribute : attribute) in case of an attribute participant; • Mandatory – optional or not (Mandatory : Boolean), if the participant must exist in order for the design pattern to be applicable, or just optional; • Unique - unique or not (Unique : Boolean), if there can be one or more participants of the Role type. The solution description of a DPA case is the name of the design pattern applied, which is then used to select the correct software design pattern operator. 4.3 DPA Case Library The DPA cases are indexed using the context synsets of the object participants (see Figure 4). The WordNet structure is used as an index structure enabling the search for DPA cases in a gradual way. Each case can be stored in a file, which can be read only when needed. In Figure 4 there are four indexed objects, three of them corresponding to object participants, and one a method participant, indexed by the object comprising the method.
is-a
Institution
Educational Institution
Room
i
is-a
is-a member-of School
Teacher
index
index
[DPACase2] Object: University
[DPACase1] Object: School
[DPACase1] Object: Teacher
Classroom
University
index
index
is-a
part-of
[DPACase2] Method: Classroom:: Classroom()
Figure 4 - An example of the DPA case indexing.
4.4 Software Design Pattern Operators For each design pattern there is one operator, for instance, the Abstract Factory design pattern has a specific pattern operator, which defines how to apply the Abstract Factory pattern, and if it can be applied. A software design pattern operator comprises three parts: the set of specific participants, the application conditions, and the actions for a the specific design pattern. For example, the participants specification for the Abstract Factory pattern operator is shown in Table 1. Role name
Type
Mandatory
Unique
AbstractFactory
Object
No
Yes
ConcreteFactory
Object
No
No
AbstractProduct
Object
No
No
ConcreteProduct
Object
Yes
No
Client
Object
No
No
Description Declares an interface for operations that create abstract product objects. Implements the operations to create concrete product objects. Declares an interface for a type of product object. Defines a product object to be created by corresponding concrete factory. Uses only interfaces declared by AbstractFactory and AbstractProduct classes.
Table 1. Participants for the Builder software design pattern.
The application conditions for Abstract Factory are: • ConcreteProducts must have at least one element. • All classes in ConcreteProducts must: o exist and; o have no public attributes and; o have no static methods. The pattern actions for Abstract Factory are defined in an algorithm presented in Figure 5.
NewClassDiagram ← Copy ClassDiagram ConcreteProducts ← Get all concrete products from Mapping (Role = ConcreteProduct) Clients ← Get all classes that use at least one ConcreteProduct AbstractFactory ← Create new class with name “AbstractFactory” Add to NewClassDiagram the class AbstractFactory AbstractProducts ← For each ConcreteProduct get/create the correspondant AbstractProduct ConcreteFactories ← Get/create all the ConcreteFactories for ConcreteProducts FOREACH Product in ConcreteProducts DO AbstractProduct ← Get Product superclass Abstract the access of Clients from Product to AbstractProduct Encapsulate the construction of Product in AbstractFactory and AbstractProduct ENDFOR Apply the Singleton pattern to AbstractFactory RETURN NewClassDiagram
Figure 5 - The application algorithm for the Abstract Factory design pattern. It transforms ClassDiagram into NewClassDiagram.
4.5 Retrieval of DPA Cases The retrieval of DPA cases is done using the WordNet as the indexing structure. The retrieval algorithm, see Figure 6, starts with the target class diagram (ClassDiagram). Then it uses the context synsets of the objects in the target diagram as probes to search the WordNet structure. The algorithm initiates the search on the synset probes, and then expands the search to neighbor synsets using all the WordNet semantic relations (is-a, part-of, member-of, and substance-of). It runs until the number of cases to be retrieved (NumberOfCases) is reached, or the maximum search level (MSL) is reached, or the Synsets list is empty which corresponds to the exhaustive search of the WordNet. Objects ← Get all classes and interfaces from the ClassDiagram Synsets ← ∅ FORALL Object in Objects DO Add to Synsets list the Object’s context synset ENDFOR SelectedCases ← ∅ SearchLevel ← ∅ Explored ← ∅ WHILE (#SelectedCases < NumberOfCases) AND (SearchLevel < MSL) AND (Synsets ≠ ∅) DO DPACases ← Get all DPA cases indexed by at least one synset from Synsets Add to SelectedCases the DPACases list NewSynsets ← ∅ FORALL Synset in Synsets DO Neighbors ← Get Synset Hypernyms, Hyponyms, Holonyms and Meronyms Neighbors ← Neighbors – Synsets – Explored – NewSynsets Add to NewSynsets the Neighbors list ENDFOR
Add to Explored the Synsets list Synsets ← NewSynsets SearchLevel ← SearchLevel + 1 ENDWHILE RETURN SelectedCases
Figure 6 – The DPA case retrieval algorithm, the input parameters are: the target ClassDiagram, the NumberOfCases to be retrieved, and the maximum search level (MSL) for searches in WordNet.
4.6 Selection of DPA Cases After the retrieval of the relevant cases, they are ranked accordingly to its applicability to the target diagram (ClassDiagram). The selection algorithm (see Figure 7) starts by mapping the ClassDiagram to each of the retrieved cases (SelectedCases), resulting in a mapping for each case. The mapping is performed from the case’s participants to the target class diagram (only the mandatory participants are mapped). Associated to each mapping there is a score, which is given by:
TScoreObj Methods Attributes Score = w1 × + w2 × + w3 × CObjs CMets CAtrs
(1)
Where TScoreObj is the sum of the semantic distance of the mapped object participants. Methods and Attributes are the number of methods participants and attribute participants mapped. CObjs, CMets and CAtrs are the number of object participants, method participants, and attribute participants, in the DPA case. W1, w2 and w3 are constants, which we defined as 0.5, 0.25 and 0.25. So, what this score measures is the degree of participants mapping between the DPA case and the target diagram. The next step in the algorithm is to rank the SelectedCases list based on the mapping scores. The final phase consists on checking the applicability of the best DPA case, which is done using the design pattern operator associated with the DPA case. If the application conditions of this operator are not violated, then this DPA case is returned as the selected one. Otherwise, this case is discarded and the next best case goes through the same process, until one applicable case is found or it returns null. Scores ← ∅ Mappings ← ∅ FORALL SelectedCase in SelectedCases DO Mapping/Score ← Get the mapping and score for the SelectedCase Add to Mappings the SelectedCase Mapping Add to Scores the SelectedCase Score ENDFOR Rank lists: SelectedCases, Mappings and Scores, by Scores FORALL SelectedCase in SelectedCases DO IF (Design Pattern (solution of SelectedCase) can be applied to ClassDiagram using the Mapping established before) THEN RETURN SelectedCase and the respective Mapping ENDIF
ENDFOR RETURN NULL
Figure 7 - The algorithm for selection of DPA cases. The input list of DPA cases is SelectedCases.
4.7 Application of DPA Cases Selected the DPA case, the next step is to apply it to the target class diagram generating a new class diagram and a new DPA case. The application of a DPA case is done using the pattern operator corresponding to the software design pattern given as the solution of the DPA case. Starting with the participants mapping established before, the application of the pattern is done using the application algorithm of the pattern operator.
5
Application Example
This section illustrates the functioning of the pattern module with an example. Figure 8 shows the target class diagram used in our example. The goal is to improve this class diagram through the application of design patterns. Pattern application makes the extension and maintenance of Object Oriented designs easier and faster. In the remaining of this section we will explain the three steps of the pattern module: retrieval, selection and application of DPA cases.
Figure 8 - The target class diagram used in the example section.
5.1 DPA Case Retrieval The first step is the retrieval of DPA cases from the case library. This is done using the algorithm presented in Figure 6. The initial search probes are the synsets for: Repair Shop, Stock, Motor (the synset for Car Motor and Motorcycle Motor is the same of Motor), and Wheel (the synset for Car Wheel and Motorcycle Wheel is the same of
Wheel). The case library comprises several DPA cases, from which we present the initial class diagrams for two of them (see Figure 9 and Figure 10). DPA case 1 represents the application of the Abstract Factory design pattern to the initial class diagram of Figure 9 (due to space limitations we can not present the class diagram that resulted from the application of the Abstract Factory to this diagram). The participants in this DPA case are: PlaneEngine, PlaneWheel, HeliEngine and HeliWheel which are Concrete Products; and Plane and Helicopter which are Clients. The solution of this DPA case is Abstract Factory.
Figure 9 - The initial class diagram of DPA Case 1.
The DPA case 2 is also the representation of an application of the Abstract Factory pattern, but to the initial class diagram of Figure 10. The participants are: TTLLogicGate, TTLMultiplexer, TTLDecoder, CMOSLogicGate, CMOSMultiplexer, and CMOSDecoder, which are Concrete Products; and Equipment which is a Client.
Figure 10 - The initial class diagram of DPA Case 2.
The search then starts using these four synsets and is done in the WordNet structure. Figure 11 presents part of the WordNet structure, which indexes DPA case 1 (through the synset of Motor and Wheel, Engine has the same synset as Motor) and DPA case 2 (through the synset of Multiplexer). Starting on Wheel and Motor, case 1 is the first being selected, then the algorithm expands to the neighbor nodes until in the four iteration it gets to Multiplexer where it founds case 2. Due to space limitations we only retrieve two cases, but more cases could be retrieved. The cases retrieved for the next step are: DPA case 1, and DPA case 2.
Device
Electronic Device
Mechanism
Machine
Multiplexer
Mechanical Device
Motor
DPA Case 2
Simple Machine
DPA Case 1
Wheel
DPA Case 1
Figure 11 - Part of the WordNet is-a structure that is used by retrieval in the example.
5.2 DPA Case Selection The next step is to select which of the retrieved cases is going to be applied. The first phase of selection is to establish the mappings and the score associated with each mapping. For case 1 the following mappings were obtained: PlaneEngine – CarMotor; PlaneWheel – CarWheel; HeliEngine – MotorcycleMotor; and HeliWheel – MotorcycleWheel. Mappings for case 2 are: TTLLogicGate – Motor; TTLMultiplexer – CarMotor; TTLDecoder – CarWheel; CMOSLogicGate – Wheel; CMOSMultiplexer – MotorcycleMotor; and CMOSDecoder – MotorcycleWheel. Mappings for case 1 get the following score: 0.5 * (4 / 4) + 0.25 * 1 + 0.25 * 1 = 1, according to equation (1). Notice that all the mappings established between case 1 and the target diagram match perfectly, so they all have the score of 1, yielding 4 for the sum. Since there are no method or attribute participants, the score associated with each of these items is 1. For case 2, the computation of the mappings’ score is: 0.5 * ((0.31 * 4 + 0.34 * 2) / 6) + 0.25 * 1 + 0.25 * 1 = 0.66. There are six mappings between case 2 and the target diagram, which leads to the following semantic distances: LogicGate – Motor, Decoder – Wheel, LogicGate – Wheel, 8 is-a semantic relations, yielding the similarity of 0.31; and Multiplexer – Motor with 6 is-a semantic relations, yielding the similarity of 0.34. To this point, we have case 1 ranked in the first place. The next step is to assess the applicability of the solution pattern of case 1, which is the Abstract Factory pattern. Sub section 4.4 presents the pre-conditions needed for this pattern to be applied. Since case 1 meets all the pre-conditions the Abstract Factory can be applied to the target diagram using the mapping established before.
5.3 DPA Case Application The final step is the application of the design pattern selected, using the respective design pattern operator. Figure 5 presents the application algorithm for the Abstract Factory design pattern, which after being applied to the class diagram of Figure 8, using the mapping determined before, results in the diagram of Figure 12. One of the advantages of this transformation is that is easier to maintain and extend this design, because this new design enables the extension of the design in two different axis: types of products that can be added (for instance steering mechanism), or by family of products (for instance truck).
Figure 12 - The new class diagram generated from the application of DPA Case 1 to the target diagram.
6
Conclusions
This paper presents an approach to the automation of the application of software design patterns. Our approach is based on CBR and cases represent situations in which a design pattern was applied in the past to a software design. This approach is implemented in a CASE tool, and allows software designers to improve their designs, modifying them having in mind design changes or design reusability. An obvious advantage of our approach is the complete automation of the application of design patterns. Our approach selects which pattern to apply based on DPA cases. This enables a CASE tool to offer new functionalities, aimed for design maintenance and reuse. One limitation of our approach is that the system performance depends on the quality and diversity of the case library, which will improve as time follows. Another limitation, is that the range of case application is always limited, and it
does not outperform a software designer ability to identify which pattern to apply. Despite this, we think that our approach can provide a good contribute for design improvement, especially in situations when the user has to deal with a huge amount of objects. In this situation, automation is possibly the only way to apply design patterns, since it is difficult for the designer to deal with such an amount of objects. There are some research works that have common aspects with our approach. Eden et. al. [4] has proposed an approach to the specification of design patterns, and a prototype of a tool that automates extensively their application. This approach considers design patterns as programs that manipulate other programs, thus they are viewed as metaprograms. Eden’s approach does not automates all the process of design application, since it is the user that has to select which pattern to apply. In our approach this step is automated. Another difference is that Eden applies patterns at code level, while we apply them at design level. Tokuda and Batory [5] also present an approach in which patterns are expressed in the form of a series of parameterized program transformations applied to software code. Like Eden’s work, this work does not address the automation of which pattern to apply. Other works on specifying design patterns and automating its application are presented by Bär [2] and Cinnéide [3]. These works also automate the application of design patterns, but do not select which pattern to apply. This must be done by the user. Both works deal with design modification instead of code modification.
References 1. Gamma, E., et al., Design Patterns: Elements of Reusable Object-Oriented Software. 1995, Reading: Addison-Wesley. 395. 2. Bär, H., et al., The FAMOOS object-oriented reengineering handbook, . 1999, Forschungszentrum Informatik, Software Composition Group, University of Berne: Karlsruhe. 3. Cinnéide, M. and P. Nixon. A Methodology for the Automated Introduction of Design Patterns. in IEEE International Conference on Software Maintenance. 1999. Oxford, England: IEEE. 4. Eden, A., J. Gil, and A. Yehudai, Automating the Application of Design Patterns. Journal of Object Oriented Programming, 1997(May). 5. Tokuda, L. and D. Batory. Automated Software Evolution via Design Patterns. in 3rd International Symposium on Applied Corporate Computing. 1995. Monterrey, Mexico. 6. Kolodner, J., Case-Based Reasoning. 1993: Morgan Kaufman. 7. Maher, M.L., M. Balachandran, and D. Zhang, Case-Based Reasoning in Design. 1995: Lawrence Erlbaum Associates. 8. Aamodt, A. and E. Plaza, Case-Based Reasoning: Foundational Issues, Methodological Variations, and System Approaches. AI Communications, 1994. 7(1): p. 39-59. 9. Rumbaugh, J., I. Jacobson, and G. Booch, The Unified Modeling Language Reference Manual. 1998, Reading, MA: Addison-Wesley. 10. Miller, G., et al., Introduction to WordNet: an on-line lexical database. International Journal of Lexicography, 1990. 3(4): p. 235 - 244.
