A library circulation system for city and special libraries

Abstract

Purpose - The aim of this research is to model and implement a software system for library circulation, so that all requirements of city and special libraries for electronic business with the library users can be fulfilled. Design/methodology/approach - Object-oriented methodology is used for modelling of information systems. Modelling is carried out in the CASE tool that supports the Unified Modelling Language (UML 2.0). The software architecture of the system is based on the software components and web services. Findings - The result is a software system for library circulation. The application of the system supports the work with the local database (intranet), as well as with the remote database (internet). Also the application supports the work with different library formats (UNIMARC, MARC21 et al.). Research limitations/implications - The system is integrated into the BISIS system so that communication with the system for cataloguing is carried out via the text server of the BISIS system. For this reason integration into the other library software systems requires an additional programming. This limitation can be solved through implementation of the software package for communication with the system for cataloguing. In this case, the integration into another library system should require only the implementation of the method of the corresponding interface for work with bibliographic records. Originality/value - The contribution of the paper is in the system architecture that can be configured for work in the local intranet, as well as on the internet, and that is independent of the library record format. Also, the architecture enables integration of the application in different library systems.

1. Introduction

The results represented in this paper were obtained within the development of the BISIS library software system, especially of its part related to the library circulation system. The BISIS system has been developing since 1993 at the University of Novi Sad and a review of the system development is given in the paper ([13] Konjovic and Surla, 2004). The actual version of the system is 3.1. After the introduction of this version into city and special libraries some shortcomings were noticed in the existing implementation of the application for the library circulation system relating to the requirements that these libraries have in their library work. Based on the analysis of the requirements and needs of the libraries using the BISIS system, a library circulation system able to satisfy the needs of electronic management with the users of the city and special libraries was developed and is described in this paper.

The development of the fourth version of the BISIS system based on XML technology is underway. Within the version, an XML editor for cataloguing in the UNIMARC and MARC21 formats ([9] Dimic and Surla, 2009), as well as a web oriented editor for processing bibliographic material in the UNIMARC format ([3] Belic and Surla, 2008) are developed. Also, an XML editor for searching and downloading bibliographic records in accordance with Z39.50 standard ([5] Boberic and Surla, 2009) is developed. Modelling and implementation of library circulation system is presented in this paper as a component part of the research.

There are many library information systems that have also the library circulation system as a component. Within the Library of Congress site for the MARC standards[1] there is a special section containing a list of library software packages[2] . Some packages support also circulation control in addition to other functions of the library information systems. The majority of the software products are commercial and it not publicly accessible for downloading. What is possible is to download the accessible instructions for the users and, based on their contents, to analyse the software functionalities. Some of these software are ALEPH 500[3] , Voyager[4] , Atriuum[5] , Concourse[6] , CyberTools for Libraries[7] , EOS.Web[8] , etc. There are also free software products such as the Evergreen Integrated Library System[9] and Koha[10] , the functionalities of which are possible to analyse completely by downloading their installation packages.

The systems enable standard activities related to the work with the users such as charging and discharging procedures, membership fee renewal, printing lending form and receipt, searching users and publications as well as generating statistical reports. Some of them include the support for UNICODE, bar code and RFID technology, printing and sending reminders to users for exceeding the loan period and publication reservation. Client applications of the systems are implemented either as Windows applications only supported by the Windows operating systems or as web applications. The library circulation is a component part of all the systems and there is not any possibility for its separation as an independent software component that could cooperate with some other library systems.

Besides those software systems, the concepts of library circulation have been observed in many papers. The paper ([2] Babafemi, 2002) describes the role of circulation librarians as the intermediary between users and library. The major contribution of that collaboration is in providing feedback from the users, which can be used for further collection development based on user needs. Also, circulation statistical reports have a significant impact on collection development as it is described in the papers ([1] Adams and Noel, 2008) and ([7] Cheng et al. , 2002). Experiences presented in papers ([6] Boone, 2002) and ([11] Joint, 2008) indicate that different services provided by libraries bring to efficient usage of both printed and digital library collection. Some of those services are described by [10] Falk (2005). [4] Bennett (2007) describes findings according to which OPAC enhancements result in significant increase in circulation. Also, efficiency of circulation is increased by using RFID technology in libraries according to [12] Kern (2004).

In accordance with all the aspects of circulation systems mentioned above, in this paper is presented the proposal of a library circulation system. The system is an independent software component with the possibility of the integration into the different library systems. It means that the system has support for communication with the different bibliographic databases, as well as the support for different MARC formats. In addition, a client application is implemented as a desktop application so that it can be executed on the different operating systems. The application also has support for work in the local network as well as on the internet.

The system includes a unique interface for communication of the client application with the database - but the interface has two implementations. One of them is used when the database is located in the local intranet, and the other one is used when the database is located on the remote server on the internet. The system also includes the interface through which it receives the contents from the library records. This interface also has two implementations. One of them is used when the records are stored in the UNIMARC format and the other when they are stored in the MARC21 format. In that way, the system becomes independent of the format in which the records within the BISIS system (or within the other library systems) are stored. The system supports all standard activities of the work with users such as registering, charging and discharging users, searching users and publications, generating various types of statistical reports as well as user reminders.

The unified modelling language (UML 2.0) and the Visual Paradigm for UML 5.3 CASE tool[11] are used in phase of modelling. The system is implemented in the Java environment[12] . The Eclipse v 3.2 environment[13] is used as development tool. The system consists of three parts: client application, server part of the application and database.

2. Use case diagrams

The specification of the basic functionality of the system is represented on the Work with users use case diagram, which is shown in Figure 1 [Figure omitted. See Article Image.]. It includes the functions that a librarian carries out in every day work with users. This includes new library user registration, membership fee renewal, checkout procedure and searching holdings. Other functions of the system such as generating reports and reminders that are sent periodically to the users that are late for returning check out publications as well as functions for the system adaptations for work in a concrete library are given in the similar diagrams which are not presented in this paper.

Textual descriptions of the use cases:

Registering new user. Librarian registers new user into library. There are two user types: individual and corporate users. The librarian selects the user type and depending on the selection the Individual user use case or Corporate user use case is performed.

Individual user. Librarian registers individual user into library. Individual user is a single person that can use library holdings. Single person can be registered into the library through a collective/corporate user already registered into library. In that case, there is the information to which corporate user that individual user belongs. Within this use case, the User data use case, as well as Membership data use case, are carried out. If the user wants to check out some publications on the occasion of the registration, then the Charging and discharging use case is carried out.

User data. Librarian enters or updates data about an individual user. The data includes: user name and family name, name of a parent, address and place of residence, phone, e-mail address, umcn (unique master citizen number), identification card number and place of document issue, sex, age, secondary address, educational degree, occupation, title, organization of employee, mother tongue, interests, and note. The library determines which of this data is mandatory for data input. If the librarian wants to print library card then the Card printing use case is done.

Membership data. Librarian enters or updates membership data of a user. This data includes: user number, linking user data with the corporate user membership data if the user is registered by a corporate user, user category, type of membership, beginning date of the membership fee, expiration date of the membership fee, department on which the user is registered, price, and number of the receipt issued to the user for membership fee paid. The library determines which data is mandatory for data input.

Charging and discharging. A list of current borrower's account is displayed. If the user returns some of the checked out publications, the librarian can discharge the user or can renew the charge. If the user wants to be charged for a publication, the librarian can do loan charge by inputting its acquisition number or searching and retrieving the publication. In case of its retrieval, the Searching publication use case is carried out. If the librarian wants to print a lending form for the user, then the Printing lending form use case is carried out. If the librarian wants to see or to print the previous loan charges of the user, then the Printing history of loan charges use case is carried out.

Printing card. A display of the card, which is printable, is presented to the librarian and he can print it out as necessary.

Printing lending form . A display of the lending form, which is printable, is presented to the librarian for eventual printing. The lending form is a document on which can be seen current check out items of a user. By putting his signature on the lending form, a user confirms the accuracy of data recorded on the lending form.

Printing history of loan charges. Librarian determines a period for which he wants to see the history of loan charges. A listing, printable if needed, of the user loan charges in this period is displayed.

Corporate user. Librarian registers a corporate user into a library. A corporate user is the organization that enables certain privileges to its members at their inscription by its enrollment. The privileges depend exclusively on the contract between the corporate user and the library. The Corporate user data use case is carried out within this use case.

Corporate user data. Librarian enters or updates data about corporate user. The data includes: number of users, name of the organization, address and place of the organization, phone, fax number, e-mail address, additional address, and data about the contact person from the organization such as the name, family name and e-mail address of the contact person. The library determines which of this data is mandatory for data input.

Existing user. Carrying out this use case is possible in the three cases:

Through librarian's initiation in which case the librarian enters the user number.

When the data display of a user is selected in carrying out the Searching user results display use case.

When the data display of the user that was checked out by a publication is selected in carrying out the Searching publication results display use case.

Depending on whether a user is an individual or corporate one, the next use cases are carried out:

- Individual user data, Membership fee data , and Charging and discharging in a case of the individual user.

- Corporate user data in a case of the corporate user.

Searching users. Searching each user's data saved in the system is enabled. A search is performed by combining up to a maximum of five data with the operators and, or and not. In addition, this data can be combined with the periods of time when the user was charged or discharged along with his membership renewals. After the search has been done, the Searching user results display use case is performed.

Searching user results display. The hit number and the hits themselves are displayed. For each hit, that is, each user satisfied the query, user number, name, family name, parent name, address and place of residence are displayed. If the librarian wants to see the other data, then Existing user use case is carried out.

Searching publications. Searching is enabled with the defined prefixes of the BISIS library system text server. A search is done by combining up to a maximum of five data with the operators and, or and not. In addition, the prefixes can be combined with the periods of time in which the user was charged or discharged. After the search was done, the Searching publication results display use case is performed.

Searching publication results display. The hit number and the hits themselves are displayed. The hit display is enabled at the record level as well as the copy level. There is an indication for each copy whether it can be checked out or not. If the copy is checkable, then the use case can be extended by performing the Charging and discharging use case. If the copy is checked out, then the use case can be extended by performing the Discharging use case. If the librarian wants to see the data about the user checking out the copy, then Existing user use case is carried out. For each hit, a short info containing a certain information subset from the records about the publication is displayed.

Discharging. It relates to discharging of the publication that is found by carrying out the Searching publication results display use case.

3. Static structure of the system

