Tài liệu Module 1: Designing Distributed Applications for Windows® 2000 pptx

Contents
Overview 1
Microsoft Enterprise Strategy 2
Microsoft Solutions Framework 4
Unified Modeling Language 11
Practice: Using Visio 2000 to Create UML
Diagrams 16
Design Patterns 20
Market Purchasing 30
Practice: Using Market Purchasing 35
Lab 1: Reviewing the Market Purchasing
Conceptual Design 43
Review 47

Module 1: Designing
Distributed Applications
for Windows
®
2000

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, Active Directory, ActiveX, BackOffice, FrontPage, Microsoft Press, MSDN, MS-DOS,
PowerPoint, Visio, Visual Basic, Visual C++, Visual InterDev, Visual J++, Visual Studio, Win32,
Windows, and Windows NT are either registered trademarks or trademarks of Microsoft
Corporation in the U.S.A. and/or other countries.

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

Program Managers: Rhy Mednick, Susie Parrent
Instructional Designer: Susie Parrent
Subject Matter Experts: David Chesnut, Sam Gill (TechnoWiz), Michel Pahud
Media Management: David Mahlmann
Editing Manager: Lynette Skinner
Editor: Mick Alberts, Jennifer Linn
Production Manager: Miracle Davis
Print Coordinators: Linda Lu Cannon (Write Stuff), Marlene Lambert (Online Training
Solutions, Inc.)
Build Coordinator: Eric Wagoner
Graphic Artist: Scott Serna

Test Lead: Eric Myers
Manufacturing Manager: John Williams
Group Product Manager: Juan Fernando Rivera
Lead Product Manager, System Services and Infrastructure: Edward Dudenhoefer
Manufacturing Manager: Rick Terek
Operations Coordinator: John Williams
Manufacturing Support: Laura King; Kathy Hershey
Lead Product Manager, Release Management: Bo Galford
Group Manager, Courseware Infrastructure: David Bramble
General Manager: Robert Stewart

Module 1: Designing Distributed Applications for Windows® 2000 iii


Instructor Notes
This module provides students with an overview of the design methodologies
and the technology infrastructure that facilitates distributed application
development. In particular, this module presents an overview of the Microsoft
®

Enterprise Strategy, Microsoft Windows
®
2000 technologies, the Microsoft
Solutions Framework (MSF), the Unified Modeling Language (UML), and
design patterns. This module also introduces students to the sample application,
Market Purchasing, that is used in the labs throughout the course.
After completing this module, students will be able to:
!
Describe Microsoft Enterprise Strategy and identify the Windows 2000
technologies and the types of applications they can build.

!
Identify the technologies and application types that this course will focus
on.
!
Describe design patterns and how they apply to architecture and logical
design.
!
Describe the MSF application model and UML.
!
Describe the attributes of the Market Purchasing application that will be
used in this course.

Materials and Preparation
This section provides the materials and preparation tasks that you need to teach
this module.
Required Materials
To teach this module, you need the following materials:
!
Microsoft PowerPoint
®
file 1910A_01.ppt
!
Module 1: Designing Distributed Applications for Windows 2000
!
Lab 1: Reviewing the Market Purchasing Conceptual Design

Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.

!
Complete the lab.

Presentation:
60 Minutes

Lab:
45 Minutes
iv Module 1: Designing Distributed Applications for Windows® 2000


Other Activities
This section provides procedures for implementing interactive activities to
present or review information, such as games or role paying exercises.
Practice: Using Visio 2000 to Create UML Diagrams
!
To prepare for this practice
1. Review the instructions in the student notes.
2. Complete the practice.

Practice: Using Market Purchasing
!
To prepare for this practice
1. Review the instructions in the student notes.
2. Complete the practice.

Module 1: Designing Distributed Applications for Windows® 2000 v


Module Strategy

