<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Relations extraction on patterns lacking of Resulting Context</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Asma HACHEMI</string-name>
          <email>ashachemi@usthb.dz</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Mohamed AHMED-NACER</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Computer science department, USTHB</institution>
          ,
          <addr-line>Algiers</addr-line>
          ,
          <country country="DZ">Algeria</country>
        </aff>
      </contrib-group>
      <fpage>282</fpage>
      <lpage>287</lpage>
      <abstract>
        <p>Many software patterns are available nowadays. They allow the reuse of proved solutions in various areas of software engineering, but are expressed in different formalisms. This diversity is detrimental for patterns reuse, since it is difficult to compare and compose heterogeneous patterns (patterns expressed in different formalisms). Moreover, patterns composition is based on inter-patterns relationships, that are difficult to discern if they are not explicit. Thus, an automatic method that extract non explicit relations between patterns even if those latter are heterogeneous, becomes a necessity. In this context, we improve an existing method of automatic inter-patterns relations analysis. As many patterns lack of resulting context, our aim is to enable that method to extract relations on this kind of patterns.</p>
      </abstract>
      <kwd-group>
        <kwd />
        <kwd>Patters formalisms</kwd>
        <kwd>inter-patterns relationships</kwd>
        <kwd>automatic relations extraction</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>Nowadays, the WWW supplies an increasing amount of knowledge covering
diverse domains. Among others, it supplies a large number of software patterns that are
a formidable tool allowing the reuse of proved solutions, in various areas of software
engineering. A software pattern presents an issue to a recurrent problem, by offering a
proven solution. Software patterns need to be composed, in order to solve complex
problems that are not dealt by a single pattern. Inter-patterns relationships are on the
basis of the patterns composition. However, it is difficult to discern these relations if
they are not explicit in each pattern. Moreover, even if those relations are explicit,
they are limited to intra-catalog relationships.</p>
      <p>Indeed, a pattern is expressed through a pattern formalism, which is a syntactic
structure of the pattern content. The majority of pattern formalisms in the literature
differ in the number and degree of detail of their items. So, it is difficult to interpret
and compare heterogeneous patterns. It is also difficult to compose them into larger
solutions; a fact which is detrimental for patterns reuse.</p>
      <p>This paper presents our approach that improves an existing method of automatic
inter-patterns relations analysis. This method is the first automatic approach which
handles relations between heterogeneous patterns, cross different catalogs. The aim
of our improvement is to enable that method to handle more patterns formalisms;
specially, those formalisms lacking of resulting context. So, works related to
interpatterns relationships extraction are described in section 2. Our approach for
automatic relations analysis on patterns lacking of resulting context is presented in section 3.
Finally, we conclude this paper and give some research perspectives in section 4.</p>
    </sec>
    <sec id="sec-2">
      <title>Related works</title>
      <p>
        Many researcher were interested in defining inter-patterns relationships, like [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ],
[
        <xref ref-type="bibr" rid="ref2">2</xref>
        ], [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], … but very few works treat relationships extraction. In this area,
Prabhakar et al. [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ] propose a graphical model called Design Decision Topology Model,
in order to represent design patterns and extract relationships between them;
unfortunately, this work is limited to the analysis of relations on design patterns only. The
method of Kubo et al. [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] is the first automatic approach able to extract relations on
heterogeneous patterns, belonging to different catalogs, and is the only approach able
to deal with different kinds of software patterns. Kubo et al. method is an interesting
approach based on its own pattern model (consisting of Starting Context, Forces,
Resulting Context), and on several text processing techniques (stop word removal
[
        <xref ref-type="bibr" rid="ref11">11</xref>
        ], stemming [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ], the TFIDF term weighting [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ], vector space model [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] and the
cosine similarity). However, Kubo et al. method is not able to treat patterns which
lack of Resulting Context, so we propose to improve it to extract relations on this kind
of patterns.
      </p>
    </sec>
    <sec id="sec-3">
      <title>4 Our approach</title>
      <p>
        Our approach towards an automatic way to analyze relations between patterns is
based on Kubo et al. method, that we propose to improve in terms of the pattern forms
handled. As many patterns do not express the Resulting Context explicitly (like those
in [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ], [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ], [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ], [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ], [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ], …), they cannot be represented and analyzed by the mo-del
of Kubo et al.. Therefore, a value-added of our approach is the proposition of a
solution to represent this kind of patterns and analyze relations on them.
      </p>
      <p>
        Resulting Context is the result or product generated by the pattern application. So,
