Modular model building

Abstract

Mathematical models are increasingly used in both academia and the pharmaceutical industry to understand how phenotypes emerge from systems of molecular interactions. However, their current construction as monolithic sets of equations presents a fundamental barrier to progress. Overcoming this requires modularity, enabling sub-systems to be specified independently and combined incrementally, and abstraction, enabling general properties to be specified independently of specific instances. These in turn require models to be represented as programs rather than as datatypes. Programmable modularity and abstraction enables libraries of modules to be created for generic biological processes, which can be instantiated and re-used repeatedly in different contexts with different components. We have developed a computational infrastructure to support this. We show here why these capabilities are needed, what is required to implement them and what can be accomplished with them that could not be done previously.

Full text

Page 1

arXiv:0710.3421v1 [q-bio.MN] 18 Oct 2007
Modular model building
Aneil Mallavarapu1∗, Matthew Thomson1,
Benjamin Ullian1, Jeremy Gunawardena,1∗
1Department of Systems Biology, Harvard Medical School
200 Longwood Avenue, Boston, MA 02115, USA.
∗Corresponding authors:
aneilbaboo@gmail.com jeremy@hms.harvard.edu
Tel: (617) 432 4839; Fax: (617) 432 5012
Abstract
Mathematical models are increasingly used in both academia and
the pharmaceutical industry to understand how phenotypes emerge
from systems of molecular interactions. However, their current con-
struction as monolithic sets of equations presents a fundamental bar-
rier to progress. Overcoming this requires modularity, enabling sub-
systems to be specified independently and combined incrementally,
and abstraction, enabling general properties to be specified indepen-
dently of specific instances. These in turn require models to be rep-
resented as programs rather than as datatypes. Programmable mod-
ularity and abstraction enables libraries of modules to be created for
generic biological processes, which can be instantiated and re-used
repeatedly in different contexts with different components. We have
developed a computational infrastructure to support this. We show
here why these capabilities are needed, what is required to implement
them and what can be accomplished with them that could not be done
previously.
1

Page 2

Introduction
With the sequencing of the human genome, biological attention is shifting
from characterizing molecular components to a systems-level understanding
of how phenotypes emerge from molecular interactions [26, 49]. Mathemati-
cal models are increasingly used to shed light on this [1, 4, 33]. Such models
present unusual challenges, not previously encountered in physics or engi-
neering, upon which this paper focuses.
Models may be static (eg: constraint based [4]) or explicitly incorporate
time. The latter are typically a form of dynamical system: they specify
a set of molecular states and how those states evolve in time. Depending
on the type of model, the states may be discrete levels (boolean models
[30]), concentrations (ordinary differential equation models [41]), molecular
numbers (stochastic models [39]) or sets of individual molecules (agent-based
models [13]), considered as functions of time or of space and time (spatial
models [44]). While much of what follows may be broadly generalized, we
focus here on dynamic models represented by ordinary differential equations,
dx
dt= f(x;a)(1)
where x ∈ Rnis a vector of species concentrations, a ∈ Rmis a vector of
parameter values and f expresses the balance between the rates of production
and consumption of each species. Such models are predominantly nonlinear.
Although they may occasionally be analyzed mathematically [18], they are
usually simulated numerically, for which parameter values must be specified
and initial conditions chosen.
Concern is sometimes raised about the complexity of such models and the
large number of undetermined parameters. Model complexity is inevitable,
however, if we wish to reflect the underlying biology [41], while methods
for dealing with parameters are being developed [1, 40]. Pharmaceutical
companies like AstraZeneca and Pfizer as well as biotechnology companies
like GNS and Entelos are now using modeling in drug development [19, 3, 21].
Model complexity is not necessarily a barrier to usefulness and methodologies
for constructing complex models in a controlled manner are therefore all the
more important.
A variety of modeling tools are available [2, 39], standards and ontologies
formulated [24, 38] and public model repositories established [37]. With the
right information to hand, it is straightforward to build a model. However,
2

Page 3

if model building is to be integrated into a research or development pro-
gram, a single monolithic model is never sufficient. Simply to understand
how a model works, it is often essential to create it incrementally, adding
a few ingredients at a time and exploring the effect of alternative assump-
tions. More importantly, feedback between experiments and models leads to
corrections or new assumptions, links appear to systems studied by others
and new knowledge continually emerges in the literature. Such changes are
readily incorporated into the mental “models” maintained by all biologists.
Mathematical models lack such plasticity. Even simple biological changes
can have profound effects on the equations, requiring new equations to be
introduced or the modification of many existing equations and many terms
in each. Beyond a certain level of model complexity, it is easier to build a
new monolithic model from scratch.
For example, Huang and Ferrell constructed an influential model of the
MAP kinase cascade, which shed light on the decision making underlying
maturation of Xenopus oocytes [23]. Levchenko et al subsequently elucidated
the surprising effect of a scaffold protein on MAP kinase signaling [29]. The
second model contains exactly the same MAP kinase cascade as the first,
based on identical assumptions, and differs only in the addition of one new
component, the scaffold. Nevertheless, it was not obtained from the former
by incremental extension; a new monolithic set of equations was constructed.
Anyone wishing to build upon the work of Levchenko et al would have to do
the same. The need to reinvent the wheel each time is a fundamental barrier
to progress.
Much of biology can be thought of as general processes, which operate on
different components and which are combined in different ways. For example,
all scaffolds behave in essentially the same way: they have no intrinsic enzy-
matic function but bind other proteins [36]. Scaffolds may differ in the num-
ber of binding partners and in the behavior of partners when bound but there
is a core mechanism which must be incorporated in any model in which a
scaffold participates. At present, such common behavior cannot be exploited
in model construction. The corresponding equational details must be speci-
fied each time. Model construction would be far easier if these details could
be specified once (by scaffolding experts, say) and this description re-used
repeatedly by instantiating it with the particular binding partners and bind-
ing assumptions that are relevant to the context being modeled. Many other
molecular processes are generic, in the sense that the same core mechanism is
used with different components in different contexts. For instance, all recep-
3

Page 4

tor tyrosine kinase pathways are built from the following generic processes:
receptor dimerization, endo- and exo-cytosis, endosomal recycling, multisite
post-translational modification (including phosphorylation and ubiquitina-
tion), scaffolding, GTPase switching, membrane localization, nuclear import
and export, etc. Model construction would be revolutionized if models could
be built in a modular and incremental fashion from a library of expert de-
scriptions of such generic processes. Models would then build upon each
other, greatly increasing their scope and credibility.
To accomplish this requires modularity, allowing sub-systems to be spec-
ified and then combined incrementally, and abstraction, allowing generic
properties to be specified independently of specific instances. These in turn
require models to be represented as programs within a computational in-
frastructure. Despite the variety of modeling tools available, none provide
programmable modularity and abstraction. We have developed a novel com-
putational infrastructure which does. It is open source and freely available
and a detailed description appears elsewhere. Our purpose here is to show
why modularity and abstraction are needed, what is required to implement
them and what can be accomplished with them that could not be done pre-
viously.
Results
Modularity and abstraction: models as programs Modularity is a
fundamental method for building complex engineering systems. Modules are
sub-systems which are encapsulated to hide their internal complexity and
inter-module communication is only permitted through specified interfaces
(Figure 1a).By sub-dividing the design problem, modularity allows the
engineer to subdue complexity. Although the same term is used in discussions
of evolutionary mechanisms [20] we make no assumptions about evolution;
modularity for us means a method of model construction.
The advantages of the kind of “engineering modularity” just described
have been previously appreciated and the capability is available in certain
tools [31, 16, 48]. However, encapsulating a module and specifying its inter-
face at the time it is designed restrict the module’s interactions to situations
envisaged at design time. Biological modules have no natural encapsulation
other than membranes: in the absence of physical separation, the compo-
nents of one module may, in principle, always interact biochemically with
4

Page 5

the components of another. Our knowledge of which interactions actually
occur may change over time in the light of new experiments. Whether or not
such interactions are incorporated into a model may depend on the assump-
tions being made. In other words, not all interactions can be anticipated
at design time. Furthermore, biological interaction creates entities, either
new biochemical species or complexes of existing ones, which have to be
represented in a model. This does not happen in engineering: wiring two
transistors together does not create a capacitor.
A flexible notion of modularity, adapted to biology, has to allow for the
possibility that modules may be brought together in a way that was not
envisaged at design time and that new entities (species, reactions) may arise
from such modular composition (Figure 1b). The creation of new entities
leads to two problems. First, the introduction of a new entity may have
knock-on consequences in other modules, requiring yet more entities to be
created, and these may in turn have further consequences and so on. Second,
the new entity may already exist in some other module. If so, it is very
important that a duplicate not be constructed.
To solve these problems a computational infrastructure needs, first, to be
capable of reasoning over the modules and the properties of their components
and inferring which entities need to be created (Figure 1b). In engineering
modularity this reasoning is carried out by the designer at design time (Fig-
ure 1a). The capability needed here is analogous to the reasoning process
used in artificial intelligence systems, where pattern-action rules, of the form
P ⇒ A, specify actions (A) to be performed—including modification, re-
moval or creation of entities—whenever there are entities matching the cor-
responding set of patterns (P). The “many-pattern/many-entity” matching
problem is efficiently solved by the widely-used RETE algorithm [14]. Sec-
ond, the infrastructure needs to give unique identities to its entities. This
is a subtle problem because identities cannot simply be random tags: they
must reflect the biological location of the entity and such locations can be
complex entities in their own right (Figure 1c and d).
To implement modularity and abstraction, models have to be represented
as programs. Programming is needed to specify biological knowledge, to cre-
ate new abstractions and to construct and reason about the new entities
that arise from modular composition. This contrasts with SBML, the Sys-
tems Biology Markup Language [24], which treats models as datatypes and
marks them up with meta-data, allowing a model created by one tool to be
analyzed by another. SBML has made a vital contribution by nucleating the
5