Introduction to Software Architecture Concepts
By: Ismayil Shahaliyev
Tags: Computer Science, Software Architecture, Software, Stakeholder, Software Design

Software Systems Architecture is a book by Nick Rozanski and Eoin Woods. Everything that follows is the summarization of chapters 1 & 2, and for a better understanding, one should refer to the book — this article only highlights some key points and doesn’t touch the details.

The book focuses on the three fundamental concepts of software architecture:

Stakeholders Viewpoints Perspectives

Stakeholders are the people whom the systems are created for. An architect's responsibility is to effectively meet the concerns of stakeholders and balance out the arising conflicts among their requirements.

Views are the application of the principle “divide and conquer” that describe one aspect of the system’s architecture. They may include the system’s functional structure, information organization, or the deployment environment.

Choosing which view to use can often be problematic. The solution for that is to use template views, also known as, architectural viewpoints, which guide the process of developing views.

Views and viewpoints are only part of the system that defines what the system is going to do. However, it is equally important to know how the system is going to meet the requirements. For this reason, considering many non-functional factors, collectively called quality properties (or cross-cutting concerns), is crucial.

Perspectives are similar to viewpoints, but rather than addressing a type of architectural structure, they address a quality property, such as performance or availability.

What is Computer System

Software + Hardware

What is Architecture

ISO definition:

(system) fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.

Let’s extract the three key concepts from the definition:

elements and relationships

fundamental properties

principles of design and evolution

Elements and Relationships

Elements are fundamental pieces of a system (e.g. modules, partitions, subsystems, etc). They define the structure of the system. Two types of structures interest software architectures:

Static structure Dynamic structure

Static structure is the organization of internal design-time elements and their arrangement, i.e. what are the elements and how they interact with each other. Design-time software elements are programs, object-oriented classes, services, etc. Internal data elements are classes, relational database tables, and data files. Internal hardware elements are computers and their constituent parts. Their static arrangement defines how they associate and connect with each other (hierarchy of elements, how one data or hardware is linked to another, etc).

Dynamic structure is the organization of runtime elements. It shows how a system works and how it responds to internal and external stimuli. These interactions could be flows of information between elements or the way how tasks are executed (parallelly or sequentially), etc.

Fundamental Properties of a System

That is, 1) what system does 2) how system does it. Or to put it differently:

Externally visible behavior Quality properties

Externally visible behavior treats systems as black boxes (i.e. making this request returns this response). It is the combined functional behavior of the system’s internal elements.

Quality properties deal with non-functional properties, such as performance, security, or scalability. It is the quality properties of the system’s internal elements.

Design and Evolution Principles

Defining and following clear-cut architectural principles that guide to achieve consistency and evolution of the system is very important. They are going to be powerful heuristics, leading to quick and effective solutions to the arising problems.

System Properties & Internal Organization

Architects can deal with different circumstances in different ways. For example, they can choose between two-tier and three-tier architectures, that is, between candidate architectures in a specific scenario.

In the first case, the static structure would consist of the client programs (presentation, database, network layers, etc), server, and connection between them. The dynamic structure would be based on a request/response model.

In the second case, the static structure would consist of the client programs, application server, database server, and the connections in between. The dynamic structure will be based on the three-tier request/response model.

An architect can choose any of the candidate architectural approaches based on the match between the possible system properties and the system requirements. Candidate architectures will surely be similar in many general features, however, they will differ in a specific set of quality properties (e.g. one will be easier to maintain and the other is going to be cheaper).

Architectural Elements

An architectural element (component, module) should clearly define three key concepts:

Set of responsibilities Boundary Set of interfaces

Set of interfaces define the services that the element provides to other elements.

Stakeholders

A software system is not only limited to users. It needs to be built, tested, maintained, repaired, paid for, etc. These people, who have different degrees of interests, concerns, and expectations, collectively constitute the notion of stakeholders. A stakeholder could be an individual, team, or organization.

Often, an architect should select a representative for each stakeholder who will speak for the group. Without stakeholders, building architectures would make no sense. If a system does not meet the needs of its stakeholders then the system cannot be considered as being successful.

For sure, different stakeholders may have contradictory expectations. That always leads to a difficult dilemma that an architect should deal with. Therefore, an effective balance among the needs of stakeholders constitutes the essence of a good architecture.

Architectural Descriptions

Architectural description (AD) is simply a documentation of an architecture that demonstrates to stakeholders how their concerns are met. It summarizes the overall architecture of the whole system in a simple and clear manner.

An AD that is unclear or doesn’t demonstrate how the expectations of stakeholders are met is not worth existing. AD should contain all (or better only) the information needed to effectively communicate the architecture to the stakeholders.

Connecting Core Concepts

For the UML diagram, please refer to the figure 2–5 in the aforementioned book.