each pattern has its resulting context either explicit in a dedicated section, or
implicitly given in the Solution section. Here is an example of a resulting context expressed
within the Solution : The pattern Declare Before First Use [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] aims to ensure that the
declaration of an element is positioned before the reference to it (in an XML
document). The resulting context of this pattern is the increase of the probability of
treating the document in a single pass. Actually, this resulting context is expressed within
the Solution section :“This gives the processing software a better chance of doing a
single pass traversal of the document”.
      </p>
      <p>
        Our idea is to overcome the absence of a dedicated section for Resulting Context
by using the Solution section, so that one be able to represent the third element of the
pattern model (Resulting Context). A such use of the Solution does not alter the
significance of the relationships that we are interested in (Starting-Starting [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ],
Same[
        <xref ref-type="bibr" rid="ref10">10</xref>
        ], Resulting-Starting[
        <xref ref-type="bibr" rid="ref10">10</xref>
        ], Uses[
        <xref ref-type="bibr" rid="ref6">6</xref>
        ] and Refines[
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]). The reasons are :
 The relation Starting-Starting : The analysis of this relation is based on the
Starting Context [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ]. The Resulting Context is used only to represent the
pattern in the Kubo et al. model. Thus, the use of the Solution section instead
of the Resulting Context does not affect the meaning of this relation.
 The relations Refines : The analysis of this relation is based on the Starting
Context and Forces [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]. The Resulting Context is used only to represent the
pattern in the Kubo et al. model. So, the use of the Solution instead of the
Resulting Context does not alter the meaning of this relationship.
 The relation Same : When two patterns share the same Starting Context and
the same Solution, this means that these two patterns deal with the same
problem and provide the same result. Thus, we can use the Solution section
instead of the Resulting Context to analyze this relation.
      </p>
      <p>
        For example, let’s consider the pattern Navigation Tabs [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ] (called P1)
which is Same as the pattern Navigation Tabs [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] (called P2). This relation is
given by the author of [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ], so we consider it as correct and process the
analysis using our method. This latter starts by eliminating stop words [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] and
applying the Stemmer [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ] on the elements of P1 and P2. After that, the
terms of these elements are weighted using the TFIDF method [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ], and the
cosine similarity is calculated as explained in [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ]. Also, our method checks
the inclusion [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ], either it is true or false between each couple of elements.
We obtain the results shown in Table 1.
      </p>
      <p>Table 1. Results of comparisons between patterns elements</p>
      <sec id="sec-3-1">
        <title>Compared Elements</title>
        <p>
          Since we obtain the similarity and inclusion results, we calculate the value of
each relation between P1 and P2, using the definition of each relation (Uses
[
          <xref ref-type="bibr" rid="ref6">6</xref>
          ] Refines [
          <xref ref-type="bibr" rid="ref6">6</xref>
          ], Same [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ], Resulting-Starting [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ], Starting-Starting [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ]).
For instance, the relation Starting-Starting between the patterns P1 and P2 is
represented by the similarity value of the Staring Contexts of these patterns.
The results of the relations analysis are shown in Table 2.
        </p>
        <p>Table 2. Results of relations analysis</p>
      </sec>
      <sec id="sec-3-2">
        <title>Its value</title>
        <p>0,934
0,136
0,135
Finally, as in Kubo et al. method, the strongest relation of the eight types (P1
Uses P2, P1 Refines P2, P2 Uses P1, P2 Refines P1, Same,
ResultingStarting (P1 then P2), Resulting-Starting (P2 then P1), Starting-Starting) is
assumed as the representative relationship. So we conclude in this case that
the patterns P1 and P2 are Same.
0,156
0,248
0
Finally, considering the strongest relationship, we conclude that P1 and P2
are related via the relationship Resulting-Starting.
Finally, considering the strongest relationship, we conclude that the pattern
P1 Uses the pattern P2.</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Conclusion and perspectives</title>
      <p>Our way of looking at the analysis of relations between patterns is based on Kubo