Use the following strategy to present this module:
!
Microsoft Enterprise Strategy
The purpose of this topic is to introduce students to the Microsoft Enterprise
strategy. Focus on defining the three service layers (user, business, and data)
and the technologies that are available for each. This is only an introduction.
Avoid presenting the details that will be provided in subsequent modules.
!
Microsoft Solutions Framework
The purpose of this section is to introduce students to the Microsoft
Solutions Framework.
In the “MSF Motivation” topic, discuss why a successful approach to
application development is needed. The statistics are grim.
In the “Enterprise Services Framework” topic, present MSF in the context
of the Enterprise Services Framework (ESF). It is important to emphasize
the two other frameworks: Microsoft Readiness Framework (MRF) and
Microsoft Operations Framework (MOF). You can refer students to the
MRF URL:
In the “MSF Team Model” topic, discuss how different roles in the MSF
Team model can benefit from this course.
!
Unified Modeling Language
The purpose of this section is to introduce students to UML. The
introduction includes all of the elements they will need to know to complete
the labs. Focus on the two diagrams―use case and class―and the notations
that are used in these diagrams. Avoid providing the details of the
Automated Teller Machine (ATM) sample, which will be covered in detail
in Module 3.
!
Practice: Using Visio 2000 to Create UML Diagrams

The purpose of this practice is to familiarize students with using Microsoft
Visio
®
for UML. Visio is used for design work in the labs in this course.
Most of the tasks in this practice are tasks that students will use in the labs.
!
Design Patterns
The purpose of this section is to introduce students to design patterns. The
concepts involved with design patterns are introduced by describing a
scenario that is complex (without a facade) and by describing how a facade
provides an elegant solution to a recurring design problem.
!
Market Purchasing
The purpose of this section is to introduce students to the Market Purchasing
sample application.
• Introduction to Market Purchasing
The purpose of this topic is to review with the students the business
problem, the vision, and the description.
• Market Purchasing Conceptual Design
The purpose of this topic is to review with the students the conceptual
design of Market Purchasing. The conceptual design is given to the
students as a starting point for the labs in this course.
vi Module 1: Designing Distributed Applications for Windows® 2000


!
Practice: Using Market Purchasing
This practice is an excellent way to familiarize students with the key
concepts of the Market Purchasing application. After completing this
practice, students should be more familiar with what a requisition is and

with how to create one. They should also be familiar with the lifecycle of a
requisition and how it flows through Market Purchasing.
Because this is the first time students have seen Market Purchasing,
consider demonstrating the practice first. Demonstrate all of the steps in the
practice, explaining what is happening during each step. After completing
the practice, let the students experiment with Market Purchasing to try
creating and processing requisitions.
Familiarize yourself with how Market Purchasing works before presenting
this module. Be sure to read all pertinent information about Market
Purchasing, and spend some time running Market Purchasing before you
teach this course. Also, read the Readme.txt file in the root folder of the
Trainer CD to find descriptions of any minor bugs in Market Purchasing
that students may encounter.
• Market Purchasing Logical Design
The purpose of this topic is to describe the process of logical design—
that is, to map the conceptual design to classes by using design patterns
as a mechanism for solving recurring logical design problems.
• Market Purchasing Physical Design
The purpose of this topic is to describe the process of physical design—
that is, to map the logical classes to physical classes, making the correct
technological choices.

Lab Strategy
!
Lab 1: Reviewing the Market Purchasing Conceptual Design
The purpose of this lab is for students to become familiar with the actors
and use cases of the Market Purchasing application. These are important for
creating the logical and physical designs in later labs.
Students need to do a lot of reading to complete this lab. To make the lab
more interesting, you could provide a discussion that leads students through

the conceptual design. Discuss each actor and use case with the students.
Ask them questions about the use cases to test their understanding. It is not
necessary for students to memorize every detail and business rule of Market
Purchasing. The main goal of the lab is for students to understand the larger
issues.
Students might ask questions for which there aren’t answers in the
conceptual design. Rather than trying to find an answer in the conceptual
design, consider making these types of questions discussion points to
provide a further understanding of the design process and maybe Market
Purchasing. The conceptual design represents a hypothetical interaction
between designers, managers, administrators, and users for an unspecified
company. It probably does not answer every possible question for the
solution to that company’s needs.
If you do not provide a detailed discussion of the conceptual design, be sure
to discuss with students their answers to the questions in Lab 1.

Module 1: Designing Distributed Applications for Windows® 2000 1


#
##
#

Overview
!
Microsoft Enterprise Strategy
!
Microsoft Solutions Framework
!
Unified Modeling Language

!
Design Patterns
!
Market Purchasing


In this module, you will learn about the Microsoft
®
Enterprise strategy. You
will also learn about the Microsoft Solutions Framework (MSF) and how it
serves as the basis for design work in this course. You will then learn about the
Unified Modeling Language (UML), which serves as the notation in this
course. You will also learn about the background of design patterns and how
they will be applied in this course. Finally, you will be introduced to Market
Purchasing, the sample application that is used throughout this course.
After completing this module, you will be able to:
!
Describe the Microsoft Enterprise strategy, identify the Microsoft
Windows
®
2000 technologies, and identify the types of applications that you
can build.
!
Identify the technologies and application types that this course will focus
on.
!
Describe design patterns and how they apply to architecture and logical
design.
!
Describe the MSF application model and UML.

!
Describe the attributes of the Market Purchasing application that will be
used in this course.

Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about the key elements in
designing distributed
applications for Windows
2000.
2 Module 1: Designing Distributed Applications for Windows® 2000


Microsoft Enterprise Strategy
User Services
Business Services
Data Services
SQL Server
ADO
IIS ASP COM+ Components
HTML
DHTML
ActiveX
Win32®
Application
DCOM

HTTP


The Microsoft Enterprise strategy is based on the n-tier design and uses
Microsoft tools and services to build scalable, distributed applications.
User Services
User services can be implemented in 32-bit Windows applications (often
referred to as rich clients) and developed by using Microsoft development tools
such as Microsoft Visual Basic
®
, Microsoft Visual C++
®
, and Microsoft Office.
Alternatively, lighter-weight HTML front ends (often referred to as thin clients)
can be developed by using Microsoft FrontPage
®
or Microsoft Visual InterDev
®

and hosted on Internet Information Server (IIS). These HTML-based
applications allow greater reach to clients in intranet and Internet solutions by
using technologies such as Active Server Pages (ASP). Dynamic HTML
(DHTML) and ActiveX
®
controls can be used to provide varying degrees of
functionality.
Business Services
Business services are implemented in Component Object Model (COM)
components. As a result, business functionality can be encapsulated and reused.
COM components can be developed in any COM-aware language, such as

Visual Basic, Visual C++, or Microsoft Visual J++
®
, and they can be
distributed over multiple computers running different operating systems. The
COM+ services in the Windows 2000 operating system provide declarative
transaction management, asynchronous operations, a distributed event
mechanism, security, and ease of deployment. Other infrastructure services
such as ActiveX Data Objects (ADO) can be used to access the data services.
Topic Objective
To provide an overview of
Microsoft Enterprise
strategy.
Lead-in
In this topic, you will be
introduced to the key
technologies used by the
Microsoft Enterprise
strategy.
Module 1: Designing Distributed Applications for Windows® 2000 3


Data Services
Data services are usually provided by relational databases stored in a database
management system such as Microsoft SQL Server
™
. These databases contain
the application data in normalized tables linked by common fields. In some
applications, data may be stored in a nonrelational form; for example, in the
Windows 2000 Directory or Microsoft Exchange Server.
4 Module 1: Designing Distributed Applications for Windows® 2000

#
##
#

Microsoft Solutions Framework
!
MSF Motivation
!
Enterprise Services Framework
!
MSF Team Model
!
MSF Process Model
!
MSF Application Model


MSF is a guide for planning, building, and managing distributed computing
systems. Like a compass, MSF guides product developers and consultants in a
consistent direction without providing the details of how to get there.
This allows everyone to agree on the higher-level aspects of the project,
including vision, architecture, responsibilities, and many other factors that
determine the success of a distributed computing application. Once you
establish a shared vision, you can use detailed methodologies, if necessary, to
achieve your goals. MSF also serves as a useful tool for measuring progress
against the original goals for the project.
MSF models help provide the foundation for effective distributed computing by
addressing the areas identified as key requirements for next-generation systems

throughout the planning, building, and managing life cycle. In this section, the
following topics will be covered:
!
MSF Motivation
!
Enterprise Services Framework (ESF)
!
MSF Team Model
!
MSF Process Model
!
MSF Application Model

Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
about the Microsoft
Solutions Framework.
Module 1: Designing Distributed Applications for Windows® 2000 5


