SlideShare uma empresa Scribd logo
Documentação de
Arquitetura de
Software
Aplicando C4 Model
Douglas Alonso Cruz
Douglas Alonso Cruz
Arquiteto de Software / Lider de equipe na Modalgr
Consultor de TI atuando a mais de 20 anos no mercado nacional participando de grandes
projetos para grandes empresas.
Pós Graduado em Engenharia de Software – PUC SP
Graduado em Tecnologia e Desenvolvimento de Sistemas – IBTA SP
Diagrama de Sequência
Diagrama de Classes / Colaboração
O que você usa
para diagramas
de arquitetura?
Sendo otimista
1 a cada 10 pessoas usam UML
Diagrama de classes, objetos,
componentes, instalação, pacotes,
estrutura composta, perfil.
Definitivamente Engenheiros de Software não são artistas!!!
Qual a importância de bons diagramas de software?
Bons diagramas de arquitetura de software auxiliam na comunicação
(tanto dentro quanto fora da equipe de desenvolvimento de software/
produto), integração de nova equipe, equipes de sustentação e
suporte, identificação de riscos e ameaças.
Ajudam a alinhar o entendimento de todos sobre o software que está
sendo construído e tornando as equipes mais eficientes.
Mas então, o que é o C4 Model?
Com o uso dos Métodos ágeis a criação de documentação de sistemas
foi sendo deixada de lado e os diagramas complexos da UML também.
Pensando nisso o Arquiteto de Software Simon Brown criou um
combinado de métodos leves, unidos a linguagem gráfica para
representar arquitetura de software tanto para concepção quanto para
documentação;
O C4 Model foi criado por Simon Brown entre 2006 e 2011. Elaborado
com conceitos da base do UML e do Modelo arquitetural 4+1
Teve o lançamento oficial do Website e artigo publicado em 2018 e desde então
vem se popularizando.
https://c4model.com/
Simon Brown é consultor independente especializado em arquitetura de software e autor do livro
"Arquitetura de Software para Desenvolvedores" (Software Architecture for Developers).
O C4 Model é uma proposta para padronizar de forma coerente e eficiente a
representação da arquitetura de um software.
Os diagramas do C4 Model facilitam a comunicação entre todos os envolvidos no
projeto do software.
A construção dos diagramas conforme prescrito no C4 Model permite que você
consiga ter uma linguagem consistente, em quatro níveis de detalhe, conforme a
necessidade (e o stakeholder).
Para que serve o C4 Model?
Ao criar uma documentação precisamos entender que teremos
pessoas com diferentes interesses vendo aquela documentação
(arquiteto de software, desenvolvedores, time de operações,
testers, diretores, PO, gerentes de projeto, scrum masters, usuários,
patrocinadores, clientes, investidores, ...)
Mova-se rápido na mesma direção
que o seu time precisa
Boa comunicação é a chave do sucesso
Níveis do C4 Model.
O nome C4 vem dos quatro “níveis” de diagrama propostos pelo autor.
Contexto
contêiners
Componentes
Classes/Código
Software System
contêiner
Component
Code
C4 Model
Contexto
contêiners
Componentes
Classes/Código
Diagramas principais (Core diagrams)
Level 1 – System Context Diagram
O nível 1, um diagrama de contexto do sistema, mostra o sistema de
software que você está construindo e como ele se encaixa no mundo em
termos das pessoas que o utilizam e dos outros sistemas de software com
os quais ele interage.
• Escopo: O sistema de software em escopo;
• Elementos primários: Pessoas (users, personas, actors, etc), Sistemas
de software (dependências externas) que se conectam diretamente ao
sistema em escopo.
• Público alvo: Pessoas técnicas e não técnicas, dentro e fora da equipe
de desenvolvimento de Software.
Level 2 – contêiner Diagram
O nível 2, um diagrama de contêiner, amplia o sistema de software e
mostra os contêiners (aplicativos, armazenamentos de dados,
microservices, etc.) que compõem esse sistema de software. As decisões de
tecnologia também são uma parte fundamental desse diagrama.
• Escopo: um único sistema de software;
• Elementos primários: Pessoas e Sistemas de software (dependências
externas) que se conectam diretamente ao contêiner.
• Público alvo: Pessoas técnicas, dentro e fora da equipe de
desenvolvimento de Software, incluindo arquitetos, desenvolvedores e
time de operações e suporte.
Level 3 – Component Diagram
O nível 3, um diagrama de componentes, amplia um contêiner individual
para mostrar os componentes dentro dele. Esses componentes devem
mapear para abstrações reais (por exemplo, um agrupamento de código)
em sua base de código.
• Escopo: um único contêiner;
• Elementos primários: Componentes do contêiner em escopo;
• Público alvo: arquitetos e desenvolvedores.
contêiner que será
expandido no
diagrama de
componente
Level 4 – Class and Code
O nível 4, finalmente se você realmente quiser ou precisar, você pode
ampliar um componente individual para mostrar como esse componente é
implementado.
Especificamente o diagrama de nível 4, Simon Brown não encoraja o
arquiteto a criar este diagrama, uma vez que as IDEs modernas conseguem
gerar de forma automática de acordo com as classes do seu sistema.
• Escopo: um único componente;
• Elementos primários: Elementos de código (classes, interfaces,
objetos, funções, tabelas de banco de dados, etc) ligados ao
componente em escopo;
• Público alvo: arquitetos e desenvolvedores.
Considerações Importantes - Notações
A notação: o modelo c4 não prescreve nenhuma notação específica, e
o que você vê nesses diagramas apresentados é uma notação simples
que funciona bem em quadro brancos, papéis, notas adesivas e uma
variedade de ferramentas de diagramação.
É altamente recomendado que cada elemento inclua um nome, o tipo de elemento, uma
opção de tecnologia (se apropriado) e algum texto descritivo.
Pode parecer incomum incluir tanto texto em um diagrama, mas esse texto adicional elimina
Grande parte da ambiguidade vista em diagramas de arquitetura de software.
Considerações Importantes - Notações
Certifique-se de que você tenha uma chave/legenda para descrever qualquer notação que
esteja usando, mesmo que seja óbvio para você.
Chave legenda utilizada nos exemplos
E finalmente, não se esqueça do título do diagrama que deve aparecer em cada diagrama para descrever
Inequivocamente o tipo e o escopo de cada diagrama. Exemplo “Context Diagram of E-mail System”
Considerações Importantes - Notações
Diagramas Elementos Relacionamentos
Cada diagrama deve ter um título que
descreve o tipo e o escopo do diagrama
(por exemplo, "Diagrama de contexto
do sistema para Meu sistema de
software").
O tipo de cada elemento deve ser
especificado explicitamente (por
exemplo, Pessoa, Sistema de Software,
contêiner ou Componente).
Cada linha deve representar uma
relação unidirecional.
Cada diagrama deve ter uma chave /
legenda explicando a notação que está
sendo usada (por exemplo, formas,
cores, estilos de borda, tipos de linha,
pontas de seta, etc).
Cada elemento deve ter uma breve
descrição, para fornecer uma visão
"rápida" das principais
responsabilidades.
Cada linha deve ser rotulada, sendo a
etiqueta consistente com a direção e
intenção do relacionamento (por
exemplo, dependência ou fluxo de
dados).
Siglas e abreviações (negócios /
domínio ou tecnologia) devem ser
compreensíveis por todos os públicos
ou explicados na chave / legenda do
diagrama.
Cada contêiner e componente deve ter
uma tecnologia explicitamente
especificada.
Os relacionamentos entre os
contêineres (geralmente representam a
comunicação entre processos) devem
ter uma tecnologia / protocolo
explicitamente rotulado.
Diagramas Complementares
Até aqui foi demonstrado diagramas de um sistema simples, mas esse não é
o dia a dia das grandes corporações, o cenário é bem diferente, são muitos
sistemas, banco de dados, filas se comunicando dentro e fora das fronteiras
da empresa, como apresentar isso?
1) System Landscape diagram
Fica “No Topo” do C4, para mostrar o panorama do sistema de uma
perspectiva de TI, facilitando o entendimento das fronteiras do sistema
dentro da empresa.
É um mapa de alto nível dos sistemas de software a nível corporativo, com
um detalhamento C4 para cada sistema de interesse.
É um diagrama de contexto do sistema, sem foco especifico em um sistema
de software específico.
• Escopo: Uma empresa;
• Elementos primários: Pessoas e sistemas de software relacionados à
empresa em escopo;
• Público alvo: Pessoas técnicas e não técnicas, dentro e fora da equipe de
desenvolvimento de Software.
1) System Landscape diagram
A tendencia é que estes diagramas se tornem grandes, complexos e com muitos
relacionamentos, neste caso o ideal é criar vários diagramas, fatiando o contêiner.
2) Dynamic diagram
O Dynamic diagram pode ser útil para demonstrar como os elementos em
um modelo estático colaboram em tempo de execução para implementar
uma história de usuário, um caso de uso, um recurso etc.
É semelhante ao diagrama de sequência, porem permite um arranjo de
forma livre dos seus elementos com interações numeradas para indicar
ordem.
• Escopo: uma empresa, sistema de software ou contêiner;
• Elementos primários: Depende do escopo do diagrama (Landscape,
Leve 1,2,3);
• Público alvo: Pessoas técnicas e não técnicas, dentro e fora da equipe
de desenvolvimento de Software.
3) Deployment diagram
O diagram de implantação permite ilustrar como os sistemas de software e ou /contêineres
serão implantados na infraestrutura. Mostra o mapeamento entre os contêiners e nós de
implantação.
Um nó de implantação é algo como infraestrutura física (ex servidor, dispositivo físico),
infraestrutura virtualizada (IasS, PaaS, maquina virtual), infraestrutura em contêiner (Docker,
kubernetes), ambiente de execução (database, servidores web, servidor aplicativo). Os nós
podem estar aninhados
• Escopo: Um ou mais sistema de software;
• Elementos primários: Nós de deploy, instancias de sw e contêineres
• Público alvo: Pessoas técnicas, dentro e fora da equipe de
desenvolvimento de Software, incluindo arquitetos de software,
arquitetos de infra, desenvolvedores, time de operação e suporte
Ferramentas
Structurizr Archi Visio Sparx EA
MooD PlantUML Diagrams.net OmniGraffle
Algumas ferramentas para construção dos diagramas.
Atenção especial ao Structurizr
que permite criar diagramas
através de código utilizando
uma DSL DSL - Domain Specific Language?
Diagram as Code?
https://structurizr.com/help/code
Fica para uma próxima conversa!!!
Referências
https://c4model.com/
https://www.infoq.com/br/articles/C4-architecture-model/
https://www.eximiaco.tech/pt/2019/08/12/o-que-e-e-para-que-serve-o-c4-model/
Ebook - Software Architecture for Developers: Volumes 1 & 2
Open Agile Architecture™, a Standard of The Open Group
Agile Architecture Modeling using the ArchiMate® Language
www.modalgr.com.br
OBRIGADO
Douglas Alonso
douglas.alonso@modalgr.com.br
http://www.modalgr.com.br
Somos um time apaixonado por tecnologia e a entrega de
resultados é uma obsessão de nossos consultores.
A entrega de Resultados está no nosso DNA. Nosso Time
trabalha para atender os clientes, entregando o melhor
resultado, dentro do prazo e custo esperado.
Venha trabalhar na Modalgr
Temos Vagas
https://youtu.be/mUVzPBrAgqQ

