# Incremental Construction for Scalable Component-Based Systems
## 4 Incremental Construction in CBD
### A Comparative Study of the Three Categories of Component Models  
With respect to component behavior, we categorize the current component models from the three categories into two groups, as shown in Figure 24. Using component models from the category of not-fixed behavior for incremental construction, a system's functionality may be fixed once the system is completed. In contrast, using component models from the category of fixed functionality for incremental construction, the final system as well as the intermediate systems have fixed functionality; the functional behavior of such systems can be verified.  
Figure 23: EX-MAN: (**a**) First system, and (**b**) Second system.  
In a composite of two components \(A\) and \(B\) (Figure 25), component interaction begins/ends on a provided port with a request/response message, as described in Section 3. In general, objects have external method calls in their methods; an object with external method calls (Figure 25a) does not have fixed functionality with respect to control and computation. With respect to control and computation, the functionality of \(A\) and \(B\) are not fixed as including one of these components implies to have more components; hence, this leads the developer to add more components. In object-based component models (from Section 4.1), a truly component-based construction may be achieved artificially if components are implemented as encapsulated components, as shown in Figure 12. However, achieving incremental construction by the weaving mechanism is limited as the code (e.g., external method calls) cannot be inserted everywhere in a component to achieve behavioral increment to the system.  
In basic-cs (from Section 4.2.2), a typical AU has required ports; hence, functionality of an AU is not-fixed with respect to control and computation. Required ports of a component represent the dependencies of the component upon other components with matching ports. As with object specific composites, the functionality of component \(A\) (Figure 25b) depends on the functionality of some component (e.g., \(B\)) compatible to be connected with component \(A\). Computation of component \(A\)'s method or service halts by making request to a method or service of component \(B\); \(A\)'s halted computation resumes after receiving response from \(B\). In contrast, AUs in basic-pnf and basic-ps styles have their own control. For a filter component, a computation is fixed to read data from the in-ports and to produce data on the out-ports. Similarly, in the publish-subscribe style, computation of a component is fixed to listen to event notifications on the sub-ports (subscriber ports) and to raise events on the pub-ports (publisher ports). Component for these two styles have fixed behavior.  
For not having required ports, component models with encapsulated components are placed in the category of fixed behavior. In some component models, increments can also be added by programming (or by refactoring) and by adapting. Another way to increment an existing system seems to be by substituting an existing component with another component (with the signature based compatible ports). However, substituting a component by another component with the compatible ports may raise port tracing issue (sequence of messages of provided services) [33]. Moreover, non-functional  
Figure 24: Behavior-based categories.  
Figure 25: Behavior of Components: (**a**) First view, and (**b**) Second view.  
properties of the services offered by the two components (developed by different vendors) may be different.