Events

1
CSC 335 Object-Oriented Programming and Design
Presentation 12 Analysis, Design, Artifacts, CRC
Cards, Role Play
2
Summing Up, Coming Up

• Summing Up
• Discussed all the Java you need to complete
  current project
• You have made progress in a rational manner
• Coming Up
• New specification, example of what each team will
  need in the final project
• OO Analysis
• Actors, use case diagram, detailed uses cases
• OO Design
• CRC cards, Class Diagram

3
Object-Oriented Analysis and Design

• Object-oriented (OO) analysis can begin by
• identifying objects (the initial list of objects)
• identifying actors
• identifying uses case
• writing system sequence diagrams
• Object-Oriented Design can include
• CRC card development through role play
• writing a class diagram to represent a model (the
  architecture) of the system

4
Object-Oriented Software Development

• In the context of the "Cashless Jukebox"
• Given a new problem specification, find the
  objects (an initial list)
• Find actors uses cases, draw use case diagram
• Write a use case
• Assign responsibilities to objects through role
  play while developing CRC cards
• Write a UML class diagram to represent the
  architecture of the system (static, not dynamic)

5
A New Problem Specification

• The student affairs office has decided to put
  some newfound activity fee funds toward a music
  Jukebox in the student center. The Jukebox will
  allow a student to play individual songs.
• No money will be required. Instead, a student
  will swipe a magnetic ID card through a card
  reader. Students will each be allowed to play up
  to 1500 minutes worth of "free" Jukebox music in
  their academic careers at the school, but never
  more than two selections on any given date.
• A student may select a CD from the available
  collection of CDs and then an individual song
  from that CD. Students may not play entire CDs.

6
Find the Objects An initial list

• Candidate objects may come from
• the problem statement
• an understanding of the problem domain
• knowledge of the system that the problem spec.
  may have missed or taken for granted
• the words floating around the room while
  analyzing the problem
• Object-Oriented Design Guideline
• Model the real world whenever possible

7
The Noun Phrases

• student affairs office
• activity fee funds
• music Jukebox
• money
• student center
• student
• student ID card
• card reader

• song
• minutes
• Jukebox music
• academic careers
• date
• selection
• CD
• collection of CDs

8
Candidate Objects required artifact

• Jukebox
• Student
• Song
• Card reader
• Student ID card
• CD
• Collection of CDs
• Top-10 list

9
Yesses

• Jukebox coordinates activities (a Mediator
  maybe)
• one instance to start things and keep them going
• Student maintains one student account
• the software version of the user that selects
• CdTrack data concerning one song on a CD
• CardReader reads the magnetic ID card

10
A No

• StudentIdCard store user data
• Object-Oriented Design Heuristic
• Eliminate classes that are outside the system
• The hallmark of such a class is one whose only
  importance to the system is the data contained in
  it.
• Student identification number is of great
  importance
• The system should not care whether the ID number
  was read from a swiped magnetic ID card, typed in
  at the keyboard, or "if a squirrel arrived
  carrying it in his mouth" Arthur Reil

11
More Candidate Objects

• CD store a collection of songs
• CdCollection stores a collection of CDs
• What about a collection of accounts?
• JukeBoxAccountCollectionstore user accounts
• What about a compact disk player?
• CdPlayer plays the songs
• could have a software equivalent to hide details

12
Another No?

• StereoSystem Amplifies the music
• No, it's on the other side of the physical
  cdPlayer
• The next slide summarizes the major classes and
  sets the boundaries of the system

13
The candidate objects, and the system boundary
CardReader Gets student ID
JukeboxAccountCollection Stores all
JukeboxAccount objects
JukeboxAccount
JukeBox Coordinates activities
CdCollection Stores all CDs that can be played
CD
CdPlayer Plays a song
CdTrack
14
Identify Actors

• An actor
• Is external to the system
• often stimulates the system with input events or
  receives something from it
• Types of actors include
• The roles that humans play (almost always a user)
• A mediator (an object that coordinates activities
  to represent the system itself)
• Electrical or mechanical devices

