Grady Booch

Grady Booch in 2011.

Booch in 2002

Grady Booch (born February 27, 1955) is an American software engineer. Booch is best known for developing the Unified Modeling Language with Ivar Jacobson and James Rumbaugh.

Quotes

• Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world.
  • Grady Booch (1986) Software Engineering with Ada p. 220. cited in: David J. Gilmore et al. (1994) User-Centred Requirements for Software Engineering Environments. p. 108

• The entire history of software engineering is that of the rise in levels of abstraction.
  • Grady Booch in his talk "The Limits of Software."; Cited in: Gerry Boyd (2003) "Executable UML: Diagrams for the Future." published at devx.com, February 5, 2003.

• … I pounded the doors at the local IBM sales office until a salesman took pity on me. After we chatted for a while, he handed me a Fortran [manual]. I'm sure he gave it to me thinking, "I'll never hear from this kid again." I returned the following week saying, "This is really cool. I've read the whole thing and have written a small program. Where can I find a computer?" The fellow, to my delight, found me programming time on an IBM 1130 on weekends and late-evening hours. That was my first programming experience, and I must thank that anonymous IBM salesman for launching my career. Thank you, IBM.
  • Grady Booch (2003-04-03) in interview "Grady Booch polishes his crystal ball", IBM

• The Unified Modeling Language (UML) is a general-purpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software system. It captures decisions and understanding about systems that must be constructed. It is used to understand, design, browse, configure, maintain, and control information about such systems. It is intended for use with all development methods, lifecycle stages, application domains, and media. The modeling language is intended to unify past experience about modeling techniques and to incorporate current software best practices into a standard approach. UML includes semantic concepts, notation, and guidelines. It has static, dynamic, environmental, and organizational parts. It is intended to be supported by interactive visual modeling tools that have code generators and report writers. The UML specification does not define a standard process but is intended to be useful with an iterative development process. It is intended to support most existing object-oriented development processes.
  • James Rumbaugh, Ivar Jacobson, & Booch (1999) The Unified Modeling Language Reference Manual. p. 1

• As a noun, design is the named (although sometimes unnamable) structure or behavior of a system whose presence resolves or contributes to the resolution of a force or forces on that system. A design thus represents one point in a potential decision space. A design may be singular (representing a leaf decision) or it may be collective (representing a set of other decisions).

As a verb, design is the activity of making such decisions. Given a large set of forces, a relatively malleable set of materials, and a large landscape upon which to play, the resulting decision space may be large and complex. As such, there is a science associated with design (empirical analysis can point us to optimal regions or exact points in this design space) as well as an art (within the degrees of freedom that range beyond an empirical decision; there are opportunities for elegance, beauty, simplicity, novelty, and cleverness).

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

• Grady Booch (2006) "On design" cited in: Frank Buschmann, ‎Kevlin Henney, ‎Douglas C. Schmidt (2007) Pattern-Oriented Software Architecture, On Patterns and Pattern Languages. p. 214

• The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exist.
  • Grady Booch, ‎Robert A. Maksimchuk, ‎Michael W. Engle (2007) Object-Oriented Analysis and Design with Applications Chapter 6.

• Model Driven Architecture is a style of enterprise application development and integration, based on using automated tools to build system independent models and transform them into efficient implementations.
  • Attributed to Grady Booch in: Tarek M. Sobh (2008) Advances in Computer and Information Sciences and Engineering. p. 457

• The function of good software is to make the complex appear to be simple.
  • Attributed to Booch in: Frank H. P. Fitzek et al. (2010) Qt for Symbian. p. xv

• In the early days of modern computing - the 40s, 50s and 60s - computing was a priesthood. Only a few were allowed to commune directly with the machine; all others would give their punched card offerings to the anointed, who would in turn genuflect before their card readers and perform their rituals amid the flashing of lights, the clicking of relays, and the whirring of fans and motors. If the offering was well-received, the anointed would call the communicants forward and in solemn silence hand them printed manuscripts, whose signs and symbols would be studied with fevered brow.
  • Grady Booch (2011) "The Computing Priesthood" on ibm.com/developerworks/community/blogs/gradybooch. November 14, 2011

Object-oriented design: With Applications, (1991)

Grady Booch (1991) Object-Oriented Design: with Applications; Second ed. 1994 as Object-Oriented Analysis and Design with Applications.

• A physician, a civil engineer, and a computer scientist were arguing about what was the oldest profession in the world. The physician remarked, "Well, in the Bible, it says that God created Eve from a rib taken out of Adam. This clearly required surgery, and so I can rightly claim that mine is the oldest profession in the world." The civil engineer interrupted, and said, "But even earlier in the book of Genesis, it states that God created the order of the heavens and the earth from out of the chaos. This was the first and certainly the most spectacular application of civil engineering. Therefore, fair doctor, you are wrong: mine is the oldest profession in the world." The computer scientist leaned back in her chair, smiled, and then said confidently, "Ah, but who do you think created the chaos?"
  • p. 2

• 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.
  • p. 19

• Philosophy and cognitive science have contributed to the advancement of the object model. The idea that the world could be viewed either in terms of objects or processes was a Greek innovation, and in the seventeenth century, we find Descartes observing that humans naturally apply an object-oriented view of the world. In the twentieth century, Rand expanded upon these themes in her philosophy of objectivist epistemology. More recently, Minsky has proposed a model of human intelligence in which he considers the mind to be organized as a society of otherwise mindless agents. Minsky argues that only through the cooperative behavior of these agents do we find what we call intelligence.
  • p. 34-35

• Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships.
  • p. 35

