ARCHITECTURAL STYLES

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.
Language-Based Systems
 Language-Based Systems
The programming paradigm of the language selected to implement
a system will affect the architectural style of that system.

Each programming paradigm has its own set of constructs, principles,

and design patterns, and their use shapes the system being created

This section focuses on object-oriented architectural styles, which

result from object-oriented programming paradigms
The following object-oriented principles were explored:

Abstraction: that simplifies a concept

Encapsulation: that bundles data and functions into a self contained
object, so other objects can interact with it through an exposed
interface
Decomposition: that breaks a whole into parts
Generalization: that allows you to factor out conceptual commonalities
Object-oriented design patterns were also explored. These can fall
into the following categories: Creational patterns, Structural patterns,
Behavioural patterns

Interview Question: Can you define each one of this terms?

These elements lead to an object-oriented
architectural style for the system.
Abstract Data Types and Object Oriented
Design
Object-oriented design architectural styles are focused on the data.

• An abstract data type can be represented as a class.

• Encapsulation restricts access to the data and dictates what can be
done with it.
• Objects may interact with each other through the use of their
methods.
 In other words, the overall object-oriented architectural style of a
system directly follows from the fact that an object-oriented approach
was used in development.

However, not all situations will have easily identifiable classes. In

some situations, another design choice may be better suited for the
problem at hand.
Main Program and Subroutine
 Main Program and Subroutine
Main program and subroutine architectural styles are focused on
functions. They develop from a procedural programming paradigm.

C is an example of a language that follows this paradigm.

 In a main program and subroutine architectural style, a system is
modelled by breaking up the overall functionality of the system into a
main program and subroutines
In the diagram, subroutines are connected by procedure calls, and they
may have nested calls. In nested calls, subroutines may call other
subroutines, which may call yet more subroutines, and so on.

This means that the structure of the resulting code is not flat, but
rather it is hierarchical.

Interview Question: ¿What can you say about that style? Pros and cons
In this paradigm, data is stored as variables. The main focus of this
paradigm is therefore on the behaviour of functions and how data
moves through those functions.

The main program and subroutine architectural style is best suited for
computation-focused systems.
Each subroutine may have its own local variables. A subroutine has
access to all data within its scope. To access data outside its scope, data
may be passed into the subroutines as parameters, by value or by
reference, and data may be passed out of a subroutine as a return
value.

This architectural style promotes modularity and function reuse, which

results in certain advantages. When functions are well defined and do
not produce side effects, they are considered like “black boxes.”
Interview question: What is a “side effect”?. In your words define
“scope”
There are also certain disadvantages from this style. Subroutines may
mutate data in unexpected ways. A subroutine may be affected by data
changes made by another subroutine during execution.

This issue is especially true for global data shared across subroutines.

Interview Questions: ¿What is the problem when you use a Global

Variable?
Procedural programming paradigms are well suited to systems centred
around computation, such as spending management programs.

Identifying object-oriented components of these kinds of systems can be

difficult and result in overly complex solutions.
Repository-Based Systems
This architecture allows data to be stored and shared between multiple
components, thus increasing the maintainability, reusability, and
scalability of the system.

This architecture can be achieved by integrating a method of shared

data storage, such as a database, into the overall system design.
At the core of a data-centric architecture are two types of components:

• Central data is the component used to store and serve data across
all components that connect to it.

• Data accessors are the components that connect to the central data
component. The data accessors make queries and transactions
against the information stored in the database.
Interview Questions: What type of UML Diagram is these? Explain the Diagram
Do you think that would be another component connected to Payroll component?
 Databases
Databases ensure several data qualities, which are important to data-
centric architectures.

Interview Questions: ¿What are the data qualities in a Database ?

These are:

• Data integrity. A database ensures that data is accurate and

consistent over its lifespan.
• Data persistence. A database ensures that data will live on after a
process has been terminated—databases can save data from any
number of components.
 In data-centric architectural design, the central data is passive. Central
