Arquitetura de Software

21/03/2023, 20:15 Arquitetura de Software
ARQUITETURA DE SOFTWARE
CAPÍTULO 2 - QUAIS SÃO AS
ABORDAGENS ALTERNATIVAS E DE
ARQUITETURA PARA SISTEMAS WEB E
APLICATIVOS MÓVEIS?
Fernando Skackauskas Dias
INICIAR
Introdução
Com o grande avanço da web e dos dispositivos móveis nos últimos anos, os
cientistas da computação se viram diante de grandes desafios. Quais são as
abordagens da arquitetura de software que foram elaboradas para contemplar esses
novos modelos de sistemas? Como esses sistemas são tratados no processo de
projeto, desenvolvimento e implantação? Existem modelos alternativos de
arquitetura de software? Estas questões se tornam relevantes, visto a convergência
de novas mídias e aplicativos para web e dispositivos móveis.
O desenvolvimento de sistemas está cada vez mais atrelado às inovações
tecnológicas, surgindo, assim, novas linguagens e novos modelos de arquitetura em
um intervalo cada vez menor de tempo. O que temos é uma tendência de se projetar
sistemas mais dependentes da web e dos dispositivos móveis, a fim de atender aos
modelos de negócio contemporâneos. Temos visto que diversos serviços que eram
oferecidos em plataformas tradicionais estão migrando paulatinamente para
https://student.ulife.com.br/ContentPlayer/Index?lc=daOC9gBTKk4VqPoEZKx%2bXQ%3d%3d&l=em87Bto5KPKBRlZLvb%2bRnQ%3d%3d&cd… 1/28
ambiente web ou para dispositivos móveis. Mais do que isso: diversos serviços já
nascem nestes ambientes. Um exemplo claro são os aplicativos urbanos para
transporte de passageiro.
Neste capítulo, veremos como a arquitetura de software é modelada para aplicações
web e dispositivos móveis, analisaremos quais são as avaliações possíveis das
alternativas de projetos, descreveremos como é empregada a linguagem de
descrição da arquitetura (ADL) e, por fim, como é feita a verificação de conformidade
da arquitetura de software.
Desejamos um excelente estudo.
2.1 Projeto de arquitetura para

aplicações web e dispositivos móveis
Desenvolver sistemas para web e dispositivos móveis é uma tarefa complexa, pois
essas aplicações sempre agem integrando diversos bancos de dados e
componentes distribuídos, além de suportarem perfis múltiplos de usuários.
Quais as características específicas na criação da arquitetura de software para
ambiente web e dispositivos móveis? Quais os modelos próprios para arquiteturas
alternativas? Quais as alternativas de arquiteturas existentes?
A fim de desenvolver uma arquitetura de software para ambiente web e aplicativos
móveis, é necessário compreender o nível de aplicações subjacentes, tais como os
objetos, os comportamentos dos componentes e as regras de negócios, além de ser
necessário adotar arquiteturas de software flexíveis para esses domínios.
Nesse sentido, abordagens orientadas a reuso, entre outras, fazem parte do projeto
de arquitetura web e dispositivos móveis. Veremos, a seguir, como são criados
projetos para esses ambientes.
2.1.1 Projeto de arquitetura para aplicações web

O desenvolvimento de aplicações para o ambiente web tem crescido
consideravelmente nos últimos anos com o fortalecimento da internet como uma
plataforma de comércio de produtos e serviços, tendo como estratégia a redução de
custos e o aumento da abrangência de atuação. Além disso, houve uma grande
evolução na capacidade de transmissão de dados, máquinas servidoras em cloud
computing e um avanço enorme na capacidade de armazenamento dos dados.
Portanto, quais são as diferenças na arquitetura de software para este ambiente?
Antes de tudo, é importante ressaltarmos a importância da aplicação de arquitetura

de software no desenvolvimento dos sistemas de informação. Segundo Sommerville
(2011, p. 5), temos dois motivos para tal:
1. Cada vez mais, indivíduos e sociedades dependem dos sistemas de

software avançados. Temos de ser capazes de produzir sistemas confiáveis
econômica e rapidamente.
2. Geralmente é mais barato, a longo prazo, usar métodos e técnicas da
engenharia de software para sistemas de software, em vez de simplesmente
escrever os programas como se fossem algum projeto pessoal. Para a maioria
dos sistemas, a maior parte do custo é mudar o software depois que ele
começa a ser usado.
A vantagem deste padrão de arquitetura é a permissão de os dados serem alterados

de forma independente da sua representação. Uma descrição resumida do
comportamento das aplicações que utilizam o padrão MVC é: o componente Visão
envia os eventos para o componente Controlador o qual, por sua vez, modifica o
estado do componente Modelo e, a seguir, o componente Visão busca as
informações do Modelo. Poderemos acompanhar o funcionamento básico do
padrão MVC na figura a seguir.
Figura 1 - Modelo MVC demonstrando a relação entre o Modelo, a Visão e o Controlador e os eventos
associados aos componentes. Fonte: Elaborada pelo autor, baseado em JÚNIOR; FORTES, 2007.
#PraCegoVer: Ilustra o modelo MVC demonstrando a relação entre o Modelo, a

Visão e o Controlador e os eventos associados aos componentes. A imagem contém
3 grandes retângulos, um para cala elemento do modelo MVC. O Controlador define
o comportamento da aplicação, mapeia as ações de alteração do modelo, seleciona
a visão para resposta e, seleciona cada uma das funcionalidades. É o controlador
que solicita alterações de estado ao modelo. O Modelo define o estado das
aplicações encapsuladas, responde aos estados das pesquisas, mostra as
funcionalidades da aplicação e notifica as alterações de visão. O elemento Visão do
MVC processa o modelo, realiza o pedido de alterações no modelo, envia ações do
usuário ao controlador e, permite ao controlador selecionar a visão.
Vimos, na figura anterior, que o componente Visão envia um determinado evento

