Presentación de PowerPoint

Aplicaciones Web – Origen y Evolución
Cátedra Capgemini – Universitat de València
Pablo Mir Gómez
Diciembre de 2015
de
Copyright © Capgemini 2013.Diciembre
All Rights Reserved
2015
1
Contextualización
Arquitectura de Capas
Evolución
› JSPs y Servlets
› EJB
› Spring Fwk
› SOA
› Put it all together
Metodología
Fwk devon
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
2
Contextualización
Arquitectura de Capas
Evolución
Metodología
Fwk devon
Fundamentos básicos de las Aplicaciones Web
¿Dónde podemos encontrar hoy en día aplicaciones web? ¿Por qué se han impuesto
en el modelo de negocio actual? ¿Para qué sirven realmente?
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
3
Definición de Aplicación Web
Definimos Aplicación Web como toda aquella herramienta software codificada en un lenguaje
soportado por navegadores web y donde se confía la ejecución al navegador.
Existe una independencia clara y marcada de la plataforma, evitando problemas de distribución,
compatibilidad, actualizaciones, seguimiento, etc. Pero una dependencia estricta en su ejecución
(requieren siempre de un navegador web y cumplir estándares).
Facilita la interacción y la comunicación activa entre usuario e información.
En muchas ocasiones permite una centralización de la solución.
› Ofreciendo herramientas multi-dispositivo y evitando la generación de numerosas
versiones para escritorio, móvil (iOS, Android, Wphone).
› Leyendo y escribiendo información directamente en la fuente.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
4
Antecedentes en el mundo de las Aplicaciones Web
Inicialmente, cada aplicación tenía su propio programa cliente instalada por separado en cada
ordenador.
El cliente realizaba peticiones y el servidor respondía.
Una mejora en la parte servidor, implicaba en muchos casos la modificación del cliente, con el
coste que ello suponía (soporte técnico, actualizaciones, gestión de errores…).
En las aplicaciones web, es la propia aplicación la que te sirve las páginas, es decir, cliente y
servidor son un único todo.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
5
Ventajas en el uso de Aplicaciones Web
Multiplataforma
Independencia del sistema operativo pero adaptación a navegadores del mercado.
Centralización
Unificación de la información leída y escrita normalmente a tiempo real.
Free Space
No ocupan espacio en disco y por consiguiente, evitan instalaciones de software.
Instant Update
Siempre se dispone de la última versión liberada por el autor.
Recursos
Evitan el consumo de recursos que puede ocasionar una aplicación de escritorio.
Disponibilidad
En aplicaciones web de envergadura se ofrece servicio desde múltiples fuentes para evitar caídas.
Seguridad
Los virus no afectan al cliente, puesto que si existen, se alojan en el servidor.
Colaboración
Se favorece un modelo colaborativo y compartir la información.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
6
Desventajas en el uso de Aplicaciones Web
Limitación
Normalmente están limitadas por el entorno y no ofrecen el 100% de funcionalidad.
Disponibilidad
La disponibilidad del servicio está supeditada a un tercero (pj. Empresa de hosting).
Conectividad
Pese a permitir funcionamientos offline, en algún momento deben sincronizar con servidor.
Recursos
La incorrecta gestión de memoria por parte del desarrollador, puede originar experiencias de
usuario nefastas y bloqueos en la operativa.
Seguridad
Los virus no afectan al cliente, pero pueden afectar a los datos del servidor si no están
debidamente protegidos.
Privacidad
Nuestra información se almacena en servidores cuya ubicación desconocemos. ¿Renunciamos a
nuestra privacidad?
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
7
Concepto de Centralización en Aplicaciones Web
Unificación de las fuentes de datos empleadas en los procesos de lectura y escritura, así como del
backend empleado en negocio.
En ocasiones, también se realiza unificación de la parte de vista, gracias a soluciones responsive.
Las características de la centralización son:
›
Origen de información único sin réplicas ni sincronizaciones
›
Mayor control y seguridad de la información
›
Fácil de mantener
›
Backend/Vista única favoreciendo multicanalidad (Móvil, Tablet, Escritorio…)
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
8
Concepto de Centralización en Aplicaciones Web
Vista A
Negocio A
A
Descentralización
B
Vista B
Responsive development
Negocio B
Pj. Cordova project
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
9
Concepto de Centralización en Aplicaciones Web
Centralización
N
e
g
o
c
i
o
A
V
i
s
t
a
A
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
10
Consideraciones a tener
en cuenta en el desarrollo
de AW
Una de las principales ventajas
competitivas de las Aplicaciones
Web es la independencia del
entorno,
no
independencia
contrarresta
dependencia
obstante,
del
con
de
esta
entorno
la
fuerte
ejecución
(navegador y estándares).
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
11
Consideraciones a tener en cuenta en el
desarrollo de AW
El desarrollador debe concienciarse del uso de
tecnologías estándar y transversales a cualquier
entorno de ejecución, desestimando aquellas que
puedan suponer un callejón sin salida en pocos
años (Flash, Silverlight, Applets…)
La
vulneración
de
estándares
sobre
los
navegadores web más comunes puede ocasionar
problemas de visualización y funcionamiento que
pueden ser arrastrados a negocio (pj. Valores
undefined en JavaScript).
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
12
Cronología de las Aplicaciones Web más relevantes de la historia
Las
aplicaciones
web
han
revolucionado la forma de utilizar
Nace
JavaScript
Aparece
Flash
Nuevo enfoque de las
WebApps. Gracias a él
se puede cambiar el
contenido de forma
dinámica
Surge una de las
primeras soluciones
de vista interactiva
contra las WebApps
internet, pasando de páginas con
contenido exclusivamente estático
a contenidos ricos e interactivos.
1987
1995
1996
1995
1998
1997
Comienzo del
camino
Surge
PHP
Surge
Hotmail
Primer
Periodismo en línea
Surge uno de los
primeros lenguajes
para el desarrollo de
WebApps: PERL
Rasmus Lerdorf pone
a disposición el
lenguaje PHP que
revolucionó la parte
servidor
Sabeer Bhatia y Jack
Smith construyen una
de las primeras
WebApps más
famosas
Nunca se había tomado
como medio de
comunicación. Difundió
noticia mediática antes
que la prensa
escrita
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
13
Cronología de las Aplicaciones Web más relevantes de la historia
Wikipedia
Conferencia
Web 2.0
Se lanza
Youtube
Aparece como subproyecto de Nupedia y
fomenta en desarrollo
colaborativo
John Battelle y Tim
O'Reilly liberaron el
concepto de Web
como Plataforma
Permite compartir
videos, alquilar
películas y es uno de
los sitios más famosos
hoy en día
1998
2003
2004
2004
2001
Google
MySpace
Google desarrolla su
primer motor de
búsqueda
Se convirtió en el
medio de
comunicación social
más visitado
2005
Surge
Digg y Facebook
2006 – Se lanza
Twitter
FB surge inicialmente
para estudiantes y
ahora es el segundo
sitio más visitado del
planeta
2007 – Aparece el
primer iPhone
2011 – KickStarter
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
14
Las Aplicaciones Web en el entorno empresarial
Hoy en día las empresas apuestan por la elaboración de soluciones íntegras, con una marcada
centralización tanto en arquitectura como en solución.
Los clientes buscan invertir poco dinero a cambio de soluciones desproporcionadamente
completas (pj. Para entornos de escritorio y móvil) y cada día abogan más por un modelo de fácil
mantenimiento y con una gran capacidad de interconexión entre los sistemas que ya poseen.
Gracias al modelo de centralización y a la arquitectura usada actualmente por la mayor parte de
consultoras (SOA), es mucho más sencillo conseguir la satisfacción del cliente y por consiguiente,
aportar más valor a los desarrollos. Esto no quiere decir que sea más sencillo construir una
solución (os cansareis de oír: “hacer esto no cuesta nada ¿no?” o “bueno, esto con una jornadita…”)…
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
15
Contextualización
Arquitectura de Capas
Evolución
Metodología
Fwk devon
Arquitectura de Capas
Principal definición de la arquitectura de capas sobre aplicaciones web. ¿Para qué se
emplea? ¿Programación modular?
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
16
Arquitectura de capas
El
objetivo
principal
de
esta
arquitectura se basa en la separación
de lógica de negocio y presentación.
Cuando existe un problema sólo se
ataca al nivel afectado.
Capa Web
al
Recibe y responde a todas
Debe
contemplar
las peticiones de usuario. Se
de
usabilidad,
Presenta
el
usuario.
principios
Permite un entorno colaborativo, en
accesibilidad,
el que los desarrolladores pueden
limpieza.
trabajar en paralelo sin perjudicarse.
Capa Negocio
sistema
sencillez
y
establecen
filtrados
peticiones
las
o
se
a
reglas
y
realizan
sistemas
externos.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
17
Programación modular
La arquitectura de capas es el primer paso hacia la programación modular. Tecnologías como JSP,
PHP, JSF… no siguen puramente (por sí solas) un modelo MVC (Modelo-Vista-Controlador), lo que
provoca en muchas ocasiones que el programador localice Vista y Negocio sobre la página
implementada.
El hecho de introducir directivas (lenguaje servidor) en capas de vista acarrea validaciones,
condicionales, bucles… que únicamente deberían aparecer en negocio.
Por deferencia a estas tecnologías, cabe destacar que la principal culpa la tiene el desarrollador y
las prácticas que adquiera. Podemos separar CSS, JS, Java… en ficheros independientes tales
como *.css, *.js, *.java (servlets), pero incluso con ello, en algunas ocasiones seguiremos sin
emplear un modelo puro MVC.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
18
Programación modular
El principal objetivo de la programación modular radica en la posibilidad de poder sustituir una
capa/modulo por otro, sin necesidad de adaptaciones o con un conjunto de cambios mínimos.
Del mismo modo que podemos sustituir un CSS por otro y cambiar el aspecto de una página en
segundos, podemos sustituir la capa de Base de Datos por otra y no tocar ninguna línea de
código.
JSPs
Servlets + Backend
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
19
Programación modular
El principal objetivo de la programación modular radica en la posibilidad de poder sustituir una
capa/modulo por otro, sin necesidad de adaptaciones o con un conjunto de cambios mínimos.
Del mismo modo que podemos sustituir un CSS por otro y cambiar el aspecto de una página en
segundos, podemos sustituir la capa de Base de Datos por otra y no tocar ninguna línea de
código.
JSPs
Servlets + Backend
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
20
Contextualización
Arquitectura de Capas
Evolución
Metodología
Fwk devon
» JSP + Servlets
Evolución de las aplicaciones web
Las aplicaciones web desde su origen, JSP-Servlets, EJB, Spring. Arquitectura SOA. El
modelo actual y su cohesión con la programación modular y la arquitectura de capas.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
21
Orígenes de Aplicaciones Web Empresariales – JSPs/JSFs y Servlets
Siempre desde el contexto MVC presente:
› Servlets: Tratan la información de los formularios, generan contenido, redireccionan
peticiones…
› JSP: Facilitan el desarrollo y mantenimiento del contenido HTML.
› No crea beans!!
›
Usar <jsp:useBean … type=“paquete.Clase” /> en vez de <jsp:useBean … class=“paquete.Clase” />
› No modifica beans!!
›
Usar jsp:getProperty en vez de jsp:setProperty
› Java Beans y Enterprise Beans: Facilitan la implementación de la lógica de negocio.
Independientes de la presentación.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
22
Controlador
Vista
Modelo
2. Procesado de petición
Petición HTTP
Servlets
Java Beans
Enterprise Beans
Respuesta HTTP
JSPs
3. Acceso a BD
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
23
Contextualización
Arquitectura de Capas
Evolución
Metodología
Fwk devon
» EJBs
Evolución de las aplicaciones web
Las aplicaciones web desde su origen, JSP-Servlets, EJB, Spring. Arquitectura SOA. El
modelo actual y su cohesión con la programación modular y la arquitectura de capas.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
24
Orígenes de Aplicaciones Web Empresariales – EJBs
EJB es un modelo de componentes o framework que permite crear aplicaciones sin tener que
reinventar servicios como transacciones, seguridad, persistencia automática, etc.
El código se ejecuta en un entorno llamado “Contenedor EJB” encargado de proveer servicios.
Se apoyan mucho en tecnologías que nos aporten los servidores de aplicaciones (cada servidor
aporta las suyas…)
La versión actual de la especificación EJB es la 3.2
Existen numerosas evoluciones de EJB, sin embargo, es a partir de la 3.0 donde realmente el
trabajo con esta tecnología merece la pena, puesto que las versiones anteriores eran demasiado
complejas y tenían muchos problemas.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
25
Problemas con la especificación EJB 2.x
Acoplamiento
Fuerte acoplamiento entre el código generado y las funciones propias de EJB. Se introducen
métodos en nuestras clases exclusivos para el funcionamiento de EJB (ejbCreate, ejbActivate…).
Descriptores
Se usan descriptores de despliegue (son complejos y propensos a fallos). Describen cómo se debe
desplegar cada EJB (de sesión con estado o sin estado, de entidad…)
Dependencia
Dependencia del JNDI cada vez que se tiene que acceder a un recurso, lo que supone una
operación repetitiva y tediosa en J2EE.
Persistencia
El desarrollo y gestión del modelo de persistencia es muy complejo.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
26
Características principales del nuevo modelo simplicado de EJB 3.x
POJO
Los EJBs son objetos POJO (Plain Old Java Object) sin requisitos heredados.
Anotaciones
Se emplean anotaciones sobre los POJOs con objeto de generar código Java sin intrusiones.
Descriptores
Se elimina la dependencia de los descriptores de despliegue. Se pueden sustituir por anotaciones.
Persistencia
Se utiliza un nuevo modelo de persistencia completo basado en el estándar JPA y que reemplaza
los beans de entidad.
Enfoque
Los valores predeterminados se usan siempre que sea posible (enfoque “configuración por
excepción”).
Home
Se elimina el requerimiento de especificar una interfaz HOME.
Interceptores
La existencia de interceptores, elimina la necesidad de implementar interfaces de tipo callback.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
27
Ejemplo de código entre EJB 2.x y EJB 3.x
// EJB 2.x
public class AccountBean implements javax.ejb.SessionBean {
SessionContext ctx;
DataSource accountDB;
public void setSessionContext(SessionContext ctx) {
this.ctx = ctx;
}
public void ejbCreate() {
accountDB=(DataSource)ctx.lookup("jdbc/accountDB");
}
public void ejbActivate() { }
public void ejbPassivate() { }
public void ejbRemove() { }
// EJB 3.x
@Stateless
public class AccountBean implements Account {
@Resource
private DataSource accountDB;
public void setAccountDeposit(int customerId,
double deposit) {
...
Connection conn=accountDB.getConnection();
...
}
...
}
public void setAccountDeposit(int empId, double deposit){
...
Connection conn = accountDB.getConnection();
...
}
...
}
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
28
Ejemplo de código entre EJB 2.x y EJB 3.x
// EJB 2.x
<session>
<ejb-name>AccountBean</ejb-name>
<local-home>AccountHome</local-home>
<local>Account</local>
<ejb-class>com.example.AccountBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<resource-ref>
<res-ref-name>jdbc/accountDB</res-ref-name>
<res-ref-type>javax.sql.DataSource</res-ref-type>
<res-auth>Container</res-auth>
</resource-ref>
</session>
...
<assembly-descriptor>...</assembly-descriptor>
// EJB 3.x
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
29
Servidor de Aplicaciones
Contenedor de EJB
Módulo Vista
Lógica de negocio
Módulo DAO
Entidades JPA
Cliente Local
Cliente Remoto
Beans de sesión
Proveedor JMS
Beans gestionados por
Gestor de entidades
Cliente Remoto
mensajes
Pool de servicios: JMS, JTA, JNDI,
JDBC, Seguridad, WS…
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
30
Competidores directos: Spring vs EJB
La enorme dificultad en la utilización de las versiones previas de EJB (1.0, 1.1, 2.0, 2.1) motivaron
la aparición de tecnologías como Spring, que supieron imponerse y mantenerse hasta el día de
hoy en el mercado.
La versión 1.0 de Spring Framework fue liberada en Marzo de 2004 y su principal punto clave es
la flexibilidad y aportar una serie de ventajas que EJB incorporó demasiado tarde.
Pese a ello, no debemos olvidar los estándares y en esto, EJB es dominante.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
31
Contextualización
Arquitectura de Capas
Evolución
Metodología
Fwk devon
» Spring Fwk
Evolución de las aplicaciones web
Las aplicaciones web desde su origen, JSP-Servlets, EJB, Spring. Arquitectura SOA. El
modelo actual y su cohesión con la programación modular y la arquitectura de capas.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
32
Orígenes de Aplicaciones Web Empresariales – Spring Fwk
Spring Fwk no es una evolución de EJB, sino una alternativa... Y todo sea dicho, muy buena.
Algunas de sus principales características son:
flexibilidad
Permite una conexión sencilla con otras tecnologías o fwk’s (estándar o no), ampliando así sus capacidades
de manera muy relevante (alta capacidad de integración).
actualización
Al ser un fwk de un único fabricante, lo mantiene al día e incorpora últimas tecnologías.
aislamiento
Sólo necesitamos Spring para poder trabajar, lo podemos instalar en cualquier servidor de aplicaciones y no
presenta problemas ni condicionamientos. Podemos usarlo con aplicaciones web, con swing, JavaFX… Nos
aísla de muchas problemáticas.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
33
Orígenes de Aplicaciones Web Empresariales – Spring Fwk
En contraprestación:
no estándar
complejo
Pero se ha consolidado
¿Configurar múltiples
como estándar de facto
características para que
en el mercado
funcionen juntas sin colisiones?
Sí claro y ¿cuándo decías que lo
necesitabas?
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
34
La solución del modelo empresarial
Spring Fwk es una solución muy versátil para grandes empresas, puesto que éstas disponen de
múltiples clientes que usan Servidores de Aplicaciones e infraestructuras muy diversas.
El motivo principal es que EJB presenta mucho acoplamiento de cara a Servidores de
Aplicaciones y por consiguiente, todos los desarrollos no se podrían enfocar de forma
homogénea.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
35
Spring es un framework para el desarrollo de aplicaciones y contenedor
de inversión de control, de código abierto para la plataforma Java.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
36
Inversión de Control (IoC)
Tradicionalmente, el desarrollador especificaba el flujo de acciones y decisiones mediante la
llamada a métodos… En la inversión de control es justamente al contrario: se especifican las
respuestas deseadas y se cede el control a una arquitectura externa.
Spring gestiona las creaciones y destrucciones de los objetos generados por el usuario y son
estos objetos los que procesan las respuestas y las gestionan.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
37
Inyección de Dependencias
Otro de los puntos relevantes y esenciales de Spring es la inyección de dependencias. En este
caso, Spring gestiona los objetos y permite que, en vez de crear nuevos objetos en cada clase,
sean suministrados mediante su “inyección”.
Mediante la utilización de estos dos conceptos, nos es más sencillo cumplir con otros, tales como
la modularidad y la reutilización. Por lo que podemos generar bibliotecas comunes y modulares
que luego inyectaremos en los lugares requeridos de nuestra aplicación.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
38
Módulo Vista
Lógica de negocio
Módulo DAO
Dispatcher Servlet
Entidades JPA
Petición HTTP
Basado en el patrón: Front
2. El Controller lanza
Controller, que nos da un
la petición
punto de entrada único.
Página de vista
Controller
Gestor de entidades
Handler Mapping
View Resolver
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
39
Contextualización
Arquitectura de Capas
Evolución
Metodología
Fwk devon
» SOA
Evolución de las aplicaciones web
Las aplicaciones web desde su origen, JSP-Servlets, EJB, Spring. Arquitectura SOA. El
modelo actual y su cohesión con la programación modular y la arquitectura de capas.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
40
Arquitectura Orientada a Servicios - SOA
Esta arquitectura tiene tres objetivos principales: flexibilidad, escalabilidad e integración con
sistemas heredados.
Permite encapsular pequeños bloques funcionales y hacerlos accesibles mediante interfaces.
Estos bloques funcionales son considerados servicios (petición-respuesta) y pueden ser
consumidos por la propia aplicación web que los contiene o por aplicaciones externas.
Por tanto, pese a lo que se diga, SOA NO ES UNA METODOLOGÍA.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
41
Arquitectura Orientada a Servicios - SOA
El encapsulado de servicios no sólo supone un buen sistema para la construcción de
aplicaciones, sino que beneficia al programador, puesto que permite atacar un problema de
forma más localizada. Gracias a esto, también mejora el tiempo de realización de cambios.
Esta arquitectura es el punto fuerte de la oferta de las consultoras actuales. La mayor parte de
clientes busca integración con los sistemas de los que ya dispone, migrando poco a poco sus
ecosistemas de aplicaciones, sin que les suponga un impacto grave en coste económico.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
42
Contextualización
Arquitectura de Capas
Evolución
Metodología
Fwk devon
» Put it all together
Evolución de las aplicaciones web
Las aplicaciones web desde su origen, JSP-Servlets, EJB, Spring. Arquitectura SOA. El
modelo actual y su cohesión con la programación modular y la arquitectura de capas.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
43
Spring Fwk
Módulo Vista
Lógica de negocio
Módulo DAO
Módulo SOA aislado y accesible desde sistemas externos
Petición HTTP
Model JPA <<
View
>> DTO
DTO
Interface
Entidades JPA
Interface
REST
Controller
Controller
Service
DAO
POOL de Servicios publicados
Model
Centralizamos Arquitectura y Lógica. No lo
hacemos con vista.
Utilizamos una arquitectura de capas con
MVC tanto en negocio como en vista.
Utilizamos maven para asegurar una gestión
de dependencias del proyecto centralizada
Hacemos uso de la programación modular
para elaborar componentes reutilizables.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
44
Contextualización
Arquitectura de Capas
Evolución
Metodología
Fwk devon
Metodología
Proceso de Testing: JUnit, pruebas unitarias, pruebas de pares, pruebas de
integración… Integración continua, Análisis Estático, SCRUM
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
45
Me acaban de asignar un proyecto!! Y ahora qué hago?
En muchas ocasiones y sobretodo al comenzar nuestra carrera profesional, desconocemos los
pasos a seguir en el momento de asignación a un proyecto.
Si el alcance está definido y ya se ha acordado un comienzo, finalización, presupuesto y recursos
con el cliente, debemos seguir unos “sencillos” pasos que nos pueden facilitar la vida.
Requisitos
Acribilla al cliente a preguntas. Deja claros los objetivos y remarca las
facetas en las que pone interés. Posiblemente cuando entregues el
producto, lo primero que haga sea buscarlas.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
46
Me acaban de asignar un proyecto!! Y ahora qué hago?
Analiza
Todo evolutivo debe acompañarse de un documento funcional que recoja
un análisis contextual, modelo de dominio, Arquitectura, Casos de Uso y
Mockups.
Estima
Cada caso de uso puede resumirse en un número: el volumen de horas
que va a costar implementarlo. El cliente debe ser conocedor del coste y
validarlo.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
47
Me acaban de asignar un proyecto!! Y ahora qué hago?
Planifica
Jamás dejes nada al azar!!! El “Creo que llegamos” o “no te preocupes que
sobra tiempo” no suelen funcionar nunca. Toda acción debe ser
cuantificada y valorada para su inclusión en el pool de tareas.
SCRUM
Utiliza metodologías ágiles para la consecución de proyectos. Avanzar con
pequeños pasos y con una monitorización continua del cliente, motivará
acercarse más a un nivel óptimo de satisfacción.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
48
Genial.
Pero… ¿para qué nos adentramos en metodología si el curso es sobre
Aplicaciones Web y Backend?
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
49
SCRUM y su vinculación con negocio
La metodología SCRUM establece una forma de relacionarse dentro del proyecto, pero también
define y acota las tareas del desarrollador (tarjetas).
Toda tarjeta SCRUM contempla un Caso de Uso completo o parcial y en algunos casos hay
dependencias entre ellos.
Una tarjeta SCRUM, es decir, un desarrollo, se considera terminada cuando:
› Se ha desarrollado el caso de uso reflejado en la misma.
› Se ha documentado tanto la parte técnica como la parte de usuario.
› Se han elaborado las pruebas necesarias para garantizar la calidad del software.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
50
¿Cómo probamos el Backend?
Los métodos habituales para la realización de pruebas sobre el backend-vista de cualquier
aplicación web son:
Pruebas Unitarias
Normalmente se hace uso de JUnits y deben encargarse de cubrir los escenarios
funcionales básicos para el correcto desarrollo del Caso de Uso.
Pruebas de pares
Son realizadas por un miembro del equipo ajeno al desarrollo y por consiguiente a la
tarjeta SCRUM asignada. Garantizan la solución de errores básicos.
Pruebas funcionales
Son realizadas por el analista funcional que elaboró el documento origen de todo y
desencadenan en un documento de Plan de Pruebas escrito sin tecnicismos.
Pruebas integración
Batida de pruebas realizada sobre una réplica del entorno de despliegue oficial con objeto
de validar comportamientos anómalos en caso de interacción con terceros.
http://www.uv.es/capgeminiuv/programa.html
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
51
¿Cómo estabilizamos el Backend del proyecto?
Tras el ciclo de pruebas, el código se sube a los repositorios y puede dar comienzo un proceso de
integración de código fuente (automatizado en muchos casos).
El objetivo de este procedimiento se basa en evitar que el equipo trabaje de forma aislada y que
conforme avance el tiempo, las discrepancias del código sean tan graves que puedan producirse
errores por el propio merge (normalmente suele ocurrir los viernes o cualquier día a la hora de
irse a casa).
El proceso de integración continua abarca todo el ciclo de vida de construcción de la solución:
Compilación > Testing > Testing de Calidad > Despliegue
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
52
¿Cómo aportamos valor a nuestro desarrollo?
Dentro del proceso de integración continua, se lanza una tarea para evaluar la calidad del código
subido por cada usuario.
Este procedimiento permite al desarrollador mejorar su código y hacer frente a posibles errores,
tales como variables que pueden llegar a ser null en algún momento de la traza, vulneraciones
de estándares, reservas de memoria innecesarias…
Capgemini presenta a sus desarrolladores el estado de los
proyectos en todo momento mediante monitores y de este
modo, es posible ver a tiempo real quién ha subido un fallo
en algún proyecto de los existentes y corregirlo cuanto antes.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
53
Contextualización
Arquitectura de Capas
Evolución
Metodología
Fwk devon
Breve introducción al fwk de desarrollo utilizado por Capgemini.
Fwk devon
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
54
Contextualización
Devon nació como herramienta de desarrollo propia y con el único objetivo de facilitar el día a día
a los desarrolladores.
Asimismo, con ella garantizábamos la estandarización de la forma de trabajo y un amplio
hándicap de reutilización (hasta entonces cada proyecto diseñaba su arquitectura y los
movimientos de personas entre proyectos se hacían complicados por el tiempo de adaptación).
Actualmente su versión estable es la 5.0, donde se incluyen las últimas librerías de Spring,
Hibernate, ExtJS 5, SenchaTouch 2 y un sinfín de módulos más. Sus principales principios son:
Multiplataforma, MultiBrowser/Multicanal, Opensource, SOA, continua evolución y últimas
tecnologías.
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
55
Aceleración en el desarrollo
Gracias al fwk, la gente que se dedica a desarrollar ha dejado de preocuparse por:
›
Configuración de librerías (Spring, Hibernate, Caché, Seguridad, i18n, properties, Reports…)
›
Crear un proyecto y partir de cero (Cuando creas un proyecto con el fwk partes de una plantilla
funcional)
›
Dependencias, builds… (Maven está automatizado para eliminar todos estos problemas al
desarrollador)
›
Tener un entorno de trabajo (devonfw no es sólo un fwk, sino un bundle de herramientas con todo
lo necesario para gestionar un proyecto: BD, Entornos, sistemas de caché, aplicaciones…)
›
Transaccionalidad (se utiliza el principio de transaccionalidad declarativa, evitando que el
desarrollador tenga que gestionar transacciones o se queden abiertas).
›
Gestión de conexiones (se aísla al desarrollador de la apertura y cierre de conexiones).
›
Controllers (se ha homogeineizado la comunicación de vista y negocio a través de anotaciones).
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
56
Web
Negocio
Datos
Más…
Estructura
Programación de tareas
Optimistic locking
Web Services
Schedulers
Auditoría
Mail
Eventos
Funcionalidades extendidas
Test en memoria
BO
Paginación
Seguridad
BO Asíncronas
Conversores
EDI
Monitorización de BO
Batch Query
Informes
Grids
Caché BO
Permisos y gestión de autorización
Búsquedas
Drools
BO
Controles
Forms
Caché
Gestión de Errores
Validaciones
Caché URLs
Accesos rápidos por teclado
Integración con Maps
Componente Gantt
jBPM
Batch
Permisos de visibilidad
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
57
Flexibilidad modular
test
Touch2
bam
WebExtJS5
batch
core
JPA
hibernate
ibatis
bpm
WebExtJS4
WebExtJS3
jsf
JDBC
rules
web
The happy path
reporting
birt
edi
ws
ucm
sws
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
58
Imagen visual, vista y multicanalidad
Devon hace uso de ExtJS como interfaz de vista por su gran versatilidad, rapidez, estandarización,
flexibilidad y escalabilidad.
Los proyectos móviles no son un problema con Sencha Touch, puesto que es multi-dispositivo y
multi-plataforma. Además funciona perfectamente con PhoneGap, que puede ser usado para
distribuir nuestras aplicaciones en las stores de Android, Apple, Wphone…
Asimismo, gracias a PhoneGap, podemos hacer uso de la API nativa del dispositivo y acceder así
a la cámara, contactos, etc.
Con devonfw la tecnología no es un problema, sino una oportunidad para el cliente
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
59
[email protected]
Diciembre de 2015
Copyright © Capgemini 2013. All Rights Reserved
60
Acerca de Capgemini
Con alrededor de 120.000 empleados en 40
países, Capgemini es uno de los principales
líderes en servicios de consultoría, tecnología y
outsourcing del mundo. El Grupo Capgemini
ha alcanzado unos ingresos globales de 9.700
millones de euros en 2011.
Capgemini en colaboración con sus clientes,
crea y proporciona las soluciones tecnológicas
y de negocio que mejor se ajustan a sus
necesidades y que conducen a alcanzar los
resultados deseados.
Siendo una organización profundamente
multicultural, Capgemini ha desarrollado su
propia forma de trabajar, la Collaborative
Business Experience TM, basada en su modelo
de producción Rightshore ®.
Para más información: www.es.capgemini.com
Rightshore® is a trademark belonging to Capgemini
www.capgemini.com
Diciembre de 2015
© 2015 Capgemini. All rights reserved.
Copyright © Capgemini 2013. All Rights Reserved
61