2. 470 Captulo 12 Caso de estudio del ATM, Parte 1: Diseoorientado a objetos con UML 12.1 Introduccin al caso de estudio12.2 Anlisis del documento de requerimientos 12.3 Identicacin delas clases en un documento de requerimientos 12.4 Identicacin delos atributos de las clases 12.5 Cmo identicar los estados yactividades de los objetos 12.6 Identicacin de las operaciones delas clases 12.7 Indicar la colaboracin entre los objetos 12.8Conclusin Respuestas a los ejercicios de autoevaluacin 12.1Introduccin al caso de estudio Ahora empezaremos la parte opcionalde nuestro caso de estudio de diseo e implementacin orientados aobjetos. En este captulo y en el 13, disear e implementar unsistema de software de cajero automtico (ATM) orientado a objetos.Este caso de estudio le brindar una experiencia de diseo eimplementacin concisa, cuidadosamente pautada y completa. En lassecciones 12.2 a 12.7 y 13.2 a 13.3, llevaremos a cabo los diversospasos de un proceso de diseo orientado a objetos (DOO) utilizandoUML, mientras relacio- namos estos pasos con los conceptosorientados a objetos que se describieron en los captulos 2 a 10. Eneste captulo trabajar con seis tipos populares de diagramas de UMLpara representar el diseo en forma grfica, y en el siguiente(captulo 13) optimizar el diseo con la herencia, y despus realizaruna imple- mentacin completa del ATM, en una aplicacin Java de 673lneas (seccin 13.4). ste no es un ejercicio sino una experiencia deaprendizaje de extremo a extremo que concluye con un anlisisdetallado del cdigo en Java que implementamos con base en nuestrodiseo. Este caso de estudio le ayudar a acostumbrarse a los tiposde problemas sustanciales que se encuentran en la industria. Estoscaptulos se pueden estudiar como una unidad continua despus de quehaya completado la introduccin a la programacin orientada a objetosen los captulos 8 a 11. O tambin puede ir viendo las secciones, unaa la vez, despus de los captulos 2 a 8 y 10. Cada seccin del casode estudio comienza con una observacin que le indica el captulodespus del cual se puede cubrir. 12.2 Anlisis del documento derequerimientos [Nota: esta seccin se puede estudiar despus delcaptulo 2]. Empezaremos nuestro proceso de diseo con la presentacinde un documento de requerimientos, el cual especifica el propsitodel sistema ATM y qu debe hacer. A lo largo del caso de estudio,nos re- feriremos a este documento de requerimientos. Documento derequerimientos Un banco local pretende instalar una nueva mquina decajero automtico (ATM), para permitir a los usuarios (es decir, losclientes del banco) realizar transacciones financieras bsicas(figura 12.1). Cada usuario slo puede tener una cuenta en el banco.Los usuarios del ATM deben poder ver el saldo de su cuenta, retirarefectivo (es decir, sacar dinero de una cuenta) y depositar fondos(es decir, meter dinero en una cuenta). La interfaz de usuario delcajero automtico contiene los siguientes componentes: una pantallaque muestra mensajes al usuario un teclado que recibe datosnumricos de entrada del usuario un dispensador de efectivo quedispensa efectivo al usuario, y una ranura de depsito que recibesobres para depsitos del usuario. 3. 12.2 Anlisis del documento derequerimientos 471 El dispensador de efectivo comienza cada dacargado con 500 billetes de $20. [Nota: debido al alcance limitadode este caso de estudio, ciertos elementos del ATM que se describenaqu no imitan exactamen- te a los de un ATM real. Por ejemplo,comnmente un ATM contiene un dispositivo que lee el nmero de cuentadel usuario de una tarjeta para ATM, mientras que el ATM de nuestrocaso de estudio pide al usuario que escriba su nmero de cuenta. UnATM real tambin imprime por lo general un recibo al final de unasesin, pero toda la salida de este ATM aparece en la pantalla].Fig. 12.1 Interfaz de usuario del cajero automtico. Bienvenido!Escriba su numero de cuenta: 12345 Escriba su NIP: 54321 Inserteaqu el sobre de depsitoInserte aqu el sobre de depsitoInserte aquel sobre de depsito Tome aqu el efectivoTome aqu el efectivoTomeaqu el efectivo Teclado Pantalla Ranura de depsito Dispensador deefectivo Problema de seguridad: el NIP no se muestra como textosimple en un ATM real El banco desea que usted desarrolle softwarepara realizar las transacciones financieras que inicien losclientes a travs del ATM. Ms tarde, el banco integrar el softwarecon el hardware del ATM. El software debe encapsular lafuncionalidad de los dispositivos de hardware (por ejemplo:dispensador de efectivo, ranura para depsito) dentro de loscomponentes de software, pero no necesita estar in- volucrado en lamanera en que estos dispositivos ejecutan su tarea. El hardware delATM no se ha desa- rrollado an, por lo que en vez de que ustedescriba un software para ejecutarse en el ATM, deber desarrollaruna primera versin del software para que se ejecute en unacomputadora personal. Esta versin debe utilizar el monitor de lacomputadora para simular la pantalla del ATM y el teclado de lacomputadora para simular el teclado numrico del ATM. Una sesin conel ATM consiste en la autenticacin de un usuario (es decir,proporcionar la identidad del usuario) con base en un nmero decuenta y un nmero de identificacin personal (NIP), seguida de lacreacin y la ejecucin de transacciones financieras. Para autenticarun usuario y realizar transacciones, el ATM debe interactuar con labase de datos de informacin sobre las cuen- tas del banco [esdecir, una coleccin organizada de datos almacenados en unacomputadora; en el captulo 28 (en ingls) estudiaremos el acceso abases de datos]. Para cada cuenta de banco, la base de datosalmacena un nmero de cuenta, un NIP y un saldo que indica lacantidad de dinero en la cuenta. [Nota: asumiremos que el bancoplanea construir slo un ATM, por lo que no necesitamos preocuparnosde que varios ATM puedan acceder a esta base de datos al mismotiempo. Lo que es ms, vamos a suponer que el banco no realizarmodificaciones en la informacin que hay en la base de datosmientras un usuario accede al ATM. Adems, cualquier sistemacomercial como un 4. 472 Captulo 12 Caso de estudio del ATM, Parte1: Diseo orientado a objetos con UML ATM se topa con cuestionescomplejas y desafiantes de seguridad, las cuales van ms all delalcance de un curso de programacin de primer o segundo semestre. Noobstante, para simplificar nuestro ejemplo supondremos que el bancoconfa en el ATM para que acceda a la informacin en la base de datosy la manipule sin necesidad de medidas de seguridad considerables].Al acercarse al ATM por primera vez (suponiendo que nadie lo estutilizando), el usuario deber experimentar la siguiente secuenciade eventos (vea la figura 12.1): 1. La pantalla muestra el mensajeBienvenido! y pide al usuario que introduzca un nmero de cuenta. 2.El usuario introduce un nmero de cuenta de cinco dgitos, medianteel teclado. 3. En la pantalla aparece un mensaje, en el que se pideal usuario que introduzca su NIP (nmero de identificacin personal)asociado con el nmero de cuenta especificado. 4. El usuariointroduce un NIP de cinco dgitos mediante el teclado numrico.1 5.Si el usuario introduce un nmero de cuenta vlido y el NIP correctopara esa cuenta, la pan- talla muestra el men principal (figura12.2. Si el usuario introduce un nmero de cuenta invlido o un NIPincorrecto, la pantalla muestra un mensaje apropiado y despus elATM regresa al paso 1 para reiniciar el proceso de autenticacin.Fig. 12.2 Men principal del ATM. Menu principal 1 - Ver mi saldo 2- Retirar efectivo 3 - Depositar fondos 4 - Salir Escriba unaopcion: Inserte aqu el sobre de depsitoInserte aqu el sobre dedepsitoInserte aqu el sobre de depsito Tome aqu el efectivoTome aquel efectivoTome aqu el efectivo 1 En este ATM simple, de lnea decomandos y basado en texto, a medida que escribe el NIP, steaparece en la pantalla. Sin duda sta es una fuga de seguridad; noes conveniente que alguien est detrs de usted en un ATM, viendo queaparece su NIP en la pantalla. En el captulo 14 introduciremos elcomponente de GUI JPasswordField, el cual muestra asteriscos amedida que el usuario escribe; este componente es ms apropiado paraingresar nmeros de NIP y contraseas. El ejercicio 14.18 le pedirque cree una versin basada en GUI del ATM, y que use un objetoJPasswordField para obtener el NIP del usuario. Una vez que el ATMautentica al usuario, el men principal (figura 12.2) debe conteneruna opcin numerada para cada uno de los tres tipos detransacciones: solicitud de saldo (opcin 1), retiro (opcin 2) 5.12.2 Anlisis del documento de requerimientos 473 y depsito (opcin3). El men principal tambin debe contener una opcin para que elusuario pueda salir del sistema (opcin 4). Despus el usuario elegirsi desea realizar una transaccin (oprimiendo 1, 2 o 3) o salir delsistema (oprimiendo 4). Si el usuario oprime 1 para solicitar susaldo, la pantalla mostrar el saldo de esa cuenta bancaria. Paraello, el ATM deber obtener el saldo de la base de datos del banco.Los siguientes pasos describen las acciones que ocurren cuando elusuario elige la opcin 2 para hacer un retiro: 1. La pantallamuestra un men (vea la figura 12.3) que contiene montos de retiroestndar: $20 (opcin 1), $40 (opcin 2), $60 (opcin 3), $100 (opcin4) y $200 (opcin 5). El men tambin contiene una opcin que permiteal usuario cancelar la transaccin (opcin 6). Fig. 12.3 Men deretiro del ATM. Inserte aqu el sobre de depsitoInserte aqu el sobrede depsitoInserte aqu el sobre de depsito Tome aqu el efectivoTomeaqu el efectivoTome aqu el efectivo Menu de retiro 1 - $20 4 - $1002 - $40 5 - $200 3 - $60 6 - Cancelar transaccion Elija un monto deretiro: 2. El usuario introduce la seleccin del men mediante elteclado numrico. 3. Si el monto a retirar elegido es mayor que elsaldo de la cuenta del usuario, la pantalla mues- tra un mensajeindicando esta situacin y pide al usuario que seleccione un montoms pe- queo. Entonces el ATM regresa al paso 1. Si el monto aretirar elegido es menor o igual que el saldo de la cuenta delusuario (es decir, un monto de retiro aceptable), el ATM procede alpaso 4. Si el usuario opta por cancelar la transaccin (opcin 6), elATM muestra el men principal y espera la entrada del usuario. 4. Siel dispensador contiene suficiente efectivo para satisfacer lasolicitud, el ATM procede al paso 5. En caso contrario, la pantallamuestra un mensaje indicando el problema y pide al usua- rio queseleccione un monto de retiro ms pequeo. Despus el ATM regresa alpaso 1. 5. El ATM carga el monto de retiro al saldo de la cuentadel usuario en la base de datos del banco (es decir, resta el montode retiro al saldo de la cuenta del usuario). 6. El dispensador deefectivo entrega el monto deseado de dinero al usuario. 6. 474Captulo 12 Caso de estudio del ATM, Parte 1: Diseo orientado aobjetos con UML 7. La pantalla muestra un mensaje para recordar alusuario que tome el dinero. Los siguientes pasos describen lasacciones que ocurren cuando el usuario elige la opcin 3 (par-tiendo del men principal de la figura 12.2) para hacer un depsito:1. La pantalla muestra un mensaje que pide al usuario queintroduzca un monto de depsito o que escriba 0 (cero) para cancelarla transaccin. 2. El usuario introduce un monto de depsito o 0mediante el teclado numrico. [Nota: el tecla- do no contiene unpunto decimal o signo de dlares, por lo que el usuario no puedeescribir una cantidad real en dlares (por ejemplo, $27.25), sinoque debe escribir un monto de dep- sito en forma de nmero decentavos (por ejemplo, 2725). Despus, el ATM divide este nmeroentre 100 para obtener un nmero que represente un monto en dlares(por ejemplo, 2725 100 = 27.25)]. 3. Si el usuario especifica unmonto a depositar, el ATM procede al paso 4. Si elije cancelar latran- saccin (escribiendo 0), el ATM muestra el men principal yespera la entrada del usuario. 4. La pantalla muestra un mensajeindicando al usuario que introduzca un sobre de depsito en laranura para depsitos. 5. Si la ranura de depsitos recibe un sobredentro de un plazo de tiempo no mayor a dos minutos, el ATM abonael monto del depsito al saldo de la cuenta del usuario en la basede datos del banco (es decir, suma el monto del depsito al saldo dela cuenta del usuario). [Nota: este dine- ro no est disponible deinmediato para retirarse. El banco debe primero verificarfsicamente el monto de efectivo en el sobre de depsito, y cualquiercheque que ste contenga debe vali- darse (es decir, el dinero debetransferirse de la cuenta del emisor del cheque a la cuenta delbeneficiario). Cuando ocurra uno de estos eventos, el bancoactualizar de manera apropiada el saldo del usuario que estalmacenado en su base de datos. Esto ocurre de manera indepen-diente al sistema ATM.] Si la ranura de depsito no recibe un sobredentro de un plazo de tiempo no mayor a dos minutos, la pantallamuestra un mensaje indicando que el sistema cancel la transaccindebido a la inactividad. Despus el ATM muestra el men principal yespera la entrada del usuario. Una vez que el sistema ejecuta unatransaccin en forma exitosa, debe volver a mostrar el men principalpara que el usuario pueda realizar transacciones adicionales. Si elusuario elije salir del sistema, la pantalla debe mostrar unmensaje de agradecimiento y despus el mensaje de bienvenida para elsi- guiente usuario. Anlisis del sistema de ATM En la declaracinanterior se present un ejemplo simplificado de un documento derequerimientos. Por lo general, dicho documento es el resultado deun proceso detallado de recopilacin de requeri- mientos, el cualpodra incluir entrevistas con usuarios potenciales del sistema yespecialistas en campos relacionados con el mismo. Por ejemplo, unanalista de sistemas que se contrate para preparar un docu- mentode requerimientos para software bancario (por ejemplo, el sistemaATM que describimos aqu) podra entrevistar expertos financierospara obtener una mejor comprensin de qu es lo que debe hacer elsoftware. El analista utilizara la informacin recopilada paracompilar una lista de requerimientos del sistema, para guiar a losdiseadores de sistemas en el proceso de diseo del mismo. El procesode recopilacin de requerimientos es una tarea clave de la primeraetapa del ciclo de vida del software. El ciclo de vida del softwareespecifica las etapas a travs de las cuales el software evolucionadesde el momento en que fue concebido hasta que deja de utilizarse.Por lo general, estas etapas incluyen: anlisis, diseo,implementacin, prueba y depuracin, despliegue, mantenimiento yretiro. Existen varios modelos de ciclo de vida del software, cadauno con sus propias preferencias y especificaciones con respecto acundo y qu tan a menudo deben llevar a cabo los ingenieros desoftware las diversas etapas. Los modelos de cascada realizan cadaetapa una vez en sucesin, mientras 7. 12.2 Anlisis del documento derequerimientos 475 que los modelos iterativos pueden repetir una oms etapas varias veces a lo largo del ciclo de vida de un producto.La etapa de anlisis se enfoca en definir el problema a resolver. Aldisear cualquier sistema, uno debe resolver el problema de lamanera correcta, pero de igual manera uno debe resolver el pro-blema correcto. Los analistas de sistemas recolectan losrequerimientos que indican el problema es- pecfico a resolver.Nuestro documento de requerimientos describe nuestro sistema ATMcon el suficiente detalle como para que usted no necesite pasar poruna etapa de anlisis exhaustiva; ya lo hicimos por usted. Paracapturar lo que debe hacer un sistema propuesto, losdesarrolladores emplean a menudo una tcnica conocida como modeladode caso-uso. Este proceso identifica los casos de uso del sistema,cada uno de los cuales representa una capacidad distinta que elsistema provee a sus clientes. Por ejemplo, es comn que los ATMtengan varios casos de uso, como Ver saldo de cuenta, Retirarefectivo, Depositar fondos, Transferir fondos entre cuentas yComprar estampas postales. El sistema ATM simplificado queconstruiremos en este caso de estudio requiere slo los tresprimeros casos de uso. Cada uno de los casos de uso describe unescenario comn en el cual el usuario utiliza el sistema. Usted yaley las descripciones de los casos de uso del sistema ATM en eldocumento de requerimien- tos; las listas de pasos requeridos pararealizar cada tipo de transaccin (como solicitud de saldo, retiro ydepsito) describen en realidad los tres casos de uso de nuestroATM: Ver saldo de cuenta, Retirar efectivo y Depositar fondos,respectivamente. Diagramas de caso-uso Ahora presentaremos elprimero de varios diagramas de UML en el caso de estudio. Crearemosun diagrama de caso-uso para modelar las interacciones entre losclientes de un sistema (en este caso de estudio, los clientes delbanco) y sus casos de uso. El objetivo es mostrar los tipos deinteracciones que tienen los usuarios con un sistema sin proveerlos detalles; stos se mostrarn en otros diagramas de UML (loscuales presentaremos a lo largo del caso de estudio). A menudo, losdiagramas de caso-uso se acompaan de texto informal que describelos casos de uso con ms detalle; como el texto que apa- rece en eldocumento de requerimientos. Los diagramas de caso-uso se producendurante la etapa de anlisis del ciclo de vida del software. Ensistemas ms grandes, los diagramas de caso-uso son herra- mientasindispensables que ayudan a los diseadores de sistemas a enfocarseen satisfacer las necesi- dades de los usuarios. La figura 12.4muestra el diagrama de caso-uso para nuestro sistema ATM. La figurahumana representa a un actor, el cual define los roles que desempeauna entidad externa (como una perso- na u otro sistema) cuandointeracta con el sistema. Para nuestro cajero automtico, el actores un Fig. 12.4 Diagrama de caso-uso para el sistema ATM, desde laperspectiva del usuario. Depositar fondos Retirar efectivo Versaldo de cuenta Usuario 8. 476 Captulo 12 Caso de estudio del ATM,Parte 1: Diseo orientado a objetos con UML Usuario que puede ver elsaldo de una cuenta, retirar efectivo y depositar fondos del ATM.El Usua- rio no es una persona real, sino que constituye los rolesque puede desempear una persona real (al desempear el papel de unUsuario) mientras interacta con el ATM. Un diagrama de caso-usopuede incluir varios actores. Por ejemplo, el diagrama de caso-usopara un sistema ATM de un banco real podra incluir tambin un actorllamado Administrador, que rellene el dispensador de efectivo adiario. Nuestro documento de requerimientos provee los actores: losusuarios del ATM deben poder ver el saldo de su cuenta, retirarefectivo y depositar fondos. Por lo tanto, el actor en cada uno deestos tres casos de uso es el usuario que interacta con el ATM. Unaentidad externa (una persona real) desem- pea el papel del usuariopara realizar transacciones financieras. La figura 12.4 muestra unactor, cuyo nombre (Usuario) aparece debajo del actor en eldiagrama. UML modela cada caso de uso como un valo conectado a unactor con una lnea slida. Los ingenieros de software (msespecficamente, los diseadores de sistemas) deben analizar eldocumento de requerimientos o un conjunto de casos de uso, y disearel sistema antes de que los pro- gramadores lo implementen en unlenguaje de programacin especfico. Durante la etapa de anlisis, losdiseadores de sistemas se enfocan en comprender el documento derequerimientos para producir una especificacin de alto nivel quedescriba qu es lo que el sistema debe hacer. El resultado de laetapa de diseo (una especificacin de diseo) debe detallar conclaridad cmo debe construirse el sistema para satisfacer estosrequerimientos. En las siguientes secciones llevaremos a cabo lospasos de un proceso simple de diseo orientado a objetos (DOO) conel sistema ATM, para producir una especificacin de diseo quecontenga una coleccin de diagramas de UML y texto de apoyo. UML estdiseado para utilizarse con cualquier proceso de DOO. Existenmuchos de esos pro- cesos, de los cuales el ms conocido es RationalUnified Process (RUP), desarrollado por Rational SoftwareCorporation, que ahora forma parte de IBM. RUP es un procesorobusto para disear aplicaciones a nivel industrial. Para este casode estudio, presentaremos nuestro propio proceso de diseosimplificado, desarrollado para estudiantes de cursos deprogramacin de primer y segundo semestre. Diseo del sistema ATMAhora comenzaremos la etapa de diseo de nuestro sistema ATM. Unsistema es un conjunto de componentes que interactan para resolverun problema. Por ejemplo, para realizar sus tareas desig- nadas,nuestro sistema ATM tiene una interfaz de usuario (figura 12.1),contiene software para ejecutar transacciones financieras einteracta con una base de datos de informacin de cuentas bancarias.La estructura del sistema describe los objetos del sistema y susinterrelaciones. El com- portamiento del sistema describe la maneraen que cambia el sistema a medida que sus objetos interactan entres. Todo sistema tiene tanto estructura como comportamiento; losdiseadores deben especificar am- bos. Existen diversos tipos deestructuras y comportamientos de un sistema. Por ejemplo, lasinterac- ciones entre los objetos en el sistema son distintas a lasinteracciones entre el usuario y el sistema, pero aun as ambasconstituyen una porcin del comportamiento del sistema. El estndarUML 2 especifica 13 tipos de diagramas para documentar los modelosde un sistema. Cada tipo de diagrama modela una caractersticadistinta de la estructura o del comportamiento de un sistema; seisdiagramas se relacionan con la estructura del sistema; los sieterestantes se relacionan con su comportamiento. Aqu listaremos slolos seis tipos de diagramas que utilizaremos en nuestro caso deestudio; uno de ellos modela la estructura del sistema, mientrasque los otros cinco modelan el com- portamiento. En el apndice P(en ingls en el sitio web), veremos las generalidades sobre lossiete tipos restantes de diagramas de UML. 1. Los diagramas decaso-uso, como el de la figura 12.4, modelan las interaccionesentre un sistema y sus entidades externas (actores) en trminos decasos de uso (capacidades del sis- tema, como Ver saldo de cuenta,Retirar efectivo y Depositar fondos). 9. Ejercicios deautoevaluacin de la seccin 12.2 477 2. Los diagramas de clases, queestudiar en la seccin 12.3, modelan las clases o bloques deconstruccin que se utilizan en un sistema. Cada sustantivo u objetoque se describe en el documento de requerimientos es candidato paraser una clase en el sistema (por ejemplo, Cuenta, Teclado). Losdiagramas de clases nos ayudan a especificar las relacionesestructurales entre las partes del sistema. Por ejemplo, eldiagrama de clases del sistema ATM especificar que el ATM estcompuesto fsicamente de una pantalla, un teclado, un dispensador deefec- tivo y una ranura para depsitos. 3. Los diagramas de mquinade estado, que estudiar en la seccin 12.5, modelan las formas enque un objeto cambia de estado. El estado de un objeto se indicamediante los valores de todos los atributos del objeto, en unmomento dado. Cuando un objeto cambia de estado, pue- decomportarse de manera distinta en el sistema. Por ejemplo, despusde validar el NIP de un usuario, el ATM cambia del estado usuariono autenticado al estado usuario autenticado, punto en el cual elATM permite al usuario realizar transacciones financieras (porejemplo, ver el saldo de su cuenta, retirar efectivo, depositarfondos). 4. Los diagramas de actividad, que tambin estudiar en laseccin 12.5, modelan la actividad de un objeto: su flujo de trabajo(secuencia de eventos) durante la ejecucin del programa. Undiagrama de actividad modela las acciones que realiza el objeto yespecifica el orden en el cual desempea estas acciones. Porejemplo, un diagrama de actividad muestra que el ATM debe obtenerel saldo de la cuenta del usuario (de la base de datos deinformacin de las cuen- tas del banco) antes de que la pantallapueda mostrar el saldo al usuario. 5. Los diagramas de comunicacin(llamados diagramas de colaboracin en versiones an- teriores deUML) modelan las interacciones entre los objetos en un sistema, conun nfasis acerca de qu interacciones ocurren. En la seccin 12.7aprender que estos diagramas mues- tran cules objetos debeninteractuar para realizar una transaccin en el ATM. Por ejemplo, elATM debe comunicarse con la base de datos de informacin de lascuentas del banco para ob- tener el saldo de una cuenta. 6. Losdiagramas de secuencia modelan tambin las interacciones entre losobjetos en un sistema, pero a diferencia de los diagramas decomunicacin, enfatizan cundo ocurren las interaccio- nes. En laseccin 12.7 aprender que estos diagramas ayudan a mostrar el ordenen el que ocurren las interacciones al ejecutar una transaccinfinanciera. Por ejemplo, la pantalla pide al usuario que escriba unmonto de retiro antes de dispensar el efectivo. En la seccin 12.3seguiremos diseando nuestro sistema ATM; ah identificaremos lasclases del documento de requerimientos. Para lograr esto,extraeremos sustantivos clave y frases nominales del do- cumento derequerimientos. Mediante el uso de estas clases, desarrollaremosnuestro primer borrador del diagrama de clases que modelar laestructura de nuestro sistema ATM. Recurso Web Hemos creado unextenso Centro de recursos de UML, el cual contiene muchos vnculosa informacin adicional, incluyendo introducciones, tutoriales,blogs, libros, certificacin, conferencias, herramien- tas paradesarrolladores, documentacin, libros electrnicos, secciones FAQ,foros, grupos, UML en Java, podcasts, seguridad, herramientas,descargas, cursos de capacitacin, videos y otros ms. Para navegarpor nuestro Centro de recursos de UML, visite www.deitel.com/UML/.Ejercicios de autoevaluacin de la seccin 12.2 12.1 Suponga quehabilitamos a un usuario de nuestro sistema ATM para transferirdinero entre dos cuentas bancarias. Modifique el diagrama decaso-uso de la figura 12.4 para reflejar este cambio. 10. 478Captulo 12 Caso de estudio del ATM, Parte 1: Diseo orientado aobjetos con UML 12.2 Los modelan las interacciones entre losobjetos en un sistema, con nfasis acerca de cundo ocurren estasinteracciones. a) Diagramas de clases b) Diagramas de secuencia c)Diagramas de comunicacin d) Diagramas de actividad 12.3 Cul de lassiguientes opciones lista las etapas de un tpico ciclo de vida desoftware, en orden secuencial? a) diseo, anlisis, implementacin,prueba b) diseo, anlisis, prueba, implementacin c) anlisis, diseo,prueba, implementacin d) anlisis, diseo, implementacin, prueba 12.3Identificacin de las clases en un documento de requerimientos[Nota: esta seccin se puede estudiar despus del captulo 3]. Ahoraempezaremos a disear el sistema ATM. En esta seccin identificaremoslas clases necesarias para crear el sistema ATM, analizando lossustantivos y las frases nominales que aparecen en el documento derequerimientos. Presentaremos los diagramas de clases de UML paramodelar las relaciones entre estas clases. Este primer paso esimportante para definir la estructura de nuestro sistema.Identificacin de las clases en un sistema Para comenzar nuestroproceso de DOO, identificaremos las clases requeridas para crear elsistema ATM. Ms adelante describiremos estas clases mediante el usode los diagramas de clases de UML y las imple- mentaremos en Java.Primero debemos revisar el documento de requerimientos de la seccin12.2, para identificar los sustantivos y frases nominales clave quenos ayuden a identificar las clases que conformarn el sistema ATM.Tal vez decidamos que algunos de estos sustantivos y frasesnominales sean atributos de otras clases en el sistema.Tal veztambin concluyamos que algunos de los sustantivos no corresponden aciertas partes del sistema y, por ende, no deben modelarse. Amedida que avancemos por el proceso de diseo podemos irdescubriendo clases adicionales. La figura 12.5 lista lossustantivos y frases nominales que se encontraron en el documentode reque- rimientos. Los listaremos de izquierda a derecha, en elorden en el que los encontramos por primera vez. Slo listaremos laforma singular de cada sustantivo o frase nominal. Fig. 12.5Sustantivos y frases nominales en el documento de requerimientosdel ATM. Sustantivos y frases nominales en el documento derequerimientos del ATM banco dinero / fondos nmero de cuenta ATMpantalla NIP usuario teclado numrico base de datos del bancocliente dispensador de efectivo solicitud de saldo transaccinbillete de $20 / efectivo retiro cuenta ranura de depsito depsitosaldo sobre de depsito Crearemos clases slo para los sustantivos yfrases nominales que tengan importancia en el sistema ATM. Nomodelamos banco como una clase, ya que el banco no es una parte delsistema ATM; el banco slo quiere que nosotros construyamos el ATM.Cliente y usuario tambin representan enti- 11. 12.3 Identicacin delas clases en un documento de requerimientos 479 dades fuera delsistema; son importantes debido a que interactan con nuestrosistema ATM, pero no necesitamos modelarlos como clases en elsoftware del ATM. Recuerde que modelamos un usuario del ATM (esdecir, un cliente del banco) como el actor en el diagrama de casosde uso de la figura 12.4. No necesitamos modelar billete de $20 nisobre de depsito como clases. stos son objetos fsicos en el mundoreal, pero no forman parte de lo que se va a automatizar. Podemosrepresentar en forma adecuada la presencia de billetes en elsistema, mediante el uso de un atributo de la clase que modela eldispensador de efectivo (en la seccin 12.4 asignaremos atributos alas clases del sis- tema ATM). Por ejemplo, el dispensador deefectivo mantiene un conteo del nmero de billetes que contiene. Eldocumento de requerimientos no dice nada acerca de lo que debehacer el sistema con los sobres de depsito despus de recibirlos.Podemos suponer que con slo admitir la recepcin de un sobre (unaoperacin que realiza la clase que modela la ranura de depsito) essuficiente para re- presentar la presencia de un sobre en elsistema. En la seccin 12.6 asignaremos operaciones a las clases delsistema ATM. En nuestro sistema ATM simplificado, lo ms apropiadosera representar varios montos de dinero, incluyendo el saldo deuna cuenta, como atributos de clases. De igual forma, lossustantivos nmero de cuenta y NIP representan piezas importantes deinformacin en el sistema ATM. Son atributos importantes de unacuenta bancaria. Sin embargo, no exhiben comportamientos. Por ende,podemos modelarlos de la manera ms apropiada como atributos de unaclase de cuenta. Aunque, con frecuencia, el documento derequerimientos describe una transaccin en un senti- do general, nomodelaremos la amplia nocin de una transaccin financiera en estemomento. En vez de ello, modelaremos los tres tipos detransacciones (es decir, solicitud de saldo, retiro y depsito) comoclases individuales. Estas clases poseen los atributos especficosnecesarios para ejecutar las transacciones que representan. Porejemplo, para un retiro se necesita conocer el monto de dinero queel usuario desea retirar. Sin embargo, una solicitud de saldo norequiere datos adicionales aparte del nmero de cuenta. Lo que esms, las tres clases de transacciones exhiben comportamientos nicos.Para un retiro se requiere entregar efectivo al usuario, mientrasque para un depsito se requiere recibir un sobre de depsito delusuario. En la seccin 13.3 factorizaremos las caractersticascomunes de todas las transacciones en una clase de transaccingeneral, mediante el uso del concepto orientado a objetos de laherencia. Determinaremos las clases para nuestro sistema con baseen los sustantivos y frases nominales res- tantes de la figura12.5. Cada una de ellas se refiere a uno o varios de los siguienteselementos: ATM pantalla teclado numrico dispensador de efectivoranura de depsito cuenta base de datos del banco solicitud de saldoretiro depsito Es probable que los elementos de esta lista seanclases que necesitaremos implementar en nuestro sistema. Ahorapodemos modelar las clases en nuestro sistema, con base en la listaque hemos creado. En el proceso de diseo escribimos los nombres delas clases con la primera letra en mayscula (una con- vencin deUML), como lo haremos cuando escribamos el cdigo de Java paraimplementar nuestro diseo. Si el nombre de una clase contiene ms deuna palabra, juntaremos todas las palabras y 12. 480 Captulo 12Caso de estudio del ATM, Parte 1: Diseo orientado a objetos con UMLescribiremos la primera letra de cada una de ellas en mayscula (porejemplo, NombreConVarias- Palabras). Utilizando esta convencin,crearemos las clases ATM, Pantalla, Teclado, Dispensador- Efectivo,RanuraDeposito, Cuenta, BaseDatosBanco, SolicitudSaldo, Retiro yDeposito. Cons- truiremos nuestro sistema mediante el uso de todasestas clases como bloques de construccin. Sin embargo, antes deempezar a construir el sistema, debemos comprender mejor la formaen que las clases se relacionan entre s. Modelado de las clases UMLnos permite modelar, a travs de los diagramas de clases, las clasesen el sistema ATM y sus inte- rrelaciones. La figura 12.6representa a la clase ATM. En UML, cada clase se modela como unrectngu- lo con tres compartimientos. El compartimiento superiorcontiene el nombre de la clase, centrado hori- zontalmente y ennegrita. El compartimiento intermedio contiene los atributos de laclase (en las secciones 12.4 y 12.5 hablaremos sobre losatributos). El compartimiento inferior contiene las operacio- nesde la clase (que veremos en la seccin 12.6). En la figura 12.6, loscompartimientos intermedio e in- ferior estn vacos, ya que no hemosdeterminado los atributos y operaciones de esta clase todava. Fig.12.6 Representacin de una clase en UML mediante un diagrama declases. ATM Fig. 12.7 Diagrama de clases que muestra una asociacinentre clases. Ejecuta1 transaccionActual 0..1 RetiroATM Losdiagramas de clases tambin muestran las relaciones entre las clasesdel sistema. La figura 12.7 muestra cmo nuestras clases ATM yRetiro se relacionan una con la otra. Por el momento modelaremosslo este subconjunto de las clases del ATM, por cuestin desimpleza. Ms adelante en esta seccin, presentaremos un diagrama declases ms completo. Observe que los rectngulos que representan alas clases en este diagrama no estn subdivididos encompartimientos. UML permite suprimir los atribu- tos y lasoperaciones de una clase de esta forma, cuando sea apropiado, paracrear diagramas ms legibles. Un diagrama de este tipo se denominadiagrama con elementos omitidos (elided diagram): su infor-macin,comoelcontenidodeloscompartimientossegundoytercero,nosemodela.Enlassecciones12.4y 12.6 colocaremos informacin en estos compartimientos. En lafigura 12.7, la lnea slida que conecta a las dos clases representauna asociacin: una rela- cin entre clases. Los nmeros cerca de cadaextremo de la lnea son valores de multiplicidad; stos indi- cancuntos objetos de cada clase participan en la asociacin. En estecaso, al seguir la lnea de un extremo al otro se revela que, en unmomento dado, un objeto ATM participa en una asociacin con cero ocon un objeto Retiro; cero si el usuario actual no est realizandouna transaccin o si ha solicitado un tipo distinto de transaccin, yuno si el usuario ha solicitado un retiro. UML puede modelar muchostipos de multiplicidad. La figura 12.8 lista y explica los tipos demultiplicidad. 13. 12.3 Identicacin de las clases en un documentode requerimientos 481 Una asociacin puede tener nombre. Porejemplo, la palabra Ejecuta por encima de la lnea que conecta a lasclases ATM y Retiro en la figura 12.7 indica el nombre de esaasociacin. Esta parte del dia- grama se lee as: un objeto de laclase ATM ejecuta cero o un objeto de la clase Retiro. Los nombresde las asociaciones son direccionales, como lo indica la punta deflecha rellena; por lo tanto, sera inapro- piado, por ejemplo, leerla anterior asociacin de derecha a izquierda como cero o un objetode la clase Retiro ejecuta un objeto de la clase ATM. La palabratransaccionActual en el extremo de Retiro de la lnea de asociacinen la figura 12.7 es un nombre de rol, el cual identifica el rolque desempea el objeto Retiro en su relacin con el ATM. Un nombrede rol agrega significado a una asociacin entre clases, ya queidentifica el rol que desempea una clase dentro del contexto de unaasociacin. Una clase puede desempear varios roles en el mismosistema. Por ejemplo, en un sistema de personal de una universidad,una persona puede desempear el rol de profesor con respecto a losestudiantes. La misma persona puede desempear el rol de colegacuando participa en una asociacin con otro profesor, y deentrenador cuando entrena a los atletas estudiantes. En la figura12.7, el nombre de rol transaccionActual indica que el objetoRetiro, que participa en la asociacin Ejecuta con un objeto de laclase ATM, representa a la transaccin que est procesando el ATM enese momento. En otros contextos, un objeto Retiro puede desempearotros roles (por ejemplo, la transaccin anterior). Observe que noespecificamos un nombre de rol para el extremo del ATM de laasociacin Ejecuta. A menudo, los nombres de los roles se omiten enlos diagra- mas de clases, cuando el significado de una asociacinest claro sin ellos. Adems de indicar relaciones simples, lasasociaciones pueden especificar relaciones ms comple- jas, comocuando los objetos de una clase estn compuestos de objetos de otrasclases. Considere un cajero automtico real. Qu piezas rene unfabricante para construir un ATM funcional? Nuestro documento derequerimientos nos indica que el ATM est compuesto de una pantalla,un teclado, un dispensador de efectivo y una ranura de depsito. Enla figura 12.9, los diamantes slidos que se adjuntan a las lneas deasociacin de la clase ATM indican que esta clase tiene una relacinde composicin con las clases Pantalla, Teclado, Dispen-sadorEfectivo y RanuraDeposito. La composicin implica una relacintodo/parte. La clase que tiene el smbolo de composicin (el diamanteslido) en su extremo de la lnea de asociacin es el todo (en estecaso, ATM), y las clases en el otro extremo de las lneas deasociacin son las partes; en este caso, las clases Pantalla,Teclado, DispensadorEfectivo y RanuraDeposito. Las composiciones enla figura 12.9 indican que un objeto de la clase ATM est formadopor un objeto de la clase Pantalla, un objeto de Smbolo Signicado 0Ninguno 1 Uno m Un valor entero 0..1 Cero o uno m, n m o n m..nCuando menos m, pero no ms que n * Cualquier entero no negativo(cero o ms) 0..* Cero o ms (idntico a *) 1..* Uno o ms Fig. 12.8Tipos de multiplicidad. 14. 482 Captulo 12 Caso de estudio del ATM,Parte 1: Diseo orientado a objetos con UML la claseDispensadorEfectivo, un objeto de la clase Teclado y un objeto dela clase RanuraDeposito. El ATM tiene una pantalla, un teclado, undispensador de efectivo y una ranura de depsito (como vimos en elcaptulo 9, la relacin es un define la herencia. En la seccin 13.3veremos que hay una buena opor- tunidad de usar la herencia en eldiseo del sistema ATM). Fig. 12.9 Diagrama de clases que muestralas relaciones de composicin. 1 1 1 1 1 1 1 1 Pantalla ATM TecladoRanuraDeposito DispensadorEfectivo De acuerdo con la especificacinde UML (www.uml.org/technology/documents/formal/ uml.htm), lasrelaciones de composicin tienen las siguientes propiedades: 1. Slouna clase en la relacin puede representar el todo (es decir, eldiamante puede colocarse slo en un extremo de la lnea deasociacin). Por ejemplo, la pantalla es parte del ATM o el ATM esparte de la pantalla, pero la pantalla y el ATM no puedenrepresentar ambos el todo dentro de la relacin. 2. Las partes en larelacin de composicin existen slo mientras exista el todo, y eltodo es respon- sable de la creacin y destruccin de sus partes. Porejemplo, el acto de construir un ATM inclu- ye la manufactura desus partes. Lo que es ms, si el ATM se destruye, tambin sedestruyen su pantalla, teclado, dispensador de efectivo y ranura dedepsito. 3. Una parte puede pertenecer slo a un todo a la vez,aunque esa parte puede quitarse y unirse a otro todo, el cualentonces asumir la responsabilidad de esa parte. Los diamantesslidos en nuestros diagramas de clases indican las relaciones decomposicin que cumplen con estas propiedades. Si una relacin es unno satisface uno o ms de estos criterios, UML especifica que sedeben adjuntar diamantes sin relleno a los extremos de las lneas deasociacin para indicar una agregacin: una forma ms dbil de lacomposicin. Por ejemplo, una computadora per- sonal y un monitor decomputadora participan en una relacin de agregacin: la computadoratiene un monitor, pero las dos partes pueden existir en formaindependiente, y el mismo monitor pue- de conectarse a variascomputadoras a la vez, con lo cual se violan las propiedadessegunda y tercera de la composicin. La figura 12.10 muestra undiagrama de clases para el sistema ATM. Este diagrama modela lamayora de las clases que identificamos antes en esta seccin, ascomo las asociaciones entre ellas que podemos inferir del documentode requerimientos. Las clases SolicitudSaldo y Deposito participanen asociaciones similares a las de la clase Retiro, por lo quepreferimos omitirlas en este diagrama por cuestin de simpleza. Enla seccin 13.3 expandiremos nuestro diagrama de clases para incluirtodas las clases en el sistema ATM. 15. 12.3 Identicacin de lasclases en un documento de requerimientos 483 La figura 12.10presenta un modelo grfico de la estructura del sistema ATM. Estediagrama de clases incluye a las clases BaseDatosBanco y Cuenta,junto con varias asociaciones que no presenta- mos en las figuras12.7 o 12.9. El diagrama de clases muestra que la clase ATM tieneuna relacin de uno a uno con la clase BaseDatosBanco: un objeto ATMautentica a los usuarios con base en un objeto BaseDatosBanco. Enla figura 12.10 tambin modelamos el hecho de que la base de datosdel banco contiene informacin sobre muchas cuentas; un objeto de laclase BaseDatosBanco participa en una relacin de composicin concero o ms objetos de la clase Cuenta. El valor de multiplicidad0..* en el extremo de la clase Cuenta, de la asociacin entre lasclases BaseDatosBanco y Cuenta, indica que cero o ms objetos de laclase Cuenta participan en la asociacin. La clase BaseDatosBancotiene una relacin de uno a varios con la clase Cuenta;BaseDatosBanco puede contener muchos objetos Cuenta. De manerasimilar, la clase Cuenta tiene una relacin de varios a uno con laclase BaseDatos- Banco; puede haber muchos objetos Cuenta enBaseDatosBanco. Si recuerda la figura 12.8, el valor demultiplicidad * es idntico a 0..*. Incluimos 0..* en nuestrosdiagramas de clases por cuestin de claridad. La figura 12.10 tambinindica que, en cualquier momento dado, puede existir 0 o 1 objetoRetiro. Si el usuario va a realizar un retiro, un objeto de laclase Retiro accede a/modifica un saldo de cuenta a travs de unobjeto de la clase BaseDatosBanco. Podramos haber creado unaasocia- cin directamente entre la clase Retiro y la clase Cuenta.No obstante, el documento de requeri- mientos indica que el ATMdebe interactuar con la base de datos de informacin de las cuentasdel banco para realizar transacciones. Una cuenta de banco contieneinformacin delicada, por lo que los ingenieros de sistemas debenconsiderar siempre la seguridad de los datos personales al disearun sistema. Por ello, slo BaseDatosBanco puede acceder a una cuentay manipularla en forma directa. Fig. 12.10 Diagrama de clases parael modelo del sistema ATM. Accede a/modifica el saldo de una cuentaa travs de Ejecuta 1 1 1 1 1 1 1 1 1 1 1 1 1 0..* 0..1 0..1 0..10..10..1 1 Contiene Autentica al usuario en base a Teclado RetiroRanuraDeposito ATM DispensadorEfectivo Pantalla CuentaBaseDatosBanco 1 1 16. 484 Captulo 12 Caso de estudio del ATM,Parte 1: Diseo orientado a objetos con UML Todas las dems partesdel sistema deben interactuar con la base de datos para recuperar oactualizar la informacin de las cuentas (por ejemplo, el saldo deuna cuenta). El diagrama de clases de la figura 12.10 tambin modelalas asociaciones entre la clase Retiro y las clases Pantalla,DispensadorEfectivo y Teclado. Una transaccin de retiro implicapedir al usuario que seleccione el monto a retirar; tambin implicarecibir entrada numrica. Estas acciones requieren el uso de lapantalla y del teclado, respectivamente. Adems, para entregarefectivo al usuario se requiere acceso al dispensador de efectivo.Aunque no se muestran en la figura 12.10, las clases SolicitudSaldoy Deposito participan en varias asociaciones con las otras clasesdel sistema ATM. Al igual que la clase Retiro, cada una de estasclases se asocia con las clases ATM y BaseDatosBanco. Un objeto dela clase SolicitudSaldo tambin se asocia con un objeto de la clasePantalla para mostrar al usuario el saldo de una cuenta. La claseDeposito se asocia con las clases Pantalla, Teclado yRanuraDeposito. Al igual que los retiros, las transacciones dedepsito requieren el uso de la pantalla y el teclado para mostrarmensajes y recibir datos de entrada, respectivamente. Para recibirsobres de depsito, un objeto de la clase Deposito acce- de a laranura de depsitos. Ya hemos identificado las clases iniciales ennuestro sistema ATM (aunque tal vez descubramos otras, a medida queavancemos con el diseo y la implementacin). En la seccin 12.4determinaremos los atributos para cada una de estas clases, y en laseccin 12.5 utilizaremos estos atributos para exami- nar la formaen que cambia el sistema con el tiempo. Ejercicios de autoevaluacinde la seccin 12.3 12.4 Suponga que tenemos una clase llamada Auto,la cual representa a un auto. Piense en algunas de las distintaspiezas que podra reunir un fabricante para producir un autocompleto. Cree un diagrama de clases (similar a la figura 12.9) quemodele algunas de las relaciones de composicin de la clase Auto.12.5 Suponga que tenemos una clase llamada Archivo, la cualrepresenta un documento electrnico en una compu- tadoraindependiente, sin conexin de red, representada por la claseComputadora. Qu tipo de asociacin existe entre la clase Computadoray la clase Archivo? a) La clase Computadora tiene una relacin deuno a uno con la clase Archivo. b) La clase Computadora tiene unarelacin de varios a uno con la clase Archivo. c) La claseComputadora tiene una relacin de uno a varios con la clase Archivo.d) La clase Computadora tiene una relacin de varios a varios con laclase Archivo. 12.6 Indique si la siguiente aseveracin es verdaderao falsa. Si es falsa, explique por qu: un diagrama de clases deUML, en el que no se modelan los compartimientos segundo y tercero,se denomina diagrama con elementos omitidos (elided diagram). 12.7Modifique el diagrama de clases de la figura 12.10 para incluir laclase Deposito, en vez de la clase Retiro. 12.4 Identificacin delos atributos de las clases [Nota: esta seccin se puede estudiardespus del captulo 4]. Las clases tienen atributos (datos) yoperaciones (comportamientos). Los atributos de las clases seimple- mentan como campos, y las operaciones de las clases seimplementan como mtodos. En esta seccin determinaremos muchos delos atributos necesarios en el sistema ATM. En la seccin 12.5examinaremos cmo esos atributos representan el estado de un objeto.En la seccin 12.6 determinaremos las operacio- nes de las clases.Identificacin de los atributos Considere los atributos de algunosobjetos reales: los atributos de una persona incluyen su altura,peso y si es zurdo, diestro o ambidiestro. Los atributos de unradio incluyen la estacin, el volumen y si est 17. 12.4 Identicacinde los atributos de las clases 485 en AM o FM. Los atributos de unauto incluyen las lecturas de su velocmetro y odmetro, la cantidadde gasolina en su tanque y la velocidad de marcha en la que seencuentra. Los atributos de una compu- tadora personal incluyen sufabricante (por ejemplo, Dell, Sun, Apple o IBM), el tipo depantalla (por ejemplo, LCD o CRT), el tamao de su memoria principaly el de su disco duro. Podemos identificar muchos atributos de lasclases en nuestro sistema, analizando las palabras y frasesdescriptivas en el documento de requerimientos. Para cada palabra ofrase que descubramos desempea un rol importante en el sistema ATM,creamos un atributo y lo asignamos a una o ms de las clasesidentificadas en la seccin 12.3. Tambin creamos atributos pararepresentar los datos adi- cionales que pueda necesitar una clase,ya que dichas necesidades se van aclarando a lo largo del pro- cesode diseo. La figura 12.11 lista las palabras o frases del documentode requerimientos que describen a cada una de las clases. Paraformar esta lista, leemos el documento de requerimientos eidentificamos cual- quier palabra o frase que haga referencia a lascaractersticas de las clases en el sistema. Por ejemplo, eldocumento de requerimientos describe los pasos que se llevan a cabopara obtener un monto de retiro, por lo que listamos montoenseguida de la clase Retiro. Clase Palabras y frases descriptivasATM el usuario es autenticado SolicitudSaldo nmero de cuenta Retironmero de cuenta monto Deposito nmero de cuenta monto BaseDatosBanco[no hay palabras o frases descriptivas] Cuenta nmero de cuenta NIPsaldo Pantalla [no hay palabras o frases descriptivas] Teclado [nohay palabras o frases descriptivas] DispensadorEfectivo empiezacada da cargado con 500 billetes de $20 RanuraDeposito [no haypalabras o frases descriptivas] La figura 12.11 nos conduce a crearun atributo de la clase ATM. Esta clase mantiene informacin acercadel estado del ATM. La frase el usuario es autenticado describe unestado del ATM (en la sec- cin 12.5 introduciremos los estados),por lo que incluimos usuarioAutenticado como un atributo Boolean(es decir, un atributo que tiene un valor de true o false) en laclase ATM. El atributo tipo Boolean en UML es equivalente al tipoboolean en Java. Este atributo indica si el ATM autentic con xitoal usuario actual o no; usuarioAutenticado debe ser true para queel sistema permita al usuario realizar transacciones y acceder a lainformacin de la cuenta. Este atributo nos ayuda a cerciorarnos dela seguridad de los datos en el sistema. Las clases SolicitudSaldo,Retiro y Deposito comparten un atributo. Cada transaccin requiereun nmero de cuenta que corresponde a la cuenta del usuario querealiza la transaccin. Asignamos Fig. 12.11 Palabras y frasesdescriptivas del documento de requerimientos del ATM. 18. 486Captulo 12 Caso de estudio del ATM, Parte 1: Diseo orientado aobjetos con UML el atributo entero numeroCuenta a cada clase detransaccin para identificar la cuenta a la que se aplica un objetode la clase. Las palabras y frases descriptivas en el documento derequerimientos tambin sugieren ciertas diferencias en los atributosrequeridos por cada clase de transaccin. El documento derequerimientos indica que para retirar efectivo o depositar fondos,los usuarios deben introducir un monto espec- fico de dinero pararetirar o depositar, respectivamente. Por ende, asignamos a lasclases Retiro y Deposito un atributo llamado monto para almacenarel valor suministrado por el usuario. Los montos de dinerorelacionados con un retiro y un depsito son caractersticas quedefinen estas transaccio- nes, que el sistema requiere para que selleven a cabo. Sin embargo, la clase SolicitudSaldo no nece- sitadatos adicionales para realizar su tarea; slo requiere un nmero decuenta para indicar la cuenta cuyo saldo hay que obtener. La claseCuenta tiene varios atributos. El documento de requerimientosestablece que cada cuen- ta de banco tiene un nmero de cuenta y unNIP, que el sistema utiliza para identificar las cuentas yautentificar a los usuarios. A la clase Cuenta le asignamos dosatributos enteros: numeroCuenta y nip. El documento derequerimientos tambin especifica que una cuenta debe mantener unsaldo del monto de dinero que hay en la cuenta, y que el dinero queel usuario deposita no estar disponible para su retiro sino hastaque el banco verifique la cantidad de efectivo en el sobre dedepsito y cualquier cheque que contenga. Sin embargo, una cuentadebe registrar de todas formas el monto de dinero que deposita unusuario. Por lo tanto, decidimos que una cuenta debe representar unsaldo utilizando dos atributos: saldoDisponible y saldoTotal. Elatributo saldoDisponible rastrea el monto de dinero que un usuariopuede retirar de la cuenta. El atributo saldoTotal se refiere almonto total de di- nero que el usuario tiene en depsito (es decir,el monto de dinero disponible, ms el monto de depsitos en efectivoo la cantidad de cheques esperando a ser verificados). Por ejemplo,suponga que un usuario del ATM deposita $50.00 en efectivo, en unacuenta vaca. El atributo saldoTotal se incrementara a $50.00 pararegistrar el depsito, pero el saldoDisponible permanecera en $0.[Nota: estamos suponiendo que el banco actualiza el atributosaldoDisponible de una Cuenta poco despus de que se realiza latransaccin del ATM, en respuesta a la confirmacin de que se encontrun monto equivalente a $50 en efectivo o cheques en el sobre dedepsito. Asumimos que esta ac- tualizacin se realiza a travs de unatransaccin que realiza el empleado del banco mediante el uso de unsistema bancario distinto al del ATM. Por ende, no hablaremos sobreesta transaccin en nues- tro ejemplo prctico]. La claseDispensadorEfectivo tiene un atributo. El documento derequerimientos establece que el dispensador de efectivo empiezacada da cargado con 500 billetes de $20. El dispensador de efec-tivo debe llevar el registro del nmero de billetes que contienepara determinar si hay suficiente efectivo disponible parasatisfacer la demanda de los retiros. Asignamos a la claseDispensadorEfectivo el atri- buto entero conteo, el cual seestablece al principio en 500. Para los verdaderos problemas en laindustria, no existe garanta alguna de que el documento de re-querimientosserlosuficientementerobustoyprecisocomoparaqueeldiseadordesistemasorientadosa objetos determine todos los atributos, o inclusive todas lasclases. La necesidad de clases, atributos y comportamientosadicionales puede irse aclarando a medida que avance el proceso dediseo. A medida que progresemos a travs de este caso de estudio,nosotros tambin seguiremos agregando, modificando y eliminandoinformacin acerca de las clases en nuestro sistema. Modelado de losatributos El diagrama de clases de la figura 12.12 enlista algunosde los atributos para las clases en nuestro siste- ma; las palabrasy frases descriptivas en la figura 12.11 nos llevan a identificarestos atributos. Por cuestin de simpleza, la figura 12.12 nomuestra las asociaciones entre las clases; en la figura 12.10mostramos estas asociaciones. sta es una prctica comn de losdiseadores de sistemas, a la hora de desarrollar los diseos. En laseccin 12.3 vimos que en UML, los atributos de una clase se colocan19. 12.4 Identicacin de los atributos de las clases 487 en elcompartimiento intermedio del rectngulo de la clase. Listamos elnombre de cada atributo y su tipo, separados por un signo de dospuntos (:), seguido en algunos casos de un signo de igual (=) y deun valor inicial. Considere el atributo usuarioAutenticado de laclase ATM: usuarioAutenticado : Boolean = false La declaracin deeste atributo contiene tres piezas de informacin acerca delatributo. El nombre del atributo es usuarioAutenticado. El tipo delatributo es Boolean. En Java, un atributo puede repre- sentarsemediante un tipo primitivo, como boolean, int o double, o por untipo de referencia como una clase. Hemos optado por modelar slo losatributos de tipo primitivo en la figura 12.12; en breve hablaremossobre el razonamiento detrs de esta decisin. Los tipos de losatributos en la figura 12.12 estn en notacin de UML. Asociaremoslos tipos Boolean, Integer y Double en el diagrama de UML con lostipos primitivos boolean, int y double en Java, respectivamente.Fig. 12.12 Clases con atributos. ATM usuarioAutenticado : Boolean =false SolicitudSaldo numeroCuenta : Integer DispensadorEfectivoconteo : Integer = 500 RanuraDeposito Pantalla Teclado RetironumeroCuenta : Integer monto : Double BaseDatosBanco DepositonumeroCuenta : Integer monto : Double Cuenta numeroCuenta : Integernip : Integer saldoDisponible : Double saldoTotal : Double Tambinpodemos indicar un valor inicial para un atributo. El atributousuarioAutenticado en la clase ATM tiene un valor inicial de false.Esto indica que al principio el sistema no considera que el usuarioest autenticado. Si no se especifica un valor inicial para unatributo, slo se muestran su nombre y tipo (separados por dospuntos). Por ejemplo, el atributo numeroCuenta de la claseSolicitudSaldo es un entero. Aqu no mostramos un valor inicial, yaque el valor de este atributo es un nmero que to- 20. 488 Captulo12 Caso de estudio del ATM, Parte 1: Diseo orientado a objetos conUML dava no conocemos. Este nmero se determinar en tiempo deejecucin, con base en el nmero de cuenta introducido por el usuarioactual del ATM. La figura 12.12 no incluye atributos para lasclases Pantalla, Teclado y RanuraDeposito. stos son componentesimportantes de nuestro sistema, para los cuales nuestro proceso dediseo an no ha revelado ningn atributo. No obstante, tal vezdescubramos algunos en las fases restantes de diseo, o cuandoimplementemos estas clases en Java. Esto es perfectamente normal.Observacin de ingeniera de software 12.1 En las primeras fases delproceso de diseo, a menudo las clases carecen de atributos (y ope-raciones).Sinembargo,esasclasesnodebeneliminarse,yaquelosatributos(ylasoperaciones)pueden hacerse evidentes en las fases posteriores de diseo eimplementacin. La figura 12.12 tampoco incluye atributos para laclase BaseDatosBanco. En Java, los atribu- tos pueden representarsemediante los tipos primitivos o los tipos por referencia. Hemosoptado por incluir slo los atributos de tipo primitivo en eldiagrama de clases de la figura 12.12 (y en los diagra- mas declases similares a lo largo del caso de estudio). Un atributo detipo por referencia se modela con ms claridad como una asociacinentre la clase que contiene la referencia y la clase del objeto alque apunta la referencia. Por ejemplo, el diagrama de clases de lafigura 12.10 indica que la clase BaseDatosBanco participa en unarelacin de composicin con cero o ms objetos Cuenta. De estacomposicin podemos determinar que, cuando implementemos el sistemaATM en Java, tendremos que crear un atributo de la claseBaseDatosBanco para almacenar referencias a cero o ms objetosCuenta. De manera similar, podemos determinar los atributos de tipopor referencia de la clase ATM que correspondan a sus relaciones decomposicin con las clases Pantalla, Teclado, Dispensa- dorEfectivoy RanuraDeposito. Estos atributos basados en composiciones seranredundantes si los modelramos en la figura 12.12, ya que lascomposiciones modeladas en la figura 12.10 transmi- ten de antemanoel hecho de que la base de datos contiene informacin acerca de ceroo ms cuentas, y que un ATM est compuesto por una pantalla, unteclado, un dispensador de efectivo y una ranura para depsitos. Porlo general, los desarrolladores de software modelan estasrelaciones de todo/parte como asociaciones de composicin, en vez demodelarlas como atributos requeridos para implemen- tar lasrelaciones. El diagrama de clases de la figura 12.12 proporcionauna base slida para la estructura de nues- tro modelo, pero no estcompleto. En la seccin 12.5 identificaremos los estados y lasactividades de los objetos en el modelo, y en la seccin 12.6identificaremos las operaciones que realizan los objetos. A medidaque presentemos ms acerca de UML y del diseo orientado a objetos,continuaremos refor- zando la estructura de nuestro modelo.Ejercicios de autoevaluacin de la seccin 12.4 12.8 Por lo general,identificamos los atributos de las clases en nuestro sistemamediante el anlisis de en el documento de requerimientos. a) lossustantivos y las frases nominales b) las palabras y frasesdescriptivas c) los verbos y las frases verbales d) todo loanterior. 12.9 Cul de los siguientes no es un atributo de unaeroplano? a) longitud b) envergadura c) volar d) nmero de asientos21. 12.5 Cmo identicar los estados y actividades de los objetos 48912.10 Describa el significado de la siguiente declaracin de unatributo de la clase DispensadorEfectivo en el diagrama de clasesde la figura 12.12: conteo : Integer = 500 12.5 Cmo identificar losestados y actividades de los objetos [Nota: esta seccin se puedeestudiar despus del captulo 5]. En la seccin 12.4 identificamosmuchos de los atributos de las clases necesarios para implementarel sistema ATM, y los agregamos al diagrama de clases de la figura12.12. En esta seccin le mostraremos laformaenqueestosatributosrepresentanelestadodeunobjeto.Identificaremosalgunosestadosclavequepueden ocupar nuestros objetos y hablaremos acerca de cmo cambianlos objetos de estado, en respuesta a los diversos eventos queocurren en el sistema. Tambin hablaremos sobre el flujo de trabajo,o activi- dades, que realizan los objetos en el sistema ATM, ypresentaremos las actividades de los objetos de transaccinSolicitudSaldo y Retiro. Diagramas de mquina de estado Cada objetoen un sistema pasa a travs de una serie de estados. El estadoactual de un objeto se in- dica mediante los valores de losatributos del objeto en cualquier momento dado. Los diagramas demquina de estado (que se conocen comnmente como diagramas deestado) modelan varios estados de un objeto y muestran bajo qucircunstancias el objeto cambia de estado. A diferencia de losdiagramas de clases que presentamos en las secciones anteriores delejemplo prctico, que se en- focaban principalmente en la estructuradel sistema, los diagramas de estado modelan parte delcomportamiento del sistema. La figura 12.13 es un diagrama deestado simple que modela algunos de los estados de un objeto de laclase ATM. UML representa a cada estado en un diagrama de estadocomo un rectngulo redon- deado con el nombre del estado dentro deste. Un crculo relleno con una punta de flecha ( ) de- signa elestado inicial. Recuerde que en el diagrama de clases de la figura12.12 modelamos esta in- formacin de estado como el atributoBoolean de nombre usuarioAutenticado. Este atributo se inicializaen false, o en el estado Usuario no autenticado, de acuerdo con eldiagrama de estado. Fig. 12.13 Diagrama de estado para el objetoATM. Usuario no autenticado Usuario autenticado la base de datosdel banco autentica al usuario el usuario sale del sistema Lasflechas ( ) indican las transiciones entre los estados. Un objetopuede pasar de un estado a otro, en respuesta a los diversoseventos que ocurren en el sistema. El nombre o la descripcin delevento que ocasiona una transicin se escribe cerca de la lnea quecorresponde a esa transicin. Por ejemplo, el objeto ATM cambia delestado Usuario no autenticado al estado Usuario autenticado, unavez que la base de datos autentica al usuario. En el documento derequerimientos vimos que para autenticar a un usuario, la base dedatos compara el nmero de cuenta y el NIP introducidos por elusuario con los de la cuenta correspondiente en la base de datos.Si el usuario ha introducido un n- mero de cuenta vlido y el NIPcorrecto, el objeto ATM pasa al estado Usuario autenticado y cambiasu atributo usuarioAutenticado al valor true. Cuando el usuariosale del sistema al seleccionar la opcin salir del men principal,el objeto ATM regresa al estado Usuario no autenticado. 22. 490Captulo 12 Caso de estudio del ATM, Parte 1: Diseo orientado aobjetos con UML Observacin de ingeniera de software 12.2 Por logeneral, los diseadores de software no crean diagramas de estadoque muestren todos los posibles estados y transiciones de estadospara todos los atributos; simplemente hay de-masiados.Locomnesquelosdiagramasdeestadomuestrenslolosestadosylastransicionesde estado importantes. Diagramas de actividad Al igual que undiagrama de estado, un diagrama de actividad modela los aspectosdel comportamiento de un sistema. A diferencia de un diagrama deestado, un diagrama de actividad modela el flujo de trabajo(secuencia de objetos) de un objeto durante la ejecucin de unprograma. Un diagrama de ac- tividad modela las acciones a realizary en qu orden las realizar el objeto. El diagrama de actividad dela figura 12.14 modela las acciones involucradas en la ejecucin deuna transaccin de solicitud de saldo. Asumimos que ya se hainicializado un objeto SolicitudSaldo y que ya se le ha asignado unnmero de cuenta vlido (el del usuario actual), por lo que el objetosabe qu saldo extraer de la base de datos. El diagrama incluye lasacciones que ocurren despus de que el usuario selecciona la opcinde solicitud de saldo del men principal y antes de que el ATMdevuelva al usuario al men principal; un objeto SolicitudSaldo norealiza ni inicia estas acciones, por lo que no las modelamos aqu.El diagrama empieza extrayendo de la base de datos el saldo de lacuenta. Despus, SolicitudSaldo muestra el saldo en la pantalla.Esta accin completa la ejecucin de la transaccin. Recuerde que he-mos optado por representar el saldo de una cuenta como losatributos saldoDisponible y saldoTotal de la clase Cuenta, por loque las acciones que se modelan en la figura 12.14 hacen referenciaa la ob- tencin y visualizacin de ambos atributos del saldo. Fig.12.14 Diagrama de actividad para un objeto SolicitudSaldo. obtenersaldo de cuenta de la base de datos mostrar saldo en la pantallaUML representa una accin en un diagrama de actividad como un estadode accin, el cual se modela mediante un rectngulo en el que suslados izquierdo y derecho se sustituyen por arcos ha- cia fuera.Cada estado de accin contiene una expresin de accin; por ejemplo,obtener de la base de datos el saldo de la cuenta; eso especificauna accin a realizar. Una flecha ( ) conecta dos es- tados deaccin, con lo cual indica el orden en el que ocurren las accionesrepresentadas por los estados de accin. El crculo relleno (en laparte superior de la figura 12.14) representa el estado inicial dela actividad: el inicio del flujo de trabajo antes de que el objetorealice las acciones modeladas. En este caso, la transaccin primeroejecuta la expresin de accin obtener de la base de datos el saldode la cuenta. Despus, la transaccin muestra ambos saldos en lapantalla. El crculo relleno encerrado en un crculo sin relleno (enla parte inferior de la figura 12.14) representa el estado final:el fin del flujo de trabajo una vez que el objeto realiza lasacciones modeladas. Utilizamos diagramas de actividad 23. 12.5 Cmoidenticar los estados y actividades de los objetos 491 de UML parailustrar el flujo de control para las instrucciones de control quepresentamos en los cap- tulos 4 y 5. La figura 12.15 muestra undiagrama de actividad para una transaccin de retiro. Asumimos queya se ha asignado un nmero de cuenta vlido a un objeto Retiro. Nomodelaremos al usuario selec- Fig. 12.15 Diagrama de actividad parauna transaccin de retiro. [el usuario cancel la transaccin] [elusuario seleccion una cantidad] [monto > saldo disponible][monto = billetesRequeridos ) 29 return true; // hay suficientesbilletes disponibles 30 else 31 return false; // no hay suficientesbilletes disponibles 32 } // fin del mtodohaySuficienteEfectivoDisponible 33 } // fin de la claseDispensadorEfectivo 64. 532 Captulo 13 Caso de estudio del ATM,Parte 2: Implementacin de un diseo orientado a objetos una ranurade depsito. RanuraDeposito no tiene atributos y slo cuenta con unmtodo: seRecibio- Sobre (lneas 8 a 11), el cual indica si se recibiun sobre de depsito. En el documento de requerimientos vimos que elATM permite al usuario hasta dos minutos para insertar un sobre. Laversin actual del mtodo seRecibioSobre slo devuelve true deinmediato (lnea 10), ya que sta es slo una simulacin de software,por lo que asumimos que el usuario insert un so- bre dentro dellmite de tiempo requerido. Si se conectara el hardware de unaranura de depsito real a nuestro sistema, podra implementarse elmtodo seRecibioSobre para esperar un mximo de dos minutos a recibiruna seal del hardware de la ranura de depsito, indicando que endefinitiva el usuario insert un sobre de depsito. Si seRecibioSobrerecibiera dicha seal en un tiempo mximo de dos minutos, el mtododevolvera true. Si transcurrieran los dos minutos y el mtodo norecibiera ninguna seal, entonces devolvera false. 13.4.6 La claseCuenta La clase Cuenta (figura 13.18) representa a una cuentabancaria. Cada Cuenta tiene cuatro atributos (modelados en lafigura 13.10): numeroCuenta, nip, saldoDisponible y saldoTotal. Laslneas 6 a 9 implementan estos atributos como campos private. Lavariable saldoDisponible representa el monto de fondos disponiblespara retirar. La variable saldoTotal representa el monto de fondosdisponibles, junto con el monto de los fondos depositadospendientes de confirmacin o liberacin. Fig. 13.18 La clase Cuentarepresenta a una cuenta bancaria (parte 1 de 2). Fig. 13.17 Laclase RanuraDeposito representa a la ranura de depsito del ATM. 1// RanuraDeposito.java 2 // Representa a la ranura de depsito delATM 3 4 public class RanuraDeposito 5 6 // indica si se recibi elsobre (siempre devuelve true, ya que sta 7 // es slo una simulacinde software de una ranura de depsito real) 8 public booleanseRecibioSobre() 9 10 return true; // se recibi el sobre 11 //fin del mtodo seRecibioSobre 12 // fin de la clase RanuraDeposito1 // Cuenta.java 2 // Representa a una cuenta bancaria 3 4 publicclass Cuenta 5 6 private int numeroCuenta; // nmero de cuenta 7private int nip; // NIP para autenticacin 8 private doublesaldoDisponible; // fondos disponibles para retirar 9 privatedouble saldoTotal; // fondos disponibles + depsitos pendientes 65.13.4 Implementacin del caso de estudio del ATM 533 Fig. 13.18 Laclase Cuenta representa a una cuenta bancaria (parte 2 de 2). 10 11// el constructor de Cuenta inicializa los atributos 12 publicCuenta( int elNumeroDeCuenta, int elNIP, 13 doubleelSaldoDisponible, double elSaldoTotal ) 14 15 numeroCuenta =elNumeroDeCuenta; 16 nip = elNIP; 17 saldoDisponible =elSaldoDisponible; 18 saldoTotal = elSaldoTotal; 19 // fin delconstructor de Cuenta 20 21 // determina si un NIP especificado porel usuario coincide con el NIP en la Cuenta 22 public booleanvalidarNIP( int nipUsuario ) 23 24 if ( nipUsuario == nip ) 25return true; 26 else 27 return false; 28 // fin del mtodovalidarNIP 29 30 // devuelve el saldo disponible 31 public doubleobtenerSaldoDisponible() 32 33 return saldoDisponible; 34 //fin de obtenerSaldoDisponible 35 36 // devuelve el saldo total 37public double obtenerSaldoTotal() 38 39 return saldoTotal; 40 // fin del mtodo obtenerSaldoTotal 41 42 // abona un monto a lacuenta 43 public void abonar( double monto ) 44 45 saldoTotal +=monto; // lo suma al saldo total 46 // fin del mtodo abonar 47 48// carga un monto a la cuenta 49 public void cargar( double monto )50 51 saldoDisponible -= monto; // lo resta del saldo disponible52 saldoTotal -= monto; // lo resta del saldo total 53 // fin delmtodo cargar 54 55 // devuelve el nmero de cuenta 56 public intobtenerNumeroCuenta() 57 58 return numeroCuenta; 59 // fin delmtodo obtenerNumeroCuenta 60 // fin de la clase Cuenta 66. 534Captulo 13 Caso de estudio del ATM, Parte 2: Implementacin de undiseo orientado a objetos La clase Cuenta tiene un constructor(lneas 12 a 19) que recibe como argumentos un nmero de cuenta, elNIP establecido para la cuenta, el saldo disponible inicial y elsaldo total inicial de la cuenta. Las lneas 15 a 18 asignan estosvalores a los atributos de la clase (es decir, los campos). Elmtodo validarNIP (lneas 22 a 28) determina si un NIP especificadopor el usuario (es decir, el parmetro nipUsuario) coincide con elNIP asociado con la cuenta (es decir, el atributo nip). Recuer- deque modelamos el parmetro nipUsuario de este mtodo en la figura12.19. Si los dos NIP coinciden, el mtodo devuelve true (lnea 25);en caso contrario devuelve false (lnea 27). Los mtodosobtenerSaldoDisponible (lneas 31 a 34) y obtenerSaldoTotal (lneas37 a 40) devuelven los valores de los atributos doublesaldoDisponible y saldoTotal, respectivamente. El mtodo abonar(lneas 43 a 46) agrega un monto de dinero (el parmetro monto) a unaCuenta como parte de una transaccin de depsito. Este mtodo agregael monto slo al atributo saldoTotal (lnea 45). El dinero abonado auna cuenta durante un depsito no se vuelve disponible de inmediato,por lo que slo modificamos el saldo total. Supondremos que el bancoactualiza despus el saldo dis- ponible de manera apropiada. Nuestraimplementacin de la clase Cuenta slo incluye los mtodos requeridospara realizar transacciones con el ATM. Por lo tanto, omitiremoslos mtodos que invocaracualquierotrosistemabancarioparasumaralatributosaldoDisponible(confirmarundepsito)orestar del atributo saldoTotal (rechazar undepsito). El mtodo cargar (lneas 49 a 53) resta un monto de dinero(el parmetro monto) de una Cuenta, como parte de una transaccin deretiro. Este mtodo resta el monto tanto del atributosaldoDisponible (lnea 51) como del atributo saldoTotal (lnea 52),debido a que un retiro afecta ambas unidades del saldo de unacuenta. El mtodo obtenerNumeroCuenta (lneas 56 a 59) proporcionaacceso al numeroCuenta de una Cuenta. Incluimos este mtodo ennuestra implementacin de modo que un cliente de la clase (porejemplo, BaseDatosBanco) pueda identificar a una Cuenta especfica.Por ejemplo, BaseDatosBanco contiene muchos objetos Cuenta, y puedeinvocar este mtodo en cada uno de sus objetos Cuenta para localizarel que tenga cierto nmero de cuenta especfico. 13.4.7 La claseBaseDatosBanco La clase BaseDatosBanco (figura 13.19) modela labase de datos del banco con la que el ATM in- teracta para accedera la informacin de la cuenta de un usuario y modificarla. En elcaptulo 28 estu- diaremos el acceso a las bases de datos. Por ahoramodelaremos la base de datos como un arreglo. Un ejercicio en elcaptulo 28 le pedir que vuelva a implementar esta parte del ATM,usando una base de datos real. Fig. 13.19 La clase BaseDatosBancorepresenta a la base de datos de informacin sobre las cuentas delbanco (parte 1 de 3). 1 // BaseDatosBanco.java 2 // Representa a labase de datos de informacin de cuentas bancarias 3 4 public classBaseDatosBanco 5 6 private Cuenta cuentas[]; // arreglo deobjetos Cuenta 7 8 // el constructor sin argumentos deBaseDatosBanco inicializa a cuentas 9 public BaseDatosBanco() 10 67. 13.4 Implementacin del caso de estudio del ATM 535 Fig. 13.19La clase BaseDatosBanco representa a la base de datos de informacinsobre las cuentas del banco (parte 2 de 3). 11 cuentas = newCuenta[ 2 ]; // slo 2 cuentas para probar 12 cuentas[ 0 ] = newCuenta( 12345, 54321, 1000.0, 1200.0 ); 13 cuentas[ 1 ] = newCuenta( 98765, 56789, 200.0, 200.0 ); 14 // fin del constructorsin argumentos de BaseDatosBanco 15 16 // obtiene el objeto Cuentaque contiene el nmero de cuenta especificado 17 private CuentaobtenerCuenta( int numeroCuenta ) 18 19 // itera a travs decuentas, buscando el nmero de cuenta que coincida 20 for ( CuentacuentaActual : cuentas ) 21 22 // devuelve la cuenta actual siencuentra una coincidencia 23 if (cuentaActual.obtenerNumeroCuenta() == numeroCuenta ) 24 returncuentaActual; 25 // fin de for 26 27 return null; // si no seencontr una cuenta que coincida, devuelve null 28 // fin delmtodo obtenerCuenta 29 30 // determina si el nmero de cuenta y elNIP especificados por el usuario coinciden 31 // con los de unacuenta en la base de datos 32 public boolean autenticarUsuario( intnumeroCuentaUsuario, int nipUsuario ) 33 34 // trata de obtenerla cuenta con el nmero de cuenta 35 Cuenta cuentaUsuario =obtenerCuenta( numeroCuentaUsuario ); 36 37 // si la cuenta existe,devuelve el resultado del mtodo validarNIP de Cuenta 38 if (cuentaUsuario != null ) 39 return cuentaUsuario.validarNIP(nipUsuario ); 40 else 41 return false; // no se encontr el nmero decuenta, por lo que devuelve false 42 // fin del mtodoautenticarUsuario 43 44 // devuelve el saldo disponible de laCuenta con el nmero de cuenta especificado 45 public doubleobtenerSaldoDisponible( int numeroCuentaUsuario ) 46 47 returnobtenerCuenta( numeroCuentaUsuario ).obtenerSaldoDisponible(); 48 // fin del mtodo obtenerSaldoDisponible 49 50 // devuelve el saldototal de la Cuenta con el nmero de cuenta especificado 51 publicdouble obtenerSaldoTotal( int numeroCuentaUsuario ) 52 53 returnobtenerCuenta( numeroCuentaUsuario ).obtenerSaldoTotal(); 54 //fin del mtodo obtenerSaldoTotal 55 56 // abona un monto a la Cuentaa travs del nmero de cuenta especificado 57 public void abonar( intnumeroCuentaUsuario, double monto ) 58 59 obtenerCuenta(numeroCuentaUsuario ).abonar( monto ); 60 // fin del mtodo abonar61 68. 536 Captulo 13 Caso de estudio del ATM, Parte 2:Implementacin de un diseo orientado a objetos Determinamos unatributo de tipo referencia para la clase BaseDatosBanco con baseen su rela- cin de composicin con la clase Cuenta. En la figura13.9 vimos que una BaseDatosBanco est compuesta de cero o msobjetos de la clase Cuenta. La lnea 6 implementa el atributocuentas (un arreglo de objetos Cuenta) para implementar estarelacin de composicin. La clase BaseDatos- Banco tiene unconstructor sin argumentos (lneas 9 a 14) que inicializa cuentaspara que contenga un conjunto de nuevos objetos Cuenta. A fin deprobar el sistema, declaramos cuentas de modo que contenga slo doselementos en el arreglo (lnea 11), que instanciamos como nuevosobjetos Cuenta con datos de prueba (lneas 12 y 13). El constructorde Cuenta tiene cuatro parmetros: el nmero de cuenta, el NIPasignado a la cuenta, el saldo disponible inicial y el saldo totalinicial. Recuerde que la clase BaseDatosBanco sirve comointermediario entre la clase ATM y los mismos obje- tos Cuenta quecontienen la informacin sobre la cuenta de un usuario. Por ende,los mtodos de la clase BaseDatosBanco no hacen ms que invocar a losmtodos correspondientes del objeto Cuenta que pertenece al usuarioactual del ATM. Incluimos el mtodo private utilitario obtenerCuenta(lneas 17 a 28) para permitir que la BaseDatosBanco obtenga unareferencia a una Cuenta especfica dentro del arreglo cuentas. Paralocali- zar la Cuenta del usuario, la BaseDatosBanco compara elvalor devuelto por el mtodo obtenerNumero- Cuenta para cadaelemento de cuentas con un nmero de cuenta especfico, hastaencontrar una coincidencia. Las lneas 20 a 25 recorren el arreglocuentas. Si el nmero de cuenta de cuentaActual es igual al valordel parmetro numeroCuenta, el mtodo devuelve de inmediato lacuentaActual. Si ninguna cuenta tiene el nmero de cuenta dado,entonces la lnea 27 devuelve null. El mtodo autenticarUsuario(lneas 32 a 42) aprueba o desaprueba la identidad de un usuario delATM. Este mtodo recibe un nmero de cuenta y un NIP especificadospor el usuario como argu- mentos, e indica si coinciden con elnmero de cuenta y NIP de una Cuenta en la base de datos. La lnea 35llama al mtodo obtenerCuenta, el cual devuelve una Cuenta connumeroCuentaUsuario como su nmero de cuenta, o null para indicarque el numeroCuentaUsuario es invlido. Si obte- nerCuenta devuelveun objeto Cuenta, la lnea 39 regresa el valor boolean devuelto porel mtodo validarNIP de ese objeto. El mtodo autenticarUsuario deBaseDatosBanco no realiza la compara- cin de NIP por s solo, sinoque enva nipUsuario al mtodo validarNIP del objeto Cuenta para quelo haga. El valor devuelto por el mtodo validarNIP de Cuenta indicasi el NIP especificado por el usuario coincide con el NIP de laCuenta del usuario, por lo que el mtodo autenticarUsuariosimplemente devuelve este valor al cliente de la clase (es decir,el ATM). BaseDatosBanco confa en que el ATM invoque al mtodoautenticarUsuario y reciba un valor de retorno true antes depermitir que el usuario realice transacciones. BaseDatosBancotambin confa que cada objeto Transaccion creado por el ATM contendrel nmero de cuenta vlido del usuario actual autenticado, y que steser el nmero de cuenta que se pase al resto de los mtodos deBaseDatosBanco como el argumento numeroCuentaUsuario. Por lo tanto,los mtodos obtener- SaldoDisponible (lneas 45 a 48),obtenerSaldoTotal (lneas 51 a 54), abonar (lneas 57 a 60) y cargar(lneas 63 a 66) tan slo obtienen el objeto Cuenta del usuario conel mtodo utilitario obte- Fig. 13.19 La clase BaseDatosBancorepresenta a la base de datos de informacin sobre las cuentas delbanco (parte 3 de 3). 62 // carga un monto a la Cuenta con el nmerode cuenta especificado 63 public void cargar( intnumeroCuentaUsuario, double monto ) 64 65 obtenerCuenta(numeroCuentaUsuario ).cargar( monto ); 66 // fin del mtodo cargar67 // fin de la clase BaseDatosBanco 69. 13.4 Implementacin delcaso de estudio del ATM 537 nerCuenta, y despus invocan al mtodo deCuenta apropiado con base en ese objeto. Sabemos que las llamadas aobtenerCuenta desde estos mtodos nunca devolvern null, puesto quenumero- CuentaUsuario se debe referir a una Cuenta existente. Losmtodos obtenerSaldoDisponible y obtenerSaldoTotal devuelven losvalores que regresan los correspondientes mtodos de Cuenta. Adems,abonar y cargar simplemente redirigen el parmetro monto a losmtodos de Cuenta que invocan. 13.4.8 La clase Transaccion La claseTransaccion (figura 13.20) es una superclase abstracta querepresenta la nocin de una trans- accin con el ATM. Contiene lascaractersticas comunes de las subclases SolicitudSaldo, Retiro yDeposito. Esta clase se expande a partir del cdigo estructural quese desarroll por primera vez en la seccin 13.3. La lnea 4 declaraesta clase como abstract. Las lneas 6 a 8 declaran los atribu- tosprivate de las clases. En el diagrama de clases de la figura 13.10vimos que la clase Transaccion contiene un atributo llamadonumeroCuenta (lnea 6), el cual indica la cuenta involucrada en laTransaccion. Luego derivamos los atributos de Pantalla (lnea 7) yde BaseDatosBanco (lnea8) de la clase Transaccion asociada y que semodela en la figura 13.9. Todas las transacciones requieren accesoa la pantalla del ATM y a la base de datos del banco. Fig. 13.20 Lasuperclase abstracta Transaccion representa una transaccin con elATM (parte 1 de 2). 1 // Transaccion.java 2 // La superclaseabstracta Transaccion representa una transaccin con el ATM 3 4public abstract class Transaccion 5 6 private int numeroCuenta;// indica la cuenta implicada 7 private Pantalla pantalla; //pantalla del ATM 8 private BaseDatosBanco baseDatosBanco; // basede datos de informacin de cuentas 9 10 // el constructor deTransaccion es invocado por las subclases mediante super() 11public Transaccion( int numeroCuentaUsuario, Pantalla pantallaATM,12 BaseDatosBanco baseDatosBancoATM ) 13 14 numeroCuenta =numeroCuentaUsuario; 15 pantalla = pantallaATM; 16 baseDatosBanco =baseDatosBancoATM; 17 // fin del constructor de Transaccion 18 19// devuelve el nmero de cuenta 20 public int obtenerNumeroCuenta()21 22 return numeroCuenta; 23 // fin del mtodoobtenerNumeroCuenta 24 25 // devuelve una referencia a la pantalla26 public Pantalla obtenerPantalla() 27 28 return pantalla; 29 // fin del mtodo obtenerPantalla 30 70. 538 Captulo 13 Caso deestudio del ATM, Parte 2: Implementacin de un diseo orientado aobjetos La clase Transaccion tiene un constructor (lneas 11 a 17)que recibe como argumentos el nmero de cuenta del usuario actual yreferencias tanto a la pantalla del ATM como a la base de datos delbanco. Puesto que Transaccion es una clase abstracta, esteconstructor se llama slo a travs de los constructores de lassubclases de Transaccion. La clase tiene tres mtodos obtenerpblicos: obtenerNumeroCuenta (lneas 20 a 23), obtener- Pantalla(lneas 26 a 29) y obtenerBaseDatosBanco (lneas 32 a 35). Estosmtodos son heredados por las subclases de Transaccion y se utilizanpara obtener acceso a los atributos private de esta clase. La claseTransaccion tambin declara el mtodo abstract ejecutar (lnea 38). Notiene caso proveer la implementacin de este mtodo, ya que unatransaccin genrica no se puede ejecutar. Por ende, declaramos estemtodo como abstract y forzamos a cada subclase de Transaccion apro- veer una implementacin concreta que ejecute este tipoespecfico de transaccin. 13.4.9 La clase SolicitudSaldo La claseSolicitudSaldo (figura 13.21) extiende a Transaccion y representauna transaccin de solici- tud de saldo con el ATM. SolicitudSaldono tiene atributos propios, pero hereda los atributos numero-Cuenta, pantalla y baseDatosBanco de Transaccion, a los cuales sepuede acceder por medio de los mtodos public obtener deTransaccion. El constructor de SolicitudSaldo recibe los argumentoscorrespondientes a estos atributos, y lo nico que hace esreenviarlos al constructor de Transaccion mediante el uso de super(lnea 10). 31 // devuelve una referencia a la base de datos delbanco 32 public BaseDatosBanco obtenerBaseDatosBanco() 33 34return baseDatosBanco; 35 // fin del mtodo obtenerBaseDatosBanco36 37 // realiza la transaccin (cada subclase sobrescribe estemtodo) 38 abstract public void ejecutar(); 39 // fin de la claseTransaccion Fig. 13.20 La superclase abstracta Transaccionrepresenta una transaccin con el ATM (parte 2 de 2). Fig. 13.21 Laclase SolicitudSaldo representa a una transaccin de solicitud desaldo en el ATM (parte 1 de 2). 1 // SolicitudSaldo.java 2 //Representa una transaccin de solicitud de saldo en el ATM 3 4public class SolicitudSaldo extends Transaccion 5 { 6 //constructor de SolicitudSaldo 7 public SolicitudSaldo( intnumeroCuentaUsuario, Pantalla pantallaATM, 8 BaseDatosBancobaseDatosBanco ) 9 10 super( numeroCuentaUsuario, pantallaATM,baseDatosBanco ); 11 // fin del constructor de SolicitudSaldo 1213 // realiza la transaccin 14 @Override 15 public void ejecutar()16 { 71. 13.4 Implementacin del caso de estudio del ATM 539 Laclase SolicitudSaldo sobrescribe el mtodo abstracto ejecutar deTransaccin para pro- veer una implementacin discreta (lneas 14 a36) que realiza los pasos involucrados en una solicitud de saldo.Las lneas 18 a 19 obtienen referencias a la base de datos del bancoy la pantalla del ATM, al invocar a los mtodos heredados de lasuperclase Transaccion. Las lneas 22 y 23 obtienen el saldodisponible de la cuenta implicada, mediante una invocacin al mtodoobtenerSaldoDisponible de baseDatosBanco. La lnea 23 usa el mtodoheredado obtenerNumeroCuenta para obtener el n- mero de cuenta delusuario actual, que despus pasa a obtenerSaldoDisponible. Las lneas26 y 27 obtienen el saldo total de la cuenta del usuario actual.Las lneas 30 a 35 muestran la informacin del saldo en la pantalladel ATM. Recuerde que mostrarMontoDolares recibe un argumentodouble y lo imprime en la pantalla, con formato de monto en dlares.Por ejemplo, si el saldoDisponible de un usuario es 1000.5, la lnea32 imprime $1,000.50. La lnea 35 inserta una lnea en blanco desalida para separar la informacin del saldo de la salidasubsiguiente (es decir, el men principal repetido por la clase ATMdespus de ejecutar la SolicitudSaldo). 13.4.10 La clase Retiro Laclase Retiro (figura 13.22) extiende a Transaccion y representa unatransaccin de retiro del ATM. Esta clase se expande a partir delcdigo estructural para la misma, desarrollado en la figura 13.12.En el diagrama de clases de la figura 13.10 vimos que la claseRetiro tiene un atributo, monto, que la lnea 6 implementa comocampo int. La figura 13.9 modela las asociaciones entre la claseRetiro y las clases Teclado y DispensadorEfectivo, para las que laslneas 7 y 8 implementan los atributos de tipo referencia teclado ydispensadorEfectivo, respectivamente. La lnea 11 de- clara unaconstante que corresponde a la opcin de cancelacin en el men.Pronto veremos cmo es que la clase utiliza esta constante. Fig.13.21 La clase SolicitudSal
Como Programar En Java Deitel 7 Edicion Pdf
Download File: https://placbocepe.blogspot.com/?ol=2vDIU9
2ff7e9595c
Comments