et al method. We improved this method to enable it dealing with patterns which do
not give their Resulting Contexts in an explicit manner. Our idea consisted of using
the Solution section. As we have explained earlier, a such use does not alter the
significance of the different relations treated. Some other improvements can be addressed to
face the drawbacks inherent to Kubo et al. method, and to offer more benefits for
patterns composition. Such as :
 The block HTML Analysis of the method is limited to the treatment of
patterns expressed in HTML. This block can be extended to deal with patterns
expressed in other ways.
 The method can be improved to treat patterns lacking of Starting Context
and/or Forces, which are two necessary elements to represent patterns in the
model of Kubo et al.
 The method can be extended to offer the functionality of Patterns Retrieval,
which provides to a user having a particular problem, all available patterns
that treat this problem.</p>
    </sec>
    <sec id="sec-5">
      <title>References</title>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Zimmer</surname>
          </string-name>
          , W.:
          <article-title>Relationships between design patterns</article-title>
          .
          <source>In: PLoP</source>
          (
          <year>1994</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Conte</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fredj</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Giraudin</surname>
            ,
            <given-names>J.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rieu</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          : P-Sigma :
          <article-title>un formalisme pour une représentation unifiée de patrons</article-title>
          . In: Inforsid,
          <string-name>
            <surname>Genève</surname>
          </string-name>
          (
          <year>2001</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Gnatz</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Marschall</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Popp</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rausch</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Schwerin</surname>
            ,
            <given-names>W.:</given-names>
          </string-name>
          <article-title>The Living Software Development Process</article-title>
          .
          <source>Journal Software Quality Professional</source>
          , Volume
          <volume>5</volume>
          , Issue 3 (
          <year>2003</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Henney</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          :
          <article-title>Patterns Inside Out</article-title>
          .
          <source>Talk presented at Application Development</source>
          , London (
          <year>1999</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Crumlish</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Malone</surname>
          </string-name>
          , E.:
          <article-title>Designing social interfaces</article-title>
          . available at http://www.designingsocialinterfaces.com/patterns/Main_Page (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Hachemi</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ahmed-Nacer</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Primary inter-patterns relationships analysis</article-title>
          .
          <source>In: CARI2012</source>
          ,
          <string-name>
            <surname>Algiers</surname>
          </string-name>
          (
          <year>2012</year>
          )
          <article-title>unpublished</article-title>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <article-title>Yahoo design pattern library</article-title>
          . http://developer.yahoo.com/ypatterns/.
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <article-title>Develop effective XML documents using structural design patterns</article-title>
          . http://www.xmlpatterns.com/ (
          <year>2000</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Lammi</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Varjokallio</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hocksell</surname>
            ,
            <given-names>J.:</given-names>
          </string-name>
          <article-title>A user interface design pattern library</article-title>
          . http://www.patternry.com.
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Washizaki</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kubo</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Takasu</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fukazawa</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          :
          <article-title>Analyzing Relations among Software Patterns based on Document Similarity</article-title>
          .
          <source>In: IEEE Internationale Conference on Information Technology : Coding and Computing</source>
          (
          <year>2005</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Salton</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>McGill</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Introduction to Modern Information Retrival</article-title>
          .
          <article-title>MG-Hill Inc</article-title>
          .,
          <source>NY</source>
          (
          <year>1983</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Paice</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Another stemmer</article-title>
          .
          <source>SIGIR Forum</source>
          , Vol.
          <volume>24</volume>
          , No.
          <issue>3</issue>
          , pp.
          <fpage>56</fpage>
          -
          <lpage>61</lpage>
          (
          <year>1990</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Salton</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Yang</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>On the specification of term values in automatic indexing</article-title>
          .
          <source>Journal of Documentation</source>
          , Vol.
          <volume>29</volume>
          , pp.
          <fpage>351</fpage>
          -
          <lpage>372</lpage>
          (
          <year>1973</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Tidwell</surname>
          </string-name>
          , J.:
          <article-title>Designing interfaces - Patterns for effective interaction design</article-title>
          . available at http://designinginterfaces.com/firstedition/ (
          <year>2005</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Prabhakar</surname>
            ,
            <given-names>T.V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kumar</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          :
          <article-title>Design Decision Topology Model for Pattern Relationship Analysis</article-title>
          .
          <source>In: Asian PLOP 2010</source>
          Tokyo (
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>