I_MSoftware

Prévia do material em texto

Geórgia Maria Ferro Benetti
Jeanfrank Teodoro Dantas Sartori
Sidartha Azevedo Lobo de Carvalho
Manutenção de Software
© Universidade Positivo 2018
Rua Prof. Pedro Viriato Parigot de Souza, 5300 – Campo Comprido 
Curitiba-PR – CEP 81280-330
*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência.
Informamos que é de inteira responsabilidade da autoria a emissão de conceitos. 
Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização. 
A violação dos direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.
Imagens de ícones/capa: © Thinkstock / © Anatomy Insider / Shutterstock.com
Presidente da Divisão de Ensino 
Reitor
Pró-Reitor de Graduação 
Pró-Reitor de Pós-Graduação e Pesquisa
Coordenação Geral de EAD
Coordenação de Metodologia e Tecnologia
Autoria
Parecer Técnico
Supervisão Editorial
Projeto Gráfico e Capa
Prof. Paulo Arns da Cunha
Prof. José Pio Martins
Prof. Carlos Longo
Prof. Ronaldo Vinicius Casagrande
Prof. Everton Renaud
Profa. Roberta Galon Silva
Profa. Geórgia Maria Ferro Benetti
Prof. Jeanfrank Teodoro Dantas Sartori
Prof. Sidartha Azevedo Lobo de Carvalho 
Prof. Cleverson Avelino Ferreira
Aline Scaliante Coelho Baggetti
Regiane Rosa
Dados Internacionais de Catalogação na Publicação (CIP)
Biblioteca da Universidade Positivo – Curitiba – PR
DTCOM – DIRECT TO COMPANY S/A
Análise de Qualidade, Edição de Texto, Design Instrucional, 
Edição de Arte, Diagramação, Design Gráfico e Revisão.
3
Caro aluno,
A metodologia da Universidade Positivo apresenta materiais e tecnologias apropriadas 
que permitem o desenvolvimento e a interação entre alunos, docentes e recursos didáticos e 
tem por objetivo a comunização bidirecional entre os atores educacionais.
O seu livro, que faz parte dessa metodologia, está inserido em um percurso de aprendi-
zagem que busca direcionar a construção de seu conhecimento por meio da leitura, da con-
textualização teórica-prática e das atividades individuais e colaborativas; e fundamentado 
nos seguintes propósitos:
COMPREENDA SEU LIVRO
valorizar suas 
experiências;
incentivar a 
construção e a 
reconstrução do 
conhecimento;
estimular a 
pesquisa;
oportunizar a reflexão 
teórica e aplicação 
consciente dos temas 
abordados.
Metodologia
4
COMPREENDA SEU LIVRO
Com base nessa metodologia, o livro apresenta a seguinte estrutura:
Percurso
Pergunta norteadora
Ao final do Contextualizando o cenário, 
consta uma pergunta que estimulará sua 
reflexão sobre o cenário apresentado, 
com foco no desenvolvimento da sua 
capacidade de análise crítica.
Tópicos que serão estudados
Descrição dos conteúdos que serão 
estudados no capítulo.
Boxes
São caixas em destaque que podem 
apresentar uma citação, indicações de 
leitura, de filme, apresentação de um 
contexto, dicas, curiosidades etc.
Recapitulando
É o fechamento do capítulo. Visa sinte-
tizar o que foi abordado, reto mando os 
objetivos do capítulo, a pergunta nortea-
dora e fornecendo um direcionamento 
sobre os questionamentos feitos no 
decorrer do conteúdo.
Pausa para refletir
São perguntas que o instigam a 
refletir sobre algum ponto 
estudado no capítulo.
Contextualizando o cenário
Contextualização do tema que será 
estudado no capítulo, como um 
cenário que o oriente a respeito do 
assunto, relacionando teoria e prática.
Objetivos do capítulo
Indicam o que se espera que você 
aprenda ao final do estudo do 
capítulo, baseados nas necessida-
des de aprendizagem do seu curso.
Proposta de atividade
Sugestão de atividade para que você 
desenvolva sua autonomia e siste-
matize o que aprendeu no capítulo. 
Referências bibliográficas
São todas as fontes utilizadas no 
capítulo, incluindo as fontes mencio-
nadas nos boxes, adequadas 
ao Projeto Pedagógico do curso.
5
BOXES
Assista 
Indicação de filmes, vídeos ou similares que trazem informações 
complementares ou aprofundadas sobre o conteúdo estudado. 
Biografia 
Dados essenciais e pertinentes sobre a vida de uma determinada 
pessoa relevante para o estudo do conteúdo abordado.
Contexto 
Dados que retratam onde e quando aconteceu determinado fato; 
demonstram a situação histórica, social e cultural do assunto. 
Curiosidade 
Informação que revela algo desconhecido e interessante sobre 
o assunto tratado.
Dica 
Um detalhe específico da informação, um breve conselho, um alerta, 
uma informação privilegiada sobre o conteúdo trabalhado. 
Exemplo 
Informação que retrata de forma obje tiva determinado assunto 
abordando a relação teoria-prática.
Afirmação
Citações e afirmativas pronunciadas por teóricos de relevância 
na área de estudo.
Esclarecimento 
Explicação, elucidação sobre uma palavra ou expressão específica 
da área de conhecimento trabalhada. 
7
SUMÁRIO
Apresentação 13
A Autoria 14
CAPÍTULO 1
A Arquitetura de Software no processo de desenvolvimento de 
sistemas 17
Contextualizando o cenário 18
1.1. Visão Geral 19
1.1.1. Arquitetura do sistema 19
1.1.2. Motivação para desenvolver uma Arquitetura de Software 21
1.1.3. Erros comuns 22
1.2. Conceitos e processos de software 23
1.2.1. Definição de Arquitetura de Software 23
1.2.2. Modelo de análise e projeto 24
1.2.3. Coesão e acoplamento 25
1.2.4. Níveis de abstração 25
1.3. Arquiteto de Software 27
1.3.1. Papel do arquiteto de software 27
1.3.2. Contexto de atuação 28
1.4. Casos de Uso 29
1.4.1. Exemplo de aplicação 29
1.4.2. Custo e benefícios 30
1.4.3. Modelo Visual do Sistema (MVS) 31
Proposta de Atividade 33
Recapitulando 33
Referências 34
CAPÍTULO 2
O modelo 4 + 1 35
Contextualizando o cenário 36
2.1. Diferentes conceitos 37
2.1.1. Modelo de referência 37
2.1.2. Framework 39
2.1.3. Estilos 40
2.1.4. Padrões 43
2.2. 4+1 e a visão de cenários de uso 44
2.2.1. Visão lógica 45
2.2.2. Visão de processo 46
2.2.3. Visão física 47
2.2.4. Visão de desenvolvimento 48
2.3. Documento de Arquitetura de Sistema (DAS) 49
2.3.1. Visão geral 49
2.3.2. Como utilizar 50
Proposta de Atividade 51
Recapitulando 51
Referências 53
CAPÍTULO 3
Padrões de Projeto 55
Contextualizando o cenário 56
3.1. Padrões do Gang of Four (GOF) e suas categorias 57
3.1.1. Componentes dos padrões GOF 57
3.1.2. Padrões Criacionais 60
3.1.3. Padrões Estruturais 61
3.1.4. Padrões Comportamentais 62
3.2. Implementação dos padrões 64
Proposta de Atividade 70
Recapitulando 70
Referências 71
9
CAPÍTULO 4
Arquitetura Orientada a Serviços (SOA) 73
Contextualizando o cenário 74
4.1. Introdução 75
4.1.1. Requisitos 77
4.1.2. Acoplamento 78
4.1.3. Desenho 79
4.2. Serviço 80
4.2.1. Visão geral 82
4.2.2. Granularidade 84
4.3. Aplicação 86
4.3.1. Exemplo de aplicação 86
4.3.2. Vantagens e desvantagens da arquitetura SOA 87
Proposta de Atividade 88
Recapitulando 88
Referências 90
CAPÍTULO 5
Arquitetura n-tier 91
Contextualizando o cenário 92
5.1. Camadas 93
5.1.1. Camada cliente 95
5.1.2. Camada aplicação 97
5.1.3. Camada banco de dados 100
5.2. Aplicação 101
5.2.1. Exemplo de aplicação 101
5.2.2. Vantagens e desvantagens da arquitetura n-tier. 103
Proposta de Atividade 105
Recapitulando 105
Referências 107
10
CAPÍTULO 6
Arquitetura móvel 109
Contextualizando o cenário 110
6.1. Modelo de arquitetura 111
6.1.1. Visão geral 113
6.1.2. Estilo Representational State Transfer (REST) 116
6.2. Aplicação 119
6.2.1. Exemplo de aplicação 120
6.2.2. Premissas e restrições de uma arquitetura móvel 122
Proposta de Atividade 123
Recapitulando 123
Referências 124
CAPÍTULO 7
Arquitetura de aplicações ricas (RIA) 125
Contextualizando o cenário 126
7.1. Visão geral 127
7.1.1. Benefícios 127
7.1.2. Deficiências e restrições 129
7.1.3. Dificuldades de gerenciamento 131
7.2. Tecnologia 132
7.2.1. Chamada assíncrona 132
7.2.2. Tecnologias de apresentação 134
7.2.3. Interfaces Web Mobile responsivas 135
7.3. Aplicação 136
7.3.1.Utilização de Java Script 137
7.3.2. Utilização de Angular JS 138
Proposta de Atividade 139
Recapitulando 140
Referências 141
11
CAPÍTULO 8
Computação em nuvem e softwares adaptativos 143
Contextualizando o cenário 144
8.1. Introdução à computação em nuvem 145
8.1.1. Tipologia da computação em nuvem 146
8.1.2. Desenho da arquitetura 148
8.1.3. Modelo de implantação 149
8.2. Arquitetura reativa 151
8.2.1. Manifesto reativo 152
8.2.2. Decisões arquiteturais 153
8.3. Arquitetura adaptativa 154
8.3.1. Habilidade de mudança 155
8.3.2. Exemplo de aplicação 155
Proposta de Atividade 157
Recapitulando 157
Referências 158
13
Planejamento prévio é uma recomendação válida e pertinente para todo projeto. Afi-
nal, muitos erros decorrem diretamente do fato de essa etapa ter sido negligenciada ou 
feita inadequadamente. Ela busca garantir, em linhas gerais, que se saiba claramente onde 
se quer chegar e o que precisará ser executado para esse fim.
 No desenvolvimento de softwares, não é diferente. Antes de iniciar-se o processo de 
