Demostración Final

Taller de Programación Orientada a Objetos

Demostracion Final.



VIDEO DEMOSTRACION:

Implementación de Interfaces Gráficas

Taller de Programación Orientada a Objetos - Semana 13 - Reporte 12.

Mi intención es colocar algo parecido a esto, tomando en cuenta el diseño personalizado que el cliente ha pedido.

Para lograr mi objetivo, decidi implementar el VIEW CONTROLLER MODEL.

En este caso solamente mi sistema extiende a un JFrame, mi clase Sistema es como el gestor de la GUI, se encarga de recibir los paneles de otros métodos y de mostrarlos en la pantalla:

Para tener una mejor estructura en mi código y no sobrecargar las clases, decidí distribuir la tarea de crear paneles. Asi por ejemplo, la factura es un panel formado por 4 paneles individuales, que a su vez se componen de paneles independientes armados por cada subclase. Como es el caso del segundo panel contenedor de la factura, el cual recibe los paneles de origen y destino de los métodos correspondientes de cada subclase:

Cuando se entra a la primera pantalla, se implementa un JMenuBar, con varias opciones disponibles, se invita al usuario a elegir una de ellas. Aquí parte del código de la implementación del JMenuBar:

Posterior a eso, se redibuja la pantalla y dependiendo de la opción seleccionada es el panel que se mostrará:

- Si se elige Facturacion > Nueva Factura se mostrará esta pantalla.

La pantalla de nueva factura mostrará todo el entorno de edición de una factura, un tipo de formulario donde se podrán introducir todos los datos necesarios.

Lo botones del final son las acciones que se pueden realizar con la factura.

• Imprimir: Para imprimir la factura en papel. Conexión con una impresora.
• Exportar: Para exportar la factura. A XML o PDF.
• Guardar: Guarda la factura en la base de datos.
• Limpiar: Limpia todos los campos.

- Si se elige Facturacion > Buscar se mostrará esta pantalla.

Se introducen las palabras clave y al presionar el botón buscar se envían las palabras clave como parámetros a la función buscarFactura(), la cual a su vez conecta con la base de datos por medio de un proxy, el proxy regresa los resultados y buscarFactura los procesa para mostrarlos dentro de un JTable().

Otra cosa que no se debe olvidar son los ActionListener, de que le sirve a uno tener interfaz gráfica, si no tenemos ActionListeners. Estos componentes nos ayudan a asignar acciones a cada botón, movimiento del ratón, etc. Aqui les muestro parte del código de alguno de mis ActionListeners:

La interfaz que he diseñado la hice utilizando muchos tipos de Layouts, definitivamente el que más me ayudo fue el GridBagLayout el cual es realmente poderoso.

SALUDOS :)

Referencias

• http://www.chuidiang.com/java/layout/GridBagLayout/GridBagLayout.html
• http://download.oracle.com/javase/tutorial/uiswing/layout/using.html
• http://download.oracle.com/javase/tutorial/uiswing/components/table.html

Implementacion de Sistemas Distribuidos

Taller de Programación Orientada a Objetos - Semana 12 - Reporte 11

Para mi proyecto, decidí programar un Sistema Distribuido por medio de sockets (TCP).

Su funcionamiento es simple. El sistema lo probé en forma local y funciona a base de 5 clases:

- SocketServer: Es la clase que se encarga de las tareas del servidor, su función es la de generar un Proxy entre el servidor y la base de datos principal. Después espera a recibir las peticiones, una vez recibidas se encarga de procesarlas y posteriormente enviar las palabras clave al Proxy para realizar la búsqueda dentro de la base de datos. Si se encuentran coincidencias en la base de datos, el Proxy almacena los resultados en un ArrayList y regresa la lista al servidor, el servidor empaquetara los resultados y enviara la ArrayList al cliente. Limpia la memoria y cierra conexiones.

- SocketCliente: Se encarga de realizar las peticiones. Se pide el nombre de la empresa y el RFC de la misma, dichos parámetros se envían al servidor empaquetados en un String. Se espera la respuesta del servidor, la cual es recibida en forma de ArrayList. Una vez recibida la respuesta, se desempaqueta por medio de un Iterador (Iterator) y después se siguen desempaquetando los resultados individuales por medio de un StringTokenizer(). El Iterador a la vez va imprimiendo los resultados uno a uno. Limpia memoria y cierra conexiones.

