UPi – A Unified Process for Designing Multiple UIs Kênia Soares Sousa, Elizabeth Furtado Universidade de Fortaleza [email protected], [email protected] Abstract This research work intends to present two workflows of a new Software Development Process (SDP) that integrates some Human-Computer Interaction (HCI) aspects along the software life cycle. Such HCI aspects include models used in the User Interface (UI) generation process. The purpose of this integration is to develop interactive systems that are easy to learn and use, therefore, helping users in performing their daily tasks in an efficient manner. Besides that, this integration intends to bring together researchers from the HCI and Software Engineering (SE) areas of study, which started to be a concern in the research community in the last years.

1. Introduction Nowadays, different manners to integrate aspects from the HCI and SE fields are found in SDPs. A software development organization can apply a SDP that only focuses on delivering software on the pre-defined cost and schedule, and that accommodates users’ expectations related to functionalities. On the other hand, a software development organization can choose to apply a SDP that focuses on the users’ characteristics, the tasks they perform, the work environment where they are located, and the devices they use to perform their tasks. On the first case, most activities performed during the software lifecycle are related to: scope and risk control; functionalities definition; components design, implementation, and integration; functionalities tests; change control; tools definition; and documentation development. On the second case, the focus is more closely related to human factors [20], usability [13], acceptability, accessibility, guidelines [16] and UI modeling. These aspects, when applied in a SDP, may bring benefits such as decrease in time to learn how to use the software, increase in the speed in performing tasks using the software, and increase in the user satisfaction towards the software.

This work is a continuous research on the integration of HCI and SE aspects and practices in an integrated SDP, called UPi (Unified Process for Interactive systems). This process is based on the worldwide renowned Rational Unified Process (RUP), which is the basis for the definition of this new SDP. Our intention is to associate both areas in the UPi in order to define the roles played by professionals from each field, which artifact each one is responsible for creating and using in a complementary and efficient manner, in which moment and how they work throughout the lifecycle, and how they communicate as part of the same team. We exposed our first ideas related to the addition of HCI aspects in only four RUP workflows in [21], which is the basis for the definition of this new SDP, and detailed and exemplified this work in [22]. We extended this work by applying HCI aspects in all of the RUP workflows in [23]. Then, we focused this integration on requirements engineering in [24]. Now, we focus on the requirements, and analysis and design workflows in order to identify requirements by attending users’ goals, considering their environmental and device restrictions, besides applying techniques that generate more usable UIs. Since most software development companies in the market-place do not even know HCI concepts, we intend to integrate HCI activities, workers, and artifacts with the existing ones in a SDP. Considering that the RUP is applied worldwide, we intend to provide those organizations a way to easily integrate HCI aspects with the SDP that they already apply in their software projects. In this paper, the second section presents the state of the art; the third section presents the requirements, and the analysis and design workflows in the UPi; the fourth section presents future work; and the last section concludes this work.

2. State of the Art In this section, we reflect about initiatives that integrate HCI and SE techniques while stablishing requirements, and introduce the related works.

2.1. Requirements Definition with HCI and SE Techniques Once requirements arise from data-gathering and interpretation activities, they need to be established from an understanding of the user’s needs (i.e. the reasons for doing a project). One user’s need can be related to one or more requirements, which is a statement about an intended product that specifies what it should do or how it should perform a task [17]. The functional requirements being established can be analyzed and documented using different techniques or artifacts. We analyze four of them, that are used to understand user’s goals and tasks and to design the UIs: scenarios, context of use, use case, and task analysis. A scenario is an informal narrative description [4], which describes the human activities being performed in an environment. It has two important advantages: it is easy for the stakeholders to write stories, and it allows developers and ergonomists to concentrate on understanding what people do and the contexts, irritations, facilitators and so on with which the humans operate. The context of use model defines aspects related to the system to be developed, which are: the platform, the environment, and users. This model associates the platform with an environment, anchoring the description to the physical world, besides taking into account the variations of the tasks in order to preserve usability [2]. This model reflects one way to represent textual scenarios in a defined manner, organized in three entities. A set of related scenarios allows identifying one use case, which represents a functionality that an interactive system has to perform in order to return one result to its actors (such as a user, or another interactive system). The Use Case Model represents a complete set of flow of events that can happen as a result of the user interaction with the system [8]. Essential use cases [5] are a textual structured and platform-independent definition of use cases, organized in user intentions, and system responsibilities. A task, in the user interfaces conception, specifies a set of activities the user and/or the interactive system does in order to achieve the user’s goals identified. In task models, it is possible to represent the task decomposition (that involves breaking a complex task down into subtasks, until the lowest level task), and the structural and temporal relations as an ordering between tasks. We agree that all of these sorts of techniques should be combined to help people to imagine what they could have in a system. This is due to the fact that some requirements are difficult to find or they are unconscious (for instance, people can be used to it or maybe they do not have a clue to see the overall picture). In addition to that, each technique is more appropriate to one kind of modelling

