SKI SCHOOL MANAGEMENT TOOLpro.unibz.it/library/thesis/00001097.pdf · 2.3.1 – MySQL MySQL[2] is very fast, reliable, and easy to use. MySQL also has a very practical set of features

SKI SCHOOL MANAGEMENT TOOL

Faculty of Computer Science Bachelor of Science in Applied Computer Science

Free University of Bolzano

Stefan Pizzinini [email protected]

Academic Year 2003/2004 2nd Graduate Session - October 29, 2004

Supervisor Prof. Alessandro Artale

2

Contents 1 Introduction

1.1 Abstract…………………………………………………………………..4 1.2 Outline……………………………………………………………………5

2 State of the Art 2.1 Existing Applications…………………………………………………….6 2.2 GUI Interface…………………………………………………………….7 2.3 Database………………………………………………………………….7

2.3.1 MySQL………………………………………………………..7 2.3.2 GUI for Database Management………………………….........8

2.4 ODBC Technology………………………………………………………8 2.4.1 MySQL Connector/J……………………………………..........8

2.5 jakarta-tomcat-4.1.29…………………………………………………….9

3 User Analysis and Functional Requirements 3.1 Users of the System…………………………………………………….11 3.2 General Requirements…………………………………………………..12 3.3 Use Cases………………………………………………………….........13 3.4 Functional Requirements and User Stories……………………………..13

4 System Design 4.1 Database Modeling……………………………………………………..17 4.2 Relational Model………………………………………………………..18 4.3 Flow Diagram…………………………………………………………..20

5 Implementation 5.1 System Structure………………………………………………………..23

5.1.1 Standalone Client Application……………………………….23 5.1.2 Web Based Application……………………………………...24

5.2 Multi User Support……………………………………………………..25 5.3 Managing Updates in the Database…………………………………….26 5.4 A Running Example……………………………………………………26

6 Conclusions and Future Work 6.1 Self Assessment………………………………………………………...31 6.2 New……………………………………………………………………..31 6.3 Future Works…………………………………………………………...32

7 Bibliography

3

List of Tables

3.1 End Users of the system.......………………………………….............11 3.2 General requirements and their priorities…………………………….12 3.3 Functional requirements and their priorities…………………….........16 4.1 Relational Schema………………………………………………........20

6.1 Implemented features…………………………………………………32

List of Figures

3.1 Use case diagram……………………………………………………..13 4.1 ER diagram – Design of the Database………………………………..18 5.1 Standalone Architecture………………………………………………24 5.2 Web Based Architecture……………………………………………...25

List of Screenshots

5.1 Using the define period function.……………………………………..27 5.2 Insert instructors into database……………………………………….27 5.3 Instructor list with timetable………………………………………….28 5.4 Insert lesson cost……………………………………………………..28 5.5 Book lesson…………………………………………………………..29 5.6 Timetable with booked lesson………………………………………..29 5.7 Web based application access………………………………………..30 5.8 Displayed applet……………………………………………………...30

4

Chapter 1 Introduction A ski school provides services to clients like ski lessons, snowboard lessons, ski tours, group lessons. A ski school is made of one or more offices, secretary and ski instructors. A lot of clients visit the ski school office every day to book lessons or to get information about lessons. Thus everything should be well organized in order to provide a good service. 1.1 – Abstract The objective of my project is to design a system which can be used in a ski school office. Clients go to the ski school and want to book a lesson with a ski instructor. The problem is that a big number of people have to wait long time before they are able to book their lesson. This is because the booking procedure takes some time. Client data has to be written somewhere; the secretary has to look if there is some free ski instructor for the desired period. In other words everything has to be done more quickly, so a good solution for that situation could be to write software that helps the secretary to perform the booking procedure. The system should be as user friendly as possible. Usually secretaries are not expert users and so the application has to be very simple to use. It takes long time to collect all data from the client like name, surname, e-mail, phone number. An interesting solution could be to store all that data somewhere so when the same client books more lessons in the same ski school he is already stored as client and the user of the system has only to enter the data one time. Some ski schools have more than one office. The big problem in that case is that the same lesson with the same ski instructor can be sold to more clients, because there is no real time update between the offices. This problem can only be solved using an application. The system should provide more services like to store information about ski the ski instructors. Each instructor has to know his timetable for his working day. For now the only way is to go to the office or to phone there. Software could provide some good solutions. A mail service could be a good idea, or better a sms service. Maybe the sms service is better, because the instructor can look at the timetable during his working day. Sms is a good solution even because some lessons are sold during the working day and the instructor has no possibility to check his mail box. One of the main objectives of the project is to build a software solution that allows to book lessons not only in the ski school office and during office hours, but from everywhere and anywhere. So the goal is not only to design a normal application, but also a web application which allows connecting to the system from everywhere, not only in the ski school office. An important part is also security and reliability. Only

5

