1
|
- Session 8
- LBSC 790 / INFM 718B
- Building the Human-Computer Interface
|
2
|
- Questions
- Some useful data structures
- Rapid prototyping
|
3
|
- 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
|
4
|
- 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
|
5
|
- 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
|
6
|
- 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
|
7
|
|
8
|
- 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
|
9
|
|
10
|
- Linked list with multiple next elements
- Just as easy to create as linked lists
- Binary trees are useful for relationships like “<“=
li>
- 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
|
11
|
|
12
|
- Resizable array [O(n) insertion, O(1) access]:
- Linked list [O(1) insertion, O(n) access, sorted]:
- 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)
|
13
|
- 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
|
14
|
- 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
|
15
|
- 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
|
16
|
- Maintain an implicit order
- Easy additions and deletions
- Maps naturally to certain problems
- Interrupt a task to compute an intermediate value
- Implemented as a Java class
|
17
|
- 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?
|
18
|
- Plan on 6 hours per person per week after that
- Go through three prototype iterations
- 2 weeks each (=3D36 person-hours to design/code/test)
- Make a presentation during the final class session
|
19
|
- 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
|
20
|
|
21
|
- Quality
- Build systems that satisfy the real requirements by focusing on
requirements discovery
- Affordability
- Minimize development costs by building the right thing the first ti=
me
- Schedule
- Minimize schedule risk by reducing the chance of requirements disco=
very
during coding
|
22
|
- Attributes
- Appearance
- Concepts (represented by data)
- Behavior
- What it does
- How you control it
- How you observe the results
|
23
|
- 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)
|
24
|
|
25
|
- 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
|
26
|
- Functional View
- Use case diagram, narrative, scenarios
- Static view
- Class diagram, object diagram
- Dynamic view
- Sequence diagram, collaboration diagram
|
27
|
- Easily built (“about a week’s work”)
- Insightful
- Basis for gaining experience
- Well-chosen focus (DON’T built it all at once!)
- Easily modified
- Facilitates incremental exploration
|
28
|
- 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
|
29
|
- 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
|
30
|
- 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
|
31
|
- 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
|
32
|
- 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
|
33
|
- 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.
|