Abstraction and reusability in Abstraction and reusability in the biological modelling processthe biological modelling process

Jonathan Blakes

RAD 20098th June

Escherichia coli © David S. Goodsell 1999

OutlineOutlineIntroduction to biological modelsReusing model componentsInheritance for modelsDesign patternsOutcomes

Executable biologyExecutable biologyMany different computational formalisms

for model specification and analysis:◦P systems, Petri nets, π-calculus, κ, ...

Executed on abstract machine:◦ implementations of Gillespie algorithm

General features of executable models:◦pools of molecules (in compartments)◦quantities modified by discrete reactions

TerminologyTerminologyP system model◦ P systems

Membrane structure Volume Lattice position Rules + Modules Multiset of objects

◦ Lattice

Model◦ Cells (compartment)

Compartments... Volume Position in space Reactions Molecules

◦ Lattice

So modelling is programming?So modelling is programming? If executable biology means models built in

computational formalisms that are interpretable as algorithms, then what lessons can we learn from software engineering that we enable us model better and therefore build better models?

Answer:◦ Reusable components lower the barriers to

development. Robustness follows as reused code implemented only in one place.

◦ Abstraction is key to delivering reusable components.

Reusability in biological modelsReusability in biological modelsOne example already, modules of P system rules: Set of reactions where some molecular identities,

compartment labels or rate constants are undefined.◦ UnregulatedExpression({X},{b},{c1 ,c2}) = {

[geneX]b → [geneX + proteinX]b,

[ proteinX]b → [Ø]b }

Modules of modules:◦ NegativeAutoRegulation = ({X},{b},{c1 ,c2 ,c3}) ={

UnregulatedExpression({X},{b},{c1 ,c2}),

[gene X]b+ [proteinX]b → [geneX.proteinX]b, ... }

Equivalent of Traits* in OOP languages◦ No state just expected inputs and outputs

c1

c2

c3

* Shärli et al. (2002) Traits: Composable Units of Behaviour.

Reusing latticesReusing latticesLattice by itself:◦reuse size, shape and topology of lattice

Lattice with identities◦by switching between lattices we can explore

how neighbourhood affects system

→

Reusing modelsReusing modelsCompose larger models from smaller onesScenarios:◦ intracellular endosymbionts: insert compartment

(Buchneria sp.) into top-level compartment (aphid), observe changes in aphid metabolism.

◦ Also parasites, infections, tumors, ...◦Mixing populations of bacteria – cross talk of quorum

sensing moleculesNeed to resolve conflicts between models?

Reusing simulation resultsReusing simulation resultsCan already reuse simulation protocols as simulation

parameters are factored out of modelEach simulation produces large HDF5 file containing

multiple runsSimulator results software produces plots quantities

from HDF5 [demo]Can’t combine plots from different models in GUIMore plots: histogram of quantities of molecule A at

time ti, surface histogram (A for all timepoints)Extract plot data (and formatting) belonging to model-

simulation pairs so that appropriate comparisons can easily be made

Extending the OOP metaphorExtending the OOP metaphorModels are classes or objects!◦Models must have structure (class):

compartments in space (nested / on lattice) reactions (in compartments)

◦Models can have state (object): molecules in compartments current time

◦Models with a partially undefined structure are like abstract classes.

Abstract modelsAbstract modelsJust like abstract classes in OOP, some features

remain undefined:◦ compartment identities in model structure◦ reactant/compartment identities and rate constants

in reactions◦ compartment positions in space◦ quantities of molecules in compartments

Abstract models can’t be simulated as they are incomplete

Abstract models must be inherited by other models and missing features defined.

Inheriting from a modelInheriting from a modelDeclare parent-child relationship:◦“E.coli inherits AbstractBacteria”

Concrete models can be inherited too

Esherichia coli P. aeruginosa

AbstractBact.

PAO1 Nott. PAO1 Santa Fe

Overriding inherited reactionsOverriding inherited reactions In OOP languages methods in subclasses can override and replace

methods in a superclass by declaring a method with the same header: <return type> <name>(<parameters>)

In models, reaction overriding = method overriding:model.reaction: reactants → products <constant>

e.g.Parent.Reaction3: A + B → C c3 = 0.0125

Child.Reaction3: A + B → C c3 = 0.06 4x faster Reaction can be removed in the child model by declaring a reaction

with the same header and a rate constant of zero:Child.Reaction3: A + B → C c3 = 0 propensity = A x B x 0

Reaction 3 can never occur now because its propensity will always be zero.Plus, the absence is explicit in the model.

c3

c3

c

c3

Reusing model stateReusing model stateCreate a set of states that represent hypotheses

about the potential states of the system◦what happens when A is high and B is low? (v.v.)

Can initialise various concrete submodels of abstract parent with same state to test the hypotheses they embody

Can extract ‘reached’ states from large simulations, run repeats starting from there to get distributions of fate given past, or vary model at that point (unrealistic?)

““Known unknowns”Known unknowns”With abstract models and inheritance:Unknown rates do not have to be guessedUnknowns are delegated to inheriting models◦which therefore embody hypotheses about the

values of those unknownsmodels can be built with incomplete knowledge◦ and future modellers clearly know what was

unknown

Software design patternsSoftware design patternsSoftware design patterns* in are general reusable solutions to commonly occurring design problems. In OOP design patterns:are relationships and interactions between objectsdefined by abstract classes and interfaces (purely abstract)have simple distinctive names: Singleton, Prototype, Compositeindependent of applicationallow communication between programmers in terms of patterns

Are there biological design patterns?

* Gamma, Helm, Johnson and Vlissides (1995) Design Patterns.

Addison-Wesley Professional

Biological design patternsBiological design patterns

Margaret Boden’s 7 features of life:1. self-organization

2. autonomy

3. growth

4. adaptation

5. reproduction

6. evolution

7. metabolism

Add to that:8. autopoiesis

9. sexual reproduction

Architectural patterns, not molecular

Biological design patternsBiological design patterns Regulatory motifs:

◦ NAR, IFFL, ...*◦ molecular, varying levels of detail◦ too small to be patterns?

Potential patterns:◦ oscillators◦ delays◦ inverters

Partial models enable us to encode context in modules which would otherwise need to be associated with compartments by the modeller.

* Alon, U. (2007) An Introduction to Systems Biology: Design Principles of Biological Systems. Chapman & Hall/CRC

OutcomesOutcomesManage complexityShare common structure between modelsEncourages incremental model building:◦ one set of features added◦model is inherited◦ next set of features added

Potential applicability in evolutionary optimisation and ALife:◦mutated model inherits parent model but only mutated

features are recorded – trace evolution◦ crossover more difficult – multiple inheritance makes

lineage harder to trace

AcknowledgementsAcknowledgementsThanks to:◦ Dr. Natalio Krasnogor◦ Dr. Francisco J. Romero Campero◦ Dr. Jamie Twycross◦ Dr. Hongqing Cao◦ James Smaldon

Funded by:EPSRC grant EP/E017215/1BBSRC grant BB/F01855X/1

InfobiotiInfobioticscs

An An aspirationalaspirational quote quote“The crucial lesson for biology...is that as our

capacity to make scientific observations and measurements grows, the need to deal with the complexity of the studied systems becomes more, not less of an issue, requiring concomitant development of the means by which to synthesise knowledge from the data. Real knowledge is more than just data – it [comes] from the intellectual frameworks that we create to organise the data and to reason with them.” – Gordon Webster (2009) Biologists flirt with models. Drug Discovery Today.