CSC323 2010S, Class 22: The OOA&D Lifecycle

Overview:
* New groups
* The OOA&D Lifecycle.
* Dijkstra's Shortest Path Algorithm.
* Subways.
* Reflecting on Head-First.
* Project/CRC cards.
* Code reading.  (If time.)

Admin:
* Extra credit for today's CS extra.
* Extra credit for tomorrow's CS table.
* Reading for Tuesday: Ch. 1 of Design Patterns (to be distributed).
* Shoot for another nine hours of work by next Thursday.
* I'll pay $10 for any hardcopy books from this class that you want to 
  get rid of (except for the Python pocket reference)

New Groups
* UI: Nora & Josh & Jordan & Aaron
* Network: Ravi & Terian & Nathan & Dylan
* World: Jesse & Jeff & Alex & Dennis

OOA&D Lifecycle
* Feature List
  * Purpose: Gives you an idea of what you want your program to accomplish.
  * Process: You write it down. Negotiated with client: An attempt by 
    the designer to summarize the needs of the client
* Use Case Diagrams
  * Decomposition of program into primary actors and primary actions
  * Form: Little stick figures connected to bubbles that represent
    their actions
    * These actions are potentially the use cases, but we may not
      have written them in detail
  * Construction: Think about it (reflecting on feature list), Talk to 
    customer
  * Uses: 
    * Helps think about the features in ways that are closer to the code
    * Provides a framework for checking that we've thought about all of
      the features
    * Gives you something to show to clients 
      * "I've written an architecture for your system.  Give me the first 20%"
      * "And look, you can even understand it."
    * Helps you divide up the features between teams.
  * Use Cases (the stories from early in the book)
    * Offer a scenario that describes the things your program is going to do
* Decompose the Problem into Smaller Problems
  * What? You end up with smaller problems, each with more restricted
    functionality
  * How? The use case diagram provides a start.  Might also decompose
    based on actors or features.  Customer not necessary, since the
    decomposition should not be relevant.
  * Why? Allows us to work on one part at a time, which is easier to
    test (and probably easier to think about).  Encourages us to think
    in more details about each part.  Allows us to break up the project.
* Requirements
  * What?  Something that needs to be met in order to make a feature work.
  * How? Consult with client.  Reflect/think.  Use cases help us think
    about these!
  * Why? Gives us criteria for building our software / a starting point
    for any code.  A checklist for when we're done.  A checklist to make
    sure we're meeting the needs of our use cases.  Another chance to
    talk to the client.  Helps us think about how the parts of the
    project interrelate.
* Domain Analysis
  * What? A mechanism for turning our use cases into classes.
  * How? Go through your use cases, identifying nouns and verbs
  * Why? So that you have classes
* Preliminary Design
  * What? UML diagram ; relationships between classes
  * How? Think about the results of the domain analysis.  Formalize.
    No client necessary.
  * Why? Lets us start coding!  Lets us break up the work.  Lets us
    make sure we understand the relationship of parts.
* Implement
  * What?  Write code.
  * How? Draw upon your knowledge, experience, and other resources (e.g., Wikipedia) to turn the needs of each class into working code. 
  * Why? In the end, this is the thing that the customer wants.
* Deliver
  * What? Finish the thing and give it to them.
  * How? (Negotiated with customer.)
  * Why? To get paid.  To have a sense of satisfaction.

* Iterate!
  * Requirements through implementation (done on each module)
* Why not iterate through other parts?
  * You shouldn't need to break up the problem more than once, so nothing before then is necessary.
  * Your customer might object to multiple deliveries, so Delivery is done once

* One hidden step: Understand the Problem!
  * After "break up the problem"
  * Before "Requirements"
* Why there?
  * Maybe they just mean "Understand the subproblem"
  * You need to do so at some time.
  * You may not be able to understand the problem until you've done some of the other work.
* Is it iterated?
  * Maybe.  Then you could understand each module before trying to
    R/DA/PD/I it.

Dijkstra's Shortest Path Algorithm
* Problem: Given a graph (can be directed, can be weighted), and two points (often designated source and sink), find the shortest path from source to sink
* Output: Shortest path from source to sink (or cost of the shortest path)

Dijstra's strategy: Find the shortest path from source to *every node* in the graph
* Keep track of:
  Known: Nodes to which we know the shortest path
  Predecessors: The predecessors to the nodes in known
  Reachable: Nodes to which we know some path x the cost to get to those nodes

* Initialization
  * Known = empty
  * Predecessors = empty
  * Reacable = source (cost of 0)
* At each step
  * Find the node in Reachable which has the lowest cost.
  * Remove that from Reachable
  * Add it to Known
  * Compute the cost to each of its neighbors and update Reachable

Simplifications: 
* If you don't have weighted edges, the "distance" is always 1, and you can just count neighbor steps
* If you want to save a little time, you can stop when you find the distance to sink.

Question: Can we talk about how the different parts of the system
interact?  Who is in charge of everything?

* Two "main" classes
  * One for local play
  * One for networked play
* Local play

Main
* s = speciesdatabase.get()
* s.loadFile(___)
* prompt = new SetupGUI()
  * speciesdatabase.get().allSpeciesNames()
* (width,height,speciesName) = prompt.runSetup()
* w = new LocalWorld(width, height, s.getSpecies(speciesName))
* gui = new WorldGUI(w)


SpeciesDatabase should be a singleton class
* You can get the species database with
  speciesdatabase.get()