Solution Specific Languages (SSL) - Ab Initio Architect

You are here

By Arnon Sela

Introduction

Change is an integral part of an agile development paradigm.  Without the ability to quickly adapt to changing requirements, short cycles of development become either very limited or unrealistic all together. 

Some of those changes involve accommodating variances in the input data; such as, a new field in input table or a new tag in XML files.  In my experience, realization of most of these variances occurs in a late stage of the project; when upstream systems are ready to produce example data.  Although these changes may appear to be small and simple, the domino effect they may produce on coding and testing can become substantial.

IT system development Ab Initio software developer SSLOne method that allowed me to quickly adopt changes is the use of code generators that are specific to the solution space.  These code generators are of two types.  One can be compared with common languages compilers (Figure 1) in which run-time artifacts are produced as part of the development process. The other approach is similar to just-in-time compilers where the generator is embedded within components (Figure 2). The SSL JIT evaluates the specifications at system startup.

Ab Initio, with its good functionality of textual processing and ability to read a variety of data sources coupled with the ease of building template programs, makes it easy to create such mechanisms.

SSL Compiler

The products of the code generators, in this case, Ab Initio artifacts XFRs and DMLs, are being used within graph components to make the solution. We refer to such code generators as SSL compilers, and they are usually used as development tools.  After writing the SSL compiler, its great benefit is the ability to quickly generate large amounts of artifacts upon changes in the requirement document.

SSL compiler mechanisms are used in conjunction with template graphs.  The graphs are built parallel to the development of the compiler in order to host its products.  The template graphs and the products of the SSL compiler create the run-time solution.

SSL JIT Compiler

In the case of a JIT compiler, components’ code is produced in whole or in part at the startup of the graph. SSL business software development, business data solutions USA TX

When the components are evaluated for their run, the SSL JIT compiler reads the specifications.  According to its configuration and the specifications, the compiler produces the appropriate code – XFR or DML.

At each startup of the system, solution’s specifications are reread and relevant code is reproduced.

Solution Specifications

The source data, solution specifications, for the generator is a set of directives that tells the generator how processing needs to be accomplished.  The generator reads this directive information, evaluates the conditions, and produces programs. 

The set of directives, that allows someone to describe how the solution should work, makes the Solution Specific Language.  It is important that the language structure and its medium of delivery be easy for the intended users who would describe the solution with it.

The medium I use to express the specifications in SSL varies.  They have been MS-Excel spreadsheets, Database tables, and MS-Word.  From my experience, the best result is when the professional who uses the medium is the one who completes the definition of the SSL.  After all, the more comfortable with the tools one is, the stronger chances for precision.

Solution Specific Languages are a subset of the more general purpose Domain Specific Languages.  They make it simpler to describe a software solution by using the domain terminology.  Domain Specific Languages are created to address all that is needed to be expressed in a domain (such as SQL), which means that a DSL is made as generic as possible.  As a result, DSL compiler is sophisticated and complicated.

In opposition, the scope of SSL is kept simple and limited to the solution space, which is usually a small segment of the domain.  As such, the SSL can be more tuned to the vocabulary used by the business analyst, thereby allowing the analyst to express completely his/her direction for processing that solves the problem at hand.  Narrowing the language scope simplifies the mechanism needed to process specifications written in the language, and therefore, makes it easier to produce a compiler to it. 

Benefits of using SSL

The benefits of using SSL are as follows:

1.  Quicker time-to-market of enhancement in the requirements tied to the ability to quickly address changes. 

There are two aspects to consider in this category.  One is change that can be represented with the existing SSL. The other is change that uses new semantics not present in SSL.

The first type of change requires re-compilation only, if using SSL compiler.  In case of SSL JIT, restarting the system is the only thing required.

The other type requires enhancements in the compiler and then re-compiling the enhanced specifications.  Usually, this is much simpler than enhancing numerous artifacts manually.  Moreover, it is a much safer approach that yields higher quality. 

2.  The creation of automated programming mechanisms. 

If we consider programming as the mechanism to translate specifications into executing artifacts, conventional mechanisms have many points of failures due to the manual translation of requirements into programs.  These are at least one cause for a slower pace to create a high quality solution.  With SSL as a mediator, points of failures are reduced to the specifications and their SSL compiler.

Performance Considerations

Some people may worry over performance suggesting that the code generated using SSL compilers may not be as efficient as writing it directly (by hand).   My experience demonstrates this is not the case. 

As in any programming practice, one needs to pay attention and plan for the performance of the SSL, its compiler and artifacts, and the hosting graphs (the resulting system consuming those artifacts).

When planned well, the development process (specifications, programming, and testing) can be dramatically reduced compared with conventional tools.  The resulting system will perform as fast as any other system developed conventionally or even better due to its higher quality.

Disadvantages of SSL

“No pain no gain.”  Since we talked about gains, we should also uncover the pains.

One main disadvantage of using SSL is related to expertise.  The concept of building a simple solution language and a compiler for it requires a great deal of abstraction.  Such capabilities come only with ample expertise and experience.  Thus, it is difficult to find professionals that are knowledgeable with this concept.  Once you find the right people, however, the gain far outweighs the pain.

Regarding the maintenance of the system, as long as enhancements to the system can be covered by the SSL, changes become simpler and quicker to deploy than otherwise can be done.

If the changes require enhancements to the SSL, more experienced people will be required to attend to the enhancements.  However, the nature of the changes will predict the level of expertise necessary.

Although it is easier to fall back and deploy changes in the artifacts themselves, this will invalidate the SSL and the compiler, thereby foregoing the benefits they bring.  It is therefore highly recommended to avoid this path. 

Even with the need for experienced and qualified personnel, it is clear that SSL’s benefits far outweigh its few disadvantages.

Conclusion

Following my experience of developing in a wide range of programming languages and paradigms, the most successful projects are those where the solution bridges between the business language and the technical deployment.  In the longer term, it eases maintenance and support.

Developing SSL as part of the project and incorporating it into the solution create that bridge.

A skilled architect and a proficient business analyst armed with Ab Initio capabilities can make such project strategy successful.

Try it out in your next project.

References

1.  Notable design patterns for domain-specific languages, by D. Spinellis, the journal of systems and software 56 (2001) 91-99

2. Language Design Patterns: Techniques for Implementing Domain-Specific Languages, by T. Parr, 2009

3.  When and how to develop domain-specific languages, by J. Heering and A. M. Sloane, 2005

About the author

Arnon Sela has more than 20 years of information technology experience in a wide range of competencies – from programming through management.  Arnon was involved in many large and small development projects that joined hundreds of personnel around the world.  Recently, Arnon as Ab Initio architect expert is focusing on improving IT shops with the use of the Ab Initio computing environment. Arnon realized that use of such an environment is more powerful than the traditional methods of IT.

Comments

Esther (not verified)
May 13th, 2014

AB INITIO design integrates processes whose efficiency significantly improve big data information for client efficiency.

Leave a Reply

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters shown in the image.