CSSE 220 – Object-Oriented Software Development
Capstone Team Project: VectorGraphics

For this project you will design and implement software 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 (my personal favorite) OmniGraffle.

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.

Your project has three categories of features:

Required Features

A successful program must allow the user to do ALL of the following:

• Draw rectangles, lines, and ellipses.
• Resize the program window.
• Set border and fill colors before drawing a new shape.
• Select and move any existing shape.
  • Selection must be by clicking with the mouse, but moving can be implemented using buttons.

Additional Features

For a higher grade (see the Grading Rubric below), your program must also allow the user to do some of the following:

• Select and delete any existing shape.
• Select and duplicate any existing shape.
• Draw regular polygons.
• Change properties (size, colors) of any existing shape.
• Move any existing shape to the front or the back of all other shapes.
• Zoom in and zoom out.

Bonus Features

A top-notch project (see the Grading Rubric below) will also allow the user to:

• Run the program at the same time that other users are running the program, all on the same set of graphics.
• Save and Load the graphics window and create a New graphics window.
• Group and ungroup existing shapes, such that the group can be manipulated as a single entity.
• Move and resize shapes by dragging with the mouse.
• Draw arbitrary polygons.
• Select and rotate any existing shape. (See the AffineTransform class in the Java libraries.)
• Undo previous actions.
• Draw UML class diagrams easily. (In particular, have arrows that stick to components.)
• Other features that you find interesting…

Two Rules for Teaming / Learning

Team Grading

See Team Score and Individual Score for how the team is graded and how individual grades may be more or less than the team's grade. Note here that:

Those who don't obey the two rules for an appropriate learning experience (in Team Participation, to the left) 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.

Also:

• Those who don't “carry their weight” or otherwise shirk their individual responsibilities 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 EARLY IN THE PROJECT 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

    http://svn.cs.rose-hulman.edu/repos/
    csse221-201020-vg-TeamXX

Check out the VectorGraphics project from this repository.

All work should be placed in this project folder and committed back to your repository.

• Exception: If you do other short projects (a) to learn how something in Swing (or whatever) works, or (b) as a spike solution to better understand the complexity of a problem, feel free to include those projects in your TeamXX repository (alongside the CapstoneProject folder, not beneath it).

After you check out your VectorGraphics project, examine its Planning folder and note that templates for all of your non-code documents are already in your VectorGraphics project, beneath Planning.

Recall the advice on using version control in teams. FIX ME - DO THIS LINK.

Extreme Programming

You will use many of the Rules and Practices of Extreme Programming. In particular, you will use, in one form or another, all the indicated rules/practices on the image to the right (which is taken from the preceding link).

For pair programming, each team member should do at least one pair programming session per cycle.