codificação, é recomendada a seguinte prática: a criação de um modelo geral que descreva 
como esse sistema será distribuído em componentes (ou módulos) e suas conexões e rela-
ções. Mas essa responsabilidade compete a qual profissional? E ele fará uso de qual prin-
cipal instrumento de planejamento? Quais são as metodologias mais comuns adotadas? 
Esses e outras perguntas serão respondidas ao longo nesta disciplina, que também ensi-
nará de que forma é possível executar, com propriedade, esse importante papel em proje-
tos de desenvolvimento de software. Bons estudos!
APRESENTAÇÃO
14
A Professora Georgia Maria Ferro Benetti Ribeiro é Doutora em Ciências Humanas, com 
formação em Análise de Sistemas. Tem vários anos de experiência como docente no ensino 
superior em cursos de graduação e pós-graduação. Embaixadora e mentora no desafio Tech-
novation Challenge Brasil. Integrante do PyLadies Florianópolis. Sócia Fundadora da ONG 
Inspiring Girls no Brasil.
Currículo Lattes:
<lattes.cnpq.br/2605217800781166>
A AUTORIA
Dedico esse material a todos e todas 
que tenham como propósito trabalhar 
a tecnologia como um recurso que está 
a serviço do humano em nós e da vida 
humana como parte integrante da 
natureza.
15
O Professor Jeanfrank Teodoro Dantas Sartori é graduado em Administração pela 
Universidade Federal do Paraná. Possui mais de 15 anos de experiência na área de Tecnologia 
da Informação e Análise de Dados, tendo atuado no setor educacional, gráfico e bancário. 
Currículo Lattes:
<lattes.cnpq.br/2047592684381858>
A AUTORIA
A Deus, a quem tudo pertence. Aos 
meus pais, que me deram amor 
e me prepararam para a vida. 
Aos meus professores, que me 
ensinaram o caminho acadêmico. 
Aos verdadeiros amigos e a todos 
vão além do seu dever.
16
O Professor Sidartha Azevedo Lobo de Carvalho é mestre em Ciência da Computa-
ção pela Universidade Federal de Pernambuco com ênfase em Sistemas Embarcados (2015). 
Bacharel em Sistemas da Informação pela Universidade Federal do Ceará (2012). Atuou como 
pesquisador no Projeto Samsung e Motorola pelo Projeto CIN/UFPE. Trabalha principal-
mente com ferramentas e técnicas inteligentes para eficiência energética em smatphones. 
Currículo Lattes:
<lattes.cnpq.br/9163574470590664>
A AUTORIA
Agradeço toda a equipe que contribuiu 
para a concretização desse deste 
trabalho. 
17
OBJETIVOS DO CAPÍTULO
• Entender como a Arquitetura de Software está inserida no processo de desenvol-
vimento e o papel do arquiteto de software nesse processo, definindo os conceitos
básicos e suas aplicações.
CAPÍTULO 1
A Arquitetura de Software no processo de 
desenvolvimento de sistemas 
Jeanfrank Teodoro Dantas Sartori
TÓPICOS DE ESTUDO
1 Visão Geral 3 Arquiteto de Software
• Arquitetura de Software.
• Motivação para desenvolver uma
arquitetura de software.
• Erros comuns.
• Papel do arquiteto de software.
• Contexto de atuação.
2 Conceitos e Processo de Software 4 Casos de Uso
• Definição de Arquitetura de
Software.
• Modelo de análise e projeto.
• Coesão e acoplamento.
• Níveis de abstração.
• Exemplo de aplicação.
• Custo e benefícios.
• Modelo Visual do Sistema (MVS).
18
Contextualizando o cenário
A primeira etapa de aprendizado desta disciplina trará uma visão geral da Arquitetura de 
Software ou de Sistemas. Os estudos também contemplarão sua definição, seus benefícios 
e custos, além de uma visão geral do papel do profissional responsável por sua criação – o 
Arquiteto de Software –, quais suas atribuições, desafios e contribuições para o processo de 
desenvolvimento como um todo.
Diante desse cenário, fica a questão: é possível imaginar qual é papel da Arquitetura de 
Software e do profissional responsável por ela? E como isso se encaixa no fluxo de cria-
ção de um software? 
19
1.1. Visão Geral
A maioria dos profissionais de arquite-
tura conhece o papel do arquiteto em uma 
construção ou ponto urbanístico, suas rela-
ções com o trabalho do engenheiro civil e 
suas responsabilidades quanto ao resultado 
geral de um projeto.
Nesse sentido, o uso do termo arqui-
tetura para a área de Tecnologia da Infor-
mação não é coincidência ou uma aleatoriedade. Ao contrário: a analogia é bastante 
pertinente e ajuda a compreender o papel e a função da arquitetura no processo de desen-
volvimento de um software.
1.1.1. Arquitetura do sistema 
A palavra arquitetura representa, entre outros significados, segundo o dicionário 
Michaelis, a “Arte e ciência de projetar e supervisionar a construção de edifícios ou outras 
estruturas (...)” ou o “modo como se dispõem as partes ou os elementos de um edifício ou 
de um espaço urbano”. Já a expressão engenharia significa, na construção civil, segundo 
esse mesmo dicionário, a “Arte de aplicar os conhecimentos científicos à invenção, aperfei-
çoamento ou utilização da técnica industrial” (Weiszflog, 2004). 
Nesse contexto, em linhas gerais, cabe à arquitetura a concepção geral de uma edifi-
cação, definição de suas partes, sua integração, seus aspectos técnicos e funcionais. Além 
disso, a arquitetura planeja o aspecto visual desse edifício (por exemplo, a fachada de um 
prédio, suas cores, revestimento, etc.). Ademais, apesar de ter conhecimentos gerais sobre 
as questões estruturais e operacionais, ela se ocupa prevalentemente dos aspectos mais 
panorâmicos do planejamento de uma dada construção.
Ao engenheiro civil, por sua vez, compete transformar o projeto arquitetônico em 
uma construção efetiva, competindo a ele os cálculos estruturais, orçamento e otimização 
dos materiais a serem empregados, planejamento e coordenação da operação de constru-
ção e vistoria do resultado final, entre outras muitas atribuições.
Como exemplo disso, podemos pensar na construção de um museu. Para projetar 
esse museu, um arquiteto desenha, primeiramente, um croqui (esboço). O resultado real (o 
museu pronto para visitação), produzido por meio do trabalho dos engenheiros que atua-
ram em seu planejamento e construção, foi baseado em um desenho. A figura a seguir 
demonstra o Museu Oscar Niemeyer já pronto para visitação.
©
 D
ra
go
n 
Im
ag
es
 / 
/ S
hu
tt
er
st
oc
k.
 
20
Museu Oscar Niemeyer
E é justamente a partir de uma analogia desses termos oriundos da área da constru-
ção que surgem as expressões equivalentes na área de sistemas, conforme apresentado no 
quadro a seguir.
Paralelos entre as atividades da Construção Civil e da Análise de Sistema
Construção Civil Análise de Sistemas
Arquiteto Arquiteto de oftware
Engenheiro Civil Engenheiro de Software
Assim, a Arquitetura de Software corresponde, em linhas gerais, ao planejamento 
ou à definição dos componentes de um sistema, suas principais propriedades e suas inter-
-relações. Por componentes podemos compreender os elementos fundamentais, como um
servidor, um banco de dados e até mesmo os usuários.
A engenharia de software,por sua vez, resumidamente é a área encarregada de 
gerenciar e executar efetivamente a programação de um sistema, a partir do escopo defi-
nido inicialmente, até o seu resultado final. Zela, também, pela manutenção e atualização.
©
 G
re
go
ri
o 
K
oj
i /
 / 
