COMP290%20Project:%20Team%20B

1
COMP290 Project Team B

• Yuanxin Lui
• Nguyen-Tuong Long Le
• Phil Holman
• Yongjik Kim
• Andrew Nashel
• Stephan Sherman (AWOL)

2
Overview

• The presentation will consist of 3 parts
• Project design
• Demo of the product
• Comments on the development process

3
Part 1 Design
Status Window
Sequence Window
3PB Tracker
Data Feed
Primary UI Window
Adaptor
Cache
4
Application Structure

• Our design is primarily event-driven.
• Three types of events drive the system
• 1. User changes the stock.
• 2. User changes the time frame.
• 3. Data is received from the TOS server.

5
Event Example
When a new TOS arrives at the Adaptor (1), it is
checked to determine whether it is needed. If so,
the TOS is passed to the Data Feed (2), which
then caches it (3) and updates the Status Window
(4). If the TOS is the last in the current time
frame, it is passed to the Tracker (5). If the
Tracker state changes, then the UI Window is
informed (6) and the Sequence Window is updated
(7) in the event that the change marked the end
of a sequence.
Status Window
Sequence Window
7
4
3PB Tracker
Data Feed
5
2
Adaptor
3
6
1
Cache
Primary UI Window
6
Points of Interest

• We only track (and cache) the last TOS in each
  time slot and the opening TOS. All other TOSes
  are discarded at the Data Feed.
• We use only in-memory caching because there are
  fewer than 2000 1-minute time frames in any day,
  suggesting that very few TOSes will be cached.

7
Part 2 The Demo

• Insert demo here.

8
Part 3 The Development Process
The development process attempted to follow three
principles

• Emphasize working code over documentation
• Pair programming
• Test-first programming

9
Working code over documentation

• This approach resulted in some additional
  overhead when integrating the code.
• However, we feel that this approach was
  beneficial overall.

10
Pair programming

• Pair programming probably does work well when
  both programmers are consistently available each
  day to code for a long period of time.
• Although we did experience some benefits due to
  catching errors early, the overhead due to the
  scheduling problems introduced by pair
  programming seemed to be more costly.
• Even when we did find time to meet, the meetings
  were usually limited to at most a few hours.

11
Test-first (TF)

• Test-first programming seemed to hinder
  development more than help it.
• First, we spent more time correcting errors in
  the test than in the code, due to our lack of
  experience.
• Second, an event-driven design does not require
  accessor methods in most objects, but the tests
  are difficult to construct without these methods.
• Third, assertion-based testing did not seem
  appropriate for some objects, such as GUI
  components and the Adaptor.

12
Summary(1)

• We will now summarize our observations.
• It is important to note that all members of our
  group had little to no prior experience with the
  Java language or with these programming
  principles.

13
Summary (2)

• We consistently used pair programming.
• However, when the second person had little to
  work on, his attention span typically dropped off
  quickly.
• Pair programming seemed to work well when the
  second programmer was actively engaged in some
  task, such as looking up an objects API.

14
Summary (3)

• We were unable to use the testing principles as
  they were described in class.
• In most cases, we were able to use
  assertion-based testing with our objects, despite
  their event-driven designs.
• There was some additional code in the GUI
  components that should be tested assertionally,
  but would require refactoring first.

15
Tracker as a State Machine
3
2
0
1
2
3