MySql

MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario con más de seis millones de instalaciones.^[1] MySQL AB desarrolla MySQL como software libre en un esquema de licenciamiento dual. MySQL AB pertenece a Sun Microsystems desde enero de 2008.

Polimorfismo

En Java, el polimorfismo de métodos se implementa con la sobrecarga de métodos: métodos con el mismo nombre, y mismo número y tipo de argumentos.

Una variable también puede ser polimórfica, es decir, cambiar de forma o de clase de objeto al que referencia durante la ejecución de un programa. El polimorfismo de una variable en Java está limitado de tal forma que una variable que referencia a un objeto sólo puede especializarse, tal y como ocurre en la vida real.

Ejemplo con polimorfismo en el método canta y en la variable fulanito

class Persona{

private String nombre;

protected String cancion;

public void canta(){System.out.println("la la la");}

} //End Persona

class Ladron extends Persona{

private int ganancias;

public void canta(){System.out.println("Yo no he sido");}

public void roba(int n){ ganancias= ganancias + n; }

} //End Ladron

class Juez extends Persona {

public void canta() {System.out.println("Soy la ley");}

} //End Juez

public class Poli5 {

// ejemplo de polimorfismo de mensaje canta

public static void main(String args[])

{

Persona fulanito = new Persona();

Ladron ladroncito = new Ladron();

Juez juececito = new Juez();

fulanito.canta(); // canta una persona

fulanito = ladroncito;

fulanito.canta(); // canta un ladrón

fulanito.roba(100);

//error de compilación: fulanito es Persona. ¿Solución?

fulanito = juececito;

fulanito.canta (); // canta un juez

}

} // End Poli5

Restricción en Java al polimorfismo sintáctico: cambio a subclases o especialización.

Verificación estática de tipos: tiempo de compilación.

Casos de uso

Los diagramas de UML se pueden dividir en estáticos (aportan una visión estática del sistema) y dinámicos (aportan una visión dinánica del sistema).

Los diagramas estáticos:

· Diagrama de casos de uso

· Diagrama de clases

· Diagrama de objetos

· Diagrama de componentes

· Diagrama de despliegue

Los diagramas dinámicos:

· Diagrama de estados

· Diagrama de actividad

· Diagramas de interacción:

o Diagrama de secuencia

o Diagrama de colaboración

Diagramas de casos de uso.

Los diagramas de casos de uso muestran la funcionalidad del sistema desde la perspectiva que tienen los usuarios y lo que el sistema debe de hacer para satisfacer los requisitos propuestos. Pueden mostrar el comportamiento de un sistema completo o de una parte.

Los elementos básicos que se utilizan son:

1. Actores: Son los diferentes usuarios y el papel que representan dentro del sistema.

2. Caso de uso: Representan todo lo que el usuario puede realizar dentro del sistema

3. Relaciones: Para asociar los elementos anteriores.

Comunicación

Generalización

Extensión (*)

Inclusión (*)

(*) En estas dos se deben de poner también las letras (include, o exclude).

Ejemplo:

Contenedor EJB

Con la tecnología J2EE Enterprise JavaBeans es posible desarrollar componentes (enterprise beans) que luego puedes reutilizar y ensamblar en distintas aplicaciones que tengas que hacer para la empresa.
El desarrollo basado en componentes promete un paso más en el camino de la programación orientada a objetos. Con la programación orientada a objetos puedes reutilizar clases, pero con componentes es posible reutilizar n mayor nivel de funcionalidades e incluso es posible modificar estas funcionalidades y adaptarlas a cada entorno de trabajo particular sin tocar el código del componente desarrollado.
En este momento podemos ver un componente como un objeto tradicional con un conjunto de servicios adicionales soportados en tiempo de ejecución por el contenedor de componentes. El contenedor de componentes se denomina contenedor EJB y es algo así como el sistema operativo en el que éstos residen. Recuerda que en Java existe un modelo de programación de objetos remotos denominado RMI. Con RMI es posible enviar peticiones a objetos que están ejecutándose en otra máquina virtual Java. Podemos ver un componente EJB como un objeto remoto RMI que reside en un contenedor EJB que le proporciona un conjunto de servicios adicionales.