than to another. For instance, as scenarios are not intended to capture a full set of requirements since they are very personalized to specific kinds of users, it can be very helpful to define use cases to represent how users achieve their goals with the system functionalities. Since the context of use model is structured with three specific entities, it is a more organized manner than a free-textual representation as in scenarios. Although use cases are also focused on users’ goals, their emphasis is on a user-system interaction rather than the user’s task itself [17]. This happens because they contain certain assumptions about the UI and the kind of interaction to be designed, including the technology device the user interacts with. Essential use cases [5] try to avoid these assumptions, by defining only what the user role (not the actor) is responsible for (her/his intentions) and what the system should do. It is important to represent use cases more often as essential use cases, allowing the assumptions about the UI and the kind of interaction to be expressed in task models, which are more appropriate to model the user-system interaction from the user’s point of view.

2.2. Related Works In this section, we describe some initiatives that allow a reflection about the importance of using and integrating the artifacts mentioned previously in order to model system requirements and generate prototypes. Phillips [15] suggests the use of tabular representation of use cases in order to describe the flow of events, and the use of UI element clusters, which can be used as references to the UI prototype. Tabular use cases separate user and system actions. Lauesen [11] argues that separating users' and systems' actions as early as in requirements may be a barrier for future decisions in the project. Therefore, he suggests the use of task descriptions, which specify what the users and the system shall do, not dividing the work between them. On the other hand, Constantine & Lockwood [5] focuses on preparing task cases that address users' intentions rather than their actions and on system responsibilities rather than on responses. This approach offers a requirement modeling more technologyindependent, providing designers the flexibility related to the actual interface components when designing the UI, but maintaining conformity to users'needs. When the requirements are defined, users, clients, and designers define the UI abstract prototype (non-operational prototype) using post-it notes on a white board. After that, the interactive prototypes are built. Kruchten [10] presents the concern on UI design in the RUP by including the worker UI Designer, responsible for performing the activities UI Modeling and UI Prototyping in the Requirements Workflow. In the activity UI

Modeling, the UI Designer analyzes the use case model, and creates a use case storyboard. This artifact is composed of a textual description of the interaction between the user and the system, interaction diagrams, class diagrams, usability requirements, references to the UI prototype, and a trace dependency to the use case. In the activity UI Prototyping, the UI Designer designs and implements the UI prototype, then obtains feedback from other project members, external usability experts, and users. In our work, we generate prototypes from scenario, essential use case, and task modeling, which are used in a complementary manner.

3. UPi in UI Design In this research work, we present how the RUP suggests the performance of two workflows (Requirements, and Analysis and Design) [9], and we recommend the participation of HCI experts in those workflows. Each workflow is composed of workflow details, which have a set of activities to be performed by workers that produce valuable results, called artifacts.

3.1. The Requirements Workflow The RUP requirements workflow has the purpose of defining the system scope. The system scope needs to be based on the detection of problems in the target organization and on understanding users’ needs. Then, this scope needs to be managed, and refined in order to reflect users’ changing requests. This workflow is depicted in figure 1.

Figure 1: The RUP Requirements Workflow from [19] The UPi requirements workflow focuses on users’ needs, and proposes new techniques to establish requirements that are related to the production of artifacts that are valuable to the generation of usable systems. In summary, the context of use serves as a basis for the refinement of the system functionalities, represented as essential use cases, which in its turn, is detailed in a platform-dependent manner in the task model. For this reason, two workflow details in the RUP are refined. 3.1.1. Define the system. In this workflow detail, the system analyst is responsible for analyzing the stakeholders’ requests, and refining the use case model. In the UPi, we recommend the participation of the UI designer, the ergonomist, and users in this workflow detail in order to produce the context of use, the use case, and the task models (figure 2). Therefore, the system analyst provides the information that reflects stakeholder’s needs as a basis for the UI designer and the ergonomist to prepare those models that are useful throughout the development process, especially in the UI generation.

Figure 2: Activities in the Define the System Workflow Detail From the context of use model, it is possible to define the use case model because the latter provides information about the users’ activities in their working place, using specific devices, which might become constraints and functionalities of the system to be developed. Therefore, the context of use model is able to guarantee that the use case model represents users’ reality, in terms of what are their real needs towards the system, not what systems analysts think the system should do. We recommend that use cases are generated in two levels: abstract and concrete. Abstract use cases represent the system’s processes, while concrete use cases represent abstract ones according to the specific platform to be used. This way, a concrete UI can be referenced back to a concrete use case, thus, following the use-case oriented best practice [19]. Each concrete use case can be textually defined according to essential use cases [5]. We also recommend the preparation of the task model. In this work, we use the CTT notation [14], which has a graphical hierarchical structure of tasks and sub-tasks. The CTT is a flexible notation, it is able to represent concurrent and interactive activities, it supports cooperation among multiple users, and other characteristics which are provided in an intuitive way. The task model is generated based on concrete use cases, that is, each concrete use case adds information to the task model, since the use case model considers characteristics of different kinds of users, their environment, and different platforms, thus, enabling adaptation. The task model is useful to allow the system analyst to envision what tasks users perform, predict difficulties, evaluate systems, measure system complexity, and predict performance, among other aspects.

3.1.2. Refine the system definition. In this workflow detail, the requirements specifier is responsible for detailing software requirements, and documenting the results of this refinement in the software requirements specification and in the supplementary specifications documents. Since these requirements are focused on functionality, we enhance this workflow detail with activities that result in HCI artifacts. Therefore, the requirements specifier has its artifacts complemented with information generated by the UI designer and the ergonomist. In the UPi, we recommend the participation of the UI designer in this workflow detail in order to choose or specify new HCI patterns (figure 3) that address both UI development and usability requirements. The HCI patterns are defined with the following concepts: problem, context, forces, solution, comment, and tag (e.g. HTML tag for a visual element) [18]. The usability requirements are defined by users themselves and they are related to users’ satisfaction and to the system quality of use (e.g. easy access to shortcuts, number of data users need to remember, etc.). These requirements are associated to metric criteria used as a basis for the UI evaluation. Usability requirements are specific to each platform addressed in the system design. Later in the process, HCI patterns will be used to generate the concrete UI. Besides that, we also recommend the participation of the UI designer, and the ergonomist in order to define style guides for each platform (figure 3) based on the context of use model, and on users’ usability requirements. Style guides are important to provide consistency in the UI, increasing user productivity, decreasing number of errors, among other aspects related to usability.

Figure 3: Activities in the Refine the System Definition Workflow Detail

3.2. The Analysis and Design Workflow The RUP analysis and design workflow has the purpose of transforming requirements into a design specification useful for the implementation workflow. This workflow is depicted in figure 4, in which the software architect is responsible for defining, and refining the system architecture. The system architecture is based on components, which can be tested individually and integrated gradually to compose a complete system.

Figure 5: Activity in the Analyze Behavior Workflow Detail

Figure 4: The RUP Analysis and Design Workflow from [19] The UPi analysis and design workflow uses the models prepared in the requirements workflow in order to generate more usable UIs. With this goal in mind, two existing workflow details are improved:

3.2.1. Refine the Architecture. In this workflow detail, the software architect is responsible for defining the architecture by focusing on implementation and deployment. In the UPi, we recommend the participation of the UI designer in order to prepare the Abstract UI and the Concrete UI, as specified in the Unified Reference Framework [3] (figure 5 and 6). The Abstract UI represents the concepts from the class diagram and the functions from the task model, as elements, organized in workspaces. For instance, a task to add a user on a system with the name and password attributes are represented in a workspace with two data input elements and two actionactivators (confirm and cancel). The Concrete UI represents the Abstract UI with concrete elements, but it is not a Final UI. The example above, becomes concrete when the elements are visually represented with two input boxes, and two buttons. The Concrete UI is based on information from the context of use model, task model, class diagram, HCI patterns, and style guides, which are all mapped into the mapping model. The mapping model groups information from various models in order to promote the generation of concrete UIs for multiple devices. That is, the tasks to be performed by users, acting on specific data, situated on a specific environment, using specific devices directly influence the look-and-feel of the UI. Therefore, there is one Concrete UI for each platform addressed in the system design.

Figure 6: Activity in the Refine the Architecture Workflow Detail As a result of the participation of the software architect and the UI designer, we can design a well-structured system in terms of its functionality, and usability. 3.2.2. Design Components. In this workflow detail, the class characteristics and relationships are completely specified. In the UPi, we recommend the class model to be enhanced by being specified in a n-tier architecture (figure 7). In such a class model, the first layer represents the interface, the second one is the control layer, the third is the business logic layer, and the fourth one is the data layer. This approach allows the accordance to the separation of concern principle, which means modeling the system application independent from the system UI. The main goal is to facilitate changes in these layers. This way, a change in the UI will not affect the application, and vice-versa.

As for future work, we have three main intentions. First, we intend to define the UI models (which are: use case model, context of use model, task model, mapping model, class diagram, HCI patterns, abstract UI, and concrete UI) with ontology using the tool Protégé [6]. The ontology defines the concepts related to each UI model, specified in XML. For instance, name, type, frequency, and importance are examples of concepts for the task model. Second, we intend to develop a plug-in for Protégé in order to translate the models instantiated by designers into the concrete UI. We chose Protégé because it is an opensource tool, which easily accepts plug-ins developed in Java, and it interacts with XML, which is the standard format for the UI models. Third, we intend to use information from specific UI models as a basis for the definition of the JavaServer Faces (JSF) [1] configuration file, which holds information concerning the web system, such as, the actions performed in the system, the UI associated to those actions, the UIs associated to the results of those actions, the elements in those UIs, etc. JSF is a UI framework composed of an API for UI components and a JavaServer Pages (JSP) custom tag library for expressing UI components. This API represents UI components and manages their state; handles events, server-side validation, and data conversion; defines page navigation; supports internationalization and accessibility; and provides extensibility for all of these features. With this work, designers will be able to create the UI models using tools they are accustomed to (e.g. CTTE, Rose), and translate these models into XML using such tools, which serves as input to Protégé. Then, they will use Protégé to instantiate the other necessary models (e.g. context of use model, mapping model, HCI patterns, and abstract UI). As a result, designers will be prompted with the concrete UI and the configuration file necessary to start developing the classes for the system, according to the UI models.

5. Conclusion

Figure 7: Activity in the Design Components Workflow Detail

4. Future Works We are currently working on applying these UI models in the distance learning domain. We are creating the models with available tools, such as CTTE [12] for the task model, and Rational Rose for the use case model, and the class diagram. We are creating the other models, defined in XML, manually.

This research work presented two UPi workflows, the requirements, and analysis and design workflow, focusing on how to integrate HCI and SE workers, activities, and artifacts. The Requirements Workflow is enhanced by focusing on model-based UI generation, on achieving usability goals by defining HCI patterns and style guides. The Analysis and Design Workflow is enhanced by focusing on different kinds of users, their environments, platforms they use, tasks they perform, thus, generating context-sensitive UIs. The focus of HCI aspects in the UPi workflows brings benefits both to the HCI and SE experts. The first ones benefit from system functionality definition, leading to better precision useful for the UI definition. The latter

benefit from usability, acceptability, and accessibility aspects, leading into user satisfaction. We hope to develop interactive systems that are easy to learn and use, therefore, helping users in performing their daily tasks in an efficient manner.

6. References [1] Bergsten, H.: Associates, 2004.

JavaServer

Faces.

O´Reilly &