MSF Motivation
Application Development Projects
Challenged
Succeeded
Failed
28%

28%
46%
46%
26%
26%


This slide highlights the need for a solution framework—a set of models that
will guide application development efforts toward success.
The information for this slide appeared in the September 1998 issue of PM
Network and is based on the analysis of more than 23,000 application
development projects. The slide shows that 28 percent of all projects failed, 26
percent succeeded, and a majority of 46 percent were challenged, which means
that they were completed but overextended their budgets, took longer than
originally scheduled, or delivered less functionality than originally promised.
Topic Objective
To provide the reason for
MSF.
Lead-in
In this topic, you will learn
about the outcomes of
projects.
6 Module 1: Designing Distributed Applications for Windows® 2000


Enterprise Services Framework
Building
Planning
Managing
MOF

MOF
MSF
MSF
MRF
MRF


The Enterprise Services Framework (ESF) consists of models that encompass
an application’s complete life cycle: planning, building, and managing. There
are three main frameworks within ESF: Microsoft Readiness Framework
(MRF) focuses on the readiness of an organization to adopt and implement new
Information Technology (IT) solutions; Microsoft Solutions Framework (MSF)
provides the guidelines for successful IT solution development and
implementation; and Microsoft Operations Framework (MOF) provides the
guidelines for successful IT solution operations management.
Each of these frameworks (MRF, MSF, and MOF) has a process model, a team
model, and key deliverables.
The MSF framework also has an application model.
Topic Objective
To provide the context for
MSF.
Lead-in
In this topic, you will learn
about the Enterprise
Services Framework and its
components: MRF, MSF,
and MOF.
Module 1: Designing Distributed Applications for Windows® 2000 7

MSF Team Model
Program
Management
Program
Program
Management
Management
Development
Development
Development
Testing
Testing
Testing
Logistics
Management
Logistics
Logistics
Management
Management
User
Education
User
User
Education
Education
Product
Management
Product
Product
Management

Management


The MSF team model for application development consists of a small team of
peers working in interdependent and multidisciplinary roles. The team model
describes the principals that successful teams use. The team model defines six
roles for a team:
!
Product Management
Manages the customer relationship.
!
Program Management
Responsible for delivering the right product at the right time through
leadership and coordination.
!
Development
Builds and tests features to meet the specification and customer
expectations.
!
Testing
Develops testing strategy, plans, and scripts.
!
User Education
Deliver a product that is useful and usable.
!
Logistics Management
Manages the relationship with operations and supports the day-to-day
operational needs of the team.

Topic Objective

To provide an introduction to
the team model.
Lead-in
In this topic, you will be
introduced to one of the
three important MSF
models: the team model.
8 Module 1: Designing Distributed Applications for Windows® 2000


MSF Process Model


The MSF development process consists of four distinct phases: Envisioning,
Planning, Developing, and Stabilizing. These four phases provide the critical
planning, assessment, and coordination milestones between the customers and
the project team.
Each phase of the development process culminates in an externally visible
milestone. (Deliverables are visible to the internal and external team.) These
milestones are points in time when all team members synchronize their
deliverables with customers and end users; with operations, support, and help
desk personnel; with the distribution channel (commercial software); and with
other key project stakeholders.
In this course, you will work with the Market Purchasing sample application
and other lab exercises from the perspective of an application developer in the
Planning phase. Three of the key deliverables in the Planning phase are the
Conceptual design, Logical design, and Physical design. You will be provided
with the Conceptual design for Market Purchasing. You will also be provided
with some of the Logical and Physical design, and will create the rest of the
Logical and Physical design in lab exercises.

Topic Objective
To provide an introduction to
the process model.
Lead-in
In this topic, you will be
introduced to the process
model.
Module 1: Designing Distributed Applications for Windows® 2000 9


MSF Application Model


