“The key books about object-oriented graphical modeling languages appeared between 1988 and 1992. Leading figures included Grady Booch [Booch, OOAD]; Peter Coad [Coad, OOA], [Coad, OOD]; Ivar Jacobson (Objectory) [Jacobson, OOSE]; Jim Odell [Odell]; Jim Rumbaugh (OMT) [Rumbaugh, insights], [Rumbaugh, OMT]; Sally Shlaer and Steve Mellor [Shlaer and Mellor, data], [Shlaer and Mellor, states]; and Rebecca Wirfs-Brock (Responsibility Driven Design) [Wirfs-Brock].”

—  Rebecca Wirfs-Brock

Martin Fowler (2004) A Brief Guide to the Standard Object Modeling Language. p. 7

Adopted from Wikiquote. Last update June 3, 2021. History

Help us to complete the source, original and additional information

Do you have more details about the quote "The key books about object-oriented graphical modeling languages appeared between 1988 and 1992. Leading figures includ…" by Rebecca Wirfs-Brock?
Rebecca Wirfs-Brock photo
Rebecca Wirfs-Brock 13
American software engineer 1953

Related quotes

Grady Booch photo

“A proposed profile of UML—Executable UML—supports creating a complete and implementation-neutral self-contained expression of application functionality. Steven J. Mellor and Marc J. Balcer define this profile in their book Executable UML: A Foundation for Model-Driven Architecture”

Grady Booch (1955) American software engineer

The Limits of Software

“Use cases, scenarios or scripts are roughly synonymous terms for important ways to focus our design activities. I prefer the term use case (although quickly saying it three times can leave your tongue tied) because it emphasizes usage. A use case is a textual description of a sequence of interactions between an actor (roughly corresponding to an external agent or class of users) and the system we are designing. Use cases were first described by Ivar Jacobson in his book “Object Oriented Software Engineering A Use Case Driven Approach.”
Use cases have been around in various forms for quite some time. Jacobson, however, made the keen observation that use cases can be treated as refineable, extensible and even reusable specifications of system requirements. We’ve had these same goals for object designs. We know that it is harder to actually accomplish them than it is to talk about them.”

Rebecca Wirfs-Brock (1953) American software engineer

About What is a Use Case?
Designing scenarios: Making the case for a use case framework (1993)

Jack Buck photo

“Brock takes the lead, Ruthven checks him. He is … GOING! The pitch is a strike, the throw … he is there! HE DID IT! 105 for Lou Brock!”

Jack Buck (1924–2002) American sportscaster

Calling Lou Brock's single season record-breaking 105th stolen base of the 1974 season.
1970s

“Encapsulation is the key to increasing the value of such software metrics as reusability, refinability, testability, maintainability, and extensibility. Object-oriented languages provide a number of mechanisms for improving encapsulation, but it is during the design phase that the greatest leverage can be realized.
The data-driven approach to object-oriented design focuses on the structure of the data in a system. This results in the incorporation of structural information in the definitions of classes. Doing so violates encapsulation.
The responsibility-driven approach emphasizes the encapsulation of both the structure and behavior of objects. By focusing on the contractual responsibilities of a class, the designer is able to postpone implementation considerations until the implementation phase.
While responsibility-driven design is not the only technique addressing this problem, most other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.”

Rebecca Wirfs-Brock (1953) American software engineer

Source: Object-oriented design: a responsibility-driven approach (1989), p. 75: Conclusion

Ed Yourdon photo

“Designed as a companion volume to the acclaimed Object-Oriented Analysis, this book focuses on the middle part of the software lifecycle: the activity of design. It shows readers how to apply object-oriented design, and how to tailor and expand the method to suit specific organization and project needs. Readers will explore the major issues in OOD; the role of OOD in the systems lifecycle; how to use graphical notation; strategies for creating design; and hints for evaluating the efficiency of a design created with OOD. For software engineers and other users undertaking real-world systems development projects and designing overall software architecture for systems will find this reference approach to improving systems design indispensable.”

Ed Yourdon (1944–2016) American software engineer and pioneer in the software engineering methodology

Abstract.
Object-oriented design (1991)

“Like structured design, the term object-oriented design (OOD) means different things to different people. For example, OOD has been used to imply such things as”

Edward V. Berard

The design of individual objects, and/or the design of the individual methods contained in those objects
The design of an inheritance (specialization) hierarchy of objects
The design of a library of reusable objects
The process of specifying and coding of an entire object-oriented application
The term nonformal is used to describe approaches to OOD that are not well defined, step-by-step, or repeatable, such as those that emphasize the design of individual objects, specialization (inheritance) hierarchies, and libraries of objects...
Abstract
Object‐Oriented Design (2002)

“Object-oriented programming languages support encapsulation, thereby improving the ability of software to be reused, refined, tested, maintained, and extended. The full benefit of this support can only be realized if encapsulation is maximized during the design process.
We argue that design practices which take a data-driven approach fail to maximize encapsulation because they focus too quickly on the implementation of objects. We propose an alternative object-oriented design method which takes a responsibility-driven approach. We show how such an approach can increase the encapsulation by deferring implementation issues until a later stage.”

Rebecca Wirfs-Brock (1953) American software engineer

Source: Object-oriented design: a responsibility-driven approach (1989), p. 71: Abstract

Grady Booch photo

“Object-oriented design is a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design.”

Grady Booch (1955) American software engineer

Source: Object-oriented design: With Applications, (1991), p. 37

Grady Booch photo

“In object-oriented analysis, we seek to model the world by identifying the classes and objects that form the vocabulary of the problem domain, and in object-oriented design, we invent the abstractions and mechanisms that provide the behavior that this model requires.”

Grady Booch (1955) American software engineer

Source: Object-oriented design: With Applications, (1991), p. 141

Grace Hopper photo

“The Group started out by trying to design a language for stating procedures, but soon discovered that what was really required was a description of the data and a statement of the relationships between the data sets.”

Grace Hopper (1906–1992) American computer scientist and United States Navy officer

As quoted in Management and the Computer of the Future (1962) by Sloan School of Management, p. 273
Context: We must include in any language with which we hope to describe complex data-processing situations the capability for describing data. We must also include a mechanism for determining the priorities to be applied to the data. These priorities are not fixed and are indicated in many cases by the data.
Thus we must have a language and a structure that will take care of the data descriptions and priorities, as well as the operations we wish to perform. If we think seriously about these problems, we find that we cannot work with procedures alone, since they are sequential. We need to define the problem instead of the procedures. The Language Structures Group of the Codasyl Committee has been studying the structure of languages that can be used to describe data-processing problems. The Group started out by trying to design a language for stating procedures, but soon discovered that what was really required was a description of the data and a statement of the relationships between the data sets. The Group has since begun writing an algebra of processes, the background for a theory of data processing.
Clearly, we must break away from the sequential and not limit the computers. We must state definitions and provide for priorities and descriptions of data. We must state relationships, not procedures.

Related topics