A program verifier is a complex system that uses compiler technology, program semantics, property inference, verification-condition generation, automatic decision procedures, and a user interface. This paper describes the architecture of a state-of-the-art program verifier for object-oriented programs.

No abstract

Previousresearchhasdocumentedthefragmentednatureofsoftwaredevelopment work.Toexplainthisin moredetail,weanalyzedsoftwaredevelopers'day-to-day informationneeds.Weobservedseventeendevelopersat alargesoftwarecompanyandtranscribedtheiractivities in -minute sessions. We analyzed these logs for the informationthatdeveloperssought,thesourcesthatthey used,andthesituationsthatpreventedinformationfrom being acquired.Weidentifiedtwenty-oneinformation typesandcatalogedtheoutcomeandsourcewheneach type of information was sought. The most frequently soughtinformationincludedawarenessaboutartifacts and coworkers. The most often deferred searches includedknowledgeaboutdesignandprogrambehavior, suchaswhycodewaswrittenaparticularway,whata programwassupposedtodo,andthecauseofaprogram state. Developers often had to defer tasks because the onlysourceofknowledgewasunavailablecoworkers.

Architectures for software use rich abstractions and idioms to describe system components, the nature of interactions among the components, and the patterns that guide the composition of components into systems. These abstractions are higher level than the elements usually supported by programming languages and tools. They capture packaging and interaction issues as well as computational functionality. Well-established (if informal) patterns guide architectural design of systems. We sketch a model for defining architectures and present an implementation of the basic level of that model. Our purpose is to support the abstractions used in practice by software designers. The implementation provides a testbed for experiments with a variety of system construction mechanisms. It distinguishes among different types of components and different ways these components can interact. It supports abstract interactions such as data flow and scheduling on the same footing as simple procedure call. It can express and check appropriate compatibility restrlctions and configuration constraints. It accepts existing code as components, incurring no runtime overhead after initialization. It allows easy incorporation of specifications and associated analysis tools developed elsewhere. The implementation provides a base for extending the notation and validating the model.

An object invariant defines what it means for an object's data to be in a consistent state. Object invariants are central to the design and correctness of objectoriented programs. This paper defines a programming methodology for using object invariants. The methodology, which enriches a program's state space to express when each object invariant holds, deals with owned object components, ownership transfer, and subclassing, and is expressive enough to allow many interesting object-oriented programs to be specified and verified. Lending itself to sound modular verification, the methodology also provides a solution to the problem of determining what state a method is allowed to modify.