Los Patrones de Diseño Java EE (II)

Vamos a continuar con el anterior post en el que hablábamos sobre los patrones de diseño de Java EE, recordando que quedaban por detallar la Capa de Negocios y de Integración.

Capa de Negocio

Esta es la capa que presenta un mayor número de patrones, algo bastante razonable porque es aquella que se encarga de la gestión de toda la lógica de negocio de la aplicación Java EE.

• Business Delegate: Un objeto de la capa de presentación llama a métodos remotos de los objetos de la capa de negocio, se produce una búsqueda del elemento requerido, generando posteriormente una llamada al servicio en cuestión.
• Transfer Object: Encapsula la serialización de un objeto que debe ser traspasado por la red. El flujo de ejecución que sigue comienza con la realización de la petición para, a continuación, crear el objeto Transfer Object que encapsulará el traspaso del objeto requerido por el cliente.
• Session Facade: Crea una fachada para encapsular las complejas interrelaciones de los distintos elementos de negocio, proporcionando un servicio uniforme y manejando el flujo de ejecución de los subelementos.
• Aggregate Entity: Encapsula la creación de un Bean de entidad compuesto por otros Beans de entidad.
• Transfer Object Assember: Es una combinación del Transfer Object y el Session Facade. El primero lo emplea para serializar el objeto, mientras que el segundo llevar a cabo la encapsulación de la creación de un objeto compuesto por otros.
• Value List Handler: Maneja la ejecución de sentencias SQL, empleando para ello Beans de Sesión.
• Service Locator: Utilizado para abstraer toda la utilización de JNDI (Interfaz de Nombres y Directorios de Java) y de la creación de cualquier contexto inicial de complejo, además de para la encapsulación de búsqueda o creación de los objetos Home y EJB.

Capa de Integración

• Data Access Object (DAO): Crea un objeto que es un medio para el acceso a la Base de Datos de la aplicación, de forma que se abstraen y encapsulan todas las operaciones relacionadas con el tratamiento del acceso a datos.
• Service Activator: Se utiliza para recibir peticiones y mensajes asíncronos por parte del cliente, buscando el elemento de negocio que contiene el método que se ha de invocar.
  

Por último vamos a enumerar una serie de ventajas e inconvenientes que presentan este tipo de patrones de diseño.

Ventajas

• Estandarización de la solución y consecuente posibilidad de reutilización.
• Mejor aprovechamiento de las características la POO.
• Interoperabilidad de los patrones.
• Aumento del rendimiento a medio plazo.
• Diseño de la aplicación de forma robusta.
• Adaptada a posibles modificaciones y nuevas adiciones.

Inconvenientes

• Necesidad de análisis y estudio previo de los distintos patrones.
• Incremento del tiempo de desarrollo.
• Posible ligero aumento del coste del proyecto.

Arquitecturas Orientadas a Servicios: SOA

La Arquitectura Orientada a Servicios (SOA – Service Oriented Architecture) es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos de software de usuario. Se trata de una arquitectura de software ágil que permite la creación y/o el cambio de los procesos de negocio desde la perspectiva de las TI de forma ágil, a través de la composición de nuevos procesos utilizando las funcionalidades de negocio que están contenidas en la infraestructura de aplicaciones actuales o futuras.

En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado.
A diferencia de arquitecturas orientadas a objetos, las SOAs están formadas por servicios de aplicación débilmente acoplados y altamente interoperables. Para la comunicación entre nodos, los servicios se basan en una definición formal independiente de la plataforma subyacente y del lenguaje de programación; permitiendo el uso en cada nodo de lenguajes de programación heterogéneos y obligando a únicamente coincidir en el contrato entre nodos con necesidades de comunicación.

SOA define las siguientes capas de software:

• Aplicaciones básicas, que son sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad.
• De exposición de funcionalidades, donde las funcionalidades de la capa aplicativas son expuestas en forma de servicios (Servicios Web).
• De integración de servicios, facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración.
• De composición de procesos, que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio.
• De entrega, donde los servicios son desplegados a los usuarios finales.

Los beneficios que puede obtener una compañía que adopte el modelo de arquitectura SOA son:

• Optimización de los tiempos de modificación en los procesos.
• Accesibilidad para migrar a distintos modelos de negocio, tales como los basados en tercerización o colaborativos.
• Capacidad de integración de distintas tecnologías en una sola lógica de negocio.
• Posibilidad de modificación de elementos de la capa de aplicación de la arquitectura sin afectar a otros procesos de negocio.

