Arquitetura de Software

1
ARQUITETURA
DE
SOFTWARE
2
ARQUITETURA DE
SOFTWARE
U1 - QUAIS SÃO OS
FUNDAMENTOS E CONCEITOS
BÁSICOS DA ARQUITETURA DE
SOFTWARE?
Introdução
A complexidade dos sistemas de software tem aumentado consideravelmente nas últimas
décadas devido à 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 software têm
utilizado novas abordagens, a fim de desenvolver sistemas com alto desempenho. Portanto,
desenvolver softwares com qualidade é uma questão que tem merecido a devida atenção dos
cientistas da computação.
Assim, podemos nos questionar: qual o papel da arquitetura de software? Quais são os
modelos de arquitetura? Como a implantação de um modelo de arquitetura de software pode
melhorar a qualidade dos sistemas de informação?
Antes de responder a essas questões, é importante relembrarmos que a arquitetura de

software é considerada a área de conhecimento da Ciência da Computação na qual são
aplicadas práticas da engenharia de software e da 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 software com a

demonstração das fases de 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 software. Por fim, analisaremos os impactos das decisões do tipo de
arquitetura no desempenho de um sistema.
Desejamos um excelente estudo.
1.1 Introdução ã ãrquiteturã de software

3
Você sabe qual o propósito da arquitetura de software? Segundo Galloti (2016, p. 3),
é o de “criar soluções [...] 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 prevenir a ocorrência deles e aperfeiçoar as soluções já existentes.
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 software para
compreender a evolução dos sistemas de informação e a estruturação lógica e
abstrata deles, além de desenvolvê-los com confiabilidade e alta qualidade.
1.1.1 Conceitos introdutórios de arquitetura de softwãre
Qual o sentido fundamental de arquitetura de software? Para Galloti (2016, p. 10), ela
“[...] explica a forma como [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 software deve ser clara, a fim de atingir o máximo da simplicidade, tendo o software
as seguintes características:
• flexível: deve permitir as mudanças que se façam necessárias em

decorrência das alterações de 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;
• reutilizável: é possível adaptar componentes de um software para outro.
O projeto de arquitetura é o primeiro passo no processo de implantação de um

modelo de arquitetura de software: ele a conecta com a engenharia de requisitos –
esta última é o processo que elabora os documentos 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 software se altera na mesma medida em que ele evolui e se ajusta
às novas demandas e evoluções tecnológicas. Portanto, ela é parte integrante da
engenharia de software, que é uma abordagem sistemática e formal de
desenvolvimento dos sistemas de informação.
Essas características fazem parte dos quesitos de qualidade, ou seja, é o conjunto
de atributos que se espera de um software de alto desempenho. Podemos detalhálas
no quadro a seguir, segundo Sommerville (2011, p. 5).
4
Deslize sobre a imagem para Zoom
Quãdro 1 - Atributos essenciãis de quãlidãde de um softwãre, sendo pãrte integrãnte dã elãborãção dã ãrquiteturã de
um sistemã de informãção. Fonte: SOMMERVILLE, 2011, p. 5.
#PraCegoVer: Contém uma tabela com os atributos essenciais de qualidade de um

software, sendo parte integrante da elaboração da arquitetura de um sistema de
informação. A tabela é composta de duas colunas denominadas, Características do
produto e Descrição. A coluna Características do produto contém as linhas, sendo
elas: Manutenibilidade, Confiança e proteção, Eficiência e, Aceitabilidade. A
descrição de Manutenibilidade é: O software deve ser escrito de forma que possa
evoluir para atender às necessidades dos clientes. Esse é um atributo crítico, porque
a mudança de software é um requisito inevitável de um ambiente de negócio em
mudança. A descrição de Confiança e proteção é: A confiança do software inclui uma
série de características como confiabilidade, proteção e segurança. Um software
confiável não deve causar prejuízos físicos ou econômicos no caso de falha de
sistema. Usuários maliciosos não devem ser capazes de acessar ou prejudicar o
sistema. A descrição de Eficiência é: O software não deve desperdiçar os recursos
do sistema, como memória e ciclos do processador. Portanto, eficiência inclui
capacidade de resposta, tempo de processamento, uso de memória, entre outros. A
descrição de Aceitabilidade é: O software deve ser aceitável para o tipo de usuário
para qual foi projetado. Isso significa que deve ser compreensível, usável e
compatível com outros sistemas usados por ele.
Estas características terão maior ou menor relevância dependendo do propósito do

software e do contexto no qual ele está inserido. Por exemplo, softwares de
transações informacionais básicas (como, por exemplo, um sistema de cadastro de
5
clientes de uma loja) terão atributos de qualidade diferentes de sistemas mais

complexos como, por exemplo, um software de controle de uma fábrica. No primeiro
caso, o foco do sistema estará mais 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 softwares sejam tipificados conforme
sua aplicabilidade e natureza, sendo fundamentais ao construirmos o projeto de
arquitetura de um sistema, pois estes fatores 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 qual ele é desenvolvido. O fator mais importante para
determinar quais são as técnicas e os métodos de engenharia de software é o tipo
de aplicação que, segundo Sommerville (2011, p. 7, grifos nossos), podem ser
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 Web
como aplicações de comércio.
• Sistemas de controle embutidos. São sistemas de controle que controlam e
gerenciam dispositivos de hardware. Exemplos de sistemas embutidos é o
software em telefone celular 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 software,
como um programa de planilha eletrônica.
Tendo como base as tipificações definidas anteriormente, é necessário definir como

são classificados os modelos de processo de desenvolvimento de software, isto é, a
representação, de forma simplificada, de um determinado processo específico.
Segundo Sommerville (2011, p. 20, grifos nossos), os modelos são englobados em
três tipos:
6
• 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 software
orientada a reuso. 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 níveis e aquilo que é considerado a decomposição da arquitetura
de software – esta, segundo Sommerville (2011, p. 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 software em dois
níveis de abstração, segundo Sommerville (2011, p. 104, grifos nossos):
• A arquitetura em pequena escala está preocupada com a arquitetura de

programas individuais. Nesse nível, estamos preocupados com a maneira
como um programa individual é decomposto em componentes.
• A arquitetura em grande escala preocupa-se com a arquitetura de sistemas
corporativos 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 software é fundamental, portanto, para o desenvolvimento

de um sistema, pois integra o desempenho, a robustez e a capacidade do sistema
de sua manutenibilidade.
Existem arquiteturas de softwares com diversas abordagens, inclusive as que são orientadas 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>.
As arquiteturas de software geralmente são modeladas usando diagramas de blocos

simples, nos quais cada 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
software utilizando diagrama de blocos é representado na figura a seguir, que elabora
um controle robotizado de empacotamento.
7
Figurã 1 - Arquiteturã de um sistemã de controle robotizãdo de empãcotãmento, indicãndo os componentes, os

subcomponentes e ã trãnsãção de dãdos. Fonte: Elãborãdã pelo ãutor, ãdãptãdo de SOMMERVILLE, 2011.
#PraCegoVer: Ilustra a arquitetura de um sistema de controle robotizado de

empacotamento, indicando os componentes, os subcomponentes e a transação de
dados. A ilustração contém o componente Sistema de Visão que aponta para o
componente Sistema de identificação de objetos e para os subcomponentes
Controlador de Braço e Controle de Garra. Estes subcomponentes também são
apontados pelo componente Sistemas de Identificação de Objetos, que por sua vez,
também aponta para os subcomponentes Sistema de Seleção de Empacotamento e,
Sistema de Empacotamento. Estes subcomponentes apontam para o componente
Controlador de Esteira.
Os diagramas de blocos representam a arquitetura de um software e apresentam

uma visão de alto nível da 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çoes de ãrquiteturã
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 software em um único modelo, porque
8
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 software propõem que devemos ter quatro visões
fundamentais, as quais, segundo Sommerville (2011, p. 107, grifos nossos), são:
• 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 software é decomposto para o
desenvolvimento, ou seja, apresenta a distribuição do software em
componentes que são implementados por um único desenvolvedor ou por
uma equipe de desenvolvimento. Essa visão é útil para gerentes de software
e programadores.
• física, que mostra o hardware do sistema e como os componentes de software
são 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
visão conceitual, pois ela 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.
A internet das coisas é uma revolução tecnológica recente que tem como objetivo
conectar os itens – ou seja, as coisas – utilizados no dia a dia com a internet. Cagnin
(2015) desenvolveu sua dissertação propondo uma arquitetura de software denominada
de “Uma arquitetura 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-082017/000868971.pdf>.
Uma das possíveis visões que podem servir de referência para a construção da
arquitetura de um sistema é a Unified Modeling Language (UML), uma linguagem de
modelagem que serve para definir artefatos que auxiliam na tarefa de desenhar e
documentar os sistemas, sendo composta por diversos diagramas que compõem a
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.
9
• Classes. Este diagrama representa a coleção de classes e define seus

interrelacionamentos.
• Objetos. Este diagrama visa mostrar em forma de um retrato os objetos do
software e seus 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 software, pois às 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 sistema que se está implementando. Por outro lado, vários
pesquisadores indicam o uso de linguagens de descrição de arquitetura
(Architectural Description Languages, as ADLs) para apresentá-la. Os elementos
fundamentais das ADLs são os componentes e conectores, que agregam regras e
diretrizes para a arquitetura do sistema.
1.2 Generos e estilos de ãrquiteturã
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”.
Baseandonos 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 processo de projeto de arquitetura, os
desenvolvedores precisam tomar várias 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 software
10
com exemplos e situações em que são utilizados, bem como suas vantagens e
desvantagens.
A arquitetura de um software pode ser baseada em um determinado padrão ou estilo.
Um padrão de arquitetura significa como o software é organizado: por exemplo,
existe o padrão de organização cliente-servidor e um padrão de arquitetura em
camadas. Esses padrões mostram o objetivo de uma arquitetura que foi utilizada em
sistemas de software diferenciados. Nesse sentido, o desenvolvedor, ao tomar
decisões sobre qual a 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 requisitos do sistema.
Para que se decomponham em unidades estruturais do sistema, o 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 dos componentes do sistema é controlada. Ou
seja, se desenvolve um modelo de visão mais alta dos 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 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 software

se aplicarem a todos os 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 software de forma geral, sendo que em cada categoria podem ser 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.
11
• 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 estilos na arquitetura de software descreve uma

categoria de sistema: pode 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:
• arquitetura centralizada em dados: um repositório de dados reside no

centro desta arquitetura e é, em geral, acessado por outros componentes.
Observe-a na figura a seguir.
12
Figurã 2 - Arquiteturã centrãlizãdã em dãdos demonstrãndo o deposito de dãdos e os softwãres ãssociãdos. Fonte:
Elãborãdã pelo ãutor, bãseãdo em PRESSMAN, 2016.
#PraCegoVer: Ilustra a arquitetura centralizada em dados demonstrando o depósito

de dados e os softwares associados. Ao centro existe um cilindro, representando o
depósito de dados e ao redor, vários retângulos, representando os softwares que
consomem e abastecem o depósito de dados.
• 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.
13
Figurã 3 - Arquiteturã de fluxo de dãdos demonstrãndo os filtros de dãdos e os tubos ãssociãdos. Fonte: Elãborãdã
pelo ãutor, bãseãdo em PRESSMAN, 2016.
#PraCegoVer: Contém a ilustração da Arquitetura de fluxo de dados demonstrando

os filtros de dados e os tubos associados. A imagem é composta por vários
retângulos, contendo em seu interior a palavra Filtro, onde vários filtros apontam para
vários filtros. As ligações entre estes filtros, são chamadas de tubos.
• arquitetura de chamadas e retornos: permite obter dados em programa

principal e subprograma. Atente-a na figura a seguir.
14
Fi
gurã 4 - Arquiteturã de chãmãdãs e retornos demonstrãndo o progrãmã principãl e subprogrãmãs controlãdores e
de ãplicãção. Fonte: Elãborãdã pelo ãutor, bãseãdo em PRESSMAN, 2016.
#PraCegoVer: Ilustra a arquitetura de chamadas e retornos, demonstrando o

programa principal e subprogramas controladores e de aplicação. A imagem é
composta por vários retângulos. Inicia com um retângulo contendo a inscrição
Programa Principal. Em um nível inferior, há três retângulos contendo a inscrição
Subprograma de Aplicação, que estão ligados ao Programa Principal e também, a
outros subprogramas.
• 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.
15
igurã 5 - Arquiteturã em cãmãdãs demonstrãndo ãs diversãs cãmãdãs e os componentes ãssociãdos ã elãs. Fonte:
Elãborãdã pelo ãutor, bãseãdo em PRESSMAN, 2016.
#PraCegoVer: Ilustra a arquitetura em camadas demonstrando as diversas camadas

e os componentes associados a elas. A imagem possui círculos, uns dentro dos
outros, representando as camadas. Na camada mais interna está a Camada Central.
Em direção mais externa, estão as camadas de utilitários, de aplicação e de interface
do usuário, respectivamente.
Diante das características expostas das arquiteturas de software, é possível

descrevermos os 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 Modelo é responsável por gerenciar o
sistema de dados e as operações associadas aos dados; o componente
Visão é responsável por definir e gerenciar a forma de os dados se
apresentarem; o componente Controlador é responsável por gerenciar a
interação do usuário e passá-la para a Visão e o Modelo. Geralmente, este
padrão pode 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.
16
Figurã 6 - Modelo dã orgãnizãção MVC com ã demonstrãção do fluxo de ãçoes e dãs mudãnçãs de estãdo. Fonte:
Elãborãdã pelo ãutor, bãseãdo em SOMMERVILLE, 2011.
#PraCegoVer: Ilustra o modelo da organização MVC com a demonstração do fluxo

de ações e das mudanças de estado. A imagem possui três retângulos, Modelo,
Controlador e Visão. O Modelo encapsula o estado de aplicação e notifica visão de
mudanças de estado. O controlador mapeia ações de usuário para atualizar o modelo
e seleciona visões. A visão modelo os renders, solicita atualização de modelo e envia
eventos de usuário para o controlador.
• 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 mutabilidade e a portabilidade. Se a interface ficar
inalterada, uma 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. Portantto, este padrão se
caracteriza pela organização do software em camadas, cuja funcionalidade
é associada a cada uma delas. 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 substituição de camadas inteiras, mas, por outro lado, é difícil ter
clara a separação entre as camadas e como interagem camadas de níveis
mais alto e mais baixo, impactando o desempenho geral do sistema.
17
Existe uma proposta de arquitetura de software baseada no padrão em camadas e que 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=S164698952010000200003>.
• De repositório: tem como característica que todos os dados do sistema são

gerenciados em um repositório central, ficando acessível a todos os
componentes do sistema. Neste padrão, existe a 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 servidores que oferecem serviços a outros componentes.

Exemplos de 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 clientes que podem chamar os serviços oferecidos pelos
servidores. Em geral, haverá várias instâncias de um programa cliente
executando simultaneamente em computadores diferentes.
• Uma rede que permite aos clientes acessar esses serviços. A maioria dos
sistemas cliente-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 modelopadrão.
18
Figurã 7 - Modelo cliente-servidor, demonstrãndo ã relãção entre clientes, internet e serviços disponíveis. Fonte:
#PraCegoVer: Ilustra o Modelo cliente-servidor, demonstrando a relação entre

clientes, internet e serviços disponíveis. A imagem contém um grande retângulo com
a inscrição Internet, acima estão 4 retângulos representando os clientes e abaixo
existem retângulos com as inscrições servidor de catálogos e catálogo de biblioteca
para o cliente 1, servidor de vídeos e arquivo de filmes para o cliente 2, servidor de
fotos e arquivos de fotos para o cliente 3 e, servidor web e Informações sobre vídeos
e fotos para o cliente 4.
A vantagem desse modelo é a característica de distribuição por meio de uma rede,

podendo estar disponível para todos os clientes. Porém, cada serviço se torna um
ponto de falha, tornando o desempenho imprevisível.
O desenvolvimento de software baseado em agentes tem como objetivo a sua aplicação

em 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>.
• 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
processamento de dados, quando as entradas são processadas em etapas
distintas para gerar saídas relacionadas entre si. Sua vantagem é a
capacidade de reuso do processamento dos dados ser de fácil
19
compreensão e facilidade de suporte. Por outro lado, o formato para a

transferência dos dados deve ser acordado entre os processamentos.
1.3 Decisoes sobre ãrquiteturã
Os arquitetos de software criam uma metodologia própria para coletar e analisar os

requisitos e definir a arquitetura para ser utilizada no desenvolvimento dos sistemas.
Nesse sentido, são realizadas diversas 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 a essas questões considerando que um projeto de
software desenvolvido com qualidade deve atender aos 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 hardware,
dos componentes, das estruturas, das plataformas, dos sistemas de gerenciamento
de software, entre outros recursos acoplados ao sistema e que ele deve se integrar.
Portanto, definir a arquitetura de software envolve implantar uma solução estruturada
que atenda ao maior número possível dos requisitos técnicos e operacionais e que
aperfeiçoe os atributos de qualidade (como 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.
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 Enterprise Resource Planning (ERP), cujo 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.
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
20
algoritmos e a forma da estrutura de dados, a arquitetura engloba decisões sobre

as estruturas que formarão o sistema, o controle, os protocolos de comunicação, a
sincronização e o acesso a 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 impacto em todo o projeto. 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.
1.3.1 Como ãs decisoes sobre ã ãrquiteturã ãfetãm o

desenvolvimento de um sistemã
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 modelos de projeto que são necessários e o nível de detalhamento para eles.
Isso dependerá do tipo de sistema que está sendo desenvolvido.
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 Unified Modeling Language (UML), geralmente
utilizamos dois 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 reconsiderar as
decisões de projeto tomadas anteriormente. A partir do momento em que escolhemos
a arquitetura de software, ela pode evoluir e, assim sendo, requer que novos
21
requisitos arquiteturais 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.
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>.
Os impactos da escolha da arquitetura podem influenciar na manutenibilidade do

sistema e na 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 escalabilidade e a refatoração do sistema. Ou seja, neste tipo de
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 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
desenvolvimento de um sistema de forma consistente e de alto desempenho.
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 sempre atualizada,
conforme os requisitos forem sendo alterados ou novos forem implantados.
1.4 Projeto de ãrquiteturã
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 primeiro estágio do processo de projeto de 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.
22
O filme O jogo da imitação (TYLDUM; MOORE, 2014) mostra a história do matemático Alan 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.
Quando é iniciado o projeto de arquitetura de um sistema, o software deverá ser

dentro de um contexto que o represente, definindo as entidades externas que o
sistema interage e o tipo da interação. Tais informações são obtidas pela engenharia
de requisitos e que completam o modelo de representação do sistema no contexto.
1.4.1 Representãção do sistemã no contexto
Neste momento, podemos nos questionar: como os sistemas operam entre si? O que
temos como resposta é o que chamamos de contexto de arquitetura, que representa
como o sistema interage com entidades externas a seus limites. O desenvolvedor,
para modelar como o sistema interage com suas entidades externas, utiliza o
Diagrama de Contexto Arquitetural, e os sistemas que interagem com o chamado
sistema-alvo são representados segundo Pressman (2016, p. 240, grifos nossos)
como:
• superiores – sistemas que usam o sistema-alvo como integrante de algum

esquema de processamento de mais alto nível.
• 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.
23
Figurã 8 - Estruturã genericã do diãgrãmã de contexto ãrquiteturãl mostrãndo os componentes e os

relãcionãdos hierãrquicos. Fonte: Elãborãdã pelo ãutor, bãseãdo em PRESSMAN, 2016.
#PraCegoVer: Ilustra a estrutura genérica do diagrama de contexto arquitetural

mostrando os componentes e os relacionados hierárquicos. No centro da imagem há
a inscrição sistema-alvo. Ao redor existem os demais componentes e sua relação
hierárquica, onde sistemas superiores são usados por atores e pares que dependem
de sistemas subordinados.
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.
24
Figurã 9 - Exemplo do Diãgrãmã de Contexto em um sistemã de segurãnçã domiciliãr. Fonte: Elãborãdã pelo ãutor,
bãseãdo em PRESSMAN, 2016.
#PraCegoVer: Ilustra um Exemplo do Diagrama de Contexto em um sistema de

segurança domiciliar. No centro da imagem existe um círculo com a inscrição
Software de Casa Segura. Dois retângulos, painel de controle e Sensores apontam
para o círculo do software, que por sua vez, aponta para os retângulos Exibição do
painel de controle, Alarme e Linha telefônica
Para produzirmos detalhes significativos, precisamos realizar o refinamento do

diagrama e dos fluxos de dados, sendo que os Diagramas de Fluxo de Dados
detalham estes refinamentos e estas transformações, a fim de exibir a coesão
correspondente a cada transformação do refinamento.
1.4.2 Definição de ãrquetipos

Após ser modelado o diagrama de contexto, quais, podemos dizer, que seriam as
próximas representações da arquitetura de software? Uma vez que o contexto é
modelado e as interfaces foram representadas, devemos 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
estáveis, e são derivados após a análise de as classes 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.
25
Síntese
Compreendemos, com o fim este capítulo, o quanto é importante elaborarmos as arquiteturas de

software para o 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 software,
devemos atingir ao máximo a simplicidade, para que o sistema tenha as 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;

• 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.
SOBRE ARQUITETURA
Os sistemas de software atuais, em larga escala, estão entre as

estruturas mais complexas já construídas por humanos, contendo
milhões de linhas de código, milhares de tabelas de banco de dados e
centenas de componentes, todos rodando em dezenas de
computadores interligados. Isso apresenta alguns desafios para as
equipes de desenvolvimento de software – e se esses desafios não
forem resolvidos com antecedência, os sistemas serão entregues com
atraso, acima do orçamento ou com um nível de qualidade
inaceitável. Atualmente, a maioria das empresas reconhece a
importância de ter um arquiteto de software ou, em alguns casos, um
grupo de Arquitetos de software em seus projetos para fornecer
orientação e liderança em tecnologia à equipe. No entanto,
geralmente, não há uma definição clara da atuação desse
26
profissional, do que fazem, como fazem e o que se espera que eles

entreguem.
Ana é uma arquiteta de software que trabalha para uma grande

organização comercial. Como um dos membros mais altos da equipe
de TI, Ana se envolve em muitas atividades diferentes, mas seu papel
principal é liderar a definição e o design dos sistemas de informação
da empresa. No momento, um desses sistemas está tomando a maior
parte de seu tempo e atenção. Tudo começa da seguinte forma: Ana é
convidada a procurar opções para atender as necessidades de
mudança da empresa e substituir o sistema atual de gerenciamento
de estoque (que é razoavelmente idoso) por um sistema mais
moderno para dar um melhor apoio aos novos negócios. Em
particular, o negócio quer que o sistema seja mais interativo e
permita que os funcionários movimentem os estoques em tempo
real, em vez de inserir os dados para ver os resultados no dia
seguinte. O intervalo de tempo imposto pelo sistema atual leva a
erros por causa da falta de feedback imediato e também coloca a
empresa em desvantagem competitiva. À primeira vista, o problema
não parece complicado. Em conversas com algumas pessoas da
organização sobre os requisitos do novo sistema, Ana teve uma ideia
de como começar o trabalho: entrevistar os analistas de negócios e
alguns dos principais usuários, os quais sugerem alguns requisitos
importantes que parecem bastante eficazes. Assim, Ana começa a
esboçar possíveis soluções. No entanto, ao discutir suas ideias com os
outros funcionários da empresa, ela percebe que algumas destas
pessoas têm ideias muito diferentes sobre os principais requisitos do
sistema. Os usuários nos depósitos de distribuição dizem precisar de
informações totalmente diferentes das dos funcionários da sede. De
volta à sede, os gerentes comerciais dizem que é crucial que eles
tenham relatórios resumidos em tempo real ao longo do dia. No
entanto, isso reduziria significativamente o fluxo principal de
27
transações, o que não é aceitável para as pessoas do grupo de

logística, que são os reais pagantes do sistema.
Ana fez reuniões para entender os problemas e envolver as partes

interessadas e, embora não sinta que pode atender a todas as
solicitações, agora sente que tem um bom entendimento do que são
essas preocupações. Com base em sua compreensão das importantes
necessidades das partes interessadas, Ana inicia seu projeto
arquitetônico. Ela esboça a funcional estrutura do sistema,
identificando os principais componentes e planejando como eles
trabalharão juntos para fornecer a funcionalidade necessária.
Enquanto está pensando sobre isso, começa a agrupar componentes
em processos para descobrir onde esses processos serão executados
no data center. Para atender as necessidades do grupo de operações,
adiciona ao seu design alguns componentes de gerenciamento do
sistema, que devem torná-lo mais gerenciável. Percebe que precisa
pensar nos dados do sistema, portanto, adiciona os principais
armazenamentos de dados e anota os fluxos dos dados entre os
principais componentes. Ana está bastante envolvida no projeto e em
algumas semanas terá um modelo de arquitetura detalhado para
mostrar às pessoas.
Neste contexto, percebe-se que existe um grande desafio no início do

trabalho: as decisões de arquitetura e como registrá-las para que
possam atender os interesses de todos os envolvidos. Vamos

Praticar
Baseado no caso mencionado acima, como a decisão pode ser estruturada para melhorar a
comunicação, avaliar os critérios e opções e, principalmente, documentar a decisão para
consultas futuras?
Ao final, disponibilize seu trabalho no fórum da seção.

28
Referências
GALLOTI, G. M. A. Arquitetura de Software. São Paulo: Pearson
Education do Brasil, 2016.
HOFMEISTER, C.; NORD, R.; SONI, D. Applied Software Architecture.

Boston: Addison-Wesley, 2000.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson

Prentice Hall, 2011.
29
TETURA DE SOFTWARE
U 2 - QUAIS SÃO AS
ABORDAGENS ALTERNATIVAS E
DE ARQUITETURA PARA
SISTEMAS WEB E APLICATIVOS
MÓVEIS?
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 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 ãrquiteturã pãrã ãplicãçoes web e dispositivos

moveis
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
30
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 ãrquiteturã pãrã ãplicãçoes 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.
31
Figurã 1 - Modelo MVC demonstrãndo ã relãção entre o Modelo, ã Visão e o Controlãdor e os eventos ãssociãdos ãos
componentes. Fonte: Elãborãdã pelo ãutor, bãseãdo 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
32
que permitem ao componente Modelo ser atualizado a partir dos eventos disparados
pelo componente Visão.
Figurã 2 - Exemplo de interãção entre os componentes do pãdrão MVC e suãs interãçoes de umã ãplicãção em
linguãgem Jãvã. Fonte: SÚN, 2007 ãpud 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:
33
• 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.
34

Figurã 3 - Exemplo de interãção entre os componentes do pãdrão de ãrquiteturã em 3 cãmãdãs e suãs interãçoes
em umã ãplicãção comerciãl. Fonte: Elãborãdã pelo ãutor, bãseãdo 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 ãrquiteturã pãrã dispositivos moveis
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
35
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.
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>.
Lee (2005) apresenta uma arquitetura específica para o desenvolvimento dos

aplicativos, que poderemos visualizar na figura a seguir.
36
sobre a imagem para Zoom
Figurã 4 - Exemplo de ãrquiteturã pãrã ãplicãtivos moveis com ãs cãmãdãs físicãs e logicãs e suãs interãçoes.
Fonte: Elãborãdã pelo ãutor, bãseãdo 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.
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;
37
• 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 Avãliãção dãs ãlternãtivãs 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;
38
• 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.
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>.
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 Linguãgem de descrição dã ãrquiteturã (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.
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).
39
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.
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 Verificãção de conformidãde dã ãrquiteturã
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-
40
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.
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>.
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
41
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
tempode-execução é quando está pronto para ser executado pelo sistema.
Para Sommerville (2011, p. 317), os componentes têm as seguintes características:
42

Quãdro 1 - Relãção dos componentes e ãs descriçoes relãtivãs ãs suãs cãrãcterísticãs. 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
43
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.
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
44
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’.

Figurã 5 - Exemplo dã representãção grãficã dãs interfãces ‘require’ e ‘provides’ com um componente e suãs
descriçoes. 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.
45

Figurã 6 - Exemplo dã representãção grãficã do modelo de um componente coletor de dãdos. 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.
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>.
46
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.

Figurã 7 - Elementos bãsicos de um modelo de componentes, demonstrãndo suãs relãçoes e definiçoes. Fonte:
#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
47
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.

Figurã 8 - Serviços de middlewãre definidos em um modelo de componente, demonstrãndo suãs relãçoes. Fonte:
48
#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.
• 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.
Projeto
DESENVOLVIMENTO BASEADO EM COMPONENTES
Os sistemas de software modernos têm se tornado cada vez mais

complexos e gerenciados de maneira a resultar em um alto custo de
49
desenvolvimento, baixa produtividade, qualidade incontrolável de

software e alto risco de atualização de tecnologia.
Consequentemente, há uma demanda crescente na procura de uma
solução para o paradigma do desenvolvimento de software, ou seja, o
desenvolvimento de um software que apresente eficiência e seja
econômico.
Atualmente, uma das soluções mais promissoras é a abordagem de

desenvolvimento de software baseada em componentes. Essa
abordagem é baseada na ideia de que os sistemas de software podem
ser desenvolvidos selecionando componentes prontos para uso e
montando-os com uma arquitetura de software bem definida. Essa
abordagem de desenvolvimento de software é muito diferente da
abordagem tradicional, na qual os sistemas só podem ser
implementados do zero. Esses componentes comerciais fora da
prateleira (COTS) podem ser desenvolvidos por diferentes
desenvolvedores, usando idiomas e plataformas diferentes.
O desenvolvimento de software baseado em componentes (CBSD)

pode reduzir significativamente o custo de desenvolvimento e o
tempo de colocação no mercado, além de melhorar a manutenção, a
confiabilidade e a qualidade geral dos sistemas de software. Essa
abordagem suscitou interesse tanto na comunidade de pesquisa
quanto na indústria de software. O ciclo de vida e o modelo de
engenharia de software do CBSD são muito diferentes dos modelos
tradicionais, isto é, a CBSE (Component-Based Software Engineering)
é focada na utilização da engenharia para modelar esses softwares.
As tecnologias de componentes de software são uma tecnologia

emergente, que está longe estar amadurecida. Não há padrões ou
diretrizes existentes nesta nova área, nem sequer temos uma
definição unificada do item principal, o "componente". No entanto,
em geral, um componente tem três características principais: 1) ele é
uma parte independente e substituível de um sistema que cumpre
50
uma função clara; 2) um componente funciona no contexto de uma

arquitetura bem definida; e 3) um componente se comunica com
outros componentes por meio de suas interfaces. Para garantir que
um sistema de software baseado em componentes possa funcionar
de maneira adequada e eficaz, a arquitetura do sistema é o fator
fundamental para esse processo.
A arquitetura de sistemas de software baseados em componentes

