CLIENTE SERVIDDOR.

www.monografias.com/trabajos24/arquitectura-cliente-servidor/arquitectura-cliente-servidor.shtmlwww.desarrolloweb.com/articulos/arquitectura-cliente-servidor.htmlwww.csae.map.es/csi/silice/Global71.html.
http:www.pressman5.com 


 En el mundo de TCP/IP las comunicaciones entre computadoras se rigen básicamente por lo que se llama modelo Cliente-Servidor, éste es un modelo que intenta proveer usabilidad, flexibilidad, interoperabilidad y escalabilidad en las comunicaciones.

El término Cliente/Servidor fue usado por primera vez en 1980 para referirse a PC’s en red.

Este modelo Cliente/Servidor empezó a ser aceptado a finales de los 80’s. Su funcionamiento es sencillo: se tiene una máquina cliente, que requiere un servicio de una máquina servidor, y éste realiza la función para la que está programado (nótese que no tienen que tratarse de máquinas diferentes; es decir, una computadora por sí sola puede ser ambos cliente y servidor dependiendo del software de configuración).

DEFINICION:

Sistema distribuido entre múltiples procesadores donde hay clientes que solicitan servicios y servidores que los proporcionan. Separa los servicios situando cada uno en su plataforma más adecuada.

EL MODELO CLIENTE - SERVIDOR:

Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información en forma transparente aún en entornos multiplataforma.

En el modelo cliente servidor, el cliente envía un mensaje solicitando un determinado servicio a un servidor (hace una petición), y este envía uno o varios mensajes con la respuesta (provee el servicio).

 

En un sistema distribuido cada máquina puede cumplir el rol de servidor para algunas tareas y el rol de cliente para otras. 

La idea es tratar a una computadora como un instrumento, que por sí sola pueda realizar muchas tareas, pero con la consideración de que realice aquellas que son mas adecuadas a sus características. 

Si esto se aplica tanto a clientes como servidores se entiende que la forma más estándar de aplicación y uso de sistemas Cliente/Servidor es mediante la explotación de las PC’s a través de interfaces gráficas de usuario; mientras que la administración de datos y su seguridad e integridad se deja a cargo de computadoras centrales tipo mainframe. Usualmente la mayoría del trabajo pesado se hace en el proceso llamado servidor y el o los procesos cliente sólo se ocupan de la interacción con el usuario (aunque esto puede variar). 

En otras palabras la arquitectura Cliente/Servidor es una extensión de programación modular en la que la base fundamental es separar una gran pieza de software en módulos con el fin de hacer más fácil el desarrollo y mejorar su mantenimiento.

Esta arquitectura permite distribuir físicamente los procesos y los datos en forma más eficiente lo que en computación distribuida afecta directamente el tráfico de la red, reduciéndolo grandemente.

 CLIENTE / SERVIDOR.

Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.

En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.

La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma.

Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de distribución del sistema.

La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.

La red Cliente/Servidor es aquella red de comunicaciones en la que todos los clientes están conectados a un servidor, en el que se centralizan los diversos recursos y aplicaciones con que se cuenta; y que los pone a disposición de los clientes cada vez que estos son solicitados. Esto significa que todas las gestiones que se realizan se concentran en el servidor, de manera que en él se disponen los requerimientos provenientes de los clientes que tienen prioridad, los archivos que son de uso público y los que son de uso restringido, los archivos que son de sólo lectura y los que, por el contrario, pueden ser modificados, etc. Este tipo de red puede utilizarse conjuntamente en caso de que se esté utilizando en una red mixta.

Cuando Implantar Cliente/Servidor?

1. Cambios estructurales y organizativos.

2. Cambios en organigramas.

3. Respuesta dinámica de mercado.

4. Cambio en procesos de negocio.

Que ayuda a la Implemetacion?

1. La demanda de sistemas fáciles.

2. Precio/rendimiento de estaciones y servidores.

3. Creciente acceso a la información para decisiones:

A.Separación datos-programas.

B.Programas flexibles.

4. Nuevas tecnologías de alta productividad.

FUNCIONAMIENTO DEL CLIENTE/SERVIDOR.

Un sistema cliente/servidor funciona tal como se detalla en el siguiente diagrama: 

El cliente envía una solicitud al servidor mediante su dirección IP y el puerto, que está reservado para un servicio en particular que se ejecuta en el servidor.

El servidor recibe la solicitud y responde con la dirección IP del equipo cliente y su puerto.

CLIENTE:

Es el que inicia un requerimiento de servicio. El requerimiento inicial puede convertirse en múltiples requerimientos de trabajo a través de redes LAN o WAN. La ubicación de los datos o de las aplicaciones es totalmente transparente para el cliente. En la arquitectura C/S el remitente de una solicitud es conocido como cliente. 

CARACTERISTICAS DEL CLIENTE. 

1.Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo).

2.Espera y recibe las respuestas del servidor.

3.Por lo general, puede conectarse a varios servidores a la vez.

4.Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario.

5. Al contratar un servicio de redes , se tiene que tener en la velocidad de conexión que le otorga al cliente y el tipo de cable que utiliza , por ejemplo : cable de cobre ronda entre 1 ms y 50 ms.

SERVIDOR:

Es cualquier recurso de cómputo dedicado a responder a los requerimientos del cliente. Los servidores pueden estar conectados a los clientes a través de redes, para proveer de múltiples servicios a los clientes y ciudadanos tales como impresión, acceso a bases de datos, fax, procesamiento de imágenes, etc. Al receptor de la solicitud enviada por cliente se conoce como servidor.

