SMD158 Interactive Systems, 2005
[Course home page]
[Class list and assignment status]
A common programming problem is to create a graphical editor for a specific
type of diagram. Diagrams are often used as languages to document programs or
as visual programming languages. For this class, your group will create an
editor for a diagrammatic language know as Interaction Object Graphs or IOGs.
IOGs closely related to the state diagrams contained in UML. These, in turn, are
are directly derived from the Statechart language developed by Professor David
IOGs are described in 4 publications available from my home page. These are:
- Carr, D., Interaction Object Graphs: An Executable Graphical Notation
for Specifying User Interfaces, Formal Methods for Computer-Human
Interaction, P. Palanque and F. Paterno', editors, ISBN 3-540-76158-6,
Springer-Verlag, 141-156, Nov. 1997.
- Carr, D., Toward More Understandable User Interface Specifications,
Design, Specification, and Verification of Interactive Systems '96,
F. Bodart & J. Vanderdonckt eds., Namur, Belgium. 5-7 June 1996,
Springer-Verlag, Vienna, 141-161.
- Carr, D., A Compact Graphical Representation of User Interface Interaction
Objects, University of Maryland, Department of Computer Science, Ph.D.,
[PDF, 117 pages]
- Carr, D., Specification of Interface Interaction Objects,
Proceedings of the ACM CHI'94 Conference on Human Factors in Computing
Systems, Boston, MA. 24-28 April 1994, 372-378.
from the ACM Digital Library]
The last paper gives a short overview. The first two papers give more
complete descriptions of IOGs and offer more examples. I wouldn't advise anyone
to read the entire dissertation. There is also a 9.5-minute video about IOGs.
In order to pass the lab portion of the course your group must implement an
editor with the basic features and write a report documenting the editor. A
well-done editor with good documentation incorporating the basic features would
receive a maximum of 40 points toward your grade. In order to get more, you must
attempt some of the advanced features.
The basic features for your IOG editor are:
- Adding, moving, and deleting all of the different IOG state types.
- Linking states with arcs and creating event arcs. Arcs should be
automatically typed depending on source and destination types.
- Setting parameters for states and arcs.
- Constructing arcs from line segments and editing their location.
- Saving and loading IOG diagrams from a file.
- Zooming and panning over diagrams that are larger that the display.
- Cut/copy/paste of diagram elements.
- Simple Undo/Redo of editing operations
Advanced features include:
- Expanding and collapsing individual meta-states (semantic zoom).
- Adding focus+context display techniques and/or multiple views.
- Animating the execution of the diagram by letting the user specify the
occurrence of events
- Allowing users to define a user interface layout for a widget that is
attached to the IOG.
- Binding window system events to an IOG interpreter and executing an IOG
- Creating a "debug" mode that binds execution, interface layout, and diagram
- Selective Undo/Redo of editing operations.
- A visual representation of Undo/Redo.
The project will be done in groups of three.
The project has three milestones:
- On February 8, 2005, you will present a design in the form of a
paper prototype, a preliminary software design documented in UML, and an
- On February 22, 2005, you will demonstrate you progress. It is expected
that you will have partially functioning software at this point.
- The final milestone on March 11, 2005 is to demonstrate a working editor
for IOG diagrams. A written report in English is
due later the same day.
Finally, some useful things to know are:
All groups must have three members unless granted special dispensation
by the examiner. Once your group has been formed register it using
the form found here. The groups are listed
on the class list page.
The lab report will be due on Friday, 11 March 2005 at 1700. The
report should include sections describing: system design including
documentation for classes that you have developed, user interface operation,
experience with development, and suggested improvements. The source
code should be submitted electronically.
- The system design description should include a short and high-level
(about a page) overview of how the system operates. It should also have
Use Case descriptions and diagrams showing how messages and control flow
through the program to the instruments and back. UML is the recommended
method. Finally, each class that you develop should have a short
description in the style of the Java online documentation. Collect these
in an appendix.
- The user interface operation should include a screen dump or two and
describe the user interface. It shouldn't be very long either (a page or
- The experiences section should cover things you learned doing the
project. This may include Java bugs and work-a-rounds or similar things.
If you used an interface builder, describe your experience with it.
- The "suggested improvements" section should be constructive criticism
with proposed solutions. Basically, think about how you what you would
change if you were going to do another version. (You shouldn't complain
about inadequate documentation or buggy systems. You can briefly describe
these problems in the experiences section, but without rancor.)
Remember the report is in English.
[Course home page]
[Class list and assignment status]
Author David A. Carr