UML para desarrolladores

Internet está lleno de artículos sobre UML, encontrará cientos de ejemplos para cada tipo de diagrama y creará el suyo sin problemas, la notación no es complicada. Pero, ¿es realmente necesario pasar tiempo en esto? Nuestra riqueza de experiencia dice que sí. Si tiene más de 2 personas en un equipo y un proyecto de 3 meses o más, entonces ya tiene sentido dibujar 2-3 tipos de diagramas. Nuestro equipo tiene más de 30 personas, un proyecto que dura más de 3 años, y usamos ... 2-3 tipos de diagramas.

La notación UML es redundante. Por otro lado, no es suficiente para el diseño de sistemas distribuidos, y aquí Archimate nos ayuda. En este artículo, le diremos qué es realmente útil de toda esta variedad, y consideraremos el ciclo completo de creación de diagramas para un proyecto como ejemplo.

¿Qué vamos a dibujar?


Si su objetivo es "rápido y hermoso" (por ejemplo, para una presentación o para este artículo), entonces Visio es más que adecuado: su editor es conveniente y perdona cualquier desviación de la notación.

Si está involucrado en el diseño, necesitará un sistema completo con soporte para las relaciones entre los diagramas. Utilizamos productos de Enterprise Architect, baratos y alegres.
Una comparación de los sistemas de diseño y una historia sobre cómo usarlos correctamente es un tema para un artículo separado.

Tarea técnica


Diseñaremos una hipotética aplicación móvil para aprender idiomas extranjeros. Los términos de referencia generalmente son preparados por analistas que prepararán el primer lote de diagramas. Los desarrolladores, en este caso, solo deben leerlos correctamente.

El diagrama más simple es el caso de uso:



el diagrama muestra los tipos de usuarios y enumera las funciones o grupos de funciones que están asociados con ellos. El elemento resaltado en azul que no está presente en UML, pero que a menudo carece de: Requisito - Requisito (de la notación Archimate), refinamiento de las funciones.

Usted pregunta, ¿y cuál es el punto? Después de todo, la lista de funciones se puede especificar simplemente en texto, ¡en una lista compacta! Y tendrás razón, pero hay matices.

  1. Algunas funciones se relacionan con varios usuarios, es difícil mostrar el texto.
  2. Cuando dibuja todas las funciones y requisitos en el sistema de diseño, puede subirlos al mismo Jira y luego asociarlos con tareas y errores, lo que simplifica la gestión de proyectos.

¿Por qué mezclamos UML y Archimate en el mismo diagrama? No es necesario que sigas estrictamente las anotaciones; no tienes que aprobar los exámenes en la universidad con esto, sino comunicarte con el equipo, para lo cual lo estás preparando todo.

¿Por qué usamos líneas en lugar de flechas para conectar elementos? Porque nadie recuerda cómo son las flechas de "Generalización" y "Extensión", y cuáles son en general. Cuanto más simple dibuje, más personas entenderán el cuadro sin su participación.

El segundo tipo de diagramas que puede cumplir en la tarea técnica es Diagrama de actividad:



Aquí, todo es obvio para el desarrollador, excepto uno: ¿por qué la IA hace llamadas de estudiantes? No. Este diagrama está dibujado por analistas, no por programadores, no saben dónde está el cliente, sino dónde está el servidor, y no están interesados ​​en los flujos de datos. En el diagrama de Actividad, verá una secuencia de acciones y nada más. ¿Cómo hacer un código de esto? Pasamos a la etapa de diseño.

Diseño arquitectónico


La arquitectura de la aplicación móvil es obvia: cliente, servidor, base de datos. Si estamos diseñando algo serio, entonces deberíamos ocuparnos de dividir el proyecto en Subsistemas, en nuestro caso será al menos:

  • Subsistema de reserva de lecciones
  • Subsistema de formación web
  • Facturación
  • Subsistema de gestión de grabación de voz

Los subsistemas deben estar aislados unos de otros: sus propias bases de datos sin conexiones relacionales con otros subsistemas, comunicación entre subsistemas solo a través de la API. El subsistema puede ser un conjunto de microservicios o un monolito, a su discreción.