Mais conteúdo relacionado

Mais procurados

Integração Contínua
Integração ContínuaIntegração Contínua
Integração Contínua
Jackson Veroneze
 
Tópicos Especiais em Engenharia de Software
Tópicos Especiais em Engenharia de SoftwareTópicos Especiais em Engenharia de Software
Tópicos Especiais em Engenharia de Software
Rogerio P C do Nascimento
 
Arquitetura de Software EXPLICADA
Arquitetura de Software EXPLICADAArquitetura de Software EXPLICADA
Arquitetura de Software EXPLICADA
Fábio Nogueira de Lucena
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
Mauricio Cesar Santos da Purificação
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
eros.viggiano
 
Apresentação fdd
Apresentação fddApresentação fdd
Apresentação fdd
Marlon Ribeiro
 
Padrões MVC
Padrões MVCPadrões MVC
Padrões MVC
Suzana Viana Mota
 
Arquitetura de Software Na Pratica
Arquitetura de Software Na PraticaArquitetura de Software Na Pratica
Arquitetura de Software Na Pratica
Alessandro Kieras
 
Projeto e Desenvolvimento de Software
Projeto e Desenvolvimento de SoftwareProjeto e Desenvolvimento de Software
Projeto e Desenvolvimento de Software
Aragon Vieira
 
