Recognition of Patterns in Software Designs Models via Logic Inferences

Recognition of Patterns in Software Designs Models

via Logic Inferences

Hong ZhuDepartment of Computing and Electronics

Oxford Brookes UniversityOxford OX33 1HX, UK

Email: [email protected]

Sep

t. 20

10

2Seminar: Recognition of Patterns in Design Models

Acknowledgement

This presentation is based on joint research work with Dr. Ian Bayley of Oxford Brookes University Dr. Lijun Shan, who was my PhD student Mr. Richard Amphlett, who was supported by t

he Undergraduate Research Student Scholarship funded by the Reinvention Centre, UK.

Sep

t. 20

10


Outline

Motivation and related works Tool support to the application of DPs Formalisation of DPs

Our previous work Specification of DPs Semantics of UML models

The proposed approach Bridge the gaps The tool LAMBDES-DP Experiments

Conclusion and future work

Sep

t. 20

10


Motivation

Design patterns (DPs) Reusable solutions to commonly occurring design pr

oblems Represented in Alexandrian form

Synopsis, Context, Forces, Solution, Consequences, Implementation, Examples, Related patterns

Proper use can improve software quality and development productivity Reduce ambiguity Automated tool support

Explained informally (in English)

Clarified with illustrative diagrams

Specific code examples

Sep

t. 20

10


Existing works 1Tool support to the application of DP

Instantiation of patterns Generating an instance of a design pattern Widely available in modelling tools

Recognition of patterns Code level

• Recognizing instances of patterns by analyzing the program code

Design level

• Recognizing instances of patterns by analyzing the design documents, especially UML diagrams

Sep

t. 20

10


Code Level DP Recognition Tools

Program Code intermediate

representation

Pattern Library

Pattern Match Engine

Program Code

Code Analyzer

e.g. Java Program

e.g. Prolog clauses

e.g. Prolog queries

e.g. Prolog execution engine

Architecture of the tools

e.g. SQL queries

e.g. Relational DB

e.g. DBMS/SQL server

Sep

t. 20

10


Code Level DP Recognition ToolsCurrent state of art

More than a dozen such tools have been reported in the literature; See (Dong, Zhao and Peng, SERP 2007) for a survey;

Well-known examples: HEDGEHOG (Blewitt, Bundy and Stark, ASE 2005) FUJABA (Niere, et al. ICSE 2002) PINOT (Shi and Olsson, ASE 2006)

Problems Low level of abstraction Late in development process Hard to improve precision and recall rate

Sep

t. 20

10


Design/Model Level DP Recognition Tools

Model intermediate

representation

Pattern Library


Software Design Model

Model Analyzer

UML diagram

Specification of design patterns

Architecture

Prolog statements

Prolog execution engine

Meta-models in RBML

Special SW that matches UML diagram to RBML meta-models

Sep

t. 20

10


Design/Model Level DP Recognition Tools

Current state of art (Kim and Lu, ICECCS’06):

Translate RBML and UML into Prolog (Kim and Shen, SAC’07, SQJ 2008): RBMLCC

Plug-in to IBM Rational Rose Patterns are specified by meta-models in RBML Applied to 7 of the 23 GoF patterns Used class diagram only

Problems Unclear about precision and recall rate. Behaviour features of DPs are not considered.

Sep

t. 20

10


Our Approach

Model intermediate

representation



Model Analyzer

UML diagram: Class diagram + sequence diagram

Specification of design patterns in first order logic

Pattern Library

Based on the formal descriptive semantics of the UML language

Statements in first order predicate logic

Logic inference engine

Sep

t. 20

10


Implementation 1: LAMBDES-DP

Model intermediate

representation


Model Analyzer




Pattern Library

LAMBDES: Logic Analyser of Models and Meta-Models Based on Descriptive Semantics of UML

Logic statements in SPASS format

SPASS: A general purpose first order predicate logic inference engine

UML Meta-Model

Sep

t. 20

10


Implementation 2

Model intermediate

representation



Model Analyzer



Pattern Library

UML to SPASS translator

Logic statements in SPASS format

SPASS

Sep

t. 20

10


Implementation 3

Model intermediate

representation



Model Analyzer



Pattern Library

UML to Prolog translator

Prolog statements

Prolog Interpreter

Sep

t. 20

10


Formalisation of DPs

Two approaches in the literature:Definition of the structural and behavioural feat

ures of design patterns Using a graphic meta-modelling language

Extension of UML meta-model Devise new meta-modelling language

Using formal logics

Transformation of “non-standard” designs into instances of patterns e.g. Lano et al. (1996)

Sep

t. 20

10


Specification of DPs as Graphic Meta-ModelsWell-known works

Lauder and Kent (1998): UML meta-model

