The Matrix Language is the language of the Analysis Design Matrix which is shown in the Matrix Diagram and described by the Matrix Theory of Software Engineering.
Matrix is an abstract language that is designed to be translated to any programming language, such as C based languages including Java and other languages such as Ada and VHDL; although it is possible to create a Matrix language interpreter.
Working at the analysis level of abstraction, Matrix has no programming level concepts such as arrays, pointers and global variables of customary 3GL code. It does, however, have similar or overlapping concepts such as local data and assignment statements that are used by the analyst to specify how for example, entity attributes are calculated.
Modeling is a different activity to that of programming. The language concepts dealt with during modeling are different to those being dealt with during programming. When a program is being written, that's called programming not modeling. When a model is being created, that's called modeling not programming.
Matrix models are never called programs because models and programs deal with different semantics. However, the actual text used to describe a Matrix model is sometimes called code.
Although development with a textual language is more efficient, it is strongly advised that to properly visualise a model a graphical tool is required.
Building models with Matrix lets the analyst think and work at higher levels of abstraction.
The Matrix language is structured and formatted to allow the analyst to express each fact about the Real World in just one place and what's more, in only one way.
Matrix is a very scalable language that purposely constrains the writing and presentation of code while allowing the analyst a great deal of scope to express extremely large and complex systems for which it has been especially designed.
Most coding style rules are enforced by the Matrix language simply by the type of statements employed and their structuring. Other rules are enforced by the Model Compiler.
Matrix code requires no acronyms or object identifiers, though signifiers may appear to perform a similar purpose. A signifier, such as "Robot", means use the Robot object that is currently in context. It does not represent the actual object itself, although this may be the effect. Similarly, Robot.Distance means use the Distance attribute of the Robot object currently in context.
Unlike other action languages, objects can only be present as part of entities. This means there are no conceptual problems involving redundant copies of objects, simply because they cannot be copied.
A textual modeling language makes refactoring, searching, merging and establishing the difference between two model versions relatively easy using common tools (compared to graphical models).
The purpose of Matrix language statements, like graphical tools and other action languages, is simply to populate higher level metamodels. It is the purpose of the Model Compiler to generate code from these metamodels.
Each Matrix model is well structured and statements are laid out in a very similar fashion. A simplified view of the language's high-level system structure is shown below:
Not only does this show how the statements relate together but also how the underlying entities relate to one another in the constraints of the language syntax.
Matrix Language statements are grouped according to their complexity or the subject areas they address. Below is an overview of the types of statements that presently exist in Matrix:
Professional Edition Statements
Not all Matrix statements are available in all editions of the Matrix Model Compiler. The free Learning Edition has all the primitive statements along with a selection of other statements but no pattern statements.
The Professional Edition comes with all the statements in the Learning Edition plus pattern statements and some other advanced statements. Statements that are not available in the Learning Edition are shown in italic.
UML Diagram Notation Conversion
Unfortunately, the existing de facto UML notation is sub-optimal for Matrix analysis. Instead, the notation used in the Shlaer-Mellor method has been enhanced for use with the Matrix language. For completeness, the names of the Shlaer-Mellor diagrams have also been included in the table below:
||Executable UML Notation
|Domain Bridge Diagram (DBD)
|Entity Relationship Diagram (ERD)
|State Transition Diagram (STD)
||State Transition Diagram
|Process Flow Diagram (PFD)
||Action Data Flow Diagram