aT NT ee eae | ans Teen aera PIU CYS Ey WC ih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 cliemte desea segin la percepcién del desarrollador, Por ello, es esencial que los clientes fo comprendan, EI modelo de requisitos es el primero en dexirollarse, y ex lt base pana 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 (facobsom ef al. 1992), que tiene su fundamento en el modelo de casus 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én: D> Requisitos: El modelo de casos de uso: sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperackin con otros mexdelos como se veri mis adelante. D> Analisis: 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 Idgico independiente del ambiente de implemen- tacitin, D> Disefio: 1a funcionalidad de los casos de uso, ya estricturada por el and lisis, La realiza el modelo de diseho, adaptindose af ambiente de implemen- taciéin real y refindindose atin mis. implememtacién: Los cass de uso se instrumentan mediante el eddie fuente en el modelo de implementacién. Be Pruebas: Los casos de uso se compniban a través de las pruebas de com 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 documentos come las manuales de usuario, de administracion, etoétera. Fl diagrama de la figura 6.1 ilustra los distintos modelos, los detalles y la nota cién que se describirin mas adelante.196 (S) [e8] al [=] Ee] = ES G+} |G+ Stee Modelo de Modelo de = Madolo 2 Madelo de © Madalo da Maal da requisiios anita ieeFio—implementaciéa pruebas documentacida Figura 6.1. Dependencia de los distintos modetos del proceso de software del modsio de casos de uso. El propésito del modelo de requisitos es comprender en su totalidad el proble- ma y sus implicaciones, Los demiis modelos, anilisis, disefo, implemenacicn, y pruchas depencen directa © indirectamente del moclelo 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 desde la perspectiva del usuario. El mexiela de requisitos na es un praceso me- ciinico, | analista debe interactuar constantemente con el cliente para comple- tar la informacién faltante, y asi resolver ambigiiedades € inconsistencias. Tam- bign debe separar los requisitos verdaceros de las decisiones relacionadas con el diseno ¢ implementacién, Se deben indicar cuiles aspectos son obligatorios y euiles opeionales para evitar que se limite la flexibilidad de la implementa Durante el diseho, 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 el 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 easos de uso} 4 ae __Informacién Lo (Gominio: det problema) Prosentacién (irtartaces/bore) 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 ofrece el sistema desde el punto de vista del usuario, Este modelo utiliza dos conceptas claves: actores para re- CAP. 6 — MOBELO. 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 efecutar los casos de uso, En Particular, en los sistemas de informacion que thenen mucho contacto con el usuario, especifica cémo se verin visualmente las interfaces grificas, y ‘qué funcionalidad ofrecer! cada una. > El modelo de tjormacién o modelo del domino del problema especifica los 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. Ademas, es utilizade para guar- dar informacidé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 cle modelado indepen- dientes sirve para una mayor estabilidad en el desarrollo del sistema, lo que permite minimizar los efectos de cada uno sobre los otros. dos Para ilustrar el modelo de requisites y el desarrollo de las models 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 tuna especificacion de necesidades y no una propuesta de solucidn. La descrip- ci6n inicial puede ser incompleta € informal, pues al realizarse sin un andlisis completo, no hay ninguna razon para esperar que sea correcta, Como ejemplo se desarrollaed un Sistema de reseriaciones de rueios, el cual per- mitiri al usuario hacer consullas y reservaciones de vuclos; ademis de comprar los boletos aéreos de forma remou, 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 los 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 vuelos es la siguiente: DESCRIPCION DEL PROBLEMA 197°198 _——— Fl 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), EI sistema presenta en su pantalla principal un mensaje de bienvenida des- ccribiendo 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 vvalidarse. Una vez registrado el usuario, y después de haberse validado el regi. 110 y contrasefta del usuario, se pueden seleccionar las siguientes activi- dades; Consulta de vnelos 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 nucle La consulia segiin horarios muesira los horarios de las diferentes aeroli- eas que dan servicio entre dos ciudades, La consulta segtin tarifas muestra los diferentes vuelos entre dos 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 esté a tiempo. Se pueden incluir preferencias en las xisquedas, 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, adquitir los boletos. aéreos, Kcontimiay CAP, 6 — MODELG, 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 es la primers actividad del desarra- lo del sistema, permite hacer muchos cambios cn su cspecificacion sin. afectar al resto del sistema. Cuando se identifican y describen los casos de uso, habri ciertas 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 cienta funcidin que una persona real realiza, En la terminologia orten- tada a objetos, se considera al actor una clase de ustiatio, 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 maxlelan cualquier entidad externa que necesite intercambiar infor- macién con el sistema. No estan restringidos a set personas fisicas, por lo que pueden representar otros sistemas externos al actual. Lo esencial es que los ac- ‘ores representen entidades externas al sistema, Ademés, cada uno de estos actores pod ejecutar una o mis tareas del sistema. Antes de identificar los casos de uso, se identifican 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 sistent como una “caja negra’, y a los diferentes actores, como entidades externas a ésta, como se anuestea en la figura 64, 2. Programador Re Usuuare Figura 6.4 Delimitacion de un sistema segan los actores, CAP. 6 — MODELO DE AEQUISITOS,En general, no se describen los actores con demasiado 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 entre multiples opciones. Por otro lado, el sistema y los 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 recanacer 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 ejecucién del sistema. Ademds 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 los 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 secundatios Conesponden, por lo general a miquinas a sistemas ex- temas (estos himos son mis dificiles de identifica. Los actores secundarios Hienden a responder a secuencias Kigicas de! 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 funcién 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 Tamaremas la Base de Datos ce Reservactones, el cual mantiene Ia informacién sobre los vuelos y feservaciones. 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 informaciin 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 do Datos ‘Ge Registros Figura 6.5 Delimitacién del sistema de reservaciones de vueto. Volviendo a Ia distincién entre actor y persona, una misma persona puede des- empefar la funcion del actor Uswaria cuando hace reservaciones, y ademyis 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 Datas 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 vi en el capitu- lo 4. Q —__aesas 2 ns 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 @ pane del mismo caso de usa se puede ejecutar por va- fins actores diferentes. el caso de uso necesita ser especificada 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 a niltiples actores en un sistema, 6.2.2 Casos de uso Despueé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 orientasla 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 tina instancia del mismo, sea, 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 secuencias, 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 cas0 de USO nuevo, Las diferentes instancias dle los easos de uso 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 imeractiia 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 informacidn 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 fas 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 PESGSWRCIMER DE WELD ens dent Ba ph “Gane ees Perego i ren meen a ee | | of oe —— - - SEE Figura 6.14, Pantalla principal del sistema (P-f). Observe que el caso de uso Registrar Usuario, como Io deseribiremos en nues- tro ejemplo, agrupa la l6giea relacionada com wn usuario ya registrada junto con fro que se registra por primera vez, Dado que la opcién para registrarse: por ACTORES Y 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 Jos puntos de inclusién y extensi6n pars 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. ‘Actors Usuarie, Base de Datos Registro. Tipo Basico. Propésito 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 rear, modiicar y eliminar el registra de usuario con el sistema de reservaciones. Precondiciones | Todos los subflujos, con excepoiin de Crear Registro Usuario. ($1). requisren ejecutar inicialments 1 caso de uso Validar | usuario, ‘Flujo principal | Se ejecuta el caso de uso Validar Usuario, Dependiendo de las opciones seleccionadas por el usuario, s@ continuand Con las 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. aca exe [ae tg ra Ss | 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 prosenia al usuario ta pantalla “crear registro usuario” (F-3), qua contiene 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 na entrada adicional de repetir password para asegurarse de que Se escribié correctamente, El sistema usaré ol login y el password para validar ai usuario. EI uouario puede seleccionar entre las siguientes actividades: “Registrar ~ y “Salle. ‘Sie! usuario selecciona “Registrar, el 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 6s “Salir se saldré del sistema (s! atin no 8@ ha 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 egis- 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 Registros. 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 Usuario. Gtrece funcionalidad para creat, modificar y eliminar al registro de tarjeta usuario con ‘objeto de pagar las reservaciones diractamante en oi sistema de reservaciones. Precondiciones | Ei usuario ya 58 debi6 registrar mediante ta activacion del caso de uso Registrar Usuario, Flujo principal | Se continda con el subflujo Obtener Registra Tarjeta (5-2). Si na existe Un registro dé tarjeta vélido 8& ContinGa con et subtlujo Grear Registro Tanta (5-1). De la contrario, 51 ya existe uno, ‘56 continua con el subfiujo Administrar Registra Tarjeta (S-3). El disedo Figura 6.18, nuestra en Atala 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 Grear 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 2 cantina con el subfyja Administrar Registro Tavjeta (S-3), i 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 pantalla para la administracién de wn rex istro de tarjeta existente, Observe que la informaciGn que ofrece es exactamen: te igual a ki anterior. La tinica diferencia son las opeiones que se ofrecen: el minar ¥ actualizar en lugar de registrar | RRS 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 (2) y Administrar Registro Tarjeta ($-3) se uiilizan para leer y manipular el registra de tarjeta, respectivamente. El subflujo Aetualizar Registre Taneta (S-4) se instanciado presianando el hotén correspondiente de a 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 resorvaciones 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 6! caso de uso Validar usuario. ‘Se ejecuta el caso de uso Validar usuario, Dependiendo de as opciones seleccionadas por el usuario, s¢ continuard 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 decisin, como se muestra en la figura 6.20, Figura 6:20 Pantalla de Seleccién de tipo de Consuitas (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 (S-1), como se observa 2 continuacién: YY CASOS DE USO PARA EL SISTEMA DE RESERVACIONES DE VUELOS . 22; ACTORES Y CaSO Copyrighted mateSubtiujos | $1 Consuitar. Se dow i panala “Conaulo (F7 El usuario pute, seleccionar entre las siguientes actividades: “Horarios", “Tarifas”, “Esiado’, "Servicios" y “Sali”, ‘Si el usuario presiona "Horarios”, se activa el subfvjo Gonsultar Horarios (5-2). ‘Si el usuario presiona “Taritas’, se activa el subfiyjo Consultar Taritas (S-). ‘Si el usuario presiona “Estado”, 38 activa é! subfujo Consultar Estado (S-6). Si ol usuario presiona "Servicios, se pasa al caso de uso Otrecer ‘Servicios. Sie! usuario presiona “Sali sale del sistema. En la Figura 6.21 se muestra el disehio de la pantalla para la consulta de hora nos de vuclos, correspondiente al subfluja Constiltar Hiorartos ($-2), Figura 6.21 Panialla de Consulta de horarios de vuelos (+8). En ta Figura 6.22 s¢ muestra ¢l diseno de la pantalla para ef resultado de la consulta de horirios de vuelos, correspondiente al subflujo. Devoler Horarios «S3). CAP. 6 — MODELD. DE AEQUISTOSS jorCs | decane | tes |] Figura 6.22 Pantalia de Resultados de consulta de horarios de vueios (P-9) Los subflujos Consultar Horarias (8-2) y Devolver Honarios (5-3) se muestean a ccontinuacisn: ‘S-2 Consultar Horarios. ‘Se presenta al usuario la pantalla “Consulta horarios” (P-8), Esta pantalla debe Ser lienada con informacion de ciudad de onigen y destino, y preferencias opcionales de: aerolinea, horario y una opcion de vuelo directo. El usuario pusde seleccionar las siguientes actividades: “Consultar’, “Servicios” y “Salir. ‘Si e/ usuarlo presiona “Consular”, 6! sistema recibe la informacion {E1, £2), 5e continda con el subtujo Devotver Horarios (S-3). ‘Sie! usuario presiona "Servicios", se continua con el caso de uso Ofrecer Servicios. Si 6! usuario presiona “Salir" se sale del sistema. $3 Devolver Horarios. ‘Se presenta la pantalla “Resultado horarios” (F-9) que contiene Infermacién sobre los diferentes vuelos encontrados, La Informacion incluye la aerolinea, el vuelo, los dias, el horario y las restricciones, tales como facha de inicie terminacién del vuelo. Al principio de cada fla se encuentra una opcidn de seleccién para obtener informacién adicional sobre et vusio. (©ontinda) AGTORES ¥ CASOS DE USO PARA EL. SISTEMA DE RESERVACIONES DE VUELOS 223E usuario puede seleccionar entre las siguientes opciones: "+". “2, “Nueva consulta’, “Servicios” y “Salle”. En la figura 6.23 se muestra el disco de la pantalla para la consulta de tarifas de vuelos, correspondiente al subflujo Consultar Tarifas (5-4) Figura 6.23 Pantalla de Consulta de taritas de vuelos (F-10). En Ia figura 6.24 se ilustra el disefio de Ia pantalla para el resultado de la con- sulta de tarifas de vuelos, correspondiente al subflujo Devoleer Tarifas (S-5). CaP. 6 — MODES RA HERE AfaterialFigura 6.24 Pantalla de Resultado de consulta de taritas de vuelos (P+ 1), ‘Los subflujos Gonsultar Tarifas (Sf) y Devolver Tarifas (5-5) se muestean a con inuacidn: $4 Consuttar Taritas. ‘Se presenta al usuario la pantalla “Consultar taritas” (P-10), la cual se lena con informaci6n de la ciudad de origen y el destino, y las proferencias opcionales: fecha de salida, fecha de regres, aerolinea, ‘lase y opciones de organizar la informacsén por menor tarta, una opcién de vuelo directo y si la tara se basa en viaje redendo. El usuario puede seleccionar entre las siguientes actividades: “Consultar’, “Servicios” y “Sali, Si el usuerio presiona "Consulta, el sistema recibe la. informacion (E1, £3, 88 continda con el subtlyjo Devolver Tarilas (5-5), Si el usuario presiona "Servicios", se continda con el caso de uso Ofrecer Servicios. Si el usuario presiona “Salir, sale del sistema, $5 Devolver Tarifas, Se presenta la pantalla “Resultado tarifas" (P-11}, que contiene intormacién sobre los diferentes: vuelos encontrados. La informacién incluye fa aerolinea, el ywelo, la fecha, el horario, la tarita en viaje ‘sencillo 0 viaje redondo y restriociones correspandientes. Al principio de cada fla se encuentra una opeién para seleccionar en caso de hacer consultas 0 reservas sobre los vuelos obtanidos. (contiaua) AGTORES ¥ GASOS DE USO PARA EL SISTEMA DE RESERVAGIONES DE VUELOS 225El usuario puade seleccionar entra las siguientes opciones: “Nueva Consulta’, “Servicios” y “Sallr’ Si el usuario presiona "+", se muestran resultados adicionales de: horarios, Se continda al inicio de este subllujo. Si el usuario presiona "", se muesiran resultados anteriores de horarios. Se continga al inicio de este subfujo. ‘Si el usuario prestona ‘Nueva Consulta’, se continda con et ‘subflujo Consullar Tarifas (S-4). ‘Si el usuario presiona “Servicios”, s# continGa con et caso de Uso Ofrecer Servicios. ‘Si.el usuario prasiona “Sali, sale del sistema. La figura 6.25 ihistra el disefo-de la pantalla para la consulta de estado de vuelo, correspondiente al subflujo Consular Estado (5-6). Figura 6.25 Pantalla de Consulta de estado de vuelo (P-12), En la figura 6.26 se muestra el diseno de Ia pantalla para el resultado de ka con- sulta de estado de vuelo, correspondiente al subfujo Devolver Estado (5:7). CAP 6 — MORSE GRAY Rtateriala ich SETTUN GE EMCEE ORL i Pin rms Bene 1 i Feomnn [ee | ce et a ee cacy —— pa ae Figura 6.26 Pantalla de Resultado de consulta de estado de vusio (P-13). Las subflujos de Consular estada (S-6) y Devolver Estado (S-7) se muestran a continuaci6n: $6 Consuitar Estado. ‘Se presenta al usuario la pantalla “Consultar estado" (P-12). Esta [pantalis debe ser llenada con informacion de Ia cludad de origen y 11 destino, la aerolinea, el nimero de wuelo y la opeién dé vuslo ‘3é dia consultada, El usuario pusde Seleccionar alguna de las siguiontes actividades: “Consultar’, “Servicios” y “Sali, ‘Si el usuario presiona "Consultar’, el sistema recibe la informacion (E-1, E-2) y 88 continisa con el subfiujo Devolver Estado (S-7). ‘Si el usuario presiona “Servicios”, 8e continda con al cas0 08 USO Ofrecer Servicios. Si el usuario prasiona “Sali”, sale del sistema. S-7 Devolver Estado. Se presenta la pantalla “Resulted estado" (P-73), que contiene informacion sobre ei vuelo, como su estado, por ejemplo. -contimmado, retrasads, cancelado, (continga) AGTORES Y GASOS DE USO PARA EL SISTEMA DE RESERVAGIONES DE YUELOS 227228 Subflujos | El usuario puede seleccionar entre las siguientes opciones: “Nueva {continuacién} | consulta”, “Servicios” y “Safir”. Si ol usuario presiona “Nueva consulta’, se continda oon at subflujo Consultar Estado (5-6) ‘Si la actividad seleccionada es “Servicios”, se continua oon el caso de uso Ofrever Servicios. ‘Si el usuario presiona “Sallir’, sale del sistema Las excepciones del case de uso son las siguientes: ‘Excepclones: | Ef informacién incompleta: falta benar Informacion indispensable, [a cludad de origen 0 de destino. Se le vuelve a pede al usuario la informacion, E:2 informacién invdliol: una. de las entradas de ta solicitud 65 incorrecta. HACER RESERVACION El case de use Hacer Reservacién se instancia a panir de la panualla de servi Gos (P-2), una vez se haya validado el usuario y seleccionado el botn. corres pondiente. E1 caso de uso. se deseribe a continuacién, excluyendo los subilujos y excep- ciones que se describen mas adelante. Caso deuso | Hacer Reservaciin Actores ‘Usuario, Base de Dalos de Reservaciones Tipo Basico, Propésito Permitr a un usuario hacer reservaciones con el sistema de reservaciones de vuello. Resumen El usuario inca este caso de uso. Clrece funcionalidad para ‘rear, obtener, modifcar y elminar reservaciones de vusios con el sistema de reservaciones. ‘Se debe haber ejecuiado anteriorments el caso de uso Walidar Ususario. ‘Se ejecuta ol caso de uso Validar Usuario. Dependiendo de las ‘opciones seleccionadas por ! usuario, 88 continuaré con los sdiversos subtlujos de este caso de uso. En la figura 6.27 se muestra el disefia de la pantalla para crear obtener una reservaciGn, si se cuenta con una clave, CAP, 6 — MODPLO, DE REQUISITOSFigura 6.27 Pantalta de insercién do Clave de reservaciones (P-14). El subflujo Solicitar Clavw Resertacién (5-1) se muestra a continuactén: ‘$1 Solicitar Clave Reservaciin, Se preeuntag) amenity ie panier coos ee Lea © usuario actividades: “Crear’ En la figura 6.28 se muestra el disefia de la pantalla para la solicitud de reser- vaciones de vuelos, utilizado por los distintos subflujos.. ACTORES Y CASOS DE USO PARA EL SISTEMA DE RESERVACIONES DE VUELOS Gapyrighted ieeeFigura 6.28 Pantalla Crear reservaciones de vuelos (P- 13). La figura 6.29 ilustra el diseio de la pantalla para el nécord o registro de reser- vaciones de Vuelos utilizado por los distintos subfujos, ‘Figura 6.29 Pantalla Récord de reservaciin de vuelos (P- 16). Cs 6 — OTIS ERR torialLos demds subflujas se muestran a continuaci’n ‘Subflujos (continuaeién) | $2 Crear Reservaciin. Se presenta la pantalla “Croar rasorvaciones” (P-12), la cual debe llenarse con el apeliio y nombre del pasajero, un nimero de viajero ‘tecuente opesonal, la. aerolinea, el ndmera de wielo, la ciudad de origen y da destino, la fecha, la clase, la asignaciée de asiento y si ‘desea ventana © pasilo. y opcionaimente comida vegstariana 0 carne. El ususrin pueds seleccionar entre las siguientes actividades: “Agregar, "+", "Reservar’, “Servicios” y "Saur. Si el usuario splecciona “Agregar, el sistema agrega una nueva pantalla “Grear reservaciones” (P-15) para ser llenad par el usuario, Si el usuario selecciona “+, el sistema avanza a la siguiente pantalla de resarvacion, Si el usuario selecciona ~", el sistema retrocede a la pantalla anterior de reserracién, | Si el usuario solecciona “Rasorvar’, el sistema acepta la solicitud (6-2, ED, envidndola a la base de datos del sistema de | reservaciones (E-5}; se continua con e1 subtlujo Administra Reservacion (S-4). | Si la actividad seleccionada es “Servicios”, se continua con al caso ‘de uso Ofrecer Servicios. Sia actividad seleccionada es “Sali, se sakdra del sistem S-3 Obtenar Reservacién El sistema obliene #1 récord de reservaciéin de la base de datos de | t09istro. Se. continua con el subtlujo Administrar Raservacion (S4) ‘$4 Administrar Reservacién. Se presenta la pantalla récord reservacién (P16) con la opcitin a modificar la informacion (E-1) El usuario puede seleccionar entre las siguientes opciones: “Eliminar', “actualizar’,"s*,*", ‘Nueva reservacién’, “Pagar, “Reembolsar,, “Servicios” y “Sali | Si él usuario presiona “Actualiza’’, se ejecuta el subflujo Actualizar | Reservacién ($5). Si el usuaro presiona “Eliminar’, se ejecuta e! subtiujo Elminar Reservacién (5-6) Si el usuario selecciona +", el sistema avanza a la siguiente pantalla de reservacion, Si el usuario solecciona ~", el sistema refrocede a la pantalla anterior de rosorvacién, Si el usuario selecciona “Nueva reservacién’, s8 continia con el subtlujo Crear Reservackin ($:2). Si el usuario selecciona *Pagar’, el sistema continda con el caso de uso Pagar Reservacion. SI el usuario splecciona "Reembolsar’, ol sistema continua con el caso de use Pagar Reservacién. Si ia actividad ssieccionada es “Servicios”, se continda con al caso de uso Ofrecer Servicios, Si la actividad seleccionada as "Salir, se sakird del sistema. (eontinda) 231| Subtlujos tcontinuacion) ‘$5 Actualizar Reservaciin. Se actualiza el récord de reservaciones (E-2, &3, E-4). Se continga con el subftujo Administrar Reservacion (S-3), $46 Eliminar reservacién. Se olimina el récord de reservacién (E-5). Se continua con el subfiujo- Crear Raservacién ($2) Las excepeiones del caso dee uso son las siguientes Excepciones. E+t Récord imallido: no existe el récord especificadio. E-2 Informacion incomplete: falta lenar informacion indispensable, la ciudad de origen © destina. Se le vuelve a. ‘pedir al usuario ia informacidn 9 Informacién invélida: una de las entradas de la solicitud es incorrecta, E-4 Reservacion sin éxita: no se logrd obtener una reservacisn, 5 Eliminacién reservacién sin éxito: no se logrd eliminar la reservaciin. PaGaR RESERVACION Fl caso de uso Pagar Reservacién se instancia a partir de ta pantalla Récord re- Servaiciones (P-16), una vex que sé ba seleccionado el botén comespondiente. ase dle uso se deseribe a ontinuackén, excluyenda los subflujas y exeep- clones que se deseriben mas adelante, Caso de uso | Pagar Reservacion Actores Usuario, Base de Datos de Reservaciones, Tipo Extensién, Propésite Permiir a un UsUaTO pagar reservaciones con ol sistema de reservaciones do, visio. Resumen EJ usuario inicla este caso de uso, Ofrece funcionaldad para agar y reembolsar pagos de reservaciones de vublos con él sistema de reservaciones mediante tarjetas de crécito registradas en el sistema. Precondiciones | Se requiere haber ejeculsdo anteriormente ol caso de uso Validar Usuario y tener ya Necha una reservaciin mediante et caso de uso Hacer Resarvaciin. Flujo principal ‘Se obtione ol registro de tarjeia ejecutando el caso de uso Registrar Tarjeta, eubflujo Obtener Registro Tarjets (5-2). ‘Sila Solicitud original fue pagar, $6 continiia con ef subliujo Pagar Rleservacidn (S-1), si tue reembolsar $6 continda con él subfujo Aleemboisar Pago (S-2). CAP. 6 — MODELO. DF REQUISITOSLa figura 6.30 ilusta el disehio de la partalla para el pago de reservaciones de vuelos, utilizando el subflujo Pagar Resernactin (S-1 (BBTEMIA CH RENESAS MELD Pena Page Res Te P17) toon [ Mirena rere es meee pee ene eis =f | ae] ein os Figura 6.30 Pantalia de Pago de reservaciones de vueios (F- 17), El subllujo Pagar Reservacion (S-) se muestra a continuacién: Subflujos | $-1 Pagar Reseracién. ‘So prosenia al usuario la pantalla "Pagar registro tarjeta” (P-17), la cual incluye Informacion sobre el nombre tal como aparece e tarjeta, ol niimoro de tarjeta, el tipo de tarjeta, la fecha de vencimionta y la cantidad a pagar (E-1), El usuario podra seleccionar entre las siguiertes actividades: “Pagar, “Servicios” y “Sali” ‘Sila actividad seleccionada es “Pager’, el sistema utiliza ios datos de Ia tarjeta registrada por el usuario y le envia una pantalla de confirmacion (E-2). Se continua con el caso de uso Hacer Reservacién, subfujo Solicitar Clave Aasarvaciin (S- 1). Si la actividad seleccionadta es “Servicios”, se continua con el caso te uso Ofrecer Servicios. Si la actividad seteccionada es “Sali”, se sale del sistema. En la figura 6.31 se muestra el disefio de [a pantalla para el pago de reserva- ciones de vuelos, utilizanda ef subflujo Reembotsar Pago (8-2) ACTORES Y CASOS DE USO PARA FL SISTEMA DE RESERVACIONES DE VUELOS 233.Pana teers agar Tan — FSS Serer eon eres stn en =f pee | eee | see Figura 6.31 Pantalla de Reembolso de reservaciones de vusios (P-18). El subflujo Reembolsar Pago (S-2) se muestra a continuaciGn: ‘Subflujes | $2 Reembolsar Pago. (continuacién) | Se presenta al usuario la pantalla “Reembolsar registro tarjeta” (P-18), la cual incluye informaciin del nombre tal como aparece en la tarjeta, el nimero de tarjeta, el tipo de tarjeta, la fecha de vvencimiento y la cantidad a reembolsar (P-1). El usuario podrd seleccionar entre las siguientes actividades: “Reemboisar, “Servicios” y “Sali. Si la actividad seleccionada 6s “Reembolsar’, el sistema utiliza los datos de la tarjeta registrada por ol usuario y envia una pantalla de canfirmacién al usuario (E-3, E-4). Se continia con el caso de uso Hacer Reservacién, Subfiuja Solictar Glave Reservacién (S-1), Sila actividad seleccionata es “Servicios”, se continia con el caso 0 uso Ofrecer Servicies. Sila actividad seieccionada es “Salir, se sale del sistema. Las excepeiones del eas de uso son las siguientes Excepctones | E-1 Récord invaiido: no existe el récord especificada. El usuario deberd insertar los datos de Ia tarjeta, E-2 Pago invéiide: @! pago no tuvo éxito o Ia informacién de pago est incompleta E-3 Pago inexistente: la reservacion ain no ha sido pagada. E-4 Reombolso inviiido: no. 86 puddo hacer @l reembolso del pago. CAP. 6 — MODELO_DE REQUISITOS6.5 Modelo del dominio del problema FE] modelo del dominio del problema define un modelo de clases comin para todos Ios involucrados en el modelo de requisitos, tanto an: clientes. Este modelo de clases consiste en los objetos del dominio del proble- objetos que tienen una correspondencia directa en el sirea de la apli- eacién, Como los usuarios y dientes dehen reconacer todas los conceptos, se puede desarrollar una terminologia comin al razonar sobre los casos de uso: y por lo tanto, disminuir la probubilidad de malos entendidos entre el analista y el usuario, Al discutito, se evolucianari el madelo- del daminio del problema, Una técnica utilizada cuando se trabaja con tal modelo, es darle al cliente un Papel y un lipiz, y pedisle « ibuje su vision del sistema. Histéricamente, el modelo del dominio del problema se utilizaba como el mo: delo fundamental para la especificaciin de requis dologias de ingenieria de safeware orientadk a abjetos de primera generacién (ver capitulo 3), Sin embargo, dadas ws limitaciones que impedian obtener los requisitos funcionales de un sistema, el moxieko del dominio del problema dej6. de ser la base nica part el desarrollo completo del sistema y paso a ser un elemento adicional en kt especificacion de éste, como en el modelo de cisos de uso. EI propdsito principal del dominio del problema en el modelo de re- quisitos de nuesta metodologia es formar wow base comin de entendimiento del desarrollo y no definir el sistema completo. Por tanto, se pueden aprave- char algunas heuristicas de los métodos anteriores para identificar fos objetos en ef dominio del problema, con lo que se lograri un glosario 0 diccionario de clases que sirva como comtin denominader a todas las componentes del sistema, inclayendo a las personas inwolucradas a lo largo del desirratio. & di: ferencia de los métedos anteriores, el modelo del dominio del problema no debe: ser demasiado extenso, ya que s¢ realizarin varios grados de refinamien: to después, Y aunque es suficiente deseribir el dominia del problema en térmi- nos dé objetos o clases, ¢ posible refinar todavia mis mediante la inclusion de asociaciones, atribures, herencia y operaciones, siempre y cuando esto ayuce a comprender mejar el problema, y que no se vuelva un esfuerzo demasiado gran de durante esta etapa. Se debe tener cuklads con hacer demasiado trabajo al 0, va que esto puede dificultar su modificicion posterior durante el mode- Jo de analisis. La experiencia muestra que muchos, si ne todos, de los abjetos del dominio padein aparecer durante éste, Sin embaggo, pueden haber cambios durante éxte, incluyendo la eliminacién de clases identificadas en este etapa, o incluso, la incorporacién de clases adicionales. sen muchas de Jax meto- En esta secci’in describiremos mo identifica las clases del dominio del pro- blema junta con aspectos adicionales, como asoviaciones y atributos, Lo que definiivamente no se hard aqui, y que era parte esencial de las metodolegias anteriores, es identificar la herencia y las opera La her cia y, en especial, las Openiciones de un sistema son los aspectos de mayor complejidad, algo que nosotres elaboraremos de manera muy cuidadosa churari- te el dise”io del sistema, 6.5.1 identificacion de clases La identificactén de clases de| dominio del problema, se obtiene principale mente de alin documemto textual que describa el sistema, Aunque se pudie- MODELO DEL DOMINIO: BEL PROBLEMA 235fa tomar como punto de partida los documentos desarollados. part el modelo de casos de uso, a menudo la deseripeiGn original del problema es suficiente. Se comienza este proceso a partir de la klentificacion de las clases candidatas, explicitas o implicias, a las que se refiera tx descripcién del problema, Para ¢llo, se extraen todas las sustantivos de la deseripeién del problema © de algin otro documento similar. de acuerdo con las siguientes consideraciones: D> Las sustantivas en la descripcién del problema son los posibles candidatos a clases de objetos. Por ejemplo en “un sistema de reservaciones que vende boletos para funciones a varios teatros”, las clases candidatas. serian, siste- ma de reservactones, boletos, funcién y teatro, Se deben identificar las entidades fisicas al igual que las conceptuales No se debe tratar de diferenciar entre las clases y los atributos Dado que no todas las clases se describen de manera explicita, siendo al- _gunas implicitas en fa aplicackin, seri necesario: afadir clases que puedan ser identificadas por nuestro. conocimiento del dre. D> Se deben revisar lox pronombres en La descripcién del problema, para ase- gurar que no se haya perdido ningdn sustantivo descrito de forma impli- cit. > Para facilitar la identificacién de clases, se subrayan todos los sustantivos de la descripcién del problema, vvyY En el caso del sistema de reservaciones de vuelos, partimos de la descrip- idm del problema y subrayamos todos los sustantivos, con sus complementos adietivos, como se ve a continuacién: El Sistema de reservaciones ce vuclos es un sistema que pemmite al usuario hacer consultas y neservaciones de vuelos, ademas de pader comprar los boletos aéreos en forma remota, sin ta necesidad de recurrir a un agente de viajes. Se desea que el sisicma de rescrvaciones sca accesible a través de Internet (World Wide Weel). Fl sistema presenta en su pantalla pringipal un mensaje de bicnvenicta que deserite los servicios ofrecidos junta con la opeidn para registrarse por primera ver, o si ya se esté registrado, poder utilizar el sistema de cescrmaciones de vuckos. Este aeceso se da por medio de la insercicn de un agit previamente es- pecificado y un passiwand previamente escogide y que debe validarse. Una vez registrado e] usuario, y después de haberse validado el regisiro y | contraseha del usuario, se pueden seleccionar de las. siguientes (continua) CAP, 6 — MODELO. DE. REQUISITOS(continuaciin) La consulta de vurlos se puede hacer de tes maneras diferentes Honarios de vuelos Tarifas de vuelos Estado cle uwelo La consulta sean horario muestra Jos horarios de las diferentes acrolineas que dan seevicio entre dos siudades. La consulta septin tarifzs muestra los diferentes yuelos entre dando prioridad a su costo. 8 Cidicltehess La informacién de vielg se utiliza principalmente para coasultar el estado de algiin wuicko, incluyendo informacién «le disponibilidad de asicnies ¥, en el caso de un yuelo para el mismo dig. si el vuelo esti a tiempo. Se puede incluir preferencias en las busquedas, como fecha y horanio Todas las clases deben tener sentide en el drea de la aplicacién, Ia relevan- cia del problema debe ser el tinico eriterio para Ia seleccién, > Como regia general, se deben escoger los nombres de las clases com cui dado, que no sean ambiguos y que mejor describan el problema. Este es uno de Ios procesas mas dificiles. Los nombres deben establecerse con un formato consistente (e.g., nombres en singular). (> Duninte esta clapa, no hay que preocuparse por la asociackin, agregaciéin ‘o herencia, Primero hay que tener las clases especificas cormectas para no suprimir detalles en el intento de ajustarse a estructuras preconcebidas D> Ante 1a duda, se cleben conservar las clases, ya que posteriormente siem- pre habe oportunidad de climinarlas J Eliminar clases recundantes, si expresan la misma informacién. La clase mis descriptiva debe ser guardada. D> Eliminar clases imelevantes, que tienen poco o nada que ver con el proble- mma, Esto requiere de juicio, porque en un contexto, una clase puede ser importante, mientras que en otro, la clase podria no serlo, Im Se deben clarificar las clases imprecisas. Algunas pueden tener bordes mal definidos © demasiade generates. CAP, 6 — MODEL. DE REQUISITOS> 's necesario climinar fas clases que debicran ser atributos mis que clases, cuando Jos nombres comesponden a propiedades mas que a entidades in. dependientes. D> Eliminar las clases que debieran ser roles mis que clases, cuando los nom- bres correspanden a la funcidn que tienen las clases mis que a las entida- des independientes D> Suprionir fas clases que debieran ser operaciones mis que clases, si las en idades sepresentan opericiones que se aplican a los objetos y no a enti dades manipuladas par si nsismas D> Hay que climinar def anilisis las cases que corresponden 4 consmucciones de implementacion, si estin alejadas del mundo real. No se necesita una clase para representar una enuidad fisiea, Por ejemplo: subratinas, Histas y arregias, son clases tipicas de implementacién; Internet y World Wide Web son cl medio de implementacién del sistema. > Se-deben eliminar clases que correspondain a aspectas ce interfaces che usua- no y no de fa aplicactén, Se deben eliminar clases que correspondan. a todo un sistema completo: b Suprimir clases que correspondan a actores del sistema. D> Se deben agregar clases implicitas que no aparezcan en la descripeidn de! problema Se tomarin algunas clases candidatas del sistema de reservaciones de vuelo identificadas anteriormente y s¢ seleccionarin las que mejor se apliquen a nues tro problema, como se ve a confinuacién: D> Clases redundantes: CHeme y Usuario, ambos témminas pueden ser equiva lentes, pero en el caso del sistema de te: consideramas que Ustario es mis descriptive por ser la persona que utiliza cl sistema, Pm Clases irrelevantes: Mostrador def Aeropuerto, Agente de Viajes y Boleto Aéreo. Si el sistema generart © se refiriera a un boleto aéren, esta clase se mantendria, D> Clases. impreciss: Sistema, Servicios, Actividad, Proferencia, Biisqueda, In- Jformactin, Estado, Dispenibilidad, Opcién, Acceso ¢ Itineraric som clases imprecisas, Durante la introduceién de herencia puede que sea necesirio tink clase para compartir aspectos comunes a ambas clases. > Nombres de clases: Aeropuerto cn lugar de Citedad. b> Clases que son atributos: Nimero de iarjeta de crédito es un atributo de Turjeta cle erédito, Categoria de asiente (Asiento), Informacién de vueks (Vuelo) y Horaria de vuelo (Vuelo). Ises que son operaciones: Constite, Pago y Reservaciones. s de interfaces de usuario: Mensaje de Blenventda y Pantalla Prin- srvaciones. eipat. Be Clases del sistema completo: Sistema der Resernaciones D> Clases de actores: Clie te. La tabla 6.2 muestra Las: modific jones a las clases candidatas originales MODELO DEL DOMINIO DEL PROBLEMA 239240 5 candidstas: ‘Sistema do reservaciones de vuole Sistema Usuario Coneuka Reserva Vuelo Boleto aére0 Agente de viajes ‘Sistema de reservaciones lateret World Wide Web Hoja principal Mensaje de bionvenida Servicios Registro Actividad ‘Consulta de vuelos Reservacién de vuelos Pago de boletos: Horatio de vuelos ‘Tarifa de vuelos lnformacién de vuelto Horario Aerolineas Cudad Moditicecion Eliminada (sistema completa) Eliminada (imprecisa) Eminada (actor) Eliminada (operacién} Etmminada (operacién) Exminads (relevante) Etiminada (retovante) Eliminada (sistema completo) Eliminada (implementacién) Eliminada (amplementacion} Eliminada (intertace) Eliminada (intertace) Ellminada (improcisa) Eliminada (imprecisa) Renombrada: Reservacién Eliminada (imprecisa) Eliminada (stributo) Eliminada (stributo) Ekeminada. (atributo) Rlenombcada: RegistroUsuario Eliminad (imprecisa) Etiminads (operacién) Eliminada (operacién) | Eliinada (operacién) Eliminada (dupllcada con horario) Eliminada (duplicada con tarifa} Eliminada (stributo) Rlenombrada: Aeropuerto : (continda) CAP. 4 — MODEEO DE RFOUISITOS.Torita Costo Eliminada (redundante) Estado Eliminada (imprecisa) Disponibaidad Eliminada (imprecisa) Iinformacién ‘Eliminada (imprecisa) Asiento Dia Eliminada (atributa) Hora ‘Eliminada (atributo) Preterencia ‘Ellminada (imprecisay Bosqueda Elminada (operacton) Facha Eliminada (atributo) ‘Categoria de asiento Eliminada (atributo} ‘Vuelo directo Eliminada (atributo) ‘Clionte Eliminada (redundante y actor) Itinerario Eliminada (imprecisa) Pasajero ‘Compra Eliminada (operacion) Tarjeta de: crédito Renombrada: RegistroTarjeta Boleto Eliminada (inelevante) Mostradlor del aeropuerto Eliminada (inelavante) Numero de tarjeta de crédito Etiminada (atribute) Las clases idemtificadas se muestran en la tabla 6.3, Note que se agregan dos nuevas clases: Aviin y ViajeroFrecnente, que no aparecian en la deseripeién del problema. Esto se hizo para lagrar un dominio mas completa. En general, dis- tintos analistas ientificarin listas similares de clases, aunque siempre con algu- na. variacién. Horario FlogistroTarjeta Aerolineas ‘Avion ‘Aeropuerto ViajoroFrecuente MODFLO DEL DOMINIO DEL PROBLEMA 241242 DIAGRAMA DE CLASES Después de identificar y seleccionar las clases, se debe construir el diagrama de clases para el dominio del problema. Este diagrama se muestra en la figu- ra 632 y puede ayudar a identificar clases adicionales, ademis serviri de base para encontrar las atributos y asaciaciones entre ellas. ‘hin Tarte epuare | S| = = Figura 6.32 Diagrama de clases identificadas para el sistema ‘de reservaciones de vuelo, Aunque se puede parar aqui el proceso de desarrotlo del dominio. del proble- ma, continuaremos Con la identificaciéh de asociaciones y atributos para el sis tema de reservaciones de yuelo. 6.5.2 identificacién de asociaciones El proceso de identificacion de asoclaciones 5 bastante similar al de identi Reeacidn de clases, s6lo que en lugar de stistantivos buseamos frases qe rela cionen a fos sustantivos de clases ya identificadas, En general, este proceso ya no es necesario como parte del modelo de casos de use, dade que las asacia ciones y operaciones del sistema serin identificadas durante el modelo de li sefo. Sin embargo, aqui se dari un pequeno ejemplo de la Wenlificacién de asociaciones con base en nuestro conocimiento del skominio del problema. (En cierta manera, se escogié come ejemplo el desarrollo de un sistema de vaciones de vuelos, por ser un dominio con el cual ke mayoria de pueden identificarse.) ser 8 lectores car. 6 — Mong 2, DE REQUISITOSDIAGAAMA DE CLASES CON ASOCIACIONES En lugar de partie de la descripcién del problema o tos documentos de casos de uso, simplemente identificamos nuestras propias frases correspondientes al dominio de! problema del sistema de reservaciones, como se observa en la tabla 444, Este proceso de identificacion es sencilla cuando el problema es muy limi tado y el dominio es ficil de analizar, De lo contrario, se requiere un proceso: de identificacién mucho mis extensa, como veremos en ka etapa de diseno, Un vuelo requiere reservaciones. Un wuelo se dirige @ un aeropverto. Un vuelo contiane tarifas, Un vuelo se efectia en un avién, } Un vueio tiene asientos. Un vuelo pertenece una asrolinea. Un vueio tiene un horario. Un pasajero puede acumular millas coma viajero trecuente. Un pasajera efectua reservaciones. Una reservaciGn requiere de un registro de tarjeta de crédito. Un registro de tarjeta pertenéce a un registro de usuario. Después de haber identificado las asociaciones, se debe construir una versién del diagrama de clases que incluya estas asociaciones, como se muestra en la figura 6.33. Figura 6.33 Diagrama de clases con asociaciones entre clases identificadas, Se omiten las nombres de las asociaciones. MODELO DEL DOMINIO DEL PROBLEMAIAGRAMA DE CLASES CON ROLES Después de fiber hecho el diagrama de clases eon asaciaciones, se puede cons nuit una versiGn del diagrama de clases incluyendo roles. Como se explicé en et capitulo 4, el nombre del rol describe la funcién que desempefard una clase en Ia asociacién desde él punto de vista de la otra clase. Si hay una sola aso- ciackin entre un par de clases, ¥ el nombre de la clase describe ackecuadamen- te su rol, se pueden omitir los nombres def mismo. Para tal propésite, modificamos Jevemente las asociaciones identificadas ante- riormente, como se muestran en la tabla 6,5, Un vuelo puede hacer escalas en attos aeropuertos. Un vuelo: contiene taritas de ida y vuelta. Se extiende el diagrama de clases con asociaciones para inchiir roles, como se muestra en ta figura 6.34 DIAGRAMA DE CLASES CON MULTIPLICIDAD Después de haber hecho Vuelo: se denomina por medio de un niimero, El vuelo tiene come origen Jun aeropuerto en una ciudad y tiene como desting un aeropuerto de otra dudad, Un vuelo puede tener miltiples escalas, y diversos vuelos se rela- cionan por medio de conexiones El vuelo pertenece a una aerolinea y puede operar varios dias a la semana, con un horirio de salida y otro de Negada. D> Reservacién: para poder tomar un vuelo, es necesario contar con una re servacidn previa, la cual debe pagarse antes de una fecha limite, incluscr el mismo dia del vuelo. Una reservacién puede hacerse para multiples vuetos y dlistintos pasajeros. La reservaci6n cuenta con una clave que coresponde aun récord de reservacion particular. p> RegistroUsuario: pars pocer utilizar el sistema de reservaciones, el usta- ‘no debe estar registrado en él, El registro. contiene informacion acerca del “usuario como nombre, direceién, colonia, ciudad, pais, cédigo- postal, tele- fono de cast, teléfono de oficina, fax, email, /ogin y password. MODELO DEL DOMINIO DEL PROBLEMA248 Figura 6.38 Diagrama de clases con asociaciones, roles, multipbeidad y atributos ara clases Identificadas. Se omiten los nombres: de las asociaciones y sélo se rmuestran los atributos mas. relevantes vrvy Horario: el horario de un yuelo se determina por su hora de said y de egada durante los dias que opera Aefolinea: la acrolinea provee varios vuclas entre diferentes ciudades bajo diversos horarios, La aerolinea se identifica por un nombre. Aeropuerto: el aeropuerto sirve como erigen, destino y escalas de un vuele, El aeropuerto se encuentra en una ciudad de un pais determinado, Tarifa: un mismo vuelo puede contar con diferentes tarifas, que varian se- _ptin la clase de boleto, si son de viaje sencillo o viaje redondo, y depen- diendo de las restricciones y ofertas existentes, CAP. 6 — MODELO.DE REQUISITOSD> Asiento: una reservacidn de vuelo puede inchuir la asignaciéin de asiento, especificada mediante una fila y un numero, El nikmero de asientos dispo- nibles en un vuelo dependen del tipo de avidin que opere ese dia B Pasajero: para hacer una reservaciOn, se requicie dar ef nombre del past- jero. Varios pasajeros pueden aparecer bajo una sola reservacién, D> RegistroTarjeta: para pagar con una tarjeta de crédito, se debe tener un registro de tarjeta. El registro contiene informacién acerca de la tare cluyendo nombre, mimero, expedidor y vencimiento. La tarjeta esti ligada aun registra de usuario. B AVI6A: uh Vuelo en una fecha determinada se hace en un tipo de avidn en particular. El tipo de avién define la cantidad mixima de pasajeros que pue- den viajar en ese vuelo para esa fecha b ViajeroFrecuente: el pasajero tiene la opcién de acumular millas para un vuelo, si cuenta con una tarjeta de viajero frecuente de la aerolinea corres: pondiente. 6.5.5 Identificacién de Médulos Fl modelo del dominio del problema, puede hacere bastante complejo en el caso de un sistema de gran tamaio, para lo cual es necesario separar las cla- ses en médulos, De tal manera, ef medelo completa se dividiria en una colec- cién de médulos, donde cada meéulo es una agrupacidn ligica de clases y sus jones comespondientes, Para el sistema de reservaciones de vuelo, se pueden identificar dos médulos principales cel dominio. del problema, de acuer- do con Ia relacién ldgica entre las clases. Estos médulo son, Registra, que conti ne las clases que guardan informacién sobre el usuario del sistema; que contiene fas clases que guardan informacién sobre los vuelos, pasajeras y reservaciones, En otras palabras, las clases para el médulo de registro se rela- conan con la utilizacion del sistema ligadas al actor Base de Datas de Regtstro, mientras. que las clases para el médlulo de servicios se relacionan con el pro: pio sistema de reservaciones, ligadas al actor Base de Datos de Reservaciones La razdn de separar en dos médulos, va may de la mano con la existencia de estos dos actores secundarias, ya que al comesponder cada actor sccundatio a Una hase de datos, los médulos afianzan esta correspondencia. Sin embargo, esto no tiene por qué ser realmente asi, pudiendo existir un solo médulo para un sistema con miltiples actores secundarios, o incluso varios médulos por cada actor secundario. A continuacién describimos los médulos para el sistema de reservaciones de vuelo, Servicios En Ia figura 6.37 sc muestran Ins clases pertenecientes al médule de Servicios del sistema de reservaciones, 249250 Fis Lata ‘Reralines Aarsiinas . Figura 6.37 Diagrama de clases para al médulo de Servicios del sistema de teservaciones de. vuslo, RecistRo En la figura 6,38 se muestra las clases pertenecientes al médulo de Registro del sistema de reservaciones, egewaUsuana Nomnnee Direccion Coli ‘Ciudad Pals | céaige Postal Teléfono case ‘Taster ofcina | Fax | Ema Login Prasward Figura 6.38 Diagrama de clates para el médulo de Registra del sistema de reservaciones de vuelo,Resumen En este capitulo se inicia ta desenpcitin de la metodologia de desarratie de soft ware asada en casos de uso, En particu se deserihe el modelo de sequisi- tos. Se introduce el sistema de reservaciones de vueles, el cual sive de ejem plo de la aplicacion de la metodologia a Io largo del libre, Se describe el motlelo de casos de uso, que consiste en actores y casos de uso, como base para la cspecificacién funcional de un sistema. Se kdentifican y describen los ac- ores y casos de uso mais importantes para ¢l sistema de reservaciones de vue las, Se explican tos modelos de imerfaces y del dominio del problema de los auiles se obtienen especificaciones adicionales; entre ellos se destaca la impor lancia de un modelo de requisitos que separa los tres aspectos anteriores, REFERENCIAS 1. Jacobaon, 1, Chriemen, Mt, Jonstoe, B., Guersand, G., “Object Oviented Soitware Engeneering, A Use Case Driven Approsth, Adkison Weskey, 1902, bap ‘ewe rakonal com ‘ore aabre.com saw gales con spr worden com saw aad cee ‘arms tavelacty cm www espe RUPERENCIAS 251Copyrighted material