 | Mandy Chessell (mandy_chessell@uk.ibm.com), Distinguished Engineer, Master Inventor, IBM
Larry Yusuf (yusuf@uk.ibm.com), Solution Architect, IBM
25 Mar 2008 This series provides basic information on how to build user models. In this
third article, learn about the stereotypes and relationships used to extend Unified
Modeling Language (UML) for user models. A user model is a description of a set of
people and how they will work with an IT solution.
Introduction
A user model is a description of a set of people and how they will work with an IT
solution. This type of modeling, which is based on leading usability theory and
practice, lets solution architects specify the external design elements of the IT solution so that
it's both useful and usable to all types of users.
Part
1 of this series, "Creating a system specification from the user's point of view,"
describes a user model and why it helps improve the
usability of the systems you build.
Part 2, "Building a user model,"
explains how to build a user model of a simple component that supports secure
access to Web resources.
In this article, learn about the stereotypes and relationships used to extend
Unified Modeling Language (UML) for user models.
UML basics
User models are built using UML, which is
is an industry-standard language used to describe designs for IT systems. It is
very flexible and allows you to model the system at many levels of abstraction.
Blobs and lines are the essence of UML. The blobs represent the concepts
in the design, and the lines linking the blobs each represent a relationship
between them. The relationships can be decorated with arrow heads,
cardinality, and other shapes to provide more information about the nature of the
relationship.
Figure 1. Blobs and lines
The shape of the blobs in UML reflects the broad category to which they belong.
For user modeling, a class (a rectangle)
represents each of the concepts in a user model, such as the user roles, user goals,
and user tasks. You specify which type of concept it is using a
stereotype.
Think of the stereotype as a subcategory. It is displayed
within angle brackets (<< >>).
In a large model, each stereotype
may have an icon (or decoration) to make it easier to spot the different
stereotypes. The example in Figure 2 shows a concept called Resource
Owner, which has a stereotype that defines it as a user role.
Figure 2. Concept in a user model
Attributes describe the properties of a concept, while stereotypes describe what type of property the concept is. In Figure 2, Resource Owner
has a single property called "Responsible for controlling the use of owned
resources." This property has the
<<definition>> stereotype applied.
Types of relationships
Although UML allows a wide range of relationships among UML classes, user
models are more restrictive. They use only associations, dependencies, and
generalizations in selected places.
An association, used to show that two UML classes are connected in some
way, is represented by a line drawn between the two UML
classes. Associations can be decorated by an open arrowhead and a black
or white diamond to give more information about the type of association.
Table 1 explains the four types of associations most common in user modeling.
Table 1. Associations
Each association shows how many instances of each UML class are involved in the
relationship. The number of instances is called the cardinality of the
relationship, and it is expressed as a number (for example, 1) or a range of numbers
(such as 1..7). The asterisk (*) is used to mean "many." So, 1..* means "one or
more." If an asterisk is used on its own, it is short-hand for zero
or more.
The cardinality is expressed at each end of the relationship. If there
is a relationship between UML classes A and B, the cardinality at the A end of the
relationship shows how many As that B is connected to. For example, as shown in Figure 3, a cat has four
legs and a leg can only be part of one cat.
Figure 3. Examples of associations
A stereotype can also apply to an association. The
stereotype is set on the role of the association (in Figure 3: has, wears, cares for,
lives with, and eats) through the stereotypes tab on the
properties pane, as shown in Figure 4.
Figure 4. Setting stereotypes
Once applied, the stereotypes then appear in the Project Explorer tree view. Figure
5 shows two views of an attribute—before and after
the <<primary_goal>> stereotype is applied.
Figure 5. Before and after
the <<primary_goal>> stereotype is applied
A dependency relationship is used between user goals when completion of one user
goal is dependent on the completion of another user goal. The dependency
relationship is especially
significant when the two user goals belong to different user roles, because it's an
area where collaboration or handover of work is required. The
dependency is represented by a dotted line with an arrowhead showing the direction
of the dependency. In the example in Figure 6, an application can be available
only if the infrastructure it runs on is also
available.
Figure 6. Dependency relationship
A generalization relationship is represented by a line connecting two UML
classes with a closed arrowhead. It means that the UML class that is the farthest
away from the arrowhead is a specialization of the other UML class. In Figure 7, a
Java™ developer user role is a specialized developer user role.
Figure 7. Specialized role
A specialization has all of the associations and attributes of the other class, plus
any additional associations that are connected to it. If the
specialization is modeled with an association that has the same name as the other
UML class, the specialization's definition is used.
Stereotypes and relationships
The tables in this section describe the stereotypes that are used on UML classes and
the types of relationships within a user model.
Table 2. User role
Table 3. User goal
Table 4. User team
Table 5. Skill set
Table 6. Discipline
Table 7. User task
Table 8. User domain
Table 9. User object
Table 10. User datatype
Table 11. User object filter
Table 12. User artifact
 |
