Data Metrics

The team has chosen an architecture similar to Main Program/Subroutine with Shared Data as the necessary architecture for the Data Metrics portion of our application.  The Main Program/Subroutine with Shared Data architecture decomposes the problem according to the basic functions performed.  For the Online Golf Handicapping Data Metrics subsystem this will be input retrieval, round calculations, course information, handicap computation and output.  The main program (Online Golf Handicapping Controller) coordinates the computational components as sub-routines and sequences through them in turn.  All data is communicated between the components through a shared storage. Since the coordinating program guarantees central access to the data, communication between the computational components and the shared data is an unconstrained read-write protocol, which results in the final handicap metrics displayed to the output medium.

         Online Golf Handicapping Data Metrics Subsystem Shared Data Architecture

By utilizing the architecture above the information stored on the web server will be accessible by all necessary components.  This accessibility will subsequently lead to all components also having access to the information stored within the database.  Through setting up the metrics subsystem with this architecture we were able to address several of the previously listed functional requirements.   Req-4, the storage of round and correlating course locations is met through the Input Retrieval, Round Calculation, and Course Information components interacting with the server and database.  Given that the Shared Data architecture employs a read/write protocol.  These components will store and retrieve their specified information with the shared data repository, in this case the database.  Additionally, Req-5, which calls for tracking of various shot metrics is met through Round Calculation, Course Information, and Handicap Computation components.  These will allow collection of items such as hole-by-hole score, sand saves, drives, etc.  However the true power of this architecture is displayed in that once the information is input into the database it is accessible to all of the components to process over it.  The last two requirements addressed through the design of this subsystem are closely related and are addressed through the Output component.  Req-6 and Req-7, which both allow for player information to be made somewhat public, are perfectly suited for this design as the Output component will be able to access the database that has been populated with information from the other components.  This will allow for the user’s requested information to be pulled from the database and examined.  Lastly, the data metrics subsystem is responsible for facilitating the creation of graphs and charts, which is indirectly addressed in Req-13.  In order to do this the Output component uses a COTS [3] plug-in to create graphs/charts of the data pulled by the web service. 

Design Rationale

The choice to use Main Program/Subroutine with Shared Data architecture for the data metrics component of our application was based on several factors.  The first and possibly most important was that Shared Data easily assisted in addressing many of our stated requirements.  Additionally, it kept performance efficient and timely while also maximizing the use of space.  Space is a big issue for this subsystem, as it will consistently be handling more and more data.  As the user base expands and more courses are introduced the database will also be expected to hold more data.  With these issues in mind, as well as our performance requirements that need to be met, the team felt that Shared Data would be best suited for the job.   

While the Shared Data solution does present some potentially difficult issues they were deemed as low risk given our desired use.   Shared Data is noted for not being a very good architecture for changes to the processing algorithm or changes to the data storage format [1].  We do not envision these changes being of any issue for the data metrics component.  The storage format will always be some form of a relational database and the processing algorithm is already drilled down to a pretty basic level and should not require extensive change.  Furthermore, Shared Data is a particularly good choice given the temporary nature of the data that this subsystem deals with.  The data permanently resides in the database and will only be held in memory momentarily, on an as needed basis, when the system runs.  By taking this characteristic of the system into account the risk around Shared Data’s relationship with the processing algorithm and the data storage format becomes much less of an issue.  While Shared Data does offer another con of not being a good architecture for reuse [1] we deemed that currently, and in the foreseeable future, there was no need to reuse this subsystem and that the benefits of efficiency that Shared Data brings with it outweighed any benefit surrounding the small likelihood of reuse.

Back to main page