- Origen implements Serializable: Esta clase es muy sencilla, es donde se almacenan el nombre y RFC del cliente. Esta clase es Serializable. Sus atributos son el nombre y RFC ambos en forma de string, su unico metodo es toString() que empaqueta el objeto en un String para ser enviado.

- Resultados extends ArrayList implements Serializable: Es la clase usada por SocketServer para empaquetar los resultados de la búsqueda, no se si fue la forma mas optima de hacerlo pero funciono a la primera :). Una lista de Strings que es serializable para poder ser enviada.

Los resultados almacenan datos como el folio de la factura, la empresa destino y su ubicación, el total a pagar de la factura y la fecha en la cual la factura fue capturada.

Por ahora solo estoy trabajando con una base MySQL con facturas ficticias.

- Proxy: Conecta la base de datos con la aplicación principal (solo SocketServer) proporciona los métodos necesarios para interconectar la base de datos MySQL, realizar búsquedas, borrar registros, actualizar registros, crear registros, etcétera.

La aplicación funciono satisfactoriamente, no esperaba tan buenos resultados, les dejo las capturas de pantalla donde se ve la ejecución de la misma.

Pantalla SocketServer

Pantalla SocketClient

Les dejo el código al final de la entrada. No incluyo la clase Proxy por lo que no podran compilarlo y correrlo, pero sé que les servirá de referencia.

DESCARGA : Google Docs: rmi.tar.gz

SALUDOS :)

Implementación de Pruebas Unitarias

Taller de Programación Orientada a Objetos - Semana 11 - Reporte 10

Como mencione la clase anterior mencione para qué funciona el JUnit, lo descargamos y configuramos; ahora voy a utilizarlo para realizar algunas pruebas unitarias en mi código:

1. La clase en la que se implementarán las pruebas unitarias de llama Converter.java.

Los métodos a probar son los siguientes:

Existen dos métodos getStringOfNumber(), la diferencia es que uno recibe un flotante y el otro un entero. Ambos serán probados en el test.

Diseño de la Prueba

Primero importaremos las librerias de nuestro Test JUnit y marcaremos nuestro Test como parte del paquete principal:

Despues programamos el Test.

Estos son los métodos del Test. testUno() se encarga de verificar si efectivamente el valor en letra del entero escrito en la variable String expected es igual a la String result cuyo valor es el que la función getStringOfNumber() esta retornando.

testDos() hace exactamente lo mismo pero con un double.

Incluímos tambien la funcion main() que es la que inicializa el test.

Los resultados fueron variados, mi primer resultado fue utilizando el test assertTrue(), este metodo afirma si una condición es verdadera. Como atributo utilicé la función a.equals(b), la cual compara dos strings y regresa 1 o 0 como valor. Entonces assertTrue recibe dicho valor y si es 1 se pasa el test, si es 0 el test tiene un error.

El testUno() no se paso porque la cadena no es igual. Yo especifique lo siguiente:

137 = CIENTO TREINTA Y SIETE

pero para el test:

137 = CIENTO TREINTA Y SIETE PESOS 0/100 MN.

porque getStringOfNumber() me regresa el valor en letra pero en tipo moneda.

Entonces solo hace falta modificar la variable String expected de testUno() y realizamos la prueba otra vez

Ahora ambos test fuerons pasados.

Saludos :)

Implementación de Eventos, Excepcion y Errores propios

Taller de Programación Orientada a Objetos - Semana 10 - Semana 9

Aquí les muestro algunas capturas de pantalla implementando eventos y excepciones.

EVENTOS

Todos mis eventos están orientados a la interfaz gráfica, es por ello que les muestro como quedarían algunos de mis eventos implementando una de las barras de herramientas.

Implementación en el Código

Ejecución

EXCEPCIONES

