Assignment: Mass Transit Simulation - Design & Maintenance (v1)
Scenario: Your requirement for this assignment involves updating Unified Modeling Language (UML) based diagrams that accurately reflect the structure and behavior of the provided Mass Transit Simulation (MTS) system. Continuing from the earlier assignments, you must describe how you would modify the current design of the MTS application to account for the new requirements and other circumstances described below. You must provide a before and after version of the Class Diagram to highlight the structural changes that you are proposing to address these requirements. Also, you must select reasonable UML-based Behavioral Diagrams to describe the dynamic and functional aspects of your proposals. Finally, you must also supply short text descriptions to help clarify the intent, motivation and supporting details of your proposals.
Deliverables: For this assignment, you must review the different requirements described below, provide proposals for how you would address these requirements, along with UML Diagrams that accurately reflect how you would implement your proposals. You must submit the following items:
(1) "Before Version" of the Class Diagram - Your diagram must include all of the classes, attributes and methods as included in the MTS application, with a few exceptions as listed here. To make your class diagram more readable, you may omit very basic "setters and getters" [e.g. set_() and get_() based operations and methods], especially those of the one-line variety that only access and/or modify an object's basic attribute. You are welcome to leverage the Class Diagram that you developed for the previous assignment as a start, but please note that the MTS application has been updated (described below). Your "before version" Class Diagram must reflect these updates.
(2) "After Version" of the Class Diagram - This version of the Class Diagram must reflect the classes, attributes and methods in the MTS application based on your design proposals. If possible, it would be very helpful if you highlight the differences between your "after" and "before" versions of the diagram graphically; however, this is not required, especially if it causes significant difficulties with your UML drawing tool. In all cases, you must be clear in describing the differences between the two versions in your supporting text.
(3) Behavioral Diagrams - You must provide UML behavioral diagrams that reflect the new functionality that you have described as part of your design proposals. You are welcome to use Sequence Diagrams, but you are also permitted to use/substitute Collaboration Diagrams or State Chart Diagrams if you feel that these formats allow you to better describe the functionality that you've proposed. As mentioned in the previous assignment, you are encouraged to use as few diagrams as possible to capture your ideas. However, if you can't fit everything into one diagram, then please use multiple diagrams as required to ensure that the results are readable.
Submission Requirements
- You must generate your diagrams using an automated tool (e.g. Argo UML, LucidCharts, Microsoft Visio, etc.) so that they are as clear & legible as possible. Even PowerPoint is allowed, though this is an excellent opportunity to use a tool that is more appropriately designed for UML as opposed to a general drawing tool like PowerPoint. The choice of tool(s) is yours; however, you should do a "sanity check" to make sure that your final diagrams are readable when exported to PDF; or, if necessary, some reasonable graphical format (PNG, JPG or GIF).
- "Automated tools" don't mean tools that will automatically generate all of the diagrams for you
based directly on the given source code. The goal is for you to read the source code, work with the compiled and executable program, and generate the UML diagrams yourself to improve your understanding of the correspondence between the system and the UML diagrams that describe it in detail.
- Your design proposals will be evaluated based on a combination of factors, including:
o The accuracy of your classes, along with the corresponding attributes and operations;
o The correctness of the format of your design artifacts with respect to the UML Standards;
o The clarity, conciseness and consistency of the text describing your proposals;
o How thoroughly your proposals address the client's concerns; and,
o *The "general technical feasibility" of your proposals.
- You are not required to provide a working implementation of your proposals for this assignment. However, you must clearly describe the data that will be needed to support your proposals, and how and where that data will be stored and organized with respect to the various classes and other structures. Also, you should describe operations in enough detail to ensure that they can be reasonably implemented.
- *With regards to the "general technical feasibility" comment: since you aren't actually developing a working prototype for this assignment, we aren't going to penalize you for incredibly specific technical issues. However, you also don't get to "wish away" or completely ignore the technical ramifications of your proposals. The design proposals that you submit for this assignment might very well become the designs that you are required to implement in later assignments, to you should ensure that your proposals are technically sound.
- You must designate which version of UML you will be using - either 1.4 (the latest ISO-accepted version) or 2.0 (the latest OMG-accepted version). There are significant differences between the versions, so your diagram must be consistent with the standard you've designated. Either version is acceptable at this point in the course. We might require a specific version for some of the other UML style components later in the course, especially considering the behavioral/activity-based diagrams; and, if so, we'll let you know.
- You are permitted to add a few sentences to explain any aspects of your design that you feel need extra clarification. These sentences are optional: non-submissions will not be penalized.
New Client Requests - The Areas of Focus for Your Design Proposals
The MTS System has been updated, and you should take some time to explore and analyze the new and improved capabilities of the application. However, even with the new capabilities, there's still much work to be done to satisfy the client's requests. First, we will describe the client's requests, which will be the focus of your efforts for this assignment. Your main goal will be to describe how you would modify the MTS application to address the client's requests, and then provide design artifacts that clearly, consistently and comprehensively capture the details of your proposed modifications.
After we describe the client's requests, we will give an overview on the updated MTS system. The client's requests are reflected in four basic categories: Riders, Roads, Rails and Random.
Riders: Currently, the system models riders with very simple models. When a bus arrives at a stop, calculations are performed to determine some random number of riders who will get off of the bus, and a possibly different random number of riders who will then get on. The random numbers are generated using default distribution values, or inferred from some of the GT SLS MARTA data. Also, the bus capacity is used to determine if some riders will have to wait at the stop for the next bus.
However, the clients have some concerns:
In real life, an individual rider normally goes to a stop with the intent of catching a specific bus that he/she knows will take them to a desired stop. It's rare that all of the riders at a stop will always get on the next bus without considering that bus' particular route. How would you modify the MTS application to handle riders in a way that is more accurate with respect to real-life behaviors?
Also, how will your proposed system handle the scaling up to tens of thousands of riders, as commonly encountered by MARTA on a daily basis?
Roads: Currently, the system models travel between stops using a very simple technique. The locations of the two stops are interpreted using their latitude and longitude coordinates, and the distance between the stops is approximated using a simple Euclidean distance formula. This distance value is then converted to statute miles using a simple conversion factor, and the speed of the bus is used to calculate the approximate time needed for the bus to move to the next location. Finally, the bus speed is normally entered in miles per hour, so a conversion factor is used to convert the travel time from hours to minutes, and the number of minutes is used to generate a new event that will be processed when the bus arrives at it's next station.
However, the clients have some concerns:
Most roads between stops are not perfectly straight. Some are curved, and that distance can affect the travel time. Also, some roads are in residential areas where the maximum allowable speeds are lower, while some paths between stops are highways that allow buses to travel at significantly higher speeds than normal. Finally, roads are not always clear - other cars, trucks and vehicles can occasionally cause traffic conditions that can also affect travel times. How would you modify the MTS application to handle travel between stops/locations in a way that is more accurate with respect to these real-life conditions?
Rails: Currently, the system models transit as buses traveling along designated routes, and transporting passengers between stops along that route. Buses are an incredibly important part of the MARTA system. They transport thousands of riders between hundreds of stops spread across the Metropolitan Atlanta geographical area on a daily basis.
However, the clients have some concerns:
Buses aren't the only component of the transit system: there is also a rail system that connects various locations in the Atlanta area. The rail system consists primarily of two lines (routes) oriented along a Northbound - Southbound axis, and an Eastbound - Westbound axis, with a few "branch routes" near the ends of certain lines. There aren't as many trains traveling on the rails as buses traveling the roads, but the trains do have some advantages like avoiding traffic. How would you modify the MTS application to account for the existence and effect of the rail service?
Random: Well, not actually random - more like "developer's choice." This is your opportunity to suggest a modification to the current MTS system that will improve the effectiveness and/or usefulness of the application for the clients. The client's intent is to use the application to help model the real-world MARTA system as accurately as reasonably possible, so that they can use it to help predict the effect of making changes. The goal is to MARTA as effective and efficient as possible in allowing users to get from their current location to their desired destination as rapidly and consistently as possible. The kinds of changes that they are interested in are varied: the frequencies, speed and capacities of buses and trains; the locations of stops and rail stations; and, the impacts of different traffic loads on the system's effectiveness, among other possible changes.
You must propose a modification, and describe how you would implement the modification in text and using the UML diagrams, similar to the other categories above. However, for this category, you must also provide a few sentences that clearly capture how this modification will benefit the users from an operational/business perspective. Also, please be specific with your proposal - indeed, you should be specific with all of your proposals, but especially with this one. For example, the proposal "Add a User Interface" is, by itself, much too vague; however, you could offer much more specific proposals focused around the user interface that would be acceptable. Remember that you must describe your proposals clearly and precisely in terms of the UML design artifacts that you submit. Other potential areas include improved support for data management and/or analysis of the results.
MTS System Description - Updates
The Mass Transit Simulation System simulates the process of using buses traveling along different routes to transport riders to different stops. The description below gives a brief, high-level overview of how the system provides these capabilities, but a large part (and intent) of this assignment also involves you taking the time to study the system more closely to better understand how it is constructed and how it operates. The changes that have been made since the previous assignment will be highlighted below (*new). This is the core of the system that will also be used for the group based Implementation assignment to come.
- When the system is started, the user is provided with a command line prompt (labeled as #main) to enter MTS commands. The SimDriver class provides the interactive command loop that accepts and processes the MTS commands.
- The user can enter commands manually one at a time, or create a file to facilitate easier testing of a specific sequence or "script" of commands.
- There are a number of different MTS commands that are currently organized into three basic categories: Creational, Operational, and Reporting.
- *new The Creational category includes commands such as add_stop, add_route, add_bus, add_event, and upload_real_data. These commands are used to create the objects in the simulation environment. The extend_route command is used to modify the route that bus takes to travel a sequence of stops.
- The add_stop, add_route, add_bus and add_event commands create those objects in the simulation domain. Each command accepts the proper attribute values in the order given in the corresponding JAVA file class listing. The BusSystem class holds the collections of objects that have been created to form the simulation environment.
- *new The upload_real_data command creates objects based on the data collected from the GT SLS MARTA data set. Portions of the data set have been loaded into a PostgreSQL database, and this command extracts that data using a combination of tables and views to create objects in the simulation environment.
- Stops are defined by the BusStop class, and represent the places where riders arrive to catch a bus to a different location. Each stop has a unique ID (currently generated by the simulation system), along with a "user facing" and more descriptive Name attribute. A stop also contains a Riders attribute, which records the number of people waiting at the stop to board an available bus. Each stop also contains X- and Y-Coordinate attributes that translate to its geographical location on the travel map. The coordinate attributes are used to calculate the distance between stops, which is then used along with the Speed attribute of a bus to determine when the bus will arrive at its next stop.
- Routes are defined by the BusRoute class, and represent the path along which the buses travel. Each route has a unique system-generated ID, along with more descriptive Name and Number attributes. Most importantly, each route contains an attribute that lists the stops covered by that route. The order of the list is important: normally, a bus begins at the stop listed in the first position of the list, and then progresses to each stop as ordered in the given route list. If the bus is located at the last stop on the list, it then goes back to the first stop in the list, and continues the cycle as long as required for the duration of the simulation session. Please note that a route might have the same stop listed twice, which is not necessarily an error. In these cases, the bus is likely traveling along a fixed path in alternating directions - for example, first Northbound, then Southbound, etc.
- Buses are defined by the Bus class, and are used to transport passengers from a simulation perspective. Each bus has a unique system-generated ID, and travels along a certain Route. To facilitate movement along the route, the bus Route Location attribute refers to an item in the route's list of stops, rather than having the bus refer directly to the stop itself. Also, each bus has a Capacity attribute which limits the total number of passengers that it can carry at any one time, along with a Speed attribute that affects how quickly the bus travels along the route.
- The Operational category includes commands such as step_once and step_multi. When used, these commands cause the simulation system to select the next event from the priority queue, and then process this event according to specific rules based on the type of event. The step_once command executes one event and then returns control to the user, while the step_multi command allows the user to execute several events in a row for convenience.
- *new The step_multi command has three new additional (and optional) parameters to help manage interaction with the event-processing loop. The second parameter still controls the number of iterations as mentioned above. The third parameter causes the system to display a count of how many events have been processed so far during the loop. The fourth parameter causes a delay of a given number of seconds after each event is processed to aid readability. The fifth parameter causes the graphical display output to be updated during the given loop with a certain frequency. As an example, the command step_multi,2000,50,2,10 will cause the system to process the next 2000 events. During the loop, a message of " events processed so far" will be displayed every 50 events. The system will pause for 2 second after processing each event. Finally, the graphical display output will be updated after every 10 events.
- This system uses very basic discrete-event simulation techniques to drive its operations. The SimQueue class provides a priority queue to manage system events. The events are sorted in the queue using the functionality provided in the SimEventComparator class. In principle, the rank attribute of an event represents the logical time at which it will be executed, and the events are sorted based on the rank attribute. One of the events having the lowest rank in the queue will always be selected as the next event to be processed.
- Events are defined by the SimEvents class, and represent the different types of actions that we will track in our simulation. Each event has a Rank attribute, which corresponds to the logical time that events will happen during the simulation, and is used to organize items in the simulation queue. Each event also has a Type attribute, and an ID attribute which is used to designate which simulation object in the system - bus, stop or route - should be used to execute the associated event actions.
- There two types of events at this point: the move_bus event, and the riders_arrive event. The move_bus event corresponds to the actions of a bus beginning its turn by allowing passengers to get on and off at its current stop, and then moving to the next stop on its route. The riders_arrive event corresponds to the actions of passengers who arrive at a departure stops at a certain time during the simulation with the intent to catch a bus to a different destination stop when possible.
- For the move_bus event, we begin by envisioning the bus at its current stop. Currently, we generate random values to represent the number of riders who wish to get on and off the bus, respectively. We check certain limits to ensure that the numbers are reasonable: for example, we ensure that the number of riders getting on the bus is limited to the number of riders currently at the stop, and we also check that the number of riders who would like to board the bus don't exceed the capacity of the bus. We then update the number of passengers riding the bus, along with the number of riders still waiting at the stop.
- The final step of the move_bus event is to calculate the distance to the next stop on the route,
and use the speed of the bus to calculate the time needed to travel to that location. This travel time is used to generate the rank for a new event, and enter that event into the simulation queue.
- *new To improve the "synchronization" of events during the simulation, the distance and speed calculations are adjusted with conversion factors so that the rank of an event corresponds to when the event would be executed in minutes from the start of the simulation run. For example, if the event being processed refers to a bus (ID# 12) moving between at rank (time) 501, and it will take the bus 6 minutes to travel to the next stop, then a new event will be created for the next event for bus #17 with rank 507.
- *new For the riders_arrive event, the simpler functionality provided by the BusRiderGenerator class has been replaced. The bounded random values that were provided earlier are now based (in some cases) on analysis of the MARTA data set. Riders are no longer generated in advance to wait at a stop, but instead are generated only when a bus arrives at its next stop. Riders will only be found waiting at a stop when they were unable to catch the original bus due to a capacity limitation. This also makes scheduling riders_arrive events unnecessary, and so they have been removed from the event-processing cycle for now.
- *new The Reporting category includes the system_report and the display_model commands. The system_report command is used to display the current state of various simulation objects, including the buses, stops and routes. This command will be useful when generating your Object Diagram. The display_model command produces a DOT file, which is basically a plain text file that describes a graph in the dot "nodes and links" format. This file can then be rendered using the XDot application to display the current status of the buses, including their passenger counts and their current locations between stops. The output also lists the number of passenger waiting at different stops.
- *new A bus also tracks its previous location as well, to help produce the graphical display output.
- Quick note: "riders" and "passengers" are both people moving through our simulated transportation system, and there isn't intended to be any significant distinction between the two. The system currently uses the term "passengers" for people currently on a bus, as opposed to "riders" who are waiting at a stop.
Simulation System Commands
This is a quick guide to all of the MTS commands. *new One significant change: the system no longer generates the IDs for simulation objects automatically, but rather the user is expected to generate and submit unique (per category/object type) IDs for each object. This makes it easier to construct test files in many cases, since it offers better control over the relationships between the objects, and is less affected by variations in ordering the creation of objects.
*new Also, there is a different command that should be used to execute the system:
java -cp "./mass_transit.jar:./postgresql-42.2.1.jar" edu.gatech.Main
You can also use redirection to feed in some of the test files (e.g. < simple_test.txt)
- add_stop, , , , ,
This command creates a stop object with a give , and an initial number of , located on the travel map at the location , .
- add_route, , ,
This command creates a route object with a given and . The route initially doesn't have any stops.
- extend_route, ,
This command appends the stop designated by to the end of the route designated by
. The ID values are the ones generated by the simulation system, not the "user facing" numbers and names entered with the commands.
- add_bus, , , , , , This command creates a bus object that travels along , starting at with an initial number of . Also, the bus can hold at most passengers, and
travels along the route at the given .
- add_event, , ,
This command creates an event object that will be executed when the simulation reaches "logical time" . When executed, the system will perform the actions corresponding to the event
using the object designated by .
- *new upload_real_data
This command creates stop, route, bus and event objects based on data extracted from the GT SLS MARTA data set.
- step_once
This command executes one event from the simulation queue.
- *new step_multi, , opt: [, , ] This command executes events from the simulation queue. Every events a message is displayed that shows the number of events processed so far. The system pauses for
approximately seconds after processing each event. And the system updates the graphical display output after every events are processed.
- system_report
This command displays the attribute values of the simulation objects.
- *new display_model
This command produces an output file (named mts_digraph.dot) that reflects the current locations of the buses (and number of passengers), and the status of stops (and numbers waiting to catch a bus). The file is formatted in the DOT format, which is a plain text listing of information about the nodes and edges in the graph. The XDot application can be used to render the graph.
- quit
This command stops the simulation.
Closing Comments & Suggestions: This is the information that has been provided by the customer so far. We (the OMSCS 6310 Team) will likely conduct an Office Hours where you will be permitted to ask us questions in order to clarify the client's intent, etc. We will answer some of the questions, but we will not necessarily answer all of them. Also, though this current version of the system if "the core" of the system going forward, our clients will very likely add, update, and possibly remove some of the requirements over the span of the course. One of your main tasks will be to ensure that your architectural documents and related artifacts remain consistent with the problem requirements - and with your system implementations - over time.
Attachment:- VM for the assignment.rar