Example 1: Instantiating the Pop3 Component

The aim of the following example is to clarify the workings of algorithms 1 and 2, to be presented in section 6.3.3. In Figure 6.5 five components are displayed. The components are an e-Mail client (EC), a Pop3 protocol implementation component (P3), an IMAP protocol implementation component (IM), a binary patch component 122

Ins No. Instantiation Component State with Feature(s) Requires Once

1 ECR1: Instantiation Built ECR1: State Source

1 ECR1: Instantiation Install ECR1: State Built

1 ECR1: Instantiation Built CCR1: State Running with Java

1 ECR1: Feature Pop3 P3R1: State Built

1 ECR1: Feature IMAP imR1: State Built

1 ECR2: Instantiation Built ECR2: State Source

1 ECR2: Instantiation Package ECR2: State Built

1 ECR2: Instantiation Built CCR1: State Running with Java

1 ECR2: Instantiation Install ECR2: State Package

1 ECR2: Feature Pop3 P3R1: State Built

1 ECR2: Feature IMAP IMR1: State Built

2 ECR2: Feature Pop3 P3R1: State Built

2 ECR2: Feature IMAP IMR1: State Built

2 ECR2: Instantiation Built ECR1: State Built

2 ECR2: Instantiation Built PAR1: State Built

1 P3R1: Instantiation Built P3R1: State Source

1 P3R1: Instantiation Built CCR1: State Running with Java

1 IMR1: Instantiation Install IMR1: State Source

1 IMR1: Instantiation Install CCR1: State Running with C++

Figure 6.5: Component Definition Examples

for the e-Mail client (PA), and a compilation component (CC) that can compile Java and C++ source files. The e-Mail component is the focal point of our example and to instantiate the e-Mail client with certain features, all these other components are required. For the sake of brevity, a naming convention is used that individually identifies each component state, being CNRX: State, where CN stands for component name abbreviation, RX stands for revision number X, and State describes the state we are referring to. If we want to describe the second revision of the e-Mail client in its running state, it shall be referred to as “ECR2: Running”.

To ease the reader into the creation of instantiation trees, a small example tree is created first as shown in Figure 6.6. The figure displays the instantiation tree for the first revision of the Pop3 component for the statebuilt. The tree can be used to establish an order in which these states must be instantiated. The example allows for only one instantiation order, and requires that both the source code of the Pop3 component and

theinstalledstate of the compilation component are present.

The main function is called as follows: createTree(P3B1, Built, {}). First the algorithm checks whether the requested feature or state is already present on the system, and if so, the node is returned as a bottom node with the alreadyExists flag set to true. If the feature or state is not present, the algorithm will check whether it is possible to provide the feature set requested inrequestedFeatures. If these features do not result in an inconsistent or incomplete set the user is approached with questions. To begin with, the branches are created of component state instantiations this component directly depends on. Secondly, the branches are created of instantiations for this component state. A component state can have multiple instantiations, as we will later see in our larger example. The example shown, however, only has one instantiation branch 124

Figure 6.6: Instantiation Tree for Component State P3R1: Built

with one other dependency. The dependencies for this example are listed in Table 6.2. The first table is the Requires Always dependency table. The second table is the Requires Once dependency table. The instantiations and states are identified by their abbreviation and their revision. For the current example the components compilation component and Pop3 are abbreviated to CCR1 and P3R1, where the R1 stands for revision 1. The first entry in table 6.2 for instance reads “to get the e-Mail client in its running state, it must be installed at all times during its run”. The example can now be used to tell us that before we can instantiate thebuiltstate of the Pop3 component, we must first instantiate the compilation component with feature Java.

1. First call createTree(P3R1, Built,{})

2. We see no features being requested, and no illegal feature set. Nu customer intervention is required at this point in time.

3. We look up what other components are always required (requiresAlways) and what components are required only once (requiresOnce). The lookup tables are tables 6.1 and 6.2. We find no “requiresAlways” and two “requiresOnce” for this instantiation, being “P3R1: Source” and “CCR1: Running”. The first one is already present on the system.

4. “CCR1: Running” always requires an installed state instance “CCR1: Installed”. This leads us to another state instance that is already present on the system: “CCR1: Installed”.

The instantiation tree (as shown in figure 6.6) shows that we can now decide an “instantiation order”. For this tree the order is simplistic, because there exist no options in build up time. In the next example we show how the alrogithm works for a larger set of components.

Figure 6.7: Instantiation Tree for Component State ECR2: Running With Pop3