Unified Modeling Language (UML)

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

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

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

2.5. Ejercicio

• Un sistema de ficheros tiene ficheros y carpetas
• Una carpeta puede contener otros ficheros y carpetas
• Tanto ficheros como carpetas tienen:
  • un nombre
  • permisos tipo linux (rwxrwxr)
• 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

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

3.3. Refinamiento

• Los casos de uso se pueden refinar o explotar

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

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

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

3.6.2. Solución 2

4. Diagramas de actividad

4.1. Ejemplo

4.2. Ejemplo

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

5.2. Ejemplo

5.3. Ejemplo

Manual de permisos y licencias

6. Referencias

• Formatos:
  • Transparencias
  • PDF
  • Página web
  • EPUB
• Alojado en Github