Arquitetura de Software: Padrões, Qualidade e Desenvolvimento

UNIVERSIDADE ESTADUAL DO NORTE DO PARANÁ
CENTRO DE CIÊNCIAS TECNOLÓGICAS

ENGENHARIA DE SOFTWARE II
ANDRÉ MENOLLI
ARQUITETURA DE SOFTWARE
Bandeirantes
2017
Engenharia de Software II Arquitetura de Software
Arquitetura de Software
Sumário
Introdução ........................................... 3
Arquitetura de Software .............................. 5
Visões da Arquitetura de Software ....................................................... 7
Atributos de Qualidade .............................. 11
Táticas para Atingir os Atributos de Qualidade .................................. 12
Principais Tipos de Atributos de Qualidade........................................ 15
Padrões Arquiteturais ............................... 19
Camadas (Layers) ........................................................................... 23
Pipes e Filters (Dutos e Filtros) ........................................................ 25
Invocação Implícita ......................................................................... 28
Padrão MVC ................................................................................... 29
Cliente Servidor .............................................................................. 31
Arquitetura Peer to Peer .................................................................. 33
Arquitetura Orientada a Serviço (Service-Oriented Architecture –SOA) 34
Multicamadas (Multi-tier) ................................................................ 36
Padrões e Táticas de Atributos de Qualidade ......... 38
Decisões Arquiteturais Baseada em Atributos de Qualidade ................ 40
Arquiteturas e o Desenvolvimento de Software ........ 43
Sistemas Web .................................................................................. 44
Sistemas Mobile .............................................................................. 46
Sistemas IoT.................................................................................... 49
Exercícios .......................................... 53
Leitura Complementar ................................ 57
Referências ......................................... 58
André Menolli - Centro de Ciências Tecnológicas – Universidade Estadual do Norte do Paraná UENP 2
Introdução
A complexidade dos softwares vem aumentando ao longo dos

anos, e este aumento está relacionado a diversos fatores,
como o aumento do número de tecnologias envolvidas no
desenvolvimento do software. Novos softwares necessitam, por
exemplo, muitas vezes funcionar em diferentes plataformas
(smartphones, tablets, computadores, sistemas embarcados) e
em diferentes sistemas operacionais. Estes fatores
interferem, portanto, nos requisitos do software e
consequentemente nas decisões do projeto do software.
Com projetos cada vez mais complexos, é necessário
utilizar meios de facilitar esta etapa. Uma maneira de se
conseguir isso é definindo uma boa arquitetura do software.
Arquitetura é um conceito antigo, que vem do grego e
significa a arte de projetar e construir. O projeto
arquitetural precede a etapa de construção e determina os
elementos da construção e como estes devem interagir. A
arquitetura de software segue os mesmos conceitos, e visa
auxiliar a definir a solução mais adequada para determinado
tipo de problema.
A arquitetura consiste em um modelo de alto nível que
auxilia no entendimento e análise do software a ser
desenvolvido e ganhou destaque para representar soluções de
software principalmente por (GARLAN e PERRY, 1995):
• A abstração facilita a visualização e o entendimento

de certas propriedades do software.
• A exploração cada vez maior de frameworks visando
diminuir o esforço de construção de produtos por meio
da integração de partes previamente desenvolvidas.
A arquitetura de software é uma etapa fundamental nos

processos de software. Como exemplo, o Processo Unificado
(UP) possui uma fase específica (elaboração) para definir,
validar e criar a baseline da arquitetura.
Entender as necessidades do projeto, ou seja, seus
requisitos são fundamentais para definir a arquitetura.
Dentre as necessidades do projeto, um ponto essencial a ser
observado são os atributos de qualidade, pois se estes forem
incorporados ao núcleo da arquitetura, auxiliará a criar uma
arquitetura adequada as necessidades do projeto. Além disso,
a arquitetura do software é definida principalmente por meio
de padrões arquiteturais e táticas arquiteturais.
Embora tanto táticas quanto padrões sejam usados

durante o projeto da arquitetura, há uma clara distinção
entre eles. Como mostra a Figura 1, os padrões arquiteturais
descrevem a estrutura de alto nível e o comportamento dos
sistemas de software como soluções para os requisitos
múltiplos do sistema. Por outro lado, as táticas são
decisões de projeto que melhoram os interesses dos atributos
de qualidade individuais. É importante compreender as
diferenças entre padrões arquiteturais e táticas, as
relações entre eles e como eles interagem.
As táticas que são selecionadas durante o projeto da
arquitetura inicial, impactam significativamente a
arquitetura do sistema a ser projetado, influenciando
decisões como: quais padrões usar e como eles devem ser
alterados para acomodar as táticas selecionadas.
Figura 1: Padrões e Táticas Arquiteturais
Por fim, este capítulo trata do projeto da arquitetura

de software e apresenta conceitos fundamentais sobre
arquitetura de software e atributos de qualidade. Além
disso, apresenta alguns dos principais padrões arquiteturais
definidos na literatura e como as táticas arquiteturais se
relacionam com os padrões. Por fim, é feita uma breve
descrição de como os padrões podem ser utilizados no
desenvolvimento de software.
Arquitetura de Software
O conceito de arquitetura de software surgiu nos anos 60,

mas se tornou popular nos anos 90. A arquitetura de software
ganha importância de acordo com os softwares sem tornam mais
complexos, pois é necessário tomar decisões de quais
elementos existirão e como eles serão organizados, de forma
que o software seja escalável.
A arquitetura de software pode ser definida como um
sistema em termos de componentes computacionais e, os
relacionamentos entre estes componentes, os padrões que
guiam a sua composição e restrições (SHAW e GARLAN, 1996).
A arquitetura de software envolve decisões de ato nível,
que guiará a estruturação e organização do software. Dentre
as escolhas envolvidas na arquitetura de software, estão
decisões sobre as estruturas que formarão o sistema;
controle; protocolos de comunicação; sincronização e acesso
a dados; atribuição de funcionalidade a elementos do
sistema; distribuição física dos elementos, escalabilidade;
desempenho e outros atributos de qualidade; e seleção de
alternativas de projeto. Portanto, a arquitetura é a
organização fundamental de um sistema incorporada em seus
componentes, seus relacionamentos com o ambiente, e os
princípios que conduzem seu projeto e evolução. Pode-se
afirmar que a arquitetura é uma abstração do sistema.
A escolha da arquitetura é feita com base, entre outros
fatores, nos requisitos do sistema. Para se decidir sobre a
arquitetura é importante ter um bom conhecimento sobre os
requisitos do sistema, principalmente os atributos de
qualidade. Contudo, deve-se considerar o projeto
arquitetônico como algo mais abrangente, envolvendo aspectos
técnicos, sociais e de negócio. É necessário conhecer todos
estes aspectos para se entender a adequação da arquitetura
ao projeto, de forma entender os impactos, riscos e
dificuldades de sua implantação, além de como esta
arquitetura poderá evoluir.
Assim como em qualquer área, a experiência e formação do
arquiteto de software são muito importantes, uma vez que
existem inúmeros modelos de arquitetura que podem servir de
guia nos projetos. No entanto, a escolha do modelo, ou mesmo
a combinação de diferentes modelos não é uma tarefa trivial.
Quanto maior a experiência do projetista, maior a chance de
sucesso. Por exemplo, se em projetos anteriores, similares a
um projeto novo, os projetistas obtiveram bons resultados
usando uma arquitetura, então é natural que eles tentem
utilizar a mesma arquitetura em um novo projeto. No entanto,
se esta arquitetura foi uma escolha ruim os projetistas vão
relutar em tentar utilizá-la novamente, mesmo que se

apresente como uma solução adequada.
A arquitetura de software envolve diferentes papéis no
desenvolvimento do sistema, tais como clientes, usuários
finais, desenvolvedores, gerentes de projetos entre outros.
A arquitetura tem diferente interesse para cada um dos
papéis, por isso é necessário, em muitos casos a mediação
dos conflitos de interesses. Por exemplo, em um determinado
caso existem duas arquiteturas que a princípio podem
satisfazer a necessidade do projeto, uma mais simples e uma
mais complexa. Os projetistas, depois de rever os requisitos
e aspectos técnicos e legais, decidem pela arquitetura mais
complexa. Esta decisão vai contra os interesses dos
desenvolvedores, que optariam pela arquitetura mais simples,
uma vez que a princípio satisfaz as necessidades do projeto.
Dessa forma, a escolha da arquitetura deve ser feita com
cautela, atendendo de forma mais adequada a todos os
interesses, uma vez que guiará todo o projeto de software,
assim como sua evolução e manutenção.
A arquitetura de software é muito importante no projeto
do sistema, principalmente por:
• Abstração serve como base para criar um entendimento

mútuo, para comunicação entre os participantes. A
arquitetura provê uma linguagem comum nas quais
diferentes preocupações podem ser expressas,
negociadas e resolvidas em um nível que seja
intelectualmente gerenciável.
• Sua representação serve como guia para o projeto de
sua implementação, teste e implantação do sistema. As
primeiras decisões do projeto são definidas, assim
como restrições e a estrutura geral. A implementação
deve ser dividida nos elementos prescritos pela
arquitetura e os elementos devem interagir conforme
exposto pela estrutura. Por fim, os elementos devem
desempenhar as responsabilidades definidas pela
arquitetura. Além disso, a extensão na qual o sistema
vai ser capaz de satisfazer os atributos de qualidade
requeridos é substancialmente determinada pela
arquitetura. Particularmente a manutenibilidade é
fortemente afetada pela arquitetura.
• A arquitetura constitui modelos compreensíveis de
como o sistema é estruturado e como seus elementos
trabalham em conjunto, permitindo diferentes visões
sobre o projeto.
Portanto, o uso da arquitetura de software, se bem

aplicada deve facilitar o reúso em diferentes níveis. A
arquitetura deve permitir que o sistema suporte alterações
de forma localizada, sem afetar outras partes e que novas
funcionalidades sejam adicionadas sem causar impacto nas já
existentes. Assim, a vida útil do sistema depende de uma boa
arquitetura que facilite modificações e permita sua
evolução.
Outro aspecto importante é que o projetista de
arquitetura conheça as principais arquiteturas de software
existem, de modo a reconhecer estruturas comuns utilizadas
em sistemas já desenvolvidos. Isto permite desenvolver novos
sistemas como variações dos sistemas existentes. O
conhecimento e entendimento de arquiteturas de software
existentes permite que os projetistas avaliem alternativas
de projeto.
Visões da Arquitetura de Software

Quando se projeta a arquitetura de um software, é necessário
defini-la e documentá-la. Esta arquitetura não tem uma visão
única, mas um conjunto de diferentes visões, que separam
diferentes aspectos e propósitos com o objetivo de gerenciar
a complexidade. Cada visão descreve diferentes conceitos da
engenharia e permitem reduzir a quantidade de informações
que o arquiteto trata em um dado momento.
De acordo com Hofmeister, Nordi e Soni, (2000) existem
quatro visões na arquitetura do software:
• Conceitual: descreve o sistema em termos dos

elementos de projeto e relacionamentos entre eles
• Módulo: consiste na decomposição do sistema em
módulos.
• Execução: consiste no mapeamento dos componentes a
entidades de execução e de hardware. Este mapeamento
deve ser definido na fase de projeto arquitetural e
não apenas na fase de desenvolvimento.
• Código: consiste na organização do código fonte em
bibliotecas, binários, arquivos, versões e
diretórios.
A Figura 2 mostra como estas visões interagem entre elas

e entre o código e o hardware de um sistema.
Figura 2: Visões Arquiteturais
A visão conceitual é a mais próxima ao domínio da

aplicação e mapeia os elementos arquiteturais em
componentes, conectores e configuração. Os componentes e
conectores são mapeados em subsistemas e módulos. Não existe
um diagrama UML específico que possa ser utilizado para
descrever a visão estática, o importante é conseguir
abstrair os principais componentes e como eles se conectam.
Contudo, pode ser importante fazer uma abstração dinâmica
desta visão, descrevendo, por exemplo, quais eventos levam
um componente a se comunicar com outro. Para essa
representação uma alternativa é utilizar o diagrama de
máquina de estados da UML.
Um exemplo de visão conceitual é apresentado na Figura
3, que apresenta uma arquitetura de um sistema para
dispositivos móveis que converte arquivo do formato .pdf
para um documento editável. A arquitetura conceitual divide
o sistema em duas partes (cliente e servidor). No cliente o
usuário insere o arquivo a ser convertido, que é então
envidado ao servidor. O servidor é implementado por diversos
componentes que estão distribuídos em três camadas. O
primeiro componente é responsável por receber o arquivo e o
envia para o componente responsável por verificar a validade
do arquivo submetido. Após isso, um componente pega
individualmente cada palavra do texto (tokenizador) que

então envia as palavras para um componente que as reconhece.
Por fim, o componente Gerador de Documento gera o arquivo
editável, que é enviado de volta ao cliente.
Figura 3: Exemplo de Visão Conceitual
Na visão de módulo os componentes e conectores são

