oo: Patrones

Que es un Patron?

Es conocida la existencia de los llamados "Patrones" por la gran mayoria de los involucrados en el desarrollo de software. Quien paso por alguna facultad, tuvo la necesidad de consultar el famoso libro "Design Patterns: Elements of Reusable Object-Oriented Software" de "The Gang of Four" (GoF) o escucho sobre POSA.

La definicion mas conocida de Patron dice que es aquella solucion establecida para un problema recurrente en un cierto contexto.

En el primer volumen de POSA, el conocido libro "Pattern-Oriented Software Architecture: A System of Patterns", incluye una definicion mas completa, que surge a partir de la definicion del termino "Patron" dada por Christopher Alexander:

"Cada patron es una regla de tres partes, la cual expresa una relacion entre un cierto contexto, un problema y una solucion.
Como elemento del mundo, cada patron es una relacion entre un cierto contexto, un cierto sistema de fuerzas que ocurren repetidamente en ese contexto, y una cierta configuracion espacial que permite que esas fuerzas se resuelvan entre si.
Como elemento del lenguage, un patron es una instruccion, la cual muestra como esta configuracion espacial puede ser usada, una y otra vez, para resolver un sistema de fuerzas, donde sea que el contexto lo permite.
Un patron es, en resumen, al mismo tiempo una cosa, la cual ocurre en el mundo, y una regla nos dice como recrear esa cosa, y cuando debemos crearla. Es a la vez, un proceso y una cosa: ambas una descripcion de algo vivo, y una descripcion del proceso que lo genera."

Ahora la definicion de Patron segun POSA:

"Un patron de software describe un problema de diseno recurrente que ocurre en contexto de diseno especificos, y presenta un esquema generico bien establecido para solucionarlo. El esquema de solucion se especifica mediante la descripcion de sus componentes constitutivos, sus responsabilidades y relaciones, y las formas en las cuales colaboran."

Se parece mucho a lo que ya conocemos, verdad?

Como se define un Patron?

Un Patron queda definido por un esquema compuesto por tres partes:

• Contexto: es aquella situacion que lleva a un problema
  Debe describir todas aquellas situaciones en las cuales ocurre el problema. Esto resulta imposible, por lo que se espera que se una descripcion tan generica como sea posible o la enumeracion de las situaciones en las cuales el problema ocurre.
  
  
• Problema: es aquel problema recurrente que ocurre en el contexto dado
  
• Solucion: es la forma establecida que resuelve el problema
  

Categorias

Existen diversos tipos de patrones. Es posible agruparlos mediante las siguientes categorias:

• Patrones de arquitectura
• Estructura
• Sistemas Distribuidos
• Sistemas Interactivos
• Sistemas Adaptables
  
• Patrones de diseno
• de Creacion
• de Estructura
  
• de Comportamiento

Patrones de Arquitectura

Los patrones de arquitectura mas conocidos son los presentados en POSA 1:

• Estructura
  
• Layers
• Pipes and Filters
• Blackboard
• Sistemas Distribuidos
• Broker
  
• Sistemas Interactivos
  
• Model-View-Controller
• Presentation-Abstraction-Control
  
• Sistemas Adaptables
• Microkernel
• Reflection
  

Patrones de diseno

Los patrones de diseno mas importantes son los presentados por GoF (aunque existen otros muy utiles presentados por Java EE y Martin Fowler):

• Creacion
• Estructura
• Comportamiento

Vinculos:

• Patron de Diseno @ Wikipedia
• Patrones de Diseno @ Wikipedia
• Patron de Arquitectura @ Wikipedia
• Java EE Patterns
• Java EE Patterns Catalog
• Patterns of Enterprise Application Architecture Catalog (from Martin Fowler)
  

spring: Integracion de codigo legacy

Spring framework provee dos atributos para la definicion de un bean, que son particularmente interesantes cuando hace uso de codigo legacy. Estos atributos son:

• factory-method
• factory-bean

El atributo factory-method permite especificar un metodo static de la clase que es utilizado por Spring para crear una instancia de la misma.
En el siguiente ejemplo se puede observar con claridad:

El atributo class especifica la clase del bean, y es dicha clase la cual contiene el metodo static que retorna una instancia de la misma.

public class ExampleBean
{
   private static ExampleBean bean;

   static
   {
       bean = new ExampleBean();
   }

   private ExampleBean() {}

   public static ExampleBean create()
   {
       return bean;
   }
}

Vinculos:

• Spring Framework Reference

wtp: Aplicacion sencilla con WTP 3.0

En eclipse live se puede ver el video que muestra la creacion de una aplicacion sencilla empleando las nuevas prestaciones de WTP 3.0:

Video

Vinculos:

• Aplicacion simple basada en EJB con Webtools

cache: Introduccion

El termino Cache

Fue acunado por Lyle R. Johnson, editor que buscaba un termino mas descriptivo al utilizado por sus creadores, "high-speed buffer". Cache es una palabra francesa que significa ocultar.

Funcionamiento

El cache es almacenamiento temporario para aquellos datos que son utilizados con frecuencia. El cache esta compuesto por:

• Un conjunto de datos, que son copia de los datos en algun medio de almacenamiento
• Una forma de identificar la frecuencia de uso de esos datos
• Una politica de reemplazo de los datos en el cache
• Una politica de escritura de los datos en el cache al medio de almacenamiento
  

Vinculos:

• Cache @ Wikipedia

scm: Diff entre versiones de un archivo

Configuracion del entorno de usuario

Edite el archivo .bashrc en su directorio home:

vi $HOME/.bashrc

y agregue la siguiente linea:

alias ct=/usr/atria/bin/cleartool

Ejecucion de Diff grafico sobre un archivo

Es necesario montar a la vista de clearcase en la cual se encuentra el archivo a analizar:

ct setview [view-tag]

por ejemplo:

ct setview vista_desarrollo

Verifique la que vista haya sido montada:

ct pwv

y vera como respuesta en la consola:

Working directory view: ** NONE **
Set view: vista_desarrollo

Acceda al directorio, en la vista, donde se encuentra el archivo a analizar:

cd /vobs/proyecto/src/main/java/paquete/

Luego ejecute la herramienta grafica que muestra el arbol de versiones:

ct lsvtree -g [nombre-archivo]

por ejemplo:

ct lsvtree -g Clase.java

Si obtiene el siguiente error:

Error: Can't open display:

implica que no ha configurado correctamente su servidor X en su sistema Windows.
Finalmente debera observar la siguiente ventana:

El circulo azul indica la ultima version del archivo del cual se desea obtener la diferencia con otra. En la imagen se borraron algunos nombres para evitar confusiones.
Podra seleccionar esa ultima version o alguna anterior, solo debe asegurarse que un circulo rojo pinte el borde del circulo correspondiente a la version para la cual desea obtener las diferencias.

Luego acceda al menu principal y efectue la seleccion que se muestra a continuacion:


Al seleccionar la opcion "Selected vs. other...", aparecera una nueva ventana donde podra seleccionar la "otra" version a comparar. Luego de hacer esto, podra observar las diferencias en una ventana con dos marcos, el izquierdo mostrando la "otra" version y el derecho mostrando la version seleccionada.

Vinculos:

• http://www.yolinux.com/TUTORIALS/ClearcaseCommands.html
• Clearcase Cheatsheet
  

oo: Programacion Orientada a Objetos

Que es la Programacion Orientada a Objectos?

Es el metodo de implementacion por el cual un programa es organizado a partir de un conjunto de objetos que cooperan entre si, los cuales son instancias de clases, las cuales son miembros de una jerarquia de clases, vinculadas por relaciones jerarquicas.

Es importante destacar:

• La unidad fundamental en la POO es el objeto, no los algoritmos
• Cada objeto es instancia de alguna clase
• Las clases pueden estar relacionadas unas con otras por relaciones jerarquicas

Caracteristicas de la Programacion Orientada a Objetos



Vinculos:

• Object Oriented Programming (OOP) @ Wikipedia

oo: Unified Modelling Language (UML)

Introduccion e historia

