miércoles, 30 de mayo de 2012

Desarrollo Rápido con Spring Roo.


Spring Roo es una herramienta de desarrollo rápido de aplicaciones (RAD), que permite el desarrollo de aplicaciones Java EE de manera más productiva y cómoda para el desarrollador.

Tecnologias Utilizadas.

  • Spring Framework: framework de Java cuya principal caracteristicas es brindar una fabrica de objetos basado en la Inyeccion de Depedencias.
  • Spring MVC: modulo del framework Spring, que implementa una arquitectura Modelo-Vista-Controlador para desarrollar una aplicación web.
  • Spring Security: modulo del framework Spring, que permite gestionar completamente la seguridad de las aplicaciones Java.
  • Spring Web Flow: modulo del framework Spring, que define y gestiona los flujos de paginas dentro de una aplicación web.
  • Selenium: herramienta para hacer pruebas de aplicaciones web.
  • Maven: herramienta de software para la gestión y construcción de proyectos Java, basado en un formato XML.
  • Log4j: biblioteca desarrollada en Java que permite a los desarrolladores de software elegir la salida y el nivel de granularidad de los logs a tiempo de ejecución.
  • JUnit: conjunto de bibliotecas utilizadas para hacer pruebas unitarias de aplicaciones Java y llevar un desarrollo guiado por pruebas (TDD).
  • JavaServer Pages.
  • Java Persistence Api (JPA): framework de java que maneja datos relacionales en aplicaciones, no perdiendo las ventajas de la orientación a objetos al interactuar con una base de datos (mapeo objeto-relacional), y permitiendo usar objetos regulares (POJOs)
  • AspectJ: lenguaje de programación orientado a aspectos construido como una extensión del lenguaje Java.

Caracteristicas.

  • Genera código (de forma activa y pasiva) para aplicaciones Java con Spring.
  • Eliminar el trabajo tedioso centrando el desarrollo en la lógica de negocio.
  • Se basa en el paradigma Convencion sobre Configuración (CoC).
  • Posee un enfoque de diseño guiado por el dominio (DDD).

    • Está dirigido por un modelo de entidades.
    • Se centra en la logica de las entidades y elimina las capas redundantes.
    • Utiliza el patron de diseño "Active Record" en oposicion al anti-patrón de diseño "Anemic Domain Model (ADM)".

  • Crea un proyecto en minutos.
  • Añade valor durante todo el ciclo de vida (Retroalimentación).
  • Las aplicaciones siguen las mejores práticas de diseño.
  • Permite auto-generar test unitarios y de integración.
  • No incorpora elementos adicionales al entorno de ejecución, por lo que no penaliza la velocidad de aplicación.
  • Se puede integrar con IDEs como Spring Tool Suite o Eclipse.
  • Recibe instrucciones a través de una consola interactiva con auto-completado y ayuda en línea.
  • Es extensible usando modulos OSGI (ficheros JAR con un conjunto de metadatos que especifican la caracteristicas del modulo).
  • Se puede eliminar un proyecto en minutos.

Interfaz de Linea de Comandos (CLI)

Spring Roo es una herramienta de Linea de Comandos (CLI) de fácil uso, que proporciona auto-completado "Tab" de comandos y argumentos, y ayuda en linea mediante "help" y "hint".



Arquitectura.

Roo genera código que se puede dividir en dos categorías:

  1. Código gestionado por Spring Roo => Ficheros AspectJ ITD (.aj)
  2. Código gestionado por el programador => Fuentes Java.



En tiempo de compilación, el código de los ficheros .aj, es tejido en el código de los fuentes Java.


Ejemplo: Aplicacion de Inventario.


Se tiene una clase "Producto" con sus respectivos atributos: numero identificador (id_producto), nombre, descripcion y precio.


Se procede a crear la carpeta "Inventario" donde se almacenara el proyecto, y dentro de esta, se ingresa a la consola del Roo.


A continuación se comienza a desarrollar la aplicación:

// Se Crea el Proyecto
roo> project --topLevelPackage com.curso.inventario
// Se Define la herramienta de persistencia y la base de datos a utilizar
roo> jpa setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY
// Se Crea la entidad "Producto"
roo> entity jpa --class ~.domain.Producto --testAutomatically
// Se crean los antributos de la entidad "Producto" con sus respectivas restricciones
roo> field number --fieldName id_Producto --type int --notnull
roo> field string --fieldName nombre --notNull
roo> field string --fieldName descripcion
roo> field number --fieldName precio --type double
// Se genera la capa de presentacion
roo> web mvc setup
roo> web mvc all --package ~.web
// Se ejecutan las pruebas respectivas
roo> perform tests
// Se empaqueta el proyecto
roo> perform package
// Se estructura el proyecto para ser usado y modificado en eclipse
roo> perform eclipse
// Se sale de Roo
roo> exit
// Se despliega la aplicación en un contenedor web
C:\Users\Arak\Roo\Inventario> mvn tomcat:run

A traves de estos simples pasos, se genero la siguiente aplicación web:



Desarrollo en MQ Arriendos.

Se propone desarrollar la aplicación del "Sistema de Inventario" para MQ Arriendo utilizando Spring Roo, donde cada tarea asociada a un requerimiento, tendra un script con todos los comandos utilizados en el desarrollo de la aplicacion de esa tarea. Luego estos script se uniran para formar solo uno, y por ende, solo una aplicación que integre todas las tareas y finalmente todos los requerimientos planteados por el Product Owner.


Fuente y más información:

Desarrollo en Java EE.



Java es un lenguaje de programación que como plataforma integra tres componentes:

  • Lenguaje: lenguaje de alto nivel que utiliza el paradigma POO.
  • Maquina Virtual: permite que los programas ejecutables sean compilados como archivos ejecutables de la Java Virtual Machine (JVM), y que sean ejecutados en distintas arquitecturas.
  • Bibliotecas: tambien conocidas como Java Aplication Programming Interface (Java API) que es un conjunto de componentes que proporcionan diferentes herramientas para el desarrollo.

Ediciones.


  1. Java Micro Edition (Java ME): se enfoca en el manejo de java en dispositivos móviles y portátiles.
  2. Java Standart Edition (Java SE): define las caracteristicas basicas para trabajar en ambientes de escritorio y servidores.
  3. Java Enterprise Edition (Java EE): define las características necesarias para desarrollar aplicaciones empresariales que se ejecuten de forma portable a través de servidores de aplicaciones.


La plataforma Java EE permite crear aplicaciones empresariales basado en un modelo de multicapas, que divide a la aplicación en diferentes niveles, cada uno con una tarea especifica.

Componentes.


De los elementos aqui nombrados, los principales son:

  • Java Servlet: programas que permiten generar páginas web de forma dinámica, a partir de los parámetros de petición que envíe el navegador web.
  • JavaServer Pages (JSP): tecnologia Java que permite generar contenido dinámico para web, en forma de documentos HTML, XML o de otro tipo.
  • JavaServer Faces (JSF): tecnología Java basada en web que simplifica el desarrollo de interfaces de usuario.
  • Enterprise Java Bean (EJB): modulos encargados de manejar toda la logica de programación detras de la aplicación.

La utilización en niveles de la logica de programación, permite separar los elementos de las aplicaciones en partes explicitamente definidas, como por ejemplo, dejar los procesos en un lugar, los datos en otro y mostrar las interfaces en otro.

Aplicaciones en Multicapas.

En la programación por capas, la idea es buscar la forma de separar lo que ve el usuario de los procesos creados por el desarrollador. En la siguiente figura se muestran las diferentes capas que posee una aplicación Java EE:


Enfoque Java EE en MQ Arriendos.

Para llevar a cabo el desarrollo del Sistema de Inventario en MQ Arriendos, se utilizara una herramienta llamada Spring Roo, la cual se enfoca en el desarrollo rapido de aplicaciones Java EE de manera más productiva y cómoda para el desarrollador. En el siguiente articulo hablaremos sobre esta herramienta.

Fuente y más información:

sábado, 26 de mayo de 2012

Diseño con UML.


¿Qué es UML?

UML (Lenguaje Unificado de Modelado) es una herramienta que permite a los creadores de sistemas generar diseños que capturen sus ideas en una forma convencional y fácil de comprender para comunicarlas a otras personas.

¿Por qué es necesario?

