Bar Software Specifications

I. System Model

Client GUI


• Anyone would be able to use this GUI to search for drinks they want to order and add it to their tab. They could either use the category buttons or type in the name of their drink, which would show them likely matches as they type. Hopefully eliminating the need to type all of the name.

Bartender GUI


• This is the tool used by bartenders to visually see the orders made by clients. The orders will appear in a list as they come in from the client machines. When the bartender clicks on an order the node that it was ordered at is selected from a visual layout of nodes at the top of the GUI. They can see the list of all the drinks ordered and click on each drink to see the recipe for it. If the bartender needs to create a new order, they simply click on the "New Order" tab where they type in the names of the drinks similarly to the client drink search page.

Admin GUI


• This part is ranked 3 in importance, but would show the owner of the bar statistics on how many drinks had been sold and what to expect as far as inventory purchases.

DB Interface

• Drink Statistics- This class would perform queries on almost all of the tables in the database and would use those queries to determine the overall output of the bar over various time periods.
• Owner- This class would call upon the Owner table in the database directly to login an admin to the admin page or to create a new admin, etc.
• Drinks- The main queries to this table would be to perform searches for the search portion of the Bartender and Client GUIs.
• Orders- The Bartender and Client GUIs would use this table to add new orders into the database as well as to delete drinks from orders.
• Drink Category- The Client GUI will depend on this component to find all the top ranked drinks in a particular category.

Networking

• This is one of the more interesting parts of the project and would probably result in the most difficult coding. It basically communicates between the client guis and the bartender guis, so that the bartender gui knows which nodes to display and which orders have been placed.

Database Model

• Owner- Table representing the owner of the bar. Used in the Admin GUI. Contains the admins' user names and passwords.
• Orders- Table of all the orders made. A unique id, the quantity, the date purchased and the price.
• Drinks- Table of all the possible drinks. The name of the drink, the ingredients, the price and an unique id.
• DrinkOrders- Table linking unique drink ids to order ids.
• Components- All the possible ingredients for drinks: their names and their price/ liter.
• DrinkComponents- Links drink ids with component ids.
• Category- List of all the possible categories of drinks with links to parent categories.
• DrinkCategories- Links drinks to their respective categories(may be more than one).

II. External Dependencies

• The main external dependency is an outside source, which we would parse for drinks and their ingredients.

III. Task Breakdown/ Group Organization

1. Program Manager: Tara

   Organize meetings, make sure the schedule is up to date and being followed. Instigate positive communication and feedback amongst group members. Work closely with the heads of design to help the implementers fully understand the layout of the system.

2. Heads of Design: Lincoln, Kevin, Nate

   Lead the design discussions and hold the implementers accountable for the design document. Responsible for insuring that changes to the design document made during implementation is properly recorded.

3. Developers
   • GUI (Client and Bartender): Owen, Nate, Kevin

     There would be further division into the components of the Client and Bartender GUIs, i.e. the drink tab, drink list, order list, drink details and drink search. For now we can say that Nate would implement the drink search and details, Owen would take the order list and drink list, and Kevin would take the drink tab.

   • Database: Josh, Tara

     This would be the first portion of the project to be completed and just be setting up the database as described in the diagram above.

   • Networking: Lincoln, Sean

     The Monitor component is what sends notifications to the Bartender GUI of orders placed by the Client GUIs.

   • Database Interface: Colin, Brendan, Lincoln
   • Admin: Sean

     Responsible for setting up the initial dev tools, specifically: version control, bug tracking system, automated build script, etc.

4. Lead Testers: Colin, Brendan

   Every developer should be writing unit tests for their portions of the code, but we will also need testers to develop a test suite. Parts of the test suite would be incorporated into the automatic build. They would also be responsible for leading the user testing and using the bug tracker for reporting bugs found with either the interface or actual functionality of the program.

5. Documentation Lead: Dominic

   As with testing all the developers should be commenting their code as they go along. However it is essential to have someone keep others accountable for the clarity of the developers documentation and to summarize the projects overall components at the end of the project. This person should have a good handle on writing clear and detailed technical documents. Their documents will be what eases new developers into the project and refreshes old developers who may come back to the project in the future.

IV. Schedule

• 3/05- Tools setup on server (Continue work on final design.)
• 3/09- Final Design Document (Have database implemented, begin working on database interface, begin working on GUI stubs for the Client and Bartender GUI, begin creation of the user testing environment, begin finding volunteers for user testings)
• 3/14- Interface Proposals (Continue work on database interface, continue work on GUI layout, begin work on test suite, i.e. integrating written unit tests into a nightly build, begin working on networking component)
• 3/23- Final Interfaces (Finish database interface, finish GUI layout, begin integrating GUI and database interface, begin system wide tests for integrating into test suite, finish networking component, begin integrating networking component into the GUIs, begin working on analyzing documentation/ unit test written by the developers, user test)
• 4/6- Detailed Designs (Finish integration of the GUI with its networking and database interface, add more system wide test cases and unit tests to the test suite, user test)
• 4/9- Component Design (heavy user testing, demo release, get user feedback on additional features)
• 4/16- Compilation Demo/ Initial Integration (selectively merge in newly implemented features, continue adding tests to the test suite, continue fixing bugs, continue rectifying differences between the design doc and the actual implementation, continue documenting the release for future work)
• 4/27- In Class Demo (again merge in newly implemented features, continue with the testing and fixing of bugs, etc)
• 5/4- Project Status Pres
• 5/7- Public Demo
• 5/17- Final Demo

V. Assumptions

The main assumptions that I made in my specification was with relation to the GUI components. I should have flushed out the components of the GUIs for clarification of which components overlap between the Bartender and Client GUIs.

In this document I detailed the implementation of the Admin GUI but did not incorporate its implementation into the Task Breakdown or into the Schedule for the project.