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.

Giotto provides an abstract programmer's model for the implementation of embedded control systems with hard real-time constraints. A typical control application consists of periodic software tasks together with a mode switching logic for enabling and disabling tasks. Giotto speci es timetriggered sensor readings, task invocations, and mode switches independent of any implementation platform. Giotto can be annotated with platform constraints such as task-to-host mappings, and task and communication schedules. The annotations are directives for the Giotto compiler, but they do not alter the functionality andtiming of a Giotto program. By separating the platform-independent from the platform-dependent concerns, Giotto enables a great deal of exibility inchoosing control platforms as well as a great deal of automation in the validation and synthesis of control software. The timetriggered nature of Giotto achieves timing predictability, which makes Giotto particularly suitable for safety-critical applications.

Abstract. Software architectures shift developers ’ focus from lines-of-code to coarser-grained architectural elements and their interconnection structure. Architec-ture 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 ADL is best suited for a particular problem. Fur-thermore, 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 modcling notations. The framework is used to classify and compare several existing ADLs.’

Software architects use a number of commonly-recognized “styles” to guide their design of system structures. Each of these is appropriate for some classes of problems, but none is suitable for all problems. How, then, does a software designer choose an architecture suitable for the problem at hand? Two kinds of information are required: (1) careful discrimination among the candidate architectures and (2) design guidance on how to make appropriate choices. Here we support careful discrimination with a preliminary classification of styles. We use a two-dimensional classification strategy with control and data issues as the dominant organizing axes. We position the major styles within this space and use finer-grained discriminations to elaborate variations on the styles. This provides a framework for organizing design guidance, which we partially flesh out with rules of thumb.

Software architecture is an area of growing importance to practitioners and researchers in government, industry, and academia. Journals and international workshops are devoted to it. Working groups are formed to study it. Textbooks are emerging about it. The government is investing in the development of software architectures as core products in their own right. Industry is marketing architectural frameworks such as CORBA. Why all the interest and investment? What is software architecture, and why is it perceived as providing a solution to the inherent difficulty in designing and developing large, complex systems? This report will attempt to summarize the concept of software architecture for an intended audience of mid to senior level management. The reader is presumed to have some familiarity with common software engineering terms and concepts, but not to have a deep background in the field. This report is not intended to be overly-scholarly, nor is it intended to provide the techni...

Recent developments in Component technology enable the construction of complex software systems by assembling together off-the-shelf components. However, it is still difficult to develop efficient, reliable, and dynamically configurable component based systems. Components are often developed by different groups with different methodologies. Unspecified dependencies and behavior lead to unexpected failures. Component-based software systems must maintain explicit representations of inter-component dependence and component requirements. This provides a common ground for supporting fault-tolerance and automating dynamic configuration. In this paper, we present a generic model for reifying dependencies in distributed component systems and discuss how it can be used to support automatic configuration. We describe our experience deploying the framework in a CORBA-compliant reflective ORB and discuss the use of this model in a new distributed operating system.

Existing ADLs typically support only static architecture specification and do not provide facilities for the support of dynamically changing architectures. This paper presents a possible solution to this problem: in order to adequately support dynamic architecture changes, ADLs can leverage techniques used in dynamic programming languages. In particular, changes to ADL specifications should be interpreted. To enable interpretation, an ADL should have an architecture construction component that supports explicit and incremental specification of architectural changes, in addition to the traditional architecture description facilities. This will allow software architects to specify the changes to an architecture after it has been built. The paper expands upon the results from an ongoing project-- building a development environment for C2-style architectures. 1 I.

Giotto is a principled, tool-supported design methodology for implementing embedded control systems on platforms of possibly distributed sensors, actuators, CPUs, and networks. Giotto is based on the principle that time-triggered task invocations plus time-triggered mode switches can form the abstract essence of programming real-time control systems. Giotto consists of a programming language with a formal semantics, and a retargetable compiler and run-time library. Giotto supports the automation of control system design by strictly separating platform-independent functionality and timing concerns from platform-dependent scheduling and communication issues. The time-triggered predictability of Giotto makes it particularly suitable for safety-critical applications with hard real-time constraints. We illustrate the platform-independence and time-triggered execution of Giotto by coordinating a heterogeneous flock of Intel x86 robots and Lego Mindstorms robots.

CBSE currently lacks a universally accepted terminology. Existing component models adopt different component definitions and composition operators. We believe that for future research it would be crucial to clarify and unify the CBSE terminology, and that the starting point for this endeavour should be a study of current component models. In this paper, we take this first step and present and discuss a taxonomy of these models. The purpose of this taxonomy is to identify the similarities and differences between them with respect to commonly accepted criteria, with a view to clarification and/or potential unification. 1

Current middleware solutions such as CORBA and Java's RMI emphasize compositional design by separating functional aspects of a system (e.g. objects) i~om the mechanisms used for interaction (e.g. remote procedure call through stubs and skeletons). While this is an effective solution for handling distributed interactions, higher-level requirements such as heterogeneity, availability, and adaptability require policies for resource management as well as interaction. We describe the Distributed Connection Language (DCL): an architecture description language based on the Actor model of distributed objects. System components and the policies which govern an architecture are specified as encapsulated groups of actors. Composition operators are used to build connections between components as well as customize their behavior. This customization is realized using a metaarchitecture. We describe the syntax and semantics of DCL, and illustrate the language by way of several examples. 1