You are on page 1of 11

(continuation

)
Los boletos seran enviados al cliente posteriormente, o estaran listos para
ser recogidos en el mostrador del aeropuerto antes de la salida del primer vuelo.
Es necesario estar previamente registrado con un numero de tarjeta de
credito valida para poder hacer compras de boletos, o de lo contrario proveerla en el momento de la compra.
Ademas de los servicios de vuelo, el usuario podra, en cualquier momento, accesar, modificar o cancelar su propio registro, todo esto despues de
haber sido validado en el sistema.

Es conveniente que el lector note lo informal y limitado de esta descripcion,
que se refinara a lo largo del capitulo. Dado que el modelo de casos de uso
es el principal de todo el sistema, comenzaremos con el.

6.2 Modelo de casos de uso
El modelo de casos de uso describe un sistema en terminos de sus distintas
formas de utilizacion, cada una de las cuales se conoce como un caso de uso.
Cada caso de uso o flujo se compone de una secuencia de eventos iniciada por
el usuario. Dado que los casos de uso describen el sistema a desarrollarse, los
cambios en los requisites significaran cambios en los casos de uso. Por ejemplo, un caso de uso para manejar un automovil seria la secuencia de eventos
desde que el conductor entra en el coche y enciende el motor hasta llegar a su
destino final. Por tanto, para comprender los casos de uso de un sistema primero es necesario saber quienes son sus usuarios; por ejemplo, conducir un
automovil es distinto de arreglarlo, pues los usuarios tambien son diferentes: el
dueno del automovil y el mecanico, respectivamente. Para ello, se define el concepto de actor, que es el tipo de usuario que esta involucrado en la utilizacion
de un sistema, y que ademas es una entidad externa al propio sistema. Juntos,
el actor y el caso de uso, representan los dos elementos basicos de este modelo, lo cual se muestra de manera grafica en la figura 6.3 de acuerdo con la
notacion UML.

Figura 6.3

El actor y el caso de uso son las entidades basicas
del modelo de casos de uso.

Los casos de uso son ideas simples y practicas que no requieren muchas habilidades tecnologicas para ser utilizadas (a diferencia de las demas actividades
del desarrollo). Por el contrario, si se volvieran muy complejas se perderia su
MODELO DE CASOS DE USO

199

se establece la funcionalidad completa de este. operadores. Incluso.2. Cada actor ejecuta un numero especifico de casos de uso en el sistema. como entidades externas a esta. se considera al actor una clase de usuario. incluso concurrente.1 Actores Los actores son entidades distintas a los usuarios. Lo esencial es que los actores representen entidades externas al sistema. Los actores modelan cualquier entidad externa que necesite intercambiar informacion con el sistema.4. CAP. esto es para que estos sean la herramienta principal que permita encontrar los casos de uso. Para especificar los actores de un sistema. la cual representa al sistema como una "caja negra". como mencionamos anteriormente.4 200 Delimitacion de un sistema segun los actores. Una vez definidos todos los actores y casos de uso en el sistema. En la terminologia orientada a objetos. Cada uno de estos tipos de usuario corresponde a un actor diferente y. 6 — MODELO DE REQUISITOS . mientras que los usuarios se consideran como objetos o instancias de esa clase. Dado que el modelo de requisites es la primera actividad del desarrollo del sistema. cada uno de estos actores podra ejecutar una o mas tareas del sistema.utilidad. como se muestra en la figura 6. por lo que pueden representar otros sistemas externos al actual. Por ejemplo. un sistema de computacion puede tener diferentes tipos de usuarios: programadores. Encontrar actores implica trabajo y raramente se encuentran todos los actores de una vez. Figura 6. y a los diferentes actores. habra ciertas imprecisiones que se iran resolviendo de manera gradual. se identifican los actores del sistema. se dibuja un diagrama correspondiente a la delimitacion del sistema. De esta manera. Antes de identificar los casos de uso. Ademas. 6. mientras que los actores representan cierta funcion que una persona real realiza. Cuando se identifican y describen los casos de uso. en el sentido de que estos son las personas reales que utilizaran el sistema. una misma persona puede aparecer como diversas instancias de diferentes actores. se pueden desarrollar de forma independiente los distintos casos de uso para despues integrarlos y formar el modelo de requisites completo. administradores o usuarios generales. Esta habilidad de tomar parte de la funcionalidad permite un desarrollo mas flexible. una misma persona puede desempenar la funcion de programador u operador. permite hacer muchos cambios en su especificacion sin afectar al resto del sistema. No estan restringidos a ser personas fisicas.

