Difference between revisions of "Design Patterns for engineering SOS"

Revision as of 10:47, 13 July 2010

Design Patterns for SOS?

• The idea of reuse existing, proven solutions seems to be interesting, but...
• Focus on mechanisms that cause systems to be SOS
• Use a pattern at design time, so that a SOS runtime behaviour shows up
• The usage of design patterns depends on the nature of the desired system
  • Kategorize types of SOS and assign possible design patterns, which are useful for which type
• Checklist seems currently to be more appropriate, we know what is necessary to get SOS
  • Checklist for basic properties of SOS: Adaptivity, Emergence, Autonomy, Decentralisation, Cognition, Feedback, Multiple intercations
• Runtime effects to show up: spatial temporal structures, multiple stability, parameter bifurcation

Design Patterns

• Achitectural patterns
  • Observer-Controller Architecture (Organic Computing)
  • MAPE (Monitor, Analyze, Process, Execute) Cycle (IBM Autonomic Computing)
• Patterns for (interaction) mechanisms
  • Artificial Hormone System (moving/placing resources/load balancing)
  • Ant foraging (reliably find shortest routes)
  • Pulse-coupled oscillators
  • Plain diffusion, replication, chemotaxis, and stigmergy, …

• Patterns of coordination
  • Stigmergy
  • Combine positive/negative Feedback w. Balance
• Control Theory -> Feedback
• Coupling between local interactions and global behaviour

Related Work on Design Patterns

In software engineering: a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations [1]

• Design Patterns for Self-organising Systems, Gardelli et al.
• Design Patterns from Biology for Distributed Computing, Babaoglu et al.
• Design patterns for decentralised coordination in self-organising, De Wolf et al.