Chapter 6  

Evaluation and Conclusions



Table of Contents



6.0 Introduction

At this point the intended system has been fully implemented.  The final task in this project is to evaluate the system.  The function of this evaluation is to determine the usefulness of the system to the intended users, identify faults and to suggest improvements.  The main focus of this evaluation is to answer the question “do the classes DatabaseConnect and Mapping simplify the process of designing and constructing object oriented database applications, for use locally and across a network such as a LAN (Local Area Network), Intranet and across the Internet ?”.  The different types of evaluation that might be used in this context are first outlined and an evaluation is then carried out to gauge the success of the system.


6.1 Evaluation

Evaluation is the process of collecting information about the state of a system in order to either improve features, or to assess a completed system.  Evaluation is important as it is the study of the relationship between design and use, i.e. what the system was intended to do, and how efficiently the system carries out the intended tasks. 


Evaluation is an integral part of system design and development and can be carried out at many different points during the lifecycle of a system.  As mentioned earlier the life cycle of an object oriented system is an iterative one, with various stages being repeated or redone to help improve the design and development process.  As a result evaluation is also an iterative process and any changes made to the system are a direct outcome of the recommendations made by evaluating some aspect of the system.

There are two main types of evaluation.

1.      Formative evaluation.

2.      Summative evaluation.


6.1.1 Formative Evaluation

Formative evaluation occurs before the final implementation of the system.  It was carried out for this project to suggest improvements that could be made to the design and during development it is carried out to solve programming errors.  During the design and development of the system, formative evaluation played an important role in ensuring a fully operational successful system.


During design, the appropriateness of the designed system and how it reflected the needs of the user, as outlined in the problem statement was evaluated.  This was done in an iterative fashion during all stages of design, to ensure that the final design would be useful when constructing a system to satisfy the needs of the end user.  The design carried out is satisfactory as it helped the process of implementing the system.


During development or coding of the system, formative evaluation was also ongoing.  The entire system had to reflect the design and it also had to work successfully.  Debugging errors in program code can be a tedious task, but when approached in a methodological fashion the problem areas can be easily identified and the problems solved.  Tracing the flow of control as the current system was executed solved most of the errors encountered.  This was done by placing appropriate messages in strategic points in the system and displaying them to the standard output stream.  Along with compilation error messages this method identified how far the flow of control moved before an error was encountered and if the required information was being passed to where it was needed.  These messages can be seen in the mapping class in Appendix B.  The messages display the necessary information and the line number from which the message was executed.


6.1.2 Summative Evaluation

Summative evaluation occurs after the implementation of the system, with the aim of testing the functionality of the final system (Preece, 1994).  According to Hannafin & Peck (1988);

            “Summative evaluation is, typically, conducted for signature purposes.”

This means that some final decision has been made regarding an application, such as whether it will be adapted or purchased.  This type of evaluation is generally not conducted to identify features for modification or revision.  Summative evaluation will be performed to determine the usefulness and success of this system.  


6.2 Methods of Evaluation

The different types of evaluation that takes place during the lifecycle of  a system have been outlined.  The different methods, which can be used to implement the different types of evaluation, are now examined.


6.2.1 Analytic Evaluation

Analytic evaluation is generally carried out before the system is developed, it normally starts early in the design cycle, when the system is documented using a  formal specification.  It allows designers to analyse and predict expert performance of error free tasks in terms of physical and cognitive operations that must be carried out.  It is chiefly used for evaluating user interfaces and is not appropriate for this system.


6.2.2 Expert Evaluation

In expert evaluation, people with considerable knowledge in the system domain simulate how an end user would use the system.  Drawing on their experience and using rules of thumb or heuristic evaluation (Nielson & Molich, 1990), they can quite often identify areas where problems are likely to occur.  The main difficulty with this form of evaluation is locating a suitable expert for the particular subject area.  Experts can be personally biased and this can influence their decisions.  Apart from this expert evaluation is a valid choice for evaluating the success of this system, it is an attractive form of evaluation as it requires few resources, is relatively cheap and can provide a source of potentially accurate feedback.


6.2.3 Observational Evaluation

Observational evaluation is used to assess the ease of use of a graphical user interface (GUI).  It is done by observing users as they interact with the interface, thus enabling the designer to identify weaknesses and advantages in the system.  This form of evaluation is not suitable for evaluating this system.  But it could be modified and used by observing and evaluating how a user designed and implemented their system using the classes DatabaseConnect and Mapping.  This would involve examining the system design and possibly their implementation after the work was completed.


6.2.4 Survey Evaluation

Survey evaluation involves the use of interviews and questionnaires.  The intended user first uses the system and then expresses their views and understanding of the system.  This method of evaluation enables a wide range of systems to be effectively evaluated, while interviews are carried out with a small number of the intended users, suitable questionnaire’s can be given to large numbers of users to provide quick and easy feedback.


6.3 Testing

Testing of a program can provide valuable feedback regarding the usability, strengths and weaknesses of the system.  Testing can be both formative and summative, and carried out at different stages during the lifecycle of the system.  This system was tested, by developing a number of applications that used the constructed classes.  The DatabaseConnect class was tested by the DatabaseConnectTest and GUI applications.  It was subsequently used to provide a mechanism for communications with a database by all of the other classes and applications which were developed.  The Mapping class was initially tested, by extending it to create a subclass called Car.  The function of the Car class is to hold information about a car.  The variables of the class included the make, model, price and the registration, which uniquely identified different cars.  Using the functionality provided by the Mapping class, see fig 6.1, the Car class allowed new instances of a car to be created and its attributes persistently stored in a database table called Car.  Once an instance of car is stored, the object can be reinitialised using a second constructor, which calls the second Mapping constructor.  A new instance of Car is created using the new keyword and by specifying the registration number of the stored car, for example;

