Glossary: Software Architecture
The term architecture is not new and has been used for centuries to denote the physical structure of an artifact. The definition in Websters’ Dictionary – Architecture:
1: the art or science of building; specifically: the art or practice of designing and building structures and especially habitable ones.
2a: formation or construction as or as if as the result of conscious act. b: a unifying or coherent form or structure.
3: architectural product or work.
4: a method or style of building.
5: the manner in which the components of a computer or computer system are organized and integrated. The software engineering community has adopted the term to denote the gross-level structure of software-intensive systems. The importance of structure was already acknowledged early in the history of software engineering, software integration, and custom software development.
The first software programs were written for numerical calculations using programming languages that supported mathematical expressions and later algorithms and abstract data types. Programs written at that time served mainly one purpose and were relatively simple compared to the current large-scale diverse software systems. Over time due to the increasing complexity and the increasing size of the applications, the global structure of the software system became an important issue. Already in 1968, Dijkstra proposed the correct arrangement of the structure of software systems before simply programming. He introduced the notion of layered structure in operating systems, in which related programs were grouped into separate layers, communicating with groups of programs in adjacent layers. Later, Parnas maintained that the selected criteria for the decomposition of a system impact the structure of the programs and several software design principles must be followed to provide a good structure. Within the software engineering community, there is now an increasing consensus that the structure of software systems is important and several design principles must be followed to provide a good structure. In tandem with the increasing popularity of software architecture design many definitions of architecture have been introduced over the last decade, though, a consensus on a standard definition is still not established. We think that the reason why so many and various definitions on software architectures exist is because every author approaches a different perspective of the same concept of software architecture and likewise provides a definition from that perspective. Compare this to the parable of “the elephant in the dark” (as described by the mystic Rumi), in which four persons are in a dark room feeling different parts of an elephant, and all believing that what they feel is the whole beast. Notwithstanding the numerous definitions it appears that the prevailing definitions do not generally conflict with each other and commonly agree that software architecture represents the gross-level structure of the software system consisting of components and relations among them.
Looking back at the historical developments of architecture design we can conclude that similar to the many concepts in software engineering the concept of software architecture has also evolved over the years. We observe that this evolution took place at two places. First, existing stable concepts are specialized with new concepts providing a broader interpretation of the concept of software architecture. Second, existing interpretations on software architectures are abstracted and synthesized into new and improved interpretations. Let us explain this considering the development of the definitions in the last decade. The set of existing definitions is large and many other definitions have been collected in various publications. We provide only the definitions that we consider as representative.
In the following definition, software architecture represents a high-level structure of a software system. It is in alignment with the earlier concepts of software architecture as described by Dijkstra and Parnas: “The logical and physical structure of a system, forged by all the strategic and tactical design decisions applied during development” – G. Booch, Object-Oriented Design With Applications, Benjamin Cummings, 1991. The following definition explicitly considers the interpretation on the elements of software architecture. It is a specialization of the previous architecture definitions and represents the functional aspects of the architecture focusing basically on the data-flow in the system. “We distinguish three different classes of architectural elements: processing elements; data elements; and connection elements. The processing elements are those components that supply the transformation on the data elements; the data elements are those that contain the information that is used and transformed; the connecting elements (which at times may be either processing or data elements, or both) are the glue that holds the different pieces of the architecture together.” – D.E. Perry & A.L. Wolf, Foundations for the Study of Software Architecture.
A specialization of the structural issues can be found in the following definition: “As the size and complexity of software systems increase, the design and specification of overall system structure become more significant issues than the choice of algorithms and data structures of computation. Structural issues include the organization of a system as a composition of components; global control structures; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; dimensions of evolution; and selection among design alternatives. This is the software architecture level of design.” – M. Shaw & D. Garlan, Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall, 1996. The following definition extends the previous definitions by including software design information in the architectural specification: “The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time.” – D. Garlan, R. Allen & J. Ockerbloom, Architectural Mismatch: Why it’s hard to build systems out of existing parts, Proceedings 17th international Conference on Software Engineering (ICSE), 1995.” Finally the following definition abstracts from the previous definitions and implies that software architectures have more than one structure and includes the behaviour of the components as part of the architecture. “The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.” – L. Bass, P. Clements & R. Kazman, Software Architecture in Practice, Addison Wesley 1998.
The understanding on the concept of software architecture is increasing though there are still several ambiguities. Custom business software differs from BusinessSoftware in terms of software design and architecture, and the same can be said about the diferences between custom ecommerce software and InternetSoftware. Architectures consist of components and relations, but the term components may refer to subsystems, processes, software modules, hardware components or something else. Relations may refer to data flows, control flows, call-relations, part-of relations etc. To provide a consistent and overall definition on architectures, we need to provide an abstract, yet a sufficiently precise meaning of the components and relations. For this we provide the following definition of architecture: Architecture is a concept representing a set of abstractions and relations. In essence this definition considers architecture as a concept that is general yet well defined. The reason for this is that the word concept has a well-defined meaning. A concept is usually defined as a (mental) representation of a category of instances and is formed by abstracting knowledge about instances. The process of assigning new instances to a concept is called categorization or classification. In this context, concepts are also called categories or classes. There are several theories on concepts and classification addressing the notions of concepts, classes, instances and categories. Hereby it is essential to note that concepts are not just arbitrary abstractions or groupings of a set of instances but are defined by a consensus of experts in the corresponding domain. As such, concepts are stable and well-defined abstractions with rich semantics. The definition thus enforces that each architecture consists of components that do not only represent arbitrary groupings or categories but are semantically well defined. In that sense, we think that this definition is general enough to cover the various perspectives on architectures. In addition, since an architecture is a structure of concepts and each concept may represent structures themselves, the definition implies that an architecture may have different structures. In the simple case the architecture consists of a set of concepts that can be considered as ‘atomic’ and do not have an internal structure. For large software systems, however, it is necessary to define the architecture from various perspectives such as, for example, from a logical view, the process view, the development view and the physical view as defined by Kruchten. Therefore, at the highest abstraction level the software architecture may consist of concepts that each represents different architectural views.