158 WebSphere Version 5 Application Development Handbook
Moving from analysis to design
In object-oriented analysis and design, we typically need two different
perspectives of the system:
򐂰 Analysis model, which is an implementation-independent view
򐂰 Design model, which is an implementation-dependent view
The analysis model focuses on what the system will do, while the design model
focuses on how the system will do it.
The design model represents the PiggyBank application components and
determines their appropriate placement and use within the overall architecture.
The design model is based on the analysis and architectural requirements. Refer
to “Analysis” on page 119 and “Architecture” on page 143.
Design model structure
The PiggyBank design model partitioning strategy follows the application
architecture, whereas the design layer packages represent the different
application layers. Each layer has a specific responsibility. The design layer
packages are derived from the application architecture described in “Application
architecture” on page 146.
Figure 8-1 shows the specified design layer packages for the PiggyBank
application design model.
In addition to the design model layers derived from the application architecture,
we introduce an additional layer named Common Elements. The Common
Elements << layer >> captures the design model components that are shared
across the other design layers.
Chapter 8. Design 159
Figure 8-1 PiggyBank design model layers
Design layers
The << layer >> packages contain the design elements of the system (design
classes, interfaces, and design subsystems) that evolve from the analysis
classes. The <<layer>> package could contain any number of subpackages that
further partition the contained design elements.
The PiggyBank design model is divided into the following design << layer >>
packages:
򐂰 The << layer >> Presentation package contains the user interface related
design elements, such as HTML pages, JSPs, and servlets.
򐂰 The << layer >> Business package is responsible for performing any
business process.
򐂰 The << layer >> Integration package is responsible for providing access to
back-end resources, including databases and external systems.
򐂰 The << layer >> Common Elements package contains the elements that are
shared across layers.
Design subsystems
Design subsystems are represented by a package stereotyped as a subsystem
and used to further partition the design elements within a << layer >> package.
<< layer >>
Presentation
<< layer >>
Business
<< layer >>
Integration
<< layer >>
Common Elements
160 WebSphere Version 5 Application Development Handbook
Figure 8-2 illustrates the subsystem structure of the Business layer package. The
subsystem structure is derived from the business layer architecture introduced in
“Business layer” on page 151.
Figure 8-2 Business layer subsystems
Realization package
Within every design layer package we create an additional Realization package.
The Realization package contains all required design model classes used by a
specific design layer (Figure 8-3).
Figure 8-3 Business layer realization package

Get WebSphere Version 5 Application Development Handbook now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.