Performance assessment of an architecture with adaptative interfaces for people with special needs

Abstract

People in industrial societies carry more and more portable electronic devices (e.g., smartphone or console) with some kind of wireless connectivity support. Interaction with auto-discovered target devices present in the environment (e.g., the air conditioning of a hotel) is not so easy since devices may provide inaccessible user interfaces (e.g., in a foreign language that the user cannot understand). Scalability for multiple concurrent users and response times are still problems in this domain. In this paper, we assess an interoperable architecture, which enables interaction between people with some kind of special need and their environment. The assessment, based on performance patterns and antipatterns, tries to detect performance issues and also tries to enhance the architecture design for improving system performance. As a result of the assessment, the initial design changed substantially. We refactorized the design according to the Fast Path pattern and The Ramp antipattern. Moreover, resources were correctly allocated. Finally, the required response time was fulfilled in all system scenarios. For a specific scenario, response time was reduced from 60 seconds to less than 6 seconds.

Appendices

Appendix A: Design of the System

1.1 A.1 First Interaction Scenario

First Interaction, depicted in the UML sequence diagram (SD) in Fig. 19, consists in the creation of the INREDIS initial interface, which acts as the access medium to the environment for the user. It lists all the available devices and services along with their current state and related information; and allows the user to select which one she wants to interact with. Its creation involves two processes detailed in the following sections:

• The calculation of the INREDIS parameter for that concrete user (Perimeter Calculation).

• The generation of the initial interface in terms of this newly calculated perimeter (Initial Interface Generation).

Fig. 19

UML SD representing the user’s first interaction

1.1.1 A.1.1 Perimeter Calculation Process

The user perimeter represents the list of devices and services available to the user in a given moment. This kind of information is stored in the KB, but its calculation is made by the AMS. This module makes the necessary updates in the KB, keeping updated the situation of the user, the state of the surrounding devices, and the current state and information of the available services. Figure 20 shows the SD describing this process.

Fig. 20

UML SD showing the Perimeter Calculation process

This task involves the following steps: First it must update the current location of the user. It starts with the setAbsoluteLocation() method that updates the information about the user in the KB. After setting the current location of the user, the AMS updates the current status of each device in the user’s INREDIS perimeter. It first requests the list of device and services in the user’s perimeter (the KB getUserPerimeterServices() method) and for each of these devices:

• It requests to the Interoperability Gateway module the current state of each device (the getState() method). The Interoperability Gateway obtains this information no matter whether the device is exposed as a Web service or for UCH Target in a transparent fashion.

• It updates their current state on the KB accordingly (the KBsetState() method).

  A similar process is performed for the services in the user’s INREDIS parameter:

• It requests to the services in the perimeter information about their current state (the getServiceInfo() method).

• It updates the current state of the KB accordingly (the KB setState() method).

1.1.2 A.1.2 Initial Interface Generation Process

Once the system has ensured that the interaction is possible, the first interface is created, see Fig. 21.

Fig. 21

UML SD modelling the Initial Interface Generation

Before creating the initial interface the system has firstly to guarantee that the user is able to interact with its controller device. In consequence, it is necessary to determine the assistive technology that is necessary to enable such interaction. The ATS is the module responsible of such task; and also of determining how this software should be configured (method AskAT() ). Using the user URI (Uniform Resource Identifier) the ATS makes queries to the KB to obtain user’s profile, which is according to CAP (International Standard Organization 2009). With such profile, the ATS creates the list of the necessary assistive technology along with its configuration. The next step is the creation of the interface generator context where the variables are stored, such as the user URI, the controller device URI, navigation graph and its variables. Now the initial interface is created. As we have stated, in order to define interfaces we use a set of User Interface Markup Language UIML interfaces. The case of the initial interface is no exception, but instead of having a static UIML document, in the case of the first interaction the UIML interface definition is generated, a UIML document that contains all the available devices and services, allowing the user to choose among of them. The Generator module, the module that generates the UIML documents, delegates the creation of such interface to the Initial Creator module.

