You are to develop software for a simple online shopping situation. The entities in this scenario include the web shop, customers, products, orders and invoices. The shop has a list of products available. A customer logs in, selects products and adds them to his/her order. When the shopping is complete an invoice with unique invoice number is generated for the order. There are 10 products in this simple example and they should be stored in an array. Products can be added and deleted from an order. Only one customer at a time need be considered.
The above scenario can be modelled in a number of ways. A complete OO solution would use a class for each of the above entities: webshop, customer, product, order and invoice. Solutions which are partially OO might use records(structures) for some entities, for example customers or products. To gain a Pass level grade in this assignment you must use at least one class. Non-OO solutions will not pass. If you choose to only use one class it must be the order entity which is used. See below for the requirements for different grades:
You must model the order entity as a class. For a discussion of how to do this refer to section 3. Entities such as products and customers can be records(structures). The products need not be read from a file they can be hard-coded into your source code. The webshop can simply be procedural code in the main program. An invoice can be generated by a simple function. Coding style; comments, meaningful names, indentation and use of functions may be poor in some places.
You should model both the order entity and the product entity as classes. Products should be read in from the file ‘products.dat’. The webshop can be procedural code as for the pass level. Credit level solutions might also include some advanced features such as constructors and/or use of default parameters. Code style should generally be good with few areas of criticism.
Solutions should be mainly OO with 3 or 4 classes. Procedural code should be minimal. Products should be read from the file. Advanced features such as constructors and/or default parameters are expected. Code style must be good in all respects.
Below are shown some suggested attributes and methods for the various possible classes. You do not have to slavishly follow these examples, if you don’t understand them or wish to model differently that is allowed. NOTE: Depending upon your modelling not all components may be used. Below are suggested UML type diagrams representing the object types (classes):
Typical data to be found in the file is as follows:
Chainsaw CS001 59.95
Each line is compose of a name (space) model_number (space) price
If you do not use a file then you may 1 use structures and hardcode data as below:
product prods[10]={{"Chainsaw","CS001",59.95},etc.
2 use a class and hardcode data as shown below :
prods[0].createProduct("Chainsaw","CS001",59.95);
The Order object is responsible for building a list of products ordered via adding from the list of all products or deleting from the list of ordered products. Thus there are two lists in this program viz. the complete list of products and the list of ordered ones. Some sort of search facility would normally be part of the Order class. The Product class should be able to provide details such as name and price to other classes such as the Order class. If a file is used then it should be able to read a record from the file and load the data. If used the Web_shop class should load the complete list of products from the file, allow customer login, provide the on-screen menus and generate invoices. The Customer class is relatively simple just being able to provide details such as name to other classes and to accept/create details from the login process.
Your program should begin by offering a login prompt on screen. Once a username and password is accepted a customer can be created. At this point a menu of products should appear on screen. These products should either have been loaded from the file or have been hard-coded in the program. The user uses the menu to select products which are added to the order. A facility to quit this menu should be provided. The order thus far should then be displayed on screen. At this stage there should now be a facility to delete items in the order. This can be done on the basis of the name of the product. Once this phase is quit an invoice should be generated and displayed on screen. The program can then finish or the user logout.