Dirigido por Casos de Uso-1.ppt

DIRIGIDO POR CASOS DE USO
ÍNDICE
•
•
•
•
•
•
•
•
El Usuario
Los Casos de Uso, su importancia
El aspecto “dirigido-por-casos-de-uso”
Todos los modelos se relacionan
El Modelo de Casos de Uso
El Modelo de Análisis
El modelo de diseño
Ejemplo
EL USUARIO
•
•
•
Un sistema software ve la luz para dar servicio a sus
usuarios.
Por tanto, para construir un sistema con éxito debemos
conocer lo que sus futuros usuarios necesitan.
El término usuario no sólo hace referencia a usuarios
humanos sino a otros sistemas.
El término usuario representa alguien o algo (como otro
sistema fuera del sistema en consideración) que interactúa
con el sistema que estamos desarrollando. Un ejemplo de
interacción sería una persona que utiliza un cajero
automático.
Él usuario inserta la tarjeta de plástico, responde a las
preguntas que le hace la máquina en su pantalla, y recibe
una suma de dinero. En respuesta a la tarjeta del usuario y
a sus contestaciones, el sistema lleva a cabo una secuencia
de acciones que proporcionan al usuario un resultado
importante, (la retirada del efectivo).
EL USUARIO




Una interacción de este tipo es un caso de uso (Capítulo 3).
Un caso de uso es un fragmento de funcionalidad del
sistema que proporciona al usuario un resultado
importante.
Los casos de uso representan los requisitos funcionales.
Todos los casos de uso juntos crean el modelo de casos de
uso (Sección 2.3), el cual describe la funcionalidad total del
sistema.
Puede decirse que una especificación funcional (el modelo)
contesta a la pregunta: ¿Qué debe hacer el sistema?
añadiendo tres palabras al final de esta pregunta: ¿...para
cada usuario?
Regresar
LOS CASOS
DE
IMPORTANCIA
USO,
SU
Estas tres palabras tienen un significado importante.
Nos fuerzan a pensar en términos de importancia para el usuario
y no sólo en términos de funciones que serían bueno tener.
•
•
•
•
Los casos de uso no son sólo una herramienta para
especificar los requisitos de un sistema. También guían su
diseño, implementación, y prueba; esto es, guían el proceso
de desarrollo.
Basándose en el modelo de casos de uso, los
desarrolladores crean una serie de modelos, de diseño e
implementación que llevan a cabo los casos de uso.
Los desarrolladores revisan cada uno de los sucesivos
modelos para que sean conformes al modelo de casos de
uso.
Los ingenieros de prueba prueban la implementación para
garantizar
que
los
componentes
del
modelo
de
implementación implementan correctamente los casos de
uso.
De este modo, los casos de uso no sólo inician el proceso de
desarrollo sino que le proporcionan un hilo conductor.
LOS CASOS
DE
IMPORTANCIA
•
•
•
•
•
USO,
SU
Dirigido por casos de uso quiere decir que el proceso
de desarrollo sigue un hilo —avanza a través de una
serie de flujos de trabajo que parten de los casos de
uso.
Los casos de uso se especifican, se diseñan, y los
casos de uso finales son la fuente a partir de la cual
los ingenieros de prueba construyen sus casos de
prueba.
Aunque es cierto que los casos de uso guían el
proceso, no se desarrollan aisladamente. Se
desarrollan a la vez que la arquitectura del sistema.
Es decir, los casos de uso guían la arquitectura del
sistema y la arquitectura del sistema influye en la
selección de los casos de uso.
Por tanto, tanto la arquitectura del sistema como los
casos de uso maduran según avanza el ciclo de
desarrollo.
Regresar
EL OBJETIVO DEL PROCESO UNIFICADO
Guiar a los desarrolladores en la implementación y
distribución eficiente de sistemas que se ajusten
a las necesidades de los clientes.
• La eficiencia se mide en términos de coste, calidad, y
tiempo de desarrollo.
• El paso desde la determinación de las necesidades del
cliente hasta la implementación no es trivial.
• En primer lugar, las necesidades del cliente no son
fáciles de discernir.
• Esto nos obliga a tener algún modo para capturar las
necesidades del usuario de forma que puedan
comunicarse fácilmente a todas las personas
implicadas en el proyecto.
EL ASPECTO “DIRIGIDO-POR-CASOS-DE-USO”
La Figura 3.1 muestra la serie de flujos de trabajo
y modelos del Proceso Unificado.
• Los
desarrolladores
comienzan
capturando
los
requisitos del cliente en la forma de casos de uso en el
modelo de casos de uso.
• Después analizan y diseñan el sistema para cumplir los
casos de uso, creando en primer lugar un modelo de
análisis, después uno de diseño y después otro de
implementación, el cual incluye todo el código, es
decir, los componentes.
• Por último, los desarrolladores preparan un modelo de
prueba que les permite verificar que el sistema
proporciona la funcionalidad descrita en los casos de
uso.
Regresar
TODOS
•
•
•
•
LOS MODELOS SE RELACIONAN
Los casos de uso se utilizan casi universalmente para la
captura de requisitos de sistemas software, y de sistemas
basados en componentes en particular.
Los casos de uso son mucho más que una herramienta para
capturar requisitos.
Dirigen el proceso de desarrollo en su totalidad.
Los casos de uso son la entrada fundamental cuando se
identifican
y
especifican
clases,
subsistemas
e
interfaces, cuando se identifican y especifican casos de
prueba, y cuando se planifican las iteraciones del desarrollo
y la integración del sistema (Capítulo 10).
Para cada iteración, nos guían a través del conjunto
completo de flujos de trabajo, desde la captura de
requisitos,
pasando
por
el
análisis,
diseño
e
implementación, hasta la prueba, enlazando estos
diferentes flujos de trabajo.
FIGURA 3.1 EL PROCESO UNIFICADO CONSISTE EN UNA SERIE DE FLUJOS DE
TRABAJO QUE VAN DESDE LOS REQUISITOS HASTA LAS PRUEBAS (DE IZQUIERDA
A DERECHA Y DE ARRIBA HACIA ABAJO).
LOS FLUJOS DE TRABAJO DESARROLLAN MODELOS, DESDE EL MODELO DE CASOS
DE USO HASTA EL MODELO DE PRUEBA.
Regresar
EL MODELO

