Skip to main content

NS Development Process

NS Application development relies on a 4-step development process.

  • Model your application
  • Expand the model to generate code
  • Customize the code to better accommodate your use-cases
  • Harvest to extract the customizations to insert during the next expansion

This process is repeated iteratively to rapidly build up the application, adjust it to new requirements and improve it with new insights.

Model​

Create an Application model that describes the structure of your application. You will be defining DataElements, TaskElements, FlowElements etc.

The models are stored in XML files and can be edited with an advanced modeling tool.

Expand​

Based on this model, the expanders will generate a source code project in a pre-defined expansion directory. This project can be built to create a basic application with a simple user interface to create, modify and delete data according to the model.

Expanders are extendable, so newly discovered patterns can be converted to new expanders to reduce subsequent work.

Customize​

The developer then modifies the code with customizations to implement use-cases which are not supported by the code generated by the expanders.

The customizations come in 2 forms:

  • Code can be added to the generated files in specific places called custom anchors. These are 2 comments that define the start and end of the custom code, like this: 
    // anchor:custom-pre-create:start
    doSomeValidation(details);
    // anchor:custom-pre-create:end
  • Custom classes can also be added in an ext directory. There are multiple ext directories in the project where new classes or other source files can be added.

Harvest and Repeat​

When you are satisfied with the customizations, you can run the harvest step. This will take all of your customizations and stores them next to the model files. The next time the application is expanded, these customizations will be reinserted into the generated files.

Working like this allows us to regenerate the code after it was modified, which has several benefits:

  • The model can be updated throughout the development process, giving much needed flexibility.
  • The expanders can be updated to provide bug-fixes, security fixes and new features, while keeping the customizations intact.

Benefits​

Evolvability​

The code generated by the expanders are built based on the NS theory. This theory gives us methods to pinpoint where possible issues might arrive due to new requirements and changes in the future.

These new requirements and changes are not always predictable and in typical projects they often lead to changes all over the project.

By studying these changes combining it with classic stability theory, the NS theory gives a framework to limit these _ combinatorial_ effects.

Decreased Development Cost​

An application can be described as a combination of concepts and features.

For example, you might have some concepts: Products, Orders and Customers. You then also need some features for each concept: persistence, user interfaces and validations.

To implement this functionality you will need to invest time in the order of:

N (number of concepts) x F (number of features) + C (some additional specific additions)

As your applications grows, this can become problematic:

  • New features require work to the order of N
  • New concepts require work to the order of F

The expanders remedy this situation by generating features based on a model. Concepts are modelled as elements. Features are implemented in expanders. The amount of work then becomes:

N (number of elements) + F (number of expanders) + C (custom code)
  • New features require you to write a new expander
  • New concepts require you to model a new element

In addition, you can reuse the work done on expanders provided by the framework, as well as work done in other applications!

Flexibility​

By iteratively modelling, expanding and customizing your application, it becomes simple to adapt to changes:

  • The generated code can be regenerated, unlike code-generators that you run once and then adapt.
  • Generated code is cheap, so adding a new field or element takes little effort for a lot of gain.
  • Likewise, redesigning the model only has effect on the custom code that was added on top of the elements that have now changed.
  • Expanders can be swapped out for other expanders through settings and options, making it considerably less painful to switch to different underlying technologies and implementations.

Structure​

Since all applications are generated with the same expanders and every element is generated in a similar way, it the source code gets a very predictable structure. This has several added benefits:

  • The code becomes easier to navigate
  • It easier to get into as a new developer
  • It becomes easier to communicate about aspects of the source code