We have treaded lightly on requirements and their impact on application design. First I tried to get you to appreciate the freshman’s introduction to TMs and how to program them. You wrote some programs that they write. Everyone seemed to be very satisfied with the TM simulators on the web and you modeled your designs on them without thinking that if they were satisfactory I would not need alternative software to be developed (see requirement 2). You did not develop your own requirements list in your teams, so I presented you one. You did not analyze these requirements very carefully. I have studied both functional specifications and find that they fall considerably short of the requirements and the sophistication that they point to. Below is a set of suggestions for adding functionality that address each requirement. Each team need to recycle through their functional specifications (and re-prototype the application) even as you mature your implementation architecture. It is apparent that neither team has much feel for what can be done in a context-sensitive IDE.
Use color to indicate repetition (count of how many times an instruction has been executed or how may times a tape cell has been evaluated): White =0, pale yellow =1, dark yellow =2-5, light orange=6-15, orange = 16-50, pink=more than 50.
[existing applets view execution as a BLACK BOX function where only the table is visible. Our project is to develop a WHITE BOX application that displays how the machine functions.]
Requirement #3 testing is interpreted as executing on a tape (without animation). This is one-shot testing. No provision made to support changing tapes or verifying that the results are correct. Facility to compare to tapes desired.
Requirement #4 wizard for row loops, reminder for need states, automatic presentation of row cells, check for validity (introduce new symbol by typing it instead declaring it in advance).
Requirement #5 ignored
Requirement #6 creative effort to convey nature of finite state machine and how programmers need to think in order to program. Emphasis on states and trigger for transitioning to new state. Requirement affects simulated execution and program construction.
Requirement 6a: Instructions are of three types: future potential: (either never executed or previously executed), current, and executed.
Requirement 6b: Use animation to emphasize execution of instruction: change state counter, change tape symbol, change tape cell, in sequence (with sound), place instruction in execution trace list, reposition on new instruction.
Requirement 6c-6f. The TM table is important because the IDEA of a finite state machine is transition from state to state. The table organizes the states (rows) and for each describes the transitions (determined by the column) that could occur. The program is understood by comprehending the sequence of states rather than by understanding the sequence of instructions. The goal therefore should be to animate the sequence of states that is generated by a specific tape.
Requirement 6h. The report should do more than tabulate how many instructions were executed or how many times each state was entered or how many of each kind of symbols were processed. It should report how many iterations of each loop in the process.
Requirement 6i: no errors were said to be detected. Sample errors are
· Running off the tape (if finite)
· Being directed to a state in which there is no instruction for the tape symbol
· Duplicating a tape symbol with a programmer symbol
· Entering an infinite loop (set a limit on the number of instructions to be used)
· Leaving a programmer symbol on the tape (warning if there is no erase command for any programmer symbol)
Requirement 6j. this required though about how to input instructions in the edit pane and how to simulate the way the machine moves through the table in the execution pane. The execution pane animates state transitions so the non-selected instructions in each state are unimportant to the animation and can be made so small they are unreadable. Only ONE instruction is important in each state, the one in the column identified by the symbol in the tape cell. That is the only one that need be visible in each cycle of the execution animation. It is counter productive to try to use the same representation for the TM table in the execution pane and the edit pane.
Requirement 7: As the program passes from state to state, the purpose of that state should be displayed. If the TM stays in the same state for several cycles (a row loop) the IDE should signal that fact (perhaps make the state description blink). If the TM returns to a state it was in previously, a state loop has been discovered and that should be signaled in some way (perhaps graying all the states traversed in between). The instruction trace should also evidence the fact that some instructions are part of a loop structure. The TM editor should have the ability to determine which states need to be elaborated and should have the ability at the press of a button to reorganize the table in precedence order of states.
Requirement 8 buttons are planned to permit the user to control the animation of the program execution but no details were provided as to how reset performed and how the load point and starting state are determined (when overriding the default of state 1 (or “start”) and the leftmost non-blank cell). If the starting state is changed should “reset” remember the new starting state or should “resume” be used?
Requirement 9. There should be at a minimum a pane for editing tapes, a pane for editing TM programs, and a pane for execution. There might also be a debugging pane, an opening control panel, and a report pane.