POO - 16 - Polimorfismo
POO - 16 - PolimorfismoPOO - 16 - Polimorfismo
POO - 16 - Polimorfismo
Ludimila Monjardim Casagrande
 
Aula 2. frameworks js
Aula 2. frameworks jsAula 2. frameworks js
Aula 2. frameworks js
andreluizlc
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
Leinylson Fontinele
 
Design Patterns - Aula 1
Design Patterns - Aula 1Design Patterns - Aula 1
Design Patterns - Aula 1
Talita Pagani
 
Gestão de Serviços de TI com a ITIL. Uma introdução
Gestão de Serviços de TI com a ITIL. Uma introduçãoGestão de Serviços de TI com a ITIL. Uma introdução
Gestão de Serviços de TI com a ITIL. Uma introdução
Rildo (@rildosan) Santos
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
Nécio de Lima Veras
 
Aula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareAula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de Software
Cloves da Rocha
 
Análise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e JavaAnálise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e Java
armeniocardoso
 
Prototipagem
PrototipagemPrototipagem
Prototipagem
jwainer
 
O Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de SoftwareO Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de Software
Camilo de Melo
 
Modelagem de dados
Modelagem de dadosModelagem de dados
Modelagem de dados
Fabrício Lopes Sanchez
 

Mais procurados (20)