podemos identificar un actor adicional. Retomando la description del Sistema de Reservaciones de Vuelos. el cual mantiene la informacion sobre los vuelos y reservaciones. existe siempre la duda. y ademas puede trabajar para el sistema de reservaciones. se puede identificar que las bases de datos de los sistemas externos de reservaciones tienen una funcion muy activa con respecto al sistema en desarrollo. La decision depende de la funcion que desempenen con respecto al sistema en desarrollo. no se describen los actores con demasiado detalle por ser externos al sistema. que tipicamente pertenecen a personas fisicas. En particular. Si se analiza un poco mas. lo cual no es aceptable. MODELO DE CASOS DE USOS 201 . por ejemplo. Al contrario de estos. en otras palabras. es necesario identificar primero a los actores del sistema. Mas aun. para reconocer los casos de uso. Por otro lado. ademas de que sus acciones no son deterministas. se puede identificar al menos un actor. Ademas de los actores primarios.En general. de lo contrario. si desempefian una funcion activa entonces deben modelarse como actores.5 Delimitacion del sistema de reservaciones de vuelo. los actores secundarios corresponden. Figura 6. Volviendo a la distincion entre actor y persona. el sistema hara lo que crea conveniente. quien esta encargado de hacer las consultas y reservaciones en el sistema. por lo general a maquinas o sistemas externos (estos ultimos son mas difidles de identificar). representando una segunda base de datos. que se involucre en la informacion de los usuarios mas que de las reservaciones. comenzando por aquellos que son la razon principal del sistema. encargado de mantener la informacion de los usuarios sobre la utilization del sistema. que corresponderia a otro actor no mostrado en nuestro ejemplo. Estos actores tipicamente rigen la secuencia logica de ejecucion del sistema. conocidos como actores primaries.5. por ejemplo como Opemdor. existen actores supervisando y manteniendo el sistema. A este actor lo llamaremos la Base de Datos de Reservaciones. el sistema y los casos de uso correspondientes deben ser deterministas. Los actores secundarios tienden a responder a secuencias logicas del sistema y no tanto a inicializarlas de manera propia. de si el sistema operativo o una base de datos serian actores. el Usuario. a los que se les llama actores secundarios y existen primordialmente como complemento a los actores primarios. A este actor lo llamaremos la Base de Datos de Registros. una misma persona puede desempenar la funcion del actor Usuario cuando hace reservaciones. un actor —a diferencia del propio sistema— en cada momento puede decidir entre multiples opciones. Sin embargo. siendo esta distincion importante para dedicarle el esfuerzo principal a las necesidades de los actores primarios. El diagrama de delimitacion del sistema con los actores correspondientes se muestra en la figura 6.

