Estimados estudiantes:

Les muestro algo de teora y algunos ejemplos sobre CU. Este viernes, todos los grupos deben entregar: 1. Una explicacin narrativa de alto nivel sobre lo que har su sistema, como introduccin a su diagrama de casos de uso de su sistema entero. 2. Diagrama de Casos de uso bien hecho (pasos 3 y 4) 3. Los casos de uso de alto nivel ( paso 5) 4. Por donde han decidido empezar y por qu? El paso 6 pueden dejarlo para las iteraciones ( de todos sus CU deben tener el modelo expandido) , sin embargo cuanto antes se empapen del dominio del sistema mejor, de hecho con cada iteracin mejorar su comprensin del sistema. Y se espera que al final de la segunda o tercera iteracin, el modelo de casos de uso est completo. Lo que quiere decir que tienen el diagrama completo (seguramente mejor que el inicial) y los casos de uso expandidos de todo el sistema.

Casos de uso

Ofrecen un medio sistemtico e intuitivo para capturar los requisitos funcionales, centrndose en el valor aadido para el usuario Dirigen todo el proceso de desarrollo puesto que la mayora de las actividades (planificacin, anlisis, diseo, validacin, test,..) se realizan a partir de los casos de uso. Mecanismo importante para soportar trazabilidad entre modelos.
Los diagramas de caso de uso son uno de los cinco diagramas en UML para modelar los aspectos dinmicos del sistema (diagramas de actividad, diagramas de estado, diagramas de secuencia y diagramas de colaboracin son los otros cuatro). Los diagramas de caso de uso son centrales para modelar el comportamiento de un sistema, subsistema o una clase. Cada uno muestra un conjunto de casos de uso y actores y sus relaciones.

Definicin de caso de uso (CU):

Es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso[jacobson92]. Los casos de uso son historias o casos de utilizacin de un sistema; no son exactamente los requerimientos y las especificaciones funcionales, si no que ejemplifican e incluyen tcitamente los requerimientos en las historias que narran [Larman] Ejemplo: Comprar productos Icono de UML para caso de uso Los casos de uso primarios representan los procesos ms comunes ms importantes como comprar productos en un supermercado. Los casos de uso secundarios representan procesos menores o raros; solicitud de surtir un nuevo producto. Los casos de uso opcionales representan procesos que pueden o no abordarse. Caso de uso esencial: Se expresan en forma terica, con oca tecnologa y pocos detalles de implementacin, decisiones de diseo se posponen y abstraen de la realidad, especialmente lo que concierne a la interfaz de usuario [Constantine]. Los CU de alto nivel son de carcter esencial debido a su brevedad y abstraccin Ejemplo: en una descripcin esencial de un cajero: El cliente se identifica

Ing. de Software: Indira Camacho 1

Caso de uso real: Describe concretamente el proceso a partir de su diseo concreto actual sujeto a tecnologas especficas de entrada y de salida Ejemplo: el cliente introduce tarjeta.

Definicin de Actor:
El actor es una entidad externa del sistema que de alguna manera participa en la historia del caso de uso. Por lo regular estimula el sistema (directa o indirectamente) con eventos de entrada o recibe algo de l. Los actores estn representados por el papel que desempean (rol) en el caso, los actores pueden ser personas, secciones/departamentos de la organizacin, mquinas y otros sistemas que interactan con el sistema estudiado. Conviene escribir su nombre con mayscula en la narrativa del caso para facilitar la identificacin. Ejemplo: Para una sistema de contabilidad algunos actores podran ser: Personas: contador, , vendedor, cobrador, auxiliar de contabilidad, Sistemas: Sistema de inventarios, sistema de planillas de sueldo. Departamentos: Depto. Almacenes, Depto.Ventas. Icono para representar actores

Relaciones entre casos de uso: En los diagramas de caso de uso hay que considerar que se pueden dar tres tipos de relaciones, y que son: Generalizacin Un CU hereda el comportamiento y significado de otro Inclusin Un CU base incorpora explcitamente el comportamiento de otro en algn lugar de su secuencia. Permite factorizar un comportamiento en un caso de uso aparte y evita repetir un mismo flujo en diferentes casos de uso. Extensin Un CU base incorpora implcitamente el comportamiento de otro caso de uso en el lugar especificado indirectamente por este otro caso de uso. El caso de uso base incluye una serie de puntos de extensin. El caso de uso base no conoce los casos de uso de extensin, est completo sin las extensiones. Los puntos de extensin no son parte del flujo principal (escenario principal). 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 Ejemplo:

Ing. de Software: Indira Camacho 2

Extensin extend
Realizar Pedido Realizar Pedido Urgente

(establecer prioridad)

include Inclusin
Validar Usuario

Comprobar clave

Generalizacin include
Consultar Pedido Examinar retina

Los actores se muestran por fuera el sistema, no mezclados con los CU. A la izquierda se ponen actores que ingresan datos al sistema y a la derecha se ponen los actores que reciben datos del sistema ( en realidad un CU debera ser de utilidad para algn actor, sino est dems)

Obtencin de casos de uso

Paso 1: Identificar las reglas de negocio
Reglas de negocio: Las reglas de negocio son las tareas, actividades, procedimientos que caracterizan a una organizacin. Son la esencia misma de la organizacin. Ejemplo: En una biblioteca, las actividades esenciales son registrar libro, registrar lector, prestar libro, devolver libro, buscar libro, etc. Ejemplo: En una farmacia registrar medicamento, comprar medicamentos, vender medicamentos, manejar inventarios, manejar proveedores, reporte de ventas, reporte de compras, stock mnimo, colocar inyectables, etc.

Paso 2: Identificar los usuarios del sistema.

Encontrar todos los roles que juegan los usuarios y que son relevantes al sistema. Para cada rol identificar todas las formas (objetivos) de interactuar con el sistema.

Paso 3: Crea un caso de uso por cada objetivo

Estructurar los casos de uso. (Cuidado!) Crea diagrama de casos de uso del sistema

Paso 4: Revisar y validar con el usuario. Paso 5: Crear los casos de uso de alto nivel
Casos de uso de alto nivel:
A partir del diagrama de casos de uso se comienza a desarrollar la narrativa del caso de uso de alto nivel.

Ing. de Software: Indira Camacho 3

Caso de uso de alto nivel: Un CU de alto nivel describe un proceso muy brevemente, casi siempre en dos o tres enunciados. Conviene servirse de este tipo de casos durante el examen inicial de los requerimientos y del proyecto, a fin de entender rpidamente el grado de complejidad y de funcionalidad del sistema. Estos casos son muy sucintos y vagos en las decisiones de diseo [LARMAN]

Plantilla de CU de alto nivel y ejemplo:

Caso de uso: Comprar productos Actores: Cliente, cajero Tipo: Primario Descripcin: Un cliente llega a la caja registradora con los artculos que comprar. El cajero registra los artculos y cobra el importe. Al terminar la operacin el cliente se marcha con los productos. Notar que es conveniente comenzar cuanto antes con los casos de uso de alto nivel para lograr rpidamente entender los principales procesos globales de nuestro sistema

Paso 6: Crear los casos de uso expandidos

Casos de uso expandido:
Describe un proceso con ms detalle que el de alto nivel. La diferencia bsica con el caso de uso de alto nivel consiste en que tiene una seccin destinada al curso normal de los eventos (escenario principal), que lo describe paso por paso. Durante la actividad de especificacin de requerimientos, conviene escribir en el formato expandido los casos ms importantes y de mayor influencia; en cambio los menos importantes pueden posponerse hasta el ciclo de desarrollo en el cual van a ser abordados [LARMAN]

Plantilla de para Casos de uso expandidos

Caso de uso: Nombre del caso de uso Actor Principal: Agentes externos que interactan con el sistema. Se debe indicar quin inicia el caso de uso. Personas involucradas e Intereses : Actores secundarios Precondiciones: Estado del sistema antes de empezar Postcondiciones: Estado del sistema al finalizar. Resumen: Repeticin del caso de uso de lato nivel o alguna sntesis similar. Tipo:

Ing. de Software: Indira Camacho 4

