June 9, 2017 9:44 ws-book9x6 An Introduction to Component-Based. . .

b2915 page 1

by 2409:40c1:1023:46b2:ccca:f9ff:fe83:f44f on 11/16/24. Re-use and distribution is strictly not permitted, except for Open Access articles.

Chapter 1

Introduction
An Introduction to Component-Based Software Development Downloaded from [Link]

Component-based Software Development (CBD)1 [Bachmann et al. (2000);

(2001); Szyperski et al. (2002)] aims to compose systems from pre-built software
units, or components. A system is developed not as a monolithic entity, but as a
composite of sub-parts that have already been built separately. Such an approach
reduces production cost by composing a system from pre-existing components,
instead of building it from scratch. It also enables software reuse, since compo-
nents can be reused in many systems. Thus CBD promises the benefits of: (i)
reduced production cost; (ii) reduced time-to-market; and (iii) increased software
reuse. These benefits have long been sought after by the software industry.
The basic idea of CBD is illustrated by Fig. 1.1: first, components are (de-
signed and) built and deposited in a repository; then different systems can be
(designed and) built by using components retrieved from the repository. By thus
reusing repository components for multiple systems, we can reap the benefits of
CBD.

   


    

   
  


      

Fig. 1.1 Component-based software development.

The use of repository components for building systems suggests that CBD
is essentially bottom-up, starting with pre-defined components, and composing
them into a specific system; rather than top-down, starting with a top-level system
1 Various abbreviations have been used, CBD and CBSE being the main ones. We choose CBD.

1
June 9, 2017 9:44 ws-book9x6 An Introduction to Component-Based. . . b2915 page 2

2 An Introduction to Component-Based Software Development

design, and successively decomposing it until components for this system are
identified and then built just for this system.
by 2409:40c1:1023:46b2:ccca:f9ff:fe83:f44f on 11/16/24. Re-use and distribution is strictly not permitted, except for Open Access articles.

In CBD, the life cycle of components [Christiansson et al. (2002)] consists of

three stages: (i) the design phase, when components are designed, defined and
constructed; (ii) the deployment phase, when components are deployed into the
execution environment of the system under construction; and (iii) the run-time
An Introduction to Component-Based Software Development Downloaded from [Link]

phase, when components are instantiated with data and executed in the running
system.
Precisely what components are, and what desirable properties they should
have in order to provide the requisite support for CBD, has been discussed at
length [Broy et al. (1998); (2001); Szyperski et al. (2002); Meyer (2003)]. The
resulting set of desiderata has been widely disseminated and accepted, and is sum-
marised in the table in Fig. 1.2. The implications of these desiderata for the rele-
vant phases of component life cycle (the design and deployment phases) are also
included in this table.

Desideratum Design Phase Deployment Phase

Components should Deposit components Retrieve components
pre-exist in repository from repository
Components should be Use builder
produced independently
Components should be Use assembler
deployed independently
It should be possible to copy Copies possible Copies and
and instantiate components instances possible
It should be possible to Composition Composition possible
build composites possible
It should be possible to Use repository
store composites

Fig. 1.2 Desiderata for component-based software development.

Firstly, for the purpose of system development, components should be pre-

existing reusable software units, which system developers can reuse to compose
software for different applications more quickly than writing all the code from
scratch for each application. This necessitates the use of a repository, in which
components can be deposited in the design phase of the component life cycle, and
from which components can be retrieved in the deployment phase.
Secondly, components should be produced and used, or deployed, by inde-
pendent parties. That is, component developers need not be the same people as
component customers such as system developers. This is important for ensuring
that components are truly reusable by third parties. It requires the use of tools
that can interact with a repository: in the design phase, a builder tool is needed
June 9, 2017 9:44 ws-book9x6 An Introduction to Component-Based. . . b2915 page 3

Introduction 3

for building components and depositing them in the repository; in the deployment
phase, an assembler tool is needed for assembling components (more accurately,
by 2409:40c1:1023:46b2:ccca:f9ff:fe83:f44f on 11/16/24. Re-use and distribution is strictly not permitted, except for Open Access articles.

component instances, see below) retrieved from the repository.

Thirdly, it should be possible to copy and instantiate components, so that their
reuse can be maximised, both in terms of code reuse and in terms of components’
scope of deployment. Thus, it should be possible to make distinct copies of com-
An Introduction to Component-Based Software Development Downloaded from [Link]

ponents, and to distinguish components from their instances; and thus differentiate
the design and deployment phases from the run-time phase of the component life
cycle.
Fourthly, it should be possible to compose components into composite com-
ponents, and then store these composite components. Composite components in
turn can be composed with (composite) components into larger composites (or
subsystems), and so on. This requires that, like their non-composite counterparts,
composites can also be deposited in and retrieved from a repository. Composition
means not only reuse, but also a systematic approach to system construction.
In addition to these desiderata, we have identified another ideal one: the possi-
bility to perform composition in both design and deployment phases. Composition
means component reuse, and therefore composition in both phases will maximise
reuse. It also means design flexibility in the sense that the deployed components,
in particular composite components, can be designed, by composition in either
phase: either entirely in one phase or partially in both phases.
An idealised component life cycle should meet all the aforementioned desider-
ata, and we have defined such a life cycle [Lau and Wang (2005, 2007)].

1.1 An Idealised Component Life Cycle

Our idealised component life cycle is depicted in Fig. 1.3. It is derived from all
the desiderata together with their life cycle implications listed in Fig. 1.2.
Figure 1.4 summarises the characteristics of the actors and artefacts involved
in the idealised component life cycle.

1.1.1 Design Phase

In the design phase, components have to be constructed, catalogued and stored in

a repository in such a way that they can be retrieved later, as and when needed.
Components in the repository are in source code, or they may have been compiled
into binary.
June 9, 2017 9:44 ws-book9x6 An Introduction to Component-Based. . . b2915 page 4

4 An Introduction to Component-Based Software Development

Design Phase Deployment Phase Run-time Phase

Builder Repository Assembler Run-time
Environment
by 2409:40c1:1023:46b2:ccca:f9ff:fe83:f44f on 11/16/24. Re-use and distribution is strictly not permitted, except for Open Access articles.

A A
A InsA
B
B B InsB
C
C InsD
D
An Introduction to Component-Based Software Development Downloaded from [Link]

BC BC InsBC

Component (source code) Component (binary) Component

instance
Design phase Deployment phase
composition operator composition operator

Fig. 1.3 An idealised component life cycle.

Design Phase Deployment Phase Run-time Phase

Role Component designer System developer System user

(producer/vendor)
System System execution
Environment independent System speci
c environment
Component Template + Deployed Executable
type deployment contracts subsystem subsystem
Data in Place-holders +
components Place-holders con
guration data All data initialised
Component
Source or binary Binary Binary instance
format
Composition Pre-de
ned Pre-de
ned
operators

Fig. 1.4 Characteristics of actors and artefacts in idealised component life cycle.

Components should be composed into well-defined composites using suitable

composition operators, ideally supported by a composition theory. It should be
also possible to store composites in, and retrieve them from the repository, and
use them for further composition, like any components.
A builder tool can be used to (i) construct new components, and then deposit
them in the repository, e.g. in Fig. 1.3, A is a new component constructed in the
builder and deposited in the repository; (ii) retrieve components from the repos-
itory, compose them and deposit them back in the repository, e.g. in Fig. 1.3, B
and C are retrieved from the repository and composed into a composite BC that is
deposited in the repository.
June 9, 2017 9:44 ws-book9x6 An Introduction to Component-Based. . . b2915 page 5

Introduction 5

To promote reuse, components in design phase should be templates that pro-

vide services. They should be identified and designed by domain experts as basic
by 2409:40c1:1023:46b2:ccca:f9ff:fe83:f44f on 11/16/24. Re-use and distribution is strictly not permitted, except for Open Access articles.

building blocks for the domain in question. They should be generic, rather than
system-specific so that they could be (re)used to build many different applications.
Similarly, composition operators in design phase should be generic composition
schemes to coordinate components which can be customised for many different
An Introduction to Component-Based Software Development Downloaded from [Link]

systems.
To support its reuse, any component should have an interface. In particular,
a composite component should expose an interface generated during the compo-
sition process and its content should be determined according to the semantics of
the composition operator involved.
Components in design phase should also include information of the environ-
mental dependencies or resources needed for its deployment. Composition in
design phase should generate such information for composites. For instance, de-
ployment contracts [Lau and Ukis (2006)] could be used to specify this kind of
information.

1.1.2 Deployment Phase

Ideally, composition in deployment-phase should follow on from, and thus exploit

composition in design phase. That is, as far as possible, the composites here
should be built directly from the (composite) components created in design phase.
In the deployment phase, components have to be retrieved from the repository,
and if necessary compiled to binary code and then composed. The result of de-
ployment phase composition is a whole system in binary code, and so this is the
end result of system design and implementation. The completed system should be
then ready for execution.
As in design-phase, composition should be carried out via composition oper-
ators. But in here, they should allow the coordination between components down
to the last detail, as required by the specific application.
An assembler tool can be used to retrieve components from a repository, com-
pile them into binary code, and then assemble them into a system. For example, in
the assembler in Fig. 1.3, binaries of A, B, D and BC are retrieved and composed
into a system.
Composite components in the deployment phase should have interfaces that
allow them to be instantiated and executed at run-time phase. These interfaces
should be generated during the composition process.
Composition in deployment-phase should be supported by suitable deploy-
ment tools to, for example, check the component compatibility with one another
June 9, 2017 9:44 ws-book9x6 An Introduction to Component-Based. . . b2915 page 6

6 An Introduction to Component-Based Software Development

and with the execution environment, e.g. a tool for checking deployment contracts
would be useful. Also with such tools, it should be possible to deploy a composite
by 2409:40c1:1023:46b2:ccca:f9ff:fe83:f44f on 11/16/24. Re-use and distribution is strictly not permitted, except for Open Access articles.

in many different systems.

1.1.3 Run-time Phase

In the run-time phase, the constructed system is instantiated and executed in the
An Introduction to Component-Based Software Development Downloaded from [Link]

run-time environment, e.g. A, B, D and BC in the run-time environment in Fig. 1.3.

Although this phase does not include further composition, for highly available ap-
plications it should be possible to perform some kind of adaptation on the compo-
nent’s instances in executable system.

1.2 Development Processes

The idealised component life cycle is about the stages of a component’s life, start-
ing from its creation and ending in its execution. These stages provide the basis of
development processes for CBD. The desiderata of independent component pro-
duction and deployment require that there is a separate development process for
components, and hence a separate development process for systems built form
components. We call these processes the component life cycle and the system life
cycle respectively. As is standard practice in the literature, we will use ‘life cycle’
interchangeably with ‘development process’ or simply ‘process’.
A number of development processes for CBD have been proposed, e.g. [Chris-
tiansson et al. (2002); Kotonya et al. (2003); Sommerville (2004a); Capretz
(2005); Crnkovic et al. (2006)], to name but a few. (A survey can be found in
[Kaur and Singh (2010)].) Naturally these processes all reflect the desiderata of
CBD, and converge on the general view depicted in Fig. 1.5.

   
 

  

 
  

    

   
 
 
   

Fig. 1.5 CBD development processes.

June 9, 2017 9:44 ws-book9x6 An Introduction to Component-Based. . . b2915 page 7

Introduction 7