Puede entregar cada subsistema a un equipo de desarrollo dedicado, se sumergirán en su tema y interferirán menos con sus colegas con sus compromisos inesperados.

Para cada subsistema, se requiere un esquema arquitectónico , ¿cómo dibujarlo correctamente? No hay diagramas adecuados en UML para esto, veamos Archimate:



Incluso sin el conocimiento de la notación, el diagrama es generalmente legible. Recuerde que el 90% de los miembros de su equipo no conocen UML, y mucho menos Archimate, y nunca aprenderán estas anotaciones, así que concéntrese en las inscripciones. Sin embargo,



algunas palabras sobre los cubos y las flechas: puede encontrar fácilmente la especificación Archimate completa.

Color: a su gusto, la notación no los regula de ninguna manera. Colorea el subsistema actual con un color, los subsistemas adyacentes con el segundo, los sistemas externos con el tercero, esto mejora enormemente la legibilidad del circuito.

El diagrama usa solo dos tipos de flechas: flujo y acceso. El flujo muestra la dirección de la transferencia de datos y la llamada: quién está hablando con quién. La flecha de flujo debe entenderse correctamente:



El diagrama de flujo de la aplicación móvil al servidor no se muestra en el diagrama, aunque de hecho sí lo es (el flujo de "Solicitud de datos" va primero). Esto se hace para que el esquema sea más fácil de leer: mostramos solo lo más importante. El hecho de que también hay una solicitud de datos inicial ya es evidente desde el cubo con la API de inscripción.

Detalle


Los dos últimos diagramas, que son muy útiles (el lector atento, por supuesto, notó que ya no hay 2-3 tipos de diagramas): diagrama de secuencia (diagrama de clase) y diagrama de clase (diagrama de clase, pero no para clases).

A veces, la interacción cliente-servidor es de varias etapas, utilizando terceros recursos. Por ejemplo, autorización con Oauth2: una descripción textual de este proceso es muy difícil de entender. Aquí el diagrama de secuencia nos ayudará :



esta implementación de Oauth2 no es una referencia, puede haber muchas opciones. Lo más importante que debe comprender en el diagrama es que no hay flujos de datos en este diagrama, solo Llamadas y respuestas a las llamadas. Aunque esto no nos impidió especificar los flujos con texto en las flechas.

Cuando profundice en el estudio del diagrama de secuencia, encontrará que le permite mostrar bucles y ramas, pero no los abuse: no necesita dibujar las ramas "Si el usuario eligió la autorización local" y "Si eligió la autorización FB" , en su lugar, Dibuja dos esquemas para cada opción. Las condiciones, especialmente las anidadas, en el diagrama de secuencia reducen en gran medida la legibilidad del circuito.

El último diagrama (no hoy, pero en general) es el Diagrama de clases . Su nombre está hablando, se asumió que con la ayuda de sus clases se diseñaría. En los viejos tiempos de los editores de texto de DOS, esto puede haber estado justificado, pero los entornos de desarrollo modernos le permiten diseñar y analizar clases sin abandonar sus temas oscuros y claros.

Pero la aplicación práctica de Diagrama de clase aún permanece: diseño de base de datos:



si sabe qué son las bases de datos relacionales, entonces esto es más que obvio. Los atributos en el diagrama no firman por completo, solo se indican las relaciones, los tipos de datos y, a veces, las restricciones.

No intente dibujarlo en Visio, Enterprise Architect o equivalente. Para el diseño de bases de datos, existen muchas herramientas especializadas que se adaptan a DBMS específicos, úselas.

Eso es todo. De todos los diagramas en UML y Archimate, en la práctica, se enumeran más que suficientes. ¿Cuántos diagramas de cada tipo se necesitan para un proyecto? ¿Debo dibujarlos para cada proceso y subsistema? La regla principal es que el diagrama acompaña la descripción del texto, solo se necesita donde el texto no es suficiente, es decir donde el equipo no te entiende.

Gracias por su atención, había una compañía de productos de software con usted.

All Articles