TrabajoFinal V4

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD
PROGRAMACION ORIENTADA A OBJETOS_301403_30

TRABAJO FINAL
Fase 9:
Proyecto Final de Investigacin Orientado a Objetos
Integrantes
LUIS EDUARDO URRESTE MELO
LUIS ALBERTO JARAMILLO GONZALEZ
JOSE RAMON VALENCIA
RONALD EDUARDO MURILLO GONZLEZ
Tutor:
Cesar Jimnez

Escuela de Ciencias Bsicas, Tecnologa e Ingeniera
PROGRAMACION ORIENTADA A OBJETOS
2016
1
TRABAJO FINAL
Tabla de Contenidos
introduccion................................................................................................................. 4
objetivos generales ...................................................... Error! Marcador no definido.
objetivos especificos .................................................... Error! Marcador no definido.
justificacion ................................................................................................................. 6
marco conceptual y metodologico............................................................................... 7
fase 3: modelo de requisitos y modelo de anlisis orientado a objetos ...................... 8
6. Modelo de Requisitos Orientado a Objetos ........................................................ 8
6.1. Descripcin del Problema................................................................................. 8
6.2. Modelo de casos de uso................................................................................... 9
6.3. Modelo de Interfaces ...................................................................................... 11
6.4. ACTORES Y CASOS DE USO ...................................................................... 16
6.5. Modelo del dominio del problema ................................................................. 189
6.6. Arquitectura de Clases ................................................................................... 20
7. Modelo de Anlisis Orientada a Objetos....................................................... 1920
Identificacin de Clases segn Estereotipos ......................................................... 20
Borde ..................................................................................................................... 20
Diccionario de Clases ............................................................................................ 25
Diagrama de secuencias ....................................................................................... 25
Diccionario de Clases .......................................................................................... 337
fase 5: modelo de diseo orientado a objetos........................................................... 28
8.1. ESTRATEGIAS DEL DISEO DEL PROYECTO ............................................. 28
8.1.1. Arquitectura ................................................................................................. 28
8.1.2 Robustez ...................................................................................................... 29
8.2. Diseo de Objetos ........................................................................................... 30
8.3. Diseo de Sistema de su proyecto ................................................................. 34
8.3.1. Mtodo Usuario ........................................................................................... 34
8.3.2. Mtodo Uso Tarjeta Dbito .......................................................................... 34
8.3.3. Mtodo Uso Tarjeta credito ......................................................................... 35
8.4. Revisin del Diseo de su proyecto............................................................... 37
8.4.1. Revisin del Diseo .................................................................................... 38
8.5. Diagramas de Secuencias del Diseo de su proyecto ................................. 39
8.5.1. Secuencia para validar los datos del usuario .............................................. 39
8.5.2 Diagrama de secuencias para cuando la contrasea est errada ................ 39
2
TRABAJO FINAL
8.5.3. Secuencia correcta del usuario en el cajero. ............................................... 40

8.5.4. Diagrama de secuencias para cuando no hay fondos en la cuenta ............ 40
fase 7: modelo de implementacin y modelo de prueba orientado a objetos ... 41
Captulo 9: Modelo de Implementacin................................................................. 41
9.1. Programacin en Java de su proyecto de Investigacin .................................... 41
9.2. Diagrama de Clases de su proyecto de Investigacin ....................................... 41
9.2.1 Interface Usuario .............................................................................................. 42
9.2.2 Principal ........................................................................................................... 42
9.2.3 Dominio ............................................................................................................ 43
9.2.4 Registro............................................................................................................ 43
9.2.5 Servicios .......................................................................................................... 45
Captulo 10: Modelo de Pruebas............................................................................... 45
10.1. Definicin de Conceptos de su proyecto de Investigacin ............................... 45
10.2. Tipos de Pruebas de su proyecto de Investigacin .......................................... 45
10.2.1 Tcnicas de pruebas ...................................................................................... 46
10.2.2 Nivel de pruebas ............................................................................................ 47
10.3. Proceso de Pruebas de su proyecto de Investigacin ..................................... 48
10.3.1 Estrategia de prueba ...................................................................................... 48
10.3.2 Planeacin de la prueba ................................................................................ 49
10.3.3 Construccin de la prueba ............................................................................. 49
10.3.4 Ejecucin de la prueba................................................................................... 49
10.4. Pruebas del Sistema de su proyecto de investigacin ..................................... 50
10.4.1 Registrar Usuario ........................................................................................... 50
10.4.2 Registrar tarjeta ............................................................................................. 50
conclusiones ........................................................................................................... 52
referencias bibliograficas....................................................................................... 53
3
TRABAJO FINAL
INTRODUCCION
La interconexin entre aplicaciones javas y bases de datos constituye quiz un referente muy
importante dentro de la programacin orientada a objetos. Es por ello que en la siguiente entrega se
revisaran aquellos aspectos direccionados al trabajo e interaccin entre nuestro programa y una
base de datos realizada en Microsoft Acces.
Por lo tanto se encontrara aquellas definiciones encaminadas a la resolucin de los aspectos
relevantes en el proyecto de Software para Cajeros electrnicos, que constituye el proyecto objetivo
de ste curso acadmico.
En la historia de la informtica se han desarrollado diversos lenguajes de programacin que han ido
evolucionando a medida que la tecnologa de los sistemas de cmputo avanza. Pero no solo los
lenguajes de programacin han avanzado sino tambin la tcnica para realizar programas ms
rpidos, eficientes y menos complejos, es por esto que muchos desarrolladores y programadores
han adoptado paradigmas de programacin que les permitan representar y abstraer los elementos
involucrados en un sistema. Uno de los paradigmas ms utilizados actualmente es la programacin
orientada a objetos en el cual el ncleo central es la unin de datos y procesamiento en un unidad
llamada Objeto relacionable a su vez con otras entidades Objeto. En este documento se pretende
dar solucin a un problema implementando un lenguaje sencillo como UML, para representar cada
uno de los actores y casos de uso asociados, los cuales servirn de base para definir las clases.
Por otro lado, disearemos la estrategia de diseo que permitir construir la arquitectura de nuestro
proyecto y desarrollar los diagramas de secuencias que ilustraran la forma en que los objetos que
interactuaran con el sistema. Tambin se har una revisin del diseo del proyecto para evaluar la
forma en que el usuario ingresa y se valida en el sistema, y verificar el manejo de las clases entidad
en relacin con las clases borde.
4
TRABAJO FINAL
OBJETIVO GENERAL
El objetivo general del desarrollo de la presente actividad colaborativa es realizar el anlisis y

solucin del problema planteado al inicio del curso, danto respuesta utilizando la
Programacin Orientada a Objetos, diseando casos de uso, diagramas, flujos, clases,
objetos, propiedades e interfaces para el desarrollo de un aplicativo funcional que de solucin
integral a todos los problemas y requisitos planteados al inicio.
OBJETIVOS ESPECIFICOS
Definir un problema informtico solucionable dentro del paradigma de la programacin

orientada a objetos.
Utilizar herramientas de modelado como UML para representar el problema.
Disear un modelo de interfaces para representar un prototipo de la solucin.
Identificar las clases inherentes al problema.
Disear las estrategias de diseo del proyecto.
Identificar los objetos del Proyecto.
Aprender a disear el sistema que permitir la implementacin del cajero automtico.
Comprender la importancia de la revisin del diseo del sistema.
Desarrollar los diagramas de secuencia que mostrarn la interaccin entre los objetos del
sistema.
Obtener modelo de implementacin.
Ejecutar modelos de prueba.
Interconectar bases de datos a java.
Crear, modificar y eliminar informacin en la base de datos.
5
TRABAJO FINAL
JUSTIFICACION
En este trabajo debemos aprender una forma de organizar cdigo y datos que aseguren el control
sobre la complejidad del proceso de desarrollo de software haciendo los programas ms eficientes,
donde los objetos son tipos de datos abstractos definidos por nosotros los programadores, pero
donde la potencia real de los objetos reside en las propiedades que soportan herencia,
encapsulamiento y polimorfismo junto con los conceptos de objetos, clases y mtodos, lenguaje que
debe manejar con propiedad un ingeniero de Sistemas o afines.
En el trabajo Un paradigma proactivo orientado a objetos se propone crear un modelo que exponga
la creacin de sistemas proactivos en funcin de mensajes de activacin. Esto permite que el modelo
sea robusto, incremental, evolutivo e independiente de una jerarqua implcita y obligada en la parte
del diseo.
El principal problema al que se enfrenta un diseador informtico es el de modelar un sistema. Esta

actividad por lo regular representa una transferencia de actividades proactivas a un esquema basado
en una secuencia de procesos y durante el anlisis, el esquema es interpretado por una mquina o
autmata en particular. Posteriormente, en el ciclo de desarrollo los costos aumentan principalmente
por la reingeniera de procesos. Esto es debido a que, el diseador deber conocer los aspectos
importantes de la programacin y del modelo para modificar o adecuarlo a los nuevos
requerimientos.
Hay que recordar que uno de los objetivos principales de la programacin orientada a objetos es el
de la reutilizacin del cdigo, que en este caso son los objetos. Realizar una reingeniera de
procesos no es una tarea simple y en ocasiones es preferible rehacer el mdulo al momento en que
el diseo no es claro.
6
TRABAJO FINAL
FASE 3: MODELO DE REQUISITOS Y MODELO DE ANLISIS ORIENTADO A OBJETOS
6. Modelo de Requisitos Orientado a Objetos
6.1. Descripcin del Problema

La entidad financiera PobreBank S.A necesita implementar un software en sus Cajeros Automticos
que les permita a sus usuarios realizar las siguientes operaciones:
Consulta de saldo en pantalla de su cuenta de ahorros PobreBank.
Retiro de dinero de su cuenta de ahorros PobreBank.
Realizar avances de su tarjeta de crdito Visa PobreBank.
Cambiar la clave de su tarjeta debito Visa Pobrebank.
Bloqueo de tarjeta dbito o crdito por intentos fallidos de clave secreta.
Requisitos:
El cliente debe identificarse en el cajero automtico a travs del chip de su tarjeta dbito o
crdito Visa PobreBank, despus de seleccionar la transaccin que desea realizar.
El cliente debe escoger una de las operaciones listadas anteriormente dentro de un lmite de
tiempo de 30 segundos, de lo contrario la transaccin se cancela automticamente.
Despus de seleccionar cualquiera de las operaciones, el sistema debe pedir la clave secreta
asociada a su tarjeta de crdito o dbito, y si la clave es ingresada errneamente ms de 4
veces, la transaccin es cancelada y el ID del chip de la tarjeta es bloqueada.
El cliente debe poder cancelar la operacin en cualquier momento.
La tarjeta dbito o crdito debe ser retenida por el cajero automtico hasta el final de la
transaccin o despus de un cancelamiento en cualquier punto de la operacin.
6.1.1. ACTORES
Los actores que utilizaran el sistema son:
Clientes.
Hardware Cajero Automtico
Administrador de la base de datos.
Cajero Automtico.
Base de datos registro clientes.
Base de datos Tarjeta dbito y crdito.
Base de datos cuentas de ahorro.
7
TRABAJO FINAL
6.1.2. CASOS DE USO

Consulta de saldo en pantalla de su cuenta de ahorros PobreBank.
Retiro de dinero de una cuenta de ahorros PobreBank.
Realizar avances de una tarjeta de crdito Visa PobreBank.
Cambiar la clave de una tarjeta debito Visa Pobrebank.
6.2. MODELO DE CASOS DE USO
6.2.1 ACTORES
Figura 1. Delimitacin del sistema segn actores externos
8
TRABAJO FINAL
6.2.2 CASOS DE USO
Figura 2. Delimitacin del Sistema segn actores internos y externos con herencia ente
actores
9
TRABAJO FINAL
Figura 3. Principales Casos de Uso para el sistema de cmputo del cajero automtico.
Figura 4. Diagrama de Usos completo
6.3. Modelo de Interfaces
Caso de Uso: Consultar Saldo
10
TRABAJO FINAL
11
TRABAJO FINAL
Caso de Uso: Retirar Dinero
12
TRABAJO FINAL
Caso de Uso: Retirar avance Tarjeta de crdito
13
TRABAJO FINAL
Caso de Uso: Cambiar Clave
14
TRABAJO FINAL
6.4. ACTORES Y CASOS DE USO
6.4.1. Actores:
Actor Cliente
Caso de Uso Consultar saldo, Retirar Dinero, Retirar avance T. Crdito,
Cambiar clave, Validar cliente
Tipo Primario
Descripcin Es el actor principal y representa cualquier persona que
desee utilizar el sistema de cmputo del cajero automtico
Actor Base de Datos Cuenta de Ahorros

Caso de Uso Consultar saldo, Desplegar saldo, Pagar dinero Debito,
Retirar dinero, validar cliente
Tipo Secundario
Descripcin Es un actor secundario y representa la base de datos
donde se guarda toda la informacin relacionada con el
registro de datos personales de los clientes y sus cuentas
de ahorro
Actor Base de Datos Tarjeta Dbito y Crdito

Caso de Uso Retirar Avance Tarjeta crdito, Pagar Dinero Crdito,
Cambiar clave, Ingresar nueva clave, validar cliente.
Tipo Secundario
Descripcin Es un actor secundario y representa la base de datos
donde se guarda toda la informacin relacionada con las
tarjetas dbito y crdito.
6.4.2. Casos de uso:
Caso de Uso Consultar Saldo
Actores Cliente, Base de Datos Cuenta de Ahorros.
Tipo Bsico
Propsito Permite a un usuario iniciar el proceso de consultar el
saldo de su cuenta de ahorros.
Resumen El Cliente inicia este caso de uso y despus de la
validacin de la clave, la base de datos debe suministrar la
informacin del saldo de la cuenta de ahorros el cual se
desplegar en pantalla.
Precondiciones Se necesita que el hardware del cajero automtico valide
el chip de la tarjeta ingresada.
Flujo Principal Se ejecuta el caso de uso Validar Cliente el cual pide la
clave de la tarjeta para continuar.
Subflujos
Excepciones
15
TRABAJO FINAL
Caso de Uso Retirar Dinero

Actores Cliente, Base de Datos Cuenta de Ahorros.
Tipo Bsico
Propsito Permite a un usuario iniciar el proceso de retirar dinero de
su cuenta de ahorros
informacin del saldo de la cuenta de ahorros para
comparar con el monto solicitado.
Subflujos
Excepciones
Caso de Uso Retirar Avance Tarjeta de Crdito

Actores Cliente, Base de Datos Tarjeta dbito y crdito.
Tipo Bsico
Propsito Permite a un usuario iniciar el proceso de retirar un avance
de dinero de la tarjeta de crdito.
informacin del cupo disponible de la tarjeta de crdito
para los avances.
Subflujos
Excepciones
Caso de Uso Cambiar clave

Tipo Bsico
Propsito Permite a un usuario iniciar el proceso de cambio de clave
de la tarjeta dbito o crdito
validacin de la clave, la base de datos debe permitir el
ingreso de una nueva clave para la tarjeta.
Subflujos
Excepciones
16
TRABAJO FINAL
Caso de Uso Desplegar Saldo

Tipo Extensin
Propsito Permite a un usuario visualizar en pantalla el estado actual
de su cuenta de ahorros
Resumen El caso de uso Base de Datos Cuenta de Ahorros debe
suministrar informacin del saldo del cliente y luego
desplegarlo en la pantalla del cajero automtico.
Precondiciones
Flujo Principal
Subflujos
Excepciones
Caso de Uso Pagar Dinero Debito

Actores Cliente, Base de Datos Cuenta de Ahorros, Hardware
Cajero Automtico
Tipo Extensin
Propsito Permite a un cliente retirar dinero del cajero automtico
Resumen El caso de uso Base de Datos Cuenta de Ahorros debe
autorizar al hardware del cajero automtico para entregar
el dinero solicitado por el cliente.
Precondiciones El cliente debe tener fondos suficientes en su cuenta de
ahorros
Flujo Principal
Subflujos
Excepciones Si el cliente no tiene fondos suficientes debe desplegar un
mensaje diciendo No Posee Fondos Suficientes y debe
finalizar la transaccin.
Caso de Uso Pagar Dinero Crdito

Actores Base de Datos Cuenta de Ahorros, Hardware Cajero
Automtico
Tipo Extensin
Propsito Permite a un cliente retirar dinero del cajero automtico
Resumen El caso de uso Base de Datos Tarjeta Dbito y Crdito
debe autorizar al hardware del cajero automtico para
entregar el dinero solicitado por el cliente.
Precondiciones El cliente debe tener cupo disponible para avances
Flujo Principal
Subflujos
Excepciones Si el cliente no tiene cupo disponible para avances debe
desplegar en pantalla un mensaje diciendo No tiene cupo
disponible para este avance y debe finalizar la
transaccin.
17
TRABAJO FINAL
Caso de Uso Ingresar nueva clave

Tipo Extensin
Propsito Permite a un usuario ingresar una nueva clave de la tarjeta
dbito o crdito
Resumen El caso de uso Base de Datos Tarjeta Dbito y Crdito
debe autorizar el ingreso de la nueva clave de 4 dgitos.
Precondiciones Se necesita autorizacin de la base de datos para ingresar
la nueva clave.
Flujo Principal
Subflujos
Excepciones Si el cliente ingresa la misma clave que tena
anteriormente, entonces debe desplegar una mensaje en
pantalla diciendo Por favor ingrese una clave diferente
6.5. Modelo del dominio del problema
18
TRABAJO FINAL
6.6. Arquitectura de Clases
7. MODELO DE ANLISIS ORIENTADA A OBJETOS
Identificacin de Clases segn Estereotipos
Borde
Clases Borde Para la Implementacin de Software en Cajeros Automticos de PobreBank,
identificados directamente con los actores:
19
TRABAJO FINAL
Clases Borde identificadas del caso de uso Consultar Saldo:
Clases Borde identificadas del caso de uso Retirar Dinero:
Clases Borde identificadas del caso de uso Retirar Avance Tarjeta de Crdito:
20
TRABAJO FINAL
Clases Borde identificadas del caso de uso Cambiar Clave:
Clases Borde identificadas del caso de uso Desplegar Saldo:
Clases Borde identificadas del caso de uso Pagar Dinero Debito:
21
TRABAJO FINAL
Clases Borde identificadas del caso de uso Pagar Dinero Crdito:
Clases Borde identificadas del caso de uso Ingresar Clave Nueva:
Relacin entre Casos de Uso, Actores y Clases Borde. Software Cajeros Automticos
PobreBank
Casos de Uso Actores Clases Borde

Consultar Saldo Cliente, Hardware Cajero InterfaceCliente,
Automtico, Base de Datos
InterfaceHardwareCajeroAutomatico,
Cuentas Ahorro
PantallaServicios
PantallaValidarCliente
InterfaceBaseDatosCuentasAhorro
Retirar Dinero Cliente, Hardware Cajero InterfaceCliente,

Cuentas Ahorro
PantallaMontoRetirar,
PantallaFinTransaccin
Retirar Avance Tarjeta de Cliente, Hardware Cajero InterfaceCliente,

Crdito Automtico, Base de Datos
Tarjeta Crdito o Debito
22
TRABAJO FINAL
InterfaceBaseDatosTarjetaCreditoDebito
PantallaMontoRetirar,
Cambiar Clave Cliente, Hardware Cajero InterfaceCliente,

PantallaServicios
,PantallaValidarCliente
PantallaNuevaClave,
Desplegar Saldo Cliente, Base de Datos InterfaceCliente,

Cuentas de Ahorro
InterfaceBaseDatosCuentasAhorro,
Pagar Dinero Debito Cliente, Hardware Cajero InterfaceCliente,

Cuentas de Ahorro
Pagar Dinero Crdito Cliente, Hardware Cajero InterfaceCliente,

Ingresar Clave Nueva Cliente, Base de Datos InterfaceCliente,

Tarjeta Crdito o Debito InterfaceBaseDatosTarjetaCreditoDebito
7.2.2 Entidad
Consultar saldo:
Requiere validar informacin guardada en la base de datos cuentas de ahorro, as como tambin
validacin de usuario a travs del chip y la clave de la tarjeta debito guardado en el registro del
cliente.
23
TRABAJO FINAL
Retirar Dinero:
Sigue el mismo proceso de la consulta de saldo, para lo cual utiliza las mismas clases entidad.
Retirar Avance Tarjeta de Crdito:
Requiere validar informacin guardada en la base de datos tarjeta crdito dbito, as como tambin validacin de usuario a travs
del chip y la clave de la tarjeta debito guardado en el registro del cliente. Aplican la clase entidad RegistroCliente.
Cambiar Clave:
Requiere de informacin guardada el registro del cliente as como tambin la clave asociada a las tarjetas dbito o crdito, por lo
tanto comparte las clases entidad IDChipTarjetaCredito, IDTarjetaDebito, ClaveDebitoCliente, ClaveCreditoClinete:
Desplegar Saldo:
Sigue el mismo proceso de la consulta de saldo, para lo cual utiliza las mismas clases entidad.
24
TRABAJO FINAL
Relacin entre Casos de Uso y Clases Entidad. Software Cajeros Automticos PobreBank
Casos de Uso Clases Entidad
Consultar Saldo CuentaAhorrosCliente, IDChipTarjetaDebito,

ClaveDebitoCliente, RegistroCliente
Retirar Dinero CuentaAhorrosCliente, IDChipTarjetaDebito,

Retirar Avance Tarjeta de CuentaCreditoCliente, IDChipTarjetaCredito,

Crdito ClaveCreditoCliente, RegistroCliente
Cambiar Clave RegistroCliente
Desplegar Saldo CuentaAhorrosCliente, IDChipTarjetaDebito,

7.2.3 Control
Consultar saldo
Retirar dinero
Retirar avance tarjeta de crdito
25
TRABAJO FINAL
Cambiar clave
Desplegar saldo
Pagar dinero debito
Pagar dinero crdito
Ingresar clave nueva
26
TRABAJO FINAL
Controlador General
Relacin entre Casos de Uso y Clases Control. Software Cajeros Automticos PobreBank
Casos de Uso Clases Control
Consultar Saldo ControladorSaldo
Retirar Dinero ControladorRetiro
Retirar Avance Tarjeta de ControladorAvance

