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 INTRODUCCIONEste 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 LIBROEn 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 BREVEPrimeros 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 EVOLUTIVA5.2.1 AntecedentesComo 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 ACTIVIDADEn 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 soportadoVersiones 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 ACTIVIDADEsta 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 PROGRAMABLELos 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 DISTRIBUIDAProgramas 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 SOFTWAREDesarrollo 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 INTEGRADOEl 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 PROPUESTORepetidamente 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 PRESENTACIONESEn 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 MALLASResultados 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 y se especificaron para dar formato a texto en negrita. El 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 elemento por el 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 DISPOSITIVORequisitos 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 INTERACCINEl 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 USUARIOMuchas 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 USUARIOPor 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 NAVEGACINEl 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, , 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 URLProcesos 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 ORIENTACINHerramientas 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 COMPLEJASEn 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 ARQUITECTURAHemos 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 en XML en Apache Struts (http://jakarta.apache.org/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 FUNCIONALEl 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 INTEGRACINPodemos 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 MIDDLEWAREMiddleware 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-CORPORATIVASEl 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 WS-Security 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 PERSPECTIVASLa 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 CONTEXTOUna 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 DISPOSITIVOLos 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 REUTILIZACINReutilizacin 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 MALLASEl 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 CONCEPTOSTipos 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 ALTERNATIVOSLas 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 RESUMENLa 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 inform