Modeling demystified, Part 3: Extend UML for user models

Associations, relationships, and stereotypes

Mandy Chessell, Distinguished Engineer, Master Inventor, IBM

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 (yusuf@uk.ibm.com), Solution Architect, IBM

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.

Summary: 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.

View more content in this series

Tag this!

Date: 25 Mar 2008
PDF: A4 and Letter (47KB | 8 pages)Get Adobe® Reader®
Activity: 1543 views

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

Name of association	Appearance	Meaning
Two-way		No arrowhead indicates a two-way association, meaning both ends have knowledge of the other. For example, a two-way association is often used between two user roles to indicate that the user roles need to communicate with each other.
Directed		An open arrowhead indicates that the relationship is one way. Only the instance farthest from the arrowhead has knowledge of the instance at the other end.
Aggregation		Indicated with a white diamond, an aggregation relationship means that the UML class closest to the diamond maintains a reference to instances of the other class from time to time. However, that UML class does not own it, and the association can be broken without damage to either element.
Composition		A black diamond indicates a composition relationship. The UML class farthest away from the diamond is a part of the other UML class or is owned by it.

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

User Role <<user_role>> Describes a related set of responsibilities that could be assigned to a single person or team	Attributes
	Icon and stereotype	Type	Description
	<<definition>>	-	A short description of the user role
	<<primary_goal>>	A class with the <<user_goal>> stereotype	Defines a user goal for the user role
	<<assumed_skill>>	A class with the <<skill_set>> stereotype	Defines a skill set that a person performing the user role is assumed to have

Table 3. User goal

User goal <<user_goal>> Describes an end state that a user role wishes to achieve. It explains why they do what they do.	Attributes
	Icon and stereotype	Type	Description
	<<definition>>	-	A short description of the user goal
	<<measure>>	-	How achievement with respect to the goal is to be measured
	<<target>>	-	The target that indicates the goal is successfully achieved
	<<subgoal>>	A class with the <<user_goal>> stereotype	Indicates that this user goal can be partially achieved by achieving the referenced user goal
	<<supporting_task>>	A class with the <<user_task>> stereotype	Indicates that this user goal may be achieved by performing this user task

Table 4. User team

User team <<user_team>> A grouping of user roles working together to achieve a common goal	Attributes
	Icon and stereotype	Type	Description
	<<definition>>	-	A short description of the user team
	<<member>>	A class with the <<user_role>> stereotype	A user role in the team
	<<primary_goal>>	A class with the <<user_goal>> stereotype	The user goal for the team

Table 5. Skill set

Skill set <<skill_set>> Describes a related set of skills that could form part of a course or a book, or be expected of someone from a particular profession or discipline	Attributes
	Icon and stereotype	Type	Description
	<<definition>>	-	A short description of the skill set
	<<skill>>	-	A skill associated with a skill set
	<<glossary>>	A class with either the <<user_object>> or <<user_artifact>> stereotype	The referenced class is a concept that is understood by a user role that has this skill set
	<<nested_skill_set>>	A class with the <<skill_set>> stereotype	Indicates that a skill set is nested within this skill set (a prerequisite skill)

Table 6. Discipline

Discipline <<discipline>> A grouping of related skill sets	Attributes
	Icon and stereotype	Type	Description
	<<definition>>	-	A short description of the discipline
	<<nested_skill_set>>	A class with the <<skill_set>> stereotype.	A skill set is a part of this discipline
	<<nested_discipline>>	A class with the <<discipline>> stereotype.	A discipline is nested within this discipline

Table 7. User task

User task <<user_task>> A user task describes a piece of work that has to be done	Attributes
	Icon and stereotype	Type	Description
	<<definition>>	-	A short description of the user task
	<<subtask>>	A class with the <<user_task>> stereotype	Indicates that the referenced user task is executed as part of this user task's implementation
	<<follow_on_task>>	A class with the <<user_task>> stereotype	Suggests that a user may typically perform the referenced user task after this task is complete
	<<action_target>>	A class with either the <<user_object>>, <<user_object_filter>> or <<user_artifact>> stereotype	The user task operates on the referenced class as one of the steps in its operation. The keyword on the association describes the action performed. Examples of keywords for user objects and user object filters include: <<create>> - One or more instances are created. <<update>> - One or more instances are updated. <<view>> - One or more instances are displayed for review. <<browse>> - One or more instances are displayed for navigation to a nested object. <<delete>> - One or more instances are deleted. <<select>> - One or more instances are selected from a list. <<search>> - One or more instances are retrieved from a search. <<compare>> - One or more instances are displayed for comparison purposes. <<merge>> - One or more instances are displayed for comparison, and attributes are selected to create a new instance that is a merge of the original instances. <<reorganize>> - One or more instances are to be restructured internally by the user. Examples of keywords for user artifacts include: <<new>> - One or more instances are created on disk. <<open>> - One or more instances are opened and the contents displayed. <<save>> - The contents of one or more instances are saved to disk. <<remove>> - One or more instances are destroyed. <<close>> - The user is no longer working with the user artifacts. <<file>> - A combination of <<save>> and <<close>> The cardinality of this attribute describes how many instances of the referenced class are involved in the action.
	<<required_skill_set>>	A class with the <<skill_set>> stereotype	Indicates that a user role must have the referenced skill set to perform this user task

