辅导案例-5PM
CS355, Section 1, Spring 2020 Team Project – Scrum, Sprint 1 Travel Agent: Agent, Server, Display Due: Friday, April 24th at 5PM (your GitLab repos will be cloned for evaluation shortly after this date/time) Overall Project 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. Process We will use a Scrum-like process for working on this project. Scrum divides work into sprints (for us, two-week work periods), with the following structure: - Initial planning meeting - at the beginning of the sprint, including the topics of: o Discuss the project to ensure overall understanding o Generate a list of tasks (based on the project description), try to make your tasks fairly small (15 minutes to several hours) if possible A task like “make client software” is too large and broad; divide this up into “get client/server socket communication working”, “identify agent through workstation name”, “do not allow second agent from same workstation to connect to server”, etc. o Estimate the work times for each task o Prioritize your task list, with the tasks that must be done earlier and/or are more important given higher priority. No priority number should be used more than once. o Divide the sprint tasks among the team members - Regular work - each day, try to do some quality work, accomplish part or all of at least one task - Regular status meetings (the “Scrum”) - preferably each day, no less than every other day), focusing on three topics: o What have you done since the last status meeting? o What do you plan to do before the next status meeting? o What obstacles/problems/issues have you encountered in your recent work that are interfering with your progress? - Retrospective meeting – at end of each sprint, reflect on what worked in this sprint, what didn’t work well in this sprint, how to improve your process for the next sprint. See the Scrum notes on Canvas for more information on the Scrum process in general. Each team must use GitLab to store your team code. The only code I’ll evaluate (at the end of each sprint) will be what is in your GitLab repository on the UWEC server. I also want each team to use the GitKraken Glo Boards to set up tasks for your project and track task progress and completion that way. One member of each team should create a board for the Travel Agent project, add the other member and myself to the board (gurunghl), and use this board regularly. More information on Glo Boards will be posted later in the week of April 13th. Sprint Tasks The overall tasks for this sprint are to develop the server (including agent handler), agent, and display subsystems using Java sockets. Several additional requirements will be added to the overall project description, and are listed here: - The agent view and display view must be GUI-based. You are allowed to use any standard Java GUI library from the following list: AWT, Swing, SWT, JavaFX. No additional GUI (or other libraries, besides ojdbc8.jar for Oracle connectivity) may be used without instructor/client permission. - The agent view should include information identifying what it is (e.g. Travel Agent System - Agent, and should include at least three buttons as follows: o Find Trips button, with primary color of green in the button text, background fill, or outline o List Customers button, with primary color of red in the button text, background fill, or outline o Purchase Trip, after a number of tickets to purchase has been selected o A small display area for status or error messages returned by the server (e.g. if there are not enough seats available on a trip, a purchase cannot be made and a message should be printed notifying the agent of this). - The agent subsystem should only be allowed to connect to the server once for each workstation; any subsequent requests from the same workstation should be disallowed on startup. - The display should update every 3-5 seconds. - The display view should include: o General Text identifying the application (e.g. Travel Agent Display) the room (Phillips 115 Lab) the current time o For each agent, two columns should be used (and labeled) Agent name (start at 1, go down as far as needed) The workstation name making the request (in P115, this is in the form LAB-P115-xy, where xy is currently a number between 01 and 24, but we want to support 100 machines (that is, numbers between 01 and 99) o For each trip, four columns should be used (and labeled) Trip name Trip destinations Maximum trip capacity Current available seats o The five lowest and five highest availability trips should be shown Highest availability should be labeled ‘Recommended’ Lowest availability should be labeled ‘Almost Gone’ o The general style of the display (including colors, font choices, font sizes) is up to each team, though generally should be readable and professional (do not choose extreme colors or nonstandard fonts). o Since we can’t easily control the display, the display window does not have to be scrollable, but should show at least the top 5 recommended and ‘avoided’ trips. - Currently, if you stop one of the agent, server, or display subsystem programs, you may cause an unhandled exception in one or several of the other subsystems, sometimes with this exception happening within a loop. For the travel agent system, all exceptions should be handled so that: o Stopping a single agent, many agents, or all agents does not cause an unhandled exception in the server or display o Stopping the display should not cause an unhandled exception in the server or any agent o Stopping the server should not cause an unhandled exception in the display or any agent; for now any result (display and agents stopping, display and agents still running but given that connection is lost they don’t do anything) is allowed, and we’ll work on this more in sprint 2. You may use the chat client/server code posted as a starting point or you may develop your own code from scratch if you would like to do so (though this is not recommended unless you are very comfortable with Java sockets.) • The chat server system is quite similar in architecture to a possible solution to our travel agent project – the server is already generating client-helper instances to work with each agent, and has a structure set up to track all agents through that client’s helper. • To allow the display system to also communicate with the server, you will need to adjust the chat client/server code to “share” cycles with agent connections and the display update, as noted in the overall Project Description. You may not change the structure of the Travel Agent system to use other architectures, such as a web server and web client system. Please contact the instructor if you have any questions on this.