Antes de UML, el desarrollo de sistema era, con frecuencia, una propuesta al azar. Los analistas de sistemas intentaban evaluar los requerimientos de sus clientes, generar un análisis de requerimientos en algún tipo de notación que ellos mismo comprendieran (aunque el cliente no lo comprendiera), dar tal análisis a uno o varios programadores y esperar que el producto final cumpliese con lo que el cliente deseaba.

Al ser el desarrollo de sistema una actividad humano, existen muchas posibilidades de cometer errores en cualquier etapa del proceso:

  • El analista produce un documento que el cliente no puede comprender.
  • El documento generado por el analista no fue comprendido por los programadores.
  • Generar programas dificiles de utilizar.
  • No generar una solución al problema original del cliente.

Hoy en día, un cliente tiene que comprender qué es lo que hará un equipo de desarrollo, y debe ser capaz de señalar cambios si no se han captado claramente sus necesidades o si cambia de opinion durante el proceso.

La clave está en organizar el proceso de diseño de tal forma que los analistas, clientes, desarrolladores y otras personas involucradas en el desarrollo del sistema lo comprendan y convengan con el.

Organizacion de UML.

El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas, con la finalidad de presentar diversas perspectivas de un sistema (modelo). Un modelo UML describe lo que supuestamente hará un sistema, pero no dice cómo implementar dicho sistema.

A continuación se presenta un mapa conceptual en donde se nombran un conjunto de elementos que agrupan distintos tipos de diagramas UML:



De estos diagramas, los mas usados en la Ingeniería de Software son los siguientes:

i) Diagrama de Clases: tipo de diagrama estatico que describe la estructura de un sistema mostrando sus clases, atributos, metodos y las relaciones entre ellos.


Estos diagramas son utilizados durante el proceso de análisis y diseño de sistemas, en donde se crea el diseño conceptual de la información que se manejara, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

ii) Diagrama de Casos de Uso: diagrama de comportamiento que muestra la relación entre los actores y los casos de uso de un sistema. Aqui se representa al sistema mediante una caja rectangular con el nombre en su interior. Los casos de uso se encuentran dentro de la caja del sistema y los actores fuera de ella. Cada actor está unido a los casos de uso en los que participa mediante una línea de interacción.


iii) Diagrama de Secuencia: representación de las interacciones (mensajes) que muestran los objetos entre si a lo largo de su vida en el tiempo.

Su funcion es mostrar que objetos se comunican con otros y que mensajes se dan en esas comunicaciones.



Para generar estos diagramas se analizan casos de uso, con el fin de determinar los objetos que son necesarios para la implementación del escenario, es decir, una secuencia de varios pasos a seguir para lograr conceptualizar los casos de uso.

iv) Diagrama de Colaboración: tipo de diagrama en donde se muestran las interacciones entre objetos organizados y enlazados entre ellos.



v) Diagrama de Estado: diagrama que representa la descripción del comportamiento de un sistema, dando a conocer todos los estados posibles en los que puede estar un objeto especifico a lo largo de su ciclo de vida.



vi) Diagrama de Actividades: diagrama que muestra el flujo de control entre actividades, es decir, muestra las operaciones que ocurren entre objetos que interactuan entre sí.


Conclusión.

UML proporciona una visión mas global de lo que se quiere construir, ya que para cada una de las clases que compone el modelo unificado, se conoce: la relación entre las clases, los métodos públicos y privados de las clases y objetos que la componen, los datos que necesitan y producen estos objetos. Todo esto nos proporciona un mayor dominio del negocio y de los procesos que implementan las reglas de negocio que trabajan sobre un modelo especifico.

Fuente y más información:

Diseño Orientado a Objetos.

La Programación Orientada a Objetos (POO) es un paradigma o modelo de programación, que usa objetos y sus interacciones, para diseñar aplicaciones y sistemas. Esta describe el problema en terminos del problema en lugar de en terminos de la computadora en la que se ejecutara la solución.

El objetivo es que el programa pueda adaptarse por sí solo a la jerga del problema añadiendo nuevos tipos de objetos, de modo que cuando se lea el código que describe la solución, se estén leyendo palabras que también expresen el problema.

Conceptos.

  • Clase: es aquella que describe un conjunto de objetos que tienen caracteristicas (elementos de datos) y comportamientos (funcionalidad) idénticos.
  • Objeto: entidad con un estado determinado (datos que lo componen), un comportamiento definido (metodos o mensajes a los que responde) y una identidad unívoca (su identificador).
  • Propiedad o Atributo: contenedor de un tipo de dato asociado a un objeto, que hace los datos visibles desde fuera del objeto y cuyo valor puede ser alterado por la ejecución de algún método.
  • Metodo: operaciones que pueden modificar el comportamiento de un objeto tras la recepción de un "mensaje".
  • Evento: accion que puede generar un objeto.
  • Mensaje: comunicación dirigida a un objeto, que ordena que ejecute uno de sus metodos en base a ciertos parametros asociados al evento que lo generó.

Principios.

  • Herencia: capacidad que tiene una clase de derivar las propiedades y métodos en otra, permitiendo que los objetos compartan y extiendan su comportamiento sin tener que volver a implementarlos.
  • Abstracción: capacidad de seleccionar las características relevantes dentro de un conjunto de objetos e identificar comportamientos comunes para definir nuevos tipos de objetos.
  • Polimorfismo: capacidad que tienen los objetos de una clase de responder al mismo mensaje o evento en función de los parametros utilizados.
  • Encapsulamiento: capacidad de ocultar los datos miembros de un objeto, de manera que este solo puede ser modificado por operaciones o metodos definidos para ello.

Este enfoque proporciona herramientas al programador para representar los elementos en el espacio del problema, sin estar restringido a ningun tipo de problema en particular.

Una de las herramientas para modelar sistemas usando el paradigma de POO es UML, el cual nos permite diagramar la realidad de los requerimientos. De esta herramienta hablaremos en el proximo articulo.

Fuente y más información: 

  • Libro: Piensa en Java, Bruce Eckel, 4ta Edicion.

viernes, 25 de mayo de 2012

SIMAQ: Planificación Sprint 1.

En base a los requerimientos nombrados en la ultima publicacion "MQ Arriendos: Requerimientos y Scrum", se ordenan estos últimos en 4 requerimientos y luego se agregan a la Pila de Producto. Se considera tambien dentro de esta Pila, la estimacion de valor del Product Owner y la estimacion de esfuerzo del Equipo por cada requerimiento. A continuacion se muestra la Pila de Producto resultante:

  

Con la Pila de Producto definida, se lleva a cabo la primera parte de la reunion de planificacion del Sprint 1, en donde junto al Product Owner y el Equipo:

  • Se revisan los elementos de alta prioridad que el Product Owner está interesado en implementar para el Sprint.
  • Se habla sobre los objetivos y el contexto de dichos elementos de alta prioridad, de tal forma que el Equipo se haga una idea de lo que piensa el Product Owner.
  • Se revisa la definicion de "Hecho": codigo integrado, completamente probado y potencialmente entregable.

En la segunda parte de la reunion de planificacion del Sprint 1, el Equipo:

  • Selecciona los elementos de la Pila de Producto a los que se comprometen a tener finalizados al final del Sprint, comenzando por los elementos con mayor prioridad y escribiendo la lista en orden.
  • Estima cuanto tiempo tiene cada miembro para trabajo relacionado con el Sprint:
  

  • Divide en tareas individuales los elementos seleccionados de la Pila de Producto, asignandole a cada una, estimaciones de horas de trabajo. Luego cada integrante se ofrece de voluntario para realizar una tarea especifica.
Finalmente la Pila del Sprint resultante es la siguiente:

   
Teniendo la Pila de Sprint, se arma la hoja visual de seguimiento de tareas, en donde cada tarea es representada por un post-its:



Con esta planificación finalizada, se da comienzo al Sprint 1 del proyecto SIMAQ: Sistema de Inventario para MQ Arriendos.

domingo, 20 de mayo de 2012

MQ Arriendos: Requerimientos y Scrum.

