Vector Graphics

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. This QuickTime movie shows how the developers of OmniGraffle implemented the features at the bottom of this document.

Administrative Background

Team Assignment

This is a team assignment. My intention is not that you “divide and conquer” as much as that you have people to talk with as you write and test this program.

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 something 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).

Subversion Repository

Your SVN repository for this assignment is:

    http://svn.csse.rose-hulman.edu/repos/csse221-201110-vectorgraphicsX
where X is defined here. You should check out the VectorGraphics project from this repository, and all subsequent work should be placed in this project folder and committed back to your repository.

Deliverables

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

Project Schedule and Milestones

Due Date Deliverables
(due at start of class on the given date)
Thursday, Sept 30 CRC Cards, UML Class Diagram, User Stories
 Monday, Oct 4 Working software

CRC Cards and UML Class Diagram

You must use the object-oriented design technique discussed in the book and in class to generate CRC Cards and a UML Class Diagram for your project. Name your class with the main() method Main.

Before brainstorming candidate classes, you will probably find it helpful to do two things. First, decide as a team which features (see Features below) sound most interesting to do and which you'll want to do first. Second, make some sketches of potential screen layouts for your project.

You must draw your UML Class Diagram using UMLet.

To be turned in:

Turn in your CRC index cards to your instructor.

To commit your UML Class Diagram, you’ll also add it to your Eclipse project, replacing the existing UML.uxf document. Save the file to your Eclipse workspace → VectorGraphics → Planning  folder. Then commit, being sure the UML file is checked so it is added to the repository.

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.

To be turned in:

In the Planning folder, use the file named “User Stories.txt”. Commit the file to your repository.

Working Software

Your code should be well-commented and should use appropriate class, method, field, and variable names. No Eclipse warnings should remain for your final code according to our standard Eclipse preferences for CSSE 221.

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 program as a group or to carefully work on completely different classes in the beginning.

Team Evaluation

I will post a team evaluation survey on ANGEL. You will receive individual points for completing the survey. Usually all team members will receive the same score for this assignment. But if there is ample evidence that one person did not fully participate in the learning and the doing, I reserve the right to assign different scores to different team members. If the survey or my observations indicate the need, I may ask you to explain parts of your project to me. Perhaps most importantly, the survey results will help me identify where you are doing well as a teammate and where you can improve.

Grading

Design: 20% Your design must include polymorphism (talk to us if you don't see a good place to use this in your design)

Required features: 60%

Additional features: 20+%

Features

Required Features

A successful program must include all of the following features:

Additional Features

Assuming you complete the required features, you should complete two additional features to earn an A (you can choose to do more to balance points lost on design).