CSSE 220 – Object-Oriented Software Development
Vector Graphics Team Project

Overview

For this project you will create a program for drawing “vector graphics”. Unlike the graphics created by a program like Paint in Windows, vector graphics store each shape separately. This allows individual shapes to be selected, resized, moved, layered, or deleted independently of the other shapes. And because the program records the properties of each shape, you can zoom in on a vector graphics image without it becoming pixelated. Examples of vector graphics programs include Visio, the shape drawing facility in Microsoft Word and Powerpoint, and OmniGraffle for the Macintosh.

Here is a cool QuickTime movie about the project (circa 27 MB).

Administrative Background

Team Assignment

This is a team assignment. That means that some “divide and conquer” is valuable (indeed, necessary!) and appropriate.

It is also a learning experience. To that end:

• For full credit, every team member must participate in every major activity.
  • For example, everyone should participate in the UML class design, although it is fine to divide up the classes so that each team member does the details for only some of the classes.
  • Another example: everyone should do some GUI work, but it is appropriate do divide up the GUI so that everyone does only part of it.
  • It is your responsibility BOTH to participate in every major activity AND to help your teammates do so.
  • So if you do all the UML by yourself, YOU will receive a reduced score (as will your teammates).
• Everything that you submit for this project should be understood by all team members.
  • It is your responsibility to (a) not submit anything without first discussing it with your teammates, and (b) not let code (or other documents) that your teammates write go “over your head” without making a strong effort to understand it (including having a teammate explain it to you, of course).
• It is perfectly fine to get help from the in-class or lab assistants. As always, they should provide help, not do the design or write the code for you.

Team Grading Note

If all team members obey the above two rules for an appropriate learning experience, and if all team members “carry their weight” in the project, then all team members will receive the same score for this assignment.

• Those who don't obey the above two rules for an appropriate learning experience will receive a reduced grade. This means BOTH the person who (for example) did not participate in a major activity AND the person(s) who did not actively help that person participate.
• Those who don't “carry their weight” will receive a reduced grade.
• A person who goes “above and beyond the call of duty” may receive an increased grade.
• In particular, if you aspire to a higher level of achievement than your teammates do on this project, your team should talk with me to see how we can structure the project for this.
• If you have a team member who is not participating appropriately, help the team member change his behavior and BRING ME INTO THE LOOP EARLY.
  • If necessary, the team can experience a “divorce” in which the non-participant leaves the team.

Subversion Repository

Your SVN repository for this assignment is:

    http://svn.cs.rose-hulman.edu/repos/csse220-200930-TeamX

Add ordinary (non-code) files to your Eclipse project as follows:

1. Outside Eclipse, put the file into your VectorGraphics project (under C:\JavaProjects or wherever your workspace is), in the appropriate subfolder.
2. Within Eclipse, right-click the VectorGraphics project folder in the Package Explorer view, and choose Refresh.
3. Your file should appear under the subfolder you placed it in. Now right-click the VectorGraphics project folder again, and choose Team → Commit. Be sure the new file is checked so that it is added to the repository. Enter an appropriate message and complete the commit.

Process

You will use many of the Rules and Practices of Extreme Programming. In particular, you will use:

• Pair programming: at least 1/3 of your own coding sessions must be pair programmed (else a reduced score on the project for you!).
• More to be added here - you can probably guess what from the above link.

Deliverables

Milestone dates are listed in the table below. This rest of this section describes the artifacts (deliverables) due at each milestone. Follow the instructions carefully.

