Technological Choices

Technological Choices

Roberto Paiano (University of Salento, Italy), Anna Lisa Guido (University of Salento, Italy) and Andrea Pandurino (University of Salento, Italy)
DOI: 10.4018/978-1-60566-300-5.ch011
OnDemand PDF Download:
$37.50

Abstract

Referring back to how much was described in the preceding chapters, we introduce in this chapter the technological choices made up in order to address the requirements to realize a tool of support to the designer applying the proposed methodologies, and that it allows to export, according to the selected design choices, using the ontological language OWL (W3C, 2004), the realized design., We also want to provide in this chapter a technological scouting related to the choices made up for realizing the code generator.
Chapter Preview
Top

Technological Choice For The Realization Of The Editor

The choice of the technology made up for the realization of the design tool to support the methodology is a very hard task because the technology must allow the realization of a tool easy to use that, in the meanwhile allows to manage the whole intrinsic complexity of the methodologies previously defined. The technological choice in this job is Eclipse™ Platform.

The Eclipse™ (//www.eclipse.org/) project was originally created by IBM® in November 2001 and supported by a consortium of software vendors. The main goal of the project is the realization of a software development platform that is very modular and extensible. Eclipse™ is entirely written in Java™, and it is available therefore for all platforms.

Despite that Eclipse™ was developed as a development environment for Java™ projects, really its elevated modularity allows its use as an environment of generic development: other programming languages as C and C++ are supported (also thanks to the plug in CDT™, “C/C++ Development Tooling”™), XML and PHP. However, the great flexibility of such a platform has allowed realizing plug-in (Eclipse Visual Editor™) for the graphic design of the graphic interfaces of the Java™ applications, making the Eclipse™ environment a RAD (rapid application development) environment.

The modularity of Eclipse™ platform is made up through the architecture introduced in Figure 1 in which it can be seen how all of its components are plug-in.

Figure 1.

Eclipse platform architecture

The core of the architecture is the platform runtime, that represents the kernel of Eclipse™ through which the operation of the environment and the start of the plug-in contained in it are guaranteed. The workbench module defines the whole work area with which the user interacts; this area is made up through the modules devoted to the graphics and those devoted to the manager of events (JFace and SWT). The workspace represents the work area that is the part of file system that Eclipse™ uses to save the projects and the configuration files.

Help system and team support defines other functionalities available in order to provide support for the realization of documentation (contextual help) and for the execution of the work in team (through CVS or concurrent version system).

The modules just described provide some base functionality to the platform, while the two modules showed on the left, Eclipse JDT™ (Java™ development tools) and Eclipse PDE™ (plug-in developer environment), provide some specific functionality.

The first one is made up by a set of plug-ins useful to provide all the functionality of a Java™ IDE (integrated development environment): they add to the workbench functionality of editing, compilation, execution and debugging of Java™ code.

The second is the module thanks to which it is possible to realize further plug-ins for the platform.

The Eclipse™ platform is therefore a layered architecture made up of four levels, as it is possible to see in Figure 2.

Figure 2.

Four layer architecture of the Eclipse platform

Complete Chapter List

Search this Book:
Reset