Crdito
Cambiar Clave ControladorCambioClave
Desplegar Saldo ControladorDespliegueSaldo
Pagar Dinero Debito ControladorPagoDebito
Pagar Dinero Crdito ControladorPagoCredito
Ingresar Clave Nueva ControladorClaveNueva
ControladorGeneral
27
TRABAJO FINAL
7.3. Clases segn Casos de Uso
Consultar saldo
Retirar dinero
28
TRABAJO FINAL
Retirar avance tarjeta de crdito
Cambiar clave
29
TRABAJO FINAL
Desplegar saldo
Diccionario de Clases
30
TRABAJO FINAL
Diagrama de secuencias
31
TRABAJO FINAL
32
TRABAJO FINAL
Diccionario de Clases
33
TRABAJO FINAL
FASE 5: MODELO DE DISEO ORIENTADO A OBJETOS
8.1. ESTRATEGIAS DEL DISEO DEL PROYECTO
8.1.1. Arquitectura
A continuacin se muestra un diagrama representando la arquitectura a implementar en nuestro
proyecto.
34
TRABAJO FINAL
8.1.2 Robustez
El siguiente diagrama muestra la arquitectura de nuestro proyecto, incluyendo el manejo de errores y
excepciones con el fin de dar robustez al sistema.
35
TRABAJO FINAL
8.2. Diseo de Objetos
Clase: InterfaceCliente
Descripcin: Es el ambiente de interaccin entre el actor cliente y el cajero
automtico de PobreBank
Mdulo: Usuario
Estereotipo: Borde
Propiedades: Concreta
Superclases:
Subclases:
Atributos:
Solicita ingreso de la tarjeta crdito o ControladorGeneral
dbito.
Solicita ingreso de clave PantallaValidarCliente
Clase: InterfaceAdmonBaseDatos
Descripcin: Medio de comunicacin del actor administrador del sistema
Mdulo: Base Datos
Estereotipo: Borde
Superclases:
Subclases:
Atributos:
Permite el acceso la administracin ControladorGeneral
del sistema.
Despliega men de administracin ControladorGeneral
base de datos
Acceso a la base de datos tarjeta CuentaCreditoCliente
crdito debito
Acceso a la base de datos cuentas de CuentaAhorrosCliente
ahorro
36
TRABAJO FINAL
Clase: InterfaceHardwareCajeroAutomtico
Descripcin: Dispositivo encargado de realizar las interacciones fsicas con
el cliente, tal como entregar dinero.
Mdulo: Cajero
Estereotipo: Borde
Superclases:
Subclases:
Atributos:
Valida el chip de la tarjeta ingresada ControladorCambioClave
Solicita clave de usuario PantallaValidarCliente
Da paso a la pantalla principal ControladorGeneral
Clase: InterfaceBasedeDatosCuentasAhorro
Descripcin: Mediacin entre el actor Base Datos Cuentas de ahorro y el
sistema.
Mdulo: Base Datos
Estereotipo: Borde
Superclases:
Subclases:
Atributos:
Paga dinero debito de la cuenta de ControladorRetiro
ahorros si existe saldo.
Presenta informacin de estado de ControladorSaldo
cuenta
Clase: InterfaceProgramador
Descripcin: Acceso del actor programador con el software del sistema
Mdulo: Base Datos
Estereotipo: Borde
Superclases:
Subclases:
Atributos:
Acceso al software del sistema ControladorGeneral
(cdigo fuente)
Acceso al software general de ControladorGeneral
aplicacin del cajero automtico.
Acceso al control del hardware ControladorGeneral
Clase: InterfaceBaseDatosTargetaCrditoDbito
37
TRABAJO FINAL
Descripcin: Ambiente de interaccin entre el actor Base Datos Tarjetas

Crdito Dbito y el sistema.
Mdulo: Base Datos
Estereotipo: Borde
Superclases:
Subclases:
Atributos:
Selecciona tipo de tarjeta crdito o PantallaServicios
dbito.
Paga dinero por avance tarjeta crdito ControladorPagoCredito
si existe cupo.
Presenta informacin de estado de ControladorDespliegueSaldo
cuenta tarjeta crdito.
Actualiza informacin de saldo en ControladorAvance
tarjeta de crdito.
Clase: PantallaServicios
Descripcin: Es el ambiente de mediacin entre el actor cliente y los
servicios ofrecidos por el cajero automtico.
Mdulo: Usuario
Estereotipo: Borde
Superclases:
Subclases:
Atributos:
Despliega servicio Consultar saldo. ControladorSaldo
Despliega servicio retiros. ControladorGeneral
Despliega servicio avances. ControladorGeneral
Despliega servicio cambio de calve. ControladorCambioClave
Clase: CuentaAhorrosCliente
Descripcin: Valida la informacin almacenada en la cuenta de ahorros del
cliente.
Mdulo: Base Datos
Estereotipo: Entidad
Superclases:
Subclases:
Atributos:
Actualiza informacin de saldo en ControladorPagoDebito
cuenta de cliente.
Almacena informacin del usuario. RegistroCliente
38
TRABAJO FINAL
Clase: IDChipTarjetaDbito
Descripcin: Valida la informacin almacenada en el chip de la tarjeta dbito
del cliente.
Mdulo: Cajero
Superclases:
Subclases:
Atributos:
Guarda datos del chip asociados a la RegistroCliente
clave de usuario.
Clase: ClaveDbitoCliente
Descripcin: Valida la informacin de la clave suministrada por el cliente y
almacenada en la base de datos dl sistema.
Mdulo: Cajero
Superclases:
Subclases:
Atributos:
Almacena informacin sobre clave de ControladorCambioClave
usuario
Actualiza informacin sobre cambio ControladorClaveNueva
de calve usuario.
Clase: RegistroCliente
Descripcin: Valida toda la informacin relacionada con el cliente del banco
que se encuentra almacenada en la base de datos.
Mdulo: Banco
Superclases:
Subclases:
Atributos:
Guarda informacin personal de ControladorGeneral
contacto del cliente.
Actualiza informacin personal de ControladorGeneral
contacto del cliente.
Asocia cuenta de ahorro al cliente CuentaAhorrosCliente
Asocia tarjeta crdito al cliente CuentaDebitoCliente
39
TRABAJO FINAL
8.3. Diseo de Sistema de su proyecto
Para el desarrollo del diseo del sistema me he basado en los trabajos anteriormente desarrollados,
aqu podemos observar que encontramos entradas, salidas y el procedimiento que debe realizar
cada una de las funciones que hemos planteado anteriormente.
8.3.1. Mtodo Usuario

Para este primer punto vamos a tratar la interfaz del usuario, este mtodo tiene como mtodos la
consulta de la fecha de creacin del usuario, el estado del usuario en el sistema, identificar cuantos
productos tiene asociados asignarle productos y retirarles productos.
Entradas
- Obtener la fecha de creacin del usuario
- Estado del usuario
- Cuales productos tiene asociados
- Asignacin de productos
- Retiro de productos
- Cambio de productos
Procesos
El proceso que se debe realizar para cada uno de los siguientes mtodos, es el
de consultar la informacin del usuario a la base de datos y retornar la
informacin solicitada en caso de consulta, en caso de actualizacin se debe
realizar la actualizacin sobre la base de datos dejando registro de quien y cul
fue el motivo de la actualizacin de dicha informacin.
Salidas
- Obtener la fecha de creacin
- Obtener el estado del usuario
- Obtener el nmero y cuales productos tiene asociados
- Confirmacin de la asignacin del producto
- Confirmacin del retiro del producto
- Confirmacin del cambio del producto
8.3.2. Mtodo Uso Tarjeta Dbito

