We always recommend drawing out the system to be created using a graphical tool first. This helps to visualise what the components at different levels are and how they fit together. We suggest using the Matrix notation since it has a complete and meaningful mapping to the Matrix language.
Converting a graphical model to a text model should be a process of consolidation. Usually, Entity Relationship and State Transition diagrams are drawn. Drawing out Process Flow diagrams is not considered worthwhile as this is best done in Matrix code.
In the typical software development process a programmer writes source code in a programming language which is compiled into an executable that runs on a computer. The code will have an implicit software architecture embedded within it and if another architecture or language is wanted then the entire program has to be rewritten.
In the Matrix software development process the source code is automatically generated from an implementation independent Matrix model by the Model Compiler.
The Matrix code must be free of implementation details because the implementation such as target language and architecture is added later by the Model Compiler during the process of code generation.
If a Matrix model is that of an application then an application is generated. If the model describes a Model Compiler then a Model Compiler is generated. The software development process for both is identical.
A key point is that the application's language and structure is defined solely within the Model Compiler and this is true when the application is itself a Model Compiler.
This means that the generated Model Compiler's functionality is independent from the host Model Compiler's functionallity. So, a host Model Compiler which is written in C (or any other language) can generate a target Model Compiler which is designed to generate Java (or any other language).
Matrix Model Compilers have three components. The first is the Transformer whose purpose is to parse the Matrix code for syntax errors and to compile the model whilst checking for semantic errors.
The output of this process populates the second component, which is confusingly named a Meta Model. From a Model Compiler constructor's point of view the Meta Model is just a number of record structures or database tables.
However, from the Model Compiler user's point of view it is indeed a Meta Model. The confusion arises from the fact that the Model Compiler creator regards the Model Compiler as an application, whilst the Application writer regards the Model Compiler as a Model Compiler for their application!
The third component is the Generator. Its job is to take the contents of the Meta Model and to produce the source code by a process known as Translation. The Generator is constructed from models that describe the software architecture and code structure of all the applications that it generates.
Seen in its correct context, a Model Compiler exists on the level above the application model it compiles. According to the Matrix Analysis Diagram, a Model Compiler is defined at the meta model level, M2 and applications are defined at the model level, M1.
Of course, a Model Compiler that is used to compile an application must itself have been compiled by a Model Compiler that exists at the Meta Meta Model level, M3.
The Model Compiler's Model Compiler does not have to be one that generates C source code as shown here; any language would have been suitable.
This chain of Model Compilers can be traced back to the first Model Compiler called the Bootstrap Model Compiler.
New Model Compilers are evolved from existing Model Compilers and as more Model Compilers are developed existing Model Compilers move to the left so that application models always exist at the model level, M1 and the objects they manipulate in the Real World at M0.