Your SlideShare is downloading. ×
! quot;
    Wirfs-Brock Associates   www.wirfs-brock.com                  Copyright 2006           1




  What Is Respons...
The Design Process
Design is messy and iterative
Early descriptions often are
imprecise
Deciding details too early can
con...
Head                        Designing a Horse
                                                           Speed Up
Start   ...
Responsibility-Driven Design Principles

 Maximize Abstraction
      Initially hide the distinction between data and behav...
Role Stereotypes: A tool for seeing and
            shaping object behaviors




stereotype—A conventional, formulaic, and...
Object Role Stereotypes

  Coordinator – mechanically reacts to
  events Sensor Poller




  Controller - makes decisions ...
Three Uses for Object Role Stereotypes
1. In early modeling, stereotypes help you think about the
different kinds of objec...
Pulling up a level…to compare




                                                                     !     quot;      !
...
n-tier web applications
 Layer                  Functionality                 Role               Technique

 Client       ...
A Designer’s Story: A tool for seeing what’s
                important


                                                 ...
Why tell a designer’s story?

To put your spin on what’s important
Describing the problem helps you own it
Sharing them bu...
Finding Candidates




  Wirfs-Brock Associates       www.wirfs-brock.com   Copyright 2006   23




     Guidelines for In...
Where Do We Find Objects?

Objects that support
    System behaviors
    Architecture
    Performance requirements
    Sof...
The Whole Value* Pattern

   Classes that represent meaningful quantities in your domain
          Examples: currency, cal...
What To Look For

Look for inventions that represent:
    The work your software performs
    The things your software aff...
CRC Cards: An informal design tool
         Candidate, Responsibilities, Collaborators




              !                ...
Purpose Matches Stereotype


A service provider does specific work. The type of work it does
is important to describe:
   ...
CRC Cards: An informal design tool
              Candidate, Responsibilities, Collaborators




                          ...
Naming Candidates

   Fit a name into some naming scheme
   Calendar GregorianCalendar JulianCalendar?
   ChineseCalendar?...
Refining Candidates




     Wirfs-Brock Associates      www.wirfs-brock.com   Copyright 2006   39




  Are You Looking F...
When finding Common Roles

  Blur distinctions — Identify categories. Let go of the little
  details that make objects dif...
Powerful abstractions simplify
  and give your design economy
  of expression


  Reusable roles can be identified
  and s...
Finding and Assigning Responsibilities




    Wirfs-Brock Associates   www.wirfs-brock.com   Copyright 2006   45




Wher...
The generative power of role stereotypes

Pushing on an object’s character leads to initial
responsibilities
    Ask of a ...
Technique: Seeing at different
                           abstract levels

                                               ...
To get a general picture:
                       Calendar revealed




     Wirfs-Brock Associates   www.wirfs-brock.com  ...
Deriving Responsibilities from Use Case
               Descriptions



We bridge this gap by:
    Identifying things our s...
Use Case: Report Sensor Reading

 Trigger: A reporting interval has elapsed, or a sensor has been polled
 1. Physical sens...
