Catálogo de Normas de Desarrollo JEE6. Arquitectura de Referencia

(1)

Catálogo de Normas de Desarrollo JEE6 Arquitectura de Referencia

Versión: v01r00 Fecha: 18/09/2015 Gobernanza y Calidad

Subdirección de Tecnologías de la Información y Comunicaciones

(2)

Nrm_JEE6_ArquitecturaReferencia_v01r00 Página 2 de 19

CONTROL DE CAMBIOS DEL DOCUMENTO

Registro de cambios

Autor Versión Referencia de cambios Fecha

Ángel Miralles v01r00 Creación del documento 06/08/2015

Revisores

Nombre Versión Aprobada Posición Fecha

Fco. Javier Delgado v01r00 Coordinador 17/09/2015

Propiedades del documento

Propiedad Detalle

Título Catálogo de Normas de Desarrollo JEE6 Proyecto Arquitectura de Referencia

Autor Ángel Miralles

Nombre fichero Nrm_JEE6_ArquitecturaReferencia_v01r00 Fecha de creación 18/3/2015 11:39

Última actualización 17/09/2015 9:34 Plantilla base

(3)

INDICE

1. Introducción ... 4

1.1.O^BJETIVOS ... 4

1.2.A^LCANCE ... 4

1.3.CONDICIONES DE U^SO ... 4

2. Tecnología ... 5

2.1.J^AVAE^NTERPRISEE^DITION ... 5

2.2.SERVIDORES DE A^PLICACIÓN ... 7

2.3.RÊQUISITOSNÔFÛNCIONALES ... 7

3. Arquitectura ... 9

4. Empaquetado, Diseño y Modularidad ... 11

4.1E^MPAQUETADO... 11

4.2.D^{ISEÑO Y}M^ODULARIDAD ... 12

5. Patrones ... 14

6. Pruebas ... 15

6.1.P^RUEBASU^NITARIAS ... 15

6.2.P^{RUEBAS DE}I^NTEGRACIÓN ... 15

6.3.P^{RUEBAS DE}R^ENDIMIENTO ... 15

7. Ciclo de Vida del Software ... 16

8. Artefacto ... 17

9. Resumen de Pautas ... 18

10. Bibliografía y Referencias ... 19

(4)

1. Introducción

1.1. Objetivos

El presente documento tiene por objeto especificar normas, pautas y mejores prácticas aplicables al desarrollo con tecnología Java Enterprise Edition 6 o superior, en adelante Java EE 6.

1.2. Alcance

El presente documento aplica a proyectos que supongan nuevos desarrollos en tecnología Java.

El documento va dirigido a los siguientes actores:

 Equipos de desarrollo de proveedores.

 Jefes de proyecto y desarrollo del SAS.

 Oficina de calidad (OCa).

Para desarrollos ya existentes, así como para mantenimientos evolutivos y correctivos, la normativa aplicable se encuentra publicada en el documento Nrm_JEE_ArquitecturaReferencia_v03.pdf accesible desde el portal Unifica del Servicio Andaluz de Salud.

1.3. Condiciones de Uso

Las normas y recomendaciones recogidas en esta guía son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales. Asimismo cualquier aspecto no recogido en este documento deberá regirse según las normas establecidas en el Marco de Desarrollo de la Junta de Andalucía (MADEJA), debiendo ser puesto de manifiesto ante la STIC por el equipo de desarrollo.

La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata.

En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendación, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica.

(5)

2. Tecnología

2.1. Java Enterprise Edition

Java Enterprise Edition o Java EE (anteriormente conocido como J2EE hasta la versión 1.4; traducido informalmente como Java Empresarial), es una plataforma de programación para desarrollar y ejecutar software de aplicaciones en el lenguaje de programación Java. Permite utilizar arquitecturas de N capas distribuidas y se apoya ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones. La plataforma Java EE está definida por una especificación. Similar a otras especificaciones del Java Community Process (JCP), Java EE es un estándar debido a que los proveedores deben cumplir ciertos requisitos para declarar que sus productos son conformes al mismo.