Integração Contínua
Integração ContínuaIntegração Contínua
Integração Contínua
 
Tópicos Especiais em Engenharia de Software
Tópicos Especiais em Engenharia de SoftwareTópicos Especiais em Engenharia de Software
Tópicos Especiais em Engenharia de Software
 
Arquitetura de Software EXPLICADA
Arquitetura de Software EXPLICADAArquitetura de Software EXPLICADA
Arquitetura de Software EXPLICADA
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Apresentação fdd
Apresentação fddApresentação fdd
Apresentação fdd
 
Padrões MVC
Padrões MVCPadrões MVC
Padrões MVC
 
Arquitetura de Software Na Pratica
Arquitetura de Software Na PraticaArquitetura de Software Na Pratica
Arquitetura de Software Na Pratica
 
Projeto e Desenvolvimento de Software
Projeto e Desenvolvimento de SoftwareProjeto e Desenvolvimento de Software
Projeto e Desenvolvimento de Software
 
POO - 16 - Polimorfismo
POO - 16 - PolimorfismoPOO - 16 - Polimorfismo
POO - 16 - Polimorfismo
 
Aula 2. frameworks js
Aula 2. frameworks jsAula 2. frameworks js
Aula 2. frameworks js
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
 
Design Patterns - Aula 1
Design Patterns - Aula 1Design Patterns - Aula 1
Design Patterns - Aula 1
 
Gestão de Serviços de TI com a ITIL. Uma introdução
Gestão de Serviços de TI com a ITIL. Uma introduçãoGestão de Serviços de TI com a ITIL. Uma introdução
Gestão de Serviços de TI com a ITIL. Uma introdução
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
 
Aula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareAula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de Software
 
Análise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e JavaAnálise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e Java
 
Prototipagem
PrototipagemPrototipagem
Prototipagem
 
O Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de SoftwareO Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de Software
 
Modelagem de dados
Modelagem de dadosModelagem de dados
Modelagem de dados
 

Semelhante a Documentação de Arquitetura de Software Aplicando o C4 Model

Visão Geral Arquiteturade Software
Visão Geral Arquiteturade SoftwareVisão Geral Arquiteturade Software
Visão Geral Arquiteturade Software
elliando dias
 
Do Diagrama de Fluxo de Dados ao Use Case
Do Diagrama de Fluxo de Dados ao Use CaseDo Diagrama de Fluxo de Dados ao Use Case
Do Diagrama de Fluxo de Dados ao Use Case
Robson Silva Espig
 
Amostra algoritmos funcionais-1
Amostra algoritmos funcionais-1Amostra algoritmos funcionais-1
Amostra algoritmos funcionais-1
Joao Carlos Drumond
 
Amostra algoritmos funcionais-1
Amostra algoritmos funcionais-1Amostra algoritmos funcionais-1
Amostra algoritmos funcionais-1
Joao Carlos Drumond
 
Aula Teste Fatec Engenharia de Software III
Aula Teste  Fatec Engenharia de Software IIIAula Teste  Fatec Engenharia de Software III
Aula Teste Fatec Engenharia de Software III
Dalton Martins
 
Esboços na arquitetura de software
Esboços na arquitetura de softwareEsboços na arquitetura de software
Esboços na arquitetura de software
Pedro Victor de Almeida Lopes
 
Openday PUC-RIO - Ferramenta gráfica para modelagem e análise em Engenharia E...
Openday PUC-RIO - Ferramenta gráfica para modelagem e análise em Engenharia E...Openday PUC-RIO - Ferramenta gráfica para modelagem e análise em Engenharia E...
Openday PUC-RIO - Ferramenta gráfica para modelagem e análise em Engenharia E...
Opencadd Advanced Technology
 
Dfd
DfdDfd
Aula modelagem de dados
Aula modelagem de dadosAula modelagem de dados
Aula modelagem de dados
Gabriel Moura
 
DDD – Domain Driven Design
DDD – Domain Driven DesignDDD – Domain Driven Design
DDD – Domain Driven Design
Ítalo Bandeira
 
