We use DSLs to gain insight in your software and help make a future-proof implementation.
What to do when a legacy system becomes too expensive to maintain or to add new functionality? Rebuilding the leagcy system from scratch will be expensive, error-prone and maintenance-intensive.
Domain knowledge forms the foundation of the Swat.engineering Methodology for legacy systems:
Our first step is to deeply explore all knowledge we can collect about the system, ranging from interviews with developers to automatic analysis of source code and documentation. The result will be a map of all the concepts and their relationships that are implicit in the system.
Based on this insight questions can be asked and next steps can be planned. What are the components of the system and how do they interact? What is the quality of each component? How could replacements be staged?
One approach is to automatically transform parts of the legacy based on the acquired domain knowledge.
Another approach that can be applied to many of the components is to design a domain-specific language (DSL). A DSL captures the domain knowledge and allows to flexibly express desired functionality. Using this DSL, the functionality of the software components to be replaced can be described concisely. These component descriptions are at a high level and can be understood and reviewed by experts from other disciplines such as marketing, finance, legal and auditing.
These high-level descriptions are used for simulation, visualisation, validation, and code generation.
The net effect: gained insight in your software and the components that were in most need of replacement have been reimplemented with future-proof technology.
Contact us at [email protected] to discuss your specific situation.
Recent posts
Any substantial change to critical software should be backed by a high confidence in correctness. Testing can be difficult when working with existing software systems. Automated tests might be sparse and hard to write effectively, while manual testing practices are often error-prone and labor-intensive.
During the reverse-engineering of legacy systems, in particular, correctness can be challenging to define and components might interact in non-obvious ways. Therefore, simply “writing tests” is not as simple as it sounds.
I write a lot of Java. These days, I use Visual Studio Code. Sometimes, I see a variable but do not remember its initial value. No worries: I just put the cursor on the variable, press F12, and watch the editor navigate to the declaration. It’s called Go to Definition in Visual Studio Code. Many other IDEs have it, too, and for many other languages. It’s a very useful feature. So… Should IDEs for DSLs have Go to Definition as well?