wlldd_232_u3_arq_sof

Prévia do material em texto

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!
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.
23 minutos
 Aula 1 - Documentação da arquitetura
 Aula 2 - Decisões arquiteturais
 Aula 3 - Visões arquiteturais
 Aula 4 - Estudo de caso – sistema de aluguel e streaming
de �lmes (SASF)
 Aula 5 - Revisão da unidade
 Referências
132 minutos
Imprimir
V
er
 a
n
o
ta
çõ
es
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula1
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula1
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula1
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula1
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula2
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula2
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula2
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula2
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula3
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula3
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula3
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula3
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula4
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula4
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula4
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula4
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula4
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula4
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula4
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula5
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula5
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula5
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#aula5
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#referencias
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/index.html#referencias
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 é 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 é 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 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 é 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
 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.
V
er
 a
n
o
ta
çõ
es
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. esse documento descreve uma visão geral do
sistema, incluindo seus componentes, suas interações e as decisões arquiteturais fundamentais.
2. 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:
Quadro 1 | Modelos de diagramas de arquitetura
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 Casos de 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.
Fonte: adaptado pelo autor a partir de Sommerville (2011).
3. 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).
4. 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).
5. 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 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 de forma unidirecional,
das camadas inferiores para as superiores. Na 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.
V
er
 a
n
o
ta
çõ
es
Na 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 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 (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.
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.
1. é uma ferramenta de modelagem abrangente que permite criar diagramas e
modelos para representar a arquitetura do software. Ela oferece recursos de rastreabilidade,
permitindo estabelecer links entre requisitos, componentes, testes e outras entidades do sistema
(CERVANTES; KAZMAN, 2016).
2. é 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).
3. 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).
4. 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
V
er
 a
n
o
ta
çõ
es
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.
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 comunicação, mostrando ainda como o modelo
para análise e ferramenta de rastreabilidade são úteis.

Sugerimos uma referência para que você possa aprofundar um poucomais seus conhecimentos sobre
arquitetura de software: 
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!
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.
23 minutos
V
er
 a
n
o
ta
çõ
es
https://aws.amazon.com/pt/what-is/service-oriented-architecture/
https://aws.amazon.com/pt/what-is/service-oriented-architecture/
https://aws.amazon.com/pt/what-is/service-oriented-architecture/
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 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 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 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 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).
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
V
er
 a
n
o
ta
çõ
es
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 não de�nem
partes do sistema, mas são responsáveis por de�nir sua estrutura, componentes e interações (BARBOSA,
2009). Essas decisões envolvem a escolha de padrões de 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.
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).
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
V
er
 a
n
o
ta
çõ
es
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 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.
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.

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 .
V
er
 a
n
o
ta
çõ
es
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/Metodologia%20%C3%81gil%20%E2%80%93%20O%20que%20%C3%A9
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/Metodologia%20%C3%81gil%20%E2%80%93%20O%20que%20%C3%A9
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/Metodologia%20%C3%81gil%20%E2%80%93%20O%20que%20%C3%A9
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/Metodologia%20%C3%81gil%20%E2%80%93%20O%20que%20%C3%A9
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 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!
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.
Figura 1 | Modelo 4+1 de Kruchten
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 dessesmodelos 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.
24 minutos
V
er
 a
n
o
ta
çõ
es
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).
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.
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 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
V
er
 a
n
o
ta
çõ
es
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.
Quadro 1 | Modelo de visões do SEI
Concentra na estrutura lógica do sistema de software e
descreve os componentes principais do sistema, e as
pendências funcionais entre eles
ROZANSKI & WOODS
(2012)
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)
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)
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)
V
er
 a
n
o
ta
çõ
es
Focanos aspectos relacionados à gerência e à
organização no sistema
CLEMENTS et al. (2003)
 
Fonte: elaborado pelo autor.
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 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.
• 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).
• 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).
• é 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.
• 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).
• 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.
V
er
 a
n
o
ta
çõ
es
• 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.
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.

Para aprofundar seu conhecimento sobre os temas relacionados à Integração do Modelo de
Maturidade de Capacidade (CMMI), recomendamos a leitura do capítulo 8.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.
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!
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.
23 minutos
V
er
 a
