Declarative Meta Programming Dr Kim Mens Kim Mensvub

Declarative Meta Programming Dr. Kim Mens (Kim. Mens@vub. ac. be) 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 Ø Ty. Ru. Ba Ø QSOUL Ø SOUL for Java Ø Conclusion May 2001 © Programming Technology Lab 4

Overview Ø Declarative Meta Programming Ø Logic Meta Programming Ø Applications of DMP Ø SOUL Ø Ty. Ru. Ba Ø 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 Ø Ty. Ru. Ba Ø 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 Ø Ty. Ru. Ba Ø 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. Ph. D 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, Ph. D 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 8 th International Conference on Compiler Construction. May 2001 © Programming Technology Lab 15

Applications of DMP Ø Code Generation ØTy. Ru. Ba Ø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, Ph. D 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 Ty. Ru. Ba QSOUL 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 implementati on 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 [SOULExplicit. MLI current is. Class: ? class]. May 2001 © Programming Technology Lab 23

SOUL: symbiosis with ST Ø “Smalltalk clause” ØExecute parameterized Smalltalk expressions write(? text) if [Transcript show: (? text as. String). true]. smaller. Than(? 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]) all. Classes([Smalltalk all. Classes]) a. Integer object May 2001 © Programming Technology Lab a. Collection object 26

SOUL: symbiosis with ST Ø “Generate” predicate ØDisassembles a Smalltalk collection into subsequent results of the generate-clause class(? class) if generate(? class, [SOULExplicit. MLI current all. Classes]) a. Class May 2001 a. Collection 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 [ SOULExplicit. MLI current is. Class: ? class ] [false ] “down” “up” Smallta lk[: env | (SOULExplicit. MLI current false is. Class: (env at: 1) soul. Down) soul. Up ] 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 is. Classified. As find. Methods. From. Classes find. Meta. Classed. From. Classes factory. Method composite. Pattern instance. Creation. Method is. Sent. To hierarchy traverse. Method. Parse. Tree class. Implements. Method. Named class. Name inheritance class. Implements. Method method. Name protocol. Name meta. Class method. In. Protocol artefact. Nesting. ID © Programming Technology Lab 30

SOUL: example Composite Design Pattern: look for all the possible composite classes, where the component is Visual. Part: if composite. Pattern([Visual. Part], ? comp, ? sel) May 2001 © Programming Technology Lab 31

SOUL: example composite. Pattern(? comp, ? composite, ? msg) if composite. Structure(? comp, ? composite), composite. Aggregation(? comp, ? composite, ? msg). composite. Structure(? comp, ? composite) if class(? comp), hierarchy(? comp, ? composite). composite. Aggregation(? comp, ? composite, ? msg) if common. Methods(? comp, ? composite, ? M, ? composite. M), method. Selector(? composite. M, ? msg), one. To. Many. Statement(? composite. M, ? inst. Var, ? enum. Statement), contains. Send(? enum. Statement, ? msg). May 2001 © Programming Technology Lab 32

SOUL: the repository inspector Construct and execute queries Inspect logic facts and rules May 2001 Browse and edit (hierarchic) repository structure © 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 Ty. Ru. Ba QSOUL for Java Conclusion May 2001 © Programming Technology Lab 35

Ty. Ru. Ba Ø 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

Ty. Ru. Ba: set-up Ty. Ru. Ba 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

Ty. Ru. Ba: 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 pre Represents Re Set of logic propositions sen ts Base Language Program May 2001 © Programming Technology Lab 38

Ty. Ru. Ba: the language Ø Ty. Ru. Ba language ØProlog ØConstants, variables, functors, lists ØPredicates, facts, rules, queries ØCode generation constructs ØQuasi. Quoted. Code term ØCore code generator May 2001 © Programming Technology Lab 39

Ty. Ru. Ba: 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

