![\"\"](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6aba16348678d.png\")
<\/p>\nEl UML es m\u00e1s \u00fatil cuando mejora la comunicaci\u00f3n y la toma de decisiones, no cuando se convierte en un ejercicio de documentaci\u00f3n. Un equipo rara vez necesita todos los tipos de diagramas UML. En la mayor\u00eda de los proyectos, siete tipos de diagramas proporcionan una base s\u00f3lida:<\/p>\n
<\/p>\n
Diagramas de casos de uso<\/p>\n<\/li>\n
Diagramas de actividad<\/p>\n<\/li>\n
Diagramas de secuencia<\/p>\n<\/li>\n
Diagramas de clases<\/p>\n<\/li>\n
Diagramas de componentes<\/p>\n<\/li>\n
Diagramas de despliegue<\/p>\n<\/li>\n
Diagramas de m\u00e1quinas de estado<\/p>\n<\/li>\n<\/ol>\n
Juntos, estos diagramas describen el sistema desde perspectivas complementarias:<\/p>\n
![\"\"](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6aba168046439.png\")
<\/p>\n
Objetivos:<\/strong> Lo que los usuarios y los sistemas externos necesitan<\/p>\n<\/li>\n Comportamiento:<\/strong> C\u00f3mo fluye el trabajo a trav\u00e9s del sistema<\/p>\n<\/li>\n Interacci\u00f3n:<\/strong> C\u00f3mo colaboran los objetos y los servicios<\/p>\n<\/li>\n Estructura:<\/strong> Qu\u00e9 entidades y relaciones existen<\/p>\n<\/li>\n Arquitectura:<\/strong> C\u00f3mo se organizan las partes principales del software<\/p>\n<\/li>\n Operaciones:<\/strong> D\u00f3nde se ejecuta el sistema<\/p>\n<\/li>\n Ciclo de vida:<\/strong> C\u00f3mo cambian los objetos importantes con el tiempo<\/p>\n<\/li>\n<\/ul>\n El objetivo no es crear un diagrama para cada posible preocupaci\u00f3n. El objetivo es crear el conjunto m\u00e1s peque\u00f1o y coherente de modelos que responda a las preguntas que realmente tienen las partes interesadas.<\/p>\n El UML efectivo m\u00ednimo es una estrategia de modelado basada en cuatro principios:<\/p>\n Modelar para una decisi\u00f3n:<\/strong> Crear un diagrama porque aclara un requisito, una elecci\u00f3n de dise\u00f1o, un riesgo o un detalle de implementaci\u00f3n.<\/p>\n<\/li>\n Utilizar la notaci\u00f3n m\u00e1s simple adecuada:<\/strong>Evite s\u00edmbolos, decoraciones y detalles innecesarios.<\/p>\n<\/li>\n Mantenga la trazabilidad:<\/strong>Conecte los requisitos con el comportamiento, la estructura, el c\u00f3digo, las pruebas y el despliegue cuando sea pr\u00e1ctico.<\/p>\n<\/li>\n Mantenga los diagramas comprensibles:<\/strong>Un diagrama que contiene todo a menudo no comunica nada.<\/p>\n<\/li>\n<\/ul>\n Un modelo \u00fatil debe ayudar a responder preguntas como:<\/p>\n \u00bfQui\u00e9n interact\u00faa con el sistema?<\/p>\n<\/li>\n \u00bfQu\u00e9 capacidades debe proporcionar el sistema?<\/p>\n<\/li>\n \u00bfQu\u00e9 pasos componen un proceso de negocio?<\/p>\n<\/li>\n \u00bfQu\u00e9 objeto o servicio es responsable de cada acci\u00f3n?<\/p>\n<\/li>\n \u00bfQu\u00e9 datos y conceptos del dominio deben representarse?<\/p>\n<\/li>\n \u00bfC\u00f3mo se dividen los subsistemas?<\/p>\n<\/li>\n \u00bfD\u00f3nde se despliegan las aplicaciones, las bases de datos y los servicios externos?<\/p>\n<\/li>\n \u00bfC\u00f3mo transita una entidad importante a trav\u00e9s de su ciclo de vida?<\/p>\n<\/li>\n<\/ul>\n Si un diagrama no ayuda a responder una de estas preguntas, es posible que no sea necesario.<\/p>\n Estos diagramas no son independientes. Forman una cadena:<\/p>\n \u00a0<\/p>\n Casos de uso \u27f6 Actividades \u27f6 Secuencias \u27f6 Clases y Componentes \u27f6 Despliegue<\/span>Usar<\/span>\u00a0Casos<\/span><\/span><\/span>\u27f6<\/span><\/span><\/span>Actividades<\/span><\/span><\/span>\u27f6<\/span><\/span><\/span>Secuencias<\/span><\/span><\/span>\u27f6<\/span><\/span><\/span>Clases<\/span>\u00a0y<\/span>\u00a0Componentes<\/span><\/span><\/span>\u27f6<\/span><\/span><\/span>Despliegue<\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/section>\n \u00a0<\/p>\n<\/div>\n<\/div>\n Los diagramas de m\u00e1quinas de estado atraviesan esta cadena al describir el ciclo de vida de objetos que tienen estados significativos.<\/p>\n Por ejemplo, un pedido en l\u00ednea puede representarse de la siguiente manera:<\/p>\n Caso de uso:<\/strong> Realizar un pedido<\/p>\n<\/li>\n Actividad:<\/strong> Validar carrito, autorizar pago, reservar stock, confirmar pedido<\/p>\n<\/li>\n Secuencia:<\/strong> La interfaz de cliente llama al servicio de pedidos, servicio de pagos y servicio de inventario<\/p>\n<\/li>\n Clase:<\/strong> Componente:<\/strong> Aplicaci\u00f3n web, servicio de pedidos, adaptador de pagos, servicio de inventario<\/p>\n<\/li>\n Despliegue:<\/strong> Navegador, cl\u00faster de aplicaciones, base de datos, proveedor de pagos<\/p>\n<\/li>\n M\u00e1quina de estado:<\/strong> Borrador \u2192 Pago pendiente \u2192 Pagado \u2192 Enviado \u2192 Entregado<\/p>\n<\/li>\n<\/ul>\n Un diagrama de casos de uso presenta el sistema desde el exterior. Identifica los actores que interact\u00faan con el sistema y los objetivos que persiguen.<\/p>\n Los elementos principales son:<\/p>\n L\u00edmite del sistema:<\/strong> Define qu\u00e9 est\u00e1 dentro del sistema que se est\u00e1 modelando<\/p>\n<\/li>\n Actores:<\/strong> Personas, organizaciones, dispositivos o sistemas externos<\/p>\n<\/li>\n Casos de uso:<\/strong> Objetivos o servicios que proporciona el sistema<\/p>\n<\/li>\n Asociaciones:<\/strong> Conexiones entre actores y casos de uso<\/p>\n<\/li>\n Relaciones de inclusi\u00f3n:<\/strong> Comportamiento reutilizable requerido por otro caso de uso<\/p>\n<\/li>\n Relaciones de extensi\u00f3n:<\/strong> Comportamiento opcional o condicional<\/p>\n<\/li>\n<\/ul>\n Ejemplo:<\/p>\n1. Qu\u00e9 significa “UML Efectivo M\u00ednimo”<\/h2>\n
\n
\n
2. El n\u00facleo de los siete diagramas<\/h2>\n
\n\n
\n \nDiagrama<\/th>\n Pregunta principal<\/th>\n Audiencia principal<\/th>\n Fase t\u00edpica del proyecto<\/th>\n<\/tr>\n<\/thead>\n \n Caso de uso<\/td>\n \u00bfQui\u00e9n necesita qu\u00e9 del sistema?<\/td>\n Clientes, analistas, propietarios del producto<\/td>\n Requisitos<\/td>\n<\/tr>\n \n Actividad<\/td>\n \u00bfC\u00f3mo fluye el trabajo?<\/td>\n Analistas, dise\u00f1adores, desarrolladores, probadores<\/td>\n Requisitos y dise\u00f1o de procesos<\/td>\n<\/tr>\n \n Secuencia<\/td>\n \u00bfC\u00f3mo colaboran los participantes a lo largo del tiempo?<\/td>\n Desarrolladores, arquitectos, probadores<\/td>\n Dise\u00f1o detallado<\/td>\n<\/tr>\n \n Clase<\/td>\n \u00bfQu\u00e9 conceptos, datos y relaciones existen?<\/td>\n Desarrolladores, analistas, arquitectos<\/td>\n Dise\u00f1o de dominio y software<\/td>\n<\/tr>\n \n Componente<\/td>\n \u00bfC\u00f3mo se divide el sistema en partes principales?<\/td>\n Arquitectos, desarrolladores, equipos de operaciones<\/td>\n Arquitectura<\/td>\n<\/tr>\n \n Despliegue<\/td>\n \u00bfD\u00f3nde se ejecuta el software?<\/td>\n Arquitectos, DevOps, operaciones, equipos de seguridad<\/td>\n Despliegue y operaciones<\/td>\n<\/tr>\n \n M\u00e1quina de estados<\/td>\n \u00bfC\u00f3mo cambia una entidad con el tiempo?<\/td>\n Desarrolladores, analistas, probadores<\/td>\n Dise\u00f1o del ciclo de vida<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \n\n\n\n\n\n\n\n\n\n\n\n\n
Pedido<\/code>, L\u00ednea de pedido<\/code>, Pago<\/code>, y Producto<\/code><\/p>\n<\/li>\n3. Diagramas de casos de uso: Definici\u00f3n de objetivos del sistema<\/h2>\n
3.1 Qu\u00e9 contiene un diagrama de casos de uso<\/h3>\n
![\"\"](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6aba17707eb25.png\")
<\/p>\n\n
![\"\"](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6aba187c4326c.png\")
<\/p>\n\n\nPlantUML<\/span>
\n
\n