“In a quality object-oriented software system, you will find many classes that speak the language of the domain expert”

—  Grady Booch

Source: Object Solutions: Managing the Object-Oriented Project. (1996), p. 39; as cited in: Journal of Database Management. Vol 10-11. p. 33

Adopted from Wikiquote. Last update May 30, 2022. History

Help us to complete the source, original and additional information

Do you have more details about the quote "In a quality object-oriented software system, you will find many classes that speak the language of the domain expert" by Grady Booch?
Grady Booch photo
Grady Booch 35
American software engineer 1955

Related quotes

Grady Booch photo

“Whereas object-oriented analysis typically focuses upon one specific problem at a time, domain analysis seeks to identify the classes and objects that are common to all applications within a given domain, such as missile avionics systems, compilers, or accounting software.”

Grady Booch (1955) American software engineer

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

“Object-oriented domain analysis seeks to identify reusable items localized around objects e. g., classes, instances, systems of interacting objects, and kits.”

Edward V. Berard

Source: Essays on object-oriented software engineering (1993), p. 185

Ed Yourdon photo

“[Object-oriented analysis is] the challenge of understanding the problem domain and then the system's responsibilities in that light.”

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

Source: Object-oriented design (1991), p. 8-9; as cited in: Elisa Bertino, ‎Susan Urban (1994) Object-Oriented Methodologies and Systems. p. 160.

Grady Booch photo

“Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain.”

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

Grady Booch photo

“The object-oriented paradigm is useful when building software systems where there is a hierarchy defined as a ranking or ordering of abstractions.”

Grady Booch (1955) American software engineer

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

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)

“In order to better understand object-oriented methodologies in general, it helps to understand the people who make up the "object-oriented community" itself. Far from being monolithic, there is a great deal of diversity within this community. Many object-oriented people, for example, seem to focus almost entirely on programming language issues. They tend to cast all discussions in terms of the syntax and semantics of their chosen object-oriented programming language. These people find it impossible (for all intents and purposes) to discuss any software engineering activity (e. g., analysis, design, and testing) without direct mention of some specific implementation language.
Outside of producing executable "prototypes", people who emphasize programming languages seldom have well-defined techniques for analyzing their clients' problems or describing the overall architecture of the software product. A great deal of what they do is intuitive. If they happen to have a natural instinct/intuition for good analysis or good design, their efforts on small-to-medium, non-critical projects can result in respectable software solutions.”

Edward V. Berard

Source: Essays on object-oriented software engineering (1993), p. 5

“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

Grady Booch photo

“Structured design does not scale up well for extremely complex systems, and this method is largely inappropriate for use with object-based and object-oriented programming languages.”

Grady Booch (1955) American software engineer

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

Related topics