Lecture 2 1

Lecture 5Responsibility-Driven Design

Object Oriented Analysis and Design

K268 SENG2100

Pat Browne

Patrick.Browne@comp.dit.ie

http://www.comp.dit.ie/pbrowne/

Object Analysis• This lecture is based on “A Brief Tour of

Responsibility –Driven Design” by Rebecca J. Wirfs-Brock and Alan McKean, which was resented at OOPSLA 2002: The ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications

• http://www.wirfs-brock.com/pages/resources.html

• Last accessed 29-9-2004

Object Analysis• Candidate Objects

• Information

• Essential Behavior

• Associations (not strictly part of RDD)

• Responsibilities

• Collaborations

Object Design• Roles, Responsibilities and Collaborations

• State Models

• Control Architecture

• Candidate Classes

• Class Inheritance Hierarchies

• Design Level Conversations

What Is Responsibility-DrivenDesign?

• A way to design emphasizing behavioral modeling using objects, responsibilities and collaborations employing informal tools and techniques that enhances development processes from XP (eXtreme Programming) to RUP (Rational Unified Process) with responsibility concepts and thinking

• Described in the book Design of Object Oriented Software (DOOS) by Wirfs-Brock, Wilkerson and Wiener.

R-DD Principles

• Maximize Abstraction: Hide the distinction between data and behavior. We think of responsibilities for “knowing,” “doing,” and “deciding”

• Distribute Behavior: Make objects smart— have them behave intelligently, not just hold bundles of data. Objects should not be too lean or too fat

• Preserve Flexibility: Design objects and collaborations so they can be readily changed

R-DD 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)

Responsibility-Driven DesignProcess

RDD Summary

• Responsibility-Driven Design is a set of tools for thinking, not for documenting (that’s for the UML)

• Objects behave by knowing, doing and deciding. Behavior first. Data second

• Responsibility-Driven Design can be used in every development project

• Responsibility-Driven Design is compatible with all development methods, from the lightest (XP) to the heaviest (RUP)

Identifying Objects/classes

• In the initial stages of analysis there are various approaches for identifying objects:

• Data driven methods focus on the data encapsulated by the object and the operations performed on them.

• Process driven methods concentrate on the process encapsulated by an object.

Identifying Objects/classes

• Event driven methods focus on states encapsulated by the object and the definitions of the events causing state transitions.

• An object driven approach focuses on the extraction of the objects existing in the problem domain.

Identifying Objects/classes

• Responsibility driven methods start with identifying the responsibilities the object determined by the role of the object in carrying out the overall purpose of the system.

• RDD enables us to characterize the objects in ways that help you reason about them and their relationships

A Software ‘Story’

• Talk about important ideas:• 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 have done before?

What will make your application a success? • What are the most challenging things to

design?

Identifying Objects/Classes

• 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

Look for Objects First, ThenShared Roles

• Candidates represent important, vivid abstractions:– concepts, machinery and mechanisms

• Initially we think very concretely: We identify candidate objects that represent things that know and do and perform some work in our application

• Once we have a few candidates, we can think more abstractly. Looking at candidates, we identify the roles that these objects play and which can be shared by different kinds of objects

Identifying Objects/Classes

•Candidate classes:•tangible objects;•roles;•events;•organisational units.

Identifying Objects/Classes

•When looking a system analysts can ask some initial questions

•"What processing must this system do?"

•"What are the objects and classes involved in this system?"

•"Which objects initiate or are acted upon by operations or actions?"

Naming Candidates

• Fit a name into some naming scheme• Give service providers “worker” names. • Choose a name that suits a role.• Choose names that expand an object’s

behavior• Choose a name that lasts a lifetime• Include facts most relevant to its users• Eliminate naming conflicts by adding

description

Is Requirement Document Enough?

• 1. Object oriented systems are modeled using the objects and their relationships. The end user functionality is realized by the interaction of these objects. The objects interact by sending messages to each other. Therefore, objects, relationships and messages are important notions which characterize the object oriented systems. It is difficult to directly identify objects from the requirement documents. Objects fall in multiple categories like physical objects, roles, incidents, interactions and specifications. All this may not be easily visible in the requirement document.

