Main Conferences and Workshops on Software Architectures

  • European Conference on Software Architecture (ECSA): 2009 (merged with WICSA), 2008, 2007, 2006, 2005, 2004.

Other resources:

Main Conferences and Workshops on Autonomic Computing

  • Software Engineering for Adaptive and Self-Managing Systems (SEAMS): 2009, 2008, 2007, 2006.
  • Latin-American Autonomic Computing Symposium (LAACS): 2009, 2008, 2007.
  • Workshop on Self-Healing Systems (WOSS): 2004, 2002.
  • Design and Evolution of Autonomic Application Software (DEAS): 2005.
  • Conference on the Human Impact and Application of Autonomic Computing Systems (CHIACS2): 2004.
  • International Conference on Self-Organization and Autonomous Systems in Computing and Communications (SOAS): 2007, 2006, 2000-2005.
  • Special Issue on Self-managed systems and services Commun. ACM, 49 (2006), pp. 36-39.
  • IFIP/IEEE International Workshop on Self-Managed Systems and Services: 2006, 2005.

Other resources:

Bibtex

@inproceedings{FromGoalsToComponents,
 author = {Daniel Sykes and William Heaven and Jeff Magee and Jeff Kramer},
 title = {From goals to components: a combined approach to self-management},
 booktitle = {SEAMS '08: Proceedings of the 2008 international workshop on Software engineering
              for adaptive and self-managing systems},
 year = {2008},
 isbn = {978-1-60558-037-1},
 pages = {1--8},
 location = {Leipzig, Germany},
 doi = {http://doi.acm.org/10.1145/1370018.1370020},
 publisher = {ACM},
 address = {New York, NY, USA},
 }

From Goals to Components: A Combined Approach to Self-Management

Authors: Daniel Sykes, William Heaven, Jeff Magee, and Jeff Kramer.
Booktitle: SEAMS '08: Proceedings of the 2008 international workshop on Software engineering
           for adaptive and self-managing systems.
Year: 2008.

pdf (479k)

1. INTRODUCTION

The software used to control highly reliable autonomous systems must itself be reliable and highly adaptable. This requires that the autonomous system is able to cope with changes in the environment, changing goals, and failures in its software or hardware. Contact with the operator or programmer may be infrequent at best. The three-layer reference model proposed by the authors contains the following: an uppermost layer (goal management layer) which comprises expensive deliberative planning, a middle layer (change management layer) responsible for plan execution, and a lowest layer (component layer) which handles reactive control concerns. Two feedback loops exist between the layers. Reactive planning from abstract goals forms the top layer, a plan interpreter and configuration generator occupy the middle layer, and a configuration os software components resides in the lowest layer.

Reactive plans are generated from a high-level goals given in temporal logics, and a description of the capabilities of the system. A reactive plan consists of a set of condition-action rules, which specify the behaviour of the system. In addition to the sequence of actions intended to lead to the goal, a reactive plan also includes alternative paths which can be followed, should the environment change in an unpredictable way. The plan drives an automatic assembly of components, as the actions in the plan implicitly give the functional requirements of the configuration. Having divorced the specification of the architecture from the programmer, we are able to permit arbitrary adaptations. The focus is on architecture adaptation, which permits widespread, if not total, change, while keeping the consistency and safety issues present at lower levels to a minimum.

2. RELATED WORK

  • D. Garlan, V. Poladian, B. Schmerl, and J. P. Sousa. Task-based self-adaptation. In WOSS ’04: Proceedings of the 1st ACM SIGSOFT workshop on Self-managed systems, pages 54–57, New York, NY, USA, 2004. ACM Press: adaptations are driven by a change of goal.
  • N. Arshad, D. Heimbigner, and A. L. Wolf. A planning based approach to failure recovery in distributed systems. In WOSS ’04: Proceedings of the 1st ACM SIGSOFT workshop on Self-managed systems, pages 8–12, New York, NY, USA, 2004. ACM Press: adaptations are found by resorting to replanning.
  • D. Sykes, W. Heaven, J. Magee, and J. Kramer. Plan-directed architectural change for autonomous systems. In Proc. of SIGSOFT/FSE Workshop on Specification and Verification of Component-based Systems. ACM Press New York, NY, USA, 2007: introduces the idea of automatically deriving software component configurations from automatically generated plans.
  • S. W. Cheng, D. Garlan, B. R. Schmerl, J. P. Sousa, B. Spitnagel, and P. Steenkiste. Using architectural style as a basis for system self-repair. In WICSA 3: Proceedings of the IFIP 17th World Computer Congress – TC2 Stream / 3rd IEEE/IFIP Conference on Software Architecture, pages 45–59, Deventer, The Netherlands, The Netherlands, 2002. Kluwer, B.V.  D. Garlan and B. Schmerl. Model-Based Adaptation for Self-Healing Systems. In Proc. of 1st Workshop on Self-healing Systems, New York, NY, USA, 2002.  D. Garlan, R. Allen, and J. Ockerbloom. Exploiting Style in Architectural Design Environments. In Proc. of 2nd ACM SIGSOFT Symposium on Foundations of Software Engineering, New York, NY, USA, 1994: achieves dynamic change by describing an architectural style for a system and a repair strategy.
  • J. Zhang and B. Cheng. Modular Model Checking of Dynamically Adaptive Programs. Technical report, Michigan State University, 2006: derives the state machines of two programs and examine the guarantees of each to determine if a programmer-specific transition between them is safe.
  • E. M. Dashofy, A. van der Hoek, and R. N. Taylor. Towards architecture-based self-healing systems. In WOSS ’02: Proceedings of the first workshop on Self-healing systems, pages 21–26, New York, NY, USA, 2002. ACM Press.  J. E. Robbins, D. M. Hilbert, and D. F. Redmiles. Using Critics to Analyze Evolving Architectures. In Joint Proc. of ISAW-2 and Viewpoints ’96 on SIGSOFT ’96 Workshops, New York, NY, USA, 1996: uses an architectural model and design critics to determine whether a set of changes (an architectural ‘delta’) is safe to apply to a given configuration.
  • J. C. Georgas and R. N. Taylor. Towards a knowledge-based approach to architectural adaptation management. In WOSS ’04: Proceedings of the 1st ACM SIGSOFT workshop on Self-managed systems, pages 59–63, New York, NY, USA, 2004. ACM Press: describes a system where change is enacted by architectural policies which are invoked in response to certain events such as component failure.
  • I. Georgiadis, J. Magee, and J. Kramer. Self-organising software architectures for distributed systems. In WOSS ’02: Proceedings of the first workshop on Self-healing systems, pages 33–38, New York, NY, USA, 2002. ACM Press: describes a distributed approach to enforcing architectural constraints, though ultimately repairs are specified by the programmer.

3. GOAL MANAGEMENT LAYER

The top layer of the conceptual model concerns the generation of reactive plans from high-level goals. These plans specify the behaviour of the system in terms of actions which lead from an initial state to a goal state. A reactive plan accommodates a non-deterministically changing environment by prescribing an action towards a givel goal for each state from which that goal is reachable. Execution of such a plan proceeds by determining the current state of the environment, selecting the action prescribed for that state by the plan, performing it and then determining the new state.

In authors’ implementation, reactive plans are generated using planning-as-model-checking technology. A description of the system’s environment is specified in the NuSMV 2 tool, expressing state predicates and pre- and post-condition constraints on the actions that may be performed. This description is submitted to the Model-Based Planner (MBP) tool along with a specification of the initial state and a goal, typically expressed in computational tree logic (CTL).

3.1. DOMAIN MODEL

In order to generate plans automatically, the environment of the system must be defined formally. This description is known as the domain model. A given state of the environment is represented by the set of propositions that are true in that state. Formally a domain model is a 4-tuple:

D = <Props, States, Actions, Trans> where:

  • Props = finite set of propositions;
  • States ⊆ 2Props = set of states;
  • Action = finite set of actions;
  • TransStates x Actions x States = transition relation.

3.2. PLAN GENERATION

Plans to achieve a particular goal in a given environment are automatically generated from a domain model and a goal expressed in a temporal logic (in authors’ implementation CTL). The required steps for plan generation are: i) the model-checking technology identifies those states in the domain satisfying the specified goal; ii) search breadth-first for paths to those states from all other states in the domain model from which the goal states are reachable, iii) if the search terminates having found a path from the current state of the system to a goal state, then the goal is achievable. Formally, a plan can be represented as a partial map from states of the domain to actions of the domain:

P : States → Actions

The component configuration of the system is determined by the actions required by a plan. For a state sStates and a action aActions, P(s) = a only if (s, a, s’)Trans, for some s’States:

ActionsP = range(P)

4. CHANGE MANAGEMENT LAYER

The middle layer is concerned with using the plans generated by the layer above to construct component configurations and direct their operation to achieve the goal addressed by the plan. It is also concerned with making changes to the component configuration when this becomes necessary (on component failure). The authors use a simplified component model based on Darwin. In this model a component explicitly states its requirements and provisions. We refer to the set of provision of a component x as prov(x), and the set of requirements as req(x). A configuration is constructed by instantiating components and connecting required ports to the provided ports of another component where the interface type matches. A complete configuration, then, contains no component with an unsatisfied requirement.

4.1. DERIVING COMPONENT CONFIGURATIONS

The change management layer is able to use the plan to derive the functional requirements of the system’s architecture. For example, the presence of a move operation in the plan clearly indicates that the configuration must include a component which provides a suitable implementation of this action. With each type of action, the authors associate a particular interface type, and thus the plan interpreter selects components which implement the relevant interface. Given the set of components required for their functionality, the interpreter can then construct a complete configuration by considering the required interfaces of those components. In the case where a component is already instantiated (or selected for instantiation) is should be reused. Components can be marked as “unavailable”.

