wop towards a web of patterns - · meta-meta model) or an uml profile that specifies the following...

Web of Patterns (WOP) © Jens Dietrich - 2004

WOP Towards a Web of Patterns

Jens DietrichMassey UniversityEmail: [email protected]: http://www-ist.massey.ac.nz/JBDietrich/


Overview

• Formalizing Design Patterns

• Semantic Web

• Why not UML

• Meta Modeling Architecture Used

• Services

• Tool Support

• Tool Presentation

• Related Work

• Future Work


Background: OO Design Patterns

• Software design patterns have been made popular by the GangOf4 catalogue in the mid 90ties.

• Approach to re-use design and to facilitate communication between software engineers.

• Intention: re-use across different PL’s.

• But design re-use makes sense on a more detailed level as well (i.e. using PL dependent features such as nested classes, meta-tags and interfaces) = PL dependent pattern catalogues.


Formal Representation of Design Patterns

• Patterns usually defined semi-formal using textual description and UML diagrams.

• Using UML is technically not correct – UML does not include the concept of a variable.

• Using UML would require a new modeling language (defined using the MOF M3 meta-meta model) or an UML profile that specifies the following entities and their relationships:

• Patterns

• Class templates (or roles)

• Method templates

• Field templates

• Other pattern participants: templates for static blocks, assertions, meta tags, interfaces, packages/units etc

• Further disadvantage: UML more suitable to build monolithic models, flexible sharing/extending not well supported (although possible using XMI).


Using OWL instead of UML

• OWL (web ontology language) is cornerstone of the semantic web technology.

• Suitable modeling language for communities sharing knowledge.

• No central model, models grow “uncontrolled” (everybody can create models, but there will be natural selection).

• Flexible association of knowledge with meta information (e.g. Dublin Core) – forms the base for reasoning (e.g. to deal with inconsistencies, to find the models we trust).

• Introducing ODOL (Object Design Ontology) – System of OWL classes representing Design Patterns and their participates.

• The PDL (Pattern Description Language) – documents containing RDF statements using the vocabulary defined in ODOL and other vocabularies (in particular Dublin Core). Resources are instances of ODOL classes.


Meta Model Architecture

application objects (corresponds to OMG M0)e.g. transactions, customers, windows

application classes (corresponds to OMG M1)e.g. Transactions, Customers, Window

PDL pattern description layere.g. AbstractFactory.Creator, Singleton.StaticField

ODOL object design ontology layere.g. ClassTemplate, MemberTemplate, Pattern

OWL layer (corresponds to OMG M3)e.g. owl:Class, owl:ObjectProperty

abst

ract

ion

inst

antia

tion


(OWL-) Classes in ODOL

owl:Thing

Participant Pattern PatternCatalog

ClassTemplate MemberTemplate

ConstructorTemplate FieldTemplateMethodTemplate


URIs for Patterns and Participants

• Resources are represented by URIs (uniform resource identifiers, a generalization of URLs).

• URIs are built as follows:

http://www.massey.ac.nz/iist/cs/pattern/ontology#AbstractFactory.ConcreteFactory.Creator

base URI pattern participant (role)


An Alternative Approach• Description given here is top-down approach.• Bottom-up approach is possible as well.• Based on partial isomorphisms between “software structures”:

f: (A,L,R,P) � (A’,L,R,P) • (A,L,R,P) consisting of artifacts (classes, methods,..), literals (booleans,

integers, strings), binary relations between artifacts and properties – binary relations between artifacts and literals.

• A isomorphisms h is a one-to-one mapping that preserves the structure: • IF R(a1,a2) THEN R(h(a1),h(a2))• IF R(a,l) THEN R(h(a),l)• IF a1!=a2 THEN h(a1)!=h(a2)

• These properties can be used to establish equivalence classes of structures. These classes are the design patterns.

• This is an extensional definition: patterns as classes of their instances. Vs intentional definition starting with abstract concepts.


Physical Design

AbstractFactory.rdfpattern description

wop-catalogue.rdfpattern catalog

Singleton.rdfpattern description

...pattern description

wop.rdfvocabulary

<owl:imports/><owl:imports/>

<owl:imports/> <owl:imports/>

