Como Programar En Java Deitel 7 Edicion Pdf !!BETTER!!

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 procesorob