User Interface Design Notes

Brief notes on user interface design.

Goals

One of the main goals of the simulation engine was to cleanly separate the task of simulating a microprocessor (at the bus-cycle level) from the quite different task of allowing a user to interact with this simulated model. The simulation engine itself does its thing and also provides mechanisms ("hooks") that a UI can exploit. The engine is NOT designed for any specific user interface.

Here I discuss two obvious user interfaces: command line and graphical. HOWEVER, there are other useful interfaces: batch, BUFFALO monitor and others...

Architecture

The basic architecture is:

                           AbstractUI
                                |
                                |
                                |
                   ------------------------------------------
                   |                           |             |
                   |                           |             |
              CmdLineUI                     SwingUI    ...other UIs...

NOTES:
  • The AbstractUI class is NOT really abstract. Yes, it is DECLARED abstract, ALL methods are instantiated. The DummyUI simply inherits from the alleged abstract class... (This class is used for testing.)
  • The methods in AbstractUI could have been more logically distributed into various classes. A UI could then use composition (instead of inheritance) to access their functionality
  • The first (partially) working versions of cmdLineUI and SwingUI used the inheritance scheme.
  • Consequently, despite reservations about fundamental design, I decided to push ahead with the (possibly brain-dead) initial design. To do otherwise would have been both anal and stupid; the project simply would not have been completed on time.
  • Implementation

    The UI classes have not been designed as carefully as the engine classes. Some thought went into the AbstractUI class; the CmdLineUI class also has some cute features (the command array, for example).

    SwingUI Implementation

    I am no expert in GUIs either in general (good design habits) or in details (I have not written any significant Java code for a GUI.)

    Testing

    The simulation engine lends itself easily to automatic (automated?) regression testing using a tool like JUnit.

    Alas, user input complicates things. Some possible testing stategies include:

  • Command line interfaces can be automated by redirecting stdin, stdout and stderr to(from) files and comparing outputs with expectations. NOT IMPLEMENTED!
  • Since AbstractUI can be (trivailly) instantiated, JUnit can test its methods. (IMPLEMENTED)
  • A specialzed UI (batch with embedded assertions). (NOT IMPLEMENTED)
  • Combining batch/command line tests on software with actual results from (eg) BUFFALO Monitor i/o on hardware. (NOT IMPLEMENTED!)
  • Colophon: This html rendition is derived from the XML file com/kclowes/sim11/docs/ui/DesignNotes.xml. It was translated to html with the XML translation specification in ./article2html.xsl using a standard xslt command written in Java. The source file was written by Ken Clowes (kclowes@ee.ryerson.ca). The dtd and xsl files were written by kclowes. Everything was written using xemacs and maintained using make and the bash shell under WindowsME, Solaris and Linux operating systems.