Arquitetura_de_software_e_como_descreve-la_v2

Arquitetura de software
Universidade Federal do Amazonas – UFAM
Institute of Computing - IComp
Usability and Software Engineering Group – USES
Manaus, Brasil, 2022
Por que pensar nela e como registrá-la
Leonardo Barreto Tayana Conte

❑ Leonardo Barreto
❑ Programa de Pós-graduação em Informática - UFAM
❑ Orientadora: Prof. Tayana Conte
❑ Linha de pesquisa: Arquitetura de software, Documentação
Sobre mim

Analogia: Arquitetura de uma casa
Bass, L., P. Clements, and R. Kazman, Software Architecture in Practice, 2nd ed., Addison-Wesley, 2003
Elementos
Propriedades
Relações

O que é arquitetura de software?
❑ Definição
❑ estrutura, ou estruturas, do sistema,
❑ abrange os componentes de software,
❑ as propriedades externamente visíveis
desses componentes
❑ as relações entre eles.
Bass, L., P. Clements, and R. Kazman, Software Architecture in Practice, 2nd ed., Addison-Wesley, 2003

❑ Importância
❑ Qualidade
❑ Escala
❑ Segurança
❑ Desempenho
❑ Disponibilidade
❑ Princípios sobre o sistema
❑ Planejamento do futuro
Erder M., Pureur P., Woods E., Continuous Architecture in Practice, 1st ed., Addison-Wesley, 2021

❑ Como era feito antes?
❑ Cascata
❑ Planejamento completo do sistema antes do desenvolvimento
❑ Desenvolvimento incremental e iterativo
❑ Como é feito hoje?
❑ Ágil - Scrum, XP
❑ Ad-hoc

Pensar na arquitetura de software?
❑ Decisões, decisões e decisões
❑ O que é mais importante para o meu sistema?
❑ Como ele será implementado?
❑ Linguagem
❑ Plataforma
❑ Distribuído?
❑ Cloud ou servidor próprio?
❑ Recursos disponíveis
❑ Tempo
❑ Dinheiro
❑ Pessoas

Pensar na arquitetura de software?
❑ Decisões, decisões e decisões
❑ Aspectos de qualidade
❑ Escala
❑ Segurança
❑ Infraestrutura
❑ Arquitetura
❑ Usuários
❑ Todo mundo usa a mesma parte do sistema?
❑ Quem vai ver a arquitetura do sistema?

Por que registrar a arquitetura de software?
❑ Como as novas pessoas na empresa vão entender o sistema?
Tirar dúvidas
com o chefe
Reuniões com a
equipe de
desenvolvimento
Documentação
❑ E se as pessoas que entendem do sistema saírem da empresa?

Exemplo: Desenvolvimento contínuo
❑ Problemas com documentação em desenvolvimento de software
contínuo
❑ Documentação informal é difícil de entender
❑ Documentação é considerada lixo
❑ Documentação não sincronizada com o código,
❑ Práticas de documentação
❑ Comunicação informal
❑ artefatos de desenvolvimento como documentos
❑ frameworks arquiteturais
Theo Theunissen, Uwe van Heesch, Paris Avgeriou, A mapping study on documentation in Continuous Software Development, Information and Software Technology, Volume
142, 2022, 106733, ISSN 0950-5849, https://doi.org/10.1016/j.infsof.2021.106733.

Como registrar a arquitetura de software?
❑ Não há padrões para desenhar a arquitetura de um software.
Imagens extraídas de www.c4model.com

Como registrar a arquitetura de software?
❑ Não há padrões para desenhar a arquitetura de um software.
Imagens extraídas de pesquisa no Google Imagens, com a string "software architecture"

ISO 42010:2011
"ISO/IEC/IEEE Systems and software engineering -- Architecture description," in ISO/IEC/IEEE 42010:2011(E) (Revision
of ISO/IEC 42010:2007 and IEEE Std 1471-2000) , vol., no., pp.1-46, 1 Dec. 2011, doi: 10.1109/IEEESTD.2011.6129467.

ISO 42010:2011 - Stakeholders
❑ Para quem eu quero mostrar algo do sistema.
"ISO/IEC/IEEE Systems and software engineering -- Architecture description," in ISO/IEC/IEEE 42010:2011(E) (Revision of ISO/IEC 42010:2007 and IEEE Std
1471-2000) , vol., no., pp.1-46, 1 Dec. 2011, doi: 10.1109/IEEESTD.2011.6129467.
Usuários Donos Desenvolvedores

ISO 42010:2011 - Concerns
❑ O que eu quero mostrar do sistema.
"ISO/IEC/IEEE Systems and software engineering -- Architecture description," in ISO/IEC/IEEE 42010:2011(E) (Revision of ISO/IEC 42010:2007 and IEEE Std
1471-2000) , vol., no., pp.1-46, 1 Dec. 2011, doi: 10.1109/IEEESTD.2011.6129467.
Riscos
Propósito Manutenção Evolução