some people can access the system and perform changes on it. This means that the web based access to the system should be password protected. The system should also be reliable. This is the most important part because that kind of data stored can not get lost. Thus data has to be put in a secure place like in a database and needs to be periodically backed up.

1.2 – Outline Chapter one has given an introduction to the project, describing the situation and the

problems that have to be solved. Chapter two speaks about existing applications that are similar to that one that has

been developed. This chapter gives also information about used software to design and implement the application.

Chapter three analyzes the end users of the application. Analyzing the users it was

possible to list some general requirements and functional requirements that explain better the functionality of the system.

Chapter four describes the design of the system. It explains haw the database has been

modeled and how data flows from one process to one other. Chapter five explains the implementation and architecture of the system. The most

important functionalities of the system are explained through a running example. Chapter six gives an overview of what has been implemented and the problems

encountered. Some future changes and implementations are proposed.

6

Chapter 2 State of the Art

This chapter speaks about existing applications which are similar to the one I am developing for the ski school. The second part provides a list of software. This applications has been used to develop the system. 2.1 – Existing Applications The software market offers a lot of different. Each big or small company uses software to increase their production and to decrease production time. There are not so many applications on the market that are appropriate for a ski school, but there are a lot which are similar and have more or less the same functionalities and same structure. Let us consider the system of a tour company. It is more or less the same as a ski school. People go there and want not to book a lesson, but a voyage. The procedure is the more or less the same. The guests go to the office and want to book a voyage in a specific place. They have to choose some parameters like destination, departure place and date. The office has to collect also information about the guests, like name, surname, address. All the data has to be kept in a place. This place is, like the ski school system, a central database. Another system which uses this kind of architecture and has some similarities with the ski school system is a booking application for a hotel. The situation is always the same. People, go to the hotel and ask for a room. They have to give the secretaries some parameters like number of people, desired period, suite or normal room. The system uses the given data to retrieve a list of free rooms. The important part is again the database which holds all data which regards the guests and their booked rooms. These are only two examples where such a system is used. Other fields are for example train and flight companies. It is difficult to imagine how a big company could work without the help of software. We would say that it is almost impossible. Using software to perform calculations and a big number of check means decreasing waiting time for clients and it also means increasing productivity for the company.

7

2.2 – GUI Interface There are a lot of open source development environments on the net. Sun ONE Studio 4 CE[9] is a development environment for the java programming language provided by Sun. It is free and also very user friendly. Thanks its good graphical interface it is easy to have an overview of the packages and classes present in the project. It provides also interesting helps like the popup-window containing all the methods for the specified object. 2.3 – Database In the abstract I mentioned that the system has to be accessed from everywhere and anywhere. This means that data has to be somewhere on the internet where it can be accessed and downloaded by the different users. The best way to store data is to store it in a database. The main characteristic of a database is that it is hold in a consistent state, no data can get lost. It is also possible to give access only to specific users in order to deny the access to undesired users. On the market there are a big number of databases. Each provides more or less the same services so the problem is now to choose the most appropriate for my application. My studies took in consideration different database systems. PostgreSQL, MySQL and ORACLE where possible solutions for the problem. At the end I choose MySQL database. MySQL is a Relational Database Management System. A relational database adds speed and flexibility, by storing data in separate tables rather than putting all the data in one area. These tables are linked by defined relations making it possible to combine data from several tables upon request. Using a RDMS means it is possible to add, access, and process the data stored in your database. 'SQL' stands for "Structured Query Language" - the most common standardised language used to access databases. 2.3.1 – MySQL MySQL[2] is very fast, reliable, and easy to use. MySQL also has a very practical set of features developed in close cooperation with its users. It is also Open Source and therefore freely accessible. MySQL is used to access databases on the internet due to its connectivity, speed and security. It was originally developed to manage large databases at a much faster speed than the solutions that previously existed. MySQL has for several years, been thriving in the challenging areas of production. MySQL database with the MySQL Connector/J driver came out as a winner among the server databases reviewed from IBM, Microsoft, Oracle and Sybase, on a Java-based application server. In the results, MySQL is presented as having the overall best performance and scalability along with Oracle9i. Also, MySQL excelled in stability, ease of tuning and connectivity. Another reason of choosing a MySQL database is

8

