How to Write a Software Requirements

Specifications (SRS) Document

By William Jordan, eHow Member

Software Requirements - SRS

User-Submitted Article

Professional software developers must go through a software

requirements gathering process at the beginning of software
development projects of any meaningful size. The end product
of that project phase is a document commonly referred to as a
Software Requirements Specification or SRS. It is usually the
first project milestone or deliverable. The importance of this
document can not be understated. Its foremost function is to
record the client's business needs and requirements in written form and become the foundation
for the rest of the software development process. Once these requirements are compiled, the
document becomes the record of both the client's and developer's understanding of what the
software should accomplish. Usually the client reviews and signs off on the SRS thus beginning
the full software design and development phase. This article presents the high level steps
involved in creating this document.

Difficulty: Challenging

Instructions

Things You'll Need:

 Microsoft Word 2007

 Other word processing software
 Attention to detail
 Many meetings
 Diagramming software such as Microsoft Visio

1.If your organization does not have a standard Software Requirements Specifications document
template, create one now. Please see the Resources section below for some links to templates I found
on the internet.

2.Meet with the subject matter experts / clients to gather the requirements.

3.Define the functions of the software.

4.Create use cases for the major sub processes. For example, if you are designing an order entry system.
Use cases would consist of creating a new order, modifying an existing order, customer order search,
etc.

5.Define the user interface.

6.Define any other interfaces such as hardware interfaces or other software system interfaces.

7.Define the process flow.

8.Determine any specific business rules.

9. Define the performance specification.

10.Create any diagrams needed to illustrate process flow or elaborate on key requirements.

11.Compile the SRS document and have all necessary parties review or sign off on it.

Tips & Warnings

 Create a standard document template

 Include a traceability matrix
 Include a linkage between requirements and the source of those requirements
 Clearly list defined business operation rules
 Ensure the rules and processes are defined with precise, unambiguous language
 The SRS only contains functional requirements only - no software design or implementation
details should be included

Read more: How to Write a Software Requirements Specifications (SRS) Document | eHow.com
http://www.ehow.com/how_4804549_software-requirements-specifications-srs-
document.html#ixzz18C2q2gRb
UML Class Diagrams: Guidelines
Visual Studio 2010

In Visual Studio Ultimate, you can use a UML class diagram to describe data types and their
relationships separately from their implementation. The diagram is used to focus on the logical
aspects of the classes, instead of their implementation. To create a UML class diagram, on the
Architecture menu, click New Diagram.

Note
This topic is about UML class diagrams. There is another kind of class diagram, which you can
create and use to visualize program code. For more information, see Designing and Viewing
Classes and Types.
In This Topic

Using UML Class Diagrams

Basic Steps for Drawing Class Diagrams

Using Classes, Interfaces, and Enumerations

Attributes and Operations

Drawing and Using Associations

Inheritance

Template Types

Defining Namespaces with Packages

Using UML Class Diagrams

You can use a UML class diagram for a variety of purposes:

 To provide an implementation-independent description of the types that are used in a

system and passed between its components.

For example, the type Meal Order might be implemented in .NET code in the business
layer, in XML at the interfaces between components, in SQL in the database, and in
HTML in the user interface. Although these implementations are different in detail, the
relationship between a Meal Order and other types, such as Menu and Payment, is always
 the same. The UML class diagram makes it possible to discuss these relationships
separately from the implementations.

 To clarify the glossary of terms used for communication between the application and its
users, and in descriptions of the users' needs. For more information, see Modeling User
Requirements.

For example, consider the user stories, use cases or other requirements descriptions of a
restaurant application. In such a description, you would find terms like Menu, Order,
Meal, Price, Payment, and so on. You could draw a UML class diagram that defines the
relationships between these terms. This will reduce the risk of inconsistencies in the
requirements descriptions, and in the user interface, and in the help documents.

Relationship to Other Diagrams

A UML class diagram is usually drawn together with other modeling diagrams to provide
descriptions of the types that they use. In each case, the physical representation of the types is
not implied by any of the diagrams.

If you have
Use a UML class diagram to describe:
drawn:
Type of data passing through an Object Node.

Activity diagram Types of input and output pins, and of activity parameter nodes.

For more information, see UML Activity Diagrams: Guidelines.

Types of parameters and return values of messages.

Types of the lifelines. The class of a lifeline should include operations for all
Sequence diagram
the messages it can receive.

For more information, see UML Sequence Diagrams: Guidelines.

Component interfaces, listing their operations.
Component
You can also describe a complete component as a class.
diagram
For more information, see UML Component Diagrams: Guidelines.
Types mentioned in descriptions of the goals and steps of a use case.
Use case diagram
For more information, see UML Use Case Diagrams: Guidelines.
Basic Steps for Drawing Class Diagrams

For reference information about the elements on UML class diagrams, see UML Class Diagrams:
Reference.
 Note
Detailed steps for creating any of the modeling diagrams are described in How to: Edit a UML
Model and Diagrams.

To create a UML Class diagram

1. On the Architecture menu, click New Diagram.

2. Under Templates, click UML Class Diagram.
3. Name the diagram.
4. In Add to Modeling Project, select an existing modeling project in your solution, or
Create a New Modeling Project, and then click OK.

A new class diagram appears with the UML Class Diagram toolbox. The toolbox
contains the required elements and relations.

To draw a UML Class Diagram

1. To create a type, click the Class, Interface or Enumeration tool on the toolbox and then
click a blank part of the diagram.
2. To add attributes or operations to the types, or literals to an enumeration, click the
Attributes, Operations or Literals heading in the type, and press ENTER.

You can write a signature such as f(x:Boolean):Integer. For more information, see
Attributes and Operations.

To add several items quickly, press ENTER two times at the end of each item. You can
use the arrow keys to move up and down the list.

3. To expand or collapse a type, click the chevron icon at its upper-left. You can also
expand and collapse the Attributes and Operations section of a class or interface.
4. To draw associations, inheritance, or dependency links between the types, click the
appropriate relation tool, then the source type, and then the target type.
5. To create types in a package, create a package using the Package tool, and then create
new types and packages within the package. You can also use the copy command to copy
types, and paste them into a package.
6. Every diagram is a view on a model that is shared between other diagrams in the same
project. To see a tree view of the complete model, click View, point to Other Windows,
and then click UML Model Explorer.

Using Classes, Interfaces, and Enumerations

There are three standard kinds of classifier available on the toolbox. These are referred to as
types throughout this document.
  Use Classes (1) to represent data or object types for most purposes.
 Use Interfaces (2) in a context where you have to differentiate between pure interfaces
and concrete classes that have internal implementations. This difference is useful when
the purpose of the diagram is to describe a software implementation. It is less useful
when you are modeling passive data, or where you are defining concepts used to describe
the user requirements.
 Use an Enumeration (3) to represent a type that has a limited number of literal values, for
example Stop and Go.
o Add the literal values to the enumeration. Give each one a separate name.
o You can also provide a numeric value for each literal value, if you want. Right-
click the literal in the enumeration, click Properties, and then type a number in the
Value field in the Properties window.

Give each type a unique name.

Getting Types from Other Diagrams

You can make types from another diagram appear on your UML class diagram.

Other diagram
How to get types from the other diagram
type
UML Class You can make a class appear on more than one UML class diagram. When you
Diagram have created a class on one diagram, drag the class from UML Model Explorer
onto the other diagram.

This is useful if you want each diagram to focus on a particular group of

 relationships.

For example, you could show the associations between a Meal Order and the
restaurant Menu on one diagram, and the associations between Meal Order and
Payment on another diagram.
If you have defined components in a component diagram, you can drag a
Component
component from UML Model Explorer onto the class diagram. It will appear as a
Diagram
class. For more information, see UML Component Diagrams: Guidelines.
You can create classes and interfaces from lifelines in a sequence diagram, and
then drag the class from UML Model Explorer to a UML class diagram. Each
lifeline in a sequence diagram represents an instance of an object, component, or
UML Sequence actor.
Diagram
To create a class from a lifeline, right-click the lifeline and then click Create
Class or Create Interface. For more information, see UML Sequence Diagrams:
Guidelines.
Attributes and Operations

An attribute (4) is a named value that every instance of a type can have. Accessing an attribute
does not change the state of the instance.

An operation (5) is a method or function that instances of the type can perform. It can return a
value. If its isQuery property is true, it cannot change the state of the instance.

To add an attribute or operation to a type, right-click the type, point to Add, and then choose
Attribute or Operation.

To see its properties, right-click the attribute or operation and then click Properties. The
properties appear in the Properties window.

To see the properties of an operation's parameters, click […] in the Parameters property. A new
properties dialog box appears.

For detailed information about all the properties that you can set, see the following topics:

 Properties of Attributes in UML Class Diagrams

 Properties of Operations in UML Class Diagrams

Types of Attributes and Operations

Each Type of an attribute or operation, and each parameter type, can be one of the following:

 (none) - You can leave a type unspecified in the signature by omitting the preceding
colon (:).
  One of the standard primitive types: Boolean, Integer, String.
 A type that is defined in your model.
 A parameterized value of a template type, written Template<Parameter>. See Template
Types.

You can also write the name of a type that you have not yet defined in your model. The name
will be listed under Unspecified Types in UML Model Explorer.

Note
If you subsequently define a class or interface of that name in your model, the older attributes and
operations will still refer to the element in Unspecified Types. If you want to change them to refer
to the new class, you must visit each attribute or operation and reset the type, selecting the new
class from the drop-down menu.

Multiple Types

You can set a multiplicity of any attribute, operation, or parameter type.

The allowed values are as follows:

Multiplicity The attribute, parameter, or return value contains:

[1] One value of the given type. This is the default.
[0..1] Null or a value of the given type.
[*] A collection of any number of instances of the given type.
[1..*] A collection of at least one instance of the given type.
[n..m] A collection of between n and m instances of the given type.

If the multiplicity is more than 1, you can also set these properties:

 IsOrdered - If true, the collection has a defined order.

 IsUnique - If true, there are no duplicate values in the collection.

Visibility

Visibility indicates whether the attribute or operation can be accessed outside the class definition.
The allowed values are as follows:

Short
Name Meaning
form
Public + Accessible from all other types.
Private - Accessible only to the internal definition of this type.
Accessible only within the package that contains this type, and in any
Package ~
packages that explicitly import it. See Defining Namespaces and Packages.
Protected # Accessible only to this type and types that inherit from it. See Inheritance.
Setting the Signature of an Attribute or an Operation

The signature of an attribute or an operation is a collection of properties that includes its

visibility, name, parameters (for operations), and type.

You can write a signature directly in the diagram. Click the attribute or operation to select it, and
then click it again.

Write the signature in the form:

Copy
visibility attribute-name : Type

- or -

Copy
visibility operation-name (parameter1 : Type1, ...) : Type

For example:

Copy
+ AddItem (item : MenuItem, quantity : Integer) : Boolean

Use the short form of visibility. The default value is + (public).

Each type can be types that you have defined in the model, standard types such as Integer or
String, or the name of a new type that you have not defined yet.

Note
If you write a name without a type in a parameter list, it indicates the name of the parameter,
instead of its type. In this example, MenuItem and Integer become the names of two parameters
with unspecified types:

AddItem(MenuItem, Integer) /* parameter names, not types! */

To set the multiplicity of a type in a signature, write the multiplicity in square brackets following
the type name, for example:

Copy
+ AddItems (items : MenuItem [1..*])
+ MenuContent : MenuItem [*]

If the attribute or operation is static, its name will appear underlined in the signature. If it is
abstract, the name will appear in italic font.

However, you can only set the Is Static and Is Abstract properties in the Properties window.
Full Signature

When you edit the signature of an attribute or operation, some additional properties might appear
at the end of the line, and after each parameter. They appear enclosed in braces {…}. You can
edit or add these properties. For example:

Copy
+ AddItems (items: MenuItem [1..*] {unique, ordered})
+ GetItems (filter: String) : MenuItem [*] {ordered, query}

These properties are as follows:

In
Property Meaning
signature
There are no duplicate values in the collection. Applies to types with
unique Is Unique
multiplicity greater than 1.
Is The collection is a sequence. If false, there is no definite first item.
ordered
Ordered Applies to types with multiplicity greater than 1.
The operation does not change the state of its instance. Applies only to
query Is Query
operations.
The attribute is computed from values of other attributes or associations.

/ Is Derived "/" appears before the name of an attribute. For example:

Copy
/TotalPrice: Integer

Usually the full signature appears on the diagram only while you are editing it. When you finish
editing, the additional properties are hidden. If you want to see the full signature all the time,
right-click the type and then click Show Full Signature.

Drawing and Using Associations

Use an association to represent any kind of linkage between two elements, regardless of how the
linkage is implemented in the software. For example, you could use an association to represent a
pointer in C#, a relation in a database, or a cross reference from one part of an XML file to
another. It can represent an association between objects in the real world, such as the earth and
the sun. The association does not say how the link is represented, only that the information
exists.

Properties of an Association

After you have created an association, set its properties. Right-click the association and then
click Properties.
In addition to the properties of the association as a whole, each role, that is, each end of the
association, has some properties of its own. To view them, expand the First Role and Second
Role properties.

Some properties of each role are directly visible on the diagram. They are as follows:

 Role name. This appears at the appropriate end of the association on the diagram. You
can set it either on the diagram or in the Properties window.
 Multiplicity, which defaults to 1. This also appears on the diagram near the appropriate
end of the association.
 Aggregation. This appears as a diamond shape at one end of the connector. You can use it
to indicate that instances at the aggregating role own or contain instances of the other.
 Is Navigable. If true for only one role, an arrow appears in the navigable direction. You
can use this to indicate navigability of links and database relations in the software.

For the full details of these and other properties, see Properties of Associations in UML Class
Diagrams.

Attributes and Associations

An association is a pictorial way of showing an attribute. For example, instead of creating a class
Restaurant with an attribute of type Menu, you can draw an association from Restaurant to
Menu.

Each attribute name becomes a role name. It appears at the opposite end of the association from
the owning type. Look, for example, at myMenu in the illustration.

Generally, it is better to use attributes only for types that you would not draw on the diagram,
such as primitive types.

Inheritance
Use the Inheritance tool to create the following relationships:

 A generalization relationship between a specialized type and a general type

- or -

 A realization relation between a class and an interface that it implements.

You cannot create loops in inheritance relationships.

Generalization

Generalization means that the specializing or derived type inherits attributes, operations, and
associations of the general or base type.

The general type appears at the arrowhead end of the relationship.

The inherited operations and attributes are not typically shown in the specializing types. But you
can add inherited operations to the specializing type's operations list. This is useful if you want to
override some of an operation's properties in the specializing type, or if you want to indicate that
the implementing code should do so.

To override an operation's definition in a specializing type

1. Click the generalization relation.

It appears highlighted, and a Action tag appears near to it.

2. Click the Action tag, and then click Override Operations.

The Override Operations dialog box appears.

3. Select the operations that you want to appear in the specializing type, and then click OK.

The operations that you selected now appear in the specializing type.

Realization

Realization means that a class implements the attributes and operations specified by the
interface. The interface is at the arrow end of the connector.

When you create a realization connector, the operations of the interface are automatically
replicated in the realizing class. If you add new operations to an interface, they are replicated in
its realizing classes.
After you have created a realization relationship, you can convert it to lollipop notation. Right-
click the relationship and choose Show as Lollipop.

This lets you show the interfaces that a class implements, without cluttering the class diagrams
with realization links. You can also show the interface and the classes that realize it on separate
diagrams.

Template Types

You can define a generic or template type that can be parameterized by other types or values.

For example, you can create a generic Dictionary parameterized by key and value types:

To create a template type

1. Create a class or interface. This will become your template type. Name it accordingly, for
example, Dictionary.
2. Right-click the new type and then click Properties.
3. In the Properties window, click […] in the Template Parameters field.

The Template Parameter Collection Editor dialog box appears.

4. Click Add.
5. Set the name property to a parameter name for your template type, for example, Key.
6. Set Parameter Kind. The default is Class.
7. If you want the parameter to accept only derived classes of a particular base class, set
Constrained Value to the base class that you want.
8. Add as many parameters as you need, then click OK.
 9. Add attributes and operations to the template type as you would do for other classes.

