Treffer: Extra-functional contract support in components

Title:
Extra-functional contract support in components
Source:
CBSE 2004 : component-based software engineering (Edinburgh, 24-25 May 2004)Lecture notes in computer science. :217-232
Publisher Information:
Berlin: Springer, 2004.
Publication Year:
2004
Physical Description:
print, 22 ref
Original Material:
INIST-CNRS
Document Type:
Konferenz Conference Paper
File Description:
text
Language:
English
Author Affiliations:
INRIA-Rennes, Campus universitaire de Beaulieu, Avenue du général Leclerc, 35042 Rennes, France
ISSN:
0302-9743
Rights:
Copyright 2004 INIST-CNRS
CC BY 4.0
Sauf mention contraire ci-dessus, le contenu de cette notice bibliographique peut être utilisé dans le cadre d’une licence CC BY 4.0 Inist-CNRS / Unless otherwise stated above, the content of this bibliographic record may be used under a CC BY 4.0 licence by Inist-CNRS / A menos que se haya señalado antes, el contenido de este registro bibliográfico puede ser utilizado al amparo de una licencia CC BY 4.0 Inist-CNRS
Notes:
Computer science; theoretical automation; systems
Accession Number:
edscal.15875926
Database:
PASCAL Archive

Weitere Informationen

According to Szyperski, a software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. But it is well known that these contractually specified interfaces should go well beyond mere syntactic aspects: they should also involve functional, synchronization and Quality of Service (QoS) aspects. In large, mission-critical component based systems, it is also particularly important to be able to explicitly relate the QoS contracts attached to provided interfaces with the QoS contracts obtained from required interfaces. In this paper we propose a language called QoSCL (defined as an add-on to the UML2.0 component model) to let the designer explicitly describe and manipulate these higher level contracts and their dependencies. We show how the very same QoSCL contracts can then be exploited for (1) validation of individual components, by automatically weaving contract monitoring code into the components; and (2) validation of a component assembly, including getting end-to-end QoS information inferred from individual component contracts, by automatic translation to a Constraint Logic Programming language. We illustrate our approach with the example of a GPS (Global Positioning System) software component, from its functional and contractual specifications to its implementation in a.Net framework.