Patrones de diseño: Chain of Responsability e Interpreter

El patrón de diseño Chain of Responsibility es un patrón de comportamiento que evita acoplar el emisor de una petición a su receptor dando a más de un objeto la posibilidad de responder a una petición. Para ello, se encadenan los receptores y pasa la petición a través de la cadena hasta que es procesada por algún objeto. Este patrón es utilizado a menudo en el contexto de las interfaces gráficas de usuario donde un objeto puede contener varios objetos. Según si el ambiente de ventanas genera eventos, los objetos los manejan o los pasan.

Se utiliza cuando:
-Las peticiones emitidas por un objeto deben ser atendidas por distintos objetos receptores
-No se sabe a priori cual es el objeto que me puede resolver el problema
-Cuando un pedido debe ser manejado por varios objetos
-El conjunto de objetos que pueden tratar una petición debería ser especificado dinámicamente

La motivación detrás de este patrón es crear un sistema que pueda servir a diversas solicitudes de manera jerárquica. En otras palabras, si un objeto que es parte de un sistema no sabe cómo responder a una solicitud, la pasa a lo largo del árbol de objetos. Como el nombre lo implica, cada objeto de dicho árbol puede tomar la responsabilidad y atender la solicitud.
Un ejemplo típico podría ser el lanzar un trabajo de impresión. El cliente no sabe siquiera qué impresoras están instaladas en el sistema, simplemente lanza el trabajo a la cadena de objetos que representan a las impresoras. Cada uno de ellos lo deja pasar, hasta que alguno, finalmente lo ejecuta.

Hay un desacoplamiento evidente entre el objeto que lanza el trabajo (el cliente) y el que lo realiza (impresora). 

Ejemplo

Escenario: estamos realizando el software para un banco y uno de los puntos más importantes es saber quién puede aprobar un crédito. Por lo tanto el banco define las siguientes reglas de negocio:

Si el monto no supera los $ 10.000 entonces el ejecutivo de cuenta pueda aprobar el préstamo.
Si el monto esta entre los $10.000 y $50.000 entonces la persona indicada para realizar la aprobación es el líder inmediato de dicho ejecutivo.
Si el monto se encuentra entre $ 50.000 y $100.000 entonces es el Gerente quién debe realizar dicha aprobación.
Por montos superiores a los $100.000 entonces la aprobación la realizará el Director.

Para este caso se ha decidido realizar un patrón Chain of Responsibility. Se decide crear una interface llamada IAprobador que debe implementar toda clase que pertenezca a nuestra cadena de responsabilidades.








En nuestro caso será el banco quién organice la cadena, pero seguramente en la práctica utilizaremos un factory. Para el cliente el banco será su punto de entrada.


Y, desde el punto de vista del cliente, verán que es muy sencillo:

Interpreter

Este patrón busca representar un lenguaje mediante reglas gramáticas. Para ello define estas reglas gramáticas y como interpretarlas. Utiliza una clase para representar una regla gramática.
Si un tipo particular de problema se presenta frecuentemente, puede ser provechoso expresar los diferentes casos del problema como sentencias de un lenguaje simple. Se puede, entonces, construir un intérprete que resuelva el problema interpretando dichas sentencias.

Cuando Utilizarlo.

Este patrón se debe utilizar cuando hay un lenguaje que interpretar y se puede interpretar sus palabras como árboles sintácticos abstractos. Para ello, la gramática debe ser simple.
Difícilmente el desarrollador utilice este patrón en algún momento de su vida, lo que no quita que no sea un patrón utilizado. La situación ideal que se debe considerar para aplicar este patrón es que exista un lenguaje sencillo que pueda interpretarse con palabras. El ejemplo más claro es JAVA: este lenguaje permite escribir en archivos .java entendibles por humanos y luego este archivo es compilado e interpretado para que pueda ejecutar sentencias entendibles por una máquina.

Ejemplo

Luego de leer el ejemplo, se entenderá porque este patrón sólo funciona con lenguajes con reglas sencillas... de hecho este ejemplo no lo pensé yo, lo vi en una página hace muchos años y no recuerdo cual era para colocar la fuente...
Veamos un ejemplo donde se utiliza el interpreter para interpretar los números romanos mediante ciertas reglas matemáticas y convertirlo en un número de escala decimal.

Primero creamos el contexto: esto es una clase donde tiene un input (un String ya que los numeros romanos son letras) y un output (un int ya que la respuesta será un número).

