1
Download Metodología y Herramientas para el Desarrollo del Proyecto
Document related concepts
no text concepts found
Transcript
UNIVERSIDADE DA CORUÑA Departamento de Tecnoloxías da Información e as Comunicacións (TIC) Diseño e Implementación de una Aplicación Web Java EE con Arquitectura MVC Generalidades PFC3 Manuel Álvarez Díaz http://www.tic.udc.es/~mad [email protected] Diciembre 2006 Índice • Enfoque para el Proyecto • Generalidades Metodología Proceso Unificado Estándar de Codificación Java • Generalidades Herramientas Características Java SE 5.0 Apache Ant Apache Maven 2 IDE Eclipse JUnit • Visión Rápida de Tecnologías J2EE – (documentación de IS) Instalación de Ejemplos de Integración de Sistemas Tutorial de JDBC - MiniBank Tutorial de XML Tutorial de Tecnologías Web (MVC & Apache Struts) - MiniPortal Diciembre 2006 Generalidades PFC3 2 Enfoque para el Proyecto • Para la realización de la aplicación software del proyecto se aconseja un enfoque basado en iteraciones, de manera que cada iteración incorpora más funcionalidad, hasta que en la última iteración se termina con un software que implementa toda la funcionalidad. En cada iteración se hace análisis, diseño, implementación y pruebas . Enfoque opuesto al concepto tradicional de analizar todo, diseñar todo, implementar y probar todo. • Se divide el problema en iteraciones, y en cada iteración se hace todo el ciclo de vida tradicional. En la primera iteración se aborda lo más complicado, intentando obtener en poco tiempo una arquitectura software que permitirá incorporar el resto de la funcionalidad en subsiguientes iteraciones – “línea base” • Objetivo: detectar problemas de diseño y/o implementación cuanto antes, y no al final, cuando ya sería demasiado costoso (en tiempo y dinero) refactorizar todo el diseño y el código. El resto de las iteraciones van introduciendo funcionalidad menos crítica, y no deberían causar cambios importantes a la línea base. • Los procesos de desarrollo de software actuales (eXtreme Programming, Proceso Unificado de Desarrollo de Software, etc.), usan un enfoque iterativo similar a éste. Diciembre 2006 Generalidades PFC3 3 Estándar de Codificación • Normalmente en proyectos grandes se suele seguir un estándar de codificación, de manera que el aspecto del código sea el mismo, independientemente de qué programador lo haya escrito Facilita el mantenimiento del software • Código de calidad y fácilmente legible • Un estándar de codificación define: Reglas para nombrar clases, atributos y métodos, normas de identación, etc. • Un documento muy sencillo (breve), pero muy utilizado en el mundo Java son las Java Code Conventions, definidas por Sun Microsystems. http://java.sun.com/docs/codeconv/index.html Diciembre 2006 Generalidades PFC3 4 Herramientas • Modelado UML MagicDraw (instalado en Laboratorios de Docencia FIC) Poseidon for UML Rational Rose • Desarrollo HTTP/HTML/XML/CSS Java EE 5.0 + Apache Struts 1.2.9 + TagLibs 1.1.2 + JUnit 4.1 Apache Maven 2 IDE Eclipse Otras: AJAX, Hibernate, EJB3, Spring, Apache Shale, ... • Bases de Datos MySQL 4.x/5.x ó PostgreSQL 7.x/8.x • Servidor Web Apache Tomcat 5.5.x Diciembre 2006 Generalidades PFC3 5 Arquitectura del Sistema Capa 1 Navegador Capa 2 Int. Modelo web Capa 3 Base de datos Serv. ap. web Navegador Internet/ Intranet Navegador Diciembre 2006 Generalidades PFC3 6 Capas de una Aplicación Web Java EE: MVC+Layers HTML/CSS + JSP + JSTL Vista Controlador Apache Struts ActionForm + Action Factory Interfaces con Casos de Uso (lógica de negocio) Modelo Business Delegate Session Facade CTO Plugin: Plain | RMI | EJB | … Factory Interfaces para Acceso a Datos DAO/TO Plugin: JDBC | XML | … Diciembre 2006 Generalidades PFC3 7 UNIVERSIDADE DA CORUÑA Departamento de Tecnoloxías da Información e as Comunicacións (TIC) Generalidades Metodología Introducción al Proceso Unificado El proceso Unificado de Desarrollo de Software. Ivar Jacobson, Grady Booch, James Rumbaugh. Addison Wesley, 2001. Java Code Conventions Sun Microsystems, Java Code Conventions,http://java.sun.com/docs/codeconv/index.html. Introducción al Proceso Unificado • Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software: Requisitos del usuario • Proceso Procesode dedesarrollo desarrollo de deSoftware Software Sistema software Proceso Unificado: Más que un proceso de desarrollo de software Marco de trabajo genérico que puede especializarse para una gran variedad de sistemas software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto. Basado en componentes software, interconectados a través de interfaces bien definidas Utiliza el Lenguaje Unificado de Modelado (Unified Modeling Language, UML) para preparar todos los esquemas de un sistema software Diciembre 2006 Generalidades PFC3 9 Introducción al Proceso Unificado • Orígenes Modelo original Objectory definido por Ivan Jacobson (1987) Rational Software compra la empresa de Objectory (1995) Surge la primera versión de UML (1997) Se publica la primera versión del Proceso Unificado de Rational RUP (junio 1998) • Características del Proceso Unificado Dirigido por casos de uso Centrado en la Arquitectura Iterativo e incremental Diciembre 2006 Gui Generalidades PFC3 gos s e i r or p o d a 10 Introducción al Proceso Unificado • Dirigido por Casos de Uso Se centra en la funcionalidad que el sistema debe poseer para satisfacer las necesidades de un usuario (persona, sistema externo, dispositivo) que interactúa con él Casos de uso como el hilo conductor que orienta las actividades de desarrollo Casos de Uso <<defineNecesidades>> Análisis Recopilar, Clarificar y Validar los requisitos Diciembre 2006 <<realiza>> <<verifica>> Diseño Pruebas Realizar los casos de uso Verificar que se satisfacen los casos de uso Generalidades PFC3 11 Introducción al Proceso Unificado • Centrado en la Arquitectura Concepto similar a la arquitectura de un edificio • Varios planos con diferentes aspectos del edificio • Tener una imagen completa del edificio antes que comience la construcción Arquitectura en software • Diferentes vistas del sistema: estructural, funcional, dinámico, etc. • Plataforma en la que va a operar • Determina la forma del sistema Arquitectura: determina la forma del sistema Casos de uso: determinan la función del sistema Diciembre 2006 Generalidades PFC3 12 Introducción al Proceso Unificado • Iterativo e Incremental Descomposición de un proyecto grande en mini-proyectos Cada mini-proyecto es una iteración Las iteraciones deben estar controladas Cada iteración trata un conjunto de casos de uso • Ventajas del enfoque iterativo Detección temprana de riesgos Administración adecuada del cambio Mayor grado de reutilización Mayor experiencia para el grupo de desarrollo • Guiado por riesgos Se detectan los riesgos graves para asegurarlos lo antes posible. El objetivo es detectar los problemas lo antes posible para darles solución rápidamente. Diciembre 2006 Generalidades PFC3 13 Rational Unify Process (RUP) - Dimensiones • Estática - Flujos de trabajo • Roles Actividades Artefactos Flujo de Trabajo QUIÉN? CÓMO? QUÉ? CUÁNDO? Dinámica El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. • Ciclo: cada ciclo una nueva versión del producto • Fase: Etapas de un ciclo que finalizan en un HITO • Iteración: Proceso de ingeniería sobre una funcionalidad limitada del sistema En cada fase se realizan una o más iteraciones a través de los flujos de tareas: requisitos no procedimentales (de eficiencia) y casos de uso, Análisis (opcional), Diseño, Implementación y Pruebas. • Entradas al proceso: Lista de características: descripción informal (2 páginas) de lo que se espera del desarrollo. Modelo de dominio (Opcional). Modelar con UML el entorno en el que operará el producto. Diciembre 2006 Generalidades PFC3 14 Dimensión Estática del Proceso • Rol Definición del comportamiento y responsabilidades de los participantes Propietario de una serie de artefactos • Actividad Unidad de trabajo que puede ejecutar un individuo en un rol específico Tiene un propósito claro y se expresa en términos de “actualizar” artefactos La granularidad de la actividad es generalmente de horas o pocos días Ejemplos de actividades • Planear una iteración (administrador del proyecto) • Encontrar caso de uso y actores (analista del dominio) • Revisión del diseño (probador) Diciembre 2006 Generalidades PFC3 15 Dimensión Estática del Proceso • Artefacto Pieza de información producida, modificada y utilizada en un proceso Productos tangibles del proyecto Utilizados por los roles como entrada para la realización de sus actividades Resultado de las actividades realizadas por los roles • Flujo de Trabajo Forma de describir la secuencias de actividades que producen resultados y las interacciones entre cargos En términos de UML se puede utilizar: diagrama de actividades, de secuencia, de colaboración Diciembre 2006 Generalidades PFC3 16 Dimensión Dinámica del proceso ciclo fase Concepción Elaboración hito 1 Iter. 1 hito 2 Iter. 2 Construcción hito 3 Iter. 3 Iter. 4 Iter. 5 Transición hito 4 Iter. 6 Hito: punto en el tiempo donde se evalúan los objetivos logrados y se pueden tomar decisiones críticas Diciembre 2006 Generalidades PFC3 17 Desarrollo Iterativo Construcción Iteración de desarrollo 1 Análisis Diciembre 2006 Iteración de desarrollo 2 Iteración de desarrollo n Perfeccionar el plan Sincronizar Artefactos Diseño Implementación Generalidades PFC3 Pruebas 18 Fase de Concepción • Objetivo: Definir la razón de ser y el alcance del proyecto. Estudio de oportunidad. Visión = QUÉ + PARA QUÉ + CUÁNTO • Actividades Especificación de los criterios de éxito del proyecto Definición de los requisitos Estimación de los recursos necesarios Cronograma inicial de fases • Artefactos Documento de definición del proyecto Diciembre 2006 Generalidades PFC3 19 Fase de Elaboración • • Objetivo: Establecer un plan de proyecto y una arquitectura correcta del sistema Actividades • Artefactos • Análisis del dominio del problema Definición de la arquitectura básica Análisis de riesgos Planificación del proyecto Modelo del dominio Modelo de procesos Modelo funcional de alto nivel Arquitectura básica Al final de la fase de elaboración se establece la línea base de la arquitectura. Los riesgos de la lista de riesgos están mitigados (con solución, implementada o no). En realidad, además de la línea base de la arquitectura también se habrán implementado aquellos elementos necesarios asociados a los casos de uso de la línea base, pero que no son críticos (no existían dudas para su realización). Diciembre 2006 Generalidades PFC3 20 Fase de Construcción / Transición • Construcción Objetivo: Desarrollar el sistema a lo largo de una serie de iteraciones Actividades • Análisis • Diseño • Implementación / Codificación – El flujo de tareas de implementación se divide en Builds: consolidación del trabajo de los desarrolladores (punto de encuentro del trabajo de varios diseñadores). • Pruebas (individuales, de integración) • Transición: Pruebas beta (de usuario). Diciembre 2006 Generalidades PFC3 21 Ciclo de Vida del Proceso Unificado Ágil - AUP Diciembre 2006 Generalidades PFC3 22 Resumen Java Code Conventions ... • Extensiones de ficheros: .java, .class • Un fichero por clase pública o interfaz Puede incluir clases privadas, pero siempre después de la pública • Estructura de un fichero con código fuente Comentarios de inicio /* * Classname, Programmer(s), Date * Version info * Copyright notice * Description */ Paquete y lista de imports necesarios Declaración de clase o interfaz Diciembre 2006 Generalidades PFC3 23 Resumen Java Code Conventions ... • Estructura de un fichero con código fuente (continuación) Declaración de clase o interfaz • • • • /** ... */ Comentario Javadoc de Clase o Interfaz Declaración “class” o “interface” /* ... */ Comentario de implementación, si es necesario Variables de Clase (static) – public > protected > private • Variables de instancia – public > protected > private • Constructores • Métodos – • • • Agrupados por funcionalidad para facilitar el entendimiento del código. Identación, 4 espacios (con algunas excepciones para mejorar legibilidad). Longitud de línea como mucho 80 caracteres División de líneas: después de una coma antes de un operador dar preferencia a divisiones de nivel superior alinear la nueva línea con el comienzo de la expresión del mismo nivel en la línea anterior si al aplicar estas reglas el código queda poco legible, utilizar 8 espacios Diciembre 2006 Generalidades PFC3 24 Resumen Java Code Conventions ... • Comentarios: Javadoc /** ... */, Bloque/línea /* ... */, Fín de línea // ... • Declaraciones Una por línea Definir variables al comienzo de bloques “{ }” (más claro) e inicializarlas cuando se definen si es posible • Excepción: bucles for Evitar declaraciones locales para ocultar declaraciones de niveles superiores Clases e interfaces • No utilizar espacio entre el nombre del método y el paréntesis de inicio de lista de parámetros • La llave de inicio aparece al final de la línea de declaración de la sentencia • La llave de fin aparece al comienzo de línea, identada con el inicio de la sentencia que cierra – Excepción: métodos vacíos Æ {} • Los métodos se separan por una línea en blanco Diciembre 2006 Generalidades PFC3 25 Resumen Java Code Conventions ... • Sentencias Una por línea Sentencias compuestas Æ entre “{}” • Sentencias incluidas deben de ser identadas • “{“ aparecerá al final de la línea de inicio del bloque; y “}” al principio de línea, identado con el inicio del bloque. • En sentencias if-then-else o bucles, se utilizará siempre “{}” aunque el bloque esté compuesto por una sola sentencia – Esto facilita el mantenimiento del código (por ejemplo, si en el futuro se añade una nueva línea al bloque, el programador podría olvidarse de añadir las llaves} Sentencias “return” • No deben especificarse entre paréntesis, salvo por claridad. Sentencias • if, for, while, do/while, switch, try/catch Diciembre 2006 Generalidades PFC3 26 Resumen Java Code Conventions ... if (condition) { statements; } for (initialization; condition; update) { statements; } if (condition) { statements; } else { statements; } for (initialization; condition; update); if (condition) { statements; } else if (condition) { statements; } else if (condition) { statements; } while (condition) { statements; } while (condition); do { statements; } while (condition); try { statements; } catch (ExceptionClass e) { statements; } finally { statements; } Diciembre 2006 Generalidades PFC3 switch (condition) { case ABC: statements; /* falls through */ case DEF: statements; break; case XYZ: statements; break; default: statements; break; } 27 Resumen Java Code Conventions ... • Líneas en blanco (dos) • Entre secciones de un fichero fuente • Entre definiciones de clases e interfaces • Líneas en blanco (una) • • • • Entre métodos Entre definición de variables locales y la primera sentencia Antes de un comentario de bloque o de línea Entre secciones lógicas de un método • Espacios en blanco Antes de un paréntesis, salvo que sea la invocación de un método Después de una coma, en una lista de argumentos Para separar los operandos de todos los operadores binarios excepto “.”. No aplicable a operadores unarios Para separar las expresiones de una sentencia for Los casts deben de ir seguidos por un espacio Diciembre 2006 Generalidades PFC3 28 Resumen Java Code Conventions ... • Convenciones de nombrado (nombres representativos) Clases • Deben de ser nombres, con la primera letra de cada palabra involucrada en ese nombre, en mayúsculas. Interfaces • Ídem clases Métodos • Deben de ser verbos, con la primera letra de cada palabra involucrada en mayúsculas, salvo la de la primera. Variables • Palabras, con la primera letra de cada palabra involucrada en mayúsculas, salvo la de la primera. • Nombres comunes para variables temporales son i,j,k (numéricas) c,d,e (caracteres) Constantes • En mayúsculas, separando cada palabra involucrada en el nombre por el carácter subrayado “_”. Paquetes (no incluido en Java Code Conventions) • Palabras simples y en minúsculas. Diciembre 2006 Generalidades PFC3 29 Resumen Java Code Conventions ... • Prácticas de Programación (salvo casos justificados) Variables de clase o instancia no deben de ser públicas Evitar acceder a variables de clase desde instancias de objetos. Las constantes numéricas deben de definirse previamente en lugar de utilizarlas como literales (salvo inicializaciones como -1, 0, 1) Asignación de variables • Evitar asignaciones múltiples en la misma sentencias (difícil de leer) • No utilizar el operador de asignación en lugares en los que pueda ser fácilmente confundido con el operador de igualdad • No utilizar asignaciones embebidas para intentar optimizar la ejecución: Esa es tarea del compilador Es buena práctica utilizar paréntesis en expresiones que combinan múltiples operadores, aunque no sean necesarios por las reglas de precedencia de los mismos. Estructurar el programa de forma que sólo haya una sentencia return. En sentencias con “?”, si la expresión condicional contiene un operador binario, es recomendable ponerlo entre paréntesis. Comentarios especiales • XXX – Marca algo que tiene algún problema pero funciona • FIXME – Marca algo como que no funciona correctamente • TODO – Marca algo como que está por terminar Diciembre 2006 Generalidades PFC3 30 Java Code Conventions ... Ejemplo /* * Firstname Lastname * * Copyright (c) 1993-1996 Sun Microsystems, Inc. All Rights Reserved. * */ package java.blah; import java.blah.blahdy.BlahBlah; /** * Class description goes here. * * @version 1.10 04 Oct 1996 * @author Firstname Lastname */ public class Blah extends SomeClass { /* A class implementation comment can go here. */ /** classVar1 documentation comment */ public static int classVar1; /** * classVar2 documentation comment that happens to be * more than one line long */ private static Object classVar2; /** instanceVar1 documentation comment */ public Object instanceVar1; Diciembre 2006 Generalidades PFC3 31 Java Code Conventions ... Ejemplo /** instanceVar2 documentation comment */ protected int instanceVar2; /** instanceVar3 documentation comment */ private Object[] instanceVar3; /** * ...method Blah documentation comment... */ public Blah() { // ...implementation goes here... } /** * ...method doSomething documentation comment... */ public void doSomething() { // ...implementation goes here... } /** * ...method doSomethingElse documentation comment... * @param someParam description */ public void doSomethingElse(Object someParam) { // ...implementation goes here... } } Diciembre 2006 Generalidades PFC3 32 UNIVERSIDADE DA CORUÑA Departamento de Tecnoloxías da Información e as Comunicacións (TIC) Generalidades Herramientas Características Java SE 5.0 Herramientas de Gestión de Proyectos Software Ant Maven 2 IDE Eclipse Pruebas de Aplicaciones Software JUnit Características Java SE 5.0 • Generics - Mejora en el sistema de tipos. Añade comprobación de tipos en tiempo de compilación para el framework de collections y elimina los castings. • • Bucle for - Facilidad en iteraciones sobre arrays y colecciones. Autoboxing/Unboxing Elimina la conversión manual entre tipos primitivos (int) y los tipos envoltorio correspondientes (Integer). • • • Typesafe Enums - Tipos enumerados orientados a objetos. Varargs - Métodos con número de argumentos variable. Static Import Acceso no calificado a miembros estáticos de un tipo sin heredar de él. • Annotations - Posibilidad de anotar el código fuente. Posibilita que herramientas generen código a partir de las anotaciones. Diciembre 2006 Generalidades PFC3 34 Gestión de Proyectos: Apache Ant (1) • Herramienta del tipo de make (gnumake, nmake ...) Open Source - Proyecto Apache (http://ant.apache.org) Desarrollada en Java. Otras herramientas existentes. • Shell-based – Ejecutan comandos específicos del sistema operativo Æ (no reutilizables en diferentes plataformas). – Formatos 'estrictos' (ej. tabuladores en Makefiles) Ant es más portable. • Las tareas son ejecutadas por clases Java. Solo requiere una MV Java 1.1 o superior (Reutilizable en diferentes plataformas) • Existe una tarea que permite ejecutar comandos basados en el SO utilizado. • Utiliza ficheros de configuración XML (project, targets, tasks). • Ejecución de ant Por defecto busca el fichero build.xml en el directorio actual. Se pueden especificar uno o más targets a ejecutar. Por defecto ejecuta el target indicado en el atributo default de la etiqueta <project >. » ant [<target>]* Diciembre 2006 Generalidades PFC3 35 Gestión de Proyectos: Apache Ant – build.xml (2) <project name="MyProject" default="dist" basedir="."> Propiedades <!-- set global properties for this build --> <property name="src" value="."/> <property name="build" value="build"/> <property name="dist" value="dist"/> <target name="init"> <!-- Create the time stamp --> <tstamp/> <!-- Create the build directory structure used by compile --> <mkdir dir="${build}"/> </target> <target name="compile" depends="init"> <!-- Compile the java code from ${src} into ${build} --> <javac srcdir="${src}" destdir="${build}"/> </target> Targets <target name="dist" depends="compile"> <!-- Create the distribution directory --> <mkdir dir="${dist}/lib"/> <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file --> <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/> </target> <target name="clean"> <!-- Delete the ${build} and ${dist} directory trees --> <delete dir="${build}"/> <delete dir="${dist}"/> </target> </project> Diciembre 2006 Generalidades PFC3 36 Estructura de los Ejemplos de Integración de Sistemas (5ºII) - J2EE_EXAMPLES_HOME ConfigurationParameters.properties ServiceLocatorJNDIInitialContext.properties CommonEnvironmentVariables.{bat,sh} build.xml CommonPathReferences.xml CommonProperties.xml MySQLCreateTables.sql PostgreSQLCreateTables.sql build.xml Diciembre 2006 Generalidades PFC3 37 Ficheros build.xml de los Ejemplos • build.xml global a todos los subsistemas. • • all compile (default) ears init initdb jars javadoc rebuild sourcedist wars NOTA Cada fichero build.xml incluye los ficheros CommonProperties.xml y CommonPathReferences.xml del directorio Subsystems. Los targets del fichero build.xml general enlazan a los targets equivalentes en los build.xml de cada subsistema particular. ant –projecthelp muestra los targets que define un fichero build.xml Diciembre 2006 build.xml de un Subsistema particular (MiniBank) clean cleanclasses compile (default) deployejbear deployplainwar deployrmiwar ears ejbear ejbmodeljar ejbwar entitiesjar init jars javadoc plainwar rebuild rmijars rmiwar wars TestAccountFacadeDelegateFactory Generalidades PFC3 38 Gestión de Proyectos: Maven 2 (1) • Herramienta de Gestión de proyectos Software Open Source; Proyecto Apache (http://maven.apache.org) • Maven es una herramienta de más alto nivel que Ant: Ant – enfoque basado en tareas • Crear el script build con las tareas a ejecutar • Ejecutar los targets Maven – enfoque declarativo • Describir el proyecto y configurar plugins • Ejecutar plugins existentes (goals) • Núcleo de Maven - POM – Project Object Model Contiene una descripción detallada del proyecto, incluyendo información de versiones, gestión de configuración, dependencias, recursos de la aplicación y de pruebas, miembros del equipo, ... Fichero XML situado en el directorio raíz del proyecto Æ pom.xml Diciembre 2006 Generalidades PFC3 39 Gestión de Proyectos: Maven 2 (2) • Estandarización de prácticas de gestión de proyectos No se pierde tiempo reinventando estructuras de directorios, convenciones ni personalizando scripts build.xml de ant para cada proyecto. Maven permite redefinir la estructura de directorios estándar pero es conveniente respetarla por las siguientes razones: • El fichero pom.xml será más pequeño y sencillo. • Hace que el proyecto sea más fácil de entender y facilita el mantenimiento futuro por otros. • Facilita la integración de plug-ins (asumen también la estructura por defecto) Diciembre 2006 Generalidades PFC3 40 Gestión de Proyectos: Maven 2 – pom.xml (3) <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>es.udc.fbellas.j2ee</groupId> <artifactId>standardutil</artifactId> <packaging>jar</packaging> <version>2.1.1</version> <name>J2EE-Examples Standard Util Subsystem</name> <url>http://www.tic.udc.es/~fbellas/teaching/is</url> <dependencies> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.0.4</version> <scope>test</scope> </dependency> </dependencies> </project> Diciembre 2006 Generalidades PFC3 41 Gestión de Proyectos: Maven 2 – Ciclo de Vida (4) • Ciclo de vida de un proyecto Fases de construcción de un proyecto como “compile”, “test”, “deploy” • En Ant se crean “targets” con esos nombres que implementen esa semántica • En Maven 1 se invocan plugins (goals) existentes – Un lenguaje de Scripting basado en XML, Jelly, permitía definir nuevos goals o modificar el comportamiento de los existentes. • En Maven 2 se estandariza el conjunto de fases del ciclo de vida del proyecto, y al ejecutar una de ellas se ejecutarán los plugins correspondientes – Es posible implementar nuevos plugins a asociar a las diferentes fases, como clases Java. Para compilar: mvn compile Diciembre 2006 Generalidades PFC3 42 Gestión de Proyectos: Maven 2 – Dependencias (4) • En el fichero pom.xml se definen los recursos de los que depende un proyecto Maven automáticamente descarga los recursos de repositorios remotos en repositorios locales • Local a la máquina (estructura de directorios en base al groupid y artifactid del recurso) – Maven 1 Æ HOME/.maven/repository – Maven 2 Æ HOME/.m2/repository • Gestión de Dependencias Transitivas Maven 1 obliga a que cada proyecto defina todos los jars necesarios, directa o indirectamente por la aplicación. Con Maven 2 sólo es necesario especificar los jars que la aplicación necesita de forma directa; Maven 2 gestiona las dependencias de las librerías utilizadas, para incluirlas de forma automática. • Ámbitos de Dependencias – en función de las fases (Maven 2) compile Æ necesaria en todas las fases (valor por defecto) provided Æ necesaria para compilar pero no para deployar (e.g. servlet API). runtime Æ necesaria sólo para ejecutar (e.g. JDBC drivers). test Æ necesaria sólo para pruebas (e.g. Junit API). Diciembre 2006 Generalidades PFC3 43 Estructura de los Ejemplos de IS migrados a Maven 2 pom.xml MySQLCreateTables.sql PostgreSQLCreateTables.sql ConfigurationParameters.properties Diciembre 2006 Generalidades PFC3 44 Eclipse IDE (http://www.eclipse.org) Compile Run Debug Plugins - Ant - Maven 2 - Tomcat -… n o i dit E itors t c je ... ed ro, SQL, P ls L o PX, XM o b T P, JS rer WeTML, aJSse explo - H tab a -d . - .. Diciembre 2006 Generalidades PFC3 45 Pruebas de Unidad • ¿Qué es una prueba de unidad? - Definición de IEEE Prueba individual de hardware o software, o grupos de unidades relacionadas • Normalmente, un test de unidad es un código que prueba una “unidad”: que puede ser una clase, un componente, un módulo o una función. • Las pruebas se crean y se ejecutan mientras se desarrolla el software. • Las pruebas de unidad no son pruebas funcionales, de aplicación. • Las pruebas de unidad no son interactivas. • Un Framework de pruebas de unidad proporciona: Un mecanismo para organizar y agrupar varios tests Una forma sencilla de invocar tests Un indicación clara de qué tests han sido exitosos o fallidos. Una forma estándar para escribir tests y especificar resultados esperados. En general, el objetivo de las pruebas de unidad es comprobar que los diferentes componentes del SW funcionan de forma aislada y que ante cambios en el código continuan funcionando. Diciembre 2006 Generalidades PFC3 46 ¿Qué es Junit? • JUnit es un framework para escribir pruebas de unidad repetibles en Java. http://www.junit.org/ Open Source Programado por Erich Gamma y Kent Beck • Características Utiliza aserciones para comprobar resultados esperados Test Suites para organizar y ejecutar tests Runners de tests gráficos y textuales Diciembre 2006 Generalidades PFC3 47 Framework JUnit junit.framework << interface >> Test Assert run() assertTrue() assertEquals() ... TestResult TestCase fName setUp() runTest() tearDown() run() junit.textui.TestRunner Diciembre 2006 * TestSuite run() addTest() junit.swingui.TestRunner Generalidades PFC3 48 Junit - Pruebas de Unidad junit TestCase App 1..* TestApp TestRunner 1..* run test1 test2 … Diciembre 2006 Generalidades PFC3 49 Junit - Pruebas de Unidad • Creación de prueba: Crear una subclase de junit.framework.TestCase Escribir un método de pruebas • public void testXXX() [throws …] • Pueden realizarse varias comprobaciones (aserciones) por método Escribir un método “suite”, que utiliza introspección para crear de forma dinámica un grupo de casos de prueba conteniendo todos los métodos testXXX(). public static Test suite() { return new TestSuite (SimpleTest.class); } Escribir un método main() para ejecutar el test con el ejecutor en modo texto public static void main(String args[]) { junit.textui.TestRunner.run(suite()); } Diciembre 2006 Generalidades PFC3 50 Assert • La clase Assert proporciona un conjunto de métodos estáticos para realizar comprobaciones Pueden lanzar un objeto con mensajes de fallo • Los mensajes sólo se muestran cuando un assert falla • Assert.assertEquals(Object, Object) Æ Compara utilizando el método "equals". Si no se redefine, el método equals de un Object realiza una comparación por referencia; es necesario redefinir el método equals de una clase para la que se desee comparación por contenido. • Clases como String lo tienen redefinido Î comparan por contenido. Debería redefinirse el método equals en la clase con la que comparar igualdad (que haría la igualdad atributo a atributo), en lugar de utilizar el método toString. • Dependiendo de cómo esté implementado, el método toString podría dar igual para dos objetos que no lo fuesen realmente. • Las clases que implementan las pruebas suelen implementarse en el mismo paquete que la clase que prueban, pero en un directorio de fuentes diferente. Diciembre 2006 Generalidades PFC3 51 Inicialización y Borrado de Datos de Prueba • La idea de hacer las pruebas con JUnit es que sean "pruebas automáticas". • Por tanto, cuando se ejecute, debe hacer con anterioridad todo lo que sea necesario y con posterioridad restaurar el estado inicial. protected void setUp() { // initialization code } protected void tearDown() { // cleanup code } • Creación de Grupos de pruebas public static Test suite() { TestSuite suite = new TestSuite(); suite.addTest(SomeTest.suite()); suite.addTest(AnotherTest.suite()); return suite; } Diciembre 2006 Generalidades PFC3 52 Ejecución de un Caso de Prueba • Ejecución en modo texto ... • Ejecución mediante interfaces gráficas • java junit.textui.TestRunner <testCaseClass|testSuiteClass> java junit.swingui.TestRunner <testCaseClass|testSuiteClass> Ejecución desde ant, con la tarea "junit" (OPTIONAL-TASK => necesario añadir junit.jar al directorio lib de ant) <junit> <test name="my.test.TestCase"/> </junit> <junit printsummary="yes" fork="yes“ haltonfailure="yes"> <formatter type="plain"/> <classpath path="."/> <test name="my.test.TestCase"/> </junit> • NOTA: Con EJBs el TestRunner Swing falla; debe utilizarse el TestRunner en modo consola de texto para evitar problemas. Diciembre 2006 Generalidades PFC3 53 JUnit 4.0 o superior y Anotaciones (1) • Requiere Java SE 5.0. • Cases de prueba no tienen que extender junit.framework.TestCase. • Métodos de prueba no tienen que prefijarse con 'test'. • No hay cambios entre los métodos assert antiguos y los nuevos. • Utiliza anotaciones @Test para marcar un método como un caso de prueba. • Utiliza anotaciones @Before y @After para definir los métodos a ejecutar antes y después de la ejecución de cada prueba. • Utiliza anotaciones @BeforeClass y @AfterClass para definir los métodos a ejecutar antes y después de la ejecución del conjunto de pruebas de una clase Diciembre 2006 Generalidades PFC3 54 JUnit 4.0 o superior y Anotaciones (1) • Las anotaciones @Test pueden incluir el parámetro timeout. El test falla si tarda más de ese tiempo en ejecutarse. • Las anotaciones @Test pueden incluir un parámetro que especifique el tipo de excepción a lanzar para que sea exitoso. • JUnit4Adapter habilita la ejecución de los nuevos tests JUnit4 con “runners“ antiguos. • El nuevo “runner” puede ejecutar tests JUnit "antiguos". • ... Diciembre 2006 Generalidades PFC3 55 Referencias • Asignatura “Integración de Sistemas”. Facultade de Informática. Universidade da Coruña • http://www.tic.udc.es/~fbellas/teaching/is • Asignatura “Proyecto de Fin de Carrera”. Facultade de Informática. Universidade da Coruña • http://www.tic.udc.es/~mad/teaching/pfc3 Diciembre 2006 Generalidades PFC3 56
