Download Metodología y Herramientas para el Desarrollo del Proyecto

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
mad@udc.es
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