Juan Carlos Espinosa Ceniceros: mayo 2011

viernes, 6 de mayo de 2011

Demostración Final

Taller de Programación Orientada a Objetos

Demostracion Final.

VIDEO DEMOSTRACION:

Interfaces Gráficas

Programación Orientada a Objetos - Semana 13 - Reporte 12

Interfaces Gráficas en JAVA

Las GUI (Graphic User Interface) o Interfaz Gráfica de Usuario es una forma de hacer los dispositivos más accesibles a los usuarios en general.

Las interfaces gráficas son en realidad un componente o programa que corre en segundo plano en el sistema donde se ha implementado, su función es transformar cada una de las instrucciones, métodos, acciones o comandos en componentes visuales (haciendo uso de imagenes, pequeños iconos, efectos y demás).

Todo esto convierte un entorno de línea de comandos en un entorno visual más atractivo e intuitivo al usuario lo que es una invitación a utilizar nuestro sistema o aplicación

La necesidad de las interfaces gráficas surge como una consecuencia de la falta de conocimientos por parte de los usuarios sobre el manejo y uso de las CLI (Interfaces de Línea de Comandos) había la necesidad de masificar los sistemas, pero aprender cientos de instrucciones, sintaxis, parámetros y demás no era una buena solución.

Las Interfaces gráficas automatizan gran parte de este trabajo, ya que no es necesario aprender toda una instrucción textual, solo es necesario aprender la funcionalidad de un botón para lograr los resultados deseados.

Los sistemas operativos implementan diferentes gestores GUI o entornos de escritorio, solo por mencionar algunos:

Windows XP: LUNA
Windows Vista/Seven: AERO
MAC OS: AQUA
Linux: GNOME, UNITY, KCD

Java ofrece una serie de librerias que facilitan en gran medida la implementación interfaces gráficas.

java.awt(Abstract Windowing Toolkit)

Es el paquete original de herramientas GUI de Java. Las principales ventajas AWT son que viene incluída en todos los paquetes de tecnología Java, incluyendo implementaciones de Java en navegadores de Internet y es muy estable.

AWT es un conjunto de herramientas muy simples con pocos componentes GUI, administradores de diseño, y eventos.

Esto se debe a Sun Microsystems decidió utilizar un mínimo común denominador (LCD) para el enfoque de AWT.

Como resultado de ello, y por desgracia, algunos de los componentes de uso común, tales como tablas, árboles, barras de progreso, y otros, no son compatibles. Para las aplicaciones que necesitan más tipos de componentes, es necesario crearlas desde cero. Esta es una gran carga.

AWT ofrece tres tipos de componentes principales:

a) Básicos: Componentes básicos en cualquier GUI.

Button
CheckBox
Container
Panel
Window
Frame
Label
List
TextComponent
MenuComponent

b) Layouts: Sirven para acomodar los componentes de la GUI.

FlowLayout
GridLayout
BorderLayout
CardLayout
GridBagLayout

c) Eventos: Otorgan funcionalidades a cada uno de los componentes de la GUI.

KeyEvent
ActionEvent
MouseEvent
TextEvent

javax.swing

El paquete Swing es parte de la JFC (Java Foundation Classes) en la plataforma Java. La JFC provee facilidades para ayudar a la gente a construir GUIs.

Las componentes Swing se identifican porque pertenecen al paquete javax.swing.

Swing existe desde la JDK 1.1 (como un agregado). Antes de la existencia de Swing, las interfaces gráficas con el usuario se realizaban a través de AWT (Abstract Window Toolkit), de quien Swing hereda todo el manejo de eventos. Usualmente, para toda componente AWT existe una componente Swing que la reemplaza, por ejemplo, la clase Button de AWT es reemplazada por la clase JButton de Swing (el nombre de todas las componentes Swing comienza con "J").

Las componentes de Swing utilizan la infraestructura de AWT, incluyendo el modelo de eventos AWT, el cual rige cómo una componente reacciona a eventos tales como, eventos de teclado, mouse, etc... Es por esto, que la mayoría de los programas Swing necesitan importar dos paquetes AWT: java.awt.* y java.awt.event.*.

Ojo: Como regla, los programas no deben usar componenetes pesados de AWT junto a componentes Swing, ya que los componentes de AWT son siempre pintados sobre los de Swing. (Por componentes pesadas de AWT se entiende Menu, ScrollPane y todas las componentes que heredan de las clases Canvas y Panel de AWT)

Swing abarca componentes como botones, tablas, marcos, paneles, ventanas, etc...

APLICACIÓN AL PROYECTO

Es clave en mi proyecto desarrollar una interfaz gráfica amigable para el usuario. Mi intención es desarrollar algo parecido a la factura en físico, con un orden parecido.

En general, la ventana siempre estará compuesta por 2 paneles. El panel de barra de menú y el panel del área de trabajo

El panel de menú tendrá diferentes opciones las cuales se activaran dependiendo del área de trabajo. Para ello implementaré un JMenuBar. Si alguien por ahí sabe como implementarlo pues no dude en comentar.

El área de trabajo sera dinámica, ya que es la que cambiará con cada opción que se elija. Para ello se deberán utilizar de manera creativa los Layouts disponibles en java.awt.
Algunos paneles que me serán útiles son GridLayout, BorderLayout, FlowLayout y el dios GridBagLayout :).
Otros componentes necesarios para mi proyecto serán los básicos: JLabel, JButton, JTextField, JTextArea; asi como implementar de forma correcta el JTable

