Responsibility driven design
1 / 55

Responsibility Driven Design - PowerPoint PPT Presentation

  • Uploaded on

Responsibility Driven Design. Overview. Use Cases Responsibility-driven design CRC Cards. Use Cases. Use Case : a collection of related success and failure scenarios that describe an actor using a system to support a goal Note: use cases are text stories

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Responsibility Driven Design' - dara-craft

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript


  • Use Cases

  • Responsibility-driven design

  • CRC Cards

Use cases
Use Cases

  • Use Case: a collection of related success and failure scenarios that describe an actor using a system to support a goal

    • Note: use cases are text stories

  • Actor: something with behavior (e.g. person, another system, an organization)

  • Scenario: a specific sequence of (inter)actions between actors and a system

    • One particular story of using a system

Why use cases
Why Use Cases?

  • A good way to ‘keep it simple’ for both domain experts and requirements providers

  • User-centric emphasis: emphasize user goals and perspective

  • Can scale in terms of sophistication and formality

  • Typically serve as the means of capturing functional/behavioral requirements in context

Common use case formats
Common Use Case Formats

  • Brief: Terse, one-paragraph summary, usually of the main success scenario

  • Casual: Information paragraph format; multiple paragraphs covering various scenarios

  • Fully Dressed: All steps and variations written in detail

Use case guidelines
Use Case Guidelines

  • Focus on intent; keep the user-interface out (an essential style)

  • Focus on responsibility; avoid describing internal workings

  • Write terse use cases

  • ‘Drill down’ on goals (e.g. prefer ‘identify user’ as opposed to ‘login’)

  • Take an actor and actor-goal perspective

    • Focus on understanding what the actor considers a valuable result

Finding use cases
Finding Use Cases

  • Determine the system boundary

    • Software application? +hardware? +person using system? +organization?

  • Identify the primary actors

  • Identify the goals for the primary actors

  • Define use cases that satisfy the primary goals

    • Name them according to their goal

Finding use cases1
Finding Use Cases…

  • Questions to help find actors/goals

    • Who starts and stops the system?

    • Who does user and security management?

    • Who does system administration?

    • Does the system respond to “timed” event(s)

    • Are there external software systems that call upon services of the system?

Evaluating use cases
Evaluating Use Cases

  • Tests to evaluate whether a use case is properly scoped

    • The ‘boss’ test: would a boss be happy to hear that you’ve been working all day on that use case

    • The Elementary Business Process (EBP) test:‘A task performed by one person in one place at one time, in response to a business event, which adds measurable business value’

    • The size test: use cases typically contain many steps, and require 3-10 pages of text in ‘fully dressed’ form

Evaluating use cases1
Evaluating Use Cases…

  • What do you think about the following use cases:

    • Negotiate a Contract

    • Handle Returns

    • Log In

    • Move piece on Gameboard

  • Caveat: subfunction-level use cases (e.g. Pay by credit) may not meet the evaluation requirements, but are still useful for composition

Goals of oo analysis
Goals of OO Analysis

  • Encourage early exploration, yet provide structure for improving upon initial decisions

  • Provide simple, conceptual and physical tools to reason about analysis

    • It should be easy to record and modify decisions

  • Develop language-independent methods and guidelines


  • The start, analysis is exploratory

    • Looking for classes of object

    • Trying out schemes to discover the most natural and reasonable way to abstract a system

  • What behavior is the application responsible for?

  • What classes are required to model the application?

Object analysis
Object Analysis

  • Constructing and understanding a model of key objects and how they cooperate to achieve the system’s goals

  • Abstracting essential entities and inventing mechanisms

Finding objects from use cases
Finding Objects From Use Cases

  • Attempt to separate the system context from

    • Devices

    • Human roles outside the system

    • Other systems

  • Within the system context, look for

    • Things or events remembered (nouns)

    • Human roles that will be replaced by the system

    • Information about people, other systems or devices outside the system


  • Idealized

    • Helps me elaborate object roles, interactions and responses

    • Fits my style of thinking

    • Transparently supports and promotes the good things about object technology

      • Encapsulation (information hiding)

      • Abstraction

      • Re-use

    • Results are easily traceable to system requirements