Le Guennec et al. (UML 2000): an extension of the UML meta-model and OCL

Eden (2001): the graphical language LePUS

Mapelsden et al. (CRPIT ’02): Design Pattern Modeling Language

Kim, France, Ghosh, and Song (COMPSAC 2003): Role-based metamodelling language RBML

Sep

t. 20

10


Problems in Graphic Meta-Modelling

Expressiveness: Difficult (if not impossible) to specify negative features

such as to specify no association between two classes

Difficult (if not impossible) to specify variant features such as to specify object adapter and class adapter patterns in one

meta-model

Readability: Graphic meta-models are hard to understand

Precision: Meta-modelling languages are usually informally defined It is non-trivial to define what is an instance of a meta-model

Thus, the need of OCL

Sep

t. 20

10


Formalisation of DPs in Formal Logics

Well-known works Mikkonen (ICSE’98):

the use of predicate logic to specify structural features Taibi (2003, 2006):

the use of first order predicate logic to specify structural features and temporal logic to specify behavioural features

Bayley and Zhu (SEFM’07, COMPSAC’08, QSIC’08, JSS 2010): GEBNF definition of UML abstract syntax Formal predicate logic induced from GEBNF syntax

definition Specify both structural and behavioural features

Sep

t. 20

10


Our Work on Specification of DPs

Formal meta-modelling in first order logic (Bayley and Zhu 2007, 2008, 2009, 2010)

Basic ideas: The abstract syntax of UML diagrams specified in G

EBNF (Graphically Extended BNF). A formal predicate logic (FOL) language systematic

ally derived from the abstract syntax definition Specifying design patterns in the FOL as predicate o

n UML diagrams and pattern instantiation is predicate satisfaction.

Sep

t. 20

10


GEBNF: ExampleClassDiagram ::=

classes : Class+,assocs, inherits, CompAg : Rel*

Class ::=name : String , [attrs : Property*],[opers : Operation*]

Rel ::=[name : String ], source, end : End

End ::=node : Class, [name : String ], [mult : MultiplicityElement]

Function symbol: function induced from the syntax definition. For example, classes is a function from “ClassDiagram” to the set of “Classes” in the diagram.

Non-terminal symbol: the type of entities in the model.

Terminal symbol: the basic entities that may occur in a model. For example, here ‘String’ represent any string of characters can be used as the name of the relation.

Referential occurrence of non-terminal symbol: the model construction contains a reference to an existing element of the type of entities. Here, the end of a relation refers to an existing class in the diagram.

Sep

t. 20

10


Example: Template Method pattern

=

Sep

t. 20

10


Comparison with Other Approaches Expressiveness:

Both structural feature and behavioural features are specified in the same FOL

Variants of patterns can be specified All 23 GoF patterns are specified

Readability: More readable than its rivals

Tool support Facilitate reasoning,

To formally prove patterns’ properties and relationships To recognise pattern instances in designs

Facilitate operations and transformations of DPs E.g. to compose patterns: A Calculus of DP Composition

Sep

t. 20

10


Our Work on Semantics of UML

Semantics of UML models

(Shan and Zhu, 2008, 2009)Basic Ideas: the formal semantics of UML is def

ined separately on two aspects: descriptive semantics:

defines which systems are instances of a model. e.g. the system consists of two classes A and B, and A is a

subclass of B. functional semantics:

defines the basic modeling concepts, e.g. If class X is a subclass of Y, then all instances of X are

also instances of Y.

It describes the system without referring to what is meant by class and subclass.

It defines the notion of class and subclass.

Sep

t. 20

10


Translation of models into Formal Logic

Signature mapping: rules to derive symbols of FOL from the metamodel Axiom mapping: rules to derive statements in the FOL from the metamodel

that must be true for all valid models Translation mapping: rules to translate a graphical model into predicates in

FOL that it is true if and only if a system is an instance of the model Hypothesis mapping: rules that selected by the user to be applied in order to

characterise the context in which the model is used

Sep

t. 20

10


Example: The following is a subset of the

predicates generated from the diagram

Sep

t. 20

10


Bridging the Gap Differences between the FOL for DP spec and the FOL

for UML semantics Syntactic difference Semantic difference

Predicates in a DP specification are evaluated on UML models Predicates in the descriptive semantics of UML models are evaluated

on software systems DP specification is translated into the syntax of FOL

for descriptive semantics

Sep

t. 20

10


Example: The specification of Template Method can be translated

into:

Sep

t. 20

10


P is a pattern.Spec(P) is the formal specification of P.

The descriptive semantics of model m.

System s is an instance of model m.

System s satisfies the specification.

Recognition of a pattern at design level becomes a logic inference problem.

Sep

t. 20

10


The Tool LAMBDES-DP

Sep

t. 20

10


Experiments:

1. Use StarUML to produce design instances as UML diagrams and export them as XMI representations.

2. Use LAMBDES to convert these XMI representations to FOL;3. Use LAMBDES to check these FOL representations for consiste

ncy errors, revising them until there are no more errors;4. For each pattern, use LAMBDES-DP to determine if the model c

onforms to (i.e. implies the specification of) the pattern. Three possible outcomes:

Proof Found, meaning definitely yes, Completion Found, meaning definitely no, and Time Out, meaning that no proof was found in the maxim

um time limit that SPASS allows, which is 990 seconds.

Sep

t. 20

10


Subjects of the experiments

Patterns: 23 Patterns in GoF book

Design Instances:Two sets of design instances were produced manually

from the diagrams in the GoF book. Set 1 (Class Only): contains a class diagram for each

of the 23 patterns in the book. Set 2 (Class + Seq): contains class and sequence dia

grams for the only 6 patterns in the book that contain both.

Sep

t. 20

10


Overview of the Design Instances: ClassOnly Set

Sep

t. 20

10


Overview of the Design Instances: Class+Seq Set

Sep

t. 20

10


Experiment Results

ClassOnly Class+Seq

Recall

(False negative error rate)

0% 0%

Precision

(False positive error rate)

< 22% 0%

Why is the false positive error rate so high for class only subjects?

Can we improve the error rate?

Is there a limit to which the error rate can be improved?

Sep

t. 20

10


Why is the error rate is so high?

Interdependence between patterns Inadequate specification of design patterns Inclusive relationships between patterns

Redundancy in the subject models used in the experiment a model for testing its conformance to one pattern

may coincidently contain an instance of another pattern

Sep

t. 20

10


Inclusion Relation on Patterns

Definition 1. (Inclusion relation on patterns)

A pattern A includes pattern B if the logic specification of pattern A implies the logic specification of pattern B. Formally,

Spec(A) Spec(B).

Theorem 1.

For all patterns A and B, if a model contains an instance of pattern A, then the model must also contains an instance of pattern B if A includes B.

Sep

t. 20

10


Redundancy in test models

Definition 2. (Inclusion relation on models)A model A structurally includes (or includes for short) model B if B can be obtained by deleting some elements and systematically renaming the elements in B. In such a case, we say that model A is a superset of model B, or B is a subset of model A.

Theorem 2. For all models A and B, if model B contains an instance of a DP and B is a subset of model A, then, A also contains an instance of the DP.

Sep

t. 20

10


Inclusions between DP Specs and Test Models

Sep

t. 20

10


The limit of false positive error rates

Definition 3. (Minimal model of design pattern)

A model M is a minimal model of a design pattern DP, if it contains an instance of pattern DP and any model obtained by removing an element from M contains no instance of pattern DP.

Corollary of Theorem 2.

For all sets of models to test the same set of specifications of the design patterns used in the experiment, the error rate of false positives must be greater than or equal to the error rate obtained in the test on the minimal models.

Sep

t. 20

10


Results of Testing against Minimal Models

The error rate is ≈8%.

Sep

t. 20

10


Conclusion:

Recognition of patterns at design level can be accurate with good precision and recall rate;

Behavioural feature is crucial for accurate specification and hence the recognition of patterns, as we have argued in (Bayley and Zhu, COMPSAC 2008);

Sep

t. 20

10


Future work

Experiment with industrial real systems Integration with code level tools

Some tools extract information from code and represent the extracted information in the form of first order logic predicates

Sep

t. 20

10


References I. Bayley and H. Zhu. Formalising design patterns in predicate logic. In Proc.

of SEFM’07, pp 25–36. I. Bayley and H. Zhu. Specifying behavioural features of design patterns in fi

rst order logic. Proc. of COMPSAC’08, pp203–210. L. Shan and H. Zhu. A formal descriptive semantics of UML. Proc. of ICFE

M’09, pp375–396. H. Zhu, I. Bayley, L. Shan and R. Amphlett, Tool Support for Design Pattern

Recognition at Model Level, Proc. of COMPSAC'09, July 2009. L. Shan and H. Zhu, Semantics of Metamodels in UML, Proc. of TASE’09,

Aug. 2009 H. Zhu, L. Shan, I. Bayley and R. Amphlett, A Formal Descriptive Semantics

of UML And Its Applications, in UML 2 Semantics and Applications, Kevin Lano (Eds.), John Wiley & Sons, pp95-123, Nov. 2009.

I. Bayley and H. Zhu, Formal Specification of the Variants and Behavioural Features of Design Patterns, Journal of Systems and Software Vol. 83, No. 2, Feb. 2010, pp 209–221

Recognition of Patterns in Software Designs Models via Logic Inferences

Documents

Transcript of Recognition of Patterns in Software Designs Models via Logic Inferences