Towards a UML profile for interaction design: the Wisdom approach

Towards a UML profile for interaction design: the Wisdom approach Nuno Jardim Nunes1 , João Falcão e Cunha 2 1

Universidade da Madeira, Unidade de Ciências da Computação, Dep. de Matemática, 9000-390 Funchal, Portugal [email protected] 2 Universidade do Porto, GEIN, Faculdade de Engenharia, 4099 Porto CODEX, Portugal [email protected]

A b s t r a c t . The UML is recognized to be the dominant diagrammatic modeling language in the software industry. However, it’s support for building interactive systems is still acknowledged to be insufficient. There is a common misconception that the same models developed to support the design of the application internals are also adequate to support interaction design, leveraging the usability aspects of the applications. In this paper we identify and discuss the major problems using the UML to document, specify and design interactive systems. Here we propose a UML profile for interactive systems development that leverages on human-computer interaction domain knowledge under the common notation and semantics of the UML. Our proposal integrates with existing object-oriented software engineering best practice, fostering co-evolutionary development of interactive systems and enabling artifact change between software engineering and human-computer interaction.

1 Introduction Building interactive systems that are efficient and reliable in use, easy to learn and remember, and that provide user satisfaction is one of the greatest challenges of the software industry. Such requirements are increasing with the widespread use of the Internet, the advent of the information appliances and agent-based systems. In fact the Internet changed the importance of usability because the user interface is increasingly becoming the customer-interface, hence, a business critical factor. The Unified Modeling Language (UML) has found widespread use in many different application domains and is increasingly becoming the de facto standard language for object-oriented analysis and design. However, UML support for interactive system development is recognized to be insufficient. Although it is acknowledged that in interactive applications about 50% of the code is devoted to the user interface the UML and related methods and tools still focus more the application internals and less the usability aspects [1]. Moreover there is a com-

mon misconception that the same models developed to support the design of the application internals are adequate to support user interface development. In order to adequately support interactive system development we need to leverage on human-computer interaction (HCI) domain knowledge. Model based notations and formalism proliferate in the HCI field; however, they lack a common language that enables co-evolutionary development and artifact change with the software-engineering field. The same argument that led to the adoption of the UML, by the software engineering (SE) community, applies in bridging the gap between HCI and SE. The UML provides a common language for specifying, visualizing and documenting software intensive systems and enables tool interoperability at the semantic level, all of these issues are of ultimate importance for interactive system development [1]. HCI methods and techniques usually require modeling constructs to: _ describe users and their relevant characteristics; _ describe user behavior while performing the envisioned or supported tasks; _ specify abstract (conceptual) and concrete (physical) user interfaces. The adoption of use-cases in the UML acknowledges the importance of identifying the different roles users play when interacting with an application to support their tasks. However they are still mainly used to structure the application internals and don’t provide an efficient way to support the usability aspects of the interactive system. Essential use-cases [2] identified some of the requirements for user interface development enabling the connection between the structure of use and the structure of the user interface. An essential use-case is “a simplified, abstract, generalized use-case defined in terms of user intentions and system responsibilities” [3], it contrasts Jacobson’s original definition of a concrete use-case “a class describing the common pattern of interaction of a set of scenarios” [4]. Essential use-cases define user role maps, a set of relationships between actors (affinity, classification and composition) that reveal how the different roles in a system fit together defining who will use the system and how [3]. Other approaches, used in goal-driven interaction design, rely on archetypal descriptions of users. In one of those proposals [5] the author defines a persona, a hypothetical archetype of a user defined with precision and detail. The author claims that instead of designing for a broad audience of users, interaction designers should design for a small set of archetypal users – the cast of characters [5]. The requirements in such proposals are substantially different from the common interpretation of usecases in OO analysis and design – they recognize the peculiarities of interaction design and they focus on users’ goals and the structure of use. A proposal for structuring usecases with goals [6] already recognizes some of the above problems distinguishing goals as a key element of use-cases. The descriptions of user behavior are intimately associated with the technique (and underlying concepts) used to abstract the end-users. In the UML, and related methods, descriptions of user behavior are usually captured detailing use-cases with scenarios, activity diagrams or interaction diagrams. From an HCI perspective the descriptions of user behavior usually encompass a task model, which, at least to some degree, can be achieved with the mentioned UML diagrams – in [1] and [7] two UML extensions are proposed to accommodate task analysis. However the major problem with descriptions of user behavior are related to the system-centric nature of use-cases. In [3] the authors

