Tài liệu Module 2: Designing and Modeling docx

Contents
Overview 1
Introduction to Analysis and Design 2
Creating a Conceptual Design 8
Lab 2.1: Reviewing the Requirements
Document 17
Creating a Logical Design 19
Creating a Physical Design 38
Lab 2.2: Using the Visual Modeler 50
Best Practices 55
Review 57

Module 2: Designing
and Modeling


Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any

license to these patents, trademarks, copyrights, or other intellectual property.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, BackOffice, MS-DOS, Windows, Windows NT, PowerPoint, Visual Basic, and Visual
Studio are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A.
and/or other countries.

The names of companies, products, people, characters, and/or data mentioned herein are fictitious
and are in no way intended to represent any real individual, company, product, or event, unless
otherwise noted.

Other product and company names mentioned herein may be the trademarks of their respective
owners.


Module 2: Designing and Modeling i


Instructor Notes
This module covers the major phases and deliverables in the Microsoft
®

Solutions Framework (MSF) Application model. The conceptual, logical, and
physical design phases are then discussed in relation to the Unified Modeling
Language (UML). Students also use Microsoft Visual Modeler to model the
Purchase Ordering solution.
After completing this module, students will be able to:
!
List and describe the three design phases defined in the MSF Application

model.
!
Employ UML use cases, scenarios, and use case diagrams in the conceptual
design phase.
!
Use UML class diagrams and sequence diagrams in the logical design
phase.
!
Use Visual Modeler to create class diagrams.
!
Use component diagrams and deployment diagrams in the physical design
phase to generate code from Visual Modeler.

In the labs, students will review the Requirements Document for the Purchase
Order Online application and then test their understanding of the proposed
solution. In the second part of the lab, students will use Visual Modeler to
model aspects of the system and generate code.
Materials and Preparation
This section provides you with the required materials and preparation tasks that
are needed to teach this module.
Required Materials
To teach this module, you need the following materials:
!
Microsoft PowerPoint
®
file 1907A_02.ppt
!
Module 2: Designing and Modeling
!
Lab 2.1: Reviewing the Lab Solution

!
Lab 2.2: Using the Visual Modeler

Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.
!
Complete the labs.
!
Read the instructor notes and the margin notes for the module.
!
Practice the demonstrations.

Presentation:
120 Minutes

Lab:
60 Minutes
ii Module 2: Designing and Modeling


Demonstrations
This module contains the following demonstrations. Use the following
instructions as the basis of your presentation to the students. Although the
demonstrations are indicated by a slide, you may wish to present them
incrementally as you explain the concepts. In this case, use the slide to
summarize what you have demonstrated.
Using Visual Modeler
!

Create a Visual Modeler model
1. Start Microsoft Visual Modeler from the Microsoft Visual Studio
®
6.0
Enterprise Tools program group.
2. Point out the different model views available in the browser window
(Logical View, Component View, and Deployment View).
3. Return to the Logical View and display the Three-Tiered Service Model.

!
Add classes to the model
In this procedure, you will add two classes to the model. Explain to students
that this demonstration is unrelated to the lab scenario.
1. On the Tools menu, point at Create and choose Class from the submenu.
2. Click in the User Services section of the diagram to create the class.
3. Change the class name from New Class to Customer.
4. Click the Class button on the toolbar.
5. Click in the Business Services section of the diagram to create a second
class.
6. Name the second class Account.
7. Right-click the Account class and choose Open Specification.
8. In the Documentation tab, type This class represents a customer’s
account then click OK.

!
Add Properties and Methods to the Account class
1. Right-click the Account class and choose New Property.
2. Name the new property AccountNo and click in free space to deselect the
class. (Pressing Return adds another property.)
3. Right-click the Account class and choose New Method.

4. Name the new method Credit and click in free space to deselect the class.
5. Right-click the Account class and choose Open Specification.
6. Show the Properties and Methods tabs.
7. On the Methods tab, right-click in the list of methods and choose Insert.
Name the new method Debit.
8. Click in the Return Type column of the Debit method and point out that you
need to click the column again to display the drop-down list of data types.
Choose Boolean from the list and explain that custom data types can be
added by simply typing them.
Module 2: Designing and Modeling iii


9. Double-click the Debit method in the list of methods to display its
specification. Note that the return class can also be set from this dialog box.
10. On the Arguments tab, right-click in the empty list of arguments and
choose Insert.
11. Name the new argument curAmount.
12. Click in the Type column for the curAmount argument and then click the
column again to display the data type drop-down list. Choose Currency
from the list.
13. Click OK to confirm the changes to the Debit method.
14. On the Properties tab, double-click the AccountNo property. Explain that
the property is private by default.
15. Change the Export Control setting to public.
16. Point out that you can change the property’s data type here. Change the
Type to Long and click OK.
17. Click OK again to close the Specification dialog box for the Account class.

!
Add class dependencies

1. On the Tools menu, point at Create and choose Dependency from the
submenu.
2. Click on the Customer class and drag to the Account class to create the
dependency.
3. Save the model as bank.mdl in the <Install
Folder>\Democode\Mod02\CreateModel folder.

Generating Code with Visual Modeler
!
Prepare Visual Basic
®
for code generation
1. Start Visual Basic and create a new Standard EXE project.
2. On the Add-Ins menu, click Add-In Manager.
3. In the list of available add-ins, locate the Visual Modeler Add-In and the
Visual Modeler Menus Add-In.
4. Select each of these add-ins and check the Load on Startup check box.
5. Click OK to close the Add-In Manager.
6. Close Visual Basic without saving the project.

!
Add a component to the model
1. Open the bank.mdl model you saved in the last demonstration and expand
the Component View folder in the browser window. (If you did not
complete the last demonstration, open bank.mdl from the <install
folder>\Democode\Mod02\GenerateCode folder.)
2. Double click Main to view the components in the model (currently, there
are none).
3. On the Tools menu, point at Create and choose Component from the
submenu.

iv Module 2: Designing and Modeling


4. Click anywhere in the model window to create the new component.
5. Rename the component Bank.

!
Configure the component
1. Right-click the Bank component and choose Open Specification.
2. Change the Stereotype to DLL and the Language to Visual Basic, then
click Apply and point out that a Visual Basic tab has been added to the
dialog box.
3. Click the Realizes tab and note that all of the classes in the model are listed.
Explain that this component will only contain the Account class.
4. Right-click the Account class in the list of classes and choose Assign. Point
out the red tick and the change of language for the Account class.
5. Clear the Show All Classes check box so that only classes assigned to this
component are displayed.
6. Click the Visual Basic tab and click the Edit Set button.
7. Choose Class from the Type drop-down list and point out the default class
settings.
8. In the list of settings, click Creatable and then click again to reveal the
drop-down list of values. Choose MultiUse from the list.
9. In the list of settings, click CollectionClass and then click again to reveal
the value text box. There are no collections associated with this class, so
clear the text box.
10. Click OK to close the Visual Basic settings dialog box and then click OK
again to close the component specification dialog box.

!

Generate Visual Basic code
1. Right-click the Bank component and choose Generate Code.
2. On the Welcome screen, click Next.
3. On the Select Classes screen, point out that more classes can be assigned to
the component at this stage and then click Next.
4. On the Preview Classes screen, select the Account class and click Preview.
a. On the Class Options screen, point out that the options you configured
have been used. Then click Next.
b. On the Property Options screen, point out the code preview at the
bottom of the screen. Then click Next.
c. On the Role Options screen, click Next.
d. On the Method Options screen, select each method and point out the
code preview at the bottom of the screen. Then click Finish to return to
the Code Generation Wizard.
5. On the Preview Classes screen, click Next.
6. On the General Options screen, ensure the Save model and project before
generating code check box is checked. Clear all of the check boxes in the
Code Generation Options section and click Next.
7. On the Finish screen, click Finish. Code generation will begin.
Module 2: Designing and Modeling v


8. When the Delete Classes screen is displayed, click Form1. (Note that you do
not actually need to click the Delete button.) Then click OK.
9. Read the summary screen and then click Close to close it.
10. Switch to the Visual Basic project that has been generated.
11. Point out the code that has been generated and note that the model is listed
as a Related Document in the Project Explorer window.
12. Save the project in the folder containing bank.mdl.

