GUI Computer Simulator

Transcription

1 Comp145 UNC Chapel Hill Contract II GUI Computer Simulator Team #8 Client: Dr. Frederick P. Brooks Jr. and Prof. Greg Welch February 13, 2001 Dr. Frederick P. Brooks Jr. Chris Bailey [Admin] Ed Goode [Librarian] Andy Hans [Q&A] Cary Hall [Director] John Ehrhardt [Producer]

2 Preface Note that this is the second version of this Contract. Both the team and the client have reviewed this document after initial delivery and altered it as needed and agreed upon. This document specifies the requirements for the computer simulator and the schedule in which they will be done. Document Change History Added Validation and Verification, Section 5; Schedule moved to Section 6 Ammended Section 6.3 Risk Analysis Added Document Change History (this Section) 1 Introduction Dr. Brooks teaches a computer architecture course that teaches basic computer system architecture. Assignments are programs written to be simulated on one or more of a set of different computer architectures. Before now, these programs could only be hand-checked by Dr. Brooks himself. Dr. Brooks asked that a computer simulator be built to simulate the instructions on various systems. This allows Dr. Brooks a better way to test these student programs and to provide the students with a valuable learning tool. 2 Non-Functional Requirements 2.1 Context Model

3

4 2.1-A User Interface The user interface allows the client to interact with the product. 2.1-A.i User Input The user interacts with the product through an interface. The user can choose which machine s instruction set to load, load his/her code into the simulator, begin execution of the code, step through the code, and select what parts of the computer s state to monitor. 2.1-A.ii Graphical User Interface The GUI allows the user to interact with the product. Through the GUI, the user can input commands and view the state of the computer simulator. 2.1-A.iii Monitor Client s Program The user must be able to view the state of the running computer simulation in order to comprehend what is occurring. The user view s the state of his/her program running in the computer simulator that is loaded in the APL interpreter. 2.1-B APL Interpreter The APL interpreter actually runs the simulation, which is monitored by the user interface. 2.1-B.i APL Machine Definitions The user must choose a machine definition that is to be used to executing their code. After the user makes his/her choice the physical APL code for the machine definition is loaded into the interpreter. Once the definition is loaded, the computer simulator is up and running. 2.1-B.ii Client s Code Once the computer simulator is running, it is ready to execute the user s code. This code is loaded and then can be executed continuously or in step. The user interface will monitor its execution, so that the user knows what is happening in the simulation.

5 2.2 Process Model 1. Start Program: The GUI interface is executed 1a APL Machine Definition The various machine definitions are listed. 2. Choose Machine Definition: The user chooses the correct machine definition they need 2a. Load Definition in APL Interpreter: The definition chosen by the user must be loaded into the APL interpreter. 3. Import Client Code: The actual code to be executed must be imported 3a. Load Client Code in APL The code written by the user go into the Interpreter APL interpreter 4. Initiate Execution Client starts execution of their code 5a. Execute in Interpreter Line of Client code is executed in the APL interpreter 5b. Monitor Machine State Interface displays state of the simulator during execution 5c. Request State From Interpreter Interface must receive state to display from the APL interpreter 6. Print of Dump State Interface display of State may be printed or discarded

6 3 System Level Requirements 3.1 State Machine Diagram Stimulus Specification Chosen Code loaded into APL interpreter Step button pressed Run button pressed Execution complete New Specification Chosen New Code Loaded Description Client has chosen one of the many machine architectures Client has selected code to run and Code has been loaded into interpreter Client has selected to single step through execution of program Client has selected to run program beginning to end Execution of program has finished see Specification Chosen see Code loaded into APL interpreter 3.2 User Interface Requirements Plan A Viewing of machine state: registers, memory Selection of machine architectures Loading of client code Widgets for invoking step or complete execution (i.e., buttons) Area displaying the client code being executed (note that this same code will also be in the memory space, but it would be easier to locate in its own window).

7 Message log area (scrollable) Plan B Mechanism for inserting breakpoints Toggle display representation for memory and register contents (binary/octal/hexadecimal) Mechanism for placing variable (memory or registers) on watch status.

8 3.3 Non-Functional Requirements A.) Client Platform Windows Machine Running X Client for Windows to view UI, or Linux machine running X to view UI 800x600 resolution to fit all parts of UI into screen Optimal 1024x768 to comfortably fit all parts of UI on screen Ethernet latency to server under 200 ms (suggested) or the user interface will be slow to respond B.) Server Platform Server running code will have its small set of data (negligible room) Client Preferences stored on server per username (negligible room) Amount of Users to connect to server must be reasonable else processing could take excessive amounts of time. 3.4 Goals Run APL Machine Emulator from a server and be able to have entire 265 course able to theoretically connect all at the same time and use the software with reasonable response time to help complete and/or understand assignments for the class To correctly emulate, as the 265 text shows, the thirty or so computer architectures described therein via a modeled APL description of each architecture 4 Hardware and Software Resource Requirements Plans to procure: We are still in the search for a functional open-source APL interpreter. We have examined several different interpreters including APL2000, APL-Plus, SharpAPL, and OpenAPL. Prices range from free, open-source modules to $2000 personal license programs. The interpreter is the only piece of software aside

