Arquitetura de Software

Prévia do material em texto

Disciplina
Arquitetura de Software
Unidade 1
Introdução à arquitetura de software
Aula 1
Fundamentos de arquitetura de software
Introdução
Olá, estudante!
Boas-vindas à nossa aula sobre Fundamentos da Arquitetura de Software! Você está interessado
em aprender a projetar um software de alta qualidade que atenda às necessidades de seus
usuários? Quer aprender a usar a arquitetura de software para atingir esse objetivo? Junte-se a
mim para uma aula que explora os conceitos e princípios essenciais da arquitetura de software e
como ela pode ser usada para desenvolver o melhor software possível.
Você aprenderá sobre os conceitos fundamentais de arquitetura de software, o padrão ISO/IEEE
1471-2000 e muito mais. Ao �nal desta aula, você terá uma sólida compreensão dos
fundamentos da arquitetura de software e do padrão ISO/IEEE 1471-2000 e estará pronto para
uma visão mais afundo do tema!
Bons estudos! 
Disciplina
Arquitetura de Software
Conceitos fundamentais de arquitetura de software
Às vezes, quando pensamos em arquitetura de software, é comum fazer analogia com a
construção civil, pois também realizamos essa comparação com a engenharia de software com
as outras engenharias (ZENKER et al., 2019). A arquitetura de software é a base de qualquer
projeto de software bem-sucedido. Ela abrange o design de alto nível e a organização de um
sistema de software, e de�ne os relacionamentos e interações entre seus componentes.
Apesar de realizar analogias com a construção civil, para você, estudante, é importante entender
que a arquitetura de software não é uma área independente. Pressman e Maxim (2021, p. 253)
esclarecem que a arquitetura de software de um programa ou sistema computacional “abrange
os componentes de software, as propriedades externamente visíveis desses componentes e as
relações entre eles”.
Para Perry e Wolf (1992), a arquitetura de software é um conjunto de elementos arquiteturais
(dados, processamento e conexão), que estão organizados de certa forma. Essa organização é
de�nida por tomadas de decisões para contentar os objetivos e restrições. Pressman e Maxim
(2021, p. 182) destacam três principais razões pelas quais a arquitetura de software é
importante:
“A arquitetura de software fornece uma representação que facilita a comunicação entre
todos os envolvidos;
A arquitetura destaca desde o início as decisões de projeto que terão profundo impacto no
trabalho de engenharia de software que se segue;
Disciplina
Arquitetura de Software
A arquitetura constitui um modelo relativamente pequeno como os componentes do
sistema que estão estruturados e trabalham em conjunto.”
Para Pressman e Maxim (2021, p. 182) “o modelo de projeto de arquitetura e os padrões de
arquitetura são transferíveis, ou seja, representam um conjunto de abstrações que permitem aos
engenheiros de software descrever a arquitetura de modo previsível”.
Padrões de arquitetura
Um padrão de arquitetura resulta em uma transformação do projeto de arquitetura. Segundo
Pressman e Maxim (2021, p. 186), ele difere de um estilo em alguns modos fundamentais, como:
o escopo de um padrão é menos abrangente; um padrão impõe uma regra sobre a arquitetura,
descrevendo como o software vai tratar um aspecto de sua funcionalidade em termos de
infraestrutura; os padrões de arquitetura tendem a tratar de questões comportamentais e
especí�cas no contexto de arquitetura, por exemplo, aplicações em tempo real que tratam a
sincronização ou interrupções.
Nesta aula, abordaremos o padrão ISO/IEEE 1471-2000, também conhecida como “Prática
Recomendada para Descrição Arquitetural de Sistemas Intensivos em Software”. Ele fornece
uma estrutura para descrever e avaliar a arquitetura de um sistema de software, e de�ne os
seguintes termos:
Visão arquitetural: uma representação da arquitetura de um sistema a partir de uma
perspectiva particular ou ponto de vista das partes interessadas. Por exemplo, um
desenvolvedor pode usar uma visão de componente para descrever a estrutura do sistema,
enquanto um stakeholder do negócio pode usar uma visão funcional para descrever os
recursos do sistema.
Ponto de vista arquitetônico: uma especi�cação das convenções, regras e preocupações
que governam a construção, interpretação e uso de uma visão arquitetônica. Elas servem
para capturar as preocupações e interesses de diferentes partes interessadas no sistema.
Descrição da arquitetura: o conjunto de visualizações e pontos de vista arquitetônicos que
descrevem a arquitetura de um sistema. Ela deve ser uma descrição abrangente e coerente da
arquitetura do sistema.
Compreendendo a arquitetura de software
Disciplina
Arquitetura de Software
A arquitetura de software é como a planta de um prédio. Assim como um projeto que ajuda
arquitetos e construtores a entender como um prédio será construído, a arquitetura de software
permite que os desenvolvedores de software entendam como um sistema de software será
construído, o que deve ser seguido e como deve ser feito (ZENKER et al., 2019).
A arquitetura de software garante que as diferentes partes de um sistema de software funcionem
juntas adequadamente. É como um quebra-cabeça, com muitas peças diferentes que precisam
se encaixar perfeitamente (PERRY; WOLF, 1992). Por exemplo, se você estiver construindo um
sistema de software para uma loja, precisará garantir que o sistema de estoque, o sistema de
checkout e o sistema de pagamento funcionem conjuntamente sem problemas.
Uma boa arquitetura de software é importante porque garante que o sistema de software
funcione bem e seja fácil de manter. Assim como um prédio bem construído dura muito tempo,
um sistema de software bem projetado será mais con�ável e durará mais.
Compreendendo a arquitetura do software, os desenvolvedores podem garantir que o software
que construíram funcione bem e atenda às necessidades das pessoas que o utilizam. Também
os ajuda a se comunicar melhor com outras pessoas envolvidas na construção do software,
como designers, analista de negócios e/ou gerentes de produto.
O padrão ISO/IEEE 1471-2000 fornece uma estrutura para descrever e avaliar a arquitetura de
software. Ele de�ne diferentes perspectivas ou “visões” do sistema de software, dependendo dos
interesses e preocupações dos diferentes stakeholders. Por exemplo, um desenvolvedor de
software pode usar uma “visão de componente” para entender como as diferentes partes do
Disciplina
Arquitetura de Software
sistema serão construídas, enquanto uma parte interessada do negócio pode usar uma “visão
funcional” para entender como o sistema atenderá às necessidades dos usuários (ISO/IEEE,
2000).
O padrão ISO/IEEE 1471-2000 também de�ne princípios para uma boa arquitetura de software.
Isso inclui abstração, que signi�ca focar nas partes mais importantes do sistema;, separação de
interesses, que signi�ca dividir o sistema em partes menores que atendam a interesses
especí�cos; modularidade, que signi�ca organizar o sistema em módulos independentes; e
hierarquia, que signi�ca organizar o sistema em níveis de abstração.
Ao seguir o padrão ISO/IEEE 1471-2000, os desenvolvedores podem garantir que o software
criado por eles atenda aos altos padrões de qualidade e con�abilidade. Também os ajuda a se
comunicar melhor com outras pessoas envolvidas na construção do software. Compreendendo a
arquitetura de software e o padrão ISO/IEEE 1471-2000, os desenvolvedores podem criar
sistemas de software escaláveis, sustentáveis e que atendam às necessidades de seus usuários
e stakeholders. Eles também podem se comunicar efetivamente com outros stakeholders, como
proprietários de empresas, designers e outros desenvolvedores, usando uma linguagem e uma
estrutura comuns. 
Adotando o padrão ISO/IEEE 1471-2000
Disciplina
Arquitetura de Software
O padrão ISO/IEEE 1471-2000 para arquitetura de software fornece uma estrutura que os
desenvolvedores de software podem usar para projetar e construir sistemas de software
con�áveis e de alta qualidade (IEEE ARCHITECTURE WORKING GROUP et al., 2000). Seguindo o
padrão, desenvolvedorespodem criar softwares fáceis de manter, que atendam às necessidades
de seus usuários e sejam consistentes com as melhores práticas de desenvolvimento de
software.
Para aplicar o padrão ISO/IEEE 1471-2000, desenvolvedores devem seguir um conjunto de
etapas que servirão de orientação no processo de projeto e construção de um sistema de
software. São elas, (IEEE ARCHITECTURE WORKING GROUP et al., 2000):
Passo 1: entenda as diferentes visões da arquitetura de software
O padrão ISO/IEEE 1471-2000 fornece diferentes visões de arquitetura de software, que mostram
diferentes aspectos do sistema de software. Essas visões incluem:
A visão funcional, que mostra o que o software faz e como o faz.
A visão de componentes, que mostra como as diferentes partes do sistema estão
conectadas.
A exibição de implantação, que mostra como o software é instalado e usado.
Para aplicar o padrão, desenvolvedores devem entender cada uma dessas visões e como elas se
relacionam entre si.
Etapa 2: de�nir a arquitetura do software
Depois que os desenvolvedores entenderem as diferentes visões da arquitetura de software, eles
devem criar um plano de como o sistema de software funcionará. Isso envolve a de�nição dos
componentes do sistema, como eles interagem entre si e como serão implementados. Os
desenvolvedores podem usar as diferentes visualizações do padrão para ajudá-los a criar esse
plano.
Passo 3: avalie a arquitetura
Depois de criar um plano para o sistema de software, os desenvolvedores devem avaliá-lo para
garantir que atenda às necessidades do software. Eles devem considerar fatores como
usabilidade, desempenho e capacidade de manutenção e garantir que a arquitetura seja
consistente com as melhores práticas de desenvolvimento de software. Os desenvolvedores
podem usar os princípios de uma boa arquitetura de software, como: abstração, separação de
preocupações, modularidade e hierarquia, para avaliar o plano e garantir que seja de alta
qualidade.
Etapa 4: comunicar a arquitetura
Para construir um sistema de software que atenda às necessidades de seus usuários, os
desenvolvedores precisam comunicar a arquitetura de forma nítida a todas as partes
interessadas no projeto. Isso inclui designers, responsáveis por negócios e outros
desenvolvedores. Ao comunicar de forma clara o plano, todos podem estar na mesma página e
trabalhar juntos para construir o software.
Etapa 5: atualizar a arquitetura
À medida que o sistema de software é construído e testado, desenvolvedores podem precisar
fazer alterações na arquitetura. Ao seguir o padrão ISO/IEEE 1471-2000, desenvolvedores podem
garantir que quaisquer alterações feitas sejam consistentes com o plano geral do software. Eles
podem avaliar as mudanças usando os princípios da boa arquitetura de software e certi�car-se
Disciplina
Arquitetura de Software
de que as mudanças não comprometam a con�abilidade, manutenibilidade ou usabilidade do
sistema de software.
Em conclusão, o padrão ISO/IEEE 1471-2000 para arquitetura de software fornece um conjunto
de diretrizes e princípios que os desenvolvedores de software podem usar para projetar e
construir sistemas de software de alta qualidade. Seguindo as etapas descritas acima, os
desenvolvedores podem criar um software fácil de manter, que atenda às necessidades de seus
usuários e seja consistente com as melhores práticas de desenvolvimento de software.
Videoaula: Fundamentos de arquitetura de software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Nesta videoaula, você aprenderá sobre os princípios fundamentais da arquitetura de software e
do padrão ISO/IEEE 1471-2000 em seus projetos. Você obterá uma compreensão profunda das
diferentes visões da arquitetura de software e como criar um plano de arquitetura e�caz que
atenda às necessidades de seus usuários.
Saiba mais
Disciplina
Arquitetura de Software
1. Arquitetura de Software: nesse link, você poderá acessar uma aula da professora Silvia
Regina Vergilio, da UFPR, sobre arquitetura de software, com de�nições de outros autores.
2. A importância do arquiteto de software: nesse link, você terá acesso a características do
papel de um pro�ssional de arquitetura de software.
Referências
https://www.inf.ufpr.br/andrey/ci163/IntroduzArquiteturaAl.pdf
https://www.inf.ufpr.br/andrey/ci163/IntroduzArquiteturaAl.pdf
https://www.devmedia.com.br/a-importancia-do-arquiteto-de-software/27794
Disciplina
Arquitetura de Software
IEEE ARCHITECTURE WORKING GROUP et al. IEEE recommended practice for architectural
description of software-intensive systems. IEEE std, v. 1471, 2000;
MEDVIDOVIC, Nenad; TAYLOR, Richard N. Software architecture: foundations, theory, and
practice. In: Proceedings of the 32nd ACM/IEEE International Conference on Software
Engineering – Volume 2, 2010. p. 471-472.
PERRY, Dewayne E.; WOLF, Alexander L. Foundations for the study of software architecture. ACM
SIGSOFT Software engineering notes, v. 17, n. 4, p. 40-52, 1992.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software. Porto Alegre: Grupo A, 2021. E-
book. ISBN 9786558040118. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 14 ago. 2023;
ZENKER, Aline M.; SANTOS, Jailson Costa dos; COUTO, Júlia M C.; et al. Arquitetura de sistemas.
Porto Alegre: Grupo A, 2019. E-book. ISBN 9788595029767. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788595029767/. Acesso em: 14 ago. 2023.
Aula 2
Decompondo a de�nição de arquitetura de software
Introdução
Disciplina
Arquitetura de Software
Olá, estudante!
Nesta aula, exploraremos os conceitos fundamentais da arquitetura de software, incluindo sua
de�nição, elementos-chave e processos essenciais de tomada de decisão. Também
discutiremos o papel crítico que a qualidade arquitetônica e os atributos de visão desempenham
na formação do sucesso de um projeto de software.
Ao longo desta aula, usaremos exemplos para ilustrar como diferentes decisões arquiteturais
podem impactar o processo de desenvolvimento e o produto. Ao �nal dela, você terá uma
compreensão da de�nição da arquitetura de software e do papel crucial que ela desempenha na
criação de software e�ciente e e�caz. Prepare-se para embarcar nessa jornada no mundo da
arquitetura de software!
Bons estudos!
Revelando a arquitetura de software
Disciplina
Arquitetura de Software
Elementos arquiteturais
De acordo com Perry e Wolf (1992), os elementos arquiteturais são os blocos de construção da
arquitetura de software. Esses elementos são os componentes básicos usados para criar a
arquitetura de um sistema de software. Exemplos de elementos arquiteturais incluem módulos,
componentes, conectores e modelos de dados. Os elementos arquiteturais fornecem a base para
o projeto e desenvolvimento do sistema de software.
A relação entre os elementos arquiteturais é crucial para o sucesso de um sistema de software.
Os componentes e conectores devem trabalhar juntos para garantir que o sistema funcione
conforme o esperado. Portanto, os arquitetos de software devem considerar cuidadosamente o
projeto e a utilização dos elementos arquiteturais para garantir que o sistema funcione conforme
esperado pelo usuário �nal (PERRY; WOLF, 1992).
Compreender os diferentes elementos arquiteturais e seus relacionamentos é essencial para
criar um sistema de software bem projetado. À medida que os sistemas de software se tornam
cada vez mais complexos, é ainda mais difícil ter uma profunda compreensão dos elementos
arquiteturais e suas interdependências. Ao dominar os elementos fundamentais da arquitetura
de software, os arquitetos podem criar sistemas de software e�cientes, con�áveis e sustentáveis
ao longo do tempo.
Decisões arquiteturais
Para Pressman e Maxim (2021), “as decisões sobre a arquitetura do software identi�cam
importantes problemas do projeto e o raciocínio por trás das soluções arquiteturais escolhidas”.As decisões são realizadas por meio da organização do sistema de software, por exemplo, das
escolhas de padrões arquiteturais e suas interfaces, através de suas colaborações e da
composição desses elementos em subsistemas cada vez maiores.
As decisões arquiteturais nada mais são do que as escolhas realizadas por arquitetos de
software no planejamento da estrutura de sistemas de software. De acordo com Perry e Wolf
(1992), essas decisões envolvem:
Disciplina
Arquitetura de Software
A seleção de quais componentes usar.
Como serão as interações.
Quais técnicas devem ser usadas para atingir a qualidade desejada do sistema.
As decisões tomadas no nível de arquitetura impactarão signi�cativamente todo o sistema de
software, incluindo seu desempenho, manutenibilidade e escalabilidade. Os arquitetos devem
considerar uma ampla gama de fatores, como requisitos de projeto, restrições de recursos e
necessidades do usuário ao tomar decisões arquiteturais. Com decisões arquiteturais
conscientes e bem pensadas, os arquitetos de software poderão criar sistemas mais con�áveis,
e�cientes e econômicos.
Atributos de qualidade arquiteturais
Atributos de qualidade de arquitetura são os critérios que os arquitetos de software usam para
avaliar a qualidade de um sistema de software. Eles re�etem as características do sistema que
são as mais importantes para os stakeholders, como desempenho, segurança, con�abilidade e
usabilidade.
Esses atributos são críticos para garantir que o sistema de software atenda às necessidades de
seus usuários, além da manutenção e durabilidade dele. De acordo com Perry e Wolf (1992),
identi�car e priorizar atributos de qualidade arquiteturais é uma etapa essencial no processo de
projeto de arquitetura de software. Se essa etapa for ignorada, pode resultar em sistemas de
baixa qualidade, difíceis de manter e evoluir.
Visão arquitetural
A visão arquitetural é uma descrição de alto nível das metas e objetivos da arquitetura de um
sistema de software. Ele fornece um roteiro para a equipe de desenvolvimento e os stakeholders
seguirem, a �m de garantir que o sistema atenda aos objetivos esperados para o usuário �nal
(PRESSMAN; MAXIM, 2021).
Descodi�cando a arquitetura de software
Disciplina
Arquitetura de Software
Exemplos de elementos arquiteturais
Cada elemento arquitetural tem suas próprias responsabilidades especí�cas e interações com
outros elementos, e eles determinam coletivamente o comportamento do sistema e os atributos
de qualidade. De acordo com Pressman e Maxim (2021), nesse âmbito, podemos elencar três
elementos fundamentais para qualquer projeto de software:
1. Componentes: unidades essenciais do sistema; podem ser de�nidos por módulos de
software com responsabilidades especí�cas dentro do sistema, como gerenciamento de
dados ou processamento de entrada do usuário.
2. Propriedades: elementos que são de�nidos pelas particularidades de cada componente,
como desempenho e con�abilidade
3. Conectores: são identi�cados como mecanismos pelos quais os componentes se
comunicam entre si, por meio de chamadas de função ou de mensagens.
Para entender melhor como esses três componentes funcionam juntos, imagine um motor de
carro. O próprio motor é um componente, sua potência e e�ciência de combustível são suas
propriedades, e os vários tubos e cabos que o conectam ao resto do carro são seus conectores.
Ao entender esses elementos e como eles interagem, os arquitetos podem projetar sistemas de
software con�áveis, e�cientes e fáceis de manter.
Exemplos de decisões arquiteturais
Escolher uma linguagem de programação, selecionar um sistema de gerenciamento de banco de
dados, determinar a escalabilidade do sistema e projetar os recursos de segurança do sistema,
Disciplina
Arquitetura de Software
são exemplos de decisões arquiteturais realizadas pelo arquiteto de software. Vamos entender
um pouco mais?
Escolha de uma linguagem de programação: selecionar uma linguagem de programação
pode afetar o desempenho e a manutenção do sistema, pois algumas linguagens são mais
adequadas para tarefas especí�cas do que outras.
Seleção de um sistema de gerenciamento de banco de dados: a escolha de um sistema de
gerenciamento de banco de dados pode afetar a capacidade de o sistema armazenar e
recuperar dados com e�ciência.
Determinar a escalabilidade do sistema: decidir sobre a escalabilidade do sistema pode
afetar a capacidade de o sistema lidar com um número crescente de usuários ou dados.
Recursos de segurança: projetar os recursos de segurança do sistema pode afetar a
capacidade do sistema de se proteger contra-ataques cibernéticos.
Portanto, os arquitetos devem considerar cuidadosamente essas decisões e seu impacto no
design e na função geral do sistema. Pressman e Maxim (2021) enfatizam a importância de
tomar decisões arquiteturais de forma correta, pois os arquitetos podem garantir que o sistema
de software atenda aos objetivos desejados e possa ser facilmente adaptado às mudanças nos
requisitos.
Por que devemos entender os atributos de qualidade arquiteturais e visão arquitetural?
De acordo com Pressman e Maxim (2021), os atributos de qualidade arquiteturais referem-se às
características de um sistema de software que determinam sua e�cácia e e�ciência. Exemplos
incluem desempenho, segurança, con�abilidade e escalabilidade. A visão arquitetural, por outro
lado, refere-se a um entendimento compartilhado das metas e objetivos de um sistema de
software, que orienta seu projeto e implementação. Inclui elementos como a �nalidade, o escopo
e os stakeholders do sistema. Para obter um sistema de software bem-sucedido, é crucial
considerar os atributos de qualidade arquitetural e a visão desde o início do processo de design.
Ao fazer isso, podemos garantir que o sistema atenda aos seus requisitos funcionais e não
funcionais, alinhando-se com os objetivos gerais do projeto. 
Vamos entender arquitetura mais a fundo?
Disciplina
Arquitetura de Software
A arquitetura de software é uma parte essencial do desenvolvimento de software. Envolve o uso
de elementos arquiteturais, decisões arquitetônicas, visão arquitetural e atributos de qualidade
para desenvolver um sistema de software que atenda aos requisitos do usuário. Elementos de
arquitetura referem-se aos componentes, propriedades e conectores que compõem um sistema
de software. As decisões de arquitetura, por outro lado, são as escolhas feitas pelos arquitetos
de software para alcançar as propriedades desejadas do sistema, como con�abilidade,
segurança e capacidade de manutenção (PRESSMAN; MAXIM, 2021).
A visão arquitetural refere-se aos objetivos de longo prazo de um sistema de software, enquanto
os atributos de qualidade referem-se aos requisitos não funcionais do sistema, como
desempenho, escalabilidade e usabilidade. Por exemplo, um sistema de software projetado para
uma plataforma de comércio eletrônico deve ter alta disponibilidade, con�abilidade e segurança
para garantir a satisfação do cliente.
Para aplicar esses conceitos de forma e�caz, os arquitetos de software precisam usar uma
combinação de ferramentas, princípios e classi�cações. De acordo com Pressman e Maxim
(2021) a Uni�ed Modeling Language (UML) é uma dessas ferramentas que os arquitetos usam
para projetar sistemas de software. O modelo de visão 4+1, desenvolvido por Kruchten (1995), é
outra ferramenta que ajuda os arquitetos a projetar sistemas de múltiplas perspectivas, como
visão lógica, visão de processo, visão física e visão de desenvolvimento.
Os princípios que os arquitetos de software usam para projetar sistemas de software incluem
modularidade, encapsulamento, abstração e separação de preocupações. Esses princípios
garantem que os sistemas de software sejam fáceis de manter, entender e modi�car. A
Disciplina
Arquitetura de Software
classi�cação dos estilos de arquitetura de software inclui camadas, cliente-servidor,
microsserviços e arquitetura orientada a eventos.
Vamos para um exemplo prático?
Vamos imaginar que uma equipe esteja construindo uma nova plataformade comércio
eletrônico. Sua visão arquitetural é criar uma plataforma escalável, segura e fácil de usar, e que
possa lidar com um grande volume de transações. Para atingir essa visão, eles tomam várias
decisões arquiteturais, como usar uma arquitetura baseada em micros serviços e implantar a
plataforma em uma infraestrutura baseada em nuvem.
Para implementar essas decisões, eles identi�cam vários elementos arquiteturais, como:
autenticação do usuário, processamento de pagamentos, catálogo de produtos e funcionalidade
de pesquisa. Eles de�nem as propriedades desses elementos, como desempenho,
disponibilidade e segurança. Também determinam os conectores entre esses elementos, como
APIs e �las de mensagens, para garantir a comunicação e a coordenação adequadas entre eles.
Finalmente, eles de�nem vários atributos de qualidade arquiteturais que desejam que a
plataforma tenha, como alto desempenho, disponibilidade, segurança e usabilidade. Eles
desenvolvem e implementam casos de teste e métricas de desempenho para avaliar a
conformidade da plataforma com esses atributos.
Em conclusão, a arquitetura de software desempenha um papel crítico no desenvolvimento de
sistemas de software que atendam aos requisitos dos usuários. Os arquitetos devem usar uma
combinação de ferramentas, princípios e classi�cações para projetar sistemas de software
e�cazes. Eles também devem tomar decisões arquiteturais corretas e manter uma visão
arquitetural nítida em mente para garantir o sucesso do sistema a longo prazo. Por �m, os
arquitetos devem equilibrar os atributos de qualidade arquitetural para garantir que o sistema
funcione de maneira ideal enquanto atende aos requisitos do usuário (PRESSMAN; MAXIM,
2021). Seguindo essas diretrizes, os arquitetos podem desenvolver sistemas de software
con�áveis, seguros e e�cientes. 
Videoaula: Decompondo a de�nição de arquitetura de software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Nesta videoaula, vamos de�nir as decisões arquiteturais, a visão arquitetural, os elementos
arquiteturais e os atributos de qualidade. Também vamos explorar a importância desses
conceitos na engenharia de software e como eles podem ser aplicados para criar sistemas de
software e�cazes e e�cientes. Esta aula fornecerá insights valiosos de práticas para melhorar
suas habilidades de arquitetura de software.
Disciplina
Arquitetura de Software
Saiba mais
1. Arquitetura de Software:. Aprenda os conceitos e a importância da arquitetura de software.
2. Arquitetura de Software: atributos para decisões do projeto arquitetural. Conheça um
conjunto de informações que podem subsidiar decisões de projeto arquitetural de sistemas
de software.
 
 
Referências
https://www.devmedia.com.br/arquitetura-de-software-desenvolvimento-orientado-para-arquitetura/8033
https://www.devmedia.com.br/arquitetura-de-software-atributos-para-decisoes-do-projeto-arquitetural/16121
https://www.devmedia.com.br/arquitetura-de-software-atributos-para-decisoes-do-projeto-arquitetural/16121
Disciplina
Arquitetura de Software
KRUCHTEN, Philippe B. The 4+ 1 view model of architecture. IEEE software, v. 12, n. 6, p. 42-50,
1995.
PERRY, Dewayne E.; WOLF, Alexander L. Foundations for the study of software architecture. ACM
SIGSOFT Software engineering notes, v. 17, n. 4, p. 40-52, 1992;
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software. Porto Alegre: Grupo A, 2021. E-
book. ISBN 9786558040118. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 14 ago 2023;
ZENKER, Aline M.; SANTOS, Jailson Costa dos; COUTO, Júlia M C.; et al. Arquitetura de sistemas.
Porto Alegre: Grupo A, 2019. E-book. ISBN 9788595029767. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788595029767/. Acesso em: 14 ago 2023.
Aula 3
Visões da arquitetura
Introdução
Disciplina
Arquitetura de Software
Olá, estudante!
Nesta aula, exploraremos o conceito de documento de arquitetura e sua importância no
desenvolvimento de software. Discutiremos os benefícios que ela traz, as di�culdades envolvidas
e por que documentar a arquitetura de software é crucial.
Então, do que se trata este documento de arquitetura? É como um projeto que descreve como
um sistema de software deve ser construído. Isso nos ajuda a organizar nossas ideias,
comunicar de forma e�caz e orientar o processo de desenvolvimento. A documentação da
arquitetura de software tem seus benefícios. Traz clareza para a equipe, facilitando o
entendimento e a manutenção do sistema. Também permite escalabilidade, garantindo que o
software possa crescer com o negócio.
Agora, você deve estar se perguntando, por que deveríamos nos preocupar em documentar a
arquitetura? Vamos descobrir juntos? Então, prepare-se para explorar o fascinante mundo da
arquitetura de software e descobrir como ela molda o cenário digital!
Bons estudos!
Desvendando as visões de arquitetura
Disciplina
Arquitetura de Software
Documento de arquitetura
De acordo com Pressman e Bruce (2014), o documento de arquitetura é um artefato vital, um
modelo para projetar e construir sistemas de software. Ele fornece uma visão de alto nível da
estrutura, componentes e interações do sistema. O documento de arquitetura serve como
referência para desenvolvedores, interessados e futuros mantenedores, garantindo um
entendimento compartilhado do design do sistema.
Agora, vamos nos aprofundar nos benefícios de documentar a arquitetura de software. Wiegers e
Beatty (2013) enfatizam que uma arquitetura bem documentada traz clareza ao projeto. O
documento de arquitetura ajuda as partes interessadas a visualizar a estrutura e a funcionalidade
do sistema, reduzindo mal-entendidos e permitindo uma comunicação e�caz entre os membros
da equipe.
Além disso, documentar a arquitetura do software aumenta a capacidade de manutenção do
sistema, conforme mencionado por Pressman e Bruce (2014). Ao documentar a arquitetura, os
desenvolvedores podem compreender facilmente o design do sistema, permitindo solução
e�ciente dos problemas, correção de bugs e aprimoramentos. Esta documentação atua como
um ponto de referência, orientando futuras modi�cações e garantindo que o sistema permaneça
adaptável ao longo do tempo.
No entanto, documentar a arquitetura de software pode apresentar desa�os. Wiegers e Beatty
(2013) observam que capturar a complexidade da arquitetura com precisão é uma dessas
di�culdades. O documento de arquitetura deve fornecer uma visão abrangente do sistema,
mantendo-se conciso e compreensível. Equilibrar esses requisitos pode ser desa�ador, exigindo
atenção cuidadosa aos detalhes e habilidades de comunicação e�cazes.
Disciplina
Arquitetura de Software
Manter a exatidão da documentação é outro desa�o destacado por Pressman e Bruce (2014). Os
sistemas de software evoluem e as atualizações são feitas para atender a novos requisitos ou
para melhorar a funcionalidade existente. É crucial manter o documento de arquitetura
atualizado, re�etindo essas mudanças com precisão. Deixar de fazer isso pode levar a confusão
e a inconsistências entre a arquitetura documentada e o sistema real.
Agora, você pode se perguntar, por que é importante documentar a arquitetura de software?
Segundo Pressman e Bruce (2014), a documentação promove o compartilhamento do
conhecimento dentro da equipe. O documento garante que todos os envolvidos tenham uma
compreensão clara da estrutura e funcionalidade do sistema. Esse conhecimento compartilhado
aprimora a colaboração, minimiza a dependência de indivíduos especí�cos e promove a
comunicação e�caz.
Além disso, a documentação da arquitetura de software permite a rastreabilidade, conforme
descrito por Booch et al. (2005). O documento de arquitetura permite a rastreabilidade das
decisões de projeto e a lógica por trás delas. Ele fornece um registro histórico da evolução do
sistema, ajudando as futurasequipes a aprender com as experiências passadas e a tomar
decisões informadas.
A documentação da arquitetura de software dá suporte à evolução do sistema, conforme
enfatizado por Pressman e Bruce (2014). À medida que o sistema cresce e muda, o documento
de arquitetura atua como um guia para incorporar novos recursos, modi�car os existentes ou
atender a requisitos emergentes. Ele garante que essas alterações se alinhem com a arquitetura
geral, evitando inconsistências e preservando a integridade do sistema.
Explorando documentos arquiteturais
Disciplina
Arquitetura de Software
Exemplos de documentos arquiteturais
De acordo com Clements et al. (2002), os documentos arquiteturais desempenham um papel
fundamental no desenvolvimento de software. Vejamos alguns exemplos desses documentos:
Diagrama de arquitetura: esse diagrama mostra a organização dos componentes do
sistema e suas relações. Por exemplo, em um sistema de comércio eletrônico, o diagrama
de arquitetura pode incluir componentes como banco de dados, servidor web, aplicativo de
front-end e sistemas externos de pagamento. Esses componentes são interligados por
meio de interfaces e troca de dados.
Documentação de interfaces: esse tipo de documentação descreve como os diferentes
componentes se comunicam entre si. No sistema de comércio eletrônico, por exemplo,
pode haver uma interface entre o aplicativo de front-end e o servidor web, de�nindo os
métodos e parâmetros necessários para a troca de informações.
Modelo de componentes: esse modelo descreve os diferentes componentes do sistema e
suas interações. Em uma rede social, por exemplo, o modelo de componentes pode incluir
componentes como per�l do usuário, feed de notícias, sistema de mensagens e sistema de
busca.
Fluxo de dados: esse tipo de documento mostra como os dados são processados e
movimentados dentro do sistema. Em um sistema de gerenciamento de estoque, por
exemplo, o �uxo de dados pode descrever como os pedidos de compra são recebidos,
processados e registrados no banco de dados.
Disciplina
Arquitetura de Software
Características dos documentos arquiteturais
Para Kruchten (1995), os documentos arquiteturais possuem características importantes que
garantem sua e�cácia como ferramentas de comunicação e referência. São elas:
1. Clareza e compreensibilidade: os documentos arquiteturais devem ser elaborados de forma
clara e compreensível para todos os envolvidos no projeto, independentemente do nível de
conhecimento técnico. A linguagem utilizada deve ser acessível, evitando jargões e
terminologia técnica complexa, permitindo que desenvolvedores, gerentes de projeto e
clientes entendam facilmente a arquitetura do sistema.
2. Atualização e precisão: os documentos arquiteturais devem ser atualizados conforme o
sistema evolui. É importante re�etir as mudanças nos requisitos, funcionalidades e
componentes na documentação. Manter a documentação atualizada garante sua
relevância e precisão, evitando inconsistências entre a documentação e o sistema real.
3. Coerência e consistência: os documentos arquiteturais devem manter coerência e
consistência interna. As informações apresentadas nos diferentes documentos e
diagramas devem estar alinhadas e não apresentar contradições. Isso garante a
con�abilidade da documentação como referência para o sistema em desenvolvimento.
4. Abordagem modular: os documentos arquiteturais devem adotar uma abordagem modular,
destacando as diferentes partes do sistema e suas interações. Isso permite uma
compreensão clara da estrutura do sistema, identi�cando componentes, módulos e
camadas envolvidas. A abordagem modular facilita a manutenção e a evolução do sistema,
pois as partes podem ser modi�cadas independentemente umas das outras.
5. Integração com outros artefatos: os documentos arquiteturais devem ser integrados a
outros artefatos e documentos relacionados ao desenvolvimento do software, como
requisitos, casos de uso, diagramas de sequência e planos de testes. Essa integração
proporciona uma visão completa do sistema e garante consistência entre as diferentes
partes do processo de desenvolvimento.
Essas características garantem que os documentos arquiteturais sejam valiosos recursos para
comunicar e compreender a arquitetura do sistema, permitindo que todos os envolvidos tenham
uma visão clara e consistente dele. 
Um exemplo de aplicação para o documento de arquitetura
Disciplina
Arquitetura de Software
Imagine que você faz parte de uma equipe de desenvolvimento de software em uma empresa de
tecnologia. Vocês estão trabalhando em um projeto para criar um sistema de gerenciamento de
pedidos online para uma empresa de comércio eletrônico. O objetivo é permitir que os clientes
façam pedidos de forma fácil e e�ciente, enquanto a empresa acompanha e gerencia os pedidos
de forma automatizada.
De acordo com Pressman e Bruce (2014), para garantir o sucesso do projeto, é crucial que todos
os membros da equipe tenham uma compreensão clara da estrutura e das interações do
sistema. Nesse sentido, você decide utilizar um documento de arquitetura com várias visões
dentro dele para representar e documentar as informações essenciais sobre o sistema. Vamos
ver como fazer isso?
Um dos documentos arquiteturais que você cria é o diagrama de arquitetura. Nesse
diagrama, você representa gra�camente a estrutura geral do sistema, incluindo os
principais componentes e como eles se relacionam entre si. Por exemplo, você identi�ca
componentes como a interface do usuário, o banco de dados, o servidor web e o sistema
de pagamentos. Você mostra como esses componentes estão interconectados e como as
informações �uem entre eles. Isso ajuda a equipe a visualizar a arquitetura do sistema e
entender como os diferentes componentes se relacionam para fornecer a funcionalidade
desejada.
Além disso, você cria uma documentação de interfaces. Nessa documentação, você
descreve em detalhes como os diferentes componentes se comunicam entre si. Por
exemplo, você explica como a interface do usuário interage com o servidor web, quais
Disciplina
Arquitetura de Software
dados são transmitidos e quais ações são realizadas. Você também descreve como o
servidor web se comunica com o banco de dados para armazenar e recuperar informações.
Essa documentação de interfaces é fundamental para garantir a integração e a correta
comunicação entre os componentes do sistema.
Outro documento importante que você desenvolve é o modelo de componentes. Nesse
modelo, você descreve cada um dos principais componentes do sistema em detalhes. Por
exemplo, para o componente de interface do usuário, você descreve as diferentes telas e
funcionalidades disponíveis para os usuários. Para o componente de banco de dados, você
descreve as tabelas e os relacionamentos entre elas. Esse modelo de componentes ajuda a
equipe a entender as responsabilidades de cada componente e como eles se encaixam no
contexto geral do sistema.
Além disso, você cria um �uxo de dados para ilustrar como as informações são
processadas e movimentadas dentro do sistema. Por exemplo, você descreve o �uxo
desde o momento em que um cliente faz um pedido na interface do usuário, passando pela
validação e processamento no servidor web, até o armazenamento no banco de dados.
Esse �uxo de dados ajuda a equipe a entender como as informações percorrem o sistema
e como são transformadas ao longo do processo.
Ao desenvolver esses documentos arquiteturais detalhados, você garante que todos os
membros da equipe tenham uma visão compartilhada e precisa do sistema em desenvolvimento.
Esses documentos servem como uma referência fundamental durante todo o ciclo de vida do
projeto, desde o planejamento até a implementação e a manutenção. Eles facilitam a
comunicação e a colaboração entre os membros da equipe, além de fornecerem uma base sólida
para tomar decisões de projeto e realizar ajustes quando necessário.
Documentos arquiteturais promovem a colaboração e�caz, facilitam a tomada de decisões e
contribuem para o sucesso do projeto como um todo. 
Videoaula;Visões da arquitetura
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Convidamos você para uma videoaula sobre documentos arquiteturais na prática. Aprenda a
projetar sistemas de software de forma e�ciente e a entender sua estrutura e interações.
Compartilharemos um exemplo real e explicaremos como criar e utilizar esses documentos.
Descubra as melhores práticas e como elas impulsionam o desenvolvimento de software. Não
perca essa oportunidade de expandir seus conhecimentos e se destacar na área!
Disciplina
Arquitetura de Software
Saiba mais
Aprofunde seus conhecimentos com:
Uma abordagem para Inspeção de Documentos Arquiteturais Baseada em Checklist.
Princípios e Práticas em Arquitetura de Software.
Referências
https://www.cos.ufrj.br/index.php/pt-BR/publicacoes-pesquisa/details/15/1922
https://www.machado.mg.gov.br/files/concursos/1cf11cf161fe4eb688dfeec880d6b4d9.pdf
Disciplina
Arquitetura de Software
BOOCH, Grady; et al. The uni�ed modeling language. Unix Review, v. 14, n. 13, p. 5, 1996.
CLEMENTS, Paul C. Software architecture in practice. Pittsburgh: Software Engineering Institute,
2002.
KRUCHTEN, Philippe B. The 4+ 1 view model of architecture. IEEE software, v. 12, n. 6, p. 42-50,
1995.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software. Porto Alegre: Grupo A, 2021. E-
book. ISBN 9786558040118. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 14 ago. 2023.
PRESSMAN, R. S.; BRUCE, M. Software Engineering: A Practitioner’s Approach. 8a edição. Nova
York: McGraw-Hill Education, 2014.
WIEGERS, Karl; BEATTY, Joy. Software requirements. Londres: Pearson Education, 2013. 
Aula 4
Stakeholders
Introdução
Disciplina
Arquitetura de Software
Olá, estudante!
Nesta aula, mergulharemos no mundo dos stakeholders e exploraremos sua importância no
desenvolvimento de projetos. Os stakeholders são indivíduos ou grupos que possuem interesse
ou são afetados pelo resultado de um projeto. Eles desempenham um papel crucial na de�nição
de requisitos, tomada de decisões e sucesso geral do projeto.
Ao longo de nossa jornada, examinaremos os diferentes tipos de stakeholders, suas expectativas
e como gerenciar efetivamente suas necessidades. Vamos discutir estratégias de engajamento e
comunicação, além de abordar os desa�os e benefícios de envolver os stakeholders desde o
início até o �m do projeto. Prepare-se para aprender e descobrir como maximizar a colaboração
e o suporte dos stakeholders.
Bons estudos!
De�nição de stakeholders
Disciplina
Arquitetura de Software
Quando falamos de um sistema de software, é importante entender que existem várias pessoas
e grupos que têm interesse ou são afetados por ele. Essas pessoas e grupos são chamados de
interessados, ou stakeholders. Mas quem são eles?
Os stakeholders são indivíduos, ou organizações, que têm algum tipo de interesse no sistema de
software. Isso signi�ca que eles podem se bene�ciar ou serem afetados pelo sistema de alguma
forma. Os interessados podem incluir clientes, usuários �nais, gerentes, desenvolvedores,
analistas de negócios e até mesmo fornecedores de hardware ou software.
Agora que sabemos quem são os interessados, é importante entender a importância deles. Os
interessados desempenham um papel fundamental no desenvolvimento e sucesso de um
sistema de software. Eles têm necessidades, expectativas e preocupações especí�cas em
relação ao sistema.
O Guia PMBOK (2013), que é uma referência importante na área de gerenciamento de projetos,
aborda os interessados como parte do processo de gerenciamento das partes interessadas. Ele
destaca a importância de identi�car, analisar e gerenciar os interessados ao longo de todo o
ciclo de vida do projeto de software.
Os interessados têm uma grande in�uência nos atributos de qualidade de um sistema de
software. Por exemplo, os usuários �nais desejam um sistema fácil de usar, com uma interface
amigável. Os clientes podem estar preocupados com a con�abilidade e segurança do sistema.
Os gerentes podem estar interessados na escalabilidade e e�ciência do sistema.
Disciplina
Arquitetura de Software
Existem diferentes tipos de interessados, cada um com suas próprias necessidades e
expectativas em relação ao sistema de software. Alguns exemplos de tipos de interessados
incluem:
1. Clientes: são aqueles que solicitam o desenvolvimento do sistema de software e têm
interesse direto no seu funcionamento. Eles são responsáveis por de�nir os requisitos e
fornecer orientações sobre o que esperam do sistema.
2. Usuários �nais: são as pessoas que realmente utilizarão o sistema de software. Eles têm
interesse em um sistema intuitivo, fácil de usar e que atenda às suas necessidades
especí�cas.
3. Desenvolvedores: são os pro�ssionais responsáveis por construir o sistema de software.
Eles têm interesse em um sistema bem documentado, com código de qualidade e que
possa ser facilmente mantido e atualizado.
4. Analistas de negócios: são responsáveis por entender as necessidades dos clientes e
traduzi-las em requisitos claros para o sistema de software. Eles têm interesse em um
sistema que atenda aos requisitos de negócio e agregue valor para a organização.
5. Fornecedores: são as empresas ou indivíduos que fornecem hardware, software ou
serviços relacionados ao sistema de software. Eles têm interesse em um sistema
compatível com suas soluções e que possa integrar-se de forma e�ciente ao ambiente
existente.
A relação entre os interessados e os atributos de qualidade é fundamental para o sucesso do
sistema de software. Cada interessado tem suas próprias necessidades e expectativas em
relação ao sistema, e é importante considerar esses aspectos ao de�nir e desenvolver os
atributos de qualidade do sistema.
Em resumo, os interessados são pessoas ou grupos que têm interesse ou são afetados por um
sistema de software. Eles desempenham um papel fundamental no desenvolvimento e sucesso
do sistema, in�uenciando os atributos de qualidade. Identi�car, analisar e gerenciar os
interessados ao longo do projeto é essencial para garantir o alinhamento de expectativas e a
satisfação de todas as partes envolvidas.
Partes interessadas no projeto
Disciplina
Arquitetura de Software
Na gestão de projetos, compreender o papel das partes interessadas é fundamental para o
sucesso de qualquer empreendimento. As partes interessadas são indivíduos ou grupos que têm
interesse, in�uência ou são afetados pelo projeto. Elas podem variar de acordo com o projeto em
questão, mas geralmente incluem clientes, membros da equipe, gerentes, acionistas, usuários
�nais e até mesmo a comunidade em que o projeto está inserido. Cada uma dessas partes
interessadas possui expectativas e necessidades especí�cas que devem ser levadas em
consideração ao longo do ciclo de vida do projeto.
Uma parte importante do papel da equipe de projeto é identi�car e engajar as partes
interessadas de forma e�caz. Isso envolve a compreensão das suas necessidades e
expectativas, bem como a comunicação clara e constante para manter todas as partes
alinhadas. Uma comunicação e�caz é essencial para garantir que as informações relevantes
sejam compartilhadas, o feedback seja ouvido e quaisquer problemas ou preocupações sejam
abordados prontamente. A comunicação também permite que as partes interessadas se sintam
envolvidas e tenham con�ança de que suas perspectivas estão sendo consideradas. A Figura a
seguir, presente no Guia PMBOK (2013), ilustra a relação entre o projeto, a equipe e as diversas
partes interessadas, destacando a importância de uma comunicação e�caz e um
relacionamento sólido para o sucesso do projeto.
Disciplina
Arquitetura de Software
Relação entre as partes interessadas e o projeto. Fonte: PMBOK (2013, p. 25).
As partes interessadas desempenham um papel fundamental no sucesso do projeto, pois podem
fornecer informações valiosas,in�uenciar decisões importantes e contribuir com recursos. Por
exemplo, os clientes são partes interessadas cruciais, pois solicitam o projeto e �nanciam sua
execução. Eles têm interesse direto no sucesso do projeto e esperam que suas necessidades
sejam atendidas de forma adequada. Os usuários �nais também são partes interessadas
essenciais, pois são aqueles que utilizarão o produto do projeto. Satisfazer suas expectativas é
vital para garantir a aceitação e a utilidade do produto.
O Guia PMBOK (2013) é uma referência importante para a gestão de projetos e fornece diretrizes
especí�cas para o gerenciamento das partes interessadas. O guia destaca a importância de
identi�car todas as partes interessadas relevantes, analisar suas expectativas e necessidades,
bem como determinar o nível de in�uência e poder que cada uma possui. Essa análise é
fundamental para priorizar as partes interessadas e alocar recursos de forma e�ciente.
Além disso, as partes interessadas podem ser classi�cadas de acordo com sua in�uência e
poder no projeto. Algumas têm um impacto direto e signi�cativo, enquanto outras têm uma
in�uência indireta ou menos expressiva. É essencial identi�car e envolver as partes interessadas
com maior poder e in�uência, pois suas decisões e ações podem afetar consideravelmente o
andamento e o resultado do projeto.
Outro aspecto importante é a compreensão dos diferentes interesses das partes interessadas.
Cada uma delas tem seus próprios objetivos e expectativas em relação ao projeto. Por exemplo,
alguns podem estar mais preocupados com o resultado, enquanto outros podem enfatizar o
cumprimento dos prazos, controle de custos ou qualidade do produto. Conhecer essas
Disciplina
Arquitetura de Software
expectativas permite que a equipe do projeto desenvolva estratégias adequadas para atender às
necessidades de todas as partes interessadas envolvidas. 
Stakeholders na prática
Na gestão de projetos, os stakeholders desempenham um papel fundamental. Eles são
indivíduos ou grupos que têm interesse, in�uência ou podem ser afetados pelo projeto. São
essenciais para o sucesso do projeto, pois sua participação e suporte são fundamentais para
alcançar os objetivos estabelecidos.
Para entender melhor o conceito de stakeholders, vamos considerar um exemplo prático de um
projeto de desenvolvimento de um novo produto tecnológico, como um smartphone avançado.
Nesse caso, os stakeholders podem incluir:
1. Clientes: são os consumidores �nais do produto, aqueles que vão comprar e utilizar o
smartphone. Eles têm interesse direto no produto e suas necessidades devem ser
atendidas para garantir a satisfação do cliente e o sucesso do projeto.
2. Acionistas: são os investidores ou proprietários da empresa que está desenvolvendo o
smartphone. Eles têm interesse no retorno �nanceiro do projeto e esperam que o produto
seja bem-sucedido no mercado, gerando lucro para a empresa.
3. Equipe do projeto: são os pro�ssionais envolvidos no desenvolvimento do smartphone,
como engenheiros, designers, especialistas em marketing, entre outros. Eles têm interesse
Disciplina
Arquitetura de Software
em entregar um produto de qualidade dentro do prazo e orçamento estabelecidos.
4. Fornecedores: são as empresas ou indivíduos que fornecem os componentes, materiais e
serviços necessários para o desenvolvimento do smartphone. Eles têm interesse em
fornecer produtos de alta qualidade e cumprir os prazos acordados.
5. Governo e reguladores: são as entidades governamentais e órgãos reguladores
responsáveis por estabelecer normas e regulamentos para a indústria de tecnologia. Eles
têm interesse em garantir que o produto atenda aos requisitos de segurança, qualidade e
conformidade.
�. Comunidade: é a comunidade local onde a empresa está sediada ou onde o produto será
lançado. A comunidade pode ter interesse em questões como impacto ambiental,
empregos gerados pelo projeto, responsabilidade social da empresa, entre outros.
A interação e o envolvimento desses stakeholders ao longo do projeto são cruciais para o seu
sucesso. A comunicação e�caz é essencial para entender suas expectativas, necessidades e
preocupações. Além disso, é importante estabelecer canais de comunicação abertos e
transparentes para garantir que todas as partes interessadas sejam ouvidas e suas contribuições
sejam consideradas.
No exemplo do projeto do smartphone, os stakeholders podem ser envolvidos em várias fases,
desde a concepção e design do produto até sua produção, lançamento e suporte pós-venda. Por
exemplo, os clientes podem ser convidados a participar de pesquisas de mercado e testes de
usabilidade para garantir que o produto atenda às suas necessidades e expectativas. Os
acionistas podem acompanhar o progresso do projeto por meio de relatórios e reuniões
periódicas. A equipe do projeto pode se comunicar regularmente com os fornecedores para
garantir que os materiais e componentes sejam entregues no prazo.
Em resumo, os stakeholders desempenham um papel fundamental na gestão de projetos. Eles
têm interesses, in�uência e expectativas que podem impactar diretamente o sucesso do projeto.
É essencial identi�car, engajar e gerenciar os stakeholders de forma e�caz, estabelecendo uma
comunicação clara e estreitando relacionamentos sólidos. Um envolvimento adequado dos
stakeholders aumenta as chances de alcançar os objetivos do projeto e garantir a satisfação de
todas as partes envolvidas. 
Videoaula: Stakeholders
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Nesta videoaula, vamos explorar exemplos reais de projetos e discutir como identi�car, analisar e
gerenciar os stakeholders de forma e�caz. Aprenda como selecionar, engajar e satisfazer as
Disciplina
Arquitetura de Software
diferentes partes interessadas, garantindo o sucesso do projeto. Não perca essa oportunidade
de aprimorar suas habilidades em gestão de stakeholders!
Saiba mais
Aprofunde seus conhecimentos com:
1. Gestão de stakeholders: o que é, por que é importante fazer e 4 dicas para implementar na
sua empresa.
2. Stakeholders, o que são, exemplos, importância e tipos.
Referências
https://www.siteware.com.br/gestao-estrategica/gestao-de-stakeholders/
https://www.siteware.com.br/gestao-estrategica/gestao-de-stakeholders/
https://neilpatel.com/br/blog/stakeholders-o-que-sao/
https://neilpatel.com/br/blog/stakeholders-o-que-sao/
Disciplina
Arquitetura de Software
PMBOK. Um guia de conhecimento em gerenciamento de projetos. São Paulo: Editora Saraiva,
2014. E-book. ISBN 9788502223745. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788502223745/. Acesso em: 14 ago. 2023.
Aula 5
Revisão da Unidade
Revisão da introdução à arquitetura de software
Disciplina
Arquitetura de Software
Olá, estudante! A habilidade de compreender e de�nir a arquitetura de software é de extrema
importância para os pro�ssionais da área de desenvolvimento. Uma das abordagens que nos
auxiliam nessa tarefa é o padrão ISO/IEEE 1471-2000. Vamos explorar os conceitos
fundamentais desse padrão e como eles nos ajudam a criar sistemas de alta qualidade.
A arquitetura de software é a estrutura organizacional fundamental de um sistema, englobando
seus componentes, interações e restrições. Ela nos dá uma visão abrangente do sistema,
permitindo compreender seus elementos e relacionamentos. Nesse contexto, o padrão ISO/IEEE
1471-2000 fornece uma abordagem sistemática para a de�nição, documentação e comunicação
da arquitetura de software.
Um dos principais aspectos abordados pelo padrão é a identi�cação dos stakeholders.
Stakeholders são as partes interessadas no sistema, como usuários, clientes, desenvolvedores,
gerentes, entre outros. Compreender suas necessidades e expectativas é essencial para de�nir
uma arquitetura que atenda aos requisitos e objetivos estabelecidos. O padrão nos orienta a
identi�car e descrever os stakeholders deforma clara e precisa.
Outro conceito importante do padrão é a de�nição de visões arquiteturais. As visões
arquiteturais são perspectivas especí�cas da arquitetura que permitem uma compreensão mais
aprofundada do sistema. Cada visão representa uma preocupação ou interesse particular dos
stakeholders. Por exemplo, uma visão pode focar na segurança, enquanto outra na usabilidade. O
padrão ISO/IEEE 1471-2000 nos guia na criação de diferentes visões arquiteturais para
representar essas perspectivas.
Além disso, o padrão destaca a importância da documentação arquitetural. A documentação é
essencial para comunicar e compartilhar a arquitetura com a equipe de desenvolvimento e os
Disciplina
Arquitetura de Software
stakeholders envolvidos no projeto. Ela proporciona um registro claro e compreensível da
estrutura, comportamento e restrições do sistema. A documentação arquitetural pode incluir
diagramas, descrições textuais, especi�cações técnicas e outros artefatos relevantes.
Ao aplicar o padrão ISO/IEEE 1471-2000, somos capazes de de�nir a arquitetura de software de
forma precisa e abrangente. Consideramos as necessidades e expectativas dos stakeholders,
desenvolvemos visões arquiteturais que representam suas perspectivas e documentamos a
arquitetura de maneira clara e acessível. Isso resulta em sistemas mais robustos, �exíveis e de
alta qualidade.
Em resumo, a competência de compreender e de�nir a arquitetura de software utilizando o
padrão ISO/IEEE 1471-2000 é essencial para os pro�ssionais da área. A aplicação desse padrão
nos permite criar sistemas que atendam às expectativas dos stakeholders e evoluam de forma
contínua. Portanto, é fundamental estudar e aplicar os conceitos desse padrão em nossos
projetos, visando à excelência na arquitetura de software.
Esperamos que esse resumo tenha sido útil para você compreender melhor esse tema. Continue
se aprofundando nos conceitos e pratique a aplicação do padrão ISO/IEEE 1471-2000 em seus
projetos. Com o tempo e a experiência, você se tornará um arquiteto de software habilidoso na
de�nição de arquiteturas sólidas e e�cientes. 
Videoaula: Revisão da Unidade
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Nossa videoaula fará um resumo sobre a de�nição da arquitetura de software usando o padrão
ISO/IEEE 1471-2000. Você aprenderá os conceitos-chave, termos e técnicas necessárias para
compreender e documentar arquiteturas de software de forma precisa e abrangente. Descubra
como identi�car stakeholders, visões arquiteturais e documentos arquiteturais signi�cativos.
Não perca a oportunidade de fortalecer seus conhecimentos e aprimorar suas habilidades na
área de arquitetura de software. Junte-se a mim nessa jornada de aprendizado!
Estudo de Caso
Disciplina
Arquitetura de Software
Arquitetura de software para uma plataforma de streaming
Descrição do cenário: você foi contratado como arquiteto de software por uma empresa de
entretenimento para desenvolver uma nova plataforma de streaming de vídeos. O objetivo é criar
uma arquitetura sólida e e�ciente para o aplicativo, que possa lidar com muitos usuários e
fornecer uma experiência de streaming de alta qualidade. O foco é utilizar o padrão IEEE 1471-
2000 para a elaboração da arquitetura, considerando as visões arquiteturais, envolvimento dos
stakeholders e documentos arquiteturais.
Situação-problema 1: um dos desa�os enfrentados é garantir a escalabilidade da plataforma
para lidar com muitos usuários simultâneos. Como arquiteto de software, você precisa de�nir
uma visão arquitetural que aborde essa questão, considerando a distribuição de carga, o
dimensionamento horizontal e a utilização de tecnologias escaláveis. Como garantir que a
plataforma possa crescer de forma e�ciente e atender à demanda de um grande público?
Situação-problema 2: outro desa�o é assegurar a disponibilidade e con�abilidade do serviço de
streaming. A plataforma deve ser capaz de lidar com falhas de componentes e garantir a
continuidade do serviço sem interrupções para os usuários. Como arquiteto de software, você
precisa de�nir uma visão arquitetural que aborde a resiliência do sistema, incluindo a utilização
de redundância, monitoramento e recuperação de falhas. Como garantir que a plataforma seja
con�ável e ofereça uma experiência de streaming contínua?
Situação-problema 3: a plataforma de streaming precisa oferecer uma ampla variedade de
conteúdos, incluindo vídeos, músicas e podcasts. Além disso, é necessário fornecer recursos
como recomendações personalizadas e a capacidade de criação de listas de reprodução. Como
arquiteto de software, você precisa de�nir uma visão arquitetural que aborde a �exibilidade e a
extensibilidade do sistema, permitindo a inclusão de novos tipos de conteúdo e recursos
adicionais. Como garantir que a plataforma seja adaptável às mudanças nas demandas dos
usuários e possa ser facilmente expandida no futuro?
Disciplina
Arquitetura de Software
Estudante, utilize as ferramentas vistas em aula para indicar como resolver as questões
abordadas nas situações propostas, aplicando os conhecimentos adquiridos. Utilize essas
ferramentas como insumos para identi�car soluções adequadas e apresentar uma abordagem
e�caz para lidar com os desa�os apresentados nas situações propostas.
Neste estudo de caso, você terá a oportunidade de enfrentar desa�os reais ao desenvolver a
arquitetura de software para uma plataforma de streaming. Essa experiência prática vai
estimular sua leitura, raciocínio lógico e capacidade de resolver problemas, enquanto fortalece
seus conhecimentos teóricos.
Para começar, é fundamental entender a importância de uma arquitetura sólida e e�ciente para
lidar com muitos usuários e fornecer uma experiência de streaming de alta qualidade. Ao aplicar
o padrão IEEE 1471-2000, você terá uma estrutura guia para elaborar a arquitetura, considerando
as visões arquiteturais, envolvimento dos stakeholders e documentos arquiteturais.
Ao analisar as situações-problema, você perceberá a necessidade de uma arquitetura escalável,
capaz de suportar o crescimento da plataforma. Isso envolve distribuição de carga,
dimensionamento horizontal e utilização de tecnologias escaláveis. Além disso, a disponibilidade
e con�abilidade do serviço são aspectos cruciais a serem considerados, incluindo a resiliência
do sistema, redundância, monitoramento e recuperação de falhas.
Outra questão é a �exibilidade e extensibilidade da plataforma. É essencial projetar uma
arquitetura que permita a inclusão de novos tipos de conteúdo e recursos adicionais, garantindo
a adaptabilidade às mudanças nas demandas dos usuários e a facilidade de expansão futura.
Ao mergulhar nesse estudo de caso, você vivenciará uma situação complexa da realidade
pro�ssional, aplicando seus conhecimentos teóricos e habilidades práticas. Lembre-se de buscar
soluções alinhadas com as diretrizes do padrão IEEE 1471-2000. No �nal, você terá a satisfação
de ter contribuído para o desenvolvimento de uma plataforma de streaming robusta e de alta
qualidade.
Resolução do Estudo de Caso
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Para resolver essas situações-problema, é necessário aplicar os conceitos do padrão IEEE 1471-
2000. A seguir, estão algumas sugestões de ações a serem realizadas:
Situação-problema 1: garantir a escalabilidade da plataforma para lidar com muitos usuários
simultâneos.
Identi�cação dos stakeholders: realizar uma análise dos stakeholders envolvidos, como
usuários �nais, produtores de conteúdo, anunciantes e administradores da plataforma.
Disciplina
Arquitetura de Software
De�nição das visões arquiteturais: elaborar visões arquiteturais relevantes, como a visão de
implantação, descrevendo a infraestruturade hardware e software necessária para suportar
a plataforma, incluindo servidores, serviços de armazenamento e serviços de streaming.
Consideração da escalabilidade, disponibilidade e �exibilidade: Avaliar soluções
tecnológicas escaláveis, como a utilização de serviços em nuvem e arquiteturas de
microsserviços.
Implementar mecanismos de balanceamento de carga, monitoramento de desempenho e
recuperação de falhas para garantir a disponibilidade e con�abilidade do serviço.
Situação-Problema 2: assegurar a disponibilidade e con�abilidade do serviço de streaming.
Elaboração dos documentos arquiteturais: desenvolver documentos arquiteturais, como
diagramas de contexto, diagramas de componentes e diagramas de sequência, para
descrever a arquitetura proposta.
Consideração da escalabilidade, disponibilidade e �exibilidade: implementar mecanismos
de balanceamento de carga, monitoramento de desempenho e recuperação de falhas para
garantir a disponibilidade e con�abilidade do serviço.
Situação-Problema 3: oferecer uma ampla variedade de conteúdos e recursos na plataforma de
streaming.
De�nição das visões arquiteturais: elaborar visões arquiteturais relevantes, como a visão de
informação, detalhando a estrutura de dados utilizada, como metadados de vídeos,
músicas e informações do usuário.
Elaboração dos documentos arquiteturais: desenvolver documentos arquiteturais, como
diagramas de contexto, diagramas de componentes e diagramas de sequência, para
descrever a arquitetura proposta;
Consideração da escalabilidade, disponibilidade e �exibilidade: adotar padrões e práticas
de desenvolvimento que permitam a extensibilidade e a modularidade do sistema,
facilitando a inclusão de novos conteúdos e recursos.
Ao aplicar essas ações, você utilizará os conceitos do padrão IEEE 1471-2000 para resolver as
situações-problema do estudo de caso. Essa abordagem permitirá a criação de uma arquitetura
de software robusta e e�ciente para a plataforma de streaming, considerando as necessidades
dos stakeholders e seguindo as diretrizes estabelecidas. Lembre-se de utilizar as ferramentas
vistas em aula como insumos para identi�car soluções adequadas e apresentar uma abordagem
e�caz na resolução dos desa�os propostos.
Resumo Visual
Disciplina
Arquitetura de Software
Fonte: elaborada pela autora.
Referências
Disciplina
Arquitetura de Software
ISO/IEC/IEEE. Systems and software engineering–architecture description. ISO/IEC/IEEE 42010:
2011 (E)(Revision of ISO/IEC 42010: 2007 and IEEE Std 1471-2000), v. 2011, p. 1-46, 2011;
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software. Nova York: McGraw Hill Brasil,
2021;
,
Unidade 2
Arquitetura de Software e o Modelo de Qualidade
Aula 1
Atributos de qualidade e suas relações
Introdução
Disciplina
Arquitetura de Software
Olá, estudante!
O objetivo principal desta aula é ajudá-lo a entender como os desejos dos clientes são
transformados em um documento que servirá de base para os programadores. Vamos explorar o
processo de levantamento de requisitos, suas etapas, os artefatos gerados e, principalmente, os
padrões de qualidade que de�nem o sucesso de um produto.
Ao �nal desta aula, você estará apto a aplicar os principais conceitos e criar um artefato que
englobe o levantamento de requisitos e os padrões de qualidade. Leia atentamente o conteúdo
da aula e não deixe de conferir o material da bibliogra�a para se aprofundar no assunto.
Bons estudos!
Levantamento de requisitos e atributos de qualidade
Disciplina
Arquitetura de Software
A etapa de levantamento de requisitos é, sem dúvidas, uma das mais importantes do processo
de desenvolvimento de sistemas. Nessa fase, de�nimos o escopo do produto, ou seja, o que o
sistema deve ter e como deve se comportar. O levantamento de requisitos é uma atividade que
começa durante a comunicação e continua na fase de modelagem. É importante adaptar essa
etapa às necessidades do processo, projeto, produto e pessoas envolvidas no trabalho
(PRESSMAN; MAXIM, 2021, p. 132). Portanto, é natural que os requisitos possam sofrer
alterações ao longo do desenvolvimento.
Requisitos podem ser entendidos como as características que o sistema deve possuir, desde as
tarefas que deve desempenhar até o ambiente em que o sistema será executado. Nesse
contexto, os requisitos podem ser divididos em requisitos funcionais e não funcionais (NFR, sigla
do inglês: nonfunctional requirement).
Os requisitos funcionais estão diretamente ligados ao funcionamento do sistema, ou seja, são as
funcionalidades que o software deve oferecer. Por exemplo, o sistema deve permitir o cadastro
de usuários, o envio de e-mail de con�rmação de conta, rede�nição de senha, entre outras
funcionalidades. O levantamento de requisitos tem três objetivos primordiais: expressar as
necessidades do cliente, fornecer a base para a etapa de desenvolvimento e estabelecer uma
base de funções que poderão ser validadas quando o sistema estiver pronto (PRESSMAN;
MAXIM, 2021).
Já os requisitos não funcionais são aqueles que não se relacionam diretamente com o que o
sistema deve fazer, mas sim com como ele deve fazer. Podemos dizer que que os NFRs
expressam premissas ou restrições do software. Eles podem estar relacionados a atributos de
qualidade, desempenho, segurança ou restrições diversas. Alguns exemplos de requisitos não
funcionais são:
O sistema deve estar adaptado para uso em dispositivos móveis.
É necessário que o software possibilite a navegação na interface sem o uso do mouse.
Disciplina
Arquitetura de Software
Deve oferecer suporte para modo o�ine.
Precisa ter uma resposta rápida para cada ação do usuário.
Esses são apenas alguns exemplos que destacam como os NFRs vão além das funcionalidades
básicas do sistema.
A medição da qualidade do software é um dos principais desa�os no processo de
desenvolvimento. É nesse contexto que se consideram os atributos de qualidade, os quais
podem ser de�nidos como um conjunto de características que precisam ser atendidas ao �nal
do processo de desenvolvimento para o produto satisfazer as necessidades dos usuários �nais.
Esses atributos estão diretamente relacionados à lista de requisitos do sistema. Os padrões de
qualidade de software estão de�nidos pela norma internacional ISO/IEC 9126, corroborados pela
norma nacional NBR 13596, e incluem um modelo com seis atributos de qualidade de software,
conforme apresentado no Quadro 1.
ATRIBUTO DESCRIÇÃO
Funcionalidade
O grau com que o software satisfaz as
necessidades declaradas, incluindo:
adequabilidade, exatidão, interoperabilidade,
conformidade e segurança.
Con�abilidade
A disponibilidade do software ao longo do
tempo, incluindo: maturidade, tolerância a
falhas e facilidade de recuperação.
Usabilidade
O grau de facilidade de uso do software,
incluindo: compreensibilidade, facilidade de
aprendizado e operabilidade.
E�ciência
O grau de otimização do uso de recursos pelo
software, incluindo: desempenho em relação ao
tempo e aos recursos.
Facilidade de manutenção
A facilidade com que correções e modi�cações
podem ser realizadas no software, incluindo:
análise, realização de mudanças, estabilidade,
testabilidade.
Portabilidade
A facilidade com que o software pode ser
transferido de um ambiente para outro,
incluindo: adaptabilidade, facilidade de
instalação, conformidade, substituição.
Quadro 1 | Atributos de qualidade do software. - Fonte: adaptado de Pressman e Maxim (2021, p.
418).
Disciplina
Arquitetura de Software
O atendimento dos atributos de qualidade interessa a todos os stakeholders, tanto os envolvidos
no processo de desenvolvimento quanto no uso �nal. Ao mesmo tempo que esses atributos
satisfazem as necessidades do usuário, agregam valor ao produto da empresa.
Os atributos de qualidade estão diretamente ligados às funcionalidades do sistema. São os
atributos que validam se uma funcionalidade está de acordo com o que foi apurado durante a
fase do levantamento de requisitos. Em diversos sistemas, as funcionalidades podem ter limites
conforme o per�l de usuário queo está acessando. Um per�l de usuário pode ter acesso a
determinadas funcionalidades que não estarão disponíveis para outro per�l. Portanto, os
atributos de qualidade também estão relacionados a limitações nas funcionalidades.
Etapas para a modelagem de requisitos e atributos de qualidade
Ao desenvolver um software, é crucial ter um escopo bem de�nido, ou seja, os requisitos
necessários para atender às necessidades das partes interessadas (stakeholders). Nem sempre
os usuários têm uma compreensão clara do que desejam que o software faça e, muitas vezes,
essas necessidades podem mudar ao longo do processo de desenvolvimento.
Por isso, estudante, o levantamento de requisitos desempenha um papel fundamental nesse
processo. É nessa etapa que entendemos o contexto do software a ser desenvolvido, as
necessidades que ele deve atender, as prioridades e os comportamentos esperados. O
levantamento de requisitos pode ser dividido em sete fases, que podem ocorrer
simultaneamente e devem ser adaptadas às necessidades do projeto: concepção, levantamento,
elaboração, negociação, especi�cação, validação e gestão de requisitos. Cada uma dessas fases
desempenha um papel importante no processo, como descrito no Quadro 2.
ETAPA DESCRIÇÃO
Concepção Compreender o problema de forma preliminar,
identi�car os interessados e o problema que
Disciplina
Arquitetura de Software
deve ser solucionado.
Levantamento
Estabelecer as metas de negócio, envolver os
interessados para expor suas necessidades e
de�nir as prioridades, também conhecidas
como valor de negócio.
Elaboração
Criar e re�nar os cenários que descrevem como
os usuários vão interagir com o software,
podendo incluir a criação de casos de uso.
Negociação
Lidar com solicitações con�itantes dos clientes
e usuários, avaliar custos e riscos, eliminar ou
modi�car requisitos e de�nir as prioridades
para atingir a satisfação de todos os
envolvidos.
Especi�cação
Apresentar os requisitos levantados de forma
clara e compreensível, seja por meio de
documentos escritos, grá�cos, cenários de uso
ou protótipo.
Validação
Avaliar a qualidade do levantamento de
requisitos, veri�car se os requisitos foram
declarados corretamente, sem inconsistências,
sem erros, informações ausentes ou requisitos
em con�ito.
Gestão de requisitos Identi�car, controlar e acompanhar as
mudanças nos requisitos ao longo do projeto.
Quadro 2 | Fases do Levantamento de Requisitos. - Fonte: adaptado de Pressman e Maxim (2021,
p. 133-138).
Na etapa de concepção, é importante identi�car os envolvidos, os interessados no sistema e em
sua qualidade. Inicialmente, podemos criar uma lista das pessoas envolvidas, que pode ser
ampliada à medida que o processo avança.
Em seguida, iniciamos o levantamento, que geralmente é realizado de forma colaborativa com os
envolvidos. Cada stakeholder contribui com sua visão sobre o que é necessário para o sistema.
A ideia é reunir todos os interessados em um ambiente propício para a discussão de ideias.
Nesta etapa, diversas ferramentas podem ser utilizadas, como planilhas, �ip charts, notas
adesivas, quadro branco, bate-papo online, fóruns virtuais, entre outras. O importante é que todos
tenham condições de participar e expressar suas necessidades, com a mediação de um
facilitador.
O objetivo é identi�car problemas, propor soluções, negociar diferentes perspectivas e
estabelecer um conjunto preliminar de requisitos. Vale ressaltar que essa fase pode abranger
etapas posteriores, como elaboração, negociação e especi�cação.
Disciplina
Arquitetura de Software
Ao �nal dessas etapas, temos uma visão geral das funções e características do sistema, mas
ainda não temos uma forma de visualizar como essas funções e características serão usadas
pelos diferentes per�s de usuários. É nesse momento que podemos construir os cenários de uso
(ou casos de uso), que são diagramas com descrições de como o sistema será utilizado.
Na etapa de validação, as funcionalidades e suas limitações ou permissões são testadas de
acordo com o levantamento de requisitos. Ao �nal da etapa, pode-se certi�car de que o software
atende aos interesses de todos os envolvidos.
Requisitos e atributos de qualidade na prática
Agora que conhecemos as etapas do processo de levantamento de requisitos e as de�nições de
qualidade de software, vamos expandir nossos estudos com exemplos práticos. Após levantar
requisitos e atributos de qualidade, precisamos criar cenários de uso, também conhecidos como
casos de uso, para tornar mais clara a interação do usuário com o sistema. É preciso lembrar que
o atendimento dos atributos de qualidade interessa a todos os envolvidos, tanto usuários quanto
empresa desenvolvedora.
O primeiro passo é de�nir os atores envolvidos, que são todos que interagem com o sistema
     em diferentes papéis. De acordo com Pressman e Maxim (2021) um ator não é
