A Study Guide for Object Design

Version:	1.0	Quick Links
Author:	Nik Boyd	Study Goals
Started:	January, 2005	Study Schedule
Updated:	January, 2005	Study Questions

This guide provides a structured introduction to the book:

Rebecca Wirfs-Brock, Alan McKean. Object Design: Roles, Responsibilities, Collaborations. Addison-Wesley Publishing Co., Inc., 2003. ISBN 0-201-37943-0.

Study Group Goals

For an introduction to study groups, please see A Learning Guide to Design Patterns, by Joshua Kerievsky

For this study group on object design, we want to:

understand responsibility-driven design enough to apply it in our professional software development practice,
develop some feel for (and facility with) the various strategies of object and role discovery, responsibility discovery and assignment, and collaboration design.

Proposed Discussions

The proposed discussion order is intended to quickly introduce participants to the primary concepts and techniques. The sessions are generally organized to cover the material in a single meeting. However, some sessions may spill over across more than one week if the discussions get lively. For example, folks new to object-oriented design may want to consider an additional session between Chapters 6 and 7 to discuss design patterns. Some of the on-line catalogs in the supplementary readings can be used for this purpose.

On Design (355-374)	Session 1
Considers design in the context of problems and problem frames. Differentiates core problems from revealing problems, and their consequent (re)solution.

Design Concepts (1-38)	Session 2
Introduces the central concepts of object-oriented design: objects, roles, responsibilities, collaborations, contracts, interfaces, classes, components, patterns, architectures, and architectural styles.

Responsibility-Driven Design (39-75)	Session 3
Provides a summary overview of behaviorally oriented analysis and design, including scripts, exploratory design with CRC cards, and design refinement.

Finding Objects (77-107)	Sessions 4
Discusses candidate object and role discovery strategies.

Responsibilities (109-147)	Session 5
Discusses responsibility discovery, assignment, and assessment.

Collaborations (149-194)	Session 6
Discusses collaboration discovery and design trade-offs, including control, responsibility, patterns, simplicity, visibility, and reliability.

Control Style (195-238)	Session 7
Considers trade-offs related to control: centralization vs. delegation and the design of control centers.

Describing Collaborations (239-276)	Session 8
Provides guidance for capturing collaborations in written forms as stories.

Reliable Collaborations (277-314)	Session 9
Considers the consequences of failures and the need to establish and limit trust in collaborations, as well as how to surface these considerations in design contracts.

Flexibility (315-354)	Sessions 10
Considers the need for flexibility and extensibility in designs, esp. the need to support variations and the attendant benefits of design patterns.

Study Questions

Disclaimer: These questions can and should be augmented and / or replaced by questions raised by the participating study group members.

On Design (355-374)	Session 1
What rule(s) of thumb can we use to distinguish core problems from revealing problems and peripheral problems? What kinds of problems do we often encounter in the world that purport to need software solutions? What are the distinguishing characteristics of these problem categories? Why is it useful to categorize problems? What value do problem frames offer to software development? What are the consequences of faulty connections and latency? How might one handle a problem of incomplete information? Are there limits on how much can be (or on what makes sense to be) automated? What does it mean to characterize design as "a process of error-reduction"? What distinguishes wicked problems from other kinds of problems? What distinguishes human and animal problem solving from that of insects? What are some strategies that can help us solve difficult problems? What other kinds of problems may distract us from the core and revealing problems? How can agility and discipline be balanced during software development?

Design Concepts (1-38)	Session 2
What value do biological and mechanical metaphors offer in relation to software designs? What is a role? What differentiates a role from an object? What are role stereotypes? What value do stereotypes offer during design? What are some of the stereotypical roles objects play? What are the relationships between objects, roles, responsibilities, and collaborations? What broad categories of responsibilities are there? In what sense do collaborators have and hold each other to contracts? What distinguishes domain objects from application-specific objects? What distinguishes interfaces from classes? How do these relate to each other? What roles do classes play in an object framework? What distinguishes composition from inheritance? How does inheritance relate to the Peter Principle? How are design patterns structured? What do they accomplish through that structure? What benefits do design patterns offer to software developers? What are the trade-offs that accompany framework (re)use? What are some of the characteristic software architectural styles? What would motivate the choice of one architectural style over another?

Responsibility-Driven Design (39-75)	Session 3
Is responsibility-driven design a linear process? What are some of the initial analysis and planning activities that precede design? What kinds of descriptions result from these initial activities? What kinds of quality concerns might be discovered during analysis or during initial usage? When do you know that you're done collecting requirements (hint: this is a "trick" question)? What are the two major phases of object design? What are the activities in these two major phases? What are some useful kinds of descriptions that can emerge during analysis? What differentiates analysis from design? What results do (can) each of these activities produce? What are some of the kinds of stakeholder expectations (perspectives) that need to be balanced and satisfied by a design? Why is it useful to characterize the different kinds of stakeholders that surround a software product, esp. different kinds of users? What information about stakeholders is it useful to capture (and why)? What are three kinds of use case descriptions commonly used in the software development community? What differentiates these? What information does each kind of use case description capture? How is this information used subsequently? What information will typically be captured on CRC cards? How will that information be used? What questions are useful to ask during exploratory design? What questions are useful to ask during design refinement? What kinds of quality concerns emerge during refinement? How can these be addressed? What are hot spot cards? How are they used?

Finding Objects (77-107)	Sessions 4
What is the ultimate goal of object design (hint: see the lower side bar on pg. 78)? Why is focusing solely on nouns and objects in the real world simplistic and naïve? Can other kinds of words be used to discover objects (i.e., how can you use verbs and adjectives to discover objects)? What are some useful ways to discover objects and roles? How do we discover the themes and concerns that appear in stories? How can we determine which themes are central vs. peripheral? What are some useful candidate naming heuristics? How can names be made to fit within a set of conventions, phrases, and patterns? How can we distinguish candidate names for similar, related, and unrelated concepts? When is it important to include a model of the user(s)? How do we know when to eliminate candidates? How do candidates turn into classes? What kinds of selection criteria can be applied to making this decision?

Responsibilities (109-147)	Session 5
What are the major categories of responsibilities? What are some of the most common sources of responsibilities? What differentiates strong verbs from weak verbs? What are some of the important design qualities that can help you properly assign responsibilities to candidates? What is a paramount design concern for maintenance reasons (hint: see lower side bar on pg. 136)? What are some of the alternative ways by which an object may "know" some information? In a programming language without first-class interfaces, how would you implement an object with multiple roles? What are some of the quality checks to apply during candidate responsibility reviews?

Collaborations (149-194)	Session 6
What are some reasons for distributing responsibilities among collaborative objects? What are some key concerns for collaboration design (hints: control, trust, contracts)? What are some of the common object stereotypes? What kinds of collaborations are implied by the common stereotypes? What are some reasons for using objects instead of primitive data types? What are some consequences of applying the Law of Demeter? What are some benefits of the Law of Demeter and many other software design principles (hint: implementations depend on interfaces)?

Control Style (195-238)	Session 7
What are three control styles? What are some drawbacks to centralized control? What are some drawbacks to too much control dispersion? How can centripetal and centrifugal design forces be balanced? What are some design patterns that may help distribute control properly? What are some useful basic object-oriented design practices from which to start designs?

Describing Collaborations (239-276)	Session 8
What are the benefits of documenting object collaborations as design decisions before implementation vs. after (hint: capture and share decisions)? What are the costs associated with capturing design decisions upfront? What's "just enough" upfront design? What are some of the limitations of UML collaboration and sequence diagrams? How can these be overcome? What are some of the trade-offs between collaboration vs. sequence diagrams? Where does each better serve capturing vs. sharing design decisions? Should we even bother using diagrams to capture design decisions? When would a narrative be preferable? When are design diagrams worth retaining and maintaining (hints: hot spots, frameworks)? What are the costs associated with their upkeep?

Reliable Collaborations (277-314)	Session 9
What are four levels of criticality worth considering with respect to potential failures? What kinds of prevention and responses are appropriate for these kinds of failures? What impact do trust considerations have on collaboration design? What are the implications of trust (and its lack)? What distinguishes an exception from an error? When should lower-level exceptions be translated into higher-level exceptions? What role could (should) logging play in exception handling scenarios?

