1 / 36

A Tester Specification Code Translator Using Ontology and XML/XSLT Technologies

A Tester Specification Code Translator Using Ontology and XML/XSLT Technologies. The 1 st Malaysian Software Engineering Conference 13 Dec 2005 Lim Lian Tze, Tang Enya Kong and Zaharin Yusoff Computer Aided Translation Unit School of Computer Sciences

darrin
Download Presentation

A Tester Specification Code Translator Using Ontology and XML/XSLT Technologies

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 Tester Specification Code Translator Using Ontology and XML/XSLT Technologies The 1st Malaysian Software Engineering Conference 13 Dec 2005 Lim Lian Tze, Tang Enya Kong and Zaharin Yusoff Computer Aided Translation UnitSchool of Computer Sciences Universiti Sains MalaysiaPenang, Malaysia

  2. Outline of Presentation • Problem Background • Program Translators & Code Generation • Design of Translation Engine • Overall Strategy • Test Domain Ontology • Generic Representation • Parser Module • Generator Module • Conclusion With Simple (Dummy) Examples in 2 Languages

  3. Problem Background

  4. Project Background • Test equipment from different vendors  different tester language syntax • Structures and constructs • Names of special entities (test keywords) • Developing same tests for equipment from different vendors by hand is time-consuming, tiresome and error-prone

  5. Different Syntax Language A: C-like Language B: Lisp-like reserved keywords Different Test Keywords Test schema types Parameter names Enumeration values (>2 languages in actuality) Dummy Code Example test_template_instance t1 schema1 { binding1 = 0, binding2 = "operation1", binding3 = "-0.05, 0, 0.05" } test_template_instance t1 schema1 { binding1 = 0, binding2 = "operation1", binding3 = "-0.05, 0, 0.05" } test_template_instance t1 schema1 { binding1 = 0, binding2 = "operation1", binding3 = "-0.05, 0, 0.05" } test_template_instance t1 schema1 { binding1 = 0, binding2 = "operation1", binding3 = "-0.05, 0, 0.05" } test_template_instance t1 schema1 { binding1 = 0, binding2 = "operation1", binding3 = "-0.05, 0, 0.05" } Language A define-instance t1 template1 ( (define param1 0 :choice "No") (define param2 operation1) (define param3 -0.05 0 0.05) ) define-instance t1 template1 ( (define param1 0 :choice "No") (define param2 operation1) (define param3 -0.05 0 0.05) ) define-instance t1 template1 ( (define param1 0 :choice "No") (define param2 operation1) (define param3 -0.05 0 0.05) ) define-instance t1 template1 ( (define param1 0 :choice "No") (define param2 operation1) (define param3 -0.05 0 0.05) ) define-instance t1 template1 ( (define param1 0 :choice "No") (define param2 operation1) (define param3 -0.05 0 0.05) ) Language B

  6. Two Requirements • “Syntactic” • Grammars • For parsing: use CFG • For generation: use XSLT template • “Semantic” • Test Keywords (names of test schemas, bindings, enumeration values) • Use ontology

  7. Objectives To develop a translation engine prototype that can • Generate tester-specifications for different vendors, based on a generic language syntax • Reverse engineer vendor-specific tester syntax to generic language syntax

  8. Program Translators and Code Generation

  9. Program Generators • Automates creation of repetitive code • Commonly encountered and widely used • Web page creation (ASP, PHP, JSP…) • SQL scripts • Documentation, code snippets (or whole classes) by CASE tools • Example program generator: Jostraca(http://www.jostraca.org) • Requires systematic process of understanding application domains, and building software tools in that domain (Cleaveland 2001) • Cleaveland, J. C.Program Generators with XML and Java. Prentice-Hall PTR, New Jersey, 2001.

  10. Code Generation Model • HOW to generate • Output text boilerplates or templates • WHAT to generate • A declarative model • Needs to be “discovered” from a existing platform-specific test program

  11. Design of Translation Engine

  12. Language for vendor 1 lang. A Language for vendor 2 lang. B Language for vendor n Synthesis (generation) Analysis (parsing) Overview Test DomainOntology Test Specs inGeneric Representation Generation Modules Parser Modules n platforms  2n modules

  13. (This won’t work very well) Test specs in lang. A Test specs in lang. B Test specs in lang. C Test specs in lang. D n platforms  n(n-1) modules

  14. Generic Representation Scheme • The “pivot” in our architecture • Needs platform-specific knowledge, configuration files and settings for analysing/generating How to store/represent this knowledge?

  15. Test Domain Ontology

  16. Ontology • “Explicit formal specifications of the terms in the domain and relations among them” (Gruber 1993) • To share common understanding of the structure of information • To enable reuse of domain knowledge • To separate domain knowledge from operational knowledge • Taxonomy – categorisation of concepts • OOP: focus on methods • Ontology: focus on data structure(Noy & McGuiness 2001) • Semantic information: properties, restrictions • Gruber, T. “A Translation Approach to Portable Ontology Specification”, Knowl­edge Acquisition, 5(2), 1993, pp. 199-220. • Noy, N. F. and McGuiness, D. L. “Ontology Development 101: A Guide to Creating Your First Ontology”, Technical Report SMI-2001-0880, Stanford Medical Informatics, Stanford University, Stanford, 2001.

  17. Test Domain Ontology • To aid our understanding of the domain (in the early days) • To provide a model for the generic language • To specify platform-specific constraints, configurations etc • Protégé — tool for: • ontology editor • knowledge acquisition • Protégé. “The Protégé Ontology Editor and Knowledge Acquisition System”, http://protege.stanford.edu/, 2005.

  18. Key Concepts • Platform • Code templates required for generation • Test specs file extensions • Other platform-specific formatting • Test_Template • Instances = test_template_instance or define-instance blocks • has key-value Bindings for each test-instance • Enum • Enumeration values for some types of bindings

  19. Key Concepts (cont’d) • Test_Template, Binding, Enum have translations • “translations” of keywords on different platforms • No translation  schema or parameter unavailable on target platform

  20. Role of the Ontology • Test_Template, Binding • Instances correspond to code blocks in test spec files • Represented generically by an XML file • Platform, Enum, hasTranslation • “Configuration settings” • Stored as OWL ontology file • Can be accessed/queried via API (e.g. Jena/RDQL for Java) • JENA – A Semantic Web Framework for Java, HP Labs. http://jena.sourceforge.net/, 2005.

  21. Generic Representation Schema

  22. XML as Generic Representation Schema • Based on key concepts in Test Domain Ontology • Benefits of using XML: • Portable • Large range of widely available manipulation tools • Can be converted to various formats and outputs test_template_instance t1schema1 { binding1 = 0, binding2 = "operation1", binding3 = "-0.05, 0, 0.05" } <test> <name>t1</name> <schema>sc1</schema> <binding name = "Bind1" enum="true" >BIND1_NO</binding> <binding name = "Bind2"> operation1</binding> <binding name = "Bind3"> <value>-0.05</value> <value>0</value> <value>0.05</value> </binding> </test> Language A define-instance t1template1 ( (define param10 :choice "No") (define param2operation1) (define param3-0.05 0 0.05) ) Language B Generic

  23. The Translator

  24. Translator Modules Test DomainOntology Translator input files(sourceplatform) output files(targetplatform) ParserModule GeneratorModule test specs ingenericrepresentation

  25. Example: Translating from Language A to Language B test_template_instance t1schema1 { binding1 = 0, binding2 = "operation1", binding3 = "-0.05, 0, 0.05" } define-instance t1template1 ( (define param10 :choice "No") (define param2operation1) (define param3-0.05 0 0.05) )

  26. The Parser

  27. Parser Generation from Context Free Grammar (CFG) • Parse and analyse platform-specific test specifications • well-formed • context free •  CFG (with parser actions) • JavaCC: a parser generator • generates Java classes from high-level grammar specifications • JavaCC. “Java Compiler Compiler (JavaCC) - The Java Parser Generator”,https://javacc.dev.java.net/, 2005.

  28. Example JavaCC Source File A.jj (CFG specification for Language A) void Start( Element testspecs ): { TestInstance test; } { ( test = TestBlock() { ... process test object ... } )* <EOF> } TestInstance TestBlock(): { TestInstance test = new TestInstance(); String s; } { <KW_TESTINST> s = Head() { test.setName( s ); } TBody( test ) Tail() { return test; } } String Head(): { Token t; } { t = <ID> <OBRACE> { return t.image; } } void Tail(): {}{ <CBRACE> <SEMICLN> } void TBody(): ... JavaCC Java Source filesfor Lang. A Parser

  29. Example Parsing Process Test Specs Ontology Platform-independenttest.xml Input file (language A)test.A <test> <name>t1</name> <schema>sc1</schema> <binding name = "Bind1" enum="true">BIND1_NO </binding> <binding name = "Bind2"> operation1</binding> <binding name = "Bind3"> <value>-0.05</value> <value>0</value> <value>0.05</value> </binding> </test> Parser Module test_template_instance t1 schema1 { binding1 = 0, binding2 = "operation1", binding3 = "-0.05, 0, 0.05" } inputplatformspecifictest specs GenericTest Specs(XML) Syntax-directed parsing Filtering* & keyword translation XML writer name: t1 schema: schema1 bindings: name Value(s) binding1 0 binding2 operation1 binding3 -0.05;0;0.05 name: t1 schema: sc1 bindings: name isEnum multiple Value(s) values Bind1 Y N 0 Bind2 N N operation1 Bind3 N Y -0.05;0;0.05 Platform-specifictest instances & segments Filtering + keyword translation(specific  generic) Platform-A specific object Platform-independent object • *Filtering: • Discard test instances with non-generic schemas • Discard non-generic parameters

  30. The Generator

  31. Code Generation from XML with XSLT • XML  plain text output • XSL stylesheets as “boilerplates” – natural choice • Example XSL Stylesheet snippet (much simplified!): <test> <name>t1</name> <schema>template1</schema> ... <binding name = "param2"> operation1 </binding> ... </test> B.xsl (XSL Stylesheet for Language B) <xsl:template match = "test"> (define-instance <xsl:value-of select = "name" /> <xsl:text>&#x20;</xsl:text> <xsl:value-of select = "schema" /> <xsl:apply-templates select="binding" /> ) </xsl:template> <xsl:template match="binding"> <xsl:text> </xsl:text> (value <xsl:value-of select="@name" /> <xsl:text>&#x20;</xsl:text> <xsl:value-of select="." />) <xsl:text>&#xa;</xsl:text> </xsl:template> define-instance t1 template1 ( ... (define param2 operation1) ... )

  32. intermediateDOM tree (withplatform-specificlabels) input DOMtree Example Generation Process Test Specs Ontology outputboilerplates Platform-independenttest.xml <test> <name>t1</name> <schema>sc1</schema> <binding name = "Bind1" enum="true">BIND1_NO </binding> <binding name = "Bind2"> operation1</binding> <binding name = "Bind3"> <value>-0.05</value> <value>0</value> <value>0.05</value> </binding> </test> define-instance t1 template1 ( (define param1 0 :choice "No") (define param2 operation1) (define param3 -0.05 0 0.05) ) outputplatform-specifictest specs Generation Module Input generic XMLfile XMLparser translatekeywords XSLTtransformation Output file (language B)test.B <test> <name>t1</name> <schema>template1</schema> <binding name = "param1" enum="true" str="No"> 0</binding> <binding name = "param2"> operation1</binding> <binding name = "param3" multiple = "true"> <value>-0.05</value> <value>0</value> <value>0.05</value> </binding> </test> <test> <name>t1</name> <schema>sc1</schema> <binding name = "Bind1" enum="true">BIND1_NO</binding> <binding name = "Bind2"> operation1</binding> <binding name = "Bind3" multiple="true"> <value>-0.05</value> <value>0</value> <value>0.05</value> </binding> </test> Platform-independent DOM tree DOM tree with platform B-specific keywords

  33. Conclusion

  34. Conclusion • A reusable framework for code translation between platform-specific formats/languages • Parse-Generate c.f. interlingual machine translation • a.k.a. abstract-reimplement (Waters 1988) • O(n) modules instead of O(n2) • Ontology as knowledge repository • Jena API, RDQL for querying ontology • ParserGenerators • Context-free grammar (CFG) specifications • JavaCC generates parser classes • XML and XSL Transformations • XSLT templates as output templates • JDOM, SAXON to aid XML parsing and XSLT execution. • Waters, R. C. “Program Translation via Abstraction and Reimplementation”, IEEE Transactions on Software Engineering, 14(8), 1988, pp. 1207-1228.

  35. Thank you for listening!

  36. Ideas for refinement • Ontology: • Define more schema types • Model other types of code blocks in ontology • Translation engine: • Handle platform-specific extensions • Extend to 3rd (or more) language • Understanding of Domain is Crucial

More Related