This is an old version of this course, from Winter 2014-2015. A newer version is avaliable here.
Objectives
- Use the Observer pattern to facilitate teamwork
- Use the Observer pattern to reduce coupling
Overview
In this lab, you will create a GUI application that observes the location and velocity of Milwaukee County Transit System busses, using the Observer pattern to facilitate teamwork and program design. You can get a feel for the information available by look at the MCTS real-time online bus map
Do not hit the MCTS web-page more than once a second! In general, once or twice a minute should be all your application needs.
User Requirements
Through the graphical user interface, a user can at any time select a bus on the Green line (Designator GRE, running from downtown to the airport). Once selected, the program displays information about the bus based on its position north and east of the center of Milwaukee in miles. The user can select multiple views of a bus. One view of the bus displays, as text, the bus's position and velocity, another graphically draws the bus on a map. Each display will update as new information about the bus becomes available.
In the textual display, the position is displayed as the number of miles east and north of Milwaukee City Hall (located at 43.04173o north, -87.90976o east). (As mentioned above, the textual display also displays the velocity or speed of the bus.) In the graphical display, the position is displayed as a dot (or icon) on a map. The map may not have any physical features such as roads displayed, but it has lines marking each mile north/south and east/west of city hall. Each bus may be displayed on its own map, or all busses may be displayed on a single map.
Implementation requirements
The program uses the Observer pattern, including an abstract subject and observer, a concrete subject, and at least two concrete observers. The abstract subject and observer are designed to facilitate the development of new observers similar to those already required by the user.
Documentation Requirements
General requirements
Every uploaded file and every sheet of paper should include all team members' names and the date at the top of the file. Java source code should include these in a block comment at the top of the file, distinct from the class comment (which documents the specific author of the class). UML diagrams created with EA should include these in a diagram note. UML diagrams created with EA should not have a blue gradient background, but instead be exported with EA's export function (or EA's copy-paste into paint, if you prefer)
Preliminary Design
The preliminary design includes a UML hand-sketch of the classes to be written. It includes two sequence diagram that at a high level illustrate: (1) the user starting to track a new bus, (2) one update of a bus's display. Only the principle method calls are included on these sequence diagrams; use your judgement about what calls matter and which ones don't. It also includes a written description of how all user and implementation requirements are met.
The preliminary design also includes a complete working implementation of the abstract subject and observer.
Final Design
The final design includes a UML diagram that describes every class in the final program, created with enterprise architect. Every class in the diagram is connected to at least one other class, and pattern stereotypes are included on all classes. The final design also includes an updated written description of how you met the requirements. If you go beyond the requirements (necessary for an A), please describe how you did this at the end of this description.
The final design does not need to include a sequence diagram.
Code delivery
All code is placed in the <username>_<username> package, where the <username>s are replaced by the MSOE usernames of the members on your team. For example, on Phileas Fogg and Jean Passepartout's team, the package would be foggp_passepartout. The main program should be directly in this package. You may put other classes in subpackages if it helps your design.
Each class should have the original owner indicated with an @author comment in the javadoc code. Write the interfaces together at the start (@author the team for these).
Tools and Information
Webpage Fetching Classes
Do not hit the MCTS web-page more than once a second! In general, once or twice a minute should be all your application needs
Classes will be provided to fetch the location of busses from the MCTS realtime webset, providing the bus id, latitude, longitude, and time as text strings. You will need to create an account with the MCTS real-time system and request a developer's key.
The fetching system represents the raw information about each bus using the VehicleText.java class.
The fetching system (RealtimeWrapper, in the buswrapper package) is now available. And a useful Stackoverflow link to get you started.
For your internal representation of time, you may find the toEpochSecond method of the LocalDateTime object useful.
In Milwaukee, a degree of latitude (degrees north) is 69.03 miles, and a degree of longitude (degrees east) is 50.63 miles. (The degrees of longitude get closer together as you approach the north pole.) These were found with a CSG Network online calculator. If you are not sure how to use these numbers, please contact me.
Map Drawing Suggestions
Suggestions will be provided about how to draw lines and display a moving dot in Swing.
You might want to use the WinPlotter from SE1021 Lab3 for drawing the bus's location. You can use clear() to clear the plotter between draws, if you like.
Threading Suggestions
To specify from another thread that code should be run on the event dispatch thread, you can use SwingUtilities.invokeLater(...).
You could probably write a similar mechanism if you wanted to transfer control from the GUI to a continuously-running worker thread. Or, you could just spawn a short-lived thread...
Acknowledgement
This lab is inspired by and draws code from a Weather Observer Lab developed by Dr. Urbain.