The Liquid Computing Paradigm
Thomas Gabor and Matthias H¨olzl
Lehr- und Forschungseinheit Programmierung & Softwaretechnik
Ludwig-Maximilians-Universit¨at M¨unchen
Steering Complex Adaptive Systems & Fundamentals of
Collective Adaptive Systems
20th July 2015, European Conference on Artificial Life 2015,
University of York
Warning
This is a talk about emerging trends in software engineering!
Traditional Software Engineering
time
requirements:
deployment
development runtime
Traditional Software Engineering (in the field)
time
deployment
requirements:
development runtime
Challenges
Software everywhere!
complex software projects “absorb” real-life problems
software developers face increasingly more complex problems
...but are not getting any smarter!
Challenges
Software everywhere!
complex software projects “absorb” real-life problems
software developers face increasingly more complex problems
...but are not getting any smarter!
Thus, software needs to get smarter...
adapt to ever-changing environment/requirements
guarantee functionality
fail gracefully
Engineering Self-Adaptive Software
time
deployment
offline
development
online
adaptation
requirements
Engineering Self-Adaptive Software (in the field)
time
deployment
deployment
offline
development
requirementsonline
adaptation
Problems
Engineering paradigms are not fit for collective adaptive systems
De-centralization makes deployment difficult
Self-adaptation makes guarantees difficult
Problems
Engineering paradigms are not fit for collective adaptive systems
De-centralization makes deployment difficult
Self-adaptation makes guarantees difficult
Information loss during the software’s life-cycle
during deployment, the development history of the software is
lost
during development, the online adaptations of the system are
lost
Suggestion #1
“Eternal Systems” (Nierstrasz et al., 2008)
changes in the software are added as new artifacts with
certain semantic relationships to existing ones
old artifacts are never completely removed but used for tests
or fall-back behavior, e.g.
Suggestion #1
“Eternal Systems” (Nierstrasz et al., 2008)
changes in the software are added as new artifacts with
certain semantic relationships to existing ones
old artifacts are never completely removed but used for tests
or fall-back behavior, e.g.
But we need a meaningful way to choose between or combine
multiple conflicting artifacts.
Suggestion #2
“Continuous Collaboration” (H¨olzl and Gabor, 2015)
several “teachers” are programmed to propagate certain
respective behavior inside the CAS
their fight for success gives rise to an implicit evolutionary
mechanic
Suggestion #2
“Continuous Collaboration” (H¨olzl and Gabor, 2015)
several “teachers” are programmed to propagate certain
respective behavior inside the CAS
their fight for success gives rise to an implicit evolutionary
mechanic
But we need a respective pool of suitable candidate programs for
our problem.
The Liquid Computing Paradigm
time
development
+ adaptation
requirements
The Liquid Computing Paradigm
“We envision the future of software development to be less like
architecture, but more like gardening.”
blending between design and run time
pervasive use of autonomous learning techniques
“ball of mud” scalability, no central instance of control
large library of local strategies available among several systems
Thank You!

The Liquid Computing Paradigm

  • 1.
    The Liquid ComputingParadigm Thomas Gabor and Matthias H¨olzl Lehr- und Forschungseinheit Programmierung & Softwaretechnik Ludwig-Maximilians-Universit¨at M¨unchen Steering Complex Adaptive Systems & Fundamentals of Collective Adaptive Systems 20th July 2015, European Conference on Artificial Life 2015, University of York
  • 2.
    Warning This is atalk about emerging trends in software engineering!
  • 3.
  • 4.
    Traditional Software Engineering(in the field) time deployment requirements: development runtime
  • 5.
    Challenges Software everywhere! complex softwareprojects “absorb” real-life problems software developers face increasingly more complex problems ...but are not getting any smarter!
  • 6.
    Challenges Software everywhere! complex softwareprojects “absorb” real-life problems software developers face increasingly more complex problems ...but are not getting any smarter! Thus, software needs to get smarter... adapt to ever-changing environment/requirements guarantee functionality fail gracefully
  • 7.
  • 8.
    Engineering Self-Adaptive Software(in the field) time deployment deployment offline development requirementsonline adaptation
  • 9.
    Problems Engineering paradigms arenot fit for collective adaptive systems De-centralization makes deployment difficult Self-adaptation makes guarantees difficult
  • 10.
    Problems Engineering paradigms arenot fit for collective adaptive systems De-centralization makes deployment difficult Self-adaptation makes guarantees difficult Information loss during the software’s life-cycle during deployment, the development history of the software is lost during development, the online adaptations of the system are lost
  • 11.
    Suggestion #1 “Eternal Systems”(Nierstrasz et al., 2008) changes in the software are added as new artifacts with certain semantic relationships to existing ones old artifacts are never completely removed but used for tests or fall-back behavior, e.g.
  • 12.
    Suggestion #1 “Eternal Systems”(Nierstrasz et al., 2008) changes in the software are added as new artifacts with certain semantic relationships to existing ones old artifacts are never completely removed but used for tests or fall-back behavior, e.g. But we need a meaningful way to choose between or combine multiple conflicting artifacts.
  • 13.
    Suggestion #2 “Continuous Collaboration”(H¨olzl and Gabor, 2015) several “teachers” are programmed to propagate certain respective behavior inside the CAS their fight for success gives rise to an implicit evolutionary mechanic
  • 14.
    Suggestion #2 “Continuous Collaboration”(H¨olzl and Gabor, 2015) several “teachers” are programmed to propagate certain respective behavior inside the CAS their fight for success gives rise to an implicit evolutionary mechanic But we need a respective pool of suitable candidate programs for our problem.
  • 15.
    The Liquid ComputingParadigm time development + adaptation requirements
  • 16.
    The Liquid ComputingParadigm “We envision the future of software development to be less like architecture, but more like gardening.” blending between design and run time pervasive use of autonomous learning techniques “ball of mud” scalability, no central instance of control large library of local strategies available among several systems
  • 17.