06 Arquitetura de Software

Prévia do material em texto

- -1
ARQUITETURA DE SOFTWARE
CAPÍTULO 1 - QUAIS SÃO OS FUNDAMENTOS 
E CONCEITOS BÁSICOS DA ARQUITETURA 
DE ?SOFTWARE
Fernando Skackauskas Dias
- -2
Introdução
A complexidade dos sistemas de tem aumentado consideravelmente nas últimas décadas devido àsoftware 
inclusão de novas interfaces, integração de várias mídias e novas tecnologias de armazenamento e distribuição
de dados. Nesse sentido, os engenheiros de têm utilizado novas abordagens, a fim de desenvolversoftware 
sistemas com alto desempenho. Portanto, desenvolver com qualidade é uma questão que temsoftwares 
merecido a devida atenção dos cientistas da computação.
Assim, podemos nos questionar: qual o papel da arquitetura de ? Quais são os modelos de arquitetura?software
Como a implantação de um modelo de arquitetura de pode melhorar a qualidade dos sistemas desoftware 
informação?
Antes de responder a essas questões, é importante relembrarmos que a arquitetura de é considerada asoftware 
área de conhecimento da Ciência da Computação na qual são aplicadas práticas da engenharia de e dasoftware 
gerência de projetos, procurando obter melhor organização dos sistemas e com alta produtividade. São nas
bases dessas disciplinas é que encontramos os modelos para especificar, projetar, implantar e manter sistemas
com qualidade.
Iniciaremos esta disciplina analisando os princípios de arquitetura de com a demonstração das fases desoftware 
desenvolvimento de um projeto arquitetural e a descrição dos elementos pertinentes à arquitetura e os padrões
arquiteturais básicos. A seguir, explicaremos os tipos de modelagem e a utilização dos diferentes estilos, padrões
e gêneros na especificação da arquitetura de . Por fim, analisaremos os impactos das decisões do tipo desoftware
arquitetura no desempenho de um sistema.
Desejamos um excelente estudo.
1.1 Introdução à arquitetura de software
Você sabe qual o propósito da arquitetura de ? Segundo Galloti (2016, p. 3), é o de “criar soluções [...]software
cada vez mais simples, rápidas e eficientes”. Além do exposto pelo autor, devemos ir além, ou seja, não somente
resolver problemas, mas também a ocorrência deles e as soluções já existentes.prevenir aperfeiçoar
A história recente da Ciência da Computação mostra a evolução das técnicas e dos métodos de desenvolvimento
de sistemas, passando pela programação estruturada, orientada a evento até a orientação a objeto, assim como a
evolução da lógica dos algoritmos e da estrutura de dados.
Diante da complexidade dos sistemas atuais, é inevitável que tenhamos estilos de arquitetura acompanhando tal
evolução. É necessário ter um conhecimento bastante sólido dos fundamentos e conceitos básicos da arquitetura
de para compreender a evolução dos sistemas de informação e a estruturação lógica e abstrata deles,software
além de desenvolvê-los com confiabilidade e alta qualidade.
1.1.1 Conceitos introdutórios de arquitetura de software
Qual o sentido fundamental de arquitetura de ? Para Galloti (2016, p. 10), ela “[...] explica a forma comosoftware
[ele] se organiza e funciona, além de seu modo de implementação”. Portanto, agrega os componentes
denominados elementos arquiteturais (dados, processamentos e conexão), que se organizam de maneira lógica
para atender aos requisitos funcionais e não funcionais. Para tal, a arquitetura de deve ser clara, a fimsoftware 
de atingir o máximo da simplicidade, tendo o as seguintes características:software 
• : deve permitir as mudanças que se façam necessárias em decorrência das alterações de flexível
requisitos;
• extensível: deve ter a capacidade de incorporar novos elementos, permitindo que a estrutura do 
sistema como um todo se estenda;
• portabilidade: permite que ele seja executado em mais de uma plataforma;
•
•
•
- -3
• portabilidade: permite que ele seja executado em mais de uma plataforma;
• reutilizável: é possível adaptar componentes de um para outro.software 
O é o primeiro passo no processo de implantação de um modelo de arquitetura de projeto de arquitetura
: ele a conecta com a – esta última é o processo que elabora os documentossoftware engenharia de requisitos
dos requisitos funcionais e não funcionais durante todo o ciclo de vida do sistema. É nesta parte do processo que
são identificados os componentes estruturais e os seus relacionamentos.
A arquitetura de se altera na mesma medida em que ele evolui e se ajusta às novas demandas esoftware
evoluções tecnológicas. Portanto, ela é parte integrante da , que é uma abordagemengenharia de software
sistemática e formal de desenvolvimento dos sistemas de informação.
Essas características fazem parte dos , ou seja, é o conjunto de atributos que se espera dequesitos de qualidade
um de alto desempenho. Podemos detalhá-las no quadro a seguir, segundo Sommerville (2011, p. 5).software
Quadro 1 - Atributos essenciais de qualidade de um software, sendo parte integrante da elaboração da 
arquitetura de um sistema de informação.
Fonte: SOMMERVILLE, 2011, p. 5.
Estas características terão maior ou menor relevância dependendo do propósito do e do contexto nosoftware
qual ele está inserido. Por exemplo, de transações informacionais básicas (como, por exemplo, umsoftwares
sistema de cadastro de clientes de uma loja) terão atributos de qualidade diferentes de sistemas mais complexos
como, por exemplo, um de controle de uma fábrica. No primeiro caso, o foco do sistema estará maissoftware
atrelado à interface do cliente, e fatores como usabilidade e acessibilidade serão mais críticos. Por outro lado,
nos sistemas de controle industrial, por exemplo, os atributos de confiança e proteção serão mais críticos devido
à natureza e finalidade deste sistema.
Nesse sentido, existem abordagens para que os sejam tipificados conforme sua e softwares aplicabilidade
, sendo fundamentais ao construirmos o projeto de arquitetura de um sistema, pois estes fatoresnatureza
impactam quando modelamos o desenho dos componentes e suas relações com o fluxo de dados nos quais
haverá alguma interação.
Como explicamos, as abordagens de desenvolvimento variam conforme o objetivo do sistema e o ambiente no
•
•
- -4
Como explicamos, as abordagens de desenvolvimento variam conforme o objetivo do sistema e o ambiente no
qual ele é desenvolvido. O fator mais importante para determinar quais são as técnicas e os métodos de
engenharia de é o que, segundo Sommerville (2011, p. 7, grifos nossos), podem sersoftware tipo de aplicação
identificados como:
• Aplicações stand-alone. Essas são as aplicações executadas em um computador local, como
um PC. Elas contêm toda a funcionalidade necessária e não precisam estar conectadas a uma
rede.
• Aplicações interativas baseadas em transações. São aplicações que executam em um
computador remoto, acessadas pelos usuários a partir de seus computadores ou terminais.
Certamente, aqui são incluídas aplicações como aplicações de comércio.Web 
• Sistemas de controle embutidos. São sistemas de controle que controlam e gerenciam
dispositivos de . Exemplos de sistemas embutidos é o em telefone celularhardware software 
ou que controlam antitravamento de freios em um carro.
• Sistemas de processamento de lotes. São sistemas corporativos projetados para processar
dados em grandes lotes. Exemplos de sistemas de lotes incluem sistemas periódicos de
cobrança, como sistemas de cobrança telefônica, e sistemas de pagamentos de salário.
• Sistemas de entretenimento. São sistemas cuja utilização principal é pessoal e cujo
objetivo é entreter o usuário.
• Sistemas para modelagem e simulação. São sistemas que incluem vários objetos
separados que interagem entre si, desenvolvidos por cientistas e engenheiros para modelar
processos ou situações físicas.
• Sistemas de coleta de dados. São sistemas que coletam dados de seu ambiente com um
conjunto de sensores e enviam esses dados para outros sistemas para processamento.
• Sistemas de sistemas. São sistemas compostos de uma série de outros sistemas de software
. Alguns deles podem ser produtos genéricos de, como um programa de planilhasoftware
eletrônica.
Tendo como base as tipificações definidas anteriormente, é necessário definir como são classificados os modelos
de processo de desenvolvimento de , isto é, a representação, de forma simplificada, de um determinadosoftware
processo específico. Segundo Sommerville (2011, p. 20, grifos nossos), os modelos são englobados em três tipos:
• em cascata. Este modelo determina as atividades principais do processo de especificação,
desenvolvimento, validação e evolução, sendo que cada uma das partes do modelo são
consideradas fases distintas.
• desenvolvimento incremental. Este modelo integra as atividades de especificação,
desenvolvimento e validação, porém é desenvolvido como sendo uma série de versões - ou
incrementos - sendo que cada versão agrega novas funcionalidades à versão anterior.
• engenharia de orientada a reusosoftware . Esta abordagem considera um número
considerável de componentes reusáveis.
A partir das tipificações de sistemas e dos modelos de processo de desenvolvimento, são definidos os eníveis
aquilo que é considerado a da arquitetura de – esta, segundo Sommerville (2011, p.decomposição software
104), é necessária para organizar e estruturar a especificação da arquitetura do sistema, sendo útil no momento
em que se realiza o levantamento dos requisitos junto aos envolvidos no desenvolvimento do sistema. Podemos
projetar a arquitetura de em dois níveis de abstração, segundo Sommerville (2011, p. 104, grifossoftware
nossos):
• A arquitetura em está preocupada com a arquitetura de programaspequena escala
•
•
•
•
•
•
•
•
•
•
•
•
- -5
• A arquitetura em está preocupada com a arquitetura de programaspequena escala
individuais. Nesse nível, estamos preocupados com a maneira como um programa individual
é decomposto em componentes.
• A arquitetura em preocupa-se com a arquitetura de sistemas corporativosgrande escala
complexos que incluem outros sistemas, programas e componentes de programas. Esses
sistemas empresariais estão distribuídos por diversos computadores, que podem pertencer e
ser geridos por diferentes empresas
Desenhar a arquitetura de é fundamental, portanto, para o de um sistema, poissoftware desenvolvimento
integra o desempenho, a robustez e a capacidade do sistema de sua manutenibilidade.
As arquiteturas de geralmente são modeladas usando simples, nos quais cadasoftware diagramas de blocos
caixa representa um componente. Quando são representadas caixas dentro de caixas significa que o componente
foi decomposto em subcomponentes. Por outro lado, as setas indicam que os dados são passados de um
componente ao outro. Um exemplo de representação de uma arquitetura de utilizando diagrama desoftware
blocos é representado na figura a seguir, que elabora um controle robotizado de empacotamento.
•
•
VOCÊ QUER LER?
Existem arquiteturas de com diversas abordagens, inclusive as que são orientadassoftwares
para a avaliação do processo de ensino-aprendizagem de forma contínua. Esta, inclusive, é
bastante criativa e interessante, e foi desenvolvida em uma pesquisa feita pelos autores Cunha;
Filgueira; Viana (2017). Leia mais em: <www2.ifrn.edu.br/ojs/index.php/HOLOS/article
>./download/5335/pdf
http://www2.ifrn.edu.br/ojs/index.php/HOLOS/article/download/5335/pdf
http://www2.ifrn.edu.br/ojs/index.php/HOLOS/article/download/5335/pdf
- -6
Figura 1 - Arquitetura de um sistema de controle robotizado de empacotamento, indicando os componentes, os 
subcomponentes e a transação de dados.
Fonte: Elaborada pelo autor, adaptado de SOMMERVILLE, 2011.
Os diagramas de blocos representam a arquitetura de um e apresentam uma visão de alto nível dasoftware
estrutura do sistema, sendo que os usuários de diferentes áreas que estão envolvidos no processo de
desenvolvimento podem compreender a organização dos componentes, suas relações e a transação de dados.
1.1.2 Descrições de arquitetura
Quais são as visões e descrições que são necessárias ao se projetar uma arquitetura de sistema? Quais notações
devem ser usadas com o objetivo de se descrever os modelos de arquitetura? É necessário considerar que é
impossível representar todas as informações relevantes da arquitetura de em um único modelo, porquesoftware
cada modelo representa uma perspectiva do sistema. Portanto, são necessários vários deles para conceber a
arquitetura na sua totalidade. Os autores da área de arquitetura e engenharia de propõem que devemossoftware
ter fundamentais, as quais, segundo Sommerville (2011, p. 107, grifos nossos), são:quatro visões 
• lógica, que mostra as abstrações fundamentais do sistema como objetos ou classes de
objetos. Nessa visão, deveria ser possível relacionar os requisitos de sistema com as
entidades.
• de processo, que mostra como, no tempo de execução, o sistema é composto de processos
interativos. Essa visão é útil para fazer julgamentos sobre as características não funcionais do
sistema, como desempenho e disponibilidade.
• de desenvolvimento, que mostra como o é decomposto para o desenvolvimento,software 
ou seja, apresenta a distribuição do em componentes que são implementados porsoftware 
um único desenvolvedor ou por uma equipe de desenvolvimento. Essa visão é útil para
gerentes de e programadores.software 
• física, que mostra o do sistema e como os componentes de sãohardware software 
•
•
•
•
- -7
• física, que mostra o do sistema e como os componentes de sãohardware software 
distribuídos entre os processadores. Essa visão é útil para os engenheiros de sistemas que
estão planejando uma implantação do sistema.
Hofmeister; Nord; Soni (2000) argumentam que é necessário, também, incluir uma , pois elavisão conceitual
pode servir como uma decomposição dos requisitos de um nível mais alto para um mais detalhado. Essa
ferramenta é fundamental para a administração da complexidade do sistema, porque pode esconder detalhes,
permitindo que os desenvolvedores se concentrem no nível de abstrações do sistema.
Uma das possíveis visões que podem servir de referência para a construção da arquitetura de um sistema é a 
( ), uma linguagem de modelagem que serve para definir artefatos que auxiliamUnified Modeling Language UML
na tarefa de desenhar e documentar os sistemas, sendo composta por que compõem adiversos diagramas
estrutura do projeto de arquitetura do sistema. Segundo Galloti (2016, p. 81, grifos nossos), os diagramas UML
são de:
• Caso de Uso. Este diagrama define o grupo de comportamentos no alto nível do sistema e
como deve ser executado para um determinado ator.
• Classes. Este diagrama representa a coleção de classes e define seus inter-relacionamentos.
• Objetos. Este diagrama visa mostrar em forma de um retrato os objetos do e seussoftware 
inter-relacionamentos.
• Colaboração. Este diagrama figura uma coleção de objetos que trabalham conjuntamente
para atender o comportamento do sistema.
• Sequência. Representa uma perspectiva que é orientada por tempo, da colaboração
existente entre os objetos.
• Atividades. Este diagrama mostra o fluxo das tarefas que são executadas pelo sistema ou
por um determinado ator.
• Estados. Este diagrama mostra um conjunto de estados de um objeto pode ter e os ‘gatilhos’
que fazem a transição do objeto de um determinado estado para outro.
• Componentes. Representa uma coleção de componentes pertinentes ao sistema e seus inter-
relacionamentos.
• Depuração. Este diagrama mostra um conjunto de componentes e como eles são
distribuídos nos nós de .hardware
• Pacotes. Mostra uma coleção de outros possíveis elementos de modelagem ou de diagramas.
Alguns autores têm opiniões divergentes pelo uso da UML para a construção da arquitetura de , pois àssoftware
vezes ela é usada de forma inadequada para demonstrar o comportamento dos componentes do sistema e suas
relações. Sua utilização – ou não – dependerá do nível de experiência do desenvolvedor e da complexidade do
•
VOCÊ SABIA?
A internet das coisas é uma revolução tecnológica recente que tem como objetivoconectar os
itens – ou seja, as coisas – utilizados no dia a dia com a internet. Cagnin (2015) desenvolveu
sua dissertação propondo uma arquitetura de denominada de “Uma arquiteturasoftware
multiagente para o gerenciamento de dispositivos em ambientes da internet das coisas”. Veja
mais em: <http://www.athena.biblioteca.unesp.br/exlibris/bd/cathedra/02-08-2017
>./000868971.pdf
•
•
•
•
•
•
•
•
•
•
http://www.athena.biblioteca.unesp.br/exlibris/bd/cathedra/02-08-2017/000868971.pdf
http://www.athena.biblioteca.unesp.br/exlibris/bd/cathedra/02-08-2017/000868971.pdf
- -8
relações. Sua utilização – ou não – dependerá do nível de experiência do desenvolvedor e da complexidade do
sistema que se está implementando. Por outro lado, vários pesquisadores indicam o uso de linguagens de
descrição de arquitetura ( , as ) para apresentá-la. Os elementosArchitectural Description Languages ADLs
fundamentais das ADLs são os e , que agregam regras e diretrizes para a arquiteturacomponentes conectores
do sistema.
1.2 Gêneros e estilos de arquitetura
Podemos conceituar o projeto de arquitetura, segundo Sommerville (2011, p. 105), como “[...] um processo
criativo no qual você projeta uma organização de sistema para satisfazer aos requisitos funcionais e não
funcionais de um sistema”. Baseando-nos na afirmativa do autor, podemos perguntar: existe uma arquitetura
genérica que pode atuar como um modelo para o sistema que está sendo projetado? Quais gêneros ou estilos de
arquitetura podem ser usados?
O que temos é que, durante o de arquitetura, os desenvolvedores precisam tomar váriasprocesso de projeto 
decisões estruturais que podem afetar de forma significativa o sistema e todo o seu processo de
desenvolvimento. Segundo Sommerville (2011, p. 106), “um padrão de arquitetura é uma descrição abstrata de
boas práticas vivenciadas e testadas em diferentes ambientes e sistemas”, logo ele deve descrever a organização
de um sistema que foi bem-sucedida e incluir informações de quando o uso desse padrão é adequado, incluindo
os pontos fortes e fracos. A seguir, descreveremos os padrões existentes na arquitetura de comsoftware
exemplos e situações em que são utilizados, bem como suas vantagens e desvantagens.
A arquitetura de um pode ser baseada em um determinado padrão ou estilo. Um software padrão de
 significa como o é organizado: por exemplo, existe o padrão de organização cliente-arquitetura software
