ARQUITETURAS E PADRÕES DE SOFTWARE V

Prévia do material em texto

Arquiteturas e Padrões 
de Software 
Responsável pelo Conteúdo:
 Prof. Me. Wilson Vendramel 
Revisão Textual:
Prof.ª M.ª Sandra Regina Fonseca Moreira 
Projeto de Arquitetura de Software
Projeto de Arquitetura de Software
 
 
• Entender as etapas do desenvolvimento de sistemas de software centrado na arquitetura.
OBJETIVO DE APRENDIZADO 
• Atributos de Qualidade;
• Componentes Arquiteturais;
• Conectores Arquiteturais;
• Configurações Arquiteturais;
• Representação da Arquitetura de Software com Notações UML;
• Projeto Arquitetural.
UNIDADE Projeto de Arquitetura de Software 
Atributos de Qualidade
As Unidades anteriores descreveram padrões de software como uma prática comum 
e apropriada para o reuso e construção de produtos de software de qualidade. Vale 
lembrar que esses padrões são aplicáveis ao longo do processo de desenvolvimento 
de software. Enquanto em uma unidade se enfatizou os padrões de projeto (design 
patterns), em outra se manteve o foco nos padrões de arquitetura (architectural patterns). 
Esta unidade já se concentra no desenvolvimento de sistema de software centrado na 
arquitetura, destacando o projeto baseado em padrões.
Já que os padrões foram recordados, qual a relação do projeto arquitetural com pa-
drões de software?
O projeto de arquitetura estabelece as relações entre os principais elementos estrutu-
rais do software, os estilos arquiteturais e padrões de projeto que podem ser utilizados 
para satisfazer os requisitos definidos para o produto de software e as restrições que 
influenciam o modo como a arquitetura pode ser implementada (SHAW, 1996 apud 
PRESSMAN; MAXIM, 2016, p. 226).
O projeto arquitetural é uma das atividades de projeto de software que tem o obje-
tivo de construir o alicerce de uma arquitetura com base nos requisitos exigidos para 
o sistema, identificando os componentes arquiteturais e seus relacionamentos, ligados 
por conectores arquiteturais. Um conjunto de componentes e conectores comunicantes 
representam uma configuração arquitetural. Além da extração de uma arquitetura, o 
projeto arquitetural também deve levar em consideração atributos que buscam garantir 
a qualidade do sistema de software, denominados atributos de qualidade. Resumindo, é 
possível perceber que o projeto de arquitetura de software não é uma atividade trivial.
Importante!
Segundo Charles A. R. Hoare, “Há duas maneiras de construir um projeto de software. 
Uma delas é fazê-lo tão simples que, obviamente, não existirão deficiências; a outra 
maneira é fazê-lo tão complicado que não há nenhuma deficiência óbvia. O primeiro 
método é bem mais difícil” (PRESSMAN; MAXIM, 2016, p. 227).
Se você considerar atributos de qualidade desejados para um produto de software como 
disponibilidade, modificabilidade, desempenho, segurança, testabilidade, usabilidade, qual 
seria o atributo mais importante no seu entendimento?
Na verdade, todos esses atributos de qualidade, também vistos como requisitos não 
funcionais, são importantes para um produto de software. Esses atributos de qualidade 
foram extraídos da classificação realizada por Bass, Clements e Kazman (2003), visto 
que essa classificação evidencia os requisitos de qualidade que influenciam o projeto 
(design) arquitetural de software, desse modo, são elencados os seguintes atributos: dis-
ponibilidade (availability), modificabilidade (modifiability), desempenho (performance), 
8
9
segurança (security), testabilidade (testability) e usabilidade (usability). É claro que, de-
pendendo do objetivo do software em relação ao domínio de negócio, certos atributos 
de qualidade precisam ser priorizados, enquanto outros devem ficar em segundo plano. 
Certo, mas o que vem a ser atributos de qualidade?
Os atributos de qualidade descrevem capacidades, serviços e comportamentos do 
sistema de software. Esses atributos indicam o quão bem o software satisfaz às neces-
sidades dos stakeholders, devendo ser mensuráveis e testáveis. Tais atributos nunca po-
dem ser atingidos de forma isolada, ressaltando que alguns podem impactar outros. Um 
exemplo claro disso é que quase todos os atributos de qualidade afetam negativamente o 
desempenho do sistema, portanto, para atingir os atributos de qualidade, é importante 
tomar decisões arquiteturais que implicam em vantagens e desvantagens (trade-offs), 
causando consequências para o projeto (BASS; CLEMENTS; KAZMAN, 2003).
De acordo com a classificação de Bass, Clements e Kazman (2003), os atributos de 
qualidade são:
• Disponibilidade: esse atributo se refere à capacidade de um software estar pronto para 
executar funções quando requisitado em um dado momento e sob condições específi-
cas. O atributo de disponibilidade também pode ser entendido como confiabilidade, ou 
seja, a habilidade do sistema de se recuperar diante de falhas em um período de tempo 
pré-estabelecido, sendo assim, o atributo de disponibilidade tem o propósito de mitigar 
falhas para diminuir o tempo de interrupções de funcionamento de um sistema;
• Modificabilidade: esse atributo corresponde à capacidade de um software absor-
ver mudanças com o mínimo de impacto, sabendo que mudanças são inevitáveis já 
que é necessário realizar manutenções no sistema, seja adicionando novas funcio-
nalidades ou melhorando as existentes. Alguns estudos revelam que o maior custo 
de um software acontece após esse ser entregue para o cliente, devido a isso, é 
importante projetar sistemas passíveis de adequação a tais mudanças. Ao tratar de 
mudanças, é importante saber o que pode mudar, qual a probabilidade de a mu-
dança ocorrer, quem é o responsável pela modificação e o custo dessa mudança;
• Desempenho: esse atributo se refere à capacidade do sistema cumprir requisito de 
tempo. Isso significa dizer que, quando ocorrer um evento (mensagens, requisições 
etc.), partindo de um usuário ou outros sistemas, o sistema deve responder dentro 
do tempo. Historicamente, o desempenho é um atributo importante na arquitetura 
de sistemas e, frequentemente, compromete outros atributos de qualidade. Ao lidar 
com eventos é importante mensurar o tempo que o sistema leva para processar 
um evento (latência), a quantidade de eventos que um sistema consegue processar 
em um período de tempo (throughput) e a quantidade de eventos não processados 
quando o sistema está ocupado e rejeita o processamento desses eventos;
• Segurança: esse atributo e corresponde à capacidade de um sistema proteger os 
dados e resistir a acessos não autorizados, garantindo também acesso àqueles que 
tem permissão para acessá-lo. Esse atributo deve considerar características como 
proteção de dados ou serviços de acessos não autorizados (confidencialidade), proteção 
de dados ou serviços de alterações não autorizadas (integridade), garantia de que 
as partes de uma transação são de quem dizem ser (autenticação) e permissão aos 
usuários para realizar uma tarefa (autorização);
9
UNIDADE Projeto de Arquitetura de Software 
• Testabilidade: esse atributo se refere à capacidade do sistema de facilmente de-
monstrar suas falhas por meio de testes. Para um sistema ser testável apropriada-
mente, deve ser possível controlar as entradas, o estado interno e a saída dos com-
ponentes de forma a validar seus comportamentos. Uma medida importante para 
entender o quanto o sistema é testável é quão efetivo são os testes para descobrir 
novas falhas e quanto tempo leva para realizá-los;
• Usabilidade: esse atributo se refere a quão fácil é utilizar uma funcionalidade 
desejada no sistema ou o quanto de suporte esse sistema disponibiliza. O atribu-
to de usabilidade tem se demonstrado uma maneira barata e fácil de melhorar 
a qualidade de um sistema, focando o aprendizado das funcionalidades do sis-
tema, o uso efetivo do sistema, a redução do impacto ao surgimento de erros, 
a adaptação do sistema às necessidades do usuário e o aumento de confiança e 
satisfação do usuário.
Além da classificação apresentada nesta seção, há outras classificaçõesde atributos 
de qualidade, podendo destacar a norma ISO/IEC 9126 e o modelo FURPS.
A norma ISO/IEC 9126 enfatiza a qualidade do produto de software, propondo atributos de 
qualidade com o intuito de padronizar a avaliação da qualidade de software. Para maiores 
detalhes, você pode explorar essa norma a partir do link: https://bit.ly/3a4bqy5
O modelo FURPS é um acrónimo que representa um modelo para classificação de atributos 
de qualidade de software. Para maiores detalhes, você pode explorar esse modelo a partir 
do link: https://bit.ly/3aUSuRI
Uma vez abordados os atributos de qualidade, as seções 2, 3 e 4 descrevem compo-
nentes, conectores e configurações arquiteturais, respectivamente.
Componentes Arquiteturais
Os componentes arquiteturais são módulos que compõem o software e que podem 
ser substituídos. Além disso, eles devem encapsular a implementação, revelando apenas 
as interfaces de comunicação. Na perspectiva de arquitetura de software, os compo-
nentes são elementos funcionais que possuem o papel de ajudar a atingir os objetivos 
e os requisitos do sistema a ser construído, sendo capazes de se comunicar com outros 
componentes e entidades que podem existir dentro ou fora das fronteiras do sistema de 
software (PRESSMAN; MAXIM, 2016). 
A Figura 1 ilustra exemplos de componentes arquiteturais e as camadas de software 
onde eles podem ser alocados, tomando como base o padrão arquitetural em camadas.
10
11
<<component>>
InterfaceDeUsuario
<<component>>
Controller
<<component>>
Model
<<component>>
Persistencia Infraestrutura
Domínio
Aplicação
Apresentação
Componentes
Figura 1 – Exemplos de componentes arquiteturais
Ainda sobre a Figura 1, a responsabilidade de cada um dos componentes exemplifi-
cados é:
• InterfaceDeUsuario: a responsabilidade deste componente é apresentar uma in-
terface amigável para o usuário final, desse modo, este componente é alocado na 
camada de apresentação;
• Controller: a responsabilidade deste componente é ter os objetos controladores do 
sistema que, por sua vez, realizam a mediação entre a entrada das requisições e a exe-
cução da lógica de negócio, sendo assim, é um componente da camada de aplicação;
• Model: a responsabilidade deste componente é conter os objetos modelos do sis-
tema com suas respectivas regras de negócio, desse modo, é um componente da 
camada de domínio;
• Persistencia: a responsabilidade deste componente é realizar a persistência dos da-
dos do sistema, fazendo a comunicação com o sistema operacional e/ou um banco 
de dados externo, sendo assim, é um componente da camada de infraestrutura.
Conectores Arquiteturais
O s conectores arquiteturais são elementos, vistos também como componentes mais 
simples, que realizam a comunicação entre os componentes por meio de interfaces 
estabelecidas, possibilitando assim que esses componentes realizem as interações devi-
damente (BASS; CLEMENTS; KAZMAN, 2003).
Como e xemplos de conectores podem ser listados: chamadas de métodos (Call/
Return), Remote Name System (RMI), Remote Procedure Call (RPC), Hyper-Text 
Transfer Protocol (HTTP), Open Database Connectivity (ODBC), entre outros.
11
UNIDADE Projeto de Arquitetura de Software 
A Figura 2 mostra exemplos de conectores arquiteturais sendo endereçados em suas 
respectivas camadas de software, tendo como base o padrão de arquitetura em camadas.
<<connector>>
HTTP
<<connector>>
Call-Return
<<connector>>
Call-Return
<<connector>>
ODBC Infraestrutura
Domínio
Aplicação
Apresentação
Conectores
Figura 2 – Exemplos de conectores arquiteturais
Ainda com base na Figura 2, o conector HTTP pode ser utilizado para a comuni-
cação entre a interface gráfica de usuário (camada de apresentação) com o restante da 
aplicação. Já o conector ODBC é utilizado para se comunicar com o banco de dados, 
desse modo, se encontra na camada de infraestrutura.
Configurações Arquiteturais
A atividade de projeto de arquitetura produz o artefato de arquitetura de sistema (vide 
Figura 4 da unidade de título “Contexto e Visões de Arquitetura”) cuja intenção é repre-
sentar a estrutura global do software em um alto nível de abstração, expondo assim os 
componentes identificados, inclusive seus relacionamentos e a maneira como eles são dis-
tribuídos. Com base nisso, é importante expressar a arquitetura de software em uma con-
figuração arquitetural formada basicamente por componentes e conectores arquiteturais.
As configurações arquiteturais representam um conjunto de componentes e conecto-
res inter-relacionados. A Figura 3 apresenta um exemplo de uma configuração arquitetu-
ral ilustrando componentes e conectores arquiteturais, seguindo um estilo de arquitetura 
em camadas, especificamente quatro camadas. Dessa maneira, cada componente e 
cada conector é alocado em uma determinada camada.
12
13
<<connector>>
HTTP
<<connector>>
Call-Return
<<connector>>
Call-Return
<<connector>>
ODBC Infraestrutura
Domínio
Aplicação
Apresentação
Conectores
<<component>>
InterfaceDeUsuario
<<component>>
Controller
<<component>>
Model
<<component>>
Persistencia
Domínio
Componentes
Banco 
de dados
Figura 3 – Exemplo de uma confi guração arquitetural
Ainda sobre a Figura 3, é importante ressaltar que pode haver mais de um compo-
nente e/ou conector por camada de software.
Em síntese
Enquanto os componentes arquiteturais a tendem aos requisitos funcionais exigidos 
para o software, o s conectores arquiteturais contemplam os requisitos não funcionais 
(atributos de qualidade), assim como as restrições requeridas para o software. Ambos 
formam a configuração arquitetural do sistema de software a ser desenvolvido.
A UML, abordada em Unidade anterior, é uma linguagem que também permite mo-
delar representações (visões) arquiteturais de software. A próxima seção elenca alguns 
diagramas UML que podem ser adotados para representar visualmente elementos arqui-
teturais de software.
Representação da Arquitetura 
de Software com Notações UML
A Unidade anterior apresentou que a arquitetura de um sistema de informação pode 
ser estabelecida em dois níveis de arquitetura: arquitetura lógica e arquitetura física. 
Esses níveis arquiteturais estão relacionados à decomposição do sistema de software 
no contexto arquitetural. A arquitetura lógica estabelece como o software deve ser de-
composto pelos diversos subsistemas e como suas classes são organizadas nesses diver-
sos subsistemas identificados, já a arquitetura física define como os subsistemas devem 
13
UNIDADE Projeto de Arquitetura de Software 
ser organizados fisicamente em nós de processamento quando esse produto de software 
for implantado (BEZERRA, 2015).
Tanto a arquitetura lógica quanto a física podem ser representadas visualmente com 
notações UML. Sob o aspecto estático e estrutural, a arquitetura lógica pode ser retra-
tada por meio do diagrama de classes e do diagrama de pacotes. Já a arquitetura física 
pode ser representada através dos diagramas de implementação, ou seja, diagrama de 
componentes e de implantação.
A UML possui dois grupos de diagramas, sendo um para representar os elementos 
estáticos e estruturais e outro para representar os elementos dinâmicos e comportamen-
tais do software. A Figura 4 exibe os diagramas definidos pela UML. Observe que os 
diagramas mencionados anteriormente são diagramas estruturais.
Introduzido pela UML 2.0
Introduzido pela UML 2.0
Introduzido pela UML 2.0
Diagramas da
UML
Diagramas 
Estruturais
Diagramas 
Comportamentais
Diagrama
de Objetos Diagrama de
Classes
Diagramas de
Casos de UsoDiagrama de
Pacotes
Diagrama de
Atividades
Diagramas de
Interação
Diagrama de
Transições de EstadosDiagrama de
Estrutura Composta
Diagrama de
Componentes
Diagrama de
Implantação
Diagramas de
Implementação
Diagrama de
Sequência Diagrama de
Temporização
Diagrama de
Colaboração
Diagramas de Visão
Geral da Interação
Figura 4 – Diagramas definidos pela UML
Fonte: Adaptado de BEZERRA, 2015, p. 18
Dentre os diagramas listados na Figura4, esta apresenta os diagramas comumente utili-
zados para representar a estrutura das arquiteturas lógica e física. Desse modo, temos:
a) Diagrama de Pacotes;
b) Diagrama de Componentes;
c) Diagrama de Implantação.
O diagrama de pacotes é um esquema lógico interessante para a representação do 
software. Esse diagrama auxilia na compreensão das partes lógicas do software, inclusi-
ve suas dependências (FOWLER, 2005). Um diagrama de pacotes oferece uma maneira 
de agrupamento de elementos, podendo ser casos de uso, classes, outros pacotes etc. 
(LARMAN, 2007).
A arquitetura lógica é uma organização em larga escala das classes em pacotes, sub-
sistemas e camadas, podendo ser ilustrada por meio do diagrama de pacotes (LARMAN, 
2007). Na arquitetura lógica, os subsistemas podem ser representados como pacotes, 
sendo assim, é possível entender que um pacote representa logicamente um subsistema 
(BEZERRA, 2015).
14
15
Importante!
Uma camada é um agrupamento de granularidade muito grossa de classes, pacotes ou 
subsistemas que tem responsabilidade coesiva sobre um tópico importante do sistema 
(LARMAN, 2007, p. 221).
A Figura 5 exibe um exemplo de uma arquitetura lógica em camadas representada 
por meio do diagrama de pacotes. Observe que são apresentadas três camadas lógicas 
e as dependências existentes entre elas.
Impostos
Swing Web
UI
Domínio
Vendas Pagamentos
Serviços Técnicos
Persistência Registro MotorDeRegras
Não são as
bibliotecas Swing
de Java, mas nossas
classes de IGU baseadas
em Swing.
Figura 5 – Camadas mostradas com notação de diagrama de pacotes UML
Fonte: Adaptado de LARMAN, 2007, p. 221
Ainda sobre a Figura 5, cabe destacar que a notação visual de pacote definida pela UML 
é usada para representar camadas, subsistemas, pacotes, entre outros elementos. Embora 
a notação visual UML seja a mesma para subsistemas e camadas, cada elemento tem sua 
aplicabilidade. Enquanto um subsistema agrupa classes, a camada agrupa subsistemas.
Importante!
 Um pacote UML é um conceito mais geral do que simplesmente um pacote Java ou es-
