Download - Lecture 5 Responsibility-Driven Design
Lecture 2 1
Lecture 5Responsibility-Driven Design
Object Oriented Analysis and Design
K268 SENG2100
Pat Browne
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