Roles and Activities >
Analyst Role Set >
User-Interface Designer >
Model the User-Interface
Roles and Activities >
Analyst Role Set >
User-Interface Designer >
Model the User-Interface
Activity:
| ||||||||||||||
Purpose
|
|
| Steps
For each use case prioritized to be considered from a usability perspective in the current iteration, take the following steps:
For the identified boundary classes, take the following steps:
Note: these steps are presented in a logical order, but you may have to alternate between them, or perform some of them in parallel. Also, some steps are optional depending on the complexity of the specific user interface under consideration. |
|
| Input Artifacts: | Resulting Artifacts: |
| Role: User-Interface Designer | |
| More information: See [CON99] for a very complete coverage of creating designs which focus specifically on usability. | |
| Workflow Details: |
Describe the characteristics of the (human) actors related to the use case. Focus on describing the primary actor of the use case since the major part of the interaction involves this actor. This information is important for the subsequent steps below.
Refer to Guidelines: Actor, Characteristics for details.
Start by creating a use-case storyboard for the use case, and assign a trace dependency between the two. The use-case storyboard has various properties, such as text fields and diagrams, that describe the usability aspects of the use case.
A use-case storyboard in the analysis model can be traced to a use case in the use-case model.
Refer to Guidelines: Use-Case Storyboard for details.
The step-by-step description of each use case that is input to this activity need to be refined and focused on usability issues; this refinement is captured in the Flow of Events - Storyboard property of the use-case storyboard.
Start by creating an initial outline of the Flow of Events - Storyboard using brief action statements, to acquire an understanding of the use case.
Then complement the Flow of Events - Storyboard with desired guidance, average values and volumes of objects, and average action usages for the different parts of the flow of events.
Refer to Guidelines: Use-Case Storyboard, Describing the flow of Events for details.
Capture the usability requirements on the use-case storyboard, defining how high the usability of the user interface must be.
Refer to Guidelines: Use-Case Storyboard, Capturing Usability Requirements for details.
In this step we identify the central and primitive boundary classes needed to provide the user interface of the use case.
Identify one central boundary class representing the primary window with which the actor is interacting. If such a class already exists, consider reusing it. This is because you should strive to minimize the number of primary windows a particular actor needs to interact with. However, you will, of course, have to compromise; primary windows should not be too complex or cluttered.
These central boundary classes are often aggregates of more primitive boundary classes (see below).
The central boundary class identified in a mail application is Mail Box. For details, refer to Guidelines: Boundary Class.
The central boundary class identified in a document editor is Document. For details, refer to Guidelines: Boundary Class.
Study the flow of events - storyboard in detail, and any other use-case descriptions at hand. Look for information interesting to the user, and information that needs to be visible and managed in the user interface.
Consider any business entity objects, or terms (especially nouns) in a glossary. Also consider entity objects if they exist. These are ways of gaining an understanding of what information is manipulated by the system and is thereby also interesting to the user.
Then, create one boundary class for each logical object manipulated by the actor via the user interface. When doing this, always consider reusing already existing boundary classes. The result of this step will prepare for the building of an object-oriented user interface.
The primitive boundary classes identified in a mail application include Mail Message Attachment. For details, refer to Guidelines: Boundary Class.
The primitive boundary classes identified in a document editor include Paragraph and Footnote. For details, refer to Guidelines: Boundary Class.
Describe obvious things about the boundary classes. At this stage, it is often possible to outline most of their attributes, aggregations, associations, and also some of their responsibilities. Recall that central boundary classes are often aggregations of more primitive boundary classes.
Each class will be refined and described in detail in the steps below; please refer to the steps below for examples.
The boundary classes participating in a use-case storyboard need to be related to it. This is done by capturing the classes in class diagrams, including their relationships, attached to the use-case storyboards.
Refer to Guidelines: Use-Case Storyboard, Creating Boundary Class Diagrams for details.
This step is optional and is done if the interaction sequence (e.g., flow of windows and navigation paths) needs to be captured formally in an interaction diagram.
Step through the flow of events of the use case (or more precisely, the subset of the use case under consideration in the current iteration), identifying the boundary objects responsible for the visible behavior of the use case. Note that these boundary objects are instances of the boundary classes as found in the previous step (Find Boundary Classes Needed by the Use-Case Storyboard). Illustrate the interactions between the participating boundary objects by creating one or more collaboration diagrams.
The collaboration diagram should also show interactions between the system and its actors. The flow of events usually begins when one of the actors requests something from the system, since an actor always invokes the use case.
Illustrate the interactions between objects by creating links between them; annotate the links with a short description of the intent of the invoking object, i.e. what it wants to achieve in the interaction with the invoked object. These "intents" will then be integrated into responsibilities on each corresponding boundary class, as described in the following step (Describe Responsibilities of Boundary Classes).
Refer to Guidelines: Use-Case Storyboard, Creating Boundary Object Interaction Diagrams for details.
This step is optional and is done if the diagrams and descriptions (as created above) need to be complemented and further clarified with references to an already existing user-interface prototype (if any).
Refer to Guidelines: Use-Case Storyboard, Complementing the Diagrams for details.
This step is optional and is done if the diagrams and descriptions (as created above) need to be complemented and further clarified with references to an already existing user-interface prototype (if any).
Refer to Guidelines: Use-Case Storyboard, Referring to the User-Interface Prototype for details.
The approach to follow in this step is similar to the one presented in the section "Describe Responsibilities" as described in the Activity: Use-Case Analysis. The only difference is that the demands are extracted from use-case storyboards instead of use-case realizations.
Note that a responsibility is a textual description of a cohesive subset of the behavior provided by a class. Given this, the responsibilities of boundary classes can be considered as high-level descriptions of the operations provided by the user interface and its windows.
For examples, refer to section "Examples of Boundary Class Responsibilities" in Guideline: Boundary Class.
The approach to follow in this step is similar to the one presented in the section "Describe Attributes and Associations" as described in the Activity: Use-Case Analysis.
Note that the attributes and their types should be conceptual, and serve as high-level descriptions of the properties of objects (such as windows) in the user interface. Also, these attributes may become classes themselves when the user interfaces is designed and implemented.
For examples, refer to section "Examples of Boundary Class Attributes" in Guidelines: Boundary Class.
In this step, we define aggregations, associations, and generalizations between boundary classes.
The approach to follow in this step is similar to the one presented in the section "Describe Attributes and Associations" as described in the Activity: Use-Case Analysis.
For examples, refer to section "Examples of Boundary Class Relationships" in Guidelines: Boundary Class.
Most of the usability requirements on the use-case storyboard should be distributed onto the participating boundary classes, and be refined on the classes, if necessary.
For examples, refer to section "Examples of Special Requirements on Boundary Classes" in Guidelines: Boundary Class.
Note that the class diagrams as created in the step Find Boundary Classes Needed by the Use-Case Storyboard above are local to the use-case storyboard. However, in some cases it is of value to present the boundary classes in "global" class diagrams that are not local to any use-case storyboard; for example, when used as input to the user-interface prototyping activity. For example, such class diagrams can include the following:
The use-case storyboards should be evaluated to verify that the work is headed in the right direction.
For check points on boundary classes, refer to section "Goodness Criteria on Boundary Classes and their Relationships" in Guidelines: Boundary Class.
|
Rational Unified
Process
|
