Using DomainSpecific Modeling to Generate User Interfaces for Wizards

1
Using Domain-Specific Modeling to Generate User
Interfaces for Wizards

• Enis Afgan, Jeff Gray, Purushotham Bangalore
• University of Alabama at Birmingham (UAB)
• Department of Computer and Information Sciences

MDDAUI Workshop MoDELS 2007, Nashville, TN
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

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

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

• ltaslApplicationDescriptiongt
• ltaslApplicationNamegtDynamicBLASTlt/aslApp
  licationNamegt
• ltaslDescriptiongtA 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.lt/aslDescriptiongt
• ltaslVersiongt0.1lt/aslVersiongt
• ltaslCategorygtMaster-Workerlt/aslCategorygt
  
• ltaslAuthorgt
• ltaslNamegtEnis Afganlt/aslNamegt
• ltaslEmailgtafgane_at_uab.edult/aslEmailgt
• ltaslOrganizationgtUniveristy of
  Alabama at Birmminghamlt/aslOrganizationgt
• lt/aslAuthorgt
• ltaslOwnergt
• ltaslNamegtEnis Afganlt/aslNamegt
• ltaslContactInfogtafgane_at_uab.edult/aslC
  ontactInfogt
• ltaslOrganizationgtUniveristy of
  Alabama at Birmminghamlt/aslOrganizationgt
• ltaslSupportInfogtunsupportedlt/aslSupp
  ortInfogt
• lt/aslOwnergt

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

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
Questions?

• Slides available at www.cis.uab.edu/afgane

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