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

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 Physic

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

Physical DesignSpecificationReview

Activity 10.2: Refining Preliminary Distribution for Performance

Module 10:

Completing the Physical Design

Physical DesignRationalization Basics

Rationalization:

Distribution andPackaging

Activity 10.1: Creating and Distributing Preliminary Components

Activity 10.3: Factors

Impacting the Programming

Model

! Overview

Performance

Programming Model

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

! Physical Design Rationalization Basics

In this section

Slide Objective

To provide an overview of

the topics and activities in

this section

Deliverables of the Rationalization Baseline

Using strategy and prototypes torefine packaging and distribution

Deliverable

Packaging and distribution strategy

Services-based preliminarycomponents

Deployment model

" Future network topology

" Future data topology

" Future component topologyBaselined 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

Distribution and Packaging Strategy

$ 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

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

Packaging Terminology: Cohesion

$ 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:

" 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

Packaging Terminology: Coupling

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

$ 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

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

Distribution and Packaging Strategy Considerations

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

$ 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

When deciding how to

distribute and package the

solution services, you must

take into account solution

and physical requirements

! Rationalization: Distribution and Packaging

Components

Creating Preliminary Components

$ Package the low-level services into components by layer

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

Transforming Objects into Components

Business Services User Services

Data Services

User Component Business Component Data Component

A B C D Preliminary Components

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

Distributing Preliminary Components

User and Business Services

Data and Business Services

Business Services

Preliminary Component Distribution

Validate timesheet

Consultant

Update timesheet

Get timesheet

Store timesheet

Consultant

Archive timesheet

Consultant

Retrieve timesheet

Find job number

Display timesheet 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

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

Validating Distribution and Packaging

distinct design step

evolution

goals, the application requirements, the conceptual and logical design, and the enterprise architecture

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

Refining Distribution and Packaging

topology

strategies, and solution requirements

strategies and solution requirements

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

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

! Physical Design Specification

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

Deliverables of the Specification Baseline

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

Component Specification

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

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

Programming Model

used

across the project

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

describes how components

will be structured based on

the goals of the solution and

the technologies being

implemented

Programming Model Considerations

" 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