A Flexible Strategy for Embedding and Configuring Run-Time Contract Checks in .Net Components (original) (raw)

Runtime Contracts Checker: Increasing Robustness of Component-Based Software Systems

IOP Conference Series: Materials Science and Engineering

Software Systems are becoming increasingly complex leading to new Validation &Verification challenges. Model checking and testing techniques are used at development time while runtime verification aims to verify that a system satisfies a given property at runtime. This second technique complements the first one. This paper presents a runtime contract checker (RCC) which checks a component-based software system’s contracts defined at design phase. We address embedded systems whose software components are designed by Unified Modelling Language-State Machines (UML-SM) and their internal information can be observable in terms of model elements at runtime. Our previous research work, CRESCO (C++ REflective State-Machines based observable software COmponents) framework, generates software components that provide this observability. The checker uses software components’ internal status information to check system level safety contracts. The checker detects when a system contract is violate...

Supporting Behavioral Contracts for COM Components

Specifying behavioral specifications for components apart from the conventional syntactic interface specifications can be very useful in component based system development. Preconditions and postconditions describe one form of behavioral aspects of components. We discuss a tool and an implementation mechanism to incorporate behavioral contracts expressed in terms of preconditions and postconditions for COM components. A method invocation on a component is executed only if the precondition is satisfied. Similarly, the results are successfully returned upon successful execution of the postcondition. A design criterion was to facilitate contract specifications for existing components with least amount of changes at client and server side code. The tool requires that the component should implement an additional interface called IAccess if the behavioral contract needs component state. No modification is required to existing clients of the component.

A Technique for Verifying Component-Based Software

Electronic Notes in Theoretical Computer Science, 2005

Component-based software systems raise new problems for the testing community: the reuse of components suggests the possibility of reducing testing costs by reusing information about the quality of the software components. This paper addresses the problem of testing evolving software systems, i.e., systems obtained by modifying and/or substituting some of their components. The paper proposes a technique to automatically identify behavioral differences between different versions of the system, to deduce possible problems from inconsistent behaviors. The approach is based on the automatic distilling of invariants from in-field executions. The computed invariants are used to monitor the behavior of new components, and to reveal unexpected interactions. The event generated while monitoring system executions are presented to software engineers who can infer possible problems of the new versions. 1

Toward multi-language, multi-component interface contract enforcement

2009

This paper describes current work aimed at helping scientists gain confidence in software built from emerging component technologies through the automated enforcement of interface contracts. These contracts consist of assertions required to hold before and after interface methods are executed. Runtime contract enforcement is a well-known technique for enhancing testing and debugging, but is typically considered too expensive for deployment. Prior work investigated strategies intended to retain an application's high performance while enforcing contracts during plug-and-play component deployment. The associated studies involved single-component implementations in C and C++.

Supporting Tools for Designing-By-Contract in Component-Based Applications

Lecture Notes in Computer Science, 2005

This paper deals with the modeling and the automatic implementation of constraints in component based applications. Constraints have been assuming an ever more relevant role in modeling distributed systems as long as business rules implementation, design-by-contract practice, and fault-tolerance requirements are concerned. Nevertheless, component developers are not sufficiently supported by existing tools to model and implement such features. In this paper, we propose a set of tools that enable developers both to model component constraints and to automatically generate component skeletons that already implement such constraints.

Application invariants: Design by Contract augmented with deployment correctness logic

Software: Practice and Experience, 2006

Design by Contract is a method for the development of robust object-oriented software, introducing class invariants as conditions corresponding to the design axioms that should be satisfied by every valid instance of a class. Additionally, the method states formally the way client programs should correctly utilize supplier classes, so that the composition of correct programs may be accomplished. However, the contextual correctness of supplier instances within client programs, only reflected in the client-specific semantics for supplier-class deployment, cannot be expressed through Design by Contract. For instance, supplier instances satisfying the supplier class invariant may not constitute plausible supplier instances in the context of a particular client program. In this context, we introduce application invariants as an extension to Design by Contract, for hosting the contextual-correctness logic for supplier instances, as conditionally defined by client programs. This allows stronger validation of supplier instances, through the dynamic encapsulation of client-specific acceptance filtering, enabling more intensive defect detection. Application invariants are implemented in the context of client classes as methods utilizing correctness condition expressions, are dynamically hosted within supplier instances, while always called by supplier instances when the basic supplier-class invariant test is performed.

Painless Support for Static and Runtime Verification of Component-Based Applications

Lecture Notes in Computer Science, 2015

Architecture Description Languages (ADL) provide descriptions of a software system in terms of its structure. Such descriptions give a high-level overview and come from the need to cope with arbitrarily complex dependencies arising from software components. In this paper we present Painless, a novel ADL with a declarative trait supporting parametrized specifications and architectural reconfigurations. Moreover, we exhibit its reliable facet on its integration with ProActive-a middleware for distributed programming. This is achieved by building on top of Mefresa, a Coq framework for the reasoning on software architectures. We inherit its strong guarantees by extracting certified code, and subsequently integrating it in our toolchain.

Making components contract aware

Computer, 1999

Before we can trust a component in mission-critical applications, we must be able to determine, reliably and in advance, how it will behave.

A framework for detecting interface violations in component-based software

1998

Two kinds of interface contract violations can occur in component based software: a client component may fail to satisfy a requirement of a component it is using, or a component implementation may fail to fulfil its obligations to the client. The paper proposes a systematic approach for detecting both kinds of violations, so that violation detection is not hard coded into base level components, but is “layered” on top of them, and so that it can be turned “on” or “off” selectively for one or more components, with practically no change to executable code (limiting changes to a few declarations). Among the salient features of this approach are its use of formal specifications, the ability to handle parameterized (i.e., generic, or template) components, and the automatic generation of routine aspects of violation detection. We have designed, built, and experimented with a generator of checking components for C++ templates