Servicios proporcionados por el contenedor EJB

• Manejo de transacciones: apertura y cierre de transacciones asociadas a las llamadas a los métodos del bean.
• Seguridad: comprobación de permisos de acceso a los métodos del bean.
• Concurrencia: llamada simultánea a un mismo bean desde múltiples clientes.
• Servicios de red: comunicación entre el cliente y el bean en máquinas distintas.
• Gestión de recursos: gestión automática de múltiples recursos, como colas de mensajes, bases de datos o fuentes de datos en aplicaciones heredadas que no han sido traducidas a nuevos lenguajes/entornos y siguen usándose en la empresa.
• Persistencia: sincronización entre los datos del bean y tablas de una base de datos.
• Gestión de mensajes: manejo de Java Message Service (JMS).
• Escalabilidad: posibilidad de constituir clusters de servidores de aplicaciones con múltiples hosts para poder dar respuesta a aumentos repentinos de carga de la aplicación con sólo añadir hosts adicionales.
• Adaptación en tiempo de despliegue: posibilidad de modificación de todas estas características en el momento del despliegue del bean.

Funcionamiento de los componentes EJB

El funcionamiento de los componentes EJB se basa fundamentalmente en el trabajo del contenedor EJB. El contenedor EJB es un programa Java que corre en el servidor y que contiene todas las clases y objetos necesarios para el correcto funcionamiento de los enterprise beans.

En la figura siguiente puedes ver una representación de muy alto nivel del funcionamiento básico de los enterprise beans. En primer lugar, puedes ver que el cliente que realiza peticiones al bean y el servidor que contiene el bean están ejecutándose en máquinas virtuales Java distintas. Incluso pueden estar en distintos hosts. Otra cosa a resaltar es que el cliente nunca se comunica directamente con el enterprise bean, sino que el contenedor EJB proporciona un EJBObject que hace de interfaz. Cualquier petición del cliente (una llamada a un método de negocio del enterprise bean) se debe hacer a través del objeto EJB, el cual solicita al contenedor EJB una serie de servicios y se comunica con el enterprise bean. Por último, el bean realiza las peticiones correspondientes a la base de datos.

El contenedor EJB se preocupa de cuestiones como:

• ¿Tiene el cliente permiso para llamar al método?
• Hay que abrir la transacción al comienzo de la llamada y cerrarla al terminar.
• ¿Es necesario refrescar el bean con los datos de la base de datos?

representación de alto nivel del funcionamiento de los enterprise beans.

Anotaciones

En programación, una Anotación Java es una forma de añadir metadatos al código fuente Java que están disponibles para la aplicación en tiempo de ejecución. Muchas veces se usa como una alternativa a la tecnología XML.

Las Anotaciones Java pueden añadirse a los elementos de programa tales como clases, métodos, campos, parámetros, variables locales, y paquetes. Al contrario que las etiquetas añadidas a la documentación Java y procesadas con las herramientas tales como XDoclet, las Anotaciones Java son completamente accesibles al programador mientras que el software se ejecuta usando reflexión.

Las Anotaciones toman la forma de una declaración de interfaz con un caracter @ precediéndola, y marcada opcionalmente con meta-anotaciones, como se ve debajo:

 @Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})

Las Anotaciones permiten al programador declarar en su código fuente
cómo debe comportarse el software. Esto es un ejemplo de cómo las
construcciones de la Programación declarativa pueden añadirse al lenguaje procedimental.

EJBs en JBoss

EJBs en JBoss

La arquitectura de EJBs en JBoss está basada en la funcionalidad que provee la clase Proxy del paquete java.lang.reflect (esta clase apareció en la versión 1.3)

La clase Proxy es una clase especial que nos permite interceptar un conjunto de métodos definidos en un interfaz.

Para una breve explicación ver: http://www.javalobby.org/java/forums/t18631.html

