SEKE 2012 Proceedings - Knowledge Systems Institute

A. Pattern Reuse
In patterns reuse state of the art and practice, there are two
complementary processes: a process for the reuse and a process
by the reuse [14]. The software engineering process for re use
concerns patterns engineering and aims to identify, specify and
organize patterns that should be used during the process. The
software engineering process by reuse is devoted to patterns
engineering allowing the search, selection, adaptation and the
integration of patterns for software engineering.
As conclusion to the literature review that we carried out on
patterns reuse, we noted that a great deal of interest is
addressed to product patterns and more precisely design
patterns in research as well as in industry. In addition, we
derived that most of the deployed efforts to improve pattern
reuse are specific to design patterns and could not be adopted
or adapted for other pattern types. Among these, we cite the
efforts deployed by [15] to automatically detect design
patterns’ problem.
On the other hand, process patterns are increasingly being
described within software development communities but in
different forms. In fact, in our literature review, we identified
eleven process patterns’ description models that are being
adopted separately and independently. In other words, every
community creates and manages its own patterns’ collection or
system. This would in our view, cripple patterns’ knowledge
reuse especially when we find communities using different
models to describe their patterns. As a consequence, patterns’
users could only have access to patterns that are maintained by
their own community.
So, we argue that a holistic approach is required to better
reuse and capitalize process patterns’ knowledge. This latter
should support the two complementary processes mentioned
above, namely: patterns for reuse and patterns by reuse
B. Motivating Example
To motivate our position, we try to state the problem of
model diversity with regard to process patterns description by
showing some patterns’ samples. Figure 1 illustrates this by
presenting three different process patterns. Pattern A, proposed
by Störrle [16], deals with requirements administration using
its own vocabulary to describe patterns attributes such as Intent
to express the pattern’s problem. Pattern B, described by
Dittman [17], handles the technical review process using the
term subproblem as a pattern’s problem. Pattern C which is
created by Gnatz [18], deals with task analysis and employs
another different vocabulary such as Pros and Cons Pros to
express pattern’s discussion.
As far as we can see, these patterns are not only informally
and differently defined but also described in an unstructured
manner. We believe that all of these observations conspire to
create barriers to patterns share and reuse. This matter of fact
leads us to think to unify and to formalize pattern descriptions
in order to make them machine- processable so as to more
efficiently share and capitalize them.
Section III presents the unification meta-model that we
created to express process patterns knowledge after the
mapping efforts that we made on the different patterns
description models.
Figure 1.
Heterogeneity of process patterns’ descriptions.
III. BACKGROUND
This section is intended to provide background information
for the proposed approach. The first subsection is devoted to
sum up results of the study that we carried out in order to
assess process patterns representation and reuse within
software development communities. The next subsection will
exhibit the general structure of the proposed process pattern
meta-model as the building block of the proposed approach.
A. Process Patterns Literature: Review’s Results
Different works have been carried out in the literature of
patterns dealing with process patterns’ description and
formalization. These are classified into description models such
as Ambler [8], RHODES[19], Gnatz [18], P-Sigma [3], Störrle
[16] and other as languages, such as PROMENADE [20],
PPDL [5], PROPEL [21], PLMLx [22], UML-PP [6] and PPL
[23].
Based on eleven evaluation criteria that we fixed in a
previous work [24], we assessed the aforementioned works and
revealed several lacks, detailed in [12] and [24], creating
barriers to patterns’ knowledge capitalization and reuse.
Among these, we notice the lacks of architectural as well as
terminological consent in patterns descriptions.
Pattern A
Pattern B
Pattern C
The lack of architectural consent means that different
process pattern descriptions have been proposed using
disparate architectures. In fact, when comparing the
eleven selected works from the literature, we identified
eleven different pattern description facets, namely:
506