servidor e um padrão de arquitetura em camadas. Esses padrões mostram o objetivo de uma arquitetura que foi
utilizada em sistemas de diferenciados. Nesse sentido, o desenvolvedor, ao tomar decisões sobre qual asoftware
arquitetura de um sistema, deve conhecer os padrões mais comuns e saber onde eles podem ser usados e quais
são seus prós e contras.
É necessário que o desenvolvedor saiba escolher a estrutura que mais se adequa às necessidades do sistema a
ser desenvolvido, como a arquitetura cliente-servidor ou a em camadas, que seja capaz de permitir o
atingimento dos . Para que se decomponham em unidades estruturais do sistema, orequisitos do sistema
desenvolvedor deverá decidir sobre qual a estratégia utilizada para a decomposição de componentes em seus
subcomponentes. As abordagens que podem ser usadas devem permitir a implantação de tipos distintos de
arquitetura.
Por fim, ao chegar ao processo de modelagem de controle, é necessário tomar decisões sobre como a execução
 do sistema é controlada. Ou seja, se desenvolve um modelo de visão mais alta dosdos componentes
relacionamentos de controle entre as diversas unidades do sistema. Segundo Sommerville (2011, p. 106, grifos
nossos), devem ser analisados os seguintes requisitos para que se faça a escolha do :estilo de arquitetura
• Desempenho. Se o desempenho for um requisito crítico, a arquitetura deve ser projetada
para localizar as operações críticas dentro de um pequeno número de componentes.
• Proteção. Se a proteção for um requisito crítico, deve ser usada uma estrutura em camadas
para a arquitetura, com os ativos mais críticos protegidos nas camadas mais internas.
• Segurança. Se a segurança for um requisito crítico, a arquitetura deve ser concebida de
modo que as operações relacionadas com a segurança estejam localizadas em um único
componente.
• Disponibilidade. Se a disponibilidade for um requisito crítico, a arquitetura deve ser
projetada para incluir componentes redundantes.
• Manutenção. Se a manutenção for um requisito crítico, a arquitetura do sistema deve ser
•
•
•
•
•
- -9
• Manutenção. Se a manutenção for um requisito crítico, a arquitetura do sistema deve ser
projetada a partir de componentes autocontidos de baixa granularidade que podem ser
rapidamente alterados.
Para Pressman (2016), apesar de os princípios do projeto de arquitetura de se aplicarem a todos ossoftware
tipos de sistemas, o gênero ditará a abordagem específica para a estrutura que deve ser construída, isto é, uma
categoria específica no domínio de de forma geral, sendo que em cada categoria podem sersoftware
enquadradas subcategorias. Segundo Pressman (2016, p. 233, grifos nossos), podemos ter os seguintes gêneros
:de arquitetura
• Inteligência artificial – sistemas que simulam a cognição.
• Comercial e sem fins lucrativos – sistemas para operação de empreendimento.
• Comunicações – sistema para infraestrutura e gerenciamento de dados.
• Autoria de conteúdo – sistemas para controlar artefatos.
• Dispositivos – sistemas que interagem com o mundo físico.
• Esportes e entretenimento – sistemas que gerenciam eventos públicos.
• Financeiros – sistemas para gerenciar movimentações financeiras.
• Jogos – sistemas que geram experiência de entretenimento.
• Governo – sistemas que dão apoio às entidades governamentais.
• Industriais – sistemas que controlam processos físicos.
• Legais – sistemas que dão apoio jurídico.
• Médicos – sistemas de diagnóstico.
• Militar – sistemas de controle de inteligência militar.
• Sistemas operacionais – sistemas que se situam acima do .hardware
• Plataformas – sistemas que posicionam acima dos sistemas operacionais.
• Científicos – sistemas utilizados para pesquisa.
• Ferramentas – sistemas utilizados para desenvolver outros sistemas.
• Transportes – sistemas que controlam veículos.
• Serviços públicos – sistemas para oferecer serviço à sociedade.
Por outro lado, a questão de na arquitetura de descreve uma categoria de sistema: podeestilos software
englobar um conjunto de componentes que realiza uma função que é exigida, ou diversos conectores e várias
restrições que definem como os componentes interagirão. Seu objetivo é estabelecer uma estrutura única para
todos os componentes do sistema e, de acordo com Pressman (2016), eles podem ser classificados como:
• : um repositório de dados reside no centro desta arquitetura e é, arquitetura centralizada em dados
em geral, acessado por outros componentes. Observe-a na figura a seguir.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
- -10
Figura 2 - Arquitetura centralizada em dados demonstrando o depósito de dados e os softwares associados.
Fonte: Elaborada pelo autor, baseado em PRESSMAN, 2016.
• arquitetura de fluxo de dados: dados de entrada devem ser transformados por meio de uma série de 
componentes. Perceba-a na figura a seguir.
Figura 3 - Arquitetura de fluxo de dados demonstrando os filtros de dados e os tubos associados.
Fonte: Elaborada pelo autor, baseado em PRESSMAN, 2016.
• arquitetura de chamadas e retornos: permite obter dados em programa principal e subprograma. 
Atente-a na figura a seguir.
•
•
- -11
Figura 4 - Arquitetura de chamadas e retornos demonstrando o programa principal e subprogramas 
controladores e de aplicação.
Fonte: Elaborada pelo autor, baseado em PRESSMAN, 2016.
• arquitetura orientada a objetos: caracterizada pelos componentes terem os dados e as operações 
encapsulados.
• arquitetura em camadas: sua estrutura básica é definida em camadas distintas, que interagem em 
operações de forma progressiva. Observe-a na figura a seguir.•
•
- -12
Figura 5 - Arquitetura em camadas demonstrando as diversas camadas e os componentes associados a elas.
Fonte: Elaborada pelo autor, baseado em PRESSMAN, 2016.
Diante das características expostas das arquiteturas de , é possível descrevermos os software padrões
arquiteturais.
• MVC (Modelo-Visão-Controlador): considerado a base do gerenciamento de interação, separa a 
apresentação e a interação dos dados do sistema, sendo que o sistema é estruturado em três 
componentes lógicos que se comunicam entre si: o componente é responsável por o Modelo gerenciar 
sistema de dados e as operações associadas aos dados; o componente é responsável por e Visão definir 
a forma de os dados se apresentarem; o componente é responsável por gerenciar Controlador 
a interação do usuário e passá-la para a Visão e o Modelo. Geralmente, este padrão pode gerenciar 
interagir e visualizar os dados de diversas maneiras, sendo que sua vantagem é permitir que os dados 
podem ser alterados de forma independente da sua representação. Por outro lado, quando o modelo de 
dados é muito simples, pode envolver complexidade adicional desnecessária. Na figura a seguir, 
demonstraremos este modelo.
•
- -13
Figura 6 - Modelo da organização MVC com a demonstração do fluxo de ações e das mudanças de estado.
Fonte: Elaborada pelo autor, baseado em SOMMERVILLE, 2011.
• Abordagem em camadas: sustenta o desenvolvimento de um sistema de forma incremental. Quando 
uma camada é desenvolvida, alguns serviços podem ficar disponíveis para os usuários. A arquitetura 
também tem como características a e a . Se a interface ficar inalterada, uma mutabilidade portabilidade
camada pode ser substituída por outra equivalente, ou seja, quando uma camada de interfaces é alterada 
ou tem novos recursos incluídos, somente a camada adjacente é afetada. Portanto, este padrão se 
caracteriza pela organização do em camadas, cuja funcionalidade é associada a cada uma delas. software 
Desse modo, uma camada deve fornecer serviços à camada acima dela, e os níveis mais baixos de 
camadas representam os principais serviços utilizados no sistema. Sua vantagem é permitir a 
de camadas inteiras, mas, por outro lado, é difícil ter clara a separação entre as camadas e substituição 
como interagem camadas de níveis mais alto e mais baixo, impactando o desempenho geral do sistema.
•
- -14
• De repositório: tem como característica que todos os dados do sistema são gerenciados em um 
repositório central, ficando os componentes do sistema. Neste padrão, existe a acessível a todos 
vantagem de os componentes serem independentes. Mas, por outro lado, o repositório se torna um ponto 
único de falha.
• Cliente-servidor: é organizado segundo um conjunto de serviços e servidores ligados aos clientes. 
Segundo Sommerville (2011, p. 113, grifos nossos), os principais componentes deste modelo são:
• Um conjunto de que oferecem serviços a outros componentes. Exemplos deservidores 
servidores incluem: servidores de impressão que oferecem serviços de impressão; servidores
de arquivos que oferecem serviços de gerenciamento de arquivos; e um servidor de
compilação, que oferece serviços de compilação de linguagens de programação.
• Um conjunto de que podem chamar os serviços oferecidos pelos servidores. Emclientes 
geral, haverá várias instâncias de um programa cliente executando simultaneamente em
computadores diferentes.
• Uma que permite aos clientes acessar esses serviços. A maioria dos sistemas cliente-rede 
servidor é implementada como sistemas distribuídos, conectados através de protocolos de
Internet.
Esse modelo geralmente é utilizado quando os dados compartilhados precisam ser acessados de vários locais. Na
figura a seguir, demonstraremos esse modelo-padrão.
VOCÊ QUER LER?
Existe uma proposta de arquitetura de baseada no padrão em camadas e quesoftware
demonstra sua aplicação na construção e integração de ambientes virtuais de aprendizagem. A
arquitetura facilita a adição de novos módulos a estes sistemas de forma distribuída. Essa
proposta foi realizada por Sizo; Lino e Favero (2010). Leia mais em: <http://www.scielo.mec.pt
>./scielo.php?script=sci_arttext&pid=S1646-98952010000200003
•
•
•
•
•
http://www.scielo.mec.pt/scielo.php?script=sci_arttext&pid=S1646-98952010000200003
http://www.scielo.mec.pt/scielo.php?script=sci_arttext&pid=S1646-98952010000200003
- -15
Figura 7 - Modelo cliente-servidor, demonstrando a relação entre clientes, internet e serviços disponíveis.
Fonte: Elaborada pelo autor, baseado em SOMMERVILLE, 2011.
A vantagem desse modelo é a característica de por meio de uma rede, podendo estar disponíveldistribuição
para todos os clientes. Porém, cada serviço se torna um ponto de falha, tornando o desempenho imprevisível.
• Dutos e filtros: é um padrão de arquitetura no qual o processamento dos dados está organizado de 
forma que cada componente de processamento – o filtro – realize um determinado tipo de 
processamento dos dados, ou seja, os dados fluem – como um duto – de um componente para outro. Este 
tipo de arquitetura geralmente é utilizado em sistemas de , quando as entradas processamento de dados
são processadas em para gerar saídas relacionadas entre si. Sua vantagem é a etapas distintas
capacidade de do processamento dos dados ser de fácil compreensão e facilidade de suporte. Por reuso 
outro lado, o formato para a transferência dos dados deve ser acordado entre os processamentos.
1.3 Decisões sobre arquitetura
Os arquitetos de criam uma própria para coletar e analisar os requisitos e definir asoftware metodologia
arquitetura para ser utilizada no dos sistemas. Nesse sentido, são realizadas diversasdesenvolvimento
questões que deverão ser respondidas: como os usuários interagirão com o aplicativo e como ele será
implantado e gerenciado? Quais são os requisitos de qualidade do aplicativo? Como projetá-lo para que seja de
fácil manutenção? Quais são as tendências arquitetônicas que podem interferir no sistema? Podemos responder
VOCÊ SABIA?
O desenvolvimento de baseado em agentes tem como objetivo a sua aplicação emsoftware
sistemas distribuídos e visa buscar técnicas capazes de minimizar as dificuldades encontradas
nessa nova abordagem, como demonstrado no trabalho desenvolvido por Huzita; Oliveira;
Laine (2000). Veja mais a respeito em: <http://periodicos.uem.br/ojs/index.php
>./ActaSciTechnol/article/view/3131/2252
•
http://periodicos.uem.br/ojs/index.php/ActaSciTechnol/article/view/3131/2252
http://periodicos.uem.br/ojs/index.php/ActaSciTechnol/article/view/3131/2252
- -16
implantado e gerenciado? Quais são os requisitos de qualidade do aplicativo? Como projetá-lo para que seja de
fácil manutenção? Quais são as tendências arquitetônicas que podem interferir no sistema? Podemos responder
a essas questões considerando que um projeto de desenvolvido com qualidade deve atender aossoftware
requisitos do usuário sem que haja interrupções e com uma usabilidade que atenda às demandas. Essas
indagações afetam as decisões que o desenvolvedor tomará a respeito do , dos componentes, dashardware
estruturas, das plataformas, dos sistemas de gerenciamento de , entre outros recursos acoplados aosoftware
sistema e que ele deve se integrar.
Portanto, definir a arquitetura de envolve implantar uma solução estruturada que atenda ao maiorsoftware
número possível dos técnicos e operacionais e que aperfeiçoe os atributos de (comorequisitos qualidade
desempenho, segurança e capacidade de gerenciamento). Decidir sobre ela significa analisar diversas ,decisões
que devem ser baseadas em vários fatores, e cada uma, provavelmente, trará um impacto considerável sobre o
desempenho, a facilidade de manutenção e a qualidade do .software
As decisões de projeto de arquitetura incluem tanto aquelas do tipo de aplicação, distribuição do sistema e
estilos da arquitetura que deverão ser utilizados quanto as formas de a arquitetura ser documentada e avaliada.
Ou seja, além da escolha dos e a forma da , a arquiteturaengloba decisões sobrealgoritmos estrutura de dados
as que formarão o sistema, o controle, os protocolos de comunicação, a sincronização e o acesso aestruturas
dados, além da atribuição de funcionalidades aos elementos do sistema.
Outras variáveis a serem analisadas são: distribuição física dos elementos, escalabilidade, desempenho e demais
atributos de qualidade. Assim, as tomadas de decisão necessitam de uma análise profunda e detalhada dos
impactos, pois elas podem causar um em todo o projeto. impacto Assim sendo, o desenvolvedor deverá focar
nos estudos da organização de forma global do sistema e seus relacionamentos entre subsistemas e demais
componentes, utilizando ferramentas e técnicas, tais como visões gráficas e análise técnica.
CASO
Uma indústria de autopeças decidiu desenvolver internamente um sistema integrado de
manutenção da fábrica com os departamentos de compras, controle de estoque e de
contabilidade. Esse sistema é denominado de (ERP), cujoEnterprise Resource Planning
objetivo principal é ter o máximo de integração dos processos disparando eventos entre os
departamentos. Por exemplo, quando houver uma manutenção preventiva na fábrica, o
sistema já executa o controle de estoque para garantir os insumos necessários para
manutenção e dispara um evento para o departamento de compras e contabilidade, caso haja a
necessidade de se adquirir algum insumo.
Os desenvolvedores estavam analisando qual seria o estilo de arquitetura que mais se
adequaria ao modelo desse tipo sistema. Segundo os princípios analisados, as arquiteturas
centralizada em dados, de fluxo de dados, orientada a objetos e em camadas não foram
consideradas adequadas ao perfil do sistema. Concluiu-se que o estilo de chamadas e retornos
seria o que mais se acopla à proposta de um ERP, devido ao fato de que esse estilo teria um
programa principal: faria o controle de informações e procedimentos entre os outros
subprogramas e procedimentos remotos.
- -17
1.3.1 Como as decisões sobre a arquitetura afetam o desenvolvimento de 
um sistema
Você sabe dizer como decisões específicas de arquitetura podem ser feitas enquanto o sistema é implantado?
Como estas decisões impactam no desenvolvimento do sistema? O primeiro passo importante no processo de
projeto é tomar a decisão de quais de projeto que são necessários e o paramodelos nível de detalhamento
eles. Isso dependerá do que está sendo desenvolvido.tipo de sistema
A maneira de projetarmos um sistema sequencial de processamento é diferente da maneira de fazer um sistema
de tempo real – assim como a arquitetura terá modelos de projeto diferentes. Por exemplo, segundo Sommerville
(2011, p. 130, grifos nossos), quando utilizamos a (UML), geralmente utilizamos doisUnified Modeling Language
modelos de projeto:
• estruturais, os quais descrevem a estrutura estática do sistema, usando as classes de
objetos e seus relacionamentos. Relacionamentos importantes que podem ser documentados
nesse estágio são os de generalização (herança), usa/usado por, e composição.
• dinâmicos, os quais descrevem a estrutura dinâmica do sistema e mostram as interações
entre os objetos do sistema. Interações que podem ser documentadas incluem a sequência de
solicitações de serviço feitas pelos objetos e as mudanças de estado que são disparadas por
essas interações de objetos.
De modo geral, as razões que levam às decisões do projeto original de arquitetura não são registradas. Porém, é
necessário que os responsáveis pela evolução do sistema compreendam por que as decisões de projeto foram
tomadas, sendo fundamental que elas sejam .documentadas
Os impactos tomados pela decisão de determinada arquitetura compreendem que as alterações propostas
precisam ser muito bem analisadas. É importante ter em mente que, durante a implantação, pode haver a
necessidade de se de projeto tomadas anteriormente. A partir do momento em quereconsiderar as decisões
escolhemos a arquitetura de , ela pode evoluir e, assim sendo, requer que novos requisitos arquiteturaissoftware
sejam definidos com o objetivo de atender às mudanças desejadas. Portanto, devemos adicionar ou modificar
características, e o sistema deverá estar preparado para estas mudanças.
Os impactos da escolha da arquitetura podem influenciar na do sistema e na manutenibilidade adaptabilidade
dos requisitos funcionais e não funcionais. Outros fatores também podem significar o nível do impacto da
decisão da arquitetura, como a capacidade de e a do sistema. Ou seja, neste tipo deescalabilidade refatoração
desenvolvimento, ao invés de se desenvolver protótipos, a análise dos requisitos e a implantação ocorrem de
forma conjunta. Os métodos ágeis são aqueles de desenvolvimento incremental, em que os incrementos são
•
•
VOCÊ O CONHECE?
John von Neumann foi um cientista que contribuiu fortemente para a evolução da Ciência da
Computação, sendo um dos construtores do primeiro computador: o Eniac. Foi responsável
pelo aprimoramento do poder computacional, levando-o a um aperfeiçoamento da estrutura
lógica do processamento de dados, contribuindo de maneira inigualável para a evolução da
Ciência da Computação. Veja mais a respeito no livro de Fonseca Filho (2007), disponível em: <
>.http://www.pucrs.br/edipucrs/online/historiadacomputacao.pdf
http://www.pucrs.br/edipucrs/online/historiadacomputacao.pdf
- -18
forma conjunta. Os métodos ágeis são aqueles de desenvolvimento incremental, em que os incrementos são
pequenos, e as novas versões do sistema são criadas e disponibilizadas aos clientes periodicamente. As versões
envolvem os clientes no processo de desenvolvimento para que se obtenham retornos rápidos sobre a evolução
dos requisitos. Portanto, é possível perceber como a escolha da arquitetura pode ser fundamental para o 
 de forma consistente e de alto desempenho.desenvolvimento de um sistema
