JHotDraw is a Java version of the original Smalltalk HotDraw framework developed by Kent Beck and Ward Cunningham. The rewrite in Java was done as an exercise in applying design patterns by Thomas Eggenschwiler and Erich Gamma (the latter of Gang of Four fame). The framework is in the public domain, and is maintained, upgraded, and modified as an open source project at SourceForge.
For this project the class will be divided into teams of four to five students. One team will serve as the Framework Support Team (FST) whose responsibility is to gain in-depth knowledge of the framework so as to support the teams developing applications. The other teams will develop applications in the class JHotDraw targets.
The home page for JHotDraw contains a link to the project page at SourceForge, from which you can download the most recent beta version of JHotDraw (5.4b1) as well as a couple of earlier "stable" releases. If you go to the forum section of SourceForge you'll find discussions of JHotDraw - and some indications of problems others have encountered. Part of the excitement of working with open source software is dealing with the bugs as part of a volunteer development process. Members of the FST (and possibly the application teams) should register as JHotDraw developers at SourceForge so as to have close contact with other users.
There is a smattering of documentation on JHotDraw distributed across the net. One of the best is the article "Becoming a Programming Picasso with JHotDraw" at JavaWorld - this is an introduction to the framework couched in the development of a simple UML editor. The version used is 5.2; there is also an updated version for 5.3 as well as a version (definitely beta) for 5.4b1.
Also available on the web is the JHotDraw Pattern Language from Britain. This document gives a tour through the framework by including the class models and sub-models (in UML) that comprise JHotDraw, as well as advice as to how to put together an application. A similar discussion is in chapter of a thesis by Dick Riehle.
And, of course, you can find a wealth of material by Googling for JHotDraw!
The members of the framework should be interested in:
This project format will not work without a dedicated FST. Indeed, 13.33% of the team's grade will be based on feedback from the application teams.
You are to use JHotDraw to create a logic design editor. Your editor need only support simple combinational circuits (no feedback loops and no storage mechanisms) built from AND, OR, and INVERTER gates. There must be a way to specify the input(s) to the circuit as a whole as well as the circuit output(s). In addition, when the inputs change, the gates themselves will change appearance so as to indicate whether the output of the gate is true (1) or false (0). This change can be done via colors, labels, or any other clearly identifiable marking.
Inputs to a gate come from the specified input sources and/or other gates in the diagram. Outputs can also be directed to the output displays and/or other gates. There is no limit to the number of outputs to which a given gate can be connected. However, AND and OR gates require exactly two inputs, and INVERTERS require exactly one input. If a gate has one or more undefned (e.g., unconnected) inputs, then its output is also undefined. Undefined values must also be indicated by the appearance of the gate, which must be different from the appearance for true and false values.
Gates and groups may be created, copied, and deleted from the diagram (with obvious effects on the inputs and outputs).
You are not required (but you are encouraged) to create specific new figure types to represent the three types of gates in their standard graphical representations.
A finite state machine (FSM) is a form of directed graph used to accept some input strings and reject others. The nodes in the graph are the states, usually labeled by digits. One of the states is designated as the start state, which is the state the machine is in prior to receiving the first character of the string. Zero of more states are designated as accepting states - if the machine is in one of these states after all input has been consumed, the string as a whole is accepted, otherwise the string is rejected.
States are connected by labeled arcs. The labels are characters drawn from the machine's alphabet - that is, the characters the machine is prepared to process. If the arc from state S1 to state S2 is labeled with C, then if the machine is in state S1 when a C is input, the machine makes a transition to state S2.
The diagram below shows a three state machine that accepts of all strings of
1's and 0's that end in 10. The start state is S1, as indicated by the arrow
from the black ball. The only accepting state is S3, as indicated by the
convention of two circles around the state name.
If the string 100110 is fed in (left to right) then the corresponding state transitions are:
S1 -> S2 -> S3 ->S1 -> S2 -> S2 -> S3.
As the last state is S3, the string is accepted. The string 101, however, is rejected, as the transition sequence is:
S1 -> S2 -> S3 -> S2.
The task of this team is to implement an editor for creating FSMs whose alphabets are the digits 0 and 1. At a minimum, the editor must allow the user to:
An FSM is valid if and only if:
If the FSM is valid, the user must be able to test it by simulating execution. This entails:
The FSM must visually indicate the current state as part of the simulation. I suggest using color here. Note that the FSM may be simulated several times, so there must be an explicit reset mechanism.
You should all remember from data structures that an arithmetic expression can be represented as a tree. Your task is to create a tree editor for expressions, and to support evaluation of the expressions so represented.
At a minimum you must have tree nodes representing the four basic integer operators (+, -, *, /) as well as a node that represents a numeric value. The value nodes, of course, are the leaves of the tree; the operators are the internal nodes; and the root node represents the value of the expression as a whole. Note that the root node can be a value node (this is the simplest expression).
The expression tree must be constructed incrementally. That is, you will create a root node first. If this is an operator, you will then create the left and right operand trees and attach them to the root. Until you have a properly formed tree, the value of the whole expression is undefined. What is more, the initial value of a vlaue node is undefined as well. It will probably be easiest if you also allow the deletion of sub-trees for correcting mistakes.
When a value node with an operator node parent is changed, then the parent must be informed so that it can update its value. If the parent node's value changes as a consequence, then it notifies its parent (the grandparent of the value node), continuing in this way until either:
Rules for evaluation:
Once you have constructed a valid expression tree (that is, every operator has two operands and all the leaf nodes are value nodes), then you should use the evaluation rules above to show the value of the expression and each sub-expression. Changing a value node may cause some of the operator nodes containing that value to change as well. At all times, the labels must reflect the current value associated with the node.
The team will make 20 minute technical presentation presentation of the JHotDraw framework. The presentation must include the following:
In addition, the team should provide a demonstration of one or more of the prototype experiments they performed to familiarize themselves with the framework. Overall, this presentation is worth 10 points.
The team will also be evaluated for its effectiveness by the application development teams. These evaluations will be worth 2 points
The team must prepare a document describing the overall framework design, its initial state, and its final state; I expect this document to be 8-12 pages in length. Note that UML is an excellent tool for showing the class relationships, but UML in and of itself is not sufficient. This document will be worth 3 points.
The team will also be asked to comment on the relationship it had with the application teams. These comments will be used to assign one point of each application team's grade.
Each team will make a 20 minute technical presentation of its application, with a focus on:
In addition, each team will demonstrate its application as part of the presentation. Overall, the presentation is worth 10 points.
As noted above, one point will be assigned based on the application team's interactions with the framework support team.
The remaining four points will be assigned based on the submitted application code (2 points) and a design document showing the primary application classes, their relationship to JHotDraw, and the roles and responsibilities of each application class (2 points).
I expect the design document to be 8-12 pages in length. Note that UML is an excellent tool for showing the class relationships, but UML in and of itself is not sufficient.
Finally, each application team will provide feedback on its relationship with the framework support team; as noted above, this feedback will be used to assign 2 of the points for the framework team.