Today, Mike Finn presents a new abstract modeling language called Matrix based on the Shlaer-Mellor Method.
Matrix is a textual modeling language that’s designed to be translated to many existing programming languages such as C, C++, Java and Ada.
The Matrix language provides an extremely high level of abstraction compared to currently available executable modeling languages, that’s because Matrix semantics are especially designed to deal with true modeling concepts. And by being firmly based on the Analysis Design Matrix framework, relational theory and state machines, Matrix provides a solid foundation for future proof software development.
Not only is Matrix able generate today’s and tomorrow’s programming languages (given a suitable Model Compiler), models are also architecture independent. This allows exactly the same model to be targeted to vastly different kinds of software architecture.
Matrix has also been specifically constructed to handle large and complex systems with built-in language components to specify sequential and parallel processing.
With a textual language such as Matrix, model development is often faster due to easier refactoring, merging, differencing and configuration management. Also, the ability to search a model just makes it far more accessible.
Matrix has many new and innovative features. A full list is available here.
The best way of exploring a new language is to see a small but complete example and work through it step by step. We present a model based on the simple and well understood Hello World! program below:
When you’ve recovered from the shock of Matrix not looking like C or Java, remember that this is a modeling language not a programming language. The concepts being manipulated here are different to the concepts controlled in programming languages.
This model, like most Matrix models has two parts. The upper part (M1 silo starting from line 7) defines the analysis model itself in terms of entities, relationships, states, etc. and directly corresponds to the set of
diagrams that form a graphical model. The lower part (M0 silo starting from line 22) sets the initial configuration of the entities in the M1 model. In other words, it defines objects for the entities at initialisation time.
Notice that the Matrix language uses indentation to structure statements. This is important to how regions are defined (the scope over which statements act over other statements and data).
The heart of our Matrix Hello World! model lies in the domain called Friend (line 9) and the single entity named Greeting (line 10). Greeting declares one state (line 14), one event and a single transition from the state (line
21).
When the model executes, a Greeting object is created in the Display state (line 28) and the event named Wave is sent to the object with a Message of “Hello World!” (line 31) which causes a transition out of and back into the Display state (line 21). On entry to the state the single action in the process sequence is executed (line 15). The Message received on the event is then displayed by the Template statement (line 16). A full line by line explanation is given here.
The Matrix Model Compiler enforces a standardised Matrix Coding Style that has the advantage of ensuring all Matrix models everywhere appear with the same organisation and lay-out.
We’re planning to release a free Model Compiler to generate C/C++ source code early Q3 2012. In the meantime, more example models and further Matrix language details will be made available over the coming months.
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Yawn, another language using indentation instead of blocks:
“When you’ve recovered from the shock of Matrix not looking like C, C++ or Java, remember that this is a modeling language not a programming language. The concepts being manipulated here are different to the concepts controlled in programming languages.”
Someone introduce them to HUTN (Oh no! Braces AND semicolons!! What will we do?).
@Jay
Whatever happened to HUTN? Was that the language that could only handle class diagrams and overcomplicated that simple task?
Matrix had braces and semicolons in the early days but I took them out. 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 like to do and this is why style guides where invented. When I built my style guide rules into the Model Compiler the need for braces and semicolons simply disappeared.
@Jay
Don’t think comparing Matrix to HUTN is fair. HUTN belongs with JSON, basically a very slim generic textual notation for maps/graphs, where everything looks the same no matter the purpose (even “foo : Integer” becomes a map with two slots, named “name” and “type”). Matrix does have some generic syntax, but also has purposed syntax, and that means a world of difference in terms of usability (more on this here).
Re: blocks vs. indentation – these are the two options, right? Would block delimiters not make you yawn then?
Yet another programming language in the guise of a modeling one. The pivotal question, namely what’s the intrinsic difference between analysis and design models, is simply ignored.
@Remy
I’m claiming Matrix is a modeling language because the semantics are different to that of a programming language. I’m also asserting that 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.
I don’t think there is an difference between analysis and design models except the subject matter each deals with and where it belongs in the Analysis Design Matrix.
“The pivotal question, namely what’s the intrinsic difference between analysis and design models, is simply ignored.”
On the contrary. This is the first time I’ve seen Matrix – but it’s founded on the principles of the Shlaer-Mellor method. And Shlaer-Mellor makes a very clear distinction between ‘Anaysis’ and ‘Design’. Specifically: ‘Analysis’ is modelling the problem domain(s), ‘Design’ is composing and translating them to a target runtime infrastructure (‘Architecture’ in S-M terms). Now you may – or may not – agree with those definitions of the terms ‘Analysis’ and ‘Design’. But it’s incorrect to say it ignores the difference.
Personally I don’t use the terms ‘Analysis’ & ‘Design’ any more precisely because they cause so much unfruitful debate. I prefer ‘Description’ and ‘Translation’ (explanation on my blog if you’re interested: http://www.roperia.com/article/362/analysis-and-design-vs-description-and-translation).
@ Scott
It’s always nice to speak to someone that has used and understands Shlaer-Mellor.
I certainly think the use of the terms Description and Translation (or perhaps some other completely new terms) has merit because there is a lot of confusion especially over the word Design.
Analysis, Design and Translation are all words that describe a process.
The Analysis process produces a M1 analysis model. However, in the Railway Management System I think it’s common to say that a solution to the “One train on one track section” requirement has been “designed”, but in the context of the Analysis.
The Design process is the tricky one (remember that “Design is a subject matter for Analysis”). The Design process produces an analysis model that belongs to the Software Architecture which forms part of the Model Compiler at M2.
The Translation process produces code and is performed by the Model Compiler.
The Analysis Design Matrix moves Shlaer-Mellor’s Software Architecture domain to the M2 meta-level where it belongs. You must have wondered (like I did) why the Software Architecture domain on the Domain Chart (M1) was a clearly different kind of domain.
@Mike: thanks for reply. Old SMers never die, they just re-model 🙂
“a solution to the “One train on one track section” requirement has been “designed”, but in the context of the Analysis.”
Nicely put. And a good example of why I dislike the terms ‘analysis’ and ‘design’. ‘Description’ – or perhaps ‘Modelling’ – seem much more intuitive and accurate depictions of what’s actually happening.
“You must have wondered (like I did) why the Software Architecture domain on the Domain Chart (M1) was a clearly different kind of domain.”
Agreed. The Architecture is a peer of the Metamodel (‘OOA of OOA’), as becomes abundantly clear when writing a model compiler: the MC rules essentially describe how to create instances in the architecture from instances in the metamodel.
Conscious I’m probably straying off topic – so will resist expounding on how visionary Steve and Sally were…
Good luck with Matrix btw.
Matrix Model Compiler Released
The free Matrix Learning Edition Model Compiler (Beta) is available for download.
http://analysisdesignmatrix.com/
Models written in the Matrix modeling language can now be automatically translated to C source code by the Model Compiler.
Matrix is a textual modeling language that’s designed to be automatically translated by a Model Compiler to existing programming languages such as C, C++, Java and Ada within the context of the selected software architecture.
The generated code will always compile and build correctly. Code produced by the Learning Edition has been optimised with extra checking to help developers detect some errors present in Matrix models which can only be found at run-time.
Dark Matter Systems is pleased to announce Matrix V1.0.1. This release features a Simulator which provides developers with a model specific interactive debugging and testing environment.
Also in this release, a new Passenger Elevator (Lift) model, additional statements for allowing access to previously visited contexts of the same entity plus various bug fixes.
http://analysisdesignmatrix.com/