O documento discute a importância da visualização e dos esboços na arquitetura de software, enfatizando que a criação de sketches permite uma melhor comunicação entre as equipes de desenvolvimento e a compreensão das ideias do arquiteto. Além disso, apresenta diferentes formas de materializar informações, destacando diagramas de contexto, containers e componentes como ferramentas úteis para representar a estrutura de sistemas. O texto sugere que esboços são uma alternativa eficaz à formalidade do UML, ressaltando a necessidade de abstrair e compartilhar visualmente as ideias dentro da equipe.

1. Sketches
Esboços eficazes na
arquitetura de
software
Colaboradores:
● Gabriel Barbosa
● Igor Queiroz
● João Henrique
● Lucas Vinicios
● Pedro Victor
● Vinicius Carvalho

2. Arquitetura
● Sistemas grandes são sempre decompostos em subsistemas que
fornecem algum conjunto de serviços relacionados. (Sommerville –
Eng. de Software 8 edição .).
● A arquitetura de software de um sistema consiste na definição de
software, suas propriedades externas, e seus relacionamentos com
outros softwares. (Wikipédia)
2

3. 3
Fonte: http://www.institutopangea.org/blog/15-a-importancia-da-arquitetura-de-software

4. 4
Fonte: http://www.powerlogic.com.br/powerportal/site.do?
evento=portlet&pIdPlc=ecpTaxonomiaMenuPortal&app=site&tax=10223&lang=pt_br&pg=2&taxp=0&

5. Visualização de ideias
● Visto o contexto da arquitetura no mundo dos softwares,
podemos perceber a importância da visualização dentro
dela.
● Surgem então formas de se materializar essas ideias em
algo visual para o entendimento do resto da equipe.
5

6. Visualização de ideias
● Dentre as principais formas de “materialização” das informações, está
presente entre elas o UML, conhecidos (ou deveria ser) por todos, mas que
somente poucos dominam.
○ Ferramenta complexa;
○ Leva, geralmente, muito tempo para transpor as ideias para as regras
do uml;
○ Algumas vezes não há entendimento completo da ideia pela equipe, e
muito menos do cliente!!
6

7. 7
Fonte: http://static.codingthearchitecture.com/presentations/yowsydney2014-software-architecture-sketches.pdf

8. Visualização de ideias
● Dificuldade de se transformar ideias em algo visível
○ diagramas raramente fazem sentido, ou fazem só pra quem os criou;
○ muitos desenvolvedores, assim como membros da equipe, podem achar que diagramas uml
são irrelevantes.
● O código poderia ser então a própria arquitetura?
○ Com o abandono do UML, estão perdendo a capacidade de comunicarem visualmente,
resultando em retrabalho (software caro).
8

9. Esboços efetivos
● Surgiram, então, métodos efetivos que levam em consideração a criação de
uma arquitetura de software de maneira a fugir de toda a formalidade e
burocracia do uml.
● Desta forma, a equipe de desenvolvimento consegue entender melhor o que
se passa “na cabeça” do arquiteto de software, aumentando a compreensão
e diminuindo o retrabalho.
9

10. Esboços efetivos
10Fonte: https://www.flickr.com/photos/codingthearchitecture/sets/72157632939643234

11. Esboços efetivos
● Diversas são as formas utilizadas para conseguir uma
melhor abstração de ideias:
○ Uso de papéis coloridos;
○ Cartazes pregados nas paredes do ambiente de desenvolvimento;
○ Linguagens e figuras informais e descontraídas (porém ambas com
objetivos)
○ E muitas outras formas criativas e úteis.
11

12. Esboços efetivos
12Fonte: https://www.flickr.com/photos/codingthearchitecture/sets/72157632939643234

13. Esboços efetivos
13Fonte: https://www.flickr.com/photos/codingthearchitecture/sets/72157632939643234

14. Esboços efetivos
14
Fonte: https://www.flickr.com/photos/codingthearchitecture/sets/72157632939643234

15. Diagramas
● Iremos citar 3 diagramas;
○ Contexto;
○ Container;
○ Componente;
● Estes diagramas só cobrem a estrutura estática (tempo de execução,
infraestrutura, desenvolvimento, etc também são importantes).
15

