CSCI E-70
Harvard University Extension School

Spring 2003

Graphical User Interface Programming in Java

Lecture notes 5

26 Feb 2003

  1. Threads
  2. Definition and Motivation
  3. execution context
  4. independent stack
  5. location in code (program counter)
  6. may be more fine grained than you think
  7. Java Classes and Interfaces
  8. java.lang.Thread object
  9. java.lang.Runnable interface
  10. subclass thread or use Runnable?
  11. using
  12. start
  13. ending: flagging, interrupting, joining
  14. timing: sleep, getting System time
  15. Image buffering
  16. Definition and Motivation
  17. paint onto off-screen (in-memory only) region
  18. reusable for later – faster performance
  19. free up AWT thread – better interactivity
  20. Java Classes and Interfaces
  21. java.awt.image.BufferedImage
  22. usual suspects: Graphics2D, AffineTransform
  23. Design Issues
  24. Textual refactoring
  25. Life Demo Button subclassing
  26. Differentiating & Layering models
  27. identifying orthogonal models
  28. JList: selection versus actual items
  29. more Swing examples to come (JTree/Table)
  30. CellLife/Map: display versus editing/controlling
  31. identifying subordinate relationships
  32. master model(s) contain(s) full application state
  33. generally built at program start-up
  34. subordinate Swing models fed by masters
  35. proxy object that delegates
  36. master model implements multiple interfaces
  37. synchronization made easy
  38. event propagates up to proper model
  39. automatically fans out and down to all listeners
  40. the more complex the app, the bigger the model hierarchy
  41. Semantic events
  42. Creating/deriving event class
  43. Creating/deriving listener interfaces
  44. Interested party registers self in constructor
  45. Often needs model for queries anyway
  46. caller can’t forget: must pass model in constructor
  47. Creating/Propagating events
  48. Mouse events
  49. In-place
  50. MouseListener methods: click, press, release
  51. MouseEvent properties: x, y, source
  52. MouseMotionEvent: move, drag
  53. handling state
  54. mapping to your objects
  55. Javadoc
  56. class level
  57. function level
  58. tags
  59. running javadoc
  60. official spec
  61. UML
  62. description/motivation
  63. language-independent software system specification
  64. visual rep good for same reason GUIs are good: visual!
  65. although: some people more verbal, may need written spec
  66. scales well: can describe system at any level of detail
  67. survives as programmers, languages, management change
  68. actively researched & industry-suppprted language
  69. the right drawing board: not a blank one
  70. check implementation changes against UML: consistent?
  71. avoid going back to square one when module design fails
  72. good first step
  73. make project managers happy (they love diagrams)
  74. can auto-generate skeletal code from sufficiently detailed UML
  75. “official” specification
  76. take with grain of salt: develop what makes sense to you/your team
  77. I don’t care about precise iconography (open arrows/opaque arrows)
  78. make a good legend, use consistent conventions
  79. inheritance diagrams: class level analysis
  80. also called Class Diagrams (type I of Static Structure Diagrams)
  81. who extends/ implements whom
  82. determinable from class declarations only
  83. what are the “things” in my code that get operated on?
  84. entity diagrams: instance-level analysis
  85. also called Object Diagrams (type II of Static Structure Diagrams)
  86. largely determined by instance variable declarations, method headers
  87. who creates whom
  88. who contains whom: composition/aggregation
  89. multiplicity: how many instances of Y per X
  90. 1: X may be entire app (i.e. Y is a singleton)
  91. 1: X may be a node (i.e. Y is a property)
  92. many (0..*): X may be a growable list (i.e. Y is a link)
  93. possibly: who communicates with whom (esp. at network nodes level)
  94. flow diagrams: method level analysis
  95. also called Sequence Diagrams
  96. determined by method bodies: low level
  97. hence: must be selective about salient flows
  98. nested for-loop that paints grid from model too obvious
  99. focus on runtime propagations through more than 2 methods
  100. flow should be a represent a semantic event: user visible
  101. shows “how it works”
  102. event handling
  103. trace user input to stable result
  104. trace network or timer event to update
  105. can abstract out underlying libraries’ flows
  106. format like flow chart but exclude non-method call logic
  107. flowchart: statement level analysis
  108. also called deployment diagrams (type II of Implementation Diagrams)
  109. determined by method statements: lowest level
  110. use to explicate complex algorithms
  111. show every state variable update
  112. show every decision point
  113. essentially diagrammatic pseudocode
  114. some find visual organization helpful, others don’t

Find-Best Pseudocode

Base Case 1:failure (or loop prevention)

point already in this traversal → RETURN

Base Case 2:success (or possible solution)

if this solution better than best known solution:

update best known rating (rating of this one)

update best known path (this path; careful to clone it)

RETURN

Recursive Case:

mark this point as traversed

for every point in reachable neighbors:

try adding point to path

update the current cost of path

RECURSE on that point

perform backtracking clean-up:

subtract the cost

remove the point

unmark this point (allow other superior traversals to go through it)

– Page 1 of 6 –