paço de nomes .NET, assim um pacote UML pode representar esses e – muitos outros 
(LARMAN, 2007, p. 223).
Para maiores detalhes sobre arquitetura lógica e diagrama de pacotes UML, você pode ex-
plorar o capítulo 13 do livro “Utilizando UML e padrões: uma introdução à análise e ao 
projeto orientados a objetos e ao desenvolvimento iterativo”, de Craig Larman.
Disponível em: https://bit.ly/2LACmMt
Dando sequência aos diagramas UML, o próximo a ser apresentado é o diagrama 
de componentes.
15
UNIDADE Projeto de Arquitetura de Software 
Na arquitetura física, os subsistemas podem ser representados como componentes, 
sendo assim, é possível entender que um componente representa fisicamente um subsis-
tema (BEZERRA, 2015).
Um componente representa uma parte modular de um sistema que en-
capsula seu conteúdo e cuja manifestação é substituível dentro de seu 
ambiente. Um componente define seu comportamento em termos de in-
terfaces fornecidas e requeridas. Como tal, um componente serve como 
um tipo, cuja conformidade é definida por essas interfaces fornecidas e 
requeridas. (OMG, 2003b apud LARMAN, 2007, p. 618)
Os componentes UML retratam visualmente uma perspectiva de projeto, não existin-
do de forma concreta no software, porém são mapeados para elementos físicos concre-
tos, geralmente arquivos, como .jar, .war e .exe (LARMAN, 2007).
A Figura 6 mostra exemplos de componentes representados com notações UML. 
Vale lembrar que em Unidade anterior já se apresentou outro exemplo de diagrama de 
componentes (vide Figura 7 da unidade de título “Projeto Orientado a Objetos a Diagra-
mas Arquiteturais UML”).
SQL
JMS
<<componente>>
BD
<<sistema>>
ProxGer
ServiçoDe
Mensagem
notação
alternativa para
um componente
notação alternativa
para indicar o uso ou a
solicitação de uma interface
Figura 6 – Componentes UML
Fonte: Adaptado de LARMAN, 2007, p. 619
Por fim, o diagrama de implantação exibe a alocação de artefatos concretos, como arquivos 
executáveis, aos nós de processamento, representando assim a implantação dos elementos 
de software à arquitetura física como também a comunicação entre esses elementos físicos, 
comumente distribuídos em uma rede (LARMAN, 2007). Em poucas palavras, o diagrama 
de implantação mostra o esquema (layout) físico do software (FOWLER, 2005).
Esse diagrama tem dois elementos fundamentais: os nós de processamento, que re-
presentam os recursos computacionais, e suas conexões, que representam os meca-
nismos de comunicação (BEZERRA, 2015). A Figura 7 mostra um exemplo de um 
diagrama de implantação.
: Impressora
cliente :
Browser
Serviço da
Apliação
Banco de Dados
Corporativo
<<HTTP>> <<ODBC>>
<<LAN>>
Figura 7 – Exemplo de diagrama de implantação
Fonte: Adaptado de BEZERRA, 2015, p. 359
16
17
Ainda sobre a Figura 7, os componentes poderiam ser representados dentro de seus 
respectivos nós de processamento. Segundo Bezerra (2015), esse diagrama apresenta 
um mapeamento entre os componentes de software e a infraestrutura (hardware) dispo-
nível para implantação do sistema de software.
Para maiores detalhes sobre diagramas UML de Implantação e de Componentes, você pode 
explorar o capítulo 37 do livro “Utilizando UML e padrões: uma introdução à análise e 
ao projeto orientados a objetos e ao desenvolvimento iterativo”, de Craig Larman.
Disponível em: https://bit.ly/2OoXWob
Para maiores detalhes sobre arquitetura lógica e arquitetura física, você pode explorar o 
capítulo 11 do livro “Princípios de análise e projeto de sistemas com UML”, de Eduardo 
Bezerra, disponível em: https://bit.ly/3p5dvhl
Vale destacar que os diagramas apresentados nesta seção costumam ser utilizados para 
representar arquiteturas de software, porém, eles não são exclusivos para tal finalidade. 
Vale recordar que uma arquitetura de software pode ser representada a partir de relações 
entre as visões do modelo 4+1 e os diagramas UML (vide Tabela 1 da unidade de título 
“Projeto Orientado a Objetos a Diagramas Arquiteturais UML”). No âmbito desta seção, o 
diagrama de pacotes retrataria a visão lógica e de desenvolvimento; o diagrama de com-
ponentes representaria a visão de desenvolvimento; por fim, o diagrama de implantação 
reproduziria a visão física. 
Uma especificação detalhada sobre UML , disponível em: https://bit.ly/3cXpKdC
Projeto Arquitetural
Como visto em Unidade anterior, o propósito do projeto (design) de software é apli-
car um conjunto de princípios, conceitos e práticas que possibilitem o desenvolvimento 
de sistemas de software de qualidade. 
O processo de projeto (design) de software e seu conjunto de atividades visa construir 
um modelo de projeto de software que implemente de forma correta todos os requisitos 
de negócio e garanta satisfação para a comunidade usuária. Diante disso, os arquitetos de 
software devem examinar de maneira completa diversas alternativas de projeto, visando 
transformá-las em uma solução que melhor atenda às necessidades dos stakeholders do 
projeto em questão (PRESSMAN; MAXIM, 2016).
O processo de projeto, também abordado anteriormente, começa a partir de 
uma visão macro do software, que vai se deslocando para uma visão mais específica 
(abordagem top-down), descrevendo os detalhes para implementar o sistema de software. 
Esse processo inicia com foco na arquitetura, definindo subsistemas e suas formas de 
comunicação, identificando componentes e os descrevendo de modo detalhado. O 
modelo de projeto contempla quatro elementos diferentes que evoluem ao longo do 
17
UNIDADE Projeto de Arquitetura de Software 
desenvolvimento, permitindo uma visão mais completa e consistente do projeto a ser 
desenvolvido. Esses quatro elementos são:
• O elemento arquitetural: esse elemento tem como base as informações extraí-
das do domínio de negócio e de catálogos disponíveis para estilos e padrões de 
arquitetura, visando produzir uma representação estrutural completa do software,incluindo seus subsistemas e componentes;
• Os elementos de projeto de interfaces: esses elementos modelam interfaces in-
ternas e externas, como também as interfaces de usuário;
• Os elementos de componentes: esses elementos estabelecem cada um dos módu-
los (componentes) que devem completar a arquitetura do software;
• Os elementos de implantação (deployment): esses elementos alocam a arquite-
tura com seus componentes e respectivas interfaces na disposição física que deve 
hospedar, possivelmente de forma distribuída, o produto de software (PRESSMAN; 
MAXIM, 2016).
Importante!
Há três partes para o elemento de projeto de interfaces: a interface do usuário, inter-
faces com os sistemas externos à aplicação e interfaces com componentes internos à 
aplicação (PRESSMAN; MAXIM, 2016, p. 245).
Como o processo de projeto enfatiza a arquitetura do software como alicerce para 
implementar um produto de software de qualidade, o projeto de arquitetura torna-se 
uma atividade essencial e, por consequência, de suma importância para a construção do 
software, inclusive há processos de desenvolvimento de software centrados na arquitetura.
Por exemplo, o Processo Unificado (PU), contemplado nas primeiras Unidades, é 
baseado em três princípios: a) é dirigido a casos de uso; b) é centrado na arquitetura e; 
c) é iterativo e incremental.
No que tange ao princípio ‘centrado na arquitetura’, o processo de desenvolvimento 
direciona a construção de uma arquitetura de software que possibilita a implementação 
dos requisitos. Essa arquitetura tem como base a identificação de uma estrutura que é 
construída de forma iterativa a partir do modelo de análise (ou modelo de requisitos) 
(WAZLAWICK, 2015).
O PU especifica que a arquitetura do software deve ser uma das principais preocupa-
ções do time de desenvolvimento, pois a arquitetura, junto com os casos de uso, orienta 
a exploração de todos os elementos do software. A arquitetura permite compartilhar 
uma visão comum do projeto entre todos os membros do time, desse modo, guia a 
construção de um sistema de software apropriadamente robusto, flexível, expansível e 
de custo viável, com base nessa arquitetura compartilhada. No contexto do PU, a arqui-
tetura é especificada em termos de visões de seis modelos básicos, sendo eles: a) modelo 
de casos de uso; b) modelo de análise; c) modelo de projeto (design); d) modelo de im-
plementação; e) modelo de teste e; f) modelo de implantação (deployment). Essas visões 
retratam os elementos arquiteturais e significativos que, de forma conjunta, representam 
a arquitetura do software (SCOTT, 2003).
18
19
No caso do PU, ainda segundo Scott (2003), o desenvolvimento centrado na arquite-
tura tem sua importância por causa das seguintes razões:
• Compreensão da visão global do sistema;
• Organização do esforço de desenvolvimento;
• Ampliação das possibilidades de reuso;
• Facilidade de evolução do sistema;
• Dirigido a casos de uso.
Diante da relevância da arquitetura para o desenvolvimento de sistemas de software 
de qualidade, em que consiste o projeto arquitetural?
O projeto arquitetural (design arquitetural) é uma atividade em que o arquiteto deve 
tomar as mais diversas decisões, principalmente as de aspecto estrutural do software. 
Nesse caso, deve haver representações (visões) coerentes e bem planejadas do software, 
concentrando as interdependências das partes no mais alto nível lógico e de abstração 
(PRESSMAN; MAXIM, 2016).
Os padrões de software influenciam o projeto arquitetural e, por consequência, o 
projeto de software?
Os arquitetos experientes possuem uma habilidade única de visualizar padrões para 
caracterizar um problema e solucioná-lo. Nesse caso, por meio do projeto arquitetural 
devemos ser capazes de identificar oportunidades de aplicar padrões existentes, ao invés 
de criar novos padrões e reinventar a roda. Um projeto baseado em padrões implica 
em novas maneiras de pensar, sendo necessário entender o contexto de uso do sistema 
e os problemas a serem solucionados. Tudo isso influencia na solução proposta para o 
produto de software em estudo (PRESSMAN ; MAXIM, 2016).
Como um projeto baseado em padrões pode ser aplicado?
O projeto baseado em padrões é ilustrado na Figura 8. O arquiteto, com base no 
modelo de requisitos (ou modelo de análise), deve ter condições de extrair o conjunto de 
problemas, o contexto e o sistema de forças que rege o domínio. Além disso, ele também 
precisa considerar os atributos de qualidade e os conceitos de projeto (design). Os atri-
butos de qualidade, por sua vez, definem uma forma de avaliar a qualidade do software,
mas pouco faz para ajudar a obtê-la, portanto, deve-se aplicar técnicas que transformem 
a representação abstrata do modelo de requisitos em uma representação mais concreta, 
especificamente o modelo de projeto. Para tal, métodos e ferramentas voltadas para o 
projeto arquitetural, de componentes e de interfaces podem ser adotadas, porém, isso 
deve ser utilizado quando um problema, contexto ou sistema de forças ainda não foi 
resolvido, caso contrário, se já houver uma solução, utilize-a. Dessa forma, você está 
aplicando uma abordagem baseada em padrões (PRESSMAN; MAXIM, 2016).
Importante!
 Forças são as características do problema e os atributos de uma solução que restringem 
