COMP290 Project: Team B

COMP290 Project: Team B Yuanxin Lui Nguyen-Tuong Long Le Phil Holman Yongjik Kim Andrew Nashel Stephan Sherman (AWOL)

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

Part 1: Design Status Window Sequence Window 3PB Tracker Data Feed Primary UI Window Adaptor Cache

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.

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 5 Data Feed 2 Adaptor 3 6 1 Cache Primary UI Window

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.

Part 2: The Demo Insert demo here.

Part 3: The Development Process The development process attempted to follow three principles: • Emphasize working code over documentation • Pair programming • Test-first programming

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

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.

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.

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.

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 object’s API.

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.

COMP290 Project: Team B