CS355 Section 1, Spring 2020, Heidi Gurung
Overall Project Description
Travel Agent System
Overall
The team project for this semester will be a travel agent system. Imagine you own a company
that arranges vacation packages. You hire travel agents to take calls and book trips for clients.
The travel agents have an interface to do their work. Imagine the agents work in a room like
P115. You may recall there are video screens on the walls in P115. These video screens are a
good place to show a display of agents currently working, recommended trips, and low
availability trips. Finally, there is a supervisor, or administrator, responsible for starting the call
center each morning.
More information on the behavior and structure of the project is provided below.
Scope
The scope of this project may change as it proceeds, just as requirements change on projects in
the real world. However, we also know it is helpful to have a general idea of the scope of our
work so we can plan and design to minimize changes later.
The following is an overall view of the assignment:
Travel Agent System Description
• The Travel Agent system will have four separate programs:
o A server program, to manage all agent requests, coordinate interactions
between programs, and to manage the storage of data to an Oracle database.
Note that the server will generate a separate AgentHandler class instance to do
the actual communication with each Agent – just as in Assignment 1. We do not
want to overburden the server.
 The server program is run once – on some server machine outside P115
(the agents’ workspace)
o An agent program to book holidays for clients. Holidays are trips with set start
and end dates, fixed destinations, and cost. Via the travel agent, clients can
select which trip they want to take and say how many people are in their party.
If there are enough seats available on the trip, the agent calculates the total
price for the trip and clients either pay in full or place a deposit of 10% the total
trip price. If there are too many people in the party for the capacity of the trip,
the agent will tell their client that they cannot book the trip.
o A display program, with a GUI that displays which agents are currently connected
to the system and a list of the five lowest and five highest availability trips.
(Agents can promote the five highest availability to their clients, while the five
lowest availability should be avoided.)
 This display application will be run either once (for testing) or twice (in an
actual work situation).
o An administrator program which can start or stop the travel agent server,
initialize or re-initialize the agent list, start the display application on a remote
system, and disconnect any agent.
• There will also be a Data Access Object (DAO) class for database work, connected to the
server program on one end and to the Oracle database on the other end. All calls to the
DAO will be done directly in the server code, and so the database work will not require a
separate program.
o Additionally, no other program may call the database or DAO directly
• There will be deployment environment requirements for this system, including, but not
limited to, the following:
o The system programs must be written in Java
o The system programs must be able to run as a command line program (i.e. an
executable JAR file), and cannot use any additional environments (i.e. you cannot
use and assume the presence of a web server)
• The Travel Agent system’s architecture is very similar to what you did for the model of
the client-server chat system in Assignment 1. Review the given solution model for
Assignment 1 to be sure you understand this structure.
o Architecture Summary
 The server program sits in the middle and each of the other main
programs (agent, database, administrator, and display) talk to the server.
 The server will have a loop that essentially gives each type of program a
chance to communicate with it and do work for it, then the server moves
on to the next program. You can think of this in pseudocode as follows:
• Server Algorithm
o Initialize
o While true (or, later, while admin does not
choose to exit)
 Wait a limited time for a agent
request, respond if request occurs
 Wait a limited time for an
administrator request, respond if
request occurs
 Update the display

Client-Server Chat System -
• I have posted Java code for a basic client-server chat system in Canvas under the Project
– Introduction section. You should download this code and review the structure to
understand the system. There are two programs here – a server program and a client
program.
o To run the chat system, do the following:
 Start the server program
 Start an instance of the client program
 Start a second instance of the client program (NOTE: if you have not done
this before, you can run multiple instances of the same program in IntelliJ
or Eclipse) to simulate having two different people connect to the system
 Then you can send messages between the clients by moving between the
console windows for each client and using the correct command format
 The chat system protocol is:
• message # recipient
• For example, if you have two clients named ‘client 0’ and ‘client
1’, a message from client 0 to client 1 could be:
o Hello there! #client 1
o Notice there is no space between the # and word ‘client’
• The chat client-server system uses sockets to communicate between the client and the
server. Some students have worked with sockets in C in CS252, while others may have
seen them in Java in CS145. It may take some time and effort to understand Java
sockets. With most projects there are new language features and tools to learn. For
you to understand sockets better, especially in Java, review the sample code in the chat
system JAR provided and look at the Socket and ServerSocket classes in the Java API
docs.
o Each channel of socket communication uses a port (a virtual address or
communication endpoint within an operating system). For example, Oracle
generally uses port 1521 for communication between a client (e.g. SQL
Developer) and a server (the Oracle DBMS).
o You will be given three port numbers to use and will use them as follows. Say
that your group is assigned ports 3095 through 3097.
 Agent <-> Server communication – first port (the lowest numbered port
in your set, here 3095)
 Display <-> Server communication – second port (the middle numbered
port, here 3096)
 Administrator <-> Server communication – third port (the highest
numbered port, here 3097)
• The chat client-server system also uses separate threads for parts of the system. I
suggest you maintain this usage here for the travel agent system as well. Again, if you
have never worked with threads, look at the example code and do an online search for
Java Threads to learn more. You do not have to understand a lot about threads to make
them work for you in this system.
Project Tools
• This project is not just about results, but also about your process. You will work in pairs
(originally planned for four-person teams, but this is reduced to two per team given our
physical separation.) Also, we will use several tools:
o GitLab – Source code control is one of the most important concepts in today’s
software development environment. Each team will have a repository for their
code on our local GitLab server (developer.cs.uwec.edu). This UWEC repository
must be used. I will grade the code that is in your UWEC GitLab repository – not
a separate submission or code in another location. Therefore, you need to use
UWEC GitLab.
 Submit all code and artifacts to GitLab. I expect to see submissions,
including incomplete code and diagrams, throughout each sprint. This is
part of Agile Development, working in teams, and incremental
development. Regularly submit work to your personal branch, even if it
is incomplete. Wait to have working/tested functionality before merging
with the main branch.
o GitKraken – a Git client that allows submissions to the GitLab server and also
supports other functionality, such as issue tracking and task completion (through
Glo Boards).
o JUnit – for some unit testing, though we will not unit test all classes.
o Manual system testing – to make sure our system works as needed by the client
(our customer).
o Possibly other tools as needed and specified…

General Schedule
• To help you plan for the future, the general (to be more completely specified) deadlines
for your work will be:
o Test cases – due Friday, April 17th
o Sprint 1 (first two weeks, due Friday, April 24th) – Agent, Server, and Display
o Sprint 2 (second two weeks, due Friday, May 8th) – Database and Administrator
o Sprint 3 (last week, due Friday, May 15th) – Customizations and Additions – at
least some of your choice
o Final report and documentation – due Friday, May 15th
• There will also be several auxiliary assignments as part of the main work
o As noted above, after one week (due Friday, April 17th) each team will be asked
to submit a test case list for the entire system, including all four programs. I will
then generate a comprehensive test list from all of your submissions and my
own ideas. We want to think ‘test first’ here, though you do not have to follow
test-driven development unless you want to do so.
o I will also ask each of you to anonymously evaluate your team partner
• More specific information will be provided with specific assignments posted to Canvas