data is primarily concerned with storing and serving information, not
with heavy data processing or large amounts of business logic.

Interview Questions: What it means “bussiness logic”?

you should have touched on this topic in "software lab" or "software engineering"
 Data accessors
Data accessors are any component that connects to a database, which is
characterized by its abilities to:

• Communicate with the database through database queries and

transactions.
• Save the new state of the system back into the database using
transactions. Data is stored back into the database once the data
accessor has finished its processing.

Interview Question: You can see this behavior if you any time watched
your server console in your web framework project in “software
laboratory”. If you don’t yet, make this practices.
A data accessor contains all the business rules required to perform its
functions.

This means that this software architecture enables you to separate

concerns into different, specialized data accessors. Also, use of the
data accessors can be controlled, so an end user only has permission
for the ones they need on a day-to-day basis.
 Advantages
• A system that can be easily scaled up, as data accessors are
functionally independent, so additional features can be added with
having to worry about affecting others.

• Central data components usually “live” on a separate server

machine with sufficient disk storage dedicated to the database,
which allow for easier management of information.
 Disadvantages
• The system is heavily reliant on the central data component, so if it
becomes unavailable or if the data corrupts, then the entire system
is affected.

• It is difficult to change the existing data schema, particularly if a

large amount of data is already stored.
In summary, data-centric software architecture is a commonly used
design by many companies.
They allow large amounts of data to be stored and managed in a
central data repository, making a system more stable, reusable,
maintainable, and exhibit better performance.
They also separate the functionality of data accessors, so it is easier to
scale the system. Finally, they also facilitate data sharing between
data accessors through database queries and transactions.

As always, the decision to use a data-centric architecture relies on the

context of the problem at hand.
Layered Systems
The key characteristic of a layered architecture is that the components
in a layer only interact with components in their own layer or
adjacent layers. When an upper layer interacts with the layer directly
below it, it cannot see any of the deeper layers.

Usually, the inner or bottom layer provides services or abstractions

for the layer outside or above it. The interfaces provided by the
components of a layer should be well defined and driven by the needs
of the system.

Interview Question: What is the purpose of an Interface? What you get when use them?
Lower layers typically provide services to the layer above. If a layer is replaced, the
provided interface for the layer above must be consistent with the previous
implementation.
Interview Question: How you represent a “provided interface” using UML?
 In summary, layered architecture:
• It supports the separation of concerns, because each layer is a set of
components with similar responsibility or purpose.

• It is modular and loosely coupled, as each layer only communications

with one or two other layers, allowing for different implementations to
be easily swapped.

• It can be adapted so that layering is not always strict, which helps

manage design complexity or provide a starting point for structuring the
system
 Client Server n-Tier
n-Tier or multitier architectures are related to layered architectures.

Tiers refer to components that are typically on different physical

machines.

The relationship between two adjacent tiers in an n-Tier architecture is

often a client/server relationship.
Client-host and server-host refer to machines that host client software and server
software respectively.
In this diagram, the top row illustrates client-hosts, and the bottom row illustrates
server hosts. This diagram is therefore a two-tier architecture. The client hosts make
up the client tier, and the media server is the data tier.
The request-response relationship from this example can also be
illustrated in a sequence diagram.
Request-response relationships can be synchronous or asynchronous.

Interview Question: What it means synchronous or asynchronous when

refer to a communication with a server?
However, you could also build a three-tier architecture, where a tier is
inserted between the database and end users. This tier is often referred
to as a middle layer, a business layer, or an application layer—its name
depends on its main responsibility.
The middle layer will be a client of the database, and a server for the
client application software on the end users’ devices.
Middle tiers help determine how or when data can be changed, and in
what ways. Having a middle layer allows client application software to
be thinner, as it can be focused on presentation only. This makes it
easier to maintain.
Muy amables como
siempre…!!