A coordination methodology and technology for agile businesses
Luís Andrade, José Luiz Fiadeiro, João Gouveia, Georgios Koutsoukos, Michel Wermelinger
2002
Companion of the 17th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications - OOPSLA '02
MOTIVATION The engineering of Business Systems is under the increasing pressure to come up with software solutions that allow companies to face very volatile and turbulent environments (as in the telecommunications domain [3] ). This means that the complexity of software has definitely shifted from construction to evolution, and that new methods and technologies are required. Most often, the nature of changes that occur in the business are not at the level of the components that model business
more »
... ntities, but at the level of the business rules that regulate the interactions between the entities. Therefore, we believe that sucessful methodologies and technologies will have to provide abstractions that reflect the architecture of such systems by supporting a clear separation between computation, as performed by the core business components, and coordination, as prescribed by business rules. This separation should help in localising change in the system, both in terms of identifying what needs to be changed in the system and circumscribing the effects of those changes. In our opinion, the lack of abstractions for supporting the modelling of interactions and architectures explains why componentbased and object-oriented approaches have not been able to deliver their full promise regarding system evolution. Usually, interactions are coded in the way messages are passed, features are called, and objects are composed, leading to intricate spaghetti-like structures that are difficult to understand, let alone change. Moreover, new behaviour is often introduced through new subclasses which do not derive from the "logic" of the business domain, widening the gap between specification and design. The approach we have been developing [1] builds on previous work on coordination models and languages, software architecture, and parallel program design languages. Instead of delegation we use explicit architectural connectors that encapsulate coordination aspects: this makes a clear separation between computations and interactions and externalises the architecture of the system. Instead of subclassing we advocate superposition as a structuring principle: Copyright is held by the author/owner. OOPSLA'02, November 4-8, 2002, Seattle, Washington, USA. ACM 1-58113-626-9/02/0011. interactions are superposed on components in a non-intrusive and incremental way, allowing evolution through reconfiguration, even at run-time. The main advantages of our approach are adequacy and flexibility. The former is achieved by having a strict separation of computation, coordination, and configuration, with one primitive for each concept, stating clearly the pre-conditions for each coordination and reconfiguration rule. As for flexibility, interactions among components can be easily altered at run-time through (un)plugging of coordination rules, and it is possible to state exactly which coordination rules are in effect for which components, and which configuration policies apply to which parts of the system. In the following sections we briefly summafise our approach for different phases of software development. More details are provided by the publications available at www.atxsoftware.com. LAWS FOR DESIGN At the modelling level, business entities and rules are specified in an implementation-independent way, by coordination interfaces and coordination laws, respectively. A coordination interface indicates a collection of services that must be provided and events that must be generated by all components that implement the interface. A coordination law states when and how to react to the events of the components that are subject to that law. Put in another way, services are provisions, events are requests, and laws bind provisions to requests, stating exactly when a request is attended and which services are used to process it. We stress that services and events are at the conceptual level; the implementation artefacts (messages, remote procedure calls, intenupts, etc.) they are mapped to depend on the implementation platform. As an example, taken from the banking domain, consider two kinds of components: customers and accounts. We wish to model two business rules: normal customers may not overdraw their accounts, but VIP customers may overdraw up to some limit which is negotiated between the bank and the customer. For these rules, the full specification of accounts and customers is irrelevant. The only necessary services and events are given by the following interfaces: coordination interface account-debit type-id account services debit(m: money); balance() : money properties balance() after debit(m) is balance() -m end interface coordination interface customer-withdrawal 48
doi:10.1145/985072.985098
dblp:conf/oopsla/AndradeFGKW02
fatcat:ydkqzxlvdzhkdnzo32f3ttrura