Gitxisxt4xplanificacion y Casos de Uso

TEMA 4 PLANIFICACIN Y CASOS DE USO
INGENIERIA DEL SOFTWARE
CONTENIDOS
2
1 PLANIFICACIN
1.1 Introduccin 1.2 Prototipado 1.3 Casos de Uso
5 RECOMENDACIONES Y ERRORES 6 EJEMPLO DEL CASOS DE USO DEL LOGUIN

6.1 Solucin 1 6.2 Solucin 2 6.3 Solucin 3 6.4 Solucin 4 6.5 Solucin 5
2 CASOS DE USO
2.1 Introduccin 2.2 Actores 2.3 Sujetos 2.4 Flujos de eventos
7 EJEMPLOS
7.1 Mquina de reciclaje 7.2 Terminal punto de venta
3 RELACIONES
3.1 Tipos de relaciones 3.2 Generalizacin 3.3 Inclusin 3.4 Extensin
4 MODELADO DE CASOS DE USO

4.1 Pasos 4.2 Recomendaciones 4.3 Utilidad de los casos de uso 4.4 Granularidad de los casos de uso 4.5 Ordenacin
Escola Tecnica Superior de Engineria
PLANIFICACIN Introduccin
3
La primera tarea es el Estudio de Viabilidad del Sistema.
estudia las necesidades de la empresa, se investigan alternativa, se estudia la viabilidad del proyecto, se realiza un anlisis de riesgos y se definen los objetivos del proyecto.
3 actividades principales:

Obtencin de los Requisitos (funcionales funcionales). Creacin de Prototipos preliminares Especificacin de los casos de Uso

no
Diagramas de Casos de Uso Descripcin de los Casos de Uso Ordenacin Casos de Uso
Casosde Uso Expresarlos requisitos Investigary comprenderel problema
Planificarla estrategiaa seguir
PLANIFICACIN Prototipado
4
Actividad que se suele realizar para clarificar requisitos poco intuitivos y facilitar al cliente la comprensin del producto. se caracterizan por

Se centran en mostrar las interfaces de usuario Fcil de construir con herramientas visuales. Sirve para validar los requisitos. Ejemplo: Pensad un prototipo de un interfaz para que un socio de una biblioteca obtenga el prstamo de un libro o lo reserve cuando no queden ejemplares disponibles.
El Prototipo inicial desechable.
PLANIFICACIN Prototipado
5
Prototipo.
SIGNATURA LIBRO: NMERO SOCIO:
rea de texto donde aparecer el nmero de copia del libro que se ha tomado en prstamo. Si no hay ninguna libre o si el socio ha sobrepasado su nmero mximo de prstamos entonces se indicar aqu mismo.
CASO DE USO: TOMAR COPIA LIBRO EN PRSTAMO
TOMAR EN PRSTAMO
RESERVAR LIBRO
Cancel
PLANIFICACIN Casos de Uso

6
Representan los requisitos funcionales que proporciona un sistema para aadir valor a sus usuarios.
Especifican
el comportamiento deseado del
sistema Describen qu hace el sistema, no cmo lo hace.

Inician y guan todo el proceso de desarrollo. Ayudan a:

Comprensin
unificada del sistema desde distintos puntos de vista. Validar la arquitectura y a verificar el sistema.
CASOS DE USO
INTRODUCCION Definicin
8
Un caso de uso especifica un conjunto de secuencias de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un actor en particular. Partes de un caso de uso (PCU)
Conjunto de secuencias de acciones. Cada secuencia representa un posible comportamiento del sistema. Actores, roles que realizan los usuarios. Interviene un Actor (o varios) interactuando con el Sistema. Incluye variantes: versiones especializadas (extensin o inclusin).
INTRODUCCION Sintaxis
9
Un Caso de Uso (CU) debe tener un Nombre:

Lo
distingue de otros CU. Mejores nombres: expresiones verbales que describen algn comportamiento del sistema.
Sintaxis:
Procesar Datos Procesar Datos Procesar Datos
INTRODUCCION Clasificacin
10
Segn la importancia
Primario: Representan los procesos fundamentales Secundario: Representan procesos menos importantes o menos habituales Opcional: Representan procesos que podran no realizarse
Segn el nivel de abstraccin

Esencial: intenciones del usuario y responsabilidades del sistema Concreto: descripciones en trminos de pasos reales contemplando detalles de implementacin.
ACTORES Introduccin
11
Un actor representa un conjunto coherente de roles que juegan los usuarios de los casos de uso al interaccionar con el sistema. Un actor puede representar:
personas, dispositivos
(hardware) otros sistemas (software)
Puntualizaciones:
El
tiempo puede ser un actor. Un usuario puede jugar diferentes roles. Los actores no forman parte del sistema.
ACTORES Sintaxis
12
Sintaxis
<< actor >> Responsable prstamos Responsable prstamos
Responsable prstamos
Se pueden organizar en categoras (generalizacin)
Responsable prstamos Empleado Banca Cajero

