Tài liệu Module 10: Completing Physical Design ppt

Module 10: Completing Physical
Design

352 Module 10: Completing Physical Design




Module Overview

Module 3: A Services-Based
Approach to Solution Design
Module 4: Business Solution
Conceptual Design
Module 5: Business Solution
Logical Design
Module 6: Beginning Physical
Design
Module 1: Course Overview
Module 2: Solution Design Using
the MSF
Module 7: Selecting Solution
Technologies
Module 8: Solution Design and the
Component Object Model
Module 9: Designing Solutions with
Microsoft Technologies
Module 10: Completing the
Physical Design
Module 11: Designing the

Presentation Layer
Module 12: Introduction to
Functional Specifications
Designing Business
Solutions
Physical Design
Specification
Review
Activity 10.2: Refining
Preliminary Distribution for
Performance
Module 10:
Completing the
Physical Design
Physical Design
Rationalization Basics
Rationalization:
Distribution and
Packaging
Activity 10.1: Creating and
Distributing Preliminary
Components
Activity 10.3: Factors
Impacting the Programming
Model
Module 10: Completing Physical Design 353



!

!!
!

Overview
"
Physical Design Rationalization Basics
"
Rationalization: Distribution and Packaging
"
Activity 10.2: Refining Preliminary Distribution for
Performance
"
Physical Design Specification
"
Activity 10.3: Factors Impacting the
Programming Model
"
Review
In this module
In this module


After completing this module, you will be able to:
"
Complete the rationalization step of physical design.
"
Derive a physical design from a logical design.
"
Describe the deliverables of a physical design specification.
"

Describe a component specification.

Slide Objective
To provide an overview of
the module topics and
objectives.
354 Module 10: Completing Physical Design



!
!!
!

Physical Design Rationalization Basics
In this section
In this section
"
Deliverables of the Rationalization Baseline
"
Distribution and Packaging Strategy
"
Packaging Terminology: Cohesion
"
Packaging Terminology: Coupling
"
Distribution and Packaging Strategy
Considerations

The focus of the rationalization step is on designing services-based components
and developing a distribution strategy for those components.
In this section, you will learn about how to determine a strategy for the
distribution and packaging of the services that you have designed. You will also
learn about how coupling and cohesion will affect your packaging strategy.
Slide Objective
To provide an overview of
the topics and activities in
this section.
Module 10: Completing Physical Design 355



Deliverables of the Rationalization Baseline
Task
Determining a packaging and
distribution strategy
Transforming objects into
services-based components
Distributing components across
topologies
Using strategy and prototypes to
refine packaging and distribution
Deliverable
Packaging and distribution strategy
Services-based preliminary
components
Deployment model
"
Future network topology

"
Future data topology
"
Future component topology
Baselined deployment model
Rationalization Baseline
Rationalization


The rationalization baseline results in several deliverables. These deliverables
describe the technologies, strategies, and topologies that you have designed for
the solution.
Slide Objective
To list the deliverables of
the rationalization baseline.
356 Module 10: Completing Physical Design



Distribution and Packaging Strategy
"
Distribution Strategy
$
Rationale for determining which services go where in the
solution architecture
$
Distribution is services-based, not component-based
"
Packaging Strategy
$

Rationale for determining which services go into which
components
$
May have multiple strategies in a single solution


The rationalization step is an iterative process that strives for the optimum
solution at a particular point in time.
The following strategies can be used to help determine an appropriate overall
component distribution and packaging strategy:
"
Scalability involves the ability to quickly and easily extend the solution to
handle more transactions or more use.
"
Performance involves the response time of the system and the speed with
which a system performs application tasks.
"
Manageability involves the ease with which an application can be managed
on all levels.
"
Reuse involves the ease with which components can be reused by other
applications.
"
Business context involves the separate business functions such as
accounting or sales.
"
Granularity involves the number of services and objects that are packaged in
a component.

Slide Objective

To define what is meant by
distribution and packaging
strategy.
Lead-in
One of the main goals of the
rationalization step is the
distribution of services and
the packaging of those
services into components.
Delivery Tip
Do not spend too much time
on this topic; it is just the
introduction to distribution
and packaging. The details
are presented in the next
section.
Module 10: Completing Physical Design 357