Por otro lado. el caso de uso necesita ser especificado solo con respecto a un actor en lugar de varios. El actor primario se encarga de dar inicio a esta interaccion.6. un objeto. Una instancia de un actor puede ejecutar varias de estas secuencias. Si el mismo o parte del mismo caso de uso se puede ejecutar por varios actores diferentes. El resto de los actores se conoce como actores concretes.2. los actores abstractos tambien pueden utilizarse para especificar privilegios comunes a multiples actores en un sistema. Como varios casos de uso pue202 CAP. Figura 6. Cuando diferentes actores realizan roles similares. ya que el sistema se construye pensando en sus usuarios. Al usarse terminologia orientada a objetos. Cada caso de uso constituye un flujo completo de eventos. 6. La instancia del caso de uso existe mientras este se siga ejecutando. como se vio en el capitulo 4. se establece la funcionalidad propia del sistema por medio de los casos de uso. 6 — MODELO DE REQUISITOS . mientras que los casos de uso son instanciados como respuesta al evento anterior.2 Casos de uso Despues de haber definido a los actores del sistema. que constan de diferentes acciones que a su vez deben llevarse a cabo. con estado y comportamiento. cada caso de uso define una clase o forma particular de usar el sistema. La ventaja de modelar actores abstractos es que expresan similitudes entre casos de uso. ya que si no existieran usuarios no habria necesidad del sistema. mientras que cada ejecucion del caso de uso se puede ver como una instancia del mismo. mientras que Base de Datos de Reservaciones y Base de Datos de Registros son ambos actores secundarios.6 Delimitacion del sistema de reservaciones de vuelo con ejemplo de herencia entre actores. o sea. como lo muestra el actor abstracto Base de Datos en el ejemplo de la figura 6. pueden heredar de un actor abstracto comun. y utilizan terminologia similar a la de herencia. Las diferentes instancias de los casos de uso se conocen como escenarios.El actor Usuario se considera un actor primario. que especifican la interaccion que toma lugar entre el actor y el sistema. La ejecucion del caso de uso termina cuando el actor genera un evento que requiere un caso de uso nuevo.

hasta que este se haya completado.Desea el actor ser informado sobre cambios inesperados? For ejemplo. Para identificar los casos de uso. los casos de uso pueden comenzar de forma similar y no podemos saber cual se esta instanciando hasta que se termine. De aqui podemos definir nuestros casos de uso principales. For tanto.7 se muestra un ejemplo de casos de uso. no sabemos cual caso desea ejecutar. Mantener el Sistema. La figura 6. En la figura 6. el actor no requiere de que un caso de uso se ejecute. Figura 6. un actor podria ser un suscriptor. pero cuando esto ocurre. Consultar Information y Hacer una Reservation.8 ilustra el sistema con los dos casos de uso.7 Ejemplo de casos de uso que muestran la relacion con los actores.den comenzar de una misma forma.Debera el actor informar al sistema sobre cambios externos? <. La description de los casos de uso se basa en diagramas similares a los de transition de estados. no es siempre posible decidir que caso de uso se ha instanciado. Se puede ver a cada caso de uso como si representara un estado en el sistema. Observe que los nombres de los casos de uso deben corresponder a acciones y no tanto a sustantivos. en un sistema de conmutacion telefonica. se puede leer la description del problema y discutirlo con aquellos que actuaran como actores. El caso de uso comienza cuando el suscriptor levanta el telefono. Otro caso de uso es ordenar una llamada al servicio de despertador. solo que inicie una secuencia de eventos que finalmente resulte en la termination de algun caso de uso. Dado que el Usuario es el actor primario se comienza con el. ademas de un caso de uso adicional. como consultas y reservaciones.Tendra el actor que consultar y modificar information del sistema? «. En otras palabras. donde un estimulo enviado entre un actor y el sistema ocasiona una transition entre estados. correspondiente a un actor seMODELO DE CASOS DE USO 203 . mientras que otro usuario lo ejecuta. empleando preguntas como: <>Cuales son las tareas principales de cada actor? <. y un caso de uso tipico seria hacer una llamada local. Ambos casos de uso comienzan cuando el suscriptor levanta el telefono. En el sistema de reservaciones de vuelos utilizamos los actores ya identificados como punto de partida. donde un programador escribe y depura un programa. El sistema debe ser capaz de dar ciertos servicios al usuario.

