360 likes | 497 Views
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
E N D
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
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
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
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
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
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
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.
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
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
(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
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?
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”, Knowledge 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.
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.
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
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
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.
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
Translator Modules Test DomainOntology Translator input files(sourceplatform) output files(targetplatform) ParserModule GeneratorModule test specs ingenericrepresentation
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) )
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.
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
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
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> </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> </xsl:text> <xsl:value-of select="." />) <xsl:text>
</xsl:text> </xsl:template> define-instance t1 template1 ( ... (define param2 operation1) ... )
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
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.
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