390 likes | 486 Views
CSI 4V96 PROJECT SUMMARY. Addison Beyer – Undergraduate Student Dr. Paul Grabow – Professor December 14, 2009. About. August 22, 2009 – December 14, 2009 Semester Long Project Fulfills Capstone requirement Supervised by Dr. Grabow During this time
E N D
CSI 4V96PROJECT SUMMARY Addison Beyer – Undergraduate Student Dr. Paul Grabow – Professor December 14, 2009
About • August 22, 2009 – December 14, 2009 • Semester Long Project • Fulfills Capstone requirement • Supervised by Dr. Grabow • During this time • Full time employee at The Texas Life Insurance Company located in downtown Waco • Senior Computer Services Associate Addison Beyer - Fall 2009 - Project Report
Problem Statement • Project began in the fall of 2004 with CSI 4344 • Initial problem statement • ExercizeMax, Inc. is a manufacturer of exercise equipment designed for the “low-end” health club market. EM desires to upgrade its current line of low impact fitness equipment by making mechanical design improvements. EX desires to develop mechanical designs that allow variability in various equipment parameters including resistance levels. The parameter variability should be manually adjustable with the capability for automatic adjustment to the needs of a specific user. Automatic parameter adjustment should be based on a user profile. EM desires to provide each user access to time-history profiles that can be individually tailored for each user. • Motivated by work engineers doing for local company • What the project is now • A distributed system across a network that allows for users to use, change, and save settings applicable to an exercise machine. Addison Beyer - Fall 2009 - Project Report
CSI 4344 Project • CSI 4344: Fall 2004 • Initial architecture and implementation • Master’s Project: Summer 2005 • Stress testing and modifications, “cleanup” • CSI 4344: Fall 2005 • Emphasis on the “framework” • CSI 5342: Summer 2006 • Introduction of single-board computer • CSI 4344: Fall 2006 • Re-design of components • CSI 4344: Fall 2007 • Addition of RFID tags Addison Beyer - Fall 2009 - Project Report
MasterController DataManager PeripheralController1 PeripheralController2 PeripheralController3 Transducer1 User Interface1 Transducer2 User Interface2 Transducer3 User Interface3 Communications Interconnect System Architecture • Loose coupling allows individual components to be modified without disrupting the entire system • Technologies such as UDP and XML data storage encapsulated to allow changes if the need arrives Addison Beyer - Fall 2009 - Project Report
Java Implementation • The Java Peripheral and Master Controllers Addison Beyer - Fall 2009 - Project Report
Dynamic C Implementation • The Rabbit Board – Dynamic C Implementation Addison Beyer - Fall 2009 - Project Report
Starting Point • Expectations • Not sure what to expect • Never worked on such an extensive and large project • Hundreds of documents • Two different programming languages (Java and Dynamic C) • Project Size (Java) • 14 packages • 67 classes • 441 methods • 144 attributes Addison Beyer - Fall 2009 - Project Report
Starting Point • Dependency Graph of MC and PC MyProtocolContext Addison Beyer - Fall 2009 - Project Report
Starting Point • Total Lines of Java Code per Package Addison Beyer - Fall 2009 - Project Report
MasterController DataManager PeripheralController1 PeripheralController2 PeripheralController3 Transducer1 User Interface1 Transducer2 User Interface2 Transducer3 User Interface3 Communications Interconnect Starting Point Addison Beyer - Fall 2009 - Project Report
Starting Point • Total lines of Dynamic C code per file Addison Beyer - Fall 2009 - Project Report
Starting Point • Statement of Work • Defined what was to be done throughout the semester • Timeline • Problems Identifying Objectives Up Front • Don’t want to be overly ambitious with goals • Some objectives not completed • Barcode scanner subsystem to identify persons • Provide inventory management & hasten customer check-in and check-out • XML data file storage access of the network • Allow customers to use their settings at multiple facilities Addison Beyer - Fall 2009 - Project Report
Schedule • Meetings with Professor • Meet with Dr. Grabow on Mondays and Fridays to discuss weekly objectives • Weekly Objectives • Each week an objective was to be completed or started • Document created for each week’s objective • Discuss what was done to complete the objective • Problems encountered and overcame • Operated incrementally • Course altered if needed Addison Beyer - Fall 2009 - Project Report
Weekly Objective Example Week Nine Objectives October 19, 2009 – October 23, 2009 Update statecharts and animate statecharts and sequence diagrams using Rhapsody to demonstrate collaboration between MC and PC. The MC and PC statecharts were updated to more reflect the existing Java code. These changes include showing timeouts when the PC is waiting for the MC to send back and event or when the PC is waiting to change states (for example, from state SS2 to C0). In addition, internal events, events that are used to update the GUI, are ignored. This is done because they do not aid in demonstrating the actual change from state to state in the statechart. Also, the PC and MC statecharts were placed orthogonal to one another. This allows the reader to easily trace down the PC and identify how the PC events affect the events and state changes in the MC. The updated statechart is shown in Figure 1. Addison Beyer - Fall 2009 - Project Report
Project Organization • Beneficial Resources • Previous Semester’s Documentation • Invaluable • BearSpace • Hosted documents and previous semester’s documents Addison Beyer - Fall 2009 - Project Report
Project Organization • Google Groups • Discussion forum • Used at beginning of project but dropped in favor of email • Would be beneficial with more members Addison Beyer - Fall 2009 - Project Report
Project Organization • Subversion Repositories • Code and document versioning • Tagging Addison Beyer - Fall 2009 - Project Report
Project Objectives • User’s Manual • Scenarios • Activity Diagrams • Statecharts • Graphs representing statecharts • Java code modifications • CSI 3373 Quality Assurance involvement Addison Beyer - Fall 2009 - Project Report
Project Objectives • User’s Manual • Two-Sided • End User’s Perspective • Setting Up the System • Connecting the Rabbit Boards • Running the MC and PC Java Implementations (JAR files) • Using the System • Manager user accounts • Logging in with ID number or RFID tag • FAQ • Developer / Technical Perspective (Appendices) • System Architecture • Testing • Setting IP address & port numbers • XML file schemas • Using Dynamic C & Java Implementations (running, compiling, etc.) Addison Beyer - Fall 2009 - Project Report
Project Objectives • Scenarios • Document possible paths that can be taken from the set of user inputs • Logging in with ID number • Logging in with RFID tag • Logging out • Add user • Delete user Addison Beyer - Fall 2009 - Project Report
Project Objectives • Activity Diagrams • Illustrate what the system is doing internally to fulfill scenario Addison Beyer - Fall 2009 - Project Report
Project Objectives • Statecharts • Illustrate how system handles external events • MC and PC shown as a collaborating statechart • PC sends event to MC • MC responds with a different event • Process continues until PC sends evSessionDone event to MC Addison Beyer - Fall 2009 - Project Report
Collaborating Statechart Addison Beyer - Fall 2009 - Project Report
Project Objectives • Java Code Modifications • Reflect statechart • Timeout in state C3 waiting for evAckDone from MC • Check if MC is alive before sending an event – pulled out from send method and created method isMCalive • Change state names • C_OneHalf? • M0, M1, C1, C2, C3, SS1, SS2 • “M” – main • “C” – communicating with MC • “SS” – standalone state; unable to communicate with MC • Statecharts updated to reflect changes Addison Beyer - Fall 2009 - Project Report
Project Objectives • Modified Statechart Addison Beyer - Fall 2009 - Project Report
Project Objectives • Graphs • Display all possible paths that can be taken in the system (both MC and PC) • Based on statecharts • Does not show state names, guards, or transition names Addison Beyer - Fall 2009 - Project Report
Graduate Student Involvement • Chengsen Song • 1st Year Graduate Student • Dynamic C Versus Java Implementations • Found that the Dynamic C implementation follows a statechart similar to that of the Java implementation • Different state names • Similar function names (pc_evUserDone() vs. evPersonDone() Addison Beyer - Fall 2009 - Project Report
Fall Premier • About • Allows for prospective students and their parents to visit the campus, meet with Baylor faculty, staff and students, and become more familiar with life at Baylor • Participation • Presented project in Lab 114 – “Health Club Profiles” • Hands on demonstration of Rabbit Boards • Lessons Learned • Problems setting up Rabbit Boards (which IP address to use) • Technical speaking – convey project in simpler terms Addison Beyer - Fall 2009 - Project Report
CSI 3373 Involvement • Preparation • Provided scenarios, activity diagrams, statecharts, and graphs on Dr. Grabow’s profdata for students to access • Created batch files to automatically run Java MC and PCs with or without test package • Questions and Answers • Attended class on November 10 to answer any questions and to promote discussion • Followed by a system demonstration Addison Beyer - Fall 2009 - Project Report
CSI 3373 Involvement • Testing • Students were to create and execute a test plan to validate the system and find any discrepancies between intended and actual results • Test Results • Test proved intended results match expected • Could not test all scenarios • MC or PC send/receive event timeout • Would require additional code to test Addison Beyer - Fall 2009 - Project Report
Recommendations • Project • Dynamic setting of IP address and port number via graphical user interface or broadcast • Tedious to change IP address and port number in code and then flash Rabbit Boards • Replace XML files with database • Allows for remote and local use (SQLite) • Rollback changes if needed Addison Beyer - Fall 2009 - Project Report
Recommendations • Project • Allow users to change their settings • Functionality to view user settings on MC exist, but no way for PCs to pull down those settings and modify them • Completeness • Sell the project as a final product • Code • Syntax and formatting rules followed • Useful comments abundant with associated documentation Addison Beyer - Fall 2009 - Project Report
To Do It Again • Time Allocation • Objectives • Add more detail to how objective completed and any problems encountered and how they were overcame • Allocate more time for User’s Manual • Test manual in live environment • Review by peers (writing center) • Incorporate feedback from testers • Deadends • Animating statecharts in Rhapsody • If required, start small and gradually add more states and transitions • Facilities • Duplex printing in 212 Addison Beyer - Fall 2009 - Project Report
Overall • What Worked • SVN Tagging • Work on a particular version of a document or code • Google Groups • Facilitate discussion • Although dropped in favor of email, recommended for projects with more people • Rhapsody Developer for Java • Excellent tool for creating activity diagrams and statecharts • Dia • Used to create MC and PC graphs • Eclipse • SVN management, Java IDE, integrated Word 2007 Addison Beyer - Fall 2009 - Project Report
Overall • What Did Not Work • SVN Tagging (at beginning of the project) • Animating statecharts in Rhapsody • Spent over 10 hours total (downloaded the Rhapsody trial on my laptop) • Wrong Dynamic C code in the beginning • What RFID reader? • Using Rational Software Architect to design UML models • Could not create statecharts or activity diagrams as rapidly as Rhapsody • Dynamic C IDE • Libraries had to be in the LIB folder in the installation directory • Move back and forth between Eclipse project to update/commit • Down side, no solution Addison Beyer - Fall 2009 - Project Report
Overall • Development Philosophy • Don’t change code immediately when starting with an existing project • Document the changes you want to make and why • Changes can cause cascading problems • Update associated models (statecharts) when changes are made to the code • Comment your changes Addison Beyer - Fall 2009 - Project Report
Overall • Lessons Learned • Documentation • Provide enough information to allow the reader to recreate the scenario • Rhapsody modeling • Useful in understanding an existing system • Industry applicable • Organization • Hundreds of documents to filter creates need for extensive management system • Time management • How much time to spend on an objective before it’s a dead-end? Addison Beyer - Fall 2009 - Project Report
Overall • Applying these lessons in industry • Modeling • Model existing system or system in design • Documentation standards • What changed, why, and when • SVN repositories • Comments • Promote system at Texas Life to allow automatic tagging of emails to an associated project • Personal • Frequent changing of requirements/course of action • Understanding/patience Addison Beyer - Fall 2009 - Project Report