Packaging Terminology: Cohesion
"
Defines how well internal parts of a component relate to
one another
$
High level: Print Timesheet Component contains only
services that help it to print timesheets
$
Low level: Application Server Component contains all
services that exist on the application server

"
High cohesion is the goal
$
Provides a better definition of the component’s function
and behavior


Cohesion refers to how the operations in a specified unit, a component, are
related. The closer the relation between the services is, the higher the reliability
of the component. Cohesion is beneficial when it is as follows:
"
Functional
A unit does only one thing. 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 aren’t related in any other way.
This type of cohesion minimizes communication overhead in the system.
"
Temporal
Operations are combined, because they are all performed simultaneously.

Not all cohesion, however, 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:
"
Procedural

Operations are grouped together because they are executed in a specific
order. Unlike sequential cohesion, the operations do not share any of the
same data.
"
Coincidental
Operations are grouped without any discernible interrelationship.

Slide Objective
To define cohesion as an
aspect of packaging and to
define the importance of a
high level of cohesion.
Lead-in
When packaging services
into components, it is
important to take into
account how the services of
a component relate to each
other.
Delivery Tip
The concepts of cohesion
and coupling are important
to the process of distribution
and packaging of services.
Make sure that the students
understand these concepts.

Facilitate a discussion if it is
required.
358 Module 10: Completing Physical Design

Packaging Terminology: Coupling
"
Defines how each component relates externally to other
components
$
Tight: Component relies heavily on other components in
order to accomplish its function
$
Loose: Component is not dependent or less dependent
on other components to accomplish its function
"
Loose coupling is the goal
$
Provides greater component independence, enables
distribution flexibility, and leads to better-defined and
simpler interfaces


Typically, the looser the link that binds components to each other, the freer the
designer is to use individual components without causing problems. A
component should depend as little as possible on other components.
If a dependency exists, however, the connection between those components
must be as clear as possible for easier definition and greater simplicity in
determining interfaces.

Slide Objective
To define component

coupling and the importance
of loose coupling.
Lead-in
When packaging services
into components, it is also
important to take into
account how components
relate to each other.
Delivery Tip
The concepts of cohesion
and coupling are important
to the process of distribution
and packaging of services.
Make sure that the students
understand these concepts.

Facilitate a discussion if it is
required.
Module 10: Completing Physical Design 359



Distribution and Packaging Strategy Considerations
"
Each strategy will be greatly impacted by solution
architecture and infrastructure
$
If strategy involves performance and a one-user solution,
then services may all reside on one computer
$

If strategy involves performance and thousands of users,
then services may be distributed across many
computers
"
Balance is required when multiple strategies are used
$
Performance and reuse may mean one machine but
many small components


When deciding on a strategy for distributing and packaging the services of the
business solution, you to must consider the solution and physical requirements
and constraints.
Although a single strategy — such as installing all services on a single machine
— might work in some cases, you will more likely have to use multiple
strategies to accomplish your goals. When using multiple strategies, you should
strive for a balance between the various requirements and constraints of the
solution.
Slide Objective
To describe two
considerations when
distributing and packaging
services.
Lead-in
When deciding how to
distribute and package the
solution services, you must
take into account solution
and physical requirements.
360 Module 10: Completing Physical Design

!
!!
!

Rationalization: Distribution and Packaging
"
Creating Preliminary Components
"
Transforming Objects into Components
"
Distributing Preliminary Components
"
Activity 10.1: Creating and Distributing Preliminary
Components
"
Validating Distribution and Packaging
"
Refining Distribution and Packaging
In this section
In this section


Creating and refining a component topology is a crucial aspect of the services-
based approach to business solution design.
In this section, you will learn how to create an initial component topology and
how to validate and refine the topology.
Slide Objective

To provide an overview of
the topics and activities in
this section.
Module 10: Completing Physical Design 361



Creating Preliminary Components
"
Provides a link between logical business objects and
service distribution
"
Allows for a design and distribution baseline that can be
evolved
"
Is a two-step process
$
Break the high-level business object services into their
layer-based, low-level services
$
Package the low-level services into components by layer
"
Results in highly cohesive but tightly coupled
components


The primary focus of the physical design rationalization is distributing and
packaging services. In the first step of this process, you break the high-level
services — those you identified and documented in the business object model —
into the lower-level services — user, business, and data.

