The presented models manage meta-knowledge about components and their features. This meta-knowledge will always describe some kind of software or hardware on a system with a running configuration. The stored meta-knowledge can therefore be seen as a software knowledge base [80] that is used to support the processes of development, release, and deployment. Though the models currently only support component descriptions, our future will include the incorporation of consequences for the system configuration. The knowledge stored can then quickly be expanded to include knowledge about the artefacts that are affected by the deployment of a component or instantiation of a component state. Such knowledge will then enable validation of the deployed component information, through hashes, or the knowledge can be used to check whether a set of artefacts present in a configuration is the correct set for a component instance.
The sharing of knowledge between components introduces many possibilities. Due to the fact that users define their configuration settings, these can be reused for different components. This will allow, for instance, a user to type his e-mail account settings only once, and then reuse the account settings across different e-mail clients. All these different types of information require some kind of categorization. The actual structure in which the component knowledge must be stored still needs to be designed.
The implementation that is presented here only distinguishes one category of knowledge, being component knowledge. However, further categorization of knowledge items is possible into system layers, for instance, where the categories could be divided into a user, component, hardware, and network layer. The layer structure conveniently models the knowledge a component can be related to when instantiated.
The examples and descriptions of actions on knowledge provided above can be categorized.
• Extraction -One of the main questions is where the information should come from. Some of the dependency information can be automatically extracted [38], however, most of the information, such as the component states descriptions, simply need to be input by a developer or a party that is well accustomed to the component. One solution that is appealing, is where users of the models share information about components, which allows for reuse of the knowledge. Incompatibilities can also be shared in this case, since they can be sent back to the knowledge provider. Many scenarios are possible here, where information is spread through the BitTorrent [112] protocol or through RSS feeds.
• Representation - There have been many attempts to categorize and further define the data structure for a software knowledge base [70]. At present there is no proof as to whether the knowledge representation presented in this chapter is optimal. We consider proving this to be future work, in which different ways of storing knowledge about software components are compared.
• Inference - The presented models show the advantages of using the feature descriptions for component states. Many other advantages can be achieved once the component states and instances are linked to artefact knowledge that can be used to establish the validity of a configuration. Such information can also be
used to remove the right artefacts once an instantiation is removed from a system.
• Application - The knowledge allows for a myriad of applications most of which are part of our future work. The models can be used to update a software configuration and with the right communication protocols and procedures can even become a generic release, deployment, and update tool, that supports all features (instead of a subset) described in chapter 5. The envisioned deployment tool should also be able to perform automatic deployment within a multitude of scenarios, such as a software product that consists of client and server components that must be deployed automatically on different nodes in a network. These operations are all applicable to the software knowledge base described earlier. In the case of the presented models, the software knowledge base consists of the component descriptions and the system description. In our future work we hope to add network knowledge to this, so that the software knowledge base can be used to distribute components to other users. In our view the software knowledge base is going to play a big role in the future of component based development, release, delivery, and deployment.
6.5
Discussion
The main advantage of the presented models, besides correct and consistent deployment, is the possibility of “what-if” questions. The presented models enable analysis on the deployment of a componentbeforethe deployment of a component state instance, its dependent features, and state instances. The what-if questions are answered using a number of properties of the instantiation trees. Excludes relationshipsare specific to one state instance instead of components, allowing for components that normally exclude each other to still reside on a system simultaneously. The tree depth and instantiation descriptions can be used to evaluate deployment effort. Finally, during the building of the tree,users can be queriedabout what options they have left open, to reduce both the number of possible configurations and to give the user insight into the instantiation order building process.
Another advantage of the instantiation trees is that the depth of the tree can be used to estimate the effort a deployment costs. The example instantiation tree in figure 6.7 has two instantiations below the “ECR2: Built” state instance. The branch on the left has less children thus indicating less steps to a final deployment. This tool must be used with care, however. When an instantiation sequence is shorter, that does not necessarily mean it takes less deployment effort. Another indirect advantage of composing these instantiation trees is that during the composition of such a tree, when unbound features are encountered these can be communicated back to the user. Then the user can bind the feature to see what the results are of that action. The user can now remove the feature if it is not to his liking, before actually executing the instantiation sequence.
There are clear links between the methods applied here and the practices of product lifecycle engineering. This research can be seen as a first step in creating a software product lifecycle management system that can facilitate and support the processes of development, release, delivery, and deployment. The following steps in 132
this process are a distribution architecture and a knowledge management framework. The closeness between software product management and product data management is further confirmed by Crnkovic et al. [60].
The main downside of the presented models and methods is that the data entered by the component developers is crucial for the correct functioning of the deployment algorithms, since “garbage in” results into “garbage out”. As discussed in the previous section, however, there are many possibilities for adding information to the software knowledge base. To begin with, automatic feedback can be used to report back to a supplier of a component after the deployment of that component [148]. This feedback can then be used to test for excludes on external products that a software vendor can never discover independently.
Feature descriptions are rather misused here, since they are generally used to describe high-level application requirements and features [67]. The framework, however, uses feature descriptions to model the binding times of features, the requirements of components, and the relationships between the features. We firmly believe that feature descriptions form the solution to many of the complexities related to component configuration and deployment. Feature descriptions can be used to model binding times and show the relationships between features and other required instances. Feature logic and restrictions allow for complex relations to be modeled and simplified, thus enabling algorithms such as shown in algorithm 2. The final question that needs to be answered is whether a software knowledge base really improves the processes of release, delivery, and deployment. There are four facts that point in that direction.
• Product data management improves the release and delivery of other products [54]. Since software production processes share many similarities with other production processes [60], software release, delivery, and deployment can also be improved.
• Since the current trend in the software market ismass customization, much of the information gathered in the development stages of the product can be reused at later stages during implementation at the customer and customization phases.
• Case studies[148] [62] show that centrally storing knowledge leads to reduced delivery effort.
• The ability to present“what-if” questionsto a local software knowledge base that is connected to multiple component sources can increase the reliability of the component deployment process. These questions enable a system manager to more explicitly predict what changes can be made to a system and what features can be provided within a certain configuration of components.
Some practical uses of the instantiation trees are explained here, using example 2. To begin with, different instantiation sequences can be derived using the instantiation tree. It is possible, for instance, to first satisfy the right subtree of the instantiation of “ECR2: Packaged” and then decide which of the two instantiations must be used for the left side. An example instantiation sequence for “ECR2: Running” thus consists of “CCR1: Running with Java (to build ECR2: built)”, “ECR2: Built”, “CCR1: Running with C++ (to build IMR1: built)”, “ECR2: Packaged”, “ECR2: Installed”,
and finally “ECR2: Running w IM”. In the following section is demonstrated that it is possible to perform some calculations using the properties and prerequisites for state instantiations.
The algorithms presented have been applied to two theoretical experiments of 10 and 32 components respectively, with approximately 7 features per component. When applied to larger configurations of components, we expect the instantiation trees to become quite large. This presents problems for the instantiation tree evaluation, since currently we do this by hand, usingrequiredConcurrentlysets. In the future we hope to create an algorithm that presents the user with a number of routes, such that the user can choose the one he or she prefers. Furthermore, instantiation routes can be determined automatically by storing preferences (“shortest” or “smallest memory signature”).