Comunidad

Por Ding Yi, apodado Sanhua en Alibaba.

El valor de la comunicación técnica no sólo se refleja en la forma en que se desarrollan las aplicaciones a través de productos comerciales y proyectos de código abierto y en la forma en que se aceleran diversos procesos de lanzamiento de negocios. Pero, su valor se refleja también en la experiencia compartida por diferentes ingenieros destacados en la mejora de la productividad, la optimización del rendimiento del producto y la promoción de la experiencia del usuario. En una frase, la comunicación técnica es importante porque mejora nuestras capacidades profesionales.

En este artículo, un experto técnico de Alibaba, Ding Yi, compartirá sus ideas y experiencia en la creación de diagramas de arquitectura eficaces.

Para describir nuestro sistema en uno o más diagramas, a menudo nos encontramos con los siguientes problemas:

• No sabemos por dónde empezar.
• No sabemos cómo describir el sistema en un diagrama que sea lo suficientemente claro para que los equipos de producto, operaciones y desarrollo pertinentes lo entiendan con claridad.
• A mitad de camino, nos damos cuenta de que no sabemos quién es la audiencia.
• No sabemos si estamos representando un gráfico funcional del producto, un diagrama técnico o simplemente una mezcla.
• Cuando hay muy pocas casillas en el diagrama, no sabemos qué más añadir.
• Nunca estamos satisfechos con el diseño del diagrama.

Si se ha encontrado con los mismos problemas, este artículo presenta una metodología de dibujo para producir diagramas de arquitectura claros.

Conceptos

¿Qué es una arquitectura?

Una «arquitectura» puede definirse como una descripción abstracta de las entidades de un sistema y las relaciones entre ellas. Implica una serie de procesos de toma de decisiones.

La arquitectura es una estructura y una visión.

Una «arquitectura de sistema» es la plasmación de conceptos y la distribución de las correspondencias entre las funciones de las cosas o la información y los elementos formales. Define las relaciones entre los elementos, así como entre los elementos y el entorno circundante.

Construir una arquitectura sólida es una tarea compleja y un gran tema para discutir aquí. Después de construir una arquitectura, las partes pertinentes deben entenderla y seguir sus dictados.

¿Qué es un diagrama de arquitectura?

Un diagrama de arquitectura es un diagrama de un sistema que se utiliza para abstraer el esquema general del sistema de software y las relaciones, restricciones y límites entre los componentes. Es una herramienta importante, ya que proporciona una visión global del despliegue físico del sistema de software y su hoja de ruta de evolución.

¿Cuáles son las funciones de un diagrama de arquitectura?

Un diagrama al igual que una imagen vale más que mil palabras. En otras palabras, un diagrama arquitectónico debe servir a varias funciones diferentes. Para permitir que los usuarios relevantes entiendan la arquitectura de un sistema y la sigan en su toma de decisiones, necesitamos comunicar información sobre la arquitectura. Los diagramas de arquitectura son una buena manera de hacerlo. Para poner algunas funciones principales, un diagrama arquitectónico necesita:

• Romper las barreras de comunicación
• Llegar a un consenso
• Disminuir la ambigüedad

Tipos de diagramas arquitectónicos

Los diagramas se pueden clasificar en muchas categorías. Un tipo popular de diagrama es la vista 4+1, que incluye las vistas de escenario, lógica, física, de proceso y de desarrollo de la arquitectura.

Vista de escenario

La vista de escenario describe las relaciones entre los participantes del sistema y los casos de uso funcionales y refleja los requisitos finales y el diseño de interacción del sistema. Esta vista es generalmente un diagrama de casos de uso.

Vista lógica

La vista lógica se utiliza para describir las relaciones de los componentes, las restricciones de los componentes y los límites después del desglose de las funciones de software del sistema. Refleja la composición global del sistema y cómo se construye el sistema. Esta vista es generalmente un diagrama de componentes UML o un diagrama de clases.

Vista física

La vista física describe el mapeo entre el software del sistema y el hardware físico y muestra cómo se despliegan los componentes del sistema a un grupo de nodos físicos computables. Proporciona orientación en el proceso de despliegue del sistema de software.

Vista de Proceso

La vista de proceso describe la secuencia de comunicación y la entrada y salida de datos entre los componentes de software del sistema y refleja los flujos funcionales y de datos del sistema. Esta vista se presenta normalmente como un diagrama de secuencia o diagrama de flujo.

Vista de desarrollo

La vista de desarrollo se utiliza para describir la división y composición de los módulos del sistema y refinar el diseño de composición de los paquetes internos. Esta vista es utilizada por los desarrolladores y refleja los procesos de desarrollo e implementación del sistema.

Las cinco vistas arquitectónicas anteriores representan diferentes características de un sistema de software desde diferentes perspectivas. Combinándolas en un diagrama arquitectónico, podemos entonces describir la arquitectura global del sistema con mucha claridad.

¿Qué hace que un diagrama arquitectónico sea eficaz?

¿Cómo podemos saber si un diagrama es un buen diagrama? ¿Y qué métodos debemos utilizar para crear un diagrama?

Los diagramas anteriores fueron seleccionados para ilustrar los diferentes tipos de diagramas, sin pensar en su calidad. Creemos que, para representar un buen diagrama arquitectónico, debemos saber quién es nuestro público y considerar qué información queremos transmitir. Por tanto, no debemos representar una vista física o una vista lógica porque sí. Los diagramas deben utilizarse para transmitir con precisión la información que necesita un determinado público para ser eficaces. Sólo entonces debemos preocuparnos por el tipo de diagrama que es. Por lo tanto, la norma más directa por la que podemos juzgar la calidad de un dibujo es si el público puede entender con precisión la información que intentamos transmitir.

Esto significa que un diagrama arquitectónico bueno y eficaz no necesita ser explicado al público. Debe expresar todo lo que se quiere decir por sí mismo. Además, un buen diagrama también debe tener una estructura consistente, exacta a los datos que está representando, y corresponder al código directamente.

Desafíos comunes al representar diagramas arquitectónicos

¿Qué representa un cuadrado?

¿Por qué usamos cuadrados en lugar de círculos? El uso aleatorio de cuadrados u otras formas puede causar confusión.

¿Qué significan las líneas punteadas y las sólidas? ¿Qué significa una flecha? Qué significan los colores?

El uso arbitrario de líneas o flechas puede provocar malentendidos.

¿Existen conflictos entre el tiempo de ejecución y el de compilación? ¿Hay conflictos de nivel?

Construir una arquitectura es un trabajo complejo. Por lo tanto, el uso de un solo diagrama para representar la arquitectura puede llevar fácilmente a la confusión en aspectos específicos sobre la arquitectura.

Mi método de dibujo recomendado

El modelo C4 utiliza contenedores, como aplicaciones, almacenes de datos y microservicios, así como componentes y código para describir la estructura estática de un sistema de software. Estos diagramas son fáciles de dibujar y sus elementos clave son explícitos. Sin embargo, lo más importante es que puedan indicar claramente la audiencia a la que va dirigido y el significado de cada diagrama.

El siguiente ejemplo procede de la web oficial de C4. Sobre esta base, conseguimos utilizar nuestra propia comprensión para expresar mejor la arquitectura del software.

Diagrama de contexto del sistema

Este es un diagrama de un sistema bancario planificado. Utiliza un sistema bancario mainframe externo para acceder a las cuentas de los clientes y a la información de las transacciones y envía correos electrónicos a los clientes a través de un sistema de correo electrónico externo. Como puede ver, el diagrama es sencillo y claro. No requiere ninguna explicación adicional para que el público lo entienda. También podemos ver que contiene el sistema que se va a construir, los clientes del sistema y los sistemas periféricos que interactúan con este sistema.

Uso

Un diagrama tan sencillo puede decir qué tipo de sistema se va a construir, quiénes son sus usuarios, quiénes lo manipularán y cómo se integrará en un entorno informático existente. La audiencia de este diagrama puede ser el personal interno del equipo de desarrollo, el personal técnico externo o el personal no técnico. Nos dice:

• ¿Qué sistema se va a construir?
• ¿Quién lo manipulará?
• ¿Cómo se integra en el entorno informático existente?

Cómo representar el diagrama