Lo que sigue a continuación es puro algoritmo: si pensamos como funcionan los numeros romanos vamos a encontrar un patrón (pongo como ejemplo con escala de 10 pero es lo mismo para el resto de las escalas): de 1 a 3 es el mismo signo I (ocupa 1 espacio por vez), el 4 es una combinacion del 5 con el 1.... IV (ocupan dos lugares), el 5 es V (ocupa 1 lugar) y el próximo signo que hace combinación es el 9 (IX) que utiliza un signo de una escala mayor.

 Una vez que entendemos el algoritmo y logramos la interpretación correcta, agregar una nueva expresión es muy sencillo. Aca corte en 1000 porque ya se entiende la idea.

Veremos esto en practica:

Patrones de Diseño: Iterator y Mediator

Introducción:

Los patrones de diseño son la base para solucionar problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interfaces.

Los patrones de diseño describen una estructura que resuelve un problema particular dentro de un contexto específico. El patrón de diseño debe ser reutilizable y debe servir como guía para desarrollar un patrón distinto en estructura.

En este informe se describen los patrones de diseño Iterator y Mediator, cada uno con sus funciones básicas y un ejemplo de su ocupación.

Iterator

Iterator provee un mecanismo de acceso secuencial a elementos de una colección, definiendo una interface que declara métodos para acceder secuencialmente a los objetos de la colección. Una clase accede a la colección mediante dicha interface.

Su principal característica es que se busca acceder a los contenidos de los objetos sin necesidad de saber cuál es su estructura. Su idea es crear la forma de soportar el recorrido de objetos de diferentes formas mediante una interfaz uniforme.

Se utiliza cuando:

- Una clase necesita acceder al contenido de una colección sin llegar a ser dependiente de la clase que es utilizada para implementar la colección, es decir sin tener que exponer su representación interna.

- Una clase necesita un modo uniforme de acceder al contenido de varias colecciones.

- Cuando se necesita soportar múltiples recorridos de una colección.

- El patrón debe ser utilizado cuando se requiera una forma estándar de recorrido de una colección, es decir, cuando no es necesario que el cliente sepa si está recorriendo un List, un Set, un Array, un Queue, etc.

1. -          El agregado (Aggregate) define una interfaz para crear un objeto Iterator.
2. -          Iterator define una interfaz para acceder y recorrer los elementos del Aggregate.
3. -         IteratorConcreto implementa la interfaz de Iterator y guarda la posición actual del recorrido en cada momento.
4. -          AggregateConcreto implementa la interfaz de creación de iteradores devolviendo una instancia del IteratorConcreto apropiado.

Ejemplo:

Sucursal de Empleados: Se implementa un Array sin que el cliente tenga acceso a saber de ello.

Se crea el iterator para recorrer los elementos de la  sucursal (los empleados). El método Iterator devuelve un objeto DivisionIterator.

El código para recorrer la colección con el iterator es:

Consecuencias

Es posible acceder a una colección de objetos sin conocer el código de los objetos.

Utilizando varios objetos Iterator, es simple tener y manejar varios recorridos al mismo tiempo.

Es posible para una clase Colecction proporcionar diferentes tipos de objetos Iterator que recorran la colección en diferentes modos. Por ejemplo, una clase Colecction que mantiene una asociación entre la clave de los objetos y el valor de los objetos podría tener diferentes métodos para crear Iterators que recorran sólo la clave de los objetos y crear Iterators que recorran sólo el valor de los objetos.

Las clases Iterator simplifican el código de las colecciones, ya que el código de los recorridos se encuentra en los Iterators y no en las colecciones.

Mediator

Un mediator es un patrón de diseño que define un objeto como procesador central. Permite la interacción entre varios objetos, coordinando las relaciones entre los participantes.

Cuando muchos objetos interactúan entre sí, se forma una estructura compleja con demasiadas conexiones. En un caso extremo cada objeto puede conocer a todos los demás objetos. Para prevenir esto, Mediator encapsula el comportamiento de todo un conjunto de objetos en uno solo.

Usar el patrón Mediator cuando:

- Un conjunto grande de objetos se comunica de una forma bien definida, pero compleja.

- Reutilizar un objeto se hace difícil porque se relaciona con muchos objetos.

- Las clases son difíciles de reutilizar porque su función básica esta entrelazada con relaciones de dependencia.