para o componente Controlador que, a partir daí, chama um método que alterará o
estado do Modelo. A partir do momento em que o Modelo tem o estado alterado,
este componente informa à Visão, por meio do Controlador, o novo estado em que
ele se encontra. A partir daí, a Visão procura os dados no Modelo. Concluindo, o
modelo MVC é formado pelas entidades que agrupam os dados (apresentados pelo
componente Visão, que pode ser uma interface gráfica, por exemplo). Por outro
lado, o Controlador pode ser classes que têm métodos que permitem que o
componente Modelo seja atualizado a partir dos eventos que foram disparados
pelas Visões.
Na figura a seguir, demonstraremos um exemplo de interação entre os componentes
do padrão MVC em uma aplicação Java. Neste esquema, há a apresentação de como
os dados são apresentados no componente Visão: os pontos ‘x’ e ‘y’, o nível de
opacidade das informações apresentadas, o estilo da fonte e um texto descritivo.
Neste caso, um evento será disparado pelo botão change, que está na interface
gráfica. A partir do momento em que este evento é disparado, os dados são
enviados para o componente Controlador, no qual estão as classes que possuem os
métodos que permitem ao componente Modelo ser atualizado a partir dos eventos
disparados pelo componente Visão.
Figura 2 - Exemplo de interação entre os componentes do padrão MVC e suas interações de uma aplicação
em linguagem Java. Fonte: SUN, 2007 apud JÚNIOR; FORTES, 2007, p. 6.
#PraCegoVer: Ilustra um exemplo de interação entre os componentes do padrão

MVC e suas interações de uma aplicação em linguagem. A imagem é composta de
três quadros que se inter-relacionam. O quadro Model contém um código-fonte com
a declaração de algumas variáveis, sendo inicializadas com alguns valores. O quadro
Controller possui um código-fonte com a declaração de alguns métodos. O quadro
View possui o print de uma tela de um formulário que possui os campos para
preenchimento das respectivas variáreis declaradas no código-fonte do quadro
Model.
Outro tipo de padrão de arquitetura largamente utilizado é a arquitetura em 3

camadas, com base no modelo cliente-servidor. Ele se caracteriza no fato de que a
interface, a lógica do processamento, o armazenamento e o acesso aos dados ficam
em módulos independentes e cada um é atualizado, independentemente da

tecnologia utilizada. Segundo Júnior; Fortes (2007, p. 6, grifos nossos), essas
camadas se classificam em:
camada de apresentação: contém toda a interface gráfica e permite a

interação com o usuário por meio dos serviços disponíveis ao usuário
(sessões e entradas de dados, por exemplo);
camada lógica: contém toda a lógica do negócio, bem como a lógica de
transações;
camada de dados: contém os dados que são manipulados pela aplicação,
bem como o acesso a dados, atualizações e persistências deles.
Apresentaremos, a seguir, uma ilustração gráfica da arquitetura em três camadas, na

qual ocorre um sistema de vendas, em que a camada de apresentação realiza uma
função de “solicitação do total de vendas” e é onde se encontra a interface com o
usuário. A partir do momento do disparo desta solicitação, a camada lógica recebe a
solicitação e é realizado o processamento da pesquisa solicitada. Por sua vez, os
dados para realizar a pesquisa são obtidos a partir da camada de dados, onde é
realizada a recuperação dos dados necessários. Esta camada, por sua vez, retorna
para a camada lógica o resultado da pesquisa, passando o resultado do “total de
vendas” para a interface do usuário (camada de apresentação), que é a pesquisa
solicitada inicialmente.
Figura 3 - Exemplo de interação entre os componentes do padrão de arquitetura em 3 camadas e suas

interações em uma aplicação comercial. Fonte: Elaborada pelo autor, baseado em JÚNIOR; FORTES, 2007.
#PraCegoVer: Ilustra um exemplo de interação entre os componentes do padrão de

arquitetura em três camadas e suas interações em uma aplicação comercial. A
imagem contém três grandes quadros, representando cada camada, de
apresentação, lógica e de dados. Na camada de apresentação, fica a interface com o
usuário, que é o nível mais alto da aplicação. A camada lógica coordena a aplicação,
processa os comandos, executa a lógica, as decisões e as validações, além de
movimentar os dados entre as outras camadas. Na camada de dados, são estocados
os dados recuperados dos bancos de dados ou arquivos. A informação é passada
para a camada lógica e para a camada de apresentação. Na imagem existe também

um organograma do fluxo dos dados nas três camadas. Exemplo: uma solicitação do
total de vendas de uma empresa é realizada na camada de apresentação. Então na
camada lógica é construída uma pesquisa da relação de vendas. Na camada de
dados, esta pesquisa acessa o bando de dados que retorna alguns resultados. Estes
resultados são enviados para a camada lógica que processa a soma dos resultados e
envia para a camada de apresentação, que exibe ao usuário.
É possível fazermos uma comparação entre os modelos de arquitetura MVC e em 3

camadas:
arquitetura MVC: tem um comportamento de forma triangular, sendo

que a Visão emite eventos para o Controlador, que atualiza o Modelo, e a
Visão busca os dados do Modelo para exibir;
arquitetura em 3 camadas: tem um comportamento linear, pois as
camadas de apresentação não executam a comunicação de forma direta
com a camada de dados passando pela camada lógica.
2.1.2 Projeto de arquitetura para dispositivos móveis

As arquiteturas de software para dispositivos móveis consistem, fundamentalmente,
em uma aplicação que está hospedada em um servidor e que será acessada por
meio de um navegador do dispositivo.
Baseando-nos nestes princípios, temos duas possibilidades de arquitetura de
software para dispositivos móveis: a distribuída e a centralizada, as quais
explicaremos a seguir.
Arquitetura distribuída
Tem como característica principal desacoplar as regras de negócio do software (que
se encontram na camada de Modelo) das regras relativas de apresentação (camadas
de Visão e Controle). Assim, as aplicações para dispositivos móveis são
desacopladas das aplicações corporativas, e a comunicação ocorre por meio dos
serviços via web. O que temos é que as aplicações para dispositivos móveis agregam
exclusivamente as regras de visualização e controle. No lado das aplicações
corporativas, acoplam-se as regras de negócio.
Suas vantagens são:
a publicação da aplicação é independente dos serviços remotos;

o desacoplamento entre a aplicação do dispositivo móvel e as regras de
negócio;
é possível reusar as diversas funcionalidades de outras aplicações;
é possível adaptá-la às múltiplas plataformas.
Por outro lado, suas desvantagens são:
o desenvolvimento das funcionalidades pode ser dispendioso;

