1.1 System Objectives
The Serial Control Record(SCR) Builder is a software system which will
provide librarians of the University of Southern California(USC)
an automated tool to build the SCR database. The SCR
database is a database used by SIRSI library information system, and contains
information about the serial publications like journals and magazines.
The USC libraries have three different input sources for the
serial publications information - USC Record, Orion Record, and FAXON Record.
Each record has its own format, and contains different information about
a serial publication. The SCR Builder is an
automatic translator which converts the three legacy record formats
into the SCR format.
Currently, the conversion from the legacy data into the SCR data is
done manually by the librarians. Currently, there are over 15,000 records
to enter into the database. And each Serial Control Record has
about 80 data fields to be filled. Because of this, it is very time consuming
and has a high possibility of inaccurate and inconsistent conversion due to
the human error.
The SCR Builder is composed of a record converter(batch processor, BP),
mapping table editor, and exception editor. The record converter is a
batch processing
program which automatically converts the three legacy record formats into the
SCR format. By using the mapping table editor, the user can adjust the
mapping conditions to improve the conversion quality.
The exception editor is a convenient tool to browse and edit
the records which cannot be correctly converted into the SCR
records by the batch processor. A Serial Control Record contains several
required fields which are essential for a serial publication. If
one of the required fields of a record cannot be filled by the
record converter, the record is marked as an exception record and then
the librarian is notified of the exception record which the librarian has
the option to manually edit.
All the components of the SCR builder have graphical user
interfaces(GUIs), by which the librarians can interact with the system
in a user-friendly manner to start, adjust and monitor the converting
process, and browse and edit the exception records. The conversion
status monitor, the mapping table editor, and the exception record
editor interfaces are the major user interfaces of the SCR
builder.
The BP status monitor provides the user
an interface to specify the conversion process and start or stop the
process. Also it shows the user the current status of the conversion
process like the number of records processed, the number of exception
records generated, the number of errors occurred, the time elapsed,
etc. By using this interface, the user can manage and monitor the
conversion process.
Through the mapping table editor, the librarians can adjust the
conversion process by editing the mapping table. When a test run of
the record converter generates a lot of exception records, the users
can specify specific mapping conditions through this interface to
reduce the number of exception records in the real conversion process.
This can make the conversion process more flexible.
By using the exception editor, the users can browse and print the
exceptions and system errors which are generated during the current
conversion process. The user can select an exception record and fill
the unconverted fields of the record manually. This editing
function makes the SCR building job more robust and flexible.
The SCR builder will provide the USC libraries a fast, flexible,
accurate, and user friendly software system to build the SCR database
for the serial publications.
1.2 System Scope and Context
Figure 1.1 shows the system scope of the SCR Builder and the users of
the system. The record converter gets input data from the three major input
sources, converts the data formats into the SCR format and stores the
data into the SCR database. The users can browse all the exceptions
and system errors generated during the conversion process by using the
exception editor, and edit the exception records manually and store
them into the SCR database. The users of the SCR builder will be the
USC librarians who are in charge of the building the SCR database.
Figure 1.1 System Scope Block Diagram
There is an existing SIRSI interface that allows the librarians to
access the SCR database and
provide the librarians the tools to manage the SCR database. The
general USC library patrons(students, faculty and staff) can access
the catalog of the serial publications through the USC library Web
site which interacts with the SIRSI interface.
The USC UCS(University Computing Services) computing environment is
the basic infrastructure for the library information system. All the
servers and the network systems are operated and managed by the
UCS.
Figure 1.2 represents the use cases of the system. There are five
stakeholders who work with this system. The record conversion
operator initiates the conversion batch processor, the SCR editor uses
the exception editor and edits the exception records which are
generate by the batch processor, and the exception records are managed
by the exception record database manager. The mapping coordinator
adjust the mapping table by using the mapping table editor to improve
the mapping quality and the system manager monitors and maintain the
system and, ensures the normal function of the system.
3.1 Current System Overview
The large number of serial publications like journals and magazines
are received each day by the USC libraries. So the libraries need a
database of serial publications to maintain information about
the journals and magazines, and keep track of currently available
issues. The Serial Control Record database is the database for the
serial publications and is now in the process of being built. The
SIRSI library information system accesses this SCR database, and
provides catalog services to the library patrons.
In order to put correct information about a serial publication into the
SIRSI's SCR database, several different input sources should be referenced
up and searched. The USC Record, Orion Record, and
FAXON Record are the three major input sources for the serial
publications. These input sources are taken from different
institutes who use different record formats. The order and
representation of the data items for a serial publication are
different among the input sources.
Currently, the SCR database is constructed manually by the librarians.
The librarians take a look at the actual journal and bibliographic
information of the publication and collect data for the SCR.
After building the SCR database, the information about
the serial publications is available to the library patrons
through the SIRSI interface. The library patrons like students,
faculty, and staff of USC can see the catalog of the serial
publications through the USC library Web site. Also the librarians can
manage the SCR database after loading by using the the SIRSI user interface.
They may add a new record, delete a record, or modify the information
of a record through the SIRSI user interface.
Figure 3.1 shows the block diagram of the current system.
Figure 3.1 Current System Block Diagram
3.2 Current System Shortfalls
There are about 15,000 records of the serial publications which need
to be entered into the SCR database.
And each Serial Control Record has about 80 data fields which should
be filled after the conversion process. So the manual
process is a very time consuming job which will take more than
10 years to complete.
The manual process of building SCR database may lead the
database to contain incorrect information due to human mistakes.
It is possible that the librarian misinterprets the
information of the serial publication and puts the information
into the database incorrectly.
To reduce the database building time, USC libraries needs more
librarians to do the process in a parallel
manner, and this will increase the costs of the SCR database
building process.
When the conversion process is done by several librarians in a
parallel manner, the conversion result may be inconsistent.
Even though they use the same decision procedure for the
conversion, some data fields of the SCR need human decision to be
filled with certain data which should be selected from several
choices.
As a result of the WinWin negotiation, we decided the changes to
the current system for automating the current manual process and
providing efficient tool to build the SCR database. Following sections
are the description about the changes, priorities, rationale, and
changes rejected.
4.1 Description and Prioritization of Changes
Priority: Essential
The record converter of the SCR Builder performs the automated
record conversion job. It accepts data with the legacy record formats
and converts them into the SCR format data. This automatic conversion
capability will help the USC libraries to build the SCR database
quickly and correctly.
Priority: Essential
The user can browse the exception records and system errors through
the exception editor. The exception editor explains the cause of
an exception by pointing out all the missing fields which are required
to convert the input record into the Serial Control Record. And the
user can edit the missing fields manually by using this editor.
Priority: Desired
Through the mapping editor, the user can specify specific mapping
conditions for a conversion process to reduce the exception records
and improve the accuracy of the conversion. This capability will make
the conversion process flexible enough to adjust the mapping condition
of the record converter depending on the information quality of the
input sources.
Priority: Essential
The record converter shows the status of the conversion process refers
to the progress as to how much records have been processed, how
many exceptions and errors have occurred, how long it has been working
and other important information.
The user may need these metrics not only as an indicator that
processing is going on but also to measure the efficiency of the
system.
Priority: Essential
The system provides the facility to print out
the exception records generated and system errors happened.
The contents of the result records will be printed in the human
readable form.
Priority: Desired
This system may be developed as a general record converter
which is able to solve a general mapping problem. But the
general mapping problem is not currently required by the USC
libraries. Also, to develop the general mapping system,
more time and efforts should be spent. So, instead of
providing the general converter, the we will make the system
as general as possible to adapt the basic algorithm to other
products or easily extended for future demands.
Priority: Desirable
This program provides the hypertext help system to assist users to
interact with this system easily and correctly. All the help messages
are descriptive enough to be understood by the users - the USC
librarians.
Priority: Essential
Only authorized users are able to access the system because this system
deals with important data related to the serial publications.
The working environment of the system which the library client
offered is based on the computer
and campus network environment which is supported by the USC UCS.
The record converter batch-processor will be run on the
library's dedicated server which is a SUN Ultra Enterprise 4000.
And the record converter client interface and the exception
editor will be run run on a Mac or a PC.
So, the developer should consider the UNIX environment for the
batch processor and TCP/IP for the communication between
client programs and the server program.
There are approximately 15,000 records to be converted into
the SCR format.
Currently, there are at least three different input sources
for constructing the SCR database. The USC Record, Orion Record, and
FAXON Record are the three major input sources for the serial
publications. To improve the quality of the record conversion,
the user may add extra input sources to the converter.
This software system automates the record conversion process
hence the SCR database construction process will be done
in a faster way than the current manual process.
This determines whether or not the system is usable to the
librarians. Currently, the quality of the converted data
depends on the librarians who use it and the input sources.
By automating the conversion process, the quality will not
depend on human error. Also the user can add another input with
another format which is different from the three major formats
when the mapping process generates too many exceptions and
cause the results to be unacceptable.
This is related to the second capability rationale, and allows
the user to adapt the mapping table to the specific input
source they have at hand.
When the conversion process converts a record for a serial
publication, it should consider the three input
sources in a prioritized order to avoid the conflicts among
the different input data for a data item of the
publication. The system will take in priority numbers and based
on those number, resolve any conflicts that arise from the
different input formats.
The potential users are the USC librarians including
library staff and faculty. They
are experts on library systems but they may not be proficient with
computer systems. Therefore, all
the user interfaces of the system will be presented with
GUIs(Graphic User Interfaces) which look and feel like the
current SIRSI's Unicorn editor. This will have an impact on the
amount of training needed and consistency of user interface.
The system has the capability to explain the cause of exceptions
which occur during the conversion process. The
explanation of an exception will help users edit
the record efficiently. The
explanation will point out all the missing fields which are required to
transform the input record into the SCR format record.
For major hardware related faults, the record conversion
process will stop, produce an error message and exit cleanly.
For minor problems that will not can be recovered from, the
system will just log the error in some error file and explain
the cause of the error.
The system will provide capability of browsing system
error messages to check the error messages which occurred
during the conversion process. The user may browse the error
messages during or after the conversion processing in order to
check the mapping process.
The context sensitive help would be very useful to the user. However,
for this system, user is aware how they do with this
system, therefore context sensitive help may not necessary.
Also, in order to build the context sensitive help system, more time
and effort is required. So the system will support the plain
hypertext help system.
5.1 Operational Overview
Figure 5.1 Operational Overview Diagram
Figure 5.1 shows the operational overview of the SCR Builder. The
upper half part of the diagram is the part for this system.
The conversion batch processor in the record converter gets input data
from the three major input sources, converts the data formats into the
SCR format.
The result of the batch processing is not stored directly into the SCR
database. The converted Serial Control Records are first collected
into the Specific Data Format(SDF) files which are the intermediate
results of the conversion. After editing the exception
records and veryfying the correct conversion of the source records, the SDF
files are loaded into the SCR database by the Automatic Generator
which is a batch loading program.
The potential users of this system will be the USC librarians who are
in charge of the SCR database building work.
The user can indicate specific mapping conditions to the conversion
process by using the mapping editor interface provided by the
conversion editor. And during the
conversion processing, the user can monitor the current conversion
status through the status monitor interface of the record converter.
The status information
consists of the number of records processed, the number of exception
records generated, the number of errors occurred, the time elapsed,
etc.
During and after the conversion processing, the user can browse and
print all the exceptions and system errors generated during the conversion
process by using the browsers in the exception editor, and edit the
exception records manually and store them into the SDF files.
The user should give some authentication information before login into
the system. Only authorized users are able to access the system.
This program provides the hypertext help system to assist users to
interact with this system easily and correctly. The users can access
the help system any time they want.
5.2 Operational Stakeholders
The potential users of the SCR builder will be the USC
librarians including the library faculty and staff
who are in charge of the SCR database building process. This
system is not a system which provides services to the general
library patrons.
Among the system users, the record conversion operators are
the people who initiate the conversion batch processor and
keep track of the correct operation of the conversion
processing by checking the status messages generated.
These are the people among the system users who can determines
the mapping conditions and adjust the mapping table by using
the mapping table editor. The mapping conditions are depend on
the type of the input sources.
These are the librarians who can decide reasonable information
need to be filled into the exception records. They are the users for
the exception editor. They also can figure out the major
exception patterns and inform the mapping coordinator to
adjust the mapping conditions to reduce the exceptions.
These librarians manage the exception record database and load
the SDF files into the existing SIRSI's SCR database after
finishing all the conversion process. They will manage the SCR
database to insert a new record, delete a obsolete record, and
modify incorrect records.
The USC library has one computer programmer who can manage and
develop computer softwares for the library information
system. This person will be the major system manager of the
SCR database builder. He will manage all the server and client
site programs and detects abnormal operations of the system.
He/She can solve minor problems on the computer system or the
software system, and in case of the major software problems,
he/she can contact to the system developer to solve the problem.
All the system working environment including the servers and
the network systems are operated and managed by the UCS people.
people. They are usually experts on computer systems and
network systems.
The potential users of this SCR builder are experts on computer systems,
but they may be familiar with the existing SIRSI system.
So, this system will provide the users GUIs which look and feel like the
current SIRSI's interface. The users can easily and quickly learn
these interfaces after several trials. All the messages from the
system will be descriptive enough to be understood by the users. Also
the hypertext style help system will be included into the system.
The record mapping coordinators may have deep knowledge about the
different record formats of the serial publications. They can define
the mapping
conditions and adjust the condition depending on the quality of the
input sources. Also they will use the exception editor to convert
manually the exception records which cannot be converted by the
automatic converter. They will decide which data is most appropriate
for a certain data field of a exception record.
The system manager is proficient with computer systems
and software systems. He can detect problems on the computer or
network systems and solve minor problems or report major problems to
the UCS. Also he can manage the large scale software systems.
The SCR database builder will be used at the first step of the SCR
database construction work. After loading the SDF files into the
SIRSI's SCR database, this system may not be needed to be used again,
but this system may be used for the other record conversion works in the
future by modifying small portion of the program and mapping conditions.
Figure 5.3 Data Flow Diagram
Figure 5.3 show the overall data flows of the system. The input records
are converted into the SCR format data by the conversion batch processor.
The batch processor need the mapping table to decide the mapping conditions
for the conversion process. The mapping table can be modified by using the
mapping editor. All the records which are successfully converted
into the SCR format is stored into the SDF files. The exception records
which cannot correctly be converted into the SCR format are saved in the
exception record file which will be accessed by the exception editor. And all
the system errors generated during the batch process will be logged into
the system error log file. The user can see the error messages by using the
error browser. Through the exception record editor, all the
exception records are manually edited and added into the SDF files. The SDF
files which are the results of the conversion batch processing will be loaded
into the SIRSI's SCR database by the automatic generator which is a program
component of the SIRSI system.
Figure 5.4 State Transition Diagram
The major system states and transitions among the states are summarized in
Figure 5.4. By entering the user authentication information, the users can
log-in to the program component they want to work on. They can run the user
manager program to manager the user accounts or run the mapping editor to
adjust the mapping conditions. Also they can start the conversion batch
processor and monitor the status of the conversion process through the
status monitor. The conversion batch processing will be end after converting
all the records in the source record files. During or after the conversion
processing, the users can browse and edit the exception records. Also they can
browse all the system errors generated.
When the record conversion operator initiate the conversion batch
processor, both the conversion status monitor and the conversion engine
will start. The batch processor fetches the input file format
specification which indicates the next input source to be
converted. The records in the input source are converted into SIRSI's
SCRs by using the mapping table. All the exception records which
cannot be converted into SCRs are saved into the exception record
repository. The user can monitor the current conversion status and may
stop the process when the status shows an unacceptable low performance.
Figure 5.5 shows the sequence diagram of the record conversion operation.
The SCR editor can login to the exception record editor, edit the
exception records and store the modified record into the SCR database.
Each exception records are verified by the user, and fetched into the
exception editor, edited by the user, and stored into the database.
Figure 5.6 Sequence Diagram of Editing Exception Records
The mapping coordinator can edit the mapping table to improve the
conversion quality by using the mapping table editor. The mapping
table editor opens the mapping table as following the user's request
through the mapping interface, and modifies the fields and conditions in
the table with the new values given by the user.
The conversion batch processor also can be run in the command-line mode
other than the GUI mode. The user can log-in and execute the batch processor
in the command-line mode and monitor the conversion status through the text
mode interface.
All the operation mechanism and system status are same as the GUI
mode. The user can select the interface mode when he/she runs the
conversion batch processor by specifying an option. If the user want
to run the program through a text mode terminal, he/she can select the
text-mode interface instead of the GUI. Figure 5.9 is the
additional state diagram which shows the selection of the interface
mode before login to the system.
Figure 5.9 State Diagram of Interface Mode Selection
The purpose of this system is to automate the record conversion process for
building the SCR database which is currently done by human. So the system
should be more efficient and correct than the current human processing.
The followings are the quality attribute goals of the system in the viewpoints
of the performance, correctness, consistency, flexibility, portability and
security.
The automated record conversion should be faster than
the current manual conversion system. Currently, the manual conversion
takes about 15 minutes to convert a record.
Also there are about 15,000 records to be converted into the SCR format
records. So it will take very long time to complete the conversion
work by human. By using the automated system, the conversion work
should be able to finish in several days including the exception
editing process.
The current manual conversion may not convert all the records
correctly, because there may be some human mistakes while the
conversion process. It may be possible that the librarian
misinterprets the mapping table and puts incorrect data into the
target record fields. Also the mistyping is one of the major
mistakes which can be happened during the human conversion process.
The automated system should be able to avoid all these human mistakes
and convert all the source records into the desired format records
correctly.
To reduce the total time for the conversion process, several people may
work together. In that case, it is possible that different person
converts a same field of a record differently by applying
different possible mapping conditions.
The automatic converter should contain a well-defined rule to apply
the mapping conditions to a conversion consistently.
The mapping tables for the automated conversion process will be
built by the record mapping coordinators. They have to test
their mapping tables and check whether the conversion process works
well with the mapping tables before adapting those tables at the
real conversion. In the case of inefficient conversion, they
need to adjust their tables to reduce the number of exception records.
So, the system should be flexible enough to work with various mapping
tables and provide the way to modify the mapping tables.
The libraries have different types of machines to execute the client
programs of the system - the conversion status monitor and the
mapping editor. Those client programs should be portable enough to be
run on the different machines in the libraries. The SUN workstations,
Mac's and PC's are the machine types which will be used to run the
client programs.
The system should provide an authentication mechanism to protect
invalid operations on the system. Only the authorized users should
be able to use the system.
The library expect the system to be run on the current
computing environment in the libraries.
The current working environment of the system is based on the computer
and campus network environment which is supported by the USC UCS.
The record converter batch-processor will be run on the
library's dedicated server which is a SUN Ultra Enterprise 4000.
And the record converter client interface and the exception
editor will be run run on a Mac or a PC.
So, the developer should consider the UNIX environment for the
batch processor and TCP/IP for the communication between
client programs and the server program.
There are approximately 15,000 records to be converted into
the SCR format.
Currently, there are at least three different input sources
for constructing the SCR database. The USC Record, Orion Record, and
FAXON Record are the three major input sources for the serial
publications. To improve the quality of the record conversion,
the user may add extra input sources to the converter.
The system manager will be responsible for managing all the server and client
programs and detecting abnormal operations of the system. The system manager
should be able to solve minor problems on the computer system or the
software system, and in case of the major software problems, he/she can
contact to the system developer to solve the problem.
All the system working environments including the servers and the network
systems are operated and maintained by the UCS. They will fix all the problems
related to the computer and network systems on which the SCR builder system
works.
6.1 Mainstream Scenarios
The user can log-in to the conversion batch processor under the
command line and do the operations in the text mode. The
authentication step can be done by putting the user ID and
password as following the directions from the system. And user
can start the conversion batch processor by sending a
command and check the conversion status through the text
mode monitor interface.
7.1 Operational Impacts on the System
This system will automate the current manual conversion works and the SCR
database can be built in a shorter time and will contain more accurate
data of the serial publications.
7.2 Operational Impacts on Stakeholders
By automating the record conversion process, the large amount of time and
efforts of the librarians to convert the huge number of records can be saved.
And more accurate informations about the serial publications will be available
to the library patrons more early.
7.3 Impacts during Development
All the feed-back information from the librarians about this system will be
considered carefully to develop more efficient and usable system.
Also the frequent interaction between the developers and the library
customers will help us to detect and correct the incorrectly designed parts of
the system as soon as possible.
The SCR builder will automates record conversion works and provide
the USC libraries a fast, flexible, accurate, and user friendly software
system to build the SCR database for the serial publications.
The initial prototype is developed to demonstrate the GUIs and show
the operation mechanism of the SCR builder. The prototype can be
tested through the Web browsers by connecting to the following address.
http://nunki.usc.edu:8082/~cs577/team3/prototype/LCO/team3.html
Figure 1.2 System Use Case Diagram
4.2 Assumptions and Constraints
4.3 Rationale for New Capabilities
4.4 Changes Considered but Not Included
5.2.2 Operational Assumptions
5.3.1 Viewpoint of Record Conversion
Figure 5.5 Sequence Diagram of Record Conversion
5.3.3 Viewpoint of Editing the Mapping Table
Figure 5.8 Sequence Diagram of System Monitoring
5.4 Operational Modes
5.5 Quality Attribute Goals
5.6 Operational Policies and Constraints
5.7 Support Concepts
6.2 Variant Scenarios
6.3 Exception-Handling Scenarios
6.4 Support Scenarios