deve ser uma arquitetura em camadas e modular. A primeira camada
de arquitetura é o sistema de aplicativos que suporta um negócio. A
segunda camada consiste em componentes envolvidos em apenas
um domínio comercial ou um aplicativo específico, incluindo
componentes utilizáveis em mais de um único aplicativo. A terceira
camada são os componentes de middleware entre empresas, que
consistem em software e interfaces comuns com outras entidades já
estabelecidas. Finalmente, a camada mais baixa do sistema de
componentes de software inclui componentes básicos que fazem
interface com os sistemas operacionais e hardware subjacentes.
As tecnologias atuais de componentes têm sido usadas para

implementar diferentes sistemas de software, como software de
componente distribuído orientado à objetos e aplicativos
corporativos baseados na Web. Ela fornece uma infraestrutura de
objetos distribuídos reutilizáveis e um conjunto abundante de
componentes de aplicativos para aplicativos desenvolvedores.
Nesse contexto, existe um grande desafio na arquitetura de software

baseada em componentes: identificar quais componentes devem ser
construídos, mantidos e, principalmente, como eles devem interagir.
Vamos Praticar
Baseado nos casos mencionados anteriormente, descreva como os componentes de software
podem ser identificados, construídos e mantidos? Além disso, como seria a forma de
relacionamento entre eles? Ao final, disponibilize seu trabalho no fórum da seção.
51
Referências
GALLOTI, G. M. A. Arquitetura de software. São Paulo: Pearson
HOFMEISTER, C.; NORD, R.; SONI, D. Applied Software Architecture.


52
ARQUITETURA DE
SOFTWARE
U 3 - QUAIS SÃO OS PADRÕES
UTILIZADOS NA IMPLANTAÇÃO
DE ARQUITETURA DE SOFTWARE?
Introdução
Elaborar a arquitetura de um software tem sido uma tarefa complexa para muitos
desenvolvedores de sistemas. Dependendo do tamanho e do objetivo do sistema, são
desenvolvidas milhares de linhas de código, centenas de componentes e conectores, várias
bibliotecas, integração com sistemas legados, servidores de aplicações, tabelas de banco de
dados, segurança de acesso, alta disponibilidade e vários requisitos funcionais e não funcionais
que elevam a complexidade da arquitetura. Além disto, nos últimos anos, houve uma evolução
tecnológica de software e hardware exponencial, com dispositivos móveis possuindo novas
funcionalidades e alta integração de múltiplas plataformas. O que temos são diversos modelos,
padrões e estilos de arquitetura de software e de projetos que foram criados e evoluídos para
atenderem às novas tecnologias. Estes modelos e padrões devem ser aplicados conforme o
cenário e o objetivo do sistema.
Nesse sentido, saber escolher de forma correta os padrões de arquitetura de software se torna
uma função fundamental. Diante desse cenário, temos as seguintes questões: quais são os
padrões disponíveis para a implantação de uma arquitetura de software? Como analisar os
fundamentos do projeto da arquitetura? Como descrever as atividades e as funcionalidades de
um determinado padrão de arquitetura?
Neste capítulo, veremos como distinguir projeto de conteúdo de projeto funcional e saberemos
identificar a fronteira entre conteúdo e função. Apresentaremos, também, a forma de
descrever a engenharia de domínio e analisar os tipos de padrões de arquitetura. Por fim,
descreveremos o funcionamento do projeto baseado em padrões e distinguiremos padrões de
arquitetura, de componentes e de interfaces do usuário.

53
3.1 Anãlise de projetos de conteudo e projeto funcionãl

O levantamento de requisitos, geralmente, é um conjunto de procedimentos que
toma muito tempo, e muitos desenvolvedores o executam de maneira superficial ou
simplesmente não o fazem. Isso pode trazer graves consequências, pois resolver
problemas de requisitos após o desenvolvimento pode custar muito mais tempo.
Como resolver problemas de levantamento de requisitos? Qual o nível de análise é
necessário para levantá-los? Como criar projetos de requisitos para aplicativos na
web? Para responder a essas questões, precisamos definir o tamanho e a
complexidade do incremento do aplicativo e a quantidade de interessados, para
poder identificar requisitos conflitantes.
Pressman (2016, p. 197) nos explica que, “embora seja uma boa ideia analisar o
problema antes de começar o projeto, não é verdade que toda análise deva preceder
todo o projeto”. Ou seja, o projeto de uma parte específica de um aplicativo na web
necessita de uma análise apenas dos requisitos daquela parte. A seguir,
demonstraremos como são elaborados os projetos de conteúdo de funcional para
componentes web e aplicativos móveis.
3.1.1 Projeto de conteúdo e funcional para componentes
Pressman (2016, p. 381) descreve: “A arquitetura de conteúdo focaliza a maneira

