INSTITUTO TECNOLOGICO DE

PARRAL

MATERIA: INGENIERIA WEB 1

ACTIVIDAD: TEMA 5

FECHA: 28/NOVIEMBRE/2015

NOMBRE DEL ALUMNO: VICTOR ANTONIO

OCHOA PEA

TECNOLOGA CONSCIENTES DE DISEO DE APLICACIONES WEB

La Web surgi como un sistema de hipertexto muy simple que apoya el
concepto de vinculacin global. Esta receta "simplicidad" para el xito ha
puesto en duda el uso de madura mtodos y herramientas de diseo de
hipertexto / hipermedia para el da actual. XML fue la primera tecnologa para
hacer "bien desarrollados" sistemas de hipertexto posible, pero estn lejos de
ser acostumbrado. Adems, en la relativamente corta historia de la Web se ha
hecho hincapi en la conexiones de base de datos y por lo tanto el diseo de la
informacin. Sin embargo, el diseo de la informacin ha sido slo
parcialmente utilizable para el diseo de aplicaciones Web. La integracin de
mdulos de software en extensas clientes y servidores y tcnicas de diseo de
software por lo tanto orientada a objetos ha sido importante en el "crisol Web".
Sin embargo, desde los aspectos mencionados se han mantenido todas
significativa, ninguna de las tres races solo puede ofrecer soluciones
satisfactorias. En consecuencia, los enfoques para La Web especfica de
diseo estn en demanda. Pero las caractersticas "tpicas" de aplicaciones
web siguen siendo tanto en un estado de flujo y el campo es tan joven, que las
mejores prcticas y la resultando buenos mtodos de diseo, los procesos de
diseo, notaciones de diseo y herramientas de diseo no tienen realmente
surgido.
Es por ello que, en la situacin actual, un solo enfoque puede ser
recomendada: aplicacin web los desarrolladores deben romper las
aplicaciones Web en tres capas lgicas que, a su vez, se dividen en dos
mitades a cada uno por el mismo principio. Distinguimos entre los componentes
(especialmente Web los nodos de aplicacin, es decir, medios de
comunicacin, los componentes de software, base de datos de accesos), y su
disposicin en una malla. Identificamos las tres capas siguientes: (1) el diseo
de la presentacin, donde diseamos la apariencia, y donde las interfaces de
usuario multimodales entran en juego; (2) la interaccin diseo, donde
diseamos la navegacin mediante el uso de mallas, y el cuadro de dilogo
especfico mediante el uso de componentes; y (3) el diseo funcional, que
especifica el "ncleo" de nuestra aplicacin web.
A medida que nuestro diseo se vuelve ms concreta en cada nivel y para
ambas partes (nodos, mallas), lo haremos tener que recurrir a herramientas de
hipertexto, la informacin y el diseo de software. Desafortunadamente, el
estado de la tcnica actual no ofrece soporte tcnico satisfactorio para la parte
integradora de nuestro diseo.
5.1 INTRODUCCION
Este captulo representa una introduccin al diseo de aplicaciones Web. Pero
primero, tenemos que arrojar algo de luz sobre la prctica comn. La prctica
comn se caracteriza por mal coordinada las tareas de diseo, es decir, el
diseo de la informacin, diseo de hipertexto, y diseo de software: seccin

por lo tanto, utilizar un enfoque evolutivo para introducir estas partes y discutir
las posibilidades y problemas antes de discutir la parte de integracin. Las tres
secciones siguientes tratarn de superar el choque no coordinada de varias
"culturas" mediante el uso de una estructura de tres partes sobre la base de
nuevas perspectivas; cada uno de estos tres secciones discute una de las tres
partes, es decir, presentacin diseo, diseo de interaccin, diseo y
funcionalidad. Seccin 5.6 le dar una visin general de la corriente cuestiones
relacionadas con la sostenibilidad, el mayor objetivo de diseo.
LAS REFERENCIAS A OTROS CAPTULOS DE ESTE LIBRO
En este captulo se tiene en cuenta que el diseo de aplicaciones web todava
est determinado en gran medida por detalles (o limitaciones) de las
tecnologas de implementacin disponibles. Esta es la razn por qu este
captulo tiene muchos puntos de contacto con el captulo 6, mientras trataba de
concentrarse en el diseo relevantes aspectos tecnolgicos. Tambin hay
claramente una estrecha relacin de este captulo Captulo 3 y, a primera vista
puede parecer que hay una cierta redundancia. sin embargo, el autores
esperan que una segunda mirada le dar a nuestros lectores una perspectiva
integral. En el uno parte, este captulo trata de cuestiones que son
especialmente relevantes para una etapa avanzada de la ciclo de vida de las
aplicaciones Web. Por otro lado, la tendencia ya reconoci en el Captulo 3
hacia la ms compleja y ms aplicaciones Web "-software pesada" se
consideran ms intensamente en este captulo. Como su primera cifra mostr,
Captulo 3 sugiere una estratificacin triple (presentacin, el hipertexto y la
informacin). Si bien el captulo 3 enfatiz el aspecto de datos, este captulo
muestra que la "capa ms baja" de las aplicaciones Web est ms fuertemente
caracterizada por el software aspecto tcnico (funcin - vase la Figura 5-1).
Aunque la complejidad va en aumento, este tiene la ventaja de que los
aspectos de modularizacin y diseo fundamental ahora se pueden aplicar a
todas las capas. En consecuencia, este captulo se divide el aspecto hipertexto
en dos (malla y componentes), y lo dispone ortogonalmente a las tres capas.
Por ltimo, la parte discute en la seccin 3.7 es an ms desglosado: En primer
lugar, en el "puro" parte de la presentacin, que se concentra en la mediacin
de asuntos (los medios de comunicacin, los contenidos, posibilidades de
interaccin, etc.), y se hace ms compleja, ya que considera aspectos
multimodales. En segundo lugar, en la parte de interaccin que, gracias a un
diseo sistemtico, nos permite mejores iniciativas modelo de malla de hombre
y la mquina. Esto significa que este captulo ampla el enfoque presentado en
el captulo 3 hacia aplicaciones web a nivel de software pesado ms complejos
y ms, teniendo en cuenta las tecnologas. En consecuencia, este captulo no
se repiten las tcnicas de modelado que se describen en el captulo 3. Adems,
ya existen mtodos adicionales slo rudimentarios y herramientas para el
enfoque prolongado introducido aqu, en este captulo ser necesariamente
algo "conceptual" en relacin con el diseo de mtodos. Sin embargo, vamos a

tratar de compensar esta deficiencia inevitable, centrndose en aspectos clave

que, mediante el uso de las diferentes tecnologas disponibles, debe ser
equilibrada para preservar con xito las propiedades de software que CrossCut
todas las etapas de diseo de software, tales como mantenimiento,
reutilizacin, escalabilidad, la sostenibilidad y la capacidad de expansin.

