The building blocks of a robust software architecture

Architecture is a term that is popularly used in the construction world and it’s a means of ensuring that there are no failures in structural engineering and construction management, which is one of the reasons why software engineering has also adopted the practice of architecting software systems. In this context, software architectures have proven to be extremely useful in the design and implementation of software systems. Besides technical tasks, software architectures can assist stakeholders in driving project management tasks such as the assignment of human resources to the implementation of different modules of a complex system.

Understanding Software Architectures

Despite the wide use of architectures in software engineering, there is no widely accepted definition yet. Nevertheless, most software engineers agree that it is a tool for capturing and preserving the designers’ perspectives about the structure and behavior of a software system. In practice, software architectures are used in order to streamline the complexity of sophisticated software systems, through modularizing them and defining the interfaces and interactions between the different modules. Typically, a software architecture comprises of the following attributes:

• Software elements such as databases, data stores, functions, modules, libraries, subsystems, objects and more. A software architecture defines the main software elements of the system.
• The externally visible properties of the software system i.e. what a system looks like in terms of the services it provides, performance characteristics, fault handling mechanism and resilience issues, as well as the resource sharing mechanisms.
• The relationships between the various software elements, including the structuring principles that drive their integration in the complex software system. These relationships include connectivity, interaction and communication aspects, as reflected in procedure calls, inter-object communication, event-based invocations and more.

Another way to view an architecture is as an abstraction of a system, which excludes low-level implementation details (e.g., internal elements).  This abstraction conveys the structure of the software system, which can be used to drive several software engineering activities such as implementation (e.g., dividing tasks based on the modules of a system’s architecture) and deployment (e.g., deploying the various elements of the systems independently).

Software Architecture in the Development Lifecycle

An architecture influences the system design, yet it is much different from the detailed design of a system. In particular, the design of a system architecture deals with decisions that have systemic impact on the software product (e.g., they impact their overall scalability and resilience), while the detailed design of the system deals with decisions that have local impact (e.g., which algorithm will be used to implement a functional unit of the system). For instance, a detailed design describes which software elements will be invoked when a user presses a button in a software application, as well as how they will interact with each other. On the other hand, a system architecture design should describe what will happen in cases where several millions of users will press this button at the same time. It should indicate how the system will be able to handle so many users in a scalable and resilient fashion. Overall, architecture design decisions concern system-wide decisions, while narrowly-scoped decisions are not likely to be architectural.

In most cases, software architecture design activities lie between the requirements and design phases of the software engineering lifecycle. Specifically, architecture design activities include the selection of architecture elements, the specification of the interactions between them, the specification of constraints about the operation of the elements and their interactions, and more. The resulting architecture should satisfy the system’s requirements while serving as a basis for the activities of the design phase. Likewise, the design phase deals with the modularization of the system and the detailed specification of the interfaces between the design elements. The resulting design should be aligned with the architecture while satisfying the requirements as well. Finally, the system coding and implementation phase should produce data types and algorithms that satisfy the design, the requirements, and the architecture at the same time. Hence, the development of a software architecture impacts all phases of the software engineering lifecycle. Note also that all software engineering methodologies (including both waterfall and agile methodologies) include tasks where a software architecture is developed to drive design and implementation activities.

Views of a Software Architecture

An architecture is in general too complicated to be depicted based on a single view. Hence, software architectures tend to have many structures or views i.e. a software architecture is documented on the basis of multiple views. Different views might be relevant for different stakeholders and their roles in the system development process.

There are several approaches to view-based software architecture description and documentation. As a prominent example, the 4+1 View Model uses 4 complementary views to describe an architecture, while validating them against a set of reference scenarios about the operation of the target software system. In particular, the views of the 4+1 model, include:

• The Logical View, which describes the most important elements of the system (e.g., classes, packages, subsystems), their structuring principles and the relationships between them. A logical view identifies the major logical components of the system and the way they are organized (e.g., layered approach, publish-subscribe, and event-based schemes).
• The Process View, which describes the processes of the system, as well as how the elements of the architecture (e.g., threads, processes, replicated components) communicate and interact. Process views illustrate both functional and non-functional aspects of the system while addressing performance, response time, scalability and availability aspects. Process views can be documented using UML Activity diagrams.
• The Development View, which describes how internal artifacts (e.g., source code, scripts, data files, executables/binaries, libraries, packages) are used to produce software modules. In several cases, this view provides insights about the actual placement of the files in the system and the development environment. Development views can be represented using UML Package diagrams.
• The Physical View, which describes how the application is installed and how it executes in a network of nodes (such as hardware devices). It also provides the distribution of software components (e.g., processes, objects, components, subsystems) across different hardware platforms and nodes (e.g., database servers, application servers, web servers). It is also concerned with non-functional requirements such as performance, availability, and reliability. A Physical View can be represented based on UML Deployment diagrams.
• Main Use Cases (+1), which are used to test and validate the architecture. In particular, use cases are used to ensure that the designed architecture elements are appropriate for supporting the use cases at hand. As part of this process, it explains how design elements in the architecture can be used to provide the required behavior as part of the use case. For the representation of the Use Cases, UML Use Case diagrams could be used.

Other models comprise analogous views. For example, the Views & Beyond Model of the Software Engineering Institute (SEI) presents an architecture based on three major view types, namely:

• Module view type, which documents a system’s principal units of implementation and acts like a logical view.
• Component-and-connector view type, which documents the system’s units of execution, the principal units of computation and the communication among them, much like a process view.
• Allocation view type, which documents the relationship between a system’s software units and its development and execution environment, in a way similar to the development and physical views in the 4+1 case.

Overall, proper software architecture design is a key ingredient to the successful development and delivery of a complex software system. This is what makes the role of a system architect one of the most important in a software team. Software system architects need to have a broader understanding of the system, including knowledge of network, hosting and performance aspects, besides a very good understanding of software solutions. At the same time, software engineers should be proficient in understanding and interpreting the UML diagrams that reflect the various views of a system’s architecture. This knowledge will help the teams complete the development tasks faster and would ensure that there is compatibility among the various modules developed by the different teams.