III_Teorico (3)

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Arquitetura 
de Software
Arquitetura de Software em Camadas
Responsável pelo Conteúdo:
Prof. Me. Wilson Vendramel
Revisão Textual:
Prof.ª Esp. Kelciane da Rocha Campos
Nesta unidade, trabalharemos os seguintes tópicos:
• Arquitetura de Software em Camadas;
• Arquitetura do Sistema de Software;
• Arquitetura Lógica;
• Arquitetura Física.
Fonte: iStock/Getty Im
ages
Objetivos
• Entender a representação da arquitetura lógica por meio de pacotes e da arquitetura 
física por meio de alocação de camadas e de componentes.
Caro Aluno(a)!
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o 
último momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem.
Bons Estudos!
Arquitetura de 
Software em Camadas
UNIDADE 
Arquitetura de Software em Camadas
Contextualização
Os sistemas de software baseados na Web, mais conhecidos como aplicações Web, 
são implementados como arquiteturas cliente-servidor em multicamadas, exigindo no mí-
nimo três camadas: apresentação, aplicação e dados.
O sistema de software orientado a objetos pode ser visto por meio de subsistemas 
que o compõem. Esses subsistemas são definidos durante o projeto (design) de arquite-
tura de software.
A arquitetura de software é a estrutura do sistema de software, que especifica e mos-
tra os componentes do software, as propriedades visíveis externamente e como elas se 
relacionam entre si.
Por conta da importância do projeto (design) de uma arquitetura de software, as 
decisões tomadas durante o projeto arquitetural de software influenciam diretamente na 
construção do sistema de software, pois também definem a maneira como o software 
atenderá a seus requisitos não funcionais. A arquitetura do sistema de software pode ser 
definida em dois níveis arquiteturais: arquitetura lógica e arquitetura física.
Para sistemas simples, a arquitetura de software não tem tanta relevância, mas na 
modelagem de sistemas complexos, inclusive sistemas distribuídos e baseados na Web, é 
fundamental conhecer quais são os componentes físicos do sistema, quais são as interde-
pendências entre eles e de que forma as camadas lógicas do sistema de software estão 
organizadas por esses componentes.
6
7
Arquitetura de Software em Camadas
Este material teórico apresenta a arquitetura de software em camadas, representando 
a arquitetura lógica por meio de pacotes e a arquitetura física por meio de alocação de 
camadas e de componentes. Para facilitar a compreensão da representação da arquitetura 
de software em camadas, serão utilizadas notações da Unified Modeling Language (UML), 
especificamente os diagramas de pacotes, de componentes e de implantação.
Arquitetura do Sistema de Software
Na Primeira Unidade, foi mencionado que as funcionalidades de um sistema de software 
orientado a objetos são realizadas internamente por meio de colaborações entre objetos. 
Isso significa que um sistema de software orientado a objetos é formado por objetos que 
interagem entre si por meio do envio de mensagens com o objetivo de executar suas 
tarefas para com o sistema de software.
Por outro ângulo, o sistema de software orientado a objetos pode ser visto por meio 
de subsistemas que o compõem. Esses subsistemas são definidos durante o projeto 
(design) de arquitetura de software.
A definição de subsistemas divide o sistema de software em partes, estabelecendo 
as interfaces entre essas partes. As vantagens de dividir um sistema de software são:
a) produção de unidades menores de desenvolvimento; 
b) maximização do reuso no nível de subsistemas componentes;
c) suporte no gerenciamento da complexidade no desenvolvimento 
(BEZERRA, 2015).
Só para lembrar, o que é arquitetura de software mesmo?
Na Primeira Unidade, foi apresentada uma das definições sobre arquitetura 
de software.
A arquitetura de software é a estrutura do sistema de software, que especifica e mostra 
os componentes do software, as propriedades visíveis externamente e como elas se rela-
cionam entre si. A arquitetura de software é influenciada e modificada com o decorrer do 
tempo pelos requisitos de negócio, ambiente de desenvolvimento e evolução das caracte-
rísticas técnicas (BASS, CLEMENTS e KAZMAN, 2003).
Apesar de a Unidade 1 ter definido o termo arquitetura de software a partir do importante 
livro chamado Software Architecture in Practice de Bass, Clements e Kazman (2003), não há 
uma definição universal quanto ao significado de arquitetura de software.
De qualquer forma, vale a pena destacar também a definição de arquitetura de software 
apresentada no documento de especificação da Unified Modeling Language (UML).
7
UNIDADE 
Arquitetura de Software em Camadas
É a estrutura organizacional do software. Uma arquitetura pode ser 
recursivamente decomposta em partes que interagem através de 
interfaces. Relacionamentos conectam as partes e restrições que se 
aplicam ao agrupamento das partes. (OMG, 2001 apud BEZERRA, 
2015, p.339.)
Maiores informações sobre a UML podem ser encontradas em: https://goo.gl/4i9W
Na Unidade Anterior, foram elencados alguns atributos de qualidade de um sistema 
de software: funcionalidade, segurança, portabilidade, usabilidade, interoperabilidade, 
desempenho e manutenibilidade. Esses atributos de qualidade refletem os requisitos não 
funcionais do software. Dependendo do propósito do software em relação ao domínio 
de negócio, alguns atributos devem ser priorizados enquanto que outros são relevados. 
Certo, mas por que eu mencionei novamente esses atributos?
Por conta da importância do projeto (design) de uma arquitetura de software, as de-
cisões tomadas durante o projeto arquitetural de software influenciam diretamente na 
construção do sistema de software, pois também definem a maneira como o software 
atenderá a seus requisitos não funcionais. A arquitetura do sistema de software pode ser 
definida em dois níveis arquiteturais: arquitetura lógica e arquitetura física.
Arquitetura Lógica
A arquitetura lógica define como um sistema de software é decomposto em diversos 
subsistemas e como as suas classes são distribuídas nos diversos subsistemas definidos. 
A arquitetura lógica se refere à organização das classes de um sistema de software em 
subsistemas, representando, assim, um conjunto de classes. Um sistema de software pode 
ser dividido em vários subsistemas, sendo que a comunicação entre eles é realizada através 
de suas interfaces. Cada subsistema tem sua interface e fornece serviços aos outros subsis-
temas por meio do conjunto de serviços estabelecidos na sua interface (BEZERRA, 2015).
Um subsistema consome serviços de outros subsistemas através de interfaces e um sub-
sistema fornece serviços para outros subsistemas através de interfaces. Já que o conceito de 
interface será bastante utilizado nesta unidade, vamos aproveitar a ocasião para explicá-lo.
Quando surge o termo interface, é bastante comum associar o referido termo à inter-
face gráfica (de usuário), mas nem sempre estamos nos referindo a esse tipo de interface. 
Este material teórico utiliza o conceito de interface para estabelecer a comunicação entre 
objetos,tanto na visão de classes quanto na visão de subsistemas ou até mesmo na visão 
de componentes.
Vale ressaltar que uma interface representa um conjunto de serviços (métodos) fornecidos 
por uma classe, um subsistema ou um componente. Os serviços disponibilizados pelas inter-
faces são abstratos, portanto não apresentam implementação, necessitando ser implemen-
tados (realizados) por uma ou mais classes, por um subsistema ou um componente.
8
9
Uma interface pode ser vista como um contrato de comportamento entre um objeto 
consumidor e possíveis objetos fornecedores de um determinado serviço. Uma vez que 
o objeto fornecedor implemente a interface que o objeto consumidor espera, o objeto 
que consome o serviço não necessita conhecer o verdadeiro objeto que fornece o serviço 
(BEZERRA, 2015).
Não confunda classe abstrata e interface. Apesar de algumas semelhanças por ambas 
serem abstratas, tais conceitos são diferentes, tendo cada um o seu objetivo.
As classes abstratas são utilizadas para simplificar e organizar hierarquias de generali-
zação/especialização (herança), onde propriedades comuns a diversas classes podem ser 
definidas em uma classe abstrata, a partir da qual suas subclasses herdam. As classes abs-
tratas também propiciam o princípio do polimorfismo. Já as interfaces são utilizadas para 
estabelecer um contrato comportamental (de serviços) entre um objeto consumidor e objetos 
fornecedores de um determinado serviço. A classe abstrata possui tanto métodos concretos 
quanto abstratos, enquanto a interface possui apenas métodos abstratos. A classe abstrata 
tem atributos, mas a interface não; eventualmente uma interface pode ter constantes, mas 
vale lembrar que constantes não são atributos. Uma semelhança entre os dois conceitos é 
que tanto a classe abstrata quanto a interface não instanciam objetos.
A figura 1 mostra um exemplo de utilização do conceito de interface. O objeto consumi-
dor Cliente depende do objeto fornecedor ContaBancaria através da interface Manipulável 
e o objeto consumidor Gerente depende do objeto fornecedor ContaBancaria através da 
interface Administrável. Como as duas interfaces apresentam somente as assinaturas dos 
serviços, isto é, métodos abstratos, o objeto ContaBancaria precisa implementar (realizar) 
as interfaces.
Figura 1 – Realização de interfaces
Fonte: Adaptado de Bezerra, 2015 p. 287
Mas na verdade, o que há em cada uma das interfaces apresentadas na figura 1?
9
UNIDADE 
Arquitetura de Software em Camadas
Cada interface tem seu conjunto de serviços (métodos) a ser implementado (realizado) 
pela classe ContaBancaria. A figura 2 mostra o mesmo exemplo, só que agora de forma 
explícita, revelando assim os serviços das interfaces. O objeto consumidor Cliente depende 
dos serviços (métodos) creditar() e debitar() do objeto fornecedor ContaBancaria através 
da interface Manipulável, e o objeto consumidor Gerente depende dos serviços (métodos) 
desbloquear(), creditar() e debitar() do objeto fornecedor ContaBancaria através da interface 
Administrável. Os serviços de ambas as interfaces devem ser realizados pelo objeto 
ContaBancaria. Observe ainda a sintaxe de realização entre a classe ContaBancaria e as 
interfaces. Também é comum a interface ser definida de forma similar à notação de classe, 
mas vale frisar que as interfaces não possuem atributos, apenas as assinaturas dos serviços, 
isto é, métodos abstratos e definidos com visibilidade pública.
Figura 2 – Realização de Interfaces (usando notação de classe)
 Fonte: Adaptado de Bezerra, 2015 p. 286
