Loading...
Please wait, while we are loading the content...
Similar Documents
Separation of Core Concerns: Computation, Coordination, and Configuration
| Content Provider | Semantic Scholar |
|---|---|
| Author | Wermelinger, Michel Fiadeiro, José Luiz Andrade, Luis Filipe Koutsoukos, Georgios Gouveia, João |
| Copyright Year | 2001 |
| Abstract | Separating concerns helps developers to get a conceptual grip on large software systems, to reuse parts of the system, and to evolve it. We are interested in separating three generic concerns that are part of any software system: computation, coordination, and configuration. For that purpose we propose a three-layer architecture using two new modeling primitives: coordination contracts to define interactions and coordination contexts to govern system reconfiguration. Each layer is superposed in a transparent way on the layer below, which facilitates the modification of coordination and configuration policies to make the system evolve. CATEGORIES: B.A., A.B., E.A. 1. MOTIVATION Taming the ever-growing complexity of software development has been a major goal since the early days of programming. Many concepts and supporting technologies have been put forward, like modules, objects, components, design patterns, aspects, architectural connectors, frameworks, and product-line architectures just to name a few. The rationale is always to provide some help to partition huge software systems into conceptually manageable “chunks” in order to improve design, implementation, and comprehension of such systems. Moreover, such partitioning promotes reuse and facilitates maintenance. However, in turns out that often the partition, to be effective and bring about the mentioned advantages, requires quite some planning of the possible changes to the system in the future. Otherwise the modifications to be performed to the system will conflict with the dependencies that are implicit in the chosen partitioning, and hence may require substantial changes throughout the “chunks”. Recently, Aspect-Oriented Programming [16] has been advocated as a non-invasive technique to incrementally weave new concerns into an existing system. Normally such aspects are limited in scope (e.g., tracing an operation throughout the classes that implement it), and are weaved at compile-time homogeneously into all instances of a given class. If different instances of the same class are to behave differently with respect to a given aspect, the aspect has to explicitly code in which cases it is applicable. Moreover, most AOP approaches are specific to some programming language (notably Java). We are mostly concerned with higher-level abstractions (together with mappings to different technological platforms) to separate more general and fundamental aspects in order to support system evolution for agile businesses. More precisely, we want to provide modeling primitives to describe coordination and configuration aspects of a system, and to achieve technological support for reconfiguring the interactions among given computational instances in a non-intrusive way at run-time. The rationale for our research focus is as follows. Most often, the nature of changes that occur in the business are not at the level of the components that model business entities, but at the level of the business rules that regulate the interactions between the entities, and at the level of the business policies that govern the application of business rules. Therefore, we believe that successful 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, coordination, as prescribed by business rules, and configuration, as indicated by business policies. Moreover, such rules and policies change over time, in some domains (like banking, and telecommunications) quite rapidly to achieve differentiation from the competition [8]. Hence, it is important to provide modeling primitives, with precise semantics and technological support, to allow system designers and developers to easily define and implement new business rules and policies or change existing ones. Finally, different business rules may apply to different instances of the same business entity class: e.g., the rules that regulate how customers may interact with their accounts may depend on the status of the actual account (say, its balance) and not only on the account type. Furthermore, the same instance may be affected by different rules during its lifetime. Hence, it is of great importance that rules be applied on instances (and not on types) and that they be turned on or off at run-time. The next section provides more detail about the overall approach, and the remaining two sections summarize our modeling primitives for coordination and configuration. 2. SEPARATION IN THREE LAYERS The rationale for the methodology and technology that we are building is the strict separation between three aspects of any software system: the computations it performs, the coordination of those computations, and the system configuration. One of the main reasons for advocating the separation of these concerns is that it facilitates the evolution of systems, because changes that do not require different computational properties can be brought about either by reconfiguring the way components interact, or adding new connectors that regulate the way existing components operate, instead of changing the components themselves. The first two options can be achieved by superposing [11] the new coordination and configuration mechanisms on the components, while the latter has side effects on all components that use the services provided by the changed components. For this approach to evolution to be effective, both for system design and implementation, two requirements must be met. Firstly, the layering must be strict, in the sense that each layer makes use of the services of the layer(s) below. However, a layer must not be even aware there is layer above: if the components have built-in dependencies on the way they will be coordinated and configured, it will be much harder to evolve the system because it is usually very difficult to anticipate which coordination and configuration mechanisms will be needed to respond to change in the application or technological domains. Achieving this strict separation requires a very strong discipline during domain analysis. The stakeholders have to be quite clear about what is "stable" (i.e., belongs to the core business functionality) and what is "unstable" (i.e., is likely to change in the future), what behavior is purely computational in nature and what can emerge from the configuration of interactions. This is a methodological problem for which there will never be a “solution” in the sense that the quality of the evolutionary model will always depend on the expertise of the stakeholders. Nevertheless, we are building sufficient expertise in using the technology in different application domains [e.g. 12, 13], which will enable us to develop guidelines that will help to steer domain analysis towards the identification of different layers of change. The separation of coordination from computation has been advocated for a long time in the Coordination Languages [9] community, and the separation of all three concerns is central to Software Architecture, which has put forward the distinction between components, connectors and architectures [5]. The Configurable Distributed Systems community [6], in particular the Configuration Programming approach [15], also gives first-class status to configuration. However, these approaches still do not provide a satisfying way to model the three concerns in a way that supports evolution. Coordination languages do not make the configuration explicit or have a very low-level coordination mechanism (like tuple spaces); architecture description languages do not handle evolution or do it in a deficient way; configuration programming is not at the modeling level. Our main responsibility in proposing a new model is, therefore, to provide the means through which the proposed separation can be supported, both at the modeling and deployment phases. Hence, the second requirement is that the coordination and configuration aspects must be encapsulated in conceptual units with a precise semantics and implementation strategy. We have termed those units “coordination contract” [3] and “coordination context”, respectively. 3. COORDINATION In general terms, a coordination contract is a connection that can be established between a group of objects through which rules and constraints are superposed on their joint behavior, thus enforcing specific forms of interaction or adaptation to new requirements. The generic form of a coordination contract is as follows: contract class
|
| File Format | PDF HTM / HTML |
| Alternate Webpage(s) | http://www.cs.ubc.ca/~kdvolder/Workshops/OOPSLA2001/submissions/06-wermelinger.pdf |
| Alternate Webpage(s) | http://www.researchgate.net/profile/Jose_Fiadeiro/publication/228698756_Separation_of_core_concerns_Computation_coordination_and_configuration/links/09e4150b8d3acce36c000000.pdf |
| Alternate Webpage(s) | http://www-ctp.di.fct.unl.pt/~mw/pubs/2001/oopsla01asoc.pdf |
| Language | English |
| Access Restriction | Open |
| Content Type | Text |
| Resource Type | Article |
