This paper presents a model for software architecture and tools to support it. The authors describe a model for defining software architectures and present an implementation of the basic level of that model. The 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 call. It can express and check appropriate compatibility restrictions and configuration constraints. It accepts existing code as components, incurring no runtime overhead after initialization. It allows easy incorporation of specifications and associated analysis tools developed elsewhere. The implementation provides a base for extending the notation and validating the model. The model addresses several issues in novel ways: it supports abstraction idioms commonly used by designers, specifies packaging properties as well as functional properties of components, provides an explicit, localized home for information about the rules for component interactions, defines an abstraction function to map from code or lower-level constructs to higher-level constructs, and is open with respect to externally-developed construction and analysis tools. The model describes software systems in terms of two kinds of distinct, identifiable elements: components and connectors. Each of the two elements has a type, a specification, and an implementation. The specification defines the units of association used in system composition; the implementation can be primitive or composite. Components are the locus of computation and state. Each component has an interface specification that defines its properties. These properties include the component's type or subtype, functionality, guarantees about global invariants, performance characteristics, and so on. The specific named entities visible in a component's interface are its players. The interface includes the signature, functionality, and interaction properties of its players. Connectors are the locus of definition for relations among components. They mediate interactions but are not "things" to be "hooked up;" rather, they provide the rules for hooking-up. Each connector has a protocol specification that defines its properties. These properties include its type or subtype, rules about the types of interfaces it works with, assurances about the interaction, commitments about the interaction such as ordering or performance, and so on. Components may be either primitive or composite. Primitive components may be implemented as code in a conventional programming language, shell scripts of the operating system, software developed in an application such as a spreadsheet, or other means external to the architectural description language. Composite components define configurations in a notation independent of conventional programming languages. The authors describe a language called UniCon for implementing the model. UniCon emphasizes the structural aspects of software architecture. It is higher-level and more general than existing mechanisms for system composition, but it is low-level compared to the model of Section 2. The objectives of this implementation were to address real problems of system description and composition, provide a prototype of a practical tool, provide uniform access to a wide range of connection mechanisms,This paper presents a model for software architecture and tools to support it. The authors describe a model for defining software architectures and present an implementation of the basic level of that model. The 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 call. It can express and check appropriate compatibility restrictions and configuration constraints. It accepts existing code as components, incurring no runtime overhead after initialization. It allows easy incorporation of specifications and associated analysis tools developed elsewhere. The implementation provides a base for extending the notation and validating the model. The model addresses several issues in novel ways: it supports abstraction idioms commonly used by designers, specifies packaging properties as well as functional properties of components, provides an explicit, localized home for information about the rules for component interactions, defines an abstraction function to map from code or lower-level constructs to higher-level constructs, and is open with respect to externally-developed construction and analysis tools. The model describes software systems in terms of two kinds of distinct, identifiable elements: components and connectors. Each of the two elements has a type, a specification, and an implementation. The specification defines the units of association used in system composition; the implementation can be primitive or composite. Components are the locus of computation and state. Each component has an interface specification that defines its properties. These properties include the component's type or subtype, functionality, guarantees about global invariants, performance characteristics, and so on. The specific named entities visible in a component's interface are its players. The interface includes the signature, functionality, and interaction properties of its players. Connectors are the locus of definition for relations among components. They mediate interactions but are not "things" to be "hooked up;" rather, they provide the rules for hooking-up. Each connector has a protocol specification that defines its properties. These properties include its type or subtype, rules about the types of interfaces it works with, assurances about the interaction, commitments about the interaction such as ordering or performance, and so on. Components may be either primitive or composite. Primitive components may be implemented as code in a conventional programming language, shell scripts of the operating system, software developed in an application such as a spreadsheet, or other means external to the architectural description language. Composite components define configurations in a notation independent of conventional programming languages. The authors describe a language called UniCon for implementing the model. UniCon emphasizes the structural aspects of software architecture. It is higher-level and more general than existing mechanisms for system composition, but it is low-level compared to the model of Section 2. The objectives of this implementation were to address real problems of system description and composition, provide a prototype of a practical tool, provide uniform access to a wide range of connection mechanisms,