Section: Research Program

Software Composition

Modules and services. The idea that building software components, i.e., composable prefabricated and parameterized software parts, was key to create an effective software industry was realized very early  [72]. At that time, the scope of a component was limited to a single procedure. In the seventies, the growing complexity of software made it necessary to consider a new level of structuring and programming and led to the notions of information hiding, modules, and module interconnection languages  [79], [55]. Information hiding promotes a black-box model of program development whereby a module implementation, basically a collection of procedures, is strongly encapsulated behind an interface. This makes it possible to guarantee logical invariant properties of the data managed by the procedures and, more generally, makes modular reasoning possible.

In the context of today's Internet-based information society, components and modules have given rise to software services whose compositions are governed by explicit orchestration or choreography specifications that support notions of global properties of a service-oriented architecture. These horizontal compositions have, however, to be frequently adapted dynamically. Dynamic adaptations, in particular in the context of software evolution processes, often conflict with a black-box composition model either because of the need for invasive modifications, for instance, in order to optimize resource utilization or modifications to the vertical compositions implementing the high-level services.

Object-Oriented Programming. Classes and objects provide another kind of software component, which makes it necessary to distinguish between component types (classes) and component instances (objects). Indeed, unlike modules, objects can be created dynamically. Although it is also possible to talk about classes in terms of interfaces and implementations, the encapsulation provided by classes is not as strong as the one provided by modules. This is because, through the use of inheritance, object-oriented languages put the emphasis on incremental programming to the detriment of modular programming. This introduces a white-box model of software development and more flexibility is traded for safety as demonstrated by the fragile base class issue  [75].

Architecture Description Languages. The advent of distributed applications made it necessary to consider more sophisticated connections between the various building blocks of a system. The software architecture  [84] of a software system describes the system as a composition of components and connectors, where the connectors capture the interaction protocols between the components  [43]. It also describes the rationale behind such a given architecture, linking the properties required from the system to its implementation. Architecture Description Languages (ADLs) are languages that support architecture-based development  [73]. A number of these languages make it possible to generate executable systems from architectural descriptions, provided implementations for the primitive components are available. However, guaranteeing that the implementation conforms to the architecture is an issue.

Protocols. Today, protocols constitute a frequently used means to precisely define, implement, and analyze contracts, notably concerning communication and security properties, between two or more hardware or software entities. They have been used to define interactions between communication layers, security properties of distributed communications, interactions between objects and components, and business processes.

Object interactions  [77], component interactions  [90], [81] and service orchestrations  [56] are most frequently expressed in terms of regular interaction protocols that enable basic properties, such as compatibility, substitutability, and deadlocks between components to be defined in terms of basic operations and closure properties of finite-state automata. Furthermore, such properties may be analyzed automatically using, e.g., model checking techniques  [53], [62].

However, the limited expressive power of regular languages has led to a number of approaches using more expressive non-regular interaction protocols that often provide distribution-specific abstractions, e.g., session types  [66], or context-free or turing-complete expressiveness  [82], [50]. While these protocol types allow conformance between components to be defined (e.g., using unbounded counters), property verification can only be performed manually or semi-automatically.