Ingeniería del Software 1 Modelado Funcional 2024-2025 PDF

INGENIERÍA DEL SOFTWARE 1 CURSO 2024-2025 Modelado Funcional Introducción a los Casos de Uso Miguel Alemán, Agustín Salgado, Ana Plácido  Conceptos 2 Caso de uso Asociación Escenario Requisito Generalización Funcionalidad Extensión CRUD...

INGENIERÍA DEL SOFTWARE 1 CURSO 2024-2025 Modelado Funcional Introducción a los Casos de Uso Miguel Alemán, Agustín Salgado, Ana Plácido  Conceptos 2 Caso de uso Asociación Escenario Requisito Generalización Funcionalidad Extensión CRUD Punto de extensión Report Especificación Precondición Inclusión Postcondición Abstracción Variante Sistema Excepción Actor Manejo de excepciones Asociación Paso Negocio Flujo normal Sujeto Flujo alternativo  Desarrollo de productos 3 Idea Modelo Producto Necesidades Modelo Aplicación ◼ Neces1 ◼ Neces2 ◼ Neces3 https://www.imagui.com/a/foto-casa-TbKaGERbL  Creación de modelos 4 1. Necesidades del producto 2. Trasladarla en un modelo https://picale.mx/2020/09/08/asi-puedes-ahorrar-y-comprar-tu-primera-casa/ Antes de construir el producto demandado por el cliente es necesario realizar un modelo que refleje las necesidades y restricciones.  Diagramas en UML 5 Unified Modeling Language  Diagramas en UML 6 Unified Modeling Language  Tipos de Diagrama 7 Comportamiento vs Estructura ¿Para qué se usa? ¿Qué elementos hay? Cortar Tijeras Limar Destornillador Abrir Botella Cuchillo Ampliar Lima Atornillar Sacatapas Desatornillar Gancho Medir Regla … Lupa … Diagrama de Diagrama de Casos de Uso (DCU) Clases (DC)  Diagrama de casos de uso 8 ParkApp Sacar Tique Usuario Renovar Tique Es un diagrama que representa la funcionalidad de la aplicación.  Funcionalidad 9 ¿Para qué se usa? Calentar Descongelar Gratinar ¿Seleccionar tiempo? ¿Seleccionar intensidad? ¿Abrir puerta?  Ejemplo de funcionalidad 10  Proceso de elaboración de un DCU 11 1. Identificar actores. 2. Identificar las funciones principales. 3. Analizar la funcionalidad buscando elementos comunes y opcionales. 4. Clasificar y estructurar la funcionalidad. 5. Especificar los casos de uso explicando de forma detallada el flujo de interacción actor-sistema.  Identificación de actores 12 ◼ Identificar los usuarios potenciales de la aplicación: entidades físicas y jurídicas, software, etc. ◼ App Cámara: Usuario ◼ Google: Usuario ◼ Comercio online: Cliente, Operador de Pago ◼ Moodle: Profesor, Estudiante … Actor  Identificación y clasificación de CUs 13 ◼ Identificar la funcionalidad del problema. ◼ Clasificar las funciones e identificar las relaciones entre ellas. ◼ Agrupación lógica de la funcionalidad. ◼ Funciones principales y secundarias. ◼ Funciones comunes (que forman parte de las principales) ◼ Identificar las funciones obligatorias y las opcionales.  Identificación de funciones 14 ¿Cuáles son las funciones principales de la aplicación de la cámara del móvil?  Nombres de funciones 15  Nombres de los casos de uso 16 ◼ Reflejan objetivos del usuario. ◼ Cortos. ◼ Significativos. ◼ Voz activa. ◼ Presente. ◼ No identifican al actor. ◼ Consistentes.  Casos de Uso y Actores 17 Asociación entre Actor y Caso de Uso Web de viajes Comprar Billete Reservar Cliente Habitación  Casos de uso y Actores 18 Asociación entre Actor y Caso de Uso BookApp Realizar Pedido Pagar Cliente Pedido Operador de tarjetas de crédito Actor principal Actor secundario  Relaciones entre Casos de Uso 19 Inclusión y Extensión Añadir Post Redactar al Foro Mensaje Solicitar Tutoría Estudiante Responder Adjuntar Tarea Archivo  Relaciones entre Casos de Uso 20 Inclusión y Extensión Añadir Post Redactar al Foro Mensaje Solicitar Tutoría Estudiante Responder Adjuntar Tarea Archivo  Relaciones entre Casos de Uso 21 Inclusión, Extensión y Generalización Adjuntar Archivo Responder Tarea Añadir Contribución Añadir Post al Foro Estudiante Solicitar Redactar Tutoría Mensaje Asociación Abstracción/generalización Parte común/reutilizable Funcionalidad adicional opcional  Relaciones entre Casos de Uso 22 Generalización en CU abstracto Obtener Comprobante Hacer Transferencia Realizar Pagar Operación Recibo Usuario Consultar Generalización y Saldo abstracción de usos: “Clasificador”  Relaciones entre Casos de Uso 23 Generalización en CU concreto Generalización Hacer Pedido de usos sin abstracción Cliente Hacer Pedido a Domicilio Un caso de uso principal puede especializarse en uno o más casos de uso secundarios que representan formas más específicas del principal.  Relaciones entre Casos de Uso 24 Generalización en CU concreto Hacer Examen Profesor Hacer Examen Autoevaluable Los casos de uso secundarios heredan toda la estructura, el comportamiento y las relaciones del principal pero pueden modificar o insertar comportamiento adicional.  Actores 25 Generalización con abstracción Ver Ofertas Usos comunes Empleado Generalización y abstracción de actores Publicar Oferta Usos diferentes Jefe Registrar Venta Comercial  Actores 26 Generalización sin abstracción Consultar Usos comunes Acta Profesor Generalización de actores Editar Acta Usos diferentes Coordinador  Comparativa 27 Generalización, Inclusión y Extensión A B A B A B Generalización Inclusión Extensión B es un subtipo de A B es parte de A B es una opción adicional de A A puede ser abstracto o A es incompleto. A es completo por sí mismo. concreto. Se requiere al menos un caso B es necesario. B es opcional. de uso especializado si A es abstracto. No se especifica la B tiene una B tiene al menos una localización localización. localización concreta. No hay condiciones No hay condiciones Puede tener condiciones especiales. para la inclusión. para la extensión.  Comparativa 28 Generalización, Inclusión y Extensión Realizar Pagar Pedido Realizar Obligatorio Pagar ¿Hay que pagar Pedido para completarlo? Opcional Realizar ¿se puede dejar Pagar Pedido pendiente de pago?  CRUD 29 Administración de la información C: Crear / Añadir R: Visualizar / Recuperar U: Actualizar /Modificar D: Borrar / Cancelar Es un caso de uso para administrar las entidades del sistema. Realizar altas, bajas, consultas y modificaciones de profesores, cursos, productos, alojamientos, etc.  Alternativa 1 30 Identificar en CUs separados Añadir Contacto Visualizar Contacto Usuario Modificar Contacto Borrar Contacto  Alternativa 2 31 Generalizar en un CU abstracto Añadir Contacto Visualizar Contacto Gestionar Contactos Modificar Usuario Contacto Borrar Contacto  Alternativa 3 32 Resumir en un solo CU Gestionar Contactos Usuario Contacto Usuario  CRUD 33 Caso de uso estereotipado Tarjeta de Nombre de la entidad que Crédito se administra en singular No confundir con el caso Pedido de uso Hacer Pedido No confundir con el caso Usuario de uso Registrarse En ocasiones solo se necesitan algunas operaciones: CRU, CR, RUD …  report 34 Caso de uso estereotipado Pedidos Alumnos Devueltos Aprobados Préstamos Facturas Caducados Pendientes Estos casos de uso muestran los pedidos devueltos, los alumnos aprobados, los préstamos caducados y las facturas pendientes.  Casos de uso estereotipados 35 vs Libro Producto Préstamos Novedades Excedidos Cuando el usuario elige la operación READ, el sistema solo muestra los datos del libro o producto identificado por el usuario.  Especificación de un caso de uso 36 Plantilla CU Descripción Precondiciones Flujo normal Paso Descripción paso Variantes Variante Descripción variante Paso Descripción paso Extensiones Paso Descripción CU Postcondiciones Excepciones Paso Descripción excepción Paso manejo Descripción paso manejo  Especificación de un caso de uso 37 Flujo normal Información Sistema Información Usuario  Especificación de un caso de uso 38 Flujo normal CU01 Realizar Pedido Descripción El Cliente pide un conjunto de libros a la tienda. Flujo normal 1 El Cliente indica las palabras clave para buscar un libro. Información 2 El sistema muestra una lista de los libros que encajan con esas palabras, indicando título, autor, ISBN, precio, editorial y Información nº de páginas y mostrando una imagen de la portada. 3 El Cliente selecciona los libros que le interesen e indica la cantidad de cada uno que desea. Información 4 El sistema muestra un resumen del pedido con el título, precio unitario, cantidad y subtotal de cada libro y el precio total. Información 5 El Cliente termina el pedido. Información  Especificación de un caso de uso 39 Flujo normal y precondiciones CU02 Pagar Pedido Descripción El Cliente paga un pedido pendiente. Precondiciones El Cliente tiene un pedido sin pagar. Flujo normal 1 El sistema muestra un resumen del pedido pendiente con el título, precio unitario, cantidad y subtotal de cada libro y el precio total, así como una lista de las direcciones registradas del cliente. 2 El Cliente selecciona una dirección de entrega. 3 El sistema muestra los gastos de envío, la fecha de entrega esperada y la lista de tarjetas de crédito registradas por el cliente (sólo últimos 4 dígitos). 4 El Cliente selecciona una de sus tarjetas. 5 El sistema envía al operador de la tarjeta el número, propietario, fecha de validez, nº de seguridad, importe y código del establecimiento. 6 El operador de la tarjeta valida la compra enviando un código de autorización. 7 El sistema informa al Cliente de que la compra ha sido autorizada y le proporciona un código de seguimiento.  Especificación de un caso de uso Flujos alternativos: escenarios, variantes y excepciones 40 ◼ Escenario: instancia o realización concreta de un CU. Un CU es la generalización de uno o más escenarios. ◼ Variantes: formas alternativas de llegar a un mismo objetivo. ◼ Manejo de excepciones: formas de tratar posibles problemas que aparezcan en el desarrollo del CU.  Ejemplo Librería Online 41 Los pasos y precondiciones no son CU’s BookApp Log In Cliente Realizar Calcular Pedido Impuestos  Especificación de un caso de uso 42 Extensiones CU01 Realizar Pedido Descripción El Cliente pide un conjunto de libros a la tienda. Flujo normal 1 El Cliente indica las palabras clave para buscar un libro. 2 El sistema muestra una lista de los libros que encajan con esas palabras, indicando título, autor, ISBN, precio, editorial y nº de páginas y mostrando una imagen de la portada. 3 El Cliente selecciona los libros que le interesen e indica la cantidad de cada uno que desea. 4 El sistema muestra un resumen del pedido con el título, precio unitario, cantidad y subtotal de cada libro y el precio total. 5 El Cliente termina el pedido. Extensiones 5 El Cliente elige pagar ya. CU 02 (Pagar)  Ejemplo gimnasio 43 Partes comunes en varios CU’s GymApp Matricularse Pagar Cliente Inscribirse en Curso  Especificación de un caso de uso 44 Inclusiones CU01 Matricularse CU03 Pagar Descripción El Cliente se matricula en el gimnasio. Descripción El Cliente paga con tarjeta los servicios solicitados al Flujo normal gimnasio. 1 El Cliente indica nombre, apellidos, fecha de nacimiento, Flujo normal teléfono, dirección e email. 1 El sistema muestra la lista de tarjetas 2 El sistema muestra la cantidad a abonar para la de crédito registradas por el cliente matrícula. (sólo últimos 4 dígitos). 3 El Cliente confirma el pago. INCLUDE CU 03 (Pagar). 2 El Cliente selecciona una de sus tarjetas. CU02 Inscribirse en Curso 3 El sistema envía al operador de la tarjeta el número, propietario, fecha Descripción El Cliente se apunta a un curso ofrecido por de validez, nº seguridad, importe y el gimnasio. código del establecimiento. Flujo normal 4 El operador de la tarjeta valida la 1 El sistema muestra los cursos disponibles, indicando título, compra enviando un código de fecha y precio. autorización. 2 El Cliente selecciona un curso y confirma el pago. 5 El sistema informa al Cliente de que la INCLUDE CU 03 (Pagar). compra ha sido realizada.  Especificación de un caso de uso 45 Variantes CU03 Pagar Descripción El Cliente paga los servicios solicitados al gimnasio. Flujo normal 1 El Cliente selecciona: -Pagar con tarjeta: Variante 1a. -Pagar con Paypal: Variante 1b. Variantes 1a Pagar con Tarjeta 1a.1 El Cliente introduce el número de la tarjeta, el nombre, la fecha de caducidad y el código de control. 1a.2 El sistema envía al operador de la tarjeta el número, propietario, fecha de validez, nº de seguridad, importe y código del establecimiento. 1a.3 El operador de la tarjeta valida el pagoenviando un código de autorización. 1a.4 El sistema informa al Cliente de que el pago ha sido realizado. 1b Pagar con Paypal 1b.1 El sistema redirecciona a la página de pago de Paypal para el establecimiento. 1b.2 Paypal valida el pago enviando un código de autorización. 1b.3 El sistema informa al Cliente de que el pago ha sido realizado.  Especificación de un caso de uso 46 Variantes, extensiones y postcondiciones CU01 Enviar Mensaje Descripción El Usuario envía un mensaje a uno o más destinatarios. Flujo normal 1 El usuario escribe las direcciones de los destinatarios. 2 El usuario escribe un asunto. 3 El usuario redacta el contenido del mensaje. 4 El usuario envía el mensaje. Variantes 1a El usuario selecciona las direcciones de la libreta de direcciones. 1a.1 El sistema muestra los nombres y las direcciones de su libreta de contactos. 1a.2 El usuario selecciona los destinatarios. Extensiones 3 Adjuntar fichero. CU02 (Insertar archivo adjunto) Postcondiciones Una copia del mensaje se guarda en la carpeta de elementos enviados.  Especificación de un caso de uso 47 Excepciones CU01 Realizar Pedido Descripción El Cliente pide un conjunto de libros a la tienda. Flujo normal 1 El Cliente indica las palabras clave para buscar un libro. 2 El sistema muestra una lista de los libros que encajan con esas palabras, indicando título, autor, ISBN, precio, editorial y nº de páginas y mostrando una imagen de la portada. 3 El Cliente selecciona los libros que le interesen e indica la cantidad de cada uno que desea. 4 El sistema muestra un resumen del pedido con el título, precio unitario, cantidad y subtotal de cada libro y el precio total. 5 El Cliente termina el pedido. Excepciones 3a La cantidad solicitada de algún libro es superior al stock. 3b No se ha seleccionado ningún libro. 5a El Cliente no está identificado.  Especificación de un caso de uso 48 Manejo de excepciones CU 1 Realizar Pedido Excepciones 3a La cantidad solicitada de algún libro es superior al stock. 3a.1 El sistema muestra las cantidades disponibles de aquellos e que se ha sobrepasado. 3a.2 El cliente modifica las cantidades. 3a.3 Ir al paso 4. 3b No se ha seleccionado ningún libro. 3b.1 Ir al paso 1. 5a El cliente no está identificado. 5a.1 El cliente proporciona una identificación válida. 5a.2 Ir al paso 5.  Casos de uso estereotipados: 49 Criterios de selección, filtrado, orden… Pedidos Sistema Devueltos Resultado consulta Usuario CU 5 Pedidos Devueltos Flujo normal 1 El gestor indica la fecha de inicio y la de fin. 2 El sistema muestra los pedidos devueltos en el periodo incluyendo nº de pedido, nombre del cliente, importe y libros del pedido.  Casos de uso estereotipados: (I) 50 CU 1 Editor Descripción El Gestor de Ventas crea, visualiza, modifica o borra un editor. Precondiciones El Gestor de Ventas tiene que estar autenticado. Flujo normal 1 El Gestor de Ventas elige Crear editor: variante 1a Visualizar editor: variante 1b Modificar editor: variante 1c Borrar editor: variante 1d Variantes 1a 1a.1 El Gestor de Ventas indica nombre, código, dirección e email del editor. 1b 1b.1 El Gestor de Ventas identifica al editor. 1b.2 El sistema muestra el nombre, código, dirección e email del editor. 1c 1c.1 INCLUDE 1b (visualizar editor). 1c.2 El Gestor de Ventas proporciona nuevos valores para el nombre, código, dirección e email del editor. 1d 1d.1 El Gestor de Ventas identifica el editor a borrar.  Casos de uso estereotipados: (II) 51 CU 5 Editor Excepciones (1a.1,1c.2)a El código ya existe (1a.1,1c.2)a.1 El sistema indica que ya existe un editor con ese código. (1a.1,1c.2)a.2 Ir al paso que causó la excepción. 1d.1.a Existen libros asociados a ese editor. 1d.1.a.1 El sistema indica que no se puede borrar ese editor porque hay libros asociados a él. 1d.1.a.2 Ir al paso 1d.1.  Utilidad de los casos de uso 52 ◼ Permiten describir la funcionalidad del sistema. ◼ Sirven como punto de partida para definir experiencias de usuario efectivas (UX). ◼ Guían el proceso de desarrollo: Análisis → Diseño → Código → Prueba ◼ Base para la documentación de usuario. ◼ Permiten planificar iteraciones. ◼ Ayudan a la definición y validación de la arquitectura. ◼ Ayudan a crear casos de prueba.  Recomendaciones 53 ◼ Pensar desde el punto de vista del usuario: ¿Para qué se usará la aplicación? ◼ Un actor es un rol, no es una persona concreta. ◼ Evitar nombres de casos de uso muy largos. ◼ No incluir detalles técnicos o de interfaz. ◼ Colocar actores y casos de uso de manera significativa y ordenada. ◼ No presentar secuencias temporales en los diagramas. ◼ Modelar las partes comunes usando. ◼ Modelar los comportamientos especiales usando.  Recomendaciones 54 ◼ Mostrar información intercambiada entre usuario y sistema. ◼ Omitir información sobre procesamiento interno. ◼ Identificar excepciones en las que el usuario envía información que el sistema no puede manejar o aceptar. ◼ Modelar los pasos del caso de uso con otra herramienta (flujo de eventos, diagramas de secuencia…)  Bibliografía 55 OMG Unified Modeling Language Specification (Version 2.5.1) https://www.omg.org/spec/UML/2.5.1/ OMG, December 2017 El Lenguaje Unificado de Modelado. Manual de Referencia / Unified Modeling Languge Reference Manual, 2nd Edition. James Rumbaugh, Ivar Jacobson y Grady Booch. Addison Wesley, 2004 Object-Oriented Analysis and Design for Information Systems. Modeling with UML, OCL and FML. Raul Sidnei Wazlawick. Morgan Kaufmann (ed.), 2014 UMLTM Bible. Tom Pender. John Wiley & Sons 2003