The static structure of the system is depicted on one package diagram and four class diagrams. The classes of the user interface, i.e. of the screen forms, through the user communicates with the system are shown on the User interface class diagram. The logical model of the database is represented on the Data class diagram and based on the model the physical model of database is generated. The classes that are used for communication with the database are shown on the Proxy class diagram whereas the classes that present the model of the library record for library circulation system are displayed on the RecordUtils class diagram.

3.1 Package diagram of the system

The package diagram of the library circulation system by which the system structure is described is shown in Figure 2 [Figure omitted. See Article Image.].

The View package contains the user interface classes that are described with more details and displayed in section 3.2.

The Model package contains the classes that represent the database object model and serve for temporarily storing data the system deals with in that moment. These classes are described and represented in section 3.3.

The Manager package contains the classes that manage the data flow from the user interface towards the database and vice versa. The package is described in section 3.4.

The Proxy package contains the Proxy interface and its two implementations. Through this interface the classes from the Manager package communicate with the physical database. The package is described in section 3.5.

The RecordUtils package contains the interface representing the model of the bibliographic record in the library circulation system. This interface has two implementations. The package is described in section 3.6.

3.2 The View package classes

The class diagram User interface of the View package is given in Figure 3 [Figure omitted. See Article Image.]. The basic classes of the user interface that have hierarchical structure are depicted on this diagram, as well as the relations between these classes that are the unidirectional associations. These classes support the functionalities of the use case diagrams described in section 2. The attributes of the classes are defined based on the data described in the use cases of these given diagrams.

Through the BasicWindow class, the user selects the action he wants to execute. In order to perform the functionalities defined in the diagram of the Work with users use cases the IndividualUser, CorporateUser, UserData, MembershipData, Charging, SearchingUsers, SearchingUsersResult, SearchingPublications and SearchingPublicationsResults classes are used. Other classes are used for performing the additional functionalities defined on the diagrams which are not presented in this paper.

Through the IndividualUser and CorporateUser classes, the system user (librarian) accesses the data of the individual users, that is, corporate users of the library and can initiate the actions foreseen for the work with the data. The IndividualUser class uses the UserData class for the access to the basic data about user, the MembershipData class for the access to the data about the membership of the user and the Charging class for the access to the data about the check out publications of the user.

Through the SearchingUsers class, the system user (librarian) sets the criteria for searching for the library users. The results of the search are displayed through the SearchingUsersResults class. Similarly, through the SearchingPublications class, the system user sets the criteria for search for the publications and the search results are displayed by the SearchingPublicationsResults class.

Through the Reports class, the selection is made of the reports that should be generated by the system for the user. The generated report is displayed to the user through the ReportDisplay class.

Through the Reminders class, the user gets down to generating reminders, surveying the history of generated reminders and updating the reminder text. The user executes these actions through ReminderDisplay, ReminderHistoryDisplay and UpdatingReminderText classes.

Through the SystemParameters class, the system administrator sets the system parameters.

3.3 Model package classes

The Data class diagram of the Model package is shown in Figure 4 [Figure omitted. See Article Image.]. The diagram displays the database object model. Based on this model the physical database model is also generated. In the paper by [15] Tesendic (2007), the first version of this diagram is described. During the system development, the changes have been arisen on the diagram and the ending result of these changes is in the diagram in this paper. The differences between the two diagrams are not important, but for the sake of completeness the diagram is depicted in Figure 4 [Figure omitted. See Article Image.] in this section.

The Users class describes data about individual library user while the Groups class describes data about corporate library users. The Registering class gives details about the membership fee of an individual member and the Lending class represents data of user's checked out and returned items. Data about duplicate cards are described by the Duplicate class. Also, there are classes which present codebooks. The Location class is a codebook of check out and registration locations. The User_categs class is a codebook of user categories. The Mmbr_types class is a codebook of membership types. The Membership class is a codebook of membership fees. The Edu_degree class is a codebook of educational degrees. The Language class is a codebook of languages. The Organization class is a codebook of organizations. The Librarian class contains data about librarians having access to the system. Generated reminders are described by the Reminders class, whereas the Remind_types class is a codebook of reminder types and the Remind_counters class contains data about counters of reminder numbers for each year. The Archive class represents an archive of user data.

3.4 Manager package

The Manager package contains two classes: UsersManager and RecordsManager.

The UsersManager class manages the flow of user data from the user interface to the database and vice versa. Essentially, the class performs two kinds of activities:

On a request of the user interface classes from the package View, the UserManager class retrieves the data from and stores the data to the database using the classes of the Proxy package; on the client side, this data is temporarily stored in the objects of the Model package classes.

The UserManager class transfers data from the model to the user interface and vice versa.

The RecordManager class performs the communication between the system for library circulation and library records. In the library circulation system there is a need to display data from library records, as well as to change the status of a single copy from the checked out to the available status and vice versa. The RecordManager class searches and retrieves library records as well as temporarily stores records in the objects of the RecordUtils package classes. The RecordManager class delivers these objects to the user interface classes that use them for display data from the records. Also, the RecordManager class checks and changes a copy status in the process of charging copy.

3.5 The Proxy package

The class diagram of the Proxy package is shown in Figure 5 [Figure omitted. See Article Image.]. The package serves for the communication with the client side of application and the database.

The Proxy interface represents a set of abstract operations that are needed by the application to access the data of a database. The operations are as follows:

- getUser(userID:String):Users - for a given user number userID returns user data together with all his/her loan charges and membership fee renewals. This data is stored in the objects of the Model package classes.

