Ian M. Holland

Contracts: specifying behavioral compositions in object-oriented systems

Behavioral compositions, groups of interdependent objects cooperating to accomplish tasks, are an important feature of object-oriented systems. This paper introduces Contracts, a new technique for specifying behavioral compositions and the obligations on participating objects. Refinement and composition of contracts allows for the creation of large grain abstractions based on behavior, orthogonal to those provided by existing class constructs. Using contracts thus provides a basis and vocabulary for Interaction-Oriented design which greatly facilitates the early identification, abstraction and reuse of patterns of behavior in programs. Contracts differ from previous work in that they capture explicitly and abstractly the behavioral dependencies amongst cooperating objects. By explicitly stating these dependencies, contract also provide an effective aid for program understanding and reuse.

Assuring good style for object-oriented programs

The language-independent Law of Demeter, which encodes the ideas of encapsulation and modularity in an easy-to-follow form for object-oriented programmers, is presented. The law was developed during the design and implementation of the Demeter system, which provides a high-level interface to class-based, object-oriented systems. Two forms of the law, the class and object forms, are described. Its motivation is to ensure that the software is as modular as possible. Principles covered by the law include coupling control, information hiding, information restriction, information localization, and structured induction. An example is given to show how the law is applied, and valid violations are identified. It is shown how to transform a method that does not satisfy the law into one that does.<<ETX>>

Object-oriented programming: an objective sense of style

We introduce a simple, programming language independent rule (known in-house as the Law of Demeter™) which encodes the ideas of encapsulation and modularity in an easy to follow form for the object-oriented programmer. You tend to get the following related benefits when you follow the Law of Demeter while minimizing simultaneously code duplication, the number of method arguments and the number of methods per class: Easier software maintenance, less coupling between your methods, better information hiding, narrower interfaces, methods which are easier to reuse, and easier correctness proofs using structural induction. We discuss two important interpretations of the Law (strong and weak) and we prove that any object-oriented program can be transformed to satisfy the Law. We express the Law in several languages which support object-oriented programming, including Flavors, Smalltalk-80, CLOS, C++ and Eiffel.

Specifying Reusable Components Using Contracts

Contracts were introduced by Helm et al. as a high level construct for explicitly specifying interactions among groups of objects. This paper describes further developments and application of the Contract construct. We show how Contracts can be used to represent classic algorithms as large grained reusable object oriented abstractions, how these algorithms can be customized through Contract refinement and how they are reused through Contract conformance. The example algorithm used throughout is the classic graph depth first traversal algorithm. This algorithm is represented as a Contract which is then refined to specify algorithms which number connected regions of graphs and which check graphs for cycles. Changes to the Contract language are introduced and we discuss some new problems resulting from the simultaneous reuse of related contracts.

Object-oriented design

The three challenges of object-oriented design are to identify the objects and classes needed to implement the software, describe the relationships between the identified objects and classes, and define the behavior of the objects by describing the function implementations of each class. To discover an initial set of objects and classes, researchers look at the noun phrases and nouns used to analyze the system and to describe the system requirements. Possible sources of objects include tangible things (cars, telemetry data, pressure sensors); roles (mother, teacher, politician); events (landing, interrupt, request); interactions (loan, meeting, intersection); people; places; organizations; devices; and locations [Booch 1991]. Walking through scenarios of system usage, focusing on the discovery of the important objects and their responsibilities, is an important technique used early in the design process [Jacobson et al. 1992; Wirfs-Brock et al. 1990]. When the important objects have been found, the details of the class relationships and object behavior are developed through a set of interconnected models that capture four dimensions of the software architecture: logical static, logical dynamic, physical static, and physical dynamic [Booch 1991]. The logical static model describes the relationships of instantiation (class membership), association, aggregation (part-of), and generalization (is-a). This is called the system object model [Coleman 1994]. The generalization relationship implies inheritance of attributes and methods. Graphical notations derived from the entity relationship notation for data modeling are frequently used to define the object model [Rumbaugh et al. 1991]. Constraints such as cardinality (for example, one-one, one-many, many-many) that are important to the design are also expressed in the object model. A textual notation derived from BackusNaur-form grammars is also used [Lieberherr 1996]. Grammars provide a more concise representation of the class structures. The logical dynamic model describes the interactions between objects. The interactions define the run-time behavior of the system in terms of a set of participating objects, an ordered sequence of messages between the objects, and a determination of the visibility of each object in the interaction. Object interaction diagrams [Booch 1991] and interaction graphs [Coleman 1994] are used to describe important interactions. These show the participating objects and the time-ordered messages between the objects. Object visibility within an interaction is expressed via visibility graphs. Object visibility determines how an object becomes part of the scope of the method sending it a message. For example, it may be a method argument, a local variable, a new object, or a part of the current object executing the

Tools for preventive software maintenance

Tools for preventive maintenance of software which is written following the object-oriented paradigm are discussed. A set of guidelines, called the Law of Demeter is described, and its implications for software maintenance are discussed (K.J. Lieberherr, I. Holland, 1989). The advantages of grammar-based object-oriented design and programming for software maintenance are discussed. Two kinds of grammar-based maintenance tool are studied: class evolution tools, especially an automatic class parameterization tool and growth plan tools with applications to software maintenance planning and regression testing.<<ETX>>