argue that “conventional use-cases typically contain too many built-in assumptions, often hidden and implicit, about the form of the user interface that is yet to be designed.” Such argument led the authors to propose the essential use-case narrative, a technology-free, implementation independent, structured scenario expressed in the language of the application domain and end-users. The essential quality (technology free and implementation independent) of descriptions of user behavior can also be applied to diagrammatic representations, in [8] we propose to detail use-cases with activity diagrams following the same principle. Goal-driven interaction design also relies on descriptions of user behavior structured in terms of users’ goals, for instance in [5], the author proposes to drive design in terms of personal, corporate and practical goals. The above discussion concerns early models of interest to interactive system development, in particular models of user roles and models describing user behavior. The ideas described here are of ultimate importance to support interaction design and interactive system development. They should, in our opinion, be considered in further UML revisions and extension profiles. Although use-cases have proved to be an effective tool to structure application internals, alternate interpretations should be clearly defined and put into context to avoid misused in interactive system design. Experience reports on the mentioned approaches show benefit gains in terms of reduced complexity and cost of producing and maintaining the systems; enhanced user satisfaction and productivity; and even improvements in project management and resource allocation. In this paper we focus on the analysis and design models of interactive systems, the models required to specify conceptual and concrete models of user interfaces. While the requirement model concerns an external view of the system described in the language of the users/customer, the analysis model concerns an internal view of the system described in the language of the developers [9]. In analysis the focus is to build a sound architecture that outlines how to realize the functionality captured in the different use-cases. In section 2 we discuss the analysis framework of the UML profile for software development processes and present a new proposal specifically adapted to develop interactive systems. Also in section 2 we present the design level models of our approach and how they complement the standard UML profile design model in order to foster the physical realization of the use-cases in interactive applications. Section 3 outlines the semantics of the UML extensions. In section 4 we present a worked example of our approach and, finally, in section 5 the conclusions and further developments.

2

Analysis and Design Level Models in Interactive System Development

The third type of descriptions of interest to HCI mentioned in the previous section are conceptual and physical models of the user interface. A conceptual model of the user interface is a model used by interaction designers to anticipate the user’s mental model of the envisioned system. Conceptual models are important since they enable designers to ensure that the system under development will ultimately meet the expectations

of the end-users, i.e., the usability requirements that define the quality of the user interface. Usually, conceptual models encompass the things (entities) the users manipulate to perform the tasks, hence, they can be conceived as refinements of domain models. However, the intents that drive such refinement are distinct for the purpose of the application internals and interaction. A good user interface, amongst other factors, should match as much as possible the user’s conceptual model and not the internal application implementation model. Conversely, a physical or concrete model of a user interface is a specific representation of the user interface designed to accommodate the tasks the users must perform. A physical model of the user interface is sometimes called a designer’s model and should also match the user’s conceptual model of the system. However, physical models include additional information required to design and implement the user interface, not present in conceptual models. For instance, an abstract physical model considers the task decomposition and the interaction spaces required, while a concrete physical model also takes into consideration the interaction styles and the user interface technology available. In the following sections we discuss the relationship between the analysis and design models in the UML standard profile for software development processes and the corresponding descriptions necessary to support conceptual and physical models of the user interface. 2.1. The analysis framework of the UML profile for development processes and interactive systems The UML profile for software development processes [10] defines an analysis framework that divides the analysis classes in three stereotypes. This partitioning, originally from the OOSE method [4], encompasses three dimensions: _ The information dimension ( stereotype) specifies the information held in the system in both short and long term – the state of the system; _ The behavior dimension ( stereotype) specifies the behavior the system will adopt – when and how the system changes state; _ The interface dimension ( stereotype) specifies the details for presenting the system to the outside world. The reason behind this partitioning of analysis classes into information, behavior and interface is to promote a structure more adaptable to changes. Assuming that all systems change, stability will occur in the sense that changes affect (preferably) only one object in the system, i.e., they are local [4]. Therefore, the UML analysis framework aims at concentrating changes to the interface and related functionality in boundary objects; changes to (passive) information and related functionality in entity objects; and changes to complex functionality (e.g., involving multiple objects) in control objects. This approach is conceptually similar, although at a different granularity level, to conceptual architectural models for interactive system’s, for instance, PAC [11] and MVC [12]. In fact, the PAC distinction between presentation, abstraction (application) and control relate, conceptually, to the boundary, entity and control class stereo-

