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 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).
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.csse.rose-hulman.edu/repos/csse220-201030-vg-teamXX
where XX is your 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.
| Cycle | Due Date |
Deliverables
(due at start of class on the given date) |
|---|---|---|
| Cycle 0 | Fri, April 30 | CRC Cards, UML Class Diagram, Cycle 1 User Stories |
| Cycle 1 | Tues, May 4 | Cycle 1 Status Report, Cycle 2 User Stories |
| Cycle 2 | Tues, May 11 | Cycle 2 Status Report, Cycle 3 User Stories |
| Cycle 3 | Fri, May 14 | Cycle 3 Status Report, Cycle 4 User Stories |
| Cycle 4 | Tues, May 18 | Cycle 4 Status Report, Final working software |
| — | Weds, May 19 | Project Presentation |
| — | Thurs, May 20 | 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 do two things. First, decide as a team which features sound most interesting to do and which you'll want to do first (cycle 1). Second, 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 UMLet.
Scan your CRC cards and save the images to your Eclipse workspace → VectorGraphics → Planning folder, replacing the existing
Cycle 0 CRCCards.pdf document. (There is a scanner in F217 that you can use for this purpose. Instructions are taped to the table by the scanner. Contact Darryl Mouck, F205, if you have questions about the scanner.)
To commit your UML Class Diagram, you’ll also add it to your Eclipse
project, replacing the existing Cycle 0 UML.uxf document. 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. Now right-click the project folder again, and choose Team → Commit. Be sure the
UML file and your CRC Card images are checked so they are 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.
Each user story should have an estimate in ideal development time (likely between 30 mins and 4 hours). Calculate the total estimated time for this cycle and include it at the end of the list.
At the start of each development cycle, you will commit a text document to your project repository listing the user stories that you plan to complete during that cycle.
You can use the existing documents in your Eclipse project, in the Planning folder, named “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 will commit a text document to your project repository that lists the user stories and estimated times, then add the actual time you spent on each. Indicate either that you completed all of the user stories for the cycle or else list 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.”
Modify the documents named “Cycle N User Stories.txt”, where N is the cycle number, in the Planning folder.
Commit the file to your repository.
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.You should be using good process as you go. Thus, for each cycle, your code must run, have good style and complete documentation, and have no other warnings.
You must also complete the brief evaluation in ANGEL identifying areas of improvement for your team.
We’ll grade the version of your software committed to your repository at the final-working-software 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 according to our standard Eclipse preferences for CSSE 220.
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.
Your team will give a 10 minute presentation on your project, which will be open to the Rose-Hulman community. Your goals for this presentation are:
Every team member should play a significant role in the delivery of your presentation.
Keep in mind that all of us have implemented the same basic project, so you won’t have to spend much time describing the basics of the project.
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. Along with this is an individual reflection. It helps you introspect on what went well in the project and how you can do even better on your next project. You will be graded on the thoughtfulness of your answers.
The subsequent subsections list the features that your program is required to have and several potential additional features. An “A” project would include all of the required and 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 70% on this assignment.
The subsequent subsections list the features that your program is required to have and several potential additional features. At this point, my thought is that an “A” project would include all of the required and 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 70% 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.)