Jython Environment For Students (JES) Final Presentation Team 3 David Raines Claire Bailey Jason Ergle Josh Sklare July 16, 2002 1

Introduction Jython Environment For Students (JES) Client: Mark Guzdial Team: Claire Bailey - Technical Writing  David Raines - Project Manager Jason Ergle - Design Lead Josh Sklare - Technical Lead July 16, 2002

Goals Create a Jython programming environment For new Introduction to Media Computation (CS1315) class Target audience is non-technical students and first time programmers 1) The Programming Environment is specifically designed for students in a new Introoduction to Computing class here at Georgia Tech. The class will cater to students whom are not CS or Engineering majors. Mainly Architecture and LCC Majors. The class will be taught in the Jython Programming Language. Jython is a Java based Python language. No Jython specific IDE’s yet exist. July 16, 2002 3

Key Requirements Provide an editor with Syntax Highlighting for loading, modifying, and saving Jython files Provide a command prompt for interacting with Jython interpreter, as well as running loaded files Error messages should be understandable by the target users As with any IDE, we had to provide a Text Editor that allows for Loading, Viewing, and Editing of Jython files. The editor also needed to highlight keywords specific to the Jython Language. The user had to be provided with a Jython Command prompt emulator so that they could interact with the Jython Interpreter while using JES. We also had to capture Errors that were generated by the Jython Interpreter and convert these messages into a more user friendly form. This will help to make the language more friendy to beginning programmers. July 16, 2002 4

Key Requirements (cont…) Debugging will be provided by a popup window containing variable names, types, and values Implement in Jython and Swing Easy to maintain and extend We were also required to provide the users with a Debugging Window that would list all current variable names, types, and values. This needed to be implemented as a system command that would allow users to see which values were moving through the variables at any given time in the program. Also, Professor Guzduial wanted this Jython IDE impelemented in Jython itsself. All of the GUI code for the project was to be implemented in Swing. The code also had to be maintainable and extremely readable. JES potentially has a long period of use, and its requirements will likely change over time. Since all of the original designers of JES will soon be graduating, the software must be maintained by professor Guzdial and Associates. Also, as the class evolves, the software will have to evolve with it to keep up with the needs of the class. July 16, 2002

Design The major functionality of the program is divided into two different classes, JESUI and JESInterpretor JESUI contains instances of the other UI Classes. Also handles the events generated by the program. JESInterpreter executes the command line. JESProgram is the main part of the program. The main parts of functionality in the program are divided into two classes, JESUI and JESInterpreter. JESUI is a container class for the other parts of the user interface. JESUI also handles the events generated by the program. It holds instances of JESEditor and JESCommandWindow inside it. These two classes allow for the interaction of the User Interface and the main program. JESInterpreter executes the command line. It executes the interpreter in a separate thread so the overall JES program will not block when the user’s code is being interpreted. JESInterpreter is able to handle any exceptions that are generated by the user’s code in a graceful manner. July 16, 2002

UML Diagram The system is designed ot be as modular as possible to allow for the adding of features at a later date. As you can see, JESProgram is the center of activity of the program. It manages the instances of JESUI and JESInterpreter. These two classes in turn manage the other parts of the system. JESAbout and Html_Broswer are also simple UI’s that are managed by the main program. July 16, 2002

UI Design Mac Version: July 16, 2002 Main goal of UI Design was for the program to be simple and easy to use by novices. The design we came up with is effective and simple. It consists of the following major parts: ·        Title Bar – identifies the program and the file that is currently open. ·        Menu bar – provides options for the user to select for opening, closing, creating, and modifying files, as well as text editing and getting help and information about JES. ·        Jython file editor – allows the users to write Jython code to be called from the command window. ·        Load and stop buttons Panel– allows the user to load a program or stop the interpreter thread. ·        Command window – allows the user to interact with the Jython interpreter and call functions that they have defined in the editor. ·        Status bar – displays the row and column where the keyboard cursor is located in the editor. July 16, 2002

Debug Window This window will be popped up via a system command from the user. It displays all of the variables, each variables type, and each variables value on the stack. This should allow users with a way to see what is happening to the variables as a program executes. The title of the window contains a number and a timestamp for each window. This is to allow users to place the showVars command inside of loops or recursive algorithms to see how variables are changed in each stamp. Since each call will generate a new window with an incremented number and new timestamp. July 16, 2002

Accomplishments We built an IDE that will be used by students this fall Requirements were well defined Met all requirements within the deadline Little need to modify or append them Code is easy to read 1)Project was successful Finished with-in given time frame with no compromise to functionality 2) Having well defined requirements helped up because we didn’t need to make any major changes to the design 3) Developed a standard for commenting and code structure. Every function header has a description describing it’s purpose, parameters, and results July 16, 2002 10

Accomplishments (cont…) Schedule was well divided into tasks Everyone was able to work in parallel Shell of program was completed first Development information kept in a public place Swiki: http://coweb.cc.gatech.edu/mediaComp-plan/10 Document repository Status updates Change control Bug list 1) Not too many dependencies while developing July 16, 2002

Accomplishments (cont…) The client is happy with the outcome! Professor Guzdial has been happy with the program. He has already been using it to prepare for the new class. He’s also been showing it to others July 16, 2002

Assessment Original Schedule: Actual Schedule: July 16, 2002 Didn’t take into account the 4th of July holiday Some tasks took longer than planned: -Creation of UI in Swing -Threading issues: running user code July 16, 2002

Assessment (cont…) Some tasks took longer than originally planned Interfaces of objects should have been more descriptive Interactions with the client were good Swiki was very useful Overall development process went smoothly Mentioned in previous slide 2) We ran into some issues with interfaces not defined well enough -parameter was called file, but was file name 3) 4) Process went well, even though it took slightly longer than originally anticipated Outcome was very good July 16, 2002 14

What we learned Benefit of well defined requirements and a good, modular design Keeping an open dialog with client is very beneficial Design should be as specific as possible, especially with object interfaces 1) Everyone was able to work on developing simultaneously 2) Meet with client once a week We were able to work out any issues that came up and deal with them quickly He was able to let us know if there was something we were doing incorrectly 3)Helps save time when things are put together If not well defined, problems occur even when the programmer does everything they were supposed to July 16, 2002

What we learned (cont…) Benefits of dynamic languages Clearly identified team roles are good 1) Dynamic languages: Didn’t make anything harder to do Some things we actually easier: Getting variables and their values Traversing the stack Running dynamically loaded code 2) everyone may be capable of the different jobs; however: It’s much easier to get things done when one person determines who works on what No confusion about who needs to do what July 16, 2002

Demo July 16, 2002