SE2811
Software Component Design

This and future labs will be teams-of-two labs.

Objective

The objective for this lab is to demonstrate the Decorator pattern by decorating shapes to add functionality. In particular, the user will be able to create a variety of shapes (filled, solid, rectangular, ellipse) by selecting menu options. This mix-and-match functionality will be achieved with the decorator pattern.

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 to allow shapes to be decorated with outlines and labels without changing your implementation of Shape, AbstractShape, Rectangle, or Ellipse (Except possibly by deleting the enum Shape.ShapeType).

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

Begin by downloading the zipfile containing the base application.. (Individual files from this zip are available for easy reference here).

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

Details

Once the basic program is working, implement the Decorator pattern by adding the necessary classes. Study the class diagram carefuly to determine which classes or interfaces you want to play each role in the pattern.

The ShapeManager could benefit from employing the Factory Method pattern. For excellent credit, 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. You may even want to include 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.

Excellent Credit Ideas

Here are ideas of some things you might like to try to go "above and beyond". Be sure to document which ones you do in the appropriate section of the report. For those extra features which do not explicitly mention a design pattern, be sure to describe what they taught you about design patterns.

  • Implement the Factory Method Pattern for handling new shapes, and illustrate the above with a new shape type. (The simple factory idiom does not really help here — createNewShape is nearly a simple factory anyway.) You could possibly even load new shape types with a ServiceLoader (I have not used Service Loaders before)
  • Further demonstrate the power of decorators by adding another decorator to the shape. In your report, comment on whether this ended up demonstrating the utility or dis-utility of the decorator pattern
  • Implement moving/resizing shapes
  • Implement deleting shapes
  • Add the ability to insert images
  • To use the decorator pattern more cleanly, you may wish to draw all shapes as polygons, and have the concrete shape classes simply specify which polygon to use.
  • You may have other ideas about changes you would like to make that require a change to some of the core classes. As long as you can implement the basic decorator pattern without modifying the core classes, it is OK to change them for extensions or improvements.

Submission Instructions

UML Class Diagrams

  • Correct Avoid repeating any errors from the UML diagrams submitted in previous labs that have been returned to you.
  • All classes should have at least one connector to another class on the diagram
  • If a class is used in many places, lines should indicate the most significant places. Also, you may want to see if you can reduce coupling...
  • Reduce "visual noise:" Don't run lines over classes, and avoid running lines over other lines where possible.
  • Useage lines should often be annotated with "creates" or "manages" or "uses" or other such remarks.
  • All instance variables relationships should have the variable name and access type marked on the arrow in the diagram
  • If the multiplicity is something other than 1, this should be marked on the diagram as well.
  • 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 work?

Report

You will write text-file report for this lab, following this template (right-click and select "save link as").

In your text file, please limit line length to 120 characters or do not insert line-breaks within your paragraphs at all.

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

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, describe key improvements you made, mentioning them in the excellent credit section as well.

Refer to your main UML diagram to illustrate what you describe in this section.

Decorator Pattern

Describe how you implemented the decorator pattern. Refer to your main UML diagram to describe how this pattern helped (or hindered) you to organize your code. This may be two or three paragraphs.

Excellent Credit Features

List your excellent-credit features in a bulleted list. Then describe each with a sentence or paragraph. If you incorporated new design patterns, describe them using your main UML diagram.

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

Feedback on Lab

Provide comments on what you liked or could be improved about the lab.

Source Code

Refactor your code into the foggp_passepartoutj package, replacing the usernames with the usernames of your team members. Zip this package into a zip file. When unzipped, it should produce the refactored top-level foggp_passepartoutj directory, where foggp_passepartouj is replaced by the same. Submit this zip file in the form below.

(Announced verbally before the deadline, included here after the deadline) Be sure to comment your code properly, and include an @author tag on every class (every method if you collaborated on a class).

Acknowledgement

This lab developed by MSOE faculty.

Submission Form for Dr. Yoder

You should submit your solution only once, so be sure you are happy with your solution before you submit it.