ACTORES Semntica
13
Los actores se conectan a los casos de uso a travs de relaciones de tipo asociacin
El
actor y el caso de uso se comunican entre s, pueden enviar y recibir mensajes o datos.
Actualizar catalogo
Bibliotecario
ACTORES Semntica
14
Un actor puede intervenir en varios casos de uso.

Prstamo revista Profesor Devolver revista
Puede haber ms de un actor asociado a un mismo caso de uso
Usuario
Ordenar Pedido
Suministrador
ACTORES Clasificacin
15
Principales:
Utilizan
el sistema directamente Requieren al sistema el cumplimiento de un objetivo. Realizan las tareas principales.
Secundarios:
Supervisan
y mantienen el sistema. El sistema necesita de ellos para satisfacer un objetivo. Existen para que los primarios puedan utilizar el sistema.
ACTORES Clasificacin
16
Ejemplo:
Alumno
Realizar preinscripcin
Gestin expedientes
Actor Principal
Matriculacin
Entidad Bancaria
Actores Secundarios
SUJETOS Definicin
17
El sujeto es el elemento descrito por un conjunto de casos de uso.

Representa al sistema que se est modelando. Se representa por un rectngulo que rodea a los casos de uso. Cualquier elemento con comportamiento puede ser descrito en base a casos de uso
Cliente
Pedido Telefnico
Comprobar estado Vendedor Realizar Pedido
Distribuidor
Distribuir Pedido
Establecer crdito
Supervisor
FLUJOS DE EVENTOS Definicin

18
El comportamiento de un CU se puede especificar mediante un Flujo de Eventos descripcin del funcionamiento:

Forma
textual (fases iniciales). Diagramas de interaccin o actividad (fases avanzadas)
La descripcin debe incluir:

Cmo
y cundo empieza y acaba el caso de uso. Cundo interacta con los actores y qu objetos se intercambian. El flujo normal y los flujos alternativos del comportamiento.
FLUJOS DE EVENTOS Especificacin

19
Se realiza mediante documentos de texto. Alternativas:

Texto
estructurado informal Texto estructurado formal (plantillas) Pseudocdigo Notaciones grficas: diagramas de secuencia

Debe ser legible y comprensible. Debe indicar (como mnimo):

Actores Flujo
principal Flujos excepcionales.

FLUJOS DE EVENTOS Contenido de la especificacin

20
Suele incluir:
Descripcin
Reflejando
general.
uno o varios requisitos funcionales del
sistema.
Pre-condiciones
Condiciones
que deben cumplirse para que se realice el caso de uso. que se cumplen posteriormente al caso
Post-condiciones:
Condiciones
de uso.
Escenarios
Con
la descripcin de todos los flujos de eventos posibles.

FLUJOS DE EVENTOS Contenido de la especificacin

21
Ejemplo de contenido de una especificacin
FLUJOS DE EVENTOS Tipos de especificacin

22
Durante el proceso de desarrollo se emplean dos formatos para los casos de uso:
Formato Formato
Ms
de Alto Nivel (o bsico):

rpida.
Descripcin
Expandido (o extendido):
detalles. Facilita la comprensin de los procesos.
El encabezado y estructura son tpicos, aunque UML no especfica un formato rgido.

23
Formato de Alto Nivel:

Caso de Uso: nombre del caso de uso Actores: lista de actores (agentes externos). Tipo:

Primario, secundario y opcional. Esencial o real. Este caso de uso inicia cuando <actor> <inicia un EVENTO>. Realizar Venta Cliente, Cajero Primario y esencial Un cliente llega a la caja con los productos que desea comprar. El cajero registra la compra y recoge el pago. Al finalizar, el cliente se lleva los productos.
Resumen: narracin de lo que hacen los actores.
Caso de uso: Actores: Tipo: Resumen:

24
Formato expandido

Caso de Uso: nombre del caso de uso Actores: lista de actores, indicando tipo (principal o secundario). Propsito: intencin del caso de uso Resumen: misma descripcin del caso de uso de alto nivel o algn resumen similar. Tipo:

Primario, secundario y opcional. Esencial o concreto.
Referencias: a las funciones del sistema y los casos de uso relacionados. Pre-condiciones Post-condiciones Flujo de Eventos Principal Flujos Alternativos

25
Ejemplo de Formato expandido

