The Petrol Station model documents an experiment to convert an existing MASL model to the Matrix language .
MASL is a relatively new textual modelling language, having made its first public appearance in 2016 . The language employs vocabulary from Shlaer-Mellor rather than the more established Executable UML terminology. For example, it uses the term "objects" to describe modern classes (entities) and the term "instances" to describe objects.
The language clearly builds on older action languages originating from the 1980's such as ASL and OAL. MASL is similar to Matrix in that it is not limited to the state action level but is capable of describing an entire model including projects, domains, objects and state transitions. The language has a C like syntax but also has a strong Ada influence.
Unlike Matrix, MASL allows a great deal of flexibility where the various model components can be defined. This would imply that modellers will be required to adhere to a style guide to ensure consistency of format between models.
MASL retains the programming approach to action description found in ASL and OAL. Unlike Matrix where navigation is a central feature and always operates on "live" objects, MASL "pulls out" collections of objects (or instances) which are later cycled through and processed.
Also, MASL navigation is used to jump from one entity to another in order to obtain, say an object's attribute's value. Whereas in Matrix, the main context changes to that entity.
Note: All Petrol Station MASL model code is UK Crown Copyright.
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
The model describes the operation of a normal petrol station (filling station) that can be found on most main roads and contains the expected entities.
Pumps make deliveries to customers which should not be confused with petrol tankers making deliveries to a station's storage tanks. At the end of a delivery, a transaction is created that enables the customer to pay for the petrol.
A model walkthrough can be found in the PSC.mod file in the original MASL repository .
The Domain Bridge Diagram (DBD) below shows the top level application Petrol Station Control domain and sets the system boundary for the model.
In an actual project the application domain would be shown with all the other domains in the application as shown in the diagram below. Bridges to other domains are effectively "channels" that a domain sends events to and receives event from.
It is often useful to name the major entities comprising a domain and to have them visible on the DBD. These are the usually the most central active entities and are displayed on each domain as shown below.
The Entity Relationship Diagram (ERD) below shows the relationships between the various entities in the Petrol Station Control domain.
The entities have been taken directly from the MASL model except for the Transaction Policy entity which has been added to hold the next transaction number to be used. As required by Matrix, the ERD only shows relationships that are actually necessary for the model to operate.
The notation used by the diagrams below is based on Shlaer-Mellor Method notation (similar to UML) . To see the full size ERD, click on the diagram. Click again to see an annotated version.
The diagram below shows all the STDs from the Petrol Station Control domain without showing how they interact. Click on the picture to get an expanded view of the diagram.
Domain State Transition Diagrams (Separate)
Click on the picture below to get an expanded view of the diagram showing the source of actual events and their destination among the collaborating entity STDs. An event based notation is used .
Domain State Transition Diagrams (Annotated)
The Original MASL Model
During conversion to Matrix several observations were noted:
- Some state names are in sentence case others are in capped case.
- State at the end of a state name is unnecessary.
- Creating junk instances in for loops is generally not very useful because of how the method works (true for Matrix) with the exception for performance load testing.
- Tank and Pump numbers are set differently.
- Tank level flag and tank level may be incompatible when defined.
- One .tr has the keyword Begin repeated. This is a syntax error.
- Inconsistent spelling of Attendant.
- The Attendant Transaction_Pending service is defined but not used.
- In the "supplied" scenario the Transaction:Customer_absconds and Transaction:Payment_received event generation have been swapped to fix wrong state error.
- The event Delete_Delivery is redundant. Although Matrix needs it!
- In the Creating_Delivery state, the event Delivery_Complete goes to the Delivery_Cancelled state and not to the Delivery_Complete state.
- The magic number petrol unit price (0.1) has been placed with the Fuel_Grade entity in the Matrix model.
- In simple assignments such as x:=x+1 a redundant intermediate variable is made used of (a:=x+1, x:=a).
- In the Fuel_Delivery_Complete state, the Fuel_Level_Ok event has "=> Ignore,Pumping". This is a syntax error. Assumed this to be "ignore" because to move from Fuel_Delivery_Complete to Pumping makes no sense. Unfortunately, this makes the Fuel_Level_Ok event redundant.
- Pump:Pumping_fuel_from:Tank is a MANY and miss named.
- In state Checking_Levels_After_Tanker_Delivery, the begin and end around this.Check_Level(below_threshold); seem to be redundant.
- Magic number Full_Percent: 100. This is unnecessary.
- Tank_empty_flag may be redundant.
- The attribute: Transaction_Process_Time does appear to be used anywhere.
Fuel Grade Entity
- A fuel grade should be able to be stored in more than one tank so Fuel_Grade to Tank is UNCONDITIONAL MANY not UNCONDITIONAL ONE.
- No relationships to Tank junk instances are established at initialisation.