H. Conrad Cunningham
27 April 2018
Copyright (C) 2018, H. Conrad Cunningham
Acknowledgement: These notes are based, in part, on material from chapters 3, 4, 5, and 6 of [Bellin 1997].
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.
Introduce concept of CRC card [Beck 1989] [Bellin 1997]
Discuss use in object-oriented analysis and design -- in particular Responsibility-Driven Design (RDD) [Wirfs-Brock 1990, 2003]
To extract class abstractions from domain and problem requirements
Use familiar case study: Automated Teller Machine (ATM)
Provide informal, low-tech, low-cost, agile method for object-oriented analysis and design
Use a physical (4 by 6 inch) index card to represent a class (or object) -- can use tools, but keep use of method lightweight
Involve careful choice of names -- introduce vocabulary of system’s domain and design
Relate to other domain analysis tasks for software framework and domain-specific language design
|
|
Record three types of info on card
Class name -- underlined upper-left corner -- noun
Responsibilities -- list on left side under name -- verb phrases
Collaborators -- list on right side paired with responsibility
|
|
Acknowledge no one individual has all needed information
Write CRC cards as team, rather than individually
Choose team large enough to be diverse, but small enough to reach consensus
Form analysis team with five or six members
Include experienced individuals
Select facilitator skilled at OO & group techniques, not bossy
Write CRC cards to focus team activities
Use brainstorming session to collect ideas quickly and creatively
Collect diverse set of ideas
Compare ideas
Synthesize unanticipated solutions
All ideas are potentially good ideas
Don’t censure yourself or others -- All ideas are equal
Think fast and furiously; ponder later
Fast-paced discussion encourages individual creativity
Give every voice a turn
Include everyone in group -- no loudmouth domination
A little humor can be a powerful force
Humor can break barriers, relieve tension, and build trust
Before session, assign each team member an investigative task
Read all requirements documents
Look carefully at reports
Conduct interviews
Examine documentation and files
A good analyst is a good detective!
Identifying verbs and verb phrases may help find responsibilities later
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.
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.
Review brainstorming principles
State session objectives
Have a precise objective -- clear to all, narrow enough to accomplish in session
Avoid digression from objective
Use a round-robin technique
Go from individual to individual
Individuals may “pass” if they have nothing to contribute
Stop when no one has anything to contribute
Discuss and select
Restate objective
Organize candidate classes into 3 categories by consensus -- “winners” -- “losers” -- “maybes”
Discuss “maybes” for fixed time to decide if “winner” or “loser”
Postpone “maybe” items if more information needed to decide
| ATM | FinancialTransaction | BankCard |
| BankCustomer | PIN | Account |
| SavingsAccount | CheckingAccount | Transfer |
| Withdrawal | Deposit | BalanceInquiry |
| Receipt | ReceiptPrinter | Keypad |
| Screen | CashDispenser | ScreenMessage |
| Display | FundsAvailable | DepositEnvelopeFailure |
| Balance | TimeOutKey | TransactionLog |
| Key | AccountHolder | Printer |
| ScreenSaver | Prompt | NumericKey |
Divide candidate classes into categories in following order:
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
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
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”?
|
|
Determine scope -- what is and what is not part of system
Decide system boundary definitively
Perhaps draw diagram to record system boundary
ATM example: What is scope of the ATM system?
Does it handle everything -- banking application, user interface, and interactions between them?
Is ATM responsible for updating accounting records? or just recording and mediating transaction activity?
Decision: Limit scope to banking information capture, leave user interface and account update to other systems
Commonality (frozen spot): part of system unlikely to change from one system variant to another [Coplien 1998]
Variability (hot spot): part of system likely to change from one system variant to another [Coplien 1998]
Encapsulate hot spot inside component (apply information hiding)
Design interfaces of and relationships among components so that they seldom change -- reflect commonalities
ATM example hot spot: Withdrawal handling
Initial support for dispensing cash, but future support for updating cash cards
Affected classes? Account, Withdrawal, FundsAvailable, BankCard
Design pattern: design structure successfully used in similar context in past -- reusable design
Use appropriate general patterns -- e.g. from [Gamma 1995]
Use appropriate local patterns that distill specific experiences of development organization on similar projects
Add or modify classes to satisfy design pattern
ATM example: Interactions of ATM with outside entities might be modeled using local “system interaction pattern”
Result would be new core class AuthorizeSystemInteraction
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
Potentially select appropriate software framework
Add or modify core classes to fit framework
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
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.
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.
Some candidate classes may represent information held by others
May be an attribute rather than a class if:
It does not do anything -- has no operations
ATM example: Balance and FundsAvailable have few meaningful operations -- both closely associated with Account
It cannot change state
Consider PIN from ATM example:
If immutable, then perhaps make attribute of Account
If can change state (valid, invalid, suspended) then should be class
Outside scope (most part of user interface system)
Names of classes should be singular nouns beginning with capitals
Names of responsibilities (operations) should be short sequences of words containing one verb
Names of booleans should indicate meaning of the true value
Names should be easily recognized by domain experts
Names should be consistent within project (whole organization?)
Names should be unambiguous -- Use abbreviations with care!
Names should use capitalization and underscores, but avoid digits
Names should be short
Names should be pronounceable (read them out loud)
Has a good name (as defined above)
Has responsibility for behaviors
Has responsibility for remembering knowledge
Is needed by other classes (collaborates)
Actively participates in system
If class has limited (e.g. one) responsibility, then reconsider whether to keep it (e.g. to promote reuse) or combine with others.
After core classes identified, assign responsibilities to each class
Write responsibilities on CRC cards for each core class
Often intermix task of finding collaborators with finding responsibilities
Use combination of brainstorming and role-playing of scenarios (below) to discover responsibilities
Focus on the what, not the 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.
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
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:
ATM example:
ATM example:
Perhaps factor out capturing and responding to user requests
Introduce new class Form with responsibility “ask user for information”
Use abstraction to advantage.
Build hierarchies of classes
Abstract essence of related classes by identifying common responsibilities -- same “what”, different “how”
Make these polymorphic operations -- defined in abstract base class -- given specific responsibility in concrete subclass
ATM example:
Note commonalities among Withdrawal, Deposit, etc.
Create abstract base class Transaction with abstract responsibility “execute a financial transaction”
Implement responsibility differently for each subclass
Do not marry one solution. Play the field first.
Remember CRC cards are inexpensive and erasable!!
Experiment with different configurations of classes and assignments of responsibilities
Change CRC cards early to avoid changing code later
|
|
Identify relationships among classes
Pair collaborations with responsibilities on CRC card
Use scenario-based role-play to find/test collaborations
Add collaborations when relationships found
Identify clients and servers
Server -- class that provides a resource
Client -- class that uses a resource
Server is collaborator of client, not vice versa
ATM example: In Withdrawal operation, Account is server for Withdrawal client
Identify hierarchies of classes
ATM example: Transaction as superclass of Withdrawal, Deposit, etc.
Explore is-a (“kind-of”) relationships (possible inheritance)
ATM – Withdrawal is a (“kind of”) Transaction
ATM – Withdrawal is not “part of” Transaction
Name key abstractions
Separate mixed classes where necessary
Place super/subclass sets in hierarchies
Look for reusable behaviors
Create a list of scenarios for use of system (i.e. use cases, user stories, actions to realize requirement)
Use brainstorming
ATM example: customer withdraws cash
Assign roles of classes to team members
Each member has one or more classes
Rehearse the scenario
Execute scenario with team members announcing what affected classes are doing -- putting cards into play when used
Correct CRC card and revise scenario
Repeat above two steps as necessary until rehearsal smooth
Perform final scenario
Concentrate on “must do” scenarios
Core behaviors touch central features of system
ATM example: customer withdraws cash
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
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
If larger than 25 scenarios in “must do” and “can do if” categories, break into subsystems
Stick to the scenario(s)
Limit session time ( <= 2 hours )
Use conscious, deliberate problem-solving activities
Use conscious, deliberate problem-solving activities
Warm-up time never wasted
Warm-up every session
Inspire confidence of all team members, especially for new or changed teams
Don’t get too serious too fast
Identify and summarize scenarios to be enacted (agenda)
Assign roles to actors
Initiate scenario -- hold up first class
Proceed from responsibility to its collaborators
Watch action to detect problems
When errors discovered
Avoid unnecessary changes, especially after considerable role play
Do enactment-assessment on multiple scenarios per session
“Go-around” comments
Identify problem points
Create problem-solving priority list
Change or confirm CRC cards
Identify any scenarios that need to be repeated
Use similar analysis techniques to build broader model of domain concepts
Use similar Scope-Commonality-Variability (SCV) analysis [Coplien 1998] to design software families (frameworks, product lines)
encapsulate variabilities to allow customization
Use SCV analysis in design of domain-specific language (DSL) syntax and semantics
Introduced CRC cards – lightweight, informal
Discussed how to use them in OO analysis and design
Examined how to use them in teams