Sh
ut
te
rs
to
ck
.
21
No cotidiano e na própria academia, todavia, a fronteira entre a arquitetura e a enge-
nharia de software nem sempre é tão clara, e sobreposições acabam acontecendo, assim 
como na construção civil. Há diferentes visões em relações a aspectos mais específicos, e, 
por essa razão, deve prevalecer sempre o bom senso e o trabalho em equipe, visando ao 
resultado final, e não ao destaque pessoal.
1.1.2. Motivação para desenvolver uma Arquitetura de Software
Entre as razões e vantagens da criação de uma Arquitetura de Software, pode-se des-
tacar o fato de ela constituir um meio de comunicação entre os stakeholders de um projeto, 
proporcionar o estabelecimento das decisões fundamentais de sistema e a reusabilidade da 
abstração em outros sistemas (BASS; CLEMENTES; KAZMAN, 2003).
Primeiramente, o desenvolvimento de sistemas envolve um conjunto de diversos 
interesses, por vezes conflitantes, dos stakeholders.
Esclarecimento
Stakeholders são as partes interessadas ou afetadas pelo software, como o 
cliente, os engenheiros de software, os programadores etc.
Nesse sentido, a Arquitetura de Software oferece uma linguagem e uma base comum 
para que essas questões sejam discutidas e sanadas antes que as primeiras linhas de código 
tenham sido construídas.
Por sua vez, as decisões fundamentais tomadas no escopo da Arquitetura de Software 
definem, entre outros fatores, os componentes gerais de um software, o que permite um 
melhor planejamento da alocação de recursos financeiros e humanos no efetivo desenvolvi-
mento. Tem-se, assim, a possibilidade de se otimizar todo o ciclo produtivo a partir de uma 
visão mais clara de seus elementos fundamentais.
Além disso, por constituir uma abstração do sistema, a Arquitetura de Software pode 
vir a ser reutilizada, ainda que parcialmente, em outros projetos análogos ou similares, per-
mitindo uma grande economia de recursos, do mesmo modo que sempre se busca, quando 
possível, a reutilização de códigos de programação. 
Mas, apesar de apresentar diversas vantagens, a Arquitetura de Software também 
oferece algumas armadilhas, por vezes recorrentes, as quais chamamos de erros.
22
1.1.3. Erros comuns
Um dos erros mais comuns e fonte de diversos problemas é a criação de um distancia-
mento entre arquitetos de software e engenheiros de software e programadores, assim 
como ocorre, muitas vezes, na construção civil. Esse fator pode ter origem na coordenação 
geral de uma empresa ou projeto, mas também pode ter suas raízes nos próprios arquite-
tos e engenheiros.
Ser responsável pelas definições gerais 
de um software não significa ser dono da 
razão nem possuir qualquer outro poder 
sobrenatural. Ao contrário: exige grande res-
ponsabilidade, além de capacidade de ouvir 
e avaliar diferentes pontos de vista, incluindo 
o cliente e os engenheiros de software. Com
estes últimos, deve-se formar uma perspec-
tiva de equipe que compartilha um objetivo comum. Por essa razão, as preocupações e ques-
tionamentos dos stakeholders envolvidos devem ser sempre consideradas e avaliadas. 
Outro erro frequente diz respeito à criação de elefantes brancos, uma metáfora que 
se refere à idealização de uma arquitetura desproporcionalmente grande e complexa em 
relação às reais necessidades do projeto. O resultado certamente será um grande desper-
dício de recursos, uma vez que seu desenvolvimento terá dificuldades desnecessárias e não 
agregarão benefícios reais ao cliente. Ademais, há risco de, eventualmente, ser necessário 
um retorno à fase de concepção, para correções, ou mesmo de haver dificuldades posterio-
res de manutenção e atualização.
Contexto
Erros de modelagem de software podem custar caro. Em 1996, o então novo 
foguete de carga Ariane 5 explodiu 40 segundos após o lançamento, por um erro de especi-
ficação e de design do sistema de navegação. Foram pelos ares 8,5 bilhões de dólares desen-
volvimento e da carga abordo. (LIONS, 1996).
Por fim, outro erro bastante comum acontece quando há um distanciamento dos 
aspectos técnicos do posterior desenvolvimento. Em outras palavras, esse problema ocorre 
quando a arquitetura tem sua abstração do sistema demasiadamente desconectado da rea-
lidade de desenvolvimento e das questões a ele relacionados, o que pode gerar um con-
ceito de sistema difícil de ser concretizado. Esse erro pode ter origem no distanciamento 
com a equipe de engenharia e programação.
©
 G
ra
ph
ic
 fa
rm
 / 
/ S
hu
tt
er
st
oc
k
23
Pausa para refletir
Colocar em prática a arquitetura de software não é tão simples como possa parecer. Você 
consegue imaginar como esse processo é desenvolvido? E como será que essa arquitetura 
costuma ser representada? 
1.2. Conceitos e processos de software
A Arquitetura de Software é um 
modelo geral que explica como o sistema 
irá funcionar e suas principais funcionalida-
des. Assim, precisa representar quais módu-
los ou componentes farão quais papéis e 
como se conectam. A definição adequada 
dessas questões tornará mais fluidas e efi-
cientes as fases posteriores de desenvolvi-
mento e codificação.
Além dessas questões, a seguir serão estudadas as características que devem estar 
presentes no processo de desenvolvimento e fatores gerais que devem ser considerados na 
Arquitetura de Software. Esse estudo é importante porque, embora o ato de esboçar uma 
Arquitetura de Software possa parecer, inicialmente, uma tarefa até simples, a realidade 
dos projetos costuma ser bastante desafiadora.
1.2.1. Definição de Arquitetura de Software
A Arquitetura de Software é composta por um conjunto de componentes e conexões 
entre eles. Todavia, ela possui uma significativa subjetividade, fazendo uso de elementos 
gráficos, uma compreensão compartilhada do futuro sistema e um conjunto de decisões 
estabelecidas desde o início do projeto (FOWLER, 2006). Isso não é atingido pela mera 
representação gráfica. 
Primeiramente, não basta simplesmente elencar os componentes, pois eles pre-
cisam estar devidamente especificados quanto a sua natureza, além de saber se são pro-
cessos, programas ou ambos. A separação entre componentes deve ter uma justificativa 
apresentada, bem como a descrição de como suas respectivas funções serão executadas 
em termos de tempo e processamento. Além disso, cada componente deve ter sua respon-
sabilidade definida, ou seja, é necessário saber qual papel deve exercer dentro do sistema 
como um TODO (BASS; CLEMENTES; KAZMAN, 2003). 
©
 Ic
on
ic
 B
es
ti
ar
y 
/ /
 S
hu
tt
er
st
oc
k.
24
Com relação às conexões, não basta uma simples interligação gráfica. É necessário espe-
cificar o que elas significam e de que tipo são. Podem ser, por exemplo, uma relação de mera 
comunicação, controle, evocação, sincronização etc. (BASS; CLEMENTES; KAZMAN, 2003). 
Assim, a arquitetura define os componentes ou elementos de um sistema, subsidiando 
a própria divisão do desenvolvimento, uma vez que cada equipe sabe exatamente o que a sua 
parte deve fazer em relação ao todo. Desse modo, todo sistema tem uma arquitetura, ainda 
que, em alguns casos não ideais, ela não tenha sido concebida de modo prévio e deliberado.
1.2.2. Modelo de análise e projeto
Construir uma Arquitetura de Software requer, essencialmente, um modelo geral 
e panorâmico de seu funcionamento, que servirá como uma espécie de mapa e de norte 
para o desenvolvimento do sistema, guiando a atuação de engenheiros e programadores.
Isso ocorre porque o desenvolvimento de um software é algo complexo, e sua com-
preensão fica facilitada quando o problema é decomposto em partes menores que, em 
conjunto, formarão a Arquitetura de 
Software (LARMAN, 2007).
Paraa construção desse modelo, 
é bastante recomendada a utilização 
da Linguagem de Modelagem Unifi-
cada (UML, na sigla em inglês), própria 
para esse tipo de descrição de sistemas 
(LARMAN, 2007). 
Contexto
O uso de modelos é tão importante no processo de desenvolvimento de soft-
ware que cada vez tem ganho maior centralidade e preponderância. Tem-se, por exemplo, a 
arquitetura dirigida por modelo e também uma metodologia de testes nela baseada. (UZUN; 
TEKINERDOGAN, 2018).
Construir um modelo adequado e útil, que não crie dificuldades ou problemas para as 
etapas seguintes, requer algumas características e propriedades balizem o seu desenvolvi-
mento. Isso inclui coesão e acoplamento.
©
 M
ic
ro
O
ne
 / 
/ S
hu
tt
er
st
oc
k
25
1.2.3. Coesão e acoplamento
Ao modelar e fazer a definição das funções de cada um dos componentes da Arqui-
tetura de Software, é importante buscar atender às principais características de coesão e 
acoplamento, uma vez que, dessa observância, tende a emergir um projeto robusto e que 
não gerará dificuldades e conflitos na fase de desenvolvimento e codificação.
O primeiro conceito, de coesão, guarda 
sentido, primeiramente, com as funções atri-
buídas a um dado componente. A ideia por 
ela expressa é de que essas funções devem 
ser coesas e relacionadas. É de se imaginar 
que um módulo de gestão de folha de paga-
mentos também cuide, eventualmente, dos 
controles de apontamentos e bancos de 
horas. Porém seria pouco razoável incluir no 
mesmo componente o processamento de 
balanço contábil ou controle de caixa.
Em termos de acoplamento, tem-se a ideia de um encaixe adequado entre os múlti-
plos componentes, ou seja, eles se completam e possuem uma boa interdependência. Em 
outras palavras, não extrapolam suas funções nem se sobrepõem uns aos outros.
Somando ambos conceitos, podemos fazer uma analogia com um quebra-cabe-
ças: cada peça tem a forma exata do local onde deve ser encaixada, não sendo maior 
nem menor, sem sobreposições, ou seja, é o acoplamento perfeito. A imagem de sua face 
envolve somente elementos daquela parte da imagem total, pixel a pixel, próximos e corre-
lacionados: é a coesão.
Mas não só destes atributos se faz uma boa Arquitetura de Software. É preciso, ainda, 
adequar o nível de abstração às necessidades do projeto. 
1.2.4. Níveis de abstração
Abstração é a capacidade, única de nossa espécie, de, a partir de vários elementos 
dispersos, construir uma correlação superior que não está, ao menos em seu todo, explí-
cita. É encontrar significado em partes sem uma lógica previamente conhecida, podendo 
dar-se por analogia, inferência e outros métodos.
©
 ta
