Diagramas UML verdaderamente útiles

UML tiene una jungla de diagramas.
Diagramas de perfil, diagramas de clase, diagramas de paquetes ...

Sin embargo, (IMH-y-no-demasiado-experimentado-O) veo que hacer todos y cada diagrama es exagerado.

Por lo tanto, qué diagramas UML son más adecuados en un contexto web, más específicamente un blog (queremos construirlo desde cero).

_{Entiendo que solo porque use Diagramas UML no implica que nuestro código sea genial y brillante ... pero, ciertamente, sería mejor que solo código no planificado ...}

Como pauta general:

• Un diagrama de implementación para una visión general de la arquitectura (bueno para cualquier sistema)
• Un diagrama de caso de uso para obtener una descripción general de lo que los usuarios harán con el sistema (dito)
• Un diagrama de clase para el modelo de datos.
• Diagramas de actividad para el flujo de casos de uso individuales si son complejos
• Tal vez un diagrama de máquina de estado si tiene un flujo de trabajo de creación / revisión / publicación para entradas de blog

Algunos tipos de diagramas (p. Ej., Diagrama de tiempos) tienen usos bastante especializados, otros tienden a un nivel de detalle en el que el código real funciona mejor (p. Ej., Diagramas de secuencia), y otros parecen estar destinados a proyectos gigantes pero tienen una utilidad cuestionable incluso allí ( diagramas de paquetes? Cualquier IDE puede mostrarle sus paquetes).

El diagrama es menos importante que las conversaciones que tiene cuando comunica conceptos entre los distintos interesados ​​en un proyecto. Después de años de desarrollo de software, me encontré tratando de capturar información en forma de diagrama aún menos en los últimos años de lo que solía hacerlo cuando recién comenzaba. Hoy en día, podría elaborar algunos casos de uso simples en una pizarra cuando discuta conceptos, y a menudo recurriré a un diagrama de flujo simple pero clásico si estoy tratando de comprender cómo un cliente quiere que funcione un sistema. Si estoy particularmente preocupado, usaré la cámara de mi teléfono para capturar la imagen en la pizarra para ayudarme a recordar cosas específicas.

El diseño inicial muy documentado no es muy delgado. Desalienta el cambio y fija su pensamiento en torno a un solo plan de ataque que podría terminar totalmente mal para el proyecto en general. Desea poder diferir la mayor parte de su diseño hasta el último minuto para reducir las posibilidades de que un gran cambio arruine sus diseños y horarios más adelante. Esto no quiere decir que UML no deba usarse, sino que debe usarse con moderación, como un medio para mejorar la comunicación de conceptos, y no como un medio para definir los sistemas que tiene la intención de construir.

UML fue diseñado como un lenguaje de comunicación entre las personas involucradas. (programadores-programadores, programadores-gente de negocios, gente de negocios-usuarios) Las personas expresan sus modelos mentales en un lenguaje simple y unificado que todos entienden.

Debe preguntarse qué cantidad de esa comunicación necesita.

• ¿Es un software o producto interno que desea vender junto con la documentación?
• ¿Cuánto tiempo mantendrás el software? ¿Contratarás un programador para mantenerlo?
• ¿Qué tan ágil quieres ser? Puede perder tiempo haciendo una planificación demasiado detallada.
• ¿Qué cosas extrañas quieres hacer? Por lo general, no necesita documentar patrones comunes como el caso de uso detallado del registro o la arquitectura general de un blog.

Una regla general es hacer diagramas de alto nivel para darle una visión general y pasar tiempo en cosas complicadas o no tan comunes. Escribir / dibujar su modelo mental en UML lo obliga a comprenderlo completamente y resolver muchos errores antes de escribir una sola línea de código.

Necesita tantos como sea necesario para comprender y comunicar el sistema. Para el software de blogs, no creo que necesites muchos. Modele todo lo que necesite para comprender el sistema. Deje de modelar cuando deje de agregarle su comprensión.

Si es nuevo en UML, es posible que desee hacer algunos diagramas en detalle para aumentar su comprensión de los diagramas. Una vez que comprenda un tipo de diagrama lo suficientemente bien como para hacerlo en su mente, la necesidad de diagramas reales se vuelve menos.

Si fecha las versiones de su diagrama, le ayudará a juzgar si es probable que estén actualizadas. La comparación del diseño actual con los diagramas anteriores puede ser útil para determinar qué áreas del proyecto variaron significativamente del diseño original.

A menos que esté utilizando herramientas que generan el código de los diagramas o incrustan la especificación del diagrama en el código, es probable que no se sincronicen con el código. Los diagramas detallados tenderán a ser significativamente más incorrectos con el tiempo. que el diagrama general. Los diagramas generales también requerirán menos mantenimiento para mantenerlos actualizados.

Puede resultarle útil generar diagramas que:

• Describa a los actores y cómo usan el sistema.
• Resuma la estructura de los paquetes dentro del sistema. Tenga en cuenta qué paquetes contienen componentes reutilizables.
• Modele la estructura de la base de datos.
• Los diagramas de secuencia son útiles para diseñar componentes estándar. Si tiene muchos componentes similares, modele uno y úselo como patrón para los demás. Considere la reutilización del código en casos como este.

Genere diagramas que sean útiles en la planificación del proyecto. Si no es necesario un diagrama para comprender y / o comunicar algo sobre el proyecto, no pierda el tiempo en él. Siéntase libre de usar un diagrama que no sea UML si ayuda a comprender. UML puede no ser la mejor manera de modelar la base de datos.

Diría que debe adaptar los diagramas UML al nivel de modelado de todas las partes interesadas y al tiempo que tiene para completar el proyecto.

Si el equipo no conoce UML y no tiene tiempo, solo es posible el diagrama de clase que proviene del código invertido. Cada miembro puede agregar sus comentarios en el diagrama de clase que ya es una buena solución para la documentación. En este caso, el modelo es solo una vista gráfica del código. Esto cubriría casi el 90% de las necesidades de modelado si se realiza con cuidado y no agregará ningún tiempo adicional al proyecto.

Si tiene un conocimiento avanzado de las partes interesadas, todos los diagramas podrían aportar un valor real al proyecto para cubrir las necesidades completas del proyecto de modelado. Esto podría agregar un tiempo significativo a la entrega del proyecto, pero se espera que la calidad de la entrega sea mejor.

UML es genial, brillante y se puede adaptar a cualquier proyecto si se usa con moderación. No beba y conduzca, por ejemplo, al mismo tiempo :-)

Además de algunos diagramas de gran tamaño que se utilizarán para comunicar la arquitectura general de su aplicación en términos de servidores, capas o módulos grandes, no creo que pueda predecir qué diagramas necesitará de antemano.

Espera hasta el último momento responsable. Verás cuando los necesites . Por lo general, es

• durante una conversación con el cliente / dominio experto / analista, para aclarar un caso de uso
• o justo antes de comenzar a codificar, para desarrollar una primera versión de su diseño.

De todos modos, sus modelos probablemente se volverán obsoletos tan pronto como haya escrito algunas líneas de código u obtenga un primer comentario de los clientes, así que no se moleste en planear todo por adelantado o en pulir tanto sus diagramas.