El modelo C4

El modelo C4 de documentación en Arquitectura de Software

Cuando se diseña y se documenta la arquitectura de un Sistema Software es común utilizar distintos tipos de diagramas como artefacto visual de comunicación y documentación.

En este uso de diagramas se dan 2 escenarios típicos:

  • El caso más común, en el que se utilizan diagramas informales basados en cajas, líneas, flechas, etc… y se realizan ad-hoc, en el momento en el que se necesitan. No se acogen a ningún estándar.
Diagrama de arquitectura realizaddo ad-hoc
  • Utilización de algún estándar, típicamente UML, para documentar el Sistema:
UML, o el Lenguaje Unificado de Modelado, como artefacto para documentar Arquitecturas de Software

La ventaja de la primera opción es que proporciona al desarrollador una manera rápida de plasmar sus ideas de forma gráfica. Esta inmediatez ayuda a que el proceso sea más rápido y directo, con lo que idealmente el resultado se ajusta fielmente a la visión que tiene el desarrollador. Por contra, se acaban generando diagramas con notación inconsistente, nombres ambiguos, terminología demasiado genérica y muchas más otras inconsistencias.

Por supuesto, como se contempla en la segunda opción, existen estándares como UML a los que el equipo se puede acoger, evitando estas ambigüedades. El problema con estos estándares es que son costosos de aprender, son complejos y no se ajustan demasiado bien a las metodologías ágiles que imperan hoy en día. Son una buena herramienta para documentar y comunicar un sistema ya diseñado, pero no son muy amigables pera utilizar durante el propio proceso de diseño.

En este marco, y basándose en UML, el arquitecto Simon Brown creó un modelo que pretendía solucionar estos inconvenientes: A la vez que se estandariza formalmente el proceso, el lenguaje utilizado es lo suficientemente ágil, simple y flexible como para que pueda ser rápidamente adoptado por los equipos de desarrollo.

El modelo C4 establece 4 niveles de abstracción de forma jerárquica:

  1. Contexto. Este es el nivel más alto de abstracción que establece el modelo C4. Los diagramas de contexto contemplan el sistema como un todo y muestran sus relaciones con el exterior, esto es, con los usuarios y con otros sistemas.
Diagrama de contexto

2. Contenedores. Los diagramas de este nivel descomponen el sistema en contenedores relacionados. En este nivel, un contenedor representa una aplicación o un almacén de datos: Servicios Web, aplicaciones Web, Bases de datos, Sistemas de ficheros…

Diagrama de contenedores

3. Componentes. Los contenedores se descomponen en componentes interrelacionados y que a su vez pueden relacionarse con otros contenedores o sistemas.

Diagrama de componentes

4. Código. Es el nivel de abstracción más bajo. Se documenta el sistema a nivel de código. Para este nivel, el modelo C4 no proporciona ningún tipo de notación, sino que se basa en notaciones existentes, como pueda ser el diagrama de clases de UML.

Diagrama de clases

Para los niveles 1 a 3, el modelo C4 utiliza 5 elementos básicos, que son los mismos para todos los niveles: personas, sistemas, contenedores, componentes y relaciones.

C4 recomienda el uso de diagramas simples, cuyas cajas pueden estar anidadas (Por ejemplo, un contenedor del nivel 2 se puede descomponer en un diagrama del nivel 3).

C4 estandariza la documentación de arquitecturas software a la vez que simplifica su adopción y uso.

Comparte

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *