IFCD0210 - MF0493_3 - Implantación de aplicaciones web en entorno internet, intranet y extranet

IFcD0210

Informática y comunicaciones

Desarrollo De APLICACIONES con tecnologías WEB

Módulo Formativo 0493_3 Implantación de aplicaciones web en entorno internet, intranet y extranet

Certificado de Profesionalidad

© Unión Editorial para la Formación (UEF) www.unioneditorialformacion.es I.S.B.N.: 978-84-16047-36-9

Impreso en España. Printed in Spain 1ª edición Autor: José Manuel Carballeira Rodrigo

«Cualquier forma de reproducción, distribución, comunicación pública o transformación de esta obra solo puede ser realizada con la autorización de sus titulares, salvo excepción prevista por la ley. Diríjase a CEDRO (Centro Español de Derechos Reprográficos) si necesita fotocopiar o escanear algún fragmento de esta obra (www.conlicencia.com; 91 702 19 70 / 93 272 04 47)».

Reservados todos los derechos. Está prohibido, bajo las sanciones penales y el resarcimiento civil previstos en las leyes, reproducir, registrar o transmitir esta publicación, íntegra o parcialmente por cualquier sistema de recuperación y por cualquier medio sea mecánico, electrónico, magnético, electroóptico, por fotocopia o por cualquier otro medio presente o futuro, sin la autorización previa de Unión Editorial para la Formación (UEF).

IFCD0210

Desarrollo de aplicaciones con tecnolog铆as web

M贸dulo Formativo 0493_3

Implantaci贸n de aplicaciones Web en entornos internet, intranet y extranet

implantación de aplicaciones web en entornos internet, intranet y extranet REFERENCIA AL CERTIFICADO DE PROFESIONALIDAD............................................................................................ 8 INTRODUCCIÓN...................................................................................................................................................................... 9 OBJETIVOS................................................................................................................................................................................. 10 MAPA CONCEPTUAL............................................................................................................................................................. 11 UNIDAD didáctica 1. Internet..................................................................................................................................14 1.1 Breve historia y origen de Internet......................................................................................................14 1.2 Principales servicios ofrecidos por Internet................................................................................16 1.2.1 World Wide Web.................................................................................................................................................16 1.2.2 Correo electrónico.............................................................................................................................................19 1.2.3 Transferencia de ficheros (ftp)...........................................................................................................................30 1.2.4 Otros servicios.....................................................................................................................................................32 1.3 La tecnología de Internet..........................................................................................................................34 1.3.1 Arquitectura TCP/IP. Comparación con OSI..................................................................................................34 1.3.2 Protocolos de Internet: TCP, UDP, SMNP, SMTP, etc....................................................................................36 1.3.3 El protocolo HTTP..............................................................................................................................................39 1.4 Redes TCP/IP................................................................................................................................................................42 1.4.1 El direccionamiento IP. Evolución.....................................................................................................................42 1.4.2 Dominios. Jerarquía de dominios.....................................................................................................................46 1.4.3 Servicios de identificación de dominios: DNS..............................................................................................47 1.4.4 Ámbitos: Intranet, Internet y Extranet. Consideraciones de seguridad. Cortafuegos. ........................48 UNIDAD didáctica 2. La World Wide Web.........................................................................................................52 2.1 Breve historia de la World Wide Web...................................................................................................52 2.2 Arquitectura general de la Web.............................................................................................................53 2.2.1 Principios para el diseño de sistemas web.....................................................................................................53 2.2.2 Componentes básicos de un sistema web.....................................................................................................53 2.2.3 División en capas.................................................................................................................................................53 2.3 El cliente web.........................................................................................................................................................54 2.3.1 Hardware básico. Dispositivos fijos y móviles..............................................................................................54 2.3.2 Sistemas operativos de uso común e Internet..............................................................................................54 2.3.3 Navegadores. Características y comparativa.................................................................................................55 2.3.4 Funcionalidades avanzadas: extensiones, aplicaciones específicas, etc.....................................................56 2.4 Servidores web.......................................................................................................................................................56 2.4.1 Servidores web de uso común.........................................................................................................................56 2.4.2 Características básicas de un servidor web..................................................................................................57 2.4.3 Configuración de servidores web....................................................................................................................58 2.4.4 Seguridad en servidores web............................................................................................................................58 2.4.5 Funcionalidades avanzadas: extensiones, servidores virtuales, etc............................................................59 2.5 Servidores de aplicaciones...........................................................................................................................59 2.5.1 Concepto de servidor de aplicaciones...........................................................................................................59

2.5.2 Características de los servidores de aplicaciones........................................................................................59 2.5.3 Comparativa de servidores de aplicaciones de uso común.......................................................................60 2.5.4 Configuración de un servidor de aplicaciones..............................................................................................60 2.5.5 Seguridad en servidores de aplicaciones........................................................................................................60 2.5.6 Funcionalidades avanzadas: conceptos de escalabilidad, balanceo de carga, alta disponibilidad, etc...........................................................................................................................................................60 2.6 Servidores de bases de datos.......................................................................................................................61 2.6.1 Servidores de bases de datos para Internet de uso común......................................................................61 2.6.2 Características básicas de un servidor de bases de datos.........................................................................61 2.6.3 Funcionalidades avanzadas: conceptos de escalabilidad, alta disponibilidad, etc....................................62 2.7 Servidores complementarios en una arquitectura web.......................................................62 2.7.1 Servidores de correo. Características.............................................................................................................62 2.7.2 Servidores de direccionamiento (DNS). Características............................................................................63 2.7.3 Proxies...................................................................................................................................................................63 2.7.4 Servidores de directorio. Características de LDAP.....................................................................................64 2.7.5 Servidores de mensajería...................................................................................................................................64 2.7.6 Servidores de antivirus, filtrado de contenidos, etc.....................................................................................65 2.7.7 Otros servidores complementarios................................................................................................................65 2.8 Infraestructura hardware y software para servidores de Internet........................66 2.8.1 Servicios en la nube (Cloud).............................................................................................................................66 2.8.2 Tipos de servicios: infraestructura como servicio, plataforma como servicio y aplicación como servicio..............................................................................................................................................67 2.8.3 Ventajas e inconvenientes de los servicios de infraestructura en la nube...............................................69 2.8.4 Comparativa de los servicios de infraestructura en la nube de uso común..........................................71 UNIDAD didáctica 3. Aplicaciones web..............................................................................................................76 3.1 Evolución y tipos de aplicaciones informáticas........................................................................76 3.1.1 Aplicaciones de terminal. Servidores de terminales virtuales....................................................................77 3.1.2 Aplicaciones de escritorio.................................................................................................................................78 3.1.3 Aplicaciones cliente/servidor............................................................................................................................78 3.1.4 Aplicaciones web..................................................................................................................................................78 3.1.5 Ventajas e inconvenientes de los tipos de aplicaciones. Comparativa......................................................78 3.2 Tecnologías de desarrollo de aplicaciones.................................................................................80 3.2.1 Características por tipo de aplicación.............................................................................................................81 3.2.2 Comparativa según el tipo de aplicación........................................................................................................81 3.3 Tecnologías específicas para el desarrollo web........................................................................83 3.3.1 Portales de Internet. Características...............................................................................................................83 3.3.2 Gestores de contenidos: servidores de portales y documentales...........................................................83 3.3.3 Servidores de contenidos multidispositivo....................................................................................................84 3.3.4 Componentes básicos en portales web. Portlets y otros componentes de uso común.....................84 3.3.5 Características y comparativa de los portales web de uso común..........................................................85 UNIDAD didáctica 4. Desarrollo y despliegue de aplicaciones web............................................90 4.1 Modelos básicos de desarrollo de aplicaciones web.

El modelo vista-controlador (MVC)...........................................................................................................90 4.2 Herramientas de desarrollo web de uso común........................................................................95

4.2.1 Características......................................................................................................................................................96 4.2.2 Comparativa.........................................................................................................................................................96 4.3 Políticas de desarrollo y pruebas de aplicaciones web..................................................... 108 4.3.1 Entorno de desarrollo..................................................................................................................................... 108 4.3.2 Entorno de pre-producción o pruebas........................................................................................................ 109 4.3.3 Entorno de producción................................................................................................................................... 110 4.4 Organización de recursos en una aplicación web.............................................................. 112 4.4.1 Programas........................................................................................................................................................... 112 4.4.2 Hojas de estilos................................................................................................................................................. 113 4.4.3 Ficheros de configuración............................................................................................................................... 113 4.4.4 Imágenes............................................................................................................................................................. 114 4.4.5 Documentos...................................................................................................................................................... 114 4.4.6 Bibliotecas de componentes (librerías)....................................................................................................... 115 4.4.7 Otros archivos.................................................................................................................................................. 116 4.5 Seguridad en una aplicación web....................................................................................................... 116 4.5.1 Niveles de seguridad. Estándares.................................................................................................................. 120 4.5.2 Conceptos y técnicas de identificación, autenticación y autorización o control de acceso............ 128 4.5.3 Identificación y autenticación avanzada. Certificados digitales............................................................... 137 4.5.4 Concepto de sesión. Conservación de sesiones....................................................................................... 140 4.5.5 Sistemas de uso común para la conservación de las sesiones en aplicaciones web.

Single Sign-on y Single Sign-out............................................................................................................................... 142 4.6 Despliegue de aplicaciones web.............................................................................................................. 143 4.6.1 Características del proceso de despliegue................................................................................................. 143 4.6.2 Definición del proceso de despliegue de aplicaciones web.Verificación.............................................. 145 UNIDAD didáctica 5.VERIFICACIÓN DE APLICACIONES WEB..................................................................... 148 5.1 Características de un proceso de pruebas................................................................................... 149 5.2 Tipos de pruebas.................................................................................................................................................. 150 5.2.1 Funcionales......................................................................................................................................................... 150 5.2.2 Estructurales...................................................................................................................................................... 152 5.2.3 De integración con sistemas externos......................................................................................................... 152 5.2.4 Usabilidad y accesibilidad................................................................................................................................ 157 5.2.5 De detección de errores. Pruebas de caja negra....................................................................................... 158 5.2.6 De seguridad. Evaluación de la protección frente a los ataques más comunes.................................. 159 5.2.7 De rendimiento. Pruebas de carga o estrés. Estadísticas......................................................................... 159 5.2.8 De integridad de datos.................................................................................................................................... 160 5.3 Diseño y planificación de pruebas. Estrategias de uso común................................................................................................................................................................... 161 5.5 Automatización de pruebas. Herramientas.................................................................................... 165 UNIDAD didáctica 6. CONTROL DE VERSIONES................................................................................................ 168 6.1 Definición.............................................................................................................................................................. 168 6.2 Características generales ...................................................................................................................... 171 6.3 Tipos de control de versiones................................................................................................................ 172 6.3.1 Centralizados..................................................................................................................................................... 172 6.3.2 Distribuidos....................................................................................................................................................... 173

6.4 MECANISMOS DE CONTROL DE VERSIONES .............................................................................................. 175 6.4.1 Repositorios. gestión y administración...................................................................................................... 175 6.4.2 Publicación de cambios («check-in» o «commit»). Operaciones atómicas ........................................ 176 6.4.3 Tipos de desprotección, despliegue o «check-out»: exclusivos y colaborativos................................ 177 6.4.4 Ramificaciones («branching»)........................................................................................................................ 177 6.4.5 Fusiones («merging»). ..................................................................................................................................... 178 6.4.6 Etiquetado («tagging»). ................................................................................................................................... 179 6.4.7 Líneas de base («baseline»)............................................................................................................................ 180 6.4.8 Actualizaciones.................................................................................................................................................. 182 6.4.9 Congelaciones................................................................................................................................................... 182 6.4.10 Gestión de conflictos ................................................................................................................................... 183 6.5 BUENAS PRáCTICAS EN CONTROL DE VERSIONES................................................................................. 184 6.6 hERRAMIENTAS DE CONTROL DE VERSIONES DE USO COMúN....................................................... 189 6.6.1 Características. ................................................................................................................................................. 189 6.6.2 Comparativa...................................................................................................................................................... 189 6.7 INTEgRACIÓN DEL CONTROL DE VERSIONES EN hERRAMIENTAS ................................................ 194 DE USO COMúN. .......................................................................................................................................................... 194 UNIDAD DIDáCTICA 7. DOCUMENTACIÓN DE APLICACIONES WEB .......................................................... 198 7.1 CARACTERíSTICAS gENERALES DE LA DOCUMENTACIÓN. IMPORTANCIA EN EL CICLO DE VIDA SOFTWARE .......................................................................................... 198 7.2 ORgANIzACIÓN y ESTRUCTURA BáSICA DE DOCUMENTOS ........................................................... 198 7.3 gESTIÓN DE VERSIONES DE DOCUMENTOS .............................................................................................. 198 7.4 TIPOS DE DOCUMENTACIÓN. .......................................................................................................................... 199 7.4.1 De requerimientos. ......................................................................................................................................... 199 7.4.2 De arquitectura y diseño................................................................................................................................ 200 7.4.3 Técnica................................................................................................................................................................ 202 7.4.4 De usuario: tutoriales, por temas y glosarios. ........................................................................................... 203 7.4.5 Comercial. ......................................................................................................................................................... 203 7.5 FORMATOS DE DOCUMENTACIÓN................................................................................................................ 204 7.5.1 Documentos...................................................................................................................................................... 204 7.5.2 Documentación en aplicaciones. Formatos de ayuda. ............................................................................. 204 7.5.3 Documentación en línea. Wikis..................................................................................................................... 207 7.6 ESTáNDARES DE DOCUMENTACIÓN............................................................................................................ 207 7.7 hERRAMIENTAS DE DOCUMENTACIÓN....................................................................................................... 209 7.7.1 generación automática de documentación técnica................................................................................. 209 7.7.2 Documentación de código............................................................................................................................. 211 7.8 BUENAS PRáCTICAS EN DOCUMENTACIÓN............................................................................................. 211 7.8.1 Actualizaciones de documentación. ............................................................................................................. 211 7.8.3 Uso de herramientas multimedia.Vídeotutoriales.................................................................................... 212 RESUMEN ................................................................................................................................................................................ 213 BIBLIOgRAFíA........................................................................................................................................................................ 214 gLOSARIO .............................................................................................................................................................................. 215

Referencia al certificado de Profesionalidad CERTIFICADO DE PROFESIONALIDAD:

(IFCD0210) DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB (RD 1531/2011, de 31 de octubre de 2011)

MÓDULO FORMATIVO 0493_3: MF0493_3: Implantación de aplicaciones web en entornos Internet, Intranet y Extranet

Introducción Introducción El uso de Internet es algo ya inherente a la sociedad. Actualmente muchas empresas están presentes en Internet. Todos los servicios, información, comercio, etc. están presentes en la red.

Las empresas utilizan la red para ofrecer sus servicios, mostrar sus características, pero también para realizar la distribución y la comunicación dentro de la propia compañía (en lo que se conoce como Intranet).

Las tecnologías usadas están en continua evolución. Por un lado hay una serie de tecnologías, protocolos y arquitecturas que se usarán para crear las redes de la Intranet, así como para el acceso a Internet Las empresas utilizarán las aplicaciones web para mostrarse a la sociedad y ofrecer sus servicios. Actualmente hay muchas empresas dedicadas a la creación de estas aplicaciones que se personalizan dependiendo de las características de cada proyecto.

Los desarrolladores utilizarán las tecnologías que tienen a su alcance para diseñar estas aplicaciones, que son elementos software que se implantarán.

A la vez que evolucionan las tecnologías usadas para el desarrollo de aplicaciones web, también evolucionan las herramientas para su desarrollo. Aunque todas las aplicaciones (web y cualquier software) se pueden implementar usando sólo un editor de texto simple (tipo Notepad) y un compilador, estas herramientas ayudan al desarrollador a crear el código y a realizar otras tareas sobre el mismo, tales como la compilación, la verificación del software, el control del versionado, etc.

Como en cualquier elemento software, se deben seguir las fases del ciclo de vida, debiendo crearse una toma de requisitos, un diseño, un desarrollo, un testeo y finalmente una implantación. Las técnicas y las tecnologías a usar para su elaboración es lo que trataremos en esta unidad.

Objetivos Objetivos Objetivos generales • Establecer los procesos de instalación y distribución de la aplicación en distintos ámbitos de implantación.

• Elaborar y mantener la documentación aplicación web utilizando herramientas de generación de documentación y controlando las versiones.

• Seleccionar y emplear métodos y juegos de pruebas para verificar las funcionalidades y las especificaciones de rendimiento de la aplicación web.

Objetivos específicos • Determinar las diferentes fases, procesos y tecnologías informáticas que intervienen en la instalación y distribución de la aplicación web.

• En supuestos prácticos, en el que se pide instalar y distribuir la aplicación web en los ámbitos de internet, intranet y extranet.

• Identificar las diferentes herramientas de generación de documentación y control de versiones existentes.

• En un supuesto práctico en el que se pide elaborar y mantener la documentación de la aplicación web evaluar.

• Clasificar los diferentes métodos a utilizar para verificar el buen funcionamiento de la aplicación web desarrollada.

• En un supuesto práctico en el que se pide verificar las funcionalidades y las especificaciones de rendimiento de la aplicación web utilizando juegos de pruebas, los elementos siguientes.

Mapa conceptual Mapa conceptual USUARIO RECURSOS

CONTROL DE VERSIONES Navegador INTERNET/ INTRANET

ENTORNOS DESARROLLO

DESARROLLO APLICACIÓN

Servidor APLICACIÓN WEB

PRUEBAS

DOCUMENTACIÓN

01 Internet 1.1 Breve historia y origen de Internet 1.2 Principales servicios ofrecidos por Internet 1.2.1 World Wide Web 1.2.2 Correo electrónico 1.2.3 Transferencia de ficheros (ftp) 1.2.4 Otros servicios 1.3 La tecnología de Internet 1.3.1 Arquitectura TCP/IP. Comparación con OSI 1.3.2 Protocolos de Internet: TCP, UDP, SMNP, SMTP, etc 1.3.3 El protocolo HTTP 1.4 Redes TCP/IP 1.4.1 El direccionamiento IP. Evolución 1.4.2 Dominios. Jerarquía de dominios 1.4.3 Servicios de identificación de dominios: DNS 1.4.4 Ámbitos: Intranet, Internet y Extranet. Consideraciones de seguridad. Cortafuegos

14

Unidad didáctica 1. Internet

1. Internet 1.1 Breve historia y origen de Internet Para explicar el origen de Internet hay que remontarse a los años 60, cuando en época de la guerra fría entre Rusia y EEUU, los Estados Unidos crearon una red militar para que, en caso de un ataque ruso, se pudiese acceder a la información militar desde cualquier parte del país. Esta red se llamo ARPANET (Advanced Research Projects Agency Network) y fue creada en 1969.

ARPANET empezó con cuatro ordenadores distribuidos a lo largo del país en sus universidades, pero esta red fue creciendo exponencialmente de forma que el sistema de comunicación dejó de servir.

Para paliar las deficiencias del antiguo sistema de comunicación de ARPANET, se creó el protocolo TCP/IP, que desde el principio fue y sigue siendo un estándar en la comunicación informática.

Lo que en un principio fue una red de carácter exclusivamente militar, ARPANET, fue creciendo y posibilitando la entrada de diferentes sectores ajenos al campo militar sobre todo los sectores académicos y científicos, y eso hizo que se crease una nueva red para usos militares ajena a ARPANET. Esta nueva red se llamó MILNET. Además se fueron creando nuevas redes a través de diferentes asociaciones. Todas estas redes fueron intercomunicándose entre si y fueron formando una pequeña gran red, que fue la precursora de lo que hoy es Internet.

Internet fue creciendo y avanzando rápidamente de forma que a mediados de los años ochenta, ya estaba plenamente consolidada, aunque era conocida por muy pocas personas. A principio de los años noventa Internet contaba con más de diez mil servidores.

CARACTERISTICAS DE INTERNET Las principales características que definen Internet son: ––Globalidad: Internet está extendido por todo el mundo. Desde cualquier parte, se puede acceder a Internet.

––Interactividad: El usuario de Internet no es un mero espectador o lector, puede añadir y editar contenido. Herramientas como el email, los chats, las redes sociales y la mensajería instantánea permiten el diálogo en tiempo real y facilitan la interacción.

Unidad didáctica 1. Internet

––Multimedia: En Internet los formatos de la información son múltiples: texto, imágenes, animaciones, sonido, vídeo, etc. En los sitios web la integración de estos medios es muy fuerte.

––Personalización: Al buscar una información específica, Internet ofrece una serie de productos adaptados a las preferencias y necesidades de cada usuario.

––Conectividad: A la hora de conectarse a Internet existen múltiples posibilidades, algunas de las más utilizadas son: -- ADSL -- Telefonía fija -- Telefonía móvil -- Redes inalámbricas (WiFi) -- Fibra óptica ––Reducción de costes: Al usar Internet se dispone de herramientas que facilitan la búsqueda de información, lo que se traduce en un ahorro de tiempo y dinero. Además existen en la red una serie de servicios que o bien de forma gratuita o por una pequeña cantidad permiten abaratar costes. Algunos de estos servicios son: -- Las nuevas aplicaciones en los Smartphones para el envío de mensajes de texto gratuitos. Algunas de estas aplicaciones son Whatsapp o Line.

-- Aplicaciones que usan la telefonía IP para realizar llamadas y videoconferencias, por ejemplo Skype.

-- Herramientas para almacenar documentos y poder acceder a ellos para su posterior consulta o modificación, por ejemplo Google Docs.

–– Registro de la actividad: El propietario de un sitio web puede medir los resultados de su actividad, como, por ejemplo, cuantificar los visitantes del sitio, el tiempo que estuvieron, que zonas o artículos les resultaron interesantes, regularidad en las visitas, etc.

–– Crecimiento continuo: Internet está en continua expansión y evolución. El usuario debe estar al día de los cambios y actualizándose continuamente para poder aprovechar al máximo todas las herramientas que ofrece.

15

16

Unidad didáctica 1. Internet

1.2 Principales servicios ofrecidos por Internet 1.2.1 World Wide Web World Wide Web o como es conocido mundialmente por sus siglas WWW (o también W3 o simplemente Web) es el sistema de distribución de información en la Internet. Este sistema fue desarrollador por Tim Berners-Lee, investigador en el CERN, a principios de los años noventa.

Esta información puede ser en cualquier formato, por ejemplo: -- texto -- gráficos -- audio -- imágenes -- vídeos La información se accede a través del software llamado navegadores (o browsers en inglés), que se usan para visualizar esa información en forma de páginas web en múltiples dispositivos: ordenadores fijos, portátiles, pdas, teléfonos móviles, etc.

El primer navegador en modo gráfico fue Mosaic, que fue desarrollado a principios de los años noventa y que sirvió de base al navegador que durante muchos años fue el más usado, Internet Explorer. Éste fue el navegador más usado durante muchos años, sobre todo por ser de Microsoft e ir incorporado en todas las versiones de su sistema operativo y más popular, Windows. Sin embargo, problemas en su seguridad y rendimiento han hecho que pierda fuerza y esté siendo desbancado poco a poco por otros navegadores en los últimos años. Además, el resto de navegadores han ido incorporando características novedosas adelantándose a Internet Explorer, como por ejemplo el uso de las pestañas que posibilita poder visualizar varias páginas web en la misma ventana que fue incorporada en primer lugar por Firefox.

Entre los navegadores más usados están: -- Google Chrome -- Internet Explorer -- Mozilla Firefox -- Opera -- Safari En el siguiente gráfico se ve la evolución del porcentaje de uso de los diferentes navegadores a nivel mundial desde Junio 2012 a Mayo 2013.

Unidad didáctica 1. Internet

Fuente: http://gs.statcounter.com/ Para poder visualizar una web se debe conocer su dirección o URL (uniform resource locator). Si no se conoce su dirección, se puede buscar a través de los buscadores de Internet, siendo los más conocidos Google y Yahoo.

Word Wide Web se basa en el modelo cliente servidor, cuyas pautas son: ––Un cliente envía un mensaje de petición de información al servidor cuando necesita un servicio.

––El servidor está escuchando a la espera de peticiones. Al llegar un mensaje de petición, el servidor lo atiende y envía una respuesta. El servidor puede atender otros mensajes que lleguen de forma simultánea según la configuración del mismo.

––Si el servidor no puede atender una petición, ésta queda a la espera de su respuesta.

Un servidor de páginas web no es más que un ordenador (aunque lo habitual es que posea unas características de rendimiento y funcionalidad algo mejores que un ordenador de usuario), que proporciona las páginas web a los ordenadores clientes (los usuarios de Internet).

17

18

Unidad didáctica 1. Internet

El proceso para que un cliente (dispositivo del usuario) vea una página web alojada en un servidor es el siguiente: ––El cliente escribe la URL de la página en el navegador ––El DNS (Domain Name Server) del cliente traduce la URL a la IP de la página ––El router del cliente comienza el enrutamiento desde el ordenador del cliente al ordenador que tiene alojada la página web solicitada. Este enrutamiento se realiza a través de diferentes dispositivos en la red.

––Una vez que se llega al servidor de la página web se le indica la IP del dispositivo que ha enviado la petición.

––El servidor envía la página solicitada al dispositivo y llega a su destino por un proceso de enrutamiento similar a la petición.

––La página web llega al ordenador del usuario solicitante y se le muestra a través del navegador del usuario.

Es importante hablar de la memoria caché de los navegadores o los archivos temporales de Internet: Cuando un usuario solicita visualizar una página web, ésta es almacenada en el dispositivo del usuario. De esa forma cuando el usuario vuelve a querer ver la misma página y dependiendo de la configuración del navegador, se consulta la caché del navegador de forma total o parcial o se busca la web de nuevo en el servidor. Esto acelera la carga de las páginas web, ya que las partes que no cambian de la misma (logos, cabeceras, etc.) se consultan en la caché del navegador, la cual al estar en local, es muchísimo más rápida y sólo se pide las partes dinámicas de la página. Como se ha indicado, esto depende de la configuración del navegador especificada por el usuario.

HIPERTEXTO

recuerde World Wide Web (WWW) es el servicio más usado de Internet y consiste en la visualización de páginas webs a través de navegadores. Este servicio se basa en una arquitectura cliente-servidor

World Wide Web permite saltar de un lugar a otro con sólo unas pocas órdenes.

Esto se consigue fundamentalmente mediante el hipertexto. Este término se aplica cuando un elemento (fundamentalmente texto, pero también puede ser imagen, por ejemplo) que es un enlace a otro documento HTML (página web, imagen, audio, vídeo, etc.). De esta forma y mediante el hipertexto se logra una rápida navegación.

Los enlaces se denominan links. Estos links entre documentos se establecen por medio de ciertos elementos que aparecen resaltados en la pantalla y que permiten navegar entre las diferentes páginas.

Unidad didáctica 1. Internet

Existen diferentes tipos de links: ––Links dentro del a misma página ––Links a otra página pero dentro del mismo sitio web ––Links a otro sitio web El usuario no sabe dónde se encuentra el destino del enlace, ya que para él, esto es transparente: sólo debe pulsar en el enlace y se le muestra el destino del mismo.

Los documentos enlazados tienen alguna relación entre ellos. Todos los documentos enlazados es lo que hace que se llame a la Web telaraña mundial. Gracias a los links se puede acceder a una información por diferentes caminos.

1.2.2 Correo electrónico El correo electrónico o email se ha convertido en el medio de mensajería más popular y usado en la red.Y en sólo unos pocos años ha conseguido desbancar al correo postal como medio para múltiples comunicaciones.

El primer mensaje de correo electrónico fue enviado por el a principios de los años setenta. Hasta entonces se podría enviar mensajes por terminal entre usuarios de una misma máquina. La novedad dl correo electrónico residía en que hacía posible el envío de mensajes entre diferentes equipos conectados a Internet. Fue

19

20

Unidad didáctica 1. Internet

en ese momento cuando se decidió usar el símbolo “@” (arroba) para separar la partes de la dirección de correo electrónica y que todavía hoy sigue usándose.

Ejemplo de dirección de correo electrónico: jose@nombredeempresa.es es una dirección de email válida, siendo “jose” el nombre de usuario y “nombredeempresa.es” el dominio de ese correo.

En cada dominio el nombre de usuario es único, pero pudiendo existir dos nombres de usuario iguales en diferentes dominios. Por ejemplo puede existir jose@ dominio1.es y jose@dominio2.es EL CLIENTE DE EMAIL Es el programa que utilizan los usuarios para enviar y recibir correos electrónicos a través de una conexión con un servidor de correo electrónico. A finales de los años noventa aparecieron los primeros interfaces gráficos que permitían componer mensajes.

Dentro de los clientes de emails se pueden distinguir dos tipos: ––Software instalado en el equipo, por ejemplo, Microsoft Outlook, Eudora o Windows Live Mail.

––Webmail: consiste en usar un servicio de Cloud Computing para el tratamiento del email.

Todos los clientes de correo electrónico suelen realizar las siguientes acciones: ––Mostrar una lista de todos los mensajes presentes en el buzón de correo. Los encabezados de los mensajes, que están divididos en varios campos, permiten saber el remitente del mensaje, el asunto del cual habla, la hora y fecha del envío y, algunos otros detalles como la IP remitente.

recuerde

––Permitir seleccionar un mensaje para revisarlo.

El cliente de email es el programa que utilizan los usuarios para enviar y recibir correos electrónicos y se llama webmail si su acceso es a través de Internet.

––Permite crear nuevos mensajes y enviarlos. Para redactar un nuevo mensaje, hay que escribir la dirección del destinatario, el asunto y el contenido del ensaje.

––Adjuntar archivos a su mensaje y también guardar aquellos que llegan adjuntos en los mensajes del buzón de entrada. El tamaño máximo de envío y recepción de estos archivos adjuntos dependerá del servidor de correo electrónico, pero actualmente la media suele estar en 10 MB.

Unidad didáctica 1. Internet

SERVIDORES DE CORREO ELECTRONICO El servicio de correo electrónico se basa en el modelo cliente-servidor. El cliente envía una solicitud al servidor para completar alguna tarea y este último responde a esa solicitud, siguiendo las directivas indicadas en su configuración.

Los servidores de email son los encargados de transportar los mensajes del origen al destino. Suelen ser procesos del sistema operativo que operan en segundo plano y se encargan de recoger el correo electrónico enviado por los usuarios, y transferirlo de unos servidores a otros hasta quedar almacenado en el servidor correspondiente al usuario destinatario.

Estos servidores usan información contenida en los mensajes para calcular la ruta que debe seguir el correo, de forma análoga a una oficina de correos.

El protocolo que usan los servidores de correo electrónico para el intercambio de correo electrónico es el SMTP (Simple Mail Transfer Protocol).

El funcionamiento del correo electrónico es el siguiente: ––El dispositivo origen o remitente del mensaje establece una conexión TCP al puerto correspondiente del dispositivo destino o destinatario.

––En el destinatario se está ejecutando un servicio que está escuchando ese puerto a la espera de nuevos mensajes. Este servicio usa el protocolo SMTP. Cuando llega un nuevo mensaje, este mensaje acepta la conexión de entrada y entrega el mensaje en el buzón de usuario adecuado.

––Si un mensaje no puede entregarse (porque el buzón de usuario no exista, esté lleno, se supere la capacidad máxima de adjuntos, etc.) el servicio devuelve un mensaje de error.

A continuación se muestra un funcionamiento básico del correo electrónico.

Figura. Funcionamiento básico del correo electrónico.

21

22

Unidad didáctica 1. Internet

El usuario usuario1 de la empresa empresa1 (cuyo email es usuario1@empresa1.es) quiere enviar un mensaje al usuario2 de la empresa empresa2 (cuyo email es usuario2@empresa2.es). El proceso explicado en la figura es el siguiente: –– Paso 1: Usuario1 escribe el mensaje en su cliente de email, indicando la dirección de destino en el mismo. Ese mensaje es tratado por el servidor de correo saliente (smtp.empresa2.es) –– Paso 2: El servidor de correo saliente del remitente pregunta al servidor de nombres del destinatario cual es el registro MX del destinatario, es decir, cual e s el servidor de correo del destinatario.

–– Paso 3: El servidor de nombres del destinatario envía al servidor de correo del remitente el servidor de correo del destinatario.

––Paso 4: El servidor de correo del remitente entrega al servidor de correo del destinatario (en este ejemplo, smtp.empresa2.es) el mensaje.

––Paso 5: El servidor de correo del destinatario entrega en el buzón del usuario correspondiente el mensaje.

PASARELAS DE CORREO ELECTRÓNICO El correo electrónico SMTP funciona de forma correcta si el transmisor y el receptor están en Internet y pueden manejar directamente conexiones TCP/IP entre ellos.

Pero hay situaciones en las que estas conexiones no sirven y no es posible la comunicación directa, por ejemplo: ––Algunas máquinas sin conexión a Internet pueden querer transmitir y recibir correo electrónico de ordenadores conectados a Internet. Por ejemplo, muchas empresas tienen restringido el acceso a Internet por razones de seguridad.

––Si el transmisor y receptor hablan en diferentes formatos de correo.

Para solucionar estos contextos en los que la comunicación directa mediante protocolo TCP/IP no es posible se usan las pasarelas de correo electrónico.

Unidad didáctica 1. Internet

23

Para ilustrar el funcionamiento de una pasarela de correo electrónico se va a poner como ejemplo dos ordenadores que desean comunicarse por correo electrónico. El primero de ellos, PC1 usa el protocolo TCP/IP y el formato de correo RFC 822 y el segundo de ellos, PC2, sólo habla el protocolo TP4 y el formato de correo X.400 de OSI. Para el intercambio de correo, pueden usar unja pasarela de correo electrónico según se indica en la siguiente figura.

Figura. Esquema de pasarela de correo electrónico El procedimiento de funcionamiento de pasarela de correo electrónico aplicado a este ejemplo es el siguiente: ––El ordenador PC1 establece una conexión TCP con la pasarela.

––PC1 usa SMTP para transferir el mensaje a la pasarela.

––El servicio de la pasarela pone el mensaje en el buffer de mensajes cuyo destino es el ordenador PC2.

––La pasarela establece una conexión TP4 con el ordenador PC2.

––Transfiere el mensaje usando el equivalente OSI del SMTP. EL PROTOCOLO SMTP ––El protocolo SMTP es un protocolo sencillo cliente servidor en formato ASCII para el intercambio de correo. El funcionamiento de este protocolo es el siguiente: ––Una vez que se establece la conexión entre el dispositivo remitente (el cliente) y el puerto 25 (puede ser otro, pero el estándar es el puerto numero 25) del

recuerde Las pasarelas de coreo electrónico facilitan el intercambio de correo cuando la comunicación directa no es posible.

24

Unidad didáctica 1. Internet

dispositivo destinatario (el servidor), el cliente queda a la espera de recibir un mensaje del servidor.

––El servidor al principio envía una línea de texto que sirve de identificación e indica si está preparado o no para recibir correo. Si no está preparado, el cliente libera la conexión y lo reintenta más adelante.

––Cuando el servidor está listo para recibir el correo electrónico, el cliente le indica el remitente y el destinatario del mismo.

––Si el destinatario existe en el destino, el servidor da al cliente permiso para enviar el mensaje y el cliente envía el mensaje. El servidor emite un acuse de recibo.

––Una vez entregado el correo, se libera la conexión.

Comando

Descripción

HELO

Identificación del remitente.

MAIL FROM

Identificación del emisor.

RCPT TO

Identificar un destinatario individual. Se usa un comando distinto para cada destinatario diferente.

DATA

Para enviar el mensaje en líneas de texto. Cada línea tiene un tamaño máximo de 1000 caracteres y debe terminar en retorno de carro y avance de línea <CR><LF>, salvo la última que debe acabar también en punto.

RSET

Cancelar el correo actual.

QUIT

Pide al otro extremo el envío de respuesta de confirmación y finaliza la conexión.

VRFY

Se pide al receptor verificación de un destinatario no valido.

EXPN

Se pide al receptor confirmación de una lista de correo. Si es correcto, el receptor devuelve los nombres de la lista.

HELP

Pide al otro extremo ayuda sobre los comandos que estén disponibles.

TURN

El emisor pide rotación de papeles, de forma que pueda actuar como receptor. El receptor actual debe aceptar o no la petición.

SOML

Entrega el mensaje. Si el destinatario está conectado lo entrega al terminal, sino lo envía como correo.

SAML

Entrega el mensaje en el buzón del destinatario y si éste está online, también lo entrega al terminal.

SEND

Entrega el mensaje al terminal, sólo si el destinatario está online.

Tabla con los principales comandos del protocolo SMTP.

Unidad didáctica 1. Internet

Código

Descripción

211

Estado del sistema.

214

Mensaje de ayuda.

220

Servicio preparado.

221

Servicio cerrando el canal de transmisión.

250

Solicitud completada correctamente.

251

Usuario no local, se enviará a <dirección de reenvío>

354

Introduzca el texto, finalice con <CR><LF>.<CR><LF>.

421

Servicio no disponible.

450

Solicitud de correo no ejecutada, servicio no disponible (buzón ocupado).

451

Acción no ejecutada, error local de procesamiento.

452

Acción no ejecutada, insuficiente espacio de almacenamiento en el sistema.

500

Error de sintaxis, comando no reconocido. Si agente es SMTP y se conecta ESMTP

501

Error de sintaxis en parámetros o argumentos.

502

Comando no implementado.

503

Secuencia de comandos errónea.

504

Parámetro no implementado.

550

Solicitud no ejecutada, buzón no disponible.

551

Usuario no local, pruebe <dirección de reenvío>. Si no tiene buzón

552

Acción de correo solicitada abortada.

553

Solicitud no realizada (error de sintaxis).

554

Fallo en la transacción.

Tabla con códigos de respuesta del protocolo SMTP. Fuente. RFC 2821 (http://www.rfc-editor.org/rfc/rfc2821.txt)

Se va a ilustrar el funcionamiento del protocolo SMTP mediante el siguiente ejemplo de código:

25

26

Unidad didáctica 1. Internet

SERVIDOR: 220 servicio SMTP servidor.empresa1.es listo CLIENTE: HELO usuarios.empresa1.es SERVIDOR: 250 servidor.empresa1.es dice hola a usuarios.empresa1.es CLIENTE: MAIL FROM <jefedepartamento@usuarios.empresa1.es> SERVIDOR: 250 transmisor OK CLIENTE: RCPT TO: <empleado1@servidor.empresa1.es> SERVIDOR: 250 receptor OK CLIENTE: DATA SERVIDOR: 354 envía correo; termina con una línea únicamente con”.”

CLIENTE: From: jefedepartamento@usuarios.empresa1.es CLIENTE: To: empleado1@servidor.empresa1.es CLIENTE: MIME-Version: 1.0 CLIENTE: Message-Id: <0123456789.AA00123@usuarios.empresa1.es> CLIENTE: Content-Type: multipart/alternative; boundary=abcdef CLIENTE: Subject: Asunto del mensaje CLIENTE: CLIENTE: Éste es el preámbulo, el agente de usuario lo ignora.

CLIENTE: CLIENTE: --abcdef CLIENTE: Content-Type: text/richtext CLIENTE: CLIENTE: Lugar para el texto del mensaje de correo.

CLIENTE: CLIENTE: --abcdef CLIENTE: Content-Type: message/external-body; CLIENTE: access-type=”anon-ftp”, CLIENTE: site=”usuarios.empresa1.es”, CLIENTE: directory=”pub”, CLIENTE: name=”mensaje.snd” CLIENTE: CLIENTE: content-type: audio/basic CLIENTE: content-transfer-encoding: base64 CLIENTE: --abcdef CLIENTE: .

SERVIDOR: 250 mensaje aceptado CLIENTE: QUIT SERVIDOR: 221 servidor.empresa1.es cerrando conexión

Unidad didáctica 1. Internet

Si bien la sintaxis de los comandos del cliente debe ser estricta, la de las respuestas es más flexible, contando sólo el código numérico.

Si bien el protocolo SMTP está bien definido por el estándar RFC 821, pueden existir algunos problemas en su implementación, por ejemplo: ––Algunas implementaciones antiguas sólo manejan mensajes menores de 64 Kbytes.

––Si el servidor y el cliente trabajan con temporizaciones distintas, puede terminar uno antes que el otro, terminando abruptamente la conexión.

––Se pueden generar envíos de correo infinitos si se trabaja con lista de correo de forma inadecuada.

Se ha implementado un nuevo servicio, el SMTP extendido o ESMTP para solventar algunos de los problemas del SMTP. El ESMTP se ha definido en el RFC 1425.

Algunas de las diferencias entre los servicios SMTP y ESMTP se indican en la siguiente tabla SMTP

ESMTP

El primer comando de la sesión debe El primer comando de la sesión debe ser HELO ser EHLO Basado en RFC 821

Basado en RFC 1425

Los comandos ‘MAIL FROM’ y “RCPT Los comandos ‘MAIL FROM’ y “RCPT TO’ permiten sólo 512 caracteres.

TO’ permiten más de 512 caracteres.

No puede ser extendido con nuevos Se puede extender con nuevos cocomandos. mandos Tabla con las principales diferencias entre los servicios SMTP y ESMTP

RELAYING O INTERCAMBIADORES DE CORREO El término “relaying” se refiere al hecho de confiar en otro servidor para ejercer de servidor de correo, cuando el servidor de correo principal está inoperativo (por ejemplo por una caída del servicio.

Si un servidor no acepta “relay”, si en la entrega se especifica una máquina que no es la propia, rechaza el mensaje.

27

28

Unidad didáctica 1. Internet

recuerde El relaying de correo permite utilizar otro servidor de correo cuando el original falla.

Por contra, si un servidor de correo acepta “relay”, aceptará mensajes de otras máquinas, que guardará y cuando esa otra máquina vuelva a estar operativa, le reenviará el mensaje. Como lo único que se hace es “recoger” el correo electrónico cuyo destino es la otra máquina, no necesita tener creadas, ni necesita crear, las cuenta de usuario de la otra máquina.

CABECERAS DE LOS MENSAJES DE CORREO El formato de los mensajes de correo electrónico está definido en la norma RFC822. En ella se definen los campos de la cabecera (header) de un mensaje.

Esta cabecera se separa del mensaje por una línea en blanco y es transmitida junto con el resto del mensaje.

Todas las líneas de cabecera constan de una serie de palabras claves seguidas de os puntos y un valor concreto. Las únicas líneas obligatorias en la cabecera de un mensaje de correo electrónico son: ––From: (especifica el origen) ––To: (especifica el destino) Para poder enviar datos en el contenido del mensaje de correo electrónico que no estén escritos en el formato por defecto (inglés 7bit-ASCII) y poder enviar contenido diferente a texto (audio, vídeo, etc.) se debe incluir en ese mensaje una cabecera adicional denominada Multipurpose Internet Mail Extensions (MIME), que están definidas en las normas RFC 2045 y RFC 2046.

Las cabeceras para poder enviar contenido multimedia son: ––Content-Type, que especifica el tipo de contenido.

––Content-Transfer-Encoding, que permite a los agentes receptores el mensaje a su formato original en función de Content-Type (según el tipo de contenido, el agente ejecuta un procedimiento de descomprensión u otro).

Otra cabecera interesante en los mensajes de correo electrónico es “Received” que es añadida por el servidor de correo destinatario, para indicar: ––nombre del servidor SMTP cliente ––nombre del servidor SMTP que actúa de servidor ––hora de recepción del mensaje Esta cabecera “Received” es útil si el mensaje ha sido reenviado a través de varios servidores intermedios.

Unidad didáctica 1. Internet

Received: from alumno1.universidad.es by smtp.universidad.es; 03 Jun 2013 15:27:38 GMT From: alumno1@universidad.es To: alumno2@universidad.es Subject: Suerte en los exámenes MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg (base64 encoded data ……………. . . . . . . . base64 encoded data) Ejemplo de mensaje de correo electrónico con cabeceras PROTOCOLOS DE ACCESO AL CORREO ELECTRÓNICO: POP3 E IMAP Para poder leer el correo, el destinatario se conecta al servidor mediante un protocolo definido para la lectura de los mensajes. Los principales protocolos para leer correos electrónico son dos: POP3 (Post Office Protocol – Version 3, RFC 1939) Este protocolo es el más usado aunque por contra, es muy simple y de limitadas funciones. El funcionamiento del protocolo POP3 es el siguiente: ––El cliente abre una conexión TCP con el servidor de correo a través del puerto 110.

––Se requiere usuario y contraseña para leer el correo (fase de autorización) ––Se reciben los mensajes en el buzón de entrada del usuario y se marcan los mensajes que el usuario desea borrar, entre otras operaciones (fase de transacción). En esta fase los comandos enviados (list, retr, etc.) se responden de forma afirmativa con “+OK” o con “-ERR” si ha sucedido algún error.

––Se cierra el agente de correo y el servidor borra los mensajes marcados para ser eliminados en la fase anterior (fase de actualización).

Una vez descargados los mensajes, éstos quedan en carpetas locales del dispositivo del usuario y éste los trata: organiza en carpetas, crea reglas para los mismos., etc.

29

recuerde SMTP cuenta con varias cabeceras para el tratamiento del formato de codificación del correo, tipo de contenido, ruta el mensaje, etc.

30

Unidad didáctica 1. Internet

recuerde Con el protocolo POP3 se puede acceder a correos enviados con SMTP y almacenados en servidor. El protocolo IMAP es similar a POP3 pero más avanzado y su principal diferencia es que la gestión de carpetas es local en POP3 y remota en IMAP.

IMAP (Internet Mail Access Protocol, RFC 2060) Se trata de un protocolo bastante más complejo, ya que permite, entre otras características distintivas, gestionar carpetas en el servidor en lugar de hacerlo en modo local como POP3.

Para poder efectuar esto, el servidor IMAP de forma predeterminada ubica cada mensaje en una carpeta, pero el usuario puede cambiar esta ubicación.

Por esto el protocolo IMAP ofrece al usuario diversos comandos particulares que no existen en POP3· para realizar acciones con las carpetas: ––Creación de carpetas en servidor ––Borrado de carpetas en servidor ––Transferencia entre las carpetas ––Búsqueda de mensajes en carpetas según ciertas condiciones IMAP también permite obtener partes de mensajes en un mensaje MIME. Así, por ejemplo si el destinatario tiene poca capacidad o poco ancho de banda en un mensaje con audio incorporado se puede descargar sólo el texto del mensaje y no el audio.

WEBMAIL Desde hace varios años y sobre todo desde la popularización de Internet en los últimos móviles, cada vez más usuarios leen el correo a través de Internet. En este caso, el agente de correo es un navegador web y el usuario se comunica con su buzón de correo a través del protocolo HTTP. Cuando un usuario quiere acceder a su mensaje, se envía por HTTP en lugar de POP3 o IMAP. Al igual en IMAP, en Webmail los usuarios pueden tener sus mensajes en carpetas remotas del servidor. Casi todos los Webmail tienen una interface amigable que permite no solo recibir, sino redactar mensajes, incluso funciones más avanzadas como reglas o firmas.

1.2.3 Transferencia de ficheros (ftp).

El protocolo FTP (File Transfer Protocol) se usa para la transferencia de ficheros. La transferencia se puede realizar en dos sentidos: ––Transferir archivos desde el dispositivo local al servidor FTP, o lo que se llama subir archivos. Este procedimiento es muy usado cuando se desarrolla una pá-

Unidad didáctica 1. Internet

gina Web y se desea subir al servidor para poder visualizarla de forma correcta en Internet.

––Transferir archivos desde el servidor FTP al dispositivo local, lo que se llama bajar archivos. Se puede usar para tener una copia de nuestro sitio web en local.

Aunque al igual que todos los servicios de Internet, el servicio FTP se puede trabajar en modo comando a través de consola, lo más habitual es usar un cliente FTP con interface gráfico. Los clientes FTP más conocidos y usados son: ––FileZilla ––CuteFTP ––Ipswitch WS_FTP ––SmartFTP

Figura: Pantalla del cliente de FTP Filezilla. La interfaz de este cliente es muy similar a la de otros: consta de dos ventanas, una de ellas contiene los archivos locales (la de la izquierda) y la otra contiene los archivos del servidor (ventana derecha). Para subir y bajar archivos el método más sencillo es arrastrar y soltar.

31

32

Unidad didáctica 1. Internet

1.2.4 Otros servicios.

Además de los servicios ya vistos, World Wide Web, Correo electrónico y FTP: Internet proporciona otros muchos servicios, menos usados por ser menos populares o menos útiles de cara al usuario final. Alguno de estos otros servicios ofrecidos por Internet son: MENSAJERIA INSTANTANEA Este servicio sí que se ha popularizado en los últimos años, ya que permite la comunicación en tiempo real con contactos que se guardan de forma permanente (al contrario de lo que sucede en un chat). Además de poder conversar en modo texto, este servicio permite realizar videoconferencias usando voz y vídeo para la comunicación. La calidad de la videoconferencia va a depender de la velocidad de conexión a Internet y del ancho de banda disponible.

Algunos de los clientes de mensajería instantánea más usados son: ––Skype (antiguo Messenger) ––Ebuddy ––Google Talk ––Yahoo Messenger TELNET/SSH Ambos servicios sirven para el acceso remoto a otros terminales para facilitar las comunicaciones. La principal diferencia entre ambos servicios es que SSH (Secury Shell) tiene más seguridad.

Unidad didáctica 1. Internet

SSH ofrece mecanismos de seguridad que protegen a los usuarios contra cualquier persona con malas intenciones, mientras Telnet no tiene ninguna medida de seguridad, ya que fue concebido para funcionar dentro de una red privada y no a través de una red pública, donde pueden aparecer las amenazas. Debido a esto, todos los datos se transmiten en texto sin formato, incluidas las contraseñas.

Telnet omite también otra medida de seguridad llamada autenticación. Esto asegura que la fuente de los datos es el mismo dispositivo y no en otro equipo. Sin autenticación, otra persona puede interceptar la comunicación y realizar todas las acciones que crea oportunas.

Debido a las medidas de seguridad de SSH, cada paquete contiene menos datos para hacer espacio para los datos de los mecanismos de seguridad. Para transmitir la misma cantidad de datos, se consume un ancho de banda mucho mayor. Pero evidentemente, estas desventajas no son comparables a la protección que ofrece SSH. Algunos de los clientes más populares que implementan Telnet y SSH son: ––Absolute Telnet ––Open SSH ––Putty HTTPS HTTPS o HTTPS seguro es un servicio implementado para ofrecer seguridad en las comunicaciones Http críticas que lo requieran (por ejemplo en banca electrónica). Casi todos los navegadores implementan este servicio y se distingue de dos formas principalmente: ––la URL de la pagina web empieza por https:// en lugar de jttp:// ––aparece un símbolo que indica que estamos trabajando con https, normalmente suele ser un candado en la parte inferior de la página web.

Para resumir los principales servicios se ofrece un listado con los principales servicios y el puerto estándar asociado. En informática un puerto es una dirección lógica usada para la comunicación en un dispositivo. Cada uno de los servicios de Internet tiene asociado un puerto de forma predeterminada, pero se puede cambiar para otro puerto siempre que no esté ocupado.

Puerto

Nombre

Puerto

Nombre

21

FTP

143

IMAP

22

SSH

389

LDAP

33

34

Unidad didáctica 1. Internet

23

Telnet

443

HTTPS

25

SMTP

563

POP3 SSL

53

DNS

993

IMAP4 SSL

79

Finger

995

POP3 SSL

80

HTTP

1080

Proxy

110

POP3

3306

MySQL

119

NNTP

8080

Proxy Web

Puerto Nombre Puerto Nombre Tabla con los principales servicios de Internet y su puerto estándar.

Fuente original: http://www.iana.org/assignments/service-names-port-numbers/ service-names-port-numbers.xml 1.3 La tecnología de Internet 1.3.1 Arquitectura TCP/IP. Comparación con OSI. Los protocolos de Internet son los protocolos más populares de sistema abierto, es decir, no propietarios, ya que pueden ser utilizados para comunicarse a través de cualquier conjunto de redes interconectadas y se adaptan de igual forma a las comunicaciones de LAN y WAN. Los protocolos de Internet consisten en un conjunto de protocolos de comunicación, entre los cuales los más conocidos son: ––Protocolo TCP o Protocolo de Control de Transmisión ––Protocolo IP o Protocolo Internet El conjunto de protocolos de Internet también especifica las aplicaciones comunes, tales como el correo electrónico, emulación de terminal y transferencia de archivos.

Los protocolos de Internet fueron desarrollados a mediados de la década de 1970, cuando la DARPA (Defense Advanced Research Projects Agency) se interesó en el establecimiento de una red de conmutación de paquetes que facilitara la comunicación entre sistemas informáticos. Con el objetivo de una conectividad heterogénea, DARPA financió la investigación de la Universidad de Stanford y Bolt, Beranek y Newman (BBN). El resultado fue la suite de protocolo de Internet, completado a finales de 1970.

Unidad didáctica 1. Internet

TCP / IP más tarde fue incluido en el BSD (Berkeley Software Distribution) de UNIX y se ha convertido en la base de Internet y la World Wide Web (WWW).

La documentación de los protocolos de Internet (incluyendo protocolos nuevos o revisados) y las políticas de los mismos son especificados en informes técnicos llamados RFC (Request For Comments), los cuales tras su publicación, son revisados y analizados por la comunidad.

Para ilustrar el alcance de los protocolos de Internet, en la siguiente figura se especifican muchos de esos protocolos y sus correspondientes capas OSI. Modelo de referencia OSI

Arquitectura TCP/IP

APLICACION

PRESENTACION

NFS

FTP, TELNET, SMTP, SNMP XDR

SESION

TRANSPORTE

RPC

RCP, UDP IP:

–– ICMP

RED

–– PROTOCOLOS MIENTO ENLACE

ARP, RARP

FISICA

No especificado

DE

ENRUTA-

Figura: Comparación entre el modelo OSI y la arquitectura TCP/IP.

35

36

Unidad didáctica 1. Internet

1.3.2 Protocolos de Internet: TCP, UDP, SMNP, SMTP, etc.

PROTOCOLO IP El Protocolo de Internet (IP) es un protocolo de capa de red (Capa 3) que contiene información de direccionamiento y alguna información de control que permite a los paquetes a ser enviados. IP está documentado en el RFC 791. Junto con el protocolo TCP, IP representa el núcleo de los protocolos de Internet.

El protocolo IP tiene dos funciones principales: ––proporcionar conexión y la entrega de datagramas a través la interconexión de redes.

––ayudar en la fragmentación y reensamblado de datagramas para apoyar los enlaces de datos con diferentes unidades máximas de transmisión (MTU-maximum-transmission unit).

Un paquete IP contiene varios tipos de información: ––Versión: Indica la versión de IP utiliza utilizada (ipv4 o ipv6) ––Longitud de la cabecera IP (DIH): indica la longitud de la cabecera de tagrama en palabras de 32 bits.

da-

––Tipo de Servicio: especifica cómo un protocolo de capa superior tendría que manipular el actual datagrama, y asigna datagramas de diferentes niveles de importancia.

––Longitud total: Especifica la longitud, en bytes, de todo el paquete IP, incluyendo los datos y cabecera.

Identificación: contiene un número entero que identifica el datagrama actual.

Este campo se utiliza para ayudar unir diferentes fragmentos de datagramas.

––Banderas o Flags: consiste en un campo de 3 bits con el siguiente significado: -- El bit de menor orden especifica si el paquete puede ser fragmentado.

-- El bit número dos especifica si el paquete es el último fragmento en una serie de paquetes fragmentados.

-- El bit de orden superior actualmente no se utiliza.

Unidad didáctica 1. Internet

––Offset de fragmento: Indica la posición de los datos del fragmento en relación con el comienzo de los datos en el datagrama original, lo que permite poder reconstruir correctamente la datagrama original.

Time-to-Live (TTL): Mantiene un contador que se decrementa gradualmente hasta llegar a cero, momento en el que el datagrama se descarta. Esto evita que los paquetes de bucle infinito.

––Protocolo: indica qué protocolo de capa superior recibe los paquetes entrantes después de que la transformación IP es completada.

––Checksum de cabecera: operación de control que ayuda a asegurar la integridad del encabezado IP.

-- Dirección de origen: especifica el nodo emisor.

-- Dirección de destino: especifica el nodo receptor.

-- Opciones: diferentes opciones de apoyo, como la seguridad.

-- Datos: contiene la información a enviar.

Versión

IHL

Tipo de servicio

Identificación Time-to-live

Longitud total Flags

Protocolo

Offset de fragmento

Checksum de cabecera

Dirección origen Dirección destino Opciones Datos Figura: Campos de un paquete IP

37

38

Unidad didáctica 1. Internet

PROTOCOLO TCP El protocolo de control de transmisión o TCP es, junto con el protocolo IP, uno de los fundamentales de Internet.

Se trata de un conjunto de reglas que se utilizan junto con el Protocolo IP para enviar datos en forma de unidades de mensajes entre ordenadores a través de Internet. Mientras que IP se encarga del manejo de la entrega real de los datos, TCP se encarga de hacer el seguimiento de las unidades individuales de datos (llamadas paquetes) en las que un mensaje se divide.

Por ejemplo, cuando un archivo HTML es envido desde un servidor Web, el protocolo TCP en ese servidor divide el archivo en uno o más paquetes, y luego los envía de forma individual con el protocolo IP. Aunque cada paquete tenga la misma dirección IP de destino, es posible que se enruten de manera diferente a través de la red. En el otro extremo, el cliente, su protocolo TCP reensambla los paquetes individuales y espera hasta que hayan llegado todos para enviarlos al usuario que los solicitó, como u único archivo.

TCP es un protocolo orientado a la conexión, lo que significa que se establece una conexión y se mantiene hasta el momento en que finaliza el intercambio de mensaje o mensajes.

PROTOCOLO UDP UDP (User Datagram Protocol) es un protocolo que sirve para que las aplicaciones informáticas puedan enviar mensajes, llamados datagramas, a otros hosts en un protocolo de Internet (IP y sin comunicación previa para establecer canales de transmisión especiales o rutas de datos. Este protocolo fue diseñador en 1980 y fue formalmente definido en el RFC 768.

UDP es adecuado para fines en los que la comprobación de errores y la corrección no es necesario, evitando la sobrecarga de tal procesamiento en el nivel de interfaz de red.

Algunas propiedades de UDP son: ––Está orientado a transacciones ––Proporciona datagramas, adecuados para modelar otros protocolos ––Es simple ––Es un protocolo sin estado ––La falta de retardos de retransmisión le hace adecuado para aplicaciones en tiempo real.

Unidad didáctica 1. Internet

––Funciona bien en la comunicación unidireccional PROTOCOLO SMNP SMNP (Simple Network Management Protocol) es un protocolo popular para la gestión de red. Se utiliza para la recogida de información y para configurar dispositivos de red, tales como servidores, impresoras, hubs, switches y routers en un protocolo de Internet (IP).

La arquitectura de administración propuesta por este protocolo se basa en estos elementos: ––El sistema de administración de red (NMS) es un terminal por el cual los a d ministradores puedes gestionar la red.

––Los dispositivos administrados que son los mencionados anteriormente.

––Los agentes es una aplicación que es la responsable de la transmisión de datos PROTOCOLO SMTP Este protocolo es el encargado del transporte del correo electrónico, del cual se ha hablado al hablar del servicio de correo electrónico.

1.3.3 El protocolo HTTP El protocolo HTTP (Hypertext Transfer Protocol) es el más usado en Internet ya que es el que permite visualizar las páginas Web. Se usa en la comunicación bidireccional entre el navegador y el servidor Web. El proceso completo de petición de una página web es: ––El usuario teclea URL, por ejemplo http://www.paginaweb.com. El prefijo http:// ya no es obligatorio ponerlo ya que indica el protocolo y por defecto todas las web añaden este protocolo de forma predeterminada).

––El navegador consulta al DNS para averiguar la IP de la página consultada, ya que los ordenadores sólo son capaces de comunicarse por IP, no por nombres. El DNS es un traductor de nombres a IP y viceversa.

39

40

Unidad didáctica 1. Internet

––El navegador intenta establecer una conexión al puerto htttp, que por defecto es el puerto 80.

––Una vez que se establece dicha conexión, el navegador envía la petición http, en la cual solicita la URL de la página indicada por el usuario.

GET / HTTP/1.1 Host: www.paginaweb.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9, text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2, text/css,*/*;q=0.1 Accept-Language: es-es, en-us;q=0.66, en;q=0.33 Accept-Encoding: gzip, deflate, compress;q=0.9 Accept-Charset: ISO-8859-15, utf-8;q=0.66, *;q=0.66 Keep-Alive: 250 Connection: keep-alive

Ejemplo de petición HTTP En ese ejemplo se visualiza algunos de los parámetros de la petición: ––User-Agent: Tipo y versión del navegador ––Accept Language: idioma de la versión del navegador ––Accept-Encoding y Accept-Charset y Accept son cabeceras que indican los tipos de contenidos que son interpretados por el navegador. Estas cabeceras son personalizables y adaptables para los usos concretos del navegador.

––Keep-Alive y Connection son dos cabeceras que permiten recibir múltiples r e cursos.

––Cabecera Host, indica al servidor qué páginas web de qué sitio web del ervidor se desean visualizar, ya que un mismo servidor web puede tener albergados diferentes sitios web.

Unidad didáctica 1. Internet

El servidor recibe todas las cabeceras y una vez que las interpreta, devuelve al navegador una respuesta indicando si la petición ha tenido éxito o no y en caso de que sí, devuelve la página solicitada al navegador.

Es importante indicar la ruta correcta de la página web, por ejemplo www.paginaweb.com/archivo1.html. Cuando se indica la URL principal www.apaginaweb. com, en realidad no es correcto ya que se le debe indicar un fichero (normalmente con extensión .html). Pero en el caso de las páginas principales no es necesario indicarlo ya que en el servidor se configura cual es el fichero principal, normalmente suele llamarse index.html (aunque esto se puede cambiar en el servidor).

De esta forma cuando el usuario teclea www.paginaweb.com, el servidor busca el fichero www.paginaweb.com/index.html.

La respuesta del servidor a la petición http contiene la siguiente información: ––El servidor informa del éxito de la petición mediante el código 200 Ok ––También indica la versión del protocolo HTTP que conoce ––Se indica con Date la fecha y hora en el servidor ––Se indican la versión del servidor web y los módulos que contiene mediante Server.

––Con la cabecera Content-Type se indica el tipo de contenido, y a continuación, el propio contenido.

HTTP/1.1 200 OK Date: Sun, 2 Jun 2013 18:15:25 GMT Server: Apache/1.3.26 (Unix) mod_bwlimited/1.0 PHP/4.2.2 mod_log_bytes/0.3 FrontPage/5.0.2.2510 mod_ssl/2.8.9 OpenSSL/0.9.6b Last-Modified: Fri, 01 Nov 2002 12:23:38 GMT ETag: “23c32f-171cb-3dc2724a” Accept-Ranges: bytes Content-Length: 94667 Content-Type: image/png Age: 131 Ejemplo de respuesta del servidor a una petición http de un recurso binario

41

42

Unidad didáctica 1. Internet

La fecha de la última modificación del fichero y las etiquetas ETag son usados por las cachés de protocolo HTTP para decidir si almacenar o no en su memoria el recurso pedido, para luego poderlo mostrar más rápidamente desde el navegador, al devolver la copia almacenada en la memoria caché en lugar del propio recurso.

Recuerde El protocolo HTTP es el más usado en la Web y es el que implementa la comunicación bidireccional entre el navegador y el servidor Web y permite que los usuario visualicen las páginas Web. 1.4 Redes TCP/IP 1.4.1 El direccionamiento IP. Evolución Al igual que con cualquier otro protocolo de capa de red, el esquema de direccionamiento IP es parte integral del proceso de enrutamiento de datagramas IP a través de una interconexión de redes. Cada dirección IP tiene unos componentes específicos y sigue un formato básico. Estas direcciones IP se pueden subdividir y se utilizan para crear direcciones de subredes.

A cada host en una red TCP / IP se le asigna una dirección lógica única de 32 bits que se divide en dos partes principales: ––el número de red, que identifica una red y debe ser asignado por el Centro de Información de Internet (InterNIC) si la red forma parte de Internet (si es una red local o privada no es necesario). Un proveedor de servicios de Internet (ISP) puede obtener bloques de direcciones de red de la InterNIC y sí puede asignar un espacio de direcciones a sus usuarios.

Unidad didáctica 1. Internet

––el número de host, que identifica un host en una de la red y es asignado por el administrador de la red local. Un host es un dispositivo de la red, que habitualmente es un ordenador, pero puede ser otro elemento como un router, un teléfono móvil, una impresora de red, etc.

En función de los bits que ocupen el número de red y el número de host se habla de diferentes clases de IP. La dirección IP de 32 bits se agrupan ocho bits a la vez, separados por puntos, y representado en formato decimal. Cada bit en el octeto tiene un peso binario (128, 64, 32, 16, 8, 4, 2, 1). El valor mínimo para un octeto es 0, y el valor máximo para un octeto es 255. Es decir, una IP válida son 32 bits separados en conjunto de ocho bits, que representados en forma decimal, son cuatro grupos de dígitos separados por un punto y cada grupo puede tener un valor comprendido entre 0 y 255.

32 bits DIRECCION DE HOST

DIRECCION DE RED

8 bits 213

8 bits 25

8 bits 198

8 bits 4

Figura: Formato básico de una dirección IP y ejemplo de notación de IP 213.198.25.4 CLASES DE IP Como se mencionaba arriba, se clasifican las IPs en diferentes rangos en función de los bits de host y de red que usen.

––IPS DE CLASE A Son las IPS que tienen un valor comprendido entre 1 y 126 en su primer byte u octeto. Estas direcciones utilizan sólo ese byte primero como dirección de red.

Los otros tres bytes restantes se usan como dirección de host, por lo que al usar 34 bits para hosts puede haber más de dieciséis millones de dispositivos en cada una de las redes de esta clase.

Este tipo de direcciones es usado por redes muy extensas, pero por el tamaño de dirección de red, sólo puede haber 126 redes diferentes de este tamaño.

ARPANET es una de las redes de clase A existentes en el mundo.También existen redes comerciales con este tipo de direcciones, pero suelen ser poco habitual.

43

44

Unidad didáctica 1. Internet

––IPS DE CLASE B Estas direcciones utilizan en su primer byte un valor comprendido entre 128 y 191, incluyendo ambos. El identificador de la red ocupa los dos primeros bytes de la dirección IP. Por tanto, en estas redes, los dos últimos bytes son de host, permitiendo en consecuencia 64516 dispositivos en una red de clase B. Las grandes empresas usan este tipo de red, si necesitan conectar más dispositivos, pueden unir más de una red de clase B. ––IPS DE CLASE C Este tipo de IPs usa los tres primeros bytes como dirección de red y el último byte es el que reserva como dirección de host, por tanto, se pueden conectar en cada red de clase C un máximo de 254 dispositivos diferentes.

Estas direcciones permiten un menor número de pero son las más numerosas y son usadas por empresas pequeñas y medianas.

––IPS DE CLASE D Se reservan a grupos Multicast y están especificadas en RFC 1112. Su rango de IPs va desde la 224.0.0.0 a la 239.255.255.255 ––IPS DE CLASE E El uso de estas redes está destinado para fines de investigación o experimentales.

Las IPs de esta clase comprenden el rango 240.0.0.0 a 254.255.255.255.

IPV4 Y IPV6 El formato de IP descrito anteriormente (cuatro grupo de ocho bits separados por puntos, cada uno de los grupos con un valor decimal entre 0 y 255) corresponde al formato IPv4 que ha sido el estándar durante muchos años. Sin embargo, este formato que era válido cuando surgió Internet y años sucesivos ha ido quedándose pequeño conforme pasaban los años y el número de dispositivos en Internet era cada vez mayor. Hasta tal punto se quedaba pequeño que las previsiones pronosticaban que en unos pocos años no habría IPs disponibles de seguir con ese formato, las IPs se estaban agotando.

Unidad didáctica 1. Internet

Para solucionar este problema se creó otro formato, que es el IPv6. Para que todo funcionase de forma correcta este formato debía ser compatible con IPv4, ya que el proceso de cambio no podía ser inmediato y estos dos formatos deben convivir durante algún tiempo.

Una dirección IPv6 puede tener dos formatos: ––Normal o formato de IPv6 puro: segmento

segmento

segmento

segmento

segmento

segmento

segmento

segmento

Es decir, se divide en ochos segmentos, cada uno de os cuales puede tomar un valor hexadecimal entre 0 y FFFF, estando separados cada uno de los segmentos por dos puntos.

Ejemplo de IPv6 normal 2013: db8: 3333 : 28 : 5555 : 6666 : 666a : 8888 ––Formatos IPv6 dual Una dirección IPv6 dual combina una dirección IPv6 y una dirección IPv4 y tiene el siguiente formato: segmento segmento segmento segmento segmento segmento octeto octeto octeto octeto Es decir, es una porción de dirección IPv6 siempre al inicio y una porción de IPv4 al final.

45

46

Unidad didáctica 1. Internet

En la porción de la dirección IPv6, hay seis segmentos, con valor hexadecimal ente 0 y FFFF, estando separados por dos puntos.

En la porción de la dirección IPv4, hay cuatreo octetos, separados por punto y siendo el valor de cada octeto un numero decimal entre 0 y 255.

Ejemplo de IPv6 dual 2013: db8: 3333 : 28 : 5555 : 6666: 125.66.3.89 1.4.2 Dominios. Jerarquía de dominios DNS se basa en un esquema jerárquico de nombres llamado nombre de dominio.

Un nombre de dominio consiste en una secuencia de etiquetas separadas por un punto. Por ejemplo, miejemplo.com, contiene dos etiquetas, el dominio de nivel inferior es “ miejemplo.com”, y el nivel superior es “com” Se puede ver que el dominio de nivel local corresponde con la primera etiqueta, y el de nivel superior a la segunda y última etiqueta.

En realidad, un dominio puede ser una máquina o puede ser un nodo del cual pueden partir otros dominios, o ambos conceptos de forma simultánea.

En Internet se dividieron los dominios en dos tipos: ––Dominios geográficos Se pretende usar un dominio geográfico por cada país. También son conocidos como ISO3166. Algunos ejemplos de dominios geográficos son: ––.es para dominios de España ––.pt para dominios de Portugal ––.fr para dominios de Francia ––.us para dominios de Estados Unidos Se puede encontrar un listado completo de los dominios en la web que pecifica la norma ISO 3166:

es-

http://www.iso.org/iso/country_names_and_code_elements ––Dominios genéricos Se pretendía ofrecer una división según el tipo de organización. Esto se cumplió en un principio pero ahora esta división ha pasado a ser teórica al permitir casi

Unidad didáctica 1. Internet

a cualquier organización poder elegir casi cualquier tipo de dominio (al principio esto no era así).

Algunos de los dominios genéricos más usados que corresponde a la tabla TLD (Top Domain Level) son: ––.com: Organizaciones comerciales ––.edu: organizaciones educativas, como colegios, universidades, etc.

––.gov: Instituciones gubernamentales ––.mil: Organizaciones militares ––.org: Organizaciones no comerciales ––.net: Grupos relacionados con la Red ––.int: Organizaciones Internacionales

47

recuerde Los nombre de dominios tienen una estructura jerárquica y se dividen en dominios geográficos y genéricos.

Los nombres de los dominios pueden ser texto ASCII de hasta 63 caracteres de longitud.

1.4.3 Servicios de identificación de dominios: DNS Para poder comunicarnos con un ordenador necesitamos saber su dirección IP. Dado que las direcciones IP son difíciles de memorizar o recordar, se usa desde hace bastante tiempo nombres fáciles de recordar (más o menos) para las mismas.

Al principio de Internet esto no era así, se usaba una tabla con los nombres de las páginas y sus IPs y la persona debía escribir buscando en la tabla la IP de la página que quisiese visualizar. Esta tabal se guardaba en un fichero llamado HOSTS.txt (el fichero HOSTS se usa aun en sistema operativos Windows como una especia de DNS local). Evidentemente, en cuanto el número de páginas creció un poco, este método se volvió inviable por varios motivos: ––El tráfico y la carga de red para el dispositivo que contenía las tablas era muy elevado.

––Este fichero era bastante inconsistente, ya que se volvía obsoleto en poco tiempo.

––Podía haber duplicidad de nombres, al no existir una administración central.

––No era un método que se pudiese escalar.

Para solucionar este problema de traducción entre nombres de paginas e IPs surgió el sistema de resolución de nombres, DNS (Domain Name System).

recuerde El sistema DNS traduce los nombres de las paginas en IPs entendibles por la red.

48

Unidad didáctica 1. Internet

1.4.4 Ámbitos: Intranet, Internet y Extranet. Consideraciones de seguridad. Cortafuegos.

El uso de los sitios web, internos o externos a las organizaciones, se ha vuelto cada vez más frecuente conllevando una serie de ventajas e inconvenientes. En las empresas normalmente son accesibles: ––los sitios de Internet externos disponibles a todos los usuarios ––sitios sólo accesible por la red interna que contienen información de interés empresarial, como agendas y ficheros compartidos, según el principio de redes intranet.

––sitios Internet que sean visibles por personal autorizado, según el principio de redes extranet.

Internet para una empresa u organización es una herramienta con las siguientes utilidades: ––Ser más visible en el mercado ––Poder contactar con un mayor número de clientes ––Compartir recursos y datos Si una organización permite a sus empleados el acceso a Internet, tendrá que asumir una serie de desventajas como éstas: ––Los usuarios pueden pasar demasiado tiempo en Internet y por tanto, siendo menos productivos.

––Al abrir la organización a Internet se expone a las amenazas externas, tales como virus, troyanos, etc. Estas amenazas pueden conllevar problemas en el funcionamiento de los dispositivos de la red y de la propia red.

Para evitar estos dos problemas, es necesario en ocasiones limitar el acceso a sitios web no adecuados según los criterios del a organización. Ello se puede conseguir con el uso de un firewall o cortafuegos.

Un cortafuegos puede ser hardware (una máquina) o software (un programa), pero en ambos caos sus funciones son las mismas: ––limitar el acceso a determinados sitios externos desde el interior de la organización ––bloquear el acceso de usuarios no autorizados a la red interna

Unidad didáctica 1. Internet

Para lograrlo, en el cortafuegos se pueden configurar una serie de reglas que aceptan varios parámetros: ––puerto origen ––puerto destino ––IP origen ––IP destino ––franja horaria ––días de la semana, mes, etc.

Además para cada regla configurada en el firewall se pueden ejecutar una serie de acciones: ––denegar totalmente ––permitir totalmente ––cifrar la comunicación ––descifrar la comunicación, etc.

La configuración de un firewall es compleja y es importante dejarla en manos de un experto, ya que un firewall mal configurado puede impedir el correcto funcionamiento de la red (incluso se puede dejar sin acceso a la red si se configura mal).

Una Intranet es una red de ordenadores privada basada en los estándares de Internet. Una Intranet puede extenderse a Internet, pero para ello se necesita una red privada virtual (VPN).

Una Extranet es una Intranet extendida mas allá de los límites de la corporación.

Las Extranets abren el acceso a la red, aparte de los empleados de la organización,

49

50

Unidad didáctica 1. Internet

a personas cercanas a la misma, como proveedores, vendedores y distribuidores.

Ambas redes, Extranet e Intranet, pretender proteger a la organización de accesos no autorizados y de ataques.

El firewall o cortafuegos es una herramienta de seguridad que permite restringir el acceso a una red, bien sea por autenticación, por IP, por franja horarias, por contenido, etc.

Un firewall puede ser una aplicación software o un dispositivo hardware, funcionando en ambos casos de forma similar.

El firewall se suele colocar entre la red local e Internet para evitar ataques y accesos de personal sin autorización a la red local.

Otra de las herramientas de seguridad es el servidor Proxy, que es un dispositivo (normalmente un ordenador) que se sitúa entre el usuario e Internet y tiene diversos usos: ––Guardar un registro de las páginas visitadas ––Bloquear el acceso a ciertas páginas, filtrando contenidos.

––Proteger la identidad de la red, ya que cuando se navega a través de proxy, la IP que se identifica es la del proxy quedando la IP de la red “oculta”.

––Mejorar el rendimiento, al guardar en memoria caché las páginas web accedidas durante cierto tiempo, de forma que se usa esa copia en caché en lugar de volver a solicitarla.

02 La World Wide Web 2.1 Breve historia de la World Wide Web 2.2 Arquitectura general de la Web 2.2.1 Principios para el diseño de sistemas web 2.2.2 Componentes básicos de un sistema web 2.2.3 División en capas 2.3 El cliente web 2.3.1 Hardware básico. Dispositivos fijos y móviles 2.3.2 Sistemas operativos de uso común e Internet 2.3.3 Navegadores. Características y comparativa 2.3.4 Funcionalidades avanzadas: extensiones, aplicaciones específicas, etc 2.4 Servidores web

escalabilidad, balanceo de carga, alta disponibilidad, etc 2.6 Servidores de bases de datos 2.6.1 Servidores de bases de datos para Internet de uso común 2.6.2 Características básicas de un servidor de bases de datos 2.6.3 Funcionalidades avanzadas: conceptos de escalabilidad, alta disponibilidad, etc 2.7 Servidores complementarios en una arquitectura web 2.7.1 Servidores de correo. Características 2.7.2 Servidores de direccionamiento (DNS).

Características 2.7.3 Proxies

2.4.1 Servidores web de uso común

2.7.4 Servidores de directorio. Características de LDAP

2.4.2 Características básicas de un servidor web

2.7.5 Servidores de mensajería

2.4.3 Configuración de servidores web

2.7.6 Servidores de antivirus, filtrado de contenidos, etc

2.4.4 Seguridad en servidores web 2.4.5 Funcionalidades avanzadas: extensiones, servidores virtuales, etc 2.5 Servidores de aplicaciones

2.7.7 Otros servidores complementarios 2.8 Infraestructura hardware y software para servidores de Internet

2.5.1 Concepto de servidor de aplicaciones

2.8.1 Servicios en la nube (Cloud)

2.5.2 Características de los servidores de aplicaciones

2.8.2 Tipos de servicios: infraestructura como servicio, plataforma como servicio y aplicación como servicio

2.5.3 Comparativa de servidores de aplicaciones de uso común 2.5.4 Configuración de un servidor de aplicaciones 2.5.5 Seguridad en servidores de aplicaciones 2.5.6 Funcionalidades avanzadas: conceptos de

2.8.3 Ventajas e inconvenientes de los servicios de infraestructura en la nube 2.8.4 Comparativa de los servicios de infraestructura en la nube de uso común

52

Unidad didáctica 2. La word wide web

2. La World Wide Web 2.1 Breve historia de la World Wide Web Los hitos principales en la historia de la World Wide Web son: ––En los años cuarenta, Vannvar Bush propuso un sistema similar a la actual WWW: un sistema de información distribuida entramada .Este proyecto no pasó de la teoría.

––En los años cincuenta se hizo referencia a un sistema de hipertexto, fue el investigador Ted Nelson.

––En 1980 Tim Berners-Lee propuso ENQUIRE, donde se materializa la implementación práctica de este concepto.

––En 1989 el propio Tim Berners-Lee redactó la propuesta que describía el sistema de información. Se le denominaba MESH. ––Se publica una propuesta más formal en agosto de 1991 y se crearon el primer navegador web, el primer servidor web y las primeras páginas web.

––En abril de 1993, CERN anunció la gratuidad de la Web para todos los usuarios.

Unidad didáctica 2. La word wide web

2.2 Arquitectura general de la Web. 2.2.1 Principios para el diseño de sistemas web La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se reparten servidores, y los clientes. En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores y esto implementa ventajas de organización.

Esta separación cliente-servidor es lógica, no física, al poder ejecutarse cada uno de ellos en múltiples dispositivos.

Una arquitectura común son los sistemas multicapa en los que el servidor se divide en múltiples programas que pueden ser ejecutados en diferentes dispositivos.

La red cliente-servidor es aquella en la que todos los clientes se conectan a un mismo servidor, de esta forma los recursos son centralizados.

2.2.2 Componentes básicos de un sistema web Los componentes básicos para un sistema web son: ––lenguaje de los elementos del sistema: HTML. ––protocolo de transferencia del sistema: HTTP ––identificación de las páginas web del sistema: URI ––Hardware y software del servidor web ––Hardware y software del cliente web 2.2.3 División en capas Las principales ventajas de una división por capas de una arquitectura web son: ––Centralización del control: el servidor controla no solo los accesos, sino también los recursos y hasta la integridad de los datos.

––Escalabilidad: se puede aumentar la capacidad de los servidores de forma i n dependiente a los clientes y viceversa.

––Fácil mantenimiento: se puede actualizar, reparar o reemplazar un servidor de forma transparente a los clientes al estar distribuidos.

––Existen tecnologías adaptadas a los sistemas divididos en capas.

53

54

Unidad didáctica 2. La word wide web

––La principal desventaja de un sistema dividido en capas es la congestión del tráfico, ya que un cliente puede enviar múltiples peticiones de forma simultánea a un servidor y causarle problemas.

2.3 El cliente web 2.3.1 Hardware básico. Dispositivos fijos y móviles Para poder conectarse a un sistema web, un cliente puede optar por diferentes soluciones de hardware: ––ordenadores de sobremesa ––ordenadores portátiles ––notebooks ––teléfonos móviles (smartphones) ––pdas Las principales ventajas del uso de dispositivos móviles (todos los citados excepto los ordenadores de sobremesa) frente a los dispositivos fijos son: ––Son fácilmente transportables gracias a su reducido tamaño y peso.

––Se puede acceder a la web desde cualquier lugar (esto es relativo ya que debe disponer de una conexión) Los riesgos que presentan los dispositivos móviles son: ––La pérdida del dispositivo y con ella la de la información que contiene.

––Posible infección debido a programas maliciosos.

2.3.2 Sistemas operativos de uso común e Internet Casi todos los sistemas operativos soportan el uso de Internet. El problema en algunos de ellos es encontrar las aplicaciones (software) adecuado para algunos de los servicios Web, ya que si bien la navegación es implementada en todos los sistemas operativos, algunos otros servicios, como la mensajería instantánea puede ser difícil de implementar al no existir una aplicación adaptada al sistema operativo.

Por citar algunos de los sistemas operativos más usados para Internet: ––Windows ––Unix

Unidad didáctica 2. La word wide web

––Las distribuciones de Linux ––MAC OS X ––Android ––iOS ––Windows Phone ––Blackberry OS 2.3.3 Navegadores. Características y comparativa El navegador es la aplicación que posibilita que el cliente pueda ver las páginas web en su dispositivo. Como se ha comentado anteriormente, existen multitud de navegadores, algunos son específicos para dispositivos móviles, pro los más populares tienen versión para dispositivos fijos y móviles: ––Internet Explorer ––Mozilla Firefox ––Google Chrome ––Opera ––Safari ––Dolphin ––Skyfire ––Maxthon ––Netfron

55

56

Unidad didáctica 2. La word wide web

2.3.4 Funcionalidades avanzadas: extensiones, aplicaciones específicas, etc En los navegadores, las extensiones aplicaciones que se integran en el mismo y ofrecen diferentes funcionalidades: ––convertidor de formatos ––conversor de monedas ––visualizador de css ––diccionario ––traductor ––trabajar con redes sociales ––capturar instantáneas de la web ––etc.

2.4 Servidores web El servidor Web es un programa que corre sobre el servidor que escucha las peticiones HTTP que le llegan y las satisface. Dependiendo del tipo de la petición, el servidor Web buscará una página Web o bien ejecutará un programa en el servidor.

2.4.1 Servidores web de uso común Algunos de los servidores Web más populares son: ––Apache ––Internet Information Server (IIS) ––Ginx ––Tomcat

Unidad didáctica 2. La word wide web

Siendo los dos primeros citados los más usados: Apache en entorno Unix y IIS en entorno Windows.

2.4.2 Características básicas de un servidor web Si bien hay diferentes tipos de servidores web, para diferentes entornos, con diferentes configuraciones, hay una serie de características comunes a todos ellos.

Dado que los servidores web están construidos específicamente para alojar sitios web, sus funciones se centran generalmente en esto: creación y mantenimiento de alojamientos de sitios web. La mayoría de los servidores web tienen características que le permiten hacer lo siguiente: ––Crear uno o más espacios webs, entendiendo por espacios web los destinados a alojar un sitio web. Es decir, el servidor web no crea los sitios webs, sino que deja “un hueco” para que se pueden “meter en él”.

––Configurar las características de ficheros de log o registro, incluyendo ruta de los mismos, datos que van aguardar, etc.

––Configurar la seguridad de los espacios webs, indicando qué usuarios y con qué permisos pueden acceder a los mismos, qué IPs pueden visualizarlos, etc.

––Crear cuentas FTP para que los usuarios puedan transferir archivos entre su sitio local y el servidor.

––Crear directorios virtuales y asignarlos a los directorios físicos ––Configurar páginas de error personalizadas. Esto le permite crear y mostrar mensajes de error de usuario en los sitios web. Por ejemplo, puede especificar la página que se muestra cuando un usuario intenta acceder a una página que aún no existe (es decir, un “error 404”).

––Especificar documentos por defecto. Documentos por defecto son los que se muestra cuando no se especifica ningún nombre de archivo. Por ejemplo, si abre “http://www.paginaweb.com”, el archivo que se debe mostrar suele ser “index.html” o el que se configure, por ejemplo, inicio.html. Se pueden especificar varios nombres por defecto, de forma que el servidor vaya buscando sucesivamente entre los diferentes nombres por defecto especificados.

57

58

Unidad didáctica 2. La word wide web

2.4.3 Configuración de servidores web Los servidores web tienen un archivo de configuración en el cual se pueden especificar todas las características del apartado anterior y muchas más. Además en ese fichero se puede dar valor a ciertos parámetros importantes para el servidor web, algunos de los cuales son: ––tamaño máximo de los ficheros que se pueden subir.

––duración de las cookies.

––duración de las sesiones.

––ruta de los ficheros de registro.

––configuración de la memoria caché ––número máximo de procesos webs concurrentes ––etc.

Por ejemplo, este archivo de configuración en el caso de Apache se llama httpd. conf y es un archivo de texto.

2.4.4 Seguridad en servidores web Evidentemente la seguridad en un servidor web es muy importante para no comprometer las páginas webs alojadas en él. Algunas de las funciones de seguridad que se pueden implementar son: ––Crear reglas de acceso al servidor web, por ejemplo mediante firewalls.

Unidad didáctica 2. La word wide web

––Respaldo de la información.

––Ubicación del servidor en instalaciones con medidas de seguridad correctas.

––Existencia de un servidor web secundario para que en caso de que falle el primario, se ejecute éste. Para ello debe ser un duplicado en todo momento del principal.

2.4.5 Funcionalidades avanzadas: extensiones, servidores virtuales, etc Las extensiones son un conjunto de programas en el servidor Web que admiten características extras, la más habitual es permitir el alojamiento y ejecución de scripts en el servidor web. Para cada uno de los scripts habrá que activar su extensión correspondiente. Es decir, para ejecutar scripts ASP, habrá que activar una extensión, para scripts JavaScript otra, etc. Es importante que el control y configuración de estas extensiones se realice por personal experto, ya que los scripts pueden ser un peligro potencial para la seguridad del servidor Web. Un servidor virtual es un servidor web virtualizado lógicamente. De esa forma en una misma máquina se pueden correr diferentes servidores webs. Esto es lo que se está usando en empresas de hosting de modo que al usuario le da la impresión de tener un servidor web totalmente para él.

2.5 Servidores de aplicaciones 2.5.1 Concepto de servidor de aplicaciones Como su nombre indica, un servidor de aplicaciones es un servidor que ejecuta ciertas aplicaciones distribuidas a través de Internet (por ejemplo, banca electrónica o comercio electrónico).

2.5.2 Características de los servidores de aplicaciones Todos los servidores de aplicaciones cuentan con una serie de características comunes: ––incluyen software de conectividad para comunicarse con varios servicios.

––incluyen una APOI para facilitar al desarrollador su abstracción del sistema operativo o la interface.

59

60

Unidad didáctica 2. La word wide web

2.5.3 Comparativa de servidores de aplicaciones de uso común Algunos de los servidores de aplicaciones más usados son: -- Java EE -- JBoss -- GlassFish -- JOnAS -- Apache Geronimo -- Zend Server 2.5.4 Configuración de un servidor de aplicaciones A la hora de configurar un servidor de aplicaciones es muy importante tener en cuenta estos parámetros: ––estructura de sus diferentes directorios ––configuración de los puertos ––configuración de múltiples instancias ––integración con otros servidores, los más habituales son: -- servidor web -- servidor LDAP -- servidor de base de datos 2.5.5 Seguridad en servidores de aplicaciones Un servidor de aplicaciones debe contar con características que den soporte a aplicaciones seguras. Por ejemplo, en el caso de banca electrónica, los clientes se autentican contra el servidor de aplicaciones y éste debe proporcionar los mecanismos necesarios para que las transacciones sean seguras, no se vea comprometida la seguridad del usuario, etc.

Una de las formas de implementar la seguridad en un servidor de aplicaciones es usar un servidor LDAP. 2.5.6 Funcionalidades avanzadas: conceptos de escalabilidad, balanceo de carga, alta disponibilidad, etc La alta disponibilidad hace referencia a que el servidor esté activo 24x365, es decir todos los días del año a todas las horas.

Unidad didáctica 2. La word wide web

La escalabilidad es la capacidad que tenga el servidor para poder crecer según la demanda (no es lo mismo implementar un servidor de aplicaciones para un número determinado de usuarios que éstos se dupliquen, por ejemplo).

El balanceo de carga hace referencia a la técnica usada para distribuir las peticiones entre varios servidores.

2.6 Servidores de bases de datos 2.6.1 Servidores de bases de datos para Internet de uso común Los principales servidores de bases de datos son: ––MySQL ––Oracle ––SQL Server ––DB2

2.6.2 Características básicas de un servidor de bases de datos El servidor de base de datos se encargará de la gestión de las diferentes bases de datos del sistema, que incluye: ––Creación, edición y borrado de las bases de datos ––Creación, edición y borrado de las tablas ––Creación, edición y borrado de los usuarios de la base de datos ––Gestión de los permisos de los usuarios en las bases de datos ––Creación y manipulación de consultas ––Copias de seguridad de las bases de datos ––Protección de las bases de datos del exterior

61

62

Unidad didáctica 2. La word wide web

2.6.3 Funcionalidades avanzadas: conceptos de escalabilidad, alta disponibilidad, etc Al ser las bases de datos una de las herramientas más importantes actualmente, el servidor debe tener una serie de funcionalidad avanzadas como son: ––Alta disponibilidad: El servidor debe estar activo 365x24 (365 días al año, 24 horas diarias). Se debe prever que el servidor pueda fallar creando un servidor secundario, transparente al usuario.

––Escalabilidad: El servidor debe ser poder capaz de crecer si aumenta el numero de usuarios, la información de la base de datos, etc.

––Fiabilidad: Es importante que una serie de factores estén optimizados en un servidor para medir su fiabilidad: -- Tiempo medio entre fallos -- Tasa de errores no recuperables -- Capacidades de sustitución en caliente 2.7 Servidores complementarios en una arquitectura web 2.7.1 Servidores de correo. Características Un servidor de correo es el encargado de la gestión del correo electrónico. Existen una serie de características básicas de un servidor de correo, por ejemplo: ––Creación, edición y borrado de buzones de correo de usuarios ––Configuración de los buzones de correo, que incluye: -- limitar el tamaño máximo -- posibilidad de redirigir a otro buzón -- alias de email -- respuesta automática

Unidad didáctica 2. La word wide web

––Configuración de filtros antispam y antivirus ––Creación y gestión de listas de correo ––Configuración de Webmail

2.7.2 Servidores de direccionamiento (DNS). Características Como se ha indicado anteriormente, el servidor DNS es un traductor de nombres de IPS a nombre de páginas y viceversa.

Entre las características de todo servidor DNS se encuentran: ––Creación, edición y borrado de dominios. Para cada dominio se crea una zona.

––Asignar espacios web a dichos dominios (el espacio web se creará mediante el servidor web) ––Asignar a cada dominio sus servicios: -- IP a la que apunta -- Su servidor de correo -- Su servidor FTP -- Su servidor de nombres ––Creación de subdominios. Por ejemplo un dominio es paginaweb.com, un subdominio puede ser ocio.paginaweb.com. A todos los efectos el subdominio se comporta como otro dominio más con su propia configuración. El subdominio más habitual es el que comienza con www. Es decir, para el dominio paginaweb. com, un subdominio es www.paginaweb.com, que se puede configurar que apunte al mismo sitio o no.

2.7.3 Proxies Un servidor proxy actúa como intermediario en las peticiones de los clientes en busca de recursos de otros servidores. Un cliente se conecta al servidor proxy, solicitando algún servicio, tales como un archivo, conexión, página web, u otro recurso disponible desde un servidor diferente y el servidor proxy evalúa la solicitud como una manera de simplificar y controlar su complejidad. Hoy en día, la mayoría de los proxies son proxies web, lo que facilita el acceso a contenidos en la World Wide Web. Un servidor proxy tiene muchos propositivos, algunos de los cuales son:

63

64

Unidad didáctica 2. La word wide web

––mantener el anonimato de las maquinas que se encuentran por detrás, para la seguridad.

––acelerar el acceso a recursos, mediante el uso de caché.

––evitar la descarga del mismo contenido varias veces ––analizar el contenido transmitido en busca de malware antes de la entrega.

––analizar el contenido de salida, por ejemplo, para la prevención de pérdida de datos.

––aplicar la política de acceso a los servicios de red o contenidos, por ejemplo, para bloquear los sitios no deseados.

––permitir que un sitio web haga peticiones web a los recursos o contenidos alojados externamente) cuando las restricciones entre dominios prohíben el sitio web de vincular directamente a los dominios externos.

2.7.4 Servidores de directorio. Características de LDAP LDAP (Lightweight Directory Access Protocol) es un protocolo que permite el acceso a un servicio de directorio distribuido. Es un sistema de gestión de directorios.

Un ejemplo típico del uso de LDAP es la gestión de usuarios en una maquina, mediante LDAP se configura: ––Creación, edición y borrado de los usuarios ––Creación y mantenimiento de claves de usuario ––Gestión de los permisos de usuario ––Gestión de los recursos de cada usuario

2.7.5 Servidores de mensajería Como se ha visto anteriormente, lo servicios de mensajería instantánea son los más usados actualmente en la web, para poder trabajar con ellos el servidor de mensajería debe configurarse de forma correcta.

Uno de los servidores de mensajería instantánea más populares es XMPP, usado en muchas aplicaciones actuales como Google Talk.

Unidad didáctica 2. La word wide web

2.7.6 Servidores de antivirus, filtrado de contenidos, etc Como complemento de seguridad a los anteriores servidores se pueden instalar y configurar unos servidores de antivirus para proteger de ataques, accesos no autorizados, etc.

En caso de no contar con un servidor proxy existen servidores específicos de filtrado de contenido, por ejemplo por palabras claves. Esto es muy útil para el control parental de acceso de los hijos a la Web. 2.7.7 Otros servidores complementarios Existen muchos más tipos de servidores que según las características del usuario se implementarán o no. Por citar alguno de esos servidores: ––Servidor DHCP: Asigna direcciones IPs dinámicas a los clientes de la red. Se puede configurar también para que las direcciones sean estáticas.

El fichero de registro de un servidor DHCP es muy importante, ya que, en caso de que un usuario de la red realice un acceso no autorizado a algún sitio, el servidor DHCP tiene un registro de qué usuario tenía una determinada IP en cada momento.

––Servidor de impresión: Controla todas las impresoras y los trabajos de impresión de la red. Esto es muy útil en organizaciones grandes.

65

66

Unidad didáctica 2. La word wide web

––Servidor de noticias: Gestiona y controla las news, uno de los servicios webs ahora algo en desuso.

––Servidor de telefonía: Realiza funciones de centralita, como buzón de voz, r e direccionamiento de llamadas, colas de espera, etc.

2.8 Infraestructura hardware y software para servidores de Internet 2.8.1 Servicios en la nube (Cloud) Se puede definir la nube como un conjunto de hardware, redes, almacenamiento, servicios, y las interfaces que permiten usar la informática como un servicio.

Los servicios en la nube incluyen la entrega de software, la infraestructura, y el almacenamiento de información a través de Internet (ya sea como componentes separados o una plataforma completa) en base a la demanda del usuario. De esta forma, se proporciona el acceso a servicios informáticos de una manera eficaz, fácil y cómoda, sea cual sea el soporte físico o su emplazamiento, siempre y cuando se disponga de una conexión a Internet.

Los proveedores de servicios tradicionales de las tecnologías de la información manejan el hardware, software, redes, y el almacenamiento de sus clientes. Así, el cliente firma un contrato a largo plazo que especifica de mutuo acuerdo con los niveles de servicio. Estos proveedores de TI suelen personalizar un entorno para satisfacer las necesidades de un cliente.

Frente al modelo tradicional, en el modelo de la nube, el proveedor de servicios todavía aún puede manejar la infraestructura en sus propias instalaciones (excepto en el caso de una nube privada). Sin embargo, la infraestructura también puede ser virtualizada, lo cual de cara al usuario significa que no se puede saber donde están sus recursos informáticos, aplicaciones, o datos en realidad.

Según dónde se encuentren instaladas las aplicaciones y qué clientes puedan usarlas se realiza la siguiente clasificación de tipos de nubes: ––La nube pública El propietario es un proveedor que se encarga por el usuario de su mantenimiento y el usuario paga por el uso de los servicios que ofrece a través de Internet.

Los archivos y documentos de muchos usuarios están mezclados en los servidores e infraestructuras de la nube.

Unidad didáctica 2. La word wide web

––La nube privada Están en una infraestructura en demanda. Cada usuario es propietario del servidor y de la red y de esta forma tiene el control para instalar las aplicaciones donde mejor crea conveniente. De esta forma se garantiza una mayor seguridad y privacidad de datos.

Las características de la nube privada son las siguientes: -- Automatiza las tareas de administración -- Proporciona un entorno bien gestionado -- Optimiza el uso de los recursos informáticos como servidores -- Soporta cargas de trabajo específicas -- Proporciona autoservicio de recursos hardware y software ––La nube híbrida Es una mezcla de la nube pública y de la nube privada. Los usuarios comparten una parte de forma limitada y tiene acceso privado a otra parte.

––La nube comunitaria 2.8.2 Tipos de servicios: infraestructura como servicio, plataforma como servicio y aplicación como servicio Estos servicios en la nube son distribuidos desde la capa Hardware hasta la capa Aplicación Software de un sistema informático. Atendiendo a las necesidades de los usuarios, al modelo de servicio que ofrecen y a cómo se despliegan dichos modelos en la nube, se pueden agrupar estos servicios en tres niveles:

67

68

Unidad didáctica 2. La word wide web

––IaaS (Infraestructure as a Service) o Infraestructura como Servicio Permite utilizar recursos informáticos hardware de un proveedor en forma de servicio. Estos recursos pueden ser servidores, sistemas de almacenamiento, routers, etc., y con esto se consigue ampliar o reducir los recursos informáticos físicos en un corto espacio de tiempo. Este nivel de cloud computing ofrece la posibilidad de acceder a máquinas y a almacenamiento a través de Internet de forma muy rápida.

Algunos ejemplos de proveedores que ofrecen este tipo de servicios son: -- Amazon Web Services.

-- GoGrid.

-- RackSpace.

––PaaS (Platform as a Service) o Plataforma como Servicio Suministra desde la “nube” todos los componentes necesarios para el desarrollo de nuevas aplicaciones informáticas escritas en un lenguaje que soporte la plataforma. El servicio que ofrece integra tanto el entorno de desarrollo como la Interfaz de Programación de Aplicaciones (API, Application Programing Interface).

Algunos ejemplos de proveedores que ofrecen este tipo de servicios son: -- Velneo Paas.

-- Google App Engine.

––SaaS (Software as a Service) o Software como Servicio De los tres nivel de Cloud Computing es el más conocido. Suele tener como usuario al cliente final que utiliza el software para ayudar, mejorar o cubrir algunos de los procesos profesionales más habituales. Ofrece una variedad de

Unidad didáctica 2. La word wide web

aplicaciones proporcionadas por los proveedores del servicio y que se ejecutan en la infraestructura de la “nube”. De forma habitual, el cliente accede a dichas aplicaciones mediante una simple interfaz como puede ser un navegador web.

Algunos ejemplos de proveedores que ofrecen este tipo de servicios son: -- Litebi.

-- AparasW. -- Everilion.

-- ASPGems.

-- Zoho.

-- Google Apps.

Figura: Representación gráfica de los tres nivel de Cloud Computing.

2.8.3 Ventajas e inconvenientes de los servicios de infraestructura en la nube Cloud Computing permite: –– No tener que guardar la información solamente en soportes físicos. Esto evita tener que instalar aplicaciones en nuestros sistemas informáticos. De este modo, éstos se pueden ejecutar directamente desde la nube a través de la Red, ahorrando recursos con ello.

––Compartir recursos a través de la Red, en distintos dispositivos. Esto implica la posibilidad de trabajar conjuntamente sobre el mismo contenido.

69

70

Unidad didáctica 2. La word wide web

Entre las ventajas que ofrece los servicios en la nube se pueden citar:

––Se puede acceder a los archivos, documentos y aplicaciones que estén en la nube desde cualquier ordenador con acceso a Internet en cualquier parte del mundo.

––No requiere disponer de licencias múltiples. Antes se adquirían por volumenpero, desde que se trabaja en la nube, el sistema de licencias es por suscripción, normalmente mensual o anual.

––La nube es multiplataforma y por tanto, no se necesitan sistemas operativos ni plataformas especiales y por tanto se puede acceder desde dispositivos con Windows, Mac OS, Linux, Android, etc.

––No requiere de dispositivos de almacenamiento de gran tamaño como discos duros o similares.

––No se necesita tener servidores propios.

––Existen una gran variedad de aplicaciones y servicios, a los cual se puede acceder de forma inmediata sin adquirir hardware o software.

––Se reduce de forma sustancial la inversión de hardware, y esto se traduce en una disminución en los costes de mantenimiento de los equipos.

Respecto a las desventajas del Cloud Computing se pueden indicar las siguientes: ––Al ser la información accesible a través de la Red, tiene más peligro de poder ser vulnerada y accedida.

recuerde Cloud Computing es el suministro y gestión de datos y aplicaciones a través de Internet. Los tres niveles de Cloud Computing son Iaas, Paas y SaaS.

Unidad didáctica 2. La word wide web

––Es imprescindible tener una conexión a Internet para poder trabajar con estos servicios. Si la conexión falla, no se puede realizar ninguna tarea con ellos.

––Los servicios están limitados por la capacidad del proveedor.

––Se depende totalmente del proveedor, así, si por ejemplo falla algún servicio, para la resolución de la incidencia se depende de su horario y capacidad de respuesta.

2.8.4 Comparativa de los servicios de infraestructura en la nube de uso común CORREO ELECTRONICO Uno de los servicios más utilizados en es el correo electrónico en Internet o Webmail.

Se trata de un servicio SaaS que consiste consistente en el almacenamiento del correo electrónico en la nube. Se puede de enviar y recibir información a través de Internet, mediante el uso de funciones similares a las que habitualmente nos ofrece un programa cliente de correo.

Entre los webmail más conocidos y usados destacan: -- Gmail -- Outlook.com (anteriormente Hotmail) -- Yahoo A la hora de elegir un webmail es importante tener en cuenta varios factores: ––Capacidad de almacenamiento: Es decir, qué tamaño de correo se puede tener en el mismo.

––Tamaño máximo permitido en el envío o recepción de emails: Según el email el tamaño máximo que se puede recibir o enviar puede ser el mismo o diferente, habiendo diferencias importantes entre diferentes webmails.

––Disponibilidad de herramientas adicionales al tratamiento del correo, como por ejemplo: -- Filtros de mensajes -- Organización de correos en carpetas -- Firma de correos -- Libreta de direcciones -- Agenda

71

72

Unidad didáctica 2. La word wide web

DISCO DURO VIRTUAL Los discos duros virtuales son servicios SaaS que permiten el almacenamiento online de la información y el uso compartido de ficheros entre grupos de usuarios. Además, estos servicios son utilizados para generar copias de seguridad previniendo así la pérdida de datos más susceptible en entornos locales.

Las características más importantes de estos servicios son: ––Acceso a la última versión de nuestros archivos desde cualquier sistema operativo.

––Acceso a nuestros documentos y archivos a través de dispositivos móviles.

––Uso compartido de nuestros documentos simplemente a través de una conexión a Internet.

––Los discos duros más conocidos y usados son: -- Microsoft Windows Live SkyDrive -- Dropbox -- Google Drive -- Ubuntu One. COMUNICACIONES La comunicación en la nube es uno de los servicios más importantes dentro del mundo empresarial. Entre sus beneficios se pueden citar: ––Rapidez para contar con los servicios solicitados.

––Los servicios en la nube se pagan por uso y por tanto se puede conocer e forma anticipada su precio.

––Escalabilidad, estandarización y agilidad.

Para que los servicios de comunicaciones sean óptimos deben ser funcionales, por tanto la clave es buscar proveedores que ofrezcan las mejores soluciones para nuestras necesidades.

Las comunicaciones en la nube se basan fundamentalmente en los siguientes servicios: -- Red de voz privada.

-- Videocomunicación.

Unidad didáctica 2. La word wide web

-- Software social corporativo.

-- Mensajería unificada.

-- Convergencia y aplicaciones móviles.

Dentro del apartado de comunicaciones destaca el uso cada vez más aceptado de los servicios de Voz sobre Protocolo Interneto o VoIP (Voice Over IP).

La VoIP se define como todos los recursos que permiten que en lugar de usar las líneas telefónicas para el transporte de la voz, se use Internet. Para esto, se usa la señal de voz en forma digital en formato de paquetes.

Los componentes principales de una red VoIP son: ––Servidor PBX: Es una centralita telefónica similar a una centralita física pero en la red y con las mismas funcionalidades que una centralita física: gestión de llamadas entrantes y salientes, transferencias de llamadas, gestión de colas, buzón de voz, restricciones horarias, audio de espera, etc.

––Teléfonos IP: Teléfonos diseñados para trabajar en líneas de datos. son otro elementos de la red local y por tanto disponen de dirección IP, MAC, máscara de red, puerta de enlace y DNS. Estos teléfonos se autentican contra el servidor PBX para poder realizar y recibir las llamadas.

Un modelo de servicios de VoIP en la nube es Skype, el cual es un software que permite las comunicaciones de voz, vídeo y texto a través de Internet, pero para ello tanto emisor como receptor tiene que tener instalado este software. Aunque Skype también incluye una característica denominada YYSkypeOut, la cual permite a los usuarios efectuar llamadas a teléfonos tradicionales, con un precio mucho más asequible que las tarifas de telefonía convencional.

INTRANETS Una intranet es una red interna, por ejemplo, la de una empresa, que utiliza tecnologías semejantes a las usadas en Internet. Es propiedad de una organización o empresa y sólo pueden acceder a ella las personas que forman parte de dicha

73

74

Unidad didáctica 2. La word wide web

organización. Se puede decir que es como un pequeño Internet pero sólo para un entorno determinado. Para impedir el acceso de personas ajenas a la empresa se utilizan diferentes medidas de seguridad como, por ejemplo, el uso de firewalls o cortafuegos.

Usando una intranet, las aplicaciones ofimáticas, las presentaciones, documentos de texto, calendarios, agendas, etc., alojadas en la nube, pueden ser utilizados a través de la red, con lo que el trabajo colaborativo se ve implementado sin necesidad de que los usuarios tengan que permanecer en el mismo sitio físico.

Existen muchas herramientas que permiten crear intranets, por ejemplo: ––SharePoint Online, solución de pago que permite crear un sitio de grupo sólo disponible para los usuarios invitados y a los que se les concedan privilegios.

––Zyncro, solución gratuita que permite crear una intranet sin necesidad de muchos conocimientos previos.

EJEMPLO DE CLOUD COMPUTING GRATUITO: GOOGLE Para entender el Cloud Computing con un ejemplo clarificador por su uso actual, se va a hablar de Google, en el cual sus herramientas en su mayor parte son gratuitas.

Algunas de los servicios en la nube ofrecidos por Google son: ––Acceso al correo electrónico desde cualquier lugar con Gmail.

––Organizar con Calendar la agenda diaria y la posibilidad de recibir recordatorios de los eventos en el dispositivo móvil.

––Trabajar con Drive para acceder desde nuestro ordenador o dispositivo móvil a la última versión de los archivos que hemos guardado.

––Crear documentos, hojas de cálculo, presentaciones, dibujos y formularios desde Docs. Estos ficheros se pueden compartir y pueden ser accedidos desde cualquier lugar con conexión a Internet.

––A través de la herramienta Sites se pueden crear sitios webs o espacios compartidos.

03 Aplicaciones web 3.1 Evolución y tipos de aplicaciones informáticas 3.1.1 Aplicaciones de terminal. Servidores de terminales virtuales 3.1.2 Aplicaciones de escritorio 3.1.3 Aplicaciones cliente/servidor 3.1.4 Aplicaciones web 3.1.5 Ventajas e inconvenientes de los tipos de aplicaciones.

Comparativa 3.2 Tecnologías de desarrollo de aplicaciones 3.2.1 Características por tipo de aplicación 3.2.2 Comparativa según el tipo de aplicación 3.3 Tecnologías específicas para el desarrollo web 3.3.1 Portales de Internet. Características 3.3.2 Gestores de contenidos: servidores de portales y documentales 3.3.3 Servidores de contenidos multidispositivo 3.3.4 Componentes básicos en portales web. Portlets y otros componentes de uso común 3.3.5 Características y comparativa de los portales web de uso común

76

Unidad didáctica 3. apicaciones web

3. Aplicaciones web 3.1 Evolución y tipos de aplicaciones informáticas Desde la aparición de Internet, los desarrolladores de software han tratado de realizar aplicaciones comerciales que corran en la Web (es decir, hacer que la aplicación se ejecute en un navegador). Inicialmente los desarrolladores lograron esto mediante el uso de extravagantes aplicaciones que devolvían la misma aplicación de escritorio a través del navegador, aunque generalmente tenían problemas de rendimiento o volviendo a desarrollar la aplicación utilizando las herramientas y lenguajes de Java.

El problema con este enfoque fue que muchos de estas primeras tecnologías no proporcionaron las extensas capacidades de interfaz de usuario que estaban disponibles en las aplicaciones de escritorio. Además, Internet era dependiente de un modelo de entrega de solicitud-respuesta basado en páginas y HTML. Por lo tanto, los desarrolladores terminaron con aplicaciones que tenían serias limitaciones en cuanto a su funcionalidad, complejidad y experiencia del usuario en comparación con sus aplicaciones de escritorio semejantes. Los usuarios quedaron decepcionados y frustrados con una experiencia de usuario que parecía más como paginación a través de un sitio Web que estar trabajando con una aplicación empresarial.

A pesar de la naturaleza de bajo rendimiento de las aplicaciones que se están desarrollando para la Web, Internet se convirtió rápidamente en la plataforma dominante para la prestación de los proveedores de aplicaciones de software.

A medida que crecía la frustración de la comunidad de usuarios finales, empresas como Macromedia (adquirida por Adobe) y otros se dedicaron a ofrecer tecnologías como AJAX y Flex que permite las “páginas” de las aplicaciones ser más interactivas y dinámicas. En este tiempo se acuño el término “Rich Internet Application”.

recuerde Los tipos de aplicaciones evolucionan al ritmo que lo hacen as tecnologías (software y hardware) en que se basan.

Unidad didáctica 3. apicaciones web

En pocas palabras, una “aplicación rica de Internet” (o RIA) es una aplicación que se ejecuta dentro de un navegador (ya sea en línea o fuera de línea), que opera con las mismas características dinámicas y cuenta con una interactividad como cualquiera de las aplicaciones de escritorio. Aunque esto fue hace ya unos años, sólo recientemente se ha comprobado la disponibilidad de las herramientas y tecnologías necesarias para desarrollar aplicaciones de Internet verdaderamente dinámicas.

3.1.1 Aplicaciones de terminal. Servidores de terminales virtuales Un terminal virtual en línea es una aplicación basada en la web se puede acceder desde cualquier ordenador que tenga conexión a Internet con un nombre de usuario y contraseña.

Una vez iniciada la sesión, se habilita el módulo de procesado de tarjetas de crédito. Mediante una interfaz de línea gráfica de usuario (GUI), el usuario puede (de forma manual) introducir los datos de su tarjeta de crédito y llevar a cabo cualquier operación de pago.

Los terminales virtuales son a menudo utilizados por los empresarios en línea.

Estos en muchas ocasiones no tienen el volumen de negocio que justifica la plena integración de un sistema de pago en línea automatizado, y utilizan el terminal virtual como un medio que les soluciona el problema, usándolo hasta que la actividad comercial crece a un sitio automatizado a gran escala.

La mayoría de los negocios en línea, incluso si cuentan con un sistema de pago completamente integrada en sus aplicaciones, mantienen una conexión de terminal virtual para realizar una copia de seguridad.

Los terminales virtuales de hoy en día suelen ser: ––fáciles de usar, ––accesibles por medio de SSL, ––activan la autorización de las operaciones de liquidación, ––a prueba de fraude AVS y CVV y ––soportan el acceso de múltiples usuarios con diferentes permisos.

Al elegir un proveedor de terminal virtual, se debe comprobar todos los demás aspectos de procesamiento de tarjetas de crédito, tales como: ––cuenta por parte del comerciante vs procesamiento hecho por terceros, ––las capacidades de gestión del fraude, ––herramientas comerciales y de informes, ––tarifas y planes de pago.

77

78

Unidad didáctica 3. apicaciones web

3.1.2 Aplicaciones de escritorio Una aplicación de escritorio es aquella que se ejecuta en un ordenador de sobremesa o portátil, en contraste con la “aplicación basada en Web”, que requiere que el navegador Web para funcionar.

3.1.3 Aplicaciones cliente/servidor Una aplicación de cliente/ servidor es una unidad de software que se ejecuta en un equipo cliente y realiza peticiones a un servidor remoto. Muchas de estas aplicaciones están escritas en lenguajes de programación visuales de alto nivel, usando interfaz de usuario, formularios, y la mayoría de la lógica de negocio reside en la aplicación cliente. A menudo, este tipo de aplicaciones son aplicaciones de bases de datos que hacen que las consultas de base de datos a un servidor de base de datos central a distancia.

Una aplicación de cliente/ servidor puede ser multiplataforma, si está escrito en un lenguaje multiplataforma, o puede ser específico de la plataforma. En el caso de un lenguaje de plataforma cruzada existe la ventaja de que la aplicación potencialmente puede proporcionar una interfaz de usuario que es nativa en apariencia al sistema operativo o entorno de la plataforma que se está ejecutando.

Otra característica de cliente/ servidor es que la aplicación debe estar instalado en cada ordenador de los usuarios.

3.1.4 Aplicaciones web

recuerde Las aplicaciones de escritorio sólo precisan de un equipo informático, las cliente/ servidor precisan de una máquina local y otra remota, y las aplicaciones web precisan de un navegador. Los servidores de terminal permiten el pago de los servicios de forma segura, y se usan en aplicaciones web.

Una aplicación web es una aplicación que se tiene acceso por los usuarios a través de una red tal como Internet o una intranet. El término también se puede referir a una aplicación de software que se codifica en un lenguaje de programación soportado por un navegador y dependiente de un navegador web para hacer que se ejecute de la aplicación.

3.1.5 Ventajas e inconvenientes de los tipos de aplicaciones. Comparativa Ventajas de las aplicaciones web para los usuarios: ––No precisan de instalación ni de actualización ––Se puede acceder desde cualquier lugar con Internet

Unidad didáctica 3. apicaciones web

––Los datos se almacenan remotamente ––Presentan compatibilidad entre plataformas, al igual que las cliente/ servidor ––Son más adecuadas para equipos de gama baja y requieren poco espacio en disco ––El equipo cliente está mejor protegido contra los virus usando un antivirus dentro de un navegador Las desventajas de las aplicaciones web para los usuarios: ––los usuarios cuentan con una mayor experiencia en el uso de aplicaciones de escritorio ––las aplicaciones web requiere acceso a Internet ––el servidor remoto podría verse comprometido si se filtrase de información privada Ventajas de las aplicaciones web para los desarrolladores: ––son más fáciles de controlar las acciones del usuario, obtener estadísticas completas y comentarios ––se puede optar por controlar totalmente el código del lado del servidor, por lo que es imposible de piratear ––es más fácil para añadir posibilidades de colaboración como datos que se almacenan en el servidor ––es más fácil hacer una versión móvil si utiliza HTML y JS ––presentan una integración fácil con los servicios web Desventajas de las aplicaciones web para desarrolladores ––al no ser una aplicación nativa que tiene un montón de restricciones y limitaciones ––menos herramientas y marcos para el desarrollo

79

80

Unidad didáctica 3. apicaciones web

Las aplicaciones web tienen muchas ventajas, por ejemplo, no requiere instalación y actualización de lo que ahorra una gran cantidad de trabajo de administración a las grandes empresas. También son buenos para los usuarios que tienen más de un ordenador, ya que todos sus datos y el software que se use es accesible en varios dispositivos.

También se vuelve más importante que las aplicaciones web son multiplataforma y trabajar en diferentes sistemas operativos.

Sin embargo, las aplicaciones web tienen algunas desventajas. El problema más importante en las aplicaciones web en este momento es su pobre experiencia, debido a los problemas de rendimiento y limitaciones del navegador. Pero el poder de procesamiento de equipo va acelerándose de manera exponencial (por la ley de Moore), lo que combinado con las mejoras en el rendimiento del navegador, podemos estar seguros de que este problema se resolverá muy pronto.

recuerde Las aplicaciones web presentan numerosas ventajas frente al resto de aplicaciones, si bien precisan de una mayor seguridad para el intercambio de datos y se enfrentan a un gran obstáculo: el costumbrismo de los usuarios, habituados a usar aplicaciones de escritorio.

Otra limitación importante de las aplicaciones web es el requisito de la conexión a Internet. Pero esto está cambiando debido al Internet móvil y la banda ancha móvil que se está haciendo más rápida y más barata.

3.2 Tecnologías de desarrollo de aplicaciones El Desarrollo de Aplicaciones Web es un campo de soluciones de las tecnologías de la información que proporciona una amplia gama de servicios de desarrollo de aplicaciones web, tales como el uso de php, asp, .net, flash, Java, AJAX, flex… en dicho desarrollo.

La tecnología está cambiando a un ritmo rápido, las aplicaciones web desarrolladas con la ayuda de las tecnologías antiguas y obsoletas no pueden ofrecer un rendimiento que es a la par con los estándares del sector.

Unidad didáctica 3. apicaciones web

Actualmente se trabaja con las últimas tecnologías web tales como: –– XML (Extensible Markup Language) –– Programación Ajax (Asynchronous JavaScript and XML) –– LAMP (Linux, Apache, MySQL & PHP) –– Tecnología Microsoft .Net –– Adobe Flash Multimedia –– Tecnología Multimedia Silverlite –– Lenguaje de programación Java –– Tecnología Web 2.0 3.2.1 Características por tipo de aplicación.

Cuando se enfrenta a la elección de una tecnología para la implementación de una aplicación web se deben tomar en cuenta muchas consideraciones. La elección de la tecnología debe ser adecuada de las necesidades del negocio y los requisitos de la aplicación, en lugar de dejarse arrastrar por la moda (como ahora mismo es la nube, o el último lenguaje de programación).

Los principales factores son: –– ¿Cuál es el tamaño de la aplicación?

–– ¿Es necesario que la aplicación tenga escala?

–– ¿Cómo de robusta ha de ser la aplicación?

–– Código abierto o cerrado –– Se trata de una empresa o de aplicación web simple?

–– El coste de desarrollo –– Conjunto de habilidades en el mercado –– Preferencias del cliente 3.2.2 Comparativa según el tipo de aplicación.

Vamos a comparar las siguientes tecnologías: AJAX: Ventajas: –– Fácil de aprender, similar a usar JavaScript, HTML y CSS. –– Hay un gran número de desarrolladores (más experiencia, más foros, etc.)

–– Cuenta con muchos entornos para acelerar el desarrollo.

–– Tiene muchos recursos en la web.

–– Rápido de aprender.

81

82

Unidad didáctica 3. apicaciones web

Desventajas: –– Requiere testeo y depuración constante.

–– El mercado AJAX está muy dividido.

–– Aunque hay muchos desarrolladores no hay un referente oficial al que seguir.

ADOBE FLEX: Ventajas: –– Penetración del Flash Player en más del 98% de los ordenadores del mundo.

–– Flex Builder es un entorno de desarrollo veloz.

–– Soporta ActionScript 3.0, XML y CSS. –– Cuenta con muchos desarrolladores y muchos recursos.

–– Flex 3 SDK es de código abierto.

–– Permite la integración con aplicaciones JavaScript y AJAX. Desventajas: –– Está enfocado al Flash Player, que no es abierto, sino propiedad de Adobe.

Microsoft Silverlight: Ventajas: –– Muchas herramientas (Expresion Studio para diseñadores, Visual Studio para desarrolladores).

–– Muchos desarrolladores .NET Desventajas: –– El formato de video soportado tiene una menor penetración en los equipos a nivel global.

–– No soporta Linux.

JavaFX: Ventajas: –– Fuerte y robusto.

–– Retiene la estructura, permite la reutilización y encapsulación de código Java.

Unidad didáctica 3. apicaciones web

–– Soporte en aplicaciones móviles.

–– Muchos desarrolladores y comunidades.

Desventajas: –– No es un proyecto maduro.

–– Las aplicaciones se interpretan, no hay compilador.

–– Si no se es familiar con Java, puede ser de aprendizaje lento.

–– La productividad de desarrollo es baja.

3.3 Tecnologías específicas para el desarrollo web 3.3.1 Portales de Internet. Características Los portales web se organizan en pasarelas, que ayudan a estructurar el acceso a la información que se encuentra en Internet. Son mucho más que un simple motor de búsqueda, por lo general incluyen un acceso personalizado a los datos, tales como noticias (de varios tipos), informes de bolsa, y los servicios de correo electrónico. La mayoría de los portales más conocidos son comúnmente identificados como motores de búsqueda, a pesar de que ofrecen mucho más que simplemente la capacidad de buscar en la Internet.

Mientras que muchas personas asumen que el portal web ha existido desde la invención de la Internet, esto no es verdad. Las primeras herramientas que se utilizan para tener acceso a los datos en línea son simples motores que permiten a los usuarios buscar palabras clave o frases clave para encontrar páginas en línea, y que se conocen como directorios web. Posteriormente se posibilitó ampliar el uso de esta función para incluir una dirección web específica como medio de conexión con un sitio web, estas herramientas se desarrollaron en lo que se conoce como un motor de búsqueda.

3.3.2 Gestores de contenidos: servidores de portales y documentales Un sistema de gestión de contenidos web (WCMS) es un sistema de software que ofrece creación de página web y herramientas de administración diseñadas para permitir a los usuarios con pocos conocimientos en lenguajes de programación web (o lenguajes de marcado) crear y gestionar contenidos web con relativa facilidad. Un WCMS robusto proporciona la base para la colaboración, ofreciendo a los usuarios la capacidad de gestionar los documentos y dar salida a la edición de múltiples autores.

83

recuerde La tecnología a usar para la implementación de las aplicaciones ha de ser concienzudamente evaluada para adecuarse a las necesidades de la aplicación y de su entorno, sin olvidar el usuario final de las mismas.

84

Unidad didáctica 3. apicaciones web

La mayoría de los sistemas utilizan un repositorio o una base de datos para almacenar contenido de la página, los metadatos y otros activos de información que podrían ser necesarios por el sistema.

Una capa de presentación (motor de plantillas) mostrará el contenido a los visitantes del sitio usando un conjunto de plantillas para mostrarlos, como por ejemplo los archivos XSLT. La mayoría de los sistemas utilizan el lado de almacenamiento del servidor en caché para mejorar el rendimiento. Esto funciona mejor cuando los WCMS no se cambian a menudo, pero hay visitas regulares.

La administración también se realiza a través de interfaces basadas en el navegador, pero algunos sistemas requieren el uso de un cierto tipo de cliente.

Un WCMS permite a los usuarios no técnicos a realizar cambios en un sitio web con poco entrenamiento. Un WCMS normalmente requiere de un administrador de sistemas y/ o un desarrollador web para configurar y agregar características, pero es sobre todo una herramienta de mantenimiento del sitio web para el personal no técnico.

3.3.3 Servidores de contenidos multidispositivo Los servidores Web no siempre se utilizan para servir en Internet (WWW).

Pueden también encontrarse incrustados en dispositivos tales como impresoras, routers, cámaras web y que sirven sólo en una red local. El servidor web puede entonces ser utilizado como una parte de un sistema para el seguimiento y/ o la administración del dispositivo en cuestión. Esto generalmente significa que no se tiene que instalar ningún software adicional en el equipo cliente, ya que sólo se requiere un navegador web (que actualmente se incluye en la mayoría de las distribuciones de los sistemas operativos).

3.3.4 Componentes básicos en portales web. Portlets y otros componentes de uso común.

Un portlet es un componente Web basado en Java que procesa las solicitudes de un contenedor de portlets y genera contenido dinámico. El contenido generado

Unidad didáctica 3. apicaciones web

por un módulo de función se llama fragmento, que es una pieza de marcado (por ejemplo, HTML, WML, XHTML) que se adhiere a ciertas reglas. Un fragmento se puede agregar con otros fragmentos para formar un documento completo, que llama a la página del portal.

Además de las características de motores de búsqueda estándar, los portales de Internet ofrecen otros servicios tales como el correo electrónico, las noticias, las cotizaciones bursátiles, bases de datos y el entretenimiento. Los portales proporcionan una manera para que las empresas a proporcionar el control y los procedimientos para múltiples aplicaciones y bases de datos, que de otro modo habrían sido diferentes entidades integradas.

3.3.5 Características y comparativa de los portales web de uso común Aunque ha habido muchos portales en toda la historia de Internet, en este capítulo nos centraremos en comparar los que hoy en día copan la gran mayoría del mercado:Yahoo! y Google.

Yahoo tiene varios servicios además del motor de búsqueda original y correo electrónico; Yahoo News,Yahoo Mobile,Yahoo Messenger,Yahoo Music,Yahoo Finance, etc.También cuenta con la nueva generación de Internet móvil WEB 2.0 en forma de feed RSS. Ofrece servicios de redes sociales y el contenido generado por los usuarios en productos como Mi Web,Yahoo! Contactos,Yahoo! 360 º, y Flickr.

Yahoo también ha firmado acuerdos de colaboración con diferentes proveedores de banda ancha tales como AT & T, Verizon Communications, Rogers Communications y British Telecom, que ofrece una serie de gratuitos y de pago, contenidos y servicios de Yahoo a los suscriptores. También, a través de estas redes se está dando a los usuarios móviles de las características de Yahoo y el servicio de Messenger.

Yahoo también presentó su sistema de búsqueda en Internet, oneSearch, desarrollado para teléfonos móviles el 20 de marzo de 2007. OneSearch es diferente de búsquedas realizadas en la Web, ya que el nuevo servicio de Yahoo presenta una lista de información actual, que incluye: titulares de noticias, imágenes de Flickr fotos del sitio de Yahoo, listados de negocios, el clima local y enlaces a otros sitios.

También contiene foros para usuarios de Yahoo para dar su opinión sobre las futuras tecnologías de Yahoo.

Yahoo también tiene una interfaz multilingüe, conocido como Yahoo Internacional.

Así que la dirección web en la India es www.yahoo.co.in, donde como en el Reino Unido es www.yahoo.co.uk. A través de estos sitios web de Yahoo localizados, los usuarios de diferentes países pueden llegar a saber sobre las noticias locales, tiempo, entretenimiento, etc.

85

recuerde Una de las principales ventajas de estas tecnologías es que existen herramientas que permiten el desarrollo de aplicaciones a personas que no tengan una gran preparación en esa tecnología.

86

Unidad didáctica 3. apicaciones web

Google es conocido por su servicio de búsqueda web. En agosto de 2007, Google fue el buscador más utilizado en Internet con una cuota de mercado de 53,6%, por delante de Yahoo! (19,9%) y Live Search (12,9%). Google indexa miles de millones de páginas web, por lo que los usuarios pueden buscar la información que desean, a través del uso de palabras clave y operadores. Google también ha empleado la tecnología de búsqueda web en otros servicios de búsqueda, incluyendo búsqueda de imágenes, Google News, el sitio de comparación de precios Google Product Search, los interactivos Usenet archivo de Grupos de Google, Google Maps.

Google, además de su motor de búsqueda más populares, publicó varios otros servicios, como el servicio de correo electrónico popularmente conocido como Gmail, que fue el resultado de 6 años de investigación, la red social conocida popularmente como Orkut, el servicio para compartir videos, Google Video y más tarde también adquirió YouTube de la misma. Google también tiene su programa de publicidad en Gmail, donde en caso de que el usuario está recibiendo un mensaje de una empresa en particular, se pueden ver los artículos o noticias relacionadas en la ventana de correo. Google también introdujo Google Earth, para lo cual adquirió un satélite. A través de Google Earth, cualquier usuario puede visitar cualquier lugar en la tierra virtual, y puede localizar a su casa, oficina, etc.

En octubre de 2007, el servicio Google SMS se puso en marcha en la India que permite a los usuarios obtener resultados, horarios de películas e información mediante el envío de un SMS. Actualmente Google ha lanzado un teléfono de Google para competir con el iPhone de Apple, que se conoce como proyecto Android, así como otros productos, como el Google Scholar, programa de hoja de cálculo Google, a través del cual los usuarios pueden descargar el documento de Word y verlo en línea. Por lo tanto, no requiere ninguna otra suite de Office preinstalado en el sistema del usuario.

Unidad didáctica 3. apicaciones web

Logros de Google –– La liberación de Gmail, con 1 GB de almacenamiento gratuito, el 1 de abril de 2004.

–– Puesta en marcha de la red social, Orkut. Lanzamiento del sitio para compartir videos YouTube.

–– Para Google, uno de los principales logros es la innovación y la cultura del trabajo. Google ha sido votado por la revista Fortune como el número uno.

–– Es una muy buena empresa para trabajar, la filosofía de la empresa incluye frases como “No seas malvado” y “El trabajo debe ser un reto y el desafío debe ser divertido.”

–– En 2004, Google.org, una división filantrópica sin fines de lucro de Google, se creó con un fondo inicial de $ 1000 millones. La misión era concienciar sobre el cambio climático, la salud pública mundial, y la pobreza global.

Logros de Yahoo –– Antiguamente se crearon cuentas de Yahoo Mail Plus (este es un servicio premium) con una capacidad de 2 GB. Más tarde, en 2007,Yahoo sacó los medidores de almacenamiento y pasó a un límite de almacenamiento ilimitado. Yahoo ha mejorado su servicio de correo, proporcionando diversas herramientas y complementos, tales como la creación de avatar, cambiar el color de la ventana de correo.

–– Yahoo es considerado como los sitios más visitados en Internet por el análisis de tráfico Web de empresas Comscore, Alexa Internet Netcraft, con más de 130 millones de usuarios únicos. La red mundial de sitios web de Yahoo! recibió 3,4 millones de páginas vistas por día, en promedio, a partir de octubre de 2007, por lo que es uno de los sitios web más visitados de Estados Unidos.

Crítica Yahoo ha sido criticado por la financiación de programas espía y ad-ware. En este caso, la publicidad de los clientes de Yahoo aparece en pantalla pop-ups ya través de éstos ad-ware un usuario puede instalar un programas espía en su ordenador sin darse cuenta. Esto ha sido fuertemente criticado por los medios de comunicación y los usuarios, debido al escrutinio en relación con pederastas en Internet y la falta de ingresos publicitarios importantes, y que hizo que se cerrase en junio de 2005.

87

88

Unidad didáctica 3. apicaciones web

recuerde Los portales web son mucho más que un motor de búsqueda, actualmente son un compendio de aplicaciones muy variadas y versátiles.

En mayo de 2006, la imagen de búsqueda de Yahoo fue criticado por la apertura de imágenes sexualmente explícitas, incluso cuando estaba en SafeSearch.

Google ha sido criticado por muchos de sus nuevos servicios. Por ejemplo, el esfuerzo de Google Book Search para digitalizar millones de libros y hacer que la búsqueda de texto completo ha dado lugar a conflictos de derechos de autor en el gremio de autores. Debido a los datos geográficos proporcionados por imágenes de satélite de Google Earth, muchos funcionarios del gobierno indio han levantado su voz contra Google, según ellos, ahora las organizaciones terroristas pueden obtener los detalles completos de puntos de referencia y sus áreas circundantes.

Las cookie de Google y otras prácticas de recopilación de información han dado lugar a preocupaciones sobre la privacidad de los usuarios. Google también tiene problemas con el gobierno chino y sus leyes ya que el filtro de los resultados de búsqueda no han pasado sus leyes y reglamentos regionales.

04 Desarrollo y despliegue de aplicaciones web 4.1 Modelos básicos de desarrollo de aplicaciones web. El modelo vista-controlador (MVC) 4.2 Herramientas de desarrollo web de uso común 4.2.1 Características 4.2.2 Comparativa 4.3 Políticas de desarrollo y pruebas de aplicaciones web 4.3.1 Entorno de desarrollo 4.3.2 Entorno de pre-producción o pruebas 4.3.3 Entorno de producción 4.4 Organización de recursos en una aplicación web 4.4.1 Programas 4.4.2 Hojas de estilos 4.4.3 Ficheros de configuración 4.4.4 Imágenes 4.4.5 Documentos 4.4.6 Bibliotecas de componentes (librerías) 4.4.7 Otros archivos

4.5 Seguridad en una aplicación web 4.5.1 Niveles de seguridad. Estándares 4.5.2 Conceptos y técnicas de identificación, autenticación y autorización o control de acceso 4.5.3 Identificación y autenticación avanzada. Certificados digitales 4.5.4 Concepto de sesión. Conservación de sesiones 4.5.5 Sistemas de uso común para la conservación de las sesiones en aplicaciones web. Single Sign-on y Single Sign-out 4.6 Despliegue de aplicaciones web 4.6.1 Características del proceso de despliegue 4.6.2 Definición del proceso de despliegue de aplicaciones web.

Verificación

90

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

4. Desarrollo y despliegue de aplicaciones web 4.1 Modelos básicos de desarrollo de aplicaciones web. El modelo vista-controlador (MVC) El objetivo de muchos sistemas informáticos es para recuperar datos de un almacén de datos y mostrarlos el usuario. Después de que el usuario maneja los datos, el sistema almacena los cambios en el almacén de datos. Debido a que el flujo de información clave se encuentra entre el almacén de datos y la interfaz de usuario, podría estar inclinado a vincular estas dos piezas para reducir la cantidad de código y mejorar el rendimiento de las aplicaciones. Sin embargo, este enfoque aparentemente natural tiene algunos problemas significativos. Un problema es que la interfaz de usuario tiende a cambiar con mucha frecuencia el sistema de almacenamiento de datos. Otro problema con el acoplamiento de los datos y los módulos de interfaz de usuario es que las aplicaciones de negocios tienden a incorporar en de negocio, y que va mucho más allá de la transmisión de datos.

Las siguientes fuerzas actúan sobre un sistema dentro de este contexto y deben reconciliarse para ser una solución al problema: –– La lógica de la interfaz de usuario tiende a cambiar con más frecuencia que la lógica de negocio, especialmente en aplicaciones basadas en Web. Por ejemplo, se pueden añadir nuevas páginas de la interfaz de usuario, o el diseño de las páginas existentes puede estar desperdigado. Después de todo, una de las ventajas de una aplicación de cliente ligero basado en la Web es el hecho de que se puede cambiar la interfaz de usuario en cualquier momento sin tener que distribuir la aplicación. Si el código de presentación y la lógica de negocio se combinan en un solo objeto, hay que modificar el módulo que contiene la lógica de negocio cada vez que cambie la interfaz de usuario. Es probable que se introduzcan errores que requieran la repetición de pruebas de toda la lógica de negocio después de cada cambio mínimo de interfaz de usuario.

–– En algunos casos, la aplicación muestra los mismos datos en diferentes formas.

Por ejemplo, cuando un analista prefiere una vista de hoja de cálculo de los datos mientras que para la gestión prefiere un gráfico circular de los mismos datos. En algunas interfaces de usuario de cliente enriquecido, se muestran al mismo tiempo múltiples vistas de los mismos datos. Si el usuario cambia los datos en una sola vista, el sistema debe actualizar todos los otros puntos de vista de los datos de forma automática.

–– Unos diseños de páginas HTML visualmente atractivos y eficientes generalmente requiere un conjunto de habilidades diferentes a no desarrollar la lógica de negocio compleja.

–– La actividad de la interfaz de usuario general consta de dos partes: presentación y actualización. La parte de presentación recupera datos de una fuente y

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

los formatos de los datos para su visualización. Cuando el usuario realiza una acción basada en los datos, la parte de actualización pasa el control a la lógica de negocios para que se puedan actualizar los datos.

–– En las aplicaciones Web, una sola solicitud de página combina el procesamiento de la acción asociada con el enlace que el usuario selecciona con la prestación de la página de destino. En muchos casos, la página de destino no puede estar directamente relacionada con la acción. Por ejemplo, imagine una aplicación web simple que muestra una lista de elementos. El usuario vuelve a la página principal de la lista después de que cualquiera añada un elemento a la lista o elimine un elemento de la lista. Por lo tanto, la aplicación debe prestar la misma página (la lista) después de ejecutar dos comandos muy diferentes (adición o eliminación), todo dentro de la misma petición HTTP. –– Código de interfaz de usuario tiende a ser más dependiente del dispositivo de lógica de negocio. Si desea migrar la aplicación a partir de una aplicación basada en navegador para apoyar a los asistentes digitales personales (PDA) o teléfonos móviles habilitados para Web, se debe reemplazar la mayor parte del código de la interfaz de usuario, mientras que la lógica de negocio puede verse afectada. Una clara separación de estas dos partes acelera la migración y reduce al mínimo el riesgo de introducir errores en la lógica de negocio.

–– Es generalmente más difícil la creación de pruebas automatizadas para interfaces de usuario y requiere mucho tiempo para que la lógica de negocio. Por lo tanto, la reducción de la cantidad de código que está directamente ligada a la interfaz de usuario mejora la capacidad de prueba de la aplicación.

91

92

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

recuerde

El patrón Modelo-Vista-Controlador (MVC) separa el modelado del dominio, la presentación y las acciones basadas en la entrada del usuario en tres clases separadas:

La separación de funciones que da el Modelo-Vista-Controlador es la característica principal del mismo.

–– Modelo. El modelo gestiona el comportamiento y los datos del dominio de aplicación, responde a las solicitudes de información sobre su estado (por lo general de la vista), y responde a las instrucciones para cambiar de estado (por lo general desde el controlador).

–– Visualizar. La vista administra la visualización de la información.

–– Controlador. El controlador interpreta el ratón y el teclado entradas desde el usuario, informando el modelo y / o el fin de cambiar según sea apropiado.

Es importante tener en cuenta que tanto la vista y el controlador dependen del modelo. Sin embargo, el modelo ni depende de la vista ni del controlador. Esta es una de las principales ventajas de la separación. Esta separación permite que el modelo se construya y pruebe independiente de la presentación visual. La separación entre la vista y el controlador es secundaria en muchas aplicaciones de cliente, y de hecho, muchos marcos de interfaz de usuario de la aplicación de las funciones son tratados como un solo objeto. En las aplicaciones Web, por otro lado, la separación entre la vista (el navegador) y el controlador (los componentes del lado del servidor que controla la solicitud HTTP) está muy bien definida.

Modelo-Vista-Controlador es un patrón de diseño fundamental para la separación de la lógica de la interfaz de usuario de la lógica de negocio. Desafortunadamente, la popularidad de la pauta ha dado lugar a una serie de descripciones defectuosas. En particular, el término “control” se ha utilizado para referirse a cosas diferentes en diferentes contextos. Afortunadamente, la llegada de las aplicaciones web ha ayudado a resolver algunas de las ambigüedades, porque la separación entre la vista y el controlador es tan evidente.

VARIACIONES En la programación de aplicaciones en Smalltalk-80: Cómo utilizar Modelo-VistaControlador (MVC), Steve Burbeck describe dos variaciones de MVC: un modelo pasivo y un modelo activo.

–– El modelo pasivo cuando se emplea un controlador manipula el modelo exclusivamente. El controlador modifica el modelo y luego informa a la opinión de que el modelo ha cambiado y debe ser renovado. El modelo en este escenario es completamente independiente de la vista y el controlador, lo que significa que no hay ningún medio para el modelo para informar de los cambios en su estado. El protocolo HTTP es un ejemplo de esto. No hay ninguna manera

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

sencilla en el navegador para recibir actualizaciones asíncronas del servidor. El navegador muestra la vista y responde a la entrada del usuario, pero no detecta los cambios en los datos en el servidor. Sólo cuando el usuario solicita explícitamente una renovación es el servidor interrogado por los cambios.

–– El modelo activo se utiliza cuando el modelo cambia de estado sin la participación del controlador. Esto puede ocurrir cuando otras fuentes están cambiando los datos y los cambios deben reflejarse en las vistas. Ha de considerarse la posibilidad de una pantalla en acciones que recibe datos de stock de una fuente externa y desea actualizar los puntos de vista cuando cambian los datos de valores. Debido a que sólo el modelo detecta cambios en su estado interno cuando se producen, el modelo debe notificar a los puntos de vista para actualizar la pantalla.

Sin embargo, una de las motivaciones de utilizar el patrón MVC es hacer el modelo independiente de las opiniones. Si el modelo tuvo que notificar a las opiniones de los cambios, debe reintroducir la dependencia que se buscaba evitar. Afortunadamente, el patrón Observador proporciona un mecanismo para alertar a otros objetos de los cambios de estado sin introducir dependencias en ellos. Los puntos de vista individuales implementan la interfaz de Observador y se registran en el modelo. El modelo sigue la lista de todos los observadores que se suscriben a los cambios. Cuando hay un cambio en el modelo, el modelo se repite a través de todos los observadores registrados y les notifica del cambio. Este enfoque se conoce como “publicación-suscripción”.

El modelo nunca requiere de información específica sobre los puntos de vista.

De hecho, en situaciones en las que el controlador necesita ser informado de los cambios de modelo (por ejemplo, para activar o desactivar las opciones de menú), todo lo que el regulador tiene que hacer es implementar la interfaz Observador y suscribirse a los cambios de modelo. En situaciones en las que hay

93

94

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

muchos puntos de vista, tiene sentido definir varios temas, cada uno de los cuales describe un tipo específico de cambio de modelo. Cada vista puede luego suscribirse únicamente a los tipos de cambios que son relevantes para la vista.

La capacidad de prueba es mucho mayor cuando se emplean empleando ModeloVista-Controlador. La prueba de componentes se hace difícil cuando son altamente interdependientes, en especial con los componentes de interfaz de usuario. Estos tipos de componentes a menudo requieren una configuración compleja sólo para probar una función simple. Peor aún, cuando se produce un error, es difícil aislar el problema en un componente específico. Esta es la razón para la separación de los componentes que hace que sea un motor arquitectónico importante. MVC separa la preocupación de almacenar, visualizar, y la actualización de datos en tres componentes que pueden ser probados individualmente.

Aparte de los problemas que plantea la interdependencia, los marcos de interfaz de usuario son inherentemente difíciles de probar. Prueba de interfaces de usuario es un tanto tediosa (y propensa a errores), y deben usarse pruebas manuales o scripts de pruebas que simulan las acciones del usuario. Estas secuencias de comandos tienden a consumir mucho tiempo para desarrollar. MVC no elimina la necesidad de pruebas de la interfaz de usuario, pero separando el modelo de la lógica de presentación permite que el modelo sea independiente de la presentación y reduce el número de casos de prueba de interfaz de usuario.

Beneficios –– Soporta múltiples puntos de vista. Debido a que la vista se separa del modelo y no hay dependencia directa del modelo a la vista, la interfaz de usuario puede mostrar varias vistas de los mismos datos al mismo tiempo. Por ejemplo, varias páginas en una aplicación Web pueden utilizar los mismos objetos del modelo.

Otro ejemplo es una aplicación web que permite al usuario modificar el aspecto de las páginas. Estas páginas muestran los mismos datos desde el modelo común, pero muestran de una manera diferente.

–– Capacidad para el cambio. Los requisitos de la interfaz de usuario tienden a cambiar más rápidamente que las reglas de negocio. Los usuarios pueden preferir diferentes colores, fuentes, diseños de pantalla, y los niveles de apoyo a nuevos dispositivos, como teléfonos móviles o PDAs. Debido a que el modelo no depende de los puntos de vista, la adición de nuevos tipos de puntos de vista para el sistema general no afecta el modelo. Como resultado, el alcance del cambio se limita a la vista. Este patrón sienta las bases para nuevas especializaciones de este patrón como el “Controller and Front Controller”.

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Desventajas –– Complejidad. El patrón MVC introduce nuevos niveles de direccionamiento indirecto y por lo tanto aumenta ligeramente la complejidad de la solución.

También aumenta la naturaleza orientada a eventos del código de interfaz de usuario, que puede ser más difícil de depurar.

–– Costo de actualizaciones frecuentes. Desacoplamiento del modelo de la vista no significa que los desarrolladores del modelo pueden ignorar la naturaleza de las vistas. Por ejemplo, si el modelo se somete a cambios frecuentes, que podría llenar con solicitudes de actualización. Algunos puntos de vista, tales como pantallas gráficas, pueden tardar algún tiempo para hacer. Como resultado, la vista puede caer detrás de solicitudes de actualización. Por lo tanto, es importante mantener la vista en cuenta al codificar el modelo. Por ejemplo, el modelo podría lotes varias actualizaciones en una única notificación a la vista.

4.2 Herramientas de desarrollo web de uso común Los sitios Web van desde los sitios Web corporativos, personales, y destinados el comercio electrónico seguro (que son altamente interactivos) o de los sitios de gestión de relaciones con los clientes con altos volúmenes de transacciones.

Hay sitios que manejan millones de visitas, como Amazon.com, Microsoft.com, eBay. com, y muchos otros, y tendrán gigabytes de datos de sus bases de datos, así como de miles de transacciones de tarjetas de crédito por día.

Hemos clasificado las funciones de desarrollo web en cinco áreas: –– preparar estructura de la página, –– organización y gestión de la jerarquía de contenido, –– servir contenido al usuario (recoger y enviar información al navegador del usuario), –– entrada de captura de usuario y –– realizar el procesamiento de back-end e integración.

Las herramientas que se discuten aquí son algunos de los más populares en el desarrollo de sitios web hoy en día.

Cada herramienta seleccionada proporciona una cobertura diferente de estas funciones, y cada uno tiene una curva de aprendizaje diferente. Algunas de las herramientas son multifuncionales, mientras que otros son más limitadas en su función.

95

recuerde Smalltalk-80 tiene dos variaciones: modelo pasivo (sólo el controlador manipula el modelo) y modelo activo (el modelo cambia de estado sin la participación del controlador).

96

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

recuerde Las herramientas de desarrollo web pueden ser editores de texto WYSIWYG, basadas en código puro, o una combinación de ambas.

4.2.1 Características Es más fácil que nunca crear un sitio Web con un editor HTML, ya que los desarrolladores de software cuentan con herramientas que continúan agregando opciones que le permiten desarrollar funciones avanzadas con estilo. Los medios actuales de creación de Web proporcionar avanzadas opciones para construir un sitio interactivo, animado, etc., y para crear desde una página web personal a un sitio de una mediana empresa. Los nuevos diseñadores Web no necesitan tener conocimientos de HTML para crear foros, las ventanas pop-up, barras de navegación, transiciones de página animadas, HTML dinámico, o muchas otras características avanzadas con el fin de integrarlos en un sitio con un diseño elegante y consistente.

Tipos de herramientas de creación Web: –– Editor WYSIWYG puro (lo que ves es lo que se obtiene): Con un editor WYSIWYG puro, que también contiene en una interfaz que se asemeja a un programa de autoedición. Estos programas son los más adecuados para aquellos que quieran un sitio con buena apariencia, facilitando su construcción. NetObjects Fusion y Drumbeat son ejemplos de editores WYSIWYG. –– Editor basado en código puro: con el editor basado en código puro, se trabaja directamente con las etiquetas HTML primarias y se establecer sus propias reglas acerca de cómo diseñar y organizar el código. El desarrollador tiene el control total sobre el código. HomeSite, WebberActive y WebEdit, HTMLed son ejemplos de editores basados en ​​ código puro.

–– Editor Compuesto (editores WYSIWYG Pure + editores basados ​​en código puro): Con un editor de compuesto, se puede realizar la mayoría de las tareas de un modo de edición WYSIWYG, pero el interruptor de la ventana de edición de estilo procesador de textos para una vista de código fuente para modificar de la página HTML subyacente. Macromedia Dreamweaver, Microsoft FrontPage, QuickSite y Visual Page son ejemplos de editores compuestos.

4.2.2 Comparativa DREAMWEAVER Dreamweaver es un editor visual profesional para la creación y gestión de páginas web. Su primer lanzamiento fue a finales de 1997 a través de la empresa Macromedia y fue creciendo en popularidad, ya que aunque era una potente herramien-

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

ta de Webauthoring, era muy fácil de usar, al permitir a los usuarios replicar un sitio Web remoto localmente.

En sus inicios, sus principales competidores eran Adobe GoLive y Microsoft FrontPage, siendo este último parte del paquete Microsoft Office.

En 2007 la empresa Adobe compró Macromedia y Dreamweaver pasó a denominarse Adobe Dreamweaver CSx, siendo la última versión estable la CS6 del año 2012. En el 2013 apareció una nueva versión con nueva nomenclatura, Dreamweaver CC, que incluye aplicaciones Cloud.

Adobe Dreamweaver sustituyó a Golive y pasó a formar parte del paquete de programas Adobe Creative Suite (de ahí vienen las siglas CS) que incluye entre otros Photoshop, Flash, Illustrator, Fireworks y Acrobat. Los competidores actuales de Dreamweaver son Frontpage sobre todo y , en menor medida, Blue Fish y Kompozer entre otros.

Los desarrolladores web pueden diseñar y administrar visualmente sitios Web entre exploradores sin sacrificar el control del lenguaje Hypertext Markup Language (HTML).También ayuda a los desarrolladores a optimizar el flujo de trabajo entre los miembros del equipo de desarrollo y dar soporte de gráficos y aplicaciones destinadas a diseñar el contenido, como Photoshop, Fireworks y Microsoft Office. Dreamweaver también permite a los desarrolladores web personalizar el entorno y automatizar tareas.

Al igual que otras herramientas de esta clase, el valor de Dreamweaver es en la automatización del proceso de construcción de un sitio Web permitiendo añadir elementos con drag-and-drop. Al generar el código fuente HTML que corresponde a lo que el desarrollador crea visual, Dreamweaver elimina la necesidad de

97

98

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

saber HTML. La característica de inspección de HTML da total visibilidad y control al desarrollador del HTML fuente generado. Aunque hay otras herramientas de generación HTML Dreamweaver es una de las más potentes y sencillas.

Se suele decir que el uso de una herramienta de conversión en lugar de función de escritura como HTML de Word es mejor para convertir documentos de Microsoft Word a HTML. Sin embargo, la función Clean-Up-Word-HTML de Dreamweaver es muy útil para aquellos que utilizan Word para generar los contenidos. Dreamweaver elimina etiquetas innecesarias, tales como metatags de Word que fueron insertados, artículos específicos del navegador, y varios otros objetos de Word, y devuelve código optimizado que mantiene la apariencia visual de la materia original de Word. Otra de las características más populares de Dreamweaver es característica HTML. La capacidad de leer los documentos entre Dreamweaver y un editor de HTML basado en texto, tiene poco o ningún impacto sobre el contenido y la estructura del código fuente HTML del documento. También permite identificar el código HTML sintácticamente inválido creado en un editor HTML externo y posteriormente importado.

Fortalezas de Dreamweaver Dreamweaver proporciona herramientas para el desarrollo de sitios Web neutrales del navegador y rápidamente, permitiendo operaciones de arrastrar y soltar, sin necesidad de codificación manual de HTML. Además, Dreamweaver establece un sitio local como un lugar de almacenamiento para todos los documentos y archivos que pertenecen al proyecto de sitio Web. Esta función permite a los desarrolladores Web comienzan a desarrollar y organizar la estructura de directorios de un sitio Web desde su escritorio o en un espacio compartido.

Esto, a su vez, alivia la necesidad de utilizar el almacenamiento de servidor Web para fines de desarrollo. Por último, Dreamweaver puede establecer una conexión FTP a un sitio web remoto a través del cual los desarrolladores pueden hacer drag-and-drop de archivos desde un sistema local.

Debilidades de Dreamweaver Es conveniente la utilización de Dreamweaver localmente para construir un sitio Web.

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Sin embargo, aún el pasar al servidor web para probar y ejecutar los procesos de un servidor del lado es una parte importante de un sitio web interactivo que recoge los datos introducidos por el usuario.

Además, Dreamweaver es una poderosa herramienta de desarrollo Web. Si necesita editar o modificar algunas páginas web existentes, esto se puede aumentar al usar Dreamweaver.

Active Server Pages ASP es un entorno de scripting del lado del servidor para crear páginas web dinámicas o construir aplicaciones interactivas de páginas web. ASP son archivos que contienen etiquetas HTML, texto y comandos de script. Pueden llamar a componentes ActiveX para realizar tareas como conectarse a una base de datos o la realización de un cálculo. ASP permite a los desarrolladores agregar contenido interactivo en páginas web o crear aplicaciones web completas que utilizan las páginas HTML y la interfaz de usuario.

Las secuencias de comandos ASP dan a los desarrolladores de HTML una manera fácil de crear páginas interactivas. ASP proporciona un mecanismo relativamente sencillo para: –– recoger información de un formulario HTML, –– personalización de un documento HTML con el nombre de un cliente, o –– el uso de características específicas del navegador HTML. Si se quiere obtener información de un formulario HTML, lo más habitual es utilizar un lenguaje de programación para crear una aplicación de Common Gateway Interface (CGI). ASP permite recopilar y analizar los datos de un formulario mediante instrucciones simples integradas directamente en los documentos HTML. Así que no es necesario aprender o utilizar un lenguaje de programación completo o compilar ejecutables separados para crear páginas interactivas.

Los desarrolladores que ya conocen un lenguaje de programación, como Microsoft Visual Basic Scripting Edition (VBScript), JavaScript o Perl, saben cómo utilizar páginas Active Server.

ASP puede adaptarse a cualquier lenguaje de scripts instalado con un motor de scripting que sigue el estándar de secuencias de comandos ActiveX. ASP viene con motores de scripting de VBScript y Microsoft Jscript. Los motores de secuencias de comandos ActiveX para Perl, lenguaje de programación Ejecutor Extended Reestructurado y Python también están disponibles.

99

recuerde Dreamweaver es una herramienta de las más importantes y pioneras con muchos recursos, pero se debe tener en cuenta que el ser un pionero es muchas veces negativo, ya que se busca muchas veces mantener la compatibilidad (y en la medida de lo posible la apariencia también) con versiones antiguas, mientras que una herramienta “nueva” se centrará en implementar las herramientas que desee de la manera que prefiera.

100

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Los desarrolladores que ya conocen un lenguaje de programación como Visual Basic encontrarán que ASP proporciona una forma flexible para crear rápidamente aplicaciones Web. Mediante la adición de los comandos en las páginas HTML, los desarrolladores pueden crear una interfaz HTML a una aplicación. Mediante la creación de componentes de ActiveX, los desarrolladores pueden encapsular la lógica de negocio de una aplicación en módulos reutilizables que se pueden llamar desde un script, otro componente, u otro programa.

El modelo ASP Una secuencia de comandos ASP comienza cuando un navegador solicita un archivo ASP de la Web, llamando luego a ASP, que lee el archivo solicitado, de arriba abajo, ejecutando sus comandos, y presenta la página Web resultante en el navegador.

Debido a que los scripts se ejecutan en el servidor en lugar del cliente, el servidor hace todo el trabajo necesario para generar las páginas web enviadas a los navegadores que las solicitan. Así que el desarrollador no necesita preocuparse acerca de si el navegador solicitante puede procesar los scripts.

Además, el usuario no puede copiar fácilmente secuencias de comandos del lado del servidor, ya que solo muestra resultado, no la lógica de la escritura o la elaboración de los comandos en sí.

ASP permite a los autores Web intercalar directivas limitadoras de código de secuencia de comandos en un archivo de código fuente HTML, lo que se conoce como plantilla. Este archivo reside en el servidor con una extensión. Cuando se producen referencias de código HTML de un cliente de un archivo ASP, Internet Information Server (IIS) pasa la solicitud al analizador de tiempo de ejecución de ASP. El analizador actúa como un procesador de archivos de plantilla que analiza el archivo ASP, y toma las medidas correctas, tal como se especifica en las directivas delimitadoras.

Desde el interior de estas directivas, los scripts pueden evaluar expresiones, rama condicional, e invocar métodos en componentes del lado del servidor. Se producirán bloques de salidas de la Directiva de las respectivas áreas de la plantilla en la secuencia HTML resultante, que luego viaja a la máquina cliente a través de HTTP. La naturaleza de este proceso permite la creación HTML dinámica y especializada.

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

101

Fortalezas ASP Tal vez la característica más importante de Active Server Pages es que permite crear instancias y utilizar los componentes programables. Puede crear estos componentes en herramientas como Visual Basic, Visual C + +, Visual J + +, Borland Delphi y Builder. Permite integrar las aplicaciones web con los sistemas clienteservidor existentes.

Debilidades ASP ASP tiene dos limitaciones principales: Funciona sólo en plataformas de Microsoft que utilizan IIS como servidor de aplicaciones Web, y su uso requiere de experiencia y conocimientos de programación.

DOMINO (RELEASE 5) Domino R5 es Lotus última versión de su aplicación web y del servidor backoffice.Además de servir para las aplicaciones web, es también compatible con una arquitectura cliente-servidor y el entorno de desarrollo basado en una interfaz gráfica de usuario típico. Domino R5 se ejecuta en otros sistemas operativos Windows NT, Windows 95 y 98, Solaris, Linux, AIX. Descripción técnica Domino proporciona a los desarrolladores web y administradores de TI un enfoque de ventanilla única para la entrega de aplicaciones Web. Domino también proporciona un componente indizador de texto completo. Este componente es similar a otros constructores de índice de sitio Web que proporcionan la capacidad de buscar un sitio Web o entre el contenido de una base de datos usando cadenas de caracteres. Domino también tiene un componente de servidor HTTP que ofrece todas estas funciones a la Web. El servidor HTTP de Domino es esencialmente un servidor Web HTTP estándar con una interfaz de programación de aplicaciones que permite llamadas a una base de datos Domino.

También puede sustituir el servidor HTTP de Domino con otros servidores HTTP, como servidor HTTP de Apache o IIS de Microsoft, y seguir proporcionando acceso completo a una base de datos Domino que se ejecuta en el servidor Domino.

Esta capacidad permite integrar Domino en una infraestructura existente.

El API es donde se lleva a cabo la conversión dinámica.

recuerde ASP da una gran flexibilidad y herramientas para la gestión de bases de datos.

102

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Domino convierte automáticamente el diseño, la lógica de una base de datos Domino, el scripting, y el contenido de la información en HTML y JavaScript. A continuación, se envía esta información al servidor HTTP. El servidor, a su vez, presenta la página en el navegador. Esta conversión se produce en tiempo real.

Domino es compatible con muchos de los estándares actuales de Internet. Por ejemplo, el Protocolo de Internet interoperable ORB permite el despliegue de objetos distribuidos basado en diferentes lenguajes orientados a objetos tales como Java. Por lo tanto, Domino puede ayudar a desarrollar aplicaciones distribuidas en Internet.

Base de datos de Domino La base de datos es el mecanismo que almacena todo lo relacionado con una aplicación particular: las páginas Web HTML, gráficos y archivos de imágenes, datos, consultas, scripts y código, y los agentes de antecedentes. Por lo tanto, un único archivo del sistema operativo contiene toda la aplicación. Esto simplifica el mantenimiento de la aplicación, ya que los elementos de diseño y el contenido no se dispersan a través de dispositivos de almacenamiento del entorno operativo.

Las técnicas de almacenamiento de base de datos usadas por Domino difieren de los de muchos otros fabricantes. Los desarrolladores no diseñan tablas y relaciones como con un sistema de gestión de bases de datos relacionales como Oracle.

En cambio, se debe diseñar cómo permitir al desarrollador almacenar la información en los documentos, por lo que una base de datos pueden tener varias formas diferentes que crean diferentes tipos de documentos.

Por ejemplo, el sistema de base de datos de usuario contiene una forma para la creación de cuentas de usuario individuales y uno para la creación de grupos de usuarios.

Cada usuario o grupo de usuarios pueden tener acceso a diversos privilegios de control y de edición.

Herramientas de desarrollo de Domino Domino proporciona a los desarrolladores Web varias herramientas de desarrollo de aplicaciones. Es compatible con la tecnología insertada del lado del cliente y JavaScript en una página HTML. Un desarrollador puede utilizar secuencias de comandos del lado del cliente para la validación de los datos en un formulario antes de que entre al servidor. Para el procesamiento del lado del servidor, Domino soporta JAVA y LotusScript. Por ejemplo, un desarrollador puede utilizar secuencias de comandos del lado del servidor para procesar la entrada del usuario.

Los agentes de Domino se lanzan cuando un documento se guarda en la base de

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

datos, permitiendo ayudar al scripting del lado del servidor. Además de utilizar muchos estándares de desarrollo Web de Internet, Domino también proporciona una herramienta; proporciona una interfaz gráfica de usuario para el desarrollo WYSIWYG. Por último, el indexador de texto reconoce más de 130 tipos de archivos. Además de indexar las páginas HTML almacenadas, el indexador también permite indexar el contenido de los documentos almacenados.

El motor de búsqueda asociado del indexador de búsqueda ofrece funciones sofisticadas como el párrafo próximo y búsquedas ponderadas.

Debilidades Domino Domino está limitado por su falta de capacidad de bases de datos relacionales. El servidor de base de datos de Domino es un motor de base de datos jerárquica y no permite la implementación de bases de datos que requieren claves primarias y externas. Los datos se almacenan ya sea como archivos planos o jerárquicamente.

Además, aunque sus funciones podrían proporcionar las aplicaciones necesarias para una aplicación web basada en transacciones, como un sitio de comercio electrónico, el motor de base de datos de Domino no es particularmente adecuado para aplicaciones de bases de datos relacionales de alto volumen y de alto rendimiento. Por último, los desarrolladores novatos pueden encontrar que el desarrollo del aprendizaje Domino es difícil.

Por lo general, los desarrolladores senior Domino tienen dos o tres años de experiencia práctica con la arquitectura y el entorno, y de 10 a 15 días de entrenamiento formal.

PERL Las plataformas de servidores Web más populares, con sus entornos de programación integrados incluyen Internet Information Server de Microsoft con páginas Active Server, Enterprise Server de Netscape con Java y Apache HTTP Server de Apache Software Foundation.

La selección de la herramienta adecuada depende tanto del entorno de desarrollo disponibles y la sofisticación de la aplicación.

Otra consideración es la relativa a la cantidad de procesamiento que se realizarán en el lado cliente y el lado servidor. Los cálculos del lado del cliente tienen sentido para los pequeños procesos (tales como velar por que todos los campos requeridos en un formulario se completen) o cálculos que involucran datos que el usuario prefiere mantener en privado (como las calculadoras de asignación hipotecaria).

103

recuerde DOMINO/ NOTES (en las últimas versiones se encuentra fusionado) permite la integración con características del tipo de correo electrónico, calendarios, agendas, y bases de datos colaborativas.

104

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Se ha dicho que Perl se asemeja lo que sería la cinta adhesiva de la Internet, ya que pega los procesos grandes. Pero también hace una gran navaja suiza, con todo el poder que ofrece al desarrollador.

Perl es un lenguaje de programación de código abierto GNU cuya sintaxis es un cruce entre los lenguajes de programación y scripting C / C + +, awk, y Sed. Originalmente desarrollado para Unix, Perl ahora viene en versiones para Unix, Linux, DOS y Windows 95/98/NT. ActivePerl (versión 522) es la versión estándar de 5.005_03 Perl construidas para los procesadores de Windows 95/98/NT. ActivePerl fue encargado originalmente por Microsoft. Incluye extensiones Win32 y Open Database Connectivity estándar (ODBC).

Perl es una gran opción para un lenguaje de programación de uso múltiple, gracias a su base de una sintaxis uniforme a través de todas las plataformas y su, de un paso relativamente rápido, compilación y estructura de ejecución. Los analistas, consultores, y otros estiman que el 90 por ciento del contenido activo en Internet se genera a través de Perl de alguna manera. En particular, los sitios web de gran tamaño, como Netscape, Yahoo, CNET, y Amazon.com usan ampliamente Perl en la prestación de la gestión del sitio y los servicios Web. Perl viene integrado con Linux y se envía con el paquete de de Microsoft NT. Kit de recursos Para sacar el máximo provecho de las extensiones Win32 a Perl (por ejemplo, la vinculación e incrustación de automatización y conectividad ODBC), los desarrolladores tienen que descargar el archivo binario libre ejecutable de ActiveState (http://www.ActiveState.com/ActivePerl/). Este sitio web también ofrece servicios especializados paquetes adicionales (como MD5, SHA y funciones criptográficas SSLeay; interfaces de LDAP, y especializada Oracle, Sybase, MySQL, y conectores de base de datos XBase) a través de la URL apenas anunciado, http:// www. ActiveState.com/packages/. Utilizando Perl en el procesado back-end. Quizás la parte más complicada de desarrollar funciones Web avanzadas sea el llevar a cabo procesos de back-end, como pueden ser captura de entrada de formulario o los archivos subidos, acceso a bases de datos y automatización de las funciones de administración del sistema.

En general, el procesamiento de back-end se puede ejecutar como un script común de interfaz de puerta de enlace, o más de forma nativa, como un módulo. Un script CGI se ejecuta como un proceso generado por separado, añadiendo una cierta sobrecarga a una aplicación. Los servidores web más modernos, además, publican una API para que los desarrolladores escriban módulos personalizados que se ejecutan en el espacio proceso del servidor de aplicaciones Web. Las APIs suelen compensar las deficiencias del CGI y exponen los puntos de entrada

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

al sistema operativo, produciendo de este modo las capacidades adicionales de automatización.

Los módulos de acceso a las API pueden ser compilados o interpretados scripts.

Perl funciona muy bien en los roles tanto de script CGI como las nativas. De hecho, cuando se aplican buenas prácticas de programación, la única diferencia significativa entre la programación de CGI y escritura nativa es que el código CGI debe anunciar explícitamente tipo Multi-Purpose Internet Mail Extension (MIME) de la página resultante.

El programa auto-instalable de distribución ActivePerl instala tres componentes Perl: –– Perl para Win32 es el Perl estándar aumentado con extensiones Win32.

–– Perl para ISAPI es una versión de plug-in diseñado para ejecutar Perl más rápido en los servidores Web compatible con ISAPI. –– PerlScript es un motor de secuencias de comandos ActiveX que le permite utilizar Perl dentro de cualquier secuencia de comandos de host ActiveX, como IIS 3.0 +, Peer Web Services 3.0 +, Internet Explorer 4.0 +, Microsoft Exchange y Windows Scripting Host.

Aunque del lado del cliente VBScript difiere ligeramente del lado del servidor VBScript (o, más exactamente, Active Server Pages), las funciones de Perl son las mismos en ambos scripts de cliente y de servidor. Acceso a la base de datos de programación ilustra bien este punto. Con la codificación del lado del servidor

105

106

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

ASP, las llamadas a las conexiones “Servidor” manejan la base de datos y proporcionan una gestión de registros conjunto.

Para probar y depurar, el desarrollador debe tener acceso a una plataforma de servidor Web (normalmente un cuadro Servidor NT 4.0). Por ejemplo, el desarrollador no puede continuar el trabajo en casa usando una plataforma Windows 95/98, ya que el objeto de servidor no está disponible en el cliente. A diferencia de las conexiones de base de datos en Perl son la misma y se basan en el objeto de ODBC, ya sea en el lado del cliente (por ejemplo, en casa) o en el lado del servidor (por ejemplo, en el servidor Web principal).

Adicionalmente sería necesario el código de detección de error en otro sistema realmente operativo. Por lo tanto, PerlScript proporciona la base para el desarrollo de las funciones Web muy potente con herramientas de entorno de desarrollo mínimo.

Procesamiento de entrada con Perl también ofrece otras funciones de servidor Web estándar.

El módulo CGI.pm hace que la captura de la entrada del usuario a partir de un sencillo envío de formulario. CGI. pm también proporciona la captura de los archivos subidos. Los que han tratado de implementar esta funcionalidad en ASP o han buscado en la Web para un componente libre puede apreciar el poder y la flexibilidad de Perl. Debido a que Perl tiene una rica colección de funciones de búsqueda de patrones y de manipulación de cadenas, es una excelente herramienta para interpretar y transformar la entrada del usuario.

Hemos utilizado Perl para poner en práctica muchos de nuestros servicios web.

Los scripts de Perl detectan dinámicamente la presencia de nuevos archivos y los muestran en una página Web bajo un nombre de archivo, con un menú desplegable de todos los tiempos de subida disponibles. Este procedimiento automatizado libera completamente a los webmasters de tener que gestionar la estructura de archivos y contenido de la página.

En otro proyecto, los investigadores usaron los contenidos de datos de forma muy dinámica, con flexibilidad en un formato de libro de cuatro hojas Excel. Perl scripts automatizan los procesos de:

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

107

–– la lectura de la hojas de cálculo Excel, –– comprobación de consistencia interna en los campos clave, –– solicitar cambios (si es necesario) antes de proceder y –– generar contenidos de la página Web tanto estáticos y la dinámica de código JavaScript.

Utilizando técnicas de scripting similares, muchos webmasters han utilizado Perl para generación de cuentas automatizadas, análisis de registro remoto, controles periódicos de seguridad de datos, así como para el sistema de administración y las tareas de mantenimiento.

Fortalezas En primer lugar, Perl ofrece una excelente portabilidad del código a través de sistemas operativos como Unix, Linux, Wintel y WinAlpha.

En segundo lugar, permite a los desarrolladores utilizar cualquier plataforma Wintel, ya que no requiere un servidor.

En tercer lugar, Perl tiene muchas extensiones Win32 gratis, disponibles para funciones adicionales.

En cuarto lugar, el estado de código abierta de Perl añade a su estabilidad la adición frecuente de nuevos módulos.

En quinto lugar, Perl proporciona una buena integración en el motor de secuencias de comandos ActiveX. Debilidades En el lado negativo, Perl requiere experimentados programadores para aprovechar sus múltiples métodos de interactuar con los procesos de back-end. La complejidad de la sintaxis puede ser desalentadora para los nuevos programadores.

Además, se requiere una instalación especial en el lado del cliente. La programación Perl no requiere las mismas herramientas del entorno de desarrollo como C / C++, que a menudo requieren programadores igual de talentosos, lo que aumenta los costes de su desarrollo normal y de mantenimiento.

recuerde Perl se centra en la portabilidad sin precisar de un servidor, pero requiere de desarrolladores experimentados para su uso.

108

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

4.3 Políticas de desarrollo y pruebas de aplicaciones web 4.3.1 Entorno de desarrollo Los requisitos se basan en la práctica actual de las pruebas de usabilidad, pero se deben anticipar a posibles necesidades futuras. Los requisitos tratarán de: –– Proporcionar, instruir y evaluar a los usuarios.

–– Facilitar las tareas de los usuarios y gestionar la realización de tareas.

–– Proporcionar los medios para la construcción de material de prueba.

–– Proporcionar varios usuarios el acceso local y remoto a los servicios basados​​ en la Web. –– Comportamiento de los usuarios en cuanto al registro y respuestas.

–– Pre-procesar los datos brutos recogidos (antes de continuar con el análisis de datos con un paquete de software estadístico) Puesta a punto general: Un ingeniero, en cuanto a la usabilidad, debe ser capaz de establecer una evaluación utilizando el entorno de prueba. Es decir, se debe ser capaz de definir tareas que incluyen un estado inicial y un estado final. También se deben definir en esta etapa las preguntas que se presentan después de la finalización de la tarea. Debe ser posible el desarrollo de un nuevo examen o la adaptación de las existentes para alguien sin conocimientos técnicos específicos.

Presentación de tareas: Una prueba de usabilidad se compone de un número de tareas que los usuarios tienen que realizar. Las tareas basadas en la red tienen que realizarse con un navegador convencional (es decir, Netscape Communicator o Microsoft Internet Explorer). El entorno de prueba debe comenzar con

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

una presentación de la primera tarea y, posteriormente, presentar el servicio necesario para realizar la tarea en un estado inicial predefinido específico (por ejemplo, una página web específica). El usuario lleva a cabo la tarea y el entorno de prueba supervisa si se ha alcanzado (o no) la condición de parada predefinida.

La condición de parada puede ser una página de destino, un tiempo máximo o una parada indicada por el usuario. Cuando se detecta la condición de parada, una o más preguntas pueden ser presentados.

Tras la finalización de todas las tareas y preguntas ha terminado la prueba.

Registro: Durante la ejecución de la tarea, el entorno de prueba registra el comportamiento de los usuarios y sus respuestas a las preguntas que se presentan después de cada tarea. Las medidas de se pueden utilizar para deducir la eficacia, la eficiencia y la satisfacción de la utilización de un servicio basado en la web. Las medidas se pueden derivar de los indicadores. Es importante utilizar múltiples indicadores: un tipo de datos complementa y puede explicar los resultados de los otros tipo de datos.

4.3.2 Entorno de pre-producción o pruebas Muchos de los sistemas de los clientes trabajan con lo que podría considerarse sistemas críticos de negocio.Ya se trate de herramientas de automatización de diseño (DA), un sistema PLM / PDM, una aplicación personalizada estaría en apuros para completar de manera eficiente sus actividades si el sistema estuviese apagado o no funciona como debería. Hay una serie de elementos que deben tenerse en cuenta al realizar un cambio en uno de estos sistemas deberán garantizar la debida documentación, capacitación, diseño de sistemas y pruebas. Una de las mejores prácticas pasadas por alto para asegurar el éxito es tener una zona de concentración donde las aplicaciones pueden desarrollar, probar y desplegarse rigurosamente.

Los ambientes separados se precisan porque nunca se debe hacer cambios en un entorno de producción de trabajo sin antes asegurarse de que los cambios sean correctos y estén bien probados. Por supuesto, si no se tiene un entorno de ensayo por separado, es imposible seguir esta simple regla. Aunque aparentemente los pequeños cambios pueden conducir a un error o una regresión.

Un entorno de desarrollo es donde viven los programadores. Este ambiente suele tener herramientas de desarrollo como Visual Studio.NET instalados. Otras herramientas de desarrollo para el registro, la supervisión del rendimiento y la depuración también pueden estar presentes. Este entorno se puede actualizar muy fácilmente (es decir, a través de una partición de disco una imagen o instan-

109

recuerde El uso de entornos de desarrollo de aplicaciones repercute en un ahorro de tiempo, que finalmente es un ahorro en recursos (económicos y de personal) de los proyectos.

110

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

recuerde Se debe intentar que los entornos de pruebas sean lo más parecidos posibles al entorno final del sistema.

tánea de la máquina virtual) y puede ser controlado libremente cuando se trata de acceso al sistema para permitir que los programadores a hacer de registro, base de datos y cambios en la red fácilmente.

Un entorno de prueba es muy diferente del entorno de desarrollo. En lugar de contener herramientas y software especiales o ser configurado con permisos especiales o de acceso, el entorno de prueba es idéntico al entorno de producción. Este entorno está estrechamente controlado de manera que las versiones de software, permisos y opciones de configuración coincidan con el entorno de producción. Todas las pruebas se llevan a cabo en este entorno. Un entorno de prueba servirá para múltiples audiencias: –– Los programadores lo utilizan para probar los cambios y mejoras en aplicaciones personalizadas.

–– Los administradores de sistemas lo utilizan para probar las nuevas versiones de software o parches de software.

–– Los usuarios finales lo podrán utilizar para hacer pruebas unitarias y verificar la solicitud se ajuste a sus necesidades empresariales específicas.

Se puede preguntar si es una exageración tener múltiples entornos y múltiples servidores físicos o virtuales. La respuesta depende de si se puede permitir para todos sus usuarios el estar caído durante horas de oficina debido a que un cambio no funcionó como estaba previsto. Si no se tiene ningún problema con ese escenario, entonces puede ser una exageración. Sin embargo, para los sistemas en que esto plantearía un problema, cuando el tiempo de inactividad de los sistemas críticos de negocio, tiene un costo significativo para el negocio.

4.3.3 Entorno de producción Las pruebas en producción con usuarios reales en los centros de datos reales será una necesidad para cualquier servicio de software a gran escala de alto rendimiento.

Actualmente los probadores aprovechan la nube para lograr una eficacia y productividad sin precedentes.

Los organizaciones de desarrollo de software están cambiando la forma en que ponen a prueba el software y cómo organizarse para garantizar la calidad del software. Esto dará lugar a cambios drásticos en la profesión de pruebas.

Cualquier intento de predecir el futuro es casi seguro que esté equivocado. Lo que se hace es mirar las tendencias de los cambios actuales, y hacer algunas conjeturas.

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Pruebas en Producción Los servicios de software, tales como Gmail, Facebook y Bing se han convertido en una parte cotidiana de la vida de millones de usuarios. Todos ellos son considerados servicios de software debido a que: –– Los usuarios no (o no deben) instalan las aplicaciones de escritorio que utilizan –– El proveedor de software controla cuando se implementan actualizaciones y las características están expuestos a los usuarios –– El proveedor también es visible en el centro de datos que ejecuta el servicio, la concesión de acceso a los datos del sistema, el diagnóstico, e incluso los datos del usuario están sujetos a las políticas de privacidad.

Proceso de Producción Como muestra anterior figura, si los ingenieros de software pueden controlar la producción que sigue, pudiendo detectar los problemas antes de (o simultáneamente a) que manifiesten sus efectos al usuario. Se puede entonces crear y probar un remedio al problema, y a continuación implementarlo antes de que se produzca un impacto significativo en el problema. El ciclo en la anterior figura ayuda a mitigar el riesgo de este enfoque mediante la limitación de tiempo que

111

112

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

recuerde Las pruebas de producción han de realizarse (al menos en parte) por los usuarios finales del sistema.

los usuarios que están potencialmente expuestos a los problemas encontrados en el sistema sometido a prueba.

Debido al enfoque actual de la Gran Prueba de Up-Front (BUFT) en un laboratorio de pruebas, sólo puede ser un intento de aproximar las verdaderas complejidades de su entorno operativo. Una de las habilidades como probadores es anticipar los casos extremos y comprender los entornos, pero en los grandes usuarios del World Wide hace las cosas sin poderse anticipar, siendo los centros de datos son sistemas sumamente complejos en sí mismos con las interacciones entre servidores, redes, fuentes de alimentación y sistemas de refrigeración.

Gran Prueba de Up-Front (BUFT) Sin embargo no se trata de tirar cualquier sistema no probado a los usuarios. Se debe controlar el riesgo durante la conducción mejora de la calidad: –– El circuito limita el impacto en los usuarios, permitiendo una respuesta rápida a los problemas.

–– Prueba Up-Front (UFT) sigue siendo importante no sólo “Big” Testing UpFront (BUFT). Prueba por adelantado la cantidad justa (pero nunca más). Si bien hay un muchos escenarios que se pueden probar bien en un laboratorio, no hay que entrar en los rendimientos decrecientes, tratando de simular toda la producción en el laboratorio.

–– Para algunas metodologías se puede reducir el riesgo mediante la reducción de la exposición del nuevo código bajo prueba. Esta técnica se llama “Control de exposición” y limita el riesgo mediante la limitación del número de usuarios potencialmente afectados por el nuevo código.

4.4 Organización de recursos en una aplicación web.

4.4.1 Programas Podemos querer insertar programas para su descarga en nuestra web por diversas razones, tales como:

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

–– Que se precisen ciertos programas/ parches para poder visualizar correctamente los recursos de nuestra web; –– Tener programas para su descarga por otras razones, normalmente relacionadas con el contenido de la web.

Se recomienda usar hiper-enlaces a la web que permitirá la descarga, que ha de ser la web de su creador o la que tenga los derechos de distribución del programa.

113

recuerde Se ha de tener muy presente las licencias que tienen los programas que se utilicen.

4.4.2 Hojas de estilos Las hojas de estilo describen cómo se presentan los documentos en las pantallas, en forma impresa, o tal vez la forma en que se pronuncian. W3C ha promovido activamente el uso de hojas de estilo en la web desde que el Consorcio fue fundado en 1994. La Actividad de Estilo ha producido varias Recomendaciones del W3C (tales como CSS1, CSS2, XPath, XSLT). En especial, CSS se aplica ampliamente en los navegadores.

Uniendo hojas de estilo para documentos estructurados en la Web (por ejemplo, HTML), los autores y los lectores pueden influir en la presentación de los documentos sin sacrificar la independencia del dispositivo o la adición de nuevas etiquetas HTML. La forma más fácil de empezar a experimentar con las hojas de estilo es usar un navegador que soporte CSS. El estilo Actividad W3C también está desarrollando XSL, que consiste en una combinación de XSLT y “Objetos de formato” (XSL-FO).

Cascading Style Sheets (CSS) es un mecanismo sencillo para añadir estilo (por ejemplo, fuentes, colores, espaciado) a los documentos Web. 4.4.3 Ficheros de configuración Web.config es el archivo de la configuración principal y el archivo de configuración de una aplicación web ASP.NET. El archivo es un documento XML que define la información de configuración sobre los almacenes de archivos de la aplicación.

Contiene la información sobre cómo actuará la aplicación web. El archivo web. config guarda información que controla el módulo de carga, configuración de seguridad, la configuración del estado de sesión, y el idioma de la aplicación y la configuración de compilación. Los archivos Web.config pueden contener elementos específicos de la aplicación, tales como cadenas de conexión de base de datos.

recuerde El uso de hojas de estilo propicia que se desarrollen las webs de una forma más atractiva e intuitiva.

114

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

recuerde Los ficheros de configuración contendrán la forma en que la aplicación web va a funcionar.

Una aplicación Web puede contener más de un archivo Web.config. La configuración se realiza en un archivo de aplicación en el directorio en el que se encuentra, y todos los directorios secundarios. Archivos Web.config en directorios secundarios tienen prioridad sobre los valores que se especifican en los directorios principales.

Archivos Web.config están protegidos por IIS, por lo que sus usuarios no pueden navegar a ellos. Si intenta recuperar un archivo http://somedomain.com/Web. config existente, un se muestra un mensaje de error “acceso denegado”.

No hay necesidad de reiniciar el servidor Web después de modificar un archivo Web.config. Cuando se produce un cambio esto es detectado por ASP.NET en la siguiente petición, volviendo a cargar la aplicación.

4.4.4 Imágenes Las páginas web se visitan de forma rápida, siendo en muchas ocasiones las imágenes las que las hacen más atractivas. Si bien el contenido sigue siendo lo primordial, una web atractiva invitará al usuario a quedarse en ella, así como facilitará la comprensión del contenido.

Dejando al margen la idoneidad de las imágenes a elegir, se han de tener en cuenta diferentes características de las imágenes a la hora de insertarlas: –– Formato: se deben usar los formatos más reconocidos por todos los navegadores, para evitar problemas de compatibilidades. Son buenos formatos tales como jpeg, jpg, png y gif.

–– Editado de la imagen: en términos de marco, ajustar su tamaño, alineamiento vertical y horizontal, que la propia imagen pueda ser un propio hiper-enlace a otro recurso, crear thumbnails (miniaturas de las fotos que permiten ampliarse al seleccionarlas).

–– Privilegios: el desarrollador establecerá los privilegios de salvado de las imágenes, entre otros.

recuerde Además del tema estético, la inserción de imágenes debe enfocarse en facilitar la comprensión del contenido de la web.

Las imágenes se deben etiquetar, de forma que al situar el ratón sobre la imagen, aparezca una breve descripción de la misma.

4.4.5 Documentos Existen diversas formas de insertar documentos en las páginas web. La forma más directa es introducir el hiper-enlace que permite descargar el documento. Para

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

algunos formatos, como las bases de datos y las hojas de cálculo, se permite la inserción de las tablas directamente en la web.

Para los archivos de texto, se recomienda utilizar archivos pdf protegidos, de forma que no se permita el copiar y pegar en el mismo, ni su edición. Aunque en ocasiones se requiere insertar archivos editables, tales como formularios modelo que permitan su edición. Estos se pueden insertar en un formato editable, aunque se recomienda el uso de un PDF editable en modo plantilla, que requiere un cierto trabajo de preparación de cada documento, si bien conseguimos un archivo con unos datos más legibles y tratables.

4.4.6 Bibliotecas de componentes (librerías) El modelo de componentes para la Web (“Componentes Web”) se compone de cinco partes: –– Plantillas, que definen trozos de marcado que son inertes pero pueden activarse para su uso posterior.

–– Decoradores, que se aplican plantillas basadas en selectores CSS que afectan ricos cambios visuales y de comportamiento a los documentos.

–– Elementos personalizados, que permiten a los autores definen sus propios elementos, con los nuevos nombres de las etiquetas y nuevas interfaces de script.

–– Sombra DOM, que encapsula un subárbol DOM para la composición más fiable de elementos de la interfaz de usuario.

–– Las importaciones, que define cómo se empaquetan y se cargan las plantillas, decoradores y elementos personalizados como un recurso.

115

recuerde Si por alguna razón específica se desea permitir la edición de los archivos, se debe usar archivos PDF protegidos, de forma que se asegure en la mayor medida posible la propiedad y el uso restringido de los datos.

116

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

recuerde Usar librerías con los recursos de la web facilitará su reutilización.

Cada una de estas piezas es útil individualmente. Cuando se utiliza en combinación, componentes Web permiten a los autores de aplicaciones web para definir los widgets con un nivel de riqueza visual y la interactividad no es posible sólo con CSS, y la facilidad de composición y no reutilizar posible con bibliotecas de scripts de hoy.

Las librerías se utilizan para tener bien clasificados los recursos, especialmente para favorecer su reusabilidad.

4.4.7 Otros archivos Las aplicaciones web pueden contener otros archivos tales como videos, audios, enlaces a otras páginas, etc.

Para cualquier archivo insertado se ha de tener en cuenta las siguientes consideraciones: –– Contar con el copyright del archivo, o que tenga una licencia que nos acredite a su uso o distribución; –– Usar preferiblemente formatos reconocidos por todos los navegadores y, cuando sea necesario, incluir enlaces a los programas/ drivers/ parches necesarios para su visualización; –– Establecer los derechos deseados para cada elemento (lectura, edición, copia…)

4.5 Seguridad en una aplicación web

recuerde Una web puede contener numerosos tipos de recursos.Tras decidir qué se quiere incluir, se deben buscar los formatos más estándar para favorecer la compatibilidad con el mayor número posible de navegadores.

La seguridad Web es un conjunto de procedimientos, prácticas y tecnologías para la protección de los servidores web, los usuarios web y de sus organizaciones circundantes. Se trata de un seguro que protege contra un comportamiento inesperado.

La seguridad web requieren una atención especial, aparte de la cuestión general de la seguridad informática y de Internet, ya que la Web está cambiando muchas de las suposiciones que la gente históricamente han hecho sobre la seguridad informática y la edición: –– Internet es una red de dos vías. Como Internet hace posible que sus servidores publiquen información a millones de usuarios, también permite a los hackers, crackers, delincuentes, vándalos y otros “malos” entrar en los mismos equipos en los que los servidores web corren. Esos riesgos no existen en la mayoría de

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

los entornos de publicación, tales como periódicos, revistas, e incluso sistemas de publicación “electrónicos” que implican teletexto y respuesta de voz.

–– La World Wide Web es cada vez más utilizada por las empresas y los gobiernos para distribuir información importante y llevar a cabo transacciones comerciales. Las reputaciones se pueden dañar y se puede perder dinero si se subvierten los servidores web.

–– A pesar de que la Web es fácil de usar, los servidores web y los navegadores son piezas excesivamente complicadas de software, con muchos fallos potenciales de seguridad. Muchas veces en el pasado se añadieron nuevas características sin la debida atención sobre su impacto en la seguridad.

Por lo tanto, el software instalado correctamente puede todavía plantear amenazas a la seguridad.

–– Una vez subvertido, los navegadores web y servidores pueden ser utilizados por los atacantes como punto de partida para llevar a cabo nuevos ataques contra los usuarios y organizaciones.

–– Los usuarios no especializados serán (y son) los usuarios comunes de los servicios basados ​​en la WWW. La actual generación de peticiones de software sobre los usuarios les lleva a tomar decisiones relevantes para la seguridad a diario, sin embargo, a los usuarios no se les da suficiente información para tomar dichas decisiones.

–– Es mucho más caro y consume más tiempo de recuperación ante un incidente de seguridad que tomar medidas preventivas antes de tiempo.

En los últimos años, la frase “servidor seguro” ha llegado a significar diferentes cosas para diferentes personas: –– Para los proveedores de software que los venden, un servidor web seguro es un programa que implementa ciertos protocolos criptográficos, para que la información transferida entre un servidor web y un navegador de Internet que no puede ser espiado.

–– Para los usuarios, el servidor web seguro es uno que proteja cualquier información personal que es recibida o recogida. Es uno que apoya su privacidad y no permite al navegador descargar virus u otros programas maliciosos en su ordenador.

117

118

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

–– Para una empresa que opera uno, un servidor web seguro es resistente a un ataque inducido a través de Internet o de la información corporativa.

Un servidor web seguro es todas estas cosas y muchas más. Es un servidor confiable. Es un servidor que se refleja o sirve de copia de seguridad, por lo que en caso de un fallo de hardware o software que se puede reconstituir rápidamente.

Es un servidor que es expandible, por lo que puede dar servicio adecuado a grandes cantidades de tráfico.

Por desgracia, cuando los vendedores utilizan la frase “servidor seguro”, que casi siempre se refieren a un servidor de la World Wide Web que se desarrollan determinados protocolos criptográficos. Estos protocolos permiten a los navegadores web y servidores para el intercambio de información, sin el riesgo de espionaje por las partes que tienen acceso a los mensajes en el medio. Esta encriptación es ampliamente considerado como un requisito previo para el comercio en Internet.

Mientras que los protocolos criptográficos son ciertamente útiles para proteger la información que se envía a través de Internet a partir de las escuchas, no son estrictamente necesarios para la seguridad web, ni son suficientes para garantizarla. Es por eso que vamos a utilizar el término servidor web cuando el cifrado está activado, en lugar de “servidor seguro”, para describir a un servidor Web que implementa los protocolos criptográficos. Para entender esta distinción, consideremos una analogía que Gene Spafford ha estado utilizando durante los últimos años: Servidores web “seguros” son el equivalente de los vehículos blindados pesados.

El problema es que se están utilizando para transferir los rollos de monedas y cheques escritos en lápiz por la gente en los bancos del parque a los comercian-

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

tes que hacen negocios en cajas de cartón de debajo de puentes de carretera.

Además, las carreteras están sujetos a desviaciones aleatorias, cualquier persona con un destornillador puede controlar el semáforo, y no hay policía.

La seguridad web requiere mucho más que una sencilla protección contra el espionaje.

El problema de seguridad web se compone de tres temas principales: –– Asegurar el servidor web y los datos que se encuentran en él. Se necesita estar seguro de que el servidor puede continuar su operación, y que la información en el servidor no se ha modificado sin autorización, y la información sólo se distribuye a las personas a las que desea que se distribuye.

–– Seguridad de la información que viaja entre el servidor web y el usuario. Se quiere garantizar que la información que suministra el usuario al servidor web (nombres de usuario, contraseñas, información financiera, etc.) no puede ser leída, modificada o destruida por otros. Muchas de las tecnologías de red son especialmente susceptibles a las escuchas, ya que la información se transmite a cada equipo que está en la red de área local.

–– Asegurar el propio ordenador del usuario. Para tener una manera de asegurar que los usuarios de información, datos o programas descargados de sus sistemas no causan daño, ya que de lo contrario serán reacios a utilizar el servicio.

También se quiere tener una manera de asegurar que la información descargada se controla de acuerdo con el contrato de licencia del usuario y/ o derechos de autor.

Junto con todas estas consideraciones, es posible que también tenga otros requisitos. Por ejemplo, en algunos casos, se tendrán los siguientes desafíos: –– Verificación de la identidad del usuario al servidor –– Verificación de la identidad del servidor al usuario –– Asegurar que se pasan mensajes entre el cliente y el servidor en el momento oportuno, confiable y sin repetición –– Inicio de sesión y la auditoria de información sobre la transacción para fines de facturación, resolución de conflictos, “no repudio”, y la investigación de abuso –– Equilibrio de la carga entre varios servidores Para abordar adecuadamente estas preocupaciones se requiere la interacción de varios componentes principales, junto con la red subyacente y sistema operativo.

La seguridad en el servidor web es una tema que tiene dos partes. En primer lugar, el propio ordenador debe estar asegurado con las técnicas tradicionales de

119

120

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

seguridad informática. Estas técnicas tratan de garantizar que los usuarios autorizados del sistema tienen la capacidad de hacer su propio trabajo. Por lo tanto, es posible que se desee autorizar a los usuarios anónimos a leer el contenido de nuestra página web principal, pero no se quiere que tengan la capacidad de apagar el equipo o alterar los archivos de contabilidad del sistema. Estas técnicas tradicionales también aseguran que la gente en Internet que no estén autorizados no puedan entrar en ella y hacerse con el control.

recuerde Debido a que una de las principales funciones de las web es el relacionado al comercio, el tema de asegurar la seguridad de los datos bancarios es algo a tener muy en cuenta, y a lo que las empresas le dedican muchos recursos.

La seguridad del servidor es complicada cuando un equipo se utiliza tanto como un ordenador personal a la vez que como un servidor Web. Esto se debe a que el servidor web se puede utilizar para explotar fallos en la seguridad del host, y fallos en la seguridad del host se puede utilizar para investigar si hay problemas con el servidor web. Por ejemplo, un script CGI mal escrito puede hacer que sea posible cambiar el archivo de configuración de un servidor web, que puede ser modificado para que el servidor web se ejecute con privilegios excesivos. Mediante el uso de un fallo de seguridad de host, un atacante podría entonces crear un script CGI que conduzca a la concesión al atacante de acceso total a todo el sistema informático. Por lo tanto, una de las mejores estrategias para mejorar la seguridad de un servidor web es minimizar el número de servicios prestados por el host en el que se ejecuta el servidor Web. Si se necesita proporcionar un servidor de correo y un servidor web, lo mejor es ponerlos en equipos diferentes.

Otra buena estrategia para conseguir la información en el servidor web es restringir el acceso al servidor web.

El servidor debe estar ubicado en un lugar seguro, para que las personas no autorizadas no tengan acceso físico al equipo. Se debe limitar el número de usuarios que tienen la capacidad de iniciar sesión en el equipo. El servidor sólo debe utilizarse para su aplicación individual, ya que de lo contrario las personas que tienen acceso al servidor puede obtener acceso a su información. Y también se debe asegurar que las personas que tienen acceso al servidor para fines administrativos lo hacen utilizando medios seguros, como Kerberos Telnet, SecurID, S / Key o ssh.

4.5.1 Niveles de seguridad. Estándares Las dos principales organizaciones de estandarización de aplicaciones web son Open Web Application Security Project (OWASP), el Instituto SANS (SysAdmin, Audit, Network, Security) y otras fuentes reconocidas para las mejores prácticas de la industria.

OWASP es una comunidad abierta dedicada a habilitar a las organizaciones a desarrollar, adquirir y mantener las aplicaciones en las que se puede confiar.Todas las herramientas de OWASP, los documentos, foros y capítulos son gratuitas y

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

abiertas a cualquier persona u organización que esté interesada en la mejora de la seguridad de sus aplicaciones.

SANS Institute fue establecido como un centro de investigación cooperativa y la organización en la educación. El corazón de SANS lo forman muchos profesionales de la seguridad de diversas organizaciones mundiales de las empresas y de las universidades, que trabajan juntos para ayudar a toda la comunidad de seguridad de la información.

Se deben propiciar las siguientes características: Denegar el acceso a las condiciones de excepción: la gestión de errores con seguridad es fundamental para la codificación segura, en especial las excepciones que se producen en el proceso de un control de seguridad. Es importante que estas excepciones no permiten el comportamiento de control establecido normalmente. Sólo hay tres resultados posibles de un mecanismo de seguridad: 1. Permitir la operación 2. No permitir la operación 3. Excepción En general, se debe diseñar un mecanismo de seguridad para que un fallo siga la misma ruta de ejecución hasta llegar a no permitir la operación. Por ejemplo, los métodos de seguridad como IsAuthorized (), isAuthenticated (), y validar (); todos debe devolver false si hay una excepción durante el procesamiento.

Validar todas las entradas y desinfectar todas las salidas: todos los datos de entrada deben ser validados, la validación de datos de entrada debe ocurrir en la secuencia siguiente: ––1) Decodificar los datos antes de realizar la validación por ejemplo, comprobar las cadenas de entrada para evitar que el programa se ejecute comandos maliciosos, scripts, códigos, etc; ––2) Verifique que los criterios de longitud por ejemplo, determinar si está dentro del mínimo y máximo permitido; ––3) Verifique que los tipos de datos aceptables por ejemplo, determinar si se trata de un tipo de datos válido (por ejemplo, los caracteres o números únicos), y por último

121

122

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

––4) Comprobar si los tipos de datos inaceptables por ejemplo, determinar si la información ingresada es que no son personajes, no numéricos, caracteres especiales.

Todas las salidas deben ser “desinfectadas” para garantizar que los resultados no revelan demasiada información, especialmente para evitar que los mensajes de error puedan proporcionar demasiada información (por ejemplo, por defecto los mensajes generados por el sistema) que un atacante pueda utilizar para explotar las debilidades de seguridad. Para el manejo de errores de los datos de entrada, el mensaje de error no debe revelar demasiada información.

Por ejemplo, cuando hay un ID de usuario y contraseña introducida inválidos, el mensaje de error no debe revelar lo que entró bien, si fue el ID de usuario o contraseña lo que causó el error. El mensaje debe ser de carácter general (por ejemplo, la entrada no válida) y no debe revelar más información de la necesaria.

Mantener la separación de funciones: el concepto de separación de funciones consiste en que la entidad que aprueba una acción, la entidad que lleva a cabo una acción, y la entidad que supervisa la acción deben ser distintos. El objetivo es eliminar la posibilidad de que un único usuario la lleve a cabo y oculte una acción prohibida.

En general, los administradores de aplicaciones no deben ser usuarios de la aplicación, ya que los administradores de aplicaciones heredan acceso privilegiado en la aplicación. Hay situaciones en las que el administrador de la aplicación es también un usuario de la aplicación; en tal caso se deben mantener cuentas separadas, una como administrador de la aplicación y la otra como usuario de la aplicación.

El uso de la cuenta de administrador de la aplicación debe ser utilizado exclusivamente para sólo tareas administrativas autorizadas.

Verificar toda la autenficación y autorización de usuarios: debe haber un mecanismo de control de seguridad para autenficar la identidad del usuario. Esto se controla normalmente con una cuenta de ID de usuario y una contraseña. La contraseña debe ser lo suficientemente larga y compleja, constando únicamente de caracteres alfanuméricos y, si es posible, de caracteres especiales. La autenticación se puede lograr usando Columbia UNI a través de WIND.

recuerde Casi tan importante es la seguridad de la entrada de datos por parte del usuario, como la devolución de los resultados.

Una vez autenticado el usuario, un mecanismo de control de seguridad también debe asegurarse de que los derechos de acceso del usuario a la información debe estar limitado únicamente a su nivel de acceso autorizado.

Implementar acceso de los usuarios con el privilegio mínimo requerido.

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Asignar usuario con el nivel de acceso mínimo privilegio: el acceso a los recursos debe concederse con el privilegio mínimo para asegurar que las cuentas tienen la menor cantidad de privilegios necesarios para realizar su función de trabajo y responsabilidad.

Esto incluye los derechos de usuario y permisos de recursos, incluidos los archivos y permisos de base de datos. Los derechos y privilegios de acceso del usuario deben ser limitados para llevar a cabo únicamente las tareas para las que el usuario esté autorizado y no más allá de su autoridad. Además, antes de conceder el acceso se debe garantizar que se cuente con la autorización adecuada por parte solicitante del titular de los datos o administrador de datos (es decir, una persona que se le ha dado la autoridad por el titular de los datos para aprobar el acceso a datos en nombre del propietario).

Por ejemplo, si el usuario sólo necesita acceso de lectura a la aplicación, este es el permiso que se le debe otorgar. Bajo ninguna circunstancia se debe permitir que el usuario actualice los privilegios a menos que haya sido expresamente autorizado por tanto lectura y el acceso de actualización.

Establecer valores predeterminados de seguridad: la configuración de los parámetros relacionados con la seguridad, incluidas las contraseñas, que deben ser salvaguardados y no se puedan sustituir por el usuario. Por ejemplo, por defecto, longitud de la contraseña y la complejidad de la misma debe estar habilitada y no debe poder ser cambiado por el usuario. Además, algunas aplicaciones se suministran con una o más cuentas de usuario y contraseñas por defecto. Si no se utilizan estas cuentas, entonces deben ser desactivados o eliminados. Si se requieren las cuentas por defecto, entonces las contraseñas por defecto se deben cambiar inmediatamente a una nueva contraseña compleja.

123

124

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Si una aplicación requiere una contraseña por defecto, ya sea para el usuario que logueado en la aplicación o en el caso de restablecimiento de contraseña para la contraseña olvidada, la contraseña por defecto debe ser una contraseña compleja y debe ser diferente para cada usuario. La contraseña por defecto también debe tener un período de caducidad (por ejemplo, no es válido más de 24 horas) y sólo ha de permitir usarse una sola vez, por lo que el sistema hará que el usuario cambie su contraseña inmediatamente después de usar la contraseña por defecto.

Mantener el área de la superficie de ataque al mínimo: la superficie de ataque del sistema es el conjunto de puntos de entrada que la aplicación tiene para un atacante. Cuantos más puntos de entrada tenga la aplicación, más posibilidades hay para un atacante de encontrar una debilidad. Cada característica que se agrega a una aplicación añade una cierta cantidad de riesgo para la aplicación general. El objetivo para el desarrollo seguro es del de reducir el riesgo global mediante la reducción de la superficie de ataque. Cada función debe funcionar de acuerdo a las especificaciones de aplicación y requisitos de negocio y no se debe permitir llevar a cabo las funciones ajenas a su finalidad prevista.

Mantener una seguridad sencilla y evitar la seguridad por oscuridad: la superficie de ataque y la sencillez van de la mano. Algunos programadores prefieren enfoques excesivamente complejos a lo que sería relativamente sencillo y de código simple. No añadir complejidad a la simplicidad logrará los mismos resultados. Se debe evitar el uso de arquitecturas complejas cuando un enfoque más simple sería más rápido y más eficiente.

Utilizar la oscuridad para proporcionar un control de seguridad siempre falla cuando es el único control. Esto no quiere decir que guardar secretos sea una mala idea. Simplemente significa que la seguridad de los sistemas con clave no debe ser dependiente en mantener ocultos los detalles.

Por ejemplo, la seguridad de una aplicación no debe centrarse únicamente en que el código fuente se mantiene en secreto. La seguridad debe depender de muchos

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

125

otros factores, incluidas las políticas de contraseñas y controles razonables, la defensa en profundidad, los límites de transacción, los controles de acceso a la red, y las auditorias.

Proporcionar defensa en profundidad: la defensa en profundidad es un concepto en un control razonable, será mejor realizar más controles que los riesgos de abordaje de diferentes maneras. Cuando se usan en profundidad los controles, pueden hacer grandes vulnerabilidades muy difíciles de explotar siendo poco probable que ocurran. Cuantas más capas de control, más difícil será eludirlas, pero también se debe tener en cuenta que los controles de seguridad no deben ser demasiado complejos, ya que esto dificultaría su gestión y mantenimiento.

Para la codificación segura se pueden combinar los controles de varios elementos como: la validación, el basado en niveles, los controles de auditoria centralizada, y los que requieren la actividad del usuario para iniciar sesión.

No confiar automáticamente el acceso de otros sistemas: la confianza implícita de los sistemas administrados externamente no se justifica, por lo tanto, la validación de acceso al sistema debe ser revisado cuando la solicitud es iniciada por el sistema externo. Todos los sistemas externos deben ser tratados de una manera similar.

Por ejemplo, al recibir las peticiones de otro sistema, la identidad del sistema que debe ser validado y el permiso verificado antes de procesar las peticiones. Si se reciben entradas desde el sistema, siempre se debe validar la entrada antes de la transformación.

Mantener los parches de seguridad hasta al día y parches: una vez identificados los problemas de seguridad, los vendedores lanzarán parches de seguridad o parches para evitar problemas en la vulnerabilidad. Por lo tanto, se deben revisar constantemente las notificaciones y actualizaciones de seguridad del proveedor y aplicar los parches de seguridad y parches en forma oportuna.

Mantener registros de auditoría: nunca se será capaz de evitar todos los ataques. No importa lo bien que estén diseñadas e implementadas sus defensas, siempre se escaparán flecos. Es muy importante que haya suficientes registros de auditoria in situ para poder descubrir cuándo y cómo ha ocurrido un ataque.

Procedimientos de registro de auditoría deben estar documentados. Se deben realizar registros de auditoría de las actividades de registro de usuario, excepciones y eventos de seguridad de la información.

En su caso, los eventos grabados técnicamente deben incluir: las actividades de administración de seguridad, el acceso restringido cuenta, el éxito y el fracaso de inicio de sesión / cierre de sesión, los intentos fallidos de acceder a

recuerde Dar al usuario el mínimo de privilegios ayuda a que los posibles atacantes tengan muy poca capacidad de maniobra.

126

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

los sistemas y la información, fechas y horas de actividad; fuente de la conexión y el acceso.

Los registros son un objetivo y, por tanto, han de ser garantizados. Siempre que sea posible, se deben bloquear los archivos de registro de manera que sólo los administradores tienen acceso a ellos. Idealmente, se deben generar registros en un servidor de registro independiente. Si alguien ataca un equipo, lo primero que buscará será los logs.

Los registros deben estar protegidos para evitar que haya alteraciones de los mensajes grabados, edición o eliminación de archivos de registro, que exceda la capacidad de almacenamiento de registros, la visualización de la información confidencial de los registros de personas no autorizadas; y retención de registros de auditoría que deba cumplir con los requerimientos del negocio.

OWASP Web Lista de verificación de seguridad de aplicaciones ––Las “Normas de aplicación de OWASP Seguridad Verificación 2009 Aplicación de estándares web” constituyen un documento que proporciona una lista de comprobación de seguridad de claves de controles para la verificación.

Estos son algunos ejemplos de los puntos de control para realizar la comprobación: –– Verificar que todas las páginas y recursos requieren autenticación, excepto los destinados específicamente a ser pública.

–– Verificar que todos los campos de contraseña no se hacen eco de la contraseña del usuario cuando se introduce, y que los campos de contraseña (o las formas que los contienen) tienen inhibida la capacidad de autocompletar.

–– Verificar que las sesiones se invalidan cuando el usuario cierra la sesión.

–– Comprobar que los usuarios sólo pueden acceder a las direcciones URL para las que poseen una autorización específica.

–– Se debe leer y comprender el documento de las “Normas de aplicación de seguridad OWASP Verificación 2009 Aplicación de estándares web”. Cada elemento de la lista de control está asociado a uno o varios niveles de verificación. El documento describe el requisito para cada nivel de verificación.

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

127

El top 10 de los riesgos de seguridad de aplicaciones según OWASP es: OWASP realizó un documento que identifica los diez riesgos de seguridad más importantes de las aplicaciones web y sugieren los remedios a implementar.

Estos son algunos ejemplos de los puntos de control para comprobar: –– Las fallos de inyección de datos, tales como SQL, OS, y la inyección LDAP, ocurren cuando los datos no son de confianza se envían a un intérprete como parte de un comando o consulta.

–– Fallos de scripting entre sitios (XSS) ocurren cuando una aplicación toma datos no confiables y los envía a un navegador web sin necesidad de una validación adecuada y escapar.

–– Falsificación de Petición de ataque Cross-Site (CSRF) de una sesión se inicia en el navegador de la víctima para enviar una petición HTTP segura, incluyendo una cookie de sesión de la víctima y cualquier otra información de autenticación se incluyen automáticamente, haciendo una aplicación web vulnerable.

–– Referencia de objeto directo inseguro que ocurre cuando un desarrollador expone una referencia a un objeto de aplicación interna, como un archivo, un directorio o base de datos de claves.

Estas son las áreas donde pueden ocurrir la mayoría de los fallos de seguridad de las aplicaciones web, y por lo tanto, donde se deben implementar las medidas preventivas.

Se deben implementar las recomendaciones de OWASP para contrarrestar las vulnerabilidades.

Según SANS, el top 25 de los errores de software más peligrosos son: SANS tiene otra lista que identifica los errores de software más comunes que pueden resultar en fallos y vulnerabilidades.

Estos son algunos ejemplos de los puntos de control para comprobar: –– Copia de búfer sin comprobar el tamaño de la entrada (“desbordamiento clásico de búfer”).

–– Dependencia de las entradas que no son de confianza en una decisión de seguridad.

–– Limitación incorrecta de un nombre de ruta de un directorio restringido (“Camino Transversal”).

–– No limitación en la subida de archivos que puedan ser de tipo peligroso.

recuerde OWASP y SANS son las dos organizaciones más fuertes en cuanto a los temas de seguridad web.

128

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

4.5.2 Conceptos y técnicas de identificación, autenticación y autorización o control de acceso.

Para los usuarios sus mayores preocupaciones sobre la seguridad del comercio electrónico son fundamentalmente los de los controles de acceso remoto. Cada vez que alguien necesita para hacer negocios, ya sea en línea o cara a cara, el cliente y el comerciante deben servir como identificación, autenticación y autorización. Los usuarios deben asegurarse de que saben exactamente lo que se está ejecutando el servidor Web con el que pretenden hacer negocios. Los comerciantes necesitan la identificación de sus clientes para asegurarse de que se les paga por sus productos y servicios.

En un caso alarmante de incumplimiento de identificación, autenticación y autorización ocurrió en 1996 y 1997, cuando los espectadores de fotos en varios sitios web recibieron unas elevadísimas facturas de teléfono. Las víctimas que habían descargado un “visor especial” en realidad estaban instalando un programa troyano que desconectaba su conexión con su ISP normales y reconectando (con el altavoz del módem apagado) a una serie de Moldavia en el centro de Europa.

A continuación, la llamada se desvía a un ISP en América del Norte, que continuó la sesión. Las llamadas de larga distancia continuaba hasta que el usuario se había desconectado, a veces horas más tarde, incluso cuando las víctimas pasaron a otros, quizás menos lascivos, sitios. En la Ciudad de Nueva York, un juez federal ordenó cerrar ese sitio, sin embargo, el sitio continúa en la Web e incluye advertencias de que los funcionarios encargados de hacer cumplir la ley y quienes tengan la intención de emprender acciones legales contra los propietarios no deben conectarse (no recomendamos que corre el riesgo de conectar a la misma).

Más tarde, en 1997, la FCC ordenó re-embolsar a las víctimas los 2,6 millones de dólares en cargos obtenidos de forma fraudulenta.

Identificación La identificación, de acuerdo con una recopilación actual de términos seguridad de la información, es el proceso que permite el reconocimiento de un usuario que describe a un sistema de procesamiento automatizado de datos. Esto es generalmente por el uso de nombres legibles por máquina únicas. En términos humanos, el cliente y el comerciante se involucran en la identificación mutua cuando (por ejemplo) dicen unos a otros sus nombres a través del teléfono. En el caso del troyano moldavo, la violación de la identificación se produjo cuando no había disposición alguna para la determinación de la identidad de la empresa que gestiona la estafa.

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

129

Autenticación La autenticación es “una identificación positiva, con un grado de certeza suficiente para permitir ciertos derechos o privilegios a la persona o cosa identificada positivamente.” En términos más simples, es “El acto de verificación de la identidad declarada de un individuo, la estación o el autor”. En un contacto humano por teléfono, el cliente y el comerciante pueden reconocerse (autenticarse) entre sí por sus voces familiares. El troyano moldavo violó el principio de autenticación al afirmar que su software era un archivo espectador cuando en realidad era un ISP-switcher.

Los métodos clásicos para la correlación de identidades virtuales y físicos en el ciberespacio son paralelos a los métodos utilizados para la autenticación de los seres humanos en el mundo físico. Las cuatro categorías de autenticación de la información son: –– Lo que se sabe la contraseña o frase de contraseña, por ejemplo; –– Lo que se hace por ejemplo, ¿cómo se firma el nombre de uno?; –– Lo que está por ejemplo, una es la cara u otros atributos biométricos, como las huellas dactilares; –– Lo que tenemos por ejemplo, una señal, como una llave o un certificado, como una licencia de conducir.

Todos estos tipos de autenticación se utilizan en el ciberespacio. El último ejemplo es particularmente interesante: Los certificados tienen un papel crucial en la autenticación de personas (o programas o máquinas) en el mundo del e-commerce. La licencia de conducir, por ejemplo, si se supone que es real, dice que un comerciante que en algún momento en el pasado, una autoridad de certificación (el departamento de emisión de tráfico) ha emprendido algunas medidas para garantizar que la información de la licencia es correcta. En el ciberespacio, la verificación de la legitimidad de un certificado puede ser más fácil que en el espacio real.

Autenticación conduce a un concepto relacionado, el del no repudio. Una definición formal de no repudio es “Método por el cual el emisor de datos se proporciona con un comprobante de entrega y el destinatario tiene la seguridad de la identidad del emisor, por lo que ni la tarde se puede negar haber procesado los datos.” No repudio, como veremos en la siguiente sección sobre cifrado, depende de la afirmación de que la autenticidad no se ha violado la hora de identificar el origen de la transacción o un mensaje.

recuerde La identificación se refiere al reconocimiento del usuario, mientras que la autenticación dotará de los privilegios configurados a los usuarios identificados positivamente.

130

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Autorización La autorización es la concesión a un usuario, programa o procesar el derecho de acceso. En el mundo real, experimentamos la autorización cada vez que un comerciante consulta nuestra VISA o MasterCard de servicio para ver si estamos autorizados a gastar una cierta cantidad de dinero en su establecimiento.

El troyano moldavo violó por una autorización fraudulenta la apropiación del derecho de desconectar una llamada de teléfono e iniciar una llamada de larga distancia caro sin previo aviso o permiso de la víctima.

En el entorno de mainframe, la autorización depende del sistema operativo y el nivel de seguridad que los administradores de sistemas han impuesto. La identificación y autenticación (I & A) comienzan cuando se inicia una sesión.

Una sesión es una actividad durante un período de tiempo, la actividad es el acceso a un ordenador / recursos de la red por un usuario: un período de tiempo es limitado por iniciación de sesión (una forma de inicio de sesión) y la terminación de la sesión (una forma de cierre de sesión). Sin embargo, en la web, la mayoría de las interacciones son sin sesión, por ejemplo, no hay identificación y autenticación cuando un usuario anónimo accede a una página pública en un sitio Web. No hay ningún inicio de sesión y cierre de sesión en tales circunstancias. Interacciones Web requieren de I & A únicamente cuando el usuario y el propietario Web están de acuerdo en establecer una sesión segura. Por lo general, las transacciones web seguras requieren algún tipo de inicio y cierre de sesión, incluso si estos pasos no se etiquetan expresamente como tales.

La integridad y la autenticidad de sesión pueden ser violados de diversas maneras.

Piggybacking es el uso no autorizado de una sesión existente por personal no autorizado. Este problema es difícil de imaginar en el mundo real, en la que sería poco probable que alguien podría, por ejemplo, cortado en el medio de una conversación telefónica a los bienes y servicios de pedidos utilizando el buen nombre de otra persona y tarjeta de crédito.

En el ciberespacio, sin embargo, es muy común que los usuarios iniciar una transacción en un terminal o estación de trabajo. Si una persona deshonesta se sitúa en ese lugar, es posible mal uso de la sesión de la persona ausente. Un problema común que lleva a cuestas es el mal uso de algún otro programa de correo electrónico para enviar mensajes falsos a nombre de la persona ausente. Otro ejemplo podría tener el ladrón entrando en una sesión para cambiar una orden o tener bienes enviados a una dirección diferente, pero ser pagados con tarjeta de crédito la sesión del iniciador. Tales ejemplos de fraude puede tener consecuencias desastrosas para las víctimas, en general, todas las historias de noticias sobre este tipo de abuso reduce la confianza en la seguridad del comercio electrónico.

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Un ataque más técnico se llama secuestro de sesión: así se permite a un atacante hacerse con un terminal o sesión de un usuario abierta que ha sido autenticado por el sistema de ataques de secuestro que por lo general se llevan a cabo en un equipo remoto, aunque a veces es posible secuestrar una conexión desde un ordenador de la ruta entre el equipo remoto y el equipo local.

El secuestro se produce cuando un intruso utiliza privilegios mal establecidos para aprovechar el software de un sistema que accede a ellos o controla el comportamiento del TCP local. Un logro permite a un atacante secuestrar para pedir prestado o robar una conexión abierta (por ejemplo, una sesión de Telnet) en un servidor remoto para sus propios fines. En el caso probable de que el usuario real ya ha sido autenticado en el host remoto, las pulsaciones de teclado que envía el atacante se reciben y procesan como si escrito por el usuario.

En resumen, la identificación, autenticación y autorización son componentes normales de cualquier transacción comercial y deben ser garantizados por los sistemas de comunicaciones y software de mediación en la relación entre el proveedor y el cliente.

El papel del cifrado Todas las tecnologías propuestas por empresas de la competencia y los consorcios, como fichas, protocolos seguros para la transmisión de datos, certificados digitales, y las normas para confiar en los sitios Web implican algún tipo de cifrado. El cifrado es el proceso de transformación de los datos en una forma ininteligible, de tal manera que los datos originales se obtengan sin necesidad de utilizar el proceso de desencriptación inversa.

Privacidad –– P3 La Plataforma de Principios de Privacidad (P3) cuenta con el respaldo de la World Wide Web Consortium, la Asociación de Marketing Directo y (originalmente) Microsoft. Esta norma ayuda a describir y definir las limitaciones en la recopilación y el uso de la información privada de los usuarios de los sitios Web. –– TRUSTe TRUSTe (antes conocido como eTrust) es una iniciativa sin fines de lucro que certifica el respeto a la privacidad de los usuarios de los sitios Web. Los usuarios tienen el poder de controlar la cantidad de información personal será revelada

131

recuerde La autorización consiste en la concesión de los derechos de acceso.

132

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

mientras están en línea. La marca de confianza TRUSTe indica que un sitio web se compromete a proteger la privacidad del usuario, y su programa de garantía de la intimidad con el respaldo de revisiones periódicas por TRUSTe, que también almacenan las semillas del sitio con la información personal del usuario para ver si es mal utilizado. Además, Coopers & Lybrand y KPMG Peat Marwick realizan auditoria al azar de los sitios; TRUSTe también recibe retroalimentación de los clientes sobre los sitios trustmarked. La marca de confianza de TRUSTe ayuda a los usuarios se sientan seguros de su privacidad personal. Hay tres niveles de la marca de confianza: -- Intercambio de terceros: es el nivel más bajo TRUSTe. El proveedor comparte información con otros proveedores; -- Intercambio uno-a-uno: el proveedor mantiene la información en el servidor Web, pero utiliza sólo para la interacción con ese cliente específico; -- No hay intercambio de garantía: es el nivel más alto de TRUSTe. El vendedor no captura o mantiene los datos del cliente.

–– SSL Netscape Communications Corporation, creadores del navegador Netscape Navigator, crearon el protocolo Secure Sockets Layer (SSL) para proteger la información que se transmite a través de la Internet. Además, el SSL proporciona para la autenticación de los servidores Web. Identificación –– Fichas Muchos métodos de identificación y de autenticación se basan en fichas. Estos dispositivos encapsulan microprocesadores en un paquete resistente a la manipulación, que por lo general el tamaño de una tarjeta de crédito gruesa. Los generadores de contraseñas de un solo uso tienen un panel LCD para mostrar una cadena alfanumérica que consta de su propio número de serie junto con la hora y la fecha y cifrados adecuadamente de modo que sólo el software host puede deducir el número de serie del identificador que generó esa cadena en particular.

Tales dispositivos actualmente cuestan alrededor de 30 dólares o menos.

Las tarjetas inteligentes son similares a la mano, siendo capaces a la vez de generar contraseñas y también se pueden utilizar para la autenticación; sin embargo, requieren lectores especializados. Algunos testigos han sido creados para interactuar con la unidad de disco común. Es posible la autenticación basada en

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

PC-card (antes “PCMCIA”), pero estos dispositivos son más caros que las tarjetas inteligentes, que cuesta alrededor de 60 dólares, sin contar a los lectores.

Tales dispositivos propiedad de los usuarios pueden funcionar como monederos electrónicos y jugar un papel en los pagos anónimos diseñados para proteger la privacidad del usuario.

–– FIPS 196 Federal Information Processing Standard del Gobierno de EE.UU. FIPS 196 define cómo se va a utilizar la PKC para la autenticación de usuario con el sistema desafío-respuesta. Los proveedores destinados a la contratación pública tendrán que tomar en cuenta FIPS 196 en sus diseños de sistemas.

–– vCard La especificación vCard es gestionada por el Consorcio de correo de Internet, sino que permite que se intercambien “tarjetas de visita electrónicas”. El protocolo vCard se ha presentado a la IETF para su aprobación como standard abierto.

Autenticación –– Los certificados digitales Los certificados digitales son cada vez más importantes para comercio por Internet. Básicamente, para generar certificados digitales, los usuarios y los comerciantes utilizan claves secretas en conjunto para establecer confianza y los dispositivos pueden autenticarse entre sí usando certificados digitales. Los cer-

133

recuerde Los esfuerzos del cifrado se centran en hacer ininteligibles los datos introducidos, si bien el cifrado de no asegura la seguridad de los mismos.

134

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

tificados digitales se utilizan para autenticar otros mensajes electrónicos de correo electrónico y, además, las empresas pueden emite certificados digitales a los empleados, evitando la necesidad de identificadores de usuario y contraseñas para tener acceso a intranets y otras redes corporativas. Sin embargo, el uso de certificados fuera una sola empresa puede ser complicado ya que los certificados digitales emitidos bajo diferentes protocolos son, en general, todavía no son interoperables.

–– CCITT (UIT) X.509v3 estándar de certificados digitales La mayoría de los certificados digitales se basan en el standard CCITT (UIT) X.509v3. Los vendedores Groupware coinciden en que X.509 es la mejor manera de proteger la información de transferencia de Internet, Lotus, Microsoft y Novell acordaron apoyar X.509 (utilizado por VeriSign y GTE Service Corp) y se cree que el cumplimiento de X.509 mejora la interoperabilidad y la simplificación de los protocolos de seguridad. Otros partidarios de X.509 incluyen Lotus (Domino 4.6 apoyará certificados X.509) y Microsoft (la próxima versión de Microsoft Exchange apoyará certificados X.509). NDS servicios de directorio de Novell apoyan X.509 desde 1998. La infraestructura de clave pública X.509 compatible, a veces se conoce como la PKIX. –– SESAME norma europea para la autenticación de certificados digitales En Europa, Bull, ICL y Siemens Nixdorf están mejorando el estándar SESAME para los certificados digitales. Certificados SÉSAMO expiran después de minutos o días para controlar el acceso a los privilegios del sistema. SESAME finalmente incorpora el protocolo X.509.

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

–– Entidades de certificación de terceros La autenticidad de los certificados digitales se puede visualizar haciendo que cada certificado firmado por una entidad (o persona) de confianza sea visible por ambas partes en la transacción. En un modelo popular de la autenticación de certificados, una web de confianza entre las personas y las organizaciones se asegura de que cada clave pública está firmado por alguien que sabe que la clave pública es auténtica. En un modelo más jerárquico, llaves públicas utilizadas para firmar los certificados son autenticados por las autoridades de certificación (CA) que son a su vez autenticados por mayores niveles de CA. Las organizaciones que necesitan su propia infraestructura de certificación pueden comprar el software de los vendedores, el vinculado de los certificados a una estructura de directorios facilita sistemas de un solo inicio de sesión, donde los usuarios tienen que identificarse y autenticarse a sí mismos ante el sistema de una sola vez para tener acceso a todos los servicios de sistemas autorizados.

Sin embargo, las CA no han tenido en cuenta la importancia y la historia de las relaciones comerciales bilaterales, los productos de CA de hoy son complejos, difíciles de manejar y asustan a la gente.

Quizás como resultado de esta complejidad, en una encuesta en diciembre de 1996 realizada por Netcraft y O’Reilly & Associates, en la que examinaron 648.613 sitios en el WWW encontraron a menos de 1% de los sitios WWW que ofrece tanto SSL y autenticación de terceros.

–– SET Autorización y no repudio Las Transacciones Electrónicas Seguras (SET) se basan en un protocolo que requiere certificados digitales para cada uso de la tarjeta de crédito por un usuario intenta pagar una mercancía. MasterCard y Visa anunciaron la norma establecida en febrero de 1996; SET también es apoyado por GTE, IBM, Microsoft, Netscape, SAIC,Terisa y VeriSign. Sitios compatibles SET protegen a los comerciantes de pagos no autorizados y el repudio de los clientes, los bancos que utilizan SET están protegidos contra compras no autorizadas que utilizan sus tarjetas, y los consumidores están protegidos contra impostores mercantes y el robo de los números de la tarjeta de crédito. Los partidarios dicen SET permitirá a los consumidores para relajarse por la seguridad en la Web. –– OFX Open Financial Exchange El Open Financial Exchange (OFX) con el apoyo de Microsoft, Intuit, Checkfree y otros. Los certificados digitales incluye el estándar usado para el intercambio

135

136

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

de entre las instituciones financieras para autenticar transacciones. VeriSign, actualmente el más importante CA de terceros, ha emitido un nuevo tipo de ID digital llamado el ID de servicio financiero que es utilizable por las instituciones de apoyo a la especificación OFX. El ID de Servicios Financieros será proteger las transacciones como en aplicaciones bancarias.

–– Gold Standard En competencia directa con OFX, Integrion (una empresa conjunta de 17 bancos norteamericanos IBM y Visa) es la creación de un protocolo de certificación financiera independiente llamada “The Gold Standard”.

Autorización y Single Sign-On –– Kerberos Kerberos fue desarrollado en el MIT en la década de 1980 como parte de un plan ampliado para la identificación del usuario, la autenticación y autorización. La seguridad del sistema depende en gran medida de la protección de un servidor de Kerberos que habla con los usuarios y los servicios informáticos, tales como impresoras y servidores de archivos. Una vez que el usuario se ha inscrito con seguridad en el servidor de Kerberos, las contraseñas de los usuarios nunca viajan por el servidor de autenticación Kerberos.

Cuando se solicita una relación bilateral con un servicio por un usuario autenticado es en sí autenticado por el servidor de Kerberos que emite certificados digitales (llamados tickets) para permitir el uso de los servicios específicos por parte de usuarios específicos. Kerberos requiere aplicaciones y servidores que se kerberizan (se modifican para su uso con Kerberos, ya que la mayoría del software off-the-shelf no soporta Kerberos). Sin embargo, Microsoft Kerberos define como Windows NT v5, como un mecanismo de autenticación y hay un interés considerable en la ampliación de Kerberos a otras aplicaciones como parte del entorno de computación distribuida (DCE) con el apoyo de un consorcio de fabricantes de ordenadores.

–– OPS Open Norma de Perfiles para la Autorización y Single Sign-On La Norma de Perfiles Abierta, apoyada por Netscape, Firefly y VeriSign elimina la necesidad de los usuarios de volver a introducir su información de identificación más de una vez en los sitios Web. También está diseñado para permitir que los

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

137

sitios Web para adaptar su presentación a un usuario mediante la lectura de la información personal que haya sido autorizadas por el usuario y se transmite al servidor a través de tarjetas de visita y los certificados digitales. La OPS cuenta con el apoyo de activistas de la privacidad, como la EFF, EPIC y eTrust / CommerceNet (ahora TRUSTe).

Interoperabilidad Los estándares en competencia hacen que sea difícil para los usuarios y las empresas comunicarse de manera efectiva, y muchos observadores esperan que el campo va a desarrollar estándares para la interoperabilidad de los diferentes certificados y protocolos. La mayoría del directorio/ certificado de esquemas de vinculación que se refieren los certificados de usuarios y servidores específicos suelen utilizar LDAP, Lightweight Directory Access Protocol, y hay algunos hablan de la fusión de OFX y el “The Gold Standard”, pero a partir de octubre 1997 no había habido progresos notificados.

Interfaces de programación de aplicaciones (API) que permiten que diferentes programas inter-operen. Es frustrante que varios marcos API estén en fase de desarrollo por parte de grupos de proveedores que compiten y que las normas propuestas no explican cómo pasar de autenticación a autorización. Gradient Technologies, especialista en kerberizar, apoya la integración de la infraestructura de clave pública (PKI) con Kerberos/ DCE. El marco SecureOne integra las API de programas antivirus, autenticación, cifrado y certificados digitales, RSA, VeriSign, McAfee Security Dynamics apoyan SecureOne. 4.5.3 Identificación y autenticación avanzada. Certificados digitales Los certificados digitales son los equivalentes electrónicos a licencias de conducir, pasaportes y tarjetas de identidad. Se puede presentar un Certificado Digital electrónicamente para probar su identidad o su derecho a acceder a cierta información o servicios en línea.

Los certificados digitales se unen una identidad, asociando un par de claves electrónicas que pueden ser usadas para encriptar y firmar información digital. Un Certificado Digital hace posible verificar la afirmación de alguien que tienen el derecho de utilizar una clave determinada, que ayuda a evitar que la gente use claves falsificadas para hacerse pasar por otros usuarios. Utilizado junto con el cifrado, los certificados digitales proporcionan una solución de seguridad más completa, asegurando la identidad de todas las partes involucradas en una transacción.

recuerde La identificación unívoca de la persona centra buena parte de los esfuerzos enfocados a la seguridad en la red.

138

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Un certificado digital es emitido por una autoridad de certificación (CA) y firmada con la clave privada de la CA. Un certificado digital contiene típicamente el: –– Clave pública del propietario –– Nombre del propietario –– Fecha de caducidad de la clave pública –– Nombre del emisor (la CA que emitió el Certificado Digital) –– Número de serie del certificado digital –– La firma digital del emisor El formato más ampliamente aceptado para certificados digitales se define en la norma internacional CCITT X.509, por lo que los certificados pueden ser leídos o escritos por cualquier aplicación que cumpla con X.509. Otras mejoras se encuentran en los estándares PKCS y el estándar PEM. Los certificados digitales se pueden utilizar para una variedad de las transacciones electrónicas, incluyendo correo electrónico, comercio electrónico, trabajo en grupo y las transferencias electrónicas de fondos. Algunos como de Netscape Enterprise Server requiere un certificado digital para cada servidor seguro.

Por ejemplo, en un centro comercial virtual de electrónica para cargar la compra de software usando el servidor de Netscape, solicita el certificado digital del servidor para autenticar la identidad del operador de centros comerciales y de los contenidos proporcionados por el comerciante. Sin la autenticación del servidor,

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

el comprador no debe confiar en que el operador o el comerciante para cambiar información sensible como números de tarjetas de crédito. El Certificado Digital es un instrumento para establecer un canal seguro de comunicación de información sensible al operador comercial.

Los centros comerciales virtuales, la banca electrónica y otros servicios electrónicos son cada vez más comunes, ofreciendo la comodidad y flexibilidad de servicio las veinticuatro horas del día directamente desde su casa. Sin embargo, sus preocupaciones acerca de la privacidad y la seguridad podrían impedir que se aprovechen de este nuevo medio para su propio negocio.

El cifrado por sí solo no es suficiente, ya que no proporciona ninguna prueba de la identidad del remitente de la información cifrada. Sin elementos especiales para el guardado seguro, corre el riesgo de ser suplantado en línea. Los certificados digitales enfrentan este problema, proporcionando un medio electrónico de verificación de la identidad de una persona. Utilizado junto con el cifrado, los certificados digitales proporcionan una solución de seguridad más completa, asegurando la identidad de todas las partes involucradas en una transacción.

Del mismo modo, un servidor seguro debe tener su propio certificado digital para garantizar a los usuarios que el servidor se ejecuta por la organización que pretende ser afiliado y que el contenido siempre es legítimo.

Tipos de certificados: –– Certificados de servidor, que permiten a los servidores Web operar de forma segura. Un certificado de servidor identifica inequívocamente y autentica el servidor, y encripta la información que pasa entre el servidor y un navegador Web. –– Certificados Developer se utilizan en combinación con la tecnología de Microsoft AuthenticodeTM (validación de software) proporcionar a los clientes la información y la seguridad que necesitan al descargar software de Internet.

–– Certificados digitales personales, son utilizados por los individuos cuando se intercambian mensajes con otros usuarios o servicios en línea.

Las clases se diferencian por su nivel de seguridad (el nivel de confianza que se puede colocar en el Certificado Digital basado en el conocimiento de los procedimientos utilizados para verificar la identidad del propietario). Los requisitos de identificación son mayores para las clases más altas numeradas, por ejemplo, un Certificado Digital de Clase 1 verifica la dirección de correo electrónico del propietario, mientras que un Certificado Digital Clase 2 ofrece la garantía adicional de la verificación de la identidad personal del propietario.

139

140

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Supongamos que Alicia quiere enviar un mensaje firmado a Roberto. Se crea un resumen del mensaje mediante el uso de una función hash sobre el mensaje. El resumen de mensaje sirve como una “huella digital” del mensaje, si cualquier parte del mensaje se modifica, la función hash devuelve un resultado diferente.

Alicia cifra el resumen del mensaje con su clave privada. Este resumen de mensaje cifrado es la firma digital para el mensaje.

Alicia envía tanto el mensaje y la firma digital a Roberto. Cuando Roberto los recibe, que descifra la firma utilizando la clave pública de Alicia, lo que revela el resumen del mensaje. Para verificar el mensaje, entonces los hash del mensaje con la misma función hash utilizada por Alicia, se compara el resultado con el resumen del mensaje que recibió de Alicia. Si son exactamente iguales, Roberto puede estar seguro de que el mensaje efectivamente provienen de Alicia y no ha cambiado desde que se firmó. Si los resúmenes de mensaje no son iguales, el mensaje o bien se originó en otro lugar o fue alterado después de su firma.

El uso de una firma digital no cifra el mensaje en sí. Si Alicia quiere asegurar la privacidad del mensaje, también debe cifrar utilizando la clave pública de Roberto.

Sólo entonces Roberto puede leer el mensaje por descifrar con su clave privada.

Si bien eran viables, un intruso podría adjuntar un mensaje falso a la firma de Alicia. Se han diseñado funciones de hash específicas para tener la propiedad de que la búsqueda de una coincidencia no es factible, y por lo tanto se consideran adecuados para su uso en la criptografía.

Uno o más certificados digitales pueden acompañar una firma digital. Si un Certificado Digital está presente, el destinatario (o un tercero) puede comprobar la autenticidad de la clave pública Normalmente, una clave caduca después de un cierto período de tiempo, por ejemplo un año, y un documento firmado con una clave expirada no debe ser aceptado. Sin embargo, hay muchos casos en los que es necesario que los documentos firmados se consideren legalmente válidos durante mucho más tiempo de dos años, como los alquileres y los contratos a largo plazo, por ejemplo. Al registrar el contrato con un servicio de sellado de tiempo digital en el momento de su firma, la firma puede ser validada aún después del vencimiento de la clave.

recuerde

4.5.4 Concepto de sesión. Conservación de sesiones

El certificado digital lo firma el prestador de servicios, que es quien se compromete a la identificación.

Una sesión de web es una secuencia de la red de solicitud de HTTP y las transacciones de respuesta asociadas al mismo usuario. Las aplicaciones web modernas y complejas requieren la retención de información o de estado acerca de cada usuario durante la duración de múltiples peticiones. Por lo tanto, las sesiones ofrecen la posibilidad de establecer las variables (como los derechos de acceso

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

y los ajustes de localización) que se aplicarán a todas y cada interacción tiene un usuario con la aplicación web para la duración de la sesión.

Las aplicaciones Web pueden crear sesiones para realizar un seguimiento de los usuarios anónimos después de la primera petición del usuario. Un ejemplo podría ser el mantenimiento de la preferencia de idioma del usuario. Además, las aplicaciones web hará uso de sesiones una vez que el usuario se ha autenticado. Esto asegura la capacidad para identificar al usuario en todas las solicitudes posteriores, así como ser capaz de aplicar los controles de acceso de seguridad, el acceso autorizado a los datos privados de usuario, y para aumentar la facilidad de uso de la aplicación. Por lo tanto, las aplicaciones web actuales pueden proporcionar capacidades de sesión tanto antes como en la autenticación de mensaje.

Una vez que una sesión autenticada ha sido establecida, el ID de sesión (o símbolo) es temporalmente equivalente al método de autenticación más seguro que utiliza la aplicación, tales como nombre de usuario y contraseña, contraseñas de un solo uso (OTP), certificados digitales basados ​​en cliente, tarjetas inteligentes, o la biometría (tales como huellas dactilares o de la retina del ojo).

El ID de sesión o ficha une las credenciales de autenticación del usuario (en la forma de una sesión de usuario) para el tráfico HTTP de usuario y el acceso apropiado controlo forzado por la aplicación web. La complejidad de estos tres componentes (autenticación, gestión de sesiones, y el control de acceso) en las aplicaciones web modernas, más el hecho de que su aplicación y unión reside en las manos de los desarrolladores web (como marco de desarrollo web no proporcionan estrictas relaciones entre estos módulos), hace que la implementación de un módulo de gestión de sesión segura sea un tema muy desafiante.

La divulgación, la captura, la predicción, la fuerza bruta, o la fijación de la identificación de la sesión dará lugar a secuestros de sesión (o sidejacking) los ataques, cuando un atacante puede suplantar completamente a un usuario víctima en la aplicación web. Los atacantes pueden realizar dos tipos de secuestro de sesión, los ataques dirigidos o genéricos. En un ataque dirigido, el objetivo del atacante es hacerse pasar por un usuario web que es víctima de una aplicación específica (o privilegio). Para los ataques genéricos, el objetivo del atacante es hacerse pasar (o conseguir acceso como) cualquier usuario válido y legítimo en la aplicación web.

La aplicación de gestión de sesión define el mecanismo de cambio que se utilizará entre el usuario y la aplicación web

141

142

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

recuerde La conservación de versiones es un tema que trae mucha controversia, ya que se intenta favorecer la comodidad del usuario, pero sólo cuando esto no ponga en peligro la seguridad.

para compartir e intercambiar continuamente el ID de sesión. Existen múltiples mecanismos disponibles en HTTP para mantener el estado de sesión en las aplicaciones web, como cookies (encabezado HTTP estándar), los parámetros URL, argumentos URL de peticiones GET, los argumentos del cuerpo en las peticiones POST, como los campos de formulario ocultos (formularios HTML), o cabeceras HTTP de propiedad.

El mecanismo de intercambio de ID de sesión preferido debe permitir definir las propiedades avanzadas, tales como la fecha y hora de vencimiento de contadores, o restricciones de uso granulares. Esta es una de las razones por las que las cookies son uno de los mecanismos de intercambio de identificación de sesión más ampliamente utilizadas, y ofrece capacidades avanzadas que no están disponibles en otros métodos.

El uso de los mecanismos específicos de la sesión Identificación, tales como aquellas en las que el ID está incluido en el URL, puede revelar el identificador de sesión (en enlaces a las webs y los registros, historial de navegación web y los favoritos, el encabezado Referer o motores de búsqueda), así como facilitar otros ataques, tales como la manipulación de los ataques de fijación ID o sesión.

4.5.5 Sistemas de uso común para la conservación de las sesiones en aplicaciones web. Single Sign-on y Single Sign-out Inicio de sesión único (SSO) es una propiedad de control de acceso múltiple relacionado con los sistemas de software independientes. Con esta propiedad un usuario inicia sesión en una vez y se accede a todos los sistemas sin que se le pida que entre de nuevo en cada uno de ellos. Por el contrario, Single sign-off es la propiedad por la que una sola acción permitirá cerrar la sesión, finalizando el acceso a múltiples sistemas de software.

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Las diferentes aplicaciones y recursos tienen diferentes mecanismos de autenticación, registro único se tiene que traducir internamente y almacenar credenciales diferentes en comparación con lo que se utiliza para la autenticación inicial.

4.6 Despliegue de aplicaciones web La organización de los recursos humanos tiene una nueva aplicación basada en Web para la actualización de los registros de empleados. Compras quiere implementar una nueva aplicación para las solicitudes de capital. El próximo mes, la aplicación “campaña de contribuciones de caridad” debe ser completamente funcional. ¿Cómo una organización de tecnología de la información (IT) puede garantizar la capacidad suficiente para soportar estas nuevas aplicaciones al tiempo que proporciona un rendimiento aceptable para los usuarios?

Basado en la experiencia, se sabe que: –– La planificación de capacidad es más rentable y eficiente si se hace antes del despliegue –– Los problemas de rendimiento resultantes de la falta de capacidad son más complejos y costosos de resolver después de la implementación –– La capacidad de planificación proporciona la información necesaria para evaluar estratégicamente las futuras necesidades de TI para nuevos equipos, capacidad de red adicional y nueva –– Involucrar a una organización independiente con experiencia en la aplicación Web, en sistemas y arquitecturas de red, ayuda a garantizar un análisis imparcial de las necesidades de recursos de aplicaciones. Esto a su vez ayuda a que el equipo de implementación prepare adecuadamente a los sistemas y redes para las nuevas cargas de tráfico.

4.6.1 Características del proceso de despliegue Muchas empresas implementan nuevos procesos sólo después se ha producido algún problema o avería. Sin embargo, a menudo, los resultados de fracaso porque los desarrolladores no tienen en cuenta la complejidad del sistema y conexión a la hora de diseñar o desarrollar aplicaciones. Además, los desarrolladores de aplicaciones no siempre son conscientes de la cantidad de potencial de usuarios que acceden a un sitio Web en cualquier momento dado. Sin esta información, la planificación de la capacidad no es más que meras conjeturas.

143

144

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Por ejemplo: Una empresa implementa una nueva solicitud de revisión por pares basado en la Web. Después de una larga serie de problemas de rendimiento, los usuarios están informados de que, hasta nuevo aviso, se debe reanudar el uso de la versión anterior basada en la aplicación, una decisión que se une a una menor productividad y al descenso de la satisfacción del usuario.

Este tipo de situaciones se pueden prevenir si las empresas aprendan a valorar correctamente nuevas aplicaciones desde el principio. Esto requiere una comprensión de cómo las aplicaciones Web pueden afectar de una organización de TI arquitectura de sus sistemas operativos, tipos de servidores y comunicaciones de red subyacente, además de la arquitectura de la aplicación. Asegurar una evaluación estandarizada también exige una metodología de análisis fiable, que incluye la entrada de datos y estructuras de información definidas. Es importante entender que la planificación de la capacidad representa costos adicionales para el desarrollo y despliegue de aplicaciones y de los gastos que deben ser incluidos en el proceso de evaluación.

La adecuada aplicación de costos y la creación de la estructura organizativa de apoyo son esenciales en la aplicación de un proceso de planificación de la capacidad. Lo ideal sería que las empresas diseñen la organización para incluir la planificación de capacidad como parte de los costos de desarrollo. Esto no sólo permite una vuelta más precisa de los cálculos de la inversión (ROI), pero también trae el equipo de desarrollo en el proceso. El equipo de planificación de la capacidad debe seguir siendo una entidad separada, con las decisiones finales que son propiedad del equipo de implementación.

Por ejemplo, si el equipo de desarrollo fueron a solicitar una excepción para eludir el proceso de planificación, el equipo de implementación debe estar autorizado para aprobar o rechazar la solicitud. En algunos casos, las aplicaciones pueden tener un impacto mínimo y los costos de planificación hacen que pueda no ser económicamente viable.

En algunas organizaciones, los costos relacionados con la planificación de capacidad se cargan de nuevo al equipo de desarrollo de aplicaciones (recursos humanos, etc.) El equipo de planificación recibe la entrada del equipo de desarrollo, lleva a cabo el análisis de la capacidad de planificación y pasa los resultados a la organización de implementación.

Con estos resultados del equipo de implementación se inicia la identificación y aplicación de recursos para apoyar los requerimientos de la nueva aplicación. Un beneficio adicional de este proceso es que el equipo de desarrollo puede encontrarse con que la comprensión de la comunidad de usuarios es incorrecta. Esto

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

proporciona una oportunidad para modificar el diseño para apoyar un mayor acceso de usuario real esperado. Si se pide al equipo de desarrollo de una excepción al proceso de evaluación, el equipo de planificación, simplemente pasa la excepción junto con el equipo de implementación para su aprobación. El equipo de implementación tiene la responsabilidad final de la ejecución de la aplicación.

4.6.2 Definición del proceso de despliegue de aplicaciones web.Verificación.

Los proyectos de desarrollo de software son únicos desde la perspectiva de que su estado cambia sustancialmente durante un período de tiempo llamado “aplicación” (lo que otros también podrían llamar “el despliegue de producción”, y muchas otras variaciones sobre este tema). La singularidad de su situación es impulsada por el hecho de que a lo largo de una gran parte de su ciclo de vida no son más que un potencial a la espera de hacerse realidad. Sólo una vez que se mueven en el entorno de producción de la organización y se agregan a los activos oficiales registran que la tecnología se convierte en algo real, un activo de la tecnología que se puede utilizar para realizar el objeto para el que fue creado.

Parte de la singularidad de proyectos de software en comparación con, por ejemplo, los proyectos de construcción, surge del hecho de que mientras que un edificio está siendo construido y elaborado en una sola ubicación física progresivamente, el software se somete a las transformaciones que lo llevan a través una serie de entornos antes de que llegue a su lugar de descanso final en el entorno de producción.

Para ilustrar el viaje que una parte del código tiene que recorrer, en un entorno de software típico necesitará el código de software pase por los siguientes pasos:

––Entorno de desarrollo –– Ambiente Testing System –– Entorno de Pruebas de Integración –– El estrés y el entorno de pruebas de volumen –– Entorno de usuario de pruebas de aceptación –– Entorno de despliegue Pre-Producción –– Entorno de producción El riesgo evidente de que necesita ser administrado a lo largo de este proceso es la similitud entre estos diversos entornos. El viaje que el software tiene que tomar desde el momento en que está siendo desarrollado por el programador hasta que se coloca en una plataforma accesible para el usuario final es peligroso y lleno de peligros.

145

recuerde El despliegue, como parte del proceso de creación de software, ha de tener su propia planificación, lo que optimizará su impacto.

146

Unidad didáctica 4. Desarrollo y despliegue de aplicaciones web

Aunque los planes de proyecto principal se refieren a la ejecución de una manera breve y concisa, están a menudo acompañados de una instalación detallada y robusta y las listas de verificación y notas de implementación. En cierto modo, la implementación de software en producción es un proyecto en sí mismo, acompañado de artefactos formales y compensaciones.

Así se necesitarían qué artefactos clave, como mínimo, han de acompañar a una implementación de producción exitoso. Por ejemplo: –– Matriz de actores: a todas las personas y las unidades de la organización (internos y externos) necesarios para la implementación exitosa. Esto incluirá, por ejemplo, el equipo del proyecto asignado a la implementación, los grupos de apoyo necesarios, el resto de negocios y tecnología de las partes interesadas.

Un RACI detallado será necesario para asegurar roles claros y responsabilidades se identifican de tal manera que no hay ambigüedad sobre quién hace qué y en qué capacidad.

–– Plan de Implementación Detallado/ Instrucciones de instalación/ Hojas Run: listas detalladas que determinan lo que hay que hacer, cuando hay que hacerlo y quién va a hacerlo. Se debe incluir toda la información relevante para llevar a cabo estas instrucciones, incluidos los nombres de los servidores, versiones de aplicaciones, y cualquier otro parámetro necesario. Ningún detalle (a menos que sea absolutamente trivial) debe dejarse a la interpretación o la opinión personal.

–– Puntos de decisión No-Go: un buen plan debe permitir seguir y dejar seguir puntos, con instrucciones claras de cómo se toman estas decisiones y por quién. El uso de No-Go considera apropiado, el plan debe incluir un plan de Back-Out detallado con todas las instrucciones pertinentes de manera de revertir el trabajo realizado hasta el momento para entornos de producción de la organización queda afectada.

recuerde La migración es un proceso clave que, si bien debería requerir muchos menos recursos para su elaboración, es un punto crítico en el sistema, por lo que se debe realizar con la debida atención.

–– Verificación de implementación: que es una buena práctica para completar la implementación de una serie de verificaciones encaminadas a confirmar que es correcta desde un punto de vista técnico y de negocios. Estas verificaciones son generalmente llamados pruebas de verificación técnica (TVT) y pruebas de verificación de negocios (BVT). El primero se ejecuta para confirmar el despliegue es técnicamente sonido mientras que el segundo se ejecuta para confirmar tanto la aplicación desplegada, así como cualquier otra aplicación tocado durante el despliegue se sigue trabajando correctamente.

Hay mucho más que la transición de un producto de software para la producción. Lo anterior, sin embargo, es lo mínimo que se necesita para asegurar que el trabajo duro puesto en el desarrollo y en la prueba del producto de software no se pierden por falta de atención a la migración adecuada en manos de negocio.

05 Verificación de aplicaciones web 5.1 Características de un proceso de pruebas 5.2 Tipos de pruebas 5.2.1 Funcionales 5.2.2 Estructurales 5.2.3 De integración con sistemas externos 5.2.4 Usabilidad y accesibilidad 5.2.5 De detección de errores. Pruebas de caja negra 5.2.6 De seguridad. Evaluación de la protección frente a los ataques más comunes 5.2.7 De rendimiento. Pruebas de carga o estrés. Estadísticas 5.2.8 De integridad de datos 5.3 Diseño y planificación de pruebas. Estrategias de uso común 5.4 Consideraciones de confidencialidad. Pruebas con datos personales 5.5 Automatización de pruebas. Herramientas

148

Unidad didáctica 5. Verificación de aplicaciones web

5.VERIFICACIÓN DE APLICACIONES WEB Cuando un programa se implementa para proporcionar una representación concreta de un algoritmo, los desarrolladores de este programa están, naturalmente, preocupados por la corrección y el rendimiento de la aplicación. Los ingenieros de software deben garantizar que sus sistemas de software alcancen un nivel adecuado de calidad. La verificación de software es el proceso de garantizar que un programa cumple con su especificación deseada.

Una técnica que puede ayudar en la especificación, diseño e implementación de un sistema de software es la verificación de software a través de prueba de la corrección. Las pruebas de software, o el proceso de evaluación de la funcionalidad y corrección de un programa a través de la ejecución o el análisis, es otra alternativa para la verificación de un sistema de software. Como señaló Bowen, Hinchley y Geller, las pruebas de software se puede utilizar adecuadamente en conjunto con pruebas de corrección y otros tipos de enfoques formales con el fin de desarrollar sistemas de software de alta calidad. Sin embargo, también es posible utilizar técnicas de pruebas de software en forma aislada de pruebas de corrección de programas u otros métodos formales.

Las pruebas de software no es una “bala de plata” que puede garantizar la producción de sistemas de software de alta calidad. Mientras que una prueba de corrección “correcta” demuestra que un sistema de software (que cumple exactamente su especificación) siempre funcionará correctamente, las pruebas de software dado que no es totalmente exhaustiva sólo puede sugerir la presencia de defectos y no puede demostrar su ausencia. Por otra parte, Kaner et al. han señalado que es imposible probar completamente una aplicación debido a que: (1) el dominio de los insumos del programa es demasiado grande, (2) hay demasiados caminos posibles de entrada, y (3) los problemas de diseño y las especificaciones son difíciles de probar.

El primer y segundo puntos presentan complicaciones evidentes y el punto final, pone de relieve la dificultad de determinar si la especificación de una solución al problema y el diseño de su aplicación también es correcto.

Con el uso de un experimento desarrollado por Beizer, podemos explorar la primera afirmación, asumiendo que tenemos un método que toma una cadena de diez caracteres como entrada y realiza alguna operación arbitraria en la cadena.

Para probar esta función de manera exhaustiva, tendríamos que introducir 140 caracteres y determinar si producen la salida apropiada. La prueba de nuestro método hipotético podría también involucrar el uso de la entrada anómala, como cadenas que consisten en más o menos de diez caracteres, para determinar la

Unidad didáctica 5. Verificación de aplicaciones web

149

solidez de la operación. En esta situación, el número total de entradas sería significativamente mayor que 140. Por lo tanto, podemos concluir que la prueba exhaustiva es un problema irresoluble, ya que es imposible de resolver con un algoritmo de tiempo polinómico.

Las dificultades aludidas por la segunda afirmación se ven agravados por el hecho de que determinadas rutas de ejecución de un programa podría ser inviable. Por último, las pruebas de software es un problema sin solución algorítmica ya que puede haber valores de entrada para las que el programa no se detiene.

Hasta el momento, hemos proporcionado una comprensión intuitiva de las limitaciones de las pruebas de software. Sin embargo, Morell ha propuesto un modelo teórico del proceso de prueba que facilita la demostración de teoremas pesimistas que muestran claramente las limitaciones de las pruebas. Además, Hamlet y Morell han declarado formalmente los objetivos de una metodología de pruebas de software e implícitamente proporcionado una comprensión de las limitaciones de las pruebas. Young y Taylor también han observado que todas las técnicas de pruebas de software debe implicar alguna solución de compromiso entre la precisión y el coste computacional debido a la presencia (o la ausencia) de defectos dentro de un programa es una propiedad indecidible. Las limitaciones teóricas de las pruebas indican claramente que es imposible proponer e implementar una metodología de pruebas de software que es completamente precisa y aplicable a los programas .

Mientras que las pruebas de software se enfrentan sin duda a limitaciones inherentes, también hay un número de consideraciones prácticas que pueden obstaculizar la aplicación de una técnica de prueba. Por ejemplo, algunos lenguajes de programación no pueden soportar fácilmente un enfoque de prueba seleccionado, un marco de automatización de pruebas no puede facilitar fácilmente la ejecución automática de ciertos tipos de conjuntos de pruebas, o podría ser la falta de soporte de herramientas para una prueba específica de criterio de adecuación.

A pesar de cualquier esfuerzo de pruebas se enfrentará a limitaciones esenciales y accidentales significativas, la aplicación rigurosa, coherente e inteligente de las técnicas apropiadas de pruebas de software puede mejorar la calidad de la aplicación en desarrollo.

5.1 Características de un proceso de pruebas.

Hay varias pruebas que se usan para probar un software. Cada prueba tiene sus propias características. Los siguientes puntos, sin embargo, deben tenerse en cuenta.

RECUERDe Las pruebas se centran en comprobar que la aplicación cumple con las especificaciones.

150

Unidad didáctica 5. Verificación de aplicaciones web

RECUERDe Se debe realizar un estudio de las pruebas más adecuadas para cada tipo de implementación.

––Alta probabilidad de detección de errores: Detectar errores máximos, el auditor debe entender el software a fondo y tratar de encontrar las maneras posibles en las que el software puede fallar. En un programa para dividir dos números, por ejemplo, la manera posible en que el programa puede fallar es cuando se dan 2 y cero como entradas y dos se va a dividir por cero. En este caso, un conjunto de pruebas debe ser desarrollado para que pueda demostrar un error en el operador de división.

––Sin redundancia: Los recursos y el tiempo de prueba está limitada en el proceso de desarrollo de software. Por lo tanto, no es beneficioso para el desarrollo de varias pruebas, que tienen la misma finalidad prevista. Cada ensayo deberá tener un propósito distinto.

––Seleccione la prueba más adecuada: No puede haber diferentes pruebas que tienen la misma intención, pero debido a ciertas limitaciones, como el tiempo y la limitación de recursos, sólo unos pocos de ellos se utilizan. En tal caso, se deben considerar las pruebas que tienen la probabilidad más alta de encontrar errores.

––Moderada: Una prueba se considera buena si no es ni demasiado simple ni demasiado compleja. Muchas pruebas se pueden combinar para formar un caso de prueba. Sin embargo, esto puede aumentar la complejidad y dejar muchos errores no detectados. Por lo tanto, todas las pruebas deben realizarse por separado.

Generación de la prueba anticipada tiene varias ventajas: ––Las pruebas generadas independientemente del código, cuando las especificaciones están frescas en la mente de los analistas ––La generación de casos de prueba puede resaltar las inconsistencias y omisiones de las especificaciones correspondientes ––Las pruebas se pueden utilizar como compendio de las especificaciones de los programadores 5.2 Tipos de pruebas 5.2.1 Funcionales.

Las pruebas funcionales verifican que cada función de la aplicación de software opera en conformidad con la especificación de requisitos. Este ensayo se centra principalmente en las pruebas de caja negra y no se preocupa por el código fuente de la aplicación.

Todas y cada una de las funcionalidades del sistema se prueban para proporcionar una contribución apropiada, la verificación de la producción y la comparación de

Unidad didáctica 5. Verificación de aplicaciones web

los resultados reales con los resultados esperados.

Esta prueba requiere la comprobación de la interfaz de usuario, las API, base de datos, seguridad, aplicaciones cliente/ servidor y la funcionalidad de la aplicación en pruebas. La prueba se puede realizar de forma manual o mediante automatización.

Traductor El principal objetivo de las pruebas de función es el control de las funcionalidades del sistema de software. Se concentra principalmente en: ––Funciones RENFE: Prueba de las funciones principales de una aplicación ––Usabilidad básica: Se trata de las pruebas de usabilidad básica del sistema.

Se comprueba si un usuario puede navegar libremente a través de las pantallas sin ninguna dificultad.

––Accesibilidad: Comprueba la accesibilidad del sistema para el usuario ––Condiciones de error: Uso de técnicas de prueba para comprobar las condiciones de error. Comprueba si se muestran los mensajes de error adecuados.

Para probar funcionalmente una aplicación, se deben observar los siguientes pasos: ––Entender los Requisitos ––Identificar entrada de prueba (datos de prueba) ––Calcular los resultados esperados con los valores de entrada de prueba seleccionados ––Ejecutar casos de prueba Hay varias herramientas disponibles en el marcador para realizar pruebas funcionales. Se explican de la siguiente manera: ––Junit: Se utiliza principalmente para aplicaciones Java, lo que puede ser utilizado en la Unidad y las pruebas del sistema ––soapUI: Esta es una herramienta de pruebas funcionales de código abierto, que se utiliza principalmente para las pruebas de servicio Web. Es compatible con varios protocolos HTTP, SOAP y JDBC. ––Watir: Esta es una herramienta de pruebas funcionales para aplicaciones web.

Es compatible con las pruebas realizadas en el navegador web y utiliza el lenguaje scripting ruby.

151

152

Unidad didáctica 5. Verificación de aplicaciones web

Conclusión: Las pruebas funcionales es un proceso que prueba las funcionalidades del sistema y asegura que el sistema está funcionando de acuerdo con las funcionalidades especificadas en el documento de negocios. El objetivo de este ensayo es comprobar si el sistema es funcionalmente perfecto.

5.2.2 Estructurales.

RECUERDe Las pruebas funcionales se centran en comprobar que el software cumple con las especificaciones.

La prueba estructural es la prueba de la estructura del sistema o de un componente.

Las pruebas estructurales se refiere a menudo a las pruebas de “caja blanca” o “caja de cristal” caracterizada en que sólo estamos interesados en cómo el sistema realiza la implementación, en el interior del sistema o aplicación.

––En las pruebas estructurales se requiere que los probadores tengan el conocimiento de las implementaciones internas del código. Aquí los probadores requieren el conocimiento de cómo se ejecuta el software, cómo este funciona.

––Durante las pruebas estructurales del probador se concentra en la forma en que el software lo hace. Por ejemplo, una técnica estructural quiere saber cómo los bucles en el software están trabajando. Los diferentes casos de prueba se pueden derivar de ejercer el bucle una vez, dos veces, o muchas veces. Esto puede realizarse independientemente de la funcionalidad del software.

––Las pruebas estructurales se puede utilizar en todos los niveles y fases de las pruebas. Los desarrolladores utilizan pruebas estructurales en las pruebas de componentes y pruebas de integración de componentes, especialmente cuando existe una buena herramienta de apoyo para la cobertura de código. Las pruebas estructurales también se utiliza en el sistema y las pruebas de aceptación, pero las estructuras son diferentes. Por ejemplo, la cobertura de las opciones de menú o las grandes operaciones de negocio podría ser el elemento estructural en el sistema o pruebas de aceptación.

RECUERDe

5.2.3 De integración con sistemas externos.

Las pruebas estructurales, o de caja blanca, se centran en el cómo el software realiza sus funciones, la lógica del software.

Un neófito del mundo del software podría, una vez que se les ha hecho la prueba de unidad a todos los módulos, cuestionar de forma aparentemente legítima lo siguiente: “Si todos funcionan bien por separado, ¿por qué dudar de que funcionen todos juntos?” Por supuesto, el problema es “ponerlos juntos” (interacción).

Los datos se pueden perder en una interfaz; un módulo puede tener un efecto adverso e inadvertido sobre otro; las subfunciones, cuando se combinan, pueden no producir la función principal deseada; la imprecisión aceptada individualmente puede crecer hasta niveles inaceptables; y las estructuras de datos globales pueden presentar problemas. Desgraciadamente, la lista sigue y sigue.

Unidad didáctica 5. Verificación de aplicaciones web

La prueba de integración es una técnica sistemática para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción. El objetivo es coger los módulos probados mediante la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño.

A menudo hay una tendencia a intentar una integración no incremental; es decir, a construir el programa mediante un enfoque de big bang. Se combinan todos los módulos por anticipado. Se prueba todo el programa en conjunto. Se encuentran un gran conjunto de errores. La corrección se hace difícil, puesto que es complicado aislar las causas al tener delante el programa entero en toda su extensión.

Una vez que se corrigen esos errores aparecen otros nuevos y el proceso continúa en lo que parece ser un ciclo sin fin.

La integración incremental es la antítesis del enfoque del big bang. El programa se construye y se prueba en pequeños segmentos en los que los errores son más fáciles de aislar y de corregir, es más probable que se puedan probar completamente las interfaces y se puede aplicar un enfoque de prueba sistemática.

En las siguientes secciones se tratan varias estrategias de integración incremental diferentes.

La prueba de integración descendente es un planteamiento incremental a la construcción de la estructura de programas. Se integran los módulos moviéndose hacia abajo por la jerarquía de control, comenzando por el módulo de control principal (programa principal). Los módulos subordinados (subordinados de cualquier modo) al módulo de control principal se van incorporando en la estructura, bien de forma primero-en-profundidad, o bien de forma primero-en-anchura.

El proceso de integración se realiza en una serie de cinco pasos: ––Se usa el módulo de control principal como controlador de la prueba, disponiendo de resguardos para todos los módulos directamente subordinados al módulo de control principal.

––Dependiendo del enfoque de integración elegido (es decir, primero-en-profundidad o primero-en-anchura) se van sustituyendo uno a uno los resguardos subordinados por los módulos reales.

––Se llevan a cabo pruebas cada vez que se integra un nuevo módulo.

––Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el módulo real.

––Se hace la prueba de regresión para asegurarse de que no se han introducido errores nuevos.

153

154

Unidad didáctica 5. Verificación de aplicaciones web

El proceso continúa desde el paso 2 hasta que se haya construido la estructura del programa entero.

La estrategia de integración descendente verifica los puntos de decisión o de control principales al principio del proceso de prueba. En una estructura de programa bien fabricado, la toma de decisiones se da en los niveles superiores de la jerarquía y, por tanto, se encuentran antes. Si existen problemas generales de control, es esencial reconocerlos cuanto antes. Si se selecciona la integración primero en profundidad, se puede ir implementando y demostrando las funciones completas del software. Por ejemplo, considere una estructura clásica de transacción en la que se requiere una compleja serie de entradas interactivas, obtenidas y validadas por medio de un camino de entrada. Ese camino de entrada puede ser integrado en forma descendente. Así, se puede demostrar todo el proceso de entradas (para posteriores operaciones de transacción) antes de que se integren otros elementos de la estructura. La demostración anticipada de las posibilidades funcionales es un generador de confianza tanto para el desarrollador como para el cliente.

La estrategia descendente parece relativamente fácil, pero, en la práctica, pueden surgir algunos problemas logísticos. El más común de estos problemas se da cuando se requiere un proceso de los niveles más bajos de la jerarquía para poder probar adecuadamente los niveles superiores. Al principio de la prueba descendente, los módulos de bajo nivel se reemplazan por resguardos; por tanto, no pueden fluir datos significativos hacia arriba por la estructura del programa. El responsable de la prueba tiene tres opciones: ––Retrasar muchas de las pruebas hasta que los resguardos sean reemplazados por los módulos reales; ––Desarrollar resguardos que realicen funciones limitadas que simulen los módulos reales; ––Integrar el software desde el fondo de la jerarquía hacia arriba.

El primer enfoque (retrasar pruebas hasta reemplazar los resguardos por los módulos reales) hace que se pierda cierto control sobre la correspondencia de ciertas pruebas específicas con la incorporación de determinados módulos.

Esto puede dificultar la determinación de las causas del error y tiende a violar la naturaleza altamente restrictiva del enfoque descendente. El segundo enfoque es factible pero puede llevar a un significativo incremento del esfuerzo a medida que los resguardos se hagan más complejos. El tercer enfoque, denominado prueba ascendente, se estudia más adelante.

La prueba de la integración ascendente, como su nombre indica, empieza la construcción y la prueba con los módulos atómicos (es decir, módulos de los niveles

Unidad didáctica 5. Verificación de aplicaciones web

155

más bajos de la estructura del programa). Dado que los módulos se integran de abajo hacia arriba, el proceso requerido de los módulos subordinados siempre está disponible y se elimina la necesidad de resguardos.

Se puede implementar una estrategia de integración ascendente mediante los siguientes pasos: 4. Se combinan los módulos de bajo nivel en grupos (a veces denominados construcciones) que realicen una subfunción específica del software.

5. Se escribe un controlador (un programa de control de la prueba) para coordinar la entrada y la salida de los casos de prueba.

6. Se prueba el grupo.

7. Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la estructura del programa.

PRUEBA DE REGRESIÓN Cada vez que se añade un nuevo módulo como parte de una prueba de integración, el software cambia. Se establecen nuevos caminos de flujo de datos, pueden ocurrir nuevas E/S y se invoca una nueva lógica de control.

Estos cambios pueden causar problemas con funciones que antes trabajaban perfectamente. En el contexto de una estrategia de prueba de integración, la prueba de regresión es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse de que los cambios no han propagado efectos colaterales no deseados.

En un contexto más amplio, las pruebas con éxito (de cualquier tipo) dan como resultado el descubrimiento de errores, y los errores hay que corregirlos. Cuando se corrige el software, se cambia algún aspecto de la configuración del software (el programa, su documentación o los datos que lo soportan). La prueba de regresión es la actividad que ayuda a asegurar que los cambios (debidos a las pruebas o por otros motivos) no introduzcan un comportamiento no deseado o errores adicionales.

La prueba de regresión se puede hacer manualmente, volviendo a realizar un subconjunto de todos los casos de prueba o utilizando herramientas automáticas de reproducción de captura. Las herramientas de reproducción de captura permiten al ingeniero del software capturar casos de prueba y los resultados para la subsiguiente reproducción y comparación. El conjunto de pruebas de regresión (el subconjunto de pruebas a realizar) contiene tres clases diferentes de casos de prueba: ––Una muestra representativa de pruebas que ejercite todas las funciones del software;

RECUERDe Una vez probados los distintos módulos se debe comprobar que al integrarlos sigan cumpliendo con su funcionalidad y se comuniquen bien entre ellos.

156

Unidad didáctica 5. Verificación de aplicaciones web

––Pruebas adicionales que se centran en las funciones del software que se van a ver probablemente afectadas por el cambio; ––Pruebas que se centran en los componentes del software que han cambiado.

A medida que progresa la prueba de integración, el número de pruebas de regresión puede crecer demasiado.

Por tanto, el conjunto de pruebas de regresión debería diseñarse para incluir sólo aquellas pruebas que traten una o más clases de errores en cada una de las funciones principales del programa. No es práctico ni eficiente volver a ejecutar cada prueba de cada función del programa después de un cambio.

Ha habido muchos estudios sobre las ventajas y desventajas de la prueba de integración ascendente frente a la descendente. En general, las ventajas de una estrategia tienden a convertirse en desventajas para la otra estrategia. La principal desventaja del enfoque descendente es la necesidad de resguardos y las dificultades de prueba que pueden estar asociados con ellos. Los problemas asociados con los resguardos pueden quedar compensados por la ventaja de poder probar de antemano las principales funciones de control. La principal desventaja de la integración ascendente es que el programa como entidad no existe hasta que se ha añadido el último módulo. Este inconveniente se resuelve con la mayor facilidad de diseño de casos de prueba y con la falta de resguardos.

La selección de una estrategia de integración depende de las características del software y, a veces, de la planificación del proyecto. En general, el mejor compromiso puede ser un enfoque combinado (a veces denominado prueba sándwich) que use la descendente para los niveles superiores de la estructura del programa, junto con la ascendente para los niveles subordinados.

A medida que progresa la prueba de integración, el responsable de las pruebas debe identificar los módulos críticos. Un módulo crítico es aquel que tiene una o más de las siguientes características:

RECUERDe Tras detectar un fallo y corregirlo, se deben volver a realizar las pruebas que lo detectaron, así como otras “colaterales” para asegurarse de que el fallo no se siga produciendo.

––Está dirigido a varios requisitos del software; ––Tiene un mayor nivel de control (está relativamente alto en la estructura del programa); ––Es complejo o propenso a errores (se puede usar la complejidad ciclomática como indicador); o ––Tiene unos requisitos de rendimiento muy definidos. Los módulos críticos deben probarse lo antes posible. Además, las pruebas de regresión se deben centrar en el funcionamiento de los módulos críticos

Unidad didáctica 5. Verificación de aplicaciones web

5.2.4 Usabilidad y accesibilidad.

Las pruebas de usabilidad es una técnica utilizada para evaluar un producto. En la prueba, los usuarios tratarán de completar las tareas típicas, mientras que los observadores ven, escuchan y toman notas.

Su objetivo es identificar los problemas de usabilidad, recoger datos cuantitativos sobre el rendimiento de los participantes (por ejemplo, el tiempo de trabajo, las tasas de error), y determinar la satisfacción del participante con el producto.

Esta técnica permite probar pronto y prueba a menudo. Las pruebas de usabilidad permite que los equipos de diseño y desarrollo a identificar problemas antes de que sean codificados. Cuanto antes se encuentren y resuelvan los problemas, más baratas serán las revisiones.

No precisa de laboratorios formales para hacer las pruebas. Permitiendo hacer pruebas de usabilidad efectiva en cualquiera de estas opciones: ––Un laboratorio fijo que tiene dos o tres habitaciones conectadas equipado con un equipo audiovisual.

––Una sala de conferencias, o en el hogar o espacio de trabajo del usuario, con el equipo de grabación portátil.

––Una sala de conferencias, o en el hogar o espacio de trabajo del usuario, sin ningún equipo de grabación, siempre y cuando alguien está observando el usuario y tomar notas.

––Remota, con el usuario en una ubicación diferente.

Con este tipo de pruebas se aprenderá si los participantes son capaces de completar las tareas de rutina identificados con éxito y cuánto tiempo se tarda en hacer esto. Se descubrirá cuánto los participantes están satisfechos con su sitio Web. En general, se identificarán los cambios necesarios para mejorar el rendimiento del usuario. Así mismo se puede igualar el rendimiento para ver si cumple con sus objetivos de usabilidad.

Hay muchas herramientas de software sofisticadas que se pueden utilizar para comprobar la accesibilidad web. Las agencias y corporaciones federales de Estados Unidos están gastando millones de dólares en este tipo de herramientas que pretenden probar sitios web de accesibilidad. Se debe estudiar lo que se puede y no se puede probar con estas herramientas.

Cualquier revisión de la accesibilidad debe ser vista como un proceso que combina herramientas de software automatizado con el juicio humano. No existe una herramienta que se puede ejecutar en su sitio web (o una página web para

157

158

Unidad didáctica 5. Verificación de aplicaciones web

RECUERDe El éxito de estas pruebas se basa en la prontitud en que se detecten fallos en el sistema.

el caso) con el fin de afirmar que es accesible y/ o cumple con las disposiciones de la Sección 508 o las Directrices de Accesibilidad para el Contenido Web, por mucho que se esté dispuesto a pagar.

5.2.5 De detección de errores. Pruebas de caja negra.

Pruebas de caja negra, también llamado pruebas funcionales y pruebas de comportamiento, se centra en determinar si un programa hace lo que se supone que debe hacer en base a sus requerimientos funcionales. Las pruebas de caja negra intentan encontrar errores en el comportamiento externo del código en las siguientes categorías: ––incorrectitud o falta de funcionalidad; ––errores de la interfaz; ––errores en las estructuras de datos utilizadas por interfaces; ––comportamiento o errores de funcionamiento, e ––inicialización y terminación errores.

A través de esta prueba, se puede determinar si las funciones parecen funcionar adecuadamente.

Sin embargo, es importante tener en cuenta que por muchas pruebas que se hagan, no se podrá demostrar de forma inequívoca la ausencia de errores y defectos en el código.

RECUERDe Las pruebas de caja negra se centran en probar que las entradas producen las salidas esperadas, sin centrarse en cómo el sistema las produce.

Lo mejor es que la persona que planifica y ejecuta las pruebas de caja negra no sea el programador del código y no sepa nada acerca de la estructura del código.

El programador del código es innatamente parcial y es probable que se centre en probar que el programa hace lo que ha hecho que haga. Lo que se necesita son pruebas para asegurarse de que el programa hace lo que el cliente quiere que haga. Como resultado, la mayoría de las organizaciones tienen grupos de pruebas independientes para llevar a cabo las pruebas de caja negra. Estos probadores no son los desarrolladores y se conocen como probadores de terceros a menudo.

Probadores sólo deben ser capaces de entender y especificar lo que la salida deseada debe ser para una entrada dada en el programa.

Pruebas de Caja Negra

Unidad didáctica 5. Verificación de aplicaciones web

5.2.6 De seguridad. Evaluación de la protección frente a los ataques más comunes.

Cualquier sistema basado en ordenadores que maneje información sensible o lleve a cabo acciones que puedan perjudicar o beneficiar impropiamente a las personas es un posible objetivo para entradas impropias o ilegales al sistema. Este acceso al sistema incluye un amplio rango de actividades: piratas informáticos que intentan entrar en los sistemas por hobbie, empleados disgustados que intentan penetrar por venganza e individuos deshonestos que intentan penetrar para obtener ganancias personales ilícitas.

La prueba de seguridad intenta verificar que los mecanismos de protección incorporados en el sistema lo protegerán, de hecho, de accesos impropios. Por citar a Beizer: «Por supuesto, la seguridad del sistema debe ser probada en su invulnerabilidad frente a un ataque frontal, pero también debe probarse en su invulnerabilidad a ataques por los flancos o por la retaguardia.»

Durante la prueba de seguridad, el responsable de la prueba desempeña el papel de un individuo que desea entrar en el sistema. Debe intentar conseguir las claves de acceso por cualquier medio, puede atacar al sistema con software a medida, diseñado para romper cualquier defensa que se haya construido, debe bloquear el sistema, negando así el servicio a otras personas, debe producir a propósito errores del sistema, intentando acceder durante la recuperación o debe curiosear en los datos sin protección, intentando encontrar la clave de acceso al sistema, etc.

Con tiempo y recursos suficientes, una buena prueba de seguridad terminará por acceder al sistema. El papel del diseñador del sistema es hacer que el coste de la entrada ilegal sea mayor que el valor de la información obtenida.

5.2.7 De rendimiento. Pruebas de carga o estrés. Estadísticas.

Para sistemas de tiempo real y sistemas empotrados, es inaceptable el software que proporciona las funciones requeridas pero no se ajusta a los requisitos de rendimiento. La prueba de rendimiento está diseñada para probar el rendimiento del software en tiempo de ejecución dentro del contexto de un sistema integrado.

La prueba de rendimiento se da durante todos los pasos del proceso de la prueba. Incluso al nivel de unidad, se debe asegurar el rendimiento de los módulos individuales a medida que se llevan a cabo las pruebas de caja blanca. Sin embargo, hasta que no están completamente integrados todos los elementos, no se puede asegurar realmente el rendimiento del sistema.

Las pruebas de rendimiento, a menudo, van emparejadas con las pruebas de resistencia y, frecuentemente, requieren instrumentación tanto de software como

RECUERDe Las pruebas deben también ocupar el tema de la seguridad. Para sistemas críticos y con datos sensibles este punto es especialmente importante.

159

160

Unidad didáctica 5. Verificación de aplicaciones web

de hardware. Es decir, muchas veces es necesario medir la utilización de recursos (por ejemplo, ciclos de procesador), de un modo exacto. La instrumentación externa puede monitorizar los intervalos de ejecución, los sucesos ocurridos (por ejemplo, interrupciones) y muestras de los estados de la máquina en un funcionamiento normal. Instrumentando un sistema, el encargado de la prueba puede descubrir situaciones que lleven a degradaciones y posibles fallos del sistema.

Durante los pasos de prueba anteriores, las técnicas de caja blanca y de caja negra daban como resultado la evaluación del funcionamiento y del rendimiento normales del programa. Las pruebas de resistencia están diseñadas para enfrentar a los programas con situaciones anormales. En esencia, el sujeto que realiza la prueba de resistencia se pregunta: «A qué potencia puedo ponerlo a funcionar antes de que falle?»

La prueba de resistencia ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volúmenes anormales.

RECUERDe Las pruebas de carga son de vital importancia en las aplicaciones web, para prever el comportamiento de las aplicaciones ante posibles saturaciones producidas por sobrecarga.

Por ejemplo: ––Diseñar pruebas especiales que generen diez interrupciones por segundo, cuando las normales son una o dos; ––Incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar cómo responden las funciones de entrada; ––Ejecutar casos de prueba que requieran el máximo de memoria o de otros recursos; ––Diseñar casos de prueba que puedan dar problemas en un sistema operativo virtual; ––Diseñar casos de prueba que produzcan excesivas búsquedas de datos residentes en disco. Esencialmente, el responsable de la prueba intenta romper el programa.

Una variante de la prueba de resistencia es una técnica denominada prueba de sensibilidad. En algunas situaciones (la más común se da con algoritmos matemáticos), un rango de datos muy pequeño dentro de los límites de una entrada válida para un programa puede producir un proceso exagerado e incluso erróneo o una profunda degradación del rendimiento. Esta situación es análoga a una singularidad en una función matemática. La prueba de sensibilidad intenta descubrir combinaciones de datos dentro de una clase de entrada válida que pueda producir inestabilidad o un proceso incorrecto.

5.2.8 De integridad de datos.

La integridad de datos se refiere a la calidad de los datos en bases de datos y es la medida por la cual los usuarios examinar la calidad de datos, fiabilidad y utilidad.

Las pruebas de integridad de datos verifica que los datos convertidos son exac-

Unidad didáctica 5. Verificación de aplicaciones web

161

tos y funciones correctamente dentro de una aplicación dada.

La prueba de integridad de los datos consiste en: –– Asegurar la compatibilidad de los datos con hardware antiguo, las viejas versiones de los sistemas operativos, los datos antiguos y con diferentes interfaces; ––Verificar si se puede recuperar un valor en blanco de los datos; ––Verificar que los valores por defecto se guardan en bases de datos; ––Verificar que cada valor de un único conjunto de datos está totalmente guardado en la base de datos; ––Asegurarse de que los datos de las tablas de datos se pueden modificar y borrar; ––Pruebas de servicio de datos de todos los archivos de datos, incluyendo imágenes prediseñadas, tutoriales, plantillas, etc.

Las pruebas de integridad de los datos es la única manera de asegurarse de que los datos almacenados son exactos, completos y consistentes. Las pruebas de calidad de los datos se debe ejecutar de forma regular debido a que se debe realizar una copia de seguridad y a que los datos almacenados pueden cambiar con el tiempo.

Por lo general, los servicios de entrada de datos se centran más en los entregables, tales como son el análisis de datos, las especificaciones técnicas y la conversión de datos que lo hacen en las pruebas de datos. Esto dependerá de los recursos destinados a las pruebas.

Existen una serie de herramientas automatizadas para las pruebas de integridad de datos. Las pruebas automatizadas de verificación de datos son muy útiles cuando los análisis de datos han de ejecutarse varias veces debido a las tareas de verificación manuales, un proceso que puede ser muy lento y tedioso para los empleados de la entrada de datos. Además, las pruebas automáticas de verificación de datos se pueden llevarse a cabo simultáneamente, en máquinas diferentes, mientras que las pruebas manuales se deben ejecutar secuencialmente. Sin embargo, las pruebas de calidad de datos manual es menos costoso y permite a los usuarios realizar pruebas de datos aleatorios, lo que aumenta las probabilidades de encontrar los errores reales de los usuarios.

5.3 Diseño y planificación de pruebas. Estrategias de uso común.

Una estrategia para las pruebas de software integra los métodos de diseño de casos de prueba de software en una serie bien planificada de pasos que conducen a la construcción exitosa de software. Una estrategia de pruebas de software

RECUERDe La integridad de los datos asegura que no se produzcan salidas erróneas, por lo que se debe asegurar.

162

Unidad didáctica 5. Verificación de aplicaciones web

proporciona una hoja de ruta para el desarrollo de software, la organización de control de calidad, y al cliente una hoja de ruta que describe los pasos que se realizarán como parte de la prueba, cuando se planean estos pasos y cómo se llevaron a cabo, y cuánto esfuerzo tiempo y recursos se requerirá. Por tanto, cualquier estrategia de ensayo debe incorporar la planificación de controles, diseño de casos de prueba, ejecución de la prueba, y la recopilación y evaluación de datos resultante.

Una estrategia de pruebas de software debe ser lo suficientemente flexible como para promover la creatividad y la personalización, que son necesarios para probar adecuadamente todos los grandes sistemas basados en software. Al mismo tiempo, la estrategia debe ser lo suficientemente rígida para promover la planificación razonable y el seguimiento de la gestión a medida que avanza el proyecto.

Teniendo en cuenta el proceso desde el punto de vista del procedimiento de prueba en el contexto de la ingeniería de software es una serie de cuatro pasos que se implementan de forma secuencial.

Los pasos de prueba se centran en cada módulo individualmente, asegurando que funciona como una unidad de ahí el nombre de unidad de prueba. Prueba de la unidad hace uso intensivo de técnicas de pruebas de caja blanca, en ejercicio de rutas específicas en la estructura de control de un módulo para garantizar la cobertura y la detección de errores máximo. A continuación, los módulos deben ser montados o integrados para formar el paquete de software completo.

Las pruebas de integración se ocupa de las cuestiones relacionadas con el doble problema de la verificación y de la construcción del programa. Las técnicas de diseño de casos de prueba de recuadro negro son más frecuentes durante la integración, a pesar de una cantidad limitada de pruebas de caja blanca se puede utilizar para asegurar la cobertura de las principales rutas de control. Después de que el software ha sido integrado (construido), se llevan a cabo juegos de prueba de alto orden. Los criterios de validación (establecidos durante el análisis de requisitos) deben ser probados. Las pruebas de validación proporcionan una garantía final de que el software necesita todos los requisitos funcionales, de comportamiento y rendimiento. Las técnicas de pruebas de caja negra se utilizan exclusivamente durante la validación.

A menudo hay una tendencia a tratar de construir el programa con un enfoque de big bang. Todos los módulos se combinan con antelación. El programa completo se prueba como un todo. Se detecta un conjunto de errores. La corrección es difícil porque el aislamiento de las causas es complicado por la gran extensión de todo el programa. Una vez que estos errores se corrigen, aparecen otros y el proceso continúa en un bucle sin fin.

Unidad didáctica 5. Verificación de aplicaciones web

163

La integración de arriba hacia abajo es un enfoque gradual para la producción de la estructura del programa.

Los módulos integrados se mueven hacia abajo a través de la jerarquía de control, comenzando por el módulo de control principal. Los módulos subordinados al módulo de control principal están incluidos en la estructura, ya sea en una primero-profundidad o el primero en amplitud manera. La selección de un camino importante es arbitraria y depende de las características particulares de aplicación.

El proceso de integración se lleva a cabo en una serie de cinco etapas:

RECUERDe

1. El módulo de control principal se utiliza como un conductor de pruebas y los talones están sustituidos para todos los módulos directamente subordinados al módulo de control principal.

2. Dependiendo de la técnica de integración elegido, los talones de subordinadas se sustituyen a la vez con los módulos reales.

3. Las pruebas se llevaron a cabo como se integra cada módulo.

4. En la finalización de cada grupo de pruebas, otro trozo se sustituye con el módulo real.

5. Las pruebas de regresión se puede realizar para asegurarse de que se han introducido nuevos errores.

El diseño de la estrategia a seguir para las pruebas es base para la optimización de las mismas.

Elección de una estrategia Las estrategias funcionales requieren más planificación ––Estrategias estructurales (de abajo hacia arriba, de arriba hacia abajo, sándwich) son más simples ––Sin embargo, hilo y probar los módulos críticos proporcionan una mejor visibilidad del proceso, sobre todo en sistemas complejos ––Posibilidad de combinar de arriba hacia abajo, de abajo hacia arriba, o un sándwich son razonables para los componentes relativamente pequeños y subsistemas ––Combinaciones de hilo y pruebas de integración de los módulos críticos a menudo se prefiere para los subsistemas más grandes Especificar los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas. Aunque el objetivo principal de la prueba es encontrar errores, una buena estrategia de prueba también evalúa otras características de la calidad, tales como la portabilidad, facilidad de mantenimiento y facilidad de uso. Todo esto debería especificarse de manera que sea medible para que los resultados de la prueba no sean ambiguos.

164

Unidad didáctica 5. Verificación de aplicaciones web

Se deben establecer los objetivos de la prueba de manera explícita. Se deberían establecer en términos medibles los objetivos específicos de la prueba. Por ejemplo, la efectividad de la prueba, la cobertura de la prueba, tiempo medio de fallo, el coste para encontrar y arreglar errores, densidad de fallos remanente o frecuencia de ocurrencia, y horas de trabajo por prueba de regresión deberían establecerse dentro de la planificación de la prueba.

Se debe comprender qué usuarios van a manejar el software y desarrollar un perfil para cada categoría de usuario. Se deben usar casos que describan el escenario de interacción para cada clase de usuario pudiendo reducir el esfuerzo general de prueba concentrando la prueba en el empleo real del producto.

Desarrollar un plan de prueba que haga hincapié en la prueba de ciclo rápido. Gilb recomienda que un equipo de ingeniería del software aprenda a probar en ciclos rápidos (2 por 100 del esfuerzo del proyecto) de incrementos de funcionalidad y/o mejora de la calidad útil para el cliente, y que se puedan probar sobre el terreno. La realimentación generada por estas pruebas de ciclo rápido puede usarse para controlar los niveles de calidad y las correspondientes estrategias de prueba.

Construir un software robusto diseñado para probarse a sí mismo. El software debería diseñarse de manera que use técnicas de depuración anteriores. Es decir, el software debería ser capaz de diagnosticar ciertas clases de errores.Además, el diseño debería incluir pruebas automatizadas y pruebas de regresión.

Usar revisiones técnicas formales efectivas como filtro antes de la prueba. Las revisiones técnicas formales pueden ser tan efectivas como las pruebas en el descubrimiento de errores.

Por este motivo, las revisiones pueden reducir la cantidad de esfuerzo de prueba necesaria para producir software de alta calidad.

Se deben realizar revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba. Las revisiones técnicas formales pueden descubrir inconsistencias, omisiones y errores claros en el enfoque de la prueba. Esto ahorra tiempo y también mejora la calidad del producto.

RECUERDe Los datos sensibles han de ser ocultados a los desarrolladores, por política de empresa, así como por legalidad.

Desarrollar un enfoque de mejora continua al proceso de prueba. Debería medirse la estrategia de prueba. Las métricas agrupadas durante la prueba deberían usarse como parte de un enfoque estadístico de control del proceso para la prueba del software.

Unidad didáctica 5. Verificación de aplicaciones web

5.5 Automatización de pruebas. Herramientas En las pruebas de software, la automatización de pruebas es el uso de un software especial (separado del software que está siendo probado) para controlar la ejecución de las pruebas y la comparación de los resultados reales con los resultados predichos. La automatización de pruebas puede automatizar la prueba repetitiva pero necesaria, anterior en un proceso de prueba formalizado ya en el lugar, o añadir pruebas adicionales que sería difícil de realizar manualmente.

Algunas de las tareas de pruebas de software, tales como pruebas de regresión interfaz de bajo nivel extensa, puede ser laborioso y el tiempo para hacerlo de forma manual. Además, un enfoque manual no podría siempre ser eficaz en la búsqueda de ciertas clases de defectos. La automatización de pruebas ofrece una posibilidad para llevar a cabo estos tipos de pruebas de eficacia. Una vez que las pruebas han sido automatizadas, se pueden ejecutar de forma rápida y repetidamente. Muchas veces, esto puede ser un método rentable para las pruebas de regresión de los productos de software que tienen una larga vida sin mantenimiento. Incluso los parches menores durante la vida útil de la aplicación pueden causar características de ruptura que trabajan en un punto anterior en el tiempo.

Hay dos enfoques generales para la automatización de la prueba: ––Código impulsado por las pruebas. Los interfaces públicos a las clases, módulos o bibliotecas se prueban con una variedad de argumentos de entrada para confirmar que los resultados devueltos son correctos.

––Pruebas de la interfaz gráfica de usuario. Un marco de pruebas genera eventos de interfaz de usuario, como las pulsaciones de teclado y los clics del ratón, y observa los cambios que resultan en la interfaz de usuario, para validar que el comportamiento observable de que el programa es correcto.

Las herramientas de automatización de pruebas pueden ser costosas, y por lo general se emplean en combinación con la prueba manual. La automatización de pruebas se puede hacer rentable a largo plazo, especialmente cuando se utiliza en varias ocasiones en las pruebas de regresión.

En las pruebas automatizadas el ingeniero de pruebas de software o la persona de control de calidad deben tener la capacidad de codificación de software, ya que los casos de prueba se escriben en forma de código fuente que, cuando se ejecuta, produce una salida de acuerdo con las afirmaciones que forman parte de ella.

Una forma de generar casos de prueba automáticamente se basa en modelos mediante el uso de un modelo de sistema para la generación de casos de prueba, pero la investigación continúa en una variedad de metodologías alternativas para hacerlo. En algunos casos, el enfoque basado en modelos permite a los usuarios

165

166

Unidad didáctica 5. Verificación de aplicaciones web

no técnicos crear casos de prueba automatizados en inglés sencillo, de manera que no es necesaria la programación de ningún tipo con el fin de configurarlos para múltiples sistemas operativos, navegadores y dispositivos inteligentes.

Lo que hay que automatizar es si uno realmente se necesita, se toman las decisiones cruciales que las pruebas (o desarrollo) del equipo debe hacer. La selección de las características correctas del producto para la automatización determina en gran medida el éxito de la automatización. Deben evitarse automatizaciones características inestables o características que están experimentando cambios.

Muchas de las herramientas de automatización de pruebas proporcionan funciones de grabación y reproducción que permiten a los usuarios grabar interactivamente acciones de los usuarios y reproducir de nuevo las veces necesarias y comparar los resultados reales con los esperados. La ventaja de este enfoque es que se requiere poco o ningún desarrollo de software. Este enfoque se puede aplicar a cualquier aplicación que tenga una interfaz gráfica de usuario. Sin embargo, la dependencia de estas características plantea importantes problemas de confiabilidad y mantenibilidad. El re-etiquetado de un botón o mover a otra parte de la ventana puede requerir la prueba para volver a grabar. La grabación y reproducción también se añaden a menudo actividades irrelevantes o registra incorrectamente algunas actividades.

Una variación de este tipo de herramienta es para la prueba de los sitios web.

Aquí, el interfaz es la página web. Este tipo de herramienta también requiere poco o ningún desarrollo de software. Sin embargo, dicho marco utiliza totalmente diferentes técnicas, ya que es la lectura de HTML en vez de observar eventos de ventana.

RECUERDe No en todos los entornos se permite el uso de herramientas para la automatización de pruebas. Es sólo una posibilidad más que permitirá, en caso de que sea posible, ahorrar en costes temporales y de recursos.

Otra variación es la automatización de pruebas sin scripts que no utiliza grabación y reproducción, pero en su lugar se construye un modelo de la solicitud en virtud de prueba (AUT) y luego permite que el probador cree casos de prueba simplemente editando en los parámetros y condiciones de ensayo. Esto no requiere de habilidades de scripting, pero tiene todo el poder y la flexibilidad de un enfoque con guión. El mantenimiento de prueba de los casos parece ser fácil, ya que no existe un código a mantener y que los cambios AUT los objetos de software sólo se puede volver a añadirlas. Se puede aplicar a cualquier aplicación de software basada en GUI. El problema es el modelo de la AUT se implementa realmente usando scripts de prueba, que tiene que ser constantemente mantenido cada vez que hay cambio en la AUT.

06 Control de versiones 6.1 Definición 6.2 Características generales 6.3 Tipos de control de versiones 6.3.1 Centralizados 6.3.2 Distribuidos 6.4 Mecanismos de control de versiones 6.4.1 Repositorios. Gestión y administración 6.4.2 Publicación de cambios («check-in» o «commit»).

Operaciones atómicas 6.4.3 Tipos de desprotección, despliegue o «check-out»: exclusivos y colaborativos 6.4.4 Ramificaciones («branching»)

6.4.5 Fusiones («merging») 6.4.6 Etiquetado («tagging») 6.4.7 Líneas de base («baseline») 6.4.8 Actualizaciones 6.4.9 Congelaciones 6.4.10– Gestión de conflictos 6.5 Buenas prácticas en control de versiones 6.6 Herramientas de control de versiones de uso común 6.6.1 Características 6.6.2 Comparativa 6.7 Integración del control de versiones en herramientas de uso común

168

Unidad didáctica 6. CONTROL DE VERSIONES

6. CONTROL DE VERSIONES 6.1 Definición Un sistema de control de versiones (o sistema de control de revisiones) es una combinación de tecnologías y prácticas para el seguimiento y el control de cambios en los archivos de un proyecto, en particular, el código fuente, documentación y páginas web. En estos días, todo el mundo espera que al menos el código fuente de su proyecto esté bajo el control de versiones, y probablemente no va a tomar en serio el proyecto si no utiliza el control de versiones.

El control de versiones es tan universal que ayuda a prácticamente todos los aspectos de la ejecución de un proyecto: la comunicación entre desarrolladores, la gestión de la liberación, la gestión de error, código de estabilidad y los esfuerzos de desarrollo experimental, y la atribución y autorización de los cambios por los desarrolladores particulares. El sistema de control de versiones proporciona una fuerza central de coordinación entre todas estas áreas. El núcleo del sistema es la gestión del cambio: la identificación de cada cambio discreto hecho en los archivos del proyecto, anotar cada cambio con metadatos como la fecha y el autor del cambio, y luego disponer esta información a quien lo solicite, en la forma que piden. Se trata de un mecanismo de comunicaciones donde un cambio es la unidad básica de información.

Esta sección no trata todos los aspectos de la utilización de un sistema de control de versiones. Aquí nos concentraremos en la selección y configuración de un sistema de control de versiones de una manera que fomente el desarrollo cooperativo en el futuro.

En este tema no se puede explicar cómo usar el control de versiones, sin conocer algunos términos clave. Estos términos son útiles independientemente de cualquier sistema de control de versión particular: son los sustantivos y los verbos básicos de la colaboración en red. Incluso si no hay sistemas de control de versiones en el mundo, el problema de la gestión del cambio se mantendría, y estas palabras nos dan un lenguaje para hablar de ese problema de forma concisa.

Mensaje de registro (log) Un pequeño comentario añadido a cada commit que describe la naturaleza y propósito de la confirmación. Los mensajes de registro se encuentran entre los documentos más importantes en cualquier proyecto: son el puente entre el lenguaje altamente técnico de cambios en el código de las personas y el lenguaje más orientado al usuario de características, correcciones de errores y el progreso del proyecto. Más adelante en esta sección, vamos a ver formas de distribuir mensajes de registro a las audiencias adecuadas.

Unidad didáctica 6. CONTROL DE VERSIONES

Actualizar Para hacer que los cambios de los demás (commits), se incorporen en su copia local del proyecto, esto es, para hacer su copia “up-to-date”. Esta es una operación muy común ya que la mayoría de los desarrolladores de actualizan su código varias veces al día, por lo que saben que están corriendo más o menos lo mismo que los otros desarrolladores que están ejecutando, por lo que si ven un error, se puede bastante seguro de que todavía no se haya fijado.

Casilla El proceso de obtención de una copia del proyecto de un repositorio. A la salida por lo general produce un árbol de directorios llamado “copia de trabajo” (ver más abajo), de la que los cambios pueden ser enviados de vuelta al depósito inicial. En algunos sistemas de control de versiones descentralizados, cada copia de trabajo es en sí mismo un repositorio, y los cambios pueden ser expulsados (o atraídos) a cualquier repositorio que esté dispuesto a aceptarlos.

Copia de trabajo Árbol del directorio privado que contiene los archivos del proyecto de código fuente, y posiblemente sus páginas web u otros documentos. Una copia de trabajo también contiene metadatos administrados por el sistema de control de versiones, diciendo a la copia de trabajo lo repositorio contiene, lo que contienen las “revisiones” (ver abajo) de los archivos que están presentes, et. Por lo general, cada desarrollador tiene su propia copia de trabajo, en el que hace y pone a prueba los cambios, y de la que confía.

Revisión, cambio Una revisión suele ser una encarnación específica de un archivo o directorio en particular. Por ejemplo, si el proyecto se inicia con la versión 6 del archivo F, y luego alguien hace un cambio a la F, lo que produce la revisión 7 de F. Algunos sistemas también utilizan “revisión”, “cambiar”, o “el conjunto de cambios” para referirse a un conjunto de cambios cometidos juntos como una unidad conceptual.

Estos conceptos pueden tener distintos significados técnicos en los diferentes sistemas de control de versiones, pero la idea general es siempre el mismo: dan una manera de hablar sobre los puntos exactos en el tiempo en la historia de un archivo o un conjunto de archivos (por ejemplo, inmediatamente antes y después de un error se corrige). Por ejemplo: “Se solucionó en la revisión 10” o “Se fija en la revisión 10 de program.c.”

Cuando se habla de un archivo o conjunto de archivos sin especificar una revisión en concreto, en general se asume que nos referimos a la revisión más reciente(s) disponible.

Diff Una representación textual de un cambio. Un diff muestra que se cambiaron las líneas y la forma, además de unas pocas líneas de contexto que rodea a cada lado.

169

170

Unidad didáctica 6. CONTROL DE VERSIONES

Un desarrollador que ya está familiarizado con el código puede, leer un diff contra ese código y entender lo que hizo el cambio, e incluso detectar fallos.

Rama Una copia del proyecto, bajo control de versiones, pero aislado, por lo que los cambios realizados a la rama no afectan al resto del proyecto, y viceversa, excepto cuando los cambios son deliberadamente fusionados de un lado al otro (véase más adelante). Las ramas también son conocidas como líneas de desarrollo. Incluso cuando un proyecto no tiene ramas específicas de desarrollo está siendo considerado como sucede en la rama principal, también conocida como la “línea principal” o “troncal”.

Las ramas ofrecen una manera de aislar diferentes líneas de desarrollo de las otras. Por ejemplo, una rama se puede utilizar para el desarrollo experimental, que sería demasiado inestable para la rama principal. O a la inversa, una rama puede ser utilizada como un lugar para estabilizar una nueva versión. Durante el proceso de liberación, el desarrollo normal continuará ininterrumpidamente en la rama principal del repositorio, mientras tanto, en la rama de lanzamiento, no se admitirán cambios salvo los aprobados por los administradores de la versión. De esta manera, una versión no tiene por qué interferir en el trabajo de desarrollo en curso.

Erge (puerto alias) Para mover un cambio de una rama a otra. Esto incluye la fusión de la rama principal a otra rama, o viceversa. De hecho, esos son los tipos más comunes de las fusiones, es poco frecuente portar un cambio entre dos ramas que no sean principales.

RECUERDe Un sistema de control de versiones permitirá controlar la evolución del software, así como volver atrás en caso de versiones inestables, olvidándose de las técnicas de fuerza bruta.

Bloquear A manera de declarar la intención exclusiva de cambiar un archivo o directorio en particular. Por ejemplo, “No puedo confirmar ningún cambio a las páginas web en este momento. Parece que Jose las tiene bloqueadas mientras arregla sus imágenes de fondo.” No todos los sistemas de control de versiones ofrecen la capacidad de bloquear, y de los que lo hacen, no todos requieren la función de bloqueo para ser utilizado. Esto se debe a que, el desarrollo simultáneo en paralelo es la norma, y encerrar a la gente de los archivos esta (normalmente) en contra de este ideal.

Los sistemas de control de versiones que requieren de bloqueo para el que se compromete, se suele utilizar el modelo de bloqueo-modificación-desbloqueo.

Aquellos que no se dice que usar, se suele utilizar la opción-modificar-mezclar copia del modelo. En general, el modelo copiar-modificar-mezclar es mejor para el desarrollo de código abierto, y todos los sistemas de control de versiones discutidos en este tema soportan este modelo.

Unidad didáctica 6. CONTROL DE VERSIONES

6.2 Características generales Seguimiento de versiones Los desarrolladores pueden desear comparar la versión actual de algún tipo de software con la versión anterior o con otra versión más antigua. Dado que los sistemas de control de versiones no pierden de vista todas las versiones del software, esto se convierte en una tarea sencilla. Saber el qué, el quién y el cuándo de los cambios ayudarán a comparar el rendimiento de determinadas versiones. Los problemas que surgen a partir de un cambio pueden ir seguidas de un examen de quién hizo el cambio y las razones que dieron para realizar el cambio.

Equipos de Coordinación El desarrollo de los recursos se lleva a cabo habitualmente por equipos, o bien permiten ubicarse de forma distribuida. El control de versiones es central para la coordinación de los equipos de colaboradores. Permite un trabajo colaborador en una copia de los recursos y libera sus retornos a versiones anteriores. Otros colaboradores trabajan en sus propias copias de los mismos recursos al mismo tiempo, no afectadas por los cambios del otro hasta que decidan fusionarse o confirmar sus cambios de vuelta al proyecto. Los conflictos que surgen cuando dos contribuyentes cambian independientemente el mismo parte de un recurso, provocando que se puedan combinan los cambios. Tales conflictos pueden ser manejados por los contribuyentes y por el propio programa de control de versiones, que deberá realizar una copia por cada contribuyente.

Normalmente, en los proyectos de código abierto, los sistemas de control de versiones permiten que cualquiera pueda leer y copiar los recursos de los proyectos, pero sólo a los usuarios autenticados, conocidos como committers se les permite actualizar el código fuente en el repositorio.

Due Diligence Muchas de las actividades en los negocios van acompañados de una responsabilidad para realizar comprobaciones de ‘due diligence’. Es precisamente lo que estos controles prevén dependerá de la actividad de que se trate, pero en lo que respecta a la propiedad intelectual de una importante actividad de “diligencia debida” es el seguimiento de la propiedad de sus partes constituyentes. Así, por ejemplo, si alguien crea una pieza de software y desea que su organización para liberarlo, su organización es casi seguro que desee comprobar la procedencia de todo el código en el software. Este proceso se ve facilitado por la capacidad de seguimiento que hizo que los cambios en el código, y cuando lo hicieron. Un sistema de control de versiones permite elaborar una lista de contribuyentes y las fechas de sus contribuciones para ser comprobada. Esta lista puede ser fácilmente cotejará con una lista de los contratos de propiedad intelectual.

171

172

Unidad didáctica 6. CONTROL DE VERSIONES

RECUERDe La comparación de los cambios entre versiones permite comprobar la evolución del software y retomar versiones anteriores en caso de que los cambios no hayan mejorado la funcionalidad introducida en los cambios entre versiones.

El desarrollo abierto implica que muchos contribuyentes hagan pequeños cambios regulares a los recursos. Un sistema de control de versión proporciona un medio para el seguimiento de los cambios que se producen. Los sistemas automatizados notificarán a los responsables de la gestión de la propiedad intelectual todos estos cambios. Estas notificaciones, junto con los registros facilitados por cada modificación individual, permiten a los administradores de proyectos poder monitorear y rastrear todas las contribuciones.

6.3 Tipos de control de versiones 6.3.1 Centralizados Hay dos tipos generales de control de versiones: centralizada y distribuida. Control de la versión distribuida es más moderno, se ejecuta más rápido, es menos propenso a errores, tiene más características, y es algo más complejo de entender. Se debe decidir si la complejidad adicional le merece la pena.

Algunos sistemas de control de versiones populares son Mercurial (distribuido), Git (distribuido) y Subversion (centralizado).

La principal diferencia entre el control de versiones centralizado y distribuido es el número de repositorios. En el control de versiones centralizado hay un solo repositorio, y en el control de versiones distribuido, hay múltiples repositorios.

Los sistemas de control de versiones centralizados están diseñados con la intención de que existe una verdadera fuente que ha sido verificada, y por lo tanto es buena. Todos los desarrolladores de trabajo (compra) de esa fuente a continuación añaden (commit) los cambios, que luego se verifican. La única diferencia real entre CVS, Subversion, ClearCase, por fuerza,VisualSourceSafe y todos los demás CVCSs está en el flujo de trabajo, el rendimiento y la integración que ofrece cada producto.

En el control de versiones centralizado, cada usuario tiene su propia copia de trabajo, pero sólo hay un repositorio central. Para ver los cambios deben suceder dos cosas:

RECUERDe En el control de versiones centralizado hay un solo repositorio.

- Commit - Se actualizan

Unidad didáctica 6. CONTROL DE VERSIONES

6.3.2 Distribuidos El control de versiones distribuidos (DRC) tiene un enfoque peer-to-peer para el control de versiones, en comparación con el enfoque de cliente-servidor de los sistemas centralizados. En lugar de un único repositorio central en el que los clientes sincronicen una copia de trabajo de cada par del código base en un depósito de control de revisiones distribuido que realiza la sincronización mediante el intercambio de parches (conjuntos de cambios) de igual a igual. Esto da lugar a algunas diferencias importantes de un sistema centralizado: ––No canónica: copia de referencia de la base de código existente por defecto, sólo las copias de trabajo.

––Operaciones habituales (tales como confirmaciones, ver el historial, y revertir cambios) son rápidos, porque no hay necesidad de comunicarse con un servidor central.

Más bien, la comunicación sólo es necesaria, cuando se va a empujar o tirar de cambios hacia o desde otros pares.

––Cada copia de trabajo efectivamente funciona como una copia de seguridad remota de la base de código y de su cambio de la historia, proporcionando una protección natural contra la pérdida de datos.

Otras diferencias son las siguientes: ––Puede haber muchos repositorios “centrales”.

––Código de repositorios dispares se fusionan en base a una red de confianza, es decir, el mérito histórico o la calidad de los cambios.

––Numerosos modelos de desarrollo diferentes son posibles, como el desarrollo/ ramas de liberación o un modelo Comandante/ Teniente, lo que permite una delegación eficaz de los acontecimientos de actualidad en proyectos de gran envergadura.

––Tenientes son miembros del proyecto que tienen el poder de decidir de forma dinámica que se ramifica a la combinación de correspondencia.

––La red no está implicada en la mayoría de las operaciones.

––Un grupo separado de las operaciones de “Sync” podrá cometer o recibir cambios con repositorios remotos.

Los autores DVCS señalan varias ventajas de los sistemas de control de versiones distribuidos sobre el modelo centralizado tradicional: ––Permite a los usuarios trabajar de forma productiva, incluso cuando no están conectados a una red

173

174

Unidad didáctica 6. CONTROL DE VERSIONES

––Hace que la mayoría de las operaciones sean mucho más rápidas, ya que no hay ninguna red involucrada ––Permite la participación en los proyectos sin necesidad de permisos de las autoridades del proyecto, y por lo tanto podría decirse que mejora y fomenta la cultura de la meritocracia en lugar de requerir status “confirmador” ––Permite el trabajo privado, por lo que los usuarios pueden utilizar su sistema de control de versiones, incluso para los primeros borradores que no quieren publicar ––Evita depender de una sola máquina física como un único punto de fallo.

––Aún así permite el control centralizado de la “versión” del proyecto ––Para proyectos de software FLOSS, se vuelve mucho más fácil crear un proyecto tenedor que un proyecto que está estancado debido a los conflictos de liderazgo o desacuerdos de diseño.

Desarrollo de software autor Joel Spolsky, el dueño de un DVCS comerciales, describe el control de versiones distribuidos como “posiblemente el mayor avance en la tecnología de desarrollo de software en los últimos diez años.”

Como desventaja de DVCS, se puede notar que la clonación inicial de un depósito es más lento en comparación con la salida centralizada, porque se copian todas las ramas y el historial de revisión. Esto puede ser relevante si la velocidad de acceso es baja y el proyecto es lo suficientemente grande. Por ejemplo, el tamaño del repositorio git clonado (toda la historia, ramas, etiquetas, etc) para el kernel de Linux es de aproximadamente el tamaño del registro de salida HEAD sin comprimir, mientras que la caja equivalente a una sola rama en una caja centralizada ser el tamaño comprimido de los contenidos de la cabeza (excepto sin ninguna historia, ramas, etiquetas, etc). Otro problema con DVCS es la falta de mecanismos de bloqueo que forma parte de VCS más centralizados y sigue desempeñando un papel importante cuando se trata de archivos binarios no mergeable como los activos gráficos.

Un sistema abierto de control de revisiones distribuido se caracteriza por su apoyo a los poderes independientes, y su fuerte dependencia de las operaciones de combinación. Sus características generales son: Cada copia de trabajo es efectivamente un “tenedor”.

––El sistema implementa cada rama como una copia de trabajo, con fusiones realizadas mediante canje parche ordinario, de rama en rama.

––Por lo tanto, si se bifurcan en Código se produce más fácilmente, cuando se desee, ya que cada copia de trabajo es un “tenedor” potencial. (Por la misma razón, los “tenedores” no deseados son más fáciles de reparar ya que, si la disputa se puede resolver, volver a fusionar el código es fácil.)

Unidad didáctica 6. CONTROL DE VERSIONES

––Puede realizar “cherry-picking”, cambios individuales, realizando selectivamente de igual a igual.

––Nuevos compañeros pueden afiliarse libremente, sin necesidad de solicitar el acceso a un servidor.

Uno de los primeros sistemas abiertos, BitKeeper, servido en el desarrollo del kernel de Linux. Cuando los fabricantes de BitKeeper decidieron en 2005 restringir su licencia, Linus Torvalds, en busca de una alternativa libre, finalmente comenzaron a desarrollar su propio software de gestión de control de código fuente distribuido, Git. Para obtener una lista de los sistemas de control de versiones distribuidos, vea la comparación de software de control de versiones.

Un sistema replicado de control de revisiones distribuido depende de una base de datos replicada. El check-in es equivalente a una confirmación distribuida. El éxito consiste en crear una sola línea de base, lo que reduce la necesidad de la fusión.

6.4 Mecanismos de control de versiones 6.4.1 Repositorios. Gestión y administración.

Si se realiza muchos cambios en los paquetes de descarga de código, es fácil perder la noción de lo que se cambió en los archivos, así como recordar lo que se hizo y cuándo. Un repositorio de control de versiones mantiene un registro de estos cambios en los archivos de forma automática, y permite realizar un seguimiento de los cambios en el tiempo y volver a un estado anterior si no te gusta la forma en que va un proyecto.

Consiste en una base de datos en la que se almacenan los cambios. Algunos sistemas de control de versiones son centralizados: hay un único repositorio maestro, que almacena todos los cambios en el proyecto. Otros son descentralizados: cada desarrollador tiene su propio repositorio y los cambios se pueden intercambiar y venir entre repositorios arbitrariamente. El sistema de control de versiones mantiene un registro de las dependencias entre los cambios, y cuando es el momento de hacer un lanzamiento, un conjunto de cambios está aprobado para esa versión.

La cuestión de si centralizada o descentralizada es mejor, es una de las guerras santas perdurables de desarrollo de software; tratar de no caer en la trampa de discutir sobre ello en sus listas de proyectos.

175

RECUERDe El control de versiones distribuido evita la dependencia de una sola máquina, estableciendo un enfoque peer-to-peer.

176

Unidad didáctica 6. CONTROL DE VERSIONES

Teniendo en cuenta la complejidad de la historia de las revisiones es una buena idea para etiquetar revisiones importantes, por ejemplo, cualquier revisión que se utilizó para un lanzamiento o algún hito bien definido.

Examinar el historial de revisión debe tener en cuenta la naturaleza de la historia.

Para cualquier cliente que lo esté utilizando, es necesario crear un nuevo repositorio de control de código fuente. Se tendrá que introducir la URL del repositorio junto con su nombre de usuario y contraseña en el cliente. La URL se suele parecer a https://svn servidor> número> .hostname.com / svn / <repository> (se puede utilizar https:// (SSL) si se tiene una cuenta de pago) Tras hacer clic en la carpeta raíz, hacer clic en el botón Extraer y crear una carpeta de trabajo en el cliente. Ahora se puede agregar archivos a esta carpeta.

Después de comprobar los archivos del proyecto, se pueden editar desde el directorio que ha creado en el equipo local.

Después de editar los archivos, para editarlos, haga clic en el botón Registrar en la barra de herramientas para actualizar los cambios. Puede revisar los cambios y añadir un comentario, lo que ayuda para que pueda recordar lo que estaba trabajando, los cambios realizados, y notificar a otros miembros de su proyecto lo que ha estado haciendo.

RECUERDe El repositorio es la base de datos en la que se almacenan los cambios producidos entre las versiones.

El cliente también debe ser capaz de verificar las revisiones en cualquier momento haciendo clic en el visor de la revisión o el botón de la historia, puede restaurar los cambios anteriores, por cada archivo si es necesario. Una vez concienciado sobre estos conceptos básicos, la documentación proporcionada con cada cliente es un buen punto de partida para las funciones más avanzadas.

6.4.2 Publicación de cambios («check-in» o «commit»). Operaciones atómicas A menudo los usuarios de control de versiones indican que se ha realizado un cambio, lo que significa que se realizan cambios en sus copias de trabajo de archivos y se introdujeron al repositorio.

Para realizar un cambio en el proyecto; más formalmente, para almacenar un cambio en la base de datos de control de versiones de tal manera que se pueda incorporar en futuras versiones del proyecto. “Commit” puede ser utilizado como un verbo o un sustantivo. Como sustantivo, es esencialmente sinónimo de “cambio”. Por ejemplo: “Acabo de enviar una solución para las personas de choque de errores del servidor han estado informando sobre Mac OS X. Jay, ¿podría por favor revisar que no estoy haciendo mal uso del asignador?”

Unidad didáctica 6. CONTROL DE VERSIONES

El registro (check-in) de un archivo o directorio: Esto copia el directorio de trabajo al repositorio como una nueva versión.

Extracción (check-out) de los archivos o directorios: Esta copia la última revisión de un archivo desde el repositorio a su espacio de trabajo. Cuando se echa un vistazo a un directorio, se echa un vistazo a todos los archivos y subdirectorios que hay bajo él.

6.4.3 Tipos de desprotección, despliegue o «check-out»: exclusivos y colaborativos.

177

RECUERDe La adecuada publicación de los cambios se debe realizar de forma coordinada entre todos los programadores, por lo que todos deben usar el procedimiento establecido.

Check-outs de un documento: El check-out archivo permite al usuario editar el archivo. Se crea un bloqueo en el archivo, lo que impide que otros usuarios puedan sobrescribir otros cambios en cada uno. Para editar el documento, se procede a hacer check-out del documento y guardarlo localmente en el escritorio. Una vez que termine de trabajar en un archivo, se puede check-in para hacer una vez más a disposición de otros usuarios. Los usuarios en el área de trabajo se podrá ver la última versión del archivo que se ha facturado.

Check-in de un documento: Al hacer el check-in de un archivo se elimina el bloqueo en el archivo. Después de editar el archivo, puede cargar la última versión del archivo. Cuando se protege un archivo se dispone para otros usuarios en el área de trabajo para posibilitar su edición.

El check-out exclusivo permite a los desarrolladores bloquear un archivo para que nadie más pueda trabajar en él hasta que se terminan los trabajos y procede a liberarlo. Aunque esta característica puede sonar poco intuitiva para los más prácticos, es muy útil para asegurar que los archivos que no se pueden combinar con los cambios de diversos desarrolladores.

El check-out colaborativo permite a varios desarrolladores trabajar sobre un mismo archivo y, a la hora de fusionarlo se realizará un “control de cambios” que identificará los cambios de cada desarrollador, sin que se pierdan cambios de cada colaborador.

6.4.4 Ramificaciones («branching»).

La ramificación, en el control de la revisión y la gestión de configuración de software, es la duplicación de un objeto bajo control de revisión (tales como un archivo de código fuente, o un árbol de directorios), de modo que las modificaciones pueden ocurrir en paralelo a lo largo de las dos ramas.

Las ramas también son conocidas como los árboles, los streams o codelines.

La sucursal de origen a veces se llama la rama principal, la rama ascendente (o,

RECUERDe Se debe establecer el tipo de check-out según las necesidades del proyecto. El exclusivo es adecuado cuando un solo (o pocos) usuarios tocan cada módulo. En el resto de casos se debe realizar un check-out colaborativo.

178

Unidad didáctica 6. CONTROL DE VERSIONES

simplemente, aguas arriba, especialmente si las ramas son mantenidas por las diferentes organizaciones o individuos), o en el flujo de respaldo. Ramas secundarias son ramas que tienen un padre; una rama sin un padre se conoce como el tronco o la línea principal.

En algunos sistemas de control de versiones distribuidos, como Darcs, no hay distinción entre depósitos y sucursales, en estos sistemas, ir a buscar una copia de un repositorio es equivalente a la ramificación.

Una bifurcación general también implica la posibilidad de fusionar o integrar los cambios de nuevo en la rama principal más tarde. A menudo, los cambios se fusionan de nuevo al tronco, incluso si esta no es la rama principal. Una rama no pretende ser fusionados (por ejemplo, porque se ha re-licenciado bajo una licencia incompatible por un tercero, o se intenta servir a un propósito diferente) por lo general se llama un “tenedor” (fork).

RECUERDe El uso de árboles (ramificaciones) en el control de versiones facilita la estructura del versionado.

Las ramas permiten que partes del software se desarrollarán en paralelo. Los grandes proyectos requieren muchos papeles por cubrir, incluyendo desarrolladores, administradores de construcción, y el personal de control de calidad. Además, los múltiples lanzamientos en diferentes plataformas de sistemas operativos pueden tener que ser mantenidos. Las ramas permiten contribuir a aislar cambios sin desestabilizar el código base, permitiendo por ejemplo, correcciones de errores, nuevas características, la integración y versiones. Estos cambios pueden realizarse más tarde, cuando se fusionen (resincronización) después de la prueba.

6.4.5 Fusiones («merging»).

La fusión (también llamada la integración) en el control de revisión, es una operación fundamental que reconcilia múltiples cambios realizados en una colección bajo control de revisiones de archivos. Muy a menudo, se hace necesaria cuando un archivo es modificado por dos personas en dos ordenadores distintos al mismo tiempo. Cuando se fusionan dos ramas, el resultado es una sola colección de archivos que contiene ambos conjuntos de cambios.

En algunos casos, la combinación se puede realizar automáticamente, porque no hay suficiente información de la historia para reconstruir los cambios, y los cambios no entran en conflicto. En otros casos, una persona tiene que decidir exactamente lo que deben contener los archivos resultantes. Muchas de las herramientas de software de control de versiones incluyen capacidades de combinación.

Se refiere pues a la combinación de varios cambios realizados en diferentes copias de trabajo de los mismos archivos en el repositorio de código fuente. La fusión es una estrategia para la gestión de conflictos, dejando que múltiples desarrolladores trabajen a la vez (sin bloqueos de archivos), y luego la incorporación de su trabajo en una versión combinada. La fusión funciona bien cuando se

Unidad didáctica 6. CONTROL DE VERSIONES

179

realizan dos conjuntos de cambios a diferentes líneas en un archivo y se pueden combinar fácilmente. Cuando los cambios en un archivo se hacen en la misma línea o líneas, se producen conflictos, que requieren a alguien para editar el archivo manualmente para que los cambios puedan ser cometidos satisfactoriamente en el repositorio fuente.

Hay dos tipos de fusiones: automático y manual.

––Automatic fusión es lo que el software de control de versiones hace cuando reúne los cambios que se han producido de forma simultánea (en un sentido lógico). Además, otras piezas de software de despliegue automático de la fusión permiten editar el mismo contenido al mismo tiempo. Por ejemplo, Wikipedia permite que dos personas editen el mismo artículo, al mismo tiempo, cuando este último colaborador salva sus cambios se fusionan en el artículo en lugar de sobrescribir el anterior conjunto de cambios.

––Fusión Manual es lo que la gente tenga que recurrir a (posiblemente con la asistencia de la fusión de las herramientas) cuando tienen que conciliar los archivos que difieren. Por ejemplo, si dos sistemas dan ligeramente diferentes versiones de un archivo de configuración y el usuario quiere tener las cosas buenas de ambos, esto se puede lograr mediante la fusión de los archivos de configuración a mano, recogiendo los cambios deseados de ambas fuentes. También se requiere la combinación manual cuando la fusión automática se ejecuta en un conflicto, por ejemplo, muy pocas herramientas automáticas de combinación pueden combinar dos cambios en la misma línea de código (por ejemplo, uno que cambia el nombre de la función, y otro que se suma un comentario). En estos casos, la revisión compleja de sistemas de control permiten especificar el resultado de la fusión prevista.

Combinar algoritmos es un área de investigación activa, y por lo tanto hay muchos enfoques diferentes para la combinación automática, con diferencias sutiles.

Los algoritmos de fusión más notables incluyen la fusión tres bandas, recursivo de mezcla de tres vías, y la conmutación de parches.

6.4.6 Etiquetado («tagging»).

Una etiqueta de revisión es el término comúnmente utilizado para definir una etiqueta textual que puede estar asociada con una revisión específica de un proyecto mantenido por un sistema de control de revisión. Esto permite al usuario definir un nombre con significado que debe darse a un estado particular de un proyecto que está bajo control de versiones. Esta etiqueta se puede utilizar en lugar del identificador de revisión para los comandos soportados por el sistema de control de versiones.

RECUERDe La fusión se utiliza para integrar en el código los diversos cambios realizados por los diversos desarrolladores.

180

Unidad didáctica 6. CONTROL DE VERSIONES

Por ejemplo, en el desarrollo de software una etiqueta puede ser usada para identificar una versión específica del software tales como “versión 2.4”, Release_1_0, Delivery_00456, etc.

6.4.7 Líneas de base («baseline»).

RECUERDe Las versiones se etiquetan de forma que se pueda entender de dónde se partió para llegar a ellas.

Dado que el cambio requiere de un estado inicial y el estado siguiente, el marcado de los estados importantes dentro de una serie de varios cambios se convierte en importante. La identificación de los estados importantes dentro de la historia de las revisiones de un elemento de configuración es el propósito central de la identificación inicial.

Por lo general, los estados significativos son los que reciben un estado de aprobación formal, ya sea explícita o implícitamente (estados de aprobación pueden marcar de forma individual, cuando dicha marca se ha definido o significaban simplemente por asociación a una determinada línea de base). Sin embargo, este estado de aprobación es generalmente reconocido públicamente. Por lo tanto, una línea de base también puede marcar un elemento de configuración aprobada, por ejemplo, un plan de proyecto que se ha firmado para su ejecución. De una manera similar, la asociación de múltiples elementos de configuración con tal línea de base indica los puntos sobre cómo ha de ser aprobado.

En general, una línea de base puede ser un único producto de trabajo, o un conjunto de productos de trabajo que se pueden utilizar como una base lógica para la comparación. Una línea de base también puede ser establecida (cuyos productos, trabajo a cumplir con ciertos criterios) como la base para seleccionar actividades posteriores.Tales actividades pueden ser atribuidos a la aprobación formal.

Por el contrario, la configuración de un proyecto a menudo incluye una o más líneas de base, el estado de la configuración, y cualquier métrica recogida. La configuración actual se refiere a la situación actual, la auditoria actual, métricas actuales, y la última revisión de todos los elementos de configuración. Del mismo modo, pero con menos frecuencia, una línea de base puede referirse a todos los elementos asociados con un proyecto específico. Esto puede incluir todas las revisiones de todos los artículos, o sólo la última revisión de todos los elementos del proyecto, dependiendo del contexto, por ejemplo, “La línea de base del proyecto está avanzando según lo previsto.”

Pueden especializarse como un tipo específico de la línea de base. Algunos ejemplos incluyen: ––Línea de base funcional: las especificaciones iniciales establecidas, contratadas, etc ––Línea de base asignada: estado de los productos del trabajo una vez que se aprobaron los requisitos

Unidad didáctica 6. CONTROL DE VERSIONES

––Línea de base de desarrollo: estado de los productos de trabajo en el medio de desarrollo ––Línea de base del producto: contiene los contenidos del proyecto ––Otros, en base a las prácticas comerciales de propiedad Mientras que marca el estado de aprobación cubre la mayoría de usos de una línea de base, las líneas de base podrán establecerse únicamente para indicar el estado de los trabajos a través del paso del tiempo. En este caso, una línea de base es una participación visible a través de un esfuerzo colectivo soportado, por ejemplo, una línea de base de desarrollo. Las líneas de base también pueden marcar hitos, aunque algunos hitos también significan aprobación.

Las líneas de base mismas se valoran no sólo por su capacidad para identificar el estado notable de producto de trabajo(s), sino también proporcionar una importancia particular en su capacidad para ser recuperado. Una vez recuperado, el estado de los productos de trabajo en el subconjunto que comparten la misma importancia en cuanto a los cambios observaron este significado. La línea de base pasa a considerarse con cualidades (ya sean favorables o desfavorables). Por esta razón, la identificación de línea de base, el seguimiento, y la recuperación son críticos para el éxito de gestión de la configuración. Sin embargo, la facilidad de recuperación de cualquier línea de base dada varía de acuerdo con el sistema empleado para llevar a cabo la gestión de configuración que puede utilizar un método manual, automatizado, o híbrido. Una vez recuperada, de la línea de base puede ser comparada con una configuración particular u otra línea de base.

La mayoría de las líneas de base se establecieron en un punto fijo en el tiempo y sirven para seguir referencia a ese punto (identificación de estado). Sin embargo, se establecen algunas líneas de base para llevar adelante como una referencia al artículo en sí mismo, independientemente de cualquier cambio en el material.

Estas últimas líneas de base que evolucionan con la progresión del esfuerzo de trabajo, pero continúan para identificar los productos de trabajo notables en el proyecto.

En el proceso de llevar a cabo la gestión de configuración, los elementos de configuración (o productos de trabajo) pueden ser líneas de base a fin de establecer con un cierto estatus a las partes interesadas. En este sentido, a la línea de base un producto de trabajo puede requerir ciertos cambios para el producto de trabajo para asegurar su conformidad con las características asociadas con la línea de base de referencia. Esto varía del contexto, pero en muchos casos esto tiene la consecuencia de que el producto de trabajo es “reset” a un estado inicial (posiblemente inherentemente aprobado) de la que el trabajo puede continuar.

181

182

Unidad didáctica 6. CONTROL DE VERSIONES

En muchos entornos, las líneas de base se controlan de tal manera que ciertas actividades posteriores contra los productos de trabajo en esa línea de base son prohibidas o permitidas. Estas actividades son cuidadosamente seleccionadas y controladas, y otra vez, dependiendo del sistema de gestión de la configuración, también se monitorizan. En consecuencia, las líneas de base están normalmente sometidas a auditorias de gestión de configuración. Las auditorias de configuración puede incluir un examen de las acciones específicas llevadas a cabo en contra de la línea de base, la identificación de las personas que participan en una acción, una evaluación de los cambios en la línea de base, re-certificación para su aprobación, la contabilidad, la recopilación de mediciones, la comparación con otra línea de base, o todos éstos.

RECUERDe La identificación de los estados importantes dentro de la historia de las revisiones de un elemento de configuración es el propósito central de identificación de la baseline.

Aunque es común en los sistemas de control de versiones de software encontrar elementos como etiquetas o tags, la existencia de líneas de base se encuentra en otros ámbitos relacionados con la tecnología. Las líneas de base se pueden encontrar en los sistemas de modelado UML y sistemas de gestión de reglas de negocio, entre otros.

Además del campo de la ingeniería de hardware y software, las bases de referencia se pueden encontrar en la medicina (por ejemplo, monitoreo del progreso de la salud), la política (por ejemplo, estadísticas), la física y la química (por ejemplo, observaciones y modificaciones), finanzas (por ejemplo, elaboración de presupuestos), y otros.

6.4.8 Actualizaciones.

Una actualización (sync o update) se compone por la integración de los cambios que han realizado en el repositorio en la copia de trabajo local.

6.4.9 Congelaciones.

La congelación es un punto en el tiempo en el proceso de desarrollo después de lo cual las reglas para realizar cambios en el código fuente o los recursos relacionados se vuelven más estrictos, o el período durante el cual se aplican esas reglas.

El congelamiento ayuda a mover el proyecto hacia una liberación o el final de una iteración mediante la reducción de la cuantía y frecuencia de los cambios, y se puede utilizar para ayudar a cumplir con un plan de trabajo. Las reglas exactas dependen del tipo de congelación y el proceso de desarrollo, por ejemplo, pueden incluir sólo permitir cambios que corrija los errores, o permitir sólo los cambios después de la revisión a fondo por otros miembros del equipo de desarrollo.

También pueden especificar lo que sucede si se requiere un cambio en contra de las reglas, como reiniciar el período de congelación.

Dos tipos comunes de congelación son: ––El congelamiento de función, en la que se suspende todo el trabajo en la adición de nuevas características, cambiando el esfuerzo para corregir errores y

Unidad didáctica 6. CONTROL DE VERSIONES

183

mejorar la experiencia del usuario. La adición de nuevas características puede tener un efecto perjudicial sobre otras partes del programa, debido tanto a la introducción de, código fuente no probado nuevo o recursos y a las interacciones con otras características, por lo tanto, una función de congelación ayuda a mejorar la estabilidad del programa.

––El congelamiento del código, en el que ningún cambio en absoluto se permite a una parte o la totalidad del código fuente del programa. Especialmente en grandes sistemas de software, cualquier cambio en el código fuente puede tener consecuencias no deseadas, lo que podría introducir nuevos errores, por lo que la congelación de código ayuda a asegurar que una parte del programa que se sabe que funciona correctamente continuará haciéndolo. Congelar el código se emplean a menudo en las etapas finales del desarrollo, cuando se está probando una liberación o iteración particular, pero también se pueden usar para prevenir los cambios en una parte de un programa, mientras que otro está siendo desarrollado.

En entornos de desarrollo que utilizan el control de la revisión, el uso de ramificación puede aliviar los retrasos en el desarrollo causados por las heladas. Por ejemplo, un proyecto puede tener una rama estable de la que se liberan nuevas versiones del software, y una rama de desarrollo independiente en el que los desarrolladores agreguen código nuevo. El efecto de la congelación es a continuación para evitar la promoción de algunos o todos los cambios de la rama de desarrollo a la rama estable. En otras palabras, la congelación se aplica sólo a la rama estable, y los desarrolladores pueden continuar con su trabajo en la rama de desarrollo.

RECUERDe Las congelaciones de las versiones son necesarias para desembocar en la entrega de una versión completa.

6.4.10 Gestión de conflictos “Merge” tiene un segundo significado relacionado: es cuando el sistema de control de versiones se encuentra con que dos personas han cambiado el mismo archivo, pero de manera que no se superponen. Puesto que los dos cambios no interfieren entre sí, cuando una de las personas que actualiza su copia del archivo que ya contiene sus propios cambios, los cambios de la otra persona se fusionan automáticamente. Esto es muy común, especialmente en proyectos de múltiples personas que crean partes del mismo código. Cuando dos cambios diferentes se superponen, el resultado es un “conflicto” ¿Qué sucede cuando dos personas tratan de hacer diversos cambios en el mismo lugar en el código. Todos los sistemas de control de versiones detectan automáticamente los conflictos, y notifican al menos uno de los involucrados que sus cambios entran en conflicto con otra persona. Le corresponde entonces resolver el conflicto, y comunicar esa resolución con el sistema de control de versiones.

RECUERDe Con un adecuado sistema de mergeo en el control de versiones se evitan los conflictos en el versionado del software.

184

Unidad didáctica 6. CONTROL DE VERSIONES

6.5 Buenas prácticas en control de versiones.

En resumen las mejores prácticas para el uso de control de versiones se puede describir con siete frases básicas: ––Poner todo bajo control de versiones.

––Crear carpetas de inicio de sandbox.

––Utilizar una estructura de proyecto común y la convención de nomenclatura.

––Comprometerse a menudo y en unidades lógicas.

––Escribir mensajes de confirmación significativas.

––Todas las operaciones de archivo deben estar en el sistema de control de versiones.

––Se deben configurar notificaciones de cambio.

Estas recomendaciones están basadas en la propia experiencia y usando CVS y Subversion, pero los principios deben también transferir fácilmente a otros sistemas.

1. Poner todo bajo control de versiones Los archivos asociados a cualquier proyecto sobre el que se está trabajando que puedan ser de interés para cualquier persona, o para una sola, deben ponerse bajo control de versiones. Se debe tener en cuenta que esto no se limita al código fuente y los archivos relacionados con la ejecución de un proyecto, sino que también incluye documentos como actas de reuniones, especificaciones, arquitectura y diseño de documentos, dibujos, archivos de configuración y scripts de instalación. Al hacer la investigación para un proyecto y la recopilación de información de los recursos externos, también se debe añadir los del repositorio. Algunos ejemplos son los folletos de productos, las especificaciones del protocolo, referencias de libros y enlaces a sitios web de las empresas. Correspondencia por correo electrónico, análisis de notas de la pizarra o un dibujo conceptual en una servilleta también son útiles para almacenar para su posterior consulta.

Aunque algunas personas piensan que es tonto para archivar archivos que no cambian en un sistema de control de versiones, resulta sumamente valioso contar con todos los documentos relacionados con un proyecto almacenados en el mismo lugar. Esto posibilita encontrar las cosas de forma mucho más fácil, permitiendo ahorrar un montón de tiempo en el que no tiene que navegar a través de cientos de mensajes de correo electrónico para localizar esa especificación recibida hace muchos meses. Además, en el área de desarrollo de software, no hay ningún documento que nunca cambie (o al menos, no debería ser así). Si está trabajando en un proyecto en el que muchos de los documentos son producidos por personas sin conocimientos técnicos o no de programación (es decir, perso-

Unidad didáctica 6. CONTROL DE VERSIONES

nas que no utilizan el control de versiones), se recomienda establecer la sincronización automática entre los recursos compartidos de archivos de proyecto y el repositorio de control de versiones.

Cuando la documentación se mantiene en un wiki, las cosas podrían ser un poco diferentes. Si el propio wiki mantiene un registro de los cambios, cosa que cualquier wiki decente hará, no puede haber ninguna necesidad de almacenar estos datos en un sistema separado. Si el wiki es respaldado por una base de datos, se puede considerar poner la propia base de datos bajo control de versiones, pero alguna gente verá esto como redundante, ya que se tiene copias de seguridad automáticas de todas las bases de datos. No se debe tener ninguna preferencia sobre cómo debe resolverse, siempre y cuando todos los documentos relacionados con el proyecto se almacenen en un servidor central con el historial de revisiones asociado.

Para formatos de documentos que requieren un procesamiento antes de ser legible, como archivos DocBook LaTeX, LyX, y se prefiere cometer los mismos de manera más legible, como PDF o HTML. Algunos pueden argumentar que esto viola el principio DRY, sino que hace que los documentos sean más fáciles de leer para las personas que no cuentan con las herramientas de procesamiento necesarios instalados (o que son simplemente perezosos). Esto puede ser muy útil para la distribución de documentos mediante la vinculación a ellos directamente en el repositorio (por ejemplo a través de HTTP), pero no hacerse cargo de actualizar ambas versiones al hacer cambios en esos archivos o, mejor aún, automatizarlo.

2. Crear Sandbox carpetas principales Para animar a los desarrolladores a utilizar el sistema de control de versiones también para sus propios documentos, proyectos y herramientas, se recomienda crear carpetas de inicio en el repositorio, dando a cada usuario una caja de arena para jugar. Muchas herramientas útiles han comenzado como scripts simples en la carpeta de inicio de un desarrollador y se convirtió en utilidades de gran alcance en el tiempo, ¿por qué no mantener el historial de revisiones desde el primer día?

Esto también permite a los desarrolladores con menos experiencia experimentar con ramificaciones, etiquetado y fusión, se deben utilizar las características de los proyectos reales también.

3. Utilización de una estructura común de proyectos y Convención de nomenclatura Se recomienda una nomenclatura coherente para todos los archivos y carpetas de un proyecto. Preferiblemente, se debe hacer un esfuerzo para mantener el convenio entre proyectos en el repositorio. Esto hace que sea más fácil localizar

185

186

Unidad didáctica 6. CONTROL DE VERSIONES

los archivos de adivinar parcialmente su nombre o ubicación. Por ejemplo, encontrar el código fuente de un proyecto con muchos sub-carpetas será mucho más fácil si el que contiene el código fuente de la carpeta se denomina src en lugar de algo totalmente arbitrario.

RECUERDe Que todo el software esté bajo un adecuado control de versiones es sin duda un buen criterio para la elaboración óptima del software.

Usando la estructura del proyecto común también puede ser valiosa para herramientas automatizadas. Por ejemplo, si todos los proyectos tienen un readme.txt o readme.html en su carpeta raíz, se puede implementar fácilmente una secuencia de comandos para generar una página web con una breve descripción de cada proyecto en el repositorio. Si está utilizando un sistema de generación automática, como Apache Maven, parte de esta estructura esta ya definido para usted.

Idealmente, la estructura y las políticas de denominación del proyecto se deben describir en sus convenciones de código o directrices similares.

4. Comprometerse a menudo y en unidades lógicas El procedimiento para seguir el ciclo de trabajo de base se describe en la documentación de Subversion. Esto significa que se debe siempre actualizar su copia de trabajo antes de realizar cualquier cambio en los archivos. En general es preferible para confirmar los cambios en unidades lógicas. Los cambios que van de la mano deben comprometerse juntos. Esto puede hacer que el historial de revisión resulte mucho más útil en sistemas cuando los cambios abarcan múltiples archivos.

Si se están haciendo muchos cambios en un proyecto al mismo tiempo, dividir en partes lógicas y comprometerse en varias sesiones, esto hace que sea mucho más fácil para realizar el seguimiento del historial de los cambios individuales, lo que le ahorrará un montón de tiempo cuando se trata de encontrar y corregir los errores en el futuro. Por ejemplo, si está implementando función A, B y C, y corrección de errores 1, 2 y 3, que debería dar lugar a un total de al menos seis, una para cada función y una para cada error. Si se está trabajando en una gran característica o hacer una amplia refactorización, se debe considerar dividir el trabajo hasta incluso en partes más pequeñas, y hacer un compromiso después de finalizar cada parte. Además, al aplicar cambios independientes a varios módulos lógicos, confirmar los cambios a cada módulo por separado, incluso si son parte de un cambio más grande.

Idealmente, nunca se debe salir de su oficina con los cambios no confirmados en su disco duro. Si está trabajando en proyectos en los que los cambios afecten a otras personas, se ha de considerar el uso de una rama para implementar los cambios y unirlos de nuevo en el tronco cuando haya terminado. Confirmar los cambios a las bibliotecas o proyectos de otros proyectos que afecten a otras personas, se ha de asegurar de no romper sus builds realizando código que no compile. Sin embargo, tener código que no compile no es una excusa para no comprometerse, se han de utilizar las ramas en su lugar.

Unidad didáctica 6. CONTROL DE VERSIONES

5. Escribir mensajes de confirmación significativos Si no tiene nada que decir sobre lo que se está cometiendo, no tiene nada que cometer.

Siempre se debe escribir un comentario al cometer algo en el repositorio. El comentario debe ser breve y conciso, que describa lo que se ha cambiado y, posiblemente, el por qué. Si han realizado varios cambios, escribir una línea o frase sobre cada parte. Si se escriben una larga lista de cambios, se debe considerar en dividir su compromiso en partes más pequeñas, como se describió anteriormente. Se deben prefijar los comentarios con identificadores como “Fix” o “Añadir” es una buena manera de indicar el tipo de cambio que se hizo. También hace que sea más fácil de filtrar el contenido más tarde, ya sea visualmente, por un lector humano, o automáticamente, mediante un programa.

Si fija un error específico o implementado una solicitud de cambio específico, también se recomienda hacer referencia al número de error o problema en el mensaje de confirmación. Algunas herramientas pueden procesar esta información y generar un enlace a la página correspondiente en un sistema de seguimiento de errores o actualizar el tema basado en el compromiso.

Muchos desarrolladores son descuidados al comentar sus cambios, y algunos pueden sentir que no son necesarios mensajes de confirmación. O bien se consideran los cambios triviales, o argumentan que sólo puede examinar el historial de revisiones para ver qué se ha cambiado. Sin embargo, el historial de revisiones sólo muestra lo que realmente cambiaron, no lo que el programador tuvo la intención de hacer, o por qué se hizo el cambio. Esto puede ser aún más problemático cuando la gente presenta el valor de una semana de cambios en varios módulos en una gran pila. Con un historial de revisiones de grano fino, los comentarios pueden ser útiles para distinguir la trivialidad de los cambios en el repositorio. Si se considera que los cambios realizados no son lo suficientemente importantes como para tener que comentarlos, probablemente no vale la pena comentar cualquier otro.

6. Hacer todas las operaciones de archivos en el sistema de control de versiones Siempre que necesite copiar, borrar, mover o cambiar el nombre de archivos o carpetas en el repositorio, se debe realizar usando las operaciones de archivo correspondientes en el control de versiones. Si esto se hace sólo en el sistema de archivos local, la historia de esos cambios se perderá para siempre. Se considera que los cambios estructurales son tan importantes como los cambios en los propios archivos, por lo que no hay ninguna razón para no dejar que el sistema de control de versiones no los pierda de vista. Además, cuando las personas saben todos los cambios que se pueden deshacer, el umbral para hacer una reestruc-

187

188

Unidad didáctica 6. CONTROL DE VERSIONES

turación radical y de gran refactorización bajará, lo cual puede tener un impacto significativo en la prevención de la acumulación de deuda técnica.

7. Configurar notificaciones de cambio Para monitorear los cambios en el repositorio a medida que ocurren, se recomienda configurar notificaciones de cambio por medio del envío de un e-mail o actualizaciones por un canal RSS cada vez que se ha hecho una confirmación.

Algunos sistemas de apoyo a las notificaciones directamente a través de eventos, a veces con implementaciones predeterminadas proporcionadas, mientras que otros pueden requerir trabajos externos, demonios o scripts personalizados para proporcionar esta función.

Se recomienda que todos los desarrolladores se suscriban a las notificaciones de cambio, ya que pueden tener muchas ventajas. Obviamente, son útiles si desea ver qué cambios se están haciendo a los proyectos que están trabajando o tienen un interés (es decir, una biblioteca de su proyecto), pero también podrían favorecer o asustar a la gente a escribir mensajes, ya que muchas veces no saben quién en realidad podría estar leyéndolos.

Normalmente, las notificaciones también contienen extractos de los archivos que se han cambiado, que los hace útiles para ligeras revisiones de código. Los programadores que controlan los cambios de código fuente pueden mantener un ojo hacia fuera para los olores de código o violaciones de las convenciones de código, y si hay suerte, puede que incluso aprender algo mediante la lectura de código de otras personas.

RECUERDe Los desarrolladores se deben comprometer con el sistema de control de versiones que se establezca, y no salirse nunca de él.

Si se está trabajando en un proyecto grande o hay muchos proyectos activos en el repositorio, puede que le resulte útil crear notificaciones por separado para cada módulo o proyecto. Si las notificaciones se envían a través del correo electrónico, también puede configurar el campo de asunto para indicar qué módulo o repositorio de la notificación pertenece, por lo que es posible procesar con reglas de filtrado de correo electrónico estándar.

Si se está haciendo todo lo anterior, se está haciendo lo correcto. Si no es así, añadiendo algunos de ellos a sus hábitos de trabajo puede hacer que se note la diferencia. Por supuesto, no todo el mundo está en condiciones de cambiar la estructura de su proyecto o de la configuración del repositorio, pero cualquier programador puede hacer su vida más fácil al agrupar lógicamente las confirmaciones y mensajes de confirmación que sean significativos. Se debe considerar al menos la posibilidad de darle una oportunidad.

Unidad didáctica 6. CONTROL DE VERSIONES

189

6.6 Herramientas de control de versiones de uso común.

6.6.1 Características.

Hay muchas soluciones de entre las que se ha seleccionado un puñado de las más relevantes y realizado una comparación sobre sus características para permitir elegir la mejor para cada caso. Es un tema bastante técnico, por lo que si no se tiene un fondo del software, se debe leer la comparación cuidadosamente, y consultar con el personal técnico antes de tomar cualquier decisión final. El software de control de versiones, incluyendo la SVN y Git se sabe que fue diseñado desde el principio para permitir que los equipos de programadores puedan trabajar juntos en un proyecto sin perder horas-hombre en el papeleo. En lugar de las ramas de código y notas asociadas, exploración manual, control de versiones permite un repositorio central que está organizado, lógico y facilita la actualización de archivos de notación, y que se fusionan.

Hay muchas opiniones con respecto a que la versión marco de control es el mejor, y puede obligar a los programadores y los equipos de gestión de proyectos a un intenso debate. Al elegir el control de la versión adecuada para su proyecto, se debe considerar que algunas de las ventajas de un paquete que se encontrará son subjetivos, es decir, la opinión del programador, y otros factores, como la velocidad y el plug-in IDE de capacidades, ensombrecen los crudos números.

La principal diferencia entre los sistemas de control de versiones es si son de servidor basado en peer-to-peer, o bien tienen un repositorio centralizado donde el código está desprotegido de nuevo con los cambios, o una configuración donde el código se actualiza con frecuencia, una red más descentralizada, para mantener actualizado el código.

Más allá de eso, también se tendrá que considerar la velocidad, la funcionalidad, y la curva de aprendizaje asociada con el sistema. Para decidir cuál es el adecuado para cada proyecto y equipo, se echará un vistazo a algunos de los principales sistemas disponibles y las razones por las cuales algunos programadores prefieren uno sobre el otro.

6.6.2 Comparativa.

Concurrent Versions System (CVS) CVS (http://www.nongnu.org/cvs/) ha estado presente desde los años 80, y ha sido muy popular entre los desarrolladores comerciales y de código abierto. Es liberado bajo la licencia GNU, y utiliza un sistema para que los usuarios “checkout” del código que se va a trabajar y “check in” a sus cambios. Originalmente, CVS maneja los conflictos entre dos programadores, permitiéndose sólo para la

RECUERDe Las herramientas de control de versiones son bastante similares, por lo que se debe centrar en las pequeñas diferencias que las definen para decantarse por una u otra.

190

Unidad didáctica 6. CONTROL DE VERSIONES

última versión del código que se va a trabajar y actualizada. Así se usará la técnica first in, first out, por la que el primer llegado es el primer servido por el sistema donde el usuario debe publicar los cambios rápidamente para asegurarse de que otros usuarios no les gane de mano. CVS puede manejar proyectos de ramificación por lo que el software desarrollado puede divergir en diferentes productos con características únicas y será reconciliada en un momento posterior.

El servidor CVS se ejecuta en sistemas tipo Unix con el software de cliente que se ejecuta en varios sistemas operativos. Se considera que es el sistema de control de versiones más maduro, ya que se ha desarrollado durante mucho tiempo y no recibe muchas peticiones de nuevas características en este momento. Un proyecto “tenedor” de CVS, CVSNT se crea para ejecutar CVS en servidores Windows, y actualmente se está desarrollando activamente para aumentar la funcionalidad.

Ventajas ––Ha estado en uso durante muchos años y se considera una tecnología madura

RECUERDe CVS presenta la experiencia y la madurez como sus principales ventajas.

Inconvenientes ––El mover o renombrar archivos no incluye una actualización de la versión ––Los riesgos de seguridad de los enlaces simbólicos a los archivos ––No hay soporte de operación atómica, lo que lleva a la corrupción de la fuente ––Las operaciones de sucursales son caros, ya que no está diseñada para la ramificación a largo plazo Apache Subversion (SVN) Subversion SVN (http://subversion.apache.org/) fue creado como una alternativa a CVS que permite corregir algunos errores en el sistema CVS, manteniendo una alta compatibilidad con él. Al igual que CVS, SVN es gratuito y de código abierto con la diferencia de que se distribuye bajo la licencia Apache en lugar de GNU. Para evitar la corrupción en la base de datos, SVN emplea un concepto llamado operaciones atómicas. Cualquiera de todos los cambios realizados en el origen se aplican o no, lo que significa que no hay cambios parciales se romperá la fuente original.

Muchos desarrolladores han cambiado a SVN, ya que es una nueva tecnología que toma las mejores características de CVS y mejora sobre ellos. Mientras que las operaciones de sucursales de CVS son caros y realmente no se prestan a “tenedores” de largo plazo en el proyecto, SVN está diseñado para permitir por ello, se presta mejor a los grandes proyectos, ampliando la horquilla con muchas direcciones. La crítica de SVN incluye una velocidad mas lenta, comparada y la falta de control de revisiones distribuida. El control de revisiones distribuido utiliza un modelo peer-to-peer en lugar de utilizar un servidor centralizado para

Unidad didáctica 6. CONTROL DE VERSIONES

191

almacenar actualizaciones de código. Mientras que un modelo peer-to-peer que funcionaría mejor para proyectos de código abierto, puede no ser ideal en otras situaciones. La desventaja de un enfoque de servidor dedicado es que cuando el servidor está caído, los clientes no pueden acceder al código.

Ventajas ––Más nuevo sistema basado en CVS ––Incluye operaciones atómicas ––Operaciones de la sucursal más baratos ––Amplia variedad de plug-ins para IDEs ––No usa modelo peer-to-peer Inconvenientes No usa modelo peer-to-peer (esto también puede suponer un inconveniente) Todavía contiene errores relativos a renombrar archivos y directorios Comandos de gestión de repositorios insuficientes Velocidad comparativa lento Git Desarrollado por primera vez por Linus Torvalds de Linux fama, Git (http://gitscm.com/) adopta un enfoque radical que difiere enormemente de CVS y SVN. Los conceptos originales para Git eran para hacer un sistema de control de revisiones distribuido más rápido que abiertamente desafían las convenciones y prácticas utilizadas en CVS. Está desarrollado principalmente para Linux y cuenta con las más altas velocidades que hay.También puede funcionar en otros sistemas similares a Unix y puertos nativos de Git están disponibles para Windows como msysgit. Como no hay un servidor centralizado, Git no se presta a proyectos de desarrolladores individuales o pequeños equipos como el código no es necesariamente disponible cuando se utiliza un equipo que no repositorio. Existen soluciones para este problema, y algunos ven mejor velocidad de Git como un compromiso decente para la molestia.

Git también viene equipado con una amplia variedad de herramientas para ayudar a los usuarios a navegar por el sistema de la historia. Cada instancia de la fuente contiene todo el árbol de la historia, que puede ser útil cuando se desarrollan sin una conexión a Internet.

Ventajas: ––Ideal para aquellos que odian CVS / SVN ––Aumento drástico de la velocidad de operación

RECUERDe SVN presenta alguna ventaja sobre CVS (en el que se basa) como operaciones de sucursales más económicas, así como variedad de integración en IDEs.

192

Unidad didáctica 6. CONTROL DE VERSIONES

––Operaciones de sucursales baratos ––Árbol de historia completo esté disponible sin conexión ––Modelo distribuido peer-to-peer

RECUERDe Git permite disponer del histórico de control de versiones aún sin conexión.

Es una alternativa al uso de CVS y SVN.

Inconvenientes ––Modelo distribuido peer-to-peer (esto también puede suponer un inconveniente) ––Curva de aprendizaje para aquellos acostumbrados a SVN ––No es óptimo para los desarrolladores individuales ––Compatibilidad limitada de Windows en comparación con Linux Mecurial Mecurial (http://mercurial.selenic.com/) comenzó a la vez que Git y es también una herramienta de control de versiones distribuida. Fue hecho originalmente para competir con Git para el desarrollo del kernel de Linux, y fue seleccionado Git, Mecurial ha visto menos éxito en esa área. Sin embargo, eso no quiere decir que no se utilice, como muchos acontecimientos importantes lo utilizan, incluyendo OpenOffice.org. Es diferente de otros sistemas de control de revisiones en Mecurial se implementa principalmente en Python en lugar de C, pero hay algunos casos en que se utiliza C. Debido a su naturaleza distribuida y su creación en Python, los desarrolladores de Python están considerando un cambio a Mecurial ya que permitiría a los desarrolladores no básicos para tener un acceso más fácil a la creación de nuevos árboles y revertir cambios.

Los usuarios han señalado de las acciones Mecurial algunas características con SVN, además de ser un sistema distribuido, y debido a las similitudes, la curva de aprendizaje para aquellos que ya están familiarizados con SVN será menos pronunciada. La documentación para Mecurial también es más completa y facilitará el aprendizaje de las diferencias más rápidos. Algunos de los principales inconvenientes para Mecurial incluyen que no permite que dos padres que se unieron a diferencia de Git, usa un sistema de extensión en lugar de ser secuencias de comandos. Eso puede ser ideal para algunos programadores, pero muchos encuentran el poder de Git es una característica que no quieren que negocie.

Ventajas ––Más fácil de aprender que Git ––Mejor documentación ––Modelo distribuido Inconvenientes: ––Modelo distribuido (esto también puede suponer un inconveniente)

Unidad didáctica 6. CONTROL DE VERSIONES

193

––No la fusión de dos padres ––Extensión basado en lugar de guionización ––Menos de la alimentación de la caja ¿Qué sistema se debe utilizar?

En su mayor parte, la gente usa CVS, porque ya están acostumbrados a él, y aunque algunas de las peculiaridades y limitaciones son molestos, ya han descubierto la manera de hacer un trabajo salvando las limitaciones establecidas y tener esas soluciones implementadas. Sobre todo si su equipo está llevando a cabo en un determinado proyecto, la posibilidad de migrar todo a otro control de revisiones es molesto, y si iban a cambiar, lo más probable es que sea a SVN. Como ahora se ha trasladado a la “tecnología madura” parte de su ciclo de vida, es poco probable que CVS salgan con características innovadoras, y como se pierde el impulso en el proyecto como la gente se mueve a SVN, parece más probable en su salida.

SVN es actualmente el rey de control de versiones basado en servidor. Tiene todas las buenas características de CVS y mejora sobre ellos. En cuanto a la interacción social, es más probable encontrarse con CVS o SVN de lo que será con Git o Mecurial, por lo que una familiaridad con la tecnología de un solo servidor, aunque no es un requisito, facilitará las transiciones en el lugar de trabajo.

Con su amplia gama de usos y su nivel de madurez del software, SVN tiene una amplia base de conocimientos, y los usuarios podrán encontrar ayuda fácilmente accesible a otros usuarios.

Git tiene una clara mejora en la velocidad respecto a sus competidores, y para los proyectos que se prestan a los sistemas distribuidos, es una clara mejora. La desventaja principal citada para Git es que puede ser a veces difíciles de explicar a los demás, y no es probable que sea una ralentización en la producción como programadores adaptarse a él. Una vez que se aprende, sin embargo, aumenta la velocidad y una mejor gestión de rama recuperar ese tiempo y más. Para aquellos que rechazan Git, Mecurial ofrece un puente entre la SVN y Git que está bien documentado y se utiliza en muchos proyectos bien conocidos. La versión para Windows de usar de Git también ha hecho algunos avances que trae la velocidad cercana a la de las versiones de Linux, por lo que todavía se podría usar si no está desarrollando en Linux.

Para saber cuál es el mejor para cada caso se ha de tener en cuenta el proyecto y los desarrolladores, y hablar con ellos. Si se quiere tener un solo árbol de código fuente principal sobre el que trabajar por un pequeño grupo básico de desarrollo, SVN debería ser el primer intento del sistema, ya que es fiable y adaptada para ello. Si se comienza un proyecto de código abierto, donde varios programadores trabajan en diferentes momentos y/ o presentando varios cambios al código, Git es una excelente opción para su proyecto debido a la gran mejora en la veloci-

RECUERDe Mercurial es otra alternativa a CVS y SVN, más sencillo de usar que Git.

194

Unidad didáctica 6. CONTROL DE VERSIONES

dad y una mejor gestión de los árboles sobre SVN. Si se está en el punto medio o no gusta la forma en SVN o Git funciona después de probarlos, siempre está Mercurial.

RECUERDe Tras elegir el sistema a usar (bien uno de los expuestos, bien otro de los que hay en el mercado), se debe proceder a su implantación y a concienciar a los desarrolladores en su uso.Tras el periodo de adaptación se podrán comprobar las ventajas que supone el uso del control de versiones.

Todos estos sistemas son completamente funcionales, y también son gratuitos.

Todos ellos han sido utilizados para crear software, sitios web, y los sistemas operativos. La primera decisión que tendrá que tomar es cual se adapta mas a las necesidades de su negocio y al equipo y, a continuación, es importante que se debe asegurar de que la elección no enojará al equipo de desarrollo.

6.7 Integración del control de versiones en herramientas de uso común.

Uno de los principales criterios para la evaluación de las herramientas a elegir es la integración de control de versiones. El software más exitoso es el que se integra con otras herramientas y sistemas que se hacen útiles. La nueva generación de herramientas de control de versiones suelen permitir la integración con el control de versiones, pero se debe hacer mucho más.

A nivel de productos básicos, el diseño de la integración se reduce a cuatro puntos importantes: ––El programa debe estar abierto.

––El software necesita una arquitectura de capas.

––La solución total debe ser manejable.

––Un modelo de dominio rico es altamente deseable.

Los sistemas cerrados son extremadamente difíciles de integrar en las herramientas.

Como mínimo, los sistemas deben soportar protocolos abiertos o una API abierta para que otros productos puedan hablar con el producto de una manera estable. Idealmente, el sistema será de código abierto, así integradores pueden acceder, comprender y mejorar los puntos de integración.

Los beneficios de una arquitectura en capas, donde la interfaz de usuario está desacoplada de servicios de back-end se entienden bien. Además de múltiples capas se necesitan varios modelos de comunicación, tanto síncronas como asíncronas. En otras palabras, los sistemas que se desean integrar sin problemas con un producto normalmente necesitan alguna manera de escuchar los eventos interesantes en el producto principal, aunque eso es solo a través de correo electrónico, además del modelo de comunicación de solicitud y respuesta más comunes.

Unidad didáctica 6. CONTROL DE VERSIONES

195

Una vez que se dan los distintos módulos y se consigue que se comuniquen entre sí como se desee, los problemas de gestión de aplicación se vuelven muy importantes. Los grandes problemas son temas como la seguridad (por ejemplo, las credenciales de autenticación para compartir) y la gestión de la dependencia entre el producto de la base y los complementos.

Por último, en gran medida ayuda si el producto de base tiene una rico modelo semántico. Esto hace que sea más fácil para que los productos externos puedan comunicarse de una manera lógica y minimiza la cantidad de pérdida de datos cuando se intercambian datos con el núcleo del producto.

Los líderes de sistemas de control de versiones distribuidas tienden a propiciar su integración con los sistemas. Todos son de código abierto. Todas cuentan con una arquitectura en capas.

RECUERDe Si se desea utilizar el control de versiones (algo muy recomendable) conviene elegir una herramienta que lo integre, por lo se debe considerar este punto a la hora de elegir el software a utilizar.

07 Documentación de aplicaciones web 7.1 Características generales de la documentación. Importancia en el ciclo de vida software 7.2 Organización y estructura básica de documentos

7.7 Herramientas de documentación 7.7.1 Generación automática de documentación técnica 7.7.2 Documentación de código

7.3 Gestión de versiones de docu- 7.8 Buenas prácticas en documentos mentación 7.8.1 Actualizaciones de documentación 7.4 Tipos de documentación 7.8.2 Documentación colaborativa mediante wikis 7.5 Formatos de documentación 7.8.3 Uso de herramientas 7.5.1 Documentos multimedia. Vídeotutoriales 7.5.2 Documentación en aplicaciones. Formatos de ayuda 7.5.3 Documentación en línea.

Wikis 7.6 Estándares de documentación

198

Unidad didáctica 7. DOCUMENTACIÓN DE APLICACIONES WEB

7. DOCUMENTACIÓN DE APLICACIONES WEB 7.1 Características generales de la documentación. Importancia en el ciclo de vida software El documento del Ciclo de Vida de Desarrollo (DDLC) es considerado como el ciclo de vida completo de una tarea de documentación.

La documentación del software requiere de una metodología bien definida para la finalización con éxito. DDLC debe comprender y estar conforme con el ciclo de vida de desarrollo de software (SDLC), ya que ambos son paralelos y entrelazados.

El DDLC consta de las etapas siguientes ––análisis de necesidades ––diseño ––desarrollo del contenido ––edición / corrección de pruebas ––publicación ––mantenimiento 7.2 Organización y estructura básica de documentos Dependiendo del tipo de documentación, contará con un tipo de organización y estructura que otras. No es lo mismo un manual de usuario que una documentación técnica, por ejemplo.

Si se habla de la documentación técnica debe tener la siguiente estructura: ––Diagrama de los módulos ––Diagrama de navegación ––Relación de programas y función de cada uno de ellos ––Estructura de las tablas y modelo entidad relación 7.3 Gestión de versiones de documentos Se debe realizar una buena gestión de versiones de documentos. Para ello en cada documentación debe aparecer reflejada:

Unidad didáctica 7 DOCUMENTACIÓN DE APLICACIONES WEB

El numero de versión Fecha de esa versión Autores de la misma Breve explicación de las principales diferencias respecto a la versión anterior.

7.4 Tipos de documentación.

Existen diversos tipos de documentación, en función del público al que se dirija y del tipo de contenido. Se explican a continuación los principales tipos.

––De requerimientos: Se identifican atributos, capacidades, características o cualidades de un sistema. Esta es la base de lo que será o ha sido implementado.

––De arquitectura y diseño: Es un listado de software. Incluye las relaciones con el entorno y los principios de construcción que se utilizarán en el diseño de componentes de software.

––Técnico: Documentación de código, algoritmos, interfaces y APIs. ––De usuario final: Manuales para el usuario final, los administradores de sistemas y personal de apoyo.

––Comercial: Se indica cómo comercializar el producto y el análisis de la demanda del mercado.

7.4.1 De requerimientos.

La documentación de requerimientos contiene la descripción de lo que hace una aplicación. Se suele usar en la parte de desarrollo del sistema para comunicar todas las funciones que realiza el sistema (o las que no realiza). En los requerimientos tienen influencia, más o menos directa, todas las personas involucradas en la producción del software, por ejemplo: ––usuarios finales ––clientes ––gerentes de producto ––gerentes de proyectos ––departamento de ventas ––departamento de marketing ––arquitectos de software ––ingenieros de usabilidad ––desarrolladores ––ingenieros de testeo

199

200

Unidad didáctica 7. DOCUMENTACIÓN DE APLICACIONES WEB

Por tanto, la documentación de requerimientos tiene muchos propósitos diferentes.

Los requerimientos pueden ser globales (por ejemplo, el entorno de trabajo distribuido), acerca de diseño (por ejemplo, para usar una función del sistema se de be hacer clic con el botón derecho en cierta parte de la interface y elegirla), y muchas otras cosas.

Los requerimientos se pueden especificar como declaraciones en lenguaje natural, como figuras dibujadas, como fórmulas matemáticas detalladas, o como combinaciones de los anteriores.

Los requisitos pueden ser implícitos y difíciles de descubrir. Además es difícil documentar los requisitos, teniendo en cuenta la variedad de personas que deben leer y documentar la documentación. Por eso, a menudo la documentación de requerimientos es incompleta y si esto sucede, los cambios de software se vuelven más difíciles y por lo tanto, más propenso a errores, que equivale a una disminución de la calidad del software y requiere un elevado tiempo, lo que se traduce en mayor presupuesto.

La necesidad de documentación de requerimientos suele estar relacionada con la complejidad del producto, el impacto del producto, y la esperanza de vida del software: ––Si el producto es muy complejo y desarrollado por muchas personas, los requerimientos pueden ayudar a comunicar mejor lo que debe lograr.

––Si la aplicación es crítica para la seguridad y puede tener un impacto negativo en la vida humana (por ejemplo, los sistemas de energía nuclear, equipos médicos), a menudo se requiere más documentación formal de los requisitos.

––Si se estima que la esperanza de vida de la aplicación va a ser muy corta, de pocos meses, (por ejemplo, pequeñas aplicaciones para teléfonos móviles desarrolladas específicamente para una determinada campaña) puede ser necesaria muy poca documentación de los requisitos.

––Si la aplicación es una primera versión que más adelante va a ser modificada, la documentación de los requisitos es muy útil para la gestión del cambio y la verificación de las modificaciones.

7.4.2 De arquitectura y diseño.

La documentación de arquitectura es una clase especial dentro de la documentación de diseño. Se podría decir que al igual que los documentos de código derivan directamente del código fuente de la aplicación, la documentación de diseño es la

Unidad didáctica 7 DOCUMENTACIÓN DE APLICACIONES WEB

segunda derivación del código y la documentación de arquitectura es la tercera derivación del código.

Esta documentación no describe cómo programar los métodos (rutinas o procedimientos) ni el por qué de los mismos, si no que se limita a establecer los requisitos generales que motivan la existencia de los métodos. una buena documentación de arquitectura es poco extensa en detalles, pero de gran extensión en la explicación.

Una parte muy importante de la documentación de diseño es el documento de diseño de base de datos (DDD). Éste contiene elementos de diseño conceptuales, lógicos y físicos. Incluye la información oficial que necesitan las personas que interactúan con la base de datos necesita. Los usuarios potenciales de la base de datos son: ––Diseñador de base de datos ––Desarrollador de base de datos ––Administrador de base de datos ––Diseñador de aplicaciones ––Desarrollador de aplicaciones ––Al hablar de sistemas de bases de datos relacionales, la documentación debe incluir los siguientes elementos: ––Entidad: Esquema de relación incluidos los siguientes datos y sus definiciones: -- Conjuntos de entidades y sus atributos -- Las relaciones y sus atributos -- Claves para cada conjunto de entidades -- Esquema relacional, incluyendo la siguiente información: -- Tablas, atributos y sus propiedades -- Vistas -- Restricciones de referencia -- Cardinalidad de las restricciones de referencia -- Claves principales En esta documentación es muy importante incluir toda la información que va a ser usada por todas las personas involucradas, así como actualizar todos los documentos cuando se produzca un cambio en la base de datos.

201

202

Unidad didáctica 7. DOCUMENTACIÓN DE APLICACIONES WEB

7.4.3 Técnica.

Esto es lo que la mayoría de los programadores definen como documentación de aplicación. Cuando se crea una aplicación, el código de la misma no es suficiente, ya que debe haber información complementaria para describir varios aspectos de su funcionamiento. Es importante que la documentación técnica sea exhaustiva, pero en un equilibro, ya que no debe ser tan detallada como que su mantenimiento sea muy difícil.

Esta documentación puede ser usada por los desarrolladores y las personas que testean la aplicación, pero también puede ser usada por los clientes finales que usan la aplicación. La documentación técnica ha ganado bastante importancia en los últimos años.

Existen herramientas para la generación automática de documentación técnica, por ejemplo: ––Doxygen ––NDoc ––Javadoc ––EiffelStudio ––Sandcastle ––ROBODoc ––TwinText ––Universal Report Estas herramientas generan automáticamente la documentación a partir de los comentarios del código, entre otras partes, y crean manuales de referencia en formato de texto o Html como formatos más usuales. La documentación de código se organiza a menudo en un estilo guía de referencia, lo que permite a un programador poder buscar rápidamente una función o clase.

La generación automática de documentación técnica ofrece muchas ventajas a los programadores, por ejemplo, ya que se extrae a partir del código fuente (a través de comentarios es lo más usual), el programador puede escribir el código y a la vez está generando la documentación; de esta forma la documentación suele estar actualizada.

En contraposición, una desventaja de esta técnica es que sólo los programadores pueden editar este tipo de documentación, y que se depende de ellos para actualizarla.

Unidad didáctica 7 DOCUMENTACIÓN DE APLICACIONES WEB

7.4.4 De usuario: tutoriales, por temas y glosarios.

La documentación de usuario describe cómo se usa una aplicación. Si bien en algún tipo de aplicación, la documentación de código y la documentación de usuario pueden confundirse, esto no es lo general.

Por lo general, la documentación de usuario describe cada función del programa y ayuda al usuario en la realización de estas funciones. Una documentación de usuario bien realizada puede proporcionar asistencia para resolver posibles problemas con el uso de la aplicación.

Es muy importante que los la documentación de usuario sea clara, coherente y fácil de actualizar y si bien no debe tener una estructura determinada, es muy importante que posea un índice. A veces, la documentación del usuario se considera que constituye un contrato que especifica lo que el software va a hacer.

Existen tres formas generales en que la documentación de usuario se puede organizar: Tutoriales: Se considera un enfoque tutorial el más útil para un usuario nuevo, en el que se guían a través de cada paso de la realización de tareas específicas Por temas: Un enfoque temático, donde los capítulos o secciones se concentran en un área particular de interés, se suele usar para un usuario intermedio.

Glosario: En esta organización por lista o referencia, se organiza la documentación en orden alfabético o se grupa de forma lógica, normalmente a través de índices de referencia cruzada. Este enfoque es de mayor utilidad para los usuarios avanzados que saben exactamente qué tipo de información que están buscando.

Una queja común entre los usuarios con respecto a la documentación de las aplicaciones que se suele usar sólo uno de los tres enfoques anteriores de forma exclusiva. Normalmente se usa el enfoque por temas, informando sobres los comandos y elementos visuales de la aplicación, dejando la creación de tutoriales o glosarios en manos de editores privados.

7.4.5 Comercial.

Para muchas aplicaciones, es necesario tener algunos materiales de promoción para alentar a clientes potenciales a aprender más sobre el producto. Es lo que se llama documentación comercial o de marketing. Este tipo de documentación tiene tres objetivos:

203

204

Unidad didáctica 7. DOCUMENTACIÓN DE APLICACIONES WEB

––Incentivar el usuario potencial sobre el producto e inculcarle el deseo de saber más sobre el mismo.

––Informar acerca de qué es exactamente lo que hace el producto, para asegurarle que las expectativas que tiene sean cumplidas por el mismo.

––Explicar las ventajas de ese producto respecto a otras alternativas al mismo.

Una buena documentación comercial debe proporcionar frases claras y fácil de recordar y también indicar la interoperabilidad de sea aplicación con otras de ese mismo fabricante.

7.5 Formatos de documentación.

7.5.1 Documentos.

Existen múltiples formatos de documentación. Se usara uno u otro en función del tipo de documentación o uso que se le vaya a dar. Algunos de los formatos más habituales son: ––html ––chm ––pdf ––doc 7.5.2 Documentación en aplicaciones. Formatos de ayuda.

En una aplicación, una de las partes más importantes de cara al usuario es ofrecer un sistema de ayuda claro y eficaz.

AYUDA HTML EN FORMATO CHM Microsoft Compiled HTML Help es un formato de ayuda online, cuyo propietario es Microsoft. Este formato consta de un conjunto de páginas HTML, un índice y unas herramientas de búsqueda. Estos archivos se comprimen y se muestran en formato binario con la extensión .chm (Compiled HTML. Este sistema fue el sucesor del primitivo formato WinHelp y fue lanzado en la versión Windows 98, siendo aún compatible con las versiones actuales del sistema operativo Windows.

El formato fue diseñador por Microsoft, pero ahora es usado en muchos visores de ayuda en múltiples.

Unidad didáctica 7 DOCUMENTACIÓN DE APLICACIONES WEB

SISTEMA DE AYUDA WEB Un sistema de ayuda web es un sistema de ayuda que se puede cargar a su servidor web o ubicarse en una carpeta compartida de la red de área local, de modo que otras personas puedan acceder a él mediante un navegador. Por lo tanto, un sistema de ayuda web es en realidad un conjunto de archivos HTML que contienen los temas de ayuda del proyecto de ayuda. También debe incluir la tabla de contenido y el índice de palabras clave para proporcionar una navegación fácil para el usuario final.

205

206

Unidad didáctica 7. DOCUMENTACIÓN DE APLICACIONES WEB

Un sistema de ayuda Web se puede usar como una alternativa a la ayuda HTML en formato CHM o junto a éste. Mientras que la Ayuda HTML en formato CHM se utiliza principalmente como un sistema de ayuda local para una aplicación de escritorio en el entorno Windows, un sistema de ayuda de Web está disponible para los usuarios en la página principal del producto. Esto ayuda a reducir el tiempo y los esfuerzos invertidos en asistencia técnica al cliente porque sólo tiene que dirigir a los usuarios a una página web con la sección de solución de problemas que se encuentra en su sitio de Internet.

Además un sistema de ayuda Web es, probablemente, el único documento que contiene una gran cantidad de palabras clave relevantes para el producto, lo que puede ayudar a obtener más tráfico de cara a los principales motores de búsqueda. y si es un software basado en web es un formato imprescindible.

Algunas de las ventajas de un sistema de ayuda web son: ––Permiten una actualización constante del contenido ––Posibilitan a los usuarios una vista previa más detallada de la ––Es una solución multiplataforma, ya que se visualiza con un navegador de Internet, a diferencia de las ayudas locales que se ejecutan en un visor de ayuda y normalmente en una plataforma específica.

––Si se usa un sistema de DocBook XSL, se puede usar una única fuente de publicación que luego puede ser convertida a formato PDF (muy usada para manuales técnicos), en HTML para la publicación en red o para su distribución en formato físico (CDROM, DVD o similares).

Entre las principales desventajas de los sistemas de ayuda web se encuentran: Si la conexión a Internet falla o no se dispone de la misma, no se puede usar.

––Es difícil de aplicar de manera efectiva la ayuda contextual. Si bien es verdad que esta desventaja se ha ido solucionando usando parámetros URL que se crean en algún software destinado a crear esta clase de ayuda.

––Casi todos los sistemas de ayudas web cuentan con secciones muy parecidas, algunas de las cuales son: FAQ (frequently asked questions) o las preguntas que con más frecuencias son realizadas. De esa forma, las cuestiones que más suelen preocupar a los usuarios son respondidas y esto sirve de ayuda para que las dudas más frecuentes sean respondidas sin necesidad de ningún sistema adicional.

Support o servicio técnico: suele ser usada para contactar directamente con el servicio de asistencia técnica

Unidad didáctica 7 DOCUMENTACIÓN DE APLICACIONES WEB

Manuales técnicos.

Algunos ejemplos de sistemas de ayuda web son: ––Helpsmith ––DocBook XSL ––Word-2-Web ––FAR HTML ––XDocs Knowledgebase 7.5.3 Documentación en línea. Wikis.

Una wiki es un conjunto de páginas web entrelazadas que muestran la información almacenada en una base de datos.

Una wiki en una empresa permite a los empleados de diferentes secciones o departamentos poder editar, guardar y compartir los distintos documentos internos de forma colaborativa. En general, son de gran ayuda para desarrollar y gestionar proyectos de personas que no están ubicadas en un mismo espacio físico.

Los tres principios fundamentales de la filosofía wiki son: ––Participación igualitaria: Todos los participantes de la wiki deben tener la misma capacidad de publicar y modificar los contenidos.

––No debe haber un control centralizado: Las Wikis deben ser totalmente c o laborativas.

––Renuncia de la propiedad intelectual de los contenidos: Cualquier participante de una actividad en una Wiki puede modificar, ampliar, reutilizar o eliminar cualquier contenido. Nadie posee el material de la Wiki de manera personal.

A nivel usuario, el sitio más conocido que usa Wikis es Wikipedia, la enciclopedia más grande del mundo. Pero también existen Wikis sobre temáticas específicas en los que profesionales de cada sector desarrollan sus contenidos.

7.6 Estándares de documentación.

ISO/IEC 18019:2004 Este estándar proporciona directrices para el diseño y preparación de la documentación de usuario para las aplicaciones web. En el mismo se describe cómo

207

208

Unidad didáctica 7. DOCUMENTACIÓN DE APLICACIONES WEB

establecer qué información necesitan los usuarios, cómo determinar la forma en que esa información debe serles presentada, y cómo preparar esa información para ser presentada.

Esta norma está pensada para ser usada por las personas responsables de la especificación, diseño y la preparación de la documentación de usuario de las aplicaciones web y las personas que manejan estas actividades, incluyendo los desarrolladores de herramientas para la creación de documentación en papel, los diseñadores, desarrolladores de aplicaciones, administradores de proyectos, autores, programadores y traductores.

Está diseñado para ser utilizado en todo tipo de organizaciones, incluso si no existe un departamento de documentación especializado. Se puede utilizar como una base para las normas y procedimientos locales.

ISO/IEC 26514:2008 Este estándar corresponde a la última revisión del anterior estándar citado ISO/ IEC 18019:2004.

ISO / IEC 26514:2008 proporciona los requisitos para el diseño y desarrollo de la documentación de usuario del software como parte de los procesos del ciclo de vida. Define el proceso de documentación desde el punto de vista del desarrollador de documentación. Este estándar cubre también la documentación del producto. Se especifica la estructura, contenido y formato de la documentación del usuario, y también proporciona una guía informativa para el estilo de documentación del usuario. Es independiente de las herramientas de software que pueden ser utilizados para producir la documentación, y se aplica tanto a la documentación impresa y la documentación en pantalla.

ISO/IEC/IEEE 26512:2011 ISO / IEC / IEEE 26512:2011 fue desarrollada para ayudar a los usuarios de la norma ISO / IEC 15288:2008 o ISO / IEC 12207:2008 (estándares para los procesos de ciclo de vida del software) a adquirir o suministrar documentación de usuario.

Define el proceso de documentación del punto de vista de la entidad adquirente y el punto de vista del proveedor.

Esta norma cubre los requisitos de los elementos de información utilizados en la adquisición de productos de documentación de usuario: ––El Plan de Adquisición, ––Especificación de documentos

Unidad didáctica 7 DOCUMENTACIÓN DE APLICACIONES WEB

––Declaración de trabajo, ––Solicitud de propuestas ––Propuestas.

Proporciona una visión general de la documentación de usuario del software y de los procesos de gestión de la información que puede requerir la adquisición y suministro de documentación de usuario.

Se dirige a la preparación de los requisitos para la documentación de usuario del software, ya que estos requisitos son fundamentales para la especificación de la documentación de usuario y la Declaración de Trabajo.

Incluye requisitos para salidas de documentos primarios del proceso de adquisición y suministro: la solicitud de propuesta y la propuesta de productos y servicios de documentación del usuario.

También se discute el uso de un plan de gestión de documentación y un Plan de documento que se presenten en los procesos de adquisición y suministro.

Esta norma es independiente de las herramientas de software que pueden ser utilizados para producir la documentación, y se aplica tanto a la documentación impresa como a la documentación online.

7.7 Herramientas de documentación.

7.7.1 Generación automática de documentación técnica.

Como se ha comentado en un punto anterior, existen herramientas para la generación automática de documentación técnica, las cuales se basan en los comentarios del código entre otros elementos del mismo y generan una documentación en formato texto o html, como formatos más habituales. Esta documentación creada automáticamente se suele organizar en estilo guía de referencia para poder permitir la búsqueda rápida de una función u otro elemento de la programación.

Al ser obtenida a partir del código fuente de forma automática, hace más fácil su mantenimiento.

Algunos ejemplos de herramientas para la generación automática de documentación de código son:

209

210

Unidad didáctica 7. DOCUMENTACIÓN DE APLICACIONES WEB

DOXYGEN Es la herramienta estándar para generar documentación desde código C++, pero también es compatible con otros lenguajes como C, PHP Java y Python entre otros.

Doxygen puede trabajar de tres formas: ––Puede generar una documentación online en formato html o un manual de referencia offline a partir de archivos de código fuente documentados.También puede generar la documentación en otros formatos como por ejemplo: -- RTF -- PostScript -- PDF con hipervínculos -- HTML comprimido ––Se puede configurar Doxygen para extraer la estructura del código de los archivos de origen no documentados. Esto es muy útil para las grandes distribuciones de código fuente, ya que también puede generar gráficos de dependencia, diagramas de herencias y diagramas de colaboración.

––Se puede usar Doxygen para crear una documentación tradicional.

Doxygen se puede usar en múltiples plataformas: Mac OS X , Linux y Windows.

JAVADOC Javadoc es propiedad de Oracle y genera documentación a desde código fuente Java.

El formato utilizado por Javadoc es el estándar para la documentación de las clases de Java. Este formato es generado de de forma automática por algunos entornos como Eclipse.

Javadoc también permite crear doclets y taglets, los cuales tienen como función analizar la estructura de cualquier aplicación Java.

Otras herramientas son: ––NDoc ––EiffelStudio ––Sandcastle

Unidad didáctica 7 DOCUMENTACIÓN DE APLICACIONES WEB

––ROBODoc –– TwinText –– Universal Report 7.7.2 Documentación de código.

Es muy importante documentar el código fuente de una aplicación, ya que una aplicación puede ser desarrollada por varias personas y la documentación es esencial en la comunicación entre ellos. Además a la hora de actualizar el código es muy importante una correcta, clara y estructurada documentación.

El tipo de documentación que se debe aplicar va a depender del tipo de aplicación o de la complejidad del código. Así, por ejemplo, un programa simple, tendrá un comentario para cada línea de código que necesita ser explicado. Eso es bueno para los desarrolladores - no recarga para arriba y se necesita menos tiempo para desplazarse a través de ella y cambiar las cosas.

Por poner un ejemplo de documentación de código, en las cabeceras de programa se debe indicar un resumen rápido de lo que el programa se supone que debe hacer.

La descripción debe ser breve, pero detallada. Después de la descripción viene el nombre del creador y la fecha. Después de que se puede añadir una pequeña sección para notas propias.

7.8 Buenas prácticas en documentación.

7.8.1 Actualizaciones de documentación.

Al igual que es importante actualizar la aplicación, es importante que cada cambio en la misma quede reflejado en la documentación.

Aunque es una tarea a veces tediosa, es muy importante que ambos, aplicación y documentación estén perfectamente actualizados.

7.8.2 Documentación colaborativa mediante wikis.

Tal y como se ha explicado anteriormente las wikis son una herramienta colaborativa de generación y edición de contenido y como tal se puede aprovechar para múltiples funciones, por ejemplo en la generación de documentación, permitiendo que los propios usuarios editen y generen su propia documentación, fruto del uso de la aplicación.

211

212

Unidad didáctica 7. DOCUMENTACIÓN DE APLICACIONES WEB

7.8.3 Uso de herramientas multimedia.Vídeotutoriales.

Con las últimas tecnologías se ha incrementado el uso de videotutoriales para la realización de la documentación.

Existen herramientas como Camtasia que permiten grabar las acciones del instructor con el programa de forma que se puede grabar un videotutorial usando la aplicación que es la forma más visual y atractiva de explicarla.

Algunas herramientas de videoconferencia también permite crear u videotutorial en tiempo real, por ejemplo, se puede grabar una asistencia técnica a un grupo de usuarios para que sirva de videotutorial al resto.

Resumen Resumen El Internet es un sistema global de redes de ordenadores interconectados que utilizan el conjunto de protocolos estándar de Internet (TCP/IP) para servir a varios millones de usuarios en todo el mundo. Es una red de redes que se compone de millones de organizaciones privadas, públicas, académicas, empresariales, y las redes del gobierno, de los gobiernos locales con el alcance global, que están unidos por una amplia gama de tecnologías de redes electrónicas, inalámbricas y ópticas. Internet conlleva una amplia gama de recursos y servicios de información, tales como los documentos de hipertexto interrelacionados de la World Wide Web (WWW) por medio del protocolo HTTP y la infraestructura de apoyo como el correo electrónico.

En este módulo se han explicado también tecnologías relacionadas, tales como FTP (protocolo dedicado a la transferencia de archivos), UDP (protocolo que no está conectado a conexión, al contrario que el TCP), el direccionamiento IP (direcciones unívocas de cada web) que son traducidas por el sistema DNS. Se pueden crear distintos tipos de aplicaciones, cada una con sus propias características, usando diversas herramientas para su mejor y más sencilla implementación.

En las aplicaciones web tan importante es el contenido como los sistemas de seguridad que se usen, en caso de tratar con datos personales o datos sensibles (tales como datos bancarios), así como el tema estético y de diseño de la propia aplicación. Es conveniente que las aplicaciones tengan un estilo y sean accesibles, para atraer y facilitar su uso.

El tema de la seguridad es crítico, ya que la confianza de los usuarios en Internet, y en las webs es clave para que estos las usen. Actualmente hay sistemas complejos de seguridad, tales como la encriptación, los certificados digitales, y otros sistemas de identificación y autenticación.

Para los desarrolladores es fundamental el mantener controlados los cambios que se realizan en el software. Actualmente muchas de las herramientas para el desarrollo de software integran esta funcionalidad.

Otro tema muy importante en el desarrollo del software es el de las pruebas del mismo.

Se debe comprobar que el sistema realice lo que se supone que debe hacer. Es imposible comprobar la ausencia de errores, pero se debe comprobar que todo aquello que se pide que haga el software, se realice como se espera que lo haga.

Por último cabe destacar la importancia de la documentación en la generación de aplicaciones web, que no es más importante que en cualquier otro desarrollo software. El tema de la importancia de la documentación en el software no es bien entendido por muchos, pero se debe tener presente que tan importante como el propio software desarrollado es la documentación del mismo.

213

Bibliografía Bibliografía • Roldán, David. Aplicaciones Web, un enfoque práctico. Editorial Alfaomega, Mayo 2010.

• González Alvarán, Luis Fernando. Metodología para el desarrollo colaborativo de aplicaciones WEB: Basada en herramientas de Software Libre. Editorial Académica Española. Septiembre 2012.

• Moseley, Ralph. Desarrollo de aplicaciones Web. Ed. Anaya. 2008.

• Barceló Ordinas, José M. y varios. Protocolos y aplicaciones Internet. Editorial UOC. 2008.

Glosario Glosario Desarrollo Software Es el proceso de escribir y mantener el código fuente, pero en un sentido más amplio del término que incluye todo lo que está involucrado entre la concepción del software deseado a la manifestación final del software, idealmente en un proceso planificado y estructurado.

Despliegue Proceso que consta de varias actividades interrelacionadas con las posibles transiciones entre ellos. Estas actividades pueden ocurrir en el sitio productor o en el lugar de los consumidores o ambos.

DNS Traductor bidireccional de nombres de páginas a IPs. IaaS (Infraestructura como Servicio) Permite utilizar recursos informáticos hardware de un proveedor en forma de servicio PaaS (Plataforma como Servicio) Provee desde la nube todos los componentes necesarios para la creación de nuevas aplicaciones informáticas.

Repositorio Es un lugar de almacenamiento donde los paquetes de software pueden ser recuperados.

SaaS (Software como Servicio) Ofrece una variedad de aplicaciones proporcionas por los proveedores del servicio y que se ejecutan en la infraestructura de la “nube”.

Seguridad Abarca las medidas tomadas a lo largo del ciclo de vida de la aplicación para evitar que las excepciones en la política de seguridad de una aplicación o del sistema subyacente (vulnerabilidades) a través de defectos en el diseño, desarrollo, implementación, actualización o mantenimiento de la aplicación.

Verificación Es una disciplina de la ingeniería de software, cuyo objetivo es asegurar que el software satisface plenamente todos los requisitos previstos.

215

Versionado (de software) Es el proceso de asignar cualquiera de los nombres o números de versión única versión únicos a los estados particulares de software.

VoIP Grupo de recursos que posibilita que la señal de voz viaje a través de Internet, usando un protocolo IP (Protocolo de Internet), enviando la señal de voz digitalizada en paquetes de datos.

VPN Virtual Private Network. Red privada virtual.

Webmail Correo electrónico en la nube.

Certificado de Profesionalidad

IFCD0210

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB

l

as competencias profesionales que se adquieren con este Certificado de Profesionalidad son desarrollar documentos y componentes software que constituyan aplicaciones informáticas en entornos distribuidos. Utilizando tecnologías web, partiendo de un diseño técnico ya elaborado, realizando la verificación, documentación e implantación de los mismos.

Módulos formativos y Unidades formativas MF0491_3: Programación web en el entorno cliente UF1841: elaboración de documentos web mediante lenguajes de marca UF1842: Desarrollo y reutilización de componentes software y multimedia mediante lenguajes de guión UF1843: aplicaciones técnicas de usabilidad y accesibilidad en el entorno cliente

UF1844: Desarrollo de aplicaciones web en el entorno servidor UF1845: acceso a datos en aplicaciones web del entorno servidor UF1846: Desarrollo de aplicaciones web distribuidas MF0493_3: Implantación de aplicaciones web en entorno internet, intranet y extranet

ISBN: 978-84-16047-36-9

MF0492_3: Programación web en el entorno servidor