En este diagrama, su propio sistema está en el centro, y los usuarios y sistemas que interactúan con este sistema se colocan alrededor. El aspecto clave de este diagrama es que organiza y muestra claramente los usuarios y las dependencias de alto nivel del sistema a construir. Una vez realizado el trabajo conceptual, sólo se tarda unos minutos en representar el diagrama.

Diagrama contenedor

El diagrama contenedor amplía el sistema en el diagrama de contexto del sistema anterior.

En la figura anterior, además de los usuarios y los sistemas periféricos, el sistema a construir incluye una aplicación web basada en Java Spring MVC para proporcionar un portal de funciones para el sistema, mientras que una app móvil basada en Xamarin proporciona un portal de funciones para los clientes móviles. Una aplicación API basada en Java proporciona servicios, y una base de datos MySQL se utiliza para el almacenamiento. Las flechas indican las interacciones entre las aplicaciones.

Cuando observes este diagrama, no notarás si las cajas tienen esquinas afiladas o redondeadas o si las flechas tienen líneas sólidas o punteadas. Incluso las direcciones de las flechas no llaman mucho la atención.

Hay muchos métodos de dibujo, todos los cuales definen los significados de los cuadros y las líneas. Esto requiere que tanto el dibujante como el espectador del diagrama entiendan claramente estas definiciones. Sólo entonces se puede entender toda la información del diagrama. Sin embargo, esto es exigente, y muchos espectadores sólo captarán los conceptos generales.

Uso

La audiencia de este diagrama puede ser desarrolladores internos o externos o personal de O&M. Este diagrama tiene los siguientes propósitos:

• Presenta la estructura general del sistema de software.
• Refleja la toma de decisiones técnicas de alto nivel.
• Muestra cómo se distribuyen las responsabilidades en el sistema y cómo interactúan los contenedores entre sí.
• Indica a los desarrolladores dónde se requiere programación de código.

Cómo representar el diagrama

Este diagrama utiliza marcos, que pueden incluir nombres, opciones técnicas, responsabilidades e interacciones entre marcos. Si un sistema externo está involucrado, es mejor definir el límite.

Diagrama de componentes

Un diagrama de componentes se utiliza para ampliar un contenedor y describir sus módulos internos.

Uso

Este diagrama está destinado a los desarrolladores internos y les muestra cómo organizar y desarrollar el código. Este diagrama sirve para los siguientes propósitos:

• Describe los componentes o servicios del sistema.
• Aclara las relaciones y dependencias entre los componentes.
• Proporciona un marco de trabajo que muestra cómo se pueden distribuir y entregar las tareas de desarrollo de software.

Diagrama de código o clase

Este diagrama está destinado al personal de soporte técnico. Es un tipo de diagrama común, por lo que no lo describiremos en detalle.

Caso de estudio

La siguiente figura muestra la arquitectura de una herramienta interna de datos en tiempo real. Como un diagrama de arquitectura debería ser evidente, no hay mucha necesidad de explicarlo. Si no se puede entender claramente, el diagrama definitivamente no es lo suficientemente bueno.

Hay muchas metodologías para representar un buen diagrama de arquitectura. Este artículo presenta el método C4, que sin embargo también está en constante evolución. A pesar de ello, independientemente de la metodología de dibujo, simplemente debemos tener en cuenta la intención del dibujo y comunicarla mejor al público. No tenemos que estar excesivamente limitados por las reglas en el proceso de dibujo. En resumen, antes de empezar un diagrama, pregúntate: Para quién es, de qué es y cómo hacerlo intuitivo y comprensible.

Acerca del autor: Sanhua es un experto técnico de Alibaba. Zijing, Pengsheng y Yule también contribuyeron a este artículo. Ding Yi trabajó anteriormente en el motor de flujo de trabajo R&D durante muchos años, pero ahora se está centrando en la arquitectura y el desarrollo de aplicaciones de Internet móvil de alta moneda. Los colaboradores de este artículo pertenecen al Departamento de LST de Alibaba.

¿Estás ansioso por conocer las últimas tendencias tecnológicas de Alibaba Cloud? Escuche a nuestros mejores expertos en nuestra serie recién lanzada, Tech Show!