FRINK Linked Data Fragments server

Matches in SemOpenAlex for { <https://semopenalex.org/work/W1482398686> ?p ?o ?g. }

• W1482398686 abstract "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." @default.
• W1482398686 created "2016-06-24" @default.
• W1482398686 creator A5007467537 @default.
• W1482398686 creator A5017967454 @default.
• W1482398686 creator A5043602579 @default.
• W1482398686 date "2001-01-01" @default.
• W1482398686 modified "2023-10-18" @default.
• W1482398686 title "A Model for Integrating Knowledge into Component-Based Software Development" @default.
• W1482398686 cites W1511102551 @default.
• W1482398686 cites W1536217426 @default.
• W1482398686 cites W1593874741 @default.
• W1482398686 cites W1980767016 @default.
• W1482398686 cites W1992050254 @default.
• W1482398686 cites W2082810026 @default.
• W1482398686 cites W2109033710 @default.
• W1482398686 cites W2131227007 @default.
• W1482398686 cites W2132661148 @default.
• W1482398686 cites W2149561845 @default.
• W1482398686 cites W2167500728 @default.
• W1482398686 cites W2174627168 @default.
• W1482398686 cites W2295244175 @default.
• W1482398686 cites W3006510919 @default.
• W1482398686 cites W3214983284 @default.
• W1482398686 cites W60370665 @default.
• W1482398686 hasPublicationYear "2001" @default.
• W1482398686 type Work @default.
• W1482398686 sameAs 1482398686 @default.
• W1482398686 citedByCount "5" @default.
• W1482398686 countsByYear W14823986862013 @default.
• W1482398686 crossrefType "journal-article" @default.
• W1482398686 hasAuthorship W1482398686A5007467537 @default.
• W1482398686 hasAuthorship W1482398686A5017967454 @default.
• W1482398686 hasAuthorship W1482398686A5043602579 @default.
• W1482398686 hasConcept C115903868 @default.
• W1482398686 hasConcept C121332964 @default.
• W1482398686 hasConcept C144133560 @default.
• W1482398686 hasConcept C168167062 @default.
• W1482398686 hasConcept C174683762 @default.
• W1482398686 hasConcept C195094911 @default.
• W1482398686 hasConcept C199360897 @default.
• W1482398686 hasConcept C2777904410 @default.
• W1482398686 hasConcept C41008148 @default.
• W1482398686 hasConcept C529173508 @default.
• W1482398686 hasConcept C56739046 @default.
• W1482398686 hasConcept C97355855 @default.
• W1482398686 hasConceptScore W1482398686C115903868 @default.
• W1482398686 hasConceptScore W1482398686C121332964 @default.
• W1482398686 hasConceptScore W1482398686C144133560 @default.
• W1482398686 hasConceptScore W1482398686C168167062 @default.
• W1482398686 hasConceptScore W1482398686C174683762 @default.
• W1482398686 hasConceptScore W1482398686C195094911 @default.
• W1482398686 hasConceptScore W1482398686C199360897 @default.
• W1482398686 hasConceptScore W1482398686C2777904410 @default.
• W1482398686 hasConceptScore W1482398686C41008148 @default.
• W1482398686 hasConceptScore W1482398686C529173508 @default.
• W1482398686 hasConceptScore W1482398686C56739046 @default.
• W1482398686 hasConceptScore W1482398686C97355855 @default.
• W1482398686 hasLocation W14823986861 @default.
• W1482398686 hasOpenAccess W1482398686 @default.
• W1482398686 hasPrimaryLocation W14823986861 @default.
• W1482398686 hasRelatedWork W1493616098 @default.
• W1482398686 hasRelatedWork W1543219516 @default.
• W1482398686 hasRelatedWork W1567296372 @default.
• W1482398686 hasRelatedWork W1649109310 @default.
• W1482398686 hasRelatedWork W1705738597 @default.
• W1482398686 hasRelatedWork W182987280 @default.
• W1482398686 hasRelatedWork W184025731 @default.
• W1482398686 hasRelatedWork W2002345421 @default.
• W1482398686 hasRelatedWork W2108884323 @default.
• W1482398686 hasRelatedWork W2110778140 @default.
• W1482398686 hasRelatedWork W2126975916 @default.
• W1482398686 hasRelatedWork W2135178953 @default.
• W1482398686 hasRelatedWork W2137488269 @default.
• W1482398686 hasRelatedWork W2350617791 @default.
• W1482398686 hasRelatedWork W2366150543 @default.
• W1482398686 hasRelatedWork W2367501179 @default.
• W1482398686 hasRelatedWork W2386371878 @default.
• W1482398686 hasRelatedWork W2522878296 @default.
• W1482398686 hasRelatedWork W2547365576 @default.
• W1482398686 hasRelatedWork W31597494 @default.
• W1482398686 isParatext "false" @default.
• W1482398686 isRetracted "false" @default.
• W1482398686 magId "1482398686" @default.
• W1482398686 workType "article" @default.