Project 3: Part A

In this part, our team (the Nintendo division) had a bit of a slow start because we had a hard time trying to figure out the work that needed to be done and how to divide it evenly among each team. We didn’t want some teams to have to do more work than others, so we spent a lot of time in the division team meeting partitioning the tasks evenly. For this project, our division team held meetings every couple of days. They were mandatory for all team leaders but open and optional to anyone who wanted to join. After a bit of time, we were able to conclude what the different tasks were going to be. My team signed up to do the UML diagram, Sequence diagram, and some sample APIs since we aren’t the best at unit tests so that was the best option for us. My group continued the schedule of meetings every Monday and Friday on top of the additional meetings that the division team has every couple of days.

My group had some trouble working with both diagrams, but lucky one of our group members knows a bit about UML diagrams so that helped my team significantly. Instead of splitting up the work and doing the diagrams separately. During our meeting on Friday, we decided it would be easiest to complete the diagram together while all of us were on call and present. We used Lucid charts once again to create the UML diagram, the same tool we used for the last project. During the meeting, every member chose a couple of classes to create a box and filled it in with classes and variables on our own. After we had every class in boxes, we tried to slowly connect all the classes with specific arrows to indicate how the connected classes relate to each other. One of our team members put a key of what each arrow meant so that made it a lot easier to ensure we were using the correct arrows in certain places.

One of our team members was unable to make both meetings where we worked on the UML diagram and Sequence diagram. So, to make up for the lost work and ensure he still contributed to the project, he volunteered to work on half of the sample APIs (5) for the design document. Another member also volunteered to do the other half of the sample APIs because she wanted to contribute more to the project since she didn’t think she did enough in the diagrams. Because all our members did their part, we were able to complete our diagrams in time.

For this part of the project, I did struggle a bit because the only practice I had with creating sequence diagrams was in Project 2 and that was just a small one. The diagram of Project 3 is much more complex so at the beginning I watched what my teammates were doing first. That helped me learn about UML diagrams and how to make them. I learned a lot through my teammates throughout all three projects, so it has been great since I came into this class not knowing much about GitHub or creating diagrams.

Project 3: Part B

For the second part of this project, my group was assigned the continuation of the UML and sequence diagrams we worked on in part A. The diagrams need to be updated to show what the current state of the program looks like. Two of our team members who are more skilled with diagrams volunteered to add updates to them. We were also assigned to add 5 more brick shapes (classes) to the program. I offered to work on the T-Brick class and the rest of my team members signed up for the remaining four brick shapes left. I didn’t have too much trouble with creating the T-Brick class since I used the I and L brick class as a reference.

There weren’t too many issues in part b, but the hardest portion had to do with getting the timing correct. Our team had to wait for team 8 to finish fixing the bug fixes before we could start working on our Brick classes. Then team 7 had to wait for our team to finish creating the Brick classes and create a pull request. They were tasked with unit testing our Brick classes so they couldn’t do any tests without our classes.

I had a small issue with trying to do git pull from main because it kept asking me for a username and password but every time I tried my GitHub credentials, it failed. After messaging my professor for advice, I changed my remote origin to SSH instead of HTTPS and I was able to do a push to my remote branch. After that, I created a pull request. The member from team 7 in charge of doing the unit test for the T-Brick class contacted me so it became a lot easier to discuss our progress. Once I created a pull request, I messaged her then she contacted me once again to let me know the class looked good. When I tried to merge the class, there was a small merge conflict since all the brick classes are required to have a line added to the “RandomBrickGenerator” class. My team raised this concern during a meeting too, so we were expecting this to happen. There were a bunch of arrows (<<<<) that indicated which lines had a conflict. I haven’t resolved a conflict directly in GitHub before but I know one of my team members has done it before, so I googled how to do that. After reading a couple of articles about it, I was able to resolve the conflict and easily merge the pull request. I was able to edit the lines of code directly in GitHub which was especially convenient. I didn’t have to do the long process of editing in IntelliJ.

Overall, this project was a little stressful for me, mainly because there are just so many components that must be put together. Despite the limited time my team was given to implement our changes to the Tetris class, I believe the division team as well as my team did an excellent job of communicating and contributing to the project. Every single person had a significant role in making the final version of the project. The communication in our division team was splendid and everyone was kind to one another. I’m happy about the work we accomplished in such a short amount of time and more about how well we worked together.