usage-centered design using uml

Usage -Centered Design using UML 1

Usage-Centered Design using UML

1. Introduction........................................................................................................... 2 2. Driving models ..................................................................................................... 2 3. Process overview .................................................................................................. 3 4. Procedure for applying usage-centered design ..................................................... 4 5. Tools and Examples.............................................................................................. 5

5.1. User Role Model........................................................................................... 5 5.2. Task Model ................................................................................................... 6 5.3. Content Model ............................................................................................ 12 5.4. Bussiness Rule Model................................................................................. 12

6. Essential Use Case:............................................................................................. 13 IMPORTANT REMARK: This paper is a summary of some others written by Lockwood and Constantine which can be found in: http://www.foruse.com/publications/index.htm BIBLIOGRAPHY: The papers listed below are specially interesting and have been used to write the current one:

1. Rapid Abstract Prototyping" 2. "From Abstraction to Realization: Abstract Prototypes Based on Canonical

Components" 3. "Structure and Style in Use Cases for User Interface Design" 4. Usage-Centered Engineering for Web Applications"


Usage-Centered Design using UML 1. INTRODUCTION The process called usage-centered design [Constantine and Lockwood, 1999] partakes of a broadly user-centered design philosophy, but highlighting the fact that the center of attention is usage rather than users per se. In calling it usage-centered design the attention is drawn to those particular aspects of users that are most relevant to user interface design, promoting the linkage to use cases as a model of tasks (or usage). User-Centered Design Usage-Centered Design Focus is on users: user experience and user satisfaction Driven by user input Substantial user involvement:

- User studies - Participatory Design - User feedback - User testing

Design by iterative prototying Highly varied, informal, or unspecified processes Desing by trial-and-error, evolution

Focus is on usage: improved tools supporting tasks accomplishment Driven by models and modeling Selective user involvement:

- Explorative modeling - Model validation - Usability inspections

Design by modeling Systematic, fully specified process Design by engineering

2. DRIVING MODELS

As represented in Figure 1, usage -centered design is a model-driven process employing three primary abstract models: a user role model, a task model, and a content model:

- The user role model captures and organizes selected aspects of the relationship between particular users and the system being designed, i.e. the salient characteristics of the roles that users paly in relation to a system. Among numerous possible aspects of this relationship are:

o the purpose and frequency of interaction, o the volume and direction of information exchange, and


o the attitude toward the system of users in the role. - The task model represents, in the form of essential use cases, the structure of work that

users in user roles are interested in accomplishing with the system. - The content model represents the content and organization of the user interface needed

to support the identified tasks, and apart from its appearance and behavior. The content model is also called abstract prototype 1, because it represents in the abstract (independent of their actual appearance or behaviour in the user interface as realized) the contents of a user interface and how these are organized into interaction contexts, that is, the contexts withing which users interact with the system. Abstract prototypes serves as a bridge between the task model and a realistic or representational prototype, such as conventional prototypes or design sketches.

Each of these three models consists of two parts: a collection of descriptions and a map of the relationships among those descriptions:

- The relationships among user roles are represented in overview by a user role map. - The task model consists of a set of task cases and a map of the interrelationships among

those task cases. Task cases are a form of essential use cases. The interrelationships among use cases are modeled in a use case map (corresponding to but not identical with the “Use Case Diagram” of UML).

- The content model represents the contents of the various interaction contexts2 within which users can interact with the system; the navigation map represents the interconnections among these interaction contexts.

3. PROCESS OVERVIEW

Figure 3 shows a logical overview of the usage-centered design process.

1 Together, the content model and the navigation map constitute what is sometimes called an abstract prototype [Constantine, 1999]. (The “logical prototype” or “logical user-interface design” referred to in the Unified Process [Jacobson et al., 1999: 161ff] is essentially the same concept, reflecting our work with Jacobson and his colleagues earlier in the 1990s [Ahlqvist, 1996a; 1996b].) 2 or “views” as they are referred to in WISDOM [Nunes and Cunha, 2000] and some other methods


