PredictionHandler

The PredictionHandler class uses the other four classes and the model layer to pro- duce sales statistics for a given time period, and a prediction of future sales using the least squares method.

Persistence

The persistence-layer of CAKE is with with an interface and the reference im- plementation of the PersistenceInterface is made using JDBC to a PostgreSQL database. The interface allows use to use implementation hiding, which allows us to exchange the PersistenceHandler class with another for a different data-storage method, without changing anything else. The only class of significances in the per- sistence layer is PersistenceHandler.

PersistenceInterface

This is a Java interface with 7 methods, where 4 are different overloads of the same method. These methods are close(), storeObjData(Object), deleteObject(Object), getObjData(type) getObjData(type, objectid) getObjData(type,state) and getObj- Data(relationtype, relationid).

The close() method performs any needed shutdown and cleaning operations and is called when a server connection in a not implemented communication-layer is closed.

The storeObjData(Object) method stores obejcts it recognises which means they

are from the model-layer as well as the linked objects.

The deleteObject(Object) will try to delete the object given in the argument and

the return value will show the success or failure.

The getObjData method is overloaded, all, but the relationid overload, take a type

ThegetObjData(type, objectid) this overload finds the specific with the given type and objectid. This overload will in addition to returning null if it doesn’t find an object also return null if it finds more than one object.

The getObjData(type,state) will return an array of the objects found of the given

type and state, if the type and state doesn’t match it will throw an IllegalArgu- mentException.

The getObjData(relationtype, relationid) method returns an array of objects that

is in the relation between the two classes given in the relationtype. The relationid represents the objectid of the object the requested objects have a relation with.

PersistenceHandler

This class is the only class with methods in the persistence part of our implementa- tion and therefore handles everything from saving the information from the objects to make them and retrieve the information from the database again. PersistenceHan- dler implements PersistenceInterface and it is accesses through the methods defined in the PersistenceInterface, the rest of the implementation is hidden using the pri- vate access specifier.

The constructor of the class takes four string arguments with information on creat- ing the connection to the PostgreSQL database: the hostname of the database server, the name of the database, the username, and the password to login with. The con- structor also calls the private method createConnection() which attempts to create the connection to the database server, should the attempt fail, it will first attempt create database and should that fail, exit the program.

Theclose() method close the JDBC connection to the database server.

The storeObjData(Object) method identifies the type of the object using RTTI1,

creates the appropriate insert or update sql statement, executes it and based on the success either commits the changes or rolls back.

ThedeleteObject(Object)method again uses RTTI to identify the type of the object,

executes a SQL statement, commits the change and returns true, if a single row is 1_{Run-Time Type Identification, Java method to identify the type of an obituary object while the} program is running.

Based on which overloaded method is called and which arguments are given to the

getObjData() method, a SQL statement is created and executed. Then we iterate

through of the result of the SQL query, and for each iteration call a private object factory method in the persistence layer. Finally the created objects are returned or null, if no object are created.

Summary

The entire source code of the implementation and the related Javadoc documenta- tion can be found on the accompanying CD-ROM.

In this document, we described the actual implementation of the CAKE system. The implementation differs, as explained in the introduction, from the design in a few ways. This is primarily because we found some basic ideas in the design that could be improved.

Introduction

In this document we will discuss, how we have tested our system and the results produced by those tests. There are two different kinds of testing: black-box testing and white-box testing. White-box tests are done in such a way that you can see everything in between the input and output generated by the test. Black-box tests is similar to a white-box test, apart from the fact that only the input and output is known. The tests we have carried out using JUnit (explained in chapter 23) are black-box tests.

21.1

Black-box tests

The tests we have run is with JUnit, which gives us a black-box test. We chose to only thoroughly test a part of our implementation, specifically the persistence layer which has been the focus of the project. First we tested our code to compare two objects from the model-layer, as this code is needed in the process of testing correctness of the persistence layer.

Our strategy for testing the persistence code has been to test each of the publicly accessible methods in the layer with a variety of input values and check whether they return the expected output.

For each of the classes in the model-layer a bunch of objects were created to be used in the unit tests and a test case for the comparison method written. The object were given different values, such as values we would expect to cause problems and values you would see in regular usage. Then test cases for each of the layer’s public methods were written using the previously created model-layer objects. A complete printout of our test results can be found in the appendix.

This method is one of the JUnit test cases written to test the persistence code, this test case tests whether the PersistenceHandler stores, retrieves and deletes well- formed Storage objects correctly.

1 p u b l i c v o i d t e s t S t o r a g e P e r s i s t e n c e ( ) { 2 P e r s i s t e n c e H a n d l e r ph = new 3 P e r s i s t e n c e H a n d l e r ( " l o c a l h o s t " , " c a k e j u n i t " , " c a k e " , " e 3 1 1 1 " ) ; 4 s . s t o r e ( ph ) ; 5 a s s e r t T r u e ( s . g e t I d ( ) >= 0 ) ; 6 s I d = s . g e t I d ( ) ; 7 s t . s t o r e ( ph ) ; 8 a s s e r t T r u e ( s t . g e t I d ( ) >= 0 ) ; 9 s t I d = s t . g e t I d ( ) ; 10 11 S t o r a g e s t o , s t o r ; 12 s t o = ( S t o r a g e ) ph . g e t O b j D a t a ( ModelType . S t o r a g e , s . g e t I d ( ) ) ; 13 s t o r = ( S t o r a g e ) ph . g e t O b j D a t a ( ModelType . S t o r a g e , s t . g e t I d ( ) ) ; 14 a s s e r t T r u e ( s t o . e q u a l s ( s ) ) ; 15 a s s e r t T r u e ( s t o r . e q u a l s ( s t ) ) ; 16 17 a s s e r t T r u e ( ph . d e l e t e O b j e c t ( s ) ) ; 18 a s s e r t T r u e ( ph . g e t O b j D a t a ( ModelType . S t o r a g e , s I d ) == n u l l ) ; 19 a s s e r t T r u e ( ph . d e l e t e O b j e c t ( s t ) ) ; 20 a s s e r t T r u e ( ph . g e t O b j D a t a ( ModelType . S t o r a g e , s t I d ) == n u l l ) ; 21 }

Line 2 creates a new PersistenceHandler instance. After line 4 and 7 stores two pre-created Storage objects, the tests in line 5 and 8 tests whether the default id of -1 for model objects not committed to the database yet has been changed in the process of inserting the two Storage objects in the database. In line 12 and 13 the two stored Storage objects are retrieved into the variables sto and stor. Sto and stor are then compared with the two original objects s and st in line 14 and 15 to ensure the persistence layer has stored and retrieved the Storage objects without any issues. Finally the objects s and st are removed from the database again in lines 17 and 19. The success of the deletion is checked by testing the return values of deleteObject() and by attempting to retrieve Storage objects with the deleted objects’ id numbers.

Introduction

In this last part of the report we will describe, among other things, technologies used to implement our system and the focus area of the project, persistence. Finally we will go through the entire project from the start to the end, while pointing out our findings and decisions where it is felt needed.

Technologies Used

In this chapter, we will present the technologies used to implement our system, along with the reasons for using them. We will describe the technologies separately, in detail, and, if needed, comment on our findings regarding that technology.