15
Actors required artifact

• Actors may be human or could be hardware
• In the Cashless Jukebox
• Student (the user)
• JukeBox
• Stereo System

UML icon for an actor
Student
16
Uses Cases Describing Processes

• Use Cases aid in
• understanding the requirements
• moving from requirements to conceptual model
• You need to understand requirements a bit to
  develop uses cases
• Use cases are tied to "what" a system is to be
  able to do in response to an outside "actor" such
  as Jukebox or Student

17
Finding Use Cases

• Identifying uses cases and the involved actors
• Think about how actors are related to the system
• Identify the processes the actor will participate
  in
• Identify external events that a system must
  respond to
• Relate the events to the actors and uses cases

18
Actors and Use cases

• Some possible actors and the uses cases they are
  involved in
• Jukebox
• Login
• Play a song
• Student
• Select a song
• Stereo System
• Play a song

19
Use Case Diagram required artifact

• Use case diagrams illustrate a set of use cases
  for a system
• Gives overview of how actors interact with the
  system

Registrar
Jukebox
Login
Student
Play a Song
Select a Song
Stereo System
20
Writing Use Cases

• Use cases imply concepts, associations, and
  functionality in the conceptual model and system
  behavior model -- they tell stories
• Each use case has a
• Name
• Actors outside the system
• Type primary, secondary, or optional
• Narrative description of domain processes

21
A High Level (little detail) Use Case

• Use case Login
• Actors Student, Jukebox, Registrar
• Type Primary primary type means a common major
  process
• Description A student arrives at the jukebox
  with a Catcard and swipes it. The Jukebox
  verifies
• the student is valid and reports to the user
  it login was successful

22
Expanded Use Cases required artifact

• Expanded use cases have more detail such as
• Purpose
• Cross references to requirements
• Typical Course of Events
• Conversational style narrative now with both
  actor actions and corresponding system responses
• Alternative courses of events that are less
  typical and will occur in response to particular
  line numbers with the typical case (may generate
  error message)
• For examples, see uses cases from Rational handed
  out earlier

23
Typical Course of Events

• Typical course of events
• is the bulk of an expanded use case
• includes numbered actions of the actor
• includes numbered actions of the system response
• does not describe the anomalies
• it describes the typical case
• Alternative actions are described at end

24
System Sequence Diagram

• How do actors interact with the system
  dynamically?
• The sequence of events be captured with a system
  sequence diagram (more UML)
• List Actors at top
• Show interactions as line between actors

25
Play a Song required artifact

• Sequence Diagram for use case Play a Song

Jukebox
Stereo System
Student
1. login
2. show options
3. request play song
4. show all songs
5. Choose a song
6. Play the song
26
From Analysis to Design

• We have the big picture
• Now lets decide
• What objects are responsible for
• What objects should remember
• What object should do

27
CRC card Development through role play

• While the team is acting out scenarios
• determine what each class is responsible for
• understand the system
• develop documentation to capture analysis and
  design decisions
• develop algorithms

28
CRC cards

• Component/Responsibility/collaborator cards
• could be a piece of paper or a 3"x5" index card
• contains information about the classes identified
  as potential parts of a solution
• class name
• action responsibilities
• knowledge responsibilities
• collaborators (classes that help the class do
  its thing)

29
A CRC Card

• The front of a CRC card looks like this

30
Summary of CRC cards
31
Role Playing

• Role playing
• involves a team working together
• has team members pretending they are objects
• has team members acting out scenarios
• A scenario is he answer to the question "What
  happens when?"
• Two alternatives now in class
• Volunteers to dynamically do role play (fun)
• Volunteers to read the next few slides (boring)

32
Role Play a Scenario

• Scenario What happens when a student, with a
  valid account, wants to select a song?
• Jukebox I'm playing the role of the Jukebox so
  I'll start this scenario. Hey CardReader, has a
  user swiped a card?
• CardReader No
• JukeBox Hmmm, okay CardReader, has a student
  swiped a card?
• CardReader No
• JukeBox Hey, how often do I have to do this? I
  suppose I'll have to wait for a user. Okay, I'm
  waiting for a user. waiting, waiting ...
• CardReader Okay JukeBox, a user just swiped a
  card. Here is all the information on that
  magnetic strip ID card.
• JukeBox Thanks CardReader, but I don't know what
  to do with all of this stuff. What part of the
  input uniquely identifies the student?

33

• Jukebox Let me summarize I won't try to get the
  user's song selection. I know that I will somehow
  have access to the CD collection, but what has to
  happen now? What should I do next to get the
  selection?
• After some discussion, the team adds
  CdTrackSelector
• Jukebox Since I have access to the collection of
  all CDs. I'll pass it to CdTrackSelector. You
  tell me what song the user wants to hear.
• CdTrackSelector Okay, I'll communicate with the
  user and return the CdTrack. I'll add getTrack
  to my CRC card.
• ... Skip the scenario with cdCollection, CD,
  CdTrack, CdTrackSelector ...
• Jukebox Okay, now I should check to make sure
  the student is able to select this CdTrack before
  telling the CdPlayer to play it. I seem to
  remember I just can not simply play a CdTrack
  without checking on a few things. I know the
  current student and the selected CdTrack. What do
  I do now?

34
Alternative 1 Jukebox So tell me CdTrack, how
many minutes and seconds do you require to be
played? CdTrack 3 minutes and 34
seconds. Jukebox student, do you have 3 minutes
and 34 seconds credit? student I'll be
responsible for maintaining my remaining time
credit (he adds this to his CRC card), so I can
answer that, Yes, I have enough credit. Jukebox
student, have you played fewer than 2 CdTracks on
this date? student Yes, I have not played 2
songs on this date. Jukebox Okay, now we can
play the CdTrack. Here it is CdPlayer. cdPlayer
Okay Jukebox, I would be willing to tell the
physical CD player to play this CdTrack.
Actually, I have no idea how I am going to do
that, but I'll write a playTrack responsibility
on my CRC card for now as long as you send me the
CdTrack to be played during a playTrack message.
35

• Alternative 2
• Jukebox student, can you play this CdTrack?
• student It feel as though I should be
  responsible for maintaining my own time credit,
  it seems appropriate that I should also know how
  many CdTracks I've played today. So I should be
  able to do some simple calculations to give you
  the answer you seek. Yes Jukebox, I can play the
  CdTrack you sent me. I'll add these
  responsibilities to my CRC card
• know how much time credit I have left
• know how many CdTracks I've played on this date
• respond to a message like this
  currentUser.canSelect(currentTrack)

36
When does it end?

• Continue role-playing scenarios that have no
  exceptional behavior
• Then role-play the unusual cases
• student has no time credit
• want to change CDs
• student has been kicked out of the university

37
Problems with the process and suggestions

• Problem Getting too low level too quickly
• Solutions
• dont do tricky scenarios first
• do design before implementation
• focus on what, not how
• Problem Staying too high level too long
• do scenarios

38
Problems and Solutions

• Problem Team has difficulty agreeing
• deal with diversity
• summarize (marks point of disagreement)
• decide if you are just arguing about the name of
  something this can
• Problem Feel like you could use some help
• get an independent facilitator someone not on
  the team
• good design comes from experience, experience
  comes from bad design Fred Brooks

39
CRC Cards capture many design decisionsrequired
artifacts
40
CardReader
41
JukeBoxAccount
42
JukeBoxAccountCollection
43
CdTrack
44
Object-Oriented Design Heuristics that come up
during this activity

• Eliminate classes that are outside the system
• All data should be hidden within its class
• Keep related data and behavior in one place
• Model the real world whenever possible
• Avoid all-powerful (omnipotent or god-like)
  classes

45
More OO Design Heuristics

• Distribute system intelligence among the classes
  as evenly as possible. The top-level classes in a
  design should share the work uniformly.
• Minimize the number of message sends between a
  class and its collaborator

46
CdPlayer
47
TrackSelector
48
PlayList? would be useful in a simulation, you
wouldn't need the physical components