1. Primario, secundario u opcional 2. Esencial o real. Referencias cruzadas: Casos de uso relacionados relacionadas del sistema. Escenario Principal : Flujo Bsico: Describe el curso normal de los eventos y la terminacin exitosa de un proceso. No incluye acciones alternas. Extensiones: Escenarios secundarios o Flujos Alternativos: Muestran alternativas que pueden ocurrir en el nmero de lnea. Descripcin de excepciones. Requisitos especiales: Tecnologa y Lista Variaciones de datos: Frecuencia: Cuestiones pendientes: Ejemplo: En un supermercado en la terminal de venta de artculos: Caso de uso: Comprar productos en efectivo Actor Principal: Cajero Personal Involucrado e Intereses: Cliente que inicia el CU Cajero: quiere entradas precisas, rpida y sin errores de pago Compaa: quiere registrar transacciones y satisfacer clientes. Propsito: Capturar una venta y su pago en efectivo. Precondiciones: El cajero est autentificado. Postcondiciones: Se registra la venta. Se calcula el impuesto. Se actualiza contabilidad e inventario. Resumen: Un Cliente llega a la caja registradora con artculos que desea comprar. El Cajero registra los productos, se genera un recibo y recibe un pago en efectivo. Al terminar la operacin, el Cliente se marcha con los productos comprados. Tipo: Primario y esencial. Referencias cruzadas Curso normal de los eventos: Accin del actor Respuestas del sistema 1. Este caso de uso comienza cuando un Cliente llega a una caja de la Terminal de Venta (TDV), con productos que desea comprar. 2. El Cajero inicia nueva venta 3. El Cajero registra el identificador de cada producto. 4. Determina el precio del producto e incorpora a la transaccin actual la Si hay varios productos de una misma y funciones

Ing. de Software: Indira Camacho 5

Se presentan la descripcin y el precio 5. Al terminar de introducir el producto, del producto actual. el Cajero indica a TDV que se 6. Calcula y presenta el total de la venta. concluy la captura del producto. 7. El Cajero le indica el total al Cliente. 8. El Cliente efecta un pago en efectivo el efectivo ofrecido posiblemente mayor que el total de la venta. 9. El Cajero registra la cantidad de 10. El Sistema registra la venta completa y efectivo recibida. actualiza Inventario. 11. Muestra al la diferencia. Genera un recibo. 12. El Cajero deposita el efectivo recibido y extrae el cambio del pago. 13. Registra la venta concluida. El Cajero da al cliente el cambio y el recibo impreso. 14. El Cliente se marcha con los artculos comprados

categora, el cajero tambin puede introducir la cantidad.

informacin correspondiente.

Cursos alternos Lnea 2: introduccin de identificador invlido. Indicar error. Lnea 3-7: El Cliente pide eliminar un artculo de la compra 1. El Cajero introduce identificador a eliminar 2. El sistema actualiza la suma Lnea 8: el cliente no tena suficiente dinero. Cancelar la transaccin de venta.

Requisitos especiales: - Interfaz de usuario con pantalla tctil en un monitor de pantalla plana. El texto debe ser visible a un metro de distancia. - Tiempo de respuesta para autorizacin de crdito de 30 sg. El 90% de las veces Lista de Tecnologa y Variaciones de Datos: - El identificador podra ser cualquier esquema de cdigo UPC, EAN,.. - La entrada de informacin de la tarjeta se realiza mediante un lector de tarjetas. Cuestiones Pendientes: - Explorar cuestiones de recuperacin de accesos a servicios remotos - Qu adaptaciones son necesarias para diferentes negocios?

Un error comn:

Ing. de Software: Indira Camacho 6

Es representar los pasos operaciones o transacciones individuales como CU, Ejm: en el supermercado se puede definir cono CU imprimir recibo, pero esto es una operacin no un CU, es un paso ms en el CU comprar productos.

Recomendaciones

Especificar casos de uso no es una actividad de dibujar diagramas sino de escribir 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. No abusar de la relacin de inclusin incluye No hacer una descomposicin funcional! Las relaciones de generalizacin y extensin no deberan utilizarse. Un caso de uso debe tener una granularidad apropiada, especifica una interaccin en la que se produce un resultado de valor para un actor. No identificar como caso de uso lo que son interacciones que forman parte de una interaccin mayor que las engloba y no son casos de uso de inclusin. Un error comn es no identificar como casos de uso las tareas que inicia el propio sistema (Actor Tiempo). Ejemplo: Anular reservas pasados quince das No incluir como caso de uso las operaciones CRUD sobre un objeto de negocio (alta, consulta, borrado, actualizacin): funcin del sistema aparte, excepto si se trata de operaciones relevantes para el sistema, como registrar cliente en un sistema de venta por Internet. Escribir casos de uso independientes de la interfaz o de detalles de implementacin,
Ing. de Software: Indira Camacho 7