sa
ni
 b
in
 a
bd
ul
 h
am
id
 / 
/ S
hu
tt
er
st
oc
k.
https://www.shutterstock.com/pt/g/tasani+bin+abdul+hamid
26
Porém, é fácil perceber que uma abstração pode ser feita em diversos níveis, depen-
dendo do foco e da necessidade. Quanto mais alta a abstração, menor o nível de detalha-
mento, porém mais amplo o alcance do modelo. Isso é especialmente útil quando há um 
grande número de funções distintas, uma vez que a visão mais panorâmica facilitará a 
construção do modelo e o posterior desenvolvimento. 
Quanto mais baixa, mais detalhada – e maior a especificidade abrangida. Torna-se 
pertinente quando temos um número menor de funções, porém com complexidade e parti-
cularidades maiores. Contudo, não há regras: caberá ao profissional compreender qual é a 
abstração mais adequada a cada projeto.
Pausa para refletir
Por trás desta etapa importante do desenvolvimento de software certamente estará ao 
menos um profissional. Quais os desafios que ele irá enfrentar? Como ele deve conduzir a 
construção da Arquitetura de Software em um dado projeto? 
Podemos resumir os últimos três tópicos no quadro a seguir.
Síntese das características ideais da Arquitetura de Software e suas propriedades
Característica Propriedade
Coesão Funções relacionadas dentro de cada componente.
Acoplamento Complementariedade e interdependência dos componentes.
Abstração Nível de simplificação do modelo geral.
©
 K
ir
as
ol
ly
 / 
/ S
hu
tt
er
st
oc
k.
27
Desse modo, podemos perceber o quanto a coesão, o acoplamento e a abstração 
são aspectos importantes a serem considerados pelo arquiteto de software em sua atua-
ção profissional. A seguir, começaremos a explorar um pouco mais sobre sua atuação e seu 
papel em um projeto de desenvolvimento de software.
1.3. Arquiteto de Software
Por traz de uma Arquitetura de Software 
bem construída e que, efetivamente, sustente um 
eficiente e fluido desenvolvimento, está a figura 
de um profissional de suma importância, em espe-
cial em projetos de grande complexidade. 
Essa construção da Arquitetura de Software 
fica a cargo do Arquiteto de Software, que é o pro-
fissional especializado na implementação dessa 
importante etapa inicial dos projetos de desenvolvimento de sistemas. Para isso, ele preci-
sará compreender bem o seu papel e como deverá exercê-lo para atingir seus objetivos. 
1.3.1. Papel do arquiteto de software
A atividade do arquiteto de software está 
presente em todo e qualquer projeto de desen-
volvimento de sistemas, independentemente 
de o cargo específico existir formalmente ou 
não. Afinal, elaborar o design geral é uma ati-
vidade que precisará, de algum modo, ser 
feita, explícita ou implicitamente, planejada ou 
resultante, detalhada ou simplificada.
Todavia, em cenários mais complexos ou com um volume grande de projetos con-
comitantes, a tendência é que se adote a contratação de um profissional especializado, o 
Arquiteto de Software.
Nesse contexto, esse profissional – usualmente o único (ou um dos poucos) que exer-
cem essa função numa organização – ficará responsável exclusivamente pelo desenvolvi-
mento das arquiteturas de software dos projetos. Em outras palavras, todos os sistemas 
passarão primeiro por suas mãos, cabendo a esse profissional a responsabilidade de desen-
volver modelos adequados e que permitam que a continuidade do desenvolvimento e codi-
ficação se deem de modo fluido e eficiente.
©
 M
on
ke
y 
B
us
in
es
s I
m
ag
es
 / 
/ S
hu
tt
er
st
oc
k.
 
©
 S
yd
a 
Pr
od
uc
ti
on
s 
/ /
 S
hu
tt
er
st
oc
k
28
Em seu papel, o arquiteto precisa lidar 
com diversos fatores humanos e sociais den-
tro das organizações. Primeiramente, há a 
relação com engenheiros de software, que 
pode ser delicada em virtude de haver algu-
mas áreas de penumbra, ou seja, de sobrepo-
sição entre as funções. Se isso não for bem 
administrado e amenizado por meio de um 
bom relacionamento, pode tornar-se uma 
grande e persistente fonte de conflitos. 
Não menos importantes são as etapas seguintes de engenharia e programação, que 
não podem receber um grande elefante branco, que seria de difícil desenvolvimento, inte-
gração, manutenção e atualização. Entregar a essa equipe um design mal elaborado será 
fonte de conflitos, atrasos e desperdício de recursos.
Além disso, o desenvolvimento da Arquitetura de Software requer do profissional 
mais do que simplesmente conhecimento técnico e experiência. É preciso que haja uma boa 
comunicação e capacidade de abstração, uma vez que o bom desempenho de seu traba-
lho dependerá da adequada captação das necessidades e desejos dos diversos stakeholders 
envolvidos no projeto, além da habilidade de negociar expectativas por vezes conflitantes. 
Assim, é essencial que o arquiteto de software conheça seu contexto de atuação.
1.3.2. Contexto de atuação
O cargo de arquiteto de software é mais frequente em empresas de grande porte, 
com muitos projetos simultâneos e/ou poucos projetos, porém de alta complexidade. E há 
uma razão para isso.
Primeiramente, é preciso levar em conta que sua atuação é concentrada nos estágios 
iniciais de um software, com pouca participação – apesar de existente – no restante do pro-
cesso de desenvolvimento. Afinal, se esse profissional seenvolver permanentemente nas eta-
pas seguintes, talvez acabe fazendo mais sentido seu cargo ser de engenheiro de software.
Assim, se não houver uma demanda significativa, em quantidade ou complexidade, é 
difícil justificar a presença de um colaborador exclusivo para a função de arquiteto de soft-
ware. O quadro a seguir apresenta, didaticamente, a probabilidade de atuação de um pro-
fissional dedicado exclusivamente à função de arquiteto de software em uma empresa, 
com base na complexidade e quantidade de projetos.
©
 F
ot
os
59
3 
/ /
 S
hu
tt
er
st
oc
k
29
Probabilidade de atuação de um Arquiteto de Software segundo a quantidade de pro-
jetos e respectiva complexidade
Complexidade do(s) Projeto(s)
Quantidade de Projetos Baixa Alta
Poucos Improvável Provável
Muitos Possível Indispensável
Além disso, são profissionais que costumam atuar sozinhos ou, no máximo, em uma 
pequeníssima equipe. Por serem raros aqueles com experiência e domínio da área, acabam 
sendo bem remunerados – uma restrição para pequenas organizações.
1.4. Casos de Uso
Quanto mais complexo for o contexto de desenvolvimento de software, mais impor-
tante é o papel do arquiteto de software. Isso será ilustrado em um exemplo bastante inco-
mum, visando contemplar melhor a aplicação dos conceitos estudados.
Àqueles profissionais que desejam desenvolver essa função, é necessário não se 
assustar diante de áreas complexas e desconhecidas como a que ilustraremos a seguir. Ao 
contrário: essa situação deve ser familiar no sentido de que será o arquiteto de software 
que irá traduzi-la num modelo bem construído, robusto e compreensível para todos os 
envolvidos no projeto.
1.4.1. Exemplo de aplicação
Para compreender, de um modo prático e 
aplicado, a Arquitetura de Software e o traba-
lho do profissional que o desenvolve, podemos 
pensar em um novo projeto fictício de sistema: 
a criação de um software de gestão do primeiro 
laboratório de aceleração de partículas do Brasil.
Não é necessário entender da avançada 
Física envolvida neste empreendimento – ace-
lerar partículas subatômicas e colidi-las para ©
 d
om
in
ik
a 
za
rz
yc
ka
 / 
