Modelo de Dominio o conceptual
• ¿Qué es?
Captura los conceptos (tipos de objetos) más importantes del contexto del
sistema
INGENIERÍA DEL SOFTWARE I •
Desde el punto de vista del problema, no de la solución.
Objetos
Práctica 3 “cosas” que existen o eventos que suceden en el entorno en que trabaja el
sistema
• ¿Obtención de objetos o clases?
Modelado de Requisitos •
Especificación de requisitos o entrevista
Clases de Dominio
Objetos del negocio: pedidos, cuentas, contratos
Objetos del mundo real y conceptos que requieren seguimiento: aviación
enemiga, misiles, trayectorias
Sucesos: llegada y salida de un avión, hora de comida
• El modelo de dominio se representa a través de un diagrama de
Univ. Cantabria – Fac. de Ciencias clases:
María Sierra y Patricia López Con asociaciones entre ellas, pero sin cualificar (sin adornos)
Se pueden incluir atributos en las clases (de forma conceptual)
Ejemplo Práctico de Desarrollo de Software Modelo de Dominio
El proyecto consiste en el desarrollo de un sistema de
gestión para una empresa de autobuses que se dedica al
transporte regional, nacional e internacional de viajeros. Las
necesidades de esta empresa son la gestión de viajes
ofertados, trabajadores y gestión de billetes.
(El resto del enunciado lo podeis consultar en la página web)
Modelado con Diagramas de Casos de Uso Modelado – Contexto del Sistema
• Los Diagramas de Casos de Uso sirven para • Identificar los actores, externos al sistema pero que
modelar: interactúan con el, considerando los roles que
requieren ayuda del sistema para llevar a cabo sus tareas,
El Comportamiento de un Elemento
son necesarios para ejecutar las funciones del sistema,
Sistema, Subsistema, Componente, Clase.
interactúan con el hardware externo o con otros sistemas software, y
El Contexto del Sistema realizan funciones secundarias de administración y mantenimiento.
Los Requisitos del Sistema
• Organizar los actores similares en jerarquías de
generalización/especialización.
• Introducir esos actores en un Diagrama de Casos de Uso y
especificar la comunicación de cada actor con los casos de
uso del sistema.
Modelado – Contexto del Sistema Modelado – Requisitos del Sistema
• Establecer el contexto del sistema, identificando los actores.
• Considerar el comportamiento del sistema que cada actor
espera o requiere que éste proporcione.
• Nombrar los comportamientos comunes como casos de uso.
• Factorizar el comportamiento común y el comportamiento
variante.
El común en nuevos casos de uso que puedan ser utilizados por otros.
El variante en nuevos casos de uso que extiendan los flujos principales
• Modelar esos casos de uso, actores y relaciones en un
diagrama de casos de uso.
• Adornar esos casos de uso con notas que enuncien los
requisitos no funcionales.
Modelado – Requisitos del Sistema Modelado – Comportamiento de un Elemento
• Identificar los actores que interactúan con el elemento.
• Organizar los actores identificando tanto los roles más
generales como los más especializados (generalizaciones).
• Considerar
las formas más importantes que tiene cada actor de interactuar con el
elemento.
las formas excepcionales en las que cada actor puede interactuar con
el elemento.
las interacciones que implican el cambio de estado del elemento o de
su entorno o que involucran una respuesta ante algún evento.
• Organizar estos comportamientos como casos de uso.
Utilizando las relaciones de inclusión y extensión para factorizar el
comportamiento común y distinguir el comportamiento excepcional.
Modelado – Comportamiento de un Elemento Modelado – Comportamiento de un Elemento
• Ejemplo. Subsistema de Gestión de Billetes. Definición Caso de Uso. Comprar billete OnLine
Descripción
El cliente compra un billete a través de la página web.
Precondiciones
Se tiene acceso a la página web
• Post-condiciones
El billete ha sido creado y almacenado
• Flujo de eventos
1. Si el cliente no está registrado => Caso de uso registrarse
2. El cliente introduce usuario y contraseña
3. El sistema pide los datos del billete: origen, destino y fecha.
4. El cliente introduce los datos
5. El sistema comprueba que quedan asientos libres en el viaje elegido.
6. Se informa al cliente de los asientos asignados.
7. Si el cliente elige la opción de asignar asientos => Caso de uso Seleccionar Asiento
8. El sistema pide datos de pago
9. El cliente introduce los datos de pago
10. El sistema realiza la transacción
11. Se actualiza el número de asientos disponibles en el viaje
12. Se envía un correo electrónico al cliente con los datos de su billete
Flujo alternativo o de excepcion
El cualquier punto antes de 10 el cliente puede cancelar la operación
En 10 el sistema puede rechazar los datos del cliente, mostrar un mensaje y volver a 8.
Diagramas de casos de uso en VP: Creación Diagramas de casos de uso en VP: Creación
• Los elementos se pueden añadir haciendo uso de la interfaz de recursos
centrados
Asociación con Caso de Uso Asociación con Actor
Relación <<include>> con otro CDU
Asociación Herencia con otro actor
Relación <<extend>> con otro CDU
Agregar una nota
Relación herencia con otro CDU
Agregar una nota
Diagramas de casos de uso en VP: Especificación Diagramas de casos de uso en VP: Especificación
Lista de posibles
escenarios
del caso de uso
Plantilla para la
descripción
de escenarios de
los casos de uso
Se pueden generar diagramas de
secuencia automáticamente a partir de
diagramas de casos de uso
Diagramas de casos de uso en VP