pela qual objetos de conteúdo (ou objetos compostos como página Web) são
estruturados para apresentação e navegação”.
O projeto de conteúdo engloba duas tarefas de projetos distintos, sendo cada uma
delas manipuladas por pessoas com um determinado conjunto de habilidades
distintas:
• inicialmente, são desenvolvidas representações de projetos para os

objetos de conteúdo e seus mecanismos necessários para efetuar as
relações;
• em seguida, são criadas as informações em um determinado objeto de
conteúdo, sendo que esta tarefa pode ser executada por redatores,
designers e demais pessoas que geram o conteúdo a ser publicado no
aplicativo.
Um objeto de conteúdo possui atributos com informações específicas de um

conteúdo e os atributos de implantação, que são exclusivos e especificados como
parte do projeto.
Com o crescimento rápido de computação em nuvem, tem aumentado a preocupação

com a necessidade de serviços oferecidos. Um grande desafio é implementar um
ambiente tolerante a falhas. Para combatê-las, muitas técnicas são projetadas para
reduzir os erros. O que acontece é que gestores pagos oferecem esse tipo de suporte,
54
mas aqueles chamados open source não fornecem elementos que permitam tolerar
falhas e deixam os usuários vulneráveis às falhas de um ambiente de tecnologia. Veja
a dissertação de Martins (2014) e saiba
mais: <https://repositorio.unesp.br/bitstream/handle/11449/127619/000843909.pdf?se
quence=1&isAllowed=y>.
O projeto de conteúdo identifica o escopo completo do conteúdo a ser fornecido pelo
aplicativo na web. Nesse sentido, o conteúdo pode aparecer na forma de texto,
gráficos, imagens, vídeo ou áudio, sendo que ele é o elemento estrutural para
fornecer uma visão fundamental dos requisitos para o aplicativo. Esses elementos
compreendem os objetos de conteúdo e todas as classes de análise, cujas entidades
são visíveis aos usuários que foram criadas ou manipuladas, na proporção em que
o usuário interage com o aplicativo.
Segundo descrito por Pressman (2016, p. 199), “O conteúdo pode ser desenvolvido
antes da implementação da Webapp, enquanto a Webapp está sendo construída ou
bem depois de estar em funcionamento”. Nesse caso, os objetos de conteúdo podem
ser tanto uma descrição textual de um produto quanto uma foto, uma animação etc.
Eles podem ser guardados como arquivos diversos, sendo incorporados diretamente
em páginas da web ou também obtidos de forma direta e dinâmica em um banco de
dados. Quer dizer, um objeto de conteúdo significa qualquer informação que seja
coesa e que deve ser apresentada ao usuário final.
Portanto, os objetos de conteúdo podem ser obtidos a partir dos casos de uso,
analisando a descrição do cenário para obter as referências diretas e indiretas ao
conteúdo. Assim, o projeto de conteúdo tem como objetivo fazer a descrição do
conteúdo componente. Em algumas situações, uma lista dos objetos de conteúdo
com uma descrição sucinta dos objetos já é suficiente para se definir os requisitos
para os conteúdos que serão projetados. Porém, em alguns casos, o projeto de
conteúdo pode ser obtido a partir de uma análise que demonstre, graficamente, os
relacionamentos entre os objetos de conteúdo e a hierarquia do conteúdo do
aplicativo.
O filme A rede social (SORKIN; MEZRICH, 2010) retrata a história de Mark Zuckerberg e da evolução do
Facebook, uma verdadeira revolução na sociedade moderna. O longa-metragem mostra o início da rede
desenvolvida por Mark, dentro da Universidade de Harvard, e as desavenças entre Zuckerberg e os outros
fundadores, inclusive com o brasileiro Eduardo Saverin.
Podemos criar uma árvore de dados com a elaboração para qualquer conteúdo
composto de vários objetos de conteúdo e cujo objetivo é tentar demonstrar as
relações hierárquicas entre os objetos de conteúdo, oferecer uma maneira de
revisar o conteúdo para que as omissões e inconsistências sejam mostradas antes
do início do projeto e servir de base para o projeto de conteúdo.
Na figura a seguir, demonstraremos uma árvore de conteúdo para um componente
de um sistema de vendas. Neste exemplo, temos a decomposição de um
determinado componente mecânico em suas descrições e podemos observar que há
uma relação hierárquica. Entre as descrições, temos tanto elementos técnicos
55
(esquema e descrição técnica) quanto elementos comerciais (preço e descrição de

marketing).

Figurã 1 - Modelo de umã ãrvore de conteudo pãrã um componente e seus relãcionãmentos de um sistemã de
vendãs. Fonte: Elãborãdã pelo ãutor, bãseãdo em PRESSMAN, 2016.
#PraCegoVer: ilustra o modelo de uma árvore de conteúdo para um componente e

seus relacionamentos de um sistema de vendas. A imagem contém um modelo em
que um componente possui atributos como por exemplo: número da peça, nome da
peça, tipo da peça, descrição e preço. Alguns destes atributos possuem subatributos,
como o atributo preço que possui os subatributos preço no atacado e preço no varejo
e, o atributo descrição que possui os subatributos: descrição de marketing, fotografia,
descrição técnica, esquema, vídeo, preço no atacado e, preço no varejo.
Portanto, a partir do momento que todos os objetos de conteúdo forem modelados,

as informações que os objetos devem fornecer necessitam passar por um processo
de autoria e formatação, tendo como objetivo melhor atender aos requisitos
estabelecidos pelo cliente do projeto.
Apesar da possibilidade de serem criadas arquiteturas personalizadas, no projeto de
arquitetura de conteúdo temos quatro tipos mais usuais, os quais, segundo Pressman
(2016, p. 381, grifos nossos), são:
• Estruturas lineares: são encontrãdãs quãndo umã sequenciã interãçoes previsível e

comum.
• Estruturas em grade: é uma opção arquitetural que pode ser organizada em
categorias de duas ou mais dimensões.
56
• Estruturas hierárquicas: é uma estrutura que pode ser projetada para

possibilitar o fluxo de controle horizontal ao longo das ramificações verticais
da estrutura.
• Estrutura em rede: os componentes da estrutura são projetados de modo que
possam passar o controle para qualquer outro componente do sistema.
Na figura a seguir, apresentaremos a configuração das estruturas linear, em grade,
hierárquica e em rede.
57

Figurã 2 - Modelos de projeto de ãrquiteturã de conteudo mostrãndo ãs estruturãs lineãres, em grãde, hierãrquicã e
em rede. Fonte: Elãborãdã pelo ãutor, bãseãdo em PRESSMAN, 2016.
#PraCegoVer: Ilustra os Modelos de projeto de arquitetura de conteúdo mostrando
as estruturas lineares, em grade, hierárquica e em rede. Estas estruturas são
representadas na imagem por desenho de prédios, organizados conforme cada
estrutura.
Por outro lado, segundo Sommerville (2011), muitos aplicativos móveis podem
oferecer várias funções computacionais e manipuladoras, as quais podem ser
associadas diretamente ao conteúdo e são a meta principal de interação com o
usuário. Nesse sentido, o projeto funcional se associa com dois elementos de
processamento de aplicativos, com diferentes níveis de abstração procedural
(SOMMERVILLE, 2011, p. 201):
• Funcionalidade observável pelo usuário fornecida pelo aplicativo aos

usuários finais.
• As operações contidas nas classes de análise que implementam
comportamentos associados à classe.
Desse modo, a funcionalidade que é observável compreende qualquer função de

processamento iniciada pelo usuário, ou seja, as funções podem ser implementadas
usando operações dentro das classes de análise. Mas, do ponto de vista do usuário,
a função é o resultado que é visível. Quando se vai para um nível de abstração
procedural mais baixo, o modelo de requisitos demonstra o processamento que será
realizado nas operações de classe de análise. O diagrama de atividades Unified
Modeling Language (UML, em português Linguagem de Modelagem Unificada) pode
ser utilizado para representar os detalhes do processamento.
Sommerville (2011) fornece o exemplo a seguir, intitulado “controlar câmeras”, em
que temos o diagrama de atividades, a operação assumircontroledacamera(), que
faz parte da classe de análise Camera(), usada no caso de uso ControlaCameras().
58

Figurã 3 - Modelo de diãgrãmã de ãtividãdes pãrã ã operãção ãssumirControleCãmerã(), mostrãndo o fluxo de ãçoes.
Fonte: Elãborãdã pelo ãutor, bãseãdo em PRESSMAN, 2016.
#PraCegoVer: Ilustra o modelo de diagrama de atividades para a operação

assumirControleCamera(), mostrando o fluxo de ações. O diagrama retratado na
imagem, inicia por um losango que representa uma estrutura de decisão entre a
câmera estar ou não sendo usada no momento. Se a câmera estiver sendo usada,
então é invocado o método obsterUsuarioAtualCamera() e então é informado ao
usuário que a câmera que bloqueada no momento para ele. Se a câmera não estiver
sendo usada, então é invocado o método solicitarBloqueioCamera(), que então
aciona uma estrutura de decisão entre bloqueio disponível e bloqueio indisponível.
Se for bloqueio disponível, então será executada a ação: Informar câmera que está
sendo usada e o nome do atual usuário. Se a decisão for bloqueio indisponível, então
será executada a ação: Informar câmera indisponível.
Neste exemplo, a interação é relativamente simples, mas existe um risco de

funcionalidade complexa, pois a operação requer comunicação complexa com os
dispositivos localizados remotamente e acessíveis pela internet.
As aplicações mais recentes oferecem funções de processamento cada vez com
maior grau de sofisticação, executando processamento para gerar recursos de
navegação de forma dinâmica, fornecendo recursos apropriados para o campo de
59
aplicação, disponibilizando consultas de forma sofisticada e, por fim, estabelecendo

interfaces de dados com sistemas externos.
3.2 Desenvolvimento bãseãdo em componentes
Componentes de softwares comerciais são desenvolvidos para serem oferecidos

como produto e são disponibilizados com a funcionalidade desejada pelo usuário e
pelas interfaces amigáveis, permitindo que o componente seja integrado ao software
que será desenvolvido. O modelo de desenvolvimento baseado em componentes
demanda uma abordagem iterativa para o desenvolvimento do software,
incorporando características do modelo espiral, ou seja, desenvolve aplicações a
partir de componentes pré-empacotados.
Conforme descrito por Pressman (2016), as atividades de modelagem e construção
se iniciam com a identificação de candidatos a componentes. Por sua vez, estes
componentes podem ser projetados como módulos convencionais, classes
orientadas a objeto ou pacotes de classes. Pressman (2016, p. 69) nos diz que,
independentemente da tecnologia utilizada para criar os componentes, este modelo
incorpora as seguintes etapas:
• Produtos baseados sem componentes disponíveis são pesquisados e

avaliados para o campo de aplicação.
• Itens de integração de componentes são considerados.
• Uma arquitetura de software é projetada para acomodar os componentes.
• Os componentes são integrados na arquitetura.
• Testes completos são realizados para assegurar funcionalidade adequada.
Este modelo baseado em componentes leva ao reuso, o que proporciona uma série
de benefícios aos engenheiros de software, como a redução no tempo de ciclo de
vida de desenvolvimento e no custo do projeto. Mas, para ocorrer, isso deve ser um
procedimento da cultura do grupo de desenvolvedores.
3.2.1 Engenharia de domínio
A engenharia de domínio é um processo que tem como objetivo desenvolver diversas

aplicações que podem ser reusáveis em um domínio particular de problema. Nesse
caso, de forma geral, ela compreende as fases de:
• análise: é a primeira fase e é realizado o levantamento dos requisitos do

domínio em questão;
• projeto: é a fase intermediária e os modelos de análise realizados na fase
anterior são refinados, com o objetivo de construir uma arquitetura do
domínio;
• implementação: é a fase final e tem o objetivo de gerar o código-fonte para
a arquitetura gerada na fase anterior.
60
A análise de domínio compreende um fluxo processual no qual a informação que foi

utilizada no desenvolvimento de um determinado sistema possa servir como
referência para o desenvolvimento de outros sistemas. É necessário que seja
identificada a possibilidade de utilização do sistema como parâmetro e que as
informações sejam recuperadas e organizadas para o determinado fim.
A reutilização é realizada em um nível de abstração mais elevado, no qual existem
soluções mais gerais para um dado problema, que podem ser aplicadas em
contextos semelhantes. Portanto, é preciso, primeiramente, definir o domínio,
analisá-lo, desenvolver sua arquitetura e, por fim, construir seus componentes.
3.2.2 Qualificação, adaptação e composição de componentes
Componentes são abstrações de nível mais alto que os objetos individuais de um

software e são definidos por suas interfaces, sem que os detalhes de implementação
sejam encapsulados de outros componentes. A engenharia de software baseada em
componentes é, de forma geral, pouco acoplada aos sistemas, sendo que o fluxo do
processo compreende a definição, implementação e integração de componentes
independentes.
Utilizar corretamente um padrão de projeto pata desenvolvimento de sistemas acarreta uma

série de benefícios para tornar mais ágil e eficiente toda a estrutura de tecnologia de uma
corporação.
Uma grande empresa de tecnologia implantou, há alguns anos, os chamados ‘serviços inteligentes’.
Na época, estes sistemas tinham como objetivo diminuir as chamadas perdidas por meio dos
serviços ‘siga-me’, ‘caixa-postal’ e ‘desvio de chamada’. Os serviços – sistemas – não foram
implantados todos de uma vez e foi estipulado um determinado padrão para a implantação do
primeiro serviço, o qual foi utilizado para a implantação dos outros. Houve uma redução de 30% de
desenvolvimento e implantação dos sistemas posteriores, pois a utilização do mesmo padrão
agregou a experiência do primeiro sistema nos demais. Isso é chamado de ‘curva de experiência’.
Outro conceito fundamental na engenharia de componentes é um modelo de

componente-padrão, que pode ser implantado de forma independente e sem
modificações, de acordo com um padrão de composição. Essa definição é baseada
em padrões, pois uma unidade de software que esteja em conformidade com esses
padrões é um componente.
Por fim, um componente pode ser definido como uma unidade de composição com
interfaces contratualmente especificadas e que tenha dependências de contexto
explícitas. O que temos é que um componente de software é implantado,
independentemente do sistema, e tem a possibilidade de ser composto por outros
componentes.
61
Na arquitetura de software, a reutilização de modelos é considerada uma das estratégias com mais
receptividade nas propostas metodológicas, chegando a envolver de forma exaustiva o conceito de modelo.
Ela promete, na construção de uma aplicação de software, construir modelos e transformá-los de forma
semiautomática no código de um sistema de informação. Ainda existem grandes desafios para se enfrentar
na adoção de enfoques centrados em modelos, como uma grande diversidade de técnicas, linguagens e
ferramentas para transformar modelos. Acesse o artigo publicado por Quintero; Duitama-Muñoz (2011) e
leia mais: <http://revistas.javeriana.edu.co/index.php/iyu/article/view/1131/810>.
O processo de composição entre componentes, que tem o objetivo de criar um

sistema ou outro componente, denomina-se integração de componentes, e existem
várias maneiras de compô-los. Mostraremos, na figura a seguir, a representação da
composição sequencial, a composição hierárquica e a composição aditiva, de
acordo com Sommerville (2011).

Figurã 4 - Tipos de composição de componente com os diãgrãmãs de composição sequenciãl (ã), composição
hierãrquicã (b) e composição ãditivã (c). Fonte: Elãborãdã pelo ãutor, bãseãdo em SOMMERVILLE, 2011.
#PraCegoVer: Ilustra os Tipos de composição de componente com os diagramas de

composição sequencial (a), composição hierárquica (b) e composição aditiva (c). A
imagem contém retângulos para representar os componentes com as respectivas
composições.
62
Na composição sequencial, apresentada no item (a) da figura apresentada, é criado

um novo componente a partir de dois componentes existentes. Aqui, no entanto, os
componentes não chamam uns aos outros, e sim algum código de ligação extra é
necessário para chamar os serviços de componente na ordem correta e garantir que
os resultados que forem entregues por componente sejam compatíveis com as
entradas esperadas pelo componente.
Segundo Sommerville (2011), as interfaces ‘provides’ e ‘require’ da composição
dependem da funcionalidade combinada de A e B, mas, normalmente, essa não será
uma composição de suas interfaces ‘provides’. Esse tipo de composição pode ser
usado com componentes, que são elementos de programa, ou componentes, que
são serviços.
Uma das boas práticas de engenharia de software é a utilização do reuso, acarretando uma melhoria
considerável para a qualidade dos artefatos de software. Nesse sentido, pesquisas em engenharia de
domínio têm proposto métodos e abordagens, objetivando e apoiando o reuso de software. Quer ler mais?
Acesse a dissertação de Brandes; Bacelo (2010) em:
<http://repositorio.pucrs.br/dspace/bitstream/10923/6778/1/000460611-Texto%2bCompleto-0.pdf>.
Na composição hierárquica, apresentada no item (b) da figura apresentada

