Página principal

Este blog es una herramienta para plasmar las ideas del autor, compartir su conocimiento de una manera práctica que pueda servirle a alguien y como notas o tips que le han servido en varios ámbitos.
La información contenida es principalmente respecto a tecnología Java, desarrollo y arquitectura de software y programación en general.
El sitio del autor se encuentra en http://www.eliumontoya.com

La lista completa se encuentra en la sección Indice de Posts


Ver el perfil de Eliu Montoya Mariscal en LinkedIn

Gobernanza y Cobit: por qué es importante que un desarrollador lo conozca

publicado a la‎(s)‎ 3 dic 2012, 11:28 por Eliu Montoya   [ actualizado el 4 dic 2012, 19:05 ]


Tema
: Explicación de la importancia de aprender frameworks de gobernanza como Cobit
Categoria: Explicación concreta / Metodologías
Tecnologías / Componentes: Gobernanza, Cobit


Es importante el conocimiento, aunque no precisamente el dominio total , que un desarrollador debe tener sobre la gobernabilidad o gobernanza del área de IT así que en la primera parte explicaré que es gobernanza y una introduccion a Cobit y en la segunda parte expondre mi razones por las que todo desarrollador debe conocerlo.

Que es gobernanza de IT


En la actualidad IT se encuentra en todas las fases de nuestra vida cotidiana: celulares, carros , microondas, tabletas, radio, música etc; así que podemos ver que IT no es un tema de geeks, sino que ya nos incumbe a todos. De igual manera, IT a permeado en todos los niveles de una empresa así que, ya no sólo es tema de directores o exclusivo del área de sistemas. La tecnología se encuentra en mercadotecnia, funciones administrativas, contabilidad, etc. Se encuentra en los proveedores, clientes , gobiernos de países, leyes que cumplir etc. Así que IT ya no sólo incumbe a programadores , arquitectos líderes de proyecto etc. 

Debido a esta complejidad y amplia difusión es cada vez más importante poder administrar una empresa con la ayuda de  IT. Administrar una empresa implica tener un gobierno de la empresa definido y esto conlleva definir el camino , futuro y presente de la empresa; definir los procedimientos, procesos, funciones de cada área; resolver los conflictos internos, comunicar los objetivos, la misión, logros, retos, etc. 

Así que para llevar esta gobernanza eficientemente se puede ayudar en las vastas herramientas y metodologías de IT.  Por lo que, cada vez más, la dirección de las empresas están incluyendo al director de IT (o sistemas) en las decisiones. Un buen director de IT se convierte en un asesor o consultor del CEO para utilizar la tecnología para lograr los objetivos de la empresa.

Alineacion de IT

¡Esto es alinear IT con la empresa!


Por lo regular, en las empresas, el área de IT funciona por su propia cuenta; por lo regular, llevan sus propios proyectos y no son incluidos en las decisiones generales de la empresa; por lo regular, sólo le comunican a dónde quiere ir la empresa y cuales son los proyectos prioritarias en los que debe enfocarse.

Por otro lado, una empresa que tiene alineada su área de IT, el director de sistemas es parte de las decisiones y sugiere qué es lo que hay que hacer desde la perspectiva de la tecnología para lograr esos objetivos corporativos. El director toma un papel proactivo en lugar de uno pasivo.

Importancia de la gobernanza de IT


Si IT esta teniendo tanta importancia, es necesario que la misma área comience a tener una metodología definida  para poder administrarse eficientemente; requiere tener definidos sus propios procesos, objetivos, misión y funciones y comunicarlos. Además, estas definiciones deben estar alineadas a los del corporativo.



gobernabilidad IT

Esto es gobernabilidad de IT



Por ejemplo, supongamos un área de IT la cual no está alineada y por ofrecer un servicio excelente con sus clientes comienza a hacer actividades extras. Esto podría parecer que el área es eficiente y proactivo; sin embargo, podría ser que a la empresa le sea perjudicial ya que podría estar cobrando estas actividades extras o porque simplemente tiene una cierta política sobre cómo interactuar con otros proveedores. Además, podría ser que la proactividad del área está ayudando y fortaleciendo a la competencia, y esta empresa, por no involucrar al área de IT en las decisiones corporativas, se está auto puñaleando ya que IT puede justificarse en que no tenía conocimiento y la visión completa.

Como podemos imaginarnos llevar la gobernabilidad de una área de IT no es fácil, sin embargo, existen frameworks que dan tips sugerencias o recetas para facilitarlo.

¡Cobit es precisamente un framework que ofrece recetas de buenas prácticas para eso!

Gobernanza vs administración

Para poder decir que Cobit es un frameworks de gobernanza y no de administración es necesario diferenciar ambos conceptos.

Gobernanza es definir el camino del área. Identificar las necesidades de los clientes e involucrados en general (stakeholders); definir los procesos y los objetivos priorizandolos.y monitorizar los resultados. Tener controles. 
Las palabras claves son "Identificar, definir y monitorizar".

Administrar es asegurar que el área logre que se realicen los procesos y obtener los resultados. Ésto mediante: planear, diseñar,  implementar y monitorizar las operaciones técnicas que respaldan a los objetivos empresariales. 

Obviamente, la administración tiene que dar feedback a la gobernanza para que comience nuevamente el ciclo.

Razones para que desarrolladores lo conozcan


1. Nuevo rol. 

Como hemos visto el uso de la tecnología se encuentra realmente en todos los ámbitos, tanto en la vida cotidiana como en todas las funciones de las empresas. Por lo tanto, tenemos que comprender nuestro nuevo rol. Como desarrolladores y expertos en tecnología nuestro nuevo rol se ha potencializado y ahora nuestro conocimiento y actividades impactan al mundo y a las empresas. Al ser expertos en alguna de las áreas de IT nos da una ventaja enorme sobre las demás disciplinas, por lo que, sólo tenemos que ampliar nuestro conocimiento técnico con gestión y gobernabilidad y podremos hacer cambios importantes en las empresas en general, en la sociedad y de cierta manera estamos haciendo mejor  al mundo.

2. Crecimiento personal y profesional. 

Conocimiento es poder, pero no sólo es conocimiento especializado sino también holísitico o integral: completo. Esto genera sabiduría. 
A muchos nos fascina ser técnicos y nuestra orgullo es aprender más y saber que cada vez somos mejores programadores, desarrolladores o ingenieros en general. Pero a veces, esa obsesión nos aparta de otros temas, y a veces hasta los consideramos inferiores. Sin embargo, ese pensamiento nos está coartando nuestro crecimiento técnico consideradamente.
¿Que pasa si no sabemos un segundo idioma y sólo nos quedamos con el nativo? Simplemente, nos estamos limitando a platicar con más gente , a leer más libros. Sería un verdadero desperdicio que limitaramos nuestro crecimiento en conocimiento sólo por no hablar otro idioma. 
De igual manera nos limitamos como expertos técnicos. El poder conocer temas de administración y gobernanza nos amplía nuestro conocimiento técnico. Al hablar el mismo idioma de un administrador de proyectos o de un gerente o director aprenderemos otros puntos de vista de la tecnología, otros usos y necesidades, otras quejas y maneras de solución.
Podemos aprender de ellos, procesarlo e implementarlo en la parte técnica.

3. Sabiduría

La pirámide de madurez de la información es: datos - información - conocimiento - sabiduría. 
Cuando logremos hablar de un tema técnico pero después poder relacionarlo desde el punto de vista gerencial y después ligarlo a tablas y namespaces lograremos una madurez profesional impresionante. El poder subir y bajar denota sabiduría.

4. Delimitar nuestras responsabilidades. 

Finalmente considero que no hay nada más divertido que regañar a nuestros propios jefes; pero hacerlo con razones y motivos. El tener conocimiento de gobernanza nos amplía la visión y nos damos cuenta que muchos de los problemas no son técnicos sino de alta o media gerencia. Por lo que en ciertos momentos, podremos debatir y hasta indicar que lo que están presenciando es el síntoma y que el problema está arriba.
Recuerden que no se vale indicar un problema sino damos una solución.

Con éstos puntos cierro la importancia de ampliar nuestro panorama y conocimiento adentrándonos en temas de gestión y gobernanza.
En el siguiente post daré una introducción de qué es Cobit.

Cierre

¡Espero poder haber sido lo suficiente elocuente para transmitirles este tema tan importante!



Post Similares

TituloDescripciónCategoriaTecnologíasTipoFecha de publicación
Subversión y Jenkins: cómo comunicarse entre ellos Como poder indicarle a Jenkins iniciar una actividad cuando Subversion ha sido actualizado Integración continua Subversion, Jenkins Tip 17 de septiembre de 2012 
Jenkins & Sonar: Status en jenkins refleje alertas de sonar Cómo poder mostrar en Jenkins el status real dependiendo de las alertas de Sonar Integración continua Subversion, Jenkins Tip 29 de agosto de 2012 
Web Tiers: Explicación Explicación sobre el concepto "tiers" en proyectos web. Diseño Servlets Explicación 1 de septiembre de 2009 
Tipo de Pruebas para Desarrollo de Software Explicación sobre los diferentes tipos de pruebas que se pueden hacer en el desarrollo de software Calidad XUnit, Sonar, PMD, Findbugs, Thucydides, Checkstyle, Cobertura Explicación 11 de septiembre de 2012 
Integración Continua: Promociones y Líneas de Producción  Explicación del concepto de promociones y pipelines en Integración Continua Integración continua Jenkins y plugins Explicación 27 de septiembre de 2012 
Mostrando 5 elementos de la página Indice de posts ordenados por hora de edición. Ver más »


Aspectos? No entendía para que sirven

publicado a la‎(s)‎ 13 oct 2012, 10:44 por Eliu Montoya   [ actualizado el 13 oct 2012, 10:45 ]

Tema: Explicación de la Programación Orientada a Aspectos
Categoria: Explicación concreta / Conceptos de programación
Tecnologías / Componentes: AOP, Spring



Una de mis dudas de hace mucho tiempo y que por más que me explicaban, no entendía para qué y dónde se puede aplicar la programación orientada a aspectos (AOP). Y fué hasta que Mario Arias (@dh44t) me iluminó.

Asi que a continuacion trataré de explicarlo y ojala aquellos que tengan mi mismo problema puedan superarlo también.


Introducción

Para empezar la orientación a aspectos no sustituye (de cierta manera) a la orientada a objetos (OOP); pero tampoco podría nada que ver con ella, por lo que no tienen dependencia. La AOP es una manera que va encima y podría extender a OOP.
Para ser más claros AOP sirve para intercomunicar, convivir y administrar eventos que suceden entre las diferentes hileras (tiers), o como malamente se conocen como "capas" 

Capas

para saber mas y el porque de hileras y no capas ver mi post "Web Tiers: Explicación"


Pongamos un ejemplo:

Supongamos que al finalizar un desarrollo nos piden que todos los métodos validen si el usuario tiene roles de privilegios para ejecutar dicho método o que al iniciar y antes de salir de cada método registremos un log.
De ahi comienza a surgir la duda: ¿dónde codificamos esto? ¿Dentro de cada método? Y si es dentro de cada método, ¿tengo que repetir el mismo código en cada uno?
Así que de entrada algo no está bien y seguro implica que estamos violando algún patrón de diseño.

Patrón de responsabilidad simple

