Design choices - guerillatesters/TestResultDatabase GitHub Wiki

From the list of requirements a number of design choices and decisions can be made: Below follows details of how the requirements will be realized.

Requirement tag	Design decision.
TRDB.Multisite	Web technology using http will allow multiple sites to access the data. Use PHP with javascript as have had previous experience therefore a shorter learning curve.
TRDB.Centralize	Use a MySQL database that will interact with the front end. Choose an architecture that allows users to choose alternatives if MySQL is not suitable.
TRDB.PushResults	To allow different users and runners to push data to the database support both GET and POST mechanisms.
TRDB.Environment, TRDB.TestVersion, TRDB.Administration, TRDB.TestConclusion, TRDB.Characterization	Add fields in the SQL datbase to store information about test executed etc.
TRDB.LogFiles, TRDB.TestLogs	TBC: Log files to be stored in the database in compressed format.
TRDB.ResponseTime	Client side porcessing to be used to free up server as much as possible. Transmit only the part of the page that needs to be updated. (AJAX)
TRDB.Trending	TBD
TRDB.Views	Allow different viewers to access the data. Implement the factory method pattern to allow users to choose different viewers to view the data.
TRDB.Notification	Implement the observer design pattern to allow users to register for areas of interest
TRDB.Presentation	Implement an API (abstraction layer) that isolates the generation of PHP from the internal interactions with SQL database. Use the factory method pattern to separate presentation from implementation.
TRDB.UserAccount	Implement a proxy design pattern to control users access rights.

General requirement

Use OOP to avoid copy paste of code and use design patterns wherever possible to avoid trying to reinvent the wheel.

Based on our design choices a further set of requirements can be generated. This will be split into two different parts (front end requirements and back end API).