Unified Modeling Language (UML)

Índice

1. UML

  • Lenguaje Unificado de Modelado
  • Conjunto de diagramas para modelar y documentar un sistema software
    • Misma idea que los diagramas E-R de base de datos.
  • Es un estándar de facto
  • Su origen es la fusión de varios métodos orientación a objetos:
    • OMT - Object Modeling Technique (Jim Rumbaugh et al.).
    • Método-Booch (Grady Booch).
    • OOSE - Object-Oriented Software Engineering (Ivar Jacobson) .

1.1. Por qué modelar

  • Mejor documentación
    • Un diagrama es más rápido de entender que un texto largo
    • Un diagrama suele ser menos ambiguo que un texto
    • Permite la comunicación efectiva entre miembros del equipo
  • Desarrollo rápido
    • Más rápido que la implementación en código
    • Algunas herramientas permiten generar código a partir de los diagramas

1.2. Cuándo modelar

  • Ingeniería directa
    • Se diseña el sistema usando (entre otros) diagramas UML
    • Después se implementa
  • Ingeniería inversa
    • Se estudia un sistema ya existente
    • Se crean diagramas UML para mejorar la comprensión

1.3. Tipos de diagramas

  • Diagramas de clases
  • Diagramas de casos de uso
  • Diagramas de

1.4. Herramientas

  • Lápiz y papel
  • Plantuml y UMLet
  • Prácticamente cualquier herramienta de diagramas

2. Diagramas de clases

  • Rectángulo: una clase
    • Cada línea es un método o atributo
    • # para protegido, + para público, - para privado
  • Línea: relación entre clases (una referencia)
    • Cardinalidad: como en E-R
    • Con triángulo: herencia
    • Con rombo hueco: agregación (tiene varias instancias)
    • Con rombo lleno: composición (se compone de varias instancias, similar a una entidad débil E-R)

2.1. Ejemplo con PlantUML

leyenda-clases.svg

2.2. Ejemplo:

  • Un curso está compuesto por varias asignaturas.
  • Cada alumno pertenece a un único curso, aunque un curso puede tener muchos alumnos.
  • Un profesor puede impartir varias asignaturas, y una asignatura puede ser impartida por un único profesor.
  • Las asignaturas se dividen en dos tipos: teóricas y prácticas, utilizando herencia.
  • Un alumno se matricula en asignaturas mediante una matrícula.
  • La matrícula representa la relación entre un alumno y el conjunto de asignaturas en las que está inscrito.
  • Las calificaciones de un alumno en cada asignatura se almacenan en una clase llamada Nota.
  • Cada matrícula debe permitir:
    • Registrar una calificación para una asignatura (setNota(asignatura, valor)).
    • Consultar la calificación de una asignatura (getNota(asignatura)).

2.3. Ejercicio

  • Una empresa quiere manejar el stock de un almacén
  • Cada venta indica qué productos incluye, y la cantidad de cada uno, y a qué precio
  • Cada entrada en el almacén indica qué productos incluye, y la cantidad de cada uno
  • El gestor del almacén se encarga de que no haya ventas que sobrepasen el stock de ningún producto
  • El gestor aumenta el stock con cada entrada, y lo disminuye con cada venta
  • Se puede preguntar a una venta por su importe

2.3.1. solución

stock-almacen.svg

2.4. Ejercicio

  • Un procesador de textos maneja documentos compuestos de párrafos.
  • Un párrafo puede contener texto o ser una imagen.
  • Un párrafo de texto contiene cadenas, que van una detrás de otra.
  • Un párrafo puede tener alineación izquierda, derecha o centrada.
  • Una cadena puede tener negrita, cursiva, subrayado.
  • Cada cadena tiene un tipo de letra (arial, cursiva…) y un tamaño. Si no se especifica, toman los valores por defecto del documento.

2.4.1. solución

procesador-de-texto.svg

2.5. Ejercicio

  • Un sistema de ficheros tiene ficheros y carpetas
  • Una carpeta puede contener otros ficheros y carpetas
  • Tanto ficheros como carpetas tienen:
  • Los ficheros y carpetas
    • Se pueden renombrar
    • Se pueden copiar (las carpetas se copian recursivamente)
    • Se pueden borrar
  • Los ficheros tienen un contenido, que es una cadena de texto

3. Diagramas de casos de uso

  • Se representan
    • Actores: usuarios u otros sistemas externos que interaccionan con nuestro sistema
    • Responsabilidades/acciones de nuestro sistema
  • Sirven para
    • Saber qué tiene que hacer el sistema
    • Saber quién es el responsable de iniciar una acción, o quién puede hacerla, o a quién hay que notificar resultados
  • No suelen ser útiles para la codificación
    • Pero sí para delimitar el alcance de la aplicación

3.1. Nomenclatura

nomemclatura-casos-de-uso.svg

3.2. Ejemplo

  • La máquina de vending da productos a los clientes
  • Los clientes pueden consultar el precio de los productos
  • Los productos se pueden cobrar mediante tarjeta de crédito o con monedas
  • Un empleado puede
    • Abrir la máquina para reponer productos
    • Cambiar los precios de los productos
  • Un empleado, como cualquier otra persona, puede comprar productos y consultar precios

3.2.1. solución

vending.svg

3.3. Refinamiento

  • Los casos de uso se pueden refinar o explotar

vending-refinado-reponedor.svg

3.4. Ejercicio

  • Un usuario puede darse de alta y crear documentos en la web, y modificar sus propios documentos
  • Un usuario puede ver los documentos de otros usuarios
  • Un gestor también puede revisar los documentos de otros usuarios y sugerir cambios en forma de notas
  • Un administrador puede hacer lo que un gestor, y además
    • dar de baja a cualquier usuario
    • cambiar los datos de cualquier usuario
    • Borrar documentos, tras revisar su contenido

3.4.1. solución

documentos-web.svg

3.5. Ejemplo

  • Si un usuario tiene problemas, puede abrir una incidencia
  • El técnico puede decidir no gestionar la incidencia si está fuera del contrato de soporte, y cerrarla
  • El técnico trabaja en la incidencia, y la cierra cuando está resuelta y el usuario está de acuerdo
  • Si el usuario no está conforme, puede pedir una elevación (escalation) del problema. Se crea una incidencia asociada a la indicencia original.
  • El técnico puede elevar el problema a un especialista si no está formado para ello. Se crea una incidencia asociada a la indicencia original.
  • El especialista trata las incidencias elevadas como una incidencia normal (excepto que no puede elevarlas)

3.5.1. solución

soporte-tecnico.svg

3.6. Ejemplo

  • Foro
    • Los usuarios se registran. Para ello pueden validarse con SMS o con correo electrónico
    • Un administrador revisa el registro, para darlo de alta
    • Una vez registrados, pueden leer los hilos, pero no pueden escribir nuevos, solo responder a los ya escritos
    • Si un usuario tiene suficientes aportaciones, se promueve a "Escritor", que ya puede crear hilos
    • Un usuario puede ser "baneado" si no sigue las normas, por un administrador. Todos los usuarios pueden reportar a otros usuarios, para que el administrador decida si se "banea" o no

3.6.1. Solución 1

foro-1.svg

3.6.2. Solución 2

foro-2.svg

4. Diagramas de actividad

leyenda-actividad.svg

4.1. Ejemplo

arresto-cardiaco-pediatrico.jpg

4.2. Ejemplo

insuficiencia-renal-aguda.png

4.3. Ejercicio

  • Al llegar una orden de salida de productos del almacén, se separa en productos refrigerados y no refrigerados.
  • Los productos refrigerados y no refrigerados se localizan y empaquetan por separado.
  • Si durante el empaquetado falta algún producto, se crea una orden de reposición al proveedor, y se espera a que el producto llegue
  • Cuando estén todos los productos, se sacan del almacén

4.4. Ejercicio

  • Una agencia de viajes permite buscar por un vuelo entre dos aeropuertos
  • Tras especificar origen y destino, se busca simultáneamente en varios proveedores y mayoristas
  • Cuando acaba la búsqueda, se contacta con el cliente para comunicarle las ofertas
  • cuando el usuario elige una oferta, se contacta con el proveedor indicado para reservar el vuelo
  • si la oferta ya no está disponible, se ofrece la posibilidad al usuario de elegir otro vuelo o recomenzar la búsqueda

5. Vigencia de UML

  • UML es comparable a los diagramas E-R
  • No se usa mucho de forma "oficial" en las empresas
  • Pero es muy útil para aclaraciones en reuniones y documentación de requisitos complicados

5.1. Ejemplo

insuficiencia-renal-aguda.png

5.2. Ejemplo

arresto-cardiaco-pediatrico.jpg

6. Referencias

Autor: Álvaro González Sotillo

Created: 2026-05-21 jue 10:13

Validate