REPOSITORY OVERVIEW

Live repository statistics

★ 18Stars

⑂ 1Forks

◯ 0Open issues

◉ 18Watchers

README preview

Interfaz Gráfica en Java

Curso propuesto por el grupo de trabajo Semana de Ingenio y Diseño (SID) de la Universidad Distrital Francisco Jose de Caldas.

Monitor

Cristian Felipe Patiño Cáceres - Estudiante de Ingeniería de Sistemas de la Universidad Distrital Francisco Jose de Caldas

Clase 4

Objetivos

Reconocer la forma de añadir modularidad al código en las clases Template separando la creación de objetos gráficos.
Optimizar el código con el uso de un servicio que encapsule el funcionamiento de la construcción de objetos gráficos.
Optimizar los recursos de la aplicación con el uso de un servicio que administre los objetos que pueden ser utilizados en diferentes clases.

Antes de comenzar

Ajustes en el proyecto

En las anteriores sesiones se han creado las clases VistaPrincipalTemplate y LoginTemplate cada una en su respectivo paquete como se puede ver a continuación:

Ahora por motivos de modularidad se crea un paquete llamado client y allí se dejan los paquetes de las clases UI que se han creado. El archivo de ejecución App.java sigue estando ubicado en el paquete principal app.

Recordatorio

Recordando un poco el recorrido del curso, en la primera sesión se había creado la clase VistaPrincipalTemplate que hasta el momento esta vacía:

También se creo la clase LoginTemplate y el resultado de la anterior sesión fue el siguiente:

Modularización y optimización

En esta lección se van a tratar 3 temas principales que serán de vital ayuda para que el código creado al construir interfaces gráficas de usuario sea ordenado, mantenible, entendible y sencillo. Los temas principales son:

Modularización de código
Optimización de código
Optimización de recursos

Modularización de código

Ya se ha creado el login de usuario usando objetos gráficos y objetos decoradores los cuales hacen que la interfaz de usuario se vea muy bien, sin embargo, si en algún momento se quiere cambiar alguna configuración en uno de los objetos gráficos creados, realmente va ser algo complicado encontrar dicho objeto dentro del constructor. Aunque el código tiene algo de organización con la separación de la creación de cada uno de los objetos gráficos, el constructor tiene una gran cantidad de lineas de código.

Una buena idea para organizar el código es el uso de métodos que nos ayuden a separar la creación de objetos gráficos de acuerdo a varios criterios, algunos de ellos podrían ser por sus tipos, por contenido, por contexto etc. Por ejemplo en el login se puede realizar la creación de métodos que separe de acuerdo al tipo de objetos y con base a esto crear un método llamado crearJPanels() y se inserta la creación de todos los objetos tipo JPanel allí.

public void crearJPanels(){
  pIzquierda = new JPanel();
  pIzquierda.setSize(600, 500);
  pIzquierda.setLocation(0, 0);
  pIzquierda.setBackground(Color.white);
  pIzquierda.setLayout(null);
  this.add(pIzquierda);

  pDerecha = new JPanel();
  pDerecha.setSize(400, 500);
  pDerecha.setLocation(600, 0);
  pDerecha.setBackground(Color.white);
  pDerecha.setLayout(null);
  this.add(pDerecha);
}

Ahora se crea otro método llamado crearJTextfields() y se inserta la creación de los objetos gráficos tipo JTextField.

public void crearJTextFields(){
  tNombreUsuario = new JTextField("Nombre Usuario");
  tNombreUsuario.setSize(260, 40);
  tNombreUsuario.setLocation((pDerecha.getWidth() - tNombreUsuario.getWidth()) / 2, 130);
  tNombreUsuario.setForeground(colorPrincipal);
  tNombreUsuario.setBackground(Color.WHITE);
  tNombreUsuario.setCaretColor(colorGrisOscuro);
  tNombreUsuario.setBorder(bInferiorAzul);
  tNombreUsuario.setHorizontalAlignment(SwingConstants.CENTER);
  pDerecha.add(tNombreUsuario);
}

Otro método podría ser el de crearObjetosDecoradores donde se inserta la creación de todos los objetos de este tipo:

public void crearObjetosDecoradores(){
  colorPrincipal = new Color(60, 78, 120);
  colorGrisOscuro = new Color(80, 80, 80);
  fontTPrincipal = new Font("Rockwell Extra Bold", Font.PLAIN, 20);
  fontTitulo = new Font("Calibri (Cuerpo)", Font.BOLD, 17);
  fontSubtitulo = new Font("Forte", Font.PLAIN, 13);
  fontMediana = new Font("LuzSans-Book", Font.PLAIN, 15);
  cMano = new Cursor(Cursor.HAND_CURSOR);
  bInferiorAzul = BorderFactory.createMatteBorder(0, 0, 2, 0, colorPrincipal);
  iFondo = new ImageIcon("Clase4/resources/images/fondo.png");
  iLogo = new ImageIcon("Clase4/resources/images/logo.png");
  iUsuario2 = new ImageIcon("Clase4/resources/images/usuario2.png");
  iClave2 = new ImageIcon("Clase4/resources/images/clave2.png");
  iPunto1 = new ImageIcon("Clase4/resources/images/punto1.png");
  iFacebook1 = new ImageIcon("Clase4/resources/images/facebook1.png");
  iTwitter1 = new ImageIcon("Clase4/resources/images/twitter1.png");
  iYoutube1 = new ImageIcon("Clase4/resources/images/youtube1.png");
  iSvg1 = new ImageIcon("Clase4/resources/images/imagen1.png");
  iCerrar = new ImageIcon("Clase4/resources/images/cerrar.png");
}

otros métodos de creación necesarios para la clase son:

public void crearJButtons(){
    ...
}

public void crearJLabels(){
    ...
}

public void crearJPasswordFields(){
    ...
}

public void crearJComboBoxes(){
    ...
}

public void crearJCheckBoxes(){
    ... // También se crea el objeto ButtonGroup aquí al ser un objeto auxiliar 
}

Una vez realizada la modularización, vale la pena aclarar varias aspectos:

Excepción

Existe una excepción para el objeto decorador iDimAux encargado de redimensionar las imágenes, este estará presente en los diferentes métodos de construcción respectiva al objeto gráfico al que se va a incorporar, ya que es un objeto auxiliar y es necesario dejarlo justo encima del objeto gráfico al que se incorpora, porque que esta variable estará cambiando constantemente con cada redimension nueva requerida.

¿Por que es posible hacer esta modularización?

Como se vio en las anteriores lecciones, la declaración de los objetos gráficos y objetos decoradores se realiza de forma global en la clase ya que se ubica al inicio de la misma, haciendo de estos objetos atributos de la clase.

Esto permite que cualquier entorno interno (Método) dentro de la clase pueda conocer cada uno de estos objetos gráficos. Por ejemplo si en un caso hipotético se realizara la declaración de los paneles dentro del método crearJPanels() estos objetos gráficos solo existirían dentro de ese método y cuando se quiera agregar el JTextField creado en el método crearJTextFields() al panel pDerecha saltará un error porque para ese método el panel pDerecha no existe.

Es por esta razón que la declaración se hace de forma global y como atributos de la clase separando la declaración de la ejemplificación. La declaración ira siempre al empezar las clases, la ejemplificación ira dentro de cada uno de los métodos.

Aunque no todos los objetos gráficos o decoradores tienen que ser atributos, por ejemplo un ButtonGroup que solo afecta a los objetos JCheckBox se puede crear como variable en el método crearJCheckBoxes() y como probablemente este objeto no se necesite para nada más en el futuro se podría tratar como una variable dentro de este método. El programador debe elegir cual de los objetos gráficos y objetos Decoradores necesita declarar globalmente o como variable dentro de un entorno. Sin embargo nunca se sabe cuando se podría necesitar alguno de estos en otro contexto (otras clases) así que es preferible mantener todos los objetos gráficos y los objetos Decoradores como atributos de la clase.

Ejecución de métodos de creación desde el constructor

Una vez pasados todos los objetos gráficos y objetos Decoradores a sus respectivos métodos, el constructor se verá así:

Se puede notar que lo único que esta dentro del constructor es la configuración de la ventana. Si se ejecuta la aplicación se observa que no se verá nada.

Esto es por que se debe que llamar desde el constructor a los métodos de creación. Por ejemplo al llamar estos 4 métodos de creación :

La aplicación se vera así.

Por lo que es necesario llamar a todos estos métodos de creación dentro del constructor.

Organización en el eje Z y de métodos de creación

Se debe tener en cuenta la organización de los objetos con respecto al eje z como se discutió en la lección anterior. Eso quiere decir que hay que tener cuidado en el orden en que se van a llamar los métodos. Por ejemplo:

Si llamamos el método crearJTextFields() antes del método crearJPanels() ocurrirá un error por que no es posible añadir un objeto gráfico a un panel que aun no se ha creado.

Si llamamos el método crearObjetosDecoradores() después de llamar cualquier otro método que crea objetos gráficos en los que se incorporan objetos decoradores ocurrirá un error.

Si llamamos el método crearJLabels() antes de llamar el método de crearJButtons() el fondo del login tapara los botones en el panel pIzquierda.

Entonces es necesario que el programador tenga en cuenta la organización en la llamada de los métodos de creación. Una organización apropiada para este caso puede ser:

Ventajas de este enfoque

El código esta más organizado, cuando se quiera cambiar la configuración de algún botón ya no será una tarea tediosa el tener que encontrarlo dentro del constructor, ahora solo hay que enfocarse en el método encargado de la creación de botones y cambiar lo que sea necesario.

Ademas para poder concentrarse aun mejor en una parte del

ALGORITHMICALLY RELATED

Similar Open-Source Projects

Selected from shared topics, language and repository description—not editorial ratings.

lfelipemarin /

AirUsProf

★ 4

Proyecto General Una importante Aerolínea que provee servicios a nivel global desea desarrollar un nuevo sistema integrado para la gestión de vuelos, reservas y socios. Dentro del alcance de dicho sistema se incluye: 1. Puntos de venta: Estos puntos de venta proveerán servicios de compra y reserva de pasajes, y gestión de socios. Existirán entre 5 y 20 oficinas de la Aerolínea en al menos 100 ciudades del mundo. 2. Servicios on-line: A partir de una aplicación Web se proveerán servicios de compra y reserva de pasajes. Es posible que se puedan hacer check – in a través del móvil del usuario. 3. Gestión en aeropuertos: En cada aeropuerto existirán entre 10 y 50 computadores ubicados en los puntos de check-in y en las puertas de embarque que serán utilizados por empleados de la aerolínea. 4. Gestión Operativa: Las mismas del punto anterior 5. Aplicación Movil. El usuario podrá hacer consulta de vuelos, reservas, pagos y check in por medio de su smatphone o Tablet. Cabe anotar que el check - in tendrá generado además un código QR para escaneo en los filtros del aeropuerto. 6. Sistema de PQRS( Peticiones, Quejas, Reclamos y Solicitudes). Este modulo será utilizado solo por el personal del Call Center de la aerolinea. Se atenderán los PQRS de los clientes, sobre aspectos como los cambios, cancelación o activación de reservas, incidencias con la venta de tiquetes o reservas, opiniones de los usuarios, solicitudes especiales (sillas de ruedas, oxigeno, asignación de asientos, asensos de clase, redención de millas, perdida de vuelos, entre otras). Cada PQRS será emitido con un código especial para posterior seguimiento por parte del cliente. 7. Seguridad: El módulo estará formado por: la definición y configuración de un certificado digital mediante SSL (Secure Socket Layer) y por medio del protocolo HTTPS que deberá instalarse en el servidor de aplicaciones; además, comprenderá la definición de políticas de acceso, autenticación y autorización de usuarios del sistema, los cuales estarán configurados por roles. También se deberá configurar el acceso por sesiones, las cuales estarán gestionadas por el servidor de aplicaciones. El sistema contendrá una pantalla de ingreso con login y password (Este deberá estar debidamente encriptado en la base de datos). Este módulo realizará la integración de los demás módulos del sistema garantizando que los roles de los usuarios se ajusten a las distintas opciones de cada menú o formulario. Se contempla la identificación y desarrollo de los casos de uso relacionados con la seguridad así como el análisis de requisitos y el diseño del modulo. Puntos de venta. Cada una de las oficinas contará con no más de 10 PCs para atender a clientes que desean reservar y adquirir pasajes. Adicionalmente se podrá dar de alta nuevos socios, modificar sus datos personales y consultar la cantidad de millas acumuladas. Los socios podrán tener 3 categorías. Categoría 1. Socio Elite  Millas acumuladas por cada trayecto 1000  Total máximo de Equipaje a facturar 2 Maletas de 25 Kg cada una y una maleta de mano de 10 Kg  Acceso a clase turista Categoría 2. Socio Gold  Millas acumuladas por cada trayecto 2500  Total máximo de Equipaje a facturar 2 Maletas de 35 Kg cada una y una maleta de mano de 10 Kg  Acceso a Clase Turista Categoría 3. Socio Silver  Millas acumuladas por cada trayecto 5000  Total de Equipaje a facturar 4 Maletas de 35 Kg cada una y una maleta de mano de 10 Kg  Acceso a Primera clase Se ha establecido que cada socio podrá redimir sus millas por otros trayectos si tienen un mínimo acumulado de 50000 millas se podrán ser utilizadas así: Redención Vuelos Nacionales: Temporada Baja 50000 millas por un trayecto. Temporada Alta 80000 Millas por un trayecto Redención Vuelos Internacionales: Temporada Baja 70000 millas por un trayecto (Destinos América). Temporada Alta 90000 Millas por un trayecto (Destinos América) Temporada Baja 90000 millas por un trayecto (Destinos Europa). Temporada Alta 140000 Millas por un trayecto (Destinos Europa)  Las temporadas Bajas van de los meses de Marzo a Mayo y de Septiembre a Noviembre  Las temporadas Altas van de los meses de Diciembre a Febrero y de Junio a Agosto. Cada uno de los PCs en los puntos de venta cuenta con procesadores Intel Pentium 4, con 512 Mb de memoria RAM y 100 Gb de disco y sistema operativo Windows XP o superior. Todos estos PCs están conectados en red y acceden al sistema central de reservas a partir de un enlace ADSL de 2 Mbits/seg. Se definen los siguientes requerimientos para los puntos de venta: 1. RF1. Alta de socios. 2. RF2. Modificación de datos personales de socios. 3. RF3. Reserva de vuelos (venta contado y crédito de pasajes) 4. RF4. Solicitud de Reserva de Sillas (Se debe tener en cuenta si es clase turista o ejecutiva). 4. RF5. Compra y canje de millas. 5. RF6. Reporte de millas para socios. 6. RF7. Redención de millas a socios 6. RNF1. Los agentes de viaje deberán identificarse en el sistema a partir de un usuario y contraseña. 7. RNF2. En caso de fallas de conexión con el sistema central, el sistema debe permitir operar normalmente, sincronizando posteriormente la información con el sistema central. 8. RNF3. El sistema se deberá comunicar con el sistema financiero autorizador de tarjetas de crédito para las ventas a crédito (Por ejemplo sistema de pago PSE o PayPal). En caso de que el mismo no se encuentre disponible, el sistema deberá solicitar la autorización manual. 9. RNF4. La información de las reservas de los vuelos deberá estar disponible a las otras sucursales y servicios on-line en un máximo de 30 minutos. 10. RNF5. La información de los socios deberá estar disponible a las otras sucursales y servicios on-line en un máximo de 4 horas. Servicios on-line. Se deberá proveer los siguientes servicios a los clientes mediante una aplicación web: 1. RF1. Consulta de vuelos (itinerarios, tarifas, disponibilidad de asientos, etc.) 2. RF2. Reserva y compra crédito de pasajes (compra pasaje con tarjeta crédito). 3. RF3. Compra y canje de millas (compra pasaje con millas). 4. RF4. Registro de socios. 5. RF5. Modificación datos socios. 6- RF6- Reserva de sillas en la cabina. (Tener en cuenta si es clase turista o ejecutiva) 7- RF7. Realización de check-in por el móvil del usuario (Requisito opcional). 8- RF8- Generación e impresión de pasabordo del usuario con código de barras de control. Los requerimientos funcionales RF3 y RF5 requieren que el usuario previamente se autentique en el sistema utilizando su identificador de socio y contraseña. Para estos requerimientos además, el sistema deberá enviar al socio un correo electrónico notificando el resultado de la transacción. Los aspectos de seguridad son vitales para lograr una buena imagen de la empresa y para que los socios puedan utilizar los servicios on-line frecuentemente sin riesgos. Adicionalmente, debido a la intensa competencia que presentan otras aerolíneas, es deseable que el sitio web sea sumamente eficiente y visualmente atractivo para los usuarios. Por eso mismo también es necesario lograr que los usuarios se familiaricen rápidamente con el sistema on-line y que el mismo esté disponible las 24 horas del día, los 7 días de la semana. Gestión en Aeropuertos Cada uno de los PCs ubicados en los puntos de check-in y en las puertas de embarque contaran con procesadores Pentium D de 3.0Ghz, con 2Gb de memoria RAM y 200Gb de disco y utilizaran un sistema operativo Linux. Todos estos PCs se comunican con el sistema central mediante una conexión de fibra óptica. Los funcionarios de la Aerolínea ubicados en los puestos de check-in y en las puertas de embarque utilizaran los siguientes servicios del sistema: 1. RF1. Consulta de reservas de pasajeros. 2. RF2. Check-in de equipaje de pasajeros 3. RF3. Consulta de estado y ubicación de equipaje. 4. RF4. Consulta de Pasajeros embarcados y confirmados. 5. RF5. Asignación de puerta de embarque y control de horarios de llegada y salida Adicionalmente, podrán realizar modificaciones de los vuelos de los pasajeros, modificaciones de itinerarios y horarios en casos de retrasos en los vuelos o retrasos de los pasajeros. Para evitar retrasos en los pasajeros y largas colas es crítico que esta funcionalidad se ejecute de forma eficiente y que el sistema se encuentre 100% disponible. Gestión Operativa En este modulo se deberá gestionar y planear las rutas de vuelos, horarios y frecuencias , tripulación, aviones, servicios de combustible y gastos operativos por uso de plataformas. RF1. Planeación de rutas y frecuencias horarias. RF2. Tripulación por cabina. Se definirá así: para vuelos nacionales 1 piloto, 1 copiloto, 3 azafatas o auxiliares de cabina. Para vuelos internacionales 1 piloto, 1 copiloto, 6 azafatas o auxiliares de cabina. RF3. Administración de aviones. La aerolínea para vuelos nacionales cuentan con 40 aviones Airbus A320-200 configurados de la siguiente forma. Cabina primera clase 10 pasajeros (4 sillas por fila). Cabina clase turista 170 pasajeros (6 sillas por cada fila). Para vuelos internacionales cuentan con 20 aviones Airbus A330-200 configurados de la siguiente forma. Cabina primera clase 30 pasajeros (6 sillas por fila). Cabina clase turista 220 pasajeros (8 sillas por cada fila). Por cada avión debe existir una bitácora de vuelo conformado por los siguientes datos. Código de Vuelo, Código de Plan de Vuelo, Ruta asignada (Origen- Destino), fecha y hora de salida. Fecha y hora de llegada. Escalas si existen, número de pasajeros embarcados, número de tripulantes, peso general de equipaje y carga, cantidad de combustible en libras, incidentes si existen. RF4. Operación. Se refiere al control de gastos operativos en aeropuerto e incluye Tanqueo general (Proveedor, cantidad de combustible en libras, precio por libra, precio total + impuesto). Costos sobre plataforma (cobro por hora en plataforma, impuesto aeroportuario). Otros requerimientos Esta planificado que dentro de los próximos 3 o 4 años, la Aerolínea se fusione con otra importante empresa del rubro. Sin embargo, debido a la inversión que representa el desarrollo de este sistema, se requiere que el mismo este vigente por al menos 9 años. Por este motivo, será necesario que el sistema soporte mecanismos que permitan modificar fundamentalmente su interfaz grafica y la lógica correspondiente a la gestión de socios y mecanismos de acumulación de millas. Restricciones Técnicas El sistema será implementado utilizando el lenguaje Java con las APIs de JEE ver 6 o 7. El IDE será Netbeans 7.3 o superior . El servidor de Aplicaciones será Glasfish ver 3 .1 o superior. El sistema deberá contar con por lo menos 5 capas definidas de la siguiente manera: 1. Capa Web: Deberá utilizarse el framework JSF 2.2 con PRIMEFACES. 2. Capa Seguridad: Estará compuesta por un componente de acceso por login y password utilizando roles y permisos de acceso. Esta capa incluye la autenticación, autorización e integración con todos los módulos del sistema. También deberá utilizarse certificados digitales. Se recomienda un sistema centralizado de control de usuarios por medio de directorios activos como LDAP, por lo que se utilizará el software OpenDS (Opensource). 3. Capa Lógica de Negocio: Estará compuesta por Session Beans. 4. Capa Persistencia: Estará compuesta por Entity Beans y utilizarà un framework de acceso a datos y ORM (Object Relational Mapping) como Hibernate o JPA. 5. Capa de Datos: Esta compuesta por las entidades y relaciones que integran la Base de Datos y que deberá estar gestionada por el DBMS.

InterfazGraficaJavaClase4