- saveUser(user:Users):int - stores data about new or existing users into the database. The data is taken from the Model package class objects and a number is returned as the performance indicator of the operation execution. Based on the existence or inexistence of the sys_id attribute values of the Users class from the Model package, the existing user is distinguished from the new user.

- getAll(class:Class):List - for a given class from the Model package returns the list of all occurrences of the class.

- getGroup(userID):Group - for a given user number the userID returns data about corporate user. This data is stored into the class objects of the Model package.

- saveGroup(group:Groups):int - stores data about new or existing corporate users in the database. This data is taken from the class objects of the Model package, and a number is returned as a performance indicator of the operation execution. Based on the existence or inexistence of the sys_id attribute value of the Group class from the Model package, the existing user is distinguished from the new user.

- findUsers(fields:List, values:List, operators:List):List - performs a search of users based on the given list of user attributes, list of values of these attributes and list of and, or and not operators that are placed between each two operands of the type (attribute=value).

The ProxyLocal class represents the Proxy interface implementation that is used when the database server is in the local intranet. The implementation uses permanent connection with database by means of the JDBC driver.

The ProxyNet class represents the Proxy interface implementation that is used when the database server is in a remote server that is accessed via the internet. In that case permanent connection with database is not used.

3.6 RecordUtils package

In Figure 6 [Figure omitted. See Article Image.] the class diagram of the RecordUtils package is displayed. This package serves to the rest of the system for obtaining certain contents from a library record and these are displayed in the library circulation system. The package consists of an interface and two implementations thereof.

The RecordBean interface represents the set of abstract operations that return certain contents from library records. In dependence on the bibliographic format these contents are stored in different fields and subfields. The RecordBeanUnimarc class is the implementation of the RecordBean interface that is used in the case when library records are in the UNIMARC format whereas the RecordBeanMarc21 class is used in the case when library records are in the MARC21 format.

4. Implementation of the user interface

The implementation is done based on the use cases and class diagrams that are listed in the previous sections. The functionalities described on the use case diagrams are input on the screen forms of the user interface through which the librarian communicates with the system. The screen form implementation is performed on the base of the User interface class diagram. Some of the screen forms with the implemented functionalities of the Work with users use case diagrams are displayed and described here. The remaining mentioned screen forms are similarly implemented as the screen forms displayed in this paper and are not specifically represented here for the purpose of saving space.

4.1 User data

When starting the application, the basic screen form of the application is opened first. The screen form represents the implementation of the BasicWindow class from the User interface class diagram. The basic screen form contains the application main menu and application toolbar. All remaining screen forms are opened within this basic screen form. In Figure 7 [Figure omitted. See Article Image.], the appearance of the application with opened screen form for work with users is displayed. The main menu is divided in five parts: Cataloguing, Users, Searches, Reports and System. The Cataloguing menu is related to the bibliographic material processing that is not the subject of the paper. The Users menu consists of the two submenus - New and Existing submenus. In the New submenu, there are actions related to the registration of the new user. The New submenu has two actions - Individual and Corporate. The Individual action initiates the function of the registration of the new individual user, and the Corporate action initiates the function of registration of the new corporate user. This submenu represents carrying out of functionality of the New user registration use case displayed on the Work with users diagram. The Existing submenu contains the actions related to the work with the existing user in the system. These are Data, Membership and Charging actions. The functions of the user data changes, continuation of the membership fee and user charging and discharging are initiated by those actions. This submenu represents carrying out of functionality of the Existing user use case. Two actions, Users and Publications, are in the Search menu. The Users action initiates the function of the search for user, and the Publication action initiates the function of the search for publications. In the Reports menu, there are the actions by which the generation of the reports existing in the system is started, whereas, in the System menu there are the actions related to the system administration and updating codebooks. In the toolbar of the application there are the shortcuts for the most frequently used actions from the menus.

After the action for the registration of the new individual user is selected the screen form given in Figure 7 [Figure omitted. See Article Image.] is opened. This screen form represents the implementation of the IndividualUser class from the UserInterface class diagram and also the functionality of the Individual user use case from the Work with users diagram is carried out on the same screen form. The screen form contains four cards:

Basic data;

Additional data;

Membership; and

Charging.

The Basic data card is displayed also in the above-mentioned Figure 1 [Figure omitted. See Article Image.]. The Basic data and Additional data cards represent the implementation of the UserData class from the UserInterface class diagram and the functionality of the User data use case is carried out on these cards. The content of the Membership card represents the implementation of the Membership class and carries out the functionality of the Membership data use case, whereas the content of the Charging card represents the implementation of the Charging class and carries out the functionality of the Charging and Discharging use case.

The user data is input through Basic data and Additional data cards. The user number and the rest of data about the library membership are entered into the Membership card. Since the same screen form is used for both the new and existing user, it is possible to renew user membership fee as well as to print a receipt. Charging and discharging user are done on the Charging card. The table with check out publications can be seen. It is possible to perform two actions - discharging and extending a loan. The publications can be checked out in two ways - by entering acquisition number of the publication or by searching library catalogue that brings to screen form onto which the functionality of the Searching publications use case is carried out. There is a button by which the check out card printing use case is performed, as well as the button by which the Printing history of loan charges use case is performed. Also, there is a short info about a user with warnings of expiring membership fee and sent reminders.

