The way that software components — subroutines, classes, functions, etc. — are arranged, and the interactions between them, is called architecture. In this course you will study the ways these architectures are represented, both in UML and other visual tools. We will introduce the most common architectures, their qualities, and tradeoffs. We will talk about how architectures are evaluated, what makes a good architecture, and an architecture can be improved. We'll also talk about how the architecture touches on the process of software development. In the Capstone Project you will document a Java-based Android application with UML diagrams and analyze evaluate the application’s architecture using the Architecture Tradeoff Analysis Method (ATAM). After completing this course, you will be able to: • Compare and contrast the components, connections, protocols, topologies, constraints, tradeoffs, and variations of different types of architectural styles used in the design of applications and systems (e.g., main program and subroutine, object-oriented, interpreters, pipes and filters, database centric, event-based). • Describe the properties of layered and n-tier architectures. • Create UML ipackage, component, and deployment diagrams to express the architectural structure of a system. • Explain the behaviour of a system using UML activity diagrams. • Document a multi-application system with a layered architecture.
3.2.4 – Layered Systems
Loading...
Do curso por University of Alberta
Software Architecture
72 ratings
Na lição
Architectural Styles
Software comes in all shapes and sizes. The architecture you choose will affect every part of your software, from its security and efficiency, to its modularity and maintainability. In this module we will examine the different architectures that you have to choose from to shape your software.
Conheça os instrutores
Kenny WongAssociate Professor
Computing Science, Faculty of Science
[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.
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
