SE2811
Software Component Design

This is an old version of this course, from Winter 2014-2015. 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 an 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 (Except possibly by deleting the enum Shape.ShapeType).

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 (Other classes are also available to browse individually). 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.

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 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 onese you do in the appropriate section of the report.

  • Implement the Factory Method Pattern for handling new shapes, and illustrate the above with a new shape type. 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 any errors from the UML diagrams submitted in Labs 1 and 2
  • 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...
  • 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
  • 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 (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.)

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.

Acknowledgement

This lab developed by MSOE faculty.