necessariamente apenas um usuário, é qualquer coisa que se comunica com o sistema e que é
externa ao sistema. Por exemplo, um usuário pode ter um per�l “padrão” e ao mesmo tempo ser
administrador do sistema.
Os atores primários são aqueles que interagem diretamente com o sistema, enquanto os atores
secundários têm papel de suporte para os primários. É importante destacar que a construção de
Disciplina
Arquitetura de Software
diagramas de casos de uso utilizando a Linguagem de Modelagem Uni�cada (UML) é um passo
importante nesse contexto.
Figura 1 | Diagrama de casos de uso. - Fonte: Pressman e Maxim (2021, p. 135).
Na Figura 1, que representa os casos de uso para um sistema de segurança residencial,
podemos perceber a presença de um ator primário: o proprietário. Os atores secundários são as
câmeras, que fornecem os pré-requisitos para as ações dos atores primários.
Disciplina
Arquitetura de Software
Figura 2 | Diagrama de classe. - Fonte: Pressman e Maxim (2021, p. 140).
Na Figura 2, vemos a classe Sistema, que inclui os atributos (idSistema, statusSistema, etc.)  e as
operações de responsabilidade da classe (programar, exibir, etc.). Essa forma de representação
pode auxiliar os programadores durante o processo de codi�cação, visto que é mais próximo da
linguagem utilizada por eles.
Já os atributos de qualidade podem ser elaborados com base em um diagrama de árvore, como
exempli�cado no caso de um sistema web, na Figura 3. Nele, temos o objetivo mais à esquerda,
alguns atributos de qualidade estabelecidos pela ISO/IEC 9126 ao centro e, à direita, as
rami�cações correspondentes à cada um dos atributos. Por exemplo, o processamento correto
dos links web é um comportamento esperado quando falamos de um atributo de Con�abilidade.
Disciplina
Arquitetura de Software
Figura 3 | Diagrama de árvore dos atributos de qualidade. - Fonte: Pressman e Maxim (2021, p. 284).
Esses exemplos práticos nos ajudam a visualizar como o processo de levantamento de
requisitos e as características de qualidade são aplicados na prática, satisfazendo as aspirações
de todos os interessados no produto. É importante salientar que o diagrama de atributos de
qualidade deve representar as funcionalidades e suas limitações e permissões, contemplando os
diversos níveis de acesso, caso levantados nos requisitos.
Videoaula: Atributos de qualidade e suas relações
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Neste vídeo, vamos explorar as etapas essenciais do levantamento de requisitos e dos atributos
de qualidade. Você entenderá a importância desses atributos para o sucesso do produto. Além
disso, veremos, na prática, como transformar uma lista de requisitos em um documento sólido
que será a base para o desenvolvimento do sistema. Não deixe de assistir e aprofundar seus
conhecimentos nesse tema fundamental.
Disciplina
Arquitetura de Software
Saiba mais
Sobre os atributos de qualidade, um artigo interessante para expandir os seus estudos é
Qualidade de Software - Engenhariade Software 29.
Para criar os diagramas de casos de uso, você pode optar por inúmeras ferramentas disponíveis
no mercado. Entre as ferramentas gratuitas, indicamos a Draw.io.
Referências
https://www.devmedia.com.br/qualidade-de-software-engenharia-de-software-29/18209
https://app.diagrams.net/
Disciplina
Arquitetura de Software
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software. Porto Alegre: Grupo A, 2021. E-
book. ISBN 9786558040118. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 17 jul. 2023.
ZENKER, Aline M.; SANTOS, Jailson Costa dos; COUTO, Júlia M C.; et al. Arquitetura de sistemas.
Porto Alegre: Grupo A, 2019. E-book. ISBN 9788595029767. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788595029767/. Acesso em: 17 jul. 2023.
Aula 2
Modelo de qualidade e atributos de negócio
Introdução
https://integrada.minhabiblioteca.com.br/#/books/9786558040118/
https://integrada.minhabiblioteca.com.br/#/books/9788595029767/
Disciplina
Arquitetura de Software
Olá, estudante!
O objetivo dessa aula é explorar a importância da validação e qualidade no contexto dos
negócios e do valor agregado de um produto. Você entenderá os principais conceitos desse
processo, como time-to-market, vida útil do sistema, agenda de lançamento e gestão da
qualidade, que desempenham um papel crucial na entrega de um produto de qualidade.
Compreender esses aspectos permitirá que você aplique os conceitos aprendidos e crie um
diagrama de atributos de qualidade alinhado com os requisitos do sistema. Certi�que-se de ler
todo o conteúdo da aula e não deixe de conferir o material da bibliogra�a para se aprofundar no
assunto.
Bons estudos! 
Características do controle de qualidade
Disciplina
Arquitetura de Software
Quando se trata de qualidade de software, o foco principal é atender às necessidades dos
usuários com base nas etapas de concepção e levantamento. Para um produto ser considerado
de qualidade, ele não deve apenas cumprir suas funções, mas também apresentar con�abilidade
e ausência de erros do sistema.
No entanto, a qualidade tem um preço, tanto para a empresa desenvolvedora quanto para os
usuários, que podem ter que lidar diariamente com erros que di�cultam seu trabalho.
Certamente, é mais barato para a empresa reduzir custos de qualidade durante a fase de
desenvolvimento e usar os clientes como “testadores” do software, corrigindo bugs à medida
que surgem durante o uso do produto. No entanto, em um mercado cada vez mais competitivo,
uma empresa que não seja sinônimo de qualidade tende a perder espaço (PRESSMAN; MAXIM,
2021).
Existem vários tipos de custos associados aos processos de qualidade no desenvolvimento de
software. Podemos citar os custos de prevenção (como o planejamento dos testes e
treinamento); os custos de avaliação (como revisões técnicas); os custos de materiais utilizados
na modelagem, coleta de dados, avaliação de métricas e execução dos testes; os custos de
falhas internas (quando um erro é detectado antes da entrega do produto); os custos de falhas
externas (que envolvem defeitos encontrados após a entrega do produto); e custo do suporte ao
cliente. Os custos de falhas internas e externas também podem aumentar os custos dos outros
tipos, uma vez que o software precisará ser validado novamente após a correção dos erros.
É importante lembrar que os processos de qualidade devem estar presentes ao longo de toda a
vida útil do produto, não apenas durante o processo de desenvolvimento, mas também nas
etapas de operação e manutenção, desde a de�nição dos requisitos até o término de seu uso.
Na aula anterior, discutimos sobre os atributos de qualidades de�nidos na ISO/IEC 9126-1:2001.
Eles são seis atributos ao total: funcionalidade, con�abilidade, usabilidade, e�ciência, facilidade
de manutenção e portabilidade. No caso de aplicações web, podemos acrescentar mais quatro:
segurança (para evitar acesso não autorizado), disponibilidade (porcentagem de tempo em que o
Disciplina
Arquitetura de Software
aplicativo está disponível para uso), escalabilidade (facilidade de redimensionar os servidores de
acordo com a demanda) e time-to-market (tempo necessário para lançar o produto no mercado,
que não é necessariamente um atributo de qualidade técnica, mas aumenta a qualidade
comercial do produto) (PRESSMAN; MAXIM, 2021).
Podemos entender o time-to-market como o tempo decorrido entre a concepção do produto até
sua disponibilização aos clientes, ou seja, o tempo total de desenvolvimento. Vale ressaltar que o
produto que chegar primeiro ao mercado tende a conquistar uma maior fatia do mercado-alvo.
Nesse ponto, há um con�ito entre os atributos de qualidade e os objetivos de negócio. Para os
analistas de negócio, é importante ter um produto minimamente funcional para lançar
rapidamente no mercado-alvo, preferencialmente à frente dos concorrentes. Aproveitar uma
janela oportuna de lançamento oportuna certamente é bené�co para os negócios, mas os
processos de qualidade nem sempre favorecem a rapidez, o que resulta em um maior tempo de
desenvolvimento. É nesse momento que entra em cena a negociação, de�nindo valores de
negócio para funcionalidades que vão atrair mais a atenção dos usuários e, posteriormente,
incrementando o software com novas funcionalidades, que, embora não sejam tão impactantes,
agregam valor ao produto.
Questionamento importantes no processo de qualidade
Disciplina
Arquitetura de Software
Reduzir o time-to-market e aproveitar uma agenda de lançamento oportuna é, sem dúvida, um
desa�o para as equipes de desenvolvimento. É importante ter em mente que ter um software
funcional e em conformidade com os padrões de qualidade gera valor ao produto. A questão é
como conciliar os atributos de qualidade com os atributos de negócio – esse pode ser o segredo
do sucesso.
Na fase de levantamento de requisitos, surgirão diversos requisitos que os stakeholders
consideram importantes para o sistema. No entanto, a cada requisito adicionado, o escopo do
desenvolvimento aumenta, assim como o tempo necessário, não apenas para a codi�cação, mas
também para os processos de qualidade. É nesse ponto que a negociação desempenha um
papel crucial. O responsável pelo produto deve atribuir valor aos requisitos que trarão retorno
mais imediato ao negócio.
Não devemos esperar que um software chegará “pronto” para ser lançado no mercado, pois essa
abordagem é inviável do ponto de vista comercial, devido ao longo tempo de desenvolvimento.
Dessa forma, os responsáveis precisam avaliar o custo-benefício e priorizar funcionalidades
mais relevantes.
Reconhecendo que o software é um produto em constante evolução, sob a perspectiva de um
desenvolvimento iterativo, é possível focar em poucas funcionalidades e realizar o processo de
controle de qualidade de maneira mais e�caz, entregando um produto de qualidade dentro do
prazo de lançamento planejado.
A etapa de controle de qualidade deve seguir os princípios estabelecidos na ISO/IEC 9126-
1:2001. Vamos analisar os atributos e como eles se encaixam no processo. O atributo de
funcionalidade diz respeito à forma como o sistema atende os desejos dos usuários. Podemos
fazer algumas perguntas para avaliar se o software atende esses requisitos:
O software cumpre os padrões de segurança e privacidade dos dados?
O sistema executa as operações necessárias para exibir e manipular as informações
inseridas pelos usuários?
O software atende ao problema que o originou?
O atributo de con�abilidade se refere ao tempo que o sistema está disponível ao usuário.
Podemos fazer seguintes perguntas:
O software é tolerante a falhas?
Quando ocorrem falhas, o sistema consegue se recuperar ou fornece ajuda ao usuário?
O atributo de usabilidade está relacionado ao grau de facilidade de uso. Podemos fazer as
seguintes perguntas:
O layout é facilmente compreensível?
As funcionalidades são fáceis de aprender e entender?
Em relação ao atributo de e�ciência, que mede a otimização do produto, podemos fazer as
seguintes perguntas:O tempo necessário entre uma ação e sua resposta é adequado?
Os recursos de hardware (memória RAM, uso de processador) estão de acordo com as
características do sistema?
Disciplina
Arquitetura de Software
Já o atributo de facilidade de manutenção ou manutenibilidade trata da facilidade de realizar
manutenções no sistema. Podemos validar com as seguintes questões:
O produto é facilmente mantido ou alterado em relação às regras de negócio?
O software é fácil de testar?
O atributo de portabilidade trata da facilidade de mover o sistema de um ambiente para outro.
Algumas perguntas podem ser feitas nesse sentido:
O sistema pode ser adaptado a diferentes ambientes?
O software tem facilidade de substituição e/ou atualização?
O sistema garante a integridade dos dados em diferentes ambientes?
São perguntas simples, mas que, quando validadas adequadamente, podem garantir a qualidade
do produto e seu valor no mercado. 
Processo de qualidade na prática
Vimos anteriormente que o time-to-market é o tempo decorrido desde a concepção até a entrega
de um produto. Como podemos reduzir esse tempo de entrega e manter a qualidade do produto?
Disciplina
Arquitetura de Software
Existem diversas estratégias que podem ser adotadas, embora não haja um padrão especí�co
para medir o time-to-market, pois o ponto de partida pode variar.
Algumas empresas consideram o início do desenvolvimento a partir da etapa de codi�cação,
enquanto outras entendem que começa na etapa de concepção. O término do processo também
é variável: para alguns, é quando o produto está em produção, enquanto, para outros, é a entrega
ao usuário. No entanto, podemos de�nir que o processo começa quando há uma de�nição do
que será feito e a equipe é alocada para o trabalho, e o ponto �nal pode ser considerado quando
a equipe de desenvolvimento e qualidade entrega um MVP (Produto Mínimo Viável) ou a primeira
versão do software.
O grande diferencial para reduzir esse tempo está no planejamento do processo. Um conceito
importante nesse contexto é o lead time, que mede o prazo necessário para atender às
demandas dos clientes. Um lead time aceitável pode ser alcançado por meio da padronização do
processo e da automatização.
Na etapa de concepção, o uso de técnicas como design thinking, user research, lean inception ou
brainstorming podem ajudar a levantar os requisitos de maneira mais assertiva.
A aplicação de padrões de desenvolvimento, ou design patterns, auxilia os programadores a
terem uma referência, um processo bem de�nido de como elaborar o sistema. O uso de um
processo padronizado proporciona maior agilidade, fornecendo uma base consistente e
independente das pessoas envolvidas no processo.
A adoção de testes automatizados, tanto durante o desenvolvimento quanto em incrementos ou
manutenções, reduz signi�cativamente a ocorrência de falhas do produto. Embora a criação de
testes automatizados possa demandar um esforço inicial maior, a médio prazo, reduz a
necessidade de execução manual de testes a cada iteração ou correção do sistema.
Portanto, com o uso de ferramentas colaborativas no levantamento de requisitos, a aplicação de
padrões durante o desenvolvimento e a adoção de testes automatizados na etapa de validação, é
possível reduzir o time-to-market e entregar um produto de qualidade.
Além da automatização de testes que validam as funcionalidades em si, a validação dos
atributos de qualidade pode ser feita por meio da criação de diagramas de árvore contendo os
atributos de qualidade da ISO/IEC 9126-1:2001 e características pertinentes a cada um desses
atributos especí�cos ao sistema em questão. Veja a Figura 1, que representa os atributos de
qualidade e as características que devem ser validadas, com base nos questionamentos que
levantamos anteriormente:
Disciplina
Arquitetura de Software
Figura 1 | Diagrama de atributos de qualidade. - Fonte: elaborada pelo autor.
A Figura 1 é apenas exemplo de como podemos abordar a validação dos atributos de qualidade
ao avaliar um sistema, de modo a assegurar a qualidade do produto.
Portando, ter processos padronizados no desenvolvimento, ter requisitos priorizados e bem
de�nidos, utilizar um processo de validação automatizado e ter um claro entendimento dos
atributos de qualidade pode contribuir para a redução do tempo de produção e agregar qualidade
na entrega do produto.
Videoaula: Modelo de qualidade e atributos de negócio
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Neste vídeo, vamos explorar os aspectos essenciais relacionados à qualidade de software, assim
como possíveis con�itos que podem surgir entre atributos de qualidade e atributos de negócio.
Além disso, abordaremos os conceitos-chave do processo de desenvolvimento como time-to-
market, agenda de lançamento e vida útil de um sistema. Prepare-se para aprofundar seu
Disciplina
Arquitetura de Software
entendimento sobre a qualidade de software e os elementos fundamentais do processo de
desenvolvimento.
Saiba mais
No texto desta aula, citamos algumas técnicas para levantamento de requisitos. Seguem
materiais interessantes que podem ajudar a expandir seus conhecimentos sobre essa temática:
Lean Inception é uma ferramenta colaborativa com o intuito de alinhar um grupo de
pessoas para a de�nição de objetivos e/ou escopo de um projeto. Você pode saber mais
acessando este link.
Design Thinking é outra ferramenta de pensamento criativo focada em gerar soluções para
a resolução de problemas com foco no usuário. Saiba mais neste link.
User Research é uma metodologia focada na investigação dos usuários e seus requisitos,
compreendendo o contexto de uso. Um material explicativo pode ser encontrado neste link.
Brainstorming é uma técnica colaborativa para o surgimento de ideias criativas. Acesse
este link para saber mais.
Sobre os padrões de desenvolvimento ou design patterns, consulte este link.
Referências
https://caroli.org/lean-inception-saiba-como-alinhar-pessoas-e-construir-o-produto-certo/
https://rockcontent.com/br/blog/design-thinking
https://medium.com/senior/mas-afinal-o-que-%C3%A9-ux-research-de-fato-e6e490cd7ce5
https://rockcontent.com/br/blog/brainstorming
https://www.hostgator.com.br/blog/design-patterns-e-seus-beneficios
Disciplina
Arquitetura de Software
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software. Porto Alegre: Grupo A, 2021. E-
book. ISBN 9786558040118. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 17 jul. 2023.
ZENKER, Aline M.; SANTOS, Jailson Costa dos; COUTO, Júlia M C.; et al. Arquitetura de sistemas.
Porto Alegre: Grupo A, 2019. E-book. ISBN 9788595029767. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788595029767/. Acesso em: 17 jul. 2023.
ABNT (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS). NBR ISO/IEC 9126-1 Engenharia de
software – Qualidade de produto – Parte 1: Modelo de qualidade. 2003.
Aula 3
Técnicas de design arquitetural
Introdução
https://integrada.minhabiblioteca.com.br/#/books/9786558040118/
https://integrada.minhabiblioteca.com.br/#/books/9788595029767/
Disciplina
Arquitetura de Software
Olá, estudante!
A arquitetura de software é uma das etapas mais importantes de todo o processo de
desenvolvimento. Ela abrange desde a concepção até o desenvolvimento e validação da
qualidade do software. O papel do arquiteto de software é considerar uma in�nidade de
características e princípios, e tomar decisões que se adequem ao contexto especí�co do projeto.
Nesta aula, vamos estudar as técnicas e os princípios que norteiam a arquitetura de um sistema.
Vamos elencar os diferentes padrões e estilos arquitetônicos utilizados atualmente e
exempli�car como a teoria se aplica na prática, elaborando um documento. O objetivo é entender
como uma arquitetura bem projetada é essencial para o sucesso do desenvolvimento de
sistemas de alta qualidade. Aplique essesconceitos na prática para criar soluções e�cientes e
robustas que atendam às necessidades dos projetos e dos clientes.
Bons estudos!
Principais conceitos da arquitetura de software
Disciplina
Arquitetura de Software
Podemos dizer que arquitetura de software tem a sua importância de�nida por três motivos
principais, de acordo com Zenker et al. (2019):
1. Permite a comunicação de todos os envolvidos no processo.
2. As decisões tomadas na etapa de arquitetura impactarão a forma como o sistema será
desenvolvido, podendo levar a limitações ou problemas se essa etapa for mal executada.
3. Fornece a ideia essencial de como o sistema deve ser estruturado e como todos os
componentes ou camadas se integrarão para se comunicar.
Além disso, através da arquitetura, é possível analisar a efetividade do desenvolvimento no
entendimento e aplicação dos requisitos levantados. Para a arquitetura ou design de um
software, três elementos são imprescindíveis em qualquer sistema:
1. Componentes: pequenas partes do software, cada uma com uma função especí�ca.
2. Propriedades: características relativas a cada componente do sistema.
3. Conectores: descrevem como os componentes se comunicam entre si, promovendo a
integração do sistema por meio de requisições, mensagens, etc.
A separação de preocupações é um conceito importante relacionado aos componentes.
Basicamente, ele preconiza que o sistema deve ser dividido em componentes, de modo que cada
um executa uma tarefa especí�ca, sendo responsável por resolver um problema especí�co, ou
fornecer um serviço a outro componente.
Outro ponto importante são os estilos arquitetônicos. O estilo de�ne a construção dos
componentes, a forma como eles interagem e as propriedades do sistema. O Quadro 1 descreve
os estilos arquiteturais mais utilizados e suas características.
Disciplina
Arquitetura de Software
Arquiteturas centralizadas em dados
O banco de dados é uma parte central, sendo
acessado por outros componentes para
leitura e escrita de dados (PRESSMAN, 2016).
Arquiteturas de �uxo de dados
Os dados de entrada são transformados por
outros componentes. antes de prosseguirem
para o próximo componente (PRESSMAN,
2016).
Arquiteturas de chamadas e retornos
É uma estrutura utilizada em projetos mais
antigos. Há uma divisão entre programas, de
forma que o principal invoca outros
subprogramas (PRESSMAN, 2016).
Arquiteturas orientadas a objetos
Os dados e operações são encapsulados,
permitindo que apenas componentes
especí�cos tenham acesso para a
manipulação. Demais componentes acessam o
componente de manipulação para lidar com os
dados (PRESSMAN, 2016).
Arquiteturas em camadas
O sistema é dividido em camadas, cada uma
realizando operações distintas, com
funcionalidades de interface na camada central
e operações externas atendidas pelas camadas
externas (PRESSMAN, 2016).
Arquiteturas cliente-servidor
Uma das mais utilizadas atualmente, com a
presença do servidor (backend) responsável por
processar e realizar operações conforme
recebe requisições do cliente (frontend). Nesse
estilo, um servidor pode atender a um número
variado de clientes (ZENKER et al., 2019).
Quadro 1 | Estilos arquiteturais. - Fonte: adaptado pelo autor a partir de Pressman (2016) e de
Zenker et al. (2019).
Outro tema importante são os padrões arquiteturais. Os padrões tratam de aspectos mais gerais,
orientando como o sistema se comportará em alguma funcionalidade; ou seja, envolvem
questões de comportamento. Os principais padrões arquiteturais utilizados atualmente são o
MVC, o MVP e o MVVM. O Quadro 2 apresenta os padrões e suas características:
Disciplina
Arquitetura de Software
MVC: Model-View-Controller
Separa partes do sistema atribuindo tarefas
distintas. O Model trata dos dados; a View, da
exibição e interação com o usuário; e a
Controller faz a ligação entre a View e o
Model.
 