CARACTERISTICAS DEL SERVIDOR:

1. Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo).

2. Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente.

3. Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado).

4. No es frecuente que interactúen directamente con los usuarios finales.

FUNCIONES:

Cliente:  

 

El cliente es el proceso que permite al usuario formular los requerimientos y pasarlos al servidor, se le conoce con el término front-end.

El Cliente normalmente maneja todas las funciones relacionadas con la manipulación y despliegue de datos, por lo que están desarrollados sobre plataformas que permiten construir interfaces gráficas de usuario (GUI), además de acceder a los servicios distribuidos en cualquier parte de una red.

Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:

• Administrar la interfaz de usuario.

• Interactuar con el usuario.

• Procesar la lógica de la aplicación y hacer validaciones locales.

• Generar requerimientos de bases de datos.

• Recibir resultados del servidor.

• Formatear resultados.

SERVIDOR:

Es el proceso encargado de atender a múltiples clientes que hacen peticiones de algún recurso administrado por él. Al proceso servidor se le conoce con el término back-end.

El servidor normalmente maneja todas las funciones relacionadas con la mayoría de las reglas del negocio y los recursos de datos.

Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes puntos:

• Aceptar los requerimientos de bases de datos que hacen los clientes.

• Procesar requerimientos de bases de datos.

• Formatear datos para trasmitirlos a los clientes.

• Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de datos.

Problemas de Gestion de la Ingenieri web.

La ingeniería Web es una actividad técnica complicada. Hay muchas personas implicadas, y a menudo trabajando en paralelo. La combinación de tareas técnicas y no técnicas que deben de tener lugar (a tiempo y dentro del presupuesto) para producir una WebApp de alta calidad representa un reto para cualquier grupo detprofesionales. Con el fin de evitar cualquier confusión, frustración y fallo, se deberá poner en acción una planificación, tener en cuenta los riesgos, establecer y rastrear una planificación temporal y definir los controles. Estas son las actividades clave que constituyen lo que se conoce como gestión de proyectos.

Equipo de Ingenieria Web.

• Expertos en Dominios Empresariales . Ser capaz de responder todas las preguntas relacionadas con metas, objetivos y requisitos empresariales relacionados con la WebApps.

• Especialistas de Soporte . Apoyo continuo a las WebApps. Dado que las WebApps evolucionan constantemente, el Especialista de Soporte es responsable de correcciones, adaptaciones, y mejoras del sitio, actualización de contenido, implementación de nuevos procedimientos, formas y cambios en patrón de navegació.

• Administrador . Llamado “ webmaster ” tiene la responsabilidad de la operación diaria de la WebApps: desarrollo e implementación de políticas de operación, establecimiento de procedimientos de soporte y retroalimentación, implementación de seguridad y derechos de acceso, medición y análisis de trafico, etc. Además puede estar inmiscuido en actividades técnicas. 

Patrones de Diseño.

Como se ha destacado anteriormente en este mismo libro, los patrones de diseño son un buen método para resolver pequeños problemas que pueden adaptarse a una variedad mucho más amplia de problemas específicos. En el contexto de los sistemas y aplicaciones basados en Web, los patrones de diseño pueden aplicarse en el nivel jerárquico, nivel de componentes y nivel de hipertexto (de navegación).

Cuando dentro de una WebApp se requiere la funcionalidad del proceso de datos, pueden aplicarse los patrones de diseño arquitectónicas a nivel de componentes propuestas por [BUS96], [GAM95] y otros. Los patrones de diseño a nivel de hipertexto se centran en el diseño de las características de navegación que permiten al usuario moverse por el contenido de la WebApp fácilmente. Entre muchos de los patrones de diseño de hipertexto propuestos en literatura sobre este tema se encuentran los siguientes :

Ciclo: una configuración que devuelve al usuario al nodo de contenido visitado anteriormente.

Anillo de Web: una configuración que implementa un «gran ciclo que enlaza hipertextos enteros viajando por un tema». 

Contorno: un patrón que aparece cuando varios ciclos inciden en otro, permitiendo navegar por rutas definidas por los ciclos.

Contrapunto: un patrón que añade comentarios de hipertexto interrumpiendo la narrativa del contenido para proporcionar más información o más indagación.

Mundo de espejo: el contenido se presenta utilizando diferentes hilos narrativos, cada uno con un punto de vista o perspectiva diferente. Por ejemplo, el contenido que describe una computadora personal podría permitir al usuario seleccionar una narrativa «técnica » o «no técnica» que describa la máquina.

Tamiz: una configuración que va guiando al usuario a través de una serie de opciones (decisiones) con el fin de llevar al usuario a un contenido específico e indicado por la sucesión de opciones elegidas o decisiones tomadas.

Vecindario: una configuración que abarca un marco de navegación uniforme por todas la páginas Web para permitir que un usuario tenga una guía de navegación consecuente independientemente de la localización de la WebApp.

Las configuraciones de diseño de hipertexto aue se han descrito anter iormente se pueden rekilizar a medida que el contenido va adquiriendo el formato que permitirá la navegación a través de una WebApp.

Diseño de navegación.

 
Una vez establecida una arquitectura de WebApp, una vez identificados los componentes (páginas, guiones, applets y otras funciones de proceso) de la arquitectura, el diseñador deberá definir las rutas de navegación que permitan al usuario acceder al contenido y a los servicios de la WebApp. Para que el diseñador pueda llevarlo a cabo, debe (1) identificar la semántica de la navegación para diferentes usuarios del sitio; y (2) definir la mecánica (sintaxis) para lograr la navegación. 

Generalmente una WebApp grande tendrá una variedad de roles de usuarios diferentes. Por ejemplo, los roles podrían ser el de visitante, cliente registrado ocliente privilegiado. Cada uno de estos roles se pueden asociar a diferentes niveles de acceso al contenido y de servicios diferentes. Un visitante puede tener acceso sólo a un contenido limitado, mientras que un cliente registrado puede tener acceso a una variedad mucho más amplia de información y de servicios. La semántica de la navegación de cada uno de estos roles sería diferente.

El diseñador de WebApps crea una unidad semántica de navegación (USN) para cada una de las metas asociadas a cada uno de los roles de usuario [GNA99]. Por ejemplo, un cliente registrado puede tener seis metas diferentes, todas ellas con un acceso a información y servicios diferentes. Para cada meta se crea una USN. Gnaho y Larcher [GNA99] describen la USN de la siguiente manera:

La estructura de una USN se compone de un conjunto de subestructuras de navegación que llamarnosformas de navegación [WoN (Ways of navigating)]. Una WoN representa la mejor forma de navegación o ruta para que usuarios con ciertos perfiles logren su meta o submeta deseada. Por tanto, el concepto de WoN se asocia al concepto de Perfil de Usuario. 

La estructura de una WoN se compone de un conjunto de nodos de navegación (NN) relevantes conectados a enlaces de navegación, entre los que algunas veces se incluyen las USNs. Eso significa que las USNs pueden agregarse para formar una USN de nivel superior, o anidarse en cualquier nivel de profundidad.

Durante las etapas iniciales del diseño de navegación, para determinar una o más WoNs para cada meta de usuario, se evaluará la estructura de la WebApp (arquitectura y componentes). Como se ha destacado anteriormente, una WoN identifica los nodos de navegación (por ejemplo, páginas Web), y entonces los enlaces que hacen posible la navegación entre ellos. La WoN entonces se organiza en USNs.

A medida que avanza el diseño, se va identificando la mecánica de cada enlace de navegación. Entre otras muchas opciones se encuentran los enlaces basados en texto, iconos, botones, interruptores y metáforas gráficas. El diseñador deberá elegir los enlaces de navegación adecuados para el contenido y consecuentes con la heurística que conduce al diseño de una interfaz de alta calidad.

Además de elegir la mecánica de navegación, el diseñador también deberá establecer las convenciones y ayudas adecuadas. Por ejemplo, los iconos y los enlaces gráficos deberán tener un aspecto «clickable (capacidad de accederse)» con los bordes biselados, y dar así una
imagen en tres dimensiones. La realimentación visual o de sonido se deberá diseñar para proporcionar al usuario una indicación de que se ha elegido una opción de navegación. Para la navegación basada en texto, se deberá utilizar el color que indica los enlaces de navegación
y proporcionar una indicación de los enlaces por los que se ha navegado. Estas son solo unas pocas convenciones de las docenas que hacen que la navegación por la red sea agradable. Además de las convenciones, en este punto también se deberán diseñar ayudas de navegación tales como mapas de sitios, tablas de contenidos, mecanismos de búsqueda y servicios dinámicos de ayuda.

Diseño de la interfaz.

 
Los conceptos, principios y métodos de diseños de interfaz que se presentaron en el Capítulo 15 son todos aplicables al diseño de interfaces de usuario para WebApps. Sin embargo, las características especiales de los sistemas y aplicaciones Web requieren otras consideraciones adicionales.

La interfaz de usuario de una WebApp es la «primera impresión». Independientemente del valor del contenido la sofisticación de las capacidades, los servicios de procesamiento y el beneficio global de la WebApp en sí, una interfaz con un diseño pobre decepcionará al usuario potencial y podrá de hecho hacer que el usuario se vaya a cualquier otro sitio. Dado el gran volumen de WebApps que compiten virtualmente en todas las áreas temáticas, la interfaz debe «arrastrar» inmediatamente al usuario potencial. Nielsen y Wagner sugieren unas cuantas líneas generales y sencillas en el rediseño de una WebApp:

Probabilidad de que los errores del servidor, incluso los más pequeños, hagan que el usuario abandone el sitio Web y busque información y servicios en algún otro sitio.

¿Cuáles son algunas de las líneas generales básicas para el diseño de la interfaz de un sitio Web?

La velocidad de lectura del monitor de una computadora es aproximadamente un 25 por 100 más lento que leer una copia impresa. Por tanto, no hay que obligar al usuario a leer cantidades voluminosas de texto, particularmente cuando el texto explica la operación de la WebApp o ayuda a navegar por la red. 

 
Evite los símbolos «bajo construcción» -levantan expectación y provocan un enlace innecesario que seguramente sea decepcionante.

 
Los usuarios prefieren no tener que recorrer la pantalla.Dentro de las dimensiones normales de una ventana del navegador se deberá incluir información importante.

Los menús de navegación y las barras de cabecera se deberán diseñar consecuentemente y deberán estar disponibles en todas las páginas a las que el usuario tenga acceso. El diseño no deberá depender de las funciones del navegador para ayudar en la navegación.

 
La estética nunca deberá sustituir la funcionalidad. Por ejemplo, un botón sencillo podría ser una opción de navegación mejor que una imagen o icono estéticamente agradables, pero vagos cuya intención no es muy clara.

Las opciones de navegación deberán ser obvias, incluso para el usuario casual. El usuario deberá buscar la pantalla para determinar cómo enlazar con otro contenido o servicio.