a menudo es necesario contar con mecanismos que permitan extender los diagramas de manera mas elaborada. el usuario debe estar registrado. de manera analoga al concepto de herencia. Aunque.9 Prlncipales casos de uso para el sistema de reservaciones de vuelo. para lograr una mejor especificacion de requisitos y evitar complejidad adicional. en general. por lo cual agregamos un caso de uso Registrar usuario. Se elimino en el diagrama la delimitacion del sistema. se debe incluir la Base de Datos de Reservaciones y la Base de Datos de Registros ya que son actores secundarios necesarios.9. y resaltar los flujos menos comunes. no siempre es obvio que subflujos deberian definirse como casos de uso separados. Existen dos enfoques distintos para expresar extensiones: 204 CAP. para utilizar el sistema. Figura 6. Por otro lado. Las razones son aprovechar distintos subflujos que se repiten en multiples casos de uso. Notese las flechas unidireccionales dirigiendose del actor primario hacia el caso de uso y del caso de uso hacia el actor secundario.cundario Operador. Figura 6. Sin embargo. El modelo de casos de uso permite la subdivision de partes del flujo completo de un caso de uso en casos de uso separados.8 Ejemplo de casos de uso para un sistema de reservaciones de vuelo. 6 — MODELO DE REQUISITOS . En la descripcion del problema se menciona que. Aunque la idea del modelo de casos de uso es que los diagramas sean lo mas sencillo posible. no se vera ninguna funcionalidad de mantenimiento en nuestro desarrollo: un ejemplo adicional de como concentrarse en ciertos aspectos de los requisites durante diversas etapas. la complejidad de los casos de uso es un factor importante para tal decision. Estos tres casos de uso se muestran en la figura 6.

la extension se utiliza para modelar secuencias de eventos opcionales de casos de uso. En general. estos se pueden describir como variantes de un mismo caso de uso. cada caso de uso debe describirse con mas detalle.Si las diferencias entre los casos de uso son pequenas. en el caso de uso Registrar Usuario. La identificacion de casos de uso es normalmente un proceso iterativo. For ejemplo. Figura 6. el cual es el flujo mas importante dentro del caso de uso y generalmente el punto de entrada al caso de uso. Si las diferencias entre los casos de uso son grandes. En general. la cual especifica como un caso de uso puede insertarse en otro para extender la funcionalidad del anterior. dando lugar al concepto de subflujos o ramificaciones de flujos dentro de un mismo caso de uso. el caso de uso inicial no requiere consideraciones adicionales al caso de uso a ser insertado. donde el caso de uso de Hacer Reservation se extiende mediante el caso de uso Pagar Reservation. Cuando esto ocurre. se utilizan principalmente las relaciones de extension. se deben describir como casos de uso separados. unicamente se especifica su punto de insercion. primero se describe el flujo principal o bdsico. De esta manera. Cuando esto ocurre.10 la notacion para extension. pero varios subflujos y cursos alternos. donde se hacen multiples revisiones hasta llegar a una solucion final estable. Posteriormente se describen los subflujos alternos que pudieran incluir flujos para el manejo de variantes en la logica. Se puede considerar a la MODELO DE CASOS DE USO 205 . EXTENSION Un concepto importante que se utiliza para estructurar y relacionar casos de uso es la extension. en cuyo caso se conocen como subflujos alternos. inclusion y generalization. Tomando como ejemplo el Sistema de Reservaciones de Vuelos. Normalmente un caso de uso tiene solo un curso basico. utilizando la etiqueta "extiende" (extend). que al manejarse de manera independiente pueden agregarse o eliminarse del sistema de manera modular.10 Casos de uso Hacer Reservation con extension de Pagar Reservation. la creacion por primera vez del registro y su actualizacion se pueden considerar dos secuencias de eventos logicamente similares. El caso de uso donde se insertara la nueva funcionalidad debe ser un flujo completo. por lo cual este es independiente del caso de uso a insertarse. como se describe a continuacion. se muestra en la figura 6. por lo cual se tratan como distintos subflujos en un mismo caso de uso.