Modeling approaches
Modeling Approaches

  • Data-driven: first find the data, then package it into objects with associated operations

  • Procedural: start with the computations encapsulated by the object

  • Event-driven: describe objects in terms of stimuli they handle

  • Responsibility-driven: define objects in terms of the roles they play

Modeling data driven
Modeling: Data-Driven

  • A data-driven horse: a horse in terms of its parts

    • Head

    • Tail

    • Body

    • Leg (4)

Modeling data driven1
Modeling: Data-Driven

  • Problems:

    • Internal details of object structure can easily become part of the public definition

    • Internal details may be spread across collaborators

    • Classes are likely to be less reusable because their definition reflects their structure

Modeling procedural
Modeling: Procedural

  • A procedural horse: a horse in terms of the operations it can perform

    • Walk

    • Trot

    • Canter

    • Gallop

    • Bite

    • Eat

    • Neigh

Modeling event driven
Modeling: Event-Driven

  • An event-driven horse: a horse in terms of the external events it processes

    • Mount rider

    • Dismount rider

    • Start

    • Stop

    • Change direction

    • Change speed

Modeling responsibility driven
Modeling: Responsibility-Driven

  • A responsibility-driven horse: a horse in terms of its responsibilities

    • Carry a rider

    • Run a race

    • Process hay intomanure

Modeling responsibility driven1
Modeling: Responsibility-Driven

  • Initially focus on what, not how

  • Define the public interface to an object in terms of the role(s) it will play in the problem domain

  • The interface should answer:

    • What actions is this object responsible for performing?

    • What information is the object responsible for providing?

Modeling responsibility driven2
Modeling: Responsibility-Driven

  • Strengths:

    • Improves encapsulation by initially modeling behavior, not structure

      • Avoids ‘data leaks’

    • Object interactions are in terms of services (‘would you do this for me…’)

      • Helps identify patterns of communication between objects

    • Stating general responsibilities rather than specific operations/structures helps to identify common abstractions

Modeling responsibility driven3
Modeling: Responsibility-Driven

  • Responsibility

    • A related subset of the behavior defined by an object

    • Initially identify the overall purpose, not the individual operations

    • Each responsibility may be transformed into one or more messages


Responsibility: Carry a rider mountRider goToDestination dismountRiderResponsibility: Process food processFood

Responsibilities organize what an object does or reveals

Modeling responsibility driven4
Modeling: Responsibility-Driven

  • Determining collaborations

    • Who needs the result of the knowledge?

    • If the object capable of fulfilling the responsibility itself? If not, what is needed?

    • From what other object can it acquire what it needs?

Modeling responsibility driven5
Modeling: Responsibility-Driven

  • Collaboration

    • When instances of one class make use of some or all of the functionality defined by another class

    • A request made by one object to another

  • Collaborations between objects define a contract between these objects

    • ‘Client’ can ask for results, but not specify how it gets done

    • ‘Server’ is obligated to do what was requested

Class responsibility collaborator

  • Is a technique used to discover classes, their responsibilities and collaborations required to fulfill those responsibilities

  • Is done for each use case - which is reviewed for references to nouns and verbs

  • Is usually done by using index cards (CRC Cards)

Crc cards
CRC Cards

  • Identify the object and its purpose at the top of the card

  • Underneath, identify its responsibilities and the collaborators required for that responsibility (if any)


Represents an individual within the scheduling system

Creating crc cards
Creating CRC Cards

  • Review the use case for nouns - people, places and things that will be the domain classes

  • Create an index card for each class

  • Determine the responsibilities that need to be defined on the classes by reviewing the use case for verbs or actions

  • Assign responsibilities to the appropriate class

  • Examine the responsibilities for those that cannot be accomplished solely by the assigned class

  • Determine the necessary collaborators for such responsibilities

Activity crc cards
Activity: CRC Cards

  • Generate CRC cards from the use cases for a scheduling system

Example crc cards person
Example CRC Cards - Person


Example crc cards appt
Example CRC Cards - Appt.


Example crc cards meeting
Example CRC Cards - Meeting

Meeting (a type of Appointment)

Example crc cards schedule
Example CRC Cards - Schedule


