1. Zitate
  2. Autoren
  3. Rebecca Wirfs-Brock

Rebecca Wirfs-Brock Zitate

Rebecca J. Wirfs-Brock ist eine US-amerikanische Unternehmensberaterin für Objektorientierte Programmierung und objektorientiertes Design. Sie ist die Erfinderin der ersten verhaltensorientierten Herangehensweise an den Objektentwurf und hat die IT-Firma Wirfs-Brock Associates gegründet.

Rebecca Wirfs-Brock prägte 1989 mit einem Paper auf der OOPSLA, das sie mit Brian Wilkerson erstellte, die „-driven“-Begriffskategorien für objektorientierte Vorgehensweisen. Bis dahin wurden Objekte üblicherweise durch Entity-Relationship Modelle strukturiert.

Sie legte 1992 in einem Smalltalk-Artikel über Objekt-Rollen-Stereotype die Grundlagen für die heutige Vorstellung von Stereotypen in UML. Ihre Erfindung einer zweispaltigen, diskursiven Form für Use Case-Spezifikation wurde durch Larry Constantine popularisiert. Für viele der aktuellen „-driven“ Designmethoden wird RDD als Ursprung ihrer Methodik angegeben, beispielsweise für das Domain-driven Design. Eine der heute noch gebräuchlichen Techniken ist die Verwendung von Class-Responsibility-Collaboration-Karten. Wirfs-Brock hat bis Dezember 2009 eine regelmäßige Kolumne über Objektentwurf in der Zeitschrift IEEE Software geschrieben.

Wirfs-Brock studierte Informatik und Psychologie an der University of Oregon und schloss mit einem B.A. ab. Sie arbeitete 15 Jahre als Softwareentwicklerin bei der Firma Tektronix, bevor sie zu der Firma Instantiations wechselte, die von ihrem Mann Allen Wirfs-Brock gegründet wurde. Diese Firma wurde von Digitalk aufgekauft, aus der später zusammen mit Parc Place Systems die 1995 Firma ParcPlace-Digitalk wurde. Dort war sie hauptsächlich für eine Firma tätig, die Smalltalk-Anwendungen verkaufte.

Sie bekam zusammen mit Warren Dodge das U.S. Patent #4,635,049 „Apparatus for Presenting Image Information for Display Graphically“ erteilt. Wikipedia  

✵ 1953
Rebecca Wirfs-Brock: 13   Zitate 0   Gefällt mir

Rebecca Wirfs-Brock: Zitate auf Englisch

“Object-oriented programming increases the value of these metrics by managing this complexity. The most effective tool available for dealing with complexity is abstraction. Many types of abstraction can be used, but encapsulation is the main form of abstraction by which complexity is managed in object-oriented programming.
Programming in an object-oriented language, however, does not ensure that the complexity of an application will be well encapsulated. Applying good programming techniques can improve encapsulation, but the full benefit of object-oriented programming can be realized only if encapsulation is a recognized goal of the design process.”

Help us translate this quote
Rebecca Wirfs-Brock

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

“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].”

Help us translate this quote
Rebecca Wirfs-Brock

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

“Users can work with analysts and object designers to formulate and tune system requirements. People from business, analytical and object design disciplines can come together, learn from each other and generate meaningful descriptions of systems that are to be built. Each participant and each project has slightly different concerns and needs. Practical application of use cases can go a long way to improve our ability to deliver just what the customer ordered.”

Help us translate this quote
Rebecca Wirfs-Brock

About Conclusion
Designing scenarios: Making the case for a use case framework (1993)

“A subsystem is a set of classes (and possibly other subsystems) collaborating to fulfill a set of responsibilities. Although subsystems do not exist as the software executes, they are useful conceptual entities.”

Help us translate this quote
Rebecca Wirfs-Brock

Quelle: Object-oriented design: a responsibility-driven approach (1989), p. 30

“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.”

Help us translate this quote
Rebecca Wirfs-Brock

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

“Frameworks are skeletal structures of programs that must be fleshed out to build a complete application. For example, a windowing system or a simulation system can both be viewed as frameworks fleshed out by a windowed application or a simulation, respectively.”

Help us translate this quote
Rebecca Wirfs-Brock

Quelle: Object-oriented design: a responsibility-driven approach (1989), p. 13

“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.”

Help us translate this quote
Rebecca Wirfs-Brock

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

“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.”

Help us translate this quote
Rebecca Wirfs-Brock

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

“Experienced object designers explore the design space from many different angles. They refine ideas of how their system should respond while they are in the middle of building and discarding ideas about how their design should work. Getting a design to gel involves making assumptions, seeing how they play out, changing one’s mind or perspective slightly and re-iterating. Design is a difficult, involved task. It inherently is a non-linear process. Yet, we are asked to trace our design results back to system requirements. And, if we uncover some implications during design, we’d like to tune our system requirements to reflect necessary design compromises.”

Help us translate this quote
Rebecca Wirfs-Brock

Abstract
Designing scenarios: Making the case for a use case framework (1993)

“Responsibility-driven design specifies object behavior before object structure and other implementation considerations are determined. We have found that it minimizes the rework required for major design changes.”

Help us translate this quote
Rebecca Wirfs-Brock

Quelle: Object-oriented design: a responsibility-driven approach (1989), p. 74

“Frameworks are white boxes to those that make use of them. Application developers must be able to quickly understand the structure of a framework, and how to write code that will fit into the framework. Frameworks are reusable designs as well as reusable code.”

Help us translate this quote
Rebecca Wirfs-Brock

Quelle: Object-oriented design: a responsibility-driven approach (1989), p. 13

“The goal of is to improve encapsulation. It does so by viewing a program in terms of the client/server model.”

Help us translate this quote
Rebecca Wirfs-Brock

Quelle: Object-oriented design: a responsibility-driven approach (1989), p. 72

“A conceptual level view of an object design describes the key abstractions. While someone might think of key abstractions as being nothing more or nothing less than high-level descriptions of "candidate classes", I prefer to consider a conceptual design from a slightly different angle--I'm thinking about design at a slightly different level.
An object-oriented application is a set of interacting objects. Each object is an implementation of one or more roles. A role supports a set of related (cohesive) responsibilities. A responsibility is an obligation to perform a task or know certain information. And objects don't work in isolation, they collaborate with others in a community to perform the overall responsibilities of the application. So a conceptual view, at least to start, is a distillation of the key object roles and their responsibilities (stated at a fairly high level). More than likely (unless you form classification hierarchies and use inheritance and composition techniques) many candidates you initially model will map directly to a single class in some inheritance hierarchy. But I like to open up possibilities by think first of roles and responsibilities, and then as a second step towards a specification-level view, mapping these candidates to classes and interfaces.”

Help us translate this quote
Rebecca Wirfs-Brock

Rebecca Wirfs-Brock (2003) in " An Interview with Rebecca Wirfs-Brock Author of Object Design http://www.objectsbydesign.com/books/RebeccaWirfs-Brock.html" 2003-2005 Objects by Design, Inc: Answer to the question Can you clarify what you consider to be the essential elements of a "conceptual view".

Ähnliche Autoren

Helen Rowland Foto
Helen Rowland 1
US-amerikanische Journalistin
Kurt Vonnegut Foto
Kurt Vonnegut 4
US-amerikanischer Schriftsteller
Isidor Isaac Rabi Foto
Isidor Isaac Rabi 1
US-amerikanischer Physiker
Allen Ginsberg Foto
Allen Ginsberg 10
US-amerikanischer Dichter
Truman Capote Foto
Truman Capote 74
US-amerikanischer Schriftsteller
Henry Miller Foto
Henry Miller 11
US-amerikanischer Schriftsteller und Maler
Eleanor Roosevelt Foto
Eleanor Roosevelt 83
US-amerikanische Menschenrechtsaktivistin
Norman Vincent Peale Foto
Norman Vincent Peale 7
US-amerikanischer Pfarrer und Autor
Malcolm X Foto
Malcolm X 78
US-amerikanischer Führer der Bürgerrechtsbewegung
Jerome David Salinger Foto
Jerome David Salinger 6
US-amerikanischer Schriftsteller