UML LENGUAJE
El Lenguaje Unificado de Modelado fue creado en 1997 por Grady Booch, Ivar Jacobson y James Rumbaugh ("los tres amigos") en Rational Software, luego estandarizado por la OMG. UML es un lenguaje, no una metodología: describe qué modelar, no cómo proceder. Versión actual: UML 2.5.1.
PURPOSE ¿Para qué sirve UML?
- Visualizar la estructura y comportamiento de un sistema
- Especificar requerimientos y arquitectura de forma precisa
- Construir modelos que guíen la implementación
- Documentar decisiones de diseño para el equipo
HISTORY Los Tres Amigos
Booch (Booch Method), Jacobson (OOSE — Casos de Uso) y Rumbaugh (OMT) unificaron sus notaciones en 1994–1997. UML adoptó los Casos de Uso de Jacobson como artefacto central, el foco en objetos de Booch y el análisis estructural de Rumbaugh.
ARQUITECTURA 4+1 VISTAS — Philippe Kruchten, 1995
| Vista | Alias | Stakeholder principal | Diagramas típicos | Pregunta que responde |
| Casos de Uso (+1) | Escenarios | Cliente, Usuario final | Casos de Uso | ¿Qué hace el sistema? |
| Lógica | Diseño | Analista, Diseñador | Clases, Secuencia, Estado | ¿Cómo está estructurado? |
| Procesos | Dinámica | Integrador de sistemas | Actividad, Secuencia | ¿Cómo se comporta en tiempo real? |
| Implementación | Componentes | Programador | Componentes, Paquetes | ¿Cómo se organiza el código? |
| Despliegue | Física | Operaciones / DevOps | Despliegue | ¿En qué hardware corre? |
14 TIPOS DE DIAGRAMAS UML 2.x
ESTRUCTURALES (7)
- Clases — estructura estática
- Objetos — instancias en un momento
- Componentes — módulos de software
- Despliegue — hardware y software
- Paquetes — agrupación lógica
- Estructura compuesta — partes internas
- Perfil — extensiones UML
COMPORTAMIENTO (7)
- Casos de Uso — requerimientos
- Actividad — flujo de trabajo
- Estado — ciclo de vida
- Secuencia — interacción temporal
- Comunicación — interacción estructural
- Tiempos — restricciones temporales
- Visión general interacción
Casos de Uso REQUERIMIENTOS
Un Caso de Uso (UC) es una secuencia de acciones que el sistema realiza para producir un resultado de valor observable para un actor. Captura el qué sin entrar en el cómo. Ivar Jacobson introdujo este concepto en OOSE (1992).
ACTOR Definición y reglas
- Rol externo al sistema (persona, software, hardware)
- No es parte del sistema — está fuera del límite
- Se representa como figura de palo con nombre
- Puede haber herencia: Administrador extiende Usuario
- Actor primario: inicia el UC · Secundario: apoya
CASO DE USO Nomenclatura
- Elipse con nombre en verbo infinitivo
- Ejemplo: "Registrar Venta", "Consultar Saldo"
- Representa una meta completa del usuario
- Vive dentro del rectángulo del sistema
- Tiene un flujo principal + flujos alternativos
Regla de oro — «include» vs «extend»
«include»: el comportamiento incluido es SIEMPRE necesario para que el caso base funcione. El caso base está INCOMPLETO sin él. La flecha va del base al incluido.
«extend»: el comportamiento extendido solo ocurre BAJO CONDICIONES ESPECÍFICAS. El caso base es FUNCIONALMENTE COMPLETO sin la extensión. La flecha va de la extensión al base.
| Relación | Tipo flecha | Dirección | El base sin ella… | Ejemplo |
|---|
| «include» |
Discontinua punta abierta |
Base → Incluido |
Está incompleto |
Pagar Pedido «include» Verificar Stock |
| «extend» |
Discontinua punta abierta |
Extensión → Base |
Es completo |
Aplicar Descuento «extend» Pagar Pedido |
| Asociación |
Línea sólida |
Actor ↔ UC |
— |
Cliente — Realizar Compra |
| Generalización |
Flecha sólida punta cerrada |
Hijo → Padre |
— |
Pagar con Tarjeta → Pagar Pedido |
RUP METODOLOGÍA
El Rational Unified Process es un marco de proceso iterativo, incremental y centrado en la arquitectura. Desarrollado por Rational Software (Grady Booch, Philippe Kruchten). El esfuerzo se distribuye de forma desigual: la Elaboración define la arquitectura y es el corazón técnico del proyecto.
FASE 1
Inicio
Viabilidad, alcance, riesgos críticos, modelo de negocio inicial. Decisión go/no-go.
FASE 2
Elaboración
Línea base de arquitectura. UC de alto riesgo. Prototipos ejecutables del núcleo. ~30% del esfuerzo total.
FASE 3
Construcción
Desarrollo masivo de flujos de menor riesgo. Versiones beta funcionales.
FASE 4
Transición
Pruebas de aceptación, capacitación y despliegue en producción.
9 FLUJOS DE TRABAJO (WORKFLOWS)
CORE WORKFLOWS
- Modelado de negocio — contexto organizacional
- Requerimientos — UC y requerimientos no funcionales
- Análisis y Diseño — arquitectura y colaboraciones
- Implementación — código, componentes
- Pruebas — casos de prueba, integración
- Despliegue — instalación en producción
SUPPORT WORKFLOWS
- Gestión de configuración y cambios
- Gestión del proyecto — planificación, riesgos
- Entorno — herramientas, procesos del equipo
Principio clave de RUP
RUP no prescribe un único proceso — es un framework configurable. Cada organización adapta qué artefactos producir, qué workflows activar y con qué intensidad. Un proyecto pequeño puede omitir el workflow de "Modelado de negocio" sin problemas.
Modelo de Dominio ANÁLISIS
Representación visual de las clases conceptuales del dominio del problema. Es un artefacto de análisis, no de diseño: no hay métodos, no hay código — solo sustantivos del mundo real con sus atributos y relaciones. Es la base para construir el Diagrama de Clases de Diseño.
PROHIBIDO Lo que NO va aquí
- Métodos / operaciones de las clases
- Clases de software (Controller, DAO, Service…)
- Tipos de dato Java/C# (String, int)
- Detalles de implementación de base de datos
PERMITIDO Contenido válido
- Clases conceptuales: Libro, Cliente, Préstamo
- Atributos: isbn, fechaDevolucion, nombre
- Asociaciones con nombre de relación (verbo)
- Multiplicidad en cada extremo de la relación
- Asociaciones de herencia cuando existe generalización real
TIPOS DE ASOCIACIÓN
| Tipo | Notación UML | Significado | Ejemplo |
|---|
| Asociación simple | Línea sólida | Relación entre iguales | Empleado — Proyecto |
| Agregación | Rombo vacío en el "todo" | Todo/Parte, parte puede existir sola | Departamento ◇— Empleado |
| Composición | Rombo relleno en el "todo" | Parte no puede existir sin el todo | Pedido ◆— LineaPedido |
| Generalización | Flecha punta cerrada vacía | Herencia conceptual (es-un) | Perro → Animal |
MULTIPLICIDADES COMUNES
| Notación | Significado | Ejemplo en español |
|---|
| 1 | Exactamente uno | Un empleado tiene exactamente 1 número de seguridad social |
| 0..1 | Cero o uno (opcional) | Un empleado puede tener 0 o 1 auto de empresa |
| 1..* | Uno o más (al menos uno) | Un pedido tiene 1 o más líneas de pedido |
| 0..* ó * | Cero o más (cualquiera) | Un cliente puede tener 0 o más pedidos |
| m..n | Entre m y n | Un equipo tiene entre 3 y 12 miembros |
DSS PUENTE ANÁLISIS-DISEÑO
El Diagrama de Secuencia del Sistema muestra las interacciones de los actores con el sistema sin revelar la estructura interna. Es el primer paso para identificar las operaciones del sistema a partir de los Casos de Uso.
REGLA Caja negra
El sistema aparece como un único objeto :Sistema. No se muestran clases internas, ni la división BCE. Eso ocurre en el Diagrama de Secuencia de Diseño posterior.
SINTAXIS Nombrado de eventos
- Nombre en camelCase como operación
- Parámetros relevantes entre paréntesis
- Ejemplo:
introducirArticulo(idProducto, cantidad)
- Retornos con línea punteada y nombre descriptivo
- Bucles y condiciones con fragmentos combinados [loop] [alt]
Elementos del DSS
Línea de vida: línea vertical discontinua que representa la existencia de un participante (actor o sistema) a lo largo del tiempo.
Activación: rectángulo estrecho sobre la línea de vida que indica que el objeto está ejecutando una operación en ese instante.
Eje temporal: de arriba hacia abajo — el orden vertical es el orden cronológico de los eventos.
Fragmentos combinados: recuadros con etiqueta [alt], [loop], [opt] para modelar condicionales y ciclos.
Estereotipos BCE ARQUITECTURA
El patrón Boundary-Control-Entity de RUP separa responsabilidades en tres capas bien definidas. Es la aplicación del principio MVC a nivel de clases de análisis/diseño. La regla de comunicación es estricta y obligatoria.
Boundary
≡ View / UI
Interacción con actores externos o sistemas externos. Formularios, pantallas, APIs externas, reportes.
→
Control
≡ Controller
Lógica de coordinación y flujo de la aplicación. Orquesta boundary y entity. No almacena datos persistentes.
→
Entity
≡ Model
Información persistente y lógica de negocio pura. Clases del modelo de dominio promovidas a clases de diseño.
| Estereotipo | Símbolo UML | Responsabilidades | Ejemplos | Comunicación permitida |
|---|
| Boundary |
Círculo con línea a la izquierda |
Entrada/salida con actores, presentación, validación superficial |
LoginForm, ReporteVentas, APIREST |
Habla con: Control (solo) |
| Control |
Círculo con flecha circular arriba |
Flujo de caso de uso, decisiones de negocio, coordinación |
GestorPedido, ControladorLogin |
Habla con: Boundary y Entity |
| Entity |
Círculo con línea abajo |
Datos persistentes, reglas de negocio puras, validaciones de dominio |
Pedido, Cliente, Producto |
Habla con: Entity (solo) |
Regla de comunicación BCE — NUNCA violar
Actor solo habla con Boundary · Boundary solo habla con Control · Control habla con Boundary y Entity · Entity solo habla con Entity.
Un Actor nunca va directamente a Entity. Un Boundary nunca va directamente a Entity. Un Entity nunca inicia comunicación con Control o Boundary.
Diagramas de Interacción DISEÑO
Los diagramas de interacción muestran cómo colaboran los objetos para completar un caso de uso. Existen dos variantes que muestran la misma información desde diferente perspectiva: temporal (secuencia) y estructural (comunicación).
SECUENCIA Foco temporal
- Objetos en columnas, tiempo avanza hacia abajo
- Línea de vida: línea vertical discontinua por objeto
- Activación: rectángulo estrecho sobre línea de vida
- Mensajes: flechas horizontales de izquierda a derecha
- Retorno: línea punteada (opcional pero recomendable)
- Fragmentos: [alt], [loop], [opt], [par] para flujos complejos
- Mensajes síncronos: flecha rellena · Asíncronos: flecha abierta
COMUNICACIÓN Foco estructural
- Objetos ubicados libremente en el espacio 2D
- Sin eje de tiempo vertical
- Mensajes DEBEN ir numerados: 1, 1.1, 1.1.1, 2…
- La numeración jerarquizada indica anidamiento de llamadas
- Flecha de dirección en cada mensaje con número
- Más compacto para mostrar relaciones entre objetos
- Menos claro para mostrar el orden temporal exacto
¿Cuándo usar cada uno?
Usa el Diagrama de Secuencia cuando necesitas mostrar claramente el orden cronológico de los mensajes y la duración de las activaciones — ideal para documentar el flujo de un caso de uso paso a paso.
Usa el Diagrama de Comunicación cuando quieres enfatizar qué objetos están conectados entre sí y cuántos mensajes intercambian — ideal para validar la arquitectura de objetos y detectar acoplamiento excesivo.
| Característica | Secuencia | Comunicación |
|---|
| Eje de tiempo | Sí — vertical, top-down | No — orden por numeración |
| Numeración | Opcional (posición implica orden) | Obligatoria (1, 1.1, 2…) |
| Énfasis | ¿Cuándo? — temporal | ¿Quién? — estructural |
| Fragmentos combinados | Sí [alt] [loop] [opt] | Condiciones en etiqueta del mensaje |
| Claridad para bucles | Alta | Media |
| Compacidad | Media — crece verticalmente | Alta — todo en 2D |
FURPS+ NO FUNCIONALES
Clasificación estándar de requerimientos no funcionales propuesta por Grady Booch. Complementa a los Casos de Uso (que capturan funcionales). El símbolo "+" agrega categorías adicionales como restricciones de diseño, implementación, interfaz y físicas. Es compatible con ISO 25010.
| Letra | Categoría | Subcategorías | Ejemplo concreto |
|---|
| F |
Functionality |
Capacidades, Seguridad, Interoperabilidad |
"El sistema debe soportar autenticación OAuth 2.0" |
| U |
Usability |
Factores humanos, Documentación, Consistencia UI |
"Un usuario nuevo debe completar su registro en menos de 3 minutos" |
| R |
Reliability |
Frecuencia de fallos (MTBF), Recuperabilidad, Disponibilidad |
"El sistema debe tener disponibilidad del 99.9% mensual" |
| P |
Performance |
Velocidad de respuesta, Throughput, Uso de CPU/Memoria |
"La consulta de catálogo debe responder en < 2 segundos con 500 usuarios concurrentes" |
| S |
Supportability |
Mantenibilidad, Configurabilidad, Testabilidad |
"Nuevas reglas de descuento deben ser configurables sin recompilar" |
| + |
Restricciones adicionales |
Diseño, Implementación, Interfaz, Físicas, Legales |
"Debe cumplir con la Ley Federal de Protección de Datos de México (LFPDPPP)" |
ISO 25010 Equivalencias
- Functionality → Adecuación funcional
- Usability → Usabilidad
- Reliability → Fiabilidad
- Performance → Eficiencia de desempeño
- Supportability → Mantenibilidad + Portabilidad
RESTRICCIONES "+" Tipos
- Diseño: "usar arquitectura MVC"
- Implementación: "desarrollar en Java 17"
- Interfaz: "integrarse con SAP vía REST"
- Físicas: "ejecutarse en hardware de 4GB RAM"
- Legales: "cumplir GDPR / LFPDPPP"