Transcript SOUL

Declarative Meta Programming
Dr. Kim Mens ([email protected])
Programming Technology Lab
Vrije Universiteit Brussel
http://prog.vub.ac.be
© Programming Technology Lab
1
Overview of the presentation
Part 1: Declarative Meta Programming at
the Programming Technology Lab
Part 2: Declarative Meta Programming for
checking architectural conformance
May 2001
© Programming Technology Lab
2
Part 1
Declarative Meta Programming …
… at the Programming
Technology Lab
http://prog.vub.ac.be
© Programming Technology Lab
3
Overview of Part 1
 Declarative Meta Programming
 Logic Meta Programming
DMP =
Declarative Meta Programming
 Applications of DMP
 SOUL
 TyRuBa
 QSOUL
 SOUL for Java
 Conclusion
May 2001
© Programming Technology Lab
4
Overview
 Declarative Meta Programming
 Logic Meta Programming
 Applications of DMP
 SOUL
 TyRuBa
 QSOUL
 SOUL for Java
 Conclusion
May 2001
© Programming Technology Lab
5
Declarative Meta
Programming (DMP)
DMP = Declarative Meta Programming
Combines declarative meta language with
standard (object-oriented) base language
base-level programs are expressed as terms,
facts and rules at the meta level
meta-level programs can manipulate and
reason about base-level programs
May 2001
© Programming Technology Lab
6
Declarative Reasoning
 Declarative programming language
 readable, intuitive, intentional, concise
 e.g., a logic programming language
 Declarative reasoning
 use a declarative programming language to reason about
structural aspects of source code in some base language
 check source against certain constructs, conventions, patterns
 search source for certain constructs, conventions, patterns
 extract certain constructs, conventions, patterns from source
 enforce certain constructs, conventions, patterns in source
 generate source from high-level declarative descriptions
 transform source based on high-level declarative descriptions
May 2001
© Programming Technology Lab
7
Overview
 Declarative Meta Programming
 Logic Meta Programming
 Applications of DMP
 SOUL
 TyRuBa
 QSOUL
 SOUL for Java
 Conclusion
May 2001
© Programming Technology Lab
8
Logic Meta Programming
 LMP = Logic Meta Programming
 LMP is particular flavour of DMP
 Meta language is a PROLOG-like logic
programming language
 Logic programming is good at
 meta programming
 language processing
 reasoning about knowledge
 unification, backtracking, multi-way reasoning
May 2001
© Programming Technology Lab
9
Logic Meta Programming
Reasoning about the structure of OO
systems using the Smalltalk Open
Unification Language (SOUL)
 Roel Wuyts, Declarative Reasoning about the Structure of
Object-Oriented Systems. In Proceedings of TOOLS USA
1998, pages 112-124. IEEE Computer Society Press, 1998
May 2001
© Programming Technology Lab
10
Overview
 Declarative Meta Programming
 Logic Meta Programming
 Applications of DMP
 SOUL
 TyRuBa
 QSOUL
 SOUL for Java
 Conclusion
May 2001
© Programming Technology Lab
11
Applications of DMP
 What is DMP used for at PROG?
 Emerging technique to build state-of-the art software
development tools
 In particular, tools to support co-evolution in all facets
and phases of the software life-cycle
 information in implementation and earlier life-cycle phases
may evolve independently
 need to keep information in these phases synchronised
 To support advanced software engineering
techniques
 DMP is unifying approach that combines the
research of many PROG researchers
May 2001
© Programming Technology Lab
12
Applications of DMP
Co-evolution of design and
implementation
 Extract design information from the implementation.
 Verify the implementation with the corresponding design.
 Generate the implementation from the design
 Synchronize implementation and design
 Theo D'Hondt, Kris De Volder, Kim Mens & Roel Wuyts, Co-evolution
of Object-Oriented Software Design and Implementation. In
Proceedings of SACT 2000. Kluwer Academic Publishers, 2000
 Roel Wuyts, A Logic Meta-Programming Approach to Support the
Co-Evolution of Object-Oriented Design and Implementation. PhD
thesis, Dept. of Computer Science, VUB, Belgium. January 2001
May 2001
© Programming Technology Lab
13
Applications of DMP
Architectural conformance checking
Use logic programs to declare software
architectures declaratively and check them
against the implementation
 Kim Mens, Automating Architectural Conformance Checking by