- Se puede asociar el uso de un patrón Mediator a la torre de control de un aeropuerto: la función de sincronizar las acciones de los aviones (aterrizar/despegar).

1. -          Mediator define una interface para comunicarse con los objetos colegas (Colleague).
2. -          MediatorConcreto implementa la interface y define como los colegas interactúan entre ellos.
3. -          Colleague define el comportamiento que debe implementar cada colega para poder comunicarse el Mediator de manera estándar.
4. -          ColleagueConcreto: cada colega conoce a su Mediador,  y lo ocupa para la comunicación entre Colegas.

Ejemplo:

Chat: Los usuarios se comunican en un salón de chat. Se define un interface que todos los usuarios de chat deben implementar para participar. La clase usuario representa a un user que quiera participar del chat.

Su funcionamiento:

Consecuencias

Desacopla a los colegas: el patrón Mediator promueve bajar el acoplamiento entre colegas. Se puede variar y reusar colegas y mediadores independiéntemente.

Simplifica la comunicación entre objetos: los objetos que se comunican de la forma "muchos a muchos" puede ser remplazada por una forma "uno a muchos" que es menos compleja y más elegante. Además esta forma de comunicación es más fácil de entender. Es decir, un objeto no necesita conocer a todos los objetos, tan sólo a un mediador.

Clarifica como los objetos se relacionan en un sistema.

Centraliza el control: el mediador es el que se encarga de comunicar a los colegas, este puede ser muy complejo, difícil de entender y modificar.

Conclusión:

                

Los patrones Iterator y Mediator cumplen funciones específicas muy requeridas en los procesos de desarrollo de software, mientras uno permite el recorrido de cualquier tipo de colección de objetos, indiferente de cual sea la estructura de ellos, el otro permite un control de comunicación entre objetos. Ambos patrones de diseño son una solución reutilizable para problemas frecuentes en la utilización de objetos en desarrollo de programas.

“Una cosa que los diseñadores expertos no hacen es resolver cada problema desde el principio [...]. Cuando encuentran una buena solución la usan una y otra vez. Esta experiencia es lo que los hace expertos” (Gamma, 1995)

Metodologia de Desarrollo de software con KANBAN

Kanban

se define como “un sistema de producción altamente efectivo y eficiente“, ha contribuido a generar un panorama manufacturero óptimo y competitivo. El origen de la metodología Kanban debemos buscarlo en  los procesos de producción “just-in-time” (JIT) ideados por Toyota, en los que se utilizaban tarjetas para identificar necesidades de material en la cadena de producción.

Actualmente, el término Kanban ha pasado a formar parte de las llamadas metodologías ágiles, cuyo objetivo es gestionar de manera general cómo se van completando las tareas. Kanban es una palabra japonesa que significa “tarjetas visuales”, donde Kan es “visual”, y Ban corresponde a “tarjeta”.

Las principales ventajas de esta metodología es que es muy fácil de utilizar, actualizar y asumir por parte del equipo. Además, destaca por ser una técnica de gestión de las tareas muy visual, que permite ver a golpe de vista el estado de los proyectos, así como también pautar el desarrollo del trabajo de manera efectiva.

Los principios de la metodología Kanban

La metodología Kanban se basa en una serie de principios que la diferencian del resto de metodologías conocidas como ágiles:

Calidad garantizada. Todo lo que se hace debe salir bien a la primera, no hay margen de error. De aquí a que en Kanban no se premie la rapidez, sino la calidad final de las tareas realizadas. Esto se basa en el hecho que muchas veces cuesta más arreglarlo después que hacerlo bien a la primera.
Reducción del desperdicio. Kanban se basa en hacer solamente lo justo y necesario, pero hacerlo bien. Esto supone la reducción de todo aquello que es superficial o secundario (principio YAGNI).
Mejora continua. Kanban no es simplemente un método de gestión, sino también un sistema de mejora en el desarrollo de proyectos, según los objetivos a alcanzar.
Flexibilidad. Lo siguiente a realizar se decide del backlog (o tareas pendientes acumuladas), pudiéndose priorizar aquellas tareas entrantes según las necesidades del momento (capacidad de dar respuesta a tareas imprevistas).

Pasos para configurar tu estrategia de Kanban

La aplicación del método Kanban implica la generación de un tablero de tareas que permitirá mejorar el flujo de trabajo y alcanzar un ritmo sostenible. Para implantar esta metodología, deberemos tener claro los siguientes aspectos:

1) Definir el flujo de trabajo de los proyectos: para ello, simplemente deberemos crear nuestro propio tablero, que deberá ser visible y accesible por parte de todos los miembros del equipo. Cada una de las columnas corresponderá a un estado concreto del flujo de tareas, que nos servirá para saber en qué situación se encuentra cada proyecto. El tablero debe tener tantas columnas como estados por los que pasa una tarea, desde que se inicia hasta que finaliza (p.e: diagnóstico, definición, programación, ejecución, testing, etc.).

A diferencia de SCRUM, una de las peculiaridades del tablero es que este es continuo. Esto significa que no se compone de tarjetas que se van desplazando hasta que la actividad queda realizada por completo. En este caso, a medida que se avanza, las nuevas tareas (mejoras, incidencias o nuevas funcionalidades) se acumulan en la sección inicial, de manera que en las reuniones periódicas con el cliente se priorizan y se colocan dentro de la sección que se estima oportuna.

Dicho tablero puede ser específico para un proyecto en concreto o bien genérico. No hay unas fases del ciclo de producción establecidas sino que se definirán según el caso en cuestión, o se establecerá un modelo aplicable genéricamente para cualquier proyecto de la organización.

2) Visualizar las fases del ciclo de producción. Al igual que Scrum, Kanban se basa en el principio de desarrollo incremental, dividiendo el trabajo en distintas partes. Esto significa que no hablamos de la tarea en sí, sino que lo dividimos en distintos pasos para agilizar el proceso de producción.

Normalmente cada una de esas partes se escribe en un post-it y se pega en el tablero, en la fase que corresponda. Dichos post-its contienen la información básica para que el equipo sepa rápidamente la carga total de trabajo que supone: normalmente   descripción de la tarea con la estimación de horas. Además, se pueden emplear fotos para asignar responsables así como también usar tarjetas con distintas formas para poner observaciones o indicar bloqueos (cuando una tarea no puede hacerse porqué depende de otra).

Al final, el objetivo de la visualización es clarificar al máximo el trabajo a realizar, las tareas asignadas a cada equipo de trabajo (o departamento), así como también las prioridades y la meta asignada.

3) Stop Starting, start finishing. Este es el lema principal de la metodología Kanban. De esta manera, se prioriza el trabajo que está en curso en vez de empezar nuevas tareas. Precisamente, una de las principales aportaciones del Kanban es que el trabajo en curso debe estar limitado y, por tanto, existe un número máximo de tareas a realizar en cada fase.

En realidad, se trata de definir el máximo número de tareas que podemos tener en cada una de las fases (p.e: 3 tareas en la fase de planificación; 2, en la fase de desarrollo; una, en la fase de pruebas, etc.) y, por tanto, restringir el trabajo en curso. A esto, se le añade otra idea que, por muy obvia que pueda parecer, la práctica nos demuestra que no es así: no se puede abrir una nueva tarea sin finalizar otra.

De esta manera, se pretende dar respuesta al problema habitual de muchas empresas de tener muchas tareas abiertas pero con un ratio de finalización muy bajo. Aquí lo importante es que las tareas que se abran se cierren antes de empezar con la siguiente.

4) Control del Flujo. A diferencia de SCRUM, la metodología Kanban no se aplica a un único proyecto, sino que mezcla tareas y proyectos. Se trata de mantener a los trabajadores con un flujo de trabajo constante, las tareas más importantes en cola para ser desarrolladas y un seguimiento pasivo para no tener que interrumpir al trabajador en cada momento.

Asimismo, dicha metodología de trabajo nos permite hacer un seguimiento del trabajo realizado, almacenando la información que nos proporcionan las tarjetas.

Freamework GWT

GWT o Google Web Toolkit

es un framework creado por Google que permite ocultar la complejidad de varios aspectos de la tecnología AJAX. Es compatible con varios navegadores, lo cual es notorio ya que cada navegador suele necesitar código específico para lograr un front-end correcto en una aplicación web. El concepto de Google Web Toolkit es bastante sencillo, básicamente lo que se debe hacer es crear el código en Java usando cualquier IDE de Java y el compilador lo traducirá a HTML y JavaScript.

Desarrollo

Con la biblioteca GWT, los desarrolladores pueden crear y depurar aplicaciones AJAX en lenguaje JAVA usando el entorno de desarrollo que prefieran. Cuando una aplicación es desplegada, el compilador GWT traduce la aplicación Java a un archivo Javascript, que puede ser ofuscado para optimizar el rendimiento.

