JavaDrawingProgramDesign

Objectives Addressed

• understand the use of UML in the design 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

Overview

The purpose of this lab is to design and implement a small software application. The application will be a simple drawing program in the spirit of Microsoft Paint and other similar applications. The design of the program will follow a sound design process as an example, and provide an opportunity implement various design patterns in future assignment. This application is intended to build on work done for the PolymorphismExercise.

Problem Statement

Gather Requirements

This is the first step of our process. We draw upon our knowledge of other drawing programs and arrive at the following list of requirements.

1. Assume implementation using Java Swing
   • Note: We normally avoid making things like this a requirement. However, in this case it will make our design efforts a little more straightforward if we establish this now.
2. Support drawing of
   1. Line segments
   2. Ellipses (note, the PolymorphismExercise used circles instead of ellipses; since ellipses are the more general case we will need to update our previous work)
   3. Rectangles
   4. Triangles
3. Selectable fill for polygons – solid colors
4. Selectable line/outline colors
5. Load/Save drawings
6. Erase drawn shape
7. Copy / Paste objects (we'll keep this one in mind but not pursue it at this time)

Storyboard the User Interface

Based on the requirements and our knowledge of similar drawing programs, we arrive at the following mockup of the user interface. The old addage of "a picture says a thousand words" applies. It would be difficult to verbally describe exactly how we would like the user interface to appear without sketching it.

Figure 1. Storyboard of user interface for drawing program.

Create Domain Model

Based on the requirement and the storyboard, we should be able to start identifying objects in our system. We will also rely on our knowledge of Java Swing as a guide, but we do not yet care too much about types. Some examples or the domain objects we pick out of the storyboard are:

• The main application frame
• The menu bar at the top of the frame
• The toolbar for shape and color selection
• The drawing canvas
• The shape history

We can use UML notation to establish a basic model of how these objects are related. Keep in mind, these are objects we are talking about. When we are done we will have a good blueprint for these objects. That blueprint will then be considered the type. So, we can view this domain model as a very preliminary class diagram.

Figure 2. First-pass domain model for drawing program.

Use Case Modeling

Now we want to capture exactly how the user will interact with the application. While it is obvious that we want to draw with the mouse, that statement alone does not capture enough detail. Of course we do not want to be burdened by too much detail either. We want to be sure to reference objects in our domain model by name when different objects interact. This will help us tie our use cases directly to our design. Use cases should address what happens (an event), what happens next (the response), and what else might happen (an exception). Some other tips for use cases:

• Use cases should be expressed in the context of the domain model
• Use cases should use active voice and present tense
• Use cases should describe event/response flow between the user and the system

Candidate Use Cases

Here is a list of possible use cases we could write for this application.

1. User draws a shape
   • Question: Is this specific enough? Do we need a separate use case for each shape type?
2. User selects shape/line color/fill color
   • Question: Are these similar enough?
3. User erases a drawn shape
4. User loads a drawing
5. User saves a drawing

Example Use Case

Here is one use case example. While opinions vary on elements of a use case, in general, we need to know the state of the system at the start of the use case (preconditions), and then will want a chronological list of the event/response flow. Ideally, preconditions will result from other use cases and can be traced back to when the program was initially executed.

User Draws a Rectangle (let's consider a specialized version of UC1 and then see if we can generalize it)

Preconditions: Rectangle is selected as the current shape (UC2), valid line and fill colors are selected (UC2)

Normal Flow

1. User left-clicks and holds on the Canvas on starting vertex of new Rectangle.
2. User drags mouse. Canvas draws a preview rectangle between starting coordinates and current mouse coordinates.
3. User releases left button. Canvas draws final Rectangle between starting coordinates and location of mouse release. The Shape History updates the list of drawn shapes.

Exception Flow

1. User releases mouse button prior to dragging: Use case terminates.
2. User drags mouse off Canvas: Use case resumes when mouse pointer returns to canvas area.
3. User releases mouse button after dragging off Canvas: Preview rectangle removed and use case terminates.

Robustness Analysis

The use cases deal with user interaction, but clearly there are various events and responses going on behind the scenes. We could attempt to address that by making the use cases more detailed, but it might be a better approach to create a robustness diagram, which is very similar to a UML collaboration diagram, and uses three types of objects - boundary objects, entity objects, and controllers. Again, the robustness diagram should be generated within the context of the domain model.

Note that in the sample use case above, the user only interacted with the Canvas and later with the Shape History. For purposes of the robusteness diagram we are going consider the Canvas and Shape History to be a boundary objects. In most cases, each object from the domain model will be considered either boundary objects or entity objects. Controllers will represent the behavior we established in the use case.

Figure 3. First-pass robustness diagram.

Looking at this diagram we notice that the Shape History, which will probably be some type of GUI element, such as Swing's JList, appears to be responsible for containing our drawn shapes. This would seem to be mixing the business logic of maintain shapes with the interface. We should probably establish a separate entity object that is responsible for managing shapes with no explicit GUI responsibility. We also notice that the Create Rectanlge controller might not have all of the information it would need to create the new Rectangle. It needs to know the current colors. Since the Toolbar knows that information, we add that to the diagram. Here is another pass.

Figure 4. Second-pass robustness diagram.

Notice that in this latest pass that the "Draws Preview" controller was removed. It does not appear to involve any objects other than the Canvas, so it isn't really needed at this point. Also note that the exception flows are not shown on this diagram.

Update Domain Model

We need to update out domain model since we added an object during robustness. An updated version is below.

Figure 5. Updated domain model for drawing program.

We can now start to see the identity of various objects in terms of specific responsibilities, behaviors, attributes, and associations. We "instantiate" the objects in our domain model and work toward a class diagram which is a blueprint for these objects. Here is a start.

Figure 6. Initial class diagram for drawing program.

We apply our knowledge of the Java Swing API to realize that Mainframe will be a type or subtype of JFrame, Menu a JMenubar, Toolbar and Canvas will be JPanels, and Shape History, actually renamed Shape List a type or subtype of JList. We may need to put in a little more thought to decide if we really need to subtype these various types to use them.

Also notice the association drawn in from Canvas back to Mainframe. This is the start of realizing the links between the objects/controllers/objects in the robustness diagram. We know that Canvas will be the boundary object the user is communicating with and thus has context during the various mouse events that trigger the use case. One way or another, context needs to pass from Canvas to Toolbar to get the color selections, to the Shape Manager to create and contain the new Rectangle, and to Shape List to update its UI. Clearly we could contruct the Canvas and provide references to these various other objects. That certainly introduces coupling. By virtue of Mainframe creating all of these objects in the first place, Mainframe has the capability to talk to all of the various objects.

Detailed Design

Now we are ready to create sequence diagrams and finalize our domain model which has now become our class diagram. We should really complete the steps above for all of our use cases to make sure design decisions we make for one use case do not complicate another.

Implementation

We can now code and test.

Assignment

Using the information presented above:

1. Address question posed regarding UC1 and whether it can be used for all supported Shapes or if we need separate use cases.
2. Write UC2 and UC3
3. Create robustness diagrams for UC2 and UC3
4. Decide on the new classes you will need to support the domain objects and add to the model (see starter model below). Add appropriate methods, attributes, and associations.
5. Create sequence diagrams for UC2 and UC3 in model

Resources

• JavaAPI1_5.zip: This is an XML format file for importing the class definitions for the Java API into your EA model. This will allow interactions with the Java API to be very accurate. Download and unzip file. Create a folder in your model for the Java API. Right-click on your new folder and select "Import package from XMI file..." Select the unzipped file and go. This will take awhile and will cause EA to be noticeably slower. But it is worth the tradeoff.
• Sample EA Model: This is a zipped EA model that implements the model shown above with some minor tweaks. Enough methods are filled in to implement UC1 for a rectangle only. This model was used to generate the code listed below. I suggest you use this as a starting point for this project. Also, the Shapes heirarchy has been Javaized (uses Point and Color from java.awt). Due to the inclusion of the Java API, this file is huge.
• Drawing.zip: This is a zipped Eclipse project that was created via code generation and implements much of UC1 for a rectangle only. Some details are not implemented like fill, and problems remain with coordinates for some cases. Some comments are provided to illustrate what is missing. I suggest you use this as a starting point. "Rubberbanding" is demonstrated as well.

DrRothe^? Deliverables (due at beginning of week 3 lab)

Students should submit one .zip per group file containing:

• A text file (report.txt) with:
  • Answer to question posed regarding UC1.
  • UC2 and UC3.
  • A short discussion about any problems you had with this project. Be sure to discuss problems you suspect you might have with implenting the design. Specificaly address the issue of coupling between the domain objects.
  • A text file named manifest.txt. Within manifest.txt, list your email addresses (each team member, one per line), and all of the text files (just report.txt this time).
• Submit via electronic submission at online submission as Lab 2.
• Do not include EA file with this submission or any code.

I will collect in class (on a flash drive due to the size):

• Your EA model that includes:
  • Robustness diagrams for UC2 and UC3.
  • Sequence diagrams for UC2 and UC3.
  • Updated class diagram that includes all classes needed to accomplish UC1-3.
  • Note: The class diagram should include all mehtods, attributes and associations required to implement UC1-3.

DrTaylor^? Deliverables (due 11pm the day prior to week 3 lab)

Students should submit one .zip file containing:

• A text file with:
  • Answer to question posed regarding UC1.
  • UC2 and UC3.
• EA model that includes:
  • Robustness diagrams for UC2 and UC3.
  • Sequence diagrams for UC2 and UC3.
  • Updated class diagram that includes all classes needed to accomplish UC1-3.
  • Note: The class diagram should include all methods, attributes and associations required to implement UC1-3.
• Submit a log of time spent on this assignment to FAST. (added at the last minute)