UML代写：CS6310 Star Search Simulation System

设计一套模拟系统，模拟使用小型无人机探索太空的偏远地区。

Submission

• This assignment must be completed as an individual, not as part of a group.
• You must submit:
  • (1) A UML Class Model Diagram named class_diagram.pdf;
  • (2) A UML Sequence Diagram named sequence_diagram.pdf;
  • (3) Answers to the provided Design Questions as question_answers.pdf.
• You may divide your UML Class Model Diagram into multiple diagrams/files if needed. For example, if the initial diagram is so large that dividing it into multiples makes it significantly easier to read, then you may submit multiple files with reasonable name extensions such as class_model_1.pdf, class_model_2.pdf, etc. You must provide enough context for the multiple diagrams to allow us to connect them together to understand the singular/completed diagram.
• Formats other than PDF must be pre-approved an Instructor or TA.
• You must notify the Instructors and TAs via a private post on Piazza BEFORE the Due Date if you are encountering difficulty submitting your project. Send the message to “Instructors” when posting your message in Piazza, as opposed to addressing a message to just one individual, to ensure that it is acknowledged as quickly as possible.
• You will not be penalized for situations where Canvas is encountering significant technical problems. However, you must alert us before the Due Date - not well after the fact. You are responsible for submitting your answers on time in all other cases.
• Please consider that uploading files to Canvas might occasionally take a long time, even in the case of seemingly “relatively small” submissions. Plan accordingly, as submissions outside of the Canvas Availability Date will most likely not be accepted. You are permitted to do unlimited submissions, thus we recommend you save, upload and submit often. You should use the same file naming standards for the (optional) “interim submissions” that you do for the final submission.

Problem Scenario

You have been selected to assist in the development of the Star Search Simulation System for space exploration. The main concept is that the simulation will focus on using small drones - semi- autonomous spacecraft - to explore remote areas of space. The drones are semi-autonomous in that they can occasionally receive commands directly from their human controllers; however, there are also times when communicating with the drones is not possible, so the drones must be able to continue their exploration activities using only their own internal capabilities. The simulation system that you develop must:

• Be able to read in a file that will describe the specific scenario, including the characteristics of the region of space that will be explored, the capabilities of the drones that will be exploring that region and other details about the simulation run; and,
• Allow the users to test a variety of drone capabilities and strategies.
  Your design artifacts must include enough detail to show how the actions of the drones will change the state of the simulation after each action, and how your system maintains the complete state of the simulation run accurately at all times.

Project Timeline

This is the first phase of the Star Search Project. Your goal for this phase of the project is to review the provided problem description, and to identify the entities, attributes, operations, methods and relationships that are key to the successful design and development of the system. You’ll review the system requirements and specifications, analyze the given system, and then provide design artifacts (e.g., UML structural and dynamic diagrams) and other responses that represent your proposed design and how it addresses the problem’s challenges. This is similar to the Object Oriented Analysis discussed in Udacity videos P2L1 - P2L3, and demonstrated in P2L5.

In the second phase of the Star Search Project, you’ll be asked to provide peer reviews for some of your fellow classmates. You’ll be granted access to some of their submissions and design artifacts from the first phase of the project, and your goal will be to provide feedback on their designs. We will provide more specific guidance on the types and levels of feedback that are expected later, but the intention is that reviewing other designs - especially those of your peers - can help you make you more aware of alternative design approaches. The actual grade for each student’s “first phase” submission will be determined solely by a TA’s evaluation of your design - not your feedback - so please be candid and professional when providing your review. Your grade for this second phase of the project will be based on the accuracy and quality of feedback that you provide to your peers.

In the third phase of the Star Search Project, you’ll be asked to implement these requirements. It’s often the case that implementing a system can help you identify aspects of the problem description that are unclear, ambiguous or possibly even contradictory. It can also assist you in identifying aspects of your design that are faulty and/or incomplete. Your goal will be to develop, build and test the core of the simulation system to help you further think through (and possibly improve) the quality of your design. We will evaluate the correctness of your system from a source code quality and design standpoint, and by how well your system actually passes the test cases.

The first three phases of the project are all performed individually. In the fourth and final phase of the Star Search Project, you’ll work in teams to achieve two major goals: (A) Select three distinct improvements to the system, each of which will require some significant change to the current architecture and/or design; and, (B) Implement your changes, and then provide design artifacts that document your design changes.