mapeados em módulos e subsistemas. Nesta visão podem
existir representações de camadas, módulos ou subsistemas.
Pode-se empregar o diagrama de pacotes da UML para
representar subsistemas e o digrama de componentes para
representar os módulos. Um componente é um pedaço de
software independente e reutilizável, que apenas se conhece
o serviço que provê, mas não se conhece seu funcionamento
interno, tal como uma caixa preta.
Um exemplo da visão de um subsistema é apresentado na
Figura 4, que mostra que o subsistema de pedidos interage
com o subsistema de pagamento.
Figura 4: Visão de Módulo por meio de Substistema
Os subsistemas podem ser especificados em componentes

que os compõem, como por exemplo, é apresentado na Figura 5,
que presenta que o subsistema de pagamento prove um serviço
de pagamento, mas que precisa de três componentes internos

para realizar este serviço.
Figura 5: Visão de Módulo por meio de Componentes
A visão de execução descreve a estrutura do sistema em

termos de elementos da plataforma de execução (p.ex. tarefas
do Sistema Operacional, processos, threads). Esta visão
descreve a topologia de execução do sistema caracterizando
as instâncias das entidades de execução e como elas são
interconectadas. Nesta visão pode ser utilizado o diagrama
de implantação da UML. O diagrama de implantação traz uma
visão estática da modelagem dos aspectos físicos de um
sistema. Este diagrama mostra a configuração de nós de
processamento em tempo de execução e os artefatos que nele
existem. Um exemplo de uma visão de execução mostrada por
meio de um diagrama de implantação é apresentado na Figura
6.
Figura 6: Visão de Execução
A visão de código descreve como o software que

implementa o sistema é organizado. O objetivo principal
desta visão é facilitar a construção, integração, instalação
e teste do sistema respeitando a integridade das outras três
visões arquiteturais. Nesta são descritos como um módulo,
suas interfaces e suas dependências são mapeadas a
componentes e dependências específicas da linguagem.
Esta visão pode utilizar diversos diagramas estáticos da
UML, como diagrama de classes, componentes ou pacotes. Além
disso, podem ser utilizados diagramas dinâmicos da UML, como
o de sequência ou comunicação para mostrar como objetos do
módulo interagem para realizar o comportamento desejado.
Atributos de Qualidade
Quando se inicia o projeto de um software espera-se que este

consiga atender as qualidades requeridas. Para isso, a
arquitetura proposta tem que ser condizente com estas
necessidades. Portanto, é necessário expressar os atributos
de qualidade e entender como se alcançar estas qualidades.
Um atributo de qualidade é uma propriedade mensurável ou
testável de um sistema que é usado para indicar quão bem o
sistema satisfaz as necessidades dos seus stakeholders
(BASS, CLEMENTS e KAZMAN, 2013).
Os requisitos para um sistema podem ser descritos por
meio de diferentes técnicas, tais como casos de uso, user
stories, documentação, sistemas já existentes entre outras.
Não importa a origem, todos os requisitos abrangem as
seguintes categorias (BASS, CLEMENTS e KAZMAN, 2013):
1. Requisitos funcionais: indicam o que o sistema deve

fazer e como ele deve se comportar ou reagir a
estímulos em tempo de execução.
2. Requisitos de atributo de qualidade (Requisitos não
funcionais): são qualificações de algum requisito
funcional específico ou do produto global. Uma
qualificação de um requisito funcional é um item como
a rapidez com que a função deve ser executada, por
exemplo. Uma qualificação do produto global pode ser,
por exemplo, o tempo para implementar o produto ou
uma limitação nos custos operacionais.
3. Restrições: são decisões de projeto sem liberdade de
escolha. Ou seja, é uma decisão de projeto que já foi
tomada. Como exemplo, pode-se citar o uso de uma
determinada linguagem de programação ou reutilizar um
determinado módulo já existente. Em geral estas
escolhas são do arquiteto de software, no entanto

fatores externos (tal como não ter tempo de treinar a
equipe em uma nova linguagem) podem levar a
restrições que o arquiteto tem que aceitar.
Os atributos de qualidade são fundamentais na definição

da arquitetura do software, uma vez que os requisitos
funcionais não são suficientes para determinar a
arquitetura. A partir dos requisitos funcionais, consegue-
se, no máximo, dividir estas funcionalidades em subconjuntos
de funcionalidades relacionadas para atribuí-los a
diferentes elementos arquitetônicos.
Por outro lado, os atributos de qualidade são
satisfeitos pelas várias estruturas projetadas na
arquitetura, e os comportamentos e interações dos elementos
que povoam essas estruturas. Já as restrições são
satisfeitas ao aceitar a decisão de projeto e combiná-la com
outras decisões de projeto afetadas.
Portanto, funcionalidade é a capacidade do sistema para
realizar as tarefas para o qual foi planejado. No entanto é
necessário que estas funções sejam relacionadas aos
atributos de qualidade. Por exemplo, deseja-se criar um
software de ponto de vendas (PVD) para uma loja. Não se
consegue definir a arquitetura do software sem saber se o
sistema será executado em apenas um ponto ou vários, e se
estes pontos estarão fisicamente distribuídos o não.
Táticas para Atingir os Atributos de Qualidade

Os atributos de qualidades há muito tempo veem sendo
estudados na área de engenharia de software, e existem
diversas classificações na literatura, advindos de várias
comunidades diferentes. Um problema destas classificações, é
que em muitos casos, cada comunidade desenvolveu seu próprio
vocabulário, podendo então existir diferentes termos de
atributos que são equivalentes.
Independente da taxionomia utilizada para classificar os
atributos de qualidades, há duas categorias fundamentais
para se definir a arquitetura. A primeira é aquela que
descrevem alguma propriedade do sistema em tempo de
execução, como disponibilidade, desempenho ou usabilidade. A
segunda é aquela que descrevem alguma propriedade do
desenvolvimento do sistema, como modificabilidade ou
testabilidade.
A arquitetura deve ser definida com base nestes
critérios, pois, juntamente com os requisitos funcionais,
eles descrevem os objetivos do negócio. Contudo, o arquiteto
deve usar algumas técnicas para alcançar os atributos de
qualidade necessários. Essas técnicas são chamadas de

táticas arquiteturais, que são decisões de projeto que
influenciam a obtenção de uma resposta do atributo de
qualidade. As táticas afetam diretamente a resposta do
sistema a alguns estímulos. As táticas conferem
portabilidade a um projeto, alto desempenho para outros e
facilidade de integração.
O projeto de um sistema consiste em uma coleção de
decisões. Algumas dessas decisões ajudam a controlar as
respostas de atributo de qualidade, outras garantem a
realização de uma funcionalidade do sistema. Dessa forma uma
arquitetura pode ser o resultado da aplicação de uma coleção
de decisões de projeto. Dentre as decisões que um arquiteto
precisa estar mais atento, pode-se destacar (BASS, CLEMENTS
e KAZMAN, 2013):
1. Atribuição de responsabilidades: as decisões
envolvendo a atribuição de responsabilidades incluem
o seguinte:
a. Identificar as responsabilidades importantes,
incluindo funções básicas do sistema,
infraestrutura de arquitetura e satisfação de
atributos de qualidade.
b. Determinar como essas responsabilidades são
alocadas (módulos, componentes e conectores).
2. Modelo de coordenação: as decisões do modelo de
coordenação incluem:
a. Identificar os elementos do sistema que devem
coordenar, ou estão proibidos de coordenar;
b. Determinar as propriedades da coordenação, tais
como pontualidade, integridade, correção e
consistência.
c. Escolher os mecanismos de comunicação (entre
sistemas, entre o sistema projetado e entidades
externas, entre elementos do sistema projetado).
Algumas propriedades importantes dos mecanismos
de comunicação são: síncrono versus assíncrono;
garantia de entrega versus não garantia de
entrega; e propriedades relacionadas ao
desempenho, como throughput e latência.
3. Modelo de dados: as decisões sobre o modelo de dados
incluem:
a. Escolher as principais abstrações de dados, suas
operações e suas propriedades. Isso inclui
determinar como os itens de dados são criados,

inicializados, acessados, persistidos,
manipulados, traduzidos e destruídos.
b. Organização dos dados. Isso inclui determinar
como os dados serão mantidos. Por exemplo,
usando um banco de dados relacional, um conjunto
de objetos ou ambos.
4. Gestão de recursos: decisões para gerenciamento de
recursos incluem o seguinte:
a. Identificar os recursos que devem ser
gerenciados e determinar os limites para cada
um.
b. Determinar que elemento(s) do sistema gerencia
cada recurso.
c. Determinar como os recursos são compartilhados e
as estratégias de escolhas empregadas quando há
disputa.
d. Determinar o impacto da saturação em diferentes
recursos. Por exemplo, se o acesso um página web
começar a ficar sobrecarregado, pode se decidir
por replicar a serviço em outras máquinas.
5. Mapeamento entre elementos arquitetônicos: as
decisões do mapeamento incluem:
a. O mapeamento entre os módulos e os elementos da
arquitetura.
b. A associação entre os elementos em tempo de
execução a processadores.
c. A associação entre itens do modelo de dados aos
armazenamentos de dados.
6. Escolha da tecnologia: A escolha das decisões
tecnológicas envolve o seguinte:
a. Decidir quais tecnologias estão disponíveis para
realizar as decisões tomadas nas outras
categorias.
b. Determinar se as ferramentas disponíveis para
suportar estas escolhas de tecnologia (IDEs,
simuladores, ferramentas de teste, etc.) são
adequadas para o desenvolvimento prosseguir.
c. Determinar a extensão da familiaridade interna,
bem como o grau de apoio externo disponível para
a tecnologia (tais como cursos, tutoriais,
exemplos entre outros) e decidir se isso é

adequado para prosseguir.
d. Determinar se uma nova tecnologia é compatível
com a pilha de tecnologia existente. Por
exemplo, a nova tecnologia pode funcionar em
cima ou ao lado da pilha de tecnologia
existente?
Além disso, uma técnica comum para caracterizar

atributos de qualidade é a técnica de cenários gerais. Esta
técnica consiste de seis elementos, conforme apresenta a
Figura 7. Os seis elementos que compõem o cenário são:
1) O primeiro elemento, Fonte, identifica quem origina o

evento ou ação: pode ser um usuário ou outro sistema.
2) O segundo elemento é o Estímulo descreve a ação ou o
evento externo que chega ao sistema.
3) A Resposta diz como o sistema reage ao estímulo.
4) A medida de Resposta fornece métricas e quantifica o
atributo de qualidade.
5) O Ambiente descreve as circunstâncias externas em que
a exigência de qualidade precisa ser atendida.
6) O Artefato indica a parte do sistema a que se aplica
o requisito de qualidade.
Figura 7: Cenário Geral para Atributo de Qualidade
Principais Tipos de Atributos de Qualidade

Existem diversos atributos de qualidade que devem ser
analisados na definição da arquitetura. Como já foi
mencionado, existem diferentes taxionomias para os atributos
de qualidade, muitas vezes com nomenclaturas diferentes para
conceitos iguais. Um exemplo de classificação é apresentado
na ISO/IEC 25010 (2011) que divide os atributos em oito
categorias, e cada categoria possui subcategorias. A
taxonomia da ISO/IEC 25010 é apresentada na Figura 8.
Figura 8: Taxonomia da Norma de Qualidade ISO/IEC FCD 25010
Neste material são destacadas apenas algumas das principais

categorias.
Desempenho
Para caracterizar o atributo de qualidade em um projeto
específico, pode-se utilizar a técnica de cenários gerais. O
modelo de cenários de atributos de qualidade é um modelo
universal e pode ser instanciado para cada domínio de
qualidade específico.
Para explicar a técnica, vamos caracterizar o desempenho
de um sistema bancário. Nesse exemplo, o cliente acessa o
sistema bancário por meio de um caixa eletrônico, e consegue
realizar as transações de saque, consulta ao saldo ou
transferência. Para tanto, temos que caracterizar cada um
dos seis elementos que estamos analisando. O artefato é o
desempenho geral do sistema. A fonte seria o usuário, que
inicia uma transação e envia ao sistema (estimulo).
Esperamos que a operação ocorra em condições normais
(ambiente), e o sistema enviará uma resposta. Por fim, deve-
se definir a medida de resposta do sistema, que pode ser:
• Latência. O tempo entre a chegada do estímulo e a

resposta do sistema a ele.
• Prazos de processamento. No sistema bancário, poderia

ser que a verificação do saldo deve ser feita em até
três milissegundos após iniciar a transação.
• O throughput do sistema, geralmente dado como o
número de transações que o sistema pode processar em
uma unidade de tempo.
• O jitter da resposta, que é a variação permitida na
latência.
• O número de eventos não processados porque o sistema
estava ocupado demais para responder.
Considerando todos os aspectos definidos acima, podemos

