Cafeteria Management System

Transcription

1 Cafeteria Management System by E3-111 {} {} {} {} {~ ~ ~ ~ ~ ~ ~ ~ ~ ~} { ~ ~ C A K E ~ ~ } { } {\/\/\/\/\/\/\/\/\/\/\/\/\} { C a f e t e r i a } {\/\/\/\/\/\/\/\/\/\/\/\/\} { } {\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\} { A n d } {/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/} { } {\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\} { K i t c h e n } {/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/} { } {\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\} { E f f i c i e n i z e r } {/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/} { } Is it a buzzword or is it useful? - Linas Bukauskas This document complies with the ISO-838 standard

2

3 Aalborg University Department of Computer Science TITLE: CAKE Cafeteria Management System. PROJECT PERIOD: DAT1 2. September december, 2004 GROUP: E3-111 MEMBERS: Anders Jensen Ole Toft Jensen Rune Zimmer Jensen Simon Kongshøj Jesper Brix Rosenkilde Henrik Otte Sørensen SUPERVISOR: Stardas Pakalnis SUMMARY: This report describes the process of analysis, design, implementation and test of the CAKE system. The CAKE system is a cafeteria management system, which allows the cafeteria to keep track of orders and stock. Furthermore the system is able to predict orders based on the actual sale. COPIES: 8 PAGES: 115 APPENDIX: 1 CD-ROM

4 Signatures Anders Jensen Ole Toft Jensen Rune Zimmer Jensen Simon Kongshøj Jesper Brix Rosenkilde Henrik Otte Sørensen

5 Contents I Analysis Document 6 1 Introduction 7 2 Pre-analysis Project Outline Problem Analysis System definition Problem demarcation Problem domain Clusters Structure Classes Item class Storage class Order, Expected Order and Placed Order classes Statistics class Recipe class Events Application domain Usage Overview Actors Use Cases Functions Statistics Predict orders Get today s orders

6 CONTENTS 5 Interfaces User interface Examples Summary 40 Page 2 II Design Document 41 7 Introduction Analysis vs. Design Quality Goals The criteria one by one Technical Platform Peripherals Software System Interfaces Languages Architecture Basic Architecture Component Architecture Components GUI Component Structure Classes WindowInterface MainWindow StockWindow RecipeWindow OrderWindow StatisticsWindow Function Component Structure Classes Stockhandler Recipehandler Orderhandler

7 CONTENTS Statisticshandler Predictionshandler Communication Component Classes Authenticator (Client) Queue (Client) Request (Client) Connection (Client) Authenticator (Server) Connection (Server) Listener (Server) Connection Model Classes Item Order Ingredient Recipe Logger Storage ModelHandler Persistence Component Structure Classes Persistence interface Persistence Database Recipe Order Item Storage Recipe_Ingredient Order_Recipe Ingredient Use case Interaction model Dialogue model Page 3

8 CONTENTS 13.3 Navigation chart Summary 74 III Implementation Document Introduction Design vs. implementation What was left out? What differs? GUI Function layer Model layer Persistence layer Communication layer GUI Model Function Function layer StockHandler IngredientHandler, RecipeHandler, OrderHandler PredictionHandler Persistence Summary 96 IV Test Document Introduction Black-box tests teststoragepersistence V Study Report Introduction 101 Page 4

9 CONTENTS 23 Technologies Used JDBC PostgreSQL GUI JUnit Why to test code Writing tests Prediction Least-squares method Persistence Database Management Systems Relational Database Management Systems Object Oriented Database Management System RDBMS vs. OODBMS Querying in RDBMSs Database design Process Analysis document The pre-analysis phase Moving on Summary Design document Implementation document Test document Conclusion The status of the CAKE system How to complete it What we have learnt Page 5

10 Part I Analysis Document 6

11 Chapter 1 Introduction The main purpose of this document is to present our results from the analysis of problem and application domain. It is important to understand the problem domain in order to specify a system definition and be able to identify classes. These classes are described in chapter 3. In the application domain, chapter 4, we focus on the users, and where they interact with our system. Furthermore, we present state diagrams for the use cases we have identified. 7

12 Chapter 2 Pre-analysis In this chapter we will describe the formation of our ideas and the process of building an understanding of the situation. We will analyse the problems involved to form an opinion about possible solutions for the problem. This process should lead to the formulation of a system definition which satisfies the FACTOR 1 principle. 2.1 Project Outline The project proposal, as originally described by our supervisor, is as follows (abridged version): Even small restaurants are concerned about having the right amount of products in storage. Restaurants which produce food for people coming in to eat as well as taking larger external food orders (e.g. for other restaurants, conferences, special events etc.) might have very varying number of orders, making repository management even more important. The aim of the project is to develop a software system which will help to plan product resources in a restaurant.[7] However, we wish to develop a more generalized, scalable system, not constraining ourselves to a specific type of food-processing organisation. Such a system should fit the following description: In a food-processing organisation, such as a cafeteria, a restaurant or even a large private kitchen, there are a number of management issues 1 The English translation of the BATOFF, Functionality, Application domain, Conditions, Technology, Objects, Responsibility 8

13 CHAPTER 2. PRE-ANALYSIS that need to be addressed. Topics such as expiration dates, items in storage, running out of food versus throwing away excess food, compiling menus to reflect food in storage or taking special diets into consideration, are all concerns of a food-processing organisation. The goal of the project is to develop a software system to support the management of food in a food-processing organisation. 2.2 Problem Analysis It was decided early in the project that the model organization for our analysis should be a cafeteria. We believe that the system that we intend to develop would find better use in a cafeteria than in a restaurant, because all the problems we wish to address are present in this particular kind of food-processing organisation. Since cafeterias often make large amounts of food every day (and have to keep the costs affordably low) they need better planning than a restaurant, which is characterized by smaller food productions and higher profit margins. We drew a rich picture depicting our impression of how the work flow in a cafeteria would function (see figure 2.2). The main functions of a cafeteria are food serving and food preparation, both of which are handled by the cafeteria employees. Serving to customers happens at a point of sale, which would typically simply be a cafeteria employee working a cash register, although other methods of sales handling would certainly be possible. Food items are kept in some kind of storage, which can either be central or decentral. Food preparation (e.g. the conversion of raw materials into food to be sold) can likewise be handled in a central or decentral manner. This problem is a variation on the general problem of storage management, for example moving food items between storage and the point of sale, and the preparation of food from raw materials (see figure 2.1). Figure 2.1 illustrates our perception of two major factors in a cafeteria, Food movement and Human resources. Raw goods and Processed goods are stored in the Storage and later moved to either the Kitchen (for processing), to the garbage (in the event that the expiration date is exceeded), or to the Sales point for sale. From the Sales point the goods are either moved back into storage, thrown away or sold to the customers. Employees are located at the Storage, the Kitchen or the Sales point. It would be convenient for customers to know in advance about things like price changes, the dish of the day, whether some item is currently out of stock, and similar things. One obvious way for a cafeteria to reduce costs is simply by reducing waste. By keeping track of which quantities of different food items the customers demand, it is possible to increase efficiency by making sure that no items ever pass their Page 9

14 CHAPTER 2. PRE-ANALYSIS expiration dates, to avoid having to throw food in the garbage. Another kind of waste is excess work: If kitchen staff waste time preparing lots of food items for which the demand is very small, this represents another factor of inefficiency. Raw goods Processed goods Storage Employees Kitchen Sales point Food movement Garbage Customer Human resources Figure 2.1: Cafeteria Page 10

15 Employees Food movement Area Human resources CHAPTER 2. PRE-ANALYSIS Customers Storage Storage Garbage Food delivery Raw goods delivery Figure 2.2: Rich picture, cafeteria Page 11