• 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.
  • p. 37

• 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.
  • p. 37

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

• Typically, a subclass augments or redefines the existing structure and behavior of its superclasses.
  • p. 56

• As Cox points out, "Without inheritance, every class would be a free-standing unit, each developed from the ground up. Different classes would bear no relationship with one another, since the developer of each provides methods in whatever manner he chooses. Any consistency across classes is the result of discipline on the part of the programmers. Inheritance makes it possible to define new software in the same way we introduce any concept to a newcomer, by comparing it with something that is already familiar."
  • p. 56: Booch is citing: Cox, B. 1986. Object-Oriented Programming An Evolutionary Approach. Reading, MA: Addison-Wesley, p. 69.

• An operation is some action one object performs upon another in order to elicit a reaction.
  • p. 80

• Ultimately, discovery and invention are both problems of classification, and classification is fundamentally a problem of finding sameness. When we classify, we seek to group things that have a common structure or exhibit a common behavior.
  • p. 133

• If an abstraction is a kind of some other abstraction, or if it is exactly equal to the sum of its components, then inheritance is a better approach
  • p. 116

• The class Dog is functionally cohesive if its semantics embrace the behavior of a dog, the whole dog, and nothing but the dog.
  • p. 124

• 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.
  • p. 141

• 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.
  • p. 142

• Every software system needs to have a simple yet powerful organizational philosophy (think of it as the software equivalent of a sound bite that describes the system's architecture)... [A] step in [the] development process is to articulate this architectural framework, so that we might have a stable foundation upon which to evolve the system's function points.
  • p. 320

• A class is a set of objects that share a common structure and a common behavior
  • p. 513

• [A class category is] a collection of classes, some of which are visible to other class categories, and others of which are hidden.
  • p 513

Object Solutions: Managing the Object-Oriented Project. (1996)

Grady Booch (1996) Object Solutions: Managing the Object-Oriented Project.

• In a quality object-oriented software system, you will find many classes that speak the language of the domain expert
  • p. 39; as cited in: Journal of Database Management. Vol 10-11. p. 33

• Good people with a good process will outperform good people with no process every time.
  • p. 188 as cited in: Stefan Bergström, ‎Lotta Råberg (2004) Adopting the Rational Unified Process: success with the RUP. p. 92

• Is object-oriented technology mature enough upon which to build indus­trial-strength systems? Absolutely. Does this technology scale? Indeed. Is it the sole technology worth considering? No way. Is there some better technology we should be using in the future? Possibly, but I am clueless as to what that might be.
  It is dangerous to make predictions, especially in a discipline that changes so rapidly, but one thing I can say with confidence is that I have seen the future, and it is object-oriented.
  • p. 277

The Limits of Software

Grady Booch (2002) "The Limits of Software". Lecture September 2002

• The entire history of software engineering is that of the rise in levels of abstraction.
  • Cited in: Gerry Boyd (2003) "Executable UML: Diagrams for the Future." published at devx.com, February 5, 2003.

• Today, we're at the beginning stages of the next level. Executable UML is the next logical, and perhaps inevitable, evolutionary step in the ever-rising level of abstraction at which programmers express software solutions. Rather than elaborate an analysis product into a design product and then write code, application developers of the future will use tools to translate abstract application constructs into executable entities. Someday soon, the idea of writing an application in Java or C++ will seem as absurd as writing an application in assembler does today. And the code generated from an Executable UML model will be as uninteresting and typically unexamined as the assembler pass of a third generation language compile is today. This shift is made possible by the confluence of four factors:
  1. The development of the Model Driven Architecture (MDA) standards by the Object Management Group (OMG)
  2. The adoption of the Precise Action Semantics for the Unified Modeling Language specification by the OMG in November of 2001
  3. 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
  4. The availability of high-quality Model Compilers and Virtual Execution Environments (VEEs) that provide "out of the box" platforms upon which Executable UML models can execute. These VEEs, which exist today in a somewhat incipient stage, will someday soon reduce low-level system architectures to near-commodity status.
  • Cited in: Gerry Boyd (2003) "Executable UML: Diagrams for the Future." published at devx.com, February 5, 2003.

The Promise The Limits The Beauty of Software (2007)

Grady Booch, IBM Fellow (2007) The Promise The Limits The Beauty of Software lecture

• How We Got Here

1910s beginning of automation

1920s beginning of expansion

1930s beginning of dependence

1940s beginning of von Neuman machines

1950s rise of the machines

1960s rise of the languages and methods

1970s death of the mainframe

1980s age of the personal computer

1990s age of the Internet and new methods

2000s retrenchment

• Sheet 43/56

• Where We Are Going

2010s age of transparency

2020s total dependence

2030s rise of the machines

• Sheet 44/56

Quotes about Grady Booch

• Being a protagonist within the Ada-scene for long Booch is one of the pioneers of object-oriented modelling. After a number of early publications in the 1980s he as presented a design methodology within an extensive textbook (Booch 1990). Although Booch conceptualizes objects similar to Rumbaugh et al. he does not distinguish between three partial models. His methodology is primarily focused on the specification of classes. In order to allow for a detailed description of classes Booch suggests various templates. The methodology not only covers conceptual design ("logical view") but includes also techniques which are clearly associated with implementation issues ("module architecture", "process architecture"). The following description of Booch’s approach is mainly focused on the logical view.
  • Ulrich Frank (2001) A Comparison of two outstanding Methodologies for Object-Oriented Design p. 22-23

• 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].
  • Martin Fowler (2004) A Brief Guide to the Standard Object Modeling Language. p. 7