SaaS

Vamos a hablaros de un paradigma muy de moda en la actualidad de las TICs, SaaS (Software as a Service).

Software as a Service (Software como Servicio) propugna a un modelo de distribución de software en la que se sumistra, a parte del propio sistema, otra serie de servicios como soporte técnico, help desk o mantenimiento. La ventaja que ofrece es que el software requerido se distribuye y aloja en Internet, por lo que el usuario no necesita en ningún momento instalarlo en su computadora personal; y todo lo referente al mismo, datos, sesión, son guardados en un servidor externo proporcionado por la compañía que oferta sus servicios. La gran ventaja que ofrece esto es que se puede alcanzar cualquier segmento de mercado con esta distribución, ya sea una corporación grande, un usuario estándar o una pequeña empresa.

Este tipo de arquitecturas se denominan multi-tenant o multipropietario, en las que sobre un único recurso operan múltiles usuarios que son dueños, por así decirlo, del mismo.

Este modelo presenta numerosas virtudes, como que el acceso, distribución y gestión del propio software a través de la red, lo cual le dota de una disponibilidad muchísimo mayor.

Otro aspecto interesante es que el uso de la aplicación se lleva a cabo en servidores centralizados, en vez de estar alojados en sitios del propio cliente, con lo cual el acceso al mismo se realiza a través de la Web.

También resulta interesante comentar que los datos son guardados en un servidor externo, con lo cual el cliente no requiere de grandes capacidades de almacenamiento en caso de trabajar con grandes volúmenes de información (metadatos, etc.). Así mismo, esto garantiza también que se tendrá siempre copias de seguridad de los mismos, derivando esa responsabilidad en la compañía suministradora, sin tener el cliente que preocuparse de ello.

El modelo de distribución se basa en que la propia compañía suministradora ofrece los servicios de mantenimiento y soporte. Ello conlleva que se tiene en un mismo sitio toda la información, procesamiento y lógica del negocio, algo que a las compañías TIC’s beneficia mucho, pues desaparece ese concepto (en muchos casos realidad) de la dispersión y falta de integración y comunicación entre los distintos procesos del negocio.

SaaS lleva implícito que decrezca la inversión inicial, lo que conlleva un menor riesgo, al poder utilizar el software sin tener que realizar una inversión inicial en máquinas y software para el funcionamiento óptimo de la aplicación. Esto supone un beneficio importante para los directores de la empresa contratante.

Así mismo, este modelo tiene la fortaleza de que todas las actualizaciones y nuevas funcionalidades se pueden tener de manera inmediata, sin necesidad de esperar a que las nuevas versiones estén disponibles, o se tengan que instalar, amén de que no se requerirá personal alguno dedicado a esta tarea. Se dispondrá de todas las actualizaciones y mejoras de manera inmediata.

La empresa centra su esfuerzos en su negocio, realmente se externalizan los sistemas hasta el punto de no dedicar esfuerzos en la elección y mantenimiento de los sistemas. No obstante, siempre requerirá atención del departamento TI pero en mucha menor medida.

Por último, señalar que la aplicación sigue el prototipo “uno-a-muchos”, que viene a determinar que el propio producto es realizado por una empresa y distribuido y utilizado por muchos clientes.

Los Patrones de Diseño Java EE (I)

En un post anterior ya hablamos de los distintos patrones de diseño existentes, que respondían a soluciones para una serie de problemas que se repetían con cierta frecuencia en los sistemas de información. Sin embargo la creciente demanda de desarrollo de aplicaciones empresariales en entorno web ha hecho que sea necesaria una definición de un nuevo conjunto de soluciones enfocadas a este ámbito: los patrones de diseño JEE (Java Enterprise Edition).

Se dividen en cinco capas: Cliente, Presentación, Negocios, Integración y Recursos, de las cuales nos centraremos en las tres centrales, pues son las que presentan un mayor interés de cara al desarrollo de sistemas con orientación empresarial.

En el siguiente esquema se muestran los distintos patrones y las relaciones que se establecen entre ellos. Seguidamente pasaremos a comentar el primer grupo, el correspondiente a la Capa de Presentación.


Capa de Presentación

• Decorating Filter/Intercepting Filter: Maneja varios tipos de peticiones que requieren un procesamiento determinado; especialmente aplicado a procesos de validación de sesión.
• Front Controller: Acepta todas las peticiones de un cliente y las direcciona a los manejadores apropiados.
• View Helper: Encapsula la lógica de acceso a bases de datos en beneficio de la capa de presentación.
• Composite View: Elemento de la Vista compuesto por otros elementos del mismo tipo.
• Service to Worker: Similar al MVC, emplea dos subpatrones, el Front Controller para el Controlador y el View Helper para la Vista.
• Dispatcher View: Similar al MVC y al anterior, pero el Controller no realiza acciones sobre el Helper.

En un post posterior continuaremos la descripción de las dos capas que restan, la de Negocio y la de Intregración.

Patrones Arquitectónicos: el MVC

Las arquitecturas lógicas para el diseño de aplicaciones web se dividen entre dos patrones o modelos: el Cliente-Servidor y el MVC (Modelo-Vista-Controlador). La primera, más tradicional y clásica en sistemas con un tiempo de vida largo, y la segunda, más de moda en la actualidad por el paradigma que propone. Para este post nos vamos a centrar en esta última, dado que su uso está extendidísimo y es la más indicada para aplicaciones web.

El patrón MVC o Modelo-Vista-Controlador basa su robustez en que la lógica de la interfaz de usuario varía mucho más rápido que la lógica de negocio y almacenamiento, con lo que pretende separar las capas, de tal forma que un cambio en una de ellas no tenga un impacto elevado en otra. Está dividida en tres capas o niveles:

Modelo: gestiona los datos y la lógica del negocio.

• Accede a la capa de almacenamiento de datos. Independencia del modelo con el sistema de almacenamiento.
• Define las reglas de negocio, la funcionalidad del sistema.
• Registro de las vistas y controladores de la aplicación.

Vista: presentan la información del sistema al usuario y generar los eventos de la interacción con éste.

• Captura eventos del usuario y se los envía al sistema a través del controlador.
• Recibe mandatos del controlador y muestra información al usuario.

Controlador: recibe eventos del usuario, invoca servicios ofrecidos por el modelo y selecciona la vista adecuada para presentar los resultados.

En la siguiente figura se aprecia la interacción entre los distintos componentes. Hay versiones o apreciaciones del MVC en las que se permite la conexión entre la Vista y el Modelo, sobre todo para operaciones muy simples que apenas tengan complejidad o impacto en la lógica del sistema. Nosotros creemos que, si es precisamente un patrón que trata de separar estas capas de negocio, es mejor que no existan tal relación, teniendo que pasar todas las peticiones a través del Controlador. Y este argumento se refuerza en las aplicaciones Web, donde la Vista suele estar distribuida y existe un altísimo grado de concurrencia en el acceso a los datos del sistema.

Por lo anterior, el flujo de control que sigue este patrón es:

1. El usuario interacciona con la interfaz (Vista) y genera un evento.
2. El controlador captura dicho evento y lo gestiona.
3. El controlador accede al Modelo y lo actualiza.
4. El controlador invoca la Vista necesaria para presentar los nuevos datos al usuario.

En función de la tecnología en la que estéis desarrollando el diseño existen numerosos frameworks para implementar el MVC, por ejemplo Struts para Java, CakePHP para PHP y Spring.NET para .NET.

Un estándar para la Gestión de Proyectos: el PMBOK

En este post vamos a hablar de uno de los más (si no el más) importantes estándares de Gestión de Proyectos. El PMBOK (Project Management Body Of Knowledge) aglutina una colección de procesos y áreas de conocimiento generalmente aceptadas como las mejores prácticas dentro del campo de la Gestión de Proyectos. Fue desarrollado por PMI (Project Management Institute) y proporciona una serie de fundamentos para este área funcional, aplicables a proyectos de múltiple índole: software, ingeniería, construcción...

Postula que un proyecto exitoso va a ser consecuencia de la colaboración y conflictos entre el equipo de gestión o dirección y el de trabajo, y para muestra, una de las frases introductorias del libro: "Buenas prácticas no quiere decir que los conocimientos descritos deban aplicarse siempre de manera uniforme en todos los proyectos: el equipo de dirección del proyecto es el responsable de determinar lo que es apropiado para cada proyecto determinado".

Concibe que es en los propios miembros del equipo de trabajo (Gestor de Proyectos y responsables) en los que reside el conjunto de conocimientos (Body of Knowledge) que se han de aplicar para dirigir un proyecto, representando un conjunto vivo, amplio y que es fruto de la unión entre experiencia, estudio y desarrollo. Por ello, la finalidad del PMBOK no es la de proporcionar nueve pasos básicos para el éxito en la gestión de un proyecto, ni pretende mostrar disciplinas, experiencias y técnicas que pueden ayudar a conseguirlo, sino que identifica un subconjunto de éstas que dan lugar a buenas prácticas de ingeniería.

El PMBOK propone cinco procesos básicos y nueve áreas de conocimiento comunes a la mayor parte de los proyectos. Los procesos interactúan a través de un proyecto o fase, y son descritos en base a: Inputs (documentos, diseños,...), Outputs (documentos, productos de ingeniería,...) y aquellas herramientas y técnicas que, aplicadas a las entradas, dan lugar a las salidas.

Los procesos son: Inicio, Planificación, Ejecución, Supervisión y control, y Cierre. No representan fases rígidas ni excesivamente estructuradas, pero básicamente responden al modelo "planear, hacer, revisar y actuar".


Las nueve áreas de conocimiento identificadas en el PMBOK son:

1. Gestión de la Integración de Proyectos.
2. Gestión del Alcance en Proyectos.
3. Gestión del Tiempo en Proyectos.
4. Gestión de la Calidad en Proyectos.
5. Gestión de Costos en Proyectos.
6. Gestión del Riesgo en Proyectos.
7. Gestión de Recursos Humanos en Proyectos.
8. Gestión de la Comunicación en Proyectos.
   
9. Gestión de la Procura (Logística) en Proyectos.

Esperamos que este post os haya servido para tener una visión global más amplia de un campo tan complejo como la Gestión de Proyectos y que comprobéis que ésta no es una tarea trivial, sino que requiere no sólo de mucho conocimiento, sino también de experiencia.

Por último, deciros que aquí tenéis disponible la última versión del estándar en castellano, publicada en 2004.

Los Ciclos de Vida del Software (II)

Vamos a continuar la labor comenzada en el post anterior acerca de los distintos modelos de ciclos de vida de software.

Ciclo de vida PROTOTIPADO

Este modelo se basa en la realización continua de diversos prototipos, cada vez más refinados, a partir del conjunto inicial de necesidades del cliente, de tal manera que los entragables van aumentando en su complejidad, con el fin de incrementar la comprensión que tiene del sistema tanto el usuario como el desarrollador.


Su principal ventaja es ese control continuo que se tiene sobre el producto que se está desarrollando, porque está supervisado y guiado por el propio cliente, que va modificándolo a su parecer, con lo que se evita la entrega de sistemas que, al final, no satisfacen las necesidades reales del usuario.

En su contra, estas características pueden hacerle débil, porque el cliente puede exigir plazos más cortos al ver sistemas en "pseudofuncionamiento", creyendo que son los finales. Algo similar puede ocurrir en el equipo de desarrollo, que puede caer en el relajamiento y descuido del compromiso de calidad adquirido.

Ciclo de vida EN ESPIRAL

En este modelo las actividades se conforman en una espiral, representando cada bucle un conjunto determinado de actividades. Éstas no están fijadas a priori, sino que se van eligiendo en base a los distintos análisis de riesgos que se van elaborando en las sucesivas iteraciones, comenzando siempre por el último bucle efectuado.

Cada bucle empieza identificando los objetivos, las alternativas y las restricciones del ciclo. Una vez evaluadas las alternativas respecto a los objetivos y teniendo en cuenta las restricciones, se lleva a cabo el ciclo correspondiente para, una vez finalizado, empezar a plantear el próximo.

El segundo paso es evaluar las diferentes alternativas que se plantean teniendo en cuenta los objetivos a conseguir y las restricciones impuestas. Frecuentemente,este paso identifica las áreas de incertidumbre del proyecto con sus correspondientes riesgos. Si existen riesgos, el siguiente paso conlleva la formulación de una estrategia efectiva en coste (utilizando prototipos, simulación, bancos de prueba, cuestionarios para los usuarios...) para resolverlos.

El tercer paso consiste en revisar los resultados del análisis de riesgos, y el cuarto paso en planificar la fase posterior. Una vez realizado el primer ciclo se volvería a empezar, modificando los requisitos y reformulando los objetivos, estrategias, alternativas, etc.

Como veis hay mútiples alternativas... en nuestro proyecto casi todos optamos, en un principio, por un modelo en cascada, algo que viene determinado por los distintos hitos y entregables que hay que cumplir, pero creemos que va mutando en un modelo híbrido, puesto que se van realizando distintas etapas de manera disjunta con el fin de obtener una mayor productividad y, casi siempre, debido a los rechazos por parte del cliente.