<owl:imports/>

<owl:imports/>

All documents have an http://www-ist.massey.ac.nz/wop/ prefix and the URI are actual URLs of documents on the respective Massey web server.

Core ODOL PL independent

PDLlayer

Application entry point –can be extended by adding / removing import statements


Example Pattern: AbstractFactory

AbstractFactory

AbstractProduct ConcreteProduct

ConcreteFactory

AbstractFactory.Creator ConcreteFactory.Creator

isSubclassOf

returnType returnType

contains contains

isSubclassOf

overrides

abstractisAbstract

concrete

concrete

isAbstract

isAbstract

abstract

abstract

isAbstract

isAbstract

concreteisAbstract

get*create*build*

namingPatternsget*create*build*

namingPatterns

*SourceDefault**Fact**Impl

namingPatterns

*SourceAbstract**Fact*

namingPatterns

OWL/RDF is a simple modeling language – modeling primitives are resources, relations and literals. “Less is more” – inspired by simplicity of hyper text.


Using the Formal Pattern Descriptions

catalogue

Model (PL specific constraint semantics for ODOL properties)

Scanner (implemented in a PL)

Services

pattern pattern

Massey ODOL

WEBWEB


From OWL/RDF to Logic (PL1)

• OWL predicates mapped to binary predicate symbols.

• Patterns and participants (instances of *Template OWL classes) mapped to variables.

• Therefore, pattern instances are defined by derivation rules:

∧∧∧∧i Pi(<parti1 >,<parti2>) ∧∧∧∧ ∧∧∧∧j Pj(<partj>,literalj) � pattern_instance(<part1 >,..,<partn >)

• Reasoning is straight forward (no functions, no negation, no disjunctions – semantic given by least Herbrand model) if fact base is known.

• Challenges: • find fact base.• Implement effective reasoning strategy (standard unification like in

Prolog not effective).


Building the Fact Base

• Software artifacts must be represented (unique names).

• Semantic of target language: when is a fact p(a1,a2) in the fact base. E.g., when is subclassOf(class1,class2) true.

• Can be straight forward for some predicates – simply use reflection facility on target language.

• Other means:• Reflection using meta info (JSR-175 standard)• Source code analysis (predicates like isActualReturnType)• Documentation analysis (e.g., use XDoclet to detect formal pattern

documentation) • Naming patterns• Dynamic analysis (run and observe)


Some Observations

• Code analysis might not be sufficient (e.g. in patterns such as Dynamic Linkage external configuration files are used to set participants).

• In this case, a pattern instance could still have unbound variables (the implementation class).

• The patterns description language does not support negation. E.g., in patterns such as Immutable statements such as “no method writes instance variables” must be defined. Walk around: this can be defined as atomic property for classes (“isImmutable”).


Some More Observations

• Using naming patterns seems to be unreliable but:• might be necessary when interacting with external systems (e.g. to

describe a RemoteProxy / Ambassador pattern)• Anyway, naming conventions are used to “publish” the semantics of

artifacts (set*/get* methods, add*Listener/remove*Listener in the JavaBeans spec).

• What about instances having with artifacts being instances of more than one template (e.g. Factory = Product in some instances of AbstractFactory).

• Some concepts can be modeled as derived or primitive concepts. Impact on tools: Deriving them requires reasoning capabilities, having more primitives makes blows up the language and can make it inconsistent w.r.t. intended meaning (e.g., “isImmutable”).


Java Libraries / Programs (binary and

src representation)

The WOP Pattern Scanner for Java

RDF Model (using HP Jena)

Constraints

ConstraintResolver

catalogue

pattern pattern

Massey ODOL

WEBWEB

Workspace

Java Libraries / Programs (binary and

src representation)

Facts are build on demand based on

conceptual knowledge (already made variable

bindings)

Build from folders, jar

files, zip files and class

lists


The Workspace

• Contains references to (different representations of) software artifacts: reflection classes, source code references, AST objects.

• Can be built from various sources: memory, files, archives (jar/zip).

• Other sources (support not yet implemented): (http,ftp) network, cvs, Eclipse environment.

• Progress listeners can be plugged-in to monitor activities.


Constraints

• Implemented for the predicates of the relations defined in ODOL.

