5,921 research outputs found
Interacting Components
SystemCSP is a graphical modeling language based on both CSP and concepts of component-based software development. The component framework of SystemCSP enables specification of both interaction scenarios and relative execution ordering among components. Specification and implementation of interaction among participating components is formalized via the notion of interaction contract. The used approach enables incremental design of execution diagrams by adding restrictions in different interaction diagrams throughout the process of system design. In this way all different diagrams are related into a single formally verifiable system. The concept of reusable formally verifiable interaction contracts is illustrated by designing set of design patterns for typical fault tolerance interaction scenarios
Specifying Reusable Components
Reusable software components need expressive specifications. This paper
outlines a rigorous foundation to model-based contracts, a method to equip
classes with strong contracts that support accurate design, implementation, and
formal verification of reusable components. Model-based contracts
conservatively extend the classic Design by Contract with a notion of model,
which underpins the precise definitions of such concepts as abstract
equivalence and specification completeness. Experiments applying model-based
contracts to libraries of data structures suggest that the method enables
accurate specification of practical software
Pattern Reification as the Basis for Description-Driven Systems
One of the main factors driving object-oriented software development for
information systems is the requirement for systems to be tolerant to change. To
address this issue in designing systems, this paper proposes a pattern-based,
object-oriented, description-driven system (DDS) architecture as an extension
to the standard UML four-layer meta-model. A DDS architecture is proposed in
which aspects of both static and dynamic systems behavior can be captured via
descriptive models and meta-models. The proposed architecture embodies four
main elements - firstly, the adoption of a multi-layered meta-modeling
architecture and reflective meta-level architecture, secondly the
identification of four data modeling relationships that can be made explicit
such that they can be modified dynamically, thirdly the identification of five
design patterns which have emerged from practice and have proved essential in
providing reusable building blocks for data management, and fourthly the
encoding of the structural properties of the five design patterns by means of
one fundamental pattern, the Graph pattern. A practical example of this
philosophy, the CRISTAL project, is used to demonstrate the use of
description-driven data objects to handle system evolution.Comment: 20 pages, 10 figure
Semantic Component Composition
Building complex software systems necessitates the use of component-based
architectures. In theory, of the set of components needed for a design, only
some small portion of them are "custom"; the rest are reused or refactored
existing pieces of software. Unfortunately, this is an idealized situation.
Just because two components should work together does not mean that they will
work together.
The "glue" that holds components together is not just technology. The
contracts that bind complex systems together implicitly define more than their
explicit type. These "conceptual contracts" describe essential aspects of
extra-system semantics: e.g., object models, type systems, data representation,
interface action semantics, legal and contractual obligations, and more.
Designers and developers spend inordinate amounts of time technologically
duct-taping systems to fulfill these conceptual contracts because system-wide
semantics have not been rigorously characterized or codified. This paper
describes a formal characterization of the problem and discusses an initial
implementation of the resulting theoretical system.Comment: 9 pages, submitted to GCSE/SAIG '0
Abstracting object interactions using composition filters
It is generally claimed that object-based models are very suitable for building distributed system architectures since object interactions follow the client-server model. To cope with the complexity of today's distributed systems, however, we think that high-level linguistic mechanisms are needed to effectively structure, abstract and reuse object interactions. For example, the conventional object-oriented model does not provide high-level language mechanisms to model layered system architectures. Moreover, we consider the message passing model of the conventional object-oriented model as being too low-level because it can only specify object interactions that involve two partner objects at a time and its semantics cannot be extended easily. This paper introduces Abstract Communication Types (ACTs), which are objects that abstract interactions among objects. ACTs make it easier to model layered communication architectures, to enforce the invariant behavior among objects, to reduce the complexity of programs by hiding the interaction details in separate modules and to improve reusability through the application of object-oriented principles to ACT classes. We illustrate the concept of ACTs using the composition filters model
Coordination Contracts as Connectors in Component-Based Development
Several proposals for component-based development
methods have started to appear. However, the emphasis is
still very much on the development of components as
opposed to the development with components. The main
focus is on how to generate ideal reusable components not
on how to plug existing components and specify their
interactions and connections.
The concept of a coordination contract (Andrade and
Fiadeiro 1999; Andrade and Fiadeiro 2001; Andrade,
Fiadeiro et al. 2001) has been proposed to specify a
mechanism of interaction between objects based on the
separation between structure, what is stable, and
interaction, what is changeable. This separation supports
better any change of requirements, as contracts can be
replaced, added or removed dynamically, i.e. in run-time,
without having to interfere with the components that they
coordinate. A coordination contract corresponds to an
expressive architectural connector that can be used to plug
existing components.
In this paper we integrate the concept of a coordination
contract with component-based development and show
how coordination contracts can be used to specify the
connectors between components
Unifying Requirements and Code: an Example
Requirements and code, in conventional software engineering wisdom, belong to
entirely different worlds. Is it possible to unify these two worlds? A unified
framework could help make software easier to change and reuse. To explore the
feasibility of such an approach, the case study reported here takes a classic
example from the requirements engineering literature and describes it using a
programming language framework to express both domain and machine properties.
The paper describes the solution, discusses its benefits and limitations, and
assesses its scalability.Comment: 13 pages; 7 figures; to appear in Ershov Informatics Conference, PSI,
Kazan, Russia (LNCS), 201
- …