User Tools

Site Tools


general_principles:architectural_patterns:start

Architectural Patterns

Introduction

Buschmann et. al.1) provides the following descriptive definition of a pattern in general:

“A pattern describes a particular recurring design problem that arises in specific design contexts, and presents a solution to it. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate.” 2)

Moreover, Buschmann et. al.3) lists some common properties of a pattern:

  • “Patterns document existing, well-proven design experience.”
  • “Patterns provide a common vocabulary and understanding for design principles.”
  • “Patterns support the construction of software with defined properties.”
  • “Patterns help you build complex and heterogeneous software. Patterns help you manage software complexity.”

The proposed scheme by Buschmann for describing a software pattern consists of a Context, Problem and the Solution. This triple is used below to also describe individual architectural patterns which analogously address recurring design problems in robotics software development, each occurring in a specific design context, and present a well-proven solution to the design problem. There are two fundamental objectives that drive the design of all presented architectural patterns, namely:

  • Facilitate building systems by composition
  • Support Separation of Roles

Each architectural pattern needs to contribute towards these two objectives.

Template for an Architectural Pattern

This is a template for describing an architectural pattern including the required sections that the description must comprise.

Context

A context describes a situation in which the design problem occurs. Also relate the context to:

  • the Levels and Concerns
  • involved Roles

Problem

This part describes a recurring problem that repeatedly arises in a given context. This can start with a general, open ended problem and get more concrete with driving forces and concrete requirements that the solution must fulfill. Also, constraints to consider and desired properties of the sokution can be expressed here.

Solution

The solution describes how the problem is solved, thereby balancing the driving forces. In some cases, available technologies can be listed here that solve the given problem.

Optional: Discussion

Any discussion of shortcomings, differences or references to other patterns can be described here.

Optional: Example(s)

Specific scenarios or technologies that help to understand the problem and/or solution can be listed here.

List of Architectural Patterns

Further Candidates for Architectural Patterns

  • Architectural Pattern for Coordination-Frame Transformation
    • Transformation tree (e.g. TF in ROS, Time-Stamps, Pose-Stamps, etc.)
  • Subsidiarity Principle
    • at any time a clear control hierarchy
    • delegate decision spaces top-down in the hierarchy
  • Knowledge Representation
    • central Knowledge Base
    • synchronize and conflate distributed system-models over global IDs
  • Reservation based Resource Management
    • in KB through Tasks and Skills for coordination of Components
1) , 2) , 3)
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal. “Pattern-Oriented Software Architecture, Volume 1, A System of Patterns”. Wiley Press, 1996, ISBN: 978-0-471-95869-7
general_principles:architectural_patterns:start · Last modified: 2017/06/06 16:03
http://www.robmosys.eu/wiki/general_principles:architectural_patterns:start