Separating computation, coordination and configuration

Abstract

We present methodological and technological solutions for evolving large‐scale software systems. These solutions are based on many years of research and experience in developing systems in one of the most volatile application domains—banking. We discuss why ‘promising’ software development techniques, such as object‐oriented and component‐based approaches, on their own, cannot meet the challenges and objectives of software development today, and propose a three‐layered architectural approach based on the strict separation between computation, coordination and configuration. We present a set of modelling primitives, design principles and support tools through which such an approach can be put effectively into practice, and discuss how it promotes a more ‘dynamic’ approach to software evolution. Finally, we make comparisons with related work. Copyright © 2002 John Wiley & Sons, Ltd.

Robotic Software Systems: From Code-Driven to Model-Driven Software Development

“…According to (Björkelund et al, 2011), this is in line with results published in (Delamer & Lastra, 2007;Gelernter & Carriero, 1992;Lastra & Delamer, 2006) although variations exist which split configuration (into connection and configuration) or treat configuration and coordination in the same way (Andrade et al, 2002;Bruyninckx, 2011).…”

Using Association Aspects to Implement Organisational Contracts

“…The coordination model outlined here adopts a control-oriented [2] architectural approach, primarily focused on adaptivity rather than synchronisation. ROAD has many similarities and some major differences with work by Andrade, Wermelinger and colleagues [1,11]. Both approaches represent contracts as first-class entities, and both use a layered architecture.…”

“…Both approaches represent contracts as first-class entities, and both use a layered architecture. In [1,11] the layers are Computation, Coordination and Configuration ('3C'). This is broadly similar to ROAD's four layer architecture (Computational-object, Functional-role, Management-contract, Organisation) with 3C's Computation layer similar to ROAD's Object and Functional role layers.…”

“…ROAD contracts are independent, instantiable software entities that maintain the state of the association between two roles played by objects (parties to the contract), rather than being a mechanism for providing interface enforcement for a single class as in DBC; or just as a design concept. ROAD contracts also define rules for all interactions between the parties to the contract, rather than being focused on one type of interaction between many parties as in [1] and [11]. In ROAD contracts, individual interactions are represented by contract clauses that define the respective obligations of the parties during the interaction.…”

Role-based Architectural Modelling of Socio-Technical Systems

“…The particular architectural approach that we propose to extend has been developed within an industry/academia partnership [1,2,3]; it models connector types through coordination laws that bring together a number of event-condition-action (ECA) rules, each of which coordinates the joint behaviour that a group of components (partners) needs to execute in reaction to a trigger generated by another component or outside the system. In the CCC approach partners, over which coordinations laws are instantiated, are represented by means of coordination interfaces.…”