Roadmap: Developing Component Solutions
The parts of this material that relate to the use of Microsoft
Windows DNA technology are provided courtesy of Applied Information Sciences,
Inc.
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.
A discussion of some specific, additional adaptations of the
RUP® for developing component solutions using the Microsoft Windows DNA
platform is also included.
Developing Component Solutions using Microsoft Windows DNA
The Microsoft Windows DNA platform provides specific tools
and technologies for developing component-based solutions. The Windows DNA
platform provides the software infrastructure for developing components in
accordance with the Microsoft Component Object Model+ (COM)+ specification. The
basic building blocks of the Windows DNA platform are server products, along
with technologies and services that are bundled with the Microsoft Windows
2000 operating system. Some of the server products included in the Windows DNA
platform are:
Some of the key Windows DNA platform technologies include:
Some of the key services for the Windows DNA platform
include
-
Web services (Internet Information Services)
-
Queuing services (Microsoft Message Queue Services)
-
Component management and infrastructure service (COM+)
These services, technologies and servers work together to
facilitate the production and operation of component-based applications. Refer
to the Web site www.microsoft.com/dna
for a complete description of the current services and server products for the
Windows DNA platform. Refer to the Microsoft Developer Network (msdn.microsoft.com)
Web site for the latest information on COM+ technologies and services.
The primary impact of using the Windows DNA platform to the
processes defined in this Roadmap is to the activities performed in the Analysis
and Design discipline during the Inception and Elaboration phases. The major
change is an increased emphasis on the Activity:
Architectural Analysis. A key focus of architectural analysis should be on
determining the best approach for using the tools and technologies provided by
the Windows DNA platform to best meet key business requirements and global
non-functional requirements of the application.
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.
For a Windows DNA-based application development project,
the Activity: Develop Business Case
is also adjusted to take into account the need to plan for the acquisition and
deployment of any Windows DNA platform services technologies and/or server
products. The planning activity should also factor in both effort and schedule
for the evaluation or prototyping of any new releases of the server and/or
services technologies that may be used.
- 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.
For a Windows DNA-based application development project,
in the Activity: Plan Phases and
Iterations, the plans for the Inception and Elaboration phases should
include the acquisition and installation of the Windows DNA platform
technologies and server products in the project development and test
environments. The Construction Phase
or the Transition Phase plan
should include the activities to acquire and to install the Windows DNA
platform server products in the project production environment.
Business Modeling
- Workflow Detail:
Describe the Current Business
For a Windows DNA-based application development project,
it often valuable to construct a limited business model in order to understand
the business context for the application. In the Activity:
Assess Target Organization and Activity:
Find Business Actors and Use Cases, the business process analyst sketches
out a high level business organization model and business use case model to
understand the key business organizational units and business processes that
will utilize the application to be developed. These activities are especially
useful when a business is building applications to move existing business
operations to the Internet or develop new business operations for the
Internet.
Requirements
- Workflow Detail:
Define the System
For Windows DNA-based application development projects,
during the requirements gathering process, the system architect works with the
system analyst to evaluate the major business requirements, and global
non-functional requirements to determine which Windows DNA platform servers
and technology services will provide the best implementation of the
requirements. In certain situations, the software architect, designer, and
developers may assist the system analyst in creating proof-of-concept
prototypes of specific technologies to help quantify global requirements
and/or system design constraints.
- Workflow
Detail: Refine the System Definition
When refining the requirements of the system, the constraints
imposed by the selected component framework need to be captured. Component
frameworks improve development productivity in part by restricting the degrees
of freedom offered to the software architect and designer. The Activity:
Detail the Software Requirements must focus on documenting these
constraints.
For a Windows DNA-based application development project,
the Activity: Detail the Software
Requirements should focus on documenting any design constraints imposed
upon by the selection of specific Windows DNA platform technologies, services,
and server products.
Analysis and Design
- Workflow
Detail: Perform Architectural Synthesis
For a Windows DNA-based application development project,
in the Activity: Architectural
Analysis, the software architect should create initial conceptual
architectural sketches of the system. These sketches are based upon the
high-level requirements and design constraints contained in the preliminary
versions of the Artifact:
Supplementary Specifications, Artifact:
Use Case Model, and (optionally) the Artifact:
Business Object Model.
The software architect should define high-level sketches
for both the logical and deployment architecture views. The architectural
sketches should also contain an indication of the candidate Windows DNA
platform server products, technologies, and services that may be utilized in
the application design.
To develop the architectural sketches, the software
architect should consult any existing Artifact:
Reference Architecture, pertinent to the problem domain of the project
that are available either in-house or through published case studies on the
web at Microsoft’s Windows DNA Web site (www.microsoft.com/dna).
This web site contains a regular feature on case studies for application
development projects using the Windows DNA platform.
The architectural sketches serve as a key communications
mechanism between the customer and the development team to guide discussions
on evaluating and assessing the candidate Windows DNA platform server
products, technologies, and services during the Activity:
Construct Architectural Proof-of-Concept and Activity:
Assess Viability of Architectural Proof-of-Concept. These activities
should be performed only in cases where it is necessary to “test”
different architecture alternatives. The Architectural Proof-of-Concept
activities may be done in conjunction with, or separate from, the prototyping
work for quantifying non-functional requirements described in the Requirements
discipline.
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.
For a Windows DNA-based application development project,
in the Activity: Detail the
Software Requirements, the software architect and system analyst focus on
defining and quantifying any non-functional requirements imposed upon by the
specific combination Windows DNA platform server products, technologies, and
services selected for use on the project. The non-functional requirements
should be documented in the Artifact:
Supplementary Specifications. Example types of non-functional requirements
are related to compatibility issues and complimentary feature sets provided by
the different versions of the Windows DNA platform server products and
third-party products.
Analysis & Design
- Workflow
Detail: Define a Candidate Architecture
The Activity:
Architectural Analysis uses the component framework and the technical and
non-functional requirements to define an initial architecture, including an
initial layering scheme and a default set of components and services
(represented as analysis and design mechanisms). The Activity:
Use-Case Analysis focuses on identifying architecturally significant
components from architecturally significant use cases.
In the Elaboration Phase for a Windows DNA-based
application development project, the software architect evolves the initial
architectural sketches into the initial candidate application architecture.
The software architect selects the specific Windows DNA server products,
services, and technologies that will be used to build the application. The
software architect factors in the results of any Proof-of-Concept Architecture
assessments performed during the Inception Phase into the selection process.
To develop the initial candidate architecture, the
software architect can utilize existing: Reference Architectures and/or the
architectures samples contained in the Guidelines:
Sample Windows DNA Architecture Patterns and Implementation Mechanisms and
Guidelines: Technical
Infrastructure Architecture. This information can be used to define the
logical and deployment architecture views for the application.
The software architect updates the initial architectural
sketches in the Software Architecture Document. The software architect also
creates the appropriate design model packages in Rational Rose for the
designers to use in order to group subsystems and classes in the Activity:
Class Design and Activity:
Subsystem Design.
- Workflow
Detail: Refine the Architecture
The Activity:
Structure the Implementation Model establishes an implementation model
compatible with the component framework structure and the structure and
responsibilities of the development team(s).
The Activity:
Identify Design Mechanisms will refine the initial design mechanisms to
take into account specific framework services and components.
For a Windows DNA-based application development project,
in the Activity: Identify Design
Mechanisms, the software architect refines the initial design mechanisms
and selects specific Windows DNA technologies, services, and server products
to implement the defined design mechanisms.
For example, the software architect may decide to use an
event driven design mechanism for implementing notification requirements. The
software architect could chose implementation mechanisms such as the loosely
coupled events (LCE) services in the COM+ infrastructure, in combination with
queued components and the Windows message queuing services, in order to
asynchronously generate notification messages to the user as specific events
in the application occur.
The software architect should document the design and
implementation mechanisms in the Artifact:
Software Architecture Document.
The Activity:
Identify Design Elements will identify the major, architecturally
significant components of the system. Potentially reusable responsibilities
should be grouped together to improve reusability; application-specific
functionality should be separated from domain-specific and
application-and-domain-independent functionality. For purposes of design,
components can be represented as Artifact:
Design Subsystems. Artifact:
Interfaces should be identified for these components/subsystems.
The Activity:
Incorporate Existing Design Elements will ensure that identified
components are consistent and compatible with existing components identified
in prior iterations, in the framework itself, or from outside sources.
The Activity:
Describe the Run-time Architecture describes the basic process and thread
architecture of the component framework, while the Activity:
Describe Distribution describes the distributed computing environment in
which the component application will execute.
For a Windows DNA-based application development project
that utilizes multi-process/thread design mechanisms, in the Activity:
Describe the Run-time Architecture, the software architect determines the
overall process and thread distribution strategy for the application. The
software architect and designer(s) determine which threading models (Single
Threaded Apartment (STA), Multi-Threaded Apartment (MTA) or neutral
apartments) included in the Windows 2000 operating system COM+ transaction
services (formerly the Microsoft Transaction Server (MTS) product for the
Windows NT Operating System) to use in the process architecture for the
application. If the application uses transaction design mechanisms, then the
software architect also determines which components will be involved in
transactions and the appropriate transaction implementation mechanism to use,
such as: must participate, may participate, and so on.
The software architect may utilize Unified Modeling
Language (UML) sequence diagrams to depict the process threading and
transaction models and include the diagrams in the Process Architecture View
of the Artifact: Software
Architecture Document (See Concepts:
Process View for more information).
In the Activity:
Describe Distribution, the software architect defines the detailed
deployment architecture view of the Windows DNA-based application and the
allocation of applications and components to specific tiers and nodes in the
deployment architecture. See Guidelines:
Technical Infrastructure Architecture and Guidelines:
Configuration and Deployment of COM+ and IIS-Based Applications for more
information. Depending upon the performance, scalability, and availability
requirements for the application, the software architect may need to define
the types of Windows DNA platform implementation mechanisms that will be used
in the deployment architecture.
For example, for web-hosted Windows DNA-based
applications, the software architect may determine that multiple servers are
required for all major tiers (presentation, business logic, and data) of the
application. The software architect needs to define the implementation
mechanisms for the servers, such as whether to use Windows 2000 Server Edition
or Windows 2000 Advanced Server Edition for the presentation and business
logic tiers, and Windows 2000 Data Center Edition for the data tier. The
software architect may also decide to use the Network Load Balancing (NLB)
services to manage inbound web requests across multiple presentation tier
servers running Internet Information Services (IIS), and to use Windows
Clustering Services (WCS) for managing fail-over in the data tier.
These types of design and implementation decisions should
be documented in the deployment architecture view of the Artifact:
Software Architecture Document.
- 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.
For a Windows DNA-based application development project,
in the Activity: Subsystem Design
and Activity: Class Design, the
designer should follow the logical architecture layer model defined by the
software architect for organizing the classes and subsystems (components). The
designer should be cognizant of any process architecture and distribution
architecture elements that need to be factored into the class and subsystem
designs, including transaction support, threading support, Distributed COM (DCOM)
support, and so on.
The designer should also be aware of defining the required
interfaces to any COM+ component services in cases where the software
architect has defined implementation mechanisms that utilize the built-in
services of the COM+ infrastructure. The COM+ infrastructure elements can
include such items as: events, queued components, object pooling, and
component and method level role-based security mechanisms. The Guidelines:
COM+ Component Design provide additional information on design
considerations for utilizing services from the COM+ infrastructure.
For web-hosted Windows DNA-based applications development
projects, during the Activity:
Class Design, and Activity:
Subsystem Design, the designer defines the detailed design classes of the
client-side and server side design elements (client-side pages, server-side
pages, forms, client-side classes, and server-side classes) in the
presentation layer of the application. See Guidelines:
Active Server Page (ASP) Design for more information on design
considerations for using ASP technology.
- 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
identified in Workflow
Detail: Refine the Architecture and Workflow
Detail: Design Components are mapped to the persistence mechanism
and data-intensive use cases are analyzed to ensure the mechanisms will be
scalable. In conjunction with the Testing Workflow
Details: Plan Test, Design
Test, Implement Test, the
persistence mechanism and database design is assessed and validated.
For a Windows DNA-based application development project,
in the Activity: Class Design, Activity:
Subsystem Design, and Activity:
Database Design, the designer and database designer work together to
design the data access classes and subsystems, and the database. This is done
in accordance with the specific Windows DNA platform data access
implementation mechanisms selected by the software architect. The data access
implementation mechanisms are based upon the technologies defined in the
Microsoft Universal Data Access (UDA) strategy, including ActiveX Data Objects
(ADO), OLE DB, and Open Database Connectivity (ODBC). Data access
implementation mechanisms may also include the use of Windows DNA platform
server products including Microsoft SNA server. The database implementation
mechanisms can include Microsoft SQL Server, and potentially other commercial
database management systems.
The Guidelines:
Universal Data Access provides more information on design considerations
for data access classes.
Implementation
Test
- Workflow Details: Plan
Test, Design Test, Implement
Test
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 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
Deployment
- 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 >
