Thomas Gabor and Matthias Holzl

1. 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

2. Warning
This is a talk about emerging trends in software engineering!

3. Traditional Software Engineering
time
requirements:
deployment
development runtime

4. Traditional Software Engineering (in the field)
time
deployment
requirements:
development runtime

5. Challenges
Software everywhere!
complex software projects “absorb” real-life problems
software developers face increasingly more complex problems
...but are not getting any smarter!

6. 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

7. Engineering Self-Adaptive Software
time
deployment
offline
development
online
adaptation
requirements

8. Engineering Self-Adaptive Software (in the field)
time
deployment
deployment
offline
development
requirementsonline
adaptation

9. Problems
Engineering paradigms are not fit for collective adaptive systems
De-centralization makes deployment difficult
Self-adaptation makes guarantees difficult

10. 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

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 Computing Paradigm
time
development
+ adaptation
requirements

16. 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

17. Thank You!