Home   :   Matrix Language   :   Frequently Asked Questions

Frequently Asked Questions

 

Why doesn't Matrix use blocks, braces and semicolons like most programming languages?

 

Matrix had braces and semicolons in the early days but they were removed.  Braces let you put statements where you like and a semicolon lets you put a statement over as many lines as you like.  This is what programmers enjoy doing, usually to the detriment of other programmers who have other ideas; this is why coding style guides were invented.  When we built the Matrix style guide rules into the Model Compiler the need for blocks, braces and semicolons simply disappeared.

 

 

Is Matrix yet another programming language in the guise of a modeling one?

 

Matrix is a modeling language because the concepts (semantics) the analyst deals with during modeling are different to that of programming languages.  It's also an abstract language since Matrix models must be converted to a programming language and more importantly, they must also be translated via a software architecture that is defined by the Model Compiler.

 

Modeling is a different activity to that of 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.

 

 

Where are the design models in Matrix?

 

All design models are embodied in the Matrix Model Compiler.  Their purpose is to define the target architecture and language of any application analysis model that is to be compiled by the Model Compiler.

 

Since application design is a perfectly valid subject matter for analysis and all models are analysis models, design models are actually Matrix analysis models!

 

The application is modelled completely independently to its eventual design because the Model Compiler implements the design (defined in models) for the application in the translation process.

 

 

If Matrix is based on the Shlaer-Mellor Method where is the Software Architecture?

 

Matrix is founded on the principles of the Shlaer-Mellor Method.  The method makes a very clear distinction between analysis and design but placed a software architecture domain on the application’s domain chart.

 

The Analysis Design Matrix moves Shlaer-Mellor’s Software Architecture domain to the M2 level (Analysis of Analysis Realm) where it belongs as a peer of the OOA of OOA domain.

 

It had long been a puzzle as to why the Software Architecture domain (along with its implementation domains) was clearly a different kind of subject matter.

 

 

Why is the Hello World! program so long?

 

Say you need to dig a hole to bury your dead pet dog.  Do you get a shovel from the shed or rent a JCB?  The right answer is get the shovel.  In the same way, if you need to write a Hello World program, you don’t need a code generator, you don’t need to think about it very much and you can start hacking in C or Java straight away.  But what if you want to dig a hole for your Olympic sized swimming pool?  Obviously, a shovel is not going to hack it, although given enough time you could do it.

 

Instead you would choose the JCB, no question; because it’s got the capability and power to do the job.  Likewise, what if you need to produce an Aircraft Traffic Control system?  Would you bring up a text editor and start hacking in Java?  No, you would want to plan and organise what you’re going to do first, and that’s why you would want to build a Matrix model - it's designed to help you organise complex systems and then as a bonus generate the source code.

 

So why is the Hello World program so large?  The answer is that it's been built by a powerful tool that's required to enforce an infrastructure, an organising principle, on the code it generates and this shows up even when generating tiny programs.

 

 

It is not clear to me who your target audience is?

 

The target audience for Matrix are modelers (within medium to large companies).  These are developers, usually analysts but some programmers, who draw diagrams in UML to create models which encapsulate high level business rules in a more abstract way than a program written in C or Java would do.  The idea is that these models express the customer’s needs in diagrams using the same sort of language as the customer uses, so they can understand them better and change them before coding begins.

 

 

Who is responsible for the maintenance of the C code?  For example, if a piece of code doesn’t work do you change the model coding or do you change the C code?

 

If the Matrix model passes muster, the generated code will always compile without errors!   It will only do what the Matrix model says, so if the model has the wrong functionality then so will the C code.

 

You never need to change the generated C code, it would be a bit like patching the output from a C compiler - you would not want to do that when you could simply change the C program and recompile.

 

Dark Matter Systems are responsible for changing the Model Compiler and the C code it generates.  If you think you need a modified or bespoke Model Compiler which generates different C code or even another language please contact us to discuss your requirements.

 

 

Do different C Model Compilers create different C coding?

 

Different Model Compilers that generate C code do create different C coding structures.  For example, one Model Compiler may generate C code in order for the applications it generates to use text files to store data, while another may generate code to access a SQL database.

 

 

I am trying to understand how this relates to UML models. 

 

We have grown to dislike the UML notation so we use our own. Take a look at the diagram for a Banking Application model here.  It’s not exactly a UML Class Diagram but it’s very similar.

 

The diagram notation we use is described here and more specifically here.

 

The Matrix language describes diagrams in text form so if you look at the code for the Banking Application here, you can see that lines 40 to 46, 122 to 127 and 328 to 331 encode the Class Diagram.

Copyright © 2017 Dark Matter Systems Ltd. All Rights Reserved.