• Constraints = predicates in the above-mentioned fact base.

• These implementations are the semantics of the relations in the context of the PL.

• In terms of formal logic: they have methods returning a boolean defining the Herbrand base for the pattern derivation rules.


The Constraint Resolver

• Based on a constraint scheduler.

• Scheduling tries to resolve easy to verify constraints first.

• Manual scheduling possible as well (text files).

• Binary constraints return iterator for possible instances of a slot if the other slot variable has a binding. These instances are returned w.r.t. workspace.

• Performance ok but can be improved.


Constraints - Example

public class CONTAINS_FIELD extends AbstractBinaryConstraint {public String getName() {

return ‘’contains’’;}public boolean check(Object object1, Object object2, Workspace workspace) {

Class clazz = (Class) object1;Field field = (Field) object2;Field[] fields = clazz.getDeclaredFields();for (int i = 0; i < fields.length; i++) {

if (field.equals(fields[i])) return true;}return false;

}// Get the instances of the first slot if the instance of the second slot is known.public Iterator getPossibleInstances1(Workspace workspace, final Object obj2) {

Field f = (Field) obj2;return IteratorUtils.singletonIterator(f.getDeclaringClass());

}

// Get the instances of the second slot if the instance of the first slot ispublic Iterator getPossibleInstances2(Workspace workspace, final Object obj1) {

try {Field[] fields = ((Class) obj1).getDeclaredFields();return IteratorUtils.arrayIterator(fields);

} catch (Throwable x) {LOG_WOP.warn("Cannot get field for class " + obj1, x);return IteratorUtils.emptyIterator();

}


Java Libraries / Programs (binary and src represent.)

Adding SourceCode Analysis

• Proof of Concept done by Chris Elgar (BE project).

• Idea: use Eclipse AST (abstract source tree) API.

• New layer, encapsulated by factories and global environment property that detects the presence of tools.

RDF Model (using HP Jena)

Constraints

ConstraintResolver

WEBWEB

Workspace

EclipseConstraints

Tool dependent layer (e.g. Eclipse)

Java Libraries / Programs (binary and src represent.)


Integration into Agile SE – the WOP ANT task

compile

test

package (jar)

WOP

metrics

ANT build

src

lib

classes

• by Chris Elgar (BE project).

(html) pattern

report(s)

Apache VelocityTemplate Engine

deploy

(java)doc

junitreport

Jdepend /cloverreports

workspace


Example Results: Searching for AbstractFactories

Time

(ms)

Pattern Instances

ClassesLibrary

1,0164182WOP 0.1The pattern scanner itself.

1,830,187ms = 30.5 min

79817Xerces 2.6.2

Apache XML Parser and W3C DOM but no SAX APIs.

11,39044358Mandarax 3.3.1Java API for derivation rules.

9,96821104JDBC (java.sql and javax.sql) and MySQL Connector J DriverDatabase connectivity API and implementation for MySQL database.

32,3594610AWT and Swing (JDK 1.4.2 for Windows)Standard java GUI Libraries.

Platform/SW: Eclipse 3.0, SUN JDK 1.4.2, Win XP HomePlatform/HW: Pentium 3.06, 512 MB RAMWOP/Config: LOG Level is INFO (includes progress logging)Results non conclusive, some AST features not yet supported (e.g., anonymous inner classes)


Related Work

C. Krämer, L. Prechelt 96: Use Prolog Rules (Prolog based scanner, concepts are prolog predicates).

J. Dong, S. Yang 2003: UML Profile for Design Patterns.

A. Eden 2002: Higher order predicate logic to define patterns.

D. Mapelsden, J. Hosking, J. Grundy: DPML. Visual language to define patterns.

PMD – open source project (former DARPA project !), XPath (DOM query language) can be used to define anti-patterns in source code.


Next Steps

• Some more formalize – run – analyze loops.

• Add more patterns.

• Implement more constraints.

• Improve scanner performance.

• Cover antipatterns (this is just doing) and refactorings.

• Extend ontology.

• Reach the critical mass.

• Get the SE community involved (through research collaboration and open source project).

wop towards a web of patterns - · meta-meta model) or an uml profile that specifies the following...

Documents