As interfaces são utilizadas com os seguintes propósitos:
a) capturar semelhanças entre classes não relacionadas sem obrigar relacionamentos 
entre elas;
b) declarar métodos que uma ou mais classes devem implementar;
c) revelar os serviços de um objeto, sem revelar a sua classe;
d) aumentar o desacoplamento entre objetos de um sistema (BEZERRA, 2015).
Uma vez que o conceito de interface foi apresentado, torna-se mais fácil compreender 
o que é uma arquitetura lógica.
Durante o desenvolvimento de um sistema de software, seus subsistemas devem ser 
definidos, inclusive as interfaces de comunicação entre eles. Cada classe do sistema deve 
10
11
ser alocada em um subsistema. Feito isso, esses subsistemas podem ser desenvolvidos 
quase que independentemente uns dos outros.
Como um sistema de software é decomposto em subsistemas e como as classes desse 
sistema são alocadas nos diversos subsistemas?
De acordo com Bezerra (2015), o modelo de classes de domínio é o ponto de parti-
da para a identificação dos subsistemas de um sistema de software orientado a objetos. 
As classes devem ser agrupadas adotando-se algum critério para formar subsistemas, sendo 
que um critério de agrupamento interessante é considerar as classes mais importantes do 
modelo de classes de domínio. Para cada uma dessas classes, um subsistema é definido e 
as outras classes menos importantes e que estão relacionadas a uma classe considerada 
importante são alocadas no subsistema desta última.
Para exemplificar a identificação de subsistemas e a alocação de classes nos subsiste-
mas, vamos recordar o diagrama de classes de projeto apresentado na Primeira Unidade 
desta disciplina. Para você se lembrar do diagrama ao qual estou me referindo, o mesmo 
é apresentado na figura 3. Apesar desta figura exibir um diagrama de classes de projeto, 
as três classes definidas são de modelo, refletindo, assim, o domínio de negócio.
Figura 3 – Diagrama de Classes de Projeto
 Fonte: Elaborado pelo autor