anteriormente, acontece quando um componente chama de forma direta os serviços
prestados por outro componente. Portanto, a interface ‘provides’ do componente
chamado deve ser compatível com a interface ‘requires’ do componente chamador.
Segundo Sommerville (2011), o componente A chama diretamente o componente B
e, se suas interfaces corresponderem, pode não haver necessidade de código
adicional. Mas, se houver uma incompatibilidade entre a interface ‘requires’ de A e a
interface ‘provides’ de B, algum código de conversão pode ser necessário.
Fonseca Filho (2007, p. 101) explica a importância do engenheiro Konrad Zuse para a evolução da Ciência
da Computação: “[...] foi o primeiro engenheiro a criar máquinas de cálculo controladas automaticamente.
Esse engenheiro civil percebeu de forma rápida que um dos aspectos mais onerosos ao se fazerem longos
cálculos com dispositivos mecânicos era guardar os resultados intermediários para depois utilizá-los nos
lugares apropriados nos passos seguintes. Este foi um dos princípios da computação moderna”.
Por fim, na composição aditiva, que corresponde à situação (c) na figura apresentada
anteriormente, ocorre quando dois ou mais componentes são colocados juntos para
se criar um novo componente, que engloba suas funcionalidades. A interface
‘provides’ e a interface ‘requires’ do novo componente é uma combinação das
interfaces correspondentes nos componentes A e B. Conforme descrito por
Sommerville (2011, p. 326), “Os componentes são chamados separadamente por
meio da interface externa do componente composto. A e B não são dependentes e
63
não chamam uns aos outros”. Esse tipo de composição pode ser usado com
componentes.
3.3 Pãdroes de projeto
O conceito de padrões de projeto para desenvolver sistemas de softwares é originado

da área da arquitetura. É comum arquitetos utilizarem uma série de elementos de
projetos arquitetônicos estabelecidos, como arcos e colunas, ao projetarem edifícios.
Neste sentido, Sommerville (2011, p. 133) descreve:
Os padrões de projeto foram obtidos a partir das ideias apresentadas por Christopher
Alexander [...], que sugeriu haver padrões comuns de projeto de prédios que eram
inerentemente agradáveis e eficazes. O padrão é uma descrição do problema e da essência
de sua solução, de modo que a solução possa ser reusada em diferentes contextos. O
padrão não é uma especificação detalhada. Em vez disso, você pode pensar nele como uma
descrição de conhecimento e experiência, uma solução já aprovada para um problema
comum.
Sommerville (2011) explica que os padrões de projeto são comumente associados

aos padrões de orientação a objeto, pois consideram características como herança
e polimorfismo. Os padrões são uma forma de reutilizar o conhecimento e a
experiência de outros projetos. Segundo Sommerville (2011, p. 133), os quatro
elementos essenciais dos padrões de projeto são definidos como:
• Um nome que seja uma referência significativa para o padrão.

• Uma descrição da área de problema que explique quando o modelo pode
ser aplicado.
• A descrição da solução das partes da solução de projeto, seus
relacionamentos e suas responsabilidades. Essa não é uma descrição do
projeto concreto; é um modelo para uma solução de projeto que pode ser
instanciado de diferentes maneiras. Costuma ser expresso graficamente e
mostra os relacionamentos entre os objetos e suas classes na solução.
• Uma declaração das consequências — os resultados e compromissos — da
aplicação do padrão. Pode ajudar os projetistas a entenderem quando um
padrão pode ou não ser usado em uma situação particular.
Sommerville (2011) explica que, para podermos ilustrar a descrição de padrão,

devemos utilizar o padrão ‘Observer’, conforme demonstraremos no quadro a seguir.
64

Quãdro 1 - Descrição do pãdrão ‘Observer’, demonstrãndo suãs cãrãcterísticãs, suãs descriçoes, seus problemãs,
suãs soluçoes e suãs consequenciãs. Fonte: Elãborãdo pelo ãutor, bãseãdo em SOMMERVILLE, 2011.
65
#PraCegoVer: Contém uma tabela com a descrição do padrão ‘Observer’,

demonstrando suas características, suas descrições, seus problemas, suas soluções
e suas consequências. A tabela contém duas colunas. A descrição do padrão
Observer é: separa o display do estado de um objeto a partir do objeto em si e permite
que sejam fornecidos displays alternativos. Quando o estado de um objeto muda,
todos os displays são automaticamente notificados e atualizados para refletir a
mudança. A descrição de um problema que o padrão 'Observer' se propões a
resolver, é: Em muitas situações, você precisa fornecer displays de informações do
estado, como um display gráfico e em tabela. Nem todos eles podem ser conhecidos
quando a informação é especificada. Todas as apresentações alternativas devem
apoiar a interação e, quando o estado é alterado, todos os displays devem ser
atualizados. Esse padrão pode ser usado em todas as situações em que mais de um
formato de displays de informações de estado é necessário, e em que saber sobre
os formatos de display específicos usados não é necessário para o objeto que
mantém as informações do estado. A descrição da solução que o padrão 'Observer'
se propõe é: Trata-se de dois objetos abstratos, Subject e Observer, e dois objetos
concretos, ConcreteSubject e Concrete Observer, que herdam os atributos dos
objetos abstratos relacionados. Os objetos abstratos incluem as operações gerais
aplicáveis em todas as situações. O estado a ser exibido e mantido no
ConcreteSubject, que herda as operações de Subject permitindo adicionar ou
remover Observers (cada Observer corresponde a um display) e emitir uma
notificação quando o estado mudar. O ConcreteObserver mantém uma cópia do
estado do ConcreteSubject e implementa a interface atualizar do Observer, que
permite que essas cópias sejam mantidas nessa etapa. Automaticamente, o
ConcreteObserver exibe o estado e reflete as mudanças sempre que o estado é
atualizado. A descrição das consequências é: O Subject só reconhece o Observer
abstrato e não sabe detalhes da classe concreta. Portanto, há um acompanhamento
mínimo entre esses objetos. Devido a essa falta de conhecimento, as otimizações
que melhoram o desempenho do display são impraticáveis. As alterações no Subject
podem causar uma série de atualizações ligadas aos Observers relacionados para
serem geradas, algumas das quais podem não ser necessárias.
Sommerville explica que, para usar padrões em projetos, é necessário reconhecer

que qualquer problema de projeto pode ter um padrão associado que pode ser
aplicado e expõe esses problemas (2011, p. 134):
• Dizer a vários objetos que o estado de algum outro objeto mudou.

• Arrumar as interfaces para vários objetos relacionados que, muitas vezes,
foram desenvolvidos de forma incremental.
• Fornecer uma forma padronizada de acesso aos elementos de uma coleção,
independentemente de como essa coleção é implementada.
• Permitir a possibilidade de estender a funcionalidade de uma classe
existente em run-time (padrão Decorator).
Segundo Sommerville (2011), as representações gráficas são normalmente usadas

para ilustrar as classes de objeto em padrões e seus relacionamentos. Estes
suplementam a descrição do padrão e acrescentam detalhes à descrição da solução.
A figura a seguir demonstra a representação do padrão 'Observer' em UML.
66

Figurã 5 - Demonstrãção de um modelo ÚML do pãdrão 'Observer' mostrãndo ã relãção entre ãs clãsses. Fonte:
#PraCegoVer: Ilustra a demonstração de um modelo UML do padrão 'Observer'

mostrando a relação entre as classes. A imagem contém um diagrama de classes,
onde as classes Subject e Observer se relacionam. Contém também a classe
ConcreteSubject que herda de Subject e a classe ConcreteObserver que herda de
Observer. A classe Subject contém os métodos Anexar() e Separar() que recebem
um Observer por parâmetro, e também contém o método Notificar(), sem parâmetros.
A classe ConcreteSubject contém o método ObterEstado(). As classes Observer e
ConcreteObserver contêm o método Atualizar().
Por fim, os padrões podem suportar reuso de conceito em alto nível. Ao buscar o
reuso de componentes executáveis, pode acontecer de ter limitações nas decisões
do projeto detalhado feito pelos implementadores: desde os algoritmos particulares
(que são usados para implantar os componentes) até os objetos e a interface de
componentes.
3.3.1 Tipos de padrões
Padrões de projeto de software são recursos utilizados para melhorar a qualidade

deste e têm o objetivo de fornecer boas práticas para problemas encontrados em
diversas atividades do desenvolvimento de software.
Existem algumas topologias que os definem, e os processos de criação dos objetos
são abstraídos dos padrões de projetos. O objetivo, portanto, é que os padrões façam
67
com que o sistema se torne independente da forma como são seus objetos. Uma
topologia é apresentada por Farias (2006, p. 31, grifos nossos) e descreve que os
padrões podem ser classificados como:
• Padrões estruturais: tem como objetivo se ocupãrem com ã mãneirã como clãsses e
objetos são compostos pãrã criãr estruturãs mãiores. Então, ãs herãnçãs são utilizãdãs
pelos pãdroes de clãsse pãrã que sejãm compostãs ãs interfãces ou implementãçoes. Por
outro lãdo, os objetos descrevem como os objetos devem ser compostos pãrã ãs novãs.
• Padrões comportamentais: têm como foco o algoritmo e as responsabilidades
atribuídas entre os objetos do sistema. Não é objetivo, portanto, descrever
os padrões em si, mas as comunicações que são realizadas entre os objetos.
• Padrões para persistência: têm como objetivo descrever soluções para
problemas de armazenamento de informações.
• Padrões para apresentação: têm como objetivo definir as soluções para
problemas comuns no projeto da interface de software. É considerado um
caso particular dos padrões de projeto.
Outra topologia demonstrada por Lagmann (2013, p. 101) descreve que a
[...] utilização de padrões formaliza o método de descrição dos padrões, e o uso de padrões
não limitaria os desenvolvedores às soluções prescritas, mas garantiria a presença de
elementos fundamentais, e a possibilidade de aperfeiçoa-la através das experiências
adquiridas.
No quadro a seguir, apresentaremos os padrões de projeto de software, descrevendo

o objetivo de cada um.
68
69

Quãdro 2 - Descriçoes dos pãdroes de projeto de ãrquiteturã com os principãis objetivos de cãdã um. Fonte:
Elãborãdo pelo ãutor, bãseãdo em LAGMANN, 2013.
#PraCegoVer: Ilustra as descrições dos padrões de projeto de arquitetura com os

principais objetivos de cada um. A imagem contém uma tabela com os padrões e
seus respectivos objetivos, listados a seguir. Registry: um objeto conhecido para
localizar outros objetos. Facade: fornece uma interface unificada para um conjunto
de subsistema. Remote Facade: promove uma interface unificada para um conjunto
de subsistemas que são acessados remotamente. Service Layer: define o limite de
uma aplicação com uma camada de serviços que disponibiliza um conjunto de
operações e coordena a resposta a cada operação. Model View Presenter: Define a
aplicação em três regras distintas, a fim de isolar as diferentes responsabilidades em
Model, Vew e Presenter. Layer Supertype: um tipo que atua como um supertipo para
os demais componentes de uma camada. Data Transfer Object: este padrão tem o
objetivo de definir objetos que trafegam entre os processos da aplicação sobre os
quais são efetuadas as operações do sistema. Separated Interface: define a interface
de uma classe em um componente diferente de sua implementação. Gateway: este
padrão tem o objetivo de encapsular em um objeto o acesso a alguns recursos ou
sistema externo. Unit os Work: um objeto que contém a relação de objetos que foram
afetados por uma transação comercial. Query Object: um objeto que representa uma
consulta do banco de dados. Data Mapper: este padrão tem o objetivo de isolar o
mapeamento entre o modelo relacional do banco de dados ao modelo orientado a
objetos. Repository: disponibiliza uma interface para manipular dados em um formato
de coleção de dados. Lazy Load: um objeto que não contém todos dados
necessários, mas sabe como buscá-los. Singleton: este padrão tem o objetivo de
manter existência de apenas uma instância de um objeto, mantendo um ponto global
de acesso. Abstract Factory: permite a criação de objetos por meio de uma única
interface, sem que a classe concreta seja especificada. Dependency Injection: é
utilizado para manter um baixo acoplamento entre os diferentes componentes de um
sistema. Service Locator: este padrão visa encapsular e abstrair os processos
envolvidos na obtenção de um objetivo.
Portanto, por meio da demonstração das topologias, é possível confirmar a

importância em se desenvolver projetos baseados em padrões como forma de
garantir a qualidade interna do software por meio das especificações de cada padrão.
3.4 Projeto de software bãseãdo em pãdroes
Qual o objetivo de construirmos projetos de software baseando-se em padrões?

Fundamentalmente, baseia-se nas boas práticas de reuso de soluções, porém vai
além disso: projetos baseados em padrões auxiliam no entendimento da arquitetura
pelos desenvolvedores, firmam a conformidade entre a arquitetura proposta e
efetivamente implantada e, consequentemente, reduzem o tempo de implantação.
Portanto, quando desenvolvemos projetos de sistemas baseados em padrões, temos
70
uma prática de uso dos atributos de qualidade, contando que as características de

qualidade de uma determinada arquitetura estão descritas no próprio padrão.
3.4.1 Contexto do projeto baseado em padrões
Conforme demonstrado por Azevedo (2014, p. 23), as decisões arquiteturais
compreendem decisões estratégicas feitas durante o projeto de arquitetura. Estas decisões

possuem alto impacto sobre o alcance de metas do negócio que o software se propõe. Estas
decisões também possuem impacto sistêmico, quer dizer, impactam em mudanças na
estrutura e no comportamento de todo o sistema. As decisões tomadas sobre o contexto do
projeto envolvem criação de regras de projeto e de restrições aos componentes, pois define
o que o sistema ou partes dele não poderá realizar e inclusive como não poderá ser utilizado.
O que temos é que padrões de projeto não possuem, necessariamente, um foco em

preocupações de arquitetura, mas podem ser interpretados de um ponto de vista
arquitetural. Na verdade, vários pesquisadores argumentam que é difícil conhecer
um limite entre padrões arquiteturais e padrões de projeto.
Nas últimas décadas, o software deixou de ser uma parte pequena e de custo baixo
dos sistemas para se tornar parte fundamental e dispendiosa. Hoje em dia, tudo o que
se toca tem software, seja no uso doméstico ou nas organizações. O artigo de Silva
Filho (2015) discute a onipresença do software, as mudanças no cotidiano das pessoas
e organizações, e a preocupação com profissionais da área de engenharia de software.
Leia mais
em: <http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/29122/151
24>.
Podemos incluir, entre os elementos do contexto que devem ser considerados

durante a seleção de uma opção arquitetural, conforme o seguinte quadro:
71

Quãdro 3 - Elementos do contexto que devem ser considerãdos durãnte ã seleção de umã opção ãrquiteturãl.
Fonte: Elãborãdo pelo ãutor, bãseãdo em AZEVEDO, 2014.
#PraCegoVer: Ilustra os Elementos do contexto que devem ser considerados durante

a seleção de uma opção arquitetural. A imagem contém uma tabela com duas
colunas. A primeira coluna contém os seguintes termos: restrições de negócio,
restrições técnicas, atributos de qualidade, domínio da aplicação, e, requisitos
funcionais. O texto da segunda coluna para restrições de negócios é: A quantidade
de recursos disponíveis, as características da indústria, o tempo disponível para
finalização do projeto, entre outros fatores relativos ao negócio que o software apoia
devem ser considerados durante a escolha de uma opção arquitetural. O texto para
restrições técnicas é: Uma arquitetura deve estar em conformidade com restrições
impostas por ações tecnológicas resolvidas de antemão. O texto para atributos de
qualidade é: os atributos de qualidade influenciam as decisões arquiteturais, uma vez
que estes são operacionalizados em boa parte pelo projeto de arquitetura. O texto
para domínio da aplicação é: o fato de o software ser um sistema para internet, ou
um sistema de tempo real, ou um sistema stand-alone limita as opções arquiteturais
disponíveis para escolha. O texto para domínio da aplicação é: Uma vez que entre
os objetivos de se arquitetar figura a necessidade de criar arquiteturas que
possibilitem dividir o trabalho de implementação do software de maneira razoável, os
requisitos funcionais também influenciam na estruturação da arquitetura de software.
Conforme explicado por Azevedo (2014), mesmo que se compreenda a relevância

de vários fatores de contexto na tomada de decisão em arquitetura de software,
devido à necessidade de estreitar o escopo, a maioria dos projetos restringe-se a
considerar requisitos de qualidade como parâmetros de tomada de decisão.
72
3.4.2 Tarefas de projetos
Padrões de software costumam ser especificados por meio da descrição textual de

seus componentes, relacionamentos e maneiras que relacionam entre si. Segundo
Azevedo (2014, p. 30, grifos nossos), as tarefas de projeto de software podem ser
classificadas como:
• Definição das tarefas que serão executadas;

• Momento em que determinada tarefa deverá ser executada;
• Responsáveis por executar tais tarefas;
• Padronização no processo de desenvolvimento do projeto.
Segundo Sommerville (2011), a tarefa de um projeto de software é um conjunto

estruturado de atividades e resultados que satisfaça um conjunto de objetivos e
padrões. O projeto da arquitetura consiste em descrever as tarefas em um nível mais
elevado, com seus elementos fundamentais e, a seguir, executar o refinamento dos
seus recursos e suas funcionalidades, demonstrando como interagem e efetuando a
decomposição.
Síntese
Concluímos este capítulo compreendendo como distinguir projeto de conteúdo de projeto funcional
e suas fronteiras. Também foi possível compreendermos os fundamentos de componentes para
ambiente web e aplicativos móveis. Apresentamos como analisar o processo de desenvolvimento
baseado em componentes, a engenharia de domínios e demonstramos os padrões de projeto e
projetos baseados em padrões.
• conhecer projetos de conteúdo e funcional;

• compreender os sistemas baseados em componentes;
• diferenciar os tipos de padrões de projeto;
• realizar as descrições de padrões;
• analisar os projetos baseados em padrões.
Projeto
PROJETO DE SOFTWARE BASEADO EM PADRÕES
73
Projetar software orientado a objetos é difícil e projetar software

orientado a objetos reutilizáveis é ainda mais. Você deve encontrar
objetos pertinentes, fatorá-los em classes na granularidade correta,
definir interfaces de classes e hierarquias de herança e estabelecer
relacionamentos-chave entre eles. Seu design deve ser específico
para o problema em questão, mas também geral o suficiente para
resolver problemas e requisitos futuros. Você também deseja evitar o
reprojeto, ou pelo menos minimizá-lo. Desenvolvedores experientes
dirão que um design reutilizável e flexível é difícil, senão impossível,
de acertar na primeira vez. Antes de um design terminar, eles
geralmente tentam reutilizá-lo várias vezes, modificando-o a cada
ocasião.
No entanto, desenvolvedores experientes fazem bons projetos.