The generic CBD process in Fig. 1.5 comprises two separate processes: (i)
the component life cycle, for component development; (ii) the system life cycle,
by 2409:40c1:1023:46b2:ccca:f9ff:fe83:f44f on 11/16/24. Re-use and distribution is strictly not permitted, except for Open Access articles.

for component-based system development. Component development is also

known as ‘development for reuse’, since it is concerned with developing com-
ponents that can be stored in a repository and (re)used to build different sys-
tems. Component-based system development is also known as ‘development with
An Introduction to Component-Based Software Development Downloaded from [Link]

reuse’, since it is concerned with developing systems by reusing pre-built compo-

nents (the result of the component development process).
Each process follows the traditional Waterfall Model [Royce (1970); Ben-
ington (1983)] of ‘requirements analysis, design, implementation, testing and
maintenance’. For component development, implementation is a single activity,
whereas for system development, implementation is a sequence of activities based
on pre-built components, namely component selection, adaptation and assembly.
The component life cycle in Fig. 1.5 is not explicitly conformant with the
idealised component life cycle as it does not explicitly specify independent com-
ponent production or deployment, neither does it explicitly specify a repository
of independently produced components. Moreover, it does not explicitly address
V&V, i.e. Verification and Validation.

1.3 Verification and Validation

Verification is the process of evaluating the system under construction to check if

it meets the specified requirements and design specifications. Complementary to
verification, validation is the process of evaluating the system under construction
to check if it meets the customer’s requirements and expectations. Not surpris-
ingly, testing plays a central role in V&V, e.g. system testing for verification, and
acceptance testing for validation (see Fig. 1.6).

1.3.1 The V Model

For general (modular) system development, the standard model for V&V is the V
Model [IABG (2017)], which is depicted in Fig. 1.6. The V Model is an adapta-
tion of the traditional Waterfall Model for modular system development. It defines
a sequential process consisting of phases for requirements, system specification,
system or architectural design, module design, implementation and testing. Im-
plementation consists of coding for the individual modules, and coding for inte-
grating the modules into the entire system using the architectural design for the
system. Testing follows coding. Thus the coding phase divides the whole process
into ‘development’, the left arm of the V, and ‘testing’, the right arm of the V.
June 9, 2017 9:44 ws-book9x6 An Introduction to Component-Based. . . b2915 page 8

8 An Introduction to Component-Based Software Development



    

by 2409:40c1:1023:46b2:ccca:f9ff:fe83:f44f on 11/16/24. Re-use and distribution is strictly not permitted, except for Open Access articles.

      





      
An Introduction to Component-Based Software Development Downloaded from [Link]

         

     

     
     

  

Fig. 1.6 The V Model.

During each of the development phases (in the left arm of the V), a test plan
is drawn up for the corresponding testing activity (in the right arm of the V).
For example, an acceptance test plan is drawn up from the requirements, since
acceptance testing will be performed against the requirements. Similarly, unit test
plans are generated from module design, since unit testing will be carried out on
the modules, and so on.
Testing follows a sequential process, in reverse order of the development
phases, as is usual for modular system development. Thus unit testing is per-
formed first, followed by integration testing, system testing and finally acceptance
testing. Each testing activity is carried out according to the test plan generated
during the corresponding development phase.
The key property of the V Model that is pertinent here is that it is a top-down
approach to system design and development, as Fig. 1.6 clearly shows. First, a
top-level design is made of the architecture of the entire system; this identifies
and specifies sub-systems or modules, and their inter-relationships. Then the in-
dividual modules are designed according to their specifications in the top-level
design. In general, this top-down approach may be applied successively, each
time decomposing sub-systems or modules in the current level of design into fur-
ther sub-systems or modules. This decomposition is repeated as many times as is
necessary, until a final design is arrived at in which the design of the system as well
as all the individual modules is deemed complete, i.e. no further decomposition is
necessary or desirable.
June 9, 2017 9:44 ws-book9x6 An Introduction to Component-Based. . . b2915 page 9