Reverse Engineering a Component with Visual Modeler
!
Modify the code created by Visual Modeler
Explain that some of the default settings created by Visual Modeler should be
changed if the project is to be used in a distributed application.
1. Open the Bank project you generated in the last demonstration. (If you did
not complete the last demonstration, open Bank.vbp from the <install
folder>\Democode\Mod02\ReverseEngineer folder.)
2. In the Bank project, click Bank Properties on the Project menu.
3. On the General tab, make the following changes:
a. Change the Startup Object to (none).
b. Change the Threading Model to Apartment Threading.
4. Click OK.

!
Add a new method
1. Open the code window for the Account class, and on the Tools menu, click
Add Procedure.
2. In the Add Procedure dialog box, add a new public function named
GetBalance.
3. Point out the new procedure signature added to the class module. Add the
code As Currency to the end of the function heading to determine the
return type.

!
Reverse Engineer the model
1. On the Add-Ins menu, point at Visual Modeler and select Reverse
Engineering Wizard from the submenu.
2. On the Welcome screen, click Next.
3. On the Selection of Project Items screen, ensure only Class Modules is

selected and then click Next.
4. Explain that the Assignment of Project Items screen is used to assign classes
added in Visual Basic to logical tiers in the model. We have not added any
classes so simply click Next.
5. Review the Finish screen and then click Finish. Reverse Engineering will
begin.
6. When the summary screen is displayed, click Close to close it.
vi Module 2: Designing and Modeling


7. Switch to Visual Modeler and examine the Account class in the Logical
view window. Point out that the GetBalance method has been added to the
model.
8. Save the project and model and then Close Visual Basic and Visual
Modeler.

Module Strategy
Use the following strategy to present this module:
!
Introduction to Analysis and Design
Tell students that a critical part of developing enterprise solutions is to
analyze the business problem that needs to be addressed. When you
properly analyze the business problem and create an appropriate design, you
can deliver a solution that is scalable, robust, and meets user requirements.
You should also adopt a design strategy that is sufficiently flexible to
incorporate changes throughout the software development process.
!
Creating a Conceptual Design
Discuss the steps that are required to create a conceptual design. The system
requirements must be captured from the perspective of the end user and the

business services. The UML defines a set of best practices for capturing and
representing the system requirements. UML converts the requirements into
a set of use cases and associated scenarios. The scenarios are defined as the
output of the conceptual design under the MSF Application Model.
!
Creating a Logical Design
Explain that the next step in the design process after capturing the user
requirements is to build a logical model of the system. The model consists
of two views: a static view showing how the parts of the system relate to
each other, and a dynamic view showing how the system parts interact with
each other. The UML provides a variety of diagrams in which this
information can be captured. These diagrams help to refine the high-level
information gathered in the conceptual design phase into more detailed
information on which you can base your implementation.
!
Creating a Physical Design
The final design phase defined by the MSF Application Model is to create a
physical design for the solution. Explain that changes can be made to the
logical design during this phase. After all of the design phases are complete,
the solution can be made into a component, packaged, and implemented.
!
Best Practices
Summarize the best practices that have been covered in this module.

Module 2: Designing and Modeling 1


#
##
#

Overview
!
Introduction to Analysis and Design
!
Creating a Conceptual Design
!
Lab 2.1: Reviewing the Requirements Document
!
Creating a Logical Design
!
Creating a Physical Design
!
Lab 2.2: Using the Visual Modeler
!
Best Practices and Review


A critical part of developing enterprise solutions is to analyze the business
problem that needs to be addressed. When you analyze the business problem
properly and create an appropriate design, you can deliver a solution that is
scalable, robust, and meets user requirements. You should also adopt a design
strategy that is flexible enough to incorporate changes throughout the software
development process.
In this module, you will learn how the Microsoft Solutions Framework (MSF)
application model defines an iterative design approach to n-tier applications.
You will also learn how you can use the Unified Modeling Language (UML) in
each of the design phases of the development project. Finally, you will learn
how to use Microsoft Visual Modeler to produce UML models and generate
Microsoft Visual Basic code.

Objectives
After completing this module, you will be able to:
!
List and describe the three design phases defined in the MSF application
model.
!
Employ UML use cases, scenarios, and use case diagrams in the conceptual
design phase.
!
Use UML class diagrams and sequence diagrams in the logical design
phase.
!
Use Visual Modeler to create class diagrams.

!
Use component diagrams and deployment diagrams in the physical design
phase to generate code from Visual Modeler.