Work with data of an existing individual user is similar to the data input for the new user. The same screen form is used as that one, previously described, for input of the new user. The screen form for the user number input is opened by selection one of the three possible actions for the work with the existing user Data, Membership and Charging. After the user number is entered, the screen form represented in Figure 7 [Figure omitted. See Article Image.] opens up with one of the cards Basic data, Membership or Charging depending on the action that was chosen and in the case that the entered number belongs to the individual user. In the case where the number belongs to the corporate user, the screen form opens up for the corporate user representing carrying out the Corporate user data use case. Previously described actions represent carrying out the Existing user use case. If the librarian does not know the number of the user whose data s/he wants to see on the screen form for user number input, s/he can go to the screen form for user search that will be shown later in this section.

If an action for registering new corporate user is selected in the menu, the screen form, on which the functionalities of the Corporate user and Corporate user data use cases are carried out, opens up and it represents the implementation of the Corporate user class. The data set for the corporate user is entered through that screen form. It is used also for changing data of a corporate user.

4.2 Search

By choosing the user search action from the menu the screen form displayed in Figure 8 [Figure omitted. See Article Image.] is opened. This screen form represents the implementation of the SearchingUsers class and carrying out the functionality of the Searching users use case. The searching criteria are set up on the form. It is possible to search across all the fields that are defined in the Users class represented on the Data diagram in the section 3.3. The criteria can be combined with the and, or and not operators. Up to five criteria of the type "field=field value" can be specified. The button with the " ... ." mark initiates the action for the selection of the field over which the search is performed. The name of the chosen field appears on the left side of the button. On the right side of the button, there is a textual field into which the requested value of the chosen field of the Users class is specified. In case that the requested field takes the values from some of the codebooks linked with the Users class, instead of the textual field for the data input a drop-down menu appears from which one of the existing values of the codebook is chosen.

Also, it is possible to combine these criteria with the time period for the dates existing in the Registering and Lending classes and these are: charging date, discharging date, period of loan, membership renewal date, and membership expiration date, as well as with the location for each of the actions carried out in the time period. The screen form, on which the user searching results are displayed, is opened by the initiation of the search action. The form represents the implementation of the SearchingUsersResults class and carrying out the functionalities of Searching users results display use cases. The users retrieved on the base of the given criterion are displayed in a table. It is possible for a user chosen from the table to open a screen form for work with user data. The screen form is previously described and it represents carrying out of the Existing user use case.

The screen form displayed on Figure 9 [Figure omitted. See Article Image.] is opened after selecting the action for searching publications. This screen form represents the implementation of the SearchingPublications class and carrying out the functionalities of Searching publications result display use cases. The search criteria are assigned on the screen form. The search performs in accordance with the text server prefixes and it is possible to assign up to five criteria that can be reciprocally paired up by the and, or and not operators. The prefixes are related to the library record content. The screen form needed for the prefixes selection is opened by the button with the sign " ... ". The prefix name is on the button's left side. The textual field into which the searched value of the chosen prefix is assigned is on the right side of the button. If the prefix designates some coded data, it is possible to open the codebook from which the code is selected. In addition to these criteria it is possible to add time periods for the dates of charging and discharging publications, as well as the location for each of the actions done in this time period.

The screen form for the display of the search results is displayed in Figure 10 [Figure omitted. See Article Image.]. The screen form represents implementation of the SearchingPublicationResults class and carrying out of the functionalities of the Searching publications results display use case. The result list is displayed on the left half of the screen form. The results include the library records that satisfied search criteria. The author, title, publisher and publishing year are displayed in each record in the list. By a double click on each element of the list a sublist is opened for the corresponding element containing the acquisition numbers of the copies belonging to the record as well as the status of each copy. It is possible to discharge the copy that is checked out what represents carrying out of the Discharging use case. Also, the number, name and surname of the user that borrowed the copy are displayed at right upper corner of the screen form for each checked out copy. It is possible to open the screen form for work with data of that user what represents carrying out the Existing user use case. It is possible to charge the copies that are chargeable which is represented by carrying out Charging and Discharging use case that is preceded by entering the number of the user that is charged. The details of the library record selected from the hit list are displayed on the right side of the screen form. These details are displayed in two ways: as a short info as displayed in Figure 10 [Figure omitted. See Article Image.] or in the form of a catalogue card. It is possible to see desired display by selecting the corresponding card.

5. Implementation of the database updating

The part of the application that is intended for the work with data from the database is implemented based on the specification of the Model package, Proxy package and UsersManager class that is given in section 3. The Model and Proxy Java packages with their classes represent the implementation of the specification of the Model and Proxy packages, whereas the UserManager Java class represents the implementation of the UserManager class that is contained in the Manager Java package.

The Java classes of the Model package represent the implementation of the data base object model. The implementation is done based on the specification of the classes displayed on the Data class diagram. A Java class corresponds to each diagram class having the same name, for example, the Users.java Java class corresponds to the Users diagram class. All attributes specified in the diagram classes exist also in the implementation. The Java classes are implemented under the JavaBeans standard and it means that there are the setXxx() and getXxx() methods for each xxx attribute. The setXxx() methods set the attribute values and the value is forwarded to the method as a parameter, whereas the getXxx() methods return the attribute values.

5.1 Implementation of the communication with database

