CAPITULO Modelo de requisitos El modelo de requisitos tiene como objetive delimitar el sistema y capturar la funcionalidad que ofreceri desde la perspectiva del usuario. Este madelo: puede trabajar come un contrato entre cl desarrallador y el cliente, © usuaria del sis- tema, por lo que deberi proyectar lo que el cliente desea segin la percepcién del desarrollador, Por ello, es esencial que los clientes fo comprendan, EI modelo de requisitos 8 el primero en dexirollarse, y ex lt base para for: mar todos los demiis modelos en el desarrollo de sofiware. En general, cual: quier cambio en la funcionalidac del sistema es mis facil de hacer, y con me- ores consecuencias a este nivel que posterlormente. El modelo de requisitos que se desarrollara se basa en la metodologia Objectory (facobson et al. 1992), que tiene su fundamento en el modelo de casos dle uso. Actuilmente esta me- todologia ex parte del Proceso wniificado racional (RUP) (Rational Unified Pro- cess]! El modelo de casos de uso y el propio modelo de requisitos. son la base Para los demuis modelos, A continuacidn se repasarin los canceptas detalkados en el capitulo 3, que nos servirin en esta seceiéin: D> Requisitos: El modelo de casos de uso: sirve para expresar el modelo de requisites, el cual se desarrolla en cooperackin con otros madelos como se veri mis adelante. D> Anilisis: La funcionalidad especificala por ef modelo de casos de uso se estructura en ef modelo de anilisis, que es estable con respecto a cambios, lo que Io hace un modelo Iigico independiente del ambiente de implemen- tacitin, D> Disefio: 1a funcionalidad de los casos de uso, ya estricturida por el and lisis, la realiza el modelo de diseho, adaptindose af ambiente de implemen- taciéin real y refindindase atin mis. > implememtacién: Los casos de uso se instrumentan mediante el eddie fuente en el modelo de implementacidn. Be Pruebas: Los casos de uso se compnieban a través de las pruebas de come ponenies y de integracién Documentacién: El modelo de casos de uso se debe registrar a lo largo de las diversas actividades, dando lugar a distintos documents come las manuales de usuario, de administracion, etoétera. Fl diagrama de la figura 6.1 ilustra los distinios modelos, los detalles y la nota cién que se describirin mis adelante,196 (S) [e8] al [=] Ee] f= I G-o| |G+ Staa Modelo de Modelo de = Madolo d2 = Madelo de = Madalo da Maal da requisiios anita ieeFio —implementaciéa pruebas documentacidn Figura 6.1. Dependencia de los distintos modeios del proceso de software del modsio de casos de uso. El propésito del modelo de requisitos es comprender en su totalidad el proble- ia sus implicaciones, Los demiis modelos, anilisis, disefo, implememacicn, y pruchas depencen directa © indirectamente del maclelo de requisites. Asimis- mo, este modelo sirve de hase para el desarrollo de las instrucciones operacio- ales y los manuales, ya que todo lo que el sistema deba hacer se describe aqui desie la perspectiva del usuario. El mexielo de requisitos na es un praceso me- cinico, | analista debe interactuar constantemente con el cliente para comple- tar la informacién faltante, y asi resolver ambigitedades € inconsistencias. Tam- bin debe separar los requisitos verdaderos de las decisiones relacionadas con el diseno ¢ implementacién, Se deben indicar cuiles aspectos son abligatorios y cuiles opeionales para evitar que se limite la flexibilidad de la implementa Durante el diseno, se debe extender el modelo de requisites con las es pecificaciones de rendimiento y los protocolos de interacciin para los sistemas temos, al igual que las provisiones sobre modularidad y fururas extensiones, Incluso, en ciertas acasiones se pueden incluir aspectos de diseio, como él usa de lenguajes de programacién particulares, En La metodologia de Objectory, el modelo de requisitos consta de wes mode- Jos principales, visualmente representado por un diagrama de tes dimensiones como se muestra en Ia figuea 6.2 Comporansanto feasos de uso} 4 de Informacién Lo (Gominio: det problema) Prosentacién (irtartacesibore) Figura 6.2 Los tres efes de madelado del modelo de requisitos. El modelo de comportamiento, basado dinectamemte del modelo de casos de uso, especifica la funcionalidad que ofreve el sistema desde el punto de vista del usuario, Este modelo utiliza dos conceptas claves: actores para te- CAP. 6 — MOBELG. DF REQUISITOSpresentar los distintos papeles que los usuarios desemperian con el sistema y casas de uso para significar qué pueden hacer los actores con respecto al sistema modelo de presentacién o modelo de interfisces fo borde) especifica como imeracnia el sistema con actores externos al eecutar los casos de uso, En Particular, en los sistemas de informacion que thenen mucho contacte con el usuario, especifica cémo se verin visualmente las interfaces grificas, y ‘qué funcionalidad ofrecer} cada una. > El modelo de tyormaciin 0 modelo del dominio del problema especifica Jos aspectos estructurales de la aplicacién en términos de objetos, Este mo- clo permite identificar cipidamente cuales objetos podrin ser guardados en una base de datas, si ése fuera el caso. Ademds, es utilizade para guar- dar informacién temporal en La aplicaciin, y eventualmente serviri como parimetro de Hlamadas entre funciones en el sistema. Es importante resaltar que esta separacicin en tres ejes de modelado indepen- dientes sirve para una mayor estabilidad en el desarrollo del sistema, lo que permite minimizar los efectos de ada uno sobre los otros. dos Para ilustrar el modelo de requisites y el desarrollo de las modelos posteriares, se utilizari el ejemplo del “Sistema de reservaciones de vuelo” como se men- cioné antes. Para ello, mostraremos inicialmente una descripcién de! problema. ‘A partir de esta descripcién inicial se describirin los tres modelos brisicos del modelo de requisitas 6.1 Descripcién del problema La descripeién del problema es un resumen preliminar de necesidades que sive camo punto de partida para comprender los requisitos del sistema. Aqui se trata de simular una descripeién preparada por un eliente, la cual debe ever lucionar por medio del modelo de requisitos, con objeto de lograr la especifi- cacién final del sistema a desarrollarse, La descripcién del problema debe ser una especificacion de necesidades y no una propuesta de solucién. La desceip- ci6n inicial puede ser incompleta € informal, pues al realizarse sin un andlisis completo, no hay ninguna razén para esperar que sea correcta, Como ejemplo se desarrollaed un Sistema de reservaciones de rueios, el cual per- mitiri al usuario hacer consullas y reservaciones de vuclos; ademiis de comprar los boletos aéreos de forma remoua, sin la necesidad de recurrir a un agente de viaies. En kx actualidad, existen miltiples sistemas de reservaciones de vuelos que utilizin las agencias de viajes para dar servicio a fos clientes, entre és- tos los cuatro mis importantes son: Sabre®, Galileo’, Workdspan* y Amacteus* Estos sistemas son conceidos como sistemas de distribuciGn global. También existen sistemas de reservaciones de vuelo por Intemet, como Travelocity” y Expedia’, entre otras, los cuales se basan en su mayoria, de manera directa © indirecta, en los sistemas de distribucidn global anteriores. La descripcién de! problema para nuestro sistema de reservaciones de wuelos es la siguiente: DESCRIPCION DEL PROBLEMA 197198 _——— El sistemta de reservaciones de vuelos, permite al usuario hacer consultas y reservaciones de vuelos. ademas de poder comprar los boletos aéreas de forma remota, sin la necesidad de recurrir a un agente de viajes. Se de~ sea que el sistema de reservaciones sea accesible a uavés de Internet ‘World Wide Web), E] sistema presenta en su pantalla principal un mensaje de bienvenida des- ceribiendo los servicios ofrecides junto con ta opcidn para regisirarse por primera vez, 0 si ya se esta registrado, poder utilizar el sistema de reset- vaciones de vuelos, Este acceso sc da por medio de la inserciGn de un Jogin previamente especificado y un password ya escogido y que debe validarse. Una vez registrado el usuario, y después de haberse validado el regis. 110 y contrasefta del usuario, se pueden seleccionar las siguientes activi- dades; Consulta de enelos Reservacién de vuelos Pago de boletos La consulta de vuelos se puede hacer de tres maneras diferentes: Horarias de vielos Tarifas de vwetos Estado det vuclo La consulia segiin horarios muesira los horarios de las diferentes aeroli- eas que dan servicio entre dos ciudades, La consulta segiin tarifas muestra los diferentes vuelos entre das ciudades que dan prioridad a su cost, La informacién de vuelo se utiliza principalmente para consultar el esta. do de algtin wuelo, incluyendo informacién de disponibilidad de asientos y, en el caso de un vuelo para el mismo dia, si esti a tiempo. Se pueden incluir preferencias en las Ixisquedas, coma fecha y horario deseado, categoria de asiento, acrolinea y si se desea, s6lo vuelos di- rectos La reservacién de vuelo permite al cliente hacer una reservacién para un vuelo particular, especificando la fecha y horario, bajo una tarifa estable- ida, Es posible reservar un itinerario compuesto de muiltiples vuelos, para uno © mas pasajeros, ademas de poder reservar asientos El pago permite al cliente, dada una reservacion de vuelo previa y una (arjeta de crédito valida, adquirir los boletos. aéreos, Kcontimiay CAP, 6 — MODELO, DE, REQUISLTOS(comtinuactin) Los boletos senin enviados al cliente posteriommente, o estarin listos para ser recogides en el mostrador del acropuerto antes de la saliekt del pri mer vuelo Fs necesario estar previamente registrado con un miimero de tarjeta de erédito valida para poder hacer compras de boketas, o-de lo contraria peo veerla en el momento de la compra Ademtis de los servicios de vuelo, el usuario podri, en cualquier momen to, accesar, madificar 0 cancelar su propio repistto, todo esto despues de haber sido validado en el sistema. Es conveniente que el lector note lo informal y limitade de esta descripcién, que se refinard a lo largo del capitulo. Dado que el modelo de casos de user 5 el principal de todo el sistema, comenzaremes con é 6.2 Modelo de casos de uso El modelo de casos de uso describe un sistema en términos de sus distintas formas de utilizacién, cada una de las cuales se conace come tin caso de usa, ‘Cada caso de uso 0 flujo se compone de una secuencia de eventos inictada por el usuario. Dado que los casos de uso describen el sistema a desarrollarse, los cambios en los requisitos significarin cambios en los casas de uso, Por ejem- plo, un caso de use para manepir un automiivil sera la secuencia de eventos desde que el conductor entra en el coche ¥ enciende el motor hasta Megar a su destino final, Por tanto, para comprender los casos de uso de un sistema pri mero es necesario saber quiénes son sus. usuarios, por efemplo, eonducir un automévil es distinto de arreglarlo, pues los usuarios también son diferentes: el dueito del automdvil y el mecinico, respectivamente. Para ello, se define el con cepto de actor, que es el tipo de usuarie que esti involucrade en la utilizacion de un sistema, y que ademds es una entidad externa al propio sistema. Juntos, el actor y eb caso de uso, representan los dog elementos bisicos de este mo- delo, lo cual se muestra de manera grifica en la figura 6.3 de acuerdo con ta notacidin UML, AG Figura 6.3. El actor y el caso ds Uso son las entidades bésicas. dei modelo de casos de uso. Los casos dé uso son ideas simples ¥ peicticas que no requieren muchas habe lidades tecnoligicas para ser utilizadas (a diferencia de las del desarrollo}, Por el contrario, si se volvieran muy complejas se perderia su is. actividades MODELG DE CASOS DE BS 199utilidad, Dado que el modelo de requisitos ¢s la primers actividad del desarra- lo del sistema, permite hacer muchos cambios cn su especificacion sin afectar al resto del sistema. Cuando se identifican y describen los casos de uso, habri cietas imprecisiones que se inin resolviendo de manera gradual. De esta ma- -neta, se pueden desarrollar de forma independiente los distintes casos de uso para después integrarlos y formar el modelo de requisitos completo. Esta habi- lidad de tomar parte de la funcionalidad permite un desarrollo mas flexible, in- clus concurrente, 6.2.1 Actores Los actores son ¢entidades distintas a los usuarios, en el sentido de que éstos son las personas reales que utilizarin el sistema, mientras que los actores. re- presentan cierta funcidn que una persona real realiza, En la terminologia orten- tada a objetos, se considera al actor una clase de usttatio, mientras que los usua- rios se consideran como objefos o instancias de esa clase, Incluso, una misma perana puede aparecer como diversas instancias de diferentes actores. Los actores marlelan cualquier entidad externa que necesite intercambiar infor- macién con el sistema. No estan restringidos a ser personas fisicas, por lo que pueden representar otras sistemas externos al actual. Lo esencial es que los ac- ‘ores representen entidades externas al sistema, Ademés, cada uno de estos actores podri ejecutar una o mas tareas del sistema. Antes de identificar los casos de uso, se icentifican los actores det sistema, esto es para que éstos sean la herramienta principal que permita encontrar los casos de uso. Cada actor ejecuta un ntimero especifico de casos de uso en el siste- ma. Una vex definidos todos los actores y casos de uso en el sistema, se esta blece la funcionalidad completa de éste. Encontear actores implica trabajo y raramente se encuentran tadas las actores de una vez. Por ejemplo, un sistema de computaciin puede tener diferentes lipos de usuarios: programadores, operadores, administradores © usuarios gene- rales, Cada uno de estos tipas de usuario corespande aun actor diferente y, como mencionamos anteriormente, una misma persona puede desempenar la funcidn de programador u operador. Para especificar los actores de un sistema, se dibuja un diagrama correspondien- te a La delimitaci6n del sistema, Ia cual representa al sistemta como una “caja negra’, y a los diferentes actores. como entidades extemas a ésta, como se anuestea en la figura 64, 2. Programador Re Usuuare Figura 6.4 Delimitacion de un sistema segin los actores, CAP. 6 — MODELO DE AEQUISITOS,En general, no se describe los actores con demastaclo detalle por ser externos al sistema, ademiis de que sus acciones no son deterministas; en otras palabras, un actor —a diferencia del propio. sistema— en caca momento puede decidir enlre multiples opciones. Por otro lado, el sistema y lox casos de uso corres: pondientes deben ser deterministas, de lo contrario, el sistema hard. Io que crea conveniente, lo cual no es aceptable. Sin embargo, para recnacer los casos de uso, €8 necesirio identificar primero a las actores del sistema, comenzanda por aquellos que son I raz6q principal del sistema, conocides como actores pet marios. Estos actores tipicamente rigen la secuencia bigica de ejecucion del sistema. Ademis de los actores primarios, existen actores supervisando y man- teniendo el sistema, 4 los que se les llama actores secundarios y existen pri- mordialmente como complemento a fos actores primarios, siendo esta distincién importante para dedicarle el esfuerzo principal a las necesidades de los aciores primarios. Al contrario de éstas, que tipicamente pertenecen a personas fisicas, los actores secundarios conesponden, por lo general a miquinas a sistemas ex- temas (estos dhimos son mis dificiles de identifica). Los actores secundarios Henden a responder a secuencias Kigicas del sistema y no- tanto a inicializarlas de manera propia, En particular, existe siempre la duda, por ejemplo, de si el sistema operativa © una base de datos serian actores. La decisién depende de Ia funcion que desempenen con respecto al sistema en desarrollo, si desempe- fan una funcidn activa entonces deben modelarse como actores, Retomando la descripcién del Sistema de Reservaciones de Vuelos, se puede identificar al menos un actor, el Liswarta; quien esta encargado de hacer las con- sultas y reservaciones en el sistema, Si se analiza wn poco mis, se puede iden- tificar que las bases de datos de los sistemas externos de reservaciones tienen: una funcién muy activa con respecto al sistema en desarrollo. A este actor lo Jamaremas la Base de Datos cle Reservactones, el cual mantiene Ia informacién sobre los vuelos y reservaciones, Mas an, podemos identificar un actor adicio- nal, representando- una segunda base de datos, que se involucre en la informa- cidn de los usuarios mis que de las reservaciones. A este actor lo Hamaremos a Base de Datos de Registros, encargada de mantener la informacidn de los usuarios sobre [a utilizacién del sistema. Fl diagrama de delimitacién del siste- ma con los actores corespondientes se muestra en la figura 65. Base da Datos ‘Ge Registros Figura 6.5 Delimitacién del sistema de reservaciones de vueto. Volviendo a la distincién entre actor y persona, una misma persona puede des- empefar la funcién del actor Uswaria cuando hace reservaciones, y ademis puede trabajar para el sistema de reservaciones, por ejemplo como Operador, que comesponderfa a otro actor ne mostrado en nuestro ejemplo. MODELO DE CASOS DE Lsos 201EL actor Eswario se considera un actor primario, ya que el sistema se constru- ye pensando en sus usuarios, mientras que Base de Datos de Reservaciones Base de Datos de Registros son ambos actores secundarios, ya que si no existie- ran usuarios no habia necesidad del sistema, ‘Cuando diferentes actores realizan roles similares, pueden heredar de un actor absiracio comin, como lo muestra ef actor abstracto Base de Datos en el efem- plo de la figura 6.6, El resto de los actores se conoce como. actores concre- tos, y utilizan terminologia similar a la de herencia, como se vie en el capitu- lo 4. Q __aesa .2 oi Usuario Base de Datos i / Base de Datos Base de Datos de Registres ds Rasarvacionas Figura 6.6 Delimitacién de! sistema de reservaciones de vuelo con ejemplo de herencia entre actores, La ventaja de modelar actores abstractos es que expresan similitudes entre casos de user, Si el mismo a pane del mismo caso de usa se puede ejecutar por va- fins actores diferentes. el caso de uso necesita ser especificado S6lo con respec: to 3 un actor en lugar de varios. Por otro lado, los actores abstractos también pueden utilizarse para especificar privilegios comunes 2 miiltiples actores en un sistema, 6.2.2 Casos de uso Después de haber definido a los actores del sistema, se establece la funciona- lidad propia del sistema por medio de lox casos de uso, Al usarse terminolo- gin orientacla a objetos, cada caso de uso define una clase © forma particular de usar el sistema, mientras que cada ejecucién del caso de uso se puede ver come tuna instancia del mismo, 0 se, un abjeto, con estado y comportamien- to, Cada caso de uso constituye un flujo completo de eventos, que especifican la interaccién que toma lugar entre el actor y el sistema, El actor primario se -encarga de dar inicio a esta interaccién, mientras que las casos de uso son ins- ‘tunciados como respuesta al evento anterior. Una instancia de un actor puede cejecular varias de estas sccuencias, que constan de diferentes acciones que a su vez deben llevarse a cabo. La instancia del caso de uso existe mientras éste se siga ejecutando, La ejecucidn del caso de uso termina cuando el actor gene- a Un evento que Fequiere Un caso de USO nuevo, Las diferentes instancias dle los easos de us se conacen come escenarios. Como varias casos de use pue- CAP. 6 — MODPLO. DE REQUISITOSden comenzar de una misma forma, no es siempre posible decidir qué casa de uso se ha instanciado, hasta que éste se haya completado. La descripciin de los casos de uso se basa en diagramas similares a los de tran- sicién de estadas, Se puede ver a cadi cuso cle uso como si representara un estado en el sistema, donde un cstimulo enviado entce un actor y el sistema ‘ocasiona una transicién entre estados, nla figura 67 se muestra tun ejemplo de casos de uso, donde un programa- dor eseribe y depura un programa, mientras que otra usuario lo eecuta ‘Depurar Programa Figura 6:7 Ejempio de casos de uso que muestran la relacion con los actores, Para idenuificar los casas de uso, se puede leer la descripeiin del problema y discutilo con aquelles que aetuarin como actores, empleando preguntas como > Cuiles son las tareas principales de cada actor? be (Tendr’ el actor que consultar y modificar informacion del sisterna? D> Deberi el actor informar al sistema sobre cambios extenos? D> Desea el actor ser informado sobre cambios inesperados? Por ejemplo, en un sistema de conmutacién telefénica, un actor podria ser un suscriptor, y un caso de uso tipico seria hacer una Hamada local, El caso de uso- comienza cuando ef suscriptor levanta el teléfono, Guo caso de uso es ordenar una Ilmada al servicio de despertador, Ambos casos de uso: comienzan cua do el suscriptor lewanta ef teléfono, pero cuando esto ocurre, no sabemos cui caso desext ¢} Por tanto, los casos de use pueden comenzar cle forma si milar y no podemos suber cual se est instanciando hasta que se termine. En abras, el actor nc requicre de que un caso de uso se ejecute, silo que ninaciin de otras pa inicie una secuencia de eventos que finalmemte resulte en la ter a in caso de uso. En el sistema de resernacianes de ruelas utilizamos los actores ya identificades como punto de partida. Dado que el Usuario es el actor primario se comienza con él, El sistema debe ser capax de ear ciertos servicios al usuario, como con sulas y reservactones. De aqui paxlemos definir nuestros cisas de uso prin cipales, Gonsultar informacién y Hacer wna Reservacién. Observe que los nombres de Jos casos de use deben corresponder a acciones ¥ no tanto a sus tantives, La figura 6.8 ilustra el sistema con Jos dos casos de uso, ademiis de un caso de uso adticional, Mandener ef Sistema, correspondiente a un actor se MODEL DE GASUS DE USO 203cundario Operador. Sin embargo, para lograr una mejor especificacion der quisitos y evitar complejidad adicional, no se veri ninguna funeionalidad de mantenimiento en nuestro desarrollo: un ejemplo adicional de emo concen trarse en cients aspectos de los requisitos durante diversas etapas, descripein det problema se menciona que, para utilizar el sistema, el 2 debe estar regisirado, por lo cual agregamos un caso de uses Registrar usuario, Por otro lade, se debe incluir la Base de Datos de Reservaciones y la ase de Dates de Registros ya que son actores secundarios necesarias, Estos tres casos de uso se onuestran en la figura 69. Notese las flechas unidireccionales dirigi¢nddose del actor primario hacia ef caso de uso y del caso d actor secundario, uso hacia el a ees Rogistrar Usuario ase de Omas Fegistos Consutar teeraeén — 3k on Base de Datos Reservaciones cor Rasarvacion Figu 6.8 Principales casos de uso para el sistema de reservaciones de vuelo. Se eliminé en el diagrama la delimitacién del sistema. Aunque La idea del modelo de casos de uso es que los diagramas sean lo mis sencillo posible, a menudo es necesario contar con mecanismos que permitan: extender las diageumas de manera mas elaborada. EI modelo de easos de uso Permite la subdivision de partes del flujo complete de un case de uso. ef €2s08 de uso separados. Las rizones son aprovechar distintos subjlujas que se repi- ten en miltiples casos de uso, de manera andloga al concepto de herencia, y resaltar los fujos menos comunes. Aunque, la complejidad de los casos de use €s un factor importante para tal decision, en general, no siempre es obvie que subflujos deberian definime como casos de uso separados, Existen dos enfoques distinios para expresar extensiones GAP. 6 — MODEL OF EQUISHTOS,D> Si las diferencias entre las casos de usa son pequefias, éstos se pueden des- cribir como variantes de un misma caso de uso, dando lugar al concepts de subflujos © ramificaciones dé Mujos dentro dé un mismo. caso de uso. Por ejemplo, en el caso de uso Regisivar Usuario, la creaciin por primera vez del registro y su actualizacion se pueden consklerar dos secuenctas de eventos Iogicamente similares, por lo cual se tratan como distintns subflu- jos en un mismo: caso de uso. En general, primero se describe el flujo prin- cipal o fxistco, el cual es el flujo mis importante dentro del casa de uso y generalmente el punto de entrada al casa de uso, Posteriormente se deseri- ben Jos swbflejos alternas que pudieran incluir flujos para el manejo de va- riantes en la lagica, en cuyo caso se conocen como subflujas aiternes. Nor malmente un caso de uso tiene sélo un curso bisica, pero varias subllujos ¥ cursos altemos. D> Si lus diferencias entre los casos dé uso son grandes, se deben deseribir como casos de uso separados, Cuando esto ocure, se utilizan principal mente las relaciones de extensién, énclusiin y generalizactin, como se des- cribe a continuacién. La identificacién de casos de uso es normalmente: un proceso iterative, donde se hacen mihtiples revisiones hasta llegar a una solucién final estable. Cuando esto ocurTe, cada caso de use debe describirse con. mis detalle. EXTENSION Un concepto importante que s¢ utiliza para estructurar y relacionar casos de uso es la extensién, la cual especifica céme un caso de uso puede fnsertarse en otro para extender la fuincionalidad del anterior. El caso de uso donde se insertar la nueva funcionalidad debe ser un flujo completo, por lo cual éste es independiente del caso de uso a insertarse, De esia manera, el caso de uso it Gial no requiere consideraciones adicionales al caso de uso a ser insertado, Uni camente se especifica su punto de insercién, Tomande como ejemplo el Sistema de Reservaciones de Viselos, se muestra en la figura 6.10 la notacién par extensién, utilizando la etiqueta “extiende (extend), donde el caso de uso de Hacer Reservactén se extiende mediante el caso de uso Pagar Reseriacién, Figura 6.10 Casos de uso Hacer Reservaciin con extensién de Pagar Reservacién En general, a extensidn se utiliza para modelar secuencias de eventos opeto- ales de casos de uso, que al manejarse de manera independiente pueden agre- garse o eliminarse del sistema de manera modular. Se puede considlerar a la MODELO DEasociacion de extension como una interrupeidn en el easo de uso original que curve donde el nueva caso de uso se vat insertar, Para. cada caso de Uso que vaya a insertarse en otro caso de uso, se especifica la pasiciin en el caso de uso original, donde la estensién se insertari, El caso de uscr original se ejecu- ti de forma normal hasta el punta donee ef caso de uso nuevo se inser. En este punto, se continda con fa ejecucién del nuevo curso. Después que la ex: lensiGn se ha terminado, el curse origin rrido, Por regla general, se deseribe primero los casos de use basicos, texalmen te independientes de cualquier extensidn de funcionalidad, y Inego las de ex tension, arse I continiia come si nada hubiera acu- IncLusION Una relacién adicional entre casos de uso es la inciusién. A diferencia de tina, extensidn, la inclusién se define como una seccitin de un caso de uso que es pane obligaroria del ciso de uso basic, 8) caso de uso dende se insertari funcionalidad depende del caso de uso a ser insertado, Esta relaciGin se etique- ta con “ineluye” Cinclude). Por ejemplo, en el Sistema de Reservaciones de Vue- Jas, el case de uso Consular informacion incluye el caso de uso Vatidar Ustia- Fo Como Se nitiestea en la figura 6.11 7 Nalidar Usuario Base de Datos oe ie Regist . ; Cs oe en a de Resenaciones GENERALIZACION Una relicider adieional entre casos de iso es la generalizacién, la cual apoya la reutilizacién de Ios casos de uso. Mediante la relacién de generalizacién €s necesurio describir las partes similares una sola ver, en lugar de repetiqlas para todos Jos casos de uso con comportamiento comin. Los casos de uso extraidos se conocen como eases de uso abstractos, ya que no serin instanciades. in- dependientemente, y serviein sélo para describir partes que son comunes a otros cases de uso. Las casos dé uso que realmente serin instanciados se a- man casos de uso concretos. Las descripciones de los casos de use abstrac- tos se incluyen en las deseripciones. de las casos de uso concretos. Una téeni- ca para extraer casos de uso abstracts es identificar actores abstractos. Esta generalizacién es una “herencia de secuencias’ (en lugar de operaciones, caso de herencia de objets). Por ejemplo, en el Sistema dle Resereaciones de Vuelos, cl caso de uso Pagar Reserewcin pudiera generatizarse en dos casos de CAP, 6 — MODELO. DE REQHISIVOSuso, Pagar con Tarjefa y Pagar con Transferencia, como se muestra en la figu- ma 6.12. Uno de estos dos "sub casas de use deberia instanciarse, a ssiiper” caso de uso, Pagar Reservacién, seria abstracto por no comocerse la forma de pago. K Base de Daios Fleservaciones i— a Usuatio Hocer Reservacion Pagar Rasarvacion version ei Figura 6.12 Gasos de uso Pagar Reservacién con goneralizacién de pagos: Pagar con Tarjeta y Pagar con Transferencia, Lis relaciones de extensién © inclusién entre casos de uso se implementan ambas mediante asociaciones de clases, a diferencta de: la generalizacion, la cual se implementa mediante herencia de clases. En la mayaria de los casos, Ja selecckin es bastante abvia; sin embargo, el criterio principal es ver qué tanto se acoplan las funcionalidades de los casos de uso, Si el caso de uso a ser ex: tendido es Gtil por si misma, la relacién debe ser deserita utlizando extension, Si las casos de uso 30n fuerterente acoplades y la inserci6n debe tomar higar para obtener un curse completo, la relacién debe ser deserita mediante la in- clusién. Por otro lado, la generalizacién se emplea cuande dos o mis casos de ‘uso comparten funcionalidad comin, la cual es extendids par cada uno al ¢s- filo de la generalizaci6n entre clases. También hay una diferencia en como se identifican estas relaciones. Las extensiones se identifican en un caso de vse existente, que ¢] usuario desea extender con secuencias adicionales, mientras que las inclusiones se encuentran de la extraccién de secuencias comunes ya ‘existente entre varios casos de usos, Las generalizaciones sé encuentran al tra. at de especializar de diferente manera un caso de uso existente Finalmente, se desean diagramas sencillos que no sean “telaranas", pero que muesiren de manera esquenvitica las posibles secuencias de interaceiones entre tos actores y el sistema, En la figura 6.13, se ilustra el diagrama completo de casos de uso para el Sis- tema de Reservactones de Vuelos, Los casos de uso adicionales en este diagra- ma son la extensiin de Registrar Tarjeta y Pagar ReservaciGn. Este vitime caso de uso es interesante, porque extiende Hacer Reservacién ¢ incluye Registretr Tanjeta, ambos requisites con el fin de comprar un boleto con el sistema, Ade is de La inclusién anterior, también se inchuyen las casos de usa de Validar MOPELO DE CASOS DE USO 207uswario y Oftecer Servicios en tos casos de uso bnisicos: Registrar Usuario, Core sultar kuformacion ¥ Hacer Reservack Consultar Inlormacén, Biase do Beto de Fepervaciones Figura 6.13 En el diagrama se muestran los. casos de uso completos para é! sistema de reservaciones de vuelo, que consiste en tres actores y siate casos de uso, 6.2.3 Documentacién Parte fundamental det modelo de casos de uso es Ix descripcin textual deta- Tlada de cada una de los actores y casas de uso identificados. Estos documen- tos son sumamente criticas ya que a partir de elios se desarrollari el sistema completo. El formato de documentaci6m para cada actor es el siguiente: Actor Nombre del actor Cass de uso | Nombre de los casos de uso en los cuales participa Tipo Primario o secundario, Descripcién —_| Breve descripcién del actor. Las descripciones de los casos de uso representan todas las posibles interaceio- nes de los actores con el sistema en los eventos enviadox o recibidos por €xt08, En esta etapa ng se incluyen eventas internos al propio sistema, ya que esto se estudiar durante el andlisis, y tinicamente agregaria una complejidad innecesa- ria. Fl formato de documentaci6n para cada caso de uso es el siguiente: CAP. 6 — MODELO DE REQUISITOSGaso de uso Nombre del caso deus ‘Actores ‘Actores primarios y secundarios que interaccionan con et ‘caso de uso. Tipo Tipo de taj: basico, iniusidn, extensiGn, generaiizackin @ 1 Razén de ser del casa do uso. | Resumen Resumen del caso de uso. Precondiclones | Condiciones que deben sailsfacerse para ejecutar ol caso de uso, Flujo principal | El fujo de eventos mas importante del caso de use, donde dependienda de las acciones de los actores, se continuard con alguno de los subflujos. Subfiujos Las fujos socundarios del caso da uso, numerados como ($0, (F2, etadtera, Excepciones: Excepciones que pueden ocurrir durante el caso de- uso, Hlumerados como (E-1), (E-2), etostera, Dado que el modelo de casos de uso esti motivade y enfocado: principalmen- te hacia las sistemas de informacién, donde los usuarios juegan un papel pri- mordial, es importante relacionarse con las interfaces a ser disefiadas en el sis- tema, Beas sirven pata apoyar de mejor manera la descripcién de los casos de uso, ademis de servir de base en prototipos iniciales. Un comentario importante sobre la especificacién de estos decumentas, es que ‘se sigue un proceso iterativo para definir cada uno de ellos, el cual se pod modificar © refinar después. Obviamente, cuanto mis tarde ocurran estos cam bios, mis costoso seri implementarlos, Note que en las siguientes descripci nes, ya se hace referencia a pantallas de interaccién con el usuario, tas cuales seriin mostradas en un dlisefio preliminar en la siguiente secciém, Los actores y casos de uso del sistema de reservaciones de vuelo son descritos en la secckin 6.4. 6.3 Modelo de interfaces El modelo de Interfaces describe la presentacidn de informac tores y el sistema, Se especifiea en detalle o6mo se verin las interfaces de usua- fio al ejecutar cada uno de los casos de uso, Si se trata de la interface huma no-computadera (HCI, Human Computer inierface), se pueden usar esquemas de cémo verfa el usuario las pantallas cuando se ejecuta cada caso de uso. Tas bién se puede generar una simulacién mas sofisticada usando un sistema ma- nejador de interfaces de usuario (URMS, User Interface Management System). Nor- malmente, un prototipa funcional de requisifos que muestra las interfaces de usuario es una estrategia importante. Esto ayuda al ustitrio a visualizar los casos de use segiin se mostranin en el sistema a constnuirse, Tal enfoque elimina mu- chas posibilidades de malos entendides, Cuando se diseftan las interfaces de usuario, es esencial tener a los usuarios involucrados, y que las interfaces refle- entre los ac- MODELO DE INTERFACES210 jen la visi6n légica del sistema, debiendo haber consistencia entre la imagen conceptual de} usuario y el comportamiento real del sistema. Si las interfaces son protocolos de hardware, se pueden referir a los diferentes estinetres, come protocolos de comunicacién. Estas deseripciones de interfaces son, por tanto, partes esenciales de has descripciones de 90 las dehen, acompa- iar, En estas elapas iniciales del desurrollo, ef diseiio de las pantallas no ex tan importante como el manejo de informacitin que se offece, el cual, debe corres: ponder a las necesidades de cada casa de uso, alge que se mostrar a comti- fuacién en el Sistema de Resemactones de Vuelos 8 €aS0: 6.4 Actores y casos de uso para el sistema de reservaciones de vuelos Tomande como ejemplo el sistema de reservaciones de vuelo, mostraremas | documentacién de los actores y cases de uso junto con el disedo de las inter. que se usarin como prototipo del sistema, Estos disefios pueden hacer papel o aprovechar wna herramienta que simplifique ka tarea del diseno de lias, EL objetivo primordial es llegar a un acuerdo ripido sobre la funcio- jad de Ia aplicacidn, mats que lograr un diseno grifico sofisticade pan n 6.4.1 Actores Se describen en tofal tres actores cn el sistema de reservaciones de Vuelos. El Cimario interacnia con uxdes los casos de uso, aunque todas las asociaciones no fueron diagramadas de manera explicita en la figura 6.13, ‘Actor Usuario. Casos de uso | Validar Usuaria, Registrar Usuario, Registrar Tarjeta, Consuitar informacién, Hacer Reservacion, Pagar Reservaciéa, Otrecer ‘Servicios. Tipo Primaria. Deseripelén | Es el actor principal y representa a cualquier persona que desee utilizar el sistema de reservaciones. La Base de Datos de Registros interactiia con los casos de uso relacionados ex clusivamente con registra, Actor Base de Datos de Registos Gass de uso | Validar Usuara, Registrar Usuana, Registrar Tarjeta [Tipe Secunda, Descripcion Es un actor secundario y representa a la base de datos donde ‘se guarda toda la informaciin relacionada con los usuarios, { pero independiente de las reservaciones. CAP, G — MODELO. DE REQUISITOSLa Base de Datos de Reservaciones imeractia con los casos de uso: relacionados ‘exclusivamente con reservaciones, Actor ‘Basa de Datos de Reserraciones. Casos de uso | Consular Informacién, Hacer Reservacién, Pagar Reservacién. Tipo Secundario. Deseripeién§—_| Es un actor secundario y representa la base de datos donde se Quards toda la informacian relacionada con las. reservacionss, ero independiente de los propios usuarios del sistema, 6.4.2 Casos de uso Como apoyo en la descripcién de las cases de use, mostraremos las diversas pantallas dischadas, comenzande con Lx pantalla principal. Dado que el requi- sito de uso del sistema es que todo usuario deba haberse registrado, la panta- lla principal debe dar dos apciones: 2) registrarse por primera vez y b) validar Un registto existente como se muestra en Ia figura 6.14 ‘SOMA PESGSWAGIMER DE WELD ents dent Ha ph “Gane ees Parone ren mi gre —_——_ ee | | of oe oe - - SEE Figura 6.14, Pantalla principal del sistema (P- 7). Observe que el caso de uso Registrar Usuario, como lo deseribiremos en nues- tro ejemplo, agrupa la l6giea relacionada com un usuario ya registradc junto con fro que se registra por primera vez, Dado que lx epciGn para registrars por ACTORES ¥ CASOS DE USO PAWA El. SISTEMA DE RESERVACIONES De VUELOS 2212 primera vez debe aparecer en la pantalla principal (P-2), la opciin en la pan lalla de servicios (P-2) es utilzada por un usuario ya registrado. ¥ aunque se podrian definir dos casos de uso separados para la Iigica de registro, por ejem- plo, Crear Registro Usuario y Ghtener Registro usuario, consideramos que éstos son més bien subflujos de un mismo exso de usc. Es conveniente hacer notar que existen muchas maneras de descrfbir un sistema similar, donde por lo ge= neral una forma no es necesarlamente mis cormecta que Ia otra, siendo mds bien una cuestion de estandanizackén o estilo del analista. En nuestro caso, busca- mos soluciones compactas que reduzcan el ndmero total de casos de uso, siem- pre y cuando la Iigica esté muy relacionada. Se incluyen ademds varios subflu- Jos para llamar secciones del flujo desde distintos lugares, ya que no se puede comenzar un flujo 6 subflujo en la mitad del proceso. A continuacién describ mos los distintos casas de uso con las pantallas correspondientes. Se excluyen pantallas menores como aquellas con mensajes de error o confirmacién cel Exit de la operacién. Comenzamas describiendo los flujos Validar Usuario y Ofrecer Servicios, que se incluyen en los diversas casos de uso. Pasteriormente descrt- bimos cada uno de los casos bisicos y de extensién, VALIDAR USUARIO El caso de uso Malidar Uswario esti vinculade con la pantalla principal (2) y se llama a pamtir de los casos de uso Registrar Usuario, Consultar myfarmactin y Hacer Reservacién coma se mostré en el diagrama de la figura 6.13. Dado que este caso de uso se inserta en los anterlormente mencionados, depende de éstes incluirlo y Hamarlo apropiadamente. ‘Caso de uso | Validar Usuario. ‘Actores Usuario, Base de Datos de Registros. Tire Hckasion. Propésito ‘Validar a un usuario ya repistrada para #l uso del sistema de reservaciones de vuelo, Resumen Este caso de uso, se inicla por el usuario. Valida al usuario mediante un login y password a verticarse con su respective ragisiro de usuario, para que pueda utlirar el sistema de reservacionss. Precondiciones | Se requiere haber ejecutado anteriormente e@l caso de uso Registrar Usuario subfiujo Crear Registro Usuario. Flujo principal | Se presenta al usuario ia pantalla principal (P+). El usuario puede seleccionar entre fas siguientes opciones: “Registrarse por primera waz", "OK" y “Sali Si la actividad selecctonada #8 “Registrarse por primera vez", 56 ejecuta al caso de uso Registrar Usuario, subfujo Craar Alegistra Usuario (S-1) Si la actividad seleccionada 68 “OK”, se valida ol registro de Usuaric mediante un Jogin y un password insertados. por el usuario en ta pantalla principal (F1). Una vez validado el usuario (E+), sa continda con el cago de uso Ofrecer Servicios. Si la actividad seleccionada es “Sali” se saldré. del sistema. (continua) CAP. 6 — MODELO. DE REQUISITOS(continuacin) pa Subtujos Ninguno. ] Excepclones | E-1 no hubo vaildaciGn: ol logivypassword no s2 valldo correctamente. Se solcita a! ususrio volver a registrarse. Despuds de tres intentos se saldra del sistema. OFRECER SERVICIOS Si observamos el diagmma de casos de uso de la figura 6.13, vemos que exis ten tres casos de uso basicos que el ustirio puede instanciar: Registrar Uita- rio, Hacer Reservacién y Consulter informacisn. El caso de uso Ofnecer Seni- cio se incluye en estos tres casas de usa Irisicos part delegarles de manera adecuada, segtin las opciones seleceionadas par el usuario. También se inchi- ye en el caso de uso Validar tsuario, luego de la validacién de un ustario. ‘Caso de uso Otrecer Servicios. Actores Usuario, Tipo tnotusién, Propésito Otrecer los diversos Servicios a un Usuario ya registrado ara que use el sistema de reservaciones de ueto, Resumen El usuario inicia este caso de uso. Tlene capacidad de utlizar las diversas opciones del sistema de reservaciones. Precondiciones | Se requiere haber validado correctamente al usuario, Flujo principal —_| Se presenta al usuario la pantalla servicios (P-2). E] usuario puede seleccionar entre las siguientes actividadas: “Consultar informacion”, "Hacer reservacién”, “Obtener registro” y “Sali, Si la actividad seleccionada es “Consultar informacién’, se continda con el caso de uso Consultar informacidn, subflujo Consuttar (5-1) Si la actividad seleccionada es “Hacer reservaciin’, se Continda con el caso de uso Hacer reservacién, subuio Solicitar Clave Resanvacién (S-1}. Si la actividad seleccionada @s “Obtener Registro”, 36 comtinga con @t caso de uso Registrar Usuarlo, subfiujo ‘Obtener Registro Usuario (S-2) Si la actividad seleccionada es “Sali” se saldra. del sistema. Subtlujos ‘Ningun Excepciones, ‘Ningune, Por tal motive, la siguiente pantalla del sistema debe permitir al usuario selec- cionar las epciones correspondientes, coma se muestra en la Aigura 6.15 REGISTRAR USUARIO El caso de uso Registrar Usuario esta vinculado con el registro inicial del usua- fio y 1a modificacién de la informacién de registro. Ademds, ya deben inchuit- ACTORES ¥ CASOS DE USO PARA EL SISTEMA DE RE: 213Figura 6.15 Pantalla de Mend de servicios (P-2. se los puntos de inclusién y extensi6n para los casos de uso Validar Userrio, Ofrecer Servicios y Registrar Tarjete, respectivamente, Se describe a continuactén las secetones iniciales del caso de uso, con las sec- ciones restantes, subflujos y excepciones, mas: adelante. ‘Actores Usuarie, Base de Datos Regisiros. Tipo Basico. Propésita Permit a un usuario registarse en el sistema de reservaciones de wueto para usario. Resumen El usuario inicla. este caso de uso. Otrece funcionalidad para crear, modificar y eliminar el registra de usuario con el sistema de reservaciones. Precondiciones | Todos los subflujos, con excepoidn de Crear Registro Usuario. ($1), requisren ejecutar inicialments #1 caso de uso Valdar | usuario, ‘Flujo principal | Se ejecuta el caso de uso Validar Usuano, Dependiendo de las opciones seleccionadas por el usuario, s@ continuand Con los diversos subfiujos de aste caso de uso. 214 CAP. 6 — MODELO DE REQUISITOSEl disefio de la pantalla de registrarse por primera vez se muestra en la figura 6.16. calc cme [ae tg ma of af, oo]. Figura 6.16 Pantalla de Crear registra de usuario por primera vez (P-3) El subflujo Crear Registra Usuania (5-1), descrito a continuacién, se instancia al presionar el botén correspondiente de la pantalla principal (P-2) Subflujos | 5-1 Crear Regisiro Usuario. ‘Se presenta al usuario ta pantalla “crear registro usuario” (F-3), qua ontiene informaciin de registro que debe llenar e! usuario, lo cual incluye nombre, apelldo, calle, colonia, ciudad, pais, c6digo postal, twidlonos de ta casa y oficina, rimero de fax, login, email, password y Una entrada adicional de repetir password para asegurarse de que 80 escribié correctamente, El sistema usard ol login y el password para validar al usuario. El uouario puede seleccionar entre las siguientes actividades: “Registrar ~ y “Salic’. Sie! usuario selecciona “Registrar, e! sistema genera un nuevo registro de usuario (E-1, E-2, E-3, E-4). Se continua con el subflujo ‘Adminisirar Registro Usuario (S-3. Si la actividad seleccionada os “Sali se saldré del sistema (s! atin no 8@ hia presionado “Registrar, la informacion se perder). En la figura 6.17 se ilustra el disefto de la pantalla para administrar un 1 de usuario existente, Note que la informacién que ofrece es exactamente igual ACTORFS ¥ CAS $ DE USO PARA EL SISTEMA DE RESERVACION! DE VUELOS 215a la anterior. La unica diferencia son las apeiones. que se ofrecen: eliminar y actualizar en lugar de registrar, Figure 6.17 Pantalla de Obtener registro de usuario (P-4), El resto de los subflujos se describen a continuacién, El subflujo Obtener Regis- car 6 — MODELS SByTiBT ed material‘Subftujos —_| Si 6! usuario presiona “Actualizar’, s0 ejocuta el subfiujo Actuaitzar (continuacién) | Registro Usuario (5-8) Si ol usuario: selecciona “Eliminar’, se ejecuta el subfiujo Elminar Registro tisuarie (5-5) Si ol usuario presiona “Registrar Tarjeta’, se continéa con el caso de uso Registrar Tarjeta Si ta actividad seleccionada es “Servicies”, se continua con et caso de uso Ofrecer Servicios. Si la actividad seleccionada es “Sali”, se saldrd del sistema (si alin no 8@ ha presionado “Actualizay’, ta nueva informaciie 82 perderd) $4 Actualizar Registro Usuario. Se actualiza el registro de usuario can la informaciin modificada (ET, £3, £4, Se continiia con el subtiujo Administrar Registro Usuario {$-3), ‘$5 Eliminar Registro Usuario. Se elimina el registra de usuario y s¢ continda con el subtivja | Crear Registro Usuario ($1) Las excepeiones del caso de uso son las siguientes: Excepciones | £1 informacion incompleta: falta llenar intormacién en el registro de usuario, Se vuelve # solicitar al usuario que complet registro, E-2 Registro ya existe: si ya existe un registro bajo ese login, se solicitard al usuario que lo cambie 0 que termine el caso de uso. E-3 Login incomecto: el Jagin no 88 wAlido. Se le solicita al usuario ‘que coeria el registro, E-4 Password incorrecto: €| password escogido ea muy sencilla 0 no Se validé conectamente. Se solicita ai usuario que comrja el registro REGISTRAR TARJETA El caso de uso Registrar Tarjeta es una extensién del caso de uso Registrar Uwwario, De manera similar x Registrar Usuario, el caso de uso Registrar Tarje- fa est compuesto por un registro inicial y por la modificacion de la informa- cin ya registrada, Se describe 4 continuacién las secciones iniciates del caso de uso, con las 5 Giones restantes, subflujos y excepciones, mis adelante. Note quie el flujo peine Gipal se llama al presionar "Registrar tarjeta” en. la pantalla de obtener registro de usuaria (P-4), ACTORES ¥ CASOS DE USO PARA EL SISTEMA DE RESERVACIONES BE VUELOS 217,Caso de uso | Registrar Tarjeta. Actores Usuario, Base de Oatos Rgistros. Tipo. Extension, Propésito Permitir a un usuario registrar una tarjeta de erédito en el sistema de reservaciones de wuela para pagar boletos, Resumen Este caso de uso Jo inicia el Usuarie. Gtrece funcionalidad para creat, modificar y eliminar al registro de tarjeta usuario con ‘objeto de pagar las reservaciones diractamante en ol sistema de reservaciones. Precondiciones | Ei usuario ya s debi6 registrar mediante ta activacion del caso de uso Registrar Usuario, Flujo principal | Se continda con el subfluje Obtener Registra Tarjeta (5-2). Si na existe Un registro dé tarjeta valido 8& ContinGa con et Subtlujo Grear Registro Tanta (5-1). De lo contrario, 51 ya existe uno, ‘36 continua con el subfiujo Administrar Registra Tarjeta (S-3). El diseo d Figura 6.18, nuestra en ntalla para registrar la tarjeta por pr Figura 6.18 Pantalla de Crear registro de tarjeta por primera vez (P:5), El subflujo Regiswrar Tarjeta (5-1), descrito a continuacién, se instancia al pre- sionar el bot6n correspondiente de la pantalla “servicios” (P51 218 CAP, 6 — MODELO_ DE REQUISITOSSubtiujo | S-1 Crear Registro Tajota Se presenta la pantalla “Crear Registro Tarjeta” (P-5). La pantalla incluye el nombre como. aparece en la tarjeta, nomero de tarjeta, al ‘ipo de tarjeta y la fecha de vencimiento El usuario puede seleccionar entre las actividades “Registrar, “Servicios”, “Sali. Si el usuario prasiona “Registrar, el sistema verifica ta informacion (E+), y s2 cantina con el subfivja Administrar Registre Tarjeta (5-3), Si la actividad seleccionada es “Servicios”, se continda con el caso ‘de uso Ofrecer Servicios. Sila actividad seleccionada es “Salir’, se saldrd del sistema (si aun no se ha presionada ‘Registrar’, la nueva iniarmacién se perder) En Is figura 6.19 se we el disefio de Ia pantall para la administracién de wn rex istro de tarjeta existente, Observe que la informacidn que ofrece es exactamen: te igual a Li anterior. La tinica diferencia son las opeiones que se ofrecen: el minar ¥ actualizar en lugar de registrar | RSE Figura 6.19 Pantalla de Obtener Registro Tarjeta (P-6). EI resto de los subflujos se describen a continuaci6n, Los subflujos Obiener Re- gistro Tarjeta (5-2) y Administrar Registro Tarjeta (S-3) se utilizan para leer y manipular el registra de tarjeta, respectivamente. El subflujo Aetualizar Registre Taneta (5-4) se instanciado presianando el hotén correspondiente de la panta- ACTORES Y CASOS DE USO PARA EL SISTEMA DE RESERVACIONES DE VUELOS 219Ita de registro (P-6). El subflujo Eliminar Registro: Tarjeta (8-5) se instancia pre- sionando el botén conespondiente de la pantalla de registro (P-6) Subtlujos | S-2 Oblener Registro Tanta. (continuacie) | €: sistema obtiene al registro de tarjeta de la base de datos de ragistro. Se regresa al flujo anterior. ‘$3 Adminisirar Registro Tarjela ‘Se presenta la pantalla “Obtener Registro Tarjeta’ (P-é), que incluye el nombre como aparece en la tarjeta, némero de tarjeta, el tipo de tarjeta y la fecha de vencimiento, El usuario podrd seleccionar entre las actividades "Eliminar’, *Actualizar’, "Servicios" y “Sali. Gi el usuario presiona “Actualizar” se ajecuta el subsiujo Actualizar Registro Tarjota (S-4). - Si el usuario presiona “Eliminar’, se ejecuta el subslujo Eliminar Registro Tarjeta (S-5} Si la actividad seleccionada. es “Servicios”, se contintia con el ca80 de uso Ofracer Servicios. Si la actividad eeleccionada es "Sali se saldré del sistema. $4 Actuallzar Registro Tarjeta. ‘Se actualiza el registro de tarjeta con la informaciin modificada (En, ‘Se continga con el subtiujo Adminisirar Registro Tarjeta ($2). $5 Eliminar Registro Tarjeta. Se elimina el registro de tarjeta y se continda con el subflujo Crear Registro Tarjela (S- 1. Las excepciones def caso de uso son las siguientes, Excepciones | E1 informacién incomplets: falta benar Intormacion Indispensable para completar el registro de tarjeta. Se le vuelve 2 pedir al usuario que complete el registro de tarjeta CONSULTAR INFORMACION El caso de uso Consultar informacion se instancia a pantir de la pantalla de ser- vicios (P2), una ver que se haya validado el usuario y seleceionado el batén correspondiente. Este caso de uso es ef mis complejo de todos los de! sistema, ya que incluye tres tipos de consultas distintas: consulta de horarios de vwelo, consulta de tarifas y consulta de estado de un vuelo, Fi caso de uso se describe a continuaci6n, ¥ excluye los subflujes y restriecio- nes que se describen mis adelante CAP, @ — MODELO_ DE REQUISITOSUsuario, Base de datos de reservas. [eds Parmitir a un usuario consultar informacion con el sistema de rasorvaciones de vuelo, El usuario inicia este caso de uso, Ofrece funcionalidad para ‘consuftar informacién de horarios, tarifas y estado de vuelos con reservaciones. ‘ol sistema de ‘Se requiere haber ejecutads antes 1 caso de uso Validar usuario. ‘Se ejecuta el caso de uso Validar usuario, Dependiendo de as opciones seleccionadas por el usuario, s¢ comtinuard con los diversos subflujos de este caso de uso. ‘Antes de proseguir con la descripcién del caso de uso, mostramos la pantalla que resume esta decisidn, como se muestra en la figura 6.20, Figura 6:20 Pantalla de Seleccién de tipo de Consuttas (P-7). Dado que el usuario puede iniciar una consulta de varias paginas distintas, como: se veri posteriormente, se incluye un primer subfiuje para iniciar estas consul- tas llamado Consultar (5-1), como se observa 2 continuacién: YY CASOS DE USO PARA EL SISTEMA DE RESERVACIONES DE VUELOS . 22; ACTORES Y CaS Copyrighted mate