Introduction 9

1.3.2 Adapting the V Model for CBD

Compared to the CBD processes in Fig. 1.5, which contain two life cycles, one for
by 2409:40c1:1023:46b2:ccca:f9ff:fe83:f44f on 11/16/24. Re-use and distribution is strictly not permitted, except for Open Access articles.

component development and one for system development, the V Model contains
only one life cycle, for system development. So, the question is ‘How can we
adapt the V Model for V&V in CBD?’
The CBD processes in Fig. 1.5 shows CBD as an essentially bottom-up ap-
An Introduction to Component-Based Software Development Downloaded from [Link]

proach to system design, in the sense that components have to be developed first
(in the component life cycle), and any particular system is constructed from these
components (in the system life cycle). In contrast, as we have explained in the pre-
vious section, the V Model (Fig. 1.6) is essentially a top-down approach to system
design: the system is designed first (thus identifying the requisite components),
and then components are developed.
A straightforward adaptation of the V Model for CBD would be to retain the
top-down approach to system design but use a component as a module, as shown
in Fig. 1.7. For example, the V model adopted by the avionics industry as a CBD
process (e.g. Airbus processes [da Cruz and Raistrick (2007); Gaufillet and Gabel
(2010)]) is such an adaptation.



    

      





      

         

     

           
     

  

Fig. 1.7 Adapting the V Model for CBD.

However, such a straightforward adaptation of the V Model is at variance with

the CBD processes in Fig. 1.5, precisely because it does not include a component
life cycle and consequently does not incorporate the bottom-up nature of CBD.
An adaptation of the V Model for CBD that does incorporate the bottom-up
nature of CBD is that of [Crnkovic et al. (2006)]. It does so by containing separate
life cycles for component development and system development, like in Fig. 1.5.
June 9, 2017 9:44 ws-book9x6 An Introduction to Component-Based. . . b2915 page 10

10 An Introduction to Component-Based Software Development

However, this adaptation really applies the V Model only to its system life cycle;
there is no evidence of the V Model in its component life cycle (which is the same
by 2409:40c1:1023:46b2:ccca:f9ff:fe83:f44f on 11/16/24. Re-use and distribution is strictly not permitted, except for Open Access articles.

as the one in Fig. 1.5).

In our view, to adapt the V Model properly for CBD, we need not only to
incorporate both the component life cycle and the system life cycle, but also to
apply the V Model to both of these cycles. We have defined such an adaptation,
An Introduction to Component-Based Software Development Downloaded from [Link]

which we call the W Model,2 for reasons that will become apparent later.

1.4 The W Model

The W Model is based on a bottom-up CBD process based on the idealised com-
ponent life cycle (Section 1.1), as depicted in Fig. 1.8. This process consists of

  
  

  
   
 

  
   

    
 !   
      

 

 
  
    
 
  
 

Fig. 1.8 A bottom-up CBD process based on the idealised component life cycle.

a component life cycle and a system life cycle, in line with the CBD processes
in Fig. 1.5. However, it differs slightly from the latter, in that its component life
cycle is the idealised component life cycle. In the design phase, components are
(identified and) designed and constructed according to the domain requirements
or knowledge [Lau and Taweel (2009)], and deposited into a repository. Compo-
nents in the repository are domain-specific but not system-specific. In the deploy-
ment phase, components are retrieved from the repository and instantiated into
executable component instances which are then deployed into a specific system
under construction.
The system life cycle also differs slightly from that in Fig. 1.5 in that system
design is now replaced by a completely bottom-up process of component selection
2 The name W Model has been used by others, see Discussion and Further Reading.
June 9, 2017 9:44 ws-book9x6 An Introduction to Component-Based. . . b2915 page 11

Introduction 11

