1. Applications of the Matrix Model of Computation
Sergio Pissanetzky
I present the applications of the Matrix Model of Computation.

2. The MMC consists of two sparse matrices: M = (C, Q)
C = Matrix of Services
Q = Matrix of Sequences
The model has two forms:
● imperative form
● canonical form.
Matrix Q is the imperative part of the model.
Recall the matrix model consists of two sparse matrices, the matrix C of services and the matrix Q of sequences.
The model has an imperative form, and a canonical form. Matrix Q is the imperative part.
This talk is restricted to the imperative form, and to matrix Q.

3. The MMC is universal ● Software Engineering
Object-oriented analysis and design.
Object-oriented refactoring.
Software development.
Physics
SCA algorithm, ontologies.
From thought experiments to theories.
Business
Business applications of the MMC.
UML
MMC applications to UML models.
Inheritance, polymorphism.
Artificial Intelligence
Neural networks, parallelism, training, dynamics.
The matrix model is universal and applies to all systems.
In a previous publication on Software Engineering, I discussed OO analysis and design, and OO refactoring.
I proposed a software development environment based on the MMC.
In Physics, in my previous talk, I demonstrated the use of SCA to create objects and inheritance hierarchies.
The example describes the use of the matrix model to create theories of Physics.
I will now discuss conversion between business rules and UML class models, and the matrix model.
Next week, at another conference, I will present an important application to Artificial Intelligence and Neural Networks.

4. A Business Problem M A B S C a b
Here is a business problem.
The problem statement is: calculate the cost to outfit an aircraft model A, B, or C to carry mail (M) or spray crops (S).
To model this problem I need a variable b to select the model, and another variable a to select mail or spray.
I need an Init service to initialize a and b, services AM... to calculate the list of equipment for each combination,
and services MCost and SCost to calculate the cost for the mail equipment, or the spray equipment.
That is all we need regarding the matrix of services C. But this talk is about the matrix of sequences.
Services: Init, AM, BM, CM, AS, BS, CS,
MCost, SCost

5. Matrix of Sequences Q = R actor P a b F 1 init M A AM B BM C CM S ASBS CS
MCost
SCost
exit R
Q =
Here is the matrix of sequences. The matrix is a set of relations. Each row is a tuple in one of the relations, called a sequence.
Each row describes a link between two services, service P (previous) and service F (following).
Some sequences are unconditional, others are conditioned by control variables, in this case a and b.
An actor invokes init, which selects one of the helper codes, depending on a and b.
Then, either MCost or SCost are called unconditionally. The cost is calculated, and the program exists.
This is the business model. What can I do with it?
The model is a program, it can be compiled.
The model is a relational database. Relational operations apply  refactorings, other transformations.
Keep listening. Here are some examples.

6. Relations are code P a b F init M A AM B BM C CM S AS BS CS
Relation R =
if(a==M && b==A) AM;
if(a==M && b==B) BM;
if(a==M && b==C) CM;
if(a==S && b==A) AS;
if(a==S && b==B) BS;
if(a==S && b==C) CS;
Program in C
Here is the conversion of relation R into code. Relation R is shown separated from the matrix.
Explain the code. The control variables are implemented as conditionals.
It is easy to convert between relations and code.
However, working with relations is much easier than working with code.
Code should serve only for man-machine communication. All work should be done with relations.

7. Relations are object-orientedP a b F
init M A AM B BM C CM S AS BS CS
Relation R =
MMC
OO Model
relation
inheritance hierarchy
control variable
base class
each allowed value
derived class
sub-relation
virtual method
There is a direct correspondence between relations in matrix Q and the natural ontology of the system.
A relation corresponds to an inheritance hierarchy. Each control variable corresponds to a base class.
Each value of the control variable corresponds to a derived class. Each sub-relation corresponds to a virtual method.
In the example, relation R has two control variables, therefore relation R represents multiple inheritance.

