SE2811
Software Component Design

This is an old version of this course, from Winter 2013-2014. A newer version is avaliable here.

Objective

The objective for this lab is to demonstrate the Decorator pattern by decorating shapes to add functionality. It may sound somewhat similar to a SE1021 lab, but it's very different, I promise!

Outcomes Addressed

  • understand and apply object-oriented design patterns
  • understand the use of UML in the design documentation process
  • be able to design and implement small software components and systems
  • be able to use computer-aided software engineering (CASE) tools in the design process

Assignment

Begin by creating an application following the UML diagram below (without the Decorator pattern). This application allows a user to draw filled Rectangles and Ellipses. Once the basic application is working, incorporate the Decorator pattern allow shapes to be decorated with outlines and labels without changing your implementation of Shape, AbstractShape, Rectangle, or Ellipse.

The class diagram representing this application's initial structure is as follows:

You may begin by downloading the zipfile containing the base application. or just DrawingProgram UI. The full zip is little more than the UML diagram with the getters & setters implemented for the Shape Manager (and the UI linked in the previous sentence). If you use the full zip, be sure to remove any unused methods from your code. Sometimes IE throws in extra methods which are uneeded.

Corrections to starting code:

  • Please do not implement Singleton in the ShapeManager. I intended to remove this. If you have implemented it, do not reference it from anything but the GUI.
  • The TODO comment for the "outline" check-box feature is written wrong, should not be copied from above.

Refer to the in-code javadoc comments for more details concerning how the methods AbstractShape and ShapeManager should function.

Details

Once the basic program is working, implement the Decorator pattern by adding the necessary abstract & concrete classes.

Note that ShapeManager could benefit from employing the Factory Method pattern. For extra credit (3 pts), enhance the ShapeManager so that it does not make explicit references to concrete shape classes. You will probably need to add more interfaces/classes to accomplish this. Further credit (1 pt) for including a new shape class to demonstrate the pattern

Should the ShapeManger also implement the Observer interface? After all, it's observing UI events and creating shapes as a result of mouse actions. Or is it a Subject? After all, ShapeManager notifies the UI whenever a shape is created or destroyed. Consider those questions for now; we'll return to them in a subsequent assignment.

'Extra'? Credit

6 pts
Implement the Factory interface for handling new shapes
1 pt
Illustrate the above with a new shape type
6 pts
Further demonstrate the power of decorators by adding another decorator to the shape.
1 pt
In your report, comment on whether this ended up demonstrating the utility or dis-utility of the decorator pattern
3 pts
Implement moving/resizing shapes
1 pt
Implement deleting shapes
1 pt
Add the ability to insert images
3 pts
Add the ability to save and load your drawing
other
Suggest your own, and I'll post it here. general principle: If the improvement illustrates a pattern, it will be worth 6 pts, with perhaps a bonus point for extending it. If not, it will be worth 3 pts max.

Submission Instructions

Please wait until you get your Lab4 back before submitting this assignment. I hope to have them graded in the next couple days. You will receive feedback on how to improve your UML diagrams.

In the meantime, a couple of general principles for UML class diagrams:

  • All classes should have at least one connector to another class on the diagram (or else be in separate figures)
  • Useage lines should often be annotated with "creates" or "manages" or "uses" or other such remarks.
  • If a class is used in multiple places, it should have lines to at least the most significant users holding a reference to an instance of the class, or all methods holding an instance of the class, if that is practical.
  • UML is an art. The goal is to communicate structure. Do you get a sense of the structure of your code when you look at your masterpiece?

Report Format

You will submit this lab in report format with included zip through the web form. (So you will submit a pdf and a zip to the webpage.)

Your report should include the following sections: (without the explanatory text, unless you find that helpful)

Include placeholders for the UML diagrams until your code is stable so they reflect the final version.

Introduction

Describe the lab in 1 or 2 sentences for someone who hasn't heard of it. You can assume that I'm your audience for the rest of the report.

Main Application

Describe how you implemented the main application. Highlight challenges you overcame and anything you found interesting about the general application structure before implementing the decorator pattern. You are free to modify the structure of the application. If you do so, describee key improvements you made.

Use a UML diagram to illustrate what you describe in this section. If you didn't make any changes beyond the basic requirements, this section may only contain one paragraph of text.

Decorator Pattern

Describe how you implemented the decorator pattern. Reference a UML diagram (either from the previous section, or "zoom in" on the relevant classes) and describe how this pattern helped (or hindered) you to organize your code. This may be two to three paragraphs.

Extra Credit Features

List your extra-credit features in a bulleted list. Then describe each with a sentence or paragraph. If you incorporated new design patterns, describe them using a UML diagram (again previous or newly inserted).

Missing Features

Describe any missing requirements in a bulleted list. Any discussion of these is optional.

Conclusions

Based on this lab, would you use the decorator pattern again (after this class)? "Yes", "no", "maybe yes", and "maybe no" are equally legitimate, just support your answer. (And make it clear whether you chose maybe yes or maybe no by following proper essay style. Ask me for details.)

Acknowledgement

This lab developed by MSOE faculty.