(from the repository) and adaptation, followed by (component deployment in the

component life cycle followed by) system assembly, which is simply the com-
by 2409:40c1:1023:46b2:ccca:f9ff:fe83:f44f on 11/16/24. Re-use and distribution is strictly not permitted, except for Open Access articles.

position of the deployed components. The bottom-up nature of this process is

indicated by an iterative loop in Fig. 1.8. It is worth noting that within this loop,
the component life cycle links up with the system life cycle, since deployed com-
ponents (from the component life cycle) are iteratively assembled into the system
An Introduction to Component-Based Software Development Downloaded from [Link]

under construction (in the system life cycle). This link is denoted by the arrows
between the two life cycles in Fig. 1.8, via the step of component selection and
adaptation, and the step of component deployment.
Applying the V Model to both the component and system life cycles yields a
CBD process with V&V as shown in Fig. 1.9. Compared to the straightforward

  
  

  
   
 

  
   

    
 !   
      

""  

 
   
   ""
    
 
  

  ""

Fig. 1.9 A bottom-up CBD process with V&V.

adaptation of the V Model in Fig. 1.7, component V&V (which corresponds to

component testing in Fig. 1.7) now occurs in the component life cycle, whilst
compositional V&V (which corresponds to integration testing in Fig. 1.7) and sys-
tem V&V (which corresponds to system testing in Fig. 1.7) occur in the system
life cycle.
The bottom-up CBD process with V&V in Fig. 1.9 can be re-cast straight-
forwardly as a process with two conjoined V Models, one for the component life
cycle and one for the system lifecycle. These two V Models are conjoined via
the step of component selection, adaptation, and deployment. This ‘double V’
process is shown in Fig. 1.10. We call it the W Model.3

3 In English, W is ‘double u’; there is no letter for ‘double v’.

June 9, 2017 9:44 ws-book9x6 An Introduction to Component-Based. . . b2915 page 12

12 An Introduction to Component-Based Software Development

System Acceptance
requirements testing
Component System
by 2409:40c1:1023:46b2:ccca:f9ff:fe83:f44f on 11/16/24. Re-use and distribution is strictly not permitted, except for Open Access articles.

Life Cycle System Life Cycle System

speci
cation V&V

Domain Component selection

knowledge & adaptation
An Introduction to Component-Based Software Development Downloaded from [Link]

Component Component V&V System Compositional

design & certi
cation assembly V&V

Coding Coding

Fig. 1.10 The W Model.

Discussion and Further Reading

Much of the CBD literature originates from the International Symposium on

Component-based Software Engineering ([Link]
org/). A survey of the research published at this conference can be
found in [Maras et al. (2012)].

The W Model
In the definition of the W Model, we need to specify a component model (Chap-
ter 4) that defines the components and their composition accordingly. We have
used a component model called X-MAN that we have defined ourselves. The
details of X-MAN can be found in Section 7.1.
The name W Model has been used in software testing [Spillner (2002)] and
product line engineering [Li et al. (2008)] in the context of traditional (i.e. non-
CBD) software engineering. [Spillner (2002)] extends the V Model by adding a
branch that integrates testing with debugging and code changes. [Li et al. (2008)]
applies the V Model to domain engineering and application engineering in soft-
ware product lines. This is similar to our approach, except that they do not use
components and component composition, or the idealised component life cycle.
In the context of CBD, our W Model is similar to standard CBD processes,
e.g. [Christiansson et al. (2002); Kotonya et al. (2003); Sommerville (2004a);
Crnkovic et al. (2006)], in that they both contain separate life cycles for com-
ponents and systems. However, unlike these processes, its component life cycle
is the idealised one, which meets all the CBD desiderata in the literature [Broy
et al. (1998)]. In particular the idealised component life cycle defines compo-
nent composition in both component design and component deployment phases.
June 9, 2017 9:44 ws-book9x6 An Introduction to Component-Based. . . b2915 page 13

Introduction 13

This emphasis on composition results in compositionality, which is an important

