CSC323 2010S, Class 07: Analysis

Overview:
* Lecture: Dealing with Readings
* BC 30: When A Button Is All That Connects You To The World.
* Object-Oriented Analysis, The Head-First Approach.
* Putting The Two Together.

Admin:
* Cupcakes!
* Surprise!  It's bad writing day in CSC 323.  The primary question: 
  How do you learn from things that don't have a clear point?
* EC for CS Table Friday.
* EC for Rosenfield Symposium this week.
* Readings for next class: HFOOAD 5 (both parts) and BC 31.
* Volunteers needed: Help Nora teach 151 at 10am tomorrow.

Dealing with Readings That You Don't Like
* A bad solution: Snark
* A better solution: Figure out what you can gain from the reading
  Figure out what the author's point is
* It should always be possible to come up with good comments on program
  design

BC 30: When A Button Is All That Connects You To The World
* What is beautiful in this chapter?
  * The problem itself: A radically different UI problem
  * The approach to the problem: Use the button to navigate through a tree
    * Automatic scroll through children
    * Long click for context menu
  * The success in building something that works with one button
  * A *very* customizable UI: The structure of the system is stored
    in editable text files with an easy-to-understand format
  * Selection (within the problem domain)
  * "Intelligence" in the system
  * Template sentences - a clever idea, not just for those who are
    impaired.
* What can I learn from the chapter, even if I find the code ugly?
  * When UIs are a key part of what you're doing, a language that makes
    it easy to prototype and change UI's is helpful.
  * Remember the end user!  (And talk to the end user.)
  * Code that works is beautiful, even if it's ugly. [Not true in your
    classes.]
  * Pay attention to restrictions.
  * Be careful about your need to innovate
    * Think about what other people have done
* If you're going to write about your software, you have a responsibility
  to keep the stuff you write about available.

Wikipedia: Can you cite it?
* High school history teachers don't let you (many College teachers don't, either)
* Why can this author do so?

* Okay in this case, because the author knows the definition is right. 
  (Author should provide a date, so that you can go back in the change
  log and see the version he chooses.)
* The things that are being cited are not controversial, and therefore
  unlikely to change.
* But, in the end, you've seen that using Wikipedia as a source undermines
  your authority as an author.

Head First OO Analysis
* What is analysis? Figuring out the main classes and methods of the
  application.
* What did we do in the chapter?
  * Altered code to meet use cases.
  * Considered the real-world context of the application.
  * Translated use cases to objects and methods (circle the nouns)
* What did we not do in this chapter?
  * Come up with examples that make sense
* What are the primary points of the chapter?
  * Use cases can be very helpful in thinking about design.
  * If a preliminary design seems to be causing problems, maybe
    you should change that original design, rather than patching 
    around it again and again.
  * Make sure that you learn about your domain!
  * Make sure that you think about similar issues.  (Hmm ... other
    people use RFID tags for their doggie doors, maybe we shouldn't
    pay attention to barks.)
  * Reinforce loose coupling - A class should do its own comparisons.
  * New UML syntax: When you need to have a many-one relationship.

Challenge: The "barks let dogs in" technique failed.  Design a new
system: New use case, new requirements, new classes.  You may use RFID.  
You have ten minutes to get started.

Use Cases (overview):
* Go outside (actors: Cat, Owner)
* Lost collar (actor: Owner)
* Remove permission (actor: Owner)
* Add permission (actor: Owner)
* Disable unlocking mechanism (actor: Owner)
* Enable unlocking mechanism (actor: Owner)

Use Cases (detailed):

  Use Case: Cat Goes Through Enabled Door
  Initiator: Cat
  1. Owner's cat walks up to cat door []
  2. RFID receiver detects tag in owner's cat's collar [D,F]
  3. RFID validates tag [I]
  4. Cat door unlocks [A]
  5. Cat goes through cat door [C,E]
  6. Cat leaves range of RFID receiver []
  7. Cat door locks [B]

  Use Case: Cat Tries to Go Through Disabled Door
  Initiator: Cat
  1. Owner's cat walks up to cat door []
  2. RFID receiver is disabled.  Nothing happens. [H]
  3. Cat tries to go through cat door and fails. [J]
  4. Cat remains inside/outside. []

  Use Case: Cat Goes Through Disabled Door
  Initiator: Cat
  1. Owner's cat walks up to cat door []
  2. RFID receiver is disabled.  Nothing happens. [H]
  3. Cat tries to go through cat door and fails. []
  4. Owner hears "clunk". []
     4.1. Owner doesn't hear clunk.
     4.2. Cat finds owner.
     4.3. Cat claws owner.
  5. Owner presses button on remote. [_]
  6. RFID is temporarily enabled.
  7. Use case 1 is followed.
  8. RFID becomes reenabled.
 
Requirements:
A. While an acceptable RFID tag is within range of the receiver, 
   the door is unlocked.
B. When no acceptable RFID tag is within range of the receiver,
   the door is locked.
C. Doors have flaps that cats can push.
D. The cat has an attached RFID tag.
E. Physical requirements of the cat door.
F. Range of RFID tag is "reasonable" (between 1 and 3 feet)
G. RFID tag is waterproof.
H. Owner must be able to enable/disable RFID reader.
I. The system can validate RFID tags.
J. Cat Door Lock is stronger than Cat.

Classes and relationships: