cs2340: ResponsibilityDriven Design

1
cs2340 Responsibility-Driven Design

• Spring 2007

Several slides are adapted from Rebecca
Wirfs-Brock and Associates
2
Announcement

• Wrong M1 code on site
• Only 1 submission
• Submit even late
• Will be auto marked late after 11PM

3
From Analysis to Design

• Refine Domain Objects with Roles and
  Responsibilities
• Create Architecture
• Add Application Objects
• Add Utility Objects
• Refine Collaborations
• Refine Object Contracts
• Design Exception Handling Mechanisms

4
Class Exercise Part I

• Arbor 2000 Analysis

5
Candidate Classes
6
Goal of RDD
To move from thinking about objects as data
algorithms to thinking about objects as roles
responsibilities
7
Lets Design a Horse!!
Data-Driven Procedural Event-Driven Responsibility
-Driven
8
Responsibility-Driven Design Principles

• Maximize Abstraction
• Initially hide the distinction between data and
  behavior.
• Think of objects responsibilities for knowing,
  doing,and deciding
• Distribute Behavior
• Promote a delegated control architecture
• Make objects smart have them behave
  intelligently, not just hold bundles of data
• Preserve Flexibility
• Design objects so interior details can be readily
  changed

9
RDD 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)
• a contract an agreement outlining the terms of
  a collaboration

10
Two Ways to Think About Roles

• Primary - Responsibilities that make an object
  unique
• Secondary Responsibilities that allow an object
  to fit into the community of cooperating objects.

11
Role Stereotypes

• Controller (direct activities)
• Coordinator (delegates work)
• Structurers (maintain relationships)
• Information Holder (keep facts)
• Service Provider (perform operation)
• Interfacer (support internal/external
  communication)

12
Stereotype Examples

• ATM Machine SessionController (Controller)
• Word Processor FontManager (Coordinator)
• File System Folder (Structurer)
• Pay System Employee (Information Holder)
• Pay System PayReport (Service Provider)
• ATM Machine CashDispenser (Interfacer)

13
More on Roles

• Represent how we view the object from outside
  looking in
• Dynamic during early design
• Use to what-if?
• active vs. passive?
• too many / too few responsibilities?
• too much control?
• Like slots (object substitution)

14
Finding Responsibilities

• Object role stereotypes and purpose statements
• Use cases / Scenarios
• Gaps in these descriptions
• Other requirements, themes and stories
• Following what ifthenand how chains
• Relationships and dependencies between candidates
• Candidates life events
• Technical aspects of a specific software
  environment
• A design perspective on how things should work

15
Use Roles to Generate Responsibilities

• Pushing on an objects character leads to initial
  responsibilities
• Ask of a service provider, what requests should
  it handle? Turn around and state these as
  responsibilities for doing or performing
  specific services
• Ask what duties does an interfacer have for
  translating information and requests from one
  part of the system to another (and translating
  between different levels of abstraction)?
• What events does a controller handle and who does
  it direct?

16
Stating Responsibilities

• A single responsibility is larger than an
  operation or attribute
• Example A DataCollector wraps operating system
  resources, such as sockets or data streams,
  retrieves raw data and converts it (packages it)
  into one or more data records from a sensing
  device.
• Responsibilities Receive raw data from a sensor
  or sensor group Chunks data into individual
  readings
• 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

17
Technique Seeing at differentabstract levels

• We can see objects and behavior at different
  levels
• At the conceptual (domain) level- a set of
  responsibilities
• At the specification level- set of methods that
  can be invoked
• At the implementation level- code and data

18
Class Exercise Part 2

• Arbor 2000 roles/responsibilities

19
Arbor 2000
20
From Analysis to Design

• Refine Domain Objects with Roles and
  Responsibilities
• Create Architecture
• Add Application Objects
• Add Utility Objects
• Refine Collaborations
• Refine Object Contracts
• Design Exception Handling Mechanisms

21
Software Architecture

• A part of the overall Systems Architecture
• A software architecture for a program or
  computing system consists of the structure or
  structures of that system, which comprise
  elements, the externally visible properties of
  those elements, and the relationships among them
  Bass 03.
• The quality attributes of a software system, such
  as performance, modifiability, and security, are
  bound up in its software architecture. A system
  with the wrong architecture will be a failure.
• Software Engineering Institute (SEI)

22
Architectural Views

• A view is a representation of a set of system
  elements and the relations associated with them.
  Views are representations of the many system
  structures present simultaneously in software
  systems.

23
Standard Views

• Conceptual / Logical
• Process
• Physical
• Module
• User Interaction
• Security
• Performance

24
Architectural Styles

• A style is a specialization of element types
  (e.g., client, layer) and relationship types
  (e.g., is part of, request-reply connection,
  is allowed to use), along with any restrictions
  (e.g., clients interact with servers but not
  each other or all the software comprises layers
  arranged in a stack such that each layer can only
  use software in the next lower layer).

25
Common Architectural Styles

• Client Server (thin/fat)
• n-tier
• Layered
• Implicit Invocation/Event-Driven
• Blackboard/Shared Memory
• Pipe and Filter
• Model View Controller

26
Layered Architecture Examples
27
Control Styles

• Centralized
• Dispersed
• Delegated

28
Architectural Evaluation (Validation)

• How do we know if we have a good architecture?
• SAAM (Software Architecture Analysis Method)
• ATAM (Architectural Tradeoff Analysis Method)

29
Class Exercise 3

• Arbor 2000 Architecture Conceptual, Process,
  Physical

30
(No Transcript)
31