property that is beneficial for practical system development, since it enables hier-
by 2409:40c1:1023:46b2:ccca:f9ff:fe83:f44f on 11/16/24. Re-use and distribution is strictly not permitted, except for Open Access articles.

archical system development and compositional reasoning.

The component life cycle of our W Model is similar to that in the Y Model
[Capretz (2005)], in that they are both based on ideas stemming out from domain
engineering. In the Y Model, components are developed using domain engineer-
An Introduction to Component-Based Software Development Downloaded from [Link]

ing techniques, and then archived. A framework is then defined for selecting
components from the archive, and for assembling them into systems. The archive
is of course just a repository. The framework is a structure for assembling com-
ponents. Therefore, it is like a system assembler. However, the Y Model does not
apply the V Model in any way to its component life cycle.4 Moreover, it does not
define a component model.
Other proposed processes for CBD, found in [Kotonya et al. (2003)], lack the
separate process of deriving and developing components. Components are iden-
tified along with system development or received from some component space.
Such component identification is not systematic and potentially leads to ad hoc
components with limited reuse. Also, only [Kotonya et al. (2003)] suggests veri-
fication for components (in a system) and systems.
Other software development approaches based on domain engineering, e.g.
product lines [Clements and Northrop (2015); Pohl et al. (2005)] and generative
programming [Czarnecki and Eisenecker (2000)], are similar to the Y Model, in
that they also do not apply the V Model to their component life cycle. Thus despite
their use of domain engineering techniques for developing components, all these
approaches do not follow a development process like the W Model.
On the other hand, the W Model is applicable to the V&V of product lines and
generative programs. Unlike component models based on architecture descrip-
tion languages (see Chapter 6, the X-MAN component model, that underlies the
W Model, defines explicit composition connectors. In the component life cycle
of the W Model, along with components, composition connectors can be iden-
tified from domain requirements. These domain-specific components and com-
position connectors effectively define a domain-specific component model [Lau
and Taweel (2009)]. In general, for a given domain, a domain-specific component
model is the best one to use [Medvidovic et al. (2007)]. Furthermore, in a domain-
specific component model, composition connectors can define product lines. Thus
X-MAN can offer a component-based definition of product lines and generative
programming.

4 The same is true of component models that incorporate domain engineering techniques, e.g. EAST-

ADL (2016).
June 9, 2017 9:44 ws-book9x6 An Introduction to Component-Based. . . b2915 page 14

14 An Introduction to Component-Based Software Development

In most of the related work, the process of identifying and constructing

components (if exists) does not necessarily produce components in the compo-
by 2409:40c1:1023:46b2:ccca:f9ff:fe83:f44f on 11/16/24. Re-use and distribution is strictly not permitted, except for Open Access articles.

nent repository. Components can be developed by external parties and end up in

some component pool or library. More importantly, components are not suggested
to be derived from domain engineering of a domain. Therefore, components are
not domain specific components. That leads to a major issue in that components
An Introduction to Component-Based Software Development Downloaded from [Link]

in the pool are not suitable for a new application in the domain. In order to be
reused, components are then required to be adapted or glue code is needed to wire
up components. Even so, it is not feasible every time. In contrast, in our approach,
components and connectors are derived from domain analysis. Components and
connectors in a domain can be exhaustively identified including all possible vari-
ations. Moreover, components in repository are fully implemented and verified.
Hence, the above issue does not arise.
For the purpose of V&V, our W Model is different from other adaptations of
CBD processes based on the V Model for modular system design. The W Model
contains a V model for both component and system life cycles, whereas other
adaptations, e.g. [Crnkovic et al. (2006)], contain only a V model for the system
life cycle. The value of a V Model for the component life cycle is that we can do
component V&V and store pre-verified components in the repository. These com-
ponents could be certified according to certain standards. Then, compositional
V&V of composites can be carried out by re-using component V&V.