9 from the APL computer architecture definitions from Dr. Brooks book that we need to find. The GUI will most likely be done with the FLTK libraries which are easily accessible. Estimated Schedule of procurement/delivery - We are still in discussion with Dr. Brooks on the best APL interpreter to use. We plan on a definite decision by 02/09/01 - The APL definitions from Dr. Brooks are residing with a colleague of his and should be here in the next week (again, by 02/09/01) - We can procure the FLTK libraries at any time. Alternatives (risk management) - There are no alternatives to our software requirements. It would probably not be feasible to build our own interpreter, so failure to find a compatible interpreter would mean a failure in the project. - The APL definitions are included, hard-copy only, in the Comp265 text book. If need-be, we can hard-code the definitions into the simulator, but this could cause many unwanted problems. 5 Validation and Verification 5.1 Strategy Based on feedback from Professor Welch, and preliminary input from Professor Brooks and Dean Herrington, we feel that the current plan for the project is an appropriate path. We have scheduled a text-based prototype, which will hopefully demonstrate that we have the ability to load machine definitions, user programs, and step through them or execute in whole. Given a comprehensive program for each machine definition, and its sample output, we should be able to compare memory and register dumps for differences. This will provide a concrete proof of correctness for final execution states. After each stage of development, sample programs will be executed in the simulator to verify that it works correctly and output verified against a control memory/register dump. Boundary and invalid input handling will be done at all stages at well. Testing once we reach the GUI stage will involve live user interaction to monitor the effect of GUI events and the GUI event loop. There will also be subjective monitoring of response times within the product. 5.2 Test Cases

10 Load programs that will definitely crash. Be certain that the product can detect the emulated machine s crash, and report this to the user. This will need to be done numerous times, to assure that we access enough of the instruction set for each machine architecture. Handle mislabeled machine definitions by informing the user of the specific syntax errors. Load extremely large programs and be certain the product and interpreter can handle the program size, or report to user that the program exceeds the machines memory space. Assure that the average response time to users actions is less than 200ms (ie, noticeable). 6 Preliminary Schedule 6.1 Development Items 6.1a Major Phases Phase I o Meet with client and define what is to be created o Finalize the architecture of the application o Choose which APL interpreter to use Phase II o GUI design (get FLTK working) o APL interpreter interacting with our code o Loading APL machine definitions o Get a test binary program to run in a computer simulator Phase III o Parse the APL computer definitions to find the names of variables to track the state of the machine o Implement state monitoring of the computer simulator o Link the GUI to the computer simulator for loading programs and monitoring state Phase IV o Implement step-execution o Finalize GUI with event handling (aesthetics) o Implement handling new APL machine definitions o Splash screen intro Phase V (Plan B) o Implement breakpoints o Implement printing state to file/printer o Allow binary/octal/hexadecimal toggling o Include integrated APL editor if necessary 6.1b Tasks and Dependencies

11 See section c Major Milestones - Preliminary Report signed - Website turned in - APL interpreter chosen - Contract signed by client - Design specification signed - Contract II signed - Computer Simulators up and running in APL interpreter finished - Non-linked GUI Prototype finished - Text-based Prototype with state monitoring finished - User Manual signed - Prototype finished - Implementation Manual signed - Final Application turned in - Website complete - Project Package signed - Team Report signed - Individual Reports signed 6.1d Deliverables - Project Preferences 01/11/01 - Preliminary Report 01/25/01 - Website 01/25/01 - Contract I 02/06/01 - Contract II 02/13/01 - Design Specifications 02/20/01 - User Manual 02/27/01 - Prototype 03/08/01 - Implementation Manual 04/17/01 - WWW Site Complete 05/04/01 - Project Packages 05/04/01 - Team Reports 05/04/01 - Individual Reports 05/04/ Schedule Diagrams - PERT chart available at - GANTT chart available at (you must have MS Project to view this) - Attached as Appendix A and Appendix B in hard copies. 6.3 Risk Analysis and Management Scheduling Risks

12 APL Machine definitions and a decision regarding which APL interpreter to use are current holdups. The interpreter selection is already past due. Until an interpreter is selected, we can t progress on the interpreter-socket interface. FLTK environment is not currently set up. Another early phase in the task dependencies is to develop a GUI that can later be linked to the socketinterpreter IO core. Plan A of the project is an atomic function. The functionality set of plan A has to be implemented for the project to be a success. The real risk is that if we spend too long on plan A, we won t get to plan B, which is where a lot of useful but unnecessary features are found.