Slide Objective
To provide an overview of
the module topics and
objectives.

Lead-in
A critical part of developing
enterprise solutions is to
analyze the business
problem that needs to be
addressed. When you
properly analyze the

business problem and
create an appropriate
design, you can deliver a
scalable, robust solution that
meets user requirements.
2 Module 2: Designing and Modeling


#
##
#

Introduction to Analysis and Design
!
Importance of Analysis and Design
!
The MSF Application Model


One of the ongoing challenges for developers is to build solutions that deliver
the functionality the end user wants. Building good solutions involves
analyzing business requirements and designing a suitable software system to
meet those requirements. Although the detailed steps in analysis and design
vary depending on the process and tools used, there are some common themes
found in all software development endeavors.
When choosing a software development process for building enterprise
systems, it is important to ensure that the process will enable the development
team to identify the user requirements, design and build an appropriate solution,
and adapt to changes in the requirements throughout the life of the development
project.

In this section, you will learn about the phases in the design process. You will
also learn how to use an iterative approach to design to help ensure that the
finished product meets the user's requirements.
This section includes the following topics:
!
Importance of Analysis and Design
!
The MSF Application Model

Module 2: Designing and Modeling 3


Importance of Analysis and Design
!
Analyze the Business Problem
!
Understand the Business Logic
!
Consider Enterprise Issues


The key to creating an effective application is a clear understanding of the
business processes involved. As the designer of an application, you must clearly
understand what functionality the application should deliver and how the end
user will interact with the application. To acquire this conceptual
understanding, you must communicate with the intended users of the
application and determine what they expect from it. Analysis by the Standish
Group, in the form of their CHAOS Report, has shown that user involvement is
the most significant criterion of success for software projects. To see this report,
go to the Standish Group’s Web site at www.standishgroup.com.

Analyze the Business Problem
Implementing incorrect or extraneous functionality can waste much time and
money. Implementing the correct functionality, but building an application on
incorrect assumptions about how that functionality will be used, can be equally
wasteful.
For example, consider a purchasing application that allows office personnel to
generate purchase orders for office products. Orders for individual items must
be routed to the correct vendor. In designing this application, the developers
need an understanding of how both the office workers and the vendors will
interact with the system. Failure to analyze all of the possible interactions may
lead to a solution that satisfies the requirements of only one (or none) of the
users. If the final system enables users to raise purchase orders, but does not
provide a way for vendors to process the orders, it does not solve the business
problem.
4 Module 2: Designing and Modeling


Understand the Business Logic
As well as gaining a conceptual understanding of how users need to interact
with the system, developers need to understand the business logic required by
the solution. Acquiring this information usually involves gaining an
understanding of the entities involved in the business problem. For example, in
the purchase ordering system previously discussed, one of the entities in the
system is an order. The business rules of the proposed system may require that
an order has some kind of unique identifier associated with it (such as an order
number) or that orders with a total value over a specified amount need to be
authorized by a manager. Understanding the logical entities in the business
processes allows for the development of software representations of those
entities, such as database tables or components, that model their real-world
attributes and behaviors.

Consider Enterprise Issues
The proliferation of rapid application development tools, such as Microsoft
Visual Basic, has brought many benefits to businesses and developers by
enabling software to be developed relatively quickly and easily. However, in
many cases, this quick and easy approach to software development has led to
the development of systems that work well on a single development computer,
but do not scale well enough to be used effectively in an enterprise-level
scenario. High performance and scalability must be considered in the design of
the solution because it is generally difficult or impossible to add them later.
For example, the purchase ordering system that was described earlier needs to
be designed as a distributed, multiuser application if it is to allow all users in
the office to place orders with multiple vendors. As a result, you must consider
issues such as network traffic, database performance, user concurrency,
deployment, and other physical aspects of the system.
Module 2: Designing and Modeling 5


The MSF Application Model
!
Services in the Application Model
!
Design Phases of the Application Model


MSF defines a number of models, often referred to as templates, that you can
use for different aspects of developing solutions. Many of these models, such as
the Team Model and the Process Model, focus on the logistics involved in a
software development project. For more information about the MSF models, go
to the MSF Web site at www.microsoft.com/msf.
The MSF application model presents a conceptual view of an application that

