Introducing the Software Factory

I’ve been providing bits and pieces of information about the Software Factory and what it does in my previous posts. I’ve stated that it is used to generate the entire system, but I’ve been quite vague about how this is done.

In this post, I will start laying out how it works.

What is in a name?

I use the term Software Factory very loosely. Maybe I lack imagination, but I still have not found a better name for it over all of these years.

To me, Software Factory is a term, not a name. It is like Command Line Interface (CLI) or Integrate Development Environment (IDE). I often refer to it as SF.

Software Factory has been used to represent several things in the past in the industry.

But I think it really applies to what I’m describing here. I define a Software Factory as:

A system that automates the manufacturing of software or software parts

How does it work?

I’m sorry, but there is no AI here. The only intelligence required is from people. This is just a computer system that does what computers do best: Perform massive amounts of small, menial tasks over and over again.

At a high level, the Software Factory is pretty simple. The SF takes in two inputs: Models and Solutions. And it processes this information to produce code.

The following diagram shows the major pieces:

Software Factory – High-level diagram

Here is a list of those pieces and the role they play in the system:

  • Designer: A person who analyzes the problem space and uses models to describe it.
  • Models: Describes the expected content and behavior of the desired system.
  • Engineer: A person that defines the model(s) structure and uses solutions to describe how to convert it into the desired end product.
  • Solutions: Provides information to the code generation system on transforming models into code.
  • Code Generation: Mechanisms that apply Solutions to Models and model elements to generate code.
  • Results: Provides the results of the code generation.
  • Generated Code: This is the code generated by the system.

Models

Models are nothing new. They are tools used by people to describe and simplify complicated things surrounding us. We use them in pretty much every domain, including science, medicine, chemistry, etc…

By leveraging a specific set of models, the Software Factory offers users a tool to think about the problem space. It provides the user with the ability to document it so that the generation system can interpret it.

Models are the language used to communicate between the Software Factory and its users.

Solutions

While all the instructions to generate code could be built and compiled directly into the software factory, that would be very limiting.

For the SF to be flexible, Solutions are built with all the information required by the Software Factory to convert Models into source code. That makes it possible to write a generic system that can adapt to multiple different situations,

This flexibility means that we can modify the system at run time and re-use Models for different purposes, targets, and even entirely different programming languages.

Code Generation

This is the core of a Software Factory. The factory needs to divide the models into manageable pieces and apply Solutions to them to generate the pieces of code. Then it needs to assemble all those pieces into a set of files that is the source code for the generated software.

Results

Result provides information that describes the code generation operations. Each step of code generation reports status and error messages if relevant.

This information provides the final status of the generation operation.

In addition, this information can be helpful to the Engineer when designing solutions.

Generated Code

This is the final output of the Software Factory. The resulting code files are laid out as defined in the solution.

Simple right?

Well, this is a gross simplification. There is a lot of complexity that comes with each of those elements. As I will describe in future posts, the reality is much messier.

Add to that using multiple models, multiple solutions, multiple builds, and multiple results. Heck, sometimes just the sheer volume of information becomes problematic. There are a lot of challenges.

However, even now, we can start to see the tremendous potential of this technology.

But those are all stories for another post…

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: