A formal model for module interconnection languages

1998

Interoperability is the ability of two or more software modules to communicate and cooperate with each other. The interoperability problem arises when software developers want to reuse legacy software systems, or when software systems are componentized and these components need to be connected in order to work together. The problem occurs in both heterogeneous (multi-lingual) and homogeneous environments. Software modules can be functions, objects, or components which consist of multiple functions or objects. In this paper we focus on the speci cation of software components in object oriented systems.

A simple implementation of a SML-like module system is presented as a module parameterized by a base language and its type-checker. This demonstrates constructively the applicability of that module system to a wide range of programming languages. Full source code available in the Web appendix \url{http://gallium.inria.fr/~xleroy/publi/modular-modules-appendix/

Lecture Notes in Computer Science, 1998

ACM SIGSOFT Software Engineering Notes, 1995

The necessity to deal simultaneously with different formalisms seems to be intrinsic to the discipline of Software Engineering, particularly in relation to modularity, reusability and incrementality. In order to accommodate this diversity of formalisms, some authors have proposed the adoption of a common semantic do main for the different specification languages, and their transla tion into a common style of predicate logic. In this paper, we sug gest that an alternative approach may be taken where the different modelling approaches are formalised individually in a common mathematical framework -Category Theory, and relationships are established between them using functors. Several examples are adduced to support this view and the generality of the approach is illustrated by formalising reusability as a property of a functor relating two such formalisms.

Electronic Notes in Theoretical Computer Science, 2015

The specification of a concurrent program module is a difficult problem. The specifications must be strong enough to enable reasoning about the intended clients without reference to the underlying module implementation. We survey a range of verification techniques for specifying concurrent modules, in particular highlighting four key concepts: auxiliary state, interference abstraction, resource ownership and atomicity. We show how these concepts combine to provide powerful approaches to specifying concurrent modules.

Mathematical Structures in Computer Science, 2007

We present a simple module calculus where selection and execution of a component is possible on open modules, that is, modules which still have to import some definitions from the outside. Hence, it provides a kernel model for a computational paradigm in which standard execution (that is, execution of a single computation described by a fragment of code) can be interleaved with operations at the meta-level which can manipulate in various ways the context in which this computation takes place. Formally, this is achieved by introducing as basic terms configurations, which are, roughly speaking, pairs consisting of an (open, mutually recursive) collection of named components and a term representing a program running in the context of these components. Configurations can be manipulated by classical module/fragment operators, hence reduction steps can be either execution steps of the program or steps which perform module operators (called reconfiguration steps). Since configurations combine the features of lambda abstractions (first-class functions), records, environments with mutually recursive definitions, and modules, the calculus extends and integrates both traditional module calculi and recursive lambda calculi. We state confluence of the calculus, and propose different ways to prevent errors due to lack of some needed component, either by a purely static type system or by a combination of static and run-time checks. Moreover, we define a call-by-need strategy which performs module simplification only when needed and only once, leading to a generalization, including module features, of call-by-need lambda calculi. We prove soundness and completeness of this strategy using an approach based on information content which also allows to preserve confluence even in case local substitution rules are added to the calculus. providing foundations for manipulation and combination of software components. These calculi allow to express a large variety of existing mechanisms by a small set of operators, hence can be used as a paradigmatic example for studying modular languages, in the same spirit the lambda calculus is used for functional programming. For instance, in CMS modules are constructed from basic modules, which have the shape [ι; o; ρ] where ι, o and ρ model input, output and local components, respectively, by only three primitive operators: sum (merging two modules), freeze (binding an input to an output component) and reduct (independently renaming input and output components). operators allow to express, e.g., parameterized modules similar to ML functors, extension with overriding as in object-oriented programming, and mixin modules.

Balancing between the desire for information-hiding and the risk of introducing undesired hidden dependencies is often not straightforward. Hiding important parts of the internal functionality of a module is known as the black box principle, and is associated with the property of reusability and consequently evolvability. An interface, which is roughly explaining the core functionality of a module, helps indeed the developer to use the functionality without being forced to concentrate on the implementation details. However, some implementation details should not be hidden if they hinder the use of the module when the environment changes. These kind of implementation details can be called undesired hidden dependencies. An interesting question then becomes, which information should be hidden and which not? In this paper, we use the Normalized Systems theorems as a base to evaluate which details should be hidden versus transparent in order to improve reusability. In other words, which ...

Advanced Concurrent Engineering, 2008

2003

2013

Achieving the property of evolvability is considered a major challenge of the current generation of large, compact, powerful, and complex systems. An important facilitator to attain evolvability is the concept of modularity: the decomposition of a system into a set of collaborating subsystems. As such, the implementation details of the functionality in a module is hidden, and reduces complexity from the point of view of the user. However, some information should not be hidden if they hinder the (re)use of the module when the environment changes. More concretely, all collaborating modules must be available for each other. The way how a collaborating module is accessible is also called module coupling. In this paper, we examined a list of classifications of types of module couplings. In addition, we made a study on the implications of the used address space for both data and functional constructs, and the implications of how data is passed between modules in a local or remote address ...