...from simple text transformation, up to full domain-specific modeling
Refactoring in a traditional programming approach is the process of changing a program's code without changing its functional behavior. Through this practice you obtain improved code readability and reduce complexity, improving at the same time the maintainability of the source code through a more expressive architecture.
Like in traditional programming, you can refactor your ABSE models. And the same benefits apply. You can start with solution domain Atoms, like print, database, math, etc, which you will use to model your application at a lower level of abstraction. Then, you can progressively group these Atoms together to form higher level constructs, in intermediate domains, and finally at your problem domain.
This refactoring capability of ABSE makes it rather easy to start modeling with almost no upfront investment in the preparation of metamodel libraries, which is a big advantage over other model-driven development approaches. Many organizations dismiss model-driven development because of the perceived up-front investment to be made before something comes out of a model. That is not the case with ABSE. |
Examples
One simple example is when you have a new piece of code. Because it is new, you just create a custom-code Atom to include it in the project. However, as repeated usage of that code segment is detected, it can be turned into a reusable asset (an Atom Template).
Another example is when a pattern of Atoms is consistently used many times: This pattern will be regrouped as a new Atom Template (a new metamodel) which can then have its own parameters and construction constraints, turning those low-level, solution-domain Atoms into one high-level domain Atom. |
