Abstraction and reusability in the biological modelling process Jonathan Blakes RAD 2009 8 th  June Escherichia coli © Dav...
Outline <ul><li>Introduction to biological models </li></ul><ul><li>Reusing model components </li></ul><ul><li>Inheritance...
Executable biology <ul><li>Many different computational formalisms for model specification and analysis: </li></ul><ul><ul...
Terminology <ul><li>P system model </li></ul><ul><ul><li>P systems </li></ul></ul><ul><ul><ul><li>Membrane structure </li>...
What else can we reuse? <ul><li>Model =  Σ (structure, parameters, state) </li></ul><ul><li>Structure = compartments, labe...
So modelling is programming? <ul><li>If  executable biology  means models built in computational formalisms that are inter...
Reusability in biological models <ul><li>One example already,  modules  of P system rules: </li></ul><ul><li>Set of reacti...
Reusing lattices <ul><li>Lattice by itself: </li></ul><ul><ul><li>reuse size, shape and topology of lattice </li></ul></ul...
Reusing models <ul><li>Compose larger models from smaller ones </li></ul><ul><li>Scenarios: </li></ul><ul><ul><li>intracel...
Reusing simulation results <ul><li>Can already reuse simulation protocols as simulation parameters are factored out of mod...
Extending the OOP metaphor <ul><li>Models are classes  or  objects! </li></ul><ul><ul><li>Models must have structure (clas...
Abstract models <ul><li>Just like abstract classes in OOP, some features remain undefined: </li></ul><ul><ul><li>compartme...
Inheriting from a model <ul><li>Declare parent-child relationship: </li></ul><ul><ul><li>“ E.coli inherits AbstractBacteri...
Overriding inherited reactions <ul><li>In OOP languages methods in subclasses can override and replace methods in a superc...
Reusing model state <ul><li>Create a set of states that represent hypotheses about the potential states of the system </li...
“ Known unknowns” <ul><li>With abstract models and inheritance: </li></ul><ul><li>Unknown rates do not have to be guessed ...
Software design patterns <ul><li>Software design patterns* in are general reusable solutions to commonly occurring design ...
Biological design patterns <ul><li>Margaret Boden’s 7 features of life: </li></ul><ul><li>self-organization </li></ul><ul>...
Biological design patterns <ul><li>Regulatory motifs: </li></ul><ul><ul><li>NAR, IFFL, ...* </li></ul></ul><ul><ul><li>mol...
Outcomes <ul><li>Manage complexity </li></ul><ul><li>Share common structure between models </li></ul><ul><li>Encourages in...
Acknowledgements <ul><li>Thanks to: </li></ul><ul><ul><li>Dr. Natalio Krasnogor </li></ul></ul><ul><ul><li>Dr. Francisco J...
An  aspirational  quote <ul><li>“ The crucial lesson for biology...is that as our capacity to make scientific observations...
Upcoming SlideShare
Loading in …5
×

20090608 Abstraction and reusability in the biological modelling process

487 views

Published on

2009 RAD

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
487
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Compartments in biological models can be thought of as classes in that they define the structure of an executable biological object: set of reactions and set of sub-compartments. [And a model is essentially a universal compartment with some global parameters such as the rate of cell division or the current simulation time. Like you can have a Python module without classes that still runs, you can have a model without compartments, where the reactions cannot send objects in or out of the model, and whose rate constants implicitly contain the volume of the model.] The compartment class is instantiated to a compartment object in our virtual machine (simulator, model checker, optimiser) when we specify the set of molecules contained in each compartment. The structure of the model is thus separate from its state (genotype/phenotype split?) and we can examine the model&apos;s response to any state we choose. Currently each of the models we produce is complete in that it specifies the structure of the model and the initial state.
  • We are using a stochastic simulation algorithm, so each simulation run returns a different possible trajectory - path through time and space - or &apos;evolution&apos; of the objects in the system, namely the sequence of reactions fired, the changing quantities of molecules and size, shape and position of the compartments. For small systems we can run many simulations to obtain the most probable trajectory of the system, or a distribution of outcomes. For models of bacterial colonies (many cells/single top-level compartments) each bacteria represents a different possible trajectory of the model bacteria at a colony-level model. Colony models tend to be very large - 10,000 cells in a 100 by 100 lattice (and we want to go 100 times bigger still) - and due to there running time we can only do a few different runs of the model. Quite often the interesting behaviour takes a while to emerge and it would be nice to be able to pause the execution of the model at a certain point, say when a large number of quorum sensing signals have accumulated and just before the colony becomes quorated, clone the model at that point several times over and set each instance running again to make measurements like the time until all bacteria are quorated, or the time it takes the colony to become unquorated after a certain quenching agent has been applied (model events). For static models where compartments do not move, grow or divide into sibling compartments this is easy, we can just save the set of molecules in each compartment - the models current state - and the simulation time, and instantiate several models with that state. But when the model is dynamic the structure of the model has changed: the position of the compartments has changed for instance; it is by our previous definition a new model. We need to be able to extract that new model from the simulation... ... In object-orientated languages this is called serialization (or pickling in Python) of an object. ... The structure of the model has been changed by its state and that state is the result of an initial state. Does it make sense to create a reusable abstraction of this model? [question to audience]. Is it different to specifying that exact structure a priori?
  • homeostasis (maintenance) / autopoiesis (regeneration) - the components are constantly changing but the system remains the same sex - yeast a and alpha mating types how can we describe these functions, that emerge from the interaction of molecules and their containers, in terms of molecules and containers?
  • 20090608 Abstraction and reusability in the biological modelling process

    1. 1. Abstraction and reusability in the biological modelling process Jonathan Blakes RAD 2009 8 th June Escherichia coli © David S. Goodsell 1999
    2. 2. Outline <ul><li>Introduction to biological models </li></ul><ul><li>Reusing model components </li></ul><ul><li>Inheritance for models </li></ul><ul><li>Design patterns </li></ul><ul><li>Outcomes </li></ul>
    3. 3. Executable biology <ul><li>Many different computational formalisms for model specification and analysis: </li></ul><ul><ul><li>P systems , Petri nets, π -calculus, κ , ... </li></ul></ul><ul><li>Executed on abstract machine: </li></ul><ul><ul><li>implementations of Gillespie algorithm </li></ul></ul><ul><li>General features of executable models: </li></ul><ul><ul><li>pools of molecules (in compartments) </li></ul></ul><ul><ul><li>quantities modified by discrete reactions </li></ul></ul>
    4. 4. Terminology <ul><li>P system model </li></ul><ul><ul><li>P systems </li></ul></ul><ul><ul><ul><li>Membrane structure </li></ul></ul></ul><ul><ul><ul><li>Volume </li></ul></ul></ul><ul><ul><ul><li>Lattice position </li></ul></ul></ul><ul><ul><ul><li>Rules + Modules </li></ul></ul></ul><ul><ul><ul><li>Multiset of objects </li></ul></ul></ul><ul><ul><li>Lattice </li></ul></ul><ul><li>Model </li></ul><ul><ul><li>Cells (compartment) </li></ul></ul><ul><ul><ul><li>Compartments... </li></ul></ul></ul><ul><ul><ul><li>Volume </li></ul></ul></ul><ul><ul><ul><li>Position in space </li></ul></ul></ul><ul><ul><ul><li>Reactions </li></ul></ul></ul><ul><ul><ul><li>Molecules </li></ul></ul></ul><ul><ul><li>Lattice </li></ul></ul>
    5. 5. What else can we reuse? <ul><li>Model = Σ (structure, parameters, state) </li></ul><ul><li>Structure = compartments, labels, </li></ul><ul><li>State =molecules in Σ (structure, parameters, state) </li></ul><ul><li>Compartment structure: </li></ul><ul><ul><li>nesting... </li></ul></ul><ul><ul><li>identities of top-level compartments at lattice positions </li></ul></ul><ul><ul><li>topology only </li></ul></ul>
    6. 6. So modelling is programming? <ul><li>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? </li></ul><ul><li>Answer: </li></ul><ul><ul><li>Reusable components lower the barriers to development. Robustness follows as reused code implemented only in one place. </li></ul></ul><ul><ul><li>Abstraction is key to delivering reusable components. </li></ul></ul>
    7. 7. Reusability in biological models <ul><li>One example already, modules of P system rules: </li></ul><ul><li>Set of reactions where some molecular identities, compartment labels or rate constants are undefined. </li></ul><ul><ul><li>UnregulatedExpression({X},{ b },{ c 1 ,c 2 }) = { </li></ul></ul><ul><li>[geneX] b -> [geneX + proteinX] b, </li></ul><ul><li>[ proteinX] b -> [Ø ] b } </li></ul><ul><li>Modules of modules: </li></ul><ul><ul><li>NegativeAutoRegulation = ({X},{ b },{ c 1 ,c 2 ,c 3 }) ={ </li></ul></ul><ul><ul><li>UnregulatedExpression({X},{ b },{ c 1 ,c 2 }), </li></ul></ul><ul><li>[gene X] b + [proteinX] b -> [geneX.proteinX] b , ... } </li></ul><ul><li>Equivalent of Traits* in OOP languages </li></ul><ul><ul><li>No state just expected inputs and outputs </li></ul></ul>c 1 c 2 c 3 * Shärli et al. (2002) Traits: Composable Units of Behaviour.
    8. 8. Reusing lattices <ul><li>Lattice by itself: </li></ul><ul><ul><li>reuse size, shape and topology of lattice </li></ul></ul><ul><li>Lattice with identities </li></ul><ul><ul><li>by switching between lattices we can explore how neighbourhood affects system </li></ul></ul>->
    9. 9. Reusing models <ul><li>Compose larger models from smaller ones </li></ul><ul><li>Scenarios: </li></ul><ul><ul><li>intracellular endosymbionts: insert compartment ( Buchneria sp. ) into top-level compartment (aphid), observe changes in aphid metabolism. </li></ul></ul><ul><ul><li>Also parasites, infections, tumors, ... </li></ul></ul><ul><ul><li>Mixing populations of bacteria – cross talk of quorum sensing molecules </li></ul></ul><ul><li>Need to resolve conflicts between models? </li></ul>
    10. 10. Reusing simulation results <ul><li>Can already reuse simulation protocols as simulation parameters are factored out of model </li></ul><ul><li>Each simulation produces large HDF5 file containing multiple runs </li></ul><ul><li>Simulator results software produces plots quantities from HDF5 [demo] </li></ul><ul><li>Can’t combine plots from different models in GUI </li></ul><ul><li>More plots: histogram of quantities of molecule A at time t i , surface histogram (A for all timepoints) </li></ul><ul><li>Extract plot data (and formatting) belonging to model-simulation pairs so that appropriate comparisons can easily be made </li></ul>
    11. 11. Extending the OOP metaphor <ul><li>Models are classes or objects! </li></ul><ul><ul><li>Models must have structure (class): </li></ul></ul><ul><ul><ul><li>compartments in space (nested / on lattice) </li></ul></ul></ul><ul><ul><ul><li>reactions (in compartments) </li></ul></ul></ul><ul><ul><li>Models can have state (object): </li></ul></ul><ul><ul><ul><li>molecules in compartments </li></ul></ul></ul><ul><ul><ul><li>current time </li></ul></ul></ul><ul><ul><li>Models with a partially undefined structure are like abstract classes. </li></ul></ul>
    12. 12. Abstract models <ul><li>Just like abstract classes in OOP, some features remain undefined: </li></ul><ul><ul><li>compartment identities in model structure </li></ul></ul><ul><ul><li>reactant/compartment identities and rate constants in reactions </li></ul></ul><ul><ul><li>compartment positions in space </li></ul></ul><ul><ul><li>quantities of molecules in compartments </li></ul></ul><ul><li>Abstract models can’t be simulated as they are incomplete </li></ul><ul><li>Abstract models must be inherited by other models and missing features defined. </li></ul>
    13. 13. Inheriting from a model <ul><li>Declare parent-child relationship: </li></ul><ul><ul><li>“ E.coli inherits AbstractBacteria” </li></ul></ul><ul><li>Concrete models can be inherited too </li></ul>Esherichia coli P. aeruginosa AbstractBact. PAO1 Nott. PAO1 Santa Fe
    14. 14. Overriding inherited reactions <ul><li>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>) </li></ul><ul><li>In models, reaction overriding = method overriding: </li></ul><ul><li>model.reaction: reactants -> products <constant> </li></ul><ul><li>e.g. </li></ul><ul><li>Parent.Reaction3: A + B -> C c 3 = 0.0125 </li></ul><ul><li>Child.Reaction3: A + B -> C c 3 = 0.06 4x faster </li></ul><ul><li>Reaction can be removed in the child model by declaring a reaction with the same header and a rate constant of zero: </li></ul><ul><li>Child.Reaction3: A + B -> C c 3 = 0 propensity = A x B x 0 </li></ul><ul><li>Reaction 3 can never occur now because its propensity will always be zero. </li></ul><ul><li>Plus , the absence is explicit in the model. </li></ul>c 3 c 3 c c 3
    15. 15. Reusing model state <ul><li>Create a set of states that represent hypotheses about the potential states of the system </li></ul><ul><ul><li>what happens when A is high and B is low? (v.v.) </li></ul></ul><ul><li>Can initialise various concrete submodels of abstract parent with same state to test the hypotheses they embody </li></ul><ul><li>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?) </li></ul>
    16. 16. “ Known unknowns” <ul><li>With abstract models and inheritance: </li></ul><ul><li>Unknown rates do not have to be guessed </li></ul><ul><li>Unknowns are delegated to inheriting models </li></ul><ul><ul><li>which therefore embody hypotheses about the values of those unknowns </li></ul></ul><ul><li>models can be built with incomplete knowledge </li></ul><ul><ul><li>and future modellers clearly know what was unknown </li></ul></ul>
    17. 17. Software design patterns <ul><li>Software design patterns* in are general reusable solutions to commonly occurring design problems. </li></ul><ul><li>In OOP design patterns: </li></ul><ul><li>are relationships and interactions between objects </li></ul><ul><li>defined by abstract classes and interfaces (purely abstract) </li></ul><ul><li>have simple distinctive names: Singleton, Prototype, Composite </li></ul><ul><li>independent of application </li></ul><ul><li>allow communication between programmers in terms of patterns </li></ul><ul><li>Are there biological design patterns? </li></ul>* Gamma, Helm, Johnson and Vlissides (1995) Design Patterns. Addison-Wesley Professional
    18. 18. Biological design patterns <ul><li>Margaret Boden’s 7 features of life: </li></ul><ul><li>self-organization </li></ul><ul><li>autonomy </li></ul><ul><li>growth </li></ul><ul><li>adaptation </li></ul><ul><li>reproduction </li></ul><ul><li>evolution </li></ul><ul><li>metabolism </li></ul><ul><li>Add to that: </li></ul><ul><li>autopoiesis </li></ul><ul><li>sexual reproduction </li></ul><ul><li>Architectural patterns, not molecular </li></ul>
    19. 19. Biological design patterns <ul><li>Regulatory motifs: </li></ul><ul><ul><li>NAR, IFFL, ...* </li></ul></ul><ul><ul><li>molecular, varying levels of detail </li></ul></ul><ul><ul><li>too small to be patterns? </li></ul></ul><ul><li>Potential patterns: </li></ul><ul><ul><li>oscillators </li></ul></ul><ul><ul><li>delays </li></ul></ul><ul><ul><li>inverters </li></ul></ul><ul><li>Partial models enable us to encode context in modules which would otherwise need to be associated with compartments by the modeller. </li></ul><ul><li>* Alon, U. (2007) An Introduction to Systems Biology: Design Principles of Biological Systems. Chapman & Hall/CRC </li></ul>
    20. 20. Outcomes <ul><li>Manage complexity </li></ul><ul><li>Share common structure between models </li></ul><ul><li>Encourages incremental model building: </li></ul><ul><ul><li>one set of features added </li></ul></ul><ul><ul><li>model is inherited </li></ul></ul><ul><ul><li>next set of features added </li></ul></ul><ul><li>Potential applicability in evolutionary optimisation and ALife: </li></ul><ul><ul><li>mutated model inherits parent model but only mutated features are recorded – trace evolution </li></ul></ul><ul><ul><li>crossover more difficult – multiple inheritance makes lineage harder to trace </li></ul></ul>
    21. 21. Acknowledgements <ul><li>Thanks to: </li></ul><ul><ul><li>Dr. Natalio Krasnogor </li></ul></ul><ul><ul><li>Dr. Francisco J. Romero Campero </li></ul></ul><ul><ul><li>Dr. Jamie Twycross </li></ul></ul><ul><ul><li>Dr. Hongqing Cao </li></ul></ul><ul><ul><li>James Smaldon </li></ul></ul><ul><li>Funded by: </li></ul><ul><li>EPSRC grant EP/E017215/1 </li></ul><ul><li>BBSRC grant BB/F01855X/1 </li></ul>Infobiotics
    22. 22. An aspirational quote <ul><li>“ 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. </li></ul>

    ×