Project Plan Rev. 0.1 Page 2
Project Bluebird
University of Portland / School of Engineering Phone 503 943 73145000 N. Willamette Blvd. Fax 503 943 7316
Portland, OR 97203-5798
Theory of Operations
Project Redband: StatTracker Application
Contributors:
Todd Decosta
Troy Kanemura
Nick Thede
Approvals
Name / Date / Name / DateDr. Willshire / Walt Harrison
Insert checkmark (√) next to name and add the date when approved.
University of Portland School of Engineering Contact: t. kanemura
Theory of Operations Rev. 0.9 Page 9
Project redband
Revision History
Rev. / Date / Author / Reason for Changes0.9 / 02/03/04 / T. Decosta, T. Kanemura, N. Thede / Rough Draft
1.0 / 03/14/04 / T. Decosta, T. Kanemura, N. Thede / Final Draft
University of Portland School of Engineering Contact: t. kanemura
Theory of Operations Rev. 0.9 Page 9
Project redband
Table of Contents
Summary 1
Introduction 2
Background 3
Technologies 3
MySQL 3
PHP 3
Architecture 4
General Description 4
Design Overview 5
Graphical User Interfaces 5
UML Diagrams 8
Conclusions 19
Appendices 20
Definitions Appendix: 20
University of Portland School of Engineering Contact: t. kanemura
Theory of Operations Rev. 0.9 Page 9
Project redband
List of Figures
Figure 1. StatTracker Website – Current Game Broadcast Display 5
Figure 2. StatTracker Applet – Current Game Data Entry Display 6
Figure 3. StatTracker Applet – Base Running Data Entry Display 7
Figure 4. StatTracker Applet – In Play Data Entry Display 7
Figure 5. StatTracker Class Diagram (UML) 8
Figure 6. Use Case Diagram 9
Figure 7. Begin Game Broadcast Sequence Diagram 10
Figure 8. Enter Pre-Game Information Sequence Diagram 11
Figure 9. Create/Update Player Information Sequence Diagram 12
Figure 10. View Player Information Sequence Diagram 13
Figure 11. View Pilots Game Schedule Sequence Diagram 14
Figure 12. Login Sequence Diagram 15
Figure 13. Add Game to Schedule Sequence Diagram 16
Figure 14. View Current Game Information Sequence Diagram 17
Figure 15. View Ticket Information Sequence Diagram 18
University of Portland School of Engineering Contact: t. kanemura
Theory of Operations Rev. 0.9 Page 9
Project redband
Chapter / Summary1
The goal of Project Redband is to transform the way the game of baseball is scored and how those baseball statistics are kept at the University of Portland by using an application called StatTracker. All baseball scorekeeping is currently done using a baseball scorecard and a pencil. Our project will produce an up-to-date, interactive baseball scorekeeper that will keep statistics of every player on a single team in a MySQL database.
Project Redband has four main parts. The first part of Project Redband is the interactive portion. This will consist of a series of Java applets shown in the figures below enabling the user to keep score of the game. These applets will be used to record the events of the baseball game through a sequence of mouse clicks, as these events occur during the baseball game. All of the game data entered through these applets will populate the database accordingly in a reasonable amount of time.
The second part of Project Redband is the data viewing portion. The data viewing portion will consist of an applet that will show a listing of the players currently in the game for both baseball teams, along with their current position on defense and their current statistics for the game. The user will also have the option of clicking on a player’s name to get up to date season statistics. There will also be a small section in the applet that will hold the inning-by-inning score, much like a scoreboard display at a professional baseball game showing the runs, hits, and errors for both teams. The last part of the applet will display a pitch-by-pitch text version of the events happening in the game, which will also be output to a text file for bookkeeping purposes. All of the information in this applet will be updated pitch-by-pitch from the information provided in the interactive applet that populates the database mentioned above.
The third part of Project Redband is the database. We will be setting up a MySQL Database Server on a University of Portland computer strictly dedicated to our project. The database will hold the statistics for every player on every team throughout the season. These statistics will be loaded by the data input applet as data is entered by the scorekeeper through a series of mouse clicks that will record the events of the baseball game as they happen. These mouse clicks will update the database constantly during each game in order to keep the statistics current throughout the season.
The fourth part of Project Redband is the website. The website will be used to track the current status of Project Redband and may also be used to run queries against the stored data in the database. There will be a list of pre-defined queries users will be able to choose from in order for them to obtain the statistics they want from the database.
University of Portland School of Engineering Contact: t. kanemura
Theory of Operations Rev. 0.9 Page 9
Project redband
Chapter / Introduction2
The purpose of the Theory of Operations document is to provide a technical description of the design for the StatTracker application. It will serve as a reference for maintenance and supports as well as a starting point for future designs. Team Redband is responsible for all aspects of StatTracker including its design, implementation, and documentation. This document is intended for any university faculty, student, or other party interested in learning more about Project Redband and the technical aspects of the StatTracker application. This document is significant because it provides an organized, technical examination of StatTracker’s design.
The rest of this document includes the following chapters:
Background- a brief description of any information relevant to the project that will
help the further the reader’s understanding of the project
Architecture- explains the architecture of the StatTracker application
Design Overview- explains the design of the StatTracker application using UML
diagrams and sequence diagrams
Conclusion- provides an overview of this document highlighting significant points of
the project and any conclusions derived from this document
Appendices- includes definitions of terms used throughout this document
University of Portland School of Engineering Contact: t. kanemura
Theory of Operations Rev. 0.9 Page 9
Project redband
Chapter / Background3
StatTracker is a standalone application that will connect to a database to keep statistics of a baseball season by keeping score of the games through the user input applet. The data in the database can be accessed either through the website for season statistics of the games that have been scored through StatTracker or through the user applet for current game statistics of a game in progress being scored by StatTracker. All of the data in the database can be accessed at any time from anywhere. StatTracker will change the way the game of baseball will be scored and baseball statistics kept at University of Portland. If StatTracker is successful, this project may result in several more projects to develop applications to keep score and keep statistics of other University of Portland sports.
Software applications similar to StatTracker already exist on the market. The major difference between those applications and StatTracker is StatTracker’s ability to update a database with game statistics throughout the season. StatTracker also offers the added capability of publishing the major events of the baseball game to a website for online tracking of a particular baseball game.
Technologies
MySQL
MySQL is an open source database server. MySQL will allow the scorekeeper to update game and season statistics through the scorekeeper applet. MySQL will also allow the StatTracker website to retrieve and display the baseball statistics stored in the database.
PHP
PHP (Hypertext Preprocessor) is an open-source, server-side, HTML embedded scripting language used to create dynamic Web pages. PHP will be used for the StatTracker application website the current game data as well as a wide-variety of player and school information.
4
General Description
StatTracker will be utilizing an architecture known as the Model-View-Controller (MVC) architecture in which a controller class will be responsible for notifying the viewer class of modifications to data and other GUI information performed by the model class. More of the architecture will be explained in the next chapter.
University of Portland School of Engineering Contact: t. kanemura
Theory of Operations Rev. 0.9 Page 9
Project redband
Chapter / Design Overview5
The industry-standard language for visualizing, constructing, and documenting the artifacts of software systems is known as the Unified Modeling Language™ (UML). It simplifies the complex process of software design, similar to that of making a "blueprint" for construction. For Project Redband, ten UML diagrams describe the major components of our design, and four proposed displays show the major parts of the graphical user interface. The UML diagrams include a class diagram of the project architecture, use case diagram, and several sequence diagrams showing in detail the use case scenarios.
Graphical User Interfaces
Figure 1. StatTracker Website – Current Game Broadcast Display
Figure 1 shown above is an example of the StatTracker Website. The StatTracker Website is updated from the MySQL Database in order to display the current game being broadcast.
Figure 2. StatTracker Applet – Current Game Data Entry Display
Figure 2 shown above is the StatTracker Applet. The scorekeeper will use this applet in order to track the different events that occur during the game. The current score will be shown on the top-left of the applet with an inning-by-inning breakdown of the runs scored, the total amount of runs, the total amount of hits, and the total amount of errors for each team. The current inning information (balls, strikes, and outs) will be displayed in the top left of the screen. Below the inning information, the name and position of the current batter will be displayed as well as the name of any runners on base, the name of the current pitcher, and the current lineup of both the home team and the visiting team will be displayed as well as their current defensive position. The Inning Summary Display will provide a textual description of the current game events. The buttons on the left side of the screen will be clicked on by the scorekeeper to record all of the events throughout the game. The ball and strike buttons under the Pitch Options will be used to record the balls and strikes to the current batter. The reset count button will be used by the scorekeeper to reset the count to no balls and no strikes in case they make a mistake in recording the pitches. The buttons under the Action Options will bring up windows to either record a ball in-play or to update any players on base. The Baserunning button will open up Figure 3 where the scorekeeper will select the starting base (first, second, or third), the ending base (second, third, or home), and the result of the baserunning (safe or out). The In-Play button will open up Figure 4 where the scorekeeper will select a button to record the ball in-play.
Figure 3. StatTracker Applet – Base Running Data Entry Display
Figure 4. StatTracker Applet – In Play Data Entry Display
University of Portland School of Engineering Contact: t. kanemura
Theory of Operations Rev. 0.9 Page 9
Project redband
UML Diagrams
Figure 5. StatTracker Class Diagram (UML)
Due to most current versions of Netscape and Internet Explorer not supporting the Java Swing libraries, the StatTrackerView class will extend a Java Applet, not a Java JApplet. (All JLabels, JButtons, JRadioButtons, and JTextAreas will be referred to at the time of coding as Labels, Buttons, CheckBoxes, and TextAreas). The StatTrackerView class will be responsible for showing game information in a graphical environment. The StatTrackerController class will be the controller class in our Model View Controller architecture. The controller class will be responsible for notifying the view class of changes to game information, and notifying the model class of GUI manipulations. As the model class of our architecture, the GameModel class will be responsible for controlling game information, such as determining when an inning is over after three outs have occurred. The goal being to reduce the amount of tasks the game scorekeeper will have to perform during a game. The Team class will be responsible for knowing the team name and school names of the teams participating in the game. The Player class will be responsible for knowing the personal information of a player. The Fielder and Pitcher classes will be responsible for knowing the statistical information for each player involved in the game that is being broadcasted.
Figure 6. Use Case Diagram
The Use Case Diagram shows the various use case scenarios that are performed by the actors that will access the StatTracker product. The actors will be a Pilots Game Observer, a Pilots Enthusiasts, and a Scorekeeper that will perform the following suggested scenarios. The Pilots Game Observer and the Pilots Enthusiast will perform a request to: 1) View Player Season Statistics, 2) View Past Game Information, 3) View Current Game Information. The Scorekeeper actor will perform a request to: 1) Enter Pre-Game Information, 2) Create/Update Season Schedule, 3) Create/Update Player Information, 4) Begin a Game Broadcast, 5) Update Current Game Statistics.