Java EE tiene varias especificaciones de API, tales como JDBC, EJB, CDI, JMS, Servicios Web, JAX-RS, etc. y define cómo coordinarlos. Ello permite al desarrollador crear una aplicación de empresa portable entre plataformas y escalable, a la vez que integrable con otras tecnologías. Otros beneficios añadidos son, por ejemplo, que el servidor de aplicaciones puede manejar transacciones, seguridad, escalabilidad, concurrencia y gestión de los componentes desplegados, significando que los desarrolladores pueden concentrarse más en la lógica de negocio de los componentes en lugar de en tareas de desarrollo y mantenimiento de bajo nivel.

El grupo de Desarrollo y Arquitectura Software establece como norma obligatoria la utilización del estándar Java EE 6 o superior para el desarrollo de nuevos aplicativos. Esta tecnología está compuesta por las especificaciones indicadas en la figura 1.

Figura 1. Especificaciones tecnología Java EE 6.

Agrupadas por tecnología, las especificaciones incluidas dentro de Java EE 6 son las siguientes:

Web Technologies

 JSR 45: Debugging Support for Other Languages

 JSR 52: Standard Tag Library for JavaServer Pages (JSTL)1.2

 JSR 245: JavaServer Pages (JSP) 2.2 and Expression Language (EL) 1.2

 JSR 314: JavaServer Faces (JSF) 2.0

(6)

 JSR 315: Servlet 3.0 Enterprise Technologies

 JSR 250: Common Annotations for the Java Platform 1.1

 JSR 299: Contexts and Dependency Injection (CDI) for the Java EE Platform 1.0

 JSR 303: Bean Validation 1.0

 JSR 316: Managed Beans 1.0

 JSR 317: Java Persistence API (JPA) 2.0

 JSR 318: Enterprise JavaBeans (EJB) 3.1

 JSR 318: Interceptors 1.1

 JSR 322: Java EE Connector Architecture 1.6

 JSR 330: Dependency Injection for Java 1.0

 JSR 907: Java Transaction API (JTA) 1.1

 JSR 914: Java Message Server (JMS) 1.1

 JSR 919: JavaMail 1.4 Web Service Technologies

 JSR 67: Java APIs for XML Messaging (JAXM) 1.3

 JSR 93: Java API for XML Registries (JAXR) 1.0

 JSR 101: Java API for XML-based RPC (JAX-RPC) 1.1

 JSR 109: Implementing Enterprise Web Services 1.3

 JSR 173: Streaming API for XML (StAX) 1.0

 JSR 181: Web Services Metadata for the Java Platform 2.0

 JSR 222: Java Architecture for XML Binding (JAXB) 2.2

 JSR 224: Java API for XML Web Services (JAX-WS) 2.2

 JSR 311: Java API for RESTful Web Services (JAX-RS) 1.1 Management and Security Technologies

 JSR 77: J2EE Management API 1.1

 JSR 88: Java Platform EE Application Deployment API 1.2

 JSR 115: Java Authorization Contract and Containers (JACC) 1.3

 JSR 196: Java Authentication Service Provider Inteface for Containers (JASPIC) 1.0 La adopción y utilización de tecnología estándar Java EE 6 presenta las siguientes ventajas:

1. Portabilidad. La filosofía de la tecnología Java fue siempre Write Once, Run Anywhere, y la forma de lograr esta máxima ha sido siempre la utilización de especificaciones y estándares. Diferentes proveedores (Red Hat, Oracle, IBM, Apache, etc.) están obligados a respetar funcionalidades y configuración para poder certificar con Oracle servidores de aplicación. Esto permite que programando con el estándar tengamos libertad para elegir proveedor y por tanto mayor independencia y flexibilidad.

2. Dependencia. Cuando en un proyecto se elige trabajar con frameworks externos automáticamente se adquiere un compromiso con terceros. Si el día de mañana la comunidad que soporta el framework se disuelve o si la compañía propietaria descontinúa el proyecto, las aplicaciones desarrolladas con dicho framework quedarían en una situación comprometida, suponiendo un riesgo que es necesario evaluar. No es descabellado pensar en este supuesto; un ejemplo de esto mismo en el pasado es la discontinuidad de tecnología Flex, propiedad de Adobe.