/ S
hu
tt
er
st
oc
k.
30
estudar elementos que as compõem – para compreender que se trata de um projeto de 
software totalmente novo. Para esse projeto, não temos uma arquitetura de referência no 
Brasil – é o primeiro laboratório nacional do tipo – nem no exterior, uma vez que, pelo fato 
de o projeto ser altamente estratégico e uma área de ponta na ciência, essas questões são 
tratadas como segredo absoluto, por vezes por políticas do próprio país.
Num cenário como esse, o papel do arquiteto de software tem grande relevância, 
pois não é razoável que se parta diretamente para etapas de desenvolvimento, monta-
gem de equipe, distribuição de tarefas etc. Antes disso, é fundamental que seja concebido 
um design geral do que será necessário, quais são os componentes de software que serão 
necessários, as devidas conexões, as necessidades dos stakeholders etc.
O profissional dessa área irá se deparar com diversos desafios, uma vez que, prova-
velmente, não haverá familiaridade nenhuma dele com a área específica e pouco material 
de referência. Por isso, as reuniões, discussões e negociações com os stakeholders serão 
fundamentais para o sucesso dessa etapa de planejamento, bem como das fases posterio-
res do desenvolvimento.
1.4.2. Custo e benefícios 
Obviamente, esse projeto terá custos. Primeiramente, a própria necessidade de con-
tratação do arquiteto de software (se esse profissional não fizer parte da equipe) será um 
necessário dispêndio, porém não o único. Certamente, dada a complexidade do projeto e 
da atividade, não será algo a ser resolvido em questão de poucos dias ou semanas.
Neste exemplo, não seria nenhuma surpresa se o adequado desenvolvimento da 
arquitetura deste software levasse alguns meses para ser concluído. Obviamente, o tempo 
é um recurso importante e custoso, que seria dispensado nessa etapa. Além disso, é pre-
ciso considerar que o restante da equipe pouco poderá fazer enquanto essa fase não esti-
ver concluída, podendo incidir em custos adicionais se essa equipe não estiver alocada em 
outro projeto nesse período.
Mas, apesar de tudo, os benefícios justificam esse custo. Num projeto de grande 
complexidade, como é o caso deste exemplo, são muito grandes as chances de insucesso 
se esta etapa for pulada. Pode-se imaginar que o sistema, se for desenvolvido de forma 
inadequada, não atenderá a algumas funções, fazendo com que alguma atribuição opere 
de maneira imprópria ou com que tamanha falha de integração torne necessário voltar 
às fases iniciais de concepção. Obviamente isso representaria um custo e um risco muito 
maior, que não merecem ser incorridos.
31
Ao desenvolver sua missão, o arquiteto de software pode tomar o teorema ou prin-
cípio de Pareto, que, muito resumidamente, estabelece uma relação 20/80 entre causa e 
efeito. Nesse contexto, podemos imaginar que 20% dos componentes responderão por 
80% das funções do sistema em nosso exemplo. Assim, é razoável inferir que o profissional 
deve estar focado em identificar esses elementos-chave e em uma especificação mais cui-
dadosa desses elementos, deixando os demais num plano um pouco menos relevante.
Contexto
O teorema ou princípio de Pareto possui diversas aplicações em várias áreas, e sua 
justificativa é bem mais ampla do que esta aqui apresentada. Você pode conhecer mais esse 
teorema na obra O Princípio 80/20 - Os Segredos Para Conseguir Mais Com Menos Nos Negó-
cios e na Vida (KOCH, 2015).
A principal forma de apresentar uma arquitetura de software se dá por meio de um 
modelo visual, tendo em vista o quanto ele facilita a compreensão e a transmissão das 
informações gerais de um dado projeto de desenvolvimento de software. 
1.4.3. Modelo Visual do Sistema (MVS)
Para executar adequadamente um projeto, a utilização de uma modelagem visual 
é um recurso extremamente útil, pois facilita a abstração e reflexão, bem como funciona 
como uma boa base para as discussões com os diversos stakeholders envolvidos (cientistas, 
professores, fontes financiadoras, ministério da ciência e tecnologia, universidades etc.).
©
 L
eo
W
ol
fe
rt
 / 
/ S
hu
tt
er
st
oc
k.
https://www.shutterstock.com/pt/g/leowolfert
32
Essa Modelagem Visual do Sistema (MVS) possui diversas abordagens, sendo que 
cada uma pode ser mais adequada a determinados contextos. Porém, nesta disciplina, 
basta entender o conceito geral, de uma representação que abranja os principais elemen-
tos que precisarão ser atendidos pelo sistema. Essa modelagem pode ter um foco maior 
nos processos ou nos módulos/unidades, ser mais detalhado ou resumido, panorâmico ou 
analítico. Cada necessidade irá moldar o modelo visual que o representa.
Todavia, em todos os casos, deve-se levar em consideração que a modelagem de um 
sistema precisa ser suficientemente resumida para ser útil. Como exemplo, pode-se pen-
sar em uma maquete em escala natural (ou seja, em tamanho real): exceto em casos bem 
específicos, isso seria inútil, pois se perderia justamente a maior utilidade da maquete, que 
é uma visão geral e panorâmica de um dado local ou construção, em um tamanho redu-
zido. Por analogia, assim deve ser uma visão geral de um modelo visual do software.
O exemplo da criação de um software de gestão do primeiro laboratório de acelera-
ção de partículas do Brasil, por ser complexo, não permite que, no escopo deste capítulo, 
construamos um MVS realista, pois precisaríamos, antes, explorar as diversas particulari-
dades da área, do projeto do laboratório, necessidades dos stakeholders etc. Entretanto, é 
possível ilustrá-lo no esquema a seguir.
Representação de um possível MVS para o caso de uso em análise
Controle
autenticação
e acesso aos
sistemas
Registro de
ponto e gestão
de folha
Equipamentos
de controle de
acesso físico
Equipamentoscientíficos
Cadastro e
gerenciamento
de acesso
Coleta e análise
de dados
Sistemas
nativos dos
equipamentos
Controle e
monitoramento
das instalações
Administração
geral
Gestão
financeira,
de compras e
despesas
Módulo de
manutenção
Gestão de
documentos
Gestão
financeira,
de compras e
despesas
©
 D
TC
O
M
33
Obviamente, dada a complexidade, o modelo visual anterior não passa de um 
modesto rascunho. Todavia, poderia constituir-se como uma base inicial para o desenvolvi-
mento real, a partir da interação com os stakeholders envolvidos e uma maior compreensão 
dos desafios propostos.
Proposta de Atividade
Reforce seu aprendizado com o exercício sugerido a seguir. A atividade não é avaliativa, 
mas é uma boa oportunidade para testar seus conhecimentos e fixar o conteúdo estudado no capítulo.
Agora é a hora de recapitular tudo o que você aprendeu neste capítulo! Elabore, em MVS 
(Modelo Visual de Sistema), um esboço de uma Arquitetura de Software para um sistema 
de bibliotecas em uma universidade, procurando destacar as principais ideias abordadas ao 
longo do capítulo, relacionando-as com essa elaboração. Ao produzir sua proposta de arqui-
tetura, considere as leituras básicas e complementares realizadas. 
Recapitulando
Ao longo do capítulo, estudamos que a Arquitetura de Software é um elemento de 
suma importância em qualquer projeto de desenvolvimento de software, pois se trata, em 
linhas gerais, de uma abstração geral do sistema que será desenvolvido, definindo compo-
nentes e conexões que o formarão.
Além disso, seu desenvolvimento e a dedicação de uma ou mais pessoas para essa ati-
vidade pode ensejar custos, justificados pelos benefícios que o seguem, em especial o fato de 
permitir um fluxo mais ordenado e assertivo para as etapas de programação que o seguirão.
Também estudamos que o arquiteto de software é o profissional responsável por essa 
etapa do processo, cabendo a ele a habilidade de abstrair as necessidades dos diversos 
stakeholders. Isso tudo, somado aos seus conhecimentos técnicos e requisitos do projeto, 
construirá o modelo que guiará as fases subsequentes.
Por fim, vimos que a presença desse profissional costuma estar associado à projetos 
de maior complexidade ou empresas com grande volume de projetos simultâneos.
34
Referências 
ARQUITETURA. In: WEISZFLOG, W. Michaelis Moderno Dicionário da Língua Portu-
guesa. 2004. São Paulo: Moderna. Disponível em: <michaelis.uol.com.br>. Acesso em: 
09/11/2018.
BASS, L.; CLEMENTES, P.; KAZMAN, R. Software Architecture in Practice. 2. ed. Boston: 
Addison-Wesley Professional, 2003.
FOWLER, M. Padrões de Arquitetura de Aplicações Corporativas. 1. ed. Porto Alegre: 
Bookman, 2006.
FUNDAÇÃO Oscar Niemeyer. Museu Oscar Niemeyer. Disponível em: <www.niemeyer.
org.br/obra/pro513>. Acesso em: 13/11/2018.
KOCH, R. O Princípio 80/20 - Os Segredos Para Conseguir Mais Com Menos Nos Negócios 
e na Vida. 1. ed. Belo Horizonte: Gutenberg, 2015.
LARMAN, C. Utilizando UML e Padrões: uma introdução à análise e ao projeto orientado 
a objetos. 3. ed. Porto Alegre: Bookman, 2007.
LIONS, J.-L. ARIANE 5: Flight 501 Failure. 1996. Disponível em: <www.sunnyday.mit.edu/
nasa-class/Ariane5-report.html>. Acesso em: 31/10/2018,
UZUN, B.; TEKINERDOGAN, B. Model-driven architecture based testing: A systematic 
literature review. 2018. Information and Software Technology, 30-48. Disponível em: <doi.
org/10.1016/j.infsof.2018.05.004>. Acesso em: 12/11/2018.
35
OBJETIVOS DO CAPÍTULO
• Documentar uma arquitetura e diferenciar modelo, framework, estilos e padrões
utilizando as visões arquiteturais do modelo 4+1.
CAPÍTULO 2
O modelo 4 + 1 
Sidartha Azevedo Lobo de Carvalho
TÓPICOS DE ESTUDO
1 Diferentes conceitos 3
Documento de Arquitetura de 
Sistema (DAS)
• Modelo de referência.
• Framework.
• Estilos.
• Padrões.
• Visão geral.
• Como utilizar.
2 4+1 e a visão de cenários de uso
• Visão lógica.
• Visão de processo.
• Visão física.
• Visão de desenvolvimento.
36
Contextualizando o cenário
A arquitetura de software é utilizada para definir a organização dos elementos de um sis-
tema e suas propriedades. Normalmente, ela define a disposição dos requisitos não funcio-
nais da aplicação e também a disposição dos relacionamentos entre seus elementos.
Como às vezes os requisitos são conflitantes, a arquitetura de software visa balanceá-los da 
melhor maneira para que o sistema seja implementado da forma correta. Nesse sentido, as 
diferentes visões fornecem formas de organizar os elementos do sistema.
Para balancear os requisitos, em 1995, Krushten desenvolveu um modelo de visão arquitetu-
ral denominado 4+1. Esse modelo tem como objetivo principal fornecer visões em diferentes 
perspectivas do software, permitindo que cada visão foque em um determinado conjunto de 
características.
Dito isso, surge a questão: Como funcionam as visões de Krushten? E como elas auxiliam 
a arquitetura de software?
37
2.1. Diferentes conceitos
A arquitetura de um software consiste no mapeamento dos requisitos para que 
se cumpra o objetivo do sistema em questão. Essa arquitetura deve contemplar tanto os 
requisitos funcionais como os não funcionais. 
Para se chegar a arquitetura de software de um sistema, podemos partir de uma 
arquitetura de referência para o domínio específico da aplicação, ou seja, podemos usar 
uma arquitetura já pronta que contém os principais conceitos necessários para a constru-
ção do sistema em questão. A figura a seguir ilustra a relação entre os conceitos que ire-
mos abordar nessa seção:
Modelo de
referência
Estilos de
arquitetura
Arquitetura de
referência
Arquitetura de
software
Padrões
Os estilos de arquitetura são compostos principalmente por padrões de software. 
Esses estilos, juntamente com o modelo de referência, resultam na arquitetura de refe-
rência, que, por sua vez, serve de base para a construção da arquitetura de software.
Para que esses conceitos fiquem claro, nos próximos tópicos iremos detalhar os mode-
los de referência de uma arquitetura, a utilidade e o uso dos frameworks, além dos estilos e 
padrões empregados nas fases de arquitetura durante a construção de um software.
2.1.1. Modelo de referência
O modelo de referência é formado pela decomposição padronizada do problema (con-
ceitos/funcionalidades do sistema/arquitetura formados a partir do modelo), abordado em 
partes menores para formar a solução. Esses problemas são definidos a partir da colaboração 
de diversos especialistas que percebem que ele é recorrente no domínio. Após esse processo 
de amadurecimento da solução, temos o modelo de referência (KRUCHTEN, 1995).
©
 D