1. Comenzamos por analizar los menús; cuando entramos a un menú en pantalla, hay que elegir una opción válida. Las opciones válidas son números dentro del rango permitido (el rango esta dado por el número total de opciones). Si se elige una opción fuera de ese rango ocurrirá una excepción y se imprimirá un mensaje en pantalla. De igual forma, si se introduce un carácter, espacio, salto de línea, tabulación, etcétera; como opción, se mostrará un mensaje de error también.

Implementación en el Código

Ejecución

2. Después de que elegimos una opción, hay que cargar los datos de la empresa. Los datos de la empresa están almacenados en un archivo de sistema el cual hay que leer.

Aquí puede ocurrir otra excepción, cuando el archivo no es encontrado. Si eso pasa, se muestra un mensaje de excepción y no se puede realizar ninguna factura.

Impementación en el Código

Ejecución

3. Cuando se toman los datos del concepto a facturar, hay campos en los que forzozamente hay que introducir un valor númerico, tal es el caso del precio y la cantidad de artículos de un solo tipo. En este caso se implementa un NumberFormatException.

Si ocurre la excepción, es decir, se introdujo como valor un caractér, un espacio, tabulacion o salto de línea, cualquier cosa menos un número; se mostrará un mensaje de excepción y se pedirá el valor de nuevo.

Implementación en el Código

Ejecución

Espero les sirva la información de esta entrada.

Suerte :)

Aplicación de Patrones de Diseño

Talle de Programación Orientada a Objetos - Semana 9 - Reporte 8

BUILDER PATTERN (Constructor)

Las partes de mi código que encajan con las especificaciones del patrón Builder son:

- Constructor: Mi clase Billing proporciona la interfaz y funciones para generar la factura.

- Constructor Concreto: En éste caso se trata del constructor de la Factura, el cual ensambla las partes individuales.

- Director: .

- Parte: Las partes son el Proveedor, Origen, Destino y Orden.

- Producto: El producto es la Factura.

En mi caso el primer paso es generar la factura al pedir los datos. Mi constructor sera Billing y su método makeNewBill() para construir la factura

Posterior se envían los objetos individuales al constructor de la clase Bill() :

Y el producto final es una Factura la cual se imprime en pantalla:

A partir de este producto es posible generar varios productos distintos, pues es posible imprimir la Factura, exportarla a otro formato como PDF, o generar la factura electrónica.

COMPOSITE PATTERN (Compuesto)

El Patrón compuesto lo aplique al momento de pedir los datos de cada objeto individual, cada campo que es necesario para generar ya sea el Origen, Destino ú Orden; son hojas del objeto indiviual; y cada objeto individual (pero compuesto) se vuelve hoja de lo que es la Factura principal.

Se envían los objetos a la factura y después la factura se puede guardar en la base de datos.

En éste caso el patrón compuesto se combina con el patrón constructor para generarla factura.

ITERATOR (Iterador)

Por último, en el proyecto solo he aplicado un iterador, en esté caso la función del iterador es la de ingresar a la orden del cliente para imprimir en pantalla los conceptos a facturar.

Falta implementar algunos iteradores más, porque necesito tener la capacidad de modificar los datos de la orden o agregar nuevos datos.

La implementación de los patrones fue algo complicada, de hecho siento que "emule" a los patrones y no los aplique concretamente ya que en cierto momento mi código no compiló y trate de tener algo sólido para presentar.

SALUDOS

Demostración de avance parcial

Taller de Programación Orientada a Objetos - Semana 8 - Reporte 7

Que tal amigos! En esta entrada voy a mostrarles una breve explicación y ejecución del código de mi proyecto.

Como recordaran, estoy realizando un Sistema de Facturación Electrónica para una empresa de logística empresarial.

Actualmente para lograr mi objetivo estoy trabajando con 5 clases:

La clase Bill que es la factura.

La clase Billing que es el módulo principal de facturación, contiene la función main por lo que es el inicio de la aplicación.

La clase Items que representa los artículos o conceptos del pedido.

La clase Order que es una lista de artículos y conceptos.

La clase Person que son las personas involucradas en la factura, Cliente y Proveedor.

En este caso vamos a analizar la clase Billing.

Lo primero que se va a realizar es generar un nuevo módulo de facturación y llamar a la función mainMenu() la cual mostrara el menú principal.