o consumo de serviços remotos pode gerar tempos maiores de resposta.
Arquitetura centralizada
Tem como principal característica englobar, em uma única aplicação, todas as
camadas e regras do sistema. A alteração desta arquitetura está na interface, na qual
a estrutura de dispositivo móvel serve para adaptar a interface da aplicação para
telas menores e sensíveis ao toque, melhorando a usabilidade dos usuários. A
camada de Modelo fica responsável somente para acessar serviços externos.
Segundo Pilar (2005, p. 26),
o desenvolvimento de softwares para dispositivos móveis é mais complexo do

que softwares tradicionais. Isto ocorre devido às características como
aplicações em tempo real, memória limitada da tecnologia, canais de entrada
e saída limitados, necessidade de ferramentas caras de desenvolvimento,
tendo uma forte relação com a dependência de hardware e diferentes
processadores.
Seguindo as características que mencionamos anteriormente, elas mostram os

desafios para o desenvolvimento de dispositivo móvel.
VOCÊ QUER LER?

O crescimento em tamanho e a complexidade dos sistemas de software exigem que os profissionais da
área desenvolvam novas topologias para o nível arquitetural. Como exemplo, temos os dispositivos
móveis, que têm como principal característica realizar várias tarefas distintas e se conectar com outros
aplicativos. Quer ler mais? Leia o artigo de Silva Filho (2010) em:
<http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/14312/7593
(http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/14312/7593)>.
Lee (2005) apresenta uma arquitetura específica para o desenvolvimento dos

aplicativos, que poderemos visualizar na figura a seguir.
Figura 4 - Exemplo de arquitetura para aplicativos móveis com as camadas físicas e lógicas e suas interações.
Fonte: Elaborada pelo autor, baseado em LEE, 2005.
#PraCegoVer: Ilustra um exemplo de arquitetura para aplicativos móveis com as

camadas físicas e lógicas e suas interações. A imagem apresenta as camadas na
seguinte ordem de cima para baixo: camada da arquitetura do negócio; camada da
interface do cliente móvel; camada de aplicativos de cliente móvel, que é composta
por usuário, clientes móveis, servidores back-end e de bancos de dados e, a
transferência de dados entre os clientes móveis e os servidores; camada de
segurança, e por fim; camada de gerenciamento.
https://student.ulife.com.br/ContentPlayer/Index?lc=daOC9gBTKk4VqPoEZKx%2bXQ%3d%3d&l=em87Bto5KPKBRlZLvb%2bRnQ%3d%3d&c… 10/28
Os itens da figura anterior são divididos e conceituados da seguinte forma, segundo

Lee (2005, p. 27, grifos nossos):
mobilidade: as aplicações móveis deverão seguir esta principal característica

dos dispositivos móveis;
contexto do negócio: é necessário identificar o contexto de negócio do
aplicativo;
arquiteturas de aplicação móvel: definir os tipos de arquitetura móvel;
infraestrutura móvel: análise que deve ser realizada ao definir o tipo do
dispositivo móvel;
interface com o usuário de cliente móvel: considerar a interface e periféricos
que podem ser utilizados pelo usuário;
aplicações clientes móveis: onde se deve definir a arquitetura a ser seguida;
transferência de dados cliente-servidor: definir a forma como ocorreram as
trocas de informação;
tornar móveis as arquiteturas de aplicação existentes: verificar a necessidade
de transformar ou atualizar;
segurança: é necessário o controle de acesso a usuários e a proteção dos
dados;
gerenciamento do desenvolvimento de aplicações móveis: segue as mesmas
características do gerenciamento de projetos;
estudos de caso de aplicações móveis: é considerado importante realizar
estudos de casos.
Ao desenvolvermos aplicativos para dispositivos móveis, pode ser necessária a

execução de código na camada do cliente que, nessa situação, é adotada uma
arquitetura separada em camadas. Segundo Pilar (2013, p. 30, grifos nossos), estas
camadas são descritas como:
camada de aplicação: camada que está no topo do desenvolvimento da

hierarquia da arquitetura;
camada de middleware: é a camada que suporta diferentes linguagens de
programação, como a procedural C, orientada a objetos C++ e Java;
camada do sistema operacional: responsável por cooperar com a aplicação
para aperfeiçoar o gerenciamento de processos, procedimentos e
tratamento de exceções;
camada de abstração do hardware: é a camada mais próxima do hardware,
aquela que faz contato diretamente com o dispositivo;
hardware: dispositivos móveis como smartphones, celulares, leitores de e-
books, vídeo games etc.
Vários questionamentos podem influenciar na escolha de qual arquitetura devemos

utilizar para o desenvolvimento dos sistemas de dispositivos móveis ou web, como:
o sistema deve ser desenvolvido utilizando tecnologia híbrida ou nativa? Existe
tempo hábil para desenvolver duas aplicações nativas, a fim de atender Android e
iOS? Qual o conhecimento necessário da equipe? Quanto é o custo de
desenvolvimento de aplicações nativas e híbridas? Descobriremos as respostas para
esses questionamentos no tópico a seguir.
2.2 Avaliação das alternativas do

projeto
É necessário, antes de mais nada, levantarmos de maneira clara as diferenças de
desenvolvimento dos aplicativos móveis:
aplicativo nativo: tem como característica ser desenvolvido para uma

plataforma específica, como a iOS ou a Android. Portanto, ele tem a
capacidade de explorar todos os recursos da plataforma, como o GPS ou a
câmera, mas nem sempre necessita da internet para funcionar. A
desvantagem está em seu desenvolvimento, que é mais complexo e mais
dispendioso: é necessário desenvolver um aplicativo para cada tipo de
plataforma e não pode haver reuso de código, porque cada plataforma
necessita de códigos distintos;
aplicativo híbrido: tem características do aplicativo nativo e da web,
sendo necessário utilizar os dois códigos para a criação. Portanto, este
modelo pode usar recursos tanto da internet quanto do dispositivo,
podendo ser executado em plataformas diferentes, e seu desenvolvimento
é mais ágil e com custo menor. Sua maior desvantagem é que ele não
consegue acessar as funcionalidades diretamente, sendo necessário usar
uma infraestrutura que seja intermediária entre o aplicativo e o
dispositivo.
VOCÊ SABIA?
Existem arquiteturas de software específicas para a construção e integração de ambientes virtuais de

