This document is in .org a markdown-like language that eases the introduction of a UML diagram using PlantUML
Implemenation of this MM and issues with the previous version are discussed in this document: https://github.com/KendrickOrg/kendrick/edit/master/documentation/meta-model/MM-implementation.org
The core of the MM is the concept of SAN: a composite automaton. However ODEs are also central in Kendrick and must be reified too.
To specify composition we rely on a very simple examples https://github.com/KendrickOrg/kendrick/tree/master/documentation/formal-SoC-models
The high level test are there https://github.com/KendrickOrg/kendrick/blob/master/src/Kendrick/TestMM.class.st
The old tests of the Model class are there https://github.com/KendrickOrg/kendrick/blob/master/src/Kendrick/KEModelTest.class.st
Other examples https://github.com/KendrickOrg/kendrick/blob/master/src/Kendrick/KEDeterministicExamples.class.st
All the Kendrick classes are there https://github.com/KendrickOrg/kendrick/tree/master/src/Kendrick
The core of the MM is the concept of SAN: a composite automaton.
The UMM (User MM) deals with high-level functionality and what services are served to users. It must match the high-level DSL.
The IMM (Implementation MM) specifies the low level implementation and interacts with low-level service-providers such as ODE solvers (RK4…) and stochastic simulation algorithms (Gillespie, Tau leap …).
The abstract syntax of Kendrick is based on the mathematical definitions of Kendrick and relies on an object-oriented meta-model. We use the UML graphical modelling language to describe the Kendrick meta-model.
Support for composition must be clarified. For instance a KModel section in the DSL does not describe a SAN but an atomic automaton. Can compositions be composed?
The equivalence between ODEs and automata must be clarified. When is it possible? What are the assumptions?
What is the name of a compartment in a composite automaton (different possible granularity levels)
Equivalence relations are restricted to equalities on individuals’ attributes. This guarantees that each equivalence class (the individuals with the same values for a given set of attributes) has a known name: the ordered set of attribute names used in the equality.
An attribute is a function on the population to any domain with equality. When models are combined, attributes must remain unique in the whole population (name clashes must be avoided).
An attribute has a name and a domain.
Apparently there is no representation of functional rates in the K meta-model. Do we need to introduce it ?
See //www.plantuml.com/
@startuml
namespace epi {
Model o-- "1" SAN
Model -- "1" ODESystem
Model o-- "0..*" Parameter
Model o-- "0..*" Model : submodels
Parameter <|-- Rate
Model o-- "0..*" Attribute
Model o-- "1..*" Compartment
Model o-- "1" Status
Compartment "1" o-- "1" CompName
CompName o-- "1..1" SimpleEquivalenceRelation
Attribute <|-- Status
}
namespace odes {
ODESystem o-- "1..*" ODE
ODESystem o-- "1..*" Variable
ODE o-- "1" Variable : leftHandSide
ODE o-- "1" Expression: rightHandSide
}
namespace markov {
MarkovProcess <|-- SAN
Automaton o-- "0..*" Transition
Automaton o-- "1..*" State
Transition o-- "1..1" Rate
Transition o-- "*..1" State : from
Transition o-- "*..1" State : to
SAN o-- "1..*" Automaton : subAutomata
}
namespace expressions {
Expression <|-- value
Expression <|-- Variable
Variable <|-- Parameter
Expression <|-- OperatorExp
Variable<|-- LHS
OperatorExp o-- "1" Operator
OperatorExp o-- "1..*" Expression : operands
Operator <|-- Equals
Operator <|-- Plus
Operator <|-- Sum
Operator <|-- AssignmentOp
Assignement o-- "1" AssignmentOp
Assignement o-- "1" LHS
Assignement o-- "1" Expression : rhs
}
namespace algebra {
SimpleEquivalenceRelation o-- "1..*" AttValuation
AttValuation o-- "1" AttName
AttValuation o-- "1" Value
Attribute o-- AttDomain
Attribute "1" o-- "1" AttName
Domain "1" o-- "1..*" Value
OperatorExp <|-- AttValuation
Variable <|-- AttName
}
@enduml