Para este segundo punto vamos a tratar la interfaz para el uso de la tarjeta debito del usuario aqu
podemos tener como entradas la consulta de saldo, el retiro de dinero, la consignacin de dinero, la
consulta del estado de la tarjeta y la consulta de movimientos de dicha tarjeta.
Entradas
- Consulta de saldo
- Consulta de estado de la tarjeta
- Retiro de dinero
- Consignacin de dinero
- Consulta de movimientos
40
TRABAJO FINAL
Procesos
Salidas
- Obtener el saldo de la tarjeta
- Obtener el estado de la tarjeta
- Obtener la confirmacin o negacin para el retiro del dinero
- Aumentar la cifra consignada en el saldo de la tarjeta
- Obtener los movimientos de la cuenta
8.3.3. Mtodo Uso Tarjeta crdito

Para este tercer punto vamos a realizar la interfaz para el uso de la tarjeta de crdito del usuario,
para este paso vamos a tener como entradas el cupo de la tarjeta, el valor de avance posible, el
monto mnimo a pagar, el monto total a pagar, la fecha de corte de la tarjeta de crdito y la consulta
de los movimientos relacionados con dicha tarjeta de crdito.
Entradas
- Cupo total de la tarjeta
- Valor posible para avances
- Monto mnimo a pagar
- Monto total a pagar
- Fecha de corte de la tarjeta
- Consulta de movimientos de la tarjeta
- Consulta de estado de la tarjeta
Procesos
Salidas
- Obtener el cupo total de la tarjeta
- Obtener el valor posible para los avances
- Obtener el monto mnimo a pagar
- Obtener el monto total a pagar
- Obtener la fecha de corte de la tarjeta
- Obtener el histrico de los movimientos de la tarjeta
- Obtener el estado de la tarjeta
41
TRABAJO FINAL
8.4. Revisin del Diseo de su proyecto
El Diseo Orientado a Objetos es parte del Desarrollo Orientado a Objetos utiliza una estrategia
orientada a objetos en el Proceso de Desarrollo:
Anlisis Orientado a Objetos Comprende el desarrollo de un modelo orientado a objetos del dominio
de aplicacin. Los objetos identificados reflejan las entidades y operaciones que se asocian con el
problema a resolver. Diseo Orientado a Objetos comprende el desarrollo de un modelo orientado a
objetos de un sistema software para implementar los requerimientos identificados.
Los objetos => estn relacionados con la solucin del problema.
Pueden existir relaciones entre algunos objetos del problema y algunos objetos de la solucin, pero
el diseador deber agregar nuevos objetos para transformar los objetos del problema e implementar
la solucin.
Programacin Orientada a Objetos implementa el Diseo de Software utilizando un lenguaje de

Programacin Orientado a Objetos, como Java. Un lenguaje orientado a objetos provee recursos
para definir las clases y un sistema para crear los objetos correspondientes a las clases.
A veces, las decisiones sobre la distribucin de los objetos y si stos se implementan de forma
secuencial o concurrente tambin se pueden retrasar. Esto significa que los diseadores de software
no estn condicionados por los detalles de la implementacin del sistema. Pueden formular diseos
que se adapten a los diversos entornos de ejecucin. Los sistemas orientados a objetos son ms
fciles de mantener, porque los objetos son independientes. Estos sistemas pueden ser entendidos y
modificados como entidades independientes. Cambiar la implementacin de un objeto o agregarle
servicios no afecta a los otros objetos del sistema.
Como los objetos estn asociados a cosas, a menudo hay una correspondencia clara entre las
entidades del mundo real con los objetos de software.
1. Esto mejora la comprensin y la mantenibilidad del Diseo.
2. Los objetos son componentes potencialmente reutilizables debido a que son

encapsulamientos independientes del estado y las operaciones.
3. Los diseos se pueden desarrollar utilizando objetos creados en los diseos previos.
4. Esto reduce los costos de diseo, programacin y validacin.
Tambin conduce a la utilizacin de objetos estndar (por lo que se mejora la comprensin del
diseo) y reduce los riesgos implicados en el desarrollo de software.
42
TRABAJO FINAL
El Diseo Pesado no es necesario en sistemas de negocios pequeos o medianos. Sin embargo,

para sistemas grandes, particularmente en sistemas crticos, es esencial asegurar que los equipos
trabajen en diferentes partes del sistema adecuadamente coordinados. El Proceso de Diseo que
pone nfasis en el desarrollo dirigido por casos de uso significa que el Diseo est centrado en el
usuario y basado alrededor de las interacciones del usuario con el sistema. Sin embargo,
representar los requerimientos que no estn directamente ligados a los usuarios del sistema
mediante casos de uso es difcil.
Los casos de usos tienen un excelente papel en el anlisis y diseo orientado a objetos, pero
necesitan ser complementados con otras tcnicas que nos permitan descubrir requerimientos
indirectos y no funcionales del sistema.
8.4.1. Revisin del Diseo
Para la revisin del diseo de nuestro proyecto es necesario:
NECESIDADES DEL CLIENTE: Los tipos de necesidades del cliente se corresponden con tres
exigencias de calidad:
La calidad requerida. Corresponde a los atributos indispensables que el cliente pide al expresar
sus necesidades y que la empresa puede conocer en todos sus trminos para satisfacerlas.
La calidad esperada. Se refiere a aquellos atributos del bien que complementan los atributos
indispensables no siempre explcitos, pero que el cliente desea y que suelen tener un fuerte
componente subjetivo. Se denominan expectativas.
43
TRABAJO FINAL
La calidad potencial. Son las posibles caractersticas del bien que desconoce el cliente, pero que, si
se las ofrecemos, valora positivamente.
ELEMENTOS DE ENTRADA DEL DISEO: Las entradas pueden ser de Recursos Materiales,
Recursos Financieros, recursos humanos y de Informacin, constituyen la fuerza de arranque del
sistema y pueden ser:
- En serie: resultado o salida de un sistema anterior relacionado con el sistema en estudio
- Aleatoria: entradas potenciales o al azar
- Realimentacin: reinduccin de una parte de las salidas del mismo sistema
PROCESO DE DISEO: Un sistema para que pueda funcionar, debe importar ciertos recursos del
medio. Estos pueden ser recursos materiales, recursos financieros, recursos humanos y/o
informacin. Con el fin de utilizar un trmino que comprenda todos estos insumos, podemos emplear
el concepto de energa. Por lo tanto, los sistemas a travs de su corriente de entrada, reciben la
energa necesaria para su funcionamiento y manutencin.
RESULTADO DE DISEO: se denominan resultados, xitos o beneficios Pueden ser positivas y
negativas para el medio y entorno, entendindose aqu por medio todos aquellos otros sistemas que
utilizan de una forma u otra la energa que exporta el sistema.
PRODUCTO DEL DISEO: Es el resultado final en este caso la aplicacin que se necesita para el
ingreso de los estudiantes a la sala de la Universidad.
VERIFICACION Y VALIDACION: La verificacin tiene lugar en cada paso en el ciclo de vida de
seguridad, mientras que la validacin ocurre despus de que se instala el sistema y antes de ponerlo
en servicio. Ambas actividades le ayudan a quitar fallas sistemticas del sistema instrumentado la
seguridad como sea posible.
Este recurso de validacin y verificacin proporcionan un alto nivel de garanta del que el sistema
instrumentado funcionara de acuerdo con lo requerido con su especificacin y requisitos,
estructurando la validacin y la verificacin se pueden hacer ms manejables y como las prcticas
de documentacin le pueden ayudar a producir y mantener la prueba que un sistema instrumentado
de seguridad est diseado e implementado adecuadamente.
44
TRABAJO FINAL
8.5. Diagramas de Secuencias del Diseo de su proyecto
8.5.1. Secuencia para validar los datos del usuario
8.5.2 Diagrama de secuencias para cuando la contrasea est errada
45
TRABAJO FINAL
8.5.3. Secuencia correcta del usuario en el cajero.
8.5.4. Diagrama de secuencias para cuando no hay fondos en la cuenta
46
TRABAJO FINAL
Fase 7: modelo de implementacin y modelo de prueba orientado a objetos