DE
CASOS
DE
USO
La captura de requisitos tiene dos objetivos:
a) encontrar los verdaderos requisitos (véase Capítulo 6), y
 b) representarlos de un modo adecuado para los usuarios,
clientes y desarrolladores.




Entendemos por “verdaderos requisitos” aquellos que
cuando se implementen añadirán el valor esperado
para los usuarios.
Con “representarlos de un modo adecuado para los
usuarios, clientes y desarrolladores” queremos decir
que la descripción obtenida de los requisitos debe ser
comprensible por usuarios y clientes.
Éste es uno de los retos principales del flujo de
trabajo de los requisitos.
Regresar
EL MODELO





DE
ANÁLISIS
Tanto el modelo de análisis como el modelo de diseño son
estructuras compuestas por clasificadores y por un
conjunto de realizaciones de casos de uso (Capítulos 8 y
9) que describen cómo esa estructura hace realidad los
casos de uso.
Los clasificadores son, en general, elementos “parecidos a
clases”.
Por ejemplo, tienen atributos y operaciones, se les puede
describir con diagramas de estados, algunos de ellos
pueden
instanciarse,
pueden
ser
participantes
en
colaboraciones, etc.
UML define muchos tipos de clasificadores, como son los
Subsistemas, clases e interfaces.
También son clasificadores los actores, casos de uso,
componentes y nodos (Sección 9.3.7).
EL MODELO



DE
ANÁLISIS
El modelo de análisis es una especificación detallada de los
requisitos y funciona como primera aproximación del
modelo de diseño, aunque es un modelo con entidad propia.
Los desarrolladores lo utilizan para comprender de manera
más precisa los casos de uso descritos en el flujo de trabajo
de los requisitos, refinándolos en forma de colaboraciones
entre clasificadores conceptuales (diferentes de los
clasificadores
de
diseño
que
serán
objeto
de
implementación).
El modelo de análisis también se utiliza para crear un
sistema robusto y flexible (incluyendo una arquitectura) que
emplea la reutilización de componentes de manera
considerable.
EL MODELO





DE
ANÁLISIS
El modelo de análisis es un modelo conceptual, el
modelo de diseño es un esquema de la
implementación.
El modelo de análisis puede ser transitorio y sobrevivir
sólo al primer par de iteraciones.
En algunos casos, especialmente para sistemas
grandes y complejos, el modelo de análisis debe
mantenerse durante toda la vida del sistema.
Es estos casos, existe una relación directa (mediante
dependencias de traza) entre una realización de caso
de uso en el modelo de análisis y la correspondiente
realización de caso de uso en el modelo de diseño.
Cada elemento del modelo de análisis es trazable a
partir de elementos del modelo de diseño que lo
realizan.
Regresar
NOTAS

(El modelo de análisis, su propósito y su
relación con el modelo de diseño se explican
en profundidad en las Secciones 8.1 a 8.3).
EL






MODELO DE DISEÑO
El modelo de diseño es jerárquico, pero también
contiene relaciones que atraviesan la jerarquía.
Las relaciones son las habituales en UML:
asociaciones, generalizaciones, y dependencias.
Las realizaciones de los casos de uso son estereotipos
de colaboraciones.
Una colaboración representa cómo los clasificadores
participan y desempeñan papeles en hacer algo útil,
como la realización de un caso de uso.
El modelo de diseño es también un esquema de la
implementación.
Existe una correspondencia directa entre subsistemas
del modelo de diseño y componentes del modelo de
implementación.
EL




