Tm03 modelo de casos de uso

11,577 views
11,113 views

Published on

1 Comment
3 Likes
Statistics
Notes
No Downloads
Views
Total views
11,577
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
383
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide
  • Tus comentarios:
  • Las precondiciones deben redactarse en tiempo verbal pasado.
  • Tus comentarios:
  • En algunos casos se recomienda establecer un diálogo de dos columnas entre el actor y el sistema ordenando los pasos por secuencia de ocurrencia.
  • En algunos casos se recomienda establecer un diálogo de dos columnas entre el actor y el sistema ordenando los pasos por secuencia de ocurrencia.
  • Las precondiciones establecen lo que siempre debe cumplirse antes de comenzar un escenario en un caso de uso. Normalmente implica que un escenario de otro caso de uso se ha completado exitosamente. Las poscondiciones o garantía de éxito establecen qué debe cumplirse cuando el caso de uso se completa
  • Las precondiciones establecen lo que siempre debe cumplirse antes de comenzar un escenario en un caso de uso. Normalmente implica que un escenario de otro caso de uso se ha completado exitosamente. Las poscondiciones o garantía de éxito establecen qué debe cumplirse cuando el caso de uso se completa
  • Las precondiciones establecen lo que siempre debe cumplirse antes de comenzar un escenario en un caso de uso. Normalmente implica que un escenario de otro caso de uso se ha completado exitosamente. Las poscondiciones o garantía de éxito establecen qué debe cumplirse cuando el caso de uso se completa
  • Las precondiciones establecen lo que siempre debe cumplirse antes de comenzar un escenario en un caso de uso. Normalmente implica que un escenario de otro caso de uso se ha completado exitosamente. Las poscondiciones o garantía de éxito establecen qué debe cumplirse cuando el caso de uso se completa
  • Para la explicación de las relaciones entre casos de uso se han identificado como “caso de uso origen” y “caso de uso destino” sólo para indicar el sentido del símbolo (flecha de generalización).
  • una instancia del Caso de Uso origen comprende también el comportamiento descrito por el Caso de Uso destino Muestra un comportamiento que es comun a uno o más casos de uso. En UML 1.3 se estereotipa como <<includes>>
  • Las relaciones <<include>> y <<extend>> corresponden ambas a factorizaciones del comportamiento de un caso de uso, es decir, el caso de uso incluido y el caso de uso que extiende representan un fragmento de interacción de otro caso de uso. Sin embargo, la intensión es diferente; la relación <<include>> pretende evitar duplicación de interacciones en distintos casos de uso, la relación <<extends>> pretende describir una variación del comportamiento normal de un caso de uso, sobre todo cuando dicha variación pudiera complicar la legibilidad del caso de uso.
  • el Caso de Uso origen se extiende con el comportamiento del Caso de Uso destino. Describe una variación de conducta normal.
  • En el documento UML no se proporcionan reglas específicas respecto de las modificaciones y ampliaciones posibles en el caso de uso hijo. Lo intuitivo es pensar que un caso de uso obtenido por especialización tiene en principio los mismos pasos de interacción que el caso de uso padre pero que puede insertar nuevos y/o reescribir los pasos heredados.
  • ¿Podría en este ejemplo haberse modelado el caso de uso “Transferencia por Internet” con una relación de generalización hacia el caso de uso “Transferencia”?. Si la idea de extensión (vista como especialización) forma parte esencial del concepto de generalización/especialización, ¿para qué tener dos tipos de relaciones? ... estos son algunos de lo muchos aspectos de UML que están en discusión.
  • Tm03 modelo de casos de uso

    1. 1. Asignatura de Técnicas de Asignatura de Técnicas de Modelamiento Modelamiento Tema: Modelo de Casos Tema: Modelo de Casos de uso de uso Prof. César Luza MonteroFacultad de Ingeniería de Sistemas e Informática Universidad Nacional Mayor de San Marcos
    2. 2. ¿Por qué fracasan los proyectos informáticos? Falta de soporte Tecnologicos/ Falta de recursos Tecnicos 9.3% 10.6% Requisitos 21.8% incompletos o cambiantes 7.5% No se 12.4% necesitó al 9.9% final del Usuario no involucrado desarrollo Expectativas no realistas Causas de fracaso en proyectos informáticos
    3. 3. Exploración ¿Proceso de desarrollo? ¿Requerimientos? ¿Métodos, Técnicas y Herramientas? ¿Modelos de alto nivel o conceptuales vs. Modelo de Implementación o físicos?
    4. 4. Al final de esta presentación serás capaz de: Identificar y definir los elementos del modelo de casos de uso Elaborar modelos de casos de uso
    5. 5. Modelo de Casos de uso ¿Qué es?El Modelo de Casos de uso es un modeloEl Modelo de Casos de uso es un modelo que describe los requerimientos que describe los requerimientos funcionales del sistema en forma de funcionales del sistema en forma de Casos de uso Casos de uso
    6. 6. Requerimientos funcionales Un requerimiento es: una condición o capacidad a la que debe ajustarse el sistema que se construye. Requerimiento funcional: es un requerimiento que describe que debe hacer el sistema respecto a su entorno Entorno: los usuarios u otros sistemas
    7. 7. Un ejemplo: Sistema Académico RequerimientosEl sistema permitirá: funcionales A los profesores:  Consultar los horarios de sus cursos  Consultar la programación de los exámenes  Actualizar y ver su información personal  Registrar y modificar las notas de los estudiantes a su cargo  Cerrar un curso
    8. 8. Un ejemplo: Sistema Académico A los estudiantes:  Consultar los horarios de sus cursos  Consultar la programación de los exámenes  Actualizar y ver su información personal  Consultar notas de un curso Requerimientos funcionales
    9. 9. Descripción de un Requerimiento Registrar y modificar las notas de los estudiantes a su cargo:  El profesor, que previamente se ha identificado en el sistema, podrá ingresar las notas de los estudiantes. Solo podrá acceder a sus grupos de clases. Una vez cerrado un curso no podrá hacer cambios.
    10. 10. Actor Un actor es : un rol que un grupo de usuarios de un sistema cumplen cuando interactúan con este Defineun conjunto de instancias de actores, donde cada uno juega el mismo rol en relación al sistema. Una instancia de un actor es algo(otro sistema o equipo) o alguien(persona) que interactúa con elsistema.
    11. 11. Los actores ayudan a definir la frontera del sistemaSituación 1: Sistema de aerolínea pasajero agente de viajesSituación 2: Sistema de aerolínea pasajero (www.enPista.com)
    12. 12. Caso de uso Un escenario o instancia de un caso de uso esUn escenario o instancia de un caso de uso es una secuencia especifica de acciones euna secuencia especifica de acciones e interacciones entre los actores y el sistema objeto deinteracciones entre los actores y el sistema objeto de estudio que proporciona valor a un actor enestudio que proporciona valor a un actor en particular.particular.Un Caso de uso define un conjunto de instancias deUn Caso de uso define un conjunto de instancias deCasos de uso.Casos de uso. En otras palabras: “es una descripción de laEn otras palabras: “es una descripción de la secuencias de acciones que un sistemasecuencias de acciones que un sistema ejecuta para proporcionar un resultadoejecuta para proporcionar un resultado observable de un valor a un actor enobservable de un valor a un actor en particular”particular”
    13. 13. Descripción de un Caso de uso Registrar y modificar las notas de los estudiantes a su cargo:Actor: Profesor El Caso de uso comienza cuando el profesor indica “registrar notas.” El sistema muestra un formulario de validación de ingreso al sistema. El usuario ingresa su clave de acceso y su contraseña. El sistema valida el ingreso. El sistema muestra los cursos asignados al profesor. El profesor selecciona el curso. El sistema muestra un listado de los estudiantes con sus notas. El profesor selecciona el estudiante e ingresa la nota de práctica, del parcial, del examen final y la nota final. Se repite para cada estudiante. El profesor indica “guardar”. El sistema valida toda la información y muestra un mensaje de confirmación y el Caso de uso finaliza.
    14. 14. Descripción de casos de usos Nombre. Debe indicar el título del caso de uso.  Ejemplo: matricular un estudiante. Breve descripción.  Descripción pequeña de las actividades o pasos principales que realiza el caso de uso. Debe incluir el propósito del caso de uso. Caso de uso: Comprar Producto Caso de uso: Comprar Producto Actor : : Actor Cajero Cajero Descripción: Descripción: Un cliente llega a la caja registradora con los Un cliente llega a la caja registradora con los artículos que comprará. El cajero registra los artículos yycobra el artículos que comprará. El cajero registra los artículos cobra el importe. Al terminar la operación el cliente se marcha con los importe. Al terminar la operación el cliente se marcha con los productos. productos.
    15. 15. Descripción de casos de usos Precondiciones.  Restricción que tiene que ser verdadera para que el caso de uso comience.  Se definen relativas al sistema, no a su entorno.  Deben ser estados observables por el actor. Poscondiciones  Condición que debe cumplirse para indicar que el caso de uso ha terminado con éxito.  Establecen que debe cumplirse cuando el caso de uso termine Precondición: El usuario ha sido aceptado en el sistema con el rol Precondición: El usuario ha sido aceptado en el sistema con el rol de profesor de profesor Postcondición: Se ha registrado en el sistema las notas de los Postcondición: Se ha registrado en el sistema las notas de los alumnos alumnos
    16. 16. Descripción de casos de usos Flujo de eventos.  Secuencia de eventos a desarrollar por los actores y el sistema dentro del caso de uso.  Se describe QUE hacen el actor y el sistema en el proceso y no COMO se implementa.  Está formado por dos partes:  Flujo básico y  Flujo alternativo.
    17. 17. Descripción de casos de usos Flujo Básico.  Descripción narrativa de lo que debe ocurrir cuando los actores interactúan con el sistema para satisfacer la meta u objetivo propuesto.  Se consideran los pasos básicos, normales e invariables para lograr el objetivo del caso de uso.  No incluye las alternativas o variaciones. Flujos Alternativos.  Se reflejan las diferentes situaciones que provocan una desviación del flujo básico de eventos.  Se observan condiciones anormales, extremas, ocasionales o eventuales, condiciones de error o violación de las reglas que impone las exigencias del negocio para el caso de uso.
    18. 18. Descripción de casos de usosNombre: Registrar y modificar las notas de los estudiantes a su cargoActor: ProfesorFlujo Básico1. El Caso de uso comienza cuando el profesor indica “registrar notas.”2. El sistema muestra un formulario de validación de ingreso al sistema.3. El usuario ingresa su código y su contraseña.4. El sistema muestra los cursos asignados al profesor.5. El profesor selecciona el curso.6. El sistema muestra un listado de los estudiantes con sus notas.7. El profesor selecciona el estudiante e ingresa la nota de práctica, del parcial, del examen final y la nota final. Se repite para cada estudiante.8. El profesor indica “guardar”.9. El sistema valida toda la información y muestra un mensaje de confirmación y el Caso de uso finaliza.Flujo AlternativoEn el paso 3, si codigo o contraseña son erradas el sistema muestra mensaje yvuelve a solicitar código y contraseña
    19. 19. Descripción de casos de usos  Formato Detallado (plantillas www.usecases.org)Caso de uso :Actores :Precondición :Poscondición : Flujo Básico1.El caso de uso comienza cuando el actor …2.3 Flujos Alternativos1.2.
    20. 20. Descripción de casos de usos  Formato Detallado (plantillas www.usecases.org)Caso de uso :Actores :Precondición :Poscondición : Flujo Básico Actor Sistema1.El caso de uso comienza 1.cuando el actor … 2.2. 3.3 Flujos Alternativos1.2.
    21. 21. Diagrama de Casos de uso Un Diagrama de Casos de uso muestra los Actores, los Casos de uso y las Relaciones entre ellos: <<communicate>> <Use Case Name> <Actor Name> (from <Use Case Name>) (f rom Actors)
    22. 22. El actor Profesor y sus Casos de uso Consultar horarios de cursos (from Use Cases) Profes or (f rom Actors) Mantener inform ación del profes or (from Use Cases) Registrar notas de un cursoConsultar horarios de exam enes (from Use Cases) (from Use Cases) Validar acceso (from Use Cases)
    23. 23. ¿Diferencias? Requerimiento vs. Casos de uso Hay una correspondencia directa de requerimiento funcional hacia Caso de uso Mas bien la diferencia está en la forma de la descripción. Los requerimientos funcionales se registran en un documento denominado “Software Requeriments Specifications”, conocido por sus siglas SRS. Los Casos de uso se documentan en un modelo de Casos de uso.
    24. 24. Beneficios El modelo de Casos de usos  Es usado para comunicarse con el usuario final y el experto del dominio  Proporciona credibilidad en una etapa inicial del desarrollo del sistema  Asegura una comprensión mutua de los requisitos  Es usado para identificar  Quién interactuará con el sistema y qué deberá hacer el sistema  Qué interfaz deberá tener el sistema  Es usado para verificar que:  Se capturan todos los requisitos  Que los desarrolladores hayan entendido los requisitos  Es usado como base para la pruebas.  Es usado como base para la planificación del proyecto.
    25. 25. Relaciones entre actores Si dos o más actores utilizan el sistema de la misma forma entonces es posible establecer una relación de Generalización entre ellos, con el objetivo de simplificar el modelo de Casos de uso
    26. 26. Relaciones entre actores Usuario Estudiante Profesor
    27. 27. Casos de uso del Usuario Consultar horarios de cursos Usuario Validar acceso (f rom Actors) Consultar horario de exámenes
    28. 28. Casos de uso del Estudiante Estudiante (f rom Actors) Mantener información del estudiante Consultar notas de un curso
    29. 29. Casos de uso del Profesor Mantener información del profesor Profesor(f rom Actors) Registrar notas de un curso Cerrar un curso
    30. 30. Modelo de Casos de uso del Sistema Académico Consultar notas de un curso Estudiante Consultar horarios de cursos (f rom Actors) Mantener información del estudiante Cerrar un curso Validar acceso Usuario Mantener información del profesor (f rom Actors)Consultar horario de exámenes Profesor Registrar notas de un curso (f rom Actors)
    31. 31. Construcción de Casos de uso Identificar actores  Qué grupos de usuarios necesitan apoyo del sistema para realizar sus tareas?  Qué grupos de usuarios son responsables de ejecutar las funciones relevantes del sistema  Qué usuarios realizan labores secundarias de mantenimiento y administración?  Interactuará el sistema con algún dispositivo o sistema externo?
    32. 32. Construcción de Casos de uso Encontrar casos de uso  ¿cuáles son las tareas del actor?  ¿qué información crea, guarda, modifica, destruye o lee el actor?  ¿debe el actor notificar al sistema los cambios externos?  ¿debe el sistema informar al actor de los cambios internos?  Necesita el actor realizar operaciones de mantenimiento, auditoria y/o soporte?
    33. 33. Construcción de Casos de uso Describir los casos de uso:  Formato Breve  Descripción resumida de la funcionalidad que representa el caso de uso (qué)  Formato Detallado  Contiene mayores detalles. Describe el curso flujo de eventos o diálogo que se sucede entre el actor y el sistema
    34. 34. Construcción de Casos de uso  Elaborar el diagrama de casos de uso: BIBLIOTECA Reservar Libros Socio Registrar PréstamoBibliotecario Registrar Devolución
    35. 35. Construcción de Casos de uso Ejemplo: Sistema de MatriculaLa universidad quiere automatizar su sistema de matrículade cursos de verano.Un Empleado inicializa la oferta de cursos ofrecidos parael verano. Un mismo curso tiene varias ofertas(secciones).Durante un cierto período de tiempo, después de que sehaya definido la oferta de cursos, los estudiantes puedenutilizar el sistema para añadir o eliminar cursos amatricular. Los alumnos seleccionan 4 cursosobligatorios y 2 cursos electivos.Los profesores pueden utilizar el sistema para obtener laslistas de alumnos matriculados en su curso.Los usuarios del sistema de matrícula acceden a élmediante un login y una password que le es asignada.
    36. 36. Construcción de Casos de uso Ejemplo: Sistema de Matricula•Actores : •Empleado •Estudiante •Profesor•Casos de uso •Ingresar Oferta de cursos •Añadir o Eliminar Curso •Obtener Listado de Alumnos
    37. 37. Construcción deMatricula de uso Caso Sistema de CasosCaso de uso : Ingresar oferta de cursosActor : EmpleadoPrecondición : Empleado ha sido admitido como usuarioPoscondición : Se ha registrado la oferta de cursos Flujo Básico Actor Sistema1.El C.U. comienza cuando 1. El sistema muestra formularioEmpleado Indica “Ingresar oferta” “Ingresar oferta”2.Ingresa Código de Curso 2.Muestra nombre del curso3. Ingresa Sección, Horario y 3.Verifica aula disponible y horarioAula sin cruce4. Repite 2 a 3 por cada curso 4. Repite 2 a 3 por cada curso5. Indica “Guardar” 5. Muestra mensaje de confirmación y el C.U. termina. Flujos Alternativos1.2.
    38. 38. Construcción de Casos de uso Caso Sistema de Matricula Diagrama de casos de uso Registrar Curriculum Obtener ListadoEmpleado Profesor Registrar CursoAlumno
    39. 39. Caso de EstudioSISTEMA DE BIBLIOTECA: Se trata de gestionar los préstamos de libros de una biblioteca en la que se va a estudiar exclusivamente el funcionamiento de las peticiones y devoluciones de libros.Petición de libros Un usuario puede realizar una petición de uno o más libros a la biblioteca. Para ello, es necesario presentar, el carnet de usuario de la biblioteca y una ficha en la que se detallan los libros pedidos. Puede haber varios tipos de préstamo (de sala, colaborador, proyecto fin carrera, doctorado) en función de los cuales el usuario puede disponer de los ejemplares durante un período de tiempo específico, (SALA :El día de la petición, COLABORADOR: Una semana, PROYECTO FIN CARRERA; Quince días y DOCTORADO: Un mes). Una vez entregados el carnet y la ficha, el sistema comprobará y aceptará la petición de los libros solicitados siempre que pueda satisfacer la petición, es decir, cuando haya ejemplares disponibles. Si se acepta la petición, se actualiza el número de unidades de los libros de la biblioteca y se guarda la ficha de préstamo.
    40. 40. ...Caso de EstudioDevoluciones de libros Un usuario no puede realizar más peticiones hasta que no haya efectuado todas las devoluciones de la petición anterior. El usuario, para hacer la petición, necesita el carnet, que no se le entrega hasta que no haya devuelto todos los libros. Sí puede hacer una devolución parcial de los libros.Cuando un usuario realice una devolución, el sistema actualizará el stock de libros y comprobará la fecha de devolución de cada ejemplar para estudiar, en el caso de que la devolución se haga fuera de tiempo, la imposición de una sanción que tiene un coste de X ud. monetarias por cada ejemplar y días de retraso en la devolución. En este caso, la sanción se emite cuando el usuario entrega el último ejemplar.
    41. 41. Relaciones entre casos de uso Relaciones de inclusión / uso (<<include>>) Relación de extensión (<<extend>>) Relación de generalización
    42. 42. … Casos de Uso: Relaciones Inclusión : una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino <<include>> Caso de Uso Origen Caso de Uso Destino<<include>> reemplazó al denominado <<uses>>
    43. 43. … Casos de Uso: RelacionesDe Inclusión: El caso de uso origen incorpora explícitamente el comportamiento de otro caso de uso como fragmentos de su propio comportamiento. <<includes>> Caso de uso destino El caso de uso destino no es Caso de uso origen un caso especial del caso de uso original y no se puede sustituir por él.
    44. 44. … Casos de Uso: Relaciones Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino <<extend>> Caso de uso destino Caso de uso origen Caso de Uso Origen Caso de Uso Destino
    45. 45. … Casos de Uso: Relaciones De Extensión:  Se amplia el comportamiento del caso de uso origen con otro comportamiento adicional <<extends>> Caso de uso destino Caso de uso origen Modela parte del caso de uso que representa comportamiento opcional del sistema
    46. 46. … Casos de Uso: Relaciones Generalización : el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplíaCaso de Uso Hijo Caso de Uso Padre
    47. 47. … Casos de Uso: Relaciones Ejemplo: Identificación <<include>> Transferencia Cliente <<extend>> Transferencia en Internet
    48. 48. Ejemplo de <<Include>> Reintegro cuenta corriente <<include>> Cliente Validar operación <<include>> Reintegro cuenta crédito
    49. 49. Ejemplo de <<extends>> Realizar préstamoEncargado Socio tarjeta caducada <<extends>> Solicitar nueva tarjeta
    50. 50. Casos de Uso – ejemplo 1 <<extends>> Giro por Internet Cliente <<includes>> Giro Identificación
    51. 51. Casos de Uso - ejemplo 2 Cajero Electrónico pedir saldo <include> validar usuario retirar Cliente <include> <extend> Comprobar Retiro con huella sobregiro cargarSupervisor
    52. 52. Casos de Uso - ejemplo3 <<extend>> Hacer Pedido Solictar Catalogo Vendedor <<include>> <<include>> <<include>> Suministro de Pedir Producto Realizar Pago datos clientes Pagar al Contado Acordar Crédito

    ×