Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Contents
Overview 1
Lesson: An Overview of Physical Design 2
Lesson: Physical Design Analysis 14
Lesson: Physical Design Rationalization 22
Lesson: Physical Design Implementation 34
Activity: Working on the Physical Design 42
Solution Document Narrative 45
Summary 46
Review 48
M
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, place or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no
part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
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.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
Module 6: Creating the Physical Design 1
Overview
Introduction Along with conceptual and logical design, the project team creates a physical
design of the solution during the planning phase. In this introduction to physical
design, you will learn about the purpose of physical design, and the tasks and
deliverables involved in completing the physical design. You will also learn about
the four steps in creating a physical design: research, analysis, rationalization, and
implementation.
More Info As with the conceptual and logical designs, the outputs of the physical
design step are documented in the functional specification, which is one of the
outputs of the planning phase. You will learn more about the functional
specification in Module 4, “Creating the Conceptual Design,” and Module 10,
“Completing the Planning Phase,” of Course 2710, Analyzing Requirements and
Defining Microsoft® .NET Solution Architectures.
You will learn about creating the physical design for the presentation layer in
Module 7, “Designing the Presentation Layer,” and for the data layer in Module 8,
“Designing the Data Layer.”
Introduction Physical design is the last step in the planning phase of the MSF Process Model.
The project team proceeds to physical design after all members agree that they
have enough information from the logical design to begin physical design. During
physical design, the team applies technology considerations and constraints to the
conceptual and logical designs. Because the physical design evolves from the
conceptual and logical designs, its success depends on the accuracy of the previous
two designs. The reliance of physical design on the conceptual and logical designs
ensures that the team will be able to complete a physical design that meets the
business and user requirements.
The following table summarizes the design process in the planning phase.
In this lesson, you will learn about the purpose and goals of physical design. You
will learn about the various steps that the team performs during physical design.
You will also learn about the responsibilities of the various roles in physical design.
In addition, this lesson covers the deliverables of physical design.
Module 6: Creating the Physical Design 3
Introduction Physical design is the third design activity in the planning phase of the MSF
Process Model. Physical design is the process of describing components, services,
and technologies of the solution from the perspective of development requirements.
Physical design defines the parts of the solution that will be developed, how they
will be developed, and how they will interact with each other. The following
illustration shows where the task of creating the physical design is in the MSF
Process Model.
While working on the physical design, the team creates designs based on prior
designs and refines the architecture of the solution that has been created up to this
time. These designs apply real-world technology constraints to the logical model,
including development tools and the deployment environment of the solution. In
addition, the team tries to develop a solution that addresses design considerations
such as security, availability, scalability, manageability, and performance. The team
tries to achieve these goals in a manner that is appropriate to the project and its
requirements.
Module 6: Creating the Physical Design 5
Inputs to physical The inputs to the physical design are all of the artifacts that have been created up to
design this time. This includes the logical object model, a preliminary user interface
design, and a logical data model generated during logical design. Artifacts such as
the project plan might get minor updates and are referred to in setting the deadlines
for the milestones of physical design.
During the physical design, the project team reduces the difference between the
logical design of the solution and the implementation by defining the solution in
terms of implementation details. The purposes of the conceptual design and logical
design processes are to understand the business and its requirements and to design
a solution that meets those requirements. The physical design process primarily
addresses how to implement this design.
Outputs of the At the end of the physical design, the team delivers specifications for a set of
physical design components, Microsoft .NET assemblies, binaries, and link libraries; details of the
user interface for the solution; the database schema; database objects such as
triggers, indexes, and stored procedures; and details of any reports that will be used
by the solution.
Consider the analogy of designing and building a house. In logical design, you
determine requirements such as overall electrical capacity, levels of light, and
plumbing fixtures required by the house. In physical design, you select the
appliances that you will use, the electrical requirements for each device and the
corresponding wiring, and circuit specifications.
To proceed from logical design to physical design, the team uses the layered
services-based architecture.
Note You can learn more about application architectures in Module 4, “Creating
the Conceptual Design,” in Course 2710, Analyzing Requirements and Defining
Microsoft .NET Solution Architectures.
Scope of the physical The following table explains the scope of physical design.
design
During physical design, the project team develops the component specifications
and deployment topology with which the development team will work to create the
solution. The development team takes the target topology into consideration while
building the solution.
Remember that in physical design you are still designing the solution and not
developing a version of the solution that can be released and deployed.
6 Module 6: Creating the Physical Design
Difference between Whereas during logical design the team views the problem from the perspective of
logical and physical the project team, during physical design the team views the problem from the
designs perspective of the development team. During the logical design, the team
documents the activities, constraints, and assumptions of the business. During the
physical design, the team defines a solution addressing the constraints of the
selected development technologies and deployment environment. In this sense,
physical design views the design from a more technical viewpoint.
Basically, physical design is a refinement of the logical design that leads to the
implementation of the design to create the solution.
Module 6: Creating the Physical Design 7
Introduction The project team creates the physical design with the following goals:
Introduction During physical design, each team role has a different set of responsibilities. The
following table summarizes the tasks for each team role during physical design.
Introduction At the end of the physical design phase, the project team has enough completed
design documentation for the development team to begin creating the solution.
Specific documentation can vary from solution to solution. The deliverables at the
end of physical design include:
Introduction Physical design is the last stage of the planning phase. The planning phase ends
when the team reaches the project plan approved milestone. The project team
completes the physical design before reaching this milestone.
The preceding illustration shows the physical design and its relationship to the
conceptual and logical designs in the planning phase. The physical design phase
has four steps and associated baselines, which are also depicted on the slide.
Steps in physical The four steps in physical design are:
design
■ Research, during which the team performs the following tasks:
● Determining physical constraints and requirements
● Identifying any infrastructure changes or concerns
■ Analysis, during which the team performs the following tasks:
● Developing a preliminary deployment model
● Selecting technologies that will be used to develop the solution
■ Rationalization, during which the team performs the following tasks:
● Determining a packaging and deployment strategy
● Packaging components and services
● Distributing components across the network topology
■ Implementation, during which the team performs the following tasks:
● Determining a programming model
● Specifying component interfaces, attributes, and services
Note The implementation baseline leads into the baseline of the physical design.
Module 6: Creating the Physical Design 11
Introduction During the physical design phase, the team focuses on creating technical solutions
based on the logical design. To derive these technical solutions, the team must
consider constraints such as the enterprise architecture, the business process, and
the infrastructure. In addition, the team needs to consider the architectural and
performance requirements of the solution, such as security, availability, scalability,
and manageability. For example, perhaps the solution needs to be able to handle a
specified number of transactions per second. During the research step of physical
design, the team identifies these constraints and requirements.
Deliverables of the The deliverables of the research step of physical design describe the current
research step infrastructure of the business and provide the foundation for the analysis,
rationalization, and specification steps of physical design. The deliverables of the
research baseline include:
You gather physical requirements from sources such as the current business
environment and the enterprise architecture. Some typical physical requirements of
a solution are:
■ Performance
■ Cost and benefit
■ Ease of use
■ Deployability
■ Supportability
■ Reliability
■ Reusability
■ Budget
■ Schedule
■ Network topology
■ Data topology
■ Component topology
■ Technology guidelines
■ Security
Resolving conflicts Often the requirements and constraints conflict with each other. By identifying
between requirements these conflicts early in the design and addressing them, you can reduce potential
and constraints problems early. Then, if a problem occurs, you have a plan for mitigating it. For
example, an application might require 100 megabits per second (Mbps) of
bandwidth on the network, whereas the existing network infrastructure can support
only 10 Mbps.
■ Identify the requirements that are absolutely necessary for the project. Identify
conflicts among requirements and also analyze the impact of any constraints.
Make as many tradeoff choices as possible before development begins.
■ Identify the areas in the infrastructure where the requirements might conflict
with the constraints.
■ Analyze the differences between the requirements and constraints and
determine whether you need to make some kind of choice to resolve the
conflict. For example, you might choose to upgrade the network to support 100-
Mbps speeds. You must make these choices early in the design phase to avoid
creating a solution that cannot be implemented.
■ Brainstorm solutions with all groups associated with the project—business,
users, project team, and development team.
Module 6: Creating the Physical Design 13
You can address the differences between requirements and constraints in the
following ways:
■ Accept the gap without doing anything. This choice implies that the gap is
acceptable for the initial release of the solution. Clearly describe the
consequences of accepting the gap. In addition, all stakeholders must reach a
consensus that this is the appropriate choice.
■ Identify a way to work around the gap. Working around the gap might not be
the optimal solution in the long term. However, it may be necessary because of
constraints such as limited project resources.
■ Defer addressing the requirement until later stages of the project. The project
team can decide to address a requirement in later stages of the project. The
team can modify constraints by providing a business case for the change and
identifying the impact of the change.
14 Module 6: Creating the Physical Design
Introduction During the analysis step of physical design, the team creates and refines the
physical design models by using the logical design documentation. In addition, as
in each phase, the team refines artifacts that are related to the design and
specifications (UML models, requirements, and use cases) in addition to those
related to the project (risk documents, project plans and schedules, and the actors
catalog). Physical design involves selecting candidate technologies for the
implementation, based on the application requirements. After selecting the
probable technologies, the team creates a preliminary deployment model.
In this lesson, you will learn how to refine Unified Modeling Language (UML)
models. You will also learn how to select candidate technologies and create a
preliminary deployment model.
Lesson objectives After this lesson, you will be able to:
Introduction At the end of the logical design, the team has UML models for objects, services,
attributes, and relationships in the solution. Typically, the team uses the artifacts
that best represent their intent and decisions to manage the complex parts of the
project. This includes the following set of deliverables:
Class diagrams Class diagrams are used in logical design to represent the static structure of the
application object model. During physical design, the team performs the following
tasks to refine UML class diagrams:
The following illustration shows the class diagram for the Order components:
Sequence diagrams Sequence diagrams represent the interaction between objects and the dynamic
aspect of the object model. They are usually used to clarify complex class
relationships that might not be easily understood by reviewing the static methods
and attributes of a group of classes. In the physical design, the team performs the
following tasks:
The following illustration shows the sequence diagram for the Product and Catalog
objects.
Activity diagrams Activity diagrams are used to represent the state transition and flow of an
application. You can use activity diagrams instead of sequence diagrams, and you
can also use sequence diagrams instead of activity diagrams. During the physical
design, the project team refines activity diagrams to:
Component diagrams Component diagrams are used to represent the dependencies between components
or component packages. As with sequence and activity diagrams, they are typically
used in more complex situations. In the physical design, the project team might
create component diagrams to:
The following illustration shows the component diagram for the Order process.
20 Module 6: Creating the Physical Design
Introduction Taking artifacts such as the application architecture, the team structure, the project
schedule, the requirements, the risks assessment document, and candidate
technologies into consideration, the team can draft a preliminary deployment
model. The preliminary deployment model includes network, data, and component
topologies. This model enables the project team and other stakeholders to review
the design. Remember that during physical design the team proposes topologies for
solutions that have not been selected yet.
Network topology The network topology is an infrastructure map that indicates hardware locations
and interconnections. The map shows workstations and servers and describes their
functions. Additionally, the topology shows the network infrastructure that
connects the computers.
On the CD The illustration shows a sample network topology. For the complete
network topology for the Adventure Works Cycles case study, see AWC – Network
in the Module 6 solution documents under Appendices on the Web page on the
Student Materials compact disc.
Deployment topology The deployment topology is a map that indicates the locations of packages,
components, and their services in relation to the network topology, in addition to
data store locations. The map shows the physical distribution of the components
and their locations across the various service layers. The current-state version
should already exist if the team is not working on a completely new solution. You
can add any new components and services required by the application at this time.
On the CD The illustration shows a sample component and data topology. For the
complete component and data topology for the Adventure Works Cycles case
study, refer to AWC Component Topology in the Module 6 solution documents
under Appendices on the Web page on the Student Materials compact disc.
22 Module 6: Creating the Physical Design
Introduction After selecting candidate technologies, the project team proceeds to the
rationalization step of physical design. In this step, the project team designs
services-based components for services-based applications and develops a
distribution strategy for those components.
In this lesson, you will learn about the deliverables of the rationalization step. You
will also learn how to develop strategies for distributing and packaging the services
that have been designed. In addition, you will learn the effect of coupling and
cohesion on the packaging strategy. You will also create a component topology and
validate and refine the topology.
Lesson objectives After this lesson, you will be able to:
Introduction The rationalization step results in several deliverables. These deliverables describe
the technologies, strategies, and topologies that you have designed for the solution.
Introduction The rationalization step is an iterative process during which the project team tries
to design an optimal solution. One of the goals of the rationalization step is the
distribution of services and the packaging of those services into components.
Definition of The distribution strategy is a rationale for determining where the services will be
distribution strategy located in the solution architecture. Distribution is services-based and not
component-based.
Definition of packaging The packaging strategy is a rationale for determining which services go into each
strategy component. You might have multiple strategies in a single solution. For example, a
common practice is to divide the business services into business objects
(commonly called a business facade layer) without incorporating the business rules
directly in the class interfaces. This practice allows the team to create a business
rules layer that incorporates most of the business rules (limiting discounts by
authorization, for example). The business rules layer can then be changed and
redeployed without modifying the business objects. Creating this layer limits the
changes to interfaces that communicate with these objects. This strategy can be
decided in advance.
■ The ViewState property. Web Forms pages provide the ViewState property as a
built-in structure for automatically retaining values between multiple requests
for the same page. The state is contained in a structure within the page code.
Although this is an enhancement in server resource use, security, and
implementation, the page can display and post slowly if large values are stored.
Note For more information, see “Introduction to Web Forms State Manage-
ment” in Visual Basic and Visual C#® Concepts on the MSDN Library Web
site at http://msdn.microsoft.com/library/en-us/vbcon/html/vbconintroduction-
towebformsstatemanagement.asp.
Note For more information about state management options, see “State Man-
agement Recommendations” in Visual Basic and Visual C# Concepts on the
MSDN Library Web site at http://msdn.microsoft.com/library/default.asp?url=/
library/en-us/vbcon/html/vbconchoosingserverstateoption.asp.
26 Module 6: Creating the Physical Design
■ Scalability. Scalability involves the ability to quickly and easily extend the
solution to handle more transactions or more users.
■ Performance. Performance of a system includes the response time of the
system and the speed with which a system performs application tasks.
■ Manageability. Manageability of a system includes the ease with which the
system can be managed on all levels.
■ Reuse. Reuse addresses the ease with which components can be reused by
other applications.
■ Granularity. Granularity refers to the number of services grouped into an
object and the size and number of objects grouped in a single component
While defining a strategy for distributing and packaging the services of the
business solution, the team must consider the solution and its physical
requirements and constraints.
When using multiple strategies, the team should strive for a balance between the
various requirements and constraints of the solution. For example, the team might
decide to choose a strategy focusing primarily on the performance needs of the
application. This might affect the scalability of the solution. In such a scenario, the
team must decide how to handle this tradeoff.
Module 6: Creating the Physical Design 27
Introduction One of the features of a good component plan is high cohesion and loose coupling.
Cohesion is the relationship among different internal elements of a component.
Coupling is the relationship of a component with other components.
Cohesion A component whose services are closely related is said to have high cohesion. The
reliability of a component is directly dependent on the close relation between its
services. Cohesion can be both beneficial and detrimental, depending on the cause
of the cohesion. Cohesion can be:
■ Functional. A unit performs only one task. This is the strongest type of
cohesion.
■ Sequential. A unit contains operations that must be performed in a specific
order and that must share the same data.
■ Communicational. Operations in a unit use the same data but are not related in
any other way. This type of cohesion minimizes communication overhead in the
application.
■ Temporal. Operations are combined because they are all performed
simultaneously.
Not all cohesion is beneficial. Other types of cohesion can result in a solution that
is poorly organized and difficult to understand, debug, and modify. Ineffective
types of cohesion include the following:
Coupling Coupling can be tight or loose. When a component is tightly coupled, the
component depends heavily on external components to accomplish its function.
When a component is loosely coupled, the component is not dependent or is less
dependent on external components.
Typically, the looser the link that binds components to each other, the easier it is for
the developer to use individual components without causing problems. A
component should depend as little as possible on other components. If a
dependency exists, the connection between the dependent components must be as
clear as possible so that you can easily define interfaces. Another reason to
represent the dependencies clearly in design is to ensure that future decisions do
not cause a series of failures in the design.
Module 6: Creating the Physical Design 29
Introduction The primary focus of the physical design rationalization is distributing and
packaging services. In the first step of this process, you package the services into
layers: user, business, and data.
To begin the process of distribution, identify the major categories of services in the
physical object model and break them into their individual, layer-based services.
For each business object, group the resulting low-level services into three layers:
the user services layer, the business services layer, and the data services layer.
30 Module 6: Creating the Physical Design
Introduction After packaging services into components comes the tasks of distributing the
components across the network topology and creating a component topology. To
start the distribution process, the team identifies categories of services—user,
business, and data—for each node in the network topology. These categories serve
as the baseline for distribution. The distribution strategy evolves as the design is
validated against the solution requirements.
The preceding illustration shows the three layers of services and the corresponding
components for a sample application.
Guidelines for To help with the distribution of layers, use the following guidelines:
distributing layers
■ Distribute user services to the Web servers or to the client computers.
■ Distribute business services to application servers or to Web servers.
■ Distribute data services to the data locations identified in the data topology,
including database servers or other locations where the data services will
reside.
■ After identifying where service layers will reside, distribute the preliminary
components into their indicated service layers. This represents the initial
component topology that will evolve throughout the rationalization process.
Module 6: Creating the Physical Design 31
The following illustration shows the logical partitioning of the three service layers
in the component model of a generic order processing system.
32 Module 6: Creating the Physical Design
Introduction A deployment model is a diagram that associates the application and its services to
the actual server topology. Its purpose is to allow the development team and the
release management team to design and plan the server topology and configuration.
It uses the network topology and indicates the application services that will be
deployed on each server.
Editing, saving and You can begin drawing the deployment model in any medium. Using a digital
converting sketches camera, you can quickly save detailed sketches drawn on a whiteboard or on paper.
The Tablet PC can make it easier still to capture and convert handwritten notations
of deployment models into formalized, presentation-quality media, such as
Microsoft Visio® diagrams.
Developing a model Creating a deployment model is usually an iterative process. As the team learns
from existing materials more details about existing and proposed services and networks, the deployment
model can be modified. For a project whose purpose is to develop an application
that will fit into an existing information technology infrastructure, a deployment
model probably already exists. The development team can use an existing
deployment model as the basis for future designs. Even so, the development team
will need to ensure that all of the details shown in the existing deployment model
are still current.
Example of a The preceding illustration shows a diagram of a deployment concept.
deployment model
Module 6: Creating the Physical Design 33
Introduction After creating the component and deployment models, the project team validates
and refines these models.
Validating component During the physical design, the team should validate the component topology
and deployment against the strategies and requirements of the solution. Validation occurs on an
models ongoing basis. This ongoing validation enables the team to iterate the design as
required.
The project team arrives at an optimal solution by iterating through the process of
validation and testing, and by using prototypes to test and tune the packaging and
distribution of the components. The team should stop iterating through the solution
when only marginal improvements can be made to the solution.
Refining component The key to refining the component topology is to work with services, not
and deployment components. To evolve the component topology, undo the preliminary component
models packaging and redistribute the services to meet the needs of the solution.
For example, a requirement states that users must be able to scroll through an entire
list without interruption. For best performance, the project team might choose to
distribute some of the data services on the client.
After the services have been redistributed, you need to repackage the services. At
each location, package the services according to the strategies identified earlier. For
example, if ease of deployment is the main goal, the project team might choose to
have only one component on the client computer rather than many small
components.
Tip Always take the concepts of cohesion and coupling into consideration when
repackaging and redistributing. High cohesion and loose coupling are the ideal, but
that ideal might not be practical given the requirements of the solution.
34 Module 6: Creating the Physical Design
Introduction During the implementation step of physical design, the team specifies the
programming model that the development team will use, the interfaces for each
component, and the internal structure of each component. The deliverables of
physical design implementation include a programming model; component
specifications for interfaces, attributes, and services; and a baseline component
specification. The level of detail of for each of these deliverables depends on the
level of interaction between project management and the development team.
In this lesson, you will learn about the implementation step of physical design. You
will learn about the programming model. You will also learn how to specify
component interfaces and define the internal structure of components. In addition,
you will learn about designing the user interface (UI) and database models.
Lesson objectives After this lesson, you will be able to:
Introduction Because physical design presents the solution from the developer’s perspective, the
project team should provide the developers with specifications for component
design and technology selection. Component specification provides the
development team with enough detail to develop the components of the solution.
The specification includes interfaces and the scope of various services and
attributes of components. The specification is directly related to the programming
model selected for implementation.
The standards prescribed by a programming model might vary for different aspects
and service layers of an application. Physical design standards reflect the
implementation of the guidelines prescribed by the architecture. If the team decides
to implement a stateless server and a stateful client, all attributes are eliminated
from class definitions in the physical design. The stateful client might use
disconnected .NET datasets as the preferred means of transferring subsets of
information to the client.
36 Module 6: Creating the Physical Design
Design considerations There are several aspects of the programming model that you should consider,
for the programming including the following:
model
■ Implementation technologies. Implementation technologies consist of the
programming languages, application programming interfaces (APIs), servers
and server technologies, and other technologies that are required for
implementing a solution. To efficiently use these technologies, you must use a
specific programming model. For example, the .NET Framework uses the
common language runtime, but you may need to use the interoperability
features available to access existing Component Object Model (COM) objects
or COM+ objects. COM and COM+ are now called .NET Enterprise Services.
Note For more information about integrating COM+, see “COM+ Integration:
How .NET Enterprise Services Can Help You Build Distributed Applications,”
on the MSDN® Library Web site at http://msdn.microsoft.com/msdnmag/
issues/01/10/complus/default.aspx.
■ Stateful versus stateless objects. The state that an object maintains can directly
affect its performance, scalability, and implementation complexity. Stateful
objects retain information that was used in one or more client calls; stateless
objects do not maintain transaction-related information. When creating stateful
objects, especially in Web-based solutions, the team must determine where and
how the state will be maintained; in contrast, stateless objects typically send
and receive all necessary information when the objects are invoked or when
objects complete a transaction.
■ In-process versus out-of-process function calls. In-process components
perform all execution within a single process, thus eliminating marshalling
overhead and increasing performance. Out-of-process components perform
their tasks in a process that is separate from that of the invoking client, thus
incurring marshalling overhead and degrading performance.
■ Cohesion and coupling. Cohesive components are closely related to other
objects with regards to their functionality. Coupling refers to the strength of
component interconnections and interactions. In determining how to apply
these principles to a programming model, you should design highly cohesive
components and loosely coupled objects. If an object is highly cohesive, its
methods and properties are tightly related, and the objects within a component
are related. Loosely coupled objects are not highly dependent on the interface,
the state, or the status of other objects. The communication between loosely
coupled objects is implemented by means of messages.
■ Connected versus connectionless modes. In distributed component
environments, various components participating in the service must have real-
time, live connections to each other to function properly. If these real-time
connections are severed, the components involved in the interaction fail.
Because real-time components must typically be run in connected mode,
components written to run in a connectionless environment must be able to
reestablish connections as required.
Module 6: Creating the Physical Design 37
Although not a part of the programming model itself, the skills and experience of
the technical people who will implement the programming model are an important
consideration.
Note Typically, there is not just one programming model for all components. An
application might use many programming models, depending on the requirements
of the various components.
38 Module 6: Creating the Physical Design
Introduction After describing the programming model, the project team defines how the
components will interact. This interaction is documented by the component’s
interfaces, which describe how to access their services and attributes. An interface
can represent one or more services. The interface provides a means for requesting a
service to perform an operation and a means for receiving information about the
resulting attributes. The external structures of the component are outlined in the
component interfaces. A component interface:
The only way to access the underlying services within a component is to use the
component’s published interface. A poorly defined interface can negatively affect
other parts of the solution.
Introduction The presentation layer enables users to interact with a system. It provides a
communication mechanism between users and the business services layer of the
system. There are two types of users: human users who require an interface through
which they can interact with the system, and other computer systems. Although
other computer systems do not require a user interface, they require an
intermediary to the system with which they will interact. Typically, this
intermediary will be the user process components or an XML Web services
interface that facilitates communication between the two layers.
Note A user interface provides a visual means for humans to interact with
systems. User services provide the navigation, display, validation, and error-
processing logic.
Inputs to UI model To design the user interface layer (UI components and UI process components), the
design project team uses the outputs of the logical design. These outputs include:
More Info You will learn more about user interface design in Module 7,
“Designing the Presentation Layer,” in Course 2710, Analyzing Requirements and
Defining Microsoft .NET Solution Architectures.
Module 6: Creating the Physical Design 41
Introduction During logical design, the database team explores various ways in which the
information needs of the conceptual design can be structured in a logical model for
a database.
Database design During physical design, the database team must consider:
considerations
■ Physical database constraints, such as memory and disk size.
■ Performance tuning considerations, such as deadlock detection, indexing, and
hot spots.
■ Primary keys and foreign keys.
■ The design of triggers.
■ Stored procedure guidelines.
■ Application object model considerations.
■ Indexing specifications.
■ Partitioning data.
■ Data migration from the previous database systems.
■ Operational considerations, such as cluster failover, backup process, and update
process.
More Info You will learn more about database design in Module 8, “Designing the
Data Layer,” in Course 2710, Analyzing Requirements and Defining Microsoft
.NET Solution Architectures.
42 Module 6: Creating the Physical Design
Estimated time to In this activity, you will use what you learned in the lessons to create a class model
complete this activity: and a component model diagram.
30 minutes
Module 6: Creating the Physical Design 43
Following are some of the possible discoveries and decisions that have been made
in C06Ex1_Answer.vsd.
The customer needs to be able to select items for purchase from the catalog while
still browsing the catalog. The group of selected items might change in many ways
before it is submitted as an order. To meet these needs, a new object is added to the
design: the ShoppingCart object.
44 Module 6: Creating the Physical Design
AWC Physical Object This diagram shows the class diagram for the following objects: Catalog,
Model.vsd CatalogItem, Order, OrderDetail, Security, Role, Customer, Employee, and
ShoppingCart.
Order Class Model.vsd This diagram shows the class diagram for only the Order and OrderDetail objects,
broken out separately from the AWC Physical Object Model.vsd.
46 Module 6: Creating the Physical Design
Summary
■ During physical design, the project team defines the services and technologies
that will be provided by the solution.
■ Physical design is defined as the process of describing the components,
services, and technologies of the solution from the perspective of the
development team.
■ The goals of physical design are:
● Transforming the logical design into specifications for a set of components.
● Providing a baseline for implementing the design.
● Identifying appropriate technologies for development.
● Creating a structural view of the solution from the perspective of the
development team.
■ There are four steps in physical design: research, analysis, rationalization, and
implementation.
■ The new deliverables of physical design include:
● Class diagrams
● Sequence diagrams
● Baseline deployment model
● Programming model
● Component specifications
■ The deliverables of the research baseline include:
● Current network topology
● Current data topology
● Current component topology
● Physical application requirements
● Risk assessment and mitigation plan
Module 6: Creating the Physical Design 47
■ During the research step of physical design, the project team identifies the
requirements and constraints of the solution and tries to reduce the gap between
the two.
■ During the analysis step of physical design, the project team refines the UML
model created during the logical design, which includes an objects and services
inventory, class diagrams, sequence diagrams, and activity diagrams.
■ During the analysis step of physical design, the project team creates a
preliminary deployment model that includes network, data, and component
topologies.
■ The network topology is an infrastructure map that indicates hardware locations
and interconnections.
■ The data topology is a map that indicates data store locations in relation to the
network topology.
■ The component topology is a map that indicates the locations of components
and their services in relation to the network topology.
■ The deliverables of the rationalization step include:
● Distribution and packaging strategy
● Services-based preliminary components
● Deployment models
● Baseline deployment model
■ The distribution strategy is a rationale for determining where services will be
located in the solution architecture. Distribution is services-based, not
component-based.
■ The packaging strategy is a rationale for determining which services will go
into each component. You might have multiple strategies in a single solution.
■ Cohesion is the relationship among various internal elements of a component.
■ Coupling is the relationship of a component with other components.
■ To distribute services, identify the major categories of services in the business
object model and break them into their individual, layer-based services.
■ To package services, group the low-level services into three components: the
user services component, the business services component, and the data
services component.
■ The deployment model links the application and its services to the actual server
topology.
■ The team must validate the component topology against the strategies and
requirements of the solution.
■ To refine the component and deployment model, the team must undo the
preliminary component packaging and redistribute the services to meet the
needs of the solution.
■ During the implementation step of physical design, the team specifies the
programming model that the development team will use, the interfaces for each
component, and the internal structure of each component.
■ A programming model describes how components will be structured, based on
the goals of the solution and the technologies being implemented.
■ A component’s interface describes how to access its services and attributes.
■ The presentation layer enables users to interact with a business system and
provides a communication mechanism between the user and the business
services layer of the system.
48 Module 6: Creating the Physical Design
Review
1. What are the goals of physical design?
5. What does the project team do during the research step of physical design?
Module 6: Creating the Physical Design 49
6. How does the project team handle the gap between requirements and
constraints?
7. During the analysis step of physical design, how does the project team use the
list of objects and services created during logical design?
8. How does the project team refine the class diagrams during the analysis step of
physical design?
10. What is the difference between the network topology and the data topology of
the deployment model?
50 Module 6: Creating the Physical Design
11. What is the difference between the distribution strategy and the packaging
strategy?
15. What are the types of users of the user services layer of an application?