* System actors –other software and hardware systems with which the system must interact– are separated from human actors playing roles as users. * Conceptually, a final visual and interaction design, usually in the form of an annotated paper prototype, is based on the abstract prototype, that is, the content and navigation models. These, in turn, derive from the task model, which itself depends on the model of user roles. * Conceptually, a straightforward and direct derivation links the final design back to task cases supporting user roles. Each page, form or other interaction context corresponds to an abstract prototype supporting a cluster of interrelated task cases. The actual buttons, links, tables, displays, and other features are derived directly form abstract components wich realized specific steps within supported task cases, in turn, support the performance of roles users can take in relation to the site or application.

In practice, the role model, task model, and content models are built more or less concurrently, with the attention of the modelers moving freely among them depending on the course of analysis and problem-solving. The models themselves serve as holding places for the designer’s fragmentary but evolving understanding, thereby helping to organize and systematize the process3. The three core models are developed in coordination with and interlinked with other models, including:

- a domain model, which may take the form of a data or object model or even a simple glossary, depending on the nature and scope of the project

- a business rules model, that embodies the underlying logic and constraints of the application

- an operational model, that captures salient aspects of the working environment or operational context within which a system is deployed and used

4. PROCEDURE FOR APPLYING USAGE-CENTERED DESIGN Preliminary steps:

1. Essential purpose and preconception: Clarify business and user purposes, and then fantasize and set aside preconceptions of features, facilities, content and capabilities.

o It is prefered to kick off the process by involving managers, users, developers, and other

stakeholders in framing the purposes of the application from the business perspective and from the point of view of external users. Business and external purposes can be brainstormed onto cards, which can then be sorted to establish priorities.

o In a similar vein, we encourage participants to share their fantasies about the features, functions facilities, content, and capabilities of the system, but these ideas are clearly labeled as preconceptions and set aside to be treated as negotiable fantasies rather than requirements.

2. Exploratory modeling: Identify questions, ambiguities, and areas of risk and uncertainty.

o This is done by sketching out rough versions of roles and tasks models that will be

develop in more refined form later. In this way, needed but missing information is quickly identified.

3 This concurrent modeling approach makes for a more flexible and efficient process than traditional process models, which are more strictly sequential whether they are based on iteration or on a once-through “waterfall” cycle.


First iteration: 3. Role modeling: inventory and prioritize all user roles and select initially targeted subset. 4. Task modeling: inventory and prioritize all tasks and select initially targeted subset. 5. Task clustering: group all tasks by affinity and draft overall navigation architecture. The

navigation architecture specifies how the overall user interface is organized into interaction contexts, collectins, and groups, how these are presented to users, and how users navigate among these.

o Example: The navigation architecture might specify how parts of the user interface will

be organized into tabbed notebooks accessed through a set of command buttons on a central dispatch dialog, with sections within notebook pages reached through shortcuts arrayed in a menu-like bar across the top of each notebook page. Fig4 pag12 web applic

6. Design: draft visual and interaction scheme; review and revise aesthetic design. The

visual and interaction scheme is a sort of abstract style guide. It briefly describes the recurrent visual elements that will be used throughout the design as well as the common layouts, visual arragements, or templates that apply to various interaction contexts.

o Example: The schema might specify a basic layout grid with a modified tree-view in

the left-most column for primary navigation and a set of view controls across the top for secondary navigation. At a more detailed level it might specify that a distinct color should identify all editable fields, which can be edited in place by double clicking. It might further spell out how certain collections of controls will be placed on slide-out tool panels that automatically open on mouseover anc close after use.

7. Abstract prototyping: develop content model for interaction contexts supporting

selected subset of tasks. 8. Desing: develop detailed user interface design for selected interaction contexts. 9. Construction: Program designed portions of user interface.

Successive iteractions (similarly):

3.a Review role model and revise as needed, select next subset. 4.a Review task model and revise as needed, select next subset. 5.a Review navigation architecture and revise as needed. 6.a Review visual and interaction scheme and revise as needed. 7.a Develop content model for interaction contexts supporting next selected task subset. 8.a Design user interface for selected interaction contexts. 9.a Construct newly design portions.