Cuando nosotros en JBoss, hacemos un lookUp del Interfaz Home o del Interfaz Remoto de un EJB, lo que obtenemos en realidad es una clase de tipo Proxy que encapsula la funcionalidad de ambos interfaces. La imágen que se muestra a continuación explica un poco toda esta arquitectura (esta imágen está obtenida de la documentación de JBoss)

Toda esta arquitectura nos ahorra el problema de tener que compilar los EJBs para crear los stubs y los skeletons.

Todas las invocaciones a los métodos de la clase Proxy son delegadas sobre el ClientContainer, que está compuesto por una cadena de Interceptores (clases que extienden la clase org.jboss.proxy.Interceptor que serán los manejadores reales de la funcionalidad). Nosotros podemos añadir o quitar funcionalidad modificando la cadena de interceptores.

El único que no podemos eliminar es el último interceptor, que será el que gestiones la comunicación con el servidor. Este último interceptor podrá ser RMI, RMI en cluster, HTTP, HTTP en cluster, CORBA etc... . En el lado servidor, existirá un componente (detached invoker) que hablará con el cliente (último invoker de la cadena) y nos pondrá en contacto con el contenedor de EJBs a través del servidor JMX de MBeans: (la imágen también está obtenida de la documentación de JBoss)

Toda esta arquitectura de EJBs es modificable en el fichero de configuración:
\server\\conf\standardjboss.xml

También podemos cambiar la configuración de esta arquitectura para un EJB usando su descriptor jboss.xml.

Refactorizacion

La refactorización es una técnica de la ingeniería de software para reestructurar un código fuente, alterando su estructura interna sin cambiar su comportamiento externo.

Servidor de aplicaciones

En informática se denomina servidor de aplicaciones a un servidor en una red de computadores que ejecuta ciertas aplicaciones

Usualmente se trata de un dispositivo de software que proporciona servicios de aplicación a las computadoras cliente. Un servidor de aplicaciones generalmente gestiona la mayor parte (o la totalidad) de las funciones de lógica de negocio y de acceso a los datos de la aplicación. Los principales beneficios de la aplicación de la tecnología de servidores de aplicación son la centralización y la disminución de la complejidad en el desarrollo de aplicaciones. Si bien el término es aplicable a todas las plataformas de software, hoy en día el término servidor de aplicaciones se ha convertido en sinónimo de la plataforma J2EE de Sun Microsystems.

Un ejemplo común del uso de servidores de aplicación (y de sus componentes) son los portales de Internet, que permiten a las empresas la gestión y divulgación de su información, y un punto único de entrada a los usuarios internos y externos. Teniendo como base un servidor de aplicación, dichos portales permiten tener acceso a información y servicios (como servicios Web) de manera segura y transparente, desde cualquier dispositivo.

Interceptores

(Interceptores)Factorias de session que se recargan según eventos:

De esta forma no recargamos las llamadas a la base de datos:

@Stateful
@Scope(SESSION)
@Name("bookingList")
@Restrict("#{identity.loggedIn}")
@TransactionAttribute(REQUIRES_NEW)
public class BookingListAction implements BookingList, Serializable
{
.......

@Factory
@Observer("bookingConfirmed")
public void getBookings()
{
bookings = em.createQuery("select b from Booking b where b.user.username = :username order by b.checkinDate")
.setParameter("username", user.getUsername())
.getResultList();
}
........
}
@Stateful
@Name("hotelBooking")
@Restrict("#{identity.loggedIn}")
public class HotelBookingAction implements HotelBooking
{
...

@End
public void confirm()
{
em.persist(booking);
facesMessages.add("#{messages.gracias}, #{user.name}, your confimation number for #{hotel.name} is #{booking.id}");
log.info("New booking: #{booking.id} for #{user.username}");
events.raiseTransactionSuccessEvent("bookingConfirmed");
}
...
}

OOP (Programación orientada a objetos)