MVP: Model-View-Presenter
A tela é disponibilizada pela View, com as
requisições capturadas pela Presenter, que se
conecta ao Model. Este devolve os dados à
Presenter, que os transfere à View para exibição
em tela.
 
MVVM: Model-View-ViewModel
A camada View de�ne a estrutura exibida ao
usuário, enquanto a ViewModel estabelece os
atributos e métodos para que a View exiba
dados e solicite sua manipulação. O Model
contém as regras de negócio e o acesso aos
dados.
 
Quadro 2 | Padrões arquiteturais. - Fonte: Zenker et al. (2019).
No início do trabalho de arquitetura, é importante de�nir o contexto, descrevendo as entidades
externas (pessoas, outros sistemas, dispositivos) que podem interagir com o sistema, com base
no levantamento de requisitos. Após a de�nição do contexto, é possível mapear os arquétipos
arquiteturais, que representam abstrações dos elementos do sistema, ou seja, funcionalidades. A
totalidade desses arquétipos constitui a arquitetura do sistema.
Para representar visualmente este trabalho, é construído o diagrama de contexto arquitetural,
que demonstra como o sistema vai interagir com as entidades externas. O sistema em
desenvolvimento é o centro do processo, enquanto as relações podem ser divididas em:
Sistemas superiores: sistemas que utilizam o sistema principal.
Sistemas subordinados: sistemas que são utilizados pelo sistema principal.
Sistemas do mesmo nível: sistemas que compartilham informações com o principal.
Atores: entidades, pessoas ou dispositivos que utilizarão o sistema principal
Técnicas utilizadas no processo de arquitetura
Disciplina
Arquitetura de Software
A arquitetura de software é a responsável por garantir que o sistema a ser desenvolvido esteja
alinhado com os requisitos e atributos de qualidade. Durante a etapa de arquitetura, são traçados
os estilos e padrões arquiteturais usados no projeto.
No bloco anterior, vimos os principais estilos, padrões e técnicas que podem ser utilizados pelo
arquiteto de software ao elaborar o diagrama arquitetural e outros documentos úteis para o
processo. Agora, veremos como esses conceitos se relacionam com o objetivo de construir um
software de qualidade.
Ao planejar a arquitetura de um sistema, é preciso levar em conta o contexto, compreendendo
quem são os envolvidos e quais dispositivos serão utilizados. Entender o contexto de uso é algo
imprescindível para de�nir o melhor estilo e padrão para o software a ser desenvolvido.
Um sistema deve ser dividido em pequenos sistemas (componentes), de forma que cada um
tenha suas características e responsabilidades (propriedades). Estas são integradas por meio de
comunicação por mensagens internas, �uxo de dados ou requisições web (conectores).
Um componente pode ser de�nido por suas interfaces, ou seja, o que o componente requer para
funcionar e o que ele fornece para o sistema. A Figura 1 ilustra o conceito de um componente:
Disciplina
Arquitetura de Software
Figura 1 | Interfaces de um componente. - Fonte: Zenker et al. (2019).
Os estilos arquiteturais de�nem de forma especí�ca como o sistema se comportará de acordo
com esses princípios fundamentais, incluindo os componentes, as conexões entre eles e as
restrições no �uxo de informações entre os diferentes componentes. Dessa forma, após a
de�nição do estilo, o arquiteto de software pode compreender o sistema de maneira mais geral.
A separação de preocupações ou responsabilidades, outro conceito abordado anteriormente, é
encarada de diferentes formas no sistema de acordo com o estilo arquitetural escolhido. Por
exemplo, um estilo orientado a objetos (Figura 2) terá a separação de preocupações em suas
classes, enquanto um sistema de camadas (Figura 3) dividirá suas funcionalidades de acordo
com as camadas. Um estilo centralizado em dados (Figura 4) vai concentrar as funcionalidades
em outros componentes, deixando para a camada de dados apenas as funções de leitura e
escrita dos dados. Na arquitetura de �uxo de dados (Figura 5), há a transformação dos dados a
cada �ltro.
Disciplina
Arquitetura de Software
Figura 2 | Diagrama de comunicação – arquitetura orientada a objetos. - Fonte: Pressman e Maxim (2021).
Figura3 | Arquitetura em camadas. - Fonte: Pressman e Maxim (2021).
Disciplina
Arquitetura de Software
Figura 4 | Arquitetura centralizada em dados. - Fonte: Pressman e Maxim (2021).
Figura 5 | Arquitetura de �uxo de dados. - Fonte: Pressman e Maxim (2021).
Por sua vez, os padrões arquiteturais, diferente dos estilos, tem foco na estruturação do código
em si, de�nindo as funções das diferentes funcionalidades e principalmente, como as partes
Disciplina
Arquitetura de Software
devem interagir. Os padrões tratam de questões comportamentais especí�cas no contexto da
arquitetura (PRESSMAN; MAXIM, 2016). Padrões MVC (Figura 6) ou o MVP focam em
componentes que exibem os dados em tela, controlam as regras de negócio e realizam as ações
de leitura, processamento e escrita dos dados.
Figura 6 | Padrão MVC. - Fonte: Pressman e Maxim (2021).
Portanto, a de�nição do estilo e padrão, o respeito aos princípios da arquitetura e a separação de
preocupações entre as partes do sistema, escolhidos pelo arquiteto, são cruciais para que os
programadores possam se orientar e desenvolver o sistema de acordo com as necessidades dos
usuários, considerando a qualidade e a estrutura criada pela pessoa arquiteta.
É importante lembrar também que a construção de um diagrama de contexto arquitetural é parte
importante do trabalho da arquitetura. A Figura 7 representa, de maneira genérica, um diagrama
de contexto arquitetural, no qual podemos ver as representações do contexto envolvido:
Disciplina
Arquitetura de Software
Figura 7 | Diagrama de contexto arquitetural. - Fonte: Zenker et al. (2019).
Artefatos gerados pelo arquiteto de software
Disciplina
Arquitetura de Software
O arquiteto de software deve elaborar diversos artefatos relacionados às de�nições da
arquitetura. Nesses artefatos, devem constar os conceitos apresentados anteriormente, tais
como componentes, diagrama de contexto, diagrama de arquétipos e de instância, para
documentar a etapa de arquitetura de um software.
É importante ressaltar que os estilos e padrões arquitetônicos não estarão diretamente
representados nos diagramas, mas são eles que de�nirão a forma como os componentes,
arquétipos, instâncias e contexto serão organizados.
Na Figura 8, vemos a representação de um diagrama de contexto arquitetural de um sistema de
vigilância residencial. Esse diagrama engloba todos os componentes, atores e sistemas que
interagem com o sistema.
Figura 8 | Diagrama de contexto arquitetural de um sistema de vigilância. - Fonte: Pressman e Maxim (2021).
Nesse exemplo, a função de vigilância é um sistema de mesmo nível e utiliza a função de
segurança (sistema principal). Os sistemas superiores são representados pelo produto em si e
por qualquer outro sistema acessado via internet que disponibilize as funções do exemplo. Os
painéis de controle e o proprietário são os atores, enquanto os sensores são sistemas
subordinados, ou seja, componentes utilizados pelo sistema principal.
A Figura 9 apresenta os arquétipos, que são classes ou padrões abstraídos que representam
funcionalidades especí�cas do sistema. Nesse contexto, o nó representa os elementos de
entrada e saída, que podem ser os sensores e os alarmes. O detector é uma abstração que
engloba todos os equipamentos que geram informações de entrada para o sistema. O indicador
representa os mecanismos que indicam alguma mensagem do sistema, por exemplo, uma
sirene. Já o controlador pode ser entendido como a função de ativar/desativar o sistema.
Disciplina
Arquitetura de Software
Figura 9 | Relacionamentos em UML de arquétipos. - Fonte: Pressman e Maxim (2021).
Todo e qualquer requisito levantado deve ser descrito pela arquitetura, visando a obter uma visão
geral dos componentes do sistema. Cabe lembrar que um componente re�ete um
comportamento do sistema. Podemos representar gra�camente um componente, conforme a
Figura 10, que de�ne um componente que coleta e compara dados de um sensor de segurança
residencial:
Disciplina
Arquitetura de Software
Figura 10 | Exemplo de diagrama de componente. - Fonte: Zenker et al. (2019).
Na interface “Requer”, há a entrada de dados que serão processados de acordo com os métodos
da interface “Fornece”. Quanto mais detalhado for o diagrama, mais fácil será a tarefa dos
programadores na hora da codi�cação.
Além de representar cada componente isolado, é preciso ter uma visão geral de como esses
componentes se relacionam. A Figura 11 representa gra�camente a estrutura de componentes
gerais de um sistema de monitoramento residencial.
Disciplina
Arquitetura de Software
Figura 11 | Componentes de alto nível. - Fonte: Pressman e Maxim (2021).
O diagrama deve representar os principais comportamentos descritos na análise de requisitos.
Na imagem, a função de gerenciamento da comunicação externa, por exemplo, é responsável por
coordenar a comunicação com entidades externas, como um app ou um painel de controle. Note
que cada retângulo representa um componente do sistema. É importante frisar que aqui
podemos notar um conceito básico da arquitetura, que é a separação de preocupações. No
diagrama, podemos perceber que cada componente do sistema tem uma função única e
separada dos demais.
Até este ponto, já de�nimos o contexto, os arquétipos, os componentes e a estrutura global do
sistema. Sem embargo, ainda precisamos re�nar um pouco mais. Para isso, é preciso expandir o
diagrama anterior com as instâncias das funcionalidades. A Figura 12 expande a visão dos
componentes.
Disciplina
Arquitetura de Software
Figura 12 | Instância da função de segurança. - Fonte: Pressman e Maxim (2021).
Neste diagrama, temos o comportamento real de uma funcionalidade do sistema. O componente
“Gerenciamento de detectores”, por exemplo, interage com o componente “Agendador”, que, por
sua vez, se conecta com cada um dos sensores existentes.
Ao aplicar os princípios e técnicas de design de arquitetura explorados ao longo da aula, o
arquiteto terá em mãos um material completo e bem elaborado para que se possa iniciar a fase
de desenvolvimento do sistema.
Videoaula: Técnicas de design arquitetural
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Neste vídeo, explanaremos um pouco sobre as responsabilidades do arquiteto de software e as
técnicas e princípios envolvidos no processo de designs arquitetural de um software.
Abordaremos os principais estilos e padrões utilizados atualmente e veremos como transformar
esses conceitos em artefatos que contemplarão uma visão bem elaborada do sistema. 
Disciplina
Arquitetura de Software
Saiba mais
Além dos padrões discutidos nesta aula, há muitos outros, como microsserviços. Você pode
conhecer um pouco mais no artigo “Padrões arquiteturais, quais e como usar?”, de Patrick
Francis Gomes Rocha.
Referências
https://www.linkedin.com/pulse/padr%C3%B5es-arquiteturais-quais-e-como-usar-patrick-francis-gomes-rocha/?originalSubdomain=pt
Disciplina
Arquitetura de Software
PRESSMAN, Roger. Engenharia de software: uma abordagem pro�ssional. 8ª ed. Porto Alegre:
AMGH, 2016.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software. Porto Alegre: Grupo A, 2021.
Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em:
17 jul. 2023.
ZENKER, Aline M.; SANTOS, Jailson Costa dos; COUTO, Júlia M, C.; et al. Arquitetura de sistemas.
Porto Alegre: Grupo A, 2019. E-book. ISBN 9788595029767. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788595029767/. Acesso em: 8 jul. 2023.
Aula 4
Táticas de design
Introdução
https://integrada.minhabiblioteca.com.br/#/books/9786558040118/
https://integrada.minhabiblioteca.com.br/#/books/9788595029767/
Disciplina
Arquitetura de Software
Olá, estudante!
Nesta aula, exploraremos táticas essenciais de design. Abordaremos aspectos importantes da
qualidade na arquitetura de software, como desempenho eescalabilidade; segurança e
tolerância a falhas; e compreensibilidade, modi�cabilidade e operabilidade.
Ao desenvolver um software, é crucial considerar o desempenho e a escalabilidade, garantindo
que ele execute tarefas de forma ágil e possa lidar com um aumento na demanda sem
comprometer sua e�ciência. A segurança é um aspecto primordial para proteger o sistema e as
informações contra ameaças maliciosas, enquanto a tolerância a falhas assegura que o sistema
continue funcionando adequadamente mesmo diante de problemas em componentes
individuais.
Além disso, veremos como tornar um software compreensível, facilitando sua manutenção e
evolução, e como torná-lo altamente modi�cável para se adaptar a novos requisitos. Por �m,
abordaremos a operabilidade, que torna o software fácil de operar e manter em ambiente de
produção.
Táticas essenciais para a arquitetura de software
Disciplina
Arquitetura de Software
Ao desenvolver um software, é essencial levar em conta uma série de aspectos para assegurar
que ele atenda às necessidades dos usuários e possa evoluir com o passar do tempo. Nesse
contexto, algumas táticas de design são fundamentais, tais como o desempenho, a
escalabilidade, a segurança, a tolerância a falhas, a compreensibilidade, a modi�cabilidade e a
operabilidade (ZENKER et al., 2019).
O desempenho de um software diz respeito à sua capacidade de executar tarefas e processos de
forma e�ciente e com boa velocidade. Isso signi�ca que o software deve ser rápido e responsivo
em relação às solicitações dos usuários e às operações que precisa realizar. As métricas de
desempenho incluem tempo de resposta, tempo de processamento e utilização de recursos
como CPU, memória e rede (ZENKER et al., 2019).
Por outro lado, a escalabilidade do software está relacionada à sua capacidade de lidar com um
aumento na demanda sem comprometer o desempenho. Existem duas abordagens principais
para escalabilidade: a vertical, que envolve adicionar mais recursos a um único servidor, e a
horizontal, que distribui o sistema em vários servidores para atender às demandas crescentes de
forma mais e�ciente (ZENKER et al., 2019). A escalabilidade é especialmente importante em
sistemas que precisam lidar com muitos usuários simultâneos, como redes sociais, serviços de
streaming e sites de comércio eletrônico durante eventos de alto tráfego.
Além disso, a segurança do software é um aspecto crucial que visa a proteger o sistema e as
informações contra ameaças e ataques maliciosos. Isso envolve autenticação, autorização,
criptogra�a, controle de acesso e resiliência contra ameaças como vírus, malware e invasões
(ZENKER et al., 2019).
Outro aspecto importante é a tolerância a falhas, que permite ao sistema continuar funcionando
adequadamente mesmo diante de falhas em alguns de seus componentes. O objetivo é evitar
que uma falha isolada cause a interrupção total do sistema (ZENKER et al., 2019).
Para garantir que um software seja compreensível, ele deve ser facilmente entendido e
interpretado por humanos, especialmente pelos desenvolvedores e mantenedores do sistema.
Disciplina
Arquitetura de Software
Um software compreensível possui uma estrutura clara, organização lógica e é bem
documentado, o que facilita a manutenção, a correção de erros e a implementação de novas
funcionalidades (PRESSMAN; MAXIM, 2016).
A modi�cabilidade é a capacidade de um software ser facilmente modi�cado, adaptado ou
estendido para atender a novos requisitos e melhorias. Isso é essencial em um cenário de
desenvolvimento contínuo, em que mudanças frequentes são necessárias para acompanhar as
demandas do mercado. Um software altamente modi�cável possui uma arquitetura bem
de�nida, componentes bem encapsulados, baixo acoplamento entre módulos e uma clara
separação de interesses (PRESSMAN; MAXIM, 2016).
Por �m, a operabilidade refere-se à facilidade de operar e manter o software em ambiente de
produção. Um software operável permite que os operadores, administradores e usuários �nais
utilizem-no de forma e�ciente, realizem tarefas sem di�culdades e solucionem problemas de
maneira ágil. A operabilidade está relacionada à facilidade de con�guração, instalação,
monitoramento, gerenciamento de logs e relatórios de erros (PRESSMAN; MAXIM, 2016).
É importante ressaltar que esses aspectos não são independentes e estão frequentemente
interligados. Um software compreensível tende a ser mais modi�cável e operável, e um software
altamente modi�cável facilita a operação e manutenção e�ciente do sistema. Portanto, ao
projetar e manter sistemas de software, é essencial considerar esses aspectos para garantir um
produto de qualidade, capaz de atender às necessidades em constante evolução do mercado ao
longo do tempo.
Principais técnicas para uma aplicação de qualidade
A arquitetura de software é uma etapa crucial no desenvolvimento de sistemas e�cientes e
escaláveis, capazes de crescer conforme as necessidades. Para alcançar esse objetivo, é
fundamental estabelecer requisitos especí�cos de desempenho e escalabilidade, de�nindo
metas claras para tempo de resposta, taxa de transferência e utilização de recursos. Uma análise
detalhada da carga esperada no sistema é essencial para dimensionar a arquitetura
adequadamente.
Disciplina
Arquitetura de Software
Além disso, a escolha das tecnologias apropriadas desempenha um papel fundamental, pois
diferentes tecnologias podem ter um impacto direto no desempenho e na escalabilidade do
sistema. Aspectos como um projeto de banco de dados escalável, monitoramento contínuo,
testes de carga e desempenho, bem como uma estratégia de escalabilidade bem de�nida, são
elementos essenciais para garantir o sucesso do sistema em cenários reais de uso (ZENKER et
al., 2019).
As decisões arquiteturais não podem negligenciar a segurança em nenhum nível. Técnicas como
redundância e isolamento de componentes críticos são fundamentais para enfrentar falhas e
garantir a integridade do sistema. Medidas como controle de acesso, autenticação e criptogra�a
são imprescindíveis para proteger dados sensíveis. Além disso, testes de segurança e de falhas,
juntamente com um monitoramento e registros detalhados de eventos, desempenham um papel
importante para assegurar a e�cácia das medidas de segurança implementadas.
Os conceitos de compreensibilidade, modi�cabilidade e operabilidade são elementos-chave para
um desenvolvimento bem-sucedido. Para alcançar esses objetivos, várias práticas podem ser
adotadas (PRESSMAN; MAXIM, 2016):
Abstração e modularização: dividir o sistema em módulos bem de�nidos, tornando a
compreensão e a manutenção mais fáceis.
Documentação: criar documentação clara sobre a arquitetura e os padrões de design,
facilitando a compreensão dos diferentes aspectos do sistema.
Padrões de nomenclatura: utilizar nomes signi�cativos para facilitar a compreensão e a
comunicação entre os membros da equipe de desenvolvimento.
Desenhar diagramas e modelos: representar a arquitetura por meio de diagramas e
modelos visuais, proporcionando uma visão mais clara do sistema como um todo.
Uso de padrões de projeto: aplicar padrões de projeto que promovam a modularidade e
�exibilidade, facilitando futuras alterações no sistema.
Automatização de implantação: automatizar o processo de implantação do software,
reduzindo erros humanos e garantindo uma implantação mais rápida e consistente.
Gerenciamento de con�guração: ter controle adequado das con�gurações do sistema,
garantindo que as mudanças sejam gerenciadas de forma controlada e rastreável.
Logs e monitoramento: implementar registro e monitoramento do sistema em produção,
permitindo uma análise detalhada do desempenho e possíveis problemas.
Projeto para con�abilidade: projetar o sistema com redundância e tolerância a falhas,
aumentando a disponibilidade e con�abilidade do sistema.
Testes de operação: realizar testes para garantir o desempenho e a operabilidade do
sistema em diferentes cenários.
Ao adotar esses conceitos e práticas, é possível criar um sistema mais compreensível,
modi�cável e operável,facilitando a manutenção e evolução do software ao longo do tempo.
Além disso, uma arquitetura bem planejada, segura e escalável é a base para um sistema de
sucesso, capaz de atender às necessidades presentes e futuras dos usuários. Portanto, investir
tempo e esforço na etapa de arquitetura é fundamental para o desenvolvimento de sistemas
e�cientes, con�áveis e adaptáveis.
Aplicação das táticas de design
Disciplina
Arquitetura de Software
A aplicação efetiva dos conceitos apresentados anteriormente garantirá não apenas a entrega de
um produto funcional, mas também a construção de um sistema con�ável, seguro e de fácil
manutenção. Ao considerar cuidadosamente esses fatores desde o início do processo de
desenvolvimento, o arquiteto de software poderá criar soluções sólidas que atendam às
necessidades dos usuários e se adaptem às mudanças futuras.
Abaixo estão alguns exemplos práticos da aplicação dos conceitos de desempenho,
escalabilidade, segurança, tolerância a falhas, compreensibilidade, modi�cabilidade e
operabilidade na etapa de arquitetura de software (PRESSMAN; MAXIM, 2016; ZENKER et al.,
2019):
Desempenho e escalabilidade
Exemplo: Uma aplicação de comércio eletrônico.
Desempenho: utilizar cache para armazenar dados frequentemente acessados,
minimizando o tempo de resposta para os usuários. Quando um usuário faz uma
solicitação à aplicação, o servidor de aplicação veri�ca se os dados necessários estão
armazenados em um cache. Se os dados estiverem no cache, o servidor os recupera
diretamente do cache, o que é muito mais rápido do que acessar o banco de dados.
Escalabilidade: projetar a arquitetura de forma que a aplicação possa ser facilmente
distribuída em múltiplos servidores, a �m de lidar com um aumento substancial de tráfego
durante picos de demanda, como vendas sazonais. Dessa forma, a aplicação é capaz de
lidar com um maior número de requisições simultâneas, pois a carga é distribuída entre os
servidores disponíveis. Além disso, os servidores de aplicação podem ser facilmente
Disciplina
Arquitetura de Software
adicionados ou removidos da arquitetura conforme a necessidade, permitindo que a
aplicação seja dimensionada de forma dinâmica para atender às demandas �utuantes de
tráfego.
Segurança e tolerância a falhas
Exemplo: Sistema de gerenciamento de dados con�denciais em uma instituição �nanceira.
Segurança: implementar autenticação e autorização robustas, criptografar dados sensíveis
em repouso e em trânsito, e realizar auditorias regulares para detectar atividades suspeitas.
Tolerância a falhas: utilizar técnicas como replicação de servidores e balanceamento de
carga para garantir a disponibilidade contínua do sistema, mesmo em caso de falhas em
componentes individuais. A replicação dos servidores de aplicação permite que múltiplas
cópias da aplicação sejam executadas em servidores separados. Isso garante que, se um
servidor falhar, outros possam assumir o processamento das requisições.
Compreensibilidade, modi�cabilidade e operabilidade
Exemplo: Sistema de gerenciamento de tarefas em uma equipe de desenvolvimento de software.
Compreensibilidade: organizar o código-fonte em módulos bem de�nidos e utilizar padrões
de projeto claros para facilitar a compreensão do funcionamento do sistema.
Modi�cabilidade: seguir princípios de design, como o da separação de responsabilidades, a
�m de tornar o código facilmente modi�cável sem afetar outras partes do sistema.
Operabilidade: incluir recursos, como logs detalhados e métricas para monitorar o
desempenho do sistema em tempo real, facilitando a identi�cação e correção de
problemas operacionais.
Esses exemplos ilustram como os conceitos de arquitetura de software podem ser aplicados
para garantir que o sistema atenda a requisitos importantes, como desempenho, segurança e
facilidade de manutenção. É essencial considerar esses fatores desde o início do processo de
arquitetura, para evitar problemas futuros e tornar o software robusto e con�ável.
Videoaula: Táticas de design
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Neste vídeo, exploraremos os princípios essenciais de desempenho e escalabilidade, segurança
e tolerância a falhas, bem como compreensibilidade, modi�cabilidade e operabilidade.
Descobriremos como esses elementos fundamentais se entrelaçam para moldar sistemas
Disciplina
Arquitetura de Software
complexos e aplicações inovadoras. Ao desvendar os segredos por trás dessas áreas-chave, o
vídeo oferecerá uma visão panorâmica dos pilares que sustentam a uma aplicação de qualidade.
Assista e amplie seu conhecimento nesse importante mundo da arquitetura de software!
Saiba mais
A seguir, estão algumas ferramentas e recursos que podem fornecer exemplos e auxiliar o
aprendizado sobre os temas abordados nesta aula:
Desempenho e escalabilidade
Apache JMeter: uma ferramenta de teste de carga de código aberto amplamente utilizada para
medir o desempenho e a escalabilidade de aplicações web, serviços e servidores.
Segurança e tolerância a falhas
OWASP WebGoat: uma aplicação web de código aberto propositalmente insegura,
desenvolvida para �ns educacionais, que ensina sobre vulnerabilidades de segurança em
aplicações web.
Chaos Monkey: uma ferramenta de engenharia de caos desenvolvida pela Net�ix, que
introduz aleatoriamente falhas em componentes de sistemas distribuídos para testar a
tolerância a falhas.
Compreensibilidade, modi�cabilidade e operabilidade
SonarQube: uma plataforma de análise de código-fonte que identi�ca problemas de
qualidade, segurança e compreensibilidade do código, auxiliando na sua modi�cação e
operabilidade.
https://jmeter.apache.org/
https://www.owasp.org/index.php/OWASP_WebGoat_Project
https://netflix.github.io/chaosmonkey/
https://www.sonarqube.org/
Disciplina
Arquitetura de Software
Docker: uma plataforma de virtualização de contêineres que permite empacotar, distribuir e
executar aplicações em ambientes isolados, melhorando a operabilidade e a portabilidade do
software.
(Observação: os sites indicados estão originalmente em língua inglesa, mas você pode utilizar a
opção de tradução automática do seu navegador, se preferir.)
Referências
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem pro�ssional. 8ª ed.
Porto Alegre: AMGH, 2016
ZENKER, Aline M.; SANTOS, Jailson Costa dos; COUTO, Júlia M C.; et al. Arquitetura de sistemas.
Porto Alegre: Grupo A, 2019. E-book. ISBN 9788595029767. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788595029767/. Acesso em: 17 jul. 2023.
Aula 5
Resumo da unidade
Técnicas e táticas para um software de qualidade
https://www.docker.com/
https://integrada.minhabiblioteca.com.br/#/books/9788595029767/
Disciplina
Arquitetura de Software
Olá, estudante! Nesta Unidade, você mergulhou em conceitos fundamentais para a criação de
sistemas bem-sucedidos.
Você aprendeu a distinguir os requisitos funcionais, que descrevem as funcionalidades
especí�cas do software, dos requisitos não funcionais, que dizem respeito às características do
sistema, como desempenho, segurança, usabilidade, escalabilidade e outros atributos de
qualidade que afetam a experiência do usuário.
Entendeu que, muitas vezes, melhorar um atributo de qualidade pode exigir um sacrifício em
outro, e explorou estratégias para equilibrar esses con�itos. Isso envolveu considerar como
aprimorar um atributo de qualidade afeta os demais e como encontrar soluções que otimizem o
desempenho geral do sistema.
Investigou quem se bene�cia dos atributos de qualidade, abrangendo tanto os usuários �nais,
que buscam um software e�ciente e fácil de usar, quanto o negócio, que almeja soluções
seguras, escaláveis e que agreguem valor ao produto. Além disso, conheceu o Padrão ISO/IEC
9126-1:2001, que oferece diretrizes para avaliar e medir os atributos de qualidade do software.
Compreendeu como as decisões arquiteturaispodem envolver con�itos entre os objetivos dos
atributos de qualidade e os requisitos do negócio. Aprendeu a lidar com esses con�itos,
encontrando soluções que atendam a ambas as necessidades.
Explorou como fatores externos, como o mercado-alvo do software, o tempo disponível para
desenvolvimento (time-to-market), o orçamento, os benefícios esperados, a vida útil do sistema e
a agenda de lançamento, podem in�uenciar as decisões arquiteturais.
Aprofundou-se nos princípios que norteiam a criação de uma arquitetura e�ciente, garantindo
uma base sólida para a construção do software. Viu como a separação de preocupações é
crucial para lidar com os diferentes aspectos do sistema de forma modular e organizada.
Conheceu padrões e estilos arquiteturais comuns, como o Modelo-Visão-Controlador (MVC).
Compreendeu como essas abordagens podem ser aplicadas para resolver problemas
especí�cos de design e melhorar a manutenibilidade e a escalabilidade do sistema.
Disciplina
Arquitetura de Software
Explorou como projetar o software para alcançar um bom desempenho, garantindo que o
sistema seja rápido e e�ciente, mesmo sob carga elevada. Aprendeu sobre técnicas para
escalabilidade, permitindo que o software cresça e se adapte às necessidades futuras.
Entendeu a importância de garantir a segurança do software, protegendo-o contra ameaças
externas e evitando vulnerabilidades. Além disso, aprendeu a projetar sistemas resilientes e com
tolerância a falhas, de forma que continuem funcionando mesmo quando ocorrerem problemas
inesperados.
Conheceu como tornar o software fácil de entender, modi�car e operar, facilitando a manutenção
e evolução do sistema ao longo do tempo.
Ao �nal desta Unidade, você está equipado com conhecimentos abrangentes sobre a arquitetura
de software e os atributos de qualidade que in�uenciam na criação de sistemas bem-sucedidos
e adaptáveis. Está preparado para aplicar esses conceitos em seus projetos futuros, visando a
entregar soluções de software e�cientes e alinhadas às necessidades do usuário e do negócio.
Videoaula: Resumo da unidade
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Neste vídeo, exploraremos os conceitos fundamentais para criar sistemas bem-sucedidos. Serão
abordados os requisitos funcionais e não-funcionais, estratégias para equilibrar atributos de
qualidade, o Padrão ISO/IEC 9126-1:2001 para medir a qualidade do software e como as
decisões arquiteturais podem afetar o negócio. Exploraremos princípios de uma arquitetura
e�ciente, padrões arquiteturais e técnicas para melhorar o desempenho e a segurança do
software.
Estudo de caso
Disciplina
Arquitetura de Software
Você é um empreendedor apaixonado por educação e tecnologia, e decidiu criar uma plataforma
de aprendizagem online inovadora para atender às necessidades dos estudantes e pro�ssionais
que desejam aprimorar suas habilidades e conhecimentos. O objetivo é fornecer uma experiência
de aprendizado interativa, acessível e �exível, que permita aos usuários desenvolverem suas
competências de forma personalizada e e�caz.
A plataforma de aprendizagem online visa a oferecer cursos em diversas áreas, desde
habilidades técnicas como programação e design grá�co, até conhecimentos mais amplos,
como empreendedorismo e liderança. Além disso, a plataforma terá um recurso de avaliação de
habilidades para ajudar os usuários a identi�carem suas competências e áreas de melhoria.
Desa�o:
Como uma pessoa empreendedora visionária, você entende a importância de lançar o produto no
mercado rapidamente para capturar a atenção dos potenciais usuários e se destacar da
concorrência. No entanto, você também reconhece a complexidade de desenvolver uma
plataforma completa e robusta desde o início.
Seu objetivo neste estudo de caso é criar um MVP (Produto Mínimo Viável) para uma plataforma
de aprendizagem online, utilizando uma abordagem de lançamento em partes evolutivas. A ideia
é começar com um conjunto básico de recursos e funcionalidades que permitam aos usuários
experimentarem a proposta de valor da plataforma, enquanto novos recursos são adicionados ao
longo do tempo para aprimorar a experiência do usuário e atingir o “time-to-market” o mais
rápido possível.
Tarefas:
Identi�que os recursos e funcionalidades essenciais que comporão o MVP da plataforma de
aprendizagem online. Explique como esses recursos atendem às necessidades dos usuários e
contribuem para a proposta de valor do produto.
Desenvolva um plano detalhado para o lançamento em partes evolutivas do produto. Divida o
desenvolvimento em etapas especí�cas, indicando quais recursos e funcionalidades serão
Disciplina
Arquitetura de Software
incluídos em cada etapa. Justi�que a ordem das etapas e explique como elas vão aprimorar a
experiência do usuário ao longo do tempo.
Descreva as estratégias que você usará para coletar feedback dos usuários durante o
lançamento do MVP. Como você vai analisar e incorporar esse feedback para melhorar o produto
nas próximas iterações?
Discuta os principais desa�os e riscos que podem surgir durante o desenvolvimento e
lançamento do MVP. Proponha soluções para mitigar esses desa�os e garantir o sucesso do
projeto.
Lembre-se de considerar aspectos técnicos, �nanceiros e de gestão de projetos ao elaborar seu
plano para a criação do MVP e o lançamento em partes evolutivas da plataforma de
aprendizagem online. Sua análise e estratégias devem ser fundamentadas, com base em
pesquisa de mercado e análise das necessidades dos usuários potenciais.
_______
Re�ita
Assumir a liderança no desenvolvimento de um novo sistema é uma tarefa desa�adora e repleta
de responsabilidades. Nesse cenário, é fundamental considerar alguns princípios essenciais para
o sucesso do projeto.
Primeiramente, ao elaborar a lista de requisitos funcionais e não funcionais, é fundamental
manter o foco no propósito do sistema e nas necessidades do negócio. Cada requisito deve ser
cuidadosamente avaliado para garantir que esteja alinhado com os objetivos da empresa e com
as expectativas dos usuários �nais.
Além disso, é importante atentar-se aos atributos de qualidade do sistema. A busca por um
equilíbrio entre atributos de qualidade e de negócio é imprescindível para garantir que o sistema
atenda às demandas do mercado e proporcione uma experiência positiva aos usuários.
Na arquitetura do novo sistema, é crucial evitar complexidade desnecessária, buscando a
simplicidade sempre que possível. Optar por padrões de desenvolvimento consolidados pode ser
uma estratégia acertada, pois eles oferecem uma base sólida e bem testada para o projeto. 
Videoaula: Resolução do Estudo de caso
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Para criar um MVP (Produto Mínimo Viável) e�caz para a plataforma de aprendizagem online, é
importante focar em um conjunto básico de recursos e funcionalidades que demonstrem a
proposta de valor do produto. Com base nas informações fornecidas, sugerimos as seguintes
etapas para o lançamento em partes evolutivas:
Etapa 1: base do MVP
Disciplina
Arquitetura de Software
Nesta fase inicial, concentre-se em construir os seguintes recursos essenciais:
Página inicial e cadastro de usuários: crie uma página de entrada atraente e intuitiva para
os usuários se cadastrarem na plataforma.
Catálogo de cursos: disponibilize uma seleção inicial de cursos que os usuários poderão
explorar e escolher.
Sistema de pagamento: implemente um método de pagamento seguro para que os
usuários possam se inscrever em cursos pagos.
Aulas interativas:
Etapa 2: melhorando a experiência
Com o MVP básico no ar, é hora de aprimorar a experiência do usuário, adicionando recursos
mais avançados:
Fóruns de discussão: integre fóruns para que os alunos possaminteragir, compartilhar
conhecimentos e tirar dúvidas.
Avaliação de habilidades: implemente um sistema de avaliação para que os usuários
possam medir seu progresso e identi�car áreas de melhoria.
Certi�cados: ofereça certi�cados de conclusão para incentivar os usuários a concluírem os
cursos.
Personalização:
Etapa 3: expansão de conteúdo e recursos
Nesta fase, amplie o catálogo de cursos e a variedade de recursos para melhorar a plataforma:
Novos cursos e instrutores: colabore com instrutores renomados e parceiros para
aumentar o número de cursos disponíveis.
Recursos complementares: adicione exercícios práticos, e-books e materiais extras para
aprofundar o aprendizado.
Funcionalidades sociais: integre recursos de compartilhamento nas redes sociais para
ampliar o alcance da plataforma.
Sistema de recompensas:
Estratégia de feedback e melhoria contínua
Para coletar feedback dos usuários, utilize pesquisas, avaliações de cursos e análise de métricas
de uso. Com base nos resultados, priorize as melhorias e correções de bugs mais relevantes em
cada nova etapa de lançamento.
Desa�os e mitigação de riscos
Os principais desa�os podem incluir a concorrência acirrada no mercado de educação online e
problemas técnicos inesperados. Para mitigar esses riscos, faça uma análise detalhada da
concorrência e garanta a estabilidade do sistema por meio de testes rigorosos.
Resumo visual
Disciplina
Arquitetura de Software
Fonte: elaborada pelo autor.
Referências
Disciplina
Arquitetura de Software
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem pro�ssional. 8ª ed.
Porto Alegre: AMGH, 2016
ZENKER, Aline M.; SANTOS, Jailson Costa dos; COUTO, Júlia M C.; et al. Arquitetura de sistemas.
Porto Alegre: Grupo A, 2019. E-book. ISBN 9788595029767. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788595029767/. Acesso em: 17 jul. 2023.
,
Unidade 3
Documentação da Arquitetura de Software
Aula 1
Documentação da arquitetura
Introdução
https://integrada.minhabiblioteca.com.br/#/books/9788595029767/
Disciplina
Arquitetura de Software
Olá, estudante!
A arquitetura de software desempenha um papel fundamental ao de�nir a organização dos
componentes, as relações entre eles e os princípios orientadores do desenvolvimento de     
sistemas. Ela proporciona uma visão global do sistema e contribui para a tomada de decisões
críticas relacionadas à modularidade, reusabilidade, desempenho, segurança e outros atributos
de qualidade. Além disso, a documentação da arquitetura é essencial para comunicar e
compartilhar o conhecimento sobre a arquitetura, garantindo que sua visão seja compreendida
por todos os membros da equipe.
Nesta aula, você aprenderá sobre os elementos que compõem a arquitetura de software,     
incluindo a documentação, que auxilia no processo de design e ferramentas de comunicação.
Além disso, exploraremos a integridade conceitual, que é composta por modelos para análise e
ferramenta de rastreabilidade. Com esse conhecimento, você estará preparado para
compreender e aplicar de forma efetiva os conceitos e práticas relacionados à arquitetura de
software em seus futuros projetos.
Bons estudos!
Conceitos essenciais de arquitetura de software
Disciplina
Arquitetura de Software
A arquitetura de software desempenha um papel fundamental no desenvolvimento de sistemas
de software de qualidade. Ela de�ne a estrutura e organização do sistema, incluindo os
componentes principais, as interações entre eles e as decisões de design (BASS; CLEMENTS;
KAZMAN, 2012). Essa documentação auxilia o �uxo de comunicação e o ciclo de vida do
software. Veremos, nesta aula, a importância da arquitetura de software e discutiremos os
principais documentos utilizados para documentar essa arquitetura. Uma arquitetura bem
projetada permite a modularidade, a reutilização de componentes, a escalabilidade e a
manutenibilidade do sistema. Além disso, ela mitiga riscos técnicos e facilita a comunicação
entre a equipe de desenvolvimento (SHAW; GARLAN, 1996).
A ideia é provermos uma arquitetura que seja clara e bem de�nida com visão geral da estrutura
do sistema, a qual ajude a identi�carmos seus componentes principais e suas interações. Isso
faz que os desenvolvedores observem o sistema como um todo, bem como propicia o trabalho
em equipe; dessa forma, evitam-se problemas de acoplamento excessivo entre os componentes
(FARLEY, 2021).
O processo de design é uma fase que pode in�uenciar a arquitetura de software. Farley (2021)
explica que esse processo tem o foco em atuar nos requisitos do sistema e envolve a
identi�cação e a seleção de estratégias de design apropriadas para atender aos requisitos
funcionais e não funcionais do sistema. Durante esse processo, os arquitetos de software
utilizam várias técnicas, métodos e ferramentas para criar uma arquitetura sólida e coerente.
A integridade conceitual é um tópico importante para o desenvolvimento de software, pois
garante que o sistema seja consistente, preciso e atenda aos requisitos estabelecidos. Ela se
refere à consistência das de�nições, conceitos e abstrações utilizadas na arquitetura e no design
Disciplina
Arquitetura de Software
do software (BASS; CLEMENTS; KAZMAN, 2012). Para alcançar a integridade conceitual, é
necessário estabelecer um modelo para análise e utilizar ferramentas de rastreabilidade.
De acordo com Kruchten (2004), o modelo para análise é uma representação estruturada e
abrangente do software, que permite identi�car e analisar os componentes, as relações entre
eles e suas propriedades. Ele ajuda a compreender a estrutura global do software e a validar sua
integridade conceitual. Sommerville (2011) destaca que o modelo para análise pode incluir
diagramas arquiteturais, diagramas de classes, diagramas de sequência e outras representações
visuais que auxiliam a análise e a validação da arquitetura. Por �m, a utilização de um modelo
para análise permite veri�car se os componentes estão corretamente de�nidos, se suas
responsabilidades estão adequadamente atribuídas e se as interações entre eles são
consistentes com as expectativas do sistema .
Para manter a integridade conceitual ao longo do ciclo de vida do software, é fundamental
utilizar as ferramentas de rastreabilidade. Essas ferramentas permitem rastrear as relações entre
diferentes artefatos do software, desde os requisitos iniciais até as decisões de design e a
implementação �nal (SOMMERVILLE, 2011). A rastreabilidade propicia a identi�cação de
dependências, a detecção de possíveis impactos de mudanças e a garantia de que todos os
elementos do sistema estejam alinhados com os requisitos e com a arquitetura. Essa
abordagem ajuda a manter a integridade conceitual do software e facilita a evolução e a
manutenção do sistema ao longo do tempo.
Processos de design e arquitetura de software
Disciplina
Arquitetura de Software
Vimos anteriormente que a documentação da arquitetura de software é uma atividade essencial
para comunicar e preservar as decisões de design tomadas durante o desenvolvimento do
sistema. Existem diversos documentos utilizados nesse processo, cada um com sua �nalidade
especí�ca. A seguir, destacamos alguns dos principais documentos da arquitetura de software:
1. Visão geral da arquitetura (architecture overview): esse documento descreve uma visão
geral do sistema, incluindo seus componentes, suas interações e as decisões arquiteturais
fundamentais.
2. Diagramas de arquitetura: os diagramas de arquitetura são representações grá�cas da
estrutura do sistema e de suas interações. O Quadro 1 a seguir mostra os principais tipos:
Diagrama de Arquitetura Descrição
Diagrama de Blocos
Representa a arquitetura do sistema em
termos de blocos ou componentes e suas
interações de alto nível.
Diagrama de Componentes Mostra a estrutura do sistema em termos de
componentes, suas interfaces e dependências.
Diagrama de Sequência
Ilustra as interações entre objetos no sistema,
destacando a sequência de mensagens
trocadas entre eles ao longo do tempo.
Diagrama de Casosde Uso
Descreve as interações entre atores (usuários
ou sistemas externos) e o sistema, mostrando
os principais casos de uso e suas relações.
Diagrama de Fluxo de Dados
Representa o �uxo de dados entre processos e
as entidades externas que interagem com o
sistema.
Quadro 1 | Modelos de diagramas de arquitetura. - Fonte: adaptado pelo autor a partir de
Sommerville (2011).
1. Descrição da arquitetura (architecture description): esse documento detalha a arquitetura
do sistema de forma mais aprofundada. Ele descreve os componentes individuais do
sistema, suas responsabilidades, interfaces, restrições e requisitos não funcionais
relevantes (BASS; CLEMENTS; KAZMAN, 2012).
2. Razões e decisões arquiteturais (architectural rationale): esse documento registra as
razões e decisões por trás das escolhas arquiteturais feitas durante o desenvolvimento do
sistema. Ele ajuda a justi�car as decisões tomadas e a fornecer um histórico para futuras
alterações e evoluções da arquitetura (KRUCHTEN, 2004).
3. Padrões arquiteturais (architectural patterns): os padrões arquiteturais são soluções
recorrentes para problemas de arquitetura. Eles facilitam o entendimento e a comunicação
entre os membros da equipe de desenvolvimento (BASS; CLEMENTS; KAZMAN, 2012).
Cervantes e Kazman (2016) destacam os diferentes estilos arquiteturais, como arquitetura em
camadas, arquitetura orientada a serviços (SOA), arquitetura baseada em microsserviços,
arquitetura cliente-servidor e muitos outros.
Na arquitetura em camadas, o sistema é dividido em camadas ou níveis hierárquicos, de modo
que cada camada possui uma responsabilidade especí�ca. Geralmente, a comunicação ocorre
Disciplina
Arquitetura de Software
de forma unidirecional, das camadas inferiores para as superiores. Na arquitetura orientada a
serviços, mais conhecida em inglês como service-oriented architecture (SOA), o sistema é
composto por serviços independentes e reutilizáveis (BASS; CLEMENTS; KAZMAN, 2012). Cada
serviço representa uma funcionalidade especí�ca e é projetado para ser autônomo, com
interfaces bem de�nidas.
Na arquitetura baseada em microsserviços, o sistema é dividido em serviços menores e
independentes, que são responsáveis por funcionalidades especí�cas. A comunicação entre eles
geralmente ocorre por meio de chamadas de application programming interface (API). Na
arquitetura cliente-servidor, o sistema é dividido em duas partes principais: o cliente (que é a
interface com o usuário) e o servidor (que fornece os recursos e a lógica de negócio). A
comunicação entre o cliente e o servidor ocorre por meio de solicitações e respostas.
Por �m, devemos citar a arquitetura em camadas MVC (Model-View-Controller), a qual é um
subconjunto do estilo arquitetural em camadas, focado em sistemas de software para interface
com o usuário. Esse estilo promove a separação de responsabilidades e facilita a manutenção e
a evolução da interface com o usuário.
Vale ressaltar que durante o processo de design, a comunicação efetiva entre os membros da
equipe de desenvolvimento é essencial. Para isso, é importante utilizar ferramentas adequadas
que permitam a colaboração e o compartilhamento de informações sobre a arquitetura do
software.
Aplicando conceitos de integridade conceitual e ferramentas de
rastreabilidade
Disciplina
Arquitetura de Software
Vimos anteriormente conceitos e a importância do uso de diagramas na arquitetura de software.
Porém, algumas ferramentas de modelagem e design especí�cas podem dar suporte às
implementações. Essas ferramentas oferecem recursos avançados, como a geração automática
de diagramas a partir de modelos, a análise de dependências e a rastreabilidade dos requisitos
(KRUCHTEN, 2004). Exemplos de ferramentas são Lucidchart, Draw.io, Microsoft Visio, StarUML,
Visual Paradigm, e Astah.
No entanto, vale ressaltar que a escolha e o uso das ferramentas devem ser adaptados às
necessidades e à cultura da equipe de desenvolvimento. O foco deve ser na efetividade da
comunicação e na facilidade de uso das ferramentas selecionadas (MAXIM; PRESSMAN, 2021).
Por outro lado, as ferramentas de rastreabilidade são usadas para manter a integridade
conceitual ao longo do ciclo de vida do software. Essas ferramentas permitem rastrear as
relações entre diferentes artefatos do software, desde os requisitos iniciais até as decisões de
design e a implementação �nal (SOMMERVILLE, 2011). A rastreabilidade auxilia a identi�cação
de dependências, a detecção de possíveis impactos de mudanças e a garantia de que todos os
elementos do sistema estejam alinhados com os requisitos e com a arquitetura.
Existem diversas ferramentas de rastreabilidade disponíveis no mercado, as quais podem ser
utilizadas para registrar e acompanhar as relações entre requisitos, componentes arquiteturais,
testes, código-fonte e outros artefatos do sistema.
Enterprise Architect: é uma ferramenta de modelagem abrangente que permite criar
diagramas e modelos para representar a arquitetura do software. Ela oferece recursos de
Disciplina
Arquitetura de Software
rastreabilidade, permitindo estabelecer links entre requisitos, componentes, testes e outras
entidades do sistema (CERVANTES; KAZMAN, 2016).
Visual Paradigm: é uma plataforma de modelagem e design que suporta a criação de
diversos tipos de diagramas, como diagramas de caso de uso, diagramas de classe e
diagramas de sequência. Ela também oferece recursos de rastreabilidade (CERVANTES;
KAZMAN, 2016; SOMMERVILLE, 2011).
Lucidchart: essa ferramenta foca na diagramação online e permite criar diagramas de
arquitetura e estabelecer vínculos entre os elementos do sistema. Embora seja
amplamente utilizada para criação de diagramas, também oferece recursos básicos de
rastreabilidade (BASS; CLEMENTS; KAZMAN, 2012).
JIRA: embora seja conhecida principalmente como uma ferramenta de gerenciamento de
projetos e rastreamento de problemas, o JIRA também pode ser usado para rastrear
relacionamentos entre requisitos, componentes e outras entidades do software (DOAR,
2011). Ele oferece recursos de rastreabilidade e é amplamente utilizado em ambientes de
desenvolvimento ágil.
Em conclusão, vamos imaginar um projeto de desenvolvimento de software para uma empresa.
Os documentos de arquitetura descreveriam a estrutura do sistema, indicando como os
componentes se relacionam, como os usuários interagem com o aplicativo, e quais tecnologias e
padrões arquiteturais foram escolhidos. A equipe implementa um processo de design bem
de�nido, que inclui a análise de requisitos, a modelagem da arquitetura, a de�nição de interfaces
e a implementação.
Após isso, a integridade conceitual é aplicada ao garantir que todas as decisões de design
estejam em conformidade com os princípios e requisitos de�nidos no início do projeto. A equipe
pode ainda utilizar diagramas UML para modelar a estrutura do sistema. Por �m, uma ferramenta
de rastreabilidade para acompanhar as mudanças nos requisitos ao longo do tempo. Quando um
requisito é modi�cado, a ferramenta registra a alteração, permitindo que a equipe saiba
exatamente quando e por que a mudança foi feita.
Videoaula: Documentação da arquitetura
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Agora que você está familiarizado com alguns dos conceitos básicos de arquitetura de software,
é hora de aprofundar seus conhecimentos assistindo à videoaula sobre este conteúdo. Teremos
a oportunidade de explorar algumas fases da arquitetura de software e a importância de sua
documentação. Além disso, vamos abordar o processo de design e as ferramentas de
Disciplina
Arquitetura de Software
comunicação, mostrando ainda como o modelo para análise e ferramenta de rastreabilidade são
úteis.
Saiba mais
Sugerimos uma referência para que você possa aprofundar um pouco mais seus conhecimentos
sobre arquitetura de software: O que é Arquitetura orientada a serviços?Referências
https://aws.amazon.com/pt/what-is/service-oriented-architecture/
Disciplina
Arquitetura de Software
AMAZON. O que é Arquitetura orientada a serviços? Disponível em:
https://aws.amazon.com/pt/what-is/service-oriented-architecture/. Acesso em: 15 jul. 2023.
BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. Software Architecture in Practice. 3a ed. Boston:
Addison-Wesley, 2012.
CERVANTES, Humberto; KAZMAN, Rick. Designing software architectures: a practical approach.
Boston: Addison-Wesley Professional, 2016.
DOAR, Matthew. Practical JIRA Administration: Using JIRA Effectively: Beyond the
Documentation. Sebastopol: O’Reilly Media Inc., 2011.                                              
FARLEY, David. Modern Software Engineering: Doing What Works to Build Better Software Faster.
Boston: Addison-Wesley Professional, 2021.
KRUCHTEN, Philippe. The Rational Uni�ed Process: An Introduction. 3a ed. Boston: Addison-
Wesley, 2004.
MAXIM, B. R.; PRESSMAN, Roger S. Engenharia de software: uma abordagem pro�ssional. Porto
Alegre: Bookman, 2021.
SHAW, Mary; GARLAN, David. Software Architecture: Perspectives on an Emerging Discipline.
Upper Saddle River: Prentice Hall, 1996.
SOMMERVILLE, Ian. Engenharia de software. São Paulo: Pearson Education, 2011.
Aula 2
Decisões arquiteturais
https://aws.amazon.com/pt/what-is/service-oriented-architecture/
Disciplina
Arquitetura de Software
Introdução
Olá, estudante!
A arquitetura de software é um campo essencial no desenvolvimento de sistemas complexos e
de larga escala. Ela envolve a tomada de diversas decisões ao longo do processo de criação,
desde a concepção até a implementação. Essas decisões têm o poder de moldar a estrutura e o
comportamento do sistema, in�uenciando diretamente sua qualidade, desempenho e
capacidade de evolução.
Nesta aula, focaremos nas decisões que permeiam a arquitetura de software, com destaque para
as decisões existenciais, descritivas e executivas. As decisões existenciais são aquelas que
determinam a própria existência do sistema, como a escolha entre desenvolver um novo sistema
ou adaptar um existente. Já as decisões descritivas são responsáveis por de�nir a estrutura, os
componentes e as interações do sistema. Por �m, as decisões executivas englobam a de�nição
de estratégias, políticas e diretrizes que guiam o desenvolvimento do sistema. Aproveite essa
jornada no mundo da arquitetura de software.
Bons estudos!
Conceitos de decisões arquitetônicas em softwares
Disciplina
Arquitetura de Software
Barbosa (2009) de�ne uma decisão arquitetural como sendo “uma escolha entre as alternativas
de design arquitetural, que se propõe a alcançar um ou mais atributos de qualidade do sistema,
por meio de estruturas ou regras que ela envolve ou de�ne”. Para tanto, a seguir, apresentaremos
os três tipos principais.
O primeiro tipo engloba as decisões existenciais, responsáveis por de�nir a própria existência do
sistema. Elas mostram que devem existir um ou mais elementos arquiteturais no projeto da
construção do software (BARBOSA, 2009; PFEIFER et al., 2022). Essas decisões estão
relacionadas à escolha entre desenvolver um novo sistema ou adaptar um existente, além de
determinar o escopo e os objetivos do projeto. Portanto, segundo Kruchten, Lago e Vliet (2006),
elas são decisões de arquitetura que podem ser classi�cadas como estruturais e
comportamentais e devem ser consideradas de forma positiva para o projeto.
Ao enfrentar uma decisão existencial, os arquitetos de software devem considerar uma série de
fatores, como a viabilidade técnica e econômica, as necessidades dos usuários e as demandas
do negócio. Nesse processo, a avaliação de riscos também desempenha um papel crucial.
Segundo Bass, Clements e Kazman (2012), é importante analisar a incerteza associada a cada
opção e identi�car os riscos envolvidos, a �m de tomar uma decisão informada.
Segundo Hofmeister, Nord e Soni (2000), essa abordagem pode reduzir o tempo de
desenvolvimento e os riscos associados a um novo sistema. No entanto, é importante avaliar
cuidadosamente a capacidade de o sistema existente suportar as mudanças desejadas e
garantir que a arquitetura resultante seja �exível e escalável.
O segundo tipo engloba as decisões descritivas, que são responsáveis por de�nir a estrutura, os
componentes e as interações do sistema. Essas decisões envolvem a escolha de padrões de
Disciplina
Arquitetura de Software
projeto, estilos arquiteturais, tecnologias e protocolos de comunicação, e têm um impacto
signi�cativo na coesão, modularidade e �exibilidade do sistema.
No processo de tomada de decisões descritivas, os arquitetos de software devem considerar
diversas fontes de informação. Bass, Clements e Kazman (2012) destacam a importância de
conhecer as melhores práticas e os padrões estabelecidos no campo da arquitetura de software.
Esses conhecimentos podem ser aplicados para selecionar as abordagens mais adequadas para
a estruturação do sistema.
Além disso, a análise dos requisitos do sistema é essencial para tomar decisões descritivas
informadas. É fundamental compreender as necessidades dos usuários, os objetivos do negócio
e as restrições técnicas. Hofmeister, Nord e Soni (2000) enfatizam que a arquitetura de software
deve ser projetada de forma a atender aos requisitos funcionais e não funcionais, como
desempenho, segurança e escalabilidade.
Por �m, há ainda as decisões executivas, que são responsáveis por de�nir estratégias, políticas e
diretrizes que guiam o desenvolvimento do sistema (KRUCHTEN; LAGO; VLIET, 2006). Kruchten
(2004) enfatiza que essas decisões envolvem aspectos relacionados aos processos de negócios,
como design do desenvolvimento do software e a tomada de decisão a respeito de quais
tecnologias e ferramentas devem ser envolvidas no projeto.
Ao tomar decisões executivas, os arquitetos de software devem considerar uma variedade de
fatores. Uma dessas considerações é a de�nição de requisitos não funcionais. Os requisitos não
funcionais, como desempenho, usabilidade e segurança, têm um impacto direto na qualidade do
sistema. Os requisitos devem ter uma de�nição clara e precisa para que sejam orientados da
forma correta na arquitetura do software (BASS; CLEMENTS; KAZMAN, 2012).
Aprofundando nos tipos de decisões arquiteturais
Disciplina
Arquitetura de Software
Um aspecto importante a ser considerado nas decisões existenciais é o alinhamento com a
estratégia de negócio. A escolha da arquitetura de software deve estar alinhada com os objetivos
de longo prazo da organização. De acordo com Shaw e Garlan (1996), a arquitetura deve ser vista
como uma estratégia para atingir metas organizacionais e permitir a evolução contínua do
sistema ao longo do tempo.
Além disso, as decisões existenciais também podem estar relacionadas à escolha de soluções
comerciais prontas ou desenvolvimento interno. A decisão de adquirir um sistema comercial
pode ser apropriada quando o sistema atende à maioria dos requisitos e oferece benefícios em
termos de tempo de implementação e suporte. No entanto, é importante considerar a
capacidade de personalização e integração dessas soluções com os sistemas existentes.
Segundo Cervantes e Kazman (2016), a tomada de decisões existenciais é uma etapa crítica no
projeto de arquiteturas de software. A seleção do tipo de sistema a ser desenvolvido, levando em
consideração aspectos como custo, tempo e qualidade, pode afetar diretamente o sucesso do
projeto. Farley (2021) ressalta que as decisões existenciais também devem considerar o
contexto organizacional e a capacidade de a equipe de desenvolvimento lidar com os desa�os
técnicos envolvidos.
De acordo com Kruchten (2004), as decisões existenciais podem ainda ser in�uenciadas pelo
processo de desenvolvimento de software adotado. Nesse sentido, metodologias ágeis de
projeto podem favorecer a adaptação de sistemas existentes.
Vimos anteriormente que, ao contrário das decisões existenciais, as decisões descritivas não
de�nem partes do sistema, mas são responsáveis por de�nir sua estrutura, componentese
interações (BARBOSA, 2009). Essas decisões envolvem a escolha de padrões de projeto, estilos
Disciplina
Arquitetura de Software
arquiteturais, tecnologias e protocolos de comunicação, e têm um impacto signi�cativo na
coesão, modularidade e �exibilidade do sistema.
No processo de tomada de decisões descritivas, os arquitetos de software devem considerar
diversas fontes de informação. Bass, Clements e Kazman (2012) destacam a importância de
conhecer as melhores práticas e os padrões estabelecidos no campo da arquitetura de software.
Esses conhecimentos podem ser aplicados para selecionar as abordagens mais adequadas para
a estruturação do sistema.
Além disso, a análise dos requisitos do sistema é essencial para tomar decisões descritivas
informadas. É fundamental compreender as necessidades dos usuários, os objetivos do negócio
e as restrições técnicas. Hofmeister, Nord e Soni (2000) enfatizam que a arquitetura de software
deve ser projetada de forma a atender aos requisitos funcionais e não funcionais, como
desempenho, segurança e escalabilidade.
Farley (2021) destaca a importância de incorporar medidas de segurança em todas as camadas
do sistema para garantir a proteção adequada dos dados e a con�dencialidade das informações
quando das decisões executivas. Cabe ressaltar a segurança do sistema. A proteção de dados
sensíveis, a prevenção de ataques cibernéticos e a conformidade com regulamentações são
aspectos que devem ser considerados na arquitetura de software.
A escalabilidade é outro atributo importante a ser considerado nas decisões executivas. A
capacidade de um sistema lidar com um aumento na carga de trabalho e no número de usuários
é fundamental para garantir um desempenho e�ciente. Nesse sentido, a escolha de abordagens
escaláveis, como a distribuição de carga e a escalabilidade horizontal, pode permitir que o
sistema se adapte às necessidades em constante evolução (HOFMEISTER; NORD; SONI, 2000).
Aplicando os conceitos das decisões arquitetônicas
Disciplina
Arquitetura de Software
As decisões existenciais são aquelas que têm um impacto duradouro e fundamental no sistema.
Em muitos casos, as decisões existenciais são difíceis de serem modi�cadas posteriormente
sem causar grandes impactos. São como a espinha dorsal do software, in�uenciando sua
estrutura, escalabilidade e manutenibilidade. Re�itamos sobre um exemplo: imagine um novo
projeto para desenvolver um sistema de gerenciamento de projetos em uma empresa de TI.
Uma decisão existencial seria escolher entre uma arquitetura monolítica e uma arquitetura
baseada em microsserviços. Essa decisão terá um grande impacto na estrutura do sistema, na
forma como os componentes se comunicam e na escalabilidade do software. Ela também
afetará as equipes de desenvolvimento, pois requer diferentes habilidades e abordagens para
implementação e manutenção.
Vale ressaltar que, ao tomar decisões existenciais, os arquitetos de software devem buscar um
equilíbrio entre os benefícios de desenvolver um novo sistema e os custos e riscos associados a
essa abordagem. Essas decisões devem ser baseadas em uma análise cuidadosa das
necessidades do negócio, das demandas dos usuários, dos recursos disponíveis e das restrições
do projeto.
Por sua vez, as decisões descritivas estão relacionadas à documentação e comunicação da
arquitetura de software; descrevem como o sistema foi projetado e explicam as decisões
existenciais tomadas. Essas decisões são importantes para garantir que todas as partes
interessadas, incluindo a equipe de desenvolvimento, gerentes e stakeholders, compreendam a
estrutura do sistema e possam colaborar de forma e�caz.
Vejamos um exemplo prático: voltando ao cenário que acabamos de apresentar sobre um
sistema de gerenciamento de projetos, uma decisão descritiva seria a criação de documentos
Disciplina
Arquitetura de Software
detalhados de arquitetura, incluindo diagramas de alto nível e descrições dos padrões
arquiteturais utilizados. Essa documentação ajudaria os membros da equipe a compreender
melhor a arquitetura e garantiria que todos estejam alinhados em relação às decisões tomadas.
Kruchten (2004) destaca a importância de selecionar o estilo arquitetural mais apropriado com
base nas características e nos requisitos do sistema em questão. Cervantes e Kazman (2016)
ressaltam que a aplicação correta de padrões de projeto pode melhorar a qualidade, a
manutenibilidade e a extensibilidade do sistema.
Sobre as decisões executivas, vimos que elas se referem a escolhas feitas durante a
implementação, evolução e manutenção do sistema. Elas são tomadas com base nas decisões
existenciais e podem ser adaptadas de acordo com as necessidades do projeto e as mudanças
nos requisitos. Por isso, Cervantes e Kazman (2016) enfatizam que as decisões sobre as
tecnologias a serem utilizadas devem considerar tanto os requisitos técnicos quanto os
objetivos do negócio. A seleção adequada de tecnologias, linguagens de programação e
frameworks pode in�uenciar a e�ciência e a manutenibilidade do sistema.
Além disso, as decisões executivas também devem levar em consideração o desempenho do
sistema. KRUCHTEN (2004) destaca a importância de medir e avaliar o desempenho do sistema
para identi�car possíveis melhorias. A otimização de recursos, a minimização de gargalos e a
melhoria do tempo de resposta são aspectos que podem ser abordados na arquitetura de
software.
Consideremos um exemplo prático: durante a implementação do sistema de gerenciamento de
projetos visto anteriormente, a equipe pode tomar uma decisão executiva de adotar um
framework especí�co para lidar com autenticação e autorização dos usuários. Essa decisão é
uma implementação detalhada da decisão existencial de escolher uma arquitetura baseada em
microsserviços, que exige uma abordagem �exível e descentralizada para gerenciar as
permissões de acesso.
Videoaula: Decisões arquiteturais
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Agora que você está familiarizado com alguns dos conceitos de arquitetura de software, é hora
de aprofundar seus conhecimentos assistindo à videoaula deste conteúdo. Veremos como são
feitas as decisões do tipo existenciais, as decisões descritivas, decisões executivas. Elas
desempenham um papel fundamental no desenvolvimento de sistemas. Além disso, vamos
abordar a aplicação dos atributos das decisões arquitetônicas, mostrando como esses
elementos in�uenciam a construção e a evolução de software.
Disciplina
Arquitetura de Software
Saiba mais
Sugerimos uma referência para que você possa aprofundar um pouco mais seus conhecimentos
sobre a metodologia ágil no processo de arquitetura de software, con�ra a matéria Metodologia
Ágil - O que é?
Referências
https://www.alura.com.br/artigos/o-que-e-metodologia-agil
https://www.alura.com.br/artigos/o-que-e-metodologia-agil
Disciplina
Arquitetura de Software
ALURA. Metodologia Ágil – O que é? Disponível em: https://www.alura.com.br/artigos/o-que-e-
metodologia-agil. Acesso em: 1 ago. 2023.
BARBOSA, Guilherme Mauro Germoglio. Um livro-texto para o ensino de projeto de arquitetura de
software. Dissertação (Mestrado em Ciência da Computação) – Universidade Federal de
Campina Grande, Centro de Engenharia Elétrica e Informática. Campina Grande, 2009. Disponível
em:
http://dspace.sti.ufcg.edu.br:8080/xmlui/bitstream/handle/riufcg/12033/GUILHERME%20MAUR
O%20GERMOGLIO%20BARBOSA%20-
%20DISSERTA%C3%87%C3%83O%20%28PPGCC%29%202009..pdf. Acesso em: 28 jul. 2023.
BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. Software Architecture in Practice. 3a ed. Boston:
Addison-Wesley, 2012.
CERVANTES, Humberto; KAZMAN, Rick. Designing software architectures: a practical approach.
Boston: Addison-Wesley Professional, 2016.
FARLEY, David. Modern Software Engineering: Doing What Works to Build Better Software Faster.
Boston: Addison-Wesley Professional, 2021.
HOFMEISTER, Christine;NORD, Robert L.; SONI, Dilip. Applied Software Architecture. Boston:
Addison-Wesley Professional, 2000.
KRUCHTEN, Philippe. The Rational Uni�ed Process: An Introduction. 3a ed. Boston: Addison-
Wesley, 2004.
KRUCHTEN, Philippe. LAGO, Patricia; VLIET, Hans van. Building Up and Reasoning About
Architectural Knowledge. In: Proceedings of the 2nd international conference on Quality of
Software Architectures (QoSA), Västerås, Suécia, p. 43–58, 2006,.
PFEIFER, Stefan; AKGÜL, Didem; RÖBENACK, Silke; TIHLARIK, Amelie; ALBERT, Bruno; ANACKER,
Harald; DUMITRESCU, Roman. Design Decisions in the Architecture Development of Advanced
https://www.alura.com.br/artigos/o-que-e-metodologia-agil
https://www.alura.com.br/artigos/o-que-e-metodologia-agil
http://dspace.sti.ufcg.edu.br:8080/xmlui/bitstream/handle/riufcg/12033/GUILHERME%20MAURO%20GERMOGLIO%20BARBOSA%20-%20DISSERTA%C3%87%C3%83O%20%28PPGCC%29%202009..pdf
http://dspace.sti.ufcg.edu.br:8080/xmlui/bitstream/handle/riufcg/12033/GUILHERME%20MAURO%20GERMOGLIO%20BARBOSA%20-%20DISSERTA%C3%87%C3%83O%20%28PPGCC%29%202009..pdf
http://dspace.sti.ufcg.edu.br:8080/xmlui/bitstream/handle/riufcg/12033/GUILHERME%20MAURO%20GERMOGLIO%20BARBOSA%20-%20DISSERTA%C3%87%C3%83O%20%28PPGCC%29%202009..pdf
Disciplina
Arquitetura de Software
Systems: Towards traceable and sustainable Documentation and Communication. Copenhague:
NordDesign, 2022.
SHAW, Mary; GARLAN, David. Software Architecture: Perspectives on an Emerging Discipline.
Upper Saddle River: Prentice Hall, 1996.
Aula 3
Visões arquiteturais
Introdução
Olá, estudante!
A documentação de arquitetura de software é de suma importância para o desenvolvimento de
sistemas complexos, permitindo uma compreensão clara e detalhada das decisões arquiteturais
tomadas durante o processo de projeto. Entre várias abordagens de documentação arquitetural,
três modelos têm se destacado como referências importantes na área: o 4+1 de Kruchten, os
viewpoints de Rozanski e Woods, e os viewtypes do Software Engineering Institute (SEI).
Cada um desses modelos oferece uma perspectiva única para representar a arquitetura,
abordando as preocupações especí�cas dos stakeholders e proporcionando uma visão
abrangente do sistema em desenvolvimento. No entanto, apesar dos muitos benefícios
oferecidos por essas metodologias de documentação, elas também enfrentam desa�os e
di�culdades na aplicação prática, exigindo uma abordagem cuidadosa e estruturada para atingir
Disciplina
Arquitetura de Software
resultados efetivos e alinhados com os objetivos do projeto. Nesse sentido, esta aula tem o
objetivo de esclarecer cada um desses modelos de forma mais detalhada.
Bons estudos!
Fundamentos dos modelos arquiteturais
O Modelo 4+1 de Kruchten é uma abordagem de arquitetura de software proposta por Philippe
Kruchten em 1995 (KRUCHTEN, 2004). Essa abordagem visa a fornecer uma visão completa e
abrangente do sistema em desenvolvimento, ajudando os arquitetos de software na
compreensão, comunicação e documentação da arquitetura do sistema. Várias organizações
têm aplicado esse modelo com sucesso em projetos de diferentes tamanhos e domínios.
Esse modelo combina quatro visões principais da arquitetura de software, juntamente com um
conjunto adicional de casos de uso para capturar os requisitos funcionais do sistema.
Disciplina
Arquitetura de Software
Figura 1 | Modelo 4+1 de Kruchten. - Fonte: adaptada pelo autor a partir de Kruchten (2004).
Os viewpoints são uma abordagem sistemática para capturar diferentes perspectivas sobre a
arquitetura de software, levando em consideração as preocupações especí�cas dos
stakeholders, ou partes interessadas. Para enfrentar os desa�os inerentes a esse processo,
diversos pesquisadores e pro�ssionais têm buscado abordagens inovadoras para capturar,
comunicar e documentar a arquitetura de software. Entre essas abordagens, os viewpoints
propostos por Rozanski e Woods (2012) se destacam como uma contribuição signi�cativa.
O conceito de viewpoints foi introduzido por Garlan e Shaw (1993). Eles destacaram a
importância de olhar para a arquitetura de software sob diferentes perspectivas para melhor
entender as preocupações dos stakeholders. Essa ideia serviu de base para o desenvolvimento
da abordagem de Rozanski e Woods, que aprimoraram essa visão ao fornecer uma estrutura
sistemática para a utilização de viewpoints.
Bass, Clements e Kazman (2012) destacam a importância da documentação arquitetural como
um meio de comunicar a arquitetura de software de forma clara e compreensível para os
stakeholders. Ao discutir a utilização de viewpoints e perspectivas, eles ressaltam que a criação
de diferentes visões da arquitetura, cada uma com foco em preocupações especí�cas dos
stakeholders, é essencial para garantir que todos os envolvidos tenham uma visão clara do
sistema.
Ao utilizar viewpoints, é possível obter uma visão mais abrangente do sistema, uma vez que cada
viewpoint representa uma perspectiva especí�ca sobre a arquitetura (CLEMENTS; KAZMAN;
KLEIN, 2002). Através da combinação e análise dessas diferentes visões, os arquitetos podem
avaliar a qualidade e a adequação da arquitetura em relação aos requisitos e metas
estabelecidas pelos stakeholders. Porém, vale ressaltar que a documentação arquitetural não
deve se limitar a uma única visão, mas sim abranger múltiplos viewpoints que representem as
perspectivas especí�cas de cada grupo de stakeholders (CLEMENTS et al., 2003).
Disciplina
Arquitetura de Software
O Software Engineering Institute (SEI) é um centro de pesquisa e desenvolvimento patrocinado
pelo Departamento de Defesa dos Estados Unidos. Ele se dedica a melhorar as práticas de
engenharia de software. O SEI  é responsável por instituir o modelo conhecido como Integração
do Modelo de Maturidade de Capacidade (CMMI) para melhorar os processos de
desenvolvimento de software em organizações. Também desenvolveu alguns modelos e
viewtypes que facilitam a documentação e a comunicação das arquiteturas. Dentre os modelos
propostos pelo SEI, destacam-se o Modelo de Visões e o Modelo de Viewtypes (CLEMENTS et al.,
2003).
O Modelo de Viewtypes, o qual é uma extensão do Modelo de Visões, descreve um conjunto
especí�co de visões, denominadas “viewtypes”. Cada viewtype é uma representação arquitetural
focada em um conjunto particular de elementos e relacionamentos, permitindo uma visualização
mais detalhada de aspectos especí�cos do sistema (HOFMEISTER et al., 2002). Os viewtypes
são particularmente úteis para organizar a documentação arquitetural e garantir que cada visão
do sistema seja adequadamente comunicada aos stakeholders relevantes.
Aprofundando nos modelos arquiteturais
Vimos anteriormente alguns conceitos de visões declaradas por Kruchten (2004), os quais
formam o modelo 4+1. Vamos agora explorar melhor esse modelo.
A primeira dessas visões refere-se à visão lógica, por meio da qual seriam identi�cados os
componentes principais do sistema, como catálogo de produtos, carrinho de compras e
Disciplina
Arquitetura de Software
processamento de pedidos. Essa visão ajuda a entender como esses componentes estão
interconectados e quais funcionalidades são fornecidas por cada um deles. Ela é descrita por
meio de diagramas de classes, diagramas de pacotes ou outras notações adequadas para
representar a estrutura lógica do software (SHAW; GARLAN, 1996).
A próxima visão é a de desenvolvimento e aborda a organização do trabalho de desenvolvimento
do software, identi�cando as diferentes unidades de trabalho atribuídas a equipes ou
desenvolvedores (BASS; CLEMENTS; KAZMAN, 2012). Nessa visão, os responsáveis
implementam cada componente do sistema. Por exemplo, uma equipe poderia ser responsável
pelo desenvolvimento do catálogo de produtos, enquanto outra equipe cuidaria do carrinho de
compras.
A visão física, por sua vez, enfoca os aspectos de implantação e distribuição do sistema,
descrevendo como os componentes do sistema são implantados em hardware especí�co
(SHAW; GARLAN, 1996). Nessa visão, são ainda identi�cados os servidores,bancos de dados e
outros recursos de hardware necessários para implantar o sistema de comércio eletrônico.
Por último, a visão de processos concentra-se nos aspectos dinâmicos do sistema, descrevendo
os �uxos de dados e as interações entre os diferentes componentes em tempo de execução
(BASS; CLEMENTS; KAZMAN, 2012). Por exemplo, quando um cliente adiciona um item ao
carrinho de compras, é necessário atualizar o catálogo de produtos e processar o pagamento.
Além das quatro visões, o modelo 4+1 também incorpora uma quinta dimensão: os casos de
uso. Esses descrevem as interações entre os atores externos e o sistema, representando os
requisitos funcionais do software (KRUCHTEN, 2004). Eles são usados para capturar os
principais cenários de uso do sistema e ajudar a validar a arquitetura proposta.
Por sua vez, a abordagem desenvolvida por Rozanski e Woods (2012) é baseada na utilização de
viewpoints para representar diferentes perspectivas do sistema. Cada viewpoint é desenvolvido
em torno de um conjunto especí�co de stakeholders e suas necessidades. Essa abordagem
garante que as decisões arquiteturais sejam tomadas levando em consideração as
preocupações e prioridades de todos os stakeholders relevantes.
Os viewpoints propostos por Rozanski e Woods incluem, por exemplo, o viewpoint de contexto
 (que descreve a relação entre o sistema e seu ambiente externo) e o viewpoint de informações