Enquanto isso, os novos profissionais ficam impressionados com as
opções disponíveis e tendem a recorrer às técnicas não orientadas a
objetos que usaram antes. Demora muito tempo para os iniciantes
aprenderem o que é um bom design orientado a objetos.
Desenvolvedores experientes evidentemente sabem algo que os
inexperientes não conhecem. O que é isso?
Uma coisa que os especialistas entendem que não deve fazer é

resolver todos os problemas, desde os primeiros princípios. Em vez
disso, eles reaproveitam soluções que funcionaram para eles no
passado. Quando encontram um bom recurso, usam-no
repetidamente. Essa experiência faz parte do que os torna
especialistas. Consequentemente, você encontrará padrões
recorrentes de classes e objetos de comunicação em muitos sistemas
orientados a objetos. Esses padrões resolvem problemas de design
específicos e tornam os designs orientados a objetos mais flexíveis,
elegantes e, finalmente, reutilizáveis. Eles ajudam os designers a
reutilizar projetos bem-sucedidos, baseando-os na experiência
anterior. Um designer familiarizado com esses padrões pode aplicálos
imediatamente a problemas de design sem precisar redescobrilos.
74
Uma analogia ajudará a ilustrar o ponto. Romancistas e dramaturgos

raramente projetam suas tramas do zero. Em vez disso, seguem
padrões como "Herói tragicamente imperfeito" (Macbeth, Hamlet etc.)
ou "O romance romântico" (inúmeros romances). Da mesma forma,
os designers orientados a objetos seguem padrões como representar
estados com objetos e modificar objetos para que você possa
adicionar/remover recursos com facilidade. Depois de conhecer o
padrão, muitas decisões de design são seguidas automaticamente.
Todos sabemos o valor da experiência em design. Quantas vezes você

teve um déjà-vu, aquela sensação de que já havia resolvido um
problema antes, mas sem saber exatamente onde ou como? Se você
se lembra dos detalhes do problema anterior e como o resolveu,
poderá reutilizar a experiência em vez de redescobri-la. No entanto,
não fazemos um bom trabalho de gravação de experiência em design
de software para outras pessoas usarem.
Cada padrão de design nomeia, explica e avalia sistematicamente um

design importante e recorrente em sistemas orientados a objetos.
Nosso objetivo é capturar a experiência de design de uma forma que
as pessoas possam usar de maneira eficaz. Para esse fim,
documentamos alguns dos padrões de design mais importantes e os
apresentamos como um catálogo.
Os padrões de design facilitam a reutilização de projetos e

arquiteturas de sucesso. Expressar técnicas comprovadas como
padrões de design permitem que elas se tornem mais acessíveis aos
desenvolvedores de novos sistemas. Os padrões de design ajudam a
escolher alternativas de design que convertem um sistema reutilizável
e evitam alternativas que comprometem a reutilização. Os padrões de
design podem até melhorar a documentação e a manutenção dos
sistemas existentes, fornecendo uma especificação explícita das
interações de classe e objeto e sua intenção subjacente.
75
Simplificando, os padrões de design ajudam um designer a obter um

design correto mais rapidamente.
Nesse contexto, utilizar padrões de projetos (ou padrões de design ou

design patterns) melhora a qualidade do software a ser construído e
facilita o projeto arquitetural.
Vamos Praticar
Baseado no caso mencionado acima, como os padrões de projetos de software podem ser
utilizados para que melhore a qualidade do software e o projeto de arquitetura? Além disso, de
que maneira os padrões de projeto permitem a criação de arquiteturas robustas? Ao final,
disponibilize seu trabalho no fórum da seção.
Referências
HOFMEISTER, C.; NORD, R.; SONI, D. Applied software architecture.


ARQUITETURA DE
SOFTWARE
U4 - COMO O DESENVOLVEDOR
DEVE DECIDIR SOBRE QUAL
76
ARQUITETURA UTILIZAR OU SE
DEVE TERCEIRIZAR O
DESENVOLVIMENTO?
Introdução
As tecnologias da informação, tanto do hardware quanto do software, têm evoluído

consideravelmente nas últimas décadas. Novos padrões de usabilidade, como o touch screen,
aplicações web integrando diversas funcionalidades e com novos paradigmas de acessibilidade
e uma grande evolução dos aplicativos móveis têm forçado os desenvolvedores de sistemas a
desenvolverem e adotarem novos modelos e padrões de arquitetura de software.
Diante desse cenário, temos as seguintes questões: quais são os modelos e padrões para
aplicações web e de aplicativos móveis? Quais são os parâmetros que auxiliam os
desenvolvedores a utilizarem determinado padrão? Como são desenvolvidos e aplicados os
projetos de arquitetura? É mais coerente desenvolver ou terceirizar o desenvolvimento de um
aplicativo? Para respondê-las, abordaremos neste capítulo como o desenvolvedor deve decidir
sobre qual arquitetura utilizar ou se deve terceirizar o desenvolvimento. Analisaremos como
identificar os padrões de arquitetura para ambiente web e para dispositivos móveis.
Explicaremos o que são sistemas distribuídos e quais são seus padrões. Mostraremos, também,
os sistemas embutidos, suas características e como criar projetos de arquitetura para tais
sistemas. Por fim, demonstraremos a web service e a arquitetura orientada a serviços.
Após a explanação desses tópicos, você será capaz de decidir quais os padrões e modelos de
arquitetura adotar, como aplicá-los a cada situação específica e objetivo de determinado
sistema, obtendo sistemas eficientes e com alto nível de qualidade.
4.1 Pãdroes de projeto e formãs ãlternãtivãs ão

desenvolvimento de sistemãs
É fundamental que os desenvolvedores de sistemas utilizem os princípios de

arquitetura de software, visto a melhora na eficiência e no desempenho dela, além
de tornar mais ágil a capacidade de efetuar as manutenções. Diante disso, podemos
nos questionar: quais as formas alternativas de um padrão de projeto para
manutenção de software? Como decidir pelo melhor padrão? Quais os impactos da
decisão sobre a qualidade do software? Como explica Sommerville (2011, p. 124), “o
projeto de software é uma atividade criativa em que você identifica os componentes
de software e seus relacionamentos com base nos requisitos do cliente”. Ou seja,
após o levantamento dos requisitos funcionais e não funcionais, inicia-se a
modelagem do padrão do sistema, elencando seus componentes e a forma como
77
eles se relacionam. Um exemplo, como forma alternativa, é projetar um software

orientado a objetos. Como descreve Monteiro (2002, p. 1),
Projetãr softwãre orientãdo ã objetos e umã tãrefã difícil, mãs projetãr softwãre reutilizãvel orientãdo ã
objetos e ãindã mãis difícil. E necessãrio modelãr objetos pertinentes, fãtorã -los em clãsses no nível correto
de grãnulãridãde, definir ãs interfãces dãs clãsses e ãs hierãrquiãs de herãnçã e estãbelecer ãs relãçoes
entre eles.
É fundamental a escolha correta da forma alternativa de um projeto no

desenvolvimento de um sistema, visto a complexidade da tarefa. Outra forma
alternativa de desenvolvimento é descrita por Sommerville (2011): o open source, que
é uma abordagem na qual o código-fonte é publicado e voluntários são convidados
a participar no processo de desenvolvimento (SOMMERVILLE, 2011). Esse tipo de
padrão define que o código-fonte não deve ser proprietário, e sim estar disponível,
para que os usuários o analisem e modifiquem conforme suas necessidades.
Segundo Sommerville (2011, p. 139), há duas questões de open source que devem
ser consideradas antes de se iniciar o desenvolvimento de um sistema:
• O produto que estã sendo desenvolvido deve fãzer uso de componentes ‘ open source’?
• Úmã ãbordãgem ‘open source’ deve ser usãdã pãrã o desenvolvimento de softwãre?
Há considerações que devem ser feitas na opção de um desenvolvimento open

source: se o sistema estiver sendo desenvolvido para uso comercial, a questão do
custo é um fator crítico; por outro lado, se o sistema estiver sendo desenvolvido em
um domínio de alta qualidade, o fator tempo é crucial. Mas, se o desenvolvimento do
sistema for direcionado para um conjunto específico de requisitos organizacionais, o
modelo open source pode não ser o mais indicado, pois pode ser necessário fazer a
integração com sistemas legados que são incompatíveis com os componentes open
source disponíveis.
4.1.1 Foco no projeto na definição de arquitetura
Segundo Pressman (2016), a arquitetura não é o software operacional, mas sim uma
representação que permite, primeiramente, analisar a efetividade do projeto para
atender os requisitos que foram declarados na engenharia de requisitos, considerar
as possíveis arquiteturas na fase inicial do projeto e, por fim, reduzir os riscos de
construção do software.
Conforme explicado por Langmann (2013), a definição da arquitetura de um software
influencia diretamente na sua qualidade, pois o sistema deve ser capaz de evoluir e
suportar mudanças, obtendo-se uma visão do software como um todo. O projeto de
um sistema, focando na sua arquitetura, consiste em descrever o sistema em um
nível mais alto, definindo seus principais elementos, que são os seus módulos. Na
sequência deve ser realizado o refinamento e detalhamento de seus recursos e suas
funcionalidades, explicitando como eles interagem. Demonstraremos na figura a
seguir a decomposição.
78

Figurã 1 - Modelo de decomposição de umã ãrquiteturã de sistemãs, indicãndo ã relãção entre os componentes.
Fonte: Elãborãdã pelo ãutor, ãdãptãdo de LANGMANN, 2013.
#PraCegoVer: Ilustra o modelo de decomposição de uma arquitetura de sistemas,

indicando a relação entre os componentes. A imagem contém um total de oito
losangos, representando componentes do sistema. No topo da imagem, existe um
destes losangos, contendo um organograma de subcomponentes. Cada um destes
subcomponentes, aponta para um dos demais componentes.
No momento da definição da arquitetura de um software, é fundamental que se

considere a modularidade, dividindo em componente e módulos, cada um com seu
propósito e demonstrando as entradas e a saída. Esses módulos deverão estar
organizados de forma hierárquica para que seja feita a decomposição. Conforme
explicado por Langmann (2013), durante o processo de decomposição, a cada nível
de um determinado módulo é necessário aperfeiçoar e detalhar os componentes do
nível superior. Portanto, o nível mais superior é onde se estabelece o maior nível de
abstração, pois ali são acopladas as informações dos detalhes de processamento.
Um projeto de arquitetura baseado em projeto deve aplicar os fundamentos de
engenharia de software para obter um alto índice de qualidade, como o acoplamento
e a coesão: o acoplamento significa o nível de dependência para poder funcionar
(quanto maior o nível de dependência, maior o acoplamento), já a coesão é o
princípio de responsabilidade exclusiva, ou seja, um componente deve ter apenas
um único objetivo.
Open source são recursos e serviços oferecidos pela internet, entregues a partir de centros de dados
localizados em todo o mundo. Com seu rápido crescimento, a preocupação com a necessidade de serviços
79
oferecidos e de implantar um ambiente tolerante a falhas é grande. Martins (2014) desenvolveu sua
dissertação com o objetivo de criar um mecanismo totalmente tolerante a falhas. Leia mais em:
<http://www.athena.biblioteca.unesp.br/exlibris/bd/cathedra/31-08-2015/000843909.pdf>.
É importante ressaltar a importância de identificarmos os padrões específicos para

aplicativos web e móveis. Primeiramente, aplicações web devem ser boas aplicações
hipermídia, porque a web é baseada no paradigma do hipertexto e ligações URL.
Portanto, a hipermídia e as navegações são atributos fundamentais para serem
criados padrões nas aplicações web. Outro fator importante nesta definição é que a
evolução das plataformas para implantação de aplicações web demonstra uma
tendência para adoção de arquiteturas modulares (nesse caso, em quais
componentes de programa e suas iterações seguem práticas consolidadas de
engenharia de software, como, por exemplo, separação de atribuições).
Para Júnior; Fortes (2007), uma subárea da Engenharia de Software está ganhando
bastante força: a Engenharia Web, tendo como principal característica o projeto
arquitetural, que é gerado como artefato de saída uma arquitetura web, e onde devem
ser atendidos os requisitos de alto grau de interação, uma distribuição em locais
fisicamente distintos e a necessidade de disponibilização contínua e rápida das
aplicações.
Como os sistemas web são considerados sistemas interativos, com arquitetura
distribuída, o padrão mais utilizado é o Model-View-Controller (MVC), cuja descrição
básica do seu comportamento considera que a Visão dispara eventos para o
Controlador e, a seguir, modifica o estado do Modelo, sendo que a Visão busca os
dados no Modelo.
Pressmann (2016) explica que a grande maioria dos aplicativos web possibilita um
diálogo entre o usuário e a funcionalidade da aplicação. Esse diálogo pode ser
descrito como “modelo de interações”, composto pelos seguintes elementos:
• cãsos de uso;
• diãgrãmãs de sequenciã; • prototipos de interfãce.
Pressmann (2016) demonstra que o modelo funcional de uma aplicação web lida com
dois elementos de processamento: as funcionalidades observáveis pelo usuário e as
operações contidas nas classes do sistema. Por outro lado, este mesmo autor (2016)
explica que o modelo de navegação expõe como cada categoria de usuário navegará
de um elemento web para outro, sendo que a lógica de navegação é definida como
parte do projeto. Por fim, o padrão para web pode usar a maioria dos elementos do
padrão de sistemas tradicionais, adicionando-se características próprias desse
ambiente: conteúdo, interação, navegação e configuração cliente-servidor.
Software como um serviço (SaaS) é um paradigma de desenvolvimento de sistemas

que permite dispor de soluções flexíveis de fácil acesso com baixo investimento. Essa
metodologia tem sido adotada por diversas empresas como suporte nos processos de
negócio, sendo uma solução de tecnologia. Saiba mais no artigo escrito por Araújo;
Cota (2016): <http://www.scielo.mec.pt/pdf/rist/n19/n19a12.pdf>.
80
Neste ponto, é interessante explorar o padrão para ambiente de dispositivos móveis.

Aqui, as arquiteturas podem ser agrupadas em web mobile distribuídas e
centralizadas. Segundo Budel; Barbara; Molossi (2011), a arquitetura web mobile é
basicamente uma aplicação web que está hospedada em um servidor e será
acessada por meio de um navegador dos dispositivos móveis. A arquitetura
distribuída desacopla as regras de negócios (que estão na camada de modelo) das
regras de apresentação (localizadas na camada de visão e controle).
Um exemplo desta arquitetura é mostrado na figura a seguir, que mostra o código do
dispositivo móvel (camada de visão e controle) buscando e recebendo as
informações na camada web (camada de modelo). Nesta camada, por sua vez, estão
as funções que processam e retornam os dados para o dispositivo.

Figurã 2 - Estruturã mãcro dã ãrquiteturã web mobile distribuídã, explicitãndo ã relãção entre ã ãplicãção mobile
e ãs ãplicãçoes do serviço web. Fonte: Elãborãdã pelo ãutor, ãdãptãdo de BÚDEL; BARBARA; MOLOSSI, 2011.
#PraCegoVer: Ilustra a estrutura macro da arquitetura web mobile distribuída,

explicitando a relação entre a aplicação mobile e as aplicações do serviço web. A
imagem contém, da esquerda para a direita, um quadrado com a inscrição Aplicação
mobile, que se comunica bilateralmente com um segundo quadrado, que contém a
inscrição Serviço Web, que se subdivide em Aplicação A, Aplicação B, e Aplicação C.
Budel; Barbara; Molossi (2011, p. 8-9) explicam as vantagens deste modelo:
• A publicãção (deploy) dã ãplicãção web mobile tornã-se independente dos serviços remotos
utilizãdos por elã.
• O controle de versoes dã ãplicãção web mobile ficã segregãdo de quãlquer serviço web
utilizãdo.
• Desãcoplãmento entre ã ãplicãção web mobile e ãs regrãs negociãis envolvidãs nos serviços
web consumidos.
• A ãplicãção web mobile pode reusãr diversãs funcionãlidãdes contidãs em outrãs
ãplicãçoes.
• Multiplãtãformã, devido suã nãturezã web.
• Possibilidãde de reusãr o sistemã de segurãnçã nãs ãplicãçoes web mobile.
• Não requer instãlãção do ãplicãtivo no dispositivo movel.
81
Por outro lado, estes mesmos autores (2011, p. 9) explicam as desvantagens:
• Desenvolver funcionãlidãdes em formã de serviço pode ser dispendioso.

• Mudãnçãs ou indisponibilidãde dos serviços web podem ãfetãr ã ãplicãção web mobile.
• O consumo de serviços remotos gerã tempos de respostã mãiores, ãlem de ãdicionãr mãis
um ponto de fãlhã pãrã ã ãplicãção web mobile.
• Não e possível utilizãr recursos nãtivos dos dispositivos moveis. Ex: cãmerã, sistemã de
ãrquivos, etc.
• Requer conectividãde (2G/3G ou Wi-Fi) pãrã utilizãção.
• Interfãces limitãdãs ãs cãrãcterísticãs do desenvolvimento web.
É necessário verificar, antes de se implantar esta arquitetura, se existem aplicações

que possam abrigar as funcionalidades.
Pereira (2011) demonstra, em sua pesquisa, a influência da arquitetura de software no desenvolvimento

