[MUSIC]

Many organizations in our lives work by some kind of hierarchy, a business,

a government, a student society.

Let's look at a school.

The basic organization of the people in a school could be visualized like this.

The boss of the school is the principal, who is the core of the school.

The teachers are the next layer, while the students are the outer layer.

The students get information, support, and guidance from the teachers and

grow into wonderful, contributing members of our society.

In our example, they only interact with the teachers and not the principal.

The principal, in turn, supports the teachers.

This could include providing a curriculum, dealing with problems that the teachers

cannot handle themselves, or giving feedback to the teachers.

In software applications, the inner layer in an interaction

is usually providing services to the one outside it.

Another common way to represent a layered structure is like this.

What we called the inner layers are now the bottom layers.

These three groups are the three layers of the organization.

People in adjacent layers interact.

So the students and the principal only have to interact with one layer,

the teachers, while the teachers have to interact with both of their adjacent

layers, the principal and the students.

People in each layer can also interact with each other.

In this simple example, of course students talk with other students.

In software, this is often the case.

A layer is a collection of components that work together toward a common purpose.

If we add more layers,

each layer would still communicate with its adjacent layers.

For example, we could add a superintendent at the center.

The principal would only need to communicate with the superintendent and

the teachers.

As far as the students or teachers are concerned,

the superintendent is totally hidden.

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.

We often simplify discussion of a layered architecture by

thinking of a layer as a single entity instead of a set of components.

As a result ,we often say that a layer only interacts with adjacent layers,

even though this is a simplification.

When an upper layer interacts with a layer directly below it,

it cannot see any of the deeper layers.

If we pretend for a moment that a school is a strictly layered architecture,

then the principal could change and the students would have no idea.

The students only rely on the services of the teacher layer.

Usually, the inner or bottom layer provides services or abstractions for

the layer outside or above it.

For example,

a higher layer may request information which the layer below it provides.

A higher layer could also request an operation from the layer below.

A lower layer could signal a layer above an event.

The interfaces provided by the components of layer should be well defined and

driven by the needs of the system.

Layering allows for separation of concerns into each of the layers.

Many layered systems are split into presentation, logic, and data layers.

Hardware systems, such as personal computers or communications protocols,

are usually based on layers of increasing abstraction from the hardware itself.

The operating system for a computer is a common example of a layered system.

Let's look at a simplified view of that.

A kernel is the core of an operating system.

One of its main responsibilities is interfacing with the hardware and

allocating resources.

For example, the kernel schedules operations for the processor or

reads the input from your mouse.

Above the kernel layer is what we call system and application libraries.

Basically, you can think of this layer as providing the higher level functions

that programs need to interface with the kernel.

This could include functions for saving files or drawing graphics, for example.

Above the libraries layer is what many end users view as the operating system,

utilities and applications.

Utilities are tools included with the operating system, such as command line

programs, and those with graphical user interface like the file browser.

Applications are additional programs, often installed by the user for

specific purposes.

Both utilities and applications rely on the layer below to use system resources.

The most obvious benefit of this layered structure is that users can perform

complex tasks without understanding the layers below.

In the same way, programmers can create applications that rely on

the libraries layer without needing direct knowledge of the kernel.

Another benefit of this structure is that the different layers can be run at

different levels of authorization or privilege.

The top layer is typically run in what is called the user space, which does not have

the authority to allocate system resources or communicate with hardware directly.

This so-called sandboxing improves the security and reliability of the kernel.

By using a layered architecture, your design will be more loosely coupled.

Layered architecture follows the principle of least knowledge.

Each layer only interacts directly with adjacent layers.

Lower layers typically provide services to the layer above.

So, if you do replace a layer, you only have to ensured that its interface with

the layer above is consistent with the previous implementation.

Unfortunately, not every software problem can easily be

mapped to a layered architecture.

Even in the simple example of a school,

we know that students don't just talk with teachers.

The principal may like to talk to students directly to see how they're doing.

Where would administrative staff or parents go?

Depending on their tasks, they actually interact with any layer.

What about a system for accessing or changing the marks of the students?

Presumably, all layers would need access to it.

This is not easily mapped to a strictly layered architecture.

Sometimes it can be difficult to find the right way to organize the solution to

a problem into layers.

In the school example, the three groups are easy to classify.

But it might not be obvious where to make the division for

software between a collection of object-oriented classes.

Enforcing layers also has an efficiency tradeoff.

If you enforce the rule that only adjacent layers can communicate,

then any real system will have some interactions that are simply passed

through one layer to the next.

Think back to the example of our teacher.

Maybe there's a math competition coming up and

the principal wants to let the students know.

In a strictly layered system,

the principal first tells the teacher to speak to the students.

The teacher then tells the students.

The teacher did not change the notification at all,

just passed it on to the students.

From a software perspective, this extra communication adds complexity and

uses processing resources.

You have to balance this overhead against the separation of responsibilities gained

from enforcing layers.

If you find yourself passing most of your communication directly through a layer,

then it's time to think of relaxing the layer design or

using a different architecture.

On the other hand, if only a small amount of communication is passed through,

the you can continue using layers.

The layered architecture can be relaxed by allowing for pass-through.

This is often shown on the layered diagram as a notch in the layer,

as in this diagram.

In this example, our diagram now shows that students sometimes interact directly

with the principal.

However, this makes for tighter coupling in your software.

The benefits of being convenient should be measured against the downsides,

tighter coupling and a more complex structure.

Other layered systems may have more than one grouping in a layer.

More complex layered architectures can even use three dimensions,

still with direct interactions only between adjacent layers.

Why use layered architecture?

Layered systems are an intuitive and powerful architecture.

Many organizations and solutions have a layered structure.

So if you understand layered architecture, you can easily apply it where appropriate.

Layering allows for separation of concerns.

Each layer is actually a set of components, but

with similar responsibility or purpose.

Since each layer communicates with only one or

two other layers, different implementations of a layer can be swapped

easily because layering encourages modular loosely coupled code.

Layers are easily mapped to organize a solution to many problems.

Even when a pure layered architecture is not used in the end product,

it can be adapted to help manage the design complexity or

serve as a starting point for structuring the system.

3.2.4 – Layered Systems

Software Architecture

Conheça os instrutores