because it is easy to find a server which provides MySQL database support. This is not the same for PostgreSQL. 2.3.2 – GUI for Database Management There are different GUI interface for MySQL database management. The one which was used to implement the database is Navicat[4]. It is an ideal solution for MySQL administration. This all-inclusive MySQL front end provides a powerful graphical interface for databases management, development and maintenance. Easy installation and intuitive interface make it irreplaceable tool for mysql on the web or your local desktop. Navicat allows you to modify data, Create or Run SQL queries, Manage user privileges, Backup/ Restore your database and migrate Database to Database. Latest version supports MySQL 4.1 and MySQL 5.0 (stored procedure), Foreign Key setting, Batch Job and Scheduling and Execute SQL Batch file. 2.4 – ODBC Technology A MySQL databases can be accessed using the following programming languages: C, C++, Eiffel, Smalltalk, Java, Perl, PHP, Python, Ruby, and Tcl. Each of them has to use a specific API in order to access the database. An ODBC interface called MyODBC also exists which allows additional programming languages that support the ODBC interface to communicate with a MySQL. Every language has its own methodology to access a database, like Java uses the MySQL Connector/J. C++ connects to an SQL database using the SQLAPI++[8] Library. This library uses native APIs of target DBMS so applications developed with SQLAPI++ library run swiftly and efficiently. The product also provides a low-level interface that allows developers to access database-specific features. By encapsulating a vendor's API, SQLAPI++ library acts as middleware and delivers database portability. DBD::mysql[5] is the Perl5 Database Interface driver for the MySQL database. In other words: DBD::mysql is an interface between the Perl programming language and the MySQL programming API that comes with the MySQL relational database management system. Most functions provided by this programming API are supported. 2.4.1 – MySQL Connector/J MySQL Connector/J[2] is a native Java driver that converts JDBC (Java Database Connectivity) calls into the network protocol used by the MySQL database. It lets developers working with the Java programming language easily build programs and applets that interact with MySQL and connect all corporate data, even in a

9

