1. Lecture 5 Responsibility-Driven Design
Object Oriented Analysis and Design
K268 SENG2100
Pat Browne 57
Lecture 2
Fact Finding

2. 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
Last accessed
Fact Finding

3. Object Analysis Candidate Objects Information Essential Behavior
Associations (not strictly part of RDD)
Responsibilities
Collaborations
Fact Finding

4. Object Design Roles, Responsibilities and Collaborations State Models
Control Architecture
Candidate Classes
Class Inheritance Hierarchies
Design Level Conversations
Fact Finding

5. What Is Responsibility-Driven Design?
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.
Fact Finding

6. 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
Fact Finding

7. an application = a set of interacting objects
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)
Fact Finding

8. Responsibility-Driven Design Process
Fact Finding

9. 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)
Fact Finding

10. 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.
Fact Finding

11. 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.
Fact Finding

12. 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
Fact Finding

13. 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?
Fact Finding

14. 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
Fact Finding

15. Look for Objects First, Then Shared 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
Fact Finding

16. Identifying Objects/Classes
Candidate classes:
tangible objects;
roles;
events;
organisational units.
Fact Finding

17. 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?"
Fact Finding

18. 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
Fact Finding

19. 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.
Fact Finding

20. 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.
Fact Finding

21. 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.
Fact Finding

22. 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.
Fact Finding

23. 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.
Fact Finding

24. 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.
Fact Finding

25. 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.
Fact Finding

26. 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
Fact Finding

27. Responsibilities Behavior for Stated at a high level
knowing
Doing e.g. calculating
deciding
Stated at a high level
Assigned to appropriate objects
Fact Finding

28. 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.”
Fact Finding

29. 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
Fact Finding

30. 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
Fact Finding

31. 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
Fact Finding

32. 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
Fact Finding

33. 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
Fact Finding

34. Summary Finding 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.
Fact Finding

35. Collaborations only exist to fulfil responsibilities.
Collaborators
A collaborator is is a class whose services are needed to fulfil a responsibility.
Collaborations only exist to fulfil responsibilities.
Fact Finding

36. 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
Fact Finding

37. 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?
Fact Finding

38. 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
Fact Finding

39. Lecture 2

40. Characteristics of Centralized Control
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
Fact Finding

41. Characteristics of Delegated Control
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
Fact Finding

42. 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
Fact Finding

43. Summary Designing 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
Fact Finding

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 .
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. Lecture 2