Desarrollo de Aplicaciones Web Antología Versión 1.0 !"! # $ % & & '( ) & " "%* * +, . ' " !"! * +, "%* . / !" ! # % $ $ & ' ' & $ $ ( ) (' $ ( % # $ ) # ! $%&' # " # ! # # ' # # # # " # # # #" ( " ' * ! $%&' # # " # + ( , * ( , " / / # " 01 # # 677 8 1 5" 6 6 79 # 7 8 $%&' $%& # #" # " " 5 • • # ) 2 4 " . + 3 • $ #" 1 • , 6 4 4 * " + 6 # 1 . , # 4 . ) # *$%&' 3 1 3 + : 2 6 • • • • • ;0 # <= ( # # # # #" # 1 # 4 # 0 . # / @ ABA # C5 D % # E 0 #" .! * , # , # 0 E # 4 % 57)5 # ( 677 > 677 ( &)& ( " > ! 38 3 ? ( # = # > 4 . 8 " !# ) ( 1 $%&' #" 3 # ( 0 • • • • 8 , ) /+ # ' # # 4 ) ! # # # - 7 -7 - 7 - 7) # F * AAG+ H 6 # # D) 5 8B Figura 1.2 Internet I 0 4 # 4 # , ) # . # 4 # "# % # 4 4 # # ( ' # # @ # ( ( # I 677 - # 7 - 7) # ( # . 4 ( # # 2, # # % # . # # ( Figura 1.3 Intranet6 0 J ! 4 # # ( # 4 @ # # # 4 ! 1 ) 0 ) # 4 # 4 # ! ) ' ! # ! # # , ! : 4 # , ! # 2, ) Figura 1.4 Extranet 8 #@ # # ' ! # # 4 B J K 677 677 677 - . # 4 , #7 7 -7 ! ( ) ( ( ) #" ! # ( # #78GGA7G=7 ! # # # ( ' ! # # # ! ! # # ( " # ( # # ( 5 @ # # # # # # # # # 0 ) ) ) ! ) ) # 6 # # ( ! ) : 2.1 Tipos de sitios WEB 9 Los sitios se pueden clasificar de muchas maneras. Cada tipo de sitio tiene unas características y limitaciones propias. Una buena organización es vital para conseguir los objetivos del Sitio. Esta es una forma de clasificar los sitios: 1) Por su audiencia a) Públicos: Es un WebSite normal, una página dirigida al público general, sin restricciones de acceso en principio. b) Extranet: Son Sitios limitados por el tipo de usuarios que pueden acceder, por ejemplo los proveedores de una empresa determinada, o los clientes. c) Intranet: Son sitios cuyo acceso está restringido a una empresa u organización, normalmente funcionan dentro de redes privadas, aunque no siempre es así. 2) Por su dinamismo en sitios interactivos y sitios estáticos: a) Sitios Interactivos: El usuario puede influir sobre el contenido del sitio que variará en función de cada usuario y de los objetivos de éste. Normalmente, las páginas se generan cuando el usuario las solicita, personalizando la información que se le ofrece. b) Sitios estáticos: Los usuarios no pueden modificar o añadir nada al sitio, de cuyos contenidos se encargan exclusivamente sus diseñadores. 3) Por su apertura en Estructuras abiertas, cerradas y semicerradas: A 677 7# 7 # L 7 # L # 4 7 L L a) Estructura abierta: Todos los documentos disponen de su dirección y los usuarios pueden acceder a cualquier punto del WebSite. b) Estructura cerrada: Limita el acceso a unos pocos puntos de entrada (incluso a uno sólo). Un ejemplo sería un sitio que requiere un registro previo para entrar, el usuario siempre tendría que pasar primero por el registro antes de poder acceder al resto de la página. c) Estructura semicerrada: A medio camino entre ambas, obliga a los usuarios a acceder por unos puntos específicos, cómo por ejemplo sólo la página principal y las páginas de entrada a las secciones más importantes. 4) Por su profundidad a) Basada en el número de enlaces que hay que pulsar para llegar al contenido. En general los usuarios prefieren sitios poco profundos. Una buena regla a seguir es que el usuario no tenga que pulsar más de 3 enlaces para encontrar lo que busca. 5) Por sus objetivos a) Comerciales: Están creados para promocionar los negocios de una empresa. Su finalidad es económica. Su audiencia puede estar formada por clientes (actuales y potenciales), inversores (actuales y potenciales), empleados (actuales y potenciales) e incluso la competencia y los medios de comunicación. Podemos a su vez dividirlas en Corporativas (Informan sobre la empresa) y Promocionales (promocionan productos). b) Informativos: Su finalidad principal es distribuir información. La audiencia de este tipo de sitios depende del tipo de información que distribuyen. c) Ocio: Aunque normalmente son sitios con una finalidad económica, son un caso especial. No son sitios fáciles de crear ni de mantener y a veces siguen reglas propias; puesto que a veces es más importante sorprender al usuario con innovaciones que mantener la consistencia y la estructura. d) Navegación: Su finalidad es ayudar al usuario a encontrar lo que busca en Internet. Dentro de este grupo se sitúan los llamados portales, que intentan abarcar prácticamente todo dentro del propio sitio. e) Artísticos: Son un medio de expresión artística de su creador o creadores. Este tipo de sitios suele saltarse todas las convenciones y las únicas normas a aplicar son las que el propio artista o artistas deseen. f) Personales: Al igual que los anteriores, son un medio de expresión de su creador o creadores. Sus objetivos y su audiencia pueden ser de lo más variopinto. Dentro de este grupo puede haber de todo desde colecciones de fotos de la familia hasta tratados científicos de primer orden. 2.2 MEDIDAD DE SEGURIDAD DE SITIOS WEB10 Para muchas aplicaciones de negocios, como la publicidad y promociones simples, es probable que no se necesite tratar con precauciones de seguridad. Pero si se permite que los usuarios tengan acceso a datos delicados, se deberán tomar medidas para proteger a los datos. Debido a que cada vez son más las personas que desean transferir documentos e información de tarjetas de crédito o cualquier tipo de transmisión de datos en forma segura y sin el temor a los crackers y piratas. Las medidas de seguridad básicas a tener en cuenta son: G 677 # #7 I7 7 # 2.2.1 La encriptación de datos Es una técnica para ocultar datos de manera que sólo puedan ser vistos por aquellos que deben verlos. Consiste en reemplazar un mensaje enviado con un algoritmo difícil de adivinar. Los servidores seguros tratan de encriptar los datos entre el navegador y el servidor. En algún momento durante el ciclo de compras, después que los datos llegan al servidor seguro, el sistema debe desencriptar los datos. Aun si los datos son desencriptados sólo por un instante, la información podría ser interceptada por algún pirata. Crear un sistema en el que la información permanezca encriptada a lo largo del ciclo es prácticamente imposible. La configuración más segura es una que transmita la información al propietario de la empresa en formato encriptado, pase la información a una computadora que no esté en Internet y luego desencripte la información. Además si en una empresa se utiliza un mismo algoritmo para encriptar y desencripar datos, se necesitará que alguna tercera pieza de datos desencripte el código, que seria una clave. Esto sólo funcionará si tanto la persona transmisora como la parte receptora conocen la clave. Si la persona receptora no conoce la clave, tiene que enviar la clave a esa parte, y está puede ser interceptada. 2.2.2 Firma digital Ofrece un método de encriptación de datos que evita tener que compartir claves para leer mensajes. Es la técnica llamada encriptación de clave pública, donde cada usuario tiene dos claves: una clave pública y una clave privada. Los algoritmos de encriptación y desencriptación son adaptados de manera que sólo la clave pública puede desencriptar los datos encriptados por la clave privada. Por consiguiente, puede transmitir con libertad la clave pública al mundo. 2.2.3 Creación de un sitio seguro Las ventajas de crear un sistema seguro antes de ser pirateado deben ser obvias. La prevención es la mejor medicina y esto se aplica también ala seguridad de las computadoras. Se debe mantener la seguridad de los archivos de datos de tal forma que solo las personas correctas puedan verlos. Esto es crucial para los siguientes tipos de datos y archivos: contraseñas de usuarios, archivos de facturación, registros de sistema y de usuarios, información de tarjetas de créditos, información confinada de sistemas remotos, compiladores, herramientas de administración. Firewalls, wrappers y proxies Los firewalls, wrappers y proxies ofrecen una buena línea de defensa para los propietarios de servidores Web y administradores de sistemas. Los firewalls pueden ser software o hardware que protege los puertos y evita que los piratas penetren al sistema. Los firewalls permiten que tengan acceso al sistema sólo ciertos nombres de dominio confiables. Los wrappers se encuentran disponibles en CERT al igual que en otros archivos en Internet. Los wrappers se ejecutan como una capa de software alrededor de su otro software. Un usuario que se conecta a FTP primero entraría en contacto con el wrapper, el cual luego habilitaría al FTP. El usuario no sabe que existe el wrapper y no puede detectar ninguna diferencia en el sistema. Los wrappers son interesantes porque son flexibles. Pueden actuar como firewalls y en realidad pueden rechazar usuarios con base en sus nombres de usuarios al igual que en sus nombres de dominios. Además permite crear callejones sin salida que permiten atrapar piratas. El modo proxy es un método permite ocultar datos por medio de reenrutamiento de las solicitudes. Es útil para usuarios que están detrás de una firewall. Los usuarios establecen una dirección proxy de su navegador para que apunte hacia su servidor Web. El servidor Web maneja entonces la dirección real de los datos hacia el mundo exterior. Esto reduce la dirección que el usuario está tomando cuando deja su sistema, permitiéndole al usuario enrutar los datos los datos a través de los agujeros en sus propias firewalls. La otra ventaja es que las solicitudes pueden ser filtradas por el software del servidor. Al filtrar la información, puede restringir el contenido y rastrear el uso al igual que modificar la información en ese instante. Los servidores proxy también pueden ser dirigidos a otros servidores proxy, lo cual les permite ocultar datos en forma efectiva. Otra ventaja de los servidores proxy es que los servicios como FTP, Telnet, Gopher, NetnNews, etc., pueden ser erutados a servidores diferentes. Esto le permite distribuir diversas cargas de servidor Web a diferentes servidores físicos. Además de beneficiarse con el ocultamiento de los datos, ser reduce la carga del servidor. 2.3 Desarrollo de aplicaciones El desarrollo de aplicaciones web involucra decisiones no triviales de diseño e implementación que inevitablemente influyen en todo el proceso de desarrollo, afectando la división de tareas. Los problemas involucrados, como el diseño del modelo del dominio y la construcción de la interfaz de usuario, tienen requerimientos disjuntos que deben ser tratados por separado. El alcance de la aplicación y el tipo de usuarios a los que estará dirigida son consideraciones tan importantes como las tecnologías elegidas para realizar la implementación. Así como las tecnologías pueden limitar la funcionalidad de la aplicación, decisiones de diseño equivocadas también pueden reducir su capacidad de extensión y reusabilidad. Es por ello que el uso de una metodología de diseño y de tecnologías que se adapten naturalmente a ésta, son de vital importancia para el desarrollo de aplicaciones complejas. En la actualidad existen tecnologías ampliamente usadas para el desarrollo de aplicaciones web, pero muchas de ellas obligan al desarrollador a mezclar aspectos conceptuales y de presentación. Esto sucede principalmente con aquellas tecnologías no basadas en objetos. La elección de tecnologías complejas demora el proceso e incrementa los costos, pero en ocasiones permite adecuarse a metodologías de diseño más fácilmente. Como es el caso de las tecnologías orientadas a objetos, las cuales tienden a demorar el desarrollo en etapas tempranas. El tiempo de desarrollo en la actualidad es crítico, tanto por razones de marketing como por límites en el presupuesto y los recursos, pero la adopción de estas tecnologías hace que el mantenimiento se transforme en una actividad más simple, la división en capas sea una tarea natural del desarrollo y el tiempo invertido en el diseño facilite el trabajo necesario para el resto de las actividades. 2.4 Aplicaciones web y la importancia del desarrollo en capas Las aplicaciones hipermedia han evolucionado en los últimos años y se han concentrado mayormente en la web. Las antiguas aplicaciones distribuidas en cd’s dieron lugar a aplicaciones dinámicas, de constante actualización e incluso personalizables, capaces de adaptarse a los tipos de usuarios y en casos avanzados, a cada usuario en particular. Estas características encuentran el medio ideal en la web, ya que de otra forma sería costoso su mantenimiento y evolución. La complejidad del desarrollo ocurre a diferentes niveles: dominios de aplicación sofisticados (financieros, médicos, geográficos, etc.); la necesidad de proveer acceso de navegación simple a grandes cantidades de datos multimedia, y por último la aparición de nuevos dispositivos para los cuales se deben construir interfaces web fáciles de usar. Esta complejidad en los desarrollos de software sólo puede ser alcanzada mediante la separación de los asuntos de modelización en forma clara y modular. La justificación de tanto trabajo puede encontrarse en cualquier aplicación que requiera navegación: en términos de programación orientada a objetos, si los elementos por los que se navega son los del diseño conceptual se estaría mezclando la funcionalidad hipermedia con el comportamiento propio del objeto. Por otro lado, si los nodos de la red de navegación tienen la capacidad de definir su apariencia, se estaría limitando la extensión de la aplicación para ofrecer nuevas presentaciones del mismo elemento y eventualmente se estaría dificultando la personalización de la interfaz. Es necesario, entonces, mantener separadas las distintas decisiones de diseño según su naturaleza (conceptual, navegacional, de interfaz) y aplicar las tecnologías adecuadas a cada capa en el proceso de implementación. 2.5 OOHDM11 Las metodologías tradicionales de ingeniería de software, o las metodologías para sistemas de desarrollo de información, no contienen una buena abstracción capaz de facilitar la tarea de especificar aplicaciones hipermedia. El tamaño, la complejidad y el número de aplicaciones crecen en forma acelerada en la actualidad, por lo cual una metodología de diseño sistemática es necesaria para disminuir la complejidad y admitir evolución y reusabilidad. Producir aplicaciones en las cuales el usuario pueda aprovechar el potencial del paradigma de la navegación de sitios web, mientras ejecuta transacciones sobre bases de información, es una tarea muy difícil de lograr. En primer lugar, la navegación posee algunos problemas. Una estructura de navegación robusta es una de las claves del éxito en las aplicaciones hipermedia. Si el usuario entiende dónde puede ir y cómo llegar al lugar deseado, es una buena señal de que la aplicación ha sido bien diseñada. Construir la interfaz de una aplicación web es también una tarea compleja; no sólo se necesita especificar cuáles son los objetos de la interfaz que deberían ser implementados, sino también la manera en la cual estos objetos interactuarán con el resto de la aplicación. En hipermedia existen requerimientos que deben ser satisfechos en un entorno de desarrollo unificado. Por un lado, la navegación y el comportamiento funcional de la aplicación deberían ser integrados. Por otro lado, durante el proceso de diseño se debería poder desacoplar las decisiones de diseño relacionadas con la estructura navegacional de la aplicación, de aquellas relacionadas con el modelo del dominio. OOHDM propone el desarrollo de aplicaciones hipermedia a través de un proceso compuesto por cuatro etapas: diseño conceptual, diseño navegacional, diseño de interfaces abstractas e implementación. 2.5.1 Diseño Conceptual En esta actividad se construye un esquema conceptual representado por los objetos del dominio, las relaciones y colaboraciones existentes establecidas entre ellos. En las aplicaciones hipermedia convencionales, cuyos componentes de hipermedia no son modificados durante la ejecución, se podría usar un modelo de datos semántico estructural (como el modelo de entidades y relaciones). De este modo, en los casos en que la información base pueda cambiar dinámicamente o se intenten ejecutar cálculos complejos, se necesitará enriquecer el comportamiento del modelo de objetos. En OOHDM, el esquema conceptual está construido por clases, relaciones y subsistemas. Las clases son descritas como en los modelos orientados a objetos tradicionales. Sin embargo, los atributos pueden ser de múltiples tipos para representar perspectivas diferentes de las mismas entidades del mundo real. ( M1 # L& , 2 Se usa notación UML (Lenguaje de Modelado Unificado) y tarjetas de clases y relaciones similares a las tarjetas CRC (Clase Responsabilidad Colaboración). El esquema de las clases consiste en un conjunto de clases conectadas por relaciones. Los objetos son instancias de las clases. Las clases son usadas durante el diseño navegacional para derivar nodos, y las relaciones que son usadas para construir enlaces. 2.5.2 Diseño Navegacional La primera generación de aplicaciones web fue pensada para realizar navegación a través del espacio de información, utilizando un simple modelo de datos de hipermedia. En OOHDM, la navegación es considerada un paso crítico en el diseño aplicaciones. Un modelo navegacional es construido como una vista sobre un diseño conceptual, admitiendo la construcción de modelos diferentes de acuerdo con los diferentes perfiles de usuarios. Cada modelo navegacional provee una vista subjetiva del diseño conceptual. El diseño de navegación es expresado en dos esquemas: el esquema de clases navegacionales y el esquema de contextos navegacionales. En OOHDM existe un conjunto de tipos predefinidos de clases navegacionales: nodos, enlaces y estructuras de acceso. La semántica de los nodos y los enlaces son las tradicionales de las aplicaciones hipermedia, y las estructuras de acceso, tales como índices o recorridos guiados, representan los posibles caminos de acceso a los nodos. La principal estructura primitiva del espacio navegacional es la noción de contexto navegacional. Un contexto navegacional es un conjunto de nodos, enlaces, clases de contextos, y otros contextos navegacionales (contextos anidados). Pueden ser definidos por comprensión o extensión, o por enumeración de sus miembros. Los contextos navegacionales juegan un rol similar a las colecciones y fueron inspirados sobre el concepto de contextos anidados. Organizan el espacio navegacional en conjuntos convenientes que pueden ser recorridos en un orden particular y que deberían ser definidos como caminos para ayudar al usuario a lograr la tarea deseada. Los nodos son enriquecidos con un conjunto de clases especiales que permiten de un nodo observar y presentar atributos (incluidos las anclas), así como métodos (comportamiento) cuando se navega en un particular contexto. 2.5.3 Diseño de Interfaz Abstracta Una vez que las estructuras navegacionales son definidas, se deben especificar los aspectos de interfaz. Esto significa definir la forma en la cual los objetos navegacionales pueden aparecer, cómo los objetos de interfaz activarán la navegación y el resto de la funcionalidad de la aplicación, qué transformaciones de la interfaz son pertinentes y cuándo es necesario realizarlas. Una clara separación entre diseño navegacional y diseño de interfaz abstracta permite construir diferentes interfaces para el mismo modelo navegacional, dejando un alto grado de independencia de la tecnología de interfaz de usuario. El aspecto de la interfaz de usuario de aplicaciones interactivas (en particular las aplicaciones web) es un punto crítico en el desarrollo que las modernas metodologías tienden a descuidar. En OOHDM se utiliza el diseño de interfaz abstracta para describir la interfaz del usuario de la aplicación de hipermedia. El modelo de interfaz ADVs (Vista de Datos Abstracta) especifica la organización y comportamiento de la interfaz, pero la apariencia física real o de los atributos, y la disposición de las propiedades de las ADVs en la pantalla real son hechas en la fase de implementación. 2.5.4 Implementación En esta fase, el diseñador debe implementar el diseño. Hasta ahora, todos los modelos fueron construidos en forma independiente de la plataforma de implementación; en esta fase se toma en cuenta el entorno particular en el cual se va a correr la aplicación. Al llegar a esta fase, el primer paso que debe realizar el diseñador es definir los ítems de información que son parte del dominio del problema. Debe identificar también, cómo son organizados los ítems de acuerdo con el perfil del usuario y su tarea; decidir qué interfaz debería ver y cómo debería comportarse. A fin de implementar todo en un entorno web, el diseñador debe decidir además qué información debe ser almacenada. 2.6 Ejemplo de una implementación OOHDM En este ejemplo se describirán las etapas de desarrollo de una aplicación web simple, siguiendo la metodología OOHDM. En cada capa de diseño, la implementación correspondiente se basa en diferentes tecnologías, elegidas con el propósito de minimizar la dificultad del desarrollo y aprovechar al máximo las virtudes de la metodología. 2.6.1 Capa Conceptual En OOHDM, el desarrollo se inicia diseñando la capa conceptual, siendo el principal objetivo de esta etapa capturar los conceptos involucrados en el dominio de la aplicación y describirlos en detalle, haciendo uso de diagramas que permitan expresar con claridad el comportamiento, la estructura y las relaciones entre dichos conceptos. La Programación Orientada a Objetos facilita el traslado del diseño conceptual a la implementación, proveyendo al programador con herramientas que permiten reducir la distancia entre el problema del mundo real y la programación de la solución en la computadora. El modelo de objetos del ejemplo consta de las entidades básicas de un dominio específico: un comercio de venta de productos B2C (Negocio a Consumidor). En este dominio, entidades como producto, categoría de productos, carro de compras, usuario, venta, se interrelacionan para responder a la navegación del usuario por la aplicación y a sus actividades transaccionales. Todas las entidades mencionadas se construyen a partir de información persistente, propiedad mantenida por la empresa en forma directa a través de un DBA (Administrador de Bases de Datos) o simplemente aprovechando una funcionalidad incorporada de la aplicación que permita manipular la base de datos. El análisis anterior de las entidades del dominio permite afirmar que dichas clases comparten (al menos) el comportamiento correspondiente a la interfaz con la capa de persistencia: todas las entidades fuertes son capaces de construirse a partir de identificadores, coincidentes con las claves primarias de las tablas correspondientes de la base de datos. Las clases del diseño conceptual que representen a estas entidades podrán obtener sus atributos al iniciarse y actualizar los cambios cuando sea necesario (realizando eventualmente algún tipo de almacenamiento temporal para mejorar la eficiencia). La consistencia de la información queda asegurada, entonces, por el comportamiento de los objetos del modelo. Figura 1.5: Paquete de interfaz con la base de datos, dentro del Diseño Conceptual La clase abstracta que define el comportamiento básico de las entidades del modelo y concentra la lógica de interacción con la base de datos será denominada EntidadAbstracta. Para cumplir con los objetivos propuestos, esta clase debe ser capaz de crear una conexión con la base de datos, ejecutar consultas y retornar los resultados para ser procesados. Por una cuestión de eficiencia, la creación de conexiones a la base de datos podría ser delegada a un singleton, es decir, una clase capaz de controlar su instanciación para retornar siempre la misma instancia en reiteradas llamadas a su constructor. Una clase con estas características podría ser instanciada por EntidadAbstracta para luego solicitarle una conexión. Sólo la información más importante y de menor volumen es cargada desde la base de datos en el momento de la instanciación. La información restante puede ser cargada bajo demanda, a partir de un eventual requerimiento de la aplicación. Para ilustrar esta idea con claridad puede considerarse cargar los siguientes atributos en la instanciación de un Producto: descripción, categoría, cantidad disponible y precio. En algún momento de la ejecución, la aplicación puede requerir los productos relacionados de un determinado producto BD Subconjunto de clases del diseño conceptual que interactúan con la base de datos Diseño Conceptual Jerarquía de entidades Resto del modelo (por ejemplo, el usuario podría solicitar una lista de productos relacionados con el producto televisor, tales como video grabadora, filmadora, mesa para televisor, etc.); dado el volumen de esta información y lo esporádico de su requerimiento, se sugiere entonces consultar a la base de datos para obtener esta información sólo cuando es requerida. Notar que la conexión a la base usada en cada consulta es siempre la solicitada en el momento de la instanciación, evitando con esto creaciones y destrucciones reiteradas de conexiones a la base de datos. Un modelo conceptual de estas características, obliga a considerar a todas las entidades del dominio como subclases de EntidadAbstracta (al menos todas aquellas entidades que se mantienen en la base de datos). Esta decisión de diseño puede refinarse aún más para evitar al máximo la incorporación de comportamiento de persistencia en las clases del dominio. Para alcanzar este objetivo puede utilizarse interfaces (mediante las cuales se pueden establecer contratos entre clases, permitiendo así ligar a las clases del dominio con las encargadas de interactuar con la base de datos) y/o un modelo paralelo de wrappers que encapsulen a las clases del dominio (estos wrappers pueden encargarse directamente de la persistencia o interactuar con otras clases para factorizar código, dejando en cada wrapper el comportamiento específico requerido por la entidad encapsulada). Es importante destacar que el diseño conceptual puede estar compuesto de otras clases que por su naturaleza no puedan considerarse subclases de EntidadAbstracta. Estos casos son simplemente colaboradores de entidades concretas, clases requeridas para realizar alguna actividad específica y de corta vida útil, o algunos casos de entidades débiles desde el punto de vista de diseño entidad-relación. Considérese como ejemplo la información relacionada con la navegación del usuario en una determinada sesión, irrelevante para otras sesiones e incluso para el resto de la aplicación. En este caso, se requiere una clase para contener la información mencionada y el comportamiento para manipularla, pero no requiere considerar la persistencia dentro de su funcionalidad. Figura 1.6: Instanciación de una subclase concreta de EntidadAbstracta 2.6.2 Capa Navegacional La capa navegacional se compone de objetos construidos a partir de objetos conceptuales, y constituyen en general los elementos canónicos de las aplicaciones hipermedia tradicionales: nodos, enlaces, anclas y estructuras de acceso. Sin embargo, estas clases pueden extender el comportamiento característico para funcionar como adaptadores de los objetos conceptuales y delegar así operaciones específicas del dominio. Entonces, los objetos navegacionales pueden actuar como observadores, para construir vistas de objetos conceptuales, y como adaptadores, para extender la actividad navegacional de un nodo y poder aprovechar el comportamiento conceptual del objeto adaptado. Estas dos perspectivas pueden implementarse aprovechando las virtudes inherentes de diferentes tecnologías: JSP para observar y Servlets para adaptar. Figura 1.7: Construcción de un nodo de la capa navegacional Como puede observarse, la cadena se inicia con un requerimiento del usuario que navega por la aplicación. Al acceder a un enlace, una página JSP es invocada para construir una página XML. En principio, el archivo XML generado puede ser útil para transferir información entre servidores cooperativos, o simplemente entre un cliente y un servidor con un esquema tradicional. En cualquier caso, la portabilidad brindada por las características simples de XML hacen posible una transferencia transparente incluso entre plataformas completamente heterogéneas. Antes de abordar la implementación de la capa de presentación es necesario describir la segunda perspectiva de los nodos, vistos como adaptadores de objetos conceptuales. Un ejemplo donde se observa claramente este tipo de nodos es el carro de compras. Para mostrar el contenido del carro de compras del usuario es necesario instanciar el objeto conceptual CarroDeCompras (notar que el identificador del usuario que navega la aplicación y solicita acceder a su carro de compras es el único dato que se necesita para invocar al constructor de dicha entidad). De este modo, el nodo construido a partir de esta información no sólo concentra los datos de las compras sino que además ofrece un menú de operaciones para manipular el carro de compras, como borrar un elemento, cambiar la cantidad solicitada de un producto, vaciar el carro, finalizar la compra. Todas estas operaciones no son responsabilidad del nodo, sino que son realizadas por el objeto conceptual. Entonces, delegar responsabilidad es lo único que debe hacer el nodo navegacional en este caso: la actividad delegada continúa dentro de un servlet y finalmente es el servlet quien se encarga de redireccionar la navegación a una página JSP para eventualmente mostrar un resultado. Los servlets son una herramienta muy útil para realizar actividades del lado del servidor y retornar información al cliente para informarle sobre el trabajo realizado o para solicitarle parámetros y retomar alguna operación. Continuando con el carro de compras, en caso que la operación elegida por el usuario sea vaciar el contenido (entre otras operaciones que puede seleccionar), una transacción debe ejecutarse a cargo del objeto CarroDeCompras correspondiente, a fin de modificar la base de datos satisfaciendo el deseo del usuario. Dado que este deseo es manifestado a través de un requerimiento (por ejemplo, realizando un get a través de una URL, o un post a través de un formulario HTML) la acción debe continuar en algún sector de la aplicación, sin necesidad de mostrar información durante el proceso, al menos en este caso puntual. Entonces, puede construirse un paquete de servlets capaces de realizar operaciones específicas e incluso agruparse en jerarquías para aprovechar la herencia de comportamiento. A manera de ejemplo, se puede considerar la jerarquía de servlets de la siguiente figura, diseñados para servir acciones específicas referidas al CarroDeCompras. Figura 1.8: Jerarquía de servlets para administrar el carro de compras El servlet abstracto de la aplicación es una clase que podría ser útil si se tiene comportamiento común a todos los servlets construidos para una aplicación específica. Luego, el servlet abstracto CarroDeComprasServlet define el comportamiento y la estructura de los servlets que encapsulan la lógica de una operación determinada sobre el carro de compras. No es necesario construir una subclase por operación concreta; varias operaciones pueden encapsularse en una única clase y parametrizarse adecuadamente si son semejantes. AgregarProductoServlet servlet abstracto de la aplicación EliminarProductoServlet VaciarCarroServlet inalizarCompraServlet HttpServlet CarroDeComprasServlet En este escenario, cada subclase concreta de servlet tiene la responsabilidad de ejecutar una operación y retornar al cliente mostrando una página fija o calculada dinámicamente en función del resultado de la operación. Un ejemplo que puede considerarse para cualquier actividad es alternativa entre un resultado exitoso o uno erróneo, de la operación ejecutada. En el primer caso, la navegación podría continuar por una página JSP capaz de ilustrar la forma de proseguir la actividad, o de mostrar los resultados de la misma. En el segundo caso, la navegación se vería interrumpida por una página JSP que informara sobre el error producido y eventualmente solicitara la corrección de parámetros, u ofreciera reintentar la operación. 2.6.3 Capa de Interfaz Abstracta Tanto un nodo actuando como observador como un nodo actuando como adaptador, finalmente continúa por mostrar cierta información y para ello necesita definir la forma de presentación mediante la cual dicha información será visualizada en la interfaz. Para ello se incorporan las dos últimas tecnologías a las que se hará mención en este artículo: XSL y un mecanismo de análisis sintáctico para obtener una página HTML en función de un par de documentos XML/XSL. Las páginas XSL, ubicadas también del lado del servidor, definirán la apariencia de los nodos que se generaron en formato XML. Cada página XSL define la forma en que los elementos del XML asociados serán mostrados, haciendo uso de código HTML y eventualmente CSS, para dar el formato deseado a las páginas finales. Enlaces y estructuras de acceso también son presentados conforme con los estilos adoptados para este tipo de información navegacional. El vínculo entre un XML y su apariencia puede establecerse en forma explícita, con una etiqueta especial situada en la primera línea del archivo XML, o bien podría ser calculado en forma dinámica para satisfacer demandas de personalización. En cualquier caso, retornar al cliente con un archivo XML que haga referencia a un archivo XSL ubicado en el servidor tiene al menos dos inconvenientes: genera un tráfico de ida y vuelta innecesario, ya que podría evitarse enviando directamente el código HTML al cliente, y puede requerir características especiales en el explorador del cliente que pueden privarlo de visualizar la página correctamente. Figura 1.9: Generación de un documento HTML a partir de una fuente XML + XSL El lenguaje XSLT (Transformaciones XSL40) se utiliza para componer hojas de estilo XSL. Estos documentos contienen instrucciones que mediante el uso de Xalan-Java, por ejemplo, sirven para llevar a cabo las transformaciones y producir un documento de salida, una secuencia de caracteres o de bytes, un DOM (Modelo de Objetos de Documento), etc. En el caso particular mencionado anteriormente, se desea obtener un documento de salida con formato HTML a partir de un par de documentos XML / XSL. !" XHTML es una reformulación de HTML 4.0 y XML 1.0. HTML fué concebido como un lenguaje para el intercambio de documentos científicos y técnicos. Siendo que HTML es una aplicación SGML, se valió de un reducido grupo de etiquetas para la formulación de documentos relativamente simples. HTML se popularizó rápidamente y superó las expectativas que motivaron su creación. La flexibilidad de HTML y la constante invención de nuevos elementos para ser usados con este lenguaje, ha creado el desorden y falta de compatibilidad con algunos navegadores, cosa que con su reformulación en el XHTML, se pretende corregir. Por su lado, XML es un simple y muy flexible formato de texto derivado de SGML diseñado especialmente para documentos web. Permite a los desarrolladores crear sus propias etiquetas. A diferencia del HTML, XML es muy estricto en su estructura. Más que por el formato, XML “se preocupa” de la estructura. En HTML, es posible visualizar documentos mal estructurados, etiquetas mal anidadas o inconclusas, en XML si se abre una etiqueta, debe cerrarse. XML es ampliamente usado para estructurar datos (inventarios, catálogos, por ejemplo). Una de sus ventajas es la capacidad que provee al permitir la transferencia estructurada de información que puede ser utilizada por otras aplicaciones. Así que XHTML reune la capacidad de formato de HTML y esta se consolida con la formalidad del XML (y sus reglas) a la hora de estructurar documentos para la portación de datos. Esto le permite a la vez, ser manejado y validado por cualquier herramienta estándar. Nos permite echar mano de la modularización. Esta reformulación nos permite desarrollar sitios que podrán ser “vistos” por personas discapacitadas, ya que existen agentes de usuario que pasan la información (obviamente debido a la bien formada estructura) a formatos como Braile. Al ser una recomendación y un estándar, es necesario observar que nuestros documentos XHTML deben respetar ciertas reglas básicas : ! " Cuando se escriba un documento es muy común que erroneamente se cierren elementos de forma inadecuada, por ejemplo: <p><i>El <b>Veloz murcielago hindú</b> comía feliz cardillo y caña</p></i> En este ejemplo, se ha cerrado la etiqueta de párrafo antes de lo debido, en algunos navegadores esto pasará desapercibido, sin embargo la forma correcta es la siguiente: <p><i>El <b>Veloz murcielago hindú</b> comía feliz cardillo y caña</i></p> # Lo cual quiere decir que losdocumentos deben tener al menos la siguiente estructura: <html> <head> ... </head> <body> ... </body> </html> $ ! % Al ser XHTML una aplicación XML, está hace diferencia entre mayúsculas y minúsculas, por lo que <BODY> y <body> son dos cosas muy diferentes En versiones anteriores del HTML era posible dejar etiquetas sin cerrar, incluso algunos autores te decía que no era necesario cerrar tal o cual etiqueta, en XHTML es obligatorio que todas las etiquetas sean cerradas, por lo que: <p>Esto es un párrafo Es incorrecto, en su lugar debe ser: <p>Esto es un párrafo</p> El cual tiene su etiqueta de cierre correspondiente. en los casos donde las etiquetas son unarias como <br>, <hr>, <img> y otras, el cierre se da dentro de ella misma, terminando la etiqueta con />, por ejemplo: Este texto hace un <br /><b>Salto de Línea</b> y después pone una línea abajo <br /><hr /> & % Por lo antes mencionado en el punto 3, todos los nombres de atributos para una etiqueta deben ir en minúsculas, por ejemplo: <img SRC="imagen.gif"> es inválido, en su lugar <img src="imagen.gif" /> sería lo correcto ' ( Esto para evitar confusiones, por ejemplo: <div align=center> es incorrecto, en su lugar use <div align="center"> ) * " En XHTML el atributo name está descontinuado, en su lugar use el atributo id: <input type="text" id="txt_nombre" size="25" /> Sólo en casos de compatibilidad con navegadores antiguos debe usarse el atributo name, si se está usando XHTML transicional, el atributo name es permitido. +,- ./ Todos los documentos XHTML válidos deben llevar un elemento llamado DOCTYPE, el cual no es parte del documento en sí, sino que define el tipo de DTD (Document Type Definition o Definición de tipo de documento) a emplear en los documentos, es obligatorio y puede ser uno de estos tres: • • • XHTML 1.0 Strict: Se usa cuando se desea utilizar al 100% XHTML, su nombre lo dice bien claro, es XHTML estricto, la declaración del mismo es como sigue: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1strict.dtd"> HTML 1.0 Transitional: Es el más usado ya que permite manejar elementos de XHTML y HTML 4.01, además de que se debe usar cuando el navegador no soporta correctamente CSS, su declaración es la que sigue:<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> XHTML 1.0 Frameset: Se debe usar cuando se manejan frames, su declaración es la siguiente: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd"> Comprender los elementos del lenguaje XHTML y hojas de estilo. % * $ # $ 0 $ ' & # & 1 & ( 2 1 & 2 34 ' & / 5 ' & & 8 N " 677 # 6 7# 7 #7 - H 7 H H H H H # & & & & & ' / & / 6 6 • "%* • 7 & & + • . 7 • 9 ( • : .+" • . ++ + 8 & 6 • • • • • ; • • * + $ # *!* !"! & 1 !"! !"! <0 ! / > > >' 2 & "%* !"! 9 =/ =/ = & .+! + !"!=? > =?/ > = > ! "%* =()>=()> =@ / / A! !"!= >AB 1C DEBC =3EBC FF2 G / A A C A= >AB H @> =? > =?/ > ' !"! 6 & 3E C I! E 9 K J 5 !"!A & & & 5 5 !"! ' !"! C % & 5 =/ > =/ > = >' !"!=? > =?/ > = > =@ / C D 3B C D L LMB C D A" * AB / C A= >A C A= >A C B @> =? > =?/ > '# 4 & & N . 8 B ' & 8 F Q S ? U FF QQ ' =/ > =/ > = >' =?/ > = > =@ / C D TB C D LB / C FC / C QC / C SC / C ?C C FFB / C A= C QQB / C A= @> =? > =?/ > DD 0 VD $ =* >* =D * >D * O ' + ) * $ * + ) -FP RQJ PSL M?T RU4 3 C FF 3 C QQ 6 !"!=? A= A= A= A= > >AB >AB >AB >AB >AB >AB O ' $ C DD C C C C VD C C C & C =C C & & C >C C & C =D C C C >D C C 6 C C & & C C / + =@ / 1 G + 2 H G + H @> & ! & / C A A & & L 3 A A & 4 ( + =@ / / 1 G / 2 H @> * & / =/ > =/ > = >' =?/ > = > 0 =()> =@ / !"!=? > C DEB / 1C =3E2 G / A' C FFB H @> : =()> =? > =?/ > A C A= >AB + ' ' & & & : ' / =@ / O 1 3 4 2 G 3B 4B LB MB N N B H @> * $ !"! # # S S S & S 1 2 O 1 5 2 $ 1 3 1 2 $ 4 2 : # S / S S 1 2 ' 3 & 1 N 1 42 ( 3 4 4 # 2 ) # =/ > =/ > = >' !"!=? > =?/ > = > =@ / / 1A34LM-A2 A= >AB C D 1A A A' A2B 1C DEBC WC XBC FF2 / C WC X A= >AB C D 1AT#- D U = >A TS-2B / C A= >AB / 1A$ 1 / 1A Y Y A2 DD A A2 / A0 = >= >AB / 1A( / N 1A AA A AK @> =? > =?/ > ' ' . 3 3 4 A J L2 A= >= >AB A A A2 A= >= >AB / A2 A= >AB !"! 8 Z & !"! & 8 & =/ > =/ > = >' !"!=? > =?/ > = > ="3>' =?"3> 0 6 =: )* . %0 ODA / A *'%" $DA<'%A> =0O!K% %[!'DA # A O.*'DA A>=()> =0O!K% %[!'DA A 9. K'DA' A> =?: )*> =? > / =?/ > ! / CN! +%WX * / ' <'% CN<'%WX & 8 ! +% / & 8 *'%" $ 8 <'% & ! +% 8 8 <'% +%$0 =/ > =/ > = >' !"!=? > =?/ > = > ="3>' =?"3> =: )* . %0 ODA 4 / A *'%" $DA<'%A> 0 6=0O!K% %[!'DA # A O.*'DA 0 6=0O!K% %[!'DA # A O.*'DA =0O!K% %[!'DA A 9. K'DA' A> =?: )*> =? > =?/ > =/ > =/ > = >' !"!=? > =?/ > = > ="3>' =?"3> =: )* . %0 ODA 4 / A *'%" $DA! +%A> 0 6=0O!K% %[!'DA # A O.*'DA 0 6=0O!K% %[!'DA # A O.*'DA =0O!K% %[!'DA A 9. K'DA' A> =?: )*> =? > =?/ > =/ > =/ > = >' !"!=? > =?/ > = > & : )* K) 8 A>=()> A>=()> A>=()> A>=()> ! +% ="3>' ' & A CN<'%W\ ' & A CN! +%W\ = > =? > =?/ > / =?"3> 6 =@ / / CN<'%W\ <'% \X A \X @>= > / ! +% 6 =@ / / CN! +%W\ \X A \X @> ' !"! 12 =@ / 1 @> # 2B ' # # '# # =@ / 1 @> # 1 2 & Z # 2B ' ) Q% 6 : 6 Q 6 & . & 6 • * • * & • ' " , +, + * & • • + - ( ( . ( / % & ' # & 8 K 3L O . / 3M 00+ 3- & & 6 % # . 00+ *,0%" %0+ , - ( - 1 2 4$2 ' & '# $ 8 6 • • • = E I 677 677 677 $( 7$( !$ #7 7 7 O.%09. 0 3 / . /56% $( 3P 1 $ 2 $( 8 & . 8 # 6 • • • • • • • • • +, + . + 0 : ?$Q0+.* 0O $ + ] K $( =@ ^ C $+O A N D ^& C& A 1A / D ^ / / / 1 N /N C D N C D N 1AC C A A :) * / & N # 1C C& / 1C 1C A2B AB 2B 22G 32B 1C Y A2B 42B H B J 677 677 ( #7 #7 ( 7 7 7 6 A A A / D A+' ' % ^ C 3R !" 7 7A 7 ! # A N 1C 2B @> K $( + + + + 3T ^ 6 B < % #B $ B B . 3 G ! G * 1 WX 2 G $ D 1A$+OD+.*! 'N0+.*A2B $ 12B $ $ $ D$ 12B % # D A+' ' % S :) * O.%0 OAB $ ) D$ '# ) 12B ) D$ ) : 1 1 A6A 2B D EB = + O B B FF 2 G D$ ) < O 1 O F A6A 2B 1 2B H 12B / 1$ ) ) 122 G 1 A6A 2B K 677 ( #7 7 7 7 1 :> ! # 1 D EB = B FF2 G + D$ ) < + 1 F A6A2B 1 2B H 12B H $ ) $ $ 12B $ 12B 12B H H H 756% 7$( 17 $ 7 2 • • • • • • • • ! • " # • • • • ! ' 7$( 6/ 6?? K A $ 677 ? 7$( $ A ? * 6 6 N B * ( #7 73> L:> ? 3J +, + 1 DSSSB 1A ? DSSSA2B 6 L1O'L1 6 N L A 2B # 6 ?? A ?SS S S S? +& + / 1 2 4EER A A $ " A [ & SB +& + 1+ B D . / G 2G WX G O ?? 1A 7 $ A2 B / A D$ 6 * 6+, N+')9')B 1A: + 1 D B D" [ A2B _ A2B 12B ?? / ! 1A 1A D$ 2B D ! A A A2B A A" [ * + A2B 1A 12B 6 1A+ 6+, N+')9')A _ A2B 12B H / 1'# 2G 1A'# + 6 AF * 122B H H H K D G ?? + 8G 677 4E 7$( ! # / 7$( O #7 B DA 7 $ 7 : # AB 6 O ?? + + + + B + + 1 O 2B / D A34R E E 3AB D A3-43AB AB 6 6 / 6`A F O O DA DA DA DA D$ * H /1 O : '# ?? / H / 1+, '# 2G ?? / H O F A6A F 1 2B 2G $ ( ) $ 0 1 8 '$( +, + # * +, 2 (' $ ' & O %.6 . / / !"! * & # . % 0 F A6A F AB AB ' ( O + / & / K "%* / 6 = DA *!*) 3 A / DA*/ "A> ' 6 = DA # A # /DA3EA DA3EA DA ' 6 = DA # A # /DA3EA DA3EA DA ' % 6 = DA # A # /DA3EA DA3EA DA = >= >= > = DA A DA'O90.) $.% +A> DA A DA( )).) $.% +A> =? > K & & !" $A> = >= > A> = >= > A> = >= > *!* & 6 ' / / 5 # / & 1A A2B & 8 =@ 9 ) 3 9 : C+ CK C! C( C D / B DA & AB D AAB $ $ D A: # D &N AB 1C+ CK ' C D &N N 1C( $ $ C! A2B C 2 # 2B @> ' & / *!*) 3 =@ / ^ .a.$0* + ' OK'9 )'<0+%) C 3DC B C 4DC B C LDC B & 1A / A2B C D & N& 1A0O+')% 0O% 1b b bO b$ b b% b2 9. K'+ 1\\ \C 3\ \C 4\ \C L\2A2B 1C DD & N& 1AC A22 G / A) . AB H G / A AB H @> % b 1A' 6 $ 0 8 ( $ ( $ • % - ) $ ) • 5 $ 1 $ + A ( -8 ) $ <= > 1 $ ( ? ;555 @< ) $ ? $ 1 1 $ $ B ( $ $ ) % ' & , / • 6 / / B & / 6 = ' = = =? DA & / A / DA! +%A> 6 DA # A # DA A /DA3EA DA DA A> A> > / 5 & / / / & 5 & B 6 =@ & 1A C 3DC B C D & N& 1AC A2 G / A2B 1A+ S / 1O _ \C 3\2A2B / / A= / 1C D / A= >AB /1C / A= >A C D4>AB &N /N C 1C 22G 2G A=? >AB H H / A=? >AB H G / A AB H &N 12B @> 6 C D$ IC(@I 9 : ' 8 E8 9 F & $ 23 G $ & 5 & IO c & & C 3 23 C D$ 8 E& 3E 2 C ' $ 8 E& & & 3 C C 3E 1C 2 2 ( ' C & $ 8E & : 8 # / / & & / / / H 0 ( 5 6 J 8 $ $ 1 $ $ ) & $ - $' $ : . 1 & 2 / 6 • / / B & / 6 = ' = = =? DA $ ) 3 A / DA! +%A> 6 DA # A # DA A /DA3EA DA' DA ) A> A> > / / / & B / / 6 =@ & 1A / A2B C 3DC B C D & N& 1A+ S / 1O _ \C 3\2A2B 1AC A2 G / A= D D % & $ $ / D >AB / 1C D &N /N 1C 22 G / A .9'6 A A= D # D DC A= >AB / AO *()'6 A A= D # D DC A= >AB / A$0)' 0 O6 A A= D # D DC A= >AB / A%' ': O A A= D # D DC A= >A A= >A A= >AB H / A' + ' A A= >A A= >AB / A= D D+ >AB ) 3 WEX>A W3X>A W4X>A WLX>A / A= D DO >AB H G / A A A= >A A= >AB H &N 12B @> / / % $ ) 3 & $ / & $ ) 3 / & % ' & $ / $ + & ' D / 6 / A2B & N& 1C 2G / A)'<0+%) 1A$' '%' :) * "')'10 ' 0*0O.$ AB H G / A ')) ) O H &N @> / ) 3 ) =@ & 1A C9DC B C & 12B +' !K$ / & ' 0*0O.) ' )'<0+%) AB _ C92A2B / 5 ' ) & / 6 • / / B & / 6 = = =? DA DA > A A D9 DA* ) 3 9 $ / DA! +%A> ( $ A> / * & / & / / =@ & 1A / A2B C 3DC B C D & N& 1A+ S / A= 'O%')> = D4>AB / 1C D &N /N 1C 22G / A= >AB /1C C 2G / A= >A C A=? >AB H H / A=? > =? 'O%')>AB &N 12B @> A2B d 0 5 ( 6 1 % $ $1 $1 ( $ $ $ $' ) 3 3 1 - ) & Z . * $ & 6 + $ & 8 • $ • ) • < '?+ ! & • ' • K • ! • $ & & ' + & • ) & 2 • ' • $ Z & + * $ 5 • ) • 0 • < 1 Z 2 4 1 • ! 1 2 . 6 • + • ( • . / • $ 1: 6 . ( $ 2 $ # ( 1* 8 2 6 & • 7 : • %/ 0 • ! : • f 40 14 7 . e 0 ( ) Q* _6 %/ K < * 13 . . $ ) Q* ! 10 % / ' 2 ! _ : ' ! 2 ! 3 ' 2 9 7 ! *