The concept’s central element is a meta model. This model describes the variable parts of the application domain of the system family. It contains solely the variable parts, which differentiate the individual members of the family. In contrast to other approaches, invariant parts are not modelled in the HyperSenses meta model, the modelling effort is therefore reduced significantly. A meta model can be created in HyperSenses itself or created within an UML-case tool, imported via XMI interface and edited in HyperSenses if necessary.
… might be the most commonly used argument from software programmers against the usage of a generator. As the (generator) developer himself defines the target language and code as well as its formatting, this argument doesn’t hold in HyperSenses. The developer’s definition ensures the readability and maintainability of the generated code and the fulfilment of company-specific programming guidelines. Also important, the look and readability of the code increases the acceptance of the generator by programmers.
This is achieved by using code patterns which specify the language dependant parts of the generator. Such a pattern is derived from existing code (or code fragment), the underlying concept is called ‘pattern by example’. Existing implementations or prototypes, developed and optimised by an expert and possibly already usage-proven, are the basis for code patterns.
Derived code pattern, frame for C#
To create a code pattern, the code is searched for variable parts which differentiate single members of the system family. Those variable parts are exchanged by slots or optional code blocks which are linked to the meta model. Due to the linkage between meta model and slots respectively optional blocks it is only possible to generate code which is valid within the according application domain.
In this way, the expert knowledge is shared between all developers of the team, especially those with less experience, and can be easily reused and extended.
The meta model describes the variable parts of the application domain of the system family including their relationships. The code patterns describe the code to be generated and its formatting. Due to the linkage of the patterns to the meta model the necessary navigation is implicitly given.
Thus, the meta model and code patterns contain sufficient information to enable HyperSenses to automatically create the generator, i.e. instead of tediously programming the generator it is simply specified.
You’re an expert in building generators and expected a long description about the programming of the generator as usually when a new technology is introduced? Sorry, in HyperSenses you just have to press the correct button and there is therefore no need for a long explanation.
To create a certain instance of the system family, the generator needs to know how to calibrate the variable points. This calibration is task of a configuration which is described by a DSL. Generally, developing an extendable DSL and generator, where DSL and generator fit to each other, is nearly a secrete science. For this task, a developer needs significant knowledge about the creation of consistent languages and plenty of time. This is not required in HyperSenses. What can or has to be configured and how is specified by configuration patterns, i.e. they specify the DSL. Like code patterns they contain slots and block which are linked to the meta model. In addition to support the end user of the DSL it is possible to add explanatory text within the configuration patterns.
Similar to the generator which is specified by the meta model and code patterns instead of being programmed, the DSL is created automatically from the meta model and the configuration patterns whereby grammar and syntax are implied by the meta model.
Depending on the DSL’s complexity the familiarisation effort for the language can be quite high until a first configuration can be written. HyperSenses bypasses this obstacle by introducing form-DSLs which are similar to electronic forms known from the internet for example. Such a form-DSL is easy to read and fill-in for the user and unambiguously evaluable by the generator, particularly only syntactically and grammatically correct input is possible. To further improve the readability of a form-DSL, its optic can easily be manipulated.
As soon as a part of the meta model exists, the patterns (code as well as configuration) can be developed. This development can be done distributed. It is possible to change, extend or enhance the meta model and all patterns at any point in the development process with only little effort. Likewise, it is possible to create an executable generator and/or DSL which can then be tested at any time. Thus, HyperSenses supports a stepwise development as e.g. required when agile methods come into play.
HyperSenses can be run as stand-alone tool as well as integrated into another development site like Eclipse or VisualStudio. It is also possible to exchange the meta model with other case tools via HyperSenses’ XMI interface.
White Paper - HyperSenses
White Paper about HyperSenses: HyperSenses simplifies the development of generators and DSLs and supports their stepwise and distributed development. First results are obtained, testable and reproducible within hours or a few days instead of weeks as usual. Therefore HyperSenses enables the development of generators and DSLs for agile methods.