Home   :   Matrix Language   :   Matrix Language Statements

Matrix Language Statements

Statement Categories

Statements can be categorised into different kinds according to the type of functionality they offer:

Primitive Statements:

System Statements

Action Statements

Object Statements

Pattern Statements

Auxiliary Statements

Utility Statements

Primitive Statements

As the name implies these statements provide orthogonal functionality of a basic kind.  No statement in this group can be replaced by any other Matrix statement or statements in combination.

Together they describe the essential functionality of the analysis model to the Model Compiler.

Primitive statements can be further subdivided into:

System Statements

Action Statements

Object Statements

System Statements

These statements define the Matrix model framework and structure without reference to the model functionality.  In terms of structure they extend from the System statement, through the Domain, Entity and State statements, down to the StateAction statement.

Information from these statements populate the System, Document, Type and OOA meta model domains in the Analysis of Analysis realm.

Action Statements

All states that belong to an active entity will perform a number of actions.  Each action is described by an action statement.  A single action or a group of actions can be regarded as a process and named appropriately.

When taken as a whole the states and their actions describe the actual processing to be performed by the model.

In model terms states are processed without interruption and are coordinated via generated events using the generate event action statements.

Information from these statements populate the Action and Item meta model domains in the Analysis of Analysis realm.

The only effect action statements can ultimately have is to create & delete objects, update attributes and generate events that may cause change in the model (or in something Real World).

Object Statements

These statements provide a method of supplying objects and events which are present in the Real World at "initialisation".  They capture a static and dynamic picture of the system's configuration at start up.

Information from these statements populate the Real World meta model domain in the Analysis of Analysis realm.

Statement Syntax

The syntax for Matrix statements is extremely simple.  There are just three forms:

Name

Name:Major

Name:Major:Minor

A statement may be formed from just the statement name, a statement name plus a major model element name or a statement name plus a major model element name and a minor model element name.  Names are separated by a colon.

Only one statement per line is allowed and it must be placed at the correct indentation level.

Regions and Subregions

A statement's region includes the statement itself and all the subsequent indented statements below.

A statement's subregion excludes the statement itself but includes all the statements indented below it.

There are two kinds of subregion:

Statement Subregion - Only contains other statements at the same indentation level.

Data Subregion - Only contains data and directives at the indentation level.

Statement Subregions

A statement can be regarded as defining the start of a block.  The end of a block is given by the end of the statement's subregion.  In practice, this means the subregion of the last indented statement.

The following example indicates the statement region blocks.

\System:Hello_World

\Type

\BaseType

\String

Text : 12

/String

/BaseType

/Type

\Matrix:Model:Application

\Silo:M1:Software_Application

\Realm:Analysis_Of_Application

\Domain:Friend

\Entity:Greeting

\State

\Dataset:Hail

Text : Message

/Dataset

\DynamicDataState:Display:Hail

\StateAction

\Template

<<|>><<#Message>>

<<:>>

/Template

/StateAction

\Transition

\EventState

Wave -> Display

/EventState

/Transition

/DynamicDataState

/State

/Entity

/Domain

/Realm

/Silo

/Matrix

/System

Data Subregion Formats

All data subregions conform to one of the following formats:

Source

Source : Target

Source <Symbol> Target

Source : Relation : Target

Source : Minimum .. Maximum

Source : Delta : Minimum .. Maximum

Source [ : Data... ]

Source : Target [ : Data... ]

Line

Where <Symbol> represents various symbols such as "==", "->", "-|>", or ":=".

There must be at least one space between a colon, symbol or ".." and a model element name.

Matrix uses "<<" for the less than symbol (normally "<") and ">>" for the greater than symbol (normally ">").

The Context

Each action statement exists in an associated context.  An initial context is always provided by a state on entry that corresponds to an entity or more specifically the object to which it belongs.

A context is also formed from one or more entities that have been "visited" by context changing statements.

Only one object per context entity is ever visible in a process (unless the "^" modifier is used).  The appearance of an entity name does not refer to the object as such but to the entity's context.  This is a subtle distinction since the attribute values of the context are accessed using the familiar Entity.Attribute notation.

There are several ways of referring to a general or particular context:

Initial Context - The single non-iterating entity context that always exists on entry to a state action.

Current Context - The entire available context.  Includes all entities that have been navigated up to a certain point in the state action.  Amalgamates the Surface and Hidden Contexts.

Surface Context - The context reachable without the use of the "^" modifier or with just "^0".  The context formed from the set of last navigated Entity Contexts for each individual entity.

Hidden Context - The context only reachable with the use of the "^" modifier or without "^0".  The context formed from the set of entity contexts obscured by subsequent navigations.

Entity Context - The Initial Context or the context set by the last context generating statement.  An Entity Context can be iterating or non-iterating.

There are relatively few context changing statements:

Traverse

CreateActive

CreatePassive

EntitySelection

The Entity Context is scoped to a context changing statement.

The Traverse statement allows several contexts to be made available or navigated at one time.

An entity in the Hidden Context may be accessed in action statements using the "^" entity modifier.  For example:

| If passenger's desired floor is higher or

| the same as the car's current floor then

| create an up stop.

WhenCase

ConditionAnd

TestAnd

Floor.Number <= Floor^1.Number

WhenCaseSelection

...

Here the modifier is used to access an object's attribute that belongs to the previous Entity Context of Floor which has become hidden by a subsequent (and last) navigation.

This example show how entity objects are compared using the ContextAnd statement:

ContextAnd

Robot^0 == Robot^1

Shelf^2 != Shelf^4

Order^0 == Order^5

Of course, only objects of the same entity existing in different entity contexts may be compared.

Signifiers

Signifiers are a way of referring to an entity or object depending on the category of the statement they are used in.  For example, in an Entity statement, the signifier refers to an entity, but in an action statement it refers to a specific object that is currently in context.

Facts

A fact represents some true statement about the Real World.  As a model executes, facts are created, changed and destroyed to reflect what is happening in the Real World at that time.

In the model they manipulated by simply updating entity atttributes (object data items).  In Object and ObjectEvent statements they appear as constants.