C4 model permite representar un sistema de software con un conjunto de diagramas que describen cada uno, en profundidad, un nivel diferente de detalle, orientado a un público objetivo específico.
Diagramas de arquitectura con C4 model.
0. Índice de contenidos.
- 1. Introducción.
- 2. Entorno.
- 3. Diagramas de contexto.
- 4. Diagramas de contenedores.
- 5. Diagramas de componentes.
- 6. Diagramas de código.
- 7. Otros diagramas.
- 8. Referencias.
- 9. Conclusiones.
1. Introducción.
C4 model permite representar un sistema de software con un conjunto de diagramas que describen cada uno, en profundidad, un nivel diferente de detalle. Estos distintos niveles ayudan a comunicar ideas abstractas de forma visual y desde distintos puntos de vista, de tal modo que las personas implicadas o interesadas pueden ampliar y explorar los detalles de las partes que más les interesen.
En C4, cada «C» representa un tipo distinto de modelo con un nivel de detalle diferente:
- contexto
- contenedores
- componentes
- código
Podríamos decir que C4 model es una forma de crear mapas de tu código, con distintos niveles de detalle, de la misma manera que utilizarías algo como Google Maps para acercarte o alejarte de una zona que te interese.
C4 model fue creado por el arquitecto de software Simon Brown entre 2006 y 2011
sobre la base de UML y el modelo de vistas de arquitectura 4 + 1.
Recientemente Simon ha creado structurizr, una herramienta para generar diagramas como código que permite automatizar la generación, en base a un modelo único de componentes, contenedores y sistemas, junto con sus relaciones, todos los niveles de diagramas de C4
de manera automática.
El este tutorial nos centraremos en el modelo C4 en sí y veremos más adelante, en otros tutoriales, la posibilidad de generar los diagramas de C4 model cómo código usando distintas herramientas. En principio, el propio modelo no impone una notación específica, si recomienda que sea coherente entre todos los tipos de diagramas que generemos, pero podríamos utilizar la nuestra propia con cualquier herramienta genérica de diagramado; no impone una en concreto.
2. Entorno.
El tutorial está escrito usando el siguiente entorno:
- Hardware: Portátil MacBook Pro 16′ (Apple M1 Pro, 32GB DDR4).
- Sistema Operativo: Mac OS Ventura 13
3. Diagramas de contexto
Los diagramas de contexto ofrecen al público en general una vista global de todo el sistema. Los detalles internos del funcionamiento del mismo
y las tecnologías no son importantes ahora. Estos diagramas deben ser una descripción general del sistema: qué hace, quién lo utiliza
y con qué otros sistemas interactúan.
Estos diagramas son buenos para compartirlos con audiencias no técnicas porque pueden ayudar al público en general a comprender el alcance del proyecto, quiénes son los usuarios e incluso verse reflejados en el diagrama.
Para crear un diagrama de contexto podemos usar una primera caja, para representar el sistema en el centro. Alrededor de este sistema central, podemos usar formas sencillas para representar a las personas (usuarios, clientes, actores, roles,…) y otros cajas para representar sistemas que interactúan con él; por último debemos añadir también las relaciones entre ellos.
4. Diagramas de contenedores.
Una vez que entendemos cómo encaja nuestro sistema en el entorno de sistemas de información en general, el siguiente paso es ampliar los límites del sistema con un diagrama de contenedores. Un «contenedor» puede ser una aplicación web del lado del servidor, una aplicación del lado del cliente, una aplicación de escritorio, una aplicación móvil, una base de datos, una aplicación del lado del servidor, un sistema de archivos, etc. Es muy importante entender que cuando hablamos de contenedores no estamos hablando de un contenedor Docker, en nuestro diagrama un contenedor representa una aplicación o un almacén de datos. Algo que se despliega de manera independiente.
El diagrama de contenedores muestra a alto nivel la arquitectura de software y cómo se distribuyen las responsabilidades entre los distintos componentes (contenedores de información o ejecutores de código).
También muestra la tecnología y cómo se comunican los contenedores entre sí. Se trata de un diagrama sencillo, centrado en la tecnología de alto nivel, que resulta útil tanto para los desarrolladores de software como para el personal de soporte y operaciones.
Este diagrama va dirigido pues a personal técnico dentro y fuera del equipo de desarrollo de software; incluidos arquitectos de software, desarrolladores y personal de operaciones/soporte.
5. Diagramas de componentes.
A continuación, se puede ampliar y descomponer aún más cada contenedor para identificar los principales componentes estructurales y sus interacciones a través de diagramas de componentes.
El diagrama de componentes muestra cómo un contenedor está formado por una serie de componentes, cuáles son cada uno de ellos, sus responsabilidades y los detalles de tecnología/implementación. Un punto importante a tener en cuenta aquí es que todos los componentes dentro de un contenedor normalmente se ejecutan en el mismo espacio de proceso. En C4 model, los componentes no son unidades desplegables por separado.
Este diagrama va dirigido a Arquitectos y desarrolladores de software y no está recomendado para la mayoría de los equipos, la recomendación es que sólo generemos diagramas de componentes si añaden valor, y tenemso que considera la posibilidad de automatizar su creación para generar este nivel de documentación de manera automática.
6. Diagramas de código.
Por último, puedes hacer zoom en cada componente para mostrar cómo se implementa como código; utilizando diagramas de clases UML, diagramas de relación de entidades o similares.
Se trata de un nivel de detalle opcional que suele estar disponible en cualquier herramienta de desarrollo. Lo ideal sería que este diagrama se generara automáticamente mediante dichas herramientas y debería considerar mostrar sólo aquellos atributos y métodos que le permitan contar la historia que desea contar. No se recomienda este nivel de detalle salvo para los componentes más importantes o complejos.
7. Otros diagramas.
C4 model ha ido incluyendo otros tipos de diagramas, como los siguientes:
7.1. Esquema general del sistema.
Desde un punto de vista práctico, un diagrama de esquema general del sistema (system landscape diagram) no es más que un diagrama del contexto del sistema sin un enfoque específico en un sistema de software concreto. Si tienes más de un sistema de software permite representarlos todos.
Básicamente, se trata de un mapa de los sistemas de software dentro del ámbito elegido, con un desglose C4 para cada sistema de software de interés.
Este diagrama va dirigido al mismo público objetivo que el diagrama de contexto de sistemas.
7.2. Diagrama dinámico.
Un diagrama dinámico puede ser útil cuando se desea mostrar cómo los elementos del modelo estático colaboran en tiempo de ejecución para implementar una historia de usuario o un caso de uso.
Este diagrama dinámico se basa en un diagrama de comunicación UML (anteriormente conocido como «diagrama de colaboración UML»).
Es similar a un diagrama de secuencia UML, aunque permite una disposición libre de los elementos del diagrama con interacciones numeradas para indicar el orden.
Podemos usar en el diagrama los tres primeros niveles: contexto, contenedores o componentes, dependiendo del nivel de profundidad que queramos usar para contar la interacción entre los mismos.
Este diagrama va dirigido al mismo público objetivo que el diagrama de contexto, contenedores o componentes.
7.3. Diagrama de despliegue.
Un diagrama de despliegue permite ilustrar cómo se despliegan instancias de sistemas de software y/o contenedores en el modelo estático en la infraestructura dentro de un entorno de despliegue determinado (por ejemplo, producción, preproducción, integración, desarrollo, etc.). Se basa en un diagrama de despliegue UML.
Un nodo de despliegue representa dónde se ejecuta una instancia de un sistema/contenedor de software; puede ser una infraestructura física, una infraestructura virtualizada, una infraestructura en contenedores, un entorno de ejecución (por ejemplo, un servidor de base de datos, un servidor web/aplicación Java EE, Microsoft IIS), etc.
Los nodos de despliegue pueden anidarse.
También puede incluir nodos de infraestructura como servicios DNS, balanceadores de carga, cortafuegos, etc.
Este diagrama va dirigido al personal técnico dentro y fuera del equipo de desarrollo de software; incluidos arquitectos de software, desarrolladores, arquitectos de infraestructura
y personal de operaciones/soporte.
8. Referencias.
- https://c4model.com/
- https://www.lucidchart.com/blog/c4-model
- https://structurizr.com/help/system-landscape-diagram
- https://structurizr.com/help/system-context-diagram
- https://structurizr.com/help/container-diagram
- https://structurizr.com/help/component-diagram
- https://structurizr.com/help/deployment-diagram
9. Conclusiones.
En este tutorial hemos hecho una breve introducción a C4 model para la generación de diagramas de arqutiectura de nuestros sistemas de información a distintos niveles de profundidad y detalle.
En próximos tutoriales veremos la posibilidad de generar esos diagramas como código, en vez de usar herramientas genéricas de diagramado.
Stay tuned!