16 CHAPTER 2. PRE-ANALYSIS 2.3 System definition After an initial group discussion about the system, we arrived at a temporary system definition. We originally intended to run it by the manager of the Aalborg University cafeteria, but unfortunately he didn t show up for our appointment. We thus decided to stick with our original system definition. An electronic system for cafeteria management, which minimizes waste, keeps track of sales, and is capable of relaying information to the customers. The system should be able to assist with the menu and purchase planning. By keeping track of the cafeteria s current stock and prioritizing it by expiration date, the system should minimize wasted work effort and wasted food. Furthermore, the system should be able to register when the chef has finished converting unprocessed food items to processed food items. The system must integrate well with the cafeteria s current sales system (like cash registers) and be easy to adapt for future sales systems (for example, biometric sales systems 2 ). Apart from that, it must automatically generate relevant information about menus from the planning, and present it to the customers. All this makes a partially automated storage system, where the employees update the stock as they use it. The employees are divided in two groups: Administrators and cafeteria staff. The administrators handle purchase and planning, and the cafeteria staff handles cooking, sales and keeping the stock up to date. The system should be written in Java due to the high portability of the language, and the finished system should be able to run on inexpensive x86 PC hardware. One method for checking the completeness and usefulness of a systems definition for an object-oriented software system is the FACTOR criterion, checking whether the definition describes the Functionality, Application Domain, Conditions, Technology, Objects and Responsibilities of the system. For the above definition, this criterion is fulfilled like this: Functionality: Inventory management, menu and purchasing planning and presentation. Application Domain: The cafeteria employees, administrators and cafeteria staff. 2 Foodserve.com offers biometric sales systems for their point-of-sale systems. Page 12

17 CHAPTER 2. PRE-ANALYSIS Conditions: It must be possible to integrate the system into the existing sales system of the cafeteria. Technology: Java Virtual Machines on inexpensive x86 PC hardware. Objects: Orders, recipes, food items, storage. Responsibilities: A system which assists in purchase planning for a cafeteria Problem demarcation Purchase planning system Goods preparation system Goods database Sales system Information flow Customer information Figure 2.3: Problem domain subdivision This figure depicts the different areas of our system. All the parts interact with a central database that administrates shared information between the different subsystems. Purchase planning system is the part of our system that ensures that enough raw goods are available to keep the cafeteria from running out of some ingredient. The purchase planning system depends on information about expected Page 13

18 CHAPTER 2. PRE-ANALYSIS orders and food in stock, which is supplied by the central database. This system compiles a list of items needed with a given interval, so that restocking can be limited to e.g. once per week or twice per month Sales system keeps track of sales and income. This subsystem receives its information from points of sale, such as cash registers. The information gathered is relayed to the central database, so that stock information is always up to date. Customer information handles menus and price changes, so that customers always have access to the latest information about the cafeteria and its products Goods preparation system is responsible for all changes made to the goods in stock, for example when raw goods are combined to become a finished food item for sale. The goods preparation system can be fed a recipe, which if followed results in the used raw good being removed from stock and the finished product added to stock. Due to time constraints and staying true to the general idea of the system, we decided to narrow down our system definition. Thus, we only intend to develop the two parts of the system (See figure 2.3) marked with a dashed line. However, we chose to include the Goods preparation system and the Sales system as black boxes. This allows us to change the Goods database as the system would do in normal operation. The Goods preparation system black-box will deal with the orders and the Sales system black box will simulate sales. This makes our system more general in terms of usage, in the sense that a wider variety of organisations such as restaurants, cafeterias etc. can benefit from the system. Page 14

