Este documento presenta el modelo C4, una herramienta para documentar la arquitectura de software. El modelo C4 describe un sistema en cuatro niveles de detalle: contexto, contenedores, componentes y código. Cada nivel proporciona más detalles sobre la estructura estática del sistema. El modelo utiliza diagramas y notación estándar para comunicar la arquitectura de manera clara y concisa a diferentes audiencias como arquitectos y desarrolladores.

1. Arquitectura de software
C4model
René Guamán-Quinche
Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables
Carrera de Ingeniería en Sistemas/Computación
Enero, 2022
Loja, Ecuador

2. 2
1. Conceptos
2. Abstracción
3. Modelo C4
4. Nivel de Contexto
5. Nivel de Contenedor
6. Nivel de Componente
7. Nivel de Código
8. Notación
Agenda

3. Introducción

4. Introducción

5. Introducción

6. Introducción

7. • Surge como solución para aliviar la brecha entre modelo y código
• Creado por Simon Brown
• Permite comunicar la arquitectura de un sistema en función del
detalle que se quiera proporcionar
• Se basa en la frase “Map of your code”
• Es una forma de crear mapas de su código, en varios niveles
de detalle, de la misma manera que usaría algo como Google
Maps para acercar y alejar un área que le interesa.
EL MODELO C4

8. • Está basado en cuatro niveles que describen el sistema con
distintos grados de granularidad
• El nivel de contexto
• El nivel de contenedores
• El nivel de componentes
• El nivel de código
EL MODELO C4

9. EL MODELO C4

10. EL MODELO C4
• Para crear estos mapas de su código:
• Necesita un conjunto común de abstracciones para crear un
lenguaje ubicuo para describir la estructura estática de un
sistema de software
• El modelo C4 considera las estructuras estáticas de un sistema
de software en términos de contenedores, componentes y
código. La gente (Person) usa los sistemas de software que
construimos.

11. EL MODELO C4

12. EL MODELO C4
Sistema de software:
• Es el nivel más alto de abstracción
• Describe algo que ofrece valor a sus usuarios, sean
humanos o no
• Incluye el sistema de software que está modelando y los
otros sistemas de software de los que depende su
sistema de software (o viceversa)
• En muchos casos, un sistema de software es "propiedad
de" un solo equipo de desarrollo de software

13. Nivel de Contexto
• Permite tener una imagen genérica de nuestro sistema
y sus interacciones con el exterior
• En este nivel podemos especificar los sistemas
externos con los que interactúa nuestro propio sistema
• El sistema que modelamos se considera una “caja
negra”, solo nos interesan sus relaciones externas
• También permite identificar los usuarios finales que
harán uso de la funcionalidad de nuestro software

14. Nivel de Contexto
• Aquí el detalle no es importante
• Elementos
• Primarios: El sistema a analizar
• Soporte: Usuarios y sistemas de software conectados directamente
• Audiencia: Todos, tanto técnicos como no técnicos, dentro y
fuera del equipo de desarrollo de software
• Persona: representa a uno de los usuarios humanos de su sistema de
software (por ejemplo, actores, roles, personajes, etc.)

15. Nivel de Contexto
Se ha utilizado un código de colores para indicar qué sistemas de software ya
existen (los recuadros grises).

16. Nivel de Contexto
Mostrar el límite de la empresa
En este ejemplo ligeramente modificado, la línea discontinua representa el
límite del banco y se utiliza para ilustrar lo que hay dentro y lo que hay fuera
del banco.

17. Nivel de Contexto
Elementos básicos

18. Nivel de Contexto
Ejemplo

19. Nivel de Contenedores
• Estructura de alto nivel de la arquitectura y como están
distribuidas las responsabilides
• Los contenedores referencian cualquier entidad que ejecuta
código o almacena datos
• Pueden verse como unidades desplegables o ejecutables
• Ejemplos de contenedores:
• Aplicaciones web
• Servicios web
• Aplicaciones de escritorio
• Bases de datos
• Sistema de ficheros

20. Nivel de Contenedores
• Muestra las decisiones tecnológicas más importantes
• Elementos:
• Primarios: contenedores dentro del sistema a analizar
• Soporte: Personas y sistemas de software conectados
directamente a los contenedores
• Audiencia: Personas técnicas dentro y fuera del equipo de
desarrollo de software; incluidos arquitectos de software,
desarrolladores y personal de operaciones/soporte
Notas: este diagrama no dice nada sobre escenarios de implementación, agrupación en
clústeres, replicación, conmutación por error, etc.

21. Nivel de Contenedores
• La línea discontinua representa el límite del sistema de banca por
Internet y muestra los contenedores (azul claro) en su interior
• Además, se ha utilizado una forma de cilindro para representar la
base de datos

22. Nivel de Contenedores