UML es un lenguaje de modelado de proposito general que provee notacion grafica. La especificacion de UML es mantenida por el Object Management Group (OMG) y se basa en el UML Metamodel, que es un Meta-Object Facility Metamodel (MOF).

En 1994, dos de los padres de los metodos mas populares de modelado orientado a objetos, Rumbaugh y Booch, fueron contratados por Rational y comenzaron a trabajar en una metodologia que unificara las existentes:

• OMT, mas propicio para el analisis orientado a objetos (OOA), de Rumbaugh
• Metodo Booch, mas propicio para el diseno orientado a objetos (OOD), de Booch

En 1995, cuando Rational adquirio la compania Objectory AB, donde Jacobson, creador de ObjectOry, trabajaba, este ultimo se unio a Rambaugh y Booch en la definicion de una metodologia unificada. A este grupo se lo conocio como The Three Amigos (Los tres Amigos).

Debido a la abundancia de lenguajes de modelado orientado a objetos, algunos de ellos propietarios, la tecnologia orientada a objetos no estaba siendo adoptada con rapidez. Rational encargo a The Three Amigos crear un lenguaje de modelado unificado no propietario.
En 1996, el consorcio UML Partners, bajo la direccion tecnica de The Three Amigos, fue creado para completar la especificacion del Unified Modelling Language (UML - Lenguaje de modelado unificado).
El borrador de la especificacion UML 1.0 fue presentado al OMG en Enero de 1997. Finalmente, luego de integrar a la especificacion otros esfuerzos de estandarizacion, la especificacion UML 1.1 fue presentada al OMG en Agosto de 1997 y adoptada meses despues, en Noviembre.

UML se encuentra fuertemente influenciado por OMT. La notacion de casos fue introducida por Objectory (Jacobson) , mientras que la de componentes lo fue por Booch.
Recursos introducidos por otros metodos, como Tarjetas CRC (CRC Cards) y el metodo de Analisis de Roles (OORam) tambien son tenidos en cuenta por UML, de manera de abarcar el mas amplio espectro.

Modelado

Mediante los diversos tipos de diagramas que ofrece UML, es posible representar el modelo de un sistema mediante tres vistas:

• Vista de Requerimientos Funcionales
  Diagrama de Casos de Uso son utilizados principalmente
  
  
• Vista de Estructura Estatica
  Diagramas de Clase y de Componentes son utilizados principalmente
  
  
• Vista de Comportamiento Dinamico
  Diagramas de Secuencia, de Colaboracion, de Actividad y de Transicion de Estados son utilizados principalmente
  

Diagramas

En la especificacion UML 2.0, existen 13 tipos de diagramas categorizados en forma jerarquica. Este conjunto de diagramas puede ser agrupado en dos grandes grupos:

Diagramas de estructura: Muestran que compone al sistema

• de Clases
• de Objetos
• de Componentes
• de Paquetes
• de Despliegue

Diagramas de comportamiento: Muestran como se comporta el sistema

• de Casos de Uso
• de Actividad
• de Secuencia
• de Colaboracion
• de Transicion de Estados

Vinculos:

• Unified Modelling Language @ Wikipedia
• CRC Cards @ Wikipedia
• Object Oriented Role Analysis Method (OORam) @ Wikipedia
  

mock: Comportamiento para metodos void

Para configurar el comportamiento en metodos que retornan algun valor, se emplea el metodo estatico expect correspondiente a la clase org.easymock.EasyMock. Por ejemplo:

InetAddress addr = createMock(InetAddress.class);
expect(addr.getHostAddress()).andReturn("localhost");

Para configurar el comportamiento en metodos void, o sea, metodos que no devuelven valor alguno, es necesario emplear el metodo estatico lastExpectCall justo despues de configurar la invocacion al metodo del objeto mock. Por ejemplo:

byte[] bytes = new byte[8192];
OutputStream os = createMock(OutputStream.class);
os.write(bytes, 0, bytes.length);
expectLastCall().andThrow(new IOException());

Asi como en el ejemplo anterior una excepcion fue configurada, se pueden emplear cualquiera de los metodos asociados al expect.

