An Introduction to Eclipse Generation Factories
In order to improve software development industrialization, a major step consists in mass-producing software. This mass-production must be customizable, and must be able to support complex, large-scale and heterogeneous generations. Given the today’s available Eclipse tools, the issue here is not to provide either a new transformation engine or DSL editor but to realize their integration for flexible software mass-production. This is the purpose of EGF (Eclipse Generation Factories), a proposed EMFT component.
EGF federates generation around the pivotal element of factory component. A factory component is a unit of generation with a clear objective of generation. It has a contract to declare the factory component parameters. Contrary to a classic generation which aggregates all the generation parameters, generation data are organized by viewpoints, such as generation pattern, license description or deployment declaration. Altogether, viewpoints explicitly configure all the generation parameters. The generation orchestration is defined by a production plan. A generation step of the production plan can either be a Java task or, by assembly, an invocation to another factory component. A factory component can be edited and executed.
A factory component encapsulates generation know-how. A portfolio is a consistent set of factory components with a common generation objective, valuable for a development team or a user community. The purpose is to create off-the-shelf factory components. For instance, a technical infrastructure factory provides all the needed mechanisms for an application development (e.g., transaction management, persistence policy).
Example of customization with generation patterns
The following figure exemplifies a generation by factory component assembly: some factory components have an assembly role while others generate. This generation reuses a viewpoint provided by EGF, a M2T (model-to-text) generation pattern viewpoint for the definition of generation patterns. Those generation patterns, Jet-based today, supports pattern inheritance. This means a M2T generation can overload another one. In this example, by default, the EMF model/edit/editor generation is applied. It can be specialized by inherited patterns. The same principle can be applied to other generations other than EMF, for instance to web services or documentation.
Figure 1. Example of factory component assembly
Next figure presents the EGF perspective. With the view on the left-hand side, the factory component developer develops his own factory components, while with the view on the right-hand side he visualizes the deployed and reusable factory components. This figure shows the viewpoint/orchestration structure of a factory component and the generation delegation between factory components with parameter passing.
Figure 2. The EGF Perspective
Two levels of factory component development
As presented in the previous example, the most natural way to put factory components into practice is to develop and assembly factory components. The objective is to create valuable factory components, either for one’s team or larger development teams, and to reuse them in different generation chains. The issue is to figure out generation practices, how to implement and compose them with factory components, and the generation variability.
Factory components can be used to address simple generations. But flexibility and customization need more sophisticated mechanisms. For meeting this need, EGF offers the ability to extend the default factory component structure and generation behavior. i) One can add its own viewpoints in order to add new generation data structures, and to augment the capability to parameterize generations. This implies associated factory components are able to use those new viewpoints. ii) One can add its own orchestration types. This means orchestration is not restricted to a unique orchestration notation and engine.
Industrialization of large-scale development cannot be sum up to a succession of generators. It involves an architecture description of core components, technological generation components with their extensions, and the definition of their generation lifecycles. EGF brings one stone to the tooling aspect.
Paradigm shift with EGF
We have seen the ability to build complex chain with factory components. Now, from the software engineering viewpoint, the next step is to realize a tool- to technology-oriented software development paradigm shift. From the final user, the issue is not to develop software with a set of defined tools, but applications based on technological solutions (e.g., generation of an application infrastructure) reusable in different application contexts. The concern of the generated technological solutions is to federate and encapsulate a set of involved tools. This allows to better abstract software development. Tool and technology experts develop lower layers while application developers reuse available solutions.
This paper has presented the pivotal element of factory component for capitalizing software generation, has introduced the architectural dimension of complex generations with a factory component-based development, and the tool- to technology paradigm shift. This gives an overview of the EGF proposal and its technical scope.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)