Mandy Chessell (mandy_chessell@uk.ibm.com), Distinguished Engineer, Master Inventor, IBM
Larry Yusuf (yusuf@uk.ibm.com), Solution Architect, IBM
04 Mar 2008 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 externals of the IT
solution so that it's both useful and usable to all types of users. In this second
article in the series,
learn
how to build a user model of a simple component that supports secure access
to Web resources. See how a user model can identify possible gaps in your
requirements definitions.
Introduction
In
Part 1 of this series, you learned what a user model is, and why it helps improve the usability of the systems you build. A user model describes how people will use an IT solution in terms of their role,
their goals, their skills, the tasks we're asking them to perform, and the objects
they'll work with in the IT solution. A user model contains the following concepts:
| User role | A set of responsibilities that characterize a group of people who use the system |
|---|
| User goal | An objective or motivation that a user role has to use the solution |
|---|
| Skill set | A collection of related skills that a user role may have |
|---|
| User task | An action that a user role takes to help achieve the user goals |
|---|
| User object | A concept, or virtual object, that a user role understands and works with during a user task |
|---|
| User datatype | A complex attribute type for a user object |
|---|
| User object filter | A restricted subset of the attributes for a user object |
|---|
| User artifact | A physical object, or file, that the user role has to work
with during a user task |
|---|
| User domain | A logical grouping of user tasks |
|---|
| Discipline | A logical grouping of skill sets |
|---|
| User team | A logical grouping of user roles |
|---|
A user model is a Unified Modeling Language (UML) class model. Each element in the model is represented as a
UML class with an appropriate stereotype applied. Stereotyped UML attributes and
associations describe their properties and the relationships between them.
In this article, learn how to build a user model for a simple scenario. (The UML
screen captures are from IBM Rational® Software Architect, Version 7.0.)
The scenario
The scenario involves a simple security component that
supports Web login and controlled access to online resources. The owner of each
resource can define who is allowed to access that resource. There are
three major functions in this component, from a business point of view:
- Setting up who can access each resource
- Logging in and accessing the desired resource
- Recording which users are accessing each resource, for audit purposes
The user roles
Building a user model begins with identifying who will be using the
solution. Users are characterized in the user model by
user roles.
A user role describes a group of users who have similar needs and
responsibilities. A user role could represent a particular job in the user
organization that will make significant use of the solution. Or, it
could be more granular, covering an aspect of work that is common to people doing
different types of jobs but that requires use of the solution in a similar way.
A user model contains a multitude of user roles. You must be particularly careful to
identify all types of users, because ignoring one group of people creates a weakness
in the solution. The user roles should be based on the reality of the user
population, rather than crafted to match the design of the solution itself.
In our security component scenario, there are people who own the resources
and people who use the resources. Each of these groups is a user role called Resource Owner and Business User, respectively.
The user roles cover an aspect of a user's work rather than represent a
complete job. They are not mutually exclusive. Someone could be the Resource
Owner for one resource and a Business User for another. A Resource Owner could
even be a Business User for his or her own resource. These
user roles just need to be distinct enough that an individual is performing only a
single user role at one time.
Another user role is the Auditor, who checks the audit records to determine
who is accessing each resource.
Finally, you need to consider:
- Who will set up the solution?
- Who will ensure it keeps running?
- Who will investigate problems with the solution?
- Who will extend the solution?
The security component has the following user roles:
- Resource Owner
- Responsible for ensuring that the right users gain access to the resources they own
- Business User
- Responsible for performing business using appropriate resources
- Auditor
- Responsible for definition of (and compliance with) security policies
- IT Administrator
- Responsible for the availability of the IT systems, including the security component
- Deployer
- Responsible for initial deployment of tested software releases
- Developer
- Responsible for adding new function to the component and fixing defects in the code
- Test Engineer
- Responsible for verifying that the component is coded correctly
- Solution Architect
- Responsible for selecting where the component should be used
Each user role is represented in the user model using a UML class with a
stereotype set to <<user_role>>. This stereotype is
shown at the top of the UML class with the  icon. The UML class is also given an attribute with a
stereotype of <<definition>>. This attribute's name is
a short description of the user role and is labeled with the  icon. Figure 1 shows an example of a user role defined with a UML class.
Figure 1. User role defined with a UML class
In Rational Software Architect, each attribute is also shown with the  icon, meaning the attribute is private and
is not significant in a user model.
Determining user goals
Each user role should have at least one user goal defined. A user goal defines
the end state, or objective, that a user role it trying to achieve. Figure 2 shows an
example of a user goal for the Resource Owner user role.
Figure 2. User goal for Resource Owner
The name of the user goal is the desired state of the Resource Owner. There is a
<<definition>> attribute providing a short
description, one or more <<measure>> attributes
( ) and, optionally, one
or more <<target>> attributes ( ).
The <<measure>> attribute describes how the user role
will measure success at achieving the user goal. If appropriate, you can
also model the level of achievement of the measures that denotes success. This is
given in the <<target>> attributes.
Often, the initial user goals that you define are too closely related to the tasks
you think the user might perform. For example, you might start with a user goal
called "Define all valid users." This is actually a set of actions that
would be modeled as a user task
(described later).
A user goal should declaratively define the state of affairs that the user role
wishes to achieve. It does not describe how this end state is achieved. There are
two advantages:
- You can objectively review whether the solution you specify really meets the
users' goals.
- It does not tie you into a specific implementation model at this early stage.
So, let's refine the user goal to be "Access to
resources is properly controlled." It captures the key reason why the
Resource Owner is going to use the IT solution, without describing how.
Once the user goal is defined, it is connected to the appropriate user role using
an aggregation relationship with the <<primary_goal>>
stereotype. It is called the primary goal to highlight that we are modeling only
the principal reasons why the user role is motivated to use the solution.
Figure 3 shows the aggregation association between the user role and the user
goal.
Figure 3. Primary user goal of a user role
The Project Explorer view for Resource Owner shows its
<<definition>> and the
<<primary_goal>> association to the user goal, as shown in Figure 4.
Figure 4. Stereotypes for
associations in Project Explorer
Stereotypes are applied to associations by selecting the role name ("Access to
resources is properly controlled" in this case) to display its properties in the
properties pane. The Apply Stereotypes button is under the Stereotypes tab, as shown in Figure 5.
Figure 5. Apply stereotypes
Attributes and associations appear in the Project Explorer in
alphabetical order. The order they appear on the diagram is defined in the properties
view for the Resource Owner under the Attributes tab.
User roles and skill sets
This section discusses the skills that each of the user roles is expected to have. Skills
are defined in skill sets. A skill set is a collection of skills that relate to a
topic. Each skill typically appears only in a single skill set. A skill set is
defined using a UML class with the <<skill_set>>
stereotype. A skill set has a <<definition>> attribute
that gives a brief description and one or more
<<skill>> attributes that explicitly documents the key
skills that make up the skill set. Figure 6 shows an example.
Figure 6. Skill set
A user role is related to a skill set using an aggregation (open diamond)
relationship with the <<assumed_skill>> stereotype. It
is possible to share skill sets between user roles. A user role may have multiple
skill sets.
In the example in Figure 7, there's a skill set for the resource security skills you'd expect a Resource Owner to have. This definition is stating that an
individual that owns a resource needs to have these skills.
Figure 7. User role with an
association to a skill set
When the aggregation from the Resource Owner user role to the Resource Security
Policies skill set is added, it appears in the Project Explorer view of Resource
Owner. You can see that the <<assumed_skill>>
stereotype has been applied to it.
Figure 8. <<assumed_skill>> stereotype
Modeling skill sets involves showing which skills are unique to a user role and
which are shared between some or among all of them. To do this, you also show
relationships (using an aggregation) between skill sets. Typically, skill sets
that represent advanced skills have aggregation relationships to more basic,
prerequisite skills.
In the example in Figure 9, there are three skill sets connected together: Basic Computer Skills, Personal
User Security, and Resource Security Policies. Resource
Security Policies has an aggregation relationship to Personal User Security. The
Project Explorer view shows that this aggregation has the
<<nested_skill_set>> stereotype applied to it, meaning that any user role that understands Resource Security Policies also
understands Personal User Security. The relationship between Personal
User Security and Basic Computer Skills is similar.
Figure 9. Connected skill sets
After you've modeled the skill sets, it is interesting to contrast the skills
needed by different user roles. For example, Figure 10 shows that the
Resource Owner has the same basic skills around resource security as the Business
User. Therefore, a Resource Owner has the skills to operate the resource security user
interface for the Business User.
Figure 10. Relationships
between user roles and skill sets
In this part of the modeling process you're defining the expected skill levels of
your users. If the people who are expected to fulfill these user roles do not
have the skills that you specify, then either the project needs to include training
material for these users, or you may need to try a different approach. This
analysis is also useful when designing an organization, as it helps to expose
where people could fulfill multiple user roles.
Building the
glossary
As you define the user goals and skill sets for your user roles, you'll
discover that you are starting to define a vocabulary for your user roles in the
choice of words you use in the names and
<<definition>> attributes.
The user model contains a formal definition of this vocabulary in the form of
user objects and user artifacts. User objects represent virtual concepts that
appear on the user interface. User artifacts are physical things, such as files and
documents.
Completing the glossary will take several iterations. Once the basic
definition of user roles, user goals, and skill sets is complete, it's a good time
to start building this vocabulary of user objects and user artifacts in your user
model.
Identifying user objects and user artifacts
Consider the skill sets shown in Figure 11.
Figure 11. Skill sets
The skill sets suggest there are the following types of user objects:
- Resource
- Access Level
- Access Control List
- User Group
- User Account
And the following user artifact:
For each of these, create a UML class with either the <<user
object>> or <<user_artifact>> stereotype
and add a <<definition>> attribute to provide a short
description.
Figure 12. Creating UML classes
If you aren't sure whether to use a <<user object>>
or a <<user artifact>> stereotype, just make your best
guess. It's easy to change the stereotype later when you have more information.
Adding user
attributes
Each user object and user artifact can have user attributes defined to show what
information is known about them by the user roles. In the example in Figure 13, Resource
has been given six attributes: Name, Type, Owner, Creation Time, Last Update Time,
and Description.
Figure 13. Resource user
object with attributes defined
Each user attribute has a type, which could be one of the following:
- A basic UML primitive type (String, Integer, Boolean, or
UnlimitedNatural).
- A type from an imported model library. In this example, DateTime and Text
come from an imported model library.
- A UML enumeration if there is a fixed set of values that the user attribute
can be set to.
- A user datatype.
- An association to another user object, user artifact, or user
datatype.
A user datatype is a custom datatype that represents a related collection of
user attributes. It is modeled as a class with the
<<user_datatype>> stereotype applied. The datatype
should be meaningful to the user.
A user attribute always has the <<user_attribute>>
stereotype applied, even when its type is an association to another user object,
user artifact, or user datatype. The icon for the
<<user_attribute>> stereotype is  .
A user attribute may also have the
<<identifier>> stereotype, which has the  icon, indicating that the
user attribute is useful to the user when identifying, locating, or selecting an
instance of the user object or user artifact. Finally, there is the
<<dynamic_enum>> stereotype ( ), indicating that the valid values for
this user attribute are defined as a list on the server (rather than as a fixed
list in the model through a UML enumeration).
Figure 14 shows the tree view of the Resource user object, with
the list of user attributes: Access Control List, Creation Time, Description, Last
Update Time, Name, Owner and Type. Both Name and Type also have the
<<identifier>> stereotype, and Type has
<<dynamic_enum>> too.
Figure 14. Tree view of Resource user object from Project Explorer
When using this tree view, keep in mind:
- The list shows all of the user attributes, including those
with a type that is an association to another user object, user artifact, or user
datatype. Access Control List is such an association, as shown in Figure 15. These
associations are described in more detail in the next section.
Figure 15. Associations
Adding associations
Relationships between user objects are defined using UML associations. All four
types are used: two-way, directed (one-way), aggregation, and composition.
In the example in Figure 16, there is a composition (black diamond) between the user
artifact Audit Log and the user object Audit Log Entry.
Figure 16. Composition
association between Audit Log and its Audit Log Entries
Composition means that one user object is a part of another. In the example, Audit Log
Entry is a part of an Audit Log. The cardinality is set to * which means
zero to many Audit Log Entries in each Audit Log. At the other end of the
relationship is a cardinality of 1, which means each Audit Log Entry appears
in only one Audit Log.
In the example in Figure 17, there are two aggregation associations from User
Group. Aggregation suggests a temporary relationship between two user objects.
The first of the aggregation associations from User Group loops back to itself.
This says a User Group can list other User Groups. The cardinality is * at both
ends, so a User Group can include zero to many other User Groups inside it and a
User Group can be included in zero or many other User Groups.
The second
aggregation association is to User Account and means that a User Group
could have zero or more User Accounts associated with it. Also, a User Account may be
included in zero or more User Groups.
Figure 17. Aggregation associations
This is a common modeling pattern for describing trees of user objects. You can
think of the User Groups as the intermediary nodes of the tree and the User
Accounts as the leaves.
Figure 18 shows how the Access Control List is modeled. It has a
composition association from Resource to say that an Access Control List is a part
of a Resource. Every Resource has one, and an Access Control List can be a
part of only one Resource.
Figure 18. Access Control
List is a part of a Resource
The Access Control List is made up of multiple entries, so we created a new
user object called Access Control List Entry, as shown in Figure 19.
Figure 19. Access Control
List with multiple entries
Initially, Access Level was defined as a user object. After more thought, it became obvious that it actually was a user attribute of an
Access Control List Entry. The values it can take are a fixed list of values. This
could be modeled with a UML enumeration if you wanted to hardcode the values in
the model, as shown below.
A <<dynamic_enum>> stereotype is used
so the access values are defined later and can be varied for each type of
Resource.
When using a dynamic enumeration,
the Access Level is given to either a User Group or a User Object. You can model this
choice using inheritance. A new user object is defined, called Access
List, which is set to be abstract through its properties view.
Figure 20. Properties
Because the Access List is abstract, its name is shown in italics.
Figure 21. Abstract user object in italics
Both User Group and User Account inherit from Access List, which means they are
both kinds of Access Lists.
Figure 22. Two types of Access
Lists using inheritance
Access Control List Entry connects to Access List using another aggregation
association. Because Access List is abstract, Access Control List Entry will
only ever point to a concrete (nonabstract) user object that inherits
from Access List—User Group or User Account, in this case. Figure 23 shows an example.
Figure 23. Inheritance
Defining user
object filters
One last concept related to the glossary, which becomes more important when you start
to model user tasks, is the user object filter. This is a class with a
<<user_object_filter>> stereotype applied. You can use it
to model a restricted view of a user object, and it contains a subset of the user
attributes for the user object. The user object filter has a directed association
to the user object it is filtering. The stereotype on this directed association is
<<filtered_object>>.
Figure 24 shows the definition of two filters for the Resource user object,
called Resource Selection Filter and Resource ACL Filter.
Figure 24. Defining user object filters for Resource
The Resource Selection Filter defines those user attributes from Resource that
would be useful when selecting one or more Resources from a list. For example,
when a Resource Owner wants to select a Resource to work on, the filter contains the Name,
Type, Creation Time, and Last Update Time user attributes. When this user object
filter is used in place of a user object, the user will not see the
Owner, Description, and Access Control List user attributes.
The Resource ACL Filter includes only the Name and the Access Control List. All
of the user attributes inside Access Control List, such as Access Control List
Entry, will be visible.
Designing user tasks that support user goals
At this point you should think about how each user goal is accomplished. User goals are
accomplished by performing user tasks. Each user task describes an action that a
user performs to achieve all or part of the user goals. User tasks can vary in
scope from coarse-grained to fine-grained. Some user tasks can be composed from
others. However, the user tasks are always expressed in terms that are meaningful
to the user.
A user task is defined using a UML class with the <<user
task>> stereotype. As with other user modeling elements, a user
task has a <<definition>> attribute to provide a short
description. Figure 25 shows a user task called Maintain Access to Resource.
Figure 25. Definition of
user task Maintain Access to Resource
The user goal is connected to the appropriate user tasks with a one-way
association. The association has the
<<supporting_task>> stereotype applied. A user goal is
typically connected to more than one user task. For example, the Resource
Owner's goal to ensure "Access to resources is properly controlled" is
achieved by performing the following user tasks many times:
- View my resources
- Maintain access to resource
- Transfer resource to a new owner
The class diagram in Figure 26 shows the three relationships from the user goal to the
user tasks.
Figure 26. Tasks to be performed to achieve user goal
The Project Explorer view shows these relationships with the
<<supporting_task>> stereotype.
Figure 27. The
<<supporting_task>> stereotype
This model shows only that there is a relationship between the user
goal and the user tasks. It does not describe when the user tasks are performed.
We rely on the user's skill and understanding to know when it's appropriate to
perform these tasks. For example, the Resource Owners will use their judgment (or
information from another source) to know which users should be given access and
when the access needs to be removed.
If you feel you can describe an unambiguous procedure that explains how a user
goal is translated into the user tasks, the user goal is likely
a complex user task. In such cases, you should change its stereotype to be
<<user_task>> and create a new user goal for the user
role.
Associating user tasks with user objects or artifacts
The behavior of a user task is modeled using a directed association from the
user task to a user object, user object filter, or user artifact, as shown below. The stereotype
on the association is <<action_target>>.
Figure 28. Relationships
between user task and user objects (user object filters)
Each action_target association defines a step in the user task. The
<<select>>, <<view>>,
<<create>>, <<update>>, or
<<delete>> keywords on the relationships show what
type of operation is being performed in the step. The order that the
associations appear in the attributes tab of the properties pane is the order in which
the steps are expected to be executed.
Validating a match
You want to validate that the
user tasks match the skills of the user roles.
After the user tasks are defined, we associate them with the skill sets required
to perform them. The relationship to use is a directed association from the user
task to the skill set, as shown in Figure 29. The stereotype on the association is
<<required_skill>>.
Figure 29. Directed association
If none of the skill sets you've defined so far seems to fit, define a new
skill set and associate it with the user task.
As you associate each skill set with the user task, check that the user roles
that are expected to perform the task have the relevant skill set. This needs to
be traced back through the user goal. For example, for "Maintain Access to
Resource" in Figure 30, there is a loop of relationships connecting the
user role, user goal, user task, and skill set.
Figure 30. Consistent loop
of relationships - user role is skilled to perform a user task
Associating user objects or artifacts with skill sets
The next stage is to define which user objects (and user artifacts) are
associated with each skill set. This stage can define the type of
information that needs to be included in education classes, help information, and
manuals. The simplest way to proceed is to connect each of the user
objects or artifacts manipulated by the user tasks associated with the skill set.
In the scenario, the user tasks work with the Access Control List and related
user objects. The user tasks are both associated with the Resource Security
Policies skill set, so the Resource Security Policies skill set has these
user objects too. Figure 31 shows the relationships.
Figure 31. Relationships
between skill set and user objects or artifacts
The association between the skill set and the user object or artifact is
two-way, with the <<glossary>> stereotype at the skill
set end and the <<taught_by>> stereotype at the user
object or artifact end.
Grouping related user tasks into user domains
Finally, you can define user domains to group related user tasks together. In the
example in Figure 32, a user domain is a UML class with the
<<user_domain>> stereotype applied. User domains can
be nested inside one another, along with user tasks. They are helpful when you
want to organize
the user tasks into logical groups in larger user models.
Figure 32. Grouping related user tasks
Conclusion
This article showed how quickly you can learn the notation and process for
building user models. You need only a basic knowledge of
UML class diagrams and an understanding of the UML stereotypes used to
distinguish a user role from a user goal.
Some development teams have had difficulty answering the questions that
user modeling raises. This, however, is not because user modeling is difficult; it's
due to an incomplete understanding of the users of the solution. User modeling's greatest value is in
identifying gaps in the requirements definition that, if ignored, could result in
poor usability (and all the costs and risk of failure that entails).
User modeling can reveal when it is time to do more analysis by contacting the
stakeholders and users to get the information you need.
Once the uncertainties have been resolved, the user model captures the missing
details in a form that will be useful to the development team. The result is a self-consistent definition of the type of users
supported by the solution, the skills they need, and the work they do when using
the solution. This, indeed, is a firm basis on which to build the solution's use
cases.
Stay tuned for Part 3 of this series, which will discuss the stereotypes and relationships you can use to extend UML for user models.
Acknowledgments
Special thanks goes to our colleagues who reviewed this article and offered
excellent comments and feedback, in particular
Rebecca Schaller 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
| 