The Initial Creator creates what we refer as an abstract interface. It is a UIML document that still includes some context-dependent variables that have not been substituted, and a set of initialization rules that have not been performed. Such interfaces are made concrete by the Injector module (method concretizeInterfaze() ). This module executes the initialization rules and retrieves context related values from the IG context.

Once the UIML interface has been made concrete, it is time to determine the process that transforms this UIML document in to an accessible XHTML user interface. For that we use a collection of XSLT transformations that address different UIML components and users special needs, which after being applied to the UIML document translate it into an XHTML document tailored to user concrete needs. The Decisor module of the Interface Generator in charge of determining the set of transformations (chooseAdaptationTransformation() method). It does so by communicating with the KB (getTransformations() method) that given a user URI and the user’s controller URI determines which is the proper transformation to be applied. The selection of this transformation takes into account many orthogonal aspects, such as user’s special needs, preferences and the controller interaction capabilities, see (González-Cabero 2010).

Once the concrete UIML interface has been generated and the proper XSLT transformations have been selected, there are a set of parameters that are needed to tailor the transformations. We call them the adaptation parameters, and they include the final interface language and other lower-level implementation topics. They are determined in an analogous manner to what we did for selecting the XSLT transformation.

The Decisor module (chooseAdaptationParameters() method) gathers such information asking to the KB for information about the user, and it also takes into account information contained in the IG context. Once the IG posses all the necessary information (i.e. the initial interface as a concrete UIML interface, the set of transformations, and the adaptation parameters) it invokes the adaptInitialInterface() method of the Adaptor module. It returns the XHTML document that represents the initial user interface.

Finally, there may be some transformations that must be applied to the initial interface XHTML document that stem from the set of assistive software provided and configured by the ATS. They are applied by the Adaptor module (the applyATTransformation() method). After these transformations have been applied, the final version of the interface has been created and can be delivered to the user’s controller device.

1.2 A.2 Navigation Scenario

As we have already stated users interaction with a device often implies navigating through different atomic interfaces. Figure 22 shows the SD of the Navigation process.

Fig. 22

UML SD modelling a simple navigation

The interaction starts with the interface requesting a navigation to the Starting Point that acts as a gateway between the user interface and the system. The Interaction Enacter is the module that handles the navigation between interfaces. It is so because the Navigation activity is considered a subclass of the Device Interaction activity, as from a user perspective, the kind of buttons that perform device interaction activities are the same as those that allow the user navigate within the complex interface. In the request Interaction Enacter accesses to the navigation graph of the complex interface and determines which is the next interface that should be generated. This information is stored in the context of the IG. Finally, a new interface generation process starts. As the context of the IG has been updated with the next interface to be rendered, this is the one that is rendered.

1.2.1 A.2.1 Interface Generation Process

INREDIS devices UIML interfaces are composed of two types of documents:

• Views, a set of UIML documents that describe structure and its interaction elements of each atomic interface. As described in (Abrams et al. 1999), the use of UIML allows the abstract and platform-independent definition of user interfaces.

• Navigability graph, which defines the how and on what conditions the complex interfaces navigates throw the different views. Only one view at a time is shown, we refer to it as the current view.

Generating an interface for a user means to transform the current view of an interface into an accessible XHTML document taking into account the characteristics of the user and the needed assistive technology. Most part of the process is identical to the one defined for the first interaction. The difference is that this process does not adapt the initial interface, but it transforms the current view of the device interface that the user is using at present (which like in the case of the initial interface created by the Initial Creator is a abstract UIML interface).

The first part of the diagram (Fig. 23), the one related with the detection of accessibility gaps and the determination of the necessary assistive technology, is the same as the one defined for the first interaction with the INREDIS system. When the Generator module receives the petition of generating an interface by means of the generateInterface() module the first step is to determine which is the current view of the interface. This information is stored in the context of the IG (getCurrentView() method). The current view is a URL that points to the location of the abstract UIML document that should be used as the starting point of the final user interface. The Generator module invokes the retrieveXMLSource() method of the helper class Resource Manager, and retrieves an abstract UIML interface.

The rest of the steps of the generation of the interface are exactly as the ones described for the first interaction. Instead of using the abstract UIML interface created by the Initial Creator, they use the abstract UIML interface retrieved by the Resource Manager from the interface current view URL (Fig. 23).

Fig. 23

UML SD modelling the Interface Generation process

1.3 A.3 Device Interaction Scenario

The interactions with devices, and services are realized by the Interaction Enacter, see the SD in Fig. 24.

Fig. 24

UML SD representing a user’s device interaction

This module once initialized executes the action involved in the device/service interaction. In order to do so it invokes the executeAction() method of the Interoperability Gateway, which is a class that decouples the Interaction Enacter from the underneath technology used to interact with the device. The executeAction() method may result in:

• setValue() method invocation, in case that the device is exposed as a UCH target. The user interaction is translated into the change of one or more values of the UCH Target.

• invokeWS() method invocation, in case that the device is exposed as a Web service (or when there is no device and we are dealing with a Web service invocation)

The result is stored in the context of the IG, for later use in case of need. Once the interaction has been carried out, a new interface is generated (invoking the Orchestrator method getInteface() ). This new interface is generated to make sure that it reflects the changes and latest state after the interaction with the device.

1.4 A.4 Back to Top Scenario

This process, illustrated in the SD of Fig. 25, means going back to the device initial interface.

Fig. 25

UML SD representing the back-to-top process

As in the case of the navigation, the Interaction Enacter is the module that handles the back to top process. It is so because this activity is considered a subclass of the Device Interaction activity, as from a user perspective, the kind of buttons that perform device interaction activities are the same as those that allow going back to the device top interface. In order to keep all the information in the KB up-to-date we begin updating the location of the device and we recalculate the information about the user’s INREDIS perimeter .The next step is to generate top interface of the device, which is made using the Interface Generation process that we have already described in Section A.2.1.

1.5 A.5 Assistive Software Selection Mechanism

Assistive technology is the hardware or software that is added or incorporated within a system than increases accessibility for an individual, as defined in International Standard Organization (2011). Assistive Software (AS) is understood as a piece of software used to increase our ability to manage some kind of information in a digital device. The AS selection mechanism (ASSM) makes the environment able to automatically select the most suitable AS for a given interaction with a specific electronic target device taking advantage of the user’s context (user, controller device and target device) and considering the possible discrepancies between the user and the environment, namely in the case of functional diversity.

The ASSM uses different knowledge based on ontologies to achieve this goal, so this process consists of five main activities, one of them split into six, see the UML activity diagram in Fig. 26. The complete AS selection mechanism (ASSM) is described by Gómez-Martínez et al. (2013). The following is a summarized description of each activity.

Fig. 26

UML Activity Diagram of the AS selection process

Detecting discrepancies

The first activity detects any accessibility issues that might prevent the user from being able to use a controller. In order to detect discrepancies we use a set of specific rules stored in the KB that compare the characteristics of the interaction that the user is able to perform with those that the controller is able to emit/receive. The complete catalogue of rules is specified by González-Cabero (2010).

Checking feasibility

Each discrepancy found in the previous step, is analyzed to determine whether mediation by the AS can enable the interaction. The following activities are intended to ascertain which AS is most appropriate.

Matching by History log

When the user has already employed the system to interact with the same target using the same context, it is possible to retrieve the most suitable AS without further reasoning, just by querying the KB and retrieving the matching set from the AS History.

Matching by score

This activity triggers the reasoning process where four subsets of concepts are simultaneously queried in the KB using parallel activities. This activity is divided into the next activities:

• Retrieve Standard Fulfillment This activity performs an evaluation where the best scoring AS will be those that follow worldwide accessibility standards established by recognized accessibility entities.

• Retrieve Privacy This activity checks that the AS complies with the data protection measures issued by security bodies. It is important to note that, according to many laws in different countries, when an AS complies with a data protection act level, it also complies some data protection measures. This is taken into account here via rules to assert those facts in the KB. This is the case for e.g., Federal Data Protection and Information Commission of Switzerland or Ley Orgánica de Protección de Datos in Spain.

• Retrieve Ballot This activity increases the score for those AS with the best user reviews. These reviews are drawn from all the system’s users but they are not linked to any individual user, to maintain privacy about users’ functional diversity.