Caso de uso Actores Propsito Resumen Realizar venta en metlico (en un TPV) Cajero (principal), Cliente (secundario) Capturar una venta y su pago en metlico Un cliente llega al TPV con un conjunto de artculos. El cajero registra los artculos y se genera un ticket. El cliente paga en efectivo y recoge los artculos. Primario y esencial Funciones: F1.1, F1.2, F1.3, F1.7, F1.9, F2.1,... (especificadas en los requisitos) El cajero est autentificado en el sistema Se registra la venta. Se calcula el impuesto. Se actualiza la contabilidad y el inventario
Tipo Referencias Pre-condiciones Post-condiciones

26
Ejemplo de Formato expandido (flujo bsico)

Accin de los actores
1. El caso de uso comienza cuando un nuevo cliente accede al punto de venta. 2. El cajero inicia una nueva venta 3. El cajero registra el identificador de cada producto. Si hay varios items del producto, el cajero puede introducir la cantidad tambin. 4. Determina el precio del producto y aade el producto a la venta en curso. Se visualizan la descripcin, el precio del producto y la suma parcial. 6. Calcula y visualiza el total de la venta.
Flujo de eventos principal
Respuesta del sistema
El cajero repite los pasos 3 y 4 hasta que se indique. 5. Al completar la entrada de productos el cajero se lo indica al sistema 7. El cajero indica al cliente el precio total. 8. El cliente entrega una cantidad de dinero. 9. El cajero registra la cantidad recibida 11. El cajero entrega el dinero del cambio y el recibo al cliente 13. El cliente retira los productos.
10. Visualiza la cantidad a devolver al cliente. Genera un recibo 12. Se registra la venta completada y se actualiza el inventario

27
Ejemplo de Formato expandido (flujos alternativos)

A1: Identificador no vlido
La secuencia comienza en el punto 3. El escenario vuelve al punto 3. A2: El cliente pide eliminar un artculo de la compra La secuencia puede ocurrir entre los puntos 3-6 1. El cajero introduce identificador a eliminar. El escenario contina en el punto 6. A3: El cliente no tiene suficiente dinero La secuencia comienza en el punto 8. 9. El cajero cancela la compra El escenario termina 10. El sistema cancela la operacin y vuelve al estado de reposo 2. El sistema actualiza la suma. 4. El sistema seala el error y rechaza la entrada
Flujos alternativos
FLUJOS DE EVENTOS Representacin grfica

28
Se puede representar tambin grficamente
Cajero
Realizar Venta
Cliente
Sistema Cajero crearNuevaVenta() *introducirItem(upc, cantidad) finalizarVenta() hacerPago()
Interacciones
RELACIONES Tipos
29
Generalizacin
Un cdu hereda el comportamiento y significado de otro Un cdu base incorpora explcitamente el comportamiento de otro en algn lugar de su secuencia. Un cdu base incorpora implcitamente el comportamiento de otro Caso de Uso en el lugar especificado indirectamente por este otro Caso de Uso
RealizarPedido Extension Points Establecerprioridad <<Include>> ComprobarClave
Inclusin
Extensin
EXTENSIN
<<Extend>>
INCLUSIN
RealizarPedidoUrgente
ValidarUsuario <<Include>>
GENERALIZACIN
ConsultarPedido
ExaminarRetina
RELACIONES Generalizacin
30
Relaciona un caso de uso especializado con uno ms general. El caso de uso hijo hereda el comportamiento y el significado del caso de uso padre.
El C.U. A es una especializacin del C.U. B. Todo lo que se haya definido que se va a ejecutar para B se ejecutar tambin para A.
CASOA CASOB
El caso hijo puede:

Aadir o redefinir el comportamiento del padre. Ser colocado en cualquier lugar donde aparezca el padre.
RELACIONES Generalizacin
31
Ejemplo
ValidarUsuario
ComprobarClave
ExaminarRetina
ValidarUsuario:Flujodeeventosprincipal ComprobarClave:Flujodeeventosprincipal ObtenercontraseasdeBBDD Pediralusuariocontrasea Elusuariointroducelacontrasea ComprobarsilacontraseaintroducidacoincideconladelasBBDD ExaminarRetina:Flujodeeventosprincipal ObtenerlecturasderetinasdeBBDD Escanearlaretinadelusuarioyobtenerlecturaderetina ComprobarsilalecturaderetinadelusuariocoincideconladelasBBDD
RELACIONES Inclusin
32
Se usa para evitar describir el mismo flujo de eventos repetidas veces Se saca el comportamiento comn