means of Logic Meta Programming, PhD thesis, Dept. of
Computer Science, VUB, Belgium. October 2000
May 2001
© Programming Technology Lab
14
Applications of DMP
Code optimization & change propagation
a functional language with logic extensions to
write declarative code transformations that
detect propagation of changes to source code
replace design patterns by optimized
implementations
 Tom Tourwe, Optimizing Object-Oriented Languages Through
Architectural Transformations, Published in Proceedings of the 8th
International Conference on Compiler Construction.
May 2001
© Programming Technology Lab
15
Applications of DMP
Code Generation
TyRuBa
very expressive type system (“Type Rule Base”)
generate implementation from logic descriptions
precompiler that uses logic programs to generate
(Java) code
 Kris de Volder, Type-Oriented Logic Meta Programming for Java,
PhD thesis, Dept. of Computer Science, VUB, Belgium.
September 1998
May 2001
© Programming Technology Lab
16
Applications of DMP
Aspect-Oriented Programming (AOP)
Aspect-Oriented Logic Meta Programming
Expressing domain knowledge as a separate
aspect that can be factored out from the base
program
Declarative combination of aspects
 Kris De Volder & Johan Brichau
May 2001
© Programming Technology Lab
17
Applications of DMP
Guiding reuse
 Maja D’Hondt
 Wolfgang De Meuter
May 2001
© Programming Technology Lab
18
Overview








Declarative Meta Programming
Logic Meta Programming
Applications of DMP
SOUL
TyRuBa
QSOUL
SOUL for Java
Conclusion
May 2001
© Programming Technology Lab
19
SOUL
 SOUL = Smalltalk Open Unification Language
 Prolog-like meta language
 Smalltalk as base language
 Strong symbiosis between logic language and
Smalltalk
 Logic language works directly on current Smalltalk
image
 Smalltalk entities can be used as constants in the
logic language
 Logic clauses can execute parameterised Smalltalk
expressions
May 2001
© Programming Technology Lab
20
SOUL: set-up
Reason about and manipulate
source code:
check, extract, search,
generate, enforce, transform
May 2001
© Programming Technology Lab
Meta-level Interface
SOUL
Smalltalk
Image
Smalltalk
implementation
artefacts
21
SOUL: the language
 SOUL language
 Prolog
 Constants, variables, functors, lists
 Predicates, facts, rules, queries
append(<?car | ?cdr>,?list, <?car | ?res>) if
append(?cdr,?list,?res)
 Symbiosis with Smalltalk
 Smalltalk term, Smalltalk object
 Smalltalk clause
 Generate-predicate
