Roadmap: Developing Component Solutions
Topics
Component-based development is a variation on
general application development in which:
- The application is built from discrete executable components
which are developed and deployed relatively independently of one
another, potentially by different teams.
- The application may be upgraded in smaller increments by
upgrading only some of the components that comprise the application.
- Components may be shared between applications, creating opportunities for reuse,
but also creating inter-project dependencies.
- Though not strictly related to being component-based, component-based
applications tend to be distributed.
The adaptation of the Rational Unified Process
(RUP) to dealing with these challenges is discussed below.
The basic workflow for the Inception
Phase applies, with the following extensions or variations:
Project Management
- Workflow
Detail: Conceive New Project
The focus of the Activity:
Develop Business Case is adjusted to take into account that using
components change the cost structure of development. In specific, the cost of
developing components decreases, but more effort is spent on identifying
components and validating that selected components meet their requirements.
- Workflow
Detail: Evaluate Project Scope and Risk
Taking a component approach changes the nature of certain
risks and introduces new risks. Specifically:
- externally-sourced components increase risk because they introduce
critical elements not under the direct control of the project team
- externally-sourced components can reduce development time, reducing
resource risk
- externally-sourced components can distort the architecture of the system
if they impose architectural restrictions of their own
- Workflow
Detail: Develop Software Development Plan
In the Activity:
Plan Phases and Iterations, the plan for the Construction phase may
potentially show the project splitting into two different but parallel tracks:
one which develops the application-specific and domain-specific components
(organized in the upper layers of the architecture - see Concepts:
Layering), and the non-application and non-domain-specific components
organized in lower layers. In some cases, reusable components will be
developed by independently managed development teams. The decision to
introduce parallel tracks is largely a staffing and resource issue introduced
by a desire to manage reusable components as assets independent of the
applications in which they are deployed.
Requirements
Test
Environment
The basic workflow for the Elaboration
Phase applies, with the following extensions or variations:
Requirements
- Workflow
Detail: Refine the System Definition
The Activity:
Detail the Software Requirements additionally focuses on the technical and
non-functional requirements and constraints imposed on the components that are
either built or purchased. Specific non-functional requirements to consider
are size, performance, memory or disk footprint, run-time licensing issues,
and similar constraints that will influence component selection or
construction.
Analysis & Design
- Workflow
Detail: Design Components
The Activity:
Subsystem Design further refines the design of the components, identifying
classes within the component which provide the real behavior of the component.
In the early stages of the Elaboration phase, there is likely to be a single
class, a kind of 'subsystem/component proxy' which acts as a stub to simulate
the behavior of the component for architectural prototyping purposes. Later
the behavior of this class is distributed to a collaboration of classes
contained within the subsystem. These contained classes are refined in the Activity:
Class Design.
- Workflow Detail:
Design the Database
The focus in elaboration is on ensuring that the persistence
strategy is scalable and that the database design and persistence mechanism
will support the throughput requirements of the system. Persistent classes
are identified and mapped to the persistence mechanism. Data-intensive use
cases are analyzed to ensure the mechanisms will be scalable. In conjunction
with the Testing Workflow Details, the persistence mechanism and database
design is assessed and validated.
Implementation
Test
- Workflow Details: Define
Evaluation Mission, Verify
Test Approach, Test
and Evaluate, Achieve
Acceptable Mission, Improve
Test Assets
The testing activities in Elaboration focus on validating
the architecture. For a component-based system, this focus translates to:
- exercising the interfaces between components, to ensure that
component boundaries are appropriate, and
- a greater focus on performance testing, especially performance scaling
tests, to ensure that anticipated transaction volumes can be sustained
Any inherent assumptions in the component framework need to
be assessed as well. These commonly include the scalability and throughput
of the persistence and transaction management mechanisms, in which hidden
assumptions made by the mechanism designer often effectively undermine the
application architecture if it does not understand the assumption. A classic
example of this is the Microsoft Transaction Server, whose requirement that
transaction objects be 'stateless' has surprised more than a few unwary
software architects.
The basic workflow for the Construction
Phase applies, with the following extensions or variations:
Project Management
- Workflow
Detail: Plan for Next Iteration
Using the implementation subsystems as 'logical units of
responsibility', the construction work can be partitioned into to or more
parallel "tracks": one which focuses on application-specific
functionality, and one or more which focus on generic, reusable components.
This, of course, depends on having sufficient resources to staff parallel
development efforts. The ability to divide the development teams and work in
parallel depends wholly on the stability of the architecture, and more
specifically on the quality and stability of the interfaces between
components. Strong effort in the Elaboration phase will enable this
division.
Analysis & Design
- Workflow
Detail: Refine the Architecture and Workflow
Detail: Design Components
The focus in construction is on analyzing the remainder of
the use cases and identifying appropriate components and component
collaborations that realize the use cases. The existing architecture is
expanded and completed, and the 'internal behaviors' of the component are
completely designed and implemented.
Implementation
Test
Performance testing remains important, but there is an increasing
focus on functional testing. Completeness of functionality, regression testing
of existing functionality, as well as conformance with performance expectations
need to be addressed.
- Product release in the web environment tends to be
incremental and continuous, and less focused on traditional distribution of
media. Release planning must be adjusted accordingly.
- Production support is increasingly the focus of the
phase.
- Data conversion activities are performed.
Copyright
© 1987 - 2001 Rational Software Corporation
| |
|
Overview >
Roadmaps >
