The rising adoption and incorporation of computers into everyday life requires human-computer interaction methods to be efficient and easy to understand. Simultaneously, complexities of underlying computer systems are increasing, inherently requiring deeper understanding and a detailed level of human-computer interaction methods. Software wizards are one important example from the category of tools that simplify this interaction. Through a simple, domain-specific, and targeted set of guided questions, wizards allow complex tasks to be completed quickly and simply. Tasks accomplished by wizards range from simple information collection to complex system configuration. Because wizards are task-specific, their lifespan is short and thus must be easily and quickly adapted such that the cost associated with wizard maintenance is minimized. This paper outlines such wizard requirements and provides a metamodeling approach to wizard generation. A domain-specific modeling language is presented, which has been shown to be helpful in the generation of domainspecific wizards that are capable of adapting to changing requirements.
Many advances in technology emerge from mechanisms that hide
underlying accidental complexities by introducing additional
layers of abstraction. The renewed interest in domain-specific
languages is an example of how higher levels of abstraction can
assist end-users in describing concerns from the problem space of
a particular domain, as opposed to adopting notations of a specific
solution space (e.g., use of a general-purpose programming
language or middleware). Software wizards [
Because wizards are domain and problem specific, they are often transient and temporary in nature. New versions and various compositions of wizards need to be created, each having a possibly short life span. As such, allocating significant effort to wizard creation is poor use of one’s time and should be minimized. We realized that a significant improvement in wizard composition could be offered by providing a modeling approach that could be used by a domain expert to design targeted wizards. A domain user can use the generated wizard to create necessary artifacts based on the parameters supported through the wizard questions. By investigating this technique, two categories of users and generators emerged: (1) the domain expert who uses a DSML for specifying a wizard in his/her own domain; this user uses the DSML to concentrate on collecting desired information, (2) the domain user who uses the wizard that was designed by the expert; this user provides specific and targeted information.
The idea of wizard composition and guided information collection
contributes to the trend of improved abstraction mechanisms for
specifying application information. By applying model-driven
engineering (MDE) [
The roles of each user and the tools that they use are highlighted in Figure 1. The DSML generates the corresponding wizard (including page formatting and composition), which is then used by the application developer to provide descriptive information about the application through a targeted set of questions. After completing the wizard, an XML document is created corresponding to the data that was collected (i.e., correctly formatted, ASL schema conforming document).
Grid expert
Application developer Instance model
Application specific wizard
ASL
XML document
Using MDE to compose wizards requires the design of a metamodel capable of representing necessary entities within the wizard domain. Thus, determining the purpose of a metamodel depends on the type of wizards that will ultimately be created. In order to distinguish general types of metamodels to be created, we separate wizards into two broad categories: plain and guided. Plain wizards correspond to simple page sequencing with appropriate fields incorporated into each page. The categorizing components of this type of metamodel are needed to enable and handle connectivity between different pages, sequencing of the pages, data passing and storage across the pages, as well as page design (including proper page formatting). There is a single path of execution built into this type of wizard at the time of model creation. After the model is created, the generator is in charge of converting the model into underlying code (e.g., Java, HTML). Even though this type of wizard may seem somewhat trivial, the task that must be handled by the wizard generator at this stage is two-fold: a) create the user interface under given constraints; and b) simultaneously and automatically implement the method of capturing user data where it is output in the format (e.g., text, XML, VoiceXML) specified by the user. Depending on the underlying technology used, the correct method of data passing must be applied (e.g., if a wizard is created in HTML use CGI or servlets). This step of wizard generation must be implemented in the generator at a very generic level because the end-user denotes their intention by connecting two individual pages, but does not provide any additional parameters. The result of the modeling task is the specification of a software configuration wizard where the user specifies the necessary information to link appropriate libraries and the location of needed services.
Guided wizards extend the concept of page sequencing and are
more closely related to expert systems [
When using a generator for a wizard model and transforming it into the wizard implementation (e.g., HTML or source code), there is the additional requirement to manage control flow elements for individual user choices. This logic must be customized to the particular wizard and be completely transparent to the end-user. Beyond making the necessary connections at the page level, the generator must be capable of composing necessary code, including page scoping which introduces new challenges for the generator developer. Figure 2 provides a graphical representation of these considerations, where the workflow of a guided wizard can be seen. The user initially provides some data, which leads to a subsequent page that may branch off into several possible pages. Selection of the subsequent page is determined on user input at run-time. Each page may branch into multiple subsequent pages, some of which can be equivalent in context, even though the paths may differ. At each step of the wizard, control flow (CF) code logic must be provided by the wizard generator along with the code for data storage that incrementally constructs the resulting document (e.g., Data).
C
To investigate the benefits of model-driven generation of wizards,
we developed a metamodel capable of representing wizard
components found in ASL. A model compiler was also developed
to generate the corresponding HTML code to represent the
wizard. As a supporting tool, we used the Generic Modeling
Environment (GME) [
The modeling language mirrors the structure of ASL. Because ASL is a hierarchically structured language, which is compartmentalized so that separate sections of a document are logically related, the metamodel conforms to the desired scoping rules of individual pages. By providing hierarchical components within the metamodel based on segregation of individual sections of ASL, the metamodel supports logical and meaningful structure of wizard generation to the grid expert. These sectionallystructured components provide page scoping, which allow the user to logically separate individual pages into subsections. This assists in keeping the number of pages to a manageable level. Because pages at separate sections of a wizard are generally dissimilar, metamodel segregation also minimizes the requirement for redundant page composition. At the current stage of development, the metamodel is capable of representing individual page components, compose those into a meaningful format and make them part of a larger section. Additionally, connections between entire pages corresponding to ASL sections can be established.
Figure 4 shows the metamodel with numbered elements, which are referenced in the rest of this section. In the metamodel, there are three major sections: section model, connection elements and individual page components. The section model (number 6) is the starting element of the entire metamodel setting the connectivity rules and encompassing all the other components available in the metamodel. The connectivity elements (numbers 1-5) establish different types of connections (i.e., whether components belong to a single page or establish connections between pages), and the remaining elements (numbers 7-15) correspond to wizard page components. All of the elements except number 8 directly correspond to page components such as text box or a drop down menu. In the case of composite elements (e.g., drop down menu, radio button group), lower level elements are provided to allow user creation of individual user options. Number 8 is a ‘help element’ allowing each element to be associated with contextsensitive help (as supplied by the metamodel user).
A model compiler was developed for this metamodel to generate the wizard in HTML and accommodate for proper page formatting, sequencing and transitioning. The development of the model compiler to support all available features of the corresponding metamodel presented a significant challenge. The current implementation of the model compiler is limited in functionality to support generation of HTML pages realizing the desired page formatting. Page arrangement and page connectivity is still unavailable. The major challenge arose from the need to automatically establish connectivity protocols based on different types of connected objects within a model. A sample page of the generated wizard in HTML is provided in Figure 3. This figure shows the initial page of the wizard, corresponding to the general information collection page of ASL. The figure also shows the metamodel supplied outline of the interactive help functionality.
This paper is a report of work in progress that started with a specific goal of producing wizards to assist in grid document and application configuration. During the course of our investigation, we realized that our modeling language was broader in scope and applicable to multiple domains. This paper provides a motivation of the requirements and challenges for specifying the composition of generic wizards through the use of DSMLs. A contribution of this work is the two levels of indirection that have to be handled through the metamodeling environment. This means that the compiler must seamlessly produce not only the code for the wizard composition, but it also must incorporate code into the wizard that will store the data provided to the wizard at run-time in the appropriate format. The data storage component is not explicitly defined in the instance model and thus must exist in the generator. Provisioning of such functionality requires broad generality in the generator that must be capable of automatically invoking (i.e., as implied by current environment and/or user input) appropriate code. Development of such generalized code requires much interdependence between various code modules as well as complex code generation two levels deep (i.e., code generated by the model compiler is the wizard code). This generated code must subsequently be capable of responding to wizard requirements and guide the wizard actions as well as generate the final output.
A DSML was designed to support the approach. In the
development process, issues arose with the implementation of the
compiler code dealing with the support for the two levels of
indirection. Because both of the mentioned levels must
simultaneously be supported in the compiler code accommodating
for any possible combination of elements found in the metamodel,
the compiler encountered several challenges. This was due to the
fact that at each step of the wizard and at each level of indirection
very specific code needed to be created automatically. Portions of
generator code were often found to be equivalent and dependent
on dispersed snippets of code inviting generator code components
to be indirectly connected. Use of standard object-oriented
programming techniques resulted in inconsistent functionality that
was hard to manage and maintain. More specifically, this was
referring to compiler code that was used to generated page
connections and organize page layout. Because each component
was slightly different depending on the context, compiler code
needed to be adjusted accordingly rather than simply being able to
reuse it transparently. A need to modularize code into more
manageable components, each capturing the desired functionality,
became apparent. Thus, we are considering the use of techniques
such as the Aspect-Oriented Programming [