La Programación Orientada a Objetos es un paradigma de programación que usa objetos y sus interacciones para diseñar aplicaciones y programas de computadora. Está basado en varias técnicas, incluyendo herencia, modularidad, polimorfismo, y encapsulamiento. Actualmente son muchos los lenguajes de programación que soportan la orientación a objetos.

Los objetos son entidades que combinan estado, comportamiento e identidad:

• El estado está compuesto de datos, serán uno o vários atributos a los que se habrán asignado unos valores concretos (datos).
• El comportamiento está definido por los procedimientos o métodos con que puede operar dicho objeto, es decir, qué operaciones se pueden realizar con él.
• La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variable o una constante).

La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutilizar.

De esta forma, un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separan ni deben separarse el estado y el comportamiento.

Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a ninguno de ellos, hacerlo podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una programación estructurada camuflada en un lenguaje de programación orientado a objetos.

Características de la POO

• Abstracción: Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción.
• Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.
• Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.
• Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.
• Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que reimplementar su comportamiento. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple; esta característica no está soportada por algunos lenguajes (como Java).

AOP (Programación orientada a aspectos)

La Programación Orientada a Aspectos (POA) es un paradigma de programación relativamente reciente cuya intención es permitir una adecuada modularización de las aplicaciones y posibilitar una mejor separación de conceptos. Gracias a la POA se pueden encapsular los diferentes conceptos que componen una aplicación en entidades bien definidas, eliminando las dependencias entre cada uno de los módulos. De esta forma se consigue razonar mejor sobre los conceptos, se elimina la dispersión del código y las implementaciones resultan más comprensibles, adaptables y reusables. Varias tecnologías con nombres diferentes se encaminan a la consecución de los mismos objetivos y así, el término POA es usado para referirse a varias tecnologías relacionadas como los métodos adaptivos, los filtros de composición, la programación orientada a sujetos o la separación multidimensional de competencias.

Conceptos Básicos

• Aspect (Aspecto) es la funcionalidad que se cruza a lo largo de la aplicación (cross-cutting) que se va a implementar de forma modular y separada del resto del sistema. El ejemplo más común y simple de un aspecto es el logging (registro de sucesos) dentro del sistema, ya que necesariamente afecta a todas las partes del sistema que generan un suceso.
• Jointpoint (Punto de Cruce) es un punto de ejecución dentro del sistema donde un aspecto puede ser conectado, como una llamada a un método, el lanzamiento de una excepción o la modificación de un campo. El código del aspecto será insertado en el flujo de ejecución de la aplicación para añadir su funcionalidad.
• Advice (Consejo) es la implementación del aspecto, es decir, contiene el código que implementa la nueva funcionalidad. Se insertan en la apliacción en los Puntos de Cruce.
• Pointcut (Puntos de Corte) define los Consejos que se aplicarán a cada Punto de Cruce. Se especifica mediante Expresiones Regulares o mediante patrones de nombres (de clases, métodos o campos), e incluso dinámicamente en tiempo de ejecución según el valor de ciertos parámetros.
• Introduction (Introducción) permite añadir métodos o atributos a clases ya existentes. Un ejemplo en el que resultaría útil es la creación de un Consejo de Auditoría que mantenga la fecha de la última modificación de un objeto, mediante una variable y un método setUltimaModificacion(fecha), que podrían ser introducidos en todas las clases (o sólo en algunas) para proporcionarlas esta nueva funcionalidad.
• Target (Destinatario) es la clase aconsejada, la clase que es objeto de un consejo. Sin AOP, esta clase debería contener su lógica, además de la lógica del aspecto.
• Proxy (Resultante) es el objeto creado después de aplicar el Consejo al Objeto Destinatario. El resto de la aplicación únicamente tendrá que soportar al Objeto Destinatario (pre-AOP) y no al Objeto Resultante (post-AOP).
• Weaving es el proceso de aplicar Aspectos a los Objetos Destinatarios para crear los nuevos Objetos Resultantes en los especificados Puntos de Cruce. Este proceso puede ocurrir a lo largo del ciclo de vida del Objeto Destinatario:
  • Aspectos en Tiempo de Compilación, que necesita un compilador especial.
  • Aspectos en Tiempo de Carga, los Aspectos se implementan cuando el Objeto Destinatario es cargado. Requiere un ClassLoader especial.
  • Aspectos en Tiempo de Ejecución.

