diseño de software - casos de uso
DESCRIPTION
Clase del curso Taller de Ingeniería de Software II - 2011 Del Magister en Tecnologías de Información y Gestión UC - PUCTRANSCRIPT
Yadran Eterovic ([email protected])
MTIG 2010Departamento de Ciencia de la
ComputaciónEscuela de Ingeniería
Pontificia Universidad Católica de Chile
Introducción a losCasos de Uso
1. El problema de los requisitos
Los requisitos son capacidades y condiciones que el sistema debe cumplir
3
El sistema debe mostrar la lista completa de alumnos oficialmente inscritos en el curso ordenada alfabéticamente.
El sistema debe permitir especificar la ciudad o el aeropuerto de origen y la ciudad o el aeropuerto de destino.
El sistema debe asegurar que un mismo asiento de un vuelo en una fecha determinada sea asignado a lo más a un pasajero.
Los requisitos afectan fuertemente al desarrollo de un proyecto de software
El mal manejo de requisitos es una de las causas más comunes de fracaso de los proyectos.
Un pequeño error de requisitos llega a ser un defecto mayúsculo durante la instalación del producto:
corregir estos defectos es muy caro —se ha gastado mucho esfuerzo yendo en una dirección equivocada.
4
5
0.1 – 0.2
0.5
1
2
5
20
durante los requisitos
durante eldiseño
durante laimplementación
durante laspruebas unitarias
durante laspruebas de aceptación
durante elmantenimiento
Costo relativo de corregir defectos enlas diferentes etapas del ciclo de vida
Es difícil manejar los requisitos
Los requisitos son abstractos y muy diferentes de los programas computacionales:
es difícil para gente hábil en los aspectos concretos de la programación identificar bien los requisitos;
los requisitos no se ven reflejados claramente en un módulo del programa.
6
Tenemos que hacer gestión de requisitos
7
Un enfoque sistemático para encontrar, documentar, organizar y seguir la pista a los requisitos, siempre cambiantes, de un sistema.
La gestión eficaz de requisitospresenta varios desafíos
1. Encontrar lo que el cliente y los usuarios realmente necesitan.
2. Comunicar y recordar (es decir, escribir) esas necesidades:
escribirlas de manera clara, tanto para el cliente y los usuarios como para el equipo de desarrollo;
evitar incluir decisiones de diseño o sobre la interfaz de usuario.
8
3. Reducir el número y complejidad de los requisitos:
resolver requisitos en conflicto;eliminar requisitos redundantes;separar los requisitos funcionales de los
no funcionales.
4. Asegurarse de que se le pueda seguir la pista a los requisitos.
9
… además, se da en un contexto de necesidades cambiantes y poco claras
Un proyecto de software típico experimenta entre un 25% y un 50% de cambios en los requisitos:
C. Jones, “Applied Software Measurement”, McGraw-Hill 1997.
En promedio, un 45% de las propiedades de una aplicación, basadas en requisitos congelados al inicio del proyecto, nunca son usadas:
C. Larman, “Agile and Iterative Development: A manager’s Guide”, Addison-Wesley 2003.
10
Hay múltiples tipos de requisitos
Funcionales:características,
capacidades, seguridad.
de Usabilidad:factores humanos,
ayuda, documentación.
de Confiabilidad:frecuencia de fallas,
recuperabilidad, predictibilidad.
de Desempeño:tiempos de
respuesta, tasa de salida, exactitud, disponibili-dad, uso de recursos.
de Soporte:adaptabilidad,
mantenibilidad, internacionalización, configurabilidad.
11
2. Definiciones
Los casos de uso son relatospara describir requisitos funcionales
13
Sirven para descubrir y describir requisitos, principalmente funcionales:
influencian varios aspectos de un proyecto, p.ej., análisis, diseño, testing.
Son relatos de cómo un actor usa un sistema para lograr ciertos objetivos:
son principalmente texto y no diagramas;la idea es simple, pero es difícil descubrir lo
que se necesita y escribirlo bien.
Ejemplo: Caso de uso Consultar Vuelo (formato de un párrafo)
14
El usuario indica que quiere hacer consultas acerca de vuelos. El sistema ofrece opciones para especificar las ciudades de origen y destino y las fechas de ida y regreso. El usuario especifica las ciudades de origen y destino y las fechas de ida y regreso. El sistema muestra una lista de vuelos de ida y una lista de vuelos de regreso, con sus horas de salida y llegada y sus tarifas en cabina económica. El usuario selecciona los vuelos que desea. El sistema muestra el itinerario, las restricciones de equipaje y la tarifa total, incluyendo impuestos.
Ejemplo: Caso de uso Poner Notas(formato de un párrafo)
15
El profesor indica que quiere conectarse a “mi Portal UC”; el sistema le pide información de identificación; el profesor se identifica; y el sistema auten-tifica al profesor. El profesor indica que quiere acceder a su información académica; el sistema presenta la lista de cursos que está dictando durante el presente semestre; el profesor indica que quiere poner las notas de un curso particular; y el sistema presenta la lista de alumnos del curso. El profesor recorre la lista de alumnos calificando a cada uno; al terminar, el profesor indica que quiere grabar las calificaciones; el sistema le pide su firma digital; el profesor ingresa su firma; el sistema autentifica la firma y graba las calificaciones.
Un actor es algo con comportamiento
16
P.ej.,una persona (identificada por su rol con
respecto al sistema): usuario, profesor, etc.;un sistema computacional, p.ej., una base de
datos;una organización.
Hay tres tipos de actores:actores principales;actores secundarios;actores fuera de escena.
Un flujo es un relato particularde cómo usar un sistema
17
Flujo (también, escenario de caso de uso):Una secuencia específica de acciones e
interacciones entre actores y el sistema.Un relato particular de cómo usar un
sistema, o una ruta a través del caso de uso.
P.ej.,el flujo de consultar por un cierto vuelo;el flujo de calificar a los alumnos de un
curso.
Los casos de uso involucran a actores y varios flujos
18
Un caso de uso es una especificación de secuencias de acciones, incluyendo variantes y secuencias de error, que un sistema, subsistema o clase puede realizar interactuando con actores externos.
Un caso de uso es un conjunto de flujos exitosos y fallidos relacionados; cada flujo es una secuencia de acciones que describe a un actor usando el sistema para lograr un objetivo o resultado observable valioso.
Ejemplo: Caso de uso Comprar Pasaje(formato con alternativas, incompleto)
19
Flujo exitoso principal o básico:El pasajero indica que quiere comprar
pasajes para un vuelo; …
Flujos alternativos:Al especificar la forma de pago, el usuario
olvida especificar la marca de la tarjeta de crédito, …
Al pagar con tarjeta de crédito, el usuario ingresa una fecha de expiración errónea, …
Ejemplo: Caso de uso Poner Notas(formato con alternativas, incompleto)
20
Flujo exitoso principal:El profesor indica que quiere conectarse al
sistema “mi Portal UC”; el sistema le pide que se identifique; el profesor se identifica; y el sistema autentifica al profesor. …
Flujos alternativos:El sistema no puede autentificar al profesor, …El profesor ingresa una nota inválida, …El profesor ha dejado a un alumno sin nota, …El sistema no puede autentificar la firma
digital, …
Actores principales:Usan los servicios del sistema
21
Tienen objetivos que se logran usando servicios del sistema ➝ inician la ejecución de los casos de uso:
el pasajero, que quiere consultar por vuelos de Santiago a Punta Arenas;
el pasajero, que quiere comprar los pasajes para un vuelo de Santago a Punta Arenas;
el profesor, que quiere calificar a los alumnos.
Los identificamos para encontrar los objetivos de usuario, que son los que motivan los casos de uso.
Actores secundarios:Proporcionan servicios al sistema
22
Interactúan con el caso de uso después de que éste ha iniciado su ejecución:
la base de datos de vuelos de la línea aérea;
la base de datos de alumnos de la universidad.
A menudo son sistemas computacionales, pero podrían ser organizaciones o personas.
Los identificamos para clarificar interfaces y protocolos externos.
Actores fuera de escena: Tienen interés en la ejecución del caso de uso
23
Tienen interés en el comportamiento del caso de uso, pero no participan directamente:
la Gerencia Comercial de la línea aérea quiere saber cuáles son los destinos más consultados;
la Dirección de Docencia de la Escuela de Ingeniería quiere saber cuántos alumnos han reprobado cursos.
Los identificamos para considerar todos los intereses que afectan al caso de uso:
estos intereses —que no son objetivos de usuario— son fáciles de pasar por alto, si no los explicitamos.
3. Los casos de uso como requisitos en contexto
Diseñemos softwarecentrado en el usuario
25
Empleemos técnicas simples para capturar los objetivos de los usuarios
26
Tenemos objetivos y queremos que los computadores nos ayuden a lograrlos:
consultar por vuelos, poner notas a los alumnos.
Las mejores formas para capturar objetivos son simples y familiares:
facilitan —especialmente a los clientes— contribuir a su definición y revisión, reduciendo el riesgo de equivocarse;
la falta de involucramiento de usuarios es la primera razón por la que los proyectos de software fracasan.
Los casos de uso enfatizanla perspectiva y objetivos del usuario
27
Siempre son iniciados por un actor.
Siempre son escritos desde el punto de vista de los actores.
Para escribirlos, hacemos las siguientes preguntas:
¿Quién va a usar el sistema?¿Cuáles son sus escenarios de uso típicos?¿Cuáles son sus objetivos?
No preguntamos por las características del sistema.
Tomemos la perspectiva del actory su objetivo
28
La frase “un actor usando el sistema para lograr un objetivo o resultado observable valioso”, (diap. # 18) destaca dos actitudes al hacer análisis de requisitos:
escribamos requisitos desde el punto de vista de los actores de un sistema, preguntándonos por sus objetivos y situaciones típicas;
entendamos qué es para el actor un resultado valioso.
La industria está llena de proyectos fallidos que no entregaron lo que la gente quería realmente.
Preguntemos porel objetivo del objetivo
29
Un usuario dice que su objetivo es “ver la pantalla con los selectores de ciudades y fechas”:
el usuario está pensando en una GUI, cajas de diálogo;
este es un mecanismo para lograr un objetivo; no es el objetivo propiamente tal.
Al preguntar “¿Cuál es el objetivo del objetivo?” llegamos a objetivos independientes de un mecanismo:
“Consultar por vuelos entre dos ciudades”.“Comprar pasajes para un vuelo de una ciudad a
otra”.
Al escribir casos de uso,sigamos las siguientes sugerencias
30
Dejemos fuera la GUI:estilo esencial.
No describamos el funcionamiento interno del sistema:
casos de uso de caja negra.
Dejemos fuera la GUI, concentrémonos en la intención del usuario
31
Esta pauta ha ayudado a crear mejores interfaces de usuario y a hacer ingeniería de la usabilidad.
El estilo resultante se llama esencial:la narración es expresada al nivel de las
intenciones del usuario y de las responsabilidades del sistema, y no de sus acciones concretas;
los casos uso en las diaps. # 14, 15, 19 y 20 están escritos siguiendo un estilo esencial.
El estilo esencial deja abiertas las opciones de diseño
32
P.ej., si el caso de uso Poner Notas requiere identificación y autentificación del profesor, escribimos,
…El profesor se identifica.El sistema autentifica la identidad.…
El diseño de la solución para este objetivo y esta responsabilidad está abierto:
lectores biométricos, cajas de diálogo para contraseñas, etc.
El estilo concreto incluye las decisiones de UI en el caso de uso
33
P.ej., Comprar Pasajes lo escribimos asi:El usuario ingresa su número de tarjeta de
crédito, fecha de expiración y código de verificación en los campos de texto y selectores (ver Fig.3).
El sistema verifica la validez de la tarjeta de crédito.
El sistema muestra la página de “Confirmación” (ver Fig. 4).
Los casos de uso concretos pueden ser útiles durante el diseño detallado de la GUI, pero no son apropiados durante el análisis de requisitos.
“Bajamos” con cómoy “subimos” con por qué
34
Meta: Colocar una orden de compra
Paso: Especificar el producto
Subpaso: Ingresar el código
¿Cómo?
¿Cómo?
¿Por qué?
¿Por qué?
Escribamos casos de usode caja negra
35
Los casos de uso de caja negra no describen el funcionamiento interno del sistema, ni sus componentes, ni su diseño.
El sistema es descrito simplemente como teniendo responsabilidades:
tema metafórico unificador común en OO;los elementos de software —objetos,
módulos— tienen responsabilidades y colaboran con otros elementos que también tienen responsabilidades.
Durante el análisis de requisitos evitemos tomar decisiones de “cómo”
36
P.ej.,• Escribamos, “El sistema registra la compra
de pasajes”.
• No escribamos, “El sistema escribe la compra de pasajes en una base de datos”; tampoco, “El sistema genera una sentencia SQL INSERT para la compra de los pasajes”.
Especifiquemos lo que el sistema debe hacer —análisis de requisitos funcionales,
… sin decidir cómo lo hará —diseño de la solución.
Hay varios formatos(y niveles de formalidad)
37
Un párrafo:Resumen de un párrafo del flujo básico; p.ej.,
diaps. # 14 y 15.
Con alternativas:Formato de párrafo informal; múltiples
párrafos que cubren varios flujos; p.ej., diaps. # 19 y 20.
Detallado:Todos los pasos y variaciones están escritos
en detalle, y hay secciones de apoyo, p.ej., pre y poscondiciones.
El formato para el curso
38
Nombre e identificador único.
Proyecto y código de proyecto.
Contexto.
Actor principal.
Actores secundarios (o asociados).
Otros intereses (lista de actores fuera de escena y sus intereses).
Precondiciones.
Resultados esperados (o poscondiciones).
Flujo básico (o principal): descripción de alto nivel y descripción detallada.
Flujos alternativos.
Las pre y poscondicionesrestringen el estado del sistema
39
Precondiciones:condiciones que el estado del sistema debe
cumplir —lo que debe ser verdadero— antes de que el caso de uso pueda ser ejecutado;
son condiciones fuera del alcance del caso de uso, pero dentro del sistema que se está desarrollando.
Poscondiciones:condiciones que el estado del sistema debe
cumplir —lo que deberá ser verdadero— después de que el caso de uso haya sido ejecutado.
Precondiciones: (parte del) Contrato entre el caso de uso y el mundo
40
No son validadas por el caso de uso —se las supone verdaderas:
típicamente, un flujo de otro caso de uso que se ha completado exitosamente.
P.ej., algo dentro del sistema que se está construyendo, pero fuera de este caso uso, que debe haberse establecido o debe estar funcionando o listo para funcionar antes de que este caso de uso pueda ejecutarse.
Resultados esperados(o poscondiciones)
41
También son parte del contrato entre este caso de uso y el mundo exterior.
Después de que este caso de uso se ha completado exitosamente, los resultados esperados son verdaderos
… y deben ser independientes de la ruta alternativa tomada dentro del caso de uso.
No es necesario especificar qué pasa cuando hay un error, p.ej., en el input de un actor.
Flujo básico:Ruta feliz exitosa típica sin condiciones
42
1. El <actor> …2. El sistema …3. El <actor> ……El <actor> repite los pasos 3-4 hasta que indica que ha terminado.…7. El sistema ……
Flujos alternativos:Otras rutas, exitosas o fallidas
43
Un flujo alternativo tiene dos partes: la condición que lo produce y el manejo de la situación.
Escribamos la condición haciendo referencia al número del paso en el flujo básico y como algo que puede ser detectado por el sistema o un actor:
“4a. El sistema detecta que no se puede comunicar con el servicio de validación de cheques”.
El manejo de la situación puede resumirse en un paso o incluir una secuencia.
4. Pasos para encontrarcasos de uso
Para escribir casos de uso,sigamos (aprox.) los siguientes pasos
45
1. Encontremos la frontera del sistema.
2. Encontremos los actores.
3. Identifiquemos los objetivos de cada actor.
4. Definamos casos de uso que satisfagan los objetivos de los actores.
Iteremos hasta que los casos de uso, los actores y la frontera del sistema estén estables.
Paso 1:Encontremos la frontera del sistema
46
En uno de nuestros ejemplos, el sistema de consultas de vuelos es el sistema en estudio:
todo lo que está fuera del sistema de consultas de vuelos está fuera de la frontera del sistema, incluyendo personal del Counter, Pasajero, etc.
La próxima diap. ilustra otras fronteras posibles, más allá del sistema de consulta de vuelos:
para la Línea Aérea, el actor principal es el Pasajero; el personal del Counter es parte del sistema.
Actores y fronteras del Sistema
47
Pasajero
Fronteras del Sistema
Counter
Línea aéreaSistema de Con-sulta de vuelos
Pasos 2 y 3: Encontremos los actores principales y sus objetivos
48
Es artificial tratar de identificar a todos los actores princi-pales estrictamente antes que los objetivos de usuario:
a veces, objetivos revelan a actores, o vice versa;
sugerencia: Preguntémonos acerca de los actores principales primero.
Además de actores y objetivos obvios, las siguientes preguntas (próxima diap.) ayudan a encontrar otros que se nos pueden pasar.
49
¿Quién inicia y detiene el sistema?
¿Quién hace gestión de usuarios y seguridad?
¿Quién hace la administración del sistema?
¿Es el tiempo un actor? (si el sistema responde a eventos de tiempo).
¿Hay un proceso que reinicie el sistema si éste falla?
¿Cómo se actualiza el software?
¿Quién evalúa el desempeño del sistema?
¿Quién evalúa los logs? ¿Son recuperados remotamente?
¿A quién se le notifica cuando hay errores o fallas?
¿Hay sistemas de software o robóticos externos que llamen a los servicios del sistema?
Preguntemos por los objetivos de los actores, no por los casos de uso
50
En vez de preguntar, “¿Qué haces tú?”:las respuestas reflejarán soluciones y
procedimientos vigentes, y las complicaciones asociadas.
… preguntemos, “¿Cuáles son tus objetivos cuyos resultados tienen valor observable?”:
las respuestas posibilitan soluciones nuevas, mejores;
… se concentran en agregar valor de negocio;… y van al corazón de lo que los interesados
quieren del sistema.
Paso 4: Definamos un caso de uso para cada objetivo de usuario
51
Nombremos el caso de uso similarmente al objetivo.
Empecemos el nombre con un verbo.
Los objetivos de crear, recuperar, actualizar, y eliminar <X> pueden mezclarse en un único caso de uso —Manejar <X> :
p.ej., “crear destino”, “eliminar destino”, etc., son todos incluidos en el caso de uso Manejar Destinos.
5. ¿Cómo validar casos de uso?
Hay diferentes niveles de casos de uso
53
¿Cuál de estos es un caso de uso válido?definir una nueva ruta;hacer checkin;conectarse al sistema;ingresar el código de una reserva.
Todos podrían ser casos de uso, pero a diferentes niveles, dependiendo de la frontera del sistema, actores y objetivos.
Validemos el nivel de los casos de uso
54
En lugar de preguntar,“¿Cuál es un caso de uso válido?”
… una pregunta más útil es,“¿Cuál es un nivel apropiado para expresar casos de uso durante el análisis de requisitos?”
Pruebas para validar posibles casos de uso:
La prueba del jefe.La prueba EBP.La prueba del tamaño.
La prueba del jefe: Utilidad para el negocio
55
Si el jefe pregunta, “¿Qué has estado haciendo todo el día?”
… y le contestamos, “Conectándome al sistema”
… ¿va a estar contento el jefe?
Si el jefe no está contento, entonces el caso de uso no pasa la prueba del jefe:
el caso de uso no está relacionado con el logro de resultados de valor medible para el negocio.
La prueba EBP:Complejidad en tiempo y espacio
56
Proceso de negocio elemental (EBP):Una tarea realizada por una persona en un
lugar y de una vez, en respuesta a un evento del negocio, que agrega valor de negocio medible y deja los datos en un estado consistente.
P.ej., Consultar Vuelos, Comprar Pasajes, Hacer Checkin.
Busquemos casos de uso que reflejen EBPs:esta prueba es similar a la del jefe, en
términos de la calificación de valor de negocio medible.
La prueba del tamaño:Extensión de la narración
57
Rara vez un caso de uso es una acción o un paso individual, tal como
ingresar el código de una reserva;borrar una línea;imprimir un documento.
Un caso de uso típicamente contiene varios pasos; en el formato totalmente detallado, puede llegar a tener varias páginas de texto.
¿Qué pasa si aplicamos las pruebasa los casos de la diap. # 53?
58
Definir una nueva ruta:más amplio y demoroso que un EBP;
Hacer checkin:OK con el jefe; parece un EBP; tamaño
apropiado.
Conectarse al sistema:el jefe no está contento si es lo único que
hacemos.
Ingresar el código de una reserva:paso individual —falla la prueba de tamaño.
Hay excepciones razonables
59
Autentificar Usuario falla la prueba del jefe, pero es complejo y requiere un análisis cuidadoso.
¿Falla como EBP un caso de uso si necesita dos personas, o si una persona tiene que caminar de una oficina a otra? Probablemente no.
Casos de uso como subfunciones
60
A veces es útil escribir casos de uso como subfunciones:
subtareas o pasos dentro de un caso de uso al nivel EBP;
p.ej., si “pagar con tarjeta de crédito” aparece en varios casos de uso, lo separamos en su propio caso de uso y lo conectamos a los otros, para evitar duplicación de texto.
6. Aplicando UML a los casos de uso
El diagrama de casos de uso del UML muestra quién hace qué
62
Ilustra los nombres de los casos de uso y de los actores, y las relaciones entre ellos.
Es un diagrama de contexto visual sucinto:muestra la frontera del sistema, los casos de uso
que están dentro, y los actores que están fuera.
Sugerencias:mostrar los actores que son sistemas con una
notación diferente de la de los actores humanos;mostrar los actores principales a la izquierda y
los otros a la derecha.
63
CanjearPremio
ComprarPasajes
HacerCheckin
AnularCompra
ConsultarVuelos
ReservarPasajes
Pasajero
Diagrama deCasos de Uso
«actor»Sistema I«actor»
Sistema I
«actor»Sistema
III
«actor»Sistema
III
«actor»Sistema II«actor»
Sistema II