3. Soporte. Cuantos más frameworks externos se utilicen mayor será el soporte requerido. Utilizando el estándar cualquiera de los proveedores certificarán y ofrecerán soporte comercial para sistemas, sistemas operativos, JDK, servidores de aplicación y aplicaciones corriendo sobre los mismos.

4. Mantenimiento. Al utilizar dependencias externas la compatibilidad de las versiones con servidores de aplicación, sistemas operativos y tecnología estándar no está certificada ni garantizada. Se obliga a desarrolladores a comprobar compatibilidad, esto se traduce en problemas no contemplados en entornos productivos repercutiendo en tiempos y costes asociados.

(7)

Nrm_JEE6_ArquitecturaReferencia_v01r00 Página 7 de 19 5. Ecosistema. El ecosistema de frameworks externos se basa módulos de librerías desarrollados por terceros.

Sin embargo, el ecosistema Java EE está comprometido por especificaciones de la Java Community Process (JCP), que incluye además de la comunidad a grandes proveedores (IBM, Oracle, Red Hat, Apache, etc.).

En base a todo lo anteriormente expuesto, desde el grupo de Desarrollo y Arquitectura Software se establece como norma obligatoria la adopción del estándar Java EE 6 o superior para nuevos desarrollos.

Por otro lado, la utilización de cualquier framework externo a la tecnología estándar deberá contar con la aprobación previa del grupo de Desarrollo y Arquitectura Software. Su utilización se hará en casos justificados y será necesario y obligatorio mantener el código fuente de estas dependencias externas en el repositorio de software habilitado para tal fin.

De forma adicional, será necesario aportar la documentación técnica que acredite la compatibilidad con el estándar propuesto y los diferentes componentes del ecosistema, como puede ser por ejemplo con el servidor de aplicaciones y servidor de base de datos. Todo ello, sin menoscabo de que el soporte y mantenimiento derivado de la utilización de componentes externos será, en todo caso, responsabilidad del proveedor de desarrollo.

2.2. Servidores de Aplicación

A continuación se listan servidores de aplicación compatibles y que cumplen con el estándar Java EE 6, pudiendo, por ello, ser utilizados para el desarrollo de aplicaciones:

 Oracle GlassFish Server 3.0

 Oracle WebLogic Server 12.1.3

 JBoss Application Server 7.x

Al margen de esto, es fundamental tener en cuenta que los entornos de preproducción y producción de la Subdirección de Tecnologías de la Información y Comunicaciones trabajan con servidores de aplicación Oracle WebLogic Server 12.1.3. Por ello, y para minimizar posibles problemas de compatibilidad o errores durante el despliegue y puesta en producción, se recomienda que los desarrollos se ejecuten en entorno similar.

2.3. Requisitos No Funcionales

Los requisitos no funcionales describen la calidad del servicio (Quality of Service, QoS) de un determinado sistema. El conjunto de tecnologías a utilizar en el desarrollo de un determinado proyecto deberá, obligatoriamente, ser consensuado con el grupo de Desarrollo y Arquitectura Software, y dependerá del estudio y análisis de los requisitos no funcionales que se especifican a continuación.

2.3.1. Disponibilidad

Es el grado en el que un sistema es operable. La disponibilidad de un sistema de información está íntimamente relacionada con el rendimiento.

Por ejemplo, una aplicación puede requerir de una disponibilidad a la semana con un ratio (tiempo total/intervalo) 100/168 = 0,998.

2.3.2. Confiabilidad

Es la habilidad de un determinado componente de realizar una función bajo condiciones de estado y periodo de tiempo especificados.

Por ejemplo, una aplicación puede requerir la tolerancia al fallo o la reparación sin corte de servicio.

2.3.3. Manejabilidad y Flexibilidad

(8)

Nrm_JEE6_ArquitecturaReferencia_v01r00 Página 8 de 19 Es el conjunto de servicios que aseguran la continua integridad de una aplicación. Esto incluye seguridad, control de concurrencia y gestión de servidor.

Por ejemplo, requisitos que son necesarios para parar o arrancar el servidor, como gestionar permisos de seguridad o instalación de nuevos componentes.

2.3.4. Rendimiento

Es la medida del tiempo de respuesta o el ratio de respuesta.

Por ejemplo, una aplicación puede requerir que el tiempo de respuesta no supere los 20’’.

2.3.5. Capacidad

Es la medida de un sistema para ejecutar múltiples tareas por unidad de tiempo.

Por ejemplo, la aplicación puede requerir una capacidad de 300 usuarios concurrentes.

2.3.6. Escalabilidad

Es una medida de la habilidad del hardware, software y recursos de infraestructura de crecer durante un periodo de tiempo determinado.

Por ejemplo, pueden existir requisitos de cara a mejorar la eficiencia de las comunicaciones, el pool de sesiones, pool de conexiones a base de datos o balanceo de carga.

2.3.7. Extensibilidad y Reusabilidad

Es la habilidad de añadir nueva funcionalidad sin impactar en el sistema actual y su operativa. Por su parte, la reusabilidad debe analizarse planteando mecanismos de encapsulación y bajo acoplamiento.

2.3.8. Seguridad

Se trata de una medida esencial para asegurar componentes de servicio y hacer que los datos sean apropiadamente gestionados. El objetivo de la seguridad es proteger recursos aplicando criterios de privacidad, integridad, autenticación, autorización y disponibilidad.

La definición de requisitos no funcionales de un determinado sistema de información deberá especificarse como norma obligatoria en la herramienta CASE utilizada para la toma de requisitos, análisis y diseño.

En base a estos requisitos habrá que plantear la posibilidad de cumplir, entre otros, con:

 Cacheo de datos.

 Publicación de Servicios Web o RESTful.

 Mensajería (JMS).

 Balanceo de carga.

 Integración con diferentes sistemas.

 Manejo de transacciones.

 Seguridad.

 Aplicación de patrones.

Esto condiciona enormemente el diseño del documento Descripción General de Entorno Tecnológico (DGT), necesario para solicitud de plataforma tecnológica RFP en el procedimiento de despliegue de nuevo aplicativo definido por la STIC.

(9)

3. Arquitectura

La aplicación del principio Separación de Problemas (SoC, Separation of Concerns) permite el estudio de cada uno de los componentes de un sistema de forma aislada. Es un principio fundamental en el diseño de sistemas complejos empresariales y de la programación Orientada a Objetos. Este principio aplicado al concepto de niveles o capas de una aplicación resulta en patrones de diseño como Model View Controller(MVC).

La arquitectura base propuesta por el grupo deDesarrollo y Arquitectura Software para aplicaciones con tecnología Java EE 6 o superior está basada en este principio, obteniendo la siguiente separación lógica por capas o niveles:

 Cliente, componente que maneja la representación de la información.

 Web o Presentación, nivel que consiste en servicios que manejan sesiones de usuario y navegación de peticiones y respuestas.

 Negocio, servicios que ejecutan lógica de negocio y manejan transacciones.

 Integración, nivel que provee servicios de acceso a recursos externos.

 Recursos, incluye bases de datos, sistemas antiguos (legacy), etc.

Figura 2. Separación lógica por capas o niveles.

En los desarrollos actuales esta separación lógica por capas o niveles se traduce en uso de diferentes patrones para dar respuesta a problemas de abstracción, encapsulación y modularidad. El resultado es la arquitectura (Figura 3) que presentan todas las aplicaciones actuales en el Servicio Andaluz de Salud.

Figura 3. Arquitectura Java J2EE actual por capas o niveles.

(10)

Nrm_JEE6_ArquitecturaReferencia_v01r00 Página 10 de 19 Como objetivo del grupo de Desarrollo y Arquitectura Software del Servicio Andaluz de Salud se plantea una profunda renovación tecnológica de esta arquitectura hacia un modelo de componentes (Figura 4) más productivo y que ofrezca mayor flexibilidad.

Figura 4. Arquitectura Java EE 6 por capas o niveles.

