\PassOptionsToPackage{unicode=true}{hyperref} % options for packages loaded elsewhere
\PassOptionsToPackage{hyphens}{url}
%
\documentclass[]{article}
\usepackage{lmodern}
\usepackage{amssymb,amsmath}
\usepackage{ifxetex,ifluatex}
\usepackage{fixltx2e} % provides \textsubscript
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
  \usepackage[T1]{fontenc}
  \usepackage[utf8]{inputenc}
  \usepackage{textcomp} % provides euro and other symbols
\else % if luatex or xelatex
  \usepackage{unicode-math}
  \defaultfontfeatures{Ligatures=TeX,Scale=MatchLowercase}
\fi
% use upquote if available, for straight quotes in verbatim environments
\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
% use microtype if available
\IfFileExists{microtype.sty}{%
\usepackage[]{microtype}
\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
}{}
\IfFileExists{parskip.sty}{%
\usepackage{parskip}
}{% else
\setlength{\parindent}{0pt}
\setlength{\parskip}{6pt plus 2pt minus 1pt}
}
\usepackage{hyperref}
\hypersetup{
            pdftitle={CSci 658: Software Language Engineering Using CRC Cards (Class-Responsibility-Collaboration)},
            pdfauthor={H. Conrad Cunningham},
            pdfborder={0 0 0},
            breaklinks=true}