GWT no es sólo una interfaz de programación; proporciona un conjunto de herramientas que permiten desarrollar funcionalidades Javascript de alto rendimiento en el navegador del cliente.

Una aplicación GWT puede ser ejecutada en dos modos:

Modo desarrollo (Dev mode): La aplicación se ejecuta como código bytecode de Java dentro de la Máquina Virtual de Java (JVM). Este modo es el más usado para desarrollo, soportando el cambio de código en caliente y el depurado.

Modo web (Web mode): La aplicación se ejecuta como código Javascript y HTML puro, compilado a partir del código Java. Este modo se suele usar para el despliegue de la aplicación.

La utilidad de línea de comandos applicationCreator genera automáticamente todos los archivos necesarios para iniciar un proyecto GWT, incluso permite crear un proyecto para Eclipse.


Existen varios plugins de código abierto para ayudar a desarrollar en diferentes entornos de desarrollo, como GWT4NB para NetBeans, Cypal Studio for GWT para Eclipse o gwtDeveloper para JDeveloper.


Arquitectura GWT

GWT contiene los siguientes componentes:4

GWT Java-to-JavaScript Compiler: la función de este componente es traducir el código desarrollado en Java al lenguaje JavaScript. Lo empleamos cuando usamos al GWT en modo web.

Hosted Web Browser: este componente ejecuta la aplicación Java sin traducirla a JavaScript, en modo host usando la máquina virtual de Java.

JRE Emulation Library: contiene las bibliotecas más importantes de las clases de Java: java.lang en donde se encuentran las clases fundamentales para poder programar en Java y un subconjunto de las clases del paquete java.util. Java.lang incluye, entre otras, la clase java.lang.object que es la clase fundamental de la que heredan o extienden todas las clases en Java. El resto de los paquetes no están soportados por GWT.

GWT Web UI Class Library: contiene un conjunto de elementos de interfaz de usuario que permite la creación de objetos tales como textos, cajas de texto, imágenes y botones.

Características

Componentes gráficos dinámicos y reusables: los programadores pueden usar clases prediseñadas para implementar comportamientos que de otra manera consumirían mucho tiempo, como arrastrar y soltar o menús en árbol.

Simple mecanismo RPC.

Gestión del historial del navegador web.

Soporte para depurado de Java.

Control de diferentes características del navegador.

Integración con JUnit.

Internacionalización.

Los desarrolladores pueden mezclar código escrito en Javascript dentro del código Java usando la Interfaz Nativa Javascript (JSNI).

Soporte para las API´s de Google (inicialmente, soporte para Google Gears).

Es de código abierto.

Los desarrolladores pueden diseñar y desarrollar sus aplicaciones orientadas a objetos. Errores comunes en Javascript, como la discrepancia de tipos de datos, son controlados en tiempo de compilación.

El código Javascript generado puede ser ofuscado para optimizar el rendimiento.

Existen un numeroso conjunto de bibliotecas desarrolladas por Google y terceros que amplían las funcionalidades de GWT.

Framework Grails

Grails 

es un framework para aplicaciones web libre desarrollado sobre el lenguaje de programación Groovy (el cual a su vez se basa en la Java platform). Grails pretende ser un marco de trabajo altamente productivo siguiendo paradigmas tales como convención sobre configuración o no te repitas (DRY), proporcionando un entorno de desarrollo estandarizado y ocultando gran parte de los detalles de configuración al programador.

Grails ha sido impulsado principalmente por la empresa G2One,1 la cual fue adquirida por la desarrolladora de software libre SpringSource en noviembre de 2008.2 En agosto de 2009 SpringSource fue a su vez adquirida por VMWare, empresa especializada en virtualización de sistemas. 3

Grails se ha desarrollado con una serie de objetivos en mente:

Ofrecer un framework web de alta productividad para la plataforma Java.

Reutilizar tecnologías Java ya probadas como Hibernate y Spring bajo una interfaz simple y consistente.

Ofrecer un framework consistente que reduzca la confusión y que sea fácil de aprender.

Ofrecer documentación para las partes del framework relevantes para sus usuarios.

Proporcionar lo que los usuarios necesitan en áreas que a menudo son complejas e inconsistentes:

Framework de persistencia potente y consistente.