n
o
ta
çõ
es
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
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
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
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 paraengajar 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.
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.
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 é 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
V
er
 a
n
o
ta
çõ
es
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ências dos
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).
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
V
er
 a
n
o
ta
çõ
es
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á 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 algoritmode
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.
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!

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).
Olá, estudante! A arquitetura de software é fundamental para garantir a compreensão, organização e
33 minutos
V
er
 a
n
o
ta
çõ
es
https://tecnoblog.net/responde/como-funciona-a-netflix/
https://tecnoblog.net/responde/como-funciona-a-netflix/
https://tecnoblog.net/responde/como-funciona-a-netflix/
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 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.
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). 
V
er
 a
n
o
ta
çõ
es
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.   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. 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 maneiraadequada.
3. 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.
4. 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. 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.
6. analisar os atributos das decisões, como a criticidade,
estabilidade, �exibilidade e desempenho, para entender o impacto de cada uma na arquitetura e na
evolução do sistema.
7. 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.

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,
V
er
 a
n
o
ta
çõ
es
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. 
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.
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. a equipe receberá treinamentos e capacitação em relação à utilização das
V
er
 a
n
o
ta
çõ
es
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 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.
Fonte: elaborada pelo autor.
AMAZON. Disponível em: https://aws.amazon.com/pt/what-
is/service-oriented-architecture/. Acesso em: 15 jul. 2023.
BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. 3 ed. Boston: Addison-
Wesley, 2012.
CERVANTES, Humberto; KAZMAN, Rick. a practical approach. Boston:
Addison-Wesley Professional, 2016.
DOAR, Matthew.  Using JIRA E�ectively: Beyond the Documentation.
Sebastopol: O’Reilly Media Inc., 2011.                                              
FARLEY, David. Doing What Works to Build Better Software Faster. Boston:
Addison-Wesley Professional, 2021.
KRUCHTEN, Philippe. An Introduction. 3 ed. Boston: Addison-Wesley, 2004.
a
a
6 minutos
V
er
 a
n
o
ta
çõ
es
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/assets/img/fig_a5_01.jpg
https://conteudo.colaboraread.com.br/202302/WHITE_LABEL/ARQUITETURA_DE_SOFTWARE/LIVRO/U3/assets/img/fig_a5_01.jpg
https://aws.amazon.com/pt/what-is/service-oriented-architecture/
https://aws.amazon.com/pt/what-is/service-oriented-architecture/
https://aws.amazon.com/pt/what-is/service-oriented-architecture/
https://aws.amazon.com/pt/what-is/service-oriented-architecture/
MAXIM, B. R.; PRESSMAN, Roger S. uma abordagem pro�ssional. Porto Alegre:
Bookman, 2021.
SHAW, Mary; GARLAN, David. Perspectives on an Emerging Discipline. Upper Saddle
River: Prentice Hall, 1996.
SOMMERVILLE, Ian. São Paulo: Pearson Education, 2011.
ALURA. Disponível em: https://www.alura.com.br/artigos/o-que-e-metodologia-
agil. Acesso em: 1 ago. 2023.
BARBOSA, Guilherme Mauro Germoglio. 
 Dissertação (Mestrado em Ciência da Computação) – UniversidadeFederal 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%20MAURO%20GERMOGLIO%20BARBOSA%20-%20DISSERTA%C3%87%C3%83O%20%28PPGCC
%29%202009..pdf. Acesso em: 28 jul. 2023.
BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. 3 ed. Boston: Addison-
Wesley, 2012.
CERVANTES, Humberto; KAZMAN, Rick. a practical approach. Boston:
Addison-Wesley Professional, 2016.
FARLEY, David. Doing What Works to Build Better Software Faster. Boston:
Addison-Wesley Professional, 2021.
HOFMEISTER, Christine; NORD, Robert L.; SONI, Dilip. Boston: Addison-
Wesley Professional, 2000.
KRUCHTEN, Philippe. An Introduction. 3 ed. Boston: Addison-Wesley, 2004.
KRUCHTEN, Philippe. LAGO, Patricia; VLIET, Hans van. Building Up and Reasoning About Architectural
Knowledge. In: 
 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. 
Towards traceable and sustainable Documentation and Communication. Copenhague: NordDesign, 2022.
SHAW, Mary; GARLAN, David. Perspectives on an Emerging Discipline. Upper Saddle
River: Prentice Hall, 1996.
BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. 3 ed. Boston: Addison-
Wesley, 2012.
CLEMENTS, Paul; KAZMAN, Rick; KLEIN, Mark. 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: 
 IEEE, p. 740-741, 2003.
DOAR, Matthew. Using JIRA E�ectively: Beyond the Documentation.
Sebastopol: O’Reilly Media Inc., 2011.
GARLAN, David; SHAW, Mary. Advances in Software Engineering
a
a
a
V
er
 a
n
o
ta
çõ
es
https://www.alura.com.br/artigos/o-que-e-metodologia-agil
https://www.alura.com.br/artigos/o-que-e-metodologia-agil
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
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
Imagem de capa: Storyset e ShutterStock.
and Knowledge Engineering. Pittsburgh: School of Computer Science, 1993.
HOFMEISTER, Christine; NORD, Robert L.; SONI, Dilip. Views and
Beyond. Boston: Addison-Wesley Professional, 2002.
KRUCHTEN, Philippe. An Introduction. 3 ed. Boston: Addison-Wesley, 2004.
MEDVIDOVIC, Nenad; TAYLOR, Richard N.; OREIZY, Peyman. A Classi�cation and Comparison Framework for
Software Architecture Description Languages. 2000.
ROZANSKI, Nick; WOODS, Eoin. working with stakeholders using
viewpoints and perspectives. Boston: Addison-Wesley, 2012.
SHAW, Mary; GARLAN, David. Perspectives on an Emerging Discipline. Upper Saddle
River: Prentice Hall, 1996.
BARBOSA, Guilherme Mauro Germoglio. 
 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_GuilhermeMauroGerrmoglioBarbosa.pdf. Acesso em: 15 jul. 2023.
FUNK, Je�rey L. The Technologies and Applications Driving the Mobile Internet.
Hoboken: Wiley, 2003.
GOGONI, Ronaldo. Como funciona a Net�ix? (do DVD ao streaming). , 2019. Disponível em:
https://tecnoblog.net/responde/como-funciona-a-net�ix/. Acesso em: 20 jul. 2023.
MCDONALD, Kevin; SMITH-ROWSEY, Daniel. Technology and Entertainment in the 21st
Century. Londres: Bloomsbury Publishing PLC, 2016.
RICCI, Francesco; ROKACH, Lior; SHAPIRA, Bracha; KANTOR, Paul B. 
Nova York: Springer, 2010.
SMITH, Michael D.; TELANG, Rahul. Big Data and the Future of Entertainment.
Cambridge: The MIT Press, 2016.
TRICART, Celine. Techniques & Best Practices for VR Filmmakers. Abingdon:
Routledge, 2017.
BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. 3 ed. Boston: Addison-
Wesley, 2012.
DOAR, Matthew.  Using JIRA E�ectively: Beyond the Documentation.
Sebastopol: O’Reilly Media Inc., 2011.
KRUCHTEN, Philippe. An Introduction. 3 ed. Boston: Addison-Wesley, 2004.
ROZANSKI, Nick; WOODS, Eoin. working with stakeholders using
viewpoints and perspectives. Boston: Addison-Wesley, 2012.
SHAW, Mary; GARLAN, David. Perspectives on an Emerging Discipline. Upper Saddle
River: Prentice Hall, 1996.
a
a
a
V
er
 a
n
o
ta
çõ
es
https://storyset.com/
https://storyset.com/
https://www.shutterstock.com/pt/
https://www.shutterstock.com/pt/
http://docs.computacao.ufcg.edu.br/posgraduacao/dissertacoes/2009/Dissertacao_GuilhermeMauroGerrmoglioBarbosa.pdf
http://docs.computacao.ufcg.edu.br/posgraduacao/dissertacoes/2009/Dissertacao_GuilhermeMauroGerrmoglioBarbosa.pdf
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/
https://tecnoblog.net/responde/como-funciona-a-netflix/