Summary
This article provides a catalog of the UML modeling elements that are used in
user modeling. Because user modeling requires only a small
amount of UML knowledge, the solution architect is free to
concentrate on the content of the model.
Acknowledgments
Special thanks go to our colleagues who reviewed this article and offered excellent comments and feedback, in
particular Rebecca Schaller, David Radley, Iain Duncan, and Dan Wolfson.
Resources Learn
Get products and technologies
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational®, Tivoli®, and
WebSphere®.
Discuss
About the authors | 
| | Mandy Chessell, FREng CEng FBCS has worked for IBM since 1987. She is an IBM Distinguished Engineer, Master Inventor and member of the IBM Academy of Technology. Currently, she is the lead architect of Information Solutions in the SWG Information Management division. In earlier roles she developed new features for the CICS, Encina, TxSeries, Component Broker and WebSphere products. She has filed 40 patents, 15 of which have been granted so far. In addition to her technical responsibilities, Mandy is involved in initiatives designed to enhance the technical vitality of the IBM technical population. These activities include mentoring, serving on technical career development and promotion boards, leading innovation projects and running Women in Technology events. Outside of IBM, Mandy is a Fellow of the Royal Academy of Engineering and a visiting professor at the University of Sheffield, U.K. In 2001 she was the first woman to be awarded a Silver Medal by the Royal Academy of Engineering, and in 2000 she was one of the "TR100" young innovators identified by MIT's Technology Review magazine. More recently she won a British Female Innovators and Inventors Network (BFIIN) "Building Capability" award for her work developing innovative people and the BlackBerry "2006 Best Woman in Technology - Corporate Sector" award. |
| 
| | Larry Yusuf is a solution architect with Software Group Strategy and Technology where he develops outside-in design techniques that bring organization context and user perspectives to the architecture and design of complex software solutions. He leads the development of integration add-on components that fill gaps in the software portfolio. In previous roles, he has worked on emerging technologies, solution development, and testing. He has experience in business integration solution, model-driven development, patterns-oriented software development, and event management. He has written and presented extensively on these topics and has filed seven patents. |
Rate this page
| |
<<user_role>>
<<definition>> 
<<primary_goal>> 
<<assumed_skill>> 
<<user_goal>>
<<definition>> 
<<measure>> 
<<target>> 
<<subgoal>> 
<<supporting_task>> 
<<user_team>>
<<definition>> 
<<member>> 
<<primary_goal>> 
<<skill_set>>
<<definition>> 
<<skill>> 
<<glossary>> 
<<nested_skill_set>> 
<<discipline>>
<<definition>> 
<<nested_skill_set>> 
<<nested_discipline>> 
<<user_task>>
<<definition>> 
<<subtask>> 
<<follow_on_task>> 
<<action_target>> 
<<required_skill_set>> 
<<user_domain>>
<<definition>> 
<<nested_domain>> 
<<nested_task>> 
<<user_object>>
<<definition>> 
<<taught_by>> 
<<action_source>> 
<<user_attribute>> 
<<dynamic_enum>> 
<<identifier>> 
<<user_datatype>>
<<definition>> 
<<user_attribute>> 
<<dynamic_enum>> 
<<user_object_filter>>
<<definition>> 
<<filtered_object>> 
<<user_attribute>> 
<<dynamic_enum>> 
<<identifier>> 
<<user_artifact>>
<<definition>> 
<<taught_by>> 
<<action_source>> 
<<user_attribute>> 
<<dynamic_enum>> 
<<identifier>> 