Flexibility (315-354)	Sessions 10
What are some potential drawbacks to flexible designs? What is a design hot spot? How does identifying a hot spot help accomodate variation? What are template methods and hook methods? How do they support variation? Which design patterns often play roles in flexible object-oriented designs (and why)? What role does refactoring play in flexible design development?

Supplemental Reading

The following books are recommended as supplemental reading for Object Design.

Michael Jackson. Problem Frames: Analyzing and Structuring Software Development Problems. Addison-Wesley Publishing, Inc., 2000. ISBN 0-201-59627-X.
Problems exist in the world. Software solutions exist in some machine(s). Problem frames provide a structured and systematic way to think about and describe problems (as opposed to solutions). Problem frames, context diagrams, and problem descriptions describe how a machine relates to the world, and what are the requirements that need to be fulfilled by the machine in order to solve a real world problem.

Benjamin L. Kovitz. Practical Software Requirements: A Manual of Content and Style. Manning Publications, 1998. ISBN 1-884-77759-7.
Using problem frames as a backdrop, Kovitz focuses on what needs to actually be in the text of requirements and specification documents to make them effectively understood by both developers and end users.

M.H. Halstead. Elements of Software Science. Elsevier North-Holland, Inc., 1977. ISBN 0-444-00205-7.
Halstead pioneered the field of software metrics. This treatise still serves as a useful guide for thinking about and working with fundamental software elements such as operands, operators, program length, program volume, vocabulary size, language level, effort, difficulty, and predictive error rates.

S.A. Whitmire. Object-Oriented Design Measurement. John Wiley & Sons, Inc., 1997. ISBN 0-471-13417-1.
While the title of this book indicates a focus on object-oriented designs, it also provides metrics applicable to software designs in general. It provides an excellent introduction to the elements of measurement theory, enough to generate a wide range of measurements tailored to specific needs. If you have a metrics-oriented manager or simply want more objective ways of evaluating your designs, this book is highly recommended.

K.J. Lieberherr. Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns. PWS Publishing Co., 1996. ISBN 0-534-94602-X. Adaptive programming specifies the connections between objects as loosely as possible and defers the binding of algorithms to data structures until as late as possible. The Demeter system provides tools that support adaptive programming.

A.J. Riel. Object-Oriented Design Heuristics. Addison-Wesley Publishing Co., Inc., 1996. ISBN 0-201-63385-X.
Riel provides a fairly comprehensive set of 61 heuristics for object-oriented design. Unfortunately, the examples are all written in C++. Still, many of the heuristics are worth considering and easily transfered to Java and C# development.

Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley Publishing, Inc., 1995. ISBN 0-201-42294-8.
Reveals the essential elements of object-oriented software design patterns. Combinations of these elements can be found in all extant object-oriented design patterns. An understanding of these essential elements can be used to generate new design patterns.

E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Publishing Co., Inc., 1995. ISBN 0-201-63361-2. Provides an excellent introduction to design patterns and a catalog of solutions to common design problems.

The published literature includes many on-line design patterns and pattern catalogs. The following list provides a representative sample.

The Portland Patterns Repository.
http://c2.com/ppr/titles.html http://c2.com/cgi/wiki?CategoryPattern
The Hillside Patterns Repository.
http://hillside.net/patterns/papersbibliographys.htm
Papers from the Pattern Languages of Programming (PLoP) Conference:
1994 1995 1996 1997 1998 1999
2000 2001 2002 2003 2004

The published literature also includes several papers regarding design and design metrics.

S.R. Chidamber, C.F. Kemerer. A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering v20 #6, June 1994.
N. Fenton. Software Measurement: A Necessary Scientific Basis. IEEE Transactions on Software Engineering v20 #3, March 1994.
R. Sharble, S. Cohen. The Object-Oriented Brewery: A Comparison of Two Object-Oriented Development Methods. ACM SIGSOFT Software Engineering Notes v18 #2, Apr. 1993.
L.A. Laranjeira. Software Size Estimation for Object-Oriented Systems. IEEE Transactions on Software Engineering v16 #5, May 1990.
E.J. Weyuker. Evaluating Software Complexity Measures. IEEE Transactions on Software Engineering v14 #9, September 1988.
L.H. Putnam. A General Empirical Solution to the Macro Software Sizing and Estimating Problem. IEEE Transactions on Software Engineering vSE-4 #4, July 1978.