Un boceto

Todo desarrollo de una aplicación tiene el gran problema de la FALTA DE ENTENDIMIENTO. Esta a todos los niveles:

• Con el cliente: Por muy bien que el cliente explique lo que quiere y por muy bien que sepamos plasmarlo en una aplicación siempre habrá problemas de requerimientos en fases finales del desarrollo ya que puede que el cliente no se explicó bien en su dia, nosotros entendimos otra cosa, etc (a que te suenan estos motivos)….
• Con el equipo de desarrollo: Puede que la documentación tenga fallos o que simplemente al explicar (decir con palabras a otra persona) una funcionalidad el desarrollador entienda una cosa que sea muy diferente que lo que tiene el analista en mente.

El primer paso, o uno de los primeros, cuando ya se tiene clara la aplicación es hacer un boceto. La mejor forma de hacer un boceto es con un entorno web de páginas estáticas. Es ideal porque toda aplicación (sea web o no) se puede representar como un entorno web, es muy grafico y es muy rápido de hacer.

Puedes elegir el software que quieras pero yo te recomiendo el Microsoft Publisher. Es de pago pero me extraña que en tu empresa no tengan pagada la licencia del Microsoft Office. Recomiendo hacer el boceto con el Publisher porque esta más orientado al aspecto de la pagina web que ofrecer funcionalidad (solo ofrece hiperviculos), esto es muy importante por los siguientes factores:

• Si haces el boceto muy pobre gráficamente seguramente tu cliente no lo tenga muy en cuenta.
• Si tu boceto (que no deja de ser un entorno web) tiene mucha funcionalidad el cliente te puede pedir cosas como:”oye si al boceto le incluyes algo de código real ¿podríamos usarlo ya para…”. Esto implicaría un desarrollo adicional y además si el cliente ve que el boceto mejorado ya le sirve puede que no quiera la aplicación principal.

Reglas de pruebas. Cambio de configuración

Concepto cambio de configuración

Un cambio de configuracion es modificar un elemento que establece un comportamiento por otro elemento. Partiendo de esta base, un cambio de configuración abarca desde cambiar un valor entero en un fichero properties por otro como cambiar en una clase la carga de una clase por otra.

En una prueba no se puede modificar el codigo que se va a probar pero si la configuracion. Si para hacer una prueba se tiene que modificar una clase entonces corremos el fallo de dejar modificada la clase una vez terminada las pruebas o que dicha modificación solucione un problema. Lo que debemos hacer es cambiar la configuración en pruebas si no se puede usar la original.

Caso: Una impresora

Tenemos una clase GestionDocumento:

public class GestionDocumento {

…

private impresora IImpresora;

…

public GestionDocumento (){

impresora = new IImpresoraImpl();

}

…

public void Imprimir (){

…

impresora.imprimir (datos);

…

}

...

}

IImpresora debe ser una interfaz de la clase que implemente la funcionalidad de la impresora. De esta manera, si se hace una prueba de impresión y no disponemos de la impresora se podrá seguir realizando la prueba solo hay que cambiar la instancia:

…

public GestionDocumento (){

// impresora = new IImpresoraImpl();

impresora = new IImpresoraImplPrueba();

}

…

Y el resto de la clase GestionDocumento seguirá funcionando igual.

Fin del Swing, empieza el JavaFX 2.0

La tecnología Flash ha sido el máximo exponente en ofrecer una interfaz gráfica de alto nivel(1) para la WEB. La respuesta JAVA para competir con esta tecnología es JavaFX. Las primeras versiones de JavaFX usaban un lenguaje Script distinto del lenguaje Java de toda la vida para ganar en flexibilidad a la hora de programar. Esta fue una jugada ingeniosa por parte de SUN ya que una de las grandes ventajas de Flash es la potencia para crear aplicaciones con “pocas líneas de código” pero fue muy mal implementada ya que este lenguaje Script no reducía las líneas de código.

Desde Octubre del 2011 ya está disponible la versión 2.0 de JavaFx. Esta versión permite crear aplicaciones JavaFX como si fuese una aplicación Swing común, sin usar el lenguaje Script de JavaFx, como se puede ver en el siguiente ejemplo:

import javafx.application.Application;

import javafx.event.ActionEvent;

import javafx.event.EventHandler;

import javafx.scene.Group;

import javafx.scene.Scene;

import javafx.scene.control.Button;

import javafx.stage.Stage;

/**

*

* @author cnavarros

*/

public class Main extends Application {

/**

* @param args the command line arguments

*/

public static void main(String[] args) {

Application.launch(args);

}

@Override

public void start(Stage primaryStage) {

primaryStage.setTitle("Hello World");

Group root = new Group();

Scene scene = new Scene(root, 300, 250);

Button btn = new Button();

btn.setLayoutX(100);

btn.setLayoutY(80);

btn.setText("Hello World");

btn.setOnAction(new EventHandler() {

public void handle(ActionEvent event) {

System.out.println("Hello World");

}

});

root.getChildren().add(btn);

primaryStage.setScene(scene);

primaryStage.show();

}

}

El uso de JavaFx puede plantearse como mejora de una aplicación ya existente y que este implementada en Swing ya que JavaFx 2.0 puede usarse en Swing (ejemplo http://blogs.oracle.com/javafx/entry/how_to_use_javafx_in).

Otra gran mejora es la posibilidad de definir TODA la interfaz grafica (botones, panales, cuadros de texto, animaciones, etc..) en un XML usando la tecnología FXML. Como se puede ver en el siguiente ejemplo:

Da como resultado la aplicación:

Esta forma de trabajar ya se utiliza en otras plataformas como Android y permite separar de forma “contundente” la parte grafica de la parte de lógica de la aplicación. Ademas permite terminar con las clases “Panel” de Swing donde solo hay líneas de JAVA para definir la interfaz que ensucian el código y se mezclan con la lógica de la aplicación.

Una aplicación implementada usando JavaFx puede usarse también como una aplicación WEB (via jnpl o como un Appet dentro de una página WEB).

Lo que me preocupa es el rendimiento. Las primeras versiones de JavaFx no ofrecían un rendimiento muy bueno y tanta flexibilidad como ofrece JavaFx 2.0 siempre va en contra de ofrecer mejor rendimiento pero, como se puede leer en la pagina de JavaFx 2.0 http://javafx.com/faq/ , en esta versión se ha puesto incapie en el rendimiento. Esto, unido a su gran compatibilidad con Swing, le hace ser la opción lógica a la hora de desarrollar aplicaciones por delante de otras plataformas como Swing, Applets y Flash.

(1) -->Con alto nivel me refiero a mini aplicaciones que se descargan con la pagina WEB y ofrecen más potencia grafica que los clásicos “objetos” HTML.