Arquitectura MVC

UNIVERSIDADE DA CORUA
Departamento de Tecnoloxas da Informacin e as Comunicacins (TIC)

Diseo e Implementacin de una Aplicacin
Web Java EE con Arquitectura MVC
Manuel lvarez Daz
http://www.tic.udc.es/~mad
mad@udc.es
Diciembre 2006
Generalidades PFC3
Diciembre 2006 Generalidades PFC3 2
ndice
Enfoque para el Proyecto
Generalidades Metodologa
Proceso Unificado
Estndar de Codificacin J ava
Generalidades Herramientas
Caractersticas J ava SE 5.0
Apache Ant
Apache Maven 2
IDE Eclipse
J Unit
Visin Rpida de Tecnologas J 2EE (documentacin de IS)
Instalacin de Ejemplos de Integracin de Sistemas
Tutorial de J DBC - MiniBank
Tutorial de XML
Tutorial de Tecnologas Web (MVC & Apache Struts) - MiniPortal
Enfoque para el Proyecto
Para la realizacin de la aplicacin software del proyecto se aconseja
un enfoque basado en iteraciones, de manera que cada iteracin
incorpora ms funcionalidad, hasta que en la ltima iteracin se
termina con un software que implementa toda la funcionalidad.
En cada iteracin se hace anlisis, diseo, implementacin y pruebas .
Enfoque opuesto al concepto tradicional de analizar todo, disear todo,
implementar y probar todo.
Se divide el problema en iteraciones, y en cada iteracin se hace todo
el ciclo de vida tradicional.
En la primera iteracin se aborda lo ms complicado, intentando obtener
en poco tiempo una arquitectura software que permitirincorporar el
resto de la funcionalidad en subsiguientes iteraciones lnea base
Objetivo: detectar problemas de diseo y/o implementacin cuanto antes, y no
al final, cuando ya sera demasiado costoso (en tiempo y dinero) refactorizar
todo el diseo y el cdigo.
El resto de las iteraciones van introduciendo funcionalidad menos crtica,
y no deberan causar cambios importantes a la lnea base.
Los procesos de desarrollo de software actuales (eXtreme
Programming, Proceso Unificado de Desarrollo de Software, etc.),
usan un enfoque iterativo similar a ste.
Estndar de Codificacin
Normalmente en proyectos grandes se suele seguir un
estndar de codificacin, de manera que el aspecto del
cdigo sea el mismo, independientemente de qu
programador lo haya escrito
Facilita el mantenimiento del software
Cdigo de calidad y fcilmente legible
Un estndar de codificacin define:
Reglas para nombrar clases, atributos y mtodos, normas de
identacin, etc.
Un documento muy sencillo (breve), pero muy utilizado en
el mundo J ava son las Java Code Conventions, definidas
por Sun Microsystems.
http://java.sun.com/docs/codeconv/index.html
Herramientas
Modelado UML
MagicDraw(instalado en Laboratorios de Docencia FIC)
Poseidonfor UML
Rational Rose
Desarrollo
HTTP/HTML/XML/CSS
J ava EE 5.0 +Apache Struts1.2.9 +TagLibs1.1.2 +J Unit 4.1
Apache Maven2
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
Arquitectura del Sistema
Internet/
Intranet
Capa 2 Capa 3
Navegador
I nt.
web
Modelo
Navegador
Capa 1
Navegador
Base de
datos
Serv. ap. web
Capas de una Aplicacin Web J ava EE: MVC+Layers
Interfaces para Acceso a Datos
Plugin: Plain | RMI | EJB |
Interfaces con Casos de Uso (lgica de negocio)
Modelo
Vista
Controlador
Plugin: JDBC | XML |
HTML/CSS + J SP + J STL
Apache Struts
DAO/TO
BusinessDelegate
SessionFacade
CTO
ActionForm + Action
Factory
Factory
Generalidades Metodologa
Introduccin al Proceso Unificado
El proceso Unificado de Desarrollo de Software. Ivar J acobson, GradyBooch,
J ames Rumbaugh. AddisonWesley, 2001.
Java Code Conventions
Sun Microsystems, Java Code
Conventions,http://java.sun.com/docs/codeconv/index.html.
Un proceso de desarrollo de software es el conjunto de actividades
necesarias para transformar los requisitos de un usuario en un sistema
software:
Proceso Unificado: Ms que un proceso de desarrollo de software
Marco de trabajo genrico que puede especializarse para una gran
variedad de sistemas software, para diferentes reas de aplicacin,
diferentes tipos de organizaciones, diferentes niveles de aptitud y
diferentes tamaos de proyecto.
Basado en componentes software, interconectados a travs de interfaces
bien definidas
Utiliza el Lenguaje Unificado de Modelado (UnifiedModelingLanguage,
UML) para preparar todos los esquemas de un sistema software
Proceso de desarrollo
de Software
Proceso de desarrollo
de Software
Requisitos
del usuario
Sistema
software
Orgenes
Modelo original Objectorydefinido por IvanJ acobson(1987)
Rational Software compra la empresa de Objectory(1995)
Surge la primera versin de UML (1997)
Se publica la primera versin del Proceso Unificado de Rational -
RUP (junio 1998)
Caractersticas del Proceso Unificado
Dirigido por casos de uso
Centrado en la Arquitectura
Iterativo e incremental
G
u
i
a
d
o

