Information Technology Reference
In-Depth Information
Modeling Design Patterns with Description Logics:
A Case Study
Yudistira Asnar, Elda Paja, and John Mylopoulos
Department of Information Engineering and Computer Science
University of Trento, Italy
{ yudis.asnar,paja,jm } @disi.unitn.it
Abstract. Design Patterns constitute an effective way to model design knowl-
edge for future reuse. There has been much research on topics such as object-
oriented patterns, architectural styles, requirements patterns, security patterns,
and more. Typically, such patterns are specified informally in natural language,
and it is up to designers to determine if a pattern is applicable to a problem-at-
hand, and what solution that pattern offers. Of course, this activity does not scale
well, either with respect to a growing pattern library or a growing problem. In
this work, we propose to formalize such patterns in a formal modeling language,
thereby automating pattern matching for a given problem. The patterns and the
problem are formalized in a description logic. Our proposed framework is eval-
uated with a case study involving Security & Dependability patterns specified in
Tropos SI*. The paper presents the formalization of all concepts in SI* and the
modeling of problems using OWL- DL and SWRL. We then encode patterns as
SPARQL and SQWRL queries. To evaluate the scalability of our approach, we
present experimental results using models inspired by an industrial case study.
Keywords: design patterns, description logics, pattern matching.
1
Introduction
Design patterns represent recurring design problems and how to solve them. Design
patterns gained prominence initially in Architecture [1], and within Computer Science
with the widely-known and used design patterns for object-oriented design [2]. Today,
there are dozens of proposals for design patterns covering a range of design domains,
such as: requirements, software architectures, business processes, workflows etc.
Generally speaking, a design pattern consists of a triple (context, problem-to-solve,
solution-pattern) [1]. To use a pattern one needs to first match the design problem-at-
hand to the context, (if successful), match the problem-at-hand to the pattern context
(thereby creating mapping for pattern variables), and revise the problem at-hand by
using the solution-pattern. However, design patterns often are represented and docu-
mented informally in natural language (for an example [2]). This means that it is up to
users of a pattern library to determine which patterns are relevant, and also exactly how
they apply to the design problem-at-hand. Unfortunately, this approach does not scale
with respect to the size of the pattern library, the problem-at-hand, or the expertise of
the designer. Indeed, there is plenty of evidence that pattern libraries have low accept-
ability rates, especially so among non-expert users by now [3].
Some of the prominent
 
Search WWH ::




Custom Search