provides a services-based architecture for developing distributed multitier
applications.
Services in the Application Model
The Application Model defines a service as any software element that performs
a function for another software element. For example, a COM component that
provides data for other components or programs is a service. An Active Server
Page (ASP) that produces HTML to present to a client is also a service in the
sense that it is providing a service to an external entity, the client. From the
MSF perspective, an application is constructed from a logical network of
consumers and suppliers of services. These services can be distributed across
both physical and functional boundaries to support the needs of many different
applications.
Services are divided into three categories: user services, business services, and
data services. For more information about these services, see Application
Services in Module 1: Developing Enterprise Solutions for Windows 2000.
6 Module 2: Designing and Modeling


Design Phases of the Application Model
The Application Model defines three design phases that enable solutions to be
designed and developed in an iterative fashion. One of the major benefits of
iterative design is that the design can be adapted as user requirements are
refined or changed. The Application Model charts a solution’s development
through the conceptual, logical, and physical design phases. The above
illustration shows the iterative nature of the design phases.
Conceptual Design Phase
Conceptual design is the process of acquiring, documenting, and validating the
user and business perspectives of a problem and its solution. This process is
frequently described as "requirements capture."
The goal of conceptual design is to understand what users do and to identify

business needs. The output of conceptual design is scenarios that describe the
interactions between the users and the proposed system.
For example, in the Purchase Ordering application described earlier, the
conceptual design phase would involve identifying the interactions between the
office workers and the system, as well as the interaction between the vendors
and the system.
Logical Design Phase
Logical design is a view of the solution from the project team's perspective. It
defines the solution as a set of cooperating objects and their services. These
services are grouped into the categories of user, business, and data services
according to the MSF Application Model.
The goal of logical design is to specify the structure of the solution and how the
various elements will communicate. The output of the logical design is a set of
objects and services, high-level user interface (UI) design, and logical database
design. For example, in the Purchase Ordering solution, the logical design
phase would include modeling the order entity so that it represents the attributes
and behaviors of a real-world order and shows its relationship to other entities
in the system.
Because the design process is iterative, any new user interactions discovered
while modeling the application might mean a return to the conceptual design
phase to deal with those interactions. For example, if the business logic
modeled here revealed a previously undiscovered interaction in which a
manager approves an order, the conceptual design of the interaction between a
manager and the system would need to be analyzed.
Physical Design Phase
Physical design is a view of the solution from the developer's perspective. It
defines the solution's components, services, and technologies.
The goal of physical design is to apply real-world technology constraints to the
logical model, including implementation and performance considerations. The
outputs are components, user interface design for a particular platform, and

physical database design. For example, the Order entity modeled in the logical
design phase may be mapped to a software component, a database table, or both
in the physical design phase.
Module 2: Designing and Modeling 7


Again, in an iterative design process, performance or deployment issues may
become apparent during physical design and may require further refinements to
the logical design. For example, if the number of Order component attributes
implemented as properties will cause network congestion, the logical design
may be refined to define these attributes as method parameters. Similarly, if the
relationship between the Order table and another table representing the Product
entity shows a many-to-many relationship (that is, if many products may be
requested in many orders), then the logical design may need to be refined to
create an associative entity (such as OrderItems).
The three design phases are discussed in more detail later in this module.
8 Module 2: Designing and Modeling


#
##
#

Creating a Conceptual Design
!
Introduction to UML
!
Use Cases
!
Scenarios

!
Use Case Diagrams


To create a conceptual design, you must capture the system requirements from
the perspective of the end user and the business services. The Unified Modeling
Language (UML) defines a set of best practices for capturing and representing
the system requirements. UML converts the requirements into a set of use cases
and associated scenarios. The scenarios are defined as the output of the
conceptual design under the MSF Application Model.
In this section, you will learn how to use UML to capture the attributes and
interactions of a proposed software project. You will also learn how to create
use cases and scenarios to capture requirements.
This section includes the following topics:
!
Introduction to UML
!
Use Cases
!
Scenarios
!
Use Case Diagrams

Module 2: Designing and Modeling 9


Introduction to UML
!
Use Cases and Scenarios
!

Class Diagrams
!
Sequence Diagrams
!
Component and Deployment Diagrams


