that this was the greatest challenge of the thesis, as there were a number of trade-os to take between introducing certain improvements and making sure that none existing functionality gets lost during the process. Also, while there is still a lot to do when it comes to RED, I believe the outcomes of that thesis will be highly appreciated by anyone who will work with RED in the future.
6.3 Future work
In terms of what is left to be done, there are still areas for improvement when it comes to RED. First of all, while a lot of both high-level and low-level re-structuring has been done, some of the plug-ins may require more re-factoring.
As the main focus went for re-engineering RED architecture from high-level fea-tures (or modules) down to low-level plug-ins, but there was not enough time to examine each of the plug-ins separately and therefore to improve the code qual-ity within them. The reason for starting from a high-level approach was that restructuring RED at the module level would greatly contribute to improving the general architecture, as it would specify and enforce the contracts between various modules. Should we've started with improving the code quality in the individual plug-ins rst, we would most likely have run out of time to introduce the necessary high-level improvements, and therefore not satisfying most of the thesis goals.
Another improvement that could be made is a bit more thorough restructuring of the Core module. While the Core module implementation has been divided into a number of plug-ins, it may benet from further restructuring some of the contracts it introduces for the other modules to depend on. As Core module serves as the base of almost any other RED module, by making proper changes we may simplify the other modules, which will greatly aect the overall code quality. However, applying any xes and/or extensions to the Core module needs to be done with extreme care, as any change may unfortunately break the existing functionality. One potential improvement that could be made is to simplify the BaseEditor class, that is currently tightly coupled to an en-tirely custom BasePresenter class, which, unlike the editors or views, is not an Eclipse concept, and is therefore dicult to understand. As such implemen-tation enforces the developers to use a new, undocumented API, on top of an already complex Eclipse API, restructuring that will denitely make it easier to develop future extensions.
There are also problems related to the platform-independence of RED that has not been resolved as a part of the thesis. As pointed in [Fri12], when discussing various RichText editor implementations, an EPF RichText has been found the
most suitable and therefore used in RED. However, as it turned out during the restructuring process, EPF RichText is a platform-dependent solution, which does not work well on all the machines running either Linux or Mac OS. This is a clear example of a bad design decision made at the beginning of the development process, which resulted in severe consequences. As the support of rich text is one of RED most important features, it is not possible to simply remove it. Also, as EPF RichText editor is being used by almost any of the editors in RED, substituting it will be a major eort, not to mention the fact that there are not many other implementations that could be used. Either way, resolving that issue is of great importance if we want to maintain RED on non Windows-based platforms.
When it comes to additional functionality, it would be vital to implement a new Specication Element that would hold the model fragments and make it possible to associate them with other elements. However, in order to do that, a necessary improvement needs to be done in the ModelElements module, as it has proven itself to be unstable during certain circumstances. Fixing ModelElements would not only make it possible to convert it into another Specication Element, but would also contribute to xing the issues in both Reporting and Weaving modules.
Last, but not least, with introduction of Tool module type, we have opened an entirely new approach of integrating various Specication Elements together.
As for now, we do not allow various Specication Elements to communicate with each other directly, but only via either SpecificationElements or Core modules. However, by allowing such Tool modules, we provide an entirely new way of integrating the Specication Elements, by simply extending them with new functionality, such as an additional editor page, making it possible to associate various elements in a much more specialized way than simply using the generic RED association feature.
Bibliography
[Arn93] Robert S Arnold. Software reengineering. IEEE Computer Society Press, 1993.
[Bul12] Ian Bull. Eclipse juno milestone 7, available for download, 2012. [Online; accessed 2013-10-05].
URL: http://eclipsesource.com/blogs/2012/05/05/
eclipse-juno-milestone-7-available-for-download/.
[Fou] Eclipse Foundation. Osgi concepts. [Online; accessed 2013-10-03]. URL: http://www.eclipse.org/virgo/documentation/
virgo-documentation-3.6.2.RELEASE/docs/virgo-user-guide/
html/ch02s02.html.
[Fou13a] Apache Foundation. About subversion, 2013. [Online; accessed 2013-10-01]. URL: http://subversion.apache.org/.
[Fou13b] Eclipse Foundation. Pde overview - eclipse plug-in devel-opment environment guide, 2013. [Online; accessed 2013-09-30]. URL: http://help.eclipse.org/indigo/topic/org.
eclipse.pde.doc.user/guide/intro/pde_overview.htm.
[Fou13c] Eclipse Foundation. Target platform - eclipse plug-in development environment guide, 2013. [Online; accessed 2013-09-30]. URL: http:
//help.eclipse.org/kepler/nav/4.
[Fri12] Anders Friis. Basic tool support for requirements engineering. Mas-ter's thesis, Technical University of Denmark, 2012.
[Git13] GitHub. About github, 2013. [Online; accessed 2013-10-02]. URL:
https://github.com/about.
[Kra12] Jakob Kragelund. Advanced tool support for requirements engineer-ing. Master's thesis, Technical University of Denmark, 2012.
[McC76] Thomas J McCabe. A complexity measure. Software Engineering, IEEE Transactions on, 1976.
[Vog12a] Lars Vogel. Eclipse 4 application development : Eclipse RCP based on Eclipse 4.2 and e4. Vogella, S.l, 2012.
[Vog12b] Lars Vogel. Eclipse 4 ide not extendable via fragments or processors - bug report, 2012.
[Wik13a] Wikipedia. Acyclic dependencies principle, 2013. [Online; accessed 2013-10-05]. URL: http://en.wikipedia.org/wiki/Acyclic_
dependencies_principle.
[Wik13b] Wikipedia. Cyclomatic complexity, 2013. [Online; accessed 2013-10-05]. URL: http://en.wikipedia.org/wiki/Cyclomatic_
complexity.
[Wik13c] Wikipedia. Git (software) Wikipedia, the free encyclopedia, 2013.
[Online; accessed 2013-10-02]. URL: http://en.wikipedia.org/
wiki/Git_(software).