Transformations Between Specifications of Requirements and User Interfaces Sevan Kavaldjian, Kizito Ssamula Mukasa Jürgen Falb Hermann Kaindl Fraunhofer Institute for Institute of Computer Institute of Computer Experimental Software Technology Technology Engineering (IESE) Vienna University of Vienna University of Germany Technology, Austria Technology, Austria kizito.mukasa@ falb@ict.tuwien.ac.at {kavaldjian, kaindl}@ iese.fraunhofer.de ict.tuwien.ac.at ABSTRACT cilitate combined work on requirements and user interfaces Separating requirements from user interface specifications along the process dimension as well. In particular, we devel- often leads to unusable systems or to systems that do not oped transformations between artifacts of requirements and support the users’ needs. We address this issue by introduc- UI specifications within RSL. ing explicit transformations between models of these differ- ent “worlds”. In fact, we show how to transform artifacts The remainder of this paper is organized in the following in a model specifying requirements to artifacts in a model manner. First we sketch those parts of the RSL Metamodel specifying a user interface, and vice versa (inverse transfor- needed within the scope of this paper. Then we present our mations). We also transform from a more abstract to a more overall approach of transforming in this context. For elabo- concrete model of a user interface, and vice versa. In ef- rating on this overall approach, we specify (MOLA1 ) trans- fect, this allows starting either from requirements and get- formation rules from the requirements specification to an ab- ting support for transforming to a user interface, or from a stract UI specification, and vice versa. In addition, we spec- user interface prototype and getting support for transforming ify such rules for transforming from an abstract UI specifi- to requirements. cation to a more concrete UI prototype. Finally, we compare our approach with related work. INTRODUCTION Usually, model transformations lead from higher-level to BACKGROUND lower-level models and program code in software develop- In order to make this paper self-contained, we need to sketch ment, e.g., from architectural to design models. Model- some background material about RSL. In particular, we ex- driven generation of user interfaces (UIs) typically leads plain those parts of its metamodel for specifying require- from higher-level task models to UI models (at certain lev- ments and UI that we build our transformations upon. els of abstraction) and a final UI. Unlike other approaches, we also transform between models on the same abstraction Scenarios and use cases are popular in requirements engi- level. So, in addition to operationalizing as usual, we make neering these days. Therefore, RSL includes ConstrainedLan- use of artifacts in one “world” for creating related ones in guageScenarios contained in Use Cases. These provide a tex- another. Additionally, we allow transformations back and tual representation and consist of a sequence of SVO sen- forth between the same pair of models. tences describing the flow of interaction between the user and the system to be developed. An SVO sentence has a We present this approach of bidirectional transformations Subject and a Predicate, which in turn has one Verb, and an between models of the same level of abstraction in the con- Object. Each word used in a sentence can be mapped to its text of our previously defined Requirements Specification specific meaning in the domain vocabulary. It is possible Language (RSL) [3]. In contrast to most other languages to define the meaning of each word in this context, also by for requirements specification, RSL is a language that inte- reusing terminology from WordNet [7]. grates requirements with UI specifications [5]. This integra- tion along the representation dimension is supposed to fa- For specifying a UI, RSL provides generic elements that make it possible to define a UI independently of modality and toolkit. The static aspects of the UI, i.e., its structure and layout, can be described by using elements like InputUIEle- ment for data input; TriggerUIElement for triggering actions; SelectionUIElement for exclusive or non-exclusive selection from more than two options; and UIContainer or UIPresenta- tionUnit, which are used as containers of other UI Elements. 1 http://mola.mii.lu.lv/ MDDAUI 2009. CEUR Workshop ceur-ws.org ISSN 1613-0073 1 Proceedings Figure 1. Overview of specifications and their transformations. The dynamics of the UI, i.e., the behavior related to user in- part of a more concrete UI, i.e., a UI Prototype. Of course, teraction, can be described by using RSL elements like UIS- this prototype is most likely not the user interface of the real toryboard, UIScene, and UserAction. A UIStoryboard is a series application yet, but it may well serve the purpose of illus- of scenes displayed in a sequence. The “presentations” of trating the textual scenario in the requirements specification the individual scenes are defined in UIScenes. UIScenes can to users. When concrete scenarios are directly used for UI be connected by UserActions indicating the triggering action design, they may well lead to bad UIs, since they may in- of the user. A UserAction is performed on one source UIEle- duce an interaction approach defined ad hoc in a different ment in a predecessor UIScene and can result in a transition context. So, such scenarios should be made more abstract to a successor UIScene as well as influence some of its UIEle- first to capture the essence [2]. ments. We may also assume that it goes the other way round. Users Since these UI elements are modality-independent, they spec- themselves or together with a UI designer have developed a ify an abstract UI (according to [1]), that can be used for the prototypical storyboard, already using the GUI modality in different modalities found in advanced user interfaces. In its concrete syntax. This approach facilitates their intuition order to make a UI specification more understandable for a of how a system to be built may be used. For developing user, a concrete UI [1], which defines the modality, is bet- such a piece of software, however, a requirements specifica- ter suited. Therefore, RSL also includes related elements, tion may still be needed or simply useful for the developers. whose concrete syntax can even serve for specifying a UI Instead of having a requirements engineer manually write Prototype, see the bottom of Figure 1. such a specification, transformation rules according to T2’ in Figure 1 may be applied. They would lead to a partial OUR OVERALL APPROACH OF TRANSFORMING model of an abstract UI, this time based on the UI Proto- Based on the RSL language and its metamodel, let us il- type. Applying transformation rules according to T1’ would lustrate our overall approach of transforming between re- then lead to a part of the requirements specification, a sce- quirements and UIs, more precisely their specifications in nario. Again, the generated scenario might not be in the final the form of models. version yet, but it is consistent with the UI Prototype. Assume that a requirements engineer has specified a sce- nario using SVOScenarioSentences [3]. Instead of having a UI TRANSFORMATIONS FROM REQUIREMENTS SPECIFI- designer manually create a related UI specification, transfor- CATIONS VIA UI SPECIFICATIONS TO UI PROTOTYPES mation rules according to T1 in Figure 1 may be applied. Let us illustrate now what transformation rules are needed to They would lead to a partial model of an abstract UI. Apply- transform our concrete example in Figure 1. It consists of a ing transformation rules according to T2 would then lead to ConstrainedLanguageScenario composed of the following two 2 tion is the text of the Sentence and its sceneNumber equals the seqNumber of that sentence. The UIScene is linked to the UIPresentationUnit corresponding to this sentence. Rule 6: Each SVOScenarioSentence whose subject is not “Sys- tem” is transformed into a UserAction. Its source is the UIEle- ment (other than the UIPresentationUnit) associated with the sentence. The predecessor of this UserAction is the UIScene of the previous sentence and its successor is the UIScene of the current sentence. Applying these rules to our example results in the UI Specifi- cation Model in the right box of Figure 1. The rule execution order has no impact on the generated model. Figure 2 illustrates the formalized Rule 1 for T1 in MOLA, composed of the following elements. The outer bold rect- angle symbolizes a for-each loop. The rounded rectangle inside represents the actual rule, that will be repeated for each matched element. The small boxes inside the rule rep- resent different kinds of classes, depending on their border- line style. When the thickness of the border line is regular, they represent a “normal” class. A bold border lined box represents a loop variable. A dashed lined box border repre- sents a class that will be created by the transformation rule. The small black circle represents the starting point of the rule. The double rounded circle represents the end point of the rule. In particular, Rule 1 iterates over all SVOScenar- ioSentences. Whenever the type of the verb is “select” and the noun is not plural, the rule matches. In this case, a Se- lectionUIElement of the UI Specification Model is generated. Figure 2. MOLA Rule R1 for T1. The name attribute is set to the name of the noun and the maximumSelectableOptions attribute is set to 1. SVOScenarioSentences: 1. “User confirms selection.” and 2. The following rule is one example of transformation T2: “User selects exercise.” Rule 7: Each SelectionUIElement that only allows the selection The following rules implement the transformation T1: of one Option is transformed into a Class associated with the Combobox Stereotype. The name of the class is composed Rule 1: Each SVOScenarioSentence whose verb implies “se- of the name of the SelectionUIElement and “ComboBox”. lection” is transformed into a SelectionUIElement. Its name is the Noun in the VerbPhrase (see [3] for the definition of Figure 3 illustrates the formalized Rule 7 for T2 in MOLA. It VerbPhrase). iterates over all SelectionUIElements where the attribute max- imumSelectableOptions is set to 1 in the UI Specification and Rule 2: Each SVOScenarioSentence whose verb implies “trig- creates one class each. The name attribute of the class is gering an action/event” is transformed into a TriggerUIEle- set to the SelectionUIElement name to which the suffix “Com- ment. Its name is the Noun in the VerbPhrase. boBox” is added. It also creates an association with the cor- responding stereotype. Rule 3: Each SVOScenarioSentence whose verb implies “show- ing information” is transformed into a UIPresentationUnit. The name of this UIPresentationUnit is the Noun of the Object in TRANSFORMATIONS FROM UI PROTOTYPES VIA UI SPEC- the VerbPhrase. IFICATIONS TO REQUIREMENTS SPECIFICATIONS This section introduces transformations for T1’ and T2’, from Note, that these rules both require and utilize a mapping be- UI Prototypes via UI Specifications to Requirements Speci- tween synonyms. We reuse this mapping from WordNet. fications. Rule 4: Each ConstrainedLanguageScenario is transformed into The following rule for T1’ represents the exact opposite to a UIStoryboard of a similar name. Rule 1 in T1: Rule 5: Each SVOScenarioSentence in a ConstrainedLan- Rule 1’: Every SelectionUIElement with the attribute maximum- guageScenario is transformed into a UIScene. Its sceneDescrip- SelectableOptions set to 1 is transformed into an SVOScenar- 3 They capture interactions with sketches and transform them into structural patterns of CTT. Similarly to our approach, they transform up and downwards in the reference frame- work [1]. In addition, we transform horizontally (on the same level of abstraction) and between different “worlds”. CONCLUSION This paper presents a model-driven approach to transforma- tions from requirements to UI specifications and vice versa. We are not aware of any transformation approach between these different “worlds”, which are partly even on the same level of abstraction. And it is new to have transformations back and forth between the same pair of models. This approach of explicit transformations may help to bridge the usual gap between separated requirements and UI spec- ifications. It may also make the overall development more efficient, since it makes explicit use of artifacts from any one “world” to create artifacts in the other one. Figure 3. MOLA Rule R7 for T2. ACKNOWLEDGMENT This research has been carried out in the ReDSeeDS project ioSentence. The Verb “select” is the representative of the and is partially funded by the EU (contract number IST- equivalence class for selection. The noun is the value of the 33596 under the 6th framework programme), see http: name attribute of the SelectionUIElement. //www.redseeds.eu. This rule looks quite similar to Rule 1 in T1, but there is a REFERENCES subtle difference with the inverse transformation, since Rule 1. G. Calvary, J. Coutaz, D. Thevenin, Q. Limbourg, 1’ always transforms to the verb “select”. If another verb L. Bouillon, and J. Vanderdonckt. A unifying reference of the same type is used in the source model of T1, e.g., framework for multi-target user interfaces. Interacting “chose”, then applying T1 and subsequently T1’ will not re- With Computers Vol. 15/3, pages 289–308, 2003. sult in the identical model. This is more of theoretical than 2. L. Constantine and L. A. D. Lockwood. Software for of practical interest, since transforming back and forth iden- Use. ACM Press, New York, NY, 1999. tically is not needed for applying this approach. 3. H. Kaindl, M. Śmiałek, D. Svetinovic, The following rule for T2’ represents the exact inverse to A. Ambroziewicz, J. Bojarski, W. Nowakowski, Rule 7 in T2: T. Straszak, H. Schwarz, D. Bildhauer, J. P. Brogan, K. S. Mukasa, K. Wolter, and T. Krebs. Requirements Rule 7’: Every class with the suffix “ComboBox” in the specification language definition. Project Deliverable name attribute is transformed into a SelectionUIElement with D2.4.1, ReDSeeDS Project, 2007. www.redseeds.eu. the maximumSelectableOptions attribute set to 1. 4. G. Mori, F. Paterno, and C. Santoro. Design and The transformation T3 can be seen as a composition of trans- development of multidevice user interfaces through formation rules for T1 and T2. The transformation T3’ can multiple logical descriptions. IEEE Transactions on be seen as a combination of the rules for T1’ and T2’. Software Engineering, 30(8):507–520, 8 2004. 5. K. Mukasa and H. Kaindl. An integration of RELATED WORK requirements and user interface specifications. In Mori et al. [4] introduced ConcurTaskTrees (CTT) as task Proceedings of the Sixteenth IEEE International models, from which they can derive and semi-automatically Requirements Engineering Conference (RE’08), generate UIs. Their approach leads from higher-level to September 2008. lower-level models (like our T2 transformation). Our ap- 6. J. I. Panach, S. Espana, I. Pederiva, and O. Pastor. proach as presented in this paper does not start from high- Capturing interaction requirements in a model level task models, but from detailed requirements specifica- transformation technology based on MDA. Journal of tions. Alternatively, our approach can start from concrete Universal Computer Science, 14(9):1480–1495, 2008. UIs and lead automatically to artifacts in a requirements specification. 7. K. Wolter, M. Smialek, D. Bildhauer, and H. Kaindl. Reusing terminology for requirements specifications Panach et al. [6] propose a method to bring Software Engi- from WordNet. In Proceedings of the Sixteenth IEEE neering (SE) and Human-Computer Interaction (HCI) closer International Requirements Engineering Conference together, much as we do with our transformation approach. (RE’08), September 2008. 4