descrever um exemplo de cenário geral de desempenho para o
sistema bancário como apresentado na Figura 9.
Figura 9: Exemplo de Cenário Geral de Desempenho
A partir de cenários gerais, pode-se pensar em como

tratar os atributos de qualidade na arquitetura. O
desempenho está relacionado ao gerenciamento de recursos do
sistema para se conseguir um comportamento do sistema
aceitável em termos de tempo. O desempenho pode ser medido
em throughput e latência para sistemas de tempo real,
interativos e embarcados, embora o throughput seja
geralmente mais importante em sistemas interativos e
latência é mais importante em sistemas embarcados.
O desempenho pode ser melhorado por meio da redução da
procura ou da gestão mais adequada dos recursos. O
gerenciamento de recursos pode ser melhorado por meio do
gerenciamento mais eficaz, ou apenas aumentando os recursos
disponíveis.
Disponibilidade
Refere-se à capacidade do sistema para estar disponível
para uso, especialmente após uma falha ocorrer. A falha deve
ser reconhecida (ou impedida) e, em seguida, o sistema deve
responder de alguma forma. Táticas para tratar
disponibilidade são categorizadas em detectar falhas,

recuperar de falhas e evitar falhas.
Interoperabilidade
A interoperabilidade refere-se à capacidade dos sistemas
de trocar informações de forma útil. Os sistemas podem ter
sido construídos com a intenção de trocar informações, podem
ser sistemas já existentes e que se deseja trocar
informações entre eles, ou podem fornecer serviços gerais
sem conhecer os detalhes.
Alcançar a interoperabilidade envolve os sistemas
relevantes localizarem uns aos outros e, em seguida,
gerenciar as interfaces para que eles possam trocar
informações.
Modificabilidade
A modificabilidade lida com a mudança e o custo
monetário ou de tempo para se realizar uma mudança. As
alterações podem ser feitas por desenvolvedores,
instaladores ou usuários finais, e essas alterações precisam
ser preparadas. Há um custo de preparação para a mudança,
bem como um custo de fazer a mudança.
As táticas para reduzir o custo em se realizar uma
mudança incluem: implementar módulos menores, aumentar a
coesão e reduzir o acoplamento.
Segurança
A segurança em sistema está relacionada a diversos
conceitos distintos, tais como confidencialidade,
integridade e disponibilidade de um sistema ou de seus
dados. Confidencialidade significa manter os dados não
disponíveis àqueles que não deveriam ter acesso, ao mesmo
tempo em que se concede acesso àqueles que deveriam.
Integridade significa que não se podem realizar modificações
ou exclusão de dados não autorizadas, e disponibilidade
significa que o sistema é acessível para aqueles que têm
direito a usá-lo.
Existem táticas para detectar um ataque, limitar a
propagação de qualquer ataque, e reagir e se recuperar de um
ataque.
Recuperar-se de um ataque envolve muitas das mesmas
táticas que a disponibilidade e, em geral, envolve o retorno
do sistema para um estado consistente antes de qualquer
ataque.
Usabilidade
A usabilidade está relacionada com o quão fácil é para o
usuário realizar uma tarefa desejada e o tipo de suporte ao
usuário que o sistema fornece. O suporte arquitetônico para
usabilidade envolve tanto permitir que o usuário tome a
iniciativa em circunstâncias tais como, cancelar um comando
de longa duração ou desfazer um comando concluído.
Existe uma forte relação entre suportar o processo de
projeto da interface do usuário e suportar a
modificabilidade; esta relação é promovida por padrões que
obrigam a separação da interface do usuário do resto do
sistema, como o padrão MVC.
Portabilidade
Portabilidade está relacionada à capacidade do sistema
em rodar em diferentes plataformas. Para se obter sistemas
fáceis de portar, deve-se, dentre outros, facilitar a
instalação, a substituição de partes do sistema e a
adaptação a diferentes plataformas. As táticas de
portabilidade estão bastante relacionadas às táticas de
manutenibilidade. De fato, algumas delas são as mesmas, tal
como garantir interfaces existentes, usar intermediários e
separar a interface da aplicação. Além disso, o uso de
linguagens, bibliotecas e mecanismos de persistência capazes
de rodar em diferentes plataformas operacionais é uma
importante tática para tratar a portabilidade.
Padrões Arquiteturais
Muito das técnicas de desenvolvimento de software são

baseadas na reutilização, pois aplicando este conceito
consegue-se aumentar a produtividade e a qualidade do
produto final. No projeto da arquitetura de software, este
conceito também pode ser aplicado, uma vez que existem
arquiteturas de referência ou estilos arquiteturais que
podem ser aplicados e customizados nos projetos de software.
Muitos autores consideram estilos arquiteturais e
padrões arquiteturais como diferentes termos para designar o
mesmo conceito, tal como Gorton (2006). Outros consideram
estilos e padrões conceitos diferentes, como é o caso de
Albin (2003). Neste material, estilo arquitetural e padrão
arquitetural são tratados como dois conceitos similares, uma
vez que ambos se referem à captura de conhecimento relevante
relativo a uma solução genérica para um problema. Além
disso, novas literaturas, tais como Bass, Clements e Kazman
(2013) tratam estilos e padrões como conceitos similares,
categorizando o que são considerados como estilos
arquiteturais de outras literaturas como padrões

arquiteturais.
Os padrões em engenharia de software permitem que
desenvolvedores possam recorrer a soluções já existentes
para solucionar problemas que normalmente ocorrem em
desenvolvimento de software. Os padrões capturam experiência
existente e comprovada em desenvolvimento de software,
ajudando a promover boa prática de projeto. Um padrão
arquitetural estabelece uma relação entre (BASS, CLEMENTS e
KAZMAN ,2013):
• Contexto: é uma situação recorrente, comum no mundo

que dá origem a um problema.
• Problema: o problema, adequadamente generalizado, que
surge no contexto dado. A descrição do padrão
descreve o problema e suas variantes e descreve
quaisquer forças complementares ou opostas. A
descrição do problema geralmente inclui atributos de
qualidade que devem ser atendidos.
• Solução: uma solução arquitetônica bem-sucedida para
o problema, devidamente abstraída. A solução descreve
as estruturas arquitetônicas que resolvem o problema,
incluindo como equilibrar as muitas forças em ação. A
solução descreverá as responsabilidades e
relacionamentos estáticos entre os elementos, ou
descreverá o comportamento e a interação entre os
elementos. A solução para um padrão é determinada e
descrita por:
o Um conjunto de tipos de elementos (por exemplo,
repositórios de dados, processos e objetos).
o Um conjunto de mecanismos de interação ou
conectores (por exemplo, chamadas de método,
eventos ou barramento de mensagens).
o Um layout topológico dos componentes.
o Um conjunto de restrições semânticas abrangendo
topologia, comportamento de elementos e
mecanismos de interação.
Sistemas complexos em geral utilizam diversos padrões ao

mesmo tempo. Um sistema web, por exemplo, pode empregar um
padrão de arquitetura cliente-servidor de três camadas, mas
dentro desse padrão também pode usar proxies, caches,
firewalls, MVC e assim por diante. Além disso, cada um
destes padrões pode empregar mais padrões.
Portanto, os padrões arquiteturais são estruturas
arquitetônicas comuns e que são bem compreendidas e
documentadas. Estes padrões descrevem uma estrutura de alto
nível e o comportamento de sistemas de software, assim como

a solução para os requisitos de múltiplos sistemas. Como é
mostrado na Figura 10, diferentes problemas similares podem
usar um mesmo padrão para se chegar a uma solução.
Figura 10: Ideia Geral de Padrões
De acordo com McConnell (2004), é possível citar os

seguintes benefícios do uso de padrões em um projeto:
• Padrões reduzem a complexidade da solução ao prover

abstrações reusáveis. Um padrão arquitetural já
define elementos, serviços e relações arquiteturais,
diminuindo assim a quantidade de novos conceitos que
devem ser introduzidos à solução.
• Padrões promovem o reuso. Como padrões arquiteturais
são soluções de projeto para problemas recorrentes, é
possível que a implementação (parcial ou total) do
padrão já esteja disponível para reuso, facilitando o
desenvolvimento.
• Padrões facilitam a geração de alternativas. Mais de
um padrão arquitetural pode resolver o mesmo
problema, só que de forma diferente. Portanto,
conhecendo diversos padrões, um arquiteto pode
avaliar e escolher qual ou quais padrões irão compor
a solução do problema, considerando os benefícios e
analisando as desvantagens proporcionadas por eles.
• Padrões facilitam a comunicação. Padrões
arquiteturais facilitam a comunicação da arquitetura
porque descrevem conceitos e elementos que estarão
presentes no projeto. Portanto, se uma solução de
projeto contém padrões que são conhecidos por todos
os participantes da comunicação, os elementos e
conceitos definidos pelos padrões não precisam ser
explicitados, uma vez que os participantes já devem
conhecê-los também.
Os padrões arquiteturais contêm os principais

componentes e conectores do sistema a ser construído, e
normalmente são escolhidos em fases iniciais do projeto. A
escolha do padrão arquitetural está relacionada às decisões
para satisfazer os requisitos funcionais e não funcionais do
sistema.
Uma diferença que deve estar bem clara para qualquer
projetista de software é a diferença entre um padrão
arquitetural e um padrão de projeto. Padrões arquiteturais
podem ser usados no início do projeto, utilizando uma
granularidade alta, especificando a estrutura fundamental de
um sistema.
Como pode ser observado na Figura 11, os padrões
arquiteturais têm um escopo mais amplo, suportam decisões de
projeto de nível de sistema, tendo consequências no sistema
todo. Os tipos de componentes em padrões arquiteturais são
subsistemas ou módulos, e alguns tipos comuns de padrões
arquiteturais são: Camadas (Layers); Pipes e Filters (Dutos
e Filtros); Blackboard; Broker e Model-View-Controller
(MVC).
Por outro lado, os padrões de projeto são aplicáveis nas
fases finais de um projeto, ao refinar e estender a
arquitetura fundamental de um sistema de software. Os
padrões de projeto são aplicáveis na fase de projeto
detalhando e especificando aspectos de um projeto
particular.
Figura 11: Diferença entre Padrões Arquiteturais e Padrões de

Projeto
Os tipos de componentes em padrões de projeto são

classes ou modelos. Como exemplos de padrões de projetos,
podem ser citados algoritmos genéricos que implementam
funções de busca e classificação ou modelos de classes
especializados, como o singleton, decorator ou observer.
No intuito de entender a diferença entre padrões
arquiteturais e padrões de projeto, consideremos o exemplo
de um projeto de um carro, como mostrado na Figura 12.
No projeto de um carro, o padrão arquitetural define se

o motor será colocado na frente, no meio ou na traseira do
carro. Já o padrão de projeto está relacionado a uma decisão
mais específica, como o projeto do motor. Dependendo do
padrão de projeto a ser escolhido, será utilizado um motor
V6 ou V8, com ou sem turbos compressores.
Figura 12: Visão das diferença entre os tipos de padrões
Os padrões arquiteturais são definidos principalmente

com base em restrições impostas pelo projeto e
funcionalidades desejadas. Outro exemplo seria a construção
de uma casa. Se o terreno para construir a casa for muito
pequeno pode-se se escolher um padrão arquitetural de uma
casa sobrado ao invés de térrea. Já um padrão de projeto
poderia ser aplicado na cozinha, definindo se esta seria
estilo americano ou não.
Por fim, alguns padrões existem tanto como padrões de
projetos como padrões arquiteturais, mas são aplicados de
forma diferente e com propósitos diferentes. Um exemplo é o
padrão MVC.
Na literatura existem diversos padrões arquiteturais
definidos e descritos, e neste material serão abordados
alguns dos padrões arquiteturais mais comuns.
Camadas (Layers)
O padrão em camada define a organização do software em
serviços agrupados em camadas de abstração. As camadas são
relacionadas de maneira que cada camada deve se comunicar
apenas com a próxima camada acima ou abaixo e esta relação é
permitida apenas de forma unidirecional.
Portanto, no padrão em camadas, a camada superior provê
serviços à camada abaixo, o que configura uma dependência
entre as camadas. Em geral, as camadas mais inferiores,
provêm serviços mais básicos, normalmente de infraestrutura,
e que servem para compor os serviços de camadas mais acima.
Um exemplo é a arquitetura TCP/IP, que é organizada em cinco
camadas, sendo elas: Aplicação, Transporte, Rede, Enlace e
Física. Na arquitetura TC/IP as camadas inferiores provêm os

