Finding Implicit Contracts in .NET Components

Arnout, Karine; Meyer, Bertrand

doi:10.1007/978-3-540-39656-7_12

Cited by 8 publications

(2 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…An unfortunate challenge with the status quo is that, for the vast majority of existing code, most contracts are implicit (or only described in natural-language documentation). Arnout and Meyer [2002] formulated the Closet Contract Conjecture as a means to explain this: "Because the benefits of contracts are so clear to those who use them, it's natural to suspect that non-Eiffel programmers omit contracts because they have no good way to express them, or haven't even been taught the concepts, but that conceptually contracts are there all the same: that inside every contract-less specification there is a contract wildly signaling to be let out. "…”

Section: Detecting Contractsmentioning

confidence: 99%

Putting the Semantics into Semantic Versioning

Lam¹,

Dietrich²,

Pearce³

2020

Preprint

View full text Add to dashboard Cite

The long-standing aspiration for software reuse has made astonishing strides in the past few years. Many modern software development ecosystems now come with rich sets of publicly-available components contributed by the community. Downstream developers can leverage these upstream components, boosting their productivity.However, components evolve at their own pace. This imposes obligations on and yields benefits for downstream developers, especially since changes can be breaking, requiring additional downstream work to adapt to. Upgrading too late leaves downstream vulnerable to security issues and missing out on useful improvements; upgrading too early results in excess work. Semantic versioning has been proposed as an elegant mechanism to communicate levels of compatibility, enabling downstream developers to automate dependency upgrades.While it is questionable whether a version number can adequately characterize version compatibility in general, we argue that developers would greatly benefit from tools such as semantic version calculators to help them upgrade safely. The time is now for the research community to develop such tools: large component ecosystems exist and are accessible, component interactions have become observable through automated builds, and recent advances in program analysis make the development of relevant tools feasible. In particular, contracts (both traditional and lightweight) are a promising input to semantic versioning calculators, which can suggest whether an upgrade is likely to be safe.

show abstract

Section: Detecting Contractsmentioning

confidence: 99%

Putting the Semantics into Semantic Versioning

Lam¹,

Dietrich²,

Pearce³

2020

Preprint

View full text Add to dashboard Cite

show abstract

“…Although defining contracts for the component is still our job, there are remarkable results in this field as the authors of [1] created a tool that is capable of extracting contracts from components automatically, but only in the .NET environment. A similar tool for the Java platform would not only be appreciated by component developers and assemblers but it would also provide an opportunity to compare the contracts extracted by different tools.…”

Section: Future Workmentioning

confidence: 99%

Extending a system with verified components

Dávid

Pozsgai²,

Kozma³

2007

Per. Pol. Elec. Eng.

View full text Add to dashboard Cite

The verification of component-based systems can be extremely complicated because it is usually not possible for system developers to pre-check the compatibility of the individual parts before the actual integration takes place. A system cannot be considered correct if its components do not work properly. Unfortunately, all the information on the correctness of the individual components become irrelevant and out-of-date from the moment they are used anywhere but the original environment. The solution to this problem can be based on the idea of building correct programs in which reliability is built-in. In this paper open incremental model checking-addressing the changes to a system rather than rechecking the entire system model including the new extensions-is discussed and compared to traditional modular model checking methods. In our paper we study the practical aspects and the efficiency of using Open Incremental Model Checking by working out a sample system consisting of verified components.

show abstract