Concept: Developing Component Solutions Topics Activities across the lifecycle: Introduction Inception Phase Activities Elaboration Phase Activities Construction Phase Activities Transition Phase Activities Additional topics: Concepts distribution patterns Guidelines concurrency data modeling functionality partitioning using analysis classes interfaces layering software architecture unit testing components using design subsystems to represent components White Papers developing large-scale component-based systems 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 Concepts: 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 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: Plan the Project 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 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. Test Workflow Detail: Define Evaluation Mission A test plan identifying the overall intended testing for the project should be created, called the "Master Test Plan". Environment Workflow Detail: Prepare Environment for Project When collecting and preparing guidelines for the project, 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 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: 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. 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. 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. 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 Workflow Detail: Implement Components The Activity: Implement Design Elements must conform to the constraints imposed by the component framework. In the Elaboration phase, most of the components will contain a great deal of 'stub' code, as the implementation here focuses on validating the architecture, not producing production-quality code. Test Workflow Details: Define Evaluation Mission, Test and Evaluate, Achieve Acceptable Mission 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. 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. Construction Phase Activities The basic workflow for the Construction Phase applies, with the following extensions or variations: Project Management Workflow Detail: 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 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. Workflow Detail: 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 Workflow Detail: Refine the Architecture and Workflow Detail: 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 Workflow Detail: Implement Design Elements The work here is similar to that in Elaboration, but the remaining details are increasingly complete as the phase progresses. Workflow Detail: Integrate Each Subsystem and Workflow Detail: Integrate the System The system is progressively built as the phase continues. Test Workflow Details: Define Evaluation Mission , Test and Evaluate, Achieve Acceptable Mission 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. © Copyright IBM Corp. 1987, 2004. All Rights Reserved.

Rational Unified Process