ANÁLISIS, DISEÑO E
IMPLEMENTACIÓN PARA REALIZAR
LOS CASOS DE USO
ÍNDICE
Introducción
 Creación del modelo de análisis a partir de
los casos de uso

INTRODUCCIÓN



Durante el análisis y el diseño, transformamos el
modelo de casos de uso mediante un modelo de
análisis en un modelo de diseño, es decir, en una
estructura de clasificadores y realizaciones de casos
de uso.
El objetivo es realizar los casos de uso de una forma
económica de manera que el sistema ofrezca un
rendimiento adecuado y pueda evolucionar en el
futuro.
En esta sección, veremos cómo pasar por un modelo
de análisis para desarrollar un diseño que realice los
casos de uso.
Regresar
NOTAS

En los Capítulos 4 y 5, examinaremos cómo
la arquitectura y el desarrollo iterativo e
incremental nos ayudan a desarrollar un
sistema económico que pueda incorporar
nuevos requisitos.
CREACIÓN
DEL MODELO DE ANÁLISIS
A PARTIR DE LOS CASOS DE USO





El modelo de análisis crece incrementalmente a
medida que se analizan más y más casos de uso.
En cada iteración, elegimos un conjunto de casos de
uso y los reflejamos en el modelo de análisis.
Construimos el sistema como una estructura de
clasificadores (clases de análisis) y relaciones entre
ellas.
También describimos las colaboraciones que llevan a
cabo los casos de uso, es decir, las realizaciones de los
casos de uso.
Después, en la siguiente iteración, tomamos otro
conjunto de casos de uso para desarrollar, y los
añadimos a la iteración anterior.
NOTAS

En las Secciones 5.3 y 12.6, discutiremos
cómo identificar y seleccionar los conjuntos
más "importantes" de casos de uso para las
primeras iteraciones con el objetivo de
construir pronto una arquitectura estable
dentro del ciclo de vida del sistema.
CREACIÓN
DEL MODELO DE ANÁLISIS
A PARTIR DE LOS CASOS DE USO
•
•
•
•
Una forma práctica de trabajar es identificar y
describir en primer lugar los casos de uso para una
iteración, después leer la descripción de cada caso de
uso (Sección 3.3.3), y proponer los clasificadores y
asociaciones necesarios para llevar a cabo el caso de
uso.
Lo hacemos para todos los casos de uso de una
iteración a modo de esfuerzo coordinado.
Dependiendo de dónde nos encontremos en el ciclo de
vida y del tipo de iteración que estemos tratando,
puede que haya ya una arquitectura establecida para
guiarnos en la identificación de nuevos clasificadores y
en la reutilización de los existentes (Sección 4.3).
Cada clasificador desempeña uno o varios roles en
una realización de caso de uso.
CREACIÓN
DEL MODELO DE ANÁLISIS
A PARTIR DE LOS CASOS DE USO




Cada papel de un clasificador especifica las
responsabilidades, atributos y demás que el
clasificador debe tener para participar en la realización
del caso de uso.
Podemos pensar en esos roles como en "embriones"
de clasificadores.
De hecho, un rol en UML es un clasificador en sí
mismo. Por ejemplo, podemos pensar que un rol de
una clase es una vista de la clase.
Por tanto, incluye lo que incluya la clase, es decir, sus
responsabilidades, atributos y demás —pero sólo
aquellos que sean de interés para el rol en una
realización de caso de uso.
NOTAS

Este concepto de rol se describe brevemente
en este capítulo, aunque por simplicidad no
se desarrolla completamente hasta la Parte
II de este libro donde se explican todos los
clasificadores en detalle.
CREACIÓN
DEL MODELO DE ANÁLISIS
A PARTIR DE LOS CASOS DE USO

Otra forma de describir un rol de una clase es verlo
como lo que queda de la clase cuando se le pone un
filtro, un filtro que bloquea el resto de los roles de la
clase que no tienen responsabilidades comunes.
EJEMPLO. LA REALIZACIÓN DE UN CASO DE USO
EN EL MODELO DE ANÁLISIS