Is Requirement Document Enough?

• 2. Object oriented systems manage complexity through abstraction and encapsulation. Objects encapsulate a definite behavior. The requirement documents do not correctly indicate the amount of behavior encapsulated in each objects.

• 3. Object Oriented systems tend to encourage reuse by factoring out common responsibilities into independent classes. The requirements documents fail to indicate how much factoring is possible.

Is Requirement Document Enough?

• 4. Requirements set in the beginning of the software tend to change. Therefore, the causal analysis based on systems characteristics extracted from initial requirement specification needs to be corrected. For efficient feedback we require characterizations which can be re evaluated consistently throughout the various phases of the software development cycle.

Classes in Specification

• The main technique for indentifying classes from a statement of requirement is noun analysis. Appropriate classes are frequently suggested by the nouns or noun phrases that occur within the text of a statement of requirements.

Associations

• An association is a connection between two objects that is significant for the application area.

• The relationships between objects are represented as associations between the classes of which the objects are instances.

Associations in Specification

• Verbs connect nouns and noun phrases in a statement of requirements. Verbs or verb phrases can be used to suggest likely associations (or links) between classes.

• For example:• The department is staffed by

accountants and auditors.• Each auditor is assigned one job at a

time.

class-association matrix• For many object models of moderate

size, a useful approach is to take the classes that have been identified and pair them together and consider whether an association between the two classes is of significance to the application area – does the application area need to record how instances of the two classes are connected. A thorough, but laborious, way of doing this is via a class-association matrix, where classes are paired, one with another.

Responsibilities• State responsibilities at a high level:They

are for knowing, doing, deciding, calculating…

• 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

Responsibilities• Behavior for

– knowing

– Doing e.g. calculating

– deciding

• Stated at a high level

• Assigned to appropriate objects

How Do You State Responsibilities?

• Don’t express responsibilities as too fine-grained.

• They are larger than individual attributes or operations. A single responsibility is often realized by several methods. Example: A Customer object has a name which may be comprised of a first name, surname, middle name, maiden name, and there may be aliases or nicknames. The software Customer “knows its name and preferred ways of being addressed.”

Where Do We Find Responsibilities?

• Responsibilities come from looking at many different descriptions of system behaviour and then modeling how a community of objects work

• Use cases (covered in UML)

• Other requirements

• Themes and software stories (slide 13)

• Gaps in these system descriptions

• Role stereotypes

• Relationships and dependencies between candidates

• Candidates’ “life events”

• Technical aspects of a specific software environment

• A design perspective on how things should work

Stereotypes in RDD

• Stereotypes are simplified views that help us characterize object essentials. Use them to characterize the roles objects play in an application– Service providers do things: a Mailer

– Interfacers translate requests and convert from one level of abstraction to another: Presenter and Selector

– Information holders know things: Letters, Words, Sentences

– Controllers direct activities: the Guesser

– Coordinators delegate work: the MessageBuilder

– Structurers manage object relations: Objects that manage Letters, Words, Sentences and Commands

Assigning Responsibilities

• Responsibilities should generally match a role’s stereotype. This makes roles cohesive.

• Is the responsibility one for “bridging” between neighborhoods or layers? – Use a controller or interfacer

• Is it an extremely complex behavior? Or is it prone to change? – Use a service-provider that does little else

• Does it involve complex decision-making? – Use a controller

• Does it involve many objects of the same type? – Use a structurer

Assigning Responsibilities

• Keep behaviour with related information. This makes roles efficient

• Don’t make any one role too big. This makes roles simple

• Distribute intelligence. This makes roles smart

• Keep information about one thing in one place. This makes roles safe

Make Objects Cohesive

• An object should be the sum of its responsibilities.

• Everything an object knows or does should contribute directly to its purpose

• Avoid “doing favours” that unnecessarily tie objects from different areas of the application to each other. Common favours: conversion from one object type to another, formatting, translation