heterogeneous environment. MySQL Connector/J is a Type IV JDBC driver and has a complete JDBC feature set that supports the capabilities of MySQL. The following peace of java code shows how simple it is to connect to a mySQL database thanks to the MySQL Connector/J: import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; ... try { Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/test,user=monty, password=greatsqldb"); // Do something with the Connection .... } catch (SQLException ex) { // handle any errors System.out.println("SQLException: " + ex.getMessage()); System.out.println("SQLState: " + ex.getSQLState()); System.out.println("VendorError: " + ex.getErrorCode()); } The driver is now 50-100 percent faster in most situations than the previous version. It also creates fewer transient objects than before, leading to better performance and even more stability. The driver now also supports "streaming" result sets, which allows users to retrieve large numbers of rows without using a large memory buffer. With newly added large-packet protocol support, the driver can send rows up to 2 gigabytes in size. The driver was originally developed by Mark Matthews in 1998 as the Open Source "MM.MySQL" driver. It debuts as a MySQL product with significant performance and feature enhancements that will help maintain its position as the leading driver for Java connectivity to the MySQL database. Mark Matthews has joined the MySQL team and has brought with him an extremely valuable technology, so that it was possible to develop a MySQL API. Drivers have a huge impact on performance, and with MySQL Connector/J, Java developers have a solution that will take the built-for-speed MySQL database to new performance highs. 2.5 – jakarta-tomcat-4.1.29 Tomcat functions as a servlet container developed under the Jakarta Project at the Apache Software Foundation. A servlet container is a piece of software that has the work to control the servlets that are deployed with in the Web Server and forwards the requests and responses for them. Tomcat implements the servlet and the Java Server Pages (JSP) specifications from Sun Microsystems.

10

Tomcat[1] runs with any web server that supports servlets and JSPs. Tomcat comes with the Jasper Compiler that compiles JSPs into servlets. Tomcat can also function as an independent web server in itself: it operates as such in development environments with no requirements for speed and transaction handling. Since its developers write Tomcat in Java, it runs on any operating system that has a JVM. .

11

Chapter 3 User Analysis and Functional Requirements This chapter wants to give an overview of the functionalities of the system. The first part regards an estimation of the users of the system. Then a functional requirement analysis is performed. 3.1 – Users of the System The end users of the application are the ski school secretaries and ski instructors. A very important step in software development is to analyze the estimated users of the application. User needs and capabilities have been studied in order to implement the system in the best way. In order to get all the needed information personal interviews to the users where carried out. Through the information collected during an interview it is possible to get some general requirements of the system which will be listed in the following section of this chapter. Of course it is not simple to find the best solution to implement the application because of the big number of users and the different level of experience using working with a computer application. The administrator is also a user of the system. The administrator is extremely important; every system needs somebody who maintains it. Of course he will have some more functionalities and some more rights than normal users. The best solution would be to design the system in such a way that no administrator is needed. This is very difficult, thus the goal is to try to make the administrator job as less as possible. Table 3.1 shows the user categories of the system associated with the functionality they have.

End User Type Function Secretary Performs changes on system data Ski Instructor Views his personal data/timetable Administrator Maintains the system

Table 3.1: End Users of the system

12

3.2 – General Requirements This section shows the information retrieved from the interviews to the users. Information collected has been summarized in the following 3 points.

Simple user interface. All the users asked for a user friendly system. This is absolutely important for such an application. There are two reasons because the application should be simple and efficient. Many users and thus user categories has to use the system. This means also non expert users has to be able to get familiar with the system possibly in short time. The working situation implies the user to operate quickly. A simple user interface helps to reduce the time needed to perform the different tasks.

Reliable system. The system is the central part of the ski school office. Thus bad functionality or a crash of the system would cause consistent losses in time and in income. For that reason the application has to be first of all reliable, that means it has to work always. Every day a lot of new data is inserted into the system and retrieved from the system. A reliable system has to save data in the right way and right place. The same is when the user asks for some specific data he needs. The system has to send him exactly the data he needs. This has to be done possibly in a short period of time.

Multi user. A ski school office normally has more than one secretary. This means there should also be more than one client application installed. Thus a persistent connection and communication between different clients should be established. Each client has to know at real time which lesson has been sold by other users in order to avoid booking the same lesson twice. Not always the all the client applications are in the same office, sometimes there are more offices for the same ski school. Therefore a central database is the best solution for that problem.

System security. The system should allow the access only to authorized users. There is also a difference between users of the system as we can see in the section before. The system should allow the specific user type only to perform tasks that the specific user category is allowed to. For example it should avoid that a normal user has access to administrator tasks like to alter the database architecture. System security means also prevention against the so called “bad guys”. Bad guys are people who try to access a system and to perform undesired changes on it. Data has to be kept in a secure place where it is not possible to loose it and access is allowed only to some users.

Type Priority Multi user HIGH System security HIGH Reliable system MEDIUM Simple user interface LOW

Table 3.2: General requirements and their priorities

13

3.3 – Use Cases

Manage user access

Administrator

Super User(Secretary)

User(Ski instructor)

Look at the own timetable

Book lesson

Change DB structure

Delete user from user list

Give access to new user<include><include>

Insert timeslot cost

Define period

Delete ski instructor

List all instructors

Insert ski instructor

Look at timetable of each ski instructor

Send email to instructor

Manage ski instructors <include><include>

<include>

<include>

<include>

Login

Figure 3.1: Use case diagram

3.4 – Functional Requirements and User Stories Each user category has different tasks to perform. As mentioned in section 3.1 there are three end user types, therefore functional requirements will be specific for every user category. The difference to the general requirements is that functional requirements are

14

more precise. They contain the features of how the system should look like after implementation. Administrator: Change database structure. The administrator is the only person who has the permission to change database structure. He can connect to the database and perform different operations on it like add tables, delete tables, empty tables, alter tables, delete values from tables. The difference between administrator and normal user is that the administrator has more privileges on the database and thus has the necessary rights to change its structure. There are different tools to perform changes on the database. One example is “Navicat” which is mentioned in the section 2.2 Used software. Give access to new user. The simple user needs a permission to access the system. He has to have a valid username and password. When there is a new user who would like to access the application, the administrator has to add this new user to the user list and give him a valid username and password. Delete user from user list. When a specific user does not need the system anymore, the administrator has the right to delete this user from the user list. Secretary:

Insert instructor. From season to season there could be new instructors who work in the ski school. The system provides a function to insert new instructor into the ski school. By clicking on a specific button, a window is opened where the user has to insert different information. To perform this task, the secretary has to know all the data which is necessary to insert. Required information are name, surname, what he can teach (ski, snowboard, carving…), language skills, phone number, e-mail. The system provides some kind of support to the user. Some fields provide a check, like the e-mail field. This examines the string inserted in this field. If it is not an e-mail, a warning message is displayed to the user.

Delete ski instructor. From season to season there could be some ski instructors who leave the ski school. So the system provides a function which allows the user to dele instructors from the instructor list. By selecting the instructor or instructors which should be deleted and clicking the confirm button, data regarding that instructor is erased permanently from the database. It is not always possible to delete an instructor. If the selected instructor has still some booked lessons in his timetable, the system gives a warning message and the erasing action is immediately stopped.

List all instructors. The application gives the possibility to retrieve the instructor list and display it in a window by clicking on a button. The list displays not only the name and surname, but all information regarding the ski instructor. So the user can have an overview of all instructors. It is also possible to get for example the list of only the ski instructors, or of the snowboard instructors, or of the female instructors.

Look at timetable of each ski instructor. The main window of the application shows the timetable of each ski instructor. This is the most important part of the program, because the secretary has a good overview of all timetables. The timetables are displayed one under the other. The user can change this order by defining a new sequence.

15

Send e-mail to instructor. Each instructor should know the timetable of his working day. A good solution is a mail service. Each instructor gets every day an e-mail with the following working day timetable. This action is performed by clicking only one single button. The system goes through the instructor list, reads the instructor’s e-mail from there and sends the corresponding timetable. The possibility to send an e-mail to single instructors also exists.

Book lesson. The user has the possibility to book a lesson. The first step to do is to choose the right timetable of the instructor with whom the lesson has to be taken. The user has to mark the lesson or lesson he wants to book. Once all the desired lessons have been marked, by clicking a button a new window is opened. The user has to insert the required information to book the lesson, like name of the guest, surname of the guest, type of lesson (ski, snowboard, carving…), number of people who attend to the lesson, meeting point. By clicking the confirm button, the inserted data is send to the database. If the user tries to overwrite lessons that are booked, a warning message is displayed and the user has to decide whether to overwrite the lesson or to cancel the action.

Insert timeslot cost. In order to get the price of a lesson it is necessary that the secretary inserts the price of the lesson into the system. The price of a lesson can change from period to period, so not all timeslots has the same price. By clicking a button, a new window is opened where it is possible to define the prices for the specific timeslots. By clicking the confirm button the inserted data is sent to the database.

Define period. This task allows the secretary to define the period in which it is possible to book a lesson. A new window is opened where it is possible to define the first working day and the last working day. By clicking the confirm button, the inserted data is sent to the database.

Instructor: Login. The instructor has to insert his username and password in order to enter the system.

Look at his own timetable. The instructor can look at his timetable of the whole period. Table 3.3 shows the list of functional requirements of each user category. The functional requirements are divided in three categories; HIGH, MEDIUM and LOW. It is important to set priorities to the functional requirements in order to know which functionalities have firstly to be implemented.

Functional requirement Priority Super User Insert instructor HIGH Delete ski instructor HIGH Book lesson HIGH Insert timeslot cost HIGH Define period MEDIUM Look at timetable of instructor MEDIUM List all instructors LOW Send e-mail to instructor LOW

16

Administrator Change database structure MEDIUM Delete user from user list MEDIUM Give access to new user MEDIUM User Login LOW Look at own timetable LOW

Table 3.3: Functional requirements and their priorities

17

Chapter 4 System Design This chapter describes the architecture of the system. The first part regards database modeling where we can see the ER- diagram and how the relational schema is derived from the ER- diagram. 4.1 – Database Modeling The decision to use a database derived from the need to keep data in a secure and reliable place. This was one task which caused more problems because of its difficulty. The problem was not to implement the database, but to model it. The database model is one of the main parts of the system. A well modeled database improves efficiency and reliability of the system. Data has to be saved in such a structure that it is simple for the application to retrieve every kind of information it needs and possibly in short time. Problems encountered during database modeling could be data redundancy. A bad designed model has a lot of redundancy in its data. This means decrease in efficiency and increase in time to retrieve data. Figure 4.1 represents the model of the system database. The Entity-Relationship (ER)[6] model is a popular high level conceptual data model and is frequently used for the conceptual design of database applications. The ER diagram consists of seven entities: Maestro, Lezione_privata, Lezione_collettiva, Slot_collettivo, Cliente, Pagamento and Slot. The entities are represented by the rectangles. Entities are connected by relations, which are the squares on the figure. There are three ways in which entities can be connected. 1:1, 1:N, N:1 and M:N are possible relationships and are called cardinality ratios. The cardinality ratio specifies the maximum number of relationship instances that an entity can participate in. For example in the effettua relationship type Maestro : Lezione_privata is of cardinality ratio 1:N. This means that each maestro can be related to any number of Lezione_privata, but a Lezione_privata can be related to only one maestro. An example of M:N relationship is Partecipa. Each Cliente can be related to any number of Lezione_collettiva. The same is also the other way; each Lezione_collettiva can be related to any number of clients. In the above schema there is no example of 1:1 relationship type. Each entity has attributes which are properties that describe it. The Cliente entity has six attributes: ID, nome, cognome, alloggio, telefono, e-mail. The underlined attributes on the ER diagram is called key attribute. This is the identifier of the entity. In the example of Cliente, the identifier is ID. Some attributes are circled twice. Such attributes are called multivalued attributes. Figure 3.1 above has some multivalued attributes like lingua as attribute of the entity Maestro. There are some ski instructors who know only one language. In that case a single-valued attribute would be used.

18

Some instructors know more than one language, on that way a multivalued attribute is used.

Figure 4.1: ER diagram – Design of the Database 4.2 – Relational Model The relational model[6] is a relative simple model and is based on mathematical foundation. The model uses the concept of mathematical relation as its basic building block, and has its theoretical basis in set theory and first order predicate logic. The relational model is derived form the ER diagram represented in figure 4.1 using a specific algorithm. The procedure is divided in more steps[6]. Step 1: Mapping of Regular Entity Types. For each regular entity type E in the ER schema represented in figure 4.1, create a relation R that includes all the simple

19

attributes of E. Choose one of the key attributes of E as primary key for R. An example is the Cliente relation in the model below. The primary key is ID, all the other are attributes which describe the relation. If there are foreign key or relationship attributes, they are added during subsequent steps. Step 2: Mapping of Binary 1:N Relationship Types. For each binary 1:N relationship type R, identify the relation S that represents the participating entity type at the N-side of the relationship type. Include as foreign key in S the primary key of the relation T that represents the other entity type participating in R. This is done because each entity instance on the N-side is related to at most one entity instance on the 1-side of the relationship type. An example is the relationship between entity Maestro and entity Lezione_privata. In the relational schema below we can see that the primary key of the relation Maestro becomes foreign key in the relation Lezione_privata. Step 3: Mapping of Binary M:N Relationship Types. For each binary M:N relationship type R, create a new relation S to represent R. Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types. Their combination will form the primary key of S. An example is the relationship between Cliente and Lezione_collettiva. We map this M:N relationship type by creating the relation Partecipa. We include the primary keys of the Cliente and Lezione_privata relation as foreign keys in Partecipa. The primary key of the Partecipa relation is the combination of the foreign key attributes ID_lezionecollettiva and ID_cliente. Step 4: Mapping of Multivalued Attributes. For each multivalued attribute A, create a new relation R. This relation R will include an attribute corresponding to A, plus the primary key attribute K, as a foreign key in R, of the relation that represents the entity type or relationship type that has A as an attribute. The primary key of R is the combination of A and K. The relation Maestro has two multivalued attributes, lingua and specialitá. In the relational diagram below we can see the mapping of such attributes. Lingua is a relation with primary key lingua and foreign key ID_lezione_privata. Exactly the same is for Specialitá attribute. Table 4.1 shows the relational schema derived from the ER diagram in figure 4.1. The names written in bold are the relation names. The underlined attributes represent the primary key of the relation; the ones in italic are the foreign keys of the relation. Cliente (ID, nome, cognome, alloggio, telefono, e-mail)

Lezione_collettiva (ID, Idpagamento, lingua, specialitá)

Prezzo_collettivo (ID_collettivo, data_inizio, specialitá, data_fine, prezzo)

Maestro (nick, nome, cognome, telefono, e-mail, indirizzo, data_di_nascita,

cod_fiscale, tessera_fisi, pali)

Lezione_privata (ID, ID_cliente, ID_maestro, ID_pagamento, lingua,

specialitá, ptoRitrovo, pagato, prezzo, nrPersone)

durata(IDlezione, IDslot)

Slot (slotID, prezzoSci, supplementoSci, prezzoSnowboard,

supplementoSnowboard)

Pagamento (IDpagamento, importo, data, tipo)

20

Costo_collettivo (ID_lezione, slotID)

partecipa (ID_lezionecollettiva, ID_cliente, importo, data,

modalità_pagamento)

Lingua (lingua, simbolo)

Specialitá (specialitá, simbolo)

Insegna (nick, specialitá)

Conoscenza (nick, lingua)

Caratterizza (ID_lezione_collettiva, lingua)

Table 4.1: Relational Schema

4.3 – Flow diagram The data flow diagram shows how data is moved from the user into the system. We can see three different shapes on the diagram. The square represents the user. The user is also the font of data which flows into the system. In the graph there is a distinction between the three users of the system. The rounded rectangles represent the actions the system has to perform in order to move data from the user to the logical storage which is symbolized by the rectangles. The rounded rectangles have not only the task to send data forward to logical storage. In the most cases some checks or modifications has to be performed on the data. Let us take in consideration the book lesson action in the graph below. The user sends data to the first action which performs a type checking on inserted data. For example it checks weather data inserted in the e-mail field is or is not an e-mail. If there are some problems with the data, the system gives a warning message and wrong values have to be changed. If there are no problems, a second action is performed. This action looks if the lesson which has to be booked is already booked by another client or not. If the lesson is not booked, data is sent to the logical storage which represents the database. If the lesson is already booked, the system performs a third action. It asks the user weather to overwrite existing data or not.

21

To book a lesson, the user has to insert lesson data into the application. Before sending data to the database some checks are performed. The first one checks if data is correct. If there are some errors in the inserted data, the system gives an error and this action has to be done again. The second check looks if the lesson is already booked or not. It yes, a warning message is displayed and the user has to decide weather to overwrite data or not.

To send an e-mail to an instructor, the user has first to retrieve the instructor’s e-mail address from the database.

To insert an instructor into the database, again a check on the instructor data has to be performed. If data is ok, it is stored into the database, otherwise an error message is displayed.

Like the insert instructor function, an instructor can be deleted from the instructor list. A check is performed if the instructor data is protected or not, this means if the instructor has some booked lessons in his timetable he can not be deleted.

22

It is possible to get the list of all instructors with some options as shown in the graph.

The administrator can give access to new users of the web based application. A user needs a valid password to enter the system. The same is when the administrator wants to delete a user from the user list.

The simple user can entert he system if he has a valid password.

23

Chapter 5 Implementation The first part of this chapter describes how the system has been implemented and explains the structure of the program. In the following sections some system features and characteristics are described. 5.1 – System Structure The entire system is built in three parts. There is a client application, a database and a web based application. The system has to be used by different user categories; this is the reason because two kinds of applications have been implemented. Different user categories have also different expectations from the system. The only way to satisfy all user wishes was to implement two separate applications, a standalone and a web based. The following two sections will explain structure and functionality of both application types. 5.1.1 – Standalone Client Application In order to access the system, the application has to be installed on the computer where it has to be used. The first plan was to program also in this case a java applet and not an application. After some considerations, the final decision was to implement a standalone client application which connects to a database placed on a server as we can see in figure 5.1. The web based application was a good idea because of the free access place. This kind of implementation does not need first to install the client application on the computer. The application would be accessible from everywhere. The speed of the system to perform the tasks is very important. Therefore the best solution was to implement a standalone application. The application is entirely programmed in java. As mentioned in paragraph 2.3.1 the application connects to a MySQL database. The application has to exchange data with the database very often. Thus once the application is started, the connection is estabilished and when the application is stopped, the connection closes. On that way there is no loss of time to continuously open and close the connection. In the code of the program there is a class named DBConnection. This class contains code which allows connection to the database. This class contains also all methods which retrieve or send data to the database. The following piece of code shows how the application is able to connect to the database.

24

public DBConnection(CostFrame costFrame, DataForm dataForm) { ………….. ………….. ………….. try{ Class.forName("org.gjt.mm.mysql.Driver");

conn=DriverManager.getConnection ("jdbc:mysql://"+getIP()+"/username","password");

stmt = conn.createStatement(); }catch(Exception e){ ……… } }

Standalone Client Application

Send data to DB

Retrive data from DB

Application Server

Figure 5.1: Standalone Architecture

5.1.2 – Web Based Application For the normal users of the system, there was a need to implement an application which was accessible from everywhere and at every time. The difference between web based application and standalone application are two. One is the possibility to access the system via web, without the need to install any applications on the computer. The second is that the application is personalized for every different user. Each user has a different username and password to access the system. On that way, each user can only access to the own data. This kind of user is not allowed to perform changes on data present into the database. The only permission he has is to retrieve the proper data in order to take a look at his timetable. This part of the system is a combination of java and JSP. JSP files are pages which contains HTML code and java code together. For the user login to the system a JSP page is used. This file has to send username and password to the database as displayed in figure 5.2. If the data is correct, the JSP page loads the java applet from the server to the client. A java applet is like a java application; the difference is that an applet can run on a web page.

25

Web Based Application

Web Interface

Access response

Access to user

System access request

Retrive data from DB

Figure 5.2: Web Based Architecture 5.2 – Multi User Support Allowing multi users to work on the system in the same time has been one of the crucial problems to solve. In a ski school there can be more client applications installed in the same room, but also in different rooms. So what could be the problem if more than one user works on the system? If one user books a lesson for a specific client with a specific instructor, all the data regarding that lesson is sent to the database. The problem is that the other applications which are connected to the system do not get automatically informed if there has been done some changes on the database. One possible solution could be to do periodically a refresh of the whole application. This would retrieve the new inserted data into the application. This could be a solution, but not a good one. The time needed to refresh the whole application would be quite long, because all data has to be reloaded. To be up to date with the other clients, the refresh has to be done every five or ten seconds. The reload of the application lasts some seconds and therefore this solution would not be appropriate for that problem. The implemented solution is quite complicated but works very well. Every time a client connects to the system, it creates a table in the database. For simplicity, the name of the table is the IP address of the client. So for example if the client’s IP address is 192.168.2.3, the application creates on runtime a table with name 192.168.2.3. All the

26

connected IP addresses are also inserted in a database table called Update_All, which has only one field, the IP_address field. The table of each connected client stores all the modifications made by other clients using two fields: one contains the IP address of the client which performed the change and the other contains the ID of the booked lesson. So when a client application performs some change by booking a particular lesson, the system performs the following steps. First step: retrieve all connected clients present in the Update_All table. Second step: insert in every client table the own IP address and the ID of the new booked lesson. On each client a thread runs and checks every five seconds if there are new entries in its database table. The thread reads the lesson IDs’ that have been inserted into the database. The client can now perform a query on the database and ask for the data which has been inserted to book the lesson. That means information about slots booked, data of the person who has booked the lesson, instructor of the lesson. Once the client has received the requested data it can populate the timetable of the application with such new data. 5.3 – Managing Updates in the Database The data present in the database is very important and therefore every little unwanted change could cause big problems to the ski school. However sometimes data has to be changed or overwritten. Therefore before storing data into the database, some check and, if needed, some warning messages have to be given. If a lesson has to be booked, before inserting the data into the database, the system checks if the lesson is free. The cases are two, the lesson is not booked and in that particular case there is no problem. The problem is when the lesson or a part of the lesson is already booked. The system has to perform a query on the booked lesson and check if the lesson that has to be booked is in the set of booked lessons. If the lesson is already booked, the application gives a warning message. The user can decide weather to abort the action or to proceed and thereby overwrite the old data. 5.4 – A Running Example When the system is started for the first time, there is no time period defined. So the user has to look on the menu and click on the define period button. A window appears where it is possible to insert the period of the working season which is visible in screenshot 5.1.

27

Screenshot 5.1: Using the define period function

The application does not display anything until there is no instructor present in the database. Next step is to insert data of all ski school instructors into the database using the “inserire maestro” function in the menu.

Screenshot 5.2: Insert instructors into database

28

Screenshot 5.3: Instructor list with timetable

After this function has been performed, the application displays the instructor list and the corresponding timetable. Before beginning to use the system, one more thing has to be done. On the menu list, there is a function which allows to insert the lesson prices. This has to be done before beginning to book lessons.

Screenshot 5.4: Insert lesson cost

The system is now ready to be used. When the user of the system wants to book a lesson he has to select the slots he wants to book. By clicking the right mouse button a

29

popup menu is opened. To book the selected lesson (or lessons), the user has to click on the book lesson button. A window is opened where the user has to insert client data.

Screenshot 5.5: Book lesson

Screenshot 5.6 shows the booked lesson in the timetable of Manfred.

Screenshot 5.6: Timetable with booked lesson The web application is accessible through the web interface displayed in screenshot 5.7. The user has to type his username and his password in the apposite fields.

30

Screenshot 5.7: Web based application access

The system performs a check on the inserted data. If username and password are correct, a java applet which shows the timetable of the instructor is started.

Screenshot 5.8: Displayed applet

31

Chapter 6 Conclusions and Future Work This chapter speaks about final conclusions. The first part gives an overview of what has been implemented and what has not been implemented. At the end some future improvements and changes are proposed. 6.1 – Self Assessment The implementation of the system was quite successful. Most functions have been implemented in an efficient way. There is some functionality that has not been implemented for different reasons. The idea was that to implement a sms service for to contact and send information to the instructors. This functionality was of low priority and had to be implemented at the end and it has not been implemented because of two problems. There where a lot of functionalities with higher priority to implement and so the time was not enough. The other problem is the cost of the service. A ski school would send a lot of sms every day because of the big number of instructors and would spend a big amount of money for this service. Another service which has not been implemented is the e-mail service. This is of fundamental importance because it is possible to send the timetable of each instructor. The reason because it has not been implemented is the implementation of the web based service. This allows to each instructor to look at his own timetable of the whole season. Table 6.1 shows which functional requirements have been implemented.

Functional requirement Priority Implemented Super User Insert instructor HIGH YES Delete ski instructor HIGH YES Book lesson HIGH YES Insert timeslot cost HIGH YES Define period MEDIUM YES Look at timetable of instructor MEDIUM YES List all instructors LOW YES Send e-mail to instructor LOW NO Administrator Change database structure MEDIUM YES Delete user from user list MEDIUM NO Give access to new user MEDIUM YES

32

User Login LOW YES Look at own timetable LOW YES

Table 6.1: Implemented features

6.2 – What I Have Learned Developing this project was very useful for my personal knowledge. There was the possibility to learn new things but also to get more familiar with known tools and programming languages. I used java in other projects, at the university, for personal projects. This gave me the possibility to get in contact with objects and methods which I did not know before. Developing the web based application I learned a lot of new things about JSP. The implementation of the database was for me something new. During the three years of university I learned how to model a database, but newer tried to implement one. This project gave me the possibility to get more familiar with databases and also with the SQL language. 6.3 – Future Works The system works but is for sure not definitive. In the future some changes will be performed and some new functionality will be implemented. The first thing which will be implemented is the sms service. This could be very useful to send information to the instructors and to send them their timetable. This is interesting for the instructors who have no internet access and can not use the web application or if there are changes in the timetable during the working day. It would be interesting to give the possibility to the clients of the ski school to access the system and to look at the timetable of each instructor in order to have an overview of the free lessons.

33

Bibliography [1] Apache Jakarta Tomcat-servlet container. http://jakarta.apache.org/tomcat/ [2] MySQL database driver download and usage explanation. http://dev.mysql.com [3] MySQL Documentation. http://dev.mysql.com/doc/plusplus/en/index.html [4] Navicat-tool for database management. http://www.navicat.com [5] Perl5 Database Interface driver for the MySQL database explanation.

http://search.cpan.org/~rudy/DBD-mysql 2.9004/lib/DBD/mysql.pm [6] Ramez Elmasri, Shamkant B. Navathe. Fundamentals of DATABASE

SYSTEMS - FOURTH EDITION. [7] Ramez A. Elmasri, Shamkant B. Navathe. Sistemi di base di dati

FONDAMENTI – Prima edizione italiana.[7] [8] SQL API to access databases for C++. http://www.sqlapi.com [9] Sun Developer Network Site. http://java.sun.com