Una interfaz bien diseñada mejora la percepción del contenido o de los servicios del usuario que proporciona el sitio Web. No tiene que ser necesariamente deslumbrante, pero deberá estar siempre bien estructurada y ergonómica. 

¿Qué pasos hay que seguir para la comprobación de una WebApp?

El enfoque de las pruebas de las WebApps adopta los principios básicos de todas las pruebas del software (Capítulo 17) y aplica estrategias y tácticas que ya han sido recomendadas para los sistemas orientados a objetos (Capítulo 23). Este enfoque se resume en los pasos siguientes:

1. El modelo de contenido de la WebApp es revisado para descubrir errores. Esta actividad de <<prueba»se asemeja en muchos aspectos a la de un corrector ortográfico de un documento escrito. De hecho, un sitio Web grande tendrá la capacidad de construir un listado de los servicios de correctores profesionales para descubrir errores tipográficos, errores gramaticales, errores en la consistencia del contenido, errores en representaciones gráficas y de referencias cruzadas.

2. El modelo de diseño para la WebApp es revisado para descubrir errores de navegación. Los casos prácticos derivados como parte de la actividad de análisis permite que un ingeniero Web ejercite cada escenario de utilización frente al diseño arquitectónico y de navegación. En esencia, estas pruebas no ejecutables ayudan a descubrir errores en la navegación (por ejemplo, un caso en donde el usuario no pueda leer un nodo de navegación). Además, los enlenlaces de navegación (Sección 29.5.2) son revisados para asegurar su correspondencia con los especificados en cada USN del rol de usuario.

3. Se aplican pruebas de unidad a los componentes de proceso seleccionados y las páginas Web. Cuando lo que se tiene en consideración es el tema de las WebApps el concepto de unidad cambia. Cada una de las páginas Web encapsulará el contenido, los enlaces de navegación y los elementos de procesamiento (formularios, guiones, applets). No siempre es posible o práctico comprobar cada una de las caractensticas individualmente. En muchos casos, la unidad comprobable más pequeña es la página Web. A diferencia de la comprobación de unidades de software convencional, que tiende a centrarse en el detalle algorítmico de un módulo y los datos que fluyen por la interfaz del módulo, la comprobación por páginas se controla mediante el contenido, proceso y enlaces encapsulados por la página Web.

4. Se construye la arquitectura, se realizan las pruebas de integración. La estrategia para la prueba de integración depende de la arquitectura que se haya elegido para la WebApp. Si la WebApp se ha diseñado con una estructura jerárquica lineal, reticular o sencilla, es posible
integrar páginas Web de una manera muy similar a como se integran los módulos del software convencional. Sin embargo, si se utiliza una jerarquía mezclada o una arquitectura de red (Web), la prueba de integración es similar al enfoque utilizado para los sistemas OO. La comprobación basada en hilos (Capítulo 23) se puede utilizar para integrar un conjunto de páginas Web (se puede utilizar una USN para definir el conjunto adecuado) que se requiere para responder a un suceso de usuario. Cada hilo se integra y se prueba individualmente. La prueba de regresión se aplica para asegurar que no haya efectos secundarios. La comprobación de agrupamientos integra un conjunto de páginas colaborativas (determinadas examinando los casos prácticos y la USN). Los casos de prueba se derivan para descubrir errores en las colaboraciones.

5. La WebApp ensamblada se prueba para conseguir una funcionalidad global y un contenido. Al igual que la validación convencional, la validación de lossistemas y aplicaciones basados en Web se centra en acciones visibles del usuario y en salidas reconocibles para el usuario que procedan del sistema. Para ayudar en la derivación de las pruebas de validación, las pruebas deberán basarse en casos prácticos. El caso práctico proporciona un escenario con una probabilidad alta de descubrir errores en los requisitos de interacción del usuario.

La WebApp se implementa en una variedad de configuraciones diferentes de entornos y comprobar así la compatibilidad con cada configuración. Se crea una matriz de referencias cruzadas que define todos los sistemas operativos probables, plataformas de hardware para navegadores7 y protocolos de comunicación. Entonces se llevan a cabo pruebas para descubrir los errores asociados con todas y cada una de las configuraciones posibles.

La WebApp se comprueba con una población de usuarios finales controlada y monitorizada. Se selecciona un grupo de usuarios que abarque todos los roles posibles de usuarios. La WebApp se pone en práctica con estos usuarios y se evalúan los resultados de su interacción
con el sistema para ver los errores de contenido y de navegación, los intereses en usabilidad,
compatibilidad, fiabilidad y rendimiento de la WebApp. 

Dado que muchas WebApps están en constante evolución, el proceso de comprobación es una actividad continua, dirigida por un personal de apoyo a la Web que utiliza pruebas de regresión derivadas de pruebas desarrolladas cuando se creó la WebApp.

 

Diseño para aplicaciones basadas en web.

La naturaleza de inmediatez de las aplicaciones basadas en Web unida a la presión de evolucionar continuamente obliga a que un ingeniero establezca un diseño que resuelva el problema comercial inmediato, mientras que al mismo tiempo obliga a definif una arquitectura de aplicación que tenga la habilidad de evolucionar rápidamente con el tiempo. El problema, desde luego, es que resolver (rápidamente) el problema inmediato puede dar como resultado compromisos que afectan a la habilidad que tiene la aplicación de evolucionar con el paso del tiempo.