You can use parameters whose kind is Class, Interface or Enumeration in the definition
of attributes and operations. For example, by using parameter classes Key and Value, you
could define this operation in Dictionary:

Get(k : Key) : Value

You can use a parameter whose kind is Integer as a bound in a multiplicity. For example,
a parameter integer max could be used to define the multiplicity of an attribute as
[0..max].

When you have created template types, you can use them to define template bindings:

To use a template type

1. Create a new type, for example, AddressTable.

2. Right-click the new type and then click Properties.
3. In the Template Binding property, select the template type, for example Dictionary, from
the drop-down list.
4. Expand the Template Binding property.

A row appears for each parameter of the template type.

5. Set each parameter to a suitable value. For example, set the Key parameter to a class
called Name.

Packages

You can view packages in a UML class diagram. A package is a container for other model
elements. You can create any element inside a package. On the diagram, the elements inside the
package will move around when you move the package.

You can use the collapse/expand control to hide or show the contents of the package.

For more information, see Defining Packages and Namespaces.

See Also
Reference

UML Sequence Diagrams: Reference

Concepts

How to: Edit a UML Model and Diagrams

UML Class Diagrams: Reference
Modeling User Requirements
UML Component Diagrams: Reference
UML Use Case Diagrams: Reference
UML Component Diagrams: Reference

UML Component Diagrams: Reference

Visual Studio 2010
In Visual Studio Ultimate, a component diagram shows the parts of a design for a software
system. A component diagram helps you visualize the high-level structure of the system and the
service behavior that those pieces provide and consume through interfaces. To create a UML
component diagram, on the Architecture menu, click New Diagram.

You can use a component diagram to describe a design that is implemented in any language or
style. It is only necessary to identify parts of the design that interact with the other parts of the
design through a restricted set of inputs and outputs. The components can be of any scale, and
can be interconnected in any manner.

For more information about how to use component diagrams in the process of design, see
Modeling the Architecture of a Software System.

Note
This topic describes the elements that you can use in Component diagrams. For more detailed in
information about how to draw Component diagrams see UML Component Diagrams:
Guidelines. For more information about how to draw modeling diagrams in general, see How to:
Edit a UML Model and Diagrams.
Reading Component Diagrams

The following table describes the elements that you can use on a component diagram, together
with their main properties. For a full list of the properties of the elements, see Properties of
Elements in Component Diagrams.
Shape Element Description and Main Properties
A reusable piece of system functionality. A component provides and
consumes behavior through interfaces, and can use other
components.

You can hide or show the internal parts of a component using the
expand/collapse control (9).
1 Component
A component is a kind of class.

 Is Indirectly Instantiated. If true (default), the component

exists only as a design artifact. At run time, only its parts
exist.

Represents a group messages or calls that a component implements

Provided Interface
2 and that other components or external systems can use. A port is a
Port
property of a component that has an interface as its type.
Represents a group of messages or calls that the component sends to
Required Interface other components or external systems. The component is designed to
3
Port be coupled to components that provide at least these operations. The
port has an interface as its type.
4 Dependency Can be used to indicate that a Required Interface on one component
 can be satisfied by a Provided Interface on another.

Dependencies can also be used more generally between model

elements, to show that the design of one depends on the design of the
other.
An attribute of a component, whose type is a usually another
component. A part is used in the internal design of its parent
component. Parts are shown graphically, nested within the parent
component.

To create a Part of an existing component type, drag the component

from UML Model Explorer onto the owner component.

To create a Part of a new type, click the Component tool and then
click the owner component.

For example, a component Car has parts engine:CarEngine,

5 Part backLeft:Wheel, frontRight:Wheel, and so on.

More than one part can have the same type, and different components
can have parts of the same type.

 Type. The type of the part, which is defined elsewhere in the

model. Typically, the type is another component.
 Multiplicity. Defaults to 1. You can set it to 0..1 to indicate
that the part can have the value null, * to indicate that the part
is a collection of instances of the given type, or to any
expression that can be evaluated to a range of numbers.

A connection between the required interface ports of one part and the
provided interface ports of another. The implementation of a part
6 Part Assembly
assembly can vary from one component to another. The connected
parts must have the same parent component.
Links a port to an interface of one of the component's parts. Indicates
7 Delegation that messages sent to the component are dealt with by the part, or that
messages sent from the part are sent out from the parent component.
Indicates that one component inherits from another component. Parts
8 Generalization
and interfaces are inherited.
Collapse/Expand
9 Use this to hide or show a component's internal parts.
control
(not For additional notes. You can link a comment to any number of
Comment
shown) elements on the diagram by using the Connector tool.
See Also
Reference

UML Sequence Diagrams: Reference

Concepts

How to: Edit a UML Model and Diagrams

UML Component Diagrams: Guidelines
Validating Your System During Development
UML Use Case Diagrams: Reference
UML Class Diagrams: Reference
UML Activity Diagrams: Reference
Modeling the Architecture of a Software
System
Visual Studio 2010

To help ensure that your software system or application meets your users' needs, you can create
models in Visual Studio Ultimate as part of your description of the overall structure and behavior
of your software system or application. Using models, you can also describe patterns that are
used throughout the design. These models help you understand the existing architecture, discuss
changes, and communicate your intentions clearly.

The purpose of a model is to reduce the ambiguities that occur in natural-language descriptions,
and to help you and your colleagues to visualize the design and to discuss alternative designs. A
model should be used together with other documents or discussions. By itself, a model does not
represent a complete specification of the architecture.

Note
Throughout this topic, "system" means the software that you are developing. It might be a large
collection of many software and hardware components, or a single application, or a part of an
application.

The architecture of a system can be divided into two areas:

 High-level Design. This describes the major components and how they interact with one
another to fulfill each requirement. If the system is large, each component might have its
own high-level design that shows how it is composed of smaller components.
 Design Patterns and conventions used throughout the designs of the components. A
pattern describes a particular approach to achieving a programming goal. By using the
same patterns throughout a design, your team can reduce the cost of making changes and
developing new software.

High-level Design

A high-level design describes the major components of your system and how they interact with
one another to achieve the goals of the design. The activities in the following list are involved in
developing the high level design, although not necessarily in a particular sequence.

If you are updating existing code, you might begin by describing the major components. Make
sure you understand any changes to the user requirements and then add or modify interactions
between the components. If you are developing a new system, begin by understanding the main
features of the users' needs. You can then explore sequences of interactions for the main use
cases, and then consolidate the sequences into a component design.
In every case, it is helpful to develop the different activities in parallel, and to develop code and
tests at an early stage. Avoid trying to complete one of these aspects before you start another.
Typically, both the requirements and your understanding of the best way to design the system
will change while you are writing and testing the code. Therefore, you should begin by
understanding and coding the main features of the requirements and your design. Fill in the
details in later iterations of the project.

 Understanding the Requirements. The starting point of any design is a clear

understanding of the users' needs.
 Architectural Patterns. The choices you made about core technologies and architectural
elements of the system.
 Components and their Interfaces. You can draw component diagrams to show the major
parts of the system, and show the interfaces through which they interact with one another.
The interfaces of each component include all the messages that you identified in the
sequence diagrams.
 Interactions between Components. For each use case, event, or incoming message, you
can draw a sequence diagram that shows how the major components of the system
interact to achieve the required response.
 Data Model of the Components and Interfaces. You can draw class diagrams to describe
the information that is passed between components and stored inside the components.

Understanding the Requirements

The high-level design of a complete application is most effectively developed together with a
requirements model or other description of the users' needs. For more information about
requirements models, see Modeling User Requirements.

If the system that you are developing is a component in a larger system, part or all of your
requirements might be embodied in programmatic interfaces.

The requirements model provides these essential pieces of information:

 Provided interfaces. A provided interface lists the services or operations that the system
or component must provide to its users, whether they are human users or other software
components.
 Required interfaces. A required interface lists the services or operations that the system or
component can use. In some cases, you will be able to design all these services as part of
your own system. In other cases, especially if you are designing a component that can be
combined with other components in many configurations, the required interface will be
set by external considerations.
 Quality of service requirements. The performance, security, robustness, and other goals
and constraints that the system must meet.

The requirements model is written from the point of view of your system's users, whether they
are people or other software components. They know nothing of the internal workings of your
system. By contrast, your goal in an architectural model is to describe the internal workings and
show how they meet the users' needs.

Keeping the requirements and architectural models separate is useful because it makes it easier to
discuss the requirements with the users. It also helps you refactor the design and consider
alternative architectures while keeping the requirements unchanged.

You can separate the requirements and architectural models in two alternative ways:

 Keep them in the same solution but different projects. They will appear as separate
models in UML Model Explorer. Different team members can work in parallel on the
models. Limited kinds of tracing can be created between the models.
 Put them in the same UML model, but in different packages. This makes it easier to trace
dependencies between the models, but prevents more than one person at a time from
working on the model. Additionally, a very large model will take longer to load into
Visual Studio. This approach is therefore less suitable for large projects.

The amount of detail that you should put into either a requirements or an architectural model
depends on the scale of the project and the size and distribution of the team. A small team on a
short project might go no further than sketching a class diagram of the business concepts and
some design patterns; a large project distributed over more than one country would need
significantly more detail.

Architectural Patterns

Early in a development, you have to choose the major technologies and elements on which the
design depends. The areas in which these choices must be made include the following:

 Base technology choices, such as the choice between a database and a file system, and
the choice between a networked application and a Web client, and so on.
 Frameworks choices, such as a choice between Windows Workflow Foundation or
ADO.NET Entity Framework.
 Integration method choices, for example between an enterprise service bus or a point-to-
point channel.

These choices are frequently determined by quality of service requirements such as scale and
flexibility, and can be made before the detailed requirements are known. In a large system, the
configuration of hardware and software are strongly interrelated.

The selections that you make affect how you use and interpret the architectural model. For
example, in a system that uses a database, associations in a class diagram might represent
relations or foreign keys in the database, whereas in a system that is based on XML files,
associations might indicate cross-references that use XPath. In a distributed system, messages in
a sequence diagram can represent messages on a wire; in a self-contained application, they can
represent function calls.
Components and their Interfaces

The major recommendations of this section are as follows:

 Create component diagrams to show the major parts of your system.

 Draw dependencies between the components or their interfaces to show the structure of
the system.
 Use interfaces on the components to show the services that each component provides or
requires.
 In a large design, you can draw separate diagrams to decompose each component into
smaller parts.

These points are elaborated in the rest of this section.

Components

The central views of an architecture model are the component diagrams that show the major
parts of the system and how they depend on one another. For more information about component
diagrams, see UML Component Diagrams: Reference.

A typical component diagram for a large system might include components like these:
  Presentation. The component that provides access to the user, typically running on a Web
browser.
 Web service components. Provides connection between clients and servers.
 Use case controllers. Conduct the user through the steps of each scenario.
 Business core. Contains classes that are based on classes in the requirements model,
implements the key operations, and imposes business constraints.
 Database. Stores the business objects.
 Logging and error handling components.

Dependencies between Components

In addition to the components themselves, you can show the dependencies between them. A
dependency arrow between two components shows that changes in the design of one could affect
the design of the other. This usually happens because one component uses the services or
functions that are provided by the other component, either directly or indirectly.

A well-structured architecture has a clear arrangement of dependencies, in which these

conditions are true:

 There are no loops in the dependency graph.

 The components can be arranged into layers in which every dependency goes from a
component in one layer to a component in the next. All the dependencies between any
two layers go in the same direction.

You can show dependencies directly between components, or you can show dependencies
between required and provided interfaces that are attached to the components. By using
interfaces, you can define what operations are used in each dependency. Typically, dependencies
are shown between components when the diagrams are first drawn, and then replaced by
dependencies between interfaces as more information is added. Both versions are correct
descriptions of the software, but the version with interfaces provides more detail than the earlier
version.

Managing dependencies is most important for the production of maintainable software. The
component diagrams should reflect all the dependencies in your code. If the code already exists,
make sure that all the dependencies are shown in the diagrams. If the code is being developed,
make sure that it does not include dependencies that are not planned in the component diagram.
To help you discover dependencies in the code, you can generate layer diagrams. To help you
ensure that your planned dependency constraints are met, you can validate the code against layer
diagrams. For more information, see Layer Diagrams: Reference.

Interfaces

By placing interfaces on your components, you can separate and name the major groups of
operations that are provided by each component. For example, components in a web-based sales
system might have an interface through which customers buy goods, an interface through which
suppliers update their catalogs, and a third interface through which the system is managed.
A component can have any number of provided and required interfaces. Provided interfaces
show services that the component provides for other components to use. Required interfaces
show services that the component uses in other components.

If you define both provided and required interfaces, this helps you separate the component
cleanly from the rest of the design, so that you can use these techniques:

 Place the component into a test harness in which the surrounding components are
simulated by the test harness.
 Develop your component independently of the other components.
 Reuse the component in other contexts by coupling its interfaces to different components.

When you want to define the list of operations in an interface, you can create another view of the
interface on a UML class diagram. To do this, locate the interface in UML Model Explorer, and
drag it onto a class diagram. You can then add operations to the interface.

An operation in a UML interface can represent any way in which a behavior of a component can
be invoked. It might represent a Web service request, a signal or interaction of some other kind,
or an ordinary program function call.

To determine what operations to add, create sequence diagrams to show how the components
interact with one another. See Interactions between Components. Each of these sequence
diagrams shows the interactions that occur in a different use case. In this manner, you can
gradually add to the list of operations in each component's interface, as you explore the use
cases.

Decomposing a Component into Parts

You can apply the procedure that is described in the preceding sections to each component.

Within each component, you can show its sub-components as Parts. A Part is effectively an
attribute of its parent component, which is a kind of class. Each Part has its own type, which can
be a component. You can place this component on a diagram and show its parts. For more
information, see UML Component Diagrams: Guidelines.

It is useful to apply this technique to the whole system. Draw it as a single component, and show
its major components as parts. This helps you identify clearly the interfaces of your system with
the external world.

When your design for a component uses another component, you frequently have a choice about
whether to represent it as a part or as a separate component that you access through a Requires
Interface.

Use Parts in the following situations:

  The design of the parent component must always use the Part's component type.
Therefore, the design of the part is integral to the design of the parent component.
 The parent component has no concrete existence of its own. For example, you could have
a conceptual component called Presentation Layer that represents a collection of real
components that handle views and user interactions.

Use separate components accessed through required interfaces in these situations:

 The requiring component can be coupled through its interfaces to different providing
components at run time.
 The design is such that it would be easy to replace one provider with another.

The use of required interfaces is usually preferable to the use of parts. Although the design can
take longer, the resulting system is more flexible. It is also easier to test the components
separately. This allows less coupling in their development plans.

Interactions between Components

The major recommendations of this section are as follows:

 Identify the use cases of your system.

 For each use case, draw one or more diagrams to show how the components of your
system achieve the required outcome by collaborating with one another and with the
users. Usually, these are sequence diagrams or activity diagrams.
 Use Interfaces to specify the messages received by each component.
 Describe the effects of the Operations in the Interfaces.
 Repeat the procedure for each component, showing how its parts interact.

For example, in a web-based sales system, the requirements model might define a customer
purchase as a use case. You can create a sequence diagram to show the interactions that the
customer has with the components in the presentation layer, and to show the interactions that
they have with the warehouse and accounting components.

Identifying the initiating events

The work done by most software systems can be conveniently divided up by the responses it
gives to different inputs or events. The initiating event might be one of the following events:

 The first action in a use case. It might appear in the requirements model as a step in a use
case, or an action in an activity diagram. For more information, UML Use Case
Diagrams: Guidelines and UML Activity Diagrams: Guidelines.
 A message at a programmatic interface. If the system that you are developing is a
component in a larger system, it should be described as an operation in one of the
component's interfaces. See Components and their Interfaces.
  A particular condition that is monitored by your system, or a regular event such as a time
of day.

Describe the computations

Draw sequence diagrams to show how the components respond to the initial event.

Draw a lifeline for each component instance that takes part in a typical sequence. In some cases,
there might be more than one instance of each type. If you have described your whole system as
a single component, there should be one lifeline for each Part that it contains.

For more information, see UML Sequence Diagrams: Guidelines.

Activity diagrams are also useful in some cases. For example, if your components have a
continuous flow of data, you can describe it as an object flow. If your component has a complex
algorithm, you can describe it as a control flow. Make sure that you make it clear which
component performs each action, for example by using comments. For more information, see
UML Activity Diagrams: Guidelines.

Specify the operations

The diagrams show operations that are performed by each component, represented either as
messages on a sequence diagram, or actions in an activity diagram.

Collect these operations together for each component. Create Provided Interfaces on the
component, and add the operations to the interfaces. Typically, a separate interface is used for
each type of client. The operations are most easily added to the interfaces in UML Model
Explorer. In the same manner, collect the operations that each component uses from the other
components, and place them in Required Interfaces attached to the component.

It is useful to add comments to the activity or sequence diagrams, to note what has been achieved
after each operation. You can also write the effect of each operation in its Local Postcondition
property.

Data Model of the Components and Interfaces

Define the parameters and return values of each operation in the component interfaces. Where
the operations represent invocations such as Web service requests, the parameters are those
pieces of information that are sent as part of the request. Where several values are returned from
an operation, you can use parameters with the Direction property set to Out.

Each parameter and return value has a type. You can define these types using UML Class
Diagrams. You do not have to represent implementation detail in these diagrams. For example, if
you are describing data that is transmitted as XML, you can use an association to represent any
kind of cross-reference between nodes of the XML, and use classes to represent nodes.
Use comments to describe business constraints on the associations and attributes. For example, if
all the items on a customer's order must come from the same supplier, you can describe this by
reference to the associations between the order items and the items on the product catalog, and
between the catalog item and its supplier.

Design Patterns

A design pattern is an outline of how to design a particular aspect of the software, especially one
that recurs in different parts of the system. By adopting a uniform approach across the project,
you can reduce the cost of design, ensure consistency in the user interface, and reduce the cost of
understanding and changing the code.

Some general design patterns such as Observer are well-known and widely applicable. In
addition, there are patterns that are applicable just to your project. For example, in a Web sales
system, there will be several operations in the code where changes are made to a customer's
order. To ensure that the state of the order is accurately displayed at every stage, all these
operations must follow a particular protocol to update the database.

Part of the work of software architecture is to determine what patterns should be adopted across
the design. This is usually an ongoing task, because new patterns and improvements to existing
patterns will be discovered as the project progresses. It is helpful to organize the development
plan so that you exercise each of your major design patterns at an early stage.

Most design patterns can be partly embodied in framework code. Part of the pattern can be
reduced to requiring the developer to use particular classes or components, such as a database
access layer that ensures the database is handled correctly.

A design pattern is described in a document, and typically includes these parts:

 Name.
 Description of the context in which it is applicable. What criteria should make a
developer consider applying this pattern?
 Brief explanation of the problem it solves.
 Model of the major parts and their relationships. These might be classes or components
and interfaces, with associations and dependencies between them. The elements usually
fall into two categories:
o Elements that the developer must replicate in every part of the code where the
pattern is used. You can use template types to describe these. For more
information, see UML Use Case Diagrams: Reference.
o Elements describing framework classes that the developer should use.
 Model of the interactions between the parts, using sequence or activity diagrams.
 Naming conventions.
 Description of how the pattern solves the problem.
 Description of variations that developers might be able to adopt.
See Also

Concepts

How to: Edit a UML Model and Diagrams

Visualizing Existing Code
Modeling User Requirements
Developing Tests from a Model
Using Models within the Development Process
Modeling User Requirements
Visual Studio 2010

Microsoft Visual Studio Ultimate helps you understand, discuss, and communicate your users'
needs by drawing diagrams about their activities and the part your system plays in helping them
achieve their goals. A requirements model is a set of these diagrams, each of which focuses on a
different aspect of the users' needs.

A requirements model helps you:

 Focus on the system's external behavior, separately from its internal design.
 Describe the users' and stakeholders' needs with much less ambiguity than you can in
natural language.
 Define a consistent glossary of terms that can be used by users, developers, and testers.
 Reduce gaps and inconsistencies in the requirements.
 Reduce the work needed to respond to requirements changes.
 Plan the order in which features will be developed.
 Use the models as a basis for system tests, making a clear relationship between the tests
and the requirements. When the requirements change, this relationship helps you update
the tests correctly. This makes sure that the system meets the new requirements.

A requirements model provides greatest benefit if you use it to focus discussions with the users
or their representatives, and revisit it at the beginning of each iteration. You do not have to
complete it in detail before writing code. A partially working application, even if very much
simplified, generally forms the most stimulating basis for discussion of the requirements with
users. The model is an effective way to summarize the results of those discussions. For more
information, see Using Models within the Development Process.

Note
Throughout these topics, "system" means the system or the application that you are developing. It
might be a large collection of many software and hardware components; or a single application;
or a software component inside a larger system. In every case, the requirements model describes
the behavior that is visible from outside your system, whether through a user interface or API.
Common Tasks

You can create several different views of the users' requirements. Each view provides a
particular type of information. When you create these views, it is best to move frequently from
one to another. You can start from any view.

Diagram or
What it describes in a requirements model Section
document
 Describing how your
Use case diagram Who uses the system and what they do with it.
system is used
Glossary of types that are used to describe the
Conceptual class Defining terms used to
requirements; the types visible at the system's
diagram describe requirements
interface.
Flow of work and information between Showing work flow
Activity diagram activities performed by users and system or its between users and your
parts. system
Sequence of interactions between users and Showing interactions
Sequence diagram system or its parts. An alternative view to the between users and your
activity diagram. system
Additional
Performance, security, usability and reliability Describing quality of
documents or work
criteria. service requirements
items
Additional
Constraints and rules not specific to a particular
documents or work Showing business rules
use case
items

Notice that most of the diagram types can be used for other purposes. For an overview of
diagram types, see Developing Models for Software Design. For basic information about
drawing diagrams, see How to: Edit a UML Model and Diagrams.

Describing how your system is used

Create use case diagrams to describe who uses the system, and what they use it for. A use case
represents a goal of a user of the system, and the procedure they perform to achieve the goal.

As an example, an online meal selling system must allow customers to choose items from a
menu, and must allow the providing restaurants to update the menu. You can summarize this in a
use case diagram:

You can also show how a use case is composed of smaller cases. For example, ordering a meal is
part of buying a meal, which also includes payment and delivery:
You can also show which use cases are included in the scope of the system that you are
developing. For example, the system in the illustration does not take part in the Deliver Meal use
case. This helps set the context for the development work. (In a use case diagram, subsystem
containers can be used to represent the system or its components.)

It also helps your team discuss what will be included in successive releases. For example, you
could discuss whether, in the initial release of the system, Pay for Meal is arranged directly
between the restaurant and the customer, instead of going through the system. In that case, you
could move Pay for Meal outside the Dinner Now System rectangle for the initial release.

A use case diagram only provides a summary of the use cases. To provide more detailed
descriptions, you can link the use cases on the diagram to separate documents, and to other
diagrams. To learn how to do this, see How to: Link a Use Case to Documents and Diagrams.

Drawing a use case diagram helps your team:

 Focus on what the users expect to do with the system, without being distracted by details
of the implementation.
 Discuss the scope of your system or particular releases of the system.

The following topics provide more information:

To learn about Read

More detailed information about how to create use
UML Use Case Diagrams: Guidelines
cases
Elements on a use case diagram UML Use Case Diagrams: Reference
Modeling the Architecture of a Software
How to develop code from use cases
System
Defining Terms Used to Describe Requirements
You can use UML class diagrams to help you develop a consistent vocabulary of the business
concepts used for the following purposes:

 By the users themselves to discuss the business in which the system works.
 To describe the users' needs, for example in the descriptions of use cases, business rules,
and user stories.
 The types of information exchanged at the system's API or through the user interface.
 Descriptions of system or acceptance tests.

When they are used for this purpose, the content of a UML class diagram is called a conceptual
class diagram. (It is also known as a domain model or analysis class model.)

In a conceptual class diagram, you show just those classes needed in descriptions of the
requirements, without showing any of the detail of the system's internal design. The diagram
does not show any of the detail of the system's internal design. You would not usually show
operations or interfaces on conceptual classes.

For example, you could draw these conceptual classes for the Dinner Now system:

A conceptual class diagram provides the vocabulary of terms that you use throughout the
requirements model. For example, in the detailed description of the use case Order a Meal, you
might write:

The customer chooses a Menu from which to construct an Order, and then creates Order Items in
the Order by selecting Menu Items from the Menu.

Notice how the terms used in that description are the names of classes in the model. The diagram
removes ambiguities from relationships between those classes. For example, it shows clearly that
each Order is associated with just one Menu.
Misunderstandings about users' requirements can frequently be traced to misunderstandings
about the detailed meanings of words. For example, most restaurants will have a shared
understanding of the terms Menu and Order, but the difference between an item on an Order and
an item on a Menu is less clear. When the requirements are being discussed with the business
stakeholders, it is important to expose those differences. The class diagram is a useful tool to
help you clarify the terms and their relationships.

The conceptual class model can form the basic vocabulary by which your system's business logic
can be described. But the classes in the software will typically be much more complex than the
conceptual model, because your implementation must consider issues such as performance,
distribution, flexibility, and other factors. Several different implementations of a conceptual class
are frequently found in one system.

For example, Orders could be represented in XML, SQL, HTML, and C# in different parts of the
system and at different interfaces between the parts. The association between an Order and a
Menu could be represented in many different ways, such as references within C# code, relations
in a database, or cross-referenced IDs in XML. But despite these variations, the conceptual
model provides important information that is true in every part of the software. The class
diagram in the example tells us that in every implementation, there will be only one Menu
associated with each Order.

Drawing a requirements class diagram helps your team:

 Define and standardize the basic terms used in discussions of the users' needs.
 Clarify the relationships between those terms.

The following topics provide more information:

To learn about Read

More detailed information about finding requirements
UML Class Diagrams: Guidelines
classes
Elements on a conceptual class diagram UML Class Diagrams: Reference
Modeling the Architecture of a Software
How to develop code from conceptual classes
System
Showing Business Rules

A business rule is a requirement that is not associated with a particular use case, and should be
observed throughout the system.

Many business rules are constraints on the relationships among the conceptual classes. You can
write these static business rules as comments associated with the relevant classes on a conceptual
class diagram. For example:
Dynamic business rules constrain the allowable sequences of events. For example, you use a
sequence or activity diagram to show that a user must log in before performing other operations
on your system.

However, many dynamic rules can be more effectively and generically stated by replacing them
with static rules. For example, you could add a Boolean attribute 'Logged In' to a class in the
conceptual class model. You would add Logged In as the postcondition of the log in use case,
and add it as a precondition of most of the other use cases. This approach lets you avoid defining
all the possible combinations of sequences of events. It is also more flexible when you need to
add new use cases to the model.

Notice that the choice here is about how you define the requirements, and that this is independent
of how you implement the requirements in the program code.

The following topics provide more information:

To learn about Read

More detailed information about finding and recording
UML Class Diagrams: Guidelines
static business rules
Elements on a conceptual class diagram UML Class Diagrams: Reference
Modeling the Architecture of a
How to develop code that adheres to business rules
Software System
Describing Quality of Service Requirements

There are several categories of quality of service requirement. They include the following:

 Performance
 Security
 Usability
  Reliability
 Robustness

You can include some of these requirements in the descriptions of particular use cases. Other
requirements are not specific to use cases, and are most effectively written in a separate
document. When you can, it is useful to adhere to the vocabulary defined by the requirements
model. In the following example, notice that the main words used in the requirement are the titles
of actors, use cases, and classes in the preceding illustrations:

If a Restaurant deletes a Menu Item while a Customer is Ordering a Meal, any Order Item that
refers to that Menu Item will be displayed in red.

The following topics provide more information:

To learn about Read

More detailed information about recording quality of Guidelines for Defining Quality of Service
service requirements Requirements
How to: Link a Use Case to Documents
Attaching additional documents to use cases
and Diagrams
How to develop code that adheres to quality of Modeling the Architecture of a Software
service requirements System
Showing work flow between users and your system

You can use an activity diagram to show the flow of work between different use cases. It is
frequently useful to begin a requirements model by drawing an activity diagram showing the
major tasks that users perform - both with the system and outside it.

For example:
You can draw use case diagrams and activity diagrams to show different views of the same
information. The use case diagram is more effective at showing the nesting of the smaller actions
within the larger activity, but does not show the flow of work. For example:

Notice that you can also use activity diagrams to depict algorithms within your software, but
when you use the diagrams for the business process, you focus on the actions that are visible
outside the system.

The following topics provide more information:

To learn about Read

More information about how to define business work
UML Activity Diagrams: Guidelines
flows
Elements on an activity diagram UML Activity Diagrams: Reference
Modeling the Architecture of a Software
How to develop code from activity diagrams
System
Showing interactions between users and your system

You can use a sequence diagram to show the interchange of messages between your system and
external actors, or between parts of your system. This provides a view of the steps in a use case
that shows very clearly the sequence of interactions. Sequence diagrams are especially useful
where there are several interacting parties in a use case, and also where your system has an API.

For example:
One advantage of sequence diagrams is that it is easy to see what messages come in to the
system that you are constructing. To design the system, you can replace the single System
lifeline with a separate lifeline for each of its components, and then show the interactions
between them in response to each incoming message.

The following topics provide more information:

To learn about Read

More information about how to define
UML Sequence Diagrams: Guidelines
interactions
Elements on an sequence diagram UML Sequence Diagrams: Reference
Modeling the Architecture of a Software
How to develop code from sequence diagrams
System
Using a Model to Reduce Inconsistencies

Creating a model usually results in a significant reduction in inconsistencies and ambiguities in

the users' requirements. Different stakeholders frequently have different understandings of the
business world in which the system works. Therefore your first task is to resolve these
differences between your clients.

You will find that many questions about the business domain arise naturally while you are
creating a model. By putting these questions to your users, you will reduce the need for changes
at a later stage in the project. Here are some specific questions that you can ask yourself at first,
and then ask the business stakeholders if the answer is unclear:

 For each class in the requirements model, ask "What use case creates instances of this
class?" For example, in an online meal-ordering service, you might ask, "What use case
creates instances of the Restaurant Menu class?" This would lead to a discussion of how a
new restaurant is signed up to the service and contributes its menu. You can ask similar
questions about what creates or changes attributes and associations.
 For each use case in the requirements model, try to describe the outcome, or
postcondition, of each use case in words provided by the class diagrams. It is frequently
useful to show the effect of a use case by sketching instances of the classes before and
after an occurrence of the use case. For example, if the use case postcondition says "a
menu item is added to the customer's order," sketch instances of the Order and Menu
Item classes. Show the effects of the use case, such as a new link or a new object, in a
different color or in a new drawing. This frequently leads to discussions about what
information is necessary in the model. Although requirements classes are not directly
concerned with implementation, they do describe the information that your system will
need to store and transmit.
 Ask about the constraints on attributes and associations, especially constraints involving
more than one attribute or association.
 Ask about valid and invalid sequences of use cases, drawing sequence or activity
diagrams to illustrate them.

By examining the relationships between the views that different diagrams provide, you can
quickly understand the main concepts with which your users work, and help them to understand
what they need from the system. You also reach a better understanding of what requirements the
stakeholders are least certain about. You can plan to develop those features, at least in simplified
form, at an early stage of the project, to allow users to experiment with them.

See Also

Concepts

How to: Edit a UML Model and Diagrams

Developing Tests from a Model
Using Models within the Development Process
Modeling the Architecture of a Software System
UML Use Case Diagrams: Guidelines
Visual Studio 2010

In Visual Studio Ultimate, you can draw a use case diagram to summarize who uses your
application or system, and what they can do with it. To create a UML use case diagram, on the
Architecture menu, click New Diagram.

With the help of a use case diagram, you can discuss and communicate:

 The scenarios in which your system or application interacts with people, organizations, or
external systems.
 The goals that it helps those actors achieve.
 The scope of your system.

A use case diagram does not show the detail of the use cases: it only summarizes some of the
relationships between use cases, actors, and systems. In particular, the diagram does not show the
order in which steps are performed to achieve the goals of each use case. You can describe those
details in other diagrams and documents, which you can link to each use case. For more
information, see Describing Use Cases in Detail in this topic.

The descriptions you provide for use cases will use several terms related to the domain in which
the system works, such as Sale, Menu, Customer, and so on. It is important to define these terms
and their relationships clearly, and you can do that with the help of a UML Class Diagram. For
more information, see UML Class Diagrams: Guidelines.

Use cases deal only in the functional requirements for a system. Other requirements such as
business rules, quality of service requirements, and implementation constraints must be
represented separately. Architecture and internal details must also be described separately. For
more information about how to define user requirements, see Modeling User Requirements.

The examples used in this topic relate to a Web site on which customers can order meals from
local restaurants.
  An actor (1) is a class of person, organization, device, or external software component
that interacts with your system. Example actors are Customer, Restaurant, Temperature
Sensor, Credit Card Authorizer.
 A use case (2) represents the actions that are performed by one or more actors in the
pursuit of a particular goal. Example use cases are Order Meal, Update Menu, Process
Payment.

On a use case diagram, use cases are associated (3) with the actors that perform them.

 Your system (4) is whatever you are developing. It might be a small software component,
whose actors are just other software components; or it might be a complete application;
or it might be a large distributed suite of applications deployed over many computers and
devices. Example subsystems are Meal Ordering Website, Meal Delivery Business,
Website Version 2.

A use case diagram can show which use cases are supported by your system or its
subsystems.

In This Topic

Basic Steps for Drawing Use Case Diagrams

Drawing Actors and Use Cases

Describing Use Cases in Detail

Structuring Use Cases

Using Subsystem Boundaries

Basic Steps for Drawing Use Case Diagrams

Note
Detailed steps for creating any of the modeling diagrams are described in How to: Edit a UML
Model and Diagrams.

To create a new use case diagram

1. On the Architecture menu, click New Diagram.

2. Under Templates, click UML Use Case Diagram.
3. Name the diagram.
4. In Add to Modeling Project, select an existing modeling project in your solution, or
Create a New Modeling Project, and then click OK.

To draw a use case diagram

1. Drag Subsystem boundaries from the toolbox onto the diagram, to represent either your
whole system or its major components.
o You can draw a use case diagram without system boundaries if you do not want to
describe which use cases are supported by your system or its components.
o Drag the corner of a system to make it bigger, if it is necessary.
o Rename it appropriately.
2. Drag Actors from the toolbox onto the diagram (placing them outside any system
boundary).
o Actors represent classes of users, organizations, and external systems that interact
with your system.
o Rename them. For example: Customer, Restaurant, Credit card agency.
3. Drag Use Cases from the toolbox onto the appropriate systems.
o Use cases represent the activities that actors perform with the help of your system.
o Rename them by using titles the actors themselves would understand. Do not use
titles that are related to your code. For example: Order Meal, Pay for Meal,
Deliver Meal.
o Begin with major transactions such as Order Meal, leaving until later smaller
interactions such as Select Menu Item.
o Place each use case in the system or major subsystem that supports it (ignoring
any façade or component involved only in connecting to the user).
o You can draw a use case outside the system boundary to show that it is not
supported by your system, perhaps in a particular version or release.
4. Click Association on the toolbox, then a use case, and then an actor that participates in
the use case. Link each actor to its use cases in this manner.
5. Structure the use cases with the Include, Extend and Generalization relationships. To
create each of these links, click the tool, then the source use case, then the target. See the
following section titled Structuring Use Cases.
6. Describe the use cases in more detail. See the following section titled Describing Use
Cases in Detail.
 7. Draw separate diagrams to focus on different subsystems or different groups of related
use cases. All the diagrams in one modeling project are views of the same model.

Drawing Actors and Use Cases

The main purpose of a use case diagram is to show who interacts with your system, and the main
goals they achieve with it.

 Create Actors to represent classes of people, organizations, other systems, software or

devices that interact with your system or subsystem.
o To learn how to draw actors and other elements, see How to: Edit a UML Model
and Diagrams.
o For each distinct set of goals, identify actors by their type or role, even though the
physical persons or entities might be the same. For example, Restaurant and
Customer are separate actors, even though a restaurant employee might
sometimes be a customer.
 Create Use Cases for each of the goals that each actor seeks to achieve with the system.
o Name and describe the use cases in words that the actor would understand, instead
of implementation terms.
 Use Associations to link actors to use cases.

Inheritance between Actors

You can draw a Generalization link between Actors. The specialized actor, such as Club
Customer in the example, inherits the use cases of the generalized actor, such as Customer. The
arrowhead should point at the more general actor, such as Customer. When you create the link,
point first at the more specialized actor.

The specialized actor can have its own additional use cases that are not available to the other
actors.

Caution
You should not make loops of generalization relationships that result in an actor generalizing
itself. Loops may generate errors.
Alternative Actor Icons

You can use custom icons to represent an actor, instead of the standard stick figure. For example,
you could change it to resemble a device, restaurant, bank, and so on.

To change the appearance of an actor

1. Right-click the actor and then click Properties.

The Properties window appears.

2. Set the Image Path property to the location of an image file.

o You can use any of several image formats, including .gif, .jpg, and .bmp.
o Use a file that is included in the solution or project source control so that it is still
available when the solution is moved or copied.
3. To replicate this appearance in other use case diagrams, copy the actor and paste it into
another diagram.
o The change of image applies only to the view in a particular diagram. It does not
apply to the underlying model element. If you drag the actor from UML Model
Explorer onto another diagram, it will appear as the standard stick figure.

Multiplicities between Actors and Use Cases

The association between an actor and a use case can show a multiplicity at each end.

Note
The multiplicities of an association on a use case diagram are hidden if they are both 1.

By default, each multiplicity is 1. In a strict interpretation of the model, a multiplicity of 1 means

that, for example, only one customer is involved in ordering each meal and that each customer
orders only one meal at a time.

You can change these multiplicities.

For example:
  To state that several actors of the same class can take part in a single occurrence of a use
case, set the multiplicity at the actor end of the association to 1..*.

In the illustration, one or more restaurants can take part in fulfilling the same meal order.

 To show that each actor can participate at the same time in several occurrences of a use
case, set the multiplicity at the use case end of the association to *.

In the illustration, each restaurant can work on fulfilling more than one order at a time.

To set multiplicities on an association

1. Right-click the association and then click Properties.

2. Expand either First Role or Second Role.

Role means the element at one end of the association.

3. Set the Multiplicity property, choosing from the list:

o 1 to state that exactly one instance of this role participates in each link.
o 1..* to state that one or more instance of this role participate in each link.
o 0..1 to state that participation is optional.
o * to state that zero or more instances of this role participate in the link.

Note
Many teams do not place multiplicity information on use case diagrams, leaving the multiplicities
at the default value of 1. Instead, they provide the information in separate descriptions of the use
cases. In this case, all the multiplicities in the use case diagrams will be hidden.

Using an actor or use case on multiple diagrams

You can show the same actors and use cases on several diagrams. For example:

 You can describe in different diagrams the different use cases in which one actor is
involved.
 You can use one diagram to show the actors and subsystems with which a use case is
associated, and use another diagram to show how the use case is structured into included
and extended use cases.
To show the same actor or use case on different diagrams

1. Create the actor or use case on one diagram.

2. Create another use case diagram.
3. Drag an actor or use case off Model Explorer onto the new diagram.

Note
If you place on the new diagram an actor and a use case that are already associated, the
association between them will automatically appear on the new diagram.
Describing use cases in detail

A use case represents:

 A goal of an actor in using the system, such as Buy a Meal; and

 One or more scenarios, that is, sequences of steps performed in pursuing the goal, such
as: {Order Meal, Pay, Deliver}. In addition to success scenarios, there might be several
exception or failure scenarios, such as Credit Card Rejected.

A use case can be described in different levels of detail. At an early stage of design, just the
name on the use case diagram is sufficient. Later, more detailed descriptions of the scenarios can
be written.

In Visual Studio Ultimate, you can describe a use case in several ways, which can be used
separately or together:

 Link the use case to another diagram or diagrams in the project.

o An activity diagram helps you explain a more complex process where there are
loops, branches and parallel threads. It can also show the flow of data between
parts of the process. For more information, see UML Activity Diagrams:
Guidelines.
o A sequence diagram helps you explain a complex series of interactions between
different actors. You can also use it to show what happens inside the system in
response to each use case. For more information, see UML Sequence Diagrams:
Guidelines.
 Link the use case to a OneNote page, section, or paragraph that describes the use case in
detail.
 Link the use case to a Word document, in which you use text, screen shots, and so on to
describe the use case's scenarios. For more information, see Modeling User
Requirements.

To link a use case to a diagram or file in the same solution

1. Draw a diagram such as a sequence diagram or activity diagram to illustrate a scenario of

the use case.
 2. Go back to the use case diagram.
3. Drag the diagram or file from Solution Explorer onto a blank part of the use case
diagram.
4. Connect from the artifact to the use case using a Dependency.

To link to a solution file such as a Word document or PowerPoint presentation

1. Write a document that uses text, screen shots, and so on to describe the scenario of the
use case.
2. Add the document to the solution.
1. Move the Word document into the same Windows folder as the solution.
2. In Solution Explorer, right-click the solution, point to Add, and then click
Existing Item.
3. Navigate to the Word document and click Add.

The Word document appears in a solution folder in Solution Explorer.

3. Drag the Word document from Solution Explorer onto a blank part of the use case
diagram.

A new Artifact appears.

4. Connect from the artifact to the use case using a Dependency.

To link to a shared document, OneNote element, or web page

1. Obtain the URL of the shared element. This can be, for example, a network file path
beginning '\\', or a web page or Sharepoint URL beginning 'http://', or a link to a OneNote
section, page, or paragraph beginning 'onenote:'.
2. In the Toolbox, click Artifact and then click in the use case diagram.
3. With the new artifact selected, type or paste the URL into the Hyperlink property.

Note
You can double-click an Artifact to open the diagram or document to which it links.

Linking use cases to work items

If your project uses Visual Studio Team Foundation Server 2010 and you have Team Explorer,
you can link each use case to a work item in Team Foundation. To learn how to make these
links, see How to: Link from Model Elements to Work Items.

This enables you to:

 Describe the use case in the linked work item. In particular, if your project uses the
Visual Studio Formal Process Template, you can link to a Use Case Work Item. This
work item type provides fields for describing the goals and scenarios of the use case.
  Link test cases to the use case so that you can obtain reports on how far the code being
developed implements the use case.
 Link tasks to the use case so that you can track the progress of development work.

Structuring Use Cases

You should try to describe your system's behavior with just a few major use cases. Each large
use case defines a major goal that an actor achieves, such as buying a product, or, from the
vendor's point of view, providing products for sale.

When you have made these goals clear, you can go into more detail about how the each goal is
achieved, and about variations in the basic goals.

Avoid decomposing the use cases into too much detail. Use cases are about the users' experience
of your system, instead of its internal workings. Additionally, you will generally find it more
productive to create early working versions of the code, instead of spending time structuring use
cases into fine detail.

You can summarize on a use case diagram the relationships between major and more detailed
use cases. The following sections describe this:

 Showing the details of a use case with Include

 Sharing goals with Generalization
 Separating out variant cases with Extend

Showing the details of a use case with Include

Use an Include relation to show that one use case describes some of the detail of another. In the
illustration, Order a Meal includes Pay, Choose Menu, and Choose Menu Item. Each of the
included, more detailed use cases is a step that the actor or actors might have to perform to
achieve the overall goal of the including use case. The arrow should point at the more detailed,
included use case.

Caution
You should not make loops of include relationships that result in a use case including itself.
Loops can generate errors.

You can share included use cases. In the example, the Order a Meal and Subscribe to Reviews
use cases both include Pay.
The goal and scenarios of an included use case should make sense independently so that it can be
included in use cases that are designed later.

Separating use cases into including and included parts is useful to achieve the following goals:

 Structure your use case descriptions into different layers of detail.

 Avoid repeating shared scenarios in different use cases.

Defining the order of the detailed steps

The use case diagram says nothing about the order in which the more detailed steps must be
performed, nor about whether each of them is always necessary.

To make the order of the steps clear, you can use an Artifact to attach a separate document to the
including use case. In the following example, an activity diagram attached to the Order a Meal
use case. Alternatively, you could use a text document that has a list of steps or a sequence of
screen shots. For more information, see Describing Use Cases in Detail.

Notice these naming conventions when you use an activity diagram:

 The name of the whole activity is the same as the including use case.
 The actions in the activity diagram have the same names as the included use cases.

For more information, see UML Activity Diagrams: Guidelines.

Sharing goals with Generalization

Use a Generalization relation to show that a specialized use case is a particular way to achieve
the goals expressed by another general use case. The open arrowhead should point at the more
general use case.

For example, Pay generalizes Pay by Credit Card and Pay by Cash.
 Caution
You should not make loops of generalization relationships, that result in an actor generalizing
itself. Loops might generate errors.

Specialized use cases can help you show different ways that your system can achieve the same
goal.

The specialized use cases are considered to inherit the goals and actors of the general use case.
The general use case does not have to have scenarios of its own; its specializations describe
different ways of achieving the goals.

To refactor common goals from two or more use cases

1. Create and name the new general use case.

2. Create a Generalization relation with the large arrow pointing at the new general use
case.
1. Click Generalization in the toolbox.
2. Click a specialized use case (Pay by Credit Card in the example).
3. Click the general use case (Pay in the example).
3. If you have described the goals for the specialized use cases, move the common parts into
the description of the general use case.
4. Actors that are shared between the specialized use cases can be moved to the general use
case.

Separating variant cases with Extend

Use an Extend link to show that one use case may add functionality to another use case under
certain circumstances. The arrow should point at the main, extended use case.

Caution
You should not make loops of extend relationships, that result in an actor generalizing itself.
Loops might generate errors.

For example, the Login use case of a typical Web site can include Register New User - but only
when the user does not already have an account.

To separate a use case into main and extending parts

1. Create and name the new extension use case.

2. Create an Extend relation with the arrow pointing at the extended use case.
1. Click Extend in the toolbox.
2. Click the extending use case (Register New User in the example).
 3. Click the extended use case (Login in the example).

Note
Avoid creating a loop of Extend relations in the diagram. It is incorrect for a use
case to be an extension of itself.

3. If you have already created scenarios for the extended use case, move the relevant steps
into the scenario of the extension.
4. The description of the extension (Register New User in the example) should include
details of where in the main use case scenarios it will occur, and under what
circumstances. Think of it as modifying the main case's description.

The extension use case represents scenario steps that would otherwise be part of the main use
case's scenarios. The scenario and goal of the extension will always be read in the context of the
main use case, therefore they do not have to be useful independently.

Separating out extensions can be useful to describe these situations:

 There are additional actors who are involved only in the extension use case. For example,
an administrator is required to approve a customer's registration on the Web site.
 A separate subsystem will deal with the extension use case.
 This extension will be available only in specific versions of the system. You can show
each version as a separate subsystem in the use case diagram.

Using Subsystem Boundaries

Use a subsystem boundary to show what use cases are within the scope of your system.

To draw a subsystem boundary

1. In the toolbox, click Subsystem, then click the diagram.

A subsystem appears on the diagram.

2. Drag the corners of the subsystem to adjust its size.

3. Drag existing use cases into or out of the subsystem to adjust its contents.

- or -

To create a new use case directly in a subsystem, click Use Case in the toolbox, then click inside
the subsystem.

Note
The Subjects property of a use case indicates what subsystem it is contained within.
Use cases outside the system scope

It is frequently useful to include on the diagram use cases that are part of the business but not
dealt with by the system that you are developing. This helps developers understand the context of
their work. For example, Deliver Meal could be shown as a use case involving the actors
Restaurant and Customer, but outside the responsibility of the Meal Ordering Web Site.

Multiple subsystems

You can create several subsystem boundaries to show how different use cases are dealt with by
different components of the system. For example, Add Restaurant Appraisal may be dealt with
on a separate forum Web site. Remember that a use case diagram should deal with what is visible
to the user. If you want to describe the internal division of work in the system, consider using a
component diagram.

System versions

You can use different subsystem boundaries to illustrate different versions of the system. For
example, the Pay use case might be included in Website Version 2 but not in Version 1.This
implies that the system helps customers make their orders. However, they have to pay the
restaurant directly.

Use Dependency relations to link subsystems representing different versions or variants.

See Also

Concepts

Modeling User Requirements

UML Sequence Diagrams: Guidelines
How to: Edit a UML Model and Diagrams
UML Use Case Diagrams: Reference
UML Class Diagrams: Reference
UML Component Diagrams: Reference
UML Component Diagrams: Reference
How to: Edit a UML Model and Diagrams
Visual Studio 2010

You can create and edit a UML model through the views provided by several different types of
diagram. By providing different perspectives on your system, these diagrams help you
understand and discuss different aspects of its design and requirements. Visual Studio Ultimate
provides templates for five of the most frequently used types of UML diagram.

This topic describes techniques for editing the model that are common among the different
diagram types.

Note
For more information that is specific to particular types of diagrams, see Developing Models for
Software Design.
In this Topic

 UML Diagrams are Views of a UML Model

 Creating UML Modeling Diagrams
 Drawing UML Modeling Diagrams
 Editing Shapes and Connectors
 Undoing Changes to the Model
 Sharing Elements between Diagrams
 Copying Elements and Groups of Related Elements
 Deleting a Model Element or its Views
 Searching text in a diagram

UML Diagrams are Views of a UML Model

You can create and use UML diagrams only in modeling projects. For more information about
how to create diagrams and projects, see How to: Create UML Modeling Projects and Diagrams.

 A modeling project contains a single UML model. Every UML diagram in the project is a
view of the UML model.
 You can see the model in UML Model Explorer. On the Architecture menu, point to
Windows, and then click UML Model Explorer.
 Each shape on a diagram is a view of an element in the model. When you place a new
shape on a diagram, you are creating a new element in the model.
 When you save any diagram, Visual Studio Ultimate saves the whole model, all its
diagrams, and the modeling project file.

Creating UML Modeling Diagrams

To create a UML modeling diagram

1. On the Architecture menu, click New Diagram. The Architecture menu is available only
in Visual Studio Ultimate.

The Add New Diagram dialog box appears.

2. Click the type of diagram you want and enter the diagram name.
3. In the Add to modeling project box, you can either select an existing modeling project, or
select Create a new modeling project.

Note
A modeling diagram can exist only as part of a modeling project.

You can also add a diagram to an existing modeling project in Solution Explorer. Right-click the
modeling project, point to Add, and then click New Item.

To create an empty UML modeling project

 On the File menu, point to New, click Project, and in the New Project dialog box, double-
click Modeling Projects.

For more information about how to manage modeling projects, see How to: Create UML
Modeling Projects and Diagrams.

Drawing UML Modeling Diagrams

A modeling diagram displays a collection of model elements linked by relationships. Each

element is displayed as a shape and each relationship is displayed as a connector between two
shapes.

There are two kinds of tools, one for elements and one for relationships. For example, in the
UML class diagram Toolbox, Class is an element tool, and Association is a relationship tool.

Note
If you want information that is specific to particular diagram types, see Developing Models for
Software Design.

To create elements and relationships in a UML modeling diagram

 1. To create a model element, click an element tool in the Toolbox, and then click the
diagram where you want it to appear. After you have created the element, adjust its size
and shape by dragging its handles.

In some cases, you can place a new element inside another element. For example, on a
UML class diagram, you can place a class inside a Package.

Note
If you cannot see the toolbox, click Toolbox on the View menu.

2. To create a relationship, click a relationship tool, click the element where you want the
relationship to start, and then click the element where you want it to end.

Different types of relationships can start or end on different types of elements. For
example, on a UML class diagram, an Association relationship cannot start or end on a
Comment element.

Note
To use the same tool several times, double-click the tool. When you have finished, click
the Pointer tool.

On some kinds of diagrams, you can also draw simple shapes. These shapes are not part of the
model, but you can use them to draw attention to parts of the diagram or to divide it into different
areas.

Importing UML Elements from Other Modeling Tools

You can export elements from other modeling tools as XML Metadata Interchange (XMI) 2.1
files. To import UML class, sequence, and use case elements from .xmi files, download and
install Visualization and Modeling Feature Pack. To add imported elements to the corresponding
diagrams, drag the imported elements from UML Model Explorer.

For more information, see:

 Microsoft Visual Studio 2010 Visualization and Modeling Feature Pack

 How to: Import Model Elements from XMI Files

Editing Shapes and Connectors

When you resize or color a shape, or reroute a connector, there is no effect on the underlying
model. However, when you rename a shape on the diagram or in the UML Model Explorer, the
corresponding element is renamed in UML Model Explorer and in any other diagrams that
present that element.
 Note
There is a simple way to make new toolbox items from which you can create groups of elements,
or elements with your own choice of properties. For more information, see How to: Define a
Custom Modeling Toolbox Item.

The following figure shows how to change the size of a shape or its name.

The following figure shows how to adjust the route and position of a connector or its labels.

To move one end of a connector to another shape

1. Do one of the following:

o Press CTRL and move the end.

- or -

o Right-click the connector and then click Reconnect.

2. Click the end of the connector you want to move.
3. Click the shape that you want the connector to move to.
To change color or other properties of an element, relationship, or diagram

 Click the element and set the fields in the Properties window.

If you cannot see the Properties window, right-click the element, and then click
Properties.

To zoom in and out on a modeling diagram

 Press and hold the CTRL key while you rotate the mouse wheel.

- or -

 Press and hold CTRL+SHIFT, and then click the left or right mouse button.

- or -

 On the Architecture Designers toolbar, click the plus sign (+) or minus sign (-), or choose
a zoom level.

Searching in a Diagram

The Quick Find function will find items on a diagram. You must set Look in: to Current
Document.

To search for text in a modeling diagram

1. Press CTRL+F.

- or -

On the Edit menu, point to Find and Replace, and then click Quick Find.

Note
In the Find and Replace dialog box, you must leave the Look in field set to Current
Document. The other options are not supported.

2. Type the text that you want to find, and then click Find Next.

Note
If the text you want to find is inside a collapsed shape, the shape will be highlighted.
Expand the shape, and then click Find Next again.
Undoing Changes to the Model
You can undo and redo changes that you have made to the model and diagrams by using the
Undo and Redo commands on the Edit menu.

Each modeling project has a single stack of changes. All changes that you make to the model and
the diagrams are kept on this stack. The stack also includes changes of focus from one diagram
to another. The Undo command reverses the changes on this stack.

For example, let's say that you perform these operations: Make a change to Diagram1; change
focus to Diagram 2; change Diagram2. When you undo changes, the first undo will reverse the
last change; the next undo will shift focus back to Diagram 1; and the third undo will reverse the
change to Diagram 1.

Closing a diagram truncates the stack of changes. If you close a diagram, you cannot undo the
changes that you performed in that diagram, and you cannot undo earlier changes to the model or
any of its diagrams.

You cannot undo while you are editing a property. While you are editing a property in the
Properties window, or in a label on a diagram, you can only undo changes that you have made in
that property. Complete your change in the property by pressing ENTER, or cancel it by pressing
ESC. You will then be able to undo changes in the model and diagrams.

Closing a diagram without saving might not have the effect you expect. If you make some
changes, and then close a diagram without saving it, your changes will still be preserved in the
model. It is recommended to close the whole model if you want to do so without saving it.

Sharing Elements between Diagrams

You can make a specific instance of a model element appear more than once in your diagrams.
This applies to classes, interfaces, components, use cases, and actors.

This is useful if you want to show different groups of relationships in different diagrams. For
example, on one diagram, you could show the associations between the Customer and Address
classes. On another diagram, you could show the Address class again, with its association to
Postal Area.

You can change the properties of a model element, such as its name, by selecting any of its views
on any diagram, or by selecting it in UML Model Explorer.

Each kind of diagram can only show some kinds of model element. For example, you cannot
show a use case on a component diagram. Therefore, the following procedures will work only
for some combinations of model element and diagram.

To add a new view of a model element by using UML Model Explorer

 1. To open UML Model Explorer, on the Architecture menu, point to Windows, and then
click UML Model Explorer.
2. Drag the model element from UML Model Explorer to a compatible diagram in the same
project.

A shape providing a view of the model element appears, which may be in addition to the
views on other diagrams or on the same diagram.

Note
The effect is different when you drag a class or component onto a sequence diagram. In
that case, a new lifeline is created whose type is that class or component. For more
information, see UML Sequence Diagrams: Guidelines.

To add a new view of a model element by using Paste Reference

1. Right-click an existing element, and then click Copy.

o You can copy several elements at the same time. Hold down the CTRL key while
you click each element, right-click one of them, and then click Copy.
2. Right-click an empty part of a compatible diagram, and then click Paste Reference.

Another view of the same element appears.

Note

This differs from the Paste command, which creates a new element in the model. For
more information, see Copying Elements and Groups of Related Elements.
Note
If you add to a diagram views of two model elements that are already connected by a
relationship, a view of the relationship will also appear on the diagram. You can delete
this view only by removing one of the elements from the diagram, or by deleting the
relationship from the model.
Copying Elements and Groups of Related Elements

You can copy and paste model elements, and you can copy and paste groups of elements
together with the relationships between them.

Note
The Paste and Paste Reference commands have different effects. Paste creates new elements
whose properties are like those of the copied elements. Paste Reference creates new views of the
same elements.

To copy elements and their relationships

 1. In the diagram with the elements that you want to copy, select one or more elements.

Note
You cannot copy relationships except as part of a group of elements.

2. On the Edit menu, click Copy.

3. If you want to copy the elements to another diagram, create the new diagram or open the
existing diagram.
4. On the Edit menu, click Paste.
o Copies of the elements appear, together with copies of any relationships that link
between them.
o Each new element will have a new automatically generated name.
5. Adjust the positions, names, and other properties of the new elements and relationships.

Note
You cannot copy a model element from one model to another, for example if you have two
models in the same solution.
Deleting a Model Element or its Views

Some kinds of elements, specifically classifiers, can be removed from a diagram without deleting
them from the model. Classifiers are the major elements that are displayed on class diagrams,
component diagrams, and use case diagrams. They can appear on more than one diagram. For
these types of elements, there are two separate commands: Remove from Diagram and Delete
from Model.

By contrast, when you delete a relationship from a diagram, you are always deleting it from the
model.

Note
Certain kinds of elements on a UML diagram have labels. When you select such elements by
drawing a rectangle around them, it is possible to select the labels but not the elements that own
those labels. Deleting a subset of elements that are selected in this way is not supported. To select
a subset of these elements, press and hold the CTRL key while you click each element.

To remove a classifier's view from a diagram

 Right-click the element on the diagram, and then click Remove from Diagram.

- or -

 Click the element on the diagram and then press the DELETE key.
o This view of the element vanishes. However, the element remains in the model,
and you can still find it in UML Model Explorer. Any other views of the same
element also remain.
 o Every connector that terminates at this shape is removed from the diagram, but
the relationship it represents remains in the model. You can see the relationship in
UML Model Explorer under Relationships, under each element that it connects.

To delete an element from the model

 Right-click the element either in UML Model Explorer or on a diagram, and then click
Delete from Model.
o The element is deleted from every diagram on which it appears.
o Every relationship that terminates at this element is also deleted from the model.

To delete a relationship from the model

 Right-click the relationship on a diagram or in UML Model Explorer, and then click
Delete from Model.

Caution
You cannot remove a relationship from a diagram without removing it from the model.

 The relationship is deleted from the model and is deleted from every diagram on which it
appears.

Preparing a Diagram for Presentation

The following features help you to draw attention to particular parts of your diagram, add
explanations, or divide a diagram into different areas of interest.

 You can copy any part of a diagram into a Word, PowerPoint, or other document. Select
the shapes and connectors you want, right-click and then click Copy.
 The color of any shape or connector can be changed. Select one or more shapes and
change the Color property. If you cannot see the Properties window, press F4.
 On diagrams of some kinds, you can draw lines, rectangles and ellipses from the Simple
Shapes section of the Toolbox. These shapes do not form part of the UML model.
 To label an area, you can drag a Comment from the Toolbox and then set its Transparent
property to True. Like Simple Shapes, comments do not form part of the UML model and
do not appear in UML Model Explorer.
 To add notes and explanations to model elements, you can create comments and then link
them to the elements.

To Export a Diagram as an Image

For more information, see How to: Export Images of Diagrams.

See Also
Concepts

How to: Create UML Modeling Projects and Diagrams

Modeling the Application
Developing Models for Software Design

Developing Tests from a Model

Visual Studio 2010

In Microsoft Visual Studio Ultimate, you can use requirements and architectural models to help
you organize the tests of your system and its components. This practice helps ensure that you test
the requirements that are important to the users and other stakeholders, and it helps you update
the tests quickly when the requirements change. If you use Microsoft Test Manager, you can also
maintain links between the models and the tests.

System and Subsystem Testing

System testing, also known as acceptance testing, means testing whether the users' needs are
being met. Such tests are concerned about the externally visible behavior of the system instead of
the internal design.

System tests are very valuable when extending or redesigning a system. They help you avoid
introducing bugs when you change the code.

When you plan any change or extension to a system, it is helpful to start with a set of system
tests that run on the existing system. Then you can extend or adjust the tests to test the new
requirements, make the changes to the code, and rerun the complete set of tests.

When you develop a new system, you can begin to create tests as soon as development begins.
By defining tests before you develop each feature, you can capture the requirements discussions
in a very specific way.
Subsystem testing applies the same principles to the major components of a system. Each
component is tested separately from other components. Subsystem tests focus on the behavior
visible at the component's user interfaces or API.

For more information about how to run tests, see Testing the Application.

Deriving System Tests from a Requirements Model

You can create and maintain a relationship between system tests and a requirements model. To
establish this relationship, you write tests that correspond to the main elements of the
requirements model. Visual Studio Ultimate helps you maintain that relationship by letting you
create links between the tests and parts of the model. For more information about requirements
models, see Modeling User Requirements.

Write Tests for Each Use Case

If you use Microsoft Test Manager, you can create a group of tests for each use case that you
defined in your requirements model. For example, if you have a use case Order a Meal, which
includes Create Order and Add Item to Order, you can create tests for both the overall and the
more detailed of these use cases. For more information about use cases, see UML Use Case
Diagrams: Guidelines.

These guidelines might be helpful:

 Each use case should have several tests, for main paths and exceptional outcomes.
 When you describe a use case in the requirements model, it is more important to define
its postcondition, that is, the goal that is achieved, than to describe in detail the
procedures the user follows in order to achieve the goal. For example, the postcondition
of Order a Meal might be that a Restaurant is preparing a meal for a Customer and that
the Customer has paid. The postcondition is the criterion that your tests should verify.
 Base separate tests on the separate clauses of the postcondition. For example, create
separate tests for notifying the restaurant of the order, and for taking payment from the
customer. This separation has these advantages:
o Changes in different aspects of the requirements frequently occur independently.
By separating the tests into different aspects in this manner, you make it easier to
update the tests when requirements change.
o If the development plan implements one aspect of the use case before another,
you can enable the tests separately as development progresses.
 When you design the tests, separate the choice of test data from the code or script that
determines whether the postcondition has been achieved. For example, a test of a simple
arithmetic function might be: Input 4; verify that the output is 2. Instead, design the script
as: Choose an input; multiply the output by itself, and verify that the result is the original
input. This style enables you to vary the test inputs without changing the main body of
the test.
Linking tests to use cases

If you are using Test Manager to design and run your tests, you can organize your tests under
requirement, use case, or user story work items. You can link these work items to use cases in
your model. This enables you to quickly trace requirements changes to the tests, and helps you
track the progress of each use case.

To link tests to a use case

1. In Test Manager, create a requirement and base a test suite on it. To learn how to do that,
see Creating a Test Plan Using Requirements or User Stories.

The requirement that you create is a work item in Team Foundation Server. It might be a
User Story, Requirement, or Use Case work item, depending on the process template that
your project uses with Team Foundation. For more information, see Planning and
Tracking Projects.

2. Link the requirement work item to one or more use cases in your model.

In a use case diagram, right-click a use case and then click Link to Work Item. For more
information, see How to: Link from Model Elements to Work Items.

3. Add to the test suite, test cases that verify the use cases.

Usually, each user story or requirement work item will link to several use cases in your model,
and each use case will link to several user stories or requirements. This is because each user story
or requirement covers a set of tasks that develop several use cases. For example, in an early
iteration of your project, you might develop the basic user story in which a customer can choose
items from a catalog and have them delivered. In a later iteration, the story might be that the user
pays when completing the order, and the supplier receives the money after it sends the goods.
Each story adds a clause to the postcondition of the Order Goods use case.