You will usually have half of each of our sessions to work on your team project. (We'll do other, individual work in the other half of each session.) You should usually use your in-class team time to:

• organize (have we accomplished our tasks due today? what will we do next? who will do what?),
• discuss (what classes belong in our design? what should be the user stories for our next cycle?), and
• integrate code and other deliverables.

Project Schedule and Milestones

Screen Layout sketches

Before brainstorming candidate classes using CRC cards (see next section), you will find it helpful to make some sketches of potential screen layouts (depicting user interfaces) for your project.

• See the Overview section above and the Features section below for additional information on the responsibilities of your program.
• Your user interface can be similar to that in the QuickTime movie about the project (circa 27 MB) or it can be different; do whatever user interface / screen layout you think is best.

Reach consensus in class on a draft of the Screen Layout sketch that you will use. Then, one or more team members may finish the sketch outside of class.

• The sketch need not be detailed, but should be annotated sufficiently to convey how the user operates your program.
• One page that shows the main screen is probably enough, with annotations to indicate submenu's, dialogs and other screens.

To be turned in:

1. Your Screen Layout sketch must be a PDF file named something like ScreenLayout.pdf.
   • If you did it on paper (that's fine!), scan it.
   • You probably have PDF Creator on your computer; if not, there are plenty of free PDF writers available.

2. Place your Screen Layout sketch in the Planning subfolder of your project.
3. In Eclipse, refresh if needed and commit the change.

CRC Cards and UML Class Diagram

You must use the object-oriented design technique discussed in your textbook (Chapter 8, sections 1 and 2, and Chapter 12) and in class to generate CRC Cards and a UML Class Diagram for your project.

• You will receive a good score on your project ONLY if your design is object-oriented and obeys the design principles as discussed in your textbook (Chapter 8, sections 1 and 2, and Chapter 12).
• Name your class with the main() method Main.
• Here is a “sanity check” for your UML class diagram. Does it:
  1. Have Main?
  2. Have classes for all visual elements, e.g. EACH button?
  3. Have IS-A arrows to Jxxx for classes that extend Swing components?
  4. Have IS-A arrows to ActionListener and other Listener interfaces where necessary?
  5. Indicate what creates   what?
  6. For each development cycle, have the necessary details (attributes and properties) for that development cycle?
  7. For each property, have associations that allow that property to be implemented?

You must draw your UML Class Diagram using UMLet.

To be turned in:

To turn in your CRC Cards:

1. Put your team number on the back of each of your completed CRC Cards and hand them in when you complete them in class.
2. We'll promptly scan them into a file called CRCCards.pdf
3. We'll commit them to your VectorGraphics project in your team repository for you, in the Planning   subfolder.

To turn in your UML Class Diagram:

1. Your UML Class Diagram must be in two files: as a UXF file (native format for UMLet) AND as a PDF file. named something like UMLClassDiagram.uxf and UMLClassDiagram.pdf, respectively.

2. Place your UML Class Diagram files in the Planning subfolder of your project.
3. In Eclipse, refresh if needed and commit the change.

User Stories

Short development cycles are a key feature of Extreme Programming. This is especially useful for projects where the development team—that’s you—is unfamiliar with the problem to be solved. At the start of each development cycle, the team negotiates with the customer on the work to be accomplished during that cycle.

The customer suggests user stories to be completed. These are short, often one sentence, descriptions of what the user would be able to do with the software. For example,

User launches program and sees a blank drawing area and some buttons representing actions that could be taken.

This story doesn’t say anything about the buttons actually working, so that is not part of this user story. A user story for a button working might be something like,

User clicks the Rectangle button and can then draw a rectangle in the drawing area by clicking and dragging the mouse.

User stories are powerful in two important ways. First, they make it very clear how to test whether the story has been completed. Second, they keep the development team focused on the importance of meeting the needs of the user.

After the customer has suggested some user stories for the cycle, the development team will decide whether it is reasonable to complete them all in the time available. If not, the customer will withdraw some of the proposed stories until an achievable set of stories is agreed upon.

For this assignment you’ll play both the customer role and that of the development team. As a customer, the number of features completed will help determine your grade (and how much fun you have with the project). As a development team, you’ll have to do the work to implement the user stories.

At the START of each development cycle, you should write a short text document that lists the user stories that you plan to complete during that cycle.

To be turned in:

To turn in your user stories, at the beginning of EACH development cycle:

1. Your User Stories document must be a TEXT file named something like CycleNUserStories.txt, where N   is the cycle number (1, 2, or 3).
2. Place your CycleNUserStories.txt document in the Planning subfolder of your project.
3. In Eclipse, refresh if needed and commit the change.

Task Lists

This document should contain a list of tasks that you think you have to do to implement the user stories for the cycle. (Also include other major tasks done during the cycle like doing Swing Experiments.)

• Each task should be something that you think should take 1 to 6 hours.
• Each task should indicate who will do it, by when.
• If more than a single person is to do it, the task list should indicate when, where, and for how long they will meet to accomplish the task.
• For each task, include any notes that you think will be helpful to the team.
• Also include “integration” tasks — how will you integrate code written by separate teams or subteams? When, by whom?
• Also include “testing” tasks — how will you perform integration/system/acceptance tests of the code? When, by whom?
• Also include any Swing Experiments you do during the cycle.
• It is normal for the task list to change during the cycle — just commit the updated file to your repository whenever it changes.
• The exact format of this document is up to you, as long as it is a list of tasks and includes information like that indicated above. The purpose of this document is simply to help you organize your work, not to be a burden.

To be turned in:

To turn in your task lists, at the beginning of EACH development cycle:

1. Your Task List document must be a TEXT file or   a Microsoft Word document (your choice) named something like CycleNTaskList.txt or CycleNTaskList.doc or CycleNTaskList.docx, where N   is the cycle number (1, 2, or 3).
2. Place your Task List document in the Planning subfolder of your project.
3. In Eclipse, refresh if needed and commit the change.

Status Reports

At the END of each development cycle, you should write a short text document indicating either that you completed all of the user stories for the cycle or else listing any user stories the team planned to complete but was not able to. Briefly state any complications that prevented you from completing the stories, for example, “We underestimated how hard it would be to implement mouse dragging.” If you implemented any important features beyond your planned user stories, indicate so.

To be turned in:

To turn in your status report, at then end of EACH development cycle:

1. Your Status Report document must be a TEXT file named something like CycleNStatusReport.txt, where N   is the cycle number (1, 2, or 3).
2. Place your CycleNStatusReport.txt document in the Planning subfolder of your project.
3. In Eclipse, refresh if needed and commit the change.

Individual Reports

One of the hardest skills to develop in software engineering is how to estimate how long it will take to implement a given feature. According to the Personal Software Process (PSP), one of the best ways to being developing this skill is to:

1. For each feature you implement or task that you do, estimate how long you think it will take you to do that task.
2. Measure how long it in fact took you to do that task.
3. Note the difference between (a) and (b).

To this end, throughout the project, keep track of and record:

• Each major (1 to 6 hours) task (including non-programming tasks, like creating your UML class diagram) that you are planning to do
• How long you think it will take you to do that task
• How long it in fact took you to do that task

At the end of EACH cycle (including Cycle 0), list your records in a short TEXT file with 3 columns: one for each of the three bullets list above. After the last line, sum columns 2 and 3. For each line, indicate whether it was a whole-team activity, my yourself, with a partner, or (especially important) if it was pair programming. For example, someone's Individual Report for Cycle 0 might be:

			Design the user interface by doing a draft of the Screen Layout, whole team:                      1  1
			Begin the OO design by using CRC cards, whole team:                                               1  1
			Complete the Screen Layout draft, by myself:                                                      1  2
			Do the outline of the UML class diagram, whole team:                                              1  1
			Complete the UML for the VGFrame, Shape, Rectangle and Ellipse classes, with Husna:               3  2
			Do a Swing Experiment to learn about JSliders, pair programming with Nyimbo (NOT YET COMPLETED):  3  0
			Total:                                                                                           10  7
		

To be turned in:

To turn in your Individual Report, at then end of EACH development cycle (including Cycle 0):

1. Your Individual Report document must be a TEXT file named something like CycleNXXXIndividualReport.txt, where N   is the cycle number (0, 1, 2, or 3) and XXX   is your username.
2. Place your CycleNXXXIndividualReport.txt document in the Planning subfolder of your project.
3. In Eclipse, refresh if needed and commit the change.

Swing Experiments

You might have only one or two Swing Experiments or many, depending on the extent to which your GUI uses Swing classes that you have not yet experienced.

To be turned in:

Final Working Code

We’ll grade the version of your code committed to your repository at the final-working-code deadline. Your code should be appropriately-commented and should use good style, including (but not limited to) appropriate class, method, field, and variable names. No Eclipse warnings (or errors!) should remain for your final code.

If there are aspects of your classes that can be tested apart from the GUI, then you should provide JUnit tests for those features.

Some comments on Subversion and team projects:

Commit your code often. And don’t forget to update your code before working and before committing. The chances of SVN conflicts grow exponentially with the number of team members, but they decrease with the number of lines of code in the project. The net result is that you’ll have more trouble at the beginning of a project. For this reason it makes a lot of sense to take care to work on completely different classes in the beginning.

Team Evaluation

For each cycle (including Cycle 0), we will post a team evaluation survey on ANGEL. You will receive individual points for completing the survey. I will also use the survey results to help decide whether to give different assignment scores to different team members and to repair any dysfunctional teams. Perhaps most importantly, the survey results will help both you and me identify where you are doing well as a teammate and where you can improve.

Features

This QuickTime movie shows how the developers of OmniGraffle implemented the features below. You don’t have to implement the features the same way they did—I’d be amazed if you did—but hopefully the movie clarifies what a user could do with each feature.

Required Features

A successful program must include all of the following features:

• Ability to draw rectangles, lines, and ellipses.
• Ability to resize the program window.
• Ability to set border and fill colors before drawing a new shape.
• Ability to select and move any existing shape. Selection must be by clicking with the mouse, but moving can be implemented using buttons.
• Ability to change properties (size, colors) of any existing shape.
• Ability to move any existing shape to the front or the back of all other shapes.

Additional Features

Once your team completes the required features, you should try to complete as many of these additional features as time permits.

• Ability to select and delete any existing shape.
• Ability to select and duplicate any existing shape.
• Ability to draw regular polygons.
• Ability to zoom in and zoom out.

Bonus Features

If your team completes all of the required and additional features above, then you can implement some of these bonus features. I’ll only award bonus points for these if all of the required and additional features are also implemented correctly.

• Ability to group and ungrouped existing shapes, such that group can be manipulated as a single entity.
• Ability to move and resize shapes by dragging with the mouse.
• Ability to draw arbitrary polygons.
• Ability to select and rotate any existing shape. (See the AffineTransform class in the Java libraries.)
• Ability to Undo previous actions.
• Ability to Save and Load graphics and create New graphics.
• Other features that you find interesting… (Document them well).

Grading

The above section lists the features that your program is required to have and several potential additional features. This is still a fairly new project (and completely new to me), so I’m not sure what to expect. That said, here is my grading plan: First, compute the process score, which is 30 points based on:

• Quality of the non-code deliverables (listed in the table above)
• Did you follow XP practices?
• Quality of your code's documentation and style

• Successfully implements all the required features: 50 points (of 70).
• Successfully implements all the required features and most of the additional features: 60 points (of 70).
• Successfully implements all the required features, all the additional features, and some of the bonus features: 70 points (of 70).