1 / 9

A Declarative Meta-Programming Approach to Framework Documentation

A Declarative Meta-Programming Approach to Framework Documentation. Tom Tourw é & Tom Mens {tom.tourwe,tom.mens}@vub.ac.be Programming Technology Lab Vrije Universiteit Brussel. Motivation. Framework Documentation Often non-existent Outdated, due to constant evolution

zelig
Download Presentation

A Declarative Meta-Programming Approach to Framework Documentation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Declarative Meta-Programming Approach to Framework Documentation Tom Tourwé & Tom Mens {tom.tourwe,tom.mens}@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! Tom Tourwé

  3. Proposed Solution • Use declarative meta programming (DMP) • To document a framework’s 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 Tom Tourwé

  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 Tom Tourwé

  5. Documenting the Design Tom Tourwé

  6. Documenting the Design dpRole([instance],[role],[source code artifact]) dpRole(astVisitor,abstractElement,ScExpression). dpRole(astVisitor,concreteElement,ScConsExpression). dpRole(astVisitor,concreteElement,ScBlockExpression). ... dpRole(astVisitor,acceptMethod,nodeDo:). dpRole(astVisitor,abstractVisitor,AbstractASTEnumerator). dpRole(astVisitor,concreteVisitor,SchemeToSmalltalkConverter). dpRole(astVisitor,visitMethod,doConsExpression:). dpRole(astVisitor,visitMethod,doBlockExpression:). ... dpRelation(astVisitor,<ScConsExpression,doConsExpression:>). dpRelation(astVisitor,<ScBlockExpression,doBlockExpression:>). Tom Tourwé

  7. Consult documentation Consult implementation Documenting the Design • Rather verbose • Use full power of DMP instead dpRole(astVisitor,abstractElement,ScExpression). … dpRole(?instance,concreteElement,?concreteElement) if dpInstance(?instance,visitorDP), dpRole(?instance,abstractElement,?root), hierarchy(abstractElement,?concreteElement), concreteClass(?concreteElement). Tom Tourwé

  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). requiredRole(visitorDP,abstractVisitor). requiredRole(visitorDP,acceptMethod). checkPatternInstance(?pattern, ?instance, ?role) if requiredRole(?pattern,?role), not(dpRole(?instance,?role)) Tom Tourwé

  9. Consult documentation Check implementation Checking Consistency • Identify appropriate design constraints • Implement them by means of logic rules • Report conflicts & suggest possible actions patternConstraint(visitorDP,?instance, noAcceptMethod(?concreteElement,?acceptSelector)) if dpRole(?instance,acceptMethod,?acceptSelector), dpRole(?instance,concreteElement,?concreteElement), not(classImplements(?concreteElement,?acceptSelector)) Tom Tourwé

More Related