Can software development really be automated?
Yes it can – definitely!

Listen to Lisa’s experiences in this short video.

Cut development time in half – or more!

It’s ”just” a matter of combining tools and principles so that you can write code at a higher abstraction level than before. Both your domain experts and your developers cooperate in a far more direct way that traditional software development. The result is a development process that runs in parallel instead of in sequence.

”Domain-Specific Modeling raises the level of abstraction beyond programming by specifying the solution directly using domain concepts. The final products are generated from these high-level specifications. This automation is possible because both the language and generators need fit the requirements of only one company and domain. Your expert defines them, your developers use them.”

DSM Forum

A few of the things that make this strategy so efficient are:

  1. Specification changes and additions will take effect immediately, or as fast as you build process is capable of. This leads to faster turnaround time from idea to testing to delivery.
  2. Developers can focus on providing frameworks, code libraries, user experience and algorithms, making best use of their expertise.
  3. Both domain experts and developers work in parallel thus avoiding much of the communication overhead of transferring ideas and concepts between each other.

The end result is that your software development project will be finished a lot faster that before – and also to better quality.

Generate code from a specification

There are three main components in The Automated Software Factory™.

  1. Specifications written in a declarative format, that is tailored specifically for your business content.
  2. Templates for your selected programming languages.
  3. A Source Code Generator that combines specifications and templates into fully generated source code.

The last piece is to automate this so that the ”factory” is executed whenever a new model is committed to the code repository.

You get full tracking and control over what source code change a certain model change contributed with, since moth models and resulting code can be in the same commit.

Your domain experts write models

This is typically something that they already do. All software projects need to have some kind of specifications. The difference here is that declaratice models are written in a format that is readable by humans as well as by a program. The actual syntax for these models are of course specific to your particular problem domain, but are in plain text format, just as this example:

Since the models are written i plain text, they can be processed like any other source file. Your normal text editors and tools can use common functions such as line comments, block comments, text replacement, search, diff and more. All of this means that you will have full control of their content and life-cycle, the same as for regular source code files.

Note that these models does not contain any assumption on what actual implementation they will result in. They ”just” specifies the content and behavior of your software application.

Your software experts write frameworks

Instead of having your software experts to read specifications and convert them to source code, their time is now freed up to focus on more important things – frameworks and templates. The templates are used by the automation process to generate code directly from models. This means that any template change will take effect immediately to all generated files without the hassle of refactoring one file at the time.

Your developers will now be in full control over the implementation and how frameworks are being used.

Automating for the future

When it comes to software products there is no such thing as ”deliver and forget”. All software contains issues that needs to be fixed, whether its plain bugs, changed requirements of additional functionality.

Maintaining software is so much easier when your models are written in declarative syntax and ”live”. Changed requirements can often be handled by a simple change to the models and, since the code is generated, much less likely to contain regression bugs.

Also, taking your product to the next level by adopting to some new and better framework or functionality will also be a lot easier. Your developers can work on new implementations without breaking any of the business intention, since all business content will be specified in your models, not hidden in a lot of source code.