Considerando que o modelo de classes de projeto da figura 3 tem duas classes mais im-
portantes: Locação e Cliente, nós podemos identificar dois subsistemas chamados de Loca-
ção e Cliente, respectivamente, e distribuir as classes existentes pelos subsistemas definidos. 
A classe Carro (menos importante) é alocada juntamente com a classe mais importante à 
qual ela está relacionada (Locação).
A figura 4 mostra um diagrama de subsistemas contendo os dois subsistemas identifi-
cados. Na arquitetura lógica, os subsistemas são representados como pacotes, portanto, 
logicamente, um subsistema é um pacote de classes. Além da alocação das classes nos 
devidos subsistemas (pacotes), observe que cada subsistema tem a sua interface, sendo 
ILocacao para o subsistema Locação e ICliente para o subsistema Cliente. Vale enfatizar 
que uma ou mais classes do subsistema implementam sua interface.
11
UNIDADE 
Arquitetura de Software em Camadas
Figura 4 – Diagrama de Subsistemas (Pacotes)
 Fonte: Elaborado pelo autor
Surgindo novas classes a partir da decomposição das classes do modelo de domínio, 
essas também devem ser alocadas aos subsistemas definidos. Sendo necessário, uma 
nova classe de domínio decomposta pode definir um novo subsistema.
A figura 5 mostra novamente um diagrama de subsistemas contendo os dois subsiste-
mas identificados anteriormente, mas desta vez com a alocação de novas classes que fo-
ram decompostas a partir das classes de domínio que já existiam. O subsistema Locação 
ganhou mais duas classes: Motor e Roda, enquanto que o subsistema Cliente também 
ganhou duas novas classes: Endereço e Telefone.
Figura 5 – Diagrama de Subsistemas (Pacotes) com a alocação de novas classes
 Fonte: Elaborado pelo autor
