This paper demonstrates an approach to software generation where xml representations of models are transformed to implementations by XSLT style sheets. Although XSLT was not primarily intended for this use, it serves quite well. There are only few problems in this approach, and we identify these based on our examples

Brinkman, R.

Rein, H. van

English

van Rein, H.

Brinkman, Richard

University of Twente Research Information

Home-grown CASE tools with XML and XSLTRick van Rein Richard BrinkmanUniversity of Twente, the Netherlands{vanrein,brinkman}@cs.utwente.nlMarch 13, 2000AbstractThis paper demonstrates an approach to software generation where xmlrepresentations of models are transformed to implementations by xsltstylesheets. Although xslt was not primarily intended for this use, itserves quite well. There are only few problems in this approach, and weidentify these based on our examples.Keywords: Software generation, case tools, xml, xslt.IntroductionWith the increasing popularity of the Internet, the html language has grown outof proportions, and the xml language is intended to structure its content better.Aside from its implications on the web, xml also receives considerate attentionfrom software developers as a standard representation for data storage, whichis mainly due to the intention of xml to model content rather than layout as iscustom practice with html. To map this content to a layout, the xslt languagewas devised; this is a lanuage that recognises patterns in xml documents andtransforms them according to a standard specification.In our work, we have used the xslt language for more than just transformationof content to layout, we increasingly generate software with it. Our experiencesare reported in this paper. We start to discuss the advantages of the xml familyof languages and tools in section 1, and continue to discuss its applicability tosoftware generation in section 2. In section 3 we give several examples, andfinally we present our conclusions.1 Why XML is Useful for ModellingAn xml document contains elements, each of which may have a number ofattributes, each of which may encapsulate sub-elements. Since xml documentsalso have a single root element, the result is a tree of (what you could call)objects.This general format has a standardised representation, and the web consortiumseems to have collected the critical mass to make it into a popular standard.This means that many tools are available for xml.1One class of tool provides parsing and writing libraries for a variety of program-ming languages. These libraries can take care of many recurring compiler tasks,including lexical analysis and name space management, because the representa-tions of these aspects is the same for all xml documents. The fact that muchof the standard compiler issues resolved before you design your own xml dataformat means that a lot of overhead is taken out of the use of such a format; thissaves considerable time in application development, and case tool developmentis not an exception to that rule.Another class of tools allows editing of xml documents, xslt specificationsand even document syntaxes. These tools rely on the self-descriptive (and thusreflective) nature of xml. Every valid xml document refers to an explicit rep-resentation of its syntax. This information can be used in editors to ensure thatonly correctly formatted information is input, and even to automatically gener-ate a graphical interface that presents the content such that it is browsable andeditable. A particularly interesting development is xml schema, which cap-tures this reflective information in xml, which means that all the advantagesof xml can be applied at reflective levels too. This drastically increases theachievable complexity and fun of xml development.2 Why XSLT is Useful for Software GenerationAn xslt stylesheet (which we shall call xslt transformers in this paper) recog-nises patterns in an xml document, and transforms these to another form. Thisrecognition of patterns is quite instrumental in describing compilers. The possi-bility to specify ‘queries’ that search the input replaces searching in self-made,compiler-internal storage structures.The input of an xslt transformer is a tree which is traversed as required togenerate a tree-structured output. This implies that any tree structure canbe generated from xslt. Among the tree structured file formats are not onlyhtml and xml, but also programs in most modern programming languages.This means that it is possible to generate programs with xslt transformers.One additional property of xml makes it particularly suitable for software gen-eration through xslt transformations, namely the possibility to mix plain text(in our case, program text) with xml elements to be resolved by another xslttransformer. Because this involves the use of multiple xslt transformers appliedin a sequence, it is possible to separate concerns according to software engineer-ing principles; notably, to implement different design decisions in different xslttransformers.In our experiments with xslt as a software generation language we have workedwith xslt transformers that make decisions like ‘web enable through cgi-binscripting’ or ‘use sql for queries’ or ‘exploit Motif’. We believe that this grain-size is quite usable in practice.The dependency structure between xslt transformers seems to vary betweensoftware generation projects, although not between source documents. Further-more, the dependency structure may mix in reflective constructs. This meansthat the transformations can get complicated and project-specific, but not be-yond the reach of make. Since the result of this project-specific tweaking usuallyis a self-built sort of case tool, we think the effort of describing the dependenciesthat way is more than worthwhile.2Library.backendLibrary.sqlLibrary.interfaceMember.lifecycle Book.lifecyclecallsif2htmlLibrary.htmlbackend2sqlsql2cgibackend2c, ...sql2jdbc, ...Library.cgi-binlifecycle2backendFigure 1: Translating Life Cycles to a web application.3 Examples Software Generation ProjectsThis paper is a report of practical experience from several projects. In thissection, we describe some situations where we benefitted from our (ab)use ofxslt for software generation.3.1 Mapping Processes to SQLIn my research, I specify life cycles, informally explained as communicatingstate diagrams. We use the case tool tcm to input diagrams, and transformits native storage format into a suitable xml description of life cycles.Figure 1 shows how these xml files are translated to a web application. Eachof the x2y labels refers to a transforming step from format x to format y.The lifecycle format describes the processes in an application, in this case aMember and a Book in a library case study. The interface format describesexternally visible events. The backend format integrates knowledge from theinput life cycles, based on the interface description, and is the starting point forboth software generation and our planned formal verification. The sql formatcontains the information from the backend, implemented in sql with such xmlannotations that it may be embedded in many ‘host’ languages, like Perl, Javaand PHP3.Some transformation steps could be encoded in xslt, but not all (at least notwithout hacking around the intentions of xslt).A fragment of the library case study on such a life cycle description is thefollowing, describing how a Book can go from Available to Out state when a3checkout event occurs with that book’s identity as the first parameter.〈lifecycle name=”Book” startstate=”START” endstate=”END”〉. . .〈transit from=”Available” to=”Out”〉〈event name=”checkout”〉〈param name=”this” type=”Book” use=”out”/〉〈param name=”m” type=”Member” use=”in”/〉〈/event〉〈/transit〉. . .〈/lifecycle〉The lifecycle2backend transformer combines a few of those life cycles, and holdsthem against an interface, which is an xml document describing externallyvisible events. We regret that xslt is constrained to a single input file, eventhough we could hack our way around it; this is why lifecycle2backend is notimplemented in xslt.Our preference would have been to construct a binary operator on life cycledescriptions, used to unite two life cycles to one life cycle. Such an approachwould greatly benefit from the ability to perform algebraic analysis on the trans-former, in this case to prove commutativity and associativity. Such checks helpto ensure the correctness of the transformers. We believe such checks can beperformed using structure induction based on the input/output file structure,which is well defined since they are xml files.The backend format can be transformed to, say, sql code. This is a decisionwhich deserves its own transformer because it defines a decision which has alter-natives; such alternatives can be specified in other transformers on the backendformat. Since sql is a language which may be embedded in practically every-thing, it is fruitful to defer the decision of the programming language to thenext xslt transformer.The sql code representing the checkout (book,member) concrete event occur-rence (where book and member symbolically represent the actual parameters) isgenerated by backend2sql, and it consists of two parts. The first part is a pre-condition to implement blocking behaviour, essentially expressing that a Bookthat is checked out cannot be checked out again:〈precondition maximum=”0” message=”. . .”〉select count(*)from Bookwhere state=’Out’ and this=〈actual param=”book”/〉〈/precondition〉Note how useful the mixture of ‘plain text’ and xml elements is here: Instead ofan embedding-dependent notation ? for a parameter, we used an xml elementto represent our intention more accurately. Also note how the implementationof a precondition element may differ between host languages, and how that ishidden from this representation by use of an xml element. These techniquesrealise the separation of concerns between transformers, by selectively markingthings as work to be done in a following transformer step.4The second part of this transaction is the actual update for this transition:〈transit lifecycle=”Book” message=”. . .”〉update Bookset m=〈actual param=”member”/〉, state=’Out’where this=〈actual param=”book”/〉 and state=’Available’〈/transit〉Combined with the precondition, and possibly other effects of checking outa book in other life cycles, a transaction may be formed some sql embeddinginterface such as jdbc or dbi. This can now be done with a next transformationstep: Another transformer for another design decision. The last stages typicallyrequire tailoring with options, such as the host, username and database namefor database access. Since xslt does not incorporate options in its translationprocess, we decided to use another transformer language for this last stage.More information on life cycles can be found on the web, http://www.cs.utwente.nl/∼vanrein/research.lc.html.3.2 User Interface GenerationModern computing has given us means of portability across platforms, of whichJava and xml are just two examples. User interfaces are not similarly easy toport to different platforms, because a user interface mostly depends heavily onthe functionality of a particular widget library. For instance, Windows offersnative support for showing tree structures, which lacks in Tcl/Tk. We thereforedid a project to describe user interfaces in a general xml format. We use xslttransformers for the translation of this generic user interface format to specificprogram code in a particular programming language. This makes it possible todescribe a user interface once and translate it to any development environmentfor which an xslt transformer exists. Such environments currently includeJava/Swing, Tcl/Tk, Appbuilder/Motif and Delphi.msgdialog.guimsgdialog.pasgui2codeframecodeframe2pasgui2codeframe2pasmsgdialog.codeframeFigure 2: Generating an xslt transformer to allow editable codeframes.Figure 2 shows how the general user interface xml files are translated to thedevelopment environment. A message dialog, described in the msgdialog.gui file,is the starting point of the xslt traject.5Such a file looks like:〈window id=”msgdialog” text=”. . .window title. . .”〉. . .〈button id=”okbutton” text=”Show message” onclick=”true”/〉. . .〈/window〉This is a window with a button named okbutton, which responds when it isclicked on by invoking a bit of code.Each xml file describing the user interface of msgdialog will be transformedto a codeframe. A codeframe is a framework in which the developer typeshis language-specific program code. A codeframe xslt transformer creates anempty 〈code〉 tag for each event in the window description. A codeframe lookslike:〈codeframe〉. . .〈code id=”okbutton” event=”onclick”〉beginShowMessage (”Hello, world!”);end;〈/code〉. . .〈/codeframe〉Here, the onclick behaviour of the previously seen button okbutton is describedin a codeframe entry; the three lines of Pascal are a specific implementation ofan event response for Delphi. Note that the separation of code fragments is ad-vantageous for future extensions, including the embedding of code fragments ofone language (like sql) into another; this can be done with an xslt transformerthat operates on codeframes.The generated codeframe is originally empty, but on regeneration of the code-frame, already previously entered program code is retained to make it possibleto keep the user interface and program code integrated while the applicationevolves. It is the developers’ task to fill in the contents of the 〈code〉 tags, butcombining them remains the responsibility of this xml based mini case tool.The second step in our parse traject is to generate the program code for theselected development environment. Because it is currently not possible to jointlyparse two xml-files like the window description and the codeframe with a singlexslt transformer, we have chosen to split this step into two sub-steps. First,we transform the window description with an xslt transformer into anotherxslt transformer. This xslt transformer contains all the language-specific codenecessary for displaying the user interface. At places where the 〈code〉 tags fromthe codeframe are to be inserted, an xslt command like〈xsl:value-of select=”codeframe/code[@id=’okbutton’ and @event=’onclick’]”/〉is inserted. This selects the Pascal code snippet given above. The second andlast step evaluates this generated xslt transformer to insert the codeframe inthe rest of the program code. The result can be compiled with a traditionalcompiler.More information and code of this interface generation project can be found onhttp://www.cs.utwente.nl/∼vanrein/PLUG.63.3 Database Schema GenerationA last practical example shows the use of xml schema, which are xml repre-sentations of xml document structure. The reflective information contained inan xml schema makes it possible to generate reflective code, such as the sqlstatements to create a set of database tables that can contain the xml datainstantiated from the xml schema.We used this technique on a project, the Linux hardware Support Database.This database includes a mirrorring scheme where (database schema indepen-dent) representations of the database content are transferred in an xml docu-ment over secure ssh network connections. For this mirroring process, we alsogenerated (from the xml schema) a program that reads xml documents fromthe secure input stream and puts its contents in the database which has thedatabase schema that was also generated.The benefit of this approach is, once again, the separation of concerns. Themirrorring process passess around a standardised format, and several databaseschemas can read/write that format. This is all fairly standard. What theabove scheme adds, is the automatic generation of all access to the databaseschema; another database schema can be selected by changing to another set ofxslt transformers. This makes it possible to employ different schema optimisa-tion techniques on different databases, but still support the communication formirrorring.An interesting problem that comes up in this situation is that xml documentsare represented as trees of objects, whereas (relational) database schemas con-tain a more general network of tuples. Furthermore, order is not implied bydatabase tables, whereas xml implicitly always assumes order to be informa-tion. This is due to the single focus on parsing xml files based on schemadefinitions, and insufficient attention to writing them.It should be noted that ibm has launched a similar project named xle. In thisproject, they worked from a dtd rather than an xml schema, and not sur-prisingly, they need annotations to address the differences between a relataionaldatabase schema and xml representation.7ConclusionsWe experienced xml as a fruitful data representation, and well worth the effortof mapping a native format to. The xslt language has been similarly fruitfulin transforming conceptual descriptions to an implementation. It seems to be agood idea to construct the transformation as a number of sequential steps, whereeach xslt stylesheet represents a design decision; this provides a placeholder foralternative decisions.We stretched xslt a bit beyond the current treatment that it receives from theweb consortium, which led to a number of problems:1. An xslt transformer takes only one input, and generates only one outputfile. This means that transformations like the life cycle compiler cannotbe (directly) implemented in xslt.2. It is not possible to make small modifications of the behaviour of an xslttransformer by supplying options and arguments to it.3. We would be quite pleased to see tools to verify an xslt transformer bytreating it as an operator, and use structural induction to verify algebraicproperties such as transitivity, idempotence, monotonicity, associativityand commutativity.4. The xml schema language specifies sufficient information for parsing anxml document; however, subtle matters like whether or not the data isordered is lacking, which makes writing out xml documents based on theirschema non-deterministic.Since we believe that our use of xslt extends the line of thinking of the webconsortium, we hope and expect that these matters can be resolved in futureversions of the xslt specification.Acknowledgements. We wish to thank the students Sander Evers, KristiaanBreuker and Jeroen van Nieuwenhuizen for their work on the graphical interfacegenerator, and Roelof van Zwol and Maurice van Keulen for helping to tamethem.8

Home-grown CASE tools with XML and XSLT

https://ris.utwente.nl/ws/files/5523326/ecoop00wme.pdf

Home-grown CASE tools with XML and XSLT

Abstract

Similar works

Full text

Available Versions

University of Twente Research Information