TC
O
M
38
Ainda segundo Kruchten (1995), a arquitetura de referência é um tipo especial de 
arquitetura de software. Essa última, como é mais genérica e definida em um alto nível de 
abstração, permite incluir as regras de negócio, os estilos e os padrões arquiteturais.
A arquitetura de referência, portanto, se difere da arquitetura de software por não 
possuir um grupo bem definido das partes interessadas. Ou seja, nesse tipo de arquitetura, 
o sistema encontra-se em uma fase inicial, sendo algumas entidades e relacionamentos
ainda desconhecidos.
Pode-se dizer que a arquitetura de referência objetiva garantir mais atributos de 
qualidade arquitetural e, além disso, permite que os requisitos não funcionais sejam res-
peitados. Assim, elas são projetadas para serem aplicadas a um domínio particular, sendo 
construídas a partir de um estudo do domínio ao invés de um sistema já existente. 
Os frameworks, por sua vez, são instrumentos utilizados para prover o reuso de 
código/funcionalidades para o desenvolvimento de aplicações mais específicas. Assim, um 
framework é a implementação das arquiteturas de referência para a resolução de proble-
mas específicos.
No próximo tópico iremos detalhar melhor os frameworks no contexto da arquitetura 
de software.
©
 K
it
8.
ne
t /
/ S
hu
tter
st
oc
k
39
2.1.2. Framework
Um framework de arquitetura repre-
senta um conjunto de componentes que 
são utilizados para criar uma determinada 
arquitetura. O uso desses frameworks é pri-
mordial para acelerar o desenvolvimento de 
sistemas, uma vez que eles auxiliam na abs-
tração de complexidades quanto à infraes-
trutura e outras características complexas. 
Segundo Pressman (2011, p. 40):
Uma metodologia (framework) de processo estabelece o alicerce para um processo de 
engenharia de software completo, por meio da identificação de um pequeno número 
de atividades estruturais aplicáveis a todos os projetos de software, independente-
mente de tamanho ou complexidade. Além disso, a metodologia de processo engloba 
um conjunto de atividades de apoio (umbrella activities — abertas) aplicáveis em todo 
o processo de software.
Pode-se dizer, portanto, que a utilização de frameworks auxilia na composição de 
novas arquiteturas, uma vez que eles apresentam uma estrutura preestabelecida e tornam 
a arquitetura mais padronizada. 
Uma categoria bastante utilizada são os frameworks para desenvolvimento web e 
mobile. Veja alguns exemplos:
• ASP.NET: ASP.NET Dynamic Data, ASP.NET MVC, ASP.NET Web Forms, BFC,
DotNetNuke, MonoRail, OpenRasta e Umbraco.
• JAVA: AppFuse, Flexive, Grails, GWT, ICEfaces, ItsNat, JavaServer Faces, Jspx,
Juzu, dentre outros.
• JavaScript: Ample SDK, AngularJS, Backbone.js, Chaplin.js, jQuery, Wakanda,
dentre diversos outros.
Os frameworks mais utilizados pela indústria de software, por outro lado, são o 
TOGAF e o ZACHMAN, sendo específicos para a construção de arquiteturas em diferentes 
níveis de abstração.
Esse é um pequeno exemplo da quantidade de frameworks disponíveis para as dife-
rentes linguagens. Cada um tem suas especificidades e são melhor aproveitados depen-
dendo do contexto e do domínio da aplicação. No próximo tópico iremos detalhar melhor 
os estilos arquiteturais.
©
 S
in
ar
t C
re
at
iv
e 
// 
Sh
ut
te
rs
to
ck
40
2.1.3. Estilos
O estilo de arquitetura é um atributo das arquiteturas de software. Esse atributo 
impõe algumas regras que devem ser seguidas para garantir a uniformidade na arquitetura. 
Segundo Kruchten (1995), um estilo arquitetural pode ser representado como a 
agregação de um conjunto de características que são repetidas em diversos sistemas, ou 
seja, um conjunto de escolhas já feitas que serão aplicadas na construção de novas arquite-
turas. Um sistema que adere a um determinado estilo, nesse sentido, herda as característi-
cas do estilo escolhido, sendo utilizados para descrever aquela arquitetura.
Esclarecimento
Uma determinada arquitetura pode aderir a mais de um estilo arquitetural, con-
tendo características de diferentes estilos. 
O estilo é definido como um conjunto de padrões, componentes ou conectores que 
funcionarão como a base de uma arquitetura. Os estilos são utilizados para expressar 
esquemas da organização estrutural dos sistemas, fornecendo um mapeamento dos com-
ponentes do sistema, além de suas responsabilidades e interações (KRUCHTEN, 1995).
Cada estilo arquitetural trabalha com diferentes tipos de atributos de qualidade e, 
para saber se o estilo é adequado à construção de uma determinada arquitetura, deve-se 
confrontar os atributos mais relevantes da solução com os atributos do estilo. 
Pausa para refletir
Como o estilo arquitetural está relacionado ao processo de construção da arquitetura de 
software?
Como exemplo de estilo, podemos citar o modelo Cliente-Servidor. Nesse caso, a 
palavra modelo e estilo são usadas como sinônimos.
O Cliente tem como atribuição principal fazer pedidos ao servidor e esperar as res-
postas desses pedidos. Um pedido é uma requisição de um cliente (usuário, outro sis-
tema, dentre outros) para um servidor de dados ou aplicações requisitando algum dado. 
Após receber as respostas, o cliente pode realizar o processamento desejado com os dados 
41
recebidos. Ele geralmente se conecta a um número pequeno de servidores simultanea-
mente e faz uso de recursos de rede. Quando não definido previamente, é comum que essa 
interação entre cliente e servidor utilize um protocolo sem muita padronização estabele-
cida pelo desenvolvedor.
Por outro lado, cabe ao Servidor esperar um pedido de requisição por parte do 
cliente. Assim, ele deve estar sempre preparado para receber solicitações. Geralmente é 
criada uma classe principal, que fica executando dentro de um laço infinito, só para receber 
as requisições. Ao receber uma solicitação, o servidor abre uma thread de execução com a 
requisição e volta a esperar novas requisições. 
Esclarecimento
Uma thread de execução é uma linha de execução distinta da execução atual do 
programa, ou seja, que executa em paralelo.
O servidor pode se conectar a outros servidores ou a diversos bancos de dados para 
responder a requisição do cliente. Além disso, ele deve contar com uma boa infraestrutura 
de hardware, mensurada de acordo com a previsão de requisições que irá atender. 
A figura a seguir ilustra esse estilo arquitetura:
Modelo Cliente Servidor
Clientes
Servidor
A seguir, observe a série de vantagens que o estilo de arquitetura Cliente-Servidor 
apresenta:
©
 V
as
ut
in
Se
rg
ey
 //
 S
