代写CSCI 3081W: Program Design and Development

CSCI 3081W: Program Design and Development
Final Project: New Feature Extension
Spring 2023
Please read the whole thing!
(No deadline extensions will be provided)
Subject to minor changes until Thursday, April 6th at 11:59 pm.
New Feature Checkoff due date: Thursday, April 13th at 11:59 pm.
Writing, Coding, and Presentation due date: Friday, May 5th at 11:59 pm
Goal
Design and implement new feature(s) to add to the ongoing project.
Source Code:
1) Your lab10 solution
OR
2) Provided base code https://github.umn.edu/umn-csci-3081-S23/public-hw4-basecode.
Overview:
In this homework assignment, you will apply all the concepts learned so far from the beginning
of design patterns to being able to work in a sprint (workshop 6). Consider the lab project as an
ongoing project in your workplace. As a team of agile coders, you have to work in ~4 weeks
time to impress your product owners (the instructors and TAs). You have to design a feature(s)
addition to this project, and come up with a good design pattern which leads to seamless
integration. The report you submit will inform the reader about your feature (this refers to the
checkoff - lab11). The implementation must use a pattern which creates a robust design and
works well with any past and future features. The video should show a demo of this feature,
before deployment to DockerHub.
What you'll learn this assignment:
1. Designing a new feature(s) for a project.
2. Applying agile skills by working in a sprint.
3. Creating a UML for a new feature.
4. Coding the new feature(s) for an existing codebase.
5. Presenting the implementation through a YouTube video (make sure we are able to see
it).
Instructions:
Work with your team members but be sure that you understand the solutions you come up with
and not one person is doing all the work. If you need help, you can talk with your TAs.
Where to store your source code?
We will create a github repo for you. Please do not make your own private repo.
Repo format: Team-001-01-homework4
Designing a New Feature:
The feature that you pick must be significantly interesting!
We recommend that you get checked off before coding your idea! If the idea is trivial and the
idea was not checked off, you will have points deducted.
We also have a Gradescope submission for getting your idea checked off (due Thursday, April
13th)!
The checkoff is required!
Teams of 2: 1 non-trivial feature with a design pattern(s) as the solution
Teams of 4: 2 non-trivial features each with a design pattern(s) as the solution
Examples:
1. Decorator & Factory - battery wrapped around the drone and add recharge stations;
logic for factory pattern and business implementation must be updated too.
2. Singleton - data collection, then output to .csv and analyze the data that you collected
3. Observer - notifications
4. Memento - snapshot tracking
5. State - drone attributes
6. If you come up with another idea and want to get it checked off as “valid”, please talk to
one of your TAs during Lab 11!
Checkoffs
Once you have your features and ideas, you must get them checked off with an instructor or
graduate TA. Then submit to Gradescope for final approval/official check off so that it is officially
documented and can be referenced back to.
Requirements (whole project):
If an individual has 0 GitHub commits AND the peer review(s) about them are
poor, they will receive a 0 on Homework 4.
Coding
- Use design pattern(s) to implement your new feature(s)
- Brainstorm different design patterns, your first choice may not always be the best
one.
- If mid-way through your coding process, you see a better way to implement
things, by all means try it out
- Place all of the newly created classes inside the libs/transit folder
Important: If your code does not compile on CSElabs machines, you won’t
receive credit for the coding section.
Documentation
- Doxygen
- Doxygen for ALL of the classes (existing and newly created)
- You are NOT required to do doxygen for the classes under these folder
- dependencies/
- libs/routing/
- libs/transit/util/
- apps/
- Doxyfile and the generated materials from doxygen (i.e., index.html,...)
- Google Code Style
- Code Style for ALL of the classes (existing and newly created)
- You are not required to do code styling for the classes under these folder
- dependencies/
- libs/routing/
- libs/transit/util/
- apps/
- Write Up
- File Name: README.md (should be located in the GitHub repository)
- Team number, member names, and x500.
- What is the project about (overview of the whole project, not just the hw4)?
- How to run the simulation (overview of the whole project, not just the hw4)?
- What does the simulation do specifically (individual features ie movement of
entities etc) (overview of the whole project, not just the hw4)?
- New Feature
- What does it do?
- Why is it significantly interesting?
- How does it add to the existing work?
- Which design pattern did you choose to implement it and why?
- Instruction to use this new feature (if the new feature is not user
interactable, please mention this as well)
- Sprint retrospective
- UML
- Create UML diagram depicting ONLY your new feature
- Upload this to the github repo and also display this in the aforementioned
README file
Docker
- Upload and push your final code to DockerHub
- Put this link inside the GitHub README (be sure to state what the link is about).
YouTube Video Presentation (~5 min)
- Explain the new feature that your team has implemented
- What is it?
- Why is this new feature important?
- Which design pattern did you use?
- Demo
- Optional: Source code if you have more time
- Everyone in the team must talk with video cameras on
- You can upload this video to YouTube and put the link that will redirect toward your video
inside the README (be sure to state what the link is about). Make sure the teaching
staff has access to this video. Feel free to set it to private or delete it once you have
received your final score.
Peer Review
- Peer reviews are individual. You will assign a value for each team member in your group.
The total will add up to 100. For example, if you have 2 people, you could do 50-50.
There will also be a portion where you list each member’s responsibilities. If a peer
review comes back and a member has a 0, we will check your team’s GitHub commits. If
they have 0 commits, they will receive a 0 on homework 4.
- Review your teammates by filling out the form below.
- To be uploaded here
- This is due on Friday, May 5th at 11:59 pm.
Submission (due May 5th):
- Canvas:
- Github repository link
- Github:
- Source Code
- Doxygen
- Write up (README file)
- Write up
- Docker link
- Video presentation link
- UML
- Peer Review: Fill out this form:
Grading Breakdown:
- Coding: 45%
- Documentation: 40%
- YouTube Video Presentation: 5%
- Docker: 5%
- Peer review: 5%
Observer Pattern - Notifications
The goal of this feature is to add notifications to the sidebar in the 3D simulation using the
observer pattern.
If you are not familiar with the observer pattern, feel free to check the Refactoring Guru
Observer Example.
In our Drone Simulation System, there are several potential places where observer patterns
can apply.
- The droneObserver which will print information about drones in the frontend UI. For
example, Drone1 is on the way to pick up the robot1.
Drone1 has picked up the robot1.
Drone1 is delivering the robot1 to the final destination.
Drone1 has delivered the robot1 to the final destination.
…etc.
Here is the example screenshot. As you can see, the corresponding information is printed out on the left
side.
- The robotObserver which will print information about robots in the frontend UI. For
example, Robot1 is scheduled.
Robot1 is picked up.
Robot1 is delivered.
…etc.
- Other observers based on what you want to observe. Feel free to incorporate anything
you added into your simulation from lab10!
Decorator and Factory Pattern - Battery Wrap Around Drone and
Recharge Stations
The goal of this feature is to add the battery on top of the drone in the 3D simulation using the
decorator pattern. If you are not familiar with the decorator pattern, feel free to check the
Refactoring Guru Decorator Example and also review the previous lab where we went through
the decorator pattern. Additionally, you will need to extend your factory to include the creation of
Recharge Stations.
By applying the decorator pattern on top of the Drone, you should be able to track the battery of
the drone. For example, as time goes by, the battery of the drone decreases by 2% starting from
100%, then
if the battery is below some threshold or is <=0%, the drone should not be able to move/deliver
the robot any more. In this case, there are some possible solutions but feel free to come up with
other solutions based on your design.
1. Drone keeps track of its battery and goes to the recharge station when it detects a
depleted battery.
2. Drone stops at where it is (0% battery) and waits for other entities to recharge it.
3. …etc.
You can also add other decorators based on what you want to decorate. Feel free to incorporate
anything you added into your simulation from lab10!
Singleton Pattern - Data Collection
The goal of this feature is to add the ability to track data from the 3D simulation in a CSV file
using the singleton pattern.
If you are not familiar with the singleton pattern, feel free to check the Refactoring Guru
Singleton Example.
In our Drone Simulation System, there are several potential places where singleton patterns
can apply. For example, students can track a drone’s or a robot’s
● Speed
● Amount of trips
● Fuel efficiency
● Directions
● Position
● …etc.
● Feel free to incorporate anything you added into your simulation from lab10!
State Pattern - Drone Attributes
The goal of this feature is to modify the Drone’s attributes as it progresses through milestones of
the simulation.
If you are not familiar with the state pattern, feel free to check the Refactoring Guru State
Example.
In our Drone Simulation System, there are several potential places where the state pattern can
be applied.
For example, students can modify the drone’s:
● Speed
● Color
● Movement
● …etc.
A drone should be able to modify itself through the state pattern. A simple example would be
changing the drone’s speed depending on the number of completed trips.
Memento Pattern - Snapshots
The goal of this feature is to allow for snapshots to be taken at certain points during the runtime
of the simulation for data collection. Data collected from these snapshots are reflected back on
the scheduler for the user to see.
If you are not familiar with the Memento pattern, feel free to check the Refactoring Guru
Memento Example.
Snapshots should [also] save the state of the simulation at a given time and should be able to
restore itself back to said point.