See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220831615

Using CBR for Automation of Software Design Patterns

Conference Paper  in  Lecture Notes in Computer Science · September 2002

DOI: 10.1007/3-540-46119-1_39 · Source: DBLP

CITATIONS READS

44 819

7 authors, including:

Paulo Gomes Francisco C. Pereira

University of Coimbra Technical University of Denmark
125 PUBLICATIONS   1,070 CITATIONS    259 PUBLICATIONS   4,453 CITATIONS   

SEE PROFILE SEE PROFILE

Paulo Paiva Nuno Seco

University of Coimbra 48 PUBLICATIONS   1,178 CITATIONS   
22 PUBLICATIONS   247 CITATIONS   
SEE PROFILE
SEE PROFILE

Some of the authors of this publication are also working on these related projects:

MSc. Thesis View project

Future Mobility Sensing View project

All content following this page was uploaded by Carlos Lisboa Bento on 03 June 2014.

The user has requested enhancement of the downloaded file.

 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 ap-
plied. Their description is based on natural language which makes the automa-
tion 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 ap-
proach, providing a complete framework for pattern application. In our ap-
proach 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 pat-
terns [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. An-
other main advantage is that the application of design patterns improves and makes
software maintenance easier – design for change. Software design patterns are de-
scribed 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 selec-
tion 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 im-
prove 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 de-
picted in Figure 1. The pattern participants are: abstract factory (WidgetFactory),
concrete factories (MSWindowsFactory and MotifFactory), abstract products (Win-
dow 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 con-
trolling and abstracting object creation.

Figure 1 - The structure of the application of the Abstract Factory design pattern to the inter-
face 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 de-
signs based on similarity concepts; suggestion of new designs; verification of design
constraints; evaluation of design properties; learning of new design knowledge; appli-
cation of software design patterns; and other functionalities. The design pattern appli-
cation 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, cen-
tralizing 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 front-
end for the software designer, comprising the working space for design. The KB man-
agement 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 CBR Engine UML

Base Editor
Retrieval Adaptation Analog
y Software
Case Library
Verification Designer
Patterns Learnin
WordNet g

Case KB
Knowledge Base Manager
Indexes 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 im-
plementation of our approach to software design pattern application, which is the
subject of this paper. The verification module checks the current design for inconsis-
tencies. 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 Retrieve Applicable
Diagram DPA cases DPA Case Library

Select Best DPA case

Apply Selected New Class

Design Pattern Operators DPA case Diagram

Figure 3 - Software design pattern application module.

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 pre-
modification 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 partici-
pant;
• 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 partici-
pants 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 Educa- Room
Institution
tional
Institution

is-a
is-a is-a i
part-of
member-of Classroom
School University
Teacher
index index
index index

[DPACase1] [DPACase1] [DPACase2] Object: [DPACase2] Method:

Object: Teacher Object: School University 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 Fac-
tory 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 Description
Declares an interface for operations that
AbstractFactory Object No Yes
create abstract product objects.
Implements the operations to create concrete
ConcreteFactory Object No No
product objects.
Declares an interface for a type of product
AbstractProduct Object No No
object.
Defines a product object to be created by
ConcreteProduct Object Yes No
corresponding concrete factory.
Uses only interfaces declared by Abstract-
Client Object No No
Factory 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 ClassDia-
gram, 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:

Score =  w1 ×
TScoreObj Methods Attributes  (1)
+ w2 × + w3 ×
 CObjs CMets CAtrs 
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 Selected-
Cases.

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 remain-
ing 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: Re-
pair 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: TTL-
LogicGate, 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 struc-
ture. 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 de-
sign 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 imple-
mented in a CASE tool, and allows software designers to improve their designs, modi-
fying them having in mind design changes or design reusability.
An obvious advantage of our approach is the complete automation of the applica-
tion 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 mainte-
nance and reuse. One limitation of our approach is that the system performance de-
pends on the quality and diversity of the case library, which will improve as time fol-
lows. 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 pro-
totype 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 applica-
tion, 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 trans-
formations 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 in-
stead 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, For-
schungszentrum Informatik, Software Composition Group, University of Berne: Karlsruhe.
3. Cinnéide, M. and P. Nixon. A Methodology for the Automated Introduction of Design Pat-
terns. 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 Inter-
national 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 Man-
ual. 1998, Reading, MA: Addison-Wesley.
10. Miller, G., et al., Introduction to WordNet: an on-line lexical database. International Jour-
nal of Lexicography, 1990. 3(4): p. 235 - 244.

View publication stats