class(?class) if
[SOULExplicitMLI current isClass: ?class].
May 2001
© Programming Technology Lab
23
SOUL: symbiosis with ST
“Smalltalk clause”
Execute parameterized Smalltalk expressions
write(?text) if
[Transcript show: (?text asString). true].
smallerThan(?x,?y) if
atom(?x),atom(?y),
[?x < ?y].
May 2001
© Programming Technology Lab
25
SOUL: symbiosis with ST
“Smalltalk term”
Represent Smalltalk objects in SOUL clauses.
Smalltalk object is the result of the evaluation
of the parameterized Smalltalk expression.
plus(?x,?y,[ ?x + ?y ]).
if class([Array])
allClasses([Smalltalk allClasses])
aInteger object
May 2001
© Programming Technology Lab
aCollection object
26
SOUL: symbiosis with ST
“Generate” predicate
Disassembles a Smalltalk collection into
subsequent results of the generate-clause
class(?class) if
generate(?class,[SOULExplicitMLI current allClasses])
aClass
May 2001
aCollection object containing
all classes.
© Programming Technology Lab
27
SOUL: reflection mechanism
Meta-language: SOUL
Base-language: Smalltalk
Symbiosis
“down”
“up”
Smalltalk values can be used in SOUL
‘up’ of ST-values: explicit wrapper for ST-objects
defining the unification on ST-objects.
SOUL values can be used in Smalltalk
‘down’ of ‘upped ST-values’: ST-value.
But: ‘down’ of SOUL-values: ongoing research…
May 2001
© Programming Technology Lab
28
SOUL: reflection mechanism
SOUL
[ SOULExplicitMLI current isClass: ?class ]
“down”
[false]
“up”
Smalltalk
[:env | (SOULExplicitMLI current
false
isClass: (env at: 1) soulDown) soulUp ]
May 2001
© Programming Technology Lab
29
SOUL: a layered declarative
reasoning Framework
Architectural
Layer
Design
Patterns
Layer
Coding
Conventions
Layer
Base
Layer
Representation
al
Layer
Repositoryaccess
Layer
May 2001
isClassifiedAs
findMethodsFromClasses
findMetaClassedFromClasses
factoryMethod
compositePattern
instanceCreationMethod
isSentTo
hierarchy
traverseMethodParseTree
classImplementsMethodNamed className inheritance
classImplementsMethod methodName
protocolName
metaClass methodInProtocol
artefact
artefactNestingID
© Programming Technology Lab
30
SOUL: example
Composite Design
Pattern:
look for all the possible
composite classes,
where the component is
VisualPart:
if compositePattern([VisualPart],?comp,?sel)
May 2001
© Programming Technology Lab
31
SOUL: example
compositePattern(?comp,?composite,?msg) if
compositeStructure(?comp,?composite),
compositeAggregation(?comp,?composite,?msg).
compositeStructure(?comp,?composite) if
class(?comp),
hierarchy(?comp,?composite).
compositeAggregation(?comp,?composite,?msg) if
commonMethods(?comp,?composite,?M,?compositeM),
methodSelector(?compositeM,?msg),
oneToManyStatement(?compositeM,?instVar,?enumStatement),
containsSend(?enumStatement,?msg).
May 2001
© Programming Technology Lab
32
SOUL:
the repository inspector
Construct and
execute queries
Browse and edit
(hierarchic) repository
structure
Inspect logic
facts and rules
May 2001
© Programming Technology Lab
33
SOUL:
the query inspector
May 2001
© Programming Technology Lab
34
Overview








Declarative Meta Programming
Logic Meta Programming
Applications of DMP
SOUL
TyRuBa
QSOUL
SOUL for Java
Conclusion
May 2001
© Programming Technology Lab
35
TyRuBa
Allows to write generic templates of
software modules by means of DMP
More high-level description of the software
Code generator instantiates these
templates
Logic inference process
Generic templates are represented using
logic declarations (facts & rules)
May 2001
© Programming Technology Lab
36
TyRuBa: set-up
TyRuBa core-language implementation
Logic Program
=
Init Files
+
User Rules
Represents
Set Of
Logic Propositions
Queries
Code Generator
Outputs
Java Source Code
May 2001
© Programming Technology Lab
37
TyRuBa: code generation
Java Programs are represented by facts.
To generate Java code, we can use logic programs to
describe the Java programs we want to generate!
Logic Program
Represents
Set of logic propositions
Represents
Base Language Program
May 2001
© Programming Technology Lab
38
TyRuBa: the language
TyRuBa language
Prolog
Constants, variables, functors, lists
Predicates, facts, rules, queries
Code generation constructs
QuasiQuotedCode term
Core code generator
May 2001
© Programming Technology Lab
39
TyRuBa:
Code generation contstructs
 Quasiquoted term
 Allows to write down parameterized chunks of source
code.
class(Array<?el>,{private ?El[] contents; … })
 Code Generator
 Assembles chunks of code into working program
 A core code generator exists
 This code generator can be fine-tuned
May 2001
© Programming Technology Lab
40
TyRuBa: example
class(Array<?El>,{
private ?El[] contents;
Generic Java array
/** Construction */
Array<?El>(int sz) { contents = new ?El[sz]; }
/** Basic Array functionality */
?El elementAt(int i) { return contents[i]; }
void setElementAt(?El e,int i) { contents[i]=e; }
int length() { return contents.length; }
}).
Java array for strings
Code generator
class Array_LString_R {
private String [ ] contents ; Array_LString_R ( int sz ) { contents = new String [ sz ] ; }
String elementAt ( int i ) { return contents [ i ] ; }
void setElementAt ( String e , int i ) { contents [ i ] = e ; }
int length ( ) { return contents . length ; }
}
May 2001
© Programming Technology Lab
41
TyRuBa example:
visitor design pattern
Design Patterns [Gamma&al.] capture solutions to common problems
which are encountered while designing software.
The implementation of a design pattern typically
• spans several classes
• must be repeated for every instance of the pattern
Code Scattering!
Visitor intends to separate
• the basic implementation of an object structure
• from operations over this structure.
May 2001
© Programming Technology Lab
42
TyRuBa example:
visitor design pattern
abstract class Tree {
boolean isNode() { return false; }
boolean isLeaf() { return false; }
abstract Object accept(Visitor v);
}
class Node extends Tree {
boolean isNode() {return true;}
...
Object accept(Visitor v)
{ return v.visitNode(this); }
}
class Leaf extends AbstractTree {
boolean isLeaf() {return false;}
...
Object accept(Visitor v)
{ return v.visitLeaf(this); }
}
abstract class TreeVisitor {
abstract Object visitNode(Node node);
abstract Object visitLeaf(Leaf leaf);
}
Tree
isNode
isLeaf
accept
Node
Leaf
isNode
...
accept
isLeaf
...
accept
TreeVisitor
visitNode
visitLeaf
PrintVisitor
visitNode
visitLeaf
May 2001
© Programming Technology Lab
43
TyRuBa example:
visitor design pattern
Tree
1) Knowledge about this particular visitor
isNode
isLeaf
rootVisitedNode(TreeVisitor,Tree).
accept
visitedNode(TreeVisitor,Node).
visitedNode(TreeVisitor,Leaf).
2) Visitor Code Generation
abstractmethod(?RootNode,accept,...)
:- rootVisitedNode(?Visitor,?RootNode).
Node
isNode
...
accept
Leaf
isLeaf
...
accept
method(?Visited,accept,...,{...})
:- visitedNode(?Visitor,?Visited).
TreeVisitor
visitNode
visitLeaf
abstractmethod(?Visitor,visit<?Visited>,...)
:- visitedNode(?Visitor,?Visited).
May 2001
© Programming Technology Lab
44
Synchronization:
code scattering
class Stack {
public Object peek ( ) {
while (true) {
synchronized (this) {
…}
}
try { return contents [ pos ]; }
finally {
synchronized ( this ) { … }
}
public void push ( Object e ) {
while (true) {
synchronized (this) {
…}
}
try { contents[++pos]=e; }
finally {
synchronized ( this ) { … }
}
TODO
May 2001
© Programming Technology Lab
45
Synchronization:
AOP solution
Separate out ‘synchronization aspect’ from the basic functionality.
Use a special purpose synchronization aspect language
Basic functionality
class Stack {
public Object peek ( )
{ return contents[pos];}
public void push (Object e)
{ contents[++pos]=e; }
...
Aspect declarations
mutuallyExclusive(push,pop)
mutuallyExclusive(push,peek)
...
May 2001
Weaver
class Stack {
public Object peek ( ) {
while (true) {
synchronized (this) {
…}
}
try { return contents [ pos ]; }
finally {
synchronized ( this ) { … }
}
public void push ( Object e ) {
while (true) {
synchronized (this) {
…}
}
try { contents[++pos]=e; }
finally {
synchronized ( this ) { … }
}
© Programming Technology Lab
46
Using TyRuBa-LMP for AOP
Basic Functionality Code
In Java
Parser
Facts representing
basic functionality code
+
Weaver
Logic program
representing aspect
declarations
Logic Program
May 2001
© Programming Technology Lab
Java code
with
synchronization
47
Overview








Declarative Meta Programming
Logic Meta Programming
Applications of DMP
SOUL
TyRuBa
QSOUL
SOUL for Java
Conclusion
May 2001
© Programming Technology Lab
48
QSOUL:
combine TyRuBa & SOUL
QSOUL = “Quasiquoted SOUL”
SOUL expanded with quasiquoted terms
Implementation in Squeak
Idea: combination of reasoning about
code and code-generation.
May 2001
© Programming Technology Lab
49
QSOUL: ongoing research
 Ongoing research @ PROG & SSEL
 Original SOUL & TyRuBa functionality almost
finished.
 ‘down’ of SOUL values in Smalltalk?
 Reworking of quasiquoted terms
 Browsers built on top of QSOUL to
 Use ‘computed classifications’to browse code
[ Koen De Hondt: Classification Browser]
 Use ‘computed classifications’to generate code
[ ECOOP 2000 Classification WS]
May 2001
© Programming Technology Lab
50
QSOUL:
the repository inspector
May 2001
© Programming Technology Lab
51
Overview








Declarative Meta Programming
Logic meta programming
Applications of DMP
SOUL
TyRuBa
QSOUL
SOUL for Java
Conclusion
May 2001
© Programming Technology Lab
52
SOUL for Java
Can SOUL/DMP be applied to Java?
Represent Java classes as logic facts
Focus on class files
Java grammar is complicated
Source code is not always available
Class files have a more uniform
representation
Class-file format is more stable over time
May 2001
© Programming Technology Lab
53
SOUL for Java:
class file representation
May 2001
© Programming Technology Lab
54
Classes to Clauses: C2C
Written in Java
Extracts information from class files
Represents this information as logic facts
Based on existing class parser: BCEL
Byte Code Engineering Library
(formerly JavaClass)
Tested on Drawlets
May 2001
© Programming Technology Lab
55
SOUL for Java:
representation in C2C
 class(<className>).
 interface(<className>).
 accessFlag(<className>, <accessFlag>).
 superclass(<className>, <superClassName>).
 directInterface(<className>, <interface>).
 fieldAccessFlag(<className>, <fieldName>, <flag>).
 fieldDescriptor(<className>, <fieldName>, <returnType>).
May 2001
© Programming Technology Lab
56
SOUL for Java:
representation in C2C
 methodAccessFlag(<className>,<methodName>,
<argList>,<accessFlag>).
 methodReturnType(…, <returnType>).
 methodBody(…, <invokesUsedModifiedsList>)
 invokespecial(<invocation>)
 putfield(<fieldName>)
 putstatic(<fieldName>)
 getfield(<fieldName>)
 getstatic(<fieldName>)
May 2001
© Programming Technology Lab
57
C2C: example (input file)
public final class LineNumber implements Cloneable {
private int start_pc;
LineNumber(DataInputStream file) throws IOException {
this(file.readUnsignedShort(), file.readUnsignedShort()); }
public final void dump(DataOutputStream file) throws IOException {
file.writeShort(start_pc);
file.writeShort(line_number);
}
…}
May 2001
© Programming Technology Lab
58
C2C example (output file)
class(‘LineNumber’).
classAccessFlag(‘LineNumber’, public).
classAccessFlag(‘LineNumber’, final).
directInterface(‘LineNumber’, ‘java.lang.Cloneable’).
superClass(‘LineNumber’, ‘java.lang.Object’).
fieldAccessFlags(‘LineNumber’, ‘start_pc’, private).
fieldDescriptor(‘LineNumber’, ‘start_pc’, int).
methodReturnType(‘LineNumber’, ‘LineNumber’, [‘java.io.DataInputStream’], void).
methodException(‘LineNumber’, ‘LineNumber’, [‘java.io.DataInputStream’],
‘java.io.IOException’).
methodBody(…).
May 2001
© Programming Technology Lab
59
Overview








Declarative Meta Programming
Logic meta programming
Applications of DMP
SOUL
TyRuBa
QSOUL
SOUL for Java
Conclusion
May 2001
© Programming Technology Lab
60
Conclusion (of Part 1)
 DMP = use a declarative meta language to
reason about & manipulate programs written in
a standard object-oriented base language
 DMP is unifying approach that combines the
research of many PROG researchers
 Several DMP tools and environments already
exist:
 SOUL, TyRuBa, C2C, QSOUL, ...
 We use DMP as a technique to build state-of-the
art software development tools
May 2001
© Programming Technology Lab
61
Part 2
Declarative Meta Programming …
… for checking architectural
conformance
http://prog.vub.ac.be
© Programming Technology Lab
62
Software architectures
 describe the overall structure of a software
system, abstracting away from its
implementation details
 provide a simple mental picture that allows
software engineers to grasp the global structure
 facilitate the understanding of software systems
 improve maintainability, adaptability, reusability,
…
 … if they are up to date
May 2001
© Programming Technology Lab
63
Architectural drift
 Architectural erosion and drift
 implementation tends to drift away from the original
architecture
 changes are often made only at implementation level
 Solution
 architecture is more than documentation
 architectural constraints should explicitly constrain
the implementation
 need to ensure conformance of the implementation to
these architectural constraints
May 2001
© Programming Technology Lab
64
Conformance checking
 How to keep architecture and implementation
synchronised?
 Architectural conformance checking
 explicit description of the software architecture
 bi-directional conformance mapping between
architecture and implementation
 automated support for checking conformance of a
software implementation to its architecture(s)
 support for solving problems in case of conformance
breaches
May 2001
© Programming Technology Lab
65
Declarative meta
programming
use declarative meta programming to
express and enforce architectural
constraints
use logic expressions at meta-level to:
explicitly describe the software architecture
declare its mapping to the implementation
implement conformance checking algorithm
as a logic program
May 2001
© Programming Technology Lab
66
Case study: SOUL
 SOUL
 “Smalltalk Open Unification Language”
 Prolog-like logic language that can reason about Smalltalk code
 SOUL implementation




entirely in Smalltalk
contains about 100 classes
fairly well designed (coding conventions, design patterns)
class hierarchy resembles SOUL abstract syntax tree
 3 architectural views
 ‘rule-based interpreter’
 ‘user interaction’
 ‘application architecture’
May 2001
© Programming Technology Lab
67
SOUL implementation
Clause
Clauses:
Basic
Clause
Terms:
Abstract
Term
Generate
Predicate
Term
Named
Term
Smalltalk
Term
Clauses
True
Term
Rule
Cached
Rule
Terms
Query
Fact
...
...
May 2001
© Programming Technology Lab
68
Architecture:
‘rule-based interpreter’
view(ruleBasedInterpreter).
Working
Knowledge
…
concept(ruleBasedInterpreter,'Rule
Interpreter').
Memory
Base
relation(ruleBasedInterpreter,'Updates_1').
…
port(ruleBasedInterpreter,'Rule
Interpreter',
Uses
Uses
'interpret').
Updates1 Data
Asks2
Data
1
2
role(ruleBasedInterpreter,’Asks_1','interrogator').
…
link(ruleBasedInterpreter,'Rule Interpreter','unify',
'Asks_1','interrogator').
Rule
Clause
Asks
link(ruleBasedInterpreter, 'Clause Selector’,
1
Interpreter
Selector
'matching clauses’,'Asks_1','interrogated’).
…
May 2001
© Programming Technology Lab
69
Conformance mapping
Architecture
Conformance
mapping
Implementation
SOULClause
Clause
Selector
Asks2
Knowledge
Base
SOULBasicClause
SOULClauses
SOULQuery
SOULRule
Uses
Data2
Asks1
Uses
Updates1 Data
1
Rule
Interpreter
Working
Memory
SOULCachedRule
May 2001
SOULFact
SOULAbstractTerm
© Programming Technology Lab
SOULGeneratePredicate
SOULTerm
SOULTrueTerm
SOULNamedTerm
SOULSmalltalkConstantTerm
SOULTerms
SOULAdvancedSmalltalkTerm SOULCachedSmalltalkTerm
SOULAndTerms
SOULOrTerms
70
Conformance mapping
Architecture
Conformance
mapping
Implementation
SOULClause
Clause
Selector
qzfdxgf
Asks2
Knowledge
Base
SOULBasicClause
SOULClauses
SOULQuery
SOULRule
qzfdxgf
qzfdxgf
Uses
Data2
Asks1
Uses
Updates1 Data
1
Rule
Interpreter
Working
Memory
SOULCachedRule
SOULAbstractTerm
SOULGeneratePredicate
SOULTerm
qzfdxgf
SOULNamedTerm
SOULSmalltalkConstantTerm
SOULTrueTerm
qzfdxgf
SOULTerms
qzfdxgf
SOULAdvancedSmalltalkTerm SOULCachedSmalltalkTerm
qzfdxgf
May 2001
SOULFact
qzfdxgf
© Programming Technology Lab
SOULAndTerms
SOULOrTerms
qzfdxgf
71
“Cross-cutting” mappings
Architecture
Conformance
mapping
Implementation
SOULClause
Clause
Selector
qzfdxgf
Asks2
Knowledge
Base
SOULBasicClause
SOULClauses
SOULQuery
SOULRule
qzfdxgf
qzfdxgf
Uses
Data2
Asks1
Uses
Updates1 Data
1
Rule
Interpreter
Working
Memory
SOULCachedRule
SOULAbstractTerm
SOULGeneratePredicate
SOULTerm
qzfdxgf
SOULNamedTerm
SOULSmalltalkConstantTerm
SOULTrueTerm
qzfdxgf
SOULTerms
qzfdxgf
SOULAdvancedSmalltalkTerm SOULCachedSmalltalkTerm
qzfdxgf
May 2001
SOULFact
qzfdxgf
© Programming Technology Lab
SOULAndTerms
SOULOrTerms
qzfdxgf
72
Software classifications
Architecture
Architectural
Instantiation
Architectural
Abstraction
Implementation
SOULClause
Clause
Selector
qzfdxgf
Asks2
Knowledge
Base
SOULBasicClause
SOULClauses
SOULQuery
SOULRule
qzfdxgf
qzfdxgf
Uses
Data2
Asks1
Uses
Updates1 Data
1
Rule
Interpreter
Working
Memory
SOULCachedRule
queryInterpreter
SOULAbstractTerm
SOULGeneratePredicate
SOULTerm
qzfdxgf
SOULNamedTerm
SOULSmalltalkConstantTerm
SOULTrueTerm
qzfdxgf
SOULTerms
qzfdxgf
SOULAdvancedSmalltalkTerm SOULCachedSmalltalkTerm
qzfdxgf
May 2001
SOULFact
qzfdxgf
© Programming Technology Lab
SOULAndTerms
SOULOrTerms
qzfdxgf
73
Virtual classifications (1)
Architecture
Architectural
Instantiation
Architectural
Abstraction
Implementation
SOULClause
Clause
Selector
qzfdxgf
Asks2
Knowledge
Base
SOULBasicClause
SOULClauses
SOULQuery
SOULRule
qzfdxgf
qzfdxgf
Uses
Data2
Asks1
Uses
Updates1 Data
1
Rule
Interpreter
Working
Memory
SOULCachedRule
classifiedAs(method('queryInterpreter’), Method) :classifiedAs(class('soul'), Class),
interpretingProtocolName(ProtocolName),
protocolName(Protocol, ProtocolName),
methodInProtocol(Class, Protocol, Method).
SOULAbstractTerm
SOULGeneratePredicate
SOULTerm
qzfdxgf
SOULNamedTerm
SOULSmalltalkConstantTerm
SOULTrueTerm
qzfdxgf
SOULTerms
qzfdxgf
SOULAdvancedSmalltalkTerm SOULCachedSmalltalkTerm
qzfdxgf
May 2001
SOULFact
qzfdxgf
© Programming Technology Lab
SOULAndTerms
SOULOrTerms
qzfdxgf
74
Virtual classifications (2)
queryInterpreter
Rule
Interpreter
PredicateGenerated
for checking
classified
artefacts
or checked
artefact
or generating a collection of artefacts
classifiedAs(method('queryInterpreter'),Artef):classifiedAs(zclass('soul'), Class),
interpretingProtocolName(ProtocolName),
protocolName(Protocol, ProtocolName),
methodInProtocol(Class, Protocol, Artef).
interpretingProtocolName('interpreting').
interpretingProtocolName('interpretation').
…
May 2001
© Programming Technology Lab
75
Virtual classifications (3)
 “intentional”
 describe how to “compute” their elements
 described as logic predicates over
implementation
 expressive, readable and concise
 can be used in multiple ways
 Generating: which artifacts belong to classification?
 Checking: does artifact belong to this classification?
May 2001
© Programming Technology Lab
76
Virtual dependencies (1)
Architecture
Architectural
Instantiation
Architectural
Abstraction
Implementation
SOULClause
Clause
Selector
Asks2
Knowledge
Base
SOULBasicClause
SOULClauses
SOULQuery
SOULRule
Asks1
Rule
Interpreter
Uses
Updates1 Data
1
Working
Memory
Uses
Data2
SOULCachedRule
SOULFact
SOULAbstractTerm
asks_M_M(M1, M2) :isAskedBy_M_M(M2, M1).
isAskedBy_M_M(M2, M1) :classImplementsMethodNamed(C1, M1N, M1),
className(C1, C1N),
methodName(M2, M2N),
…
SOULGeneratePredicate
SOULTerm
SOULTrueTerm
qzfdxgf
SOULNamedTerm
SOULSmalltalkConstantTerm
qzfdxgf
SOULAdvancedSmalltalkTerm SOULCachedSmalltalkTerm
SOULTerms
qzfdxgf
SOULAndTerms
SOULOrTerms
qzfdxgf
May 2001
© Programming Technology Lab
77
Virtual dependencies (2)
Asks1
asks_M_M(M1, M2) :isAskedBy_M_M(M2, M1).
asks_M_M(M1, M2) :isAskedBy_M_M(M2, M1).
isAskedBy_M_M(M2, M1) :classImplementsMethodNamed(C1, M1Name, M1),
className(C1, C1Name),
methodName(M2, M2Name),
isSentTo(C1Name, M1Name, Rcvr, M2Name, Args),
mayHaveType_E_M_C(Rcvr, M1, RcvrClass),
classImplementsMethod(RcvrClass, M2),
isUsedBy_E_M(send(Rcvr, M2Name, Args), M1).
May 2001
© Programming Technology Lab
78
Virtual dependencies (3)
 declare high-level relationships among implementation
artifacts
 “derived” from primitive implementation dependencies
 e.g., transitive closures, complex interactions, …
 described as logic predicates over implementation
 Expressive, concise, readable, intentional
 can be used in multiple ways
 Checking: does relationship hold between artifacts?
 Generating: find all artifacts that satisfy relationship
 Browsing/searching: find artifacts related to a given one.
May 2001
© Programming Technology Lab
79
Conformance mapping:
summary
Architecture
Conformance mapping
Implementation
SOULClause
Clause
Selector
Asks 2
Asks1
Rule
Interpreter
Uses
Data1
Updates1
Working
Memory
Implementation
Abstraction
SOULBasicClause
qzfdxgf
SOULClauses
SOULQuery
SOULRule
qzfdxgf
Quantifier
Uses
Data2
Knowledge
Base
Architectural
Instantiation
qzfdxgf
SOULCachedRule
Virtual dependency
SOULAbstractTerm
Argument
Filter
Virtual classification
SOULGeneratePredicate
SOULTerm
qzfdxgf
SOULNamedTerm
SOULSmalltalkConstantTerm
qzfdxgf
SOULAdvancedSmalltalkTerm SOULCachedSmalltalkTerm
qzfdxgf
May 2001
SOULFact
qzfdxgf
© Programming Technology Lab
SOULTrueTerm
qzfdxgf
SOULTerms
qzfdxgf
SOULAndTerms
qzfdxgf
80
SOULOrTerms
Conformance checking
Architectural
Instantiation
Architectural
Abstraction
Implementation
SOULClause
SOULBasicClause
Clause
Selector
ruleSelection
Asks2
Knowledge
Base
Architecture
qzfdxgf
SOULClauses
SOULQuery
Uses
Data2
Asks1
Uses
Updates1 Data
1
Rule
Interpreter
Working
Memory


SOULRule
qzfdxgf
qzfdxgf
SOULCachedRule
asks_M_M(M1, M2)
SOULAbstractTerm
SOULGeneratePredicate
SOULTerm
qzfdxgf
SOULTrueTerm
qzfdxgf
queryInterpreter
SOULNamedTerm
SOULSmalltalkConstantTerm
SOULTerms
qzfdxgf
SOULAdvancedSmalltalkTerm SOULCachedSmalltalkTerm
qzfdxgf
May 2001
SOULFact
qzfdxgf
© Programming Technology Lab
SOULAndTerms
SOULOrTerms
qzfdxgf
81
Conformance checking
algorithm
Rule
Interpreter

r 1
Asks
1
Clause
Selector
2
exists
exists
methodFilter
queryInterpreter

methodFilter
asks_M_M
ruleSelection
exists(filteredIsClassifiedAs(queryInterpreter,
methodFilter,X1),
exists(filteredIsClassifiedAs(ruleSelection,
methodFilter,X2),
asks_M_M(X1,X2)))
May 2001
© Programming Technology Lab
82
Conclusion: strengths
 Conformance mapping is
 very expressive
 full expressive power of LMP
 intentional
 virtual classifications and dependencies
 concise and intuitive
 declarative nature of LMP
 well-chosen implementation abstractions:
 virtual classifications, filters and set qualifiers
 virtual dependencies
May 2001
© Programming Technology Lab
83
Conclusion: weaknesses
Conformance mapping
lacks efficiency
is defined manually
requires experience
can be abused
may contain bugs
Partial solution
predefined library of mapping predicates
optimizations, e.g. caching techniques
May 2001
© Programming Technology Lab
84