distribuído de software, baseando-se na larga utilização de Arquitetura Orientada a Serviços (SOA) e
demonstrando a tendência do uso desse padrão de arquitetura de baixo acoplamento por comparações que
desenvolvem seus projetos de forma distribuída. Leia mais em:
<http://tede2.pucrs.br/tede2/bitstream/tede/5149/1/434651.pdf>.
Por outro lado, a arquitetura centralizada concentra uma aplicação exclusiva e com
responsabilidade relacionadas a todas as camadas (MVC). Neste modelo da camada
de visualização, o framework é utilizado para adaptar a apresentação da aplicação a
partir das características próprias de cada dispositivo móvel. A seguir,
apresentaremos um modelo de arquitetura centralizada.
82

Figurã 3 - Arquiteturã centrãlizãdã web pãrã dispositivos moveis, indicãndo ãs relãçoes entre ãs cãmãdãs. Fonte:
BÚDEL; BARBARA; MOLOSSI, 2011, p. 8.
#PraCegoVer: Ilustra a arquitetura centralizada web para dispositivos móveis,

indicando as relações entre as camadas. A imagem possui na sua base um retângulo
que contém as tecnologias empregadas na camada de visualização: JSP/TagLibs do
sistema, Struts Tiles, TagLibs do framework / JSTL / Struts / jQuery Mobile e,
Jasoer/FOP. Acima, do lado esquerdo, há um retângulo que representa a camada
Struts, que contém StrutsConfig.xml, acrionServlet, AcrionForm, e, Acrion. Acima, do
lado direito há um retângulo que representa a camada do Modelo, composta por
Facade, Hibernate, NatAPI, DAO e as Classes POJO. Um pouco mais acima, há um
quadrado representando o BD, que se comunica com Hibernate e DAO. Há também
outro quadrado que representa Mainframe e que se comunica com NatAPI.
Externamente, na lateral esquerda, há um retângulo que representa o Browser e que
se comunica com a camada de visualização e com os Struts
Nesse modelo demonstrado na figura, temos as seguintes camadas com os

frameworks e suas funções:
• cãmãdã de visuãlizãção: temos ã ferrãmentã de relãtorios Jãsper (pãrã

gerenciãmento de relãtorios), outros frameworks (como Strut e jQuery mobile, os
quãis tem como função criãr ãplicãçoes web e mecãnismos de interfãce) e ã
ferrãmentã JSTJ (responsãvel por recuperãr dãdos de um ãrquivo de contexto
XML);
• cãmãdã de modelo: temos ãs ferrãmentãs de ãcesso ã dãdos (como o DO, que
encãpsulã e ãbstrãi os dãdos, e o Hipernãte, um framework que fãz o mãpeãmento
entre umã bãse de dãdos e o objeto dã ãplicãção);
• entre ã cãmãdã de modelo e ã cãmãdã de controle, temos o pãdrão Fãcãde, que
ãcoplã ãs clãsses por meio de umã facade (fãchãdã);
• cãmãdã de controle: temos o StrutConfig.xml (ãrquivo de configurãção que trãtã
de fornecer um link entre os componentes Visão e Modelo). Ele desempenhã o
pãpel de criãção de componentes dã cãmãdã Controle e configurãçoes específicãs
do ãplicãtivo.
Outras arquiteturas para dispositivos móveis são as arquiteturas nativas, que são
aplicações implantadas para serem executadas no próprio ambiente do dispositivo
móvel.
4.1.2 Decisão entre produzir, comprar ou alugar
Segundo vários pesquisadores da arquitetura de software, somente se torna viável

fabricar um produto de software se ele tiver um alto valor agregado aos negócios da
empresa. Por outro lado, empresários alegam que a escolha deve ser feita com base
em uma análise estratégica: se a terceirização trouxer algum ganho de eficiência ou
melhores níveis de serviço, por exemplo. Porém, se a empresa desenvolve o próprio
83
sistema, ela se torna independente de terceiros e tem o poder sobre todo o processo
de desenvolvimento. O que acontece: na maioria das vezes, a decisão é tomada
somente com base em custos, ou seja, terceirizar reduz os custos? Existe, também,
a questão de fabricá-lo: a empresa pode, estrategicamente, desenvolver o sistema e
comercializá-lo, mesmo que esse não seja o seu ramo, planejando a diversificação
do negócio.
Segundo Sommerville (2011), uma das decisões de implementação mais importantes
que precisam ser tomadas em um estágio inicial de um projeto de software é se você
deve ou não comprar ou construir o software de aplicação. Atualmente, é possível
adquirir sistemas de prateleira (COTS, do inglês commercial off-the-shelf) em uma
ampla variedade de domínios. Os sistemas podem ser adaptados e ajustados aos
requisitos dos usuários. Por exemplo, se quiser implementar um sistema de
prontuário médico, você pode comprar um pacote que já seja usado em hospitais.
Essa abordagem pode ser mais barata e rápida do que desenvolver um sistema em
uma linguagem de programação convencional.
Com o propósito de atender à diversidade de preferências e necessidades de seus clientes, uma

grande instituição bancária no Brasil foi, nos últimos anos, disponibilizando serviços financeiros por
meio de vários canais de comunicação. Nem todos os canais oferecem todos os tipos de serviços,
além de existirem diferentes agrupamentos em um mesmo canal, em função do tipo de cliente.
Para solucionar esse problema, foi implantada a solução SOA, isto é, um conceito de arquitetura
que efetua a integração entre o negócio e a TI por meio de conjunto de interfaces de serviços
acoplados.
A implantação da SOA agregou valor aos negócios da instituição bancária, sendo um recurso
estratégico para o aumento da competitividade da organização.
Quando você desenvolve uma aplicação dessa forma, o processo de projeto se

preocupa em como usar os recursos de configuração desse sistema para cumprir os
requisitos do sistema. Usualmente, você não desenvolve modelos de projeto do
sistema, como os de objetos do sistema e suas interações.
4.2 Pãdroes de ãrquiteturã pãrã sistemãs distribuídos
A grande maioria dos sistemas de porte maior, atualmente, é distribuída. Segundo

Sommerville (2011, p. 333), “Um sistema distribuído [...] envolve vários
computadores, em contraste com sistemas centralizados, em que todos os
componentes do sistema executam em um único computador”. Portanto, como se
caracteriza uma arquitetura de sistemas distribuídos? Quais são os seus padrões e
modelagens? A engenharia de sistemas distribuídos terá muitas das características
da engenharia de sistemas centralizados, mas existem algumas que são específicas
a este padrão.
84
Coulouris et al. (2005 apud SOMMERVILLE, 2011, p. 333) demonstram as seguintes

vantagens da utilização de uma abordagem distribuída no desenvolvimento de
sistemas:
• Compãrtilhãmento de recursos. Úm sistemã distribuído permite o compãrtilhãmento de

recursos de hãrdwãre e softwãre.
• Aberturã. Gerãlmente, os sistemãs distribuídos são sistemãs ãbertos, o que significã que
são projetãdos pãrã protocolos-pãdrão que permitem que os equipãmentos e softwãres de
diferentes fornecedores sejãm combinãdos.
• Concorrenciã. Em um sistemã distribuído, vãrios processos podem operãr
simultãneãmente em computãdores sepãrãdos, nã rede.
• Escãlãbilidãde. Em princípio, pelo menos, os sistemãs distribuídos são escãlãveis, ãssim, os
recursos do sistemã podem ser ãumentãdos pelã ãdição de novos recursos pãrã fãzer fãce
ãs novãs exigenciãs do sistemã.
• Tolerãnciã ã defeitos. A disponibilidãde de vãrios computãdores e o potenciãl pãrã replicãr
ãs informãçoes significã que os sistemãs distribuídos podem ser tolerãntes com ãlgumãs
fãlhãs de hãrdwãre e softwãre.
É importante ressaltar que algumas vantagens podem ter alguma consequência

negativa. Por exemplo, o uso compartilhado de recursos pode ser econômico para a
organização em primeiro momento, porém o uso concorrente na rede pode baixar o
tempo de processamento. Na realidade, os sistemas distribuídos são, geralmente,
mais complexos do que os sistemas chamados centralizados.
Devido à complexidade causada pelas interações que existem entre os componentes
de todo sistema e infraestrutura, é mais difícil compreender as propriedades do
sistema como um todo. Sommerville (2011, p. 334) nos traz uma situação na qual
Por exemplo, em vez de o desempenho do sistemã depender dã velocidãde de execução de um processãdor,

ele depende dã lãrgurã dã bãndã de rede, dã cãrgã de rede e dã velocidãde de todos os computãdores que
fãzem pãrte do sistemã. Mover os recursos de umã pãrte do sistemã pãrã outrã pode ãfetãr
significãtivãmente o desempenho do sistemã.
Uma abordagem orientada a serviços deve permitir o acesso à funcionalidade do
sistema de aplicação, por meio de uma interface de serviço padrão, com um serviço
para cada unidade.
4.2.1 Questões a serem ponderadas em projetos de sistemas

distribuídos
Os sistemas distribuídos tendem a ser mais complexos do que os sistemas

tradicionais. Isso ocorre porque é muito difícil ter um modelo que faça o controle de
todas as plataformas integradas neste sistema. Sommerville (2011, p. 334) elenca as
questões mais importantes que devem ser consideradas em um projeto de um
sistema distribuído:
• Trãnspãrenciã. Em que medidã o sistemã distribuído deve ãpãrecer pãrã o usuãrio como
um unico sistemã? Quãndo e util ãos usuãrios entender que o sistemã e distribuído?
85
• Aberturã. Úm sistemã deveriã ser projetãdo usãndo protocolos-pãdrão que ofereçãm

suporte ã interoperãbilidãde ou devem ser usãdos protocolos mãis especiãlizãdos que
restrinjãm ã liberdãde do projetistã?
• Escãlãbilidãde. Como o sistemã pode ser construído pãrã que sejã escãlãvel? Ou sejã, como
todo o sistemã poderiã ser projetãdo pãrã que suã cãpãcidãde possã ser ãumentãdã em
respostã ãs crescentes exigenciãs feitãs ão sistemã?
• Proteção. Como podem ser definidãs e implementãdãs ãs políticãs de proteção que se
ãplicãm ã um conjunto de sistemãs gerenciãdos independentemente?
• Quãlidãde de serviço. Como ã quãlidãde do serviço que e entregue ãos usuãrios do sistemã
deve ser especificãdã e como o sistemã deve ser implementãdo pãrã oferecer umã
quãlidãde ãceitãvel e serviço pãrã todos os usuãrios?
• Gerenciãmento de fãlhãs. Como ãs fãlhãs do sistemã podem ser detectãdãs, contidãs (pãrã
que elãs tenhãm efeitos mínimos em outros componentes do sistemã) e repãrãdãs?
Assim, temos que o controle total de um sistema distribuído se torna impossível.

Fatores como arquiteturas diferentes entre computadores e dependência da rede
interferem nos sistemas distribuídos. Os sistemas distribuídos considerados abertos
são construídos de acordo com normas aceitas por outros componentes da
arquitetura. A abertura considera que os componentes de um sistema possam ser
integrados, independentemente da linguagem, desde que estejam em conformidade
com as normas de funcionamento dos outros componentes. Nesse sentido, a
escalabilidade de um sistema reflete a capacidade de oferecer um serviço com
qualidade, pois tende a aumentar a sua demanda.
Neuman (1994 apud SOMMERVILLE, 2011, p. 335) identifica três dimensões da
escalabilidade:
Assim, temos que o controle total de um sistema distribuído se torna impossível.
Fatores como arquiteturas diferentes entre computadores e dependência da rede
interferem nos sistemas distribuídos. Os sistemas distribuídos considerados abertos
são construídos de acordo com normas aceitas por outros componentes da
arquitetura. A abertura considera que os componentes de um sistema possam ser
integrados, independentemente da linguagem, desde que estejam em conformidade
com as normas de funcionamento dos outros componentes. Nesse sentido, a
escalabilidade de um sistema reflete a capacidade de oferecer um serviço com
qualidade, pois tende a aumentar a sua demanda.
Neuman (1994 apud SOMMERVILLE, 2011, p. 335) identifica três dimensões da
escalabilidade:
• Tãmãnho. Deve ser possível ãdicionãr mãis recursos ã um sistemã pãrã lidãr com um
numero crescente de usuãrios. Existe umã distinção entre escãlãmento pãrã cimã e
escãlãmento pãrã forã. Escãlãmento pãrã cimã significã ã substituição de recursos no
sistemã por recursos mãis poderosos. Escãlãmento pãrã forã significã ãdicionãr recursos
ão sistemã.
• Distribuição. Deve ser possível dispersãr geogrãficãmente os componentes de um sistemã
sem comprometer seu desempenho.
• Cãpãcidãde de gerenciãmento. E possível gerenciãr um sistemã ã medidã que ele ãumentã
de tãmãnho, mesmo que pãrtes dele estejãm locãlizãdãs em orgãnizãçoes independentes.
Uma questão importante nos sistemas distribuídos é a sua abertura a ataques. Se

uma determinada parte do sistema é invadida, isso pode ser usado como uma
86
entrada para outras partes do sistema. Conforme explicado por Sommerville (2011,
p. 336), os tipos de ataques dos quais um sistema distribuído deve se defender são:
• Intercepção, em que ãs comunicãçoes entre ãs pãrtes do sistemã são interceptãdãs por um

invãsor de tãl modo que hãjã umã perdã de confidenciãlidãde.
• Interrupção, em que os serviços de sistemã são ãtãcãdos e não podem ser entregues
conforme o esperãdo. Atãques de negãção de serviços envolvem bombãrdeãr um no com
solicitãçoes de serviço ilegítimãs, pãrã que ele não consigã lidãr com solicitãçoes vãlidãs.
• Modificãção, em que os dãdos ou serviços no sistemã são ãlterãdos por um invãsor.
• Fãbricãção, em que um invãsor gerã informãçoes que não deveriãm existir e, em seguidã,
usã-ãs pãrã obter ãlguns privilegios.
Um grande problema que pode ocorrer com relação aos sistemas distribuídos é
planejar uma política de proteção que seja aplicável a todos os componentes dos
sistemas.
Haskell B. Curry executou uma experiência complexa com o Eniac, um dos primeiros computadores
desenvolvidos, sugerindo uma notação mais compacta para o código. O ponto principal de interesse foram
os algoritmos de conversão de códigos. Houve uma descrição recursiva de um procedimento de conversão
de expressões aritméticas para um código de máquina apropriado, tornando Curry a primeira pessoa a
descrever a fase de geração de código de um compilador (FILHO, 2007).
Por outro lado, a qualidade do serviço (QoS, do inglês Quality of Service) significa a
capacidade de entregar seus serviços de maneira confiável e em um determinado
tempo de resposta que seja o esperado. O ideal é que os parâmetros de QoS sejam
especificados com bastante antecedência, mas essa não é uma tarefa fácil pelo
seguintes motivos: não é efetivo projetar e configurar o sistema para oferecer uma
alta QoS no momento de carga de pico, e os parâmetros de QoS podem ser
mutuamente contraditórios. Por exemplo, um alto índice de confiança pode gerar taxa
reduzida de transferência.
O filme O quinto poder (DOMSCHEIT-BERG et al., 2013) é baseado na história real de Julian Assange,
fundador do WikiLeakes, e que, por meio de uma plataforma desenvolvida por ele, expõe documentos
sigilosos do governo norte-americano, crimes corporativos e documentos de inteligência confidenciais da
história dos Estados Unidos.
Segundo Sommerville (2011) explica, existem dois tipos principais de interação que
podem ocorrer entre os computadores em um sistema de computação distribuído: a
procedural (envolve um computador que chama um determinado serviço de outro
computador já conhecido) e a baseada em mensagens (envolve um computador que
define as informações sobre o que é requerido em uma mensagem, enviando para
outros computadores).
87
Existe uma computação na nuvem chamada green cloud, que se baseia nos conceitos
da computação nas nuvens e a TI verde, com o objetivo de oferecer um ambiente
computacional flexível e eficiente. O artigo escrito por Westphall; Villarreal (2013)
demonstra os fundamentos e o estado da arte dessa tecnologia. Saiba mais em:
<http://www.periodicosibepes.org.br/index.php/reinfo/article/view/1050/0>.
De forma geral, a interação baseada em mensagens envolve um componente que

cria uma mensagem detalhando os serviços necessários de outro componente. Por
meio do middleware do sistema, ela é enviada para o componente que receberá a
solicitação. Por outro lado, o receptor realiza os processamentos da mensagem
recebida e cria uma mensagem para o componente que enviou a solicitação com os
resultados. A seguir, ela é passada para o middleware, para que seja transmitido ao
componente que enviou a solicitação.
Demonstraremos, na figura a seguir, um modelo genérico da interação baseada em
mensagens.

Figurã 4 - Middlewãre em um sistemã distribuído, demonstrãndo os sistemãs e ãs relãçoes de conectividãde. Fonte:
Elãborãdã pelo ãutor, ãdãptãdo de SOMMERVILLE, 2011.
#PraCegoVer: Ilustra um middleware em um sistema distribuído, demonstrando os

sistemas e as relações de conectividade. A imagem contém dois grandes quadrados,
de conteúdos iguais, que representam dois sistemas. Cada sistema é composto de:
Componentes de aplicação, que se comunica com Middleware, que se comunica com
Sistema operacional, que por fim, se comunica com Rede. Os componentes Rede
dos dois sistemas, se comunica de forma bilateral. A imagem ainda informa que nos
componentes de aplicação ocorre operação coordenada. No Middleware ocorre a
troca de informações e serviços comuns. No Sistema Operacional ocorre a interação
lógica e, na rede ocorre a conectividade física.
88
Conforme demonstrado por Sommerville (2011, p. 339), em um sistema distribuído,

o middleware costuma fornecer dois tipos distintos de suporte:
• Suporte ã interãçoes, em que o middlewãre coordenã ãs interãçoes entre diferentes