EJB3 (JBoss)

JBoss es un servidor de aplicaciones J2EE de código abierto implementado en Java puro. Al estar basado en Java, JBoss puede ser utilizado en cualquier sistema operativo que lo soporte. Los principales desarrolladores trabajan para una empresa de servicios, JBoss Inc., adquirida por Red Hat en Abril del 2006, fundada por Marc Fleury, el creador de la primera versión de JBoss. El proyecto está apoyado por una red mundial de colaboradores. Los ingresos de la empresa están basados en un modelo de negocio de servicios.

JBoss implementa todo el paquete de servicios de J2EE.

Los Enterprise JavaBeans (también conocidos por sus siglas EJB) son una de las API que forman parte del estándar de construcción de aplicaciones empresariales J2EE de Sun Microsystems (ahora JEE 5.0). Su especificación detalla cómo los servidores de aplicaciones proveen objetos desde el lado del servidor que son, precisamente, los EJBs:

• comunicación remota utilizando CORBA

• transacciones
• control de la concurrencia
• eventos utilizando JMS (Java messaging service)
• servicios de nombres y de directorio
• seguridad
• ubicación de componentes en un servidor de aplicaciones.

La especificación de Enterprise Java Bean define los papeles jugados por el contenedor de EJB y los EJBs, además de disponer los EJBs en un contenedor.

Existen tres tipos de EJBs:

• EJBs de Entidad (Entity EJBs): su objetivo es encapsular los objetos del lado del servidor que almacena los datos. Los EJBs de entidad presentan la característica fundamental de la persistencia:
  • Persistencia gestionada por el contenedor (CMP): el contenedor se encarga de almacenar y recuperar los datos del objeto de entidad mediante el mapeo de una tabla de la base de datos.
  • Persistencia gestionada por el bean (BMP): el propio objeto entidad se encarga, mediante una base de datos u otro mecanismo, de almacenar y recuperar los datos a los que se refiere, por lo cual, la responsabilidad de implementar los mecanismos de persistencia es del programador.
• EJBs de Sesión (Session EJBs): gestionan el flujo de la información en el servidor. Generalmente sirven a los clientes como una fachada de los servicios proporcionados por otros componentes disponibles en el servidor. Puede haber dos tipos:
  • con estado (stateful). Los beans de sesión con estado son objetos distribuidos que poseen un estado. El estado no es persistente, pero el acceso al bean se limita a un solo cliente.
  • sin estado (stateless). Los beans de sesión sin estado son objetos distribuidos que carecen de estado asociado permitiendo por tanto que se los acceda concurrentemente. No se garantiza que los contenidos de las variables de instancia se conserven entre llamadas al método.
• EJBs dirigidos por mensajes (Message-driven EJBs): son los únicos beans con funcionamiento asíncrono. Usando el Java Messaging System (JMS), se suscriben a un tema (topic) o a una cola (queue) y se activan al recibir un mensaje dirigido a dicho tema o cola. No requieren de su instanciación por parte del cliente.

La especificación EJB ha ido evolucionando a la par que lo hacía la propia especificación J2EE. Las diferentes versiones que han existido hasta la fecha son:

• EJB 1.0: la especificación original
• EJB 1.1: la primera incluida dentro de J2EE
• EJB 2.0: incluida en J2EE 1.3, añadía las interfaces Locales y los Message-Driven beans.
• EJB 2.1: incluida en la última revisión de J2EE, la 1.4.
• EJB 3.0: Ahora con Cluster y esta incluida en JEE 5.0

Existe una propuesta de una nueva revisión de la especificación de Enterprise JavaBeans, la EJB 3.0, cuyo objetivo es simplificar la implementación de beans sin por ello sacrificar su potencia y flexibilidad.

