Formal specification techniques in object-oriented analysis: a comparative view.

During the last decade, object orientation has been advanced as a promising paradigm for software construction. In addition several authors have advocated the use of formal specification techniques during software development. Formal methods enable reasoning (in a mathematical sense) about properties of programs and systems. It is clear that also object oriented software development can benefit from the use of formal techniques.But although the object oriented analysis (OOA) methods claim to provide the necessary concepts and tools to improve the quality of software development, they are in general informal. This is surprising as the modeling techniques used in OOA have a high potential for formalization. The purpose of this study is to compare the specification techniques used in current OOA-methods. In particular, the degree of formality provided by most of the methods is discussed and evaluated from a quality control perspective.Software; Methods; Programs; Systems; Studies; Quality control;

Reasoning About Object-Oriented Programs That Use Subtypes

Programmers informally reason about object-oriented programs by using subtype relationships to classify the behavior of objects of different types and by letting supertypes stand for all their subtypes. We describe formal specification and verification techniques for such programs that mimic these informal ideas. Our techniques are modular and extend standard techniques for reasoning about programs that use abstract data types. Semantic restrictions on subtype relationships guarantee the soundness of these techniques

Modular Verification of Object-Oriented Programs with Subtypes

Object-oriented programming languages like Smalltalk-80 have a message passing mechanism that allows code to work on instances of many different types. Techniques for the formal specification of such polymorphic functions and abstract types are described, as well as a logic for verifying programs that use message passing but not object mutation or assignment. The reasoning techniques formalize informal methods based on the use of subtypes. A formal definition of subtype relationships among abstract types whose objects have no time-varying state but may be nondeterministic or incompletely specified is given. This definition captures the intuition that each instance of a subtype behaves like some instance of that type\u27s supertypes. Specifications of polymorphic functions are written by allowing instances of subtypes as arguments. Restrictions on the way that abstract types are specified ensure that such function specifications are meaningful and do not have to be rewritten when new subtypes are specified. Verification consists of showing that the specified relation among types has certain semantic properties, that each expression\u27s value is an instance of a subtype of the expression\u27s type, and a proof of correctness that ignores subtyping

Capturing and exploiting abstract views of states in OO verification

In this thesis, we study several implementation, specification and verification techniques for Object-Oriented (OO) programs. Our focus is on capturing conceptual structures in OO states in abstractions, and then exploiting such an abstract view of the state in specification and implementation approaches in a way that allows for formal verification. Generally, an OO state consists of many objects that reference each other in possibly complicated ways. At the same time, at any one point in the execution of the program, we can often reason about what is happening using an abstract view of the state that is much less complicated. To further improve the quality of implementations, better techniques must be developed for 1) specification of the abstract views that are used by the client and the programmer, and 2) the verification that an implementation satisfies its specification. This thesis contributes to that effort. We distinguish between client-level and programmer-level specification. A client-level specification acts as a contract between the client and the implementer. A programmer-level specification allows to reason formally about the implementation. We consider two specification formalisms that differ in the basic abstract view that is used: Algebraic Specification and OO Specification. We consider both client-level and programmer-level specifications based on algebraic specification. We contribute a novel syntax and semantics for the former, and we contribute an implementation approach for OO implementations based on the latter. We show that the implementation approach is suitable for problem-independent verification. We propose the programmer-level OO specification constructs inc and coop. The inc construct allows method specification to make explicit that a certain enumeration of invariants does not have to hold when that method is executed. The coop construct allows a field specification to make explicit that a certain enumeration of invariants might be invalidated when the field is updated. This allows for the specification and verification of OO designs in which in the process of updating one object, other objects with which it together implements a common purpose must be updated as well. We then generalize the inc and coop constructs by removing a restriction to enumerations of invariants. For instance, this is needed in the well-known Observer Pattern, where a Subject can have an arbitrary and dynamically changing number of Observers. A more general interpretation of invariants and accompanying proof system are provided as well. We contribute a programmer-level OO specification technique to capture layers in OO architectures, and we exploit these layers by providing a more liberal semantics of class invariants. We also provide a verification technique for the semantics. Layers are an abstraction at the architectural level in OO implementations that designate certain object structures in the design as sub-structures that are shared by other structures. An object in a higher layer is not relevant to the purpose of an object in the sub-structure. Given this intuition, an object in a higher layer is not part of the abstract view from an object in a lower layer. Therefore, the invariant of a higher layer object does not have to hold when a method of a lower-layer object is executing. Finally, we contribute a verification technique for pure methods and model fields, which are existing specification techniques for capturing an abstract view of the state in OO specifications. A method that is pure can be used as a function in predicates in class specifications. The function is axiomatized using the pre- and postcondition that are specified for the method. A model field abstracts part of the concrete state of an object into an abstract value. This too introduces an additional axiom in the underlying reasoning. The technique contributed establishes that such additional axioms do no introduce inconsistencies into the formal reasoning. It comes with heuristics that that make it amenable to automatic verification

The AutoProof Verifier: Usability by Non-Experts and on Standard Code

Formal verification tools are often developed by experts for experts; as a result, their usability by programmers with little formal methods experience may be severely limited. In this paper, we discuss this general phenomenon with reference to AutoProof: a tool that can verify the full functional correctness of object-oriented software. In particular, we present our experiences of using AutoProof in two contrasting contexts representative of non-expert usage. First, we discuss its usability by students in a graduate course on software verification, who were tasked with verifying implementations of various sorting algorithms. Second, we evaluate its usability in verifying code developed for programming assignments of an undergraduate course. The first scenario represents usability by serious non-experts; the second represents usability on "standard code", developed without full functional verification in mind. We report our experiences and lessons learnt, from which we derive some general suggestions for furthering the development of verification tools with respect to improving their usability.Comment: In Proceedings F-IDE 2015, arXiv:1508.0338

An overview of very high level software design methods

Very High Level design methods emphasize automatic transfer of requirements to formal design specifications, and/or may concentrate on automatic transformation of formal design specifications that include some semantic information of the system into machine executable form. Very high level design methods range from general domain independent methods to approaches implementable for specific applications or domains. Applying AI techniques, abstract programming methods, domain heuristics, software engineering tools, library-based programming and other methods different approaches for higher level software design are being developed. Though one finds that a given approach does not always fall exactly in any specific class, this paper provides a classification for very high level design methods including examples for each class. These methods are analyzed and compared based on their basic approaches, strengths and feasibility for future expansion toward automatic development of software systems

OpenJML: Software verification for Java 7 using JML, OpenJDK, and Eclipse

OpenJML is a tool for checking code and specifications of Java programs. We describe our experience building the tool on the foundation of JML, OpenJDK and Eclipse, as well as on many advances in specification-based software verification. The implementation demonstrates the value of integrating specification tools directly in the software development IDE and in automating as many tasks as possible. The tool, though still in progress, has now been used for several college-level courses on software specification and verification and for small-scale studies on existing Java programs.Comment: In Proceedings F-IDE 2014, arXiv:1404.578