Una de las premicias de la programación orientada a objetos dicta que cada objeto y cada método, en particular, deben ejecutar únicamente su tarea principal.
Entonces, ¿por qué debo meter código de seguridad o de loggeo a un método que es específico en ejecutar una cierta actividad? ¿Debo violar esta buen práctica sólo por requerimientos?

Código repetido, esparcido y otros costos

¿Debemos pagar el precio de tener código repetido y esparcido en todas nuestras clases? Esto conllevaría a que estamos obligados a duplicar el código en cada método nuevo que codifiquemos. Lo que a su vez provocaría un hoyo de seguridad o de falta de loggeo en caso que se nos olvide; y si en algún momento cambian los requerimientos tendremos que cambiarlo en toda la aplicación.

Aspectos extiende a Objetos

Estas desventajas, entre muchas otras más, surgen en requerimientos que implican intrusión en la responsabilidad de los métodos; y es para estos casos que AOP ayuda a solventar está problemática: pero con objetos.

Solución

Podemos crear una clase asignada para Aspectos, que cada método es el código que debemos ejecutar para la seguridad o el loggeo.
Luego tenemos que usar un contexto de aplicación donde le indicamos que aplique dicho código antes o después de ejecutar ciertos métodos (asignamos filtros).
De esta manera el contexto se encargará de estar pendiente de la ejecución de los métodos que cumplen nuestro filtro y ejecutará en el momento indicado el código que tenemos bien definido en nuestra clase de Aspectos.

Aspectos

Esto es programación orientada a aspectos.


De esta manera no violamos la premicia de responsabilidad simple de cada método, tenemos nuestro codigo de seguridad y loggeo dentro de clases y métodos y tampoco cargamos con los costos antes mencionados: si cambian los requerimientos modificamos los metodos de la clase Aspectos. Si eliminan el requerimiento o lo limitan a ciertos métodos únicamente, modificamos el filtro que le dimos al contexto.

Características de AOP

Así como la OOP tiene sus 3 características que nos enseñan desde la escuela:
  • Herencia,
  • Encapsulamiento
  • y polimorfismo.
La Aop tiene las siguientes:
  • Punto de unión (join point): Es el punto definido en el código donde entrará el aspecto.
  • Punto de corte (point cut): Es la expresión que describe uno o varios puntos de uniones (los filtros)
  • Consejo (advice): Es el código que va a ser ejecutado en un cierto punto de corte
  • Aspecto (aspect): Es el encapsulamenteo de un PointCut y un Advice.

Tipo de aspectos

Ya entendiendo los aspectos tenemos que saber qué tipos de aspectos hay :
  • Antes (@Before). Estas definiciones se ejecutan antes de iniciar el método
  • Después (@After). Estos se ejecutan después de haber sido invocado el método pero antes de regresar su valor. Por lo que en esta definición podemos alterar y manipular el valor retornado. En Spring existen dos variaciones
    • @AfterReturning
    • @AfterThrowing
  • Alrededor (@Around). Este es el más completo y poderoso ya que se ejecuta antes de ser invocado el método y nosotros tenemos que invocarlo explícitamente; por lo que, tambien podemos obtener y manipular el valor de regreso o ejecutar o no el método.

Tipos

Asi que dependiendo de nuestro requerimiento podemos utilizar cualquiera de estos tres.

Con gran poder viene gran responsabilidad

Hemos visto el alcance que la AOP  tiene y el poder de manipular los datos de entrada y de salida de los métodos y hasta podemos permitir o no la ejecución del método; o cosas mas extrañas como evitar que el método se ejecute y en su lugar invocar código nuestro y para el usuario del método será totalmente transparente.
En general podemos alterar el comportamiento de la aplicación.

Esto es excelente si tenemos código legado sin los fuentes para modificar, sin embargo también puede llevar a hoyos de seguridad o mal intencionados.

Responsabilidad

Así que úselo con precaucion y ética


Consideraciones

Obviamente no podemos manipular código que no esté siendo controlado por el contexto. Lo que significa que en el caso de Spring, los objetos deben ser tratados como beans. Es por eso que no podemos alterar tipos como String o de otras aplicaciones a menos que los definamos dentro del contesto de Spring.

Patrón Proxy

Quiero hacer un paréntesis para hacer una introducción al patron proxy (para más información ver wikipedia o el siguiente blog de patronesDeDiseño.)

A grandes rasgos este patrón soluciona el problema de controlar la invocación o acceso a un objeto y sus métodos.
Proxy en español significa "representante" por lo que un usuario de una clase hace peticiones a su representante y no al objeto específico. Por lo que el proxy puede hacer cierta lógica antes o después de llamar al método respectivo.

En UML se ve de la siguiente manera:


Para empezar debemos tener:
  • una interfaz. 
  • Después creamos la clase normal implementando a dicha interfaz.
  • Por otro lado, creamos otra clase proxy que implementa la misma interfaz y además tiene un atributo privado del tipo de la interfaz.
Por lo tanto el objeto proxy es (IS-A) y tiene (HAS-A) un tipo de esa interfaz.

Como se hace AOP en Spring

En el caso de Spring se hace mediante el patrón Proxy. Asi que en el momento de crear los objetos beans y hacer la inyección de dependencias, en lugar de insertar el objeto como referencia en otros beans realmente está insertando la referencia al proxy y a éste le inserta el objeto target (el objeto de nuestra implementación).
De esta manera, los aspectos que programamos serán la logica que se encuentra en el método Avanzar del Proxy y que ejecutará  antes o después de ejecutará  el método del objeto target que tiene en su atributo privado.

Usos comunes

Los usos comunes para utilizar aspectos son:
  • Seguridad. Validar algo antes de ejecutar un método.
  • Logs. Mostrar logs o auditoría
  • Popular repositorios. Al iniciar una aplicación ejecutar algo, por ejemplo popular una base de datos o auto instalarse y configurarse.

Resumen

Como hemos visto la programación orientada a aspectos complementa a la orientada a objetos pudiendo incrementar lógica a eventos o situaciones que pasan a lo largo de las hileras y que trasciende a la responsabilidad especifica de las clases.
Podemos diseñar aplicaciones totalmente basadas en AOP pero tenemos que tener cuidado en no alterar el comportamiento o los objetos. Para esto es recomendable tener pruebas de aceptación automatizadas.
Pero en general es un paradigma altamente útil que ya podemos utilizar en nuestros proyectos ya sea completa o parcialmente.




Post Similares

TituloDescripciónCategoriaTecnologíasTipoFecha de publicación
Subversión y Jenkins: cómo comunicarse entre ellos Como poder indicarle a Jenkins iniciar una actividad cuando Subversion ha sido actualizado Integración continua Subversion, Jenkins Tip 17 de septiembre de 2012 
Jenkins & Sonar: Status en jenkins refleje alertas de sonar Cómo poder mostrar en Jenkins el status real dependiendo de las alertas de Sonar Integración continua Subversion, Jenkins Tip 29 de agosto de 2012 
Web Tiers: Explicación Explicación sobre el concepto "tiers" en proyectos web. Diseño Servlets Explicación 1 de septiembre de 2009 
Tipo de Pruebas para Desarrollo de Software Explicación sobre los diferentes tipos de pruebas que se pueden hacer en el desarrollo de software Calidad XUnit, Sonar, PMD, Findbugs, Thucydides, Checkstyle, Cobertura Explicación 11 de septiembre de 2012 
Integración Continua: Promociones y Líneas de Producción  Explicación del concepto de promociones y pipelines en Integración Continua Integración continua Jenkins y plugins Explicación 27 de septiembre de 2012 
Mostrando 5 elementos de la página Indice de posts ordenados por hora de edición. Ver más »

Configuración Maven POM para reportes en el Sitio de Documentación

publicado a la‎(s)‎ 6 oct 2012, 8:55 por Eliu Montoya   [ actualizado el 6 oct 2012, 8:56 ]

Tema: Mostrar las configuraciones básicas y específicas que se requieren en Maven para mostrar un sitio de documentación completo.
Categoria: Tip / Programación
Tecnologías / Componentes: Maven


Introducción

Una de las ventajas de Maven es poder crear un sitio de documentación ("site" en inglés) lo más fácil y rápido posible. 
Esto se realiza en la fase "site" y se puede ejecutar con el comando:

mvn site:site

Además, dentro del archivo de configuración (pom.xml) podemos personalizar este sitio.
El sitio original contiene información básica del proyecto, el cual obtiene de los datos básicos de configuración del POM y de dependencias, etc.



En este artículo pondré las configuraciones necesarias para agregar una sección extra de Reportes, tales como: 
  • Documentación javadoc
  • Resultados de Cobertura
  • Resultados de análisis estático de código
  • y demás herramientas que son útiles.
Por lo que el sitio de documentación se verá de la siguiente manera:



Todas estas configuraciones son dentro del POM

Configuración de datos básicos

Antes de personalizar el "sitio", debemos asegurarnos que los datos básicos del POM han sido llenados correctamente. Estos datos son necesarios por 2 razones: Principalmente porque proveen información importante en el sitio, información que puede ser usada en varias secciones y/o sistemas con sólo haber llenado estos campos; además que también sirven para ciertas actividades en específico. 
Por ejemplo, la sección <distributionManagement> provee información en la documentación en el sitio y además se requiere para poner los artefactos finales (war, jar, pom, etc) en el repositorio institucional como Nexus.

Por lo tanto las configuraciones básicas y necesarias son:

Datos básicos del proyecto:

Además del groupId, parent, etc, es necesario que mencionemos la 
  • descripción: Info básica de qué hace el proyecto
  • y la url del proyecto: La liga del sitio del proyecto: También puede apuntar a la url donde se expondrá esta documentación del site en internet o en la intranet de la empresa.
<description>Descripción de qué hace el proyecto.</description>

<url>http://URL_SITE/MI_PROYECTO</url>

Datos Institucionales

<organization>
<name>MI EMPRESA</name>
<url>http://URL_EMPRESA</url>
</organization>

Datos del Controlador de Código / Versiones (SCM)

Aquí especificamos la ruta donde se guarda el código fuente en el repositorio SCM. Se comprende de 3 secciones:
  • Connection: Esta liga se usa al hacer el release, ya que el plugin Maven-Release hace checkout de esta liga para después realizar el TAG liberado
  • DeveloperConnection: Esta es la liga que en la documentación especifica al desarrollador de donde puede bajar el código. Por lo regular es la misma que Connection.
  • Url: Es la liga del repositorio en general, donde se encuentra el código. Por lo regular, apunta a la raiz del proyecto y NO a un tag, branch o trunk en específico.

El formato para Connection comprende de 3 partes separadas por ":":
  • "scm": es una constante.
  • Tipo de repositorio: Puede ser "svn" para subversion, "cvs" o "git"
  • Url: Puede ser al trunk o alguna rama

<scm>
<connection>scm:svn:http://MI_SERVER/svn/MI_PROYECTO/trunk/</connection>
<developerConnection>http://MI_SERVER/svn/MI_PROYECTO/trunk/</developerConnection>
<url>http://MI_SERVER/svn/MI_PROYECTO</url>
</scm>

Datos de Integración Continua

Aquí especificamos los datos del servidor de integración continua y cuál usamos (Jenkins, Bamboo, etc..)

<ciManagement>
<url>http://MI_SERVER/jenkins/</url>
<system>jenkins</system>
</ciManagement>


Datos de Sistema de Distribucion

En esta sección se especifíca los datos del repositorio de artefactos institucionales como Nexus o Artefactory
Además, se especifica dónde se publicará el sitio. Esta información la requiere en Plugin que publica o copia a un servidor remoto, el cual se especifica más adelante.