Vinculos:

• Documentacion de EasyMock

oo: El Metodo Booch

Es una metodologia ampliamente utilizada en el analisis y diseno de software y fue creada por Booch durante su desempeno en Rational Software Corporation.

El metodo define diferentes modelos para describir un sistema, soportando el desarrollo iterativo e incremental. El metodo tambien incluyo seis(6) tipos de diagramas:

• De clases
• De objetos
• De transicion de estados
• De modulos
• De procesos
• De interaccion

Diversos aspectos del Metodo Booch fueron incorporados mas tarde por RUP.

Vinculos:

• Metodo Booch @ Wikipedia

oo: ObjectOry y OOSE

ObjectOry es una metodologia basada en el paradigma de orientacion a objetos, creada por la compania Objectory Systems, fundada en 1987 por Jacobson. Es una extension de lo que se conoce como Metodo Ericsson, un lenguaje de modelado de objetos creado por la compania Ericsson.

Durante 1991, Ericsson adquiere gran parte de Objectory Systems, creando la subsidiaria Objectory AB. En 1995, Rational Software Corporation adquiere dicha subsidiaria.

Object-Oriented Software Engineering (OOSE) es la metodologia para el analisis y diseno de software desarrollada por Jacobson en 1992 durante su participacion en la compania Objectory AB. Es la primera metodologia que emplea Casos de Uso en el analisis de software.

Cuando en 1995 Rational Software Corporation adquiere Objectory AB, OOSE es empleado como parte de la base que funda lo que se conoce como Rational Unified Process (RUP).

Vinculos:

• Objectory @ Wikipedia
• Objectory AB @ Wikipedia
• Object-Oriented Software Engineering @ Wikipedia
  

oo: Object Modelling Technique (OMT)

OMT es un lenguaje de modelado de objetos orientado al analisis y diseno de software. Fue creado durante 1991 por Rumbaugh, entre otros, como una herramienta para el desarrollo de sistema basados en el paradigma de orientacion a objetos.

OMT es el predecesor de Unified Modelling Language (UML) y muchos elementos introducidos por OMT fueron heredados por UML.

Vinculos:

• OMT @ Wikipedia
• Object Oriented Modelling and Design by James Rumbaugh @ Amazom.com
  

ws: Mecanismo de invocacion de un Web Service

Invocacion en el servidor

1. El mensaje SOAP es recibido desde el transporte (HTTP, JMS).
2. Los manejadores de mensajes que se encargan del preprocesamiento de los mismos son invocados (persistir mensajes, analizar el encabezado, etc.).
3. Determinar el servicio del mensaje (que operacion del WSDL invoca el mensaje).
4. Para la operacion del WSDL, determinar el metodo a invocar en la clase Java apropiada. A esta clase se la llama Java target y a este proceso se lo conoce como dispatching.
5. Entregar el mensaje SOAP al sub-sistema encargado de la serializacion para que lo deserialice en objetos Java que seran pasados como parametros al Java target.
6. Invocar el Java target usando los parametros generados por el sub-sistema de serializacion y obtener el objecto Java retornado.
7. Entregar el objeto Java retornado al sub-sistema de serializacion para ser serializado en XML segun lo especificado por el WSDL para el mensaje de retorno.
8. Encapsular en un mensaje SOAP el XML generado a partir del objeto Java retornado, segun lo especificado por el WSDL para el mensaje de retorno.
9. Entregar el mensaje SOAP al transporte para ser enviado al cliente.

Nota: Si ocurre una excepcion durante este proceso, la misma debe ser encapsulada en un mensaje SOAP del tipo fault y enviada al cliente.

Invocacion en el Cliente

1. Se crea una instancia de la clase que implementa la interfaz Java para el endpoint del Web Service (SEI). El sub-sistema de invocacion emplea algun factory para crear instancias de SEI (Service Endpoint Interface). Las instancias se crean en el momento de ejecucion o se obtienen mediante JNDI. Las instancias SEI son implementadas usando proxies Java y manejadores de invocacion (invocation handler).
2.