La base de esta arquitectura es la tecnología Context and Dependecy Injection (CDI). CDI ayuda a unir la capa de presentación y el nivel transaccional de la plataforma Java EE 6. CDI está compuesto por un conjunto de servicios que simplifican a los desarrolladores el uso de la tecnología EJB junto con la tecnología de presentación en aplicaciones web. CDI también tiene otros muchos usos, lo que permite a los desarrolladores una gran flexibilidad para integrar diversos tipos de componentes y tecnologías de forma desacoplada.

Esta pauta de diseño será de obligado cumplimiento, y cualquier excepción deberá ser consensuada con el grupo de Desarrollo y Arquitectura Software del Servicio Andaluz de Salud.

La adopción de esta nueva arquitectura presenta, entre otras, las siguientes ventajas:

 Simplificación de los desarrollos. La plataforma Java EE 6 proporciona un modelo de programación común para todos los tipos de componentes.

 Mejora en la productividad entorno al 30% gracias al uso anotaciones y a la reducción y simplificación de las configuraciones basadas en XML, primando el principio de Convención sobre Configuración.

 Arquitectura más escalable, accesible y manejable. Se delega en el servidor de aplicaciones servicios de bajo nivel como concurrencia, pools de conexiones, seguridad, transaccionalidad, etc.

(11)

4. Empaquetado, Diseño y Modularidad

4.1 Empaquetado

Las nuevas aplicaciones desarrolladas en tecnología Java EE deben entregarse como un archivo JAR (Java Archive), un archivo web WAR (Web Archive) o un archivo de empresa EAR (Enterprise Archive). Utilizando JAR, WAR y archivos EAR la tecnología Java permite desarrollar diferentes aplicaciones Java EE reutilizando los mismos componentes o módulos funcionales.

Desde el punto de vista del empaquetado y entrega de software, aquellos aplicativos que contengan módulos de aplicaciones cliente (cliente pesado) o módulos de adaptación a recursos específicos (adaptadores a sistemas antiguos) deberán ser obligatoriamente empaquetados como un fichero EAR según se muestra en la Figura 5.

Figura 5. Empaquetado EAR.

Para aquellos aplicativos que no cumplan lo anterior, es decir, para la mayoría de los desarrollos que se acometen en la STIC, el empaquetado debe corresponder obligatoriamente a un fichero WAR, cuya estructura se muestra en la Figura 6.

Figura 6. Estructura fichero WAR.

(12)

Nrm_JEE6_ArquitecturaReferencia_v01r00 Página 12 de 19 Cabe destacar en este sentido que, en que versiones anteriores de Java EE, solo era posible el empaquetado de la tecnología EJB en paquetes EAR. Sin embargo, esta es una de las muchas mejoras que ofrece esta nueva versión del estándar, siendo posible ahora hacerlo en paquetes WAR o JAR.

Por último, y aplicable al desarrollo de módulos comunes (como podría ser por ejemplo el módulo de integración con MACO), el empaquetado debe ser obligatoriamente como un archivo JAR, cuya estructura se muestra en la Figura 7. El objetivo con estos módulos comunes es ofrecer soluciones reaprovechables por otros proyectos.

Figura 7. Estructura fichero JAR.

4.2. Diseño y Modularidad

Los proyectos deben estar obligatoriamente estructurados de acuerdo a la herramienta de gestión de proyectos software Maven.

Tener una estructura común y estandarizada permite a desarrolladores trabajar de forma similar en cualquier proyecto, simplificando con ello el entendimiento del mismo. La estructura de un proyecto Maven debe cumplir, como mínimo, con la siguiente organización:

Figura 10. Estructura proyecto Maven.

(13)

Nrm_JEE6_ArquitecturaReferencia_v01r00 Página 13 de 19 En base a lo anterior se establece, como norma obligatoria, la estructuración basada en aplicaciones o módulos funcionales encapsulados como WARs (Web Archives) ofreciendo microservicios mediante fachadas JAX-RS (servicios RESTful) y JAX-WS (servicios Web).

Queda totalmente prohibido, por norma:

1. Establecer módulos independientes obedeciendo a capas lógicas.

2. Incluir como dependencia de un determinado proyecto código fuente de un tercero. Cualquier dependencia debe estar empaquetada y publicada en el repositorio de librerías corporativo, Artifactory.

