Building Hierarchical Component Directories.

Abstract

Component-based development is the software paradigm focused on building applications using reusable software components. Applications are built by assembling components, where the required interfaces of a component are connected to compatible provided interfaces of other components. In order to have an effective building process, software architects need adequate component directories that both index available components and ease their search. So far, existing approaches provide only a limited structure and indexation to store/register components and, as a consequence, they propose an inadequate searching process. Even when the indexes are built as flat or hierarchical structures, the indexed elements are not the components themselves, but part of them, such as services or functions, making the search of the needed compatible components imprecise. To cope with searching and compatibility problems, the contribution of this paper is twofold: it is composed of both a refined methodology (improving a previous approach) and a tool to build a hierarchically structured component directory. The component directory solves the identified problems letting an architect find components that are compatible with a given specification (to be assembled) or components that can substitute to a given one. This directory uses Formal Concept Analysis to build component type hierarchies thanks to a three step classification process that successively classifies functionality signatures, interfaces and, at last, component types. The refinement of the methodology is based on a substitutability relationship between components, where the notion of not having a parameter or an interface of some type makes our methodology more robust when considering required interfaces. The tool made possible

Relational Concept Analysis in Practice: Capitalizing on Data Modeling Using Design Patterns

“…Revisiting applications with the DPs The DP Separate/Gather Views presented in Section 3 could be applied to revisit and improve a previous work on component catalog FCA-based building [1], in which software components were described with provided/required interfaces, each interface containing a set of services. In this catalog, the description was made using a single formal context.…”