(que se concentra nas necessidades e �uxos de dados dentro do sistema). Outros viewpoints,
como o viewpoint de estrutura (que descreve a organização interna do sistema) e o viewpoint de
comportamento (que se concentra nas interações e sequências de eventos dentro do sistema),
também são fundamentais para uma visão abrangente da arquitetura.
Por �m, vimos que o Modelo de Visões do SEI é uma abordagem que promove a representação
da arquitetura de software a partir de diversas perspectivas, conhecidas como “visões”. Esse
modelo enfatiza a importância de entender a arquitetura de múltiplos pontos de vista para
melhor atender aos interesses e necessidades dos stakeholders envolvidos no projeto
(ROZANSKI; WOODS, 2012). Cada visão no Modelo de Visões se concentra em uma área
especí�ca da arquitetura, como lógica, processos, física e cenários, proporcionando uma
compreensão mais abrangente e detalhada do sistema, conforme abaixo.
Modelo de Visão Lógica Concentra na estrutura lógica
do sistema de software e
descreve os componentes
principais do sistema, e as
ROZANSKI & WOODS (2012)
Disciplina
Arquitetura de Software
pendências funcionais entre
eles
Modelo de Visão de
Processos
Concentra nos aspectos
relacionados à execução do
sistema, como a distribuição
de tarefas e a coordenação
entre processos e threads
HOFMEISTER et al. (2002)
Modelo de Visão Física
Aborda os aspectos da
arquitetura relacionados à
implantação do software em
hardware especí�co, incluindo
a distribuição física dos
componentes em diferentes
nós de processamento
MEDVIDOVIC et al. (2000)
Modelo de Visão de Cenários
Descreve a arquitetura sob a
perspectiva de casos de uso e
cenários de interação com o
sistema, auxiliando na
interação entre os
stakeholders e o software em
situações especí�cas
CLEMENTS, KAZMAN & KLEIN
(2002)
Modelo de Visão de
Informação
Foca nos aspectos
relacionados à gerência e à
organização no sistema
CLEMENTS et al. (2003)
Quadro 1 | Modelo de visões do SEI. - Fonte: elaborado pelo autor.
Aplicando os modelos arquiteturais
Disciplina
Arquitetura de Software
No que tange às ferramentas de mercado que utilizam o modelo 4+1, existem várias opções
disponíveis. Por exemplo, o Processo Uni�cado Racional (RUP), descrito por Kruchten (2004), é
uma metodologia que incorpora o modelo 4+1 em suas diretrizes de desenvolvimento de
software. A RUP fornece um conjunto de práticas e modelos arquiteturais que auxiliam o projeto
e a implementação de sistemas de software.
O Enterprise Architect, da Sparx Systems, é uma ferramenta popular que permite a criação de
diagramas de classes, diagramas de sequência e outros modelos arquiteturais necessários para
representar as diferentes visões do sistema. Outras ferramentas, como o Visual Paradigm,
MagicDraw e Lucidchart, também oferecem recursos semelhantes para a modelagem de
software com base no modelo 4+1.
Para aplicar efetivamente a abordagem dos viewpoints de Rozanski e Woods (2012), existem
várias ferramentas e métodos disponíveis. A modelagem arquitetural é uma técnica comum para
representar os viewpoints em diagramas e outros artefatos visuais. Ferramentas como UML
(Uni�ed Modeling Language) e SysML (Systems Modeling Language) são frequentemente
Disciplina
Arquitetura de Software
usadas para criar representações visuais dos viewpoints. Além disso, a utilização de ferramentas
de gerenciamento de requisitos e colaboração, como JIRA (DOAR, 2011) ou Con�uence, pode
facilitar a coleta e análise das necessidades dos stakeholders, auxiliando a de�nição dos
viewpoints relevantes.
De forma prática, a utilização de viewtypes propostos pelo SEI ajuda a identi�car problemas
potenciais e antecipar desa�os durante o desenvolvimento e a evolução do sistema (CLEMENTS
et al., 2003). Traremos agora algumas formas de aplicarmos os viewtypes do SEI em diversos
tópicos.
Viewtype de segurança: foca em identi�car as medidas de segurança implementadas na
arquitetura de software para proteger o sistema contra ameaças e ataques (CLEMENTS;
KAZMAN; KLEIN, 2002).
Viewtype de desempenho: processo que aborda questões relacionadas ao desempenho do
sistema, como tempos de resposta, latência, utilização de recursos e capacidade de
escalabilidade (MEDVIDOVIC et al., 2000).
Viewtype de interface do usuário: é um serviço que se concentra na representação da
interação do sistema com os usuários �nais (GARLAN; SHAW, 1993). Ele inclui elementos
como grá�cos, �uxos de navegação e layout.
Viewtype de banco de dados: processo que permite descrever a organização e a estrutura
do banco de dados do sistema, mostrando como os dados são armazenados, acessados e
manipulados pela arquitetura (CLEMENTS et al., 2003).
Viewtype de comunicação: processo que ajuda a de�nir os mecanismos e protocolos
utilizados para a comunicação entre os componentes do sistema distribuído (ROZANSKI;
WOODS, 2012).
A parte prática e aplicável dos viewtypes do SEI está relacionada com a adoção dos serviços
acima durante o ciclo de desenvolvimento de software. Alguns exemplos de aplicação prática
incluem:
Em relação às viewtypes de segurança, a equipe pode identi�car possíveis vulnerabilidades
e de�nir medidas de segurança para proteger o sistema contra ameaças e ataques, por
meio de técnicas de criptogra�a, autenticação de usuários, controle de acesso e proteção
contra injeção de código malicioso.
Em relação às viewtypes de comunicação, podemos imaginar o uso de sistemas
distribuídos, e a equipe pode usar esta visão para de�nir os mecanismos e protocolos de
comunicação entre os componentes.
Nas viewtypes de interface do usuário, a equipe pode utilizar esta visão para representar como o
sistema interage com os usuários �nais. Isso pode incluir a criação de wireframes, protótipos
interativos e designs de interface grá�ca.
Videoaula: Visões arquiteturais
Disciplina
Arquitetura de Software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Você já possui um conhecimento básico sobre visões arquiteturais de software; é hora de
aprofundar seus conhecimentos assistindo a esta videoaula, na qual você terá a oportunidade de
aprender o modelo 4+1 de  Kruchten e os viewpoints de Rozanski e Woods. Também conhecerá
os modelos de visões e viewtypes do SEI e quais são os benefícios para as equipes e para os
stakeholders do projeto.
Saiba mais
Para aprofundar seu conhecimento sobre os temas relacionados à Integração do Modelo de
Maturidade de Capacidade (CMMI), recomendamos a leitura do capítulo8.6 do livro Gestão de
Tecnologia da Informação - Governança de TI: Arquitetura e Alinhamento entre Sistemas de
Informação e o Negócio, de Carneiro Ramos Molinaro.
Referências
https://integrada.minhabiblioteca.com.br/reader/books/978-85-216-1972-7/pageid/144
https://integrada.minhabiblioteca.com.br/reader/books/978-85-216-1972-7/pageid/144
https://integrada.minhabiblioteca.com.br/reader/books/978-85-216-1972-7/pageid/144
Disciplina
Arquitetura de Software
BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. Software Architecture in Practice. 3a ed. Boston:
Addison-Wesley, 2012.
CLEMENTS, Paul; KAZMAN, Rick; KLEIN, Mark. Evaluating Software Architectures: Methods and
Case Studies. Boston: Addison-Wesley Professional, 2002.
CLEMENTS, Paul; GARLAN, David; REED, Little; NORD, Robert; STAFFORD, Judith. Documenting
software architectures: views and beyond. In: Proceedings of the 25th International Conference
on Software Engineering, IEEE, p. 740-741, 2003.
DOAR, Matthew. Practical JIRA Administration: Using JIRA Effectively: Beyond the
Documentation. Sebastopol: O’Reilly Media Inc., 2011.
GARLAN, David; SHAW, Mary. An Introduction to Software Architecture. Advances in Software
Engineering and Knowledge Engineering. Pittsburgh: School of Computer Science, 1993.
HOFMEISTER, Christine; NORD, Robert L.; SONI, Dilip. Documenting Software Architectures: Views
and Beyond. Boston: Addison-Wesley Professional, 2002.
KRUCHTEN, Philippe. The Rational Uni�ed Process: An Introduction. 3a ed. Boston: Addison-
Wesley, 2004.
MEDVIDOVIC, Nenad; TAYLOR, Richard N.; OREIZY, Peyman. A Classi�cation and Comparison
Framework for Software Architecture Description Languages. IEEE Transactions on Software
Engineering, 2000.
ROZANSKI, Nick; WOODS, Eoin. Software systems architecture: working with stakeholders using
viewpoints and perspectives. Boston: Addison-Wesley, 2012.
SHAW, Mary; GARLAN, David. Software Architecture: Perspectives on an Emerging Discipline.
Upper Saddle River: Prentice Hall, 1996.
Disciplina
Arquitetura de Software
Aula 4
Estudo de caso – sistema de aluguel e streaming de �lmes (SASF)
Introdução
Olá, estudante!
O cenário do entretenimento tem sido profundamente impactado pelo surgimento de
plataformas digitais de aluguel e streaming de �lmes. Com o avanço da tecnologia e a crescente
busca dos consumidores por conteúdo sob demanda, os sistemas de aluguel e streaming de
�lmes (SASF) têm se tornado uma escolha popular para ciné�los e entusiastas do cinema.
Nesta aula, exploraremos as funcionalidades do SASF e analisaremos o impacto das
transmissões simultâneas, tempos de resposta, tamanho do inventário e o número de operações
diárias. Também discutiremos a importância de um inventário bem gerenciado e como o
crescimento constante do catálogo de �lmes pode afetar as operações diárias das empresas do
setor.
Além disso, abordaremos possíveis soluções e estratégias para otimizar a e�ciência e a
capacidade de resposta dessas plataformas, garantindo uma experiência de usuário �uida e
atraente. Compreender os aspectos do SASF vai prepará-lo para enfrentar os desa�os.
Bons estudos!
Conceitos do sistemas de aluguel e streaming de �lmes (SASF)
Disciplina
Arquitetura de Software
O sistema de aluguel e streaming de �lmes (SASF) é uma plataforma inovadora que vem
transformando a maneira como as pessoas acessam e desfrutam de conteúdo cinematográ�co.
Desenvolvido por uma equipe de especialistas em tecnologia, o SASF proporciona aos usuários
uma experiência abrangente e diversi�cada no mundo do entretenimento audiovisual.
Uma das principais funcionalidades do SASF é o amplo catálogo de �lmes disponíveis para
aluguel ou streaming sob demanda. Com a capacidade de acessar uma vasta biblioteca de
títulos, desde clássicos do cinema até os lançamentos mais recentes, os usuários têm o poder
de escolher entre diferentes gêneros, diretores e estilos cinematográ�cos, conforme suas
preferências pessoais. Isso foi possível graças ao trabalho de Smith e Telang (2016), que
destacam o impacto da tecnologia de streaming e big data na indústria do entretenimento, e
também ao estudo de Barbosa (2009), que abordou a importância do ensino de projeto de
arquitetura de software para desenvolver plataformas como o SASF.
A interface intuitiva e amigável do SASF permite uma navegação �uida e e�ciente. Os usuários
podem facilmente encontrar �lmes por meio de pesquisas, �ltros personalizados e
recomendações inteligentes baseadas no histórico de visualizações, algoritmos de aprendizado
de máquina e técnicas de análise de dados (RICCI et al., 2011). Essa capacidade de sugestão
personalizada é fundamental para engajar os usuários e manter o interesse no serviço ao longo
do tempo.
Outro destaque do SASF é a sua compatibilidade com várias plataformas e dispositivos, como
smartphones, tablets, smart TVs e computadores. Essa �exibilidade garante que os usuários
possam desfrutar de seus �lmes favoritos em qualquer lugar e a qualquer momento. Funk (2003)
destaca a mobilidade de consumo de mídia, um tema relevante na era digital, e que se refere à
capacidade de as pessoas acessarem conteúdo de mídia, como �lmes, programas de TV,
músicas e outros tipos de entretenimento, em diferentes dispositivos e locais.
Disciplina
Arquitetura de Software
O sistema de aluguel e streaming de �lmes (SASF) enfrenta diversos desa�os relacionados a
transmissões simultâneas, tempos de resposta, tamanho do inventário e número de operações
por dia (BARBOSA, 2009). Esses desa�os são inerentes ao contexto da indústria do
entretenimento e ao crescimento exponencial do consumo de conteúdo audiovisual através da
internet e dispositivos móveis (FUNK, 2003).
A alta demanda por �lmes e séries em streaming, associada à necessidade de atender a um
grande número de usuários simultaneamente, pode levar a gargalos no sistema e redução do
tempo de resposta para as requisições (SMITH; TELANG, 2016). Além disso, a diversidade do
catálogo de �lmes e a necessidade de manter constantemente atualizado o inventário de títulos
disponíveis representam um desa�o adicional (BARBOSA, 2009).
Para enfrentar esses desa�os, o SASF pode adotar uma arquitetura de microsserviços, de modo
que cada funcionalidade essencial é tratada por um componente independente (BARBOSA,
2009). Dessa forma, é possível distribuir a carga de trabalho e equilibrar o número de operações
por dia, tornando o sistema mais escalável e capaz de atender a um maior número de usuários
simultaneamente.
Outras características, benefícios e desa�os do SASF
Um dos maiores benefícios do SASF é que ele oferece a opção de download temporário de �lmes
para visualização o�ine, atendendo à demanda de consumidores que desejam assistir a
conteúdo sem depender da conexão à internet. Segundo Barbosa (2019), uma alternativa viável é
Disciplina
Arquitetura de Software
assistir aos �lmes através da internet, utilizando o streaming de vídeo por meio de um dispositivo
ou aplicativo que esteja compatível com o SASF. Essa opção dispensa a necessidade de
aguardar a entrega física da mídia pelos correios ou o tempo de download do vídeo antes de
iniciar a reprodução, uma vez que o conceito do streaming é possibilitar o consumo do arquivo
de mídia à medida que ele é transmitido.
Outra inovação trazida pelo SASF é a disponibilidade de conteúdo em resolução 4K e até mesmo
em formatos de realidade virtual (VR). Tricart (2018) a�rma que essas tecnologias de ponta
proporcionam uma experiência imersiva e envolvente aos usuários, permitindo que eles
mergulhem no mundo dos �lmes de uma forma nunca antes experimentada. A resolução 4K
oferece imagens com maior nitidez e detalhes visuais, aprimorando a qualidade visual das
produções cinematográ�cas, enquanto a realidade virtual cria uma sensação de presença e
interatividade, fazendo que os espectadores se sintam parte da narrativa.
Por �m, a plataforma SASF incorpora sistemas de recomendação baseados em aprendizado de
máquina, que, por meio de algoritmos avançados, analisam os padrões de comportamento e
preferênciasdos usuários para sugerir �lmes altamente relevantes (MCDONALD; SMITH-
ROWSEY, 2016).
Funk (2003) destaca que uma estratégia importante para lidar com as transmissões simultâneas
é a implementação de uma tecnologia de entrega de conteúdo e�ciente, como content delivery
networks (CDNs). Isso possibilita a distribuição do conteúdo para servidores localizados em
diferentes regiões geográ�cas, reduzindo a latência e garantindo uma melhor experiência de
streaming para os usuários (SMITH & TELANG, 2016).
O tamanho do inventário pode ser gerenciado de forma mais e�caz através da utilização de um
sistema de cache distribuído. Essa abordagem permite armazenar em memória os títulos mais
populares, tornando as consultas de disponibilidade mais rápidas e reduzindo o tempo de
resposta do sistema (BARBOSA, 2009).
Outra estratégia relevante é a adoção de técnicas de recomendação personalizada, com base no
histórico de preferências e comportamento dos usuários (BARBOSA, 2009; RICCI et al., 2011). Ao
oferecer sugestões de �lmes e séries mais relevantes para cada usuário, o sistema pode
aumentar o engajamento e o número de operações por dia, uma vez que os usuários são
direcionados para conteúdos de maior interesse (RICCI et al., 2011).
O SASF pode ainda se bene�ciar da utilização de tecnologias emergentes, como realidade virtual
(VR), para aprimorar a experiência de streaming de �lmes (TRICART, 2017). Ao oferecer
conteúdos em VR, o sistema pode se destacar no mercado, atrair mais usuários e,
consequentemente, aumentar o número de operações por dia.
Além dos desa�os mencionados anteriormente, o SASF também deve considerar as tendências
tecnológicas e mudanças no comportamento do consumidor para garantir sua relevância no
mercado em constante evolução (FUNK, 2003). Com o crescimento da indústria de
entretenimento digital, os consumidores estão cada vez mais exigentes em relação à qualidade
do serviço e à disponibilidade de conteúdos variados e exclusivos (MCDONALD; SMITH-ROWSEY,
2016).
Aplicação prática por estudo de caso de SASF
Disciplina
Arquitetura de Software
A empresa de entretenimento Cine�ix lançou recentemente o sistema de aluguel e streaming de
�lmes (SASF), que permite aos usuários alugar e assistir �lmes online. Com uma crescente base
de clientes, a plataforma oferece um vasto inventário de �lmes licenciados e originais, tornando-
se rapidamente popular entre os ciné�los. O SASF permite que vários usuários assistam ao
mesmo �lme simultaneamente, e a empresa tem investido em infraestrutura de servidores para
suportar a demanda crescente. No entanto, à medida que a base de clientes e o catálogo de
�lmes expandem, a empresa começa a enfrentar desa�os de desempenho, como tempos de
resposta lentos, problemas de transmissão simultânea e gargalos operacionais.
Trazendo à tona o problema, foi visto que, com o rápido crescimento do SASF, o aumento no
número de usuários simultâneos está afetando negativamente o desempenho da plataforma. Os
tempos de resposta estão mais lentos, resultando em uma experiência de usuário insatisfatória.
Além disso, a funcionalidade de transmissão simultânea de �lmes está enfrentando
instabilidades, com usuários relatando pausas inesperadas ou interrupções nas sessões de
streaming. O tamanho crescente do inventário de �lmes também está gerando gargalos nas
operações diárias, tornando a administração e a manutenção da plataforma mais complexas.
Nesse sentido, a equipe de engenharia e operações do Cine�ix conduziu uma análise detalhada
para identi�car as principais causas dos problemas enfrentados pela plataforma. Observou-se
que o aumento signi�cativo no número de usuários simultâneos está sobrecarregando os
servidores de streaming e os bancos de dados. Os tempos de resposta lentos e as interrupções
no streaming são resultado direto de a infraestrutura atual não conseguir lidar e�cientemente
com a carga crescente. Além disso, o tamanho massivo do inventário de �lmes está impactando
o gerenciamento de conteúdo e os processos de atualização. A equipe de operações está
Disciplina
Arquitetura de Software
enfrentando desa�os em relação à manutenção do catálogo e à disponibilidade de �lmes para os
usuários de forma ágil.
Como solução, a empresa Cine�ix resolveu implementar uma série de ações estratégicas.
Primeiramente, a empresa investirá em uma infraestrutura de servidores mais robusta e
escalável, capaz de lidar com a crescente demanda de usuários simultâneos. Será feita uma
parceria com provedores de serviços em nuvem para utilizar recursos elásticos, permitindo que a
capacidade de streaming seja ampliada ou reduzida dinamicamente, de acordo com a demanda.
Em relação à transmissão simultânea, a equipe de engenharia realizará uma otimização do
algoritmo de distribuição de conteúdo, garantindo uma melhor gestão dos dados enviados aos
usuários durante a reprodução dos �lmes. Isso reduzirá as pausas e interrupções nas sessões de
streaming, melhorando a experiência do usuário.
Quanto ao inventário de �lmes, a empresa adotará uma abordagem de gerenciamento de
conteúdo mais e�ciente, automatizando processos de atualização e manutenção do catálogo.
Com a implementação de ferramentas e �uxos de trabalho aprimorados, será possível adicionar
e remover �lmes do inventário de forma mais rápida e con�ável.
Por �m, para otimizar as operações diárias, o Cine�ix implementará tecnologias de
monitoramento e análise de desempenho em tempo real. Isso permitirá que a equipe identi�que
e resolva rapidamente quaisquer problemas operacionais, mantendo a plataforma funcionando
de forma suave e con�ável.
Em conclusão, com essas soluções implementadas, o sistema de aluguel e streaming de �lmes
(SASF) do Cine�ix estará preparado para lidar com o crescimento contínuo de sua base de
clientes, oferecendo uma experiência de usuário aprimorada, transmissões simultâneas mais
estáveis, tempos de resposta rápidos e uma gestão e�ciente do inventário de �lmes.
Videoaula: Estudo de caso – sistema de aluguel e streaming de �lmes (SASF)
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Agora que você conhece e entende os conceitos apresentados em nosso estudo de caso, é hora
de aprofundar seus conhecimentos assistindo à videoaula sobre esse conteúdo. Você aprenderá
as principais funcionalidades e capacidades do sistemas de aluguel e streaming de �lmes
(SASF), além de compreender o impacto causado pelas transmissões simultâneas, os tempos de
resposta, tamanho do inventário e número de operações por dia. A videoaula vai enriquecer seu
aprendizado e proporcionar uma visão ampla sobre arquitetura de software. Bons estudos!
Saiba mais
Disciplina
Arquitetura de Software
Sugerimos uma referência para que você possa aprofundar um pouco mais seu conhecimento
sobre serviços de streaming: Como funciona a Net�ix? (do DVD ao streaming).
Referências
https://tecnoblog.net/responde/como-funciona-a-netflix/
Disciplina
Arquitetura de Software
BARBOSA, Guilherme Mauro Germoglio. Um Livro-texto para o Ensino de Projeto de Arquitetura
de Software. Dissertação de mestrado para o Curso de Pós-Graduação em Ciência da
Computação da Universidade Federal de Campina Grande – Campus I, Campina Grande, 2009.
Disponível em:
http://docs.computacao.ufcg.edu.br/posgraduacao/dissertacoes/2009/Dissertacao_Guilherme
MauroGerrmoglioBarbosa.pdf. Acesso em: 15 jul. 2023.
FUNK, Jeffrey L. Mobile Disruptions: The Technologies and Applications Driving the Mobile
Internet. Hoboken: Wiley, 2003.
GOGONI, Ronaldo. Como funciona a Net�ix? (do DVD ao streaming). Technoblog, 2019.
Disponível em: https://tecnoblog.net/responde/como-funciona-a-net�ix/. Acesso em: 20 jul.
2023.
MCDONALD, Kevin; SMITH-ROWSEY, Daniel. The Net�ix Effect: Technology and Entertainment in
the 21st Century. Londres: Bloomsbury Publishing PLC, 2016.
RICCI, Francesco; ROKACH, Lior; SHAPIRA, Bracha; KANTOR, Paul B.Recommender Systems
Handbook. Nova York: Springer, 2010.
SMITH, Michael D.; TELANG, Rahul. Streaming, Sharing, Stealing: Big Data and the Future of
Entertainment. Cambridge: The MIT Press, 2016.
TRICART, Celine. Virtual Reality Filmmaking: Techniques & Best Practices for VR Filmmakers.
Abingdon: Routledge, 2017.
Aula 5
Resumo da unidade
Gestão da informação
http://docs.computacao.ufcg.edu.br/posgraduacao/dissertacoes/2009/Dissertacao_GuilhermeMauroGerrmoglioBarbosa.pdf
http://docs.computacao.ufcg.edu.br/posgraduacao/dissertacoes/2009/Dissertacao_GuilhermeMauroGerrmoglioBarbosa.pdf
https://tecnoblog.net/responde/como-funciona-a-netflix/
Disciplina
Arquitetura de Software
Olá, estudante! A arquitetura de software é fundamental para garantir a compreensão,
organização e evolução de sistemas complexos. Para desenvolver uma arquitetura sólida, é
necessário documentar as decisões e diretrizes tomadas ao longo do processo de design. Os
documentos da arquitetura atuam como registros essenciais, permitindo que a equipe de
desenvolvimento compreenda a estrutura do sistema e sua evolução ao longo do tempo. Essa
documentação é crucial para garantir a integridade conceitual do projeto.
Durante o processo de design arquitetônico, várias ferramentas podem ser utilizadas para
auxiliar na comunicação e visualização das decisões tomadas. A utilização de modelos para
análise e ferramentas de rastreabilidade facilita a identi�cação de dependências entre os
diferentes componentes do sistema. Essas ferramentas permitem uma melhor compreensão das
complexidades do projeto, possibilitando uma tomada de decisão mais informada.
As decisões arquitetônicas podem ser categorizadas em três tipos principais: existenciais,
descritivas e executivas. As decisões existenciais de�nem a estrutura fundamental do sistema,
como a escolha da plataforma, padrões arquitetônicos e tecnologias a serem utilizadas. Já as
decisões descritivas detalham a implementação de componentes especí�cos, como a escolha
de bibliotecas e frameworks. As decisões executivas estão relacionadas a questões de negócio,
como a priorização de requisitos e o planejamento de entregas.
O modelo 4+1 de Philippe Kruchten é uma abordagem de documentação arquitetônica que utiliza
cinco pontos de vista diferentes para descrever o sistema: lógico, de desenvolvimento, físico, de
processos e de cenários. Essa abordagem permite uma visão holística e abrangente do projeto,
garantindo que todos os aspectos importantes sejam considerados durante o processo de
design.
Os viewpoints são perspectivas especí�cas que destacam diferentes aspectos da arquitetura do
sistema. A abordagem de Rozanski e Woods propõe vários viewpoints, como o de contexto, de
composição, de informação e de estrutura, entre outros. Essa técnica ajuda a equipe a
Disciplina
Arquitetura de Software
compreender as necessidades e restrições de cada parte interessada, facilitando o processo de
design.
O Software Engineering Institute (SEI) de�ne viewtypes como representações particulares de
uma arquitetura que enfocam aspectos especí�cos, como o viewtype de design, de processos e
de casos de uso. Essas visualizações permitem uma análise mais detalhada dos diferentes
componentes e funcionalidades do sistema, facilitando a comunicação entre os membros da
equipe.
Para ilustrar a aplicação dos conceitos arquitetônicos mencionados acima, consideremos o
sistema de aluguel e streaming de �lmes (SASF). Esse sistema tem o objetivo de fornecer aos
usuários uma plataforma para alugar e transmitir �lmes online. Para projetar essa arquitetura, é
necessário tomar diversas decisões existenciais, como a escolha da infraestrutura de nuvem e
as tecnologias de streaming a serem utilizadas.
Além disso, decisões descritivas, como a de�nição das APIs para interação com o catálogo de
�lmes e as funcionalidades de pagamento, são fundamentais. As decisões executivas incluem a
priorização dos recursos a serem implementados e o planejamento das entregas, levando em
conta fatores como a quantidade de transmissões simultâneas suportadas, tempos de resposta
ideais, tamanho do inventário e quantidade de operações por dia.
Por �m, ao adotar o modelo 4+1 de Kruchten, os viewpoints de Rozanski e Woods e os viewtypes
do SEI, a equipe de desenvolvimento pode documentar a arquitetura do SASF de forma
abrangente, garantindo a integridade conceitual e permitindo uma análise detalhada de cada
aspecto do sistema.
Videoaula: Resumo da unidade
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Convidamos você a assistir a este vídeo que resume os conceitos fundamentais sobre
arquitetura de software, abordados durante as aulas da Unidade 3. Nele, você vai compreender
aspectos importantes, como design arquitetônico, tipos de decisões arquitetônicas, uso de
ferramentas de rastreabilidade e a relevância dos modelos de visão e viewpoints. Além disso,
vamos explorar os viewtypes do Software Engineering Institute (SEI), e as características e
funcionalidades do sistema de aluguel e streaming de �lmes (SASF). 
Estudo de caso
Disciplina
Arquitetura de Software
Para contextualizar sua aprendizagem, imagine que você trabalha para a empresa ABC, uma
plataforma de e-commerce estabelecida no mercado há vários anos. No entanto, nos últimos
tempos, a plataforma tem enfrentado diversos desa�os relacionados à sua arquitetura e à
capacidade de evolução do sistema.
A equipe de desenvolvimento percebeu que a falta de documentação arquitetônica adequada
tem causado di�culdades na compreensão global do sistema e na comunicação entre os
diferentes membros da equipe. Além disso, a arquitetura atual apresenta uma série de decisões
tomadas ao longo do tempo, sem uma visão clara de como elas se relacionam entre si. Essa
falta de uma visão abrangente tem prejudicado a capacidade de analisar o sistema para
identi�car pontos de melhoria e para entender o impacto de possíveis mudanças.
Para resolver esses desa�os, você será o protagonista na análise detalhada da arquitetura
existente e deverá identi�car as principais de�ciências. Algumas etapas-chave dessa análise
incluem:
1. Documentos da arquitetura:  revisar toda a documentação da arquitetura disponível para
identi�car lacunas e inconsistências. Será necessário veri�car se os principais
componentes, módulos e �uxos do sistema estão devidamente documentados. Além disso,
é importante avaliar a forma como a documentação está sendo compartilhada e atualizada
pela equipe.
2. Auxílio ao processo de design e ferramentas de comunicação: analisar as ferramentas e
práticas utilizadas pela equipe durante o processo de design da arquitetura. Veri�car se
existem padrões de comunicação bem de�nidos e se as ferramentas de documentação e
diagramação estão sendo empregadas de maneira adequada.
3. Integridade conceitual e modelo para análise: compreender a arquitetura como um todo e
identi�car os principais conceitos e decisões arquitetônicas. Estabelecer um modelo para
análise que permita relacionar as decisões e componentes arquitetônicos de forma coesa.
Disciplina
Arquitetura de Software
4. Ferramenta de rastreabilidade: avaliar a existência de uma ferramenta que permita rastrear
as decisões arquitetônicas ao longo do tempo, auxiliando a equipe a entender as
motivações por trás de cada escolha e facilitando a tomada de decisões futuras.
5. Decisões existenciais, descritivas e executivas: classi�car as decisões arquitetônicas
existentes em categorias, como decisões estratégicas (existenciais) que impactam a
direção geral do sistema, decisões descritivas que de�nem a estrutura e comportamento
dos componentes, e decisões executivas que envolvem aspectos tecnológicos e de
implementação.
�. Atributos das decisões arquitetônicas: analisar os atributos das decisões, como a
criticidade, estabilidade, �exibilidade e desempenho, para entender o impacto de cada uma
naarquitetura e na evolução do sistema.
7. Modelo 4+1 de Kruchten e viewpoints de Rozanski e Woods: utilizar os modelos
arquiteturais propostos para entender diferentes perspectivas do sistema e identi�car
possíveis problemas e melhorias em cada uma delas.
Após essa análise detalhada, a equipe estará mais bem preparada para criar uma solução efetiva
para os problemas enfrentados na arquitetura da plataforma de e-commerce. Poderão ser
propostas ações concretas para aprimorar a documentação, comunicação e tomada de
decisões, garantindo uma arquitetura mais sólida, coesa e adaptável.
_______
Re�ita
Para auxiliá-lo a entender melhor o estudo de caso apresentado, pense que uma empresa de
médio ou grande porte tenha muitos projetos envolvendo softwares. Em empresas com
múltiplos projetos de software, a arquitetura desempenha um papel crucial para o sucesso e a
e�ciência dos negócios.
Ao padronizar o desenvolvimento, ela cria uma base sólida e consistente para todos os projetos,
facilitando a colaboração entre as equipes e otimizando o processo de desenvolvimento (BASS;
CLEMENTS; KAZMAN, 2012; DOAR, 2011; ROZANSKI; WOODS, 2012).
Através da de�nição de padrões, estilos e tecnologias comuns, a arquitetura possibilita a
integração entre os sistemas e a reutilização de componentes, evitando a duplicação de esforços
e reduzindo custos de manutenção (SHAW; GARLAN, 1996). Além disso, a análise cuidadosa dos
requisitos funcionais e não funcionais garante que as decisões arquitetônicas sejam bem
fundamentadas, assegurando a escalabilidade, segurança e desempenho dos sistemas.
O uso de ferramentas de modelagem e documentação é essencial para visualizar a estrutura dos
sistemas e rastrear as decisões arquitetônicas ao longo do tempo, garantindo a integridade
conceitual do projeto (KRUCHTEN, 2004).
Investir na capacitação da equipe é uma prioridade, permitindo que os pro�ssionais estejam
atualizados com as melhores práticas de arquitetura de software e preparados para aplicar
soluções inovadoras e e�cazes.
Dessa forma, a arquitetura de software é o alicerce para o crescimento sustentável das
empresas, proporcionando e�ciência operacional, redução de custos, entrega de soluções
inovadoras e destaque em um mercado cada vez mais competitivo. 
Videoaula: Resolução do estudo de caso
Disciplina
Arquitetura de Software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Após realizar a análise detalhada da arquitetura da plataforma de e-commerce ABC e identi�car
os problemas, vejamos algumas ações para solucioná-los e melhorar a qualidade geral do
sistema.
Documentação arquitetônica centralizada: primeiramente, a medida é estabelecer uma
documentação arquitetônica centralizada e de fácil acesso para toda a equipe de
desenvolvimento. Isso inclui a criação de diagramas de alto nível, descrição de
componentes e interfaces, bem como documentação de decisões arquitetônicas
importantes. Uma plataforma online de compartilhamento de documentos será utilizada
para garantir a atualização constante da documentação, tornando-a uma referência
con�ável para a equipe.
De�nição de padrões de comunicação: serão estabelecidos padrões de comunicação para
garantir que todas as informações relevantes sobre a arquitetura sejam adequadamente
compartilhadas. Reuniões regulares de revisão arquitetônica possibilitarão que a equipe
discuta e esclareça dúvidas sobre o design da arquitetura e as decisões tomadas. Isso
promoverá uma comunicação mais e�ciente e evitará mal-entendidos.
Modelo para análise: um modelo arquitetônico claro será proposto. Ele ajudará a entender a
integridade conceitual da arquitetura e facilitará a análise de possíveis impactos
decorrentes de mudanças futuras.
Ferramenta de rastreabilidade: será adotada uma ferramenta de rastreabilidade para
registrar as decisões arquitetônicas e suas motivações ao longo do tempo. Isso permitirá
que a equipe compreenda o histórico das decisões e suas implicações na evolução da
plataforma, contribuindo para a transparência do processo decisório.
Classi�cação de decisões arquitetônicas: as decisões arquitetônicas serão classi�cadas
em existenciais, descritivas e executivas, considerando seus respectivos atributos de
criticidade, estabilidade, �exibilidade e desempenho. Essa classi�cação auxiliará a equipe a
priorizar ações de melhoria e a direcionar esforços para as áreas mais críticas.
Modelo 4+1 de Kruchten e viewpoints de Rozanski e Woods: ajudará a analisar o sistema
sob diferentes perspectivas e garantir uma visão abrangente da arquitetura. Isso permitirá
identi�car problemas em áreas especí�cas e propor soluções mais adequadas.
Treinamento e capacitação: a equipe receberá treinamentos e capacitação em relação à
utilização das ferramentas de comunicação, análise arquitetônica e tomada de decisões.
Isso garantirá que todos os membros tenham o conhecimento necessário para aplicar as
melhores práticas de arquitetura e alinhar-se aos modelos adotados.
Com a implementação dessas ações, a arquitetura da plataforma do e-commerce será
aprimorada, tornando-se mais clara, consistente e bem documentada. A equipe de
Disciplina
Arquitetura de Software
desenvolvimento poderá tomar decisões mais informadas, identi�car pontos de melhoria com
maior precisão e garantir uma evolução sustentável do sistema ao longo do tempo. Além disso, a
comunicação entre os membros da equipe será aprimorada, evitando mal-entendidos e
garantindo uma colaboração mais efetiva e e�ciente em todo o processo de desenvolvimento.
Lembre-se de re�etir sobre como essas melhorias e soluções podem se adequar à realidade
pro�ssional, considerando a diversidade de cenários e possibilidades. A busca contínua por
aprimoramento e a aplicação dos conceitos aprendidos serão essenciais para o sucesso na área
de arquitetura de software.
Resumo visual
Disciplina
Arquitetura de Software
Fonte: elaborada pelo autor.
Referências
Disciplina
Arquitetura de Software
BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. Software Architecture in Practice. 3a ed. Boston:
Addison-Wesley, 2012.
DOAR, Matthew. Practical JIRA Administration: Using JIRA Effectively: Beyond the
Documentation. Sebastopol: O’Reilly Media Inc., 2011.
KRUCHTEN, Philippe. The Rational Uni�ed Process: An Introduction. 3a ed. Boston: Addison-
Wesley, 2004.
ROZANSKI, Nick; WOODS, Eoin. Software systems architecture: working with stakeholders using
viewpoints and perspectives. Boston: Addison-Wesley, 2012.
SHAW, Mary; GARLAN, David. Software Architecture: Perspectives on an Emerging Discipline.
Upper Saddle River: Prentice Hall, 1996.
,
Unidade 4
Arquitetura e design de software
Aula 1
Design de software: uma introdução
Introdução
Disciplina
Arquitetura de Software
Olá, estudante!
Nesta aula, você aprenderá sobre o conceito principal do design de software e suas
características essenciais. Exploraremos como o design de software contribui para a criação de
soluções tecnológicas e�cientes e de qualidade.
Ao longo da aula, analisaremos os elementos do processo de design de software, incluindo a
identi�cação de requisitos, a modelagem de sistemas e a escolha de padrões de projeto
apropriados. Compreenderemos como o design de software busca características como
modularidade, reusabilidade e facilidade de manutenção.
Essa aula contribuirá para o seu aprendizado, fornecendo uma base sólida em design de
software e capacitando você a criar soluções robustas e e�cazes. Ao aplicar os princípios
aprendidos, você poderá desenvolver sistemas escaláveis e intuitivos.
Lembre-se de que o aprendizado contínuo é essencial para o crescimento pro�ssional. Aproveite
ao máximo esta aula, mantenha-se motivado e curioso para explorar as aplicações práticas do
design de software em sua carreira.
Bom aprendizado! 
Princípios de design de software
De acordo com Martin (2019), o design de software é um conceito crucial na áreada tecnologia,
abrangendo a criação e o planejamento de programas e sistemas. O objetivo é organizar e
Disciplina
Arquitetura de Software
estruturar esses sistemas de forma aprimorada, garantindo um funcionamento e�ciente e
facilitando sua manutenção ao longo do ciclo de vida do software.
No contexto do design de software, os elementos referem-se aos componentes essenciais e
princípios fundamentais que compõem um sistema bem projetado. Esses elementos
desempenham um papel crucial na criação de software de qualidade, sustentável e adaptável.
Um dos principais elementos do design de software é a modularidade. A modularidade envolve
dividir o código em componentes coesos e independentes, conhecidos como módulos. Cada
módulo possui uma responsabilidade única e bem de�nida, facilitando alterações isoladas e
reduz o impacto em outras partes do sistema. A modularidade promove a reutilização de
módulos em diferentes contextos, tornando o sistema mais �exível e escalável.
Outro elemento fundamental é a reusabilidade. Ela incentiva a criação de componentes
genéricos e bem projetados, que podem ser aproveitados em diferentes projetos. Isso evita a
duplicação de esforços e promove a e�ciência no desenvolvimento de software. A reusabilidade
também contribui para a consistência e para a padronização, facilitando a compreensão e a
manutenção do sistema.
A �exibilidade é um elemento essencial no Design de Software. Um software �exível é capaz de
se adaptar a mudanças nos requisitos e no ambiente em que está inserido. Isso é alcançado por
meio da criação de arquiteturas que permitam a incorporação de novos recursos e acomodam
evoluções futuras. A �exibilidade garante que o software permaneça relevante e e�caz ao longo
do tempo.
Outro elemento importante é a facilidade de manutenção. Sistemas bem projetados são fáceis
de entender, depurar e modi�car. Adotar boas práticas de organização do código (como nomes
claros e signi�cativos para variáveis, funções e classes) contribui para a manutenibilidade do
software. A facilidade de manutenção é essencial para a correção de bugs, implementação de
melhorias e atualizações, reduzindo os riscos de introduzir novos problemas durante o processo.
Compreender os requisitos do sistema é um elemento-chave para o sucesso do projeto. Isso
envolve a análise das necessidades do usuário, dos objetivos de negócio e das restrições
técnicas. A modelagem do sistema, por meio de diagramas (como de classes, de sequência e de
componentes), auxilia a visualização da estrutura e das interações entre os componentes.
A de�nição de uma arquitetura adequada também é um elemento essencial do design de
software. A arquitetura de�ne a estrutura global do sistema, incluindo os principais
componentes, suas interações e as diretrizes para a implementação. Uma arquitetura bem
projetada permite a evolução do sistema de forma controlada, facilitando a adição de novas
funcionalidades e acomodando mudanças nos requisitos.
Por �m, os padrões de projeto são elementos valiosos no design de software. Eles fornecem
soluções para problemas recorrentes de design, baseadas em experiências anteriores. Os
padrões de projeto fornecem diretrizes e melhores práticas que podem ser aplicadas em
diferentes contextos, economizando tempo e esforço no processo de desenvolvimento.
O design de software envolve a consideração cuidadosa e a aplicação desses elementos para
criar sistemas e�cientes, �exíveis, fáceis de manter e robustos. Ao adotar esses elementos como
princípios norteadores, os pro�ssionais de software podem projetar soluções de qualidade que
atendam às necessidades dos usuários e superem os desa�os do desenvolvimento de software.
Aprofundando no mundo do design de software
Disciplina
Arquitetura de Software
Vamos nos aprofundar um pouco mais no design de software? Além das características
mencionadas anteriormente, existem etapas, ferramentas, princípios, classi�cações e
formulações que são fundamentais para o processo de design, de acordo com Fowler (1997),
Gamma et al. (1995), Evans (2004) e Martin (2019). Vamos explorá-las para que você possa
entender e aplicar esses conceitos de forma mais abrangente.
Etapas do design de software:
Análise de requisitos: compreender as necessidades do usuário, os objetivos de
negócio e as restrições técnicas do sistema a ser desenvolvido.
Modelagem: criar representações visuais do software, como diagramas de classes,
diagramas de sequência e diagramas de componentes, para visualizar sua estrutura e
interações.
Arquitetura: de�nir a estrutura global do sistema, incluindo os componentes
principais, suas interações e as diretrizes para a implementação.
Implementação: codi�car o software com base na arquitetura e nas especi�cações
de�nidas.
Testes: realizar testes para veri�car se o software atende aos requisitos e funciona
corretamente.
Manutenção: realizar atividades de correção de bugs, implementação de melhorias e
atualizações ao longo do ciclo de vida do software.
Ferramentas de design de software:
Disciplina
Arquitetura de Software
Editores de código: softwares que permitem escrever e editar o código fonte do
software.
Ambientes de desenvolvimento integrado (IDEs): ferramentas que oferecem recursos
avançados para desenvolvimento, como depuração, sugestões de código e
gerenciamento de projetos.
Modelagem UML: ferramentas que auxiliam a criação de diagramas UML para
representar a estrutura e o comportamento do software.
Princípios de design de software:
Princípio da responsabilidade única (SRP): cada módulo ou classe deve ter uma única
responsabilidade.
Princípio da abstração: esconder detalhes de implementação complexos e fornecer
interfaces simpli�cadas.
Princípio do aberto/fechado (OCP): o software deve ser aberto para extensão, mas fechado
para modi�cação.
Princípio da substituição de Liskov (LSP): as classes derivadas devem poder ser
substituídas pelas classes base sem alterar o comportamento esperado.
Princípio da inversão de dependência (DIP): depender de abstrações em vez de
implementações concretas.
Classi�cações de design de software:
Design estrutural: concentra-se na organização e estrutura do software, como a
de�nição de classes, interfaces e relacionamentos entre os componentes.
Design comportamental: concentra-se no comportamento do software, como a
de�nição de algoritmos, �uxos de controle e interações entre os componentes.
Design arquitetural: concentra-se na de�nição da estrutura global do software,
incluindo a divisão em camadas, componentes e suas interações.
Formulações de design de software:
Padrões de projeto: soluções para problemas recorrentes de design, baseadas em
experiências anteriores, que fornecem diretrizes e melhores práticas.
Princípios SOLID: conjunto de princípios que visam a promover a manutenibilidade,
�exibilidade e extensibilidade do software.
Após estudar esses elementos do design de software, você será capaz de resolver problemas,
classi�car conceitos, interpretar modelos e situar os conhecimentos adquiridos. Essa
compreensão profunda do design de software permitirá que você crie soluções robustas e
e�cientes, atendendo às necessidades do usuário e do mercado.
Continue se dedicando aos estudos e explore a aplicação desses conceitos no seu cotidiano
pro�ssional. O design de software é uma habilidade valiosa e cada vez mais requisitada no
mercado de tecnologia. Esteja preparado para se destacar e alcançar o sucesso na área. 
Vejamos um exemplo prático?
Disciplina
Arquitetura de Software
Vamos agora explorar a aplicação do conteúdo sobre: design de software, características de
design de software, elementos de design de software e soluções robustas por meio de exemplos
práticos. Vejamos como esses conceitos podem ser aplicados no contexto pro�ssional.
Imagine que você está trabalhando em um projeto de desenvolvimento de um sistema de
gerenciamento de vendas para uma empresa de comércio eletrônico. Nesse caso, você precisará
aplicar os princípios do design de software para criar uma solução e�ciente e robusta.Para começar, é fundamental realizar uma análise de requisitos detalhada. Você precisa
compreender as necessidades dos usuários, os objetivos do negócio e as restrições técnicas do
sistema. A partir dessa análise, você pode de�nir as funcionalidades principais do software e
planejar a arquitetura do sistema.
No processo de modelagem, você pode criar diagramas de classes para representar as entidades
do sistema, como clientes, produtos e pedidos. Além disso, diagramas de sequência podem ser
utilizados para visualizar o �uxo de interações entre os diferentes componentes do sistema.
Essas representações visuais facilitam o entendimento da estrutura e das interações do
software.
Ao implementar o sistema, é importante utilizar boas práticas de codi�cação, como a
modularização do código. Dividir o software em módulos coesos e independentes permite uma
melhor organização e facilita a manutenção futura. Por exemplo, você pode criar um módulo
responsável pelo cálculo de descontos e outro módulo para o processamento de pagamentos.
Disciplina
Arquitetura de Software
Dessa forma, é possível realizar alterações isoladas em cada módulo, sem afetar o
funcionamento do sistema como um todo.
Durante o processo de testes, é essencial veri�car se o software atende aos requisitos
estabelecidos e funciona corretamente. É possível criar casos de teste para cada funcionalidade
do sistema, veri�cando se os resultados estão de acordo com o esperado. Além disso, a
aplicação de técnicas de testes automatizados pode agilizar esse processo, garantindo a
qualidade do software.
Após o lançamento do sistema, a manutenção se torna uma etapa crucial. É importante realizar
correções de bugs, implementar melhorias e atualizar o software de acordo com as
necessidades do negócio e feedbacks dos usuários. Nesse sentido, a facilidade de manutenção
do software, alcançada por meio de um design bem estruturado, é essencial para agilizar e
facilitar essas atividades.
Por �m, para garantir soluções robustas, é importante considerar a escalabilidade do sistema.
Caso a empresa de comércio eletrônico experimente um aumento signi�cativo de vendas, o
software precisa ser capaz de lidar com o aumento da carga de trabalho. Portanto, a escolha de
uma arquitetura escalável e o uso de tecnologias adequadas são fundamentais para garantir um
desempenho consistente e uma experiência satisfatória para os usuários.
Esses exemplos práticos ilustram como os conceitos de design de software podem ser
aplicados em situações reais. Ao compreender e aplicar esses princípios, você estará apto a criar
soluções e�cientes, �exíveis e fáceis de manter, atendendo às necessidades dos usuários e do
mercado.
Continue explorando casos práticos, trabalhando em projetos reais e ampliando seus
conhecimentos. O design de software é um tópico em constante evolução, e estar atualizado e
preparado para os desa�os do mercado é fundamental para o sucesso na área de
desenvolvimento de software. 
Videoaula: Design de software - uma introdução
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Boas-vindas à videoaula que vai transformar sua visão sobre design de software. Vamos
mergulhar no fascinante mundo do design, explorando seus conceitos, características e
elementos essenciais. Prepare-se para compreender o que é design de software, suas aplicações
e como ele in�uencia a criação de soluções robustas. Acompanhe atentamente este vídeo, pois
você verá exemplos práticos e receberá um roteiro completo do processo de design de software.
Prepare-se para ampliar seus conhecimentos e dominar essa importante habilidade. Vamos
começar essa jornada de aprendizado juntos!
Disciplina
Arquitetura de Software
Saiba mais
1. Arquitetura de Software: a diferença entre arquitetura e design: este artigo mostra que a
diferença entre arquitetura de software e design de software é frequentemente confusa
para muitas pessoas, incluindo desenvolvedores. A arquitetura de software envolve a
criação de uma solução estruturada que atenda a requisitos técnicos e de negócios,
transformando características como �exibilidade, escalabilidade e segurança em uma
solução viável.
Por outro lado, o design de software se concentra no nível de código, de�nindo o escopo
das classes, as responsabilidades dos módulos e os objetivos das funções. É importante
que os desenvolvedores tenham conhecimentos sólidos em design de software e
compreendam princípios como SOLID e padrões de design, enquanto os arquitetos de
software têm a responsabilidade de planejar a estrutura de alto nível do software,
selecionando padrões de arquitetura adequados, como microservices, arquitetura orientada
a eventos e arquitetura serverless, para atender aos requisitos comerciais e operacionais.
2. Design de software: programação tática ou estratégica? Este artigo destaca que “o design
de software busca isolar complexidades e simpli�car o código, tornando-o adequado para
correções, manutenções e reaproveitamentos futuros” (SOTO, [s. d., s. p.]).
Referências
https://oieduardorabelo.medium.com/arquitetura-de-software-a-diferen%C3%A7a-entre-arquitetura-e-design-964ab38ea61a
https://ilegra.com/blog/design-de-software-programacao-tatica-ou-estrategica/
Disciplina
Arquitetura de Software
EVANS, Eric. Domain-driven design: tackling complexity in the heart of software. Londres:
Addison-Wesley Professional, 2004.
FOWLER, Martin. Refactoring: Improving the design of existing code. In: 11th European
Conference. Jyväskylä, Finlândia, 1997.
GAMMA, Erich; et al. Design patterns: elements of reusable object-oriented software. Frankfurt:
Pearson Deutschland GmbH, 1995.
MARTIN, Robert C. Arquitetura limpa: o guia do artesão para estrutura e design de software. Rio
de Janeiro: Alta Books Editora, 2019.
SOTO, M. Design de software: programação tática ou estratégica? Ilegra, [s. d.]. Disponível em:
https://ilegra.com/blog/design-de-software-programacao-tatica-ou-estrategica/. Acesso em: 14
ago. 2023.
Aula 2
Design de software: visão geral
Introdução
Disciplina
Arquitetura de Software
Olá, estudante!
Nesta aula, exploraremos os fundamentos essenciais do design de software e sua importância
na criação de sistemas e�cientes. Abordaremos objetivos, restrições, alternativas,
representações e soluções. Veremos como o design de software divide os sistemas em
componentes coesos, promovendo modularidade e reusabilidade por meio do encapsulamento e
soluções de conquista.
Esses elementos são fundamentais para criar sistemas de qualidade, que atendam às
necessidades dos usuários e sejam fáceis de manter. Prepare-se para mergulhar no mundo
fascinante do design de software e explorar conceitos e práticas que impulsionam o
desenvolvimento de software de excelência.
Bons estudos! 
Visão geral e elementos essenciais
Disciplina
Arquitetura de Software
A compreensão da visão geral do design de software é essencial para entender os elementos
fundamentais desse processo. De acordo com Martin (2019), o design de software tem como
objetivo principal criar soluções e�cientes e funcionais que atendam às necessidades dos
usuários e do negócio. Por meio de um planejamento cuidadoso, é possível de�nir a estrutura e o
comportamento do software, garantindo um sistema de alta qualidade e desempenho.
Durante o processo de design, é importante considerar as restrições impostas, como prazos,
recursos disponíveis e requisitos técnicos. Essas restrições ajudam a de�nir o escopo do projeto
e a estabelecer limites realistas para o design, permitindo que os engenheiros de software
tomem decisões informadas e otimizem o processo.
O design de software envolve a exploração de uma variedade de alternativas, como tecnologias,
arquiteturas e abordagens de desenvolvimento. A escolha adequada depende dos requisitos e
das metas do software, podendo incluir arquiteturas em camadas, cliente-servidor ou orientada a
serviços.A representação visual de ideias e conceitos é uma parte crucial do design de software,
utilizando diagramas, esquemas e documentação clara e concisa. Essas representações visuais
facilitam a comunicação e a compreensão do design, tanto entre os membros da equipe quanto
entre a equipe e os stakeholders, além de auxiliar na manutenção do software no futuro.
Segundo Martin (2019), a divisão adequada do software em componentes coesos é uma prática
importante. Ela permite o desenvolvimento e manutenção independentes de diferentes partes do
software, facilitando a escalabilidade e a evolução do sistema como um todo. A modularidade
promove a reutilização de código, economizando tempo e esforço durante o processo de
desenvolvimento.
Disciplina
Arquitetura de Software
A conquista de um bom design de software envolve a combinação de diversos princípios e
técnicas. Um princípio fundamental é a modularidade, que busca dividir o código em
componentes coesos e independentes, conhecidos como módulos. Cada módulo deve ter uma
responsabilidade única e bem de�nida, facilitando alterações isoladas e reduzindo o impacto em
outras partes do sistema. A modularidade permite a reutilização de módulos em diferentes
contextos e promove uma arquitetura mais �exível e escalável.
Outro aspecto relevante é o encapsulamento, que visa a ocultar os detalhes internos do software
e fornece interfaces bem de�nidas para interagir com o sistema. Isso facilita a manutenção e a
evolução do software, pois as mudanças podem ser feitas dentro do módulo encapsulado sem
afetar outras partes do sistema. Além disso, o encapsulamento promove a segurança, uma vez
que impede o acesso não autorizado a partes sensíveis do software.
Em resumo, a visão geral do design de software abrange uma série de elementos interligados
que contribuem para a criação de soluções e�cientes e funcionais. Ao compreender os objetivos,
restrições, alternativas, representações e soluções, além de aplicar a divisão adequada,
conquistar e encapsular o software, os engenheiros de software podem desenvolver sistemas
robustos, �exíveis e de alta qualidade.
Princípios e elementos essenciais
Segundo Martin (2019), no design de software, é crucial considerar as restrições impostas ao
projeto, como prazos, recursos disponíveis e requisitos técnicos. Por exemplo, ao desenvolver
Disciplina
Arquitetura de Software
um aplicativo móvel para lançá-lo antes de um evento importante, é necessário adaptar o design
do software para cumprir o prazo, exigindo uma abordagem ágil e e�ciente.
Durante o processo de design de software, várias alternativas são exploradas para atender aos
requisitos do projeto, incluindo a seleção cuidadosa de tecnologias, arquiteturas e abordagens de
desenvolvimento. Por exemplo, ao projetar um sistema de comércio eletrônico, a equipe de
desenvolvimento pode considerar diferentes alternativas de arquitetura, como uma abordagem
monolítica tradicional ou uma arquitetura de microsserviços mais escalável e �exível. Cada
alternativa tem suas vantagens e desvantagens, e a escolha depende dos requisitos especí�cos
do projeto, como escalabilidade, desempenho e custo.
Uma parte crucial do design de software é a representação das ideias e conceitos, que pode ser
realizada por meio de diagramas, esquemas e documentação clara e concisa. As representações
visuais, como diagramas de classe e diagramas de sequência, desempenham um papel crucial
na comunicação e compreensão do design do software, tanto entre os membros da equipe
quanto para os stakeholders envolvidos. Além disso, uma documentação adequada permite que
os desenvolvedores entendam o raciocínio por trás das decisões de design e auxilia a
manutenção futura do software.
De acordo com Martin (2019), a divisão adequada do software em componentes coesos é uma
prática importante no design de software. Ao dividir o software em módulos ou componentes
separados, cada parte pode ter uma responsabilidade única e bem de�nida. Isso facilita
alterações isoladas e reduz o impacto em outras partes do sistema. Por exemplo, em um
sistema de gerenciamento de biblioteca, é possível dividir o software em módulos para o
cadastro de livros, gerenciamento de empréstimos e geração de relatórios. Essa divisão permite
que cada parte seja desenvolvida e mantida de forma independente, o que facilita a
escalabilidade e a evolução do sistema como um todo.
A conquista de um bom design de software envolve a combinação de diversos princípios e
técnicas. Um princípio fundamental é o encapsulamento, que busca ocultar os detalhes internos
do software e fornecer interfaces bem de�nidas para interagir com o sistema. Isso facilita a
manutenção e a evolução do software, uma vez que as mudanças podem ser feitas dentro do
módulo encapsulado sem afetar outras partes do sistema.
Em resumo, o design de software é um processo complexo e crucial para o desenvolvimento de
sistemas de software e�cientes e funcionais. Envolve a consideração de objetivos, restrições,
alternativas, representações e soluções. A divisão adequada do software em componentes
coesos, a seleção cuidadosa de alternativas e a aplicação de técnicas como o encapsulamento
são aspectos fundamentais para o sucesso do design de software. 
Exemplo prático de design de software
Disciplina
Arquitetura de Software
Uma empresa de comércio eletrônico decidiu desenvolver um novo sistema de gerenciamento de
pedidos online com o objetivo de melhorar a e�ciência do processamento de pedidos, reduzir
erros e agilizar o tempo de entrega. Esse projeto envolve várias etapas de design de software
para alcançar esses objetivos.
Ao iniciar o projeto, a equipe de desenvolvimento precisa levar em consideração diversas
restrições impostas ao projeto. Por exemplo, eles têm um prazo apertado para lançar o sistema
antes da temporada de compras de �m de ano, para aproveitar ao máximo o período de alta
demanda. Além disso, eles possuem um orçamento limitado para o desenvolvimento do sistema.
Essas restrições de�nem os limites do projeto e orientam as decisões de design a serem
tomadas.
Durante o processo de design, a equipe explora diferentes alternativas para atender aos
requisitos do projeto. Eles consideram várias arquiteturas e tecnologias disponíveis no mercado.
     Após analisar cuidadosamente as alternativas, a equipe decide adotar uma arquitetura de
