| CATEGORII DOCUMENTE |
| Comunicare | Marketing | Protectia muncii | Resurse umane |
On-line Restaurant Ordering
Problem Statement 5
Business Model 7
Business Actors 7
Business Scenarios 7
Browse the Menu 7
Place the Order 7
Process the Order 7
Pay by Credit Card 7
Review the Restaurant 7
Configure the System 8
Business Use Cases and Activity Diagrams for the Business Process 8
Browse the Menu 8
Place the Order 9
Process the Order 9
Browse the Menu & Place the Order & Process the Order 10
Pay by Credit Card 11
Review the Restaurant 12
Configure the System 13
Business Object Diagram 13
Domain Model - adding attributes 15
Position of the Application in the Business. Context Diagram. 16
Requirements Analysis Model 17
Actor Descriptions (Concerns and Responsibilities) 17
Client 17
Waiter 17
Kitchen 17
CCA 17
Administrator 17
System Event List 18
F1. The Interaction with the Client 18
F2. The Interaction with the Kitchen 18
F3. The Interaction with the Waiter 18
F4. The Interaction with CCA 18
F5. The Interaction with Administrator 18
F6. The Running Function 19
Attributes of the System 19
Software Use Cases (Use Case Diagram and Description) 19
Browse the Menu 19
Place the Order 21
Process the Order 21
Pay by Credit Card 22
Review the Restaurant 24
Configure the System 24
System Sequence Diagram 25
Browse the Menu 25
Browse the Menu - adding software classes 26
Place the Order 26
Place the Order - adding software classes 27
Process the Order 27
Process the Order - adding software classes 28
Pay by Credit Card 28
Pay by Credit Card - adding software classes 29
Review the Restaurant 30
Review the Restaurant - adding software classes 31
Configure the System 32
Configure the System - adding software classes 33
Design Model 34
Responsibility Assignment to Classes 34
System Initialization 34
Browse the Menu 34
Place the Order 36
Process the Order 38
Pay by Credit Card 39
Review the Restaurant 42
Configure the System 43
Interaction Diagrams - Collaboration Diagrams 44
Browse the Menu 44
Place the Order 45
Process the Order 45
Pay by Credit Card 46
Review the Restaurant 46
Configure the System 47
Design Class Diagram 47
Design Pattern Identification 47
Delegation 47
Marker Interface 49
Proxy 50
Factory Method 50
Singleton 52
Faade 54
Adapter 55
Model-View-Controller 55
State Diagrams for Business Objects with Non-trivial Life Cycle 56
Order 56
Bill 57
Architecture Document - Package Diagram 58
Nested packages Diagram 58
Package Diagram 59
Architecture Document - Class cohesion inside packages 59
cca 59
restaurant.main 60
restaurant.repository 61
restaurant.util 62
restaurant.menu 63
restaurant.remote 64
restaurant.view 65
restaurant.review 68
restaurant.client 68
restaurant.order 69
restaurant.payment 70
restaurant.configuration 71
Running the application 73
Instalation 73
Running 73
The restaurant of the Rex hotel become increasingly busy, waiters and waitresses are finding themselves with having to reduce the level of customer service in order to balance their higher volume of customers. In addition, there is much inefficiency involved with the standard order taking processes. This inefficiency is due to the existence of the following causes:
- Waiters and waitresses handwrite orders and walk the orders to the kitchen
- Waiters must make constant trips to the kitchen in order to check the status of an order
- Waiter handwriting can be misinterpreted by kitchen staff
- Orders can be misplaced or overlooked by kitchen staff
- Waiters become stressed due to high level of multitasking due to having to simultaneously serve multiple customers
- Credit cards are taken away from customers view, creating a potential security hazard
- Customers often have to wait long periods before being fed due to the above inefficiencies
The owner of the restaurant believes that it is time to replace the archaic use of paper and pencil with the technologies that are currently available. In order to do this, the owner decided to buy a software application that will automate many tasks that waiters and waitresses must perform.
The software system will be installed in a network and run on the thin clients that will stay on the tables from the restaurant.
The system will have a GUI which provides the following list of application features that will greatly reduce the inefficiencies describe above:
A. GUI will provide a mapping of all the restaurant tables.
1. By clicking on a specific table that a waiter/waitress is currently servicing, the customer can send an order to the kitchen wireless.
2. Orders will be placed by clicking on food items displayed on a menu that is integrated into application
If a menu item becomes unavailable, the menu item will become grayed-out to indicate its unavailability to the customer.
The customer will be able to access nutritional information for items on the menu.
The system will have a feature that will make updating the menu simple and easy in order to accommodate to the daily specials of the restaurant.
3. The GUI table representation (perhaps a simple square) will be color-coded to indicate the status of the table's order (i.e. when it becomes green, the waiter will know that the order is ready).
4. When a certain time interval has passed in which a waiter has not visited a table, the GUI representation of that table will blink in order to remind the waiter to check on that table.
B. GUI will have the capability to process a credit card payment at the table. The customer will input the credit card number and the system will verify the card validity with the help from a credit card authorization (CCA). If the credit card is OK, the system will request to the CCA to perform the payment of consumption. In addition, GUI will support this feature by having a print option that will print out a detailed receipt.
C. GUI will have a notepad feature, which allows customers to make personal notes as well send notes to the kitchen in order to place customized orders. For instance, at the end of the meal the customers may use the notepad feature of the system in order to fill out general restaurant surveys as well as specific reviews on the meals ordered. These would prove beneficial to both the restaurant and to future customers. This information would be stored in a repository for access at ordering time for other diners.
They are Actors in the business environment.
Client
CCA
Kitchen
Waiter
Administrator
They represent a sequence of actions and interactions between business actors and the system
1. Client asks to see the menu
2. System offers the menu to the Client
3. Client browses through the menu and chooses his today order
1. Client asks to place an order
2. System briefs to the Client his selected plates
3. Client can update his order
4. Order is placed to the Kitchen
1. Kitchen receives the order
2. Kitchen prepares each menu item on the order
3. When every menu item is ready the Waiter serves the meal to the client
1. Client asks to pay by credit card
2. System offers the Client the facility where to enter his personal credit card data
3. Client enters personal information
4. System forwards the payment details to CCA
5. System prints the receipt of the operation
1. Client asks to write a review of his experience in the restaurant
2. System offers the Client the facility where to enter his review
3. System saves any review filled in by the Client
1. Administrator asks to update the menu
2. System offers the Administrator the facility where to enter his modifications
3. System saves any modification made by the Administrator
describe a sequence of actions of a business as a whole to fulfill a goal of a business actor
The Domain Model illustrates the meaningful conceptual classes in the problem domain.
Candidate conceptual classes:
terminal
table
restaurant
waiter
client
order
kitchen
menu
menu item
credit card
bill
CCA
receipt
review
administrator
Domain Model - adding attributes 
Client - extern ( => Actor)
Interests:
to serve a good meal
to be served on-time
to be served according to his special requests on the menu items
Responsibilities:
to have the amount of cash to pay his bill or to carry a valid credit card
to be hungry
Waiter - intern ( => Agent)
Interests:
to serve in a restaurant with good reviews from the clients
Responsibilities:
to help the client to use the terminals on the tables
to check on his clients within a specified interval of time
to serve the order to the table
Kitchen - intern ( => Agent)
Interests:
to receive good reviews from the clients
Responsibilities:
to know how to cook each menu item
to prepare each menu item in a reasonable amount of time
CCA - extern ( => Actor)
Interests:
Responsibilities:
to check for credit card information in its database
to check the correctness of the credit card number/credit card pin-code pair
to perform a payment
to respond to any request in the lowest time possible
Administrator - intern ( => Agent)
Interests:
to work in a fashionable restaurant
to perform his duties with help from an easy to use interface
Responsibilities:
to update the menu items and specials of the day
to update the nutritional information
to update the prices and stock
The System displays the menu to the Client
The System displays nutritional information of a menu item to the Client
The System marks as unavailable the menu items whose stock ended
The System checks the Client's order
The System displays the order synopsis to the Client
The System displays the CC payment page to the Client
The System receives the CC number from the Client
The System receives the CC pin-code number from the Client
The System displays the consumption bill to the Client
The System prints a receipt of the payment for the Client
The System displays the review page to the Client
The System saves the Client review
The System displays restaurant/menu item review to the Client
2.1 The System sends the order to the Kitchen
2.2 The System receives confirmation of a cooked ordered menu item from the Kitchen
3.1 The System notifies the Waiter that a certain time interval has passed since he last visited his table
3.2 The System notifies the Waiter that a Client has ordered from one of his tables
3.3 The System notifies the Waiter that the order from the Client is prepared and must be served at the table
4.1 The System sends Client and CC data to CCA
4.2 The System receives from CCA the correctness of sent Client data
4.3 The System asks CCA to perform the payment for the Client
5.1 The System displays the authentication page to the Administrator
5.2 The System authenticates the Administrator
5.3 The System displays the configuration page to the Administrator
5.4 The System saves the modifications made by the Administrator
6.1 System checks when the entire Client order is cooked
6.2 System checks when a certain time interval has passed since the Waiter last visited his tables
6.3 System checks when a menu item becomes unavailable for further ordering
6.4 System updates stock quantities
placed order color: red
cooked order color: green
initial table color in the table mapping representation: yellow
unavailable menu item: gray
waiter notification timeout: 10 minutes
Primary Actor: Client
Stakeholders: -
Preconditions:
the Client must be sited at one of the restaurant tables
the System displays on the terminal of each table the table mapping representation, with yellow color for corresponding table
Post-conditions:
the Client knows the menu
the Client fills in quantities for the menu items he wants to order
Trigger:
the Client presses his table (yellow color) in the table mapping representation
Cross-references from System Event List: 1.1, 1.2, 1.3, 1.13, 6.3
Main Flow:
The Client presses his table button in the table mapping representation
Alternative flow: A1
Alternative flow: A2
Alternative flow: A3
The System checks availability for all menu items and specials of the day
Exception flow: E1
The System displays the menu composed of menu items and specials of the day and having the no-more available menu items gray-colored.
The Client browses the menu items and the specials of the day
Alternative flow: A3
Alternative flow: A4
The Client fills in the quantities he wants to order for each desired menu item or specials of the day
Alternative Flows:
A1.
If there is an administrator logged in who performs modifications in the system configuration, the client is notified to wait until the administrator finishes his job
Return to main flow at step 1.
A2.
If the client has an order prepared which was not yet served at the table, pressing the button marks that the order is served by the waiter to the table
The table button in the table representation becomes yellow (waiting for a new menu request)
Return to main flow at step 1
A3.
If the client at the current table has an order which started to be processed in the kitchen but is not yet entirely prepared, pressing the button marks that the waiter visits his table
The system resets the timeout signaling the waiter to check his table every 10 minutes
The table button is colored in red (order being processed)
Return to main flow at step 1
A4.
The Client presses the request nutritional information button next to a menu item
The System collects all nutritional information about the menu item
The System displays the nutritional information page of the menu item
The Client reads the nutritional information for the menu item
Return to the main flow at step 5.
A5.
The Client presses the read reviews button on the menu interface
The System collects all reviews
The System displays the reviews
The Client reads the reviews
Return to the main flow at step 5.
Exception flows:
E1.
The Systems finds that there are no menu items in stock
The System displays an error message
The flow ends.
Primary Actor: Client
Stakeholders: Kitchen, Waiter
Preconditions:
the Client must have filled in at least one quantity for one of the available menu items or the specials of the day
Post-conditions:
the Order is placed to the Kitchen and starts being processed
the Waiter is notified that a new order was placed from one of his tables
Trigger:
the Client presses the order button
Cross-references from System Event List: 1.4, 1.5, 2.1, 3.2, 6.4
Main Flow:
The Client presses the order button
The System checks entered quantities against stock quantities
A1
The System reserves the quantities for the Client order
The System displays a synopsis page of the Client order
A2
The Client fills in any custom note about his order
The Client confirms the order
The order is placed on the Kitchen's cooking queue
The Waiter is notified by marking red the table button
The System updates the stock/reserved quantities
The System starts the timeout that will visually notify the waiter to check his table if more than 10 minutes elapsed
The System automatically adjusts any menu interfaces that were currently browsed by other clients, modifying quantities
Alternative Flows:
A1.
System finds that some of the ordered quantities are exceeding available stock
System automatically modifies ordered quantities to available stock
The flow returns to main flow at step 4.
A2.
The Client infirm the order
The system releases the quantities for the Client order
Return to main flow at step 1.
Primary Actor: Kitchen
Stakeholders: Waiter
Preconditions:
the Kitchen received a new order in the processing queue
Post-conditions:
the order is served to the Client
Trigger:
System places a new order in the Kitchen's queue
Cross-references from System Event List: 2.1, 2.2, 3.1, 3.3, 6.1, 6.2
Main Flow:
The System places a new order in the Kitchen's processing queue
A1
The Kitchen cooks a menu item
The System checks if the entire order is ready
A2
The System notifies the Waiter that the order is ready to be served by marking green the table representation on the table mapping representation
The System removes the order from the Kitchen's cooking queue
The System stops any timeout interval check for the current table
The Waiter serves the order to the Client
The Waiter marks that he served the order by pressing the table button
The table button in the table mapping representation is colored yellow
The Client starts eating
Alternative Flows:
A1.
The timeout until the Waiter must re-check on his table elapses.
The System notifies the Waiter that he must visit his table by blinking the table button color on the table mapping representation
The Waiter visits the table and marks it visited by pressing the table button
The System resets the timeout
A2.
The System finds that not all ordered menu items were cooked/prepared
Return to main flow at step 3.
Primary Actor: Client
Stakeholders: CCA
Preconditions:
the Client has a unpaid bill for his order
Post-conditions:
the payment is recorded to CCA
the Client receives a receipt of the payment
Trigger:
The Client presses on pay my bill button
Cross-references from System Event List: 1.6, 1.7, 1.8, 1.9, 1.10, 4.1, 4.2, 4.3
Main Flow:
The Client presses on the pay my bill button
The System checks connection with CCA
E1
The System displays the bill to the Client
A1
A2
The Client confirms his bill by pressing the button to pay with credit card
The System asks for cc number
The Client enters his cc number
The System forwards the cc number to CCA
A3
CCA accepts cc number
The System asks for pin-code
The Client enters pin-code
The System forwards the pin-code to CCA
A4
CCA accepts pin-code
The System prints a receipt
The System asks CCA to record the payment
The System marks the bill as paid
Alternative Flows:
A1.
The Client infirm his bill
Return to main flow at step 1.
A2.
The Client asks to pay cash
The Waiter is notified that the Client wants to pay cash
The bill is marked as paid
A3.
CCA does not accept the cc number
The System displays an error message
Return to main flow at step 8.
A4.
CCA does not accept the pin-code
The System displays an error message
Return to main flow at step 13.
Exception Flows:
E1.
The connection with CCA cannot be established
The client is informed that he must pay by cash his bill
The System displays an error message
The flow ends
Primary Actor: Client
Stakeholders: -
Preconditions:
the System must be up and running
Post-conditions:
the Client review is saved for later checking by other diners
Trigger:
the Client presses on the make a review button
Cross-references from System Event List: 1.11, 1.12
Main flow:
The Client presses the make a review button
The System displays the review enter page
The Client fills in the review and presses save button
The System saves the review in the repository
The System updates the reviews information that are being held as a resource for later browsing by clients
The System updates all reviews interfaces currently being browsed by clients
Primary Actor: Administrator
Stakeholders: -
Preconditions:
the Administrator knows his authentication data
Post-conditions:
information about admin authentication details, product categories and product details are being updated
Trigger:
the Administrator presses the configure button
Cross-references from System Event List: 5.1, 5.2, 5.3, 5.4, 6.4
Main flow:
The Administrator presses the configure button
A1
The System displays the authentication page
The Administrator fills in his authentication data
A2
The System displays the configure page
The Administrator modifies/updates information regarding administrators, product categories and product details. Some checks are always being made: there must always be at least one administrator, product category names and product names have to be unique
The System saves the data entered by the Administrator
The System refreshes the product descriptions information that was being held as a resource for displaying menu interfaces to clients
Alternative flows:
A1.
There are still clients that are in the middle of the processing order
The System displays a notify to the administrator asking him to wait until all clients ended their interaction with the system
The flow goes back to step 1
A2.
The System does not accept the entered authentication data
The System displays an error message
Return to main flow at step 4.
Delegation
- all classes that are transported over the network between actors and the system must be of Serializable type - this describes Marker Interface pattern. Some of them will automatically be of Serializable type by extending classes of Serializable type (for instance, GUI classes that extend JFrame)
- class MenuManager acts as a Virtual Proxy for ProductDescription - initializes them only once and when needed, afterwards handles every request to any ProductDescription
- all Singleton implementations will use the following lazy-loaded solution:
public class Singleton
private static class SingletonHolder
public static Singleton getInstance()
- DbManager acts as a Faade that provides a simpler interface to the logic needed for executing SQL queries into the database
- RepositoryManager acts as an Adapter that wraps the logic of interaction with DbManager (which provides convenient methods for executing SQL queries) to an easy-to-use interface for the entire system
- the entire system is based on the MVC architectural pattern. The View is represented by all GUI classes. The Controller consists in following Manager classes: MenuManager, OrderManager, PaymentManager, ReviewManager, ConfigurationManager. The Model is represented by all other classes (except actors) and encapsulates a data access layer to the persistent storage mechanism (database).
- this package acts as a simulator of the real CCA system. It contains the CCA class, which implements restaurant.remote.CCARemote interface, which is the public interface of the CCA system for the restaurant
- this package
contains the classes needed to initialize the restaurant: Restaurant, Kitchen, Waiter, Table, Terminal. The Kitchen defines an internal class KitchenProcessOrderThread which will
later be used to process an order placed by a client. The Waiter class defines an internal class WaiterTimeoutThread which will later be used to remind a waiter to
check on his table after a client placed an order. The Main class is responsible for initializing the entire system. 
- this package contains the logic for accessing the repository information (in our example, the MySQL database instance). It is part of the Model component in the Model-View-Controller pattern. The package has a manager class RepositoryManager which handles all requests to the repository from the system. It uses DbManager to perform mysql queries in the database. Both classes implement the Singleton lazy-loading pattern earlier described. RepositoryManager defines an internal class Queries which holds all the queries that are executed through DbManager in the database instance.
- contains useful classes that are independently used by other classes in the system, and have no connection to the restaurant as a system. GUIUtil defines some common methods for laying out interfaces. RegExp contains regular expressions formats. ErrorCallbackInterface is an interface that can be implemented by any class that wants to act as an error catcher for some operations.
- contains all the classes needed to realize the Browse the Menu use case. ProductDescription is a class enclosing all information of a product from the repository and provides methods for reserving/releasing quantities for a client order. The Menu is composed of MenuItems which reference ProductDescriptions and catches events from the client regarding the menu and sends them to the MenuManager. The MenuManager is the controller for the Browse the Menu use case and handles all requests for a Menu and MenuItems. MenuManager and Menu both implement the lazy-loading Singleton pattern.
because the system is intended to run in a physically distributed environment, here are all remote interfaces that are to be implemented by real classes in the system so that their objects to become network accessible between remote parts of the system. Each remote interface acts as a stub for the real object in the system/remote system. Since different parts of the system must communicate using common system objects, and since those objects may reside in different name spaces (why not, different machines), this interfaces help declaring previously known public interfaces for the objects that are to be shared between different parts of the system. As seen by me, the system may be distributed as following: the terminals that are on each table (so all the information that need to be used by/retrieved from the thin clients running on the terminals must make use of such remote interfaces for the necessary objects), the CCA system which is on a different machine (a different building, company etc, so all communication to/from CCA must use a remote interface of the CCA system which is defined and declared by CCA and known by the restaurant system, and, moreover, all information sent to CCA must use remote interfaces that need to be known by CCA too) , and the main system. So all information that need to be shared between terminals and the main system, and between CCA and the main system need to be publicly known by both parts interested in the communication. This is the role of the xxxRemote interfaces defined in this package. ClientRemote (stub for Client) is needed because the client is sited at one of the restaurant tables, using a terminal that is network-accessible by the system, and the restaurant must know of a way of sending him necessary data. TerminalRemote is used for associating clients to terminals (simulation of a client who sits at a table and starts using the terminal on the table). MenuRemote and MenuItemRemote are used for displaying menu information to the client. MenuRemote is also used to catch all events sent by the client regarding the menu. OrderRemote and OrderedMenuItemRemote are used to display order information to the client. OrderRemote is also used to catch all evens sent by the client regarding his order. BillRemote is used to display bill information to the client and to catch client events regarding the bill. CCARemote is the interface for the CCA system that is used by the restaurant. PaymentRemote and CreditCardDataRemote represent information that is sent to CCA system when performing a payment/checking some credit card data validity.
- this is the View component in the Model-View-Controller architecture pattern. Here are defined all graphical interfaces that are displayed by the system. All interfaces that are to be displayed on the remote terminals are to be network-accessible, and this is achieved by extending JFrame (which is a Serializable type (see Marker Interface pattern described earlier) and by using remote interfaces of real objects: TableRepresentationGUI (displays the table representation mapping with the current table button marked yellow), MenuGUI (displays the menu interface), OrderGUI (displays the order interface), BillGUI (displays the bill interface), CreditCardGUI (displays the credit card interface), ReviewGUI (used when writing a review), ReviewsGUI (used to read saved reviews). TableRepresentationGUI also defines an internal class BlinkingThread that will be used when the table button will start blinking to notify that the waiter timeout elapsed. All other interfaces AdministrationGUI (displays the interface that allows the administrator to enter the Configure the System use case), ConfigurationGUI (interface allowing editing the configuration of the system) and AuthenticationGUI (admin authentication interface) are used for editing the system configuration. ConfigurationGUI also defines three internal classes IntegerEditor (used to restrict entering values in a table cell to an integer value), DoubleEditor (used to restrict entering values in a table cell to double value), and UniqueStringEditor (used to restrict entering unique per column values in a table).
this package contains classes that are used for Review the Restaurant use case. ReviewManager is the controller of the use case and is responsible for displaying reviews to the clients, and to save new reviews into the repository. Review is the representation of a review from the repository. RepositoryManager implements the lazy-loading Singleton pattern
- this package is a simulation of a real client that enters the restaurant and starts interacting with a terminal. It contains the Client that defines the client details, and is used by the restaurant to send data (graphical interfaces for instance) and to receive signals (of course, using the ClientRemote interface - see restaurant.remote description)
this package contains classes that are used for Place the Orderd and also in the Process the Order use cases. OrderManager is responsible for receiving order requests from the clients, asking for confirmations, sending the orders to the kitchen, permanently checking if the orders are prepared, and notifying the waiters of order status changing and when they must check their tables if too much time has elapsed. OrderManager implements the lazy-loading Singleton pattern. The Order is composed of OrderedMenuItems and contains all information related to a client order, also catches all events from the client regarding his order, events that are delegated to the OrderManager.
- this package contains classes that are used in the Pay by Credit Card use case. PaymentManager is the controller of the class, and is responsible of getting credit card information from the client, communicating with CCA for validity of the client data, and for creating and printing the bill. PaymentManager implements the lazy-loaded singleton pattern. Bill contains all information regarding the bill for a client. Receipt is the class that prints the receipt of a payment information of a bill. CreditCardData is an object used in the communication with CCA to allow checking of credit card validity for a client. Payment is the information sent to CCA to perform a payment into the client account.
- contains ConfigurationManager class which is the controller for the Configure the System use case. It implements the lazy-loaded Singleton pattern and is responsible for authenticating the administrator, building and displaying the interface with the configuration of the system, and for saving data into repository and refreshing modified data into the system.
the system must have installed a MySQL server instance (capable of transactions, supporting InnoDB tables), java sdk
install the database by running the queries inside online_restaurant.sql
change inside restaurant.properties DBHOST, DBNAME, DBUSER, DBPASS accordingly, to permit access to the database (mysql host, database name, mysql user, mysql password)
change (if necessary) in restaurant.properties the number of tables inside the restaurant (TABLENR), the number of waiters (WAITERNR) and the timeout in seconds for a waiter notification (WAITERTIMEOUT). The Restaurant will associate the waiters to the tables when initialized.
change (if wanted) in client.properties the names of the clients who will use the
restaurant and their mapping to the restaurant tables. Please take care not to
put invalid table numbers associated with the clients - must be different
numbers lower than TABLENR from restaurant.properties.
When
change (if wanted) in cca.properties the data regarding client names and credit card numbers and pincodes. This information is used by CCA class (simulator of a real CCA system) to check for correctness of client credit card data. Please take care to put similar names as in client.properties for client names.
- all classes are found in the classes folder
- all sources are found in the src folder
- a distribution jar named OnlinedRestaurant.jar is also present
- restaurant.main.Main is the main class of the project - initializes the restaurant, clients, cca, associates clients to restaurant tables/terminals.
- please include the mysql connector jar library inside lib folder in the classpath (the jdbc/odbc driver)
- you can use this command to execute from existing classes:
java -cp .;classes;libmysql-connector-java-5.1.5-bin.jar; restaurant.main.Main
- you can use this command to execute from distribution jar:
java -jar OnlineRestaurant.jar
- in the folder resources you will find this document, the associated Rational Rose .mdl file and the diagrams generated with Enterprise Architect
- when running, the system displays in the top left corner the admin button to administer the system (initial username & password: admin/password), and in the center of the screen, the table representation interfaces. Remember that tables with no associated clients will not respond to user interaction. Please take care of interfaces that are displayed on top of others (especially in the center of the screen).
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 2323
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