types. However, such similarities are misleading in the sense that they do not comply with some of the requirements defined in interactive system architectures. The major issue in conceptual and implementation architectures for interactive systems is the separation of concerns between the semantics of the application functional core and the user interface provided to the user. Such separation of concerns fosters portability, reusability, multiple interfaces and customization. The logical components of an interactive system architecture were originally identified in the Seeheim workshop [13] and later revised in the Arch workshop [14]. The initial three component proposal of the Seehim model encompassed the presentation, dialogue control and application interface components – a division that also closely maps the MVC and PAC models. The Arch model expanded this proposal on a five component model balanced around the dialogue component. The components of this model are: _ The interaction toolkit component - implements the physical interaction with the end-user; _ The presentation component - provides a set of toolkit independent objects; _ The dialogue component – responsible for task-level sequencing, providing multiple interaction space consistency, and mapping the between domain specific and user interface specific formalisms; _ The domain adapter component - implements domain related tasks required but not available in the domain specific component; _ The domain specific component - controls, manipulates and retrieves domain data and performs other domain-related functions. The Arch model provides developers with guidance to tackle the difficult engineering compromises that affect the development process of interactive systems and the quality of the end product. On the one hand, the user and the functional core play a symmetric role driving the dialogue component, hence, at high levels of abstraction there is no a priori imposition on the control of the interaction. On the other hand, both the domain adapter and interaction toolkit components serve as buffers for the functional core and the user, therefore, isolating and absorbing the effects of change in its direct neighbors [15]. 2.2

The analysis framework for interactive systems

In [16] we present a proposal for an UML based analysis architecture for interactive systems (depict in Fig. 1). This new proposal builds on UML’s analysis framework but introduces two additional dimensions: the presentation and dialogue dimensions. The new dimensions accomplish two goals, on the one hand, the presentation dimension detaches the human-interface from the existing interface dimension, on the other hand, the dialogue dimension regulates task-level sequencing while providing multiple interaction space consistency and mapping between domain specific and user interface specific formalisms. In addition, the information dimension is shared among both the user interface specific dimensions and the internal application dimensions, postponing domain adaptation to other models at lower levels of abstraction.

Behaviour

Information

Interface (non-human) Analysis model

Dialogue

Information

Presentation Interaction model

F i g . 1 . The revised analysis framework for interactive systems

The proposal for the UML analysis framework for interactive systems includes a new UML interaction model to accommodate the two new dimensions, plus the shared information dimension. Therefore, the interaction model encompasses the information, dialogue and presentation dimensions, clearly mapping the conceptual architectural models for interactive systems, while maintaining the desired separation of concerns. Accordingly, the analysis model accommodates the UML profile architecture dimensions, also including the shared information dimension. Note that the presentation dimension in the UML analysis framework is reduced to capture the interface (not the presentation) to external systems. The new interaction model defines the user interface architecture, like the analysis model defines the internal system architecture. Here we consider that an architecture for interactive systems involves the description of the elements from which those systems are built, the overall structure and organizations of the user interface, patterns that guide their composition and how they are connected in order to support the interactions with the users in their tasks [16]. In the following sections we describe the design models necessary to realize the user-interface architecture. For further details regarding the proposal for this architectural model refer to [8]. 2.3

