Clases 30 05
Upcoming SlideShare
Loading in...5
×
 

Clases 30 05

on

  • 1,129 views

 

Statistics

Views

Total Views
1,129
Views on SlideShare
1,129
Embed Views
0

Actions

Likes
0
Downloads
10
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Este tercer enfoque es rearquitectar los sistemas tal que una capa intermedia se crea entre las aplicaciones y las bases de datos. Este enfoque usa tecnología off-the-shell llamadas middleware y enterprise application integration o EAI. Las aplicaciones se modifican para que “llamen” al middleware el cual a su vez llama a los servidores (otras aplicaciones o bases de datos). Este enfoque permite cambiar las aplicaciones sin modificar las bases de datos. Tambien reduce el tiempo de mantenimiento. Este enfoque no exige mucho cambio organizacional. Pero requiere de una amplia experticia técnica. Markus, 2000
  • En este tipo de arquitectura, el cliente sólo tiene capacidades de ‘presentación’, pues toda la lógica del negocio tiene lugar en el lado del servidor.
  • Browser del cliente (Browser HTML estándar con soporte para forms) El browser es utilizado por el usuario de la aplicación para solicitar páginas Web (HTML o del servidor) y muestra las páginas html devueltas por el servidor Web. Sus Funciones/Servicios son 1.- Actuar como interfaz de usuario generalizada : toda interacción usuario/sistema se realiza a través del browser. La organización y apariencia de las páginas web es lo que conforma la interfaz de usuario de una aplicación Web . En estas aplicaciones, el browser actúa como un contenedor de interfaces de usuario generalizado, pues cada interfaz de usuario específica está definida por el contenido de una página Web (texto y controles de entrada). 2.- Aceptar y devolver ‘cookies’ Servidor Web (Punto de acceso principal al sistema para los browsers cliente) Sus Funciones/Servicios son: 1.- Aceptar peticiones de páginas Web, y según el tipo de petición... Iniciar procesamiento en el lado del servidor Delegar el procesamiento en un intérprete de scripts o un módulo ejecutable 2.- Devolver páginas HTML al browser Conexión HTTP (Protocolo de comunicación entre browsers cliente y servidores Web) Tipo de Comunicación SIN CONEXIÓN, puesto que cada vez que cliente y servidor intercambian información, se establece una conexión nueva y separada. La conexión sólo existe durante el procesamiento de una petición de página. Una vez que la petición ha sido satisfecha, la conexión finaliza. Toda actividad sobre el servidor (debida al usuario) ocurre durante la petición de página. Esto representa una muy importante diferencia con las aplicaciones cliente/servidor tradicionales . Secure Sockets Layer (SSL) es una variación de HTML que permite el intercambio de información encriptada.
  • Esta arquitectura mínima carece de algunos componentes opcionales que son encontrados normalmente en aplicaciones Web.
  • La persistencia se explica en la transparencia siguiente. -- Otra opción añadida a la arquitectura de cliente web ligero es la integración con sistemas heredados y, para aplicaciones de comercio electrónicos, con sistemas de contabilidad de mercado. Integración con Sistemas Heredados y Sistemas de Contabilidad de Mercado Se accede a estos componentes a través de los objetos del negocio, si existe, y si no, vía el Servidor de Aplicaciones. Sistemas heredados: Sistema de contabilidad o Sistemas de programación de producción Sistema de contabilidad de mercado permite que una aplicación Web para Internet, acepte y procese pagos con tarjetas de crédito para empresas más grandes, puede ser una interfaz con un sistema existente que procese solicitudes de dichos pagos
  • Explicar con pág. 103 ¡¡ corregido del libro, pues estoy convencida de que en la figura hay un par de flechas que no están en su sitio!!
  • Si los procesos ejecutados en el servidor tardan mucho, entonces este patrón puede no ser adecuado, sería necesario quizá descargar algo al servidor... Por otro lado, el browser es el único mecanismo de entrega de interfaces de usuario. Por tanto, las capacidades de dichas interfaces están limitadas a lo que soporte el browser y la versión de html utilizada.
  • Uno de los componentes más utilizados en Internet relacionado con la interfaz de usuario es el control y plug-in Shockwave ActiveX. Permite animaciones interactivas y se usa sobre todo para condimentar sitios de Internet con gráficos atractivos, así como para mostrar simulaciones y monitorizar eventos deportivos.
  • * Puesto que la comunicación entre cliente y servidor se realiza vía HTTP, la mayor parte del tiempo NO EXISTE conexión abierta entre ellos. Esto significa que los scripts del cliente, controles ActiveX y applets Java sólo pueden interactuar con objetos del cliente. * El patrón Cliente Web Pesado utiliza ciertas capacidades del browser : 1) Controles ActiveX o Applets de Java para i)ejecutar lógica del negocio en el cliente o ii)tratar aspectos de interfaz de usuario . Un control ActiveX es código binario ejecutable compilado que puede ser descargado al cliente vía HTTP e invocado por el browser. 2) Scripts del cliente. Las páginas HTML pueden contener scripts escritos en JavaScript o VBScript. Esta capacidad permite al browser interpretar código que puede ser i)parte de la lógica del negocio del sistema o ii)tratar aspectos de interfaz de usuario . Estos scripts son elementos que potencialmente son significativos para la arquitectura del sistema.
  • Una cuestión importante del diseño de aplicaciones Web es comprender este paradigma de interacción cliente-servidor. Los objetos de negocio no siempre están accesibles cuando se manejan peticiones de IU individuales. Por ejemplo, una característica común de interfaz de usuario (y del negocio) en muchas aplicaciones cliente/servidor es el rellenado automático de los campos de “ciudad” y “estado” en una dirección postal de USA, cuando se introduce un código zip. Asumiendo que esos tres campos están localizados en la misma página en un browser, esta característica requeriría una solicitud adicional de una página del servidor inmediatamente después de la introducción del valor en el campo “código zip”. Para la amplia mayoría de aplicaciones Web esto supondría una pérdida de rendimiento inaceptable, pues las peticiones de páginas suelen ser satisfechas en un tiempo del orden de segundos y no de milisegundos.
  • Cuando se utilizan scripts del cliente, applets o controles, el equipo de pruebas debe realizar un conjunto completo de escenarios de prueba para cada configuración de cliente que deba ser soportada. Puesto que se está ejecutando lógica del negocio crítica en el cliente, es importante que se comporte de forma correcta y consistente en todos los browsers involucrados Una desventaja del uso de applets es que cada browser implementa su propia versión de Java (máquina virtual Java). Y además, van muy por detrás de Sun (creador de Java). Todo esto implica que un applet puede no ejecutarse correctamente o igual en browsers diferentes.
  • El Web es utilizado sobre todo como un mecanismo de entrega para un sistema cliente/servidor de objetos distribuidos diferente del tradicional. Son aplicaciones cliente/servidor de objetos distribuidos que incluyen un servidor Web y un browser de cliente como elementos significativos para su arquitectura. Puede verse como una aplicación Web con objetos distribuidos o un sistema de objetos distribuidos con elementos Web.
  • El Web es utilizado sobre todo como un mecanismo de entrega para un sistema cliente/servidor de objetos distribuidos diferente del tradicional Aplicaciones cliente/servidor de objetos distribuidos que sólo incluyen un servidor Web y un browser de cliente como elementos significativos para su arquitectura. La mayor fortaleza de esta arquitectura es la capacidad de distribuir objetos de negocio existentes en el contexto de una aplicación Web. Con la comunicación directa y persistente entre cliente y servidor, se evitan las limitaciones de las anteriores arquitecturas. El cliente puede realizar lógica del negocio importante hasta un grado mucho mayor. No suele utilizarse en aislado, sino en combinación con alguno de los otros. Lo más típico es usar uno o ambos de los patrones anteriores para aquellas partes del sistema que no requieren una IU sofisticada o donde las configuraciones del cliente no son lo bastante fuertes como para soportar una aplicación cliente grande.
  • La mayor diferencia con los otros patrones: el protocolo de comunicación entre cliente y servidor. Si antes era HTTP, ahora se utiliza protocolos DCOM o RMI/IIOP.
  • Lo principal es el uso de un browser que contiene la interfaz de usuario y algunos objetos del negocio que se comunican independientemente del browser, con objetos del servidor (vía IIOP, RMI o DCOM) Ventaja principal: El browser tiene capacidades nativas para descargar automáticamente los componentes necesarios desde el servidor . Un nuevo equipo sólo necesita de un browser Web compatible para comenzar a utilizar la aplicación. No se necesita la instalación de software manual en el cliente, porque el browser se encarga de ello por el usuario. Los componentes son distribuidos e instalados en el cliente según se necesitan. Tanto applets Java como controles ActiveX pueden ser enviados automáticamente y metidos en la caché del cliente. Cuando esos componentes son activados, como resultado de la carga de la página Web apropiada, pueden interconectarse en una comunicación asíncrona con objetos del servidor.
  • Ejemplos: aplicaciones que requieren soportar diferentes sistemas de software. Componentes: Microkernel, Internal Server, External Server, Client, Adapter. Conectores: Interfaces de programación del Microkernel (para Internal Server, External Server, Adapter), Interfaces de programación del Servidor Externo (para Client)
  • Ejemplos: CLOS y Java. Componentes: A un meta nivel (provee información sobre las propiedades del sistema) y a un nivel base (contiene la lógica de la aplicación) Conectores: Protocolos que comunican los dos niveles.
  • Ejemplos: Java Virtual Machine, Java Class Libraries (AWT, Swing), Microsoft Foundation Classes (MFC). Componentes: aplicación componente, Wrapper Fa çade, funciones API. Conectores: Mecanismos de comunicación de las clases.
  • Ejemplos: Java Virtual Machine, Java Class Libraries (AWT, Swing), Microsoft Foundation Classes (MFC). Componentes: aplicación componente, Wrapper Fa çade, funciones API. Conectores: Mecanismos y protocolos de comunicación entre los componentes.
  • Ejemplos: Component-Based Application Servers, implementaciones de CORBA (COM), Web browsers, reflective ORB. Componentes: Context, concrete framework dispatcher, application, interceptor, concrete interceptor . Conectores: Mecanismos y protocolos de comunicación entre los componentes.
  • Ejemplos: Implementaciones de CORBA, COM/COM+, CCM, Enterprise Java Beans. Componentes: Root interface, extension interface, component, component factory, client. Conectores: Mecanismos y protocolos de comunicación entre los componentes.
  • Ejemplos: Implementaciones de CORBA, ODBC, SQL-Net. Componentes: Repositorio de datos centrales y agentes. Conectores: Mecanismos y protocolos de comunicación entre los componentes.

