RANKING AND SELECTING COMPONENTS TO BUILD SYSTEMS
Alberto Sillitti, Tullio Vernazza, Giampiero Granatella, Paolo Predonzani DIST – Università di Genova, Via Opera Pia 13, I-16145 Genova, Italy Email:
[email protected],
[email protected],
[email protected],
[email protected]
Giancarlo Succi Libera Università di Bolzano, Piazza Domenicani 3, I-39100 Bolzano, Italy Email:
[email protected]
Keywords:
Component-based software engineering, COTS, large repositories, integration
Abstract:
Component-Based Software Engineering (CBSE) allows developers to build systems using existing components. Developers need to find the best set of components that implements most of required features. Retrieving components manually can be very complicated and time expensive. Tools that partially automate this task help developers to build better systems with less effort. This paper proposes a methodology for ranking and selecting components to build an entire system instead of retrieving just a single component. This methodology was developed in the European project CLARiFi (CLear And Reliable Information For Integration).
1
INTRODUCTION
In recent years, many industries and consortia have developed standards for components. Some of these standards are Enterprise Java Beans (EJB), Component Object Model and Distributed Component Object Model (COM and DCOM), Common Object Request Broker Architecture (CORBA), and Microsoft .NET. Components suppliers and systems integrators meet in virtual marketplaces that are large commercial repositories of components now available on the web. These components marketplaces are virtual meeting point for suppliers and system integrators. These evolutions pushed the use of CBSE providing benefits like less duplication of work and lower development costs for new applications (Bass et al., 1998) (Brown et al., 1998) (Krieger et al., 1998) (Szyperski, 2002). CBSE forces system integrators to spend a lot of effort in marketplaces for retrieving the set of components that best fit requirements. These repositories contain a huge number of components; for that reason an effective search mechanism should
help reducing time spend in searching and providing better results. The aim of the EU co-founded project CLARiFi was the development of a component broker that allow integrators to perform search for set of components, rather than a single one. This retrieving technique allows building complete systems more easily. This paper presents a methodology for ranking and selecting components to build a whole system. The paper is organized as follows: section 2 presents an overview of the CLARiFi project; section 3 and subsections describe the ranking and selection process used in CLARiFi; finally, section 4 draws the conclusions.
2 THE CLARIFI SYSTEM: AN OVERVIEW The target of the CLARiFi project is the development of a component broker that provides quality components and helps integrators to build a complete system. Four parts compose CLARiFi (Figure 1):
Supplier
Broker
Integrator
Certifier
Figure 1: Overview of the CLARiFi system
1.
2.
3.
4.
Broker: it is the centralized repository of all data describing components. These data include both components’ properties descriptions and information dealing with properties certification. Supplier: it produces components and stores their description into the Broker. The description has to follow the CLARiFi classification model, based on an attributevalue scheme. The Supplier uses a tool that assists it in the classification process. Certifier: it certificates a whole component or functionalities that a component provides. The Supplier starts the certification process sending a request to a Certifier specifying properties that it has to verify. After the verification process, the Certifier certifies the property in the Broker through a specific tool. Integrator: it searches for components to build a system. The tool helps the integrator to describe the desired system, and then it performs a search inside the components’ database and displays results according to constraints and preferences specified. Then, the search refinement process helps the Integrator to find the best solution (Figure 2). User preferences
User Constrains
Ranking & Selection process
a system, among those available in the Broker. That is a process because it is composed of a sequence of steps. It involves two actors, the Integrator and the Broker, and it is interactive. The steps of the process are (Figure 3): • Functional decomposition, in which the integrator describes his target system through functionalities • Non functional requirements • Contexts. The definition and the storage of a set of requirements helps the integrators to effectively use (and re-use) the R&S in CLARiFi • Comparison of candidate components. Multiple Criteria Decision Making (MCDM) and graphical methods allows the integrator to compare easily the properties of the single candidate components • Compatibility checks. The Broker checks that selected components can effectively collaborate in a system • Multiple selections. At the end of the process, the Integrator has more candidate systems (due to selection branches). The Integrator evaluates them and selects the one that he prefers This process is not a waterfall process. The Integrator can move through the steps to have the most effective interaction with the Broker. Figure 3 shows the R&S process and the possible paths among the steps. Requirements Functional requirements
Non Functional requirements
Components’ selection
Compatibility check
System selection
System
Figure 2: Overview of the ranking and selection process Figure 3: Steps of the ranking and selection process
3 RANKING AND SELECTING COMPONENTS
3.1 Describing systems
Ranking and selection (R&S) is a process that allows an integrator to find the right components for
In CLARiFi, the Integrator starts describing requirements of the target system. A system is a set
of functionalities suitable to approach some issues. According to this view, the integrator first inserts functional requirements and then the other requirements (non-functional). The starting point of the R&S in CLARiFi is different compared to other commercial repositories. CLARiFi gives a better relevance to the functionality of the system. In commercial repositories on the web, the integrator starts the selection choosing the kind of technology. After that, he selects single components loosing the concept of system. Using such repositories, the final system is only a set of components that shares the same technology. The “functional ability” describes the functionality of a component (Damiani et al., 1999) (Frakes et al., 1994) (Furnas et al., 1987) (Prieto-Diaz, et al., 1987). Functional ability describes the functionality using a fixed semantic . The root of the functional ability tree (Figure 4) gives the more general functionality of a component. It is possible to decompose the root in more detailed nodes. The derived functionalities are a detailed description of the ancestor functionality (Henninger, 1994) (Henninger, 1997).
Functional requirements Non Functional requirements
Figure 4: Requirements’ representation
The Integrator starts from a base functionality for his system. The Broker searches in the repository the functional ability given by the integrator. Then two scenarios are possible: 1. One or more components satisfy the required general functionality. The Integrator selects the component that he prefers and the process stops. The Integrator has a system composed by a single component.
2.
The functionality is unsatisfied (or the Integrator does not like the suggested components). In this scenario, the Broker helps the Integrator to decompose the functionality in a set of sub-functionalities using pre-existing hierarchies of functionalities. In fact, during the search of functionalities, the Broker returns also the hierarchies of functional abilities that include the required ones. These derived functionalities can be recursively decomposed in ones that are more detailed. At the end of the process of decomposition, the integrator has created a tree-like structure of functionalities with decreasing granularity. The root is a general, high-level functionality and the “leaves” are detailed low-level functionalities. Then, the Broker searches in the repository the detailed functionalities. The first requirements are usually functional (Maiden et al., 1998) (Zaremski et al., 1995). Functional requirements define the system and a set of candidate components. After the system definition and the functional decomposition, the Broker asks the Integrator the non-functional requirements. The Broker uses them to discriminate candidate components. Requirements include constraints and preferences (Figure 2). Constraints represent what the system must do; preferences point out what the system should do, therefore the Broker uses them to rank components. When a functional ability is divided in subfunctionalities, the non-functional requirements could be “inherited” also by the “leaves”. The inheritance of the requirements depends on the property. If an Integrator selects “linux” as operating system for an ancestor, probably this requirement will be correct also for the derived functionalities. However, if an Integrator sets the performance for the components for a functional ability less than threshold, he wants that the sum of the performance of the leaves will be less than the selected threshold. The problem of inheritance has not a general theory but it strictly depends on the single properties.
3.2 Contexts In CLARiFi, it is possible to store and manage set of requirements (functional and non functional, constraint and preferences) through contexts. A context is a set of Integrator’s preferences and constraints stored and managed by the same Integrator or by the Broker. The context’s usage allows reusing the knowledge of a previous selection in future selection
of different systems. At the same time, it can freeze the state of a selection (that the integrator can use again) or split the selection in more branches.
3.3 Selection of single components A high number of candidate components may discourage the Integrator from evaluating them accurately. On the other hand, a small number allows the Integrator to evaluate components deeply. In both cases, the Broker can help ranking the candidates according to the Integrator’s preferences. For the comparing components, the Broker needs to understand clearly the property-values that describe them and the importance of properties. A multiple criteria decision is the choice of a possible action or alternative obtained by two or more criteria (Efthimiadis, 1993). In the literature, decision-making is performed under uncertainty (uncertainty about value of data or user preferences) or multiple criteria (which consider trade-off about criteria and relationships between objectives) (Fandel et al., 1985). Whatever technique, the interaction between the system and the user must be simple and effective (Liping et al., 1993).
3.5 Selection of the final system The R&S process allows the Integrator to make different choices. These cause the creation of branches that produce different final systems. The CLARiFi system is able to keep track of such branches using the multiple selection mechanism (the Integrator can choose more than one value for a property and look for such systems). Often, multiple branches occur because of: 1. different functional decomposition 2. selection of different components for the same functionality 3. different non functional requirements Different functional decomposition describes different ways to represent the functionality of the final system (Figure 5). F0
F0 F1 F1 B1.1 F1.2
A2
B1.2 F1.3
3.4 Compatibility check The Integrator wants to build a system. A system is a set of interacting components. To interact, components must be compatible. The description of components includes a detailed description of input and output channels (called ports) (Van Der Linder et al., 1994). The system checks the compatibility between the components and highlights if there is compatibility at a physical layer, at a semantic layer or there is no compatibility. To simplify the check of compatibility the Integrator specifies components that interact directly. An experienced Integrator can specify also the ports to apply the compatibility check, rather then the entire component. The compatibility check is combinatory problem. If the system considers compatibility among all the components, the number of calculations is extremely high and most of the comparisons have no sense at semantic level like comparing a component for printing and one for performing an ecommerce transaction. The Integrator uses the compatibility check only with the components that really interact directly.
A1
F1.1
A3
F2
Figure 5: Different functional decompositions produce branches
In this case, there are three possible final systems obtained by the different decomposition of F0 and F1. These systems are {F0, F1, F1.1, F1.2, F1.3, F2}, {F0, F1, B1.1, B1.2, F2} and {F0, A1, A2, A3}. Many candidate components can satisfy a single constrain. The choice of a single component obviously changes the final solution, because components are not single entity but parts of a system, therefore they have to communicate and collaborate inside the final solution. A single selection influences also the following components selection (e.g. if Integrator selects MS SQL Server, probably he will select MS IIS as web-server). Adding different non-functional requirements produce different sets of candidate components (e.g. certified or not certified components). Therefore, the Integrator can split the selection in branches to evaluate the impact of a non functional requirement added to the final system. At the end, the Integrator has possible systems that satisfy the requirements expressed. All of those
systems are theoretically acceptable; in fact, all of them are a set of interacting components that satisfy the required functionality. Then, the Integrator can select a system using multiple criteria that CLARiFi support MCDM (Multiple Criteria Decision Making) methods. These do not care if the alternatives are components or systems and do not care about what the attributes represent. With the suggestions of reports and MCDM methods, CLARiFi helps the Integrator in the choice of the final system.
4
CONCLUSIONS
CLARiFi proposes a new approach for searching components inside a repository moving focus from single components to the whole system that an integrator desires. The use of tools that provide automatic compatibility check, comparisons of final systems generated performing different choices, and the MCDM methods to help the integrator in the choice make CBSE easier to implement avoiding unnecessary waist of time in components retrieval.
REFERENCES Bass, L., Clements, P., Kazman, R., 1998.. Software Architecture in Practice, Addison-Wesley. Brown, A., Wallnau, K.., 1998. The Current State of Component-based Software Engineering. In IEEE Software. Damiani,, E., Fugini, M.G., Bellettini, C., 1999. A Hierarchy-Aware Approach to Faceted Classification of Object-Oriented Components. In ACM TOSEM. Efthimiadis, E.N., 1993. A integrator-centred evaluation of ranking algorithms for interactive query expansion. In Proc. of the 16th annual international ACM SIGIR conference on Research and Development in Information Retrieval. Fandel, G., Spronk, J., 1985. Multiple criteria decision methods and application. Springer-Verlag. Frakes, W., Pole, 1994. An Empirical Study of Representation Methods for Reusable Software Componentsi. In IEEE Transactions on Software Engineering. Furnas, G.W., Landauer, T.K., Gomez, L.M., Dumais, S.T., 1987. The Vocabulary Problem in HumanSystem Communication. In Communication of ACM. Henninger, S., 1994. Using iterative refinements to find reusable software. In IEEE Software. Henninger, S., 1997. An evolutionary approach to constructing effective software reuse repositories. In ACM TOSEM.
Krieger, D., Adler, R.M., 1998. The Emergence of Distributed Component Platform. In IEEE Computer. Liping, F., Hipel, K.W., 1993. Interactive Decision Making. Wiles. Maiden, N.A.M., Ncube, C., 1998. Acquiring Requirements for Commercial Off-The-Shelf Package Selection. In IEEE Software. Prieto-Diaz, R., Freeman, P., 1987. Classifying Software for Reusabililty. In IEEE Software. Szyperski, C., 2002. Component Software. AddisonWesley. Van Der Linden, F., Muller, J.K., 1994. Creating architectures with building blocks. In IEEE Software. Zaremski, M., Wing, J.M., 1995. Specification matching of software components. In Proc. of the 3rd ACM SIGSOFT Symposium on the Foundations of Software Engineering.