23. Nivel de Contenedores
Contenedor (aplicaciones y almacenes de datos)
¡No Docker! En el modelo C4,
Representa una aplicación o un almacén de datos
Es algo que debe estar ejecutándose para que el sistema de software general funcione
• Aplicación web del lado del servidor:
• una aplicación web Java EE que se ejecuta en Apache Tomcat
• una aplicación ASP.NET MVC que se ejecuta en Microsoft IIS
• una aplicación Ruby on Rails que se ejecuta en WEBrick
• una aplicación Node.js, etc.
• Aplicación web del lado del cliente:
• una aplicación de JavaScript que se ejecuta en un navegador web usando Angular,
Backbone.JS, jQuery, etc.
• Aplicación de escritorio del lado del cliente:
• una aplicación de escritorio de Windows escrita con WPF,
• una aplicación de escritorio de OS X escrita con Objective-C,
• una aplicación de escritorio multiplataforma escrita con JavaFX, etc.

24. Nivel de Contenedores
Contenedor (aplicaciones y almacenes de datos)
Es algo que debe estar ejecutándose para que el sistema de software general funcione
• Aplicación móvil:
• una aplicación de Apple iOS,
• una aplicación de Android,
• una aplicación de Microsoft Windows Phone, etc.
• Aplicación de consola del lado del servidor:
• una aplicación independiente (por ejemplo, "public static void main"),
• un proceso por lotes, etc.
• Función sin servidor - Serverless function:
• una sola función sin servidor (por ejemplo, Amazon Lambda, Azure Function,
etc.).

25. Nivel de Contenedores
Contenedor (aplicaciones y almacenes de datos)
Es algo que debe estar ejecutándose para que el sistema de software general funcione
• Base de datos:
• un esquema o base de datos en un sistema de gestión de base de datos relacional,
• almacén de documentos,
• base de datos de gráficos, etc.,
• MySQL, Microsoft SQL Server, Oracle Database, MongoDB, Riak, Cassandra, Neo4j,
etc.
• Blob o almacén de contenido: un almacén de blobs (p. ej., Amazon S3, Microsoft
Azure Blob Storage, etc.) o una red de entrega de contenido (p. ej., Akamai, Amazon
CloudFront, etc.).
• Sistema de archivos: un sistema de archivos local completo o una parte de un
sistema de archivos en red más grande (por ejemplo, SAN, NAS, etc.).
• Script de shell: un único script de shell escrito en Bash, etc.

26. Nivel de Componentes
• Dentro de cada contenedor podemos encontrar diversos
componentes
• Los componentes representan un grupo de funcionalidades
• Los componentes pueden tener relaciones entre sí y entre los
usuarios finales
• Muestra la responsabilidad de cada componente a alto nivel, así
como los detalles de implementación (tecnología utilizada, etc.)

27. Nivel de Componentes
• De cada componente nos interesa saber:
• Nombre
• Responsabilidades
• Detalles de implementación
• Elementos:
• Primarios: componentes dentro del contenedor
• Soporte: contenedores, personas y sistemas de sw conectados
directamente a los componentes
• Audiencia: Arquitectos de sw y desarrolladores

28. Nivel de Componentes
Componente
• La palabra "componente" es un término muy sobrecargado en la industria del
desarrollo de software,
• En este contexto, es una agrupación de funciones relacionadas encapsuladas detrás
de una interfaz bien definida
• En lenguajes: Java o C#, un componente es que es una colección de clases de
implementación detrás de una interfaz
• Aspectos como la forma en que se empaquetan esos componentes (por ejemplo, un
componente frente a muchos componentes por archivo JAR, DLL, biblioteca
compartida, etc.) es una preocupación separada y ortogonal.
• Todos los componentes dentro de un contenedor normalmente se ejecutan en el
mismo espacio de proceso.
• En C4, los componentes no son unidades desplegables por separado

29. Nivel de Componentes
• La línea discontinua representa el límite de la aplicación API y
muestra los componentes (azul claro) dentro de ella

30. Nivel de Componentes

31. Nivel de Código
• En este nivel se muestran detalles de la implementación de cada
componente
• Se pueden utilizar diagramas de clase, de entidad relación, o
similares

32. Nivel de Código
• Alcance: Un solo componente.
• Elementos primarios: Elementos de código (por ejemplo,
clases, interfaces, objetos, funciones, tablas de bases de datos,
etc.) dentro del alcance del componente.
• Público objetivo: Arquitectos y desarrolladores de software.
• Recomendado para la mayoría de los equipos: no, para la
documentación de larga duración, la mayoría de los IDE pueden
generar este nivel de detalle a pedido.

33. Notación

34. Herramientas

35. 35
Cŕeditos
• Transparencias basadas por:
• Dr. Francisco José García Peñalvo / fgarcia@usal.es, Universidad de
Salamanca, MODELO C4 INGENIERÍA DE SOFTWARE I
https://repositorio.grial.eu/bitstream/grial/2482/1/C4%20model.pdf
• https://c4model.com/
• Visualising software architecture with the C4 model
• https://www.youtube.com/watch?v=x2-rSnhpw0g&t=111s
• https://s3.amazonaws.com/static.codingthearchitecture.com/presentati
ons/aotb2019-visualising-software-architecture-with-the-c4-model.pdf

36. Networking académico:
Correo electrónico: rguaman@unl.edu.ec
Twitter: @rene5254
SlideShare: https://es.slideshare.net/rene5254
36
Gracias