Software Architecture

Docente: Alejandro Rodas Vásquez

24 de septiembre de 2020

1. Software Architecture in Practice: A Comprehensi-

ve Framework and Guide for Practitioners - Oliver
Vogel, Ingo Arnold, Arif Chughtai & Timo Kehrer
1.1. Architectural Patterns and Style
An architectural pattern in software, also known as an architectural style, is
analogous to an architectural style in buildings, such as Gothic or Greek Revival or Queen
Anne. It consists of a few key features and rules for combining them so that architectural
integrity is preserved. An architectural pattern is determined by:

A set of element types (such as a data repository or a component that computes a

mathematical function).

A topological layout of the elements indicating their interrelation-ships.

A set of semantic constraints (e.g., filters in a pipe-and-filter style are pure data trans-
ducers—they incrementally transform their input stream into an output stream, but
do not control either upstream or downstream elements).

A set of interaction mechanisms (e.g., subroutine call, event-subscriber, blackboard)

that determine how the elements

coordinate through the allowed topology

Mary Shaw and David Garlan’s influential work attempted to catalog a set of archi-
tectural patterns that they called architecturalstyles or idioms. This has been evolved by the
software engineering community into what is now more commonly known as architectural
patterns, analogous to design patterns and code patterns.

The motivation of [Shaw 96] for embarking on this project was the observation that
high-level abstractions for complex systems exist but we do not study or catalog them, as is
common in other engineering disciplines.

1
 These patterns occur not only regularly in system designs but in ways that sometimes
prevent us from recognizing them, because in different disciplines the same architectural
pattern may be called different things. In response, a number of recurring architectural
patterns, their properties, and their benefits have been cataloged

2. Software Architecture and Design Illuminated - Kai

Qian
2.1. Architecture Styles
An architecture style (also known as an “architecture pattern”) abstracts the common
properties of a family of similar designs. An architecture style contains a set of rules, cons-
traints, and patterns of how to structure a system into a set of elements and connectors. It
governs the overall structure design pattern of constituent element types and their runtime
interaction of flow control and data transfer. The key components of an architecture style
are:

elements that perform functions required by a system

connectors that enable communication, coordination, and cooperation among elements

constraints that define how elements can be integrated to form the system

attributes that describe the advantages and disadvantages of the chosen structure

For example, in the data-centric style, the data store plays a central role and it is ac-
cessed frequently by other elements that modify data. In the dataflow style, input data is
transformed by a series of computational or manipulative elements. In the call-and-return
style, functions and procedures are the elements organized in a control hierarchy with a main
program invoking several subprograms. In the object-oriented style, elements are represented
as objects that encapsulate data and operations, and the communication among them is by
message passing. In the layered style, each module or package completes tasks that progress
in a framework from higher-level abstractions to lower-level implementations. All of these
styles will be discussed in detail in later chapters.

For now, let us take a look at the multi-tier architecture style in detail. Multi-tier archi-
tecture is commonly used for distributed systems. It usually consists of three element types:
client, middleware server, and data server.

Each element type serves a distinct function. The client element is responsible for GUI
interface presentation, accepting user requests, and rendering results. The middleware ele-
ment gets the requests from the client element, processes the requests based on the business
logic, and sends a data request to the back-end tier. The data store server element manages
data querying and updating. All three types of elements are connected via a network (e.g.,
the Internet). Many enterprise software architectures are of the multi-tier style because they

2
share the same set of constraints.

Why are architecture styles so important? Because each style has a set of quality
attributes that it promotes. By identifying the styles that a software architecture
design supports, we can verify whether the architecture is consistent with the
requirement specifications, and identify which tactics we can use to better implement
the architecture.

Theoretically, an architecture style is a viewpoint abstraction for a software structure

that is domain-independent.

In most cases, a software system has its own application domain such as image proces-
sing, motor control, Web portal, expert system, or mail server. Each domain may have its
own reference model. For instance, the Model-View-Controller (MVC) is widely adopted by
designers of interactive systems. Such a reference model partitions the functionalities of a
system into subsystems or software components.

In many cases, a system can adopt heterogeneous architectures, i.e., more than one
architecture style can coexist in the same design. It is also true that an architecture
style maybe applied to many application domains.

3. Software Architecture and Design Illuminated - Oli-

ver Vogel, Ingo Arnold, Arif Chughtai & Timo Keh-
rer
3.1. Architecture Styles
In this section we will discuss architecture styles. Shaw and Garlan [Shaw and Garlan
1996] define an architecture style as a pattern of the structural organization of a family of
systems. For them, an architecture style consists of the following elements:

A set of building blocks that fulfill specific functions at runtime

A topological arrangement of these building blocks
A set of connectors that regulate the communication and coordination between the
building blocks
A set of semantic restrictions that determine how building blocks and connectors can
be connected to one another

Note that both the building blocks and the connectors of a style are mostly realized as
independent building blocks of an architecture or a system.

3
 An architecture style primarily reflects the fundamental structure of a software system
and its properties. You can therefore use a style to categorize architectures. Furthermore,
you can use styles to understand the consequences of a fundamental architecture and its
variants.

3.2. Architecture styles vs architecture patterns

It is very difficult to differentiate between architecture styles and architecture patterns—with
the exception that they have different forms of description. The form of description for pat-
terns covers many aspects that do not appear in the form of description for styles, such as
the reasons for a design decision. Patterns are used not only in architecture but also in other
areas, whereas styles are used only in this area.

Many of the architecture styles documented by Shaw and Garlan have also been docu-
mented in the form of architecture patterns. For this reason, and because the concept of
architecture styles is very similar to the concept of patterns, in the field of architecture you
can use the terms “styles” and “patterns” synonymously.

Shaw and Garlan have cataloged some frequently used architecture styles. These are
summarized and divided into categories (Figura 1)

Figura 1: Overview of architecture style

4
3.3. Architecture Patterns
Architecture patterns in software engineering
Over the last years, patterns have become an important instrument for software develo-
pers and architects, particularly in the area of object orientation. In particular, the Gang
of Four book (GoF) [Gamma et al. 1995], which is concerned with design patterns, and the
POSA books [Buschmann et al. 1996; Schmidt et al. 2000], which deal with software ar-
chitecture patterns, have made important contributions here. However, patterns also occur
in many other areas of software development: for example, patterns for the analysis of do-
mains [Fowler 1996], patterns for domain-driven design [Evans 2004], patterns for software
organization [Coplien and Harrison 2004], or pedagogical patterns [Fricke and Völter 2000].

Definition: Pattern according to Alexander

The original pattern definition by Christopher Alexander—who originally introduced the
pattern concept in classic architecture—states [Alexander 1977]:

A pattern is a three-part rule which expresses the relationship between a certain con-
text, a problem, and a solution.

Definition: Pattern according to Coplien

However, Alexander goes beyond this simple definition in many points. We will address
these points in the next paragraphs. The somewhat longer definition by Coplien [Coplien
2004] offers a plausible summary of these points related to a software system:

Each pattern is a three-part rule that expresses the relationship between a certain
context, a certain system of forces which occurs repeatedly in that context, and a
certain software configuration which allows these forces to resolve themselves.

Recurring problems and solutions

One very important point is that patterns are, in principle, solutions for recurring pro-
blems. This means that they have to be formulated so generally that a pattern can be applied
not only for a specific problem but for a series of concrete problems. On the other hand,
patterns are also a practical approach. This means that after reading the pattern, the reader
should have a clear solution guideline for solving a concrete problem that fits the problem
in the pattern description. However, the general solution described in the pattern must be
adjusted to the concrete design situation.

As the architect you should know the central design and architecture patterns as these
represent the typically recurring solutions to the recurring problems in software architecture
in general. You should also have a good knowledge of the design patterns and architecture
patterns of the concrete technical and non-technical domains in which you are active. This is

5
important as it enables you to solve problems of the same kind without having to “reinvent
the wheel.” Patterns are therefore a means of passing on established knowledge.

Patterns thus give architects and developers a common vocabulary to enable them to na-
me recurring architecture structures. Once you have a deep knowledge of the central patterns
in a domain, you will quickly see that these patterns frequently recur in given architectures.
Therefore, patterns are also an important instrument for documenting and discussing soft-
ware architectures. They enable you to recognize and name the common features in recurring
architectural structures.

Design and architecture patterns

In the context of software architecture, both design patterns and architecture patterns are
very important. What they have in common is that they both generally present structural,
technical solutions. You can therefore distinguish them from patterns that cover functional
aspects (see, for example, [Fowler 1996] and [Evans 2004]). Patterns for functional aspects
are often the basis for the domain-driven design of an analysis model. Design patterns and
architecture patterns are thus frequently used in the implementation of the analysis model.
In general, design patterns describe more specific design solutions that have a local effect,
whereas architecture patterns tend to describe system structures that have an effect across
the entire system. However, it is difficult to differentiate between these two categories of
patterns.