Clases 30 05 Clases 30 05 Presentation Transcript

    • Sistemas de flujo de datos (Dataflow)
    • - Batch secuencial
    • - Pipes-filters
    • Sistemas llamada-respuesta
    • - Programa principal (Main) y subrutinas, funciones, procedimientos
    • - Sistemas OO
    • - Capas jerárquicas
    • Componentes independientes
    • - Procesos que se comunican
    • - Sistemas de eventos
    • Máquinas virtuales
    • - Interpretadores
    • - Sistemas de reglas, basados en conocimiento
    • Sistemas centrados en datos (repositorios)
    • - Bases de Datos
    • - Sistemas hipertexto
    • - Pizarras (blackboard)
    ARQUITECTURAS DE SOFTWARE
  • Estilos que definen la Arquitectura
    • Sistemas Distribuidos (procesamiento)
    • Cliente/Servidor (física)
    • Repositorio (Datos)
    • O-O
    • Wireless (Comunicación)
  • Estilo - Cliente/Servidor
    • 2 capas
    • 3 capas
    • n capas
    • Tecnología en el servidor
    • Tecnología en el cliente
    • El par de entidades que ofrecen y requieren servicios constituye el
    • modelo cliente/servidor
    Client Server Interface Estilo - Cliente/Servidor
    • El análisis funcional de una aplicación pone en evidencia tres partes:
      • La interfaz usuario (presentación) . En general es gráfica ( GUI ). Debe funcionar sobre varias plataformas
      • La lógica de la aplicación. Representa las reglas del negocio. Contempla el servidor de transacciones y/o el servidor del negocio (business services)
      • El acceso a los datos . Contiene los procedimientos de acceso a los datos, la estructura de la(s) BD(s). Es el servidor de datos
    Modelo - Cliente/Servidor
  • Cliente/Servidor Dos Capas Maquina Cliente (UNIX, Windows, Linux,...) Servidor de Base de Datos
  • Estilo - Cliente/Servidor
    • Modelo de Dos Capas:
    • Este modelo se basa en que la conexión entre la aplicación Java o el applet que se ejecuta en el navegador, se conectan directamente a la base de datos. Esto significa que el driver JDBC específico para conectarse con la base de datos, debe residir en el sistema local. La base de datos puede estar en cualquier otra máquina y se accede a ella mediante la red. Esta es la configuración típica Cliente/Servidor: el programa cliente envía instrucciones SQL a la base de datos, ésta las procesa y envía los resultados de vuelta a la aplicación
    • La aplicación del modelo cliente/servidor comporta estas tres componentes ( presentación, lógica, datos ) y conlleva a un modelo denominado en tres capas ( estilo layers ), en donde cada capa sólo comunica con sus vecinos inmediatos
    Modelo - Cliente/Servidor 3 Capas
  • Interface GUI Servidor de datos Servidor de transacciones Interface Capa datos Capa lógica Capa presentación Modelo - Cliente/Servidor 3 Capas
    • Entre la GUI y el servidor de transacciones existe una relación cliente/servidor
      • La GUI juega el rol de cliente y el servidor de transacciones juega el rol de servidor
      • La capa de transacciones debe poseer una interfaz perfectamente definida que describe los servicios ofrecidos, para jugar el rol de servidor
    Modelo - Cliente/Servidor 3 Capas
    • Entre el servidor de transacciones y el servidor de datos existe una relación cliente/servidor
      • El servidor de transacciones juega el rol de cliente y el servidor de datos juega el rol de servidor
      • La componente servidor de datos debe poseer una interfaz perfectamente definida que descibe los servicios de acceso a los datos ofrecidos, para jugar el rol de servidor
    Modelo - Cliente/Servidor 3 Capas
  • Cliente/Servidor Tres capas Maquina Cliente (UNIX, Windows, ...) Maquina Servidor Servidor de Base de Datos
  • Estilo - Cliente/Servidor
    • Modelo de Tres Capas:
    • En este modelo de acceso a las bases de datos, las instrucciones son enviadas a una capa intermedia entre Cliente y Servidor, que es la que se encarga de enviar las sentencias SQL a la base de datos y recoger el resultado desde la base de datos. En este caso el usuario no tiene contacto directo, ni a través de la red, con la máquina donde reside la base de datos.
  • Arquitectura Web n-capas BDD Server Applications TCP/IP, HTTP, HTTPS, Socket, Objetos Distribuidos, CORBA, ORBA Capa de Funcionalidades de la Aplicación (2) Repositorio (3) ODBC, JDBC CONECTORES: Proxy n-Capas (4+) Server Applications Server Applications BDD cliente 1 cliente 2 cliente n Capa de Presentación (1) SQL Net
  • Enfoque Re-Arquitectura
    • Una capa intermedia se crea entre las aplicaciones y las bases de datos.
    • Usa tecnología off-the-shell llamadas middleware y Enterprise Application Integration -EAI-.
    • Permite cambiar las aplicaciones sin modificar las bases de datos.
    • Reduce el tiempo de mantenimiento.
    • No exige mucho cambio organizacional.
    • Requiere de una amplia experticia técnica. Markus, 2000
    Programas de análisis Aplicaciones y programas modificados Reportes y Análisis M i d d l e w a r e Bases de datos
  • EJEMPLO BSC
    • Aplicación para Bsc : Entorno PDVSA
      • Heterogeneos, Clientes Thin, Web Delivery, JDBC – SQLnet 2.1, Cliente/Servidor 3 tier.
      • Http, Https, Tcp/Ip, Objetos Serializados, Server Socket,Broker – Server Aplication
    Patrones para Manejo de Eventos: Proactor , The asynchronous Completion Token Patrones de Sincronización : Scope Locking C++, Strategized locking Patrones de Concurrencia : Active Object, Half Async BDD Server Applications cliente 1 cliente 2 cliente n Capa de Presentación (1) Capa de Funcionalidades de la Aplicación (2) Multi-DB SQL Net Proxy Server Applications Server Applications BDD
  • Calidad de Software
    • Son los requerimientos que debe cumplir un sistema de software desde el punto de vista estructural o arquitectónico.
    • Las características de calidad de un software, se presentan de acuerdo a tres puntos de vistas: el sistema, el negocio, la estructura arquitectónica.
  • Calidad de Software Modelo de Calidad ISO/IEC 9126-1 , 25010, 25030.
    • El modelo de calidad ISO 9126-1 es ahora un estándar en la industria del software y es definido en un alto nivel de abstracción, en términos de las visiones de calidad externa, interna y calidad en uso de las características de calidad.
  • Calidad de Software (Modelo de Calidad ISO-9126-1)
    • Los modelos de calidad basados en productos se utilizan para medir el alcance de los atributos externos de un producto de software y relacionarlos con la calidad global del producto.
    • La importancia de un diseño preciso de la arquitectura del software, ha crecido enormemente para la construcción de un sistema confiable.
    • Proporciona un framework para realizar mediciones de las características específicas deseables , requeridas en el sistema final y percibidas por los diferentes participantes durante el proyecto de software
    • Premisa: las características internas del producto en desarrollo afectan la calidad en uso y la calidad externa del producto final
    Calidad de Software
  • CALIDAD DEL PROCESO CALIDAD INTERNA CALIDAD EXTERNA CALIDAD EN USO INFLUENCIA INFLUENCIA INFLUENCIA DEPENDE DEPENDE DEPENDE MEDIDAS DE PROCESO MEDIDAS INTERNAS MEDIDAS EXTERNAS MEDIDAS DE CALIDAD EN USO PROCESO PRODUCTO DE SOFTWARE EFECTOS DEL PRODUCTO DE SOFTWARE CONTEXTOS DE USO ENFOQUES DE CALIDAD ISO 9126 (1998) )
    • Calidad interna : reflejo de la estrategia y filosofía del diseño, se evalúa con métricas internas
    • Calidad externa : calidad del producto entregado, se evalúa con métricas externas
    • Calidad en uso : vista de la calidad del usuario final como resultado de utilizar el software, se evalúa con métricas externas
    Calidad de Software
  • Calidad de Software Atributos observables en Tiempo de Ejecución (Runtime)
    • Atributos o características que responden a preguntas sobre el sistema, tales como:
      • ¿Provee resultados en tiempo razonable?
      • ¿Produce resultados deseados?
      • ¿Cómo se comporta en tiempo de ejecución?
      • ¿Cómo responde a la conexión con otros sistemas?
  • Calidad de Software Atributos observables en Tiempo de Ejecución (Runtime)
    • 1. Desempeño (performance) :
      • Tiempo requerido para responder a un evento o conjunto de eventos procesados en un intervalo de tiempo.
        • Rendimiento del tiempo de respuesta.
        • Velocidad de generación de páginas.
        • Velocidad de generación de gráficos.
    • 2. Seguridad (security):
      • Habilidad de un sistema para evitar un servicio a los usuarios no autorizados y proporcionarlo a los autorizados.
        • Validación de la entrada del usuario.
  • Calidad de Software Atributos observables en Tiempo de Ejecución (Runtime)
    • 3. Disponibilidad (availability) :
      • Porción del tiempo que el sistema está operativo. Se asocia con Integridad (habilidad para mantenerse operativo en el tiempo) y con Tolerancia a fallas (habilidad para mantenerse operativo y recuperarse de posibles fallas).
        • Recuperación de errores.
  • Calidad de Software Atributos observables en Tiempo de Ejecución (Runtime)
    • 4. Funcionalidad (functionality) :
      • Habilidad del sistema para realizar el trabajo para el cual fue concebido.
        • Capacidad de recuperación y búsqueda.
        • Servicio de búsqueda en navegación.
        • Servicio relacionados con el dominio de la aplicación.
        • Proceso correcto de enlace
    • 5. Usabilidad (usability):
      • Como el usuario percibe y comunica con el sistema y comprende factores tales como: aprendizaje, desempeño, memorización, robustez, satisfacción.
        • Capacidad de comprensión del sitio global.
        • Capacidad estética y de interfaz.
        • Servicio de ayuda y realimentación en línea.
  • Calidad de Software Atributos No observables en Tiempo de Ejecución (N-Runtime)
    • Características o atributos que responden a preguntas sobre el sistema, tales como:
      • ¿Qué tan fácil se puede integrar, probar o modificar?
      • ¿Qué tan costoso es el desarrollo?
      • ¿Cuál es el tiempo de mercadearlo, una vez concluido?
  • Calidad de Software Atributos No observables en Tiempo de Ejecución (Runtime)
    • 1. Modificabilidad (modifiability) :
      • Habilidad para realizar cambios rápidamente y a un costo razonable.
      • Incluye los aspectos: extensión, eliminación, adaptación (portabilidad), reestructuración.
        • Facilidad de corrección.
        • Adaptabilidad.
        • Extensibilidad.
  • Calidad de Software Atributos No observables en Tiempo de Ejecución (Runtime)
    • 2. Portabilidad (portability) :
      • Habilidad del sistema para ejecutarse bajo diferentes ambientes computacionales.
      • Clave: Encapsulación
      • Esconde la capa de portabilidad o el conjunto de servicios que permiten la portabilidad.
  • Calidad de Software Atributos No observables en Tiempo de Ejecución (Runtime)
    • 3. Reusabilidad (reusability) :
      • Habilidad de poseer una estructura que pueda ser utilizada por otros sistemas.
    • 4. Integrabilidad (integrability) :
      • Habilidad para hacer que componentes del sistema desarrolladas separadamente trabajen juntas correctamente.
  • Calidad de Software Atributos No observables en Tiempo de Ejecución (Runtime)
    • 5. Interoperabilidad (interoperability) :
      • Habilidad de que el sistema, visto como un conjunto de componentes, pueda trabajar con otros sistemas.
    • 6. Facilidad de prueba (testing facility) :
      • Facilidad de cómo el sistema puede ser probado y demostrar sus fallas a través de pruebas.
  • Modelo de Calidad del software Eficiencia Confiabilidad Usabilidad Mantenibilidad Portabilidad Funcionalidad - Convenienza - Correctitud - Interoperativ. - Seguridad - Conformidad - Madurez - Tol. Fallas - Recuperab. -Conformidad - Entendibilidad - Aprendibilidad - Operatividad - Atracción - Conformidad - Comporta- miento en tiempo - Uso de recursos - Conformidad Modelo de calidad según ISO 9126 (Calidad externa e interna) - Analizabilidad - Flexibilidad a cambios - Estabilidad - Prueba - Conformidad - Adaptabilidad - Inestabilidad - Co-existencia - Reemplaza- bilidad - Conformidad
    • Un solo modelo de calidad para todo el proceso de desarrollo
    • Las características internas se deben relacionar con la etapa específica del proceso de desarrollo
    • No ofrece método o “guidelines” para el proceso de construccón del modelo de calidad
    Limitaciones del modelo de calidad de ISO 9126-1
    • Reglas del negocio políticas
    • Uso de protocolos de comunicación de redes, Ancho de banda.
    • Los requisitos pueden ser vistos en líneas generales como objetivos principales, de hecho sensibles al cambiante ambiente. El contexto puede cambiar en una vía tal que la puesta en operación del objetivo no sea por tiempo valido o aceptable. En este sentido los requisitos pueden estar intermitentes entre los objetivos y la realidad actual. Por ejemplo, un objetivo para un servicio puede ser proveído para un usuario altamente interactivo. Si el contexto es favorable (Alto ancho de banda, Pantalla a color, Maquina virtual java disponible, entre otros.), El objetivo es trasladado a un servicio “Usa un applet de Java para representar una cesta de compra” (Finkestein y Savigni et .al, 2004).
    Requisitos No Funcionales APLICACIONES MOVILES
    • Reglas de procesamiento : las reglas de procesamiento más importantes de los ambientes móviles en estudio son (Wohltorf . et. al, 2004) :
    • Los servicios se ejecuta en un ancho espectro de dispositivos, cada uno con configuraciones y funcionalidades diferentes.
    • Los servicios deben siempre ser garantizados dentro del espectro de cobertura.
    • El usuario debe seleccionar el uso de los servicios ofrecidos.
    • Se debe garantizar un ambiente en el cual los usuarios y dispositivos se conectan y desconectan dinámicamente a la red.
    • Los servicios ejecutados en el espectro de cobertura son restringidos por el tipo de dispositivo y la tecnología de la plataforma de comunicación del proveedor de servicios. En particular se tiene:
      • La mayoría de los dispositivos son pequeños, no sólo en el tamaño sino también en el poder computacional, tamaño de memoria, carga limitada de batería, entre otros.
      • Aunque la mayoría de los dispositivos tiene alguna forma de conexión., incluso con los nuevos estándares de redes como GPRS, Bluetooth , 802.11x, entre otros. El ancho de banda todavía esta relativamente limitado comparado con las tecnologías de red existentes. Además, las conexiones son normalmente inestables
    Requisitos No Funcionales APLICACIONES MOVILES
  • RequisitosArquitecturales Tabla 3. Requisitos no funcionales , propiedad de calidad y solución arquitectural. -Medida de complejidad -Boolean -Boolean Middleware incluyendo MEDIATOR Maintainability (changeability) Propiedad cuantitativa -Atributo: Tamaño Reliability (consistency) propiedad cualitativa - Atributo: presencia de un mecanismo Portability (adaptability) propiedad cualitativa - Atributo: presencia de un mecanismo Reconfiguracion Dinámica de Interfaces Boolean Middleware incluyendo MEDIATOR Reliability (availability ) Propiedad cualitativa -Atributo: presencia de un mecanismo, en este caso el middleware soportado por el patrón agente MEDIATOR Solución centralizada, donde la interfaz del dispositivo es distribuida por el middleware de la aplicación a través de la red. -Medida de complejidad , es decir numero de componentes dinámicos en un periodo de tiempo -Medida de complejidad Reflection [28] Mecanismo para observar el estado de un componente para permitir cambios dinámicos en la estructura y desempeño -Maintainability ( changeability) Extensibilidad del ambiente de ejecución; propiedad cuantitativa -Atributo: Tamaño -Portability (replaceability) Propiedad cuantitativa -Atributo: Tamaño Comunicación flexible debe ser flexible a los requisitos de cambios y relaciones entre componentes que pueden ser estáticos y dinámicos. Porcentaje [0..1] Protocolo de comunicación de redes, Ancho de banda. Medida durante la ejecución Efficiency (performance ) con respecto al tiempo de respuesta y conexiones; propiedad cuantitativa -Atributo: latency Tiempo de transmisión limitado. Tiempos de respuesta adecuados a un rango Boolean Middleware incluyendo MEDIATOR Reliability (consistency) Provee un mecanismo, es decir el manejo de la replica actualizando en cada dispositivo; propiedad cualitativa -Atributo: presencia de mecanismo Los Datos deben ser transmitidos completa, correctamente y consistentes con conexiones transientes. Porcentaje [0..1] Protocolo de comunicación de redes, Ancho de banda. Medida durante la ejecución Efficiency (performance) Con respecto a la utilización de recursos ; propiedad cuantitativa -Atributo: consumo de recurso para cada dispositivo Minimización en el consumo de recursos (baterías, almacenamiento de datos, tamaño del display , entre otros). MÉTRICA SOLUCIÓN ARQUITECTURAL PROPIEDAD DE CALIDAD REQUISITOS NO FUNCIONALES
  • Tabla 4. Propiedades de calidad para cada funcionalidad y su solución arquitectural. Tabla 4. Propiedades de calidad para cada funcionalidad y su solución arquitectural. - Reliability (availability, consistency) Atributo: presencia de un mecanismo. Métrica : Boolean Repository [44] Compartimiento de Datos - Maintainability (changeability) Atributo: Tamaño Métrica: Medida de complejidad - Reliability (fault-tolerance) Atributo: presencia de un mecanismo. Métrica : Boolean -Usability (attractiveness, operability) Atributo: presencia de un mecanismo. Metrica: Boolean WrapperFaçade [28] Encapsula funciones y datos de no orientados a objetos en APIs concisas, portables, mantenibles y robustas interfaces de clases ComponentConfigurator [28] Permite al componente reconfigurarse en tiempo de ejecución vaciando, modificando, recompilando o encadenando estáticamente la aplicación. Interceptor [28] Permite transparentemente adicionar servicios cuando ciertos eventos ocurran. Variantes : Chain-of-responsibility, Publisher/subscriber y Subject/observer. Extension Interface [28] Permite exportar múltiples interfaces por un componente. El componente funcionalmente es extendido y modificado. Servicios Centrados al Usuario - Realiability (availability, consistency) Atributo: presencia de un mecanismo Métrica: Boolean - Efficiency (performance) con respecto al limitado espacio y al limitado tiempo de respuesta Atributo: consumo de recursos de cada dispositivo Métrica: Porcentaje [0..1] - Maintainability (changeability) Propiedad cuantitativa Atributo : Tamaño LocalProxy [17] Una instancia local provee una interfac e a un servicio local o remoto. Ejemplo : Ejecutando localmente un web proxy PushObject [17] Un dispositivo envía un objeto específico con un requisito fuera. Ejemplos : SMS, OBEX RequestObject [17] Un dispositivo requiere un objeto especifico (Una pagina web ) desde otro dispositivo. Ejemplo : WAP CannedCode [17] Un dispositivo envía código, el cual es ejecutado sobre otro dispositivo. El código no debe ser ejecutado sobre el dispositivo que envió. Ejemplo : WMLscript, web filters Manejo de Datos PROPIEDADES DE CALIDAD (INTERNA/EXTERNA) SOLUCION ARQUITECTURAL REQUISITOS FUNCIONALES
  • Requisitos No Funcionales APLICACIONES MOVILES Confiabilidad (confiability) -Disponibilidad (availability) 1. Garantizar la disponibilidad del servicio al conectarse.
    • Los dispositivos se conecten y desconectan dinámicamente a la red.
    Funcionalidad (Functionality) -Adecuada(Suitability) Usabilidad (usability) -Operabilidad (operability) 1. Ofrecer funcionalidades que respondan a las necesidades de los usuarios. 2. Facilidad en la selección de los servicios ofrecidos.
    • El usuario selecciona los servicios disponibles en el área de cobertura.
    Confiabilidad (confiability) -Disponibilidad (Availability) Eficiencia (eficiency) -Comportamiento del tiempo (Time Behaviour) con respecto al tiempo de respuesta y a las conexiones. 1. Hacer posible los servicios, lo cual implica, ancho de banda apropiado y garantizar las conexiones móviles, teniéndose que solventar problemas de redes. 2. Tiempo de transmisión apropiado. Tiempos de respuesta adecuados dentro de un rango establecido .
    • Los servicios deben ser garantizados dentro del área de cobertura.
    Portabilidad (Portability) -Adaptabilidad (adaptability) 1. Las funcionalidades deben adaptarse a las características de los Dispositivos.
    • Los servicios se ejecutan en una diversidad de dispositivos, cada uno con configuraciones y funcionalidades diferentes.
    Procesamiento Funcionalidad (Functionality) - Conformidad (Compliance) 1. Cumplir con estándares, normativas con el fin de garantizar el servicio requerido.
    • Uso de protocolos de comunicación de redes, ancho de banda.
    Políticas Propiedades de Calidad asociadas a los requisitos no funcionales (Características de Calidad) ISO/IEC 9126-1 [15] Requisitos no funcionales derivados de las reglas del negocio. Reglas del negocio asociadas al Dominio
  • Requisitos Funcionales APLICACIONES MOVILES Confiabilidad (Confiability) -Disponibilidad (Availability) Funcionalidad (Functionality) -Interoperabilidad (Interoperability) Compartir Datos: Los dispositivos móviles formarán una red ad-hoc que se conecta entre ellos para intercambiar la información y para proporcionar los servicios a los usuarios. Usabilidad (Usability) -Atractivo (Atractiveness) - Operabilidad (Operability) Servicios de administración: (defecto, configuración, Bitácora, ejecución y seguridad) Portabilidad (Portability) -Conformidad (compliance) -Escalabilidad (Scalability) Funcionalidad (Functionability) -Seguridad (Security) Servicios de comunicación: comunicación entre usuarios, transporte de información y establecimiento de conexiones. Usabilidad (Usability) -Atractivo (atractiveness) -Operabilidad (Operability) Portabilidad (Portability) -Adaptabilidad (adaptability) -Escalabilidad (Scalability) Servicios de información: gestiona información al usuario. Confiabilidad (confiability) -Disponibilidad (availability) Con respecto a lo limitado del recurso de espacio) Eficiencia (Efficiency) -Comportamiento del tiempo (Behaviour time) (con respecto al tiempo de respuesta limitado). Funcionalidad (Functionality) - Precisión (accurancy) En el estándar QoS ISO [17], la integridad esta relacionada con acurrancy. Manejar Datos: Los datos deben ser transmitidos completa y correctamente. Propiedades de calidad asociadas (Características de calidad ) ISO/IEC 9126-1 [15] Requisitos Funcionales
  • Topología de aplicaciones WEB. Caso De Estudio Desde un web browser, un usuario indica un URL. Este es un request a un server remoto sobre el p rotocolo HTTP. Internet es… … un mecanismo Request/Response . Workstation Server Web Pages HTTP protocol www.url.com HTML Request Response El server remoto procesa el request y envia un HTML response que es recibido por el browser y presentado al usuario como una pagina WEB.
  • Arquitectura para Web Cliente y Usuario Final Proveedores de Contexto Proveedores de Servicios While World Desarrollo Organizacional Proveedores de Software Ambiente Técnico Heterogéneo Computación Distribuida WWW Experiencia en Arquitecturas Internet y Hipertexto WWW Requerimientos (Calidad) Acceso Remoto Interoperatibilidad Extensibilidad (de software y datos) Escalabilidad Upward Compatibility Architect(s) WWW Consortium Arquitectura libWWW Jigsaw Cliente/Servidor Sistema WWW Influencias de la Arquitectura
  • Topología - 1era. Generación Zona Abierta Cliente Conversor de datos Internet IP No seguro
    • Servidor de información
    • Servidor Web
    • Lógica de Aplicación
    • Conexiones a Datos
    Páginas Estáticas
  • Topología - 1ra. Generación
    • Modelo Basado en Contenidos
      • Textual.
      • Multimedia.
    • Información Estática.
    • Objetivo:
      • Disponer rápidamente del sitio.
      • Reducir costos de implementación.
      • Información de acceso público.
    • Utilización de herramientas para ayudar a construir la interfaz de las páginas.
    • Indices de información.
    • Herramientas de búsqueda .
  • Topología - 2da. Generación
    • Sitios Web Activos.
      • Caracterizados por ofrecer páginas fabricadas dinámicamente o con fuerte componente dinámico.
    • Primeras aplicaciones comerciales:
      • Telecompra (con tarjeta de crédito).
      • Telecatálogo.
      • Telebanco.
    • Tecnología basada en HTML :
      • Soporte de conexiones (cookies).
      • Control de acceso.
      • Programas del lado del cliente.
      • Programas del lado del servidor.
  • Topología - 2da. Generación Zona Abierta Cliente Internet IP No seguro
    • Servidor de información
    • Servidor Web
    • Lógica de Aplicación
    • Conexiones a Datos
    • Conexión con Backend.
    Páginas Estáticas Mundo Exterior Red Interna Cookie Aplicación Aplicación Aplicación Aplicación Servidor de BD
  • Topología - 3era. Generación
    • Manejar adecuadamente la información.
    • Ofrecer métodos y herramientas para desarrollar fácilmente aplicaciones adecuadas a los negocios.
    • Integrar aplicaciones de diversos fabricantes.
      • Uso de Middleware: Capa de software que reduce el esfuerzo de programación para enlazar aplicaciones diferentes.
    • Ofrecer la posibilidad de actualizar facilmente las plataformas (Uso de tecnología O-O).
    • Integrar Web e Internet:
      • La clave es la interfaz que sirve para intercambiar información entre compañías.
      • Comunicaciones independientes de la plataforma.
  • Topología - 3era. Generación
    • Negocios.
      • Middleware para integradores.
    • Ventas.
      • Inventario.
      • B2B.
    • Interfaces de Usuario.
      • Movilidad.
      • Personalización.
      • HIC
  • Topología - 3era. Generación
    • Objetivo
      • Poder vender a clientes a través de la Internet.
      • Implementar un sistema de gestión de órdenes de compra por la red.
    • Funciones
      • Inventario
      • Gestión de órdenes de compra
      • Información de precios
      • Distribución
      • Cálculo de impuestos
      • Procesamiento de créditos
    • Herramientas
      • Middleware para acceder a la BD.
      • Aplicaciones de personalización a clientes y Gestión de relaciones entre consumidores (CRM)
  • Topología - 3era. Generación
    • Movilidad:
      • Filtros de datos para dispositivos inalámbricos.
      • Soporte de voz.
    • Personalización:
      • Traductores automáticos (internacionalización).
      • Gestión y explotación de portales.
      • Aplicaciones 3D.
    • Evolución de las UI.
      • Orientadas a línea: Directamente peticiones SQL.
      • Formularios.
      • Informes escritos.
      • Interfaces gráficas.
      • Interfaces 3D.
  • Topología - 3era. Generación Zona Abierta Mundo Exterior Red Interna Cliente Internet IP seguro y No seguro Páginas Estáticas Cookie Directorio Seguridad Sistemas de Gestión Cortafuegos Ligero Nodo de Integración Aplicación Aplicación Aplicación Nodo de Gestión y Creación de contenidos Cortafuegos del dominio Servidor de BD
    • Servidor de información
    • Servidor Web
    • Lógica de Aplicación
    • Conexiones a Datos
    • Conexión con Backend.
  • Estilos que definen la Arquitectura WEB
    • Sistemas Distribuidos (procesamiento)
    • Cliente/Servidor (física)
    • Repositorio
    • O-O
    • Wireless
  • Estilo – Sistemas Distribuidos
    • Client-Dispatcher-Server :
    requests service returns result Dispatcher locationMap registerService unregisterService locateServer establishChannel getChannel requests connection receiveRequest registers accepts link establishes connection Client doTask sendRequest Server acceptConnecting runService
  • Estilo – Sistemas Distribuidos
    • Broker para comunicación directa :
    Registry (Broker) Objetos distribuidos Client-side WWW browser (Client) Object server Other WWW servers WWW server RMI URL URL RMI RMI URL Server-side
  • Estilo - Cliente/Servidor
    • 2 capas
    • 3 capas
    • n capas
    • Tecnología en el servidor
    • Tecnología en el cliente
  • Arquitectura Web n-capas BDD Server Applications TCP/IP, HTTP, HTTPS, Socket, Objetos Distribuidos, CORBA, ORBA Capa de Funcionalidades de la Aplicación (2) Repositorio (3) ODBC, JDBC CONECTORES: Proxy n-Capas (4+) Server Applications Server Applications BDD cliente 1 cliente 2 cliente n Capa de Presentación (1) SQL Net
  • EJEMPLO BSC
    • Aplicación para Bsc : Entorno PDVSA
      • Heterogeneos, Clientes Thin, Web Delivery, JDBC – SQLnet 2.1, Cliente/Servidor 3 tier.
      • Http, Https, Tcp/Ip, Objetos Serializados, Server Socket,Broker – Server Aplication
    Patrones para Manejo de Eventos: Proactor , The asynchronous Completion Token Patrones de Sincronización : Scope Locking C++, Strategized locking Patrones de Concurrencia : Active Object, Half Async BDD Server Applications cliente 1 cliente 2 cliente n Capa de Presentación (1) Capa de Funcionalidades de la Aplicación (2) Multi-DB SQL Net Proxy Server Applications Server Applications BDD
  • Tecnología en el Servidor
      • CGI: Shell, Perl, C.
      • API´s Web Propietarias: ISAPI, NSAPI.
      • ASP.
      • PHP.
      • Java Script.
      • JSP
      • JSP (Servlets).
      • MIDLETS
    • Tecnología de Clientes:
      • Etiquetas:
        • SMG.
        • HTML.
        • Script.
        • Applets.
        • Thin/Fat.
        • XLETS
    Tecnología en el Cliente
  • Atributos presentes en la Arquitectura WEB
    • 1. Acceso Remoto
    • 2. Interoperatibidad
    • 3. Extensibilidad
    • 4. Escalabilidad
    • 5. Evolutiva
    • 6. Reflexiva
    • 7. Adaptable y Configurable
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
    • Aplicaciones comerciales basadas en la Web están siendo desarrollados muy rápidamente por necesidades comerciales, sin tener mucho cuidado de las prácticas de ingeniería. La calidad de estos productos no es discutida.
    • Los desarrolladores de software no tienen una descripción clara de las características de calidad de las aplicaciones Web.
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
    • Se utilizará una técnica basada en el estándar ISO 9126-1 para especificar las características de calidad relevantes de una aplicación Web, refinadas hasta el nivel de sub-característica, involucradas en el proceso de desarrollo arquitectónico de la aplicación.
  • Calidad de Software Atributos observables en Tiempo de Ejecución (Runtime)
    • Características que responden a preguntas sobre el sistema, tales como:
      • ¿Provee resultados en tiempo razonable?
      • ¿Produce resultados deseados?
      • ¿Cómo se comporta en tiempo de ejecución?
      • ¿Cómo responde a la conexión con otros sistemas?
  • Calidad de Software Atributos observables en Tiempo de Ejecución (Runtime)
    • 1. Desempeño (performance) :
      • Tiempo requerido para responder a un evento o conjunto de eventos procesados en un intervalo de tiempo.
        • Rendimiento del tiempo de respuesta.
        • Velocidad de generación de páginas.
        • Velocidad de generación de gráficos.
    • 2. Seguridad (security):
      • Habilidad de un sistema para evitar un servicio a los usuarios no autorizados y proporcionarlo a los autorizados.
        • Validación de la entrada del usuario.
  • Calidad de Software Atributos observables en Tiempo de Ejecución (Runtime)
    • 3. Disponibilidad (availability) :
      • Porción del tiempo que el sistema está operativo. Se asocia con Integridad (habilidad para mantenerse operativo en el tiempo) y con Tolerancia a fallas (habilidad para mantenerse operativo y recuperarse de posibles fallas).
        • Recuperación de errores
        • Errores en los enlaces
        • Errores de navegación
  • Calidad de Software Atributos observables en Tiempo de Ejecución (Runtime)
    • 4. Funcionalidad (functionality) :
      • Habilidad del sistema para realizar el trabajo para el cual fue concebido.
        • Capacidad de recuperación y búsqueda.
        • Servicio de búsqueda en navegación.
        • Servicio relacionados con el dominio de la aplicación.
        • Proceso correcto de enlace
  • Calidad de Software Atributos observables en Tiempo de Ejecución (Runtime)
    • 5. Usabilidad (usability):
      • Como el usuario percibe y comunica con el sistema y comprende factores tales como: aprendizaje, desempeño, memorización, robustez, satisfacción.
        • Capacidad de comprensión del sitio global.
        • Capacidad estética y de interfaz.
        • Servicio de ayuda y realimentación en línea.
  • Calidad de Software Atributos No observables en Tiempo de Ejecución (N-Runtime)
    • Características o atributos que responden a preguntas sobre el sistema, tales como:
      • ¿Qué tan fácil se puede integrar, probar o modificar?
      • ¿Qué tan costoso es el desarrollo?
      • ¿Cuál es el tiempo de mercadearlo, una vez concluido?
  • Calidad de Software Atributos No observables en Tiempo de Ejecución (Runtime)
    • 1. Modificabilidad (modifiability) :
      • Habilidad para realizar cambios rápidamente y a un costo razonable.
      • Incluye los aspectos: extensión, eliminación, adaptación, reestructuración.
        • Facilidad de corrección.
        • Adaptabilidad.
        • Extensibilidad.
  • Calidad de Software Atributos No observables en Tiempo de Ejecución (Runtime)
    • 2. Portabilidad (portability) :
      • Habilidad del sistema para ejecutarse bajo diferentes ambientes computacionales.
      • Clave: Encapsulación
      • Esconde la capa de portabilidad o el conjunto de servicios que permiten la portabilidad.
  • Calidad de Software Atributos No observables en Tiempo de Ejecución (Runtime)
    • 3. Reusabilidad (reusability) :
      • Habilidad de poseer una estructura que pueda ser utilizada por otros sistemas.
    • 4. Integrabilidad (integrability) :
      • Habilidad para hacer que componentes del sistema desarrolladas separadamente trabajen juntas correctamente.
  • Calidad de Software Atributos No observables en Tiempo de Ejecución (Runtime)
    • 5. Interoperabilidad (interoperability) :
      • Habilidad del sistema, visto como un conjunto de componentes, pueda trabajar con otros sistemas.
        • Transferencia de data entre la aplicación Web y otro software.
        • Siguiendo estándares de conectividad y manejo de protocolos.
    • 6. Facilidad de prueba (testing facility) :
      • Facilidad de cómo el sistema puede ser probado y demostrar sus fallas a través de pruebas.
        • Facilidad de prueba sin instalación en el sitio del usuario final.
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
    • Visión externa:
    • Funcionalidad: Capacidad de la aplicación Web de proporcionar las funciones que satisfagan las necesidades de la misma o para la cual fue creada.
    • Subcaracterísticas:
        • Conveniencia: Ya que la aplicación Web debe tener un conjunto apropiado de funciones para realizar las tareas que la misma debe cumplir: mecanismos de búsqueda de la aplicación, mecanismos de navegación y browsing, organización del contenido.
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
    • Funcionalidad (continuación subcaracterísticas):
        • Exactitud: Si la aplicación es de tipo transaccional, debe proporcionar resultados correctos.
        • Interoperabilidad: Es conveniente que la aplicación Web interactúe con otros sistemas específicos, por ejemplo, transferencia de data entre la aplicación Web y otro software, estándares de conectividad y manejo de protocolos.
        • Seguridad: En aplicaciones transaccionales y de comunicación, es necesario prevenir de accesos no autorizados
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
    • Visión externa:
    • Confiabilidad: Capacidad de la aplicación de mantener un nivel de funcionamiento especificado.
    • Subcaracterísticas:
        • Madurez: Referida a la frecuencia de fallas: presencia de errores en los enlaces, errores de navegación.
        • Recuperabilidad: Atributos de la aplicación Web, necesarios para recuperación en caso de fallas o de errores.
        • Tolerancia a fallas: Atributos de la aplicación Web necesarios para mantener un nivel de eficiencia en caso de falla.
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
    • Visión externa:
    • Usabilidad: Capacidad de la aplicación Web de ser aprendida, entendida, utilizada y ser atractiva a sus usuarios.
    • Subcaracterísticas:
        • Entendibilidad: Ya que es necesario que el usuario en poco tiempo reconozca la lógica de la aplicación y para qué sirve, entendimiento global de la aplicación Web, posesión de realimentación y ayuda en línea, etc.
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
    • Usabilidad (continuación subcaracterísticas):
        • Aprendizaje: Esfuerzo necesario para aprender a usar la aplicación Web, sobre todo en el caso de aplicaciones que se van a usar frecuentemente, como transaccionales, de entretenimiento, aplicaciones interactivas, etc.
        • Atractividad: Las aplicaciones Web deben ser atractivas a sus usuarios.
        • Operatividad: Esfuerzo necesario, para controlar y operar la aplicación Web, facilidades de navegación, facilidades para localizar la información, etc.
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
    • Visión externa:
    • Eficiencia: Capacidad del la aplicación Web de proporcionar ejecución apropiada, en base a unos recursos y unas condiciones específicas.
    • Subcaracterísticas:
        • Comportamiento en el tiempo: Rendimiento del tiempo de respuesta, velocidad de generación de gráficos, velocidad de generación de páginas, etc.
        • Utilización de recursos: Cantidad de recursos utilizados y duración de su uso para ejecutar una función: imágenes , video, sonido.
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1) MODELO DE CALIDAD PARA APLICACIONES WEB: VISION EXTERNA CARACTERISTICAS DE CALIDAD SUB-CARACTERISTICAS FUNCIONALIDAD CONVENIENCIA EXACTITUD INTEROPERABILIDAD SEGURIDAD CONFIABILIDAD MADUREZ ATRACTIVIDAD OPERATIVIDAD USABILIDAD ENTENDIBILIDAD APRENDIZAJE EFICIENCIA COMPORTAMIENTO EN EL TIEMPO UTILIZACION DE RECURSOS
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
    • Visión interna:
    • Mantenibilidad: Conjunto de atributos relacionados con el esfuerzo necesario para realizar modificaciones en una aplicación Web..
    • Subcaracterísticas:
        • Analizabilidad: Atributos relacionados con el esfuerzo necesario para diagnosticar deficiencias o causas de fallas: documentación disponible, trazabilidad de la aplicación, estructura de la aplicación, etc.
        • Cambiabilidad: Atributos de la aplicación relacionados con el esfuerzo necesario para hacer modificaciones o corregir errores en la misma: uso de estándares de programación, uso de modularidad,, desarrollo basado en componentes, etc.
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
    • Mantenibilidad (continuación subcaracterísticas):
    • Facilidad de prueba: Facilidad de prueba de la aplicación.
    • Estabilidad: Atributos de la aplicación Web, relacionados con el riesgo de tener efectos inesperados producto de modificaciones. En una aplicación Web, se pueden incorporar y desincorporar componentes sin afectar el desempeño de la aplicación.
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
    • Visión interna:
    • Portabilidad: Atributos de la aplicación Web que permiten su transferencia de una plataforma a otra.
    • Subcaracterísticas:
        • Adaptabilidad: Las aplicaciones Web deben tener alta escalabilidad, permitiendo a las mismas correr en diferentes plataformas.
        • Instalabilidad: Esfuerzo necesario para instalar la aplicación en un ambiente específico. Sólo es necesaria la instalación en el servidor.
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1) MODELO DE CALIDAD PARA APLICACIONES WEB: VISION INTERNA CARACTERISTICAS DE CALIDAD SUB-CARACTERISTICAS MANTENIBILIDAD ANALIZABILIDAD CAMBIABILIDAD PORTABILIDAD ADAPTABILIDAD INSTALABILIDAD
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
    • Para personalizar el modelo de calidad ISO 9126-1, debemos estar conscientes de las propiedades esperadas de la arquitectura en la cual el sistema de software debe ser construido.
    • Para el producto final hay valores de las metas de calidad que deben ser alcanzados o superados, entonces se dice que la arquitectura satisface las características de calidad requeridas.
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
    • Actividades a realizar para evaluar las arquitecturas propuestas:
    • Análisis de los requerimientos funcionales y no funcionales del sistema para establecer las metas de calidad.
    • Dar prioridad a las subcaracterísticas de calidad tomando en cuenta los requerimientos de calidad del sistema.
    • Presentación de los estilos arquitectónicos a utilizarse para definir la arquitectura.
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
    • Actividades a realizar para evaluar las arquitecturas propuestas (continuación):
    • 4. Uso del modelo de calidad ISO 9126-1 para evaluar los estilos.
    • 5. Construcción de la tabla de comparación.
    • 6. Analizar los resultados obtenidos.
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
  • Calidad de Software en WEB (Modelo de Calidad ISO-9126-1)
  • Conclusiones
    • La clasificación y comparación de estilos arquitectónicos son problemas complejos.
    • La especificación de los atributos de calidad usando un modelo de calidad basado en estándares internacionales ofrece una amplia y global visión de las características y atributos de calidad para arquitectura de software desde el punto de vista del arquitecto y del usuario.
    • La evaluación de estilos arquitectónicos respecto a atributos de calidad se basa en la definición de modelos de calidad.
  • CLASES Siguen …
    • Octubre
    • Middleware
    • Protocolos
    • EAI
    • Noviembre
    • Caracterización
    • Arquitectura
    • Patrones
    • Framework
    • Construcción de la interfaz
  • Patrones de Aplicaciones WEB Rodolfo Canelón
    • Patrones más comunes:
      • Thin Web Client (Cliente Web Ligero)
      • Fat Web Client (Cliente Web Pesado)
      • Web Delivery (Distribución Web)
    • No es una lista completa
      • evolución tecnológica constante
    • Es posible aplicar varios patrones a una misma arquitectura (topología)
    • Expresa esquemas de organización estructural básica para sistemas Web
    • Proporciona:
      • Conjunto de subsistemas predefinidos
      • Especificación de responsabilidades de cada subsistema
      • Reglas y guías para organizar las relaciones entre subsistemas
    Patrones de Aplicaciones Web
    • Aplicabilidad
      • Útil para aplicaciones basadas en Internet
      • Mínimo control de la configuración del cliente
      • El cliente sólo necesita un browser Web que realiza peticiones de páginas
      • Lógica del negocio ejecutada en el servidor
    • Usos Conocidos
      • Aplicaciones de comercio electrónico
    Thin Web Client (Cliente Web Ligero)
    • Estructura
      • Mínima arquitectura para una aplicación Web
      • Sus principales elementos están en el servidor
    • Elementos:
        • Browser del cliente (Cte)
        • Servidor Web (Cte)
        • Conexión HTTP (Ctor)
        • Páginas HTML (Cte)
        • Páginas del servidor (Cte)
        • Servidor de Aplicaciones (Cte)
    Thin Web Client (Cliente Web Ligero) (Cte): Componente ( Ctor): Conector
    • Vista lógica mínima del patrón
    Thin Web Client (Cliente Web Ligero) Browser HTTP Servidor Web Servidor de Aplicaciones Páginas del Servidor Páginas HTML + Cookies + Autenticación +Gestión de Cookies Estado de Sesión + Form +Entrada de Datos + Active Server Pages + Java Servlets + ISAPI + NSAPI + CGI + Java Server Pages
  • Thin Web Client (Cliente Web Ligero)
    • Elementos Opcionales
      • Persistencia
        • Sistemas de Bases de Datos, etc.
      • Integración con sistemas heredados
        • Sistemas Legacy, Sistemas Administrativos, etc.
    • Vista lógica completa del patrón
    Thin Web Client (Cliente Web Ligero) Browser HTTP Servidor Web Servidor de Aplicaciones Páginas del Servidor Páginas HTML Objetos del Negocio Persistencia Mapping de Persistencia Sistema de Contabilidad de Mercado Interfaz de Sistema Heredado + Active SP + Java SP + Java Servlets + ISAPI + NSAPI + CGI + Form + Elementos de Entrada + Estado de Sesión + Autenticación + Gestión de Cookies + Cookies
  • Thin Web Client (Cliente Web Ligero)
    • Consecuencias (del uso de este patrón)
      • Tiempo de Respuesta:
        • Adecuada para aplicaciones cuyas respuestas del servidor puedan ser completadas dentro del
          • tiempo de respuesta aceptable esperado por el usuario y
          • del valor de timeout permitido por el browser del cliente
        • No adecuada si la aplicación necesita permitir al usuario iniciar y controlar un proceso del negocio duradero
      • Interfaz de usuario
        • Capacidad de sofisticación limitada a lo soportado por el browser y la especificación HTML
  • Fat Web Client (Cliente Web Pesado)
    • Extiende el patrón Cliente Web Ligero con el uso de scripts y objetos en el lado del cliente:
      • Scripts del cliente, Controles, Applets, Plug-ins
    • El cliente puede ejecutar algo de lógica del negocio:
      • el browser es más que un contenedor de interfaces de usuario generalizado
  • Fat Web Client (Cliente Web Pesado)
    • Aplicabilidad
      • Útil para aplicaciones Web en las que
        • pueda asumirse cierto control sobre
          • la configuración del cliente y
          • la versión del browser,
        • se desea una interfaz de usuario sofisticada , o
        • el cliente puede ejecutar algo de lógica del negocio
    • Usos Conocidos
      • Interfaces de usuario enriquecidas
        • colores, animaciones, simulaciones, asistentes de navegación, etc..
      • Validación de datos
    • Estructura
      • Uso de capacidades del browser:
          • Scripts del cliente que sólo pueden interactuar con objetos en el cliente
          • Comunicación Cliente/Servidor vía HTTP
          • Componentes independientes o guiados por scripts en la página
          • Petición/envío/recepción/parsing de documentos XML
      • Elementos:
          • Los del patrón Cliente Web Ligero
          • Scripts del Cliente (Cte, Ctor) - Documentos XML (Cte, Ctor)
          • Controles ActiveX (Cte, Ctor) - Applets de Java (Cte, Ctor)
          • JavaBeans (Cte, Ctor)
    Fat Web Client (Cliente Web Pesado)
  • Fat Web Client (Cliente Web Pesado)
    • Vista lógica del patrón
    HTTP Objetos del Negocio Persistencia Mapping de Persistencia Sistema de Contabilidad de Mercado Interfaz de Sistema Heredado Páginas del Servidor + Active SP + Java SP + Java Servlets + ISAPI + NSAPI + CGI Páginas HTML + Form + Elementos de Entrada Servidor de Aplicaciones + Estado de Sesión Servidor Web + Autenticación + Gestión de Cookies Browser + DOM + Cookies Documentos XML + Elemento + Atributo Control ActiveX Applet Java Script del Cliente
    • Consecuencias (del uso de este patrón)
      • Portabilidad
        • No todos los browsers soportan JavaScript o VBScript
        • ActiveX sólo soportado por clientes MS-Windows
          • y el usuario puede desactivar su uso
        • Cada browser implementa su propia versión de Java
        • Diferencias en la implementación del DOM
      • Pruebas
        • Comprobar el comportamiento correcto de los scripts, controles o applets para cada browser y configuración del cliente que deba ser soportada
    Fat Web Client (Cliente Web Pesado)
  • Web Delivery (Distribución Web)
    • Sistema de objetos distribuidos basado en un sitio Web
    • Usa protocolos de comunicación entre cliente y servidor diferentes a HTTP
    • Pueden ejecutarse objetos reales en el contexto del cliente o el browser,
      • Con acceso a recursos del cliente
      • Pueden comunicarse directamente con objetos del servidor y con otros browsers
    • Aplicabilidad
      • Existe un control significativo sobre la configuración de cliente y de la red
        • No muy adecuado para aplicaciones basadas en Internet o cuando la red es poco fiable
        • Más adecuado para intranets (seguridad y rapidez)
      • Comunicación directa y persistente entre cliente y servidor
      • Combinado con otros patrones de arquitectura
    Web Delivery (Distribución Web)
    • Usos Conocidos
      • CNN Interactive Web Site
        • acceso público vía browsers y HTML3.2
        • tras el sitio Web está una red basada en CORBA de browsers, servidores y objetos distribuidos
      • Compañía de software para el cuidado de la salud
        • Aplicación Cliente Web Pesado para gestión de pacientes e historiales
        • Aplicación Distribución Web para facturación
    Web Delivery (Distribución Web)
    • Estructura
      • Comunicación entre cliente y servidor mediante protocolos diferentes a HTTP
      • Elementos:
        • Los del patrón Cliente Web Ligero y
        • DCOM (protocolo Cte – Ctor)
        • IIOP (protocolo Cte – Ctor)
        • RMI (protocolo Cte – Ctor)
    Web Delivery (Distribución Web)
    • Dinámica
      • El cliente participa en un sistema de objetos distribuidos
        • Comunica directamente con objetos del servidor
      • El Browser contiene ...
        • Interfaz del cliente y
        • Objetos del negocio
          • Descargados por el browser automáticamente desde el servidor
          • Comunicación, asíncrona e independiente, con objetos del servidor
    Web Delivery (Distribución Web)
    • Consecuencias (del uso de este patrón)
      • Traslada parte de la carga del servidor al cliente
      • Portabilidad (análogo a Cliente Web Pesado)
      • Requiere una red sólida
        • Conexiones cliente - servidor de larga duración
        • Una caída del servidor puede ser muy problemática
      • El cliente participa en un sistema de objetos distribuidos
        • Comunica directamente con objetos del servidor
    Web Delivery (Distribución Web)
  • Web Delivery (Distribución Web)
    • Vista lógica del patrón
    Objetos del Negocio Persistencia Mapping de Persistencia Sist. Contabilidad de Mercado Interfaz de Sistema Heredado Páginas del Servidor Páginas HTML Servidor de Aplicaciones Servidor Web Browser ActiveX del Servidor ActiveX del Cliente Applet Java DCOM RMI Http, Https, CORBA IIOP Enterprise JavaBeans
  • Patrones Arquitectónicos en Web Ejemplo
    • Aplicación para Bsc : Entorno PDVSA
      • Heterogeneos, Clientes Thin, Web Delivery, JDBC – SQLnet 2.1, Cliente/Servidor 3 tier.
      • Http, Https, Tcp/Ip, Objetos Serializados, Server Socket,Broker – Server Aplication
    Patrones para Manejo de Eventos: Proactor , The asynchronous Completion Token Patrones de Sincronización : Scope Locking C++, Strategized locking Patrones de Concurrencia : Active Object, Half Async BDD Server Applications cliente 1 cliente 2 cliente n Capa de Presentación (1) Capa de Funcionalidades de la Aplicación (2) Multi-DB SQL Net Proxy Server Applications Server Applications BDD
  • Patrones Arquitectónicos en Web
    • Microkernel o Socket
    • Reflection
    • Wrapper Façade
    • Component Configurator
    • Interceptor
    • Extension Interface
    • Multi-DataBase
    Patrones para Acceso y Configuración de Servicio
  • Patrones Arquitectónicos en Web (para Acceso y Configuración de Servicio)
    • Microkernel o Socket
    • Reflection
    • Wrapper Façade
    • Component Configurator
    • Interceptor
    • Extension Interface
    • Multi-DataBase
    • Separa un core funcional de las funcionalidades de más alto nivel.
    • Implementa servicios centrales, como facilidades de comunicación o manejo de recursos.
    • Implementa servicios atómicos o mecanismos, encapsulando dependencias del sistema.
    • Favorece la mantenibilidad (facilidad de cambios para la reutilización), la adaptabilidad (a diferentes ambientes) y la extensibilidad.
  • Patrones Arquitectónicos en Web (para Acceso y Configuración de Servicio)
    • Microkernel o Socket
    • Reflection
    • Wrapper Façade
    • Component Configurator
    • Interceptor
    • Extension Interface
    • Multi-DataBase
    • Proporciona un mecanismo para observar el estado de un componente con el fin de poder cambiar estructura y comportamiento de un sistema en tiempo dinámico .
    • Favorece la mantenibilidad (facilidad de cambios para la reutilización) y la adaptabilidad (a diferentes ambientes).
  • Patrones Arquitectónicos en Web (para Acceso y Configuracion de Servicio)
    • Microkernel o Socket
    • Reflection
    • Wrapper Façade
    • Component Configurator
    • Interceptor
    • Extension Interface
    • Multi-DataBase
    • Encapsula las funciones y los datos proporcionados por las APIs no orientadas a objeto, en clases de interfaces más concisas, robustas, portables y mantenibles.
    • Favorece la mantenibilidad, portabilidad y confiabilidad (tolerancia a fallas).
  • Patrones Arquitectónicos en Web (para Acceso y Configuración de Servicio)
    • Microkernel o Socket
    • Reflection
    • Wrapper Façade
    • Component Configurator
    • Interceptor
    • Extension Interface
    • Multi-DataBase
    • Permite la reconfiguración de componentes en tiempo de ejecución, sin tener que modificar, recompilar o volver a enlazar estáticamente la aplicación.
    • Favorece la mantenibilidad (modularidad para testing) y la portabilidad (adaptabilidad).
  • Patrones Arquitectónicos en Web (para Acceso y Configuración de Servicio)
    • Microkernel o Socket
    • Reflection
    • Wrapper Façade
    • Component Configurator
    • Interceptor
    • Extension Interface
    • Multi-DataBase
    • Permite agregar servicios en forma transparente cuando ocurren ciertos eventos.
    • Variantes del patrón: Chain-of-responsability, Publisher/subscriber y Subject/observer.
    • Favorece la mantenibilidad (facilidad de cambios para la reutilización).
  • Patrones Arquitectónicos en Web (para Acceso y Configuración de Servicio)
    • Microkernel o Socket
    • Reflection
    • Wrapper Façade
    • Component Configurator
    • Interceptor
    • Extension Interface
    • Multi-DataBase
    • Permite que múltiples interfaces sean exportadas por un componente a fin de prevenir un aumento de interfaces y la ruptura del código cliente la funcionalidad de un componente es extendida o modificada.
    • Favorece la mantenibilidad (facilidad de cambios para la reutilización).
  • Patrones Arquitectónicos en Web (para Acceso y Configuración de Servicio)
    • Microkernel o Socket
    • Reflection
    • Wrapper Façade
    • Component Configurator
    • Interceptor
    • Extension Interface
    • Multi-DataBase
    • Permite la manipulación de los datos centrales de las BDs a través de componentes externas independientes que pueden variar entre sistemas.
    • Organiza las BDs distribuidas sobre un modelo cliente/servidor, donde agentes o mediadores, aceptan los queries de los usuarios, los reconducen a las BDs disponibles y devuelven las respuestas adecuadas.
    • Favorece la mantenibilidad (facilidad de cambios para la reutilización) y la adaptabilidad (a diferentes ambientes).
  • Patrones Arquitectónicos en Web
    • Reactor
    • Asynchronous Completion Token
    Patrones para Manejo de Eventos
  • Patrones Arquitectónicos en Web (para Manejo de Eventos)
    • Reactor
    • Asynchronous Completion Token
    • Es un driver para que las aplicaciones multiplexen y despachen servicios que son liberados a uno o mas clientes.
    • Facilita el mecanismo de activación entre cliente y aplicación, favoreciendo la adaptabilidad.
  • Patrones Arquitectónicos en Web (para Manejo de Eventos)
    • Reactor
    • Asynchronous Completion Token
    • Permite a una aplicación multiplexar eficientemente las respuestas de operaciones asíncronas entre un proceso y un servicio.
    • Favorece la mantenibilidad.
  • Patrones Arquitectónicos en Web
    • Strategized Locking
    • Thread-Safe Interface
    Patrones para Sincronización
  • Patrones Arquitectónicos en Web (para Sincronización)
    • Strategized Locking
    • Thread-Safe Interface
    • Mecanismo de sincronización que protege a un componente en sección critica desde accesos concurrentes.
    • Favorece la adaptabilidad (a diferentes ambientes).
  • Patrones Arquitectónicos en Web (para Sincronización)
    • Strategized Locking
    • Thread-Safe Interface
    • Minimiza la sobrecarga sobre un lock para que el proceso no se bloquee (entre en un deadlock).
    • Favorece la mantenibilidad (facilita el testing y evita errores terminales).
  • Patrones Arquitectónicos en Web
    • Active Object
    • Monitor Objects
    • Half Sync / Half Async
    Patrones de Concurrencia
  • Patrones Arquitectónicos en Web (para Concurrencia)
    • Active Object
    • Monitor Objects
    • Half Sync / Half Async
    • Sincroniza los accesos al objeto activo dentro del propio threads de control.
    • Favorece la mantenibilidad, la extensibilidad, la adaptabilidad.
  • Patrones Arquitectónicos en Web (para Concurrencia)
    • Active Object
    • Monitor Objects
    • Half Sync / Half Async
    • Asegura la sincronización a un único método a la vez en runtime.
    • Favorece la mantenibilidad (para testing).
  • Patrones Arquitectónicos en Web (para Concurrencia)
    • Active Object
    • Monitor Objects
    • Half Sync / Half Async
    • Acopla y desacopla servicios en sistemas concurrentes, utilizando dos capas de intercomunicación.
    • Favorece la extensibilidad, la adaptabilidad.
  • Las características más importantes de los ambientes móviles
    • La heterogeneidad: El procesamiento se llevara a cabo en un espectro ancho de dispositivos del cliente, cada uno con configuraciones y funcionalidades diferentes.
    • El predominio de Dispositivos "Pequeños": Muchos dispositivos serán pequeños, no sólo en el tamaño sino también en el poder computacional, tamaño de memoria, entre otros.
    • Capacidades limitadas de la Red: La mayoría de los dispositivos tendrían alguna forma de conexión. Sin embargo, incluso con los nuevos estándares de redes como GPRS, Bluetooth, 802.11x, etc., El ancho de banda todavía estaría relativamente limitado comparado a las tecnologías de red existentes. Además, las conexiones son normalmente inestables.
    • La alta Movilidad: Los usuarios pueden llevar los dispositivos de un lugar a otro sin detener los servicios.
    • Orientados al Usuario: Se relacionarían los servicios al usuario en lugar de a un dispositivo específico o localización específica.
    • El Ambiente muy Dinámico: Un ambiente en el cual los usuarios y dispositivos siguen instalándose, dentro y fuera de la red.
    • Aplicaciones Distribuidas: Una aplicación simple tiene que ser desarrollada de una manera distribuida, es decir tiene que identificar partes que corran independientemente sobre otros dispositivos.
    • Disponibilidad: Hacer posible la disponibilidad, ancho de banda y la reliability de las conexiones móviles, teniéndose que solventar problemas de redes.
    • Seguridad: Privacidad, integridad y autentificación es un uso importante. Los datos en escenarios móviles son generalmente confidenciales [5,6,7,12], pero las comunicaciones inalámbricas son bastante inseguras.
    • Interfaces Dinámicas: Cuando diseñamos interfaces de usuarios para dispositivos móviles, especialmente para ambientes heterogéneos, tenemos que considerar requerimientos de usuarios especiales tanto como las capacidades de los dispositivos involucrados.
    • Un requisito importante para los sistemas de computación móviles son la habilidad de adaptarse en tiempo de ejecución, para manejar nuevos requerimientos como la movilidad del usuario, la variabilidad del recurso, cambios en las necesidades del usuario y fallas del sistema descritos en [5,16], con lo cual tenemos que las investigaciones actuales para construir las aplicaciones distribuidas no son eficaces en un ambiente móvil.
    Las características más importantes de los ambientes móviles
  • Nuevos requisitos que deben ser incorporados en la infraestructura
    • La adaptación a la Diversidad: La cual se define como la habilidad para que las aplicaciones puedan adaptar su funcionalidad según los requisitos del dispositivo, redes, entre otros.
    • La Interacción creciente con las conexiones punto a punto: Muchos de estos dispositivos formarán una red ad-hoc que se conecta entre ellos para intercambiar la información y para proporcionar los servicios a los usuarios.
    • El Modelo de Computación flexible: En un ambiente de computación móvil, hay varias maneras de acceder tipos diferentes de datos según las necesidades de los diferentes usuarios. Una combinación de código y movilidad de los datos debe permitir construir un modelo de computación flexible.
  • Modelo Conceptual APLICACIONES MOVILES Servicios Dispositivos móviles Teléfonos inteligentes Pad´s Otros Handhelp Contexto Conectividad Red Usuario Comunicación Administración Información Funciones del dispositivo Ambiente Físico Procesadores Disponibles Tiene_asociado_Un 1..* Se_Ejecutan 1..* 1..* QoS Funciones del Usuario 1..* Influye_en Ambiente del usuario Localización Perfil Iluminación Nivel de ruido Dispositivos I/O Disponibles Recursos Interacción Tiene_Asociado 1..* Tienen 1..* Usa Se_Adaptan Ambiente Computacional 1..*
  • Componentes de las aplicaciones Servicios y Aplicaciones GUI /Client Side MIDDLEWARE Seguridad ) ) ) Figura 2-5. Componentes de las aplicaciones
  • Componentes de las aplicaciones Servicios y Aplicaciones GUI cliente Contexto Seguridad ) ) ) Figura 2-5. Componentes de las aplicaciones Mediator )
  • Requisitos No Funcionales APLICACIONES MOVILES Confiabilidad (confiability) -Disponibilidad (availability) 1. Garantizar la disponibilidad del servicio al conectarse.
    • Los dispositivos se conecten y desconectan dinámicamente a la red.
    Funcionalidad (Functionality) -Adecuada(Suitability) Usabilidad (usability) -Operabilidad (operability) 1. Ofrecer funcionalidades que respondan a las necesidades de los usuarios. 2. Facilidad en la selección de los servicios ofrecidos.
    • El usuario selecciona los servicios disponibles en el área de cobertura.
    Confiabilidad (confiability) -Disponibilidad (Availability) Eficiencia (eficiency) -Comportamiento del tiempo (Time Behaviour) con respecto al tiempo de respuesta y a las conexiones. 1. Hacer posible los servicios, lo cual implica, ancho de banda apropiado y garantizar las conexiones móviles, teniéndose que solventar problemas de redes. 2. Tiempo de transmisión apropiado. Tiempos de respuesta adecuados dentro de un rango establecido .
    • Los servicios deben ser garantizados dentro del área de cobertura.
    Portabilidad (Portability) -Adaptabilidad (adaptability) 1. Las funcionalidades deben adaptarse a las características de los Dispositivos.
    • Los servicios se ejecutan en una diversidad de dispositivos, cada uno con configuraciones y funcionalidades diferentes.
    Procesamiento Funcionalidad (Functionality) - Conformidad (Compliance) 1. Cumplir con estándares, normativas con el fin de garantizar el servicio requerido.
    • Uso de protocolos de comunicación de redes, ancho de banda.
    Políticas Propiedades de Calidad asociadas a los requisitos no funcionales (Características de Calidad) ISO/IEC 9126-1 [15] Requisitos no funcionales derivados de las reglas del negocio. Reglas del negocio asociadas al Dominio
  • Requisitos Funcionales APLICACIONES MOVILES Confiabilidad (Confiability) -Disponibilidad (Availability) Funcionalidad (Functionality) -Interoperabilidad (Interoperability) Compartir Datos: Los dispositivos móviles formarán una red ad-hoc que se conecta entre ellos para intercambiar la información y para proporcionar los servicios a los usuarios. Usabilidad (Usability) -Atractivo (Atractiveness) - Operabilidad (Operability) Servicios de administración: (defecto, configuración, Bitácora, ejecución y seguridad) Portabilidad (Portability) -Conformidad (compliance) -Escalabilidad (Scalability) Funcionalidad (Functionability) -Seguridad (Security) Servicios de comunicación: comunicación entre usuarios, transporte de información y establecimiento de conexiones. Usabilidad (Usability) -Atractivo (atractiveness) -Operabilidad (Operability) Portabilidad (Portability) -Adaptabilidad (adaptability) -Escalabilidad (Scalability) Servicios de información: gestiona información al usuario. Confiabilidad (confiability) -Disponibilidad (availability) Con respecto a lo limitado del recurso de espacio) Eficiencia (Efficiency) -Comportamiento del tiempo (Behaviour time) (con respecto al tiempo de respuesta limitado). Funcionalidad (Functionality) - Precisión (accurancy) En el estándar QoS ISO [17], la integridad esta relacionada con acurrancy. Manejar Datos: Los datos deben ser transmitidos completa y correctamente. Propiedades de calidad asociadas (Características de calidad ) ISO/IEC 9126-1 [15] Requisitos Funcionales
  • Patrones de Interacción Móvil
  • Problemas en la construcción de interfaces 1.- Dificultad para construir software usable 2.- Se desestima la necesidad de un grupo de desarrollo multidisciplinario 3.- Problemas de comunicación entre los miembros de un grupo multidisciplinario 4.- En la práctica no se reconoce la relevancia del usuario 5.- Falta de integración entre la Interacción Humano-Computador y la Ingeniería de Software. Patrones de Interacción Móvil
  • Construcción de software usable
    • Cualidad del software cuyos indicadores son facilidad de aprendizaje, facilidad de memorización, satisfacción del usuario, eficiencia en cuanto al uso y baja rata de errores
    Usabilidad Usuario Patrones de Interacción Móvil
  • Grupo multidisciplinario de desarrollo Diseñador Gráfico Psicólogo Especialistas en IHC Especialistas en el dominio Usuario ... Para el diseño de Interfaces de Usuario se requiere un equipo que incluya al usuario, especialistas del dominio de la aplicación y a especialistas de otras disciplinas Patrones de Interacción Móvil
  • ¿En que se basa el diseño de interfaces?
    • Aplicación de principios y lineamientos
    • Análisis de interfaces exitosas
    • Evaluaciones de usabilidad
    • Resultados de estudios en el área Cognitiva, social, educativa, etc.
    • Estudios empíricos.
    Patrones de Interacción Móvil
  • Guías de Diseño
    • Los principios son conceptos de alto nivel que orientan la actividad del diseño de la interfaz
    • Los lineamientos son reglas que se establecen en una organización para el diseño y desarrollo de interfaces referentes al look and feel
    Patrones de Interacción Móvil
  • Limitaciones de los principios y lineamientos
    • Son abstractos (“darle control al usuario”, pero...)
    • Son generales (”usar bien los colores”, pero...)
    • Independientes del contexto (“utilizar teclado y ratón”, pero...)
    • No se relacionan a un problema específico (“divulgación progresiva”, pero...)
    Patrones de Interacción Móvil
  • Patrón de Interacción: definición
    • Un patrón de interacción describe una solución exitosa a un problema recurrente concerniente a la interfaz de usuario, en un contexto dado
    Patrones de Interacción Móvil
  • Antecedentes
    • Patrones de interacción como una herramienta apropiada para la captura y reutilización de las experiencias y conocimientos de los expertos
    90’s Patrones en Computación Patrones en IHC Patrones de Interacción Móvil
    • Describir un problema, su contexto y la solución
    • Generalizar una solución
    • Facilitar la comunicación entre miembros de distintas disciplinas
    • Registrar el conocimiento y la experiencia
    • Facilitar el prototipaje de la interfaz de usuario.
    Patrones de Diseño Un patrón de interfaz sirve para: Patrones de Interacción Móvil
  • Para qué usar patrones?
    • El uso de Patrones de Interacción en la construcción de la interfaz de usuario, facilita:
      • La construcción de software usable ,
      • La comunicación entre los miembros del grupo de desarrollo multidisciplinario ,
      • Para la construcción del prototipo de interfaz (incorporando esta actividad al proceso de desarrollo de software) .
    Patrones de Interacción Móvil
  • Estructura de un Patrón de Interfaz Patrones de Interacción Móvil
  • Ejemplo de un Patrón de Interacción Patrones de Interacción Móvil Nombre Formatos de datos de fechas Martijn van Welie Problema El usuario desea introducir datos de fechas y no desea preocuparse por la sintaxis del dato Solución Permitir que el usuario elija la fecha de un calendario tal como se encuentra en el mundo real y que solo realice selección –el usuario no tipea. Contexto Todos los sistemas que requieran que el usuario introduzca fechas (importante en interfaces internacionales) Fuerzas -     - Los datos de fechas tienen múltiples sintaxis -     Principio Usabilidad - Guiar al usuario y prevenir errores - Convenciones culturales determinan la sintaxis esperada Ejemplo
  • Patrones de Interacción Móvil
    • El Problema
    • La tecnología wireless
    • Dispositivos móviles
    • Redes
    ¿El Cómo? y la Forma de Interacción de los Usuarios con dispositivos móviles de manera reciproca Diferentes dispositivos Implica Aunado Influencia altamente Diferentes usuarios Diferentes Dispositivos Visualizar la Problemática considerando varias áreas Patrones de Interacción Móvil
  • EL PROBLEMA – Áreas del Problema
    • La aplicación tiene que ser desarrollada de manera distribuida
    • Involucrarse en los problemas de red
    • La seguridad de los datos
    • Requisitos especiales de los usuarios
    • Capacidades de los dispositivos involucrados
    Patrones de Interacción Móvil
  • EL PROBLEMA – Patrones de Diseño Con frecuencia un diseñador se enfoca sobre un área específica del problema, descuidando otras Fallas completas en el Diseño
    • Problemática que se presenta en las fases iniciales de diseño
    Áreas del Problema Patrones de Diseño Aunado Pudiese causar Posible Solución Patrones de Interacción Móvil
  • Patrones de Diseño Los patrones se derivan del diseño de software exitoso y que pueden ser reutilizados como bloques de construcción para nuevos diseños . Patrones Móviles Los patrones móviles cubren áreas del problema que los autores encontraron frecuentemente en los escenarios móviles Los patrones móviles relacionados pueden agruparse en patrones de clases, utilizando una Jerarquía de Patrones. Patrones de Interacción Móvil
  • Jerarquía de Patrones Patrones de Interacción Móvil
  • Jerarquía de Patrones Los patrones móviles no solo son aplicables en los escenarios móviles Los patrones de diseño que aparecen frecuentemente en escenarios móviles son buenos candidatos para nuevos proyectos Patrones de Interacción Móvil
  • Descripción de Patrones de Diseño Móviles Para describir los patrones de diseño móviles se utiliza el esquema de descripción de Patrones utilizados por Gamma.
    • Pattern Name
    • Synopsis
    • Context
    • Forces
    • Solutions
    • Consequences
    • Examples
    • Related Patterns
    • Classes
    • De la descripción propuesta usada en el desarrollo de software orientado a objeto:
    • Se reemplaza la sección Implementation por Examples
    • Se agrega la sección Classes
    • Pattern Name
    • Intent
    • Also Known As
    • Motivation
    • Applicability
    • Consequences
    • Structure
    • Participants
    • Collaborations
    • Consequences
    • Implementation
    • Sample Code
    • Known Uses
    • Related Patterns
    Patrones de Interacción Móvil
  • Estructura de un Patrón Móvil Patrones de Interacción Móvil
  • Proxy
    • Se utiliza cuando es imposible referenciar a un objeto, por ejemplo porque resida en otro procesador
    • Una ventaja es que ofrece la posibilidad de que el servidor pueda estar en un espacio de direcciones distinto al cliente en un sistema Distribuido
    • La principal desventaja es la perdida de performance cuando hay un solo cliente porque podrían comunicarse directamente.
    • Otra desventaja es que debe conocer la dirección del servidor Broker.
    Patrones de Interacción Móvil
  • Proxy - Patrón Móvil de Interacción Patrones de Interacción Móvil
    • Un usuario requiere una tarea especifica :
    • Busca seguridad en el ancho de banda de la red
    • Busca seguridad en los recursos computacionales ( memoria) sobre el dispositivo local
    • Espera apropiadas I/O acorde a las capacidades locales disponibles.
    Considere un usuario en un browser Web con un dispositivo handhelp. La resolución de la pantalla del dispositivo es actualmente pobre entonces elementos como gráficos y tablas son dificultosos de mostrar. Un dispositivo no tiene la capacidad de ejecutar una tarea requerida. Este conecta a otro dispositivo con un alto poder computacional el cual actúa como un delegado. SINOPSIS CONTEXTO FUERZAS
  • Proxy - Patrón Móvil de Interacción Patrones de Interacción Móvil
    • El dispositivo no se conecta directamente al punto final del servicio requerido pero pregunta a otro dispositivo o computador para ejecutar esta tarea. Este otro dispositivo o computador se llama proxy :
    • Acepta requerimientos de servicios desde otro dispositivo
    • Conecta al actual proveedor de servicio y ejecuta el requerimiento
    • Procesa los resultados
    • Envía de regreso al dispositivo inicial
    SOLUCION
  • Proxy - Patrón Móvil de Interacción Patrones de Interacción Móvil
    • Este patrón, es un patrón general y usado en varios escenarios móviles. Frecuentemente, los dispositivos usados por los usuarios finales tienen capacidades pobres. En este patrón hay 2 ptos cruciales:
    • El proxy en caso de fallar , la ejecución de las tareas son habilitadas, siempre que el dispositivo que requiera y el proveedor del servicio esten en linea.
    • El enlace de comunicación entre el dispositivo que requiere y el proxy , si este enlace es roto , la tarea no puede ser ejecutada.
    • Obviamente , el proxy tiene que tener mas capacidades que el dispositivo del usuario final. Como el proxy provee un servicio especifico el dispositivo móvil tiene que poder encontrar el proxy dentro de la red esto trae las siguientes consecuencias:
    • Un proxy tiene que tener una dirección fija en la red
    • El proxy tiene que estar en línea cuando un servicio sea requerido.
    • Actualmente un proxy es usualmente una estación de trabajo tradicional, no un dispositivo móvil
    CONSECUENCIAS
  • Proxy - Patrón Móvil de Interacción Patrones de Interacción Móvil ServiceUsage, MobileService CLASES PushObject, RequestObject PATRONES RELACIONADOS ProxyWeb ( http://www.intellisync.com ) permite a usuarios handhelp usar browser sin forzar las limitaciones. El proxy preprocesa las paginas , descarga las imágenes y pre calcula el layout apropiado. Como resultado la cantidad de datos transferidos al dispositivo es reducido drásticamente. PocketDreamTeam es la versión PalmOS. EJEMPLOS
  • Proxy - Estructura Patrones de Interacción Móvil Client …… . ... Real Subject ...
  • Editor de documentos (Ej.) DocumentEditor Graphic ImageProxy Image Draw() GetExtend() Store() Load() Draw() GetExtend() Store() Load() Draw() GetExtend() Store() Load() Image If (Image==0) { Image=LoadImage(Name); } Image->Draw(); If (Image==0) { return extend; }else { return Image->GetExtend(); } ImageImp extend Name extend Patrones de Interacción Móvil
  • Ventajas
    • Principalmente los patrones son una herramienta para describir diseños.
    • Los patrones vienen con una lista de implicaciones y consecuencias. (un diseñador está consiente de los pro y los contra de un patrón específico).
    • Los patrones permiten a un diseñador reutilizar los diseños exitosos.
    Patrones de Interacción Móvil
  • Análisis Crítico
    • ¿ Los patrones móviles propuestos por el autor pueden considerarse Alejandrinos?
    • El esquema propuesto para describir los patrones a pesar de hacer referencia al esquema presentado por Gamma, ha sido bastante modificado, se aproxima mucho mas al esquema propuesto para describir los patrones de interacción presentado por “ Colocar autor - ojo Rodolfo”.
    • El trabajo presentado abre las puertas a un área específica de la investigación, y son muchos los beneficios para los diseñadores de aplicaciones móviles que traería el enriquecimiento de la jerarquía de patrones presentada por el autor.
    Patrones de Interacción Móvil
  • Conclusiones
    • La jerarquía de patrones presentada no pretende estar completa. En el futuro se espera completar la colección de patrones móviles; en tal sentido se analizan las aplicaciones existentes en la computación móvil y los frameworks.
    • Al esquema presentado para describir los patrones móviles se le incorporó la sección Clases que indica cómo un patrón se integra en la jerarquía de patrones. Las clases del patrón dan información adicional de la estructura a un diseñador, así pueden clasificarse los problemas y soluciones relacionadas a un patrón específico más fácilmente
    • Comparado a los acercamientos más formales (por ejemplo [Borchers J.]), los patrones de movilidad tienen una característica fuertemente informal.
    Patrones de Interacción Móvil
  • Bibliografía
      • Thomas Plan, Richard Guy and Rajive Bagrodia . Universitu of California At los angeles .A scalable, Distributed Middleware Service Architecture to Support Mobile Internet Applications. 7 workshop on wireless mobile Internet. Rome 2001.
      • Jonathan Knudse . Wireless Java: Developing with JavaTM 2 Micro Edition July 2001.
      • Sun Microsystems Inc. Connected, Limited Device Configuration (JSR-30), 2001
      • Tim Lindholm and Frank Yellin . The Java Virtual Machine Specification (Java Series), Second Edition. Addison-Wesley, 1999, ISBN 0-201-43294-3 August 1998. Development of a Java-based version of ExploreNet http://www.cs.ucf.edu/ExploreNet/ - 27.6KB - explorenet: 17
    Patrones de Interacción Móvil