Aula desesenvolvimento segunda semana
Aula desesenvolvimento segunda semanaAula desesenvolvimento segunda semana
Aula desesenvolvimento segunda semana
Gabriel Moura
 
Corbawebserves
CorbawebservesCorbawebserves
Corbawebserves
Portal_do_Estudante_SD
 
DDD
DDDDDD
6_TI2007-Desenv_SI_e_DFD_v2.5.pdf
6_TI2007-Desenv_SI_e_DFD_v2.5.pdf6_TI2007-Desenv_SI_e_DFD_v2.5.pdf
6_TI2007-Desenv_SI_e_DFD_v2.5.pdf
FChico2
 
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANEAPSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
Fco Edilson Nascimento
 
DDD e Microsservicos - do negócio à arquitetura
DDD e Microsservicos - do negócio à arquiteturaDDD e Microsservicos - do negócio à arquitetura
DDD e Microsservicos - do negócio à arquitetura
Graziella Bonizi
 
Zachman framework
Zachman frameworkZachman framework
Zachman framework
Joao Santos
 
diagrama de componentes
diagrama de componentesdiagrama de componentes
diagrama de componentes
elliando dias
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
elliando dias
 
Diagrama de implantação
Diagrama de implantaçãoDiagrama de implantação
Diagrama de implantação
elliando dias
 

Semelhante a Documentação de Arquitetura de Software Aplicando o C4 Model (20)

Visão Geral Arquiteturade Software
Visão Geral Arquiteturade SoftwareVisão Geral Arquiteturade Software
Visão Geral Arquiteturade Software
 
Do Diagrama de Fluxo de Dados ao Use Case
Do Diagrama de Fluxo de Dados ao Use CaseDo Diagrama de Fluxo de Dados ao Use Case
Do Diagrama de Fluxo de Dados ao Use Case
 
Amostra algoritmos funcionais-1
Amostra algoritmos funcionais-1Amostra algoritmos funcionais-1
Amostra algoritmos funcionais-1
 
Amostra algoritmos funcionais-1
Amostra algoritmos funcionais-1Amostra algoritmos funcionais-1
Amostra algoritmos funcionais-1
 
Aula Teste Fatec Engenharia de Software III
Aula Teste  Fatec Engenharia de Software IIIAula Teste  Fatec Engenharia de Software III
Aula Teste Fatec Engenharia de Software III
 
Esboços na arquitetura de software
Esboços na arquitetura de softwareEsboços na arquitetura de software
Esboços na arquitetura de software
 
Openday PUC-RIO - Ferramenta gráfica para modelagem e análise em Engenharia E...
Openday PUC-RIO - Ferramenta gráfica para modelagem e análise em Engenharia E...Openday PUC-RIO - Ferramenta gráfica para modelagem e análise em Engenharia E...
Openday PUC-RIO - Ferramenta gráfica para modelagem e análise em Engenharia E...
 
Dfd
DfdDfd
Dfd
 
Aula modelagem de dados
Aula modelagem de dadosAula modelagem de dados
Aula modelagem de dados
 
DDD – Domain Driven Design
DDD – Domain Driven DesignDDD – Domain Driven Design
DDD – Domain Driven Design
 
Aula desesenvolvimento segunda semana
Aula desesenvolvimento segunda semanaAula desesenvolvimento segunda semana
Aula desesenvolvimento segunda semana
 
Corbawebserves
CorbawebservesCorbawebserves
Corbawebserves
 
DDD
DDDDDD
DDD
 
6_TI2007-Desenv_SI_e_DFD_v2.5.pdf
6_TI2007-Desenv_SI_e_DFD_v2.5.pdf6_TI2007-Desenv_SI_e_DFD_v2.5.pdf
6_TI2007-Desenv_SI_e_DFD_v2.5.pdf
 
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANEAPSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
 
DDD e Microsservicos - do negócio à arquitetura
DDD e Microsservicos - do negócio à arquiteturaDDD e Microsservicos - do negócio à arquitetura
DDD e Microsservicos - do negócio à arquitetura
 
Zachman framework
Zachman frameworkZachman framework
Zachman framework
 
diagrama de componentes
diagrama de componentesdiagrama de componentes
diagrama de componentes
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Diagrama de implantação
Diagrama de implantaçãoDiagrama de implantação
Diagrama de implantação
 

Último

Como fui de 0 a lead na gringa em 3 anos.pptx
Como fui de 0 a lead na gringa em 3 anos.pptxComo fui de 0 a lead na gringa em 3 anos.pptx
Como fui de 0 a lead na gringa em 3 anos.pptx
tnrlucas
 
