Emerging component software technologies — a strategic comparison

Szyperski, Clemens

doi:10.1007/s003780050002

Cited by 36 publications

(35 citation statements)

References 1 publication

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…In particular, we consider the inside of a module a space where programmers should trust their own instincts, even allowing temporary violations of contracts; the alternative poses severe challenges known as the callback problem [22]. Furthermore, monitoring the uses of contracts within a module would negatively affect opportunities for tail-call optimizations, an essential element of functional and object-oriented program design.…”

Section: Static Modules In Plt Schemementioning

confidence: 99%

Nested and Dynamic Contract Boundaries

Strickland

Felleisen

2010

Implementation and Application of Functional Languages

View full text Add to dashboard Cite

Abstract. Previous work on software contracts assumes fixed and statically known boundaries between the parties to a contract. Implementations of contract monitoring systems rely on this assumption to explain the nature of contract violations and to assign blame to violators. In this paper, we explain how to implement arbitrary, nested, and dynamic contract boundaries with two examples. First, we add nestable contract regions to a static, first-order module system. Second, we show that even a dynamic, higher-order, and hierarchical module system can be equipped with software contracts that support precise blame assignment. Contracts for ModulesPLT Scheme [1] comes with a widely used contract system for specifying behavioral (functional) properties of module exports and imports. Roughly speaking, a behavioral software contract imposes restrictions on the domain and range of a function that flows from one module to another. If the function does not produce the kind of values promised in a contract, the run-time monitoring system raises a contract exception and blames the server module for exporting an ill-behaved function. Conversely, if the client module applies an imported function to values that fail to satisfy the domain contract, the run-time system blames the client for not living up to its promises.Unlike other systems for monitoring behavioral software contracts [2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17], PLT Scheme's contract system does not restrict contracts to first-order functions and methods. Instead, programmers may formulate contracts for all kinds of values, including higher-order values [18]. The module system, however, is restrictive. In particular, modules are merely first-order namespaces, without mechanism for nesting them or linking them in a recursive fashion. Naturally programmers chafe under this module system and call for more flexibility.At the same time, the theory of contracts assumes fixed and statically known boundaries between contract parties. Contract implementations combine compilers that can determine the parties to each contract from the source text with a run-time checking system that exploits this knowledge for blaming violators.In this paper, we relax these restrictions and show how to add arbitrary contract boundaries to the PLT Scheme module system and how to implement

show abstract

Section: Static Modules In Plt Schemementioning

confidence: 99%

Nested and Dynamic Contract Boundaries

Strickland

Felleisen

2010

Implementation and Application of Functional Languages

View full text Add to dashboard Cite

show abstract

“…In particular, we need an underlying execution model of component systems. UNU-IIST has developed a model and calculus, called rCOS [12], for component systems [31], The calculus is applied to formal use of UML in requirement analysis [22,20], design [33], and consistent code generation [25]. In rCOS, we define a component with provided and required interfaces and their functional specifications [21,15].…”

Section: Initial Progressmentioning

confidence: 99%

“…From its user's (i.e. external) point of view, a component C consists a set of provided services [31]. The syntactic specification of the provided services is described by an interface, defining the operations that the component provides with their signatures.…”

Section: Initial Progressmentioning

confidence: 99%

Integrating Theories and Techniques for Program Modelling, Design and Verification

Aichernig

Liu

et al. 2008

Verified Software: Theories, Tools, Experiments

View full text Add to dashboard Cite

show abstract

“…In this paper software components are defined as binary units of independent production, acquisition, and deployment that interact to form a functioning system [10]. Interacting means that components use and provide services mutually (see Fig.…”

Section: Service and Component Conceptmentioning

confidence: 99%

A Vehicular Software Architecture Enabling Dynamic Alterability of Services Sets

Feil

Gemkov

Stüpfle

2000

Trends in Distributed Systems: Towards a Universal Service Market

View full text Add to dashboard Cite

Abstract. In this paper we present the software architecture DANA based on components for distributed systems in vehicles. Components use and provide services. Since they are binary codes that are deployable and configurable at system's runtime, it is possible to alter the set of services during the life cycle of a vehicle. Due to the flexibility of this architecture emerging new application services for drivers and passengers can be added at any time. In order to enable the offering of such application services there is a need for services collaboration inside the distributed system which meets QoS requirements. Because the existence of many small control units in future vehicles is expected, an architecture must regard also the services provided by them. We show that the presented architecture is suitable for such an automotive environment.

show abstract

Emerging component software technologies — a strategic comparison

Cited by 36 publications

References 1 publication

Nested and Dynamic Contract Boundaries

Nested and Dynamic Contract Boundaries

Integrating Theories and Techniques for Program Modelling, Design and Verification

A Vehicular Software Architecture Enabling Dynamic Alterability of Services Sets

Contact Info

Product

Resources

About