p
o
r

r
i
e
s
g
o
s
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 interacta con l
Casos de uso como el hilo conductor que orienta las actividades de
desarrollo
Casos de Uso
Anlisis
Recopilar,
Clarificar y
Validar los
requisitos
Diseo
Realizar los
casos de uso
Pruebas
Verificar que se
satisfacen los
casos de uso
<<realiza>>
<<verifica>> <<defineNecesidades>>
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
construccin
Arquitectura en software
Diferentes vistas del sistema: estructural, funcional, dinmico, etc.
Plataforma en la que va a operar
Determina la forma del sistema
Arquitectura: determina la forma del sistema
Casos de uso: determinan la funcin del sistema
Iterativo e Incremental
Descomposicin de un proyecto grande en mini-proyectos
Cada mini-proyecto es una iteracin
Las iteraciones deben estar controladas
Cada iteracin trata un conjunto de casos de uso
Ventajas del enfoque iterativo
Deteccin temprana de riesgos
Administracin adecuada del cambio
Mayor grado de reutilizacin
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
solucin rpidamente.
Rational UnifyProcess(RUP) - Dimensiones
Esttica - Flujos de trabajo
Roles QUIN?
Actividades CMO?
Artefactos QU?
Flujo de Trabajo CUNDO?
Dinmica
El Proceso Unificado se repite a lo largo de una serie de ciclosque
constituyen la vida de un sistema.
Ciclo: cada ciclo una nueva versin del producto
Fase: Etapas de un ciclo que finalizan en un HITO
Iteracin: Proceso de ingeniera sobre una funcionalidad limitada del sistema
En cada fase se realizan una o ms iteraciones a travs de los flujos de
tareas: requisitos no procedimentales(de eficiencia) y casos de uso,
Anlisis (opcional), Diseo, Implementacin y Pruebas.
Entradas al proceso:
Lista de caractersticas: descripcin informal (2 pginas) de lo que se
espera del desarrollo.
Modelo de dominio (Opcional). Modelar con UML el entorno en el que
operarel producto.
Dimensin Esttica del Proceso
Rol
Definicin 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
especfico
Tiene un propsito claro y se expresa en trminos de actualizar
artefactos
La granularidadde la actividad es generalmente de horas o pocos
das
Ejemplos de actividades
Planear una iteracin (administrador del proyecto)
Encontrar caso de uso y actores (analista del dominio)
Revisin del diseo (probador)
Dimensin Esttica del Proceso
Artefacto
Pieza de informacin producida, modificada y utilizada en un
proceso
Productos tangibles del proyecto
Utilizados por los roles como entrada para la realizacin 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 trminos de UML se puede utilizar: diagrama de actividades, de
secuencia, de colaboracin
Dimensin Dinmica del proceso
Concepcin Elaboracin
Construccin
Transicin
ciclo
fase
Iter. 1 Iter. 2 Iter. 3 Iter. 4 Iter. 5 Iter. 6
hito 1 hito 2
hito 3 hito 4
Hito: punto en el tiempo donde se evalan los objetivos
logrados y se pueden tomar decisiones crticas
Desarrollo Iterativo
Iteracin de
desarrollo 1
Iteracin de
desarrollo 2
Iteracin de
desarrollo n
Perfeccionar
el plan
Sincronizar
Artefactos
Anlisis Diseo Implementacin Pruebas
Construccin
Fase de Concepcin
Objetivo: Definir la razn de ser y el alcance del proyecto.
Estudio de oportunidad.
Visin =QU +PARA QU +CUNTO
Actividades
Especificacin de los criterios de xito del proyecto
Definicin de los requisitos
Estimacin de los recursos necesarios
Cronograma inicial de fases
Artefactos
Documento de definicin del proyecto
Fase de Elaboracin
Objetivo: Establecer un plan de proyecto y una arquitectura correcta
del sistema
Actividades
Anlisis del dominio del problema
Definicin de la arquitectura bsica
Anlisis de riesgos
Planificacin del proyecto
Artefactos
Modelo del dominio
Modelo de procesos
Modelo funcional de alto nivel
Arquitectura bsica
Al final de la fase de elaboracin se establece la lnea base de la
arquitectura.
Los riesgos de la lista de riesgos estn mitigados (con solucin,
implementada o no).
En realidad, adems de la lnea base de la arquitectura tambin se habrn
implementado aquellos elementos necesarios asociados a los casosde uso
de la lnea base, pero que no son crticos (no existan dudas para su
realizacin).
Fase de Construccin / Transicin
Construccin
Objetivo: Desarrollar el sistema a lo largo de una serie de
iteraciones
Actividades
Anlisis
Diseo
Implementacin / Codificacin
El flujo de tareas de implementacin se divide en Builds: consolidacin
del trabajo de los desarrolladores (punto de encuentro del trabajo de
varios diseadores).
Pruebas (individuales, de integracin)
Transicin: Pruebas beta (de usuario).
Ciclo de Vida del Proceso Unificado gil - AUP
Resumen Java Code Conventions ...
Extensiones de ficheros: .java, .class
Un fichero por clase pblica o interfaz
Puede incluir clases privadas, pero siempre despus de la pblica
Estructura de un fichero con cdigo fuente
Comentarios de inicio
Paquete y lista de imports necesarios
Declaracin de clase o interfaz
/ *
* Cl assname, Pr ogr ammer ( s) , Dat e
* Ver si on i nf o
* Copyr i ght not i ce
* Descr i pt i on
*/
Estructura de un fichero con cdigo fuente (continuacin)
Declaracin de clase o interfaz
/** ... */ Comentario J avadocde Clase o Interfaz
Declaracin class o interface
/* ... */ Comentario de implementacin, si es necesario
Variables de Clase (static)
public>protected>private
Variables de instancia
public>protected>private
Constructores
Mtodos
Agrupados por funcionalidad para facilitar el entendimiento del cdigo.
Identacin, 4 espacios (con algunas excepciones para mejorar legibilidad).
Longitud de lnea como mucho 80 caracteres
Divisin de lneas:
despus de una coma
antes de un operador
dar preferencia a divisiones de nivel superior
alinear la nueva lnea con el comienzo de la expresin del mismo nivel en la lnea
anterior
si al aplicar estas reglas el cdigo queda poco legible, utilizar 8 espacios
Comentarios:
J avadoc/** ... */, Bloque/lnea /* ... */, Fnde lnea // ...
Declaraciones
Una por lnea
Definir variables al comienzo de bloques { } (ms claro) e inicializarlas
cuando se definen si es posible
Excepcin: bucles for
Evitar declaraciones locales para ocultar declaraciones de niveles
superiores
Clases e interfaces
No utilizar espacio entre el nombre del mtodo y el parntesis de inicio de lista
de parmetros
La llave de inicio aparece al final de la lnea de declaracin de la sentencia
La llave de fin aparece al comienzo de lnea, identadacon el inicio de la
sentencia que cierra
Excepcin: mtodos vacos {}
Los mtodos se separan por una lnea en blanco
Sentencias
Una por lnea
Sentencias compuestas entre {}
Sentencias incluidas deben de ser identadas
{ apareceral final de la lnea de inicio del bloque; y } al
principio de lnea, identadocon el inicio del bloque.
En sentencias if-then-elseo bucles, se utilizarsiempre {} aunque
el bloque estcompuesto por una sola sentencia
Esto facilita el mantenimiento del cdigo (por ejemplo, si en el futuro se
aade una nueva lnea al bloque, el programador podra olvidarse de
aadir las llaves}
Sentencias return
No deben especificarse entre parntesis, salvo por claridad.
Sentencias
if, for, while, do/while, switch, try/catch
if ( condi t i on) {
st at ement s;
}
st at ement s;
} else {
st at ement s;
}
st at ement s;
} else if ( condi t i on) {
st at ement s;
} else if ( condi t i on) {
st at ement s;
}
for ( i ni t i al i zat i on; condi t i on; updat e) {
st at ement s;
}
for ( i ni t i al i zat i on; condi t i on; updat e) ;
while ( condi t i on) {
st at ement s;
}
while ( condi t i on) ;
do {
st at ement s;
} while ( condi t i on) ;
switch ( condi t i on) {
case ABC:
st at ement s;
/ * f al l s t hr ough */
case DEF:
st at ement s;
br eak;
case XYZ:
st at ement s;
br eak;
default:
st at ement s;
br eak;
}
try {
st at ement s;
} catch ( Except i onCl ass e) {
st at ement s;
} finally {
st at ement s;
}
Lneas en blanco (dos)
Entre secciones de un fichero fuente
Entre definiciones de clases e interfaces
Lneas en blanco (una)
Entre mtodos
Entre definicin de variables locales y la primera sentencia
Antes de un comentario de bloque o de lnea
Entre secciones lgicas de un mtodo
Espacios en blanco
Antes de un parntesis, salvo que sea la invocacin de un mtodo
Despus de una coma, en una lista de argumentos
Para separar los operandosde todos los operadores binarios
excepto .. No aplicable a operadores unarios
Para separar las expresiones de una sentencia for
Los castsdeben de ir seguidos por un espacio
Convenciones de nombrado (nombres representativos)
Clases
Deben de ser nombres, con la primera letra de cada palabra involucrada en ese
nombre, en maysculas.
Interfaces
dem clases
Mtodos
Deben de ser verbos, con la primera letra de cada palabra involucrada en
maysculas, salvo la de la primera.
Variables
Palabras, con la primera letra de cada palabra involucrada en maysculas,
salvo la de la primera.
Nombres comunes para variables temporales son i,j,k(numricas) c,d,e
(caracteres)
Constantes
En maysculas, separando cada palabra involucrada en el nombre por el
carcter subrayado _.
Paquetes (no incluido en J ava CodeConventions)
Palabras simples y en minsculas.
Prcticas de Programacin (salvo casos justificados)
Variables de clase o instancia no deben de ser pblicas
Evitar acceder a variables de clase desde instancias de objetos.
Las constantes numricas deben de definirse previamente en lugar de
utilizarlas como literales (salvo inicializaciones como -1, 0, 1)
Asignacin de variables
Evitar asignaciones mltiples en la misma sentencias (difcil de leer)
No utilizar el operador de asignacin en lugares en los que pueda ser
fcilmente confundido con el operador de igualdad
No utilizar asignaciones embebidas para intentar optimizar la ejecucin: Esa
es tarea del compilador
Es buena prctica utilizar parntesis en expresiones que combinan
mltiples operadores, aunque no sean necesarios por las reglas de
precedencia de los mismos.
Estructurar el programa de forma que slo haya una sentencia return.
En sentencias con ?, si la expresin condicional contiene un operador
binario, es recomendable ponerlo entre parntesis.
Comentarios especiales
XXX Marca algo que tiene algn problema pero funciona
FIXME Marca algo como que no funciona correctamente
TODO Marca algo como que estpor terminar
Java Code Conventions ... Ejemplo
/ *
* Fi r st name Last name
*
* Copyr i ght ( c) 1993- 1996 Sun Mi cr osyst ems, I nc. Al l Ri ght s Reser ved.
*
*/
package j ava. bl ah;
i mpor t j ava. bl ah. bl ahdy. Bl ahBl ah;
/ **
* Cl ass descr i pt i on goes her e.
*
* @ver si on 1. 10 04 Oct 1996
* @aut hor Fi r st name Last name
*/
publ i c cl ass Bl ah ext ends SomeCl ass {
/ * A cl ass i mpl ement at i on comment can go her e. */
/ ** cl assVar 1 document at i on comment */
publ i c st at i c i nt cl assVar 1;
/ **
* cl assVar 2 document at i on comment t hat happens t o be
* mor e t han one l i ne l ong
*/
pr i vat e st at i c Obj ect cl assVar 2;
/ ** i nst anceVar 1 document at i on comment */
publ i c Obj ect i nst anceVar 1;
Java Code Conventions ... Ejemplo
pr ot ect ed i nt i nst anceVar 2;
pr i vat e Obj ect [ ] i nst anceVar 3;
/ **
* . . . met hod Bl ah document at i on comment . . .
*/
publ i c Bl ah( ) {
/ / . . . i mpl ement at i on goes her e. . .
}
/ **
* . . . met hod doSomet hi ng document at i on comment . . .
*/
publ i c voi d doSomet hi ng( ) {
}
/ **
* . . . met hod doSomet hi ngEl se document at i on comment . . .
* @par amsomePar amdescr i pt i on
*/
publ i c voi d doSomet hi ngEl se( Obj ect somePar am) {
}
}
Generalidades Herramientas
Caractersticas Java SE 5.0
Herramientas de Gestin de Proyectos Software
Ant
Maven2
IDE Eclipse
Pruebas de Aplicaciones Software
J Unit
Caractersticas J ava SE 5.0
Generics - Mejora en el sistema de tipos.
Aade comprobacin de tipos en tiempo de compilacin para el
frameworkde collectionsy elimina los castings.
Bucle for - Facilidad en iteraciones sobre arraysy colecciones.
Autoboxing/Unboxing
Elimina la conversin manual entre tipos primitivos (int) y los tipos
envoltorio correspondientes (Integer).
Typesafe Enums - Tipos enumerados orientados a objetos.
Varargs - Mtodos con nmero de argumentos variable.
Static Import
Acceso no calificado a miembros estticos de un tipo sin heredar de l.
Annotations - Posibilidad de anotar el cdigo fuente.
Posibilita que herramientas generen cdigo a partir de las anotaciones.
Gestin de Proyectos: Apache Ant (1)
Herramienta del tipo de make(gnumake, nmake...)
OpenSource- Proyecto Apache (http://ant.apache.org)
Desarrollada en J ava.
Otras herramientas existentes.
Shell-based
Ejecutan comandos especficos del sistema operativo (no reutilizables en
diferentes plataformas).
Formatos 'estrictos' (ej. tabuladores en Makefiles)
Ant es ms portable.
Las tareas son ejecutadas por clases J ava. Solo requiere una MV J ava 1.1 o
superior (Reutilizable en diferentes plataformas)
Existe una tarea que permite ejecutar comandos basados en el SO utilizado.
Utiliza ficheros de configuracin XML (project, targets, tasks).
Ejecucin de ant
Por defecto busca el fichero build.xml en el directorio actual.
Se pueden especificar uno o ms targetsa ejecutar.
Por defecto ejecuta el target indicado en el atributo default de la etiqueta
<project >.
ant [<target>]*
Gestin de Proyectos: Apache Ant build.xml (2)
<project name=" MyPr oj ect " def aul t =" di st " basedi r =" . " >
<! - - set gl obal pr oper t i es f or t hi s bui l d - - >
<property name=" sr c" val ue=" . " / >
<property name=" bui l d" val ue=" bui l d" / >
<property name=" di st " val ue=" di st " / >
<target name=" i ni t " >
<! - - Cr eat e t he t i me st amp - - >
<t st amp/ >
<! - - Cr eat e t he bui l d di r ect or y st r uct ur e used by compi l e - - >
<mkdi r di r =" ${bui l d}" / >
</ target>
<target name=" compi l e" depends=" i ni t " >
<! - - Compi l e t he j ava code f r om${sr c} i nt o ${bui l d} - - >
<j avac sr cdi r =" ${sr c}" dest di r =" ${bui l d}" / >
</ target>
<target name=" di st " depends=" compi l e" >
<! - - Cr eat e t he di st r i but i on di r ect or y - - >
<mkdi r di r =" ${di st }/ l i b" / >
<! - - Put ever yt hi ng i n ${bui l d} i nt o t he
MyPr oj ect - ${DSTAMP}. j ar f i l e - - >
<j ar j ar f i l e=" ${di st }/ l i b/ MyPr oj ect - ${DSTAMP}. j ar " basedi r =" ${bui l d}" / >
</ target>
<target name=" cl ean" >
<! - - Del et e t he ${bui l d} and ${di st } di r ect or y t r ees - - >
<del et e di r =" ${bui l d}" / >
<del et e di r =" ${di st }" / >
</ target>
</ project>
Propiedades
Targets
Estructura de los Ejemplos de Integracin de Sistemas (5II) - J 2EE_EXAMPLES_HOME
build.xml
CommonPat hRef er ences. xml
CommonPr oper t i es. xml
Conf i gur at i onPar amet er s. pr oper t i es
Ser vi ceLocat or J NDI I ni t i al Cont ext . pr oper t i es
CommonEnvi r onment Var i abl es. {bat , sh}
MySQLCr eat eTabl es. sql
Post gr eSQLCr eat eTabl es. sql
build.xml
Ficheros bui l d. xml de los Ejemplos
build.xml global a todoslos
subsistemas.
all
compile (default)
ears
init
initdb
jars
javadoc
rebuild
sourcedist
wars
NOTA
Cadaficherobuild.xml incluyelos
ficherosCommonProperties.xml y
CommonPathReferences.xml del
directorioSubsystems.
Los targets del ficherobuild.xml
general enlazana lostargets
equivalentesen losbuild.xml de cada
subsistemaparticular.
ant projecthelpmuestra los targetsque
define un fichero build.xml
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
Gestin de Proyectos: Maven2 (1)
Herramienta de Gestin de proyectos Software
OpenSource; Proyecto Apache (http://maven.apache.org)
Mavenes una herramienta de ms alto nivel que Ant:
Ant enfoque basado en tareas
Crear el script buildcon las tareas a ejecutar
Ejecutar los targets
Maven enfoque declarativo
Describir el proyecto y configurar plugins
Ejecutar pluginsexistentes (goals)
Ncleo de Maven - POM Project Object Model
Contiene una descripcin detallada del proyecto, incluyendo
informacin de versiones, gestin de configuracin, dependencias,
recursos de la aplicacin y de pruebas, miembros del equipo, ...
Fichero XML situado en el directorio raz del proyecto
pom.xml
Gestin de Proyectos: Maven2 (2)
Estandarizacin de prcticas de gestin de proyectos
No se pierde tiempo reinventando estructuras de directorios,
convenciones ni personalizando scriptsbuild.xml de ant para cada
proyecto.
Mavenpermite redefinir la estructura de directorios estndar pero
es conveniente respetarla por las siguientes razones:
El fichero pom.xml serms pequeo y sencillo.
Hace que el proyecto sea ms fcil de entender y facilita el
mantenimiento futuro por otros.
Facilita la integracin de plug-ins(asumen tambin la estructura por
defecto)
Gestin de Proyectos: Maven2 pom.xml (3)
<pr oj ect xml ns=" ht t p: / / maven. apache. or g/ POM/ 4. 0. 0"
xml ns: xsi =" ht t p: / / www. w3. or g/ 2001/ XMLSchema- i nst ance"
xsi : schemaLocat i on=" ht t p: / / maven. apache. or g/ POM/ 4. 0. 0
ht t p: / / maven. apache. or g/ maven- v4_0_0. xsd" >
<model Ver si on>4. 0. 0</ model Ver si on>
<gr oupI d>es. udc. f bel l as. j 2ee</ gr oupI d>
<ar t i f act I d>st andar dut i l </ ar t i f act I d>
<packagi ng>j ar </ packagi ng>
<ver si on>2. 1. 1</ ver si on>
<name>J 2EE- Exampl es St andar d Ut i l Subsyst em</ name>
<ur l >ht t p: / / www. t i c. udc. es/ ~f bel l as/ t eachi ng/ i s</ ur l >
<dependenci es>
<dependency>
<gr oupI d>mysql </ gr oupI d>
<ar t i f act I d>mysql - connect or - j ava</ ar t i f act I d>
<ver si on>5. 0. 4</ ver si on>
<scope>t est </ scope>
</ dependency>
</ dependenci es>
</ pr oj ect >
Gestin de Proyectos: Maven2 Ciclo de Vida (4)
Ciclo de vida de un proyecto
Fases de construccin de un proyecto como compile, test, deploy
En Ant se crean targets con esos nombres que implementen esa semntica
En Maven1 se invocan plugins(goals) existentes
Un lenguaje de Scriptingbasado en XML, J elly, permita definir nuevos goalso
modificar el comportamiento de los existentes.
En Maven2 se estandariza el conjunto de fases del ciclo de vida del proyecto,
y al ejecutar una de ellas se ejecutarn los pluginscorrespondientes
Es posible implementar nuevos pluginsa asociar a las diferentes fases, como clases
J ava.
Para compilar: mvn compile
Gestin de Proyectos: Maven2 Dependencias (4)
En el fichero pom.xml se definen los recursos de los que depende un
proyecto
Mavenautomticamente descarga los recursos de repositorios remotos en
repositorios locales
Local a la mquina (estructura de directorios en base al groupidy artifactiddel
recurso)
Maven1 HOME/.maven/repository
Maven2 HOME/.m2/repository
Gestin de Dependencias Transitivas
Maven1 obliga a que cada proyecto defina todos los jarsnecesarios,
directa o indirectamente por la aplicacin.
Con Maven2 slo es necesario especificar los jarsque la aplicacin
necesita de forma directa; Maven2 gestiona las dependencias de las
libreras utilizadas, para incluirlas de forma automtica.
mbitos de Dependencias en funcin de las fases (Maven2)
compi l e necesaria en todas las fases (valor por defecto)
pr ovi ded necesaria para compilar pero no para deployar (e.g. servlet
API).
r unt i me necesaria slo para ejecutar (e.g. J DBC drivers).
t est necesar i a sl o par a pr uebas (e.g. J unit API).
Estructura de los Ejemplos de IS migrados a Maven 2
pom.xml
MySQLCr eat eTabl es. sql
Post gr eSQLCr eat eTabl es. sql
Conf i gur at i onPar amet er s. pr oper t i es
Eclipse IDE (http://www.eclipse.org)
Compile
Run
Debug
Plugins
- Ant
- Maven2
- Tomcat
-
W
e
b

T
o
o
l
s
P
r
o
j
e
c
t

E
d
i
t
i
o
n
-
H
T
M
L
,

J
S
P
,

J
S
P
X
,

X
M
L
,

S
Q
L
,

.
.
.

e
d
i
t
o
r
s
-
d
a
t
a
b
a
s
e
e
x
p
l
o
r
e
r
-
.
.
.
Pruebas de Unidad
Quesunapruebade unidad? - Definicinde IEEE
Pruebaindividual de hardware o software, o gruposde unidades
relacionadas
Normalmente, un test de unidadesun cdigoquepruebaunaunidad: que
puedeser unaclase, un componente, un mduloo unafuncin.
Las pruebasse creany se ejecutanmientrasse desarrollael software.
Las pruebasde unidadno son pruebasfuncionales, de aplicacin.
Las pruebasde unidadno son interactivas.
Un Framework de pruebasde unidadproporciona:
Un mecanismoparaorganizar y agrupar variostests
Unaforma sencillade invocar tests
Un indicacinclarade qutests hansidoexitososo fallidos.
Unaforma estndar paraescribir tests y especificar resultadosesperados.
En general, el objetivode laspruebasde unidadescomprobar quelos
diferentescomponentesdel SW funcionande forma aisladay queante
cambiosen el cdigocontinuanfuncionando.
Ques J unit?
J Unit esun framework paraescribir pruebasde unidad
repetiblesen J ava.
http://www.junit.org/
Open Source
Programadopor Erich Gamma y Kent Beck
Caractersticas
Utilizaasercionesparacomprobar resultadosesperados
Test Suites paraorganizar y ejecutar tests
Runners de tests grficosy textuales
FrameworkJ Unit
r un( )
<< interface >>
Test
f Name
setUp()
runTest()
tearDown()
r un( )
TestCase
r un( )
addTest ( )
TestSuite
*
TestResult
junit.framework
asser t Tr ue( )
asser t Equal s( )
. . .
Assert
junit.textui.TestRunner junit.swingui.TestRunner
J unit - Pruebas de Unidad
junit
App
TestCase
1..*
TestRunner
run
1..*
TestApp
test
1
test
2

J unit - Pruebas de Unidad
Creacin de prueba:
Crear una subclase de j uni t . f r amewor k. Test Case
Escribir un mtodo de pruebas
public void t est XXX( ) [ t hr ows ]
Puedenrealizarsevariascomprobaciones(aserciones) por mtodo
Escribir un mtodo sui t e, que utiliza introspeccin para crear
de forma dinmica un grupo de casos de prueba conteniendo todos
los mtodos t est XXX( ) .
Escribir un mtodo main() para ejecutar el test con el ejecutor en
modo texto
publ i c st at i c voi d mai n( St r i ng ar gs[ ] ) {
j uni t . t ext ui . Test Runner . r un( sui t e( ) ) ;
}
publ i c st at i c Test sui t e( ) {
r et ur n new Test Sui t e ( Si mpl eTest . cl ass) ;
}
Assert
La claseAsser t proporcionaun conjuntode mtodosestticospara
realizar comprobaciones
Puedenlanzar un objetocon mensajesde fallo
Los mensajesslose muestrancuandoun assert falla
Asser t . asser t Equal s( Obj ect , Obj ect ) Compara utilizando
el mtodo "equal s".
Si no se redefine, el mtodo equal s de un Object realiza una
comparacin por referencia; es necesario redefinir el mtodo equal s de
una clase para la que se desee comparacin por contenido.
Clases como St r i nglo tienen redefinido comparan por contenido.
Debera redefinirse el mtodo equal s en la clase con la que comparar
igualdad (que hara la igualdad atributo a atributo), en lugar de utilizar el
mtodo t oSt r i ng.
Dependiendo de cmo estimplementado, el mtodo t oSt r i ngpodra 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.
Inicializacin y Borrado de Datos de Prueba
La idea de hacer las pruebas con J Unit es que sean
"pruebas automticas".
Por tanto, cuando se ejecute, debe hacer con anterioridad
todo lo que sea necesario y con posterioridad restaurar el
estado inicial.
Creacin de Grupos de pruebas
pr ot ect ed voi d set Up( ) {
/ / i ni t i al i zat i on code
}
pr ot ect ed voi d t ear Down( ) {
/ / cl eanup code
}
publ i c st at i c Test sui t e( ) {
Test Sui t e sui t e = new Test Sui t e( ) ;
sui t e. addTest ( SomeTest . sui t e( ) ) ;
sui t e. addTest ( Anot her Test . sui t e( ) ) ;
r et ur n sui t e;
}
Ejecucin de un Caso de Prueba
Ejecucin en modo texto ...
j ava j uni t . t ext ui . Test Runner <t est CaseCl ass| t est Sui t eCl ass>
Ejecucin mediante interfaces grficas
j ava j uni t . swi ngui . Test Runner <t est CaseCl ass| t est Sui t eCl ass>
Ejecucin desde ant, con la tarea "j uni t " (OPTIONAL-TASK =>
necesario aadir j uni t . j ar al directorio libde ant)
NOTA: Con EJ Bsel Test Runner Swing falla; debe utilizarse el
TestRunner en modo consola de texto para evitar problemas.
<j uni t >
<t est name=" my. t est . Test Case" / >
</ j uni t >
<j uni t pr i nt summar y=" yes" f or k=" yes hal t onf ai l ur e=" yes" >
<f or mat t er t ype=" pl ai n" / >
<cl asspat h pat h=" . " / >
<t est name=" my. t est . Test Case" / >
</ j uni t >
J Unit 4.0 o superior y Anotaciones (1)
Requiere J ava SE 5.0.
Cases de prueba no tienen que extender
j uni t . f r amewor k. Test Case.
Mtodos de prueba no tienen que prefijarse con ' t est '.
No hay cambios entre los mtodos asser t antiguos y los
nuevos.
Utiliza anotaciones @Test para marcar un mtodo como
un caso de prueba.
Utiliza anotaciones @Bef or e y @Af t er para definir los
mtodos a ejecutar antes y despus de la ejecucin de cada
prueba.
Utiliza anotaciones @Bef or eCl ass y @Af t er Cl ass
para definir los mtodos a ejecutar antes y despus de la
ejecucin del conjunto de pruebas de una clase
J Unit 4.0 o superior y Anotaciones (1)
Las anotaciones @Test pueden incluir el parmetro
timeout. El test falla si tarda ms de ese tiempo en
ejecutarse.
Las anotaciones @Test pueden incluir un parmetro que
especifique el tipo de excepcin a lanzar para que sea
exitoso.
J Unit4Adapter habilita la ejecucin de los nuevos tests
J Unit4con runners antiguos.
El nuevo runner puede ejecutar testsJ Unit "antiguos".
...
Referencias
Asignatura Integracin de Sistemas.
Facultadede Informtica. Universidadeda Corua
http://www.tic.udc.es/~fbellas/teaching/is
Asignatura Proyecto de Fin de Carrera.
Facultadede Informtica. Universidadeda Corua
http://www.tic.udc.es/~mad/teaching/pfc3

Arquitectura MVC

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Arquitectura MVC

Uploaded by

Copyright:

Available Formats

UNIVERSIDADE DA CORUA

Departamento de Tecnoloxas da Informacin e as Comunicacins (TIC)

Diciembre 2006 Generalidades PFC3 50

You might also like