Slide Objective
To describe the purpose
and process of creating
preliminary components.
Lead-in
Deriving a set of preliminary
components from the
business object model is the
first step during component
specification
362 Module 10: Completing Physical Design



Transforming Objects into Components
Business Services
Business Services
User Services
User Services
Data Services
Data Services
User
Component
Business
Component
Data
Component
A
B
C

D
Preliminary Components
Objects
A
B
C
D


To begin the process of distribution, identify the high-level services in the
business object model and break them down into their individual, layer-based
services.
For each business object, the resulting low-level services are then grouped into
three components: the user services component, the business services
component and the data services component.
Generally there will be three components for every business object identified.
Slide Objective
To describe the process of
transforming business
objects into preliminary
components.
Module 10: Completing Physical Design 363



Distributing Preliminary Components
User and
Business
Services
Data and

Business
Services
Business
Services
Preliminary
Component
Distribution
Validate
Validate
timesheet
timesheet
Consultant
Update
timesheet
Get
timesheet
Store
timesheet
Consultant
Archive
Archive
timesheet
timesheet
Consultant
Retrieve
Retrieve
timesheet
timesheet
Consultant
Assign job

Assign job
to client
to client
Consultant
Submit
Submit
timesheet
timesheet
Find job
Find job
number
number
Display
Display
timesheet
timesheet
Consultant
Consultant


After the services have been packaged into components, the next step is to
distribute the components across the network topology, creating a component
topology.
To start the distribution process, the team can identify categories of services —
user, business, and data — for each node in the network topology. These
categories will serve as a baseline for distribution that will be evolved as the
design is validated against the solution requirements. To help with the
distribution of layers, use the following guidelines:
Distribute data services to the data locations identified in the data topology,
including database servers or other locations where the data services will reside.

Distribute user services to the Web servers or the client machines.
Distribute the business services to application servers or Web servers.
After you have identified 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.
Slide Objective
To describe how to
distribute components.
364 Module 10: Completing Physical Design



Activity 10.1: Creating and Distributing Preliminary Components


In this activity, you will place your candidate components onto service layers
assigned in a previous activity.
After completing this activity, you will be able to:
"
Create a preliminary component topology by distributing preliminary
components across the network topology.

Slide Objective
To introduce this activity.
Module 10: Completing Physical Design 365



Validating Distribution and Packaging

"
Validate as a fundamental aspect of design, not as a
distinct design step
"
Use validation as the trigger for design iteration and
evolution
"
Validate against the packaging strategy, the design
goals, the application requirements, the conceptual and
logical design, and the enterprise architecture
"
Use prototyping and iteration to evolve the deployment
model


You should validate the component topology on an ongoing basis during the
design. This ongoing validation will provide the impetus to iterate the design as
necessary.
Validation of the component topology should be performed against the
strategies and requirements of the solution.
The project team will arrive at an optimum solution by iterating through the
process of validation and testing, using prototypes to help test and tune the
packaging and distribution of the components.
Slide Objective
To discuss the process of
validating the solution
design.
Lead-in
After an initial component
topology has been created,

it is important to validate the
design so that it can evolve
and iterate into the final
design that meets the
solutions requirements.
366 Module 10: Completing Physical Design



Refining Distribution and Packaging
"
Begin with the previous version of the component
topology
"
Remove component boundaries around services
"
Redistribute services according to test results,
strategies, and solution requirements
"
Repackage services into components according to
strategies and solution requirements
"
Remember the goal: high cohesion, loose coupling


The key to refining the component topology is to work with services, not
components. To evolve the component topology, undo the preliminary
component 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, therefore, the project team
may choose to distribute some of the data services on the client platform.
After the services have been redistributed, repackaging needs to be addressed.
At each location, package the services according to the strategies identified
earlier. For example, if ease of deployment was the main goal, then the project
team may choose to have only one component on the client machine rather than
many small components.
Always keep the concepts of cohesion and coupling in mind when repackaging
and redistributing. High cohesion and loose coupling are the ideal but may not
be practical given the requirements of the solution.
Slide Objective
To explain the repackaging
of services.
Lead-in
Through validation it should
become obvious that the
preliminary packaging and
distribution do not meet the
requirements of the solution.
Module 10: Completing Physical Design 367