Conforme demonstramos, cada decisão da arquitetura deve ser documentada para que possa haver uma revisão
posterior, a fim de outros interessados entendam a descrição arquitetônica. Essa documentação deverá ser 
, conforme os requisitos forem sendo alterados ou novos forem implantados.sempre atualizada
1.4 Projeto de arquitetura
Você sabe qual é o objetivo e quais são as decisões que precisamos tomar ao fazer um projeto de arquitetura de
um sistema? Entender e saber desenvolver um bom projeto de arquitetura é fundamental para o sucesso de um
sistema.
O projeto de arquitetura é focado na compreensão de como um sistema de informação deverá ser organizado e
como é estabelecida a estrutura global do sistema. No modelo do processo de desenvolvimento de um sistema,
consideramos o projeto de arquitetura como o do processo de projeto de . primeiro estágio software Assim,
uma arquitetura de software serve, fundamentalmente, como um plano de projeto para a negociação de
requisitos de sistema com seus usuários e, em seguida, como uma forma de estruturar as discussões com os
desenvolvedores e gerentes. É também uma ferramenta essencial que pode gerenciar a complexidade, pois pode
esconder detalhes e permitir que os desenvolvedores foquem nas abstrações do sistema.
Quando é iniciado o projeto de arquitetura de um sistema, o deverá ser dentro de um contexto que osoftware
represente, definindo as entidades externas que o sistema interage e o tipo da interação. Tais informações são
obtidas pela e que completam o modelo de representação do sistema no contexto.engenharia de requisitos
1.4.1 Representação do sistema no contexto
Neste momento, podemos nos questionar: como os sistemas operam entre si? O que temos como resposta é o
que chamamos de , que representa como o sistema interage com entidades externas acontexto de arquitetura
seus limites. O desenvolvedor, para modelar como o sistema interage com suas entidades externas, utiliza o 
, e os sistemas que interagem com o chamado sistema-alvo sãoDiagrama de Contexto Arquitetural
representados segundo Pressman (2016, p. 240, grifos nossos) como:
• superiores – sistemas que usam o sistema-alvo como integrantede algum esquema de
processamento de mais alto nível.
• subordinados – sistemas que são utilizados pelo sistema alvo e fornecem dados ou
VOCÊ QUER VER?
O filme (TYLDUM; MOORE, 2014) mostra a história do matemático AlanO jogo da imitação
Turing – considerado o pai da informática – e sua tentativa de quebrar um código de
comunicação nazista durante a 2ª Guerra Mundial. O longa-metragem mostra um episódio
fundamental na história da computação. Não deixe de conferir.
•
•
- -19
• subordinados – sistemas que são utilizados pelo sistema alvo e fornecem dados ou
processamentos necessários para completar a funcionalidade do sistema-alvo.
• de mesmo nível – sistemas que interagem em uma base par-a-par.
• atores – entidades que interagem com o sistema-alvo.
Poderemos representar a estrutura genérica do diagrama de contexto arquitetural na figura a seguir.
Figura 8 - Estrutura genérica do diagrama de contexto arquitetural mostrando os componentes e os relacionados 
hierárquicos.
Fonte: Elaborada pelo autor, baseado em PRESSMAN, 2016.
Cada uma das entidades externas, representadas no diagrama de contexto arquitetural, comunica-se com o
sistema-alvo por meio de uma interface, mostrando como o fluxo e a direção dos dados interagem com os
módulos e as entidades. Na figura a seguir, demonstraremos como acontece um Diagrama de Contexto em um
sistema de controle de segurança.
•
•
•
- -20
Figura 9 - Exemplo do Diagrama de Contexto em um sistema de segurança domiciliar.
Fonte: Elaborada pelo autor, baseado em PRESSMAN, 2016.
Para produzirmos detalhes significativos, precisamos realizar o refinamento do diagrama e dos fluxos de dados,
sendo que os detalham estes refinamentos e estas transformações, a fim deDiagramas de Fluxo de Dados
exibir a coesão correspondente a cada transformação do refinamento.
1.4.2 Definição de arquétipos
Após ser modelado o diagrama de contexto, quais, podemos dizer, que seriam as próximas representações da
arquitetura de ? Uma vez que o contexto é modelado e as interfaces foram representadas, devemossoftware
identificar o conjunto de arquétipos arquiteturais, isto é, uma forma abstrata do que seria a representação de um 
.elemento do software
A maioria dos sistemas é representada por um número pequeno de arquétipos, pois a arquitetura do sistema-
alvo é composta destes arquétipos, que são elementos , e são derivados após a análise de as classes estáveis
serem definidas no modelo de requisitos. Portanto, os arquétipos auxiliam no desenvolvimento do projeto da
arquitetura de software, levando-o a um nível de detalhamento que torna mais fácil detectar inconsistências
entre os componentes arquiteturais.
Síntese
Compreendemos, com o fim este capítulo, o quanto é importante elaborarmos as arquiteturas de para osoftware
desenvolvimento de projetos de sistemas e tornar possível o desenvolvimento das soluções de sistemas de forma
mais simples, rápida, com melhor eficiência e fácil manutenibilidade. Ao implantarmos um determinado modelo
de arquitetura de , devemos atingir ao máximo a simplicidade, para que o sistema tenha assoftware
características de ser flexível, extensível, portável e reutilizável.
Neste capítulo, você teve a oportunidade de:
• compreender os princípios de arquitetura de ;software•
- -21
• compreender os princípios de arquitetura de ;software
• entender as fases de desenvolvimento de um projeto arquitetural;
• descrever os elementos pertinentes à arquitetura e aos padrões arquiteturais básicos;
• compreender os tipos de modelagem e a utilização dos diferentes estilos, padrões e gêneros na 
especificação da arquitetura de ;software
• analisar os impactos das decisões do tipo de arquitetura no desempenho de um sistema.
Bibliografia
CAGNIN, R. L. Uma arquitetura multiagente para gerenciamento de dispositivos em ambientes da internet
. 2015. 123 f. Dissertação (Mestrado em Ciência da Computação) – Universidade Estadual Paulista, Sãodas coisas
José do Rio Preto, 2015. Disponível em: <http://www.athena.biblioteca.unesp.br/exlibris/bd/cathedra/02-08-
>. Acesso em: 15/5/2018.2017/000868971.pdf
CUNHA, D.; FILGUEIRA, A; VIANA, G. Arquitetura de software voltada para a avaliação contínua do processo de
ensino-aprendizagem. , Natal, IF-RN, ano 33, v. 1, p. 43-56, 2017. Disponível em: <Revista HOLOS http://www2.
>. Acesso em: 15/5/2018.ifrn.edu.br/ojs/index.php/HOLOS/article/view/5335/pdf
FONSECA FILHO, C. : o caminho do pensamento e da tecnologia. Porto Alegre: PUC-RS,História da computação
2007. Disponível em: < >. Acesso em: 15/5http://www.pucrs.br/edipucrs/online/historiadacomputacao.pdf
/2018.
GALLOTI, G. M. A. . São Paulo: Pearson Education do Brasil, 2016.Arquitetura de software
HOFMEISTER, C.; NORD, R.; SONI, D. . Applied Software Architecture Boston: Addison-Wesley, 2000.
HUZITA, E. H. M.; OLIVEIRA, H. M.; LAINE, J. M. Uma proposta de arquitetura de software baseada em agentes. 
 - Technology, Maringá, UEM, v. 22, n. 5, p. 1339-1346, 2000. Disponível em: <Acta Scientiarum