The relationship between the actions required by a plan and the interfaces that implement those actions can be represented as a binary relation:

Implements ⊆ Actions x Interfaces

For a given plan P, the image of  ActionsP under Implements,

Implements[ActionsP] = {y ∈ Interfaces : ∃ x ∈ ActionsP · (x, y) ∈ Implements}

is thus the set of interfaces that implement the actions in the plan. An initial configuration can be generated with the call: Construct (∅, Implements[ActionsP]). Subsequent configurations can be generated with a call such as: Construct (oldArch, Implements[ActionsP]), where the first parameter indicates the existing configuration. The configuration generated by the algorithm presented in the paper satisfies the following constraints:

∀ i ∈ Implements[ActionsP] : ∃ c ∈ Arch · i ∈ Prov(c)

∀ c ∈ Arch : i ∈ req(c) → ∃ c2 ∈ Arch · i ∈ Prov(c2)

It is possible to find multiple solutions for a given search for configurations. It may be the case that these alternatives have differing non-functional properties which can be used to make a choice.

If an action component fails due to some internal (non-architectural) problem, it must be replaced. However, if it fails due to a problem in its dependencies, then its dependencies must be replaced. The component types that have failed are marked as unavailable, and the component selection process runs to locate alternatives. The delta computed, for some current configuration, current, and a failed component, failed, is:

delta = current – Construct(current, prov(failed))

5. COMPONENT LAYER

Components are implemented as objects in Java, following the component model prescribed by the Backbone language and its associated graphical design tool, jUMbLe. Provisions are indicated using the normal implements syntax, while required ports are implemented as fields. The Backbone interpreter runs on a JVM on a number of Koala robots and a Katana robot arm which the authors use for demonstrating the work.

The paper presents two case studies. The first one requires a robot to move to a location and take a photograph of a target. This scenario demonstrates adaptation in response to a (simulated) failure in the components which control the primary robot’s motion, and includes a second robot which is able to guide the first one towards the target. The second one requires a mobile robot to co-operate with a robot arm in order to collect a number of coloured balls. In this scenario, the goal is a continuous one, that is, balls must be picked up as long as there are balls remaining. Hence, the plan is cyclic.

6. FUTURE WORK

  • Achieve the complete feedback loop indicated in the three-layer model, by using dynamic replanning. Dynamic replanning will occur in two categories of scenario: i) when execution of the current plan fails e ii) when current goals are changed during execution;
  • Prevent the system from entering cycles where it switches between two alternative plans or configurations, neither of which make any progress;
  • Take into account, in the configuration selection process, differing non-functional properties;
  • Introduce extra structural constraints (fixed components or compliance to a specific architectural style), for example by using the Alloy analyser;
  • Ensure safety during change execution;
  • Keep the unaffected parts of the architecture running while reconfigurations are taking place.

Follow

Get every new post delivered to your Inbox.