Recognition of Patterns in Software Designs Models via Logic Inferences Hong Zhu Department of Computing and Electr onics Oxford Brookes University Oxford OX33 1HX, UK Email: [email protected]
Jan 28, 2016
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
3Seminar: Recognition of Patterns in Design Models
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
4Seminar: Recognition of Patterns in Design Models
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
5Seminar: Recognition of Patterns in Design Models
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
6Seminar: Recognition of Patterns in Design Models
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
7Seminar: Recognition of Patterns in Design Models
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
8Seminar: Recognition of Patterns in Design Models
Design/Model Level DP Recognition Tools
Model intermediate
representation
Pattern Library
Pattern Match Engine
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
9Seminar: Recognition of Patterns in Design Models
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
10Seminar: Recognition of Patterns in Design Models
Our Approach
Model intermediate
representation
Pattern Match Engine
Software Design Model
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
11Seminar: Recognition of Patterns in Design Models
Implementation 1: LAMBDES-DP
Model intermediate
representation
Software Design Model
Model Analyzer
UML diagram: Class diagram + sequence diagram
Specification of design patterns in first order logic
Pattern Match Engine
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
12Seminar: Recognition of Patterns in Design Models
Implementation 2
Model intermediate
representation
Pattern Match Engine
Software Design Model
Model Analyzer
UML diagram: Class diagram + sequence diagram
Specification of design patterns in first order logic
Pattern Library
UML to SPASS translator
Logic statements in SPASS format
SPASS
Sep
t. 20
10
13Seminar: Recognition of Patterns in Design Models
Implementation 3
Model intermediate
representation
Pattern Match Engine
Software Design Model
Model Analyzer
UML diagram: Class diagram + sequence diagram
Specification of design patterns in first order logic
Pattern Library
UML to Prolog translator
Prolog statements
Prolog Interpreter
Sep
t. 20
10
14Seminar: Recognition of Patterns in Design Models
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
15Seminar: Recognition of Patterns in Design Models
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
16Seminar: Recognition of Patterns in Design Models
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
17Seminar: Recognition of Patterns in Design Models
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
18Seminar: Recognition of Patterns in Design Models
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
19Seminar: Recognition of Patterns in Design Models
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
20Seminar: Recognition of Patterns in Design Models
Example: Template Method pattern
=
Sep
t. 20
10
21Seminar: Recognition of Patterns in Design Models
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
22Seminar: Recognition of Patterns in Design Models
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
23Seminar: Recognition of Patterns in Design Models
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
24Seminar: Recognition of Patterns in Design Models
Example: The following is a subset of the
predicates generated from the diagram
Sep
t. 20
10
25Seminar: Recognition of Patterns in Design Models
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
26Seminar: Recognition of Patterns in Design Models
Example: The specification of Template Method can be translated
into:
Sep
t. 20
10
27Seminar: Recognition of Patterns in Design Models
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
28Seminar: Recognition of Patterns in Design Models
The Tool LAMBDES-DP
Sep
t. 20
10
29Seminar: Recognition of Patterns in Design Models
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
30Seminar: Recognition of Patterns in Design Models
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
31Seminar: Recognition of Patterns in Design Models
Overview of the Design Instances: ClassOnly Set
Sep
t. 20
10
32Seminar: Recognition of Patterns in Design Models
Overview of the Design Instances: Class+Seq Set
Sep
t. 20
10
33Seminar: Recognition of Patterns in Design Models
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
34Seminar: Recognition of Patterns in Design Models
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
35Seminar: Recognition of Patterns in Design Models
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
36Seminar: Recognition of Patterns in Design Models
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
37Seminar: Recognition of Patterns in Design Models
Inclusions between DP Specs and Test Models
Sep
t. 20
10
38Seminar: Recognition of Patterns in Design Models
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
39Seminar: Recognition of Patterns in Design Models
Results of Testing against Minimal Models
The error rate is ≈8%.
Sep
t. 20
10
40Seminar: Recognition of Patterns in Design Models
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
41Seminar: Recognition of Patterns in Design Models
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
42Seminar: Recognition of Patterns in Design Models
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