Funciones de los envases

To validate if the transformation chain can produce user interfaces for a more realistic application, a bottom-up approach is used to create a task model from a set of mock-ups. This set of mock-ups is designed inde- pendent of this research without the intention to reverse-engineer the be- haviour in a task model. An excerpt from the mock-ups is depicted in Fig- ure 9.2. The mock-ups comprise a process that enables the user to define the necessary tasks to create aBuyerFunderAgreement, which is basically an agreement between a buyer entity and a funder entity. These tasks involve the selection of the involved entities and defining the agreement condi- tions.

(a) (b) (c)

For this example, a behaviour domain model, theBuyerFunderAgreement

specification, is available. This model defines 8 events, triggering transi- tions that range from creating an object (create) to changing the state to

accepted. From the domain specification, we derived tasks for each argu- ment in the transitioncreate. Whereas the mock-ups define the process of creating an agreement in 5 steps, for each group an abstraction task is de- fined that contains the smaller subtasks. These tasks are adopted in a task model that simulates a realistic application. An excerpt of this model is depicted in Figure 9.3. The three main tasks are: Authenticating, Manage AgreementsandLogout.

Create BuyerFunderAgreement

Authenticating Manage Agreements

Create Agreement

Enter SP details Enter Buyer Enter Funder Enter Supplier Review input Trigger create Update Agreement Logout >> [ ] >> >> >> >> >> [>

Figure 9.3: Excerpt from theCreate BuyerFunderAgreementtask model In addition to the observations from the previous experiments, in this ex- periment we observed the following:

Observation 1. All transformations terminate and resulted in a target model. Observation 2. Manual operations were necessary to include a reaction

that enables the user to go to the previous task, as defined in the mock-ups.

Observation 3. Automatically generated titles and text for buttons are not suitable for a real-world application.

Observation 4. The state of construct elements changes during the inter- action with the user and this state is not saved. The current imple- mentation only saves the state of containers to toggle the visibility.

transformation input (xmi) output (xmi) warnings ExpressTemporalRelationships Agreement.taskd Agreement.taskd.refined 21 TaskDmodelToAUI Agreement.taskd.refined Agreement.aui 23

Agreement.mapping

AUItoGUI Agreement.aui Agreement.cui 40

Agreement.mapping

Table 9.3: The transformations involved in theBuyerFunderAgreementex- periment

model type (metamodel) auto/manual violated

constraints notes

Agreement.taskd Taskmodel manual 0

Agreement.taskd.refined Taskmodel auto 0 The reactions that enable the user to go back to the previous tasks are added by hand

Agreement.aui AbstractUI auto 0

Agreement.mapping Mapping auto 1 The automatically gener-

ated mapping model con- tains an unresolved proxy and is thus not valid.

Agreement.cui ConcreteUI auto 0

9.5.1

Automatic generated text elements

As the implementation in a graphical user interface often requires text to, for example, label form elements or to indicate sections, text elements are generated. These text elements however, contain values that are generated throughout the process which are not necessarily suitable for presenting information in a graphical manner, as described in Observation 3. In Figure 9.4, we illustrated the difference between the generated implementation (9.4a) and the desired implementation (9.4b).

(a) (b)

Figure 9.4: Screenshot of the generated implementation and the desired implements (without style)

It is obvious that the generated text elements in Figure 9.4b are not suitable. To solve this, an approach would be to define a model that maps the rele- vant text elements to a more appropriate value. This would form the input for the transformation from an abstract to a concrete user interface model. Since for each modality the communication and interaction with the user is different, this process is different for each modality. For example, in voice assistant user interface the concept of sections and form elements do not exist. Therefore, these text elements are transformed either to statements, in the case of separate sections, or to questions to indicate input elements. In addition, this approach would make it possible to support different val- ues for different languages. The approach does, however, involve manual intervention whereas our goal is to automate the process.

9.5.2

Manual intervention to include back button

In the workflow of creating a trade agreement, an option should be adopted that enables the user to return to the previous task. However, as the struc- tural model specification does not support the definition of such an op- tion, manual intervention is required to include this option in the dynamic specification. To avoid this additional step, a solution would be to anno- tate the task in the structural model that should include this option. The transformation should add aTriggerand anEventListenerobject that hides the current tasks and enables the previous task when the user triggers the trigger.