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

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

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.

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.

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.


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


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 ReviewA 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.

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.

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.

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

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

Class Diagrams
!
Sequence Diagrams
!
Component and Deployment DiagramsUML 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.
!

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

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.

Use Case Diagrams
List Available
Products
User
Raise Purchase
Order
Vendor System
Process OrderA 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


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.