San Jose State University | CS 151 - OO Design Section 4 | Spring 2017

Group Project Rules

1. 3-4 members per team—no exceptions.
2. You can email me preferences for team members and projects by Tuesday, April 4. I assemble the teams and assign the projects.
• Send me your project preferences, starting with the project you like best and ending with the one you like least. Optionally, include the names of preferred team members. Send it from the email address that you'd like your teammates to use.
• If you do not email me your preferences, you will likely end up with students of similar lack of initiative, and be assigned the least popular topic.
3. Each team makes a new repo on Github/Bitbucket and invites me and all the participants.
4. Put all documentation in the Github/BitBucket Wiki
5. Use the issue tracker for work assignments. Each task has a single owner.
   If it's not on the issue tracker, I won't recognize it as an accomplishment.
6. Each team is prepared to give a brief progress report in class on Monday, with every member present.
7. Each team member submits an individual report each Sunday night in the project Wiki. Each report has this format:

   Week x
   ======
   Date time1-time2: What you worked on
   Date time3-time4: What you worked on
   ...
   Comments: 
   Total hours this week:
   Total hours on project:

8. All project code is always on Git.
9. There is a build script that builds the program, runs test cases, runs CheckStyle, and javadoc.
10. It must build on my machine (and on yours).

Projects

You may choose from one of the following projects. All projects are based on the Violet UML editor whose source code can be found at http://horstmann.com/violet. (Just unzip the JAR file.)

To build the source code, you need Ant. You can install it in Linux by running

sudo apt-get install ant

Then simply run

ant

in the directory containing the build.xml file.

You can get an architectural overview of Violet in Chapter 8 of your textbook and at http://www.aosabook.org/en/violet.html.

FXViolet

Class and sequence diagrams with JavaFX

• Class diagrams: Tian Peng, Colman Zhu, Daniel Chang
• Sequence diagrams: Jeremy Tabujara, Anu Vaishnav, Ian Martin

MobileViolet

Some way of doing some UML diagrams on an Android phone or tablet

• Class diagrams: Daanyal Saeed, Jose Sandoval, Filip Koperwas, Arthur Chan
• Sequence diagrams: Monil Gandhi, Nhu Nguyen, Carson Sanders, Hayley Carpenter

TeamViolet

What if multiple people want to collaboratively edit a diagram? Commands are set to a server, which sends it to all participants, and the diagrams are kept in sync.

• Class diagrams: Rebecca Woehrle, Brandt Willems, Yukai Yang, Sean Chan
• Sequence diagrams: Chitwant Singh, Cyrus Javan, Tyler Wasniowski

TextViolet

Use a text description to specify class and sequence diagram, similar to http://spinellis.gr/umlgraph, http://yuml.me, or https://www.websequencediagrams.com/.

• Class diagrams: Nyan Soe, Enrique Cardenas, Jason Do
• Sequence diagrams: Vivian Tran, Christine Zhang, Sophia Tan

Week 1 Goals

• There is a functional specification document on the Wiki (describing what features you will be able to do, with a description of the user interface.)
• There are issues in the issue tracker. Each issue must be doable in ≤ 3 days and have a single person assigned to it. Each team member must have ≥ 3 issues.
• Some code is in Git and builds on the command line, including javadoc and CheckStyle
• Each team member submitted their individual reports

Week 2 Goals

• Each team member has made at least two commits. (Note: You all commit to the main branch. No branching/merging.)
• Design documentation is complete (classes, maybe a sequence diagram or two if it's relevant for your project, I/O format or protocol if it is relevant)
• The issue tracker has enough issues to carry the project to the end of week 3. Issues are well distributed among team members, short and assigned to a single person.
• The project builds (on the command line) and does something useful. Put instructions for building and for trying out that useful feature on the wiki.
• Each team member has closed at least one issue and has put the closed issue number(s) in their report.
• Each team member submitted their individual report, with weekly and total hours.

Week 3 Goals

• The project builds and does something significant. Put instructions for building and for trying out that significant feature on the wiki.
• A status page lists what already works and what doesn't yet work.
• There are sufficient issues to keep each team member busy for project completion.
• Each team member has made at least two commits.
• Each team member has closed at least two issues and has put the closed issue number(s) in their report.
• Each team member submitted their individual report, with weekly and total hours.

Week 4 Goals

• Design documentation is revisited and lists all planned classes.
• All issues that are required for successful completion of the project are on the issue list.
• The status page is updated to list what doesn't yet work.
• The project builds and accomplishes most of what is required, perhaps with some errors.
• Every team member has multiple commits throughout the week.
• Keep your individual reports up as before.

Week 5 Goals

• The implementation is complete.
• Every team member has multiple commits throughout the week.
• Keep the status page and your individual reports up as before.