Car mine = new Car(“95 DL 2772”);



When a car object is initialised with either constructor, its attributes can be accessed just like those of any other Java object, without the programmer needing to worry about how it is stored and retrieved to and from the database.  The Car class was then used by the application CarTest which created new instances of Car, stored them to the database, retrieved their attributes and performed operations on them. 


The testing of the Car class demonstrates the use of the Mapping class but did nothing significant.  To demonstrate the use of the Mapping class for developing applications, which made use of a persistent object’s attributes and methods, the Lotto class was developed.  The Lotto class contains six int attributes, a String attribute and four methods called getLine, checkNo, checkLine and checkWin, which allow calculations to be performed on the object’s attributes.  New Lotto objects are created using the first constructor, which accepts six int’s and a string as parameters, see fig 6.1.



The string parameter is the objects unique identifier.  Once a new instance of the lotto class has been created it can then be stored or used.  The second constructor enables stored Lotto objects to be reinitialised by specifying a unique persons name within the same system.  Once an object is reinitialised it can then be used like regular Java objects with the main difference that changes can be made to the attributes and persistently stored to a database for later use.  The LottoSetup application demonstrates the use of the Lotto and Mapping classes.  It is used once to create nineteen new instances of the Lotto class, create a database table called Lotto with the correct number and type of fields and specifies one field “Name” as the primary key, and store the objects.  The stored Lotto objects are reinitialised using the LottoRun application which uses the second constructor to recall the nineteen stored Lotto objects, see fig 6.1. 


Each of the Lotto objects are compared to seven numbers which are entered from the command prompt when the application is started.  If matches are made this information is stored and later displayed to inform the users if they have succeeded in winning the lotto, as illustrated in fig 6.2.



The functionality of the classes DatabaseConnect and Mapping was tested and demonstrated further by developing a Graphical User Interface (GUI) as illustrated in fig 6.3.  The source code of the application is in appendix i.



6.4 Results and Recommendations

The results from evaluating the system verified it’s correctness.  The system successfully satisfies the criteria specified in the problem statement.  The framework for object relational mapping further simplifies the task of writing object-oriented persistent, database applications and enables the programmer to develop their system without considering how the information contained within their objects is stored and retrieved.  Their only concern is the structure of a new class, it’s name and which attribute to use as the unique identifier.


However the system is still a prototype and there is room for improvement and enhancement.

·        The system concentrated on the necessary database tasks of connecting to, querying and retrieving results.  It did not provide support for stored procedures or other advanced features supported by JDBC, which may be required by real world applications.


·        The DatabaseConnect class only provides two constructors, the first is to connect to a default database and the second is to connect to a database of the users choice.  Both constructors utilise the JDBC:ODBC bridge driver.  This could be extended for other types of bridging.


·        The Mapping class is proprietary in that it is designed for use with Microsoft Access.  This results from the use of proprietary Access SQL syntax, when creating a new table and specifying the primary key.  However this demonstrates the viability of this approach, and it could be extended to allow storage in a range of databases.


·        When an application opens a connection with a database there is some overhead. The DatabaseConnect class allows instances to open a new connection to a specified database.  When the Mapping class was implemented each instance of the subclass of the Mapping class  in return inherited a DatabaseConnect variable. The DatabaseConnect variable was used by each instance to open a new connection and create new Statement and ResultSet objects.  This does not pose a problem when a few objects are used by a system, but if the system uses large numbers of objects and each creates a new instance of the DatabaseConnect class and opens a new connection, then this is not an efficient approach to communication.  When this problem was identified, performance was improved by implementing the DatabaseConnect variable as static within the Mapping class.  A static boolean variable was then used to determine if the DatabaseConnect variable was initialised.  Even though this approach partially solved the identified problem, more work needs to be carried out in the future.


·        The framework for object relational mapping only focuses on the mapping associated with a single object.  This is important as there are very few objects that have no interaction or relationship with other objects.  A possible solution could be facilitated in a relational database by linking related database tables together and performing appropriate joins.  It was stated in the design that this was beyond the scope of this project, but for the system to be truly useful in developing real world applications the issue will need to be addressed in the future.


6.5 Conclusion

This project set out firstly to simplify for the Java programmer the task of connecting to a database capability.  In addition it aimed to demonstrate the viability of object-relational mapping.  Both solutions were designed using the object-oriented methodology, OMT.  OMT was found to be useful for identifying the components and actions of both systems, but it was not particularly helpful when designing within class activities.  Instead a combination of JSP, OMT and UML schematics (Culwin, 1998) were used for the detailed design of the actions and found to be more appropriate.


As JDBC is a Java API which enables Java programs to interact with databases,  the design was implemented using the Java language.  Java was found to be an excellent programming language.  Java is a suitable programming language for general purpose computing, and is not only suitable for database applications, but for applications which could operate across a network such as the Internet or an Intranet.  As a result the system developed can be used either locally via a LAN or Intranet, or globally across the Internet. 


As outlined in chapter two it can be quite a difficult task to integrate heterogeneous databases, existing on various platforms and operating across different networks into a single application.  Java combined with Web technologies provides a potential solution to this problem, which has plagued developers in the past.  It is due to the open standards, which form the basis of the Web and the fact that Java is platform independent that such solutions, as exemplified by the application under construction, are now feasible.



Table of Contents