The dialogue design level model

The interaction model suffers further refinement on two design level models: the dialogue model refines the dialogue dimension and the presentation model refines the presentation dimension. The dialogue model specifies the dialogue structure of the application using an UML based adaptation of the ConcurTaskTrees visual task formalism [17]. According to the author, the main purpose of ConcurTaskTrees is to support the specification of flexible and expressive task models that can be easily interpreted even by people without formal background. ConcurTaskTree is an expressive, compact, understandable and flexible notation representing concurrent and interactive activities by task decomposition and supporting cooperation between multiple users. ConcurTaskTrees defines three types of task allocations: _ user tasks (tasks performed by the user); _ application tasks (tasks completely executed by the application); _ interaction tasks (tasks performed by the user interacting with the system);

_ abstract tasks (tasks which require complex activities whose performance cannot be univocally allocated). An important feature of the ConcurTaskTrees notation, essential to bring detail in the dialogue model, is the ability to express temporal relationships between tasks. In our adaptation of the formalism we use the UML constraint extension mechanism to express such temporal relationships between tasks. A constraint is a semantic relationship among model elements that specifies conditions and propositions that must be maintained as true [10]. The temporal relationships in ConcurTaskTrees adapted in our approach are depict in Fig. 2 and described bellow (including the original notation from [17] in parenthesis next to their name): _ Independent concurrency (T1|||T2) – denotes that actions belonging to two tasks (T1 and T2) can be performed in any order without any specific constraint; _ Choice (T1[]T2) – denotes that it is possible to choose form a set of tasks and once the choice has been made the chosen task can be performed, while other tasks are not available; _ Concurrency with Information Exchange (T1|[]|T2) – same has independent concurrency but the tasks have to synchronize in order to exchange information; _ Deactivation (T1[>T2) – denotes that the first task (T1) is definitely deactivated once the second task (T2) terminates; _ Enabling (T1>>T2) – denotes that the second task (T2) is activated once the first task (T1) terminates; _ Iteration (T*) – denotes the task (T) is performed repeatedly until the task is deactivated by another task; _ Finite Iteration(s) (T1(n)) – same as iteration but the task (T) is performed n times; _ Optional Tasks ([T]) – denotes that the performance of a task is optional. Independent concurrency T1 ||| T2

Choice T1 [] T2

T

Concurrency with information exchange T1 |[]| T2

Iteration T1*

T

T T

{xor}

*

T1

T2

T1

T2

T1 T1

Enabling T1 >> T2

Enabling with information passing T1 []>> T2

Finite Iteration T1(n)

Deactivation T1[>T2

T

T T

{sequence}

{deactive}

{sequence}

T1

T2

T2

T1 T1

T2

Optional Tasks [T1]

T

T

1..n

0..1

T1

T1

T2

F i g . 2 – UML adaptation of ConcurTasktrees. Note that the icon circle with a sticky man and a stylized computer inside denote a UML stereotype . Also, all the associations between classes are stereotyped associations. Finally {xor}, {sequence} and {deactivate} are UML constraints (refer to section 3 for definitions). For a complete reference of ConcurTaskTree involving all the possible uses of such formalism, specifically for evaluation and pattern expression, refer to [17].

2.3

The presentation design level model

The other design level model defined in our approach is the presentation model. Recently several authors proposed the idea of using object models to specify presentational aspects of interactive applications. In the Ovid method Roberts and colleagues proposed the concept of an (object) view – the modeling concept responsible for presenting to the users and allowing them to use information to accomplish tasks [18]. However the initial proposal of Ovid relies on UML annotations to express relevant information of views and, hence, have little semantic significance. Ovid organizes views in designers and implementation models through class, sequence and statechart diagrams. This model organization maps the well-known HCI distinction between the different conceptual models of users, designers and implementation – the aim is to bring the implementation model as close to the user’s model as possible, hence, preventing the user interface from reflecting the internal system architecture. A similar concept is also proposed in usage-centered design (UCD), the authors of essential use-cases propose interaction contexts as the main building block of the presentation aspects of the user interface. An interaction context represents the places within the user interface of a system where the user interacts with all the functions, containers and information needed for carrying out some particular tasks or set of interrelated tasks [3]. However the authors don’t provide any information regarding the definition of interaction contexts in the UML framework. Contrasting Ovid, UCD emphasizes the navigational structure of the user interface architecture. Interaction contexts are organized in navigation maps and relationships between interaction contexts are defined (context changes). This characteristic enhances the capability of reasoning about the navigational structure of the interactive application, supporting one of the important compromises in interaction design – the balance between the number of interaction contexts and the number of context transitions. Both Ovid and UCD classify the presentation objects in terms of generic graphical interaction elements, e.g., contents, composed, properties and user assistance in Ovid; and window, screen, display, message and panel in UCD. This classification scheme imposes a dependency on the user interface technology - the WIMP graphical user interface – which restricts the ability of the modeling concepts to serve multiple interaction styles and interface technologies. In our approach the presentation model defines the physical realization of the perceivable part of the interactive system (the presentation), focusing on how the different presentation entities are structured to realize the physical interaction with the user. The presentation model provides a set of implementation independent modeling constructs (the class stereotype1) for use by the dialogue model, hence, leveraging independence of the interaction techniques provided by the user interface technology (e.g. UI toolkit). Interaction spaces are responsible for receiving and pre1

In previous versions of the Wisdom method the concept described here as an interaction space was named view. The change is related with: (i) the belief that interaction space reflected more the notion of a human user interacting with a computer system (as opposed with a more passive notion in view); and (ii) the existence of an equally named stereotype () in the data modeling profile very common in industry modeling tools.

senting information to the users supporting their task. Interaction spaces are typically organized in hierarchies and containment relationships can occur between interaction spaces. In the next section we present the UML’s extensions to support the presentation model.

3 The UML profile for interactive system development In the previous sections we presented and discussed different approaches and contributions to define adequate interactive system architectures. We also discussed the analysis framework of the standard UML profile for software development, argued about its system-centric nature and proposed some modeling concepts to overcome this nature while staying within the UML and related SE methods. In this section we present a minimal set of extensions to the UML to support the concepts introduced in the previous section. We call this extension set the Wisdom UML profile because it was originally developed to support the Wisdom software development method [19]. Wisdom is a UML based method specifically adapted to develop interactive system by small software developing companies. In this paper we intentionally detached the extension profile from its methodological background because it is our belief that the Wisdom extensions are broadly applicable in different process contexts. 3.1

Revised stereotypes for the analysis model

As we mentioned in the previous section the new analysis framework for interactive system development expands the UML standard profile framework, while introducing some subtle but important changes in the conceptual definitions of the class stereotypes. For that purpose we present the modified definitions of the Wisdom profile (where required partial definitions are retrieved from [10] and [9]): _ class stereotype – the boundary class is used, in the analysis framework for interactive systems, to model the interaction between the system and external systems (non-human). The interaction involves receiving (not presenting) information to and from external systems. Boundary classes clarify and isolate requirements in the system’s boundaries, thus isolating change in the communication interface (not human-interface). Boundary classes often represent external systems, for example, communication interfaces, sensors, actuators, printer interfaces, APIs, etc. _ class stereotype – the control class represents coordination, sequencing, transactions and control of other objects. Control classes often encapsulate complex derivations and calculations (such as business logic) that cannot be related to specific entity classes. Thereby, control classes isolate changes to control, sequencing, transactions and business logic that involves several other objects. _ class stereotype – the entity class is used to model perdurable information (often persistent). Entity classes structure domain (or business) classes and associate behavior, often, representing a logical data structure. As a result, entity

classes reflect the information in a way that benefits developers when designing and implementing the system (including support for persistence). Entity objects isolate changes to the information they represent. 3.2

Stereotypes for the interaction model

The elements of the interaction model are interaction classes, defined as stereotypes of UML class constructs. The three stereotypes proposed in the analysis framework for interactive systems are: _ class stereotype – task classes are used to model the structure of the dialogue between the user and the system. Task classes are responsible for task level sequencing, multiple interaction space consistency and mapping back and forth between entities and interaction space classes. Task classes often encapsulate complex behavior that cannot be related to specific entity classes. Thereby, task classes isolate changes in the dialogue structure of the user interface _ class stereotype – the interaction space class is used to model interaction between the system and the human actors. An interaction space class represents the space within the user interface of a system where the user interacts with all the functions, containers, and information needed for carrying out some particular task or set of interrelated tasks [3]. Interaction space classes are responsible for the physical interaction with the user, including a set of interaction techniques that define the image of the system (output) and the handling of events produced by the user (input). Interaction space classes isolate change in the user interface of the system, they are technology independent although they often represent abstraction of windows, forms, panes, etc. The UML profile for software development processes also defines association stereotypes. Although, the UML profile for interactive systems doesn’t change the semantics of those association stereotypes, they can be applied to the new class stereotypes introduced before: _ is an association between actors and use cases denoting that the actor sends messages to the use case or the use case sends messages to the actor. It can also be used between boundary, control and entity. In addition it can be used between actor and boundary, with the new specific constraint that actor is an external system. Communicate can also be used between entity, task and interaction space. In addition it can be used between actor and interaction space, with the specific constraint that actor is human. The direction of communication can be one way or two ways; _ is an association between two class states that objects of the source class (subscriber) will be notified when a particular event occurs in objects of the target class (publisher). Subscribe can be used from boundary, entity and control to entity. In addition, subscribe can also be used between task and entity. The direction of subscribe is one way.

3.3

Additional Stereotypes for the dialogue model

_ is an association between two tasks denoting that the target class (subtask) specifies the source task (parent task) at a different (lower) level of detail. The refine task association is unidirectional can only be used between task classes. Constraints for the Refine task association (assuming all objects or classes maintain their own thread of control, i.e., they are active and run concurrently with other active objects): _ {xor} – is the UML standard constraint and applies to a set of associations, specifying that over that set, exactly one is manifest for each associated instance; _ {sequence} - is applied to a set of associations, specifying that over that set, associated instances become active in sequential order, i.e., one associated instance activates the other when it becomes inactive; _ {deactivate} - is applied to two associations, specifying that one associated instance explicitly deactivates the other when it becomes active. For the purpose of task allocation the following tagged values apply to the task classes: _ {abstract task} – tasks which require complex activities and whose performance cannot be univocally allocated; _ {user task} - tasks performed by the user with no interaction with the system. For instance, thinking about which option to choose; _ {application task} - tasks completely executed by the application; _ {interaction task} - tasks performed by the user interacting with the system; 3.4

Additional Stereotypes for the presentation model

_ is an association stereotype between two interaction space classes denoting a user moving from one interaction space to another. The navigate association can be unidirectional or bi-directional, the later usually meaning there is an implied return in the navigation. Users navigate in interaction spaces while performing complex tasks and a change between interaction spaces usually requires a switch of thinking from the user; _ is an association stereotype between two interaction space classes denoting that the source class (container) contains the target class (content). The contains association can only be used between interaction space classes and is unidirectional. _ – is an attribute stereotype denoting information received from the user, i.e., information the user can manipulate; _ – is an attribute stereotype denoting information presented to the user, i.e., information the user can perceive but not manipulate; _ – is an operation stereotype denoting something a user can do in the physical user interface that causes a significant change in the internal state of the system, i.e., changes in the long term information of the system (entities), request for signification functionality, changes in context of the user interface, etc.

3.5

Valid Association Stereotypes combinations

To: From: Actor Boundary Control

Actor

Boundary

Control

Entity

communicate

communicate

communicate

communicate

communicate subscribe communicate subscribe communicate subscribe communicate subscribe

communicate communicate

Interaction space communicate

Entity Task

Task

communicate

Interaction space F i g . 3 – Valid association stereotypes combinations

communicate

communicate refine communicate

navigate contain

5 The Wisdom approach in practice: a worked example We’ve applied our approach in different development contexts and projects, of variable size and complexity. For the purpose of illustrating the notation presented in this paper, we present, throughout this section, several artifacts from a well-known example of a simple hotel reservation system (refer to [18] for other worked examples of the same problem). The “toy examples” bellow are not intended to demonstrated the applicability of the approach in a real-world scenario, that is the aim of a case-study and is out of the scope of this paper. To the left-hand side of Fig. 4 we show a possible use-case structure for the above problem statement. The use-case model is depict to illustrate how different interaction and analysis classes collaborate in their realization. For example, the customer browser class, the identify customer task and the customer entity all collaborate in the realization of the three use-cases depict in Fig. 4. In the middle left-hand side of the illustration are interaction model classes (interaction space and task classes). The task classes accommodate the dialogue of the interactive system, hence, for example, check availability and identify customer are high-level tasks belonging to the dialogue structure of this particular architecture. Task objects also guarantee consistency between interaction spaces, one example of such responsibility is visible between the confirm reservation task class, the customer browser and customer reservations. To the middle right-hand side of Fig. 4 is the internal analysis model. In this example there are no boundary objects to interface external systems. Finally rightmost in the figure we present a hypothetical traditional solution (i.e., following the boundary/control/entity division). This “traditional” solution was adapted from other examples in the literature (e.g., [4], [9] or [20]). It is not our remit here to build a thorough discussion of both alternatives, but we can easily observe that in traditional approaches typically: _ boundary classes tend to follow the same functional decomposition of use-cases, i.e., there is usually a 1-to-1 mapping between use-cases and boundary classes. Such decomposition is less adaptable to change, compromises the reuse potential

of the UI compromising the consistency and coherency of the UI (a major usability factor); _ boundary classes presuppose a user-interface technology or style (window, screen, etc.). Although we can argue that this is not explicitly a notational problem, we believe it is closely related to the lack of lower level extensions supporting the reification of the presentation aspects of the UI; _ logic related to the UI usually goes into control or boundary classes. Again this is a problem of ineffective support for the required separation of concerns for interactive applications. The result is a structure less adaptable to changes, reuse, and even existing n-tier physical architectures. For instance, we have successfully exploited mappings of our approach to n-tier architectures promoted in the UML profiles for web applications [20]; Use Case Model

Interaction Model

Hotel availability browser

Make Reservation

Analysis Model

Check availability

Room

Identify Customer

Customer

Confirm reservation

Reservation

Traditional Solutions

Availability

Check In UI/Screen/Window

Reservation Handler

Check Out UI/Screen/Window

Customer browser

Check in Clerk

Customer reservations Period

Room browser

Assign Room

Room Payment

Check out Bill

Bill customer

Make Reservation UI/Screen/Window

Bill

F i g . 4 . Example of a use-case model, an user interface architecture, an internal architecture and a “traditional” solution for a simple Hotel Reservation System.

The following two artifacts (Fig. 5 and 6) depict the reification of parts of the architecture in Fig. 4. The artifacts, shown bellow, typically belong to design level models, in this particular case part of the task model (Fig. 5) and part of the presentation model (Fig. 6).

Check availability {sequence} {sequence}

Define period

{deactive}

*

Select room type

Show & refine availability

Close availability

{xor} {sequence}

Enter start & end date

{sequence}

Enter start date perform query show availability & duration {application task} {application task}

refine availability {deactive}

Edit period Edit room type

Submit

F i g . 5 . Example of a task model for the check availability top-level task. Note that in this diagram the stereotype uses a special icon as an alternate representation. This icon enables further usage for task allocation, i.e., removing alternately the sticky man and the stylized computer we can define stereotypes for task allocation to user tasks and application tasks. Also the associations in this example omit the stereotype reference for clarity, obviously all associations are stereotypes. Hotel availability browser



Customer browser

check availability close Bill



Period Room type Availability results start date room type end date room type duration period quantity price

Room view

Customer Reservations

F i g . 6 . Example of a presentation model for the hotel availability browser. Note that in this diagram the stereotype uses a special icon as an alternate representation.

5 Conclusions In this paper we discussed the major problems using the UML for interactive system development and present several contributions that enable adequate development of user interfaces. Our proposal leverages on HCI domain knowledge, while staying within the UML framework, fostering co-evolutionary development of interactive systems, enabling artifact change between HCI and SE and providing the basis for tool support and interoperability. The proposed interactive system analysis framework supports both the internal system architecture and the interactive architecture required to build good user interfaces that foster reuse, portability, multiple user interfaces and customization. The dialogue and presentation design level models support model based development of user interfaces using a set of UML notational extensions based on a experimented software engineering method – the Wisdom method. The extensions described here are also effective for expressing task and interaction patterns. Our experience using and evolving these notational extensions shows that they can be actually applied in a practical development environment, taking full advantage of the increasing tool support for the UML.

References [1]. Kovacevic, S. UML and User Interface Design. in UML'98. 1998. Mulhouse - France, 1998. [2]. Constantine, L., Essential Modeling: Use cases for user interfaces. Communications of the ACM, 1992. [3]. Constantine, L.L. and L.A.D. Lockwood, Software for use : a practical guide to the models and methods of usage-centered design, Reading, Mass.: Addison Wesley, 1999. [4]. Jacobson, I., Object-oriented software engineering: a use case driven approach, New York: ACM Press - Addison-Wesley Pub., 1992. [5]. Cooper, A., The inmates are running the asylum, Indianapolis, IN: Sams, 1999. [6]. Cockburn, A., Structuring Use Cases with Goals. Journal of Object-Oriented Programming, (Set.-Out. 1997 and Out.-Nov. 1997), 1997. [7]. Artim, J., et al., Incorporating work, process and task analysis into industrial objectoriented systems development. SIGCHI Bulletin, 3 0 (4), 1998. [8]. Nunes, N. and J.F.e. Cunha. Detailing use-case with activity diagrams and objectviews. in Workshop on Integrating Human Factors into Use Cases and OO Methods. 1999. Lisbon - Portugal: http://www.crim.ca/~aseffah/ecoop/, 1999.

[9]. Jacobson, I., G. Booch, and J. Rumbaugh, The unified software development process. The Addison-Wesley object technology series, Reading, Mass: Addison-Wesley, 1999. [10].OMG, Unified Modeling Language 1.3, , Object Management Group, 1999. [11].Coutaz, J. PAC: An object-oriented model for dialogue design. in INTERACT'87. 1987: Elsevier Science Publisher, 1987. [12].Beck, K. and W. Cunningham. A laboratory for teaching object oriented thinking. in OOPSLA'89. 1989, 1989. [13].Pfaff, G. and P.J.W.t. Haguen, eds. User Interface Management Systems. , SpringerVerlag: Berlin, 1985. [14].Bass, L., A metamodel for the runtime architecture of an interactive system: The UIMS developers workshop. SIGCHI Bulletin, 2 4 (1): p. 32-37, 1992. [15].Coutaz, J., Software Architecture Modeling for User Interfaces, in Encyclopedia of Software Engineering, Wiley, 1993. [16].Nunes, N.J. and J.F.e. Cunha. Wisdom – A UML based architecture for interactive systems. in Proc. DSV_IS'2000. 2000, Limerick - Ireland, to appear in LNCS, Springer-Verlag, New York, 2000. [17].Paternò, F., Model Based Design and Evaluation of Interactive Applications. Applied Computing, London: Springer-Verlag, 1999. [18].Roberts, D., et al., Designing for the user with OVID : bridging user interface design and software engineering. lst ed, Indianapolis, IN: Macmillan Technical Pub., 1998. [19].Nunes, N.J. and J.F.e. Cunha, Whitewater Interactive System Development with Object Models, in Object-Oriented User Interface Design, M.v. Harmelen, Editor, Addison-Wesley, 2000. [20].Conallen, J., Building Web Applications with UML. Object Technology Series: Addison-Wesley, 1999.