<distributionManagement>

<site>

<id>site.deployments</id>
<name>Titulo de Documentacion</name>
<url>Liga a la documentacion (http) o a donde se copiara (scp,etc)</url>
</site>

<downloadUrl> http://URL_PARA_OBTENER_CODIGO_O_ARTEFACTO/</downloadUrl>

<repository>
<id>nexus</id>
<name>Nexus Releases</name>
<url>http://MI_REPO/nexus/content/repositories/MI_REPO_RELEASES/</url>
</repository>

<snapshotRepository>
<id>nexus</id>
<name>Nexus Snapshots</name>
<url>http://MI_REPO/nexus/content/repositories/MI_REPO_SNAPSHOTS/</url>
</snapshotRepository>

</distributionManagement>


Configuraciones para el sitio de documentación

Las siguientes configuraciones son para agregar más categorías a la sección de Reportes en la documentación para que se vea de la siguiente manera:

Por lo tanto, las siguientes configuraciones deberán ir dentro de la sección <reporting>, como se muestra a continuación:


<reporting>
<plugins>
...
</plugins>

</reporting>

En Maven 3.x se especifican en la sección <build> y dentro de cada plugin, sin embargo, en lo particular me gusta más tener todas las configuraciones concentradas dentro de una misma sección; así que apesar que esta configuración es de la especificación de Maven 2.x aún sigue siendo compatible con Maven 3.x

La mayoría de estos reportes son de pruebas y análisis estáticos de código; para mayor información sobre tipo de pruebas se pueden ver el post: Tipo de Pruebas para Desarrollo de Software

JavaDoc con gŕaficos UML

Este reporte obtendrá los comentarios del código y realizará la documentación de JavaDocs, además utilizaremos un plugin de UmlGraphDoc el cual incluirá en cada clase un diagrama UML en caso que conviva con otras clases o interfaces.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.8</version>
<configuration>
<doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
<docletArtifact>
<groupId>org.umlgraph</groupId>
<artifactId>doclet</artifactId>
<version>5.1</version>
</docletArtifact>
<additionalparam>-views</additionalparam>
<useStandardDocletOptions>true</useStandardDocletOptions>
</configuration>
</plugin>

Reportes de Cobertura

Estos reportes son los de cobertura de las pruebas unitarias

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<formats>
<format>html</format>
<format>xml</format>
</formats>
</configuration>
</plugin>

Reporte de TODOs Pendientes

Este reporte enlista los Tags @TODO que se encuentran en el código. Por lo que se tienen que tener presentes, ya que un sistema con muchos tags @TODOS implica que aun tiene pendiente de implementación de código.

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>taglist-maven-plugin</artifactId>
<version>2.4</version>
</plugin>


Reporte de Historial de Cambios en el SCM (Repositorio)

Este reporte enlista los cambios que se han realizado en el repositorio de versiones al momento de hacer "commits".

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-changelog-plugin</artifactId>
<version>2.2</version>
</plugin> 

Reportes de Pruebas Unitarias con JUnit

Reporte que especifica el status de las pruebas unitarias

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-report-plugin</artifactId>
<version>2.9</version>
</plugin>


Referencias de Pruebas Unitarias al Código

Reporte de pruebas unitarias, pero se puede ir haciendo clicks y hace referencia al código

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jxr-plugin</artifactId>
<version>2.3</version>
</plugin>

Reporte de FindBugs


<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<threshold>Low</threshold><!-- High|Normal|Low|Exp|Ignore -->
<effort>Default</effort><!-- Min|Default|Max -->
</configuration>
</plugin>

Reporte de Checkstyle


<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.9.1</version>
<configuration>
<configLocation>config/sun_checks.xml</configLocation>
</configuration>
</plugin>

Reporte de PMD

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>2.5</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>javancss-maven-plugin</artifactId>
<version>2.0-beta-2</version>
</plugin>

Liga a Análisis en Sonar

En caso que el proyecto haya pasado por análisis en Sonar, esta sección será una liga autoredirigida al proyecto en Sonar.

<plugin>
<groupId>org.codehaus.sonar-plugins</groupId>
<artifactId>maven-report</artifactId>
<version>0.1</version>
</plugin>


Pruebas de Aceptación de Usuario con Thucydides

Este reporte redirige al reporte que Thucydides arrojó al hacer las pruebas de aceptación de usuario

<plugin>
<groupId>net.thucydides.maven.plugins</groupId>
<artifactId>maven-thucydides-plugin</artifactId>
<version>${thucydides.version}</version>
</plugin>


Configuración para publicar el sitio en un servidor remoto


Existe un plugin (org.apache.maven.wagon) que nos puede ayudar a publicar nuestro sitio de documentación en un servidor remoto. Esto lo puede hacer mediante ftp, scp o webdav. 

Una vez que ya está configurado se puede ejecutar con los comandos:

mvn site:site site:deploy


Nota

site:deploy requiere que el sitio ya esté generado (con site:site).
Sin embargo, se puede hacer en un solo paso con el comando
mvn site-deploy



A continuación un ejemplo con scp.

Configuración del plugin

Esta configuración va en la sección <build>.

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>3.1</version>
<dependencies>
<!-- add support for ssh/scp -->
<dependency>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ssh</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</plugin>
...
</plugins>
</build>


Configuración de credenciales del servidor


Hay que agregar la configuración de credenciales al servidor en el archivo settings.xml de Maven, en la sección <servers>.

<server>
<id>site.deployments</id>
<username>MI_USERNAME</username>
<password>MI_CONTRASEÑA</password>
 <privateKey>/path/to/private/key</privateKey>
</server>


Credenciales

En caso que se use una llave privada para ingresar y NO la contraseña, DEBERÁ omitirse el tag <password>, en caso contrario, no tomará la llave privada.

Resumen

Es importante tener una documentación del proyecto, y mejor aún si está en un sitio concentrado.

El poder realizar un sitio de una manera fácil, sencilla y automatizada es parte de la filosofía de Integración Continua y en específico como Continuous Documentation. La ventaja que podemos utilizar es poniendo esta actividad como un "JOB" más en el "Pipeline" de nuestro servidor de Integración Continua..

Nota

Hay que tener en mente que al momento de hacer el release de nuestro proyecto, esta fase de generación del sitio "site:site" viene ímplicito, por lo que si el pipeline contiene una actividad de release, este JOB lo podemos ahorrar, ya que se ejecutará en automático


Post Similares

TituloDescripciónCategoriaTecnologíasTipoFecha de publicación
Subversión y Jenkins: cómo comunicarse entre ellos Como poder indicarle a Jenkins iniciar una actividad cuando Subversion ha sido actualizado Integración continua Subversion, Jenkins Tip 17 de septiembre de 2012 
Jenkins & Sonar: Status en jenkins refleje alertas de sonar Cómo poder mostrar en Jenkins el status real dependiendo de las alertas de Sonar Integración continua Subversion, Jenkins Tip 29 de agosto de 2012 
Web Tiers: Explicación Explicación sobre el concepto "tiers" en proyectos web. Diseño Servlets Explicación 1 de septiembre de 2009 
Tipo de Pruebas para Desarrollo de Software Explicación sobre los diferentes tipos de pruebas que se pueden hacer en el desarrollo de software Calidad XUnit, Sonar, PMD, Findbugs, Thucydides, Checkstyle, Cobertura Explicación 11 de septiembre de 2012 
Integración Continua: Promociones y Líneas de Producción  Explicación del concepto de promociones y pipelines en Integración Continua Integración continua Jenkins y plugins Explicación 27 de septiembre de 2012 
Mostrando 5 elementos de la página Indice de posts ordenados por hora de edición. Ver más »

Integración Continua: Promociones y Líneas de Producción

publicado a la‎(s)‎ 27 sept 2012, 15:05 por Eliu Montoya

Tema: Explicación del concepto de promociones y pipelines en Integración Continua
Categoria: Explicación concreta / Integración continua
Tecnologías / Componentes: Jenkins y plugins


Una de las tantas ventajas de tener un servidor de integración continua es poder tratar cada versión de un proyecto como una línea de producción, conocido en inglés como Pipeline.
Una linea de producción es realmente un conjunto de actividades automatizadas y ejecutadas en serie. Estas actividades pueden ser
  • Compilación y comprobación de pruebas unitarias.
  • Colocación del artefacto compilado en un repositorio de Snapshots.
  • Pruebas de control de calidad en el código, por ejemplo con los analizadores estaticos como findbug pmd, etc o con Sonar.
  • Ejecución de pruebas de funcionalidad o de aceptación de usuarios.
  • Desplegar la aplicación en un ambiente de pruebas.
  • Ejecución de un tipo de pruebas tipo Smoke test o de integración para validar que el despliegue fue satisfactorio y configurado correctamente. 
  • Ejecución de pruebas de estré, por ejemplo con Jmeter
  • Liberación del código y su etiquetación como "Productivo"  y con un número de versión final.
  • Colocar el artefacto o compilado final en un repositorio de artefactos liberados como Nexus.
  • Despliegue del artefacto liberado en el ambiente productivo.
  • Ejecución de unas pruebas finales para validar que el despliegue fue satisfactorio.
  • Generación de la documentación final y su despliegue en un servidor web o de documentos.

Estas actividades son un ejemplo de lo que se puede hacer en una línea de producción, la cual puede contener todas o más actividades.



En general se puede decir que una linea de producción realiza 4 grandes pasos:
1. Construcción . Esto incluye compilacion y pruebas unitarias y de análisis de código
2. Aceptación de usuario.  Implica pruebas automatizadas de aceptación y estress asi como validación manual del usuario.
3. Despliegue.  Incluyendo sus respectivas pruebas de validación en tantos ambientes se requiera.
4. Liberación.  Implica liberar el código, artefactos finales y documentación. 

Promociones

Existe un concepto llamado Promoción (promotion) que es el paso intermedio entre cada una de estas actividades. Al terminar cada actividad satisfactoriamente se puede marcar esa versión como lista para ser promovida para que le sea aplicada la siguiente actividad.  

Por lo tanto, Pipeline es el proceso general y Promotion es la marca de que una versión es elegida para poder pasar a la siguiente actividad.

Pipeline

Por lo tanto, Pipeline es el proceso general y Promotion es la marca de que una versión es elegida para poder pasar a la siguiente actividad.


Es importante notar que cada pipeline debe ser aplicada sobre una  misma versión por lo que hay que contemplar una manera de que la primera actividad al terminar satisfactoriamente guarde el código fuente y su compilado para pasarselos a la segunda actividad ; esta deberá ejecutarse sobre esta copia y pasársela a la siguiente actividad y asi sucesivamente. De esa manera podemos garantizar que la versión que se puso en producción con la última actividad es la misma que empezó todo el proceso y pasó por cada una de las pruebas, sin importar si en medio de la ejecucuion de la linea de producción comenzó otra vez la primera actividad con una versión diferente.

Importante

Cada modificación el código original deberá pasar por toda la linea de producción. 




La pregunta puede ser ahora: y cómo comienza la primera actividad de la linea de producción?
General y recomendablemente la primera actividad deberá iniciar automáticamente cuando el repositorio o controlador de versiones, como subversion o git, fue actualizado. Por lo tanto, la única actividad que deberá estar escuchando y ser inicializada por el SCM (source control manager) deberá ser la primera y las consecutivas deberan ser inicializadas o automáticamente por su antecesora o manualmente por un usuario pero únicamente cuando ya ha sido promovida para esa actividad.