microsserviços para o sistema de gerenciamento de pedidos. Essa escolha é feita com base na
necessidade de escalabilidade e �exibilidade para lidar com o aumento do volume de pedidos
durante os períodos de pico. A arquitetura de microsserviços permite que cada componente seja
desenvolvido e mantido de forma independente, facilitando a escalabilidade horizontal e a
atualização de partes especí�cas do sistema sem afetar as demais.
Uma vez de�nida a arquitetura, a equipe precisa representar o design do sistema de forma clara
e compreensível. Para isso, eles utilizam diferentes técnicas de representação, como diagramas
de componentes e diagramas de sequência. Os diagramas de componentes mostram a divisão
do software em diferentes módulos e componentes, como gerenciamento de pedidos,
processamento de pagamentos e logística de entrega. Essa representação visual ajuda a
comunicar a estrutura do sistema e as interações entre os componentes.
Além das representações visuais, a equipe também documenta o design do sistema de forma
detalhada. Eles elaboram uma documentação clara e concisa que descreve os componentes,
Disciplina
Arquitetura de Software
suas responsabilidades e as interfaces disponíveis para interagir com o sistema. Essa
documentação auxilia a compreensão do design e a manutenção do sistema no futuro.
Uma parte importante do design de software é a divisão adequada do software em componentes
coesos. Essa divisão é feita de acordo com a responsabilidade e a funcionalidade de cada
componente. No caso do sistema de gerenciamento de pedidos, a equipe divide o software em
módulos separados, como cadastro de pedidos, processamento de pagamentos, logísticade
entrega e geração de relatórios. Essa divisão permite que cada parte seja desenvolvida e
mantida de forma independente, facilitando a escalabilidade e a evolução do sistema como um
todo.
Ao longo do processo de design, a equipe também se concentra em alcançar a conquista de um
bom design de software. Isso envolve a aplicação de princípios e técnicas, como o
encapsulamento. O encapsulamento busca ocultar os detalhes internos do software e fornece
interfaces bem de�nidas para interagir com o sistema. Essa prática facilita a manutenção e a
evolução do software, uma vez que as mudanças podem ser feitas dentro do módulo
encapsulado sem afetar outras partes do sistema.
Em resumo, o exemplo prático sobre design de software ilustra a importância dos objetivos,
restrições, alternativas, representações e soluções no processo de design. 
Videoaula: Design de software - visão geral
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Neste vídeo, abordaremos os principais tópicos discutidos em sala de aula, como objetivos,
restrições, alternativas, representações e soluções. Além disso, vamos falar sobre a importância
de dividir o software adequadamente e alcançar o encapsulamento. Não perca a oportunidade de
aprofundar seus conhecimentos nesse assunto fundamental para o desenvolvimento de
sistemas e�cientes. O vídeo proporcionará uma visão clara e concisa dos conceitos abordados,
ajudando você a consolidar o seu aprendizado.
Saiba mais
Disciplina
Arquitetura de Software
1. Princípios da engenharia de software: este artigo é uma referência no campo da engenharia
de software. Ele aborda diversos aspectos do design de software.
2. UML: este tutorial explora conceitos básicos da linguagem UML, que é amplamente
utilizada para representar o design de software por meio de diagramas.
 
 
Referências
https://www.devmedia.com.br/principios-da-engenharia-de-software/29630
https://www.devmedia.com.br/uml/8579
https://www.devmedia.com.br/uml/8579
Disciplina
Arquitetura de Software
MARTIN, Robert C. Arquitetura limpa: o guia do artesão para estrutura e design de software. Rio
de Janeiro: Alta Books Editora, 2019.
Aula 3
Design de software
Introdução
Disciplina
Arquitetura de Software
Olá, estudante!
Boas-vindas à nossa aula sobre conceitos fundamentais em design de software. Vamos explorar
os temas de modularização, separação de preocupações, acoplamento e coesão. Esses
conceitos são essenciais para o desenvolvimento de sistemas de software e�cientes e
escaláveis. Vamos compreender como a modularização nos permite dividir o código em
componentes independentes, facilitando sua manutenção e reutilização.
A separação de preocupações nos ajuda a organizar o código de forma lógica e coesa,
garantindo a compreensão e a manutenção do sistema. Além disso, vamos explorar o
acoplamento e a coesão como métricas para avaliar a qualidade do design do software. Reduzir
o acoplamento minimiza dependências e facilita alterações isoladas. Alta coesão cria
componentes independentes e bem de�nidos. Prepare-se para uma aula repleta de
conhecimento prático e exemplos relevantes.
Bons estudos!
Conceitos iniciais
Disciplina
Arquitetura de Software
Modularização
De acordo com Martin (2019), a modularização é um princípio-chave do design de software que
consiste em dividir um sistema em módulos independentes e coesos. A ideia é organizar o
código em partes menores e mais gerenciáveis, de forma que cada módulo desempenhe uma
função especí�ca e bem de�nida. Isso facilita a compreensão, manutenção e reutilização do
código, uma vez que os módulos podem ser trabalhados separadamente e combinados para
formar o sistema completo.
Separação de preocupações
A separação de preocupações é um princípio que visa a isolar diferentes aspectos funcionais de
um sistema em módulos distintos (MARTIN, 2019). Em outras palavras, cada módulo deve lidar
apenas com uma preocupação especí�ca, como autenticação de usuários, gerenciamento de
dados ou interface do usuário. Essa abordagem permite que os desenvolvedores se concentrem
em uma área de cada vez, tornando o código mais organizado e facilitando as mudanças e
atualizações futuras.
Acoplamento
O acoplamento refere-se ao grau de dependência entre os módulos de um sistema. Um
acoplamento baixo indica que os módulos estão pouco interligados e as alterações em um
módulo têm um impacto mínimo nos outros (MARTIN, 2019). Por outro lado, um acoplamento
alto indica uma forte interdependência, de forma que as mudanças em um módulo podem
causar efeitos colaterais em vários outros. É desejável reduzir o acoplamento, pois isso aumenta
a �exibilidade e a capacidade de evolução do sistema.
Coesão
Disciplina
Arquitetura de Software
A coesão mede a relação entre as funcionalidades dentro de um módulo. Um módulo com alta
coesão realiza uma única tarefa bem de�nida, enquanto um módulo com baixa coesão executa
várias tarefas diferentes (MARTIN, 2019). É importante buscar uma coesão alta, pois isso facilita
a compreensão do módulo, torna o código mais legível e mantém a responsabilidade clara e
direta. Módulos coesos também são mais fáceis de reutilizar em outros projetos, uma vez que
sua funcionalidade é bem de�nida e isolada.
Neste bloco, exploramos os conceitos de modularização, separação de preocupações,
acoplamento e coesão no design de software. Compreender e aplicar esses princípios é
fundamental para criar sistemas de software robustos e escaláveis. Ao modularizar um sistema,
separar preocupações, reduzir o acoplamento e aumentar a coesão, você estará no caminho
certo para desenvolver soluções de software mais e�cientes e de alta qualidade.
Lembre-se de praticar esses conceitos em seus projetos, buscando dividir o código em módulos
coesos e independentes, focados em preocupações especí�cas. Explore exemplos do mundo
real e estude as melhores práticas para consolidar seu conhecimento. Agora é hora de aplicar o
que aprendemos e criar sistemas de software melhores e mais �exíveis.
Características e prática
Neste bloco, vamos aprofundar nossa compreensão dos conceitos fundamentais de
modularização, separação de preocupações, acoplamento e coesão no desenvolvimento de
software. Esses princípios são essenciais para construir sistemas robustos, �exíveis e de fácil
manutenção. Vamos explorar as características e aplicação prática desses conceitos para
aprimorar nossos conhecimentos e habilidades em design de software.
Aprofundando o conhecimento
Disciplina
Arquitetura de Software
De acordo com Martin (2019), a modularização consiste em dividir um sistema em módulos
independentes e coesos, cada um com uma função especí�ca. Isso facilita a compreensão do
sistema, melhora a organização do código e torna a manutenção mais e�ciente. Por exemplo, em
um sistema de gerenciamento de loja online, podemos ter módulos separados para o carrinho de
compras, o cadastro de clientes, o controle de estoque e o processamento de pagamentos.
A separação de preocupações está relacionada à identi�cação e ao isolamento de aspectos
distintos do sistema (MARTIN, 2019). Por exemplo, em um sistema de e-commerce, podemos
separar as preocupações da interface do usuário, da lógica de negócios e do acesso a banco de
dados em camadas diferentes. Isso permite que cada módulo se concentre em uma
preocupação especí�ca, facilitando a compreensão do código e tornando o desenvolvimento
mais modular e escalável.
O acoplamento refere-se à dependência entre os módulos de um sistema (MARTIN, 2019). Um
baixo acoplamento signi�ca que os módulos possuem poucas dependências entre si, o que
resulta em um código mais �exível e fácil de modi�car. Por exemplo, se um módulo precisa ser
atualizado, um baixo acoplamento garante que as alterações sejam restritas apenas ao módulo
em questão, sem afetar os demais. Já um alto acoplamento torna o sistema mais frágil, pois
uma mudança em ummódulo pode ter impacto em vários outros. Portanto, é importante buscar
um baixo acoplamento através do uso de interfaces bem de�nidas e da adoção de padrões de
design.
Segundo Martin (2019), a coesão diz respeito à relação entre as responsabilidades dentro de um
módulo. Um alto nível de coesão indica que as responsabilidades estão bem alinhadas e se
complementam dentro do módulo, resultando em um código mais coeso e de fácil manutenção.
Por exemplo, em um módulo de processamento de pagamentos, todas as funcionalidades
relacionadas a essa tarefa devem estar contidas no mesmo módulo. Isso evita dispersão de
código e facilita a compreensão das funcionalidades especí�cas do módulo.
Benefícios
O design de software baseado em modularização, separação de preocupações, acoplamento
baixo e coesão alta traz uma série de benefícios. A modularização permite a divisão do sistema
em partes independentes e coesas, facilitando sua compreensão e manutenção. A separação de
preocupações permite a identi�cação e isolamento de aspectos distintos do sistema,
simpli�cando o desenvolvimento e tornando-o mais escalável. O baixo acoplamento reduz as
dependências entre os módulos, tornando o código mais �exível. Por �m, a coesão alta garante
que as responsabilidades dentro de um módulo estejam bem de�nidas, resultando em um
código coeso e de fácil manutenção.
Ao aplicar esses conceitos no design de software, podemos criar sistemas mais robustos,
�exíveis e de alta qualidade. Portanto, é fundamental entender e utilizar esses princípios em
nossos projetos, buscando sempre aprimorar nossas habilidades de engenharia de software. 
Design de software e�ciente
Disciplina
Arquitetura de Software
Neste momento, exploraremos a importância do design de software na resolução de problemas
em situações do cotidiano pro�ssional. Vamos abordar como a modularização, separação de
preocupações e acoplamento podem ser aplicados para criar soluções e�cientes.
Imagine trabalhar em uma empresa de logística que precisa gerenciar um sistema de entrega de
encomendas. Esse sistema abrange o registro das encomendas, a roteirização das entregas até
o acompanhamento em tempo real. Para lidar com essa complexidade, é essencial utilizar os
princípios de modularização, separação de preocupações e acoplamento.
A modularização permite dividir o sistema em módulos independentes, cada um com uma
função especí�ca. Por exemplo, desenvolver um módulo para o cadastro das encomendas, outro
para a roteirização das entregas e um terceiro para o acompanhamento das entregas em tempo
real. Cada módulo terá suas próprias responsabilidades, tornando o código organizado e
facilitando a manutenção.
Ao dividir o sistema em módulos independentes, o desenvolvimento de cada parte pode ocorrer
de forma isolada, agilizando o processo e permitindo o trabalho em paralelo. Além disso, a
modularização promove a reutilização de código, uma vez que módulos bem de�nidos podem
ser facilmente reaproveitados em diferentes projetos. Isso resulta em uma maior e�ciência e
economia de tempo no desenvolvimento de software.
A separação de preocupações consiste em identi�car e isolar os diferentes aspectos do sistema,
como interface do usuário, lógica de negócio e integração com outros sistemas. Separar essas
preocupações em módulos distintos facilita a compreensão e manutenção do código, permitindo
o tratamento independente de cada parte. Essa separação também permite que diferentes
Disciplina
Arquitetura de Software
equipes trabalhem em paralelo, focadas em áreas especí�cas, aumentando a produtividade e
agilizando o processo de desenvolvimento.
O acoplamento se refere à dependência entre os módulos de um sistema. Um acoplamento
elevado pode tornar o código frágil e difícil de modi�car. Por isso, é importante reduzi-lo, criando
interfaces claras e bem de�nidas entre os módulos.
Para reduzir o acoplamento entre os módulos, podemos utilizar padrões de projeto, que
oferecem soluções testadas e comprovadas para problemas comuns no desenvolvimento de
software. Além disso, a adoção de boas práticas de programação, como o princípio da inversão
de dependência, também contribui para reduzir o acoplamento.
Um exemplo de coesão nesse contexto seria a criação de um módulo especí�co responsável por
gerenciar o registro das encomendas. Esse módulo teria todas as funcionalidades relacionadas
ao cadastro de encomendas, como receber os dados do cliente, detalhes do pacote e endereço
de entrega.
Ao concentrar todas as funcionalidades relacionadas ao registro das encomendas em um único
módulo, estamos criando uma alta coesão dentro desse componente. Isso signi�ca que todas as
partes desse módulo estão diretamente relacionadas à tarefa de registrar encomendas, e não há
funcionalidades irrelevantes ou dispersas que não estejam relacionadas a essa responsabilidade
especí�ca.
Uma abordagem prática para essa redução de acoplamento é estruturar nossa aplicação em três
camadas simples: uma camada para as regras de negócio, independente de tecnologia; uma
camada de infraestrutura, que abrange redes, dispositivos, bancos de dados, comunicações
externas e outros elementos; e uma camada intermediária, que engloba o framework e a
linguagem de programação responsáveis pela comunicação entre a camada de negócio e a de
infraestrutura. Essa organização em camadas segue uma ordem de importância de cima para
baixo, de forma que a camada superior, a de negócio, é a mais crucial e representa o módulo de
alto nível. 
Videoaula: Design de software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Nesta videoaula, vamos explorar conceitos fundamentais, como modularização, separação de
preocupações, acoplamento e coesão. Descubra como essas práticas podem revolucionar sua
abordagem no desenvolvimento de software. Aprenda a dividir sistemas complexos em módulos
independentes, isolar preocupações e a criar sistemas �exíveis e fáceis de manter. Vamos
embarcar nessa jornada e desvendar os segredos por trás de um software e�ciente e de alta
qualidade. Não perca esta oportunidade!
Disciplina
Arquitetura de Software
Saiba mais
Aprofunde seus conhecimentos com:
1. Amadurecendo com separação de preocupações. (Aprofundamento sobre a separação de
preocupações).
2. O que é SOLID? O guia completo para você entender os 5 princípios da POO [programação
orientada a objetos].
Referências
https://www.devmedia.com.br/amadurecendo-com-separation-of-concerns/18699
https://www.devmedia.com.br/amadurecendo-com-separation-of-concerns/18699
https://medium.com/desenvolvendo-com-paixao/o-que-%C3%A9-solid-o-guia-completo-para-voc%C3%AA-entender-os-5-princ%C3%ADpios-da-poo-2b937b3fc530
Disciplina
Arquitetura de Software
MARTIN, Robert C. Arquitetura limpa: o guia do artesão para estrutura e design de software. Rio
de Janeiro: Alta Books Editora, 2019. 
Aula 4
Implementação do design de software
Introdução
Disciplina
Arquitetura de Software
Olá, estudante!
Nesta aula, você aprenderá sobre a importância da separação de decisões de execução de
algoritmos, da separação de interfaces de suas implementações, dos níveis de design de
software e da abstração. Esses tópicos são fundamentais para construir sistemas robustos e de
fácil manutenção. Com a separação de decisões, podemos adaptar algoritmos para mudanças
futuras.
A separação de interfaces possibilita a criação de componentes reutilizáveis e independentes.
Os níveis de design facilitam o desenvolvimento e colaboração. A abstração lida com a
complexidade, ocultando detalhes de implementação. Aprender essas habilidades permitirá que
você crie sistemas de alta qualidade. Prepare-se para mergulhar nesse mundo fascinante do
design de software.
Bons estudos!
Conceitos iniciais
Disciplina
Arquitetura de Software
Na implementação do design de software, diversos conceitos são fundamentais para o
desenvolvimento de sistemase�cientes e de qualidade. De acordo com Martin (2019), vamos
explorar alguns deles: abstração, separação de decisões, interfaces de implementações e níveis
de design.
A abstração desempenha um papel crucial ao simpli�car a complexidade do sistema. Por meio
dela, podemos identi�car os aspectos essenciais e ocultar os detalhes desnecessários. Ao criar
modelos e representações, criamos uma visão mais clara e compreensível do software,
facilitando sua construção e manutenção. A abstração nos permite focar nos conceitos
fundamentais do sistema, ignorando os detalhes de implementação que não são relevantes para
a compreensão do funcionamento geral.
A separação de decisões é um princípio-chave para obter um design modular e �exível. Consiste
em identi�car partes do código responsáveis por tomar decisões especí�cas e isolá-las em
módulos independentes. Isso permite que cada decisão seja modi�cada de forma independente,
facilitando a manutenção do software e evitando impactos indesejados. Por exemplo, em um
sistema de comércio eletrônico, podemos separar a lógica de preci�cação em um módulo
separado, de modo que alterações na forma como os preços são calculados não afetem outras
partes do sistema.
As interfaces de implementações são pontos de comunicação entre os diferentes componentes
do sistema. Elas de�nem os contratos e as interações entre módulos, estabelecendo como as
partes se relacionam. Ao utilizar interfaces claras e bem de�nidas, é possível desenvolver
componentes de forma separada e substituir implementações sem afetar o funcionamento geral
do sistema. Por exemplo, em um sistema de pagamento online, podemos de�nir uma interface
Disciplina
Arquitetura de Software
comum para os diferentes métodos de pagamento, permitindo que novos métodos sejam
adicionados sem que seja necessário alterar o código existente que interage com a interface.
A organização em níveis de design é uma prática importante para construir sistemas complexos.
Consiste em dividir o software em camadas ou módulos, cada um com uma responsabilidade
especí�ca. Essa abordagem promove a modularidade, facilita a compreensão, a manutenção e a
evolução do sistema, além de possibilitar a reutilização de componentes em diferentes
contextos. Por exemplo, em um sistema de gerenciamento de estoque, podemos ter uma
camada de acesso a dados, uma camada de lógica de negócios e uma camada de interface do
usuário, cada uma com suas responsabilidades bem de�nidas.
Ao compreender e aplicar esses conceitos durante a implementação do design de software,
podemos criar sistemas mais robustos, �exíveis e de fácil manutenção. A abstração nos ajuda a
lidar com a complexidade, permitindo uma visão mais clara e focada nos conceitos essenciais. A
separação de decisões aumenta a �exibilidade, permitindo que diferentes partes do sistema
sejam modi�cadas independentemente umas das outras. As interfaces de implementações
estabelecem a comunicação entre os componentes, de�nindo contratos claros e facilitando a
substituição de implementações. Por �m, os níveis de design promovem a modularidade,
permitindo que o sistema seja dividido em partes com responsabilidades bem de�nidas.
Dominar esses conhecimentos é essencial para desenvolvedores de software que desejam criar
sistemas de alta qualidade. A implementação do design de software requer uma combinação de
habilidades técnicas e compreensão dos princípios de design. Portanto, aproveite esta
oportunidade para aprofundar seu entendimento sobre a implementação do design de software e
aplicar esses conceitos em seus projetos.
Entendendo a implementação
Disciplina
Arquitetura de Software
De acordo com Martin (2019), ao separar as decisões de execução de algoritmos em módulos
independentes, obtemos uma estrutura de código mais modular e �exível. Essa abordagem
permite que cada módulo seja responsável por uma decisão especí�ca, facilitando a
compreensão do sistema como um todo. Além disso, as alterações podem ser feitas de forma
isolada, sem afetar outras partes do software, o que contribui para a manutenibilidade e evolução
do sistema. A separação de decisões também evita a duplicação de código, permitindo que um
mesmo módulo seja reutilizado em diferentes partes do sistema, o que proporciona maior
e�ciência e economia de tempo durante o desenvolvimento.
Ao separar interfaces de suas implementações, obtemos um código mais �exível e adaptável. A
interface de�ne um contrato que estabelece como um componente deve ser usado, permitindo
que outros módulos do sistema se comuniquem com ele sem conhecer os detalhes internos de
sua implementação (MARTIN, 2019). Isso promove um baixo acoplamento e facilita a
substituição de uma implementação por outra, desde que ambas sigam a mesma interface. Essa
abordagem favorece a reutilização de código, pois diferentes módulos podem fazer uso da
mesma interface para se comunicar com diferentes implementações, proporcionando maior
�exibilidade e escalabilidade ao software. Além disso, a separação de interfaces de
implementações permite que diferentes equipes trabalhem de forma independente em cada
componente, acelerando o desenvolvimento e facilitando a manutenção do sistema.
Os níveis de design de software fornecem uma estrutura organizacional para o desenvolvimento
de sistemas complexos. No nível de arquitetura, são de�nidos os principais blocos funcionais do
sistema e suas interconexões. Essa etapa permite uma visão macro do sistema, identi�cando os
componentes e suas interações. No nível de componentes, os blocos funcionais são divididos
em módulos independentes com interfaces bem de�nidas. Isso promove a modularidade e a
separação de preocupações, facilitando a compreensão e o desenvolvimento de cada
componente individualmente (MARTIN, 2019). No nível de implementação, cada módulo é
detalhado em termos de algoritmos, estruturas de dados e codi�cação especí�ca. Essa etapa
envolve a tradução das especi�cações de design em código concreto, tornando o sistema
funcional.
A abstração é uma técnica essencial no design de software, permitindo que os desenvolvedores
se concentrem nos aspectos essenciais do sistema, enquanto ocultam os detalhes de
implementação (MARTIN, 2019). Por exemplo, ao abstrair a funcionalidade de manipulação de
estoque em uma interface genérica, podemos desenvolver diferentes implementações de
armazenamento de estoque, como em um banco de dados ou em arquivos, sem afetar a
interface abstrata. Isso facilita a manutenção e a evolução do sistema, pois mudanças na
implementação do estoque não impactarão a interface abstrata, garantindo a compatibilidade
com outros componentes do sistema.
Em resumo, a separação de decisões de execução de algoritmos, a separação de interfaces de
implementações, os níveis de design de software e a abstração são conceitos essenciais para
um design de software robusto e �exível. Essas práticas contribuem para a modularidade,
�exibilidade, reutilização de código, e�ciência e evolução do software, tornando-o mais adaptável
às mudanças e mais fácil de ser mantido. 
Implementação na prática
Disciplina
Arquitetura de Software
Na prática, a separação de decisões de execução de algoritmos pode ser aplicada de várias
formas. Por exemplo, no sistema de gerenciamento de estoque, pode-se ter um módulo separado
para tomar decisões relacionadas à reposição de estoque, como veri�car os níveis de estoque,
calcular as quantidades a serem compradas e emitir pedidos de compra. Esse módulo seria
responsável por todas as decisões relacionadas à reposição de estoque, permitindo que essa
lógica seja modi�cada de forma independente, sem afetar outras partes do sistema, como o
processo de venda ou o controle de inventário. De acordo com Martin (2019), essa separação de
decisões simpli�ca a compreensão e manutenção do sistema, além de facilitar a escalabilidade,
uma vez que cada módulo pode ser adaptado ou substituído sem impactar o restante do
software.
A separação de interfaces de suas implementações é amplamente aplicada no desenvolvimento
de software.No exemplo visto anteriormente, em um sistema de gerenciamento de pagamentos
online, pode haver uma interface comum para processar pagamentos, que de�ne métodos como
“realizarPagamento” e “cancelarPagamento”.  Diferentes implementações dessa interface podem
ser criadas para se integrar com diferentes provedores de pagamento, como PayPal, Stripe ou
PagSeguro. Cada implementação é responsável por encapsular a lógica especí�ca de integração
com o provedor de pagamento correspondente, enquanto a interface comum garante que todos
os componentes do sistema possam interagir com qualquer uma dessas implementações sem
necessidade de conhecer os detalhes especí�cos. Essa separação de interfaces de
implementações torna o sistema mais �exível, permitindo a adição ou substituição de
provedores de pagamento de forma transparente, sem impactar outros componentes do sistema
(MARTIN, 2019).
Os níveis de design de software e a abstração são amplamente aplicados no desenvolvimento de
sistemas complexos. Por exemplo, em um sistema de reservas de passagens aéreas, podemos
ter um nível de arquitetura que de�ne os principais componentes, como o módulo de reserva, o
módulo de busca de voos e o módulo de pagamento. Cada um desses módulos pode ser então
Disciplina
Arquitetura de Software
dividido em componentes menores, como o módulo de autenticação, o módulo de seleção de
assentos e o módulo de processamento de pagamentos, formando o nível de componentes.
A abstração pode ser aplicada no nível de componentes, de forma que podemos de�nir
interfaces genéricas para cada módulo, como uma interface de reserva que de�ne os métodos
“fazerReserva” e “cancelarReserva”. A implementação concreta dessas interfaces pode variar;
por exemplo, uma implementação usando um banco de dados relacional e outra usando uma API
de serviços web. Essa abstração permite que diferentes implementações sejam intercambiáveis,
desde que sigam a mesma interface.
Esses conceitos são fundamentais para o desenvolvimento de software de qualidade, pois
permitem a criação de sistemas bem estruturados, de fácil manutenção e �exíveis o su�ciente
para se adaptar a mudanças nos requisitos. Os níveis de design e a abstração auxiliam a
compreensão e organização do código, promovem a reutilização de componentes e facilitam a
evolução do software ao longo do tempo. 
Videoaula: Implementação do design de software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Aprenda sobre a separação de decisões de algoritmos, interfaces e níveis de design de software,
além de compreender a importância da abstração. Assista à nossa videoaula de resumo e
aprofunde seus conhecimentos em design de software. Descubra como a separação de decisões
e interfaces torna o código modular e �exível; explore os diferentes níveis de design e entenda
como a abstração facilita a manutenção e evolução do sistema. Prepare-se para impulsionar sua
carreira no desenvolvimento de software. Acesse agora mesmo e amplie seu conhecimento
nessa área fundamental!
Saiba mais
Disciplina
Arquitetura de Software
1. Como dividir o design de software em próximas etapas executáveis. Neste artigo você
aprenderá a direcionar sua equipe para a realização de um projeto. Com o planejamento
adequado, você pode identi�car marcos e fornecer a todos as instruções exatas para
manter seu projeto no caminho certo.
2. Por que o design de software é importante para o seu aplicativo.O desenvolvimento de
software tem tudo a ver com escrever códigos porque códigos complexos ajudam os
desenvolvedores a desenvolver software simples com grande utilidade. Nesse artigo,
vamos aprender a importância de design de software no desenvolvimento de sistemas,
como aplicativos.
Referências
https://www.lucidchart.com/blog/pt/como-implementar-o-design-de-software#:~:text=Defina%20como%20voc%C3%AA%20construir%C3%A1%20o,como%20voc%C3%AA%20planeja%20alcan%C3%A7%C3%A1%2Dlo
https://www.lucidchart.com/blog/pt/como-implementar-o-design-de-software#:~:text=Defina%20como%20voc%C3%AA%20construir%C3%A1%20o,como%20voc%C3%AA%20planeja%20alcan%C3%A7%C3%A1%2Dlo
https://appmaster.io/pt/blog/por-que-o-design-de-software-e-importante-para-seu-aplicativo
Disciplina
Arquitetura de Software
MARTIN, Robert C. Arquitetura limpa: o guia do artesão para estrutura e design de software. Rio
de Janeiros: Alta Books Editora, 2019.
VLISSIDES, John; et al. Padrões de Projeto: Soluções Reutilizáveis de Software Orientado a
Objetos. Porto Alegre: Editora Bookman, 2000.
Aula 5
Revisão da Unidade
Design de arquitetura de software: princípios e práticas
Disciplina
Arquitetura de Software
Olá, estudante! A arquitetura de software desempenha um papel fundamental no
desenvolvimento de sistemas de excelência. Ela se refere ao projeto e à organização estruturada
dos componentes de um software, abrangendo a tomada de decisões sobre a divisão e
encapsulamento de funcionalidades, modularização, separação de preocupações, acoplamento e
coesão, entre outros aspectos.
O design de arquitetura é essencial para o sucesso de um projeto de software, pois determina a
base sobre a qual o sistema será construído. Uma arquitetura bem projetada permite que o
software seja �exível, adaptável e escalável ao longo do tempo. Facilita também a manutenção,
evolução e reutilização de componentes.
No processo de design de software, há diversos elementos a serem considerados. Isso inclui a
identi�cação de requisitos e restrições, análise de riscos, de�nição de uma estratégia de design,
escolha de padrões de projeto adequados e criação de diagramas de arquitetura. Esses
elementos ajudam a guiar o desenvolvimento do software de forma estruturada e e�ciente.
A modularização é um princípio-chave do design de software, que envolve a divisão do sistema
em módulos independentes e coesos. Cada módulo é responsável por uma funcionalidade
especí�ca, o que facilita a compreensão e a manutenção do código. A separação de
preocupações, por sua vez, consiste em isolar aspectos distintos do sistema em módulos
separados, promovendo a legibilidade e a manutenibilidade do código.
O acoplamento e a coesão são conceitos relacionados ao design de software. O acoplamento
refere-se à dependência entre os módulos de um sistema, enquanto a coesão diz respeito à
relação entre as responsabilidades dentro de um módulo. Um baixo acoplamento e uma alta
coesão são objetivos desejáveis para um design de software e�ciente.
Disciplina
Arquitetura de Software
A separação de decisões de execução de algoritmos e a separação das interfaces de
implementações são práticas importantes no design de software. A separação de decisões
permite que cada módulo seja responsável por tomar decisões especí�cas, facilitando a
manutenção e evitando impactos indesejados. Já a separação de interfaces garante que a
comunicação entre módulos ocorra de forma �exível, permitindo a substituição de
implementações sem afetar outros componentes do sistema.
Os níveis de design de software fornecem uma estrutura organizacional para o desenvolvimento
de sistemas complexos. Eles envolvem a de�nição de diferentes camadas de abstração, como o
nível de arquitetura, o nível de componentes e o nível de implementação. Cada nível agrupa
componentes relacionados e de�ne suas interações, facilitando o desenvolvimento e a
compreensão do sistema como um todo.
A abstração é uma técnica essencial no design de software, permitindo que os desenvolvedores
se concentrem nos aspectos essenciais do sistema, enquanto ocultam os detalhes de
implementação. Ela favorece a reutilização de código e facilita a evolução do software ao longo
do tempo.
Em suma, o design de arquitetura é um componente fundamental no desenvolvimento de
software. Ele engloba diversos aspectos, desde a modularização e a separação de preocupações
até a separação de decisões e interfaces. Com uma arquitetura bem projetada, é possívelobter
sistemas de alta qualidade, �exíveis e fáceis de manter e evoluir ao longo do tempo.
Videoaula: Revisão da Unidade
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Neste vídeo, vamos explorar a importância do design no desenvolvimento de sistemas. Veremos
os princípios fundamentais do design de software, incluindo modularização, separação de
preocupações e acoplamento. Além disso, abordaremos a separação de decisões de execução
de algoritmos, a separação de interfaces de suas implementações, os níveis de design de
software e a importância da abstração. Prepare-se para uma jornada de aprendizado sobre
design de arquitetura de software!
Estudo de Caso
Disciplina
Arquitetura de Software
Contexto:
Você é um desenvolvedor de software em uma empresa de tecnologia �nanceira que visa a
fornecer soluções inovadoras para ajudar as pessoas no gerenciamento e�ciente das suas
�nanças pessoais. A empresa deseja desenvolver um sistema de gerenciamento de �nanças
pessoais que permita aos usuários acompanharem seus gastos, criarem orçamentos, de�nirem
metas �nanceiras e obterem insights sobre seus hábitos de consumo.
Desa�o:
Seu desa�o é iniciar um projeto de arquitetura e design do software para o sistema de
gerenciamento de �nanças pessoais. O sistema deve ser �exível, escalável e de fácil
manutenção, permitindo que novas funcionalidades sejam adicionadas no futuro sem impactar
as já existentes. Além disso, ele deve ser seguro, garantindo a proteção dos dados �nanceiros
dos usuários.
Passos:
Análise de requisitos: inicie o projeto realizando uma análise detalhada dos requisitos do
sistema. Identi�que as funcionalidades principais, como registro de transações �nanceiras,
geração de relatórios, criação de metas �nanceiras e noti�cações personalizadas.
Arquitetura do sistema: de�na a arquitetura do sistema, identi�cando os principais
componentes e suas interações. Pense em como os dados serão armazenados,
processados e apresentados para os usuários. Considere a separação de decisões de
execução de algoritmos e a separação de interfaces de suas implementações para criar
módulos independentes e reutilizáveis.
Design de componentes: projete os detalhes de cada componente do sistema. Utilize os
conceitos de acoplamento e coesão para garantir que cada componente seja coeso em sua
função e tenha baixo acoplamento com os demais.
Disciplina
Arquitetura de Software
Escolha de tecnologias: escolha as tecnologias e ferramentas adequadas para implementar
o sistema. Leve em consideração fatores como escalabilidade, segurança e desempenho.
Considere também a abstração de detalhes de implementação para permitir que diferentes
tecnologias possam ser usadas sem afetar a interface do sistema.
Passos complementares:
Testes e validação: pense em planos de testes abrangentes para cada componente do
sistema e realize testes rigorosos para garantir que o software funcione corretamente e
atenda aos requisitos de�nidos.
Documentação: apresente quais documentos você usaria, como diagramas de alto nível e
detalhes técnicos relevantes. Isso garantirá que o conhecimento do sistema seja bem
documentado e possa ser compartilhado com outros membros da equipe.
Apresentação do projeto: ao concluir o projeto, apresente a arquitetura e o design do
sistema para a equipe e os stakeholders. Explique as principais características e benefícios
do design adotado.
Resultados esperados:
Espera-se que, ao �nal do projeto, você tenha elaborado o esboço inicial de uma arquitetura
sólida e um design de software para o sistema de gerenciamento de �nanças pessoais. O
sistema deverá ser capaz de atender aos requisitos de�nidos, ser �exível o su�ciente para
acomodar mudanças futuras e garantir a segurança e proteção dos dados dos usuários. O
estudo de caso permitirá aplicar os conhecimentos adquiridos sobre arquitetura, design de
software, modularização, separação de preocupações, acoplamento, coesão, escalabilidade e
abstração em um cenário real de desenvolvimento pro�ssional.
Após re�etir sobre o conteúdo abordado, �ca evidente a importância da aplicação dos conceitos
de arquitetura e design de software no desenvolvimento de sistemas e�cientes e bem
estruturados. O estudo de caso do sistema de gerenciamento de �nanças pessoais ilustra como
a separação de decisões de execução de algoritmos e a separação de interfaces de suas
implementações podem contribuir para um design �exível e adaptável, permitindo que cada
módulo seja responsável por suas próprias tarefas e facilmente intercambiável.
A modularização e a de�nição clara de interfaces entre os módulos garantem uma baixa
dependência entre eles, facilitando a manutenção e evolução do sistema ao longo do tempo.
Além disso, a escolha adequada de tecnologias e a realização de testes abrangentes são
fundamentais para garantir a qualidade e a segurança do software.
Ao aprofundarmos nossos conhecimentos em arquitetura e design de software, podemos aplicar
esses princípios em diferentes cenários pro�ssionais, permitindo-nos desenvolver soluções mais
sólidas e e�cientes para as demandas do mundo digital. A re�exão sobre esses conceitos nos
motiva a buscar constantemente o aprimoramento de nossas habilidades e conhecimentos,
contribuindo para a excelência em nossas práticas de desenvolvimento de software e
promovendo um impacto positivo na vida das pessoas através de soluções tecnológicas
inovadoras e con�áveis.
Resolução do Estudo de Caso
Disciplina
Arquitetura de Software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Desenvolvimento de um sistema de gerenciamento de �nanças pessoais
Análise de requisitos:
Após uma análise detalhada dos requisitos, foram identi�cadas as principais funcionalidades do
sistema de gerenciamento de �nanças pessoais: registro de transações �nanceiras, geração de
relatórios �nanceiros mensais, quinzenais e semanais, criação de metas �nanceiras e
noti�cações personalizadas. Essas funcionalidades permitirão que os usuários tenham um
controle completo sobre suas �nanças e possam tomar decisões �nanceiras mais informados.
Arquitetura do sistema:
Para garantir a �exibilidade, escalabilidade e facilidade de manutenção do sistema, optou-se por
uma arquitetura de microsserviços. Cada funcionalidade será implementada como um serviço
independente, permitindo que novas funcionalidades sejam adicionadas sem afetar o
funcionamento dos demais serviços. A separação de decisões de execução de algoritmos será
aplicada em cada serviço, garantindo que cada um seja responsável por suas próprias regras de
negócio.
Design de componentes:
O sistema será dividido em módulos independentes, cada um responsável por uma
funcionalidade especí�ca. Por exemplo, o módulo de registro de transações será responsável por
receber e armazenar as transações �nanceiras dos usuários, enquanto o módulo de geração de
relatórios será responsável por processar os dados e gerar relatórios personalizados. As
interfaces entre os módulos serão cuidadosamente de�nidas, garantindo uma baixa dependência
entre eles.
Escolha de tecnologias:
Para implementar o sistema, serão utilizadas tecnologias modernas e escaláveis, como o uso de
contêineres para facilitar o empacotamento e a implantação dos serviços. O banco de dados
será escolhido com base na necessidade de escalabilidade e segurança dos dados dos usuários.
Além disso, serão adotadas práticas de segurança para proteger as informações �nanceiras dos
usuários.
Testes e validação:
Serão desenvolvidos planos de teste abrangentes para cada módulo do sistema, incluindo testes
unitários, testes de integração e testes de aceitação. Os testes serão realizados de forma
rigorosa para garantir que todas as funcionalidades estejam funcionandocorretamente e que o
sistema atenda aos requisitos de�nidos.
Documentação:
Todo o processo de arquitetura e design do software será documentado de forma detalhada,
incluindo decisões tomadas, diagramas de alto nível e detalhes técnicos. A documentação será
fundamental para garantir que o conhecimento do sistema seja bem documentado e possa ser
compartilhado com outros membros da equipe.
Disciplina
Arquitetura de Software
Apresentação do projeto:
Após a conclusão do projeto, a arquitetura e o design do sistema serão apresentados para a
equipe e os stakeholders. Serão explicadas as principais características e benefícios do design
adotado, destacando a �exibilidade, escalabilidade e segurança do sistema.
Com o projeto concluído, espera-se que o sistema de gerenciamento de �nanças pessoais seja
uma solução robusta, escalável e segura, permitindo que os usuários tenham um controle
completo sobre suas �nanças de forma e�ciente e segura. O estudo de caso permitiu aplicar os
conhecimentos adquiridos sobre arquitetura, design de software, modularização, separação de
preocupações, acoplamento, coesão, escalabilidade e abstração em um cenário real de
desenvolvimento pro�ssional.
Resumo Visual
Disciplina
Arquitetura de Software
Fonte: elaborada pela autora.
Referências
Disciplina
Arquitetura de Software
MARTIN, Robert C. Arquitetura limpa: o guia do artesão para estrutura e design de software. Rio
de Janeiro: Alta Books Editora, 2019.