You can create separate links from requirements to the clauses of the postcondition by writing
those clauses in separate comments on the use case diagram. You can link each comment to a
requirement work item, and link the comment to the use case on the diagram.

Base Tests on the Requirements Types

The types, that is, the classes, interfaces and enumerations, of a requirements model describe the
concepts and relationships in terms of how users think and communicate about their business. It
excludes types concerned only with the internal design of the system.

Design your tests in terms of these requirements types. This practice helps you ensure that when
changes to the requirements are discussed, it is easy to relate the changes to the necessary
changes in the tests. It makes it possible to discuss the tests and their intended results directly
with end-users and other stakeholders. This means that the users' needs can be maintained
outside the development process, and avoids the inadvertent design of the tests around possible
flaws in the design.

For manual tests, this practice involves adhering to the vocabulary of the requirements model in
the test scripts. For automated tests, this practice involves using the requirements class diagrams
as a basis for your test code, and creating accessor and updater functions to link the requirement
model to the code.

For example, a requirements model might include types Menu, Menu Item, Order, and
associations between them. This model represents the information that is stored and dealt with by
the meal ordering system, but does not represent the complexities of its implementation. In the
working system, there might be several different realizations of each type, in databases, in user
interfaces and on APIs. In a distributed system, there might be several variants of each instance
stored in different parts of the system at the same time.

To test a use case such as Add Item to Order, a test method could include code similar to this:

Copy
Order order = … ; // set up an order
// Store prior state:
int countBefore = order.MenuItems.Count;
// Perform use case:
MenuItem chosenItem = …; // choose an item
AddItemToOrder (chosenItem, order);
// Verify part of postcondition:
int countAfter = order.MenuItems.Count;
Assert (countAfter == countBefore = 1);

Notice that this test method uses the classes of the requirements model. Associations and
attributes are realized as .NET properties.

To make this work, the properties of the classes must be defined as read-only functions or
accessors, which access the system to retrieve information about its current state. Methods that
simulate use cases such as AddItemToOrder must drive the system through its API or through a
layer underneath its user interface. The constructors of test objects such as Order and MenuItem
must also drive the system to create corresponding items inside the system.

Many of the accessors and updaters will already be available through the application's normal
API. But some additional functions might have to be written in order to enable the tests. These
additional accessors and updaters are sometimes known as 'test instrumentation'. Because they
depend on the internal design of the system, it is the responsibility of the system's developers to
provide them, whereas the testers write the code of the tests in terms of the requirements model.

When you write automated tests, you can use Generic Tests to wrap the accessors and updaters.
For more information, see Creating an Automated Test That Runs an Executable Using Generic
Tests.

Tests for Business Rules

Some requirements are not directly related to any one use case. For example, the DinnerNow
business allows customers to choose from many Menus, but requires that in every Order, all the
chosen Items shall be from a single Menu. This business rule can be expressed as an invariant
about the associations between Orders, Menus, and Items in the requirements class model.

An invariant rule of this kind governs not only all the use cases that are currently defined, but
also any other use cases that will be defined later. Therefore, it is useful to write it separately
from any use case, and to test it separately from the use cases.

You can write an invariant business rule as a comment in a class diagram. For more information,
see UML Class Diagrams: Guidelines.

You can link tests to a business rule by linking the comment to a requirement or user story work
item, which you can link to a test suite in Test Manager. For more information, see Attaching
Test Cases to Model Elements.

Performance and other quality of service requirements can be noted in comments on use case,
activity, or sequence diagrams. You can link these also to requirements work items and their test
suites.

Sequence and Activity Diagrams for Tests

If your requirements or architecture models include sequence or activity diagrams, you can write
tests that follow the diagrams directly.

It is sometimes useful to design tests that dynamically choose different paths through the
branches and loops in the diagram.

Try to verify the state of the system after each message or action. This might require additional
instrumentation.

Deriving Subsystem Tests from Models

In the high-level design of a large system, you can identify components or subsystems. These
represent parts that can be separately designed, or are located on different computers, or are
reusable modules that can be recombined in many ways. For more information, see UML
Component Diagrams: Guidelines.

You can apply to each major component the same principles as you use for the complete system.
In a large project, each component can have its own requirements model. In smaller projects, an
architectural model or high-level design can be created to show the major components and their
interactions. For more information, see Modeling the Architecture of a Software System.

In either case, you can establish a relationship between the model elements and the subsystem
tests in the same manner as you would between the requirements model and the system tests.
Isolate Components with Provided and Required Interfaces

It is useful to identify all the dependencies that a component has on other parts of your system or
external services, and to represent these as Required Interfaces. This exercise usually leads to
some redesign that leaves the component much more decoupled and easily separable from the
rest of your design.

An advantage of this decoupling is that the component can be executed for testing by replacing
with mock objects the services it usually uses. These are components that are set up for the
purposes of testing. A mock component provides the interface that your component requires,
responding to queries with simulated data. The mock components form part of a complete test
harness that you can connect to all the interfaces of the component.

A benefit of mock testing is that you can develop your component while the other components
whose services it will use are still under development.

Maintain the Relationships between Tests and Model

In a typical project that performs an iteration every few weeks, a requirements review is held
near the beginning of each iteration. The meeting discusses the features that are to be delivered
in the next iteration. A requirements model can be used to help discuss the concepts, scenarios,
and sequences of actions that will be developed. The business stakeholders set priorities, the
developers make estimates, and the testers ensure the expected behavior of each feature is
captured correctly.

Writing tests is the most effective way to define a requirement, and is also an effective way to
ensure that a person has a clear understanding of what is required. However, whereas writing
tests takes too long to do during a specification workshop, creating models can be done much
more rapidly.

From a testing point of view, a requirements model can be seen as a shorthand for the tests.
Therefore, it's important to maintain the relationship between tests and model throughout the
project.

Attaching Test Cases to Model Elements

If your project uses Test Manager, you can link tests to the elements in your model. This lets you
quickly find the tests affected by a change in the requirements, and helps you track the extent to
which a requirement has been realized.

You can link tests to all kinds of element. Here are some examples:

 Link a use case to the tests that exercise it.

  Write the clauses of a use case postcondition, or goal, onto comments that are linked to
the use case, and then link tests to each comment.
 Write invariant rules in comments on class diagrams or activity diagrams, and link them
to tests.
 Link tests to an activity diagram, or to individual activities.
 Link a test suite to the component or subsystem it tests.

To link tests to a model element or relationship

1. In Test Manager, create a requirement and base a test suite on it. To learn how to do that,
see Creating a Test Plan Using Requirements or User Stories.

The requirement that you create is a work item in Team Foundation Server. It might be a
User Story, Requirement, or Use Case work item, depending on the process template that
your project uses with Team Foundation. For more information, see Planning and
Tracking Projects.

2. Link the requirement work item to one or more elements in your model.

In a modeling diagram, right-click an element, comment or relationship and then click

Link to Work Item. For more information, see How to: Link from Model Elements to
Work Items.

3. Add to the test suite, test cases that verify the requirement expressed in the model
element.

See Also

Concepts

Developing Models for Software Design

Modeling User Requirements
Modeling the Architecture of a Software System
Modeling the Application

Using Models within the Development

Process
Visual Studio 2010
In Visual Studio Ultimate, you can use a model to help you understand and change a system,
application, or component. A model can help you visualize the world in which your system
works, clarify users' needs, define the architecture of your system, analyze the code, and ensure
that your code meets the requirements.

How to use models

Models can help you in several ways:

 Drawing modeling diagrams helps you clarify the concepts involved in requirements,
architecture, and high-level design. For more information, see Modeling User
Requirements.
 Working with models can help you expose inconsistencies in requirements.
 Communicating with models helps you communicate important concepts less
ambiguously than with natural language. For more information, see Modeling the
Architecture of a Software System.
 You can sometimes use models to generate code or other artifacts such as database
schemas or documents. For example, the modeling components of Visual Studio Ultimate
are generated from a model. For more information, see Generating and Configuring Your
Application from Models.

You can use models in a wide variety of processes, from extreme agile to high ceremony.

Use Models to Reduce Ambiguity

Modeling language is less ambiguous than natural language, and it is designed to express the
ideas typically required during software development.

If your project has a small team following agile practices, you can use models to help you clarify
user stories. In discussions with the customer about their needs, creating a model can generate
useful questions much faster, and across a broader area of the product, than writing spike or
prototype code.

If your project is large and includes teams in different parts of the globe, you can use models to
help communicate the requirements and architecture much more effectively than you can in plain
text.

In both cases creating a model almost always results in a significant reduction in inconsistencies
and ambiguities. Different stakeholders frequently have different understandings of the business
world in which the system works, and different developers frequently have different
understandings of how the system works. Using a model as the focus of a discussion usually
exposes these differences. For more information about how to use a model to reduce
inconsistencies, see Modeling User Requirements.

Use Models with Other Artifacts

A model is not by itself a requirements specification or an architecture. It is a tool for expressing
some aspects of these things more clearly, but not all the concepts required during software
design can be expressed. The models should therefore be used together with other means of
communication, such as OneNote pages or paragraphs, Microsoft Office documents, work items
in Team Foundation, or sticky notes on the project room wall. Apart from the last item, all of
these object types can be linked to elements parts of the model.

Other aspects of specification that are ordinarily used together with models include the
following. Depending on the scale and style of your project, you might use several of these
aspects or not use any at all:

 User stories. A user story is a short description, discussed with users and other
stakeholders, of an aspect of the system's behavior that will be delivered in one of the
project's iterations. A typical user story begins "The customer will be able to…." A user
story might introduce a group of use cases, or can define extensions of use cases that
have been previously developed. Defining or extending the use cases helps make the user
story clearer.
 Change Requests. A change request in a more formal project is very similar to a user
story in an agile project. The agile approach treats all requirements as changes to what
was developed in previous iterations.
 Use case description. A use case represents one way in which a user interacts with the
system to achieve a particular goal. A full description includes the goal, main and
alternative sequences of events, and exceptional outcomes. A use case diagram helps
summarize and provide an overview of the use cases.
 Scenarios. A scenario is a fairly detailed description of a sequence of events showing
how the system, users and other systems work together to provide value to the
stakeholders. It might take the form of a slide show of the user interface or a prototype of
the user interface. It can describe one use case or a sequence of use cases.
 Glossary. The project's requirements glossary describes the words with which customers
discuss their world. The user interface and requirements models should also use these
terms. A class diagram can help clarify the relationships between most of these terms.
Creating the diagrams and glossary not only reduces misunderstandings between users
and developers, but also almost always exposes misunderstandings between different
business stakeholders.
 Business rules. Many business rules can be expressed as invariant constraints on the
associations and attributes in the requirements class model, and as constraints on
sequence diagrams.
 High-level design. Describes the major parts and how they fit together. Component,
sequence and interface diagrams are a major part of a high-level design.
 Design patterns. Describe the rules of design that are shared across the different parts of
the system.
 Test specifications. Test scripts and the designs for test code can make good use of
activity and sequence diagrams to describe sequences of test steps. System tests should be
expressed in terms of the requirements model so that they can easily be changed when the
requirements change.
  Project plan. The project plan or backlog defines when each feature will be delivered.
You can define each feature by stating what use cases and business rules it implements or
extends. You can either refer to the use cases and business rules directly in the plan, or
you can define a set of features in a separate document, and use the feature titles in the
plan.

Use Models in Iteration Planning

Although all projects are different in their scale and organization, a typical project is planned as a
series of iterations of between two and six weeks. It is important to plan enough iterations to
allow feedback from early iterations to be used to adjust the scope and plans for later iterations.

You might find the following suggestions useful to help realize the benefits of modeling in an
iterative project.

Sharpen Focus as each Iteration Approaches

As each iteration approaches, use models to help define what is to be delivered at the end of the
iteration.

 Do not model everything in detail in the early iterations. In the first iteration, create a
class diagram for the main items in the user glossary, draw a diagram of the major use
cases, and draw a diagram of the major components. Do not describe any of these in fine
detail, because the detail will change later in the project. Use the terms defined in this
model to create a list of features or major user stories. Assign the features to iterations so
as to approximately balance the estimated workload throughout the project. These
assignments will change later in the project.
 Try to implement simplified versions of all the most important use cases in an early
iteration. Extend those use cases in later iterations. This approach helps reduce the risk of
discovering a flaw in the requirements or the architecture too late in the project to do
anything about it.
 Near the end of each iteration, hold a requirements workshop to define in detail the
requirements or user stories that will be developed in the next iteration. Invite users and
business stakeholders who can decide priorities, as well as developers and system testers.
Allow three hours to define requirements for a 2-week iteration.
 The objective of the workshop is for everyone to agree what will be accomplished by the
end of the next iteration. Use models as one of the tools to help clarify the requirements.
The output of the workshop is an iteration backlog: that is, a list of development tasks in
Team Foundation and test suites in Microsoft Test Manager.
 In the requirements workshop, discuss the design only insofar as you need to determine
estimates for the development tasks. Otherwise, keep discussion to system behavior that
users can experience directly. Keep the requirements model separate from the
architectural model.
 Nontechnical stakeholders usually have no problems understanding UML diagrams, with
some guidance from you.
Link Model to Work Items

After the requirements workshop, elaborate the details of the requirements model, and link the
model to development tasks. You can do this by linking work items in Team Foundation to
elements in the model. To learn how to do this, see How to: Link from Model Elements to Work
Items.

You can link any element to work items, but the most useful elements are as follows:

 Use cases. You can link a use case to the development tasks that will implement it.
 Use case extensions. If only one aspect of a use case will be implemented in an iteration,
you can separate it into a base use case together with one or more extensions. The
extensions are use cases linked to the base case with the «extend» relationship. For more
information about use case extension, see UML Use Case Diagrams: Reference.
 Comments describing business rules or quality of service requirements. For more
information, see Modeling User Requirements.

Link Model to Tests

Use the requirements model to guide the design of the acceptance tests. Create these tests
concurrently with the development work.

To learn more about this technique, see Developing Tests from a Model.

Estimate Remaining Work

A requirements model can help estimate the total size of the project in relation to the size of each
iteration. Assessing the number and complexity of the use cases and classes can help you
estimate the development work that will be required. When you have completed the first few
iterations, a comparison of the requirements covered and the requirements still to cover can give
an approximate measure of the cost and scope of the rest of the project.

Near the end of each iteration, review the assignment of requirements to future iterations. It can
be useful to represent the state of your software at the end of each iteration as a subsystem in a
use case diagram. In your discussions, you can move use cases and use case extensions from one
of these subsystems to another.

Levels of abstraction

Models have a range of abstraction in relation to the software. The most concrete models directly
represent program code, and the most abstract models represent business concepts that might or
might not be represented in the code.

A model can be viewed through several kinds of diagrams. For information about models and
diagrams, see Developing Models for Software Design.
Different kinds of diagram are useful for describing the design at different levels of abstraction.
Many of the diagram types are useful at more than one level. This table shows how each type of
diagram can be used.
Design level
Business Process
Understanding the context within
which your system will be used
helps you understand what the
users need from it.
User requirements
Definition of what the users need
from your system.
High level design
The overall structure of the
system: the major components and
how they couple together.
Design patterns
Conventions and methods of
solving design problems that are
used in all parts of the design
Code analysis
Several types of diagram can be
generated from the code.
Diagram types
 Activity diagrams describe the flow of work between
people and systems to achieve business goals.
 Conceptual class diagrams describe the business
concepts used within the business process.
 Use case diagrams summarize the interactions that the
users and other external systems have with the system
that you are developing. You can attach other
documents to each use case to describe it in detail.
 UML class diagrams describe the types of information
that the users and system communicate about.
 Business rules and quality of service requirements can
be described in separate documents.
 Layer Diagrams describe how the system is structured
into interdependent parts. You can validate program
code against layer diagrams to ensure that it adheres to
the architecture.
 Component diagrams show the interfaces of the parts,
specifying the messages and services that are provided
and required by each component.
 Sequence diagrams show how the components
communicate to implement each use case.
 UML class diagrams describe the interfaces of the
components and the types of data passed between the
components.
 UML class diagrams describe the structures of a
pattern
 Sequence or activity diagrams show the interactions
and algorithms
 Sequence diagrams show the interaction between
objects in the code.
 Layer diagrams show the dependencies between
classes. Updated code can be validated against a layer
diagram.
 Class diagrams show the classes in the code.
See Also

Concepts

Use Models in Agile Development

Developing Models for Software Design
Modeling User Requirements
Modeling the Architecture of a Software System
Developing Tests from a Model
Structuring Modeling Solutions

Other Resources

Visual Studio 2010 Architecture Tooling Guidance

Community Content Add
FAQ
VS2010 Architecture Tooling Guidance
Visual Studio 2010 Architecture Tooling Guidance

Practical guidance for Visual Studio 2010 Ultimate, focused on modelling tools. These release
includes common usage scenarios, hands on labs and lessons learnt from the community
discussions. The scenarios include understanding and reverse engineering an existing solution or
starting a new solution from scratch. These are both common challenges that any dev lead or
architect faces. The intent is not to give you an in-depth tour of the product features, but to
present you with examples that show how these tools can support you in real world scenarios,
and to provide you with practical guidance and checklists. This guidance is focused on practical
ways of effectively using Visual Studio 2010 Ultimate and other tools to create a new or revised
design as part of application lifecycle management.
UML Sequence Diagrams: Reference
Visual Studio 2010

In Visual Studio Ultimate, a sequence diagram shows an interaction, which represents the
sequence of messages between instances of classes, components, subsystems, or actors. Time
flows down the diagram, and it shows the flow of control from one participant to another. To
create a UML sequence diagram, on the Architecture menu, click New Diagram.

The diagram shows example instances and events, instead of classes and methods; more than one
instance of the same type can appear in the diagram, and more than one occurrence of the same
message can appear also.

There are two kinds of sequence diagram:

 Code-based Sequence Diagrams can be generated from .NET program code, and can be
placed within any project. For more information, see How to: Explore Code with
Sequence Diagrams.
 UML Sequence Diagrams form part of a UML model, and exist only within UML
modeling projects. For more information, see UML Sequence Diagrams: Guidelines.

The two kinds of sequence diagram are similar, although a few of the properties of the elements
are different.

For more information about how to create and draw modeling diagrams, see How to: Edit a
UML Model and Diagrams.

Reading Sequence Diagrams

The following table describes the elements that you can see on a sequence diagram. For
information about the properties of these elements, see Properties of Elements in UML Sequence
Diagrams.

For a information about how to use sequence diagrams, see UML Sequence Diagrams:
Guidelines.
Shape Element Description
A vertical line that represents the sequence of events that occur in a
1 Lifeline participant during an interaction, while time progresses down the line.
This participant can be an instance of a class, component, or actor.
A participant that is external to the system that you are developing.
2 Actor
You can make an actor symbol appear at the top of a lifeline by setting
its Actor property.
The sender waits for a response to a synchronous message before it
Synchronous continues. The diagram shows both the call and the return. Synchronous
3
message messages are used to represent ordinary function calls within a program,
as well as other kinds of message that behave in the same way.
A message that does not require a response before the sender continues.
Asynchronous An asynchronous message shows only a call from the sender. Use to
4
message represent communication between separate threads or the creation of a
new thread.
5 Execution A vertical shaded rectangle that appears on a participant's lifeline and
occurrence
 represents the period when the participant is executing an operation.

The execution begins where the participant receives a message. If the

initiating message was a synchronous message, the execution ends with a
«return» arrow back to the sender.
A message that returns back to a participant that is waiting for the return
Callback
6 from an earlier call. The resulting execution occurrence appears on top of
message
the existing one.
A message from a participant to itself. The resulting execution
7 Self message
occurrence appears on top of the sending execution.
A message that creates a participant. If a participant receives a create
8 Create message
message, it should be the first it receives.
An asynchronous message from an unknown or an unspecified
9 Found message
participant.
10 Lost message An asynchronous message to an unknown or an unspecified participant.
11 Comment A comment can be attached to any point on a lifeline.
Encloses a sequence of messages that are defined in another diagram.
12 Interaction Use
To create an Interaction Use, click the tool and then drag across the
lifelines you want to include.
A collection of fragments. Each fragment can enclose one or more
messages. There are different kinds of combined fragments. For more
information, see Describing Control Flow with Fragments in UML
Combined
13 Sequence Diagrams.
Fragment
To create a fragment, right-click a message, point to Surround With, and
then click a fragment type.
Can be used to state a condition relevant to whether the fragment will
occur.
14 Fragment Guard
To set the guard, select a fragment, then select the guard, and type a
value.
The collection of messages and lifelines that is displayed in the sequence
Interaction diagram. To view the properties of an Interaction, you must select it in
UML Model Explorer.
The diagram that displays an Interaction. To view its properties, click on
an empty part of the diagram.
Sequence
Diagram Note
The names of the Sequence Diagram, the Interaction that it displays, and
the file that contains the diagram can all be different.
See Also

Concepts
UML Sequence Diagrams: Guidelines
How to: Edit a UML Model and Diagrams
UML Use Case Diagrams: Reference
UML Class Diagrams: Reference
UML Component Diagrams: Reference
UML Component Diagrams: Reference

UML Sequence Diagrams: Guidelines

Visual Studio 2010

In Visual Studio Ultimate, you can draw a sequence diagram to display an interaction. An
interaction is a sequence of messages between typical instances of classes, components,
subsystems, or actors. To create a UML sequence diagram, on the Architecture menu, click New
Diagram.

There are two kinds of sequence diagrams:

 Code-based sequence diagrams can be generated from .NET program code. For more
information, see How to: Explore Code with Sequence Diagrams.
 UML sequence diagrams are part of UML modeling projects.

This topic is about UML sequence diagrams.

For detailed information about the elements you can see on a sequence diagram, see UML
Sequence Diagrams: Reference.

In this Topic

Using UML Sequence Diagrams

Basic Steps for Drawing Sequence Diagrams

Creating and Using Simple Sequence Diagrams

Classes and Lifelines

Creating Reusable Interaction Sequences

Collapsing Groups of Lifelines

Describing Control Structures with Fragments

Generating Sequence Diagrams from Code

Using UML Sequence Diagrams

You can use sequence diagrams for a variety of purposes at different levels of program detail.
Typical occasions for drawing a sequence diagram are as follows:

 If you have a use case diagram that summarizes your system's users and their goals, you
can draw sequence diagrams to describe how the main components of the system interact
to fulfill the goal of each use case. For more information, see UML Use Case Diagrams:
Guidelines.
 If you have identified messages arriving at an interface of a component, you can draw
sequence diagrams to describe how the internal parts of the component interact to achieve
the result required for each incoming message. For more information, see UML
Component Diagrams: Guidelines.

Drawing sequence diagrams has several benefits:

 You can easily see how tasks are distributed between components.
 You can identify patterns of interaction that make it difficult to update the software.

Relationship to other diagrams

You can use UML sequence diagrams together with other diagrams in several ways.

Lifelines and types

The lifelines you draw in a sequence diagram can represent typical instances of the components
or classes in your system. You can create lifelines from types, and types from lifelines, and show
the types on UML class diagrams and UML component diagrams. For more information, see
Classes and Lifelines.

Parameter types

You can also describe in a UML class diagram the types of parameters and returned values that
were used in the messages sent between the lifelines.

Use case details

A use case represents a user's goal, together with a sequence of steps for achieving the goal. The
sequence of steps can be described in several ways. One option is to draw a sequence diagram
that shows the interactions between the users and the system's major components. For more
information, see UML Use Case Diagrams: Guidelines.

Source Code

You can generate a sequence diagram from source code. You can revise the diagram to
experiment with different design options. You can also copy the content to a sequence diagram
in a modeling project, if you want. For more information, see Generating Sequence Diagrams
from Code.

Basic Steps for Drawing Sequence Diagrams

For a complete list of elements on sequence diagrams, see UML Sequence Diagrams: Reference.

Note
Detailed steps for how to create any of the modeling diagrams are described in How to: Edit a
UML Model and Diagrams.

To create a sequence diagram

1. On the Architecture menu, click New Diagram.

2. Under Templates, click UML Sequence Diagram.
3. Name the diagram.
4. In Add to Modeling Project, select an existing modeling project in your solution, or
Create a new modeling project, and then click OK.

A new sequence diagram appears with the Sequence Diagram toolbox. The toolbox
contains the required elements and connectors.
To draw a sequence diagram

1. Drag Lifelines (1) from the Toolbox onto the diagram to represent instances of classes,
components, actors, or devices.

Note
You can also create a lifeline by dragging an existing class, interface, actor or component
from UML Model Explorer onto the diagram. This creates a lifeline representing an
instance of the chosen type.

2. Draw messages to show how the lifelines collaborate to achieve a specific goal.

To create a message (3, 4, 6, 7), click a message tool. Then click the sending lifeline at
the point where you want the message to start, and then click the receiving lifeline.
 An execution occurrence (5) appears at the receiving lifeline. The execution occurrence
represents a period of time during which the instance is executing a method. You can
create other messages that start from an execution occurrence.

3. To show a message that comes from an unknown event source (9), or broadcasts to
unknown recipients (10), draw an asynchronous message from or to blank space on the
diagram. These messages are called found messages (9) and lost messages (10).

Note
To move a group of lifelines that have lost or found messages, follow these steps to select
the lifelines before you move them: Draw a rectangle around those lifelines, or press and
hold the CTRL key while you click each lifeline. If you use Select All or CTRL+A to
select all lifelines, and then move them, any lost or found messages attached to these
lifelines will not move. If this scenario occurs, you can move these messages separately.

4. Draw sequence diagrams for each major message to the same component or system.

To change the order of messages

 Drag a message up or down in its lifeline. You can drag it over other messages, or into or
out of an execution block.

- or -

 Click the message and use the UP ARROW and DOWN ARROW keys to adjust message
positions. Use SHIFT+UP ARROW and SHIFT+DOWN ARROW to change the order of
the messages.

To move or copy message sequences on the sequence diagram

1. Right-click a message (3, 4) and then click Copy.

2. Right-click the execution occurrence (5) or a lifeline (1) from which you want the new
message to be sent, and then click Paste. The new sender can be on a different diagram if
you want.

A copy of the message and all its subsidiary messages is added to the end of the
execution occurrence, or to the end of the lifeline.

Note
The pasted message always appears at the end of the execution occurrence or lifeline.
After you have pasted it, you can drag it up to an earlier position.

To improve the layout of a sequence diagram

 Right-click a blank part of the diagram, and then click Rearrange Layout.
  To undo the operation, click Edit, and then click Undo.

To change the package that owns the interaction

1. In UML Model Explorer, find the Interaction that the sequence diagram displays.

Note
The interaction will not appear in UML Model Explorer until you add the first lifeline to
the sequence diagram.

2. Drag the Interaction into the Package.

- or -

Right-click the Interaction, and then click Cut. Right-click the Package, and then click
Paste.

Creating and Using Simple Sequence Diagrams

The simplest and most widely-used form of sequence diagram contains just lifelines and
messages. A diagram of this kind lets you show clearly a typical sequence of interactions
between objects in your design, or between your system and its users. This is frequently enough
to help you discuss and communicate your design.

Here are some things to consider when you draw a simple sequence diagram.

Types of message

There are three tools that you can use to create messages.

 Use the Synchronous tool to describe an interaction in which the sender waits for the
receiver to return a response (3).

A <<return>> arrow will be shown at the end of the execution occurrence. It indicates
return of control to the sender.

 Use the Asynchronous tool to describe an interaction in which the sender can continue
immediately without waiting for the receiver (4).
 Use the Create tool to describe an interaction in which the sender creates the receiver (8).

A create message should be the first message that the receiver receives.

Annotating the interactions

To describe more detail about the sequence, you can place a Comment anywhere on the diagram.

Using Comment Links, you can link a comment to lifelines, executions, interaction uses, and
fragments.

Caution
When you want to attach a comment to a particular point in the sequence, link it to an execution
occurrence, interaction use, or fragment. Do not link it to a lifeline, because in that case, it does
not remain attached at the correct point in the sequence.

Use a comment to:

 Note what has been achieved at key points in the sequence. This helps readers to see the
objectives of the interactions.
 Describe the overall objective of the whole sequence. Attach the comment to the initial
execution occurrence or leave it unattached. For example, "Customer has chosen items
from the menu and has been given a price."
 Describe the responsibilities of each lifeline. Attach the comment to the lifeline. For
example, "Ordering Manager collects the customer's menu choices."
 Note exceptions or alternatives that might be performed as an alternative to the typical
sequence shown. For example "Customer can choose to skip the rest of this sequence."
o Consider using fragments as a more formal alternative to this kind of note. See
Describing Control Structures with Fragments

Deciding the Scope of the Diagram

It is important to be clear about what the diagram is intended to show.

Initiating event

Each diagram should show the sequence of interactions that results from one initiating event.
This might be, for example:

 A user initiating a use case, for example, opening the Web page for buying a meal.
 A message from one system component to another, for example, querying the availability
of items that a customer wants to buy.
 An event triggered by a change of state, for example, stocks of an item falling below a
threshold.

Level of detail

Sequence diagrams can show different levels of detail. You can decide the level of detail in two
separate dimensions almost independently:

Lifelines can represent one of these levels of detail:

  Objects in the program code, which either exists, or you are developing.
 Components or their subcomponents, usually omitting facades, proxies, and other
connective mechanisms.
 Your system and external actors

Messages can represent one of these levels of detail:

 Software messages in the program code, at an API, or Web interface.

 Transactions or sub-transactions, for example, between users and the system, or between
code and database.
 Use cases - major interactions between users and the system.

Whether you are exploring existing code or describing a new design, it is frequently useful to
draw and discuss the less detailed views.

Describing variations

The diagram shows a single, typical sequence of events. If you want to show alternative
possibilities such as failure scenarios, you can either use either of these options:

 Draw separate sequence diagrams to describe those scenarios

 Use Describing Control Structures with Fragments to show loops, alternatives, and so on.

Assessing the Design

You can use the diagram to assess the distribution of tasks between its objects or components.
Consider refactoring if you see these patterns:

 One lifeline seems to do everything, making calls to everything else, whereas the other
lifelines just respond passively.
 Many messages cross lifelines. Each lifeline should send messages to just a few
neighbors, and should not communicate with its neighbors' neighbors. It should usually
be possible to arrange the lifelines so that there are only a few places where messages
cross lifelines; and where there are crossings, the target lifeline should not also exchange
messages that have the crossed lifelines.
 Some lifelines seem to handle more than one kind of task. It should easy to find one
succinct sentence that describes the responsibilities of each lifeline, summarizing the
work it does in response to each message that it receives.

Classes and Lifelines

The lifelines in your sequence diagrams show instances of classes or component interfaces. You
can name a lifeline in two ways:
 For this purpose Use this format
Anonymous instance of a type.
typeName
Use this if you have only one lifeline of each type.
Named instance of a type.
objectName:typeName
Use this if you want to show a sequence that involves more than one
instance of the same type.

Creating Lifelines from Types

You can create new lifelines from classes that you have already defined, for example on a class
diagram.

Note
Make sure you have an existing sequence diagram before you perform this task.

To create a lifeline from an existing type

 Drag a class, component, or interface from UML Model Explorer onto a sequence
diagram.

- or -

1. Right-click the class, component, or interface on its respective diagram, and then
click Create Lifeline.
2. In the Create Lifeline dialog box, select a sequence diagram, and then click OK.

A new named-instance lifeline appears whose type is the type you dragged.

Note
You can repeat this action as many times as you like. This will create lifelines with
different instance names.

To change the type of a lifeline

1. Right-click a lifeline, and then click Properties.

2. In the Properties window, set the Type property. You can either select a type from the
drop-down menu, or type a new name.

Creating Classes from Lifelines

When you have created one or more sequence diagrams, you can summarize the lifelines by
creating classes or interfaces from them.
To create a class or interface from a lifeline

1. Right-click the lifeline, and then click Create Class or Create Interface.

A new class or interface appears in UML Model Explorer.

2. Create operations in the class or interface for each message that the lifeline receives:
1. Select all the messages that you want to include.
2. Right-click one of the messages, and then click Create Method.

The new class or interface has operations for each selected message.

The operation name appears below each message arrow, and in the Operation
property of the message.

If your message included parameters in the form "(parameter : type)", they will
appear in the parameter list of the new operation.

Note
You must repeat this step if you add new messages in the sequence diagram.

3. To view the new class or interface in detail, add it to a class or component diagram.
1. Open or create a class or component diagram.
2. Drag the new class or interface from UML Model Explorer to a class diagram.

The class or interface appears in the class diagram.

- or -

3. Drag the new interface from UML Model Explorer onto a component or port in a
component diagram.

The interface appears on the component as a lollipop.

Creating classes for parameters

You can include parameters in the messages on a sequence diagram. You can use a UML class
diagram to describe the parameter types.

Creating Reusable Interaction Sequences

You can use a separate diagram to describe a sequence that contains detail that you want to
separate out, or that is common between several diagrams.
You can create an Interaction Use rectangle (12) on one diagram that points to the details in
another diagram.

Double-click an Interaction Use to open the sequence diagram that is linked to it.

To create a reusable interaction sequence from existing lifelines

1. In the Toolbox, click Interaction Use.

2. On the sequence diagram, hold the mouse button down while you drag across the lifelines
that you want to include in the reusable sequence. Start at the vertical position where you
want to insert the interaction use.

An interaction use appears across the selected lifelines on the sequence diagram.

3. Double-click the name on the interaction use, and rename it to describe the effect of the
reusable sequence in this diagram.

- or -

Write the name like a function call, with parameters.

4. Link the interaction use to another sequence diagram. Right-click the interaction use, and
then either:

Click Create New Sequence to create a new sequence diagram

- or -

Click Link to Sequence to link to an existing diagram.

Visual Studio creates a link between the interaction use and the new interaction sequence.

A new sequence diagram appears in your solution. It contains the lifelines that you used
to create the interaction use.

Note
Only the lifelines you used to create the interaction use will be included. The new diagram
will not include lifelines that you created after the interaction use, even if the interaction
use now covers them.

To create a reusable sequence from existing messages

 Right-click the message that you want to move, and then click Move to Diagram.

Visual Studio:
 o Replaces with an interaction use the selected message and any subsidiary
messages.
o Moves the replaced messages to a new sequence diagram.
o Creates a link between the interaction use and the new sequence diagram.

To navigate to the sequence referenced by an interaction use

 Double-click the interaction use.

- or -

Right-click the interaction use and then click Go to Sequence.

Creating a Placeholder with an Interaction Use

You can create an interaction use without linking it to another diagram. You can use this as a
placeholder for a part of the sequence whose details are yet to be worked out. Use the name of
the interaction use to indicate the outcome that you want.

Collapsing Groups of Lifelines

You can collapse a set of lifelines together, so that the group appears as one lifeline. This helps
you visualize a group of objects as a single component. Messages and interaction uses between
lifelines in a collapsed group are hidden. Messages and interaction sequences that include other
lifelines are shown.

To collapse a group of lifelines together

1. Select two or more lifelines.

2. Right-click one of them, and then click Collapse.

The separate lifelines are replaced by a single lifeline.

Messages and interaction uses that involve only members of the group are hidden.

3. To rename the group, click the name.

Note
The group name will be lost when you expand the group.

To expand a collapsed group

 Right-click the collapsed lifeline, and then click Expand.

 Note
The name of the group will be lost, together with any links from the group to comments or
work items.
Describing Control Structures with Fragments

You can use combined fragments (13) to define loops, branches and concurrent processing in a
sequence diagram. Alternatively, consider using an activity diagram instead. The activity
diagram is not as useful at showing messages between actors, but in some cases is better at
showing loops, branches, and concurrency.

For a full list of the types of fragment, see Describing Control Flow with Fragments in UML
Sequence Diagrams.

To create a combined fragment

1. Select a message, or a sequence of messages all starting on the same execution

occurrence or lifeline.

Note
Select the message arrows, not the execution occurrences that the messages point to.

2. Right-click one of the messages, point to Surround With, and then click the type of
fragment that you require.

A new fragment appears. It contains the messages that you selected.

If the combined fragment type allows multiple fragments, an empty fragment also
appears.

3. To set the guard of a fragment, right-click the fragment border, and then click Properties.
Set the Guard property.

The guard is used to define the condition for a branch or a loop.

4. To add a new fragment to a kind that allows multiple fragments, right-click the boundary
of a fragment, and point to Add. Click either Interaction Operand Before or Interaction
Operand After.
5. To add new messages to a fragment, use the message tools, or copy and paste.

Generating Sequence Diagrams from Code

You can generate a sequence diagram from a method definition in a Visual C# or Visual Basic
code file.
A generated sequence diagram is very similar to a sequence diagram that you have created in a
modeling project. But the elements in a generated sequence diagram do not appear in UML
Model Explorer.

To generate a sequence diagram from code

1. In Visual Studio, open the code file that contains the method definition.
2. Right-click anywhere within the method definition, and then click Generate Sequence
Diagram.

For more information, see How to: Explore Code with Sequence Diagrams.

Note
After you generate the diagram, any changes that you make to the diagram will not appear
in the code, and any changes that you make to the code will not appear on the diagram. To
show these changes, you must generate a new sequence diagram. You can generate a new
sequence diagram from the same method as many times as you want.

You can navigate from lifelines and messages to the code definitions of the classes and methods
that they represent.

To navigate from generated lifelines and messages to code

 Right-click a generated lifeline or message, and then click Go to Definition.

Copying Generated Sequences to a UML Model

You can copy lifelines, messages and other parts of a generated sequence to a sequence diagram
in a modeling project.

To copy a generated sequence diagram to or from a UML Model

1. On a sequence diagram, select the elements that you want to copy, such as lifelines and
messages. If you want to copy everything in the diagram, on the Edit menu, click Select
All.
2. On the Edit menu, click Copy.
3. Create or open a sequence diagram in a modeling project. To learn how to do this, see
Basic Steps for Drawing Sequence Diagrams.
4. On the Edit menu, click Paste.

Copies of the selected elements appear on the diagram.

Note
You might have to adjust the color of the pasted elements. Select them, and set the color
 in the Properties window.
See Also

Reference

UML Sequence Diagrams: Reference

Concepts

How to: Edit a UML Model and Diagrams

UML Use Case Diagrams: Reference
UML Class Diagrams: Reference
UML Component Diagrams: Reference
UML Component Diagrams: Reference
Community Content Add
FAQ
"X" at the bottom of the lifelines

VS sequence diagrams always have an X at the bottom of a lifeline. According to the UML spec,
the X should be used only to show that the object is deleted or no longer accessible. There's
currently no workaround.

History

 11/8/2010
 Alan Cameron Wills -

Some limitations and workarounds

While evaluating the sequence diagrams I came across this limitations that may prevent you from
drawing what you have in mind:

 You can’t hide the reply part of a synchronous message. A workaround is to remove the
label and color the reply arrow transparent. But you won’t get rid of the execution block.
 You need to have a message to add a combined fragment, even when your fragment
doesn’t require one. One example of this could be a Break fragment. The workaround is
to add a dummy message to be able to add the combined fragment and then remove the
message again.
 You can’t resize fragments or interaction operands. For example, if you remove some
messages from a combined fragment, you will end up with a large fragment that you
can’t resize. A workaround to reclaim diagram space in those situations is to right-click a
blank part of the diagram, and then click Rearrange Layout (you can undo this operation
if needed!).
  You can’t reorder fragments or interaction operands. I haven’t found a work around for
this.
 You can’t copy/paste fragments. A workaround is to copy/paste the messages within the
fragment and then recreate the fragment around them. That’s of course only thinkable for
very simple fragments.
 You can’t rewire messages to other lifelines. A workaround for rewiring the start lifeline
is to copy the message and paste it in the other starting lifeline. Then remove the original
message. I haven’t found a workaround for rewiring the destination lifeline of a message.

[Alan Cameron Wills: Thanks for this great feedback, Jose. We've added these items to our
backlog for future development. BTW, don't forget that you can also log bugs and feedback at
https://connect.microsoft.com/VisualStudio - this feedback does influence the development
teams.]

UML Use Case Diagrams: Reference

Visual Studio 2010

In Visual Studio Ultimate, a use case diagram summarizes who uses your application or system,
and what they can do with it. To create a UML use case diagram, on the Architecture menu, click
New Diagram.

A use case diagram acts as a focus for the description of user requirements. It describes the
relationships between requirements, users, and the major components. It does not describe the
requirements in detail; these can be described in separate diagrams or in documents that can be
linked to each use case.

For information about how use case diagrams can help you understand, discuss and communicate
your users' needs, see Modeling User Requirements.

Note
This topic describes the elements that are available in use case diagrams. For more information
about how to draw use case diagrams, see UML Use Case Diagrams: Guidelines. For more
information about how to create and draw modeling diagrams, see How to: Edit a UML Model
and Diagrams.
Reading Use Case Diagrams

The tables in the following sections describe the elements that are available on a use case
diagram, together with their main properties. For a full list of properties, see Properties of
Elements in Use Case Diagrams.

Actors, Use cases, and Subsystems

Shape Element Description and Main Properties

Represents a user, organization, or external system that interacts with your
application or system. An actor is a kind of type.

1 Actor  Image Path - the file path of an image that should be used instead
of the default actor icon. The icon should be a resource file within
the Visual Studio project.

Represents the actions performed by one or more actors in the pursuit of a

particular goal. A use case is a kind of type.
2 Use Case
 Subjects - the Subsystem in which the use case appears.

3 Association Indicates that an actor takes part in a use case.

4 Subsystem or The system or application that you are working on, or a part of it. Can be
component anything from a large network to a single class in an application.

The use cases that a system or component supports appear inside its
rectangle. It can be useful to show some use cases outside the rectangle, to
clarify the scope of your system.

A subsystem in a use case diagram has basically the same type as a

 component in a component diagram.

 Is Indirectly Instantiated - If false, your executing system has one

or more objects that directly correspond to this subsystem. If true,
the subsystem is a construct in your design that appears in the
executing system only through the instantiation of its constituent
parts.

Structuring Use Cases

Shape Element Description

An including use case calls or invokes the included one. Inclusion is used
to show how a use case breaks into smaller steps. The included use case is
at the arrowhead end.
5 Include
Notice that the diagram does not show the order of the steps. You can use
an activity diagram, sequence diagram, or other document to describe these
details.
An extending use case adds goals and steps to the extended use case. The
extensions operate only under certain conditions. The extended use case is
at the arrowhead end.
6 Extend
Notice that the diagram does not show the exact circumstances under
which the extension applies: you can record these in a comment or other
document.
7 Inheritance Relates a specialized and a generalized element. The generalized element
 is at the arrowhead end.

A specialized use case inherits the goals and actors of its generalization,
and may add more specific goals and steps for achieving them.

A specialized actor inherits the use cases, attributes and associations of its
generalization, and may add more.
8 Dependency Indicates that the design of the source depends on the design of the target.
9 Comment Used to add general notes to the diagram.
An artifact provides a link to another diagram or document. You can create
it by dragging a file from Solution Explorer. It can be linked with a
Dependency to any other element on the diagram. An artifact is typically
used to link a use case to a sequence diagram, OneNote page, Word
document or PowerPoint presentation that describes it in detail. The
10 Artifact document can either be an item in the Visual Studio solution, or a
document in a shared location such as a SharePoint site.

 Hyperlink. The URL or file path of the diagram or document.

Double-click an artifact to open the file or web page to which it links.

Use cases, actors, and subsystems can be contained within packages.
Package shapes do not appear on the diagram, but you can set the
11 (not
Packages LinkedPackage property of the diagram. Elements that you subsequently
shown)
create on the diagram are placed within the package. For more information,
see Defining Packages and Namespaces.
See Also

Reference

UML Sequence Diagrams: Reference

Concepts

UML Use Case Diagrams: Guidelines

How to: Edit a UML Model and Diagrams
UML Class Diagrams: Reference
UML Component Diagrams: Reference
UML Component Diagrams: Reference
UML Class Diagrams: Reference
Visual Studio 2010

A UML class diagram describes the object and information structures used by your application,
both internally and in communication with its users. It describes the information without
reference to any particular implementation. Its classes and relationships can be implemented in
many ways, such as database tables, XML nodes, or compositions of software objects.

Note
This topic is about UML class diagrams. There is another kind of class diagram, the .NET class
diagram, which is used to visualize program code. For more information, see Designing and
Viewing Classes and Types.
Reading Class Diagrams

The table in this section describes the elements that you can see on a UML class diagram. For
information about the properties of these elements, see the following topics:

 Properties of Types in UML Class Diagrams

 Properties of Attributes in UML Class Diagrams
 Properties of Operations in UML Class Diagrams
 Properties of Associations in UML Class Diagrams

For more information about how to draw UML class diagrams, see UML Class Diagrams:
Guidelines. To create a UML class diagram, on the Architecture menu, click New Diagram. For
more information about how to create and draw modeling diagrams, see How to: Edit a UML
Model and Diagrams.
Shape Element Description
A definition of objects that share given structural or behavioral
1 Class characteristics. For more information, see Properties of Types in UML
Class Diagrams.
The general name for a class, interface, or enumeration. Components,
1 Classifier
use cases, and actors are also classifiers.
If you cannot see the details of a classifier, click the expander at upper-
Collapse/
2 left of the classifier. You might also have to click the [+] on each
Expand control
segment.
A typed value attached to each instance of a classifier.

3 Attribute To add an attribute, click the Attributes section and then press ENTER.
Type the signature of the attribute. For more information, see Properties
of Attributes in UML Class Diagrams.
A method or function that can be performed by instances of a classifier.
To add an operation, click the Operations section and then press
4 Operation
ENTER. Type the signature of the operation. For more information, see
Properties of Operations in UML Class Diagrams.
A relationship between the members of two classifiers. For more
5 Association
information, see Properties of Associations in UML Class Diagrams.
An association representing a shared ownership relationship. The
5a Aggregation
Aggregation property of the owner role is set to Shared.
An Association representing a whole-part relationship. The Aggregation
5b Composition
property of the owner role is set to Composite.
Association
6 The name of an association. The name can be left empty.
Name
 The name of a role, that is, one end of an association. Can be used to
refer to the associated object. In the previous illustration, for any Order
O, O.ChosenMenu is its associated Menu.
7 Role Name
Each role has its own properties, listed under the properties of the
association.
Indicates how many of the objects at this end can be linked to each
object at the other. In the example, each Order must be linked to exactly
one Menu.
8 Multiplicity
* means that there is no upper limit to the number of links that can be
made.
The specific classifier inherits part of its definition from the general
classifier. The general classifier is at the arrow end of the connector.
Attributes, associations, and operations are inherited by the specific
9 Generalization classifier.

Use the Inheritance tool to create a generalization between two

classifiers.

Shape Element Description

A definition of part of the externally visible behavior of an object. For more
10 Interface
information, see Properties of Types in UML Class Diagrams.
11 Enumeration A classifier that consists of a set of literal values.
 A group of classifiers, associations, actions, lifelines, components and
packages. A logical class diagram shows that the member classifiers and
packages are contained within the package.

Names are scoped within packages so that Class1 within Package1 is distinct
from Class1 outside that package. The name of the package appears as part
12 Package
of the Qualified Name properties of its contents.

You can set the Linked Package property of any UML diagram to refer to a
package. All the elements that you create on that diagram will then become
part of the package. They will appear under the package in UML Model
Explorer.
A relationship between packages, indicating that one package includes all
13 Import
the definitions of another.
The definition or implementation of the dependent classifier might change if
14 Dependency
the classifier at the arrowhead end is changed.

Shape Element Description

The class implements the operations and attributes defined by the interface.
15 Realization
Use the Inheritance tool to create a realization between a class and an
interface.
An alternative presentation of the same relationship. The label on the lollipop
symbol identifies the interface.
16 Realization
To create this presentation, select an existing realization relationship. A
Action tag appears near the association. Click the action tag, and then click
Show as Lollipop.
See Also

Concepts

How to: Edit a UML Model and Diagrams

UML Class Diagrams: Guidelines
Properties of Types in UML Class Diagrams
Properties of Attributes in UML Class Diagrams
Properties of Operations in UML Class Diagrams
Properties of Associations in UML Class Diagrams