12
13
Uma classe deve ser definida em um único subsistema, embora possa ser utilizada em 
vários. O subsistema que define a classe deve mostrar todas as propriedades (atributos e 
métodos) da mesma. Já os outros subsistemas que fazem referência a essa classe podem 
utilizar a notação simplificada da mesma, isto é, apenas o nome da classe.
O padrão de arquitetura Model-View-Controller (MVC) tem relação com a arquitetura 
lógica do sistema de software. A figura 6 apresenta uma representação do MVC em um 
diagrama de subsistemas (pacotes). Observe que os subsistemas se comunicam através de 
suas interfaces, encapsulando as classes alocadas nos subsistemas. Vale ressaltar que esta 
figura é um refinamentoda figura 10, apresentada na Unidade Anterior.
Figura 6 – Diagrama de Subsistemas 
(Pacotes) com a alocação de novas classes
Fonte: elaborado pelo autor
Outras informações sobre o padrão arquitetural MVC podem ser encontradas em: 
https://goo.gl/QO4O5P
Já abordamos classe e subsistema. Agora, vamos abordar o conceito de camada. O 
que é uma camada de software? Por que vale a pena dividir um sistema de software 
em camadas?
Os sistemas de software têm uma arquitetura genérica que pode ser organizada como 
uma arquitetura em camadas. Esses sistemas são baseados em transações, pois normalmen-
te esses sistemas envolvem transações de banco de dados. As camadas incluem: interface de 
usuário, comunicações de usuário, recuperação e modificação de informações e banco de 
dados (SOMMERVILLE, 2011).
A figura 7 apresenta uma arquitetura genérica em camadas na forma de uma pilha de 
camadas de software.
13
UNIDADE 
Arquitetura de Software em Camadas
Figura 7 – Arquitetura Genérica em Camadas
Fonte: Sommerville, 2011 p. 118
Os sistemas de software baseados na Web, mais conhecidos como aplicações Web, são 
implementados como arquiteturas cliente-servidor em multicamadas. O servidor Web é res-
ponsável por todas as comunicações do usuário, onde a interface de usuário é implementa-
da utilizando um browser; o servidor da aplicação é responsável por implementar a lógica 
específica de aplicação, assim como o armazenamento de informações e as solicitações 
de recuperação; o servidor do banco de dados move as informações do banco de dados 
para a aplicação ou desta última para o banco de dados, além de gerenciar as transações 
(SOMMERVILLE, 2011).
De acordo com Bezerra (2015), uma camada é uma coleção de unidades (classes ou 
subsistemas) que podem ser executadas ou acessadas. As camadas representam níveis 
de abstração distintos. Por exemplo, um sistema de software orientado a objetos pode 
ser representado por uma pilha de camadas de software que se comunicam entre si. 
Enquanto as camadas inferiores apresentam serviços cada vez mais genéricos, as cama-
das superiores representam serviços cada vez mais específicos. A divisão de um sistema 
de software em camadas possibilita maior portabilidade e manutenibilidade. Se houver 
uma modificação numa camada mais baixa (mais genérica) que não afete a sua inter-
face, essa alteração não acarretará mudanças nas camadas mais altas. Se houver uma 
modificação em uma camada mais alta (mais específica) que não resulte no surgimento 
de um serviço em uma camada mais baixa, essa alteração não acarretará mudanças nas 
camadas mais baixas.
Não há uma padronização na literatura para definir os nomes das camadas típicas 
de um sistema de software.
A figura 8 mostra uma representação típica de uma arquitetura cliente-servidor em 
multicamadas comumente encontrada em sistemas de software, separando as camadas 
mais comuns de um sistema de software: apresentação, aplicação, domínio e infraestru-
tura. Observe nessa figura que de cima para baixo, as camadas vão ficando cada vez mais 
genéricas. Outra observação a ser feita é que as camadas de cima dependem das camadas 
de baixo, mas o contrário não acontece.
14
15
Embora a notação da UML para subsistemas (pacotes) e para camadas seja a mesma, 
os significados desses conceitos são distintos. Uma camada de um sistema de software 
costuma ter diversos subsistemas dentro dela. Enquanto um subsistema agrupa classes, a 
camada agrupa subsistemas. 
Figura 8 – Representação típica de uma 
arquitetura cliente-servidor em multicamadas
Fonte: Adaptado de Bezerra, 2015 p.344
• Camada de apresentação também é chamada de camada de interface com o usuário;
• Camada de aplicação também é chamada de camada de serviço;
• Camada de domínio também é chamada de camada de negócio;
• Camada de infraestrutura também é chamada de camada de serviços técnicos.
Outro aspecto importante é entender a relação entre o padrão arquitetural MVC com 
as camadas da arquitetura lógica apresentada na figura 8.
Apesar de os componentes do MVC não serem camadas, é possível haver uma corres-
pondência entre seus componentes e as camadas de software, ainda mais para aplicações 
Web. Os componentes View e Controller (no que tange requisições HTTP) estão aloca-
dos na camada de Apresentação. O componente Controller (no que tange o controle de 
um caso de uso) está alocado na camada de Aplicação, pois gerencia a resposta esperada 
ao se comunicar com a camada de Domínio. O componente Model está alocado na ca-
mada de Domínio. Por fim, na camada de Infraestrutura estão os serviços relacionados às 
15
UNIDADE 
Arquitetura de Software em Camadas
tecnologias utilizadas para o desenvolvimento da aplicação, como, por exemplo, o acesso 
a um banco de dados (BEZERRA, 2015).
Apenas para enfatizar a relação do padrão de arquitetura MVC com sistemas basea-
dos na Web, a figura 9 apresenta uma visão da arquitetura de software para aplicações 
Web utilizando o padrão arquitetural MVC.
Figura 9 – Arquitetura de software utilizando o padrão MVC
 Fonte: Sommerville, 2011 p. 110