Esta pantalla muestra 3 opciones, 1. Factura 2. Base de Datos 3. Salir.

Si entramos a la opción Factura se desplegarán 3 nuevas opciones: 1. Nueva factura 2. Buscar 3. Salir.

En el menú principal, si entramos a la opción Base de Datos se desplegarán 6 nuevas opciones: 1. Ver 2. Alta 3. Baja 4. Modificar 5. Buscar 6. Salir.

Las opciones de Base de Datos solo muestran los mensajes de las acciones que se realizarán dependiendo de la opción seleccionada.

En la opción Factura del menú principal, la opción Buscar solo mostrara una impresión en pantalla indicando que una factura se buscará.

La opción Nueva Factura ira pidiendo algunos datos para generar un cliente y almacenar cada uno de los datos pedidos en los atributos del mismo.

Ahora en éste video verán la ejecución del código, debido a una falla del micrófono de mi computadora, tendremos que verlo en silencio, lo cual esta bien porque si leyeron la explicación de arriba solo basta con observar :)

Como pueden ver por ahora el diseño esta bien aunque algo simple, no obstante ya tengo los algoritmos necesarios para programar las opciones de la base de datos (alta, baja, buscar, etcétera).

Así mismo ya estoy en búsqueda de las librerías necesarias para poder exportar mis facturas a un formato electrónico y para imprimirlas físicamente.

Espero les haya gustado mi explicación y les sirva de algo mi entrada.

Saludos!! :)

Código autogenerado y comparación

Taller de Programación Orientada a Objetos - Semana 7 - Reporte 6

COMPARACIÓN DE DIAGRAMAS

1. Diagrama diseñado por mi.

2. Diagrama autogenerado por mi código

Aunque en escencia son lo mismo, la verdad es que ambos difieren en varios aspectos.

Los mas importantes a resaltar son primeramente las variables. Podemos ver que en el diagrama que yo diseñe se ven las variables dentro de la cajita de las clases, pero en el diagrama autogenerado no aparecen. Esto es porque el nivel de acceso por default en el primer diagrama es "PUBLIC", mientras que en segundo diagrama mis variables estan declaradas como "PRIVATE", por eso aparecen ocultas.

Otra diferencia es la declaración de algunos métodos. Prinicipalmente los constructores de cada clase, que en el primer diagrama solo aparecen declarados y en el segundo aparecen incluso con los parámetros que éstos recibirán.

En ambos aparecen por medio de flechas con la punta en forma de rombo, las uniones de las clases que envían parámetros a otras, y el nombre de la variable arriba, debajo o a un lado de la flecha.

Para mi ambos tienen cosas que le faltan al otro. El primero muestra mas funciones, ya que es en el que estoy visualizando mi código con mas imaginación. Mientras que en el segundo me falta implementar mis ideas para que se complete correctamente.

COMPARACIÓN DEL CÓDIGO

El código fue muy diferente en ambos casos, para empezar, la autogeneración de código me produjo más clases que las que de verdad tengo y necesito, además de dividirme el proyecto en 2 partes: LogicalView (¿?) y toBill (paquete real):

Mayor cantidad de clases:

logicalview

toBill

Clases reales

Otra diferencia es que código autogenerado por el diagrama UML diseñado por mi no compilo muy bien, creo que se debío principalmente a la extraña forma en que se declaro el contructor de cada clase:

Algunos constructores autogenerados

Constructores correctos.

Otra diferencia que hay es que en lugar de tener un solo método para tomar los datos y posteriormente enviarlos al constructor, se autogeneraron varios métodos "GET" y "SET" (para tomar los datos y despues colocarlos en su atributo correspondiente).

Esto me dio un poco de desconfianza pero prefiero mi método personal el cual es más corto y funcional (en mi opinión)

Métodos SET y GET

Método getData()

Otro error visible en la autogeneración es que la clase Bill (factura) hereda los atributos de Paper (factura en papel) lo cual esta equivocado ya que es a la inversa:

Incorrecto (Autogenerado)

Correcto

Estos son los detallitos mas sobresalientes de ambos, lo demás son simples funciónes vacías las cuales ya estan completadas en mi código. Asi como espacios para los comentarios, etcétera.

SALUDOS!!!