13.3 Navigation chart
15.1.2 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
fore, 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.
15.1.3
GUI
We designed a very specific GUI, but it lacked functionality, this was mostly be- cause 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.
15.1.4
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, be- cause 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 imple- ment.
15.1.5
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.
15.1.6
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
15.1.7
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 RMI1, 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.
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 gen- erate 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 ar- ray 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
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 Ac- tionHandler, 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 win- dows.
OrdersWindow
The OrdersWindow (figure 16.2) gives the user all the options associated with or- ders, like adding new orders, deleting orders, edit orders, view order details and
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.
Model
In this chapter, we will describe model-layer of the CAKE system. This layer in- cludes the classes for ingredients, items, orders, recipes and storages.
Ingredient
The Ingredient class is a Java class that represents the ingredients in the system. The class has 12 methods, including the constructor.
These methods are Ingredient(name, unit), equals(object), getId(), setId(id), get- Name(), setName(name), getUnit(), setUnit(unit), store(PersistenceInterface), getO- bjects(PersistenceInterface), getObjects(PersistenceInterface, id),
delete(PersistenceInterface).
TheIngredient(name, unit) method is the constructor.
The equals(object) method will compare the object given with “this” object. The
equality is tested on objecttype, id, name and unit. If all of these are equal, the objects are equal.
ThegetId() andsetId(id) methods can return the id of the object, and set it, if it is
not already set.
getName() andsetName(name) are the methods that either get or set the name of
the ingredient.
ThegetUnit() andsetUnit(unit) methods will return the unit for the item or set the
unit to the given one.
store(PersistenceInterface) is the method for storing the object using the persisten-
ceinterface.
ThegetObjects(PersistenceInterface) method will return every ingredient object in
the system.
delete(PersistenceInterface) will delete “this” object from the system.
IngredientEntry
The IngredientEntry class contains the amount of an ingredient needed in a recipe. This class has equals(object), getAmount(), setAmount(amount), getIngredient(), toString() and IngredientEntry(ingredient, amount) methods. The getAmount() and setAmount(amount) methods are used to get or set the amount of the given ingredi- ent is needed.
getIngredient() returns the ingredient of the given entry.
TheIngredientEntry(ingredient, amount) is constructor of the class.
Item
The Item class represents the items in storage. This class has the constructor Item(ingredient, storage, price, expirationdate, statelastchanged, state) and the methods getUnit(),
equals(object), getAmount(), setAmount(amount), getExpirationDate(), setExpira- tionDate(date), getId(), setId(id), getItemState(), setItemState(state), getStorage(), setStorage(storage), getPurchasePrice(), getStateLastChanged(), getType(),
store(PersistenceInterface), getObjects(PersistenceInterface), getObject(PersistenceInterface, id),
getItems(PersistenceInterface, storage), getItems(PersistenceInterface, order), getItems(PersistenceInterface, Ingredient), getObjects(PersistenceInterface, state), getOrder(), setOrder(order), get-
Name(), setName(name), delete(PersistenceInterface).
ThegetUnit() method returns the unit of the item, from the Ingredient property.
getAmount() andsetAmount(amount)are used to get or set the amount of the given
item in the storage.
getExpirationDate() andsetExpirationDate(date) are used to get or change the ex-
piration date for the item.
getId() andsetId(id) are used to get the unique id for the item, or set the id, if it is
not already set.
ThegetItemState() andsetItemState(state) methods are used to get and manipulate
item.
getPurchasePrice() is the method used for returning the purchase price of the item.
ThegetStateLastChanged() method returns the date of the last change of state.
ThegetType() method will return the type of item it is executed on.
store(PersistenceInterface) saves the item using the given persistence interface.
getObjects(PersistenceInterface), getObjects(PersistenceInterface, id) and getOb-
jects(PersistenceInterface, state) will return the the objects of the same type from
the persistence interface, if a state is given, only the items in that state will be re- turned.
getItems(PersistenceInterface, storage), getItems(PersistenceInterface, order) and
getItems(PersistenceInterface, ingredient) will return the items in a given storage,
associated with a given order or of a given type Ingredient, depending on the second parameter.
getOrder() andsetOrder(order) returns or sets the order.
ThegetName() andsetName(name) methods are used to get or set the name of the
object.
The delete(PersistenceInterface) method will delete the item from the persistence
layer.
ItemState
This class only contains data for the state of the items. Since JUnit 3.8.1 does not work with Java 5, the data is stored in a class.
ModelType
As with the ItemState class, this is only a data storage class.
Order
This class takes care of the orders.
The Order class has these methods: equals(object), Order(name, customer, deliv- erydate, type, state, statechanged), getId(), setId(id), getName(), setName(name), getCustomer(), setCustomer(customer), getState(), setState(state), getType(), get- DeliveryDate(), setDeliverDate(deliverydate), addRecipe(recipe, amount),
state), getObject(PersistenceInterface, id) and delete(PersistenceInterface).
The constructor,Order(name, customer, deliverydate, type, state, statechanged)cre- ates the Order object with the needed information.
ThegetId() andsetId(id) methods gets and sets the id of the order.
The getName and setName(name) methods are used to set the name of the order,
and retrieve it when needed.
getCustomer() andsetCustomer(customer) are used, like the name and id methods
to manipulate the customer of the order.
ThegetState()andsetState(state)methods are used to change the state of the order.
ThegetDeliveryDate() andsetDeliveryDate(deliverydate) methods are used to ma-
nipulate the deliverydate of the order.
The addRecipe(recipe, amount) andremoveRecipe(orderentry) methods are used
to add and remove recipes from the order.
getStateLastChanged() return the date of the latest change of state on the order.
The store(PersistenceInterface) method stores the object in the given persistence
interface.
getObjects(PersistenceInterface),getObjects(PersistensInterface, state),
getObject(PersistenceInterface, id) return the objects that matches the search crite-
ria - all objects, every object in a specific state, and the object with the given id.
delete(PersistenceInterface) deletes the object from the given persistence.
OrderEntry
The OrderEntry class takes care of the Order date, based on recipes and amount. It has four methods, getRecipe(), getAmount(), setAmount(amount), OrderEntry(recipe, amount). These methods are used to get information about the order made with the constructor. It is possible to change amount by using setAmount(amount).
OrderState
The class OrderState holds information about the state the order can be in, being Placed, UnderPreparation, Delivered and Cancelled. This class has no methods.
OrderType
The OrderType class contains information on which type the current order is, Ex- pected or Placed.
Recipe
The Recipe class holds the recipes. It has the following methods: equals(object), addIngredient(Ingredient, amount), removeIngredient(ingrediententry), getIngredi- ents(), getIngredient(id), Recipe(name, comment), toString(), getComment(), set- Comment(comment).
The addIngredient(Ingredient, amount) method is used for adding a new ingredi-
ent to the recipe, as well as theremoveIngredient(ingrediententry) can remove this ingredient.
The constructorRecipe(name, comment) will prepare a new Recipe object.
toString() will return a string with a full list of ingredients.
ThegetComment() andsetComment(comment) will set or get the comment for the
recipe. The same idea goes for the getId(), setId(id), getName(), setName(name),
getSalesPrice() andsetSalesPrice(salesprice) methods.
Thestore(PersistenceInterface) andgetObject(PersistenceInterface, id) will get the
recipe object(s) from the persistence, if id is given, the specific recipe is returned.
delete(PersistenceInterface) will delete the recipe from the given persistenceinter-
face.
Storage
The Storage class represents our storages. Storage(name, location), equals(object), getId(), setId(id), getLocation(), setLocation(location), getName(), setName(name),
store(PersistenceInterface), getObjects(PersistenceInterface), getObject(PersistenceInterface, id), delete(PersistenceInterface).
The constructor method, Storage(name, location), creates a new storage with the given location.
The rest of the methods work in a similar way as the get/set and store methods pre- sented in this chapter.
Function
18.1
Function layer
The function layer provides data manipulation and access methods for the cafe- teria manager GUI. It consists of five classes, StockHandler, IngedientHandler, RecipeHandler, OrderHandler, and PredictionHandler.
18.1.1
StockHandler
The StockHandler class deals with both Storage and Item objects. It has four over- loaded methods list, add, remove and change. The list returns an array of existing Storage objects or, if supplied with a Storage object argument, an array with the Item objects in a particular Storage object. The add methods simply create a new Storage or Item object, tell the persistence layer to store it and return the created object. The remove methods tell the persistence layer to delete the supplied Item or Storage object. Finally the change method tells the persistence layer to update the information stored on the passed Item or Storage object in the persistence layer.