Para saber como inicializar una actividad de Jenkins cuando se esta usando Subversion puede verse en el artículo "Subversión y Jenkins: cómo comunicarse entre ellos"


Plugins en Jenkins 

Dentro de Jenkins podemos utilizar varios plugins:

Copy Artifact Plugin

Este plugin sirve para poder guardar una copia y pasárselo a la siguiente actividad. Por lo tanto, tiene dos facetas: una para ser ejecutada como Post-build donde le indicamos qué es lo que se quiere guardar; y otra para ser ejecutada como Pre-build donde le indicamos qué queremos obtener, de qué actividad y de cual versión; es decir, para obtener una copia guardada podemos seleccionar si queremos de la actividad antecesora e inicializadora para asegurar tener la versión indicada o poder obtener la ultima versión satisfactoria.  Etc

La configuracion para la primera faceta es la siguiente:




Para la segunda faceta deberemos de configurara la siguiente pantalla en la actividad predecesora:



Promotion Build Plugin

Este plugin sirve para hacer y marcar visualmente las promociones y nos da la ventaja que cada versión la va marcando con estrellas de diferentes colores por lo que en una vista general podemos ver todas las versiones compiladas y su nivel de promoción a la que llegó.  Al hacerle click a cada versión nos mostrará el detalle indicando el número de job único de cada actividad.
este plugin tiene que ser configurada en dos partes.

Dentro de cada actividad deberemos configurar una tarea Post-build que inicialize otra actividad. De esta manera estaremos haciendo la ejecución seriedada de las actividades.



También en la primera actividad deberemos configuara el plugin de Promotion donde indicamos las estrellas y el color que deseamos en la finalizacion de cada actividad predecesora.




De esta manera se podrá ver cada versión y su status de promoción con estrellas.


Build Pipeline Plugin 

Este plugin funciona de una manera diferente ya que las actividades tienen que estar serializadas (como en el primer paso del plugin anterior) pero deberemos crear una vista nueva llamada pipeline view la cual fue instalada con el plugin. Al crear esta vista deberemos indicar cual es la primera actividad y detectara las predecesoras. Esta vista mostrara en una tabla el avance y estatus de cada linea de producción, donde cada renglon es una versión diferente y las columnas son cada una de las.actividades del pipeline. Cada actividad que ha sido ejecutada satisfactoriamente se pintara de color verde, las fallidas en rojo. 



Además, en caso que una actividad requiera de una aprobación manual o ser inicializada por una persona, en está vista aparecerá un botón para comenzar la actividad. 

M2 Release Plugin.

Este plugin nos facilita la liberación del código en el repositorio SCM y etiquetarlos con un número final de versión.  Así como liberar los artefactos finales en un repositorio de producción como Nexus.
Es importante mencionar que este plugin funciona únicamente para proyectos Maven, y requiere las configuraciones pertinentes en el POM. Por lo tanto este plugin es una interfaz amigable de Jenkins para ejecutar los comandos
mvn release:prepare release:perform


Cargo plugin 

Este plugin nos sirve para desplegar artefactos web (war) en servidores web o de aplicaciones como Tomcat, Jboss, Websphere, etc.
Igualmente que el plugin anterior, este es una interfaz de Jenkins para el respectivo plugin de Maven, por lo que, únicamente funciona para proyectos de este tipo.


Beneficios 

Los principales beneficios para contar con una infraestructura y una técnica así son:
  • La confianza de todos los afectados (stakeholders) aumenta, ya que existe una manera de probar cada paso y tener evidencia de que no ha existido algún error que cause regresión. 
  • La participación de cada stakeholder se hace notar dentro del proceso completo.
  • optimización de tiempo y aumento de calidad, ya que cada actividad es automatizada y repetible disminuyendo error humano.
  • La valorizacion del equipo personal y profesionalmente incrementa ya que dejan tareas repetitivas y se enfocan a otras con mucho mas valor.
  • El tiempo de respuesta entre el equipo y el estatus de los proyectos es mínima.  Entre mas rápido el equipo sepa que una versión rompió alguna prueba o algún otro pipeline de otro proyecto dependiente, mayor será el tiempo de respuesta para corregirlo.


Recomendaciones para comenzar

1. Comienza con algo, después irlo creciendo.
Es importante tener un pipeline lo mas robusto y que abarque lo mas posible, sin embargo siempre se empieza con una actividad. Por lo tanto, primero comienzen con la actividad de compilación y pruebas unitarias y que esté integrado con el repositorio SCM. Una vez que se tenga dominada la activdad, sus resultados, su respectivo análisis y que el equipo esté acostumbrado a la herramienta pueden implementar otra actividad y no avanzar hasta que esta esté igualmente dominado.

2. Deja las pruebas rápidas al inicio.

Debido a que es primordial el tiempo de respuesta al equipo, es importante que las actividades mas vitales estén al inicio y su ejecución sea la mas rapido posible.; por lo que las pruebas mas pesadas deberán dejarse para tiempos que no impacten en el tiempo de espera del equipo.

3.  Hacer los commits al SCM lo mas frecuente posible.

Muchos programadores no estan acostumbrados a ingresar sus cambios al repositorio de código o lo hacen una vez que ya terminaron el desarrollo.  Sin embargo esto no es una buena práctica.  Entre mas frecuentes sean los commits implicará que contiene muy pocas modificaciones por lo que si existe un error y el cambio rompió alguna dependencia será mas fácil encontrar el problema. En cambio, si el commit conlleva muchos cambios, será mucho mas difícil saber cual de todas las nuevas funcionalidades fue la del problema.

4. Siempre estar pendiente del pipeline y estatus de cada versión.
Debemos desarrollar un hábito para ver y analizar cada pipeline y proyecto.  En caso que alguna activdad no la estemos analizando o pensemos que no aporta información es mejor eliminarla, ya que implica que dicha actividad no nos es util actualmente.

5. Nunca subir algún cambio si no se ha probado localmente.  

No por subir cambios lo mas frecuente posible implica no probarlo localmente y estar seguros que al menos la compilación y pruebas unitarias son satisfactorias.

6. Nunca dejar los pipelines rotos o con errores.

Es una muy mala práctica subir los cambios e irnos y en caso que algo se rompa dejarlo para mañana.  
Debemos acoatumbrar al equipo a mantener siempre en verde ya que si en algun momento empezamos a dejar actividades en rojo la gente se va acostumbrado y poco a poco mas actividades irán dejándose en rojo también

7. Ningún proyecto es pequeño para incluirlo.

Es un error pensar que las lineas de producción y la integración continua per-se, es para proyectos o empresas grandes. Recordemos que cada actividad es repetible, automatizada y deja resultados, por lo que inclusive en proyectos chicos después de abandonarlos un tiempo cuesta trabajo retomarlos, saber el estatus en el que se dejó, recordar su funcionalidad original etc. Por lo que sería facil recurrir a la ejecución de la línea de producción para recordar y retomarlo rápidamente

Recordar

Hay que recordar que mejora continua es un proceso de madurez y no un cambio radical e impositivo. Y un proceso de madurez implica ciertos cambios lentos pero siempre constantes con la adopción de hábitos y costumbres.


Así que,  al implementar una infraestructura de pipelines es importante comunicar al equipo hacia donde se pretende ir y darles a conocer la importancia de su compromiso diario que eventualmente se hará hábito; de cualquier manera, esas buenas costumbres se quedarán arraigados en su propia formación y madurarán también junto con el proyecto. 

¡Así que ánimo y los invito a ir implementando este método de trabajo!


Post Similares

TituloDescripciónCategoriaTecnologíasTipoFecha de publicación
Subversión y Jenkins: cómo comunicarse entre ellos Como poder indicarle a Jenkins iniciar una actividad cuando Subversion ha sido actualizado Integración continua Subversion, Jenkins Tip 17 de septiembre de 2012 
Jenkins & Sonar: Status en jenkins refleje alertas de sonar Cómo poder mostrar en Jenkins el status real dependiendo de las alertas de Sonar Integración continua Subversion, Jenkins Tip 29 de agosto de 2012 
Web Tiers: Explicación Explicación sobre el concepto "tiers" en proyectos web. Diseño Servlets Explicación 1 de septiembre de 2009 
Tipo de Pruebas para Desarrollo de Software Explicación sobre los diferentes tipos de pruebas que se pueden hacer en el desarrollo de software Calidad XUnit, Sonar, PMD, Findbugs, Thucydides, Checkstyle, Cobertura Explicación 11 de septiembre de 2012 
Integración Continua: Promociones y Líneas de Producción  Explicación del concepto de promociones y pipelines en Integración Continua Integración continua Jenkins y plugins Explicación 27 de septiembre de 2012 
Mostrando 5 elementos de la página Indice de posts ordenados por hora de edición. Ver más »

Subversión y Jenkins: cómo comunicarse entre ellos

publicado a la‎(s)‎ 17 sept 2012, 10:34 por Eliu Montoya   [ actualizado el 20 sept 2012, 21:40 ]

Tema: Como poder indicarle a Jenkins iniciar una actividad cuando Subversion ha sido actualizado
Categoria: Tip // Integración Continua
Tecnologías / Componentes: Subversion, Jenkins.


Siguiendo con el tema de integración continua en este tip explicaré como poder hacer la comunicación entre Subversion y Jenkins.

Principalmente existen dos maneras para que al momento de hacer un" commit" a subversion Jenkins pueda iniciar un JOB (actividad) que esté ligado a ese repositorio:

Jenkins como inicializador

El primero es el más nativo y es por medio de que Jenkins escaneará cada determinado tiempo si hubo algún cambio en el repositorio. Esto lo hacemos indicándole a Jenkins cuál es el repositorio donde obtendrá el código fuente y el tiempo que realizará cada inspección de cambio.

Una de las desventajas de este método es la carga constante que se está realizando, tanto del lado de Jenkins como de Subversion. Además, existe una latencia entre el momento que se subieron los cambios y el que le toma a Jenkins realizar la inspección.  

Subversion como inicializador

El otro método es mucho más dinámico en tiempo real y eliminando la carga constante. Esto se logra mediante la instrucción que Subversion le da a Jenkins en el momento que algún repositorio sufrió una actualización.
Por lo tanto, en lugar que la comunicación sea desde Jenkins hacia Subversion preguntando si hubo modificación por cada repositorio configurado, en este método es desde Subversion hacia Jenkins dando la instrucción de que cierto repositorio sufrió una actualización para que Jenkins busque los JOBS que estén asociados para ejecutarlos. De esta manera se logra la sincronización en tiempo real.

Para lograr ésto, hay que configurar un POST-HOOK en cada repositorio de subversion, ademas de la configuración básica en jenkins donde se indica el repositorio y habilitando la casilla de "Poll SCM" para habilitar que Subversion sea el inicializador de ese JOB.

El hook lo que hace a grandes rasgos es explotar la funcionalidad que ofrece jenkins de buscar jobs asignados a cierto repositorio asi como su ejecución remota. Esta funcionalidad es mediante peticiones POST que ya Jenkins expone de fábrica.  Asi que el hook es un llamado de CURL o WGET a esta funcionalidad. 

De esta manera podemos eficientar la comunicación entre Subversion y Jenkins para la ejecución de trabajos al momento de actualizar un repositorio.

Este HOOK es el siguiente:


----- Inicia código