aprendizagem. O artigo “Potencial da aprendizagem baseada-em-jogos: um caso de estudo na
Universidade do Algarve”, de Kikot; Fernandes; Costa (2015), pesquisa a interação de estudantes com
um jogo em um ambiente digital. Saiba mais em:
<http://www.scielo.mec.pt/pdf/rist/n16/n16a03.pdf
(http://www.scielo.mec.pt/pdf/rist/n16/n16a03.pdf)>.
No próximo item, abordaremos a questão da architecture description language

(linguagem de descrição da arquitetura – ADL) que descreve, de forma fundamental,
a estrutura das propriedades em alto nível de um sistema – mas sem se atrelar a
detalhes de implantação.
2.2.1 Linguagem de descrição da arquitetura (ADL)

A ADL tem como objetivo representar a arquitetura de um software, em que os
componentes são definidos, bem como seu comportamento, seus padrões e seus
mecanismos para interação entre eles. Assim, ela modela a arquitetura conceitual
de um sistema, sendo que seus elementos básicos são os componentes e os
conectores, que incluem regras e diretrizes para arquiteturas. Essa modelagem é
necessária, do contrário a descrição da arquitetura se torna uma coleção de
elementos e, se não houver uma semântica explícita, não será compreendida a sua
utilidade.
Shaw e Garlan (1994) apresentam seis propriedades que uma ADL ideal deve
fornecer: composição, abstração, reuso, configuração, heterogeneidade e análise.
VOCÊ O CONHECE?
Vannevar Bush foi professor do Instituto de Tecnologia de Massachusetts (MIT) na década de 1920 e um
dos responsáveis pela criação dos primeiros modelos de formulação matemática para problemas em
teoria dos circuitos, dando uma base fundamental para a criação dos primeiros modelos de
computadores. Leia mais em Fonseca Filho (2007).
No entanto, devido à sua natureza especializada, autores como Sommerville (2011)

consideram que a ADL seja difícil de entender e usar, o que torna complicado avaliar
sua utilidade prática na engenharia de software.
VOCÊ QUER VER?

O filme Caçada virtual (NEWMAN et al., 2000) é bastante interessante para compreender como atuam os
chamados os hackers éticos (ethical hacking). Este longa-metragem mostra a história real de Kevin Mitnick,
que utilizou todo o seu conhecimento em computação para entrar no sistema do FBI e acessar
documentos altamente sigilosos, tornando-se o criminoso mais procurado dos Estados Unidos na época.
Sommerville (2011, p. 108) declara que
[As ADLs] podem ser usadas como base para o desenvolvimento dirigido a
modelos. No entanto, acredito que os modelos e as notações informais, como
a UML [unified modeling language, ou seja, a linguagem de modelagem
unificada], continuarão a ser a forma mais comumente usada para
documentar arquiteturas de sistema.
Portanto, para atender à necessidade de usar a ADL, foram criadas linguagens como:
ADAGE: permite a criação de frameworks para sistemas de aviação;

CE: possibilita a descrição de sistemas de interface com o usuário usando
um estilo baseado em mensagens;
Rapide: admite a simulação e a análise de diferentes soluções
arquiteturais;
UniCOn: possui um compilador de alto nível com suporte para diferentes
tipos de componentes e conectores.
2.3 Verificação de conformidade da

arquitetura
Após a explanação das arquiteturas específicas para ambiente web e dispositivos
móveis, podemos questionar: como é possível verificar a conformidade de uma
arquitetura de software? Segundo Chagas (2016), essa verificação é importante para
o entendimento do código, o reuso e a manutenibilidade do sistema, podendo ser

feita de algumas maneiras:
manualmente;
por meio de técnicas e ferramentas, como a Matriz de Dependência
Estrutural (DSM), modelos de reflexão ou testes de design.
Porém, segundo Chagas (2016), nenhuma delas leva em consideração os diferentes

níveis de abstração para definir regras arquiteturais.
Uma das maneiras de se realizar a conformidade arquitetural é comparando o
código-fonte à visão arquitetural do sistema (forma estática) ou então verificando o
código-fonte em tempo de execução ou suas versões ao longo do tempo,
comparando-as com a visão arquitetural (forma dinâmica). A verificação de
conformidade da arquitetura avalia as dependências entre os componentes. Os
resultados da arquitetura, de acordo com Chagas (2016, p. 21, grifos do autor),
podem ser divididos em:
convergência - é uma relação entre dois componentes que é permitida e foi

implementada como pretendida. A convergência indica que a implementação
é compatível com a arquitetura planejada;
divergência - é uma relação entre dois componentes que não é permitida e
não foi implementada como pretendida. A divergência aponta que a
implementação não é compatível com o modelo arquitetural planejado;
ausência - é uma relação entre dois componentes que era pretendida, porém
não foi implementada. A ausência indica que as relações na arquitetura
planejada não foram encontradas na implementação.
Conforme descrito por Chagas (2016), alguns autores apresentam os modelos de

reflexão. Inicialmente, esta técnica tem como propósito ajudar o engenheiro a
utilizar um modelo de alto nível de um sistema existente, o qual foi aplicado nos
casos em que havia pouca ou nenhuma informação sobre o sistema e a sua
arquitetura.
VOCÊ QUER LER?

A arquitetura orientada a serviço (SOA) é considerada complexa pelos pesquisadores e pela Academia
sobre os meios para sua construção. O artigo publicado por Serman (2010) visa trazer o gerenciamento de
portfólio de projetos de software como uma opção para orientar o desenvolvimento da SOA. Quer ler
mais? Acesse: <http://www.scielo.br/pdf/jistm/v7n3/07.pdf
(http://www.scielo.br/pdf/jistm/v7n3/07.pdf)>.
Outras regras de verificação de conformidade são as restrições entre elementos

arquiteturais as quais, para Chagas (2016, p. 23), “[...] se dividem em permitir, proibir
ou impor alguma relação entre as entidades arquiteturais”. Fundamentalmente,
uma regra de relação de conformidade é integrada por um tipo de relação, um
componente de origem, um de destino e o tipo da regra de conformidade. Por outro
lado, o tipo de regra de conformidade determina se a relação entre os componentes
é proibida ou se deve, obrigatoriamente, existir entre os componentes.
2.4 Projeto de componentes

Após a aplicação da orientação a objetos no desenvolvimento de sistemas, houve
pouco reuso do código. Definimos, portanto, que os componentes são abstrações
de nível mais alto do que objetos e são definidos por suas interfaces. Geralmente,
eles são maiores que objetos individuais e todos os detalhes de implementação são
escondidos de outros componentes, conforme citado por Sommerville (2011, p.
315):
a engenharia de software baseada em componentes (CBSE, do inglês

component-based software engineering) surgiu na década de 1990 como uma
abordagem para softwares de desenvolvimento de sistemas com base no reuso
de componentes de softwares.
Utilizamos o termo componente, portanto, para nos referir a trechos do código-

fonte, como funções, estruturas de dados e classes. Existem outras definições para
eles, como instâncias de classes de um programa que podem ser utilizadas por
outras instâncias. Além disso, podemos denominá-los como sendo as bibliotecas de

funções e bibliotecas de ligação dinâmica.
Sommerville (2011, p. 316) enumera que
os fundamentos da engenharia de software baseada em componentes são:
1. Os componentes independentes que são completamente especificados

por suas interfaces. [...]
2. Os padrões de componentes que facilitam a integração destes. [...]
3. O middleware que fornece suporte de software para a integração de
componentes. [...]
4. Um processo de desenvolvimento que é voltado para a engenharia de
software baseada em componentes. [...]
Portanto, quando desenvolvemos sistemas baseados em componentes,

apropriamos as boas práticas da engenharia de software. Essa engenharia baseada
em componentes, conforme demonstrado por Sommerville (2011, p. 316), apoia-se
em um dos princípios de projeto na construção de softwares compreensíveis e
passíveis de manutenção:
1. Componentes são independentes, então eles não interferem na operação

uns dos outros. Detalhes de implementação são ocultados. Implementação
dos componentes pode ser alterada sem afetar o restante do sistema.
2. Os componentes comunicam-se por meio de interfaces bem definidas. Se
essas interfaces forem mantidas, um componente poderá ser substituído por
outro, que forneça funcionalidade adicional ou aumentada.
3. As infraestruturas dos componentes oferecem uma gama de serviços-
padrão que podem ser usados em sistemas de aplicações, o que reduz a
quantidade de códigos novos a serem desenvolvidos.
Segundo Sommerville (2011), o componente físico existe para o sistema

operacional e para outras ferramentas do sistema, sendo que ele pode ser
armazenado ou transferido. Por outro lado, o componente lógico possui uma
utilidade para o funcionamento do programa. O componente de tempo-de-
desenvolvimento é utilizado durante o desenvolvimento do software, enquanto o
componente de tempo-de-execução é quando está pronto para ser executado pelo

sistema.
Para Sommerville (2011, p. 317), os componentes têm as seguintes características:
Quadro 1 - Relação dos componentes e as descrições relativas às suas características. Fonte: SOMMERVILLE,
2011, p. 317.
#PraCegoVer: Ilustra por meio de uma tabela, a relação dos componentes e as

descrições relativas às suas características. A tabela contém as colunas
características do componente e descrição. As linhas da coluna características do
componente são: Padronizado, Independente, Passível de Composição, implacável
e, Documentado. A descrição de Padronizado, é: a padronização de componentes

significa que um componente usado em um processo CBSE precisa obedecer a um
modelo de componente padrão. Esse modelo pode definir as interfaces de
componentes, metadados de componente, documentação, composição e
implementação. A descrição de Independente é: Um componente deve ser
independente, deve ser possível compor e implementá-lo sem precisar usar outros
componentes específicos. Nessas situações, em que o componente preciso dos
serviços prestados externamente, estes devem ser explicitamente definidos em uma
especificação de interface ‘requires’. A descrição de Passível de composição é: Para
um componente ser composto, todas as interações externas devem ter lugar por
meio de interfaces publicamente definidas. Além disso, ele deve proporcionar
acesso externo a informações sobre si próprio, como seus métodos e atributos. A
descrição de Implantável, é: para ser implantável, um componente deve ser
autocontido. Deve ser capaz de operar como uma entidade autônoma em uma
plataforma de componentes que que forneça uma implementação do modelo de
componentes, o que geralmente significa que o componente é binário e não tem
como ser compilado antes de ser implantado. Se um componente é implantado
como um serviço, ele não precisa ser implantado por um usuário de um
componente. Pelo contrário, é implantado pelo prestador do serviço. A descrição de
Documentado, é: Os componentes devem ser completamente documentados para
que os potenciais usuários possam decidir se satisfazem a suas necessidades. A
sintaxe e, idealmente, a semântica de todas as interfaces de componentes deve ser
especificada.
Portanto, existem diversas formas de compreendermos o que é um componente.

Uma delas é como se ele fosse um provedor de serviços. Quer dizer, quando um
sistema precisa de um serviço, é chamado um componente para que seja ofertado o
serviço. Não é necessário preocupar onde ele está sendo executado ou em que
linguagem foi desenvolvido.
CASO
Uma universidade de grande porte estava reorganizando o seu portal web, que já se encontrava em
um formato obsoleto. Foram propostas duas metodologias diferentes a serem aplicadas: uma de
design centrada no usuário e outra de design participativo. Este tipo de abordagem impactaria no
modelo de arquitetura de implantação do novo portal. O objetivo era propor uma metodologia para
a reestruturação, priorizando a organização e facilidade de uso do site. A primeira etapa foi a
realização de uma entrevista com os usuários para obter as necessidades fundamentais. O problema
é se seria adotada a metodologia orientada no perfil do usuário ou na tarefa. A metodologia
orientada ao perfil do usuário leva a uma arquitetura a um modelo no qual o foco está centrado na
interface. Por outro lado, uma metodologia orientada na tarefa faz com que a arquitetura esteja mais
centrada no modelo cliente-servidor.
Segundo Sommerville (2011, p. 318), a percepção do componente como um

provedor de serviços agrega duas características essenciais de um componente:
1. O componente é uma entidade executável independente que é definida

por suas interfaces. Para usá-lo, você não precisa de nenhum conhecimento
de seu código-fonte. Ele pode ser referenciado como um serviço externo ou
incluído diretamente em um programa.
2. Os serviços oferecidos por um componente são disponibilizados por meio
de uma interface, e todas as interações se dão por meio dessa interface. A
interface de componente é expressa em termos de operações parametrizadas
e seu estado interno nunca é exposto.
Assim, o componente tem duas interfaces que se relacionam, e elas mostram o

serviço que o componente fornece e os serviços que ele necessita. Segundo
Sommerville (2011, p. 318), “a interface ‘provides’ define os serviços prestados pelo
componente. Essa interface, essencialmente, é API de componente. Ela define os
métodos que podem ser chamados por um usuário do componente [...]”. Em um
diagrama de componentes UML (sigla para unified modeling language, isto é, a
linguagem de modelagem unificada), a interface ‘provides’ para um componente é
indicada por um círculo no fim de uma linha a partir do ícone de componente.
Na figura a seguir, demonstramos um modelo genérico de um componente e as
interfaces ‘requires’ e ‘provides’.
Figura 5 - Exemplo da representação gráfica das interfaces ‘require’ e ‘provides’ com um componente e suas
descrições. Fonte: SOMMERVILLE, 2011, p. 318.
#PraCegoVer: Ilustra um exemplo da representação gráfica das interfaces ‘require’ e

‘provides’ com um componente e suas descrições. A imagem contém um retângulo
com a inscrição componente, que conecta as interfaces ‘requires’ com interfaces
‘provides’. A interface ‘requires’ define serviços que são requeridos e que deveriam
ser fornecidos por outros componentes. A interface ‘provides’ define os serviços que
são providos pelo componente para outros componentes.
Por outro lado, Sommerville (2011, p. 318) nos diz que “a interface ‘requires’
especifica quais serviços devem ser fornecidos por outros componentes no sistema
se um componente deve funcionar corretamente. Se eles não estiverem disponíveis,
o componente não funcionará. [...]”. Isso não compromete a independência ou a
capacidade de implantação de um componente, pois a interface ‘requires’ não
define como esses serviços deverão ser prestados. Em UML, o símbolo de uma
interface ‘requires’ é um semicírculo no fim de uma linha, a partir do ícone de
componente.
Na figura a seguir, demonstraremos as interfaces ‘requires’ e ‘provides’ de um
componente coletor de dados, projetado para coletar e reunir informações a partir
de um vetor de sensores.
Figura 6 - Exemplo da representação gráfica do modelo de um componente coletor de dados. Fonte:

SOMMERVILLE, 2011, p. 319.
#PraCegoVer: Ilustra um exemplo da representação gráfica do modelo de um

componente coletor de dados. A imagem contém um retângulo que conecta as
interfaces ‘requires’ com interfaces ‘provides’. A interface ‘requires’ contém alguns
exemplos como: sensorManagement (gerência do sensor) e sensorData (dados do

sensor). A interface ‘provides’ contém alguns exemplos como: addSensor (ativar
sensor), removeSensor (remover sendor), startSensor (iniciar sensor), stopSensor (
parar sensor), testSensor (testar sensor), initialize (iniciar), report (relatório) e, listAll
(listar todos).
Para Sommerville (2011, p. 318),
ele é executado autonomamente para coletar dados durante um período e,

sob requisição, fornece dados agrupados para um componente. A interface
‘requires’ inclui métodos para adicionar, remover, iniciar, parar e testar
sensores. O método report retorna os dados do sensor que foram coletados e o
método listAll fornece informações sobre os sensores conectados.
Sommerville (2011) ainda nos informa que existe o serviço externo e um

componente como elemento de programa, mas eles são diferentes: o primeiro é
uma entidade independente, já o último pode usar esses serviços sem a
necessidade de se implementar nenhum suporte adicional exigido por eles.
VOCÊ SABIA?
Existe uma proposta de arquitetura de software baseada em data warehouse para o desenvolvimento
de sistemas distribuídos, auxiliando os desenvolvedores na utilização de arquiteturas alternativas
para sistemas específicos. Leia mais no artigo escrito por Milanez; Tait (2012), disponível em:
<http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728
(http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728)>.
Um modelo de componente significa uma definição de normas para a sua

implementação, implantação e documentação. Estas normas servem para garantir
aos desenvolvedores que os componentes podem interoperar. Para Sommerville
(2011, p. 319, grifos nossos), as informações que são necessárias para se utilizar um
componentes são:
1. Interfaces. Os componentes são definidos pela especificação de suas

interfaces. O modelo de componente especifica como as interfaces devem ser
definidas e os elementos, como nomes de operação, parâmetros e exceções,
que devem ser incluídos na definição de interface. O modelo também deve
especificar a linguagem usada para definir as interfaces de componente. [...]
2. Uso. Para que componentes sejam distribuídos e acessados remotamente,
eles precisam ter um nome exclusivo ou identificador associado a eles. Isso
deve ser globalmente exclusivo — por exemplo, no EJB, um nome hierárquico
é gerado com a raiz baseada em um nome de domínio de internet. [...]
3. Implantação. O modelo de componente inclui uma especificação de como
componentes devem ser empacotados para implantação como entidades
independentes, executáveis. Como os componentes são entidades
independentes, eles precisam ser empacotados com todos os softwares de
suporte não fornecidos pela infraestrutura de componente ou não serão
definidos em uma interface ‘requires’. [...]
Sommerville (2011) elenca os elementos básicos de um modelo ideal de

componentes, conforme demonstraremos na figura a seguir.
Figura 7 - Elementos básicos de um modelo de componentes, demonstrando suas relações e definições.

Fonte: SOMMERVILLE, 2011, p. 319.
#PraCegoVer: Ilustra os elementos básicos de um modelo de componentes,

demonstrando suas relações e definições. A imagem contém na sua base um grande
retângulo com a inscrição Modelos de Componentes. Ainda destro deste grande
retângulo, mas um pouco mais acima, existem outros três retângulos para
Interfaces, Informações de uso e, Implantação e uso. Ligados à Interfaces, há

Definição de interfaces, Composição e, Interfaces específicas. Ligados à Informações
de uso, há Convenção de Nomes, Acessos a Metadados, e Customização. Ligados à
Implantação de Uso há, Embalagem, Documentação e, Suporte à Evolução.
Por outro lado, para componentes implantados como unidades de programa, no

lugar de serviços externos, o modelo de componentes define os serviços que são
fornecidos pelo middleware. Este, por sua vez, oferece suporte para a execução dos
componentes, sendo “o software que se encontra entre o sistema operacional e os
aplicativos nele executados” (MICROSOFT AZURE, 2018). Segundo Sommerville
(2011, p. 320, grifos nossos), podemos dividir os serviços fornecidos por uma
implementação de modelo de componente em duas categorias:
1. Serviços de plataforma, que permitem aos componentes se comunicarem

e interagirem em um ambiente distribuído. Esses são os serviços
fundamentais que devem estar disponíveis em todos os sistemas baseados
em componentes.
2. Serviços de suporte, que são serviços comuns, suscetíveis de serem
requeridos por muitos componentes diferentes. Por exemplo, muitos
componentes requerem autenticação para garantir que o usuário dos
serviços de componente seja autorizado.
Na figura a seguir, demonstraremos como acontecem esses serviços.
Figura 8 - Serviços de middleware definidos em um modelo de componente, demonstrando suas relações.

Fonte: SOMMERVILLE, 2011, p. 320.
#PraCegoVer: Ilustra os Serviços de middleware definidos em um modelo de

componente, demonstrando suas relações. A imagem define os itens contidos em
Serviço de Suporte e Serviços de Plataforma. O Serviço de Suporte é composto por:
gerenciamento de componentes, gerenciamento de transações, gerenciamento de
recursos, concorrência, persistência e, proteção. Os Serviços de Plataforma é
composto por: endereçamento, definição de interfaces, gerenciamento de exceções
e, comunicações de componentes.
Por fim, o middleware tem como responsabilidade implementar os serviços dos

componentes e fornecer a interface para eles. Para fazer o uso dos serviços previstos
por uma infraestrutura de modelo de componentes, podemos entender os
componentes para serem implantados em um contêiner. Assim, um contêiner
implementa os serviços de suporte, adicionando uma definição das interfaces que
um componente deve fornecer para integrá-lo com o contêiner.
Síntese
Concluímos este capítulo compreendendo como as arquiteturas de software se
adaptam e se modelam às novas tecnologias de sistemas, como ambiente web e
dispositivos móveis. Vimos que existem alternativas para a criação de arquiteturas
dependendo da aplicação e do ambiente de negócios no qual ele está inserido.
Essas arquiteturas devem se acoplar aos modelos, e não existe uma regra rígida,
mas sim um bom senso na criação e definição das linguagens, dos modelos e das
características dos sistemas.
Neste capítulo, você teve a oportunidade de:
compreender o processo de elaboração de projetos para uma aplicação
web;
elaborar projetos para uma aplicação em dispositivos móveis;
entender como avaliar as alternativas existentes para os diversos modelos;
compreender a aplicação da linguagem de descrição de arquitetura;
verificar a conformidade de uma arquitetura de software;
compreender como elaboramos os projetos de componentes.
Bibliografia
CHAGAS, F. B. Checagem de conformidade arquitetural na modernização
orientada a arquitetura. 81 f. 2016. Dissertação (Mestrado em Ciência da
Computação), Centro de Ciências Exatas e de Tecnologia, Programa de Pós-
Graduação em Ciências da Computação, Universidade Federal de São Carlos. São
Carlos: UFSCar, 2016. Disponível em:
<https://repositorio.ufscar.br/bitstream/handle/ufscar/8392/DissFBC.pdf?
sequence=1&isAllowed=y
(https://repositorio.ufscar.br/bitstream/handle/ufscar/8392/DissFBC.pdf?
sequence=1&isAllowed=y)>. Acesso em: 23/5/2018.
FONSECA FILHO, C. História da computação: o caminho do pensamento e da
tecnologia. Porto Alegre: PUC-RS, 2007.
GARLAN, D.; SHAW, M. An introduction to software architecture. New Jersey:
World Scientific Publishing Company, 1994.
JÚNIOR, E. A. O.; FORTES, R. P. M. Arquitetura de software na web atual:
processamento no servidor. Instituto de Ciências Matemáticas e de Computação
(ICMC), Universidade de São Paulo (USP), São Carlos, 2007. Disponível em:
<http://conteudo.icmc.usp.br/CMS/Arquivos/arquivos_enviados/BIBLIOTECA_113_N
D_78.pdf
(http://conteudo.icmc.usp.br/CMS/Arquivos/arquivos_enviados/BIBLIOTECA_113_N
D_78.pdf)>. Acesso em: 22/5/2018.
KIKOT, T.; FERNANDES, S.; COSTA, G. Potencial da aprendizagem baseada-em-jogos:
um caso de estudo na Universidade do Algarve. Revista Ibérica de Sistemas e
Tecnologias de Informação, Rio Tinto, n. 16, ano 3, p. 17-29, dez. 2015. Disponível
em: <http://www.scielo.mec.pt/pdf/rist/n16/n16a03.pdf
(http://www.scielo.mec.pt/pdf/rist/n16/n16a03.pdf)>. Acesso em: 23/5/2018.
LEE, V. Aplicações móveis: arquitetura, projeto e desenvolvimento. São Paulo:
Pearson Education do Brasil, 2005.
MICROSOFT AZURE. O que é middleware? Microsoft, 2018. Disponível em:
<https://azure.microsoft.com/pt-br/overview/what-is-middleware
(https://azure.microsoft.com/pt-br/overview/what-is-middleware)>. Acesso em:
23/5/2018.
MILANEZ, C. A.; TAIT, T. F. C. Uma arquitetura de data warehouse para apoio à gestão
de projetos em desenvolvimento distribuído de software. Revista
Eletrônica de Sistemas de Informação, Curitiba, v. 11, n. 1, p. 1-17, jan./jun. 2012.
Disponível em:
<http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728/pdf
(http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728/pdf)>.
Acesso em: 23/5/2018.
MILANEZ, C. A.; TAIT, T. F. C. Uma arquitetura de data warehouse para apoio à gestão
de projetos em desenvolvimento distribuído de software. Revista
Eletrônica de Sistemas de Informação, Curitiba, v. 11, n. 1, p. 1-17, jan./jun. 2012.
Disponível em:
<http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728/pdf>
(http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728/pdf>).
Acesso em: 23/5/2018.
PILAR, C. P. Avaliação das arquiteturas de desenvolvimento para dispositivos
móveis. 89 f. 2013. Monografia (Trabalho de Conclusão de Curso em Sistemas de
Informação), Centro de Computação e Tecnologia da Informação, Universidade de
Caxias do Sul. Caxias do Sul: UCS, 2013. Disponível em:
<https://repositorio.ucs.br/xmlui/bitstream/handle/11338/1245/TCC%20Carina%20
Ponzoni%20Pilar.pdf?sequence=1&isAllowed=y
(https://repositorio.ucs.br/xmlui/bitstream/handle/11338/1245/TCC%20Carina%20
Ponzoni%20Pilar.pdf?sequence=1&isAllowed=y)>. Acesso em: 23/5/2018.
PRESSMAN, R. Engenharia de software: uma abordagem profissional. 8. ed. Porto
Alegre: McGraw Hill, 2016.
SERMAN, D. V. Orientação a projetos: uma proposta de desenvolvimento de uma
arquitetura orientada a serviços. Journal of Information Systems and Technology
Management (JISTEM), São Paulo, v. 7, n. 3, p. 619-638, 2010. Disponível em:
<http://www.scielo.br/pdf/jistm/v7n3/07.pdf
(http://www.scielo.br/pdf/jistm/v7n3/07.pdf)>. Acesso em: 23/5/2018.
SILVA FILHO, A. M. Desenvolvimento de software requer processo e gestão. Revista
Espaço Acadêmico, Maringá, UEM, v. 11, n. 123, p. 46-57, ago. 2011. Disponível em:
<http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/14312/759
3
(http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/14312/7593
)>. Acesso em: 23/5/2018.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall,
2011.

Arquitetura de Software

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Arquitetura de Software

Enviado por

Direitos autorais:

Formatos disponíveis

21/03/2023, 20:15 Arquitetura de Software

2.1 Projeto de arquitetura para

2.1.1 Projeto de arquitetura para aplicações web

Antes de tudo, é importante ressaltarmos a importância da aplicação de arquitetura

1. Cada vez mais, indivíduos e sociedades dependem dos sistemas de

A vantagem deste padrão de arquitetura é a permissão de os dados serem alterados

#PraCegoVer: Ilustra o modelo MVC demonstrando a relação entre o Modelo, a

Vimos, na figura anterior, que o componente Visão envia um determinado evento

#PraCegoVer: Ilustra um exemplo de interação entre os componentes do padrão

Outro tipo de padrão de arquitetura largamente utilizado é a arquitetura em 3

em módulos independentes e cada um é atualizado, independentemente da

camada de apresentação: contém toda a interface gráfica e permite a

Apresentaremos, a seguir, uma ilustração gráfica da arquitetura em três camadas, na

Figura 3 - Exemplo de interação entre os componentes do padrão de arquitetura em 3 camadas e suas

#PraCegoVer: Ilustra um exemplo de interação entre os componentes do padrão de

para a camada lógica e para a camada de apresentação. Na imagem existe também

É possível fazermos uma comparação entre os modelos de arquitetura MVC e em 3

arquitetura MVC: tem um comportamento de forma triangular, sendo

2.1.2 Projeto de arquitetura para dispositivos móveis

a publicação da aplicação é independente dos serviços remotos;

Por outro lado, suas desvantagens são:

o desenvolvimento das funcionalidades pode ser dispendioso;

o desenvolvimento de softwares para dispositivos móveis é mais complexo do

Seguindo as características que mencionamos anteriormente, elas mostram os

VOCÊ QUER LER?

Lee (2005) apresenta uma arquitetura específica para o desenvolvimento dos

#PraCegoVer: Ilustra um exemplo de arquitetura para aplicativos móveis com as

Os itens da figura anterior são divididos e conceituados da seguinte forma, segundo

mobilidade: as aplicações móveis deverão seguir esta principal característica

Ao desenvolvermos aplicativos para dispositivos móveis, pode ser necessária a

camada de aplicação: camada que está no topo do desenvolvimento da

Vários questionamentos podem influenciar na escolha de qual arquitetura devemos

2.2 Avaliação das alternativas do

aplicativo nativo: tem como característica ser desenvolvido para uma

Existem arquiteturas de software específicas para a construção e integração de ambientes virtuais de

No próximo item, abordaremos a questão da architecture description language

2.2.1 Linguagem de descrição da arquitetura (ADL)

No entanto, devido à sua natureza especializada, autores como Sommerville (2011)

VOCÊ QUER VER?

Sommerville (2011, p. 108) declara que

ADAGE: permite a criação de frameworks para sistemas de aviação;

2.3 Verificação de conformidade da

o entendimento do código, o reuso e a manutenibilidade do sistema, podendo ser

Porém, segundo Chagas (2016), nenhuma delas leva em consideração os diferentes

convergência - é uma relação entre dois componentes que é permitida e foi

Conforme descrito por Chagas (2016), alguns autores apresentam os modelos de

VOCÊ QUER LER?

Outras regras de verificação de conformidade são as restrições entre elementos

2.4 Projeto de componentes

a engenharia de software baseada em componentes (CBSE, do inglês

Utilizamos o termo componente, portanto, para nos referir a trechos do código-

outras instâncias. Além disso, podemos denominá-los como sendo as bibliotecas de

os fundamentos da engenharia de software baseada em componentes são:

1. Os componentes independentes que são completamente especificados

Portanto, quando desenvolvemos sistemas baseados em componentes,

1. Componentes são independentes, então eles não interferem na operação

Segundo Sommerville (2011), o componente físico existe para o sistema

componente de tempo-de-execução é quando está pronto para ser executado pelo

#PraCegoVer: Ilustra por meio de uma tabela, a relação dos componentes e as

e, Documentado. A descrição de Padronizado, é: a padronização de componentes

Portanto, existem diversas formas de compreendermos o que é um componente.

Segundo Sommerville (2011, p. 318), a percepção do componente como um

1. O componente é uma entidade executável independente que é definida