ISO 42010:2011
❑ Architecture Description
❑ visão da arquitetura
❑ raciocínio
❑ explicação das decisões
importantes tomadas
❑ modelos
❑ notações, diagramas
"ISO/IEC/IEEE Systems and software engineering -- Architecture description," in ISO/IEC/IEEE 42010:2011(E) (Revision
of ISO/IEC 42010:2007 and IEEE Std 1471-2000) , vol., no., pp.1-46, 1 Dec. 2011, doi: 10.1109/IEEESTD.2011.6129467.

Arquitetura de Software
Abordagens de Descrição
Universidade Federal do Amazonas – UFAM
Institute of Computing - IComp
Usability and Software Engineering Group – USES
Manaus, Brasil, 2022
Slides feitos por Leonardo Barreto

Kruchten’s 4+1
P. B. Kruchten, "The 4+1 View Model of architecture," in IEEE Software, vol. 12, no. 6, pp. 42-50,
Nov. 1995, doi: 10.1109/52.469759.

Kruchten’s 4+1
❑ 1995 - Criada por Philippe Kruchten
❑ 4 visões principais
❑ Lógica - abstração de objetos a partir dos requisitos funcionais
❑ Processos - requisitos não funcionais; processos distribuídos no
hardware, atividades no sistema
❑ Desenvolvimento - organização de módulos; requisitos internos de
desenvolvimento
❑ Física - mapear os elementos para o hardware disponível
❑ 1 visão especial - Cenários
P. B. Kruchten, "The 4+1 View Model of architecture," in IEEE Software, vol. 12, no. 6, pp. 42-50, Nov. 1995, doi: 10.1109/52.469759.

Kruchten's 4+1

Sistema de exemplo
❑ Gerenciamento de biblioteca (MVP)
❑ Requisitos funcionais
❑ O sistema deve permitir ao bibliotecário manter os livros do catálogo,
agrupados por categoria, através de um dashboard.
❑ O sistema deve permitir ao bibliotecário gerenciar empréstimos.
❑ O sistema deve permitir ao bibliotecário manter os dados dos
estudantes.
❑ O sistema deve permitir ao bibliotecário emprestar um livro para um
estudante.
Requisitos adaptados de https://github.com/Requisitos-2018-1-iFood/iFood/wiki/Prioriza%C3%A7%C3%A3o-de-requisitos---Moscow

4+1 - Visão Lógica
❑ Abstração de objetos a partir dos requisitos funcionais
❑ Stakeholders: Analistas, gerentes, aqueles que projetam o sistema
❑ Concern: Como o sistema vai funcionar
❑ Estrutural
❑ Orientado a objetos (Abstração, Herança, Encapsulamento)
❑ Diagrama de Classes UML
❑ Visão estática do sistema
❑ módulos, serviços, APIs

4+1 - Visão de Desenvolvimento
❑ Componentes do sistema
❑ Stakeholders: programadores, gerentes de projeto
❑ Concern: gerenciamento e desenvolvimento do sistema
❑ Estrutural
❑ Abstração em pacotes e componentes
❑ Depende da linguagem e do framework escolhidos
❑ Diagrama de pacotes e componentes UML.

4+1 - Visão de Desenvolvimento

4+1 - Visão de Processos
❑ Compreende as partes dinâmicas do sistema.
❑ Stakeholders: Quem vai fazer a integração do sistema
❑ Concerns: Desempenho, escalabilidade, throughput (vazão)
❑ Comportamental
❑ Em tempo de execução
❑ Diagrama de atividades, sequência, comunicação, estados (UML)

4+1 - Visão Física
❑ Alocação dos recursos físicos para execução do sistema
❑ Stakeholders: Equipe de implantação (Operacional)
❑ Concern: Topologia do sistema, instalação, entrega
❑ Estrutural
❑ Servidores, Redes, Nuvem, Aparelhos (computadores, celulares), IoT
❑ Diagrama de Implantação UML

4+1 - Visão Física
❑ Exemplo

4+1 - Visão de Cenários
❑ Diagrama de casos de uso UML

Exercício
❑ Suponha que estamos em 2008, quando ainda não existia Spotify, e você
decidiu criar uma startup para oferecer um serviço de streaming de músicas
na Internet. Então, como primeiro passo, você implementou um MVP.
❑ Quais seriam as principais funcionalidades desse MVP?
❑ Desenhe as visões do 4+1 para o seu MVP.
Exemplo extraído de https://engsoftmoderna.info/cap3.html

C4 Model
Simon Brown, "The C4 model for visualising software architecture".
Disponível em www.c4model.com.

