El modeloC4
para visualizar la
ARQUITECTURA
DE SOFTWARE
//arquitectura de software
El concepto de arquitectura de software se refiere a la estructuración del sistema que, idealmente, se crea en etapas tempranas del desarrollo. Esta estructuración representa un diseño de alto nivel del sistema que tiene dos propósitos primarios: satisfacer los atributos de calidad (desempeño, seguridad, modificabilidad), y servir como guía en el desarrollo
//introducción
En la industria de la construcción comunicar visualmente la arquitectura de un edificio se presenta con planos, maquetas, vistas en sección transversal y dibujos detallados. Por el contrario, en ingeniería de software, la arquitectura de un sistema de software se representa con un lío confuso de cuadros y líneas ... notación inconsistente (codificación de colores, formas, estilos de línea, etc.), nombres ambiguos , relaciones no marcadas, terminología genérica, opciones tecnológicas faltantes, abstracciones mixtas, etc.
01
//el modelo C4
Mapas de tu código
Nivel 3
El modelo C4 se creó como una forma de ayudar a los equipos de desarrollo de software a describir y comunicar la arquitectura del software, tanto durante las sesiones de diseño iniciales como al documentar retrospectivamente una base de código existente. 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.
Sin embargo, navegar por un entorno desconocido se vuelve más fácil si se aleja.
02
Nivel 2
Si se aleja aún más, se proporcionará un contexto adicional que quizás no haya conocido.
Nivel 4
Al igual que el código fuente, Google Street View proporciona una vista precisa y de muy bajo nivel de una ubicación.
Nivel 1
Los diferentes niveles de zoom le permiten contar diferentes historias a diferentes audiencias.
03
//características
02
03
01
COMUNICACIÓN
DIRIGIDO A
ABSTRACCIÓN
proporciona una forma para que los equipos de desarrollo de software comuniquen de manera eficiente y efectiva su arquitectura de software
El modelo C4 es un enfoque de "abstracción primero" para la diagramación de la arquitectura de software, basado en abstracciones que reflejan cómo los arquitectos y desarrolladores de software piensan y crean software.
está dirigido principalmente a arquitectos y desarrolladores de software
04
// diagramas
Nivel 1
Nivel 3
un diagrama de contexto del sistema proporciona un punto de partida, que muestra cómo el sistema de software en su alcance se ajusta al mundo que lo rodea.
un diagrama de componentes se amplía a un contenedor individual, mostrando los componentes dentro de él.
Nivel 4
Nivel 2
Se puede usar un diagrama de código (por ejemplo, clase UML) para ampliar un componente individual, que muestra cómo se implementa ese componente.
un diagrama de Contenedor amplía el alcance del sistema de software, mostrando los bloques de construcción técnicos de alto nivel.
// ejemplo
05
Para crear estos mapas de código, primero necesitamos un conjunto de abstracciones para crear un lenguaje común que podamos usar 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 .
Un sistema de software está compuesto por uno o más contenedores (aplicaciones web, aplicaciones móviles, aplicaciones de escritorio, bases de datos, sistemas de archivos, etc.), cada uno de los cuales contiene uno o más componentes , que a su vez están implementados por uno o más elementos de código ( por ejemplo, clases, interfaces, objetos, funciones, etc.
06
// abstracciones
//abstracciones
06
SISTEMA DE SOFTWARE
PERSONAS
Un sistema de software es el nivel más alto de abstracción y describe algo que brinda valor a sus usuarios, ya sean humanos o no. Esto 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.
Una persona representa a uno de los usuarios humanos de su sistema de software (por ejemplo, actores, roles, personas, etc.).
//abstracciones
06
Ejemplos de Contenedores
CONTENEDOR
- 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 JavaScript que se ejecuta en un navegador web utilizando Angular, Backbone.JS, jQuery, etc.
Un contenedor representa una aplicación o un almacén de datos; es algo que debe ejecutarse para que funcione el sistema de software en general. Un contenedor es esencialmente un contexto o límite dentro del cual se ejecuta algún código o se almacenan algunos datos. Cada contenedor es un elemento implementable / ejecutable por separado. Debido a esto, la comunicación entre contenedores generalmente toma la forma de una comunicación entre procesos.
//abstracciones
06
Ejemplos de contenedores
Ejemplos de contenedores
- Base de datos : un esquema o base de datos en un sistema de gestión de bases de datos relacionales, almacén de documentos, base de datos de gráficos, etc., como MySQL, Microsoft SQL Server, Oracle Database, MongoDB, Riak, Cassandra, Neo4j, etc.
- Blob o tienda de contenido : una tienda de blob (por ejemplo, Amazon S3, Microsoft Azure Blob Storage, etc.) o una red de entrega de contenido (por ejemplo, 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 script de shell único escrito en Bash, 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.
- Aplicación móvil : una aplicación Apple iOS, una aplicación Android, una aplicación Microsoft Windows Phone, etc.
- Aplicación de consola del lado del servidor : una aplicación independiente (p. Ej., "Público estático vacío principal"), un proceso por lotes, etc.
- Microservicio : un solo microservicio, alojado en cualquier cosa, desde un servidor web tradicional hasta algo como Spring Boot, Dropwizard, etc.
- Función sin servidor: una única función sin servidor (por ejemplo, Amazon Lambda, Azure Function, etc.).
//abstracciones
06
COMPONENTE
Si está utilizando un lenguaje como Java o C #, la forma más sencilla de pensar en un componente es que es una colección de clases de implementación detrás de una interfaz. Un punto importante a tener en cuenta aquí es que todos los componentes dentro de un contenedor generalmente se ejecutan en el mismo espacio de proceso. En el modelo C4, los componentes no son unidades desplegables por separado.
Un componente es una agrupación de funcionalidades relacionadas encapsuladas detrás de una interfaz bien definida
//diagramas
07
CARACTERÍSTICAS
DIAGRAMA DE CONTEXTO
Alcance : un solo sistema de software.
Elementos primarios : El sistema de software en alcance.
Elementos de soporte : personas (por ejemplo, usuarios, actores, roles o personas) y sistemas de software (dependencias externas) que están directamente conectados al sistema de software en su alcance. Por lo general, estos otros sistemas de software se encuentran fuera del alcance o los límites de su propio sistema de software, y usted no tiene responsabilidad ni propiedad de ellos.
Audiencia prevista : Todos, tanto técnicos como no técnicos, dentro y fuera del equipo de desarrollo de software.
Es un diagrama que muestra el sistema como un cuadro en el centro, rodeado por sus usuarios y los otros sistemas con los que interactúa. Los detalles no son importantes aquí. El enfoque debe estar en las personas (actores, roles, personas, etc.) y los sistemas de software en lugar de las tecnologías, protocolos y otros detalles de bajo nivel
//diagramas
07
CARACTERÍSTICAS
DIAGRAMA DE CONTENEDOR
Alcance : un solo sistema de software.
Elementos primarios : Contenedores dentro del sistema de software en alcance.
Elementos de soporte : personas y sistemas de software directamente conectados a los contenedores.
Audiencia prevista : personas técnicas dentro y fuera del equipo de desarrollo de software; incluyendo arquitectos de software, desarrolladores y personal de operaciones / soporte.
Notas : Este diagrama no dice nada sobre escenarios de implementación, agrupación, replicación, conmutación por error, etc.
El diagrama de Contenedores muestra la forma de alto nivel de la arquitectura de software y cómo se distribuyen las responsabilidades en ella. También muestra las principales opciones tecnológicas y cómo los contenedores se comunican entre sí. Es un diagrama simple, enfocado en la tecnología de alto nivel que es útil para los desarrolladores de software y el personal de soporte / operaciones por igual.
//diagramas
07
CARACTERÍSTICAS
DIAGRAMA DE COMPONENTES
Alcance : un solo contenedor.
Elementos primarios : Componentes dentro del contenedor en alcance.
Elementos de soporte : Contenedores (dentro del alcance del sistema de software) más personas y sistemas de software directamente conectados a los componentes.
Destinatarios : arquitectos y desarrolladores de software.
El diagrama de componentes muestra cómo un contenedor está compuesto por una serie de "componentes", cuáles son cada uno de esos componentes, sus responsabilidades y los detalles de tecnología / implementación.
//diagramas
07
CARACTERÍSTICAS
DIAGRAMA DE CÓDIGO
Se utiliza para mostrar cómo se implementa un componente con su código; utilizando diagramas de clase UML, diagramas de relación de entidad o similares.
Este es un nivel de detalle opcional. Idealmente, este diagrama se generaría automáticamente utilizando herramientas (por ejemplo, una herramienta de modelado IDE o UML), y debería considerar mostrar solo aquellos atributos y métodos que le permitan contar la historia que desea contar. Este nivel de detalle no se recomienda para nada más que los componentes más importantes o complejos.
Alcance : un solo componente.
Elementos primarios : elementos de código (p. Ej., Clases, interfaces, objetos, funciones, tablas de bases de datos, etc.) dentro del componente dentro del alcance.
Destinatarios : arquitectos y desarrolladores de software.
//notación
El modelo C4 no prescribe ninguna notación particular. Cualquier notación utilizada debe ser tan autodescriptiva como sea posible, pero todos los diagramas deben tener una clave / leyenda para hacer explícita la notación.
Contenedor
08
Componente
Persona
Relación
Sistema de software
08
//notación: diagramas
02
03
01
TÍTULO
SIGLAS
LEYENDA
Cada diagrama debe tener una clave / leyenda que explique la notación que se utiliza (por ejemplo, formas, colores, estilos de borde, tipos de línea, puntas de flecha, etc.).
Las siglas y abreviaturas (negocios / dominio o tecnología) deben ser entendibles por todos los públicos, o explicarse en la clave / leyenda del diagrama.
Cada diagrama debe tener un título que describa el tipo y el alcance del diagrama (por ejemplo, "Diagrama de contexto del sistema para mi sistema de software").
08
//notación: elementos
02
03
01
TIPO
TECNOLOGÍA
DESCRIPCIÓN
Cada elemento debe tener una breve descripción, para proporcionar una vista "de un vistazo" de las responsabilidades clave.
Cada contenedor y componente debe tener una tecnología explícitamente especificada.
El tipo de cada elemento debe especificarse explícitamente (por ejemplo, Persona, Sistema de software, Contenedor o Componente).
08
//notación: relaciones
02
03
01
RELACIONES ENTRE CONTENEDORES
ETIQUETAS
REPRESENTACIÓN
Cada línea debe representar una relación unidireccional.
Cada línea debe estar etiquetada, la etiqueta debe ser coherente con la dirección y la intención de la relación (por ejemplo, dependencia o flujo de datos). Trate de ser lo más específico posible con la etiqueta, idealmente evitando palabras individuales como "Usos".
Las relaciones entre contenedores (generalmente representan comunicación entre procesos) deben tener una tecnología / protocolo explícitamente etiquetado.
El modelo C4
DIEGO ISMAEL VELASCO SANCHEZ
Created on June 9, 2020
Arquitectura de software
Start designing with a free template
Discover more than 1500 professional designs like these:
View
Audio tutorial
View
Pechakucha Presentation
View
Desktop Workspace
View
Decades Presentation
View
Psychology Presentation
View
Medical Dna Presentation
View
Geometric Project Presentation
Explore all templates
Transcript
El modeloC4
para visualizar la
ARQUITECTURA
DE SOFTWARE
//arquitectura de software
El concepto de arquitectura de software se refiere a la estructuración del sistema que, idealmente, se crea en etapas tempranas del desarrollo. Esta estructuración representa un diseño de alto nivel del sistema que tiene dos propósitos primarios: satisfacer los atributos de calidad (desempeño, seguridad, modificabilidad), y servir como guía en el desarrollo
//introducción
En la industria de la construcción comunicar visualmente la arquitectura de un edificio se presenta con planos, maquetas, vistas en sección transversal y dibujos detallados. Por el contrario, en ingeniería de software, la arquitectura de un sistema de software se representa con un lío confuso de cuadros y líneas ... notación inconsistente (codificación de colores, formas, estilos de línea, etc.), nombres ambiguos , relaciones no marcadas, terminología genérica, opciones tecnológicas faltantes, abstracciones mixtas, etc.
01
//el modelo C4
Mapas de tu código
Nivel 3
El modelo C4 se creó como una forma de ayudar a los equipos de desarrollo de software a describir y comunicar la arquitectura del software, tanto durante las sesiones de diseño iniciales como al documentar retrospectivamente una base de código existente. 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.
Sin embargo, navegar por un entorno desconocido se vuelve más fácil si se aleja.
02
Nivel 2
Si se aleja aún más, se proporcionará un contexto adicional que quizás no haya conocido.
Nivel 4
Al igual que el código fuente, Google Street View proporciona una vista precisa y de muy bajo nivel de una ubicación.
Nivel 1
Los diferentes niveles de zoom le permiten contar diferentes historias a diferentes audiencias.
03
//características
02
03
01
COMUNICACIÓN
DIRIGIDO A
ABSTRACCIÓN
proporciona una forma para que los equipos de desarrollo de software comuniquen de manera eficiente y efectiva su arquitectura de software
El modelo C4 es un enfoque de "abstracción primero" para la diagramación de la arquitectura de software, basado en abstracciones que reflejan cómo los arquitectos y desarrolladores de software piensan y crean software.
está dirigido principalmente a arquitectos y desarrolladores de software
04
// diagramas
Nivel 1
Nivel 3
un diagrama de contexto del sistema proporciona un punto de partida, que muestra cómo el sistema de software en su alcance se ajusta al mundo que lo rodea.
un diagrama de componentes se amplía a un contenedor individual, mostrando los componentes dentro de él.
Nivel 4
Nivel 2
Se puede usar un diagrama de código (por ejemplo, clase UML) para ampliar un componente individual, que muestra cómo se implementa ese componente.
un diagrama de Contenedor amplía el alcance del sistema de software, mostrando los bloques de construcción técnicos de alto nivel.
// ejemplo
05
Para crear estos mapas de código, primero necesitamos un conjunto de abstracciones para crear un lenguaje común que podamos usar 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 .
Un sistema de software está compuesto por uno o más contenedores (aplicaciones web, aplicaciones móviles, aplicaciones de escritorio, bases de datos, sistemas de archivos, etc.), cada uno de los cuales contiene uno o más componentes , que a su vez están implementados por uno o más elementos de código ( por ejemplo, clases, interfaces, objetos, funciones, etc.
06
// abstracciones
//abstracciones
06
SISTEMA DE SOFTWARE
PERSONAS
Un sistema de software es el nivel más alto de abstracción y describe algo que brinda valor a sus usuarios, ya sean humanos o no. Esto 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.
Una persona representa a uno de los usuarios humanos de su sistema de software (por ejemplo, actores, roles, personas, etc.).
//abstracciones
06
Ejemplos de Contenedores
CONTENEDOR
Un contenedor representa una aplicación o un almacén de datos; es algo que debe ejecutarse para que funcione el sistema de software en general. Un contenedor es esencialmente un contexto o límite dentro del cual se ejecuta algún código o se almacenan algunos datos. Cada contenedor es un elemento implementable / ejecutable por separado. Debido a esto, la comunicación entre contenedores generalmente toma la forma de una comunicación entre procesos.
//abstracciones
06
Ejemplos de contenedores
Ejemplos de contenedores
//abstracciones
06
COMPONENTE
Si está utilizando un lenguaje como Java o C #, la forma más sencilla de pensar en un componente es que es una colección de clases de implementación detrás de una interfaz. Un punto importante a tener en cuenta aquí es que todos los componentes dentro de un contenedor generalmente se ejecutan en el mismo espacio de proceso. En el modelo C4, los componentes no son unidades desplegables por separado.
Un componente es una agrupación de funcionalidades relacionadas encapsuladas detrás de una interfaz bien definida
//diagramas
07
CARACTERÍSTICAS
DIAGRAMA DE CONTEXTO
Alcance : un solo sistema de software. Elementos primarios : El sistema de software en alcance. Elementos de soporte : personas (por ejemplo, usuarios, actores, roles o personas) y sistemas de software (dependencias externas) que están directamente conectados al sistema de software en su alcance. Por lo general, estos otros sistemas de software se encuentran fuera del alcance o los límites de su propio sistema de software, y usted no tiene responsabilidad ni propiedad de ellos. Audiencia prevista : Todos, tanto técnicos como no técnicos, dentro y fuera del equipo de desarrollo de software.
Es un diagrama que muestra el sistema como un cuadro en el centro, rodeado por sus usuarios y los otros sistemas con los que interactúa. Los detalles no son importantes aquí. El enfoque debe estar en las personas (actores, roles, personas, etc.) y los sistemas de software en lugar de las tecnologías, protocolos y otros detalles de bajo nivel
//diagramas
07
CARACTERÍSTICAS
DIAGRAMA DE CONTENEDOR
Alcance : un solo sistema de software. Elementos primarios : Contenedores dentro del sistema de software en alcance. Elementos de soporte : personas y sistemas de software directamente conectados a los contenedores. Audiencia prevista : personas técnicas dentro y fuera del equipo de desarrollo de software; incluyendo arquitectos de software, desarrolladores y personal de operaciones / soporte. Notas : Este diagrama no dice nada sobre escenarios de implementación, agrupación, replicación, conmutación por error, etc.
El diagrama de Contenedores muestra la forma de alto nivel de la arquitectura de software y cómo se distribuyen las responsabilidades en ella. También muestra las principales opciones tecnológicas y cómo los contenedores se comunican entre sí. Es un diagrama simple, enfocado en la tecnología de alto nivel que es útil para los desarrolladores de software y el personal de soporte / operaciones por igual.
//diagramas
07
CARACTERÍSTICAS
DIAGRAMA DE COMPONENTES
Alcance : un solo contenedor. Elementos primarios : Componentes dentro del contenedor en alcance. Elementos de soporte : Contenedores (dentro del alcance del sistema de software) más personas y sistemas de software directamente conectados a los componentes. Destinatarios : arquitectos y desarrolladores de software.
El diagrama de componentes muestra cómo un contenedor está compuesto por una serie de "componentes", cuáles son cada uno de esos componentes, sus responsabilidades y los detalles de tecnología / implementación.
//diagramas
07
CARACTERÍSTICAS
DIAGRAMA DE CÓDIGO
Se utiliza para mostrar cómo se implementa un componente con su código; utilizando diagramas de clase UML, diagramas de relación de entidad o similares. Este es un nivel de detalle opcional. Idealmente, este diagrama se generaría automáticamente utilizando herramientas (por ejemplo, una herramienta de modelado IDE o UML), y debería considerar mostrar solo aquellos atributos y métodos que le permitan contar la historia que desea contar. Este nivel de detalle no se recomienda para nada más que los componentes más importantes o complejos.
Alcance : un solo componente. Elementos primarios : elementos de código (p. Ej., Clases, interfaces, objetos, funciones, tablas de bases de datos, etc.) dentro del componente dentro del alcance. Destinatarios : arquitectos y desarrolladores de software.
//notación
El modelo C4 no prescribe ninguna notación particular. Cualquier notación utilizada debe ser tan autodescriptiva como sea posible, pero todos los diagramas deben tener una clave / leyenda para hacer explícita la notación.
Contenedor
08
Componente
Persona
Relación
Sistema de software
08
//notación: diagramas
02
03
01
TÍTULO
SIGLAS
LEYENDA
Cada diagrama debe tener una clave / leyenda que explique la notación que se utiliza (por ejemplo, formas, colores, estilos de borde, tipos de línea, puntas de flecha, etc.).
Las siglas y abreviaturas (negocios / dominio o tecnología) deben ser entendibles por todos los públicos, o explicarse en la clave / leyenda del diagrama.
Cada diagrama debe tener un título que describa el tipo y el alcance del diagrama (por ejemplo, "Diagrama de contexto del sistema para mi sistema de software").
08
//notación: elementos
02
03
01
TIPO
TECNOLOGÍA
DESCRIPCIÓN
Cada elemento debe tener una breve descripción, para proporcionar una vista "de un vistazo" de las responsabilidades clave.
Cada contenedor y componente debe tener una tecnología explícitamente especificada.
El tipo de cada elemento debe especificarse explícitamente (por ejemplo, Persona, Sistema de software, Contenedor o Componente).
08
//notación: relaciones
02
03
01
RELACIONES ENTRE CONTENEDORES
ETIQUETAS
REPRESENTACIÓN
Cada línea debe representar una relación unidireccional.
Cada línea debe estar etiquetada, la etiqueta debe ser coherente con la dirección y la intención de la relación (por ejemplo, dependencia o flujo de datos). Trate de ser lo más específico posible con la etiqueta, idealmente evitando palabras individuales como "Usos".
Las relaciones entre contenedores (generalmente representan comunicación entre procesos) deben tener una tecnología / protocolo explícitamente etiquetado.