The Object-Oriented Modeling Process Process Patterns For An Architecture-Driven Approach, Programowanie, ...
[ Pobierz całość w formacie PDF ]
The Object-Oriented Modeling Process:
Process Patterns for an
Architecture-Driven Approach
An AmbySoft Inc. White Paper
Scott W. Ambler
Senior Object-Oriented Consultant
AmbySoft Inc.
Material for this paper has be excerpted from:
Building Object Applications That Work
Scott W. Ambler
SIGS Books/Cambridge University Press, 1998
- and -
Process Patterns
Scott W. Ambler
SIGS Books/Cambridge University Press, June 1998
Finalized: June 1, 1998
Copyright 1998 Scott W. Ambler
Table Of Contents
1. WHAT DO YOU NEED BEFORE MODELING CAN BEGIN?......................................................1
2. THE ‘T’ APPROACH TO MODELING............................................................................................2
3. ARCHITECTURAL MODELING .....................................................................................................4
3.1 E
NTERPRISE
M
ODELING
....................................................................................................................5
3.2 D
OMAIN
A
RCHITECTURE
M
ODELING
.................................................................................................6
3.3 T
ECHNICAL
A
RCHITECTURE
M
ODELING
.............................................................................................7
4. DETAILED MODELING ...................................................................................................................9
4.1 D
ETAILED
A
NALYSIS
......................................................................................................................11
4.2 D
ETAILED
D
ESIGN
..........................................................................................................................11
5. HOW ARCHITECTURAL AND DETAILED MODELING FIT TOGETHER ............................12
6. WHAT SHOULD BE DONE FOR MODELING TO BE CONSIDERED COMPLETE?.............13
7. SUMMARY .......................................................................................................................................13
8. GLOSSARY ......................................................................................................................................14
9. REFERENCES ..................................................................................................................................17
10. ABOUT THE AUTHOR .................................................................................................................19
Copyright 1998 Scott W. Ambler
1
The object-oriented modeling process is based on the development of many interrelated models –
diagrams, CRC (class responsibility collaborator) cards, documents, and prototypes – which describe all or
part of an application from a specific point of view. This white paper describes the process patterns
(Ambler, 1998b) for an architecture-driven modeling process for developing object-oriented applications.
Process patterns are the reusable building blocks from which your organization may tailor a object-
oriented software process (OOSP) that meets its unique needs.
It is important to understand that no one single model captures the entirety of an
application. A class diagram shows the static relationships between classes whereas
sequence diagrams show the dynamic interactions between objects. User interface
prototypes model the design of screens and reports whereas use cases model the user
requirements for an application. Different models, different points of view. To be
successful at object-oriented (OO) modeling you need to understand each model,
when each model should and shouldn’t be used, how each model relates to the other
models, and how to approach the modeling process for large-scale, mission-critical
projects.
There are many
interrelated
models available
for describing
an object-
oriented
application.
1. What Do You Need Before Modeling Can Begin?
There are several important entry conditions that must be met for work to proceed during modeling.
1.
Initial requirements.
The most important thing that you need are requirements for the application
that you are building, otherwise you must first define as part of modeling.
2.
Tool standards.
You need tools to aid in the modeling process, and a tool standards document
defines exactly what tools you will use on your project. For modeling, you need to choose a CASE
(computer aided software engineering) tool that supports your chosen modeling standards, a word
processor, and a simple drawing tool for the diagrams not supported by your CASE tool are a bare
minimum. I highly suggest a full-page scanner to capture hand-drawn models that you want to keep
but don’t want to invest the time needed to draw using a drawing or CASE tool. My experience has
been that a $300 scanner pays for itself in saved time in less than a week..
3.
Modeling notation standards.
You need to chose and/or define the modeling notation that will be
used to model your application. The modeling notation should be an industry standard, typically the
Unified Modeling Language (UML) (Booch, Jacobson, Rumbaugh, 1997) or the Open Modeling
Language (OML) (Firesmith, Henderson-Sellers, & Graham, 1997).
4.
Documentation standards.
Your documentation standards will define the layout of key modeling
deliverables such as use cases and user requirements. It is important to have a standard approach to
documentation as the greater consistency in your work leads to increased understandability and
usability.
Visit WWW.Ambysoft.com for more White Papers on Object-Oriented Development
Copyright 1998 Scott W. Ambler
2
2. The ‘T’ Approach To Modeling
When tackling a large problem domain you should organize your modeling efforts into smaller sections
and attack the problem one piece at a time, making your project easier to manage and increasing its
probability of success. An effective way to do so is called the ‘T’ Approach (Ambler, 1998b; Taylor,
1995), a detailed version of which is shown in Figure 1, where the first portion of modeling takes a
breadth first approach and models the entire problem domain at a high-level. This modeling consists of
three types of modeling: Enterprise modeling which explores your organization and its environment,
domain architectural modeling which explores the main domain components within your organization
and their interrelationships, and technical architectural modeling which defines the technical components
and their interrelationships that are used to support your organization. Subsequent modeling efforts
explore portions of the problem domain in detail, going into depth for each portion of the overall
modeling. In this white paper the breadth approach to modeling will be referred to as architectural
modeling (which includes enterprise modeling) and the depth approach to modeling will be referred to as
detailed modeling. The overall modeling strategy is called the ‘T’ approach because the architectural
modeling effort, in combination with one of the detailed modeling efforts (at least a middle one) forms the
shape of the letter ‘T.’
Enterprise Modeling
Domain Architectural Modeling
Technical Architectural
Modeling
Requirements,
Source Code,
Modeling Standards
Detailed
Modeling
Detailed
Modeling
Detailed
Modeling
. . .
Detailed
Modeling
Models,
Test Plan,
Requirements
Allocation
Matrix (RAM)
Subdomain
1
Subdomain
2
Subdomain
3
Subdomain
n
Figure 1. The ‘T’ Approach to object-oriented modeling.
The goal of architectural models is to describe both where your organization
is today and where it is going in the future. For example, the architectural
model for a bank would reflect the business needs of today, that of banking,
but would also include the necessary “hooks” to add other financial services
such as insurance and stock brokerage at some time in the future. A small
investment of time in thinking about potential future requirements makes
architecture models much more robust.
Architectural models
provide a high-level view
of what your organization
does, how it will do it,
and how it fits into its
environment.
The purpose of detailed models is to provide a better understanding of a specific
subdomain, perhaps an application or reusable subsystem, of the architectural
model. For example, Figure 2 shows several possible problem subdomains within
a telecommunications firm: Customer Management, Billing, Transaction Rating,
Service Offerings, Hardware Offerings, and Network Management. The customer
Detailed modeling
provides a more
thorough picture of
one portion of the
systems that
Visit WWW.Ambysoft.com for more White Papers on Object-Oriented Development
Copyright 1998 Scott W. Ambler
3
management subdomain includes customer service and the management of
customer and account information, billing deals with the invoicing of customers,
transaction rating deals with the calculation of what to bill for the services
support your
organization.
rendered, service offerings covers the various calling, Internet, and broadcast televisions services that the
customer may subscribe to, and product offerings deals with the various physical products such as cellular
phones and television descramblers that the company sells, rents, or leases. Network Management
includes all of the systems and processes needed to keep the telecommunications network operating.
Enterprise and
Architectural Models
Customer
Management
Billing
Transaction
Rating
Service
Offerings
Hardware
Offerings
Network
Management
Figure 2. Taking a ‘T’ approach for modeling a financial institution.
In Figure 2 the architectural models would describe the organization and its
external environment, define the various subdomains and how they relate to one
another (including their public interfaces), and the hardware and software
components used to support the business. The detailed models for the subdomains,
on the other hand, describe how each subdomain should be built within the confines
of the given architecture. When taking the ‘T’ approach your first release starts
with the architectural model and a detailed model of at least one subset of the
domain. The modeling for subsequent releases concentrates on detailed modeling
of other domains, updating the architectural model to reflect the new knowledge
gained in
The architectural
models provide
guidance as to
how the detailed
subdomains
should be,
ensuring that they
work together
effectively.
the detailed modeling effort. This is an important point: The architectural model provides a basis from
which to start detailed modeling, and the detailed modeling in turn drives changes to the architectural
model. The detailed models should conform to the existing architecture, but at the same time the
architectural model is shaped and evolved over time by the detailed models.
Because few project teams have the advantage of starting with a clean slate your first release will likely
need to interact with existing legacy applications. If this is the case, you will need to ‘wrap’ existing
Visit WWW.Ambysoft.com for more White Papers on Object-Oriented Development
[ Pobierz całość w formacie PDF ]