5. TOOLS AND EXAMPLES 5.1. USER ROLE MODEL Example: Application for buying flight tickets and for checking luggage Description of User Roles User Role Map (General Use Cases Map)

Customer check availability and book a seat according to his preferences Passenger check in his luggage and his flight

Book a seat

Check in Customer

Passenger


5.2. TASK MODEL 5.2.1. Describing a task case The style in which use cases are written has a profound effect on their utility to designers and on the quality of the designs that result. In this section, we will illustrate some common styles in which use cases can be written. We will see two possible methods to describe task cases:

A. Using Partitioned narratives (first using essential task cases and evolving them to obtain concrete task cases) in combination with the use of pre- and post-conditions.

B. Using structured essential use cases Important note: Only one of them (A. or B.) must be chosen to undertake the practices. There is no hard and fast rule for choosing between the informal and structured use cases. It depends as much on how the project is organized as upon the size of the problem. However, in general, modeling with informal use case narratives begins to break down with more than a few dozen use cases. Moreover, in any situation where analysts, designers, and developers work separately and communicate primarily through models, greater formality is also demanded. 5.2.1.1. Partitioned narratives Two stages:

1. To ellaborate the essential task case (Primary model) A task case written in the essential form is shorter, simpler and more closely represents what the task is truly about for the user.

2. To ellaborate the concrete task case (Concrete model)

The boundary between what is inside the system and what is outside—the user interface—must be very clear distinguished. The simple solution to this is to separate the user and the system side of the interaction completely. In partitioned narratives, there is a division of the narrative into two columns: In essential task cases In concrete task cases

- the user intention model and - the system responsability model.

- the user action model and - the system response model.

In this style, the boundary representing the user interface is obvious, and it is immediately apparent which part of the narrative refers to the user and which to the system. Example: the cash withdrawal use case expressed as a partitioned narrative: Essential task case Task case


Name of the case User intentions System responsibilities 2. Identify myself 5. Make choice 7. Take cash

1. Request identity 3. Verify identity 4. Offer choices 6. Give requested cash

Name of the case User action System response 1. Insert card in ATM 4. Enter PIN 7. Select option 9. Select account 11. Enter amount 13. Confirm amount 15. Take card

2. Read card 3. Request PIN 5. Verify PIN 6. Display option menu 8. Display account menu 10. Prompt 12. Display amount 14. Return card 16. Dispense cash if available

5.2.1.2. Pre- and post-conditions Pre-conditions also offer a means for expressing necessary ordering among use cases. Pre - and post-conditions of other use cases provides a straightforward and logical means for modeling workflow. Example: Place Order Preconditions: A valid user has logged into the system. Flow of events: Basic Path

1. The use case starts when the customer selects Place Order 2. The customer enters his or her name and address. 3. If the customer enters only the zip code, the system will supply city and state. 4. The customer will enter product codes for the desired product. 5. The system will supply a product description and price for each item. 6. The system will keep a running total of items ordered as they are entered. 7. The customer will enter credit card information. 8. The customer will select Submit. 9. The system will verify the information, save the order as pending, and forward payment information to the accounting system. 10. When payment is confirmed, the order is marked Confirmed, an order ID is returned to the customer, and the use case ends.

Alternative paths In step 9, if any information is incorrect, the system will prompt the customer to correct the information. Postcondition: The order has been saved and marked confirmed. 5.2.1.3. Structured Essential Use Cases The overall organization of a structured essential use case is illustrated schematically below. The use case is divided into three principal parts:

- The identification section uniquely identifies the use case and explains its purpose or function.

- The relationships section identifies other use cases related in some way to the use case.


- The process section, the narrative body of the use case, defines its interaction process or dynamic aspects.

