Foundations for the study of software architecture

Abstract

The purpose of this paper is to build the foundation for software architecture. We first develop an intuition for software architecture by appealing to several wellestablished architectural disciplines. On the basis of this intuition, we present a model of software architecture that consists of three components: elements, form, and rationale. Elements are either processing, data, or connecting elements. Form is defined in terms of the properties of, and the relationships among, the elements --that is, the constraints on the elements. The rationale provides the underlying basis for the architecture in terms of the system constraints, which most often derive from the system :requirements. We discuss the components of the model in the context of both architectures and architectural styles and present an extended example to illustrate some important architecture and style considerations. We conclude by presenting some of the benefits of our approach to software architecture, summarizing our contributions, and relating our approach to other current work.

Global Software Engineering: The Future of Socio-technical Coordination

“…As with most types of complex systems, software is generally designed as sets of interacting components [58,63]. Software architectures not only influence quality attributes of software, but they are also an important means of coordinating software projects.…”

Software Engineering Education in the Era of Outsourcing, Distributed Development, and Open Source Software: Challenges and Opportunities

“…Further, the increasing commoditization and distribution of hands-on software development via outsourcing and the use of thirdparty components is causing the demand for traditional software development skills in many areas to be eclipsed by new opportunities available to software engineers who possess certain kinds of enhanced software engineering expertise. To enable engineers to take advantage of these opportunities, we need to augment traditional software engineering strengths in software architecture [3], design, and development processes with new techniques that will enable software engineers to apply engineering principles in larger organizational and project management contexts. We need to produce software engineers who are just as comfortable practicing engineering in environments where the "tools" are distributed project teams and third-party components as they are designing and implementing complete systems themselves.…”

Three levels of the symbolosphere

“…Perry and Wolf (1992) distinguish between processing elements, data elements, and connecting elements, and this taxonomy by and large persists through most other definitions and approaches.…”