Use Case: Report Sensor Reading
4. System verifies that measurements are within prescribed
manufacturer’s ranges (some obj...
A Typical Life Cycle of a Domain Entity




      Wirfs-Brock Associates      www.wirfs-brock.com   Copyright 2006   59


...
Guidelines for Assigning
                   Responsibilities

 Keep behavior with related information. This
 makes objects...
Collaboration Design




    Wirfs-Brock Associates   www.wirfs-brock.com   Copyright 2006   63




         What Is A Col...
Early Collaboration Modeling



Concentrate on control, coordination, and important services
     Don’t over specify a col...
Start with rough sketches…




  Wirfs-Brock Associates   www.wirfs-brock.com   Copyright 2006   67




                 t...
by…



Showing a sequence of messages
    Label message arrows with request names
    Show arguments passed along with req...
Control Centers




 Deciding on and developing a consistent control style is one
 of the most important design decisions ...
Collaboration Styles

             Centralized                                                                            ...
Delegated Control


Some decision making and much of the action passed
off to objects surrounding a control center. Neighb...
Trust Regions: A tool for seeing where
     “defensive” behavior is or isn’t needed



                                   ...
Definition: Collaborate



2. To cooperate treasonably, as with an enemy
    occupation force




   Wirfs-Brock Associate...
Trust In A Telco Integration Application


&




                                                            &

          ...
Collaboration Cases To Consider


Collaborations between objects…
     that interface to the user and the rest of the syst...
Recovering From Exceptions




     Wirfs-Brock Associates   www.wirfs-brock.com    Copyright 2006        85




   Reason...
The Mismatch Between Use Case And
           Program Execution

A single use case step can result in thousands of
requests...
A Strategy For Handling Exceptions For
           A Key Collaboration

Brainstorm most likely exception
   cases. Name and...
Contracts




       Wirfs-Brock Associates   www.wirfs-brock.com     Copyright 2006     91




   Formal Tool:
Responsibi...
Finding and Preserving Contracts
 A class that is viewed by all its clients identically, offers a
 single contract
 A clas...
Example: A Contract For A Request That
             Spans A Trust Boundary
 Request:                       Obligations    ...
Exercise: Write a Designer’s Story

Briefly read the problem description (pages 35-7 of
the handout)
Spend 10 minutes writ...
Exercise: Define a Candidate


Now, pick one candidate stereotype it and write a brief
statement of purpose on the unlined...
Exercise: Identify Some Responsibilities


Can you identify an object with control and coordination
responsibilities for t...
Tutorial Notes for A Tour of Responsibility-Driven Design
  Tools and Techniques ............................................
designers identify the gist of what an object should accomplish. Early on, designers use
stereotypes to characterize their...
Figure 1 Rigid, tightly planned development

A design journey is filled with curves, switchbacks, and side excursions. Whe...
To address your lack of 20-20 foresight, plan pauses to reexamine, adjust, and align your work to
a changing set of condit...
Activity                  Results
Justify tradeoffs         Documentation of
                          design decisions
Di...
Tools and Techniques
Responsibility-Driven Design offers techniques for honing your thinking about how to divvy an
applica...
Here is an example for an online banking application I worked on with about 10 others. It
       was designed for a consor...
•   Stuctures and groups of objects
   •   Representations of real-world things your application needs to know something a...
Tool: Object Role Stereotypes
Role stereotypes from Responsibility-Driven Design are a fundamental way of seeing objects’
...
For example, information holders answer questions. They are responsible for maintaining certain
facts that support these q...
“knowing”. When designing a service provider asks, “What requests should it handle?” Then
restate these as responsibilitie...
Guidelines for Finding Objects
The abstractions you choose greatly affect your overall design. At the beginning, you have ...
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
A Brief Tour of Responsability Driven Design
Upcoming SlideShare
Loading in...5
×

A Brief Tour of Responsability Driven Design

991

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
991
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
38
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "A Brief Tour of Responsability Driven Design"

  1. 1. ! quot; Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 1 What Is Responsibility-Driven Design? A way to design software that… –emphasizes modeling of objects’ roles, responsibilities, and collaborations –uses informal tools and techniques –adds responsibility concepts and thinking to any process Object Design: Roles, Responsibilities and Collaborations, Rebecca Wirfs-Brock and Alan McKean, Addison-Wesley, 2003 www.wirfs-brock.com for articles & presentations Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 2 Wirfs-Brock Associates Copyright 2000. All rights reserved 1
  2. 2. The Design Process Design is messy and iterative Early descriptions often are imprecise Deciding details too early can constrain your choices Key objects and their interaction patterns have the most impact Later descriptions add details Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 3 Different Points-of-View: Different Results Choice of key design Data-Driven abstractions Responsibility-Driven influence Distribution of data and Event-Driven behavior Rule-Based Patterns of collaboration Ad-Hoc Object visibilities Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 4 Wirfs-Brock Associates Copyright 2000. All rights reserved 2
  3. 3. Head Designing a Horse Speed Up Start Body Slow Down Tail Stop Legs (4) Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 5 Designing a Horse Responsibly Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 6 Wirfs-Brock Associates Copyright 2000. All rights reserved 3
  4. 4. Responsibility-Driven Design Principles Maximize Abstraction Initially hide the distinction between data and behavior. Think of objects responsibilities for “knowing”, “doing”, and “deciding” Distribute Behavior Promote a delegated control architecture Make objects smart— have them behave intelligently, not just hold bundles of data Preserve Flexibility Design objects so interior details can be readily changed Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 7 Responsibility-Driven Design Constructs an application = a set of interacting objects an object = an implementation of one or more roles a role = a set of related responsibilities a responsibility = an obligation to perform a task or know information a collaboration = an interaction of objects or roles (or both) a contract = an agreement outlining the terms of a collaboration Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 8 Wirfs-Brock Associates Copyright 2000. All rights reserved 4
  5. 5. Role Stereotypes: A tool for seeing and shaping object behaviors stereotype—A conventional, formulaic, and oversimplified conception, opinion, or image Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 9 From Responsibility-Driven Design: Object Role Stereotypes Information holder - knows and provides information Measurement Structurer - maintains relationships between objects and information about those relationships Sensor Repository Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 10 Wirfs-Brock Associates Copyright 2000. All rights reserved 5
  6. 6. Object Role Stereotypes Coordinator – mechanically reacts to events Sensor Poller Controller - makes decisions and closely directs others’ actions Data Collector Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 11 Object Role Stereotypes Interfacer - transforms information and requests between distinct parts of a system Sensor Service provider - performs work on demand Confidence Rater Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 12 Wirfs-Brock Associates Copyright 2000. All rights reserved 6
  7. 7. Three Uses for Object Role Stereotypes 1. In early modeling, stereotypes help you think about the different kinds of objects that you need 2. You consciously blend stereotypes with a goal of making objects more responsible and intelligent –information holders that compute with their information –service providers that maintain information they need –structurers that interface to persistent stores, and derive new relationships –interfacers that transform information and hide many low-level details 3. Study a design to learn what types of roles predominate and how they interact Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 13 Layered Architecture PushButton Window PushButton Window EntryField EntryField Presentation User Interfacers Application Login Coordinator Controllers and Registration Coordination Coordinator Coordinators & Control Information-Holders, Service-Providers, and Structurers Business User A ccount User Session Information and Customer Transaction Services External Interfacers Technical OracleConnect Data Interfacers dBA SEConnect Services Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 14 Wirfs-Brock Associates Copyright 2000. All rights reserved 7
  8. 8. Pulling up a level…to compare ! quot; ! # quot; !$ & ( ) ( %' (* + , # , - quot;. .! quot; quot; /quot;) % Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 15 …and characterize Data-Driven Design Responsibility-Driven Approach Design Approach centralized control delegated control controllers coordinators inherited attributes inherited behavior many low-level fewer, higher-level messages messages lots of simplistic a few smart objects that information holders blend role stereotypes Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 16 Wirfs-Brock Associates Copyright 2000. All rights reserved 8
  9. 9. n-tier web applications Layer Functionality Role Technique Client User Interface Interfacer HTML, JavaScript Presentation Page Layout Interfacer JSP Control Command Coordinator Servlet Business Logic Business Delegate Controller POJO, Session EJB Data Access Domain Model Information JavaBean, Entity EJB Holder, Structurer Resources Database, Service Provider RDBMS, Queues, Enterprise Enterprise Services Service Bus Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 17 Exploratory Design Characteristic: Formative Goal: Produce object and interaction models Results: Class descriptions, object collaborations Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 18 Wirfs-Brock Associates Copyright 2000. All rights reserved 9
  10. 10. A Designer’s Story: A tool for seeing what’s important Designer’s story—a quickly written paragraph or two description of important ideas, what you know, and what you need to discover Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 19 Elements of a story… What is your design supposed to do? Is there something similar you can draw upon or emulate? What will make it a success? What are the most challenging parts? Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 20 Wirfs-Brock Associates Copyright 2000. All rights reserved 10
  11. 11. Why tell a designer’s story? To put your spin on what’s important Describing the problem helps you own it Sharing them builds understanding and a common vision Metaphors are hard to come by…identifying themes and key responsibilities from designer stories is one alternative Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 21 Identify Story Themes Themes are key areas of system activity and design focus Online Banking themes modeling online banking activities representing common banking functions configuring system behavior accessing scarce resources They can be broad or narrow Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 22 Wirfs-Brock Associates Copyright 2000. All rights reserved 11
  12. 12. Finding Candidates Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 23 Guidelines for Inventing Objects An object should capture one key abstraction Choose meaningful names Distinguish objects by behavior differences Fit objects into their design context Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 24 Wirfs-Brock Associates Copyright 2000. All rights reserved 12
  13. 13. Where Do We Find Objects? Objects that support System behaviors Architecture Performance requirements Software mechanisms and machinery Look for Key concepts in the domain Things that represent the software’s view of things outside the software in the “real world” Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 25 Objects from Key Concepts—Domain Objects Familiar concepts to someone who knows about the kind of problem your application is solving In the domain of banking: account, funds, currency, financial transaction In the domain of railroad shipping: consist, rail yard, shipping route Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 26 Wirfs-Brock Associates Copyright 2000. All rights reserved 13
  14. 14. The Whole Value* Pattern Classes that represent meaningful quantities in your domain Examples: currency, calendar periods, temperature, color, weight, brightness. Windspeed (NNW at 20 kph) Temperature (75 degrees Fahrenheit) Lightreading (1000 lumens) The name whole value means object do not have an identity of importance *Described by Ward Cunningham in The CHECKS Pattern Language of Information Integrity, pages 145-156 in Pattern Languages of Program Design, volume 1 see http://c2.com/ppr/checks.html#1 Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 27 Domain Objects: Entity* or Value? Entity object—An object distinguished by who it is Entities have life cycles and can change form and content, but the thread of continuity must be maintained. “You are who you are and you are unique.” Value object—An object that needn’t be unique (others can share a reference to it) It typically describes some characteristic. “I don’t care which blue crayon I use, just that I have one.” *Described by Eric Evans in Domain Driven Design, chapter on Entities Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 28 Wirfs-Brock Associates Copyright 2000. All rights reserved 14
  15. 15. What To Look For Look for inventions that represent: The work your software performs The things your software affects or is connected to The information that flows through your software Your software’s decision-making, control and coordination activities Ways to structure and manage groups of objects Representations of real world things your software needs to know something about Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 29 Characterizing Your Candidates Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 30 Wirfs-Brock Associates Copyright 2000. All rights reserved 15
  16. 16. CRC Cards: An informal design tool Candidate, Responsibilities, Collaborators ! quot; ! # # quot; $ Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 31 Explaining Purpose A candidate does and knows certain things. Briefly, say what those things are. A pattern to follow: An object is or represents a thing that knows or does certain things. And then mention one or two interesting facts about the object, perhaps a detail about what it does or who it works with. Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 32 Wirfs-Brock Associates Copyright 2000. All rights reserved 16
  17. 17. Purpose Matches Stereotype A service provider does specific work. The type of work it does is important to describe: A compiler is a program that translates source code into machine language. A RazzmaFrazzer is a converter that accurately and speedily translates Razzmas into Frazzes. As it translates, it logs statistics on how accurate the translation is and whether any information is lost. Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 33 Role Stereotypes Doing, Knowing and Deciding Stereotypes are simplified views that help you characterize the roles objects play in an application Service providers do things Interfacers translate requests and convert from one level of abstraction to another Information holders know things Controllers direct activities Coordinators delegate work Structurers manage object relations or organize large numbers of similar objects Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 34 Wirfs-Brock Associates Copyright 2000. All rights reserved 17
  18. 18. CRC Cards: An informal design tool Candidate, Responsibilities, Collaborators & % Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 35 Naming Candidates Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 36 Wirfs-Brock Associates Copyright 2000. All rights reserved 18
  19. 19. Naming Candidates Fit a name into some naming scheme Calendar GregorianCalendar JulianCalendar? ChineseCalendar? Give service providers “worker” names Service providers are “workers”, “doers”, “movers” and “shakers”: StringTokenizer, ClassLoader, and Authenticator Choose a name that suits a role Objects named “Manager” organize and pool collections of similar objects: AccountManager organizes Account objects Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 37 Naming Candidates Choose names that expand an object’s behavior AccountRecord?—facts set down in writing Account?—sounds livelier—an object that makes informed decisions on the information it represents Choose a name that lasts a lifetime A ninety-year old named “Junior”? ApplicationInitializer or ApplicationCoordinator? Include facts most relevant to its users TimerAccurateWithinPlusOrMinusTwoMilliseconds? or simply Timer? Eliminate naming conflicts by adding description Rename Properties to TransactionHistoryProperties Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 38 Wirfs-Brock Associates Copyright 2000. All rights reserved 19
  20. 20. Refining Candidates Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 39 Are You Looking For Objects, Roles, or Classes? Candidates represent important, vivid concepts, machinery and mechanisms You can think concretely, identifying concrete classes that represent things that perform some work in your application ..or more abstractly, identify abstractions that stand in for many different variations on a theme Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 40 Wirfs-Brock Associates Copyright 2000. All rights reserved 20
  21. 21. When finding Common Roles Blur distinctions — Identify categories. Let go of the little details that make objects different Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 41 Explain Key Abstractions If a role can be played by several different classes of objects, explain both the general characteristics and mention something about the others that will play this role: An AccountingService represents a single accounting transaction performed by our online banking application. Successful transactions result in updates to or queries to a customer's accounts. Specific AccountingServices communicate with the banking systems to perform the actual work. Examples of AccountingServices are FundsTransferService, MakePaymentService, and ViewAccountBalanceService. Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 42 Wirfs-Brock Associates Copyright 2000. All rights reserved 21
  22. 22. Powerful abstractions simplify and give your design economy of expression Reusable roles can be identified and shared among different classes Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 43 Keep a Candidate When You Can… Name it Define its purpose Stereotype it See it supports a particular use case See that it is an important architectural element Assign it one or two initial responsibilities Understand how others view it See how it behaves differently Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 44 Wirfs-Brock Associates Copyright 2000. All rights reserved 22
  23. 23. Finding and Assigning Responsibilities Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 45 Where Do We Find Responsibilities? By looking at various descriptions of system behavior and then modeling how a community of objects work: Object role stereotypes and purpose statements Use cases Gaps in these descriptions Other requirements, themes and stories Following “what if…then…and how” chains Relationships and dependencies between candidates Candidates’ “life events” Technical aspects of a specific software environment A design perspective on how things should work Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 46 Wirfs-Brock Associates Copyright 2000. All rights reserved 23
  24. 24. The generative power of role stereotypes Pushing on an object’s character leads to initial responsibilities Ask of a service provider, “what requests should it handle?” Turn around and state these as responsibilities for “doing” or “performing” specific services Ask what duties does an interfacer have for translating information and requests from one part of the system to another (and translating between different levels of abstraction)? What events does a controller handle and who does it direct? Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 47 How Do You State Responsibilities? A single responsibility is larger than an operation or attribute: Example: A DataCollector wraps operating system resources, such as sockets or data streams, retrieves raw data and converts it (packages it) into one or more data records from a sensing device. Responsibilities: Receive raw data from a sensor or sensor group Chunks data into individual readings Use strong descriptions. The more explicit the action, the stronger the statement. Stronger verbs: remove, merge, calculate, credit, activate Weaker verbs: organize, record, process, maintain, accept Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 48 Wirfs-Brock Associates Copyright 2000. All rights reserved 24
  25. 25. Technique: Seeing at different abstract levels We can see objects and behavior at different levels: At the conceptual level- a set of responsibilities At the specification level- set of methods that can be invoked At the implementation level- code and data Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 49 Technique: Pull of a Level Reverse engineer a class into responsibilities The Java Calendar class public final void set(int year, int month, int date) Internally, Calendar keeps track of a point in time in two ways. First, a “raw” value is This method sets the values of the year, month, and day-of-the-month fields of this maintained, which is simply a count of milliseconds since midnight, January 1, 1970 GMT, or, Calendar. in other words, a Date object. Second, the calendar keeps track of a number of fields, which are public final void set(int year, int month, int date, int hour, int minute) This method sets the the values that are specific to the Calendar type. These are values such as day of the week, day values of the year, month, day-of-the-month, hour, and minute fields of this Calendar. of the month, and month. The raw millisecond value can be calculated from the field values, or vice versa. Calendar also defines a number of symbolic constants. They represent either fields or values. For example, MONTH is a field constant. It can be passed to get() and set() to retrieve and This method sets the values of the year, month, day-of-the-month, hour, minute, and second adjust the month. AUGUST, on the other hand, represents a particular month value. Calling fields of this Calendar. get(Calendar.MONTH) could return Calendar.AUGUST. public void setFirstDayofWeek(int value) Calendar Methods This method sets the day that is considered the beginning of the week for this Calendar. This public int getFirstDayOfWeek() value should be determined by the Locale of this Calendar. For example, the first day of the week in the United States is Sunday; in France it'Monday. s This method returns the day that is considered the beginning of the week for this Calendar. This value is determined by the Locale of this Calendar. For example, the first day of the week public void setLenient(boolean lenient) in the United States is Sunday, while in France it is Monday. This method sets the leniency of this Calendar. A value of false specifies that the Calendar public abstract int getGreatestMinimum(int field) throws exceptions when questionable data is passed to it, while a value of true indicates that the Calendar makes its best guess to interpret questionable data. For example, if the Calendar is This method returns the highest minimum value for the given time field, if the field has a being lenient, a date such as March 135, 1997 is interpreted as the 135th day after March 1, range of minimum values. If the field does not have a range of minimum values, this method is 1997. equivalent to getMinimum(). public void setMinimalDaysInFirstWeek(int value) public abstract int getLeastMaximum(int field) This method sets the minimum number of days in the first week of the year. For example, a This method returns the lowest maximum value for the given time field, if the field has a value of 7 indicates the first week of the year must be a full week, while a value of 1 indicates range of maximum values. If the field does not have a range of maximum values, this method is the first week of the year can contain a single day. This value should be determined by the equivalent to getMaximum(). For example, for a GregorianCalendar, the lowest maximum Locale of this Calendar. value of DATE_OF_MONTH is 28. public final void setTime(Date date) public abstract int getMaximum(int field) This method sets the point in time that is represented by this This method returns the maximum value for the given time field. For example, for a GregorianCalendar, the maximum value of DATE_OF_MONTH is 31. Calendar. public void setTimeZone(TimeZone value) This method is used to set the time zone of this Calendar. Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 50 Wirfs-Brock Associates Copyright 2000. All rights reserved 25
  26. 26. To get a general picture: Calendar revealed Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 51 What’s Missing From Use Cases Use cases are descriptive, not prescriptive There is a gap between these descriptions and a design Use cases rarely describe aspects of Control and coordination Error recovery Visual display Timing and synchronization Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 52 Wirfs-Brock Associates Copyright 2000. All rights reserved 26
  27. 27. Deriving Responsibilities from Use Case Descriptions We bridge this gap by: Identifying things our software does and information it needs Restating these as responsibilities Breaking down large statements into smaller parts Inventing control and coordination mechanisms Designing exceptions and exception recovery Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 53 Gathering Responsibilities from Use Cases What you find depends on the level of use case details Any responsibility will have to be transformed into statements of individual objects’ responsibilities Responsibilities may be broad statements (which need to be decomposed) Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 54 Wirfs-Brock Associates Copyright 2000. All rights reserved 27
  28. 28. Use Case: Report Sensor Reading Trigger: A reporting interval has elapsed, or a sensor has been polled 1. Physical sensor transmits report, which includes: one or more raw data values, a timestamp, sensor identification. 2. System verifies physical sensor is known to system 3. System converts raw sensor data report to measurements (which include sensor id, normalized reading value, timestamp, location, confidence rating) 4. System verifies that measurements are within prescribed manufacturer’s ranges 5. System compares measurement against recent historical values and assigns each measurement a confidence rating. 6. System stores measurements Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 55 Use Case: Report Sensor Reading Trigger: A specified interval has elapsed, or the sensor has been polled (two ways to start…different set up for each case…but either way should stimulate the same processing) 1. Physical sensor transmits report, which includes:one or more raw data values, a timestamp, sensor identification. (some controlling object will have to receive the raw data and then start the action) 2. System verifies physical sensor is known to system (need to keep track of known sensors—a structurer/repository?) 3. System converts raw sensor data report to measurements (which include sensor id, normalized reading value, timestamp, location, confidence rating) (data will then have to be converted based on sensor type and manufacturer’s characteristics) Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 56 Wirfs-Brock Associates Copyright 2000. All rights reserved 28
  29. 29. Use Case: Report Sensor Reading 4. System verifies that measurements are within prescribed manufacturer’s ranges (some object will have to verify and another will have to hold onto manufacturer’s values…are these two different objects or?) 5. System compares measurement against recent historical values and assigns each measurement a confidence rating.(recent values—are they stored / cached, or both? Assuming confidence thresholds can vary based on measurement type, we’ll need different ways to determine confidence based on measurement type) 6. System stores measurements (some interface to an external data base is implied) Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 57 Responsibilities from Objects’ “life events” Some objects’ responsibilities are largely shaped by how they react to specific events Most of the work of a controller or coordinator is in response to events that they interpret When an object is born and when it leaves the scene are common places to find responsibilities for gracefully entering and leaving the scene Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 58 Wirfs-Brock Associates Copyright 2000. All rights reserved 29
  30. 30. A Typical Life Cycle of a Domain Entity Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 59 Be Opportunistic! Assigning one responsibility leads you to think… what client responsibilities will use it … and how it will be accomplished (subresponsibilities assigned to other objects in the “neighborhood”) Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 60 Wirfs-Brock Associates Copyright 2000. All rights reserved 30
  31. 31. Guidelines for Assigning Responsibilities Keep behavior with related information. This makes objects efficient Don’t make any one role too big. This makes objects understandable Distribute intelligence. This makes objects smart Keep information about one thing in one place. This reduces complexity Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 61 Options for Fulfilling a Responsibility An object can always do the work itself: A single responsibility can be implemented by one or more methods Divide any complex behavior into two parts One part that defines the sequence of major steps + helper parts that implement the steps Send messages to invoke these finer-grained helper methods Delegate part of a responsibility to one or more helper objects: Ask them to do part of the work: make a decision or perform a service Ask them relevant questions Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 62 Wirfs-Brock Associates Copyright 2000. All rights reserved 31
  32. 32. Collaboration Design Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 63 What Is A Collaboration Model? How a group of objects work together to fulfill a specific task It includes a description of objects, what each does, and how they interact We use CRC cards to record each object’s responsibilities and collaborations and sequence diagrams to show interactions Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 64 Wirfs-Brock Associates Copyright 2000. All rights reserved 32
  33. 33. Early Collaboration Modeling Concentrate on control, coordination, and important services Don’t over specify a collaboration Stop designing collaborations when you can show that your small set of objects fulfills its purpose Focus on objects you invent, not objects used from a library Ignore GUI details – Treat the buttons and list selections and entering data as the source of events (e.g. user indicates “Predict Fire Danger Rating” not “user clicks on button”) Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 65 Running a Modeling Session Ask which object receives the event? Then what happens? Stay at the same (or +-1) conceptual level If you are exploring how to handle a Sensor reporting data, don’t dive into the details of the database Follow the logic closely, think critically Are things being done in the right order? Does validating the data of a sensor reading happen before or after a Measurement is created? Do objects really know enough to perform the responsibility you are asking them to? Are you considering boundary cases? Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 66 Wirfs-Brock Associates Copyright 2000. All rights reserved 33
  34. 34. Start with rough sketches… Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 67 then get more precise… Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 68 Wirfs-Brock Associates Copyright 2000. All rights reserved 34
  35. 35. by… Showing a sequence of messages Label message arrows with request names Show arguments passed along with requests Show return values for important (unobvious) information returned Illustrate creation of key objects Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 69 Control centers and collaboration styles: Tools for shaping solutions aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl control center—a place where objects aDhfjkl aDhfjkl aDhfjkl aDhfjkl charged with controlling and coordinating reside Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 70 Wirfs-Brock Associates Copyright 2000. All rights reserved 35
  36. 36. Control Centers Deciding on and developing a consistent control style is one of the most important design decisions you can make. Not all centers the same style Handling web interactions Managing complex software processes Objects working together within a subsystem Control of external devices or external applications Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 71 Control Design Involves decisions about how to control and coordinate tasks, where to place responsibilities for making domain-specific decisions (rules), and how to manage unusual conditions (the design of exception detection and recovery) Goal: develop patterns for distributing the flow of control and sequencing of actions among collaborating objects. Make similar parts of your system be consistent Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 72 Wirfs-Brock Associates Copyright 2000. All rights reserved 36
  37. 37. Collaboration Styles Centralized Delegated aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl aDhfjkl Dispersed aDhfjkl aDhfjkl aDhfjkl Control styles range from aDhfjkl aDhfjkl centralized to fully aDhfjkl dispersed Wirfs-Brock Associates www.wirfs-brock.com aDhfjkl Copyright 2006 aDhfjkl aDhfjkl 73 Centralized Control Generally, one object (the controller) makes most of the important decisions. Tendencies with this strategy: Control logic can get overly complex Controllers can become dependent upon information holders’ contents Objects can become coupled indirectly through the actions of their controller The only interesting work is done in the controller Drawback: Changes can ripple among controlling and controlled objects Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 74 Wirfs-Brock Associates Copyright 2000. All rights reserved 37
  38. 38. Delegated Control Some decision making and much of the action passed off to objects surrounding a control center. Neighbors have significant roles: Coordinators tend to know about fewer objects than dominating controllers Messages between collaborators are higher-level Benefits: Changes typically localized and simpler Easier to divide interesting design work Copyright 2006 team Wirfs-Brock Associates www.wirfs-brock.com among a 75 Dispersed Control Spreads decision making and action among objects who individually do little, but collectively their work adds up. This can result in: Long message chains to dig information out of information holders Little or no value-added by those receiving a request Drawback: Hardwired dependencies between objects in call chain Wirfs-Brock Associates encapsulation May break www.wirfs-brock.com Copyright 2006 76 Wirfs-Brock Associates Copyright 2000. All rights reserved 38
  39. 39. Trust Regions: A tool for seeing where “defensive” behavior is or isn’t needed trust region—an area where trusted collaborations occur Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 77 Definition: Collaborate To work together, especially in a joint intellectual effort Objects or components working together toward a common goal Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 78 Wirfs-Brock Associates Copyright 2000. All rights reserved 39
  40. 40. Definition: Collaborate 2. To cooperate treasonably, as with an enemy occupation force Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 79 Implications of trust Objects at the “borders” may take on extra responsibilities Within a trust region, collaborations can be more collegial Requests can be assumed to be at the right time and contain the right information Objects deep inside a trust region can be designed to not check for well-formed or timely requests Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 80 Wirfs-Brock Associates Copyright 2000. All rights reserved 40
  41. 41. Trust In A Telco Integration Application & & # Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 81 When Using An Untrusted Collaborator If a collaborator can’t be trusted, it doesn’t mean it is inherently more unreliable. It may require extra precautions: Pass along a copy of data instead of sharing it Check on conditions after the request completes Employ alternate strategies when a request fails Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 82 Wirfs-Brock Associates Copyright 2000. All rights reserved 41
  42. 42. Collaboration Cases To Consider Collaborations between objects… that interface to the user and the rest of the system in different layers or subsystems inside your system and objects that interface to external systems you design and objects designed by someone else Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 83 Requests From Untrusted Sources The receiver is likely to check for timeliness, relevance, and correctly formed data There are degrees of trust Don’t design every object to behave defensively Redundant checks are hard to keep consistent and lead to brittle code It leads to poor performance Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 84 Wirfs-Brock Associates Copyright 2000. All rights reserved 42
  43. 43. Recovering From Exceptions Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 85 Reasons To Think About Exceptions Early, Often, Sooner And Later Usability may be affected Consider software that enables a severely disabled user to construct messages and communicate with others. Shouting “stack overflow!” or “network unavailable!” isn’t acceptable The degree to which a user can or should be involved in exception handling has profound design implications Solutions may not be obvious or “easy”. Experimentation may be required Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 86 Wirfs-Brock Associates Copyright 2000. All rights reserved 43
  44. 44. The Mismatch Between Use Case And Program Execution A single use case step can result in thousands of requests between collaborating objects, any number of which could cause numerous object exceptions There isn’t a direct correspondence between use case and program exceptions Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 87 Exceptions for Report Sensor Reading Sensor is unknown- Store data in “raw” form for potentially later processing Raw data improperly formed (bad packet)- Log error Measurement value out of expected range- Log error and do not store “suspect” measurement, signal possible physical sensor fault Historical data not available- Assign measurement low confidence Measurement value exceeds threshold for “expected value”- Assign low confidence and signal “abnormal change in reading” event Database unavailable- Attempt recovery, then signal database failure Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 88 Wirfs-Brock Associates Copyright 2000. All rights reserved 44
  45. 45. A Strategy For Handling Exceptions For A Key Collaboration Brainstorm most likely exception cases. Name and describe them first Then address how to resolve easy-to-recover from cases first Explore alternatives for tougher ones. Test for usability and feasibility Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 89 Handle Exceptions as Close to The Problem as You Can There are many different ways to “handle” an exception. It could be logged and rethrown (possibly more than once), until some object takes corrective action Who naturally might handle exceptions? External interfacers often take responsibility for handling faulty conditions in other systems The initial requestor As a fallback, pass the buck to some object who takes responsibility for controlling the action Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 90 Wirfs-Brock Associates Copyright 2000. All rights reserved 45
  46. 46. Contracts Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 91 Formal Tool: Responsibility-Driven Design Contracts “The ways in which a given client can interact with a given server are described by a contract. A contract is the list of requests that a client can make of a server. Both must fulfill the contract: the client by making only those requests the contract specifies, and the server by responding appropriately to those requests. …For each such request, a set of signatures serves as the formal specification of the contract.” —Wirfs-Brock, Wilkerson & Wiener Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 92 Wirfs-Brock Associates Copyright 2000. All rights reserved 46
  47. 47. Finding and Preserving Contracts A class that is viewed by all its clients identically, offers a single contract A class that inherits a contract should support it in its entirety. It should not cancel out any behavior A subclass may extend a superclass by adding new responsibilities and defining new contracts A class that is viewed differently by clients can offer multiple contracts. Organize responsibilities into contracts according to how they are used: Example: Specify Sensor contracts 1. Manage physical characteristics 2. Manage settings 3. Conversion of raw data into measurements 4. Know manufacture info Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 93 Technique: Specifying Detailed Contracts “Defining a precondition and a postcondition for a routine is a way to define a contract that binds the routine and its callers….” —Bertrand Meyer, Object-Oriented Software Construction Meyer’s contracts add even more details. They specify: Obligations required of the client Conditions that must be true before the service will be requested Obligations required of the service provider Conditions that must be true during and after the execution of the service Guarantees of service Defined for each method or service call Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 94 Wirfs-Brock Associates Copyright 2000. All rights reserved 47
  48. 48. Example: A Contract For A Request That Spans A Trust Boundary Request: Obligations Benefits Get Client: Sensor poller (precondition) Data request Keeps track of valid honored/poller doesn’t polling intervals and have to know comm sensor polling requests details Service provider: (preconditions) Sensor Only needs to poll active Communications assigned to comm devices, no error Channel channel recovery required Sensor is active (postcondition) Returns sensor data Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 95 Designing Responsibly Use the best tool for the job Tools for thinking, abstracting, modeling Tools for analyzing Tools for making your application flexible Learn your tool set, and practice, practice, practice The best designers never give up, they just know when to call it a day! Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 96 Wirfs-Brock Associates Copyright 2000. All rights reserved 48
  49. 49. Exercise: Write a Designer’s Story Briefly read the problem description (pages 35-7 of the handout) Spend 10 minutes writing a design story that identifies the particular challenges of the Data Collection Problem Share your story with someone seated near you (As a group, we will then identify some key themes) Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 97 Exercise: Identify Some Candidates In a 5 minute brainstorm, come up with a list candidates: What work needs to be done? (Controllers, Coordinators, Service Providers) What information flows around the software system? (Information holders, Structurers) What needs to be structured and managed? (Structurers) What real world things does the software need to be aware of?(Information holders, blends) How does it connect to other systems and external devices? (Interfacers) Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 98 Wirfs-Brock Associates Copyright 2000. All rights reserved 49
  50. 50. Exercise: Define a Candidate Now, pick one candidate stereotype it and write a brief statement of purpose on the unlined side of a CRC card Choose whether your candidate is an information holder, structurer, controller, coordinator, interfacer or service provider. You may list more than one stereotype if you think your candidate might be a “blend” Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 99 Use Case: Report Sensor Reading Actor: Physical Sensing Device Context: Either the specified reporting interval has elapsed or the sensor is being asked for its current reading… 1. Sensor transmits report, which includes: one or more raw data values, a timestamp, sensor identification. 2. System verifies physical sensor is known to system 3. System converts raw sensor data packets to measurements. 4. System verifies that measurements are within prescribed manufacturer’s ranges 5. System compares measurement against recent historical values and assigns each measurement a confidence rating. 6. System stores measurements Exceptions: 2. Sensor is unknown- Store data in “raw” form for potentially later processing Post condition: One or more measurements have been stored Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 100 Wirfs-Brock Associates Copyright 2000. All rights reserved 50
  51. 51. Exercise: Identify Some Responsibilities Can you identify an object with control and coordination responsibilities for this use case? Give it a name and list some of its responsibilities There may also be an object that represents what our system knows about the physical sensors installed in the field. What responsibilities would you give this object? Define some responsibilities of a Measurement object? What stereotype is it? Wirfs-Brock Associates www.wirfs-brock.com Copyright 2006 101 Wirfs-Brock Associates Copyright 2000. All rights reserved 51
  52. 52. Tutorial Notes for A Tour of Responsibility-Driven Design Tools and Techniques ................................................................................................................. 6 Tool: A Designer’s Story............................................................................................................ 6 Tool: Object Role Stereotypes .................................................................................................... 9 Tool: CRC Cards....................................................................................................................... 10 Guidelines for Finding Objects................................................................................................. 12 Guidelines for Finding Objects................................................................................................. 12 Guidelines for Assigning Responsibilities................................................................................ 19 Tool: Control Center Design..................................................................................................... 29 Tool: Trust Regions .................................................................................................................. 32 References................................................................................................................................. 33 Data Collection Problem OOPSLA DesignFest™ Problem..................................................... 35 The design approach known as Responsibility-Driven Design is a way of designing complex software systems using objects and component technology. Responsibility-Driven Design was conceived in 1990 as a shift from thinking about objects as data + algorithms, to thinking about objects as roles + responsibilities. The principles behind Responsibility-Driven Design were first described in an OOPSLA paper in 1989, and the book, Designing Object-Oriented Software. If you are interested in reading more about Responsibility-Driven Design, you can find several introductory articles about it on www.wirfs-brock.com, or read about the latest thinking tools and techniques in Object Design: Roles, Responsibilities, and Collaborators by Rebecca Wirfs- Brock and Alan McKean. Responsibility-driven design draws upon the experiences of a number of very successful and productive Smalltalk designers. The original concepts and motivation behind responsibility- driven design were formulated when several of us developed and taught a course on object- oriented design to Tektronix engineers in the late 1980s. These engineers were working on object-oriented projects that would be implemented in Smalltalk, C++ and other, non-object- oriented programming languages. Although we refined our initial thoughts and added several techniques to our design toolkit, but the underlying values remain. Responsibility-Driven Design emphasizes practical techniques and thinking tools. In a responsibility-based model, objects play specific roles and occupy well-known positions in the application architecture. It is a smoothly-running community of objects. Each object is accountable for a specific portion of the work. Objects collaborate in clearly-defined ways, contracting with each other to fulfill the larger goals of the application. By creating such a “community of objects,” assigning specific responsibilities to each, you build a collaborative model of your application. Responsibility-Driven Design emphasizes that objects are more than simple bundles of logic and data ... they are service-providers, information-holders, structurers, coordinators, controllers, and interfacers to the outside world. Each must know and do its part. Thinking in terms of these object role stereotypes enables you to conceive of how an object should be designed to fit in and play its part. Role stereotypes, from Responsibility-Driven Design are a fundamental way of seeing objects’ responsibilities. Think of them as “purposeful oversimplifications” that help A Tour of Responsibility-Driven Design Tutorial Notes Page 1
  53. 53. designers identify the gist of what an object should accomplish. Early on, designers use stereotypes to characterize their initial candidate objects. Later, use stereotyping to take a broader look at implemented code and discern the kind of roles various objects fulfill. Progression of Ideas 1990 1995 2005 Specifications Assumed pre-existing Create or restructure Can fit into agile and into forms that guide more traditional design development practices. Problem framing helps ask the right questions Finding objects Naïve-nouns Found in analysis, Involves modeling design and/or concept concepts and invention. formation Role stereotypes and domain objects, finding roles that may map to one or more classes Refinement Inheritance, 1990+ composition & + hotspots and designing streamlining configurable algorithms to support planned communications variations Guidelines General 1990+ Assigning Values and tradeoffs, responsibilities control style according to role stereotype, keeping objects with a narrow focus Architecture Largely ignored, 4 layer application +Control Centers, subsystems given light architecture, interfacers Trust regions. treatment to model non-oo Recovery strategies and services exception design Values Behavior is good Keep abstractions at Develop consistent (implying data focus is high level patterns of collaboration bad) Focus on behaviors Hide details inside objects Table 1: Progression of Responsibility-Driven Design Ideas Responsibilities describe what software must do to accomplish its purpose. Design work progresses from requirements definition through roughly sketched ideas and then on to more detailed descriptions and software models. At the beginning, we focus on describing our system by capturing the viewpoints of many different stakeholders. We need to consider multiple perspectives in our solutions. Responsibility-Driven Design is a clarification process. We move from initial requirements to initial descriptions and models; from initial descriptions to more detailed descriptions and models of objects; from candidate object models to detailed models of their responsibilities and patterns of collaboration. We wish to be very clear on one point: although we present object oriented development activities in a linear fashion, this is rarely how design proceeds in practice. Software design processes are highly fluid and opportunistic, even though the final results are firmly fixed in code. A Tour of Responsibility-Driven Design Tutorial Notes Page 2
  54. 54. Figure 1 Rigid, tightly planned development A design journey is filled with curves, switchbacks, and side excursions. When tracking down design solutions, you often switch among different design activities as you discover different aspects of the problem. Be opportunistic. Use a variety of tools that help gain perspective, discover information, and craft solutions. Design is fluid and malleable. Figure 2 The Responsibility-Driven path is a flexible one Ordering of activities and focus will, of necessity, change. Planning, adding new features, setting goals, characterizing the application via a prototype, creating an object model, identifying the hard problems—these are only some tasks. These tasks vary in their purpose, rigor, scope, emphasis, context, and applicable tools. With all but the simplest software, you can’t fathom what lies ahead. With so much complexity, you won’t always make optimal decisions. Progress isn’t always steady. Along the way you discover new information and constraints. Take time to breathe and smooth out these recurring wrinkles. A Tour of Responsibility-Driven Design Tutorial Notes Page 3
  55. 55. To address your lack of 20-20 foresight, plan pauses to reexamine, adjust, and align your work to a changing set of conditions. This allows you to incorporate your growing understanding into what is built. Bear in mind that design is iterative and incremental. As designers, we naturally think that software objects are the center of the software universe. However object-oriented we may be, though, many other participants and perspectives go into the conception, design, and construction of a successful application. Just like a theater production, software development involves much more than meets the eye during a performance. And although objects may take center stage for our work, it is important to recognize the impact that different perspectives and activities have on design. We break the object design process into two major phases: creating an initial design (exploratory work) and then crafting more comprehensive solutions (refinement) Activity Results Associate domain A CRC model of objects with objects, roles, execution-oriented responsibilities, and ones. collaborators Assign Sequence or responsibilities to collaboration objects. diagrams Develop initial Descriptions of collaboration model. subsystem responsibilities and collaborations Preliminary class definitions Working prototypes Table 2: Exploratory Design At some point after you’ve developed an initial exploratory design, you want to break away from designing and start coding. This could occur after a relatively short while, especially if your design is straightforward or if you are doing XP (Extreme Programming) where design-test- implement cycles are tightly integrated. Or, perhaps you want to prove part of your design by implementing a prototype before investing energy designing other parts that rely on that proof of concept being solid. Whether you take the time to polish your design a bit before coding or plan on adjusting your design during implementation, your initial design ideas will change. Most applications are too complex to “design right” the first time. Creating a workable design means revisiting initial assumptions to make sure that your design lives up to stakeholders’ expectations. It may also mean spending extra time to design a flexible solution. A Tour of Responsibility-Driven Design Tutorial Notes Page 4
  56. 56. Activity Results Justify tradeoffs Documentation of design decisions Distribute application Control styles control identified Easy-to-understand patters of decision making and delegation in the object model Revise model to make Creation of new it more maintainable, object abstractions flexible and consistent Revision of object roles, including stereotype blends Simplified, consistent interfaces and patterns of collaboration Specification of classes that realize roles Application of design patterns Document the design UML diagrams clearly describing packages, components, subsystems, classes, interaction sequences, collaborations, interfaces Code Formalize the design Contracts between system components and key classes Table 3: Design Refinement A Tour of Responsibility-Driven Design Tutorial Notes Page 5
  57. 57. Tools and Techniques Responsibility-Driven Design offers techniques for honing your thinking about how to divvy an application’s responsibilities into objects and coordinating their performance. Following are summaries of techniques that you may want to add to your designer’s toolkit. Tool: A Designer’s Story A designer’s story is a way to put your own spin on the system you are work on and a substitute for Extreme Programming’s elusive metaphor. Early on in any project I now write a design story. Originally, I used a design story as a private way to organize my thoughts. Lately, I’ve been encouraging teams to individually write design stories and then share them at the beginning of a project. This has been a good way to voice individual visions that can complement and be melded into a shared perspective. And it’s a good ice-breaker for newly formed teams or in situations where some voices dominate and others’ voices don’t get heard. Here are four reasons to write a design story: • To restate any requirements from your design perspective • To put your spin on what’s important or hard or easy or similar to what you’ve done before • Boiling it down helps you grasp the problem • To own the problem Sharing your design stories with you teammates allows you to: • Have a voice • Get others’ perspectives • Develop collective thoughts • Build mutual understanding Technique: Write a designer’s story. The technique is very simple and even those who only want to write code can bang out something if they know it will be short, sweet, to the point, and only take 15 minutes. I tend to pump out lots of words when I am put in front of a word processor. Perhaps too many. So I now prefer to write my stories by hand, especially when I intend to share them with others. This makes it more personal and it looks rough and less polished which is a good thing. Here are the basic techniques in a nutshell. Quickly write a rough story—two paragraphs or less is ideal. Write about your application’s essential characteristics: the themes. Talk about important ideas such as: • What is your application supposed to do? How will it support its users? Is it connected to a real world example that you can study or emulate? Is it similar to what you’ve done before? • What will make your application a success? What are the most challenging things to design? Tell what you know and what you need to discover. A Tour of Responsibility-Driven Design Tutorial Notes Page 6
  58. 58. Here is an example for an online banking application I worked on with about 10 others. It was designed for a consortium of South American banks. After reading the spec that the technical architect wrote after he came back from South America, I sat down and wrote a story to wrap my head around the system (after all I was the project leader and had to “own” the problem and the ensuing design). I never shared this story with my teammates and I was chatty as I wrote it in a word processor. I’ll only show an excerpt: This application provides internet access to banking services. It should be easily configured to work for different banks. A critical element in the design is the declaration of a common way to call into different backend banking systems. We will define a common set of banking transactions and a framework that will call into banking-specific code that “plugs into” the standard layer implementing the details. The rest of our software will only interface with the bank-independent service layer…At the heart of our system is the ability to rapidly configure our application to work for different backends and to put a different pretty face on each. This includes customizing screen layouts, messages and banner text. The online banking functions are fairly simple: customers register to use the online banking services, then log in and access their accounts to make payments, view account balances and transaction histories, and transfer funds…” Technique: Identifying application themes. Although you could stop after merely writing and sharing design stories, I’ve found it useful to use themes as a source of inspiration for identifying key aspects or important areas of design focus. Design themes are what I substitute when I cannot find any elusive metaphor to guide my design. The key themes I pulled from the online banking story were: • Modeling online banking activities • Representing common bank functions • Configuring system behavior • Accessing scarce resources Themes can be either broad or narrow…I find that the broader they are, the more work you have to do to drill down to an appropriate level for identifying candidate objects, but if they are too narrow, there aren’t many objects to harvest. Technique: Leveraging themes to identify key areas of activity and identify initial candidates. Once you have identified major themes, you can use them as one source of inspiration. Make educated guesses about the kinds of inventions you’ll need in your design based on the nature of your application and the things that are critical to it. I consider any candidates that I haves tot of this brief dip into the system and start up my design thinking. Consider each of these perspectives for a particular theme: • The work your system performs • Things affected by or connected to your application (other software or physical devices) • Information that flows through your software • Decision-making, control and coordination activities A Tour of Responsibility-Driven Design Tutorial Notes Page 7
  59. 59. • Stuctures and groups of objects • Representations of real-world things your application needs to know something about Although I recommend you consider each perspective when you hunt for “seed corn” candidates, if you find that a particular perspective doesn’t yield any insights, move on. For example, for the theme “online banking functions” considering the work our system performs led us to consider candidates that specifically supported performing financial transactions and queries. Things affected by our software were the accounts and backend banking transactions. Lots of information flowed through our system to accomplish these activities—information about transactions, account balances, transaction amounts, account history, payments…. Identifying candidates that support each theme is a quick brainstorming activity. Sometimes candidates leap right out when you look at a particular perspective. Often different themes and perspectives reiterate and reinforce the need for certain kinds of candidates. This is good. It builds confidence in the relevance a particular candidate has. At other times, ideas do not come so quickly and you must think more deeply to come up with potential candidates. You won’t find all important candidates in this first pass look through your system and your initial ideas will certainly change. I use this as an ice breaker for identifying objects that may play a role in the design. In a brainstorming session a team can usually work up a candidate list in a couple of hours. A Tour of Responsibility-Driven Design Tutorial Notes Page 8
  60. 60. Tool: Object Role Stereotypes Role stereotypes from Responsibility-Driven Design are a fundamental way of seeing objects’ responsibilities. Think of them as purposeful oversimplifications that help you identify the gist of an object’s responsibilities. You can use stereotyping early on to characterize your early candidate objects. Later, you can use stereotyping to characterize your design. Here is a brief description of six stereotypes: • Information holder—knows and provides information • Structurer—maintains relationships between objects and information about those relationships • Service provider—performs work and in general offers services • Controller—makes decisions and closely directs others’ actions • Coordinator—reacts to events by delegating tasks to others • Interfacer—transforms information and requests between distinct parts of a system. User interfacers translate requests from the user to the system (and vice versa). External interfacers usually “wrap” other system APIs. There are other interfacers in complex systems that serve as the “front door” to subsystems. Technique: Stereotyping a Candidate Can an object have more than one stereotype? Sure. Each candidate fits at least one stereotype. They often fit two. Common blends: service provider and information holder, interfacer and service provider, structurer and information holder. I recommend that you identify the major stereotype you want to emphasize and then check your initial ideas against your current thinking from time to time. Technique: Identifying a Candidate’s Purpose I write a purpose statement on the unlined side of a CRC (candidate-responsibilities- collaborators) card. Not surprisingly, the candidate’s purpose matches its stereotype. A candidate knows and does certain things. Briefly, say what those things are. A pattern to follow: An object is a type of think that knows or does x. And then mention one or two interesting facts about the object, perhaps a detail about what it does or who it collaborates with. You might mention one or two interesting facts about the candidate, perhaps a detail about who it works with, to provide more context: A FinancialTransaction represents a single accounting transaction performed by our online banking application. Successful transactions result in updates to a customer’s accounts. What do you do with a purpose statement? It can be recycled into a class comment, once you believe a candidate will stick around. Technique: Identifying Responsibilities Whether an object primarily “knows things”, “does things”, or “controls and decides” is based on its role stereotype. Exploring an object’s character will lead to an initial set of responsibilities. A Tour of Responsibility-Driven Design Tutorial Notes Page 9
  61. 61. For example, information holders answer questions. They are responsible for maintaining certain facts that support these questions. Rather than listing out all the “attributes” of an object, or going into details about its variables, responsibilities are a higher level view of an object. Instead of talking about a customer’s first name, last name, surname, nickname, etc…. you can state this general responsibility as “knows name and preferred ways of being addressed. When designing a service provider ask “what requests should it handle”? Then, turn around and state these as general statements for “doing” or “performing” specific services. Again, responsibilities can be written at a higher-level than a single method or operation. For example, you can talk about “compares to other dates” instead of listing out “>”, “<”, “<=”, etc. Tool: CRC Cards CRC cards were invented by Ward Cunningham and Kent Beck in the late 1980s as a way of teaching object concepts to newcomers. They were popularized by my first book, Designing Object Oriented Software, and are one technique for informally specify the role and responsibilities of an object, component or subsystem. In my most recent design book, I’ve updated my thinking on CRC cards. Initially the first C stood for Class, but now I consider it to stand for a Candidate, which may end up being a component, a class, or even an interface that is shared by multiple classes of objects or components. The R stands for responsibilities, and the second C stands for collaborators or helpers that the candidate uses to accomplish its specific tasks. On the unlined side of a CRC card is where you write a purpose statement. Not surprisingly, the candidate’s purpose matches its stereotype. A candidate knows and does certain things. Briefly say what those things are. A pattern to follow: An object (or component) represents a thing that contains certain information or performs specific work. And then mention one or two interesting facts about the candidate, perhaps a detail about what it does or who it works with. Here is a sample purpose statement: A Financial Transaction represents a single account transaction performed by our online banking application. Successful transactions result in updates to a customer’s accounts. On the lined side of the card are spaces for the candidate’s responsibilities (on the left hand side). Any objects that it uses to accomplish its tasks are listed on the right hand side of the card. Whether an object primarily “knows things” “does things” or “controls and decides” is based on its role stereotype. Exploring an object’s character will lead to an initial set of responsibilities. For example, information holders answer questions. They are responsible for maintain facts that support these questions. When assigning responsibilities to an information holder ask, “what do other objects want to ask about?” Then turn around and state these as responsibilities for A Tour of Responsibility-Driven Design Tutorial Notes Page 10
  62. 62. “knowing”. When designing a service provider asks, “What requests should it handle?” Then restate these as responsibilities for performing specific services. Below are the front and back sides of a CRC card. A Tour of Responsibility-Driven Design Tutorial Notes Page 11
  63. 63. Guidelines for Finding Objects The abstractions you choose greatly affect your overall design. At the beginning, you have more options. As you look for candidate objects, you create and invent. Each invention colors and constrains your following choices. Initially, it’s good to seek important, vivid abstractions— those that represent domain concepts, algorithms, and software mechanisms. Highlight what’s important. If you invent too many abstractions, your design can get overly complex. Not enough abstraction and you’ll end up with a sea of flat, lifeless objects. Your goal is to invent and arrange objects in a pleasing fashion. Your application will be divided into neighborhoods where clusters of objects work toward a common goal. Your design will be shaped by the number and quality of abstractions and by how well they complement one another. Composition, form, and focus are everything! Here are some guidelines to help you during your discovery and invention: Include only the most revealing and salient facts in a name. The downside of any descriptive scheme is that names can become lengthy. Don’t name every distinguishing characteristic of an object; hide details that might change or should not be known by other objects. Should people really have to care that they are using a MillisecondTimerAccurateWithinPlusOrMinusTwoMilliseconds, or will Timer suffice? Detailed design decisions should not be revealed unless they are unlikely to change and they have a known impact on the object’s users. Exposing implementation details makes them hard to change. Give service providers “worker” names. Another English language naming convention is to end job titles with “er.” Service provider objects are “workers,” “doers,” “movers,” and “shakers.” If you can find a “worker name” it can be a powerful clue to the object’s role Many Java service providers follow this “worker” naming scheme. Some examples are StringTokenizer, SystemClassLoader, and AppletViewer. If a worker-type name doesn’t sound right, another convention is to append Service to a name. In the CORBA framework, this is a common convention—for example, TransactionService, NamingService, and so on. Look for additional objects to complement an object whose name implies broad responsibilities. Sometimes a candidate represents a broad concern; sometimes its focus is more narrow. If you come across a name that implies a large set of responsibilities, check whether you’ve misnamed a candidate. It could be that your candidate should have a narrower focus. Or it might mean that you have uncovered a broad concept that needs to be expanded. Looking for objects that round out or complement a broad name can lead to a family of related concepts—and a family of related candidates. Many times we need both specific and general concepts in our design. The more generic named thing will define responsibilities that each specific candidate has in common. An object named AccountingService likely performs some accounting function. The name AccountingService isn’t specific. We cannot infer information about the kinds of A Tour of Responsibility-Driven Design Tutorial Notes Page 12

×