Activity 10.2: Refining Preliminary Distribution for
Performance


In this activity, you will reorganize your candidate components to take into
account additional constraints or requirements.
After completing this activity, you will be able to:

"
Modify a component topology based on an additional packaging and
distribution strategy.

Slide Objective
To introduce this activity.
368 Module 10: Completing Physical Design



!
!!
!

Physical Design Specification
In this section
In this section
"
Deliverables of the Specification Baseline
"
Component Specification
"
Programming Model
"
Programming Model Considerations
"
Component Interfaces
"
Component Internal Structure

In this section, you will learn about the specification step of physical design.
First, you will learn about the programming model and aspects of the
programming model. You will then learn about component interfaces and how
to complete the physical design.
Slide Objective
To provide an overview of
the topics and activities in
this section.
Module 10: Completing Physical Design 369



Deliverables of the Specification Baseline
Task
Determining a programming model
Specifying the component interface
Specifying the internal structure of
components
Deliverable
Programming model
Component specifications for
interfaces, attributes, and services
Baselined component specification
Specification
Physical Design Baseline
Specification
Baseline

The specification baseline is the final step of physical design and leads to the
physical design baseline.
The deliverables of physical design specification include a programming
model; component specifications for interfaces, attributes, and services; and the
baseline of the component specification.
Slide Objective
To list the deliverables of
the specification baseline.
370 Module 10: Completing Physical Design



Component Specification
"
Describes the internal structure of components at the
level of detail required by the development team
$
Identifies what services will be accessed through which
interfaces
$
Identifies which attributes will be public and which will be
private
"
Relies on the programming model as a foundation


Because the perspective of physical design is that of the developer, you should
provide the developer with specifications for the component design as well as
the technology selection.
Component specification provides the development team with enough detail to

begin the development of the components required by the solution. The
specification identifies interfaces as well as the scope of services and attributes.
The specification is directly tied to the programming model selected for
implementation.
Slide Objective
To define the component
specification step of physical
design.
Lead-in
Component specification
involves describing how the
developers will build the
components.
Module 10: Completing Physical Design 371



Programming Model
"
Prescribes how the selected technologies are to be
used
"
Sets design guidelines to help ensure consistency
across the project
"
Uses different models to address different aspects of
the solution


The programming model describes how to use the selected technologies. It

consists of the programming specifications or standards that will be followed
during implementation of the project. The programming model sets specific
guidelines to provide consistent component implementation and increase the
maintainability of the components. The programming model’s standards may be
different for different aspects and service layers of an application (for example,
stating that all business services will be stateless, while client-side services will
be stateful).
Slide Objective
To explain the programming
model.
Lead-in
A programming model
describes how components
will be structured based on
the goals of the solution and
the technologies being
implemented.
372 Module 10: Completing Physical Design



Programming Model Considerations
"
Implementation technologies
"
Stateful versus stateless objects
"
In-process versus out-of-process function calls
"
Cohesion and coupling

"
Synchronous versus asynchronous programming
models
"
Threading model
"
Error handling
"
Security
"
Distribution


Implementation technologies consist of the programming language, API,
servers and server technologies, and other technologies affecting
implementation. In order to efficiently use some of these technologies, you
must use a specific programming model. For example, Microsoft
®
Transaction
Services requires single-entrant, single-threaded, in-process components.
The following considerations, although not an exhaustive list of all
programming standards and guidelines, should be taken into account when
defining an application’s programming model. Once again, different aspect and
service layers my have different sets of guidelines to follow.
"
The state that an object maintains can directly affect its performance,
scalability, and implementation complexity. Stateful objects retain
information accumulated from the execution of one or more client calls,
while stateless objects do not. When creating stateful objects, the team must
determine where and how the state will be maintained; in contrast, stateless

objects typically send and receive all necessary information upon invocation
or completion.
"
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 separate process from the
invoking client, thus incurring marshalling overhead and degrading
performance. This overhead trade-off must be weighted with the benefits of
separate working spaces and remote execution of components through
Component Object Model (COM) components and Distributed Computing
Environment, Remote Procedure Calls (DCE RPC).
Slide Objective
To list the different aspects
of the programming model.
Lead-in
There are several aspects of
the programming model that
you should consider,
including the following.
Module 10: Completing Physical Design 373



