Top1 Software Component Aggregation Process
Component-Based Software Development (CBSD) is concerned with building complex software systems by integrating previously existing parts called software components. CBSD aims at enhancing the flexibility and maintainability of these systems. It is an approach used to reduce software development costs, and reduce the maintenance burden related to updating large systems (Haines, Carney & James, 1997). The foundation of this approach is the hypothesis that some parts of these systems can be written once rather than many times, and that some software systems can be assembled from existing components, so there is no need to develop them over and over (Allen & Frosts, 1998).
One of the latest trends in systems development is to make greater use of commercial-off-the-shelf (COTS) products. COTS products are commercial components that are ready to use. Component-based systems encompass both COTS products and components acquired through other means, such as non-developmental items. This kind of development becomes feasible due to:
- •
the increase in the quality and variety of COTS products;
- •
economic pressures to reduce system development and maintenance costs;
- •
the evolution and emergence of component integration technologies;
- •
the increasing amount of existing software that has been designed and implemented to be reused in new development contexts.
Szyperski states that development emphasis moves from programming software to composing software systems (Szyperski, Gruntz, & Murer, 2002). In CBSD. Building systems shifts from writing code from scratch to assembling and integrating existing software components. In contrast to traditional development, component integration is the centrepiece of the CBSD approach. Thus, integration and aggregation are key considerations in the decision to acquire, reuse or build software systems.
Brown suggests four major activities to characterize component-based development approaches:
These activities are part of a component-based development process and must be well organized and planned to build complex systems. Many software integration experts consider that technical issues are mature enough, whereas organizational and economic issues are not. Consequently, several issues become important such as integration requirements, standards, component identification, component selection, component metadata repositories, component referencing, component search and retrieval, process development, component architecture (Haines, Carney & James, 1997; Mili, Mili, Yacoub, & Addy, 2002; Seidewitz, 2003).
Most existing literature dealing with characterization of software components focuses on classification, evaluation and selection. Torchiano and Jaccheri propose a classification of software components. A more complex classification is outlined by Morisio and Torchiano. It is based on ten attributes grouped into four areas: source, customization, bundle and role. All these works are detailed in (M. Torchiano, L. Jaccheri, C.-F. Srensens, & A. I. Wang, 2002).
It’s important to note that few works deal in a coherent way with component characterization, identification, selection, processes, methods and frameworks. This is why we have built the software component aggregation process presented in Figure 1. This process model in built using the TELOS scenario editor presented in chapter 8 and discussed more thoroughly in chapter 12. It is model- and metadata-driven and is managed by a software engineer.
Figure 1. Software component aggregation process diagram (SOCAP)
Figure 1 illustrates the component aggregation process of two components labelled “component 1”(Cp1) and “component 2”(Cp2). There are six phases in the process.