serviços mais básicos e a cada camada depende da camada
abaixo dela.
Outro exemplo de uso desta arquitetura é apresentado na
Figura 13, o qual apresentada uma arquitetura em camadas
para um projeto de software. Cada camada é composta de
vários pacotes que têm funções específicas. Percebe-se que o
sistema é organizado hierarquicamente, como um conjunto
ordenado de camadas. Cada uma é construída em função das
camadas abaixo que fornecem serviços para as camadas acima.
Outra particularidade é que o relacionamento entre as
camadas são sempre unidirecionais, ou seja, as camadas só
podem requisitar serviços da camada abaixo.
No exemplo da Figura 13, a camada superior é uma camada
de lógica de negócios que precisa acessar informações
específicas sobre os dispositivos do sistema. Para isso ela
requisita os serviços da camada de serviços, e esta por sua
vez solicita os serviços da camada de drivers, que realmente
acessa os dispositivos.
Figura 13: Arquitetura em Camadas
A arquitetura em camada apresenta diversas vantagens em

seu uso, tais como:
• Facilita a compreensão, uma vez que os projetos são

baseados em níveis crescentes de abstração,
permitindo dividir um problema complexo em um
conjunto de problemas menores.
• Facilita a manutenção, uma vez que as camadas são

fracamente acopladas, assim alterações em uma camada
afetam apenas a camada adjacente superior.
• Facilita a reutilização, uma vez que as camadas podem
ser reutilizadas em diferentes contextos, desde que
se respeitem as interfaces.
Como qualquer padrão, a arquitetura em camadas apresenta

também algumas desvantagens, dentre elas:
• Nem todos os sistemas são facilmente estruturados em

camadas, sendo muitas vezes difícil encontrar os
níveis de abstração corretos. Mesmo quando isso é
possível, considerações de desempenho podem colocar
obstáculos, sobretudo para o uso de uma arquitetura
fechada (SHAW e GARLAN, 1996). Neste caso, o
desempenho poderá ficar comprometido face à
necessidade de uma solicitação externa ter de passar
por diversas camadas para ser tratada (MENDES, 2002).
• Pode não ser fácil definir o número adequado de
camadas. Esse número dependerá não só da
funcionalidade a ser provida pelo sistema, mas também
dos requisitos não funcionais desejados (MENDES,
2002).
Pipes e Filters (Dutos e Filtros)

Este padrão organiza o software para processar fluxos de
dados em várias etapas. Neste padrão existem dois
componentes básicos: os filtros (filters), que são os
elementos responsáveis por uma etapa do fluxo de
processamento; e os dutos (pipes), que são os canais de
comunicação entre dois filtros. Os componentes filtros leem
dados de suas entradas e produzem dados em suas saídas,
realizando alguma transformação local. Os filtros são
entidades independentes e não compartilham informações
internas com os outros filtros, ou seja, não conhecem os
filtros anteriores e posteriores. Apenas manipulam as
informações que recebem provendo uma saída. Uma
especialização comum desse padrão são os chamados pipelines,
que restringem a topologia para sequências lineares de
filtros. Quando em um pipeline, cada filtro processa a sua
entrada como um todo se tem um padrão de transformação em
lote sequencial (batch sequential) (SHAW e GARLAN,1996).
Figura 14: Padrão Pipe e Filters
A Figura 14 apresenta uma visão do padrão pipes e

filters. Pode-se ver nesta figura que a arquitetura pode
conter diferentes pipes e filters, que podem ser reusados e
recombinados para diferentes propósitos.
Um exemplo do uso do padrão Pipes e Filters é a
arquitetura de um compilador, que pode ser dividida nos
seguintes filters: analisador léxico, analisador sintático,
analisador semântico, gerador de código intermediário e
otimizador, que são conectados por diferentes pipes. Esta
arquitetura é apresentada na Figura 15 por um diagrama de
componentes da UML. Um componente tem as mesmas
características de um filtro, por isso, podemos utilizá-los
para criar uma arquitetura pipers e filters.
Nesta arquitetura existe um pipe que conecta o
analisador léxico ao sintático e que transmite um fluxo de
tokens; o pipe que transporta a árvore de derivação
sintática do analisador sintático para o analisador
semântico; o pipe que transporta a árvore de sintaxe do
analisador semântico para o gerador de código intermediário;
e, por fim, o pipe que conecta o gerador de código
intermediário ao otimizador.
Figura 15: Diagrama UML de um sistema baseado em pipers e filters

para um compilador
Outro exemplo do uso do padrão pipe e filters pode ser

na aplicação de etapas da mineração de textos. Na Figura 16
é apresentado alguns componentes que podem ser utilizados
para a mineração de textos. Na Figura 16 que o primeiro

componente depende de um texto, que o modifica e gera uma
lista de tokens. A partir deste momento, os componentes
podem ser aplicados na sequencia demonstrada ou em outra
ordem, além de poderem ser adicionados ou removidos
componentes, dependendo da tarefa de mineração desejada. Na
Figura 16 especificamente, o segundo remove palavras não
desejadas e o terceiro aplica o stemming, que basicamente
reduz cada token a sua raiz. É importante notar que a
mineração de texto é um conjunto de processos que são
executados em sequência, ou seja, o texto inicial vai sendo
transformado por cada componente (filters), e o resultado da
aplicação do filter é enviado a ouros filters por meio do
pipe.
Figura 16: Diagrama UML de um sistema baseado em pipers e filters

para Mineração de Texto
O padrão pipe e filters possui diversas propriedades

interessantes, dentre elas (SHAW e GARLAN, 1996):
• Permite que o projetista compreenda o comportamento

geral de um sistema como uma composição simples dos
comportamentos dos filtros individuais.
• Facilita o reúso. Quaisquer dois filtros podem ser
conectados, desde que eles estejam de acordo em
relação aos dados sendo transmitidos entre eles.
• Facilita a manutenção e o crescimento. Novos filtros
podem ser adicionados a um sistema existente, bem
como filtros podem ser substituídos por outros
melhores ou atualizados.
• Suporta execução concorrente. Cada filtro pode ser
implementado como uma tarefa separada e
potencialmente executada em paralelo com outros
filtros.
Entretanto, há também desvantagens, tais como (SHAW e

GARLAN, 1996):
• Apesar dos filtros poderem processar dados de forma

incremental, eles são inerentemente independentes e,
portanto, o projetista deve pensar cada filtro como
provendo uma transformação completa dos dados de
entrada para dados de saída.
• Devido a seu caráter transformacional, este padrão
não é recomendado para tratar aplicações interativas.
Invocação Implícita
A invocação implícita (ou baseado em eventos) requer que os
componentes interessados em um evento se registrem a fim de
recebê-lo. Os componentes podem tanto registrar interesse em
receber eventos quanto de divulgar eventos (MENDES, 2002).
A invocação implícita se baseia na ideia de que um
sistema é composto de diversos componentes, alguns
componentes divulgam um ou mais eventos enquanto outros
componentes divulgam o interesse por eventos. Quando um
evento é anunciado, o próprio sistema invoca todos os
procedimentos registrados para o evento. Assim, o anúncio de
um evento implicitamente provoca a invocação de
procedimentos em outros componentes (SHAW e GARLAN, 1996).
A Figura 17 ilustra o padrão invocação implícita. Neste
padrão, o componente anunciante de um evento divulga o
evento, que é então capturado pelo mecanismo de difusão de
eventos. Esse mecanismo é responsável por difundir o evento
para todos os componentes que registraram interesse no
mesmo, invocando os procedimentos associados. Portanto,
nesta arquitetura os componentes ouvintes e anunciantes não
são invocados diretamente, sempre a invocação é feita pelo
componente intermediário, mecanismo de difusão de eventos.
Figura 17: Padrão Invocação Implicita
Um exemplo de sistema que pode empregar este padrão

são listas de notícias que possuem componentes de registro
de novos usuários. Nestes sistemas o componente anunciante
divulga as notícias e o mecanismo de difusão é responsável

por difundir a notícia aos usuários registrados para aquele
anunciante.
Os eventos são assíncronos, o que permite que o
componente anunciante continue realizando alguma outra
computação após o envio do evento. Além disso, o componente
anunciante desconhece a identidade dos componentes ouvintes.
Assim, este padrão arquitetural provê suporte à
manutenibilidade, desde que a inserção e a remoção de
componentes sejam fáceis de serem feitas (MENDES, 2002).
Padrão MVC
O padrão MVC é muito utilizado em soluções de software,
principalmente em aplicações que contém interfaces com os
usuários e estas interfaces permita a visualização de
diferentes formas de um mesmo conjunto de dados, tal como um
aplicativo que permita o usuário ver os dados de diferentes
perspectivas, como por exemplo, a visualização dos dados por
meio de um gráfico de barras ou um gráfico circular. Quando
se deseja este tipo de interação, a interface do usuário
deve ser mantida separada da funcionalidade do aplicativo e
ainda assim ser responsiva à entrada do usuário ou a
alterações nos dados da aplicação. Queremos uma solução em
que a interface seja disjunta da aplicação, como se
existisse várias interfaces do usuário, mantidas e
coordenadas por uma mesma aplicação.
Para conseguir isto, o padrão Modelo-View-Controller
(MVC) separa a aplicação em três partes:
• O modelo (Model), que contém a funcionalidade

principal e os dados.
• A Visão (View), que exibe informações para o usuário
e;
• O controlador (Controller), que faz a mediação entre
o modelo e a visão, e gerencia as mudanças de estado
da visão.
A visão e o controlador juntos formam a interface do

usuário. Um mecanismo de mudança-propagação garante
consistência entre a interface do usuário e o modelo.
Os componentes MVC são conectados uns aos outros por
meio de algum tipo de notificação, como eventos ou retorno
de chamadas. Essas notificações contêm atualizações de
estado. Uma mudança no modelo precisa ser comunicada
a visão para que esta possa ser atualizada.
Um evento externo, como uma entrada de dados pelo

usuário, precisa ser comunicado ao controlador, que pode,
por sua vez, atualizar a visão e/ou o modelo.
A Figura 18 mostra uma possível interação entre os
componentes do MVC. Pode-se perceber que o controlador
recebe os dados da visão e solicita ao modelo para realizar
funcionalidades a partir das ações ocorridas na visão. O
modelo por sua vez é responsável por notificar as alterações
dos dados para a visão ser atualizada, no entanto em geral,
as atualizações em geral são coordenador pelo controlador,
como pode ser visto na Figura 17.
Figura 18: Padrão MVC. Adaptado de Bass, Clements e Kazman

(2013)
Como é visto na Figura 19, a camada de interface no

padrão MVC é uma combinação da visão e controlador (FOWLER,
2003). A visão refere-se à entrada e à exibição de
informações na interface. Já o controlador, recebe a entrada
do usuário, envia uma requisição para o modelo (que pode ser
estruturado, por exemplo, em várias camadas) e recebe sua
resposta e solicita que a visão se atualize conforme
apropriado. Uma vez alterado o estado dos elementos do
modelo, o controlador pode, se apropriado, selecionar outros
ou alterar elementos de visão a serem exibidos ao usuário.
Assim, o controlador situa-se entre o modelo e a visão,
isolando-os um do outro.
Figura 19: A Visão do Padrão MVC
Uma vantagem do uso do MVC é que os componentes são

fracamente acoplados, sendo fácil de desenvolvê-los e testá-
los em paralelo e as mudanças em um componente têm impacto
mínimo sobre os outros. Além disso, a partir de um modelo
pode-se ter diferentes visões.
O padrão MVC é amplamente utilizado em bibliotecas de
interface de usuário, como as classes Swing do Java, o
framework ASP.NET da Microsoft. Ademais, é comum um único
aplicativo conter muitas instâncias do MVC (muitas vezes um
por objeto de interface do usuário) (BASS, CLEMENTS e
KAZMAN, 2013).
Cliente Servidor
A arquitetura cliente servidor é uma arquitetura o qual a
aplicação é executada fisicamente distribuída em dois tipos
de estrutura:
• Os clientes, que requerem um serviço e;

• Os servidores que são os responsáveis por fornecer o
serviço.
Normalmente essa arquitetura é utilizada quando um

grande número de clientes distribuídos necessita acessar
serviços compartilhados. No entanto, isto não é tão simples,
haja vista que é necessário gerenciar os serviços ou os
recursos compartilhados para que se haja uma política e
controle sobre o acesso. Esta arquitetura permite aumentar a
escalabilidade e disponibilidade dos serviços e a
arquitetura pode ter variações, tais como um servidor
central ou múltiplos servidores distribuídos.
Um exemplo de arquitetura cliente servidor é apresentada
na Figura 20. Nesta figura vários clientes necessitam
acessar e gravar informações em uma mesma base de dados
compartilhada. Dessa maneira, o gerenciamento da base de
dados é provido pelo servidor de banco de dados, que é

acessado de forma compartilhada por todos os clientes.
Figura 20: Arquitetura Cliente Servidor
O fluxo computacional de sistemas cliente-servidor é