C4 Model
❑ Criada por Simon Brown
❑ Inspirado no 4+1 e na UML
❑ 4 visões principais
❑ Contexto
❑ Containers
❑ Componentes
❑ Código
❑ 3 visões complementares (opcionais)
❑ Landscape, Dynamic, Deployment
Simon Brown, "The C4 model for visualising software architecture". Disponível em www.c4model.com

C4 Model

C4 Model - Abstrações e orientações
❑ Caixas e setas (pode ter formas também)
❑ Todos os diagramas devem ter
❑ um título e
❑ uma legenda, explicando cada elemento
❑ Todos os elementos devem ter
❑ um tipo
❑ uma descrição breve das suas responsabilidades
❑ cada container e componente deve ter a sua tecnologia descrita
❑ Todos os relacionamentos devem
❑ ser unidirecionais
❑ ser rotulados de forma específica
❑ conter o protocolo de comunicação, se for entre containers

C4 Model - Contexto
❑ Pessoa
❑ Uma pessoa representa um dos usuários humanos do seu sistema de software (por
exemplo, atores, papéis, personas, etc.).
❑ Sistema de Software
❑ Um sistema de software é o mais alto nível de abstração e descreve algo que agrega
valor aos seus usuários, sejam eles humanos ou não. Isso inclui o sistema de
software que você está modelando e os outros sistemas de software dos quais seu
sistema de software depende (ou vice-versa).
❑

C4 Model - Contexto
https://c4model.com/:
"A System Context diagram is a
good starting point for diagramming
and documenting a software
system, allowing you to step back
and see the big picture. Draw a
diagram showing your system as a
box in the centre, surrounded by
its users and the other systems that
it interacts with."

C4 Model - Contexto
Título
Legenda

C4 Model - Containers
❑ Containers são as partes que integram o sistema que são
independentes e executam ou guardam dados.
❑ Aplicação web/mobile
❑ API
❑ Banco de dados

C4 Model - Containers - Diagrama Parte 1

C4 Model - Containers - Diagrama Parte 2

C4 Model - Containers
https://c4model.com/:"A "container" is something
like a server-side web application, single-page
application, desktop application, mobile app,
database schema, ﬁle system, etc. Essentially, a
container is a separately runnable/deployable unit
(e.g. a separate process space) that executes code
or stores data.
The Container diagram shows the high-level shape
of the software architecture and how
responsibilities are distributed across it. It also
shows the major technology choices and how the
containers communicate with one another. It's a
simple, high-level technology focussed diagram that
is useful for software developers and
support/operations staﬀ alike"

C4 Model - Componentes
❑ O diagrama de Componentes mostra como um container é composto por
um número de "componentes", o que cada um desses componentes é,
suas responsabilidades e os detalhes de tecnologia/implementação.
❑ Concern: organização do código-fonte em
❑ Submodulos
❑ Pacotes
❑ Componentes

C4 Model - Código
❑ Concerns: estrutura de código
❑ Como o sistema é implementado em código-fonte
❑ Diagramas UML (pacotes, componentes e classes)
❑ Só deve ser feito para partes realmente importantes ou complexas

Exercício
❑ Suponha que estamos em 2008, quando ainda não existia Spotify, e você
decidiu criar uma startup para oferecer um serviço de streaming de músicas
na Internet. Então, como primeiro passo, você implementou um MVP.
❑ Quais seriam as principais funcionalidades desse MVP?
❑ Desenhe as visões do C4 para o seu MVP.
Exemplo extraído de https://engsoftmoderna.info/cap3.html

Extras
❑ Ferramentas
❑ UML - Draw.io, PlantUML, Lucidchart
❑ C4 - Structurizr, PlantUML C4
❑ Papel e caneta

❑ Vejam a página oficial para ver várias explicações! Exemplo:
❑ Web applications; one container or two?
❑ If you're building a server-side web application (e.g. Spring MVC, ASP.NET, Ruby on
Rails, Django, etc) that is predominantly generating static HTML content, then that's a
single container. If there's a signiﬁcant quantity of JavaScript being delivered by the
server-side web application (e.g. a single-page application built using Angular), then
that's two containers. Here's an example.
❑ Although, at deployment time, the server-side web application includes both the
server-side and client-side code, treating the client and server as two separate
containers makes it explicit that these are two separate process spaces,
communicating via an inter-process/remote communication mechanism (e.g.
JSON/HTTPS). It also provides a basis for zooming in to each container separately to
show the components inside them.
Extras - dúvidas sobre modelagem com C4

Arquitetura_de_software_e_como_descreve-la_v2

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Arquitetura_de_software_e_como_descreve-la_v2

Semelhante a Arquitetura_de_software_e_como_descreve-la_v2 (20)

Mais de Diogo Soares Moreira

Mais de Diogo Soares Moreira (6)

Arquitetura_de_software_e_como_descreve-la_v2