Patrones de visualización potentes y fáciles de usar con GSP (Groovy Server Pages).

Bibliotecas de etiquetas dinámicas para crear fácilmente componentes web.

Buen soporte de Ajax que sea fácil de extender y personalizar.

Proporcionar aplicaciones ejemplo que muestren la potencia del framework.

Proporcionar un entorno de desarrollo orientado a pruebas.

Proporciona un entorno completo de desarrollo, incluyendo un servidor web y recarga automática de recursos.

Grails se ha diseñado para ser fácil de aprender, fácil para desarrollar aplicaciones y extensible. Intenta ofrecer el equilibrio adecuado entre consistencia y funcionalidades potentes.

Alta productividad

Grails tiene tres características que intentan incrementar su productividad comparándolo con los framework Java tradicionales:

Inexistencia de configuración XML.

Entorno de desarrollo preparado para funcionar desde el primer momento.

Funcionalidad disponible mediante métodos dinámicos.

Inexistencia de configuración XML

Crear aplicaciones web en Java tradicionalmente implica configurar entornos y frameworks al inicio y durante el desarrollo. Esta configuración a menudo está en ficheros XML para facilitar dicha configuración y evitar tenerla en el código fuente. XML fue inicialmente bienvenido para proporcionar consistencia para configurar aplicaciones. Sin embargo aunque el XML es muy útil para la configuración resulta complicado y tedioso utilizarlo para los entornos de desarrollo. La productividad de los programadores baja mucho mientras pasan tiempo configurando y manteniendo los frameworks mientras la aplicación crece. Añadir o modificar configuración en las aplicaciones que utilizan la configuración XML añade un paso extra al proceso de escribir aplicaciones que repercute en la productividad, reduciéndola y hace que el proceso completo sea poco ágil.

Grails elimina la necesidad de configurar ficheros XML. En su lugar el framework utiliza una serie de reglas de convención mientras examina el código de las aplicaciones basadas en Grails. Por ejemplo, una clase que termina en Controller es considerada un controlador web.

Entorno de desarrollo preparado para funcionar desde el primer momento

Mientras usamos herramientas Java tradicionales, es tarea del desarrollador ensamblar los componentes, lo cual puede ser tedioso. Grails tiene un servidor web integrado preparado para desplegar la aplicación desde el primer momento. Todas las librerías requeridas son parte de la distribución de Grails y están preparadas para ser desplegadas automáticamente.

Funcionalidad disponible mediante métodos dinámicos

Grails proporciona métodos dinámicos en varias de sus clases. Un método dinámico se añade a la clase en tiempo de ejecución, como si su funcionalidad hubiera sido compilada. Estos métodos dinámicos permiten a los desarrolladores realizar operaciones sin tener que implementar interfaces o heredar clases base. Grails proporciona método dinámicos basándose en el tipo de clase. Por ejemplo, la clases de dominio tienen métodos para automatizar operaciones de persistencia, como save para salvar, delete para borrar y find para buscar.

Framework Spring

SPRING

Spring es un framework para el desarrollo de aplicaciones y contenedor de inversión de control, de código abierto para la plataforma Java.2

Si bien las características fundamentales de Spring Framework pueden ser usadas en cualquier aplicación desarrollada en Java, existen variadas extensiones para la construcción de aplicaciones web sobre la plataforma Java EE. A pesar de que no impone ningún modelo de programación en particular, este framework se ha vuelto popular en la comunidad al ser considerado una alternativa, sustituto, e incluso un complemento al modelo EJB (Enterprise JavaBean).

Spring Framework comprende diversos módulos que proveen un rango de servicios:

Contenedor de inversión de control: permite la configuración de los componentes de aplicación y la administración del ciclo de vida de los objetos Java, se lleva a cabo principalmente a través de la inyección de dependencias.

Programación orientada a aspectos: habilita la implementación de rutinas transversales.

Acceso a datos: se trabaja con RDBMS en la plataforma java, usando Java Database Connectivity y herramientas de Mapeo objeto relacional con bases de datos NoSQL.

Gestión de transacciones: unifica distintas APIs de gestión y coordina las transacciones para los objetos Java.

Modelo vista controlador: Un framework basado en HTTP y servlets, que provee herramientas para la extensión y personalización de aplicaciones web y servicios web REST.

Framework de acceso remoto: Permite la importación y exportación estilo RPC, de objetos Java a través de redes que soporten RMI, CORBA y protocolos basados en HTTP incluyendo servicios web (SOAP).