Captulo 9: Modelo de Implementacin
9.1. Programacin en Java de su proyecto de Investigacin

El lenguaje de programacin Java, es un lenguaje que tiene un propsito general, concurrente,
orientado a objetos, este lenguaje de programacin fue diseado especficamente para tener pocas
dependencias de implementacin. La intencin es la de permitir a los desarrolladores que realizan
aplicaciones, que puedan realizar la escritura de su cdigo en un solo lenguaje y pueda correrse
desde cualquier dispositivo, ya que compila el cdigo en un lenguaje intermedio que puede leer
cualquier dispositivo que tenga instalada la mquina virtual de java, gracias a esto el desarrollo en
mltiples plataformas se volvi ms fcil de realizar ya que el cdigo solo se escribe una vez y se
compila para las diferentes plataformas donde se desea ejecutar.
El lenguaje de programacin Java fue originalmente desarrollado por James Gosling de Sun
Microsystems (la cual fue adquirida por la compaa Oracle) y publicado en 1995 como un
componente fundamental de la plataforma Java de Sun Microsystems. Su sintaxis deriva en gran
medida de C y C++
9.2. Diagrama de Clases de su proyecto de Investigacin
El diagrama de clases, utiliza el lenguaje unificado de modelado UML para el desarrollo visual de las
clases que puede tener un sistema, estas clases tienen atributos, operaciones o mtodos y la
relacin entre los mismos objetos, estos diagramas se realizan con la finalidad de ayudar a tener una
estructura ms clara y concisa de cmo est armado un sistema de informacin, cules son sus
atributos o propiedades y cules son sus mtodos u operaciones con sus respectivas entradas y
salidas.
47
TRABAJO FINAL
9.2.1 Interface Usuario
9.2.2 Principal
48
TRABAJO FINAL
9.2.3 Dominio
El diagrama de clases del mdulo Dominio se muestra en la figura 9.4.
Figura 9.4 Diagrama de clases del mdulo Dominio.
9.2.4 Registro
El mdulo de Registro est compuesto por los modules de Usuario, Tarjeta y InterfaceBD, como se
muestra en la figura 9.5 y con mayor detalle en las siguientes secciones.
Figura 9.5 Diagrama de mdulos del sistema de registro.

USUARIO
El diagrama de clases del mdulo Usuario se muestra en la figura 9.6.
49
TRABAJO FINAL
TARJETA
El diagrama de clases del mdulo Tarjeta se muestra en la figura 9.7.
INTERFACEBD
El diagrama de clases del mdulo InterfaceBD se muestra en la figura 9.8
50
TRABAJO FINAL
9.2.5 Servicios
Las clases del mdulo Servicios se muestran en la figura 9.9.
10.1 DEFINICION DE CONCEPTOS
Falla (Failure): Se considera falla cuando un programa en ejecucin no se comporta de forma

correcta.
Falta (Fault): Se debe cuando falta algo en el programa que puede producir una falla. No puede
haber falla sin antes existir una falta.
Error: Son provocados por la accin humana lo cual conlleva a que el software contenga una falta, y
por ende, una posible falla del sistema.
No es posible garantizar que un sistema no falle, y el hecho de no encontrar faltas en el cdigo no es

suficiente para demostrar que no habr fallas. Por lo general las pruebas son realizadas por
personas diferentes al desarrollador, lo cual conlleva a un costo adicional por lo que solo se prueban,
generalmente, las partes principales del sistema. Cuando se trata de corregir alguna falta es muy
posible que el cdigo modificado genere otras faltas, lo cual requiere nuevas pruebas esperando que
el nmero de faltas introducidas sea menor que la falta anterior.
51
TRABAJO FINAL
10.2 TIPOS DE PRUEBAS
Los tipos de pruebas pueden dividirse en Pruebas de Verificacin y Pruebas de Validacin.
Pruebas de Verificacin:
En estas pruebas se pretende verificar si el resultado obtenido satisface las especificaciones del
sistema. Esto no siempre quiere decir que el hecho que el software funciones, garantice la
satisfaccin del cliente.
Pruebas de Validacin
En este tipo de pruebas se verifica si el cliente est satisfecho con el resultado obtenido. En cada
fase de desarrollo del software pueden hacerse este tipo de pruebas para evaluar la aprobacin del
cliente, esto a travs de prototipos.
10.2.1 Tcnicas de Pruebas

Existen varios tipos de tcnicas para realizar las pruebas, las cuales se describen a continuacin:
Pruebas de Regresin:
Tiene el objetivo de encontrar faltas despus que se han realizado cambios en el software.
Prueba de Operacin:
Son pruebas diseadas para medir la confiabilidad del sistema tras un largo tiempo de operacin del
sistema.
Prueba de Escala Completa:

Son pruebas realizadas para medir el grado de estrs del sistema, en el cual se verifica la carga
mxima de equipos y usuarios simultneos, es decir se prueba el sistema en los lmites extremos
para determinar su nivel de tolerancia y verificar si ocurre alguna falla en el proceso.
Prueba de Rendimiento:
Esta prueba mide el Performance del sistema midiendo la capacidad de procesamiento del software
bajo diferentes cargas.
Prueba de Sobrecarga
Son pruebas ms rigurosas que las pruebas de escala completa y rendimiento, en el que se colocan
picos de carga con el fin de encontrar el lmite del sistema en el que cae abruptamente el
rendimiento.
52
TRABAJO FINAL
Prueba Negativa
Se hacen estas pruebas para medir el estrs del sistema ante situaciones inesperadas. Esta prueba
se hace intencionalmente para probar aspectos crticos en casos de uso que generalmente no seran
utilizados simultneamente.
Prueba basada en requisitos o prueba de casos de uso.

Son pruebas basadas en la especificacin de requisitos. Pueden usarse los mismos casos de uso
originales como casos de prueba. Por otro lado, pueden usarse para verificar las especificaciones de
rendimiento o de escala completa. Intenta verificar que el sistema final cumple con las
especificaciones funcionales definidas por los casos de uso originales.
Pruebas ergonmicas.
Tienen la finalidad de probar las caractersticas ergonmicas del sistema, en otras palabras, las
interfaces hombre-mquina en el caso de que estas existan. Por ejemplo, se prueba si las interfaces
son congruentes con los casos de uso a los cuales corresponden, o entre diferentes casos de uso, si
los mens son lgicos y legibles, si los mensajes del sistema son visibles, si se puede entender los
mensajes de falla, etctera.
Prueba de documentacin de usuario.

Sirven para probar la documentacin de usuario, lo cual incluye el manual, la documentacin de
mantenimiento y servicio. Se intenta probar que los manuales y el comportamiento del sistema sean
coherentes entre s, que sean legibles, con una buena redaccin y, en general, que sean
comprensibles.
Prueba de aceptacin o de validacin.

Tienen la finalidad de realizar una revisin final por parte del cliente, lo cual, significa la validacin del
sistema. El sistema se prueba en su ambiente real por un periodo extenso. Cuando finaliza la
prueba, se toma la decisin de aceptar o no el producto. Este tipo de prueba es a veces conocida
como prueba alfa. Si no existe un cliente particular que haya solicitado el sistema, por ejemplo en el
caso de un producto de software de venta al pblico, a menudo se hace una prueba beta, lo cual
implica que antes de enviarlo al pblico en general, el producto es probado por clientes
seleccionados que utilizan el sistema y reportan las fallas experimentadas.
10.2.2 Nivel de pruebas
Existen tres niveles principales para aplicar las diversas tcnicas de pruebas:
Prueba de unidad.
Mediante esta prueba solo una unidad es probada como tal, como una clase, un paquete de servicio
o un subsistema. A su vez estas pruebas pueden clasificarse en:
53
TRABAJO FINAL
Pruebas de Especificacin o de Caja Negra