Na plataforma JEE, as tecnologias Java ServerPages e Servlets são adotadas para implemen-
tar o padrão arquitetural MVC. Há diversos frameworks que suportam a divisão da aplicação 
Web seguindo o padrão MVC, como o Java ServerFaces, o Spring MVC e o Apache Struts. No 
contexto da plataforma Microsoft, há o framework ASP.NET MVC, por exemplo. 
Arquitetura Física
A arquitetura física, também chamada de arquitetura de implantação, representa a 
distribuição física do sistema de software pelo hardware disponível. Essa arquitetura diz 
respeito à disposição dos subsistemas de um sistema de software pelos nós de processa-
mento (máquinas) disponíveis. Para sistemas simples, a arquitetura de implantação não 
tem muita relevância, mas na modelagem de sistemas complexos, inclusive sistemas distri-
buídos e baseados na Web, é fundamental conhecer quais são os componentes físicos do 
sistema, quais são as interdependências entre eles e de que forma as camadas lógicas do 
sistema de software estão organizadas por esses componentes. O modelo da arquitetura 
física pode ser representado pelo diagrama de componentes e diagrama de implantação. 
Ambos os diagramas fazem parte da UML (BEZERRA, 2015).
Como os subsistemas devem ser distribuídos fisicamente em nós de processamento 
(máquinas) na implantação do sistema de software?
16
17
Em um sistema de software desenvolvido de acordo com a arquitetura cliente-servidor, 
é bastante comum utilizar as definições das camadas lógicas como um guia para a alocação 
física dos subsistemas. Dessa forma, a cada nó de processamento são alocadas uma ou 
mais camadas lógicas. É importante ficar atento(a) com o termo camada, pois normal-
mente é utilizado com dois sentidos diferentes. Quando abordamos a camada lógica, nós 
estamos nos referindo ao termo layer, porém quando abordamos a camada física, nós es-
tamos nos referindo a um nó de processamento, isto é, ao termo tier (BEZERRA, 2015).
A divisão de um sistema em camadas lógicas é independente da sua distribuição 
física. As camadas de software podem estar fisicamente localizadas em um único nó 
de processamento, ou podem estar distribuídas por diversos nós. Outra alternativa 
é que as camadas lógicas podem estar distribuídas fisicamente em vários nós de 
processamento. Um exemplo é a camada da lógica de negócio que pode ser dividida 
em duas ou mais máquinas.
Já foi mencionado nesta disciplina que a arquitetura adotada por sistemas de software 
baseados na Web é a arquitetura cliente-servidor em multicamadas, precisando haver no 
mínimo três camadas. A figura 10 apresenta uma representação típica da arquitetura 
cliente-servidor em três camadas para aplicações Web.
APRESENTAÇÃO
SERVIDOR DA APLICAÇÃO
SGBD
Figura 10 – Representação da arquitetura 
cliente-servidor em três camadas
Fonte: Adaptado de Bezerra, 2015 p. 358
Sobre a arquitetura cliente-servidor em três camadas, ainda é importante destacar:a) a camada lógica de apresentação fica em um nó de processamento (conhecido 
como presentation tier);
b) as camadas lógicas da aplicação e do domínio ficam juntas em outro nó (camada 
física denominada middle tier). Essa camada física representa o servidor da aplica-
ção. A camada de apresentação requisita serviços para essa camada. É possível ha-
ver mais de um servidor de aplicação, com o objetivo de aumentar a disponibilidade 
e o desempenho do sistema de software;
c) a camada física do meio faz acesso a outra camada física, onde geralmente está 
localizado um banco de dados. Essa camada física é chamada de camada de dados 
(data tier) (BEZERRA, 2015).
17
UNIDADE 
Arquitetura de Software em Camadas
Uma vez que as camadas lógicas foram alocadas aos devidos nós de processamento, 
o diagrama de implantação da UML pode ser utilizado para representar a arquitetura 
física do sistema de software.
A figura 11 apresenta uma possível representação do diagrama de implantação. Esse 
diagrama tem dois elementos básicos: os nós de processamento, que representam os 
recursos computacionais (máquinas, por exemplo) e suas conexões, que representam os 
mecanismos de comunicação.
<<LAN>>
IMPRESSORA
CLIENTE:
BROWSER
SERVIDOR
DA APLICAÇÃO
BANCO DE 
DADOS CORPORATIVO
<<HTTP>> <<ODBC>>
Figura 11 – Diagrama de Implantação
Adaptado de Bezerra, 2015 p. 359
O que deve ser alocado em nós de processamento?
Na arquitetura física, os componentes de software de cada camada também devem 
ser definidos.
Um componente de software é uma unidade que existe em tempo de execução, que 
pode ser utilizada na construção de diversos sistemas e que, havendo necessidade, pode 
ser substituída por outra unidade que tenha a mesma funcionalidade. Um componente 
provê acesso aos seus serviços por meio de uma interface. Quando o componente é cons-
truído de acordo com paradigma orientado a objetos, ele é composto por vários objetos, 
portanto a interface do componente é constituída de um ou mais serviços que as classes 
dos referidos objetos implementam (BEZERRA, 2015).
A figura 12 mostra um diagrama de implantação com os componentes alocados. 
Este diagrama foi elaborado a partir dos subsistemas (pacotes) e das camadas lógicas 
(layers) projetadas anteriormente na arquitetura lógica para o sistema de software de 
locadora de carros, sendo no caso uma aplicação Web. Na arquitetura física, os sub-
sistemas são representados como componentes, portanto fisicamente um subsistema 
é um componente de classes. Além da alocação dos componentes nos devidos nós de 
processamento (máquinas), observe que cada componente tem a sua interface, sendo 
ILoc para o componente Locação e ICli para o componente Cliente. Este diagrama 
mostra ainda dois serviços externos disponíveis na Web (Web Services), sendo um para 
consultar a situação do CPF do cliente e outro para efetuar o pagamento por meio de 
cartão de crédito. Cada Web Service (WS) foi alocado em um outro nó de processa-
mento, pois são serviços de terceiros que se encontram disponíveis em outras máquinas. 
18
19
A aplicação Web de locadora de carros somente reutilizará os serviços disponíveis em 
tempo de execução. Observe que o diagrama de implantação representa a forma como 
será a integração e implantação do sistema de software no hardware disponível.
Para mais informações sobre arquitetura de Web Services, acesse: https://goo.gl/XYDPBM
Figura 12 – Diagrama de Implantação 
com alocação de componentes
 Fonte: Elaborado pelo autor
