Skip to content

Latest commit

 

History

History
139 lines (103 loc) · 4.3 KB

meta-modelv3.org

File metadata and controls

139 lines (103 loc) · 4.3 KB
Raw

Kendrick Meta-model v3

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

High level Tests (specification of the MM)

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

Kendrick Meta-model description

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.

MM-related Issues

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)

Model

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).

Attribute

An attribute has a name and a domain.

Functional rates

Apparently there is no representation of functional rates in the K meta-model. Do we need to introduce it ?

Kendrick Meta-Model Diagram

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