"
Cohesion and coupling strategies are often highly debated. Cohesive
components exhibit a high degree of functional relatedness with other
related components. Coupling refers to the strength of component
interconnections and interactions. In determining how to apply these
principles to a programming model, you should begin by trying to 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, state, or status of other objects, and
communication is often implemented through messages.
"
In distributed component environments, various components participating in
the service of a task must have real-time, live connections to each other to
function properly. If these real-time connections are severed because of
problems at run time, the components involved in the interaction will fail.
Because real-time components must typically be run in connected mode,
components written to run in a connectionless environment are able to
automatically reestablish a connection as required. A synchronous
programming model blocks the calling component from proceeding with
other work until the called interface has completed the requested service and
returned control to the calling component.
"
An asynchronous programming model, however, allows components to send
messages to other components, and then continue to function without
waiting for an immediate reply. A component designed to use an
asynchronous programming model is more difficult to program, although
technologies such as Microsoft Message Queue Services greatly simplify
asynchronous programming. A component that uses an asynchronous
programming model, however, lends itself to more scalability, because each
component is not blocked and does not have to wait for a spawned process
to complete before proceeding.
"
As discussed in Module 8, choosing the threading model for a component is
not a simple matter: The appropriate model depends on the function of the
component. A component that does extensive I/O might support free-
threading to provide maximum response to clients by allowing interface

calls during I/O latency. On the other hand, an object that interacts with the
user might support apartment threading to synchronize incoming COM calls
with its window operations.
"
Because no component performs perfectly or within a perfect environment,
components will need an error-handling strategy. Certain programming and
deployment model decisions will constrain the number of error-handling
options available. For example, writing an error message to a log file on the
client may be difficult to retrieve and pass to someone trying to identify
systemwide problems.
Security for components and services can be addressed in four basic
options:
• Component-based security is either at the method level, the interface
level, or the component level.
• Database-based level security is handled after data is involved.
• User-context based security is either in an interactive method, using
system security, or a fixed security within the application.
• Role-based security involves groups such as a night clerk or general
manager.
374 Module 10: Completing Physical Design



"
Finally, you should carefully consider the method for distributing the
application. Remember that three logical layers do not necessarily translate
into three physically distributed tiers. For example, some business services
tend to reside on the client, so you should have as many physical tiers as are
required to meet the needs of your application and the enterprise’s business
goals, possibly even distributing all components to a single location.

Module 10: Completing Physical Design 375



Component Interfaces
"
Are the interaction contracts that represent the supplier-
consumer relationship between components
"
Are the means to access the underlying services of
supplier components
"
Are the means to access the public attributes of
supplier components
"
Contain parameters, data types, interaction standards,
and a description


The specification of the component interface must include all of the different
ways in which the component can be accessed and, if possible, examples of
how the component can be used for each way that it is accessed.
There are three implications to remember when creating component interfaces:
"
A published interface is an interface contract and should be considered
permanent.
"
A modification of an existing interface should be published either as a new
component or an entirely new interface.

"
The data types of published attributes must be supportable by the service
interface consumer.

Using the component’s published interface is the only way to access the
underlying services within a component. A poorly defined interface, therefore,
can have negative implications on other parts of a system.
An interface can represent one or more services. The interface provides a
pathway for requesting a service to perform an operation and a pathway for
receiving information about the resulting attributes.
Each implementation language varies in the syntax and complexity required to
define a component’s interface. Languages such as Microsoft Visual Basic
®

often hide much of the interface complexities from the developers, whereas
Microsoft Visual C++
®
provides more control and access to the interfaces,
which requires additional coding complexity.
Most programming languages, including the aforementioned Visual Basic and
Visual C++, can use interface definition language (IDL) interface definitions
when coding components. As you may recall, IDL is a C-like language that
strictly describes the interface, methods, properties and property types. These
definitions are especially helpful in insuring consistency and change control
when multiple developers are coding components.
Slide Objective
To explain component
interfaces and how they are
described in physical
design.

Lead-in
The next key step of
specification is describing
how the components will
interact. This interaction is
documented by their
interfaces, which describe
how to get access to a
component’s services and
public attributes.