>. Acesso em: 15/5/2018.http://periodicos.uem.br/ojs/index.php/ActaSciTechnol/article/view/3131/2252
PRESSMAN, R. : uma abordagem profissional. 8. ed. Porto Alegre: Engenharia de software McGraw Hill, 2016.
SIZO, A. M.; LINO, A. D. P.; FAVERO, E. L. Uma proposta de arquitetura de software para construção e integração
de ambientes virtuais de aprendizagem. , Revista Ibérica de Sistemas e Tecnologias de Informação (RISTI)
Porto, n. 6, p. 17-30, dez. 2010. Disponível em: < >. Acesso em:http://www.scielo.mec.pt/pdf/rist/n6/n6a03.pdf
15/5/2018.
SOMMERVILLE, I. . Engenharia de software 9. ed. São Paulo: Pearson Prentice Hall, 2011.
TYLDUM, M.; MOORE, G. . Direção: Morten Tyldum. Produção: Morten Tyldum. EstadosO jogo da imitação
Unidos: Warner Bros, 2014.
•
•
•
•
•
http://www.athena.biblioteca.unesp.br/exlibris/bd/cathedra/02-08-2017/000868971.pdf
http://www.athena.biblioteca.unesp.br/exlibris/bd/cathedra/02-08-2017/000868971.pdf
http://www2.ifrn.edu.br/ojs/index.php/HOLOS/article/view/5335/pdf
http://www2.ifrn.edu.br/ojs/index.php/HOLOS/article/view/5335/pdf
http://www.pucrs.br/edipucrs/online/historiadacomputacao.pdf
http://periodicos.uem.br/ojs/index.php/ActaSciTechnol/article/view/3131/2252
http://www.scielo.mec.pt/pdf/rist/n6/n6a03.pdf
- -1
ARQUITETURA DE SOFTWARE
CAPÍTULO 2 - QUAIS SÃO AS ABORDAGENS 
ALTERNATIVAS E DE ARQUITETURA PARA 
SISTEMAS E APLICATIVOS MÓVEIS?WEB 
Fernando Skackauskas Dias
- -2
Introdução
Com o grande avanço da e dos dispositivos móveis nos últimos anos, os cientistas da computação se viramweb 
diante de grandes desafios. Quais são as abordagens da arquitetura de que foram elaboradas parasoftware 
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 ? Estas questões sesoftware
tornam relevantes, visto a convergência de novas mídias e aplicativos para e dispositivos móveis. Oweb 
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 e dos dispositivos móveis, a fim de atender aosweb 
modelos de negócio contemporâneos. Temos visto que diversos serviços que eram oferecidos em plataformas
tradicionais estão migrando paulatinamente para ambiente ou para dispositivos móveis. Mais do que isso:web 
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 é modelada para aplicações esoftware web 
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 . Desejamos um excelente estudo.software
2.1 Projeto de arquitetura paraaplicações e web 
dispositivos móveis
Desenvolver sistemas para e dispositivos móveis é uma tarefa complexa, pois essas aplicações sempre agemweb 
integrando diversos e , além de suportarem bancos de dados componentes distribuídos perfis múltiplos de
. Quais as características específicas na criação da arquitetura de para ambiente eusuários software web 
dispositivos móveis? Quais os modelos próprios para arquiteturas alternativas? Quais as alternativas de
arquiteturas existentes? A fim de desenvolver uma arquitetura de para ambiente e aplicativossoftware web 
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 flexíveis parasoftware 
esses domínios. Nesse sentido, abordagens orientadas a reuso, entre outras, fazem parte do projeto de
arquitetura e dispositivos móveis. Veremos, a seguir, como são criados projetos para esses ambientes.web 
2.1.1 Projeto de arquitetura para aplicações web
O desenvolvimento de aplicações para o ambiente tem crescido consideravelmente nos últimos anos com oweb 
fortalecimento da internet como uma plataforma de comércio de produtos e serviços, tendo como estratégia a
 e o aumento da . Além disso, houve uma grande evolução naredução de custos abrangência de atuação
