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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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:
Document repository
Status updates
Change control
Bug list
1) Not too many dependencies while developing
July 16, 2002

12. 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

13. 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

14. 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

15. 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

16. 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

17. Demo
July 16, 2002