You’ll work together as a group of three, four or five designers to determine a single unified design using some of the techniques mentioned in Udacity videos P2L4, P3L5, and others. Then, you’ll work together to build on the “common” core simulation system that you provided (individually) in phase three. You will also provide a video demonstration of how your system addresses the requirements, along with a description of how your final “as-is” system and design artifacts compare to the “to-be” artifacts that you developed in phase one.

Finally, you might also have to account for some relatively minor changes in the requirements from the earlier phases. Changes occur often in many projects, and this is an opportunity to consider strength of your original designs based on the amount of effort needed to update your most recent designs to accommodate the changed requirements.

Deliverables

For this assignment, you must analyze the Star Search Simulation System description that has been provided, and then submit the following deliverables that accurately reflect the system. You must submit the following items:

• (1) Design Class Diagram - You must provide a Design Class Diagram (as a file named class_diagram.pdf) that includes (at a minimum) classes, attributes with basic types, public and private designations, methods and operations, relationships with visibility notation, and proper cardinalities that accurately reflect the problem space. 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 provide simple and direct read or write access for an object attribute.
• (2) Sequence Diagram - You must provide a Sequence Diagram (as a file named sequence_diagram.pdf) that represents the simulation system-wide actions needed for “the next” drone spaceship to determine and execute one action. You should use the symbols for selection (e.g. alt or if/then) and iteration (e.g. loops) in your diagram where appropriate. For your sequence diagram, you should include at least two drone spaceship objects if you need to demonstrate communication between your drones, etc. You need to include enough objects to demonstrate how you handle the situations in the questions below, but not so many that your diagram becomes unwieldy.
  The emphasis of the Sequence Diagram is on the communication between objects, so you should ensure that the messages between the objects are consistent with your Design Class Diagram methods. You don’t have to provide incredibly detailed insight about functions, procedures and other operations and calculations that are completely internal to a specific object in your Sequence Diagram. On the other hand, most reasonably well-designed solutions will have the data needed to manage the simulation spread across various objects, and so the objects will need to interact in order to complete the simulation effectively. Diagrams that demonstrate little or no communication between objects are often indications of ineffective (e.g. monolithic) design.
• (3) Question Answers - The following is a set of questions designed to help ensure that your design meets the level of detail we are looking for in this assignment. Provide a relatively short (3-8 sentences) answer for each that explains which components of your design artifacts address the issues discussed in the question.
  • How do you track the current direction and location of each drone spaceship?
  • How do you track the how much of the space region has been explored so far?
  • How do you discover and track the locations of the suns?
  • How do you update the simulation state for thrust() and steer() actions?
  • How do you determine if a drone spaceship has crashed or if it’s still safe?
  • How do you determine the appropriate output for a scan() action?
  • How do you determine which sections of the space region still need to be explored?
  • How do you keep track of the “partial knowledge” star map collected by the drones?
  • How do you determine the next action for a drone?

Vague answers that fail to reference your design artifacts appropriately (e.g., statements like “…it should be obvious that…”) and avoid addressing the significant aspects of the question will lose points. Please submit your answers as a file named question_answers.pdf.

Problem Requirements & Specifications

The Star Search Simulation System focuses on a simulation system that manages and monitors the actions of a group of drone spaceships as they chart the given space region. Note that you are developing the entire simulation system: for any given “simulation run”, there may be one or more drones exploring the region. Your system must monitor the overall actions of all drones and track the states of all associated objects in the simulation.

The Space Region

We will use a relatively simple and straightforward two-dimensional model of the space region as the basis for our simulation.

• The space region will be modeled as a rectangular grid, and further divided into uniform-sized squares much like a chessboard. Each square will (by default) contain a small “star field” that needs to be explored (i.e. visited), unless it contains an obstacle or some other artifact.
• The squares of the space region will be identified using (X, Y) coordinates. The square in the lower-left corner of the space region will be identified as (0, 0). The X coordinate will represent the width (x-axis) of the space region, and the Y coordinate will represent the height (y-axis) of the space region.
• The directions will be represented using a fairly standard “North-South-East-West” system. Moving in the North direction will correspond to moving towards increasing Y coordinate values. Moving in the East direction will correspond to moving towards increasing X coordinate values.
• The only obstacles that we will consider at this point are large suns.
• Suns are static, and do not move or otherwise change locations during a simulation run.
• A square that contains a sun never needs to be explored/visited.
• If a square contains a sun, then the drone must avoid that square - entering the square will cause that drone to be vaporized instantly, which prevents that drone from performing any more actions during the simulation run.