hu
tt
er
st
oc
k
42
• Apresenta uma divisão clara de papéis e responsabilidades, o que facilita a
manutenção;
• Possibilita a conexão com vários servidores em rede, aumentando a escalabilidade
do sistema;
• Investe mais em segurança, uma vez que apresenta uma estrutura centralizada.
Isso permite que os canais de entrada e saída de dados sejam visualizados de
forma clara, bem como o gerenciamento de acessos.
• Facilita a atualização de dados. Isto porque, como a maioria do processamento é
feita pelo servidor, não há necessidade de clientes com alto poder de processa-
mento ou armazenamento.
A arquitetura Cliente-Servidor também possui algumas desvantagens. Pode haver 
sobrecarga no servidor em determinadas situações em que o fluxo de requisições é maior 
que o normal, por exemplo. Portanto, é importante estimar de forma correta o fluxo de 
dados para que essa sobrecarga não aconteça. Outro problema recorrente nesse tipo de 
arquitetura é o ponto de falha centralizado. Se o servidor principal fica indisponível, por 
exemplo, todos os clientes ficam sem poder acessar o serviço se não houver servidores 
adicionais.
Outro exemplo de estilo arquitetural é o modelo Peer to Peer, “concorrente” direto 
do estilo arquitetural Cliente-Servidor. Nesse modelo, a conexão entre os elementos é reali-
zada de forma não centralizada, sendo cada nó da rede independente para emitir, rotear e 
receber dados.
Quando comparado ao estilo Cliente-Servidor, o Peer to Peer possui uma distribuição 
horizontal, enquanto o Cliente-Servidor conta com uma distribuição vertical. Por um lado, 
um sistema de distribuição vertical facilita o gerenciamento, uma vez que divide as respon-
sabilidades de processamento entre várias máquinas. Em contrapartida, uma distribuição 
horizontal, como a utilizada na abordagem Peer to Peer, divide o processamento entre os 
clientes e servidores. 
Assim, podemos dizer que na distribuição horizontal, todas as funções necessárias 
para o processamento e roteamento de dados devem estar presentes em todos os clientes 
e em todos os servidores. Ou seja, todo cliente e todo servidor pode atuar como cliente ou 
como servidor dependendo do processamento a ser realizado.
Os sistemas Peer to Peer não dependem da existência de alguma entidade centrali-
zada, seja para processamento ou para administração. Nesse sentido, nos sistemas decen-
tralizados desse estilo arquitetural, todos os nós são iguais, não havendo nenhum especial 
para administração ou descoberta de serviços. No entanto, há alguns nós especiais para 
43
gerenciamento dos demais nós, não sendo totalmente descentralizados, por exemplo, o 
aplicativo BitTorrent que faz uso do protocoloTorrent.
No próximo tópico iremos discorrer sobre os padrões de software. Como os padrões 
podem ser de projeto, de arquitetura, entre outros, iremos aborda-los de forma genérica 
para depois focar em um nicho específico.
2.1.4. Padrões
Os padrões da engenharia de software permitem que os desenvolvedores façam uso 
de soluções já existentes para problemas recorrentes no desenvolvimento de uma aplicação. 
Nesse sentido, podemos ter padrões de arquitetura de software, padrões de análise, padrões 
de projeto, padrões de teste, padrões de implementação, dentre outros. (GAMMA, 2000).
Assim, os padrões de projeto dispõem de um 
esquema para melhoramento de componentes ou sub-
sistemas de um sistema (GAMMA et al., 2000). Já os 
padrões arquiteturais expressam a organização funda-
mental para uma estrutura.
Um padrão deve conter as seguintes informa-
ções: nome do padrão, contexto, problemática e solu-
ção. A seguir, temos um exemplo de um padrão, 
chamado de Broker (KRUCHTEN, 1995).
Nome: Broker
Contexto: Ambiente distribuído
Problemática: Auxilia na definição dos meios de comunicação entre os componentes 
de um sistema.
Solução: É necessário criar um intermediário entre o cliente e o servidor. O cliente 
envia uma mensagem para o intermediário (Broker) contendo todas as informações 
para que a comunicação seja efetuada. 
Para a definição dos padrões de arquitetura, Pressman (2011) sugere que o docu-
mento deve conter as seguintes informações: 
• Problema de Projeto: apresenta os problemas que a arquitetura está tentando
resolver, definidos de forma clara e não ambígua.
• Resolução: apresenta a abordagem escolhida como a melhor para resolver o
problema.
©
 M
ac
ro
ve
ct
or
 //
 S
hu
tt
er
st
oc
k
44
• Categoria: descreve o projeto de dados, a estrutura de conteúdo, a comunicação,
além da integração e da apresentação dos componentes.
• Hipóteses: apresenta as propostas que podem ajudar na resolução do problema.
• Alternativas: apresenta alternativas de projeto da arquitetura e o motivo da rejei-
ção dessas alternativas.
• Argumento: descreve as justificativas de escolha da arquitetura.
• Implicações: descreve as consequências de uso da arquitetura no projeto, devendo
responder como tal escolha pode afetar outras partes do projeto.
• Decisões relacionadas: descreve quais outras decisões foram tomadas ou cogitadas.
• Necessidades relacionadas: descreve outras necessidades relacionadas à arquite-
tura proposta.
• Artefatos: descreve os artefatos que sofrerão mudanças em decorrência das deci-
sões tomadas.
• Notas: apresenta, de forma geral, as anotações da equipe que não foram contem-
pladas nos tópicos anteriores, mas que podem ser acrescentadas.
No próximo tópico iremos detalhar o modelo proposto por Kruchten, o modelo 4+1.
2.2. 4+1 e a visão de cenários de uso
Nos tópicos anteriores, vimos os conceitos relacionados as arquiteturas de forma 
geral, sem utilizar um modelo específico para representar essa arquitetura. Agora iremos 
aprofundar nosso conhecimento utilizando um modelo bastante difundido, chamado 4+1, 
desenvolvido por Philippe Kruchten em 1995. Nesse modelo, é descrito diferentes visões 
de uma mesma arquitetura para melhor compreender suas características.
Biografia
Philippe Kruchten, nascido em 1952, é um engenheiro de software canadense. Ele 
também é professor na universidade British Columbia em Vancouver, Canadá. Em 1995, Philippe 
desenvolveu o modelo de visão arquitetural 4+1 (UNIVERSITY OF BRITISH COLUMBIA, 2018). 
45
O modelo 4+1 fornece diferentes perspectivas de visualização da arquitetura. Assim, 
ele é composto por cinco visões distintas, sendo elas: a visão lógica, a visão de processo, 
a visão física, a visão de desenvolvimento e a visão utilizando cenários, como ilustra o 
esquema a seguir:
Visão lógica
Visão de
processo
Visão física
Visão de
desenvolvimento
Cenários
Fonte: Adaptado de Kruchten,1995, p. 2 
As quatro visões ilustradas dentro do retângulo devem trabalhar de forma conjunta e 
ser descritas pelos casos de uso mais gerais (cenários). Os cenários, por sua vez, são abstra-
ções dos requisitos mais importantes da arquitetura e são expressos utilizando objetos que 
compõem o sistema que está sendo modelado.
O termo “4+1” se dá pelo fato desse modelo contar com quatro visões distintas e, ao 
final, utilizar os casos de uso (+1) para ilustrar as demais visões. Esses cenários de caso de 
uso, nesse sentido, exploram os elementos de arquitetura durante sua construção e servem 
de instrumento de validação e ilustração após a finalização da construção da arquitetura. 
Nos próximos tópicos iremos descrever em detalhe cada visão desse modelo.
2.2.1. Visão lógica
A visão lógica é o design do modelo de objetos para sistemas orientados a objetos. 
Nela, o sistema é composto por um conjunto de abstrações retiradas principalmente do 
domínio do problema, fornecendo suporte às funcionalidades que os usuários necessitam 
(KRUCHTEN, 1995).
Ainda segundo Kruchten (1995), essa etapa de modelagem da visão lógica serve para 
identificar os possíveis elementos que podem ser reutilizados dentro de todo o sistema. 
Um método que verifica a autenticidade de um usuário, por exemplo, pode ser repetido em 
diversas páginas web.
©
 D
TC
O
M
46
A visão lógica utiliza diagramas de classe, mostrando um conjunto de classes e suas 
relações. A partir desse conjunto, pode ser definido um template de classe, utilizado para 
definir operações principais e identificar os objetos chave (KRUCHTEN, 1995). Além disso, 
temos o diagrama do estado de transição, utilizado para representar o comportamento 
interno de um objeto. 
A seguir, a figura ilustra a representação dos componentes do modelo da visão lógica:
Componentes 
Classe
Classe de
utilidade 
Classe
parametrizada 
Categoria
de classe
Conectores
Associação 
Agregação
Uso
Herança 
Instanciação
Fonte: adaptado de Kruchten, 1995, p. 3.
Dando continuidade ao modelo 4+1, no próximo tópico iremos descrever a visão de 
processo deste modelo.
2.2.2. Visão de processo
A visão de processo visa encaixar as principais abstrações da visão lógica no processo 
arquitetural, endereçando preocupações diferentes. Ou seja, nessa visão é a feita a decom-
posição do sistema através do mapeamento das classes e dos subsistemas. Nessa visão, 
também são levados em consideração alguns requisitos não funcionais, como desempenho 
e disponibilidade.
O processo é o agrupamento de tarefas que forma uma unidade executável. Assim, 
os processos representam o nível de abstração do processamento computacional que 
pode ser controlado, sendo iniciado, recuperado, reconfigurado ou desligado, por exemplo 
(KRUCHTEN, 1995). 
Uma tarefa é uma thread de execução separada que pode ser escalonada individual-
mente (TANENBAUM, 2003). Essas tarefas podem ser diferenciadas pelo tamanho da 
tarefa. Enquanto as tarefas maiores podem ser elementos arquiteturais e identificadas de 
forma única, as tarefas menores sempre são implementações locais. 
©
 D