Con objeto de realizar un diseño eficaz basado en Web, el ingeniero deberá trabajar reutilizando cuatro elementos técnicos:

Principios y métodos de diseño. Es importante destacar que los conceptos y principios del diseño estudiados en el Capítulo 13 se aplican a todas las WebApps. La modularidad eficaz (exhibida con una cohesión alta y con un acoplamiento bajo), la elaboración paso a paso, y cualquier otra heurística de diseño del software conducirá a sistemas y aplicaciones basados en Web más fáciles de adaptar, mejorar, probar y utilizar. Cuando se crean aplicaciones Web se pueden reutilizar los métodos de diseño que se utilizan para los sistemas orientados a objetos estudiados anteriormente en este libro. La hipermedia define «objetos» que interactúan mediante un protocolo de comunicación algo similar a la mensajería. De hecho, la notación de diagramaspropuesta por UML (Capítulos 21 y 22) puede adaptarse y utilizarse durante las actividades de diseño de las WebApps. Además, se han propuesto otros hipermedios de métodos de diseño (por ejemplo, [ISA95], [SCH96]).

Reglas de oro. 

Las aplicaciones hipermedia interactivas (WebApps) llevan construyéndose ya hace una década. Durante ese tiempo, los diseñadores han desarrollado un conjunto de heurísticas de diseño (reglas de oro) que se podrán volver a aplicar durante el diseño de aplicaciones nuevas. 

Configuraciones de diseño.

Como se ha destacado anteriormente en este libro, las configuraciones de diseño son un enfoque genérico para resolver pequeños problemas que se pueden adaptar a una variedad más amplia de problemas específicos. En el contexto de las WebApps, las configuraciones de diseño se pueden aplicar no solo a los elementos funcionales de una aplicación, sino también a los documentos, gráficos y estética general de un sitio Web.

Plantillas.

Las plantillas se pueden utilizar para proporcionar un marco de trabajo esquemático de cualquier configuración de diseño o documento a utilizar dentro de una WebApp. Nanard y Kahn  describen este elemento de diseño reutilizable de la siguiente manera:

Una vez que se ha especificado una plantilla, cualquier parte de una estructura hipermedia que se acopla a esta plantilla se podrá generar o actualizar automáticamente llamando solamente a la plantilla con datos relevantes [para dar cuerpo al esquema]. La utilización de plantillas constructivas depende implícitamente del contenido separado de los documentos hipermedia, de la especificación y de su presentación: los datos fuente se organizan en la estructura del hipertexto tal y como se especifica en la plantilla.

Diseño arquitectónico.

El diseño arquitectónico para los sistemas y aplicaciones basados en Web se centra en la definición de la estructura global hipermedia para la WebApp, y en la aplicación de las configuraciones de diseño y plantillas constructivas para popularizar la estructura (y lograr la
reutilización). Una actividad paralela, llamada diseño del contenido6, deriva la estructura y el formato detallados del contenido de la información que se presentará como parte de la WebApp. 

Estructuras de las WebApps.

La estructura arquitectónica global va unida a las metas establecidas para una WebApp, al contenido que se va a presentar, a los usuarios que la visitarán y a la filosofía de navegación (Sección 29.5.3) establecidos. Cuando el encargado de la arquitectura va a realizar el diseño
de una WebApp típica puede elegir entre cuatro fuentes diferentes.

¿Cuáles son las opciones disponibles para el diseño de una WebApp?

Las estructuras lineales (Fig. 29.3) aparecen cuando es común la sucesión predecible de interacciones (con alguna variación o diversificación). Un ejemplo clásico podría ser la presentación de un manual de usuario en la que las páginas de información se presentan con gráficos relacionados, vídeos cortos o sonido solo después de haber presentado un prerrequisito. La sucesión de presentación del contenido queda predefinida y se puede decir que, generalmente, es lineal. Otro ejemplo podría ser la sucesión de una entrada de pedido de
un producto donde se tenga que especificar la información específica en un orden específico. En tales casos, las estructuras que se muestran en la Figura 29.3 son las adecuadas. A medida que el contenido y el procesamiento crecen en complicación, el flujo puramente lineal
que se muestra a la derecha da como resultado estructuras lineales más sofisticadas en las que se puede invocar el contenido alternativo, o en donde tiene lugar una desviación para adquirir un contenido complementario (la estructura se muestra a la derecha en la Fig. 29.3).

Estructura reticular.

Las estructuras reticdares (Fig. 29.4) son una opción arquitectónica que puede aplicarse cuando el contenido de la WebApp puede ser organizado categóricamente en dos dimensiones (o más). Por ejemplo, consideremos una situación en la que un sitio de comercio electrónico vende palos de golf. La dimensión horizontal de la retícula representa el tipo de palo en venta (por ejemplo, maderas, hierros, wedges, putters). La dimensión vertical representa la oferta proporcionada por los fabricantes de palos de golf. De aquí que un usuario pueda navegar por la retícula horizontalmente para encontrar la columna de los putters, y recorrer la columna para examinar las ofertas proporcionadas por los vendedores de putters. Esta arquitectura WebApp es de utilidad solo cuando se encuentra un contenido muy regular. 

Las estructurasjerúrquicas (Fig. 29.5) son sin duda la arquitectura WebApp más común. A diferencia de la división de jerarquías de software estudiadas en el Capítulo 14, que fomentan el flujo de control solo a lo largo de las ramas verticales de la jerarquía, se podrá diseñar una
estructura jerárquica de la WebApp para posibilitar (por medio de la ramificación de hipertexto) el flujo de control en horizontal atravesando las ramas verticales de la estructura. Por tanto, el contenido presentado en la rama del extremo izquierdo de la jerarquía puede tener enlaces
de hipertexto que lleven al contenido que existe en medio de la rama derecha de la estructura. Sin embargo, debería de destacarse que aunque dicha rama permita una navegación rápida por el contenido de la WebApp, puede originar también confusión por parte del usuario.

