Um produto de software possui diversas características como: design, interação do usuário, persistência de dados, integração com outros softwares, estrutura de servidores e muitas outras. Normalmente é difícil saber como apresentar um software para os stakeholders de forma clara, a ponto dele entender como cada uma dessas características estará presente em um determinado produto.

Um dos desafios da engenharia de software está em justamente explicar um produto de software para os seus interessados. Por isso é comum, no ambiente acadêmico dos profissionais dessa área, uma análise comparativa com a engenharia civil.

A “maquete” da engenharia de software

Enquanto na engenharia civil você pode contar com plantas e maquetes para apresentar para qualquer pessoa como será uma casa que ainda não foi construída, na engenharia de software você conta com dezenas de diagramas e documentações que muitas vezes são abstratos demais para serem compreendidos por aqueles que não estão familiarizados.

Outra dificuldade encontrada na hora de documentar um software está na sua natureza dinâmica. Diferente de um prédio que, uma vez construído e entregue e dificilmente terá sua estrutura modificada, um software continua em constante atualização e manutenção mesmo após sua primeira entrega aos usuários.

Dessa forma, uma documentação extensa e com muitos diagramas complexos pode facilmente ficar desatualizada devido à dificuldade e ao custo de tempo e dinheiro para garantir sua manutenção.

Então como apresentar um software ao cliente?

Nesse cenário surge o modelo C4 que, embora não seja uma resposta definitiva para o problema mencionado, ajuda a simplificar a forma como algumas das características do software podem ser apresentadas.

Esse modelo consiste em um conjunto de quatro diagramas: contexto; containers; componentes e código. E é daí que vem o seu nome, C4.

Os diagramas do modelo C4

A principal ideia do modelo é ser capaz de olhar para o software como se fosse um mapa. Cada diagrama do modelo, começando com o de contexto até o de código, apresenta uma aproximação do leitor com o mapa do software.

Fazendo uma analogia com mapas cartográficos, enquanto o diagrama de contexto pode ser comparado a uma visão de países, o diagrama de código poderia ser comparado com uma visão de ruas e casas. Entre essas duas visões existem as de estados e cidades que fazem paralelo com os diagramas de containers e de componentes.

Uma vez que o modelo dispõe de somente quatro diagramas e devido à facilidade de compreensão dos mesmos, é bem provável que sua manutenção se torne bem mais fácil. Isso ajuda a manter uma documentação mínima de uma solução de software que estará disponível sempre que uma apresentação for necessária ou que algum membro do time de desenvolvimento tenha alguma dúvida.

Entendendo os diagramas

Cada um dos diagramas também objetiva apresentar o software para públicos específicos. Se o diagrama de contexto, é suficiente para apresentar aos diretores de uma empresa quais os sistemas envolvidos em uma solução de software, o mesmo pode não ser suficiente para demonstrar aos arquitetos de software quais os containers e componentes de cada sistema.

De acordo com isto, vamos destacar a seguir o que se trata cada um dos diagramas.

O diagrama de contexto

Aqui é apresentada uma visão geral dos sistemas e personas (perfis de usuários) envolvidos em uma solução ou produto de software. Este diagrama mostra também as relações entre esses elementos.

O diagrama de container

Esse diagrama tem como objetivo dar mais detalhes dos sistemas apresentados no diagrama de contexto. Aqui são apresentados os containers que compõem um sistema de softwares e como eles se relacionam.

O diagrama de componente

Assim como o diagrama de container, representa o detalhamento de um dos sistemas apresentados no diagrama de contexto, o diagrama de componente tem como objetivo adentrar em um container e demonstrar quais elementos fazem parte dele.

O diagrama de código

Neste ponto, o nível de mais detalhes do modelo, temos um diagrama similar ao diagrama de classes do modelo UML. Contudo, não é necessário aqui que as definições das classes de código tenham tantos detalhes quanto o diagrama da UML. O mais importante é apresentar quais as classes de um componente e como será o relacionamento entre elas.

Outros diagramas

Embora o cerne do modelo se concentre nos quatro diagramas supracitados, o modelo permite ser estendido caso necessário.

Uma visão extra que pode ser útil para profissionais que serão responsáveis por manter a infraestrutura de um produto de software é a do diagrama de implantação. Este diagrama também se baseia um diagrama da UML e, diferente de outros diagramas do modelo C4 ele apresenta um outro ponto de vista que indica quais os componentes de hardware ou da nuvem executarão o software.

Assim como o diagrama de implantação, existem outros que podem ser úteis em situações específicas ou para públicos específicos a quem pode interessar um produto de software.

Modelo C4 é um método eficaz

Ainda que não exista uma solução definitiva para documentar ou dar uma visão de como um software ficará, os diagramas do modelo C4 apresentam uma forma simples de fazer isso.

Os diagramas deste modelo podem ser bastante úteis em apresentações para clientes, diretores e até para outros profissionais técnicos ou membros novos de uma equipe de desenvolvimento que precisam conhecer quais as características dos softwares que irão se manter.

E aí? Você que trabalha com desenvolvimento de softwares e sistemas, gostou deste artigo? Deixe suas sugestões de conteúdos nos comentários. Vou adorar escrever mais por aqui.