Table 8. User domain

User domain <<user_domain>> A logical grouping of related user tasks. User domains can be composed of other user domains.	Attributes
	Icon and stereotype	Type	Description
	<<definition>>	-	A short description of the user domain
	<<nested_domain>>	A class with the <<user_domain>> stereotype	Indicates that a user domain is nested within this user domain
	<<nested_task>>	A class with the <<user_task>> stereotype	Indicates that a user task is grouped within this user domain

Table 9. User object

User object <<user_object>> Describes a concept that a user must understand to perform a user task. The understanding comes from the skill sets that the user role has acquired.	Attributes
	Icon and stereotype	Type	Description
	<<definition>>	-	A short description of the user object
	<<taught_by>>	A class with the <<skill_set>> stereotype	This user object is understood by a user role that has this skill set.
	<<action_source>>	A class with the <<user_task>> stereotype	The referenced user task can operate on this user object.
	<<user_attribute>>	A primitive type from UML or a model library A UML enumeration A class with either the <<user_object>> or <<user_datatype>> stereotype	An attribute about this user object that is of interest to the user
	<<dynamic_enum>>	See <<user_attribute>>.	Only appears on an attribute that also has the <<user_attribute>> stereotype. It indicates that the permitted values of this attribute are defined as a list at run time.
	<<identifier>>	See <<user_attribute>>.	Appears only on an attribute that also has the <<user_attribute>> stereotype. It indicates that the attribute provides useful information to the user in locating an instance of the enclosing user object.

Table 10. User datatype

User datatype <<user_datatype>> A complex type for a user attribute	Attributes
	Icon and stereotype	Type	Description
	<<definition>>	-	A short description of the user datatype
	<<user_attribute>>	A primitive type from UML or a model library A UML enumeration A class with either the <<user_object>> or <<user_datatype>> stereotype	An attribute that is of interest to the user
	<<dynamic_enum>>	See <<user_attribute>>.	Only appears on an attribute that also has the <<user_attribute>> stereotype. It indicates that the permitted values of this attribute are defined as a list at run time.

Table 11. User object filter

User object filter <<user_object_filter>> A restricted list of attributes from a user object. Used with a user task to show which attributes it uses.	Attributes
	Icon and stereotype	Type	Description
	<<definition>>	-	A short description of the user object filter
	<<filtered_object>>	A class with the <<user_object>> stereotype.	The referenced user object is being filtered by this user object filter.
	<<user_attribute>>	A primitive type from UML or a model library A UML enumeration A class with either the <<user_object>>, <<user_object_filter>> or <<user_datatype>> stereotype	An attribute about the referenced user object that is of interest to the user
	<<dynamic_enum>>	See <<user_attribute>>.	Only appears on an attribute that also has the <<user_attribute>> stereotype. It indicates that the permitted values of this attribute are defined as a list at run time.
	<<identifier>>	See <<user_attribute>>.	Only appears on an attribute that also has the <<user_attribute>> stereotype. It indicates that the attribute provides useful information to the user in locating an instance of the enclosing User Object.

Table 12. User artifact

User artifact <<user_artifact>> A physical asset, typically a file, that the user creates or works with	Attributes
	Icon and stereotype	Type	Description
	<<definition>>	-	A short description of the user artifact
	<<taught_by>>	A class with the <<skill_set>> stereotype	This user artifact is understood by a user role that has this skill set.
	<<action_source>>	A class with the <<user_task>> stereotype	The referenced user task can operate on this user artifact.
	<<user_attribute>>	A primitive type from UML or a model library A UML enumeration A class with either the <<user_object>> or <<user_datatype>> stereotype	An attribute about this user artifact that is of interest to the user. If the user artifact is a file, it could be properties of the file, or the content of the file contained within.
	<<dynamic_enum>>	See <<user_attribute>>.	Only appears on an attribute that also has the <<user_attribute>> stereotype. It indicates that the permitted values of this attribute are defined as a list at run time.
	<<identifier>>	See <<user_attribute>>.	Only appears on an attribute that also has the <<user_attribute>> stereotype. It indicates that the attribute provides useful information to the user in locating an instance of the enclosing 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

Check out the other parts of this series:
- Part 1, "Creating a system specification from the user's point of view"
- Part 2, "Building a user model"
Learn more about User Engineering UML and IBM design principles and guidelines.
"Building ease of use into the IBM user experience" (IBM Systems Journal, Volume 42, Number 4, 2003) provides an overview of the process and organizational transformation that IBM has gone through in improving the user experience with its offerings.
"Delivering expected value to users and stakeholders with User Engineering" (IBM Systems Journal, Volume 42, Number 4, 2003) gives an overview of the fundamental concepts of the UE process, including an appreciation of the engineering-inspired rigor.
Browse the technology bookstore for books on these and other technical topics.

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

Check out developerWorks blogs and get involved in the developerWorks community.

About the authors

Comments (Undergoing maintenance)

Trademarks | My developerWorks terms and conditions

Close [x]

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/

SITE_ID=1

Zone=Rational, SOA and Web services

ArticleID=297044

ArticleTitle=Modeling demystified, Part 3: Extend UML for user models

publish-date=03252008

author1-email=mandy_chessell@uk.ibm.com

author1-email-cc=

author2-email=yusuf@uk.ibm.com

author2-email-cc=