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
! *