componentes do sistemã. O middlewãre fornece trãnspãrenciã dã locãlizãção, ãssim não e
necessãrio que os componentes sãibãm os locãis físicos dos outros componentes. Ele
tãmbem pode suportãr ã conversão de pãrãmetros se diferentes linguãgens de
progrãmãção forem usãdãs pãrã implementãr componentes, detecção de eventos e
comunicãção etc.
• A prestãção de serviços comuns, em que o middlewãre fornece implementãçoes reusãveis
de serviços que podem ser exigidãs por vãrios componentes do sistemã distribuído. Úsãndo
esses serviços comuns, os componentes podem, fãcilmente, interoperãr e prestãr serviços
de usuãrio de mãneirã consistente.
Os sistemas distribuídos, por um lado, quando acessados pela web, são organizados
no modelo cliente-servidor. Por outro lado, o computador remoto fornece os serviços
solicitados pelo programa local. Na arquitetura cliente-servidor, um sistema é
implantado como sendo um conjunto de serviços fornecidos pelo servidores.
Portanto, os clientes poderão acessar os serviços e apresentar para os usuários
finais.
Na figura a seguir, mostraremos um esquema de uma arquitetura cliente-servidor, na
qual existem quatro servidores (S1, S2, S3 e S4) e 12 clientes (C1 a C12).

Figurã 5 - Sistemã de ãrquiteturã cliente-servidor demonstrãndo ãs relãçoes entre os processos cliente e os
processos servidores. Fonte: Elãborãdã pelo ãutor, ãdãptãdo de SOMMERVILLE, 2011.
89
#PraCegoVer: Ilustra um sistema de arquitetura cliente-servidor demonstrando as

relações entre os processos cliente e os processos servidores. A imagem contém 4
quadrados que representam servidores e que se inter-relacionam. Existe também na
imagem, círculos que representam os clientes, que se inter-relacionam com os
servidores.
Na realidade, os sistemas cliente-servidor dependem de uma separação entre a

apresentação dos dados dos processos que criam essas informações. Portanto, essa
arquitetura deve ser projetada para que seja estruturada em várias camadas lógicas,
permitindo que cada camada seja distribuída para um computador diferente.
4.2.2 Padrões de arquitetura para sistemas distribuídos
Segundo Sommerville (2011), os sistemas distribuídos precisam ser organizados

para encontrar um equilíbrio entre as características de desempenho, confiança,
proteção e capacidade de gerenciamento. Os padrões estão descritos a seguir.
• Arquiteturã de mestre-escrãvo
Este padrão de arquitetura é geralmente utilizado para sistemas em tempo real com
processadores separados atrelados à obtenção de dados do ambiente do sistema.
O processo mestre é responsável por processar, coordenar e comunicar os
componentes. Ele é responsável, também, por controlar os processos escravo.
Portanto, os processos escravos são dedicados a ações específicas. Na figura a
seguir, ilustraremos a arquitetura mestre-escravo com um modelo de um sistema de
controle de tráfego, em que três processos lógicos são executados em
processadores separados. O processo mestre é o processo da sala de controle, que
se comunica com processos escravos separados e que são responsáveis pela coleta
de dados de tráfego e gerência de funcionamento de semáforos.
90

Figurã 6 - Sistemã de gerenciãmento de trãfego com umã ãrquiteturã mestre-escrãvo. Fonte: Elãborãdã pelo ãutor,
ãdãptãdo de SOMMERVILLE, 2011.
#PraCegoCer: Ilustra um sistema de gerenciamento de tráfego com uma arquitetura

mestre-escravo. A imagem possui três quadrados que representação. O quadrado ao
centro, representa a coordenação e processo de exibição, que é um elemento mestre
nesta arquitetura e que comunica com os outros dois quadrados e com os consoles
do operador. Do lado esquerdo, está o quadrado que representa o processo de
controle do sensor, que é um elemento escravo, e que se comunica com os sensores.
No lado direito está o quadrado que representa o processo de controle de luzes, que
também é escravo e que se comunica com os semáforos.
• Arquiteturã cliente-servidor de duãs cãmãdãs

A arquitetura cliente-servidor de duas camadas é considerada a forma mais simples
da arquitetura. Este padrão é implementado como um único servidor lógico e o
número de clientes que usa esse servidor é indefinido. Existem duas formas que
compõem esta arquitetura, conforme demonstrado por Sommerville (2011, p. 342):
• Modelo cliente-mãgro, em que ã cãmãdã de ãpresentãção e implementãdã no cliente e
todãs ãs outrãs cãmãdãs (gerenciãmento de dãdos, processãmento de ãplicãção e bãnco de
dãdos) são implementãdãs em um servidor. O softwãre de cliente pode ser um progrãmã
especiãlmente escrito no cliente pãrã trãtãr ã ãpresentãção. No entãnto, e frequente um
browser de Web no computãdor cliente ser usãdo pãrã ãpresentãção dos dãdos.
• Modelo cliente-gordo, em que pãrte ou todo o processãmento de ãplicãção e executãdo no
cliente e ãs funçoes de bãnco de dãdos e gerenciãmento são implementãdãs no servidor.
A vantagem do uso desta arquitetura é a simplicidade no gerenciamento dos clientes,

mas pode acarretar um problema se houver um grande número de clientes. A
desvantagem do modelo cliente-magro é colocar uma carga pesada de
processamento. Por outro lado, o modelo cliente-gordo poderá usar a capacidade de
processamento disponível no computador executando o software cliente, distribuindo
o processamento de aplicação e a apresentação para o cliente. Conforme explicado
por Sommerville (2011, p. 343),
um exemplo de umã situãção em que ã ãrquiteturã cliente-gordo e usãdã e um sistemã de bãnco ATM, que
oferece dinheiro e outros serviços bãncãrios pãrã os usuãrios. ATM e o computãdor cliente, e o servidor e,
normãlmente, um mãinfrãme executãndo o bãnco de dãdos de contã de cliente. Úm computãdor
mãinfrãme e umã mãquinã poderosã que e projetãdã pãrã o processãmento de trãnsãçoes. Assim, ele pode
lidãr com o grãnde volume de trãnsãçoes gerãdãs pelãs ATMs e outros sistemãs de cãixã e bãncos on-line.
O softwãre nã mãquinã de cãixã reãlizã vãrios processãmentos relãcionãdos ão cliente ãssociãdo com umã
trãnsãção.
Demonstraremos o exemplo de ATM, conforme descrito acima, na figura a seguir, na

qual temos a interação dos clientes com a camada de aplicações (que está no serviço
web), e a interação a camada do banco de dados, por meio dos comandos SQL.
91

Figurã 7 - Arquiteturã de tres cãmãdãs pãrã um sistemã de internet bãnking. Fonte: Elãborãdã pelo ãutor,
ãdãptãdo de SOMMERVILLE, 2011.
#PraCegoVer: Ilustra a arquitetura de três camadas para um sistema de internet

banking. A imagem contém um quadrado simbolizando um Servidor Web, que realiza
a prestação de serviços de conta, e, um retângulo que simboliza p Servidor de banco
de dados, que contém o banco de dados de conta de cliente. Ligados ao Servidor
Web, estão três círculos que representam os clientes, que realizam uma interação
HTTPS com o Servidor, que por sua vez, realiza consultas SQL no servidor de banco
de dados. O servidor web está na camada 2, onde é realizado o processamento de
aplicações e gerenciamento de dados. O servidor de banco de dados está na camada
3, onde é realizado o processamento de banco de dados.
Quando o modelo cliente-gordo executa a distribuição do processamentos de forma

mais eficaz, o gerenciamento se torna mais complexo, pois existe uma distribuição
do processamento em toda a estrutura.
• Arquiteturã cliente-servidor multicãmãdãs

Neste tipo de arquitetura, diferentes camadas são processadas separadamente,
podendo ser executadas em processadores distintos. O modelo cliente-servidor de
três camadas pode ser estendido para um modelo em multicamadas, em que os
servidores adicionais são adicionados ao sistema. Veja, na figura a seguir, um
exemplo genérico.
92

Figurã 8 - Arquiteturã cliente-servidor multicãmãdãs com suãs cãmãdãs interãgindo por meio dã rede e conexão
com o bãnco de dãdos. Fonte: Elãborãdã pelo ãutor, 2018.
#PraCegoVer: Ilustra a arquitetura cliente-servidor multicamadas com suas camadas

interagindo por meio da rede e conexão com o banco de dados. A imagem possui,
da esquerda para a direita, a representação de uma máquina cliente, que se
comunica por rede com o servidor de aplicação, que também se comunica por rede
com o servidor de banco de dados, que por fim, se comunica com o banco de dados.
A figura da máquina cliente é composta por um monitor de vídeo, um teclado, um
mouse e uma xícara de café. Os servidores são ilustrados com uma figura de um
gabinete de computador. O banco de dados é ilustrado com a figura de um cilindro.
Esse processo envolve o uso de um servidor web para gerenciamento de dados e de

servidores separados, para processar a aplicação e os serviços do banco de dados.
• Arquiteturãs de componentes distribuídos

No modelo de arquitetura de componentes distribuídos, a organização é realizada
em camadas, sendo cada uma implantada em um servidor lógico de forma separada.
Um exemplo genérico é demonstrado na figura a seguir.
93

Figurã 9 - Arquiteturã de componentes distribuídos com suãs cãmãdãs interãgindo por meio dos fluxos de
informãção. Fonte: Elãborãdã pelo ãutor, 2018.
#PraCegoVer: Ilustra a arquitetura de componentes distribuídos com suas camadas

interagindo por meio dos fluxos de informação. A imagem contém retângulos
representando as camadas de componentes. No topo está a camada N e logo abaixo
etá a camada n-1 [ene menos um], mais abaixo a camada 2, e na base da imagem
está a camada 1. Respeitando a pilha de camadas, as camadas se comunicam
bilateralmente, de cima para baixo ocorre o fluxo de requisição, de baixo para cima
ocorre o fluxo de resposta.
Uma abordagem generalista de projeto de sistemas distribuídos é projetar o sistema

como um conjunto de serviços, sem alocar esses serviços nas camadas do sistema.
Segundo Sommerville (2011, p. 346), os benefícios de se usar um modelo de
componentes distribuídos para implementação de sistemas distribuídos são os
seguintes:
• A permissão ão projetistã de sistemã de ãtrãsãr decisoes sobre onde e como os serviços
deverão ser prestãdos. Os componentes fornecedores de serviços podem executãr em
quãlquer no dã rede. Não e necessãrio decidir previãmente se um serviço e pãrte de umã
cãmãdã de gerenciãmento de dãdos, umã cãmãdã de ãplicãção etc.
• E umã ãrquiteturã de sistemãs muito ãbertã, ã quãl permite ã ãdição de novos recursos
conforme necessãrio. Novos serviços de sistemã podem ser ãdicionãdos fãcilmente sem
grãndes perturbãçoes ão sistemã existente.
• O sistemã e flexível e escãlãvel. Novos componentes ou componentes replicãdos podem ser
ãdicionãdos quãndo ã cãrgã sobre o sistemã ãumentã, sem interromper ãs outrãs pãrtes do
sistemã.
• E possível reconfigurãr o sistemã dinãmicãmente com componentes migrãndo ãtrãves dã
rede conforme necessãrio. Isso pode ser importãnte onde estão flutuãndo pãdroes de
94
demãndã de serviços. Úm componente fornecedor de serviços pode migrãr pãrã o mesmo

processãdor como objetos requisitor de serviços, ãumentãndo ãssim o desempenho do
sistemã.
Este modelo tem como objetivo estruturar e organizar o sistema, fornecendo

funcionalidades como forma de serviços.
• Arquiteturãs ponto ã ponto

Neste tipo de arquitetura, os sistemas são descentralizados, e os processamentos
podem ser realizados por qualquer nó na rede. Inicialmente, não existe separação
entre os clientes e os servidores.
4.3 Pãdroes de ãrquiteturã pãrã sistemãs embutidos
Inicialmente, um sistema embutido (também chamado de sistema embarcado) é

microprocessado, ou seja, o computador é completamente dedicado ao dispositivo
ou sistema que ele controla. Conforme explicado por Sommerville (2011, p. 375), “O
software embutido é muito importante economicamente porque quase todos os
dispositivos elétricos incluem software. Portanto, existem muitos sistemas de
software embutido, mais do que outros tipos de sistema de software”. Em retorno,
deve ser criada uma saída equivalente.
Alguns dados, às vezes, devem ser armazenados. Sommerville (2011, p. 375)
declara que existem diferenças importantes entre sistemas embutidos e outros tipos
de sistema, além da necessidade de respostas em tempo real.
• Gerãlmente, os sistemãs embutidos executãm continuãmente e não pãrãm. Eles começãm

quãndo o hãrdwãre e ligãdo e devem executãr ãte que o hãrdwãre sejã desligãdo. Isso
significã que tecnicãs de engenhãriã de softwãre confiãveis podem precisãr ser usãdãs pãrã
gãrãntir ã operãção contínuã.
• As interãçoes com o ãmbiente do sistemã são incontrolãveis e imprevisíveis. Em sistemãs
interãtivos, o ritmo dã interãção e controlãdo pelo sistemã e, ão limitãr ãs opçoes de
usuãrio, os eventos ã serem processãdos são conhecidos ãntecipãdãmente.
• Pode hãver limitãçoes físicãs que ãfetem o projeto de um sistemã. Exemplos desse tipo
incluem limitãçoes sobre ã energiã disponível pãrã o sistemã e o espãço físico ocupãdo pelo
hãrdwãre.
• A interãção diretã com o hãrdwãre pode ser necessãriã. Em sistemãs interãtivos e sistemãs
de informãçoes, existe umã cãmãdã de softwãre (os drivers de dispositivo) que esconde o
hãrdwãre do sistemã operãcionãl.
• Questoes de segurãnçã e confiãbilidãde podem dominãr o projeto de sistemã.
É importante ressaltar que os sistemas embutidos são considerados reativos, ou seja,
controlam dispositivo e, se há falhas, podem ter custos humanos ou econômicos não
desejados. Assim sendo, a confiança é um fator crítico, e o projeto de sistema precisa
garantir um comportamento crítico de segurança constantemente.
4.3.1 Projeto de sistemas embutidos

95
Grande parte do projeto de sistemas distribuídos pode envolver a decisão de quais

recursos serão implantados no software e no hardware. O consumo de energia acaba
sendo um fator crítico em sistemas embutidos. O que acontece é que eles são
sistemas que reagem a eventos, e a abordagem geral de projeto de software
embutido de tempo real é baseada em um modelo de estímulo-resposta. Segundo
Sommerville (2011, p. 377), os estímulos são divididos em duas classes:
• Periodicos. Estímulos que ocorrem em intervãlos previsíveis.

• Aperiodicos. Estímulos que ocorrem de formã irregulãr e imprevisível e gerãlmente são
sinãlizãdos pelo mecãnismo de interrupção do computãdor.
Portanto, para cada tipo de sensor haverá um processo que gerenciará a sua coleta
de dados. As etapas de processamento de dados devem calcular as respostas, e não
existe um processo que seja padrão de projeto de sistemas embutidos. O que ocorre
é que processos diferentes são usados dependendo do tipo do sistema, do tipo de
hardware e da organização que está desenvolvendo o sistema.
Segundo Sommerville (2011), as seguintes atividades podem ser incluídas em um
processo de projeto de software de tempo real:
• seleção de plãtãformã;
• identificãção de estímulos/respostã;
• ãnãlise do timing;
• projeto do processo;
• projeto do ãlgoritmo;
• projeto dos dãdos; • progrãmãção dos processos.
Em sistemas embutidos, os processos precisam ser coordenados e compartilhar

informações. Portanto, os mecanismos de coordenação devem garantir a exclusão
mútua de recursos compartilhados.
4.3.2 Modelos de arquitetura mais comuns em sistemas

embutidos
Existem diferenças entre os modelos de arquitetura dos sistemas padrões e sistemas

embutidos. Os padrões de sistemas embutidos são orientados a processos, ao invés
de orientados a objetos e componentes. Segundo Sommerville (2011, p. 382), os
principais modelos de arquitetura de sistemas embutidos são:
• Observãr e reãgir. Esse pãdrão e usãdo quãndo um conjunto de sensores e monitorãdo e
exibido rotineirãmente. Quãndo os sensores mostrãm que ocorreu ãlgum evento (por
exemplo, umã chãmãdã recebidã em um telefone celulãr), o sistemã reãge, iniciãndo um
processo pãrã trãtãr esse evento.
• Controle de ãmbiente. E usãdo quãndo um sistemã inclui sensores que fornecem
informãçoes sobre o ãmbiente e ãtuãdores cãpãzes de ãlterãr o ãmbiente. Em respostã ãs
mudãnçãs ãmbientãis detectãdãs pelo sensor, sinãis de controle são enviãdos pãrã os
ãtuãdores de sistemã.
96
• Pipeline de processo. Esse pãdrão e usãdo quãndo dãdos precisãm ser trãnsformãdos de
umã representãção pãrã outrã ãntes que possãm ser processãdos. A trãnsformãção e
implementãdã como umã sequenciã de etãpãs de processãmento, que podem ser reãlizãdãs
concorrentemente. Isso permite o processãmento de dãdos muito rãpido, porque um
nucleo sepãrãdo ou processãdor pode executãr cãdã trãnsformãção.
Esses padrões podem ser combinados e, muitas vezes, existe mais de um modelo
em um único sistema. Temos, como exemplo, o padrão ‘controle de ambiente’, em
que é usual para que os atuadores sejam monitorados usando o padrão ‘observar e
reagir’. No caso de uma falha de atuador, o sistema pode reagir exibindo uma
mensagem de aviso, desligando o atuador, comutando para um sistema de backup.
4.4 Arquiteturã orientãdã ã serviço (SOA)
Conforme apresentado por Somemrville (2011), a SOA é uma abordagem de