19 Chapter 3 Problem domain In this section, we will describe the classes and structures that make up our problem domain. We will gradually refine the definitions of the elements as we move from a general overview of the problem to a more detailed, closer look. 3.1 Clusters From our system definition we derive two basic clusters (see figure 3.1 that contain the classes necessary for achieving an understanding of the problem, using the Object-Oriented Analysis method. The Order cluster contain the classes Order, Placed order, Expected order and Recipe. The Order class is a generalisation of the two types of orders the cafeteria can receive from customers, which we refer to as Expected Orders and Placed Orders. The cafeteria will have a steady daily sale of certain items. Whether it is sandwiches, apples or cups of coffee, the cafeteria will have the products in stock and prepared, if the item needs to be before sale, in order to meet the daily demand. Thus the manager will have to estimate beforehand what he expects to sell on a given day. This is what the Expected Order class represents, the usual day-to-day sales in the cafeteria. The other order type (Placed Orders) represents any extraordinary sales surges known in advance. Examples could be an order to cater at a party of 150 people, an incoming convention near the cafeteria, basically any atypical sales situation. The order classes are logically connected to the task of planning what goods to shop for. An order interacts with the recipe to determine the amount of goods needed. A placed order is when a customer or group of customers have 15

20 CHAPTER 3. PROBLEM DOMAIN ordered a number of food items for a specific date, whereas an expected order is what the cafeteria staff expects to sell some given date. The Storage cluster consists of the classes Storage and Item since items need to be placed in some kind of storage. Items not in storage cannot be tracked, so they are of no interest to our system. 3.2 Structure We can further tighten the relationship between our classes. The class Storage consists of a number of objects of the class Item. Since our system does not need to concern itself with items that are not in storage, we define our basic structure with all items in storage. We can therefore unite the item and storage classes in an aggregation structure; a Storage object can contain any number of Item objects. An Order consists of references to the Items ordered, as well as references to the Recipes needed to make the ordered Items. We have two classes of orders (joined in the Order class using a generalisation structure), namely Placed Orders and Expected Orders. A Placed Order is an actual order that a customer has placed to the cafeteria, whereas an Expected Order is what the cafeteria staff has anticipated the cafeteria will sell in a given timeframe. It stands to reason that a cafeteria should keep statistics of its expected orders as well as how many of the items in an expected order were actually sold. A facility for keeping statistics (the class for which we imaginatively title Statistics) is not a part of any of the clusters we have defined, but is associated with our Order and Item classes since information from those classes are used to compute the statistics. 3.3 Classes In this section we further describe the characteristics of the four classes from our structure description before introducing the corresponding state charts. Page Item class The item class represents exhaustible objects that the cafeteria needs in its dayto-day operation, such as ingredients, processed goods, prepared meals, disposable utensils, etc. The item object contains properties of the particular item, such as name, physical location, purchase date, expiration date and supplier. These properties are used to determine when to buy new items, and to prioritise in which order to use them in order not to waste food by allowing it to exceed the expiration date. An

21 CHAPTER 3. PROBLEM DOMAIN Ord e r Placed order Expect ed order Orde r 1..* Re cipe 1..* 1 1 St at ist ics Stora g e 1..* 1..* St orage It em 1 1..* Figure 3.1: Problem domain, clusters Page 17

22 CHAPTER 3. PROBLEM DOMAIN item can be an ingredient (e.g. a bag of flour) or a finished product (eg. a piece of bread). Since we don t differentiate between ingredient items and processed items, it is possible to make food items of arbitrary complexity, creating a processed item from some ingredients and then using that processed item as an ingredient in a dish. One should not casually dismiss the use of recursion in cooking! The item class has been the basis of some discussion as to whether or not to put it in plural form. Because it was deemed to be practical to have single items, the class was decided to be in the singular form. Furthermore the exact definition of the class was under additional dispute here mainly due to some disagreements as to how it should handle prepared items and the items used to prepare it. It was however decided to take out the items used in the preparation and let the item just appear in the system as a new item when prepared. This means that we disallow compounds. During our discussion of this class we also considered how to represent the amount each physical item contains and whether to make one item with milk with the same expiration date or to make a separate item for each physical item so that a carton of milk and still contain an amount to make it possible to have less than a full carton if maybe half of it has been used. Attributes: Item name, remaining amount of the item, amount unit, expiration date, price, supplier. Figure 3.2: State chart for the Item Class Storage class Page 18 The storage class is a container class to hold item objects. It represents various sorts of storage area in the cafeteria, such as refrigerators, deep freezers, shelves, storages areas, depots etc. It contains a property which states the physical location of the storage. Attributes: Name and Physical Location.

23 CHAPTER 3. PROBLEM DOMAIN Figure 3.3: State chart for the Storage Class Order, Expected Order and Placed Order classes The Expected Order class is used to represent expected sales in the system. It can be used to represent an actual order (e.g. when a customer has placed an order on some food item one week in advance), or to represent the anticipated sales as calculated by the cafeteria management. The order class is a generalisation of the Expected order and Placed order classes, because the basic actions needed to be taken are similar, no matter whether an order represents a party that has ordered fifty batches of Swedish meatballs, or if the order was placed by the cafeteria manager because he/she believes that the cafeteria will sell fifty batches of Swedish meatballs that day. An order object consists of references to the items ordered, as well as references to any recipes required to meet the order. Having two separate classes for expected and actually placed orders allows the cafeteria staff to both make sure that they can cater to the needs of "normal" customers (through the pre-planned expected orders), while also allowing for special situations (in which a customer places an order in advance). The order class represents orders placed by customers to the cafeteria, not orders placed by the cafeteria to its suppliers. Page 19

24 CHAPTER 3. PROBLEM DOMAIN Customer Cancels Order Canceled Order Stored Order placed Order fulfilled Items delievered Figure 3.4: State chart for the Order Class Statistics class The statistics class represents the cafeteria s system for keeping track of which orders have been placed, and which items have been sold. Since the cafeteria prepares its daily stock according to what the staff expects to sell, it is important that it can keep track of which items are actually sold if the cafeteria has expected orders of fifty vegetarian meals per day and only ten are actually sold, they will be wasting money and ingredients. An object of this class consists of references to expected orders and references to items that have been sold and items that have been thrown away. By doing so, its functions include those that a receipt covers in the real world and statistics about waste that the cafeteria manager would probably keep. This class should be called Receipt or Invoice, had it only covered sale Recipe class The recipe class represents recipes, which in our terminology means methods to transform a number of raw goods in storage into a finished, sell-able product. The interesting property of this process isn t as much the procedure itself (we can assume that a chef knows how to cook, although a recipe object could also contain cooking documentation) as it is a specification of the items needed to perform it. As such, a recipe object contains a number of references to item objects, the number of each item required, and, if added by the cafeteria manager, a comment, e.g. a description of the procedure required to turn the items into the finished product. It also contains the price of one finished product created using the recipe. Attributes: Comment, Sales Price, Cost. Page 20

25 CHAPTER 3. PROBLEM DOMAIN Get recipe Recipe Available Recipe added Recipe removed Modify recipe Figure 3.5: State chart for the Recipe Class Events In this section the events believed to have significant impact on the model are described. The events are also presented in an event table (Table 3.1). Order Placed When the manager of the cafeteria receives an extraordinary order or plans what to produce to cover expected daily sales, he will place an order in the system. Order Canceled Should a customer cancel their order or should the manager want to cancel an expected order for some reason, he would cancel it in the system. Order Met When a cafeteria worker has prepared all the items required in an order, the order will have been met. Recipe Added When the manager decides to add a new dish to the cafeteria s menu, he must add a recipe to the system. Recipe Deleted Likewise, should he want to remove a dish from the menu, he can remove the recipe. Item Added to Storage Items will be delivered from suppliers and items will be prepared, which all will need to be added to storage. Page 21

26 CHAPTER 3. PROBLEM DOMAIN Order Recipe Storage Item Statistics Order Placed + Order Canceled + Order Met + Recipe Added + Recipe Removed + Item Added to Storage + Item Removed from storage + Item Sold + Item Expired + Table 3.1: Event table + denotes that the event can occur 0 or 1 times on the class denoted that the event can occur 0 or more times in the class Item Removed from Storage When items are sold, expired or use in preparation of meals they will be removed from storage. Item Sold The system will have to be notified that an item has been sold in order to track sales. Item Expired Practically all items in the inventory has a use before or expiration date, once that date is passed the item should not be used in a meal. Page 22

27 Chapter 4 Application domain The application domain consists of the cafeteria workers and the cafeteria manager. They need two different functionalities. The functionality for the manager should present a wider overview than that used by the cafeteria assistants. The manager would, for instance, require information about ordered raw materials, whereas the cafeteria assistants only need to know whether they have what they need for preparing the food for the day. 4.1 Usage In this section, we will describe how the actors interact with the system Overview The system has two actors, the planner and the executer. The planner will take an order and add it to the system, and then the executer(s) will fill the order. The planner is involved in four use cases, taking and cancelling orders, and adding and deleting recipes from the system. The executer(s) then check the stock, get what they need there, and buy new stock, if needed. When the executors use some raw material, they will remove it from the storage database Actors We have two actors in the system. These are the cafeteria worker and cafeteria manager. These will be presented in table 4.1 and

28 CHAPTER 4. APPLICATION DOMAIN Cafeteria worker Goals: A person, who works for the cafeteria. The responsibilities of this person is primarily to fulfill orders. Characteristics: The cafeteria workers are the ones maintaining the information in the storage. Table 4.1: Actor specifications for cafeteria worker Cafeteria manager Goals: A person who works for the cafeteria. The responsibilities of this person is primarily behind the scenes, taking orders and handling recipes. Characteristics: The cafeteria manager is the one buying new supplies for the storage Use Cases Take Order Table 4.2: Actor specifications for cafeteria manager When the manager needs to register a placed order, he will go through the Take Order procedure. The manager must input delivery date of the order, quantity of the items orders, and the recipe for the ordered items. Finally the manager can either save the order, or add more items to it. See figure 4.1 Cancel Order To cancel an order, a manager must first select which order to cancel, and then confirm that he really wants to cancel it. The order will then be removed from the system. See figure 4.2. Meet Order Figure 4.3 shows the state diagram for the "meet order" function. When the cafeteria worker must fulfill an order, the worker must first select the wanted order. Then the worker can either print out the order, mark an item prepared or close the order. Once all items in the order are marked as prepared them order will changed state to met. Page 24 Add Recipe This use case will occur when the cafeteria manager wants to add a new recipe to the system. The manager will be asked for the name of the recipe. Then he must add the one or more items needed for recipe from the list of known items, as well

29 CHAPTER 4. APPLICATION DOMAIN Use Case Cafeteria Manager Cafeteria Worker Take Order Cancel Order Meet Order Add Recipe Delete Recipe Prepare Item Add to Stock Check Stock Check Condition Show Statistics Table 4.3: Actor table Take order Order taken Give userspace unique ID Save order Ask for deliverydate Order complete Wait for deliverydate Save recipe deliverydate recieved Save deliverydate Ask for recipe Recipe recieved Wait for recipe Ask for number of dishes Ask for recipe Wait for number of dishes Save number of dishes number of dishes recieved Figure 4.1: State diagram for taking orders. Page 25

30 CHAPTER 4. APPLICATION DOMAIN Ask for order identification Cancel order Wait for order id Order not found done Delete rejected Recieved order id Look up order Order removed Order found Remove order Ask for confirmation Show order Delete confirmed Wait for confirmation React on confirmation Confirmation recieved Figure 4.2: State diagram for canceling orders. as the amounts needed of said items. He also has the option of creating new items in the system, which could be needed for the recipe. finally The total cost to make the recipe will be shown and a sales price must be entered. See figure 4.4 Delete Recipe The manager can delete a recipe from the system with the Delete Recipe function. He must choose one or more recipes to be marked for deletion. After the manager requests that the marked recipes be deleted, he will be asked to confirm that these recipes should be deleted, before they actually are deleted. See figure 4.5 Add to Stock When new items are delivered the user will register them in the system, by going through the Add to stock use case. First he will enter or scan the bar code of the item, then enter how many of that particular item needs to be added, choose where the item or items should be stored by selecting a storage area, and finally the purchase price paid per item. He can then either add another item or end the procedure. See figure 4.6 Page 26

31 CHAPTER 4. APPLICATION DOMAIN Meet order Ask for order Wait for order Item marked prepared Order recieved Display items needed in order All items in order marked prepared Printout requested Printing complete Order closed Order met Printing Done Figure 4.3: State diagram for meeting order. Page 27

32 CHAPTER 4. APPLICATION DOMAIN Add recipe Ask for name Wait for name Done Save recipe Save comment Comment recieved Wait for comment Name recieved Save name Name already exists Ask for comment to recipe Save price Price recieved Ask for items in recipe Wait for item Ask for another item in recipe Wait for price Create Item Item recieved Ask for sales price Add item to storage Item recieved Add item to recipe Figure 4.4: State diagram for adding recipes. Page 28

33 CHAPTER 4. APPLICATION DOMAIN Delete recipe Ask for recipe to delete Wait for recipe Recieved Recipe Delete cancelled Recipe marked Ask for confirmation Recipe deleted Confirmation received Delete confirmed Delete recipe Figure 4.5: State diagram for deleting recipes. Add item to stock Ask for barcode Add to stock closed Wait for barcode Add another item Barcode received Barcode lookup Barcode is unknown Create item Store item Barcode is known Barcode is now known Price received Wait for number of items Wait for price Ask for storage area Ask for price Wait for storage area Storage received Assign storage area Figure 4.6: State diagram for adding new items to storage. Page 29

34 CHAPTER 4. APPLICATION DOMAIN Check Stock Check stock opened Ask user to select storage and/or item Wait for storage and/or item Storage and/or Item received Item marked for deletion Another item selected Display contents Check stock closed Printout requested Another storage selected Printing Deletion requested Deleting Item(s) Figure 4.7: State diagram for checking which items are in stock. A user can inspect the contents of a storage or all storage area for all items or a particular item with the Check Stock function. First the user will be given the option of limiting the inventory display by inputing a specific storage and/or item. Then the current inventory with the specified parameters will be shown. The user can then either specify new parameters, request a printout of the shown inventory, mark an item for deletion, delete marked items, or end the inventory display. See figure 4.7 Page 30

35 CHAPTER 4. APPLICATION DOMAIN Check Condition The user can check the storage for items that are expired by using the Check Condition function. First all stored expired items will be shown. The user can then either request a print out the currently shown expired items, mark an item for deletion, select which storage areas expired items should be displayed from, delete the marked expired items, or end the function. See figure 4.8 Show Statistics The manager can look at statistics generated by the system. To do so, he must first input the time range from which to show statistics from. Then he can narrow down the displayed statistics by selecting a specific item or order, request a printout of what s currently shown or close statistics. See figure: Functions In this section we will present a list of functions, describe their complexity and define which type of functions they are. Table 4.4 contains a list of functions that our system will implement. The table also lists the complexity and type of functions. We have chosen only to describe the two most complex functions (Predict Order and Statistics) algorithmically Statistics The Statistics function is invoked every time an order is met. It increases the number of items sold in the active period. Statistics: given an item add 1 to number of items sold over time period given period return number of items sold in period Predict orders The Predict order function is invoked in the beginning of each period. It returns the number of items sold in a given period, plus a given deviation, to avoid a production deficiency and empty stock. Page 31

36 User selects the check condition dialog CHAPTER 4. APPLICATION DOMAIN All storage selected Storage selection changed Item is marked for deletion Expired Items in storage are shown Close dialog selected Printing is completed Delete marked items requested Printing Print out of expired items is ordered Wait for confirmation Deletetion confirmed Deletion canceled Items deleted Deleting items Figure 4.8: State diagram for checking the condition of items in stock. Page 32

37 CHAPTER 4. APPLICATION DOMAIN Ask for date range Wait for date range Date range change requested Date range received Sales statistics shown Statistics closed Item parameters changed Order parameters changed Printout requested Printing complete Printing Figure 4.9: State diagram for showing statistics. Page 33

38 CHAPTER 4. APPLICATION DOMAIN Functions Function Complexity Type Take order Simple Update Cancel order Simple Update Get order Simple Read Get today s orders Medium Compute Add recipe Simple Update Delete recipe Simple Update Get recipe Simple Read Buy item Simple Update Sell item Simple Update Check item condition Simple Read Add item to storage Simple Update Remove item from storage Simple Update Check stock Simple Read Statistics Medium Compute Predict orders Medium Compute Table 4.4: Function List Predict orders: given a period and an item query Statistics for number of items sold in period return number of items plus a given deviation Get today s orders The View today s orders is invoked when a cafeteria worker requests information on the day s task. It returns the day s orders. Get today s orders: given the day query Get order for items of the day Page 34

39 Chapter 5 Interfaces 5.1 User interface We intend to develop a simple user interface which can be operated by anyone with only a little experience. The system should be fast to use, to ensure that the users are not inhibited in their daily routines. This user interface illustrates our solution to this. The system has a single window for each major task, roughly corresponding to the classes described earlier. The system uses buttons and input fields for all actions, minimizing the need for any prior knowledge to be able to use the system. The user interface we intend to develop should be composed as follows. Main screen Todays tasks Return to main View todays orderss Order meet Select a specific order and press view order View order Figure 5.1: Navigation chart for the staff 35

40 Figure 5.2: Navigation chart for the manager Page 36 Add recipe add done Take order View recipes delete done Delete recipe return after yes/no dialog take order done recipes return return stock Cancel order View orders Main screen Check stock select specific order press cancel orders return change move statistics return add done Change order Statistics Add item predict orders done Predict orders CHAPTER 5. INTERFACES check done done Check item condition remove Remove item

41 CHAPTER 5. INTERFACES Most of the functionality is reasonably simple. The largest single problem in terms of overview is the managing of items. In the working system there will be a lot of items with different attributes, so an extended list is needed to create overview. This list should be able to sort items according to their expiration dates, content levels etc. This situation is depicted below Examples The following examples should illustrate how the system should be presented to the user. These examples are temporary, and only used to describe the general idea of the user interface. Figure 5.3: Main menu window Page 37

42 CHAPTER 5. INTERFACES Figure 5.4: View Orders window Figure 5.5: View Recipes window Page 38

43 CHAPTER 5. INTERFACES Figure 5.6: View Statistics window Figure 5.7: Check Stock window Page 39

44 Chapter 6 Summary In this document we have started the Object Oriented Analysis & Design process. This process includes the pre-analysis with the system definition, the problem domain, where the structure of the system and its functions was designed. In the application domain, we isolated the users of the system, and mapped their usage of the system. Based on this, we made some drafts of the graphical user interface. 40

45 Part II Design Document 41

46 Chapter 7 Introduction This part of the report will describe in detail how we intend to implement our system. We will work with the material in our analysis and come up with a solution we find satisfying. We will furthermore describe how our design differs from our analysis. Our system will be designed corresponding to the UML notation introduced in Object Oriented Analysis & Design[6]. 7.1 Analysis vs. Design One of the major changes from the analysis to the design is the inclusion of an Ingredient class. This was done from a programming perspective, since it is overly complicated to implement the compound structure of the Order, Recipe, Item relationship. The Statistics class has been renamed to the more descriptive name Logger, which will log every database transaction. The Placed Orders class will be replaced with with an attribute in the Orders class called OrderType, this is done because for easier data storing and programming. 42

47 Chapter 8 Quality Goals In this chapter, we will create a checklist of our prioritized design criteria. Table 8.1 shows these priorities. 8.1 The criteria one by one - Usable: The system s adaptability to the organizational, work-related and technical contexts. We rate the system s usability as less important. Although the system has to be easy enough for users to use, usability and interfaces will not be our main focus in this project. - Secure: The precautions against unauthorized access to data and facilities. This criterion is important. If the database is to be trusted, it is important that nobody can add or remove anything without being granted permission to do so. On the other hand, the database is storing recipes for food and not nuclear launch codes, so it would be overkill to implement paranoia-grade security. - Efficient: The economical utilization of the technical platform s facilities. We have marked this criterion as less important to our system. The system should be able to run on reasonably modest hardware, but on the other hand, there shouldn t be any need for any particularly CPU-hungry operations anyway. The Java Virtual Machine takes care of the utilization of hardware and OS resources, although in a Java project, efficiency becomes a question of efficient utilization of Java as a platform rather than utilization of the hardware itself. - Correct: The fulfillment of requirements. We rate this criterion as important, because the system is useless if it yields 43

48 CHAPTER 8. QUALITY GOALS Criterion Very important Important Less important Irrelevant Trivial Usable Secure Efficient Correct Reliable Maintainable Testable Flexible Comprehensible Reusable Portable Interoperable Table 8.1: Design criteria Page 44 incorrect results from its calculations. On the other hand, this shouldn t be too difficult to achieve, given that our system won t be used for any complex scientific calculations. - Reliable: The fulfillment of the required precision in function execution. The reliability of the system is very important, as it is a base for continuous usage. If a cafeteria relies on our system for management, and the system suffers frequent failures, it would increase costs rather than decrease them. - Maintainable: The cost of locating and fixing system defects. We rate the maintainability of our system as important. A maintainable system is characterized by clear, understandable code organized in logical modules. In virtually all real-life software systems, much more time is spent maintaining code than initially writing it, and as such it should be a goal for any reasonable software system to be as maintainable as possible. - Testable: The cost of ensuring that the deployed system performs its intended function. We have rated this criterion important. Since we have rated the system s correctness important, it follows that there must be a good way to reliably test whether this quality goal has been met. - Flexible: The cost of modifying the deployed system. This criterion is less important to us. Mainly this is because the system is

49 CHAPTER 8. QUALITY GOALS built for a specific purpose under predictable conditions. - Comprehensible: The effort needed to obtain a coherent understanding of the system. This criterion is rated important, since the system will be used mainly by non- IT personnel. As such it should be easy for users to understand how to use the system. - Reusable: The potential for using system parts in other related systems. Code reuse is a good thing. We ve considered this criterion important because code reuse is nearly universally regarded as good software development practice. This is for good reason: No programmer should waste time reinventing the wheel except for innovative new wheel designs, of course. - Portable: The cost of moving the system to another technical platform. As the system will be written in Java, it will run on any platform that has a Java virtual machine implementation. This criterion is therefor trivially fulfilled. - Interoperable: The cost of coupling the system to other systems. This criterion is less important to us. The system should be interoperable with the existing sales and storage infrastructure of a cafeteria, although due to time constraints we have chosen not to focus on this in the project. Page 45

50 Chapter 9 Technical Platform The purpose of this chapter is to get an overview of the environment and the system peripherals. This overview dictates the conditions after which we design the system. 9.1 Peripherals The only equipment needed is what the cafeteria already have at their disposal. A computer connected to the Internet and hooked up to the cash register(s). This setup should be found at all the locations where the system is meant to run. The only requirements for any auxiliary equipment such as a computer set up for administrative use, is connection to the Internet. 9.2 Software All computers interacting with the system must be able to run the JRE We have chosen Java 5 over Java 2 because of some significant features included in Java 5, which we might as well benefit from. Specifically, the enum type and Java 5 generics proved very useful for the implementation. Ultimately the system needs a central database, for testing purposes we choose PostgreSQL, which is an relational database server (RDBMS). 9.3 System Interfaces The system will require an interface to the point of sale which is usually a cash register or a POS system 2. This interface is necessary to tell the system when an 1 Java Runtime Environment 1.5 (Java 5) 2 Point Of Sale system 46

51 CHAPTER 9. TECHNICAL PLATFORM Command Initialization Activate registration of sales Purpose Prepare the information exchange Let the system know of sales Table 9.1: Protocol for cash register interface item is sold and update the storage and take care of the statistics. The protocol for this interface is described in table 9.1. The actual implementation of an interface to POS hardware is outside the scope of this project, however. The system also needs to interface with the database. All the functionality needed is built into Java, through JDBC, so everything should run pretty smoothly. Both the cash register and the database will be included as black-boxes. The database will be implemented only as an example for testing reasons, and so will only support PostgreSQL. 9.4 Languages We have chosen to implement our system in Java with Java Swing as a graphical front-end, as opposed to Java Server Pages (JSP) which is viewed with a web browser. See chapter 23. Page 47

52 Chapter 10 Architecture 10.1 Basic Architecture We choose to structure our system after the client-server architectural model. The server component is responsible for providing a model of the stock of the cafeteria, and a number of clients can connect to that server to query or modify that model. One example of such a client could be a manager s interface, which allows a cafeteria manager to add orders or change the stock. Another example is a customer information terminal, which would allow a customer to see what today s special is, and whether some item is currently out of stock. For the server itself (and the managers client we will implement to demonstrate the system), the layered architecture (originally conceived by Edsger W. Dijkstra) appears to be the most useful. As such, our system architecture becomes a heterogenous architecture, including aspects of both client-server and layered system design. The defining characteristic of the layered architecture style is that the application is structured in logical layers, each of which is only allowed to invoke a layer one level below or one level above itself. The benefit of this organization is clarity: It is possible to achieve a logical, clear model of the application, in which individual layers have clearly defined areas of responsibility. The "strict" form of this organization means that each layer provides a service to the layer above it, and acts as a client for the layer below it that is, layers may request services from the layer below themselves, but never from the ones above. This model lends itself well to our particular application, because we can provide an outer layer which implements the user interface, and keep the function and model components in separate layers. 48

53 CHAPTER 10. ARCHITECTURE Management GUI Function Communication Communication Sales Preperation Persistence Figure 10.1: The architecture of our system. Notice that Sales and Preparation are black-boxes Component Architecture The system has four parts which are connected to each other through the persistence layer, using a communications protocol. This makes the system extensible, by allowing its administrator to change to another database if necessary. This is modelled informally on figure We decided that the optimal architecture would be the client-server model, in which the persistence layer represents the server. This model also adds to the extensibility of the system, as it allows new components to be added into the system easily (since a component programmer only needs to know about the communication interface). Each client should be able to have some form of local persistence, which is especially important in the black box sales system, to allow points of sale to still be able to sell even if the connection to the server is lost. The management part of the system will have a local queue in case the connection gets lost to the central database. There are two black boxes in our system: The preparation and the sales system. These two black boxes are there to give the system we will implement information concerning the real activities in the cafeteria. These black boxes are not necessarily written in Java. For the Purchase and planning system and the Goods database we have chosen a strict, closed layered architecture, see fig We made this choice in order to make the system as extensible as possible, by allowing to change a layer without changing the other layers. This is possible because the layers must work with welldefined interfaces, which abstract away the actual implementations of the layer. Page 49

54 CHAPTER 10. ARCHITECTURE Clie n t < < com p on e n t > > GUI < < com p on e n t > > Fu n ction < < com p on e n t > > Com m unication Se rve r < < com p on e n t > > Com m unication < < com p on e n t > > Mod e l < < com p on e n t > > Pe rs ite n ce Figure 10.2: Deployment diagram of our system If we see system as a whole it is also a strict closed architecture, since there is no need for the Goods database to call anything in the Purchase and planning system. This allows for an entire component to be rewritten without affecting the other components. The communication layer represents a protocol for calling the model from the function layer, in a real-life system this would be implemented using a network protocol. This, however, is beyond the scope of our project, so we have chosen just to make it a transport layer that could be extended to run over a network. The server will handle most of the computation such as constructing new objects, turning objects into data and storing them. The persistence wrapper is another layer made to make the system as extensible as possible, it makes it possible to store the data in any form, with small alterations to the layer. The actual persistence can theoretically be implemented by anything from an Oracle database, to a collection of XML files or, in theory, a deck of punch cards. Page 50

55 Chapter 11 Components 11.1 GUI Component In this section, we will describe our GUI component. The purpose of this component is to draw and handle the windows which are used for user interaction Structure The structure of this component is described in figure Classes WindowInterface Purpose: The purpose of the WindowInterface is to create a common structure for the GUI, so it will be easy to extend and rewrite. Attributes This class has no attributes. Operations - Draw: This operation adds all the components of the window. - Show: This operation shows the window. - Hide: This operation hides the window. - Destroy: This operation removes the window completely. 51

56 CHAPTER 11. COMPONENTS Figure 11.1: GUI Layer Page 52

57 CHAPTER 11. COMPONENTS MainWindow Purpose: The purpose of the MainWindow is to create and handle the first window the user is presented to. Attributes This class has no attributes. Operations - Draw: This operation adds all the components of the window. - Show: This operation shows the window. - Hide: This operation hides the window. - Destroy: This operation removes the window completely. - Exit: This operation makes sure the program exits cleanly and updates all data worked on StockWindow Purpose: The purpose of the StockWindow is to create and handle all aspects of inventory handling the user will be presented to. Attributes This class has no attributes. Operations - Draw: This operation adds all the components of the window. - Show: This operation shows the window. - Hide: This operation hides the window. - Destroy: This operation removes the window completely RecipeWindow Purpose: The purpose of the RecipeWindow is to create and handle all aspects of recipe handling the user will be presented to. Attributes This class has no attributes. Page 53

58 CHAPTER 11. COMPONENTS Operations - Draw: This operation adds all the components of the window. - Show: This operation shows the window. - Hide: This operation hides the window. - Destroy: This operation removes the window completely OrderWindow Purpose: The purpose of the OrderWindow is to create and handle all aspects of order handling the user will be presented with. Attributes This class has no attributes. Operations - Draw: This operation adds all the components of the window. - Show: This operation shows the window. - Hide: This operation hides the window. - Destroy: This operation removes the window completely StatisticsWindow Purpose: The purpose of the StatisticsWindow is to create and handle all aspects of viewing the statistics the user will be presented with. Attributes This class has no attributes. Operations - Draw: This operation adds all the components of the window. - Show: This operation shows the window. - Hide: This operation hides the window. - Destroy: This operation removes the window completely. Page 54

59 CHAPTER 11. COMPONENTS 11.2 Function Component In this section we will describe our function component. The purpose of this component is to provide functionality to the system Structure The classes contained in the functions layer are shown on figure Classes Stockhandler Purpose: The purpose of this class is to get and send user interface requested stock data from the the model layer through the communication layer. Attributes This class has no attributes. Operations - View: View the current stock. - Add: Add new item to stock. - Remove: Remove an item from stock. - Update: Update an item already in stock. - Sort: Sort items in stock from given criteria. - Search: Search the current stock for a given item Recipehandler Purpose: The purpose of this class is to get and send user interface requested recipe data from the the model layer through the communication layer. Attributes This class has no attributes. Page 55

60 Page 56 Function Com ponent CHAPTER 11. COMPONENTS Figure 11.2: Functions Layer St ockhandler + lis t():stora g e [] + list(storage:storage):item [] + add(nam e:string,location:string):storage + add(am ount:double,storage:storage,expirationsdate:date,purchaseprice:bigdecim al):item + rem ove(storage:storage):void + rem ove(item:item):void + change(storage:storage):void + change(item:item):void + op e ra tion _6():void Ingredient Handler + ls it():in g re d ie n t[] + add(nam e:string,unit:string):ingredient + rem ove(ingredient:ingredient):void + change(ingredient:ingredient):void RecipeHandler + lis t():re cip e [] + add(nam e:string,com m ent:string,ingridient:ingridient,double:double,saleprice:bigdecim al):recipe + rem ove(recipe:recipe):void + change(recipe:recipe):void OrderHandler + lis t():ord e r[] + add(nam e:string,custom m er:string[],deliverydate:date,recipe:recipe,int:int,[]:[]):order + rem ove(order:order):void + change(order:order):void Predict ionhandler + liststatistics(data:string[]):string[] + m akeprediction(string:string[],scale:double):order

61 CHAPTER 11. COMPONENTS Operations - View: View the current recipes. - Add: Add a new recipe. - Remove: Remove a recipe. - Update: Update an already known recipe. - Sort: Sort recipes from given criteria. - Search: Search for an already known recipe Orderhandler Purpose: The purpose of this class is to get and send user interface requested order data from the the model layer through the communication layer. Attributes This class has no attributes. Operations - View: View the current orders. - Add: Add a new order. - Remove: Remove a recipe. - Change: Change an already taken order. - CheckStatus: Check the status of a gives order. - Update: Update an already present order. - Search: Search for an already present order. - Sort: Sort orders from given criteria Statisticshandler Purpose: The purpose of this class is to get and send user interface requested statistics data from the the model layer through the communication layer. Attributes This class has no attributes. Page 57

62 CHAPTER 11. COMPONENTS Operations - View: View statistics about a given item type Predictionshandler Purpose: The purpose of this class is to predict future sales from sales and orders data, given a well defined time interval. Attributes This class has no attributes. Operations - Predict: Predict future sales Communication Component In this section, we will describe our communication component. The purpose of this component is to serve as the link between the central persistence layer and the remote clients. We will not implement this component Classes Authenticator (Client) Purpose: The purpose of this class is to encapsulate the authentication of the server. To avoid connecting to the wrong server, it is important to make sure that the server is exactly who it claims to be. Attributes - pubkey: The public key used to encrypt a message. - privkey: The private (secret) key used to decrypt a message encrypted with the corresponding public key. Operations - auth: This operation validates the key supplied by the server, and recognises the server if the key is correct. Page 58

63 CHAPTER 11. COMPONENTS Queue (Client) Purpose The purpose of this class is to queue data before they are sent through the connection. This will enable some operations in the function layer, even though a connection to the server is not established. Attributes - queue: The queue containing the requests not yet sent. Operations - push: This operation enqueues data to be send through the connection. - pop: This operation dequeues data, when it has been send to the server Request (Client) Purpose The purpose of this class is to Attributes - objecttype: Model-layer class reference. - callmethod: The method that should be called on the object object type. Operations This class does not have any operations Connection (Client) Purpose: The purpose of this class is to take care of the connections, which the authenticator class has allowed to connect. Attributes - queue: Operations - connect: This operation establish the connection between client and server. Page 59

64 CHAPTER 11. COMPONENTS Authenticator (Server) Purpose: The purpose of this class is to encapsulate the authentication of the clients. To avoid a third-party to change the data in the persistence layer, it is important to make sure that the client has the necessary permissions to access the connection. Attributes - pubkey: The public key used to encrypt a message. - privkey: The private (secret) key used to decrypt a message encrypted with the corresponding public key. Operations - auth: This operation validates the key supplied by the client, and grants access if there is a match Connection (Server) Purpose: The purpose of this class is to take care of the connections, which the authenticator class has allowed to connect. Attributes This class does not have any attributes. Operations - accept: This operation establish the connection between client and server. - handlerequest: This operation handles the request received from the client Listener (Server) Purpose: The purpose of this class is to spawn a new thread, which a distinct client connects to. Attributes: - listenport: The port on which the listener thread is active. Page 60

65 CHAPTER 11. COMPONENTS Operations - listen: This operation activates the connection on the given port. - createconnection: This operation activates the connection on the given port Connection Purpose: Attributes - remotehost: A string value containing the name that the remote host is known by. - remoteport: An integer value containing the port to connect to on the remote host. Operations - close: This operation closes the connection to the remote host. - send: This operation sends data to the remote host. - receive: This operation receives data from the remote host. - serialise: This operation prepares objects to be sent over network. - unserialise: This operation prepares objects to received over network Model This layer will represent the model of the cafeteria. These classes will be similar to the ones described in the problem domain of the analysis document Classes Item Purpose: The Item class models exhaustible resources used in the cafeteria. Page 61

66 CHAPTER 11. COMPONENTS Com m unication Com ponent (Client) Connect ion - q u e u e:qu e u e + con n e ct():void * Aut hent icat or - p u b ke y:strin g - p rivke y:strin g + auth(pubkey:string):boolean * Queue Request q u e u e:re q u e s t + push(obj:object):void + p op ():Ob je ct - ob je cttyp e:strin g - ca llm e tod:strin g * Connect ion - re m ote h os t:strin g - re m ote p ort:in t Com m unication Com ponent (Server) * Connect ion List ener + clos e():void + s e n d(ob j:ob je ct[]):void + re cie ve():ob je ct[] - s e ria lis e(ob j:ob e jct[]):b yte [] - u n s e ria lis e(d a ta:b yte []):Ob je ct + a cce p t():void + handlerequest(request:request:):object[] * * - lis te n p ort:in t + lis te n():void - cre a te con n e ction():con n e ction Aut hent icat or - p u b ke y:strin g - p rivke y:strin g + auth(pubkey:string):boolean Figure 11.3: Communication Layer Page 62

67 CHAPTER 11. COMPONENTS Attributes - id: Unique id that identifies the object. - amount: The amount of the Item, given in the unit. - storage: The storage, the Item is in. - expirationdate: When the Item expires. - purchasingprice: Containing the price paid for the item. Operations This class does not have any operations Order Purpose: Represents orders received by the cafeteria to the system. Attributes - id: Unique identity of the order. - name: The name of the order. - Customer: Customer identification. - deliverydate: Date when the order should be filled. - recipes: Recipe and number of them to be delivered. Operations This class does not have any operations Ingredient Purpose: A helper class for the Recipe class. Attributes - id: Identification id.. - name: Name of the ingredient. - unit: Unit, in which the amount of an Item is measured. Operations This class does not have any operations Page 63

68 CHAPTER 11. COMPONENTS Recipe Purpose: Contains the needed information on how many ingredient items are needed to prepare a dish. Attributes - id: Id identifying the recipe. - name: Name of the recipe. - comment: Comment on the recipe. - ingredients: Set of Ingredients and amounts used in the recipe. - salesprice: Price of the prepared dish. Operations This class does not have any operations Logger Purpose: This class logs the activity between the connection and the persistence layer, for use in the statistics system. Attributes - obj: Object that has been sold. - date: Date of sale. - requesttype: Type of log-request. Operations - log: Adds a set of object, date and requesttype to the log. - savelog: Saves log. - getstatistics: Returns a set of objects and number of them sold within a given time Storage Purpose: Represents a physical storage area in the cafeteria. Page 64

69 CHAPTER 11. COMPONENTS Attributes - id: Unique identifier for storage. - Name: Name of the storage area. - Location: Physical location the storage area. Operations This class does not have any operations ModelHandler Purpose: This class works as an interface for the classes Recipe, Order, Item, Ingredient and Storage in the model-layer. Attributes This class does not have any attributes. Operations - createobjects: Creates an empty object. - createspecificobjecttype: Creates items of a specific type. - createdepobj: Creates dependency objects. - saveobjects: Saves object. - savedepobj: Saves dependent objects Persistence Component In this section, we will describe our persistence component. To provide database or file-system accessibility for our system we need an persistence component. Once data is introduced into our system, we need to be sure that it stays there, unless we state otherwise; we need the data to be persistent, which is ensured by the persistence component. The persistence component will take commands from the communication layer and handle it appropriately. For example we will need to be able to tell the system to store a piece of data, a functionality provided by the persistence component, regardless of the database or file-system in which it is to be stored. Page 65

70 CHAPTER 11. COMPONENTS Model Com ponent 1..* Ingredient + id :in t + nam e:string + unit:string Recipe + id :in t + nam e:string + com m e n t:strin g + ingredients:(ingredient,double )[] + salesprice:bigdecim al * It em + id :in t + am ount:double + storage:storage 1..* + expirationdate:date + purchaseprice:bigdecim al * * * * * Order + id :in t + nam e:string + custom er:string + deliverydate:date + re cip e s:(re cip e,in t)[] - ord e rtyp e:strin g * St orage * + id :in t + nam e:string + location:string - ob j:ob je ct - d a te:da te - re q u e s ttyp e:strin : g Logger + log (obj:object,date:date,requesttype:string):void - s a ve log(log :Log g e r):void + g e ts ta tis tics():strin g [] < < in te rfa ce > > M odelhandler + createobjects(type:string):object[] + createspecificobject(type:string,id :int):object + createdepobj(type:string,id :int):object[] + saveobjects(obj:object[]):void + savedepobj(obj:objects):void Figure 11.4: Model Layer Structure The structure of this component is described in figure Pe rs is te n ce Com p on e n t < < in te rfa ce > > Persist ence Int erface + ge tobjda ta(type:string,id :int):string[] + ge tobjda ta(type:string):string[] + store objda ta(da ta:string[]):void Persist ence + ge tobjda ta(type:string,id :int):string[] + ge tobjda ta(type:string):string[] + store objda ta(da ta:string[]):void Figure 11.5: Persistence Layer Classes Persistence interface Purpose: The purpose of the persistence interface is to provide tools for communicating with an underlying database or file-system. Attributes This class has no attributes Page 66

71 CHAPTER 11. COMPONENTS Operations class The operations for this class will be described under the Persistence Persistence Purpose: The purpose of the persistence handler is to communicate directly with the database or file-system, taking and handling commands from the persistence interface. The persistence handler is a handler for a number of database and file-system types, so that no matter which database or filesystem is used to store the data, it happens. Attributes This class has no attributes - getobjdata: This operation is overloaded and will either return the data for one or many objects of one type depending on whether it gets an id as the second argument. - storeobjdata: This operation will handle the storing of the object data in the database Page 67

72 Chapter 12 Database Our database consists of 7 tables, which are separated into two categories, the actual items and their relations Recipe Our table recipe holds the recipes. These recipes consists of a name and a price, and additionally they can have a comment as well. Column Type id bigserial name text comment text salesprice double precision 12.2 Order The table order contains information about orders, their name, who ordered it, when it should be delivered, and what state the order is in. Column Type id bigserial name text customer text deliverydate timestamp without timezone ordertype integer state integer statechanged timestamp without timezone 68

73 CHAPTER 12. DATABASE 12.3 Item The table item holds items in the storages. Column Type id bigserial name text amount double precision expirationdate timestamp without timezone state integer statechanged timestamp without timezone ingredient_f foreign key to id of ingredient order_f foreign key to id of order storage_f foreign key to id of storage purchaseprice double precision 12.4 Storage The table storage holds information about the available storage areas. Column Type id bigserial name text location text 12.5 Recipe_Ingredient The table recipe_ingredient links between recipes and ingredients. Column Type recipe_f foreign key to id of recipe ingredient_f foreign key to id of ingredient amount double precision 12.6 Order_Recipe The table order_recipe links between recipes and orders. Column Type recipe_f foreign key to id of recipe order_f foreign key to id of order amount integer Page 69

74 CHAPTER 12. DATABASE 12.7 Ingredient The table ingredient contains information about the ingredients the system knows of. They have a unit, in which the item amount will be measured. Column Type id bigserial name text unit text Page 70

75 Chapter 13 Use case There are a number of possible use cases associated with the system. In this chapter, we will describe the use case for the management interface Interaction model To identify the interactions the system should handle, an interaction model is used. As an example of this, we have made an interaction model for the process of displaying stock information, based on storage and item information. As seen on figure 13.1, we have two views. Storage view, which contains a list of available storages, and an Item list, which can display all items, or limit the list to match the items in a specific storage. From the storage view, the user can select a specific storage as a limit for the item list. As an alternative, the item list can be shown with an Item as a limit. This would give a list of items in any storage Dialogue model The dialogue model is a way to show the dialogues and their internal relationship on a time line. Figure 13.2 shows our dialogue model for the stock part of the system dialogues. The dialogue time line starts in the Open storage window, from where the user can reach Add storage, Select storage and Select items. When a storage has been selected, it is possible to Remove storage, Add item, View item list and Select items. From the Select items dialog, it is possible to Delete item, Modify item and View item list. From View item list, it is possible to Sort items to sort the item list. 71

76 CHAPTER 13. USE CASE Storageview Select storage Storage Stock Itemlist Retrieve Itemlist Item Figure 13.1: Interaction model for Storage view Add storage Open storage window Remove storage Select storage Select items Add item View itemlist Delete item Modify item Sort items Figure 13.2: Dialogue model for Storage Page 72

77 CHAPTER 13. USE CASE 13.3 Navigation chart A navigation chart is a way to represent how the dialogs are related to each other. Our navigation chart on figure 13.3 represents the entire administration interface. The first window a user is presented with, is the Main window. This window can open the orders, recipe, statistics and storage windows, and furthermore this is where the program is to be ended. From the order window, the remove and add order windows can be reached. If the user quits from this window, he will be returned to the main window. The remove and add order windows both return to the order window on quit. In the recipe window, the add and remove windows can be triggered. A quit from this window, will return the user to the main window, while a quit from the two sub-windows (add and remove orders), will return the users to the recipe window. The statistics window, which can be opened from the main window, will return to the main window on quit. From the storage window, which is the window implementing the stock-interaction presented in section 13.1, the add and remove storage windows can be reached. These windows will return to the storage window on quit, while the quit window will go back to the main window. Figure 13.3: Navigation chart for CAKE Page 73

78 Chapter 14 Summary A complete UML chart of the design can be found on the accompanying CD-ROM, showing how the classes relate to each other. In this document we ranked some criteria for the quality goals of our system, based on the OOA&D method. Later on, we decided on a technical platform, and chose a client-server architectural model. In chapter 11, we described the classes we will need for the implementation, followed by a description of our database and a description of the use-case using the storage window. The work resulted in a general idea on how the system should be made in the implementation. Since our experience with object oriented development was limited, we changed quite a few things from the analysis to the design. If we had these thoughts when we did the analysis document, we could have had more time to improve the design towards the implementation. 74

79 Part III Implementation Document 75

80 Chapter 15 Introduction In this document we will describe our implementation of the design, how the two are different and why. We will describe in detail how the most difficult parts are implemented, while just scraping the surface of the more trivial parts of the implementation. We will also discuss how we have used databases and how networking between the client and the server was handled. Discussions regarding persistence is described later, in the study report Design vs. implementation In this section we will discuss which parts of our design we have not implemented and which parts differ from the design. We will also discuss the reason for not implementing the whole design and what approach could be used to implement these What was left out? We have chosen not to implement the communication layer, and since it is not a crucial part of our system, we chose to rip it out due to time constraints. The part of the system that we designed will run fine without the communication layer, and although it would be a crucial part of a complete running system, it is not necessary for our testing purposes. In the same move, we removed the local persistence from the implementation What differs? When we started implementing the design we realized that our initial design was hard to implement. This was due to our limited experience with object oriented 76

81 CHAPTER 15. INTRODUCTION software design and Java network technology, and implementation of these. Therefore, there are major differences between the design and implementation of all the major parts of our system, all though the main idea and functionality is preserved. We will go into a more detailed description of what differs in each layer, starting with the GUI GUI We designed a very specific GUI, but it lacked functionality, this was mostly because we decided not to focus on the user interface early on. Instead we decided to implement classes for drawing the GUI just-in-time instead of making statical windows, thus making the GUI dynamic and extensible, which is more suitable for our purpose Function layer The Function layer has not been changed much from design to implementation, apart from the prediction class. We had to do some major redesigning for that, because we underestimated the complexity of the problem. We started of designing it to use a simple average but ended up using a more complex statistical approach; least-squares, which might be overkill, but seemed easy to understand and implement Model layer Virtually everything has changed, because the designed turned out to be impossible to implement. The basic functionality is preserved, except the the logger class which we thrashed for being ineffective and useless. Also the ModelHandler interface turned out to be impossible to implement using Java, because interfaces can not contain static methods. Another minor change is that we changed alot of string identifiers to enums, which is a Java 5 feature Persistence layer The design lacked functionality which has been added during the implementation. Another big difference from the design is that the persistence layer is more closely integrated with the model layer than indicated by the design by creating and storing objects from the model layer instead of strings. Page 77

82 CHAPTER 15. INTRODUCTION Communication layer Our self designed communication layer took a rather clumsy and non-java approach to networking, this was part of the reason why we chose not to implement it. Instead of all our message parsing and object serializing we could and should have used RMI 1, this would have made implementing the network bit much easier. You could also argue that we should have made all our GUI using HTML and a JSP Java applet combo, and then network using a combination of a webserver and a browser. This would have made our system much more accessible. 1 Remote Method Invocation Page 78

83 Chapter 16 GUI The graphical user interface of CAKE is implemented using the Swing framework. Because of Swing s multi-platform nature as well as the fact that it is conveniently packaged with Java. Each window has its own class (MainWindow, OrdersWindow, etc.), and each such class inherits from the Window superclass. Window superclass The Window superclass abstracts away from all the underlying work of drawing GUI windows and widgets in Swing. Its purpose is to make it very easy to quickly define new GUI windows inheriting from it. It contains methods to add buttons to windows, either one at a time using the addbutton method, or several using the addmultiplebuttons method. All button references are saved in a hash table named buttons, used for modifying button properties or associating methods the buttons should invoke. Both the addbutton and addmultiplebutton methods can either generate buttons just from button text, or optionally be passed a Dimension argument for setting the button size. The addbutton method accepts a simple string for the text to place on the button, whereas the addmultiplebuttons takes a two-dimensional array representing the grid of buttons the method is to create. Apart from logic to add buttons, the Window superclass can also add labels, tables or generic components to the window it builds, and contains a few basic window housekeeping methods (for hiding and showing windows, and similar operations). The layout used for the CAKE GUI windows is the Swing GridBagLayout, which was chosen because of its relative simplicity. For controlling the layout, the Window superclass has the attribute backlayoutconstraints. This attribute wraps a Grid- BagConstraints object, and is used to control component positioning, spacing and alignment. 79

84 CHAPTER 16. GUI ActionHandler class The CAKE ActionHandler class is an implementation of the Swing ActionListener. It keeps a hash table in which the keys are button references and the values are method references. When a button is pressed, it sends an Action event to the ActionHandler, which then executes the method associated with that particular button in the hash table. TableData class The TableData class encapsulates our data in a model for sorting and searching, and also disables some annoying default values in JTables (for instance, that cells are editable by default). The data for the table is contained in a linked list of generic object arrays, each such array representing a row within the table. The class wraps the fundamental linked list operations, including insertions, deletions and lookups. TableSorter class The TableSorter is a class written by Phillip Milne, Brendon McLean, Dan van Enckevort and Parwinder Sekhon. We use this class to allow our JTables to sort it s rows. The windows We have used the above classes to create our windows and add components and functionality to them. We have 5 windows, we will present each in the following sections. MainWindow The MainWindow (figure 16.1) is the users entry point to the application, it presents the user with the choice to either quit or access one of the applications other windows. Page 80 OrdersWindow The OrdersWindow (figure 16.2) gives the user all the options associated with orders, like adding new orders, deleting orders, edit orders, view order details and

85 CHAPTER 16. GUI Figure 16.1: The CAKE MainWindow search for an order. To do an operation on a specific item the user must select an order from the table to the left and press the button for the desired operation. RecipesWindow The RecipesWindow (figure 16.3) handles all actions related to recipes, like adding new recipes, deleting recipes, edit recipes, view recipe details and search for a recipe. Again to do an action on a specific recipe the user must select a recipe from the table to the left and press the button for the desired action. StoragesWindow The StoragesWindow (figure 16.4) handles our systems storages and the items stored in these. The user can manage the storages from the table to the left and the buttons next to it. Selecting a storage will bring up the items from that specific storage in the table to the right, selecting an item from this table will allow the user to manage items. PredictionWindow The PredictionWindow (figure 16.5) is the front-end for the semi-automated sales prediction system. Which allows the user to get predictions for the next weeks sales, based either on a weekly average or a daily average. The user just have to push one of the prediction buttons, and the systems prediction system fills the table bellow with it s predictions. Then the user just have to select the orders that he or she wants to add and press the Add Orders button. Page 81

86 CHAPTER 16. GUI Figure 16.2: The CAKE OrdersWindow Page 82

87 CHAPTER 16. GUI Figure 16.3: The CAKE RecipesWindow Page 83

88 CHAPTER 16. GUI Figure 16.4: The CAKE StoragesWindow Page 84

89 CHAPTER 16. GUI Figure 16.5: The CAKE PredictionWindow Page 85