UML is a language for specifying, visualizing, and documenting software
systems. It provides a mixture of graphical and textual notation to represent the
concepts it is trying to capture. UML represents a collection of best engineering
practices that have proven successful in modeling large and complex systems.
UML grew out of previous object-oriented modeling languages. It was designed
to be a standard modeling language incorporating the best aspects of three
popular languages: Booch, Rumbaugh’s OMT, and Jacobson’s Objectory. The
UML specification has been standardized under the auspices of the Object
Management Group (OMG), with major contributions from vendors such as
Microsoft, Rational, and Hewlett Packard.
UML provides a standard notation for capturing different views of a system.
This notation takes the form of diagrams and textual descriptions describing
various aspects of the application, including:
!
Use cases and scenarios.
Describe the interactions between the users and the system.
!
Class diagrams.
Describe the logical model of the application.
!
Sequence diagrams.
Show the order in which various system events occur.
!

Component and deployment diagrams.
Show the physical model of the application.

10 Module 2: Designing and Modeling


A standard notation provides several benefits to the developer or systems
architect. It allows the creation of a formal description of the proposed system
from many perspectives at the conceptual, logical, and physical design phases.
It also makes it easier for external analysts or consultants to quickly
comprehend the most important points of the system design.
It is important to understand that UML itself does not have an associated
process or life cycle. As a result, it can be used as a tool within various
processes such as the MSF Process Model, the Unified Software Development
Process, or the Rational Unified Process.
UML includes many more diagrams and notational elements than the ones
described in this course. For more information about UML, go to the OMG site
at www.omg.org/uml.
Module 2: Designing and Modeling 11


Use Cases
!
Textual description of a general interaction with the
system
A user requests a list of all products that are
available to order. The system confirms that
the user has appropriate permissions to view
the product list and if not, an error message
is displayed. If the user has appropriate

permissions the product ID, name, price,
category, description, vendor code and
discontinued status of all non-discontinued
products are displayed.


Use cases are the output from the requirements capture phase of the analysis
and design process. The use cases describe what the system should and should
not do. A use case is built around a narrative, or text description, that describes
how part of the application works by explaining an interaction with the system.
The description should ignore details about how the interaction takes place and
concentrate on the sequence of events and choices that are made. From the
description, the external roles, or "actors," that will use the system can be
discovered. An actor may be a human user or another software system that
interacts with the system being designed. After a use case has been described,
the interaction between the actors involved can be formally depicted by using a
use case diagram.
For a simple example of a use case, assume that you are trying to build the
Purchase Ordering system discussed earlier. A basic use case would be that of a
user requesting a list of the products that are available to order. The actor in this
case would be the user and the description would be similar to the following
account.
Use Case: List Available Products
Consider the following use case describing a list of available products:
A user requests a list of all products that are available to order. The system
confirms that the user has appropriate permissions to view the product list and
if not, an error message is displayed. If the user has appropriate permissions, the
product ID, name, price, category, description, vendor code, and the status of all
available products are displayed.
12 Module 2: Designing and Modeling

This use case is general enough to cover both successful and unsuccessful
requests. It provides a high-level description of the complete interaction
between a user and the system when a list of available products is requested. In
a real system design, use cases would be written for every interaction, such as
placing an order or discontinuing a product.
Module 2: Designing and Modeling 13


Scenarios
!
Textual descriptions of specific use case instances
Steve requests a list of all products that
are available to order. Steve has permission
to view the product list and the product ID,
name, price, category, description, vendor
code and discontinued status of all non-
discontinued products are displayed.
Nora requests a list of all products that are
available to order. Nora does not have
permission to view the product list. An error
message is displayed.


Use cases are fairly high-level, generalized descriptions of the system’s
functionality. Although the use cases can be used to develop an initial model of
the system, more detail is needed to create a model that can be used as the basis
for the design. In particular, each possible variation of behavior within each use
case must be examined.

To fill out this detail, scenarios can be created based on the use cases. A
scenario is a use case walk-through that follows a single path. Each scenario
will describe one specific interaction with the system. It must be a precise
description of the interaction and cannot contain the generalizations used in the
use case. A scenario belongs to a single use case, but each use case can be
associated with many scenarios. The following three scenarios are based on the
use case example previously described.
Scenario 1
Steve requests a list of all products that are available to order. Steve has
permission to view the product list. The product ID, name, price, category,
description, vendor code, and the available status of all non-discontinued
products are displayed.
Scenario 2
Nora requests a list of all products that are available to order. Nora does not
have permission to view the product list. An error message is displayed.
14 Module 2: Designing and Modeling