Orientações para utilizar Drone no espaço Brasil
Orientações para utilizar Drone no espaço BrasilOrientações para utilizar Drone no espaço Brasil
Orientações para utilizar Drone no espaço Brasil
EliakimArajo2
 
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Annelise Gripp
 
Teoria de redes de computadores redes .doc
Teoria de redes de computadores redes .docTeoria de redes de computadores redes .doc
Teoria de redes de computadores redes .doc
anpproferick
 
PRATICANDO O SCRUM Scrum team, product owner
PRATICANDO O SCRUM Scrum team, product ownerPRATICANDO O SCRUM Scrum team, product owner
PRATICANDO O SCRUM Scrum team, product owner
anpproferick
 
Por que escolhi o Flutter - Campus Party Piauí.pdf
Por que escolhi o Flutter - Campus Party Piauí.pdfPor que escolhi o Flutter - Campus Party Piauí.pdf
Por que escolhi o Flutter - Campus Party Piauí.pdf
Ian Oliveira
 
Gestão de dados: sua importância e benefícios
Gestão de dados: sua importância e benefíciosGestão de dados: sua importância e benefícios
Gestão de dados: sua importância e benefícios
Rafael Santos
 

Último (7)

Como fui de 0 a lead na gringa em 3 anos.pptx
Como fui de 0 a lead na gringa em 3 anos.pptxComo fui de 0 a lead na gringa em 3 anos.pptx
Como fui de 0 a lead na gringa em 3 anos.pptx
 
Orientações para utilizar Drone no espaço Brasil
Orientações para utilizar Drone no espaço BrasilOrientações para utilizar Drone no espaço Brasil
Orientações para utilizar Drone no espaço Brasil
 
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
 
Teoria de redes de computadores redes .doc
Teoria de redes de computadores redes .docTeoria de redes de computadores redes .doc
Teoria de redes de computadores redes .doc
 
PRATICANDO O SCRUM Scrum team, product owner
PRATICANDO O SCRUM Scrum team, product ownerPRATICANDO O SCRUM Scrum team, product owner
PRATICANDO O SCRUM Scrum team, product owner
 
Por que escolhi o Flutter - Campus Party Piauí.pdf
Por que escolhi o Flutter - Campus Party Piauí.pdfPor que escolhi o Flutter - Campus Party Piauí.pdf
Por que escolhi o Flutter - Campus Party Piauí.pdf
 
Gestão de dados: sua importância e benefícios
Gestão de dados: sua importância e benefíciosGestão de dados: sua importância e benefícios
Gestão de dados: sua importância e benefícios
 

Documentação de Arquitetura de Software Aplicando o C4 Model

  • 2. Douglas Alonso Cruz Arquiteto de Software / Lider de equipe na Modalgr Consultor de TI atuando a mais de 20 anos no mercado nacional participando de grandes projetos para grandes empresas. Pós Graduado em Engenharia de Software – PUC SP Graduado em Tecnologia e Desenvolvimento de Sistemas – IBTA SP
  • 3. Diagrama de Sequência Diagrama de Classes / Colaboração O que você usa para diagramas de arquitetura? Sendo otimista 1 a cada 10 pessoas usam UML Diagrama de classes, objetos, componentes, instalação, pacotes, estrutura composta, perfil.
  • 4. Definitivamente Engenheiros de Software não são artistas!!!
  • 5. Qual a importância de bons diagramas de software? Bons diagramas de arquitetura de software auxiliam na comunicação (tanto dentro quanto fora da equipe de desenvolvimento de software/ produto), integração de nova equipe, equipes de sustentação e suporte, identificação de riscos e ameaças. Ajudam a alinhar o entendimento de todos sobre o software que está sendo construído e tornando as equipes mais eficientes.
  • 6. Mas então, o que é o C4 Model? Com o uso dos Métodos ágeis a criação de documentação de sistemas foi sendo deixada de lado e os diagramas complexos da UML também. Pensando nisso o Arquiteto de Software Simon Brown criou um combinado de métodos leves, unidos a linguagem gráfica para representar arquitetura de software tanto para concepção quanto para documentação;
  • 7. O C4 Model foi criado por Simon Brown entre 2006 e 2011. Elaborado com conceitos da base do UML e do Modelo arquitetural 4+1 Teve o lançamento oficial do Website e artigo publicado em 2018 e desde então vem se popularizando. https://c4model.com/ Simon Brown é consultor independente especializado em arquitetura de software e autor do livro "Arquitetura de Software para Desenvolvedores" (Software Architecture for Developers).
  • 8. O C4 Model é uma proposta para padronizar de forma coerente e eficiente a representação da arquitetura de um software. Os diagramas do C4 Model facilitam a comunicação entre todos os envolvidos no projeto do software. A construção dos diagramas conforme prescrito no C4 Model permite que você consiga ter uma linguagem consistente, em quatro níveis de detalhe, conforme a necessidade (e o stakeholder). Para que serve o C4 Model?
  • 9. Ao criar uma documentação precisamos entender que teremos pessoas com diferentes interesses vendo aquela documentação (arquiteto de software, desenvolvedores, time de operações, testers, diretores, PO, gerentes de projeto, scrum masters, usuários, patrocinadores, clientes, investidores, ...)
  • 10. Mova-se rápido na mesma direção que o seu time precisa Boa comunicação é a chave do sucesso
  • 11. Níveis do C4 Model. O nome C4 vem dos quatro “níveis” de diagrama propostos pelo autor. Contexto contêiners Componentes Classes/Código
  • 13.
  • 14. Level 1 – System Context Diagram O nível 1, um diagrama de contexto do sistema, mostra o sistema de software que você está construindo e como ele se encaixa no mundo em termos das pessoas que o utilizam e dos outros sistemas de software com os quais ele interage. • Escopo: O sistema de software em escopo; • Elementos primários: Pessoas (users, personas, actors, etc), Sistemas de software (dependências externas) que se conectam diretamente ao sistema em escopo. • Público alvo: Pessoas técnicas e não técnicas, dentro e fora da equipe de desenvolvimento de Software.
  • 15.
  • 16. Level 2 – contêiner Diagram O nível 2, um diagrama de contêiner, amplia o sistema de software e mostra os contêiners (aplicativos, armazenamentos de dados, microservices, etc.) que compõem esse sistema de software. As decisões de tecnologia também são uma parte fundamental desse diagrama. • Escopo: um único sistema de software; • Elementos primários: Pessoas e Sistemas de software (dependências externas) que se conectam diretamente ao contêiner. • Público alvo: Pessoas técnicas, dentro e fora da equipe de desenvolvimento de Software, incluindo arquitetos, desenvolvedores e time de operações e suporte.
  • 17.
  • 18. Level 3 – Component Diagram O nível 3, um diagrama de componentes, amplia um contêiner individual para mostrar os componentes dentro dele. Esses componentes devem mapear para abstrações reais (por exemplo, um agrupamento de código) em sua base de código. • Escopo: um único contêiner; • Elementos primários: Componentes do contêiner em escopo; • Público alvo: arquitetos e desenvolvedores.
  • 19. contêiner que será expandido no diagrama de componente
  • 20.
  • 21. Level 4 – Class and Code O nível 4, finalmente se você realmente quiser ou precisar, você pode ampliar um componente individual para mostrar como esse componente é implementado. Especificamente o diagrama de nível 4, Simon Brown não encoraja o arquiteto a criar este diagrama, uma vez que as IDEs modernas conseguem gerar de forma automática de acordo com as classes do seu sistema. • Escopo: um único componente; • Elementos primários: Elementos de código (classes, interfaces, objetos, funções, tabelas de banco de dados, etc) ligados ao componente em escopo; • Público alvo: arquitetos e desenvolvedores.
  • 22.
  • 23. Considerações Importantes - Notações A notação: o modelo c4 não prescreve nenhuma notação específica, e o que você vê nesses diagramas apresentados é uma notação simples que funciona bem em quadro brancos, papéis, notas adesivas e uma variedade de ferramentas de diagramação. É altamente recomendado que cada elemento inclua um nome, o tipo de elemento, uma opção de tecnologia (se apropriado) e algum texto descritivo. Pode parecer incomum incluir tanto texto em um diagrama, mas esse texto adicional elimina Grande parte da ambiguidade vista em diagramas de arquitetura de software.
  • 24. Considerações Importantes - Notações Certifique-se de que você tenha uma chave/legenda para descrever qualquer notação que esteja usando, mesmo que seja óbvio para você. Chave legenda utilizada nos exemplos E finalmente, não se esqueça do título do diagrama que deve aparecer em cada diagrama para descrever Inequivocamente o tipo e o escopo de cada diagrama. Exemplo “Context Diagram of E-mail System”
  • 25. Considerações Importantes - Notações Diagramas Elementos Relacionamentos Cada diagrama deve ter um título que descreve o tipo e o escopo do diagrama (por exemplo, "Diagrama de contexto do sistema para Meu sistema de software"). O tipo de cada elemento deve ser especificado explicitamente (por exemplo, Pessoa, Sistema de Software, contêiner ou Componente). Cada linha deve representar uma relação unidirecional. Cada diagrama deve ter uma chave / legenda explicando a notação que está sendo usada (por exemplo, formas, cores, estilos de borda, tipos de linha, pontas de seta, etc). Cada elemento deve ter uma breve descrição, para fornecer uma visão "rápida" das principais responsabilidades. Cada linha deve ser rotulada, sendo a etiqueta consistente com a direção e intenção do relacionamento (por exemplo, dependência ou fluxo de dados). Siglas e abreviações (negócios / domínio ou tecnologia) devem ser compreensíveis por todos os públicos ou explicados na chave / legenda do diagrama. Cada contêiner e componente deve ter uma tecnologia explicitamente especificada. Os relacionamentos entre os contêineres (geralmente representam a comunicação entre processos) devem ter uma tecnologia / protocolo explicitamente rotulado.
  • 26. Diagramas Complementares Até aqui foi demonstrado diagramas de um sistema simples, mas esse não é o dia a dia das grandes corporações, o cenário é bem diferente, são muitos sistemas, banco de dados, filas se comunicando dentro e fora das fronteiras da empresa, como apresentar isso?
  • 27. 1) System Landscape diagram Fica “No Topo” do C4, para mostrar o panorama do sistema de uma perspectiva de TI, facilitando o entendimento das fronteiras do sistema dentro da empresa. É um mapa de alto nível dos sistemas de software a nível corporativo, com um detalhamento C4 para cada sistema de interesse. É um diagrama de contexto do sistema, sem foco especifico em um sistema de software específico. • Escopo: Uma empresa; • Elementos primários: Pessoas e sistemas de software relacionados à empresa em escopo; • Público alvo: Pessoas técnicas e não técnicas, dentro e fora da equipe de desenvolvimento de Software.
  • 28.
  • 29. 1) System Landscape diagram A tendencia é que estes diagramas se tornem grandes, complexos e com muitos relacionamentos, neste caso o ideal é criar vários diagramas, fatiando o contêiner.
  • 30.
  • 31.
  • 32. 2) Dynamic diagram O Dynamic diagram pode ser útil para demonstrar como os elementos em um modelo estático colaboram em tempo de execução para implementar uma história de usuário, um caso de uso, um recurso etc. É semelhante ao diagrama de sequência, porem permite um arranjo de forma livre dos seus elementos com interações numeradas para indicar ordem. • Escopo: uma empresa, sistema de software ou contêiner; • Elementos primários: Depende do escopo do diagrama (Landscape, Leve 1,2,3); • Público alvo: Pessoas técnicas e não técnicas, dentro e fora da equipe de desenvolvimento de Software.
  • 33.
  • 34. 3) Deployment diagram O diagram de implantação permite ilustrar como os sistemas de software e ou /contêineres serão implantados na infraestrutura. Mostra o mapeamento entre os contêiners e nós de implantação. Um nó de implantação é algo como infraestrutura física (ex servidor, dispositivo físico), infraestrutura virtualizada (IasS, PaaS, maquina virtual), infraestrutura em contêiner (Docker, kubernetes), ambiente de execução (database, servidores web, servidor aplicativo). Os nós podem estar aninhados • Escopo: Um ou mais sistema de software; • Elementos primários: Nós de deploy, instancias de sw e contêineres • Público alvo: Pessoas técnicas, dentro e fora da equipe de desenvolvimento de Software, incluindo arquitetos de software, arquitetos de infra, desenvolvedores, time de operação e suporte
  • 35.
  • 36. Ferramentas Structurizr Archi Visio Sparx EA MooD PlantUML Diagrams.net OmniGraffle Algumas ferramentas para construção dos diagramas. Atenção especial ao Structurizr que permite criar diagramas através de código utilizando uma DSL DSL - Domain Specific Language? Diagram as Code? https://structurizr.com/help/code Fica para uma próxima conversa!!!
  • 37. Referências https://c4model.com/ https://www.infoq.com/br/articles/C4-architecture-model/ https://www.eximiaco.tech/pt/2019/08/12/o-que-e-e-para-que-serve-o-c4-model/ Ebook - Software Architecture for Developers: Volumes 1 & 2 Open Agile Architecture™, a Standard of The Open Group Agile Architecture Modeling using the ArchiMate® Language www.modalgr.com.br
  • 39. Somos um time apaixonado por tecnologia e a entrega de resultados é uma obsessão de nossos consultores. A entrega de Resultados está no nosso DNA. Nosso Time trabalha para atender os clientes, entregando o melhor resultado, dentro do prazo e custo esperado. Venha trabalhar na Modalgr Temos Vagas https://youtu.be/mUVzPBrAgqQ