Concept: Developing Component Solutions
Component-based development is a variation on general application development. In this guideline, "component" is used to refer to independently developed and deployable components.
Main Description
Activities across the lifecycle:
  1. Introduction
  2. Inception Phase Activities
  3. Elaboration Phase Activities
  4. Construction Phase Activities
  5. Transition Phase Activities
Additional topics:

Introduction

Component-based development is a variation on general application development in which:

  • The application is assembled 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.

Throughout this page, "component" is used to refer to these independently developed and deployable components. Elsewhere in RUP, however, we will use the term "component" in the more general sense described in Concept: Component , and qualify as necessary.

The adaptation of the Rational Unified Process (RUP) to dealing with component-based development challenges is discussed below.

Inception Phase Activities

The basic workflow for the Inception Phase applies, with the following extensions or variations:

Project Management

  • Activity: Conceive New Project
  • The focus of the Task: 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.

  • Activity: 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
  • Activity: Plan the Project
  • In the Task: 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 Concept: 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

  • Activity: 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. Task: Detail the Software Requirements must focus on documenting these constraints.

Test

Environment

  • Activity: Prepare Environment for Project
  • When collecting and preparing guidelines for the project, see  Task: Prepare Guidelines for the Project for details, take into account the specific component framework and the constraints imposed by it. Guidelines should include how to design and code using the framework. They should also provide testing guidance on how to verify conformance with both the component framework itself and with the interfaces defined between components.

Elaboration Phase Activities

The basic workflow for the Elaboration Phase applies, with the following extensions or variations:

Requirements

  • Activity: Refine the System Definition
  • Task: 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

  • Activity: Design Components
  • The Task: 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 Task: Class Design.

  • Activity: 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 Activities, the persistence mechanism and database design is assessed and validated.

Implementation

Test

  • Activities: 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
    • an increased 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.

Project Management

  • Activity: 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.

Construction Phase Activities

The basic workflow for the Construction Phase applies, with the following extensions or variations:

Project Management

  • Activity: Plan for Next Iteration

    Planning for the first construction iteration was described previously, as it occurs towards the end of elaboration. Follow-on iteration planning, and the ability to divide the development teams and work in parallel, continues to be dependent on the stability of the architecture, and the quality and stability of the interfaces between components.

Analysis & Design

  • Activity: Refine the Architecture and Activity: 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.

  • Activity: Design the Database

    The focus in construction is on completing the database design, ensuring that all persistent classes are supported by both the database and the persistence mechanism. This work is performed in parallel and iteratively with the work done in Activity: Refine the Architecture and Activity: Design Components. The ideal organization is to have integrated component teams, with cross-team coordination on persistence issues to ensure a good database design.

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.

Transition Phase Activities

  • 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.