TC
O
M
47
A figura abaixo identifica os elementos utilizados na criação da arquitetura na visão 
de processo.
Componentes 
Processo
Processo
simplificado 
Processo
periódico 
Conectores
Sem especificação 
Mensagem 
Chamada de procedimento remoto
Mensagem bidirecional
Evento de broadcast
Fonte: Adaptado de Kruchten,1995, p. 5.
Dando continuidade ao estudo do modelo 4+1, iremos estudar a visão física na pró-
xima seção.
2.2.3. Visão física
A visão física permite o mapeamento do software para o hardware. Ela foca princi-
palmente nos requisitos não funcionais do sistema, como disponibilidade, tolerância a 
falhas, desempenho e escalabilidade. Quando o software executa em uma rede de compu-
tadores, por exemplo, os vários elementos identificados podem ser: redes, processos, tare-
fas e objetos. Esses elementos identificados são mensurados para garantir os requisitos 
não funcionais. (KRUCHTEN,1995). 
Além disso, nessa visão, espera-se que diferentes configurações físicas sejam utiliza-
das, como configurações de desenvolvimento e testes e de depuração do sistema.
Pausa para refletir
Como a visão física se relaciona com as demais visões do modelo 4+1?
O mapeamento do software para os nós tem que ser feito de forma altamente flexí-
vel e gerar impacto mínimo no código fonte. O diagrama UML que representa a visão física 
é o diagrama de implementação (deployment diagram). A figura a seguir ilustra os elemen-
tos da visão física:
©
 D
TC
O
M
48
Componentes
Processador 
Outros dispositivos
Conectores
Comunicação
Comunicação não
permanente 
Comunicação direcional
Alta banda de utilização de
comunicação
Fonte: adaptado de Kruchten, 1995, p. 5.
Até o momento já vimos três das visões do modelo 4+1. Agora, dando continuidade, 
iremos estudar, no próximo tópico, a visão de desenvolvimento.
2.2.4. Visão de desenvolvimento
A visão de desenvolvimento foca nos módulos do software voltados para a orga-
nização. O software é particionado em pequenos módulos que podem ser bibliotecas ou 
subsistemas. Cada módulo pode ser desenvolvido por um ou mais desenvolvedores. Os 
subsistemas, por sua vez, são organizados de forma hierarquia, e cada nível da hierarquia 
provê uma interface bem definida para os níveis próximos (KRUCHTEN, 1995).
Ainda segundo Kruchten (1995), a arquitetura de desenvolvimento somente pode ser 
descrita em sua completude quando todos os elementos de software são identificados. 
Essa visão serve como uma base para: alocação de requisitos, alocação e organização 
de trabalho de equipes, avaliação e planejamento de custos, monitoramento do progresso 
do projeto, reutilização de software, portabilidade e segurança. Ou seja, ela é a base para o 
estabelecimento de uma linha de produto. 
A figura a seguir ilustra os componentes dessa visão:
©
 D
TC
O
M
49
Componentes Conectores 
Módulo
Subsistema
Camada
Dependência
Fonte: adaptado de Kruchten, 1995, p. 7.
Agora que finalizamos o estudo quanto às visões do modelo 4+1, vamos exemplificar 
como documentar essas visões em um documento de arquiteturas.
2.3. Documento de Arquitetura de Sistema (DAS)
O Documento de Arquitetura de Siste-
mas (DAS) é o documento utilizado para o armaze-
namento das arquiteturas criadas para o sistema 
projetado. Assim, todas as visões são agrupadas, 
simplificando o acesso à todas as arquiteturas.
Desse modo, o DAS apresenta uma perspec-
tiva geral das visões e utiliza arquiteturas específicas 
para ilustrar os diversos aspectos do sistema. Com 
isso, objetiva-se disponibilizar as decisões que foram 
tomadas durante o projeto de arquitetura do sistema. 
No próximo tópico, iremos descrever em linhas gerais o que esse documento deve 
conter. 
2.3.1. Visão geral
Segundo o RUP for Value Creation ([s.d]), o DAS deve seguir uma certa padronização, 
sendo necessário conter os seguintes tópicos:
©
 D
TC
O
M
©
 v
la
dw
el
 //
 S
hu
tt
er
st
oc
k.
50
• Introdução: Deve conter os objetivos, o escopo, as definições necessárias, os acrô-
nimos, as abreviações, as referências e a visão geraldo documento.
• Representação Arquitetural: descreve, em linhas gerais, a arquitetura de soft-
ware do sistema e como ela está sendo representada. Deve conter os casos de uso,
a implementação, o processo, a lógica e as visualizações de implementação.
• Restrições e Metas arquiteturais: Deve conter os requisitos e os objetivos do soft-
ware que possam gerar impacto sobre a arquitetura. Por exemplo: segurança, dis-
ponibilidade, privacidade, reuso de software e portabilidade.
• Visão de Casos de Uso: Deve conter os casos de uso ou cenários e a representação
das funcionalidades gerais do sistema.
• Visão Lógica: Deve conter uma visão geral, como os pacotes de design significati-
vos do ponto de vista arquitetural e os casos de uso relevantes para a visão lógica.
• Visão de Processos: deve descrever a decomposição do sistema em processos,
organizados em grupos. Os grupos devem ser formados levando em consideração
a interação entre os processos, mantendo os mais comunicantes próximos uns aos
outros.
• Visão da Implementação: deve conter a estrutura geral do modelo de implemen-
tação, bem como a divisão do software em camadas e subsistemas.
• Tamanho e Desempenho: deve conter uma descrição das principais características
do sistema, focando em seu tamanho e nas restrições de desempenho.
• Qualidade: deve apresentar uma descrição de como a arquitetura do software
contribui para todos os recursos (exceto para a funcionalidade) do sistema.
Agora que já vimos como o DAS é estruturado, no próximo tópico iremos finalizar 
este capítulo descrevendo como utilizar o DAS em um projeto de software.
2.3.2. Como utilizar
Como estudado, a arquitetura de um software é um artefato essencial para a produ-
ção de um bom sistema. Agora, para organizar essas arquiteturas em um único documento 
e prover acesso centralizado a todos os interessados no negócio, utiliza-se o DAS – descrito 
no tópico anterior. A seguir, portanto, iremos descrever como e quando utilizar esse inte-
ressante artefato de software.
51
O DAS deve ser preenchido com os artefatos gerados no momento de modelagem 
do sistema em produção, como nas diferentes arquiteturas geradas usando as visões do 
modelo 4+1. Cada tópico que compõe a estrutura do DAS deve ser escrito com as caracte-
rísticas específicas do software em construção.
Após colocar cada arquitetura em seu tópico específico e preencher as demais carac-
terísticas do software, é preciso sintetizar essas visões arquiteturas utilizando os casos de 
uso específicos.
Na sequência, após o preenchimento do DAS, é necessário disponibilizá-lo para todos 
os envolvidos na produção do software. Para tanto, podemos disponibilizar o DAS em 
uma pasta compartilhada com toda a equipe do projeto. Esse compartilhamento facilita a 
comunicação e melhora o entendimento do software que está sendo produzido. 
Proposta de Atividade
Reforce seu aprendizado com o exercício sugerido a seguir. A atividade não é avaliativa, 
mas é uma boa oportunidade para testar seus conhecimentos e fixar o conteúdo estudado no capítulo.
Agora é a hora de recapitular tudo o que você aprendeu nesse capítulo! Elabore um DAS uti-
lizando o modelo 4+1. Para tanto, crie diferentes visões para um sistema fictício. Ao produzir 
o DAS, aplique todo o conhecimento adquirido nos capítulos da disciplina. Considere as lei-
turas básicas e complementares realizadas para ampliar seu conhecimento.
Recapitulando
Nesse capítulo estudamos alguns conceitos importantes para a construção de arqui-
teturas de software. Dentre eles, resumimos a importância do modelo de arquitetura como 
uma forma de reutilizar uma arquitetura já pronta. Porém, como o modelo é genérico, res-
saltamos que é necessário adaptá-lo ao sistema que está sendo desenvolvido. 
Estudamos também o estilo de arquitetura, que define características próprias que 
devem ser seguidas para padronizar a arquitetura. Cada estilo possui características e atri-
butos que devem ser adequados ao problema a ser resolvido.
Além disso, também discorremos sobre os frameworks, que são implementações de 
componentes arquiteturais genéricos. Eles servem para auxiliar no processo de definição 
de novas arquiteturas, uma vez que possuem uma notação bem definida, permitindo a reu-
tilização de componentes. Ademais, os frameworks podem fazer uso de padrões e soluções 
já conhecidas para problemas recorrentes.
52
Também vimos a importância do modelo 4+1 e detalhamos cada uma de suas visões. 
Após esse detalhamento, pudemos observar que as visões desse modelo servem para criar 
abstrações da arquitetura do sistema, permitindo a visualização de informações únicas em 
cada arquitetura construída.
Por fim, estudamos o DAS, artefato de software que serve para documentar a arqui-
tetura criada de forma clara. Essedocumento visa ser disseminado para que toda a equipe 
possa visualiza-lo facilmente. 
53
Referências 
GAMMA, E. et al. Padrões de projeto: soluções reutilizáveis de software orientado a 
objetos. Porto Alegre: Bookman, 2000.
KRUCHTEN, Philippe. The “4+1” View Model of Software Architecture. IEEE Software. 
v. 12, n. 6, p. 42-50, nov. 1995.
RUP FOR VALUE CREATION. Artefato: Documento de Arquitetura de Software. Cen-
tro de Informática - UFPE. Disponível em: <www.cin.ufpe.br/~gta/rup-vc/extend.for-
mal_resources/guidances/templates/software_architecture_document_CE85F5AC.html>. 
Acesso em 20 de outubro de 2018.
PRESSMAN, S. R. Engenharia de Software: Uma Abordagem Profissional. 7 ed. Rio de 
Janeiro–RJ: McGraw-Hill, 2011.
TANENBAUM, A. S. Sistemas Operacionais Modernos. ed. 2. Pearson Prentice Hall. 2003.
UNIVERSITY OF BRITISH COLUMBIA. Electrical and Computer Engeneering. Disponível 
em: <www.ece.ubc.ca/faculty/philippe-kruchten>. Acesso em 23 de outubro de 2018.