capacidade de transmissão de dados, máquinas servidoras em e um avanço enorme nacloud computing
capacidade de armazenamento dos dados. Portanto, quais são as diferenças na arquitetura de para estesoftware 
ambiente? Antes de tudo, é importante ressaltarmos a importância da aplicação de arquitetura de nosoftware 
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 avançados. Temos desoftware 
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 para sistemas de , em vezsoftware software
- -3
a longo prazo, usar métodos e técnicas da engenharia de para sistemas de , em vezsoftware software
de simplesmente escrever os programas como se fossem algum projeto pessoal. Para a maioria dos
sistemas, a maior parte do custo é mudar o depois que ele começa a ser usado.software 
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.
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 , que está na interface gráfica. A partir do momento em que este evento é disparado,change
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.
- -4
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.
Outro tipo de padrão de arquitetura largamente utilizado é a , com base no modeloarquitetura em 3 camadas
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 e cada um é , independentemente da tecnologiamódulos independentes atualizado
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.
•
•
•
- -5
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.
É possível fazermos uma comparação entre os modelos de arquitetura MVC e em 3 camadas:
• arquitetura MVC: tem um , sendo que a Visão emite eventos comportamento de forma triangular
para o Controlador, que atualiza o Modelo, e a Visão busca os dados do Modelo para exibir;
• arquitetura em 3 camadas: tem um , pois as camadas de apresentação não comportamento linear
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
•
•
•
- -6
centralizada, as quais explicaremos a seguir.
• Arquitetura distribuída
Tem como característica principal as regras de negócio do (que se encontram na camadadesacoplar software 
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 . O que temos é que as aplicações para dispositivos móveis agregam exclusivamente as regras deweb
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 dispositivomó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 são:desvantagens 
• 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 , em uma única aplicação, todas as camadas e regras do sistema. Aenglobar
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 para dispositivos móveis é mais complexo do que softwares 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 e diferenteshardware 
processadores.
Seguindo as características que mencionamos anteriormente, elas mostram os desafios para o desenvolvimento
de dispositivo móvel.
Lee (2005) apresenta uma arquitetura específica para o desenvolvimento dos aplicativos, que poderemos
visualizar na figura a seguir.
•
•
•
•
•
•
•
•
VOCÊ QUER LER?
O crescimento em tamanho e a complexidade dos sistemas de exigem que ossoftware
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
- -7
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.
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
•
•
•
•
•
•
•
•
•
•
•
•
- -8
• 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 , aquela que fazhardware
contato diretamente com o dispositivo;
• hardware: dispositivos móveis como , celulares, leitores de , vídeosmartphones e-books
games etc.
Vários questionamentos podem influenciar na escolha de qual arquitetura devemos utilizar para o
desenvolvimento dos sistemas de dispositivos móveis ou , como: o sistema deve ser desenvolvido utilizandoweb
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 , sendo necessário utilizar os dois web
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.
No próximo item, abordaremos a questão da (linguagem de descrição daarchitecture description language
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.
•
•
•
•
•
•
•
VOCÊ SABIA?
Existem arquiteturas de específicas para a construção e integração de ambientessoftware
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
http://www.scielo.mec.pt/pdf/rist/n16/n16a03.pdf
- -9
2.2.1 Linguagem de descrição da arquitetura (ADL)
A ADL tem como objetivo representar a arquitetura de um , em que os componentes são definidos, bemsoftware
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 que uma ADL ideal deve fornecer:seis propriedades
composição, abstração, reuso, configuração, heterogeneidade e análise.
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
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 [ , ou seja, aunified modelinglanguage
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 para sistemas de aviação;frameworks 
• 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 
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).
VOCÊ QUER VER?
O filme (NEWMAN et al., 2000) é bastante interessante para compreender comoCaçada virtual
atuam os chamados os éticos ( ). Este longa-metragem mostra a históriahackers ethical hacking
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.
•
•
•
•
- -10
• 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 e dispositivos móveis, podemos questionar:web 
como é possível verificar a conformidade de uma arquitetura de ? Segundo Chagas (2016), essasoftware
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 , como a Matriz de Dependência Estrutural (DSM), modelos de técnicas e ferramentas
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 ( ) ou então verificando o código-fonte em tempo deforma estática
execução ou suas versões ao longo do tempo, comparando-as com a visão arquitetural ( ). Aforma dinâmica
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; 
- é uma relação entre dois componentes que não é permitida e não foi implementadadivergência 
como pretendida. A divergência aponta que a implementação não é compatível com o modelo
arquitetural planejado; - é uma relação entre dois componentes que era pretendida, porémausência 
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.
Outras regras de verificação de conformidade são as entre elementos arquiteturais as quais, pararestrições 
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
•
•
•
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 como uma opção para orientar osoftware
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
http://www.scielo.br/pdf/jistm/v7n3/07.pdf
- -11
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 de nível mais alto do que objetos e são definidos porabstrações 
suas . Geralmente, eles são que objetos individuais e todos os detalhes de implementação sãointerfaces maiores 
escondidos de outros componentes, conforme citado por Sommerville (2011, p. 315):
a engenharia de baseada em componentes (CBSE, do inglês software component-based software
) surgiu na década de 1990 como uma abordagem para de desenvolvimento deengineering softwares 
sistemas com base no reuso de componentes de .softwares
Utilizamos o termo componente, portanto, para nos referir a , como funções, estruturastrechos do código-fonte
de dados e classes. Existem outras definições para eles, como de um programa que podeminstâncias de classes
ser utilizadas por outras instâncias. Além disso, podemos denominá-los como sendo as de funções ebibliotecas 
bibliotecas de ligação dinâmica. Sommerville (2011, p. 316) enumera que
os fundamentos da engenharia de baseada em componentes são: 1. Os componentessoftware 
independentes que são completamente especificados por suas interfaces. [...] 2. Os padrões de
componentes que facilitam a integração destes. [...] 3. O que fornece suporte de middleware software
para a integração de componentes. [...] 4. Um processo de desenvolvimento que é voltado para a
engenharia de baseada em componentes. [...]software 
Portanto, quando desenvolvemos sistemas baseados em componentes, apropriamos as boas práticas da
engenharia de . Essa engenharia baseada em componentes, conforme demonstrado por Sommervillesoftware
(2011, p. 316), apoia-se em um dos princípios de projeto na construção de compreensíveis e passíveissoftwares 
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 existe para o sistema operacional e para outras ferramentas componente físico 
do sistema, sendo que ele pode ser armazenado ou transferido. Por outro lado, o possuicomponente lógico
uma utilidade para o funcionamento do programa. O é utilizadocomponente de tempo-de-desenvolvimento
durante o desenvolvimento do , enquanto o é quando está prontosoftware componente de tempo-de-execução 
para ser executado pelo sistema. Para Sommerville (2011, p. 317), os componentes têm as seguintes
características:
- -12
Quadro 1 - Relação dos componentes e as descrições relativas às suas características.
Fonte: SOMMERVILLE, 2011, p. 317.
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áriopreocupar onde ele está sendo executado ou em que
linguagem foi desenvolvido.
- -13
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 , e elas mostram o serviço que o componente interfaces que se relacionam
fornece e os serviços que ele necessita. Segundo Sommerville (2011, p. 318), “a interface ‘ ’ define osprovides
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 , isto é, a linguagem de modelagem unificada), a paraunified modeling language interface ‘ ’ provides
um componente é indicada por um a partir do ícone de componente. Na figura acírculo no fim de uma linha
seguir, demonstramos um modelo genérico de um componente e as interfaces ‘ ’ e ‘ ’.requires 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.
Por outro lado, Sommerville (2011, p. 318) nos diz que “a interface ‘ ’ especifica quais serviços devem serrequires
CASO
Uma universidade de grande porte estava reorganizando o seu portal , que já seweb
encontrava em um formato obsoleto. Foram propostas duas metodologias diferentes a serem
aplicadas: uma de centrada no usuário e outra de participativo. Este tipo dedesign design
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 . A primeira etapa foi a realização de uma entrevista com os usuários para obter assite
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.
- -14
Por outro lado, Sommerville (2011, p. 318) nos diz que “a interface ‘ ’ especifica quais serviços devem serrequires
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 ‘ ’ não define como esses serviçosrequires
deverão ser prestados. Em UML, o símbolo de uma é um ,interface ‘ ’requires semicírculo no fim de uma linha
a partir do ícone de componente.
Na figura a seguir, demonstraremos as interfaces ‘ ’ e ‘ ’ de um componente coletor de dados,requires provides
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.
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 ‘ ’ inclui métodos para adicionar,requires
remover, iniciar, parar e testar sensores. O método retorna os dados do sensor que foramreport 
coletados e o método fornece informações sobre os sensores conectados.listAll 
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.
- -15
Um modelo de componente significa uma para a sua implementação, implantação edefinição de normas
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. . Os componentes são definidos pela especificação de suas interfaces. O modelo deInterfaces
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. 
. O modelo de componente inclui uma especificação de como componentes devem serImplantação
empacotados para implantação como entidades independentes, executáveis. Como os componentes
são entidades independentes, eles precisam ser empacotados com todos os de suporte nãosoftwares 
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.
VOCÊ SABIA?
Existe uma proposta de arquitetura de baseada em para osoftware data warehouse
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
http://www.periodicosibepes.org.br/index.php/reinfo/article/view/728
- -16
Figura 7 - Elementos básicos de um modelo de componentes, demonstrando suas relações e definições.
Fonte: SOMMERVILLE, 2011, p. 319.
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 . Este, por sua vez, oferecemiddleware
suporte para a execução dos componentes, sendo “o que se encontra entre o sistema operacional e ossoftware 
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. , que permitem aos componentes se comunicarem e interagirem em umServiços de plataforma
ambiente distribuído. Esses são os serviços fundamentais que devem estar disponíveis em todos os
sistemas baseados em componentes. 2. , que são serviços comuns, suscetíveisServiços de suporte
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.
- -17
Figura 8 - Serviços de middleware definidos em um modelo de componente, demonstrando suas relações.
Fonte: SOMMERVILLE, 2011, p. 320.
Por fim, o tem como responsabilidade implementar os serviços dos componentes e fornecer amiddleware 
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