The Drones

The drones can work as a team and should coordinate their actions to explore as much of the space region as possible. You will have the opportunity to control how the drones determine their actions.

• Each drone will occupy exactly one square of the space region at any one time.
• Each drone will also be pointed in one specific direction (orientation) at a time - horizontally, vertically or diagonally.
• A drone instantly explores any square that it occupies or passes through during a thrust() action, including its initial/starting square.
• During each turn of the simulation run, a drone may execute one of four distinct actions:
  • (1) steer(): to change or reorient its direction;
  • (2) thrust(): move forward one, two or three squares;
  • (3) scan(): the surrounding squares; or,
  • (4) pass(): effectively, do nothing.
• When steering: a drone may reorient itself to any new direction - there’s no limit on the “turning radius” for a drone.
• When moving: a drone may thrust forward one, two or three squares. It automatically executes “retro-thrusters” at the end of the move to come to a complete stop.
• When moving: if a drone attempts to occupy or pass through a square with a sun, then the drone is instantly vaporized and is removed from the space region for simulation purposes. The sun remains unaffected.
• When moving: if a drone attempts to move outside of the space region at any time, then its movement is stopped instantly when it reaches the edge of the region. A barrier (i.e. force field) surrounds the edge of the space region and prevents any of the drones from leaving the region.
• When moving: if a drone collides with another drone, then both drones have crashed, and the “smoldering wreckage” is removed from the space region to avoid collision hazards for other drones (just as if they were vaporized by running into a sun).
• When scanning: the drone receives information about the eight squares that are adjacent to its current location. The scan must return information about the state of the surrounding squares using precise terms including: {stars, empty, sun, barrier, drone}.
• The list of scanned squares must begin with the contents of the Northern-most square, and then proceed in a clockwise direction (Northeastern-most contents, Eastern-most contents, etc.)
• Scanning a square in the space region does NOT count as exploring (i.e., visiting) that square.
• Finally, a drone can pass and effectively do nothing for a given turn.

The Simulation Run

The simulation run will be conducted as a discrete-event simulation, which means that the state of the simulation changes over multiple, well-defined turns. A turn is defined as the opportunity for each drone to execute a single action.

• The flow of the discrete-event simulation will appear more like a game of chess, where the drones take turns executing a single action at a time, as opposed to other simulations that might appear more like a continuously flowing movie or video game.
• A simulation run begins by reading in a scenario file that contains the following information:
  • (1) The size of the space region in terms of its width and length
  • (2) The number of drones being used along with their initial locations and directions
  • (3) The locations of the suns in the space region
  • (4) The maximum number of turns in the simulation run
• For fairness, a drone will:
  • (1) Always be started on a safe square
  • (2) Never be completely surrounded by suns and barriers in its initial position
  • (3) Always have at least one safe move
• Also, there will not be any sections of the space region that are completely surrounded by suns or barriers - all safe squares will have at least one accessible route.
• The simulation run should begin once the scenario file has been read and processed. Each simulation run will consist of a series of turns.
• During a single turn, your simulation system must allow each drone to execute one action in a round-robin format based on the order of the drones as listed in the scenario file. The drones execute their actions individually, not concurrently.
• The simulation run must continue until either:
  • (1) All safe squares have been explored; or,
  • (2) All drone spaceships have crashed or been vaporized; or,
  • (3) The maximum number of simulation turns has been reached.
• Once the simulation run has been halted, then the system must provide a summary report with the following information:
  • (1) The size of the space region (all squares);
  • (2) The total number of safe squares that originally existed on the space region (including the square initially occupied by the drones);
  • (3) The actual number of safe squares that were explored at the end of the simulation run; and,
  • (4) The total number of fully completed turns that were taken.

During the simulation run, the actions being executed by the drones must be displayed on the terminal. Similarly, the final report must be displayed on the terminal as well.

Simulation Sequence & Overall System Goals

Your main goal during this assignment is to design the simulation system that will manage simulation runs from start to finish. This includes selecting classes and objects and assigning responsibilities to manage the required information and behaviors.