Si los casos de uso A y B presentan una parte comn, sta se puede sacar a un tercer caso de uso C. SIEMPRE que se ejecuta el caso de uso A o B, se ejecuta el caso de uso C Para especificarla en el flujo de eventos se debe escribir include seguido del nombre del caso de uso que se quiere incluir. Los casos incluidos son casos de uso en s mismos, aunque NO son casos de uso normales no son activados por un actor
CASOA <<Include>> CASOC <<Include>> CASOB
RELACIONES Inclusin
33
Ejemplo
<<Include>>
Realizarseguimientopedido
ValidarUsuario
Realizarseguimientopedido:Flujodeeventosprincipal ObteneryVerificarelNmerodePedido Include (ValidarUsuario) Examinarelestadodecadapartedelpedido Prepararuninformeparaelusuario
RELACIONES Extensin
34
Un caso extiende el comportamiento de otro caso (base).
Un caso de uso puede tener varios puntos de extensin.
Si una condicin es cierta se necesita otro caso de uso para completar su conducta. El caso de uso extendido es un uso de caso normal, que suele ser activado por un actor. Sirve para modelar
La parte opcional del sistema. Un subflujo que slo se ejecuta bajo ciertas condiciones. Varios flujos que se pueden insertar en un punto.
RELACIONES Extensin
35
Esquema
CasoA Extension Points HacerB <<Extend>> B
Ejemplo
RealizarPedido Extension Points Establecerprioridad <<Extend>> RealizarPedidoUrgente
Realizarpedido:Flujodeeventosprincipal Include (ValidarUsuario) ObtenerlosproductospedidosporelCliente (establecerprioridad:puntodeextensin) Enviarelpedido

RELACIONES Extensin
36
Ejemplo Devolucin de un libro
Modelar mediante casos de uso el proceso de devolucin de un libro en una biblioteca. Tener en cuenta que:

La devolucin se hace a travs del bibliotecario. Se pondr una multa a las devoluciones realizadas fuera de plazo.
MODELADO DE CASOS DE USO Pasos

37
1) Identificar las fronteras del sistema 2) Identificar los Actores.

Requieren ayuda del sistema para llevar a cabo sus tareas Son necesarios para ejecutar las funciones del sistema Interactan con el hardware externo o con otros sistemas. Realizan funciones secundarias de administracin y mantenimiento
3) Organizar actores (generalizaciones) 4) Identificar los Casos de uso de cada Actor 5) Estructurar los casos de uso Inclusiones y exclusiones 6) Adornar los casos de uso Notas adicionales 7) Especificar el comportamiento textos y diagramas 8) Revisar
MODELADO DE CASOS DE USO Recomendaciones

38
Escribir casos de uso independientes de la interfaz o de detalles de implementacin, escribirlos a nivel esencial Centrarse en el qu no en el cmo. Comprobar que los casos de uso incluyen toda la funcionalidad del sistema. Mantener la validez y consistencia del conjunto de casos de uso. Cada CU debe representar un comportamiento distinto e identificable del sistema o de una parte del mismo.
MODELADO DE CASOS DE USO Recomendaciones

39
Recomendaciones de representacin :

Asignarle un nombre que comunique su propsito. Distribuir sus elementos para minimizar los cruces de lneas. Organizar sus elementos espacialmente para que los comportamientos y roles semnticamente cercanos se encuentren cercanos fsicamente. Utilizar las notas y los colores como seales visuales. Mostrar slo los CU y actores relevantes. Intentar no mostrar demasiados tipos de relaciones
MODELADO DE CASOS DE USO Ejercicio

40
Sistema de validacin de tarjetas de crdito
Este sistema se encarga de la gestin del proceso de compras con las tarjetas de crdito del banco. Cuando el cliente realiza una compra y paga con tarjeta el sistema se encarga de realizar la transaccin de la compra, para lo que necesita introducir su n secreto. El sistema realiza el cargo a la cuenta del banco del cliente, en su momento el banco del cliente se encargar de traspasar el dinero a la cuenta del comercio. El sistema se encarga de imprimir un recibo de la compra tanto para el cliente como para el comercio.
MODELADO DE CASOS DE USO Utilidad

41
Hay consenso en considerar casos de uso como esenciales para capturar requisitos y guiar el modelado. Pero todava existe mucha confusin sobre cmo usarlos.
Cul
es el nmero de casos de uso apropiado en un proyecto? Qu casos de uso hay en el sistema?
MODELADO DE CASOS DE USO Granularidad

42
Diferente granularidad complejidad Reglas:

1) No mostrar ms de 15 casos 2) Particionar los grficos por actor. 3) Si las relaciones de inclusin y las extensiones entran en el diagrama principal dejarlas ah. (igual para los actores abstractos) 4) Si las relaciones de inclusin no entran mostrarlas en grficos auxiliares incluyendo a todos los c.u. que incluyen a otro en un mismo diagrama. 5) Si un caso de uso es incluido por gran parte de los otros casos evitar mostrarlo en el grfico principal.
MODELADO DE CASOS DE USO Granularidad

43
Un caso de uso se puede asociar a un objetivo del usuario o a una interaccin bsica con el sistema. Se debe definir un caso de uso por cada objetivo del usuario. Se distinguen:
Casos de uso del negocio
Procesos de Negocio: Objetivo estratgico de la empresa
Ej. Venta productos
Casos de uso del sistema
Objetivo de un usuario
Ej. Realizar una compra
Casos de uso de inclusin
Forman parte de otro caso de uso, son como subfunciones
Ej. Buscar, Validar, Login

MODELADO DE CASOS DE USO Ejercicio

44
Granularidad apropiada para un caso de uso:

Sirven
para planificar el proyecto Se les asocia un flujo de interacciones actorsistema Deben ser objetivos del usuario
En un sistema de venta por internet, son casos de uso?

Aadir
producto seleccionado al carro de la
compra Introducir datos facturacin

MODELADO DE CASOS DE USO Ordenacin

45
El desarrollo de un software se organiza alrededor de los casos de uso deben de ser ordenados por importancia relativa los primeros ciclos se deben tratar los ms relevantes Se puede asignar una puntuacin en cada apartado a cada caso de uso y despus asignar una prioridad (orden)
Ejemplo: alta, media, baja
Se deben tratar antes los casos de uso de prioridad alta
MODELADO DE CASOS DE USO Ordenacin

46
Aspectos a valorar para la ordenacin. Impacto sobre el diseo arquitectnico. Aportacin de informacin significativa (o grande) sobre el diseo con poco esfuerzo. Incluir funciones complejas o crticas. Implicar mucha investigacin o nueva tecnologa. Representar lneas fundamentales de negocio. Aporte importante de ingresos (o reduccin de costes).
RECOMENDACIONES Y ERRORES Casos de Uso

47
Especificar no es dibujar sino describir con el detalle necesario el flujo principal y los flujos alternativos: centrado en la escritura en vez del dibujo El objetivo inicial es identificar los actores y a partir de sus objetivos encontrar los casos de uso el diagrama de casos de uso es una ayuda visual. El texto de los casos de uso debe ser claro. Un error comn es no identificar como casos de uso las tareas que inicia el propio sistema (Actor Tiempo)
Anular reservas pasados quince das

<<15 das>>
Realizar Venta Tiempo


48
Un caso de uso debe tener una granularidad apropiada, pues especifica una interaccin en la que se produce un resultado de valor para un actor.
No identificar interacciones que forman parte de una mayor como casos de uso de inclusin.
Cuidado con el empleo de la relacin include. No hacer una descomposicin funcional! No abusar de las relaciones de extensin. La relacin utilizarse. de generalizacin no debera

49
Ejemplo de mal uso
< < inc lude> >
A adir libro
< < inc lude> > M antener libros
E lim inar libro < < inc lu de> >
< < inc lude> > < < inc lude> >
A a dir pet ic in
B i bliot ecario
G es tionar bibliotec a
Ma ntener p etic io nes
< < inc l ude> >
< < inc lude> >
E l imi nar pet ic i n
< < inc lude> > Devolver libro
M antener pres tam os
< < inc lude> >
P res tar libro

50
No incluir como casos de uso las operaciones CRUD sobre un objeto de negocio (alta, consulta, borrado, actualizacin).
CRUD
es el acrnimo de Crear, Obtener, Actualizar y Borrar (Create, Retrieve, Update y Delete, en ingls).
La excepcin es si se trata de operaciones relevantes para el sistema

Ejemplo:
Registrar Cliente en un sistema de venta por Internet.


51
Evitar definir casos de uso que no lo son

No
hay actor que lo ejecute Es un procedimiento interno del sistema Ocurre normalmente al buscar includes o extends
REGLA DE ORO Un Caso de Uso es funcionalidad del sistema que proporciona algn resultado o valor a por lo menos a un actor.

52
Realizar Matrcula
Estudiante
Sistema
FLUJODEEVENTOS: ElestudianteintroduceelDNI, Sealmacenanlosdatosdelasmatrculasenelsistema,
Error: No se trata de un sistema externo sino del propio sistema (el c.u. es parte de l)

53
Realizar Matrcula <<includes>> Estudiante Seleccionar asignatura
Error: Si al realizar la matrcula, se van seleccionando (en la interfaz) asignaturas en las que matricularse NO ES CASO DE USO