Ty. Ru. Ba: example class(Array<? El>, { private ? El[] contents; Generic Java array /** Construction */ Array<? El>(int sz) { contents = new ? El[sz]; } /** Basic Array functionality */ ? El element. At(int i) { return contents[i]; } void set. Element. At(? 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 element. At ( int i ) { return contents [ i ] ; } void set. Element. At ( String e , int i ) { contents [ i ] = e ; } int length ( ) { return contents. length ; } } May 2001 © Programming Technology Lab 41

Ty. Ru. Ba 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

Ty. Ru. Ba example: visitor design pattern abstract class Tree { boolean is. Node() { return false; } boolean is. Leaf() { return false; } abstract Object accept(Visitor v); } class Node extends Tree { boolean is. Node() {return true; }. . . Object accept(Visitor v) { return v. visit. Node(this); } } class Leaf extends Abstract. Tree { boolean is. Leaf() {return false; }. . . Object accept(Visitor v) { return v. visit. Leaf(this); } } abstract class Tree. Visitor { abstract Object visit. Node(Node node); abstract Object visit. Leaf(Leaf leaf); } May 2001 Tree is. Node is. Leaf accept Node is. Node. . . accept Leaf is. Leaf. . . accept Tree. Visitor visit. Node visit. Leaf Print. Visitor visit. Node visit. Leaf © Programming Technology Lab 43

Ty. Ru. Ba example: visitor design pattern Tree 1) Knowledge about this particular visitor is. Node is. Leaf root. Visited. Node(Tree. Visitor, Tree). accept visited. Node(Tree. Visitor, Node). visited. Node(Tree. Visitor, Leaf). 2) Visitor Code Generation abstractmethod(? Root. Node, accept, . . . ) : - root. Visited. Node(? Visitor, ? Root. Node). Node is. Node. . . accept Leaf is. Leaf. . . accept method(? Visited, accept, . . . , {. . . }) : - visited. Node(? Visitor, ? Visited). Tree. Visitor visit. Node visit. Leaf abstractmethod(? Visitor, visit<? Visited>, . . . ) : - visited. Node(? 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 mutually. Exclusive(push, pop) mutually. Exclusive(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 Ty. Ru. Ba-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 Ty. Ru. Ba QSOUL for Java Conclusion May 2001 © Programming Technology Lab 48

QSOUL: combine Ty. Ru. Ba & 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 & Ty. Ru. Ba 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 Ty. Ru. Ba QSOUL 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: C 2 C Ø 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 Java. Class) Ø Tested on Drawlets May 2001 © Programming Technology Lab 55

SOUL for Java: representation in C 2 C Ø class(<class. Name>). Ø interface(<class. Name>). Ø access. Flag(<class. Name>, <access. Flag>). Ø superclass(<class. Name>, <super. Class. Name>). Ø direct. Interface(<class. Name>, <interface>). Ø field. Access. Flag(<class. Name>, <field. Name>, <flag>). Ø field. Descriptor(<class. Name>, <field. Name>, <return. Type>). May 2001 © Programming Technology Lab 56

SOUL for Java: representation in C 2 C Ø method. Access. Flag(<class. Name>, <method. Nam e>, <arg. List>, <access. Flag>). Ø method. Return. Type(…, <return. Type>). Ø method. Body(…, <invokes. Used. Modifieds. List>) Ø invokespecial(<invocation>) Ø putfield(<field. Name>) Ø putstatic(<field. Name>) Ø getfield(<field. Name>) Ø getstatic(<field. Name>) May 2001 © Programming Technology Lab 57

C 2 C: example (input file) public final class Line. Number implements Cloneable { private int start_pc; Line. Number(Data. Input. Stream file) throws IOException { this(file. read. Unsigned. Short(), file. read. Unsigned. Short()); } public final void dump(Data. Output. Stream file) throws IOException { file. write. Short(start_pc); file. write. Short(line_number); } May 2001 © Programming Technology Lab 58 …}

C 2 C example (output file) class(‘Line. Number’). class. Access. Flag(‘Line. Number’, public). class. Access. Flag(‘Line. Number’, final). direct. Interface(‘Line. Number’, ‘java. lang. Cloneable’). super. Class(‘Line. Number’, ‘java. lang. Object’). field. Access. Flags(‘Line. Number’, ‘start_pc’, private). field. Descriptor(‘Line. Number’, ‘start_pc’, int). method. Return. Type(‘Line. Number’, [‘java. io. Data. Input. Stream’], void). method. Exception(‘Line. Number’, [‘java. io. Data. Input. Stream’], ‘java. io. IOException’). May 2001 © Programming Technology Lab 59

Overview Ø Ø Ø Ø Declarative Meta Programming Logic meta programming Applications of DMP SOUL Ty. Ru. Ba QSOUL 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, Ty. Ru. Ba, C 2 C, 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 Ø “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 Clauses: Clause Basic Clause Terms: Abstract Term Generate Predicate Term Named Term Smalltalk Term Clauses True Term Rule Fact Cached Rule Terms Query . . . May 2001 © Programming Technology Lab 68

Architecture: ‘rule-based interpreter’ view(rule. Based. Interpreter). Working Knowledge … concept(rule. Based. Interpreter, 'Rule Interpreter'). Memory Base relation(rule. Based. Interpreter, 'Updates_1'). … port(rule. Based. Interpreter, 'Rule Interpreter', Uses 'interpret'). Updates 1 Data Asks 2 Data 1 2 role(rule. Based. Interpreter, ’Asks_1', 'interrogator'). … link(rule. Based. Interpreter, 'Rule Interpreter', 'unify', 'Asks_1', 'interrogator'). Rule Clause Asks link(rule. Based. Interpreter, 'Clause Selector’, 1 Interpreter Selector 'matching clauses’, 'Asks_1', 'interrogated’). … May 2001 © Programming Technology Lab 69

Conformance mapping May 2001 Conformance mapping Implementation Clause Selector Asks 1 Rule Interpreter Asks 2 Uses Data 2 Uses Updates 1 Data 1 Working Memory Knowledge Base Architecture © Programming Technology Lab 70

Conformance mapping Implementation Asks 1 Rule Interpreter Clause Selector Uses Data 2 Asks 2 qzfdxgf Uses Updates 1 Data 1 Working Memory Knowledge Base Architecture qzfdxgf qzfdxgf May 2001 qzfdxgf © Programming Technology Lab qzfdxgf 71

“Cross-cutting” mappings Conformance mapping Implementation Asks 1 Rule Interpreter Clause Selector Uses Data 2 Asks 2 qzfdxgf Uses Updates 1 Data 1 Working Memory Knowledge Base Architecture qzfdxgf qzfdxgf May 2001 qzfdxgf © Programming Technology Lab qzfdxgf 72

Software classifications Architectural Instantiation Architectural Abstraction Implementation Asks 1 Rule Interpreter Clause Selector Uses Data 2 Asks 2 qzfdxgf Uses Updates 1 Data 1 Working Memory Knowledge Base Architecture qzfdxgf query. Interpreter qzfdxgf May 2001 qzfdxgf © Programming Technology Lab qzfdxgf 73

Virtual classifications (1) Architectural Instantiation Architectural Abstraction Implementation Asks 1 Rule Interpreter Clause Selector Uses Data 2 Asks 2 qzfdxgf Uses Updates 1 Data 1 Working Memory Knowledge Base Architecture qzfdxgf classified. As(method('query. Interpreter’), Method) : classified. As(class('soul'), Class), interpreting. Protocol. Name(Protocol. Name), protocol. Name(Protocol, Protocol. Name), method. In. Protocol(Class, Protocol, Method). qzfdxgf May 2001 qzfdxgf © Programming Technology Lab qzfdxgf 74

Virtual classifications (2) query. Interpreter Rule Interpreter Predicate. Generated for checking classified artefacts or checked artefact or generating a collection of artefacts classified. As(method('query. Interpreter'), Artef): classified. As(zclass('soul'), Class), interpreting. Protocol. Name(Protocol. Name), protocol. Name(Protocol, Protocol. Name), method. In. Protocol(Class, Protocol, Artef). interpreting. Protocol. Name('interpreting'). interpreting. Protocol. Name('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) Clause Selector Asks 1 Rule Interpreter Asks 2 Uses Data 2 Uses Updates 1 Data 1 Working Memory Knowledge Base Architectural Instantiation Architectural Abstraction Implementation asks_M_M(M 1, M 2) : is. Asked. By_M_M(M 2, M 1) : class. Implements. Method. Named(C 1, M 1 N, M 1), class. Name(C 1, C 1 N), method. Name(M 2, M 2 N), … qzfdxgf May 2001 © Programming Technology Lab 77

Virtual dependencies (2) Asks 1 asks_M_M(M 1, M 2) : is. Asked. By_M_M(M 2, M 1) : class. Implements. Method. Named(C 1, M 1 Name, M 1), class. Name(C 1, C 1 Name), method. Name(M 2, M 2 Name), is. Sent. To(C 1 Name, M 1 Name, Rcvr, M 2 Name, Args), may. Have. Type_E_M_C(Rcvr, M 1, Rcvr. Class), class. Implements. Method(Rcvr. Class, M 2), is. Used. By_E_M(send(Rcvr, M 2 Name, Args), M 1). 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 Clause Selector Asks 2 Asks 1 Rule Interpreter Uses Data 1 Updates 1 Working Memory Implementation Abstraction qzfdxgf Quantifier Uses Data 2 Knowledge Base Architectural Instantiation Implementation qzfdxgf Virtual dependency Argument Filter Virtual classification qzfdxgf qzfdxgf May 2001 © Programming Technology Lab qzfdxgf 80

Conformance checking Architectural Instantiation Architectural Abstraction Clause Selector rule. Selection Asks 2 Knowledge Base Architecture Implementation qzfdxgf Uses Data 2 Asks 1 Uses Updates 1 Data 1 Rule Interpreter Working Memory qzfdxgf asks_M_M(M 1, M 2) qzfdxgf query. Interpreter qzfdxgf May 2001 qzfdxgf © Programming Technology Lab qzfdxgf 81

Conformance checking algorithm Rule Interpreter r 1 Asks 1 Clause Selector 2 exists method. Filter query. Interpreter method. Filter asks_M_M rule. Selection exists(filtered. Is. Classified. As(query. Interpreter, method. Filter, X 1), exists(filtered. Is. Classified. As(rule. Selection, method. Filter, X 2), asks_M_M(X 1, X 2))) 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