Estructuras jerárquicas.

Una estructura en red o de «web pura» (Fig. 29.6) se asemeja en muchos aspectos a la arquitectura en evolución para los sistemas orientados a objetos. Los componentes arquitectónicos (en este caso las páginas Web) se diseñan de forma que pueden pasar el control (mediante enlaces de hipertexto) a otros componentes del sistema. Este enfoque permite una flexibilidad de navegación considerable, aun cuando puede resultar confuso para el usuario.

Estructura en red o (cweb pura)).

Las estructuras arquitectónicas estudiadas en los párrafos anteriores se pueden combinar para formar estructuras compuestas. La arquitectura global de una WebApp puede ser jerárquica, pero parte de la estructura puede exhibir características lineales, mientras que otra parte de la arquitectura puede confeccionarse en red. La meta del diseñador arquitectónico es hacer corresponder la estructura de la WebApp con el contenido que se va a presentar y con el procesamiento que se va a llevar a cabo.

Un marco de trabajo para la IWEB.

La formulación y el análisis de sistemas y aplicaciones basados en Web representan una sucesión de actividades de ingeniería Web que comienza con la identificación de metas globales para la WebApp, y termina con el desarrollo de un modelo de análisis o especificación de los requisitos para el sistema. La formulación permite que el cliente o diseñador establezca un conjunto común de metas y objetivos para la  construcción de la WebApp. También identifica el ámbito de esfuerzo en el desarrollo y proporciona un medio para determinar un resultado satisfactorio. El análisis es una actividad técnica que identifica los datos y requisitos funcionales y de comportamiento para la WebApp.

Formulación.

 
Powell [POW98] sugiere una serie de preguntas que deberán formularse y responderse al comienzo de la etapa de formulación:

¿Cuál es la motivación principal para la WebApp?
¿Por qué es necesaria la WebApp?
¿Quién va a utilizar la WebApp?

¿Qué preguntas se deberían hacer para formular el problema? 

La respuesta a estas preguntas deberá ser de lo más sucinto posible. Por ejemplo, supongamos que el fabricante de sistemas de seguridad en el hogar ha decidido establecer un sitio Web de comercio electrónico para vender sus productos directamente a los consumidores. Una frase que describiera la motivación de la WebApp podría ser la siguiente:

 
HogarSeguroInc.com5 permitirá a los consumidores configurar y comprar todos los componentes necesarios para instalar un sistema de seguridad en casa o en su comercio.

Es importante destacar que en esta frase no se ha proporcionado ningún detalle. El objetivo es delimitar la intención global del sitio Web. Después de discutir con otros propietarios de Hogar- Seguro Inc., la segunda pregunta se podría contestar de la siguiente manera:

HogarSeguroInc.com nos permitirá vender directamente a los consumidores, eliminando por tanto los costes de intermediarios, y mejorando de esta manera los márgenes de beneficios.
También nos permitirá aumentar las ventas en un 25 por 100 por encima de las ventas anuales y nos permitirá penetrar en zonas geográficas en donde actualmente no tenemos dmacenes
de ventas.

Finalmente, la compañía define la demografía para la WebApp: «Los usuarios potenciales de HogarSeguroInc. com son propietarios de casas y de negocios pequeños.»

Las respuestas que se han establecido anteriormente implican metas específicas para el sitio Web Hogar- SeguroInc.com. En general, se identifican dos categorías:

Metas informativas: indican la intención de proporcionar el contenido y/o información específicos para el usuario final.

Metas aplicables: indican la habilidad de realizar algunas tareas dentro de la WebApp.

En el contenido de la Web HogarSeguroInc.com, una meta informativa podría ser la siguiente:

El sitio proporcionará a los usuarios especificaciones de un producto detallado, como descripción técnica, instrucciones de instalación e información de precios.
 

 El examen de las respuestas anteriores llevará a HogarSeguroInc.com consultará al cliente sobre la instalación (es decir, sobre la casa, oficina/almacén rninorista) que se va a proteger, y dará recomendaciones personalizadas sobre el producto y la configuración que se va utilizar.

Una vez que han identificado todas las metas aplicables e informativas se desarrolla el perfil del cliente. El perfil del usuario recoge «las características relevantes de los usuarios potenciales incluyendo antecedentes, conocimiento, preferencias e incluso más. En el caso de HogarSeguroInc.com, el perfil de usuario identificará las características de un comprador
típico de sistemas de seguridad (esta información sería proporcionada por el departamento de marketing de HogarSeguroInc.com). 

Una vez que se han desarrollado las metas y los perfiles de usuarios, la actividad de formulación se centra en la afirmación del ámbito para la WebApp (Capítulo 5). En muchos casos, las metas ya desarrolladas se integran en la afirmación del ámbito. Además es Útil, no obstante, indicar el grado de integración que se espera para la WebApp. Es decir, a menudo es necesario integrar los sistemas de información existentes (por ejemplo, la aplicación de base de datos existente) en un planteamiento basado en Web. En este punto se tienen en consideración también los temas de conectividad.

Análisis:

Los conceptos y principios que se trataron para el análisis de los requisitos del software (Capítulo 11) se aplican sin revisión en la actividad de análisis de ingeniería Web. Para crear un modelo de análisis completo para la WebApp se elabora el ámbito definido durante la actividad de formulación. Durante la IWeb se realizan cuatro tipos de análisis diferentes:

Análisis del contenido. Se trata de la identificación del espectro completo de contenido que se va a proporcionar. En el contenido se incluyen datos de texto, gráficos, imágenes, vídeo y sonido. Para identificar y describir cada uno de los objetos de datos que se van a utilizar dentro de la WebApp se puede utilizar el modelado de datos (Capítulo 12).

Análisis de la interacción. Se trata de la descripción detallada de la interacción del usuario y la WebApp. Para proporcionar descripciones detalladas de esta interacción se pueden desarrollar casos prácticos (Capítulo 11). 

Análisis funcional. Los escenarios de utilización (casos de uso) creados como parte del análisis de interacción definen las operaciones que se aplicarán en el contenido de la WebApp e implicarán otras funciones de procesamiento. Aquí se realiza una descripción detallada
de todas las funciones y operaciones. 

Análisis de la configuración. Se efectúa una descripción detallada del entorno y de la infraestructura en donde reside la WebApp. La WebApp puede residir en Internet, en una intranet o en una Extranet. Además, se deberá identificar la infraestructura (es decir, la infraestructura de los componentes y el grado de utilización de la base de datos para generar el contenido) de la WebApp.

Aun cuando se recomienda una especificación detallada de los requisitos para WebApps grandes y complejas, tales documentos no son los usuales. Se puede decir que la continua evolución de los requisitos de la WebApp puede hacer que cualquier documento se quede obsoleto antes de finalizarse. Aunque se puede decir que esto sucede de verdad, es necesario
definir un modelo de análisis que pueda funcionar como fundamento de la siguiente actividad de diseño. Como mínimo, la información recogida durante las cuatro tareas de análisis anteriores deberá ser revisada, modificada a petición, y organizada para formar un documento que pueda pasarse a los diseñadores de WebApps.

Atributos de Calidad.

Todas las personas que hayan navegado alguna vez por la Web o hayan utilizado una intranet de una compañía pueden opinar sobre lo que hace una «buena» WebApp. Los puntos de vista individuales vm’an enormemente. Algunos usuarios disfrutan con gráficos llamativos, en cambio otros solo quieren un texto sencillo. Algunos exigen información copiosa, otros desean una presentación abreviada. En efecto, la percepción de «lo bueno» por parte del usuario (y como consecuencia, la aceptación o no aceptación resultante de la WebApp) podría ser más importante que cualquier discusión técnica sobre la calidad de la WebApp.

Pero ¿cómo se percibe la calidad de la WebApp? ¿qué atributos deben de exhibirse ante los ojos de los usuarios para lograr lo bueno y al mismo tiempo exhibir las características técnicas de calidad que permitan a un ingeniero corregir, adaptar, mejorar y soportar la aplicación a largo plazo?

En realidad, todas las características generales de la calidad del software estudiadas en los Capítulos 8, 19 y 24 se aplican también a las WebApps. Sin embargo, las características más relevantes -usabilidad, fiabilidad, eficiencia y capacidad de mantenimiento- proporcionan una base Útil para evaluar la calidad de los sistemas basados en Web.

Olsina y sus colaboradores [OSL99] han preparado un «árbol de requisitos de calidad» que identifica un conjunto de atributos que conduce a WebApps de alta calidad. La Figura 29.1 resume su trabajo. 

FIGURA 29.1. Árbol de requisitos de calidad (OSL 99).

Las tecnologías.

El diseño y la implementación de sistemas basados en Web incorporan tres tecnologías importantes: el desarrollo basado en componentes, la seguridad y los estándares de Internet. Un ingeniero Web deberá estar familiarizado con las tres para construir WebApps de alta calidad.

Desarrollo basado en componentes Las tecnologías de componentes estudiadas en los Capítulos 27 y 28 han evolucionado en gran parte gracias al crecimiento explosivo de los sistemas y aplicaciones basados en Web. Retomando el estudio del capítulo anterior, los ingenieros Web disponen de tres estándares importantes para la infraestructura: CORBA, COMDCOM y JavaBeans. Estos estándares (acompañados por los componentes preconstmidos, herramientas y técnicas) proporcionan una infraestructura que permite a los que diseñan emplear y personalizar componentes de terceras partes permitiéndoles así comunicarse unos con otros y con servicios a nivel de sistemas.

Seguridad

Si en una red reside una WebApp, ésta está abierta a un acceso sin autorización. En algunos casos, ha sido el personal interno el que ha intentado acceder sin autorización. En otros casos, intrusos (hackers) pueden intentar acceder por deporte, por sacar provecho o con intenciones más maliciosas. Mediante la infraestructura de red se proporciona una variedad de medidas de seguridad, tales como encriptación, cortafuegos y otras. Un estudio amplio de este tema queda fuera del ámbito de este libro.

Estándares de Internet.

Durante la última década el estándar dominante en la creación del contenido y la estructura de la WebApp ha sido HTML, un lenguaje de marcas que posibilita al desarrollador proporcionar una serie de etiquetas que describen una gran variedad de objetos de datos (texto, gráficos, audio/vídeo, formularios, etc.). Sin embargo, a medida que las aplicaciones crecen en tamaño y complejidad, se ha adoptado un nuevo estándar -XMLpara la próxima generación de WebApps. XML (Extensible Markup Language) el Lenguaje de marcas extensible es un subconjunto estrictamente definido del metalenguaje SGML [BRA97], permitiendo que los diseñadores definan etiquetas personalizadas en las descripciones de una página Web. Mediante una descripción del metalenguaje XML, el significado de las etiquetas personalizadas se define en la información transmitida al sitio del cliente.

