COMP290%20Project:%20Team%20B - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

COMP290%20Project:%20Team%20B

Description:

2. User changes the time frame. 3. Data is received from the TOS server. ... If the TOS is the last in the current time frame, it is passed to the Tracker (5) ... – PowerPoint PPT presentation

Number of Views:12
Avg rating:3.0/5.0
Slides: 15
Provided by: csU49
Learn more at: http://www.cs.unc.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com