Identification ID Name Contextual Purpose Supported Roles Relationships Specializes Extends Resembles Equivalents Process Preconditions User Intentions System Responsabilities Asynchronous / Synchronous Extensions Asynchronous / Synchronous Extensions (steps) (steps) Post-conditions Business Rules ID: The Identifier is merely a sequence number or other unique and permanent identification code. Name: The name of an essential use case should reflect its function or immediate purpose. Contextual Purpose: It contains the description of the larger goals or working context in which the use case is employed. For example, the Contextual Purpose of browsing empty rooms by category in a hotel reservation system might be: “In order to complete guest registration, a suitable room must be located and assigned to the guest.” Supported Roles: It further qualifies the essential nature of the use case by listing the user roles that it is intended to support. For example, the use case browsing empty rooms by category might support the roles of Ordinary Desk Clerk, Desk Supervisor, and Self –Registering Guest. Relationships: The Relationships section identifies other use cases to which the use case is related. Within the Relationship section, related use cases are listed in clauses labeled appropriately using the terms Specializes, Extends, Resembles, and Equivalents. In usage-centered design, use cases may be interrelated in several ways: ??inclusion – one use case is included (by reference) within or used by another use case ??specialization – one use case is a specialized variant of another, more general case ??extension – one use case extends another by introducing alternative or exceptional processes In addition, we find other relationships useful on occasion. ??similarity – one use case corresponds to or is similar to or resembles another in some unspecified ways

Similarity provides a way to carry forward insight about relationships among use cases even when the exact nature of the relationship is not yet clear. Example: reviewing savings account summary and reviewing checking account summary might be modeled as separate but similar use cases before it is known whether one process can cover both or if two different approaches will be needed.

??equivalence – one use case is equivalent to another, that is, serves as an alias Equivalence flags those cases where a single definition can cover what are, from the user’s perspective, two or more different intentions. This construction makes it easier to validate the model with users and customers while also assuring that only one design will be developed. In the absence of such a relationship, the modeler would be forced to define the two use cases as trivial specializations of a totally artificial general use case.

Example: the use case “browsing empty rooms” by category might incorporate the following Relationships:

Extends: “checking arriving guest into acceptable room; reviewing room utilization” Specializes: “browsing rooms”

Identification ID Name: Browsing empty room Contextual Purpose Supported Roles Relationships Specializes: browsing rooms Extends: checking arriving guest into acceptable room;

reviewing room utilization


Resembles Equivalents Process Preconditions User Intentions System Responsabilities Asynchronous / Synchronous Extensions Asynchronous / Synchronous Extensions (steps) (steps) Post-conditions Business Rules Note: References within the Relationship section are reflected in the Use Case Map, which is discussed later. Process: The Process section of the use case begins with Preconditions and ends with Post-conditions. Both Pre - and Post-conditions can include explicit or implicit references to other use cases. The narrative body of the use case is divided into User Intentions and System Responsibilities. Example: Identification ID Name Contextual Purpose Supported Roles Relationships Specializes Extends Resembles Equivalents Process Preconditions User Intentions System Responsabilities 2. select standard test setup 4. optionally [do modifying test setup] 5. confirm test setup 7. optionally [print test results]

1. present list of standard test setups 3. display selected test setup 6. run test as set up and report 8. print and confirm

Post-conditions Business Rules Extensions: An extension is a distinct use case embodying alternative, conditional, or exceptional courses of interaction that can alter or extend the main “flow of events” embodied in some base case. Synchronous extensions The first form of “extension” is termed "synchronous" because its occurrence is synchronized with the use case it extends. In fact, a synchronous extension is nothing more nor less than a conditional inclusion. It is a use case that will, under some circumstances, be included or used at a particular point in the course of the interaction. By definition it must be "visible" in the narrative for the base case because this narrative must specify at what point in the narrative the extension can occur. Asynchronous exten sions The other case covered by the original notion of extension refers to alternative or exceptional cases whose point of occurrence is unpredictable. Such asynchronous extensions operate like interrupts to the mainline interaction. For instance, in the use case of Example 13, the user might choose at any time to reset the system, canceling the test and restoring all original values. Similarly, the system could at any time assume responsibility for informing the user that an unrecoverable exception has occurred. Because such extensions apply to the interaction as a whole but can occur at any point, they are most reasonably separated out and presented at the top of the narrative body, as in this example: Example: Identification ID Name Contextual Purpose Supported Roles Relationships Specializes Extends


Resembles Equivalents Process Preconditions User Intentions System Responsabilities Asynchronous Extension optionally at point do {resetting test}

Asynchronous Extension optionally at any point do {reporting fatal exception}

2. select standard test setup 4. optionally [do modifying test setup] 5. confirm test setup 7. optionally [print test results]


Post-conditions Business Rules

Business rules: See section 5.4 Business Rules Model. 5.2.2. Use Case Map A use case map models the interrelationships among use cases, mapping the overall structure of the tasks to be supported by the system being designed. Representing use cases Following Jacobson’s lead, we have always represented each individual use cases by an ellipse. There are two alternatives:

- One is to put the name outside the use case symbol. - The other is to include the name inside the ellyptical shape.

Cluster cases are portrayed as a graphical “stack” visually suggesting that the named case really covers a number of use cases.

Representing relationships Because in UML the type of relationship represented by a given line is not clear from its appearance, one must trace a line to its endpoints and find an adjacent label somewhere in the middle to know exactly how two use cases are related. The guillemets (« and ») surrounding relationship labels in UML are nothing more than graphical noise that makes models harder to parse visually. For readability in complex models, we use different line styles to represent different relationships, employing also labels. (See Figures 5).

Specialization

Inclusion

specializes

uses (or includes)


Extension (asynchronous)

Inclusion (conditional)

Inclusion (as pre-condition)

Equivalence

Similarity

An example of a partial use case map using these conventions is shown in Fig.6

extends

0..N may use (or include)

requires

equivalent

resembles


5.3. CONTENT MODEL For further information on this model, read papers [1] and [4] 5.4. BUSSINESS RULES MODEL Business rules are the policies, constraints, and conditions to be satisfied that underlie business processes. Business rules are a critically important part of most real world applications. Because they describe how “the business” or process is supposed to operate, the term is used even within technical areas not normally characterized in business terminology. Example: a business rule may require that a credit limit increase cannot be authorized on an account for which an activity summary has not been requested in the same session, even though, in principle, there is otherwise no necessary sequential dependency between these two functions. The use case reviewing account activity summary, therefore becomes a precondition of a use case authorizing credit limit increase. An annotation, such as, “(Rule: #27 Activity Review on Credit Increase)” is associated with the relationship between the two use cases and would appear on the relationship line in the use case map and in the Preconditions clause in a form like this:

do reviewing account activity summary (Rule: #27 Activity Review on Credit Increase) For those business rules applying to the use case as a whole, a clause within the Process section is reserved. Strickly speaking, a use case model is incomplete as a specificaion unless the associated business rules are included or connected in some manner. Identification ID Name Contextual Purpose Supported Roles Relationships Specializes Extends Resembles Equivalents Process Preconditions: do reviewing account activity summary (Rule: #27 Activity Review on Credit Increase) User Intentions System Responsabilities Asynchronous Extension optionally at point do {resetting test}

Asynchronous Extension optionally at any point do {reporting fatal exception}

2. select standard test setup 4. optionally [do modifying test setup] 5. confirm test setup 7. optionally [print test results]


Post-conditions Business Rules


Annex: UML related concepts Actor: An actor is a role that a user plays with respect to the system [Fowler, 1997: 46]. We distinguish system actors—other systems —from users in roles. A role thus constitutes a relationship between a user and a system and is defined by a set of characteristic needs, interests, expectations, behaviors and responsibilities. Most designers understand at some level that it is not so much users themselves but the roles that they play in relation to a system that must be taken into account in user interface design. Use Case: It is the specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem, or class can perform by interacting with outside actors [Rumbaugh et al, 1999:488] A use case is a typical interaction between a user and a computer system … [that] captures some user-visible function … [and] achieves a discrete goal for the user.

6. ESSENTIAL USE CASE: It is a single, discrete, complete, meaningful, and well-defined task of interest to an external user in some specific role or roles in relationship to a system, comprising the user intentions and system responsibilities in the course of accomplishing that task, described in abstract, technology-free, implementation-independent terms using the language of the application domain and of external users in role.

usage-centered design using uml

Documents