A Model for Integrating Knowledge into Component-Based Software Development
چکیده
Component-based software development allows to reduce development costs and shortening time-to-market, by using previously existing (or third-party) components to build software. But current component technologies usually solve cross-platform or low-level technical problems. There is a lack of available techniques for ensuring reliability during the integration process. There is plenty of room for component misuses, which produce hidden errors which are difficult to detect. Also, the evolution and maintenance of systems can lead to new problems when active restrictions are forgotten and violated. It is our opinion that components should incorporate additional information about assumptions and restrictions, and these statements should be automatically verifiable at construction time, in a completely static manner, prior to the testing stages. In this paper, a component model is described which allows the integration of knowledge into component definitions, so as to check the suitability of any component combination at the earliest development stages. Then, the relationship between this abstract model and its implementation is considered. Also, the role of this model in system evolution and regressive verification is discussed. PROBLEM DESCRIPTION For several years, component-based software development has been presented as a silver bullet for many of the traditional problems of the software development industry. Components –self-contained pieces that can be used to build a system by assembling them, and reused across multiple projectshave been extensively used, with great success, in microelectronics or other engineering fields; however, the software development industry had not embraced this approach. Too often, computer programs are developed almost from scratch and in an artisan manner, with obvious disadvantages; higher costs (specially taking into account that much of the work has been done already by other teams), poorer quality (due to planning pressure and higher complexity of the systems) and a much longer time-tomarket. Software development poses problems that are not present (or have been already solved) in other engineering fields; many of these problems have no solution by now, and they are expected to remain unsolved in the years to come [9, p.7]. The use of software components is expected to bring a shorter development cycle (by buying what can be bought instead of developing from the ground up), lower cost, and better quality (because components are supposed to be welltested artefacts). In the last few years, a strong trend towards component-based software development has emerged [20]. However, we find that this paradigm is far from being mature, and the main problems have to do with proper knowledge management. Although components are expected to be robust, the integration process between different components can cause completely new defects [11, 12]. One reason is that component documentation is usually a bunch of human-readable usage instructions, written in natural languages and hence ambiguous; the only automatically-checkable specifications refer to the structure of component interfaces. This leaves plenty of room for component misuses; when joining components, a systems integrator can unintentionally violate the assumptions made by the component creator, be it calling order, concurrency issues, or use protocols. These defects can easily remain hidden until run time, with catastrophic consequences [15]. Moreover, the evolution and maintenance of systems can get even worse. As components and systems evolve, any change can also introduce new problems, and they can be very difficult to catch [16] . Even if a good regression test is done, there can be defects which have nothing to do with the global behaviour of the system, but with local requirements of individual components that are violated only in a few situations; in these cases, effective testing can be very difficult to achieve. So techniques are needed in order to guarantee that evolution does not induce a degradation of the system or affect its reliability [16, 19]. We think that design issues should be represented in a manner that can be processed by a machine [3] so that they can be verified whenever a change is made to the system. Pre-/postconditions and invariants have been used for this purpose [17], but software must be executed in order for these mechanisms to act, and in some sense, they suffer from the same difficulties as testing. COMPONENTS AND KNOWLEDGE AS A MEANS OF VERIFYING SOFTWARE Our research work is oriented towards this kind of problems. We think that the traditional testing stage is necessary, but many problems could be caught in a static analysis, at earlier development stages (at construction time). Many efforts have been made in the area of general-purpose static analysis of programs [2, 5, 6, 7, 14], but we think that another important key is the use of specific knowledge about the components and the codification of this knowledge in an automatically-checkable manner. A component model can be used not only to physically organize the software, or to achieve a shorter or cheaper development cycle, but also to statically verify the software and to support the storing of knowledge about components. The term statically, in this context, implies that no execution of the program is needed. Our model proposes that a component’s interface not only has a set of operation names and parameters, but also a set of restrictive expressions. These expressions state which conditions should be fulfilled when using the component, and also what the component can guarantee about its output. Assuming that components are black boxes that can only be used by interacting with their exposed interfaces, the only way of making a bad use of a component would be a bad use of these interfaces. So restrictive expressions about interfaces should detect –and hence help to preventany kind of misuse of the components. As an elementary example, units of measurement are a traditional source of mismatches. Very frequently, type information does not allow distinguishing between different units; but type information is very often the only one that gets verified for proper matching. Should we decide to (automatically) verify measurement units mismatches in a system, a first solution would be the definition of a new, specific data type. But this is not always possible. If components carry also restrictive expressions as proposed here, this problem can be addressed. The component designer/builder can write down all the relevant information, including component requirements. When two components are connected, each of the connection points can be tested for validity; the restrictive expressions associated with both components must match without leading to inconsistencies. If a component requires certain input value to be expressed in km, for instance, the element connected to that input value must offer some expression which states that the provided value is always expressed in km. Otherwise, the verification process will pinpoint the failed statement. FIRST-ORDER LOGIC PREDICATES AND KNOWLEDGE BASE GENERATION Our undergoing research project is focused in these ideas, and we are developing a component model for checking them. This component model (code-named Itacio [4, 13]) uses first-order logic predicates [18] in the form of Horn clauses as the means for expressing restrictions. THE COMPONENT MODEL Components: A component C is an entity which has a frontier F and a set of restrictive expressions E. Given a component C, we will also use the notation F(C) and E(C) to designate the frontier and the set of restrictive expressions of that component. The set of all possible components is denoted by C. The frontier of a component is a finite set whose elements are called connection points. A connection point can be a source (s) or a sink (k), so F is in fact divided into two disjoint subsets: F = S ∪ K S ∩ K = ∅ where S = {s1, s2, ..., sn} 2 K = {k1, k2, ..., km} The set of all possible connection point names is denoted by A (from “atoms”). We will make use of the notation S(C) and K(C) to designate respectively the set of sources and the set of sinks of a given component C. Also, notice that when several components are involved, indices are used to refer to components or their parts, and the dot notation may be used to qualify the connection points. Qualified names include the component name so that ambiguities are avoided; for instance, si ∈ S(Cn) becomes Cn.si Restrictive expressions are also divided into two disjoint sets: the set of requirements, R, and the set of guarantees, G. Both R and G are populated by first-order logic 1 Domains will be expressed with bold fonts. 2 Italic fonts will be used for connection points, so that they can be distinguished from indices. predicates over the connection points of that component. The set of all possible predicates is denoted by P.