32
From Analysis to Design

• Refine Domain Objects with Roles and
  Responsibilities
• Create Architecture
• Add Application Objects
• Add Utility Objects
• Refine Collaborations
• Refine Object Contracts
• Design Exception Handling Mechanisms

33
Application Objects

• Domain Objects are familiar to the domain of
  study, recognizable to customer/user.
• Application Objects are familiar to developers
  (UI, DB, Drivers, etc.)
• Utility Objects are familiar to implementers
  (Data Structures, Algorithms)

34
Class Exercise

• Add Application and Utility Classes
• Create UML Class Diagram

35

36

37
From Analysis to Design

• Refine Domain Objects with Roles and
  Responsibilities
• Create Architecture
• Add Application Objects
• Add Utility Objects
• Refine Collaborations
• Refine Object Contracts
• Design Exception Handling Mechanisms

38
Collaboration

• Trusted and Untrusted

39
Untrusted Collaborations

• If a collaborator cant be trusted, it doesnt
  mean it is inherently more unreliable. It may
  require extra precautions
• Pass along a copy of data instead of sharing it
• Check on conditions after the request completes
• Employ alternate strategies when a request fails
• Check for timeliness, relevance and correctly
  formed data.

40
Class Exercise

• Define Trust Regions on your architecture

41
From Analysis to Design

• Refine Domain Objects with Roles and
  Responsibilities
• Create Architecture
• Add Application Objects
• Add Utility Objects
• Refine Collaborations
• Refine Object Contracts
• Design Exception Handling Mechanisms

42
Contracts

• The ways in which a given client can interact
  with a given server are described by a contract.
  A contract is the list of requests that a client
  can make of a server. Both must fulfill the
  contract the client by making only those
  requests the contract specifies, and the server
  by responding appropriately to those requests.
  For each such request, a set of signatures
  serves as the formal specification of the
  contract.
• Wirfs-Brock, Wilkerson Wiener

43
Detailed Contracts

• Defining a precondition and a postcondition for
  a routine is a way to define a contract that
  binds the routine and its callers.
• Bertrand Meyer, Object-Oriented
  Software Construction
• Meyers contracts add even more details. They
  specify
• Obligations required of the client
• Conditions that must be true before the service
  will be requested
• Obligations required of the service provider
• Conditions that must be true during and after the
  execution of the service
• Guarantees of service
• Defined for each method or service call

44
Example A Contract For A Request That Spans A
Trust Boundary
45
Class Exercise

• Define Object Contracts

46

47
From Analysis to Design

• Refine Domain Objects with Roles and
  Responsibilities
• Create Architecture
• Add Application Objects
• Add Utility Objects
• Refine Collaborations
• Refine Object Contracts
• Design Exception Handling Mechanisms

48
Exceptions and Reliability
49
Exceptions and Design
50
A range of acceptable exposure

• Loss of comfort
• Loss of discretionary money
• Loss of essential money
• Loss of life
• Alistair Cockburn

51
Design for Exceptions

• Focus on making design resilient. ID key
  collaborations
• Develop consistent collaboration styles. Develop
  an application-wide policy
• Consider exceptions early!
• Develop trust regions in your design
• Develop control centers, reporting and recovery
  strategies
• Simplify your programming. Reduce exception
  handling clutter.

52
Exceptions vs. Errors

• Exceptions are deviations from the norm that we
  expect. We try to get the application in a
  predictable state and continue on.
• Errors are when things go unexpectedly wrong.
  Little can be done to recover.

53
More Complications

• Consider the user steering our application.
  They try to make an order, but it is partially
  out of stock.
• split order
• wait till all in-stock
• cancel order
• modify order
• This might potentially put system in unexpected
  state.
• Sometimes we dont want user steering system.

54
Exception Handling Design

• There are many different ways to handle an
  exception. It could be logged and re-thrown
  (possibly more than once), until some object
  takes corrective action.
• Who naturally might handle exceptions?
• External interfacers often take responsibility
  for handling faulty conditions in other systems
• The initial requestor
• As a fallback, pass the buck to some object who
  takes responsibility for controlling the action
• Handle as close to problem as possible

55
Design Guidelines

• Use exceptions to represent emergencies
• Handle exceptions as close to the problem as
  possible
• Separate concerns (normal vs. exception)
• DRY principle
• Get enough information so handlers can make
  informed decisions
• Consistency

56
Design Guidelines

• Avoid creating many different exception classes.
  Create only if handling expected to change
  dramatically.
• Pass enough information with exception so that
  handlers can try to recover.
• Handle exceptions dont let them fly anywhere
• Raise when the object cannot fulfill contract

57
Recovery
58
Strategies

• Inaction Do nothing
• Balk Admit defeat
• Guarded Suspension Suspend execution until
  conditions are OK to continue
• Provisional Action Pretend to perform the
  action, but dont commit until conditions are OK.

59
Strategies

• Recovery Perform and acceptable alternative
• Rollback Try to perform, but on failure undo
  everything
• Retry Repeatedly attempt, after recovering from
  failed attempts
• Appeal to higher authority Allow user to steer
  application
• Resign Minimize damage, write to log, signal
  definite and safe failure.
• Controller objects frequently make good handling
  choices

60
Exceptions to try and anticipate

• Users entering bad information or not responding
  at all.
• Invalid information
• Unauthorized or untimely requests
• Dropped communications
• Equipment failure
• Corrupt data, bad files
• Failure to complete in timely manner
• Critical performance errors

61
Analyzing Exceptions
62
Class Exercise

• Define Exception and Recovery Strategy