Whenever components are assembled to perform a common task, there is always an implicit contract between them about the terms of the collaboration. In order to be able to verify the correctness of a configuration, the contracts need to be made explicit and to be compared for eventual discrepancies. This issue can be addressed by [...]
If we accept that open systems must be built in a component-oriented fashion, we must still answer the following questions: What exactly are components, and how do they differ from objects? What mechanisms must programming languages and environments provide to support component-oriented development? Where do components come from in the software development lifecycle, and how [...]
There are different ways one can structure a concurrent object-based system in order to protect objects from concurrency. A language may support constructs that favour or even enforce one particular way, or may leave it entirely to the programmer to adopt a particular model. There are three main approaches:
• The orthogonal approach: Concurrent execution is [...]
We seek to evaluate language design choices with respect to the integration of their concurrency and object-oriented features and the degree to which software reuse is supported. In particular, we wish to understand how choices of concurrency constructs interact with object-oriented techniques and affect the reusability of objects. As such, our classification scheme concentrates on [...]
Continue reading about A Design Space for Concurrent Object-Oriented Languages
In traditional environments for software development the various phases for building an application are well-defined and distinct: first one has to write a collection of modules, possibly with some inter dependencies, and with some dependencies to predefined modules stored in libraries; then one has to compile the modules, in order to generate machine code and, [...]
In the introduction, we described components in terms of their usage: a software fragment is a component if it is designed for reuse and is part of a framework. This does not tell much about the structural aspects of a component. Some global invariants seem to be valid within any composition paradigm: components typically are [...]
Continue reading about Components as Static Abstractions(OOS)
Probably the most fundamental composition mechanism to mention is functional composition. In this paradigm one entity is first encapsulated and parametrized as a functional abstraction, and is then “activated” (instantiated) by receiving arguments that are bound to its parameters. Obviously this compositional mechanism occurs in nearly every programming environment, and is by no means restricted [...]
Continue reading about Paradigms for Assembling Components(OOS)
Component-oriented software development not only requires a change of mind-set and methodology: it also requires new technological support. In this section, we will review some of the issues that arise:
• What are the paradigms and mechanisms for binding components together? What is the structure of a software component?
10 Component-Oriented Software Technology
• At which stage do [...]
Continue reading about Technical Support for Components(OOS)
Object-oriented programming languages and tools constitute an emerging software technology that addresses the development of open systems in two important ways: 1. as an organizing principle;
2. as a paradigm for reuse. In the first case, one may view an object-oriented application as a collection of collaborating objects. The fact that each object properly encapsulates both [...]
Once the programming language and associated tools support the development of components, we are still left with the question, “Where do the components come from?” Although we argue that a component-oriented approach is necessary to deal with evolving requirements, it turns out that components themselves only emerge through an iterative and evolutionary software lifecycle. This [...]