assimétrico, ou seja, os clientes iniciam interações
invocando serviços de servidores. Assim, o cliente deve
conhecer a identidade de um serviço para invocá-lo e os
clientes iniciam todas as interações. Em contrapartida, os
servidores não conhecem a identidade dos clientes antes de
uma solicitação de serviço e devem responder às solicitações
iniciadas pelo cliente. Além disso, os componentes de
servidores podem ser clientes para outros servidores.
Como desvantagens do uso da arquitetura cliente
servidor, o servidor pode ser um gargalo de desempenho, caso
haja muitas requisições de diferentes clientes. Além do
mais, se o servidor falhar (caso não haja replicação do
serviço) os clientes podem parar de funcionar.
Portanto, o padrão cliente servidor separa os
aplicativos clientes dos serviços que eles usam. Este padrão
simplifica os sistemas fatorando os serviços comuns, que são
reutilizáveis. Como os servidores podem ser
acessado por qualquer número de clientes, é fácil adicionar
novos clientes a um sistema. Da mesma forma, os servidores
podem ser replicados para suportar escalabilidade ou
disponibilidade.
O exemplo mais conhecido do uso do padrão cliente
servidor é a World Wide Web. Nestas aplicações, os clientes
(navegadores da Web) acessem informações de servidores por
meio da Internet usando o protocolo de solicitação/resposta
HTTP (HyperText Transfer Protocol).
Arquitetura Peer to Peer

A arquitetura Peer-to-Peer (P2p) consiste em uma arquitetura
o qual os recursos e serviços estão fisicamente
distribuídos, mas ao contrário da arquitetura cliente
servidor, todos os nós desempenham papeis semelhantes.
Portanto, nesta arquitetura o compartilhamento de recursos e
serviços computacionais pode ser realizado diretamente entre
os sistemas, sem a necessidade de invocar um servidor
central.
Na arquitetura P2P, cada processo é responsável pela
consistência dos seus dados (recursos), e pela sincronização
das várias operações, conforme é apresentado na Figura 21.
Nesta arquitetura os nós (peers) se conectam primeiro à rede
peer-to-peer, na qual descobrem outros pares com os quais
podem interagir e, em seguida, iniciam ações para alcançar
sua computação cooperando com outros nós solicitando
serviços. Muitas vezes a busca por outro nó é propagada de
um nó para seus pares conectados por um número limitado de
saltos. Uma arquitetura peer-to-peer pode ter nós
especializados (chamados supenodes) que possuem recursos de
indexação ou roteamento e permitem que a pesquisa de um nó
regular alcance um número maior de pares.
Os nós podem ser adicionados e removidos da rede peer-
to-peer sem impacto significativo, resultando em grande
escalabilidade para todo o sistema. Isso fornece
flexibilidade para implementar o sistema em uma plataforma
altamente distribuída
Figura 21: Arquitetura Peer to Peer
Existem diferentes categorizações dos modelos de arquitetura

P2P, dentre as quais se destacam:
• Centralizada: existe um índice central com

informações atualizadas, quando um nó quer requerer
um serviço, ele procura neste índice. Muito utilizada
em sistemas de mensagem.
• Descentralizada e Estruturada: rede que não possui um
servidor centralizado de diretório de informações,
mas que tem uma estruturação significativa entre os
nós.
• Descentralizada e não Estruturada: rede que não
possui servidor centralizado, nem controle preciso
sobre a topologia e localização/de dados e serviços.
Utilizada em sistema de compartilhamento de arquivos,
por exemplo.
A arquitetura P2P vem sendo amplamente utilizada em

diversos tipos de aplicações. Um exemplo são os sistemas de
troca de mensagens instantâneas. Diferentemente do correio
eletrônico, em que uma mensagem é armazenada em uma caixa
postal e posteriormente entregue ao usuário que verificou a
caixa postal no seu servidor, os sistemas mensagens fornecem
entrega imediata ao usuário.
Alguns outros tipos de software que comumente utilizam a
arquitetura P2P são as comunidades de jogos on-line, e os
groupwares, que são software para trabalho colaborativo. Por
fim, pode-se citar o uso da arquitetura P2P na computação
distribuída, no qual são desenvolvidos softwares que
distribuem e coordenam a execução de um aplicativo em
diversas máquinas no intuito de melhorar o seu desempenho.
As desvantagens do padrão peer-to-peer estão fortemente
relacionadas com seus pontos fortes. Como é uma arquitetura
descentralizada, o gerenciamento de segurança, consistência
de dados, disponibilidade de dados e serviços, backup e
recuperação são mais complexos.
Arquitetura Orientada a Serviço (Service-Oriented Architecture –SOA)

Um tipo de implementação que vem se tornando cada vez mais
comum é a utilização de serviços de software. Esses serviços
são oferecidos (e descritos) por provedores de serviços que
podem então serem consumidos. No entanto, para consumi-los,
os consumidores precisam ser capazes de entender e usar
esses serviços sem qualquer conhecimento detalhado de sua
implementação.
Além disso, esses serviços distribuídos podem estar
implementados em linguagens diferentes das dos consumidores
e executados em plataformas distintas. Portanto, dois
grandes desafios nesta arquitetura são:
• Tratar a interoperabilidade entre os componentes; e

• Localizar os serviços que os consumidores necessitam.
Além dos dois desafios principais, deve-se pensar em

outros aspectos, tais como disponibilidade, confiabilidade e
segurança dos serviços.
O padrão SOA descreve uma coleção de componentes
distribuídos que fornecem e/ou consomem serviços. Em um SOA,
os componentes dos provedores de serviços e os componentes
dos consumidores do serviço podem usar diferentes
plataformas e linguagens de programação. Os serviços são em
grande parte autônomos, ou seja, os provedores de serviços e
os consumidores de serviços são normalmente implantados de
forma independente e, muitas vezes, pertencem a sistemas
diferentes ou mesmo a organizações diferentes. Além disso,
os componentes possuem interfaces que descrevem os serviços
que eles solicitam de outros componentes e os serviços que
eles fornecem.
Portanto a arquitetura SOA aumenta a interoperabilidade
ao permitir que um programa cliente em uma organização possa
interagir com um programa servidor em outra, por meio do
acesso à um método remoto que é acessado por um cliente
através de uma URL (Uniform Resource Locator). Originalmente
o acesso ao servidor está baseado no protocolo HTTP, mas
pode operar sobre diferentes protocolos de transporte, tais
como SMTP, TCP e UDP.
Para acessar o serviço, o cliente deve entender o
serviço que é descrito pelo descritor de serviço. O descrito
de serviço é um “contrato” entre cliente e servidor sobre o
serviço oferecido e também especifica como as mensagens
devem ser transportadas (HTTP por exemplo). Assim, o
solicitante sabe o nome do método a ser chamado, os
parâmetros e o tipo de retorno.
Contudo, é necessário encontrar os serviços. A
arquitetura SOA se baseia na capacidade de identificar
serviços e suas características. Consequentemente, esta
arquitetura depende de um diretório que descreva quais os
serviços disponíveis dentro de um domínio.
Um exemplo do uso da arquitetura SOA é o cálculo do
valor do frete em um site do comércio eletrônico. Para
calcular o valor do frete é necessário conhecer o lugar de
origem, o lugar de destino, o peso e o tipo do transporte
(normal, sedex ou sedex 10 por exemplo). A tabela de valores
pode ser frequentemente alterada, não sendo viável, portanto
ao site de comércio eletrônico calcular este valor. Ao invés
disso, o cliente pode acessar um método remoto do servidor
(correios, por exemplo) que calcula este valor de maneira

sempre atualizada.
Outro exemplo é o mostrado na Figura 22. O cliente
acessa um site de serviços de viagens, que retorna os
melhores preços para hotéis, alugueis de carros e passagens
áreas. Uma vez que o cliente passou os detalhes da busca,
como, data e o tipo de serviço que deseja, o site de agente
de viagens invoca métodos remotos (passando os parâmetros
desejados) de cada site que realiza o serviço esperado.
Assim, com o retorno destes métodos o site de agentes de
viagens organiza estes dados e retorna ao cliente.
Figura 22: Exemplo de uso da Arquitetura SOA
O principal benefício e o principal motor da arquitetura

SOA é a interoperabilidade. Como os provedores de serviços e
os consumidores de serviços podem ser executados em
diferentes plataformas, as arquiteturas orientadas a
serviços geralmente integram uma variedade de sistemas,
incluindo sistemas legados.
Multicamadas (Multi-tier)
Em uma implantação distribuída, geralmente há a necessidade
de distribuir a infraestrutura de um sistema em subconjuntos
distintos. Isto pode ocorrer por razões operacionais ou
comerciais (por exemplo, diferentes partes da infraestrutura
podem pertencer a diferentes organizações).
Dessa forma, é necessário dividir o sistema em um número
de estruturas de execução computacionalmente independentes
que contenham grupos de software e hardware conectados por
alguns meios de comunicação. Isso é feito para fornecer
ambientes de servidores específicos otimizados para
requisitos operacionais e uso de recursos.
Como resposta a esta demanda as estruturas de execução
de muitos sistemas são organizadas como um conjunto de
agrupamentos lógicos de componentes. Cada agrupamento é

denominado uma camada. O agrupamento de componentes em
camadas pode basear-se em uma variedade de critérios, como o
tipo do componente, o compartilhando do mesmo ambiente de
execução ou ter o mesmo objetivo de execução.
Não se pode confundir o padrão em Camadas (Layers) com o
Padrão Multicamadas (Multi-tier). O padrão em Camadas é
utilizado para a organização lógica do sistema sem
considerar a distribuição física destas camadas. Já o padrão
Multicamadas é um padrão para soluções distribuídas (baseado
em componentes executáveis). Além disso, camada não é um
componente, e sim um agrupamento lógico.
O uso de camadas pode ser aplicado a qualquer coleção
(ou padrão) de componentes, embora na prática ele seja mais
usado no contexto do padrão cliente-servidor. As camadas
causam restrições topológicas que restringem quais
componentes podem se comunicar com outros componentes.
Especificamente, os conectores podem existir apenas entre
componentes na mesma camada ou que estejam em níveis
adjacentes. O padrão multicamadas encontrado em muitas
aplicações Java EE e Microsoft .NET é um exemplo de
organização em camadas derivado do padrão cliente servidor.
A principal fraqueza da arquitetura multicamadas é o seu
custo e complexidade. Contundo as camadas tornam mais fácil
garantir a segurança e otimizar o desempenho. Elas também
aumentam a modificabilidade do sistema, pois são organizados
em subgrupos computacionalmente independentes, reduzindo
assim o acoplamento.
Um exemplo de arquitetura multicamada é apresentado na
Figura 23, que usa uma notação informal para descrever uma
aplicação Java EE de um website. Muitos tipos de componentes
e conectores são específicos para a plataforma de suporte,
que é o Java EE neste caso.
Figura 23: Arquitetura Multicamadas para uma aplicação JavaEE.

(BASS, CLEMENTS e KAZMAN, 2013)
Padrões e Táticas de Atributos de Qualidade
Um padrão é uma solução para uma classe de problemas em um

contexto geral. Quando um padrão é escolhido e aplicado, o
contexto de sua aplicação torna-se muito específico, de
forma que para uma determinada conjuntura arquitetônica,
precisamos examiná-lo de duas perspectivas:
• O atributo de qualidade inerente do padrão. Os

padrões existem para alcançar certos atributos de
qualidade, e precisamos comparar os que promovem (e
os que diminuem) com as nossas necessidades.
• Outros atributos de qualidade que o padrão não está
diretamente relacionado com, mas que afeta, e que são
importantes em nossa aplicação.
Os padrões por si só já auxiliam a alcançar atributos de

qualidade, no entanto, para isso eles devem ser corretamente
aplicados. Por exemplo, se for utilizado o padrão em camadas
e a tática de dependências restritas não for empregada (a
camada só pode se comunicar com as camadas adjacentes),
qualquer função em qualquer camada pode chamar qualquer
outra função em qualquer outra camada, destruindo o baixo

acoplamento, tornando o padrão de camadas pouco efetivo.
Portanto, cada padrão arquitetural já está relacionado a
um conjunto de táticas que tornam este padrão efetivo para
determinada circunstancias. Por exemplo, na Tabela 1 são
mostradas a relação de táticas de modificabilidade e como
alguns padrões as empregam.
Dessa forma, quando aplicamos um determinado padrão,
muitas vezes temos que utilizar táticas de modo que
atributos de qualidade requisitados sejam satisfeito na
arquitetura proposta. Para isso, Bass, Clements e Kazman
(2013) enumeram um conjunto de táticas que podem ser
aplicadas para tratar certos atributos de qualidade. Uma
tática, neste contexto, é uma decisão de projeto que
influencia o controle de certo atributo de qualidade. Uma
coleção de táticas define uma estratégia de projeto
arquitetônico.
Tabela 1 - Padrões de Arquitetura e Táticas Correspondentes.

Adaptado de Bachmann, Bass e Nord (2013)
Modificabilidade
Aumento Diminuição do Retardo do Tempo
da Coesão Acoplamento de Vinculação
Usa vinculação em tempo de execução

Usa registro em tempo de execução
Aumenta a Coerência Semântica
Usa vinculação na inicialização

