The mid-1990s saw the design of programming languages for software architectures, which define the high-level aspects of software systems including how code components were composed to form full systems. Our paperAbstractions for Software Architecture and Tools to Support Thempresented a conceptual view of software architecture based on abstractions used in practice to organize software systems, a language that supported these abstractions, and a prototype implementation of this language (Shaw et al., 1995). By invitation, we reflect on the paper’s principal ideas about system-level abstractions, place the work in a historical context of steadily increasing abstraction power in software development languages and infrastructure, and reflect on how progress since the paper’s 1995 publication has been influenced, directly or indirectly, by this work. We describe current manifestations of architectural ideas and current challenges. We suggest how the strategy we used to identify and reify architectural abstractions may apply to current opportunities.

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 the 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 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.>