A Declarative MetaProgramming Approach to Framework Documentation

1
A Declarative Meta-Programming Approach to
Framework Documentation

• Tom Tourwé Tom Mens
• tom.tourwe,tom.mens_at_vub.ac.be
• Programming Technology Lab
• Vrije Universiteit Brussel

2
Motivation

• Framework Documentation
• Often non-existent
• Outdated, due to constant evolution
• Not integrated in the development process

Problems for evolution instantiation of the
framework!
3
Proposed Solution

• Use declarative meta programming (DMP)
• To document a frameworks design accurately and
  concisely
• By means of design patterns used in the framework
• Use the available information actively
• Check completeness/correctness of the
  documentation w.r.t. the source code

Concrete DMP Environment used SOUL
4
Why DMP?

• Declarative
• Represent knowledge in a straightforward and
  concise way
• Powerful reasoning capabilities
• Infer extra information from available
  information
• Tight Integration
• Of SOUL with the development environment
• Allows to consult the source code

5
Documenting the Design
6
Documenting the Design
dpRole(instance,role,source code artifact)
dpRole(astVisitor,abstractElement,ScExpression). d
pRole(astVisitor,concreteElement,ScConsExpression)
. dpRole(astVisitor,concreteElement,ScBlockExpress
ion). ... dpRole(astVisitor,acceptMethod,nodeDo).
dpRole(astVisitor,abstractVisitor,AbstractASTEnum
erator). dpRole(astVisitor,concreteVisitor,SchemeT
oSmalltalkConverter). dpRole(astVisitor,visitMetho
d,doConsExpression). dpRole(astVisitor,visitMetho
d,doBlockExpression). ... dpRelation(astVisitor,lt
ScConsExpression,doConsExpressiongt). dpRelation(a
stVisitor,ltScBlockExpression,doBlockExpressiongt).
7
Documenting the Design

• Rather verbose
• Use full power of DMP instead

dpRole(astVisitor,abstractElement,ScExpression).
dpRole(?instance,concreteElement,?concreteElement
) if dpInstance(?instance,visitorDP), dpRole(?in
stance,abstractElement,?root), hierarchy(abstract
Element,?concreteElement), concreteClass(?concret
eElement).
8
Checking Completeness

• Describe required roles
• By means of logic facts
• Check documentation for their presence
• By means of logic rules
• Report missing roles

requiredRole(visitorDP,abstractElement). requiredR
ole(visitorDP,abstractVisitor). requiredRole(visit
orDP,acceptMethod).
checkPatternInstance(?pattern, ?instance, ?role)
if requiredRole(?pattern,?role), not(dpRole(?ins
tance,?role))
9
Checking Consistency

• Identify appropriate design constraints
• Implement them by means of logic rules
• Report conflicts suggest possible actions

patternConstraint(visitorDP,?instance, noAccept
Method(?concreteElement,?acceptSelector))
if dpRole(?instance,acceptMethod,?acceptSelector)
, dpRole(?instance,concreteElement,?concreteEleme
nt), not(classImplements(?concreteElement,?accept
Selector))