En la Figura 3.4 describimos cómo se lleva a cabo el
caso de uso Sacar Dinero mediante una colaboración
(es decir, una realización de caso de uso) con una
dependencia de “traza” (una traza es un estereotipo
de dependencia que se indica mediante las comillas «
y ») entre ellos, y cómo cuatro clases participan y
desempeñan roles en la realización del caso de uso.
Como puede verse en la figura, la notación para una
realización de caso de uso o colaboración es una
elipse con una línea de trazo continuo.
Comenzamos normalmente examinando unos pocos
casos de uso, creando sus realizaciones, e
identificando los roles de los clasificadores.
EJEMPLO. LA
REALIZACIÓN DE UN CASO
DE USO EN EL MODELO DE ANÁLISIS




Después hacemos lo mismo para más casos de uso y
proponemos nuevos roles de clasificador.
Algunos de estos últimos pueden especificarse como
roles nuevos o modificados de clasificadores ya
identificados, mientras que otros roles necesitarán
nuevos clasificadores.
Después observamos de nuevo los primeros casos de
uso, alternando de esta forma entre los casos de uso
y construyendo gradualmente un modelo de análisis
estable.
Al final, cada clasificador puede participar y
desempeñar papeles en varías realizaciones de caso
de uso.
EJEMPLO. LA
REALIZACIÓN DE UN CASO
DE USO EN EL MODELO DE ANÁLISIS
CREACIÓN
DEL MODELO DE ANÁLISIS
A PARTIR DE LOS CASOS DE USO



Estereotipos de análisis
En el modelo de análisis, se utilizan tres estereotipos
diferentes sobre las clases: “boundary class”, “control
class”,y “entity class” (traducidos al castellano, clase de
interfaz,
clase
de
control
y
clase
de
entidad,
respectivamente).
Salida e Interfaz del Cajero son clases de interfaz que se
utilizan generalmente para modelar la interacción entre el
sistema y sus actores (es decir, los usuarios y los sistemas
externos).
Retirada de Efectivo es una clase de control que se utiliza
generalmente
para
representar
coordinación,
secuenciamiento, transacciones y control de otros objetos —
y se utiliza con frecuencia para encapsular el control relativo
a un caso de uso (en el ejemplo, el caso de uso Sacar
Dinero).
CREACIÓN
DEL MODELO DE ANÁLISIS
A PARTIR DE LOS CASOS DE USO




Cuenta es una clase de entidad, que en general se
utilizan para modelar información que tiene una vida
larga y que a veces es persistente.
Por tanto, cada uno de estos estereotipos de clase
encapsula un tipo diferente de comportamiento (o
funcionalidad, si se quiere).
En consecuencia, los estereotipos nos ayudan a
construir un sistema robusto, (Capítulo 8).
También nos ayudan a encontrar activos reutilizables,
ya que las clases de entidad son normalmente
genéricas para muchos casos de uso, y por tanto para
muchas aplicaciones diferentes.
EJEMPLO: UNA CLASE QUE PARTICIPA EN VARIAS
REALIZACIONES DE CASO DE USO EN EL MODELO DE
ANÁLISIS




En la parte izquierda de la Figura 3.5 tenemos un
conjunto de casos de uso para un sistema de Cajero
Automático (Figura 3.3), y a la derecha tenemos la
correspondiente estructura del sistema, en este caso,
las clases de análisis que realizan los casos de uso.
La estructura del sistema se modela en un diagrama
de clases.
Los diagramas de clases se utilizan generalmente para
mostrar clases y sus relaciones, pero también pueden
utilizarse para mostrar subsistemas e interfaces
(Sección 3.4.3).
Por sencillez, hemos utilizado diferentes sombreados
para indicar en qué realizaciones de caso de uso
participa y desempeña algún rol cada clase.
EJEMPLO: UNA CLASE QUE PARTICIPA EN VARIAS
REALIZACIONES DE CASO DE USO EN EL MODELO DE
ANÁLISIS
CREACIÓN
DEL MODELO DE ANÁLISIS
A PARTIR DE LOS CASOS DE USO





El diagrama de clases para el sistema Cajero
Automático (Figura 3.5) se obtuvo a partir del estudio
de las descripciones de los tres casos de uso y de la
posterior búsqueda de formas de llevar a cabo cada
uno de ellos.
Podríamos haber hecho algo como lo siguiente:
La realización de los tres casos de uso, Sacar Dinero,
Transferencia entre Cuentas, e Ingresar Dinero implica
a la clase Interfaz del Cajero y a la clase de entidad
Cuenta.
La ejecución de cada caso de uso comienza con un
objeto de la clase Interfaz del Cajero.
Después, el trabajo continúa en un objeto de control
que coordina la mayor parte del caso de uso en
cuestión.
CREACIÓN
DEL MODELO DE ANÁLISIS
A PARTIR DE LOS CASOS DE USO