• If you can imagine one object existing without another, don’t give it any responsibilities that require it to know about the other

SummaryFinding and Assigning Responsibilities

• Object responsibilities are derived from the application responsibilities expressed in many different requirements documents

• Responsibilities are distributed among the candidate objects according to the objects’ roles

• Responsibilities enable you to think about object behaviours without concern for how the objects perform them

• Responsibilities are higher lever abstractions than object methods.

Collaboration

• Collaborators• A collaborator is is a class whose

services are needed to fulfil a responsibility.

• Collaborations only exist to fulfil responsibilities.

What Drives the Collaborations?

• Behaviours described in use cases require object actions and collaborations

• The steps of a complex algorithms may be performed by different objects, each responsible for a given step

• Internal Events, such as a timer’s timeout, can start a collaboration

• External Events from outside devices and programs can set a group of objects into motion

Why Does an Object Collaborate?

• That’s not my role!

• I don’t know enough!

• It’s my job to direct others!

• I need help!

• Why should I do it, too?

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 roles fulfils its purpose

• Ignore UI details – Treat the UI as a source of events

• Decide what the scope of your thinking should be– When working at a high level, think about how

subsystems collaborate

– When studying details, limit your thinking to a small group of objects

Lecture 2 39

Characteristics of CentralizedControl

• Generally, one object (the controller) makes most of the important decisions. Decisions may be delegated, but most often the controller figures out what to do next.– 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

Characteristics of DelegatedControl

• A delegated control style passes some of the decision making and much of the action off to objects surrounding a control center. Each neighboring object has a significant role to play:– Coordinators tend to know about fewer objects than

dominating controllers

– Dialogs are higher-level

– Changes typically affect a fewer number of objects

– It is easier to divide design work among team members

Guidelines for Collaborating

• Delegate control if possible. Let collaborators be responsible

• Look for opportunities to ask for services or direct others’ actions more intelligently

• Develop control centers and collaboration patterns.

• Look for ways to make similar things work consistently

• Exploit polymorphism! It eliminates complexity• Determine regions where trusted collaborations

can occur and where extra precautions must be taken to ensure reliable collaborations

SummaryDesigning Collaborations

• Objects get things done by collaborating

• A collaborator is a “helper” object

• Collaborations have identifiable styles– Centralized … one controller

– Delegated … a few coordinators

– Dispersed … no centers of control

• Centers of control should be easy to locate

• Collaborations should follow a consistent style

Lecture 2 44

DOOS• Rebecca Wirfs-brock contributed much

to Responsibility-driven design approach. It is a simple idea, and it facilitates the transition from design to programming. It predates the Unified Modelling Language (UML).

• DOOS is a responsibility driven design method for OO development. See DOOS.doc for more detail.

Lecture 2 45

DOOS

Lecture 2 46

DOOS

Lecture 2 47

Display Screen

Cash Dispenser Deposit Drawer

Special Keypad

Cancel Key

Normal Pad

Printer Bank Card Reader

1 2 3

4 5 6

7 8 9

0 .

Lecture 2 48

ATM in DOOS• An automated teller machine (ATM) is a machine

through which bank customers can perform a number of financial transactions. The machine consists of a display screen, a bank card reader, input keys, a money dispenser slot, a deposit slot and a receipt printer. The main menu contains a list of the transactions that can be performed. These transactions include:

• deposit funds to an account

• withdraw funds from an account

• transfer funds from one account to the other

• query the balance of an account.

Lecture 2 49

ATM class• The ATM class represents the teller machine.

Its main operations are to create and initiate transactions. This class acts as a client of both the Financial Subsystem and the User Interface Subsystem.

Lecture 2 50

A DOOS ATM collaboration graph

Lecture 2 51

Financial Subsystem• The Financial Subsystem implements the

financial aspects of a customer's interaction with the ATM. Its main operations are to execute the following financial transactions; deposit(), withdraw(),transfer(), and balance() on customer accounts. There is one Financial Subsystem contract that must execute all the transactions. This subsystem acts as a client of the User Interface Subsystem.