La estructura del proyecto, además, debe obedecer a componentes de negocio, y no a tecnologías o patrones de diseño. En este sentido se establece como norma obligatoria la siguiente estructuración en orden descendente:

1. Estructura raíz de paquetes: es.ja.csalud.sas.<proyecto>.<aplicación>. Por ejemplo, es.ja.csalud.sas.diraya.vacunas

2. Separación por Capas Lógicas (Figura 8):

Figura 8. Separación por capas lógicas.

3. Separación por Componentes de Negocio (Figura 9):

Figura 9. Separación por componentes de negocio.

De esta forma, será posible la construcción de un catálogo de componentes comunes reutilizables para proyectos futuros.

Para la creación de cualquier nuevo proyecto, el equipo de desarrollo deberá partir de los arquetipos proporcionados por la STIC para JEE6 y JEE7. Para ello, será necesario proceder con la ejecución de uno de los siguientes comandos de generación en base a la tecnología a utilizar:

 Para Java EE 6

mvn archetype:generate -DarchetypeGroupId=es.ja.csalud.sas.base –DarchetypeArtifactId=javaee6archetype -DarchetypeVersion=1.0 -DgroupId= es.ja.csalud.sas.<proyecto> -DartifactId=<aplicación>

 Para Java EE 7

mvn archetype:generate -DarchetypeGroupId=es.ja.csalud.sas.base –DarchetypeArtifactId=javaee7archetype -DarchetypeVersion=1.0 -DgroupId= es.ja.csalud.sas.<proyecto> -DartifactId=<aplicación>

(14)

5. Patrones

Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Los patrones de diseño pretenden:

 Proporcionar catálogos de elementos reusables en el diseño de sistemas software.

 Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.

 Formalizar un vocabulario común entre diseñadores.

 Estandarizar el modo en que se realiza el diseño.

 Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

El uso de patrones se aconseja en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. Abusar o forzar el uso de los patrones puede ser un error.

Por otro lado la evolución de la tecnología Java ha deprecado la mayoría de los patrones que se venían aplicando con anterioridad a su versión Java EE 6.

Para los nuevos desarrollos iniciados dentro del marco de la presente normativa se propone la utilización de los siguientes patrones como base de la programación orientada a objetos y la división de problemas:

 SoC (Separation of Concerns).

 OOP (Object Oriented Programming).

 BCE (Boundary Control Entity).

La aplicación de cualquier otro patrón en el diseño de una nueva aplicación deberá ser justificada, consensuada y aprobada conjuntamente con el grupo de Desarrollo y Arquitectura Software, siempre en base a problemas específicos que surjan en las fases de análisis y diseño.

(15)

6. Pruebas

El desarrollo guiado por pruebas de software o Test-Driven Development (TDD) es una práctica de Ingeniería del Software que implica escribir las pruebas primero y refactorizar después. En primer lugar, se escribe una prueba y se verifica que la prueba falla. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito.

El propósito final de esta práctica es que los requisitos sean traducidos a pruebas, de modo tal que cuando el resultado de las pruebas sea satisfactorio quedará garantizado que el software cumple con los requisitos que hayan sido establecidos.

La aplicación de esta práctica redunda en:

 Creación de aplicaciones de mayor calidad.

 Cumplimiento de los requisitos especificados.

Si bien se trata de una forma de trabajo que debe asumir el proveedor en sus desarrollos, no pudiendo ser controlada ni automatizada por parte de la STIC, los nuevos desarrollos de aplicativos serán evaluados haciendo hincapié en esta práctica. Desde el grupo de Desarrollo y Arquitectura Software se controlará que, obligatoriamente:

1. La lógica de negocio del aplicativo esté soportado por pruebas unitarias.

2. Existan pruebas de integración entre capas como con sistemas o servicios externos (base de datos, servicios web, etc.).

3. Existan planes de prueba de rendimiento y estrés, así como su ejecución y resultado.

6.1. Pruebas Unitarias

En programación orientada a objetos, una prueba unitaria es una forma de comprobar el correcto funcionamiento de un método de un objeto.