La clase de este objeto es específica de cada caso de
uso.
La clase Retirada de Efectivo participa por tanto en el
caso de uso Sacar Dinero, etc.
El objeto Retirada de Efectivo pide a la clase Salida
que entregue el dinero, y éste pide al objeto Cuenta
que disminuya el saldo.
El objeto Transferencia pide a los dos objetos Cuenta
implicados en la realización del caso de uso
Transferencia entre Cuentas que actualicen sus saldos.
El objeto Ingreso acepta dinero a través del Receptor
de Dinero y pide al objeto Cuenta que incremente el
saldo.
CREACIÓN
DEL MODELO DE ANÁLISIS
A PARTIR DE LOS CASOS DE USO




Hasta aquí hemos trabajado para obtener una
estructura del sistema estable para la iteración en
curso.
Hemos identificado las responsabilidades de los
clasificadores participantes, y hemos encontrado
relaciones entre los clasificadores.
Sin embargo, no hemos identificado en detalle la
interacción que debe tener lugar en el desarrollo de
los casos de uso.
Hemos encontrado la estructura, pero ahora es
necesario sobreponer sobre esa estructura los
diferentes patrones de interacción necesarios para la
realización de cada caso de uso.
CREACIÓN
DEL MODELO DE ANÁLISIS
A PARTIR DE LOS CASOS DE USO




Como dijimos anteriormente, cada caso de uso se
desarrolla como una realización de caso de uso, y
cada realización de caso de uso tiene un conjunto de
clasificadores
participantes,
que
desempeñan
diferentes roles.
Comprender los patrones de interacción significa que
describimos cómo se lleva a cabo o se ejecuta (o se
instancia) una realización de caso de uso.
Por ejemplo, qué ocurre cuando un Cliente de Banco
concreto saca dinero, es decir, cuando él o ella
ejecutan un caso de uso Sacar Dinero.
Sabemos que las clases Interfaz del Cajero, Retirada
de Efectivo, Salida y Cuenta participarán en la
realización del caso de uso.
CREACIÓN
DEL MODELO DE ANÁLISIS
A PARTIR DE LOS CASOS DE USO





También sabemos las responsabilidades que deberían
cumplir.
Sin embargo, aún no sabemos cómo ellas — o más
correctamente, cómo objetos de esas clases —
interactuarán para llevar a cabo la realización del caso
de uso.
Esto es lo siguiente que debemos averiguar.
Utilizamos
fundamentalmente
diagramas
de
colaboración para modelar las interacciones entre
objetos en el análisis.
(UML también proporciona diagramas de secuencia
para modelar interacciones, volveremos a hablar de
ellos cuando tratemos el diseño en la Sección 3.4.3.)
CREACIÓN
DEL MODELO DE ANÁLISIS
A PARTIR DE LOS CASOS DE USO


Un diagrama de colaboración recuerda a un diagrama
de clases, pero contiene instancias y enlaces en lugar
de clases y asociaciones.
Muestra cómo interactúan los objetos secuencialmente
o en paralelo, numerando los mensajes que se envían
unos a otros.
EJEMPLO: USO DE DIAGRAMAS DE COLABORACIÓN
PARA DESCRIBIR UNA REALIZACIÓN DE CASO DE USO
EN EL MODELO DE ANÁLISIS



En la Figura 3.6 utilizamos un diagrama de
colaboración para describir cómo una sociedad de
objetos de análisis lleva a cabo la realización del caso
de uso Sacar Dinero.
El diagrama muestra cómo el control pasa de un
objeto a otro a medida que se lleva a cabo el caso de
uso, y los mensajes que se envían entre los objetos.
Un mensaje de un objeto dispara al objeto receptor
para que tome el control y lleve a cabo una de las
responsabilidades de su clase.
EJEMPLO: USO DE DIAGRAMAS DE COLABORACIÓN
PARA DESCRIBIR UNA REALIZACIÓN DE CASO DE USO
EN EL MODELO DE ANÁLISIS