\urlstyle{same}  % don't use monospace font for urls
\usepackage{longtable,booktabs}
% Fix footnotes in tables (requires footnote package)
\IfFileExists{footnote.sty}{\usepackage{footnote}\makesavenoteenv{longtable}}{}
\setlength{\emergencystretch}{3em}  % prevent overfull lines
\providecommand{\tightlist}{%
  \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
\setcounter{secnumdepth}{0}
% Redefines (sub)paragraphs to behave more like sections
\ifx\paragraph\undefined\else
\let\oldparagraph\paragraph
\renewcommand{\paragraph}[1]{\oldparagraph{#1}\mbox{}}
\fi
\ifx\subparagraph\undefined\else
\let\oldsubparagraph\subparagraph
\renewcommand{\subparagraph}[1]{\oldsubparagraph{#1}\mbox{}}
\fi

% set default figure placement to htbp
\makeatletter
\def\fps@figure{htbp}
\makeatother

\usepackage{caption}
\DeclareCaptionLabelFormat{nolabel}{}
\captionsetup{labelformat=nolabel}

\title{CSci 658: Software Language Engineering\\
Using CRC Cards\\
(Class-Responsibility-Collaboration)}
\author{\textbf{H. Conrad Cunningham}}
\date{\textbf{27 April 2018}}

\begin{document}
\maketitle

{
\setcounter{tocdepth}{4}
\tableofcontents
}
\textbf{Copyright (C) 2018, \href{http://www.cs.olemiss.edu/~hcc}{H.
Conrad Cunningham}}

\textbf{Acknowledgement}: These notes are based, in part, on material
from chapters 3, 4, 5, and 6 of {[}Bellin 1997{]}.

\textbf{Advisory}: The HTML version of this document requires use of a
browser that supports the display of MathML. A good choice as of April
2018 is a recent version of Firefox from Mozilla.

\hypertarget{objectives}{%
\subsection{Objectives}\label{objectives}}

\begin{itemize}
\item
  Introduce concept of CRC card {[}Beck 1989{]} {[}Bellin 1997{]}
\item
  Discuss use in object-oriented analysis and design -\/- in particular
  Responsibility-Driven Design (RDD) {[}Wirfs-Brock 1990, 2003{]}
\item
  To extract class abstractions from domain and problem requirements
\item
  Use familiar case study: Automated Teller Machine (ATM)
\end{itemize}

\hypertarget{what-are-crc-cards}{%
\subsection{What are CRC Cards?}\label{what-are-crc-cards}}

\begin{itemize}
\item
  Provide informal, low-tech, low-cost, agile method for object-oriented
  analysis and design
\item
  Use a physical (4 by 6 inch) index card to represent a class (or
  object) -\/- can use tools, but keep use of method lightweight
\item
  Involve careful choice of names -\/- introduce vocabulary of system's
  domain and design
\item
  Relate to other domain analysis tasks for software framework and
  domain-specific language design
\end{itemize}

\hypertarget{crc-card-preview}{%
\subsection{CRC Card Preview}\label{crc-card-preview}}

Class Name

description of responsibilities

Collaborators

other classes

\hypertarget{what-goes-on-crc-cards}{%
\subsection{What Goes On CRC Cards?}\label{what-goes-on-crc-cards}}

\begin{itemize}
\item
  Record three types of info on card

  \begin{enumerate}
  \def\labelenumi{\arabic{enumi}.}
  \item
    \textbf{Class} name -\/- underlined upper-left corner -\/- noun

    \begin{itemize}
    \tightlist
    \item
      distinction between ``object'' (or ``instance'') and ``class''
      fuzzy in early stages
    \end{itemize}
  \item
    \textbf{Responsibilities} -\/- list on left side under name -\/-
    verb phrases

    \begin{itemize}
    \tightlist
    \item
      behaviors or operations
    \item
      knowledge held
    \end{itemize}
  \item
    \textbf{Collaborators} -\/- list on right side paired with
    responsibility

    \begin{itemize}
    \tightlist
    \item
      other classes used in carrying out responsibility
    \end{itemize}
  \end{enumerate}
\end{itemize}

\hypertarget{crc-card-layout}{%
\subsection{CRC Card Layout}\label{crc-card-layout}}

Class Name

description of responsibilities

Collaborators

other classes

\hypertarget{who-writes-crc-cards-1}{%
\subsection{Who Writes CRC Cards (1)}\label{who-writes-crc-cards-1}}

\begin{itemize}
\item
  Acknowledge no one individual has all needed information
\item
  Write CRC cards as team, rather than individually
\item
  Choose team large enough to be diverse, but small enough to reach
  consensus
\end{itemize}

\hypertarget{who-writes-crc-cards-2}{%
\subsection{Who Writes CRC Cards (2)}\label{who-writes-crc-cards-2}}

\begin{itemize}
\item
  Form analysis team with five or six members

  \begin{itemize}
  \tightlist
  \item
    one or two user domain experts
  \item
    one or two systems analysts
  \item
    one object-oriented software designer
  \item
    one team facilitator and leader
  \end{itemize}
\item
  Include experienced individuals
\item
  Select facilitator skilled at OO \& group techniques, not bossy
\item
  Write CRC cards to focus team activities
\end{itemize}

\hypertarget{brainstorming}{%
\subsection{Brainstorming}\label{brainstorming}}

Use brainstorming session to collect ideas quickly and creatively

\begin{itemize}
\item
  Collect diverse set of ideas
\item
  Compare ideas
\item
  Synthesize unanticipated solutions
\end{itemize}

\hypertarget{brainstorming-principles}{%
\subsection{Brainstorming Principles}\label{brainstorming-principles}}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  All ideas are potentially good ideas

  Don't censure yourself or others -\/- All ideas are equal
\item
  Think fast and furiously; ponder later

  Fast-paced discussion encourages individual creativity
\item
  Give every voice a turn

  Include everyone in group -\/- no loudmouth domination
\item
  A little humor can be a powerful force

  Humor can break barriers, relieve tension, and build trust
\end{enumerate}

\hypertarget{candidate-class-sources-1}{%
\subsection{Candidate Class Sources
(1)}\label{candidate-class-sources-1}}

Before session, assign each team member an investigative task

\begin{itemize}
\item
  Read \emph{all} requirements documents

  \begin{itemize}
  \tightlist
  \item
    Examine any formal or informal requirements documents (e.g.~user
    stories)
  \item
    Don't overlook indirect sources -\/- memos, meeting minutes, etc.
  \item
    Circle nouns, pronouns, and noun phrases -\/- potential classes
  \end{itemize}
\item
  Look carefully at reports

  \begin{itemize}
  \tightlist
  \item
    Examine reports generated in old (manual or automated) system
  \item
    Examine profiles for reports desired in new system
  \item
    Circle nouns, pronouns, and noun phrases -\/- potential classes
  \end{itemize}
\end{itemize}

\hypertarget{candidate-class-sources-2}{%
\subsection{Candidate Class Sources
(2)}\label{candidate-class-sources-2}}

\begin{itemize}
\item
  Conduct interviews

  \begin{itemize}
  \tightlist
  \item
    Talk to experienced users of old system
  \item
    Record interview or take precise notes
  \item
    Identify nouns, pronouns, and noun phrases -\/- potential classes
  \end{itemize}
\item
  Examine documentation and files

  \begin{itemize}
  \tightlist
  \item
    Review documentation on old system
  \item
    Review any available unofficial/personal notes from users or
    maintainers
  \item
    Identify nouns, pronouns, and noun phrases -\/- potential classes
  \end{itemize}
\end{itemize}

A good analyst is a good detective!

Identifying verbs and verb phrases may help find responsibilities later

\hypertarget{landshark-bank-atm-1}{%
\subsection{Landshark Bank ATM (1)}\label{landshark-bank-atm-1}}

Landshark Bank, a new bank opening next summer, plans to provide a full
service automated teller machine (ATM) system.

The ATM system interacts with the customer through a display screen,
numeric and special input keys, a bankcard reader, a deposit slot, and a
receipt printer.

Customers may make deposits, withdrawals, and balance inquires using the
ATM machine, but the update to accounts will be handled through an
interface to the Accounts system.

Customers are assigned a Personal Identification Number (PIN) and
clearance level by the security system. The PIN can be verified prior to
any transaction.

In the future, we plan to support routine operations such as a change of
address or phone number using the ATM.

\hypertarget{landshark-bank-atm-2}{%
\subsection{Landshark Bank ATM (2)}\label{landshark-bank-atm-2}}

Landshark Bank, a new bank opening next summer, plans to provide a full
service automated teller machine (ATM) system.

The \textbf{ATM system} \emph{interacts} with the \textbf{customer}
through a \textbf{display screen}, \textbf{numeric} and \textbf{special
input keys}, a \textbf{bankcard reader}, a \textbf{deposit slot}, and a
\textbf{receipt printer}.

\textbf{Customers} may \emph{make} \textbf{deposits},
\textbf{withdrawals}, and \textbf{balance inquires} using the
\textbf{ATM machine}, but the \textbf{update} to \textbf{accounts} will
be \emph{handled} through an \textbf{interface} to the \textbf{Accounts
system}.

\textbf{Customers} \emph{are assigned} a \textbf{Personal Identification
Number (PIN)} and \textbf{clearance level} by the \textbf{security
system}. The \textbf{PIN} can be \emph{verified} prior to any
\textbf{transaction}.

In the \textbf{future}, \textbf{we} plan \emph{to support}
\textbf{routine operations} such as a \textbf{change of address} or
\textbf{phone number} using the \textbf{ATM}.

\hypertarget{brainstorming-steps-1}{%
\subsection{Brainstorming Steps (1)}\label{brainstorming-steps-1}}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  Review brainstorming principles
\item
  State session objectives

  \begin{itemize}
  \item
    Have a precise objective -\/- clear to all, narrow enough to
    accomplish in session
  \item
    Avoid digression from objective
  \end{itemize}
\end{enumerate}

\hypertarget{brainstorming-steps-2}{%
\subsection{Brainstorming Steps (2)}\label{brainstorming-steps-2}}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\setcounter{enumi}{2}
\item
  Use a round-robin technique

  \begin{itemize}
  \item
    Go from individual to individual
  \item
    Individuals may ``pass'' if they have nothing to contribute
  \item
    Stop when no one has anything to contribute
  \end{itemize}
\end{enumerate}

\hypertarget{brainstorming-steps-3}{%
\subsection{Brainstorming Steps (3)}\label{brainstorming-steps-3}}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\setcounter{enumi}{3}
\item
  Discuss and select

  \begin{itemize}
  \item
    Restate objective
  \item
    Organize candidate classes into 3 categories by consensus -\/-
    ``winners'' -\/- ``losers'' -\/- ``maybes''
  \item
    Discuss ``maybes'' for fixed time to decide if ``winner'' or
    ``loser''
  \item
    Postpone ``maybe'' items if more information needed to decide
  \end{itemize}
\end{enumerate}

\hypertarget{candidate-classes-for-atm}{%
\subsection{Candidate Classes for ATM}\label{candidate-classes-for-atm}}

\begin{longtable}[]{@{}lll@{}}
\toprule
\endhead
ATM & FinancialTransaction & BankCard\tabularnewline
BankCustomer & PIN & Account\tabularnewline
SavingsAccount & CheckingAccount & Transfer\tabularnewline
Withdrawal & Deposit & BalanceInquiry\tabularnewline
Receipt & ReceiptPrinter & Keypad\tabularnewline
Screen & CashDispenser & ScreenMessage\tabularnewline
Display & FundsAvailable & DepositEnvelopeFailure\tabularnewline
Balance & TimeOutKey & TransactionLog\tabularnewline
Key & AccountHolder & Printer\tabularnewline
ScreenSaver & Prompt & NumericKey\tabularnewline
\bottomrule
\end{longtable}

\hypertarget{identify-core-classes-1}{%
\subsection{Identify Core Classes (1)}\label{identify-core-classes-1}}

Divide candidate classes into categories in following order:

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  \textbf{critical classes} (``winners''), for which we will write CRC
  cards

  Items that directly relate to main entities of application

  ATM example: Account, Deposit, Withdrawal, BalanceInquiry
\end{enumerate}

\hypertarget{identify-core-classes-2}{%
\subsection{Identify Core Classes (2)}\label{identify-core-classes-2}}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\setcounter{enumi}{1}
\item
  \textbf{irrelevant candidates} (``losers''), which we will eliminate

  Items that are clearly outside the system scope

  ATM example: Printer, ScreenSave, and Prompt -\/- related to user
  interface done later, but not to core banking application
\end{enumerate}

\hypertarget{identify-core-classes-3}{%
\subsection{Identify Core Classes (3)}\label{identify-core-classes-3}}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\setcounter{enumi}{2}
\item
  \textbf{undecided candidates} (``maybes''), which we will review
  further

  Items that we cannot categorize without clarifying system boundaries
  and definition

  ATM example: What is an ``ATM''?
\end{enumerate}

\hypertarget{crc-card-for-account-phase-1}{%
\subsection{CRC Card for Account, Phase
1}\label{crc-card-for-account-phase-1}}

Account

description of responsibilities

Collaborators

other classes

\hypertarget{clarify-system-scope}{%
\subsection{Clarify System Scope}\label{clarify-system-scope}}

\begin{itemize}
\item
  Determine \emph{scope} -\/- what is and what is not part of system
\item
  Decide system boundary definitively
\item
  Perhaps draw diagram to record system boundary
\end{itemize}

ATM example: What is scope of the ATM system?

\begin{itemize}
\item
  Does it handle everything -\/- banking application, user interface,
  and interactions between them?
\item
  Is ATM responsible for updating accounting records? or just recording
  and mediating transaction activity?
\end{itemize}

Decision: Limit scope to banking information capture, leave user
interface and account update to other systems

\hypertarget{identify-commonalities-variabilities-1}{%
\subsection{Identify Commonalities \& Variabilities
(1)}\label{identify-commonalities-variabilities-1}}

\textbf{Commonality (\emph{frozen spot}):} part of system unlikely to
change from one system variant to another {[}Coplien 1998{]}

\textbf{Variability (\emph{hot spot}):} part of system likely to change
from one system variant to another {[}Coplien 1998{]}

\begin{itemize}
\item
  Encapsulate hot spot inside component (apply \emph{information
  hiding})
\item
  Design interfaces of and relationships among components so that they
  seldom change -\/- reflect commonalities
\end{itemize}

\hypertarget{identify-commonalities-variabilities-2}{%
\subsection{Identify Commonalities \& Variabilities
(2)}\label{identify-commonalities-variabilities-2}}

ATM example hot spot: Withdrawal handling

\begin{itemize}
\item
  Initial support for dispensing cash, but future support for updating
  cash cards
\item
  Affected classes? Account, Withdrawal, FundsAvailable, BankCard
\end{itemize}

\hypertarget{use-appropriate-design-patterns}{%
\subsection{Use Appropriate Design
Patterns}\label{use-appropriate-design-patterns}}

\textbf{Design pattern:} design structure successfully used in similar
context in past -\/- reusable design

\begin{itemize}
\item
  Use appropriate general patterns -\/- e.g.~from {[}Gamma 1995{]}
\item
  Use appropriate local patterns that distill specific experiences of
  development organization on similar projects
\item
  Add or modify classes to satisfy design pattern
\end{itemize}

ATM example: Interactions of ATM with outside entities might be modeled
using local ``system interaction pattern''

Result would be new core class AuthorizeSystemInteraction

\hypertarget{leverage-existing-frameworks}{%
\subsection{Leverage Existing
Frameworks}\label{leverage-existing-frameworks}}

\textbf{Software framework:} collection of abstract and concrete classes
that captures architecture and system operation

Extend framework classes to customize behavior

``Upside down library'' -\/- system control resides in framework code
that calls ``down'' to user-supplied code

Example: Graphical user interface toolkits like the Java Swing

\begin{itemize}
\item
  Potentially select appropriate software framework
\item
  Add or modify core classes to fit framework
\end{itemize}

\hypertarget{eliminate-unneeded-core-classes-1}{%
\subsection{Eliminate Unneeded Core Classes
(1)}\label{eliminate-unneeded-core-classes-1}}

\begin{itemize}
\item
  Remove ghost classes -\/- classes that, upon further examination, do
  not fit within application

  Look for classes outside scope of system

  ATM example: BankCustomer, Printer, and Keypad are relevant but
  outside scope

  System only needs to know about BankCustomer indirectly through
  BankCard info -\/- e.g.~PIN
\end{itemize}

\hypertarget{eliminate-unneeded-core-classes-2}{%
\subsection{Eliminate Unneeded Core Classes
(2)}\label{eliminate-unneeded-core-classes-2}}

\begin{itemize}
\item
  Combine synonyms -\/- use one name for items essentially same

  Different groups within organization may use different names for same
  thing

  ATM example: BankCustomer and AccountHolder probably synonyms. Adopt
  one or create new name.
\item
  Be careful when same word refers to different things!

  ATM example: Balance and FundsAvailable for withdrawal may differ
  because of policy affecting account. Keep separate.
\end{itemize}

\hypertarget{distinguish-attributes-classes-1}{%
\subsection{Distinguish Attributes \& Classes
(1)}\label{distinguish-attributes-classes-1}}

Some candidate classes may represent information held by others

May be an attribute rather than a class if:

\begin{itemize}
\item
  It does not do anything -\/- has no operations

  ATM example: Balance and FundsAvailable have few meaningful operations
  -\/- both closely associated with Account
\item
  It cannot change state
\end{itemize}

\hypertarget{distinguish-attributes-classes-2}{%
\subsection{Distinguish Attributes \& Classes
(2)}\label{distinguish-attributes-classes-2}}

Consider PIN from ATM example:

\begin{itemize}
\item
  If immutable, then perhaps make attribute of Account
\item
  If can change state (valid, invalid, suspended) then should be class
\end{itemize}

\hypertarget{core-classes-for-atm}{%
\subsection{Core Classes for ATM}\label{core-classes-for-atm}}

\begin{itemize}
\tightlist
\item
  FinancialTransaction
\item
  Account
\item
  BalanceInquiry
\item
  Withdrawal
\item
  Deposit
\item
  BankCard
\item
  AuthorizeSystemInteraction
\end{itemize}

\hypertarget{undecided-classes-for-atm}{%
\subsection{Undecided Classes for ATM}\label{undecided-classes-for-atm}}

\begin{itemize}
\tightlist
\item
  BankCustomer (ghost -\/- with AuthorizeSystemInteraction)
\item
  PIN (attribute)
\item
  SavingsAccount (attribute of Account)
\item
  CheckingAccount (attribute of Account)
\item
  ATM (ghost -\/- system name)
\item
  FundsAvailable (attribute)
\item
  Balance (attribute)
\item
  Amount (attribute?)
\item
  AccountHolder (synonym)
\end{itemize}

\hypertarget{irrelevant-items-for-atm}{%
\subsection{Irrelevant Items for ATM}\label{irrelevant-items-for-atm}}

Outside scope (most part of user interface system)

\begin{itemize}
\tightlist
\item
  Transfer (not handled in first version)
\item
  Receipt, ReceiptPrinter
\item
  Keypad, Screen, CashDispenser
\item
  ScreenMessage, Display
\item
  DepositEnvelopeFailure, TimeOutKey
\item
  TransactionLog, Printer
\item
  ScreenSaver, Prompt
\item
  Numeric Key, Key
\end{itemize}

\hypertarget{naming-1}{%
\subsection{Naming (1)}\label{naming-1}}

\begin{itemize}
\item
  Names of classes should be singular nouns beginning with capitals
\item
  Names of responsibilities (operations) should be short sequences of
  words containing one verb
\item
  Names of booleans should indicate meaning of the \emph{true} value
\item
  Names should be easily recognized by domain experts
\item
  Names should be consistent within project (whole organization?)
\end{itemize}

\hypertarget{naming-2}{%
\subsection{Naming (2)}\label{naming-2}}

\begin{itemize}
\item
  Names should be unambiguous -\/- Use abbreviations with care!
\item
  Names should use capitalization and underscores, but avoid digits
\item
  Names should be short
\item
  Names should be pronounceable (read them out loud)
\end{itemize}

\hypertarget{characteristics-of-a-good-class}{%
\subsection{Characteristics of a Good
Class}\label{characteristics-of-a-good-class}}

\begin{itemize}
\item
  Has a good name (as defined above)
\item
  Has responsibility for behaviors
\item
  Has responsibility for remembering knowledge
\item
  Is needed by other classes (collaborates)
\item
  Actively participates in system
\end{itemize}

If class has limited (e.g.~one) responsibility, then reconsider whether
to keep it (e.g.~to promote reuse) or combine with others.

\hypertarget{assigning-responsibilities-1}{%
\subsection{Assigning Responsibilities
(1)}\label{assigning-responsibilities-1}}

\begin{itemize}
\item
  After core classes identified, assign responsibilities to each class

  \begin{itemize}
  \tightlist
  \item
    responsibilities for exhibiting behaviors
  \item
    responsibilities for holding knowledge
  \end{itemize}
\item
  Write responsibilities on CRC cards for each core class
\item
  Often intermix task of finding collaborators with finding
  responsibilities
\item
  Use combination of brainstorming and role-playing of scenarios (below)
  to discover responsibilities
\end{itemize}

\hypertarget{assigning-responsibilities-2}{%
\subsection{Assigning Responsibilities
(2)}\label{assigning-responsibilities-2}}

\begin{itemize}
\item
  Focus on the \emph{what}, not the \emph{how}

  Grady Booch: ``When considering the semantics of classes and objects,
  there is the tendency to explain how things work; the proper response
  is `I don't care.'\,''

  False semantic distinctions among responsibilities may rob us of
  opportunities to use inheritance and polymorphism.
\end{itemize}

\hypertarget{responsibility-detection-1}{%
\subsection{Responsibility Detection
(1)}\label{responsibility-detection-1}}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  Brainstorm first. Refine later.

  Use brainstorming to identify set of candidate responsibilities for
  core classes

  Verbs that occur in requirements documents etc. may indicate behaviors
  (operations) that must exhibited

  Include rather than exclude. Don't worry about duplication

  Refine lists later

  Name each carefully
\end{enumerate}

\hypertarget{responsibility-detection-2a}{%
\subsection{Responsibility Detection
(2a)}\label{responsibility-detection-2a}}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\setcounter{enumi}{1}
\item
  Think simple. Factor out complexity.

  If most responsibilities cluster in one or two classes, then probably
  not good OO design -\/- does not exploit polymorphism and
  encapsulation

  ATM example:

  \begin{itemize}
  \tightlist
  \item
    Might give most responsibility to Account -\/- strong ``manager''
    procedure giving commands to weak ``workers''
  \item
    Account probably too inflexible and others too insignificant to
    reuse
  \item
    Give each class distinct role -\/- make each well-defined, complete,
    cohesive abstraction -\/- increase reusability
  \end{itemize}
\end{enumerate}

\hypertarget{responsibility-detection-2b}{%
\subsection{Responsibility Detection
(2b)}\label{responsibility-detection-2b}}

ATM example:

\begin{itemize}
\tightlist
\item
  Give class Withdrawal responsibility ``Withdraw Funds'' -\/- making
  potentially useful to any class needing withdrawals

  \begin{itemize}
  \tightlist
  \item
    Give class Account responsibility ``Accept Withdrawal'' -\/- done by
    Withdrawal collaborating with it
  \item
    Factor out complexity by identifying repeatedly occurring
    specialized behaviors -\/- create appropriate new classes
  \end{itemize}

  ATM example:

  \begin{itemize}
  \item
    Perhaps factor out capturing and responding to user requests

    Introduce new class Form with responsibility ``ask user for
    information''
  \end{itemize}
\end{itemize}

\hypertarget{responsibility-detection-3}{%
\subsection{Responsibility Detection
(3)}\label{responsibility-detection-3}}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\setcounter{enumi}{2}
\item
  Use abstraction to advantage.

  \begin{itemize}
  \item
    Build hierarchies of classes
  \item
    Abstract essence of related classes by identifying common
    responsibilities -\/- same ``what'', different ``how''
  \item
    Make these polymorphic operations -\/- defined in \emph{abstract
    base class} -\/- given specific responsibility in \emph{concrete
    subclass}
  \end{itemize}

  ATM example:

  \begin{itemize}
  \item
    Note commonalities among Withdrawal, Deposit, etc.
  \item
    Create abstract base class Transaction with abstract responsibility
    ``execute a financial transaction''
  \item
    Implement responsibility differently for each subclass
  \end{itemize}
\end{enumerate}

\hypertarget{responsibility-detection-4}{%
\subsection{Responsibility Detection
(4)}\label{responsibility-detection-4}}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\setcounter{enumi}{3}
\item
  Do not marry one solution. Play the field first.

  \begin{itemize}
  \item
    Remember CRC cards are inexpensive and erasable!!
  \item
    Experiment with different configurations of classes and assignments
    of responsibilities
  \item
    Change CRC cards early to avoid changing code later
  \end{itemize}
\end{enumerate}

\hypertarget{crc-card-for-account-phase-2}{%
\subsection{CRC Card for Account, Phase
2}\label{crc-card-for-account-phase-2}}

Account

Know balance

Accept Deposit

Accept Withdrawal

other responsibilities

Collaborators

~

~

~

other collaborators

\hypertarget{assigning-collaborations-1}{%
\subsection{Assigning Collaborations
(1)}\label{assigning-collaborations-1}}

\begin{itemize}
\item
  Identify relationships among classes

  \begin{itemize}
  \tightlist
  \item
    Each class specializes in some set of knowledge and behaviors
  \item
    Classes must cooperate to accomplish nontrivial tasks
  \item
    Thus \emph{collaborations} between classes important
  \end{itemize}
\item
  Pair collaborations with responsibilities on CRC card
\item
  Use \emph{scenario}-based role-play to find/test collaborations

  \begin{itemize}
  \tightlist
  \item
    Scenario -\/- system behavior and sequence of events to realize it
    -\/- use case, user story
  \item
    Simulating execution enables team to discover appropriate
    responsibilities and collaborations
  \end{itemize}
\end{itemize}

\hypertarget{assigning-collaborations-2}{%
\subsection{Assigning Collaborations
(2)}\label{assigning-collaborations-2}}

\begin{itemize}
\item
  Add collaborations when relationships found

  \begin{itemize}
  \item
    Identify clients and servers

    \begin{itemize}
    \item
      Server -\/- class that provides a resource
    \item
      Client -\/- class that uses a resource
    \end{itemize}

    Server is collaborator of client, not vice versa

    ATM example: In Withdrawal operation, Account is server for
    Withdrawal client
  \item
    Identify hierarchies of classes

    ATM example: Transaction as superclass of Withdrawal, Deposit, etc.
  \end{itemize}
\end{itemize}

\hypertarget{hierarchy-identification-tips-1}{%
\subsection{Hierarchy Identification Tips
(1)}\label{hierarchy-identification-tips-1}}

\begin{itemize}
\item
  Explore \emph{is-a} (``kind-of'') relationships (possible inheritance)

  ATM -- Withdrawal is a (``kind of'') Transaction

  ATM -- Withdrawal is not ``part of'' Transaction
\item
  Name key abstractions
\item
  Separate mixed classes where necessary
\item
  Place super/subclass sets in hierarchies
\end{itemize}

\hypertarget{hierarchy-identification-tips-2}{%
\subsection{Hierarchy Identification Tips
(2)}\label{hierarchy-identification-tips-2}}

\begin{itemize}
\item
  Look for reusable behaviors

  \begin{itemize}
  \tightlist
  \item
    reuse existing patterns and frameworks
  \item
    record new patterns and frameworks for future reuse
  \end{itemize}
\end{itemize}

\hypertarget{crc-role-play-steps-1}{%
\subsection{CRC Role Play Steps (1)}\label{crc-role-play-steps-1}}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  Create a list of \emph{scenarios} for use of system (i.e. \emph{use
  cases}, \emph{user stories}, actions to realize requirement)

  Use brainstorming

  ATM example: customer withdraws cash
\item
  Assign roles of classes to team members

  Each member has one or more classes
\end{enumerate}

\hypertarget{crc-role-play-steps-2}{%
\subsection{CRC Role Play Steps (2)}\label{crc-role-play-steps-2}}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\setcounter{enumi}{2}
\item
  Rehearse the scenario

  Execute scenario with team members announcing what affected classes
  are doing -\/- putting cards into play when used
\item
  Correct CRC card and revise scenario
\item
  Repeat above two steps as necessary until rehearsal smooth
\item
  Perform final scenario
\end{enumerate}

\hypertarget{develop-role-play-scenarios-1}{%
\subsection{Develop Role-Play Scenarios
(1)}\label{develop-role-play-scenarios-1}}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  Concentrate on ``must do'' scenarios

  Core behaviors touch central features of system

  ATM example: customer withdraws cash
\item
  Develop conditional ``can do if'' scenarios

  Routine tasks carried out under certain conditions

  Tasks to avoid exceptional situations

  Be careful about crossing out of system scope
\end{enumerate}

\hypertarget{develop-role-play-scenarios-2}{%
\subsection{Develop Role-Play Scenarios
(2)}\label{develop-role-play-scenarios-2}}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\setcounter{enumi}{2}
\item
  Record ``might do'' scenarios (``abuse cases'') to test flexibility

  Exceptions -\/- unusual, complex, difficult to handle cases

  Help uncover poor collaborations and clarify system scope (a stress
  test)

  ATM example: Withdrawal with insufficient funds
\item
  If larger than 25 scenarios in ``must do'' and ``can do if''
  categories, break into subsystems
\end{enumerate}

\hypertarget{effective-role-play-1}{%
\subsection{Effective Role Play (1)}\label{effective-role-play-1}}

\begin{itemize}
\item
  Stick to the scenario(s)
\item
  Limit session time ( \textless{}= 2 hours )
\item
  Use conscious, deliberate problem-solving activities
\end{itemize}

\hypertarget{effective-role-play-2}{%
\subsection{Effective Role Play (2)}\label{effective-role-play-2}}

\begin{itemize}
\item
  Use conscious, deliberate problem-solving activities

  \begin{enumerate}
  \def\labelenumi{\arabic{enumi}.}
  \tightlist
  \item
    Warm up

    \begin{itemize}
    \tightlist
    \item
      Prepare every session for effective group work by breaking down
      inhibitions
    \item
      Use games, puzzles, brainteasers, mock brainstorming on ``fun''
      topic.
    \item
      Use ``go-around'' review of activities since last session (use if
      organizational culture discourages above)
    \end{itemize}
  \item
    Enactment

    \begin{itemize}
    \tightlist
    \item
      Act out each scenario
    \end{itemize}
  \item
    Assessment

    \begin{itemize}
    \tightlist
    \item
      Build lists of problems encountered
    \item
      Evaluate problems found
    \end{itemize}
  \end{enumerate}
\end{itemize}

\hypertarget{warm-up-tips}{%
\subsection{Warm-Up Tips}\label{warm-up-tips}}

\begin{itemize}
\item
  Warm-up time never wasted
\item
  Warm-up every session
\item
  Inspire confidence of all team members, especially for new or changed
  teams
\item
  Don't get too serious too fast
\end{itemize}

\hypertarget{scenario-enactment-1}{%
\subsection{Scenario Enactment (1)}\label{scenario-enactment-1}}

\begin{itemize}
\item
  Identify and summarize scenarios to be enacted (agenda)

  \begin{itemize}
  \tightlist
  \item
    Handle ``must do'' first, then ``can do if''
  \end{itemize}
\item
  Assign roles to actors

  \begin{itemize}
  \tightlist
  \item
    Distribute CRC cards
  \item
    Collaborators to different persons
  \item
    Use domain experts for classes if possible
  \item
    Rotate assignments from session to session
  \end{itemize}
\item
  Initiate scenario -\/- hold up first class

  \begin{itemize}
  \tightlist
  \item
    ATM example: Start with Customer or BankCard
  \end{itemize}
\end{itemize}

\hypertarget{scenario-enactment-2}{%
\subsection{Scenario Enactment (2)}\label{scenario-enactment-2}}

\begin{itemize}
\item
  Proceed from responsibility to its collaborators

  \begin{itemize}
  \tightlist
  \item
    Hold up active card or toss ``in play'' on the table
  \end{itemize}
\item
  Watch action to detect problems
\item
  When errors discovered

  \begin{itemize}
  \tightlist
  \item
    Correct if minor
  \item
    Take notes if complex
  \item
    stop enactment immediately if significant and complex -\/- go to
    assessment
  \end{itemize}
\end{itemize}

\hypertarget{scenario-enactment-3}{%
\subsection{Scenario Enactment (3)}\label{scenario-enactment-3}}

\begin{itemize}
\item
  Avoid unnecessary changes, especially after considerable role play
\item
  Do enactment-assessment on multiple scenarios per session
\end{itemize}

\hypertarget{scenario-assessment}{%
\subsection{Scenario Assessment}\label{scenario-assessment}}

\begin{itemize}
\item
  ``Go-around'' comments
\item
  Identify problem points
\item
  Create problem-solving priority list
\item
  Change or confirm CRC cards
\item
  Identify any scenarios that need to be repeated
\end{itemize}

\hypertarget{wider-use}{%
\subsection{Wider Use}\label{wider-use}}

\begin{itemize}
\item
  Use similar analysis techniques to build broader model of domain
  concepts
\item
  Use similar Scope-Commonality-Variability (SCV) analysis {[}Coplien
  1998{]} to design software families (frameworks, product lines)

  encapsulate variabilities to allow customization
\item
  Use SCV analysis in design of domain-specific language (DSL) syntax
  and semantics
\end{itemize}

\hypertarget{summary}{%
\subsection{Summary}\label{summary}}

\begin{itemize}
\item
  Introduced CRC cards -- lightweight, informal
\item
  Discussed how to use them in OO analysis and design
\item
  Examined how to use them in teams
\end{itemize}

\hypertarget{references-1}{%
\subsection{References (1)}\label{references-1}}

\begin{description}
\tightlist
\item[{[}Beck 1989{]}]
Kent Beck and Ward Cunningham.
\href{http://c2.com/doc/oopsla89/paper.html}{A Laboratory for Teaching
Object-Oriented Thinking}, In \emph{Proceedings of the OOPSLA'89
Conference}, ACM, 1989.
\item[{[}Bellin 1997{]}]
David Bellin and Susan Suchman Simone. \emph{The CRC Card Book}, Addison
Wesley, 1997.
\item[{[}Budd 2000{]}]
Timothy Budd. \emph{Understanding Object-Oriented Programming with
Java}, Updated Edition, Addison Wesley, 2000.
\end{description}

\hypertarget{references-2}{%
\subsection{References (2)}\label{references-2}}

\begin{description}
\tightlist
\item[{[}Coplien 1998{]}]
J. Coplien, D. Hoffman, and D. Weiss.
\href{https://3aec1b23-a-eadc3f87-s-sites.googlegroups.com/a/gertrudandcope.com/info/Publications/Mpd/IeeeNov1998/coplien.pdf?attachauth=ANoY7cqjLSFhBTUnDP-C_Cj4kLTGu334X-m5cMpw_ErjA8RasBO0e9_FpIRx1o6SKVk29-QYwWl4YeLTOdspGdoohyn8jRDA7pfG8q2gaXJ6EU8NFkbS0Bs5UCiI09kChAAWrTX4-Qv3S-JxGUzHcDvJyaiY4wdqgWeAyoe-BlDYpmSEmiDuSOobndHFoqaZ4VWUvg-N4n01hKVvk5NEQCeSQBkw7lonmWkwUjWwg0363dJ27ScQVYbrdkEHxZvQPdnq2rRwCAMs\&attredirects=0}{Commonality
and Variability in Software Engineering}, \emph{IEEE Software},
15(6):37--45, November 1998.
{[}\href{localcopy/CoplienCommonalityVariability.pdf}{local}{]}
\item[{[}Gamma 1995{]}]
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
\emph{Design Patterns: Elements of Reusable Object-Oriented Software},
Addison Wesley, 1995.
\item[{[}Wilkinson 1995{]}]
Nancy M. Wilkinson. \emph{Using CRC Cards: An Informal Approach to
Object-Oriented Development}, Cambridge University Press, 1995.
\end{description}

\hypertarget{references-3}{%
\subsection{References (3)}\label{references-3}}

\begin{description}
\tightlist
\item[{[}Wirfs-Brock 1990{]}]
Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener. \emph{Designing
Object-Oriented Software}, Prentice-Hall, 1990.
\item[{[}Wirfs-Brock 2003{]}]
Rebecca Wirfs-Brock and Alan McKean. \emph{Object Design: Roles,
Responsibilities, and Collaborations}, Addison-Wesley, 2003.
\end{description}

\end{document}