54
<<includes>> Imprimir informes
Imprimir informe
Estudiante
FLUJODEEVENTOS: Elempleadoproporcionasuidentificador Seseleccionanlosinformesdelempleadoannoimpresos Seimprimecadaunodeellos
Error: Imprimir informe es una subfuncin de imprimir informes por tanto no es caso de uso.

55
Posible excepcin: generalizacin

Ingresar Dinero Realizar Transaccin Cliente
Retirar Dinero
FLUJODEEVENTOSDEREALIZAR TRANSACCION: Identificarcliente Obtenersunmerodecuenta Comprobarquelacuentano estbloqueada
En este caso no parece que Realizar Transaccin sea un CASO DE USO REAL, pero PUEDE resultar TIL para no repetir muchos flujos de eventos. Puede ocurrir en el caso de GENERALIZACIN .

56
Varios actores principales sobre el caso de uso

Solicitar Carnet Deportivo
Estudiante
Sistema Bancario
Profesor
Y si los profesores tambin pueden solicitar carnet deportivo? Pueden utilizar el mismo caso de uso?
NO, ya que eso significa que los 3 actores participan en el caso de uso y eso no es lo que queremos

57
Solucin 1: Casos de uso distintos ?
Solicitar Carnet Deportivo Estudiante Estudiante Sistema Bancario Solicitar Carnet Deportivo Profesor Profesor

58
Solucin 2: Generalizacin entre actores (mejor)
Solicitar Carnet Deportivo
Universitario
Sistema Bancario
Estudiante
Profesor
CASO DEL LOGIN Solucin 1

59
1) El caso LOGIN incluye todos los otros casos que deben ser seguros
Supone:
Actualizar el diagrama Escribir en el texto del caso de uso login referencias al resto de casos de uso (include). El resto de casos de uso no se modifican.

60
Beneficios:
La
representacin de casos de uso se parece a lo que el diseador espera.
Inconvenientes:
El
texto del caso de uso es difcil de mantener en el caso que se introduzcan nuevos casos de uso. es bueno que el LOGIN tenga conocimiento de todas las otras partes del sistema.
No

61
2) Lo otros casos de uso incluyen al caso LOGIN

Supone:
Actualizar
el diagrama Escribir en el texto del caso de uso del resto de casos de uso

62
Beneficios:
El
caso de uso LOGIN describe slo el proceso de identificacin y nada ms.
Inconvenientes:
El
diagrama y los casos de uso hacen entender que el cliente debe identificarse cada vez que quiere hacer algo.

63
3) Lo otros casos de uso extienden al caso LOGIN

Supone:
Actualizar
el diagrama Escribir en el texto del caso de uso LOGIN las referencias a los casos extendidos

64
Beneficios:
El
cliente se identifica una vez y desde all se accede al resto del sistema. LOGIN aade un punto de extensin, pero eso es todo, no es necesario cambiarlo cuando se aaden nuevos casos de uso.
Inconvenientes:
La
descripcin de la extensin. Puede ser una relacin difcil de explicar, especialmente para gente que no es desarrolladora.

65
4) LOGIN extiende a los otros casos de uso

Supone:
Actualizar
el diagrama Escribir en el texto del resto de casos de uso la extensin.

66
Beneficios:
El
caso de uso LOGIN describe slo el proceso de identificacin y nada ms.
Inconvenientes:
La
descripcin de la relacin de extensin puede ser difcil de explicar, especialmente para gente que no es desarrolladora. Todos los casos de uso tienen que aadir el punto de extensin.

67
5) LOGIN se utiliza como un caso independiente

El caso de LOGIN es totalmente independiente del resto de casos, pero se incluye en el resto de casos la precondicin que el usuario debe estar identificado. Supone:
Actualizar el diagrama Escribir en el texto del resto de casos de uso la precondicin.

68
Beneficios:
El caso de uso LOGIN describe slo el proceso de identificacin y nada ms. El diagrama y el texto es claro y fcil de comprender y el sistema es ms flexible. El resto de casos de uso no requieren de LOGIN para ejecutarse, slo un usuario vlido identificado. Ejecutar LOGIN es un modo para ser un usuario vlido pero podran existir otros mtodos de validacin.
CONCLUSIONES:
La ltima aproximacin parece la ms fcil de leer y la ms flexible, sin embargo todas son correctas el desarrollador debe escoger la que mejor se adapta a su proyecto.
EJEMPLOS Maquina de reciclaje

69
Requisitos de una Mquina de Reciclaje

