Difference between revisions of "Design Patterns for engineering SOS"
From Self-Organization Wiki
| (12 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | == Design Patterns for SOS? == | |
| − | * The idea of reuse existing, proven solutions seems to be interesting... | + | * The idea of reuse existing, proven solutions seems to be interesting, but... |
| − | |||
* Focus on mechanisms that cause systems to be SOS | * Focus on mechanisms that cause systems to be SOS | ||
* Use a pattern at design time, so that a SOS runtime behaviour shows up | * 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 |
| + | ** Categorize 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 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 | + | ** Checklist for basic properties of SOS: Adaptivity, Emergence, Autonomy, Decentralisation, Cognition, Feedback, Multiple intercations |
| − | * Runtime effects to show up: spatial temporal structures, | + | * 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 | * Patterns of coordination | ||
** Stigmergy | ** Stigmergy | ||
| − | ** Combine positive/negative | + | *** Using a shared medium/memory for aggregation |
| − | * Control Theory -> Feedback | + | *** Decoupled coordination and communication style |
| + | *** Links exist to distributed system's work on "Virtual Shared Memory", Tuple Spaces, Blackboard approaches | ||
| + | *** Examples: Ant systems, Wikipedia, etc. | ||
| + | ** "Local Gradient" | ||
| + | *** Agents perceive relation to other agents, aggregate relations, communicate their information, and adapt their actions | ||
| + | *** Highly dynamic (dependent on agent availability, location, time), real-time | ||
| + | *** Examples: Swarms and packs (coordinated flight of bird swarms, hunting behaviour of packs, etc.) | ||
| + | ** Combine positive/negative feedback w. balance, evolution | ||
| + | *** Including approaches for stopping / re-starting evolution process | ||
| + | * Control Theory -> Feedback loop | ||
* Coupling between local interactions and global behaviour | * 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'' [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29] | ||
| + | * 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. | ||
Latest revision as of 10:06, 14 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
- Categorize 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
- Using a shared medium/memory for aggregation
- Decoupled coordination and communication style
- Links exist to distributed system's work on "Virtual Shared Memory", Tuple Spaces, Blackboard approaches
- Examples: Ant systems, Wikipedia, etc.
- "Local Gradient"
- Agents perceive relation to other agents, aggregate relations, communicate their information, and adapt their actions
- Highly dynamic (dependent on agent availability, location, time), real-time
- Examples: Swarms and packs (coordinated flight of bird swarms, hunting behaviour of packs, etc.)
- Combine positive/negative feedback w. balance, evolution
- Including approaches for stopping / re-starting evolution process
- Stigmergy
- Control Theory -> Feedback loop
- 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.