Prueba basada en Estado
Prueba Estructural
Prueba de integracin.
Verifica que las unidades trabajen juntas correctamente. Ambas pueden ser realizadas mediante
casos de uso de pruebas, los cuales pueden ser aplicados a clases, paquetes de servicio,
subsistemas y el sistema completo.
Prueba de sistema.
Verifica el sistema complete o su aplicacin como tal. Se toma el punto de vista del usuario final y los
casos de uso de pruebas ejecutan acciones tpicas del usuario.
10.3 PROCESO DE PRUEBAS
Este proceso incluye actividades, mtodos y estrategias parecidas al proceso de desarrollo de

software. Estas actividades de prueba abarcan aspectos como: Planeacin, Construccin y
Ejecucin. Se crea una bitcora durante todo el proceso de pruebas.
10.3.1 Estrategia de Pruebas
Orden de pruebas
El objetivo de estas pruebas es definir en qu momento y en qu orden se aplicaran las pruebas.
Existen dos enfoques para el orden en que se realizaran las pruebas: de arriba hacia abajo y de
abajo hacia arriba. Si se aplican pruebas correspondientes a un diseo de arriba hacia abajo,
entonces se deben desarrollar inicialmente las interfaces entre subsistemas, para tratar de probar los
protocolos a alto nivel antes de ir a los niveles inferiores. Si se hace un diseo de abajo hacia arriba
se puede certificar primero las unidades de bajo nivel y luego las interfaces entre ellas. Esta tcnica
aprovecha que una vez probadas las unidades, se elimina la necesidad de crear servidores
especializados para pruebas. En el de pruebas de arriba hacia abajo se necesitan servidores de
pruebas especiales que simulen el ambiente alrededor de la unidad que se verifica. En el caso
extremo se debe construir una estructura completa para simular todos los objetos del sistema que
an no existen.
Alcance de pruebas.
La finalidad de estas pruebas es identificar el tipo, nmero y casos de pruebas que se aplicaran para
revisar las diferentes caractersticas del sistema. Si se considera que los tipos de pruebas son
bastante amplios y extensos, el objetivo es seleccionar un nmero pequeo de casos de prueba
dentro de un gran nmero de posibles pruebas donde la probabilidad de encontrar faltas sea alto. Se
define la particin de equivalencias segn conjuntos equivalentes (equivalent set) de pruebas
definiendo un grupo de condiciones donde el sistema o algn componente se comportarn de
manera similar ante diferentes pruebas. La idea es escribir casos de prueba que cubran todos los
conjuntos de equivalencia, pero tener un caso de prueba para cada conjunto de equivalencia.
54
TRABAJO FINAL
Automatizacin de pruebas.
Tiene como propsito reducir el esfuerzo y costo de las pruebas mediante la automatizacin del
proceso. Esto puede lograrse mediante programas de pruebas especiales asociados a un conjunto
de datos de pruebas. El programa de prueba debe tomar conjuntos de datos de entrada y observar la
respuesta del sistema, la cual puede guardarse directamente en un archivo de salida o ser
comparada con alguna respuesta esperada. El objetivo es tener un programa de prueba lo ms
general e independiente posible de los datos de prueba, los cuales a su vez pueden ser generados
automticamente.
10.3.2 Planeacin de la prueba
El establecimiento de las estrategias de pruebas es la condicin inicial para la planeacin de la

prueba, lo que se debe decidir si se harn automtica o manualmente y si hay programas y datos de
prueba que puedan ser usados, posiblemente modificados o desarrollados de nueva cuenta. Se
define el alcance de las pruebas por medio de conjuntos de equivalencia y se identifican los tipos de
pruebas necesarios. La planeacin se realiza durante la etapa de elaboracin del modelo de anlisis
luego de finalizar el modelo de requisitos. La prueba se construye a lo largo la fase de la actividad de
diseo en el sistema. Esta etapa de planeacin, sirve como orientacin para la especificacin y
ejecucin de la prueba.
10.3.3 Construccin de la prueba

Las pruebas deben ser diseadas a un nivel funcional donde se describa cada prueba y su propsito
de manera general y detallada. Se debe describir exactamente como se deber ejecutar el caso de
prueba, de manera que personas no familiarizadas con la aplicacin, o incluso el sistema, puedan
ejecutar el caso. Las especificaciones del diseo de las pruebas deben servir tambin como
especificaciones de la prueba, en trminos ideales. Cada caso de prueba, con excepcin de las
pruebas de unidad de ms bajo nivel, debe ser documentado. Las condiciones para realizar la
prueba deben ser especificadas. Si la prueba debe ser efectuada en un ambiente de desarrollo o
real, es necesario determinar el tipo de software, hardware y equipo de prueba, y bajo que versin
del sistema. Tambin se debe describir como debe ejecutarse la prueba, en qu orden, cual es el
resultado esperado y cules son los criterios para aprobarla.
55
TRABAJO FINAL
10.3.4 Ejecucin de la prueba
Aqu se utiliza la especificacin del diseo de prueba y los reportes de esta. La idea es aplicar de
manera paralela el mayor caso de pruebas posible. Se ejecutan las pruebas automticas y manuales
de manera correspondiente y se indican los resultados esperados. Si alguna prueba particular falla,
se interrumpe su aplicacin y se anota el resultado para luego analizar el defecto y corregirlo. Una
vez corregido, la prueba se ejecuta otra vez. Todas las pruebas son calificadas segn su
importancia, y se puede definir si la prueba total ha sido aprobada o no de acuerdo a su resultado.
Se analizan los resultados de la prueba completa y se anota en los reportes un resumen de ella, los
recursos utilizados, los resultados individuales y si los resultados fueron aprobatorios o no. El reporte
de la prueba debe tambin mostrar el resultado de cada una de ellas, recursos utilizados y acciones
tomadas.
10.4. Pruebas del Sistema de su proyecto de investigacin

En lo que respecta al Sistema de su proyecto de investigacin, nos limitaremos a verificarlo de
acuerdo con la prueba de requisites o casos de uso. Como objetivo de la prueba revisaremos que la
funcionalidad implementada corresponda a los casos de uso especificados durante el modelo de
requisites. A continuacin revisaremos los casos de uso principal, bsico y de extensin, los cuales
fueron descritos durante el diseo Registrar Usuario y Registrar Tarjeta. Ntese que los casos de
uso Validar Usuario y Ofrecer Servicios no los describiremos de manera independiente, ya que son
inclusiones de los dems.
10.4.1 Registrar Usuario
Se prueba la secuencia ms importante de los casos de uso Registrar Usuario:

Crear Registro Usuario, Actualizar Registro Usuario y Eliminar Registro Usuario.
10.4.2 Registrar tarjeta
El sistema presenta la PantallaCrearRegTarjeta CP-5), lo cual da la posibilidad de crear un nuevo

registro de tarjeta.
Se puede revisar en la Base de Datos Registro que los valores han sido eliminados correctamente
en la base de datos, como se observa en la figura 10.26.
Figura 10.26 Imagen de la Base de Datos de Registro que presenta el registro de tarjeta eliminados.
56
TRABAJO FINAL
Para finalizar el caso de uso, el usuario debe presionar el botn "Salir", como se muestra en la figura
10.27.
Figura 10.27 PantallaCrearRegTarjeta (P-5) con el botn "Salir" presionado.
57
TRABAJO FINAL
CONCLUSIONES
El trabajo realizado nos permite entender que la programacin no es solo construir cdigo,
sino crear estructuras organizadas y buenos hbitos de programacin que nos ayuden a
planear, disear, implementar y probar un sistema de calidad.
Las pruebas del sistema son esenciales para garantizar un software funcional y valido de cara
al cliente. Estas pruebas deben hacerse en todo el proceso de desarrollo con el fin de evitar
errores que sean muy complejos y engorrosos de solucionar al final de la etapa de
implementacin.
La Programacin Orientada a Objetos es un paradigma que permite interpretar de una manera

