Posts tagged ‘Eclipse’
Martin Lippert is a senior consultant and coach at akquinet it-agile GmbH. His main work and research focuses on Agile Software Development, Refactoring, Eclipse-Technology, OSGi, Spring and Aspect-Oriented Programming.
What exactly is reverse engineering? In a general sense, reverse engineering is simply an effort to try and recreate the design of a product by examining the product itself. Reverse engineering is the process of asking “how did they do that?” and then trying to do it yourself. In terms of software however, reverse engineering involves examining what a piece of software does, and how it does it.
This book covers many diverse topics. It starts with a discussion of common “reverse engineering tools” such as disassemblers, decompilers, and debuggers. It moves along to discuss low-level details of common system architectures and file formats. It then proceeds to talk about details of the compilation process, and how high-level code becomes low-level instructions.
Unfortunately, the title “Disassemblers, Debuggers, System Architectures, File Formats, Compilers and Low-level code Generation” doesn’t roll off the tongue as well as “Reverse Engineering” does.
Many architectural languages have been proposed in the last fifteen years, each one with the chief aim of becoming the ideal language for specifying software architectures. What is evident nowadays, instead, is that architectural languages are defined by stakeholder concerns. Capturing all such concerns within a single, narrowly focused notation is impossible. At the same time it is also impractical to define and use a “universal” notation, such as UML. As a result, many domain specific notations for architectural modeling have been proposed, each one focussing on a specific application domain, analysis type, or modeling environment.
These considerations led us to propose DUALLy a framework to create interoperability among ADLs themselves as well as UML. As conceptually shown in the figure below, DUALLy permits to transform concepts of an architectural model M1 into the semantically equivalent concepts in the architectural model M2. Each Mi conforms to its MMi meta-model or UML profile. Every MMi can be a meta-model of an architectural language. Therefore, DUALLy works at two abstraction levels: meta-modeling (upper part of the figure), and modeling (lower part of the figure).
At the meta-modeling level, model driven engineers provide a specification of the architectural language in terms of its meta-model or UML profile. They then define a meta-transformation so as to semantically relate architectural concepts in MM1 with the equivalent elements in MM2.
At the modeling level, software architects specify the SA using their preferred ADL or UML-based notation. DUALLy allows the automatic generation of model-to-model transformations which permit the software architect to automatically translate the M1 specification (written according to MM1) into the corresponding M2 model (conforming to MM2) and viceversa.
As it can be noticed in the figure above, the meta-transformation (and its corresponding generated transformation) relates MM1 to MM2 (as well as M1 to M2) passing through what we refer to as A0. A0 represents a semantic core set of modeling elements, providing the infrastructure upon which to construct semantic relations among different ADLs. It acts as a bridge among the different architectural languages to be related together.
DUALLy is automated and implemented as an Eclipse plugin. MMi meta-models are expressed in Ecore. MMi profiles can be realized using any UML tool which exports in UML2, the EMF-based implementation of the UML 2.0 meta-model for the Eclipse platform. A0 is represented as a UML profile. Transformations among meta-models/profiles and model-to-model transformations are implemented in the context of the AMMA platform. Model-to-model transformations are then automatically instantiated, thus providing the possibility to automatically reflect modifications made on a model designed with one extension to one or even all of the other extensions.
The main advantages DUALLy exposes can be summarized as follows:
- DUALLy works at two abstraction levels, providing a clear separation between model driven experts (the technical stakeholder) and software architects (the final users). The model transformation engine is completely hidden to a software architect, making DUALLy extremely easy to use.
- DUALLy permits the transformation among formal ADLs and UML model-based notations and viceversa.
- Software architects can continue using familiar architectural notations and tools, and reusing existing architectural models.
- DUALLy permits both languages and tools interoperability.
- The meta-transformations among two architectural notations are defined once, and reused for each model that will be made.
Further details on DUALLy may be found by navigating the “framework” left-menu of this site.
This work is partially supported by ARTDECO (Adaptive infRasTructure for DECentralized Organizations), an Italian FIRB (Fondo per gli Investimenti della Ricerca di Base) 2005 Project.
BeContent is a new way of designing data-intensive web applications. It is not a Content Management System, it is not an emulation of PHP Nuke, it is not similar to Joomla. beContent is a Model Driven framework which allows you to design your own data and to generate the application around it.
beContent is based on sound and formal foundations which are the result of the work which has been carried out by the he MDD/Software Engineering and Architecture group at the University of L’Aquila , Italy.
From a code point of view, Equinox is an implementation of the OSGi R4 core framework specification, a set of bundles that implement various optional OSGi services and other infrastructure for running OSGi-based systems.
More generally, the goal of the Equinox project is to be a first class OSGi community and foster the vision of Eclipse as a landscape of bundles. As part of this, it is responsible for developing and delivering the OSGi framework implementation used for all of Eclipse. In addition. the project is open to:
- Implementation of all aspects of the OSGi specification (including the MEG and VEG work)
- Investigation and research related to future versions of OSGi specifications and related runtime issues
- Development of non-standard infrastructure deemed to be essential to the running and management of OSGi-based systems
- Implementation of key framework services and extensions needed for running Eclipse (e.g., the Eclipse Adaptor, Extension registry) and deemed generally useful to people using OSGi.
As a peer of the Platform, JDT and PDE projects, the Equinox OSGi code is managed by the Eclipse PMC and ships with the Eclipse project major releases. The various other bundles developed here may ship independently and on different schedules.
Did you come here expecting to find the Equinox Technology project? It has been transitioned. See the transition documentation for more details.