No soy un profesional, y solo he usado UML con capacidad limitada en mis proyectos personales. Mi experiencia al tratar de usar UML estrictamente antes de la codificación tiende a enviar mis proyectos personales a un pozo de desesperación. Creo que esto se debe a tratar de diagramar ideas que aún no existen o que no se exploran adecuadamente.
They dicen "una imagen vale más que mil palabras". Mi interpretación de esto es que debes tener una idea en mente (o en palabras) antes de dibujarla. Un artista no dibuja un atardecer y luego decide dibujar un atardecer. Es al revés.
Los diagramas son una herramienta de documentación . La documentación es siempre tiempo pasado, lo que significa que cualquier documentación se refiere a las decisiones que ha tomado en el pasado. En mi experiencia, me pareció mejor documentar mis ideas por escrito y dibujar diagramas después. Al igual que el artista, debes decidir qué estás dibujando antes de poder diagramarlo. Si no sabes qué idea estás expresando, ¿cómo dibujas?
Los diagramas de casos de uso, por ejemplo, son un ejemplo de su decisión sobre qué funcionalidad debe esperar un usuario de su sistema. Los diagramas de clase son una representación gráfica de su decisión sobre la estructura de las clases de su programa y sus relaciones entre sí.
En el caso de los diagramas de clases, la elección de los nombres de los requisitos y la elaboración de un diagrama no es efectiva. ¿Cómo sabe si esas clases realmente admiten la funcionalidad necesaria para respaldar los casos de uso?Estudiar el sistema, separar las ideas en módulos, anotar las decisiones sobre las interacciones de los módulos y escribir algunas clases iniciales (o al menos sus interfaces) solidifica sus ideas. Documentar esas ideas en un diagrama simplemente facilita que las personas capten rápidamente las decisiones que usted tomó.
Si comete un diagrama de base de datos, digamos que para un sistema de compra, debe tomar la decisión de que una orden tiene muchos elementos de línea antes de crear un diagrama que muestra eso.
En efecto, lo que estoy tratando de decir es que creo que los diagramas son del pasado como toda la documentación. Tienes una idea; lo anotas y eso es documentación. Usted tiene documentación; dibuja una imagen para que sea más fácil de entender. Creo que es mejor crear diagramas después de analizar el problema y crear un modelo mental y escrito. Ya sea que usted agregue incrementos al diagrama después de tomar cada decisión, o construya un diagrama completo después de haber tomado varias decisiones, depende de usted. Hacer diagramas de ideas antes de tenerlas, o antes de que las entiendas, creo que solo te llevan a la angustia.
Vale la pena señalar que la mayoría de los IDE tienen algún generador de diagramas UML. Por ejemplo, Visual Studio le permite seleccionar archivos de origen y generar diagramas de clase UML al instante. Obviamente, primero necesitas el código. VS en contraste (no estoy seguro acerca de otras herramientas) también le permite producir código de UML, aunque las funciones/clases de plantilla. – Finglas