Scenario 3
Juan requests a list of all products that are available to order. Juan has
permission to view the product list. The product list is currently unavailable. An
error message is displayed.
These scenarios provide a detailed description of how the system should behave
for every variation of the use case on which they are based. These descriptions
are not only useful when creating a conceptual design of the system, but also
provide a sound basis for functionality testing when the initial solution has been
developed.
Guidelines for Generating Scenarios
The number of possible scenarios for a use case may be large. You should
create sufficient scenarios to exercise the use case as fully as possible.

However, take care not to create scenarios that cover the same functionality.
You should use an optimal number of scenarios that cover the possible options.
You can use the following guidelines when generating scenarios:
!
Focus on common scenarios.
Start with the most common scenarios.
!
Avoid duplication.
Look for variations within the use case and avoid duplication where
possible.
!
Cover optional scenarios.
Make sure that all optional parts of the use case are covered somewhere in
the scenarios.
!
Consider common errors.
Consider the common errors that people make when performing the task at
hand, such as entering an incorrect password or an invalid value.
!
Consider extreme cases.
Think about extreme cases, such as timeouts and internal system failures.
Also, do not forget about malicious attempts to make the system behave
incorrectly.

When creating scenarios, you may find that the use case on which they are
based is flawed in some way. This discovery may lead you to revisit the use
case and refine it, specialize it, or split it into multiple use cases.
Module 2: Designing and Modeling 15

Use Case Diagrams
List Available
Products
User
Raise Purchase
Order
Vendor System
Process Order


A use case diagram shows the bounds of the system. It consists of a list of use
cases contained within the system and associations with the actors that perform
in those use cases. The above illustration shows an example of a use case
diagram.
An actor is represented by a stick figure, regardless of whether the actor is a
human or another system or device. All the actors should be outside the system
boundary. The use cases themselves are represented as ovals within the system
boundary. Each oval contains the name of its associated use case. Lines are
used to associate actors with use cases.
For a complex system, it may be impossible to represent all the actors and use
cases on a single diagram. In this case, it may be best to create use case
diagrams for related use cases or on a per-actor basis.
To reduce repetition, use cases can be based on other use cases. This approach
is referred to as one use case extending another use case. For example, as well
as raising personal purchase orders, users may be allowed to raise purchase
orders on behalf of their department. The following diagram shows that the
Raise Departmental Purchase Order use case extends the Raise Purchase Order
use case.

16 Module 2: Designing and Modeling

Similarly, use cases can be reused by aggregation. In this case, it is said that the
aggregating use case uses the aggregated use case. Use cases can be grouped in
packages for ease of representation so that an actor is associated with a package
of use cases. For example, raising a purchase order involves selecting which
products to order. As a result, the Raise Purchase Order use case uses the List
Available Products use case as shown in the following diagram.

Actors themselves can also be extended or specialized if there are specific use
cases that are only performed by subsets of an actor type. For example, you
may want to extend the user actor to create a manager actor that performs the
use cases relating to order authorization.
Module 2: Designing and Modeling 17


Lab 2.1: Reviewing the Requirements Document


In this lab, you will review the Requirements document for the Purchase Order
application. You will read case studies and scenarios to make sure you
understand the proposed solution.
Use cases are a useful way to understand the system you are designing. You
will study some use cases for the Purchase Order application and then test your
understanding by answering some questions based on the use cases.
Objectives
After completing this lab, you will be able to:
!
Employ use cases to gain an understanding of a software development
problem.

Prerequisites
Before working on this lab, you should be familiar with the following:
!
The Gathering Requirements phase of a software development project

Exercises
The following exercise provides practice in working with the concepts and
techniques covered in this module:
!
Exercise 1: Examining Use Cases
In this exercise, you will examine the Requirements document for the
proposed Purchase Order application. You will then test your understanding
of the envisioned solution.

Estimated time to complete this lab: 30 minutes
Slide Objective
To introduce the lab.
Lead-in
In this lab, you will review
the Requirements
Document for the Purchase
Order application.