escribirlos a nivel esencial. Centrarse en el qu no en el cmo. Hay que comprobar que los casos de uso incluyen toda la funcionalidad del sistema. Preocupacin por mantener la validez y consistencia del conjunto de casos de uso. Cada compaa debe tener un manual sobre uso de los casos de uso. Algunos requisitos funcionales no conviene expresarlos como casos de uso.
<<include>> Aadir libro

Ejemplo : Mal uso de CU:

<<include>> Mantener libros

Eliminar libro <<include>>

<<include>> <<include>>

Aadir peticin

Bibliotecario

Gestionar biblioteca

Mantener peticiones

<<include>>

<<include>>

Eliminar peticin

<<include>> Devolver libro

Mantener prestamos

<<include>>

Prestar libro

Ing. de Software: Indira Camacho 8

Ejemplos buenos:

Reservar Libro

Prstamo revista

Profesor

Prstamo Libro

Devolver revista

Socio Devolver libro Actualizar catalogo

Bibliotecario

Extender Prstamo

Consultar

Socio

Otro ejemplo
Registrar curso

Rebajar Mnimo Responsable

Aprobar curso

Servicio CPE

Cerrar curso Crear proyecto Servicio Contabilidad

Fin matriculacion

Realizar preinscripcin

Sistema

Avisar admitidos Alumno

Matriculacin Cancelar curso

Ing. de Software: Indira Camacho 9

Ms especficos

Alumno

Realizar preinscripcin

Gestin Expedientes

Actor Principal
Matriculacin Entidad Bancaria

Actores Secundarios

Ing. de Software: Indira Camacho 10

Los grupos que tienen nota de reprobacin deben entregar hasta el da martes lo siguiente:
5. Organigrama revisado, por cada cargo en el organigrama: el nombre de la persona. Con una tabla con la siguiente informacin: Cargo y nombre de la persona Actividades que realizar Artefactos de su responsabilidad

6. Riesgos que han considerado importantes, solo quiero 2 o 3 riesgos bien gestionados, si consideran que a su proyecto nada le afectar y no existe ningn riesgo, pongan esto con Mayscula: NUESTRO PROYECTO NO TIENE NINGN RIESGO . (la idea es, asumir que el riesgo va ha ocurrir, pero como lo estamos gestionando, no debe afectar al proyecto PREVIENE- ) Riesgo Plan de contingencia Son acciones y actividades que se realizan, antes de que el riesgo ocurra

7. Su sistema de calidad: que harn y como lo harn para asegurarse que lo que estn haciendo es de calidad. El grupo que realiz su presentacin, fue bastante claro en esta parte. 8. Plan de una iteracin 1ra. o 2da. dependiendo donde estn. Si estn muy retrazados deberan reunirse y poner de manifiesto qu es lo que est fallando y cmo solucionarlo (esto tambin puede ser parte de su informe: su experiencia en este proceso: Se me ocurre que el jefe del proyecto podra adems confeccionar una memoria del mismo, con las lecciones aprendidas en esta experiencia.)

Su problema ms grande:
Que piensan que estn trabajando para m. Piensan que lo que estn haciendo no les va ha servir y no lo van a usar. Piensan: Qu lata
hacer documentos no es hacer sistemas!

Y efectivamente lo que me han presentado y tiene nota de reprobacin: no les va ha servir y no lo van a usar. Todo lo que hacen les debe ser TIL y SENCILLO de entender y usar: debe a ayudarles a construir un mejor sistema, en menor tiempo y en menor costo. Si no es as es mejor que no lo hagan. Ejemplo: si su plan de contingencia es solo para mi y no lo ponen en prctica NO LO HAGAN. Pero si se retrazan .yooooo leeeeeees diiiiiiiije !

Bibliografa
The Unified Software Development Process, G. Booch, J. Rumbaugh, I. Jacobson The Unified Modeling language-User Guide, G. Booch, J. Rumbaugh, I. Jacobson The Unified Modeling language-reference Manual, G. Booch, J. Rumbaugh, I. Jacobson UML y Patrones, Craig Larman Ing. de Software: Indira Camacho 11

 UML en 24 horas, Joseph Schmuller The Unified Process -Inception Phase, Scott W. Ambler-Larry L. Constantine Bruegge, B., Dutoit, A.H., Ingeniera del Software Orientado a Objetos

Ing. de Software: Indira Camacho 12