Data Structures
Session 8
LBSC 790 / INFM 718B
Building the Human-Computer Interface
Agenda
•	Questions

•	Some useful data structures

•	Rapid prototyping
What’s Wrong With Arrays?
•	Must specify maximum size when declared
–	And the maximum possible size is always used
•	Can only index with integers
–	For efficiency they must be densely packed
•	Adding new elements is costly
–	If the elements are stored in order
•	Every element must be the same type
What’s Good About Arrays?
•	Can get any element quickly
–	If you know what position it is in
•	Natural data structure to use with a loop
–	Do the same thing to different data
•	Efficiently uses memory
–	If the array is densely packed
•	Naturally encodes an order among elements
Linked Lists
•	A way of making variable length arrays
–	In which insertions and deletions are easy
•	Very easy to do in Java
•	But nothing comes for free
–	Finding an element can be slow
–	Extra space is needed for the links
–	There is more complexity to keep track of
Making a Linked List
•	In Java, all objects are accessed by reference
–	Object variables store the location of the object
•	New instances must be explicitly constructed
•	Add reference to next element in each object
–	Handy to also have a reference to the prior one
•	Keep a reference to the first object
–	And then walk down the list using a loop
Linked List Example
Linked List Operations
•	Add an element
–	Easy to put it in sorted order
•	Examine every element
–	Just as fast as using an array
•	Find just one element
–	May be as slow as examining every element
•	Delete an element after you find it
–	Fast if you keep both next and prior links
Linked List Insertion
Trees
•	Linked list with multiple next elements
–	Just as easy to create as linked lists
–	Binary trees are useful for relationships like “<“
•	Insertions and deletions are easy
•	Useful for fast searching of large collections
–	But only if the tree is balanced
•	Efficiently balancing trees is complex, but possible
Binary Tree Example
Data Structures in Java
•	Resizable array [O(n) insertion, O(1) access]: 
–	ArrayList
•	Linked list [O(1) insertion, O(n) access, sorted]: 
–	LinkedList
•	Hash table [object index, unsorted, O(1)]: 
–	HashSet (key only)
–	HashMap (key+value)
•	Balanced Tree [object index, sorted, O(log n)]:
–	TreeSet (key only)
–	TreeMap (key+value)
Hashtables
•	Find an element nearly as fast as in an array
–	With easy insertion and deletion
–	But without the ability to keep things in order
•	Fairly complex to implement
–	But Java defines a class to make it simple
•	Helpful to understand how it works
–	“One size fits all” approaches are inefficient
How Hashtables Work
•	Create an array with enough room
–	It helps a lot to guess the right size first
•	Choose a variable in each object as the key
–	But it doesn’t need to be an integer
•	Choose a spot in the array for each key value
–	Using a fast mathematical function
–	Best if things are scattered around well
•	Choose how to handle multiple keys at one spot
Java HashMap Class
•	Hashtables are objects like any other
–	import java.util.*
–	Must be declared and instantiated
•	The constructor optionally takes a size parameter
•	put(key, value) adds an element
•	containsKey(key) checks for an element
•	get(key) returns the “value” object for that key
Stacks
•	Maintain an implicit order
–	Last In-First Out (LIFO)
•	Easy additions and deletions
–	push and pop operations
•	Maps naturally to certain problems
–	Interrupt a task to compute an intermediate value
•	Implemented as a Java class
–	import java.util.*
Choosing a Data Structure
•	What operations do you need to perform?
–	Reading every element is typically easy
–	Other things depend on the representation
•	Hashing finds single elements quickly
–	But cannot preserve order 
•	Stacks and linked lists preserve order easily
–	But they can only read one element at any time
•	Balanced trees are best when you need both
•	Which operations dominate the processing?
Project
•	Plan on 6 hours per person per week after that

•	Go through three prototype iterations
–	2 weeks each (=36 person-hours to design/code/test)

•	Make a presentation during the final class session
The Rapid Prototyping Model
•	Goal: explore requirements
–	Without building the complete product
•	Start with part of the functionality
–	That will (hopefully) yield significant insight
•	Build a prototype
–	Focus on core functionality, not in efficiency
•	Use the prototype to refine the requirements
•	Repeat the process, expanding functionality
Rapid Prototyping + Waterfall
Objectives of Rapid Prototyping
•	Quality
–	Build systems that satisfy the real requirements by focusing on requirements discovery
•	Affordability
–	Minimize development costs by building the right thing the first time
•	Schedule
–	Minimize schedule risk by reducing the chance of requirements discovery during coding
What are Requirements?
•	Attributes
–	Appearance
–	Concepts (represented by data)

•	Behavior
–	What it does
–	How you control it
–	How you observe the results
Who Sets the Requirements?
•	People who need the task done (customers)

•	People that will operate the system (users)

•	People who use the system’s outputs

•	People who provide the system’s inputs

•	Whoever pays for it (requirements commissioner)
The Rapid Prototyping Cycle
The Requirements Interview
•	Focus the discussion on the task
–	Look for objects that are mentioned
•	Discuss the system’s most important effects
–	Displays, reports, data storage, device control, …
•	Learn where the system’s inputs come from
–	People, stored data, devices, …  
•	Note any data that is mentioned
–	Try to understand the structure of the data
•	Shoot for the big picture, not every detail
The Specification
•	Functional View
–	Use case diagram, narrative, scenarios

•	Static view
–	Class diagram, object diagram

•	Dynamic view
–	Sequence diagram, collaboration diagram  
Characteristics of Good Prototypes
•	Easily built (“about a week’s work”)
–	Intentionally incomplete
•	Insightful
–	Basis for gaining experience
–	Well-chosen focus (DON’T built it all at once!)
•	Easily modified
–	Facilitates incremental exploration
Prototype Demonstration
•	Choose a scenario based on the task
•	Develop a one-hour script
–	Focus on newly implemented requirements
•	See if it behaves as desired
–	The user’s view of correctness
•	Solicit suggestions for additional capabilities
–	And capabilities that should be removed
A Disciplined Process
•	Agree on a project plan
–	To establish shared expectations
•	Start with a requirements document
–	That specifies only bedrock requirements
•	Build a prototype and try it out
–	Informal, focused on users -- not developers
•	Document the new requirements
•	Repeat, expanding functionality in small steps
The Project Plan
•	One-page written contract 
–	Between developer and requirements commissioner

•	Goal 	The problem to be solved
•	Product	What you plan to deliver
•	Scope	Available time and personnel
•	Method	How your rapid prototyping works
•	Roles	What you expect each other to do
Requirements Approval
•	Plan on between 12 and 50 iterations
–	For the class project, you’ll do only the first 3
–	Adding about 10 new objects per iteration

•	Use the project plan to enforce a deadline
–	New requirements shrink, but never disappear

•	Schedule a formal approval demonstration
–	Allow one more iteration to fix any problems
What is NOT Rapid Prototyping?
•	Focusing only on appearance
–	Behavior is a key aspect of requirements
•	Just building capabilities one at a time
–	User involvement is the reason for prototyping
•	Building a bulletproof prototype
–	Which may do the wrong thing very well
•	Discovering requirements you can’t directly use
–	More efficient to align prototyping with coding
Muddiest Point
On a blank sheet of paper, write a
single sentence that will convey
to me what you found to be the
most confusing thing that was
discussed during today’s class.