System Design
This design section will describe the overall architecture and design of the project, which will employ a Model-View-Controller (MVC) software architecture pattern. It will employ a backend database, accessible through two separate front-facing graphical user interfaces (GUI), one of which will be used by the bartender and the other of which will be in the customer’s hands. Our MVC framework will be a custom system of our own creation in order to give us the flexibility to design the system exactly as we want it.
The System Architecture Graph for this design represents the relationship between the different components of the system at a high level. As can be seen the team employs a modified version of the Model-View-Controller (MVC) architecture pattern. This system, however, has a single model with two views and two respective controllers. One view represents the user interface for the customer and the other is the user interface that will face the business. Their respective controllers will handle all data transfer between the interfaces and the database, while the customer controller will also send data from customer orders to the business controller as well.
This ERD (entity relationship diagram) represents the current model of the proposed database. Below that is a sample representation of the Item_List table.
Entity Relationship Diagram (ERD)
Sample of Item_List Table
As can be seen in the table, new rows will represent new businesses while new columns will represent new items at the businesses. This design decision was made due to the reality that the majority of items will be added in the beginning, while new bars will be added often (at least to make the system scalable). The prices serve two purposes: storing the price of different items at different establishments and if that item is offered. If the price of the item is null then it is not offered, if it is non-null then it is offered and that is also the price at that given establishment. If a business wishes to add a new item to the database they should email the developers. At that point the team will add a new column to the Item_List table on the back end. Finally, the establishment can then specify that they offer the drink and the pricing for it through their administration page.
Customer-side Physical Flow Chart
Customer-side Software Flow Chart
Business-side Physical Flow Chart
Business-side Software Flow Chart
Both the business and customer will require Firefox, Chrome or Safari browser.
Customers: Required to have smart phones with a modern OS (iOS, Android, Windows Phone, etc.) with an internet connection and cookies enabled to use the application
Businesses: Require a touchscreen tablet or point-of-sale system (or any high-resolution touchscreen system) with a modern operating system (Windows 2000+, MacOS X, iOS, Android, etc.) to utilize the software.
Feature Creep - One pitfall that the TapX project may fall into is the dreaded feature creep. Specifically, adding unnecessary features that slow the development of the project or misguide developers. The Hackstreet Boys’ solution to this is to rather strictly follow the documentation they created and using the MoSCoW feature of the DSDM development methodology to add features by importance, eliminating the risk of adding extra features before system-critical features.
Breaking from the Development Timeline - The Hackstreet Boys are also concerned about the possibility of breaking from the development timeline due to a section of development taking longer than originally anticipated. Their solution to this potential issue is to put extra manpower into that section to speed up the process as much as possible and adjusting the rest of the timeline accordingly.
Mobile-Friendly UI - One potential issue that could arise with TapX development is any problem with making the site mobile friendly. The solution to this revolves around utilizing the mobile-first features of the Bootstrap framework and focusing development on mobile devices.
Software Incompatibility - Another major concern of the Hackstreet Boys is that major software components of the system will be incompatible (i.e. not want to communicate and work together properly). Their response to this possibility is the creation of the Software Architect position who, rather than focusing on an individual component of the system, will understand the high-level design and the connections between different elements in order to ensure that all pieces work together as expected.