La nueva especificación de EJB 3.0 simplifica el proceso de creación de EJB y facilita la implementación de persistencia.

Esta especificación estará disponible en la nueva versión de J2EE nombrada JEE 5.0.

J2EE

Java Platform, Enterprise Edition o Java EE (anteriormente conocido como Java 2 Platform, Enterprise Edition o J2EE hasta la versión 1.4), es una plataforma de programación—parte de la Plataforma Java—para desarrollar y ejecutar software de aplicaciones en Lenguaje de programación Java con arquitectura de n niveles distribuida, basándose ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones. La plataforma Java EE está definida por una especificación. Similar a otras especificaciones del Java Community Process, Java EE es también considerada informalmente como un estándar debido a que los suministradores deben cumplir ciertos requisitos de conformidad para declarar que sus productos son conformes a Java EE; no obstante sin un estándar de ISO o ECMA.

Java EE incluye varias especificaciones de API, tales como JDBC, RMI, e-mail, JMS, Servicios Web, XML, etc y define cómo coordinarlos. Java EE también configura algunas especificaciones únicas para Java EE para componentes. Estas incluyen Enterprise JavaBeans, servlets, portlets (siguiendo la especificación de Portlets Java), JavaServer Pages y varias tecnologías de servicios web. Esto permite al desarrollador crear una Aplicación de Empresa portable entre plataformas y escalable, a la vez que integrable con tecnologías anteriores. Otros beneficios añadidos son, por ejemplo, que el servidor de aplicaciones puede manejar transacciones, la seguridad, escalabilidad, concurrencia y gestión de los componentes desplegados, significando que los desarrolladores pueden concentrarse más en la lógica de negocio de los componentes en lugar de en tareas de mantenimiento de bajo nivel.

TestNG

TestNG es un framework para pruebas y testing que trabaja con Java y está basado en JUnit (para Java) y NUnit (para .NET), pero introduciendo nuevas funcionalidades que los hacen más poderosos y fáciles de usar, tales como:

• Anotaciones JDK 5 (Annotations) (JDK 1.4 también es soportado con JavaDoc annotations).
• Configuración flexible de pruebas.
• Soporte para pruebas para data-driven testing (with @DataProvider).
• Soporte de pasaje de parámetros.
• Permite distribución de las pruebas en maquinas esclavas.
• Modelo de ejecución poderoso (TestSuite nunca más).
• Soportado por herramientas y plugins importantes y variados como: (Eclipse, IDEA, Maven, etc...).
• Permite embeber BeanShell para una flexibilidad más amplia.
• Funciones JDK por defecto de runtime y logging. (sin dependencias)
• Métodos dependientes para pruebas sobre servidores de aplicación.

TestNG está diseñado para cubrir todas las categorías de las pruebas: unitarias, funcionales, end-to-end, integración, etc.

EasyMock

EasyMock es una librería muy útil para hacer pruebas unitarias con JUnit (o derivado como TestNG). Nos sirve para crear cualquier objeto fantasma o burla (mock) y hacer que devuelva un resultado concreto para una entrada concreta.

Por ejemplo, si queremos probar un servicio que necesita un DAO para obtener un dato, podemos crear un DAO fantasma (mock) que realice esa función y así librarnos de dependencias y probar el servicio unitariamente.

Con esto se consigue realizar pruebas de métodos basándonos en la comprobación de la corrección de su código interno (pruebas de la caja blanca).

Los pasos a realizar en cada prueba:

- Se necesita JDK 5 o superior.

- Preparación del entorno: importación de las librerías TestNG y EasyMock en eclipse: www.easymock.org y www.testng.org .

- Creación del objeto mock.

- Reset del objeto mock.

- Except de lo que recibe y devuelve dicho objeto. Su llamada es opcional, no así la llamada a la función (queda más claro en los ejemplos).

- Replay que prepara dicho objeto para las pruebas.

- Llamada a la función que se va a probar (directa o indirectamente pero el código debe ejecutar la sentencia de método del objeto mock que hemos definido).

- Verify del objeto mock creado.