Information Technology Reference
In-Depth Information
patterns (e.g., Pattern Forge
6
, Net Objectives
7
, Portland Pattern Repository
8
). In
comparison to our approach, such initiatives receive a pattern contribution in natural
language without formalizing it. In addition to disadvantages presented in Section 4.2,
users might have difficulties in finding relevant patterns in the library because textual
matching does poorly without domain knowledge.
To improve the finding and the selection phase, several works use (semi-)formal
languages for representing patterns and selection mechanisms of such representation.
In [18], Mens et al. use DL to detect inconsistencies between UML models in evolving
systems. In that work, the authors take advantage of the underlying DL representation
and reason about UML models exploiting the DL reasoning engine (e.g., Racer, Loom).
In a nutshell, this work takes a similar approach to ours where the TBox formalizes the
UML meta-model and the ABox represents instances in the designers' model. In our
work, the query represents the context of a pattern, while in this work the query repre-
sents the rules characterizing model constraints. In [19], the authors describe how to use
a meta-model to obtain a representation of a pattern at the code level. The meta-model
consists of a set of entities and interaction rules between them, and defines pattern se-
mantics. The meta-model is further specialized by adding structural and behavioral con-
stituents, thereby obtaining an abstract representation of patterns. These are gathered in
a repository and used to generate code automatically.
Some works facilitate the selection phase by structuring the pattern library in a cer-
tain manner. In [20,21], the authors proposed a structure to organize patterns. Moreover,
other authors [22,23] provide systematic and automated reasoning to select a pattern. In
these works, the authors do not formalize the pattern itself, but rather formalizing the
structure and relationships among patterns. Conversely, our approach formalizes a pat-
tern and does not prescribe a particular structure on the pattern library. In our approach,
we aim to find an applicable pattern and provide a mapping, while these works intends
to limit the solution space so that the pattern users need only evaluate a small number
of patterns. In other words, these approaches require less efforts in contributing a new
pattern because they only require where a pattern should be categorized and its relation-
ships with other patterns, while in our approach “the formalization” of a pattern defines
the performance, in term of correctness, of the system. Note that these approaches does
not guarantee the resulted pattern will be applicable to the problem-at-hand, while ours
Some works concentrate on how to apply the patterns in the problem-at-hand. For
instance, Eden et al. [24] represent patterns as meta-programs that modify other code
(i.e., the problem-at-hand). The authors have implemented a prototype that supports de-
sign pattern specification and realization in a given program and this approach allows
programmers to edit the source code at any time in the process. In comparison to our ap-
proach, this work aims at modifying the problem before implementing a chosen pattern,
whereas ours aims to find the pattern(s) that are applicable to solve a given problem.
In the area of Model-Driven Engineering, several frameworks have been proposed to
support model transformations [25]. In comparison to ours, their approaches are more
expressive in describing how a pattern is to be applied. However, these frameworks
6
http://www.patternforge.net/
7
http://www.netobjectives.com/PatternRepository
8
http://c2.com/ppr/