Para maiores detalhes sobre os diagramas da UML, você também pode explorar o livro UML 
essencial: um breve guia para a linguagem-padrão de modelagem de objetos, de Fowler 
(2005), disponibilizado na Biblioteca Virtual Pearson, em: https://goo.gl/g72tci
Este material teórico abordou diversos conceitos relacionados à arquitetura de software 
em camadas, tais como subsistema (pacote), componente, camada lógica (layer), cama-
da física (tier). Compreender a arquitetura de software cliente-servidor em multicamadas 
não é algo simples. Por esta razão, eu procurei representar os conceitos abordados com 
o suporte de diagramas da UML, visando facilitar a compreensão. De qualquer forma, é 
importante que você busque maiores informações sobre o tema nas referências utilizadas 
e no material complementar.
19
UNIDADE 
Arquitetura de Software em Camadas
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Leitura
Model-View-Controller (MVC)
https://goo.gl/QO4O5P
Biblioteca Cruzeiro do Sul Virtual
https://goo.gl/g72tci
Unified Modeling Language - UML
https://goo.gl/4i9W
W3
https://goo.gl/XYDPBM
20
21
Referências
BASS, L.; CLEMENTS, P.; KAZMAN, R. Software architecture in practice. 2.ed. 
Addison-Wesley, 2003.
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 3ª ed. São 
Paulo: Elsevier, 2015.
FOWLER. M. UML essencial: um breve guia para a linguagem-padrão de modelagem 
de objetos. 3ª ed. Porto Alegre: Bookman, 2005.
SOMMERVILLE, I. Engenharia de software. 9ª ed. São Paulo: Pearson, 2011.
21