Responsibility driven design
This presentation is the property of its rightful owner.
Sponsored Links
1 / 55

Responsibility Driven Design PowerPoint PPT Presentation


  • 80 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Responsibility Driven Design

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


Responsibility driven design

Responsibility Driven Design


Overview

Overview

  • 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


Exploration

Exploration

  • 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


Modeling

Modeling

  • 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

Horse

Responsibility: Carry a ridermountRidergoToDestinationdismountRiderResponsibility: Process foodprocessFood

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

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)

Person

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 room

Example CRC Cards - Room

Room


Example crc cards person

Example CRC Cards - Person

Person


Example crc cards appt

Example CRC Cards - Appt.

Appointment


Example crc cards meeting

Example CRC Cards - Meeting

Meeting (a type of Appointment)


Example crc cards schedule

Example CRC Cards - Schedule

Schedule


Domain modeling

Domain Modeling


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


Conceptual class categories

Conceptual Class Categories


Conceptual class categories1

Conceptual Class Categories…


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


Associations

Associations

  • 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.)


Finding associations

Finding Associations


Attributes

Attributes

  • 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

SystemIceberg

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

Exploration

Detailing


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’


Resources

Resources

  • 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 Cunninghamhttp://c2.com/doc/oopsla89/paper.html


  • Login