Aumenta o nível de abstração
Abstrai Serviços Comuns
Usa um Intermediador
Usa um Wrapper
Encapsulamento
Padrão
Camadas x x x x x
Pipes e Filters x x x x
MVC x x x x
Como exemplo de táticas que podem ser utilizadas no

projeto de arquitetura, é apresentado no Quadro 1 táticas
para atingir atributos de qualidade de segurança.
Quadro 1- Táticas para atingir atributos de qualidade de

segurança. (BASS, CLEMENTS e KAZMAN, 2013)
Resistir a Ataques
Autenticação diz respeito a garantir que um usuário ou computador remoto é realmente quem diz ser. Senhas,
Autenticar usuários certificados digitais e identificação biométrica são alguns meios de se prover autenticação.
Autorização diz respeito a garantir que um usuário autenticado tenha o direito de acessar e modificar tanto
Autorizar usuários dados quanto serviços. Isso é feito normalmente provendo alguns padrões de controle de acesso dentro do
sistema. O controle de acesso pode ser por usuário ou classe de usuário. Classes de usuários podem ser
definidas por grupos de usuários, por papéis de usuário ou por listas de indivíduos.
Dados devem ser protegidos contra acesso não autorizado. Confidencialidade é normalmente atingida
Manter aplicando alguma forma de criptografia a dados e links de comunicação. Criptografia provê uma proteção
confidencialidade extra para dados mantidos em bases de dados, além da autorização. Já links de comunicação tipicamente não
dos dados têm controles de autorização e, portanto, a criptografia é a única proteção neste caso.
Manter integridade A integridade dos dados também deve ser garantida. Para verificar a integridade, informação redundante, tal
dos dados como soma de verificação, pode ser codificada junto aos dados.
A alocação de serviços a servidores pode ser feita de modo que apenas serviços limitados estejam
Limitar exposição disponíveis em cada servidor.
Firewalls podem ser usados para restringir o acesso com base em fonte de mensagens ou porta de destinação.
Mensagens de fontes desconhecidas podem ser uma forma de ataque. Contudo, nem sempre é possível
Limitar acesso limitar o acesso a fontes conhecidas. Um site web público, por exemplo, pode esperar receber solicitações de
fontes desconhecidas.
Detectar Ataques
Sistemas de detecção de intrusão funcionam comparando padrões de tráfego de rede. No caso de detecção de
Sistema de detecção mau uso, o padrão de tráfego é comparado com padrões históricos de ataques conhecidos. Detectores de
de intrusão intrusão têm de ter, dentre outros, algum tipo de sensor para detectar ataques, bases de dados para registrar
eventos para posterior análise, ferramentas para análise e um console de controle que permita ao analista
modificar ações de detecção de intrusão.
Recuperação de Ataques
As técnicas de recuperação de falhas sugeridas nas táticas de confiabilidade podem ser aplicadas, já que elas
Restaurar estado se propõem a restaurar um estado consistente a partir de um estado inconsistente. Atenção especial deve ser
dada à manutenção de cópias redundantes de dados administrativos do sistema, tais como senhas, listas de
controle de acesso, serviços de nomes de domínio e dados de perfis de usuários.
Manter uma trilha Uma trilha de auditoria é um registro das transações aplicadas aos dados do sistema junto com informações
de auditoria de identificação. Essas informações podem ser usadas para trilhar as ações do agressor, apoiar
reconhecimento (provendo evidência de que uma particular requisição foi feita) e apoiar a recuperação do
sistema. Trilhas de auditoria são frequentemente alvo de ataques e, portanto, devem ser mantidas de modo
confiável.
Decisões Arquiteturais Baseada em Atributos de Qualidade

Quando está se se projetando uma arquitetura, diversas
questões relacionadas aos atributos de qualidade surgem, e
muitas decisões devem ser tomadas. Vamos supor que estamos
projetando um sistema para controle de processos
judiciários, e quando o processo muda de status, é enviada
uma mensagem com a mudança e o parecer as partes
interessadas.
A arquitetura é decidia baseada principalmente nos
atributos de qualidade (que não são disjuntos dos requisitos
funcionais). O sistema proposto pode ter uma arquitetura
baseada em vários padrões, como por exemplo, MVC e cliente
servidor. No entanto, para a parte específica de envio de
mensagens, pode-se utilizar o padrão de invocação implícita.
A partir disto, táticas são utilizadas junto ao padrão
escolhido para atender os atributos especificados no
sistema.
As táticas para garantir que a arquitetura suporte os
atributos de qualidade serão determinadas de acordo com os
atributos desejados pelo cliente. Neste sistema, três

atributos importantes incialmente são identificados:
• Segurança. Como garantir a confidencialidade e a

integridade da informação?
• Custo. Qual o custo de envio de mensagens?
• Disponibilidade. Como garantir que a mensagem será
entregue?
Além dos atributos iniciais como mostrado na Figura 24,

o arquiteto pode analisar outras características importantes
relacionadas a estes atributos. Por exemplo, o arquiteto
define que o custo é o atributo mais importante, e a tática
para abordar este atributo é utilizar mensagens que sejam
sem custo.
Figura 24: Decisões Iniciais da Arquitetura
No entanto, outros aspectos devem ser analisados para os

tipos de mensagem sem custo
• Desempenho: Como garantir que a mensagem será

entregue em um tempo razoável independentemente do
número de clientes?
• Modificabilidade. Como alterar o sistema atual de
forma a implementar a modificação solicitada?
• Usabilidade. Como garantir que se saiba que a
mensagem foi lida?
Considerando os atributos analisados as decisões são

então definidas de acordo com a Figura 25. Além disso, o
arquiteto poderia considerar a modificabilidade um critério
importante. Para isso ele usa o método de utilizar um
intermediário para reduzir o acoplamento. Assim outro
atributo que teria que ser levado em consideração é a
interoperabilidade do método intermediário a ser utilizado.
Figura 25: Adiconando Decisões à Arquitetura
A partir das táticas e decisões do projeto pode ser

utilizada uma matriz de qualidade para decidir como a
arquitetura será implementada. Para isso, devem-se levantar
as tecnologias que podem satisfazer as decisões
arquiteturais tomadas.
A partir das tecnologias escolhidas, o arquiteto confere
pesos aos atributos de qualidade (considerando o mais
importante ao projeto) e atribuindo uma nota para cada
tecnologia em cada atributo. No exemplo de envio de
mensagens, vamos considerar algumas tecnologias disponíveis:
SMS, whatsapp, email, ligação, mensagem dentro do próprio
sistema.
O arquiteto já havia decidido que o custo é fator
primordial, por isso, ele receberá o maior peso possível
(cinco, em uma escala de zero a cinco). O arquiteto atribuiu
pesos a todos os atributos e notas a cada tecnologia para
cada atributo, como é mostrado na Tabela 2. Portanto dessa
forma o arquiteto tem critérios para definir qual tecnologia
utilizar na arquitetura proposta.
Tabela 2 – Matriz de Qualidade das Tecnologias
Atributos
Tecnologias Custo Segurança Disponibilidade Usabilidade Modificabilidade Desempenho Total
(5) (4) (3) (4) (4) (2)
SMS 3 4 4 4 4 3 3,6
Whatsapp 5 4 4 5 4 4 4,4
Email 5 2 4 2 4 4 3,5
Ligação 2 2 2 1 2 1 1,7
Sistema 5 5 4 2 5 5 4,3
Arquiteturas e o Desenvolvimento de Software
O desenvolvimento de software apresenta uma gama de

diferentes tipos de sistemas que são categorizados na
literatura. Essas categorias podem auxiliar a ajudar a
definir a arquitetura do software, uma vez que sistemas
similares muito provavelmente terão arquiteturas similares.
Na literatura são encontradas diversas classes de sistemas,
entre elas (BLAHA e RUMBAUGH, 2006) (MENDES, 2002):
• Sistemas de Transformação (ou Processamento) em Lote:

são organizados como uma série de módulos conectados
sequencialmente.
• Sistemas de Transformação Contínua: similares aos
sistemas de transformação em lote no que se refere ao
fato de serem organizados como uma série de módulos
conectados sequencialmente, os sistemas de
transformação contínua recebem entradas continuamente
e calculam saídas de maneira incremental.
• Sistemas de Interface Interativa: são dominados por
interações com agentes externos, tais como pessoas e
dispositivos.
• Sistemas de Simulação Dinâmica: modelam ou controlam
objetos do mundo real e, portanto, o desempenho pode
ser um fator crítico.
• Sistemas de Tempo Real: são sistemas interativos com
fortes restrições de tempo, frequentemente projetados
para operarem próximos de seus limites.
• Sistemas Gerenciadores de Transações: são sistemas
cuja função principal é armazenar e recuperar dados.
• Sistemas de Informação: são sistemas com o objetivo
coletar, manipular e preservar grandes quantidades de
informações complexas.
Essas categorias não são necessariamente disjuntas. Por

exemplo, um sistema de informação normalmente é também um
sistema de interface interativa.
Além de categorizar os sistemas pelo objetivo final de
sua implementação, podem-se categorizar os sistemas de
acordo com a plataforma em que são executados, como
aplicações desktop, aplicações web e aplicações móveis.
Aplicações desktop são executadas em estações de
trabalho (computadores, notebooks) e podem utilizar os
recursos dessas máquinas. Este tipo de aplicação pode
executar em uma única máquina (standalone) ou em várias

máquinas (aplicações distribuídas).
Uma aplicação web é uma aplicação de software que
utiliza a Web, por meio de um navegador (browser), como
ambiente de execução.
Por fim, as aplicações móveis (mobile) são aplicativos
de software desenvolvidos para dispositivos móveis, como
smarthphones ou tablets. As aplicações mobile podem executar
via Web (neste caso são também aplicações web) ou como
clientes específicos de certa plataforma móvel (Apple,
Android, Windows Mobile).
Além disso, o avanço tecnológico trouxe uma nova
plataforma, a Internet das Coisas IoT (do inglês Internet of
Things). IoT visa conectar dispositivos físicos (tais como
eletrônicos, eletrodomésticos, carros entre outros) por meio
de redes de computadores. A IoT permite que os objetos sejam
detectados e/ou controlados remotamente por meio da
infraestrutura de rede existente, criando oportunidades para
uma integração mais direta do mundo físico em sistemas
baseados em computador e resultando em maior eficiência,
precisão e benefício econômico além da redução de
intervenção humana (CISCO, 2013). Contudo, a IoT pela sua
característica distribuída e interoperável traz muitos
desafios na definição da arquitetura do software.
Nas próximas seções são apresentados padrões e táticas
que podem ser utilizadas na definição da arquitetura de
algumas destas plataformas.
Sistemas Web
Sistemas Web funcionam sobre o protocolo HTTP (HiperText
Transfer Protocol), que é um protocolo de aplicações cliente
servidor que define um formato padrão para especificar a
requisição de recursos na Web. Por meio dele, um usuário
utilizando uma aplicação cliente (p.ex., um navegador) pode
requisitar recursos disponíveis em um servidor remoto
(p.ex., o servidor Web).
Além de gerenciar a requisição e a transferência de
recursos por meio do protocolo HTTP, um navegador web também
trata da apresentação visual dos recursos. A meta linguagem
HTML (HyperText Markup Language) é comumente usada para
expressar o conteúdo e a formatação visual de páginas Web.
No entanto, o navegador também pode tratar linguagens de
script, tal como JavaScript, para apresentar HTML dinâmico.
Os navegadores atuais suportam o uso conjunto de
JavaScript a da API XMLHttpRequest, o que permite fazer
requisições HTTP para um servidor web de maneira
transparente em background e independentemente da interação
com o usuário, o que é conhecido como AJAX (Asynchronous

JavaScript and XML). Essa tecnologia permitiu que
desenvolvedores tornassem a maior parte do HTML dinâmico, o
que são as chamadas Aplicações Ricas para Internet (Rich
Internet Applications – RIAs).
Aplicações Web de grande escala, tais como portais e
aplicações de comércio eletrônico, tipicamente estão
expostas a um grande número de requisições concorrentes.
Dessa forma, no desenvolvimento web alguns atributos de
qualidade devem ser considerados mais detalhadamente na
definição da arquitetura. Três em especial são:
• Usabilidade: muitas aplicações web rodam em

diferentes navegadores, com diferentes sistemas
operacionais e diferentes tamanhos de telas.
• Disponibilidade: Um sistema web, principalmente de
grande acesso precisa estar disponível em grande
parte do tempo.
• Desempenho: As aplicações web com grande volume de
acesso precisa garantir que conseguirá responder as
solicitações de acesso.
Algumas táticas para usabilidade, independentemente da

plataforma são: tratar a legibilidade (verifique a
legibilidade das informações apresentadas nas telas do
sistema), consistência (avalie se é mantida uma coerência no
projeto de códigos, telas e diálogos com o usuário),
feedback (avalie a qualidade do feedback imediato às ações
do usuário) entre outros. No entanto, para sistemas web em
especial algumas outras táticas devem ser utilizadas, dentre
elas:
• Separar a interface do usuário, usando, por exemplo,