[2] Calvary, Gaelle; Coutaz, Joëlle; Thevenin, David. A Unified Reference Framework for the Development of Plastic User Interfaces. In: Proc. of EHCI 2001, Springer Verlag, 2001, pp. 173-192. [3] Calvary, Gaelle; Coutaz, Joëlle; Thevenin, David; Limbourgh, Quentin; Bouillon, Laurent; Vanderdonckt, Jean. A Unified Reference Framework for Multi-target User Interfaces. Interacting with Computers, Elsevier, Vol. 15, No. 3, June 2003, pp. 289-308. [4] Carroll, John. Introduction to the Special issue on “scenario-Based Systems Development”, Interacting with Computers, 13(1), 2000, pp. 41-42.

[12] Mori, G.; Paternò, F., Santoro, C. CTTE: Support for Developing and Analyzing Task Models for Interactive System Design. IEEE Transactions on Software Engineering, 2002, pp.797-813. [13] Nielsen, Jakob. Usability Engineering. California : Morgan Kaufmann, 1993. [14] Paternò, Fabio. Model-based Design and Evaluation of Interactive Applications. Springer-Verlag, Berlin, November 1999. [15] Phillips, Chris; Kemp, Elizabeth. In Support of User Interface Design in the Rational Unified Process. In: Proceedings of the Third Australasian User Interface Conference, 2002, pp. 21-27. [16] Preece, Jenny et al. Human-Computer Interaction. England: Addison-Wesley, 1994. [17] Preece, Jenny; Rogers, Yvonne; Sharp, Helen. Interaction Design - Beyond Human-Computer Interaction. John Wiley & Sons, 2002.

[5] Constantine, Larry; Lockwood, Lucy. Software for Use: A Practical Guide to Models and Methods of usageCentered Design. Massachusetts: Addison-Wesley, 1999.

[18] Pribeanu, Costin; Vanderdonckt, Jean. A PatternBased Approach to User Interface Development. In: Proc. Of 9th Conf. On Human-Computer Interaction HCI International’ 2003, Vol. 4, Lawrence Erlbaum Associates, 2003, pp. 1524-1528.

[6] Gennari, J.; Musen, M. A.; Fergerson, R. W.; Grosso, W. E.; Crubézy, M.; Eriksson, H.; Noy, N. F.; Tu, S. W. The Evolution of Protégé: An Environment for Knowledge-Based Systems Development. 2002.

[19] RUP. (2003), The Rational Unified Process. Available in: . Accessed in 07 mar. 2004.

[7] Husted, Ted et at. Struts in Action. Connecticut: Manning, 2003.

[20] Shneiderman, Ben. Designing the User Interface: Strategies for Effective Human-Computer Interaction. 3 ed. England: Addison-Wesley, 1998.

[8] Jacobson, I.; M. Christersson, P.; Jonsson; G. Overgaard. Object-Oriented Software Engineering: A Use Case Driven Approach. Massachusetts: Addison-Wesley, 1992. [9] Kruchten, Philippe. The Rational Unified Process - An Introduction. 2 ed. New Jersey: Addison-Wesley, 2000. [10] Kruchten, Philippe; Ahlqvist, S; Bylund S. User Interface Design in the Rational Unified Process, in Object Modeling and User Interface Design. Massachusetts: Addison-Wesley, 2001. [11] Lauesen, Soren. Task & Support - Task Descriptions as Functional Requirements. In: Proceedings of AWRE, 2001, pp. 83-91.

[21] Sousa, Kenia; Furtado, Elizabeth. Integration of Human-Computer Interaction in a Software Development Process. In: Human-Computer Interaction International – HCII’2003, Greece, 2003a. [22] Sousa, Kenia; Furtado, Elizabeth. RUPi – A Unified Process that Integrates Human-Computer Interaction and Software Engineering. In: Bridging the Gaps Between Software Engineering and Human-Computer Interaction – ICSE’2003 Workshop, USA, 2003b pp. 41-48. [23] Sousa, Kenia; Furtado, Elizabeth. A Unified Process for Interactive Systems. In: Integrating Human-Computer Interaction and Software Engineering Models and Processes – CLIHC’ 2003 Workshop, Brasil, 2003c.

[24] Sousa, Kenia; Furtado, Elizabeth. An Approach to Integrate HCI and SE in Requirements Engineering. In: Closing the Gaps: Software Engineering and HumanComputer Interaction - INTERACT’ 2003 Workshop, 2003d, Switzerland, pp. 81-88.