Para que una prueba unitaria tenga la calidad suficiente se deben cumplir una serie de requisitos. La prueba debe ser:

 Automatizable. No debería requerirse una intervención manual.

 Completa. Deben cubrir la mayor cantidad de código.

 Repetible en el tiempo o reutilizable. No se deben crear pruebas que sólo puedan ser ejecutadas una sola vez.

 Independiente. La ejecución de una prueba no debe afectar a la ejecución de otra.

Para la programación de este tipo de pruebas se deberá hacer uso de los frameworksJUnit, Mockito y Arquillian.

6.2. Pruebas de Integración

Las pruebas de integración son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias. Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos.

Para la programación de este tipo de pruebas se deberá utilizar el framework Arquillian.

6.3. Pruebas de Rendimiento

Las pruebas de rendimiento son las aquellas que se realizan para determinar lo rápido que realiza una tarea un sistema en condiciones particulares de trabajo. También puede servir para validar y verificar otros atributos de la calidad del sistema, tales como la escalabilidad, fiabilidad y uso de los recursos.

Para la programación de este tipo de pruebas se deberán utilizar las herramientas JMeter y Selenium.

(16)

7. Ciclo de Vida del Software

Maven es una herramienta de software para la gestión y construcción de proyectos Java. Maven utiliza un Project Object Model (POM) para describir el proyecto de software a construir, sus dependencias de otros módulos y componentes externos, y el orden de construcción de los elementos.

La filosofía general de Maven es la estandarización de las construcciones generadas por seguir el principio de Convención sobre Configuración. Además Maven está construido alrededor de la idea de reutilización.

El ciclo de vida software de cualquier nuevo desarrollo en tecnología Java que se aborde en la STIC deberá manejarse obligatoriamente con Maven.

(17)

8. Artefacto

La STIC pone a disposición de los diferentes proveedores un artefacto para guiar los nuevos desarrollos. Este artefacto muestra pautas y principios de diseño y estructuración, así como ejemplos básicos de desarrollo y pruebas.

El artefacto irá evolucionando con casos prácticos que requieran ser modelados para el entorno y contexto del Servicio Andaluz de Salud.

Inicialmente este artefacto estará disponible para su descarga en UNIFICA, siendo obligatorio su uso.

(18)

9. Resumen de Pautas

Código Título Carácter

NRM.01 Utilización del estándar Java EE 6 o superior para el desarrollo de nuevos

aplicativos Obligatorio

NRM.02 Justificación de uso de frameworks externos Obligatorio

NRM.03 Justificación compatibilidad con el estándar propuesto Obligatorio

NRM.04 Mantenimiento en el repositorio de código fuente asociado a versiones

específicas de frameworks externos Obligatorio

NRM.05 Definición de requisitos no funcionales Obligatorio

NRM.06 Separación lógica por capas o niveles Obligatorio

NRM.07 Empaquetado y estructuración de aplicaciones como WARs (Web Archives) Obligatorio NRM.08 Estructura modular de proyectos en base a capas y módulos funcionales Obligatorio

NRM.09 Gestión de ciclo de vida de proyectos software mediante Maven Obligatorio

NRM.10 Aplicación de patrones de diseño para resolución de problemas Obligatorio

NRM.11 Entrega de pruebas unitarias, integración y rendimiento Obligatorio

(19)

10. Bibliografía y Referencias

Id Temática URL

1 Tecnologías Java EE 6 http://www.oracle.com/technetwork/java/javaee/tech/javaee6technologies- 1955512.html

2 Tutorial Java EE 6 http://docs.oracle.com/javaee/6/tutorial/doc/

3 Compatibilidad Servidores http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp- 136984.html

4 Maven http://maven.apache.org/index.html 5 Unifica https://ws001.juntadeandalucia.es/unifica/

6 Madeja http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/

7 TDD http://es.wikipedia.org/wiki/Desarrollo_guiado_por_pruebas 8 Patrones http://es.wikipedia.org/wiki/Patrón_de_diseño

Título Autor ISBN

Real World Java EE Patterns - Rethinking Best Practices Adam Bien 9781300149316