El requisito principal de la empresa MQ Arriendos es implementar un Sistema de Inventario que satisfaga los siguientes requerimientos:

  1. Ingresar nombre del producto: se ingresa el nombre o tipo de maquina solicitada para poder verificar el producto en inventario.
  2. Gestionar el control del inventario: se verifica la cantidad de productos y el estado en el que se encuentran.
  3. Solicitar datos del cliente: se ingresan los datos del cliente para poder generar los cobros correspondientes por arriendo.
  4. Ingresar estado de la maquina: se ingresa el estado de la maquina para así realizar chequeos que permita que estas sean entregadas en optimas condiciones.
  5. Ingresa solicitud del cliente: se ingresa la solicitud del cliente al sistema para generar el contrato de arriendo, incluyendo formas de pago y fechas.
  6. Asignar modo de despacho: se asigna el modo de despacho dependiendo si el cliente retira la maquinaria en local o si se asigna un movil para esto.
  7. Modificar ficha del producto: se modifica la ficha del producto para que cuando salga de tienda quede registrado.
  8. Entregar información para facturación: se genera informacion para generar un comprobante para el cliente.

Para el desarrollo del Sistema de Inventario se decide utilizar la metodologia agil Scrum. Esta se aplicara utilizando las siguientes herramientas:

  • Una planilla para la Pila del Producto:


  • Una planilla para la Pila de Sprint:

  

  • Una planilla para las horas disponibles:
 
 
  • Una hoja de papel de 53x38 cm como herramienta visual de seguimiento de tareas (escritas en post-its):

 


Los roles a desempeñar durante el proyecto son los siguientes:

  • Scrum Master: Pablo.
  • Product Owner: Andres.
  • El Equipo: Pablo, Andres, Gladys, Cristobal y Israel.

En cuanto a la reuniones diarias durante los Sprint, se considera el horario de clases del semestre, y se decide hacer reuniones presenciales los Lunes, Martes y Jueves, y reuniones no presenciales via internet los Miercoles y Viernes.

En base a la información presente se comienza con la planificacion del primer Sprint.

Metodologia Agil: Scrum.


¿Rugby? No, no, no. Scrum es una metodología ágil que relaciona el desarrollo exitoso de productos con el juego del rugby en el que un equipo auto-organizado (auto-gestionado) y multi-funcional se mueve junto por el campo de desarrollo de productos. El termino "Scrum" (melé) y la relación con el rugby, nace en un articulo publicado en el Harvard Business Review en 1986, donde se habla de prácticas asociadas con grupos exitosos de desarrollo de productos. Hoy en día Scrum es usado por empresas de todos los tamaños tales como Yahoo!, Microsoft, Google, Motorola, SAP y Cisco.

Algunas características de Scrum son las siguientes:

  • Es un marco de trabajo iterativo e incremental que se utiliza para el desarrollo de proyectos, productos y aplicaciones. 
  • Estructura el desarrollo en ciclos de trabajo llamados Sprints (iteraciones de 1 a 4 semanas). 
  • Los Sprint son de duración fija, es decir, terminan en una fecha específica aunque no se haya terminado el trabajo (nunca se alargan y limitan el tiempo). 
  • Al comienzo de cada Sprint, el equipo multi-funcional selecciona los requisitos del cliente de una lista priorizada, y se compromete a tenerlos terminados al final de Sprint. 
  • Durante el Sprint no se pueden cambiar los requisitos elegidos. 
  • Todos los días el equipo se reúne brevemente para informar de los avances, y actualizar unas gráficas que les orientan sobre el trabajo restante. 
  • Al finalizar el Sprint, el equipo revisa el Sprint con los interesados, y les enseña lo que han construido. De esto se obtienen comentarios y observaciones que se pueden incorporar al siguiente Sprint.

Scrum pone énfasis en productos que funcionen al final del Sprint que realmente estén "hechos"; en el caso del Software significa que el código esté integrado, completamente probado y potencialmente entregable.

Los roles, artefactos y eventos principales se resumen en la siguiente figura:



Un tema importante en Scrum es "inspeccionar y adaptar". El desarrollo inevitablemente implica aprender, innovación y sorpresas. Es por esto que Scrum se enfoca en

  1. Dar un pequeño paso de desarrollo.
  2. Inspeccionar el producto resultante y la eficacia de las prácticas actuales.
  3. Adaptar el objetivo del producto y las prácticas del proceso.

Fuente y más información: http://assets.scrumfoundation.com/downloads/3/scrumprimer_es.pdf?1285932063