o padrão MVC.
• Utilizar design responsivo (que se adaptam a
diferentes telas) para criar os sistemas web. Esta
tática auxiliará que o mesmo sistema possa ser
acessado por diferentes dispositivos.
Os sistemas web como mencionados, precisam exibir um

alto nível de disponibilidade. Para tal, são necessárias
arquiteturas de software modulares e multicamadas, nas quais
os diferentes componentes possam ser facilmente replicados
para aumentar o desempenho e evitar pontos de falhas.
(CASTELEYN et al., 2009). Assim, uma aplicação web pode ser
considerada um tipo de sistema distribuído, com uma
arquitetura cliente-servidor, como apresentado na Figura 26.

Essa arquitetura além de auxiliar na disponibilidade
facilita também que se consiga gerenciar o desempenho, uma
vez que se consegue aumentar o número de recursos em cada
camada caso seja necessário.
Figura 26: Uma Aplicação Web Usando Arquitetura Multicamada.

Adaptado de Casteleyn et al.(2009)
Sistemas Mobile
Os aplicativos mobile “apps”, são softwares que funcionam em
dispositivos móveis como smartphones ou tables. Os apps são
uma realidade, milhares deles estão disponíveis nas
principais lojas. Apenas na play store do Google, em junho
de 2016 estavam disponíveis para download mais de 2 milhões
e duzentos mil apps1. Para mensurar a evolução do mercado de
apps, a app store da Apple contava com cerca de oitocentos
apps em junho de 2008 e em janeiro de 2017 atingiu a marcar
de dois milhões e duzentos mil apps2.
No desenvolvimento mobile alguns atributos de qualidade
devem ser considerados mais detalhadamente na definição da
arquitetura. Três em especial são:
• Usabilidade: nos aplicativos mobile, softwares

complexos devem ser usáveis em telas pequenas e
funcionar apenas com interação touch. Muitas vezes
softwares que executam a mesma função em aplicativos
desktop ou web devem ter versões mobile. O desafio é
acomodar com boa usabilidade as funcionalidades de
outras plataformas na versão mobile.
• Portabilidade: O mesmo app é construído para
diferentes plataformas (Google, Apple, Microsoft,
entre outras) com diferentes sistemas operacionais. A
1 Fonte: https://www.statista.com
2 Fonte: https://www.statista.com
implementação para cada plataforma pode ser feita

utilizando diferentes linguagens de programação.
• Desempenho: Os smartphones têm capacidade de
processamento e armazenamento menores que
computadores deskotp, portanto é importante pensar
quais e como os recursos serão utilizados no projeto
da arquitetura.
Existem algumas táticas para tratar cada um destes

atributos. Para a usabilidade uma tática fundamental é o
suporte a iniciativa do usuário. Nessa tática a usabilidade
é aprimorada, dando ao usuário feedback sobre o que o
sistema está fazendo e permitindo que o usuário execute as
respostas apropriadas. Outra tática importante é separar a
interface do usuário. A separação da interface, utilizando,
por exemplo, o padrão MVC auxilia a:
• Aumentar a coerência semântica e encapsular

responsabilidades.
• Restringir dependências, que minimiza o efeito de
propagação para outro software quando a interface do
usuário é alterada.
Essa tática também pode auxiliar na protipação de

interfaces. Construir um protótipo, ou vários protótipos,
para permitir que os usuários reais experimentem a interface
pode auxiliar muito no desenvolvimento mobile.
A separação da interface do usuário é uma tática que
pode melhorar também a portabilidade. Se for utilizada a
separação, usando o padrão MVC em conjunto a arquitetura
cliente servidor, é possível criar uma aplicação que tenha o
mesmo core com interfaces distintas para diferentes
plataformas, como mostra a Figura 27.
Figura 27: Usando Cliente Servidor e MVC em Aplicações Mobile
Outras táticas que podem ser utilizadas para melhorar a

portabilidade são: reduzir o tamanho dos módulos, aumentar a
coesão e diminuir o acoplamento.
Para tratar o desempenho em sistemas mobile devem-se
utilizar táticas principalmente para gerenciar os recursos,
como utilizar dados em cache.
As aplicações mobile podem também utilizar hardwares
específicos, como GPS, bússola, acelerômetro, sensor de luz,
decibelímetro, entre outros. Caso a aplicação desenvolvida
requeira interação com hardwares específicos, essa análise
deve ser levada em consideração na definição da arquitetura.
Outro aspecto que deve ser considerado em um
desenvolvimento mobile é que muitas vezes os apps são
aplicativos corporativos em um ambiente integrado. Por meio
dela, empresas podem construir aplicativos que se conectam
às plataformas da empresa. Neste caso também é fundamental
utilizar táticas que aumentem a segurança e a
interoperabilidade.
Para exemplificar como podemos pensar no tratamento dos
atributos de qualidade em um sistema mobile, vamos
considerar o exemplo de um aplicativo para encontrar
horários de ônibus. A princípio parece um aplicativo
funcional muito simples: só precisa procurar os itinerários
em um banco de dados.
No entanto, os usuários esperam que um app tenha um alto
nível de usabilidade. Uma alternativa é o sistema proteger o
usuário contra entradas de dados incorretas. Isso é chamado
de "Proteção de Erro do Usuário". Uma maneira de se realizar
esta proteção é utilizar o auto complemento nos campos de
entrada. O complemento automático pode ser feito com base na

localização do usuário, no horário ou em pesquisas
anteriores. Algumas questões que devem ser respondidas para
conseguir implementar o auto complemento são:
• Onde posso obter a lista de pontos de ônibus

disponíveis?
• Onde armazeno esta lista?
• Como posso filtrar os pontos perto da posição real do
usuário?
Com base nestas questões, os requisitos de usabilidade

podem ser reescritos da seguinte forma:
1) Um usuário quer consultar os horários de ônibus

usando um app do sistema de transporte.
2) A interface do app apresentará uma lista predefinida
de estações de partida, levando em consideração a
localização do usuário, o horário e pesquisas
anteriores.
3) A interface do app também mostrará o horário de
partida estimado e uma lista de 3 possíveis pontos de
destino com base em pesquisas anteriores.
Com os requisitos descritos dessa forma, eles podem ser

mensurados além de facilitar as decisões arquiteturais.
Sistemas IoT
As aplicações de IoT podem estar relacionadas a uma
infinidade de atributos de qualidade, dependendo de sua
funcionalidade. Além do mais, uma aplicação IoT pode ser ao
mesmo tempo mobile e web. No entanto, três atributos são
fortemente relacionados a qualquer aplicação IoT:
• Interoperabilidade: Uma aplicação IoT conecta

diferentes dispositivos e sensores. Estes sensores e
dispositivos são de diferentes fabricantes e utilizam
diferentes protocolos.
• Modificabilidade: Outro atributo de extrema
importância é a modificabilidade. Aplicações IoT
normalmente tem que alterar e inserir novas
funcionalidades em aplicações já existentes.
• Reúso: A base de uma aplicação IoT pode ser base para
outras aplicações, que podem utilizar diferentes
sensores e dispositivos da aplicação original.
Além dos três atributos destacados, ainda é necessário

ponderar outros atributos, tais como segurança e desempenho.
Para tratar a modificabilidade, devem-se usar técnicas
para aumentar a coesão e diminuir o acoplamento. Para
diminuir o acoplamento pode utilizar usar o encapsulamento e
wrappers. Um wrapper é uma forma de encapsulamento. É uma
interface para um módulo que transforma os dados ou
informações de controle para o módulo. A distinção entre um
wrapper e encapsulamento é bastante sutil. Encapsulamento
destina-se a ocultar informações, e as transformações podem
ser usadas como uma parte da estratégia de esconder. Um
wrapper destina-se a transformar invocações, e o
encapsulamento é uma parte da estratégia de transformação.
Para o reúso, aplicam-se as mesmas táticas para tratar a
modificabilidade.
Para tratar a interoperabilidade, pode-se utilizar a
técnica de cenários gerais. Vamos considerar o exemplo do
sistema de ônibus de serviu de base para o exemplo do
sistema mobile. Neste novo sistema, queremos um sistema de
transporte inteligente, no qual cada ônibus terá um
subsistema que envia sua localização real para um servidor
central. O servidor calculará então os tempos de chegada
estimados para cada ponto e atualizará os respectivos
displays digitais.
Neste caso, será instanciado o modelo para o caso de uso
específico de comunicação entre os ônibus e o servidor e
analisado o atributo de interoperabilidade, apresentado na
Figura 28.
Figura 28: Cenário Geral para Atributo de Qualidade

Interoperabilidde
A partir da definição geral do cenário, define-se uma

matriz geral, conforme apresentado no Quadro 2.
Quadro 2- Cenário Geral de Interoperabilidade
Fonte Quem ou que O subsistema inicia uma requisição para interagir com o
sistema
Estímulo Envia dados ao sistema Envia dados para trocar informações com o sistema
Artefato O sistema ou parte dele Para o sistema central
Ambiente Sobre certas condições Os sistemas que desejam interoperar são descobertos em
tempo de execução ou conhecidos antes do tempo de
execução.
Resposta O sistema reage as ações Um ou mais dos seguintes:
• O pedido é rejeitado (apropriadamente) e as
entidades (pessoas ou sistemas) apropriadas são
notificadas.
• O pedido é aceito (apropriadamente) e as
informações são trocadas com êxito.
• O pedido é registrado por um ou mais dos sistemas
envolvidos.
Medida Que pode ser medido por Um ou mais dos seguintes:
métricas • Porcentagem de trocas de informações corretamente
processadas
• Porcentagem de trocas de informações corretamente
rejeitadas.
Depois da análise do cenário é necessário pensar como a

arquitetura irá suprir as necessidades definidas. Por
exemplo, como o sistema enviará os dados ao servidor central
e como o servidor central enviará o tempo calculado aos
pontos. Para isso algumas questões são necessárias:
• Quais tecnologias disponíveis para o envio dos
dados?
• Qual o custo das tecnologias?
• Qual a disponibilidade que o sistema apresentará?
A primeira questão está diretamente relacionada às

outras duas questões. Para definir as tecnologias envolvidas
no sistema deve-se pensar o impacto que esta tecnologia
apresenta nos outros critérios. Por exemplo, várias
tecnologias podem ser utilizadas, como comunicação via
satélite ou GPRS (General Packet Radio Service). Mas para
decidir qual destas utilizar pode aplicar a matriz de
qualidade das tecnologias (Tabela 2).
Baseada nas análises feita é possível definir a
arquitetura do sistema, que poderia ser como apresentado na
Figura 29. Uma arquitetura SOA que utiliza GPRS para a
comunicação entre os clientes e o servidor.
Figura 29: Arquitetura Geral para o Sistema de Controle de Tráfego
Além disso, podemos definir uma arquitetura em camadas

específica para aplicação dos subsistemas dos ônibus, como
apresentado na Figura 30.
Figura 30: Arquitetura em Camadas para os Subsistemas
Exercícios
1) Qual a relação entre um caso de uso e um cenário de

atributo de qualidade? Como poderiam ser adicionadas
informações sobre atributos de qualidade em um caso de
uso?
2) Como a escolha da linguagem de programação (um exemplo de

escolha de tecnologia) está relacionada com a arquitetura
em geral, e as decisões de projeto nas outras cinco
categorias (seção - Táticas para Atingir os Atributos de
Qualidade)? Por exemplo, como certas linguagens de
programação permitem ou inibem a escolha de modelos de
coordenação específicos?
3) Considere o exemplo de um caixa eletrônico apresentado

nos capítulos anteriores. Reveja as responsabilidades que
um caixa eletrônico deve suportar e proponha um projeto
inicial para acomodar esse conjunto de responsabilidades.
4) A redundância é frequentemente citada como uma estratégia

chave para alcançar a alta disponibilidade. Pesquise
sobre as táticas para tratar disponibilidade e decida
quais e como essas táticas exploram de alguma forma de
redundância.
5) Escreva um cenário de disponibilidade concreta para o

software de um carro autônomo (hipotética).
6) Qual é a relação entre a interoperabilidade e os outros

atributos de qualidade destacados neste capítulo? Por
exemplo, se dois sistemas falham em trocar informações
adequadamente, isto pode resultar em uma falha de
segurança? Que outros atributos de qualidade parecem
fortemente relacionados (pelo menos potencialmente) à
interoperabilidade?
7) Em um sistema metro, existem dois tipos de máquinas.

Máquinas de bilhetes que aceitam dinheiro, mas não dão
troco. Há um segundo tipo de máquina, que trocam
dinheiro, mas não vendem bilhetes. Em uma estação, na
média há de seis a oito máquinas de bilhete para cada
máquina de troca. Que táticas de modificabilidade
poderiam ser utilizadas neste cenário? Discuta sobre a
disponibilidade neste cenário.
8) Para o sistema de metrô na pergunta anterior, descreva a

forma específica de modificabilidade (usando um cenário
de atributo de qualidade de modificação) que pode ser
utilizado para melhorar o cenário apresentado.
9) Escreva um cenário concreto de usabilidade para um caixa

eletrônico. Seu projeto (da questão 3) teria que ser
modificado para satisfazer esses cenários? Como?
10) Considere a descrição do Sistema de Biblioteca abaixo e

os casos de uso levantados para este sistema.
Considerando isto, faça:
a) Identifique os principais atributos de qualidade do
sistema.
b) Para cada atributo identificado, veja se são
globais ou associados a algum requisito funcional.
c) Defina ao menos dois atributos que sejam essenciais
e descreva cenários concretos para estes atributos.
d) A partir das etapas anteriores, descreva a
arquitetura do sistema (baseado em um ou vários
padrões). Utilize a técnica de matriz de qualidade
para identificar tecnologias, protocolos ou outros
elementos da arquitetura caso seja necessário.
Sistema de Biblioteca
Da entrevista com o responsável da biblioteca de uma universidade resultou a seguinte
descrição para um novo sistema:
A atividade da biblioteca centra-se principalmente no empréstimo de publicações pelos
alunos da universidade. O aluguel é registrado pelos funcionários da biblioteca, que também
consultam diariamente os empréstimos cujos prazos foram ultrapassados. Todo este processo é
efetuado manualmente, sendo muito ineficiente. Espera-se que o novo sistema resolva esta
situação.
Os alunos necessitam de pesquisar os livros existentes na biblioteca. Caso um livro
esteja requisitado é mostrada a data esperada de entrega. Além disso, os alunos podem
solicitar a reserva de livros para uma data específica.
11) Considere a descrição do Sistema de Comércio On-line

abaixo e os casos de uso levantados para este sistema.
sistema.

Sistema de Comércio On-line

Uma loja de comércio on-line, deve permitir que usuários façam compras de produtos por meio de
um site. O usuário pode escolher e gerenciar vários produtos, e após isto ele pode finalizar a
comprar. Na finalização da compra, deve ser verificado o valor de cada item do pedido, assim
como o valor total. Se existirem produtos em promoção, deve ser calculado o valor do desconto.
Ao final o usuário deve inserir seus dados de entrega (ou apenas o CEP) e o sistema calculará o
valor final do compra, inclusa com o frete. Por fim, o usuário seleciona o método de pagamento, e
insere as informações necessárias para finalizar a compra.
12) Considere a descrição do Sistema de Estacionamento

abaixo e os casos de uso levantados para este sistema.
sistema.
Sistema de Estacionamento
Considere os seguintes requisitos para um sistema informatizado para a gestão de um
parque de estacionamento.
a) O controle é efetuado com base na placa do veículo
b) Na entrada do parque existirá um funcionário que introduz as placas no
sistema, ficando de imediato registrado a data e hora de início do
estacionamento. O sistema tem que verificar se a placa já existe.
c) Se a placa não for reconhecida pelo sistema então deverá criar um novo
veículo no sistema.
d) Na saída, um funcionário introduz novamente a placa, sendo que o sistema
calcula o custo do estacionamento.
e) O gestor do parque precisa consultar diariamente uma listagem dos
estacionamentos. Em algumas situações, o gestor poderá desempenhar as
funções de atendimento, no entanto apenas o gestor poderá obter as listagens.
Considere a seguinte informação adicional à descrição apresentada. Esta informação é

um resumo das entrevistas conduzidas na empresa concessionária do parque de
estacionamento.
a) Em cada veículo apenas interessa guardar no sistema a respectiva placa.
b) Um veículo pode efetuar vários estacionamentos no mesmo dia.
c) Os veículos podem ser automóveis ou motos.
d) De início existe uma tarifa base que é aplicada a todos os veículos. Contudo,
para veículos com um elevado número de estacionamentos é possível criar
tarifas específicas. Cada tarifa possui um custo por hora.
e) O estacionamento possui um número de lugares limitado. Os lugares são
caracterizados por um número, piso e um estado. Este estado só pode assumir
os valores de Livre ou Ocupado.
Leitura Complementar
Em BASS et al. (2013) o livro é todo dedicado à arquitetura

de software. Em especial na parte dois (Quality Attributes),
são abordados atributos de qualidade definindo os principais
atributos de qualidade e descrevendo táticas para tratar
cada um destes atributos na arquitetura. Em especial no
Capítulo 13 (Architectural Tactics and Patterns) são
apresentados alguns dos principais padrões arquiteturais.
Neste contexto, Buschmann et al. (1996) também apresenta
diversos padrões no Capítulo 2 (Architectural Patterns).
Buschmann et al. (1996) também apresenta no capítulo 6
(Patterns and Software Architecture) uma relação entre os
padrões e as arquiteturas de software.
Em Hofmeister, Nord e Soni, (2000) são dedicados quatro
capítulos sobre visões da arquitetura. Os Capítulos 4
(Conceptual Architecture View), 5 (Module Architecture
View), 6 (Execution Architecture View) e 7 (Code
Architecture View) apresentam e detalhes de cada uma das
visões da arquitetura do software.
Em Blaha e Rumbaugh (2006), no Capítulo 14 (Projeto de
Sistemas) são abordados temas discutidos neste capítulo,
tais como a Dividindo um Sistema em Subsistemas, Alocação de
Subsistemas e Estilos Arquiteturais Comuns.
Em P0fleeger (2004), no Capítulo 5 (Projetando o
Sistema) há uma apresentação de estilos e estratégias
arquiteturais, assim como discussões acerca de concorrência,
identificação e tratamento de exceções e prevenção e
tolerância a falhas.
Em Pressman e Maxim (2016), o Capítulo 13 (Projeto de
Arquitetura) aborda vários dos temas discutidos neste
capítulo, com destaque para as seções 10.1 (Arquitetura de
Software), 10.3 (Estilos de Arquiteturais), 10.5 (Decisões
sobre a Arquitetura) e 10.6 (Projeto de Arquitetura).
Referências
ALBIN, S.T. The Art of Software Architecture: Design Methods

and Techniques, John Wiley & Sons, 2003.
BACHMANN, F.; BASS, L.; Nord, R. Modifiability Tactics,
CMU/SEI- 2007-TR -002, September 2007.
BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in
Practice, Third edition, Addison Wesley, 2013.
BLAHA, M., RUMBAUGH, J., Modelagem e Projetos Baseados em
Objetos com UML 2, Elsevier, 2006.
BUSCHMANN, F., MEUNIER, R., ROHNERT, H., SOMMERLAD, P.,
STAL, M., Pattern-Oriented Software Architecture: A System
of Patterns, Volume 1, Wiley, 1996.
BUSCHMANN, F.; HENNEY, K.; SCHMIDT, D. Pattern-Oriented
Software Architecture Volume 4: A Pattern Language for
Distributed Computing. Wiley, 2007.
CASTELEYN, S.; DANIEL, F.; DOLOG, P.; MATERA, M. Engineering
Web Applications, Springer, 2009.
CISCO. An Introduction to the Internet of Things (IoT).
Cisco.com. San Francisco, California: Lopez Research.
November 2013. Acessado 13 de Fevereiro de 2013.
COULOURIS, G; et al. Sistemas Distribuídos: Conceitos e
Projeto., 4ª ed, 2007.
FOWLER, M., Patterns of Enterprise Application Architecture,
Addison-Wesley, 2003.
GAMMA, et al. Padrões de Projeto, Ed Bookman.
GARLAN, D.; PERRY, D. Introduction to the Special Issue on
Software Architecture. In: IEEE Transactions on Software
Engineering, v. 21, April, 1995.
GORTON, I. Essential Software Architecture, Springer, 2006.
HOFMEISTER, C.; NORD, R.; SONI, D. Software Architecture.
Reading, MA: Addison-Wesley Professional. 2000.
ISO/IEC 25010. International Organization for
Standardization. "ISO/IEC 25010:2011 Systems and software
engineering Systems and software Quality Requirements and
Evaluation (SQuaRE) System and software quality models."
LV, Q.; Cao, P.; Cohen, E.; Li, K.; Shenker, S. Search and
Replication in Unstructured Peer-to-Peer Networks”, 16 ACM
International Conference on Supercomputing(ICS'02), Junho de
2002.
MCCONNELL, S. Code Complete. Microsoft Press, Segunda

Edição, Junho 2004.
MENDES, A. Arquitetura de Software: desenvolvimento
orientado para arquitetura, Editora Campus, 2002.
P2P Architect Project. Ensuring dependability of P2P
applications at architectural level”, Deliverable D1, Abril
de 2002. Disponível em :
http://www.atc.gr/p2p_architect/results/
0101F05_P2P Survey.pdf.
PERRY, D.; WOLF, A. Foundations for the study of software
architecture. SIGSOFT Software Engineering Notes,
17(4):408211;52, October 1992.
PRESSMAN, R., MAXIM, B. Engenharia de Software, 8ª edição,
AMGH, 8ª edição, 2016.
RUP. Rational Unified Process Best Practices for Software
Development Teams. Rational Software White Paper TP026B.
Disponível em:
https://www.ibm.com/developerworks/rational/library/content/
03July/1000/1251/1251_bestpractices_TP026B.pdf
SHAW, M., GARLAN, D., Software Architecture: Perspectives on
an Emerging Discipline, Prentice Hall, 1996.

Arquitetura de Software: Padrões, Qualidade e Desenvolvimento

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Arquitetura de Software: Padrões, Qualidade e Desenvolvimento

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE ESTADUAL DO NORTE DO PARANÁ

CENTRO DE CIÊNCIAS TECNOLÓGICAS

A complexidade dos softwares vem aumentando ao longo dos

• A abstração facilita a visualização e o entendimento

A arquitetura de software é uma etapa fundamental nos

Embora tanto táticas quanto padrões sejam usados

Figura 1: Padrões e Táticas Arquiteturais

Por fim, este capítulo trata do projeto da arquitetura

O conceito de arquitetura de software surgiu nos anos 60,

relutar em tentar utilizá-la novamente, mesmo que se

• Abstração serve como base para criar um entendimento

Portanto, o uso da arquitetura de software, se bem

Visões da Arquitetura de Software

• Conceitual: descreve o sistema em termos dos

A Figura 2 mostra como estas visões interagem entre elas

Figura 2: Visões Arquiteturais

A visão conceitual é a mais próxima ao domínio da

individualmente cada palavra do texto (tokenizador) que

Figura 3: Exemplo de Visão Conceitual

Na visão de módulo os componentes e conectores são

Figura 4: Visão de Módulo por meio de Substistema

Os subsistemas podem ser especificados em componentes

de pagamento, mas que precisa de três componentes internos

Figura 5: Visão de Módulo por meio de Componentes

A visão de execução descreve a estrutura do sistema em

Figura 6: Visão de Execução

A visão de código descreve como o software que

Quando se inicia o projeto de um software espera-se que este

1. Requisitos funcionais: indicam o que o sistema deve

escolhas são do arquiteto de software, no entanto

Os atributos de qualidade são fundamentais na definição

Táticas para Atingir os Atributos de Qualidade

qualidade necessários. Essas técnicas são chamadas de

determinar como os itens de dados são criados,

exemplos entre outros) e decidir se isso é

Além disso, uma técnica comum para caracterizar

1) O primeiro elemento, Fonte, identifica quem origina o

Figura 7: Cenário Geral para Atributo de Qualidade

Principais Tipos de Atributos de Qualidade

Figura 8: Taxonomia da Norma de Qualidade ISO/IEC FCD 25010

Neste material são destacadas apenas algumas das principais

• Latência. O tempo entre a chegada do estímulo e a

• Prazos de processamento. No sistema bancário, poderia

Considerando todos os aspectos definidos acima, podemos

Figura 9: Exemplo de Cenário Geral de Desempenho

A partir de cenários gerais, pode-se pensar em como

disponibilidade são categorizadas em detectar falhas,

Muito das técnicas de desenvolvimento de software são

arquiteturais de outras literaturas como padrões

• Contexto: é uma situação recorrente, comum no mundo

Sistemas complexos em geral utilizam diversos padrões ao

nível e o comportamento de sistemas de software, assim como

Figura 10: Ideia Geral de Padrões

De acordo com McConnell (2004), é possível citar os

• Padrões reduzem a complexidade da solução ao prover

Os padrões arquiteturais contêm os principais

Figura 11: Diferença entre Padrões Arquiteturais e Padrões de

Os tipos de componentes em padrões de projeto são

No projeto de um carro, o padrão arquitetural define se

Figura 12: Visão das diferença entre os tipos de padrões

Os padrões arquiteturais são definidos principalmente

Física. Na arquitetura TC/IP as camadas inferiores provêm os

Figura 13: Arquitetura em Camadas