• Retrieve Deploy Method The scoring is the simplest, just to foster the use of AS deployed as SaaS (Software as a Service).

• Retrieve Setup Utilities This activity needs the output of Retrieve Deploy Method, so it is not executed in parallel with the others. All of the concepts are scored in this activity to take into account the ease of access and use of the AS.

• Weighted Matching This is the final activity of matching by score. It focuses on adapting the matching to the user’s preferences and the Domain Experts’ assumptions.

  The user has been previously asked to state its level of importance by means of the user profile stored in the KB. With the weighting system, all the roles involved in the selection are taken into account (i.e., domain experts, the user, and all system users at once using the reviews).

Sorting

This is the final activity of the whole process. This activity orders the set of AS products/services of the weighted matching activity in descending order.

B: GSPN Overview

A PN system is a tuple 𝒩 = (P, T, Pre, Post, M ₀ ), where P and T are the sets of places and transitions, Pre and Post are the ∣P∣ × ∣T∣ sized, natural valued, pre- and post- incidence matrices. For instance, Post [p, t] = w means that there is an arc from t to p with multiplicity w. When all weights are one, the PN is ordinary. Graphically, places and transitions are respectively represented by circles and bars, arcs are shown by arrows.

C = Post − Pre is the incidence matrix of the net. For pre- and postsets we use the conventional dot notation, e.g., ^∙ t = {p ∈ P: Pre [p,t] ≥ 1}, that can be extended to sets of nodes. If 𝒩′ is the subnet of 𝒩, defined by P′ ⊆ P and T′ ⊆ T, then Pre′ = Pre[P′, T′], Post′ = Post[P′, T′] and M′ ₀ = M ₀ [P′]. Subnets defined by a subset of places (transitions), with all their adjacent transitions (places), are called P- (T-) subnets.

A marking M is a ∣P∣ sized, natural valued, vector and M ₀ is the initial marking vector. A transition is enabled in M iff M ≥ Pre [P,t]; its firing, denoted by ${M}\stackrel {t}{\rightarrow } {M'}$, yields a new marking M′ = M + C[P, t]. The set of all reachable markings is denoted as RS (𝒩, M ₀ ). An occurrence sequence from M is a sequence of transitions σ = t ₁…t _k … such that ${M}\stackrel {t_{1}}{\rightarrow } {M_{1}}\dots {M_{k-1}}\stackrel {t_{k}}{\rightarrow }\dots$. Given σ such that ${M}\stackrel {\sigma }{\rightarrow } {M'}$, and denoting by σ the ∣T∣ sized firing count vector of σ, then M′ = M + C · σ is known as the state equation of 𝒩.

A GSPN is a tuple 𝒢 = (𝒩, Π, Λ, r), where 𝒩 is a PN system and the set of transitions T is partitioned in two subsets T _t and T _i of timed and immediate transitions, respectively. Timed transitions are depicted as thick white bars, immediate ones are depicted as thin black bars.

Π is a natural valued, ∣T∣ sized, vector that specifies a priority level of each transition; timed transitions have zero priority, immediate transitions have priority greater than zero. A transition t ∈ T, enabled in marking M, can fire if no transition t′ ∈ T : Π[t′] gt; Π[t] is enabled in M.

Immediate transitions fire in zero time. Instead, the firing of a timed transition is a random variable, distributed according to a negative exponential probability distribution function with rate parameter λ (i.e., mean $\frac {1}{\lambda }$). Then Λ is the non negative real valued, ∣T _t ∣ sized, vector associated to the transition firing rates (accordingly, the transition firing delay is the inverse of the corresponding firing rate). The positive real valued vector r is ∣T _i ∣ sized, and specifies the weights of the immediate transitions for probabilistic conflict resolution.

C: List of Performance Patterns and Antipatterns

Table 2 Performance patterns

Table 3 Performance antipatterns

D: GSPN Models of the System

Fig. 27

GSPN representing Navigation scenario

Fig. 28

GSPN representing Device Interaction scenario

Fig. 29

GSPN representing Back To Top scenario