Se trata de construir un sistema que controle una mquina para reciclar latas, botellas y cajas de botellas. La mquina puede ser utilizada por varias personas a la vez. El sistema registra cuntos elementos devuelve cada usuario e imprime un recibo con el valor de los elementos devueltos y el total a pagar al usuario. El sistema tambin lo utiliza un operador que desea conocer el nmero de elementos de cada tipo que se han introducido durante el da. Tambin debe poder actualizar los valores de los elementos. El sistema llamar al operador cuando se acabe el papel de los recibos o si detecta algn problema con los elementos introducidos

70
Diagrama de Casos de Uso

71
Especificacin de alto nivel

Actores: Usuario (principal). Escenario Principal (Flujo Bsico): Se inicia cuando el usuario desea reciclar latas, botellas, o cajas. Por cada elemento que el usuario introduce, la mquina incrementa el nmero de elementos de ese tipo que el usuario lleva reciclados as como el nmero total de elementos reciclados en el da de dicho tipo. Cuando el usuario ha depositado todos los elementos a reciclar, pulsa el botn de obtencin de recibos, resultado de lo cual el sistema imprime un recibo al usuario con el total de elementos reciclados de cada tipo y la cantidad total a cobrar. Extensiones (Flujos Alternativos): Si el elemento a reciclar no es una botella, lata o caja, el sistema muestra el mensaje Elemento no vlido. Si no queda papel de recibo se ejecuta el C.U. Fin Papel Recibo. Si hay algn problema se ejecuta el C.U. Problema elemento
Reciclar Elemento
EJEMPLOS Terminal Punto de Venta (TPV)

72
Especificacin de alto nivel

Actores: Usuario (principal). Escenario Principal (Flujo Bsico): Se inicia cuando el usuario desea reciclar latas, botellas, o cajas. Por cada elemento que el usuario introduce, la mquina incrementa el nmero de elementos de ese tipo que el usuario lleva reciclados as como el nmero total de elementos reciclados en el da de dicho tipo. Cuando el usuario ha depositado todos los elementos a reciclar, pulsa el botn de obtencin de recibos, resultado de lo cual el sistema imprime un recibo al usuario con el total de elementos reciclados de cada tipo y la cantidad total a cobrar. Extensiones (Flujos Alternativos): Si el elemento a reciclar no es una botella, lata o caja, el sistema muestra el mensaje Elemento no vlido. Si no queda papel de recibo se ejecuta el C.U. Fin Papel Recibo. Si hay algn problema se ejecuta el C.U. Problema elemento
Reciclar Elemento

73
REQUISITOS
Funcin
Registrar la venta, los productos comprados Calcular el total de la venta, incluyendo impuesto y descuentos.
Ref.
F1.1 F1.2 F1.3 F1.4 F1.5 F1.6 F1.7 F1.8 F1.9 F1.10
Categora
Evidente Evidente
Capturar informacin de los productos mediante el cdigo de barras o manualmente, Evidente mediante la introduccin del UPC. Reducir las cantidades del inventario cuando se realiza una compra Guardar un histrico de las ventas realizadas Identificar al cajero mediante un cdigo de acceso al sistema Proporcionar almacenamiento permanente de la informacin Proporcionar mecanismos de comunicacin entre procesos en el interior del sistema Visualizar datos y precio de los productos registrados Manejar pago en efectivo, calculando devolucin del pago Oculta Oculta Evidente Oculta Oculta Evidente Evidente

74
PROTOTIPADO
Datos del producto Datos de la venta

75
MODELADO DE CASOS DE USO

76
DESCRIPCION DE ALTO NIVEL
Caso de uso: Actores: Tipo: Resumen:
Realizar Venta Cajero y Stock Primario y esencial Un cliente llega a la caja con los productos que desea comprar. El cajero registra la compra y recoge el pago. Al finalizar, el sistema actualiza el stock y el cliente se lleva los productos.

77
DESCRIPCION EXTENDIDA
Caso de uso Actores Propsito Resumen Realizar Venta (en metlico) Cajero y Stock Capturar una venta y su pago en metlico Un cliente llega a la caja con los productos que desea comprar. El cajero registra la compra y recoge el pago. Al finalizar, el sistema actualiza el stock y el cliente se lleva los productos. Primario y esencial Funciones: F1.1, F1.2, F1.3, F1.7, F1.9, F1.10,...
Tipo Referencias Pre-condiciones Post-condiciones