• This is the list of simulation system-wide actions needed for the next drone spaceship to determine and execute one action. This is like the “Main Success Scenario” - the list of actions that should be addressed (at a minimum) in your Sequence Diagram:
  • (1) The simulation system alerts the next drone that it needs to provide a proposed action
  • (2) The selected drone uses its internal decision-making processes to determine its next action
  • (3) The selected drone sends its proposed action back to the simulation system
  • (4) If the selected action is a thrust(), then the simulation system must check the state of the simulation to determine whether the movement leads to a crash or vaporization
  • (5) If the selected action is a scan(), then the system returns the scan results to the selected drone
  • (6) The selected drone is allowed to digest any received information (from scans or collisions) and communicate with the other drones as needed
  • (7) The simulation system must update the state of the simulation
  • (8) The simulation system must determine if the simulation run should be halted
  • (9) If the simulation run should be halted, then the system must display the final report; otherwise, the simulation run should continue, and the system continues with the next drone
• At the beginning of the simulation, the drones don’t have any knowledge about the space region they are exploring. The only knowledge that each drone has is:
  • (1) its direction;
  • (2) its coordinates; and,
  • (3) that it is on a safe square of some space region that needs to be explored.
• You must design the simulation system such that the drones will have to learn about the space region as they perform their exploration tasks. The drones are permitted to collaborate while keeping track of all knowledge that they have collectively gathered during the simulation run.
• Finally, the overall goal is for the drones to explore the space region completely in as few turns as possible. We will provide some drone functionality, though you will also be permitted to create some of your own in later phases of the project. For this assignment, however, the main goal for you is to design a set of structures that manage the information needed for the simulation.

Scenario Example

You aren’t required to implement a working system in this phase of the project - this example is just to help you better understand the simulation system itself. Suppose that the scenario file is given as:

5
4
3
1,2,north
0,1,northeast
3,1,west
3
1,1
1,3
3,0
40

The space region is 5 squares in width (X coordinate) and 4 squares in length (Y coordinate). There are 3 drones. The first drone begins at coordinates (1,2) pointing in the North direction. The second drone begins at coordinates (0,1) pointing in the Northeast direction. And the third drone begins at coordinates (3,1) pointing in a Westerly direction. There are 3 suns located at (1,1), (1,3) and (3,0). Note that, of the total 20 space region squares, 3 are suns, and of the remaining 17 squares that 3 are already empty because the drones automatically explore any square on which they are located, including their initial squares. Finally, the simulation run will not last more than 40 fully completed turns. This is the state of the simulation at the start of the simulation run.
The display shows the (conceptual) simulation objects: namely, the drones, the safe squares and the suns.
Now imagine that the following actions are executed: first drone thrusts forward one square, crashing into the sun; the second drone thrusts forward two squares, moving safely to square (2,3); and, the third drone does a scan and discovers the following information about its surroundings: stars,stars,stars,stars,sun,stars,stars,stars
The yellow highlighting indicates the squares that were scanned, and the new state of the simulation is shown in the figure above. (Figure )
Note that the drones have no knowledge of the space region when the simulation run begins as shown above (Figure ). However, they’ve accumulated some knowledge after the first cycle of turns as shown in the figure below. The knowledge of the sun at (1,3) comes from the first drone’s “dying gasp/communication” to the other drones before being vaporized.
The simulation should continue since there’s more of the region to be explored, and there’s still at least one functioning drone. However, if we were to prepare a summary file at this point, then the values would be that the space region has a size of 20, with an initial number of 17 squares that could be explored, and a current total of 4 squares that have been explore so far after 1 fully completed turn. Also, there are 39 possible turns remaining for this simulation run. Note that the initial number of squares that could be explored includes the drone’s starting squares that are “automatically explored” at the beginning of the simulation run.

Evaluating/Grading Your Submissions

• You must generate your diagrams using an automated tool (e.g. Argo UML, draw.io, 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).
• We prefer that you submit your diagrams in dark, rich colors (particularly black). Diagrams submitted in certain colors, especially pastel or lighter shades, can be difficult to read.
• 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). We highly recommend that you label all diagrams with a header that includes your name and the UML version being used. There are significant differences between the UML versions, so your diagram must be consistent with the standard you’ve designated. Either version is acceptable at this point in the course.

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. 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.

Quick Reminder on Collaboration

Please use Piazza for your questions and/or comments and post publicly whenever it is appropriate. If your questions or comments contain information that specifically provides an answer for some part of the assignment, then please make your post private first, and we (the OMSCS 6310 Team) will review it and decide if it is suitable to be shared with the larger class. Best of luck on to you this assignment, and please contact us if you have questions or concerns.