Automatic Configurator for Application Code

Size: px

Start display at page:

Download "Automatic Configurator for Application Code"

Clyde Reynolds
6 years ago
Views:

1 Automatic Configurator for Application Code ROXANA MUREŞAN 1, ANDREI BOTOACĂ 2, HORIA CIOCÂRLIE 1 1 Computer and Software Engineering Department Politehnica University of Timisoara V. Pârvan street 2, , Timisoara ROMANIA 2 Continental Automotive Timişoara, ROMANIA roxi.muresan@yahoo.com, horia@cs.upt.ro Abstract: - This paper proposes a plug-in for ConfigTool. ConfigTool is a XML editor that generates.c and.h files using XML, XML Schema and XSL files. The tool is used by software developers to configure the generic code. The software developers need to write the XML, XML Schema and XSL files that configure the generic code. For this they need to have at least medium knowledge of XML, XML Schema and XSL technologies. The Automatic Configurator can generate these files using much less input information than the XML, XML Schema and XSL files themselves. The application uses its own script which allows the developer to define the configurable data and the way it wants to use the data. The script used by the tool is much easier and faster to learn and use than the XML [1], XML Schema [2] and XSL [3] technologies. The tool was used by software developers and it is proved that it increases the quality of the configured code by eliminating consistency errors and it minimizes the time used for code configuration. Key-words:- configuration, Schema, XML, XSL, generate, generic. 1 Introduction The application is addressed to software developers and it simplifies their work to configure the source code starting from the generic code. Generic programming is a technique that allows the types to be specified later. These types are initialized when there is need for specific types to be sent as parameters. This approach allowes developers to write common functions or types which differ only by the set of types that they operate on when they are used. This way code duplication is avoided. The generic concept is tightly related to the reusability concept. In programming, reusability is the probability a segment of source code to be reused in order to add new functionalities with no changes or with minor changes to the code. The reusable classes and modules reduce the implementation time. It is considered that this code is already tested and, therefore, free of errors and in case there are changes in the implementation, these changes are localized. To configure the generic code, a developer needs to write an XML file and its Schema file which contain the configurable data and an XSL file for each file that he needs to configure. As long as the configurable data is not changed, the XML Schema file and the XSL files stay unchanged. If a reconfiguration is needed, the developer only needs to change the elements of the XML file. The main disadvantages are that the developer needs to write these files, and for this he needs to have at least medium knowledge of XML [1], XML Schema [2] and XSL [3] technologies, and the developer can easily introduce inconsistent data in these files, these kinds of errors being hard to detect. Here is where the Automatic Configurator comes in help (Figure 1). It solves both of those drawbacks. It comes with a lighter script than the XML and it checks the consistency of the data. ISBN:

2 CFG:print - is used to print the data in the configured files. CFG:format - defines the way to display the data. Fig.1. The configuring process Together, the Automatic Configurator and the ConfigTool can almost be considered a code generator. There are other code generator tools that also use XML, such as Autogen and Tankogen, which is a tool for Model-driven development tailored for model transformation and source code generation. Code generators are widely used for building GUIs, for example Interface Builder and program "wizards", which allow the programmer to design graphical user interfaces interactively while the compiler invisibly generates the corresponding source code. The rest of this paper is organized as follows: Section II describes the script used by the Automatic Configurator to generate the XML, XML Schema and XSL files. Section III explains how the Automatic Configurator works. In Section IV we give an example of how to use the script: we show the input and the generated output. In Section V we present the results of this project. Section VI states the conclusions of this paper. 2 Automatic Configurator Script The Automatic Configurator uses a markup formal language. Whit this script the developer can define the configurable data of the generic code, which can be simple types or structures of data, and the way the data is written in the generated files (configured.c and.h files). The tags of the script are comments in the C language because they are contained between /* and */. The script has four main tags, two for defining data and two tags for writing data: CFG:typedef - is used to define local data structures and instances. CFG:inst - is used to define global data and instances. The data structures can be defined in more than one piece (this will be explained later in this section) 2.1 Data tags The data tags (CFG:typedef and CFG:inst) are a treelike structured tags. They can contain other tags like CFG:sequence, CFG:choice, CFG:element and CFG:attribute. Those tags have similar meaning with the according XML Schema tags. The CFG:typedef and CFG:inst tags have similar meaning with the xs:complextype tag from XML Schema. The syntax for the CFG:typedef tag is: /*CFG:typedef*/ /*/CFG:typedef*/ It is mandatory for a CFG:typedef to have a name attribute. The occurs attribute is optional and its default value is 1. The syntax for the CFG:inst tag is: /*CFG:inst:_name_:_parent_elemtn_*/ /*/CFG:inst*/, where _name_ is the name of the data structure created by CFG:inst and _parent_element_ indicates where the data is added in the _name_ inst structure. There can be more than one CFG:inst tags with the same name. The application will gather all of them and create the final data structure. If the parent element is not specified the node will be added as a child of the inst root node, else it will be added as a child of the specified parent node. The CFG:inst tag allows the developer to create global data structures which pieces can be defined in different files. Forth we will show the syntax of other data tags: /*CFG:element*/ /*/CFG:element*/ The CFG:element tag can contain CFG:sequence, CFG:choice, CFG:element and CFG:attribute tags and can have name, type and occurs attributes. If the type attribute is specified, it has to be the name of a type declared by a CFG:typedef and it cannot have any child nodes. The CFG:element tag has similar meaning with the xs:element tag form XML Schema. /*CFG:sequence*/ /*/CFG: sequence */ /*CFG:choice*/ ISBN:

3 /*/CFG: choice */ These two tags can contain CFG:sequence, CFG:choice, and CFG:element tags. They can t have attributes and are similar with the xs:sequence and xs:choice tags from XML Schema. /*/CFG: attribute */ The CFG:attribute tag can only contain attributes. These attributes are name (mandatory), type (mandatory), fixed or default or value, restriction, link. The syntax of the name attribute is: /*name= a_name /*/ or /*name*/a_name/*/name*/ The type attribute has the following syntax: /*type = a_type */ or /*type*/a_type/*/type*/ The type can be one of the following: short, int, long, unsignedshort, unsignedint, unsignedlong, float, double, boolean, string, or a type defined by a restriction attribute. The fixed and default attributes define a fixed or a default value respectively. Their syntax is: /*fixed = a_value /*/ /*default = a_value /*/ If an CFG:attribute has a fixed value it can t have a default, value, link or restriction attribute. The value attribute has the following syntax: /*value = generic:function_name(parameters) /*/ This attribute is used when we wish an CFG:attribute to take the return value of a function call. The application implicitly defines a java class automatic_configurator.javafunctions in generic.jar where the developer can add different functions. The link attribute can be used when we want an CFG:attribute to take values from the set of values of another CFG:attribute. This attribute shapes the behavior of the xs:key and xs:keyref XML Schema attributes. The syntax is: /* link = "xpath"/*/, where the xpath value indicates the keyref xpath. The restriction attribute allows the developer to define a new type starting from the base types by adding restriction (Table 1). Table 1 Restriction and their meaning maxlength length maximum number of characters the number of characters The totaldigits restriction can be used only for integer types and the length restrictions can be used only for string. The syntax for the restriction attribute is: /*restriction restr_1 = "value1" restr_2 = value2 /*/ 2.2 Write tags The CFG:format tag defines the format in which the data will be written. The formats defined are global and can be referenced in other input files. The syntax is: /*CFG:format:formatname:"the format"/*/ the format is a concatenation of strings and parameters (@*). Example: /*CFG:format:struct2:"'{'+@*+','+@*+'}'"/*/ The format can include the new line character \n. The CFG:print tag is used to write the data in the configured files. The tag needs to be placed exactly where the data needs to be written. Syntax: /*CFG:print:element_name:format/*/ The element_name is the name of the elements to be displayed. The format can be a locally defined format or the name of a globally defined format. Example of CFG:print with global format: Example of CFG:print with local format: /*CFG:print:element_person:"'{'+@name+','+@age+' }'"/*/ The CFG:print tags can be nested. In a CFG:print with global format we can give as parameter for the format another CFG:print tag specifying the element and the format name. The syntax of a nested print tag is: element_name : global_format (format parameters) Restriction pattern minexclusive mininclusive maxinclusive maxexclusive totaldigits minlength Meaning takes as value a regular expression minimum exclusive value minimum inclusive value maximum inclusive value maximum exclusive value total number of digits minimum number of characters 3 The Automatic Configurator 3.1 How to use the application? The application needs first to be integrated as a external in ConfigTool by adding a <External> element in the properties.xml from the ConfigTool folder. <EXTERNALS> <library enable="true" ISBN:

4 entrypoint="main.entrypoint" icon="configtool_path/ac.gif" label="run Automatic Configurator" module="configtool_path/automaticcon figurator.jar"/> </EXTERNALS>, where configtool_path is the path to the ConfigTool directory, ac.gif is the application icon and has to be placed in the ConfigTool folder, and the AutomaticConfigurator.jar is the application jar file and has to be placed also in the ConfigTool folder. To use this application, the developer needs to insert tags in the generic source files. The application is run from ConfigTool by selecting from the menu Externals the item run Automatic Configurator. The application user interface will be displayed (Figure 2). Fig.2. Automatic Configurator user interface The application requires a name for the project, the path to the folder containing the tagged input files, and a path where to put the results. If the check button Create project is checked then the application will also generate the ConfigTool project files, else it will only generate an XML file, a corresponding XML Schema file and an XSL file for each input file. The generated files will be placed in a folder which name will be the name specified by the Project name entry field. Figure 3 shows the structure of the output folder. If the developer has chosen to generate the ConfigTool project files, he can then open the project with ConfigTool, instantiate the data by adding elements in the XML file, and then generate the configured source files with ConfigTool. The configured code is ready for delivery because the tags that were initially added between comments are deleted. 3.2 How the application works The application works in four steps (Figure 4). First it reads the input files, than in scans the files for the script tags, it checks the consistency of the data and it writes the XML file, XML Schema file, XSL files, and ConfigTool project files. The most complex part is the files scanning. The application uses regular expressions [4] to scan the input files for the tags. These regular expressions mach first the beginning and the end of the tags and then with other regular expressions the content is analyzed and specific objects are created, or if the content is not valid an error message is displayed. Example of regular expressions used for the CFG:format tag, the name of the format and the format respectively: (/\\*CFG:format:)(.+)(:\\s*\"{1})(.+)(\"{1}\\s*/\\*/) \\s*[a-za-z][a-za-z0-9_]*\\s* \\s*(('[.[^'@]]*'\\s*) (@\\*\\s*)){1}((\\+\\s*@\\*\\s*) (\ \+\\s*'[.[^'@]]*'\\s*))* Input Reader Scanner Consistency check Output writer Fig.4. Application Architecture Fig.3. Output folder structure The first expression searches for the extremities of the tag, the second expression checks the validity of the name and the third one checks if the format is a concatenation of strings ISBN:

5 The content of the nested tags (CFG:typedef, CFG:inst, CFG:print) is scanned recursively because they have a tree-like structure. After scanning, the application checks the consistency of the data. It checks if the type of CFG:element tags exist, the type of CFG:attribute tags is a base type or a type defined by a restriction and it checks if the xpath specified in a link attribute exists. If the consistency check is successful the application writes the output files. The application has a well developed error reporting system. The application doesn t stops at the first occurring error. This helps the developer to find and correct the syntax and consistency errors. 4 Examples For a better understanding of how the application generates the content of the output files we will give some examples of input script tags and the generated code. In the following example, we have a data structure that represents a date of birth. /*CFG:typedef*/ /*name="date_of_birth"/*/ /*name="year"/*/ /*type= int /*/ /*restriction pattern= (19) (20)[0-9]{2} /*/ /*/ CFG:attribute*/ /*name="month"/*/ /*type= int /*/ /*restriction mininclusive = 1 maxinclusive = 12 /*/ /*/ CFG:attribute*/ /*name="day"/*/ /*type= int /*/ /*restriction mininclusive = 1 maxinclusive = 31 /*/ /*/ CFG:attribute*/ /*/CFG:typedef*/ This script will generate the following lines in the XML Schema file: <xs:complextype name = "date_of_birth"> <xs:attribute name="year" use="required"> <xs:simpletype> <xs:restriction base="xs:int"> <xs:pattern value="(19) (20)[0-9]{2}"/> </xs:restriction> </xs:simpletype> </xs:attribute> <xs:attribute name="month" use="required"> <xs:simpletype> <xs:restriction base="xs:int"> <xs:mininclusive value="1"/> <xs:maxinclusive value="12"/> </xs:restriction> </xs:simpletype> </xs:attribute> <xs:attribute name="day" use="required"> <xs:simpletype> <xs:restriction base="xs:int"> <xs:mininclusive value="1"/> <xs:maxinclusive value="31"/> </xs:restriction> </xs:simpletype> </xs:attribute> </xs:complextype> For the next example we will consider the following format and print tags /*CFG :format :birth_date :"'{'+@*+'/'+@*+'/ +@*+ },\n'" In the XLS file the following lines will be generated: </xsl:text> <xsl:for-each select="//date_of_birth"> <xsl:text>{</xsl:text> <xsl:value-of select="@month"/> <xsl:text>/</xsl:text> <xsl:value-of select="@day"/> <xsl:text>/</xsl:text> <xsl:value-of select="@year"/> <xsl:text>}, </xsl:text> <xsl:text> 5 Results The goal of this project was to improve the time spent by software developers on configuring the generic code and to eliminate the bugs introduced by consistency errors. The application provides the following functionalities: It generates the ConfigTool project files ISBN:

6 It generates an XSL file for each input file The generated XSL files don t contain the initial tags The folder with the results has a fixed subfolder structure. The user interface requires the name of the project, the input folder and the output folder path, and the user can choose to generate the ConfigTool project files or not. 6 Conclusions and further development The project facilitates the software developer s work on configuring the generic code. It improves not only the time spent to configure the code, but also improves the quality of the code by eliminating consistency errors. The application can be extended by adding more user defined function in the generic.jar. References: [1] Erik T. Ray, Learning XML, O Reilly, [2] Eric van der Vlist, XML Schema, O Reilly, [3] Doug Tidwell, XSLT, O Reilly, [4] Mehran Habibi, Java Regular Expressions, Apress, [5] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Pattern Oriented Software Architecture, Vol 1: A System of Patterns, J.Wiley&Sons, [6] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object- Oriented Software, Addison Wesley, ISBN:

XML Format Plug-in User s Guide. Version 10g Release 3 (10.3)

XML Format Plug-in User s Guide Version 10g Release 3 (10.3) XML... 4 TERMINOLOGY... 4 CREATING AN XML FORMAT... 5 CREATING AN XML FORMAT BASED ON AN EXISTING XML MESSAGE FORMAT... 5 CREATING AN EMPTY