the liquid computing paradigm

The Liquid Computing Paradigm

Thomas Gabor and Matthias Holzl

Lehr- und Forschungseinheit Programmierung & SoftwaretechnikLudwig-Maximilians-Universitat Munchen

Steering Complex Adaptive Systems & Fundamentals ofCollective Adaptive Systems

20th July 2015, European Conference on Artificial Life 2015,University of York

WarningThis 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!

I complex software projects “absorb” real-life problems

I software developers face increasingly more complex problems

I ...but are not getting any smarter!

Thus, software needs to get smarter...

I adapt to ever-changing environment/requirements

I guarantee functionality

I fail gracefully

Challenges

Software everywhere!

I complex software projects “absorb” real-life problems

I software developers face increasingly more complex problems

I ...but are not getting any smarter!

Thus, software needs to get smarter...

I adapt to ever-changing environment/requirements

I guarantee functionality

I fail gracefully

Engineering Self-Adaptive Software

time

deployment

offlinedevelopment

onlineadaptation requirements

Engineering Self-Adaptive Software (in the field)

time

deployment

deployment

offlinedevelopment requirementsonline

adaptation

Problems

Engineering paradigms are not fit for collective adaptive systems

I De-centralization makes deployment difficult

I Self-adaptation makes guarantees difficult

Information loss during the software’s life-cycle

I during deployment, the development history of the software islost

I during development, the online adaptations of the system arelost

Problems

Engineering paradigms are not fit for collective adaptive systems

I De-centralization makes deployment difficult

I Self-adaptation makes guarantees difficult

Information loss during the software’s life-cycle

I during deployment, the development history of the software islost

I during development, the online adaptations of the system arelost

Suggestion #1

“Eternal Systems” (Nierstrasz et al., 2008)

I changes in the software are added as new artifacts withcertain semantic relationships to existing ones

I old artifacts are never completely removed but used for testsor fall-back behavior, e.g.

But we need a meaningful way to choose between or combinemultiple conflicting artifacts.

Suggestion #1

“Eternal Systems” (Nierstrasz et al., 2008)

I changes in the software are added as new artifacts withcertain semantic relationships to existing ones

I old artifacts are never completely removed but used for testsor fall-back behavior, e.g.

But we need a meaningful way to choose between or combinemultiple conflicting artifacts.

Suggestion #2

“Continuous Collaboration” (Holzl and Gabor, 2015)

I several “teachers” are programmed to propagate certainrespective behavior inside the CAS

I their fight for success gives rise to an implicit evolutionarymechanic

But we need a respective pool of suitable candidate programs forour problem.

Suggestion #2

“Continuous Collaboration” (Holzl and Gabor, 2015)

I several “teachers” are programmed to propagate certainrespective behavior inside the CAS

I their fight for success gives rise to an implicit evolutionarymechanic

But we need a respective pool of suitable candidate programs forour problem.

The Liquid Computing Paradigm

timedevelopment+ adaptation

requirements

The Liquid Computing Paradigm

“We envision the future of software development to be less likearchitecture, but more like gardening.”

I blending between design and run time

I pervasive use of autonomous learning techniques

I “ball of mud” scalability, no central instance of control

I large library of local strategies available among several systems

Thank You!