16. Diagrama de Contexto
● Um diagrama de contexto pode ser um ponto de partida útil para
diagramação e documentação de um sistema de software.
● Permite voltar atrás e olhar para o panorama geral.
● Como fazer?
○ Desenhe um diagrama de blocos simples, mostrando o seu sistema como uma caixa no
centro.
○ Ao redor e ligados à caixa central:
■ Usuários do sistema
■ Outros sistemas que interaja com ele
16

17. Diagrama de Contexto
● O que estamos construindo?
● Quem usa o que? (usuários, atores, papéis, pessoas, etc)
● Como é que se encaixam no ambiente de TI?
17

18. Diagrama de Contexto
● Exemplo:
18Fonte: http://www.infoarena.com.br/arena/images/arenas/programacao/programacao-001.jpg

19. Diagrama de Containers
● "Container" = servidor web, servidor de aplicação, aplicação desktop, app
móvel, banco de dados, sistema de arquivos, etc.
● Aplicando um zoom sobre o sistema de software, um diagrama de
containers mostra os vários “containers” e como eles interagem para
formar o sistema global de software.
● Integração representada por meio de:
○ Arquivos de projeto IDE
○ Scripts de construção
○ Provisionamento(replicação) de infraestrutura e scripts de implantação
19

20. Diagrama de Containers
● Quais são as decisões de tecnologia de alto nível?
● Como que os containers se comunicam uns com os outros?
● Como um desenvolvedor, por onde eu preciso escrever código?
20

21. Diagrama de Containers
● Exemplo:
21
Fonte: http://www.methodsandtools.
com/archive/softwarearchitecturesketches
.php

22. Diagrama de Componentes
● Esse diagrama tem como objetivo mostrar os maiores componentes
lógicos do Sistema e como eles interagem entre si.
● A divisão dos componentes é única para cada sistema e varia de acordo
com o arquiteto também.
● Geralmente, os sistemas são divididos em: Componentes, Serviços,
Módulos, Subsistemas, Camadas, Fluxo de Trabalho.
22

23. Diagrama de Componentes
● Quais componentes/serviços compõem o sistema?
● Está claro como o sistema funciona em um alto nível?
● Será que todos os componentes têm uma “casa” (um container)?
23

24. Diagrama de
Componentes
24
Fonte: http://www.methodsandtools.
com/archive/softwarearchitecturesketches.php

25. 25Fonte: http://cdn.infoq.com/statics_s1_20150424-0221/resource/articles/agile-software-architecture-sketches-NoUML/en/resources/2big.png

26. Como elaborar um bom Sketche.
Dicas sobre como aplicar melhor os Sketches e torna-los mais efetivos :
● Títulos curtos e auto-explicativos.
● Utilize bordas(fronteiras) para separar grupo de itens relacionados
● Esclareça as formas, linhas, cores e bordas(fronteiras) usadas.
● Adicione responsabilidades as caixas criadas.
● Utilize papel de lembrete ao invés de desenhar caixas.
26

27. Mas… que padrão seguir?
● Sketches não é sobre seguir padrões e métodos, mas dar diferentes opções
sobre ideias organizacionais.
● Pense sobre qual o público alvo que deseja atingir e faça o funcionar.
● Faça os entender a motivação do software estar sendo construído.
● Utilize sketche se você procura uma boa comunicação com sua equipe ou
clientes.
27

28. Abstração
● Para criar um sketche é necessário reduzir o detalhamento do sistema.
● É preciso que este reflita, de forma abstrata, o que você pensa sobre o que
esta sendo desenvolvido.
28

29. Compartilhando Sketches
● É de grande importância que Sketches sejam compartilhados para a equipe.
● Deixe Sketches nas paredes, para que todos possam compartilhar o mesmo
conhecimento da estrutura do problema, como você tem.
29

30. Considerações Finais sobre SketchesFinais
●
● UML x Sketches
● Vantagens dos Sketches
● Recomendável?
30
Fonte: http://www.pesquisaitaliana.com.br/wp-content/uploads/2015/09/considera%C3%A7%C3%B5es-cidadania-1024x593.jpg

31. Referências
● http://www.codingthearchitecture.com/presentations/saturn2013-effective-
software-architecture-sketches
● https://www.infoq.com/articles/agile-software-architecture-sketches-
NoUML
● https://dzone.com/articles/simple-sketches-diagramming
● https://pt.wikipedia.org/wiki/Arquitetura_de_software
● Livros Engenharia de Software - 8ª Edição 2007 - Ian Sommerville
31