A Rigorous Architectural Approach to Adaptive Software Engineering

Abstract

The engineering of distributed adaptive software is a complex task which requires a rigorous approach. Software architectural (structural) concepts and principles are highly beneficial in specifying, designing, analysing, constructing and evolving distributed software. A rigorous architectural approach dictates formalisms and techniques that are compositional, components that are context independent and systems that can be constructed and evolved incrementally. This paper overviews some of the underlying reasons for adopting an architectural approach, including a brief "rational history" of our research work, and indicates how an architectural model can potentially facilitate the provision of self-managed adaptive software system. Software Architecture ApproachesDistributed processing offers the most general, flexible and promising approach for the provision of computing services. It offers advantages in its potential for improving availability and reliability through replication; performance through parallelism; and sharing and interoperability through interconnection.Studies in software maintenance for distributed systems have indicated that the general move to distribution contributed to the simplification of the primitive software components used in distributed systems. However, this benefit is often overwhelmed by the increased complexity of the overall system. There is therefore a need to deal with issues such as component interaction and composition, design complexity, system organisation and reasoning. Rigorous use of a software architecture offers much potential benefit in providing a framework or skeleton with which to deal with these issues.Software architecture descriptions aim to specify system structure at a sufficiently abstract level to deal with large and complex systems yet be sufficiently detailed to support reasoning about various aspects and properties. Architectures are generally defined hierarchically, as compositions of interconnected components. A component type is defined in a context-independent manner in terms of its communication interface: the services it provides to other components and the services it requires in order to perform its functionality.Composite components are defined in terms of their constituent components (other primitive or composite components) and the bindings between these. Services provided internally are bound to an interface service provision so as to be available externally. Service requirements which cannot be satisfied internal to the composite component are made visible at its interface. Thus architectural descriptions support abstraction by hierarchical decomposition and encapsulation. The purpose of an Architectural Description Language (ADL) is to facilitate provision of precise software architecture descriptions, and to provide associated reasoning and/or software construction support.A software architecture can be used as a model in much the same way as other engineers build models to check particular aspects of a system design. We believe that an ADL...

A White Box Perspective on Behavioural Adaptation

“…(ii) It allows us to relate approaches presented independently and in different areas but sharing, essentially, the same category of control data. This is, e.g., the case of the approaches based on modes of operation proposed by the Software Engineering [11] adaptation coordination strategies adaptation strategy 4.1 [48] adaptation rules adaptation strategy 5.3 [15] architecture architecture 3.1 [46] architecture architecture 3.2 [60] architecture architecture 3.2 [66] module stack architecture 3.2 [22] current workflow architecture 3.2 [7] connectors architecture 3.2 [11] architecture architecture 4.1 [76] effector channel architecture 4.3 [48] set of activities architecture 5.3 [61] entire programs entire program 4.1 [55] rewrite rules entire program 4.2 [35] processes entire program 4.3 [30] processes entire program 4.3 [28] features operation mode 4.1 [53] regions operation mode 4.1 [83] operation mode operation mode 4.1 [1] active configuration operation mode 4.1 [72] active configuration operation mode 4.1 [19] control proposition operation mode 4.1 [82] steady state programs operation mode 4.1 [42] state space zones operation mode 4.1 [33] graph rewrite rules operation mode 4.2 [80] base level Petri net operation mode 4.3 [51] adaptor processes operation mode 4.3 [16] adaptable (local) processes operation mode 4.3 [69] context stack operation mode 5.1 [36] advices operation mode 5.2 [44] policies operation mode 5.3 community with paradigm-oriented approaches and by the Theoretical Computer Science community with automata and process-algebraic approaches. (iii) It allows us to compare approaches apparently similar (and falling in the same section) but based on different categories of control data.…”

“…Adaptations in this context are typically realized via reconfigurations, which can range from the replacement of a single component to local or even global changes to the interaction topology. Usually such reconfigurations do not modify the functionalities of the individual components, but only the way they are connected and/or interact with each other (see the survey [15], summarized in Section 6, and [46]). Therefore the control data in these approaches can be identified with the interconnection topology itself, which depending on the approaches can be made of channels, connectors, gates, protocol stacks, links, and so on.…”

Architecture-Based Run-Time Fault Diagnosis

“…But it has the disadvantage that each repair handler must do its own diagnosis, possibly adding to run-time overhead (if multiple strategies are used), greatly increasing the effort required to produce repair handlers, and relying on the strategy writer to get the diagnosis right. Similarly, in the three-layer architecture model proposed in [23] higher level planning mechanisms are responsible for diagnosis once a problem has been detected.…”

Resilient critical infrastructure management with a service oriented architecture: A test case using airport collaborative decision making

“…Figure 4 shows three concentric dependability management loops that arise from the SERSCIS architecture. Similar to Kramer and Magee's model for autonomic systems (Kramer and Magee, 2009), this allows runtime information to propagate up to system decision makers and governance actions to flow down to control service execution. System modelling and decision support components are closely linked and may run synchronously; however, with respect to governance and workflow components, the execution is entirely asynchronous.…”