#!/bin/sh
JENKINS_SERVER={URL_SERVIDOR_JENKINS}
REPOS="$1"
REV="$2"
UUID=`svnlook uuid $REPOS`
/usr/bin/wget --header "Content-Type:text/plain;charset=UTF-8" --post-data "`svn
look changed --revision $REV $REPOS`" --output-document "-" --timeout=2 $JENKINS
_SERVER/subversion/${UUID}/notifyCommit?rev=$REV

----- Fin de código

Se deberá cambiar {URL_SERVIDOR_JENKINS} por la dirección real del servido rde Jenkins. Ejemplo: http://servidorjenkins.com/

Este código deberá salvarse en un archivo llamado post-commit
y guardarse dentro la carpeta hooks/ que se encuentra en la carpeta del proyecto en los repositorios de Subversion.
Ejemplo:
/var/svn/MiProyecto/hooks/post-commit

Al ejecutar este script, Jenkins buscará JOBS que estén asociados a este proyecto (Mediante el Repository URL en la configuración del proyecto) y comenzará su ejecución (hay que seleccionar la casilla "Poll SCM" dentro de la configuración del proyecto en Jenkins)


Post Recientes

TituloDescripciónCategoriaTecnologíasTipoFecha de publicación
Subversión y Jenkins: cómo comunicarse entre ellos Como poder indicarle a Jenkins iniciar una actividad cuando Subversion ha sido actualizado Integración continua Subversion, Jenkins Tip 17 de septiembre de 2012 
Jenkins & Sonar: Status en jenkins refleje alertas de sonar Cómo poder mostrar en Jenkins el status real dependiendo de las alertas de Sonar Integración continua Subversion, Jenkins Tip 29 de agosto de 2012 
Web Tiers: Explicación Explicación sobre el concepto "tiers" en proyectos web. Diseño Servlets Explicación 1 de septiembre de 2009 
Tipo de Pruebas para Desarrollo de Software Explicación sobre los diferentes tipos de pruebas que se pueden hacer en el desarrollo de software Calidad XUnit, Sonar, PMD, Findbugs, Thucydides, Checkstyle, Cobertura Explicación 11 de septiembre de 2012 
Integración Continua: Promociones y Líneas de Producción  Explicación del concepto de promociones y pipelines en Integración Continua Integración continua Jenkins y plugins Explicación 27 de septiembre de 2012 
Mostrando 5 elementos de la página Indice de posts ordenados por hora de edición. Ver más »

Tipo de Pruebas para Desarrollo de Software

publicado a la‎(s)‎ 11 sept 2012, 9:43 por Eliu Montoya   [ actualizado el 20 sept 2012, 21:45 ]

Tema: Explicación sobre los diferentes tipos de pruebas que se pueden hacer en el desarrollo de software.
Categoría: Explicación concreta / Calidad - Integración Continua
Tecnologías / Componentes: XUnit, Sonar, PMD, Findbugs, Thucydides, Checkstyle, Cobertura
En este artículo daré una explicación concreta del tipo de pruebas que podemos utilizar dentro del mismo concepto de Integración Contínua, aunque abarcaré un artículo específico para detallar cada uno.

Introducción

Dentro del proceso de Integración Contínua podemos ir agregando actividades automatizadas que prueben el funcionamiento, calidad, tiempo de respuesta de un sistema en desarrollo:
  • Pruebas Unitarias,
  • Pruebas de Aceptación de Usuario
  • Pruebas de Regresión
  • Pruebas Funcionales
  • Pruebas de Integración.
  • Pruebas de Estress
  • Pruebas de Calidad de Código
    • Cobertura
    • Análisis en Líneas de Código
    • Complejidad
    • Diseño de clases
    • Violaciones generales de desarrollo
    • Sonar



Pruebas Unitarias


Las pruebas unitarias tienen ese nombre debido a que se prueba la funcionalidad de cada método o función; únicamente contemplando la lógica que debe realizar y excluyendo la convivencia con otras clases o sistemas. Esto conlleva a que si este método utiliza funciones de otros métodos tenemos que ingeniárnosla para que esta lógica no afecte nuestro método que estamos probando.

Por ejemplo, supongamos que tenemos una Asistente de un doctor con la siguiente funcionalidad:
  • Recibir el seguro social de un paciente.
  • Después utiliza a un Bodeguero para que éste busque su respectivo expediente.
  • Una vez que ya tiene el expediente tiene que buscar una sección en específico y extraer el nombre de una medicina.
  • Ese nombre entregárselo al paciente.
Esa lógica que realiza la Asistente es la que tenemos que probar unitarimente pero se tiene que contemplar que existe una dependencia entre el proceso de obtención del nombre de la medicina con el dato ingresado (seguro social) y del contenido del expediente (el cual fue entregado por un tercero).
Por lo tanto, para realizar las respectivas pruebas tendremos que controlar el dato ingresado y también el contenido del expediente.  De esta manera si nosotros sabemos y podemos controlar estas variables podremos saber con certeza el valor de salida (en este caso el nombre de la medicina)   
Así que, lo que tenemos que hacer es desarrollar un Bodeguero para pruebas el cual regresará siempre el mismo expediente que nosotros conocemos. Este tipo de Bodeguero para pruebas también se le conoce como mock,  stub, dummy, etcétera.  En otro artículo escribiré las diferencias.
Por lo pronto, y regresando al tema hay que notar que se deben desarrollar dos implementaciones del mismo Bodeguero. Uno que realiza la logica real que se usará en producción y otro que servirá para controlar los datos que regresa utilizado únicamente en pruebas.
Por ende,  nosotros al programar la lógica de la Asistente tenemos que programar sus respectivas pruebas unitarias indicándole que utilize la implementación de Bodeguero de pruebas; y al mismo tiempo tendremos que desarrollar otra implementación para pruebas de Asistente para que otras pruebas puedan utilizarla también. 
El objetivo principal de las pruebas unitarias es asegurar que el código que hemos programado funciona realmente como lo esperamos; no precisamente refleja lo que el cliente nos pidió (aunque debería de ser), para eso existen otro tipo de pruebas como las de Aceptación de Usuario. Por lo tanto, las Pruebas Unitarias están destinadas para el aseguramiento del desarrollador y no para el usuario final.
Existen varios frameworks para poder realizar estas Pruebas Unitarias, tales como la familia XUnit: Junit para java CppUnit para C, PhpUnit  y Nunit para .Net. Existe otra familia de frameworks igualmente famosa como TestNG.


Pruebas de Aceptación de Usuario


Las Pruebas de Aceptación (acceptance tests) son principalmente para usuarios no técnicos como aprobadores, clientes, usuarios de sistema etc.
Se pueden hacer este tipo de pruebas montadas sobre Xunit pero también existen frameworks especializados como EasyB para groovy, JBehave y Cucumber para Java, etc. Éstos están basados en las metodologías de Desarrollo Basado en Pruebas (TDD Test Driven development ) y Desarrollo Basado en Comportamiento (BDD Behavior Driven Development) que es un subconjunto de TDD.
 Para poder generar este tipo de pruebas y poder montarlos sobre Xunit o en cualquiera de los otros frameworks podemos utilizar herramientas como como Webdriver ,Selenium y en lo particular prefieroThucydides

Existen tres maneras de hacer pruebas en web.
1. Mediante grabación:  Con una herramienta empieza a grabar la pantalla y uno comienza a abrir la aplicación web,  hacer clicks, llenar campos etc, y la herramienta grabará todos los inputs que se escribió y recuerda la posición de cada campo o elemento. De esta manera, para ejecutar las pruebas posteriormente, prácticamente, se le pone "play" y la herramienta comenzará a repetir lo grabado.
El mayor problema de este tipo de pruebas es que si la página cambia de look& feel o de posición los elementos, la grabación ya no servirá porque las coordenadas de los campos han cambiado de posición.  Sin embargo es un método válido, muy usado y fácil de implementar. 
2. Otro método es por Scripts: En el cual, uno levanta la herramienta, por lo regular como plugin de Firefox, y comenzamos a utilizar la aplicación.  La herramienta en lugar de grabar las coordenadas obtendrá los objetos del DOM del navegador y comenzará a guardar instrucciones en Javascript. Para ejecutar posteriormente las pruebas, habrá que inicializar el plugin en el navegador y éste comenzará a ejecutar los comandos de javascript.
Este método es muy bueno y confiable sin embargo no tiene la facilidad de ejecutar las pruebas de manera automatizada y obtener reportes de las pruebas.
Selenium y Webdriver utilizan este método.
3. La tercera manera se le llama Page Objects: El cual es prácticamente una capa encima del método Por Scripts pero el desarrollo de las pruebas se programan en Java ( o groovy)  y la herramienta, al ejecutar las pruebas, creará las respectivas instrucciones de javascript y ejecutará Selenium, por ejemplo. Pero estará al control de las pruebas y podrá generar reportes de resultados.
La ventaja de este método es la automatización de las pruebas y la generación de reportes enfocado a Usuarios Finales, Clientes y demás personal no técnico. Además de poder hacer la abstracción entre información de negocio (para clientes de alto nivel), bajando a cada paso de pruebas (para usuarios de sistema) y separando la implementación la capa WEB de las páginas (información muy técnica)
Thucydides es un gran ejemplo de un framework que utiliza esta manera.


Importante

El objetivo de las Pruebas de Aceptación es mostrar al usuario no técnico el avance del desarrollo.


Existe una variación de este tipo de pruebas las cuales son las Pruebas de Aceptación Automatizadas, las cuales, la única diferencia con las no automatizadas es que, las automatizadas siempre deben de tener los mismos inputs y esperar siempre los mismos resultados; por lo tanto, para realizar este tipo de pruebas automatizadas se deberán utilizar Clases Mock o Stubs para la interacción con otros componentes como base de datos, mensajería, etc. y tener datos controlados como en el caso de las Pruebas Unitarias. De esta manera, garantizaremos que nuestras Pruebas de Aceptación de Usuario Automatizadas podrán ser ejecutadas mil veces y las mil veces tendrán el mismo resultado.


Pruebas de Regresión


Existen también las Pruebas de Regresión las cuales pueden ser Pruebas de Aceptacion o Pruebas Funcionales pero se realizan sobre una aplicación ya terminada para tener una base de su funcionalidad básica.
Este tipo de pruebas se realizan principalmente sobre una aplicación que no se tiene documentación o ningún tipo de pruebas, por lo que estas pruebas se deben realizar antes de hacerle una modificación a la aplicación.  Por lo tanto, solo hay que hacer pruebas de las funcionamiento básico y no exhaustivo preferentemente.


Pruebas Funcionales


Las Pruebas Funcionales son pruebas similares a la de aceptación con la diferencia que sí son técnicas y por lo tanto deberán incluir cada uno de los requerimientos funcionales. En general, las Pruebas de Aceptación incluyen Pruebas Funcionales y No Funcionales.
Para este tipo de pruebas es necesario que se realizen también bajo ambientes controlados para poder manipular los datos de entrada y salida. Por ejemplo, en una base de datos que deberá popularse con datos ya conocidos antes de iniciar. Esto servirá para que las pruebas siempre funcionen y no marquen error cada vez que se ejecutan debido a que la base ya cambió de estado


Pruebas de Integración


Las Pruebas de Integración son similares a las funcionales o las de aceptación, pero sobre repositorios reales, datos reales y con la interacción real con otros sistemas o componentes.
Principalmente sirven para asegurar que la implementación en alguna ambiente en particular (UAT o Producción ) ha sido exitosa. Aquí el término exitoso implica que la aplicación corre al 100% por lo tanto, todos los artefactos han sido instalados y configurados correctamente y que también su convivencia con otros componentes como base de datos, mensajeria entre otros es correcto. Estas pruebas automatizadas ayudan mucho en tareas repetidas y aburridas cada vez que se hacen implementaciones.


Pruebas No Funcionales


Este tipo de pruebas están destinadas a probar que los requerimientos no funcionales han sido satisfechos completamente. Lo que en general se intenta probar son funcionalidades en el comportamiento bajo estréss, alta demanda, respuesta bajo los límites de tiempo establecidos por el cliente, ciertos criterios de look&feel, etc.


Pruebas de Stress


Las Pruebas de Stress son una particularidad de las Pruebas No Funcionales y sirven para verificar el comportamiento de una aplicación bajo una demanda excesiva.
El objetivo es poder generar una gran cantidad de peticiones a la aplicación y verificar su comportamiento, y de esta manera poder garantizar el número máximo de peticiones bajo las cuales la aplicación, servidor, interacción con otros aplicativos, etc, es normal.
Para poder realizar este tipo de pruebas hay que contemplar muchas variables y se vuelve un tanto complejo su implementación y análisis.
Por ejemplo:
  • Deben realizarse sobre un ambiente lo más parecido al de Producción. De esta manera, los resultados serán congruentes con los experimentados en producción.
  • En caso que no se tenga un ambiente similar a Producción, el análisis se vuelve complejo; esto es porque es dificil poder extrapolar los resultados en este ambiente y llevarlos a un análisis productivos, ya que por lo general los sistemas no se comportan de una manera lineal para poder predecir.
  • Por otro lado, se debe contemplar varios clientes que realizen las pruebas y los clientes deberán ejecutarse en diferentes computadoras. Esto debido a que tenemos que considerar la carga de CPU que se genera en cada computadora y no sobrecargarlas, sino las peticiones que generen irán disminuyendo.
  • Si se realizan estas pruebas distribuidamente, se tendrá que considerar la recolección de los resultados de cada una de las computadoras y analizar el conglomerado de datos.
En general, para poder realizar este tipo de pruebas deberá tenerse un plan bien definido de la arquitectura de servidores / computadoras que las realizarán, un método de recolección y análisis centralizado.
JMeter de Apache es excelente para ésto.


Pruebas de Calidad de Código


Este tipo de pruebas sirven para garantizar que la calidad del código es realmente óptima y que la probabilidad de tener errores o bugs en la codificación es mínima (nunca dejarán de existir los bugs pero al menos podemos hacer lo pertinente para disminuir la probabilidad).
Existen varios tipos de análisis de calidad y para cada uno existen diferentes herramientas, por lo que a continuación explicaré generalmente qué tipo de análisis se pueden realizar y con qué herramienta.

Cobertura:

Este análisis nos indica el porcentaje que nuestro código desarrollado ha sido probado por las pruebas unitarias. La idea principal es que entre más código probado menor el riesgo de que aparezcan comportamientos indeseados. Cobertura es una herramienta muy usada para este tipo.

dashboard

Análisis de Líneas de Código: 

Este tipo de análisis nos indica la pulcritud del código y se puede dividir en varios:
  • Código repetido: Nos indica el porcentaje de código que se encuentra repetido. Esto es, evita que tengamos la misma funcionalidad repetida en varios lugares en el proyecto y que al encontrar un bug y corregirlo nos falte corregirlo en los demás bloques. También nos ayuda a tener un diseño más estructurado y con mayor cohesión.PMD y Simian son buenas herramientas para ésto.
  • Código Documentado: Nos ayuda en poder conocer qué porcentaje de nuestro código está documentado para que al generar el JavaDoc sea los más real posible.
  • Código comentado: Nos dice el porcentaje del código que se encuentra comentado. Aunque en la práxis este código documentado no afecta, ya que la máquina virtual lo ignora, sí mete ruido y suciedad en el código al debuggearlo. Si en teoría comentamos un código porque actualmente no se va hacer uso de el pero en un futuro es probable y no tegamos que recodificarlo, es un hecho que la mayoría de las veces NUNCA descomentamos el código para usarlo, por lo que casi siempre resulta basura. Además, contando que se usa una versionador como Git o Subversion, es más facil remitirnos a la versión donde el código sí existe, tomarlo y luego copiarlo que andarlo arrastrando siempre comentado e inservible.

Complejidad: 

Este dato de complejidad nos indica que tan complicado es el código (es la implementación ciclomática de McCabe). Por lo regular la complejidad aumenta cuando el código tiene muchas sentencias IF-ELSE, Loops, Switch, etc. La teoría bajo este análisis es que entre menos complejo es un código, más sencillo es poder entenderle, por lo que será mas probable que haga lo que nosotros queríamos que hiciera.
Con un buen "refactoring" este indicativo puede ser controlado bastante eficaz.

Diseño de Clases:

Este análisis lo que intenta demostrarnos es la relación que existe entre las clases en diferentes paquetes. La agrupación de clases en paquetes sirve para diferenciar la funcionalidad entre clases. Por ejemplo, se tiene una clase de pojos, otra de controladores, otra de interfaces otra de implementación, otra de constantes y utilierías, etc. Por lo que este análisis nos muestra los paquetes desde los más abstractos a los más concretos, por lo que la mayoría de las relaciones las tienen las clases más concretas. Así que si en nuestro diseño existe algún error, este análisis nos mostrará las relaciones indebidas de una clase concreta que hace uso de una abstracta.

Violaciones de Calidad:

Existen varias reglas ya definidas y conocidas las cualas al analizar el código y su funcionalidad pueden caer en este tipo de reglas. Estas pueden ser desde meramente funcionales, estéticas, estándares  y hasta críticas con bugs potenciales. Herramientas como Checkstyle, Findbugs o PMD
Por ejemplo: Existe la regla Magic Number, el cual nos indica que estamos haciendo una comparación con un número establecido y la teoría dice que ningún número debe ser definido ya que al analizar el código nos costará trabajo enteder el por qué de ese número; así que es más facil usar una constante con un nombre explícito que mencione el significado de ese número. Al poder disminuir éstas violaciones lo más posible, estaremos garantizando que el código cumple con estándares o convenciones, tiene el menor riesgo de bugs probables y en general buenas prácticas de desarrollo.

Sonar:

Sonar es una herramienta que tiene integrado todas estas pruebas de control de calidad por lo que dentro utiliza PMD, Findbugs, Checkstyle, Cobertura y demás herramientas en un lugar centralizado. La ventaja de esta herramienta es que podemos utilizarla para poder realizar estos análisis en un lugar centralizado con reportes generalizados, detallados y con la posiblidad de ir adentrando (drilldown). Existe un plugin para maven, jenkins, eclipse, etc. para poder hacer todos los análisis bajo un mismo criterio que en Sonar asignemos.



Resumen

En resumen, podemos hacer uso de todos o alguno de este tipo de pruebas. Entre más pruebas abarquemos, mayor garantía estaremos dando a nuestros clientes de entregar un producto de alta calidad, código limpio, reportes de avances, status de implementación de requerimientos funcionales y no funcionales, etc.
Estas pruebas pueden implementarse bajo un Contenedor de Integración Contínua como Jenkins para que se realicen automáticamente y escalonadamente.
En caso que aún no tengas en tus proyectos algunas de estas pruebas, no te asustes, puedes comenzar a implementar y estandarizar de una en una. ¡Recuerda que es un proceso de madurez!


Post Similares

TituloDescripciónCategoriaTecnologíasTipoFecha de publicación
Subversión y Jenkins: cómo comunicarse entre ellos Como poder indicarle a Jenkins iniciar una actividad cuando Subversion ha sido actualizado Integración continua Subversion, Jenkins Tip 17 de septiembre de 2012 
Jenkins & Sonar: Status en jenkins refleje alertas de sonar Cómo poder mostrar en Jenkins el status real dependiendo de las alertas de Sonar Integración continua Subversion, Jenkins Tip 29 de agosto de 2012 
Web Tiers: Explicación Explicación sobre el concepto "tiers" en proyectos web. Diseño Servlets Explicación 1 de septiembre de 2009 
Tipo de Pruebas para Desarrollo de Software Explicación sobre los diferentes tipos de pruebas que se pueden hacer en el desarrollo de software Calidad XUnit, Sonar, PMD, Findbugs, Thucydides, Checkstyle, Cobertura Explicación 11 de septiembre de 2012 
Integración Continua: Promociones y Líneas de Producción  Explicación del concepto de promociones y pipelines en Integración Continua Integración continua Jenkins y plugins Explicación 27 de septiembre de 2012 
Mostrando 5 elementos de la página Indice de posts ordenados por hora de edición. Ver más »


Web Tiers: Explicación

publicado a la‎(s)‎ 31 ago 2012, 9:44 por Eliu Montoya   [ actualizado el 20 sept 2012, 21:54 ]

Tema
: Explicación sobre el concepto "tiers" en proyectos web.
Categoría: Explicación concreta / Diseño en Java Web
Tecnologías / Componentes: Servlets
Este articulo lo realice en el año 2009 como una presentación - explicación de algo tan básico que muchos consideramos como "commodity", sin embargo en muy pocas escuelas, cursos etc, logran explicar realmente el concepto. Así que apesar que el escrito ya tiene sus años, quisiera  redocumentarlo para cualquier referencia que se le pueda dar.


1. Justificación

Como estudiante de tecnología java en todas sus facetas, siempre he encontrado modelos y patrones de arquitectura, por lo cual, para mí, está excelente. El único problema que tuve al inicio
fue la definición "Tier" y cómo en la vida práctica se dividen.Es por eso, que he hecho este escrito, ya que puede ayudar a alguien a entender un poco mejor la
arquitectura empresarial, y en específico, la arquitectura para Web.

Por lo tanto, explicaré que son los Tiers (Web Tier, Client Tier, etc.), cuales son sus responsabilidades y como en la vida práctica de un programador podría mejorar su desarrollo, todo esto, enfocado al desarrollo web.
Aunque hay mucho tema que abarcar en cada punto, éste escrito únicamente está intencionado a ser una introducción y comprensión rápida sin llegar a ser muy técnica. Por lo que al final habrá referencias especializadas para una mayor lectura. 

En caso que alguien quiera comentar, dar sugerencias, correcciones, agregaciones o de plano
contradecir, con todo gusto pueden contactarme.

2. Introducción

Durante los años la arquitectura de las redes y los sistemas ha evolucionado.



En el inicio solo existían terminales tontas conectadas a un Main Frame.
Después surgieron las computadoras personales, las cuales corrían aplicaciones siendo totalmente
autistas, esto es, que no se compartían los datos de una con otra. En los 90s se extendieron las aplicaciones de escritorio para que pueda comunicarse y guardar datos
en un servidor central; Sin embargo, conforme fue evolucionando la tecnología, fueron surgiendo
varios tipos de clientes, lo cual evolucionó a la arquitectura de Internet.
Ahora, con la perspectiva empresarial, han surgido muchas teorías, patrones y modelos de arquitectura, las cuales son usadas en casos específicos, no obligando a que una sola sea totalmente
efectiva o totalmente errónea. Y una de éstas tantas es la que está enfocada en desarrollo java Web,
la cual está basada en Tiers.

3. Tiers

Primeramente, considero importante aclarar la terminología "tier" ya que con una mejor comprensión de su significado, muchas ideas se pueden aclarar. En ingles se llaman "tiers" y en español se traduce muchas veces como "capas" lo cual está un tanto incorrecto. Si imaginamos una cebolla, donde existe una capa superior y se quita, hay una capa interna, etc. Esta traducción es correcta cuando hablamos de capas lógicas en un servidor: existe la capa de la aplicación, que debajo de esa está la de servicio y debajo de ésta la del protocolo, y debajo la del sistema operativo, etc... Pero cuando hablamos de tiers, no son capas, son más bien filas o hileras.
Haciendo una similitud, como en el cine hay hileras de butacas donde están las hileras de enfrente, luego las de en medio y las de atrás, pero no están en forma de capas. Así es como debemos
entender los tiers; y de esta manera, existe un tier de cliente, un tier de web, de aplicación, de persistencia y de base de datos; y dentro de cada una de estas hileras existe una función específica.



Así que durante este escrito usaré hileras o filas indistintamente.

Importante

Los "tiers" no son capas, son hileras

Para empezar tenemos que entender cómo funcionan las filas (tiers) y cuáles son sus responsabilidades, ya que es básico para un desarrollo profesional; esto cumplirá la regla de alto acoplamiento (tight coupling) lo cual significa que cada clase debe tener un nicho de funciones únicamente, en otras palabras, deberá hacer ciertas tareas y no varias; entre más especializado esté una clase, mejor diseñado está el sistema y tendrá menos problemas y será más fácil de solucionar situaciones futuras.

3.1 Modelos

Existen dos modelos para desarrollar Web: web centric y ejb container

3.1.1 Web Centric

Es un modelo basado en 3 "tiers", hileras:
  1. Una para el cliente,
  2. otra donde se juntan la de presentación y la de negocio, a ésta se le conoce como Web Tier; 
  3. y otra para los recursos (base de datos o cualquier repositorio).



La fila de Cliente (Client Tier) es la hilera donde se ejecutan procesos del lado del usuario; aquí se encuentra lo que corre en el navegador; esto puede ser javascript, applets, Ajax, web start, etc.

La hilera de Presentación es lo que se ejecuta del lado del servidor web que está manejado por un contenedor Web, como Tomcat.
Aquí se encuentran los archivos jsp y servlets.

Business Tier es la hilera que ejecutará procesos de negocio, pero debido a que se encuentra en el mismo Web Tier, junto con la de Presentación, entonces, en este caso, deberá haber una
carpeta o paquetes donde estén los servlets y otros paquetes donde estén los servicios. Esto se encuentra manejado dentro del mismo contenedor web (tomcat, etc).

Por lo tanto, cuando una petición del navegador llega al servidor, ésta la recibe un servlet que su función es únicamente la recolección de los datos del navegador, y decidir a que clase de servicio
llamará, y por último decidir que jsp de respuesta mandará al navegador.

Aunque explicaré el otro modelo también (EJB Contrainer), el resto de este documento será específico para este modelo Web Centric, por lo que no usaremos ejbs sino clases Javas como
servicios; aunque, en otro escrito ya se evolucionará esta presentación a EJB 3.0 y JPA

3.1.2 EJB Container

Este modelo consiste en la división del Web Tier en dos hileras más, por lo que tenemos 4 hileras:

  1. La hilera de Cliente sigue siendo para el navegador y los procesos que corren dentro de él.
  2. La de Presentación está asignada para el contenedor Web y aquí residirán los jsp y servlets.
  3. La hilera de Negocio está reservada para clases de negocio, ejbs de sesión, de mensajes, o web service, etc. Éstos componentes tendrán la responsabilidad de ejecutar las reglas de negocio. En esta hilera vive un contenedor de aplicaciones como JBoss, Glassfish, etc.
  4. Por último está la hilera de Recursos, en la cual vive el repositorio de datos, ya sea una base de datos, archivos, ftp, ldap, etc.


En la práctica esto funciona de la siguiente manera:
1) El navegador manda una petición al contender web.
2) El contenedor web detecta la petición y se lo manda a un servlet para su ejecución.
3) El servlet obtiene los datos de la petición, y por medio de JNDI hace una búsqueda al servicio (ya
sea ejbean o web service).
4) Por medio de RMI manda objetos y ejecuta remotamente el método.
5) En la hilera de negocio, el ejbean hace todas las validaciones de negocio y ejecuta las reglas.
6) Llama a clases DAO, asignadas para la intervención con la base de datos.
7) Los daos hacen la tarea especifica dentro de la bd.
8) El ejbean termina su ejecución y manda una respuesta al servlet.
9) El servlet recibe o no, la respuesta del ejbean y decide que jsp regresa como respuesta al
navegador.

3.1.3 Otros Modelos

Obviamente existen muchos otros modelos, que pueden usarse fuera o dentro del concepto web, así que para mayor referencia se puede consultar una excelente página de Chad Z. Hower: http://www.codeproject.com/KB/architecture/TierPressure.aspx

Pero en general el modelo EJB Container puede ser la base para los demás, ya que éste puede
crecer para que se pueda hace una aplicación de escritorio, la cual residirá en la hilera de Cliente y se
pueda comunicar directamente con los ejbs del lado del Negocio.



O expandir el lado del negocio para crear una capa de web services, los cuales expondrán al mundo
entero las funcionalidades de negocio de los ejbs pero en formato XML; así que cualquier cliente
pueda comunicarse con el sistema.

4 Componentes de un Web Tier

Como habíamos dicho, el web container está compuesto por:
  • servlets que su función será de controladores de la vistas,
  • Jsp, que serán las vistas,
  • EJB o clases de servicio que realizarán el negocio,
  • Pojos que serán las entidades de negocio,
  • DAOS las cuales serán las responsables de la conexión a la base de datos y realizar el CRUD (create,
  • retrieve, update, delete).
  • Y clases de utilería y librerías.



Como recomendación, se puede dividir en las siguientes carpetas:
1) /web/*
en esta carpeta estarán los html, imágenes, .js, .css
2) /web/jsp/*
Aquí vamos a meter los jsp
3) /src/servlets
Únicamente servlets
4) /src/pojos
Meteremos las clases pojos
5) /src/daos
Meteremos las clases responsables de la persistencia en la base de datos
6) /src/services
Clases que harán la lógica del negocio (como si fuera el business tier)
7) /src/utils
Clases extras



4.1 Jsp

Los Jsp son las vistas para el cliente dentro del modelo MVC.
Estos JSP están compuesto de html y acciones o comandos de java, pero que sufren una transformación de la JVM para que al llegar al navegador no se vea nada de código java, sino que ya se haya ejecutado en el lado del servidor.



Se usan como páginas html dinámicas, aunque en el fondo son "servlets modificados", pero eso es otro tema y que seguramente se abarcará en otro escrito.
Por lo tanto, se pueden ver a los jsp, que cuando están del lado del servidor son documentos html con comandos java los cuales se ejecutarán antes de enviarse al navegador como una respuesta; y del lado del navegador, son páginas HTML puras.



4.2 Servlets

Los servlets tienen la responsabilidad únicamente de recopilar los datos del navegador, validar que se tengan los necesarios y el tipo correcto y después mandar a llamar al servicio correspondiente (los
que están en /src/services o al ejb o webservice de la Business Tier) y finalmente mostrar el jsp de respuesta. Así que en general fungirán como Controladores del modelo MVC; por lo que serán el
único punto de comunicación con el cliente.



Ej. En el navegador llenas un formulario para crear un Cliente nuevo, con campos Nombre, apellidos, sexo y edad. Entonces el servlet debe obtener estos valores del httpRequest y llenar un Pojo Cliente (cliente.setNombre(request.getParameter("nombre")); )
Una vez lleno el pojo se lo mandas al servicio:
ClienteServicio.crear(cliente);
Al final regresará el jsp que queremos:



4.3 Pojos

Los pojos se traducen como Plain Old Java Objects y únicamente son clases de negocio: Clientes, Categorias, Productos, etc.. aunque también son conocidos como Entities, o entidades.




En caso que necesitemos crear clases extras como MyException, esa se meteria en /src/utils, ya que no serían parte del negocio.
Hay que recordar que cuando se habla de clases de negocio o de clases de persistencia, significa que son objetos que se guardarán en la base de datos, osea que hay una tabla para cada pojo, etc.

Algo muy importante de los pojos es que TODAS sus propiedades son prívate y se tienen que hacer funciones de acceso y modificación por cada propiedad, a lo que se les conoce como getter y setters.
Además que debe tener el constructor sin argumentos.




4.4 Daos




Son clases responsables de la conexión a la bd y llamadas en sql. Una de sus practicidades es que si en algún momento se cambia de framework de ORM, como hibernate, NO habrá que cambiar nada más, únicamente estas clases.

Existe un DAO para cada Pojo (por lo regular) y contiene métodos especializados para cada acción que se quiera realizar en la bd con esa clase de negocio. Además, estas clases son responsables de abrir y cerrar la conexión a la base de datos; y para crear una conexión se puede usar una clase Factory la cual contendrá el string, búsqueda en el contexto, etc, para iniciar el data source.



Por lo que las ventajas de los DAOs son:

  • La lógica del neogocio con la del acceso a la base de datos están separadas.
  • Promueven el reuso y la flexibilidad de ser cambiadas o modificada



4.5 Servicios

Los servicios son las clases encargadas de realizar la lógica de negocio y es recomendable tener una clase servicio por cada Pojo que existe y dentro habrá funciones específicas para cada acción que se
puede hacer con ese pojo; o por otro lado, tener un servicio por cada caso de uso y métodos por cada escenario.

EJ. La clase ClienteServicio tendrá las funciones crear, modificar, eliminar, clonar, buscar, obtenerTodos, verificar, etc.
Estos servicios NO accesan directamente a la bd, sino que usa a los daos para eso.

5. Conclusión

Así que para finalizar, hemos visto los 2 diferentes tipos de modelos de arquitectura para web, los cuales se resumen en tener componentes especializados para cada una de las hileras del proceso. Jsp para el cliente, servlets para el web tier que sean la cara al cliente, los servicios que son parte del proceso de negocio y los de acceso a la base de datos, los cuales están encargados la conexión y acceso al repositorio.



Por lo que es muy importante tener siempre en cuenta esta división de trabajo, al momento de diseñar nuestros sistemas, ya que serán mucho más confiables, seguros, mantenibles y al seguir estándares de arquitectura, son escalables.

6 Referencias


Componentes:

 

Post Similares

TituloDescripciónCategoriaTecnologíasTipoFecha de publicación
Subversión y Jenkins: cómo comunicarse entre ellos Como poder indicarle a Jenkins iniciar una actividad cuando Subversion ha sido actualizado Integración continua Subversion, Jenkins Tip 17 de septiembre de 2012 
Jenkins & Sonar: Status en jenkins refleje alertas de sonar Cómo poder mostrar en Jenkins el status real dependiendo de las alertas de Sonar Integración continua Subversion, Jenkins Tip 29 de agosto de 2012 
Web Tiers: Explicación Explicación sobre el concepto "tiers" en proyectos web. Diseño Servlets Explicación 1 de septiembre de 2009 
Tipo de Pruebas para Desarrollo de Software Explicación sobre los diferentes tipos de pruebas que se pueden hacer en el desarrollo de software Calidad XUnit, Sonar, PMD, Findbugs, Thucydides, Checkstyle, Cobertura Explicación 11 de septiembre de 2012 
Integración Continua: Promociones y Líneas de Producción  Explicación del concepto de promociones y pipelines en Integración Continua Integración continua Jenkins y plugins Explicación 27 de septiembre de 2012 
Mostrando 5 elementos de la página Indice de posts ordenados por hora de edición. Ver más »

Jenkins & Sonar: Status en jenkins refleje alertas de sonar

publicado a la‎(s)‎ 29 ago 2012, 22:27 por Eliu Montoya   [ actualizado el 20 sept 2012, 21:36 ]

Tema: Como poder mostrar en Jenkins el status real dependiendo de las alertas de Sonar
Categoria: Tip // Integración Continua
Tecnologías / Componentes: Subversion, Jenkins.

Introducción

Una de las facilidades de Jenkins es la integración transparente con Sonar ya que toda la configuración del proyecto lo toma del POM, por lo que no hay que configurar nada (a excepción de la configuración general de Sonar, pero eso se hace solo una vez).
Sin embargo, al crear un JOB en Jenkins que ejecute Sonar, éste siempre aparecerá en Verde (o Azul) apesar que el projecto en Sonar haya tenido alertas.

Para éso sirve el plugin Break Build.

Break Build es un plugin que se instala en Sonar y que logra mandar mensajes de error al momento de hacer BUILD con maven. Por lo tanto, si Sonar levanta alguna alerta, break build le dirá a maven que existió un error en el BUILD por lo que maven se detendrá aunque Sonar sí logrará terminar por completo su análisis.
Los mensajes de error que aparecerán en los logs del build serán las alertas de Sonar.

Esto nos ayuda a poder crear un JOB en Jenkins que pueda ser Verde o Rojo en caso que hayan existido alertas en Sonar.


Instalación

La instalación es muy facil:
  1. Bajar el jar de la página de Sonar en la sección de Break Build
  2. Copiar el jar en la carpeta interna de Sonar $SONAR_HOME/extensions/plugins
  3. Reiniciar el servicio de sonar
  4. Ejecutar el Job desde Jenkins.

Post Similares

TituloDescripciónCategoriaTecnologíasTipoFecha de publicación
Subversión y Jenkins: cómo comunicarse entre ellos Como poder indicarle a Jenkins iniciar una actividad cuando Subversion ha sido actualizado Integración continua Subversion, Jenkins Tip 17 de septiembre de 2012 
Jenkins & Sonar: Status en jenkins refleje alertas de sonar Cómo poder mostrar en Jenkins el status real dependiendo de las alertas de Sonar Integración continua Subversion, Jenkins Tip 29 de agosto de 2012 
Web Tiers: Explicación Explicación sobre el concepto "tiers" en proyectos web. Diseño Servlets Explicación 1 de septiembre de 2009 
Tipo de Pruebas para Desarrollo de Software Explicación sobre los diferentes tipos de pruebas que se pueden hacer en el desarrollo de software Calidad XUnit, Sonar, PMD, Findbugs, Thucydides, Checkstyle, Cobertura Explicación 11 de septiembre de 2012 
Integración Continua: Promociones y Líneas de Producción  Explicación del concepto de promociones y pipelines en Integración Continua Integración continua Jenkins y plugins Explicación 27 de septiembre de 2012 
Mostrando 5 elementos de la página Indice de posts ordenados por hora de edición. Ver más »

Integración Continua: ¿Qué es?

publicado a la‎(s)‎ 29 ago 2012, 22:24 por Eliu Montoya   [ actualizado el 20 sept 2012, 21:40 ]

Tema: Explicación a grandes rasgos de una plataforma de Integración Continua.
Categoria: Explicación concreta / Integración continua
Tecnologías / Componentes: Subversion, Jenkins, Nexus, Maven
Integración continua es una parte de mejora continua y el punto principal es automatizar el proceso de desarrollo, el cual abarca desde la programación hasta la liberación en producción, sea cual sean los pasos intermedios.  

Descripción

Para poder explicarlo mejor tomaré un ejemplo concreto:
Con integración continua en el área de desarrollo se podrá :
  • Un desarrollador inicia un proyecto desde cero y guarda el código en un versionador.
  • Los demas desarrolladores podrán accesar a dicho código y pueden codificar todos a la vez y hasta crear otros proyectos o modulos dependientes.
  • Mientras cada uno registra sus cambios en el versionador, un servidor de Integración Continua irá bajando cada versión y lo compilará en un ambiente independiente para asegurar que el código funciona en cualquier ambiente sin dependencias de configuración local.
  • El mismo servidor hará pruebas unitarias para asegurar que cada versión no ha sufrido una regresión en funcionalidad.
  • Después guardará el artefacto (el compilado, ejecutable, jar, war etc) en un repositorio de artefactos como versión SNAPSHOT o EN-DESARROLLO para que otros puedan usarlo. 
  • En caso que tenga proyectos dependientes,  este servidor también obtendrá el código del repositorio de versiones y hará la compilación y pruebas unitarias pero, obviamente, utilizando la versión que se está probando para asegurar que no solo el proyecto funciona sino que no haya provocado errores en sus proyectos o módulos que lo usan.
  • Después de verificar las pruebas unitarias, el servidor podrá ejecutar varias tareas escalonadas, tales como pruebas funcionales, siguiendo con pruebas de control de calidad de código, stress, etc.
  • Si todos esos pasos han concluido satisfactoriamente podrá hacer la implementación en algún ambiente, por ejemplo UAT o pruebas. Esto implica que ponga el ejecutable en algún contenedor (jboss, tomcat, etc), realice las configuraciones necesarias,  configure la base de datos, repositorios, etc para que funcione correctamente en dicho ambiente.
  • Después podrá ejecutar pruebas de aceptación sobre la reciente implementación para asegurar que la funcionalidad y requerimientos iniciales estén implementados. Estas pruebas son las mismas que se le entrega a los testers para validar cada caso de uso y escenario,  únicamente que estas son automatizadas.
  • Si las pruebas son correctas, el servidor podrá hacer nuevamente la implementación pero tal vez ahora en el ambiente de producción.  
  • Después podrá repetir las pruebas de aceptacion pero ahora con datos reales. Esto se convertiría en Pruebas de Integración ya que estariamos asegurando que la implementación esté correcta y el sistema esté integrado con los demás sistemas como base de datos, mensajeria y hasta redes.

Este ejemplo muestra la capacidad y gran ventaja que ofrece Integración Continua. Lo mas hermoso es que todo esto es automatizado y permite que mientras el desarrollador se dedica a lo suyo, que es codificar e ir avanzando en el proyecto, tras bambalinas se va probando lo que hizo y hasta puede terminar el producción. ¡¡Probablemente se pueden llevar 2 o 3 horas desde que el desarrollador sube algún cambio al repositorio hasta que se encuentre liberado en producción con todo y pruebas!!

¡Que gran ventaja es poder contar con esté framework!


Herramientas que Componen a Integración Continua


Si seguimos el ejemplo previo podemos extraer mínimo 4 componentes :
1. Un compilador de proyectos y administrador de dependencias  como Maven. También se les conoce como "build automation"
2. Un controlador de versiones o también conocido como SCM (source control manager o revision control) como Subversion o Git.
3. Un repositorio de artefactos que sirva para separar versiones liberadas y en desarrollo como Nexus o Artifactory.
5. Un servidor de integración continua como Jenkins o Bamboo
6. Una herramienta para pruebas de calidad de código como Sonar.

Prácticamente estos son los componentes mínimos. 

En los siguientes artículos iré detallando cada uno de los componentes, sus configuraciones mínimas y sus funcionalidades primarias.

Nota

existe una máquina virtual para virtualbox abierta que se llama Agilebox. Este appliance es gratuito gracias a lebrijo y es una máquina con Ubuntu donde ya vienen todos estos componentes instalados y configurados listo para comenzar a usarse.


Resumen.

Finalmente podemos concluir con las bondades y ventajas que una plataforma de integración continua nos puede dar :
  • Automatización de tareas para disminuir error humano.
  • Automatización de pruebas para poder hacer análisis y verlo todo en un tablero de control.
  • Disminución de responsabilidades extras a los desarrolladores, testers, integradores, etc.
  • Establecimiento de métricas y procesos definidos para optimizar y eficientar tiempo y calidad. 
  • Facilidad para obtener reportes de cada prueba y así poder integrar al usuario en el status de cada proyecto.  
  • Visibilidad de todos los proyectos y su relación entre varias dependencias.
  • Tener un repositorio centralizado tanto de códigos fuentes como de artefactos finales y la capacidad de poderlos dividir entre desarrollo y liberaciones.
  • Posibilidad de decrementar el tiempo para liberar a producción cambios y aumentando la calidad.}

Posts Similares

TituloDescripciónCategoriaTecnologíasTipoFecha de publicación
Subversión y Jenkins: cómo comunicarse entre ellos Como poder indicarle a Jenkins iniciar una actividad cuando Subversion ha sido actualizado Integración continua Subversion, Jenkins Tip 17 de septiembre de 2012 
Jenkins & Sonar: Status en jenkins refleje alertas de sonar Cómo poder mostrar en Jenkins el status real dependiendo de las alertas de Sonar Integración continua Subversion, Jenkins Tip 29 de agosto de 2012 
Web Tiers: Explicación Explicación sobre el concepto "tiers" en proyectos web. Diseño Servlets Explicación 1 de septiembre de 2009 
Tipo de Pruebas para Desarrollo de Software Explicación sobre los diferentes tipos de pruebas que se pueden hacer en el desarrollo de software Calidad XUnit, Sonar, PMD, Findbugs, Thucydides, Checkstyle, Cobertura Explicación 11 de septiembre de 2012 
Integración Continua: Promociones y Líneas de Producción  Explicación del concepto de promociones y pipelines en Integración Continua Integración continua Jenkins y plugins Explicación 27 de septiembre de 2012 
Mostrando 5 elementos de la página Indice de posts ordenados por hora de edición. Ver más »

... de regreso

publicado a la‎(s)‎ 29 ago 2012, 21:54 por Eliu Montoya

Finalmente y después de que por algún motivo Google eliminó el sitio anterior en un cambio, estoy de regreso!

Este blog es un espacio donde compartir lo que voy aprendiendo y tips que me han servido en algún momento,  tanto para que no se me olviden y también, por si a alguien le sirve.

De ninguna manera pretendo hacer tendencia hacia algun enfoque, herramienta o framework en particular ni sugerir que mi punto de vista, recomendación o comentario son autoridad. Creo que hay personas que son generadores de tecnología y por lo tanto autoridades en el tema tales como Rod Johnson, James Gosling, Richard Stallman, Kohsuke Kawaguchi, entre muchos otros; y que habemos consumidores de dichas tecnologías.  Pero también creo en la superación continua personal y profesional donde cada uno vamos incrementando nuestro conocimiento y experiencia. También soy adepto al movimiento opensource por lo que, también creo que es mediante el intercambio de ideas, conocimiento y retroalimentacion donde todos vamos avanzando.
Es por eso que cualquier comentario, queja o sugerencia es siempre bienvenida con respeto.

Aprovecharé artículos viejos de mi otro sitio para también publicarlos de vez en cuando, aunque les daré una revisión para que no se encuentren desactualizados.

Espero que a alguien, ademas de a mí, le pueda servir de algo este espacio.

Saludos
Eliu Montoya

1-10 of 10