HISTORIA EN BREVE
Primeros intentos de la World Wide Web de a pie se caracteriz por, pginas
HTML basadas en textos centrados en los documentos, para lo cual el trmino
"aplicacin web" parece ser exagerado. De hecho, la descripcin del
documento HTML el lenguaje tiene sus races en la industria de la impresin y
la edicin. HTML promueve la creacin de documentos grandes, estructurados,
que se enriquecen mediante enlaces. Adems de su simplicidad inflexible, el
secreto WWW de xito fue la plena integracin de los vnculos globales - URL.
"Los documentos grandes" significan que HTML promueve la violacin de una
mxima en la investigacin de hipertexto, por el cual los nodos de hipertexto
deben representar las posibles unidades de significado portadores ms
pequeos. Esta y otras contradicciones con el estado de la tcnica se discutir
en la seccin 5.2.1. Hoy en da, estos dficits se puede quitar slo por los
estndares basados en XML del W3C (http://www.w3c.org), pero an as slo
en parte "en principio", porque las mejoras se introducen poco a poco en los
navegadores y servidores web.
La transicin a las "verdaderas" aplicaciones Web, junto con el desarrollo de
los lenguajes de script, por ejemplo, JavaScript (en el lado del navegador) e
interfaces como CGI (en el lado del servidor), la interactividad y las bases de
datos trado y la creacin dinmica de documentos HTML en jugar. Y, por
ltimo, junto con la aparicin de Java, aplicaciones Web comenzaron a ganar
cada vez ms carcter software. La seccin de la clasificacin en el captulo 1
se menciona este punto brevemente.
Para reflejar este gran nmero de diferentes aspectos en el diseo de
aplicaciones Web, utilizaremos subtareas de diseo de aplicaciones Web,
como se muestra en la Figura 5-1, en nuestra discusin. Esta discusin
bsicamente distinguir los componentes de aplicaciones web, es decir, los
nodos y enlaces que los conectan, y sus puntos de inicio y de destino dentro de
los nodos ("anclas"), de malla que consta de tales componentes, es decir, de
toda la aplicacin Web. Cuando decimos "todo" nos damos cuenta de que el
trmino tendr que ser flexibles, porque las referencias a partes de la WWW
que estn fuera del control de los desarrolladores de aplicaciones Web deben
seguir siendo posible. Esto parece ser el nico camino para la Web a
permanecer todo el mundo.1 Adems de la estructura de dos partes se
mencion anteriormente, la Figura 5-1 muestra una de tres partes de capas,
con una clara diferenciacin entre la presentacin y la interaccin, similar al

Modelo- Vista - Controlador concepto (MVC) y la forma de su gran cantidad de

extensiones (Buschmann et al. 1996) distinguen entre la vista y el controlador.
Por un lado, la presentacin se refiere a la malla, teniendo el nodo (el "cursor"
en el camino a travs de la malla; puede haber varios en paralelo) actualmente
visitado por un usuario en cuenta. Por otra parte, la presentacin de los
componentes, es decir, el contenido del nodo, es una tarea central de diseo
(vase el captulo 1); esta primera etapa enfatiza las caractersticas relevantes
de las aplicaciones Web, especialmente las caractersticas de contenido
relacionado, como el carcter de documento y multimedialidad, y las
caractersticas relacionadas con la presentacin, tales como la esttica y
selfexplanation.
Esto significa que es importante la participacin de expertos (diseadores
llamados medios de comunicacin en este contexto) y coordinarlos con otros
desarrolladores de aplicaciones Web (llamados ingenieros en este contexto).La
separacin de las mallas a partir de componentes contina en el nivel de
interaccin. La interaccin dentro de una malla se conoce normalmente como
la navegacin. Navegacin puede ser exploratoria, como lo expresa la
navegacin plazo. El usuario sigue los enlaces que aparecen interesantes para
l o ella durante la lectura de las pginas, y se mueve a travs de la malla en
un camino aparentemente aleatoria. Alternativamente, la navegacin puede ser
(co) controlado por - quizs sofisticado - software, que se adapta las opciones
de seleccin en cada situacin de navegacin (determinado por el "cursor"),
por ejemplo, en forma de una barra de navegacin que cambia dinmicamente,
o un diseo grfico con las partes actualmente desactivado en gris. Modelos
sofisticados de usuario, modelos de dominio, o estrategias de enseanza (en el
e-learning) podran determinar estas dinmicas (De Sujetador et al. 1999)
(Brusilovsky 2001). En contraste, nos referimos a la interaccin con
componentes como un cuadro de dilogo en el sentido de una interfaz de
usuario. En primer grado de interaccin de una aplicacin web, el cuadro de
dilogo se lleva a cabo por las formas (o plantillas). Junto con la posibilidad de
utilizar el software de Java como componentes (applets), la riqueza de
posibilidades de interfaces grficas de usuario puso a disposicin de las
aplicaciones web por primera vez. Aplicaciones Web ubicua apoyan cada vez
ms la amplia gama de clientes mviles, incluyendo los dispositivos basados
en la voz, dilogos multimodales, etc. En el diseo de este tipo de sistemas, el
enfoque MVC mencionado anteriormente impacta sus lmites en el lado del
componente. Aunque sigue siendo vlido como un esquema de organizacin,
MVC como concepto no se refiere en particular a la naturaleza de navegacin
de la interaccin interfaz de usuario.
Observe una pequea indicacin de que la horizontal (presentacin /
interaccin) y (mallas / componentes) separacin vertical es justificada. Las
mallas no haban sido representados en absoluto a principios del Web basada
en HTML, mientras que la navegacin dentro de una malla fue apoyado

(haciendo clic en enlaces o utilizando los botones Adelante / Atrs en el

navegador). A la inversa, la presentacin de los componentes (documentos
HTML prestados por el navegador) se ha tomado muy en serio desde el
momento en que se haban introducido los primeros navegadores grficos,
mientras que de dilogo con un componente ha sido posible slo a partir de la
introduccin de "formas" en HTML.
Similar al concepto MVC, donde el llamado "modelo" acomoda el ncleo real,
es decir, la funcionalidad de una aplicacin, el principio de diseo se muestra
en la Figura 5-1 requiere una capa adicional, que se refiere al diseo funcional
como en la siguiente discusin. Queremos que el trmino "funcin" de ser
inicialmente neutral y comprenden todas las etapas de desarrollo Web. La
plataforma de documento centrado en principios se caracteriz principalmente
por contenidos estticos, es decir, los contenidos en forma de componentes
especificados por los autores, por lo que funciona en el verdadero sentido eran
slo las llamadas de la presentacin o de la funcin de reproduccin (por los
medios de comunicacin), lo que significa que la capa estaba prcticamente
vaco. En relacin con la posibilidad de acceder a bases de datos, aplicaciones
web cada vez haban sido influenciados por los principios del clsico sistemas
de informacin y bases de datos, es decir, el diseo de la parte funcional
consistan esencialmente en el diseo de la informacin. Junto con la transicin
a las ms recientes categoras de aplicaciones Web mencionados en el
captulo 1 (basado en el flujo de trabajo, colaboracin, portal, omnipresente),
los componentes con extensas funcionalidades han movido en el primer plano.
Por supuesto, los enfoques orientados a objetos son adecuados a los aspectos
funcionales y de datos integralmente modelo. De acuerdo con ello, Java y
compitiendo enfoques como ASP / .NET, haban jugado inicialmente un papel
dominante. Han sido ms recientemente mejorados sustancialmente los
estndares del W3C para fortalecer la interoperabilidad a nivel mundial en la
Web. La creciente importancia de los componentes activos se refleja tambin
en las llamadas a procedimientos remotos, por ejemplo, los que segn el
estndar SOAP, apareciendo adems a los enlaces "estticos", y en el hecho
de que el nodo de destino de un enlace se puede determinar en tiempo de
ejecucin, por ejemplo, a travs de UDDI. En una poca fuertemente
influenciada por los sistemas de informacin, el lado de la malla se caracteriz
por los enfoques de gestin de flujo de trabajo, que son ms adecuados para
los modelos de mallado componente esttico en el sentido de los pasos
involucrados en un proceso de negocio. Junto con la introduccin de servicios
Web y conceptos para modelar procesos de negocio cruz de una misma
empresa, conceptos de mallado ms flexibles entraron en juego por trminos
como la orquestacin o coreografa (2002a W3C), pero el desarrollo de estos
conceptos es todava en curso. El grado de la dinmica en las aplicaciones
Web ubicua probablemente aumentar en lnea con el surgimiento de un
mercado de servicios abierto. Los servicios sern entonces prcticamente ser

componentes Web, que pueden ser orquestados a una malla en el sentido de

las aplicaciones Web ubicua, altamente personalizados y complejos, a juego
con las necesidades de los usuarios. Como criterio general para el diseo de
aplicaciones web, se recomienda cubrir las seis partes destacaron en la figura
5-1, y observar los siguientes aspectos, en vista de nuestra discusin anterior:
El fondo cultural de todos los desarrolladores deben estar representados en
un equipo, y se debe tener cuidado en cuanto a su integracin.
Hay modelos independientes, mtodos y herramientas para el diseo y puesta
en prctica en cada una de las seis partes, pero difieren considerablemente,
dependiendo de la categora de aplicaciones web (vase el captulo 1). Una
discusin completa de este tema ira ms all del alcance y volumen de este
libro. Cabe sealar, sin embargo, que una mayor evolucin de una Web
aplicacin a una categora ms sofisticada es concebible.
La seleccin se mencion anteriormente, no slo debe tener en cuenta las
categoras de aplicaciones Web planificadas, sino tambin las tecnologas
previstas. Esta dependencia es tan fuerte que juega un papel central en este
captulo.
Un proceso de diseo integral como un camino a travs de las seis piezas
que se muestran en la Figura 5-1 no se puede recomendar en general. Ms
bien, es significativa para cubrir las tres capas horizontales primero en un lado
y luego en la otra, tal vez de forma iterativa. Mientras que el lado de la malla se
puede disear primero cuando la mayor parte del desarrollo de una aplicacin
web es nuevo, lo primero que tenemos que desarrollar componentes
reutilizables si no tenemos conocimiento de las mallas. Dentro de un lado, se
recomienda desde la perspectiva de la ingeniera de software para comenzar
en la capa ms baja, debido a la interaccin puede ser orientado a la funcin, y
la presentacin puede ser orientada a la interaccin. Si la esttica y otras
caractersticas relacionadas con los usuarios de las aplicaciones Web estn en
el primer plano, a continuacin, se recomienda el camino opuesto.
5.2 DISEO WEB DESDE UNA PERSPECTIVA EVOLUTIVA
5.2.1 Antecedentes
Como se mencion al principio del captulo 1 y superiores, una caracterstica
central de las aplicaciones Web es su visin centrada en el documento, es
decir, una mayor importancia de la informacin legible por humanos contra
software convencional: el contenido es el rey. Inicialmente, Tim Berners-Lee
quera desarrollar la Web para ser un simple aunque sistema de hipertexto en
todo el mundo a travs de Internet, y se centr principalmente en la informacin
textual. En consecuencia, las actividades de los autores y programadores
chocan, o descaradamente hablando, el mundo de los artistas golpea la de

ingenieros. Esta seccin examina estos opuestos a travs de espectculos

histricos para entender mejor las aplicaciones Web y discutir cuestiones de
diseo importantes. Secciones 5.2.2 a 5.2.5 comienzan con una discusin
sobre el aspecto de autora y se mueven a travs del aspecto tecnolgico de
software para luego discutir las caractersticas y beneficios de la integracin de
ambos aspectos comunes, y, finalmente, miran los problemas existentes o
nuevas de esta integracin.
5.2.2 DISEO DE INFORMACIN: Y AUTORA DE ACTIVIDAD
En esta seccin se distingue entre la era antes de la Web, la era HTML (desde
el advenimiento de la Web hasta el ao 1997), y la era actual XML (W3C 1998).
El comienzo de la era de HTML se centr exclusivamente en la edicin. Slo
los documentos de hipertexto fueron apoyados, como el nombre de la llamada
lenguaje de programacin Web, HTML, sugiere: Hypertext Markup Language,
un lenguaje para obtener instrucciones - o etiquetas - esparcidos a lo largo de
los documentos de texto. En el curso del tiempo, HTML apoyado otros medios:
imgenes, medios sensibles al tiempo, como el vdeo y el audio, etc., reflejados
en el hipermedia plazo, que a veces se utiliza para distinguir HTML de
hipertexto y, a veces como sinnimo de hipertexto. Vamos a utilizar el
hipertexto como un trmino genrico en la siguiente discusin.
El concepto de hipertexto es ms antiguo que el HTML; su idea bsica fue
formulada por Vannevar Bush tan pronto como a finales de la Segunda Guerra
Mundial, en vista de la riqueza emergente de soportes de informacin tcnica.
Ted Nelson acu el trmino en s mismo, en la dcada de 1960. Documentos
de hipertexto se componen de lo siguiente:
Nodos, enlaces y anclajes, introducido en el captulo 1; y Mallas y otros
agregados. Mallas designan nodos y enlaces coherentes, y fueron llamados
documentos de hipertexto en la era antes de la Web. Ejemplos de agregados
incluyen vistas (por ejemplo, para expertos y profanos entre los lectores),
caminos (secuencias de lectura predeterminados), y meta-nodos (mallas que
se pueden incrustar en mallas envolventes, como un nodo). El simple Web de
la era de HTML no los soporta, pero su importancia ha crecido fuertemente con
el advenimiento de los conceptos de modularizacin avanzadas, por ejemplo,
estructuras de navegacin como "Navegacin en forma de estrella" (ver
seccin 5.4.6), por citar un solo ejemplo de diseo de interaccin. Aunque
HTML consider inicialmente slo el aspecto de creacin, representaba un
paso atrs en comparacin con los sistemas de hipertexto populares incluso en
este sentido, e incluso con respecto a la visin fundamental de los documentos
exploratorios no lineales (vase el captulo 1). La popularidad de la Web fue
posible slo gracias a su sencillez y disponibilidad gratuita en todo el mundo.
Se mencionan brevemente a continuacin en la medida en que son relevantes
desde el punto de vista de diseo Sus principales debilidades:

 HTML se puede entender como un (clsico) documento de descripcin de la

lengua con las etiquetas de hipertexto injertado sobre. Este seduce a la gente a
no tener en cuenta el principio de la atomicidad de nodos; muchos documentos
"HTML" (en realidad nodos) son varias pginas, y la idea de hipertexto bsica
de la lectura no secuencial es la actualidad slo rudimentariamente o en casos
excepcionales.
HTML mezcla aspectos ortogonales como estructura de hipertexto (a travs
de las etiquetas para los enlaces y anclajes), documento de estructura
(encabezados, listas, etc.), y el diseo (color de fondo, cursiva, etc.).
Aunque la Web reconoce la arquitectura de software distribuido con los
navegadores y servidores introducidos en el captulo 4, carece de la
"horizontal" arquitectura de software de las mquinas abstractas.
Los ejemplos incluyen la arquitectura clsica de Dexter, que separa el
contenido y la gestin de la malla de la presentacin o la estratificacin sugiere
en el captulo 3 y en este captulo.
HTML es el texto centrado. Otros medios de comunicacin a menudo se
producen slo como destinos de enlace (caminos sin salida); muchos tipos de
medios de comunicacin no se admiten como fuentes de enlace en absoluto o
han sido recientemente. No fue hasta la llegada de SMIL (vase el Captulo 6)
que la descripcin de los medios de comunicacin temporal podra ser cubierto
en la Web.
La evolucin de la Web aument la importancia de primer inconveniente
anteriormente. El apoyo a la estructuracin y formato dentro de nodos mejor
gradualmente, mientras que los tipos de aspectos importantes de hipertexto,
por ejemplo, nodo definido por el usuario y de enlace, enlaces, almacenamiento
separado de enlaces y nodos, anclas de destino no triviales, etc. inversa,
todava faltan.
Para entender mejor el aspecto de creacin de XML, en contraste con lo
anterior, lo primero que echar un vistazo a el origen de HTML. Su origen se
remonta a SGML, un lenguaje de marcas genrico estandarizado para el
mundo de las imprentas y editoriales. "Generalizado" significa que SGML define
etiquetas y reglas vlidas que se utilizarn para toda una clase de documentos
(es decir, un campo especfico de solicitud y los documentos que utiliza
normalmente). Los resultados son las definiciones de tipo de documento (DTD).
Un analizador SGML DTD puede leer y comprobar los documentos para ver si
son o no corresponden a un DTD. Sin embargo, un software especial se debe
escribir para interpretar y ejecutar las instrucciones de las etiquetas specifiedby.
Las editoriales utilizan DTDs para distinguir entre diferentes libros, revistas, y
los formatos de folletos, formularios, y muchas otras cosas. En el principio, el
HTML no era ms que un SGML DTD para el formato de "pantalla", extendida

por las etiquetas para los enlaces y anclajes como "injertados sobre"
funcionalidades de hipertexto. Versiones HTML posteriores correspondieron a
nuevas DTD. Los navegadores de la poca HTML no son analizadores SGML;
en cambio, no tienen soporte para unos DTD (el soportado
Versiones HTML) codificada en ellos, incluyendo la forma en que interpretan y
traducen las etiquetas comandos. La "representacin" tambin est codificado
y slo la introduccin de CSS (Cascading Style Sheets) habilitadas diseos
reutilizables y una forma rudimentaria de separar el diseo de la estructura.
La era XML amaneci cuando los PC estndar estaban listos para "digerir"
analizadores SGML. Casi sugiri s para estandarizar una versin simplificada
de SGML para hacer la cantidad de posibilidades de un lenguaje de marcas
genrico utilizable. Junto con la aparicin de XML, un enorme nmero de
"lenguajes de programacin simples", definidas como XML-DTD (ms
recientemente llamado esquemas XML), se haba definido, incluyendo un
lenguaje para describir las llamadas a procedimiento remoto (SOAP), un
lenguaje para describir las transacciones financieras (XML-EDI), una
contraparte a HTML (XHTML), y muchos ms (ver Captulo 6). Desde XML le
permite describir formalmente la sintaxis, pero no la semntica, los
navegadores modernos pueden analizar esquemas XML arbitrarios y
documentos, pero ellos (esencialmente) pueden ejecutar solamente XHTML.
Casi todas las debilidades de HTML antes mencionados por su parte se han
abordado en diversos estndares XML. Si, y cmo estas normas en parte de la
competencia se proliferar queda por verse.
Podemos identificar algunas reglas bsicas para el diseo de aplicaciones Web
basados en documentos, es decir, por el aspecto de creacin, de la discusin
anterior:
Las mallas deben constituir el centro de diseo de informacin.
Documentos convencionales deben descomponerse en nodos atmicas.
Aspectos como la presentacin y el contenido, nodo y malla, etc., deben ser
separados conceptualmente, aunque una tecnologa no es compatible con esta
separacin.
La tecnologa seleccionada debe apoyar los conceptos avanzados, por
ejemplo, el centro de gestin de enlace, al menos en el diseo, ideal tambin
en el sistema de gestin de contenidos (oculto al usuario final), y en intranets,
incluso en la propia tecnologa de aplicacin. Soluciones basadas en XML se
debe dar preferencia a los enfoques de propiedad.

5.2.3 DISEO DEL SOFTWARE: PROGRAMACIN DE UNA ACTIVIDAD

Esta seccin sigue teniendo una perspectiva histrica, distinguiendo entre el
desarrollo gradual de la "Web programable" y el desarrollo de (distribuido) de
programacin.
Esta seccin aborda temas discutidos en detalle en los captulos 4 y 6,
dirigindose a ellos slo en la medida en que se relacionan con los aspectos de
diseo importantes.
WEB PROGRAMABLE
Los primeros pasos hacia la "dinmica" eran los formularios HTML. Con su
introduccin, la importancia de lenguajes de script aument dramticamente, ya
que podran ser adaptados especficamente a las necesidades de
procesamiento de los navegadores o servidores y fuera fcil de manejar.
Scripts se utilizan generalmente para crear pginas HTML sobre la marcha, en
funcin de los insumos en un formulario HTML.
Sin importar el idioma que se utiliza para crear nuevas pginas HTML, el script
o programa deben ofrecer estructuras y operaciones de datos predefinidos para
ser capaz de crear elementos de pgina HTML tpicos, como los encabezados
de los diferentes niveles, prrafos, listas, y otras cosas, se llenan con
contenidos y ponerlo todo junto (como una estructura tipo rbol de elementos).
Esto casi siempre se basa en el Document Object Model (DOM), que ha sido
definido consistentemente como nuevas versiones de HTML llegaron junto con
los aos, y que est disponible en lenguajes de script o lenguajes de
programacin.
Los desarrolladores de Java originalmente se propuso introducir "el lenguaje de
la Web", con la idea de que los navegadores deben representar no slo HTML,
sino tambin ejecutar Java. Al igual que en los documentos HTML, llamados
applets de Java fueron diseados para su descarga desde los servidores, y en
vez de un documento esttico, (applet) interfaz de usuario de un programa
apareceran en la ventana del navegador. En consecuencia, el enfoque
principal se coloc en los aspectos de seguridad para evitar que los applets de
terceros de la ejecucin de las operaciones no deseadas en las mquinas de
los usuarios finales. Con Java, Sun tuvo la visin de un mercado de software
de pago por uso, que casi no se ha realizado hoy. Sin embargo, s Java se hizo
muy popular, aunque slo de forma moderada como un lenguaje de
programacin applet, sino como un lenguaje de programacin "regular" y un
idioma para servidores y programacin distribuida. Adems de los scripts y
applets, navegadores ejecutar programas en particular para la representacin
dinmica de presentaciones multimedia, por ejemplo los desarrollados con
Macromedia Flash.

PROGRAMACIN DISTRIBUIDA
Programas distribuidos en Internet originalmente corrieron directamente encima
de las conexiones TCP; comunicacin entre procesos (IPC para abreviar), es
decir, el intercambio de mensajes entre dos pares iguales, dominado. Para
multimedia, IPC (reforzada por la calidad garantizada de servicio para
"Corrientes") parece haber recuperado algo de importancia, pero haban sido
reemplazados por llamada a procedimiento remoto (RPC), acompaado de las
arquitecturas cliente / servidor en la dcada de 1990. El siguiente paso en la
evolucin, es decir, la adaptacin de la RPC para orientada a objetos lenguajes
de programacin, se refiere incorrectamente como "programacin orientada a
objetos distribuida" y, finalmente, condujo a una mayor proliferacin de
programas distribuidos, con tecnologas como CORBA y Java de Remote
Method Invocation (RMI). El nombre anterior es incorrecto porque los principios
orientados a objetos, como la modularidad y flexibilidad, contradicen el mundo
RPC de los clientes y servidores monolticos, que siguen existiendo en CORBA
y RMI. El tipo de programacin a objetos distribuida que merecera este
nombre se ha pegado en la etapa acadmica hasta hoy. En cambio, la
comunicacin basada en eventos (EBC para abreviar), y de publicacin /
suscripcin arquitecturas se han convertido cada vez ms importante. En EBC
creador informacin determina cuando para comunicarse ("cuando se produce
un nuevo evento") utilizando el principio de empuje en contraste con el principio
de traccin cuando el solicitante inicia la comunicacin. Los clientes registran
los tipos de eventos que les interesan mediante suscripcin. Estos tipos de
eventos, en lugar de las conexiones, determinar el grupo de receptores.
Receptores originalmente no incluidos en un grupo se pueden agregar
fcilmente. JavaBeans y middleware orientado a mensajes utilizan formas
rudimentarias de EBC. La fuerte tendencia hacia aplicaciones web a nivel de
software centrada llev a una situacin en la que desarrollos mencionados
anteriormente se han producido en time-lapse (cf. por ejemplo, la aparicin de
Servicios Web). Dado que este se refiere principalmente el diseo funcional,
este tema ser discutido ms adelante y en el apartado 5.5.
5.2.4 LA FUSIN DE DISEO DE INFORMACIN Y DISEO DE SOFTWARE
Desarrollo de software orientado a objetos encapsula significativa de datos
coherente junto con las operaciones que tenga relacin - los mtodos.
Enfoques purista ni siquiera se permitir acceder a los datos directamente
desde el exterior; slo los mtodos son "visibles" para oponerse a los usuarios.
Obviamente, mallas consisten de los objetos y las relaciones de llamadas entre
ellos son muy similares al nodo de enlace de las mallas en el hipertexto. Por un
lado, un nodo de hipertexto podra ser considerado como un objeto con
mtodos, por ejemplo, "Presentes datos legible por humanos", "seleccione
ancla", y "seguir el enlace al ancla seleccionado". Por otro lado, botones en los
formularios HTML a menudo se esconden mtodos de JavaScript. Por lo tanto,

invertir un poco de tiempo y esfuerzo, podramos poner en prctica muchos

diseos de software orientado a objetos generales como documentos HTML.
Despus de todo, los applets de Java son objetos y nodos de hipertexto, por
definicin. El hecho de que la orientacin a objetos y el hipertexto se han
mezclado se puede ver fcilmente en un nodo del tipo "video generada por
ordenador". Basta pensar en un enlace apuntando desde una pgina Web a la
animacin de un cmic. Si usted sigue este enlace, se reproduce la animacin,
pero usted puede o no puede saber si las imgenes se reproducen a partir de
un solo archivo, como en un video, o calculado por un programa en tiempo real,
es decir, si usted ve un documento de vdeo o un programa de vdeo. Pero
entonces, realmente necesitamos distinguir entre las funciones de los autores
y programadores? Nos inclinamos a decir que no, pero todava hay muy pocos
desarrolladores Web que representan tanto las "culturas".
Obviamente, ni tienen las tecnologas de la Web y programacin distribuida
totalmente fusionadas, ni las "culturas" de los seres humanos que participan en
el desarrollo de aplicaciones Web. Sin embargo, podra ser til simplemente
ignorar una "impulsada por la tecnologa" separacin artificial del mundo de los
objetos del mundo hipertexto en un proceso de diseo. Entonces podramos
disear aplicaciones Web de elementos (hermafroditas objeto de nodo) y
enlaces (que tambin podra ser relaciones mtodo de llamada). Esta enfoque
permite identificar tecnologas que se utilizar ms adelante, o de un caso a
otro. Las siguientes alternativas enormemente simplificadas se pueden
observar en este enfoque:
Los elementos pueden ser implementadas ya sea como pginas estticas,
cliente generados (por ejemplo, JavaScript), o como pginas generadas por el
servidor (ASP, JSP). Adems, pueden ser implementados como applets,
interfaces de usuario de los programas orientados a objetos distribuidos (Java),
o medios estticos o generados.
Lo que los usuarios ven en su navegador puede ser contenido multimedia,
formularios o interfaces de usuario de software, en funcin de la caracterstica
de la presentada (prestado) HTML. Cosas que los usuarios pueden seleccionar,
hacer clic y ejecutar son enlaces.
Enlaces representan URLs en HTML, o para XLinks en XML, si el objetivo es
la informacin ms que un programa, y si tanto el contenido y la direccin son
conocidos en el momento de aplicacin (HTML plano) o al tiempo de
presentacin (HTML dinmico). Los enlaces representan las llamadas remotas
a, por ejemplo, las secuencias de comandos remotos (si la informacin tiene
que ser "calculado"), o los mtodos (si los clculos requeridos son
algortmicos). Si la direccin de destino se debe calcular sobre la marcha,
entonces la tcnica de software utilizado debe apoyar enlaces de objetos
calculados dinmicamente (esto es posible incluso en HTML con algunas

soluciones, es decir, mediante la instalacin de servidores proxy entre el

navegador y el servidor, y por la aplicacin de la puntero re-directa concepto).
5.2.5 PROBLEMAS Y RESTRICCIONES EN DISEO WEB INTEGRADO
El camino hacia la integracin de hipertexto, la informacin y el diseo de
software en el diseo web es accidentado, sobre todo debido a tres obstculos
especficos: "cultural", tecnolgico, y los problemas conceptuales. Por el lado
de "cultural", podramos criticar que el entendimiento mutuo para chocar
culturas es insuficiente no slo entre los desarrolladores Web en la prctica,
sino tambin entre los investigadores, la herramienta y los desarrolladores de
mtodos, y de los formadores. En el lado tecnolgico, las herramientas y
mtodos disponibles son insuficientes. Adems, la fusin de estos campos se
describen en la seccin 5.2.4 an no se ha materializado. Y, por ltimo, en la
parte conceptual, el concepto integrado dibujado all realmente tendra que
adaptarse a ltimas novedades y hallazgos antes de que pueda llegar a la
madurez necesaria para ser implementado en herramientas y mtodos, o
incluso proliferar. Sin embargo, esto no debe impedir que los buenos
desarrolladores web de adaptar el modelo esbozado a sus necesidades, y su
uso en sus diseos web, al menos conceptualmente. Estos desarrolladores
podran entonces seleccionar las herramientas que les permitan mapear el
modelo para un diseo legible por mquina, al menos rudimentariamente.
Ahora vamos a discutir brevemente los tres problemas mencionados
anteriormente para entenderlos mejor; una discusin detallada ira ms all del
alcance y volumen de este libro. Obstculos culturales pueden tener tantas
caras que queremos dar slo un ejemplo representativo: mientras especficos
de diseo grfico de las pginas Web se tratan en los libros de texto y material
educativo, informacin especficos de diseo para la web apenas se aborda
como un problema educativo. Ejemplos de obstculos tecnolgicos son ms
fciles de ver con ms detalle:
El diseo de pginas Web en el sentido de diseo de informacin y diseo de
software y las fases de desarrollo posteriores son normalmente no es
compatible con las tecnologas disponibles en el mercado.
La transicin de las formas-base interfaces de usuario interactivas al software
con interfaces grficas de usuario normalmente representa un cambio
tecnolgico espectacular, porque los applets de Java no han ganado mucho
terreno en el mundo de la produccin de software industrial, a pesar de Java se
ha convertido en un "lenguaje de programacin para la Web" mucho ms
general de lo previsto inicialmente, por ejemplo, en forma de Java Server
Pages (JSP).
No existe una tecnologa apropiada para algunas variantes deseables de los
dos conceptos de diseo descritos en la seccin 5.2.4, es decir, elementos y

enlaces. Por ejemplo, HTML no tiene manera de calcular el destino de un

enlace en el tiempo de navegacin (cuando se hace clic), excepto para el uso
de proxies intermedios, que es algo engorroso.
La mezcla de grano fino de los aspectos de creacin y programacin dentro
de un elemento o un enlace no est suficientemente apoyada por tecnologas.
Por ejemplo, si queremos apoyar la navegacin sofisticada a travs de una
malla, tendramos que aplicar una capa de software de navegacin por
separado en HTML o XML e introducirlo en la parte superior de la malla. La
nica forma en que actualmente podramos lograrlo es mediante el
establecimiento de una gran cantidad de trabajo de desarrollo, el uso de
tecnologas basadas en XML especiales que an estn escasamente utilizados
en la prctica.
En cuanto a la tercera y ltimo problema se refiere, es decir, los obstculos
conceptuales, tenemos que destacar sobre todo el tema de la sostenibilidad y
la reutilizacin. Este tema ser discutido en la seccin 5.6.
5.2.6 UN ENFOQUE ESTRUCTURAL PROPUESTO
Repetidamente Habr que distinguir entre el diseo de hipertexto, diseo de la
informacin, y diseo de software en las siguientes secciones, porque, por
desgracia, esto sigue siendo habitual en los mtodos de diseo y herramientas
de diseo, como en la prctica. Sin embargo, vamos a tratar de evitarlo en
favor de una visin integradora de diseo de aplicaciones Web. Seccin 5.1
introdujo un diseo estructurado sobre la base de la figura 5-1, y las secciones
5.3 a 5.5 discutir las partes de este enfoque en los detalles. Para recuperar el
tres partes, les enumeran a continuacin, cada uno con un lado de los
componentes y un lado de malla:
Diseo de Presentacin: Este diseo tiene la salida de los documentos,
medios de comunicacin y datos (en el sentido de un sistema de informacin, o
en el sentido de datos de la aplicacin de un componente de software) en su
lado componente. En su lado de malla, este diseo debe centrarse en la
visualizacin, auditiva o de salida multi-modal de mallas, y el componente (s)
actualmente visitado por un usuario. Desde este lado se encuentra todava en
la etapa de investigacin, adems de la utilizacin comn de las barras de
navegacin en los navegadores, que ser discutido brevemente en la seccin
5.3.
Diseo de Interaccin: Esta parte tiene que ver con el flujo de control de la
interaccin de un usuario con una aplicacin web. Por el lado de la malla, la
navegacin trmino se ha convertido en una costumbre, mientras que el
dilogo trmino se utiliza en el lado de los componentes. Ambos temas sern
discutidos en la seccin 5.4.

 Diseo funcional: Seccin 5.5 presenta el diseo de la base de componentes

y mallas, haciendo hincapi en la perspectiva del desarrollador de software,
porque esto es importante para las ltimas categoras de aplicaciones Web
(vase el captulo 1). En consecuencia, el lado de los componentes se
describir como un diseo de la informacin, en lugar de un diseo de
componentes de software. Del mismo modo, el lado de la malla se centrar en
la composicin de los componentes activos en los procesos de negocio (flujos
de trabajo) y aplicaciones Web ubicuas altamente personalizadas.
5.3 DISEO DE PRESENTACIONES
En un diseo de la presentacin, "los diseadores de medios de comunicacin"
(ver seccin 5.1) definen el aspecto y - hasta cierto punto - la estructura de la
forma en contenidos multimedia se presentan. Basado en la idea original que
contenido es el rey, HTML clsico contenidos especifica junto con las
instrucciones de formato, enlaces y programas (scripts). Por el contrario, el
diseo moderno presentacin sigue la separacin conceptual del contenido de
una aplicacin web y su presentacin. El contenido de un resultados de la
aplicacin web desde la composicin de contenidos multimedia desarrollado
explcitamente en el lado de los componentes y contenido implcitamente
definidos en el lado de la malla. Esto significa que un buen diseo de la
presentacin nos permite adaptarnos con flexibilidad la presentacin de varios
requisitos culturales, tecnolgicos y contextuales.
Adems, muchas pginas web, aplicaciones web y sitios web completos se
reestructuran o equipados con un nuevo diseo visual (vase el captulo 1)
durante su ciclo de vida. En el desarrollo web tradicional, esto a menudo
significa que cientos o incluso miles de documentos HTML deben adaptarse de
forma manual. Las personas involucradas en este proceso de modificacin de
documentos HTML normalmente necesitan tener conocimientos de HTML
sonido. Aunque las herramientas adecuadas se pueden utilizar hasta cierto
punto, a menudo una parte considerable queda modificada manualmente. Esto
significa que es imposible o muy costoso para modelar consistentemente todos
los contenidos en un equipo de desarrollo ms grande.
Herramientas disponibles para crear aplicaciones Web se pueden agrupar en
dos categoras por la forma en que apoyan el diseo de la presentacin:
editores de pginas convencionales y los sistemas ms avanzados de gestin
de contenidos.
Editores de pgina se utilizan generalmente para crear pequeas presencias
de Internet ad-hoc. Sus principales ventajas son que son similares a software
estndar, que permite a los usuarios trabajar en un ambiente familiar, y que
permiten dar formato directamente contenidos. Sus principales inconvenientes
son que el conocimiento de HTML es necesario para las tareas no triviales, y
que los desarrolladores trabajan en el nivel de pgina, lo que significa que

pueden perder fcilmente la imagen conceptual ms grande. Por otra parte, el

diseo, la navegacin, y la interaccin se mezclan, que se puede considerar
una simplificacin slo para aplicaciones triviales.
A diferencia de los editores de pginas, sistemas de gestin de contenido
permiten la separacin de las actividades de redaccin de la disposicin, lo que
facilita el mantenimiento de una presencia en Internet. Esto significa, sin
embargo, que la estructura de una presentacin de Internet tiene que ser
asignada. Los detalles de los sistema de manejo de contenido son que las
herramientas especiales para diversos roles participantes, por ejemplo, artistas
grficos o editores, son disponibles, mientras que normalmente no se requiere
conocimientos de HTML. Otro beneficio es que el contenido, el diseo y la
navegacin son independientes, se especifican los contenidos de las unidades
de informacin individuales, y los flujos de trabajo se pueden asignar. La
diferenciacin entre editores de pginas y sistemas de gestin de contenidos
introducidos aqu difumina continuamente, porque en las versiones recientes
muchos editores de pginas integrar las funciones del sistema de gestin de
contenido simples.
5.3.1 PRESENTACIN DE LOS NODOS Y MALLAS
Resultados de contenido de una pgina web desde la composicin de
contenidos multimedia desarrollados explcitamente en el lado de los
componentes y contenidos implcitamente definidos en el lado de malla (por
ejemplo, opciones de navegacin).
Al crear contenidos multimedia, los desarrolladores tienen un gran nmero de
opciones de diseo a su disposicin. Con respecto al concepto deseado de
separacin de contenido y presentacin, estas opciones de diseo son a
menudo compiten. Por ejemplo, generalmente ocurre que la flexibilidad para
adaptar el contenido a un contexto de presentacin disminuye a medida que el
nmero de opciones de formato aumenta. Para un ejemplo sencillo,
supongamos que los elementos HTML <b> y <strong> se especificaron para
dar formato a texto en negrita. El <b> formato se pierde normalmente en
dispositivos que no admiten la presentacin en negrita, ya que se ha
especificado ninguna alternativa. XHTML 2.0 sustituye a la <b> elemento por el
<strong> elemento. La presentacin de este elemento se controla en el diseo
de la presentacin, de modo que se puede adaptar a las capacidades tcnicas
de un dispositivo, por ejemplo, mediante el uso de negrita subrayado si no est
soportada.

Mientras que el desarrollador especifica el aspecto fundamental de contenidos

multimedia en el lado del componente, en el lado de malla de la interaccin y
diseo funcional implcitamente resultan en contenidos sin formato.

Como ejemplo de las tareas involucradas en el diseo de navegacin, echemos

un vistazo a un diseo de la presentacin para las interfaces de navegacin.
Interfaces de navegacin deberan ayudar a encontrar respuestas a las tres
preguntas de navegacin importantes: (1) Dnde estoy? (2) Dnde estaba?
y (3) Dnde puedo ir? Un diseo de la presentacin es un ejemplo tpico de
las tareas para las que el conocimiento experto es ms importante y ms
factible que los mtodos formales. Los patrones de diseo son adecuados para
tales tareas (Rossi et al. 1999). Por ejemplo, podramos recurrir al uso patrn
para encontrar respuestas a las preguntas anteriores.
La pregunta "Dnde estoy?", A menudo se puede responder con la "migas de
pan" esquema de navegacin, basada en el cuento de hadas de Hansel y
Gretel. En una interfaz de usuario que involucra la navegacin a travs de
datos o pginas, migas de pan puede ser un mecanismo til para volver sobre
los pasos, dejando un rastro visual del camino recorrido. En cualquier
momento, el usuario puede volver sobre sus pasos para cualquier punto
visitado anterior.
Encontrar una respuesta a la pregunta "Dnde estaba yo?" No es tan fcil,
porque HTTP como una tecnologa Web ncleo es un protocolo sin estado, y
las tcnicas que unen son primitivas. El botn y listas de pginas visitadas
anteriormente "Volver" se utilizan generalmente en los navegadores. Este
sencillo ejemplo muestra que hay una necesidad de coordinar el diseo de la
presentacin y la interaccin. En la compra de artculos en la web, por ejemplo,
un usuario no puede utilizar el botn "Atrs" para deshacer una compra, y la
confusin correspondiente entre los usuarios normalmente se evita slo en
algunas aplicaciones web bien diseados. Otro ejemplo importante es la
consistencia, idealmente a travs de toda la Web. Diferentes presentaciones de
los vnculos y enlaces visitados previamente, an no visitados son un concepto
comn para diseos de presentacin. Jakob Nielsen recomienda no cambiar
los colores de los enlaces habituales, ya que, en este sentido, la consistencia
debe tener prioridad sobre la esttica (Nielsen 1997a).
Un enfoque popular para responder a la pregunta "Dnde puedo ir?" Consiste
en enumerar todos los niveles superiores de un sitio Web. En relacin con la
"migas de pan" esquema de navegacin y adecuada sealizacin de los
destinos que se puede llegar desde dentro de la pgina actual, el usuario
bsicamente obtiene informacin suficiente acerca de su posicin dentro de la
malla. Como mnimo, esta marca debe hacer hincapi en los enlaces en el
texto (o en otro medio); Adems, se recomienda que marca en la barra de
navegacin. La representacin grfica de la malla y la posicin actual dentro es
deseable, pero rara vez se utiliza en la prctica debido a la falta de normas o
mtodos generalmente aceptados y presentaciones.
5.3.2 ENFOQUES DE DESARROLLO INDEPENDIENTES DEL DISPOSITIVO

Requisitos mejorados en el resultado diseo de la presentacin de una

demanda creciente a considerar la tendencia hacia un gran nmero de
diferentes dispositivos habilitados para Web en el diseo de aplicaciones Web.
El espectro de estos dispositivos habilitados para Web incluye casi todas las
clases imaginables de dispositivos mviles, desde muy pequeos telfonos
mviles con navegadores WAP ms de los telfonos inteligentes y los
organizadores a los Tablet PC con pantallas sensibles al tacto. Dispositivos
cooperativos y muy grandes en este momento no son relevantes en la prctica.
Al mirar las caractersticas tcnicas de los dispositivos mviles, un conjunto
muy diferente de opciones de presentacin e interaccin resulta para su uso en
aplicaciones Web.
El diseo de la presentacin considera estos requisitos en el mbito de
actividades especiales para apoyar el desarrollo independiente del dispositivo
de aplicaciones. Por ejemplo, el dispositivo Grupo Independiente de Trabajo
(DIWG) (2001c W3C) del W3C est trabajando en este tema. Las tareas de la
DIWG incluyen aspectos del campo de desarrollo de aplicaciones, la
adaptacin de aplicaciones a contexto del usuario, y diferentes
representaciones de la informacin Seccin 5.6.1 discute enfoques relevantes
en ms detalle.
5.4 DISEO DE INTERACCIN
El diseo de interaccin se refiere a la interseccin de los elementos visuales,
dinmicos, funcionales y tcnicos de las aplicaciones Web. Su objetivo principal
es combinar estos elementos y suavizar los conflictos entre ellos, con el fin de
ofrecer a los usuarios una experiencia interesante y atractiva, adems de
consistente y fcil de entender. En esta seccin se sugiere un enfoque
sistemtico que divide a la interaccin de las aplicaciones web en cuatro
aspectos: la interaccin con el usuario, la organizacin de interfaz de usuario,
la navegacin y las actividades del usuario.
5.4.1 INTERACCION DEL USUARIO
Muchas de las llamadas caractersticas ", que permite la Web" en sistemas
heredados o aplicaciones tienen un enfoque de desarrollo comn: el diseo de
interaccin se reduce al diseo de la presentacin. Esto significa que las
aplicaciones se publican en la web simplemente traducir sus opiniones en
pginas HTML, al tiempo que introduce solamente algunas caractersticas
adicionales, tales como el acceso simultneo a bases de datos.
Como las aplicaciones web se hicieron ms sofisticados, un nmero creciente
de papeles se acoplaron en HTML: transporte de informacin, el diseo, la
interaccin del usuario, la navegacin, los procesos (como un subproducto de
enlace posterior recorrido), y acceso directo a los contenidos digitales. Junto

con las crecientes responsabilidades, HTML tambin evolucion de embalaje

ms funcionalidad para dar cabida a escenarios cada vez ms complejos. En
este proceso, la interaccin del usuario se convirti en una importante
limitacin: los servidores necesitan para generar una nueva pgina cada vez,
las aplicaciones se ejecutan ms lentamente, y puesto que las formas no son
suficientes para cubrir las tcnicas de interaccin de usuario ms avanzadas,
HTML como interfaz rpidamente se qued corto en comparacin con el
escritorio aplicaciones. Para superar estas limitaciones, en los ltimos aos se
han desarrollado varios enfoques tecnolgicos, con un amplio conjunto de
funciones que se superponen hace que sea difcil determinar qu combinacin
puede adaptarse mejor a las necesidades particulares de la aplicacin a
desarrollar.
Dos fuerzas opuestas se encuentran en el corazn del problema: la cantidad de
funcionalidad de la interfaz qu necesitamos con el fin de mostrar los datos y
realizar operaciones; y en segundo lugar, cmo los datos de uso intensivo es la
aplicacin en absoluto (vase la Figura 5-2). Las evidentes ventajas y
desventajas son la portabilidad, proveedor de tecnologa (in) dependencia y
usuario (cliente) la satisfaccin.
Vamos a esbozar un criterio para ayudar a organizar las decisiones de
desarrollo a realizar por regresar a las propiedades bsicas de una aplicacin
de software: el mantenimiento, la reutilizacin, la escalabilidad, la sostenibilidad
y la capacidad de expansin (Carnegie Mellon Software Engineering Institute
2005) (ver Tabla 5-1).
Capacidad de mantenimiento se refiere al esfuerzo medio para localizar y
corregir un fallo de software, y se mide generalmente por la sencillez, la
concisin, la modularidad y la auto-descriptivo. Las aplicaciones Web que
proporcionan interfaces de usuario atractivas, altamente interactivos
generalmente se basan en tecnologas XML (AJAX) ActiveX / applets o
Asynchronous JavaScript y.

Estos usuarios y las interfaces suelen tener la presentacin, los datos y la

lgica estrechamente unidos, dando lugar a dificultades en el desarrollo y
mantenimiento. Por otro lado, existen alternativas como DHTML y Portlets que,
debido a una separacin estricta de las preocupaciones, permiten una mayor
modularidad y facilidad de mantenimiento general.
Reutilizacin se refiere a la posibilidad de factorizar el cdigo de una
aplicacin en particular para su uso en otras aplicaciones sin (muchos) los
cambios. Tecnologas de desarrollo proporcionan diferentes mecanismos de
reutilizacin como bibliotecas de cdigo / script. Como las primeras pginas
web deben ser generados de forma rpida, la necesidad de buscar la
reutilizacin a nivel de interfaz de usuario a menudo se descuida.
Escalabilidad refiere no slo a la capacidad de mantener grandes cantidades
de usuarios, sino tambin, desde un punto de vista del desarrollo, a la
capacidad de diferentes actividades de desarrollo exigentes que se pueden
llevar a cabo en paralelo por un equipo de desarrollo. Algunas de las
tecnologas basadas en ActiveX permiten funcionalidad sorprendente, sin
embargo, para proyectos ms grandes, su naturaleza atmica y el nivel de
acoplamiento de los problemas de desarrollo hace que sea muy difcil para un
grupo de desarrolladores de estar trabajando en la misma aplicacin
simultneamente. Tecnologas basadas en XML (XHTML, XSL / T) son ms
escalables desde el punto de vista del desarrollo, ya que las aplicaciones
puede ser estructurado en diferentes normas, XML separadas que se asignan
de forma ms natural en diferentes roles en un desarrollo o grupo.

Por ltimo, tambin consideramos la capacidad de expansin de un sistema, es

decir, el grado de esfuerzo necesario para mejorar o modificar la eficiencia de
las funciones de software ', y la sostenibilidad que se discutir a fondo en la
seccin 5.6.
5.4.2 ORGANIZACIN DE INTERFAZ DE USUARIO
Por su naturaleza, el aspecto discutido aqu est estrechamente relacionado
con el diseo de la presentacin, pero est determinada por aspectos de
integracin y no por aspectos de presentacin. Interfaz de usuario de una
aplicacin web a menudo tiene que representar a una gran cantidad de
informacin, las operaciones en esta informacin y las relaciones entre esta
informacin. El reto es entonces para asignar adecuadamente este gran
nmero de aspectos. Como primer paso hacia la solucin de este problema,
podemos agrupar los elementos en los canales de interaccin. Esta agrupacin
debe ser clara y consistente a travs de toda la interfaz. La mayor parte del
grupo de entrada y la interaccin debe seguir siendo el mismo durante una
sesin, mientras que el grupo de salida general cambia.
Un problema frecuente se produce cuando un nodo contiene ms informacin
que cabe en una pantalla. Cuando tratamos de sopesar los aspectos de diseo
de presentacin en contra de los aspectos de diseo de interaccin, podemos
dejarnos guiar por las siguientes preguntas: Deberan las dimensiones de la
pantalla tienen prioridad sobre el concepto de que los nodos son unidades
atmicas (y unidades de navegacin)? Debe o puede un nodo puede dividir
en varios nodos ms pequeos? Puede la navegacin adicional ser una
alternativa al desplazamiento? Cmo debe el comportamiento complejo de la
interfaz de usuario y la portabilidad equilibrarse unos contra otros? Al igual que
en el apartado anterior, la mezcla de tecnologa en particular tiene
implicaciones, esta vez en trminos de la semntica de navegacin (si la
navegacin se activa para seguir leyendo o, en cambio, para acceder a un
tema relacionado), portabilidad y facilidad de uso. Podemos diferenciar distintos
enfoques (vase el cuadro 5-2):
1. El nodo completo se enva al usuario como HTML. La pgina HTML incluye
cualquiera de las secuencias de comandos o una tecnologa plug-in
personalizado para dejar que los subconjuntos de acceso de usuarios de la
informacin. El uso de programacin integrado evita an ms, la navegacin
innecesaria.
2. El nodo completo se enva al usuario como una pgina HTML grande sin
scripts. El usuario selecciona vnculos relativos de la pgina para navegar en la
pgina.

3. Una vista parcial al nodo se enva al usuario. Esta pgina muestra

significativa organiz subconjuntos de informacin. El usuario puede navegar a
otras pginas para leer completamente la informacin deseada.

Pginas enlazadas a evitar excesivamente utilizar el desplazamiento pero

conducen a la navegacin adicional y, en consecuencia, a la latencia ms
grande cuando la recuperacin de la misma informacin de nuevo. Estudios de
usuarios recomiendan prefiriendo desplazamiento sobre medidas adicionales
de navegacin (Nielsen 1997a), sin embargo, hemos mencionado la violacin
del concepto de hipertexto de nodos atmicas en el apartado 5.2.1. Un
concepto global (desaparecidos en HTML, como critic antes) podra
ayudarnos a tomar las dos reclamaciones en cuenta.
Generalmente aceptado las reglas para el equilibrio de fuerzas "de diseo" uno
contra el otro, normalmente fallan debido a la fuerte influencia de las
caractersticas especficas de la aplicacin Web. Por ejemplo, las aplicaciones
de intranet pueden hacer suposiciones acerca de los navegadores utilizados.
Por el contrario, los proveedores de comercio electrnico tienen que centrarse
en la portabilidad para asegurarse de que todos los clientes potenciales pueden
acceder a sus pginas.
5.4.3 DISEO DE NAVEGACIN
El resultado de un diseo de navegacin es doble: los usuarios pueden
acceder a los elementos, por una parte, y la estructura de navegacin en la otra
mano. Elementos convierten en nodos en el caso ms simple.
La estructura define las relaciones entre los nodos. Estas relaciones ms tarde
se convertirn en enlaces visibles anclas en la interfaz de usuario. En este
escenario, el diseo de interaccin define los aspectos necesarios para la
propia navegacin (ancla y URL), y elementos requeridos para los usuarios
para orientarse.

5.4.4 DISEO DE UNA REPRESENTACIN ENLACE: LAS ANCLAS

Son correspondencias visibles de URLs y como tales, tienen que transmitir

tanto las motivaciones para que los usuarios activen ellos y las posibles
consecuencias. Desde la implementacin basada en HTML de la Web se
mezcla el concepto de anclaje con el concepto link en un elemento
unidireccional nica, <a>, la semntica se funden en consecuencia. Esta es la
razn por la cual los usuarios no pueden estar seguros de lo que las posibles
consecuencias sern cuando se sigue un enlace (ver Tabla 5-3).
El texto de un ancla idealmente debera explicarse por s mismo (2001c W3C).
Tambin es til para clasificar los enlaces por categoras. Adems, los iconos
se pueden utilizar dentro de las anclas de visualizar enlaces.
Si bien esas anclas y los iconos se pueden especificar estticamente, las
propiedades que cambian dinmicamente (por ejemplo, si es o no ciertos tipos
de medios se pueden abrir) deben ser marcadas por el uso de scripts
incrustados en estas pginas.
5.4.5 PROYECTOS ENLACE INTERNOS: LA URL
Procesos de navegacin se activan mediante la activacin de los anclajes en la
interfaz de usuario. Estos anclajes representan enlaces (URLs en HTML) que
especifican el destino del proceso de navegacin debe conducir a. Las anclas
deben, por lo tanto, ser claras, concisas, de larga vida, y apuntan a una
direccin absoluta.
La introduccin de XML signific un gran paso adelante para los enlaces y
anclajes. Estndares XML combinados como XPath, XPointer y XLink, ofrecen
una infraestructura para la funcionalidad general hipermedia, llegando mucho
ms all de enlaces HTML. Captulo 6 discutir los detalles tecnolgicos, por lo
que vamos a limitar esta discusin a un breve vistazo a los aspectos de diseo
relevante.
En general, es importante para los diseadores de aplicaciones Web para
conocer las capacidades ampliadas de enlaces en XML. Por ejemplo, los
llamados enlaces multidireccionales se pueden usar para enlazar un
documento XML con varios recursos. Esto significa que un solo enlace
integrado vincula estos recursos, a fin de que se pueda llegar en cualquier
secuencia. Por ejemplo, un enlace en un ndice podra apuntar a todas las
ocurrencias de las palabras "Ingeniera Web". Despus, los usuarios pueden
navegar por estos hechos arbitrariamente y utilizar el mismo enlace para saltar
de nuevo al texto original. Adems, los enlaces XML son auto-descriptivo, lo
que significa que un enlace puede contener texto arbitrario que describe los
recursos que apunta.
Desde XLink soporta ambos enlaces externos e internos, esta tecnologa
facilita la introduccin y el uso cooperativo de las bases de datos de enlace. El

enorme nmero de enlaces en la Internet global crea el deseo de manera

eficiente y utiliza de forma conjunta estos enlaces. XLink tiene una
caracterstica para definir las bases de datos de enlaces relevantes para los
documentos. Cada vez ms se han propuesto Equipamientos (suscripciones o
perfiles) para hacer enlaces disponibles en general.
5.4.6 NAVEGACIN Y ORIENTACIN
Herramientas de navegacin deberan ayudar a limitar el esfuerzo cognitivo
para los usuarios. Identificamos tres estrategias bsicas para lograr este
objetivo:
Organizacin de navegacin: Esta estrategia determina toda la estructura de
navegacin.
La ayuda Orientacin: Esta estrategia responde a las preguntas y "Dnde
estaba yo?", Bajo los aspectos de interaccin del diseo de la presentacin,
como se explica en la seccin 5.3.1 "Dnde estoy?".
Percepcin Enlace: Esta estrategia se refiere principalmente a cuestiones
relacionadas con la asociacin de enlaces a la motivacin y la consecuencia,
como se explica en la seccin 5.4.3.
Es obvio que esta seccin tiene que hablar sobre todo el primer punto, que an
no se ha abordado.
Se refiere a la organizacin significativa del espacio de navegacin en un
diseo, incluido el apoyo de las actividades de navegacin significativa, por
ejemplo, al evitar la redundancia de navegacin. Un ejemplo de despidos es un
ndice (por la lista de un resultado de bsqueda, o como estructuras de
acceso), donde la nica manera para que los usuarios acceder a los elementos
de ndice est dando un paso atrs para el ndice. Este tipo de navegacin se
llama navegacin en forma de estrella. Incluso la posibilidad de permitir a los
usuarios navegar de vuelta a la anterior elemento y transmita al siguiente
elemento sin necesidad de primer regreso al ndice sera una mejora menor.
Esta mejora solo reducira el nmero de pasos de navegacin promedio
(nmero de enlaces a seguir) a la mitad.
A medida que el tamao de una aplicacin web se incrementa, los usuarios se
benefician cada vez ms de orientacin y navegacin ayudas adicionales. Por
mencionar un ejemplo, echemos un vistazo a un objeto, que est siempre
activo y perceptible, y que sirve como un ndice para objetos adicionales de
navegacin (nodos y sub-ndices).
Este objeto de referencia activo, incluyendo representaciones de objetos de
destino, permanece visible, ayudando a los usuarios, ya sea para ver objetos
de destino o para seleccionar objetos relacionados. En cuanto a revertir la

navegacin, no slo es la informacin sobre la ruta de acceso a la posicin

actual puesto a disposicin, sino tambin abreviaturas de los ndices y los
nodos a lo largo de ese camino.
5.4.7 DILOGO ESTRUCTURADO DE ACTIVIDADES COMPLEJAS
En el diseo de aplicaciones Web complejas, a menudo tenemos que hacer
extensivos los procesos que los usuarios deben activar visible. "Amplia" puede
significar que una actividad se extiende sobre varias pginas.
En este caso, podemos identificar tres categoras de navegacin hacia
adelante: (1) Una accin se desencadena como consecuencia del paso de
navegacin. (2) Las llamadas de navegacin "slo" una pgina adicional, por
ejemplo, en la pgina 2 de un formulario. (3) El paso de navegacin conduce a
un nodo que no participan directamente en la actividad (informacin, etc.).
Estas alternativas ponen en peligro tanto la claridad para el usuario y la
consistencia de apoyo a las actividades. Un ejemplo es el ltimo paso de una
actividad, que sella acuerdos vinculantes entre un usuario y una aplicacin
web, la llamada caja. Si un usuario decide mudarse a una pgina
independiente antes de completar el pago y envo, entonces tenemos que
aclarar el estado de la actividad est en. Lo mismo ocurre cuando un usuario
pulsa el botn "Atrs" antes de que se complete el pago y envo.
Estos problemas indican que, desde la perspectiva de interaccin, las
caractersticas de un proceso de negocio difieren marcadamente de las de una
aplicacin de hipertexto. Tabla 5-4 resume estas caractersticas.
Enfoques para implementar procesos de negocio en las aplicaciones Web van
desde la simple HTML (procesos son una navegacin subproducto) de mtodos
y herramientas para la gestin del flujo de trabajo (hipertexto flujo de trabajo
impulsado). En el segundo caso, las interacciones de flujo de trabajo
generalmente no se asignan al sistema de navegacin de una aplicacin web
de forma automatizada. Definiciones de procesos generalmente describen
cmo se incrustan en los procesos de flujos de trabajo, pero no cmo los
usuarios interactan con procesos.
Por lo tanto, el diseo de interaccin debe tratar de asignar tareas complejas
por hbilmente utilizando las posibilidades de navegacin.

5.4.8 INTERACCIN CON LA TECNOLOGA Y ARQUITECTURA

Hemos subrayado en repetidas ocasiones que el diseo, la arquitectura y la

tecnologa estn estrechamente relacionados en el desarrollo de aplicaciones
Web. Esto se refiere sobre todo la transicin de simples a complejas
actividades. Esta transicin tiene un impacto en la tecnologa y el software de la
arquitectura de nuestra eleccin, siendo a veces una transicin dura a las
arquitecturas ms complejas y mejores tecnologas escnicas como nuestra
aplicacin Web evoluciona. Naturalmente, tal transicin tiene un impacto en el
diseo, tambin, que es la razn por la cual esta seccin se relaciona
estrechamente con los captulos 4 y 6.
Actividades simples que recuperan informacin pueden ser implementadas por
simples "arquitecturas de 3 capas", que utilizan plantillas para generar las
solicitudes de cliente salidas HTML coincidentes (por ejemplo, basado en
ASP.NET, JSP o PHP). En tales arquitecturas simples, el control de la
aplicacin y las lgicas de aplicacin estn incrustados en el cdigo fuente de
la escritura de las plantillas. A medida que la informacin que se ha
representado se hace ms compleja, por ejemplo, cuando se combina de
diversas fuentes, los scripts pueden llegar a ser muy grande. Entonces sera
mejor sustituir lenguajes de script por las etiquetas del lado del servidor
definidos por el usuario. Estas etiquetas permiten separar y ocultar el cdigo
necesario para la representacin de la pgina HTML. Sin embargo, incluso si
separamos HTML en el cdigo, la lgica de control en las etiquetas definidas
por el usuario todava se implementa por separado para cada nodo. Cada uno
de ellos determina la vista posterior de forma independiente y lo reenva a la
plantilla adecuada. Este concepto se puede comparar con el uso de go-a los
comandos en la programacin temprana. Los inconvenientes de este concepto
en materia de mantenimiento, comprensibilidad, y modularizacin fueron
criticados en la dcada de 1960. Podemos tratar de superar "ir a la
programacin" mediante la adopcin de una nocin bsica de ingeniera de
software para productos de software interactivo complejos, es decir, utilizando
el Modelo-Vista-Controlador (MVC), la arquitectura (Krasner y Pope 1988)
analiza en el captulo 4.
Para los procesos de negocio complejos, sin embargo, el concepto MVC
golpea sus lmites. No es compatible con las transacciones que requieren ms
de una entrada del usuario. En consecuencia, estas transacciones no pueden
extenderse por ms de un nodo (una pgina, una sola accin). Esto significa
que el concepto tiene que ser desglosado, "la prohibicin de" transacciones
complejas en la lgica de la aplicacin (modelo). En general, el papel del
controlador en "Model-2" aplicaciones web es bastante subdesarrollado.

El controlador recibe eventos de los usuarios y los asigna a las llamadas

coincidentes. Ejemplos Tecnolgicos de mapeo evento de llamada son los

archivos de configuracin basados

(http://jakarta.apache.org/struts/).

en

XML

en

Apache

Struts

Los fabricantes tambin tildan conceptos regulador demasiado simples como la

fuente de complejidad y redundancia adicional en el cdigo (2003c Sun
Microsystems, Microsoft 2003). Un buen ejemplo es el problema bien conocido
que se repiten los parmetros por pgina (nodo) en mensajes de solicitud
tienen que estar autenticado, validado y procesado por separado. Sin embargo,
diferentes conclusiones se derivan de esta situacin.
En sus J2EE Arquitectura Blueprints, Sun favorece controladores ms
especializados, separados en dos partes: una frontController y ViewDispatcher.
.NET Utiliza el concepto herencia en ASP.NET para agrupar el comportamiento
comn de todos los controladores en una PageController conjunta, que se
coloca en la parte superior de la jerarqua.
5.5 DISEO FUNCIONAL
El diseo funcional tambin tendr que sopesar los aspectos tecnolgicos que
tienen un fuerte impacto en la aplicacin Web en desarrollo. Tenemos que
observar la conmensurabilidad de nuestros medios, pero nuestras aplicaciones
deberamos ser ampliable, escalable y fcil de mantener, entre otras cosas.
Dificultades particulares se ven en la interaccin de los componentes.
Aplicaciones web como tickers de noticias pueden hacer normalmente sin
soporte de transacciones, mientras que las tiendas en lnea pueden tener que
mapear muchas fases del producto, desde la configuracin sobre el pedido de
reparar. Esto requiere de la transaccin y el flujo de trabajo de apoyo y la
integracin de las bases de datos existentes y sistemas de software. Captulo 4
discute enfoques apropiados en relacin con Enterprise Application Integration
(EAI).
5.5.1 INTEGRACIN
Podemos integrar sistemas en tres niveles, que han de ser interpretados como
subniveles del diseo funcional: el nivel de datos, el nivel de aplicacin y el
nivel de proceso.
En la integracin en el nivel de datos, nos aseguramos de que los datos entre
las representaciones de las diferentes aplicaciones se transforman y se copian.
Los ejemplos incluyen pasos de transformacin primitivas entre la exportacin
de datos de una aplicacin y la importacin de datos en otra aplicacin, o el
uso de JDBC para vincular las bases de datos. Este enfoque no implica las
propias aplicaciones, y no vamos a validar los datos.
En la integracin en el nivel de aplicacin (tambin llamado nivel de objeto), la
interaccin se produce con el API, lo que significa que el tiempo y la semntica
estn estrechamente intercalados. Sin embargo, muchos detalles dependen del

middleware utilizado para el acoplamiento; este tema ser discutido en la

prxima seccin.
Integracin en el nivel de proceso normalmente es visto como el ms alto nivel,
ya que modela los modelos de negocio de forma independiente de la
infraestructura utilizada.
5.5.2 LOS PARADIGMAS DE COMUNICACIN Y MIDDLEWARE
Middleware se ha mencionado anteriormente como una tecnologa para
aplicaciones de enlace. Existente enfoques difieren fuertemente en sus
complejidades y objetivos, como se explica en el captulo 4 y en la seccin
5.2.3, donde describimos brevemente la comunicacin entre procesos (IPC),
Remote Procedure Call (RPC), Basado en eventos de Comunicacin (EBC),
Message-Oriented Middleware (MOM), y los enfoques orientados a objetos
distribuidos.
Los enfoques basados en XML mencionados en diferentes lugares en este libro
se resumen a continuacin en la preparacin para los siguientes sections.XML
es una lengua franca emergente de Internet es la base no slo para una
"mejor Web / HTML" y la especificacin porttil de semi datos -estructurados,
sino tambin para los nuevos estndares de aplicaciones distribuidas, en
particular el Protocolo simple de acceso a objetos (SOAP), el Web Service
Description Language (WSDL), y Universal Description, Discovery y la
Integracin (UDDI), por mencionar algunos. JABN controla los mensajes y
llamadas a travs de diferentes protocolos de Internet, por ejemplo, HTTP,
SMTP, etc. WSDL sirve para describir interfaces y servicios Web de
direcciones, y UDDI proporciona una especie de base de datos para publicar y
buscar Web servicios (vase el captulo 6 para ms detalles).
5.5.3 DISTRIBUIDOS APLICACIONES WEB CROSS-CORPORATIVAS
El aspecto de distribucin ha ganado cada vez ms importancia en la
aplicacin del lado del software de las aplicaciones Web. As como enlaces a
pginas Web remotos son comunes hoy en da, el software distribuido
emerger desde el acceso de malla a las aplicaciones Web remotas en el
futuro. Esto se puede interpretar como la comunicacin-servicio-servicio, donde
el servicio trmino caracteriza funcionalidad ofrecida por una interfaz bien
definida. Servicios Web cada vez se han aplicado sobre la base de XML. Por
ejemplo, eBay proporciona no slo un sistema de autenticacin nica, pero
tambin es compatible de Microsoft Passport, y Google le permite integrar su
funcin de bsqueda en aplicaciones externas a travs de SOAP. Este
"mercado de componentes abierta grano grueso" tiene consecuencias
dramticas para los diseadores de sistemas. El uso de funcionalidades
desarrolladas externamente ahorra los costes de desarrollo y la calidad de los
componentes (servicios) puede ser mejor, pero esto normalmente se produce a

costa de perder "control" sobre estos servicios. Por ejemplo, los agujeros de
seguridad en Pasaporte han disminuido el entusiasmo inicial, y el umbral de
aceptacin de servicios externos en aplicaciones crticas de seguridad es muy
alta. Por otro lado, un enfoque basado en componentes puede ayudar a
justificar el dinero que gastamos para los productos de software de alta calidad
debido a su alto grado de reutilizacin, y establecer la confianza en la calidad
de estos componentes. En el mediano plazo, por lo tanto, esperamos un
mercado para servicios web, comparable a la riqueza de los servicios ofrecidos
en nuestra vida cotidiana. Sobre la base de XML y tecnologas bsicas como
SOAP, WSDL y UDDI, otros protocolos actualmente estn surgiendo, de los
cuales algunos son complementarios y algunos estn compitiendo.
Estos son los protocolos del tipo necesario para manejar los negocios a travs
de las fronteras de una empresa. Figura 3.5 ofrece una visin general de cmo
estos protocolos dependen unos de otros.

Las especificaciones de servicios web Transacciones (WS-Transaction)

describen un marco extensible para coordinar acciones en las aplicaciones
distribuidas (WS-coordinacin) y tipos especficos de coordinacin para las
transacciones atmicas y las transacciones comerciales (IBM 2005a).
Transacciones atmicas le permiten coordinar acciones cortas basadas en el
protocolo 2-Phase-Commit. Este enfoque es adecuado especialmente para
encapsular formatos propietarios de sistemas orientados a las transacciones
actuales. Actividades empresariales en contraste se destinan a acciones de
larga vida, ya que no bloquean los recursos durante un largo perodo de
tiempo.
El Servicio de Coreografa Interfaz Web (W3C 2002a) y la competencia de
servicios web Conversacin Idioma (2002b W3C) ofrecen una forma de
especificar los mensajes que participan en un servicio y sus estructuras, as
como la secuencia en que se deben intercambiar estos mensajes. BPEL4WS
(Business Process Execution Language para Servicios Web), o BPEL para

abreviar (IBM 2005a), se basa en el anterior, lo que permite la descripcin de

los procesos de negocio complejos (workflows). BPEL se puede utilizar para
describir flujos de control y dependencias entre los procesos de participantes.
Adems de BPEL4WS y WSCI / WSCL (que es adecuado no slo para el
propsito discutido aqu), un nmero de otros protocolos especficos del
fabricante estn disponibles para describir procesos de negocio de XML.
(Bernauer et al., 2003) incluye una comparacin ms detallada de los
protocolos mencionados aqu y otros protocolos, que no se basan en la pila de
protocolos de servicios Web.
Otro tema importante para las empresas en los aspectos de seguridad de las
preocupaciones de Internet, se indica brevemente en la Figura 5-3 con WSSecurity como ejemplo. La autenticidad, confidencialidad, integridad y no
repudio juegan un papel central en este tema. Captulo 13 discutir este tema
en relacin con los servicios Web.
Con base en el enfoque de negocio a negocio (B2B), aplicaciones web parecen
evolucionar hacia grandes sistemas distribuidos en muchas computadoras.
Este enfoque integra no slo las aplicaciones internas de la empresa, sino
tambin las aplicaciones de terceros (servicios). Algunas empresas ya tienen
un amplio acceso a las aplicaciones de terceros en virtud de la Cadena de
Suministro lema Management (SCM). Se espera que los servicios Web para
estandarizar este enfoque en la Web. Alguna investigacin el trabajo ya se ha
llevado a cabo para seleccionar los servicios sobre la marcha segn sea
necesario, dependiendo de la situacin. El servicio de aprovisionamiento
Markup Language (SPML), que se puede utilizar para la facturacin de los
servicios utilizados, representa un primer paso en esta direccin.
5.6 PERSPECTIVAS
La era llamada post-PC ya no est dominada por una sola clase de dispositivos
(PC), pero caracteriza por un gran nmero de diferentes dispositivos. Durante
los prximos aos, los dispositivos mviles sern de gran importancia, como se
mencion en la seccin 5.3.2. Por lo tanto, para ser sostenibles, las
aplicaciones Web tienen que estar preparados para esta tendencia hoy en da,
es decir, considerando dos conceptos importantes, es decir, conciencia
contexto y la independencia de dispositivo, que ser discutido en las secciones
5.6.1 y 5.6.2, respectivamente. Desde el primero de estos dos conceptos se
encuentra todava en fase de investigacin, la seccin 5.6.1 acaba de explicar
los aspectos que deben observarse en el diseo de aplicaciones web sensibles
al contexto. Seccin 5.6.3 se centrar exclusivamente en dar una visin de los
conceptos nuevos o que faltan en la ingeniera que generalmente podran
promover la sostenibilidad de las aplicaciones Web en el futuro.
5.6.1 APLICACIONES SENSIBLES AL CONTEXTO

Una aplicacin sensible al contexto es una aplicacin que tiene el conocimiento

especfico del usuario - contexto de un usuario - personalizar de manera ptima
tanto su interaccin y su funcin. Adems, la conciencia contexto conduce a
nuevos tipos de aplicaciones, por ejemplo, servicios basados en localizacin
(LBSS), por mencionar un ejemplo. Dependiendo de la ubicacin, podramos,
por ejemplo, mostrar informacin personalizada acerca de los restaurantes en
el barrio de un usuario. Una gran cantidad casi ilimitada de variantes ms
sofisticadas es concebible, por ejemplo, las preferencias culinarias de un
usuario, o la informacin de trfico local de electrnica.
Una serie de problemas tendr que ser resuelto para poder introducir
ampliamente este tipo de aplicacin sofisticada. Estos problemas no slo son
de naturaleza tcnica, por ejemplo, con respecto a hacer la informacin de
contexto requerida disponible. Los operadores de telecomunicaciones han
empezado tmidamente a disposicin de terceros con medidas tcnicas e
interfaces para LBS, y normalmente pedir a los altos precios. En vista de las
enormes ventas potenciales, los operadores de telecomunicaciones parecen
estar interesados en ofrecer servicios sensibles al contexto a s mismos oa
travs de socios seleccionados. La falta de competencia y, en consecuencia, la
baja calidad de los servicios que actualmente ofrece hacen de este modelo de
negocio parece dudosa.
Otro obstculo importante para la introduccin de aplicaciones web sensibles al
contexto es que los usuarios quieren confidencialidad. LBSS en particular, se
han discutido con el argumento de si es o no terceros pudieran reconstruir y
mal uso de la localizacin del usuario. Los beneficios de las aplicaciones web
sensibles al contexto, as como una creciente confianza y una seguridad mejor
tcnica debe ayudar a superar estos obstculos en el mediano plazo.
Se ha observado claros progresos en el apoyo tcnico para las aplicaciones
web sensibles al contexto.
Como se describe en la seccin 5.5, existen protocolos independientes de la
plataforma para describir y combinar servicios web. Tambin, hay bases de
datos pblicos para registrar los servicios web y de buscar los servicios
adecuados. Sin embargo, esto slo crea posibilidades para recopilar
informacin sobre contextos de usuario y servicios de enlace. El problema con
respecto a las descripciones de contexto uniformes sigue sin resolverse. Por
ejemplo, un operador de telecomunicaciones puede recoger la ubicacin de un
usuario de la ID de celda, y el suministro de las coordenadas GPS de la
estacin base mvil con el que se ha registrado ese usuario. La triangulacin
se puede utilizar hasta cierto punto para reducir la ubicacin. Sin embargo,
muchas aplicaciones, tales como los sistemas de informacin de trfico local o
navegacin peatonal requieren nombres de las calles (o incluso puntos de
referencia) en lugar de las coordenadas geogrficas. Los esfuerzos de

normalizacin correspondientes estn en marcha, pero muchos detalles

todava tienen que aclarar en proyectos de investigacin. Si nos fijamos en el
ejemplo de una gua de restaurantes, aplicaciones Web y luego en todas partes
se requieren clasificaciones de los restaurantes o los platos en todas las
salidas gastronmicas aceptado. Tal demanda problemas para los esfuerzos en
el campo de la Web semntica (vase el Captulo 14). Los dos ejemplos que se
utilizan en esta seccin muestran que una amplia normalizacin es uno de los
requisitos ms importantes para el software sensible al contexto omnipresente.
5.6.2 LAS SOLICITUDES INDEPENDIENTES DEL DISPOSITIVO
Los fabricantes de herramientas de ingeniera Web han entendido desde hace
tiempo el problema de las aplicaciones deviceindependent pero han sugerido
demasiado optimista de que el problema podra resolverse mediante la
transformacin de un genrico de presentacin (basado en XML) a los
lenguajes de marcas utilizados por los dispositivos (HTML, WML, etc. ).
Diferentes implementaciones de aplicaciones de usuario, las directrices del
sistema operativo, y las diferencias fsicas y tcnicas de los dispositivos
representan grandes obstculos en la prctica. Por mencionar algunos
ejemplos: implementaciones en parte incompletas y diferentes versiones de
HTML, diferente medida de los elementos disponibles de interfaz de usuario
(por ejemplo, cuadros de lista, botones de radio), tamao de pantalla y de
orientacin, y de poder de cmputo limitado o ancho de banda de la red. Estas
restricciones han dado lugar a varias propuestas, entre ellas WML como un
lenguaje de marcado especfico para dispositivos mviles.
Podemos bsicamente identificar dos enfoques alternativos en el desarrollo de
aplicaciones independientes del dispositivo. El primero es un enfoque
"minimalista", lo que reduce los elementos utilizados a un mnimo, suponiendo
que todos los dispositivos posibles apoyarn estos. Un inconveniente
importante de este enfoque es que tanto la facilidad de uso y la apariencia de
las aplicaciones se reducen a sabiendas. El segundo enfoque desarrolla
aplicaciones adaptativas, integrando el contexto de usuario en varios niveles.
En este enfoque, la independencia de dispositivo considera no slo los
aspectos del dispositivo fsico real, pero se funde a la perfeccin con el
conocimiento del contexto se discute en la seccin 5.6.1. Por la propia
aplicacin, diversas tecnologas y estndares estn disponibles y otros estn
en las obras de los organismos de normalizacin. Sobre la base del trabajo de
la CC / Grupo de Trabajo del PP, el Grupo de Trabajo de Independencia de
Dispositivo (DI WG) (2001c W3C) del W3C definen la CC / PP estndar y un
protocolo de transmisin perteneciente a describir y transmitir contextos de
usuario y dispositivo. CC / PP puede ser utilizado para describir de manera
uniforme perfiles de contexto y transmitirlas a un servidor de aplicaciones.

Mdulos de adaptacin actual interpretan partes del protocolo HTTP (por

ejemplo, la identificacin de agente de usuario) como una alternativa a ceder informacin de contexto - propietario. Y diferentes tecnologas se usan para
adaptar realmente aplicaciones. Lenguajes de script (por ejemplo, JSP / ASP),
se combina con los modelos de transformacin (XML, XSL, XSLT), se utilizan
con frecuencia para la adaptacin en los servidores, mientras que los
estndares como XHTML y CSS en relacin con scripting (JavaScript) se
utilizan para transformacin en los clientes. Servidores de transcodificacin
utilizan un enfoque alternativo para la adaptacin de aplicaciones, en donde la
adaptacin transforma una descripcin genrica de una aplicacin en un nuevo
formato de destino.
Al principio, la gente trat de transformar una descripcin basada en HTML
existente en un nuevo formato de destino (por ejemplo, WML) sin aadir
informacin semntica, que no produjo resultados satisfactorios. Hoy en da, la
adaptacin se produce en varios niveles de una aplicacin web. Por ejemplo,
(1) la complejidad de toda la aplicacin est adaptada para el contexto de
usuario y el dispositivo disponible (adaptacin de la lgica de la aplicacin); (2)
el contenido y el diseo de pginas estn optimizadas; y (3) la presentacin
est optimizada para la abordado / aplicacin existente de un lenguaje de
marcas.
5.6.3 REUTILIZACIN
Reutilizacin ha recibido menos que su parte justa de las tecnologas de
aplicaciones Web, y algunas tecnologas an carecen de prerrequisitos
conceptuales para reutilizacin. El hecho de que los conceptos apropiados
juegan un papel importante en el diseo se puede ver en la programacin
orientada a objeto o en el diseo orientado a objetos. Las siguientes
subsecciones discutirn brevemente tres campos de investigacin y desarrollo
que prometen promover sustancialmente la reutilizacin como ejemplos
representativos.
CONCEPTOS PARA MALLAS
El apoyo actual para los conceptos que permiten el diseo elegante mallas
compuestas de elementos y enlaces es pobre; es insuficiente para el diseo de
software y para el diseo de la informacin de las aplicaciones Web. Lo que se
necesita son particularmente conceptos para agregados (vase la seccin
5.2.2) y las jerarquas de los mismos.
TIPOS DE CONCEPTOS
Tipos de elementos y enlaces similares a los introducidos en la seccin 5.2.4
eran bastante comunes en el diseo de la informacin durante la era de HTML,
y ahora estn experimentando un renacimiento con XML (aunque an no

popular). En el diseo de software (ver UML), tipos (clases) de elementos estn

soportados de manera satisfactoria, y tambin son compatibles con las
jerarquas de clase y conceptos de componentes modernos tecnologa de
software orientado a objetos. Sin embargo, no hay notacin diseo actual tiene
conceptos uniformes para tipificar los elementos y enlaces en el diseo de Web
integrado. Si bien los conceptos de tipo de elementos y vnculos (y tambin
para los anclajes, que no se describen aqu por razones de espacio) son
relativamente fciles de desarrollar y han sido utilizados por los diseadores
web, conceptos de tipo de mallas siguen siendo un desafo para ms trabajo de
investigacin (ver Muhlhauser et al. 1998a, 1998b Muhlhauser). En particular, el
diseo de mallas reutilizables debe ser de primera importancia en esta
investigacin, por lo que, por ejemplo, las mejores prcticas podran ser
modelados en el diseo de sitios web, extensas presencias corporativas,
conceptos de formacin basados en la web, etc. Tal diseo de malla conceptos
deben permitir que describe la dinmica, es decir, los cambios en el nmero y
disposicin de los elementos y enlaces, tanto ms de ciclo de vida de una malla
y en diferentes encarnaciones de un tipo de malla. A lo sumo, el Resource
Description Framework (RDF) puede ser considerado un enfoque rudimentario
en esta direccin.
COMPOSICIN CONCEPTOS ALTERNATIVOS
Las mallas discutidas aqu representan grafos dirigidos. En vista de los
conceptos de programacin avanzadas, por ejemplo, la comunicacin basada
en eventos y conceptos de hipertexto avanzadas como n-arias enlaces (que en
parte se admiten en los estndares basados en XML), se supone que el
concepto de una "malla" como tal tendra que ser mejorada. Sin embargo, no
hay trabajo actual en esta direccin se conoce a los autores.
5.7 RESUMEN
La web comenz como una infraestructura de hipertexto flexible basado en
conceptos SGML. Su simplicidad tecnolgica y visin unificadora sobre otras
tecnologas existentes, como Gopher, FTP, Telnet y Usenet (NNTP)
contribuyeron a su adopcin generalizada. Una evolucin tecnolgica rpida
transform la antigua infraestructura de documento de hipertexto en una
interfaz de software remoto. La mezcla de documentos y tareas introdujo
nuevos temas en la interfaz de usuario, tales como su organizacin, la
interaccin del usuario, y los factores de navegacin que deben ser abordados
con el fin de crear aplicaciones exitosas. El creciente nmero de dispositivos
capaces de navegar por la web, para lo cual se han creado diferentes
estrategias de adaptacin y transcodificacin, tambin ha afectado a la interfaz
de usuario.
Las aplicaciones de negocios se benefician de la articulacin flexible de la
Web. Esta capacidad desencaden la visin de aplicaciones como la

interaccin de servicios web que pueden estar disponibles para los clientes y
las empresas. Esta visin se apoya en una serie de tecnologas que
estandarizados de intercambio de informacin (SOAP), descripcin del servicio
(WSDL), descubrimiento de servicios (UDDI) y cmo los servicios pueden
coordinar o, ms bien, orquestado (BPEL, WSCI / WSCL).
Junto con el desarrollo tecnolgico y el aumento de la cantidad de informacin
disponible, surgi semnticamente la preocupacin por el aflojamiento de las
capacidades de hipertexto originales para relacionar informacin. La Web
Semntica (descrito en el captulo 14) es un esfuerzo continuo para abordar
esta cuestin.
Junto con otras tecnologas emergentes como la ayuda de la conciencia
contexto, las nuevas fundaciones se estn dispuestas para permitir la web para
convertirse en una fuente ms dinmica del conocimiento.