1. Introduction

A design pattern can be seen as a set of classes, related through inheritances, aggregations and delegations, which represents a partial solution to a common non-trivial design problem (Gamma et al., 1995). Design patterns are widely used to separate/to have been separating an interface from the different possible implementations, to wrap/to be wrapping legacy systems, to encapsulate/to be encapsulated command requests, to use/to have been used different platforms, and so on (Gamma et al., 1995). They represent a useful technique in forward engineering since they allow reusing successful practices, to improve communication between designers, and to share knowledge between software engineers. However, patterns can also be used/be using for reverse engineering OO software systems in order to capture/to have been captured relevant information on the design and code, and improve program understanding (Antoniol et al., 2001; Brown, 1996; Niere et al., 2002; Shull et al., 1996; Tsantalis et al., 2006a).

As a matter of fact, the use of patterns during the design phases affects the corresponding code, and the extraction of design pattern information from design and code can help the comprehension of the adopted solution for a system. This information can be used to highlight/to be highlighted wished properties of the design model, which can be reused/ reuse whenever a similar problem is encountered. Indeed, as also highlighted in Antoniol et al. (2001) when a software system has been designed using documented and well-known design patterns they can exhibit good properties such as modularity, separation of concerns, and ease of extension. Moreover, the information on the recovered design patterns can improve the system documentation and can guide the restructuring of the system. As a matter of fact, the recovery of design pattern instances from design documents and corresponding source code can be crucial for the identification of traceability links between different software artifacts in order to make/to be made the code easier to maintain and modify. In particular, this information can be profitably exploited to highlight/to have highlighted the rationale of implemented solutions in order to support and simplify the conceptual modeling of the system to be restructured/to have been restructured(Antoniol et al., 2001). According to (Gamma et al., 1995), design patterns are classified as structural, which concentrate on object composition and their relations in the run-time object structures, creational, which address object instantiation issues, and behavioral, which focus on the internal dynamics and object interaction in the system.

In this paper we present an approach to recover/to be recovering structural design patterns from OO source code, which is based on the use of visual language grammars and parsing techniques. A preliminary analysis is carried out to extract/to have extract the structural information needed to recover design patterns. In particular, the class diagram information, such as the name and type of classes, methods, and fields, inheritance and association relationships, and so on, are stored in a suitable data structure that speeds up the recovery process. The recovery process combines a diagram-level analysis, by using a parser for visual languages, with a source code level analysis. In particular, the recovery process is organized in two phases. In the first phase, design pattern instances are identified based on the design structure only by using a recovery technique based on visual language parsing (Costagliola et al., 2005). The design pattern recovery problem is reduced to the problem of recognizing subsentences in a class diagram, where each subsentence corresponds to a design pattern specified by a grammar. In the second phase the identified candidate patterns are validated by performing a source code analysis, which eliminates false positives and consequently increases the precision (Salton and McGill, 1983) of the recovery approach. To validate/to have been validated the proposed design pattern recovery approach, we have developed a tool, named Design Pattern Recovery Environment (DPRE), which supports the whole recovery process. In this paper, we extend the work presented in Costagliola et al. (2005); Costagliola et al. (2006); De Lucia et al. (2007) by:

– presenting a recovery technique supporting design pattern

definitions that include multi-level inheritance relationships;

– providing a detailed description of the proposed approach,

including the visual parsing phase and the source code analysis

phase;

– presenting a classification and an analysis of the design pattern

recovery approaches proposed in the literature;

– evaluating the approach and tool on six public-domain software

systems and libraries of different size, ranging from 8 to 560

KLOC;

– providing a detailed comparison with related approaches that

used the same software systems for the evaluation.

The paper is organized as follows. In Section 2, we describe related work on design pattern recovery. Section 3 presents the proposed design pattern recovery process while Section 4 describes the tool DPRE supporting it. The results of the case studies are reported and discussed in Section 5. Conclusion and future work are given in Section 6.

Task 1. Read the Introduction and formulate:

• the problem under study

• the existing solutions (literature)

• the best solution

• the research gap

• the goal of research

• the evaluation of research

• the structure of the paper

Task 2. Choose the correct form of the infinitive

Task 3. Match the pairs of synonyms:

However

As a matter of fact

Indeed

Moreover

In particular

Actually

Furthermore

Especially

Nevertheless

In reality

Task 4. Retell the Introduction.

Exercise V

Visual Cryptography Scheme for Color Image Using Random Number

with Enveloping by Digital Watermarking

Shyamalendu Kandar1, Arnab Maiti2, Bibhas Chandra Dhara3