Software architectures shift the focus of developers from lines-of-code to coarser-grained architectural elements and their overall interconnection structure. Architecture description languages (ADLs) have been proposed as modeling notations to support architecture-based development. There is, however, little consensus in the research community on what is an ADL, what aspects of an architecture should be modeled in an ADL, and which of several possible ADLs is best suited for a particular problem. Furthermore, the distinction is rarely made between ADLs on one hand and formal specification, module interconnection, simulation, and programming languages on the other. This paper attempts to provide an answer to these questions. It motivates and presents a definition and a classification framework for ADLs. The utility of the definition is demonstrated by using it to differentiate ADLs from other modeling notations. The framework is used to classify and compare several existing ADLs, enabling us in the process to identify key properties of ADLs. The comparison highlights areas where existing ADLs provide extensive support and those in which they are deficient, suggesting a research agenda for the future.

There is a real need for clear and sound design specifications of distributed systems at the architectural level. This is the level of the design which deals with the high-level organisation of computational elements and the interactions between those elements. The paper presents the Darwin notation for specifying this high-level organisation. Darwin is in essence a declarative binding language which can be used to define hierarchic compositions of interconnected components. Distribution is dealt with orthogonally to system structuring. The language supports the specification of both static structures and dynamic structures which may evolve during execution. The central abstractions managed by Darwin are components and services. Services are the means by which components interact. In addition to its use in specifying the architecture of a distributed system, Darwin has an operational semantics for the elaboration of specifications such that they may be used at runtime to di...

Architectures for software use rich abstractions and idioms to describe system components, the nature of interactions among the components, and the patterns that guide the composition of components into systems. These abstractions are higher-level than the elements usually supported by programming languages and tools. They capture packaging and interaction issues as well as computational functionality. Well-established (if informal) patterns guide architectural design of systems. We sketch a model for defining architectures and present an implementation of the basic level of that model. Our purpose is to support the abstractions used in practice by software designers. The implementation provides a testbed for experiments with a variety of system construction mechanisms. It distinguishes among different types of components and different ways these components can interact. It supports abstract interactions such as data flow and scheduling on the same footing as simple procedure...

Much of the recent work on Architecture Description Languages (ADL) has concentrated on specifying organisations of components and connectors which are static. When the ADL specification is used to drive system construction, then the structure of the resulting system in terms of its component instances and their interconnection is fixed. This paper examines ADL features which permit the description of dynamic software architectures in which the organisation of components and connectors may change during system execution. The paper outlines examples of language features which support dynamic structure. These examples are taken from Darwin, a language used to describe distributed system structure. An operational semantics for these features is presented in the n-calculus, together with a discussion of their advantages and limitations. The paper discusses some general approaches to dynamic architecture description suggested by these examples. 1

a "one-of-a-kind" process, where most software is developed from scratch, even though much of the code is similar to code written for other applications. The cost of these systems can be drastically reduced and the capability of these systems improved by providing a suitable software framework for all R&A sys~ terns, We describe a novel software framework, based on the notion of dynamically reconfigurable software for sensor-based control systems. Tools to support the implementation of this framework have been built into the Chimera 3.0 Real-Time Operating System. The framework provides for the systematic development and predictable execution of flexible R&A applications while maintaining the ability to reuse code f)om previous applications. It combines object-oriented design of software with port-automaton design of digital control systems. A control module is an instance of a class of port-based objects. A task set is formed by integrating objects from a module library to form a specific configuration. An implementation using global state variables for the automatic integration of port-based objects is presented. A control subsystem is a collection of jobs which are executed one at a time, and can be programmed by a user. Multiple control subsystems can execute in parallel, and operate either independently or cooperatively. One of the fundamental concepts of reconfigurable software design is that modules are developed independent of the target hard- ware. Our framework defines classes of reconfigurable device driver objects for proving hardware independence to IJO devices, sensors, actuators, and special purpose processors. Hardware independent real-time communication mechanisms for inter-subsystem eommurtication are also described. A/ong with providing a foundatio...

Abstract not found

Regis is a programming environment aimed at supporting the development and execution of parallel and distributed programs. It embodies a constructive approach to the development of programs based on separating program structure from communication and computation. The emphasis is on constructing programs from multiple parallel computational components which cooperate to achieve the overall goal. The environment is designed to easily accommodate multiple communication mechanisms and primitives. Both the computational and communication elements of Regis programs are programmed in the Object Oriented programming language C++. The elements are combined into parallel and distributed programs using the configuration language Darwin. The paper describes programming in Regis through a set of small example programs. Keywords parallel programming, distributed programming, inter-process communication, parallel programming language, software development environment. 1. Introduction The Regis en...

Regis is a programming environment aimed at supporting the development and execution of distributed programs. It embodies a constructive approach to the development of programs based on separating program structure from communication and computation. The emphasis is on constructing programs from multiple parallel computational components which cooperate to achieve the overall goal. The environment is designed to easily accommodate multiple communication mechanisms and primitives. Both the computational and communication elements of Regis programs are programmed in the Object Oriented programming language C++. The elements are combined into distributed programs using the configuration language Darwin. The paper describes programming in Regis through a set of small example programs drawn from the implementation of an Active Badge system. Keywords configuration programming, dynamic reconfiguration, inter-process communication, distributed programming language, software development enviro...

The architecture of a software system shows how the system is realized by a collection of components and the interactions among these components. Conventional design focuses on defining the components, but the properties of the system depend critically on the character of the interactions. Although software designers have good informal abstractions for these interactions, the abstractions are poorly supported by the available languages and tools. As a result, the choice of interaction is often defaulted or implicit rather than deliberate choice; further, interactions may be defined in terms of underlying mechanisms rather than the designers ’ natural abstractions. UniCon provides a rich selection of abstractions for the connectors that mediate interactions among components. To create systems using these connector abstractions, you need to produce and integrate not only the object code for components, but also a variety of other run-time products. To extend the set of connectors supported by UniCon, you need to identify and isolate many kinds of information in the compiler, graphical editor, and associated tools. This paper describes the role of connector abstractions in software design, the connector abstractions currently supported by UniCon, and implementation issues associated with supporting an open-ended collection of connectors.

Abstract The keyrequiwD6( for open systemsi that they be flexi55N or recomposab7 .Thi suggests that they must first of all be composable.Object-oriw2+ techniori help by allowio appli))1wD6 to be vi wed ascomposiD6+ of collaborati ( objects, but areliw2+ i supportiD other kier ofabstracti6+ that may have finer or coarsergranulari2 than objects. Acomposi676 language supports thetechni21 requi21wD67 of acomponent-orii development approach by shi62+N emphasi from programmiD andiw151+NwD6 of classes tospeci)wD657 andcomposiwD6 of components. Objects are vi wed as processes, and components areabstracti61 over the object space.Anappli(wD61 i vi wed as an expli5+ composiw62 of software components. Bymaki6 softwarearchiew15) expli51 andmani)2+wD62 we expect to better support applitw62+ evolutiN and flexi2(7( . Inthi posi267 paper wewi5 elaborate ourrequi27wD6N andoutli( a strategy for the desi6 andiw2111)wD7)N) of acomposi7)N language for the development of open systems. * In Proceedi+ of the...