SALUDOS!! :)

REFERENCIAS

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

Presentacion Final

Programación Orientada a Objetos - Semana 14 - Reporte 13

Presentación Final

SALUDOS :)

jueves, 5 de mayo de 2011

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 :)

domingo, 1 de mayo de 2011

Sistemas Distribuídos

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

SISTEMAS DISTRIBUIDOS

Un sistema distribuido se define como: una colección de computadoras separadas físicamente y conectadas entre sí por una red de comunicaciones distribuida; cada máquina posee sus componentes de hardware y software que el usuario percibe como un solo sistema (no necesita saber qué cosas están en qué máquinas).

El usuario accede a los recursos remotos (RPC) de la misma manera en que accede a recursos locales, o un grupo de computadores que usan un software para conseguir un objetivo en común.

Los sistemas distribuidos deben ser muy confiables, ya que si un componente del sistema se descompone otro componente debe de ser capaz de reemplazarlo, esto se denomina Tolerancia a Fallos.

El tamaño de un sistema distribuido puede ser muy variado, ya sean decenas de hosts (red de área local), centenas de hosts (red de área metropolitana), y miles o millones de hosts (Internet); esto se denomina escalabilidad.

En Java se puede utilizar la Invocación Remota de Métodos o RMI para establecer un sistema distribuido.

El sistema de Invocación Remota de Métodos (RMI [Remote Method Invocation] ) de Java permite a un objeto que se está ejecutando en una Máquina Virtual Java (VM) llamar a métodos de otro objeto que está en otra VM diferente compartiendo así recursos y carga de procesamiento a través de varios sistemas.

Existen tres procesos que participan en una aplicación RMI:

Cliente (Client): Es el proceso que invoca los métodos de los objetos remotos.
Servidor (Server): Es el proceso que crea los objetos, hace referencia a los mismos y espera a que sean invocados por el cliente.
Registro de Objetos (Object Registry): Crea las referencias a los objetos en el servidor. Los objetos son registrados con éste proceso y una vez que son registrados se puede obtener acceso al mismo con tan solo su nombre.

Las aplicaciones distribuidas deben cumplir 3 tareas específicas para funcionar:

Localizar objetos remotos. Las aplicaciones pueden utilizar diversos mecanismos para obtener referencias a objetos remotos. Por ejemplo, una aplicación puede registrar sus objetos remotos con el registro RMI. Por otra parte, una aplicación puede pasar y devolver referencias de objetos remotos como parte de otras invocaciones remotas.
Comunicarse con objetos remotos. Los detalles de la comunicación entre objetos remotos son manejados por el RMI. Para el programador, la comunicación a distancia es similar a regular llamadas a métodos Java.
Cargar las definiciones de clases para los objetos que se pasan a través de la aplicación. Debido a que RMI permite a los objetos pasar en dos direcciones (Ida y Vuelta), se proporciona mecanismos para cargar las definiciones de clase de un objeto, así como para la transmisión de datos de un objeto.

La siguiente ilustración muestra una aplicación RMI distribuida que utiliza el registroRMI para obtener una referencia a un objeto remoto. El servidor llama al registro paraasociar (o unen) un nombre con un objeto remoto. El cliente busca el objeto remotopor su nombre en el registro del servidor y luego invoca un método en él. La ilustración también muestra que el sistema RMI utiliza un servidor Web existentepara cargar las definiciones de clase, del servidor al cliente y del cliente al servidor,para los objetos cuando sea necesario.

Realizar un sistema distribuido con RMI es algo sencillo, se pueden seguir los siguientes pasos:

1. Crear un servidor RMI

Definir un objeto remoto que va a ser utilizado por los clientes. Para crear un objeto remoto...
Definir una interfaz, y el objeto remoto será una clase que implemente dicha interfaz.

2. Definir el interfaz remoto

El interfaz debe ser público.
Debe extender (heredar de) el interfaz java.rmi.Remote, para indicar que puede llamarse desde cualquier máquina virtual Java.
Cada método remoto debe lanzar la excepción java.rmi.RemoteException en su claúsula throws, además de las excepciones que pueda manejar.

APLICACIÓN AL PROYECTO

En el caso de mi proyecto, mi idea es aplicar algo equivalente al servicio que ofrecen las tiendas de conveniencia en línea.

Seria un portal, ya sea en línea o por medio de una aplicación java móvil que permite descargar la factura en formato PDF a la computadora o dispositivo móvil.

Por ahora y por el poco tiempo restante, solo me encargaría de hacer el sistema en línea.

Como método de autentificación se pediría el RFC del cliente (esté a su vez se convertiría en un filtro para solo mostrar las facturas almacenadas en la base de datos que correspondan a ese cliente)

Después, si lo sabe el cliente, se pediría el folio de la factura a descargar. Si el cliente no sabe el folio de la factura se procede a imprimir una lista de las facturas correspondientes al cliente para que pueda verificar y descargar la que desee.

Una vez seleccionada la factura, el programa, en silencio, recupera la factura y arma un PDF que puede ser descargado.

REFERENCIAS