6 — MODELO DE REQUISITOS . en lugar de repetirlas para todos lis casos de uso con comportamiento comun. For ejemplo. totalmente independientes de cualquier extension de funcionalidad. GENERALIZACION Una relation adicional entre casos de uso es la generalizacion. en el Sistema de Reservaciones de Vuelos. Los casos de uso que realmente seran instanciados se llaman ^asos de uso concretos. Despues que la extension se ha terminado. el curso original continua como si nada hubiera ocurrido. For ejemplo. se especifica la posicion en el caso de uso original. en el Sistema de Reservaciones de Vuelos. Esta generalizacion es una "herencia de secuencias" (en lugar de operaciones. Figura 6. El caso de uso donde se insertara la funcionalidad depende del caso de uso a ser insertado. y luego los de extension.11 Casos de uso Consultar Information con inclusion de Validar Usuario. INCLUSION Una relacion adicional entre casos de uso es la inclusion. En este punto. Mediante la relacion de generalizacion es necesario describir las partes similares una sola vez. se describe primero los casos de uso basicos. For regla general. Las descripciones de los casos de uso abstractos se incluyen en las descripciones de los casos de uso concretos.11. el caso de uso Consultar Information incluye el caso de uso Validar Usuario como se muestra en la figura 6. Para cada caso de uso que vaya a insertarse en otro caso de uso. la inclusion se define como una seccion de un caso de uso que es parte obligatoria del caso de uso basico. Esta relacion se etiqueta con "incluye" (include). y serviran solo para describir partes que son comunes a otros casos de uso. Los casos de uso extraidos se conpcen como casos de uso abstractos. donde la extension se insertara. el caso de uso Pagar Reservation pudiera generalizarse en dos casos de 206 CAP. se continua con la ejecucion del nuevo curso. la cual apoya la reutilfeacion de los casos de uso.asociacion de extension como una interrupcion en el caso de uso original que ocurre donde el nuevo caso de uso se va a insertar. Una tecnica para extraer casos de uso abstractos es identificar actores abstractos. A diferencia de una extension. El caso de uso original se ejecuta de forma normal hasta el punto donde el caso de uso nuevo se inserta. en el caso de herencia de objetos). ya que no seran instanciados indepenjdientemente.

Pagar con Tarjeta y Pagar con Transferencia. Finalmente. En la mayoria de los casos. mientras que las inclusiones se encuentran de la extraccion de secuencias comunes ya existente entre varios casos de usos. se desean diagramas sencillos que no sean "telaranas".12. se ilustra el diagrama complete de casos de uso para el Sistema de Reservaciones de Vuelos.13. pero que muestren de manera esquematica las posibles secuencias de interacciones entre los actores y el sistema. ambos requisites con el fin de comprar un boleto con el sistema. Uno de estos dos "sub" cases de uso deberia instanciarse. En la figura 6. Las relaciones de extension e inclusion entre casos de uso se implementan ambas mediante asociaciones de clases. Figure 6. Por otro lado. Si el caso de uso a ser extendido es util por si mismo. ya que el "super" caso de uso. a diferencia de la generalization. porque extiende Hacer Reservation e incluye Registrar Tarjeta. seria abstracto por no conocerse la forma de pago. Ademas de la inclusion anterior. tambien se incluyen los casos de uso de Validar MODELO DE CASOS DE USO 207 . Los casos de uso adicionales en este diagrama son la extension de Registrar Tarjeta y Pagar Reservation. la seleccion es bastante obvia. la cual se implementa mediante herencia de clases. Las generalizaciones se encuentran al tratar de especializar de diferente manera un caso de uso existente. la generalizacion se emplea cuando dos o mas casos de uso comparten funcionalidad comun. Pagar Reservation. la cual es extendida por cada uno al estilo de la generalizacion entre clases. el criterio principal es ver que tanto se acoplan las funcionalidades de los casos de uso. Las extensiones se identifican en un caso de uso existente. como se muestra en la figura 6. Si los casos de uso son fuertemente acoplados y la insercion debe tomar lugar para obtener un curso complete. la relacion debe ser descrita mediante la inclusion. que el usuario desea extender con secuencias adicionales. Este ultimo caso de uso es interesante.12 Casos de uso Pagar Reservation con generalization de pagos: Pagar con Tarjeta y Pagar con Transferencia. la relacion debe ser descrita utilizando extension.uso. sin embargo. Tambien hay una diferencia en como se identifican estas relaciones.