8. normalization, projection
Relations support inheritance transformations
Transformation
Relational operation
multiple to single
normalization, projection
single to multiple
join P a b F
init M 1 S 2 A AM B BM C CM AS BS CS P a k b F
init M 1 A AM B BM C CM S 2 AS BS CS R1
R =
Normalization converts multiple-inherited polymorphism to single-inherited polymorphism.
Joins convert in the opposite direction.
In the example, there are two control variables, a and b, and there are two ways to normalize.
Normalize first with respect to a. The a decision is made first, then the b decision.
Add the new domain k with foreign keys into a, then project onto {P, a, k} and {k, b, F}.
The result are relations R1, R2, with a single control variable each  single inheritance. R2

9. Case b/a ● Consider control variable b.
● Add foreign keys for variable b.
● Project on (P, b, h) and (h, a, F). P a b F
init A 3 B 4 C 5 M AM S AS BM BS CM CS P a h b F
init M 3 A AM 4 B BM 5 C CM S AS BS CS R3
R =
Here is the same operation with respect to variable b.
Add the domain h with keys into b, then project onto {P, a, h} and {h, b, F}.
The result are relations R3, R4, each with a single control variable. R4

10. Relations support UML modelsb F
init M 1 S 2 A AM B BM C CM AS BS CS
MCost
SCost
exit
Document
Cost(a)
MList
SList
Mail
MCost(Document d) R1
Spray
SCost(Document d) R2 R2
AModel
MList{AM}
SList{AS}
BModel
MList{BM}
SList{BS}
CModel
MList{CM}
SList{CS}
Caller initializes a.
Caller constructs A/B/CModel  initialize b.
Caller calls Cost, passing a
Cost selects MList /SList  a decision.
MList, SList call their override  b decision,
calculate the list of equipment,
construct a Mail or Spray object,
and call their M/SCost method to calculate cost.
Here is the MMC/UML interface.
I have inserted R1 and R2 in place of R into matrix Q.
Then, I have created the UML model for the case where the decisions are handled in the order a/b,
the a decision is implemented as a conditional, and the b decision as polymorphism.
Thus, R2 is converted to an inheritance hierarchy. One relation, one inheritance hierarchy.
One control variable (b), one base class. Three values, three derived classes.
Two sub-relations, two virtual methods in the base class, overriden in the derived classes.

11. Relations support Patternsb F
init A 3 B 4 C 5 M AM S AS BM BS CM CS
MCost
SCost
exit
Document
accept(Visitor v) R3 R3
AModel
accept(Visitor v)
{v.visitA(this)}
CModel
accept(Visitor v)
{v.visitC(this)}
BModel
accept(Visitor v)
{v.visitB(this)} R4 R4
Visitor
visitA(AModel d)
visitB(BModel d)
visitC(CModel d)
Case b/a is handled in the same way, an here is the resulting matrix Q.
In this example, I have converted both R3 and R4 to class hierarchies, following the same rules.
In traditional refactoring, this model requires the use of patterns, and it takes 16 Fowler refactorings.
Here, just one relational operation, automatic, no patterns. Same result.
Caller constructs Mail/Spray  initialize a. Caller constructs A/B/CModel initialize b
Caller calls accept, passing Visitor  b decision. accept calls the corresponding virtual visitA/B/C
which finally calls the derived Mail/Spray the a decision
Mail
visitA(AModel d){AM}
visitB(BModel d){BM}
visitC(CModel d){CM}
Spray
visitA(AModel d){AS}
visitB(BModel d){BS}
visitC(CModel d){CS}

12. Refactoring in the MMC Action Traditional method MMC
decide what to refactor
manual
automatic
perform the refactoring
manual (tools available for some languages)
procedure
16 Fowler refactorings
1 normalization
implementation
requires use of pattern
natural
Compare refactoring by the traditional method, with refactoring in the matrix model.
Traditionally, developers decide what to refactor, perform refactorings manually, although
tools are now available for some languages, use a large number of Fowler refactorings,
and frequently use patterns.
In the matrix model, all steps are automatic and natural, and no patterns are required.

13. Conclusions ● The MMC is Universal Interfaces easily with applications
Supports Object-Orientation
Unifying factor for systems
Conclusions.
The matrix model is universal, interfaces easily with other systems, and supports object-orientation.
The model is a unifying factor for systems.