Additionally, you should use documented stubs throughout (i.e., document each method while the method has a stub, THEN write the method's code).

Where practical, you should include unit tests and do test-driven programming (where you write the unit test before implementing the unit).

In-class time

You will usually have about 1/4 of each of our sessions (i.e., about 25 minutes) to work on your team project.

• We'll do other, unrelated-to-the-project, individual work in the rest of each session.

• 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.

Team meetings and communication

Schedule regular out-of-class meetings, at least once a week. Recall the advice on conducting Effective Meetings. FIX ME - I NEED TO DO THIS LINK.

You will have a Stand-Up Meeting at each class session.

Reach agreement on how you will communicate with each other between meetings:

• Exchange email addresses and phone numbers.
• Agree how often you will check your email, during the week and over the weekend.
• Decide if you want to use other modes of communication, e.g. Instant Messenger (IM).

Release Plan

The Release Plan specifies, for each scheduled release of the software, which User Stories will be implemented in that release. We require you to have 4 cycles (releases)

At the beginning of each cycle, you review your Release Plan and possibly revise which user stories are to be implemented in that cycle.

• That is part of how you retain agility.

Find the template for your first Release Plan document in Planning/Cycle1.

• After the first cycle, you will copy your Release Plan from the previous cycle into a new Release Plan document for the forthcoming cycle.
• That makes it easy for readers to see the history of revisions to your Release Plan and learn from that history.

User Stories and Acceptance Tests

Your Release Plan document should contain your User Stories. From the Rules of Extreme Programming (XP) at www.extremeprogramming.org/rules/userstories.html:

User Stories are written by the customers as things that the system needs to do for them … They are in the format of about three sentences [for us, 1 to 3 sentences] of text written by the customer in the customer’s terminology without techno-syntax … Each story will get a 1, 2 or 3 week [for us, 1, 2 or 3 hours] estimate in “ideal development time” [includes testing, but no meetings, email or other interruptions].

• You should have 30 plus or minus 15 User Stories. (Real XP projects might begin with 80 plus or minus 20.)
• Each User Story should have a 1, 2 or 3 hour estimate in ideal development time. (Real projects would have 1, 2 or 2 week time estimates.)
  • If a User Story needs more time, break it down into sub-stories.
  • If it requires less than 30 minutes, lump it with another User Story.
• Use your Features as a starting point for generating your User Stories.

Note that User Stories are 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.

If the user can't tell by RUNNING the program whether the User Story was satisfied, then it is NOT a User Story.

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.

User stories are powerful in two important ways.

• First, they make it very clear how to test whether the story has been completed. As such, they generate what is called Acceptance Tests.
• Second, they keep the development team focused on the importance of meeting the needs of the user.

Place your User Stories in the Planning/Cycle1/ReleasePlan-ForCycle1.docx file that we provided, at the indicated place in that file.

Grading Rubric: Your User Stories must be of the appropriate number (else no credit) and use correct grammar and spelling (else score reduced by up to 50%). Additionally:

• 40% — The User Stories make sense with no context other than your Screen Layout Sketch.
• 40% — The User Stories describe the project adequately.
• 20% — The User Stories' time estimates are not unreasonable.

Screen Layout Sketch

One way to specify a project is to list its Features or User Stories, as described above. Another way is to provide a Screen Layout Sketch that depicts the user interface for your project.

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.
• Two or three pages that show the main screen and major subscreens are probably enough, if you have annotations to indicate submenu's, dialogs and other screens.

Place your Screen Layout Sketch in the Planning/Cycle0 folder, replacing the ScreenLayoutSketch.pdf file that is already there as a stub.

• If you did your sketches on paper (that's fine!), scan them. (There is a nice scanner in the CSSE lab, Moench F-217.)
• You probably have PDF Creator on your computer; if not, there are plenty of free PDF writers available.

Grading Rubric:

• 50% — The Screen Layout Sketch makes sense with no context other than your Elevator Statement.
• 50% — The Screen Layout Sketch describes the user interface of your project adequately.

CRC Cards

Your project must incorporate a good object-oriented (OO) design, as described in your textbook (Chapter 8, sections 1 and 2, and Chapter 12). To come up with this design you will:

• Use CRC Cards to migrate from your User Stories to the classes that will implement those User Stories. Your user stories will generate the responsibilities.
• From your CRC Cards, develop a UML Class Diagram that shows the classes and their relationships.
• At the start of each development cycle, flesh out the details on your UML Class Diagram of the classes that are relevant to that cycle.
• Refactor whenever appropriate, updating your UML Class Diagram as you do so.
• Apply the principles of High Cohesion and Low Coupling as practical.

CRC Cards are part of Extreme Programming and described at www.extremeprogramming.org/rules/crccards.html. Briefly:

• CRC stands for Class, Responsibilities and Collaboration.
• Use index cards for the CRC Cards. Each index card has:
  • a class name (which should be a noun) on the top,
  • a list of responsibilities (which should be verbs), written on the left-hand-side, and
  • a list of the collaborators needed to carry out the responsibilities, written on the right-hand-side.

Place your CRC Cards in the Planning/Cycle0 folder, replacing the CRCCards.pdf file that is already there as a stub.

• You can scan your cards (there is a nice scanner in the CSSE lab, Moench F-217) or type them into a document, your choice.
• You probably have PDF Creator on your computer; if not, there are plenty of free PDF writers available.

Grading Rubric: Your CRC Cards must be of the appropriate number and make sense given the context of your Screen Layout Sketch, Features and User Stories (else score reduced by up to 50%). Additionally:

• 20% — You have enough classes, that is, most of the User Stories can be implemented by your CRC Cards.
• 20% — You have enough detail in your classes, that is, most of the responsibilities listed can be implemented with help that the listed Collaborators are capable of giving.
• 10% — Your class names are nouns and your responsibilities use verbs.
• 20% — Your design has classes that have high cohesion.
• 10% — Your design has classes that have low coupling.
• 20% — Overall, your design is good object-oriented design.

UML Class Diagram

After you have completed your CRC Cards, use them to generate a UML Class Diagram, as described at www.agilemodeling.com/artifacts/classDiagram.htm (and at many other places as well).

Here is a sanity check for your UML class diagram. Does it:

1. Have a class (possibly called Main) with the required main method?
2. Have classes for all visual elements, e.g. the frame, all panels, all buttons?
   • You might implement some of the buttons as anonymous classes, but it would be wise to include them as full-fledged classes on your UML class diagram, perhaps with a Note indicating that the button is implemented as an anonymous class.
3. Have IS-A arrows to JBlah 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. Have every object created by something?
7. For each development cycle, have the necessary details (attributes and properties) for that development cycle?
8. For each development cycle, for each property relevant to that development cycle, have ALL the associations necessary to implement that property?

You must draw your UML Class Diagram using UMLet.

Find and use an empty template for your first UML Class Diagram in Planning/Cycle1.

• After the first cycle, you will copy your UML Class Diagram from the previous cycle into a new UML Class Diagram for the forthcoming cycle.
• That makes it easy for readers to see the history of revisions to your UML CLass Diagram and learn from that history.

Grading Rubric: Your UML Class diagram must be readable (but need not be optimal in terms of minimizing line-crossings and so forth); it must use correct correct notation; and it must be up-to-date with your code (else no credit). Additionally, for all of the User Stories in the upcoming cycle:

• 10% — You have enough classes, that is, all those User Stories can be implemented by the classes in your UML Class Diagram.
• 10% — You have enough detail in the attributes of your classes to implement those User Stories.
• 20% — You have enough detail in the operations of your classes to implement those User Stories.
• 20% — All of the operations relevant to those User Stories can be implemented with help that the associated objects are capable of giving.
• 5% — Your class names are nouns and your operations use verbs.
• 5% — Your design has classes that have high cohesion.
• 5% — Your design has classes that have low coupling.
• 5% — Where practical, you provide interfaces to allow others to interface their code with yours.
• 10% — Overall, your design is good object-oriented design.
• 10% — Overall, your UML Class Diagram is complete enough to turn to coding.

Task List

At the beginning of each development cycle, AFTER you have finalized the User Stories to be implemented in that cycle, make a Team Task List for implementing those user stories.

This list should contain all the tasks that you think you have to do to implement the user stories for the cycle. Each task should include:

• A one-sentence description of the task, with any other notes you think will be helpful to the team.
• How long you think it will take you to complete that task, to the nearest half-hour.
  • If more than 3 hours, break it down into subtasks. If less than 15 minutes or so, combine it with another task.
• Who will do the task. (This can be more than one person, e.g. if pair programming.)
  • If more than one person, it would be wise to indicate when and where they will meet to do the task.
• When the task should be completed by.
• The status of the task, e.g. not-started, in-progress, completed, cancelled, modified to ...
• After the task is completed (or cancelled), indicate how long it actually took to complete the task, to the nearest half-hour.
  • So for every task, keep track of how long you work on that task.

• Make sure that you are reporting ALL your work on the project.
• Consider spending more time on the project out of class.

Be sure to include:

• Specification tasks, like updating your Release Plan at the beginning of each cycle.
• Design tasks, like updating your UML Class Diagram prior to coding.
• Implementation tasks, like implementing one of your User Stories.
• Integration tasks — how will you integrate code written by separate teams or subteams? When, by whom?
• Testing tasks — how will you perform integration/system/acceptance tests of the code? When, by whom?
• Exploration tasks like implementing a Spike Solution to a problem whose complexity you are having difficulty judging.

You will have a separate Team Task Plan document for each cycle; find and use the template for your Cycle 1 Team Task Plan in Planning/Cycle1, and similarly for Cycles 2 and 3.

It is normal for the task list to change during the cycle — just commit the updated file to your repository whenever it changes.

Grading Rubric: Your Team Task List must have enough tasks to implement all of the User Stories in the current cycle (else at most half credit) and it must appear that your team used your Team Task List throughout the cycle (else at most half credit). Additionally:

• 25% — There is enough detail in the descriptions of the Tasks for them to be carried out, given the context of your User Stories and UML Class Diagram.
• 25% — Your team appears to have taken seriously the requirements of estimating how long each Task would take.
• 25% — Your team appears to have taken seriously the requirements of measuring how long each Task actually took.
• 25% — Your team appears to have taken seriously the requirements of documenting who will do the task, when it will be completed, and its status.

Working Code

At the end of Cycle 1, commit your Working Code with a comment Release 1; and similarly for subsequent cycles. Your released code should:

• compile and run,
• be documented appropriately, with the html Javadoc generated,
• contain NO compiler warnings,
• include only genuine TODO's (i.e., none that are accidentally left behind),
• be written using documented stubs (i.e., document each method while the method has a stub, THEN write the method's code), and
• use good style, as described by java.sun.com/docs/codeconv and enforced in part by control-shift-F in Eclipse.

  • Good style includes (but is not limited to) self-documenting class, method, field and variable names; introducing local variables as needed but not more than needed; introducing fields as needed but not more than needed; avoiding global variables except possibly for static constants; and reasonably-sized methods (generally not more than about 15 lines).

You should strive to pass all your acceptance tests for this cycle (as generated from your User Stories), but it is OK if your code does not do so.

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

Grading Rubric:

• Subtract 20% of your possible score on this deliverable for every violation of the qualities listed above.

Status Report

At the END of each development cycle, complete the Status Report for that cycle. It should indicate:

• The User Stories that you expected to accomplish in this cycle (copy-and-pasted from your Release Plan).
• An indication of which User Stories you did NOT complete as planned.
  • It would be wise to include any relevant explanations, e.g. “Moved this User Story to the next cycle because we need to learn more about slider bars.”
• An indication of any noteworthy additional accomplishments (beyond the planned User Stories) in this cycle.

You will have a separate Status Report document for each cycle; find and use the template for your Cycle 1 Status Report in Planning/Cycle1, and similarly for Cycles 2 and 3.

Grading Rubric:

• 100% — You successfully list all the User Stories that were planned but not implemented in the cycle.

Evaluation of Team Performance

For each cycle (including Cycle 0), I will post a survey on ANGEL called Evaluation of Team Performance. The surveys for the first three cycles will be brief; the survey for the final cycle will be longer. The surveys will help:

• Diagnose any team dysfunction while there is still time to do something about it.
• Adjust individual scores appropriately from the team score (see the Grading Rubric below).
• Identify where you are doing well as a teammate and where you can improve.

Each person does the Evaluation of Team Performance at the end of each cycle; it is NOT a team activity.

Individual Reflection

Public Demonstration

• 20% — Your demo communicates the quantity of your work.
• 20% — Your demo  communicates the quality of your work.
• 30% — You successfully answer technical questions about your project.
• 30% — You successfully answer questions about your teaming experience.

Your Team Score is:

Your Individual Score (that is, your final grade on the project) is your Team Score, but REDUCED if you are NOT:

• participating fully in all major aspects of the project
• understanding (at an appropriate level) everything your team turns in
• carrying your weight on the team
• following the required process, including (but not limited to) pair programming at least once per cycle and using documented stubs in all your coding.
• helping your teammates do the above (in part by answering the Evaluation of Team Performance survey candidly)
• maintaining your Individual Task List appropriately

If you aspire to a higher level of achievement than your teammates do on this project, your team should talk with me early in the project to see how we can structure the project for this.