The part of the application that is intended for the communication between the previously described database object model and physical database is carried out by the ORM (Object/Relational Mapping) technology, and the Hibernate package[14] is used for the implementation. This part of the application represents the implementation of the Proxy package that is described in the section 3.5 and it is packaged in the Java package that is also named as Proxy. The classes and the interface displayed on the class diagram of the Proxy package have its implementation in the form of the Java classes and interfaces and these are the Proxy.java interface, the ProxyLocal.java class and the ProxyNet.java class. In addition to this, the files needed to the Hibernate package for storing information about the database object model mapping onto the physical database are contained in the Java package. That information is stored in the XML documents. For each class of the Model package there is an XML document named ClassName.hbm.xml containing the information on mapping this class to the corresponding table of the database.

The ProxyLocal.java class represents the Proxy.java interface implementation that is used for the access to the database when it is in the local intranet. The class implements all interface methods that are defined and described in section 3.5, as well as some auxiliary methods for which the need has arisen during the implementation. The implementation uses the JDBC driver for the communication with database and it means that a permanent connection exists with the database. Because of that, this implementation is used as the local intranet.

During query running the object of corresponding Model package class is obtained as a result. Also, during the database updating the objects of the Model package classes are forwarded to the methods. Based on the information about mapping object model to database, which is described previously, Hibernate makes decision about on which tables to run queries and which object attributes correspond to which table fields of the database.

The ProxyNet.java class represents the implementation of the Proxy.java interface that is used for the access to the database when the database is on the remote server. The class implements all methods of the interface that are defined and described in the section 3.5. This implementation realizes the communication with the database via the server side of the application that is on the same or any other remote server. The server side of the application is implemented as the web service in order to provide the communication between the server and client via the HTTP protocol.

The operations offered by the web service are equivalent to the methods that the Proxy.java interface possesses and that are implemented by the ProxyNet.java class. The methods of the ProxyNet.java class call the corresponding operations of the web service and forward to them the objects that have been received whereas the further operations of the web service carry out the functionality of the method that is defined by the Proxy.java interface. The web service is not public and it is exclusively intended for use by the client side application of the library circulation system.

The server side of the application contains the web service implementation and the database object model implemented by the Model package already described. The Hibernate package is used for the implementation of the web service operations and the implementation of the operations is the same or very similar to the implementation of the ProxyLocal.java class methods that are described in the previous section. The differences in regard to the local interface exist mostly in the way the Hibernate accesses to the database. In the case of the local interface the Hibernate package is set to access to the database through the JDBC driver. That way of the access is chosen for the sake of the simplicity of the system maintenance because, in that case, the system at the server side needs nothing but database. In the case of the interface for the remote access, the existence itself of the web service already requires the existence of the server side of the application that is carried out on a web server. That is why the extenuating circumstances enabled by the web server are chosen instead of the JDBC driver for the communication with database. Thus, in this case, the Hibernate is set to use JTA access to the database across the web server instead of the JDBC driver. Because of the transparency of the Hibernate interface intended for the transactions with database whether in the case of using the JDBC or in the case of the JTA access, the code modifications using the interface are insignificant. That is why the implementation of the web service operations is very similar or identical to the implementation of the ProxyLocal.java class methods.

5.2 Implementation of the manager

The UserManager.java class contained in the Manager Java package implements the functionalities that direct the flow of data about the users from the user interface to the database and vice versa. The class makes the links among the View, Model and Proxy packages by its functionalities.

These functionalities include:

- retrieval of data from the database through the Proxy package classes that are temporarily stored into the class objects of the Model package;

- storage of the data from the object model into database through the Proxy package classes; and

- load of data from the object model to the user interface and vice versa.

Running methods of the class is initiated from the user interface towards the user actions. In total, 17 methods are implemented and some of them are:

- loadUser(User userForm, Users userModel) - that loads data about the user from the userModel object model to the screen form represented by the userForm parameter for work with users.

- loadGroup(Group groupForm, Groups groupModel) - that loads data about the corporate user from the groupModel object model to the screen form represented by the groupForm parameter for work with corporate users.

- getUser(User userForm, Group groupForm, String userID) - that retrieves data about the user for the given userID user number through the Proxy package classes, from the database and stored data in the Model package classes and then, by calling one of two previously described methods (depending on the fact whether the user is individual or corporate), loads the data from the object model to the corresponding userForm or groupForm screen form.

6. Implementation of the work with library records

The application part intended for the work with the library records is implemented based on the specification of the RecordUtils package and the RecordManager class described in detail in section 3. The implementation of the specification of the RecordUtils package is represented by the RecordUtils Java package with its classes, whereas the implementation of the RecordManager class is represented by the RecordManager.java Java class that is contained in the Manager Java package.

6.1 Implementation of the library record interface

The library circulation system obtains the contents of the library records by the implementation of the classes of RecordUtils package the specification of which is described in section 3.6. The package contains an interface and two classes that have their implementation in the form of Java classes and the interfaces such as RecordBean.java interface, RecordBeanUnimarc.java class and RecordBeanMarc21.java class. These classes and the interface implement all methods described in section 3. The RecordBeanUnimarc.java class is the implementation of the RecordBean.java interface that is used when the library records are in the UNIMARC format, whereas the RecordBeanMarc21.java class is used when the library records are in the MARC21 format.

In the frame of the BISIS system, as the format for library record processing, a variant of the UNIMARC format that is named YUMARC format is used. Because of that the implementation of the RecordBeanYumarc.java interface is made and it is used for the work with records in the YUMARC format being the case in the BISIS system. This class also implements all methods of the RecordBean.java interface. The object model of the BISIS system record is forwarded to the class constructor. The class methods of the record object model take the necessary data in order to run its functionality. A survey of all the class methods and corresponding record fields and subfields from which the values are taken is given in Table I [Figure omitted. See Article Image.]. The 996dl and 996dn designations in the table represent the l and n subsubfields of the 996d subfield.

The record object model of the BISIS system is implemented by the Record package that is contained within the BISIS system. Figure 11 [Figure omitted. See Article Image.] demonstrates the Record package class diagram. The basic package class that represents a library record is the Record class. The contents of the fields and subfields of the library record are contained in the Field and Subfield class objects respectively. A description in details of the package and classes is given in the paper by [9] Dimic and Surla (2009).

6.2 Implementation of the record manager

The RecordManger.java class implements the functionalities related to the communication between the library circulation system and the library records. Within the BISIS system the records are accessed through the text server implemented within the system. The RecordManger.java class is intended for the communication with the text server.

The first functionality for which the class is intended is the modification of the status of a single copy. On the occasion of charging a copy it is necessary to check if the copy is in some of the chargeable status in order to be approved charging the copy. Also, on the occasion of charging it is necessary to modify the copy status into check out, as it is necessary to modify the status into free on the occasion of discharging. This functionality is carried out by the following RecordManger.java class methods:

- lendBook(String acquisit_no) - the status of the copy with the acquisit_no acquisition number is tested and if the copy is chargeable, the status is modified into check out.

- returnBook(String acquisit_no) - the status of the copy with the acquisit_no acquisition number is modified into free.

The second functionality for which the class is intended is search and retrieval of the library records. A search is performed by creating queries in the text server language and by sending them to the text server. The text server returns as hits the records in the record object model implemented by the Record package that is previously described. The class has to forward these records to the rest of the library circulation system in the form of the RecordUtils package class objects the implementation of which is also previously described. The system further uses these objects for display of data from the library records. The RecordManger.java class methods for the communication with text server are as follows:

- getRecord(String acquisit_no) - retrieves the record containing the copy with given acquisit_no acquisition number.

- getRecord(Query q) - retrieves the records satisfying the q query; the query is created by the makeLuceneAPIQuery() auxiliary method that creates the query of the adequate parameters in the text server language.

7. Conclusion

After the introduction of the BISIS library information system, version 3.1, into city libraries, the existing segment related to the library circulation system was evaluated as being inadequate for the needs of the library management in these libraries. Based on such an experience as well as on the analysis of the existing software solutions given in this work, a specification and modeling of the library circulation system was made so that all requirements of electronic business that involve users of the city and special libraries were fully satisfied.

Based on the model, the library circulation system is implemented in the Java environment by using the open-source programming packages. The software system consists of the client side that is realized as a desktop application and the server side that is realized as the web service and database. The software system is integrated in the new (fourth) version of the BISIS system. Testing and verification of the system are done in the city and special libraries.

The basic characteristics of the proposed software architecture are:

- to provide the work with the local database (intranet) and the remote database (internet); and

- to support the work with different library formats (UNIMARC and MARC21, as well as the other).

In addition to the described functionalities of the library circulation system within further development of the BISIS system, special attention will be devoted to the modeling and implementation of a portal for the library users as well as to archiving data related to the users. Through the portal, a user should access to his/her own account by which renewal of a loan, reservation of publications, as well as survey of check out history should be enabled. By forming data archive of library circulation, a possibility of generating different statistical reports on reading characteristics across different criteria for diverse time periods should be more feasible.

Proceedings, International Conference on Distributed Library Information Systems, Ohrid, FYROM

This paper is part of the research project "Abstract models and applications in computer science", supported by the Ministry of Science of the Republic of Serbia (Project No. 144017).

Footnote

1. Network Development and MARC Standards Office, Library of Congress, available at: http://lcweb.loc.gov/marc/ (accessed 10 July 2008).

2. MARC Records, Systems and Tools, available at: www.loc.gov/marc/marcservice.html (accessed 10 July 2008)

3. Aleph 500, available at: www.exlibrisgroup.com/category/Aleph (accessed 10 July 2008)

4. Voyager, available at: www.exlibrisgroup.com/category/Voyager (accessed 10 July 2008)

5. Atriuum, available at: www.booksys.com/v3/products/atriuum/ (accessed 10 July 2008)

6. Concourse, available at: www.booksys.com/v3/products/concourse/ (accessed 10 July 2008)

7. Cybertools for Libraries, available at: www.cybertoolsforlibraries.com/ (accessed 10 July 2008)

8. EOS.Web, available at: www.eosintl.com/ (accessed 10 July 2008)

9. Evergreen Integrated Library System, available at: http://open-ils.org/ (accessed 10 July 2008)

10. Koha Integrated Library System, available at: www.koha.org/ (accessed 10 July 2008)

11. Visual Paradigm, available at: www.visual-paradigm.com/product/vpuml/ (accessed 10 July 2008)

12. Java, Sun Microsystems, available at: http://java.sun.com/ (accessed 10 July 2008)

13. Eclipse SDK v3.2.1, available at: www.eclipse.org/ (accessed 10 July 2008)

14. Hibernate v3.2.2, available at: www.hibernate.org/ (accessed 10 July 2008)

References

1. Adams, B. and Noel, B. (2008), "Circulation statistics in the evaluation of collection development", Collection Building, Vol. 27 No. 2, pp. 71-3, available at: www.emeraldinsight.com/10.1108/01604950810870227.

2. Babafemi, G.O. (2002), "Public relations activities in an academic library: the roles of the circulation librarian", Library Review, Vol. 51 No. 9, pp. 464-8, available at: www.emeraldinsight.com/10.1108/00242530210446944.

3. Belic, K. and Surla, D. (2008), "User friendly web application for bibliographic material processing", The Electronic Library, Vol. 26 No. 3, pp. 400-10, available at: www.emeraldinsight.com/10.1108/02640470810879536.

4. Bennett, M.J. (2007), "OPAC design enhancements and their effects on circulation and resource sharing within the library consortium environment", Information Technology and Libraries, Vol. 26 No. 1, pp. 36-46, available at: http://proquest.umi.com/pqdlink?did= 1269339471&sid=1&Fmt=3&clientId=57708&RQT=309&VName=PQD.

5. Boberic, D. and Surla, D. (2009), "XML editor for search and retrieval of bibliographic records in the Z39.50 standard", The Electronic Library, Vol. 27 No. 3.

6. Boone, M.D. (2002), "Taking FLITE: how new libraries are visioning their way into the future", Library Hi Tech, Vol. 20 No. 4, pp. 464-8, available at: www.emeraldinsight.com/10.1108/07378830210452668.

7. Cheng, R., Bischof, S. and Nathanson, A.J. (2002), "Data collection for user-oriented library services: Wesleyan University Library's experience", OCLC Systems & Services, Vol. 18 No. 4, pp. 195-204, available at: www.emeraldinsight.com/10.1108/10650750210450130.

9. Dimic, B. and Surla, D. (2009), "XML Editor for UNIMARC and MARC21 cataloguing", The Electronic Library, Vol. 27 No. 3.

10. Falk, H. (2005), "Temple of the computer", The Electronic Library, Vol. 23 No. 2, pp. 244-8, available at: www.emeraldinsight.com/10.1108/02640470510592951.

11. Joint, N. (2008), "Is digitisation the new circulation? Borrowing trends, digitisation and the nature of reading in US and UK libraries", Library Review, Vol. 57 No. 2, pp. 87-95, available at: www.emeraldinsight.com/10.1108/00242530810853973.

12. Kern, C. (2004), "Radio-frequency-identification for security and media circulation in libraries", The Electronic Library, Vol. 22 No. 4, pp. 317-24, available at: www.emeraldinsight.com/10.1108/02640470410552947.

13. Konjovic, Z. and Surla, D. (2004), "Overview of the development of the library information system BISIS", , pp. 13-18.

15. Tesendic, D. (2007), "A database model for library material usage", NSJOM, Vol. 37 No. 1, pp. 155-62, available at: www.im.ns.ac.yu/NSJOM/.

Appendix

About the authors

Danijela Tesendic has worked at the Department of Mathematics and Informatics, Faculty of Science, Novi Sad on the position of research assistant since 2005. Ms. Tesendic received her Bachelor degree in 2004 and Master degree in 2007 both in Computer Science from the University of Novi Sad, Faculty of Science. She is an active participant on the project "Abstract models and applications in computer science", supported by the Ministry of Science and Environmental Protection of the Republic of Serbia and has published four papers related to the development of the library information systems. Also, she holds teaching seminars on the subject Computer Networking at the Department of Mathematics and Informatics. She is the corresponding author and can be contacted at: [email protected]

Branko Milosavljevic is an Assistant Professor at the Faculty of Technical Sciences, Novi Sad, Serbia since 2004. Dr Milosavljevic received his Bachelor degree (1997), Master degree (1999), and PhD degree (2003) all in Computer Science from the University of Novi Sad, Faculty of Technical Sciences. Since 1998 he is with the Faculty of Technical Sciences in Novi Sad. Dr Milosavljevic participated in six science projects; in one he was the project leader. He published more than 70 scientific and professional papers.

Dusan Surla is a Full Professor at the Department of Mathematics and Informatics, Faculty of Science, Novi Sad, Serbia since 1991. Dr Surla received his Bachelor degree in Mathematics from the University of Novi Sad, Faculty of Philosophy in 1969, Master degree in Robotics from the University of Novi Sad, Faculty of Mechanics in 1976, and PhD degree in Robotics from the University of Novi Sad, Faculty of Technical Sciences in 1980. Since 1976 he is with the Faculty of Science in Novi Sad. Dr Surla participated in 14 science projects; in 8 out of 14 he was the project leader. He has published more than 170 scientific and professional papers.

  

Illustration

Figure 1: Work with users use case diagram

  

Figure 2: Package diagram

  

Figure 3: User interface class diagram

  

Figure 4: Data class diagram

  

Figure 5: The Proxy class diagram

  

Figure 6: Class diagram of the RecordUtils package

  

Figure 7: Basic data screen form

  

Figure 8: Screen form for searching user

  

Figure 9: Screen form for searching publications

  

Figure 10: Searching publications result display

  

Figure 11: Record package class diagram

  

Table I: RecordBeanYumarc.java class methods