desenvolvimento de sistemas distribuídos na qual os componentes são serviços
executados em computadores distribuídos em vários lugares. Foram projetados
protocolos específicos baseados em Extensible Markup Language (XML), Simple Object
Access Protocol (SOAP) e Web Services Description Language (WSDL) para oferecer
suporte à comunicação e à troca de informações para a SOA. Na figura a seguir,
demonstraremos a ideia de uma SOA.

Figurã 10 - Arquiteturã orientãdã ã serviço indicãndo ã relãção entre ã solicitãção, o registro e o provedor. Fonte:
97
#PraCegoVer: Ilustra a arquitetura orientada a serviço indicando a relação entre a

solicitação, o registro e o provedor. A imagem apresenta três círculos, que se
interrelacionam e representam: registro de serviço, solicitação de serviços e,
provedor de serviços. Na imagem, a conexão entre registro e solicitação de serviços,
é nomeada de: Encontrar. A conexão entre registro e provedor de serviços, é
nomeada de: Publicar. A conexão entre provedor e solicitação de serviços, é
nomeada de: Ligar (SOAP). Parcialmente a cima do círculo do provedor de serviços,
há um círculo menor com a inscrição Serviços.
Os provedores de serviços são projetados para programarem serviços e especificam

a interface para eles. Os provedores publicam as informações sobre serviços em um
registro, e os solicitantes de serviço que procuram por um serviço encontram a
especificação desse serviço e localizam o provedor. A seguir, eles ligam sua
aplicação ao serviço e se comunicam com ele, usando protocolos de serviço.
4.4.1 Noções de web service e padrões de web service
A ideia de um serviço tipo web service surgiu como uma proposta de disponibilizar as
informações entre programas, definindo e publicando as informações por meio de
uma interface própria. A interface web service define os dados disponíveis e a maneira
como podem ser acessados, sendo, de modo geral, uma representação para algum
recurso ou de informações que pode ser acessado por outros softwares, podendo ser
recursos de informações, de computador ou de armazenamento.
Foram criados padrões fundamentais para oferecer suporte a web services, conforme
ilustraremos na figura a seguir.

Figurã 11 - Pãdrão de web service exibindo ãs cãmãdãs e os serviços que são disponíveis. Fonte: Elãborãdã pelo
ãutor, ãdãptãdo de SOMMERVILLE, 2011.
#PraCegoVer: Ilustra um padrão de web service exibindo as camadas e os serviços

que são disponíveis. A figura contém uma coluna com cinco linhas. De cima pra
98
baixo, as linhas contêm: Tecnologias XML (XML, XSD, XSLT, ...); Suporte
(WSSecurity, WS-Addressing, ...); Processo (WS-BPEL); Definição de serviço (UDDI,
WSDL), e; Serviço de mensagem (SOAP).
Os protocolos de web service abarcam todos os aspectos da arquitetura orientada a

serviço, iniciando pelos mecanismos básicos para troca de informações de serviço
(SOAP) chegando até os padrões de linguagem da programação (WS-BPEL). Todos
esses padrões são baseados na notação XML, a qual é legível por máquina e
pessoas, permitindo a definição de dados estruturados, em que o texto é marcado
com um identificador. O XML tem uma variedade de tecnologias (como a XSD, para
definição de esquemas), que estendem e manipulam as descrições de XML.
Segundo Sommerville (2011, p. 357), os principais padrões da arquitetura orientada
a serviço de web service são:
• SOAP. Esse e um pãdrão de trocãs de mensãgens que oferece suporte ã comunicãção entre
os serviços. Ele define os componentes essenciãis e opcionãis dãs mensãgens pãssãdãs
entre serviços.
• WSDL. A linguãgem de definição de web service (Web Service Definition Language) e um
pãdrão pãrã ã definição de interfãce de serviço. Define como ãs operãçoes de serviço
(nomes de operãção, pãrãmetros e seus tipos) e ãssociãçoes de serviço devem ser definidãs.
• WS-BPEL. Esse e um pãdrão pãrã umã linguãgem de workflow, que e usãdã pãrã definir
progrãmãs de processo que envolvem vãrios serviços diferentes.
Os sistemas que envolvem trocas de informações pelas fronteiras das empresas

podem ser automatizados de maneira mais fácil. Portanto, as aplicações baseadas
em serviço são construídas por meio da interação de serviços de diversos
fornecedores, utilizando uma linguagem de programação padrão ou de workflow que
seja especializada.
4.4.2 Arquitetura orientada a serviço
A arquitetura orientada a serviço é mais flexível, e as ligações de serviços podem se

alterar durante a execução. Isso quer dizer que uma versão diferente, porém
equivalente, pode ser executada em momentos distintos. Alguns sistemas podem ser
construídos com o uso exclusivo de web service, enquanto outros poderão misturar
web service com componentes desenvolvidos localmente.
Para ilustrar uma arquitetura orientada a serviço, será mostrada a construção do
seguinte cenário, conforme proposto por Sommerville (2011, p. 357):
Úm sistemã de informãçoes em um cãrro fornece ãos motoristãs informãçoes sobre climã, condiçoes de
trãfego dã estrãdã, informãçoes locãis, e ãssim por diãnte. Ele e ligãdo ão rãdio do cãrro pãrã que ã
informãção sejã entregue como um sinãl em um cãnãl de rãdio específico. O cãrro e equipãdo com
receptores GPS pãrã descobrir suã posição, e, com bãse nessã posição, o sistemã ãcessã umã gãmã de
serviços de informãção. Em seguidã, ãs informãçoes podem ser entregues nã linguãgem especificãdã pelo
motoristã.
99
Inicialmente, o carro se comunica como serviço móvel eterno que agrega as

informações de outros serviços. Outros provedores também oferecem esse serviço,
sendo que o sistema de bordo utiliza um serviço para descobrir e localizar o serviço
de informação adequado e ligar a eles. Os serviços trocam mensagens SOAP, que
englobam informações sobre a posição do GPS usada pelos serviços para selecionar
as informações necessárias. A informação agregada é encaminhada para o carro por
um serviço, que converte esses dados na linguagem definida pelo motorista. A
arquitetura deste exemplo está exposta na figura a seguir.

Figurã 12 - Sistemã de informãçoes de bordo bãseãdo em serviços, mostrãndo ãs relãçoes entre os componentes.
Fonte: Elãborãdã pelo ãutor, ãdãptãdo de SOMMERVILLE, 2011.
#PraCegoVer: Ilustra um sistema de informações de bordo baseado em serviços,

mostrando as relações entre os componentes. Na base da imagem há um grande
retângulo, contendo os componentes: Receptor, que se comunica com Radio,
Localizador com Transmissor e, Interface de usuário que também se comunica com
Transmissor. Acima, fora deste retângulo, estão os componentes: Serviço de
100
informação móvel, que é comunicado pelo Transmissor e que comunica para

Tradutor, Informações Meteorológicas, Informações sobre instalações e Localizador
de Entrada, que por sua vez, comunica Informação de Tráfego. Transmissor também
comunica Descoberta de Serviços.
O exemplo acima mostra uma vantagem da abordagem orientada a serviços.

Conforme explicado por Sommerville (2011), não é necessário decidir quando o
sistema é programado ou implantado, ou qual o provedor de serviço será usado,
como também quais serviços específicos devem ser acessados. Conforme o carro
se move, o sistema de bordo utiliza o serviço de reconhecimento de serviços para
buscar o serviço de informações que mais se adequa, efetuando a vinculação.
Síntese
Concluímos este capítulo mostrando a importância de conhecer e aplicar as arquiteturas
alternativas aplicadas ao ambiente web e aplicativos móveis. Conhecemos os diversos padrões de
arquitetura com os sistemas distribuídos e sistemas embutidos e orientados a serviços e web
service. Tivemos a oportunidade de verificar como as novas tecnologias impactam e levam ao
desenvolvimento de novos padrões e modelos de arquitetura.
• analisar formas alternativas da arquitetura de software;

• identificar os padrões webapp;
• analisar as alternativas entre desenvolver, comprar ou alugar uma solução;
• avaliar e identificar os aspectos a serem considerados ao desenvolver um sistema
distribuído;
• analisar a utilização de sistemas embutidos;
• conhecer e analisar a arquitetura orientada a serviço.
Projeto
PADRÕES DE ARQUITETURA PARA SISTEMAS EMBUTIDOS
Um sistema embarcado pode ser definido como "um sistema

computadorizado dedicado a executar um conjunto específico de
funções do mundo real, ao invés de fornecer um ambiente de
computação generalizado". Claramente, essa é uma ampla
categorização que inclui pequenos computadores de 8 bits,
101
incorporados em marcapassos cardíacos, e computadores de 64 bits

que controlam aeronaves, comunicações, controle de incêndio para
aeronaves e WANs, compostos por centenas de poderosos sistemas
para gerenciamento de C4ISR (Comando, Controle, Comunicações,
Computadores, Inteligência, Vigilância e Reconhecimento). Muitos
sistemas embarcados não possuem discos, interface humana e quase
nenhuma memória, mas o escopo do mercado de sistemas
embarcados é muito mais amplo do que esses dispositivos simples.
Os sistemas embarcados já controlam, aumentam, monitoram e
gerenciam praticamente todos os dispositivos de alta tecnologia que
existem, de televisores, trens a automação de fábrica, e seu uso está
aumentando.
Um subconjunto importante de sistemas embarcados são os sistemas

em tempo real. Muitas pessoas têm a impressão equivocada de que
"tempo real" significa "bem rápido", mas isso não é verdade. Um
sistema em tempo real é aquele em que as restrições de
pontualidade devem ser atendidas para a correção do sistema. Uma
categorização comum, embora simplista, de sistemas em tempo real
é dividida em dois grupos (rígido e moderado). Sistemas em tempo
real são aqueles em que as restrições de pontualidade são
modeladas com pontos no tempo em que é necessário concluir a
execução de ações específicas. Isso pode incluir taxa de transferência
média, tempo médio de execução, duração máxima de burst ou
alguma outra medida. Todos os sistemas podem ser modelados
como sistemas rígidos em tempo real, mas isso geralmente resulta
em um "over-design" do sistema para ser mais rápido ou ter mais
recursos disponíveis do que o necessário, aumentando o custo
recorrente (aproximadamente "custo de fabricação") do sistema.
Embora todos os sistemas possam ser modelados como sistemas
rígidos em tempo real, na verdade, a maioria não é. Se a resposta for
ocasionalmente atrasada ou mesmo se um evento de entrada inteiro
for perdido, a maioria dos sistemas continuará funcionando
102
corretamente. O principal motivo para modelar sistemas em tempo

real é porque facilita a garantia da pontualidade do sistema por meio
de análises matemáticas.
Por dentro, uma das características mais marcantes dos sistemas

embarcados é a severidade de suas restrições. Ao contrário do
software para um computador de uso geral, um sistema
embarcado geralmente é enviado já integrado com todo o
hardware necessário. A plataforma de hardware geralmente não é
extensível ao usuário; portanto, recursos como memória, energia,
refrigeração ou poder de computação contribuem para o custo por
unidade (conhecido como custo recorrente). Para manter a
lucratividade, quase sempre há uma enorme pressão sobre o
desenvolvedor para minimizar o uso desses recursos de hardware.
Isso significa que os sistemas embarcados geralmente exigem
esforços adicionais de otimização muito além do exigido para
aplicativos de desktop.
Além da necessidade de minimizar o hardware, as preocupações com

o desempenho geralmente são críticas para o sucesso de um sistema.
Há muitos aspectos no desempenho, e sistemas diferentes valorizam
esses aspectos de maneira diferente. Em alguns sistemas, a taxa de
transferência é um critério crítico. A taxa de transferência é
normalmente medida em termos do número de transações,
amostras, conexões ou mensagens que podem ser processadas por
unidade de tempo. Em outros sistemas, lidar com cada solicitação o
mais rápido possível é mais importante, uma qualidade conhecida
como capacidade de resposta, geralmente capturada como o pior
tempo de execução. Outros sistemas valorizam a previsibilidade do
desempenho em relação à taxa de transferência máxima ou
capacidade de resposta. A previsibilidade é geralmente medida como
ocorrendo dentro de um intervalo ou como extraída de uma função
de densidade de probabilidade.
103
Confiabilidade, robustez e segurança são outros tipos de restrições

impostas aos sistemas embarcados. A confiabilidade de um sistema é
uma medida (estocástica) da probabilidade de o sistema fornecer a
funcionalidade correta. Robustez refere-se à capacidade de um
sistema de fornecer serviços adequadamente quando suas condições
prévias (como condições operacionais ou taxas de entrada de dados)
são violadas. Segurança denota o nível de risco de um sistema, ou
seja, a probabilidade de que o uso do sistema resulte em acidente ou
perda. Essas preocupações geralmente exigem medidas adicionais de
hardware e software para manter a operação do sistema dentro de
limites aceitáveis. Por exemplo, a maioria os sistemas incorporados
têm um POST (Power on Self-Test), bem como um teste interno
periódico ou contínuo (BIT).
Coletivamente, essas restrições no sistema são conhecidas como

qualidades de serviços (QoS) fornecidas pelo sistema. Além das várias
restrições de QoS, para reduzir custos recorrentes, é comum criar
hardware personalizado que requer software de driver de dispositivo
especializado.
Vamos Praticar
Como a arquitetura para sistemas embarcados deve ser considerada para melhorar o
desempenho e confiabilidade do software a ser executado nestes dispositivos? Ao final,
disponibilize seu trabalho no fórum da seção.
Referências
HOFMEISTER, C.; NORD, R.; SONI, D. Applied software architecture.



Arquitetura de Software

Enviado por

Dados do documento

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

1

Antes de responder a essas questões, é importante relembrarmos que a arquitetura de

Iniciaremos esta disciplina analisando os princípios de arquitetura de software com a

Desejamos um excelente estudo.

1.1 Introdução ã ãrquiteturã de software

1.1.1 Conceitos introdutórios de arquitetura de softwãre

• flexível: deve permitir as mudanças que se façam necessárias em

O projeto de arquitetura é o primeiro passo no processo de implantação de um

Deslize sobre a imagem para Zoom

#PraCegoVer: Contém uma tabela com os atributos essenciais de qualidade de um

Estas características terão maior ou menor relevância dependendo do propósito do

clientes de uma loja) terão atributos de qualidade diferentes de sistemas mais

• Aplicações stand-alone. Essas são as aplicações executadas em um

Tendo como base as tipificações definidas anteriormente, é necessário definir como

• em cascata. Este modelo determina as atividades principais do processo de

A partir das tipificações de sistemas e dos modelos de processo de desenvolvimento,

• A arquitetura em pequena escala está preocupada com a arquitetura de

Desenhar a arquitetura de software é fundamental, portanto, para o desenvolvimento

As arquiteturas de software geralmente são modeladas usando diagramas de blocos

Deslize sobre a imagem para Zoom

Figurã 1 - Arquiteturã de um sistemã de controle robotizãdo de empãcotãmento, indicãndo os componentes, os

#PraCegoVer: Ilustra a arquitetura de um sistema de controle robotizado de

Os diagramas de blocos representam a arquitetura de um software e apresentam

1.1.2 Descriçoes de ãrquiteturã

cada modelo representa uma perspectiva do sistema. Portanto, são necessários

• lógica, que mostra as abstrações fundamentais do sistema como objetos ou

• Caso de Uso. Este diagrama define o grupo de comportamentos no alto nível

• Classes. Este diagrama representa a coleção de classes e define seus

1.2 Generos e estilos de ãrquiteturã

Podemos conceituar o projeto de arquitetura, segundo Sommerville (2011, p. 105),

• Desempenho. Se o desempenho for um requisito crítico, a arquitetura deve

Para Pressman (2016), apesar de os princípios do projeto de arquitetura de software

• Inteligência artificial – sistemas que simulam a cognição.

• Autoria de conteúdo – sistemas para controlar artefatos.

Por outro lado, a questão de estilos na arquitetura de software descreve uma

• arquitetura centralizada em dados: um repositório de dados reside no

Deslize sobre a imagem para Zoom

#PraCegoVer: Ilustra a arquitetura centralizada em dados demonstrando o depósito

• arquitetura de fluxo de dados: dados de entrada devem ser transformados

Deslize sobre a imagem para Zoom

#PraCegoVer: Contém a ilustração da Arquitetura de fluxo de dados demonstrando

• arquitetura de chamadas e retornos: permite obter dados em programa

Deslize sobre a imagem para Zoom

#PraCegoVer: Ilustra a arquitetura de chamadas e retornos, demonstrando o

• arquitetura orientada a objetos: caracterizada pelos componentes terem os

Deslize sobre a imagem para Zoom

#PraCegoVer: Ilustra a arquitetura em camadas demonstrando as diversas camadas

Diante das características expostas das arquiteturas de software, é possível

• MVC (Modelo-Visão-Controlador): considerado a base do gerenciamento de

Deslize sobre a imagem para Zoom

#PraCegoVer: Ilustra o modelo da organização MVC com a demonstração do fluxo

• Abordagem em camadas: sustenta o desenvolvimento de um sistema de

• De repositório: tem como característica que todos os dados do sistema são

• Um conjunto de servidores que oferecem serviços a outros componentes.

Esse modelo geralmente é utilizado quando os dados compartilhados precisam ser

Deslize sobre a imagem para Zoom

#PraCegoVer: Ilustra o Modelo cliente-servidor, demonstrando a relação entre

A vantagem desse modelo é a característica de distribuição por meio de uma rede,

O desenvolvimento de software baseado em agentes tem como objetivo a sua aplicação

• Dutos e filtros: é um padrão de arquitetura no qual o processamento dos

compreensão e facilidade de suporte. Por outro lado, o formato para a

Os arquitetos de software criam uma metodologia própria para coletar e analisar os

Uma indústria de autopeças decidiu desenvolver internamente um sistema integrado de

As decisões de projeto de arquitetura incluem tanto aquelas do tipo de aplicação,