MODELO DE DISEÑO
Los desarrolladores crean un modelo de análisis que
utiliza el modelo de casos de uso como entrada.
Cada caso de uso en el modelo de casos de uso se
traducirá en una realización de caso de uso en el
modelo de análisis.
La dualidad caso de uso/realización de caso de uso es
la base de una trazabilidad directa entre los requisitos
y el análisis.
Tomando los casos de uso uno a uno, los
desarrolladores pueden identificar las clases que
participan en la realización de los casos de uso.
Regresar
EJEMPLO,
DINERO





EL CASO DE USO
SACAR
Por ejemplo, el caso de uso Sacar Dinero puede
realizarse por parte de las clases de análisis Retirada
de Efectivo.
Cuenta, Cajero, y otras que no necesitamos identificar
para esta explicación.
Los desarrolladores asignan responsabilidades
definidas en el caso de uso a responsabilidades de las
clases.
En nuestro ejemplo, la clase Cuenta podría tener
responsabilidades como “restar cantidad de la
cuenta”.
De esta forma, podemos garantizar que obtenemos un
conjunto de clases que juntas realizan los casos de
uso y son verdaderamente necesarias para los
usuarios.
EJEMPLO,
DINERO


EL CASO DE USO
SACAR
Después, los desarrolladores diseñan las clases y las
realizaciones de casos de uso para obtener mejor
partido de los productos y tecnologías (object request
brokers, kits de construcción de IGU, y sistemas de
gestión de base de datos) que se utilizarán para
implementar el sistema. Las clases de diseño se
agrupan en subsistemas, y pueden definirse interfaces
entre ellos.
Los desarrolladores también preparan el modelo de
despliegue, donde definen la organización física del
sistema en términos de nodos de cómputo, y verifican
que los casos de uso pueden implementarse como
componentes que se ejecutan en esos nodos.
EJEMPLO,
DINERO


EL CASO DE USO
SACAR
A continuación, los desarrolladores implementan las
clases diseñadas mediante un conjunto de ficheros
(código fuente) en el modelo de implementación, a
partir de los cuales se pueden producir (compilar y
enlazar) ejecutables, como DLL’s, JavaBeans, y
componentes ActiveX.
Los casos de uso ayudan a los desarrolladores a
determinar el orden de implementación e integración
de los componentes.
EJEMPLO,
DINERO




EL CASO DE USO
SACAR
Por último, durante el flujo de trabajo de prueba los
ingenieros de prueba verifican que el sistema
implementa de verdad la funcionalidad descrita en los
casos de uso y que satisface los requisitos del
sistema.
El modelo de prueba se compone de casos de prueba
(y otros elementos que explicaremos más adelante en
el Capítulo 11).
Un caso de prueba define una colección de entradas,
condiciones de ejecución, y resultados.
Muchos de los casos de prueba se pueden obtener
directamente de los casos de uso y por tanto tenemos
una dependencia de traza entre el caso de prueba y el
caso de uso correspondiente.
EJEMPLO,
DINERO




EL CASO DE USO
SACAR
Esto significa que los ingenieros de prueba verificarán
que el sistema puede hacer lo que los usuarios
quieren que haga, es decir, que ejecuta los casos de
uso.
Cualquiera que haya probado software en el pasado
en realidad ha probado casos de uso — incluso si su
trabajo no los describía en esos términos en su
momento.
Lo novedoso y diferente del Proceso Unificado es que
la prueba puede planificarse al principio del ciclo de
desarrollo.
Tan pronto como se hayan capturado los casos de uso,
es posible especificar los casos de prueba (pruebas de
caja negra”) y determinar el orden en el cual
realizarlos, integrarlos y probarlos.
EJEMPLO,
DINERO




EL CASO DE USO
SACAR
Más adelante, según se vayan realizando los casos de
uso en el diseño, pueden detallarse las pruebas de los
casos de uso (pruebas de “caja blanca”).
Cada forma de ejecutar un caso de uso — es decir,
cada camino a través de una realización de un caso de
uso — es un caso de prueba candidato.
Hasta aquí, hemos presentado el Proceso Unificado
como una secuencia de pasos, muy parecida al
antiguo método en cascada. Pero lo hemos hecho así
sólo para mantener la simplicidad hasta este
momento.
En el Capítulo 5 veremos cómo estos pasos pueden
desarrollarse de una forma mucho más interesante
mediante una aproximación iterativa e incremental.
EJEMPLO,
DINERO



EL CASO DE USO
SACAR
Realmente, lo que hemos descrito hasta aquí es una
sola iteración.
Un proyecto de desarrollo completo será una serie de
iteraciones, en la cual cada una de ellas (con la
posible excepción de la primera) consiste en una
pasada a través de los flujos de trabajo de requisitos,
análisis, diseño, implementación y prueba.
Vamos a examinar con más detalle los beneficios de
los casos de uso antes de estudiar los flujos de trabajo
más en profundidad.
Regresar