78
Flujo de eventos principal Accin de los actores 1. El caso comienza cuando un cajero inicia una nueva venta al llegar un cliente Respuesta del Sistema
3. Determina el precio del producto y 2. El cajero registra el identificador de cada aade el producto a la venta en curso. producto. Si hay varios items del producto, el Se visualizan la descripcin, el precio cajero puede introducir la cantidad tambin. del producto y la suma parcial. El cajero repite los pasos 2 y 3 hasta que se indique. 4. Al completar la entrada de productos el 5. Calcula y visualiza el total de la cajero se lo indica al sistema venta. 6. El cajero indica al cliente el precio total. 7. El cliente entrega una cantidad de dinero. 9. Visualiza la cantidad a devolver al 8. El cajero registra la cantidad recibida cliente. Genera un recibo. 10. El cajero entrega el dinero del cambio y el 11. Se registra la venta completada y recibo al cliente se actualiza el inventario del stock.

79
Flujos alternativos
A1: Identificador no vlido La secuencia comienza en el punto 2. El escenario vuelve al punto 2. A2: El cliente pide eliminar un artculo de la compra La secuencia puede ocurrir entre los puntos 2-5. 1. El cajero introduce identificador a 2. El sistema actualiza la suma. eliminar. El escenario contina en el punto 5. A3: El cliente no tiene suficiente dinero La secuencia comienza en el punto 7. 8. El cajero cancela la compra. El escenario termina 9. El sistema cancela la operacin y vuelve al estado de reposo. 3. El sistema seala el error y rechaza la entrada.

Gitxisxt4xplanificacion y Casos de Uso

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Gitxisxt4xplanificacion y Casos de Uso

Cargado por

Copyright:

Formatos disponibles

TEMA 4 PLANIFICACIN Y CASOS DE USO

INGENIERIA DEL SOFTWARE

5 RECOMENDACIONES Y ERRORES 6 EJEMPLO DEL CASOS DE USO DEL LOGUIN

4 MODELADO DE CASOS DE USO

La primera tarea es el Estudio de Viabilidad del Sistema.

Casosde Uso Expresarlos requisitos Investigary comprenderel problema

Planificarla estrategiaa seguir

Escola Tecnica Superior de Engineria

El Prototipo inicial desechable.

CASO DE USO: TOMAR COPIA LIBRO EN PRSTAMO

Escola Tecnica Superior de Engineria

PLANIFICACIN Casos de Uso

el comportamiento deseado del

sistema Describen qu hace el sistema, no cmo lo hace.

Inician y guan todo el proceso de desarrollo. Ayudan a:

Escola Tecnica Superior de Engineria

Un Caso de Uso (CU) debe tener un Nombre:

Escola Tecnica Superior de Engineria

Segn el nivel de abstraccin

Escola Tecnica Superior de Engineria

(hardware) otros sistemas (software)

Se pueden organizar en categoras (generalizacin)

Responsable prstamos Empleado Banca Cajero

Escola Tecnica Superior de Engineria

Un actor puede intervenir en varios casos de uso.

Puede haber ms de un actor asociado a un mismo caso de uso

Escola Tecnica Superior de Engineria

El sujeto es el elemento descrito por un conjunto de casos de uso.

Comprobar estado Vendedor Realizar Pedido

Escola Tecnica Superior de Engineria

FLUJOS DE EVENTOS Definicin

El comportamiento de un CU se puede especificar mediante un Flujo de Eventos descripcin del funcionamiento:

textual (fases iniciales). Diagramas de interaccin o actividad (fases avanzadas)

La descripcin debe incluir:

FLUJOS DE EVENTOS Especificacin

Se realiza mediante documentos de texto. Alternativas:

Debe ser legible y comprensible. Debe indicar (como mnimo):

principal Flujos excepcionales.

FLUJOS DE EVENTOS Contenido de la especificacin

la descripcin de todos los flujos de eventos posibles.

FLUJOS DE EVENTOS Contenido de la especificacin

Ejemplo de contenido de una especificacin

Escola Tecnica Superior de Engineria

FLUJOS DE EVENTOS Tipos de especificacin

de Alto Nivel (o bsico):

detalles. Facilita la comprensin de los procesos.

El encabezado y estructura son tpicos, aunque UML no especfica un formato rgido.

Escola Tecnica Superior de Engineria

FLUJOS DE EVENTOS Tipos de especificacin

Formato de Alto Nivel:

Resumen: narracin de lo que hacen los actores.

Caso de uso: Actores: Tipo: Resumen:

Escola Tecnica Superior de Engineria

FLUJOS DE EVENTOS Tipos de especificacin

Primario, secundario y opcional. Esencial o concreto.

FLUJOS DE EVENTOS Tipos de especificacin

Ejemplo de Formato expandido

Tipo Referencias Pre-condiciones Post-condiciones

Escola Tecnica Superior de Engineria

FLUJOS DE EVENTOS Tipos de especificacin

Ejemplo de Formato expandido (flujo bsico)

Flujo de eventos principal

Respuesta del sistema

FLUJOS DE EVENTOS Tipos de especificacin