En esta etapa no se incluyen eventos internos al propio sistema.usuario y Ofrecer Seruicios en los casos de uso basicos: Registrar Usuario. Estos documentos son sumamente criticos ya que a partir de ellos se desarrollara el sistema completo. Consultar Information y Hacer Reservation. que consiste en tres actores y siete casos de uso. 6. El formato de documentation para cada actor es el siguiente: Actor Nombre del actor.13 En el diagrama se muestran los casos de uso completos para el sistema de reservaciones de vuelo. Las descripciones de los casos de uso representan todas las posibles interacciones de los actores con el sistema en los eventos enviados o recibidos por estos. El formato de documentation para cada caso de uso es el siguiente: 208 CAP. 6 — MODELO DE REQUISITOS .3 Documentation Parte fundamental del modelo de casos de uso es la descripcion textual detallada de cada uno de los actores y casos de uso identificados. Figura 6. Tipo Descripcion Breve descripcion del actor. Casos de uso Nombre de los casos de uso en los cuales participa. y unicamente agregaria una complejidad innecesaria.2. ya que esto se estudiara durante el analisis. Primario o secundario.

Tambien se puede generar una simulation mas sofisticada usando un sistema manejador de interfaces de usuario (UIMS. Los actores y casos de uso del sistema de reservaciones de vuelo son descritos en la seccion 6. y que las interfaces refleMODELO DE INTERFACES 209 . Cuando se disenan las interfaces de usuario. donde dependlendo de las acciones de los actores. las cuales seran mostradas en un diseno preliminar en la siguiente seccion. Proposito Razon de ser del caso de uso. extension. etcetera. se continuara con alguno de los subflujos.4. Actores primarios y secundarios que interaccionan con el caso de uso. User Interface Management System).3 Modelo de interfaces El modelo de interfaces describe la presentation de informacion entre los actores y el sistema. es esencial tener a los usuarios involucrados. Obviamente. cuanto mas tarde ocurran estos cambios. Estas sirven para apoyar de mejor manera la descripcion de los casos de uso. el cual se podra modificar o refinar despues. numerados como (E-1). Subflujos Los flujos secundarios del caso de uso. mas costoso sera implementarlos. donde los usuarios juegan un papel primordial. Un comentario importante sobre la especificacion de estos documentos.Caso de uso Actores Nombre del caso de uso. un prototipo funcional de requisites que muestra las interfaces de usuario es una estrategia importante. Tal enfoque elimina muchas posibilidades de malos entendidos. es importante relacionarse con las interfaces a ser disenadas en el sistema. Normalmente. 6. inclusion. Note que en las siguientes descripciones. ya se hace referencia a pantallas de interaccion con el usuario. Dado que el modelo de casos de uso esta motivado y enfocado principalmente hacia los sistemas de informacion. Resumen Precondiciones Resumen del caso de uso. Si se trata de la interface humano-computadora (HCI. numerados como (S-1). (E~2). Se especifica en detalle como se veran las interfaces de usuario al ejecutar cada uno de los casos de uso. Flujo principal El flujo de eventos m6s importante del caso de uso. ademas de servir de base en prototipos iniciales. Human Computer Interface). Condiciones que deben satisfacerse para ejecutar el caso de uso. se pueden usar esquemas de como veria el usuario las pantallas cuando se ejecuta cada caso de uso. Excepciones Excepciones que pueden ocurrir durante el caso de uso. etcetera. Esto ayuda al usuario a visualizar los casos de uso segun se mostraran en el sistema a construirse. Tipo Tlpo de flujo: basico. (S-2). es que se sigue un proceso iterative para definir cada uno de ellos. generalization o algun otro.