|
|||||||||
| PREV NEXT | FRAMES NO FRAMES | ||||||||
See:
Description
| Packages |
|---|
The document provides an overview of the design of eStyle source code beautifier.
| Class name | Purpose |
| EStyleExtension | BlueJ extension and flow control |
| JalopyWrapper | Encapsulates the Jalopy object and formats code |
| EPreferences | Displays the preferences |
Alternative A: Create our own formatter, parser, and tokenizer.
Advantages: Would have complete control over what styles we would implement and how we implement those styles.
Disadvantages: The amount of time used to create our own would be better spent finding a working formatter, parser, and tokenizer. It would take a lot of design work and we would be "reinventing the wheel."
Alternative B: Use Jalopy's libraries.
Advantages: Jalopy has a tokenizer, parser, and formatter already written that is readily available. By using Jalopy to format the code, we would be able to create a product that checked most of the styles the customer was looking for in more than half the time it would take to write our own.
Disadvantages: Jalopy does not check all of the style rules we would want. It is harder to control the style checks we want Jalopy to check for.
Alternative C: Use AStyle, a command line formatter.
Advantages: Checks about half of the styles we need. Would take minimal lines of code to call AStyle to beautify the java file we send it. Easier to specify what checks we want than it is in Jalopy.
Disadvantages: AStyle is written in C++ which would make it difficult to edit and we would have to package AStyle up with our Extension which is cumbersome and could lead to problems.
Alternative D: Use preexisting BlueJ Extension Jempft.
Advantages: Jempft has a preexisting tokenizer and it is already written as a BlueJ extension.
Disadvantages: We would have to write the style rules ourselves. We would be "reinventing the wheel" when there is no need to do it.
Decision: Alternative B. By using Jalopy, we create a usable product in a short amount of time. The style checks that Jalopy does not do are not top priority style checks and therefore are not needed for the product at this moment.
Alternative A: Create our own GUI menu from scratch.
Advantages: Have complete control over what preferences we would display. We would have uniform style between the different style check preferences. We would be able to implement a way to add style preferences t the GUI.
Disadvantages: Would take time and effort to code and understand how GUI's work. Would take a lot of design to create a well planned out and organized preferences panel. We would be "reinventing the wheel" instead of using someone else's GUI that is proven to work.
Alternative B: Use a configuration file with no GUI.
Advantages: Saves time and effort and we would not have to implement a preferences GUI.
Disadvantages: Not what the user wants and it is much harder for the user to change style checks.
Alternative C: Use Jalopy's preferences menu.
Advantages: Would take a couple of lines of code to implement and it would interface with changing what style rules Jalopy checks for.
Disadvantages: Have very little control on what style preferences there are. It would take a lot of time to implement new style preferences in the same GUI.
Decision: Alternative C. The time and effort saved is far greater than the end result of Alternative A, could use the time to figure out a way to add style rules to the Jalopy preferences if the customer needed more style rules than Jalopy checks for. The preferences needed to be easy to access because it is meant for students just learning Java.
Alternative A: Use Jalopy's abstract plugin class.
Advantages: We make the implementation cleaner.
Disadvantages: Would take time to understand how to make the plugin classes work with BlueJ, and since BlueJ already has an extension library it would be better to use that.
Alternative B: Create our own BlueJ extension that encapsulates Jalopy.
Advantages: It would allow us more control. Implementation would be easier because we have prior knowledge of how BlueJ interacts with extensions.
Disadvantages: We would need to figure out a way to use Jalopy to format. Our encapsulation would not use the Jalopy libraries to the fullest extent.
Decision: Alternative B. Our needs are rather simple so using the Jalopy libraries to the fullest extent is not a top priority and because we have prior knowledge of how BlueJ interacts with extensions, and there are examples in the Jalopy API on how to format using a Jalopy object it would take less time to create our own.
Alternative A: (User Preferred) Access GUI from the extension preferences menu.
(Tools->Preferences->Extensions Tab)
Advantages: Localized with the rest of BlueJ extensions.
Disadvantages: Since we are using Jalopy's preferences window, which is meant to be a stand alone window, it would look cluttered with all the other preferences and would look very unorganized which is not something we would want to give to students just learning Java.
Alternative B: Access GUI from own menu item.
(Tools->eSytlePreferences)
Advantages: Clean and organized look. It takes fewer steps to access preferences GUI.
Disadvantages: Not localized with other extensions.
Decision: Alternative B. The organization and clean look outweigh the need for localization. Because of the audience, students just learning Java, we felt it was more important to have a clean, well organized, and easy to navigate GUI than it was to include the preferences with all the other extensions.
Alternative A: Read in the file name from BlueJ and set jalopy input to that file.
Advantages: No need to create a new file. Do not have to deal with using the BlueJ editor.
Disadvantages: BlueJ will have to reload the editor for the beautified text to show up in the editor. We would have to deal with getting the file name from BlueJ.
Alternative B: Get the text from the BlueJ editor and set jalopy input to that.
Advantages: Will not have to deal with getting the file name and will not have to reload the BlueJ editor. It will allow us to format a selection if the customer decides this is a reasonable feature to add.
Disadvantages: We will have to find/set the beginning and end of the text in the editor.
Decision: Alternative B. It was cleaner grabbing the text from the editor because it allows us to quickly change/get the code. If need be we could always store it into a file, thus grabbing the text from the editor allows us to do both options.
Alternative A: In a string.
Advantages: Storing it in a string is simple. All we really need because Jalopy accepts strings or files for input.
Disadvantages: The code taken in from the editor is not parsed; we would have to write our own parser/tokenizer if we wanted to add style checks.
Alternative B: In a new class called a Program that would parse the code into separate modules.
Advantages: Code taken in is parsed into smaller sections of the program which makes adding style checks easier.
Disadvantages: Writing our own parser would take time and because we are just using Jalopy we would not need to parse the code.
Decision: Alternative A. The simplicity and time saved that comes from storing the code in a string outweighs the need to store it as parsed modules, because we are shipping the product using only Jalopy style checks there is no need to parse the code.
Alternative A: Integrate a command line interface that runs separately from the BlueJ extension.
Advantages: A command line interface would allow for automated testing, and beautifying multiple Java files at once, if needed for a grader.
Disadvantages: It would require more development time and because we are not developing this for a grader the time taken to implement this feature is unjustified.
Alternative B: Only develop a BlueJ extension.
Advantages: Requires less development time.
Disadvantages: Does not allow for automated testing.
Decision: Alternative B. The need for a command line interface does not outweigh the need to get a working product out to the customer fast.
Alternative A: Progressive formatting.
Advantages: Formats the code on the fly.
Disadvantages: Progressive formatting is very process intensive. The amount of time and effort we would put in to have it format on the fly is not worth having it format on the fly.
Alternative B: On demand formatting.
Advantages: Allows the user to format when he/she wants to, far less time to implement than progressive formatting.
Disadvantages: Does not format code that does not compile.
Decision: Alternative B. Getting a working product to the user as soon as possible is of higher priority than getting the extension to format code on the fly.
Sun Java Development Kit 1.4.2
Library: Jalopy version 1.5rc1
API: http://jalopy.sourceforge.net/jalopy/apidocs/index.html
Library: BlueJ v. 2.2.1 Extension
API: http://www.bluej.org/doc/extensionsAPI/
SRS - System Requirements Specification
|
|||||||||
| PREV NEXT | FRAMES NO FRAMES | ||||||||