a maneira como o projeto pode ser desenvolvido (PRESSMAN; MAXIM, 2016, p. 348).
19
UNIDADE Projeto de Arquitetura de Software 
Modelo de
Requisitos
Considerar
conceitos
de projeto
Extrair contexto
das forças e 
do problema
Considerar atributos
de qualidade
do projeto
Iniciar tarefas de
projeto baseado 
em padrões
Aplicar outros
métodos e notações
de projeto
Modelo de projeto
sim não
Tratado pelo
padrão?
O projeto é iniciado
Figura 8 – Contexto do projeto baseado em padrões
Fonte: Adaptado de PRESSMAN; MAXIM, 2016, p. 355
Há algum caminho que permite ao arquiteto o pensamento em termos de padrões?
Há uma abordagem para o arquiteto pensar em padrões (SHALLOWAY; TROTT, 
2005 apud PRESSMAN; MAXIM, 2016, p. 355), constituída por seis passos: 
1. Entenda o contexto em que o sistema será implementado e utilizado a partir 
do modelo de requisitos;
2. Examine o contexto e extraia os padrões existentes nesse nível de abstração;
3. Comece seu projeto com os padrões que definam um contexto ou a estrutura 
básica para dar continuidade a ele;
4. Procure por padrões com níveis de abstração mais baixos que possam contri-
buir para a solução do projeto;
5. Repita os passos de 1 a 4 visando completar a estrutura do projeto;
6. Refine o projeto, adequando os padrões às especificidades do software a 
ser  construído.
Como mencionado em Unidade anterior, uma das metas do projeto (design) de 
software é constituir um quadro arquitetural que represente a organização do software 
para guiar as atividades mais detalhadas de projeto, incluindo um conjunto de padrões 
de arquitetura que propicie o reuso de conceitos em nível de projeto.
20
21
No decorrer do projeto baseado em padrões pode ser complicado organizar e classifi-
car os padrões de software a serem utilizados para concretizar o modelo de projeto. Uma 
alternativa é criar uma tabela para organizar esses padrões, como mostra a Tabela 1. 
Essa tabela pode ser elaborada de modo a organizar os problemas em quatro tópicos: a) 
dados/conteúdo; b) interface do usuário; c) componentes e; d) arquitetura. 
Nessa tabela há também quatro tipos de padrões: a) banco de dados; b) aplicação; 
c) implementação e; d) infraestrutura. Os padrões candidatos devem ser preenchidos 
nas células de forma que cada padrão seja associado a um problema e a um tipo de pa-
drão. Para realizar o preenchimento da tabela, é necessário pesquisar e entender quais 
padrões se enquadram e solucionam o problema em particular e inseri-lo na célula que 
corresponde ao problema e ao tipo do padrão (PRESSMAN; MAXIM, 2016).
Uma relação de padrões e linguagens de padrões , disponível em: https://bit.ly/2Z4HNqc
Tabela 1 – Uma tabela paraorganização de padrões
Banco de Dados Aplicação Implementação Infraestrutura
Dados / Conteúdo
Enunciado do problema... Nome(s) do(s) Padrão(ões)
Nome(s) do(s) 
Padrão(ões)
Enunciado do problema... Nome(s) do(s) Padrão(ões)
Nome(s) do(s) 
Padrão(ões)
Enunciado do problema... Nome(s) do(s) Padrão(ões)
Nome(s) do(s) 
Padrão(ões)
Interface do usuário
Enunciado do problema... Nome(s) do(s) Padrão(ões)
Enunciado do problema... Nome(s) do(s) Padrão(ões)
Nome(s) do(s) 
Padrão(ões)
Enunciado do problema...
Componentes
Enunciado do problema... Nome(s) do(s) Padrão(ões)
Nome(s) do(s) 
Padrão(ões)
Enunciado do problema... Nome(s) do(s) Padrão(ões)
Enunciado do problema... Nome(s) do(s) Padrão(ões)
Nome(s) do(s) 
Padrão(ões)
Arquitetura
Enunciado do problema... Nome(s) do(s) Padrão(ões)
Nome(s) do(s) 
Padrão(ões)
Enunciado do problema... Nome(s) do(s) Padrão(ões)
Nome(s) do(s) 
Padrão(ões)
Enunciado do problema... Nome(s) do(s) Padrão(ões)
Nome(s) do(s) 
Padrão(ões)
Fonte: Microsoft (2004) apud PRESSMAN; MAXIM, 2016, p. 358
21
UNIDADE Projeto de Arquitetura de Software 
É importante salientar que erros podem ocorrer durante o projeto baseado em padrões, 
como não ter dedicado tempo suficiente para entender o problema e seu contexto e 
forças, ocasionando em uma escolha inapropriada de um padrão para a solução exigida. 
Quando isso acontece, a tendência é forçar a utilização do padrão, mesmo que ele 
não se enquadre corretamente na solução do problema em questão. É possível evitar 
certos erros no projeto de software, para tal, por exemplo, pode-se utilizar técnicas de 
revisão e também convidar outros integrantes do time de desenvolvimento a revisar as 
representações arquiteturais e a tabela de organização de padrões. Vale ressaltar que a 
abordagem de projeto baseado em padrões não é utilizada de maneira isolada, portanto, 
deve ser utilizada de forma conjunta com outros conceitos e técnicas de projeto de 
software (PRESSMAN; MAXIM, 2016).
Importante
 “Não imponha um padrão, mesmo que ele atenda ao problema em questão. Se o contexto 
e as forças estiverem errados, procure outro padrão”. (PRESSMAN; MAXIM, 2016, p. 359)
Um vídeo sobre arquitetura de software num cenário de incertezas pode ser assistido a 
partir do link disponível em: https://bit.ly/3aSm4qP
22
23
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
Biblioteca Cruzeiro do Sul Virtual
https://bit.ly/3jyGs4g 
OMG – Object Management Group
https://bit.ly/3a67gpi
The Hillside Group 
https://bit.ly/2Z4HNqc
 Vídeos
 Arquitetura de software num cenário de incertezas
https://bit.ly/3aSm4qP
 Leitura
 ISO/IEC 9126 
https://bit.ly/3jCdEaY
 FURPS 
https://bit.ly/3jBMdhy
23
UNIDADE Projeto de Arquitetura de Software 
Referências
BASS, L.; CLEMENTS, P.; KAZMAN, R. Software architecture in practice. 2.ed. 
Addison-Wesley, 2003.
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 3.ed. São 
Paulo: Elsevier, 2015.
FOWLER. M. UML Essencial: um breve guia para a linguagem-padrão de modelagem 
de objetos. 3.ed. Porto Alegre: Bookman, 2005.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orien-
tados a objetos e ao desenvolvimento iterativo. 3.ed. Porto Alegre: Bookman 2007.
PRESSMAN, R. S.; MAXIM. B. R. Engenharia de software. 8.ed. Porto Alegre: 
AMGH, 2016.
SCOTT, K. O processo unificado explicado. Porto Alegre: Bookman, 2003.
WAZLAWICK, R. S. Análise e design orientados a objetos para sistemas de informa-
ção: modelagem com UML, OCL e IFML. 3.ed. Rio de Janeiro: Campus Elsevier, 2015.
24