An application model is a conceptual view of an application that establishes the
definitions, rules, and relationships that structure the application. It serves as a
basis for exchanging ideas during the logical design of an application, and it
determines how applications are built. An application model shows how the
application is structured, not how it will be implemented. An organization can
use more than one application model to accommodate the different types of
applications that it is developing. Understanding the particular application
model is essential for the project team to effectively develop applications that
will be successful in the organization.
A simple analogy helps to explain the concept of a model. When someone
mentions a house, we assume, without knowing any particulars, that the house
has an entrance, bedrooms, bathrooms, a kitchen, and so on. Even if a particular
house is different from this model (for example, it might have a sleeping loft
rather than bedrooms), the model serves as a starting point for discussing form
and function.
Similarly, an application model describes in general terms what an application
is or, more exactly, what people think a typical application is.

Services in the MSF Application Model
A service is a unit of application logic that implements operations, functions, or
transformations that are applied to objects. Services can enforce business rules,
perform calculations or manipulations on data, and expose features for entering,
retrieving, viewing, or modifying information.
The MSF Application Model introduces a new paradigm for structuring
applications. In the MSF view, 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. COM is an enabling technology when building
applications with Microsoft products and technologies.
Topic Objective
To provide an introduction to
the application model.
Lead-in
In this section, you will be
introduced to the application
model.
10 Module 1: Designing Distributed Applications for Windows® 2000


The MSF Application Model defines three categories of services: user,
business, and data. These services promote a three-tiered logical model for
distributed applications. The MSF Application Model is the recommended
approach for designing such applications.
The Application Model offers a new perspective on creating applications.
Breaking functionality into logical services rather than creating individual
monolithic applications allows multiple applications to share common services.
In this course, you will be working with the Market Purchasing sample
application. The MSF Application Model is reflected in the functional

specification, where the user, business, and data services are identified. You
will update the functional specification as you work through the lab exercises.
Module 1: Designing Distributed Applications for Windows® 2000 11


#
##
#

Unified Modeling Language
!
What is UML?
!
UML – Use Case Diagrams
!
UML – Class Diagrams


This section provides a brief introduction to the Unified Modeling Language
(UML) and its nomenclature. For detailed information refer to UML Distilled,
2
nd
edition, by Martin Fowler with Kendall Scott. In this section, the following
topics will be covered:
!
What is UML?
!
UML – Use Case Diagrams
!
UML – Class Diagrams

Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
about UML.
12 Module 1: Designing Distributed Applications for Windows® 2000


What is UML?
!
A Mixture of Graphical and Textual Notation
for Specifying, Visualizing, and Documenting
Software Systems
!
Elements Include:
$
Use cases and scenarios describing the interactions
between the users and the system
$
Class diagrams describing the logical model of the
application
$
Sequence diagrams showing the order in which various
system events occur
$
Component and deployment diagrams showing the
physical model of the application

The documentation for the Market Purchasing sample application used in this
course includes Microsoft Visio
®
2000 documentation with UML 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 documents. UML represents a collection of best engineering
practices that have proven successful in the modeling of 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 Object Modeling Technique (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 representing
various aspects of the application. These include:
!
Use cases and scenarios describing the interactions between the users and
the system.
!
Class diagrams describing the logical model of the application.
!
Sequence diagrams showing the order in which various system events occur.
!
Component and deployment diagrams showing the physical model of the
application.

Topic Objective
To provide an introduction to
UML.
Lead-in
In this topic, you will be
introduced to UML.
Module 1: Designing Distributed Applications for Windows® 2000 13


A standard notation provides a number of benefits to the developer and systems
architect. It allows the creation of a formal description of the envisioned system
from many points of view at the conceptual, logical, and physical phases of its
design. It also makes it easier for external analysts or consultants to quickly
understand the salient points of the system design.
It is important to understand that the UML itself does not have an associated
process or life cycle. This means that 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 are listed
here. For more information about UML, go to the OMG site at
or refer to the book UML Distilled.
14 Module 1: Designing Distributed Applications for Windows® 2000


UML – Use Case Diagrams
ATM User
Authentication
ATM
Deposit

Withdrawal
Record
Confirmation


The design of an IT solution can be broken down into three design phases:
conceptual, logical, and physical. During the conceptual design phase, you can
use UML to create use case diagrams to describe the interactions between users
or objects and your system. These diagrams will help you understand the
system requirements and the terminology used in the domain area.
Use case diagrams include:
!
Actors
An actor (represented as a stick figure) is a role played by an outside object.
Actors can be human users or other objects. A single actor can perform
many use cases. In the use case diagram in the slide above, one actor is the
ATM User, the other actor is the Automated Teller Machine (ATM).
!
Use cases (represented as an ellipse)
Use cases are narrative descriptions of processes.

Topic Objective
To provide an introduction to
use cases.
Lead-in
In this topic, you will be
introduced to notation for
use case diagrams.
Module 1: Designing Distributed Applications for Windows® 2000 15

UML – Class Diagrams
+Authenticate()
-Card ID
-PIN
ATM User
+Submit()
+Close()
-Date
-Amount
Financial Transaction
Deposit Withdrawal
*
1
Association
Generalization


Once the conceptual design of an IT solution is complete and all actors and use
cases have been mapped onto a use case diagram, the logical design can begin.
The logical design consists of defining the business classes in the IT solution
and presenting them in a class diagram.
UML allows developers to describe a logical design with a class diagram. A
class diagram describes a set of interactions between classes. The preceding
slide shows a class diagram for the ATM system.
A class ATM User has an association (a relationship between instances of
classes represented by a line) with a Financial Transaction.
A financial transaction represents a generalization of the two classes: Deposit
and Withdrawal. It represents the similarities between the two classes.
In addition, a class diagram represents the attributes and operations of a class.

An attribute is information about a class. It is similar to an association. In the
preceding slide, the ATM User class has two attributes: Card ID and PIN.
An operation is a process that a class needs to carry out. In the preceding slide,
the ATM User class has one operation (method): Authenticate.
Topic Objective
To provide an introduction to
class diagrams.
Lead-in
In this topic, you will be
introduced to the notation
for class diagrams.
16 Module 1: Designing Distributed Applications for Windows® 2000


Practice: Using Visio 2000 to Create UML Diagrams


The functional specification for Market Purchasing uses UML notation to
describe the pertinent sections of the design in a Microsoft Word document. All
of the UML diagrams are included in a separate Visio file. While you work
through the lab exercises in this course, you can work with the Visio file to read
and create design elements for Market Purchasing. This practice will help you
become more familiar with using Microsoft Visio 2000 for working with the
Market Purchasing design.

The course uses Microsoft Visio 2000 because it provides more complete
UML support than the Microsoft Visual Studio
®
version of Visual Modeler.

In this practice, you will create a use case diagram and static structure diagram
for a tic-tac-toe game. The model you create is not intended to be a perfect
UML model of tic-tac-toe, but is intended to help you become familiar with
creating diagrams and setting properties in UML by using Visio.
!
Create a new UML model diagram with conceptual and logical design
packages
1. On the Start menu, point to Programs, and click Microsoft Visio. If the
Welcome to Microsoft Visio dialog box appears, click Cancel to close it.
2. On the File menu, point to New, point to Software, and then click UML
Model Diagram. A new model is created.
3. The UML Navigator is in the left pane. Right-click the Top Package folder,
point to New, and then click Package.
4. Name the package Conceptual Design, and click OK.
5. Right-click the Top Package folder again, point to New, and click Package.
6. Name the package Logical Design and click OK.

Topic Objective
To provide practice for using
Visio 2000 to create UML
diagrams.
Lead-in
In this topic, students will
use Visio 2000 to create
UML diagrams.
Note
Module 1: Designing Distributed Applications for Windows® 2000 17


!

Add actors and use cases to the conceptual design package
1. Right-click the Conceptual Design folder, point to New, and click Use Case
Diagram.
2. The toolbar in the center pane will contain use case elements. Select the
Actor element and drag it onto the page.

If it is difficult for you to see the actor symbol on the use case
diagram, maximize the Visio window to increase the size of the diagram. If
the actor symbol is still too small, click a higher value in the Zoom list or
click the Zoom In tool (the magnifying glass with the plus sign in the
center) to increase the size of the diagram even more.

3. Right-click the actor and click Properties. Change the name to Player and
click OK.
4. Drag a use case onto the page just to the right of the Player actor.
5. Right-click the use case and click Properties. Change the name to Start
Game, and click OK.
6. Repeat Steps 4 and 5, and create two more use cases called Make Move and
Set Player Type.
7. Drag a Communicates element onto the page. It looks like a line. Connect
one end to an anchor on the actor, and the other end to an anchor on the
Start Game use case.
8. The Communicates element displays some unnecessary information. Right-
click it, and click Shape Display Options.
9. In the UML Shape Display Options dialog box, clear the First End Name,
Second End Name, and End Multiplicities check boxes, and then click
OK.
10. Drag two more Communicates elements onto the page to connect the Player
actor to the Make Move and Set Player Type use cases.
You can modify the Shape Display options for these connectors as well, if

you want.

!
Add classes and data types to the logical design package
1. Right-click the Logical Design folder, point to New, and click Static
Structure Diagram.
2. Drag a Data Type element onto the page.
3. Right-click the Data Type element and click Properties. In the UML
Datatype Properties dialog box, make the following changes:
a. Click the DataType tab, and change the name to PlayerType. This data
type will enumerate the values that can be represented on a tic-tac-toe
playing board. There are 3 possible values in tic-tac-toe: Empty, X, and
O.
b. Change the stereotype to enumeration.
c. Click the Enumeration tab, and click New to create a new enumeration.
d. Set the name of the enumeration to Empty with a value of 0.
Note
18 Module 1: Designing Distributed Applications for Windows® 2000



e. Create a second enumeration called X with a value of 1.
f. Create a third enumeration called O with a value of 2.
g. Click OK to close the UML Datatype Properties dialog box.
4. Drag a Class element onto the page.
5. Right-click the element and click Properties. In the UML Class Properties
dialog box, make the following changes:
a. Click the Class tab. Change the name to PlayingBoard. This class will
store tic-tac-toe positions as the game is played.
b. Click the Operations tab. Click the New button to create a new

operation.

The Visio interface term “operation” is equivalent to the term
“method.”

c. Select the new operation and change the name to Set. Change the return
type to Boolean and the visibility to public. The Set operation changes a
specific position on the playing board to a specific value (Empty, X, or
O). It returns true if successful.
d. Click the New button to create another operation. Name the operation
Clear. Change the return type to Boolean and the visibility to public.
The Clear operation resets the playing board to all empty. It returns true
if successful.
e. Select the Set operation, and click the Properties button.
f. In the UML Operation Properties dialog box, click the Parameters
tab. There is already a parameter listed for the Boolean return type.
g. Click the New button to create another parameter. Name the parameter
XPos and set the type to Integer. Make XPos an in parameter.
h. Create another parameter called YPos. Make YPos an Integer type and
an in parameter.
i. Create one more parameters called PlayerVal. PlayerVal is of type
PlayerType (the enumeration) and contains a value of Empty, X, or O.
PlayerVal is also an in parameter.
j. Click OK to close the UML Operation Properties dialog box.
k. Click OK to close the UML Class Properties dialog box.
6. Now create a dependency between PlayingBoard and PlayerType by
dragging a Dependency element onto the page. Connect the starting point of
the dependency to PlayingBoard and the ending point (the end with the
arrow) to PlayerType.
7. Using the techniques you learned in the previous steps, create the following

classes by dragging them onto the page and setting their properties
appropriately:
Class
TicTacToe
Methods
MakeMove (in XPos: Integer; in YPos: Integer)
Reset()
Note
Module 1: Designing Distributed Applications for Windows® 2000 19




Both of the TicTacToe methods have a return type of Boolean and
public visibility.

Class
PlayerController
Methods
CmdNewGame()
CmdMove(in XPos: Integer; in YPos: Integer)
CmdEndGame()
RefreshDisplay()
CmdSetPlayerType()

All PlayerController methods have a return type of <None> and
public visibility.

8. Create two more dependencies—one from the PlayerController class to the
PlayingBoard class and one from the TicTacToe class to the

PlayingBoard class.
9. Finally, create a composition (aggregation) relationship between the
PlayerController class and the TicTacToe class. Drag the Composition
element onto the page and connect the diamond point to PlayerController
and the other point to TicTacToe.
10. Save your work, if you want, and then exit Visio.

Your solution should look like the solution found in install
folder\Practices\tictactoe.vsd.
Note
Note