Team Project: OOLALA

Computer Science is a science of abstraction, creating the right model for a problem and devising the appropriate mechanizable techniques to solve it. — A. Aho and J. Ullman

Submitting Your Work

Use GIT to push your team's implementation to the master branch of the provided, shared, oolala_teamNN repository hosted in the course's Gitlab group.

As your submission for this project, use GIT to add, commit, and push the following:

• src/main/java folder: all project code
• src/main/resources folder: any images or program files
• src/test/java folder: all JUnit test code
• src/test/resources folder: any test program files
• top-level (no separate folder): project README, and otherwise no other files created by you

Your code is expected to follow the course coding conventions and be reasonably commented.

Your team's project GIT repository must show many, purposeful, commits from all team members rather than just one or two large "kitchen sink" commits and marathon merging or redesign sessions. Specifically, we will be looking for deliberate attempts to regularly:

• integrate each other's work
• refactor code to improve its design
• test your functionality

We strongly suggest using the course's suggested GIT workflow for teams to manage this process.

Specification

In teams, write a Java program from scratch using straight OpenJFX (without FXML), that implements three seemingly different CompSci 101 level applications that use a small programming language to operate one or more "turtles" to move or draw with. Details for each application will be provided as the project progresses to help provide concrete examples for your Object-Oriented Language Architecture for Little Applications, OOLALA: a common interpreter for languages based on the similar syntax that allows users to enter programs interactively to be evaluated and visualized in various ways.

User Interface

While the exact User Interface for each program is up to your team to decide, they should all allow the user to:

• enter and run programs interactively
• display the results of executing the commands visually
• see errors that may result from entered commands in a user friendly way (i.e., not just printed to the console or crashing the program)
• load a program from a file
• save the current program to a file
• reset the environment back to its starting state
• see commands previously entered and reuse them again easily (perhaps by clicking on them rather than having to copy/paste them by hand)
  
• view any turtle's state (i.e., xy-location and heading)
• set a color and thickness to use for the turtles' pen
• set an image to use for the current turtles
• set a background color for the display area
• set the Home location to a specific xy-location (default is the center of the display)

Property Values

The View must use configuration file(s) for the details of its components instead of hard-coded values within your Java code, specifically:

• Resource property file: for any text or images displayed in the user interface
• CSS file: for any styles (colors, font, borders, etc.) used to customize the user interface
• Any text displayed should be able to appear in at least three languages (English and two others, you can use Google Translate if no one on your team can do it)
  You are not required to change the language dynamically, since that would require calling methods like setText() directly on every GUI element (so perhaps prompting the user at beginning of the program in an introductory screen).
  You are also not required to change the corresponding language in which program commands are understood, but it is encouraged.

The Model must implement basic error checking of the user programs and throw Exceptions for the View to catch and report to the user, specifically:

• Resource property file: for the error message text since it will displayed to the user (and these should be separate from the View's GUI text resources)
• String.format(): use this method to allow the property value in your file to include variable values and be a single String (rather than concatenated together as you might usually write)

Testing

Test your program using JUnit 5 test methods (code annotated with @Test and checked with one or more assertions) that demonstrate your code works as intended. Additionally, use TestFX to simulate common user "actions" that are checked with standard JUnit assertions to verify the UI responds appropriately. Make well named tests that test both "happy" and "sad" possible code paths (here are many, many, many examples in case you are having trouble thinking of possible negative tests):

• for each concrete Model class such that you achieve at least 75% Line test coverage of the class it is testing (aim for two happy/positive and one sad/negative test for each non-trivial public method and more for complex methods)
• for each common user "action" in the View(s) such that you achieve at least 50% Line test coverage of the class it is testing
• for each Exception expected to be thrown (both for when it is thrown and caught directly in the JUnit test for the Model and when it is caught and handled appropriately in the View using TestFX)
• for each program language command, using test programs given as hard-coded Strings in your test code (rather than separate files) that include both appropriate and error results

You are expected to create tests frequently to develop a working rhythm during the coding process rather than waiting until the end.

Deliverables

This project will be submitted in stages, each adding a new application:

• Logo programming IDE: a programming language with commands for drawing
• L-System Visualizer: a programming language for drawing growth processes, such as in plants and fractals
• Refactoring: focus on improving the project's design, robustness, and reliability

It is encouraged that you to start simply in order to verify your understanding of the project's core features. Then refactor your code to help it serve as a foundation for the more diverse functionality expected.

Design Specifications

The functionality features emphasize design goals, so your focus should be implementing them in such a way as to promote creating abstractions that generalize your core code, not simply as special cases added without a clear plan. Ideally, a well-designed program will make implementing new features easier so, when choosing a new feature to implement, look for something that fits into your design or refactor your code first to accommodate it. Specifically, your design should be thoughtful and intentional: clearly avoiding duplicate code structures and making it easy to add more of these kinds of applications without changing the existing code.

Adding functionality not related to an abstraction or resulting in poor code that diminishes your overall design efforts will not be rewarded. Specifically, the credit you receive for a functionality feature will be in proportion to how clearly it shows that your core classes are closed to modification while open to extension. Thus, a program with fewer features, but plenty of clear paths to easy expansion, is worth more than a program with many features but lacking clean code and good abstractions.

In addition to following the course Code Design Habits Checklist, your project design should clearly show the your progress learning the topics we have discussed so far in the course:

1. Clean code. Write your code primarily for communication: to avoid duplication, to support your team mates, and so that it can be easily understood by others
2. Use multiple classes. Divide your code into several classes that each have an active, useful, purpose (i.e., non-get/set methods)
3. Encapsulation: Create classes, based on their behavior rather than their state, to hide the each part's implementation decisions
4. Build abstractions. Create inheritance hierarchies to define common methods that can be implemented in multiple ways in separate concrete classes
5. Avoid hardcoded values. Move typical "magic" values into files, rather than compiled into your program, using resources, properties, and styles
6. Exceptions. Communicate errors in a thoughtful, intentional, manner rather than returning null or other error prone values
7. Separate Model/View. Create a cleanly structured GUI that is separated from the model and what information (including errors) needs to be returned from the model
8. Design Principles. Structure the core of your project with single-purposed, substitutable abstractions to help your design be more understandable and flexible

CompSci Context

This project highlights the following interesting and foundational Computer Science concepts. You are not expected to write a general or complete version of any of these concepts, but learning about them may help provide a context to begin thinking about some design issues or connect your work in this course to the broader computing community.

• Turtle Graphics was invented as part of the Logo programming language designed to teach programming to children by allowing them to control a physical robot. Users could issue commands such as FORWARD 50 to make the robot actually move 50 steps or RIGHT 90 to make it turn ninety degrees. The turtle robot carried a pen to produce drawings on paper put down under the robot. The turtle, which has since moved on to the computer screen, has become Logo's most familiar feature. In fact, most modern languages and platforms have an implementation, including being the core of the current modern children's programming environment Scratch. Additionally, it has helped people think differently about teaching geometry, social science, and especially programming.
• Abstract Syntax Trees, AST,  are the data structure underlying all programming languages, from HTML to JavaScript to Java, in which the leaves represent values in an expression and the internal nodes represent operations on those values. The inherent hierarchical nature of trees precisely captures operator precedence and provide a convenient mechanism for storing, traversing, and transforming expressions. Note that, unlike binary trees, each node of an Abstract Syntax Tree can have any number of children, modeling operators with one, two, or even arbitrary numbers of arguments.
• Parsing a simple string to produce the AST structure requires knowing the set of separator characters (e.g., whitespace and semi-colon in Java) and recognizing the expected tokens in the separated strings and their relationship (e.g., Java keywords, operators, and parentheses). During the parsing process, tokens are converted into useful objects and separators are typically thrown out. An error is thrown if the input string contains structural errors (e.g., an incomplete expression or an unrecognized word). The resulting parsed commands are evaluated to run the program (e.g., to control a "turtle" that can move, turn, and draw).
• The read-eval-print loop, REPL, allows coders to build programs interactively, per expression, and is available for many languages such as Logo, Python, JavaScript DevTools, entire web sites, the command line, and Java (or in IntelliJ). As its name implies, it is a program that repeatedly receives, parses, and evaluates commands from the user, then displays the results or reports any errors encountered. Many people prefer this interactive, immediate feedback, style of programming because it helps "work stuff out", makes programming more concrete and allows you to easily experiment with your program or the language. A REPL is fairly straightforward to build for interpreted languages requiring minimal context, like Logo, Python, and JavaScript, but Java requires code be within a class, be compiled, and start with public static void main, so it took about 20 years to figure out how to implement a meaningful version!

Individual Responsibilities when Working as a Team

This project requires steady, consistent, work — only by putting in consistent time each week will you see measurable progress and not have to pull "heroic" all-nighters.

Although this is a team project, everyone has individual responsibilities to the team that can be summed up as follows:

• actively participate in all team meetings
• regularly contribute clean code to the shared repository in reasonably sized chunks
• solving and coding at least one "interesting" design problem
• helping teammates at least once by going above and beyond

Unfortunately conflicts are likely to occur, so please let the Teaching Team know as soon as possible — even if it has happened just once or twice since it is better to deal with the situation early rather than having a disaster at the end when little can be done to get back on track.