El nombre de un mensaje indica el motivo del objeto
que realiza la llamada en su interacción con el objeto
invocado,
Más adelante, en el diseño, estos mensajes se
retinarán en una o más operaciones proporcionadas
por las clases de diseño correspondientes (Sección
3.4.3).
Como complemento a un diagrama de colaboración,
los desarrolladores pueden usar también texto para
explicar cómo interactúan los objetos para llevar a
cabo el flujo de eventos del caso de uso.
Existen muchas otras formas de describir una
realización, como el texto estructurado o el
pseudocódigo.
FIGURA 3.6 UN DIAGRAMA DE COLABORACIÓN PARA
LA REALIZACIÓN DEL CASO DE USO SACAR DINERO EN
EL MODELO DE ANÁLISIS.
EJEMPLO. DESCRIPCIÓN
DEL FLUJO DE
SUCESOS DE UNA REALIZACIÓN DE USO
Describimos ahora la realización del caso de uso
Sacar Dinero en términos de objetos y actores
que interactúan, como se muestra en la Figura
3.6.
 Un Cliente de Banco decide sacar dinero y activa el
objeto Interfaz del Cajero.
 El Cliente de Banco se identifica y especifica la
cantidad a retirar y la cuenta de la cual hacerlo (1).
 Interfaz del Cajero verifica la identidad del Cliente de
Banco y solicita al objeto Retirada de Efectivo que
lleve a cabo la transacción (2).
EJEMPLO. DESCRIPCIÓN
DEL FLUJO DE
SUCESOS DE UNA REALIZACIÓN DE USO



Si la identidad del Cliente de Banco es válida, se le
solicita al objeto Retirada de Efectivo que confirme si
el cliente del banco tiene derecho a sacar la cantidad
especificada de la Cuenta, El objeto Retirada de
Efectivo lo confirma solicitando al objeto Cuenta que
valide la petición y: si la petición es válida, que reste
la cantidad (3).
Después el objeto Retirada de Efectivo autoriza a
Salida a que entregue al Cliente de Banco la cantidad
solicitada (4).
Entonces es cuando el Cliente de Banco recibe la
cantidad de dinero solicitada (5).
EJEMPLO. DESCRIPCIÓN
DEL FLUJO DE
SUCESOS DE UNA REALIZACIÓN DE USO



Obsérvese que este sencillo ejemplo sólo muestra un
camino a través de la realización del caso de uso,
cuando todo sucede sin complicaciones.
Podrían ocurrir complicaciones, por ejemplo, si el
saldo de la Cuenta es demasiado bajo para permitir la
retirada de efectivo.
En este momento, hemos analizado cada caso de uso
y por tanto hemos identificado todos los roles de clase
que participan en cada realización de caso de uso.
Ahora pasamos a cómo analizar cada clase.
FIGURA 3.6 UN DIAGRAMA DE COLABORACIÓN PARA
LA REALIZACIÓN DEL CASO DE USO SACAR DINERO EN
EL MODELO DE ANÁLISIS.
CREACIÓN
DEL MODELO DE ANÁLISIS
A PARTIR DE LOS CASOS DE USO




Cada clase debe cumplir todos sus roles de
colaboración
Las responsabilidades de una clase son sencillamente la
recopilación de todos los roles que cumple en todas las
realizaciones de caso de uso.
Juntándolas y eliminando repeticiones entre los roles,
obtenernos
una
especificación
de
todas
las
responsabilidades y atributos de la clase.
Los desarrolladores responsables de analizar y realizar los
casos de uso son los responsables de especificar los roles de
las clases.
Un desarrollador responsable de una clase agrupa todos los
roles de la clase en un conjunto completo de
responsabilidades para la clase, y después los integra en un
conjunto consistente de responsabilidades.
CREACIÓN
DEL MODELO DE ANÁLISIS
A PARTIR DE LOS CASOS DE USO




Los desarrolladores responsables de analizar los casos
de uso deben asegurarse de que las clases realizan los
casos de uso con la calidad adecuada.
Si se cambia una clase, su desarrollador debe verificar
que la clase sigue cumpliendo sus roles en las
realizaciones de casos de uso.
Si se cambia un rol en una realización de caso de uso,
el desarrollador del caso de uso debe comunicar el
cambio al desarrollado de la clase.
Por tanto, los roles ayudan a mantener la integridad
del análisis tanto a los desarrolladores de las clases,
como a los de los casos de uso.
Regresar
Descargar

Análisis, diseño e implementación para realizar