Pattern-Oriented Software Design (Fall 2009)
Homework#7 (Due 2010/01/15)
1 Introduction
This is the last homework. A lot of new features are required. The maximum
grade of this homework is 200 points. You are encouraged to implement as many
features as possible to make your program more useful. In addition, performing an
adequate unit testing is also required.
2 Feature Requirements
1. Presentation Model Pattern (30%): You are required to apply the presentation
model pattern in your program. The presentation model is used to pull the state
and behavior out of the view. The basic principle is to make the view as a very
“thin” class; the code remains in the view is all about handling GUI control
without handling any logic. The logic code is extracted from the view to the
presentation model.
2. Two-side Mind Map (30%): The root node of a mind map is supposed to have
two sides for arranging its children nodes. As the example shown in Fig 1, the root
node (Topic) is placed at the center of the mind map, and some nodes are
placed on the right-side of the root node and other nodes are placed on the
left-side.
Fig 1 A two-side mind map example
To support such feature, the AbstractNode class introduces a getSide()
method used to indicate the side of the node. The return value is RIGHT, LEFT, or
NONE. Note that the side-value of the root node is always NONE.
1
When a node is inserted into a mind map, its side value is determined
automatically. There are two cases. The first case is simple. If a node is inserted as
a child of another node, its side value is the same as the side value of its parent
node. The second case is a bit complicated. If a node is inserted as a child of a root
node, its side value depends on the number of left-children (NOT including
descendants) and right-children of the root node. If the number of left-children is
less than that of right-children, the new node should be placed at the left, and vice
verse.
To fulfill this requirement, a lot of code need revision. For example, the
drawing visitor should take care the drawing of the left-side. So does the visitor of
automatic layout.
3. Style Properties (30%): In order to display a mind map beautifully, you are
required to support some style properties for nodes. The properties include the
following items:
z
Description font name, face, and size: These properties set the font of the
description of a node. For simplicity, you may assume that there are only
three types of font faces – bold, italic, and underline; and there are only four
levels of font sizes – small, medium, large, and very large. Each level
corresponds to a pre-defined point size, e.g., small means 8pt and medium
means 12pt.
z
Description foreground and background color: These properties set the
foreground and background colors of the description.
z
Rectangle foreground and background color: These properties set the
foreground and background colors of the surrounding rectangle.
z
Side: every node has a “side” property, which is either LEFT, RIGHT, or
NONE. The side property of a node can be revised, if the node is a child of
the root node.
A proper design is to introduce a “property” object (a dumb data object) that
records all the above style properties. Each node is associated with a property object
and provides getter/setter methods to access the property object. By using a property
object, the set of related property fields is encapsulated instead of explicitly storing all
property fields in a node.
All of the above style properties should be saved permanently. Therefore, you
should revise the save/load procedures to support this requirement. In addition, a
“property dialog” should be provided for the user to editing the style properties of a
selected node. Note: undo and redo of style property change are not required.
2
4. Mind Map Operation (30%):
z Move up/down: The sibling order of a node can be changed by moving the
node up or down. Moving up makes a node one step forward in its sibling
list, and moving down makes a node one step backward.
z
Expand/Collapse: When a mind map is complicated, sometimes the user
does not want to see every node. In this case, the user can collapse a node.
All the descendants of a collapsed node will not be displayed. Therefore, the
mind map can be displayed concisely. Of course, the user can expand a
collapsed node later, and the descendants of the expanded node will be
displayed again.
To support this feature, isCollapsed() and setCollapsed()
methods are introduced to access the collapse state of a node. A collapsed
node returns TRUE when isCollapsed() is called. Note that a
non-collapsed node should not be displayed, if its parent is collapsed.
There are two types of expand and collapse: one for a single level and
the other for all levels. The former only expands its children, and the later
expands all descendants of a collapsed node.
To support the above operations, MyMind should support an enhanced
menubar and a toolbar providing corresponding menu items and tool buttons.
Note: undo and redo of move up, move down, expand, and collapse are not
required.
5. Painting Area Resizing (15%): The painting area should be resized automatically
when the size of the mind map is too large to fit in the current size of the painting
area. In addition, the painting area should also be resized to a smaller size when
the mind map becomes smaller.
6. Supporting Scrollbars (15%): The size of the mind window of MyMind is fixed
(e.g., 800*600), but the painting area may be significantly larger. Therefore, you
should support both vertical and horizontal scrollbars for the window so that the
user can view any part of the painting area by scrolling the scrollbars.
3 Unit Testing
You are required to perform unit testing for your program. Existing test cases
should be maintained and your program should pass all the tests. For all new testable
3
methods, you are required to add new test cases for them.
4 Class Diagram
Please draw a UML class diagram to present the design of your program (except
for the test code). The following elements are required in your class diagram:
1. No missing classes.
2. Private and protected data members and member functions of classes should
be listed.
3. Static members should be listed.
4. The relationships (inheritance, dependency, association, and composition)
between classes should be complete and appropriate.
5. The cardinality of a relationship is required.
5 Grading
Your homework will be graded based on the following items:
1. Feature Requirements (150%)
2. Unit Testing (35%) – new test cases are written and all test cases should pass
3. Class Diagram (10%) – in JPEG, PNG, or PDF format.
4. Describe the difficulties you encountered when you did your homework (5%)
5. Bug Report (0%, but necessary) - during the development of your program, if
there are any bugs detected by your unit test, report the bugs. If none, report
none.
6. Time Log (0%, but necessary) – in DOC or XLS format.
4