abstracta y cercana al mundo real dentro un cdigo de programa.
El Lenguaje de Modelado Unificado (UML) es una gran herramienta grafica que permite
especificar y documentar un sistema de software, ya que cuenta con un modo estndar y
semnticas para el modelado de un sistema orientado a objetos.
Los patrones de diseo implementados en este trabajo permiten que una parte del sistema
vare de forma independiente sin afectar las dems partes cuando existen cambios de
requerimiento del cliente, cambios de nuevas funcionalidades del sistema o cambios en el
software con el que interacta el sistema.
La Programacin Orientada a Objetos es un paradigma que permite interpretar de una manera

abstracta y cercana al mundo real dentro un cdigo de programa.
El Lenguaje de Modelado Unificado (UML) es una gran herramienta grafica que permite
especificar y documentar un sistema de software, ya que cuenta con un modo estndar y
semnticas para el modelado de un sistema orientado a objetos.
Los patrones de diseo implementados en este trabajo permiten que una parte del sistema
vare de forma independiente sin afectar las dems partes cuando existen cambios de
requerimiento del cliente, cambios de nuevas funcionalidades del sistema o cambios en el
software con el que interacta el sistema.
58
TRABAJO FINAL
REFERENCIAS BIBLIOGRAFA
Mora, A. 2008. Tema 3: Diagrama de Casos de uso. [En lnea].Formato HTML. Recuperado
Septiembre 16 de 2016 en:https://es.scribd.com/doc/82603040/Casos-de-Uso-explicacion-
y-ejemplos
Weitzenfeld, A. 2014. Ingeniera de Software orientado a objetos con UML. Mxico, Julio 3 de 2014.
[En lnea].Formato PDF. Recuperado Septiembre 25 de 2016 en:
https://es.scribd.com/doc/82603040/Casos-de-Uso-explicacion-y-ejemplos
Berzal, F. Tema 3: Relaciones entre clases: Diagrama de clases UML. [En lnea]. Formato PDF.
Recuperado Noviembre 3 de 2016 en: http://elvex.ugr.es/decsai/java/pdf/3C-
Relaciones.pdf
Camila. 2013. Dependencia y asociacin. [En lnea]. Formato HTML. Recuperado Noviembre 3 de
2016 en: http://programacioncolmayor3.blogspot.com.co/2013/02/dependencia-y-
asociacion.html
Weitzenfeld, Alfredo. Ingeniera de Software Orientada a Objetos con UML, Java e Internet. Mexico
City: Cengage Learning, 2005. Gale Virtual Reference Library. Web. 3 July 2014. Parte III
Desarrollo de Software Orientada a Objetos
Weitzenfeld, Alfredo. Ingeniera de Software Orientada a Objetos con UML, Java e Internet. Mexico
City: Cengage Learning, 2005. Gale Virtual Reference Library. Web. 3 July 2014. Recuperado
de: http://campus03.unad.edu.co/ecbti07/mod/lesson/view.php?id=4408&pageid=1656
Mora, A. 2008. Tema 3: Diagrama de Casos de uso. [En lnea].Formato HTML. Recuperado
Septiembre 16 de 2016 en:https://es.scribd.com/doc/82603040/Casos-de-Uso-explicacion-
y-ejemplos
Weitzenfeld, A. 2014. Ingeniera de Software orientado a objetos con UML. Mxico, Julio 3 de 2014.
[En lnea].Formato PDF. Recuperado Septiembre 25 de 2016 en:
https://es.scribd.com/doc/82603040/Casos-de-Uso-explicacion-y-ejemplos
59

TrabajoFinal V4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TrabajoFinal V4

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

PROGRAMACION ORIENTADA A OBJETOS_301403_30

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

8.5.3. Secuencia correcta del usuario en el cajero. ............................................... 40

El objetivo general del desarrollo de la presente actividad colaborativa es realizar el anlisis y

Definir un problema informtico solucionable dentro del paradigma de la programacin

Utilizar herramientas de modelado como UML para representar el problema.

Disear un modelo de interfaces para representar un prototipo de la solucin.

Identificar las clases inherentes al problema.

Disear las estrategias de diseo del proyecto.

Identificar los objetos del Proyecto.

Aprender a disear el sistema que permitir la implementacin del cajero automtico.

Comprender la importancia de la revisin del diseo del sistema.

Obtener modelo de implementacin.

Ejecutar modelos de prueba.

Interconectar bases de datos a java.

Crear, modificar y eliminar informacin en la base de datos.

El principal problema al que se enfrenta un diseador informtico es el de modelar un sistema. Esta

FASE 3: MODELO DE REQUISITOS Y MODELO DE ANLISIS ORIENTADO A OBJETOS

6. Modelo de Requisitos Orientado a Objetos

6.1. Descripcin del Problema

6.1.2. CASOS DE USO

6.2. MODELO DE CASOS DE USO

Figura 1. Delimitacin del sistema segn actores externos

6.2.2 CASOS DE USO

Figura 4. Diagrama de Usos completo

6.3. Modelo de Interfaces

Caso de Uso: Consultar Saldo

Caso de Uso: Retirar avance Tarjeta de crdito

6.4. ACTORES Y CASOS DE USO

Actor Base de Datos Cuenta de Ahorros

Actor Base de Datos Tarjeta Dbito y Crdito

Caso de Uso Retirar Dinero

Caso de Uso Retirar Avance Tarjeta de Crdito

Caso de Uso Cambiar clave

Caso de Uso Desplegar Saldo

Caso de Uso Pagar Dinero Debito

Caso de Uso Pagar Dinero Crdito

Caso de Uso Ingresar nueva clave

6.5. Modelo del dominio del problema

6.6. Arquitectura de Clases

7. MODELO DE ANLISIS ORIENTADA A OBJETOS

Identificacin de Clases segn Estereotipos

Clases Borde identificadas del caso de uso Consultar Saldo:

Clases Borde identificadas del caso de uso Retirar Dinero:

Clases Borde identificadas del caso de uso Cambiar Clave:

Clases Borde identificadas del caso de uso Desplegar Saldo:

Clases Borde identificadas del caso de uso Pagar Dinero Debito:

Clases Borde identificadas del caso de uso Pagar Dinero Crdito:

Clases Borde identificadas del caso de uso Ingresar Clave Nueva:

Casos de Uso Actores Clases Borde

Retirar Dinero Cliente, Hardware Cajero InterfaceCliente,

Retirar Avance Tarjeta de Cliente, Hardware Cajero InterfaceCliente,

Cambiar Clave Cliente, Hardware Cajero InterfaceCliente,

Desplegar Saldo Cliente, Base de Datos InterfaceCliente,

Pagar Dinero Debito Cliente, Hardware Cajero InterfaceCliente,

Pagar Dinero Crdito Cliente, Hardware Cajero InterfaceCliente,

Ingresar Clave Nueva Cliente, Base de Datos InterfaceCliente,

Retirar Avance Tarjeta de Crdito:

Casos de Uso Clases Entidad

Consultar Saldo CuentaAhorrosCliente, IDChipTarjetaDebito,

Retirar Dinero CuentaAhorrosCliente, IDChipTarjetaDebito,

Retirar Avance Tarjeta de CuentaCreditoCliente, IDChipTarjetaCredito,