Lecture 2 52

Financial Subsystem   The User Interface Subsystem

implements the interface between the ATM and the bank customer. The User Interface Subsystem has three contracts 1)To get numeric values from users. 2) Get users selection from menu. 3) To display messages and wait for events. This subsystem acts as a server of both the Financial Subsystem and the ATM class.

Lecture 2 53

A DOOS ATM collaboration graph

Lecture 2 54

DOOS ATM  Subsystems, which represent groups of classes, are

described as rectangles with rounded corners while rectangles represent single classes. The arrows indicate client-server relation point to server. Simi-circles represent contracts, when the arrow points to a semi-circles it indicates a contract. Numbers are used to identify the contracts, they are cross referenced in the textual description. The object that makes the request is termed the client, and the object that receives the request (and provides the service in response) is termed the server.

Lecture 2 55

DOOS ATM  The diagram shows that the Financial Subsystem, and the User Interface Subsystem are collaborators for the ATM class i.e. ATM is the client while the other two are the servers. A collaborator is a class whose services are needed to fulfil a responsibility. Collaborators are associated with the responsibilities that they help fulfil (1:M).

Lecture 2 56

DOOS ATM  A collaborator may appear in more than one class

if it helps fulfil responsibilities for several classes, so User Interface Subsystem is a collaborator for the other two. To fulfil a particular collaboration, each object takes on a different role. The object that makes the request is termed the client, and the object that receives the request (and provides the service in response) is termed the server, the Financial Subsystem is both a client and a server.

Lecture 2 57

DOOS ATM  The analyst decides that an Account class and a Transaction class are needed within the Financial Subsystem. The analyst decides that the Account class should have one contract. The contract states that the Account class could access and modify the balance. The Transaction class defines the behaviour common to all transactions, including transfer. The following is a collaboration graph representing the Financial Subsystem.

Lecture 2 58

A DOOS ATM collaboration graph

Lecture 2 59

DOOS ATM  It was stated that the Transaction class

represented common behaviour for each type of transaction, so we have subtyping. Nesting is used to show class/subsystem hierarchies. The original contract labelled 8 should still be show, it represents the Financial Subsystem's server role with respect to the ATM class.

Lecture 2 60

DOOS ATM  By convention the internal diagram of a subsystem

does not show its client role (the out going arrows), only its contracts are shown (in coming arrows), hence 8 is shown above but not Financial Subsystem's client relationship with the User Interface Subsystem. It does not matter whether one decides on Transaction or the Financial Subsystem to handle user interaction provided that the responsibility is handled by one of them.

Lecture 2 61

DOOS ATM  A class (such as Financial Subsystem)

can fulfil its own responsibilities or collaborate with other classes. Collaboration graphs represent classes, subsystems, contracts and collaboration and class hierarchies. The collaboration between objects in DOOS is done in a client-server way: one object (the client) requests a responsibility from another object (the server). A contract is a cohesive set of responsibilities which a client can request.

Lecture 2 62

DOOS ATM  The cohesion between those responsibilities

measures how closely those responsibilities are to one another. The contract must be fulfilled by the server. The ATM class (client) expects the Financial Subsystem to carry out a transaction. Within the Financial Subsystem the Transaction class has this responsibility which is inherited by its subclasses. The Account class expects Transaction and its subclass to request the operations. The word contract is not just another name for a responsibility.

Lecture 2 63

DOOS ATM  Client-Server-Contract: The collaboration

between objects in DOOS is done in a client-server way: one object (the client) requests a responsibility from another object (the server). A contract is a cohesive set of responsibilities which a client can request. The cohesion between those responsibilities measures how closely those responsibilities are to one another. The contract must be fulfilled by the server. ATM class (client) expects the Financial Subsystem to carry out a transaction. Within the Financial Subsystem the Transaction class has this responsibility which is inherited by its subclasses.

Lecture 2 64

Subsystems  Subsystem: A set of classes (and possibly other

subsystems, recursive definition) collaborating to fulfil one or more contracts. Conceptually a subsystem can be treated like a Class on a higher level. Subsystems are conceptual, but can be treated like coarse grain classes. Collaborations graphs are used to show Classes, Subsystems and the Client-Server Collaborations between them. The clients and servers for contracts are denoted. Subsystems, Contracts and Delegations are denoted on Subsystem cards.

 

Lecture 2 65

Identify Subsystems   Identifying Subsystems starts with drawing a

complete Collaborations Graph. The next guidelines have to be applied for identifying Subsystems:

  Classes in a Subsystem should collaborate to support a small and cohesive set of Responsibilities.

  Classes within a subsystem should be interdependent in some way. High coupling is still to be avoided, but here it is internal to the subsystem and the coupling should still be kept as low as possible between classes in the subsystem.

Lecture 2 66

Identify Subsystems  After identifying the Subsystems the

patterns of Collaborations have to be simplified by applying the next guidelines:

  Minimize the number of Collaborations a Class has with other Classes or Subsystems

  Minimize the number of Classes and Subsystems to which a Subsystem delegates

  Minimize the number of different Contracts supported by a Class or Subsystem

Lecture 2 67

Identify Subsystems   Subsystems are denoted on Subsystem

cards. The CRC cards have to be modified because Collaborations between Classes have become Collaborations between Classes and Subsystems.The changes in Classes, Collaborations and Contracts have to be recorded both in the Hierarchy Graphs and on the CRC cards. At this stage it is again suggested to perform a 'Walk-through' to check the design.

Lecture 2 68

Identify Subsystems   In summary subsystems can be identified

by looking for frequent and complex collaborations between strongly coupled classes

Lecture 2 69

Guidelines for identifying contracts

 Group responsibilities used by the same clients

Maximize the cohesiveness of classes

Contracts of a class should make sense together

Minimize the number of contracts

Use inheritance

The set of classes all supporting a common contract should inherit the contract from a common superclass

Lecture 2 70

Identifying Contracts  Applying the Guidelines

Start defining contract at the top of the hierarchies

Name and number each contract.

For each collaboration, determine which contract represents that collaboration

Lecture 2 71

Walk-through  A walk-through takes some coherent

piece of behaviour that the system must exhibit – like the transfer of funds between accounts – and explores (or exercises) how this behaviour can be carried out by the object model.

A scenario is a description of a sequence of actions that illustrate a piece of interesting behaviour. A ‘use case’ in UML can be considered as a generic scenario.

Lecture 2 72

DOOS ATM  Clients = Balance, Deposit, Withdraw,

Transfer, Transaction.

Servers = Account, Financial Subsystem (at analysis design stage)

 

Lecture 2 73

DOOS Diagrms  Rectangles with rounded corners=subsystems

Rectangles = classes

Nesting = class/subsystem hierarchies.

The arrows indicate client-server relation point to server.

Simi-circles = contracts, when the arrow points to a semi-circles it indicates a contract.

The numbers are the identity the contracts. They are cross referenced in the textual description.

Lecture 2 74

DOOS Protocol   The protocol of a class is the set of

message understood by that class. Protocols include details of the message semantics;

Lecture 2 75

Some comments on DOOS • The responsibility driven approach of DOOS does

not place a strong empahasis on data modelling. DOOS uses only a simple inheritance graph. The technique focuses on describing the system in terms of responsibility, which is taken on by classes. These responsibilities are used to describe collaborations between classes that are eventually formalized in terms of an architectural view. No behavioral view is used (e.g. not interaction diagrams). The notion of responsibilities is generally accecpted as being useful, and the initial class identification techniques of Wirfs-Brock are still used.

Lecture 2 76

Some comments on DOOS• One of the key appeals of the technique is

that the hiding of the data structure and the use of responsibilities carries the notion of encapsulation into the analysis and design activity. Other techniques see encapsulation more as a detailed design notion. It may be difficult to effectively describe larger systems without defining a data model.

Lecture 2 77

Lecture 2 78