Domain model
Domain Model

  • A domain model is a visual representation of conceptual classes in a domain

    • Typically expressed using UML class diagrams at a conceptual perspective

  • It is not a visualization of software objects

    (e.g. Window, database, etc.)

  • It is not the same as a data model

Creating a domain model
Creating a Domain Model

  • Find the conceptual classes (using CRC, etc.)

  • Draw them as classes in a UML class diagram

  • Add associations & attributes

    (within the bounds of the current iteration…)

Finding conceptual classes
Finding Conceptual Classes

  • Reuse or modify existing models

    • There are published & well-crafted domain & data models for many common domains

  • Use a category list

  • Identify noun-phrases

Creating a domain model1
Creating a Domain Model

  • Find the conceptual classes (using CRC, etc.)

  • Draw them as classes in a UML class diagram

    (more on this momentarily)

  • Add associations & attributes

Creating a domain model2
Creating a Domain Model

  • Find the conceptual classes (using CRC, etc.)

  • Draw them as classes in a UML class diagram

  • Add associations & attributes


  • An association is a relationship between classes that indicates some meaningful and interesting connection

  • Usually imply knowledge of a relationship that needs to be preserved for some duration

    • i.e. what objects do we need some memory of a relationship

  • Associations in domain modeling are not statements about the software solution (e.g. data flows, foreign key relationships, instance variables, object connections, etc.)


  • An attribute is a logical data value of an object

  • Include attributes that the requirements imply a need to remember

  • Note: attributes in the domain model should preferably be data types

    • Values for which unique identity is not meaningful (i.e. value objects)

    • Typically immutable

  • Note: do not represent foreign-key attributes

Data types

Common Data Types

When to define new data types?

If it is composed of separate sections (e.g. phone number, name of person)

There are operations associated with it (e.g. social security number)

It has other attributes (e.g. promotional price)

It is a quantity with a unit (e.g. currency)

Data Types

Results of the analysis
Results of the Analysis

  • The result of the responsibility-driven analysis process is a description of

    • The domain model of objects within the system

    • The responsibilities of those objects

    • The collaborations between those objects

    • A rough idea of the object roles

Analysis guidelines
Analysis Guidelines

  • Make object behavior cohesive

    • Don’t assign too many disparate responsibilities to one object

    • Group related knowledge and behavior

  • Keep knowledge about one thing in one place

  • Distribute system intelligence

  • State responsibilities generally

Analysis guidelines1
Analysis Guidelines…

  • Distribute system intelligence

    • Avoid single ‘controller’ classes

      • Reduces most other classes to the level of data structures

    • Pros/Cons of distributed intelligence

      • - More study is required to understand control and flow of information

      • + Any single object will know about relatively fewer objects (less coupling)

      • + Changes are typically localized

      • + Relatively fewer classes needed

Analysis guidelines2
Analysis Guidelines…

  • State responsibilities generally

    • Typically allows for more maintainable/extensible systems

    • Less general:

      • An appointment knows how to check for conflicts with the schedule for a person

      • A meeting knows how to check for conflicts with the schedule for multiple people and a room

    • More general

      • An appointment knows if it has conflicts

Analysis guidelines3
Analysis Guidelines…

  • In initial analysis:

    • Develop a big picture before diving into the details

    • Get a high-level view of key objects and interactions

    • Trace through collaborations between objects to verify their ability to address the system requirements

      • Try not to be sloppy and leave gaps in the chains of collaboration

    • Focus on breadth-first elaboration over depth-first

Transformation process


Transformation Process

  • Analysis & design (ideally) proceeds through a number of phases

    • Exploration (building initial model)

    • Detailing (improving clarity, reuse and robustness)

  • In general, design is an iterative process of successively uncovering and addressing the full scope of a system



When are we done
When Are We Done?

  • When we have modeled the major objects in the system and addressed the system wide policy issues

  • When we are designing objects that are already available in existing component libraries

  • When we are dealing with language specific concerns

Be careful to avoid ‘analysis paralysis’


  • Use Cases

    • Applying UML & Patterns, Craig Larman

    • UML Distilled, Martin Fowler

  • CRC Cards

    • Designing Object-oriented Software, Rebecca Wirfs-Brock

    • OOPSLA ’89 Paper, Kent Beck & Ward Cunningham