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.
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 code 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).
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 give different grades. A peer evaluation survey at the end of the project will help me to determine this. If the survey or my observations indicate the need, I may ask you to explain parts of your project to me.
Your SVN repository for this assignment is:
http://svn.cs.rose-hulman.edu/repos/csse220-200920-vgXY
where
XY
is your two-digit team number given in class. 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.
Milestone dates are listed in the table below. This rest of this section describes the artifacts due at each milestone. Follow the instructions carefully. Your team may want to print a copy of this document, highlight the key things to do, and check them off as you do them. Note that there will also be some small assignments relating to new class material during this time, but this project will be your main work for this course.
|
Pre-Cycle 1
Jan 26-28 |
Cycle 1
Jan 28-29 |
Cycle 2
Jan 29-Feb 2 |
Cycle 3
Feb 2–4 |
All due times are start of the class session unless otherwise noted.
| Wednesday, Jan 28 |
CRC Cards, UML Class Diagram, Cycle 1 User Stories. Also research Swing classes that you want to use, and write small programs to try them out. Put those programs in the swingExperiments package in your
repository |
| Thursday, Jan 29 | Cycle 1 Status Report, Cycle 2 User Stories |
| Monday, Feb 2 | Cycle 2 Status Report, Cycle 3 User Stories |
| Wednesday, Feb 4 | Cycle 3 Status Report, Final working code |
| Wednesday, Feb 4 (midnight) | Team evaluation survey |
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 make some sketches of potential screen layouts for your project. See the Overview section above and the Features section below for additional information on the responsibilities of your program.
You must draw your UML Class Diagram using Violet, available here. Choose File → New → Class Diagram to get started.
Put your team number on the back of each of your completed CRC Cards and hand them in at the start of class. We’ll check them quickly and hand them back to you. To commit your UML Class Diagram, you’ll add it to your Eclipse project. In Violet, choose
Save As
to save the file to your
Eclipse workspace → VectorGraphics → Planning
folder. Within Eclipse, right-click the
VectorGraphics
project folder in the
Package Explorer
view, and choose
Refresh. Your Violet file should appear under
Planning. Now right-click the project folder again, and choose
Team → Commit. Be sure the Violet file is checked so it is added to the repository. Enter an appropriate message and complete the commit.
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 commit a text document to your project repository listing the user stories that you plan to complete during that cycle. You can use
File → New → Untitled Text File
to add a new text file to an Eclipse project. Save your file to your
Planning
folder with a name like “Cycle
N
User Stories.txt”, where
N
is the cycle number. Commit the file to your repository.
At the end of each development cycle, you should commit a text document to your project repository 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.”
Save your file to your
Planning
folder with a name like “Cycle
N
Status Report.txt”, where
N
is the number of the cycle just completed. Commit the file to your repository.
We’ll grade the version of your code committed to your repository at the final-working-code deadline. 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.
If there are aspects of your classes that can be tested apart from the GUI, then you should provide JUnit tests for those features.
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 carefully work on completely different classes in the beginning.
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. Perhaps most importantly, the survey results will help me identify where you are doing well as a teammate and where you can improve.
The subsequent subsections list the features that your program is requird to have and several potential additional features. This is still a fairly new project, so I’m not sure what to expect. At this point, my thought is that an “A” project would include all of the required features and several (perhaps all) of the additional features. A team that delivers all of the milestones, well done and on time, and produces a project that correctly implements all the required features will earn at least 75% on this assignment.
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.
A successful program must include all of the following features:
Once your team completes the required features, you should try to complete as many of these additional features as time permits.
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.
AffineTransform
class in the Java libraries.)