Mathematical Frameworks for Component Software

The following sections are included:

• Preface

• Contents

In this chapter, we present a formal characterisation of component based systems with support for polymorphic dynamic reconfiguration. By dynamic reconfiguration we mean, as usual, changes in the system architecture at run time. By polymorphic reconfiguration we mean that reconfiguration operations may concern different types of components or connections, exploiting an inheritance relationship over components, as in object orientation.

The formal characterisation of component based systems is based on a first-order temporal logic. The logic is a variant of the Manna-Pnueli logic, expressive enough for straightforward specification of component types, connector types and dynamic amalgamations of components. On top of this logic, and in the form of a (rather low level) specification language, we build the necessary machinery for specifying components, connectors and amalgamations, together with inheritance and polymorphism.

Virtually all contemporary component models use object oriented method invocation as the foundation of their component composition semantics. However, two objects composed by method invocation do not yield a new object. This produces component models that are not closed under component composition; require complex composition operators; or, often, suffer from both of these deficiencies. Such object oriented component models are based on Abstract Data Types (ADT).

In contrast, a simpler model of components and their composition exists that uses the notion of Abstract Behavior Types (ABT) as its foundation [3]. The ABT model supports a much looser coupling than is possible with the ADT model, and is inherently amenable to exogenous coordination. We have argued that both of these are highly desirable, if not essential, properties for models of components and their composition. Furthermore, the composition of two ABTs always yields another ABT, which in this model makes components closed under composition.

In this chapter, we describe two concrete formalizations of the notion of Abstract Behavior Types as (1) constraint automata, and (2) relations on timed-data streams. To demonstrate the utility of the ABT model, we describe Reo: an exogenous coordination language for compositional construction of component connectors based on a calculus of channels. We show the expressive power of Reo, and the applicability of the ABT model, through a number of examples.

In this chapter we present a coalgebraic semantics for components. Our semantics forms the basis for a family of operators for combining components. These operators together with their algebraic laws establish a calculus for software components. We present two applications of our semantics: a coalgebraic interpretation of UML diagrams and the design of a component repository.

We extend the Focus model [2] and its interface theory of distributed concurrent interactive systems and their structuring into components. Our goal is the scientific foundation for two methodologically essential, complementary and orthogonal concepts for the structuring of multi-functional systems in software and systems engineering. One addresses essentially requirements engineering and the specification of the comprehensive user functionality of multi-functional systems in terms of their functions, features and services. The other addresses mostly the design phase with its task to develop logical architectures formed by networks of interactive components that are specified by their interface behavior. The first concept is of major interest for the requirements engineer, the second for the software architect. We show that these concepts are complimentary, how they work and fit together as milestones in requirements engineering and systems architecture design.

In this chapter we introduce a formal model of components which extends object-orientation with additional structuring and abstraction mechanisms to support a modelling discipline based on interfaces. The component model formalizes the concepts of interfaces, roles, connectors, and ports. Components encapsulate their internal class structure and interact only through a certain kind of objects which are called ports. Ports are instances of classes which are represented by roles. Roles export information about the required and provided operations of these classes by means of interfaces. By means of connectors which wire roles of different components together, ports of one component can dynamically create ports of another component.

As an example, we show how to model mobile channels for the dynamic reconfiguration and exogenous coordination of components.

Despite the advances in software engineering since 1968, current methods for going from a set of functional requirements to a design are not as direct, formal, repeat-able and constructive as we would like. Progress with this fundamental problem is possible once we recognize that individual functional requirements represent fragments of behavior, while a design that satisfies a set of functional requirements represents integrated behavior. This perspective admits the prospect of constructing a design out of its requirements. A formal representation for individual functional requirements, called behavior trees makes this possible. Behavior trees of individual functional requirements may be composed, one at a time, to create an integrated design behavior tree. From this problem domain representation it is then possible to transition directly, systematically, and repeatably to a solution domain representation of the component architecture of the system and the behavior designs of the individual components that make up the system: both are emergent properties of the integrated design behavior tree.

We present a model for components, their composition and refinement to be used in component-based software development. We describe how components are specified for its syntactical view at the interface level, functional view at the requirement level, internal view at the design level and how they are composed. In a component based system development, a component consists of a set of interfaces, provided to or required from the software being developed.

In a component development, the component is an executable code that can be coupled with other components via its interfaces. The developer has to ensure that the specification of a component is satisfied by its design and the design is met by its implementation.

This work is an extended and revised version of [25].

In the component-based approach Catalysis, a framework is a reusable artefact that can be adapted and composed into larger systems. The signed contract between components specifies how the required properties of one component are satisfied by the provided properties of another. We examine this concept in the context of framework-based development. Although Catalysis advocates rigorous development, frameworks lack a comprehensive formal foundation. We consider a simplified view of frameworks and their transformation into first-order logic. Theorem proving may be used to check the consistency of framework specifications and we identify ways in which these specifications may be simplified beforehand to reduce the burden of proof.

We present a unifying conceptual framework for components, component interfaces, contracts and composition of components by focusing on the collection of properties or qualities that they must share. A specific property, such as signature, functionality, behavior or timing is an aspect. Each aspect may be specified in a formal language convenient for its purpose and, in principle, unrelated to languages for other aspects. Each aspect forms its own semantic domain, although a semantic domain may be parameterized by values derived from other aspects.

The notion of aspects is illustrated in terms of the currently most adapted terminology, we consider a contract as a collection of selected aspects compatible with some component. Keeping aspects separate opens up an opportunity to combine semantic models.

The proposed conceptual framework is introduced by small examples, using UML as concrete syntax for various aspects, and is illustrated by one larger case study based on an industrial prototype of a complex component based system.

Modern business systems need to cater to rapidly evolving business requirements in an ever-shrinking window of opportunity while keeping pace with advances in technology. Current industry practice for developing large and complex applications is expensive and error prone as it relies heavily on manual verification. Model-driven development approach addresses this problem by providing a set of modeling notations like UML for specifying the different aspects of a system and a set of code generators for transforming these models into code. These modeling notations can be used to specify an application as a set of interacting components that can be adapted along the dimensions of change. Typically, business applications vary along the dimensions of domain functionality, business process, architecture, design strategies and technology platforms. We present a methodology, emerging from and aimed at guiding the engineering practice, that uses aspect-orientation and model-driven development techniques for specifying different views of interest of a system as models and transforming them in successive stages of refinement with specific aspects of interest being imparted at each stage. We discuss how this approach was used to restructure a model driven development environment resulting in greater reuse and ease of its evolution.

Present-day software systems are in increasing need of modification and evolution due to changing requirements. Component-based development constitutes a key methodology for creating large-scale, evolvable systems in a timely fashion as it advocates the (re)use of prefabricated replaceable software components. However, it is often the case that undesirable or unpredictable behaviour emerges when components are combined. This is partly due to lack of behavioural information about the individual components. In this paper, we describe a formal model for component specification which can be used to support the analysis and predictability of component composition and to identify undesirable behaviour. In our approach, component behaviour is modelled by so-called behavioural presentations, a powerful model of true-concurrency. Moreover, the framework is compositional and supports the assembly of the final system from arbitrary components.

The following sections are included:

• Subject Index