Using Domain-Specific Modeling to Generate User Interfaces for Wizards

1. Using Domain-Specific Modeling to Generate User Interfaces for Wizards MDDAUI Workshop MoDELS 2007, Nashville, TN EnisAfgan, Jeff Gray, Purushotham Bangalore University of Alabama at Birmingham (UAB) Department of Computer and Information Sciences This project is supported by an NSF CAREER grant.

2. Wizards and Abstraction • Many advances in technology emerge from mechanisms that hide underlying accidental complexities by introducing additional, but simpler layers of abstraction • Software wizards provide simplified user interaction methods by guiding configuration and customization through a set of targeted questions • Many activities that previously involved lower level knowledge of the inner workings of a specific application can thus be avoided, inherently improving productivity

3. Software wizards transiency • A challenge emerges, however, with respect to how the actual wizards are designed, created, and maintained because: • Wizards are domain and problem specific • New versions and various compositions of wizards need to be created quickly with a short lifespan Temporary Version Domain

4. Benefits of MDE wizard generation • End-users can quickly create a pipeline of wizard pages using high-level modeling abstractions, rather than low-level code artifacts; such models are easier to change than the equivalent code representation • Different model compilers can be associated with the wizard DSML to generate wizards in many different formats (e.g., HTML, Java) • Each wizard can subsequently and transparently store obtained data in different formats (e.g., text, XML, VoiceXML)

5. Wizard classification • Based on generation complexity, two types of wizards exist in many applications • Plain wizards: correspond to simple page sequencing with appropriate fields incorporated into each page • Guided wizards: must incorporate generic code that, based on user input at runtime, can appropriately sequence wizard pages

6. Generating plain wizards • Metamodel needs to enable and handle: • Wizard generator must be capable of: • creating the user interface under given constraints • simultaneously and automatically implementing the method of capturing user data where it is output in the format (e.g., text, XML, VoiceXML) specified by the user TXT Connectivity Page sequencing Data passing TXT Data storage across pages Page design

7. Generating guided wizards • Guided wizards resemble expert systems • Wizard designer primarily concerned with page components rather than entire pages • Individual pages must be broken up into components where, based on input of wizard user at runtime, such components can dynamically be used to compose complete wizard pages at runtime • Page compositions lead to page scoping within a page as well as across pages • Various wizard paths may take user to a page with equivalent information – page scoping becomes important because of requirement to reduce size of the model

8. Handling Control Flow points • When transforming a model into source code, there is a requirement to manage control flow (CF) elements for individual user choices • CF logic must be customized to the particular wizard and be transparent to the end-user • CF logic includes connections at the page level and also must deal with page scoping CF CF CF CF CF CF CF CF TXT TXT TXT TXT

9. Case Study: ASL for Grid Deployment • ASL is a new, XML- based, grid language created to provide a method for capturing the core purpose of the application, its requirements, and its options • It aims at enabling standardized, application-specific information sharing between grid users • <asl:ApplicationDescription> • <asl:ApplicationName>DynamicBLAST</asl:ApplicationName> • <asl:Description>A wrapper for BLAST application that parallelizes BLAST job execution • by dynamically selecting a number of queries from a pool of user submitted query file • and based on available resources it selects the most appropriate version of BLAST • algorithm to complete the job as soon as possible.</asl:Description> • <asl:Version>0.1</asl:Version> • <asl:Category>Master-Worker</asl:Category> • <asl:Author> • <asl:Name>Enis Afgan</asl:Name> • <asl:Email>afgane@uab.edu</asl:Email> • <asl:Organization>Univeristy of Alabama at Birmmingham</asl:Organization> • </asl:Author> • <asl:Owner> • <asl:Name>Enis Afgan</asl:Name> • <asl:ContactInfo>afgane@uab.edu</asl:ContactInfo> • <asl:Organization>Univeristy of Alabama at Birmmingham</asl:Organization> • <asl:SupportInfo>unsupported</asl:SupportInfo> • </asl:Owner> • <asl:PublishedUnderLicence>None</asl:PublishedUnderLicence> • </asl:ApplicationDescription>

10. Applying MDE to generate ASL

11. WizardGen Metamodel

12. A prototype metamodel • As a prototype, we developed a metamodel for representing wizard components and a model compiler capable of generating the corresponding HTML code; used these for an ASL instance model • The following elements of a wizard can be described in the metamodel prototype Connectivity Page sequencing Page design HTML HTML generation

13. Using the metamodel (1)

14. Using the metamodel (2)

15. Generated wizard

16. Metamodel experiences • ASL is a hierarchically structured language, where separate sections of a document are logically related - the metamodel exploits this structure and uses it as scoping rules for individual pages, thus minimizing number of pages to be generated • A model compiler accounts for proper page formatting, sequencing, transitioning, and data collection and storage • The model compiler must be capable of seamlessly producing not only the code for the wizard, but also code that will store the wizard-collected data provided to the wizard at run-time • Implies inclusion of two-level code where model compiler not only generates wizard code, but also embeds executable code into the wizard itself that, once wizard is executed, is capable of manipulating obtained data in the current environment • Metamodel details are provided in paper

17. Model compiler challenges • The development of the model compiler to support all available features of the corresponding metamodel presented a significant challenge and is currently limited in functionality to support generation of HTML pages realizing the desired page formatting • The major challenge arose from the need to automatically establish connectivity protocols based on different types of connected objects within a model • This is because the data storage component is not explicitly defined in the instance model and thus must exist in the compiler alone • Provisioning of such functionality requires broad generality in the model compiler that must be capable of automatically invoking appropriate code (i.e., as implied by current environment and/or user input) • Development of such generalized code requires much interdependence between various code modules as well as complex code generation that requires multiple passes over the model

18. Conclusions • Domain-Specific Modeling can be an effective tool in improving composition and modification of transient code such as software wizards • Major challenges dealing with two levels of code generation arose, likely stemming from the model compiler coding practices

19. Slides available at: www.cis.uab.edu/afgane Questions?

20. Future work • Creation of ‘plain wizard’ version that can easily be modified and subsequently used • Address challenges with two levels of indirection during code generation • Adoption of Aspect Oriented Programming (AOP) techniques to leverage required code dependencies and interactions • A need to modularize code into more manageable components, each capturing the desired functionality