Convención sobre Configuración: el módulo Spring Roo ofrece una solución rápida para el desarrollo de aplicaciones basadas en Spring Framework, privilegiando la simplicidad sin perder flexibilidad.

Procesamiento por lotes: un framework para procesamiento de mucho volumen que como características incluye funciones de registro/trazado, manejo de transacciones, estadísticas de procesamiento de tareas, reinicio de tareas, y manejo de recursos.

Autenticación y Autorización: procesos de seguridad configurables que soportan un rango de estándares, protocolos, herramientas y prácticas a través del subproyecto Spring Security (antiguamente Acegi).

Administración Remota: Configuración de visibilidad y gestión de objetos Java para la configuración local o remota vía JMX.

Mensajes: Registro configurable de objetos receptores de mensajes, para el consumo transparente desde la a través de JMS, una mejora del envío de mensajes sobre las API JMS estándar.

Testing: Soporte de clases para desarrollo de unidades de prueba e integración.

IEEE830

Introducción:

El análisis de requisitos es una de las tareas más importantes en el ciclo de vida del desarrollo de software, ya que este establece que debe hacer el sistema, basándose en las características y atributos que este debe poseer, omitiendo el cómo será su implementación, fase posterior del diseño del 
sistema.

El análisis de requisitos se puede definir como el estudio de las necesidades de los usuarios para llegar a una definición exacta de los requisitos del sistema, así como el refinamiento y proceso de estudios de estos. Esta definición es proporcionada por el IEEE, normativa útil para redactar la Especificación de Requisitos de Software (ERS), el cual es el documento final con todo el contenido de cómo se comportara a futuro el sistema según la necesidad del cliente.

Objetivos de una ERS:

-          Ayuda al cliente a describir claramente lo que desea obtener mediante un software. Este proceso de retroalimentación es clave, ya que el cliente es quien tiene el mayor conocimiento sobre los procesos que se llevan a cabo y así también se siente participe del propio desarrollo.

-          Ayuda al desarrollador a saber que es realmente lo que quiere un cliente, ante las indecisiones o desconocimientos que estos puedan presentar. Las ERS ayudan al desarrollador dándole una base por donde partir el trabajo.

-          Servir como base para desarrollos estándares de ERS, donde cada entidad puede desarrollar su propio estándar según las necesidades que el sistema tenga.

Las características de un ERS son:

-          Debe ser Correcta, es decir, que cada requisito represente una necesidad real.

-          No debe ser ambigua: solo debe tener una interpretación en cuanto a las características del producto final.

-          Debe tener completitud en requisitos, definición de respuestas a las posibles entradas, etiquetado de figuras e imágenes y definición de términos.

-          Debe ser Verificable: que se pueda chequear el software con respecto a un requisito.

-          Debe ser consistente, es decir, que ningún requisito entre en conflicto con otro.

-          Debe ser clasificada: tomar la importancia correspondiente a cada requisito.

-          Modificable: Que de haber un cambio, sea realizado de manera fácil, rápida y consistente, con requisitos no redundantes.

-          Explorable en sus requisitos, donde el origen de este sea recorrido tanto hacia atrás como adelante, con referencias.

La ERS es una descripción que debe decir ciertas cosas de una determinada manera. Uno de estos estándares es el IEEE380.

A continuación se presenta como es la estructura según el IEEE en su estándar 830.

1.       Introducción

Aquí se proporciona un resumen del documento de ERS.

1.1.    Propósito

Se define el propósito  del documento y a quién va dirigido.

1.2.    Ámbito del Sistema

Aquí se define el nombre del sistema,  se explica lo que hace y no hace, la descripción de beneficios, objetivos y metas.

1.3.    Definiciones, Acrónimos y Abreviaturas

Se definen los términos utilizados en el desarrollo de la ERS

1.4.    Referencias

Se presenta un listado de los documentos referenciados.

1.5.    Visión general del  documento

En esta sección se describe brevemente la organización y contenidos de la ERS.

2.       Descripción General

Aquí se describenlos factores que afectan al producto y sus requisitos. Se define el contexto de cada requisito.

2.1.    Perspectiva del Producto

En esta subsección se debe relacionar el futuro sistema con otros productos. Se pueden considerar los siguientes tópicos.

2.1.1. Indicar si es producto independiente o parte de un sistema mayor