EL PROCESO DE INGENIERIA WEB.

Las caracteristicas de Sistemas y aplicaciones basados en web influyen enormemente en el proceso IWEB. La inmediatez y evoluci[on continuan dicctando un modelo de proceso incremental e interactivo que elabora versiones de WebApps muy rapidamente. La Naturaleza intensiva de red de las aplicaciones en este dominio sugiere una poblacion de usuarios diversa (exigiendo especialmente la obtención y modelado de requisitos) , y una arquitectura de aplicacion que pueda ser altamente especializada (realizando de esta manera exigencias en el diseño). Dado que las WebApps suelen ser controladas por el contenido haciendo hincapié en la estetica, es probable que las actividades de desarrollo paralelas palnifiquen  dentro del rpoceso IWEB y necesitan un equipo de personas tanto tecnicas como no, (por ejemplo, redactores  publicitarios, diseñadores graficos).

 

Los Atributos de Aplicaiones Basadas en WEB.

No hay mucho que decir con respecto al hecho de que los sistemas y las aplicaciones' basados en Web (nos referiremos a estas como WebApps) son muy diferentes de las otras categorías de software informático que se tratan en el Capítulo 1. Powell resume las diferencias básicas cuando afirma que los sistemas basados en Web «implican una mezcla de publicación impresa y desarrollo de software, de marketing e informática, de comunicaciones internas y relaciones externas, y de arte y tecnología». Los atributos siguientes se van a encontrar en la gran mayoría de las WebApps2:

Intensivas de Red. Por su propia naturaleza, una WebApp es intensiva de red. Reside en una red y debe dar servicio a las necesidades de una comunidad diversa de clientes. Una WebApp puede residir en Internet (haciendo posible así una comunicación abierta par todoel mundo). De forma alternativa, una aplicación se puede ubicar en una Intranet (implementando la comunicación a través de redes de una organización) o una Extranet (comunicación entre redes).

Controlada por el contenido. En muchos casos, la función primaria de una WebApp es utilizar hipermedia para presentar al usuario el contenido de textos, gráficos, sonido y vídeo.

Evolución continua. A diferencia del software de aplicaciones convencional, que evoluciona con una serie de versiones planificadas y cronológicamente espaciadas, las aplicaciones Web están en constante evolución. No es inusual que algunas WebApps (específicamente, su contenido) se actualicen cada hora.

Un cuidado y una alimentación continua permite que un sitio Web crezca (en robustez y en importancia). Pero a diferencia de un jardín, las aplicaciones Web deben de servir (y adaptarse a) las necesidades de más de un jardinero, Las siguientes características de WebApps son las que conducen el proceso:

Inmediatez. Las aplicaciones basadas en Web tienen una inmediatez [NOR99] que no se encuentra en otros tipos de software. Es decir, el tiempo que se tarda en comercializar un sitio Web completo puede ser cuestión de días o semanas3. Los desarrolladores deberán utilizar los métodos de planificación, análisis, diseño, implementación y comprobación que se hayan adaptado a planificaciones apretadas en tiempo para el desarrollo de WebApps.

Seguridad. Dado que las WebApps están disponibles a través de1 acceso por red, es difícil, si no imposible, limitar la población de usuarios finales que pueden acceder a la aplicación. Con objeto de proteger el contenido confidencial y de proporcionar formas seguras de transmisión de datos, deberán implementarse fuertes  medidas de seguridad en toda la infraestructura que apoya una WebApp y dentro de la misma aplicación.

Estética. Una parte innegable del atractivo de una WebApp es su apariencia e interacción. Cuando se ha diseñado una aplicación con el fin de comercializarse o vender productos o ideas, la estética puede tener mucho que ver con el éxito del diseño técnico.

Las características generales destacadas anteriormente se aplican a todas las WebApps, pero con un grado diferente de influencia. Las categorías de aplicaciones que se enumeran a continuación son las más frecuentes en el trabajo de la Web:

informativa: se proporciona un contenido solo de lectura con navegación y enlaces simples.

descarga: un usuario descarga la información desde el servidor apropiado.

personalizable: el usuario personaliza el contenido a sus necesidades específicas.

interacción: la comunicación entre una comunidad de usuarios ocurre mediante un espacio chat (charla), tablones de anuncios o mensajería instantánea; entrada del usuario: la entrada basada en formularios es el mecanismo primario de la necesidad de comunicación.

orientada a transacciones: el usuario hace una solicitud (por ejemplo, la realización un pedido) que es cumplimentado por la WebApp;

orientado a servicios: la aplicación proporciona un servicio al usuario, por ejemplo, ayuda al usuario a determinar un pago de hipoteca.

portal: la aplicación canaliza al usuario llevándolo a otros contenidos o servicios Web fuera del dominio de la aplicación del portal.

acceso a bases de datos: el usuario consulta en una base de datos grande y extrae información.

almacenes de datos: el usuario hace una consulta en una colección de bases de datos grande y extrae información.

Las características y las categorías destacadas anteriormente en esta sección, y las categorías de aplicaciones representan los hechos reales para los ingenieros de la Web. La clave es vivir dentro de las restricciones impuestas por las características anteriores y aun así tener éxito en la elaboración de la WebApp.