db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
@InProceedings{Welch09b,
  title =        "{E}ngineering {E}mergence: an occam-pi {A}dventure",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  author=        "Welch, Peter H. and Wallnau,  Kurt and Klein,  Mark",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  editor=        "Welch, Peter H. and Roebbers,  Herman and Broenink,  Jan F. and Barnes,  Frederick R. M. and Ritson,  Carl G. and Sampson,  Adam T. and Stiles,  G. S. and Vinter,  Brian",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  pages =        "403--403",
  booktitle=     "{C}ommunicating {P}rocess {A}rchitectures 2009",
  isbn=          "978-1-60750-065-0",
  year=          "2009",
  month=         "nov",
  abstract=      "Future systems will be too complex to design and implement
     explicitly.
Instead, we will have to learn to engineer
     complex behaviours
indirectly: through the discovery and
     application of local rules of
behaviour, applied to simple
     process components, from which desired
behaviours
     predictably emerge through dynamic interactions
     between
massive numbers of instances.  This talk considers
     such indirect
engineering of emergence using a
     process-oriented architecture.
Different varieties of
     behaviour may emerge within a single
application, with
     interactions between them provoking ever-richer
patterns ­
     almost social systems. We will illustrate with a study
based
     on Reynolds' boids: emergent behaviours include flocking
     (of
course), directional migration (with waves), fear and
     panic (of
hawks), orbiting (points of interest), feeding
     frenzy (when in a large
enough flock), turbulent flow and
     maze solving. With this kind of
engineering, a new problem
     shows up: the suppression of the emergence
of undesired
     behaviours.  The panic reaction within a flock to the
sudden
     appearance of a hawk is a case in point. With our
     present
rules, the flock loses cohesion and scatters too
     quickly, making
individuals more vulnerable. What are the
     rules that will make the
flock turn almost-as-one and
     maintain most of its cohesion? There are
only the boids to
     which these rules may apply (there being, of course,
no
     design or programming entity corresponding to a flock).
     More
importantly, how do we set about finding such rules in
     the first
place?  Our architecture and models are written in
     occam-pi, whose
processes are sufficiently lightweight to
     enable a sufficiently large
mass to run and be interacted
     with for real-time experiments on
emergent behaviour.  This
     work is in collaboration with the Software
Engineering
     Institute (at CMU) and is part of the CoSMoS project (at
the
     Universities of Kent and York in the UK)."
}