Assignment 2
GIT, Scrum, GUI, Design Patterns
| Due: |
Oct 23 by 11:59 pm: Sprint 1 Oct 30 by 11:59 pm: Sprint 2 Nov 6 by 11:59 pm: Sprint 3 Nov 14 by 11:59 pm: Sprint 4 (including updated architecture discussion) |
|---|---|
| Late penalty (applies to sprint4 only): | 20% if handed in up to 48 hours late. Not accepted after that. Please indicate the commit ID you want us to mark in this page. Otherwise we will not check your code out of the repository for marking. |
| Hand in: | Electronic submit via git, that is, you should have your code checked into your repository by the due date. We will check it out from there. |
| Marking: |
A detailed marking scheme will follow. For now...marks will be given for
|
| Groups: | Groups of size 4.
Please visit the group signup application to see which group we have placed you in.
You can switch to another group of your choice, but there must be 3 or 4 members, and all members must be in the same tutorial section.
All groups will be marked the same.
You can clone your repo at
Your repos have been created, you will add members.txt as well as the Assignment2 starter code. then add your contact information to the members.txt, then add, commit and push. Make sure very little time has passed between the clone, change to members.txt, add, commit and push. At some point later, you can git pull to see the other members in your team. Remember, this is not the same as the labs which were inside your personal repo. |
Paint Background
- You and your team will first understand and then modify (Sprint1), re-architect and extend (Sprint2, Sprint3, Sprint4) the paint program.
- You and team will be using
- IntelliJ
- Java 22
- Openjfx 22
- git
- the school provided repo_a2_NNN
- Scrum
Meet the team and the code
The first meeting with your team should have everyone- Exchange contact information
- Review the tool chain, and make sure everyone understands and can effectively use their tools.
- Initially claim at least one user story.
- Clone the group repo.
- Make sure members.txt is in the repo and everyone has their information in it.
- Unzip the starter code at the root of your repo. So we should see repo_a2_NNN/Assignment2/...
- Add, commit and push
- Pull the latest version of the repo. See that all of the contact information is in members.txt.
- Make sure that you can get the starter code running on your system.
Learning about the code
In this part of the assignment, your goal is to review the system, and understand how features can be added to the system. You should get together with your team and
- Review the code
- Create UML diagrams for the existing classes
- Discuss how one adds another shape feature (such as rectangle) to the system.
- identify the way in which the current version of the software implements the MVC pattern (which parts are the M, V and C).
Sprint 1: Planning Meeting
For this sprint, no major architecture changes or application of design patterns is allowed. Architecture and design pattern changes will happen in Sprints 2,3,4. Sprint1 is about familiarizing yourself with the code, with git, with the documents etc.I have imagined that we
- had our Sprint1 planning meeting
- generated productBacklog.txt
- Prioritized the BUGs and UserStories (1,2,3).
- NOTE: We should have estimated the amout of time for each before the next step!!! You can do this now!
- selected BUG1.001, BUG1.002,BUG1.005,BUG1.006 and US1.002, US1.003, US1.004 for Sprint1 (due Oct 23, 2025). Note: we changed the numbers of these User Stories and BUGs to indicate that they are being worked on starting in Sprint 1 (see the leading 1). Do not do any other user stories for this sprint.
- copied them to the sprintBacklog1.txt.
- Pick a BUG or USER STORY from the sprintBacklog1.txt
- Put your utorid on it (both in productBacklog.txt as well as sprintBacklog1.txt)
- List the item as Started
- Place an estimate on the amount of time needed to complete the user story. Normally this would have been done during the planning meeting.
- add, commit and push so everyone knows that you claimed that US or BUG
- Create a branch (named for the US or BUG), and checkout your branch
- work on your US/BUG till you complete it, adding, committing and pushing your branch all along
- Switch to master
- pull master, to get the latest commit
- merge your branch
- Mark your user story as Complete in sprintBacklog1.txt
- Mark your user story as Complete in productBacklog.txt and move them to the completed section
- Add, commit and push
- Repeat (but make sure each team members handles at least one user story or bug)
Notes for Sprint 1
- Inside the repo, you will find important documents and directories
scrum - the directory to store scrum artifacts. - please review and maintain the documents here. You will be adding to - architecture/architecture.txt - used to describe the architecture of your system and list design patterns used. - dailyScrumMeeting[1-4].txt, one file for each team member - productBacklog.txt - sprintBacklog0.txt - a sample sprint backlog outlining the work I did to prepare the assignment. - sprintBacklog[1-4].txt - you use these - planningNotes.txt, a note outlining how you are to work together on the scrum - ANoteOnGit.txt, outlining how we expect you to collaborate on the project. - When you create a branch, please name it USx.xxx or BUGx.xxx corresponding to its type and number in the productBacklog.txt/sprintBacklog1.txt. Make sure to include your UTORID in the user story/bug when you claim it.
- Please make sure to commit and push your branches, so that everyone, including instructional staff, can see progress on branches and master.
- Please make sure that your UTORID is attached to your commits, so we can see your contribution to the project.
Sprints 2, 3 and 4
- You will start to re-architect in these sprints.
- IMPORTANT: Please make sure to use appropriate design patterns as you see them arise.
- Register a bug when refactoring your code.
- You can complete more user stories as well as add new user stories and bugs.
Sprint 2
From Sprint1: You understand the existing code base, and some of the JavaFX api. You now know how to add to productBacklog.txt, manage sprintBacklog1.txt, clone your repo, run the project, branch to work on a US/BUG, work on it, pushing to remote, merge back to master. You have some feeling about your team members (some teams have fired some of their team members, please let me know ASAP if you want to fire yours because they are not responsive or contributing). If they just don't understand, then be a good team member and go out of your way to teach them.
For Sprint2, Due Oct 30 at 11:59 PM, you should
- Have someone in the team take the role of the Product Owner and write Square, Triangle and Oval user stories and add them to the productBacklog.txt. Take a look at how Ovals are drawn in paint programs (bounding boxes is one approach).
- Have a sprint planning meeting to decide on the list of BUG/US which go into this sprint (I have decided for you!) and who will take them.
This will modify productBacklog.txt and sprintBacklog2.txt on master in the remote.
- If US/BUG are incomplete from Sprint1, add them to Sprint2
- Include BUG?.003 in sprintBacklog2.txt, and so discuss the new architecture.
This will be an application of some Design Patterns discussed in class.
Make sure everyone understands your design choices.
-------------------------------------------------------------------------- TYPE : BUG BUG?.003 : UTORID : NotStarted NAME : Architecture behind choosing selection mode is poor PRIORITY : 3 ESTIMATE : (1 hour, 2 hours, 4 hours, 1 day, 2 days, 4 days) ACTUAL : ISSUE : Code is not modular and is difficult to expand. Need a better architecture behind selecting a drawing mode, and handling the drawing events. Consider some design patterns here. Refactor ShapeChooserPanel and PaintPanel to get rid of the 'if' blocks in the PaintPanel mouse event code. -------------------------------------------------------------------------- - Include Triangle, Square and Oval in Sprint2
- Do not include any other BUG/US in this sprint
- Work on the sprint for the week. So complete BUG2.003, and then US for Square, Triangle and Oval.
- Throughout Sprint2, add in BUG to productBacklog.txt. As a team, take the role of Product Owner and suggest some new US you might want to add in Sprint3 and Sprint4. You can add them into productBacklog.txt.
Sprint 3
From Sprint 2: You understand how to modify the architecture to create a framework and make use of your framework to add features. For Sprint 3, you will complete BUG3.004 and start adding in and completing BUG and US of your own.
For Sprint3, Due Oct Nov 6 at 11:59 PM, you should
- Imagine that you spoke with the product owner. As a result, create a collection of US and BUG and add them to the productBacklog. Make sure to make the BUG/US concrete. Just saying you want to add a feature is not sufficient. Please make it clear how the user interacts with the feature. For example, to add a Triangle, you must describe the steps the user takes and the result.
- Your sprint planning meeting should have you decide which BUG and US go into this sprint, and who will work on them. Remember, you had some BUG and US from sprint2 and now more for the start of sprint3.
- Include BUG?.004 in Sprint3. It is not well defined, you will need to flesh out how to fix this in the expanded BUG. Consider some design patterns.
- carry out the sprint, branching, issuing pull requests, handling pull requests, and merging along the way
- Only let code into master as a result of a pull request. We will do this through
through a file. The
scrum/pullRequests.txt. Note: All changes to pullRequest.txt take place on the master branch.pullRequests.txtwill look like...Pull Requests: BUG3.012 author:noble2 puller:jaybe1 status:Complete US2.002 author:jaybe1 puller:sidd27 status:InProcess BUG3.011 author:noble2 puller:? status:Waiting Please make sure to conform to this standard, with appropriate BUG, US, utorid, and status (Complete, InProcess,Waiting, Rejected), as we will use this file to mark you on the BUG/US you complete as well as which pull requests you handle.
Here is how it works.- US2.002 was taken by jaybe1 and completed.
- jaybe1 wants this to be merged into master, but jaybe1 WILL NOT MERGE TO MASTER.
- jaybe1 creates a pull request. That is
jaybe1 adds the line
US2.002 author:jaybe1 puller:? status:Waiting topullRequests.txtand tells the team that "US2.002 is complete, I have left a pull request in pullRequests.txt" - sidd27 agrees to take the request
- sidd27 changes the the pull request to
US2.002 author:jaybe1 puller:sidd27 status:InProcess - sidd27 checks out branch US2.002 and pulls
- sidd27 contacts jaybe1 to discuss the feature, and the changes to the code
- sidd27 might find that there are bugs in the code, or more work needs to be completed
before they are willing to merge the code and can reject this request. In this case they would
modify the status to
US2.002 author:jaybe1 puller:sidd27 status:Rejected in which case jaybe1 would continue to work on US2.002 and then contact sidd27 again when they want sidd27 to pull again.
sidd27 might find that the changes to the code are good and so the code can be merged
into the master branch. sidd27 would then merge the code into master and modify the pull request to
Sprint 4
For Sprint4, Due Nov 14 at 11:59 PM, you should ...-
Scrum (scrum and rest of code base)
Continue as in Sprint 3, adding US/BUG to the productBacklog, choosing some for the sprint, executing by implementing US, fixing BUG, effectively using git, handling pull requests. -
Features (
scrum/extraFeatures.txt)
Extra features are worth 15% of your a2 mark.
Extra Features are competitively marked by number, difficulty, creativity and quality. The extra features are up to your team to create and implement. Fill inscrum/extraFeatures.txtwith features that you implemented outside of those that we required or were originally provided. These are US/BUG you proposed and implemented on your own, to make the application function better, or even great. New Drawing Modes, ability to add text, a mosaic feature, Undo/Redo, Select, cut, copy, paste, ...
Here is a summary of what we required: BUG1.001, BUG1.002,BUG1.005,BUG1.006 and US1.002, US1.003, US1.004, Square, Triangle , Oval, BUG?.003, BUG3.004.
Hint: A great architecture will enable easy addition of lots of extra features, good use of Factory, Command and Strategy in Paint would make a big difference in your ability to add features like Redo/Undo, Cut/Copy/Paste, Adding new Drawing Modes, ...
Writing Component
During practicals/tutorials on November 5th or November 6th, you will be working with your group on the writing component related to accessibility. The writing component will complement what we discussed during ethics lecture on accessibility during week 8 (October 20th to October 24th). The groups are created based on the tutorial you are enrolled in officially on Acorn and will remain as your group for the full duration of assignment 2. The writing component instructions and rubric will be provided when you attend the tutorial that week. You will be expected to work on and submit the writing component (as a group) at the end of your tutorial. To prepare for the writing component and the w08 lecture, please review Ability Based Design and Principles of Universal Design.Questions and Answers
- Question:
- Any comments about the first sprint?
- Answer:
-
Sprint 1 was about... 1) Setting up your environment. 2) Figuring out if team members are reliable. 3) Understanding MVC, and the challenges you face in starting to think about solutions using OO and design patterns. 4) Using git It was important to experience this early. Imagine if left to the last week before the assignment was due. Also, that is not how scrum works. So... If you are still having issues with project setup, please let me know and we will fix it, of course, you can work in the lab, and this is the target platform anyway so you should probably work there or on the VM anyway. As far as unresponsive team members are concerned, I will pull the repos so see if a team member has not registered in members.txt. Those not already not in members.txt may find themselves moved out of the current groups. A few issues I have seen with the repos: 0) Some students put student numbers in members.txt, nope, we want your utorid. 1) Some have placed all kinds of interesting files in the project. They should not be there. For example, I have seen a complete JDK in the project. I also have seen a collection of dll in others. 2) Some people leave merge conflicts that unresolved. If you see >>>>>>>>>> in your files, you have not correctly resolved a merge conflict. See for example: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-using-the-command-line Arnolds Famous Saying: Pay now or pay later, sooner or later you will pay. Paying the price to get the environment setup correctly now will save you more effort later. - Question:
- When do I branch?
- Answer:
- Yes, you should be branching now. Create a branch for each user story/bug you take, then develop your user story/bug, adding and committing on the branch then merge back to master when complete. Master should only have working, complete code on it.