The project architecture is based on the MVC (Model-View-Controller) design pattern, implementing the well-established concept of separation between data and presentation layers:
The Conversion engine API constitutes the data Model. It contains only raw data and pure logic for manipulating it (i.e. performing conversions). The data is accessible via a designated API.
The Eclipse SWT GUI is the data View, which presents data retrieved from the model in various ways. It handles all GUI aspects such as data presentation, menus, GUI elements, user actions, etc., and does not contain any data manipulation logic.
Communication between the model and the view is bi-directional and done via the Controller, which updates the model from the view and vice versa based on user actions.
Core conversion engine: main API for performing data conversions. Activates conversion subcomponents such as simple and complex conversion objects.
Conversion objects (clusters): classes for performing simple conversions. These will be used as is from the existing NumericalChameleon application source code.
Specific conversion modules: additional modules for performing more complex conversion tasks, such as exchange rates or translations.
Eclipse SWT GUI: Eclipse Plug-In View written in SWT, for representing data and handling user actions.
Eclipse IDE Integration: a module containing implementations for various Eclipse Extension Points, for IDE integration (refactoring, editing, etc.).
A bridge between the aforementioned conversions Model and SWT View. Invoked upon user actions to update model from view or vice versa.
The project’s essence is converting a stand-alone open-source application into an eclipse plug-in. As such, it will be developed exclusively using the latest version of the Eclipse SDK (currently Stable Build 3.0M8) and its Plug-in development environment (PDE).Eclipse homepage
Eclipse donwloads pageEclipse plugin development homepage
In compliance with these specific development environments, and the original Numerical Chameleon application, code will be written completely in Java, with GUI elements written using the Standard Widget Toolkit (SWT). Following these guidelines, this project will be inherently platform independent.
As previously detailed, the project architecture can be broken down to three main components: the Data Model, the Data View and the Controller. The Data Model and Data View components can be developed virtually independently of each other and therefore should be completed simultaneously, whereas the Controller bridges both aspects and therefore can only be completed after both have been completed. This basic break-down can be used for the initial project scheduling, with Netta taking over the View aspect of the project, and Erez working on the Model aspect. The Controller, being the final aspect of the project to be developed, will be a joint effort of both developers.
Both main components will be developed in a logical top-down approach, on a six week schedule (starting June 1st).
Eclipse SWT GUI – Weeks 1-3. Since the original Numerical Chameleon’s GUI has been written using the Swing package, it will have to be re-written for our Numerical Gecko plug-in. However, several aspects of the original application’s GUI will be omitted for the purpose of this project. These include elements that are valuable for stand alone applications but are useless within a plug-in application (for instance, view settings that determine the application window’s size) and elements that we feel are unnecessary even in the original application. One of the main selling points of our project has been the Hebrew translation, which has already been completed and incorporated into the latest Numerical Chameleon release (version 1.6). New additions to the GUI will include some improved elements (conversion of multiple values concurrently) and a new preferences mechanism, as detailed in the previous document.
Eclipse IDE Integration – Weeks 4-6. Along with integraion into existing extension points, new extension points will be added so that future developers may use the plug-in’s API for various uses (including, for instance, automated conversions).
Core conversion engine – Weeks 1-3. While the main API’s logic will not be changed, a lot of the original code will have to be re-written or re-arragned to work with the new GUI and other new features.
Conversion objects (clusters) – Week 4. Ideally, no changes will be made to any of the clusters, however, we will need to go over each and every one and verify its behavior. The idea is to use the existing NC package as is, so the plugin will be seamlessly compatible with future NC versions.
Specific conversion modules – Weeks 5-6. These additional modules will include translation and automated exchange rate updates, as detailed in the previous document. They will feature internet connectivity, and will also be contributed to the original Numerical Chameleon project.
Controller development should commence at the seventh week (approx. 15/7) and will be completed by the end of week eight.
These timeframes are pretty loose, and take into consideration outside factors such as work and school related commitments. Should Netta complete the View components prior to Erez completing the Model components, she may move on to developing new model features as part of the Specific conversion modules. Some ground work for the controller can also be done prior to the completion of both model and view aspects of the project.
We will attempt to keep as up-to-date as possible in regards to the latest versions of the Eclipse SDK and Numerical Chameleon. However, once development gets underway, the most recent versions of Eclipse and NC at that time, will be the versions used in the development of the Numerical Gecko plug-in. Should new versions be released during the development cycle, they will not be incorporated into this project, unless time allows it at the end of development.