Industrial-scale software is commonly very large and complex, making it difficult and time-consuming to develop. In order to manage complexity in software, developers break systems into smaller components which can be developed independently. Software contracts were first proposed several decades ago; they are used to explicitly specify the interfaces between software components to ensure that they work together correctly. Software contracts specify both the responsibility of a client using a service and of the component providing the service. The advantage of contracts is that they formalise what constitutes correct interactions between software components. In addition, they serve as documentation, as well as a basis for test cases, and help clarify correct use of inheritance. However, despite their usefulness, software contracts are still not widely used in mainstream software engineering. In this work, we aim to develop a new software contract tool which we hope will help increase the use of software contracts. We start our work by evaluating existing software contract technologies and uncover a range of inconsistencies and shortcomings. We find that there are disagreements surrounding even some of the most basic aspects of software contracts. Using the lessons learned from our analysis of existing tools, we design a new contract tool, PACT. We describe in detail the formal semantics and typing of PACT and develop a first implementation of our tool. Finally, we discuss the advantages of PACT over existing tools, including its rigorous separation of interfaces and implementations, its rich inheritance semantics, and its support for flexible and expressive definition of contracts.

Master of Science / Department of Computing and Information Science / Torben Amtoft / Invariants are properties which are asserted to be true at certain program points. Invariants are of paramount importance when proving program correctness and program properties. Method, constructor, and class invariants can serve as contracts which specify program behavior and can lead to more accurate reuse of code; more accurate than comments because contracts are less error prone and they may be proved without testing. Dynamic invariant generation techniques run the program under inspection and observe the values that are computed at each program point and report a list of invariants that were observed to be possibly true. Static checkers observe program code and try to prove the correctness of annotated invariants by generating proofs for them. This project attempts to get strong invariants for a subset of classes in Java; there are two phases first we use Daikon, a tool that suggests invariants using dynamic invariant generation techniques, and next we get the invariants checked using ESC/Java2, which is a static checker for Java. In the first phase an ‘Instrumenter’ program inspects Java classes and generates code such that sufficient information is supplied to Daikon to generate strong invariants. All of this is achieved without any user input. The aim is to be able to understand the behavior of a program using already existing tools.

This thesis aims to analyze whether the alternative EU forum loci solutionis of Article 7 (1) of the Brussel Ibis Regulation is applicable to Software Contracts. This is done by analyzing and accounting for the structure, purpose and problems of the application of BIbis Article 7 (1) to Software Contracts, by using a fictive case to highlight the particular problems regarding these types of contracts. Since two types of contracts are specifically stated in Article 7 (1) (b): sale of goods and provision of services, the thesis finds that Software Contracts may be characterized as either of these with the autonomous criteria established by CJEU case-law, or as another type of contract under Article 7 (1) (a). In the second step of localization in the method established by CJEU case-law, the four identified places of performance for Software Contracts are: (i) the place of the upload; (ii) the place of the download; (iii) the place to which the service provider has a special connection; and (iv) the place to which the buyer has a special connection. By approaching this issue de lege ferenda, a technology neutral method is first proposed for resolving the issue of characterization. This technology neutral method is further proposed for the following localization issue of identifying the place of performance for Software Contracts under the forum loci solutionis provision in BIbis Article 7 (1), where the place of performance for Software Contracts characterized as sale of goods is the place of download. Respectively, the place of performance for Software Contracts for provision of services under BIbis Article 7 (1) (b) is the domicile of the service provider.