2.1.2. Interfaces del Sistema

2.1.3. Interfaces de Usuarios

2.1.3.1.             Características Lógicas de Interfaz

2.1.3.2.             Cuestiones de Optimización del Interfaz de Usuario

2.1.4. Interfaces de Hardware

2.1.5. Interfaces de Software

2.1.5.1.             Descripción del Software Utilizado

2.1.5.2.             Propósito del Interfaz

2.1.5.3.             Definición de Interfaz: Contenido y Formato

2.1.6. Interfaces de Comunicaciones

2.1.7. Limitaciones de Memoria

2.1.8. Operaciones

2.1.8.1.             Modos de Operación de los grupos de Usuario

2.1.8.2.             Periodos de Operación Interactiva y Automáticas

2.1.8.3.             Funciones de Respaldo del Procesamiento de Datos

2.1.8.4.             Operaciones de Backup y Recuperación

2.1.9. Requerimientos para Adaptación de Ubicación

2.1.9.1.             Indicar cualquier dato de inicialización especifica en cualquier lugar, modo de operación.

2.1.9.2.             Características que deben ser modificadas para una instalación en particular

2.2.    Funciones del Producto

En esta sección se proporciona la información de las funciones principales que el software debe llevar a cabo. Debe ser legible tanto por el cliente como por el desarrollador.

2.3.    Características de los Usuarios

Se describe el usuario al cual se dirige esta aplicación, asi como su experiencia técnica, nivel de conocimientos, etc.

2.4.    Restricciones

Se indica aquí cualquier limitación impuesta por el cliente al desarrollador. Pueden ser por políticas empresariales, límite de software y hardware, protocolos de comunicación, etc.

2.5.    Suposiciones y Dependencias

En esa sección se describen aquellos factores que, de cambiar, pueden afectar los requisitos del sistema.

2.6.    Requisitos Futuros

Aquí se esboza alguna mejora a futuro del sistema.

3.       Requisitos Específicos

Esta sección contiene los requisitos a un nivel de detalle suficiente como para permitir a los diseñadores diseñar un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos.

3.1.    Interfaces Externas

Se describen los requisitos que afectan a la interfaz de usuario, interfaz con otros sistemas e interfaces de comunicación.

3.2.    Funciones

En esta subsección se especifican todas las funciones que debe llevar a cabo el software. Debe ser organizada según los tipos de usuario, los objetos (entidades del mundo real reflejadas en el sistema), por objetivos, estímulos y jerarquía funcional.

3.3.    Requisitos de Rendimiento

Se detallarán los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por ejemplo, el número de terminales, el número esperado de usuarios simultáneamente conectados, número de transacciones por segundo que deberá soportar el sistema, etc.

También, si es necesario, se especificarán  los requisitos de datos, es decir, aquellos requisitos que afecten a la información que se guardará en la base de datos.

3.4.    Restricciones de Diseño

Es todo aquello que restrinja las decisiones relativas al diseño de la aplicación.

3.5.    Atributos del Sistema

Se detallan los atributos de calidad (las “ilities”) del sistema: Fiabilidad, mantención, portabilidad, y, muy importante, la seguridad. Deberá especificarse qué tipos de usuario están autorizados, o no, a realizar ciertas tareas, y cómo se implementarán los mecanismos de seguridad (por ejemplo, por medio de un login y una password).

3.6.    Otros Requisitos

Cualquier otro requisito que no encaje en otras secciones.

4.       Apéndices

Pueden contener todo tipo de información relevante para la ERS pero que, propiamente, no forme parte de la ERS.

Por ejemplo:

1. Formatos de entrada/salida de datos, por pantalla o en listados.

2. Resultados de análisis de costes.

3. Restricciones acerca del lenguaje de programación

5.       Índice

Conclusión:

                
La importancia de contar con una buena definición de las especificaciones de requerimientos es tener la comprensión total de las necesidades del usuario. Puede estar totalmente bien diseñado y codificado el software, pero de no analizarse bien los requerimientos del cliente puede llevar a que este se sienta defraudado y a la frustración del desarrollador.

                
El documento de especificación de requisitos del software indica las necesidades del cliente y lo que deben implementar los desarrolladores. Es la principal razón por la cual la fase de análisis de requerimientos tiene tanta importancia.

La existencia de un estándar como el IEEE830 permite la coherencia en la especificación de requisitos y ayuda a no dejar cabos sueltos.